Part 1 オリエンテーション・動画
第2章 作る前に価値を見る
動画台本ナレーション全文
Slide 01. 作る前に価値を見る
前の章で、この研修全体の地図を見ました。Chapter 2では、その最初の一歩として、作るものが誰の何に役立つかを考えます。実務では、「一覧画面がほしい」「CSVも出したい」のように、作るものの名前から相談が始まることがあります。そのときに、誰が何に困っていて、作った後に何が良くなれば成功なのかを一度言葉にします。
Slide 02. 機能要求は答えではない
実務では、「この画面がほしい」「この項目を追加してほしい」と相談されることがあります。新人のうちは、そのまま実装することが正解に見えやすいです。ただ、最初に渡される要求には、まだ聞けていない事情や思い込みが混ざることがあります。機能要求は、完成した仕様ではなく、課題を一緒に整理する入口だと捉えます。
Slide 03. ケースで考えます
今回のケースは、研修の学習ログアプリです。運営から、「メンターが受講者の進捗を見られる一覧画面がほしい。誰が詰まっているか分かるようにしたい。できればCSV出力もあると助かる」と相談されました。ここですぐ一覧画面とCSVを作る前に、要求を分解していきます。
Slide 04. ユーザーを分ける
まず、この機能を直接使う人を確認します。このケースでは、直接使う人はメンターです。一方で、影響を受ける人は受講者です。メンターが見やすくなるだけでなく、詰まっている受講者に早く支援が届くかも重要です。直接使う人と影響を受ける人を分けると、見落としが減ります。
Slide 05. 課題を言葉にする
次に、今誰が何に困っているかを言葉にします。メンターは、複数の受講者のログを一つずつ開いて確認しています。そのため、誰が提出していないのか、誰が困っているのかに気づくまで時間がかかります。ここでの課題は、一覧画面がないことではなく、支援が必要な人に気づきにくいことです。
Slide 06. 出力と成果を分ける
まず、作るものと、良くしたい状態を分けます。作るものは、進捗一覧画面、絞り込み、CSV出力のように形として残るものです。良くしたい状態は、メンターが詰まっている受講者に早く気づける、受講者が放置される時間が減る、といった変化です。英語では作るものをOutput、変化をOutcomeと呼びます。ここでは言葉より、混ぜないことを大事にします。
Slide 07. ユーザー価値と事業価値
ユーザー価値は、使う人や影響を受ける人がどれだけ助かるかです。このケースでは、メンターが確認しやすくなり、受講者への支援が早くなります。事業価値は、チームや事業にとって何が良くなるかです。研修の品質が安定し、特定の人だけに頼らず運営しやすくなることも価値です。どちらか一方ではなく、両方を見ます。
Slide 08. すぐ作らず質問する
質問は、作業を止めるためではありません。間違ったものを速く作らないために、依頼者やメンターに確認します。たとえば、メンターは毎日見るのか、週に数回見るのか。誰がどの受講者のログを見てよいのか。詰まっているとは、どの情報から判断するのか。CSVは誰が何に使うのか。こうした確認が、実装の形を変えます。
Slide 09. 成功状態を先に置く
機能が成功したと言える状態も、先に考えます。「一覧画面ができた」だけでは、成功かどうか分かりません。「メンターが担当受講者の最終ログ日時、困っていること、提出状況を短時間で確認できる」のように、見て確かめられる状態で書きます。完璧な数値目標でなくても、何を見れば良いかが分かる形にします。
Slide 10. 制約が判断を変える
技術判断は、理想だけでは決まりません。このケースでも、いつまでに必要か、既存ログにどんなデータがあるか、チームがその技術に慣れているかで、選べる案が変わります。さらに、困っていることには個人的な内容が含まれる可能性があります。誰がどこまで見られるか、権限やセキュリティの確認も必要です。制約は邪魔ものではなく、判断材料です。
Slide 11. 小さく作ることと雑は違う
初回リリースでは、小さく届ける単位を考えます。ただし、小さく作ることと雑に作ることは違います。たとえば、初回は最終ログ日時、困っていること、提出状況だけを見る一覧に絞る。一方で、閲覧権限や表示の分かりやすさは雑にしない。目的に効く最小単位を選ぶことが大切です。
Slide 12. MustからWon’tまで決める
スコープは、初回で必ず入れるもの、できれば入れたいもの、余裕があれば入れたいもの、今回はやらないものに分けます。英語では、Must、Should、Could、Won’tと呼ぶことがあります。このケースなら、受講者の進捗を見られる一覧は必須です。一方で、自動アラートや詳細な分析ダッシュボードは、初回では見送る判断ができます。
Slide 13. 案を比べて選ぶ
実装案は一つだけとは限りません。進捗一覧画面を作る案、CSV出力だけを先に作る案、自動アラートまで作る案が考えられます。それぞれ、役に立つか、作る手間はどれくらいか、危ない点はないか、あとで続ける手間は重くないかを比べます。便利そうかどうかだけでなく、初回の目的に対して説明できる選択かを見るのがポイントです。
Slide 14. 見送る理由も判断です
何を作るかだけでなく、何を今回は作らないかも判断です。CSV出力は便利そうでも、誰が何に使うかが不明なら後回しにできます。自動アラートは早く気づける価値がありますが、誤通知や通知疲れのリスクがあります。見送った理由を価値、手間、リスクと結びつけて説明できると、判断がチームに伝わります。
Slide 15. 判断を文章で残す
技術判断は、コードだけでは伝わりません。なぜその範囲にしたのか、何を見送ったのか、どのリスクを確認するのかを短く書きます。レビューに出すときの変更説明、設計メモ、タスク分解は、後からチームが判断を追うための資料になります。正しく動くだけでなく、なぜその作り方でよいと言えるかを説明できることが実務では重要です。
Slide 16. 悪いメモと良いメモ
悪いメモは、「一覧画面を作る。CSVも便利そうなので作る」で終わります。これでは、誰の課題か、成功状態は何か、見てはいけない人に見えてしまう心配はないかが分かりません。良いメモは、「初回はメンターが担当受講者の最終ログ日時、困っていること、提出状況を見られる一覧に絞る。CSVと自動アラートは理由を添えて見送る」と書きます。
Slide 17. 演習で要求を分解する
第2章の演習では、まず要求を分解するワークシートを書きます。ファイル名は feature-value-breakdown.md です。ユーザー、課題、期待する成果、作るかもしれないものを分けます。次に、確認したい不明点を5つ以上書き、時間、データ、権限、運用、既存システムの制約も整理します。実装案を急がず、価値と制約を先に見ます。
Slide 18. 個人開発にもつながる
最後に、判断を残すメモを書きます。ファイル名は decision-memo.md です。実装案を2つ以上比べ、採用案、理由、見送ったこと、リスクと確認事項を残します。この型は、個人開発課題にも使います。次の章では、このメモをAIに相談するときの前提にもします。作ったものだけでなく、なぜ作ったのかを説明する練習です。