発注者側PMOとは？ベンダー側PMOとの違いと発注側に立つ外部支援の活用法

「ベンダー側にはPMOも立っているし体制は整っているはずなのに、プロジェクトの本当の状況がこちらからは見えない」。システム開発を外部委託した情シスやDX推進の担当者が、一度は突き当たる違和感だと思います。僕自身、周りの経営者からシステム開発の発注に失敗した話を数え切れないほど聞いてきました。結論から言うと、その違和感の正体はベンダー側PMOと発注者側PMOの守備範囲の違いにある。ベンダーのPMOは受注したスコープを管理する存在であって、発注側の意思決定や社内調整までは面倒を見てくれません。この記事では、受注側のPMと発注側の支援、両方に立った僕の経験をもとに、発注者側PMOの役割とベンダー側PMOとの違い、丸投げが破綻する構造、発注側に立つ外部支援の使い方までを整理します。

発注者側PMOとは、システム開発やDXプロジェクトにおいて、発注企業の側に立ってプロジェクト推進を支える機能のことです。具体的には、要件のインプット、社内の合意形成と意思決定の推進、ベンダーからの質問への回答管理、進捗・品質の発注側視点での見える化といった「発注者にしかできない仕事」を回すための役割。社内メンバーが担う場合もあれば、外部のPMO支援会社が発注側の席に座る場合もあります。

「PMOはベンダーが立てるもの」というイメージは根強いと思います。実際、SIerに開発を委託すれば、ベンダー側の体制図にはたいていPMOが入っている。ただ、そのPMOが管理しているのは受注した範囲、つまり開発チームの進捗・品質・課題であって、発注側の社内で起きていること——部門間の意見対立、決裁の遅れ、要件の伝達漏れ——は管理対象の外です。ここを勘違いして「PMOがいるから大丈夫」と構えてしまうのが、後で述べる丸投げの入口になります。

なぜ今、発注者側PMOが必要とされるのか。理由はシンプルで、プロジェクトの成否を左右する仕事の多くが、発注側にしか実行できないからです。要件を決めるのも、業務を変えるのも、投資判断をするのも発注者。開発プロジェクトの7割は上流で決まると僕は考えていますが、その上流へのインプットの大半は発注側からしか出てきません。ベンダーがどれだけ優秀でも、インプットが出てこないプロジェクトは前に進まないんです。

僕はシンプレクスで受注側のPMを4年間やり、独立後は大手外食チェーンのCIOアシスタントとして発注側にも立ちました。両面を経験して確信しているのは、プロジェクトの失敗原因は発注側にも受注側にもあり、どちらか片方だけに手を打っても解けないということです。だからこそ、両者のPMOの守備範囲の違いを正確に押さえておく必要があります。

大事なのは、これが善し悪しの話ではないということです。ベンダー側PMOが発注側の社内調整に踏み込まないのは怠慢ではなく、契約上そういう建て付けだから。逆に言えば、表の左列の仕事は、発注側の誰かが担わない限り永遠に空席のままです。この空席を放置した状態を、世間では「丸投げ」と呼びます。

僕はYouTubeで「発注者研修」というシリーズを始めたとき、初回の動画でシステム開発の発注側の失敗パターンを「7つの大罪」として整理しました。ベンダーはプロだから細かいところはうまくやってくれるだろうと、要件を曖昧なまま任せる「曖昧の罪」。契約書にサインすれば仕事は終わりと構え、仕様の質問ラッシュに答えられずタスクを止めてしまう「沈黙の罪」。社内のコンセンサスが取れていないまま要件を伝え、後から部門ごとに指示が逆走する「不決断の罪」。開発が始まったら納品物のチェックだけすればいいと放置し、終盤で致命的な設計ミスが発覚する「無関心の罪」。契約形態を理解しないまま判を押してしまう「無知の罪」——。ほかにも、お金を払う側なのだからと高圧的に振る舞った結果、ベンダーが防衛的になり、資料作りやクレーム対応に開発リソースが溶けていくパターンも動画では取り上げました。どれも独立した問題ではなく、互いに絡み合って悪化していく機能不全のシステムです。

では、なぜ発注者が関与しないとプロジェクトは失敗するのか。動画ではこう話しました。

format_quote

発注者の知識ですとか、発注者からの意思決定、そして発注者の積極的な参加というところが、プロジェクトにとって最大のインプットになっているんですよね。

format_quote

それが欠けてしまったプロジェクトというのは、推測とか仮定とか、こういった砂のようなものの上にシステムという建物を建てる、もう本当に砂上の楼閣みたいな状態になってしまうので、システム開発は開始時点から破綻が運命付けられているよという話になります。

つらいのは、丸投げする発注者に悪気がないことです。「プロに任せるのが一番」という善意の判断が、ベンダーから見ると「インプットが出てこない案件」になっている。冒頭の「状況が見えない」という違和感も、多くの場合ベンダーが何かを隠しているのではなく、発注側に状況を受け止めて判断する機能がないために、報告が意味を持たなくなっているだけなんです。この構造を裏返せば、発注側が主体的にベンダーを管理する動き方が見えてきます。

「7つの大罪」の全体像と、発注者の参加がなぜ最大のインプットなのか。動画で詳しく知りたい方は、以下もあわせてご覧ください。

「【発注者研修①】システム開発を丸投げすると必ず破綻する」

丸投げの対義語は「マイクロマネジメント」ではありません。同じ動画で、僕は発注者の責任をこう定義しました。

format_quote

発注者の責任というのは、明確な決断を下して、タイムリーな情報連携をして、自社の組織についてもちゃんと管理をして、そして開発している会社のパートナーとして振る舞うこと。これが必要になってくるかなという風に思っています。

この「自社の組織をちゃんと管理する」ための具体的な仕組みが、発注者側PMOです。そして、外部からPMOを迎える場合には、もう一段の設計が要る。

シンプレクスでPMをしていた頃、僕はPMOの参画初日に必ず「あなたに期待する成果物と、判断を求める場面」を1枚にまとめたシートを渡していました。これだけでPMOの動き方が劇的に変わります。PMOが議事録係で終わる現場は珍しくありませんが、原因の多くはPMO側の能力不足ではなく、受け入れる側の期待値設計の不在にある。PMOを入れる側にも設計責任がある、というのが僕の結論です。

期待値シートに書くことは難しくありません。

• 期待する成果物（例：週次の課題一覧と判断依頼リスト）
• 判断を求めたい場面（例：スケジュールとスコープがトレードオフになったとき）
• アクセスしてよい情報・参加してよい会議体
• 誰に・何を・いつエスカレーションするか

A4一枚で十分です。逆にこれが書けないなら、PMOの要否以前に「自分たちがこのプロジェクトで何を担うのか」を言語化できていないサインだと受け止めたほうがいい。

設置パターンは大きく3つ

僕が検討の起点として勧めたいのは、真ん中のハイブリッド型です。業務を知らない外部PMOだけでは要件の妥当性を判断しきれず、プロマネ経験のない社内担当だけではベンダーと対等に議論できない。両方を組み合わせると、それぞれの欠けが埋まります。

また、外部の力を借りるパターンを選ぶ場合は、設置と同時に契約形態を必ず決めておく必要があります。準委任・派遣・請負のどれを選ぶかで指揮命令の在り方が変わるため、契約形態の選び方と偽装請負リスクの整理もあわせて確認しておいてください。

注意したいのは、外部PMO常駐型を選ぶ場合でも、意思決定そのものは外部に委任できないことです。判断材料を揃え、選択肢と影響を並べるところまでがPMOの仕事で、決めるのはあくまで発注者自身。ここを取り違えると、丸投げの相手がベンダーから外部PMOに変わるだけになります。

業務範囲チェックリスト

発注者側PMOが担うべき業務は、おおむね次のとおりです。自社の体制でどれが誰の担当にもなっていないか、チェックしながら読んでみてください。

• ベンダーからの質問・確認事項の一次受けと、回答期限の管理
• 社内ステークホルダーの合意形成（意思決定の場の設計と論点整理）
• 要件・仕様変更の影響を発注側視点で整理し、判断材料に変換する
• 進捗・課題・リスクを、経営層が判断できる粒度に翻訳して報告する
• 検収観点の整理と、受け入れテストの計画・推進
• 会議体の設計（報告の読み上げの場ではなく、判断の場にする）

なお、ベンダーへの具体的な統制・評価の手法（いわゆるベンダーコントロール）はそれ自体が大きなテーマなので、本記事では踏み込みません。

外部の力を借りるべきサイン

次のうち2つ以上当てはまるなら、外部支援を検討する段階だと思います。

• 社内に、ベンダーと対等に議論できるPM経験者がいない
• 今回の案件規模・種類が、自社にとって初めての経験
• 複数ベンダーが並走していて、その間の調整が誰の仕事か曖昧
• 担当者が通常業務と兼任で、ベンダーへの回答が数日単位で滞っている
• ベンダーの報告を聞いても、順調なのか危ないのか判断がつかない

システム開発の成功率は3割と言われる世界です。発注側の推進機能の空席を埋めるコストは、破綻後の立て直しコストに比べればずっと小さい。前始末は後始末より安いんです。

支援者を選ぶときに見るべき3つの目

• 発注側に立った実績があるか。 ベンダー側PMOの経験だけでは、発注側の決裁の泥臭さや部門間調整は扱えません。
• 受注側の経験もあるか。 ベンダーの見積もりの組み方や「あえて言わないこと」を内側から知っている人は、報告の行間が読めます。
• 期待値定義から一緒にやってくれるか。 着任時に「何を期待し、どこで判断を仰ぐか」を紙に落とす支援者は信頼できる。役割を曖昧なまま走り出す支援者は、どれだけ優秀でも議事録係化のリスクを抱えます。

導入の進め方

外部支援の導入は、次の流れで進めるとつまずきにくいと思います。

1. 現状整理：案件の状況と社内体制を棚卸しし、業務範囲チェックリストのどこが空席かを洗い出す
2. 役割定義：期待値シートの要領で、期待する成果物と判断を求める場面を言語化する
3. 小さく始める：いきなりフル常駐ではなく、週数日の伴走や体制診断から始めて相性を確かめる
4. 定期的な見直し：役割と稼働を定期的に見直し、社内メンバーへ引き継げる業務は段階的に移していく

契約形態は準委任が選ばれるのが一般的ですが、準委任・派遣・請負の違いや偽装請負リスクの整理は本記事の範囲を超えるため、別の機会に譲ります。

最後にもう一つ。外部PMOを入れることは丸投げの解消であって、新しい丸投げ先を作ることではありません。動画の締めで話したとおりです。

format_quote

その危機感こそが、あなたをシステム開発を失敗させてしまう受動的な発注者から、プロジェクトを成功させる能動的なパートナーに成長させていくかなという風に思います。

• 発注者側PMOは発注企業の側に立ち、要件インプット・社内合意形成・意思決定を回す機能。ベンダー側PMOとは守備範囲がまったく別物
• ベンダー側PMOは受注スコープの管理者であり、発注側社内の空席は埋めてくれない
• プロジェクト最大のインプットは発注者の知識・意思決定・積極的な参加。それが欠けた丸投げは開始時点で破綻が決まっている
• PMOを迎えるなら、期待する成果物と判断を求める場面をA4一枚の期待値シートで言語化する
• 外部支援は「発注側に立った実績」「受注側も含む両側の経験」「期待値定義への伴走」の3点で選ぶ

プロジェクトが見えない不安の正体は、ベンダーの能力や誠意の問題ではなく、発注側の推進機能の空席であることがほとんどです。そして空席は、埋め方さえ分かれば埋められる。あなたの会社は、受け身の検収者で終わる必要はありません。

※本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。

---

発注側の推進体制に空席を感じたら

「ベンダーの報告を聞いても、順調なのか危ないのか判断できない」「社内にPM経験者がおらず、仕様の質問に答えきれていない」「外部PMOを入れたいが、何を任せて何を自社で持つべきか整理できない」——そんな状態のまま走り続けると、問題は検収やリリース直前になって一気に表面化します。

クリエイティブテックスタジオでは、受注側のPMと発注側の支援、両方を経験したメンバーが、発注者側に立つPMO支援を提供しています。まずは現状の体制と案件の状況を伺い、外部支援が本当に必要か、必要ならどの範囲かを一緒に整理するところから始めます。内製での立て直しや他社のサービスが適していれば、その旨も正直にお伝えします。

無料相談から、いまの状況をお聞かせください。支援内容の詳細はPMO支援サービスのページでもご覧いただけます。