システム開発の役割分担？発注者が知るべきプロジェクト体制作りのポイントを解説【2024年最新版】

システム開発プロジェクトが始まると、開発会社（ITベンダー）側にはプロジェクトチームが発足します。システム開発会社の体制図にはPM、PL、SEなど、さまざまな立場のエンジニアが登場しますが、「誰が何の役割を担っているかよくわからない」という人もいるのではないでしょうか。

この記事は、大手通信会社の情報システム部に6年間勤務した筆者が、一般的なシステム開発の体制やメンバーの役割、作業分担表や体制図の重要性について解説します。

役割分担が曖昧なプロジェクトは、頓挫しやすい傾向にあります。きちんとした開発体制を組んでくれるシステム開発会社を選びましょう。

※信頼のおけるシステム開発会社を探している方は、ぜひシステム幹事にお気軽に相談ください。プロジェクト規模に適した体制を組めるシステム開発会社をご紹介します。相談料や紹介料は一切かかりませんので、ご安心ください。

【無料】自社の規模にあったシステム開発会社を紹介してもらう

覚えておくべきシステム開発のメンバーの名称と役割

ここでは、一般的なシステム開発プロジェクトに登場する以下の役割を説明します。
・プロジェクトオーナー（PO）
・プロジェクトマネージャー（PM）
・プロジェクトマネジメントオフィス（PMO）
・プロジェクトリーダー（PL）
・サブリーダー（SL）
・システムエンジニア（SE）
・プログラマー（PG）

プロジェクトオーナー（PO）

プロジェクトの最高責任者。発注者（顧客側）に置かれるポジションです。社内プロジェクトの場合、お金や人を投入するスポンサーを兼ねていることがほとんど。

中小企業では社長や役員がなることが多く、忙しくてプロジェクトにはあまり関わらないケースも。しかしできればプロジェクトオーナーの役割も担い、プロジェクトの目的や経営戦略をメンバーにしっかり伝えたほうが、プロジェクトが進めやすくなります。

プロジェクトマネージャー（PM）

プロジェクトを円滑に推進するための執行責任者で、よくプロマネと略されます。システム開発会社と発注者（顧客側）に置かれ、協力してプロジェクトを進めます。お金や人のリソースを割り当て、スケジュールを調整し、リスクや品質を管理をしながら、QCD（※）の達成を目指します。

※QCD：Q（Quality/品質）、C（Cost/価格）、D（Delivery/納期）の頭文字をとったプロジェクトの管理項目。

会社によってはPMの責任ばかりが重く、リソースやスケジュールを決める権限がほとんど与えられていないことも。責任ばかりを押し付けられては、PMもやる気を失ってしまうので、そういうプロジェクトはうまくいきません。

PMにはコミュニケーション力や交渉力、統率力が必要です。発注者（顧客側）や社内の要求をのんでばかりいては、プロジェクトとしての方向性が定まらず、スケジュールにも無理がでて、メンバーが疲弊してしまいます。PMに向いているのは、全体を俯瞰してみる鷹の目と、細部を見逃さない蟻の目、どちらも持ち合わせている人。PMの実力によってプロジェクトの成否が決まるといっても過言ではない重要なポジションです。

プロジェクトマネジメントオフィス（PMO）

複数のITベンダーが関係するマルチベンダー案件のような大規模システム開発の場合に、発注者（顧客側）に置かれることが多いポジションです。プロジェクトマネージャーの迅速な意思決定を支援・サポートするのが役割。

具体的には、各チームからの作業進捗報告書の収集や整理、各種ルール策定（コミュニケーションルール、資料フォーマット統一など）をします。
発注者が大規模なシステム開発に不慣れな場合やプロジェクトの人員が足りない場合は、コンサルティング会社などにPMOを外注するケースもあります。

プロジェクトリーダー（PL）

システム開発会社側で、実際にプロジェクトを実行していく現場責任者です。設計やプログラミングなど、開発の進捗状況を管理します。

大きなプロジェクトでは、アプリケーションやインフラといった分野単位や、受注管理や発注管理など機能単位に分けて、複数のプロジェクトリーダーを置くこともあります。

サブリーダー（SL）

システム開発会社側で、プロジェクトリーダーをサポートする役です。
数名～10名程度のプロジェクトであれば1人、数十名規模の大きなプロジェクトでは複数のサブリーダーが置かれることもあります。

システムエンジニア（SE）

システム開発会社側で、システムの設計・開発をする人です。
顧客にヒアリングをして業務要件を整理し、基本設計書や詳細設計書を作ります。技術力だけでなく、コミュニケーション能力も必要です。
実際のプログラミングは次に紹介するプログラマー（PG）が行います。

関連記事：システム開発の詳細設計とは？プロジェクトの位置付け・役割をわかりやすく解説！

プログラマー（PG）

システム開発会社側で、SEが作成した仕様書や設計書に基づいて、実際にプログラミング（プログラムを書く）人です。プログラム言語としては、業務システムではJavaやC系、WebシステムではPHPやPythonがよく使われます。なお、プログラミングは受注したシステム開発会社が別会社（下請け）に再委託しているケースも少なくありません。

営業

システム開発会社の営業担当は、発注者との連絡の窓口となります。発注者からの要望を持ち帰り、開発チームへ展開したり、契約全般に関わる業務を行ったりします。

システム開発の体制図を作るべき理由

POやPMなどの用語は、プロジェクトの体制図の中で目にします。表記がアルファベットの略語のみということもあるので、意味を知っておくと理解が深まります。体制図を作るメリットはいくつかあります。

役割や指揮命令系統を定義できる

発注者とシステム開発会社を合わせた体制図を作成しておくと、誰がどの仕事を担当するか、ひと目でわかり便利。指揮命令系統が曖昧にならず、情報共有もスムーズです。開発側の体制を決めるのは、システム開発会社です。体制図には具体的な担当者名も記載してもらいましょう。

責任者を上、担当者を下に、階層的に書いた体制図は見やすい反面、細かな役割を表に書き込みづらいのが難点。
ポジションと具体的な役割、担当者名を別の役割表にまとめておくのもおすすめです。

開発プロジェクト体制が見える化されて評価できる

体制図は、メンバーのスキルやチームの人数も併記または別表でまとめてもらうと、十分なスキルを持ったエンジニアによってプロジェクト体制が組まれているかを確認できます。

時々、同一人物が複数の役割を兼務していることもあり、それ自体は問題ありませんが、実際に業務を回せるレベルなのか、無理な体制になっていないかを確認する必要はあります。体制図があれば、途中の体制変更の管理も容易。内容は随時アップデートし、常に最新状況を共有します。

丸投げは「ベンダーロックイン」のリスクもある

システム開発会社にすべて丸投げしてしまうと、そのIT会社独自の技術などを盛り込まれ、次回以降もそのシステム開発会社（ITベンダー）に発注せざるをえないことも。これを「ベンダーロックイン」と呼びます。

システム開発会社は業界ごとにチームを組んでいることも多く、基本的な業務知識は持ち合わせていますが、各社の細かな業務ルールは把握していませんから、丸投げでは最適なシステムは作れません。業務要件定義や各種成果物のレビュー（品質を満たしているかの確認・審査）、受入テストなどには、発注者が責任をもって取り組みましょう。

ベンダーロックインの詳細は下記記事をご参照ください。
関連記事：ベンダーロックインとは｜放置すると搾取のリスク！対策方法も紹介

※開発体制が整っているシステム開発会社を探している方や、外注時の自社の役割が気になる方は、ぜひシステム幹事にお気軽に相談ください。プロジェクトに最適なシステム開発会社を無料でご紹介します。

【無料】安心な開発体制のシステム開発会社を紹介してもらう

システム開発の役割分担表作成のポイント

システム開発では体制図のほかに、役割分担表も作成します。トラブルがあったとき、発注者（顧客側）とシステム開発会社のどちらに責任の所在があるが明確にでき、それぞれの担当者が責任をもって作業を進めることができます。

フェーズごとに必要な作業の担当を決める

役割分担表では、フェーズごとの作業を洗い出し、担当が発注者（顧客側）かシステム開発会社かを明確にしておきます。発注サイドとシステム開発会社の役割分担が曖昧だと、あとから「これもウチがやるの？」「そっちの仕事じゃないの？」などもめる原因になります。なお、それぞれの作業項目の時期や期間を表すスケジュール表は別途作成します。

どちらか一方が担当するのではなく、両者が協力し合って作業をする項目も多いので、メイン担当とサブ担当というような意味で、「主体」と「支援」などで分けて表現されることもあります。要件定義のとりまとめ、各種成果物のレビュー（品質を満たしているかの確認・審査）や、進捗や課題管理、受入テストが主な発注者の役割です。

細かな担当者まで書くのもアリ

「主体」や「支援」は、役割分担表でよく使われる表現ではあるものの、言葉の意味に曖昧さがあり、トラブル時に問題になることもあります。既存の定型にとらわれず、工程ごとの具体的な成果物や実際の担当者名（○○会社xx）などまで記載するのも一案です。

システム開発における発注者の役割と責任

システム開発会社は上記のように、それぞれの役割で名称を使いわけ、プロジェクトごとに最適な体制図を組んできます。システム開発というと、システム開発会社が主役に思えるかもしれませんが、発注者（顧客側）でもはたすべき役割や責任があります。

「協力義務」がある

システム開発の裁判例としては、発注後の度重なる仕様の変更・追加、さらにプロジェクトへの協力不足から裁判で敗訴し、システム開発会社へ多額の支払いを命じられた事例もあります。近年の判例では、システム開発会社にはプロジェクトマネジメント義務、発注者には協力義務があるとする凡例が多くなっています。

協力義務とは、発注者側が主体的に内部の意見調整を行う、社内の見解を統一して要望をベンダーに伝える、リスク分析を行う、成果物を確認する、ベンダーからの協力要請に応じる姿勢を示す、等のことを指します。

業務要件のとりまとめ（要件定義）が最重要

システム化の計画は発注サイドの仕事です。発注者は既存の業務を見直し、何をシステム化したいかという「業務要件」を確定させます。発注者のITや情報システムの担当者は、実際にシステムを利用する業務部門に課題や要望をヒアリングし、要件を詰めていく必要があります。

ここが不十分だと、あとから「そういえば、これも…」とか「これだと使いづらい」など業務部門から五月雨式に要求が出てきかねません。基本的に契約後の仕様変更は別料金です。たとえば「入力データの制限文字数を増やしたい」といった程度の要望でも、改修には数十万かかることもありますから、精度の高い業務要件を定義することが重要です。

要件定義の重要性や外注時の進め方については、下記記事にてくわしく解説していますので、ご参照ください。
※関連記事：システム開発の要件定義とは？受託開発における重要性や進め方を解説！

発注者はレビュープロセス・担当者を明確にしておく

これを決めておかないと、いざそのタイミングになって「誰がやるんだ？」という話になってしまいます。社内調整に時間がかかると、システム開発のスケジュールが遅れてしまいます。

あらかじめレビュープロセス（設計書やマニュアルなどの成果物が品質を満たしているかの確認・審査のフロー）やレビュー担当者、承認担当者を明確にしておくとよいでしょう。

受入テスト（UAT）を実施しなければならない

受入テスト（UAT/User Acceptance Test）とは、開発されたシステムが、最終的に要望どおりに正しく構築され、問題なく稼働するかを見極めるテストです。検収したシステムの不具合が稼働した後に見つかることがあります。プログラム不良（バグ）であればシステム開発会社に責任がありますが、単純に受入テストで発注者が要件を満たしていないことを見逃していたのであれば発注者の責任です。

受入テストには主体的に参加して、検証・評価をしてください。たとえば、新しい顧客管理システムを開発した場合、新システムでは「新規顧客登録」「既存顧客の住所変更」「顧客情報削除」など、さまざまな業務が行われます。

受入テストでは、すべての業務が問題なく処理できるか、もれなくテストをする必要があります。また、テストすべき項目や手順をまとめたテストケースを用意する必要があります。テストケースの洗い出しには、実際にシステムを使うユーザー（業務部門）の協力が欠かせません。

【まとめ】機能する体制を作れるシステム開発会社に任せよう

開発に必要十分な体制を整えてくれるかどうかも含めて、間違いのないシステム開発会社を選ぶには、事前にしっかり比較検討をすることが大事です。自社内でシステム開発会社の評価基準が確立していない場合は、システム幹事にお気軽にご相談ください。

お客様のプロジェクトに適した開発体制の規模をお伝えし、それを準備できるシステム開発会社をご紹介します。

【無料】プロのアドバイザーにおすすめのシステム開発会社を紹介してもらう