
プロジェクトマネージャーの役割と責任
受託案件で最初にやるべきは「スコープの輪郭を固める」
受託開発では、契約の一文が後工程の自由度を決めます。PMの最初の仕事は、RFPやヒアリングから「やらないこと」を含めた輪郭をつくり、発注側と対等に合意することです。請負か準委任か、成果物ベースか時間ベースか、検収条件は何か。ここが曖昧だと、スコープクリープに飲み込まれます。
合意に入れるべきは、機能一覧だけではありません。非機能(SLO、性能、セキュリティ)、受入基準(テスト観点、データ条件)、変更管理のルール(誰が、何を、いつ判断するか)まで。特に変更は、「1ポイント=8時間」「チケットの優先度はRICEで決定」「週次の変更ボードで承認」というように、粒度とリズムを明記します。
要件の翻訳と見える化
抽象的な要望は、ユーザーストーリーと受入条件(Given/When/Then)に翻訳して並べます。ユーザーフローや画面骨子は1枚にまとめ、認識を早期に合わせます。初期のイメージ合意には、ChatGPTやGeminiで文面を整え、Midjourneyでラフの方向性を共有するのも有効です。技術リスクが高い箇所は、CopilotでPoCの足場を素早く作り、見積りの不確実性を減らします。
- 決めることチェックリスト:成果物の定義、優先順位のルール、受入基準、変更プロセス、コミュニケーション設計、予算のガードレール、既知リスクと対応枠、開発/検証環境の用意
見積・リスク・スケジュールは「数式」と「バッファ」で支える
見積はWBSで分解し、三点見積(楽観/悲観/最頻)からPERT平均で出します。不確実な領域には明示的に20〜30%のバッファを置き、個人ではなくマイルストーンにぶら下げます。スケジュールはクリティカルパスを可視化し、依存関係の前倒し確認を週次で行います。
リスクは登録簿で管理します。項目は「内容/影響/確率/対策/オーナー/トリガー/期日」。例えば「外部API変更」なら、影響「高」、トリガー「提供元のリリースノート更新」、対策「週1回の差分チェックとsandboxでの回帰」。GeminiやChatGPTでリリースノートの差分要約を自動化すると、見落としが減ります。
品質はゲートで担保します。設計レビュー完了=レビュー観点30項目で合格、実装完了=カバレッジ80%かつ主要フローE2E合格、受入=UATで致命的欠陥ゼロの状態など、退出条件を先に決めます。バーンダウンは理想線からのズレを±10%以内に収める運用を目標にし、ズレの原因を「スコープ/能力/障害/外部依存」に分類して是正します。
ステークホルダー運営は「リズム設計」と「判断の透明化」
受託PMは、顧客の意思決定速度に自チームを合わせる調律師です。会議体は役割で分けます。日次のスタンドアップは課題解消、週次の進捗会は成果物レビュー、隔週〜月次のステアリングコミッティは方針と変更審議。議事は24時間以内にサマリー化し、未決事項はオーナーと期日を明記します。ChatGPTで議事録の初稿を作ると回転が上がります。
コミュニケーション契約も有効です。緊急は2時間以内、通常は48時間以内に一次返信、エスカレーション先は役割で固定。外部ベンダーにはSLAと受入条件を契約化し、成果物の定義(例:ソース、テスト、運用手順)まで含めます。Copilotはコードレビューやテスト生成の補助として使いますが、「AI提案は必ず人が承認」の運用を徹底します。
意思決定を支えるKPI
- 納期遵守率、変更要求のリードタイム、欠陥密度(工程別)
- 稼働率とコンテキストスイッチ回数、UATの一次合格率
- 顧客満足(CSAT)とリリース後30日の障害件数
身近な企業活用例:中堅ECの再構築で陥った罠と立て直し
在庫基幹と連携する新ECサイトを受託で刷新。初期は「UIの改善要求」が際限なく増え、在庫連携の遅延、決済ベンダーAPIの仕様変更も重なり、納期は3週遅延、コストは15%超過しました。原因は、変更管理の不在と非機能要件の曖昧さでした。
立て直しでは、変更ボードを新設し「RICEで優先度を数値化、1スプリントあたり変更ポイント上限=13」と明文化。非機能は「在庫反映10分以内、決済エラー率0.2%以下、ピーク500RPSでP95=300ms」を合意。決済APIはGeminiでリリースノートの差分要約を自動化し、sandboxでの結合テストを定例化。テストはCopilotでE2Eの雛形を量産し、回帰の抜けを削減。デザイン合意はMidjourneyで方向性を早めに固定しました。議事・決定はChatGPTで要約し、未決管理を可視化。結果、機能は2段階リリースへ再計画し、KPI達成を優先。最終的にCSATは+0.8、障害は初月3件→1件、超過コストを+6%まで圧縮できました。
受託開発は、要件の不確実性と契約の制約が常に同居します。PMの役割は、合意の輪郭を描き、数値と運用で揺れを吸収し、判断を透明化することです。スコープ、リスク、品質、関係者のリズムを設計できれば、発注側と開発側の境界は摩擦ではなく推進力に変わります。受託開発ソリューション事業では、この境界面を丁寧に扱うPMの型こそが、継続的な価値提供の土台になります。