IT職種の関係を「家づくり」で理解する！SE・PG・インフラ・PMの役割を図解で解説

皆さんはインターネット等でIT関連の求人票などを検索した際、「SE募集」「PG募集」といった求人が並ぶのを見て、「結局、これらは何が違うんだ？現場でどう繋がっているんだ？」と疑問に感じませんでしたか？

この記事では、「注文住宅の建築」の比喩を使い、IT業界の根幹を支えるコア職種の関係性を現場目線で解説します。この比喩を使うことで、ITプロジェクトの「見えない構造」が一気にクリアになり、あなたがどこを目指すべきかが見えてきます。

IT職種の違いがわかりにくい理由

IT業界の仕事は抽象的でわかりづらいですが、その構造は私たちが知る「注文住宅の建築」と驚くほど同じです。顧客の要望を聞く人、設計図を描く人、実際に施工する人、そして土地と基礎を整える人がいる。

一般的な職種リストは、各々の役割を辞書的に説明するだけで、システムという一つの成果物を生み出すための職種間の連携や責任の境界線が見えてきません。IT初心者や未経験者から見れば、どちらも「パソコンを使って開発する人」であり、ここでつまずくのは当然です。

職種の役割を知らないと現場で方向性を見失う

もし、あなたが家づくりを任されたとして、設計士と大工と現場監督の役割が曖昧だったらどうなるでしょうか？

ITプロジェクトも同じです。職種間の関係性を理解せずに入社すると、役割の境界線が曖昧な混乱した現場に放り込まれ、キャリアの方向性を見失うことになりかねません。

まずは、現場のコアを担う4大職種の関係性を明確にします。

ITプロジェクトを支える4大コア職種の関係

ここで紹介するSE、PG、インフラという役割は、プロジェクトにおける「責任の区切り」を示したものです。

実際の現場では、特に小規模な会社やプロジェクトでは、一人のSEがプログラミングやインフラの設定を兼務することも少なくありません。

関わる人数が少ないほど認識のズレが生まれにくく、品質が上がりやすいという側面もあります。一人で全工程を担うのが最も品質が高い形ですが、その分対応できる範囲に限界があり、範囲を広げればスケジュールが伸びるというトレードオフがあります。

まずはこの基本的な「責任の設計図」を理解することが、キャリアをブレさせない土台となります。

SEは上流工程の設計図を作る責任者

SEは、「設計士」の役割を担います。顧客からヒアリングした要望を整理し、ユーザー向けの基本設計から、プログラマー向けの詳細設計まで、システム全体の「設計図（仕様書）」を作成するのが仕事です。

この設計図が、後のプログラマーの作業効率とシステムの品質を決定づけます。SEの仕事は「コードを書くこと」ではなく、「正しく考えること」にあります。

では「正しく考える」とは、具体的にどういうことでしょうか。例えばWEBシステムだと「同時実行」の考慮があります。

詳細設計でよく作成されるシーケンス図では1リクエストの流れを記述しますが、実際には複数ユーザーが同じ処理を同時に実行しますし、同じユーザーが同じ処理を二重に実行してしまうケースもあります。

そのため、アプリケーションが複数同時に動いても問題ないか、DBの排他制御やロックなど関連するリソースへの影響がないかなどシーケンス図から想定し、設計する必要があります。さらに夜間バッチや管理者向け機能が裏で動いていることも多く、それらとの干渉を最小限に抑える設計も求められます。

PGは設計図をコードに変換する実装担当者

PGは、SEが作成した「詳細設計図」に基づいて、実際にコードを書き、システムを形にする「施工職人」です。

設計書の意図を正確に読み取り、バグのない堅牢なコードを書き上げることが求められ、正確性とスピードが求められる仕事です。

インフラエンジニアはシステムの土台を支える職人

インフラエンジニアは、家（システム）を建て、住み続けるための「土地、基礎、電気、水道といったライフライン」を構築し、保守する職人です。

サーバー、ネットワーク、セキュリティ基盤など、システムが「動いて当たり前」の状態を裏側で支えています。また、セキュリティ対策の土台作りや、リリース方法といった職種横断的な運用設計の基盤づくりも含まれます。

ここで一つ注意しておきたいのが、近年のクラウド普及によって生まれた誤解です。クラウドの登場でインフラは以前より簡単に構築できるようになりました。しかし「画面からぽちぽち操作するだけ」で立ち上げた環境は、設定変更の履歴が残らず再現性もないため、構築した本人さえ後から触れなくなることがあります。

設計を省いてスピード重視で構築した環境は、変更時の影響範囲が把握できず、最悪の場合インフラ全体を止めるような障害につながりかねません。

クラウドになって変わったのは、ハードウェアの調達や物理的な設置作業がなくなったことです。インフラ設計そのものの重要性は何も変わっていません。インフラが止まればシステム全体が止まる。短時間であっても止めてはいけない領域だからこそ、設計を省くことは許されません。

PMはプロジェクト全体を管理する現場監督

PMは、工務店の社長や現場監督にあたります。顧客の要望と予算、納期を調整し、SE、PG、インフラといった職人たちをまとめ、プロジェクト全体の成功に責任を負います。

主に管理、調整、意思決定を担い、SEやPGが目指すキャリアの管理職側のゴールとなることが多いポジションです。

PMに求められる役割は、SEやPGとは大きく異なります。SEからPMになると、技術判断の目的が「設計・実装のため」から「意思決定・リスク管理のため」へとシフトします。

コスト面では人の管理が重要になり、SEとしてはあまり意識してこなかった領域に向き合う必要があります。スケジュール面では、アプリやインフラといった個別領域だけでなく、システム稼働までに必要なすべての要素を把握し全体を調整する視点が求められます。

常にチームより一歩先を見越して、マイルストーンを定義し、チームが迷わず進めるよう進路を確保することがPMの仕事です。

初めて聞くと難しく感じるかもしれませんが、経験を積みPMの仕事を意識しながらプロジェクトに関わっていくと、いつかこれらの作業が頭の中でイメージできるようになります。着実に経験を重ね、自分ができる領域を広げていくことが、その日への近道です。

4大コア職種の役割を一覧で確認する

家づくり（比喩）の工程	IT開発のプロセス	主な担当者（コア職種）	SEが作る主要な成果物
1. 土地の選定と契約	企画・要件定義	PM / 顧客	ビジネス要件の確定
2. 基本設計図の作成	基本設計（外部設計）	SE (PMも関与)	基本設計書 (画面仕様、機能一覧)
3. 詳細設計図の作成	詳細設計（内部設計）	SE	詳細設計書 (データベース、処理手順)
4. 地盤とライフライン整備	インフラ構築・運用設計	インフラエンジニア	サーバー構築、ネットワーク設定、運用マニュアル
5. 建築作業の実施	プログラミング・実装	PG	ソースコード、単体テスト結果
6. 検査・引き渡し	テスト・リリース	QA / 全員	総合テスト報告書、システムリリース

コア職種から派生する専門支援職一覧

以下はコア職種を土台に派生する専門職です。興味のある分野への入口として参考にしてください。

職種名	主な役割	キャリアの土台となるコア職種
ITコンサルタント	IT戦略に基づき、企業の経営課題を解決するためのシステムの企画・提案を主導する。	PM / SE
バックエンドエンジニア	サーバー側で動作するデータベース処理やビジネスロジックの開発を専門に担う。	PG
フロントエンドエンジニア	Webサイトやアプリのユーザーに見える部分（画面操作やデザインの動き）を専門に開発する。	PG
サーバーエンジニア	システムの土台となるサーバー（OSやミドルウェア）の設計、構築、運用を専門に行う。	インフラ
ネットワークエンジニア	サーバー同士をつなぐネットワーク（回線、ルーターなど）の設計・構築・運用を専門に行う。	インフラ
スマホアプリエンジニア	iOSやAndroidで動くネイティブアプリの開発を専門に担う。	PG
データベースエンジニア (DBA)	システムの心臓部であるデータの格納庫の設計、構築、管理を専門に行う。	SE / インフラ
データサイエンティスト	収集したデータを統計や機械学習で分析し、ビジネスの課題解決を行う。	SE / PM
AIエンジニア	人工知能（AI）や機械学習モデルを開発し、システムに組み込むことを専門とする。	PG / SE
セキュリティエンジニア	情報セキュリティに配慮した設計・構築、サイバー攻撃への対策など、システムの安全を守る専門家。	インフラ / SE
QAエンジニア	品質保証の専門家。テストの計画から実施、改善までを担い、製品の品質を担保する。	全職種
Webディレクター	WebサイトやWebサービスの企画、制作、進行管理など、クリエイティブな開発を指揮する。	PM / SE
セールスエンジニア	営業に同行し、技術的な側面から顧客への提案やデモンストレーションを行う。	SE
社内SE/情シス	外部の顧客ではなく、自社のITシステムやインフラの管理・戦略的な活用を担う。	インフラ / PM

SEやPMを目指すPGが今日からできること

未経験者がSEやPMへ進むために必要なスキル

未経験者は、まずPGやテスターといった「施工」のフェーズからキャリアをスタートすることが多いです。

AIがコードを生成する時代になっても、プログラミングスキルはシステムを理解するための共通言語であり、設計図の意図を正確に読み解き、生成されたコードをレビュー・修正する「PGの力」は不可欠です。

その上で、SEやPMといった「設計」や「管理」のポジションを目指すなら、コードスキル以上に重要な現場の「暗黙知」を身につける必要があります。

① 設計書に書かれていないことを察知する力

設計書にすべてが書かれているとは限りません。設計書には設計者が想定している運用の前提条件や制約が潜んでいることがあります。

たとえば「A機能は夜間バッチで更新」と一文書いてあっても、「夜間とは何時から何時？」という前提を理解していなければ、バグの原因になる可能性もあります。

実装上の考慮が必要な点は、必要に応じて設計者にヒアリングする習慣を持ちましょう。「書いてあること」だけでなく「書いていないこと」を察知できるPGは、上流から信頼されます。

② 運用・保守を見据えてシステムを設計する力

システムは構築後に必ず運用・保守フェーズに入ります。その時に正確かつ迅速に対応できるような設計を意識することが重要です。

たとえば障害発生時にエラーハンドリングで出力した情報が担当者にわかりやすく通知されるか、バッチ処理の障害時に原因排除後は単純にリランでリカバリできるか、といった観点を設計段階から意識する習慣を持ちましょう。

将来の保守・改修を見据えて「この設計は運用担当者が読んで理解できるか」を問い続けることが、上流工程への近道です。

今の職場から始められる上流工程への準備

上流工程に行くために転職する必要は必ずしもありません。まずは隣のSEの目線を借りることから始めましょう。

設計書レビューや障害分析の場に混ぜてもらい、「なぜそう決めたのか」を観察することが最初の訓練になります。

設計者を目指すPGが今日から持つべき思考習慣

設計者になるのは、才能ではなく視点の切り替えです。コードを書く前に「なぜこの仕様なんだろう？」と一度考える癖をつけることが、上流工程への入口になります。

まとめ：職種の関係を理解することがキャリアの第一歩

「家づくり」の比喩で見れば、IT業界は決して難しい世界ではありません。PM、SE、PG、インフラの連携という基本構造を理解することで、職種間の連携と責任の境界線が見えてきます。

「自分は設計に向いているか、施工に向いているか？」

この問いへの答えこそが、あなたのキャリア設計の第一歩です。この知識を羅針盤に、あなたの理想とするキャリアの「家」を築いていきましょう。