発注側と請負側のPM、PMOの違いとは？実際の役割

ITプロジェクトでは、開発規模・開発体制によって、プロジェクトマネジメントの体制が変わってきます。
マルチベンダー体制のプロジェクト、またはシングルベンダー体制のプロジェクトでも発注側で複数の部署が関わるような場合は、発注側にもPM、PMOの役割が必要になります。
この時、発注側のPM、PMOの役割と、請負側＝ベンダー側のPM、PMOの役割にはどのような違いがあるでしょうか。
JQでは、発注側PM、PMOと請負側のPM、PMOの役割の違いを理解したうえで、双方の協力関係を築くことが、プロジェクトの成功確率を向上させると考えています。

発注側と請負側のPM、PMOの責任範囲の違い

発注側と請負側のPM、PMOの違いを理解するために、まずそれぞれの役割を整理しましょう。

請負側のPM、PMO：

• 自社が請け負ったスコープのQCD（品質、コスト、納期）に責任を持つ

発注側のPM、PMO：

• プロジェクト全体のQCD（品質、コスト、納期）に対して責任を持つ
  複数のシステムを開発する場合、すべてのシステムがトータルでしっかり動くかどうかに責任を持つということです

発注側と請負側のPM、PMOの役割の違い

責任範囲の違いから、発注側と請負側のPM、PMOの役割には以下のような違いがでてきます。プロジェクトマネジメント業務の３つの分類、計画実務、管理実務、推進実務、それぞれの観点で見ていきたいと思います。

計画実務：

• 請負側
  自社の開発スコープ・作業スコープに基づいて、スケジュール、体制を組みます。
  • スコープ
    仮に開発スコープがあいまいなものがあっても、積極的な検討はしません。
    また作業スコープも自社のスコープの境界線を明らかにして、それ以上のことはやろうとしません
  • スケジュール
    自社の開発スケジュールだけを考えます
  • 体制
    自社の作業範囲のみを考えた体制を組みます

請負で契約をしている以上、スコープを超えた作業を行うと、赤字になってしまうため、このように動くのは当然といえるでしょう。

• 発注側
  プロジェクトの対象となる全システム・作業を対象に、スケジュール、体制を組みます。
  • スコープ
    １つ１つのシステムの開発スコープだけでなく、システム間の開発スコープを定めようとします。あいまいなものがあれば、どのシステムが担当するか、クリアにする必要があります。
  • スケジュール
    プロジェクトの全体のスケジュールを考えます。１つのシステムだけでなく、全体として整合がとれたスケジュールを組みます。
  • 体制
    特に業務部門など、ベンダー側ではない体制も含めて、プロジェクト全体の作業を前提とした体制を組みます。例えば、宙に浮きやすいタスクも、誰が担当するのかを明らかにするようにします。

プロジェクト全体の成功に責任を負っているので、計画実務も、プロジェクト全体の視点で整理する必要があります。

管理実務：

• 請負側
  自社のQCDを守るための管理を行います。
  • 進捗管理、品質管理
    自社内のプロセス・ルールに沿った進捗管理や品質管理を行います。その会社独自の進捗報告書のフォーマット・内容での報告、独自の品質基準に沿った品質の分析、報告を行います。
  • 課題・リスク管理、変更管理
    自社の開発・作業スコープの範囲内の課題やリスク、変更の管理を行います。自社のスコープを超えるものは、取り扱いません。

発注側PM/PMOからの指定や取り決めがなければ、請負側は独自のやり方で管理をします。請け負っている範囲で、最適化された管理をするのが最も効率的なので、当然といえるでしょう。

• 発注側
  プロジェクト全体のQCDを守るための管理を行います。
  • 進捗管理、品質管理
    プロジェクト全体の進捗や品質の状況把握が必要なため、複数のシステム・チームが従う共通のプロセス・ルールを整備し、運用します。例えば、報告書の基準となる期間がばらばらでは、正しい進捗状況がわからなくなってしまいます。また、品質基準もバラバラだと、どのシステムの品質がいいのか、悪いのかがわからなくなってしまいます。
  • 課題・リスク管理、変更管理
    プロジェクト全体の課題やリスク、変更の管理を行います。複数のシステム・チームをまたいだような課題やリスク、変更について取り扱います。

発注側PM/PMOは管理実務も全体の目線で行うため、共通的なプロセス・ルール、横断的な検討を行う必要があります。

推進実務：

• 請負側
  自社の請負範囲内での課題解決・リスク対策を行います。
  • 課題解決
    例えば、自社の請け負っている範囲で、チーム間のスコープがあいまいな点は積極的に解決していきます。また、対向システムがあれば、その対向システムとの機能分担・インターフェースについては、自社のスコープに影響を与えるので解決をしようとします。しかし、対向システムの先のシステム含めた機能やインターフェースの最適化までは考慮しません。
  • リスク検知・対策
    自社の開発・作業スコープの範囲内でリスクを検知し、必要な対策を取ります。例えば、あるチームの進捗が繰り返し遅れる場合、チームリーダーや要員の変更・追加などの対策を取ります。しかし、対向システム側も同様に遅延を繰り返していたとしても、それを察知しても、特に対策はとりません。

• 発注側
  プロジェクト全体の課題解決やリスク対策を行います。
  • 課題解決
    複数のシステムにまたがるスコープの調整、業務側とベンダー側の作業スコープの解決などを積極的に行います。
  • リスク検知・対策
    １つのシステムやチームの遅延が他のシステムやチームにどのような影響を与えるか、どのような対策を取るべきか、というように全体目線でのリスク検知と対策を考えます。

体制図上の発注側PMと実際の役割の違い

プロジェクトの体制図では、発注側の部課長クラスの社員がPMとして記載されることが多いです。

ではその社員が全体のスケジュールを引くのかというとそうではありません。
あくまで体制図上のPMだからです（もちろん一概には言えず、スキルがある人は計画実務もできるかもしれません）。

仕事・役割としてのPMはどこにいるかというと、体制図上は発注側のPMO（多くの場合、全体PMOと呼ぶ）にいます。全体PMOのチームの中で、計画・推進実務、管理実務を分担して行うことになります。

発注側の社員のPMは何をするかといえば、全体PMOがまとめた計画案や課題解決案に対して、それでいいかどうかを意思決定します。もし、スケジュールが大幅に遅延する、予算が超過しそう、などのプロジェクトオーナー（PO）への共有・承認事項があれば、その調整をするのも発注側の社員PMになります。

全体PMOでPM的仕事をする人は、社外であることが多いので、やはり発注者として意思決定してくれる人、社内調整をしてくれる人は重要です。

まとめ

発注側のPM、PMOであっても、請負側のPM、PMOであっても、仕事・役割という軸で考えれば、大きくはやることは変わりません。計画を立てて、管理をして、推進をするというプロジェクトマネジメントをする仕事です。

しかし、
・請負側は自分たちの請け負った範囲で
・発注側は請負側のスコープも含めて全体に対して
プロジェクトマネジメントを行います。

どんな巨大なプロジェクトであっても、この考え方の原則は変わりません。
皆さんのプロジェクトでも、仕事・役割としてのPM、PMOはだれが担っているかを見てみましょう。もし誰も担っていないとしたら、自分が手を挙げてやるか、必要性をPOに訴えるか、何かしたら対応をする必要があります。

体制図の呼称に惑わされず、責任範囲、仕事内容・役割の観点で、誰が何をするべきかを整理し、適切な人物をアサインすることで、プロジェクトが円滑に推進されるようになります。