プロジェクトのプレモーテムを実施する

著者: AILesson7 分でセットアップテスト済み:ChatGPTレビュー日: 2026-08-28

クイック回答

失敗した結果を想定し、もっともらしい原因、弱い兆候、検証方法、予防措置を明らかにする. 入力するもの: プロジェクトと失敗判定日, 根拠と仮定, 参加者と対応権限. 期待される結果: 根拠、指標、担当者、すぐに行う実験を含む、優先順位付きの失敗シナリオ図.

コンテキストを追加

テキストはこのブラウザ内に留まります。AILesson Prompts は、そのテキストをモデルやサーバーに送信しません。

プロジェクトと失敗判定日根拠と仮定参加者と対応権限

あなたのプロンプト

未入力のフィールドはプレースホルダーとして表示されたままなので、プロンプトをコピーして編集できます。

提示された背景を使って、プロジェクトのプレモーテムを実施してください。

プロジェクト、利用者、計画、目標、具体的な失敗の定義：
[project]

制約、依存関係、過去の問題、見積もり、異論、不明点：
[assumptions]

参加者の視点、権限、リスク軽減能力、確認時期：
[participants]

指定された将来の時点でプロジェクトが失敗したと仮定し、関連する場合に限り、利用者価値、範囲、納品、品質、運用、人員、ベンダー、ガバナンス、セキュリティ、アクセシビリティ、データ、外部環境について、互いに異なるもっともらしい説明を作成してください。根拠のある懸念と仮説を分けてください。一般的な大惨事、責任追及、後知恵による断定は避けてください。原因を因果関係の連鎖にまとめ、最も早く観察できる指標を特定し、作り上げた精密な確率ではなく、もっともらしさと被害に対する明確な理由で順位付けしてください。上位シナリオごとに、低コストの検証、予防策、緊急対応の発動条件、対応、明確な担当者または「未割り当て」、意思決定期限を示してください。反対意見に基づくシナリオと、リスクを下げる既存の強みも含めてください。

Playgroundで試す

デフォルトで非公開プロンプトの組み立てはブラウザ内で行われます。組織が許可しない限り、機密情報を AI サービスに入力しないでください。

入力から結果へ

具体例

具体的なコンテキストを加えると、このレシピが実用的な結果になる様子をご覧ください。

実際の入力

プロジェクトと失敗判定日: 地域の慈善団体が3月に、ボランティア600人とコーディネーター40人向けのオンライン勤務表ポータルを公開する。6月30日時点で、コーディネーターが並行して表計算ファイルを管理している、予定されたシフトの10%超に異議がある、または月間でポータルを使う現役ボランティアが50%未満なら失敗とする。2月に2チームで試験運用を始める。
根拠と仮定: 多くのボランティアはスマートフォンを使う。現在の記録の18%には一意のメールアドレスがない。コーディネーターごとにシフト名が異なる。ベンダーは CSV インポートに対応するとしているが、当団体のファイルは未検証。研修予算はライブセッション2回分。ボランティアがキャンセル通知に気付かないのではないかと、コーディネーター1人が懸念している。認証にはメールリンクを使う。アクセシビリティテスト、サポート当番、表計算ファイルの廃止ルールはまだない。
参加者と対応権限: ワークショップには、ボランティアコーディネーター、ボランティア代表、公開権限を持つ運用マネージャー、データ責任者、コミュニケーション担当者、ベンダー専門家が参加する。リスク軽減に使える時間は残り2人週。意思決定は次の火曜日に確認する。

出力例

失敗ストーリー A——分断された本人確認とインポート：一意のメールアドレスがない記録18%と未検証の CSV インポートにより、アカウントの重複や欠落が発生します。ボランティアは認証できず、コーディネーターは表計算ファイルを残し、異議が増えます。根拠あり。最も早い指標：インポート例外率、重複アカウント、ログイン失敗。低コストの検証：個人を特定できない代表的なファイルをインポートし、メールアドレスが欠落または重複する記録でスマートフォンからのログインを試す。予防策：試験運用前に本人情報の修復方法を定義し、件数を照合する。検証担当：データ責任者。本人確認方針の担当者：未割り当て。次の火曜日までに決定。

B——シフト定義の不一致：異なる名称が誤って対応付けられ、勤務表への異議と並行記録が発生します。根拠あり。2つの試験チームで共通分類を検証し、インポートした全シフトを照合します。C——キャンセル通知が運用上機能しない：メールリンクを使う利用者は通知を見落とす可能性があり、サポート当番も通知確認ルールもありません。懸念は明示されていますが、結果に至る仕組みは一部仮説です。配信・開封と、ボランティア5人によるタスク手順を検証し、緊急時の代替手段と担当者を定義します。D——利用率は合格に見えても、コーディネーターが非公式の表計算ファイルを残すという、反直感的なガバナンス上の失敗。指標：移行後も編集が続くこと。公開前に廃止基準と例外記録を定義します。

その他の仮説：モバイルのアクセシビリティがタスク完了を妨げる。研修2回では交代勤務者をカバーできない。ベンダーの不具合対応が2人週を超える。強み：2チームによる段階的な試験運用、明確な公開権限、ボランティアの視点、測定可能な失敗基準。A と B はデータ基盤を共有しますが、受け入れ確認は別々に必要なため、試験運用前に優先してください。

これがうまくいく理由

1
将来から振り返る想定により、楽観的な計画では抑え込まれがちな失敗原因をチームが挙げやすくなります。
2
指標と低コストの検証により、想定した失敗を、計画変更に使える根拠へ変えられます。

結果を確認

シナリオはこのプロジェクトに固有で、提示された根拠に結び付いているか、仮説と明記されていますか？
上位シナリオに早期指標、低コストの検証、発動条件、実行可能な対応がありますか？
出力は責任追及、根拠のない確率、同じ因果関係の重複表現を避けていますか？

安心して使うために

よくある質問

このレシピをいつ使うか、何を用意するか、どの場面で人による確認が依然として重要かについての実践的な回答です。

「プロジェクトのプレモーテムを実施する」を使う前に、何を準備すればよいですか？

「プロジェクトのプレモーテムを実施する」には、プロジェクトと失敗判定日、根拠と仮定、参加者と対応権限を準備してください。プレースホルダーは確認できる情報だけで置き換え、不明な詳細はモデルに推測させず、不明であることを明示してください。

「プロジェクトのプレモーテムを実施する」の結果は、どのような場合にまだ使えませんか？

提示された根拠から、記載された成果である「根拠、指標、担当者、すぐに行う実験を含む、優先順位付きの失敗シナリオ図」をまだ作成できていない場合や、未解決の仮定、不足する承認、作り上げた詳細に依存している場合、結果は使用できません。チェック項目を公開可否の基準として使い、裏付けのない出力を磨くのではなく、入力情報を修正するか、権限を持つ担当者を指名して確認してください。

「プロジェクトのプレモーテムを実施する」では、どの AI ツールのテスト記録がありますか？

2026-08-28 時点で、「プロジェクトのプレモーテムを実施する」の公開テスト記録には ChatGPT が掲載されています。これは記録された試行があることを示すもので、後の製品バージョンでの互換性や同一の結果を保証するものではありません。別のツールやバージョンを使う場合は、すべての制約を明示したまま、使用前に結果のチェックを繰り返してください。

さらに探す方法