- はじめに
- 1. 意見の違いは、前提の違いから生まれる
- 2. さらに一つ前の前提を見る
- 3. 何を重要視しているかを確認する
- 4. 前提が一致しない場合どうするべきか
- 5. 良い技術者は正解を知っている人ではない
- まとめ
過去のブログで、良い判断をするためには、良い前提が必要であるという主張をしました。
例えば以下の記事です。
多くの場合、前提を明確にすればうまくいくと感じています。
しかし、場合によってはうまくいかないこともありました。
今回は、 前提 について深堀していき、
前提を明確にしてもうまくいかない場合に、どうしたらよいのかを考えた内容を共有します。
はじめに
アプリ開発では、日々多くの技術的な判断を行います。
- どのアーキテクチャを採用するか
- どこに責務を配置するか
- 新しいライブラリを導入するか
- 技術的負債を返済するか
これらの判断には、多くの場合「唯一の正解」はありません。
同じ技術者でも、状況によって異なる判断をすることがあります。
では、良い技術的判断とは何でしょうか。
この記事では、技術的な意思決定を行う上で重要な「前提」という考え方について整理します。
1. 意見の違いは、前提の違いから生まれる
例：
「APIレスポンスの加工処理をどこに書くべきか」
という議論。
Aさん：
ViewModelで十分ではないか
Bさん：
UseCaseに分離すべきではないか
表面的には、
「ViewModel派」 「UseCase派」
の対立に見える。
しかし、本質的には、
「どのような未来を想定しているか」
が違います。
Aさん：
- この機能は小さい
- 今後変更されない
- シンプルさを優先したい
Bさん：
- 今後拡張される可能性がある
- 複数画面で利用する可能性がある
- テスト容易性を重視したい
つまり、意見ではなく、その背景にある前提を見る必要があります。
2. さらに一つ前の前提を見る
前提は深掘りできます。つまり、さらに一つ前の前提が存在します。
例えば、
「UseCaseに分離するべき」
という判断の裏には、
「保守性を高めたい」
という前提があります。しかし、さらに上を見ると、
- このプロダクトは長期運用されるのか
- リリース時期は固定なのか
- 開発リソースは十分なのか
- 今回変更できる範囲はどこまでなのか
という、さらに上位の前提が存在します。例えば、
- 1週間後にリリース予定
- リリース延期はできない
- 対応できるエンジニアが2人しかいない
という状況なら、
「理想的な設計に変更する」
よりも、
「今回は既存構造を維持してリリースを優先する」
という判断になる可能性があります。つまり、
正しい設計を選択すること
ではなく、
状況に対して最適な判断をすること
が技術的判断と言えるでしょう。
3. 何を重要視しているかを確認する
技術的な議論では、相手の結論を見るだけでは不十分です。確認すべきなのは、
- 何を重要視しているのか
- 何を守ろうとしているのか
- 何をリスクとして見ているのか
ということです。例えば、
「シンプルなコードにしたい」
という意見の背景には、
- チームメンバーが理解しやすい状態を維持したい
- 不必要な抽象化を避けたい
という意図があるかもしれない。
「責務分離したい」
という意見の背景には、
- 変更に強い構造にしたい
- テストしやすくしたい
という意図があるかもしれない。
結論だけを見ると対立しているが、目的を見ると共通点が見つかることがあります。
4. 前提が一致しない場合どうするべきか
私は「前提が一致しないこと自体は悪ではない」と考えています。
ただし、プロダクト開発では、人間関係のように「別々の道を選ぶ」というわけにはいきません。
チームとして一つの判断をする必要があります。そのためには、
4-1. 価値観の違いを認識する
例：
- 品質を優先したい
- スピードを優先したい
これは正解不正解ではなく、何を重要視するかの違いです。
4-2. 制約によって変更できない場合を理解する
例：
「今すぐリファクタリングしたほうが良い」
しかし、
- 会社としてリファクタリングの優先度が低い
- 大規模変更になる
- 対応できる人員がいない
という場合もあります。この場合は、
「改善すべきではない」
ではなく、
「改善したほうが良いが、現在はそのコストを払えない」
という判断になるでしょう。その場合は、
- 技術的負債として記録する
- 将来的な改善タイミングを決める
などの意思決定を行うことになるでしょう。
5. 良い技術者は正解を知っている人ではない
シニアエンジニアやテックリードなど、経験を積んだエンジニアは、
「この状況では何を優先すべきか」
を考えているはずです。
技術的判断とは、知識量だけではなく、
- 前提を整理する力
- 制約を理解する力
- トレードオフを判断する力
- チームで合意形成する力
によって決まると考えています。
まとめ
私は 技術的な議論で重要なのは、結論を合わせることではない と考えています。
まず、
- なぜその判断をしたのか
- どんな前提があるのか
- 何を重要視しているのか
- どんな制約があるのか
を理解することから始めるべきでしょう。
そして、その前提を共有した上で、プロダクトにとって最適な判断を行う。
私は、技術的判断とは正解を選ぶことではなく、
限られた条件の中で、最適な選択をすることである。
と考えています。