こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2018 の22日目の記事です。 前日は@kackytwさんのDQNの学習速度を改善するでした。
Engineering Managerのjob descriptionを共有する流れ
近年、Engineering Manager(EM)業界が賑わってきています。特に2018年は非常に活発化した年でした。書籍としては、エンジニアリング組織論への招待とエンジニアのためのマネジメントキャリアパスという名著が生まれました。また、Engineering Manager Meetupが3回開催され、Slack workspaceでは12/22時点で268人となっています。EMのためのPodcast EM.FMも誕生し、総再生回数が10,000回を突破するなど、多くの方から注目を集めています。*1
私自身もEM Meetupには全て参加していて、毎回アツい議論が展開されています。 その中でも最近のHot TopicはEMのjob descriptionです。 この話の大元は、EM.FMの及川さんがゲストで参加されたep.8にあります。
及川さん: CTOとVPoEはいろんな形で説明したけれども、各社によって組織構造によっても違うし、役割も違う。これが一つと考えずに、ずっと話しているみたいに役割・job descriptionみたいなのを決め、あとはどういうふうな組織構造にするかをしっかり決めていくほうがよいのではないか
広木さん: ２つありますよね。社内の中で明確に役割が決まっている、これが1つ良いことですよね。次のステージとして、社会として決まっていた方がいいというのもあって。転職するとか採用するときに、全体のキャリアパスとしてマネージメントキャリアを積んでいくことが、閉じたキャリアじゃなくなっていく。別の会社にもあるキャリアなんだな、スキルなんだな、というのが見えてくる。2ステップだなと思っています。 あまり各社でjob descriptionをはっきりしないで、公開もしないことが当たり前になってしまうと、社会に共有されるという次のステップにいかないだろうな、と思っていて。及川さんと話していて思うのが、社会でjob descriptionとか求めるものが共有されていって、人が循環していったり、人が高められているステージに早く日本をさせていきたいのかな、と思っていて。
及川さん: そうですね、人材の流動性とかを考えたときにそれはあって、各社ごとに違うといっても、これはこういうCTOです、ということがなんとなくわかって、自分自身ちゃんと説明できるのが良いのかな、と。
このやりとりを聞いて、エンジニア組織のマネージャーのjob descriptionを共有していく取り組みは良い方法だと感じました。 なぜなら、CTO/VPoE/EM/Tech Leadの役割分担が言語化されておらず、一方で他社のEMと話しても組織によってそれぞれの役割が大きく異なっていて、役割を一般化することに苦戦していたためです。
この流れを受けて、EM MeetupのコミュニティでEMのjob descriptionを作ろう、とSlack workspaceで呼びかけてみました。 幸いにも賛同してくださる方が多く、少しずつ進み始めています。 先日のEM Meetup #3でも、約10名のEMの方々と議論が出来ました。
コミュニティとしては、いきなりジェネラルなjob descriptionを作ろうとするのではなく、各社がそれぞれの組織の状態や責任範囲を持ち出し、 そこからCTO/VPoE/EM/Tech Leadの役割を定義していく流れになっています。 そのいちアウトプットとして、本エントリーでは、アカツキのエンジニア組織の状態をRACI図で読み解いてみます。
RACI図とは
RACIとはResponsible(実行責任者)、Accountable(説明責任者)、Consult(相談先)、Informed(報告先)の頭文字をとった言葉で、RACI図はプロジェクト管理で役割/分担を明確にするためのPMBOKにも定義されているフレームワークです。 ある役割やタスクに対して、R/A/C/Iを定義することで、円滑にものごとが進むことをRACI図で期待しています。
CとIは比較的わかりやすいですが、RとAはわかりづらいので、補足で説明します。
responsibilityとaccountabilityの違い
responsibilityとは、実行責任と訳されます。responsibilityを保持している人は、あらゆる手段を使って困難を解決する責務を持っています。 responsibilityを保持している人は1人とは限りません。
一方、accountabilityとは、説明責任と訳されます。*2 accountabilityを保持している人は、誰にいつ聞かれても説明出来る責任を持っています。 accountabilityを保持している人は1人に限定されます。
RACI図を作ってみた
アカツキでは、エンジニア組織の役割として、CTO、VP of Engineering(VPoE)、EM、Lead Engineer(LE)、Memberと分かれています。 アカツキにおけるエンジニア組織のおおまかな役割の違いは以下の通りです。
| 役割 | 業務内容サマリー |
|---|---|
| CTO | 全社の技術な意思決定者 |
| VPoE | エンジニア組織のマネージメント |
| EM | プロダクト/プロジェクトの開発マネージメント |
| LE | プロダクト/プロジェクトの技術意思決定者 |
| Member | プロダクト/プロジェクトの開発 |
さっそく、結果を見てみましょう。
| 責務 | CTO | VPoE | EM | LE | Member |
|---|---|---|---|---|---|
| Big pictureを描く | A,R | C | C | C | C |
| 社内情報システムのテクノロジーの採用 | A,R | C | C | C | I |
| エンジニア組織づくり | I | A,R | R | R | R |
| エンジニアのアサイン | l | A,R | R | C | C |
| エンジニアの評価(LE) | A,R | I | |||
| エンジニアの評価(Member) | I | A | R | R | C |
| エンジニアの評価(EM) | I | A,R | |||
| エンジニアの評価制度設計 | A,R | R | C | C | C |
| エンジニアの採用 | A,R | R | R | R | R |
| エンジニア決裁(一定額以上) | A,R | R | R | R | R |
| エンジニア決裁(一定額未満) | A,R | R | R | R | |
| プロジェクト内のテクノロジーの採用 | C | C | C | A,R | R |
| プロジェクト内の開発チームの組成 | I | A,R | R | R | |
| プロジェクト内の開発チームのピープルマネージメント | I | A,R | R |
何やらたくさんありますが、少しずつ読んでいき、現状のアカツキのエンジニア組織を読み解いていきましょう。
CTOとVPoEの責任の違い
まず、CTOとVPoEがそれぞれaccountabilityを保持している理由を説明します。 アカツキのエンジニア組織のaccountabilityは基本的にCTOが保持します。 一方、CTOの方が技術サイドの志向性が強かったり、VPoEの方が組織サイドの志向性が強い、という特徴もあります。 そのため、CTOからVPoEに一部を権限移譲(委譲ではない)する形でエンジニア組織を成り立たせています。 結果として果たすべき業務に対して、accountabilityをCTOとVPoEが持っていることにつながっています。
さらに、VPoEがaccountabilityを保持しているとき、CTOはInformed(結果を通知される)あるいは空欄(責任なし)になっていることがわかります。 これは権限移譲をした業務に対して、CTOとして結果は知らせて欲しいのか、完全に任せたいのか、という意思を表しています。 CTOのこの2つの意思をはっきりさせるために、以前本ブログで事例紹介した、Management 3.0のDelegation Boardを使いました。
Delegation Boardは、以下のように権限委譲を7段階で表現します。
- 指示する ：管理者として意思決定を行う。
- 売り込む ：意思決定についての人々を納得させる
- 相談する ：決定する前に、チームからの意見を得る
- 同意する ：チームと一緒に決定を下す
- アドバイスする ：チームによる意思決定に影響を及ぼす
- 問い合わせる ：チームの決定後のフィードバックを求める
- 移譲する ：特に影響を及ぼさずチームに任せる
権限を委譲する*3とは、責任を委譲することにもなりますが、RACIでも表現することが出来ます。 特に、accountabilityの移譲の分かれ目がDelegation Level 1~5と6~7です。
Delegation Level 1~5はマネージャーがaccountabilityを保ったままとなります。 逆にaccountabilityをメンバーに移譲すると考えると、マネージャーの役職もセットでやらなければ整合性が合わなくなります。
Delegation Level 6~7はresponsibilityとaccountabilityの移譲です。 6は結果をマネージャーが結果を尋ねる、なので、マネージャーがInformedとなります。 一方、7は完全にチームを任せて移譲する、なので、マネージャーは一切タッチしなくなります。
以上から、Delegation BoardとRACIは以下のように対応していると考えて、RACI図に反映しました。
| Delegation Level | CTO | VPoE |
|---|---|---|
| 1(指示する) | A,R | |
| 2(売り込む) | A,R | I |
| 3(相談する) | A,R | C |
| 4(同意する) | A,R | R |
| 5(アドバイスする) | A | R |
| 6(問い合わせる) | I | A,R |
| 7(移譲する) | A,R |
VPoEとEMの責任の違い
RACI図でアカツキの特徴を表しているのは、エンジニアのアサインとエンジニア評価(Member)です。 ここではこの2つに着目します。
エンジニアのアサインの責任
アカツキでは、Matrix型組織を成しており、基本的な意思決定はプロダクト/プロジェクト(簡単のためプロジェクトとします)内で完結するようになっています。
各プロジェクトに1人はEMがいることになっていて、EMがそのプロジェクトに必要となるエンジニアを採用したり、他のプロジェクトから勧誘したりします。このため、EMにはエンジニアのアサインのresponsibilityがあります。 一方、VPoEは組織全体を俯瞰して、ビジネス的な視点でどのエンジニアがどのプロジェクトにいるべきか、の最終的な責任(accountability)を負うようになっています。
エンジニアの評価の責任
アカツキのエンジニア組織は、常に近くにいる人が評価をするのが適切である、という考えを持っています。 このため、プロジェクトに所属するEMあるいはLEがresponsibilityを保持し、プロジェクトのMemberを評価するようになっています。 VPoEの立場としてはMemberがどのような評価をされたのかのaccountabilityを保持していますが、直接的にはMemberの評価をしません。*4
EMとLEの責任の違い
EMとLEの役割の一番の違いはプロジェクト内のテクノロジーの採用と、開発チームのマネージメントです。
テクノロジーの採用の責任
プロジェクト内のテクノロジーの採用の責任は、LEがaccountabilityを持つようになっています。 これはアカツキの基本的な考え方が、最適な技術は最前線に立っているメンバーが適切に判断出来る、となっているためです。 このため、より現場に近い立ち位置のLEが技術的な意思決定をしています。
開発チームのマネージメントの責任
開発チームのマネージメントの責任は、EMがaccountabilityを持つようになっています。 これは、プロジェクトの達成したい目標を実現可能となる開発チームをどのように組成すれば良いか、 チームが潜在的に持っている力を100%発揮させるためにどうすれば良いか、を観察して実行する役割をEMが担っているためです。 そのために目標設定であったり、1on1であったり、開発チームの足りない役割を一時的に埋めたりします。
その他特徴的な事項
エンジニアの採用は全エンジニアがresponsibilityを保持している
エンジニアの採用には、全員がresponsibilityを保持しています。 面談、面接、懇親会など、あらゆる場面で、アカツキの顔として出ていくことを期待しています。
エンジニア決裁は全エンジニアがresponsibilityを保持している
決裁者(accountable)としてCTOあるいはVPoEが保持していますが、決裁が必要となる行動のresponsibilityは全エンジニアが保持しています。 これはアカツキに所属しているエンジニアは自由に行動出来ることを保証していて、かつ、悪いことをしないという信頼をベースに構築された組織としているためです。
RACI図は組織の状態を映し出す
RACI図を作る過程で、CTOとVPoEのaccountabilityの明確化したり、Delegation Boardを更新して、組織の現状がより明確になりました。 これにより、エンジニア組織の責任範囲の透明性が高まった感覚があります。
面白かったのは、RACIが自分の思っていた以上に組織構造に強く依存していた、ということです。 これはつまり、組織構造を考慮せずにjob descriptionを作ることは出来ない、ということを示唆しています。
他でも組織構造とRACI図が作成され、公開されていくと、双方にとってメリットのある取り組みとなりそうですね！
