第2章価値から機能を考える

第1章では、研修全体を一つの仕事の流れとして見るための地図を作った。第2章では、その地図の最初の地点へ進む。つまり、作る前に価値を見る。

実務では、依頼が最初から整理された要件として届くとは限らない。むしろ多くの場合、最初に届くのは「一覧画面がほしい」「通知を出したい」「CSVを出せるようにしたい」のような、作りたいものの名前である。しかし、作りたいものの名前は、まだ問題そのものではない。

エンジニアが最初に考えるべきことは、画面やボタンの形ではない。誰が、何に困っていて、作った後に何が良くなれば成功なのかである。ここを確認しないまま作り始めると、動くものはできても、役に立つものにならないことがある。

この章でできるようになること

この章のゴールは、一人で事業判断を背負えるようになることではない。小さな機能要求を受け取ったときに、すぐ実装名へ飛ばず、確認すべきことを自分の言葉で分けられるようになることである。

この章を読み終えたら、次のことができる状態を目指す。

相手の要望から、ユーザー、課題、期待する成果を分けて書ける。
直接使う人と、影響を受ける人を分けて考えられる。
作るものと、作った後に起きてほしい変化を分けられる。
成功状態を、あとで確認できる言葉にできる。
時間、データ、権限、運用、既存システムの制約を書き出せる。
初回リリースでやること、やらないことを説明できる。
案を一つだけ出すのではなく、価値、コスト、リスク、運用負荷で比べられる。
Decision Memoに、採用案、見送った案、理由、確認事項を残せる。

最初から完全な答えを出す必要はない。大事なのは、分かっていること、まだ確認していないこと、仮に置いている判断を混ぜないことである。

要望と課題を分ける

第1章で見た依頼をもう一度使う。

「メンターが担当受講者の支援ステータスを一覧で見られるようにしたい」

この文には、すでに一つの実装案が含まれている。「一覧で見られるようにしたい」という部分である。しかし、ここですぐに一覧画面へ項目を追加する話へ進むと、重要な確認を飛ばしてしまう。

まず分けるべきなのは、要望、課題、成果である。

要望：相手が最初に言った、作りたいものや変えたいもの。
課題：現在困っていること、時間がかかっていること、間違いや見落としが起きていること。
成果：作った後に、利用者の仕事がどう良くなるか。

似た言葉として、output と outcome もよく使われる。

Output：作って提供するもの。画面、API、CSV、通知、ドキュメントなど。
Outcome：作った結果として起きてほしい変化。見落としが減る、確認時間が短くなる、次の対応が早くなるなど。
Success signal：その変化が起きたかを確認する手がかり。確認にかかった時間、見落とし件数、問い合わせ件数、利用者の観察結果など。

要望、課題、成果を分けると、同じ「一覧で見たい」という要望でも、まったく違う機能になる可能性が見えてくる。

たとえば、課題が「支援が必要な受講者を見落としやすい」なら、ステータスの表示や絞り込みが効くかもしれない。課題が「上長への週次報告に時間がかかる」なら、一覧よりも集計やエクスポートが重要かもしれない。課題が「メンター同士で判断がずれる」なら、ステータスの定義や更新ルールの整備が先かもしれない。

要望は入口である。課題は理由である。成果は、作った後に確認する変化である。この三つを混ぜないことが、価値から考える第一歩になる。

価値を確認する質問

価値を見るとは、抽象的なビジネス用語を並べることではない。相手の仕事がどう変わればよいのかを、具体的に聞くことである。

支援ステータスの依頼を受けたら、たとえば次のように確認する。

誰がこの一覧を見るのか。
いつ見るのか。毎日なのか、週次なのか、面談前なのか。
何を判断するために見るのか。
今はどうやって支援が必要な受講者を見つけているのか。
今の方法では、何に時間がかかっているのか。
見落としが起きると、誰にどんな影響があるのか。
作った後、何が減れば成功と言えるのか。確認時間か、見落とし件数か、報告作業か。

これらの質問は、相手を問い詰めるためのものではない。作るものを小さくし、最初に確認すべき成果を明確にするためのものだ。

たとえば、確認の結果、次のように整理できたとする。

利用者：メンター。
現在の課題：担当受講者の状態を複数の場所で確認していて、支援が必要な人を見つけにくい。
期待する成果：支援が必要な受講者を早く見つけ、声かけや面談につなげられる。
候補機能：担当受講者一覧に支援ステータスを表示する。ステータスで絞り込める。ステータスを更新できる。

ここまで整理できると、依頼は単なる「一覧に項目を追加する」ではなくなる。目的は、支援が必要な受講者を早く見つけ、次の対応へつなげることだと分かる。

成功状態を、見て確かめられる言葉にする

「便利にする」「見やすくする」「効率化する」は、方向としては間違っていない。しかし、そのままだと実装後に成功したかどうかを判断しにくい。価値を扱うときは、成功状態をあとで確認できる言葉に近づける。

たとえば、次の表現だけではまだ弱い。

メンターが受講者の状況を見やすくする。

少し具体化すると、確認しやすくなる。

メンターが担当受講者の最終ログ日時、困っていること、提出状況を一覧で確認し、
当日声をかける受講者を選べるようにする。

さらに、観察する手がかりも置ける。

初回確認では、メンターが一覧を見て支援が必要そうな受講者を選べるかを確認する。
可能なら、確認にかかった時間と、見落とした受講者がいなかったかも記録する。

数字を必ず置かなければならないわけではない。ただし、成功状態が「気持ち」だけで終わると、テストやレビューやリリース判断につなげにくい。観察できる行動、減らしたい手間、避けたい失敗のどれかに近づけて書くと、後の章で扱いやすくなる。

制約を見る

価値が見えても、すべてを一度に作れるとは限らない。実務には制約がある。

制約とは、実装範囲を決めるときに無視できない条件である。時間、データ、権限、セキュリティ、運用、既存システムとの関係などが含まれる。

支援ステータス機能なら、次のような制約が考えられる。

時間の制約：初回リリースまでに使える日数が限られている。
データの制約：既に受講者データはあるが、支援ステータスを保存する場所はまだない。
権限の制約：メンターは担当受講者だけを見られるべきかもしれない。
運用の制約：ステータスの更新ルールを誰が決めるのかがまだ曖昧かもしれない。
既存システムの制約：現在の一覧画面の構成やAPIの形を大きく変えられないかもしれない。

支援状況や困っている内容には、受講者本人にとって慎重に扱うべき情報が含まれることがある。そのため、価値が高そうに見える機能でも、誰が見てよいか、どこまで表示してよいか、ログやCSVに残してよいかを確認する必要がある。価値の確認と、権限やセキュリティの確認は別の話ではない。役に立つものほど、見せ方と扱い方を間違えると影響が大きくなる。

制約は、やる気を削ぐために書くものではない。安全に小さく始めるために書く。制約が見えていれば、今回やることと、今回はやらないことを説明しやすくなる。

MVPは、何を確かめるかで決める

MVPは Minimum Viable Product の略である。日本語では、最初に価値を確かめるための最小構成と考えるとよい。

MVPを「機能を削った版」と考えてはいけない。 MVPは、何を確かめたいのかから決める。

支援ステータス機能で最初に確かめたいことが、「メンターが支援の必要な受講者を早く見つけられるか」だとする。その場合、初回MVPは次のようにできる。

担当受講者一覧に、現在の支援ステータスを表示する。
ステータスの意味を画面上で分かるようにする。
支援が必要な受講者が一覧で見つけられるかを確認する。

一方で、次のものは初回から入れない判断もできる。

ステータス更新履歴の詳細表示。
Slackやメールへの通知。
CSV出力。
複雑な集計ダッシュボード。

これらが不要だという意味ではない。最初に確かめたい成果に対して、今すぐ必要ではないという意味である。 MVPは、価値を小さくするのではなく、確認する順番を決めるための考え方である。

また、小さく作ることと、雑に作ることは違う。初回MVPでも、次のような条件は後回しにしにくい。

見てはいけない人に情報が見えないこと。
表示されるステータスの意味を利用者が誤解しにくいこと。
既存の一覧画面やAPIを壊さないこと。
確認したい成果に必要な最低限のデータがそろっていること。

「あとで直す」は、価値検証に関係ない飾りを後回しにするときには有効である。しかし、権限、個人情報、データの正しさ、利用者の誤解に関わる部分まで雑にすると、価値を確かめる前に信頼を失う。

Must、Should、Could、Won’tで期待値をそろえる

初回リリース範囲を決めるときは、Must、Should、Could、Won’tで分けるとよい。この分け方は MoSCoW と呼ばれることがある。ただし、ここでは名前を覚えることより、関係者の期待値をそろえる道具として使うことが大事である。単なる優先順位表ではなく、今回の目的に対して何が必要で、何を後回しにするのかを合意するために使う。

Must：今回入れなければ、目的を確認できないもの。
Should：できれば入れたいが、初回確認の必須条件ではないもの。
Could：余裕があれば入れたいもの。
Won’t：今回はやらないと明示するもの。

初学者が特に書きにくいのは Won’t である。やらないことを書くと、消極的に見える気がするからだ。しかし実務では、Won’tを書かない方が危ない。今回やらないことが曖昧なままだと、レビュー中やリリース直前に期待のずれが表面化する。

支援ステータス機能なら、たとえば次のように分けられる。

Must：担当受講者一覧に支援ステータスを表示する。
Should：ステータスで一覧を絞り込める。
Could：ステータスごとの件数を表示する。
Won’t：初回では通知、CSV出力、詳細な更新履歴は扱わない。

この分け方があれば、作る範囲だけでなく、作らない理由も説明できる。

案を比べて選ぶ

実装案は、一つだけとは限らない。最初に思いついた案が悪いとは限らないが、他の案と比べていないと、なぜそれを選んだのかを説明しにくい。

支援ステータス機能なら、たとえば次のように比べられる。

案	内容	価値	コスト	リスク	運用負荷
A	担当受講者一覧に支援ステータスを表示する	メンターが毎日確認しやすい	中	権限設計と表示定義が必要	低
B	CSV出力を先に作る	既存の表計算や週次報告に使いやすい	低から中	最新状態が分かりにくい。ファイルの扱い方に注意が必要	中
C	自動通知まで作る	支援が必要な受講者に早く気づける	高	誤通知、通知疲れ、通知条件の調整が必要	高

ここでのコストは、実装時間だけではない。レビュー、テスト、データ移行、権限確認、運用後の問い合わせ対応も含めて考える。リスクも、コードが難しいかだけではない。見せてはいけない情報が見える、古い情報で判断する、通知が多すぎて無視される、といった利用者側の失敗も含める。

案比較の目的は、完璧な採点表を作ることではない。今回の目的に対して、なぜその案から始めるのかを説明できるようにすることである。

判断をDecision Memoに残す

価値、制約、MVPを考えたら、判断を短いメモに残す。これがDecision Memoである。

Decision Memoは、立派な設計書ではない。なぜその範囲にしたのか、何を採用し、何を今回は見送ったのかを、後から読めるようにするためのメモである。

たとえば、次のように書ける。

背景: メンターが担当受講者の状況を確認するとき、支援が必要な人を見つけにくい。

ユーザーと課題: メンターが、担当受講者の支援状況を短時間で把握したい。現在は複数の情報を見比べる必要があり、見落としが起きやすい。

期待する成果: メンターが担当受講者一覧を見て、当日声をかけるべき受講者を選べるようにする。初回確認では、支援が必要な受講者を一覧上で見つけられるか、ステータスの意味を誤解しないかを見る。

比較した案:

A: 一覧に支援ステータスを表示する。
B: CSV出力を先に作る。
C: 自動通知まで作る。

採用する案: 案A。担当受講者一覧に支援ステータスを表示する。初回では、支援が必要な受講者を一覧上で見つけられるかを確認する。

今回やらないこと: 通知、CSV出力、詳細な更新履歴、複雑な集計は初回では扱わない。

理由: 初回の目的は、支援対象を見つけやすくなるかを確認することだからである。通知や集計は、一覧表示の利用状況と運用方法を確認してから判断する。

確認方法: メンターが担当受講者一覧を見て、支援が必要な受講者を見つけられるかを確認する。支援ステータスの意味が画面上で誤解なく読めるかも確認する。

リスクと確認事項: メンターが担当受講者以外の情報を見られないようにする必要がある。支援ステータスの定義と更新ルールが曖昧なままだと、メンターごとに判断がずれる可能性がある。困っている内容を一覧に出す場合は、表示してよい範囲を確認する。

この程度の短いメモでも、後の章で大きな意味を持つ。第9章でユースケースを書くとき、第13章でテスト観点を作るとき、第23章で本番前確認をするとき、ここで決めた成果と範囲へ戻れるからである。新しい事実が分かったら、Decision Memoは更新してよい。ただし、過去の判断を消すのではなく、何が分かって判断を変えたのかを残すと、後から経緯を追いやすい。

価値整理で起きやすい誤解

要望の表現をそのまま実装チケット名にする。
利用者を確認せず、依頼者と利用者を同じだと思い込む。
OutputとOutcomeを混ぜて、作るものを成果だと思い込む。
成果を決めずに、画面やデータの設計へ進む。
未確認のことを、都合よく決まった事実として書く。
Won’tを書かず、今回やらないことを曖昧にする。
MVPを、価値を確かめる範囲ではなく、単なる機能削減版として扱う。
小さく作るという理由で、権限や個人情報の確認を後回しにする。

Decision Memoで確認すること

feature-value-breakdown.md と decision-memo.md を作り、作る理由と今回作らない範囲を説明する。

feature-value-breakdown.mdでは、要望、ユーザー、現在の課題、期待する成果、候補機能、制約、不明点を分ける。特に、分かっている事実、まだ聞けていないこと、自分が仮に置いた前提を混ぜないようにする。

decision-memo.mdでは、採用する案、採用しない案、理由、確認方法を短く書く。案を比べるときは、価値、コスト、リスク、運用負荷を見る。採用しなかった案にも、なぜ今は選ばないのかを書く。リスクと確認事項には、権限、扱うデータ、利用者の誤解、運用で続けられるかを書く。

大切なのは、きれいな文章にすることではない。作る前の判断を、後から読み返せる形にすることである。

価値から機能を考える章で持ち帰ること

第2章で身につけるべきことは、機能名の前に価値を見ることである。価値を見るとは、誰の何がどう良くなるのかを確認することである。

要望、課題、成果を分ける。 OutputとOutcomeを分ける。制約を見る。 MVPで何を確かめるかを決める。案を価値、コスト、リスク、運用負荷で比べる。やることだけでなく、今回はやらないことも書く。そして、その判断をDecision Memoに残す。

この流れができると、後の章で要件、ドメイン、テスト、リリース判断を考えるときに、何のために作っているのかへ戻れる。

AI利用と検証の章へ

次章では、AIを学習と実務の流れに入れる。 AIに相談するときも、価値の整理は先に必要である。目的、制約、期待する成果が曖昧なままAIへ依頼すると、もっともらしいが使えない答えが返ってくる。

第2章 価値から機能を考える