プロジェクト現場では、全員が同じレベルのスキルや意識を持っているとは限りません。中には、質問せずに自己完結してしまう人、AIに頼りすぎて理解が浅い人、レビューを軽視する人など、チームの生産性を下げる行動をとるメンバーもいます。この記事では、そうした“困ったエンジニア”とどう向き合うべきかを、現場経験に基づいて解説します。
1. 問題の本質を見極める：スキル不足か、姿勢の問題か
まず重要なのは、「できない理由」がスキルの問題なのか、姿勢の問題なのかを見極めることです。スキル不足なら教育やサポートで解決できますが、姿勢の問題は個人の意識改革が必要です。
例えば「AIにやらせたので理由がわかりません」という発言は、技術力というよりも責任感や学習意欲の問題を示している可能性があります。このような場合、根本的な改善には本人の意識変化が不可欠です。
2. チームのルールを明確化し、責任範囲を線引きする
コミュニケーションを避けるメンバーや、仕様確認を怠るメンバーに対しては、チーム全体でのルール明確化が有効です。例えば、次のような共通認識を文書化しておくとよいでしょう。
- プルリク前にコンパイルエラーがないことを確認する
- レビュー指摘は原則全て対応し、理由がある場合はコメントで説明する
- 不明点は必ず担当者または上長に確認する
こうしたルールを「暗黙の了解」にせず、正式なドキュメントやミーティングで共有することで、後から問題が起きた際の説明責任が明確になります。
3. 教育ではなく“期待値調整”で対応する
本人が意欲的でない場合、いくら教えても改善は見込めません。その場合は、教育よりも期待値の調整が必要です。つまり、難易度の高いタスクを任せず、影響範囲の少ない部分を担当してもらう形に切り替えるのです。
また、タスクの進行を「レビュー依存」にせず、小さく区切って進捗を報告させることで、問題を早期に発見できます。
4. マネージャーや上司への報告を早めに行う
自分の仕事が滞るレベルで影響が出ている場合は、我慢せずに上司やPMへ報告しましょう。その際は感情的な訴えではなく、客観的な事実ベースで伝えるのがポイントです。
例：「コンパイルエラーのままプルリクが提出されるため、レビュー工数が1件あたり30分増えています」「仕様確認が不足しているため、再実装が週1件発生しています」など、具体的な影響を数字で示すと理解されやすいです。
5. 限界を感じたらキャリアの選択も視野に入れる
最終的に、改善の見込みがなく、チーム全体のストレスや生産性低下が続く場合は、環境を変えることも現実的な選択肢です。自分が潰れてしまっては意味がありません。
転職を検討する際は、次の職場で同じ問題を避けるために「チーム文化」や「コードレビュー体制」が整っているかを面接時に確認するとよいでしょう。
6. まとめ
困ったエンジニアと働く状況では、「指導・ルール・報告・線引き」の4ステップで対応することが重要です。個人の性格やスキルを変えるのは難しいですが、チームとしての仕組みを整えることで、被害を最小限に抑えることは可能です。
それでも状況が改善しない場合は、自分のキャリアを守るために「撤退」を選ぶ勇気も必要です。自分の努力が正当に評価される環境で働くことが、長期的な成長につながります。
コメント