リリース前リスクチェックリスト作成

リスクチェックをプロンプト1行で依頼すると、「スケジュールの遅延」「予算オーバー」「人員不足」といった教科書通りの回答が返ってきます。間違いではありませんが、どのプロジェクトにも当てはまる抽象論になり、チェックリストに転記しても誰も確認しません。このプロンプトは、その一般論を「今回のプロジェクト固有の言葉」に変換することに重点を置いています。

第1段落の役割は、PMでありつつ「煽りもせず、ありきたりにもしない」人物に設定しています。リスクを尋ねるとAIは安全策として過剰に列挙しがちになるため、両側からブレーキをかけて実用的なサイズに収めます。コンテキストの段落に残りの期間と関連部署を含めているのは、同じリスクでも残り3週間と3ヶ月では打つべき手が異なるからです。

中盤の2行の例示が、アウトプットの目線合わせを行います。良い例には「何が何に引っかかってどうなるか」という因果関係が含まれており、悪い例にはそれがありません。この対比ひとつで、リスク要素の具体性が劇的に上がります。

フォーマット段落の「危険の予兆となるサイン」列は、このチェックリストの実用性を決定づけます。リスクを認識していても、いつ動くべきかわからず手遅れになるケースが多いからです。「確認担当部署」の列を設けているのも同様です。担当が明確でない項目は、会議で読み上げられるだけで誰も持ち帰りません。

制約の段落で項目数を12個に絞り、架空の担当者を防ぎます。20個もあるチェックリストは誰も最後まで読まず、存在しない部署名が混ざると表全体の信頼性が損なわれます。完了済みの作業を除外する指示は、過去の会議メモをそのまま持ち出されるのを防ぎます。

このように依頼すると、「スケジュールリスク／技術リスク／予算リスク」といった見出しの下に、教科書のような説明文が並んで返ってきます。自社のプロジェクトで実際に起こりうるボトルネックが書かれておらず、担当部署もないため、会議で読んでも誰が何をすればいいかが決まりません。

発生可能性が「高」ばかりになってしまう場合があります。表が出力された後に「『高』が半数を超える場合は、基準を見直して再分類してください」と追加で指示すると、バランス良く整理されます。