システム開発の発注者体制｜役割・工数・作り方

システム開発を外注しても、目的・優先順位・予算・受入可否の判断は発注者側に残ります。責任者、業務担当、進行管理、IT・セキュリティ担当の役割と決裁期限を発注前に決め、足りない実務だけを外部PM支援で補うことが成功の基本です。

• システム開発に発注者体制が必要な理由
  • 発注体制の代表的な3パターン
• 発注者側に必要な役割と工数・費用の目安
  • 必要な役割と担当内容
  • 工程によって発注者の負荷は変わる
  • 社内PMが不足する場合の外部支援費用
• 発注者体制を作る5つのステップ
  • 1．目的・予算・期限を1枚に整理する
  • 2．意思決定者と日常窓口を分けて決める
  • 3．業務・IT・管理部門の協力者を指定する
  • 4．担当者の稼働時間を確保する
  • 5．会議・課題・変更のルールを決める
  • 発注前チェックリスト
• 開発会社・外部PMの選び方と見積もりの見方
  • 開発会社のPMと発注者側PMの違い
  • 商談で確認したい質問
  • 見積もりで確認すべき項目
  • 契約前に合意しておきたい条件
• まとめ
• よくある質問
  • 小規模なシステム開発なら発注者側は最低何人必要ですか？
  • 発注者側の担当者は月にどの程度の工数が必要ですか？
  • 発注者側のPMをすべて外部へ任せてもよいですか？
  • 発注者体制はいつまでに決めるべきですか？

システム開発に発注者体制が必要な理由

開発会社へ依頼すれば、設計や開発、テストなどの専門的な作業は外注できます。しかし、「なぜ作るのか」「どの業務ルールを採用するか」「どの機能を優先するか」といった事業上の判断までは、開発会社だけでは決められません。

発注者体制とは、単に問い合わせ窓口を1人置くことではありません。システム開発に必要な社内判断を、誰が、何を根拠に、いつまでに行うかを決めた仕組みです。

発注者と開発会社の役割は、概ね次のように分けられます。

発注のご相談を受ける開発会社の立場から見ると、遅延の原因は開発作業だけにあるとは限りません。業務ルールへの回答待ち、複数部署の意見調整、責任者の承認待ちなど、発注者側の判断が止まって工程全体が動かなくなるケースもあります。

特によくある誤解は、「詳しい担当者を窓口にすれば十分」というものです。現場担当者が業務に詳しくても、予算変更や仕様の優先順位を決める権限がなければ、結局は社内確認の往復が発生します。実務を理解する人と、判断できる人の両方を体制に含めることが重要です。

発注体制の代表的な3パターン

案件の規模や関係部署数によって、適した体制は異なります。

PMとは、プロジェクトマネージャー、つまり進行・課題・予算・関係者調整を管理する役割です。PMOとは、プロジェクト管理を支援する担当または組織を指します。名称よりも、実際に誰が何を行うかを明文化することが大切です。

発注者側に必要な役割と工数・費用の目安

標準的なシステム開発では、少なくとも「最終責任」「日常の進行」「業務確認」「IT・セキュリティ確認」の役割が必要です。小規模案件なら1人が複数の役割を兼務できますが、役割そのものをなくすことはできません。

必要な役割と担当内容

上記は中小規模案件を想定した一般的な目安です。関係部署数、既存システムとの連携数、個人情報の取り扱い、社内の承認手続きなどによって変わります。

同じ人が複数の役割を兼務する場合、表の工数を単純に合計する必要はありません。一方で、「本業の空き時間で対応する」とだけ決めると、確認が後回しになりやすいため注意が必要です。要件定義や受入テストの期間は、担当者の予定表へあらかじめ作業時間を確保しておく方が現実的です。

工程によって発注者の負荷は変わる

発注者側の作業量は、開発期間を通じて一定ではありません。特に要件定義と受入テストで負荷が高まります。

要件定義とは、作る機能や品質、制約条件を具体的に決める工程です。その前段階で、目的や業務上の要求が曖昧な場合は、要求定義の進め方｜要件定義との違いと外注準備も参考にしてください。

社内PMが不足する場合の外部支援費用

社内に進行管理の経験者がいない場合は、外部PMやPMO支援を利用できます。一般的な費用目安は次の通りです。

費用は、担当者の稼働量、会議頻度、成果物の範囲、システム規模によって変動します。週1回の会議と課題管理だけを依頼する場合と、要件整理や受入テスト設計まで任せる場合では、同じ「PM支援」でも金額は大きく異なります。

外部PMは、論点整理や進行管理を代行できますが、自社の経営判断までは代行できません。「全部任せる」のではなく、社内責任者が判断しやすい材料を整えてもらう役割として利用するのが基本です。

発注者体制を作る5つのステップ

発注者体制は、最初から大人数を集める必要はありません。まず意思決定の中心を決め、案件の性質に応じて必要な協力者を追加します。

1．目的・予算・期限を1枚に整理する

最初に、プロジェクトの前提を簡潔に整理します。詳細な仕様書である必要はありません。最低限、次の項目を1枚程度にまとめます。

• 解決したい業務課題または事業課題
• システム導入後に達成したい状態
• 対象となる利用者と部署
• 予算の上限または検討可能な範囲
• 希望する利用開始時期と、その理由
• 絶対に守る条件と、調整できる条件
• 成果を判断する指標

目的が曖昧なまま担当者だけを任命すると、担当者ごとに異なる方向へ仕様を検討してしまいます。体制づくりの前提として、プロジェクトの判断軸をそろえてください。

2．意思決定者と日常窓口を分けて決める

次に、最終判断を行う人と、開発会社からの連絡を受ける日常窓口を決めます。同じ人が兼任しても構いませんが、役割は分けて定義します。

例えば、日常窓口が回答できる範囲を次のように決めます。

• 軽微な文言や配置変更は窓口が判断する
• 開発費が増える変更はプロジェクトオーナーが承認する
• 業務フローの変更は業務責任者が承認する
• 個人情報や外部サービス利用はIT・セキュリティ担当が確認する
• 公開日の変更は事業責任者が決定する

誰が決めるかだけでなく、「何営業日以内に回答するか」まで合意すると、開発会社も現実的な工程を組みやすくなります。

3．業務・IT・管理部門の協力者を指定する

中心担当者がすべての質問へ回答する必要はありません。必要な分野ごとに、確認先となる協力者を指定します。

発注前に確認したい協力者は次の通りです。

• 現場業務を詳しく説明できる人
• 例外処理や承認ルールを決められる人
• 既存システムやデータを確認できる人
• アカウント、端末、ネットワークを管理する人
• 個人情報やセキュリティ基準を確認する人
• 契約、発注、支払い条件を確認する人
• 公開後の問い合わせ対応を担当する人

全員が毎回の定例会へ出席する必要はありません。参加が必要な工程と確認事項を限定した方が、現場の負担を抑えられます。

4．担当者の稼働時間を確保する

役割を決めても、時間が確保されていなければ機能しません。通常業務との優先順位を上司と合意し、週単位で時間を確保します。

特に次の作業は、会議以外の時間も必要です。

• 開発会社から届いた資料の確認
• 業務ルールに関する社内ヒアリング
• 仕様変更が費用と業務へ与える影響の検討
• テストデータの準備
• 受入テストの実施
• 利用部門への説明と操作教育
• 社内承認資料の作成

開発会社の見積もりに記載される工数は、通常、開発会社側の作業工数です。発注者側の工数が含まれているとは限りません。社内人件費も含めて予算と計画を考える必要があります。

5．会議・課題・変更のルールを決める

開発開始前に、情報共有と意思決定の方法をそろえます。最低限、次のルールを開発会社と確認してください。

• 定例会の頻度、参加者、目的
• 議事録を作成する担当者と承認方法
• 質問や課題を管理する場所
• 回答期限と期限を超えた場合の連絡先
• 仕様変更を申請・見積もり・承認する手順
• 追加費用を承認できる人
• 重大な遅延や障害が起きた場合の報告経路
• 成果物を確認し、承認する担当者

チャットや口頭だけで仕様を決めると、後から認識を確認しにくくなります。重要な判断は、課題管理表や議事録など、双方が参照できる形で残しましょう。

発注前チェックリスト

以下の項目に回答できれば、開発会社が提案と見積もりを作りやすくなります。

• プロジェクトの目的を一文で説明できる
• 予算と優先順位を最終決定する人が決まっている
• 開発会社の日常窓口が決まっている
• 現場業務を説明する担当者が決まっている
• IT・セキュリティ上の確認先が決まっている
• 契約・発注手続きを担当する部署が分かっている
• 各担当者が確保できる時間を確認している
• 不在時の代理担当者が決まっている
• 仕様変更と追加予算の承認手順が決まっている
• 受入テストと公開可否を判断する人が決まっている

開発会社・外部PMの選び方と見積もりの見方

発注者体制が十分でない場合、開発会社には実装力だけでなく、要件整理と意思決定を支援する力が必要です。ただし、「伴走します」という説明だけでは支援範囲を判断できません。会議、資料、課題管理、社内説明支援など、具体的な作業へ分解して比較してください。

開発会社のPMと発注者側PMの違い

両者は協力して進めますが、守る対象が異なります。

開発会社のPMが優秀でも、発注者側の業務調整や社内決裁をすべて担えるわけではありません。誰が発注者側の視点で全体を管理するのかを確認しましょう。

商談で確認したい質問

開発会社や外部PM候補との商談では、次の質問が有効です。

• 当社側には、どの役割と月何時間程度の稼働が必要ですか
• 要件が曖昧な場合、どの工程で、どの成果物まで整理しますか
• 定例会以外の質問や課題は、誰がどのように管理しますか
• 仕様変更が発生した場合、費用と納期への影響をどう提示しますか
• 当社の回答が遅れた場合、工程へどう反映しますか
• 受入テストの計画やテスト項目作成は支援範囲に含まれますか
• 経営層や利用部門向けの説明資料作成を支援できますか
• 開発中に担当PMが交代する場合、どのように引き継ぎますか
• プロジェクトが計画から外れた際、誰へ、どの基準で報告しますか

良い提案は、発注者側の作業を隠しません。むしろ「この時期に、この部署の判断が必要です」と具体的に示します。発注者の負担を一切説明せず、すべて任せられるように見せる提案は、実際の役割分担を詳しく確認した方がよいでしょう。

見積もりで確認すべき項目

PM・要件整理・導入支援の費用は、開発費へまとめて計上される場合と、個別項目で示される場合があります。総額だけでなく、次の作業が含まれるかを確認してください。

• プロジェクト計画の作成
• 定例会の運営と議事録作成
• 課題・リスク管理
• 要件ヒアリングと要件定義書の作成
• 画面や業務フローの確認支援
• 仕様変更の影響調査と再見積もり
• 受入テスト計画と実施支援
• データ移行と公開計画
• 利用者向けマニュアルや研修
• 公開後の問い合わせ対応

例えば、2社のPM費が同額でも、一方は定例会の進行だけ、もう一方は課題管理や受入テスト支援まで含むことがあります。「PM一式」という項目だけで比較せず、作業内容、担当者、稼働量、成果物を確認しましょう。

また、外部PMを別会社へ依頼する場合は、開発会社との責任分界を明確にします。外部PMが仕様を決めるのか、発注者の承認を取り付けるのか、開発会社の成果物をレビューするのかによって、必要な権限と費用が変わります。

契約前に合意しておきたい条件

体制に関する次の条件は、提案書、見積書、契約書、プロジェクト計画書のいずれかへ記載しておくと安全です。

• 双方の責任者と窓口
• 会議頻度と報告内容
• 発注者が提供する情報・データ・環境
• 発注者の確認期限
• 期限までに回答できない場合の扱い
• 仕様変更の手続きと追加費用の算定方法
• 成果物と承認者
• 担当者交代時の引き継ぎ方法
• 問題発生時の報告経路

自社の案件に必要な発注者体制や、開発会社へ任せる範囲を整理したい場合は、開発のご相談はこちらからご相談ください。

まとめ

• システムを外注しても、事業目的、優先順位、予算、業務ルール、受入可否の判断は発注者側に残ります
• 小規模案件では1人が複数の役割を兼務できますが、最終責任、進行、業務確認、IT・セキュリティ確認の役割は必要です
• 中心担当者の工数は、企画・選定期で月20〜40時間、要件定義や受入テストでは月40〜80時間以上になることがあります
• 外部PM・PMOの継続支援は、一般的に月60万〜180万円程度が目安ですが、稼働量と支援範囲で変動します
• 発注前に、誰が何を何日以内に決めるかを明確にすると、確認待ちによる遅延を抑えられます
• 開発会社の見積もりでは、PM費の金額だけでなく、会議、課題管理、要件整理、受入テストなどの範囲を確認することが重要です
• 外部PMへ進行管理を任せる場合も、社内の最終責任者と意思決定者は必要です

よくある質問

小規模なシステム開発なら発注者側は最低何人必要ですか？

小規模案件では、意思決定者と実務担当を兼ねた1人を中心に進めることも可能です。ただし、その人が不在の際の代理決裁者と、業務・IT・セキュリティを確認できる協力者は決めておく必要があります。

発注者側の担当者は月にどの程度の工数が必要ですか？

一般的な目安は、企画・選定期で月20〜40時間、要件定義や受入テストの繁忙期で月40〜80時間程度です。案件規模や関係部署数で大きく変わるため、週単位で会議、確認、社内調整、資料作成の時間を確保してください。

発注者側のPMをすべて外部へ任せてもよいですか？

進行管理や論点整理は外部PMへ委託できますが、事業目的、優先順位、予算、業務ルール、受入可否の最終判断は自社に残します。社内責任者を置いたうえで、足りない実務を補う使い方が適切です。

発注者体制はいつまでに決めるべきですか？

理想は開発会社への相談前です。少なくとも相見積もりを依頼する前に、責任者、窓口、決裁者、業務確認者、セキュリティ確認者を仮決めすると、提案条件と見積もりをそろえやすくなります。