システム開発の社内体制。発注担当者一人に背負わせない

「開発会社との窓口を一人決めれば、社内体制は足りますか」と聞かれることがあります。連絡先は一人でも構いませんが、意思決定まで一人へ集める体制は勧めません。

システム開発の社内体制には、経営決裁、事業責任、現場業務、技術評価、受入、運用の役割が必要です。社員数が少ない会社では一人が複数の役割を担えます。ただし、役割ごとの決定範囲、回答期限、不在時の代理を分けておかなければ、発注担当者が社内と開発会社の間で質問を運ぶだけになります。

僕は、発注担当者の頑張りで開発を進める体制を作りません。誰が何を決め、どの条件で経営者へ上げ、担当者が休んだ日に誰が答えるかを契約前に書きます。

システム開発の社内体制は、六つの責任を埋めます

経営決裁者は、投資目的、予算上限、公開日の変更、顧客への影響を決めます。個々の画面には口を出さず、事業責任者が示す選択肢から会社として守る条件を選びます。

事業責任者は、変える業務、機能の優先順位、部門間で希望が割れた際の採用案を決めます。発注先からの質問を受け、自分で答える論点と経営決裁へ上げる論点を分けます。

現場担当は、現在の手順、帳票、入力、例外、利用者の困り事を説明します。希望をすべて採用する決裁者ではなく、実際の業務を開発会社へ示し、画面案やテストが現場に合うか確認します。

技術評価者は、設計、データ移行、権限、セキュリティ、復旧案を読み、費用、期限、運用負荷へ翻訳して採用案を示します。社内にいなければ、開発会社とは別の外部技術責任者へ依頼できます。

受入担当は、誰がどのデータで操作し、何をもって合格とするか決め、不一致を開発会社へ戻します。運用担当は、公開後の問い合わせ、アカウント、障害連絡、改善要望、保守窓口を引き取ります。

2026年8月時点の情報処理推進機構（IPA）の「情報システム・モデル取引・契約書（第二版）」は、契約時にユーザー企業（発注企業）とITベンダー（開発会社）が、仕様、プロジェクト管理方法、検収方法を共通理解のもとで話し合うことを期待しています。経済産業省の「デジタルガバナンス・コード3.0」も、デジタル技術を使う戦略を中長期の投資を伴う経営戦略として扱い、経営者や取締役会の関与を示しています。

いずれの資料も、六つの役割を指定してはいません。僕が発注側の会議で使える形へ置き換えたのが次の責任表です。同じ人が複数行に入っても、代理と経営へ戻す条件まで同じ欄へ書きます。

| 責任 | 主担当の例 | 不在時の代理 | 回答期限を置く場面 | 経営へ戻す条件 | | -------- | -------------------------------- | ---------------------------- | ---------------------------------------- | ------------------------------------------------ | | 経営決裁 | 代表または事業担当役員 | 決裁権限を委任した役員 | 追加費用や公開日の変更を開発会社へ返す前 | 予算上限、顧客との約束、停止判断が動く | | 事業責任 | 対象事業の責任者 | 優先順位を決められる副責任者 | 未回答で開発作業が止まる前 | 部門間の希望が割れ、事業方針の選択が要る | | 現場業務 | 実務を説明できる現場責任者 | 同じ業務を行う別担当者 | 画面案や受入条件を確定する前 | 現行業務を続けられない変更が出た | | 技術評価 | 社内IT責任者または外部技術責任者 | 設計資料を読める別の評価者 | 設計、移行、権限、復旧案を承認する前 | 個人情報、復旧、継続費用へ大きく影響する | | 受入 | 利用部門の受入責任者 | 合否基準を共有した代理 | 検収日より前に不一致を返せる日 | 主要業務を完了できず、公開延期の判断が要る | | 運用 | 公開後のシステム責任者 | 障害連絡と管理権限を持つ代理 | 本番移行を承認する前 | 復旧手順や問い合わせ先がなく、運用を引き取れない |

工程ごとに必要な判断は変わります。システム開発の流れと発注者が決める内容へ役割を重ねると、提案時に必要な人、要件定義へ参加する人、検収を行う人、本番移行を承認する人が見えます。

開発会社のプロジェクトマネージャーは、社内の優先順位を決められません

開発会社のプロジェクトマネージャー（以下、PM）は、開発側の担当者、日程、課題、成果物を管理します。発注側へ未決事項を示し、選択肢と費用・期限への影響を説明する役割も持てます。一方で、どの顧客との約束を優先するか、どの部門の業務を先に変えるか、追加予算を受け入れるかは社内の仕事です。

PMが社内の売上計画、取引先との約束、繁忙期を知らなければ、技術上進めやすくても事業に合わない順番になり得ます。

外注できる作業と社内へ残る選択を分ける考え方は、システム開発の丸投げを防ぐ方法でも説明しています。実装と進行管理を広く任せても、事業の優先順位と受入判断を行う人は発注側に置きます。

発注担当者も、開発会社から届いた言葉を社内へ転送するだけの窓口にしません。質問を受けたら、決める内容、選択肢、開発会社の推奨案、費用への影響、公開日への影響、回答期限を一枚へそろえます。事業責任者が一枚を読み、自分で決めるか経営者へ上げます。

現場要望も直接流さず、事業責任者が優先度を決め、技術評価者が設計への影響を確かめ、費用と期限を承認してから変更依頼にします。

発注担当者には、会議を設定する権限だけでなく、未回答の担当者へ期限を確認し、必要な情報が足りない議題を差し戻し、決裁条件に達した議題を経営者へ上げる権限を渡します。決める人へ届く経路を整えると、発注担当者は伝言係ではなく、意思決定を進める役になります。

兼務する体制でも、回答期限と代理を分けます

小さな会社で六人を集める必要はありません。一人が複数の責任を持つ場合は、同じ名前を役割表の複数箇所へ書きます。名前を重ねると、担当者が不在の日に止まる責任と、一人へ集中した権限が見えます。

各質問には回答者と回答日を置きます。「早めに確認」や「次回まで」という曖昧な期限を避け、開発会社が作業を止める日、費用や公開日へ影響が出る日から回答期限を決めます。回答期限までに決められない場合に、対象機能を後ろへ送るのか、作業を止めるのかも記録します。

代理は、担当者のメールを受け取るだけの人ではありません。業務資料、課題管理ツール、過去の判断記録を開けて、決められた範囲なら回答できる人を置きます。代理が承認できる金額や仕様の範囲も書き、範囲を超えた議題は経営者または事業責任者へ上げます。

経営者へ上げる条件は、会議で迷ってから決めません。予算の上限を超える変更、顧客へ約束した公開日の変更、扱う個人情報や権限への大きな影響、受入で業務を完了できない問題は、経営決裁へ送る条件として先に合意します。

技術評価を担う人へ上げる条件も必要です。認証や権限の変更、データ移行方法の変更、障害時に元へ戻せない設計、運用費へ影響する構成は、発注担当者の判断だけで承認しません。技術評価者が危険と選択肢を説明し、事業責任者が事業上の採否を決めます。

定例会議では、進捗の読み上げより未決事項を先に扱います。各議題について、決める人、回答期限、期限を過ぎた場合の影響、次に上げる相手を確認します。欠席者へ議事録を送るだけで終えず、代理が決めるか、決裁会議の日時を入れます。

経営者は、条件が動く場面へ参加します

経営者が毎回の要件確認や画面レビューへ出る必要はありません。最初に参加するのは、投資目的、対象業務、予算、動かせない期限、事業責任者の権限を決める場面です。技術作業へ入る前に、会社として守る条件を開発会社へ渡します。

要件定義中は、部門間の希望が衝突し、事業責任者の権限を超える場面へ参加します。経営者向けの議題には、選択肢、推奨案、顧客への影響、費用、公開日、回答期限を載せます。画面の細部を経営者へ選ばせず、投資判断が必要な差だけを上げます。

開発中は、仕様変更によって予算上限、公開日、顧客との約束が動く場面へ参加します。経営者が判断できる材料が届かない場合、開発会社へ説明を追加してもらいます。技術用語の理解を経営者だけへ求めず、技術評価者が事業上の影響へ翻訳します。

受入前には、未解決の問題、現場の確認結果、データ移行、利用者への案内、障害時の戻し方を見ます。経営者は個々のテストを実行せず、事業として利用を始めるか延期するかを決めます。受入担当者と運用担当者が同じ資料へ署名できる状態を作ります。

経営者の参加場面は予定表に入れ、定例で未決事項と予算・公開日の見通しを共有し、決裁間近の議題を知らせます。

公開後まで担当を残せるか、役割表を一枚で確かめます

開発中だけの体制を作ると、本番公開後に問い合わせ先が消えます。受入担当者が合格を出した後、運用担当者がアカウント管理、障害連絡、定期作業、改善要望を引き取れるか確認します。保守契約の対象外となる作業も社内の担当へ戻します。

運用担当者は完成後に初めて参加する人ではありません。要件定義では公開後に手作業で残る業務を確認し、設計では管理画面と権限を確認し、テストでは障害時の連絡と復旧手順を確認します。運用できない設計を納品後に引き取らないよう、開発中から会議へ参加します。

会社が管理するアカウント、ソースコード、設計資料、手順、判断記録を社内で開ける状態も必要です。将来、外注範囲を変えたり採用したエンジニアへ引き継いだりする可能性があるなら、システム内製化で先に引き取る情報と権限も参考にしてください。

候補会社との初回会議前に、空の役割表を一枚開いてください。六つの欄へ、担当者、決定範囲、回答期限、代理、次に上げる相手を書きます。

空欄へ開発会社のPMを入れる前に、社内で決める責任か、外部へ評価を頼める責任かを分けます。技術評価者がいなければ外部の専門家を候補にできますが、事業の優先順位と予算の最終決裁は社内へ残します。

初回会議では、開発会社側の担当表と役割表を重ねます。質問者、回答者、期限管理、承認記録が両社でつながれば、連絡先が一人でも開発は止まりにくくなります。

システム開発の社内体制は、人数の多さで完成しません。発注担当者が休んでも回答経路が残り、担当者の権限を超えた議題が経営者へ届き、公開後の仕事まで受け取る人が決まっている状態を作ってください。