「危ない」だけでは伝わらない
設計レビューや開発途中でリスクに気づいたとき、「これ、危ないと思います」とPMに伝えても、動いてもらえないことがある。
PMがすぐに動けない理由は、「危ないこと」は分かっても「何がどう影響するのか」「いつまでに何を判断すれば良いのか」が分からないからだ。
技術的な懸念をPMの判断材料に変えるには、事象から影響・選択肢まで一緒に渡す必要がある。
伝える項目は5つ
1. 何が起きているか（事象）
現在確認できていることを事実として説明する。推測は推測と明示する。
「Aのサードパーティ認証SDKが来月末でサポート終了します。」
2. 何に影響するか（影響）
その事象が放置された場合、スケジュール・品質・コスト・ユーザー体験のどこに波及するかを言う。
「対応しない場合、認証機能が動かなくなり、ログイン不能になる可能性があります。」
3. いつ顕在化するか（発生条件・タイミング）
リスクが現実になるタイミング、または判断期限を示す。
「来月末のサポート終了後に問題が顕在化します。代替SDK調査と実装に2週間は必要なため、今週中に着手判断が必要です。」
4. 選択肢（何ができるか）
「対応するかどうか」だけではなく、複数の選択肢を提示する。
「選択肢は3つあります。①今月中に代替SDK対応（工数2週間）、②動作確認後の暫定対応（1週間）、③一旦現行維持でサポート終了後に緊急対応（リスク高）。」
5. 相談事項（何を決めてほしいか）
PMに判断してほしいことを明確に言う。
「今週中に①②③どれで進めるかの判断をお願いしたいです。」
PMへの相談文例
メールやチャットでの相談例：
【件名】Aの認証SDK サポート終了に伴う対応判断のお願い
事象：AのサードパーティSDKが来月末でサポート終了します。
影響：このまま放置すると認証機能が動作しなくなり、ユーザーのログインが不能になります。
タイミング：今週中に着手判断しないと来月末に間に合いません。
選択肢：
①今月中に代替SDK対応（2週間）
②暫定対応のみ（1週間）
③現行維持→サポート終了後に緊急対応
判断をお願いしたいこと：①②③どれで進めるかを今週中に教えてください。この形にすることで、PMは読んだ瞬間に状況と判断軸が分かる。