イベント参加: Engineering Manager Meetup #16 〜EMConf expansion〜 #em_meetup
2025年4月25日に開催された「Engineering Manager Meetup #16 〜EMConf expansion〜」というイベントに参加しました。
株式会社 mento としてフード・ドリンクスポンサーをさせていただきました。僕個人としても、エンジニアリングマネージャーのコミュニティに積極的に参加してみて、人とのつながりや学ぶ機会をどんどん増やしていきたいという気持ちで参加。
イベント構成は、ライトニングトーク（LT）が2本と、OST（オープンスペーステクノロジー）が1セッション。以下に、それぞれで印象に残ったことや気づき、学びを書いてみます。
LT 1: マネージャー不在の組織は機能する？ 元VPoEから見たホラクラシー組織の実態
Ubie株式会社の @capyogu さんによるLT。EMが直面しがちな課題が、ホラクラシー組織によってどう解決され・どう変わるのか、Ubie 社内でのホラクラシー組織運営の実例も含めて紹介されていた。
印象に残ったのは「マネージャーが不要な組織でもマネージメントは必要」ということ。ホラクラシー組織ではマネージャーという役割は存在しないが、マネージメント上の課題は多く発生する。それらの課題に対応するのがマネージャー個人から「チーム」に変わっただけ。
ホラクラシー組織じゃないでも、ホラクラシー組織から学べることがあることに気づいた。リーダー以外もリーダーシップは発揮する必要があるのと同じように、マネージャー以外も何かをマネージメントすることはできるはず。メンバーがマネージャーの役割や責務を少しずつ担っていくことで、多忙になりがちなマネージャーの負荷を減らし、マネージャーが本来向き合うべき、より重要な仕事に時間を使えるようになったりもする。
「いや、それはマネージャーじゃなく、メンバーが自分自身でマネージメントできるんじゃないか」という気づきを得て、日々の業務の中で行動に変えていくのは難しい部分もあるのかもしれない。ホラクラシー組織は、組織構造や環境によって、そういう気づきや行動変容を強制的に生み出すような役割・効用もあるんだということが学びになった。
LT 2: 他責思考で考える、EMとICの本音
株式会社メルカリの @tokkuu さんによるLT。キャリアにおいて開発にEMとIC(Individual Contributor)の双方の役割からプロダクト開発に関わられてきた経験をもとに、EMからIC、ICからEMにどのような「期待」（≒他責思考）があるのかを分析し、期待と実態のギャップを埋めるためのいくつかの手法を紹介されていた。
僕のこれまでのキャリアの中で、「課題の発生原因を他責にせずに、自分ごととして捉えて解決に積極的に取り組むべき」という価値観が、かなり深く刷り込まれている。これ価値観は僕の中ではとても大切なものなんだけど、「他責にせずに」という言葉には解釈に広い幅があり、難しさも感じている。
極端に言えば、課題の原因を100%自責で捉えてしまうと、取りうる解決策も自分個人の学習や行動変容に限られてしまう。実際は、プロダクト開発はチームというシステムで行うものなので、100%自分が原因で発生した課題なんてほとんど存在しない。過剰な自責思考が、建設的な振り返りや原因究明、解決策の検討や今後の改善を邪魔してしまうことがある。
「他責思考」という言葉だけを捉えると、少しネガティブな印象を持ってしまうかもしれない。でも、それを「他人への期待」と置き換えると、印象は大きく変わる。起きてほしくない課題が起きた時に、自分は他人に何を期待していたのか、また同じ課題が起きないようにこれからは何を期待するのか。自責思考だけにとらわれずに、他責思考で考えることで、チームとしてより本質的な答えに辿り着ける可能性がある、ということに気づくことができた。
OST - 「EMよくわからん」
OSTでは、最初に「議論したいテーマ」を参加者が付箋に書いて前に張り出し、参加者が興味があるテーマに対して投票を実施。その後上位５テーマが選ばれ、テーマに参加者が分かれて議論を行う形で進行した。
選ばれたテーマの中で「EMよくわからん」というテーマがあり、語呂が面白かったのと「そういえば自分もEMってどういう仕事なのかよくわからないな」と思ったので、参加してみた。
議論に参加して、会社・組織の規模や体制、フェーズ、その時の注力テーマや、EM個人のスキルセットなどによって、EMの仕事内容は本当に多様だということを再実感した。
僕自身、EMのような役割で仕事していた時を振り返って、一言でその頃の仕事内容を表現するのは難しい。大きく言うと「プロダクト開発チームのパフォーマンス最大化」なんだけど、これを聞いても一体何をしている人なのかピンとこないし、それ以外にも日々起きる緊急性の高い様々なタスク（トラブル対応含む）に追われていたりもしたので、全てを表現できている感じはしない。
議論の中で印象に残ったのは、日々仕事内容が変わる緊急性の高い仕事以外に、全体の5%くらいの時間で薄く長く取り組んでいる中長期的なテーマがある、という話だった。開発組織のあるべき姿に向かって、本来やるべき中長期的な投資（＝重要だが緊急ではない仕事）から、EMがなんなのかを定義して「よくわからん」状態を脱却できるかもしれないという期待が一瞬沸いた。
けど、緊急性の高い仕事に追われていて、重要な仕事に全体の5%くらいの時間しか使えていなかったり、そもそも全く時間が使えなかったりすることも多い。この、本来やるべきことに深く集中して取り組み時間が少ない、ということが「EMよくわからん」状態が発生している根本原因なのかもしれない。これに気づいたことがOSTでの個人的な一番の学びだった。
他にも、仕事からどの要素がなくなったらEMじゃなくなるの？という問いに対しては「ピープルマネージメント」と答える人が多かったが、HRBPとどう違うの？じゃあEMにエンジニアリングはなぜ必要なの？と意見もあって、興味深かった。
まとめると、「EMよくわからん」テーマの議論に参加したら、さらに「EMよくわからん」状態になる、という結果になった。
僕は、「EMよくわからない状況でも、やれること・やるべきことはあるし、前に進むしかない」と思って、よくわからない状態のまま、あまり気にせず、深く考えないタイプ。だから実際は「EMよくわからん」は僕にとって少なくても顕在化した課題ではない。
でも、そうじゃないEMも世の中にはいるのかもしれない、「EMよくわかる」状態になることで、より楽に仕事ができて救われるEMもいるのかもしれない、という自分以外のEM像が想像ができてよかった。
おわりに
LT2本もとても良いインプット・勉強になり、その後のOSTでしっかりアウトプットまでできるとても素敵なイベントだった。また次回も参加したいと思う。運営・スポンサーの皆様、ありがとうございました。
機会があれば、いつか登壇もしてみたいです。
Member discussion