会議で発言できない理由
「定例会に出席しているが、ほぼ聞くだけになっている」というエンジニアは少なくない。
発言できない理由を「性格の問題」と捉えるのは間違いで、多くの場合は「何を言えばよいかの判断軸がない」ことが原因だ。
PM・PL向けの会議では、ステータス確認・課題判断・スケジュール調整が議題の中心になる。ここにエンジニアとして何を持ち込めるかが分かれば、自然に発言できるようになる。
会議前に整理する4項目
1. 担当作業の現状
「進んでいるか、詰まっているか」を一言で言える状態にする。
「○○は完了、△△は作業中」という形で用意するだけで、進捗確認の場面で発言できるようになる。
2. 技術的な懸念
現在の担当作業や設計で「このまま進むとリスクになりそうだ」と感じていることを言語化しておく。
「AのAPIの仕様変更があった場合、Bの処理に影響します」「テストデータの準備がまだなので、来週のテスト開始が遅れる可能性があります」。
3. 確認したいこと
仕様・優先順位・担当範囲について、会議の場で確認できることがあれば整理する。
「Xの仕様について判断が必要です」「Yの対応はこちらの担当ですか？」の形で用意する。
4. 前回確認事項の結果
前の会議で「確認します」「後で共有します」と言ったことがあれば、その結果を用意する。
技術的な懸念を言語化する
技術的な懸念を会議で発言するときは、「なんか危ない気がします」ではなく、何がどう影響するかを具体的に言う。
「Bのモジュールで使っているライブラリが今月末でサポート終了します。このまま進めると来期のセキュリティ対応で追加工数が発生します。今月中に対応可否の判断をしたいです。」
技術的な詳細は後に回して、「何に影響するか」「いつ判断が必要か」を最初に出す。
発言内容の悪い例・良い例
技術的な懸念を言語化するときの伝え方の違いを示す。
| 悪い例 | 良い例 |
|---|---|
| 「このままだと危ないかもしれません」 | 「本番環境へのデプロイ手順が未確認なため、来週のリリースで問題が起きる可能性があります」 |
| 「Aの件、ちょっと厳しいです」 | 「A機能の実装に予定より1.5日余分にかかっています。今週末の完了が難しいです」 |
| 「仕様が変わったんですけど…」 | 「B機能の画面仕様が先週の打ち合わせから変わっています。変更範囲を確認して明日中に報告します」 |
「何が・いつ・どう影響するか」の3点が入ると、PMが判断できる発言になる。
会議後のフォロー
会議で自分が言った内容は、終わってから議事メモに反映されているか確認する。「言ったけど記録されていなかった」が積み重なると、発言することへの抑止力になる。
フォローしておくことで、次回の発言への信頼感が積み上がる。