プロジェクトの統括責任者
QCD、計画、体制、リスク、顧客調整を見ながらプロジェクト全体を成功に導く役割。
- 案件概要: PM、PL、プロジェクト推進
- 見る点: 責任範囲、規模、意思決定経験
01 / Why
この領域を営業が知る意味
PM・PMO案件では、言語やフレームワークの一致だけでは判断できません。 「どの工程を、どの立場で、どの規模まで動かしたか」を読み取れる営業ほど、提案の精度が上がります。
営業が見るべき中心は「管理経験の中身」
PM経験と書かれていても、実態は進捗管理だけのこともあれば、要件定義、見積もり、ベンダー管理、 ステークホルダー調整まで担っていることもあります。肩書きより、任された範囲を確認します。
営業向けポイント
PM・PMOは「できる作業」ではなく「任せられる責任範囲」で評価されます。
02 / Overview
PM・PMOの概要
まずは役割の違いを押さえます。営業実務では、PM、PMO、PdM、POを混同しないことが重要です。
PMを支援し標準化する役割
進捗・課題・会議体・資料・ルール整備を通じて、PMや複数PJを横断的に支える役割。
- 案件概要: PMO支援、PM補佐、PMO事務局
- 見る点: 管理表、会議運営、横断調整
プロダクトの成長を決める役割
市場、KPI、ロードマップ、顧客価値を見て「何を作るべきか」を決める役割。
- 案件概要: プロダクト企画、PdM支援
- 見る点: KPI、仮説検証、事業視点
アジャイル開発の要件決定者
バックログの優先順位や受入基準を決め、開発チームが次に作るものを明確にする役割。
- 案件概要: PO、スクラム、バックログ管理
- 見る点: 優先順位付け、受入判断
ウォーターフォールとアジャイルは、案件の進め方を読む言葉
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | 要件、設計、開発、テストを順番に進める | 短い期間で作って確認するサイクルを回す |
| 案件概要での出方 | 要件定義、基本設計、結合テスト、V字モデル | スクラム、スプリント、バックログ、PO、SM |
| PM/PMOに求められること | 計画精度、変更管理、ドキュメント管理 | 優先順位調整、素早い合意形成、継続改善 |
03 / PMO Types
PMOは一種類ではない
案件概要に「PMO支援」と書かれていても、実態はかなり幅があります。 新人営業は、PMOという肩書きではなく、管理対象・報告相手・判断範囲を確認することが重要です。
会議と管理表を正確に回す
議事録、会議調整、進捗表更新、各種管理表の整備が中心。
- 提案できる人材
- 若手PMO、PMO補佐、アシスタント経験者
- 営業の見方
- 正確性、調整力、ドキュメント作成力を見る。
遅延・課題に自分で動く
課題管理、WBS、リスク管理、ベンダー調整、会議体運営まで担う。
- 提案できる人材
- 自走できるPMO、開発PM補佐、リーダー経験者
- 営業の見方
- 更新作業だけでなく、遅延・課題に対して自分で動いた経験があるかを見る。
複数PJを横断して整える
複数PJ管理、標準化、経営層報告、複数ベンダー管理、全体進捗管理を担う。
- 提案できる人材
- 上級PMO、PMOリード、大規模PJ経験者
- 営業の見方
- 報告相手、調整範囲、意思決定への関与度を見る。
業務課題を整理して推進する
業務改善、As-Is/To-Be、施策推進、課題整理、業務部門との調整が中心。
- 提案できる人材
- 業務コンサル、ITコンサル、DX推進PMO
- 営業の見方
- 単なる管理ではなく、業務課題の整理や改善提案までできるかを見る。
PMO支援という言葉だけで判断しない
「PMO支援」と書かれていても、議事録中心の事務局型から、経営層報告を含む横断PMOまで幅があります。 新人営業は、PMOという肩書きではなく、管理対象・報告相手・判断範囲を確認することが重要です。
04 / Foundation
プロジェクトマネジメントの基礎
PM・PMO案件を読む時は、まず「プロジェクトとは何か」「何を管理しているのか」を押さえます。 新人営業は、PMBOKの細かい知識を暗記するより、案件概要に出る管理対象を理解することが大切です。
プロジェクトとは、期限つきで成果物を作る活動
プロジェクトは、開始と終了があり、目的・範囲・期限・予算が決まっている活動です。 たとえば「新しい販売管理システムを半年で導入する」「既存の基幹システムを刷新する」 「社内申請を電子化する」などが該当します。
営業としては、候補者が単なる定常運用ではなく、期限・体制・成果物がある活動の中で どの役割を担ったのかを確認します。
QCDはPM案件の共通言語
- Quality
- 品質。要件通りに作れているか、不具合や手戻りが少ないか。
- Cost
- コスト。予算、人員、工数が想定内に収まっているか。
- Delivery
- 納期。スケジュール通りにリリースや納品ができるか。
案件概要では
「QCD管理」「進捗・課題・リスク管理」「PMBOK知識」「ステークホルダー調整」といった言葉で出ます。
スキルシートでは
管理した対象が、品質だけか、納期だけか、コストや体制まで含むかを読みます。
面談では
「遅延した時に、QCDのどこに影響が出ると判断しましたか」と聞くと経験の深さが出ます。
PMBOKの知識エリアは、営業にとって「管理対象の一覧」
| 知識エリア | ざっくり意味 | 案件概要・面談での見方 |
|---|---|---|
| スコープ管理 | 作る範囲、やらない範囲を決める | 仕様変更や追加要望をどう管理したか確認する |
| スケジュール管理 | 作業順序、期限、遅延を管理する | WBSやガントチャートを作ったか、更新だけかを見る |
| コミュニケーション管理 | 会議体、報告、関係者間の情報共有を設計する | 誰向けに、どんな頻度で、何を報告していたか聞く |
| リスク管理 | 起きる前の問題を洗い出して対策する | 課題管理だけでなく、リスクの予防経験があるかを見る |
| ステークホルダー管理 | 顧客、現場、開発、ベンダーなど関係者を調整する | 対立や優先順位のズレをどう整理したか聞く |
05 / Requirements
要件定義と設計を営業向けに理解する
PM・PMO案件で「要件定義経験」が出てきたら、営業は必ず深掘りします。 要件定義は、単に要望を聞く作業ではなく、「何を作るか」を合意できる形にする工程です。
ヒアリング
現場、事業部、情報システム部などから課題や要望を集める。
整理
要望を機能要件・非機能要件・制約条件に分ける。
文書化
要件定義書、業務フロー、画面一覧、受入条件に落とす。
合意
レビューし、承認を取り、後続工程の基準にする。
機能要件と非機能要件
| 区分 | 意味 | 具体例 | 営業が聞くこと |
|---|---|---|---|
| 機能要件 | システムが何をするか | 検索、登録、承認、CSV出力、メール通知 | 誰に何を聞き、どう要件に落としましたか |
| 非機能要件 | システムがどう動くべきか | レスポンス3秒以内、稼働率、セキュリティ、同時接続数 | 性能・運用・セキュリティ面の確認経験はありますか |
基本設計
ユーザーや顧客に説明できる外側の設計。画面、帳票、API概要、業務フローなど。
詳細設計
開発者が実装するための内側の設計。DB、処理フロー、クラス、バッチなど。
提案時の見せ方
要件定義から基本設計まで顧客合意を進めた経験がある、と補足できると強い。
誤解しやすい注意点
「要件定義に参加」と「要件定義を主導」は別物です。 会議に同席して議事録を取ったのか、ヒアリング設計から合意形成まで担当したのかで、提案できる案件が変わります。
06 / Planning
WBS・ガントチャート・リスク管理
PMO案件で多く出るのが、進捗管理や課題管理です。 ただし、管理表を更新するだけなのか、計画を作り、遅延を検知し、対策まで動かしたのかでレベル感が変わります。
WBSは「作業の分解表」
WBSは、プロジェクトで必要な作業を大タスク、中タスク、小タスクに分解するものです。 作業を分解することで、抜け漏れ、担当者、工数、期限を見えるようにします。
スキルシートに「WBS作成」とあれば、営業は「ゼロから作ったのか」「既存WBSを更新したのか」 「担当者や工数まで設計したのか」を確認します。
ガントチャートは「スケジュールの見える化」
ガントチャートは、タスクを時間軸に並べたスケジュール表です。 依存関係、マイルストーン、遅延影響を確認するために使われます。
PM/PMO候補者には、単に線を引いた経験ではなく、遅延時にクリティカルな作業を見つけて調整した経験があるかを聞きます。
類推見積もり
過去の類似案件から概算する。初期段階では使いやすいが、精度は粗くなりやすい。
ボトムアップ見積もり
WBSのタスクごとに積み上げる。手間はかかるが、説明しやすく精度も上げやすい。
三点見積もり
楽観値、最頻値、悲観値で見る。不確実性が高い作業のリスクを説明しやすい。
課題管理とリスク管理の違い
| 区分 | 意味 | 面談で聞くこと |
|---|---|---|
| 課題管理 | すでに起きている問題を管理する | 課題の優先順位、担当者、期限をどう決めましたか |
| リスク管理 | これから起きるかもしれない問題を事前に扱う | どんなリスクを事前に洗い出し、どう予防しましたか |
| エスカレーション | 自分たちで解決できない問題を上位者へ上げる | どの基準で、誰に、どんな情報を添えて上げましたか |
07 / Documents
UML・ドキュメント管理の見方
PM・PMOはコードを書かなくても、システムの構造や業務フローを図や文書で理解する必要があります。 営業は、候補者が「どのドキュメントを扱い、誰に説明していたか」を確認します。
ユースケース図
ユーザーとシステムの関わりを表す。要件定義や業務整理で使われる。
アクティビティ図
業務フローや処理の流れを表す。As-Is/To-Be整理と相性が良い。
シーケンス図
システム間のやり取りを時系列で表す。API連携や処理順序の確認で出る。
ER図
データベースのテーブル関係を表す。データ移行やBI案件でも見かける。
PM・PMOがよく扱うドキュメント
| ドキュメント | 用途 | 営業の確認ポイント |
|---|---|---|
| プロジェクト計画書 | 体制、スコープ、スケジュール、進め方を定義する | 作成したのか、レビューしたのか、更新だけか |
| 要件定義書 | 機能・非機能・業務要件を合意する | ヒアリングから書いたのか、修正中心か |
| 議事録 | 決定事項、TODO、未決事項を残す | 単なる記録か、次アクション管理までしたか |
| 課題管理表 | 課題、担当者、期限、ステータスを管理する | 課題の整理・優先順位付けまでしたか |
| テスト計画書 | テスト範囲、観点、体制、スケジュールを決める | 受入テストや品質管理の経験があるか |
08 / Validation
PoC・MVP・RFP/RFIを案件文脈で読む
これらはPM・PMO案件でよく出る略語です。 営業は意味だけでなく、候補者が「検証」「市場投入」「調達」のどこに関わったかを見る必要があります。
PoC
技術的に実現できるかを小さく検証する。AI、データ、クラウド、外部API連携などで出やすい。
聞くこと検証目的、期間、Go/No Go判断、検証結果のまとめ方。
MVP
最小限の機能で市場やユーザーに出し、反応を見ながら改善する。Webサービスや新規事業で出やすい。
聞くこと何を最小機能にしたか、KPI、ユーザー反応、改善サイクル。
RFI / RFP
ベンダー選定や調達のための依頼書。情報収集がRFI、提案依頼がRFP。
聞くこと作成側か回答側か、要件整理、評価基準、ベンダー比較。
提案時の補足に使える見方
PoC経験者は「不確実性の高い案件で検証観点を整理できる人材」として、RFP経験者は 「要件整理とベンダー比較を理解している人材」として補足できます。
09 / DX
DX・As-Is/To-Be分析の押さえ方
DX案件では、単なるIT化ではなく、業務やビジネスの変化を伴うことが多くなります。 PM・PMOには、現場、経営、IT部門の間に立つ調整力が求められます。
デジタイゼーション
紙や手作業を電子化する。例: 紙申請をWebフォームにする。
デジタライゼーション
デジタル技術で業務プロセスを改善する。例: 承認フローを自動化する。
デジタルトランスフォーメーション
ビジネスモデルや働き方そのものを変える。例: データを使って新しい収益モデルを作る。
As-Is / To-Beは業務改善の出発点
As-Isは現在の業務やシステムの状態、To-Beは将来あるべき姿です。 その差分が、プロジェクトで解決すべき課題になります。
営業が確認すること
候補者が現場ヒアリング、業務フロー作成、課題一覧化、施策の優先順位付けのどこまで担当したかを聞きます。 DX案件では、技術名よりも業務理解と関係者調整の具体性が強い提案材料になります。
10 / SES Use Case
SES案件での使われ方
PM・PMOは、開発プロジェクト、基幹システム刷新、DX推進、ベンダー管理などで募集されます。
プロジェクト推進
進捗、課題、リスク、会議体を回し、遅延や認識ズレを早めに潰す。
要件定義・設計支援
業務ヒアリング、要件整理、要件定義書、基本設計、受入条件を整える。
ベンダー管理
複数ベンダーの進捗、成果物、品質、問い合わせ、調整事項を管理する。
DX・業務改善
As-Is/To-Beを整理し、現場とIT部門の橋渡しとして推進する。
11 / Job Description
案件概要でよく見るキーワード
キーワードは単語で覚えるより、「何を任せたい募集なのか」に置き換えて読みます。
役割
PMPMOPM補佐PLディレクターベンダーコントロール
工程・成果物
要件定義基本設計WBSガントチャート課題管理表議事録RFP
進め方・ツール
ウォーターフォールアジャイルスクラムJiraBacklogConfluenceTeams
案件文脈
DX推進基幹刷新業務改善受入テストステークホルダー調整英語
誤解しやすい注意点
「PMO支援」は事務作業だけとは限りません。経営層向け報告、複数PJ横断、品質管理、ベンダー調整まで求められる案件もあります。 逆に「PM」と書かれていても、実態は進捗管理中心の補佐ポジションの場合もあります。
12 / Reading Drill
案件概要をその場で読み解く練習
新人営業がつまずきやすいのは、キーワードを知っていても「結局どんな人を探せばよいか」に変換できないことです。 ここでは案件概要に出やすい書き方を、提案要件へ読み替えます。
案件例①
基幹システム刷新 PMO支援
- 作業内容
- 進捗・課題・リスク管理、会議体運営、ベンダー調整、経営層向け報告資料作成
- 必須
- 大規模PJでのPMO経験、WBS/課題管理表の運用、顧客折衝、PowerPoint資料作成
- 尚可
- 基幹システム刷新、受入テスト、複数ベンダー管理、会計・販売管理の業務知識
これは「事務局」ではなく横断PMO寄り
経営層向け報告、複数ベンダー調整、リスク管理があるため、議事録・日程調整だけの候補者では弱いです。
スキルシートでは成果物名を見る
WBS、課題管理表、リスク管理表、週次報告資料、ステコミ資料など、実際に扱った資料名があるか確認します。
面談では「報告の相手」を聞く
PMだけに報告していたのか、部長・役員・顧客責任者向けに説明していたのかでレベル感が変わります。
案件概要の言葉
「ベンダーコントロール」
営業が確認する意味
進捗を聞くだけか、品質・納期・仕様差分まで詰めていたか。
カウンセリング質問
ベンダーから遅延報告が来た時、どの情報を確認して、誰にどう報告しましたか。
提案コメント
複数ベンダーの進捗・課題を横断管理し、遅延時の影響範囲整理まで対応しています。
案件例②
新規Webサービス開発 PO支援
バックログ管理、スプリント計画、受入基準整理、ユーザー部門との要件調整。 Jira / Confluence利用。PdMやデザイナーとの連携経験歓迎。
営業の読み替え
これは進捗管理PMOより、プロダクト寄りの調整ポジション。候補者にはアジャイル用語を知っているだけでなく、優先順位付けや受入判断の経験が必要です。
案件例③
DX推進 As-Is / To-Be整理
現場ヒアリング、業務フロー作成、課題一覧化、施策優先順位付け、経営層向け報告。 業務改善またはシステム導入PJ経験歓迎。
営業の読み替え
技術PMというより業務整理・合意形成が中心。現場から情報を引き出し、業務フローや課題に落とせる候補者が合います。
13 / Domain
代表的な案件領域
PM・PMOは業界知識との相性が出やすい領域です。候補者の経験業界も合わせて確認します。
基幹システム刷新
販売、会計、人事、在庫など。ウォーターフォール、要件定義、ベンダー管理の比重が高い。
Webサービス開発
アジャイル、PdM/PO、バックログ、KPI、ユーザー改善の経験が評価されやすい。
DX・業務改善
As-Is/To-Be、業務フロー、現場ヒアリング、部門間調整が重要になる。
データ・BI導入
DWH、BI、MA、レポート設計など。業務側とデータ活用側の橋渡し経験を見る。
14 / Skill Sheet
スキルシートの読み方
肩書きだけではなく、担当工程、成果物、規模、相手、ツール、トラブル対応の具体性を見ます。
まず見る項目
深掘りしたい項目
| 記載例 | 営業の読み方 | 面談で確認すること |
|---|---|---|
| PMOとして進捗管理を担当 | 管理表更新だけか、会議運営や改善提案までしたかを見る | 遅延検知後、誰に何を提案したか |
| 要件定義を担当 | ヒアリング、整理、文書化、合意形成のどこまで担ったかを見る | 機能要件と非機能要件をどう整理したか |
| ベンダーコントロール | 進捗確認だけか、品質・課題・契約範囲まで調整したかを見る | ベンダーと顧客の意見が割れた時の対応 |
スキルシートで強いサイン
- 「作成」「設計」「改善」「標準化」など、本人が組み立てた言葉がある
- 会議体、報告資料、管理表、成果物レビューなど、運用の具体名がある
- 顧客、情シス、業務部門、開発チーム、ベンダーなど、調整相手が明確
- 遅延、仕様変更、品質問題、優先順位変更への対応が書かれている
追加確認したいサイン
- 「PMO」「管理」「調整」だけで、何を管理したかが書かれていない
- ツール名は多いが、運用設計や改善経験が見えない
- 要件定義と書いてあるが、ヒアリング・文書化・合意形成の範囲が不明
- 規模、人数、期間、ベンダー数、報告相手が書かれていない
そのまま聞ける一言
スキルシート上ではPMOとありますが、管理表を更新する立場だったか、管理ルールや会議体を設計する立場だったか、どちらに近いですか。
深掘りの一言
その時に作っていた資料を、案件側に説明するとしたら、何のための資料で、誰が見て、どう意思決定に使っていましたか。
Skill Sheet Drill
記載例を△ / ○ / ◎で読む
スキルシートは、書いてある言葉をそのまま信じるのではなく、どこまで本人が担ったかを読み替えます。 下の例は、実際の候補者確認で使える判断の型です。
「PMOとして進捗管理・課題管理を担当」
△
管理表の更新、会議の日程調整、議事録作成が中心。PMの指示で動いていた。
○
進捗遅延や課題を整理し、PMへ報告。週次会議でステータス確認まで担当。
◎
会議体や管理フォーマットを設計し、遅延・課題・リスクを横断管理。影響範囲と対応案まで提示。
聞くこと: 管理表は誰が設計しましたか。遅延を見つけた後、何を判断しましたか。
「要件定義から基本設計まで対応」
△
要件定義会議に参加し、議事録や資料修正を担当。判断や合意形成は別担当。
○
業務部門へヒアリングし、機能要件・非機能要件を整理。要件定義書へ反映。
◎
As-Is/To-Be、業務フロー、受入条件、変更影響まで整理し、顧客合意の場を主導。
聞くこと: ヒアリング設計、要件整理、レビュー、承認のどこを主担当で行いましたか。
「ベンダー調整・顧客折衝を担当」
△
ベンダーから状況を聞き、顧客へ共有。伝言役に近い。
○
進捗・課題・QAを整理し、顧客とベンダーの認識合わせを実施。
◎
品質・納期・仕様差分・契約範囲を踏まえて論点整理し、代替案や優先順位調整まで実施。
聞くこと: 意見が割れた時、何を判断軸にして落とし所を作りましたか。
「DX推進プロジェクトに参画」
△
DX案件の会議体に参加。作業内容は資料作成や進捗確認が中心。
○
現場ヒアリング、課題一覧、業務フロー整理、施策管理を担当。
◎
経営課題と現場課題をつなぎ、As-Is/To-Be、ロードマップ、優先順位、関係者合意まで推進。
聞くこと: 単なるIT化ではなく、業務や組織の何を変えるプロジェクトでしたか。
15 / Interview
登録面談で聞くこと
PM・PMO面談では、経験の有無よりも「自分の言葉で再現できるか」を確認します。
基礎確認
- PMとPMOの違いを、ご自身の経験に置き換えるとどう説明できますか。
- ウォーターフォールとアジャイル、どちらの案件経験が多いですか。
- 使っていた管理ツールは何ですか。入力だけか、運用設計もしていましたか。
- 議事録、課題管理表、WBSなど、主に作成していた成果物を教えてください。
実務深掘り
- プロジェクトが遅延した時、最初に何を確認し、誰にどう報告しましたか。
- 要件定義では、ヒアリング、整理、文書化、合意形成のどこを担当しましたか。
- ステークホルダーの意見が対立した時、どのように落とし所を作りましたか。
- ユーザー側、SIer側、ベンダー側のどの立場で動いていましたか。
面談での見極め
「やっていました」だけで止めず、成果物、関係者、判断したこと、困ったこと、改善したことを順番に聞きます。 上位層ほど、遅延・対立・変更・品質問題への対応を具体的に話せます。
面談で使う深掘りフレーズ
| 聞きたいこと | 質問例 | 見えること |
|---|---|---|
| 主体性 | その管理表はご自身で設計しましたか、既存フォーマットを更新しましたか。 | 自走PMOか、作業者寄りか |
| 調整力 | 顧客と開発側で意見が割れた時、どのように整理しましたか。 | 関係者調整や合意形成の経験 |
| 技術理解 | 要件定義で非機能要件はどこまで扱いましたか。 | 表面的な進行管理か、技術前提を理解しているか |
| 上位対応 | 経営層や部長クラスへの報告資料を作成・説明した経験はありますか。 | 上級PMO・大規模案件への適性 |
回答の見極め例: △ / ○ / ◎
面談では、正解を暗記しているかよりも、経験を具体的に説明できるかを見ます。 新人営業は、下のように「抽象度」「担当範囲」「再現性」で回答を評価します。
| 質問例 | 弱い回答 | 提案可能な回答 | 強く推せる回答 |
|---|---|---|---|
| WBSを作る手順を教えてください | タスクを一覧にして、期限を入れていました。 | 成果物から作業を分解し、担当者・工数・期限を入れて進捗管理していました。 | 要件や成果物からWBSを作り、依存関係・クリティカルな作業・マイルストーンまで設計し、遅延時は優先順位を調整していました。 |
| 要件定義で意識していたことは何ですか | お客様の要望を漏れなく聞くことです。 | 要望を機能要件と非機能要件に分け、要件定義書に落としてレビューしていました。 | 現場・情シス・開発側の認識差を整理し、業務フロー、受入条件、変更時の影響範囲まで合意できるように進めていました。 |
| プロジェクトが遅延した時、どう対応しましたか | 関係者に確認して、急いで対応しました。 | 遅延原因を確認し、課題管理表に整理して、PMや関係者へ報告しました。 | 遅延原因、影響範囲、代替案を整理し、QCDのどこに影響するかを示したうえで、追加要員・スコープ調整・期限変更の選択肢を提示しました。 |
| ステークホルダーの意見が対立したらどうしますか | 双方の話を聞いて調整します。 | 論点を整理し、優先順位や制約を確認して、会議で合意を取りました。 | 対立の背景を業務目的・予算・納期・品質に分けて整理し、決定者、判断基準、持ち帰り事項を明確にして合意形成しました。 |
| PMOとして何を担当していましたか | 進捗管理や議事録作成をしていました。 | 進捗・課題管理、会議運営、資料作成、関係者への報告を担当していました。 | PMO事務局として会議体設計、管理フォーマット整備、複数チームの進捗・課題・リスクの横断管理、経営層向け報告まで担当していました。 |
16 / Level
レベル感の見極め
PM・PMOのレベルは、経験年数よりも「任された範囲」と「判断の重さ」で見ます。
PMOアシスタント
議事録、進捗更新、課題管理表の入力、会議調整が中心。指示を受けて正確に回せる。
提案しやすい案件PMO補佐、進捗管理支援、事務局運営、ドキュメント整備。
小中規模PM / 自走PMO
WBS作成、課題整理、顧客折衝、要件定義支援を一人称で進められる。
提案しやすい案件業務改善PMO、開発PM補佐、ベンダー調整、受入テスト推進。
大規模PM / 横断PMO
複数チーム、複数ベンダー、経営層報告、リスク管理、見積もり、方針決定まで担う。
提案しやすい案件大規模刷新、DX推進、複数PJ横断、PMOリード。
PMOの種類とレベル感をつなげて見る
- 初級: 事務局型PMO、PMOアシスタント。正確な議事録、管理表更新、会議調整が中心。
- 中級: 管理推進型PMO、自走PMO。課題管理、WBS、リスク管理、ベンダー調整まで動ける。
- 上級: 横断PMO、PMOリード。複数PJ、経営層報告、標準化、全体進捗管理を担う。
- コンサル寄りPMO: 業務改善・DX推進・As-Is/To-Be経験がある場合に強い。
17 / Mismatch
営業がミスりやすいPM・PMO提案
PM・PMO提案は、肩書きだけで判断するとミスマッチが起きやすい領域です。 失敗しやすいパターンを先に知っておくと、面談で確認すべきポイントが見えます。
新人がやりがちなミスマッチ
| よくあるミス | なぜ危ないか | 面談で確認すること |
|---|---|---|
| PMO補佐を上級PMO案件に提案する | 経営層報告や横断調整ができずミスマッチになる | 報告相手は誰だったか、複数チームを見ていたか |
| PM経験ありだけで提案する | 実態が進捗更新や補佐中心の可能性がある | 何を意思決定し、どこまで責任を持ったか |
| Jira経験ありだけでアジャイル案件に提案する | ツール入力だけで、スクラム理解がない可能性がある | スプリント計画、バックログ管理、受入基準に関わったか |
| 要件定義経験ありを鵜呑みにする | 会議同席だけか、主導したかでレベルが大きく違う | ヒアリング、整理、文書化、合意形成のどこを担当したか |
| WBS更新経験をWBS作成経験として提案する | 計画設計力が求められる案件では不足する | ゼロから作ったか、既存表の更新だけか |
| ベンダーコントロール経験を浅く見る | PMO案件では重要な差別化要素になる | 進捗確認だけか、品質・納期・仕様差分まで管理したか |
18 / Proposal
提案時の注意点と補足コメント例
提案では「PM経験あり」ではなく、案件側の不安を埋める材料を添えます。
提案時の注意点
- PM、PMO、PL、ディレクターを同じ意味で提案しない。
- 管理ツール名だけで強みと判断しない。運用設計経験まで確認する。
- DX案件では、技術理解だけでなく業務部門との調整経験を補足する。
- 要件定義経験は、合意形成まで含むかを確認してから出す。
19 / Check
確認テスト
研修後に、案件概要・スキルシート・面談・提案の判断軸が残っているかを確認します。 回答を暗記するより、自分の言葉で説明できるかを見ます。
1. PMとPMOの違いを一言で説明してください。
回答の観点:
PMはプロジェクト全体の責任者、PMOはPMや複数PJを支援・標準化・推進する役割。
2. 「PMO支援」と書かれた案件で、必ず確認すべきことは何ですか。
回答の観点:
事務局型か、管理推進型か、横断PMOか。管理対象、報告相手、判断範囲を確認する。
3. 「WBS更新経験」と「WBS作成経験」は何が違いますか。
回答の観点:
更新は既存表のメンテナンス中心。作成は作業分解、担当、期限、依存関係、工数を設計する経験。
4. 横断PMOに提案するには、どんな経験が必要ですか。
回答の観点:
複数チーム・複数ベンダー管理、経営層報告、リスク管理、標準化、全体進捗管理など。
5. 提案コメントで「PM経験あり」だけでは弱い理由は何ですか。
回答の観点:
PMという肩書きだけでは、実際の責任範囲・意思決定経験・規模・成果物が分からないため。
20 / Summary
まとめ
PM・PMOの提案精度は、肩書きではなく経験の粒度を読めるかで変わります。
案件概要
役割、工程、規模、進め方、成果物、調整相手を確認する。
スキルシート
担当した範囲、成果物、判断経験、トラブル対応の具体性を見る。
登録面談
「何をしたか」から「どう判断したか」まで掘り下げる。
提案
案件側の不安に対して、任せられる根拠を短く補足する。
会話で使える提案コメント