PM/ITコンサルタントのためのtoishi活用法
要望を削り、数字で決断する。
プロジェクトマネージャーが toishi で得られる武器を解説します。
PMが抱える6つの課題と解決策
ステークホルダーから「あれも欲しい、これも欲しい」と要望が積み上がる。 感覚で「NO」と言えば角が立つ。根拠がないから押し切られる。
toishi の解決策: ROI順でスコープを決定。各ユーザーニーズの月間実行回数と工数から ROI を自動算出し、数字で「NO」が言えます。「この機能は ROI が 80% なので、Phase 2 に回しましょう」と提案できる世界です。
エンジニアによって見積もりが大きく異なる。1人が「3日」と言えば別の人は「2週間」。 どちらを信じればいいのか分からない。
toishi の解決策: AIによる工数概算と、2点推定（最小〜最大）で不確実性を可視化。 「最小3日、最大8日」のように幅を持たせることで、リスクを織り込んだ計画が立てられます。
個別の見積もりはあるのに、全体を足し上げた数字がどこにもない。 「結局、全部でどれくらいかかるの？」に即答できない。
toishi の解決策: スコープセクションで、選択したユーザーニーズの合計工数をリアルタイム表示。 ニーズを追加・削除するたびに合計が更新されるので、予算との整合性を常に確認できます。
Excel の要件定義書を渡しても「これだけじゃ分からない」と言われる。 口頭で補足した内容は記録に残らず、後から「聞いてない」が発生する。
toishi の解決策: 構造化された8セクション（前提、ペルソナ、ユーザーニーズ、画面遷移、画面詳細、工数決定、スコープ、検証）で要件を整理。 SPEC.md 自動生成で、エンジニアが AI ツールに読み込める形式で出力できます。
定例会議で画面仕様を共有したいが、毎回スクリーンショットを貼り付けるのは手間。 最新版がどれか分からなくなる。
toishi の解決策: 画面詳細セクションで画面名・種別・紐付くユーザーニーズを管理。 PDF出力機能で、定例用の資料をワンクリックで生成できます。
ユーザーの操作フローを可視化したいが、専用ツールを導入するほどでもない。 PowerPoint で描くと更新が追いつかない。
toishi の解決策: 画面遷移セクションで簡易フローを管理。要件定義と同じプラットフォーム上でフローを確認できます。 より詳細なフロー図への拡張も将来予定しています。
PMの toishi ワークフロー
前提セクションでプロジェクト背景を整理
プロジェクトの目的、背景、制約条件を記録。ステークホルダー全員が同じ前提を共有できます。
ペルソナセクションでターゲットを明確化
誰のための機能なのかを定義。「全員向け」ではなく、具体的なユーザー像を描くことで要件がブレなくなります。
ユーザーニーズセクションで要望を洗い出し
各ニーズに月間実行回数を設定。AI が受入基準を自動生成するので、抜け漏れを防げます。
スコープセクションでROIベースの優先順位付け
月間実行回数 × 工数から ROI を算出。予算内に収まるよう、数字を見ながらスコープを調整します。
承認フローでステークホルダーと合意
セクション単位で承認を依頼。「誰が、いつ、何を承認したか」が記録に残り、後から揉めません。
PMが得られるメリット
数字で「NO」が言える
ROI が低い機能は数字で説明して後回しにできる。感情論ではなくデータで議論。
見積もりの透明性
2点推定で不確実性が見える。「最悪ケースでも予算内か？」を事前に確認できる。
合意の記録が残る
承認履歴が全て記録される。「言った言わない」問題が構造的に発生しない。
開発チームとの共通言語
構造化された要件定義で、エンジニアが「何を作ればいいか」を正確に理解できる。