非EMがEMConf JP 2025に参加して学んだこと〜エンジニア視点で見るEMの役割と未来〜

はじめに

プロダクト開発部でTUNAGの開発をしているhisaです。最近、花粉の症状が出始めて悩まされています。目のかゆみと戦いながらも、先週EMConf JP 2025に参加してきました。

エンジニアリングマネジメント（EM）は、エンジニアのキャリアの中でも特に難易度が高い領域の一つだと感じています。私はEMではありませんが、「プロダクトに関わるすべての人が幸せになれば」という思いを持ち、そのためには「良いプロダクトを作るには良い組織が必要」と考えています。その延長として、EMについての理解を深めたいと思い、EMConf JP 2025に参加しました。

今回のカンファレンスを通じて、EMという役割の多様性と、その難しさを改めて実感しました。また、EMだけの問題ではなく、エンジニアとしても組織やプロジェクト運営に関わることの大切さを学びました。本記事では、非EMの立場から見たEMの役割や学びについて、特に印象に残ったポイントを紹介します。

エンジニアとしての学び

1. 不確実性との向き合い方

「エンジニアリングは不確実性との戦い」と言われることがありますが、EMにとっても同じであることが分かりました。

カンファレンスでは「フェイルファスト（Fail Fast）」という考え方が強調されていました。特に印象的だったのは、不確実性を無理に排除しようとするのではなく、向き合い、小さな成功体験を積み重ねていくことが重要だという話です。

エンジニアリングにおいても、技術選定や仕様策定の際に「最適解が分からないから決められない」と迷うことは多々あります。しかし、その状態を避けるのではなく、「とりあえず試す」「失敗してもすぐにリカバーできる環境を整える」といったアプローチが大切だと感じました。

2. タスク管理ではなくリスク管理

「プロジェクトマネジメントとはタスクを管理するのではなく、リスクを管理すること」という話がありました。

ソフトウェア開発は目に見えないことが多く、進捗の管理が難しいですが、そもそも「進捗を管理しようとする」こと自体が間違っているのかもしれません。

重要なのは、何がリスクになり得るかを見極め、それを最小化すること。

特に、以下のポイントが印象に残りました。

進捗共有を頻繁に行うこと
- プロダクトの完成形が見えにくいからこそ、こまめな共有が必要
- チームメンバーだけでなく、ステークホルダーにとっても進捗が可視化されている状態を作る
タスクよりもリスクを中心に考えること
- 「このタスクが終わるか？」ではなく、「どこでつまずく可能性があるか？」を考える

これはプロジェクトマネージャーだけでなく、エンジニアとしても意識できるポイントだと感じました。

3. 技術的負債とエンジニアリングマネジメント

技術的負債に関する話も多く出てきました。「技術的負債とアーキテクチャは対の存在」という考え方はとても腑に落ちるものでした。技術的負債は見えてしまえば管理できる。逆に言えば、見えていないから管理が難しくなる。

エンジニアとしても、以下のような点を意識することで、EMや組織全体に貢献できるのではないかと感じました。

技術的負債の可視化
- 負債がどこにあるかを整理し、共有する
ADR（Architecture Decision Record）の管理
- どんな判断をしたのか記録を残し、振り返りやすくする
非機能要件の見える化
- 性能・運用コスト・可用性などの指標を数値化する

EMは「エンジニアが働きやすい環境を作る」役割ですが、その環境づくりにエンジニア自身が協力することも重要だと感じています。

EMの役割とは？

EMの役割について話を聞く中で、「EMとは価値を実現するためになんとかすること」という表現が印象に残りました。

これは単にチームの管理をするのではなく、「必要なことを理解し、それを実現するためにあらゆる手段を講じる」役割だということです。

「なんとかする」とは？
- 制約のある中で、目標を達成する手段を探す
- 必要なスキルがなければ、自ら学ぶか、適切な人をアサインする
- プロダクトの方向性が見えないときに、仮説を立て、検証のサイクルを回す
- 組織の成長に合わせて、マネジメントの仕組みそのものを変える

つまり、EMは「何をすべきか」「どうすれば組織として目標を達成できるか」を考え、障害を取り除く仕事をしていると感じました。

これは、EMだけの話ではなく、エンジニアとしても「自分の仕事をどう価値につなげるか？」を考える上でヒントになる考え方だと思いました。