大紹介 atama plus のエンジニアリング組織の施策集
はじめに
atama plus の深澤 (@qluto) です。
一人目のエンジニアリングマネージャーとして活動をし始め、採用・組織作り・制度づくり・技術的負債の解消といった課題に向き合いながら組織運営全般の活動を推し進め、最近その全バトンを新たな人に受け渡しました。
この4年間を振り返った大局的な記事を書いたのですが、組織運営の具体的な活動内容をそれ単独で追加記事としてみました。
ここに紹介した取り組みは他組織にコピペできるものではなく、コンテクストを理解した上で自組織に本当に必要なことはなんだろうかということを考え抜くことが大事だと考えています。そのためコンテクストがきちんと伝わるように書いており、とても長い記事です。
様々な組織パターンについて聞くのは食傷気味だとか、そこから学んだ抽象的な考え方のほうが知りたいという人は最後の節まで読み飛ばしてもらっても構いません。
この文章はどんな人向け？
特にスタートアップのような変化の激しい開発組織において、これから分業や仕事間の調整を図って組織をスケールさせていく必要を感じているがどのように考えをまとめればいいか探りかねている人、分業や調整をしているけれど課題を感じている人向けです。
開発体制が、エンジニア人数15人ほどから50人ほどになるまでの4年間で進めてきたこと、そこから学んだことについて実例を交えながら紹介していきます。
エンジニアに焦点を当てた話のためここでは詳しく触れませんが、エンジニア以外の職能も含めた開発組織規模としては20人ほどから70人ほどへの変化になります。
組織の Before / After
冒頭で軽く組織規模の前後比較を行いましたが、このあとの具体的な例がよりはっきりとつかめるよう、より詳しく背景を説明しておきます。
筆者が入社した頃は15人が5チームに分かれて開発を進める体制でした。担当アプリケーションごとのチームが3つ、レコメンドエンジンを開発するチームが1つ、クラウドインフラストラクチャを扱うチームが1つといったかたちです。いわゆるマネジメントとしての専任者などはおらず、全員で必要なものをより良い検証サイクルにて届けるべく、個別のスクラムチームとして立ち振る舞っていたと言えます。
今ではエンジニアの人数は50人ほどとなり、チームの数は10以上にまで広がりました。その中にはチーム間連携をより上手く行うための役割や、社内のエンジニアに向けて価値を提供する開発チームが存在していたりと、より発展的な組織設計が組まれています。
さて、ここからは具体的にどのような組織設計、コミュニケーション設計が行われてきたかという話に移ります。
チームの設計、役割の設計、それ未満だけれども大事な横断的コミュニケーション機会の設計という3つの分類でみていきましょう。
組織運営の数々の取り組み詳細
はっきり大きなリソース投資としての、特定役割を持ったチーム組成の検討内容
まずはチーム設計です。組織図として社内外にもはっきりと見てとりやすいものでもありますし、実際にどのような開発にどのようにリソースを割いているかというのを多く表現したものでもあります。
チームが組成されるということは、そのチームのミッションやアウトカム、業務領域、リソース自体を会社として重要だと置いていることをはっきり表現することにつながります。
atama plus でもその時々で何が必要かということを話し合った上でチームを組成してきました。
創業のころから大事にしているアジャイル開発、スクラムというプラクティスをより大規模な開発でも活かすべく LeSS をもとにしたチーム数のスケールは、チーム組成にあたっての大事な考え方でした。LeSS の話はすでに記事や登壇スライドなどで多く語られているので、この記事では割愛します。
ここでは、節のタイトルの通り、”特定役割をもったチーム”を詳しく紹介します。
SRE
組織の Before / After でも少し触れた通り、以前からクラウドインフラストラクチャを扱うチームがインフラチームとして存在していました。その名の通りプロダクトを展開・運用するためのインフラ構築を行なっていたチームなのですが、プロダクトの利用規模が大きくなりや複雑性が増すなかで健全なシステムスケーリングや日々のインフラに関する開発・運用の効率化を図っていく必要性が次第に高まっていました。
チームの規模拡大、チームとしてありたい姿、世間一般でも知名度が上がってきていた Site Reliability Engineering の考えに基づいて SRE チームとして改名し、プロダクト開発のためのインフラ関連業務を素早く効率化するようなチームとなっています。高まりゆくデータベース負荷に対処するためのシャード化を行なったり、大規模に運用していた Heroku からよりスケールしやすく高度な効率化を図りやすい ECS への移行を無事に進めることができたのも専門性をもった強固なチームがいたからこそでした。
Kaizen
Kaizenというチームについてです。Webアプリケーションフレームワークのアップデートや非機能要件に当たるような品質改善、CI/CDを通じてのビルドパイプラインといったような、インフラストラクチャではない部分の DevOps を主な業務範囲としていると言えるようなチームです。
立ち上げ当初、具体的にどのような活動をしてきたかは上記スライドが詳しいのですが、ここではなぜそういったチームを組成するに至ったかというところを紹介します。
スライドにある通り、Kaizen というチームが起こる前も、絶妙な隙間を縫うような形でこういった開発を推し進めていたのですが、エンドユーザに向き合ってどのように価値提供を行っていくかということ、どのように開発パイプラインを磨き上げて価値提供をしやすくしていくかということの両方を同時に意識することはチームのプロダクトオーナーの認知負荷も高くコンテクストスイッチも容易ではないということから、専任チームを作るに至りました。
今は技術的関心ごとを軸足とした遊軍的な立ち振る舞いをしていることもあり、何が守備範囲なのかということを白黒はっきり線引きしにくくはなっているのですが、プロダクトの認証基盤をどうしていくかという技術検証は、このチームの形があったからこそ進めやすかった開発内容だったと言えます。
チーム立ち上げ当初は自分がチームのプロダクトオーナーを担っていました。そのときには生まれて間もないチーム活動が上手く形取られるようにしたということも意識していましたが、持続的で高品質な開発を続けるための検知・改善のループがうまく回るために足りなさそうなことを埋めるということも意識していました。現状の可視化が行えていなければありたい状態とのギャップもうまく把握できず改善すらままならないよねといった話。OODAループが描けたらいいなみたいな考えもうっすらありました。
Kiban
さらに多様な開発を進めていく中で、技術的資産の大規模な再利用性についても需要が高まってきました。なにかというと、モジュールレベルでのコードベースの再利用や各所から参照されているデータの再利用性といったことです。我々の提供している学習体験をコアとしながらも、それを少しアレンジした新機能を早く作りたいといったことに答えられるような基盤をつくりあげる必要を感じていたということです。
需要自体は“基盤“を作り上げていきたいというものではありましたが、基盤の提供チームとして成立させたものではなく、課題を明らかにし、既存の設計を整えていくようなプロセスを担う”基盤構築チーム”として作られました。実際の活動もモジュール性の高いコードベース設計を打ち立てながらも、どのようにコード内の責務を分離するかといったことを考え、それを守りやすい設計上の工夫や啓蒙活動に励んでいます。これからも会社事業やプロダクト戦略に照らし合わせたソフトウェアアーキテクチャのあり方を模索し皆が自然とそれを扱えている状態を目指していくことになると考えています。
チームトポロジーの言葉を使うのなら、プラットフォームチームではなくイネイブリングチームとしてあろうとしているということになります。
（【資料公開】30分で分かった気になるチームトポロジー 気になる人はこちらも見てみてください。この本の内容をどう活用するかはそれぞれが自分の組織にあてはめて深く考えるところですが、まずチームトポロジーで語られている内容やキーワードを通じて自組織内でステークホルダー同士の共通認識を作るということ自体がとても有意義だったと感じています）
技術企画
SRE, Kaizen, Kiban といった技術的関心ごとに合わせたチーム組成を進めてきましたが、それでもなお、預かりどころを定めづらい話題も日々あがり続けていました。単に今まで話題に出たことのなかった新たな話題であったり、そもそもそれをはっきりとした課題として取り上げるには情報が不十分であるとか、費用対効果や実現可能性を判断するだけの解決策まではっきりしていないなど、理由は様々でした。
状況を改善すべく、少なくとも議論が空中に浮きっぱなしになっている話題を減らすべく、多様な話題を扱えるように領域横断のメンバー数名で兼務チームを構成しました。エンジニアから上がる懸念・課題のうち重要性が高そうなものを掘り下げ、課題を噛み砕いた上でどのチームで預かって進めていくかということを話し合うことが主な活動でした。
1週間のスプリントの中で兼務での作業に時間を捻出することの難しさや、領域横断的な話題を取り扱いながら解決のための実行体制を描いていくことのコミュニケーションの取りづらさ、さらに複雑化し多様となってきた話題に対するキャッチアップの難しさといった点を踏まえて、新たな形を模索することになりました。
後述する、組織設計の役割を持った人と技術的課題を取り扱う役割を持った人の2人体制で片手間以上の時間リソースをとって議論をしていくという形です。これによって時間をじっくりかけて議論をしたり、各方面に対する情報キャッチアップを行うことで情報の集約自体は叶いました。
ただ、話題の発端でも解決を実際に進めるでもないところで、その話題を扱う構図であったため、情報連携をするためのコミュニケーションコストやリードタイムの増加が負担になっていました。
そのため、より広範囲にステークホルダーを集結したディスカッショングループを構成することを検討中です。
期待や責務が明確な役割の定義の検討内容
チームを組成する以外にも、特定の役割を定義し、より個人にフォーカスした振る舞いを明らかにすることで浮きがちなボールを拾いにいきやすくしたり、相談先を明らかにしてお見合いになりにくい状態にしたり、自チーム以外の活動に目を向けやすくしロールモデルを見出しやすくすることなどを狙いました。
Dev Unit Success / Dev Success
いわゆるマネジメント的役割は定義されていませんでしたが、組織の発展と共に必要な業務を見極めながら、そういった役割を定義づけてきました。
atama plus では、「マネージャー」という呼称を回避してきました。マネージャーと呼ぶと強い権威構造を想起したり、従業員の業務を厳しく監視し統制し半ば強制的に従わせる”ボス”といったステレオタイプを真っ先に念頭に置きすぎてしまう人が出てほしくないという理由からです。その代わり、必要な責務から設計した独自の役割定義を置くようにし無用な誤解がないようにしてきました。
カスタマーサクセスという役割は世の中で広く認知されてきていますが、それにあやかり社内のエンジニア（社内では Dev と呼んでます）を成功裏に導く支援者として Dev Unit Success / Dev Success という命名をしています。その責務自体は斬新なものというよりは堅実に積み上げてきたという感じです。
Dev Unit Success は複数のチームのエンジニアをまとめた Unit を見る役割、Dev Success は Unit 内のサブセットとなるチームを見る役割でありますが、両者間に強い上下関係などは置いてはいません。Dev Unit Success は各 Dev Success 間の調整を図ったり、両役割の定義自体を適切に運用するなどのメタな業務を持っているといったところでしょうか。
自分自身がこの Dev Unit Success を務めていたわけですが、その際には以下の点を特に意識していました
組織が安定してスケールするために欠かせないことは何か
最初ははっきりとしていない、あるいはこの先も同じようなことが定常的に発生しうるかどうかはまだわからない業務を “組織の例外処理“ として預かり、定常的に発する見込みや課題解決のためのリソースをスケールさせる必要性がみえてきたタイミングで、役割やチームとしてそれを定義し、皆で預かれるようにするにはどうするべきか
Deliver Planning
一つの機能開発は一つのチームで収まるよう設計されたフィーチャーチーム（チームトポロジーで言えばストリームアラインドチーム）ではありますが、やや長めの期間を見据えた一連の機能開発の流れや、チーム間の連携が求められる開発内容に対しては状況を取りまとめたりするなどしてプロセスをリードする役割の人が求められるシーンが増えてきました。世間一般で言うところのプロジェクトマネジメントが一番近いものです。
チーム内でお互いよしなに必要な動きをとっていくという共通認識だけでは立ち振る舞い方の工夫や改善自体を話題にすることすら難しかったため、デュアルトラックアジャイルでいうところの Discover & Deliver のうち、Deliver というプロセスをうまく前に進めるものとして Deliver Planning という役割を定義しました。
チームの開発内容のコンフリクトを早期に検知したり、息を合わせた開発内容の工夫を図るなどして、よりよい開発を目指したりできるような連携を進めています。
Component Mentor
LeSS の体制下では特定領域に関する属人性の高まりは回避されるべきものではありますが、仕様もシステムも複雑であり超高頻度で手を入れるわけでもない領域をどのように預かっていくかということが悩みの種でした。
「たまたま以前この部分を触ったことがあるから相談を持ちかけられるけれども、日々の更新をちゃんと追いかけ切れているわけではないのでスッキリした答えも返しづらい……」といったことがちらほらと起きていました。
そんな中、上記の条件に当てはまるような特殊領域を一手に引き受けてシステム改善を推し進めてくれたメンバーがおり、すでに一貫した技術的意思決定が行えるよう各所からの相談を受けてくれていたことから、これを形のある役割としておくようにしました。
誰か一人だけに寄せるのではなく、ある程度冗長性があったほうがよいのでは、他にもこの役割を置く領域がもっとあってよいのではといったことについても、他の組織設計パターンと見比べながら引き続き考えています。
Tech Lead
Dev Unit Success / Dev Success という役割にて組織的側面、個々人のソフトスキルなどに向き合った組織運営は整いつつありましたが、プロダクト戦略を実現するにあたっての技術的課題を特定し、優先順位をつけた上でより実現可能性の高いプロダクト戦略を組み上げるということはなかなかできていませんでした。
さまざまな開発内容が進む中でも一貫した技術的意思決定ができる状態になるべく Tech Lead という役割をおき情報を集約するようにしました。（Tech Lead という呼び名は世間一般でも広く受け入れられているものです。独自命名のものが社内で多くなりつつあったため、認知負荷軽減のためにより一般的な概念を取り入れていくことを飲んだゆえの命名をしました）
ベテランエンジニアのそれまでの振る舞いを下地にした役割としてまずは成立しているものの、他職種との連携や機体調整などについて相互理解を深めていく必要があります。
組織や役割の調整機構としての、横断コミュニケーション設計の検討内容
オンボーディング
組織作りはまず採用からとも言えますが、採用の話ひとつとっても語れることがたくさんあるので、ここでは入社後にスムーズに開発に入っていけるようなコミュニケーション機会の創出としてのオンボーディングに目を向けてみます。
エンジニア向けのオンボーディングは上記記事の通り、atama plus に入社したエンジニアが早く活躍できるようにするためのプログラムとして持続的にアップデートを重ねています。長らくの間中途入社向けの内容が主となっていましたが、新卒入社の方向けにエンジニアとしての基礎的な部分を補強し、スムーズに開発に入れるようなものとして増強されています。
持続的にアップデートを重ねていることもあり、入社3ヶ月で活躍ができる状態に到達するという当初の目的は十分にかなっていると言えます。
伸び代がどこにあるか？と問われたら、すでに大規模となったコードベースに対するソフトウェアアーキテクチャの読み解き方や設計思想の言語化が挙げられると答えるところでしょうか。
Dev Unit Gathering!
下記記事でも触れていますが、チームを超えたエンジニア同士のコミュニケーション機会として継続しているイベントです。LeSS を運用する中でチーム横断でのレトロスペクティブを行なっていたものが独自進化したというものです。
数ヶ月に1度、OST形式でなんでも自由に話したい話題を持ち込む場なのですが、普段の開発チームを横断してのコラボレーションの創出機会となったり、毎週のスクラムスプリント内のレトロでは目を向けづらい中長期の方向性に対する疑問や懸念、意気込みを口にしやすい場となっており、有意義な場となっています。
こういった場の運用をする上で心がけているコツは、気軽に話題を出して話し合ってもらう対話を重視しておりなんらかの結論や成果を追い求める必要はないと最初に宣言しておくこと、イベントが終わった後、取り上げられた話題のフォローアップをちゃんと行うことで「ここで気になっていることを口にすれば不安が解消されたり、改善が進むんだ」と感じ取ってもらうというところでしょうか。
Dev Lumberjack Day
Dev Unit Gathering! から生まれた社内ハッカソンイベントです。
上記記事内でも経緯が語られていますが、もともと直接的な価値提供につながる機能開発以外にエンジニアとしての実験的な取り組みや開発改善活動に一定割合の業務時間を割くことは認められていました。
とはいえ忙しさに追われる中、自分自身で可処分時間を工面したり、ひとりで動くにはアイディアも知識も足りないかも……などなどの悩みがあったところにハッカソンという強い要望とアイディアが合流し、 あれよあれよと開催にいたったという流れです。
ギルド
Spotifyモデルをご存知の方には馴染みの深い”ギルド”です。
とはいってもこれが成立するまでには紆余曲折、うまくいかないこともたくさんありました。
LeSS にはコミュニティという組織横断的なグループに関するプラクティスが案内されているのですが、これをやんわりとした形で始めた結果、興味のある技術的内容に対する勉強会でもなく、開発時間を多く確保できるわけでもないのになんとなくコミットメントを求められるという集まりとなってしまいました。どっちつかずとなってしまい高いモチベーションを維持しづらかったため一度終息をさせました。
ソフトウェアテストを推進し開発をより良く進めるために期間限定のタスクフォースを組成したこともありましたが、ソフトウェアテストの拡充というテーマはほぼ永続的なテーマであり、都度状況をアップデートしながら、かつテストポートフォリオ全体の様子を汲み取りながら良い形のテストピラミッドを目指すことが必要です。期間限定で一度きりのゴール設定をするというのスタイルとは相性が良くありませんでした。
そんななか、既に社内で安定しつつあった別種の活動を手がかりに設計したのが今回のギルドです。社内の定義文章は割愛しますが、端的に言うと “特定テーマの識者たちによって方針提示を行う集まり“ といったところです。
これまでの学びから、そのテーマに強い関心を寄せており「ありたい姿」を描く人がいること、組織としての実行リソース調整を図れる人が加わっていることなど要点を明記しての設計になっています。
アイディアの提案と調整
これは正直にいうと、なにか収まりの良い形に落ち着いているとまでは言えない話です。
上記のチームや役割、コミュニケーション機会で拾えるものが多くなってきてはいますが、それでも小粒だけど見逃すのは惜しいといった話題の預かりどころを調整する機会を、週に一度の定例にて相談する場で賄っています。
より具体化されたアイディア、影響も大きく慎重な判断を行いたい際の手段として ADR （Architectural Decision Record） をもとにしたものを用意しています。確かに重要な意思決定を丁寧に進めるのにはよかったものの、そもそも提案をするには重た過ぎて腰が上がりにくい手段となっていました。また、長期に取り組む内容であったときに提案者と実行者が異なっていき元々の思いを受け止め軌道修正を行うことがやりにくかったという課題もありました。
もっと気軽に、かつ提案者が最後まで主体性を持ってことをなすための手段を作れればよいなと考えているところです。ティール組織における助言プロセスを土台にしたやり方はそれに見合う一つの手がかりかもしれません。
結び: 組織改善を図るに当たって大事だったこと、あるいはその過程から学んだこと
これまでの私の経験から、チームの運営、役割分担、ゆるやかなコミュニケーションの大切さを学び、本記事ではそれぞれの取り組みや試行錯誤について紹介してきました。
atama plus の事例が自分達なりの組織を描くための手がかりになっていれば幸いです。
私は他組織の取り組みを聞いたり、書籍を読んで情報を集めたりしながら、これらのことを考え、後押ししてきました。そして、その結果得た教訓をまとめ、今回の記事の結びの言葉としたいと思います。
以前にも言及しましたが、他組織で成功しているパターンをそのまま自組織に取り入れるという方法は、大抵の場合、成功しないことが多いです。多くの方がご存知のように、「Spotifyはもうあの時有名になったSpotifyモデルを使っていない。我々はそれを自社の問題に対応させ進化させてきた。あなたたちもそうすべきだ」(Spotify’s Failed #SquadGoals) という記事の存在は、他組織の取り組みを単純にコピー＆ペーストすることの問題点を示しています。
私自身もその教訓を念頭に、自組織に何が必要なのか、どのように他組織の事例をアレンジすれば良いのかを考えてきました。それは一定の成果を上げることができましたが、他組織の事例をアレンジするという出発点自体が、実は遠回りだったのです。
どんなに優れた組織設計を描いても、最終的に組織の形は、その組織に所属するメンバーの活動によって決まります。
任意の組織設計は多種多様な人々のインタラクションによって生まれます。しかし、未来に対する不確実性が高く、未知の事態に遭遇する可能性が高い組織、または組織自体の変化が激しい組織では、借りてきた組織設計がうまく当てはまる可能性は低いです。
それでも、有効なアプローチとして挙げられるのは、既に必要性と熱意を伴い成果を上げている活動に名前をつけ、その安定化とスケールアップを図ることです。はっきりやり遂げたいことが見えてから他組織でのやり方を参考にするという順番の方がしっくりきます。
ある程度の大きさや安定性を持つ組織においては、理想的な設計からの活動展開が有効だとは思います。しかし、我々のような規模や変動性のある組織では、上記のアプローチが最も有効だと感じています。
さらに、自分自身へ言い聞かせるものでもありますが、組織の改善という重責を担う人々は、組織内の工夫を重ねることで課題を解決しようとするきらいがあるかもしれません。しかし、これまでの経験を通じて学んだことは、プログラマーの哲学の一つであるYAGNI（You Aren't Gonna Need It）を組織運営のときにも思い出すべきだということです。
これらを押さえておくことで、組織改善に取り組む際の視点が少しでも広がれば幸いです。
この記事が気に入ったらサポートをしてみませんか？