システム開発を外注するとき、
「開発会社との打ち合わせについていけない」
「見積や設計書を出されても、妥当なのか判断できない」
「社内の要望がまとまらず、ベンダーへ伝える内容が毎回変わる」
「進捗報告は受けているが、本当に予定どおり進んでいるのか分からない」
といった問題が起こることがあります。
このような場合に利用できるのが、PMO支援です。
PMOはProject Management Officeの略で、プロジェクト管理を支援する役割を指します。
特にシステム開発では、
発注者と開発会社の間に入り、要件・進捗・課題・成果物・意思決定を整理する
という役割を持たせることができます。
例えば、
発注企業
↓
PMO
↓
開発会社
という体制です。
発注者側にシステム開発経験が少なくても、外部PMOを入れることで、
- 業務要件の整理
- RFP・要件資料の作成支援
- 見積比較
- ベンダー選定
- 進捗管理
- 課題管理
- ベンダーコントロール
- 成果物レビュー
- 仕様変更管理
- 受入テスト支援
などを任せられます。
この記事では、システム開発におけるPMO支援でできること、PM・開発会社との違い、外部PMOを入れるメリット、任せるべき業務・任せるべきではない業務まで解説します。
PMOとは
PMOとは、プロジェクトを円滑に進めるために、プロジェクト管理を支援する役割・組織です。
大規模企業では社内にPMO組織が設置されることもありますが、中小規模のシステム開発では、外部のPMO支援を利用する方法もあります。
PMOの仕事内容はプロジェクトによって大きく異なります。
例えば、
- プロジェクト計画作成
- スケジュール管理
- 課題管理
- リスク管理
- 会議運営
- ドキュメント管理
- ベンダー管理
を中心に担当するPMOもあります。
一方、発注者側へ入るPMOでは、
- 業務整理
- 要件整理
- ベンダーへの説明
- 見積精査
- 成果物レビュー
- 受入支援
まで担当する場合があります。
そのため、PMOを依頼するときは、
「PMOをお願いします」ではなく、具体的に何を支援してほしいのか
を明確にすることが重要です。
PMO支援でできること一覧
システム開発では、主に次のような業務をPMOへ依頼できます。
| 業務 | 主な内容 |
|---|---|
| プロジェクト計画 | 体制・工程・スケジュール整理 |
| 業務整理 | 現状業務・課題の整理 |
| 要件整理 | 業務要件・機能要件の整理 |
| RFP作成支援 | 開発会社への依頼内容整理 |
| ベンダー選定 | 提案・見積比較 |
| 進捗管理 | 計画と実績の確認 |
| 課題管理 | 課題・期限・担当者管理 |
| リスク管理 | 遅延・品質・体制リスク確認 |
| ベンダー管理 | 報告確認・質問・調整 |
| 会議運営 | 議題・議事録・決定事項整理 |
| 変更管理 | 仕様変更・追加費用管理 |
| 成果物レビュー | 要件書・設計書などの確認 |
| 受入支援 | 受入条件・テスト計画整理 |
| 経営報告 | 状況・リスクの可視化 |
すべてを依頼する必要はありません。
例えば、
ベンダー管理だけ依頼する
要件定義から開発開始まで支援してもらう
開発中の進捗・課題管理を任せる
など、必要な範囲だけ外部PMOを活用できます。
1．プロジェクト計画を整理する
開発開始時には、
- 目的
- スコープ
- 開発体制
- 役割
- スケジュール
- 会議体
- 成果物
- 意思決定方法
などを整理する必要があります。
例えば、
「9月末までにリリースする」
だけでは不十分です。
そのためには、
要件定義
↓
基本設計
↓
詳細設計
↓
開発
↓
テスト
↓
受入テスト
↓
リリース
という工程を作り、それぞれの終了条件を確認します。
PMOは、こうしたプロジェクト全体の進め方を整理する支援ができます。
2．業務フロー・課題を整理する
発注者が、
「顧客管理システムが欲しい」
と考えていても、それだけでは開発会社は具体的なシステムを設計できません。
まず、
- 現在どのような業務をしているか
- 誰が担当しているか
- 何に困っているか
- どこをシステム化するか
を整理する必要があります。
例えば、
営業担当者
↓
Excelへ顧客登録
↓
案件情報を別Excelへ入力
↓
管理者が毎週集計
↓
会議資料を作成
という業務があるなら、
「顧客管理システムを作る」
ではなく、
顧客・案件情報を一元管理し、管理者の週次集計を不要にする
という目的まで具体化します。
PMOが業務ヒアリングへ入り、開発会社へ説明できる状態まで整理する方法があります。
3．要件整理・要件定義を支援する
PMO支援では、発注者側の要望を整理して開発会社へ伝える役割も重要です。
例えば現場から、
- CSVが欲しい
- メール通知が欲しい
- AIを入れたい
- グラフが欲しい
- スマホでも使いたい
という要望が出たとします。
そのまますべて開発会社へ渡すのではなく、
「なぜ必要なのか」
を確認します。
例えばCSVが必要な理由が、
「毎月会計システムへ登録するため」
なら、CSVだけでなくAPI連携も選択肢になる可能性があります。
PMOが間に入ることで、
現場の要望 → 業務要件 → システム要件
へ整理しやすくなります。
4．開発スコープと優先順位を整理する
システム開発では、要望をすべて実装すると予算を超えることがあります。
例えば、
- 顧客管理
- 案件管理
- CSV
- ダッシュボード
- Slack通知
- AI分析
- 会計連携
という要望があった場合です。
PMOは、
- 業務価値
- 必須度
- 開発費
- 技術的依存関係
を確認し、
初回リリース
- 顧客管理
- 案件管理
Phase 2
- CSV
- ダッシュボード
Phase 3
- AI分析
- 会計連携
など、スコープを整理する支援ができます。
5．RFP・見積依頼を支援する
開発会社へ見積を依頼するとき、会社ごとに違う条件を伝えると比較できません。
そこで、
- 開発目的
- 現状業務
- 要件
- 開発範囲
- 利用人数
- データ
- 外部連携
- 希望納期
- 予算
- 保守条件
などを整理して依頼します。
PMOがRFPや見積依頼資料を作成・レビューすることで、複数ベンダーから比較しやすい提案を受けやすくなります。
6．ベンダー選定を支援する
ベンダー選定では、金額だけを比較するのは危険です。
例えば、
A社：500万円
B社：700万円
という見積でも、A社には、
- データ移行
- インフラ
- 保守
- テスト
が含まれておらず、B社には含まれている可能性があります。
PMOは、
- 対象範囲
- 前提条件
- 工程
- 体制
- 工数
- 保守
- 追加費用条件
などを整理して比較します。
また、
- 業務理解
- 技術力
- PM体制
- コミュニケーション
- 類似実績
など、価格以外の評価項目も整理できます。
7．ベンダー管理・ベンダーコントロールを行う
開発開始後のPMO支援で特に重要なのがベンダー管理です。
例えば開発会社から毎週、
進捗率80％です。
と報告されたとしても、それだけでは本当に順調か分かりません。
PMOでは、
- 何が完了したのか
- 成果物はあるのか
- 未完了タスクは何か
- 課題は何か
- 納期への影響はあるか
を確認します。
「進捗80％」という主観的な報告だけではなく、成果物・マイルストーンを基準に確認することが重要です。
8．進捗管理を支援する
例えば、
| タスク | 期限 | 状態 |
|---|---|---|
| 要件定義 | 6/30 | 完了 |
| 基本設計 | 7/20 | 遅延 |
| 開発 | 8/31 | 未着手 |
| テスト | 9/15 | 未着手 |
| リリース | 9/30 | 未着手 |
と管理します。
基本設計が5日遅れた場合、
「5日遅れました」
だけではなく、
後続工程に影響するか
まで確認します。
例えば、
- 開発要員を追加する
- 一部機能を後回しにする
- テスト期間を変更する
など、対応策を検討します。
9．課題管理を行う
システム開発では、多くの課題が発生します。
例えば、
- CSV仕様が未確定
- API仕様書が届いていない
- 本番環境の契約が未完了
- 権限ルールが決まっていない
- データ移行範囲が未決定
などです。
課題管理では、
| ID | 課題 | 担当 | 期限 | 状態 |
|---|---|---|---|---|
| Q01 | CSV仕様確定 | 業務担当 | 8/10 | 対応中 |
| Q02 | API仕様確認 | ベンダー | 8/12 | 未着手 |
| Q03 | 権限確定 | 発注者 | 8/15 | 対応中 |
のように管理します。
PMOは、
課題を記録するだけでなく、期限・担当者・プロジェクトへの影響まで追跡する
役割を持ちます。
10．リスク管理を支援する
課題はすでに発生している問題です。
一方、リスクは、
今後問題になる可能性があるもの
です。
例えば、
「特定エンジニアしか仕様を理解していない」
という状態なら、現在は問題なくても、その人が離脱すると開発が止まる可能性があります。
ほかにも、
- 要件未確定
- 開発要員不足
- 外部APIの仕様変更
- データ品質不足
- リリース時期の繁忙期重複
などがあります。
PMOは早い段階でリスクを見える化し、対応策を検討します。
11．会議運営・議事録を支援する
システム開発では会議が増えがちです。
しかし、
「毎週会議しているのに何も決まらない」
という状態では意味がありません。
PMOでは会議前に、
- 何を報告するか
- 何を相談するか
- 何を決定するか
を整理します。
例えば、
報告
開発進捗
相談
データ移行方法
決定
CSV出力仕様
とします。
会議後には、
- 決定事項
- 宿題
- 担当者
- 期限
を記録します。
12．成果物レビューを支援する
開発会社から、
- 要件定義書
- 基本設計書
- 画面一覧
- 画面設計書
- テスト計画書
などが提出されても、発注者側に開発経験がなければ、
「何を確認すればよいか分からない」
ことがあります。
PMOが、
- 要件と矛盾していないか
- 必要項目が抜けていないか
- 未決事項が残っていないか
- 発注者の認識と合っているか
を確認する支援ができます。
ただし、PMOがレビューしたから発注者側の確認が不要になるわけではありません。
業務ルールは、実際の業務担当者にも確認してもらいます。
13．仕様変更を管理する
開発途中では、
「この項目も追加したい」
「CSVをもう1種類追加したい」
といった変更が発生します。
そのたびに開発者へ直接依頼すると、スコープが広がり続ける可能性があります。
PMOでは変更要求を、
- 内容
- 理由
- 優先度
- 追加工数
- 費用
- 納期への影響
で整理します。
そのうえで、
- 今回対応
- 次期開発
- 対応しない
を判断します。
14．受入条件・受入テストを支援する
開発完了後、
「なんとなく画面を触ってOK」
では検収の判断が曖昧になります。
例えば顧客検索なら、
- 顧客名で検索できる
- 電話番号で検索できる
- 部分一致できる
- 権限外の顧客は表示されない
など、受入条件を整理します。
PMOは、
要件 → 受入条件 → 受入テスト
のつながりを確認する支援ができます。
15．社内向けの状況報告を整理する
経営層へ開発状況を報告するとき、
タスクを数百件並べても状況は伝わりません。
例えば、
スケジュール
1週間遅延
予算
計画内
重大課題
データ移行仕様が未確定
リスク
テスト期間が短縮される可能性あり
必要な意思決定
8月10日までに移行範囲を確定
などに整理します。
PMOは、現場レベルの情報を経営・責任者が判断できる粒度へ変換する役割も持てます。
PMとPMOの違い
PMとPMOは似ていますが、一般的には役割が異なります。
PM
プロジェクト全体の責任を持ち、意思決定・チーム管理を行います。
PMO
PMやプロジェクト責任者が管理・意思決定できるように支援します。
例えば、
PM：
納期を維持するため、機能AをPhase 2へ変更する。
PMO：
現在5日遅延しています。機能AをPhase 2へ送ると予定日へ戻せる見込みです。
といった関係です。
ただし、実際の案件では外部PMOがPMに近い役割まで担うこともあります。
そのため契約前に役割を明確にすることが重要です。
PMOと開発会社の違い
開発会社は基本的に、
システムを設計・開発する側
です。
一方、発注者側PMOは、
発注者の立場からプロジェクトを管理・支援する側
です。
例えば開発会社から、
「追加機能は80万円です」
と提案された場合、PMOが、
- 本当に追加要件なのか
- 当初スコープに含まれていないか
- 80万円の根拠は何か
- 次期開発へ回せないか
を整理できます。
発注者と開発会社の間に技術・プロジェクト管理を理解する担当者を置くことで、情報の非対称性を小さくできます。
外部PMOが特に有効なケース
社内にシステム開発経験者がいない
開発会社とのコミュニケーションを支援してもらえます。
複数ベンダーが関わる
例えば、
- アプリ開発会社
- インフラ会社
- 既存基幹システム会社
などを横断して管理する必要があります。
要件がまとまっていない
開発会社へ依頼する前に業務・要件を整理できます。
大規模なシステム刷新を行う
関係部署が多いほど、課題・意思決定・調整が増えます。
社内PMが忙しすぎる
資料作成・課題管理・進捗管理などをPMOへ移し、PMを意思決定に集中させる方法があります。
PMOへ任せるべきではないこと
PMOを入れれば、すべて任せられるわけではありません。
特に発注者側で持つべきなのは、
事業判断
「このシステムへ投資するか」は自社が判断します。
業務上の最終判断
「承認金額はいくらから部長決裁か」など、自社業務のルールです。
優先順位
どの課題を優先して解決するかは発注者側で決めます。
最終受入
PMOはテストを支援できますが、業務として利用可能か最終判断するのは発注者です。
つまりPMOは、
意思決定を代行するというより、意思決定できる状態を作る役割
と考えると分かりやすいでしょう。
PMO支援を依頼するときに決めること
外部PMOへ依頼するなら、最初に次を明確にします。
| 項目 | 確認内容 |
|---|---|
| 対象工程 | 要件定義・開発・受入など |
| 役割 | 何を担当するか |
| 会議 | 参加する会議 |
| 成果物 | 作成・レビューする資料 |
| 権限 | どこまで判断可能か |
| ベンダー窓口 | 直接連絡するか |
| 稼働 | 週何時間程度か |
| 報告 | 誰へ何を報告するか |
特に重要なのが、
PMOに決定権があるのか、提案までなのか
です。
RACIでPMOの役割を明確にする
例えば次のように整理できます。
| タスク | 発注責任者 | PMO | 業務担当 | ベンダー |
|---|---|---|---|---|
| 開発目的 | A | C | C | I |
| 業務整理 | A | R | C | C |
| 要件整理 | A | R | C | C |
| 技術設計 | I | C | C | R/A |
| 進捗管理 | A | R | I | C |
| 仕様変更 | A | R | C | C |
| 開発 | I | C | I | R/A |
| 受入テスト | A | R | R | C |
このように役割を明確にしておくと、
「PMOが決めると思っていた」
「ベンダーがやると思っていた」
という問題を防げます。
【テンプレート】PMO支援業務の整理表
外部PMOへ相談するときは、次のように整理できます。
| 項目 | 支援要否 | 現在の課題 |
|---|---|---|
| 業務ヒアリング | 要 / 不要 | |
| 要件整理 | 要 / 不要 | |
| RFP作成 | 要 / 不要 | |
| 見積比較 | 要 / 不要 | |
| ベンダー選定 | 要 / 不要 | |
| スケジュール管理 | 要 / 不要 | |
| 課題管理 | 要 / 不要 | |
| リスク管理 | 要 / 不要 | |
| ベンダー管理 | 要 / 不要 | |
| 会議運営 | 要 / 不要 | |
| 成果物レビュー | 要 / 不要 | |
| 変更管理 | 要 / 不要 | |
| 受入テスト | 要 / 不要 | |
| リリース支援 | 要 / 不要 |
全部を「要」にする必要はありません。
自社で不足している部分だけ支援してもらう方法があります。
PMO支援でよくある失敗
失敗1｜PMOの役割が曖昧
「プロジェクト管理をお願いします」だけでは担当範囲が分かりません。
支援内容を具体化します。
失敗2｜議事録作成だけになっている
PMOが会議設定・議事録・資料更新だけになってしまうケースがあります。
それが必要な案件もありますが、期待しているのがベンダー管理・課題解決なら役割が合っていません。
失敗3｜PMOへ意思決定まで丸投げする
事業・業務上の最終判断は発注者側に残します。
失敗4｜ベンダーと対立する役割にする
PMOはベンダーを責める存在ではありません。
目的は、
発注者とベンダーが同じ目標へ向かって進める状態を作ること
です。
失敗5｜技術を理解できないPMOを配置する
システム開発PMOでは、進捗表だけでなく、
- 要件
- 設計
- テスト
- インフラ
- 開発工程
をある程度理解している方が、ベンダーとの会話を進めやすくなります。
失敗6｜課題を記録するだけになる
「課題一覧を更新すること」が目的ではありません。
誰が・いつまでに・どう解決するかまで追跡します。
PMO支援を依頼する前のチェックリスト
プロジェクト
- 開発目的は明確か
- 予算は決まっているか
- 希望納期はあるか
- ベンダーは決まっているか
自社体制
- プロジェクト責任者はいるか
- 業務担当者はいるか
- システム開発経験者はいるか
- ベンダー窓口はいるか
PMOに任せたいこと
- 要件整理
- RFP
- ベンダー選定
- 進捗管理
- 課題管理
- 成果物レビュー
- 受入支援
権限
- PMOが直接ベンダーへ指示できるか
- 仕様変更を誰が承認するか
- 追加費用を誰が承認するか
- リリースを誰が判断するか
PMO支援に関するよくある質問
PMOは小規模システムでも必要ですか？
必ずしも必要ではありません。
発注者1名・開発者1名など役割が明確な小規模開発なら、正式なPMOを置く必要性は低いでしょう。
一方、小規模でも発注者側にシステム開発経験がなく、要件・ベンダー管理に不安がある場合は、部分的なPMO支援が有効です。
PMOだけ外注できますか？
可能です。
システム開発会社とは別に、発注者側の立場でPMO・PM支援を依頼する方法があります。
要件定義だけPMOへ依頼できますか？
可能です。
業務ヒアリング、要件整理、RFP作成まで支援してもらい、その後の開発は別ベンダーへ発注する方法もあります。
ベンダー選定前からPMOを入れた方がよいですか？
要件整理やRFP作成に不安があるなら、選定前から入れるメリットがあります。
依頼条件を整理したうえで相見積もりを取れるためです。
PMOは開発会社と技術的な話もできますか？
担当者によります。
システム開発PMOを依頼する場合は、PM経験だけでなく、要件定義・設計・開発工程への理解があるか確認するとよいでしょう。
hiro-dev-labのPM・PMO・システム開発支援
hiro-dev-labでは、Webシステム・業務システムについて、実装だけでなく、発注者側の要件整理・プロジェクト推進も支援できます。
例えば、
- 現状業務ヒアリング
- As-Is・To-Be業務整理
- 業務要件・機能要件整理
- 開発スコープ整理
- RFP・見積依頼内容の整理
- ベンダーとの仕様調整
- 進捗・課題管理
- 成果物レビュー
- 受入条件整理
- Webシステム設計・開発
などを検討できます。
例えば、
「開発会社は決まっているが、自社側にプロジェクトを管理できる人がいない」
という場合でも、
発注者側：事業・業務判断
PMO支援：要件・進捗・課題・ベンダー管理
開発会社：設計・開発
という体制で進められます。
PMO支援の価値は「管理作業を代行すること」だけではない
PMOというと、
- スケジュール表を更新する
- 会議を設定する
- 議事録を書く
といった事務的な業務をイメージされることがあります。
もちろんこれらもPMO業務の一部です。
しかしシステム開発において特に価値が出るのは、
発注者が正しい意思決定をできるように、情報を整理すること
です。
例えば、
「開発が遅れています」
だけではなく、
「基本設計が5日遅れており、このままではテスト開始も5日遅れます。リリース日を維持するには、機能Aを次期開発へ移すか、開発体制を増やす判断が必要です」
まで整理します。
同様に、
「追加費用80万円です」
ではなく、
「当初スコープ外の機能で、今回追加すると80万円・2週間の影響があります。現在の業務は手作業で代替できるため、Phase 2へ送る選択肢があります」
まで整理します。
PMO支援でできることは、
- 業務・要件を整理する
- 開発会社へ正確に伝える
- スケジュール・進捗を確認する
- 課題・リスクを可視化する
- 仕様変更を管理する
- ベンダーの成果物を確認する
- 受入テストを支援する
- 意思決定に必要な情報をまとめる
ことです。
特に、
社内にシステム開発経験者がいないが、開発を丸投げしたくない
という企業では、発注者側PMOを置くことが有効な選択肢になります。
「開発会社とのやり取りを任せたい」
「要件がまとまっていない」
「プロジェクトが遅れているが原因が分からない」
「発注者側のPM・PMOとして支援してほしい」
といった段階からでも、現在のプロジェクト状況を整理できます。
PMO・要件定義・業務システム開発について相談する