発注者のためのtoishi活用法
ROIで説明し、透明性を確保する。
発注者が抱える7つの課題と、toishi の解決策を紹介します。
「要件が不明確」
何を伝えればいいか分からない。抜け漏れが怖い。
8セクション構造で漏れなく整理
「前提」「ペルソナ」「ユーザーニーズ」「画面遷移」「画面詳細」「工数」「スコープ」「検証」。 この順番で埋めていけば、要件定義が完成します。 AIが質問を生成してくれるので、何を書けばいいか迷いません。
「ROIを経営陣に説明できない」
「なぜこのシステムが必要なのか」を数字で示せない。
ROIシミュレーション結果をPDF出力
各機能の月間実行回数と工数から ROI を自動算出。 「この機能は月5,000回使われ、開発工数は8人日。ROI は625」と数字で経営陣に説明できます。 PDF出力すれば、そのまま稟議資料として使えます。
「ベンダーの見積もりが妥当か検証できない」
技術に詳しくないと、提示された工数が適正か判断できない。
AIによる工数概算で見積もりの透明性を確保
AIが画面仕様から工数の目安を算出します。 ベンダーの見積もりと比較することで、大きな乖離がないか検証できます。 あくまで参考値ですが、対話の出発点として有効です。
「機能の依存関係がわからない」
「この機能を削ると、他のどこに影響するの？」が見えない。
N:Mマッピングで画面の共有関係を可視化
ユーザーニーズと画面の関係をN:Mで管理。 「商品詳細画面」が検索フローとお気に入りフローの両方で使われていることが一目で分かります。 スコープ調整時に「この画面を削ると、2つのニーズに影響する」と判断できます。
「承認が面倒」
項目が多すぎて、1つずつ確認する気力がない。
セクション単位承認、Webで完結
「ペルソナ」「ユーザーニーズ」などセクション単位でまとめて承認。 30秒で承認完了できます。問題がある項目だけ選んで差し戻すことも可能。 承認者は無料で利用できるので、社内の関係者を何人でも招待できます。
「言った言わない」
口頭やメールで決めた内容が、後から「聞いてない」と言われる。
全変更履歴、承認記録、SPEC.md生成
誰が、いつ、何を変更したか全て記録されます。 承認者名と承認日時も残るので「承認したはず」「聞いてない」が起きません。 SPEC.md を生成すれば、合意内容をマークダウンで出力できます。
「複数ベンダーの管理」
ベンダーごとに別のツールで管理していて、全体像が見えない。
一元管理プラットフォーム、APIキーでベンダー別アクセス
全ベンダーの要件を1つのプラットフォームで管理。 APIキーを発行すれば、ベンダーごとにアクセス範囲を制御できます。 発注者は全体を俯瞰しながら、各ベンダーの進捗を把握できます。
承認者・閲覧者は何人でも無料
課金は編集する人（Owner / Admin / Editor）だけ。 承認者や閲覧者は無料で招待できます。
編集席（課金対象）
- ・Owner: プロダクト作成者
- ・Admin: メンバー管理・設定変更
- ・Editor: 項目作成・編集
無料席
- ・Approver: 閲覧・承認・差し戻し
- ・Viewer: 閲覧のみ
経営層、部門長、品質管理担当...関係者全員を気兼ねなく招待できます。
発注者としての始め方
アカウントを作成する
メールアドレスまたは Google アカウントで無料登録。
プロダクトを作成し、8セクションを埋める
AIが質問を生成してくれるので、対話しながら要件を整理できます。
承認者・ベンダーを招待する
経営層を承認者として、ベンダーを編集者として招待。全員が同じ画面を見て議論できます。
ROIシミュレーションで優先順位を決める
数字に基づいてスコープを調整。PDF出力して経営陣への報告にも使えます。