この記事はカケハシPart1 Advent Calendar 2023の12/25分の記事になります。 カケハシPart2 Advent Calendar 2023もありますので、ご興味あれば読んで頂けたら幸いです。
はじめに
こんにちは。カケハシCTOの海老原です。カケハシでは2022年から明確にエンジニアリングマネージャー制を敷きそれを前提に組織を構成していますが、そこに至るまで様々な紆余曲折を経たり、また設定後も隣接職種間でのいわゆるRole & Responsibilityに関する議論が多く行われてきました。今回は、この点について既存のフレームワークを援用しつつ私の考え方をまとめてみたいと思います。
長すぎるので先にまとめ
- 事業フェーズに応じて開発ディレクター概念の発生からエンジニアリングマネージャー設置までのシームレスな流れがあった
- 両者は本来明確に分かれるというよりはグラデーションのある役割分担だと思う
- エンジニアリングマネジメントは、エンジニアリングチームをプロダクトに見立てたプロダクトマネジメントのようなものだと考えると分かりやすいのではないか
- エンジニアリングマネジメントトライアングルも、その前提で整理できると分かりやすいのではないか
- エンジニアリングマネジメントトライアングルは、エンジニアリングマネージャーが自分で全部埋めるのが偉いのではなくチームでカバーされている状況を作るのが重要
カケハシのエンジニアリングマネジメントの歴史
考え方をまとめる前に、そもそもエンジニアリングマネジメントという概念にどのような変遷を辿ってきたのかごく簡単に整理してみます。
創業期
創業から最初のサービスであるMusubiをリリースするまでの一年間は毎日が戦場であり混沌の極みであったため、一般的なレベルでのエンジニアリングマネジメントというものは存在しなかったと思います。ただ、そのような状況でもブロークンながらスクラムの技法で開発を回していたためスクラムマスターとしての一般的な業務、つまり開発の進め方の定義やスクラムのプラクティスのファシリテーションは私が行っていました。
コミュニケーションにおけるHRT概念などのインストールや、相互理解のためのチームビルディングのアクティビティはエンジニアリングマネジメント領域に含まれるかも知れません。また、サービスを開発チームの自分ごと化するため(サービスマーケティングやポートフォリオ構成に対する意識と半々でしたが)に行った初期メンバーを交えたサービス名決定の議論を断行したのは、なにげにその後のあらゆることに良きにつけ悪しきにつけ大きなインパクトのある行動だったかも知れません(創業当初はサービス名は社名と同様の「カケハシ」になる予定だった)。
開発ディレクターの設置
二年目以降は私はより全体感のある課題に注力する必要があった―要は開発者の採用体制構築が急務だった―ため実開発へのコミットメントは極力減らしていく必要がありました。ここは比較的珍しい点かと思いますが、まだ全社で10人程度の規模の組織の段階で専任のスクラムマスターを開発チームごとに設置するという意思決定をしました。特にまだ人員が潤沢でないスタートアップではソフトウェアエンジニアがスクラム関連のファシリテーションも兼ねるケースが多いと思いますが(この時も実際はコードも書いていたと思いますが、あくまでメインの業務はスクラムマスターと考えて欲しいとミッション伝達していた)、チームのコンディションやより良い仕事の進め方とサービスの品質や開発の敏捷性の関連性に強めの思想を持っていたためそれを専任ミッションとする人員の配置を必須としました。
「スクラムマスター」はあくまでスクラム上の概念ですし、また本来であればプロダクトオーナー以外のどの立場の人が行ってもいい役割であるはずなので、職種としてはあくまで「開発ディレクター」と今に至るまで表現しています。いずれにしても、CTOによる「オレが三人分になる…」(画像引用略)状態からの脱却を行ったわけですがこの時点ではまだまだ会社のフェーズとして評価・育成観点であったり従業員エンゲージメント、リテンションのようなピープルマネジメント要素は優先順位が高くなかったため、いわゆるエンジニアリングマネジメントの概念はまだ弱かったと思います。
開発ディレクター=実質エンジニアリングマネージャー
その後の変化は主に評価関連が引き金になりました。三年目辺りからは何らかの評価制度に関する動きが発生しており四年目まではどのような制度設計であれ私が開発系職種全員の評価をしていましたが、多分管掌範囲が40人を超える辺りで破綻が見え始めていました。これにあたり人事・業務監督を引き受けるいわゆるミドルマネージャー的立場の設置が考えられましたが、急速で全面的な権限委譲というよりは目標管理とその達成のサポート、その結果としての中間評価者のミッションを開発ディレクターに設定するという漸近的・修正可能なアプローチを取りました。
これについては、それまでの組織の前提にあった完全に無階層な状態からのギャップ・認知負荷を抑える側面もあれば、役割の定義や肩書と実際の業務のずれや組織を動かしていくのにかかる時間の長さのような側面もあり、その良し悪しは今でもはっきりと評価することはできないと感じています。この時点で、開発ディレクターが担う職務はエンジニアリングマネージャーに近くなってきていたのではないでしょうか。
エンジニアリングマネージャーの設置と開発チームの2レポートライン化
開発ディレクターが目標管理・評価関連を担うにあたって最初から見えていた歪みとして、
- スクラムの知見やチームディレクションを期待して採用した開発ディレクターがシニアなソフトウェアエンジニアを専門性の観点で正しく目標管理のサポートをできるのか
- スクラムチームは多職種混合チームとして組成されており、プロダクトマネージャーやデザイナーを専門性の観点で以下略
がありました。事業フェーズの進行・組織拡大の中で、上記の歪みが強く出始めそうなタイミングになりつつ2022年アドベントカレンダーの記事に書いたような「メンタリティやスタンスとしてのフラットさはそれとして組織の分割統治は必要である」という認識に全体として大きなギャップは発生しないだろうという想定のもと、大部分の組織開発上の権限が委譲されたエンジニアリングマネージャー職の設置と(今回のテーマには直接関係しませんが)開発チーム内でのレポートラインをエンジニアリング系と(強いて言うなら)企画系(プロダクトマネージャーとデザイナー)に分ける変更を行いました。
実はこの変更によって必ずしも1つ目の歪みが解決できたとは言えないですが(高い技術的専門性は同じ専門性にしか評価できないのではないか?という問題)、現在も試行錯誤しながら進めているところです。
エンジニアリングマネージャーの設置にあたり、ミッションを設定した人たちには、開発ディレクターとエンジニアリングマネージャーのグラデーションについて概ね以下のような雑な整理を手慰みに書いた上で右に寄ったスタンスで業務していくことを期待するというような話をしました。
余談ですが、デザイナーについては更に状況が更新していて、現在はいわゆる職能集団CoEとしてのデザイナー組織を組成しそこでのマネジメント体制になっています。
エンジニアリングマネジメントについて考える上での前提
ここまで組織的な変遷について述べてきましたが、それを踏まえてエンジニアリングマネージャーの役割について考える前にいくつかの前提を置いておきたいと思います。
エンジニアリングマネージャーは「エンジニアリング」のマネージャーである
違う表現をすれば「エンジニアマネージャー」ではない、ということであり、ピープルマネジメントは重要な一要素ではあるがあくまで一要素でしかなく、マネジメントする対象はエンジニアリング=工学的なアプローチで実現される何らかの出力・成果の安定や増強である、と考えています。エンゲージメント・組織コンディションのような観点は重要ですが、もし管掌範囲において開発進捗の妨げになるより重篤な案件があればそちらに注力することも当然ありえるでしょう。
普遍で不変の役割定義は存在しないからこそ
敢えて言うまでもないようなことにも思えますが、十年以上開発組織を見てきた実感として改めて、何らかの形式化をしたとしてもそれは同時に存在する複数のチーム間で、また同じチームであっても事業やサービスの状況変化によって勘所が大きく変わっていきます。それらをカバーするためには広範囲の内容を入れざるを得ないですが、だからこそ
- 一人で全てをカバーするのではなく、チームとしてその内容がカバーされている状況を目指すこと
- そのカバーの仕方について明確に合意すること、そのために定義を用いて対話することが定義そのものよりも重要
なのではないかと考えています。
開発ディレクターとエンジニアリングマネージャーのグラデーション
これはカケハシにおける職種間の話になりますが、上で述べたエンジニアリングマネージャー設置のタイミングで考えたこととして「本質的には両者に違いはなくカバーする領域の重みのグラデーションなのではないか?」ということがありました。
図の左側が開発ディレクターで右側がエンジニアリングマネージャーの領域としましたが、例えばエンジニアリングマネージャーとして組織の課題を解決する上でどのように複数人が協調して進捗を出していくか、タスク管理していくかといった開発プロセスの具体に対する洞察は必要ですし、逆にスクラムのファシリテーションは単にプラクティスを機械的に回していく仕事ではなくチームとしてことに向き合うためのカウンセリング・メンタリングのようなピープルマネジメント的要素は非常に重要です。
では完全に同一です、と無邪気に言いにくいのは一つには「評価」というものの存在ではないかと考えています。開発ディレクター、あるいは役割としてのスクラムマスターはその性質上会社組織における評価というものにタッチするのは好ましくないと考えていますが(また別の議論になるため詳細は割愛します)、エンジニアリングマネージャーの職責上評価ということをしないのは難しいと思います。
会社運営上の形としていわゆる管理監督者の設定も行う必要があるため、カケハシでは現在エンジニアリングマネージャーは管理監督者であり開発ディレクターはそうではない、という設定をしています。
エンジニアリングマネジメントトライアングルをもう一度考えてみる
開発ディレクターとエンジニアリングマネージャーのグラデーションを考えた後に「これはもう一捻りあるのではないか」と言うのでふと浮かんだのが有名なプロダクトマネジメントトライアングルからの類推だったのですが、当時検索したら既にあったのでまあそりゃそうだよなと思ったことを覚えています。
先達の偉大な成果に弓をひくわけではないし内容もほぼ変わらないのですが、こう整理するとしっくり来ると考えたことについて述べていきたいと思います。
何を中心とするのか?
「エンジニアリング」マネジメントトライアングルなのでエンジニアリングが中心であることは本来当然なのですが、「エンジニアリング」はやや抽象的な概念であることに難しさがあると感じています。
カケハシにおけるエンジニアリングマネジメントに関する変遷の中で開発ディレクターを実質エンジニアリングマネージャーに近い状態に変更させた辺りで考えたり、またメンバーからも相談されたこととして「成果が無形になりがちな開発ディレクターを評価する/されるために自身の成果を報告することの難しさ」がありました。このタイミングから今に至るまで私の中にある考えとして、「チームをプロダクトと見立てたプロダクトマネージャーとして捉えれば、そこからの類推で色々なことが整理可能なのではないか」というものがありました。
その発想から敷衍すると、やや即物的にはなりますがトライアングルの中心は「エンジニアリングチーム」であると割り切るのも一つの手ではないかと思います。頂点は「ピープル」「技術」「事業」とするのが自分としてはしっくり来ていますが、「チーム」を「ピープル」に、「プロダクト」を「事業」に言い換えているだけではないかとも言えると思いますが、エンジニアリングチームはプロダクトを作って終わりではなくその先にある事業の執行や成長への寄与を意識してここはプロダクトではなく事業と言い換えています。
大分思いつきベースで検討の余地があり中身の粒度もバラバラだったりであくまで仮のものですが、この考え方で整理すると例えば以下のようなものになるのではないでしょうか。
せっかくこのような整理の仕方をしているので、「どちらかというと事業より」とか「両者のちょうど中間」といった頂点との距離・位置関係も意識して整理できるとより面白いのではないかと思っています。
エンジニアリングマネジメントトライアングルによる各職種のカバレッジ
このような整理の利点は物事の把握を空間的にしやすくなることだと思いますが、例えば既に散々話題に上がっている開発ディレクターの他にも、例えばテックリードの役割にも活用できるのではないかと思います。事業-ピープルラインの中でもスプリントごとのインクリメントの保証やチーム活性化のような部分に専門家として重点を起くのが開発ディレクターであり、技術の近接範囲を見るのがテックリードという整理もできると思います。
そしてエンジニアリングマネージャーの職責と成果はこのトライアングルがいかにハイレベルに埋められているかにかかってくるのだと考えています。そして、繰り返しですが、自身で急所を埋める動きは当然重要でありつつも本質的に求められるのは自分ひとりでどうにかするのではなく「チーム・組織として」全体が高いレベルでカバーされているのを保証する動きになってくると考えています。
おわりに
今回は、カケハシにおけるエンジニアリングマネジメントの変遷とそこから自然発生的に生まれた役割定義の考え方について述べてきました。途中でも触れている通り、この整理の仕方もあくまでこの瞬間のスナップショットに過ぎず例えば今日中にここがおかしいので考え直しだなとなり得るものです。何事によらず、静的な定義や状態よりもそこからより良い何かに変わっていく変化、そのための運動、対話とそこに発生する相互作用そのものが重要で価値があるというのが私の基本的なスタンスであり、カケハシもまた「どのようにより良く働くのか」に対して非常に意識的な組織だと思います。そのようなトピックに関心がある方は(もちろんそうでない方も)、ディスカッション目的や情報共有ベースでも構いませんので是非カジュアルにアクセスして頂ければと思います。
