要件定義は、最適化問題である。
要望は無限、予算は有限。この矛盾を解く方法。
要件定義が失敗する本当の理由
ソフトウェアプロジェクトの66%が失敗する（Standish Group CHAOS Report）。 技術力の問題ではない。「何を作るか」を決めるプロセスに構造的な欠陥がある。
構造的な矛盾
発注者は「あれもこれも欲しい」。予算は決まっている。 この矛盾を解消する仕組みがないまま会議を重ねても、「全部必要です」で議論が堂々巡りするだけ。
必要なのは「もっと頑張る」ことではない。要望と予算の矛盾を構造的に解く仕組みが必要。
ユーザーニーズと画面の「多対多」の関係
要件定義で扱う要素は、大きく2種類に分かれる。
ユーザーニーズ
「〜したい」という価値
- 例: 商品を検索したい
- 例: 注文履歴を確認したい
- 例: お気に入りを管理したい
画面・機能
「〜ができる」というコスト
- 例: 検索画面
- 例: マイページ
- 例: 商品詳細画面
- 例: お気に入り一覧画面
ここで重要なのは、ニーズと画面が1対1ではないこと。 1つの画面が複数のニーズを満たし、1つのニーズが複数の画面にまたがる。 この「多対多」の関係に、最適化のカギがある。
ニーズと画面の対応関係
「マイページ」は注文履歴の確認とお気に入り管理の両方を担う。 この重なりが、スコープ最適化の鍵になる。
「重なり」が生む効率
あるニーズのために作った画面が、別のニーズも同時に満たすことがある。 この重なりを見つけられれば、追加コストゼロで対応できるニーズが増える。 従来の要件定義では、この構造が見えないまま進んでしまう。
ROI = 価値 ÷ 工数
すべてのユーザーニーズには「どれくらい使われるか」がある。 すべての画面には「作るのにどれくらいかかるか」がある。 この2つを掛け合わせれば、各ニーズの投資対効果が見える。
価値 = 月間実行回数
そのニーズが月に何回実行されるか。 「商品検索」なら月5万回、「退会手続き」なら月10回。 実行回数が多いほど、ユーザーにとっての価値が高い。
コスト = 画面工数
そのニーズを実現するために必要な画面の開発工数。 共有画面がある場合、すでに作る予定の画面は追加コスト0。
| ユーザーニーズ | 月間実行回数 | 工数（人日） | ROI |
|---|---|---|---|
| 商品を検索したい | 50,000 | 8 | 6,250 |
| 注文履歴を確認したい | 12,000 | 5 | 2,400 |
| お気に入りを管理したい | 8,000 | 3 | 2,667 |
| 退会手続きをしたい | 10 | 4 | 2.5 |
ROIが高いニーズから順に採用すれば、限られた予算で最大の価値を届けられる。 「退会手続き」は必要な機能だが、初期リリースに含めるべきかは別の話。感覚ではなく、数字で優先順位を議論できる。
スコープ最適化：限られた予算で最大の価値を
ROIが見えたら、次は「予算内でどのニーズを採用するか」を決める。 ここで、先ほどの「多対多」の関係が効いてくる。
ROI順に選択する
ROIが高いニーズから順に、予算の範囲内で採用していく。 「全部必要」ではなく「この予算なら、ここまでが最善」という判断ができる。
共有画面の効果を活かす
あるニーズのために作る画面が、別のニーズにも使われる場合、 そのニーズは追加コスト0（またはごく少ない工数）で採用できる。 「マイページ」を作るなら、注文履歴もお気に入りも同時に対応できる。
What-Ifシナリオで比較する
「予算を100万円増やしたら、どのニーズが追加で入るか？」 「この機能を外したら、どれだけ工数が減るか？」 複数のシナリオを並べて比較し、最善の選択を見つける。
「全部必要」から「最善の選択」へ
スコープ最適化は「機能を削る」作業ではない。限られた予算で、ユーザーに届けられる価値を最大化する作業。削るのではなく、選ぶ。その判断基準がROI。
AIの役割：たたき台と問いの生成
toishiはAIコーディングツールとMCPで接続する。 ただし、AIの役割は明確に限定されている。
AIがやること
- ペルソナのたたき台を提案
- ユーザーニーズの洗い出し
- 月間実行回数のフェルミ推定
- 工数の概算見積もり
人間がやること
- ペルソナが実態に合っているか判断
- ニーズの優先順位を決定
- スコープの最終判断
- 承認・差し戻し
AIは「問い」を生む道具
AIが出すたたき台は、そのまま使うものではない。 「この観点は抜けていないか？」「この数字は妥当か？」という問いを引き出すための起点。 判断するのは、プロジェクトの文脈を知っている人間の仕事。
追加のAI課金は不要
toishiはAIモデルを内蔵していない。 お使いのAIツール（Claude Code, Cursor, Windsurf など）からMCPで接続する方式。 AIの利用料はお使いのツールの料金に含まれる。toishi側での追加課金はなし。
この思想を具体化する8つのセクション
toishiは、上記の考え方を8つのセクションに落とし込んでいる。 前のセクションが承認されると次のセクションが解放される、段階的な構造。
プロジェクトの前提
背景、目的、制約条件を明文化する
ペルソナ
誰のために作るのかを具体化する
ユーザーニーズ
「〜したい」を洗い出し、月間実行回数を設定する
画面遷移
ニーズを実現するユーザージャーニーを設計する
画面詳細
各画面の仕様と、紐づくニーズを定義する
工数決定
各画面の開発工数を見積もる
スコープ
ROIシミュレーションで、予算内の最善を選ぶ
検証
テスト計画を立て、品質を担保する
セクション1〜5で「何を作るか」を定義し、セクション6〜7で「どこまで作るか」を決める。 最後のセクション8で「正しく作れたか」を検証する。 この流れが、要件定義を「最適化問題」として解くプロセスそのもの。