🧠

YAGNIと『先回り設計』は本当に矛盾する?不可逆性で考えるプロの判断軸

に公開

執筆の契機: 若手エンジニアからの本質的な問い

ある日の若手エンジニアとの1on1で、技術的な課題について話しました。

その中でこのような問いがありました。(経緯は割愛)

「YAGNI(不要なものは作らない)と、予測して先回りする設計って矛盾してませんか?どう両立させるかが難しいと思いました。」

「良い質問だな」と思いました。同時に、回答に困りました。

「(プロジェクトやソフトウェアの)将来の寿命を考慮できているか?や、その観点を持っているか?が大事だと思う。」
「短期的に機能要件を満たし"ただ単に動けばいい"という考え方だと、(経験則上)手戻ることが多いよ。」

その場ではこのように答えましたが、表層的な回答だったと反省して学びを整理しようと思いました。

エンジニアなら誰もが直面するジレンマ

実際、この矛盾は開発現場でよく起きます。

例えば

  • 「早く出したい」チーム:「YAGNIでいこう、今必要な機能だけ」
  • 「設計重視」エンジニア:「将来のこと考えないと技術負債が...」

どちらも正論に聞こえるため、議論が平行線になりがちです。

新機能や非機能要件を予測して先回りする誘惑は常にあります。
特にAIが登場してからは、実装をアウトソーシングできるのでWantをどんどんやりたくなるエンジニアが増えているのではないでしょうか?(僕はそうなりがち。)

一方でYAGNIは「今いらないなら作るな」と言う。

この矛盾に対する答えは「不可逆性」という軸で判断することだと考えています。

不可逆な意思決定の存在

この矛盾が生まれるのは、「後戻りできない意思決定」と「後戻りできる意思決定」が混在しているからです。

プロの設計は、最小限の現在最適を選びながら、不可逆な領域だけは先に潰します。

ここでの失敗は以下の両極端に振れることです:

  • 「全部を先回りする」→ 過剰設計で速度が出ない
  • 「何も考えずYAGNIを盾にする」→ 後戻りできない設計ミス

不可逆を特定し、そこだけ手当てするのが要点です。

例示: 不可逆な意思決定の4分類

アーキテクチャレベル

  • データベース設計、認証方式、マイクロサービス分割
  • 一度決めると全体改修が必要

典型例はスキーマ変更と認証方式のやり直しです。数百万行のデータ移行や全クライアントの再ログインは、軽い判断では済みません。

マイクロサービス分割も同様で、境界を誤ると通信コストと整合性担保で延々と燃え続けます。

インフラ・プラットフォーム

  • クラウドプロバイダー、フレームワーク、言語選択
  • 移行コストが膨大(数ヶ月〜年単位)

IaaS/PaaSの選択は課金・運用モデルまで固定します。フレームワークや言語変更は事実上の全面リライトになります。

将来の採用難や運用人員の確保まで含めて、初期に最低限の見立てが必要です。

データ・API設計

  • 外部公開API、データフォーマット、連携仕様
  • 既存ユーザー・システムへの影響大

公開APIは互換性が命です。曖昧なスキーマや独自仕様は後からのバージョニング地獄を招きます。

最初にバージョン付け、エラー設計、非推奨化ポリシーを決めておくと被害を最小化できます。

セキュリティ・コンプライアンス

  • 暗号化方式、ログ設計、GDPR対応
  • 後から追加が困難/不可能

暗号化のやり直しは既存データの再暗号化を伴い、ダウンタイムやコストが跳ね上がります。監査ログの粒度不足は事後では埋められません。

削除権対応は最初からデータモデルに組み込むしかありません。

実践的な判断フレームワーク

不可逆性の判定方法

チェックリストは「やる/やらない」を感情論から引き剥がすためのものです。
後述するアンチパターンでも整理するが、美学として「Leanに美しく」だったり、「正しさ」を振りかざしたりすると意思決定を誤るからです。

各項目に対して事実で答えます。Yesが出たら、それは先回りの信号です。
そうでないならば迷わずYAGNIで進めば良いです。

これは先回りすべき?チェックリスト

不可逆度合いでクリティカル、Highで整理しました。
特にクリティカルは、どのプロジェクト / プロダクトでも必ず気にすべき事項です。

不可逆度がクリティカル: 1つでもYesなら「不可逆」として先回り検討

□ コスト要件に関わるか?(予算的に大丈夫?)
□ 法的・コンプライアンス要件に関わるか?(機密情報は保護されている?どこかに蓄積されてない?蓄積されたものは追跡・保護できている?)
□ 既存データの移行が必要になるか?(将来的にデータベースの移行が発生するか?)

コストとセキュリティは言わずもがなですが、私はデータ移行の観点は注意してみるようにしています。
これは過去「CRMのデータ移行プロジェクト」での学びが大きいです。
このプロジェクトで、「互換性がないシステムに、データを失わないように移行すること」は極めて困難だったことを経験しました。

https://qiita.com/kusaaaaagi/items/926f57c6f840e9a8fd9e

https://qiita.com/kusaaaaagi/items/018f979689113a954bbd

不可逆度がHigh: 1つチェックついたら、テックリードやマネージャーと相談

□ 外部組織への依存はあるか?(他チームのヘルプが必要になる?他チームに影響ある?)
□ 外部システムとの調整が必要か?
□ ユーザーに影響するか?
□ 変更に1人月以上かかるか?

重要なのは、チェックを通った部分だけに先回りを限定することです。

アンチパターンの回避

(自戒も込めて)自称プロの正論振りかざしを避ける

  • 「技術的には〜」「ベストプラクティス的には〜」の口癖
  • 不確実性を無視した過剰設計

「正しさ」で殴ると、速度も学習機会も失います。正論は不可逆性チェックで裏づけて初めて有効になります。
全部を固めてはいけません。 柔らかいところは柔らかいままにして速度を確保しましょう。

バランス感覚:

  • 不可逆なものは慎重に先回り
  • 可逆なものは積極的にYAGNI
  • チェックリストで判断、感情で判断しない

この三点をチームの合意事項として明文化すると、議論コストが大きく下がります。

「YAGNIと、予測して先回りする設計って矛盾してませんか?」への答え

「不可逆な意思決定を外してないなら、進めば良いよ。」

下記のようなバランス感覚と言語化できました。

  • アマチュア:「動けばOK」で後で困る
  • 自称プロ:「設計的には〜」「技術的に正しいのは〜」で過剰設計
  • プロ:不可逆性の観点で判断

まとめ

現場では「早く出す」と「長く持たせる」が常に衝突します。だからこそ、不可逆性という軸で意思決定を簡略化できます。
迷ったら小さく出し、不可逆だけは外さない。これに尽きるなと思いました。

Discussion