プロジェクトの「管理」に週15時間。「推進」に使えているのは何時間？ ― PMのAI活用プロンプト

ステータス確認、議事録作成、リスク報告書、進捗レポート、メンバーへの依頼文面……。

PMの仕事は「プロジェクトを前に進めること」のはずなのに、実際に手を動かしている時間の大半は「管理のための管理」になっていないだろうか。

週40時間のうち、純粋に「判断する」「方向性を示す」「メンバーの壁を取り除く」に使えている時間は、たぶん思っているより少ない。

AIにステークホルダーの表情を読むことはできない。メンバーが言いにくそうにしている「実はここ、厳しいです」を引き出すことも、チーム全体の空気を感じ取ることも、PMにしかできない。

でも「進捗レポートの下書き」「リスク分析の整理」「会議のアジェンダ設計」なら、チームと向き合う時間を取り戻せる。

プロジェクトを始める

キックオフの設計

キックオフで「何を共有するか」で、その後の進め方が決まる。

新しいプロジェクトのキックオフミーティングを設計したい。

■ プロジェクト概要: [内容]
■ 期間: [期間]
■ チーム構成: [人数・役割]
■ ステークホルダー: [関係者]

以下を一緒に考えてほしい:
- キックオフのアジェンダ（60分想定）
- 「この場で必ず合意すべきこと」リスト
- チームの役割分担の説明方法
- プロジェクトのゴールイメージの伝え方（抽象的にならないように）
- 「何か不安なことは？」の引き出し方
- キックオフ後に送る確認メールの構成

「よくわからないけど始まった」にしないキックオフを。

WBSのたたき台を作る

完璧なWBSを最初から作ろうとして、いつまでも着手できない。まず叩き台を。

以下のプロジェクトのWBS（作業分解構成）のたたき台を作ってほしい。

■ プロジェクト: [概要]
■ 期間: [期間]
■ 主要マイルストーン: [わかっていれば]
■ チーム人数: [人数]

条件:
・大項目→中項目→タスクの3階層で
・各タスクに想定工数（人日）をざっくり
・依存関係がわかるように
・「抜けがち」なタスク（環境構築、テスト、ドキュメント整備など）も意識して

チームレビュー用のたたき台として使いたい。「ここ足りてない」が見つかるくらいの粒度で。

日々のマネジメント

進捗レポートを書く

毎週同じフォーマットで書くのに、毎回30分かかるのはなぜだろう。

以下の情報から、ステークホルダー向けの週次進捗レポートを作ってほしい。

■ プロジェクト名: [名前]
■ 報告期間: [○月○日〜○月○日]
■ 進捗状況:
[箇条書きで。完了タスク、進行中タスク、遅延タスク]
■ 課題・リスク:
[今起きていること、起きそうなこと]

以下の構成で:
- サマリー（3行。忙しい人が読む最初の3行で全体像がわかるように）
- 進捗（予定 vs 実績。「順調」だけでは伝わらない）
- 課題とリスク（影響度・対応策つき）
- 来週のアクション
- 判断が必要な事項（あれば）

「で、結局どうなの？」と聞かれないレポートで。

リスクを「見える化」する

「想定外でした」は、想定していなかっただけ。

以下のプロジェクトのリスク分析を手伝ってほしい。

■ プロジェクト概要: [概要]
■ 現在のフェーズ: [企画/開発/テスト/リリース前など]
■ 気になっていること: [あれば]

以下を出して:
- 潜在リスク（5つ以上。「よくあるけど見落としがち」なものも含めて）
- 各リスクの発生確率と影響度（高/中/低のマトリクス）
- 対応策（予防策と発生時の対応）
- 「今すぐ手を打つべき」の優先順位
- チームに共有する際の伝え方（不安を煽らず、でも危機感は持ってもらう）

リスク管理表のたたき台として使いたい。

「遅れてます」にどう対応する？

遅延報告を受けたとき、責めるのではなくリカバリーに集中するために。

プロジェクトで以下の遅延が発生した。リカバリープランを一緒に考えてほしい。

■ 遅延しているタスク: [内容]
■ 当初の期限: [日付]
■ 遅延の原因: [わかっている範囲で]
■ プロジェクト全体への影響: [他タスクへの影響]
■ 動かせない期限: [最終デッドラインがあれば]

以下を出して:
- リカバリーの選択肢（3つ。スコープ調整/リソース追加/期限延長など）
- 各選択肢のメリデメ
- ステークホルダーへの報告文面
- チームへの伝え方（「誰のせい」ではなく「どうリカバリーするか」）
- 同じ遅延を繰り返さないための振り返りポイント

チームを動かす

1on1で「本音」を引き出す

「特にないです」で終わる1on1を変えたい。

チームメンバーとの1on1の質問リストを作ってほしい。

■ メンバーの状況: [新人/中堅/ベテラン]
■ 最近の様子: [順調/なんとなく元気がない/過負荷気味など]
■ 1on1の頻度: [週1/隔週/月1]
■ 特に聞きたいこと: [あれば]

以下を出して:
- アイスブレイク（仕事以外の話題。2つ）
- 仕事の状況確認（「忙しい？」ではない聞き方で。3つ）
- 成長やキャリアについて（2つ）
- チームや環境について（2つ）
- 「実は困っていること」を引き出す質問（2つ）
- クロージング（次回までのアクション）

「話してよかった」と思ってもらえる30分にするための質問で。

依頼を「やりたい仕事」に変える

「これやっといて」と「これ、あなたにお願いしたい理由があって」は違う。

以下のタスクをチームメンバーに依頼する文面を作ってほしい。

■ タスク内容: [内容]
■ 依頼先: [メンバーの役割・スキル]
■ 期限: [日付]
■ 背景: [なぜこのタスクが必要か]
■ なぜこの人にお願いするか: [理由]

条件:
・「作業指示」ではなく「なぜあなたに頼みたいか」が伝わる
・期待するアウトプットのイメージを具体的に
・困ったときの相談先
・自分の裁量で判断していい範囲
・「やらされ仕事」にならないように

Slackで送る想定で、長すぎず短すぎず。

プロジェクトを振り返る

振り返り（レトロスペクティブ）を設計する

「KPT、マンネリ化してきたな」と思ったら。

プロジェクトの振り返り会を設計してほしい。

■ プロジェクト: [概要]
■ チーム人数: [人数]
■ 期間: [プロジェクト期間]
■ 全体的な結果: [成功/一部課題あり/苦戦した]
■ 振り返りに使える時間: [○分]

以下を出して:
- KPT以外の振り返りフレームワーク案（2つ。それぞれのメリット）
- ファシリテーションの進め方（タイムライン付き）
- 「全員が発言できる」工夫
- 「個人攻撃にならない」ための仕掛け
- 振り返りの結果を「次のアクション」に変える方法
- 振り返り後の共有フォーマット

「振り返り、やってよかったね」とチームが思える場にしたい。

ステークホルダーへの完了報告

「終わりました」だけでは、次のプロジェクトにつながらない。

プロジェクト完了報告書を作ってほしい。

■ プロジェクト名: [名前]
■ 期間: [期間]
■ 目標: [当初の目標・KPI]
■ 結果: [実績]
■ チーム構成: [人数・役割]
■ 特筆すべきこと: [うまくいったこと/苦労したこと]

以下の構成で:
- エグゼクティブサマリー（1ページで全体像）
- 成果（数字と定性的な評価）
- プロセスの振り返り（何がうまくいき、何が課題だったか）
- 学び（次のプロジェクトに活かせること）
- 感謝（チームとステークホルダーへ）

「このPM、また一緒にやりたい」と思ってもらえる報告書で。

PMがAIを使うときの3つの心得

1. プロジェクトの機密情報は入れない ― クライアント名、予算の具体額、メンバーの人事情報はNG。「Webサービス開発、5名チーム、半年」程度の粒度で
2. AIのアウトプットは「たたき台」 ― WBSもリスク分析も、チームでレビューして初めて使える。AIが出した計画をそのまま運用すると、現場との乖離が必ず起きる
3. 浮いた時間を「チームとの対話」に使う ― レポート作成が30分早く終わったら、その30分でメンバーと話す。PMにとって一番価値のある時間は、チームの声を聞いている時間