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

第2章は、作りたいものの名前へすぐ飛ばず、誰の何が良くなれば成功かを先に確かめる章である。 ここでは、価値の整理と範囲決めで広く使われる用語を解説する。

MVP

• 読み：エムブイピー（Minimum Viable Product）
• 一言で言うと：最初に価値を確かめるための最小構成。
• くわしく：MVPは「機能を削った版」ではなく、「何を確かめたいのか」から決める。最初に確かめたい成果に対して今すぐ必要なものだけを入れ、それ以外は不要だからではなく「今すぐは必要ない」から外す。MVPは価値を小さくするのではなく、確認する順番を決めるための考え方である。なお、小さく作ることと雑に作ることは違う。権限・個人情報・データの正しさ・利用者の誤解に関わる部分は、初回でも後回しにしにくい。
• 具体例：支援ステータス機能で確かめたいことが「メンターが支援の必要な受講者を早く見つけられるか」なら、初回MVPは一覧にステータスを表示し意味が分かるようにするところまで。通知・CSV出力・詳細な更新履歴・複雑な集計は初回に入れない判断ができる。一方で、見てはいけない人に情報が見えないことは初回でも守る。
• つまずきやすい点：MVPを単なる機能削減版として扱う。あるいは「あとで直す」を、権限や個人情報の手抜きの言い訳に使ってしまう。
• 関連語：Output / Outcome（第2章）、MoSCoW（第2章）、vertical slice（第21章）、受け入れ条件（第9章）
• テキスト本文での登場箇所：第2章「MVPは、何を確かめるかで決める」

Output / Outcome

• 読み：アウトプット／アウトカム
• 一言で言うと：作って提供するもの（output）と、作った結果として起きてほしい変化（outcome）。
• くわしく：Outputは画面・API・CSV・通知・ドキュメントなど、作って渡すもの。Outcomeは、見落としが減る・確認時間が短くなる・次の対応が早くなるなど、作った結果として起きてほしい変化である。この二つを混ぜると、作ったこと自体を成果だと思い込んでしまう。さらに、変化が起きたかを確かめる手がかりを success signal（成功の兆候）と呼ぶ。確認にかかった時間、見落とし件数、問い合わせ件数、利用者の観察結果などが該当する。
• 具体例：支援ステータス機能のOutputは「一覧にステータスを表示する画面」。Outcomeは「支援が必要な受講者を早く見つけ、声かけや面談につなげられる」。success signalは「確認にかかった時間」「見落とした受講者がいなかったか」。
• つまずきやすい点：「便利にする」「見やすくする」で止めてしまい、outcomeを後で確認できる言葉にできない。数字を必ず置く必要はないが、観察できる行動・減らしたい手間・避けたい失敗のどれかに近づける。
• 関連語：MVP（第2章）、受け入れ条件（第9章）、SLI / SLO（第17章）
• テキスト本文での登場箇所：第2章「要望と課題を分ける」「成功状態を、見て確かめられる言葉にする」

MoSCoW（Must / Should / Could / Won’t）

• 読み：モスクワ（Must / Should / Could / Won’t）
• 一言で言うと：やることを、必須・できれば・余裕があれば・今回はやらない、に分けて優先度と範囲の合意を作る方法。
• くわしく：Mustは今回入れなければ目的を確認できないもの、Shouldはできれば入れたいが必須ではないもの、Couldは余裕があれば入れたいもの、Won’tは今回はやらないと明示するものである。名前を覚えることより、関係者の期待値をそろえる道具として使うことが大事である。単なる優先順位表ではなく、今回の目的に対して何が必要で何を後回しにするかを合意するために使う。
• 具体例：支援ステータス機能なら、Must=一覧にステータスを表示、Should=ステータスで絞り込み、Could=ステータスごとの件数表示、Won’t=通知・CSV出力・詳細な更新履歴は初回では扱わない。
• つまずきやすい点：Won’tを書きにくい。やらないことを書くと消極的に見える気がするからである。しかしWon’tを書かないと、レビュー中やリリース直前に期待のずれが表面化する。
• 関連語：MVP（第2章）、スコープ／境界（第9章）
• テキスト本文での登場箇所：第2章「Must、Should、Could、Won’tで期待値をそろえる」