プロジェクト週次進捗の共有

週次進捗報告が形骸化する瞬間は決まっています。うまくいったことだけが並び、ステータスがすべて「青信号」になっているときです。そして納期の2週間前に問題が一気に噴き出し、その時には周囲が手を打つ時間が残されていません。プロジェクト進捗報告プロンプトの目的は、悪い知らせが表の外に追いやられないよう、あらかじめそのための枠を確保することです。

形式の段落でステータスを「順調・注意・危険」の3択に限定した理由はここにあります。自由に書かせると「進行中」という曖昧な言葉ですべての欄が埋め尽くされ、遅れているのかどうかが分からなくなります。「根拠（1行）」の列を設けることで、ステータス判断の根拠となる事実を隣に並べ、読み手がその妥当性を確認できるようにしています。

制約の段落にある「課題事項に記載されたマイルストーンは順調にしないでください」は短いながらも最も重要な指示です。メモに問題が書かれていても、モデルは文章を整えようとして楽観的な表現に偏りがちだからです。表の下に「依頼・サポート希望事項」の枠を設けたのも同じ目的です。枠がなければ、必要な支援要請は書かれないまま終わってしまいます。

最後の段落では、出力前にセルフチェックを行わせています。進捗共有をチャットボットに任せた際によくある失敗は、冒頭の条件を後から忘れてしまうことですが、最後に条件と照合させることで、すべて「順調」で埋まった表を出力してしまう事態を自律的に防ぎます。

出力結果は「画面設計レビューが完了し、QA環境の構築も終わりました」のように、完了したことだけを並べた文章になってしまいます。決済代行会社の仕様書が未受領で開発が止まっているという重要な事実は「一部確認中」という曖昧な一言に要約され、その文章を読んでも誰も助け舟を出せません。マイルストーン別のステータスもないため、チームリーダーはどのスケジュールが危険なのかを改めて聞き直す必要があります。

セルフチェックを指示する最終段落を無視して初稿のまま出力するモデルもあります。その場合は結果を受け取った後、「ステータスが順調になっている各項目の根拠をもう一度確認してください」と追加で指示してください。