プロジェクトマネジメントプロンプト

プロジェクト名「[プロジェクト名]」の定義書を[会社名]向けに作成してください。目的：[目的]、スポンサー：[責任者]、チーム構成：[メンバー]、予算：[予算]、目標納期：[納期]、背景：[プロジェクト発足の経緯]。

構成案：背景と解決すべき課題（3行程度）、測定可能な目標設定、プロジェクト範囲（Scope）、対象外事項（Scope Out：後のトラブルを防ぐため詳細に）、合格基準を含む成果物、日付入りマイルストーン、役割と責任（RACI：決定権、実行、相談、報告）、特定されたリスクと対策（[想定リスク]）、前提条件と依存関係。

各セクションは、プロジェクト進行中ではなく「今」異論が出るような具体的な表現にしてください。最後に、キックオフ前に委員会で決着をつけるべき3つの問いを提示してください。

以下の会議メモを構造化された議事録に変換してください。会議名：[議題]、日時：[日付]、参加者：[参加者]。メモ内容：[乱雑なメモ内容]。

出力形式：決定事項（誰が決定したかを含め、曖昧さのない表現で）、アクションアイテム（表形式：内容、担当者、期限。メモに不足がある場合は捏造せず「要確認」と記載）、決定に至らなかった議論点（各2行以内）、次回へ持ち越された課題と検討予定日。

ルール：A4サイズ1枚分に収めること。発言の意図を変えるような書き換えは禁止。「前向きに検討することに合意した」といった決定を濁す表現は使わないこと。最後に、参加者に確認が必要な「要確認事項」のリストを添えてください。

以下のプロジェクトをタスク分解し、スケジュールを作成してください。プロジェクト概要：[内容と最終成果物]、納期：[日付]、リソース：[人数と稼働率、例：2名が50%稼働]、制約条件：[顧客承認待ち、ベンダー依存、長期休暇など]。

手順：検証可能な成果物を生むワークパッケージに分解（「調整」などの曖昧な項目は避ける）、各タスクを0.5〜3日単位に細分化、タスク間の依存関係とクリティカルパスを特定、不確実なタスクには隠れたバッファではなく明示的な予備期間を設定。

出力：見積もりを含む構造化されたタスクリスト、マイルストーン付きの週次スケジュール、クリティカルパスの明示、および全体に影響するため即座に開始すべき3つのタスク。もし提示されたリソースで[納期]が不可能な場合は、数値を根拠に指摘してください。

[プロジェクト名]の週次フラッシュレポートを[宛先、例：ステアリングコミッティ]向けに作成してください。今週のデータ：進捗（予定vs実績）、課題（発生した問題）、変化したリスク（リスク状況）、予算消費（実績vs予算）、要判断事項（停滞している決定事項と経過日数）。

構成（厳守）：プロジェクトの天気予報（晴・曇・雨）とその理由を1行で、今週のトピックス3選、進捗状況（主要タスクごとに1行）、リスクと懸念点（先週からの変化のみ）、要判断事項（決定者名と遅延による影響）、来週の優先事項。

ルール：問題が解決されない限り「晴」に戻さないこと。2週連続の「曇」は「雨」に格上げすること。未決事項には最初の依頼日を明記すること。

[プロジェクト名]の振り返り会議（KPT等）の進行案を作成してください。結果：[納期通り、X日の遅延、中止など]、参加者：[役割]、時間：[例：90分]、特記事項：[成功点、失敗点、チーム内の摩擦など]。

出力内容：タイムスケジュール（「犯人探しではなく原因究明」というルールの徹底、同調圧力を防ぐための個人ワーク、主要議題の議論、アクション決定）、一般論で終わらせないための具体的な質問（例：「納期が遅れると確信した瞬間はいつか？」「なぜその時報告できなかったか？」）、デリケートな[特定の話題]を個人攻撃にせず議論する手法。

教訓の形式：各学びを次回のルールとして言語化し（「今後は〜する」）、担当者を割り当てること。ルールは最大5つまで（それ以上は実行されないため）。

経験豊富なプロジェクトディレクターとして、[会社名]が検討中の[プロジェクト名]の投資判断資料を作成してください。背景：[課題や機会]、期待される効果：[メリット]、想定最大予算：[金額]、代替案：[何もしない場合を含む選択肢]。

構成（6部構成）：解決すべき課題と放置した場合の損失（CoI）、現状維持を含む選択肢の比較（メリット・デメリット）、各案の概算費用と工期の幅、測定可能な指標に関連付けた期待効果、各案の主要リスク、根拠のある推奨案。

制約：効果は必ず検証可能な指標と結びつけること（できない場合は「測定不能な賭け」と分類）。委員会がチェックできる5つのGo/No-Go判断基準を提示してください。最後に、判断を鈍らせている不足情報とその提供責任者をリストアップしてください。

詳細な定義書を必要としない小規模プロジェクト用の簡易憲章を作成してください。プロジェクト概要：[2行で説明]、依頼者：[名前]、関係者：[担当と稼働時間]、希望納期：[日付]、予算：[金額またはなし]。

形式（1枚厳守）：測定可能な目標（1行）、最終成果物と完了の定義、対象外事項（最も重要なため3行以上）、調整が必要な際の最終決定者、マイルストーン（最大3つ）、最大のリスクと対策。

制約：専門用語を避け、誰が読んでも一度で理解できる平易な言葉を使うこと。情報不足で埋められない項目は捏造せず「[氏名]と要確認」と記載すること。最後に、開始前に依頼者に確認すべき2つの質問を添えてください。

[会社名]の[プロジェクト名]において、要件定義前のヒアリングを準備しています。対象者：[経営層、現場ユーザー、IT部門など]、想定成果物：[成果物]、1人あたりの時間：[分]。

対象者別のインタビューガイドを作成してください。質問は8〜10問で、広範な質問から詳細な質問へ展開し、現状の運用（不満点、回避策、量）と将来のニーズを区別してください。各対象者に「現在のツールで足りない時、具体的にどう対処していますか？」のような、潜在的ニーズを引き出す2つの「切り込み質問」を含めてください。

制約：誘導尋問や「はい/いいえ」で終わる質問は避けること。ヒアリング結果を統合するための集約テンプレート（明示されたニーズ、推測されるニーズ、矛盾点、印象的な発言）も提供してください。

以下の要望を、開発チームが活用できるユーザーストーリーに変換してください。プロジェクト名：[概要]、対象ユーザー：[ペルソナ]、要望リスト：[箇条書きの要望]。

各要望について次を出力してください：「[ユーザー]として、[メリット]のために[機能]したい」形式のストーリー、3〜5個の二値的（Yes/Noで判定可能。「使いやすい」等の主観は不可）な受入基準、および具体化するために必要な質問事項。

制約：1つのストーリーは数日で完了できるサイズに分割すること。要望に見せかけた「解決策の押し付け」は真のニーズに書き換えてください。結果は表形式（ストーリー、受入基準、見積もりサイズS/M/L、未決事項）で提示し、最後にストーリー間の依存関係をまとめてください。

[プロジェクト名]のバックログの優先順位付けを支援してください。未着手リスト：[要望リストと概要]、チームのキャパシティ：[例：月間15人日]、今期の最優先目標：[目標]、政治的背景：[強い要望を出している部署など]。

各項目を2軸で評価してください：価値（目標への貢献度、影響ユーザー数、放置した場合のコスト）と相対的な工数。その後、4つのカテゴリに分類してください：即実行（高価値・低工数）、計画（高価値・高工数）、隙間時間で実行（低価値・低工数）、却下または延期（低価値・高工数）。

制約：声の大きさは価値に含めないこと。ただし、却下する際に説明が必要な項目は別途リスト化してください。表形式で理由と共に提示し、最も断りづらい3つの要望に対する、事実に基づいた丁寧な拒絶メール案を作成してください。

[会社名]の[製品/プロジェクト]について、今後2四半期のロードマップを作成してください。年間目標：[目標]、候補案件：[リスト]、チーム体制：[人数と稼働]、既約事項：[納期厳守の案件]。

ロードマップは四半期ごとに整理し、各項目は機能名ではなく期待される成果で記載してください（例：「X機能の実装」ではなく「申請処理時間の短縮」）。各期につき：最大2〜3つの主要案件、目標成果、成功を測る指標、依存関係を明記してください。

制約：予期せぬ事態に備え、キャパシティの20%をあえて未割当とし、その旨を明示すること。「なぜXはやらないのか？」という質問を防ぐため、意図的に除外した項目とその理由をリスト化してください。チーム向けの詳細版と、経営層向けの5行要約版の2種類を提供してください。

[プロジェクト名]の工数見積もりを支援してください。内容：[タスクリスト]、チーム構成：[経験値]、過去実績：[類似プロジェクトの実績値があれば]。

各タスクについて：単一の数値ではなく3点見積もり（楽観、最確、悲観）を提示し、その根拠となる前提条件（これが満たされないと見積もりが崩れる要素）と、悲観的シナリオに転じるリスク要因を明記してください。

制約：過去実績がある場合はそれと比較し、乖離がある場合は理由を説明すること。多くの見積もりで漏れがちな「検収後の修正」「会議・調整」「学習コスト」「有給休暇」を必ず加算してください。合計を3つのシナリオで提示し、楽観と悲観の乖離率を示してください。乖離が2倍を超える場合は、精度を高めるために必要な情報を指摘してください。

[会社名]の[プロジェクト名]の予算計画を作成してください。内部工数：[役割別単価と人日]、外部発注：[内容]、期間：[期間]、承認済み予算枠：[金額]。

まず、費目別予算を出力してください：人件費、外注費、ライセンス・ツール費、諸経費、および不確実性に応じた予備費（％の根拠も記載）。承認予算との整合性を確認し、不足があればこの時点で指摘してください。

次に、月次モニタリング体制を設計してください：予算実績管理表の項目、残作業の再見積もり（単なる残予算ではなく）、完了時予測（EAC）、およびスポンサーへの報告が必要となる2段階のアラート閾値。最後に、この種のプロジェクトで発生しがちな3つの予算超過パターンと早期発見法を提示してください。

[プロジェクト名]のリスク登録簿を作成してください。背景：[概要、納期、重要度]、想定リスク：[既知のリスク]、外部依存：[ベンダー、他部署、承認工程]。

提示したリスクに加え、この種のプロジェクトで典型的なリスクを4つの観点（リソース、技術、組織、外部要因）で補完してください。各リスクについて：具体的な事象、発生確率（低/中/高）、影響度（低/中/高）、優先度、予兆となる指標、予防策、発生時の対応策（コンティンジェンシープラン）、監視責任者を定義してください。

制約：「スケジュール」のような曖昧な言葉ではなく、「ベンダーの納品が1ヶ月遅れる」のような具体的なイベントとして記述すること。追跡すべき上位10個のリスクに絞り込み、レビューの頻度と確認項目を提案してください。

[会社名]の[プロジェクト名]におけるステークホルダーを分析してください。関係者：[リストと役割]、プロジェクトによる変化：[影響]、現状の反応：[支持、抵抗など]。

各関係者を2軸でマッピングしてください：プロジェクトへの影響力（阻止・加速できるか）と賛同度（支持・中立・抵抗）。影響力の強い関係者については、彼らのメリット・デメリット、想定される懸念（彼らの言葉で）、および関与策（意思決定への参加、定期報告、個別面談など）を策定してください。

制約：組織図上の役職と実際の影響力を混同しないこと。役職はなくても発言権の強い人物を特定してください。関与計画を表形式（対象、現状、目標状態、アクション、担当、期限）で作成し、今週優先的に会うべき2名とその理由を提示してください。

[プロジェクト名]のコミュニケーション計画を作成してください。対象：[スポンサー、チーム、ユーザー、他部署など]、期間：[期間]、主要イベント：[マイルストーン、リリース、発表]、利用可能な手段：[会議、メール、Slack/Teams、社内ポータル]。

対象ごとに定義してください：必要な情報（それだけに絞る）、頻度、手段、形式（簡潔な報告、詳細資料、対面）、作成者。定常的な報告（進捗）とイベント的な報告（キックオフ、トラブル、完了）を分けて考えてください。

制約：すべての発信は、受信者の「自分にとってどんな影響があるか？」という問いに答えるものであること。そうでなければ計画から除外してください。キックオフとリリース時の通知文案を作成してください。計画表を作成し、よくある3つのコミュニケーションミスと、この計画がそれをどう防ぐかを説明してください。

[プロジェクト名]のRACIマトリックスを作成してください。主要タスク：[活動や成果物リスト]、関係者：[担当者や部署]。現状の課題：[例：2人が同じ件で決定権を主張している]。

各タスクに役割を割り当ててください：R（実行責任者）、A（説明責任者：最終決定者、1行につき1名のみ）、C（相談先）、I（報告先）。判断が難しい割り当てには理由を添えてください。

品質チェック：1行にAが2人いないか、Rが不在の行はないか、Cが多すぎて意思決定のボトルネックになっていないか、役割のない人がいないかを確認してください。表形式で提示し、紛争が起きやすい3つのタスクに対する対策と、配布前にチームで合意すべき項目をリストアップしてください。

[プロジェクト名]のキックオフミーティングを準備してください。参加者：[役割]、時間：[例：60分]、定義書の状況：[承認済み、または調整中]、懸念点：[懐疑的な意見、過去の失敗経験など]。

出力内容：分単位の進行表（なぜ今このプロジェクトをやるのか、具体的なゴール、範囲外のこと、役割分担、マイルストーン、チームの運営ルール、質疑応答）、参加者が持ち帰るべき3つの重要メッセージ、および[懸念点]を会議を壊さずに適切に扱う方法。

制約：単なる一方的な説明会にせず、参加者が発言する機会（リスクの出し合い、各自の制約共有など）を2回設けてください。招待メール案、各自の事前準備依頼、およびキックオフ前に「これだけは決めておくべき」事項のリストを提供してください。

[プロジェクト名]のステアリングコミッティの準備をしてください。参加者：[役員等]、時間：[分]、現状：[進捗、課題、予算]、必要な決定：[選択肢を含む決定事項]、議論が逸れそうな話題：[デリケートな件]。

進捗報告ではなく「意思決定」を軸にしたアジェンダを作成してください。各決定事項に時間を割り当て、準備した選択肢（2〜3案、メリット・デメリット、推奨案）と、決定を先送りにした場合の影響を明記してください。進捗は事前資料の参照とし、説明は最大10分に留めます。

出力：分単位のアジェンダ、各決定依頼の具体的な言い回し、[逸れそうな話題]を失礼なく切り上げるテクニック、24時間以内に送付する決定事項メモの型。最後に、開催48時間前までに配布すべき資料リストを提示してください。

[プロジェクト名]のステアリングコミッティ用プレゼン資料の構成案を作成してください。今月のデータ：進捗（実績vs予定）、予算（実績vs予算）、リスク（変化）、要決定事項（リスト）、トピックス。

最大10枚の構成案：サマリー（天気予報、重要メッセージ、要決定事項）、ワークパッケージ別進捗（予定との乖離）、予算推移、評価が変わったリスク、今月の最重要課題（選択肢と推奨案）、意思決定依頼（1項目1枚）、次月のステップ。

各スライドについて：メッセージ性のあるタイトル（例：「Avancement」ではなく「第2工程の遅延を挽回」）、5つ以内の箇条書き、スライドに書かない口頭補足説明。制約：周知の背景説明は省き、数値は比較（計画比、前月比）で示すこと。詳細データは付録へ。最後に「1枚目だけ読めば要点が伝わるか」を確認してください。

[プロジェクト名]の変更管理フローを構築してください。背景：[変更要求の発生源、例：顧客の追加要望、経営方針の変更]、既存の会議体：[会議名]、残りの猶予：[納期と予算のバッファ]。

定義事項：最小限の変更要求書（内容、依頼者、理由、緊急度）、4つの標準評価項目（納期、予算、他への影響、実施しない場合のリスク）、影響度に応じた承認権限（金額や日数の閾値案）、変更履歴管理表（Change Log）への記録方法。

3つの回答パターン案：承認（影響の明示）、次期フェーズへ延期、却下（理由付き）。制約：プロセスはA4半分に収まる簡潔なものにすること。口頭での変更承諾は一切禁止するルールを徹底してください。最後に、最も要求の激しい依頼者にこのルールを納得させる説明方法を提示してください。

実現不可能な納期に対する再交渉の準備を支援してください。プロジェクト：[名]、要求納期：[日付]、現実的な予測：[期間]とその理由（工数見積もり、依存関係、リソース不足など）、スポンサー：[タイプや重視すること]、納期設定の背景：[もし分かれば]。

構成案：事実に基づく乖離の証明（工数vs稼働可能時間）、および3つの誠実な選択肢：範囲を絞って納期を守る（削る機能を具体的に）、範囲を守って納期を遅らせる、リソースを追加する（コストと、投入直後の生産性低下のリスクを明記）。

制約：「できません」で終わらせず、必ず代替案を出すこと。会議の場で計算の裏付けがない妥協をしないこと。スポンサーからの「何とかしろ」「とりあえずやってみて」という反論に対する3つの切り返し案を用意してください。比較表を含む1枚の交渉用メモを作成してください。

[プロジェクト名]のリカバリー計画を作成してください。現在の遅延：[期間]、目標納期：[日付]、遅延の理由：[原因]、残作業：[見積もり付きリスト]、チーム：[体制]、調整の余地：[追加予算、スコープ削減の可否]。

まず原因を再確認してください：見積もりの甘さ、スコープ肥大、リソースの引き抜き、外部要因か？それにより対策が変わります。次に、現実的な手段（スコープ削減、タスクの並列化、不要なタスクの削除、クリティカルパスへの重点投入）のみで計画を再構成してください。

制約：根拠なく残作業の工数を「圧縮」することや、テスト期間を削ることは禁止します。出力：信頼できる新スケジュール、そのために犠牲にしたもの、計画達成の2つの条件、および遅延を認めつつ誠実に報告するスポンサー向けメッセージ。

[プロジェクト名]の停滞に関するエスカレーションを準備してください。問題：[決定待ち、リソース未配分、部署間対立など]、経過期間：[日数]、試みたこと：[催促の内容]。報告先：[役職]、関係者：[配慮が必要な人物]。

メッセージ案：事実と日付に基づいた3行の現状説明、放置した場合の具体的損失（損失金額、遅延日数、マイルストーンへの影響）、解決のための2〜3の選択肢と推奨案、いつまでに判断が必要か。

制約：個人攻撃を避け、事実と数字に語らせること。相手がこのメッセージだけで判断できるよう構成すること。対面で会った時の60秒エレベーターピッチ案と、エスカレーション対象者に角を立てないための事前通知メッセージも用意してください。

[プロジェクト名]の会議間のタスク追跡を組織化してください。現状：[会議で決まったことが実行されない、催促が「監視」と捉えられる等]、会議頻度：[頻度]、利用ツール：[Excel、Backlog、Slack等]。

システム提案：管理表の形式（動詞で始まる具体的な成果物、担当者1名、期限、ステータス）、更新ルール（誰がいつ更新するか）、および段階的なリマインド（期限2日前、期限当日、2回以上の遅延で会議での言及）。

各段階の、感情を排した簡潔な催促メッセージ案を作成してください。制約：期限や担当者が不明確なタスクは登録させないルールにすること。チームが消化できるタスク量に制限を設ける提案を含めてください。最後に、チームに「管理のためではなく助け合うため」と説明する方法を提示してください。

[プロジェクト名]のダッシュボードを設計してください。種類：[IT開発、業務改善等]、期間：[期間]、監視すべき重要点：[納期、予算、品質等]、利用可能なデータ：[工数管理、チケット管理、予算管理]。

指標を6〜8個に絞り、3つのブロックで構成してください：進捗（完了した成果物ベースの実績vs予定。仕掛かり品の％は不可）、健全性（遅延タスク数、未決事項の滞留期間、リスク評価の変化）、リソース（予算消費率、チーム負荷）。

各指標について：定義、データ元、更新頻度、アラート基準を明記してください。制約：自己申告の「進捗80%」は排除し、完了か未完了かの二値で測ること。赤信号時に取るべき具体的なアクションをセットで定義してください。毎週15分で状況を把握するための読み解き方を解説してください。

[プロジェクト名]の月次報告書を[宛先：経営会議など]向けに作成してください。今月のデータ：成果[完了したもの]、乖離[遅延や予算超過]、予算[実績vs予定]、リスク[変化]、決定事項[リスト]、アラート[重要課題]。

形式（1枚厳守）：全体状況の2行要約（納期と予算内に着地するか否か、今月の変化）、マイルストーンに紐づいた今月の成果、乖離の理由と対策（対策のない報告は不可）、完了予測を含む予算状況、経営層の判断が必要な事項。

制約：経営層は多くの報告書を読みます。自己アピールや埋め草の文章は排除してください。アラートは必ず具体的な依頼（判断、リソース、承認）とセットにすること。悪いニュースを最後に隠さず、最初の方に記載してください。

競合する複数のプロジェクト間でのリソース調整を支援してください。進行中案件：[リスト、納期、重要度、進捗]、共有リソース：[担当者と現在の配分]、現在の衝突：[具体的な問題]、最終決定者：[役職]。

まず、理論値ではなく実態に基づいた稼働状況（100%を超えているメンバーの特定）を可視化してください。次に、明確な基準（事業貢献度、遅延コスト、機会損失のリスク、対外的な約束）による優先順位付けの枠組みを提案してください。

この枠組みを現在の衝突に適用し、2つの配分シナリオを作成してください。各シナリオについて、各プロジェクトが得るもの・失うもの、および最終的な完了予定日を明示してください。制約：無理な残業や、1人が3つのプロジェクトを掛け持つような非現実的な解決策は禁止します。

[プロジェクト名]における[チーム名]の次期スプリント計画を準備してください。期間：[期間]、キャパシティ：[メンバー数、休暇予定、定常業務（サポートや会議）の時間]、バックログ：[候補項目と見積もり]、前回の残り：[未完了項目]。

セッション構成：実効キャパシティの算出（総時間から定常業務とバッファを引く）、スプリント目標の策定（チケットの羅列ではなく、終了時に達成される状態を1行で）、キャパシティ内での項目選択（前回残りを優先）、各項目の定義が十分かどうかの確認。

制約：受入基準のない項目は拒否すること。要求がキャパシティを超える場合、黙って引き受けるのではなく、項目の取捨選択を促すこと。進行表、スプリント目標の文案、および計画が未達になる予兆（3つのサイン）を提示してください。

[チーム名]のスプリント振り返りの進行案を作成してください。時間：[例：45分]、現在の雰囲気：[形骸化している、最近ギスギスしている、新チームなど]、今スプリントの出来事：[トピックス]、過去の改善策の状況：[実施状況]。

出力内容：分単位の進行表（前回の改善策の確認から開始。実行されない改善策は儀式を殺します）、[現在の雰囲気]に合わせた手法（KPT、Start-Stop-Continue等）の具体的な進め方、議論を深めるための質問、および絞り込み（最大2つのアクション、担当者と次スプリント内の期限を設定）。

制約：「コミュニケーションを良くする」のような曖昧なものは避け、観測可能な変化を伴うアクションにすること。チームで解決できない組織的課題は別途エスカレーションリストに分け、その場では議論しすぎないこと。次回以降に使える2つの代替フォーマットも提案してください。

[プロジェクト名]における[チーム名]の日次ミーティングを設計し直してください。現状：[30分以上かかる、リーダーへの報告になっている、内職している人がいる等]、チーム人数：[人数]、勤務形態：[出社、リモート、ハイブリッド]。

目標とする形式を提案してください：最大時間、固定時間、および「昨日完了したこと」「妨げになっている（なりそうな）こと」「他メンバーに助けてほしいこと」に集中した内容。技術的な議論や問題解決はその場では行わず、終了後に当事者のみで実施するルールを設けます。

提供内容：報告会化を防ぐための運営ルール（メンバー同士で話す、進行役の持ち回り）、話を遮るための丁寧なフレーズ、[勤務形態]に合わせた工夫、および朝会が機能していない3つの兆候と対策。旧来のやり方を否定せず、目的を説明するチーム向け告知文も作成してください。

[チーム名]が[プロジェクト名]で使用する「完了の定義（DoD）」の策定を支援してください。成果物の種類：[ソフトウェア機能、マニュアル、調査報告書など]、現状の課題：[完了したはずのタスクが再開される、品質がバラバラ、検収で不備が出る等]。

DoDを3つのレベルで構成してください：完了とみなすための必須条件（レビュー済み、テスト済み、ドキュメント化、承認者など）、現実的であるためにあえて除外する事項、および例外を認める際のルールと記録方法。

制約：基準は最大8項目とし、すべてYes/Noで判定可能なものにすること。現在のリソースで達成不可能な基準は含めないこと（緊急時に無視されるため）。出力：ワークショップでの合意形成手順、進行中の作業への適用ルール、および数週間後の見直し手順。

[プロジェクト名]のユーザー受入テスト（UAT）を計画してください。対象：[成果物]、テスター：[役割と人数]、期間：[期間]、既存の受入基準：[あれば]。

構成案：実際の業務フローに基づいたテスト計画（機能単位ではなくユーザー体験単位）、各ケースの入力データ・操作・期待値の定義、優先順位（リリース不可、重要、改善要望）、不具合の重要度分類ルール（議論を避けるための具体例付き）、修正と再テストのフロー。

検収報告書の雛形も作成してください：テスト実施範囲、重要度別不具合数、判定（合格、条件付き合格、不合格）、署名欄。制約：本番に近いデータでのテストを必須とすること。条件付き合格の場合は、残課題の担当者と期限を明記させ、放置されないようにすること。

[プロジェクト名]の[成果物/システム]のリリース計画を作成してください。予定日：[日付]、影響ユーザー：[対象と人数]、作業時間枠：[例：夜間、休日]、作業担当：[役割]、切り戻し（ロールバック）の可否：[可否と方法]。

出力内容：事前準備リスト（技術的要件、承認、告知、バックアップ確認）、時間単位の切り替え手順（担当者と成功判定基準を明記）、Go/No-Go判断ポイント（誰がどの基準で判断するか）、異常検知時の切り戻し手順（トリガーと手順）、リリース直後の監視体制。

制約：各ステップに「なんとかなるだろう」という曖昧さを残さず、検証可能な成功基準を設けること。切り戻し手順は、プレッシャー下でも実行できるよう本番手順と同等の詳細さで記述すること。リリース前後のユーザー向け案内文案も作成してください。

[会社名]における[旧システム/プロセス]から[新システム/プロセス]への移行期間中の業務継続計画を作成してください。並行稼働期間：[期間]、停止不可の重要業務：[業務内容]、対象チーム：[チーム名]、繁忙期等の制約：[決算期、季節要因など]。

移行の失敗要因を潰すためのルールを策定してください：並行稼働中、どのデータや操作においてどちらのシステムが正（Master）となるか（ケース別の明快なルール）、二重入力の回避策または適切な運用法、移行をまたぐ処理の取り扱い、最終切り替え時のデータ凍結手順。

出力：重要業務の移行中運用一覧、ケース別「正」の判定基準、導入直後の強化サポート体制、および想定される3つのトラブルシナリオとそれぞれの対応策。

[日付]に検収完了した[プロジェクト名]の終了処理を準備してください。構成要素：[外注先、予算、成果物、チーム]、残課題：[あれば]。

終了チェックリストを作成してください：契約面（外注費精算、残課題の扱い、外部アクセス権の削除）、財務面（工数入力停止、予算実績分析と乖離理由の記録）、ドキュメント面（アーカイブ場所の指定、将来参照が必要な資料の選別）、人事面（チーム解散の告知、適切なレベルでの謝辞）、引き継ぎ面（運用保守担当への移管）。

制約：今すぐ終わらせるべきことと、後日でも良いことを区別すること。「98%完了」のまま半年放置されるコストを防ぐため、明確な終了日を設定してください。1枚のプロジェクト完了報告書案（主要数値、成功要因、乖離、教訓の所在）も添えてください。

[前任者]から[後任者]への[プロジェクト名]の引き継ぎを計画してください。交代の背景：[理由と猶予期間]、プロジェクト状況：[進捗、懸念点、直近のマイルストーン]、並走期間：[期間]。

資料には載らない「生の情報」を優先した引き継ぎ書を作成してください：過去の意思決定の裏にある本当の理由、顧客やスポンサーとの口頭での約束事、関係者の性格やデリケートな人間関係、公式報告には現れない前任者が感じている予兆的リスク、各タスクの実態。

引き継ぎ計画：主要関係者（スポンサー、顧客、チーム）への対面での紹介、緊急度順のレクチャー項目、および継続性を強調しつつ安心感を与える交代の挨拶文案。制約：引き継ぎの完了を確認するため、後任者が独力で答えられるべき質問リストを用意してください。伝えきれなかった事項の連絡先も明記すること。

[日付]に[プロジェクト名]のチームに加わる[新メンバーの役割]の受け入れ準備をしてください。現在の状況：[進捗と文脈]、期待する役割：[ミッション]、チームがサポートに割ける時間：[制約]。

最初の2週間のプログラムを作成してください：初日に読むべき厳選資料（定義書、最新レポート、リスク一覧、用語集）、主要メンバー4名との面談設定と各目的、初週から着手できる具体的で小さな成果物（[役割]に基づく）、およびメンターによる毎日10分のクイック面談。

制約：単なる会議への同席は避け、アウトプットを通じて学ばせること。人間関係の注意点や「地雷」など、明文化されていない暗黙のルールも適切に伝えてください。2週間のスケジュール、読書リスト、および15日目に本人が答えられるべき確認クイズを作成してください。

プロジェクトチーム内での対立解消を支援してください。状況：[2名間の対立の事実関係を感情を排して記述]、プロジェクト名：[名]、悪影響：[情報共有の停滞、会議の不穏な空気、遅延など]、あなたの立場：[PM、上司/同僚]、経緯：[期間、これまでの対応]。

3段階のステップを提案してください：個別ヒアリング（相手を否定せず、かつ同調せずに双方の言い分を聴く質問、審判にならないための注意点）、合同面談（冒頭で提示するルール、個人攻撃を事実に引き戻す方法、2〜3の具体的な運用ルールの合意）、フォローアップ（監視と思わせずに合意が守られているか確認する方法）。

制約：PMの役割を逸脱しないこと。人事や労務の問題は適切に報告し、深入りしないこと。どちらかを悪者にせず、チームの前で面目を保てるよう配慮すること。即座にエスカレーションすべき危険信号も提示してください。

[プロジェクト名]において、期待に応えられていないベンダーへの対応を準備してください。ベンダー名：[社名と業務内容]、問題点：[日付入りの事実：遅延、品質不良、担当者変更、約束違反]、契約条件：[成果物、納期、違約金条項など]、依存度：[代替可能性]。

段階的な対応案を作成してください：まず是正会議（契約と実態の乖離を事実ベースで提示し、言い訳ではなく期限付きの改善計画を要求する）、次に強化モニタリング（短いマイルストーン設定、明確な脱出基準、全やり取りの書面化）、最後に改善が見られない場合の代替案準備（依存度が高い場合は水面下で開始）。

制約：すべての口頭のやり取りを後に書面で残すこと（法的保護のため）。実行不可能な脅しはせず、事実と契約に基づいた態度を貫くこと。乖離一覧表、会議への招集メール案、および契約解除を検討する客観的な基準を提示してください。

[会社名]の[対象：サイト刷新、ツール導入など]に関する提案依頼書（RFP）を作成してください。目的：[解決したい課題]、環境と制約：[既存システム、組織]、予算目安：[範囲、または非公開]、スケジュール：[納期]。

構成：会社概要と背景、解決すべき課題と期待する成果（解決策ではなく「何を実現したいか」を記述）、範囲と除外事項、必須要件（技術、法規制、納期）、納品物、選定基準と配点、選定スケジュール（質問期限、提出日、プレゼン日）、回答フォーマットの指定。

制約：各要件は納品時に検証可能な表現にすること。必須（Must）と希望（Want）を明確に分けること（すべてを必須にすると比較ができなくなるため）。プレゼン時に、ベンダーが真にニーズを理解しているかを見極めるための5つの質問を添えてください。

[案件名]に対する各社の提案比較表を作成してください。提案概要：[社数と各社の特徴：価格、納期、手法、懸念点]、重視する点：[優先順位：納期、サポート、総コスト、安定性など]、違和感：[安すぎる、回答が一般的すぎる等の懸念]。

評価シートの構成：評価カテゴリ（ニーズ理解度、提案手法、体制の信頼性、保守を含む総コスト、類似実績、契約条件）、優先順位に基づいた配分、主観を排除するための5段階評価基準の定義。

各社の提案をこの基準で分析し、次の点を指摘してください：説明のつかない価格差（安すぎる場合は範囲漏れの可能性を疑い、確認質問を作成）、プレゼン担当と実作業者の乖離リスク、隠れたランニングコスト。比較表、各社への確認質問リスト、および5行の選定推奨理由を作成してください。

[会社名]の[プロジェクト名]におけるチェンジマネジメント計画を作成してください。対象ユーザー：[属性、人数、変化の内容]、想定される抵抗：[懸念点]、スケジュール：[主要日程]、利用可能なリソース：[予算、推進メンバー]。

対象グループごとに：日常業務の具体的な変化（メリットとデメリットの両方。デメリットを隠すと後で反発を招きます）、必要な支援レベル（情報提供、トレーニング、個別サポート）、および彼らの視点に立った重要メッセージを定義してください。

時間軸での構成：導入前（告知、現場で信頼されている人物による推進ネットワークの構築）、導入中（サポート強化、不満の吸い上げと迅速な改善）、導入後（定着度測定、残存する抵抗勢力への対応）。

制約：「周知を徹底する」といった曖昧な表現は避け、具体的なアクションと担当、期日を明記すること。対象別の計画表と統合スケジュールを出力してください。

[会社名]の[ツール/プロセス]導入に向けたユーザー教育計画を作成してください。対象：[属性、人数、ITリテラシー、拠点]、習得すべきスキル：[役割別のタスク]、制約：[時間、予算、リリース日]。

一律の教育ではなく、役割別のプログラムを設計してください：各役割がマスターすべき5〜10の主要操作（全機能紹介は不要）、最適な形式（少人数ワークショップ、動画、個別指導）、所要時間、および配布資料（マニュアルではなく、1枚のクイックリファレンス）。

リリース直前に実施するよう計画してください（早すぎると忘れるため）。欠席者へのフォロー体制や、現場のリーダーによるサポート体制も含めてください。制約：評価基準を受講率ではなく、リリース後の実操作能力やサポートへの問い合わせ件数に置くこと。役割別の計画表と作成すべき資料の優先順位リストを提供してください。

[プロジェクト名]で重大なインシデントが発生しました：[内容：リリース失敗、データ紛失、サービス停止、重大な遅延発覚]。影響範囲：[対象と内容]、現在の状況：[判明していること、不明なこと]、報告先：[経営層、チーム、顧客、パートナー]。

一連のメッセージ案を作成してください：まず迅速に送る第一報（事実、不明点、現在の対応、次回の報告予定時刻を明記。復旧時刻の安請け合いは厳禁）、定期的な状況報告（進展がなくても定刻に送る）、解決報告と再発防止策。

対象別に内容を調整してください：経営層には影響度と判断材料を、ユーザーには代替運用法を、顧客には保護状況を伝えます。制約：原因が確定するまで推測で話さないこと。犯人探しをしないこと。一度でも守れない約束をすると信頼を失うため、慎重な言葉選びをすること。連絡ルートのルールも添えてください。

[会社名]の[チーム名]の[四半期]OKR作成を支援してください。会社の優先事項：[内容]、チームの定常業務：[内容]、検討中の案件：[アイデア]、チーム人数：[人数]。

最大2〜3つの目標（Objective）を作成してください：ワクワクするが具体的な状態を示す言葉で記述し、会社の優先事項との関連を明示してください。各目標に対し、2〜4つの主要な結果（Key Results）を設定してください：開始値と目標値を持ち、活動（〜をする）ではなく成果（〜がXからYになる）で測定すること。

制約：ルーチンワークはOKRにせず、別途管理すること。測定方法が不明なKRは除外または書き換えること。チームの権限外で達成不可能な目標には警告を出してください。提案するOKR、チーム会議での検討項目、および15分で終わる週次レビューの手順を提示してください。

[チーム名]のOKR四半期レビューを準備してください。今期のOKR：[目標とKRの達成度]、特記事項：[予期せぬ事態、優先順位変更、欠員]、参加者：[役割]、時間：[分]。

レビューを3部構成で設計してください：実績数値に基づく厳格なスコアリング（「だいたいできた」は未達とみなす）、乖離分析（実行力の問題か、目標設定のミスか、外部要因かを切り分ける）、次期への決定（継続、廃止、再設定）。

制約：言い訳の場にさせないため、背景説明のスライドは禁止し、数値から入ること。100%達成が続く場合は目標が低すぎないか、20%以下の場合は実行力に問題がないかを問い直してください。進行表、分析用の質問リスト、およびレビュー後の全社共有用サマリーの型を作成してください。

[プロジェクト名]で[日付]に発生した[インシデント内容]のポストモーテムを準備してください。時系列：[発生から収束までの経緯]、関係者：[役割]、現在の雰囲気：[誰かが責任を感じている、経営層が犯人を探している等]。

報告書と会議の構成：事実のみに基づいた時系列の再構成（解釈を入れない）、個人攻撃を避けた根本原因分析（「ヒューマンエラー」で終わらせず、なぜそのミスが起きる状態だったか、なぜ防げなかったかを探る）、検知・対応で機能した点、再発防止策。

進行ルール：冒頭で「システムを改善するための場であり、個人を責めない」ことを宣言すること。「ミスをした」と正直に話した人が不利益を被らない環境を作ること。制約：対策は最大5つに絞り、個人の注意喚起ではなく、ミスが起き得ない仕組みの導入を優先すること。資料の雛形と進行案を出力してください。

[チーム/会社]が蓄積した教訓を、標準運用ルールに変換してください。元データ：[振り返り議事録、完了報告書、トラブル事例など]、現状の課題：[同じミスが繰り返される、報告書が読まれない等]。

手順：教訓をテーマ別に分類し、頻出するものを特定する（それが優先すべき標準化項目です）。各教訓を「〜の際は、〜する」という1行の実行可能なルールに変換し、それをどこに組み込むか（既存のテンプレート、チェックリスト、ツール設定など）を定義してください。独立した「教訓集」は誰も開かないため、業務フローの中に埋め込みます。

制約：ルールは合計10個以内に絞り、それぞれに維持管理責任者を置くこと。形骸化を防ぐため、不要になったルールを削除する半年ごとの見直し手順も含めてください。提案するルール一覧、組み込み先、チームへの告知文を作成してください。

[日付]に行われる[監査人：社内監査、顧客、認証機関など]による[プロジェクト名]の監査準備をしてください。監査範囲：[対象]、プロジェクトの実態：[強みと弱み、資料の整備状況]、重要度：[継続承認、顧客の信頼、認証取得など]。

準備計画を作成してください：提出資料リスト（定義書、決定履歴、リスク管理、議事録、予算管理）の整理と、不足・古い資料の優先順位付け。この種のプロジェクトで監査人が尋ねる可能性の高い質問リスト。既知の弱点に対する誠実な回答案（隠さず、認識しており、いつまでにどう改善するかという計画を示す）。

制約：資料の捏造や日付の改ざんは絶対にしないこと。取り繕った説明よりも、課題を把握し管理下にあることを示す方が評価されます。ヒアリング対象者への、事実に基づいた回答のブリーフィング案を作成してください。チェックリスト、想定問答、準備スケジュールを提供してください。