michiomochi/📝Blog/🔰1人目のEngineering Managerが最初の半年間何をやるか
🔰

1人目のEngineering Managerが最初の半年間何をやるか

Engineering Manager Advent Calendar 2023 14日目です。
https://adventar.org/calendars/8763
 
私は株式会社カンムでバンドルカード事業部のEngineering Manager (EM)をしています。
カンムには1人目のEMとして今年の2023年7月に入社しました。
EMがいなかった会社で1人目のEMが入社してからの半年の間に何をやってきたのかを書きます。
 
EMがどのような役割を担うべきかというのは理解していたものの、役割の型のようなものが決まっていない中でどのようなことをやっていくのか、というのは単に「EMという役割を全うする」といった話に収まらない難しさがあったため、同じ境遇の人の参考になれば幸いです。

目次

入社した時の会社の状況

自分が入社した時の会社の規模は社員数が50名弱で、これから事業拡大を行うためにどんどん採用を行っていくぞ、とちょうどなり始めた時期でした。
そんな中でチーム規模を拡大させるためには開発チームにもEMという役割が必要になってきたということで採用されたのが私です。
私が入社した後、事業責任者やPdMといった役割の人も続々と入社しており、非常に拡大期だなと思ったのを覚えています。

半年間なにをやってきたか

私が入社してから半年間、以下のようなことをやってきました。
  1. 自分が期待されている役割の把握 (7月)
  1. チームの業務理解 (7月〜8月)
  1. EMが求められている仕事の主導 (9月〜)
  1. 暗黙的なナレッジの言語化 (9月〜)
  1. 課題の言語化 (10月〜)
  1. 課題の解決 (10月〜)
  1. 営みの仕組み化/文化としての定着 (11月〜)

自分が期待されている役割の把握

今までEMはいなかったのでまずはチームがEMに何を求めるかの定義を行いました。
今まではEMがいない中いわゆるPeople ManagementはCTOが行っていたので、まずはどのようなタスクをしていたのかの棚卸しを行いました。
棚卸しをした結果ざっと以下のようなタスクがあることがわかりました。
  • 評価 (昇給等の判断)
  • 各メンバーとの1on1
  • チームやメンバーの目標決めのサポート
  • 別チームとやりとりをする上での橋渡し
  • 採用活動
 
また上長であるCTOが自分にどのような役割を期待しているのかを聞いたところ「メンバーの能力を最大限引き出すことや組織設計/運営を通じ、開発チームのアウトカムを最大化すること」ということを期待しているということを聞くことができました。
 
まずはこれらの今までCTOがやっていたPeople ManagementタスクをCTOから剥がすことと、「期待する役割」を成し遂げることを役割として設定しました。

チームの業務理解

EMは自分のチームがどのような開発を行っているかを以下のような点で深く理解しているべきだと思っています。
  • どのようなユーザーがプロダクトを使ってくれているのか
  • どのような開発プロセスで開発しているか
  • どのようなコードベースで開発しているか
    • 技術的負債はどの程度あるのか
    • 複雑性の高いモジュールやロジックはどれか
  • プロジェクト等の実施はどのように行われるのか
 
これらを本当の意味で理解するためにはまずは自分自身もメンバーと一緒にプロダクト開発をやってみるしかありません。私はEMという役割で採用されましたが最初の数ヶ月はメンバーと一緒に開発やユーザーインタビューを行い、業務理解を深めることに専念しました。
開発の他に日々の運用ops、プロダクトを使ってくれているユーザーへのインタビュー、各プロジェクトにもアサインしてもらい、それらをこなすことでより具体的に業務理解が深められたと思っています。
 
その後は主にEMとして期待されている仕事をこなしていくわけですが、最初の数ヶ月でプロダクト開発について理解を深めることで緊急度の高くない開発タスクやPull Requestのレビューを行えるようになっているため、それらは半年経った今でもEM仕事の傍らで行っています。
これらを定常的に行える環境を作ることでメンバーとの信頼関係も構築できますし、認識の乖離も防げるのではないかと思っています。

EMとして求められている仕事の主導

チームの業務理解ができたタイミングでEMとして求められている仕事を主導し始めました。
前述しましたが以下のような仕事を指します。
  • 評価 (昇給等の判断)
  • 各メンバーとの1on1
  • チームやメンバーの目標決めのサポート
  • 別チームとやりとりをする上での橋渡し
  • 採用活動
 
それぞれ話すとそれだけで1記事になってしまうので割愛させていただきますが、どのように取り組むのかをドキュメント化し、チームと認識合わせながら進めるよう心がけました。
例えば1on1については以下のような記事を書き1on1とはどのような場なのかの認識を合わせるなどをしました。
1on1で話すこと2023/12/14 7:082023/12/14 8:37

暗黙的なナレッジの言語化

EMとして求められている仕事の主導する上でも行いましたが、チーム内で暗黙的に行われていることを積極的にドキュメントに書き起こしました。
実際に書いてみるとチームの共通認識だと思っていたことも意外と細かいところで認識が違っていたりすることがあり、議論のきっかけとなったり、認識が異なっていたものについて明示的なナレッジにすることができました。
こういったチームの認識を言語化していくことで、現在チームはどのような営みが想定されているのかといったことが徐々に言語化できていきました。
言語化することで現在の状態を土台に課題提起を行える環境を整えられたと思っています。
現在の状態が言語化できていない状態だと芯をくった課題提起が行えないのと、芯をくった課題提起が行えたとしてもメンバーはそれを自分ごとには捉えられないと思っています。

課題の言語化

チームの業務理解や暗黙的なナレッジの言語化をある程度進めると自然と課題っぽいものが見えてきました。
ただ、課題っぽいと思ったことも本当に解決すべき課題なのかを判断するのはチームであるべきです。EMだけで解決すべき課題を判断し、解決活動を行ってしまうとチームはそれがなぜ課題なのかをきちんと理解しないまま解決活動を行うことになってしまい本質的な解決が行えなかったり、本当はその課題ではなく別の課題が解決すべきものだったりするためです。
なので見つけた課題っぽいものを自分だけで課題であるとすぐに断定し解決するのではなく、このような課題があると思っていること、課題によりこのような影響があると思っていることをチームに共有し、チームを巻き込んで解決していくことを心がけました。その際のコミュニケーションにも言語化されたナレッジは非常に役に立ちました。

課題の解決

言語化された課題の解決は積極的にチームメンバーに移譲し進めてもらいました。自分よりも圧倒的に業務理解があるので適切な方法で素早く対応してくれるためです。
ただ、課題解決をするにおいて影響範囲が全社に及んだりチームを跨ぐものの場合は私がボールを持ち対応しました。
例えば以下のような課題がそれにあたります。
  • 全社を通してプロジェクト/タスク/課題を透過的に管理できるようにする
    • 今までプロジェクトやタスクが各チームに閉じた形で管理されていたため、今どのようなことが全社的に行われているのが把握できないという課題がありました
  • 特定領域に対応する全社横断の組織を作る
    • 弊社は決済システムを構築しており、各プロダクトが共通して利用する特定のモジュールがあるのですがその対応を属人的に行ってしまっているという課題がありました
 
「特定領域に対応する全社横断の組織を作る」という課題についてはチームのメンバーから直接課題提起があり解決することになったものです。
その他にも「ユーザーフィードバックをプロダクトへ反映させるためのより良い仕組みを作りたい」といった声がメンバーからあがり、解決に動くといったことも行われました。
こういったメンバーからの声は本当にありがたいですし、こういった声に素早く反応し動いていくことで、課題提起をメンバーがしやすくなる環境や文化づくりに繋がってくるのだと思っています。

営みの仕組み化/文化としての定着

暗黙的なナレッジの言語化、課題の言語化、課題の解決といったことを書いてきましたがこれらは1回やって終わりではなく定常的にやることに意味があります。
また定常的にやっていくにあたりEMがいないと行われないのではEMはずっと同じ仕事をし続ける必要がありスケールしていくことができません。
これらを自分含めメンバー全員がやれるようにするには近道はなく、決まったことはドキュメントに書いていく、困ったことがあったら課題として言語化し解決策をチームで決めて実行に移していくといったことを言い続けたり実践してもらうよう促す他ないと思っています。
それらを続けることで徐々に徐々に文化としてチームに定着していき、そのうち息をするように出来るようになっていくといいなと思います。
そのためにこれからも続けてまずは私が主導してこれらの活動を行い文化づくりをしていきます。

これから何をやっていくのか

私はEMという役職が開発チームに必須だとは思っていません。
EMが整備をしなくてもチーム自体が自立してプロダクト開発や課題解決を行える状態がベストだと思っています。ただこういった状態には自然となるわけではなく、そのための仕組みや文化が必要です。その仕組みや文化を作るためにEMがいわゆるレールを敷く必要は感じており、私は今そこに尽力しています。
まずは今自分が所属しているチームを強いプロダクト組織にし、その過程で学んだ強い組織の作り方を全社に展開させていくというのがこれから僕がやっていくことだと認識しています。

付録

ブログのカバー画像を作る中、邪魔してくる社長 😬
 
Xでポスト