監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
ITプロジェクトマネージャー（IT PM）は、システム開発やIT導入を対象に、要件定義から設計・開発・テスト・本番移行までの進行に責任を持つ役割を指します。QCD（品質・コスト・納期）とスコープを管理し、開発チーム・ベンダー・業務部門の間に立って、合意された計画どおりに成果物が動く状態まで持っていくのが主な仕事です。
IT PMの軸は「決めること」と「ずれを早く見つけること」の二つに整理できます。プロジェクト計画書で体制・スコープ・マイルストーンを定義し、WBSとガントチャートで作業を分解して、進捗・課題・リスクを定期的に点検していきます。開発そのものを手で動かすというより、開発が止まらない状態を保つ役割です。
関わる相手は幅広く、発注側の業務部門、社内の情報システム部門、開発を担うベンダーやエンジニア、品質やセキュリティを見る担当などが並びます。IT PMはその中心で合意を取り、決定事項を文書に残していきます。具体的な守備範囲は次のように分けられます。
どこまでを自分の責任範囲とするかはプロジェクトごとに異なり、着任時にスコープと権限を確認しておくと後の混乱を減らせます。
ウォーターフォール型を例にすると、IT PMは工程ごとに異なる成果物を押さえながら進めます。軸は「何を確定させ、次工程に何を渡すか」です。まず要件定義で業務部門と要件定義書をまとめ、やりたいことと作るものの境界を言語化します。ここが曖昧なまま進むと、後工程で手戻りが膨らみやすくなります。
続く基本設計・詳細設計では、エンジニアと設計書をレビューし、要件との対応が取れているかを確認します。開発・単体テストのあとに結合テスト、システムテストへと進み、最後に業務部門が受け入れテストで実運用に耐えるかを判定します。IT PMは各工程の入口と出口で「前提がそろっているか」「次に進んでよいか」を判断する立場です。
工程を動かすうえで、IT PMが特に目を配るのは次の点です。
アジャイル型の場合は工程が反復に変わり、スプリントごとに優先順位を見直す進め方になりますが、合意を取り成果物を確定させるという役割の芯は変わりません。
IT PMがつまずく形には、ある程度のパターンがあります。軸は「人・スコープ・技術」の三つで見ると整理しやすくなります。
人の面では、業務部門と開発側で「同じ言葉で違うものを指している」状態が起きがちです。要件定義の段階で画面やデータの具体で擦り合わせず、文章の了解だけで進むと、受け入れテストで初めて認識差が表面化します。議事録と決定事項の記録を残し、誰が何に合意したかを辿れるようにしておくと、後からの蒸し返しを抑えられます。
スコープの面では、小さな追加要望が積み重なって当初計画からずれていく、いわゆるスコープの膨張があります。一件ずつは小さく見えても、変更管理を通さずに受けていくと、納期と工数が静かに崩れていきます。技術の面では、非機能要件（性能・可用性・セキュリティ）の確認が後回しになり、システムテストの終盤で問題が出る形が典型です。
いずれも共通するのは、問題が小さいうちに見える仕組みを作れているかどうかです。進捗を「予定どおり」という自己申告ではなく、成果物の完成度で確認する習慣が、後半の炎上を減らす助けになります。
IT PMと近い職域には重なりがあり、軸を「立ち位置」と「主な成果物」で分けると違いが見えます。
SIerのPMは、受託開発の請負側に立つことが多く、契約したスコープ・納期・品質を守りながら自社やパートナーの開発チームを率いる点に重心があります。成果物はシステムそのものと、それを支える各種設計・テスト文書です。一方でITコンサル系の役割は、どちらかというと発注側や経営に近い位置から、何を作るべきか、どう業務を変えるかという上流の論点設計に重きを置く場合があります。
IT PMはその中間から現場寄りに位置し、決まった方針を実際に動くシステムとして着地させる実装・進行の責任を担うことが多い役割です。次のように整理できます。
ただし現場では一人が複数の役割を兼ねることも多く、肩書きよりも「自分がどの責任を持つか」を確認するほうが実態に合います。
IT PMの経験は、PMキャリアの土台として応用範囲が広い部類に入ります。要件定義で業務部門と論点を擦り合わせた経験、変更管理やリスク管理で炎上を抑えた経験は、業界が変わっても通用しやすい技術です。職務経歴書に書くときは、担当したプロジェクトの規模や役割だけでなく、どの工程でどんな判断をし、何を成果物として残したかまで具体的に書くと、再現性のある力として伝わりやすくなります。
次の一歩としては、上流のコンサル寄りに重心を移す道や、DX推進のように業務変革まで踏み込む道、アジャイル型の開発を率いる道などが考えられます。いずれも、現在のプロジェクトで「自分がどの責任を持っているか」を言語化しておくことが、次の役割を選ぶときの手がかりになります。
ITプロジェクトマネージャーとプロジェクトマネージャーは違いますか。
プロジェクトマネージャーという役割の中で、対象がシステム開発やIT導入に特化したものがIT PMです。計画・進捗・品質・リスクを管理するという基本は共通し、要件定義書や設計書、テスト計画といったIT特有の工程と成果物を扱う点が特徴になります。
IT PMにプログラミングの経験は必要ですか。
必須とは言い切れませんが、設計やテストの内容を理解し、エンジニアと会話できる程度の技術的な素地があると進めやすくなります。自分で実装する役割というより、見積もりや課題の深刻度を判断するために、技術の勘所を持っておくと判断の精度が上がります。
IT PMはどんな成果物で評価されますか。
プロジェクト計画書やWBS、課題・リスク管理表、テスト計画などの管理面の成果物に加え、最終的には合意したスコープが本番で動く状態まで届いたかで見られることが多いです。進行中は、遅れや論点をどれだけ早く可視化できているかも評価の対象になります。