「コードの品質には自信があるのに、なぜか同期の方が先に昇進した...」
こんな悔しい思いをしたことはありませんか？GitHubのコミットログを見れば作業内容は分かるのに、上司から「もっと報告してほしい」と言われて困惑している方も多いでしょう。
実は、技術力が高いエンジニアほど陥りがちな「報告の罠」があるんです。今回は、継続率100%を維持してきたPMの視点から、エンジニアが正当に評価される報告術をお伝えします。
なぜ技術力があっても昇進できないのか？
あなたの技術力に問題はありません。問題は「評価の仕組み」を理解していないことです。
評価 = 成果 × 安心感
多くのエンジニアは「成果」にばかり注力します。しかし、上司が重視するのは「安心感」の部分。特に管理職になると、チーム全体の進捗管理や リスク回避が主な仕事になります。
あなたが完璧なコードを書けても、上司にとって「進捗が見えない状況」は大きなストレスなのです。
上司が本当に知りたいこと
- このタスクは予定通り終わるのか？
- 技術的な問題は発生していないか？
- 他のメンバーに影響はないか？
- クライアントへの説明材料は十分か？
コミットログからは、これらの情報は読み取れません。だからこそ、あなたの「言語化」が必要なのです。
エンジニアのための報告タイミング3原則
1. タスク開始時の即レス（5分以内）
タスクを受けたら、まず「受領確認」と「作業予定」を報告しましょう。
悪い例
承知しました。
良い例
承知しました。
・完了予定：○月○日
・アプローチ：既存のライブラリを活用し、パフォーマンスを重視
・懸念点：APIの仕様確認が必要（午後に確認予定）
以上で進めさせていただきます。
この一手間で、上司の不安は大幅に軽減されます。
2. 中間報告のタイミングを見極める
「3日に1回」を基準に、進捗状況を共有します。しかし、エンジニアの場合は以下のタイミングも重要です。
必須報告タイミング
- 設計方針を決定したとき
- 技術的な課題が発見されたとき
- 仕様変更の可能性が出てきたとき
- 予定よりも早く/遅く進んでいるとき
報告テンプレート
【進捗共有】○○機能開発
■現在の状況
・全体進捗：60%（予定通り）
・完了：ログイン画面、認証API
・作業中：データベース設計
■技術的判断
・パフォーマンス向上のため、キャッシュ機能を追加実装
・セキュリティ面を考慮し、暗号化方式を変更
■今後の予定
・明日：テスト実装開始
・完了予定：変更なし（○月○日）
何かご質問があればお気軽にお声かけください。
3. 問題発生時の障害即共有（30分以内）
技術者ほど「解決してから報告しよう」と考えがちですが、これは逆効果です。
問題発見時の報告例
【課題報告】○○機能で技術的課題を発見
■発見した問題
・既存APIの制限により、予定していた機能が実装困難
■影響範囲
・該当機能の完了が2日遅れる可能性
・他機能への影響：なし
■対応方針（案）
1. 代替APIの検討（調査中）
2. 仕様の一部変更
→ どちらがよろしいでしょうか？
30分後に詳細をご報告します。
解決策が見つからなくても、「問題を認識している」ことを伝えるだけで信頼度は上がります。
