プロジェクトの振り返りをしていると、よくこんな言葉を聞きます。
「この設計は間違っていた」
「この判断が悪かった」
ただ、長く開発の現場にいると、少し違う見え方をすることがあります。
多くの場合、問題は判断が間違っていたことではありません。問題は「なぜその判断をしたのか」が残っていないことです。
判断は、必ず“前提”の上にある
例えばこんな判断があります。
「スパゲッティコードでもいいからまずは動かす」
「品質よりスピード優先で作る」
「完璧主義を捨ててMVPで出す」
こういう判断は、状況によってはとても合理的です。
ただし、そこには必ず前提があります。以下はその例です。
・ユーザーは数千人程度
・まずはPoC
・3ヶ月以内に結果を見る
・ダメなら作り直す
この前提の上なら、シンプルな実装は合理的です。
前提が変わると、判断は突然「失敗」に見える
しかしプロジェクトは、概して途中で状況が変わります。
・ユーザーが10倍になる
・PoCが本番になる
・機能追加が続く
・運用が長期化する
すると突然「この設計はダメだった」という話になります。
多くのトラブルは「前提のズレ」で起きる
実際の現場では、次のようなズレがよく起きます。
・開発の前提
「これはPoCなので簡易実装」
・事業の前提
「このまま本番運用」
・運用の前提
「3年は使う」
この状態では、どんな設計でも必ずどこかで問題が起きます。
なぜならそれぞれ別の前提で合理的な判断をしているからです。
そこで必要になるのが「判断ログ」
私が現場で意識しているのが判断ログという考え方です。難しいものではありません。
重要な判断をしたときに次の3つを残すだけです。
①前提
どんな条件を仮定したか
②判断
何を選んだか
③リスク
前提が崩れたら何が起きるか
例えばこうです。
①前提
ユーザー1万以下
②判断
単一DB構成
③リスク
10万ユーザーで性能問題
これだけです。
判断ログがあると、プロジェクトが安定する
判断ログが残っていると、プロジェクトはかなり楽になります。
例えばユーザーが増えたとき、普通のプロジェクトではこうなります。
「最初の設計が悪かった」
でも判断ログがあると、こうなります。
「前提が変わったので設計を見直そう」
この差はとても大きいです。
人を責める議論ではなく、構造を直す議論になるからです。
強いチームは「判断の理由」を残している
強いチームを見ていると、共通点があります。
それは判断の理由が残っていることです。
・なぜこの設計なのか
・どの前提で決めたのか
・どこまで想定しているのか
これが分かるだけで、議論の質は一気に上がります。
判断は未来から見ると必ず粗く見える
もう一つ大事なことがあります。
それは未来から見ると、過去の判断は必ず粗く見えるということです。
未来には
・実際のユーザー数
・実際の負荷
・実際の運用
という情報があります。
その情報で過去を評価すれば、どんな判断でも雑に見えます。
だからこそ重要なのはその時の前提で合理的だったかです。
技術より難しいのは「前提を揃えること」
プロジェクトで本当に難しいのは、アルゴリズムでもフレームワークでもなく、前提を揃えることだと思っています。
・どこまで作るのか
・どれくらい使われるのか
・どのくらい続くのか
ここが揃っていないと、どんな設計でも後で破綻します。
まとめ
もしプロジェクトの振り返りで「この判断は間違っていた」と感じたら、少しだけアプローチを変えてみると、見え方が変わってきます。
その判断は間違っていたのかそれとも前提が欠けていただけなのか。
多くの場合、問題は判断そのものではありません。判断ログがないことです。
おわりに
X（旧Twitter）やBlueskyを中心に日々発信しております。
ご興味をお持ちいただけましたら、ぜひ弊社Webサイトや私のXもご覧いただけますと幸甚でございます。
https://www.tatsu-mi-systemsolution.jp/
https://x.com/itchie_tatsumi
https://bsky.app/profile/itchie-tatsumi.bsky.social
