天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

Hatena Engineer Seminar #26 エンジニアリングマネージャー編に参加してきた

hatena.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

Hatena Engineer Seminar #26 のテーマは「エンジニアリングマネージャー(以下「EM」)」です。

はてなでは、開発組織の中にエンジニアリングマネージャー職があり、開発や技術、エンジニアのマネジメントを担当しています。最近、これまで技術組織のマネジメントを担当していたチーフEMのほかに複数のEMが誕生しました。

今回は、開発組織のエンジニアを統括するCTOが組織づくりの観点から、また、はてなブックマーク / マンガ投稿 (集英社様「ジャンプルーキー!」「あしたのヤングジャンプ」、集英社様・はてな「マンガノ」) / ノベル(KADOKAWA様「カクヨム」「魔法のiらんど」)の開発を担当するチームの3名のEMが各人のキャリアやチームで実践した取り組みについてご紹介していきます。

会の様子

はてなのエンジニアリングマネジメント これまでとこれから

最初にCTOのmotemenさんから、今日のイベントの概要やこれまでのはてなの変遷について話がありました。

以下、話があった変遷をまとめます。

  1. 大西部時代(カウボーイ集団、ベンチャー)
  2. チームの誕生(15年前くらい、ディレクター(エンジニアリングやデザイン以外全ての仕事を担当)の誕生。人数は15人)
  3. シニアエンジニアの導入(エンジニアにラダーを導入したかったし、メンティーを明確に用意したかった。人数は30人くらい)
  4. CTO/テックリード誕生(エンジニアとディレクターの距離感解消。デリバリーや品質に責任を持つメンバーの明確化。人数は45人くらい)
  5. 自社toC以外の事業増加(デリバリーリード(SMに似ているイメージだがエンジニアでもある)の誕生。人数は60人くらい)
  6. 分化(EMによって組織の分割統治を開始。人数は80人くらい)

はてなEMキャリアパス 最速攻略RTA 新卒部門

続いて、総合的に思考することに楽しさを感じたことがきっかけでEMを志して実際に今年EMになったyigarashiさんから、EMとは何か?EMにどうやってなれるのか?という話を聞いていきました。

yigarashiさんは、EMは「エンジニアリングを背景に事業の成功のためにあらゆることをやる」職域だと考えているそうで、広木さんの「デリバリーマネジメント/テクノロジーマネジメント/ピープルマネジメント/プロダクトマネジメント」という4領域へ分解して考えると分かりやすくなるのでは?ということです。

また、EMになるための方法に関しても紹介がありました。yigarashiさんは、以下の内容を上から順にやっていったということです。

  • デリバリーマネジメント(WF的なプロジェクトマネジメント+アジャイル手法の学習。PJのバリューストリームに着目しつつ、スクラムをはじめとした実績のある手法を活用した)
  • ピープルマネジメント(1on1, コーチング, ファシリテーションなど育成/能力開発を実践。コミュニケーションを専門スキルと捉えて基礎を学んだ)
  • テクノロジーマネジメント(コード品質、設計、アーキテクチャなど技術に関する領域に触れる。普遍性の高い「良い」状態をinputした後、自分が関わっているプロダクトのソースコードをよく理解し、1年単位で未来の計画を考えた)

また、上記どのフェーズでも、「目の前の仕事を題材にすること」「巨人の肩に乗ること」の2つは常に意識していたそうです。

「いい感じにしといて」を支える技術

次に、shimobayashiさんから、EMになったことで起きた変化*1にまつわる話を聞いていきました。

shimobayashiさんは、プロダクト開発の課題を発見・管理・解決することがEMの職業だと思っているそうで、「情報収集→課題発見→課題管理→課題解決」のステップで仕事をしていくとうまくいくのではないか?と考えているそうです。以下、ステップごとに詳細を記載します。

情報収集

プロダクト開発のメンタルモデル(MVV, 売上 > 戦略 > 作戦 > 計画 > 体制・予算)に沿って情報収集しているそうです。

ただし、現場によってメンタルモデルは異なるため、現場を見て適応していくことが重要だということでした。

課題発見

集めた情報をロジックツリーや現状問題構造ツリーで整理するそうで、集めた情報は図で配置しているということでした。

課題管理

リスト化して管理するようにしているそうで、整理はアイゼンハワーマトリクスを活用しているということです。

課題解決

ここは課題によってぜんぜん違うので一概に言えない一方で、他のチームや世間を見たときに自分のチームとGapがある部分を見つけることができると、ヒントになることが多いというお話でした。

エンジニアとしてチーム改善してたら、EMになってた話

最後にk-murakami0609さんから、EMになりたくないけどEMをやっている人や、EMになりたくないけどEMをやることになった人向けの発表がありました。

k-murakami0609さんは、元々エンジニアとして仕事をしたいと思っていたそうですが、良いプロダクトを安く早くお客さんに届けて喜んで欲しい&無駄をなくしたいとも考えていたため、裁量が与えられて非常にやりがいのあるポジションだと感じたそうです。

また、EMとエンジニアは両立するものだとk-murakami0609さんは考えているそうで、例えばタスクを受け渡すときに、自分で一部手を動かして一部をその人に渡す選択肢が増える*2といったメリットもあるのではないか?ということでした。

会全体を通した感想

同じ会社でも色々なEM像やEMに至るまでのキャリアパスがあって、非常に面白かったです。

皆さん自身がやってきたことやどういう想いを持っているのか言語化するのが上手で、全ての発表が聞きやすかったのも印象的でした。

*1:課題が示されていた状態から、「いい感じにしといて」と言われるようになった

*2:例えばメンバーが興味ない領域のタスクを巻き取れたり、ストレッチアサインに繋げられたりする