本コラムでは、僕がエンジニアとしてマネジメントを受けた経験、そしてマネージャーとなりマネジメントを行ってきた両方の経験を踏まえ書いていきます。
僕は20代をテックリードとして、30代をCTO（Chief Technology Officer、最高技術責任者）やVPoE（Vice President of Engineering）といったエンジニアリングマネジメント経験を積んできました。
直近は、Speeeでエンジニアマネジメント責任者とエンジニア採用責任者を兼務してRubyに強い開発組織を顧問と一緒に作ったり、メルカリでVPoEとしてCTOのビジョン実現に向けたエンジニア組織のマネジメントをしていました。現在は合同会社クロスガレージを設立し技術顧問業をやりながら、2020年からサイカでCTOをやっています。
エンジニアリングマネージャーがいない世界
僕が20代のときは「マネジメントされるやつなんて仕事ができないやつ」ぐらいの感じで、「マネジメントされないことが最高のマネジメントだ」と思い込んでいるようなエンジニアでした（笑）。
その背景として、2000年に渋谷がビットバレーと呼ばれていたころは、エンジニアリングマネージャーという言葉はほとんど聞いたことがありませんでした。多くの会社でエンジニアはビジネスマネージャーの直下にあるか、経営陣の直下にありました。かくいう僕自身も、事業責任者や役員の直下でマネジメントされていました。
当時はそれなりに評価をされていた（と思っていた）ので特に不満は感じませんでしたが、それは僕自身が理想を持っていて、正しいと思ったことは誰にでも強く意見できたからでしょう。僕の意見が正しかったかどうかは話が別として。
当時の僕はマネジメントされるなんてあり得ないし、そんなことは無駄だと思っていました。
一緒に働いていたエンジニアを見渡すと、2007年ごろになるとビジネスサイドにマネジメントされることに不満を覚える人たちが増えているように感じはじめました。ビジネスサイドのマネージャーはエンジニアリングの経験がなく、技術の評価やフィードバックが的確にできる人はほぼいなかったことが要因でしょう。
エンジニアリングマネージャーの誕生
ちょうどそのころ、国内のIT界隈ではCTOや技術責任者というポジションを置き、エンジニアがエンジニアをマネジメントするという組織作りが行われる会社が出てきたように思います。ライブドアさんや、はてなさんなどはそれよりも早く取り組んでおり、彼らを参考にしていた企業は多かったと思います。僕も当時ALBERTにCTOポジションとして働いていたので、エンジニアリング以外にエンジニアの組織作りをミッションとして評価制度などを作りました。
エンジニアのマネジメントと言えば、Googleも2002年と2008年にマネージャーを撤廃する実験をしたという話があります[1]。しかし結果としては「マネージャーは必要である」という結論になり、その学びがまとめられています。
ここからの学びの一つとして、Googleは「マネージャーは良いコーチである」と言っています。僕がSpeee時代に新卒育成を担当した際、僕のアドバイスに食らいついてきた若手エンジニアがぐんぐんと成長して他人のフィードバックから学ぶスタンスを身に付け自走するようになり、3年後にはエース級のエンジニアとなったということがありました。
その実体験を通じて、「より成果を出し成長したいなら最初から自分の考えだけで試行錯誤するのではなく、まずはマネージャーに従ったほうが成功確率は高い」と教えています。これはマネージャーがコーチであり、成長を支援してくれる役割であるからです。
良いマネージャーは経験と現場以上の情報を持ち、公平性と客観性を持ったアドバイスができます。そのため、自分自身が考えるよりもより確実性が高く成果を残し、成長ができるでしょう。
さらにエンジニアという専門性を持った人たちは、専門性に理解ある人たちにマネジメントしてもらうことが重要となってきます。スポーツ選手などのスペシャリストが同じ分野で経験ある人をコーチに付けることと一緒です。
だから、エンジニアが大きな成果を残し成長確度を上げるためには、エンジニア経験のあるエンジニアリングマネージャーがいたほうがよく、個人の限界を超えるチャレンジを支援していくコーチとしてのエンジニアリングマネージャーという職種が、現在注目されているのです。
1on1とコーチング
エンジニアとエンジニアリングマネージャーとは一蓮托生で、お互い成長と成果創出につながる良い関係になっていく必要があります。そのために2人の間では定期的なコミュニケーションの場である1on1を行うことをお勧めします。
もしあなたがエンジニアで自分のマネージャーと1on1が定期的に行われていない場合は、まずはそれを設定しましょう。「え？ 設定するのはマネージャーの仕事でしょ？」と思った方、マネージャーと友好なコミュニケーションを築き成果を上げるためには、どっちがそれをやるべきかということはいったん置いておきましょう。パートナーとして考え、お互い不足があるならそれを補っていくというホスピタリティが必要で、それが円滑なコミュニケーションと信頼と生み出します。また、マネージャーになった方も最初からマネジメントのプロフェッショナルだとは限らないのです。あなたが最初からエンジニアとしてプロフェッショナルではなかったように。
参考となる1on1のやり方については、Google re:Workにある「効果的な1対1ミーティングの実施」にまとめられています。とはいえ、1on1の話をすると「そこで何を話せばよいのか？」という質問はよく挙がります。一般的には目標に対する現在の進捗や、障壁となっている課題、キャリアについての相談などが行われていると思います。僕もマネージャーとして1on1をする場合、それらの話は必ずします。
1on1で話す内容を抽象化すると、「マネジメントするメンバーの成果と成長につながることなら何でも話す」というスタンスで取り組むべきで、メンバーには「自分の成果とキャリア成長にマネージャーを利用する」というスタンスで取り組んでほしいと伝えています。
1on1の頻度
「1on1はどれぐらいの頻度で行うのがよいのか」という話もよく挙がりますが、これも前述したre:Workに書いてあるとおり、「毎週または隔週で30～60分、決まった時間に行う」ことをお勧めします。
僕の場合もレポートラインのメンバーは毎週30分もしくは60分で行っています。まだ入社したばかりやレポートラインに入ったばかりで関係が浅い人には必ず60分で行っています。
またメンバーが新しいことにチャレンジしはじめたときも1on1を60分にして、その中でやり方や途中経過の確認をオンボーディング的に行うこともあります。このやり方はマイクロマネジメント的になってしまいますが、心理的不安を取り除き自走できる入口にくるまで並走してあげるようにします。「もう自信を持ってチャレンジできるな？」と思ったら、だんだんと任せはじめ結果を見てフィードバックするようにしオンボーディングの時間を短くしていく、といったようなことを行っています。
GROWモデル
re:Workではコーチングする際、Googleではマネージャーに対してGROWモデルというコーチングのフレームワークを用いることがあると紹介されています。僕もこれは非常に有効な方法だと経験上思っています。
まずゴールを明確化して、そのゴールに対して起こっている状況を把握し現状を整理したうえで、本人にどういったことができるか可能性を考えてもらい、最後にどういったことをしたいかをネクストアクションとして決めてもらいます。そうやってゴールと背景を明確にして、仮説を持ち自らで意思決定をしてアクションにつなげることで、より成果がでやすくなります。たとえ失敗しても振り返りができる材料はそろっているので、この経験が自らの成長につながるわけです。マネージャーになる方は必ず学んでおいたほうが良いフレームワークです。
またこの手法は心理的安全性を生み出しつつチャレンジができる方法として有効なので、いちエンジニアとしても周囲の人たちをエンパワーメントしてより組織を成長させていくために学んでおいて損はないです。いろいろなところでチャレンジが生まれ、成長できているGoogleのような組織で働くのはエンジニアとしても最高な体験ですよね。その可能性を生み出せるコーチングはけっしてマネージャーだけのものではないのです。
まとめ
今回は、エンジニアリングマネージャーの必要性と、そのマネージャーとエンジニアとの関係値を作っていくためのコミュニケーションについて書きました。エンジニアが成果を残すためにはエンジニアマネージャーがいたほうがよい、というのは理解してもらえたかとは思います。
ただ一方でエンジニアリングマネージャーにはエンジニアリングの経験が求められる以上、今までエンジニアをやってきた人がマネージャーとしてチャレンジしていき経験を積んでいくことが必要です。だからこそ、メンバーとなるエンジニア一人一人にもマネジメントについて興味を持ってもらい、マネージャーと友好的なコミュニケーションを築いていき、ときにはエンジニアがマネージャーをエンパワーメントすることに取り組んでほしいと思っています。それが今後、自分自身をはじめより多くのエンジニアの成長につながり、もっと大きな成果を生み出せる、モノづくりにとってより理想的な環境を生み出すことにつながると信じて。
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現！
- 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう
- 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、NFT
