この記事はEngineering Manager Advent Calendar 2018の12/21日の記事です。
これまでの記事を読んでいると同じことを考えている方がいたり参考になる記事も多く学びの多い年末となりました。
はじめに
RettyでVP of Engineeringをやってるkosakoです。
Rettyではこの一年開発組織における課題発見とその解決に向けて様々な取り組みを行ってきました。
課題を洗い出して、課題感が高くかつ解決しやすいものから優先的に取り組んできましたが、一方でどのように組織を設計していくのか？といったことを考えるようになりました。
まだ自分の中でも明確な答えは出ていないのですが現時点での考えを整理してみたいと思います。
よくある課題
プロダクトを作って運用を続けると必然的に技術負債が増えていきますが、今後どのように取り組んでいくか？いつのタイミングでどう解決するのか？といったことはよく議論にあがります。
また過去に作ったプロダクトがあるが運用責任者がいなかったり、オーナーのいない機能やツールなど宙に浮いた責務問題などもよく見かける課題だと思います。
その他にもエンジニアのhuman managementはエンジニアがやったほうがよいということがよく言われますが、やりたがるエンジニアがいなかったり、いても人数が足りなくて一人に負荷が集中するといったこともよく聞く話です。
役割を作る
開発組織において、様々な役割は存在しており
- CTO
- VP of Engineering
- Engineering Manager
- Product Manager
- Tech Lead
などがあります。
その他にもシニアタイトルやアーキテクト、リードエンジニアなどもありその定義も明確なものではなく、なんとなくのイメージはあるものの組織に合わせて定義されるものだったりすると思います。
ここで、この課題を解決する役割の人はTech Leadがあっているようだといったことをしていくと短期的には課題が解決されたりしますが別の課題が出てきます。
似たような役割がふえてしまい結局責務が曖昧になってしまったり、役割ではなく役職になってしまい責務はないのに肩書がある人がふえてしまったり、一つのことに複数の責任者がいることになってしまったり(指揮系統の混乱)、役割を担える人数が足りずにチームをまたいだ兼務の人が増えすぎてしまったりといったことなどが考えられるかと思います。
もちろん組織の規模により必要な役割は増えていきやすいものですが、基本はできるだけシンプルに保つほうがよいはずです。
必要なことは組織やチームで必要な責務を明確にすること、そしてその責務を果たす人がちゃんといることです。
そのためには役割はできるだけシンプルにしてある程度抽象的な役割にしておき、実際の責務をだれにどう割り振るかはそのチームごとに決定するほうがよいと考えています。
その決定事項をjob descriptionとしてチームで共有するといったことなども有用だと思います。
ちなみにどうしても担える人がいない責務はチーム外にアウトソースする選択肢を持つといったこともありでしょう。
では様々な役割がある中でどのような役割を設置すればいいのでしょうか？
それを考えるにはエンジニアや開発だけを見るのではなく組織全体を見ながら考えることが必要になってきます。
事業部制組織と機能別組織
組織の形の話をするときによく出てくるのがこの2つになります。
事業部制組織
事業部制組織はプロダクトや顧客といった単位で事業を区切って組織を作る構造です。
区切り方はサービスごとだったり、toC・toBといった顧客のタイプだったり、営業組織などでは関東や関西といったエリアごとになったりします。
WEBサービスの開発ではにおいては、アプリチーム、検索チームといった形が一般的でしょうか。
そのチームの中にチームリーダー、デザイナー、エンジニアなど様々な職種の人間で構成されます。
メリットは意思決定がチームに与えられるためスピードが早く、全員がチームの目標に向かえるためモチベーションも高い傾向にあります。
デメリットとしてはチーム関連系が弱くなり全社でのノウハウ共有や共通化といったことが問題になりやすいといったものがあります。
機能別組織
機能別組織はR&D、エンジニアチーム、デザイナーチームといった機能別だったり職種別で組織を作る構造になります。
メリットとしては知識の共有が進み専門性が高めていけるところだったり、効率性を非常に高めることができます。
デメリットとしては最終的なプロダクトに対する意識が低くなりやすかったり、職種をまたいだ連携がやりにくくなったりするといったものがあります。
また、意思決定までのラインが長くなりがちで問題が起こったときに各部門だけで意思決定できなくなってしまうといったことも問題になります。
マトリクス組織
それぞれにメリット・デメリットがあるわけですが、スタートアップにおいては基本事業部制をとっているところが多いと思います。
理由はいろいろあると思いますが、不確実性が高い状態においては、意思決定までのコミュニケーションパスが少なく調整コストが低い事業部制が有利になります。
一方で、技術負債の蓄積などによりサービスのフルリニューアルや基盤の統一化といったことをが必要になった時に理解が得られにくい、決断できないといった課題を抱えてるケースも多く見られます。
そこで機能と事業の両方の軸を取り入れたのがマトリクス組織となります。
事業部制と機能別のいいところどりをしようとして導入される形態ですが、もちろん銀の弾丸ではありません。
完全に権限が同じだとうまくいかない例が多く、一人に二人のbossがつくことになるため信頼関係がより強くなった方に嫉妬が生まれるといったことも起きやすくなります。
基本的にはマネジメントの難易度が高く難しい形態であり、調整コストも高くなりがちです。
したがって何を優先するべきかを考えた上で権限、責務の差をつけるようにしたほうが難易度は下がると思います。
- プロダクトの成長やマーケットフィットが優先事項の場合は事業部を強くする
- 高度な技術の開発や基盤の構築が優先事項の場合は機能部門を強くする
今の自分たちに必要な組織デザインとは?
では結局どのようなカタチにすればいいのでしょうか?
エンジニアだけ見てあるべき論で役職や役割を設定してしまうと既存の組織デザインとコンフリクトすることもあり、対立構造になってしまうリスクがあります。
今が間違ってるとかあるべき論が正しいとかではなく、現在の組織がどのような意図をもってデザインされているのか?それが事業フェーズや組織の成長によってリファクタリングが必要なフェーズに来ているかどうかといった視点で考えてみる事が重要ではないかと思います。
またエンジニア組織が事業においてどのような役割になっていて、解決するべき課題はなにかといったことを考えて変えていかなければ、実情にそぐわなくなってしまう危険性があるので注意したいところです。
過去現在未来何を重要と設定してきてどう変化していくのかという観点から、全体の組織デザインを考えること。そして今と未来が繋がるように移行プランも考えながら実行していくことが重要ではないでしょうか。