システム開発の役職とチーム構成｜PM・PL・SE・PGの違いと、発注前に確認したい体制【図解】

システム開発の見積もりや打ち合わせでは、「PM」「PL」「SE」「PG」といった役職の名前がよく出てきます。見積書に「SE 2 人月」と書かれていても、それが何をする人なのか分からない、という方も多いと思います。

この記事では、

システム開発の主な役職と、それぞれの仕事
混同されやすい PM と PL、SE と PG の違い
チームの規模によって構成がどう変わるか
要件定義から運用まで、工程ごとに誰が中心になるか
発注する側が体制について確認しておきたいこと

を、業務システムの開発を行っている当社の視点でまとめます。

まず結論

PM（プロジェクトマネージャー）はプロジェクト全体の責任者、PL（プロジェクトリーダー）は開発チームの現場のまとめ役です
SE（システムエンジニア）は「何を作るか」を決めて設計する人、PG（プログラマー）は設計にもとづいてプログラムを書く人です
小さなチームでは、1 人が複数の役職を兼ねるのが普通です。兼任そのものは問題ではありません
発注する側にも、窓口・決める人・実際に使う人という役割があります。ここが決まっていないと、開発がうまく進みません
見積もりの段階で「誰が、どの工程を担当するか」を確認しておくと、後のトラブルを防げます

システム開発の主な役職

役職	主な仕事	ひと言でいうと
PM（プロジェクトマネージャー）	予算・スケジュール・品質の管理、発注者との調整、全体の判断	プロジェクトの責任者
PL（プロジェクトリーダー）	開発チームのまとめ、作業の割り振り、進み具合の確認、技術的な判断	現場のリーダー
SE（システムエンジニア）	要件定義（何を作るかを決める）、設計、プログラムの一部、テストの計画	設計する人
PG（プログラマー）	設計にもとづくプログラムの作成、単体テスト	作る人
テスター・QA	仕様どおりに動くかの確認、不具合の報告	確かめる人
インフラエンジニア	サーバー・ネットワーク・クラウドの設計と構築、運用の仕組み	動かす土台を作る人
デザイナー（UI/UX）	画面のデザイン、使いやすさの設計	使いやすさを作る人

会社によって呼び方や範囲は少しずつ違います。たとえば「SE」がプログラムを書く仕事まで含む会社もあれば、「エンジニア」とひとまとめに呼ぶ会社もあります。

混同されやすい 2 つの違い

PM と PL の違い

PM はプロジェクト全体に責任を持ちます。予算は足りているか、納期に間に合うか、発注者の要望とずれていないか。お金と約束を管理する立場です。

PL は開発チームに責任を持ちます。誰がどの作業をするか、技術的にどう作るか、今週の作業は予定どおり進んでいるか。作る現場をまとめる立場です。

大きなプロジェクトでは、1 人の PM の下に、画面・業務処理・データ連携などの担当ごとに複数の PL がいる形になります。小さなプロジェクトでは、PM と PL を 1 人が兼ねることがよくあります。

SE と PG の違い

SE は「何を、どう作るか」を決める人です。発注者の話を聞いて、必要な機能を整理し（要件定義）、画面やデータの形、処理の流れを設計します。

PG は「決まったものを、正しく作る」人です。SE の設計書をもとにプログラムを書き、自分の書いた部分が正しく動くかを確かめます。

見積もりで SE の単価が PG より高くなりやすいのは、要件定義や設計の出来が、システム全体の使いやすさと費用を左右するからです。単価の目安は「システム開発の費用相場」の記事にまとめています。

チームの規模による構成の違い

規模	人数の目安	よくある構成	例
小規模	2〜4 人	PM と SE を 1 人が兼ね、PG が 1〜3 人	予約・顧客管理など、1 つの業務のシステム
中規模	5〜15 人	PM・PL・SE・PG・テスターを分けて置く	複数の部署で使う業務システム、会員サイト
大規模	数十人〜	PM の下に複数の PL とチーム。インフラや品質の専門チームも	基幹システム、大きなサービス

中小企業の業務システムの多くは、小規模のチームで作られます。この場合、兼任は当たり前で、むしろ要件を聞いた人がそのまま設計と開発まで担当するので、伝言ゲームが起きにくいという良さがあります。

一方で、少人数のチームでは「その人が休むと止まる」ことが起こりえます。設計書や手順を残しているか、引き継げる人がいるかは、確認しておきたいポイントです。

工程ごとに、誰が中心になるか

システム開発は、大きく次の工程で進みます。工程によって、中心になる役職が変わります。

工程	内容	中心になる役職
要件定義	何のために、何を作るかを決める	PM・SE（発注者と一緒に）
設計	画面・データ・処理の流れを決める	SE・デザイナー
開発	プログラムを書く	PG・SE（PL がまとめる）
テスト	仕様どおりに動くかを確かめる	テスター・SE・PG
導入	データの移行、使い方の説明、本番の公開	PM・SE・インフラエンジニア
運用・保守	不具合の修正、機能の追加、サーバーの管理	SE・インフラエンジニア

発注する側がいちばん関わるのは、要件定義と、テストの最後（受け入れテスト）です。最初に「何を作るか」を一緒に決め、最後に「本当に使えるか」を自分たちで確かめる。この 2 つに時間を取れるかどうかで、システムの出来が大きく変わります。

発注する側にも「役割」がある

システム開発は、作る側だけでは進みません。発注する側にも、次の 3 つの役割を決めておくことをおすすめします。

窓口の担当者: 開発会社とのやり取りをまとめる人。質問に答え、社内の意見を集めます
決める人: 予算や仕様の変更を最終的に判断する人。社長や部門長が多いです
実際に使う人: 毎日システムを使う現場の人。要件定義とテストに参加してもらうと、「作ったけれど使いにくい」を防げます

よくある失敗は、窓口の担当者が決める権限を持たず、確認のたびに社内で止まってしまうことです。小さな会社なら、1 人が窓口と決める人を兼ねても構いません。誰が決めるのかがはっきりしていることが大切です。

見積もりの段階で確認したい、体制の 5 つのポイント

誰が担当するか: 打ち合わせに来る人と、実際に作る人は同じか。別の会社に再委託しないか
窓口は誰か: 質問や変更の相談を、誰にすればよいか
兼任の範囲: 1 人が何役を兼ねるのか。その人が休んだときはどうなるか
設計書や手順を残すか: 担当者が変わっても、引き継げる資料が残るか
公開後の体制: 不具合や機能の追加を、誰がどのくらいの早さで対応するか

これらは、会社の大きさとは関係なく確認できることです。答えがはっきりしている会社は、体制をきちんと考えている会社だと言えます。

当社の体制

株式会社Esolab は、小さなチームでシステム開発を行っています。ご要望を伺った担当者が、要件定義から設計・開発・公開後の保守まで一貫して担当するのが基本です。必要に応じて、デザインやインフラの担当が加わります。

お客様の側でシステムに詳しい方がいなくても大丈夫です。「今の業務のどこに困っているか」を伺うところから始め、作るものを一緒に決めていきます。

システム開発の相談をする（無料）

作りたいものが固まっていなくても大丈夫です。今の業務の様子を書いていただければ、体制や進め方からご提案します

よくある質問

小さな開発会社に頼んでも大丈夫ですか？

中小企業の業務システムなら、小規模なチームのほうが向いていることも多いです。要望を聞いた人がそのまま作るので、話が早く、費用も抑えやすくなります。ただし、上の「体制の 5 つのポイント」、特に担当者が休んだときの対応と、資料を残すかどうかは確認してください。

発注する側に、専門的な知識は必要ですか？

必要ありません。役職の名前や技術の言葉を覚えるより、「今の業務で何に困っていて、システムで何ができれば楽になるか」を言葉にできることのほうが大切です。分からない言葉は、遠慮なく開発会社に聞いてください。

途中で担当者が変わることはありますか？

会社によってはあります。大きなプロジェクトでは、工程ごとに担当者が入れ替わることもあります。担当者が変わっても困らないよう、設計書や打ち合わせの記録を残しているかを確認しておくと安心です。

見積書の「人月」とは何ですか？

1 人が 1 か月働く作業の量を「1 人月」と数える単位です。役職ごとの単価に人月を掛けて費用を計算します。詳しくは「システム開発の費用相場」の記事をご覧ください。

まとめ

PM は全体の責任者、PL は現場のまとめ役、SE は設計する人、PG は作る人
小さなチームでは兼任が普通。伝言ゲームが起きにくい良さがある一方、引き継ぎの備えは確認を
発注する側も、窓口・決める人・実際に使う人を決めておく
見積もりの段階で「誰が、どの工程を担当するか」と「公開後の体制」を確かめる

システム開発は、作る側と使う側が一緒に進める仕事です。体制について分からないことがあれば、お気軽にご相談ください。

システム開発のサービス内容を見る