はじめに

ログラスでEMをしている勝丸です。最近カジュアル面談で「ログラスの開発チームはどういう分け方をされているのですか？」と聞かれることが増えてきました。今まで詳しく説明した記事がなかったので説明記事を書いてみました。

ログラスの組織の基本思想は、「1チームで機能リリースが完結すること」

ログラスの組織は「1チームで機能リリースが完結すること」を念頭においています。会社によってはバックエンドチーム、フロントエンドチーム、インフラチームという分け方をすることもあると思いますが、ログラスはチームの自律性を高めるに1チームで開発からデリバリーまで閉じるように設計しています。1チームには数人のエンジニアが所属していて、エンジニアが増えるとチームを分割するようにしています。

これはチームトポロジーのストリームアラインドチームという概念を参考にしています。ストリームアラインドチームとは以下のように定義されています。

ストリームアラインドチームとは
価値のある単一の仕事のストリームに沿って働くチームのことだ。ストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザージャーニーやユーザーペルソナの１つのような場合もあるだろう。さらに、なるべくそのチームだけですばやく安全に顧客やユーザーに価値を届けられるように、チームに権限が委譲されている。他のチームへの仕事の引き継ぎは必要ないということだ。ストリームアラインドチームは、組織で根幹となるチームタイプで、残りの基本的なチームタイプの目的は、ストリームアラインドチームの負荷を減らすことにある。

マシュー・スケルトン,マニュエル・パイス. チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 (Japanese Edition) (p.144). Kindle 版

ログラスは現在開発者だけではなくPdM、デザイナー、QAも組み込んだチーム組成にチャレンジしています。企画、開発、デリバリーまでの速度を最速にすることを目指しているからで、チーム内に専任のPdM、デザイナー、QAがいたほうがチームをまたぐよりも遥かにスムーズに意思決定が出来、チーム間の依存を減らすことができるからです。

チームの担当機能制を敷いて、触るコードがバッティングする可能性を下げる

ログラスは機能開発を3チームで進めています。それぞれが独立したチームで行動しているのですが、コードは3つのリポジトリに分かれているわけではありません。1つのコードベースに対し、チームが複数存在すると触るコードがバッティングする可能性が高くなります。チーム分割をした当時はチケットだけを分けて開発をしていたので、触るコードがバッティングして開発がうまく進まないということがありました。

そういった事態を避けるために、担当機能制を敷くことにしました。Aチームは機能A、Bチームは機能B、Cチームは機能Cという様な感じです。担当機能制を敷くことによって、触るコードが分かれてバッティングすることが少なくなりました。

また担当機能制はチームの認知負荷を下げることに非常に有効でした。
知らなくて良い機能を決めることで、各チームが知るべき知識がはっきりするからです。チームトポロジーでもチームの認知負荷を下げることは非常に重要であると書かれています。

各チームがすべての機能を担当する場合、全機能に詳しくなる必要があります。開発するにつれ、機能はどんどん増えるものですが、人間の認知できる量は有限なので、どこかで限界が来ます。なので敢えて担当機能を分けることで、認知負荷を下げることが可能になります。
　担当機能を適切に分けることで、知らなくていい情報がわかるので、新しく入ってきたメンバーがキャッチアップしやすくなりました。

また担当機能制はオンコールにも良い影響がありました。全チームがすべての機能の面倒を見ていたときがあるのですが、オンコールの内容によっては自分の詳しくないコードを読んで解決する必要がありました。
それが担当制を敷くことで、オンコール担当は担当チームへのエスカレーションだけで済み、結果的にケースクローズまでの時間が短縮できるように成りました。
　また担当機能が明確に決まっているので、不具合が発生した場合の責任の所在も明らかです。もし品質が不安定な機能があった場合はその責任は担当チームであり、担当チームが問題解決をする必要があります。

とはいえ、機能開発チームだけでは回らないので、横串チームを組織した

ここまで1チームで機能開発が完結するようにチーム組成していると書いてきましたが、機能開発の文脈から漏れる対応必須な案件も確実に存在します。以前は機能開発の間に落ちるようなタスクは、機能開発チームが善意で拾うような運用になっていましたが、善意で拾いきれなかったり、そもそも解くのに機能開発の片手間では解けないような課題が増えてきました。
機能開発の間に落ちるようなタスクは、以下のようなタスクを想定しています。

• セキュリティの向上
• 開発者体験（開発効率）の向上
• インフラストラクチャー運用

そういうタスクに対応するために横串チームを組織しました。
そしてこれはチームトポロジーのイネーブリングチームを参考にしていま
す。

イネイブリングチームとは
イネイブリングチームは、特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フレームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案を行う。そうすることで、ストリームアラインドチームは、多大な労力をかけずに能力を獲得し進化できる（私たちの経験では、能力獲得と進化を自分でやる場合に必要な労力がチームに与える影響は、10～15倍過小評価されている）

マシュー・スケルトン,マニュエル・パイス. チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 (Japanese Edition) (pp.151-152). Kindle 版.

ちなみにライブラリのバージョンアップなどは、機能のテストなどもあるので横串組織には持たせておらず、機能開発チームで対応しています。そのへんの話はこちらの記事が詳しいです。

これからのログラス開発組織の課題

チーム間の連携が必要になる大玉案件にスムーズに対応できるかどうか

今までは一定チームに閉じた開発活動が出来ていたのですが、さらに大玉の開発案件が来たときにチーム間でタスクの依存関係が生まれて開発速度が出ないという事が考えられます。
　ログラスはまだまだ発展途上でありサービスの根幹に関わるような機能追加が必要です。そしてその様な機能開発は全チームが関係することになるでしょう。「一時的にチームを統合させる」や「互いのチームが関連しないようにタスクを分解する」などの対応策を考えています。
それはプロダクトマネージャーやエンジニアリングマネージャーの腕の見せ所になるのかなと感じています。

チームをどこまで増やせるのか

機能開発チームを更に増やすことが出来るのではないかと考えています。いたずらに人を増やしてチームを組織すれば良いわけではなく、それによって逆に全体のスピードが落ちてしまうことがあるのは、機能開発あるあるだと思います。依存を極力生まないにはどうすればいいのかを日々探っています。

さいごに

この記事ではログラス開発組織の設計思想を説明しました。チームトポロジーを参考に組織を実装しています。ストリームアラインドチームとイネーブリングチームが連携しながら日々の開発を行っています。チームトポロジーを読まれた方はぜひカジュアルにお話ししましょう。