ベストプラクティス
予算の中から最高のプロダクトを作る。
toishi が提案する新しい要件定義の進め方です。
「安く作る」から「予算内で最高を作る」へ
- • 「とにかく安く」を目指す
- • 品質を犠牲にしてコストを下げる
- • 使われない機能も作ってしまう
- • 後から「追加費用」が発生
- • 共有画面を増やす → 品質を維持しながら工数を下げる
- • ROI で優先順位 → 使われない画面を作らない
- • AI で客観的に見積もる → 思い込みを排除
- • 小さく合意 → 手戻りを最小化
理想のワークフロー
フェーズごとに小さく合意を積み重ねることで、 手戻りを最小化し、全員が納得したプロダクトを作ります。
前提の合意
ペルソナ・ニーズ
画面・工数
スコープ決定
実装・検証
→ 承認
→ 承認
→ 承認
→ 最終承認
確認
AI で検証
AI でフェルミ推定
共有画面の可視化
スコープ調整
作成
AI で最小〜最大推定
フィードバック
→ 検証
ポイント: 各フェーズで承認を取る
Phase 5（実装）に入る前に、全員が合意した状態を作ります。 「作ってから違った」という手戻りを防ぎます。
AI を活用した客観的な見積もり
月間実行回数や工数は、人間の思い込みに頼らず AI にフェルミ推定してもらいましょう。 根拠のある数値で議論することで、全員が納得しやすくなります。
月間実行回数は AI にフェルミ推定させる
「たぶん10万回くらい」という感覚ではなく、AI に論理的に推定してもらいます。
Claude Code での例
前提: 月間UU 5万人、平均滞在3ページ」
AI の回答例:
月間UU 5万人 × 平均訪問2回/月 × 検索利用率30% = 3万回/月
（控えめに見積もると 2.5万回、楽観的に見て 4万回）
工数は AI に最小〜最大で推定させる
エンジニアの「なんとなく5人日」ではなく、AI に根拠を示してもらいます。
Claude Code での例
最小（シンプルな実装）と最大（複雑な場合）で教えて」
AI の回答例:
- フィルタ機能: 1〜3人日（フィルタ数による）
- ソート機能: 0.5〜1人日
- ページネーション: 0.5〜1.5人日
- 合計: 最小2人日 〜 最大5.5人日
人間は「AI の推定が妥当か」をレビューする
AI は万能ではありません。ドメイン知識がないため、的外れな推定をすることもあります。 人間の役割は「AI の推定に違和感がないか」をチェックし、 必要に応じて前提条件を修正することです。
なぜ AI を使うのか？
人間は自分の経験や願望に引っ張られがちです。 AI に推定させることで「客観的な数値」として議論でき、 発注者も納得しやすくなります。
共有画面で工数を下げる
品質を犠牲にせずに工数を下げる唯一の方法は、画面の共有です。 複数のユーザーニーズが同じ画面を使えば、工数は1回だけカウントされます。
画面遷移セクションで共有を可視化する
toishi の画面遷移セクションでは、どのニーズがどの画面を使うかが一目でわかります。 同じ「商品詳細画面」を3つのニーズで共有すれば、工数は1回分で済みます。
例: 商品詳細画面の共有
ROI シミュレーションで効果を確認
共有画面が多いほど、同じ予算でより多くのニーズを実現できます。 ROI シミュレーションで「このニーズを追加しても、共有画面が多いので追加工数はわずか」 という判断ができます。
使われない画面を作らない
月間実行回数が少ないニーズ専用の画面は、ROI が低くなります。 ROI シミュレーションで「この画面は作るべきか」を数値で判断し、 使われない画面を作らないことで、予算を本当に必要な機能に集中できます。
これが「予算内で最高のプロダクト」の正体
品質を下げずにコストを下げるには、共有と優先順位付けしかありません。 toishi は、この判断を数値で可視化します。
小さく合意を積み重ねる
大きな要件を一度に決めようとすると、認識のズレが生まれます。 小さな単位で合意を取りながら進めることで、全員が同じ方向を向けます。
セクション単位で承認を進める
ペルソナセクション全体を承認依頼し、承認者がまとめて確認・承認する流れです。 小さなセクションから順番に合意を積み重ねることで、手戻りを最小化できます。
全セクション一括依頼
確認に1週間 → 大きな手戻りリスク
セクションごとに依頼
1-2日で承認 → 早期に方向修正可能
差し戻しは「次のアクション」まで書く
差し戻す場合は「何をすれば合意できるか」を具体的に書きましょう。 お互いの時間を節約し、建設的な議論ができます。
曖昧な差し戻し
「もう少し詳しく書いてください」
具体的な差し戻し
「月間実行回数の根拠（データ元）を追記してください」
週次で「未合意項目」を棚卸しする
承認待ちの項目が溜まると、プロジェクトが停滞します。 週に1回、15分程度で「承認待ち一覧」を確認しましょう。
チームコラボレーション
セクションごとに担当者を決める
「ペルソナは○○さん、ユーザーニーズは△△さん」と担当を決めておくと、 誰が何を書くべきか明確になります。 コメント機能で @メンション して、担当を割り振りましょう。
「下書き」と「承認依頼」の基準を決める
「どこまで書いたら承認依頼していいか」の基準を決めておきましょう。
- ペルソナ: 名前、年齢、職業、課題、ゴールが埋まっている
- ユーザーニーズ: 月間実行回数と根拠（AI推定含む）が記載されている
- 工数: 最小〜最大の範囲と前提条件が記載されている
Excel を捨てて、全員が同じ場所を見る
Excel ファイルを添付してメールでやり取りすると、バージョン管理が破綻します。 toishi に一元化することで、常に最新の状態を全員が見られます。
AI 活用のその他のコツ
AI に「抜け漏れ」を聞く
要件を書いた後、AI に「この要件に抜け漏れはある？」と聞くと、 人間が見落としがちな考慮点を指摘してくれます。
Claude Code での例
「toishi の『ログイン機能』の要件を見て、抜け漏れがないかチェックして」
ペルソナのリアリティを AI でチェックする
作成したペルソナが「実在しそうか」を AI に聞いてみましょう。 矛盾点や不自然な設定を指摘してくれます。
ペルソナ設計のコツ
「実在しそうな人」を作る
「20代女性」ではなく「渋谷で働く28歳のマーケター、田中花子さん」。 名前、年齢、職業、1日の過ごし方まで具体的にすると、チーム全員が同じ人物を思い浮かべられます。
良いペルソナの例
「田中花子（28歳）。IT企業のマーケター。週3でリモートワーク。 通勤中にスマホで情報収集、帰宅後にPCで資料作成が日課。 効率化ツールには月3,000円まで課金する派。」
ペルソナは2-3人に絞る
ペルソナが多すぎると、誰のために作っているか分からなくなります。 メインペルソナ1人、サブペルソナ1-2人に絞りましょう。 「この機能は田中さんには刺さるけど、鈴木さんには不要」という議論ができるようになります。