独学エンジニアが陥りがちな要求定義の罠と「なぜ」思考フレームワーク
- この記事は、勉強会で学んだフレームワークを個人開発や実務（このケースは新人研修）で実践した経験をまとめたものです。
- 「なぜ思考フレームワーク」は造語です。
初学者エンジニアあるある：機能ベースで考えてしまう
新人研修では、こんな状況によく遭遇します：
「ToDoアプリを作ろうと思います」
「いいですね！どんな課題を解決するアプリですか？」
「...えーと、ToDoを管理する...アプリです」
「具体的には、誰のどんな困りごとを？」
「...🤔」
これ、決して技術力不足の問題じゃないんです。むしろ実装力は高い方が多い。
ただ、学習の過程で「機能を作ること」が目的になってしまい、「誰の何を解決するか」の視点が抜けがちなんですよね。
（これは研修のカリキュラム側の問題でもある💦）
なぜこれが問題なのか？
- 実装中に仕様で迷ったとき、判断基準がない
- 本当に必要な機能と不要な機能の区別がつかない
- 結果的に「作ったけど使われない」状態になりやすい
「なぜ」思考フレームワーク
以前に参加した勉強会で、顧客価値を明確にするためのフレームワークのお話に感銘を受けたので、これを意識的に取り組むよう促したところ、短期間でも効果を実感できたので共有します。
本研修では、新人が顧客側としてシステムを発注する体験と、ベンダーとして受託開発をする体験をそれぞれに実施するという方針で開発演習を行っています。
フレームワーク詳細（クリックで展開）
| 項目 | 考えるべき内容 | 開発時の判断基準として |
|---|---|---|
| 🎯 顧客 | 顧客は誰か | 機能の使いやすさを判断する軸 |
| 😰 課題 | 顧客の課題は何か | 実装すべき機能の優先度決定 |
| 🤔 理由 | なぜその課題は未解決なのか | 技術選定や設計方針の指針 |
| 🛠️ 解決手法 | どうやって課題を解決するのか | 実装アプローチの明確化 |
| ✨ 価値 | 解決によってどんなメリットがあるのか | 成功指標とテスト観点の設定 |
| 🚀 優位性 | その解決手法の優位性は何か | 技術選定の根拠 |
| 💪 実現性 | 自分たちで実現可能か | スコープとスケジュールの調整 |
【実践例】チーム管理システムの開発体験
従来の進め方：機能ドリブン
新人研修のチーム開発演習の一場面の例です（ほぼ実話のフィクション）
当初の進め方：
「チーム管理システムを作ります」
「どんな機能を実装予定ですか？」
「メンバー登録、タスク割り当て、進捗管理、通知機能です」
「なるほど。で、どんな課題を解決するんでしたっけ？」
「...チーム管理の...効率化？」
このまま進めると、開発後半で「時間が足りない、何を削ろう？」となり、適当に機能を削って中途半端なものが出来上がりがちです。
フレームワーク適用後：価値ドリブン
フレームワークを使って要件を再整理してみました：
🎯 顧客：リモートワーク中心の5人チーム（営業2名、エンジニア3名）
- 😰 課題：
- 営業メンバーがエンジニアの作業状況を把握できない
- 急な顧客対応で優先度が変わっても、情報共有が遅れる
- 週次MTGでしか進捗を知れないため、問題発見が遅い
- 🤔 理由：
- SlackやGitHubの通知が多すぎて重要な情報が埋もれる
- エンジニアは技術的な詳細を話すが、営業には伝わらない
- リアルタイムでの状況共有ツールがない
- 🛠️ 解決手法：
- 営業向けの「顧客影響度」を軸にしたタスク表示
- 1日1回の自動進捗サマリー通知
- 緊急度変更時のリアルタイム通知
- ✨ 価値：
- 営業が顧客への回答スピードを2日→半日に短縮
- 問題の早期発見により、炎上プロジェクトを50%削減
- チーム全体の情報共有時間を週2時間→30分に短縮
- 🚀 優位性：
- 営業視点での情報整理（技術詳細ではなく顧客影響度）
- 既存ツール（Slack/GitHub）との連携による導入コスト削減
- 💪 実現性：
- GitHub API、Slack API を使用（学習コスト数日程度）
- 段階的リリースで MVP から開始可能
- データベース設計は既存の知識で対応可能
結果：劇的な変化
実装判断の速度向上
- 「この機能、本当に必要？」→ 顧客価値で即座に判断
- 「時間がない、何を削る？」→ 価値の優先度で明確に選択
成果報告の説得力
- Before：「〇〇機能を実装しました」
- After：「営業の顧客対応速度を2日→半日に短縮するシステムを作りました」
個人開発・実務での効果：短期間で見えた変化
📊 フレームワーク導入前後の変化
| 指標 | フレームワーク無し | フレームワーク有り |
|---|---|---|
| 機能削減の判断時間 | 悩んで数時間 | 価値基準で15分程度 |
| 仕様確認の往復回数 | 平均5回以上 | 平均2-3回 |
| 技術選定の迷い | 新しい技術を試したくなる | 課題解決に最適な技術を選択 |
🎯 定性的な変化
実装時の迷いが激減
- 「この画面項目、どう表示しよう...」
+ 「営業が見るなら、顧客名を大きく表示しよう」
- 「エラーハンドリング、どこまでやろう...」
+ 「営業の業務が止まると顧客対応が遅れるから、しっかり作ろう」
プレゼンテーション力の向上
- 機能説明→課題解決ストーリー
- 技術的なアピール→ビジネス価値のアピール
- 「作りました」→「〇〇を解決しました」
特にクライアントへの提案や社内発表での変化が顕著でした。
作ったシステムについて「自分だったらどう使うか」をイメージしやすくなり、フィードバックの内容も「お客様なら～」という質問を交えていただく中で、現場未経験ながら間違っていても想像をしながら回答を出そうとする努力が見られました。
独学エンジニアが実践するときのポイント
1. 💭 架空の設定でもOK、ただしリアルに
- 「ユーザーが便利になるTodoアプリ」
+ 「在宅勤務で家事と仕事を両立している30代会社員向けの、
一日の予定を家族と共有できるTodoアプリ」
具体的な人物像を設定することで、機能の必要性が明確になります。
2. 🔢 数値目標を設定する
- 「効率的になる」
+ 「朝の予定確認時間を10分→3分に短縮」
+ 「家族との予定調整の連絡回数を1日5回→1回に削減」
抽象的な表現を避け、測定可能な目標を設定します。
3. 🚀 実装できる範囲で価値を最大化
限られた時間・リソースでも価値を実現できるよう、機能を絞り込みます：
MVP（最小価値実現）の考え方：
× 「全機能を70%の完成度で」
○ 「コア機能を100%の完成度で」
ポートフォリオ・転職活動での活用法
このフレームワークは、ポートフォリオ作成や転職面接でも威力を発揮します：
🎨 従来のポートフォリオ
「React + TypeScript で作った家計簿アプリです」
「CRUD機能とグラフ表示機能があります」
「レスポンシブ対応もしています」
✨ フレームワーク活用後
「共働き夫婦の家計管理における『相手の支出が見えない』問題を解決する
リアルタイム共有家計簿アプリです」
「月末の家計確認時間を2時間→15分に短縮し、
家計についての夫婦喧嘩を月3回→0回に削減することを目標にしています」
「技術的には React + TypeScript で実装し、
リアルタイム同期に Firebase を使用しています」
面接官にとって、どちらが記憶に残りやすいでしょうか？
実務でのさらなる応用
このフレームワークは個人開発だけでなく、実務でも活用できます：
📝 要件定義・仕様確認時
- クライアントとの認識合わせがスムーズに
- 仕様変更時の影響範囲が明確に
- 優先度判断の根拠が共有しやすい
💡 技術提案時
- 新技術導入の説得力が向上
- コストと効果の説明が具体的に
- リスクとメリットの整理が明確に
プログラミングを学ぶ過程では、どうしても「技術習得」に意識が向きがちです。しかし実際の開発現場では、「誰の何を解決するか」を明確にする力こそが求められます。
このフレームワークは、その思考力を短期間で身につけるための実践的なツールです。
現場に入る前に、ポートフォリオを作る前後にも「これって結局誰のためなんだっけ？」を振り返ってみるとぐっと良くなります！