要件・要求
ワーク
ヒアリングが完了したら提案書を作成する段階になります。提案はチーム作業であるため、役割分担を行う必要がありますが、アジェンダを用意することが最初に必要な作業です。
成果物（例）
1. 現状課題の整理
発注側の「痛み」を言語化して共有ための観点
提案の冒頭で「あなたの課題をちゃんと理解している」と示すことで、その後の提案内容への信頼感が高まる。
発注側が自分で言語化できていない課題を整理してあげることが、提案者の重要な役割。
AI補足
- 課題は「業務負荷」「情報の分散」「更新コスト」「可視化不足」の4軸で整理すると漏れが少ない
- 発注側の言葉をそのまま使い、言い換えや誇張をしない
- この場で認識がズレていたら、提案全体を見直す必要があるため最初に置く
2. ご提案概要
解決策を「一言」で伝える
詳細に入る前に「結論」を先に示すことで、聞き手が全体像を掴んだ状態で詳細説明を聞ける。
「何を提案されているのかわからないまま話が進む」という不安を取り除くために独立させる。
AI補足
- キャッチコピー1文＋対象ユーザー別の比較表で全体を見せる
- 技術用語は使わず「誰が・何を使って・どう解決するか」だけ伝える
- 後のスライドで詳しく説明するため、ここでは深追いしない
3. システムアーキテクチャ・技術スタック
「どう動くか」を図と処理フローで可視化するの観点
発注側がシステムの動きをイメージできないと、スコープや工数の合意が難しくなる。構成図・処理フロー・技術選定理由を一か所にまとめることで、「なぜこの技術を選んだか」の根拠とセットで説明できる。
AI補足
- 構成図は「ユーザーゾーン」「GCPゾーン」「外部サービスゾーン」の3エリアに分けると伝わりやすい
- 処理の流れは番号付きのステップで説明し、デモのイメージと結びつける
- 技術選定は「なぜGCPか」ではなく「なぜこのサービスか」を1行で添える
4. 開発スコープ（MVP定義）
「やること」と「やらないこと」を明確に線引きする
スコープを曖昧にしたまま進めると、開発後半で「これも入ってるはず」という認識違いが発生する。MVP IN / MVP OUTを明示することで発注側の期待値を適切にコントロールする。
AI補足
- MVP OUTの項目には「Phase 2対応」と明記し、「できない」ではなく「後でやる」と伝える
- チェックマーク形式（○/×）で視覚的に一覧できるようにする
- スコープはQA表の回答次第で変動することを明示しておく
5. 工期・工数・体制
「いつまでに・誰が・どのくらい」を根拠とともに示す
工期・工数は発注側が最も気にする情報の一つ。 根拠なく「3ヶ月」と言うのではなく、フェーズ分けと役割分担を示すことで「なぜその期間か」を説明する。
AI補足
- スケジュールはフェーズ（設計→開発→テスト→リリース）で分け、各フェーズの主な作業を添える
- 工数表には「受託側」だけでなく「発注側に必要な工数」も明示する（隠れコストの透明化）
- 数字の根拠は「類似案件の実績」か「機能単位の積み上げ」で説明する
6. 開発方式・役割分担
「どうやって進めるか」と「何をお願いするか」を合意
ITリテラシーが高くない発注側には、ウォーターフォール／アジャイルの違いを説明したうえで、このプロジェクトにどちらが向いているかを理由とともに提示する必要がある。役割分担も同時に示すことで、発注側が「自分たちは何をすればいいか」を理解してもらう。
AI補足
- 生成AIを使うシステムはアジャイルが向いている（品質が動かして初めてわかるため）
- 2週間スプリントで「作る→見せる→直す」を繰り返すことを具体的に説明する
- 役割分担表は「貴社 / 受託側 / 両社」の3列で整理すると責任の所在が明確になる
7. 技術的課題と対策
想定リスクを先出しして信頼を得る
課題を隠したまま進めると、発生後に「聞いていない」というトラブルになる。事前に課題と対策をセットで提示することで、「リスクを把握したうえで提案している」事を共有して信頼して頂ける。
AI補足
- 課題は「AI品質」「データ整備」「セキュリティ」「コスト」の4軸で網羅する
- 各課題に対して「対策」を必ずセットで記載する（問題提起だけで終わらない）
- 発注側に協力が必要な対策（フォルダ整理など）は明示して協力を求める
8. まとめ・次のアクション
「今日決めること」と「次にやること」を明確にして会議を閉じる
提案会議が「いい話を聞いた」で終わると、次のステップが曖昧になる。アクションを担当者・期限付きで示すことで、提案後の推進力を生み出す。
AI補足
- 「本日のまとめ」は3点以内に絞り、記憶に残るように簡潔にする
- 次のアクションは「誰が・何を・いつまでに」の3点セットで記載する
- QA表への回答依頼など、発注側に最初にお願いするアクションを明確にする
ポイント
- 編集長の気持ちで、一冊の本を作るイメージ
- 用語辞書などで合わせ大事
- 基本設計は、人と人（システムなども）が話すレベル
- 見積りは算数で再現性が必要
- カテゴリ定義
- 展開：キッティング、機材の現地導入の事
- アプリケーション基盤：アーキテクチャの決定
- 開発支援：PMO。PMとの違いは？ご意見番？。開発標準
- 構成管理：昔のJenkinsのライブラリをチェックする人
- タスクセット（全行程）
- 立ち返って確認する事が必要