経営層を動かすPMO報告・意思決定の実務大全――報告・決裁・合意形成を止めない実践キット【Excel12シート付】
「報告したのに、何も決まらない」
PMやPMOの仕事をしていると、この言葉の重さを知ることになる。
毎週、進捗会議を開く。赤信号の課題には担当者と期限を付ける。経営会議向けの資料も何度も修正する。それなのに、いちばん重要なことが決まらず、現場だけが消耗していく。
なぜか。
問題を十分に報告していないからとは限らない。経営層が「何を、どの選択肢から、いつまでに、どの権限で決めればよいのか」を判断できる状態にしていないからだ。
私は経営、ITコンサルティング、プロジェクトマネジメントに携わり、30名規模のPMO組織の立ち上げも経験してきた。その経験から強く思うのは、PMOの価値を報告書の枚数や会議の回数で測ってはいけない、ということだ。
経営層が正しく判断し、その決定が現場で実行されて初めて、報告には意味が生まれる。
本記事では「資料の作り方」だけでなく、判断事項の選別、決裁権限の確認、選択肢の比較、反対意見の整理、経営会議の運営、決定後の実行管理、改善効果の測定までを一つにつなぐ。その考え方と実践事例、図解、Excelの使い方は全文無料で公開する。末尾の有料エリアで販売するのは、実際に編集して使えるExcelテンプレート12シートのファイルだけだ。
ただし、先に断っておく。ここで示す管理手法は、私の実務経験を踏まえた提案であり、PMIなどの公式テンプレートを転載したものではない。特定企業の未公開資料や、実際には測定していない成果を「実績」として紹介することもしない。後半の追加仕様の事例と数値は、手順を理解するための仮想事例である。
最初に結論――経営報告は「状況説明」ではなく「意思決定の依頼書」にする
経営層に対する報告で、私が最初に確認するのは五つだ。
誰が／何を／いつまでに／どの選択肢から／どんな根拠で決めるのか。
この五点がそろっていない資料は、どれほどグラフが美しくても「判断のための資料」にはなりにくい。
例えば、次の報告はよくある。
「開発工程が遅延しています。現在、関係部門と対応策を検討しています」
これでは、経営会議の出席者は「大変そうだ」ということしか分からない。
同じ問題でも、次のように書き換える。
「追加機能を今回のリリースに含めるか、11月13日までに承認方針を決める必要があります。A案は次期リリースに分離、B案は追加対応と納期変更、C案は追加要員を再検証する方法です。現時点では品質と既存計画を維持しやすいA案を推奨します。ただし、顧客との契約変更の要否は未確認であり、正式合意前の作業着手はできません」
判断事項、選択肢、期限、推奨、未確定事項がそろうと、経営層は「何を聞けばよいのか」が分かる。
重要なのは、PMOが経営層を言い負かすことでも、都合のよい結論へ誘導することでもない。正しい権限者が、事実に基づき、不利益も理解したうえで決定できるようにすることだ。
この記事で手に入るもの
この記事を読むだけでも、経営報告や意思決定の考え方を整理できる。一方、実際の現場へ展開するための作業を省けるよう、次の12シートをExcelで提供する。
単なる表の寄せ集めではなく、案件ID「D-001」を共通にして、判断事項・選択肢・合意事項・決裁結果がどの帳票へ流れるかを追えるようにした。特に「10_記入済_経営報告」には、白紙では分かりにくい1枚報告を記入済みの形で収めた。
いずれも、見るだけのサンプルではない。自分のプロジェクトに置き換え、列や運用ルールを調整できる実務用の原本である。
このExcelで何ができるのか――仮想案件D-001で購入前に見る
購入前に、付属Excelを使う場面を一件だけ想像してほしい。
例えば、基幹システムのリリース直前、顧客から追加機能を求められたとする。営業は「何とか応えたい」、技術は「試験期間を確保したい」、PMは「納期を守りたい」。会議では「関係者と調整中です」という報告が繰り返され、肝心の判断が進まない。
この場面では、まず「04_決裁権限」で社内と顧客の承認ルートを確認する。次に「02_意思決定台帳」にD-001として「追加機能を今回のリリースに含めるか」を登録。「03_選択肢比較」で、A案＝次期リリースへ分離、B案＝今回実装して納期を見直す、C案＝追加要員を検討する、という三つの案を並べる。見積、顧客の必須時期、契約変更の要否が分からなければ、推測で埋めず「未確認」と残す。
こうすると、単なる「調整中」が「誰が、何を、いつまでに判断できるようにするか」へ変わり始める。下の図は、その使い方を一件に絞って整理したものだ。
整理した情報を「01_経営報告1枚」にまとめれば、「A案は暫定推奨。ただし契約変更の要否と顧客の必須時期は未確認」と明示できる。経営会議の結果は「06_決裁と実行」に記録し、担当者と期限、実行状況を追う。ただし、社内決裁や必要な顧客合意が完了するまで、作業開始の許可が出たことにはしない。
このExcelは、AIが判断を代行する仕組みでも、すべてのシートを自動連携するシステムでもない。意思決定のための論点、権限、選択肢、証跡、実行担当を、迷わず確認するための実務用の型である。
販売するExcelには白紙の表だけでなく、「10_記入済_経営報告」に完成例、「11_会議運営台本」に会議前後の進め方、「00_スタート」に導入手順を収めている。まずはこの記事の第4章で判断事例を、第11章でExcelの実践手順を無料で確認してほしい。内容が自分の業務に合うと判断した場合に、末尾からExcelファイルを購入できる。
購入価格は24,900円。主な価値は文章量ではなく、既存の課題管理表から重要判断を抽出し、上程・承認・合意・実行確認までの帳票設計と運用手順を一式、再設計する手間を減らせることにある。支援なしでも導入できるように作ったが、実際の効果は組織・案件の状況によって異なる。
なお、テンプレートにある「決裁権限の例」は組織ごとの正式規程ではない。契約、職務分掌、承認規程、情報セキュリティルールを確認したうえで導入してほしい。
────────────
ここから第11章までは、判断事項の登録、対応案の比較、経営会議での承認・条件付承認・保留、決裁後の実行確認を、仮想案件D-001と図解を使って無料で解説する。Excelが自分の現場に必要かどうかを、最後まで読んで判断してほしい。
第1章 まず「問題管理」と「判断管理」を分ける
課題管理表には、数十件、ときには数百件の項目が並ぶ。しかし、その全部を経営会議に持ち込むべきではない。
現場の問題を、私は次の三つに分けて考える。
第一は、現場の委任範囲で解決できる問題。 例えば作業順序の変更、担当者間の調整、承認済み計画内での軽微な組み替えなどだ。ここまで経営会議に持ち込めば、PMの権限を弱め、判断の速度も落ちる。
第二は、PMや部門責任者の間で調整が必要な問題。 要員の優先順位、部門間の依存関係、限られた共通資源の配分などが該当する。決められた管理ルートで解消できるなら、そこを使う。
第三は、上位の権限者による判断が必要な問題。 重要な予算変更、顧客との契約変更、正式に承認された納期の変更、重大リスクの受容、継続・中止などだ。
経営報告に載せる優先順位が高いのは、第三の類型である。ただし、「重大そうだから上げる」のではない。何の権限を超えるのかを特定しなければならない。
私は、重要課題を意思決定台帳へ移す前に、次の七点が答えられるか確認する。
判断事項を一文で書けるか。
決定しない場合に、何が止まるか。
最後に安全に決められる日はいつか。
最終承認者は誰か。その根拠文書は何か。
少なくとも二つの現実的な選択肢があるか。
各案の不利益と残るリスクが書かれているか。
決定後に誰が何を実行するか。
これは「全部埋まるまで報告してはいけない」という意味ではない。未確認なら未確認と書く。しかし、判断の前提が足りないことを可視化せずに「承認してください」と迫ってはいけない。
付属Excelの「02_意思決定台帳」には、判断ID、判断事項、区分、重要度、判断期限、最終承認者、権限根拠、推奨案、判断状態、決定日、実行担当、実行期限、実行状態、未決定影響、証跡、期限状況を用意した。
最初から100件を登録する必要はない。まずは、現在のプロジェクトで経営判断が必要な案件を5件程度だけ選んでみる。期限が過ぎている案件、決定者が曖昧な案件がどれか、それだけでも運営上の弱点が見えてくる。
第2章 PMOが勝手に決めてはいけない――決裁権限を設計する
大きな組織ほど、会議の参加者が多い。困ったことに、参加者の多さと、決められる人がいるかどうかは別問題だ。
経営会議に出席している役員であっても、その案件の契約変更を承認する権限がないことはあり得る。PMOの責任者であっても、スポンサーから正式に委任されていれば一定の承認ができる場合もある。
だから私は「PMOだから決められない」「役員だから何でも決められる」という考え方を取らない。
決められる範囲は、正式な委任、組織規程、契約、プロジェクト憲章などで決める。
具体的には、次の五つを確認する。
① 判断対象。 予算、契約、スコープ、納期、品質、要員、業務運用など、何についての決定か。
② 許容範囲。 何円まで、何日まで、どの品質基準まで、といった権限の境界が既にあるか。数値閾値がなければ、無理に架空の基準を作らない。
③ 最終承認者。 推奨者、議長、事務局、最終決裁者を別々に記録する。たとえばPMOは資料をまとめて推奨を示せても、契約変更の承認者とは限らない。
④ 顧客の同意。 社内決裁が終わっても顧客との契約変更は成立していない場合がある。社内承認と対外的な合意を混同しない。
⑤ 不在時のルート。 承認者が出張中、休暇中、あるいは判断できないとき、誰が代理できるか。代理権限がないなら、勝手に代理承認したことにしない。
この整理に使うのが「04_決裁権限」シートだ。
たとえば「追加機能の受託」なら、PMは影響評価を行い、PMOは変更管理ルートを整え、スポンサーや契約権限者が所定の決裁を行い、顧客とも正式な変更合意を結ぶ、という流れが考えられる。
ただしこれは一例である。実運用では、誰が契約主体か、どの規程が優先するかを明示して初めて使える。
権限表を作る最大の効果は、誰が偉いかを整理することではない。権限がない人に判断を押し付けないこと、そして権限がある人の判断を不必要に待たせないことだ。
会議の議長、PMOの責任者、スポンサーが同席していても、それぞれが何を承認できるかは同じではない。顧客の契約条件が変わる場合には、社内決裁とは別に正式な顧客合意が必要になる点を、この図で二重に確認してほしい。
第3章 経営会議へ出す資料は1枚でよい。ただし、薄くしてはいけない
1枚にまとめるのは、「説明を省くため」ではない。経営層がその場で判断するために必要な情報を、見つけやすくするためだ。
私が推奨する1枚報告の構成は、次のとおりである。
冒頭：今回決めてほしいこと。 「A案を採用する」「追加予算の上限を決める」など、決裁動詞まで書く。
事実：何が起きているか。 現状と根拠、確定していること、まだ確認していないことを分ける。
選択肢：A/B/C案の比較。 追加費用、納期影響、品質、事業価値、主要リスク、必要な合意を同じ尺度で記載する。
推奨：どの案を選ぶべきと考えるか。 推奨案だけでなく、なぜ他の案を推奨しないか、何が欠点かを書く。
期限：いつまでに決定するか。 単なる会議の日程ではなく、判断が遅れることで選択肢が失われる期限にする。
決定後：誰が何を変えるか。 WBS、体制、契約、テスト計画、顧客説明など、影響先を記録する。
「01_経営報告1枚」は、この順番で項目を配置した。
会議で読む資料に、すべてのログを貼る必要はない。根拠資料は別添にし、1枚目に判断を集約する。重要な争点が複数あるときは、無理に一件にまとめず、決定事項ごとに1枚を作る方がよい。
失敗しやすいのは「赤字」「遅延」「人手不足」の説明に時間を使い、最後に「ご意見をお願いします」と書いて終わることだ。それでは決裁依頼になっていない。
ただし、この図の「After」にも未確認事項が残っている。未確認事項を隠して承認を求めることは、改善ではない。 確認できていないと示し、必要なら当日の会議で「方針の正式決裁」ではなく「決裁に必要な調査・権限確認の承認」を依頼する。その切り替えが重要だ。
記入済みの1枚報告を見てほしい
白紙のフォームだけでは、経営層に実際何を出せばよいか分かりにくい。そこでExcelの「10_記入済_経営報告」に仮想案件D-001の完成例を追加した。判断期限は仮置き、顧客の必要時期と契約変更要否は未確認、A案の推奨は暫定という状態を意図的に残してある。
この完成例で最も重要なのは、未確認事項があるため、最終実装承認の段階にはまだ進めないと読めることだ。きれいな資料より、承認を止めるべき箇所が明確な資料の方が統制上の価値がある。
第4章 仮想事例――追加仕様の判断を経営会議で止めない
ここからは架空の基幹システム刷新プロジェクトを想定する。特定の顧客や実案件の再現ではなく、数字も実績ではない。
リリース前の段階で顧客から追加機能の要望が出た。技術部門は「実現可能かもしれないが、試験工程への影響を確認したい」と説明する。営業部門は「顧客の期待を損なわないようにしたい」と言う。PMは品質を確保したい。経営側には「この機能は本当に今回必要なのか」という疑問がある。
最初の会議では、次の報告しかなかった。
「追加機能のご要望について、関係者間で調整中です」
これでは何週間たっても決まらない。
そこで判断IDを「D-001」とし、「追加機能を今回のリリースに含めるか」を判断事項として切り出す。顧客との契約変更が必要かも未確認であることを明記する。
まず、選択肢を並べる
A案：次回リリースに分離する。
既存計画と試験範囲を守りやすい。一方、顧客が期待する便益は先送りになる。顧客との合意が必要である。
B案：今回実装し、納期を変更する。
追加要望を早期に実現する可能性があるが、再見積もり、試験期間、契約納期、要員費用の見直しが必要になる。
C案：追加要員を投入して納期維持を検討する。
一見すると魅力的だが、要員追加が納期短縮に直結するとは限らない。引き継ぎ、設計レビュー、統合テストがボトルネックかもしれない。確かな見積もりがない状態で採用はできない。
ここでの重要なポイントは、A案が常に正しいと決めつけないことだ。
顧客の業務が今回の追加機能なしでは成立しないなら、A案の事業上の不利益は大きい。C案が短縮できないと決めつける根拠もない。結論は、事業優先順位と実測・見積に照らして決める。
今回は説明のため、現時点ではA案を「暫定推奨」とする。
推奨理由は「既存納期と品質確保の両立を優先しやすいから」。残るリスクは「顧客便益の先送りと顧客合意」。未確認事項は「追加機能の必須時期、契約上の扱い、B/C案の確定見積」である。
次に、判断期限を決める
例として、11月13日を期限とする。
なぜその日か。「11月13日に会議があるから」では弱い。設計凍結や試験計画の確定など、その日を過ぎると選べなくなる案が何かを説明する必要がある。
「11月13日までに変更方針が決まらなければ、追加機能の設計着手条件を確定できず、計画を組み直す可能性がある」
ここまで説明できて、期限に意味が生まれる。
そして、権限者へ依頼する
この事例では、社内スポンサーと顧客の契約上の権限者の確認が必要だ。
PMOが経営会議の資料を作っても、PMOだけで「A案で決定」とは書かない。内諾があっても、必要な契約や正式承認が済むまでは、未決定または条件付承認として管理する。
こうして整理した結果、経営会議の依頼文は次のようになる。
「D-001について、追加機能を今回リリースに含めるかを11月13日までに判断してください。現時点ではA案を推奨します。ただし、顧客の必須時期と契約変更の要否は未確認です。承認後はPMが変更管理表、WBS、顧客説明計画を更新し、条件を満たしたことを確認します」
私は、この程度まで判断事項を絞ってから会議へ出す方が、資料を何十枚も増やすより意味があると考える。
仮想事例の記入先
「02_意思決定台帳」にD-001を登録し、「03_選択肢比較」にA/B/Cを並べ、「05_合意形成」に営業・技術・顧客の懸念を記録する。「01_経営報告1枚」で承認を依頼し、決定後に「06_決裁と実行」へ記録する。
「09_仮想事例」には、この一連の考え方を短い記入例として整理した。実際の案件に入れ替えて、同じ流れを試してほしい。
#### 現場で使うための「判断の条件分岐」
同じD-001でも、次のように結末は変わる。
この表は「決定した」という言葉を、現場で誤って解釈しないための最低限の分岐だ。
第5章 合意形成とは、全員に「賛成」と言わせることではない
部門間の対立で厄介なのは、表面的な賛成・反対の裏側に、別々の心配があることだ。
営業は「顧客との関係」を重視する。技術は「品質と実現性」を重視する。経営は「事業価値と投資」を重視する。それぞれが間違っているとは限らない。
ここでPMOが「皆さん、協力してください」と呼びかけても、論点は解消しない。
私なら最初に、反対の理由を五つに分解する。
事業価値／費用／納期／品質／権限と責任。
例えば技術部門がB案に反対しているとする。
「技術部門が保守的だから」と解釈してはいけない。追加開発そのものに反対なのか、十分な試験期間なしで受けることに反対なのかで、打ち手は違う。
後者なら、試験期間の確保ができれば調整の余地がある。
営業部門も同様だ。A案への反対理由が「今回の対応でないと顧客が困る」なら、顧客が必要としている業務開始日と代替運用の可能性を確認する。単純に「次回にしましょう」と説得するのでは不十分だ。
「05_合意形成」シートでは、関係者ごとに懸念、譲れない条件、調整可能な条件、代替案、必要な根拠、担当、期限、合意状況を記録する。
ここで注意したいのが、利害関係者の賛同と、最終決裁者による承認は別物だという点だ。
全員が納得していても、契約変更が正式に決まったことにはならない。逆に正式に承認されても、現場が理解しなければ実行できない。両方を扱う必要がある。
第6章 経営会議は「承認・差戻し・保留」を明確にして終える
会議の結果を「概ね了承された」と記録すると、後で問題が起きる。
「概ね」とは何か。何をしてよいのか。追加条件はあるのか。顧客に連絡してよいのか。誰が決めたのか。
私は、決定結果を少なくとも次の状態に区分することを勧める。
管理上の注意： 承認済・却下は「決定済」として扱う。一方、条件付承認は実行許可ではなく、条件が満たされるまで監視対象とする。付属Excelの期限判定式も、却下を未決定の期限超過として誤カウントしないよう改修した。
承認済： 正式な承認があり、必要な手続きと条件が満たされている。
条件付承認： 条件を満たした後に実行可能となる。条件未達で実行してはならない。
却下： 提案を採用しない理由や再提案の条件を記録する。
保留： 判断しない理由、足りない情報、再判断日を明確にする。
差戻し： 追加調査や選択肢の再検討が必要。誰がいつまでに修正するかを決める。
未決定： 判断前であり、決定済みのような表現をしてはいけない。
会議の最後に確認するのは、「どの案になったか」だけではない。
承認者、承認日時、承認の証跡、付された条件、現場への展開責任者、実行期限までセットで記録する。
決裁後の仕事は、PMOの議事録が完成した時点では終わらない。
契約変更が必要ならその手続きを確認する。工程が変わればWBSを修正する。品質条件が変われば試験計画を更新する。要員が変われば実際のアサインを確認する。
さらに、関係者へ伝達され、現場が新しい条件で動けることまで確かめる。
実行可否の最終確認では、①正式な承認証跡、②条件の達成、③必要な顧客同意、④契約・品質・工程の変更反映、⑤担当者と期限の確定を別々に見る。どれかが不足していれば、たとえ経営会議が好意的だったとしても、実行開始の可否を再確認する。
「決定済み」と「実行完了」は違う。「06_決裁と実行」シートに分けて記録したのは、この違いを現場で見落とさないためである。
第7章 PMOの価値を経営層へどう示すか
「PMOは必要なのか」と問われたとき、私は会議開催数や資料の作成枚数だけを説明することには賛成しない。
PMOの価値は、少なくとも判断の健全性と、決定後の実行を見て考えるべきだ。
付属Excelには、次の七つの基礎指標を設けた。
登録判断件数。 対象範囲内の判断事項はいくつあるか。
決定済件数。 正式な承認または却下まで進んだものはいくつか。
決定済率。 決定済件数÷登録判断件数。ただし、登録件数の定義が変われば単純比較できない。
期限超過未決件数。 期限を超えて判断が止まっているものはいくつか。
実行完了件数。 決裁後に必要な対応が完了した案件はいくつか。
実行反映率。 実行完了件数÷承認済件数（却下は分母から除外）。ただし、承認後の実行が不要な案件をどう扱うか、母数の定義は導入時に固定する必要がある。
未確認権限数。 誰が最終的に決めるか確認できていない判断領域がいくつあるか。
Excelの「07_効果測定」では、台帳に入力したデータを集計する。数字を後から手入力で「改善したこと」にしないためだ。
ただし、決定済率が高ければ優秀なPMOだとは限らない。判断が難しい案件を対象から外すだけでも数字は上がる。形式的な承認を急げば品質リスクが増える。
私は、速度だけを競う運用には反対だ。
なお、改善効果を金額換算する場合は、導入前の会議時間や手戻り工数、導入後の同じ指標を同一期間・同一母数で測り、人件費単価などの前提を明示する。未計測の「削減金額」を成果として書いてはいけない。
数字を読むときは、少なくとも「対象にした案件の範囲」「案件の難しさ」「承認の質」「決定後の実行状況」を一緒に確認する。経営層へ成果を説明するときも、削減工数や金額は実測に基づいて記載すべきだ。
第8章 最初の30日でどのように導入するか
大きなPMO改革を掲げて、一度に全体導入すると、帳票を増やすだけで終わりやすい。
私が勧めるのは、30日間の限定導入だ。
第1週：重要判断を棚卸しする
現在の課題表から、経営判断が必要な案件を選ぶ。最初は5件程度で構わない。各案件の判断事項、権限者、期限、未決定影響を記録する。承認規程と契約の確認を優先する。
合格条件： 判断IDごとに「誰が何をいつまでに決めるか」が示せること。示せない部分は要確認と記録する。
第2週：1枚報告を1つの会議で試す
最重要の判断事項を「01_経営報告1枚」にまとめ、会議で使う。選択肢比較表も別添として持参する。
合格条件： 会議の結果が承認・条件付承認・保留・差戻しなどに分類され、次の担当者と期限が決まること。無理に承認件数を増やす必要はない。
第3週：決定後の実行を追う
決まったことがWBS、契約、テスト計画、関係者連絡に反映されたかを確認する。証跡を残し、完了と判断する条件を事前に決める。
合格条件： 決裁済みの案件について、実行責任者、期限、実行状態、証拠が追えること。
第4週：経営層と振り返る
判断の滞留、権限不明、差戻し、実行未反映の件数を振り返る。改善の原因を断定せず、同じ条件で比較できる部分から検証する。
合格条件： 継続する仕組み、減らす帳票、追加で必要な権限確認を決められること。
経営会議を改善するときには、私なら「試行対象1案件→1会議→1実行→1回のレビュー」の順で始める。その運用を具体化したのが付属Excel「11_会議運営台本」だ。会議の2営業日前、当日の15分間、会議後24時間の確認事項を分けている。特に議長や決裁者が不在だった場合の「未決定」の扱いを曖昧にしない。
最初の30日で、すべての問題が解決するとは限らない。重要なのは「何も決まらない会議」を、「決まらない理由と、次に必要な行動が分かる会議」へ変えることだ。
第9章 AIで資料作成を速くしても、決裁を自動化してはいけない
生成AIは、会議メモから判断事項を抽出したり、A/B/C案の比較項目を整理したり、1枚報告の草案を作ったりできる。
しかし、私はここに明確な境界線を引く。
AIが「承認された」と書いても、実際に権限者が承認した事実にはならない。AIが「追加費用は500万円」と書いても、根拠資料がなければ推測にすぎない。
付属の「08_AI支援」では、単なる「良い報告書を書いて」という指示ではなく、次の制約をあらかじめ含めている。
事実・推測・未確認を区別すること。入力にない費用、日数、承認、顧客発言を創作しないこと。最終承認者が分からなければ「要確認」とすること。推奨案と承認済みを混同しないこと。
また、AIへ資料を入力する前に、顧客名、個人名、契約条件、機密情報の取扱いを社内ルールに従って確認する必要がある。
AIを導入する目的は、PMOから責任をなくすことではない。整理する仕事の負担を減らし、人間が事実確認、調整、判断の質に集中できるようにすることだ。
第10章 失敗する運用と、立て直すための処方箋
ここまでの仕組みは、運用を間違えると逆効果になる。私が特に避けたいのは、次の五つだ。
失敗1：全課題を経営判断に上げる
すべての案件を経営会議へ持ち込むと、上位者の負荷が増え、本当に重大な判断が埋もれる。
処方箋： 権限と許容範囲で案件を分け、委任範囲内の判断は現場へ返す。上位へ上げる理由は「重要そう」ではなく「権限や許容範囲を超えるから」と説明する。
失敗2：A案のメリットだけを書く
PMOが推奨したい案の利点だけを並べれば、会議で承認されやすいかもしれない。しかし、隠した不利益が後から表面化する。
処方箋： 各案を同じ尺度で比較し、推奨案の不利益・残余リスクも先に書く。
失敗3：会議での「了解」を正式承認にする
会議の雰囲気から実行指示を出すと、契約や品質の責任問題になる。
処方箋： 決裁者・条件・日付・証跡を記録し、必要な顧客合意を別に確認する。未確認なら「条件付」または「未決定」と明示する。
失敗4：決定後の実行を見ない
経営会議の議事録が完成しても、現場のWBSが古いままなら何も変わらない。
処方箋： 決定結果と実行タスクを別々に管理し、完了証拠まで追う。
失敗5：指標を良くするために判断を急ぐ
期限遵守率を上げることが目的になると、十分に調べないまま承認する危険がある。
処方箋： 決定までの速さと、承認根拠、関係者合意、実行反映を合わせて評価する。
第11章 付属Excel12シートの使い方――仮想案件D-001で実践する
Excelが12シートもあると、「全部を埋めないと使えないのでは」と身構えるかもしれない。そんな必要はない。まずは経営判断が止まっている案件を一件選び、判断の準備から決裁後の行動までをつなげればよい。
ここでは第4章の仮想案件D-001を使う。基幹システムのリリース直前、顧客から追加機能の要望が出た場面だ。納期、品質、顧客との約束が絡むため、PMだけでは決められない。記載する日付や数値は説明用の仮想例であり、正式な顧客合意や経営承認が得られた事例ではない。
まず、見本を見て全体像をつかむ
付属Excelを開いたら、最初に「00_スタート」を確認してほしい。ここに導入の順序と注意点をまとめてある。次に「10_記入済_経営報告」を見ると、D-001を経営層へどのような1枚資料で示すのかが分かる。すべてを白紙から考えるより、完成例を見てから自分の案件に置き換える方が早い。
① 「04_決裁権限」で、誰が決める問題なのかを確かめる
最初に確認するのは「追加機能を作れるか」ではなく、「追加機能を今回のリリースへ含めると、誰の承認が必要か」だ。D-001なら、PMは影響を評価し、PMOは判断材料を整理する。一方、追加仕様や契約変更の承認は、社内の決裁権者と顧客の契約上の権限者を確認しなければならない。
Excelの「04_決裁権限」で「追加仕様・契約変更」の行を開き、社内規程、承認の範囲、顧客合意の要否を確認する。根拠欄が「【自社規程記入】」、確認状態が「要確認」のままなら、承認権限が確定したことにはならない。まずは規程や契約を確認する担当者を決める。
② 「02_意思決定台帳」で、判断事項を一つに絞る
次にD-001を台帳へ登録する。判断事項は「追加機能を今回のリリースに含めるか」。判断期限は仮に2026年11月13日とする。ただし、この日を採用する根拠は、会議の日程ではなく、設計凍結や試験計画への影響を確認して決める必要がある。
ここで重要なのは、「追加仕様について調整中」と曖昧に書かないことだ。判断事項、期限、承認者、未決定の場合の影響を分けて記載する。権限が未確認ならそのまま未確認として扱い、判断状態は「未決定」のままにする。台帳に入力したから承認されたわけではない。
③ 「03_選択肢比較」と「05_合意形成」で、判断材料を整える
「03_選択肢比較」には、A案「次期リリースに分ける」、B案「今回実装し納期を見直す」、C案「追加要員で日程維持を検討する」を同じ判断IDで並べる。費用、納期、品質、顧客への影響を比較し、算定していない金額は「未算定」と明記する。現時点ではA案が暫定推奨だが、顧客の必須時期が分からない以上、最終判断ではない。
続いて「05_合意形成」を使う。営業は顧客との関係、技術は試験時間、顧客は追加機能が使える時期を気にしている。同じD-001でも懸念は異なる。誰が何を譲れず、どの情報がそろえば判断できるかを記録する。関係者の賛同を集めても、それだけで正式な決裁にはならない。
④ 「01_経営報告1枚」で、何を決めてほしいかを伝える
ここまで整理した内容を「01_経営報告1枚」の入力欄に集約する。課題の経緯を長々と並べるのではなく、「今回決めてほしいこと」「推奨案と不利益」「判断期限」「未確認事項」を一目で分かる形にする。
例えばD-001なら、「追加機能を今回のリリースに含めるかを判断するため、顧客の必須時期、契約変更の要否、社内・顧客の正式承認ルートを確定したい」と書く。B/C案の見積や権限が未確認の段階では、A案の採用を既成事実として申請しない。「10_記入済_経営報告」にある完成例を、自分の案件と照らし合わせると理解しやすい。
⑤ 「11_会議運営台本」と「06_決裁と実行」で、会議後の行動を止めない
経営会議では「11_会議運営台本」を使い、会議前の準備、当日の確認、会議後の記録を進める。例えば会議で「顧客の必要時期を確認して再提出」となったら、それは承認ではない。追加確認の担当者と期限を決め、D-001は未決定として管理する。
正式な決裁が得られたときだけ、「06_決裁と実行」に決定内容、決裁権者、日時、条件、証跡を記録する。条件付承認なら、条件を満たす前に作業を始めない。承認後も、PMが変更管理表やWBS、顧客説明計画へ反映し、実行が完了した証拠まで追う。経営会議で「決まった」と言われても、現場が変わっていなければ終わりではない。
⑥ 「07_効果測定」で、判断と実行を振り返る
最後に「07_効果測定」を確認する。「02_意思決定台帳」などの入力情報から、判断件数、決定済率、期限超過、実行完了、権限未確認といった状態を把握できる。ただし、数値が表示されたことと、改善効果が証明されたことは違う。対象期間と母数をそろえ、判断の質と実行への反映を確かめてほしい。
なお、「09_仮想事例」はD-001の記入の道筋を確認するための見本、「08_AI支援」は匿名化した事実から報告草案を作る補助だ。AIが生成した推奨や文章を、正式な承認や顧客の同意と混同してはならない。
実務で最初に試す順番は、00で全体を確認し、04で権限を確かめ、02に登録し、03と05で判断材料をそろえ、01で報告し、11で会議を運営し、06で決裁後の実行を追い、07で振り返る、という流れだ。各シートは判断IDをそろえて使うが、すべての入力項目が自動転記されるわけではない。実際の決定内容や条件は、帳票間で必ず突き合わせてほしい。
12シートをきれいに埋めることが目的ではない。「誰が、何を、何に基づいて決め、その結果として誰が動いたか」を一件でも最後まで追えることが、このExcelの価値だ。
導入前の最終チェック
□ 何について決める必要があるか、一文で書ける。
□ その判断の最終権限者と根拠を確認した。
□ 推奨案だけでなく、代替案の不利益を記載した。
□ 判断期限が工程・契約・事業上の制約から説明できる。
□ 顧客の正式合意が必要な部分を区別した。
□ 承認結果と条件を証跡付きで記録できる。
□ 決定後の実行担当、期限、完了証拠を追える。
□ PMOの成果を、会議数ではなく判断の健全性で振り返れる。
この八点を満たせないときは、まず欠けている一項目から修正してほしい。
よくある疑問：使う前に確認したいこと
Q．PMOが経営層に報告しても決まらない理由は何か。
A．課題の深刻さだけ伝えても、誰が何をいつまでに決めるべきかが整理されていなければ、経営層は判断しにくい。ただし、決定が遅れる理由が権限不足や組織政治、情報不足の場合もある。報告書を変えれば必ず決まるという単純な話ではない。
Q．このExcelは、会社の承認規程にそのまま使えるのか。
A．いいえ。権限表はあくまで例示であり、契約・委任規程・品質基準・情報セキュリティ規程に合わせて書き換える必要がある。
Q．AIに議事録を読ませれば、承認まで自動化できるのか。
A．議事録から論点を抽出することと、正当な権限者が正式承認することは別の行為だ。AIは草案作成を支援できるが、決裁事実を創作したり、顧客合意を推測してはならない。
Q．どんなPMOには、この商品が向いていないか。
A．決裁権限や変更管理を自由に設計できない、組織の承認プロセスの改善権限がまったくない、記録を残す運用すら認められていない場合は、テンプレートだけで解決できない。スポンサー・管理者との合意形成が先になる。
おわりに――PMOの仕事は、決定者の代わりに決めることではない
PMOが頑張れば頑張るほど、会議が増え、資料が増え、判断が遅くなる。そんな逆説が起きることがある。
私は、PMO組織を立ち上げた経験から、人数の多さや管理の細かさだけでは価値は証明できないと考えている。
本当に問いたいのは、「決めるべきことが、決める権限のある人に、決められる形で届いているか」。そして、「決定が現場の行動にまでつながったか」である。
AIが報告書の草案を短時間で作れる時代だからこそ、PMOには、情報を集めるだけでなく、事実を確かめ、論点を絞り、判断の質と実行を支える力が必要になる。
本記事と付属テンプレートは、そのための実務の道具として作った。自分の現場に合わせて使い、不要なものは減らし、決めなければいけないことを前に進めてほしい。
仕事のご相談
PMOの立ち上げ・再設計、経営報告の改善、AIを使った課題・意思決定管理について個別支援が必要な場合は、私のnoteプロフィールからご相談いただきたい。
著者プロフィール
参考資料
外部資料は、PMOの価値、権限、ガバナンスに関する背景情報である。付属Excelの構造、判断の七点チェック、導入手順は著者独自の実務上の整理であり、各機関の公式フォームではない。
Project Management Institute, Project Management Offices: A Practice Guide（2025）
https://www.pmi.org/standards/pmo
Association for Project Management, What is governance?
https://www.apm.org.uk/resources/what-is-project-management/what-is-governance/
実務で使えるExcelテンプレート
ここまで、経営層への報告から意思決定、合意形成、実行管理までの考え方と実践方法を解説してきた。
しかし、実際の現場で始めようとすると、意思決定台帳や比較資料、経営報告書、実行管理表などを一から作る必要がある。項目をそろえ、それぞれをどう運用するかを決めるだけでも相応の手間がかかる。
そこで、この記事で紹介した実務手順を、自分のプロジェクトに取り入れられるよう、Excelテンプレート12シートを用意した。
例えば、追加仕様をめぐる判断が止まっている場合、判断事項を登録し、対応案を比較し、経営層へ決裁を求め、その結果が現場で実行されるまでを一連の流れで管理できる。記入済みの見本や会議運営台本も収録している。
私が重視したのは、単に情報を記録することではない。「何を決めるべきか」を明確にし、「決めたことが実行されたか」まで確認できることだ。
Excelの使い方は第11章で説明した。実際の業務で活用したい方は、以下からファイルをダウンロードしてほしい。
▪️ Excel12シートのダウンロード（購入者限定）
経営層を動かすPMO意思決定・実行推進キット【Excel12シート】.xlsx
