PMOとは｜中小企業の基幹システム刷新で必要な役割と、外部に任せる範囲の決め方

PMOとは、プロジェクトの課題・決定事項・進捗・変更を一か所で管理し、決めるべき人に決めさせる仕組みのことです。中小企業の基幹システム刷新では、PMOを専任で置く必要はありませんが、機能そのものを省くと決定が流れ、追加費用と遅延につながります。この記事では、PMOの役割、PMやステアリングコミッティとの違い、社内に残す仕事と外部に任せる仕事の判定表を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。

PMOとは：プロジェクトの「管理と意思決定の事務局」

PMOはProject Management Officeの略です。直訳すると「プロジェクト管理室」ですが、実態は部署名ではなく機能の名前です。プロジェクトの進捗や課題を集め、判断材料を整え、決まったことを記録して関係者に届ける。この一連の働きをPMOと呼びます。

PMOという言葉が指す範囲は、組織によってかなり違います。PMI（米国プロジェクトマネジメント協会）の学術誌「Project Management Journal」に掲載されたHobbsとAubryの研究（2007年）は、PMOが広く普及している一方で、その形や機能が組織ごとに大きく異なり、統一的な理解がまだないことを研究の出発点にしています。「うちのPMO」と「ベンダーの言うPMO」が別物であることは珍しくありません。

行政の例も参考になります。デジタル庁の「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック（DS-120）」（2024年）は、個別の情報システムの企画・調達・開発・運用の実務を担う職員をPJMO（ProJect Management Office）、府省内のIT施策を全体管理する職員をPMO（Portfolio Management Office）と呼び分けています。1本のプロジェクトを回す役割と、複数の施策を束ねる役割は別、という整理です。

中小企業の基幹システム刷新で必要なのは、前者のPJMOにあたる働きです。この記事では、以下「PMO」を1本の刷新プロジェクトを管理する機能の意味で使います。

PMとPMO、ステアリングコミッティの違い

PMOが機能しない原因の多くは、PM（プロジェクトマネージャー）やステアリングコミッティ（経営層による意思決定会議）との役割分担が曖昧なことです。3つを並べると違いがはっきりします。

※会議の頻度は説明用の例です。規模やフェーズによって調整します。

ポイントは、PMOは決める役ではないということです。PMOが決め始めると、PMや経営の当事者意識が薄れます。逆に、PMOが材料をそろえないと、PMは毎週「確認して次回までに」と先送りすることになります。ステアリングコミッティの設計と会議の回し方はステアリングコミッティとはで詳しく解説しています。

基幹システム刷新でPMOが担う8つの仕事

基幹システムの刷新は、販売・購買・在庫・会計と部門をまたぐため、論点が数百件に上ることがあります。PMOの仕事は、その論点をなくさない・止めない・ぶれさせないことです。具体的には次の8つです。

8つの仕事の重さは、フェーズによって変わります。構想策定から要件定義までは課題管理と決定事項の記録が中心で、論点が次々に出ては決まっていきます。設計・開発の時期は変更管理とベンダーの進捗確認に重心が移ります。テストから本番切替にかけては、リスク管理とフェーズ判定の準備が最も忙しくなります。データ移行のリハーサル結果や、未解決の不具合の件数をそろえて、稼働してよいかを判断する材料を作るためです。

8つのうち、中小企業で特に抜けやすいのは3の決定事項の記録と4の変更管理です。議事録は残っていても、「何が決まったか」が会議の流れの中に埋もれていて、後から引けない状態がよくあります。議事録とは別に、決定事項だけを1行ずつ残すログを作るのがPMOの基本です。

課題管理表の記入例

課題管理表は、項目を増やしすぎると更新されなくなります。基幹システム刷新なら、次の8項目で足ります。

※説明用の例です。従業員150名・2倉庫の食品卸を想定しています。

この表で押さえたいのは、「判断者」と「期限」を起票した時点で埋めることです。判断者が空欄の課題は、誰も決めないまま残ります。また、K-021のように部門の判断を超えるものは、状態を「ステコミへ」として上げる先を明示します。

決定事項ログの記入例

決定事項ログは、課題管理表で「決定」になったものを1行ずつ転記する台帳です。項目は「番号・日付・決定内容・判断者・関連課題」の5つで足ります。

• D-007｜6/17｜締め日は15日・20日・末日の3種類を保持する。25日締めの2社には20日締めへの変更を打診する｜営業部長｜K-012
• D-008｜6/24｜倉庫間移動は移動伝票で記録し、在庫数の直接修正は棚卸差異の処理に限る｜物流課長｜K-018
• D-009｜7/8｜過去データは直近3年分を移行し、それより前は旧システムを照会専用で残す｜ステコミ｜K-021

※説明用の例です。決定内容は「誰が読んでも同じ意味になる1文」で書き、あいまいな表現（「検討のうえ対応」など）は使いません。

中小企業でPMOがないと何が起きるか

中小企業では、そもそもプロジェクトを専任で回す体制を持つ会社が多くありません。IPA（情報処理推進機構）の「DX動向2025」によると、従業員100人以下の日本企業で、DXの取組に関する専門部署またはプロジェクトチームがあると答えた割合は20.7%でした。1,001人以上では83.0%です。PMOを置くかどうか以前に、プロジェクトを動かす専任の器がない会社が大半ということです。

器がないまま基幹システムの刷新を始めると、PMOの仕事は誰の担当でもなくなります。典型的なのが次の2つの場面です。

中小企業の刷新が大企業と違うのは、PMOの仕事の量より担い手の兼務の度合いです。大企業なら数名のPMOチームを置けますが、従業員100〜200名規模では、管理部長がPMを、経理や営業事務の担当者がPMOを、それぞれ本業と並行して担うのが普通です。だからこそ、仕組みを軽くしておく必要があります。課題管理表は8項目、決定事項ログは5項目、変更要求票は1枚。この程度に絞ると、兼務でも週1回の更新が続きます。刷新の目的や範囲を決める前段の整理は基幹システムの構想策定とはで解説しています。

どちらの場面も、技術の問題ではなく管理の問題です。公表されている失敗の傾向はERP導入の失敗パターンでも整理していますが、決定の記録と変更の管理は、規模の小さいプロジェクトでも省けない部分です。

PMOの3つの置き方：社内・ベンダー側・第三者

PMOをどこに置くかには、大きく3つの選択肢があります。どれが正解というより、誰の利益を守る立場かで役割が変わる点を押さえておきます。

社内PMO

社内の事情や人間関係に詳しく、稼働後もノウハウが残るのが強みです。一方で本業との兼務になりやすく、ベンダーの報告や見積もりに踏み込んで指摘するには経験が要ります。パッケージの標準機能に近い形で導入し、論点が少ない場合に向いています。

ベンダー側のPMO

開発の進め方に詳しく、立ち上げが早いのが強みです。ただし、ベンダー自身の作業の遅れや追加費用を、発注側の立場で指摘する役割は期待しにくくなります。ベンダー内部の作業管理としては有効ですが、発注側のPMOの代わりにはしないのが原則です。

第三者（外部）のPMO

発注側の立場で、ベンダーの進捗報告や見積もり、設計書を点検できるのが強みです。社内の業務知識は社内の担当者から補う必要があり、費用もかかります。複数のベンダーが関わる、部門間の調整が多い、社内に刷新の経験者がいない、といった状況で効果が出やすい置き方です。

見落とされがちなのは、ベンダーにPMOを任せても、発注側の責任はなくならないことです。IPAの「情報システム・モデル取引・契約書（第二版）」（2020年公開）は、民法改正に直接関係しない見直し論点の一つとして「プロジェクトマネジメント義務及び協力義務」を挙げています。システム開発では、ベンダーがプロジェクトを管理する義務を負う一方、発注側にも必要な情報の提供や判断などで協力する義務がある、という考え方です。

つまり、発注側が期限までに判断しない、資料を出さない、といった状態は、発注側の問題として扱われる可能性があります。社内に最低限のPMO機能を持つことは、自社を守ることでもあります。ベンダーに管理を任せきりにした結果、乗り換えにくくなる問題はベンダーロックインとはでも触れています。

外部に任せる範囲の決め方：判定表

外部の支援を使う場合も、PMOの仕事を丸ごと渡すのはおすすめしません。判断と社内調整は社内に残し、仕組みづくりと点検を外部に任せるのが基本の線引きです。8つの仕事を、次の判定表で振り分けます。

表を見ると、「社内に残す」列はすべて判断・承認・社内の事情に関わることです。これは外部に任せても質が上がらない、むしろ下がる部分です。一方、「外部に任せやすい」列は、型や経験がものを言う部分で、初めて刷新に取り組む会社ほど外部の価値が出ます。

社内PMO担当に向く人の条件

社内側でPMOの役割を担う人は、ITに詳しい必要はありません。むしろ次の条件を満たす人が向いています。

• 販売・購買・経理など、複数の部門の業務を一通り知っている
• 部長クラスに期限を催促できる立場、または社長の後ろ盾がある
• 刷新の期間中、業務時間の一定割合（例：週1〜2日分）をプロジェクトに充てられる
• 稼働後もシステムの運用に関わる予定がある

※「週1〜2日分」は説明用の例です。プロジェクトの規模とフェーズで変わります。要件定義と移行・テストの時期は負荷が上がります。

この条件に合う人がいない場合は、外部PMOの比重を上げつつ、社内の担当者を「見習い」として並走させます。稼働後に社内に何も残らない状態を避けるためです。

外部PMOを依頼するときの契約と進め方

外部にPMOを依頼する場合、作業の完成を約束する請負ではなく、専門家としての作業を提供する準委任の形をとることが一般的です。PMOの仕事は「何かを完成させる」より「管理を回し続ける」性質が強いためです。

準委任の場合、何をどこまでやるかが曖昧だと、「頼んだつもり」「頼まれていない」のずれが起きます。契約前に、少なくとも次の点を確認しておきます。

• 8つの仕事のうち、どれを任せ、どれを社内に残すかが書面で決まっている
• 定例の主催・資料作成・議事録・決定事項ログを誰が作るかが決まっている
• ベンダーの見積もりや設計書を点検する範囲（全部か、重要なものだけか）が決まっている
• 報告の宛先（PMか、ステコミか）と頻度が決まっている
• 外部PMOがベンダーと利害関係を持たないことを確認している
• 関わる人数・稼働の目安と、繁忙期に増減するときのルールがある
• 成果物（課題管理表・決定事項ログ・リスク一覧など）の著作権・利用権が自社に残る
• 契約終了時に、管理資料一式と運用方法を社内に引き継ぐことが決まっている
• 社内の担当者を並走させ、育成する前提になっている
• 途中で体制を見直す時期（例：要件定義の完了時）が決まっている

特に5つ目の利害関係は見落としやすい点です。外部PMOが、刷新の開発を受注するベンダーと同じ会社やグループだと、発注側の立場でベンダーの見積もりを点検する役割が果たしにくくなります。ベンダーの比較と選び方はベンダー選定の進め方で詳しく解説しています。

PMOを立ち上げる5つのステップ

中小企業の基幹システム刷新なら、PMOの立ち上げに大がかりな準備は要りません。次の5つを、構想策定から要件定義に入る前後で済ませます。

1. 体制図を1枚で描く
   ステコミのメンバー、PM、PMO担当、部門ごとの判断者、ベンダーの窓口を1枚に書きます。部門ごとの判断者を名前で書くのがポイントです。名前が書けない部門は、そこで判断が止まります。
2. 会議体と頻度を決める
   週次の定例、領域ごとの分科会、月次のステコミの3層が基本です。それぞれで「何を決めるか」を1行で書いておくと、報告だけの会議になりにくくなります。
3. 課題管理表と決定事項ログを用意する
   先に挙げた8項目の課題管理表と、「番号・日付・決定内容・判断者・関連課題」の5項目の決定事項ログで始めます。ツールは表計算ソフトで足ります。
4. 変更管理のルールを決める
   「要望はすべて変更要求票に起票する」「ベンダーへの直接依頼はしない」「一定額を超える変更はステコミで判断する」の3点を、最初の定例で全員に伝えます。
5. フェーズごとの完了条件を決める
   要件定義なら「機能要件一覧に優先度と受入基準がそろっている」「未決の課題が残っていない、または期限つきで残している」など、次の工程に進む条件を先に決めます。

全体の進め方は基幹システム導入の進め方、要件定義での会議の回し方は要件定義の進め方もあわせてご覧ください。

よくある質問

まとめ

PMOとは、プロジェクトの課題・決定・変更を一か所で管理し、決めるべき人に決めさせる機能です。中小企業の基幹システム刷新では、専任の組織は要りませんが、課題管理表・決定事項ログ・変更管理の3つは省けません。外部に任せる場合も、判断と承認、社内の事情に関わる部分は社内に残し、型づくりと点検を外部に任せるのが基本の線引きです。

自社の体制でどこまで回せるか、どの部分に外部の支援が必要かを整理したい方は、無料診断で現状の体制と刷新の進め方を一緒に確認します。支援の範囲はサービス内容でも紹介しています。