後輩「YAGNIと『先回り設計』って矛盾しませんか？」
執筆の契機: チームメンバーからの本質的な問い
ある日のチームメンバーとの1on1で、技術的な課題について話しました。
その中でこのような問いがありました。（経緯は割愛）
「YAGNI（不要なものは作らない）と、予測して先回りする設計って矛盾してませんか？どう両立させるかが難しいと思いました。」
「良い質問だな」と思いました。同時に、回答に困りました。
「（プロジェクトやソフトウェアの）将来の寿命を考慮できているか？や、その観点を持っているか？が大事だと思う。」
「短期的に機能要件を満たし"ただ単に動けばいい"という考え方だと、（経験則上）手戻ることが多いよ。」
その場ではこのように答えましたが、表層的な回答だったと反省して学びを整理しようと思いました。
エンジニアなら誰もが直面するジレンマ
実際、この矛盾は開発現場でよく起きます。
例えば
- 「早く出したい」チーム：「YAGNIでいこう、今必要な機能だけ」
- 「設計重視」エンジニア：「将来のこと考えないと技術負債が...」
どちらも正論に聞こえるため、議論が平行線になりがちです。
新機能や非機能要件を予測して先回りする誘惑は常にあります。
特にAIの普及で実装の初速が上がり、「つい追加で作りたくなる」誘惑が強まったと感じます（僕もそうなりがちです）。
一方でYAGNIは「今いらないなら作るな」と言う。
この矛盾に対する答えは「不可逆性」という軸で判断することだと考えています。
不可逆な意思決定の存在
この矛盾が生まれるのは、「後戻りできない意思決定」と「後戻りできる意思決定」が混在しているからです。
プロの設計は、最小限の現在最適を選びながら、不可逆な領域だけは先に潰します。
ここでの失敗は以下の両極端に振れることです：
- 「全部を先回りする」→ 過剰設計で速度が出ない
- 不可逆性を考慮せずYAGNIを適用する → 後戻りできない設計ミス
不可逆を特定し、そこだけ手当てするのが要点です。
例示: 不可逆な意思決定の4分類（読み飛ばしOK）
不可逆とは、後から直すと「移行・再ログイン・再設計」がセットで発生し、コストが跳ねる領域です。
- アーキテクチャレベル: DBスキーマ/認証/サービス境界。変更は全体改修＋移行になりやすい（例: 認証方式のやり直し、数百万行のデータ移行）。
- インフラ・プラットフォーム: クラウド/言語/主要FW。運用モデルごと固定され、移行は月〜年になりがち（例: 事実上の全面リライト）。
- データ・API設計: 公開API/フォーマット/連携仕様。互換性が命で、曖昧だとバージョニング地獄になりやすい（例: 非推奨化ポリシー未定で破綻）。
- セキュリティ・コンプライアンス: 暗号化/監査ログ/削除権。後付けが難しく、再暗号化やログ粒度不足で詰む（例: GDPRの削除権対応）。
実践的な判断フレームワーク
不可逆性の判定方法
チェックリストは「やる/やらない」を感情論から引き剥がすためのものです。
後述するアンチパターンでも整理するが、「Leanさ」や「正しさ」を優先しすぎると、前提や不確実性を見落として意思決定を誤ることがあります。
各項目に対して事実で答えます。Yesが出たら、「先回りを検討する価値がある」サインとして扱います。
そうでないなら、まずはYAGNIで進める判断がしやすいです。
これは先回りすべき？チェックリスト
不可逆度合いでクリティカル、Highで整理しました。
特にクリティカルは、どのプロジェクト / プロダクトでも必ず気にすべき事項です。
不可逆度がクリティカル: 1つでもYesなら「不可逆」として先回り検討
□ コスト要件に関わるか？（予算的に大丈夫？）
□ 法的・コンプライアンス要件に関わるか？（機密情報は保護されている？どこかに蓄積されてない？蓄積されたものは追跡・保護できている？）
□ 既存データの移行が必要になるか？（将来的にデータベースの移行が発生するか？）
コストとセキュリティは言わずもがなですが、私はデータ移行の観点は注意してみるようにしています。
これは過去「CRMのデータ移行プロジェクト」での学びが大きいです。
このプロジェクトで、「互換性がないシステムに、データを失わないように移行すること」は極めて困難だったことを経験しました。
（参考）
不可逆度がHigh: 1つチェックついたら、テックリードやマネージャーと相談
□ 外部組織への依存はあるか？（他チームのヘルプが必要になる？他チームに影響ある？）
□ 外部システムとの調整が必要か？
□ ユーザーに影響するか？
□ 変更に1人月以上かかるか？
重要なのは、チェックを通った部分だけに先回りを限定することです。
アンチパターンの回避
（自戒も込めて）立場や経験に頼った正論の押し付けを避ける
- 「技術的には〜」「ベストプラクティス的には〜」の口癖
- 不確実性を無視した過剰設計
「正しさ」だけを前面に出すと、速度や学習機会が失われがちです。
全部を固めてはいけません。 柔らかいところは柔らかいままにして速度を確保しましょう。
バランス感覚：
- 不可逆なものは慎重に先回り
- 可逆なものは積極的にYAGNI
- チェックリストで判断、感情で判断しない
この三点をチームの合意事項として明文化すると、議論コストが大きく下がります。
「YAGNIと"予測して先回りする設計"って矛盾してませんか？」への答え
「不可逆な意思決定を外してないなら、進めば良いよ。」
こう答えるのが良かったと思います。
下記のようなバランス感覚で言語化できました。
- 短期最適に寄りがちな判断：「動けばOK」で後で困る
- 設計重視に寄りすぎた判断：「設計的には〜」で過剰設計になる
- 不可逆性を意識した判断：先回りとYAGNIを使い分ける
まとめ
現場では「早く出す」と「長く持たせる」が常に衝突します。だからこそ、不可逆性という軸で意思決定を簡略化できます。
迷ったら小さく出し、不可逆だけは外さない。これに尽きるなと思いました。
Discussion