この記事はLITALICO Engineers Advent Calendar 2025 カレンダー4 の 10日目の記事です
この記事は、「要求をそのまま実装する」のではなく、「ユーザー価値から複数の実現方法を考え、最適解を選ぶ」エンジニアになるための思考法をまとめたものです
はじめに：なぜ「要求通りに作る」だけでは不十分なのか
「検索機能をつけてほしい」
「決済方法を増やしてほしい」
「パフォーマンスを改善してほしい」
こうした要求を受けたとき、あなたはどう考えますか？
- 「分かりました。検索機能を実装します」
- 「どの決済方法を追加すればいいですか？」
- 「具体的にどこを改善しますか？」
実は、さらに一歩進んだアプローチがあります。
それは、要求の背後にある「ユーザーの本質的な価値」を見極めること。そして、複数の実現方法から最適解を選ぶ思考を持つことです。
私自身、長年のエンジニア経験を通じて、「ユーザー価値から最適な実現方法を提案できる」思考法が、エンジニアとしての成長に大きく貢献することを実感してきました。
本記事では、要求からユーザー価値を読み解き、複数の実現方法を発想し、最適解を選ぶための思考法を体系的に解説します。
🎯 この記事で得られること
✅ 要求の背後にあるユーザー価値を見極める思考法
✅ 複数の実現方法を発想する具体的なアプローチ
✅ 最適な実現方法を選ぶための評価フレームワーク
✅ 選択肢を広げるためにエンジニアが日々すべきこと
✅ 実践的な意思決定プロセスとケーススタディ
📖 この記事の読み方
この記事は約30分で読めます。時間や目的に応じて、以下のように読み進めてください。
⏱️ 時間がない方（5分）
- 「問題の本質：要求 ≠ ユーザー価値」
- 「ユーザー価値起点の意思決定：3つのステップ」
- 「まとめ」
🎯 実践したい方（15分）
- 上記に加えて
- 「Step 1-3」の詳細
- 「選択肢を広げるために：エンジニアが日々すべきこと」
📚 深く理解したい方（30分）
- 全体を通して読み、ケーススタディとツールも確認
💭 問題の本質：要求 ≠ ユーザー価値
典型的な失敗例
ケース：検索機能の要求
❌ 表面的な対応：
要求：「検索機能をつけてほしい」
対応：「分かりました。全文検索を実装します」
結果：実装したが、ユーザーはあまり使わなかった
✅ 価値起点の対応：
要求：「検索機能をつけてほしい」
深掘り：「なぜ検索が必要？」→「目的の情報が見つからない」
本質：「ユーザーが素早く目的の情報にたどり着きたい」
実現方法の選択肢：
A. 全文検索機能の実装
B. カテゴリー分類の改善
C. レコメンド機能の強化
D. よくある質問へのショートカット
E. サイト構造の見直し
評価・選択：
→ ユーザー行動分析の結果、8割のユーザーは同じ10記事を探している
→ 最適解：「よくある質問へのショートカット」を目立つ場所に配置
→ 実装コスト: 1/10、ユーザー価値: 検索機能と同等以上
このケースが示すこと：
- 要求をそのまま実装すると、コストをかけて価値の低いものを作ってしまう
- ユーザー価値の本質を見極めれば、より良い解決策が見つかる
- 複数の実現方法を考えることで、最適解にたどり着ける
🎯 ユーザー価値起点の意思決定：3つのステップ
この記事の核となる、実践的な3ステップを紹介します。
| ステップ | やること | 成果物 |
|---|---|---|
| Step 1 | 5つのWhyで深掘り | 本質的なユーザー価値の言語化 |
| Step 2 | 4つのアプローチで発散 | 3つ以上の実現方法の選択肢 |
| Step 3 | 5軸で評価・選択 | 最適解の決定と根拠 |
🔍 Step 1: ユーザー価値の本質を見極める
5つのWhyで深掘りします。
具体例：決済方法の追加要求
要求：「決済方法を増やしてほしい」
Why 1: なぜ決済方法を増やしたいのか？
→ 「決済できないユーザーがいる」
Why 2: なぜ決済できないのか？
→ 「クレジットカードを持っていない」
Why 3: なぜクレジットカードを持っていないのか？
→ 「若年層・学生が多い」
Why 4: なぜ若年層は決済に困っているのか？
→ 「親のカードを借りるのが面倒」
Why 5: 本質的に解決したいことは？
→ 「手軽に、家族に知られず決済したい」
✅ 本質的ユーザー価値：
「プライバシーを保ちつつ、手軽に決済できること」
ユーザー価値を見極める3つの質問
質問1：「この要求がなかったら、ユーザーはどう困るのか？」
→ 具体的な困りごとを明確化
質問2：「なぜ今、この要求が出てきたのか？」
→ タイミング・背景の理解
質問3：「この要求を満たすことで、ユーザーはどう変わるのか？」
→ 期待される行動変化の明確化
💡 Step 2: 複数の実現方法を発想する
なぜ複数の選択肢が重要なのか
選択肢が1つしかないとき：
- その実装方法が本当に最適かわからない
- トレードオフを比較検討できない
- より良い方法を見逃している可能性が高い
選択肢が複数あるとき：
- 比較することで最適解が見える
- リスクや制約に応じて柔軟に選べる
- 段階的な実装戦略も立てられる
実現方法を発散させる4つのアプローチ
アプローチ1: 異なる技術領域から考える
例：「決済できないユーザー」の解決
技術的アプローチ：
- 決済API追加（コンビニ決済、キャリア決済）
- 決済プロセス最適化（ワンクリック決済）
UXアプローチ：
- 決済不安の解消（セキュリティ表示強化）
- 段階的決済（お試し→本決済）
ビジネスアプローチ：
- 後払い・分割払いオプション
- ポイント・クーポンでの決済
運用アプローチ：
- カスタマーサポート強化
- 決済エラー時のフォローメール自動化
アプローチ2: スケールで考える
小規模な解決策：
- 最もシンプルで素早く実装できる方法
- リスクが低く、検証しやすい
中規模な解決策：
- ある程度の投資で、しっかり価値を届ける
- 拡張性も考慮した設計
大規模な解決策：
- 根本的な問題解決、長期的な投資
- システム全体の再設計を含む
例：決済問題
小: 決済代行サービス（Stripe）を統合
中: キャリア決済・コンビニ決済を追加
大: 独自の決済基盤構築、複数通貨・国際展開対応
アプローチ3: 時間軸で考える
即効性重視：
- 今すぐ価値を届けられる方法
- 実装が簡単、既存のツール・サービス活用
中期的投資：
- 3-6ヶ月で効果が出る方法
- カスタム実装、チーム学習を伴う
長期的投資：
- 1年以上かけて基盤を作る方法
- 戦略的な技術選択、組織能力の向上
例：決済問題
即: 外部決済サービス統合
中: 自社で決済フロー最適化
長: 決済プラットフォーム化、他社への提供も視野
アプローチ4: 競合・事例から学ぶ
質問：
- 競合他社はどう解決しているか？
- 他業界の似た課題はどう解決されているか？
- 最新の技術トレンドで使えるものはないか？
例：決済問題
競合A: LINEPay統合で若年層を獲得
競合B: Amazon Pay導入で離脱率低減
他業界: ゲーム業界はキャリア決済が標準
トレンド: Buy Now, Pay Later (BNPL) が急成長
実現方法の発散例
本質的価値：「プライバシーを保ちつつ、手軽に決済できる」
実現方法の選択肢：
Option A: コンビニ決済
Option B: キャリア決済
Option C: プリペイドカード・ギフトカード
Option D: 後払い決済（BNPL）
Option E: ポイント・仮想通貨決済
Option F: 少額なら後払い、与信なし
Option G: 親向けの承認機能付き決済
Option H: 友達間の割り勘・代理決済
→ 8つの選択肢が浮かんだ！
📊 Step 3: 最適な実現方法を選ぶ
意思決定の5つの評価軸
どの実現方法を選ぶか判断する際、以下の5つの軸を意識します。
1️⃣ 技術的価値（Technical Value）
「技術的に正しいか、優れているか」
評価項目：
- パフォーマンス: 処理速度、メモリ効率、スケーラビリティ
- 保守性: 可読性、テスタビリティ、拡張性
- 信頼性: 可用性、耐障害性、セキュリティ
- 技術的負債: 長期的な保守コスト、技術的陳腐化リスク
判断の視点：
✅ この技術は長期的に保守可能か？
✅ パフォーマンス要件を満たせるか？
✅ セキュリティリスクは許容範囲か？
✅ 将来の拡張に対応できるか？
2️⃣ ビジネス価値（Business Value）
「事業成果にどう貢献するか」
評価項目：
- 収益への影響: 売上増加、コスト削減、新規事業機会
- 市場競争力: 差別化、市場投入速度、競合優位性
- リスク軽減: 法令遵守、事業継続性、セキュリティ
- 戦略的整合性: 事業戦略との一致、長期ビジョンとの整合
判断の視点：
✅ この技術選択はビジネス目標達成に貢献するか？
✅ 市場投入速度と技術的堅牢性のバランスは適切か？
✅ ROI（投資対効果）は合理的か？
✅ 事業戦略の変化に柔軟に対応できるか？
3️⃣ ユーザー価値（User Value）
「ユーザー体験をどう改善するか」
評価項目：
- ユーザビリティ: 使いやすさ、学習容易性、エラー回避
- パフォーマンス体験: レスポンス速度、安定性、信頼性
- アクセシビリティ: 誰もが使える設計、多様性への配慮
- 価値提供: ユーザーの課題解決、満足度向上
判断の視点：
✅ ユーザーはこの改善を実感できるか？
✅ ユーザビリティは向上するか？
✅ アクセシビリティは損なわれていないか？
✅ ユーザーの課題解決に本質的に貢献するか？
4️⃣ チーム価値（Team Value）
「チームの生産性と成長にどう影響するか」
評価項目：
- 開発効率: 開発速度、デバッグ容易性、リリースサイクル
- 学習コスト: チームメンバーの習得容易性、既存スキルとの整合
- コラボレーション: コードレビュー容易性、知識共有、属人化防止
- 成長機会: 技術スキル向上、キャリア成長、モチベーション
判断の視点：
✅ チームメンバーが無理なく習得できるか？
✅ 開発効率は向上するか？
✅ 属人化リスクは増加しないか？
✅ チームの技術的成長に貢献するか？
5️⃣ リソース制約（Resource Constraints）
「現実的に実現可能か」
評価項目：
- 時間: 開発期間、市場投入タイミング、緊急度
- 人的リソース: チーム規模、スキルセット、稼働状況
- 予算: 開発コスト、ライセンス費用、インフラコスト
- 技術的制約: 既存システムとの互換性、技術的依存関係
判断の視点：
✅ 現実的なスケジュールで完遂できるか？
✅ チームのスキルセットで対応可能か？
✅ 予算制約内で実現できるか？
✅ 既存システムとの整合性は保てるか？
🔄 5軸のバランスを取る：トレードオフマトリクス
現実には、すべての軸で最高の選択をすることは不可能です。トレードオフを明示化し、意識的にバランスを取ることが重要です。
トレードオフの可視化
技術選択の例：新フレームワークの導入
技術的価値: ⭐⭐⭐⭐⭐ (最新技術、優れたパフォーマンス)
ビジネス価値: ⭐⭐⭐☆☆ (中長期的な効率化)
ユーザー価値: ⭐⭐⭐⭐☆ (レスポンス改善)
チーム価値: ⭐⭐☆☆☆ (学習コスト大)
リソース制約: ⭐⭐☆☆☆ (移行に3ヶ月必要)
総合判断：
→ 学習コストとリソース制約が大きい
→ まずは小規模なプロジェクトで試験導入
→ チーム学習と並行して段階的に移行
状況別の優先順位
🚀 スタートアップ・新規事業フェーズ
優先順位：
1. ビジネス価値（市場投入速度）
2. ユーザー価値（PMF達成）
3. リソース制約（最小限のリソース）
4. チーム価値（少数精鋭で回す）
5. 技術的価値（短期的に妥協も可）
判断基準：
「とにかく速く市場投入して検証」
→ 技術的負債はある程度許容
→ ただし致命的なセキュリティリスクは回避
🏢 成熟プロダクト・エンタープライズフェーズ
優先順位：
1. 技術的価値（安定性・保守性）
2. ユーザー価値（信頼性・品質）
3. ビジネス価値（継続的収益）
4. チーム価値（持続可能な開発）
5. リソース制約（十分な時間とリソース）
判断基準：
「長期的に安定して価値を提供」
→ 技術的負債の計画的解消
→ 品質とセキュリティを最優先
🔧 技術負債返済フェーズ
優先順位：
1. 技術的価値（保守性・拡張性向上）
2. チーム価値（開発効率改善）
3. リソース制約（計画的投資）
4. ビジネス価値（中長期的効率化）
5. ユーザー価値（直接的影響は限定的）
判断基準：
「将来への投資として技術基盤を強化」
→ ユーザー向け機能開発を一時的に抑制
→ チーム全体で計画的にリファクタリング
💡 実践的な判断パターン
実際の開発現場でよく遭遇する状況に応じた、判断パターンを紹介します。
実現方法選定の判断パターン
パターン1: シンプル優先（Simple First）
状況：
- 不確実性が高い
- リソースが限られている
- 市場検証が必要
判断：
最もシンプルな実装で仮説検証
→ 学習してから次の一手を考える
例：
「とりあえず外部決済サービス（Stripe/PayPal）を統合」
→ 決済ニーズを検証してから独自実装を検討
パターン2: 拡張性優先（Extensible First）
状況：
- 将来の要求が予測できる
- 長期的な投資として考える
- 段階的な機能追加が予定されている
判断：
最初から拡張可能なアーキテクチャ
→ 将来の変更コストを最小化
例：
「決済プロバイダーを抽象化したアーキテクチャ」
→ 将来的に複数の決済方法を容易に追加可能
パターン3: 差別化優先（Differentiation First）
状況：
- 競合が激しい市場
- 独自性が競争優位につながる
- ブランド価値が重要
判断：
競合がやっていないアプローチ
→ ユーザー体験での差別化
例：
「ワンクリック決済＋サブスクリプション最適化」
→ 使い勝手で圧倒的な差をつける
パターン4: リスク最小化優先（Risk-Averse First）
状況：
- 規制が厳しい領域
- セキュリティが最重要
- 失敗が許されない
判断：
実績のある成熟した技術を選択
→ 安定性・信頼性を最優先
例：
「大手決済代行サービスを利用」
→ PCI DSS準拠、セキュリティは専門家に任せる
⚠️ よくある落とし穴と対処法
実装判断でよく陥りがちな思考パターンと、その対処法を紹介します。
落とし穴1: 技術ドリブン（Technology Driven）
❌ 陥りがちな思考：
「最新技術の○○を使いたいから、これで実装しよう」
✅ 望ましい思考：
「ユーザー価値を最も満たす方法を選び、その結果○○が最適だった」
💡 対処法：
技術選択の前に必ず「なぜこの技術が最適か？」を5軸で評価する
落とし穴2: 慣れドリブン（Familiarity Driven）
❌ 陥りがちな思考：
「自分が使い慣れた技術・方法で実装しよう」
✅ 望ましい思考：
「目的に最適な方法を選び、必要なら学習する」
💡 対処法：
チームで複数の選択肢を出し合い、慣れ以外の視点も取り入れる
落とし穴3: 完璧主義（Perfectionism）
❌ 陥りがちな思考：
「すべての要件を満たす完璧な実装を最初から目指す」
✅ 望ましい思考：
「最小限の実装で価値を届け、フィードバックで改善」
💡 対処法：
MVP（Minimum Viable Product）思考で、まず最小構成で検証する
落とし穴4: 過度な汎用化（Over-Engineering）
❌ 陥りがちな思考：
「将来あらゆる要求に対応できる汎用的な仕組みを作る」
✅ 望ましい思考：
「今必要な価値を提供し、拡張が必要になったら対応」
💡 対処法：
YAGNI原則（You Aren't Gonna Need It）を意識する
🌱 選択肢を広げるために：エンジニアが日々すべきこと
なぜ「引き出しの多さ」が重要なのか
学習初期の段階：
- 知っている技術・方法を中心に考える
- 選択肢が1-2個から始まる
- 「まずはこの方法で」という思考
経験を重ねた段階：
- 多様な技術・方法を組み合わせられる
- 選択肢を5-10個考えられる
- 「こういう方法もある」という発想
引き出しを増やすことで：
✅ より良い解決策にたどり着ける
✅ 状況に応じて最適な方法を選べる
✅ 技術的な会話の幅が広がる
✅ エンジニアとしての市場価値が上がる
日々の学習：4つの実践方法
1️⃣ 技術の幅を広げる
横展開の学習：
現在のスキルセット: フロントエンド（React）
横展開の例：
□ バックエンド: Node.js, Python, Goを触ってみる
□ インフラ: AWS, Docker, Kubernetesを学ぶ
□ データ: SQLだけでなくNoSQL, データパイプラインも
□ モバイル: React Nativeで既存スキルを活かす
目的：
異なる領域の視点を持つことで、実現方法の選択肢が増える
深掘りの学習：
現在のスキルセット: Webアプリケーション開発
深掘りの例：
□ パフォーマンス最適化の深い知識
□ セキュリティ対策の専門性
□ アクセシビリティのベストプラクティス
□ 大規模システムのアーキテクチャ設計
目的：
専門性を深めることで、質の高い実装判断ができる
2️⃣ 他者の解決策から学ぶ
オープンソースコードを読む：
週1回、30分だけ：
□ GitHubでトレンドのリポジトリをチェック
□ 気になる機能の実装を読んでみる
□ 「なぜこの実装方法を選んだのか」を考える
学べること：
- 自分では思いつかない実装パターン
- 問題解決のアプローチの多様性
- 品質基準・コーディングスタイル
例：
決済機能を実装する前に、Stripeのオープンソースライブラリを読む
→ エラーハンドリング、リトライロジックの実装パターンを学ぶ
技術ブログ・カンファレンストークを見る：
月1-2本、興味のあるテーマ：
□ 他社の技術的挑戦事例
□ 「なぜその技術を選んだか」の判断基準
□ 失敗事例とそこからの学び
学べること：
- 意思決定のプロセス
- トレードオフの考え方
- 実際のビジネス成果
例：
「メルカリのマイクロサービス化」の記事を読む
→ モノリスからの段階的移行戦略、組織の変化も学ぶ
3️⃣ 異なる職種の視点を学ぶ
デザイナーの視点：
実践方法：
□ デザイナーとペアで作業する機会を作る
□ ユーザビリティテストに同席する
□ デザインシステムのドキュメントを読む
学べること：
- ユーザー体験の細かい配慮
- 認知負荷、視覚階層の考え方
- アクセシビリティの実践知
活かし方：
実装方法を考える際、UXへの影響も評価できるようになる
PdM・ビジネス側の視点：
実践方法：
□ プロダクトロードマップの背景を理解する
□ ユーザーインタビュー結果を読む
□ ビジネス指標（KPI）の意味を学ぶ
学べること：
- なぜその機能が優先されるのか
- ユーザーセグメント別の価値の違い
- ROI、市場競争の視点
活かし方：
技術選択がビジネス成果にどう影響するか説明できるようになる
QA・カスタマーサポートの視点：
実践方法：
□ バグレポートの傾向を定期的に確認
□ カスタマーサポートの問い合わせ内容を読む
□ ユーザーの実際の使い方を観察
学べること：
- ユーザーが実際につまずくポイント
- テストで見落としがちな観点
- 運用負荷の高い機能の特徴
活かし方：
実装時に運用・保守のしやすさも考慮できるようになる
4️⃣ 失敗から学ぶ文化を作る
自分の判断を振り返る：
月次の振り返り：
□ 今月の重要な技術判断を3つ挙げる
□ 「別の方法もあったのでは？」と自問する
□ 実際の結果と予想のギャップを分析
記録する内容：
- どんな選択肢を考えたか
- なぜその方法を選んだか
- 結果はどうだったか
- 次はどう改善するか
効果：
同じ失敗を繰り返さない、判断の質が向上する
チームで失敗を共有する：
定期的な学習会：
□ 「うまくいかなかった実装」の共有会
□ 「もっと良い方法があった」事例の発表
□ ポストモーテム（事後分析）の実施
ルール：
- 個人を責めない、仕組みを改善する
- 「なぜ」を5回繰り返す
- 学びを次に活かすアクションを決める
効果：
チーム全体の引き出しが増える、心理的安全性も向上
実践：90日間の引き出し増強プラン
Week 1-4: 技術の幅を広げる
□ 週1回、普段使わない技術のチュートリアルをやる
□ 週1回、GitHubのトレンドリポジトリを読む
□ 月1回、技術カンファレンストークを見る
Week 5-8: 他職種の視点を学ぶ
□ 週1回、デザイナー・PdMとランチしながら話を聞く
□ 週1回、カスタマーサポートの問い合わせログを読む
□ 月1回、ユーザーインタビュー・ユーザビリティテストに同席
Week 9-12: 学びを実践に活かす
□ 週1回、今週の技術判断を振り返り記録
□ 週1回、「別のアプローチもあるのでは？」と考える習慣
□ 月1回、チームで「もっと良い方法」を議論する場を作る
継続のコツ：
- 完璧を目指さない、小さな習慣から
- 興味のあるテーマから始める
- チームメンバーと一緒に取り組む
- 学んだことをアウトプット（ブログ、LT）する
🛠️ 実践：意思決定プロセス
Step 1: 問題の明確化
まず、何を決めようとしているのかを明確にします。
問いかけ：
❓ 解決したい課題は何か？
❓ なぜ今この判断が必要なのか？
❓ 判断を先送りした場合のリスクは？
❓ この判断の影響範囲はどこまでか？
例：技術スタック選定
課題：
既存のモノリシックシステムが肥大化し、
新機能追加に時間がかかりすぎている
判断が必要な理由：
事業成長に開発速度が追いつかなくなっている
先送りのリスク：
競合に市場シェアを奪われる
エンジニアの離職リスク増大
影響範囲：
開発チーム全体（10名）
今後3年間のシステム開発
Step 2: 選択肢の洗い出し
少なくとも3つ以上の選択肢を検討します。
選択肢の例：
Option A: マイクロサービス化
Option B: モジュラーモノリス
Option C: 現行システムのリファクタリング
Option D: 段階的移行（ストラングラーパターン）
Step 3: 5軸での評価
各選択肢を5つの軸で評価します。
評価マトリクス例：
| 選択肢 | 技術的価値 | ビジネス価値 | ユーザー価値 | チーム価値 | リソース制約 | 総合 |
|---|---|---|---|---|---|---|
| Option A | ⭐⭐⭐⭐⭐ | ⭐⭐⭐☆☆ | ⭐⭐⭐⭐☆ | ⭐⭐☆☆☆ | ⭐☆☆☆☆ | 13/25 |
| Option B | ⭐⭐⭐⭐☆ | ⭐⭐⭐⭐☆ | ⭐⭐⭐⭐☆ | ⭐⭐⭐☆☆ | ⭐⭐⭐☆☆ | 18/25 |
| Option C | ⭐⭐☆☆☆ | ⭐⭐☆☆☆ | ⭐⭐☆☆☆ | ⭐⭐⭐⭐☆ | ⭐⭐⭐⭐☆ | 13/25 |
| Option D | ⭐⭐⭐⭐☆ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐☆☆ | ⭐⭐⭐⭐☆ | ⭐⭐⭐☆☆ | 19/25 |
詳細評価の記述：
Option D: 段階的移行（ストラングラーパターン）
技術的価値 ⭐⭐⭐⭐☆
+ 最終的にマイクロサービスの利点を享受
+ リスクを分散しながら移行可能
- 移行期間中は複雑性が増す
ビジネス価値 ⭐⭐⭐⭐⭐
+ 継続的に新機能をリリース可能
+ ビジネスへの影響を最小化
+ 段階的投資で予算確保しやすい
ユーザー価値 ⭐⭐⭐☆☆
+ サービス断絶なく移行
- 移行期間中の一時的なパフォーマンス影響あり
チーム価値 ⭐⭐⭐⭐☆
+ 段階的に学習できる
+ 既存システムの知識を活かせる
- 移行期間中は2つのシステムのメンテナンス
リソース制約 ⭐⭐⭐☆☆
+ 全面刷新より現実的
- 1年以上の長期プロジェクト
Step 4: リスク分析
各選択肢のリスクとその対策を検討します。
リスクマトリクス：
Option D のリスク：
高リスク：
❌ 移行期間が長引く
対策：マイルストーンを明確化、月次で進捗評価
中リスク：
⚠️ 移行期間中の技術的複雑性
対策：十分なドキュメント整備、ペアプログラミング
⚠️ チームのスキル不足
対策：外部専門家によるコーチング、段階的な学習機会
低リスク：
✅ ユーザーへの影響
対策：十分なテストとカナリアリリース
Step 5: 判断基準の設定
「どうなったら成功か」 を明確にします。
成功基準の例：
定量的基準：
✅ 新機能の開発期間が平均50%短縮（3ヶ月 → 1.5ヶ月）
✅ システム障害による停止時間を月間1時間以内に抑制
✅ 開発チームの満足度調査で平均4.0以上（5点満点）
定性的基準：
✅ ビジネス部門から「開発速度が上がった」との評価
✅ エンジニアが技術的に挑戦的な環境と感じている
✅ 新メンバーのオンボーディングが円滑
検証タイミング：
□ 3ヶ月後：第1フェーズ完了、初期評価
□ 6ヶ月後：中間評価、方針調整の判断
□ 12ヶ月後：最終評価、次フェーズへの移行判断
Step 6: 決定と実行計画
最終判断を下し、具体的なアクションプランに落とし込みます。
決定の文書化：
決定事項：
Option D（段階的移行／ストラングラーパターン）を採用
決定の理由：
- ビジネス価値とチーム価値のバランスが最良
- リスクを管理しながら目標達成可能
- 経営陣の予算承認が得られやすい
実行計画：
Phase 1（3ヶ月）：
- 認証・認可機能をマイクロサービス化
- チームトレーニング・ツール整備
Phase 2（6ヶ月）：
- コア機能を順次分離
- 監視・デプロイ基盤の構築
Phase 3（12ヶ月）：
- レガシー部分の完全置き換え
- 技術的負債の解消
振り返りポイント：
- 月次で進捗とリスクをレビュー
- 四半期ごとに成功基準を再評価
- 問題発生時は即座にエスカレーション
🎓 経験に応じた：意思決定の軸の使い分け
エンジニアの経験に応じて、意思決定の範囲と重視する軸が変わります。
🌱 キャリア初期（1-3年目）
意思決定の範囲：
- コードレベルの実装判断
- 設計パターンの選択
- タスクの進め方
重視すべき軸：
1. 技術的価値（基本に忠実、保守性重視）
2. チーム価値（レビューしやすいコード）
3. リソース制約（期限内に完遂）
判断の例：
❓「この処理をどう実装するか？」
評価：
- コードの可読性は高いか？
- テストは書きやすいか？
- チームの既存コードと一貫性があるか？
- 予定工数内で完成するか？
→ まずは基本に忠実、過度な最適化より保守性
🌿 キャリア中期（3-7年目）
意思決定の範囲：
- 機能設計・アーキテクチャ設計
- 技術選定の提案
- チーム内の技術的リーダーシップ
重視すべき軸：
1. 技術的価値（拡張性・保守性）
2. ユーザー価値（UX・パフォーマンス）
3. ビジネス価値（開発効率・ROI）
4. チーム価値（知識共有・成長支援）
判断の例：
❓「このAPIをどう設計するか？」
評価：
- 将来の拡張に対応できるか？
- ユーザーのユースケースを満たすか？
- 開発・運用コストは妥当か？
- チームメンバーが理解・保守できるか？
→ バランス重視、トレードオフを明示的に管理
🌳 キャリア後期（7年目以上）
意思決定の範囲：
- システムアーキテクチャ全体
- 技術戦略・ロードマップ
- 組織横断の技術判断
重視すべき軸：
全軸をバランスよく、状況に応じて優先順位を動的に調整
1. ビジネス価値（事業成長への貢献）
2. 技術的価値（長期的な技術基盤）
3. ユーザー価値（顧客満足・競争力）
4. チーム価値（組織能力の向上）
5. リソース制約（現実的な実行可能性）
判断の例：
❓「今後3年の技術戦略をどう描くか？」
評価：
- 事業戦略との整合性は？
- 競合との技術的差別化は？
- 技術的負債と新規投資のバランスは？
- 組織のスキル成長と採用戦略は？
- 予算とリソースの現実性は？
→ 戦略的視点、長期的影響を多面的に評価
🧪 ケーススタディ：実際の意思決定
ケース1：テスト戦略の見直し
背景：
現状：E2Eテストに時間がかかり、デプロイが遅い
提案：E2Eを削減し、ユニットテスト・統合テストを充実
反対意見：「E2Eがないと不安」
5軸での評価：
技術的価値：⭐⭐⭐⭐☆
+ テストの高速化、CI/CDの改善
+ テストピラミッドのベストプラクティスに準拠
- E2E削減による一部カバレッジ低下
ビジネス価値：⭐⭐⭐⭐⭐
+ デプロイ頻度の向上（週1回 → 毎日）
+ 市場投入速度の改善
+ 開発者の生産性向上
ユーザー価値：⭐⭐⭐☆☆
+ より頻繁な機能改善
- 初期はバグ混入リスク若干増
チーム価値：⭐⭐⭐⭐☆
+ フィードバックループの高速化
+ 開発体験の向上
- テスト戦略変更の学習コスト
リソース制約：⭐⭐⭐⭐☆
+ テスト実行時間の大幅削減
+ CI/CDコストの削減
- 移行期間は両方のメンテナンスが必要
判断：
決定：段階的にテスト戦略を移行
実行計画：
1. クリティカルなユーザーフローのみE2E維持
2. 新規機能は新テスト戦略で開発
3. 既存機能は優先度をつけて段階的に移行
4. 3ヶ月後に効果測定とリスク評価
リスク対策：
- カナリアリリースで段階的に本番展開
- バグ発生時の即座のロールバック体制
- 監視強化（エラー率、パフォーマンス）
ケース2：技術負債 vs 新機能開発
背景：
状況：レガシーコードが肥大化、保守が困難
要望：ビジネス側は新機能を急いでいる
技術側：リファクタリングしないと破綻する
5軸での評価（2つの選択肢）：
Option A：新機能を優先
技術的価値：⭐⭐☆☆☆ 技術負債がさらに蓄積
ビジネス価値：⭐⭐⭐⭐⭐ 短期的な売上機会を逃さない
ユーザー価値：⭐⭐⭐⭐☆ 要望機能が早く届く
チーム価値：⭐⭐☆☆☆ モチベーション低下リスク
リソース制約：⭐⭐⭐☆☆ 短期的には効率的
Option B：リファクタリングを優先
技術的価値：⭐⭐⭐⭐⭐ 長期的な保守性向上
ビジネス価値：⭐⭐☆☆☆ 短期的な機会損失
ユーザー価値：⭐⭐☆☆☆ 直接的な価値提供なし
チーム価値：⭐⭐⭐⭐☆ 開発環境の改善
リソース制約：⭐⭐☆☆☆ 長期的投資が必要
判断：
決定：ハイブリッドアプローチ
実行計画：
- 開発リソースの70%を新機能、30%をリファクタリングに配分
- 新機能開発と並行して、影響範囲の限定的なリファクタリングを実施
- 「ボーイスカウトルール」：触った場所は必ず改善して帰る
説得材料（ビジネス側向け）：
「技術負債を放置すると、6ヶ月後には開発速度が半減します。
今、週1日をリファクタリングに充てることで、3ヶ月後には
開発速度が30%向上し、結果的にビジネス目標を早く達成できます。」
定量的根拠：
- 現状の開発速度：機能1つあたり2週間
- 3ヶ月後の予測（リファクタなし）：機能1つあたり3週間
- 3ヶ月後の予測（リファクタあり）：機能1つあたり1.5週間
📚 意思決定を支えるツールとプラクティス
1. ADR（Architecture Decision Record）
重要な技術判断を文書化して、後から振り返りや検証ができるようにします。
ADRテンプレート：
# ADR-001: [決定のタイトル]
## ステータス
[提案中 / 承認済み / 非推奨 / 置き換え済み]
## 文脈（Context）
なぜこの決定が必要だったのか
## 決定（Decision）
何を決定したのか
## 根拠（Rationale）
なぜこの決定をしたのか（5軸での評価）
## 影響（Consequences）
この決定がもたらす影響（ポジティブ・ネガティブ両方）
## 代替案（Alternatives）
検討したが採用しなかった選択肢とその理由
2. Tech Radar
技術スタックの評価と方向性を可視化します。
採用（Adopt）：積極的に使用を推奨
├─ TypeScript
├─ React
└─ PostgreSQL
試用（Trial）：小規模プロジェクトで試験中
├─ GraphQL
└─ Kubernetes
評価（Assess）：情報収集・検証中
├─ Rust
└─ WebAssembly
保留（Hold）：新規採用を推奨しない
├─ jQuery
└─ AngularJS
3. Decision Matrix（決定マトリクス）
複数の選択肢を定量的に比較します。
重み付け：
技術的価値：30%
ビジネス価値：25%
ユーザー価値：20%
チーム価値：15%
リソース制約：10%
Option A スコア：
(5×0.30) + (3×0.25) + (4×0.20) + (2×0.15) + (1×0.10) = 3.35
Option B スコア：
(4×0.30) + (4×0.25) + (4×0.20) + (3×0.15) + (3×0.10) = 3.75
→ Option B を選択
4. Pre-mortem（事前検死）
プロジェクト開始前に「失敗した未来」を想像し、リスクを洗い出します。
シナリオ：
「6ヶ月後、このプロジェクトは失敗に終わった」
失敗の原因を列挙：
- 技術的複雑性を過小評価していた
- チームのスキル不足に対処できなかった
- ビジネス側の要求が頻繁に変わった
- 既存システムとの統合が想定以上に困難だった
対策：
各リスクに対する予防策と対処策を事前に準備
🎯 意思決定の精度を上げる習慣
日次の振り返り
今日の意思決定を記録：
□ どんな判断をしたか？
□ どの軸を重視したか？
□ 結果はどうだったか？
□ 次回はどう改善するか？
週次のレビュー
今週の重要な判断を振り返り：
□ 判断基準は適切だったか？
□ 予期しない結果はあったか？
□ トレードオフの判断は正しかったか？
□ チームからのフィードバックは？
月次の戦略確認
判断軸の見直し：
□ 事業環境の変化はあったか？
□ チーム状況は変わったか？
□ 技術トレンドの変化は？
□ 優先順位の調整が必要か？
四半期の深い振り返り
判断フレームワークの改善：
□ 過去の判断の成功率は？
□ 繰り返し発生した問題は？
□ 判断軸の追加・修正が必要か？
□ チーム全体で学びを共有
📖 まとめ：「要求を実装する人」から「価値を創造する人」へ
この記事の核心メッセージ
エンジニアとして、さらに成長するために大切なこと
それは、「要求をそのまま実装する」だけでなく、「ユーザー価値から複数の実現方法を考え、最適解を選ぶ」 思考を持つことです。
3つのステップ
Step 1: ユーザー価値の本質を見極める
- 要求の背後にある「なぜ」を5回問う
- ユーザーの本質的な困りごとを理解する
- 要求 ≠ ユーザー価値 を意識する
Step 2: 複数の実現方法を発想する
- 異なる技術領域から考える
- スケールと時間軸で考える
- 競合・事例から学ぶ
- 少なくとも3つ以上の選択肢を出す
Step 3: 最適な実現方法を選ぶ
- 5つの評価軸で判断する
- 技術的価値、ビジネス価値、ユーザー価値、チーム価値、リソース制約
- トレードオフを明示化する
- 段階的実装戦略を立てる
選択肢を広げるために日々すべきこと
1. 技術の幅を広げる
- 横展開の学習（異なる領域）
- 深掘りの学習（専門性）
2. 他者の解決策から学ぶ
- オープンソースコードを読む
- 技術ブログ・カンファレンストークを見る
3. 異なる職種の視点を学ぶ
- デザイナー、PdM、QAの視点を理解する
4. 失敗から学ぶ文化を作る
- 自分の判断を振り返る
- チームで失敗を共有する
今日から始められること
最初の一歩：
□ 今日受けた要求を1つ選び、「なぜ」を3回問うてみる
□ その要求に対して、3つの異なる実現方法を考えてみる
□ それぞれのメリット・デメリットを書き出してみる
継続的な習慣：
□ 毎週金曜日、今週の技術判断を1つ振り返る
□ 月1回、普段触らない技術のチュートリアルをやる
□ 四半期に1回、自分の「引き出し」がどれだけ増えたか確認する
最後に
「要求を実装する」ことは大切な第一歩です。
そこから、「ユーザー価値から最適な実現方法を提案できる」思考を身につけることで、さらに大きな価値を生み出せるようになります。
この記事で紹介した思考法は、少しずつ身につけていくものです。焦らず、意識して実践を続けることで、確実にあなたのエンジニアとしての成長につながります。
「この要求、本当にこの方法で良いのだろうか？」
そう自問する習慣が、あなたを次のレベルに引き上げます。
あなたは要求を受けたとき、どんな思考プロセスを経ていますか？「こんな方法で選択肢を広げている」という工夫があれば、ぜひコメントで教えてください！