― 判断を前に進めるための思考整理テンプレ ―
はじめに
設計で迷う時間は、エンジニアなら誰でも経験します。
そして厄介なのは、「迷っている理由が自分でも分からなくなる瞬間」です。
この記事では、
- 設計で迷ったときに自分に問いかける質問
- その質問を実務で使える形に落としたチェックリスト
- 設計レビューで使えるテンプレート
- 迷いを深める「悪い問い」と、判断を前に進める「良い問い」の比較
までをまとめます。
答えを与える記事ではなく、
判断できる状態に戻るための記事を目指しています。
背景・前提条件
- Webアプリケーション開発（業務システム想定）
- 小〜中規模チーム
- 要件は大枠決まっているが、設計の裁量がある状態
「正解を当てる設計」ではなく、
説明できる判断を積み重ねる設計を前提にしています。
なぜ設計で迷うのか
設計で迷うとき、多くの場合は次の状態に陥っています。
- 問題と解決策が混ざっている
- 未来の不安が膨らみすぎている
- 判断基準が言語化されていない
この状態では、どんなに調べても前に進みません。
だからこそ、問いを立て直す必要があります。
設計で迷ったら問いかける5つの質問
① これは「今」解くべき問題か？
将来の拡張や不安を、
今の設計で解こうとしていないかを確認します。
- 今の要件で本当に必要か？
- 実際に困ってから修正できないか？
- 困るとしても、それは致命的か？
多くの設計は「未来への不安」で重くなります。
② それを選ばないと、具体的に何が困るか？
「困りそう」では判断できません。
- 誰が困るのか？
- いつ困るのか？
- どの程度困るのか？
ここが言語化できない選択肢は、
優先度が低い可能性が高いです。
③ この設計を、他人に説明できるか？
設計はコードよりも先に「説明責任」が来ます。
- 半年後の自分が理解できるか？
- チームメンバーに口頭で説明できるか？
- READMEや設計書に書けるか？
説明できない設計は、
たいてい「自分も理解しきれていない」状態です。
④ 変更が入ったら、どこが壊れるか？
要件変更は避けられません。
- 影響範囲は限定できているか？
- 修正箇所は予測できるか？
- 全体に波及しない設計になっているか？
「変更に強い」とは、
変更箇所を把握できていることです。
⑤ 今回の設計で、何を捨てているか？
設計は常にトレードオフです。
- 拡張性を捨てて、実装速度を取っていないか？
- 汎用性を捨てて、理解しやすさを取っていないか？
捨てたものを自覚していれば、
後で後悔しても「判断ミス」にはなりません。
設計判断チェックリスト（実務用）
迷ったときは、以下を上から順に確認します。
- [ ] 今の要件で本当に必要か？
- [ ] 解かないと致命的な問題か？
- [ ] 選ばなかった場合の具体的な影響を説明できるか？
- [ ] 他人に5分で説明できるか？
- [ ] 変更が入ったときの影響範囲を把握できているか？
- [ ] 今回あえて捨てている要素を把握しているか？
すべてYESでなくても構いません。
YES / NO を言語化できることが目的です。
設計レビュー用テンプレート
レビュー時は、実装よりも「判断理由」を共有します。
設計意図
- 解こうとしている問題：
- 今回は解かない問題：
選択肢
- 採用案：
- 検討したが採用しなかった案：
判断理由
- 採用理由：
- 採用しなかった理由：
トレードオフ
- 得られるもの：
- 捨てているもの：
将来変更時の想定
- 変更が入った場合の影響範囲：
- 修正方針の目安：
この形で話せる設計は、
レビューでも炎上しにくいです。
「悪い問い」と「良い問い」の比較
悪い問い（迷いを深める）
- この設計って正解ですか？
- ベストプラクティスは何ですか？
- 将来拡張できなくなりませんか？
これらは答えが曖昧で、
判断を先延ばしにします。
良い問い（判断を前に進める）
- 今回の要件で困る人は誰か？
- 変更が入るとしたら、どこが壊れるか？
- 今回は何を割り切っているか？
問いが具体的になると、
自然と判断基準も明確になります。
実務での注意点・落とし穴
- 問いを立てずに実装に入る
- 「将来のため」を理由に複雑化する
- 判断理由を残さない
設計で大事なのは、
正解かどうかより、説明できるかどうかです。
まとめ
設計で迷ったときに必要なのは、
知識や経験よりも「問いの立て方」です。
- 問題を今解くべきか
- 何を捨てているか
- なぜその判断なのか
これを言語化できれば、
その設計は十分に実務で耐えられます。
迷ったら、答えを探す前に、
まず自分に問いかけてみてください。