SIer PM

SIer PMをまず「立ち位置」の軸で見ると、顧客と自社、そして協力会社という三者の結節点に置かれた役割だとわかります。顧客の情報システム部門から要望を受け、自社の開発リーダーやアーキテクト、テスト担当に作業を割り当て、不足する人員を協力会社から調達します。この三者をつなぐことが日常業務の中心になります。

担当する範囲は、プロジェクト計画書の作成から始まります。スコープ、体制図、マスタースケジュール、WBS、コスト計画、リスク一覧といった成果物を整え、顧客とキックオフで合意します。実行フェーズでは進捗会議を回し、課題管理表と変更管理表を更新し、品質指標をレビューしながら、遅延や仕様変更の影響を見積もり直します。

SES常駐との違いとして押さえておきたいのは、SIer PMが多くの場合「請負契約」の成果に責任を持つ点です。人月を提供して終わりではなく、合意した機能が動く状態で納品するところまでが守備範囲になります。そのため、見積りの前提が崩れたときにコストと納期をどう調整するかという交渉が、役割の重い部分として残り続けます。

進め方は工程の順序で見ると理解しやすくなります。多くのSIer案件はウォーターフォールに近い流れを土台に持ち、上流から下流へ成果物を積み上げていきます。近年はアジャイルや反復型を組み合わせる現場も増えていますが、契約と検収の単位が工程に紐づく点は共通しています。

入口は提案です。RFPを読み解き、概算見積りと体制案、リスクの見立てを提案書にまとめます。受注後は要求定義・要件定義で顧客の業務と実現範囲をすり合わせ、要件定義書として合意します。続いて基本設計、詳細設計、実装、単体・結合・総合テストと進み、各工程の終わりにレビューと承認を挟みます。最後に移行計画に沿って本番切替を行い、稼働後の初期対応まで見届けます。

この流れの中でPMが手を動かすのは、コードそのものよりも合意形成と調整です。工程ごとに顧客の承認を取り、変更が入れば影響範囲を設計・テスト・スケジュールに反映し直します。特に要件定義から基本設計にかけての合意が甘いと、後工程で手戻りが積み上がりやすいため、ここに時間を厚く配分する判断が問われます。

つまずきの典型を原因の軸で並べると、スコープ・見積り・体制・コミュニケーションの四つに整理できます。それぞれ崩れ方に特徴があります。

• スコープの曖昧さ
  要件定義で「やること」と「やらないこと」の線引きが弱いと、実装段階で追加要望が次々と入り、当初の見積りが合わなくなります。変更管理表で一件ずつ扱いを決める運用が効いてきます。
• 見積りの前提崩れ
  難易度や連携先システムの調査が浅いまま人月を積むと、実装で想定外の作業が膨らみます。前提条件を提案書に明記しておくと、後の交渉材料になります。
• 体制と要員のばらつき
  協力会社を含む混成チームでは、スキルや稼働状況の把握が遅れると特定メンバーに負荷が偏ります。早めの棚卸しと役割の明確化が求められます。
• 顧客との認識ずれ
  進捗の見え方が顧客と食い違うと、終盤で信頼が揺らぎます。課題管理表を共有し、悪い情報ほど早く出す運用が支えになります。

いずれも「起きてから直す」より「工程の前半で兆しをつかむ」方が痛みは小さくなります。

SIer PMを理解するには、近い立場との違いを軸に置くと輪郭がはっきりします。ここでは契約形態と責任範囲を比較の軸にします。

• SES常駐のPMとの違い
  SES PMは顧客先に常駐し、準委任の枠組みで進行を支援する形が中心です。成果物そのものより工数の提供に近く、最終的な検収責任の重さがSIer PMとは異なります。
• 社内DX推進のPMとの違い
  事業会社側で自社システムを担うPMは、発注する立場から関わります。SIer PMは受注側として、複数顧客の案件を横断しながら経験を積む点で立ち位置が反転します。
• ITコンサル系PMとの違い
  上流の構想策定や業務改革の設計に比重を置くのがコンサル寄りの役割です。SIer PMは構築の実行責任を持つため、設計から稼働までを通貫で見る度合いが高くなります。

これらは優劣ではなく責任範囲の違いです。自分がどの範囲に手応えを感じるかを見極めると、次のキャリアの方向を選びやすくなります。

SIer PMの経験は、契約・スコープ・体制・品質という重い変数を同時に扱ってきた実績として読み替えられます。この土台は、キャリアの次の一歩を考えるときに複数の方向へ展開できます。

一つは上流への移動です。要件定義や提案で顧客の業務に踏み込んだ経験は、構想策定や業務改革を担う役割に接続しやすくなります。もう一つは発注側への転身です。受注側で見積りや進行の勘所を掴んでいると、事業会社で外部ベンダーを使いこなす立場に立ちやすくなります。いずれの場合も、自分がどの工程で価値を出せたかを成果物と判断の単位で棚卸ししておくと、次の役割との重なりを説明しやすくなります。焦って肩書きを変えるより、手応えのあった範囲を軸に選ぶ姿勢が、無理のない移行につながると考えられます。

SIer PMとSES PMはどう違いますか。

SIer PMは請負契約で成果物の完成に責任を持つことが多く、要件定義から本番稼働までを通貫で統括します。SES PMは顧客先に常駐し準委任で進行を支援する形が中心で、工数の提供に近い立場です。最終的な検収責任の重さに差が出やすい点が大きな違いです。

SIer PMに求められるスキルは何ですか。

工程管理やスコープ・変更管理といった計画技術に加え、顧客と開発チーム、協力会社をつなぐ調整力が土台になります。要件定義での合意形成、見積りの前提を言語化する力、悪い情報を早く共有する運用の徹底も重要です。技術の詳細を理解しつつ、判断を言葉で残せることが問われます。

SIer PMのキャリアはどう広がりますか。

受注側で複数案件を横断した経験は、上流の構想や業務改革に軸足を移すコンサル寄りの道や、事業会社側で発注を担う社内PMへの移行に活きます。逆に構築の実行責任を深める方向で、より大規模なプロジェクトの統括に進む選択もあります。自分が手応えを感じる範囲を基準に選ぶとよいでしょう。