自分では大したことないと思っていた「判断」を棚卸ししてみた

私はこれまで、自分の仕事はコードを書くことだと思っていました。

画面を作る。
APIを作る。
データベースを作る。
最後にGCPへ載せる。

エンジニアなのだから、まあ普通です。

技術経歴書にも何を使って何を実装したのかを中心に書いてきました。

Next.jsが使えます。
Reactも使えます。
GoもLaravelも触れます。
フロントエンドからバックエンド、インフラまで一通り対応できます。

ずっとそういう見せ方をしてきました。

ところが最近、どうも話が違う気がしてきました。

私は設計を考えている時間は好きなのに、方針が決まって同じような実装を延々と続ける段階になるとわりと露骨に飽きます。

何を作るのか。
どこで分けるのか。
この構造であとから困らないか。
今回は何を作らないのか。

このあたりを考えているときは面白いのです。

でも、あとは決まった形をひたすら積み上げるだけとなると急に気持ちが重くなる。

昔はこれを根気がないせいだと思っていましたが、最近では少し違う見方をしています。

根気の問題ではなく、私が面白いと思っている仕事と売っていた仕事がズレていただけではないか。

私はコードを書く人として自分を売ってきました。

でも実際に価値を出していたのは、

「ここは分けたほうがよくないか」
「この構造だとあとで詰みそうだな」
「それ、本当に一つにまとめて大丈夫か」

と考えていた時間のほうだったのではないか。

そこで今回は、自分では大したことないと思っていた過去の判断をいったん掘り返してみることにしました。

この記事は、私がこれまで行ってきた設計判断のポートフォリオも兼ねています。

ただ、エンジニアだけに向けた記事ではありません。

自分には大した実績がないと思っている人にも、何か拾ってもらえれば嬉しいです。

自分にとって普通のことは実績として数えにくい

自分では大したことないと思っていたことが他人から見るとけっこう重要だった。

最近、そんなことが何度かありました。

自分にとって自然にできることはわざわざ記録しません。

迷った末に決めたことでも、

「普通に考えたら、こうするだろう」

くらいで終わります。

しかも実装者として案件に入っていると、設計上の判断も実装作業の中に埋もれます。

最終的に残るのは、

「画面を作った」
「APIを実装した」
「機能を改修した」

といった成果です。

なぜその形にしたのか。
何を分けたのか。
何を避けたのか。
何を作らないと決めたのか。

こちらはほとんど残りません。技術経歴書に書いたとしてもせいぜい一文です。

提案が採用されなかった場合はもっと残りません。完成したものがないので実績として書きにくいからです。

そのうち自分の中でも、

「まあ、何もしていないのと同じか」

くらいの扱いになります。

でも、経験は肩書きどおりには残りません。

何を担当したかだけでなく、何を見て、何を考え、何を決めたかまで掘り返さないと自分の価値は見えてこないのだと思います。

「全部まとめたほうが楽」があとで首を絞める

以前、業務システムのリプレイス案件で入金や請求に関する複雑な処理を扱いました。

古いシステムではいろいろな処理が強く結びついていました。

一か所を変えると別の場所まで影響する。

似たような処理が増えるほどどこを直せばよいのかわからなくなる。

一見するとよくある、

「古いシステムは大変ですね」

という話です。

ただ、私が気になっていたのはコードが古いことだけではありませんでした。

どの処理は本当に共通なのか。
どこから先は別の業務として分けるべきなのか。
共通化したせいで逆に変更しにくくなっていないか。

こういったことが気になりました。

そこで、継承関係を増やして共通化するより、役割ごとの部品を組み合わせる構成へ変えました。

技術的には継承よりコンポジションを選んだという話です。

でも要するに、

「何でも同じ箱に突っ込むのをやめた」

ということです。

一つにまとめれば最初は楽に見えます。

同じ仕組みを使い回せる。
コードも減る。
見た目もきれいに揃う。

ただ、別々に変わるものまで一緒にすると、あとから一方だけ変えたくなったときに困ります。

これはシステムに限りません。

一つの商品に、相談、制作、伴走、質問対応を全部詰め込む。
一つの記事で、初心者にも経験者にも同時に話す。
一人の担当者に、判断、作業、管理、顧客対応まで全部背負わせる。

全部まとめれば整理できるとは限らず、むしろ、混ぜたせいで何が問題なのかわからなくなることがあります。

分けるべきものを分ける。

これも立派な設計です。

将来使いたいデータを何でも保存すればいいわけではない

個人で開発したSaaSでは、顧客情報、活動記録、メモ、タスクなどを扱いました。

こうした情報はすべて「顧客に関する情報」として一つにまとめることもできます。

顧客ページの中にメモもタスクも履歴も全部入れてしまう。

小さく作るだけならこのほうが早いです。

ただ、将来的には分析や診断にも使いたいと考えていました。

そこで、顧客、活動、メモ、タスクを別々の役割として扱いました。

誰の情報なのか。
いつ起きた活動なのか。
人が書いた記録なのか。
AIが作った要約なのか。
これからやるべき作業なのか。

このあたりを曖昧にすると、あとで分析したくなったときに困ります。

ただし、将来使うかもしれないからといって、何でも保存すればよいわけでもありません。

「いつか役に立つかも」で集めたデータはだいたい使われません。

入力する人だけが疲れます。
管理する項目だけが増えます。

将来を考えることと先回りして何でも作ることは別です。

どこまで残すのか。
何は持たないのか。

こちらも決める必要があります。

設計は、足すことより捨てることのほうが難しいのかもしれません。

AIに任せると楽。でも任せたら困る場所もある

別の個人開発ではAIを使った占術系の計算サービスを作りました。

このサービスには秒単位の精度が必要な計算処理があります。

AIは文章を作るのが得意です。解釈や説明もできます。

ただし、毎回同じ答えを返してほしい計算まで任せるのはさすがに怖い。

「昨日と今日で答えが少し違います」

では困ります。

そこで、計算の中核部分はGoで実装し、AIや外部サービスから切り離しました。

AIに任せるのは解釈や説明の部分。
こちらで保証するのは再現性が必要な計算部分。

全部AIに任せれば早い。
全部自分で作れば安心。

そんな単純な話ではありません。

変わっても困らないところと、勝手に変わったら困るところを分ける必要があります。

AIが便利になるほど、何を任せるかより何を任せないかの判断が重要になります。

AIを使わないことが慎重なのではありません。

任せてよい範囲を決めずに使うほうが、よほど雑です。

技術を一つに揃えると見た目はきれい

市場分析用のデータ収集ツールを作ったときは、バックエンドを一つの技術へ統一しませんでした。

大量のデータを処理する部分とブラウザを動かして情報を集める部分では、求められる性質が違ったからです。

高速に処理したい部分にはGoを使う。

ブラウザ操作や周辺ライブラリを使いやすい部分にはNestJSとPlaywrightを使う。

技術を一つに揃えたほうが見た目はきれいですし、開発環境も一つで済みます。

「このシステムは全部この言語で作っています」と言えるので説明もしやすい。

でも、統一することを優先しすぎると得意ではない仕事まで一つの技術に背負わせることになります。

何でもできる万能選手を一人雇うようなものです。

たしかに管理は楽です。

ただ、その人が倒れたら全部止まります。

技術選定は好きな言語を選ぶことではありません。

処理の性質、変更頻度、運用方法、使えるライブラリを見て、どの道具に任せるかを決めることです。

一つの道具ですべてを片づけようとすると、仕事に道具を合わせるのではなく、道具に仕事を合わせ始めます。

これでは、だいぶ本末転倒です。

きれいな画面より現場で迷わない画面

公共インフラの管理システムではデザイナーがいない環境で画面設計にも関わりました。

現場の人が日常的に使う業務システムです。

一般向けのWebサービスなら見た目の新しさや第一印象も大切です。

でも業務画面では毎日の入力や確認で迷わないことのほうが重要です。

どの順番で入力するのか。
一覧で何を比べたいのか。
どの状態なら次へ進めるのか。
間違えたときにどこへ戻ればよいのか。

画面は情報を並べる箱ではありません。

使う人が判断し、次の行動へ進むための道です。

どれだけきれいでも、毎回「次はどこを押すんだっけ」と迷うなら業務画面としては失格です。

使いやすさはボタンを丸くしたり、色を整えたりするだけでは生まれません。

誰が、いつ、何を見て、何を決めるのか。

ここまで考えないと見た目だけ立派な迷路が完成します。

提案したけれど普通に却下されたこともある

ここまで書くと、私が何でも自由に設計してきたように見えるかもしれません。

そんなことはありません。

問題を感じて改善案を出しても普通に却下されたことがあります。

理解されなかったこともあります。

採用されなかったので、その判断が正しかったのか最後まで検証できなかったこともあります。

当時は、

「説明の仕方が悪かったのか」
「もっと根拠を出すべきだったのか」
「自分の提案力が弱いのか」

と考えました。

それもあったと思います。

ただ、私は設計方針を決める立場ではなく実装者として入っていました。

実装者の改善案はあくまで一つの意見です。

責任者が同じことを言えば方針になります。

内容が同じでも誰が言うかで重さが変わる。

身もふたもない話ですが組織ではよくあります。

ただし、

「私は正しかったのに理解されなかった」

で終わらせるつもりもありません。

技術的に良い案と、組織の中で採用できる案は同じではないからです。

納期はどうなるのか。
変更範囲はどこまで広がるのか。
チームが理解して運用できるのか。
今ここで変える必要があるのか。

こうした条件まで含めて考える必要があります。

全面的な変更が無理なら一か所だけ変える。

理想の構造を一気に作るのではなく、今の制約でも採用できる大きさに縮める。

設計者には、良い案を考える力だけでなく、相手が受け入れられる大きさにする力も必要なのだと思います。

ここは、今後もっと経験を積みたい部分です。

設計者は最初から正解を知っている人ではない

設計者というと、全体を見通して、最初から正解を出す人のように聞こえます。

しかし実際には、

何が問題なのかを整理する。
分けるべきものを見つける。
いくつかの選択肢を比べる。
何を優先し、何を捨てるか決める。
制約の中で実行できる形へ落とす。

この繰り返しです。

設計は正解を当てる仕事というより、判断の基準を作る仕事に近いと思っています。

なぜこの形にしたのか。
何を守りたかったのか。
何が変わったら設計も変えるのか。

その基準があれば途中で状況が変わっても修正できます。

基準がないまま作り始めると問題が起きるたびにその場しのぎの対応が増えます。

そして最後には、

「もう怖くて触れない」

というものが完成します。

最初は小さかったはずなのに誰も全体を説明できない。

システム開発ではなかなか見覚えのある風景です。

これはシステム開発だけの話ではなかった

ここまでの話はシステム開発に限りません。

noteの記事でも商品づくりでもサービス設計でも同じことが起こります。

一つの記事に主張を詰め込みすぎる。
一つの商品で全員の悩みを解決しようとする。
便利そうな機能を追加し続ける。
何をやめるか決めないままやることだけ増やす。

こうなると頑張って手を動かしているのに前へ進みません。

むしろ動くほど複雑になります。

材料が足りないとは限りません。
能力が足りないとも限りません。

分け方や優先順位が決まっていないため、作業を増やすほど混線していることがあります。

私は、こうした混線した場所を見つけることが好きです。

何が本当の詰まりなのか。
何を今やって、何を後回しにするのか。

どこを分ければ次の判断がしやすくなるのか。

振り返ると、システム開発でも人の相談に乗るときでもnoteや商品を考えるときでも、見ている場所はあまり変わっていませんでした。

コードを書くことと相談を受けることはまったく別の仕事に見えます。

でも私の中では、

「混ざっているものを分ける」
「判断できる状態にする」

という点でかなり近いのだと思います。

今後は実装者ではなく設計者として売っていく

これまでの私は、フロントエンド、バックエンド、データベース、GCPまで横断して実装できることを前面に出してきました。

結果として幅広く実装できる人として見られていました。

必要なら今後もやりますが、ここを自分の価値の中心に置くと、当然ながら実装量を期待される案件が集まります。

そして私は、設計が終わった後の長い実装で飽き始めます。

これでは誰も得をしません。

今後は、要件整理、基本設計、アプリケーション設計、リプレイス設計、既存構造の改善を主軸として仕事を選びます。

必要に応じて実装にも入ります。

ただし実装は、設計の妥当性を確かめたり、難しい部分を形にしたりするための手段として扱います。

設計して、同じ形の実装を延々と続けるより、次の問題を整理し、次の方針を決める役割へ移りたい。

この記事を書いたことで、その方向がかなりはっきりしました。

大したことない判断の中に売るべき価値があった

自分には実績がない。
人に見せられる経験がない。

そう思っていても、実際には判断を実績として数えていないだけかもしれません。

何を完成させたかだけでなく、

何に違和感を持ったのか。
何を分けたのか。
何を選ばなかったのか。
何をやめたのか。
誰が迷わないようにしたのか。

そこまで振り返ると、自分では見落としていた価値が出てくることがあります。

私はこれまでコードを書いた量ばかりを実績として見ていました。

でも、自分にとって重要だったのは、何を作ったかより、なぜその形にしたのかでした。

自分では大したことないと思っていた判断の中に、これから売るべき価値が埋まっていました。

自分の中では普通すぎて実績として数えていない判断があるかもしれません。

何を作ったかだけでなく、何に違和感を持ち、何を分け、何を選ばなかったのか。

そこまで掘り返すと、これから発信や仕事に使える価値が見えてくることがあります。

WindShiftでは、会社員やフリーランスとして積み上げた経験を自分自身の事業に変えるための事業設計支援を準備しています。

経験を誰のどんな課題に結びつけ、商品、発信、集客へどうつなげるのか。その考え方を固定記事にまとめました。

また、法人や小規模事業者向けには、業務の整理、要件定義、AI活用、既存業務の改善を支援しています。

Webアプリケーションの要件整理、基本設計、リプレイス設計、既存構造の改善を含め、何を作るべきか、どこまで作るべきかを整理する段階から対応しています。

業務改善や設計支援をご検討の場合は、WindShiftのサイトをご覧ください。