食べチョクのプロダクトチームとチームトポロジー
この記事はビビッドガーデン Advent Calendar 2021 最終日の記事です。
皆さんこんにちは、エンジニアの西尾です。
2019年、食べチョクのプロダクトチームは数名だけでした。 2020年から少しずつ、2021年頭からは一気にメンバーが増加し、12月現在は30名近いメンバーが所属しています。
プロダクトチームはもともと大きな1チームでしたが、2021年からチーム分割を検討し、6月頃から本格的に分割を始め、12月現在は7つのチームでプロダクト開発をすすめています。
組織設計、チーム分割にあたり参考にしたのが、チームトポロジーの概念です。 今回はチームトポロジーの一部を食べチョクでの実例を踏まえて紹介しつつ、運用してみての感想や今後の課題について紹介します。
本記事を書くにあたり、日本語版チームトポロジーを大いに参考にしています。
チームファースト
食べチョクのプロダクトチームは、もともと1つだけでした。 徐々にメンバーが増えていき、分割前には10〜15名ほどが所属する、大きな1チームとなっていました。
大きすぎるチームでは以下の問題が発生していました。
- プロダクトが1つのチームで把握するには大きく、メンバーのプロダクトに対する認知負荷がとても高い状態になっていた
- プロダクトの端から端まで把握できるメンバーは極めて少ない。そのため仕事がその分野に詳しい個人に張り付く状態となっていた
- 例えば、定期便の担当はMさん、商品検索はKさん、注文画面はFさん担当といった具合になっていた
- 仕事が個人に張り付くことにより、計画がメンバー個人に左右される状態になっていた
- 今週中に最優先の施策、機能のデリバリーができるかどうかは、担当する個人の能力や状況に左右される
- チームとしてサポートできず、大きなプレッシャーが個人にのしかかる状態であった
- 今週中に最優先の施策、Aさんどうか体を壊さずに無理して実装してくれ!
プロダクトチームのメンバーは続々と増えている状態でした。 増員したのだから、その分チームとしてのケイパビリティを高め成果を出していくことが求められます。 メンバー数名でうまくいっていたときの開発方法や構成のまま増員しても、チームのパフォーマンスはどんどん落ちていってしまいます。
プロダクトが大きく複雑化したことにともない、個人が気合でプロダクトを開発するフェーズは終わりを迎えました。 組織がスケールするために、より大きな成果をだしていくために、2021年はチームとして成果をだしていかなければならない、すなわち物事をすべてチームファーストで考えるフェーズに変わりました。
チーム分割のアンチパターン
チームとして成果を出していくためには、チームサイズは重要です。 効率よく動くためには、大きな1チームから複数の5〜9名が所属する小さなチームに分割する必要があります。
どう分割したらよいのでしょうか。 職能別に分ければよいのか、顧客別に分ければよいのか、機能ベースでわければよいのか、はたまたミッションベースでチームをわければよいのか。
いろいろなアプローチが浮かび、どれも一長一短だと思います。ただし、アンチパターンは存在します。
チームトポロジーでは、頻繁にメンバーが入れ替わるようなプロジェクトベースのチームは良くないと紹介しています。 機能A開発プロジェクトが立ち上がり、メンバーがプロジェクトごとに集められ、プロジェクトが終了したら解散するようなチームはよくありません。 それはチームに知識が蓄積されず結局は個人に作業が紐付いてしまいます。また、メンバーは頻繁にコンテクストスイッチを求められパフォーマンスが出せない恐れがあります。
場当たり的で無策のままチームを分割するのもよくありません。単に情報が分断されただけの開発のしにくい組織になってしまいます。
変更のフローに最適化した組織
チーム分割のアンチパターンはわかりました。ではどうやって分割すればよいのでしょうか。 チームトポロジーでは、変更のフローに最適化した組織を作るのがよいと紹介しています。
なかなか難しい言葉ですが、要はチーム間の引き継ぎを極力少なくし、自分たちのチームの中でできるだけ仕事が完結するチームにするのが良いとのことです。
エンジニアであれば、ときにはすべて自分ひとりで考えて作って運用したほうが速いのでは、と感じたことはないでしょうか。 なぜ速いと思うのか。それは仮説出し、機能検討、デザイン、設計、開発、テスト、デリバリー、運用保守とそこからのフィードバックがすべて自分だけで完結し、 他のメンバーとの調整が発生しなくて楽だからではないでしょうか。
チームにも同じことが言えます。 企画は企画チームが考えて、開発チームに引き継ぐ。開発チームは機能を作りテストチームに引き継ぐ。テストチームの許可がでたらデプロイし運用チームに引き継ぐ。 運用チームは気になる点がありフィードバックはしたいけど他のチームと調整するのは面倒だな。 このように引き継ぎが多いとプロダクトを素早く改善しチームとしてのパフォーマンスを出すことはできません。 重要なフィードバックや気付きも得にくく、良いプロダクトを作ることはできません。
ストリームアラインドチーム
チームトポロジーでは、モダンなソフトウェアの開発と運用に必要なのは、たった4つのチームタイプであると紹介しています。 ストリームアラインドチーム、イネイブリングチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームの4つです。
このうち、組織の根幹となるのがストリームアラインドチームです。
ストリームとはなんでしょうか。 チームトポロジーでは、「ビジネスドメインや組織の能力に沿った仕事の継続的な流れ」と呼んでいます。 またまた難しい言葉ですが、例えばプロタクト開発においては、顧客にどんな価値を届けるかを考え、 企画検討からデリバリー、その後のフィードバックをもとにした改善までの一連の仕事の流れのことをストリームと呼びます。
ストリームアラインドチームは、単一のストリームに沿って動くチームです。 例えば、「カート機能を通じて、顧客がほしいと思った複数の商品を送料を押さえつつ購入できる体験を提供する」といった価値ストリームに沿って動くチームです。 そもそも顧客の課題は何なのか、何をしたら改善するのか、どういう設計にしたらよいか、本番運用はどうしたらよいか、 ストリームアラインドチームは自分たちの中で作業が完結する能力を備えている必要があります。
モダンなソフトウェア組織では、ほとんどのチームがストリームアラインドチームとなるとのことです。 食べチョクのプロダクトチームでは、上記の考えを踏まえつつ、2021年12月現在は3つのストリームアラインドチームを作っています。
ストリームアラインドチームを支える３つのチーム
ストリームアラインドチームはすべての根幹となるチームです。 このチームタイプの他に、ストリームアラインドチームを支える以下3つのチームタイプが定義されています。 今回はチームタイプの紹介は割愛します。詳しくはチームトポロジーを参照ください。
食べチョクのプロダクトチームでは、2021年12月現在、以下3つのチームを設置しています。
- イネイブリングチーム
- 1つのチーム、5名のメンバーが所属しています。内訳は開発全般を担当するメンバーが2名、フロントエンドエンジニアが2名、QAエンジニアが1名です。
- プラットフォームチーム
- 1つのチーム、4名のメンバーが所属しています。
- コンプリケイテッド・サブシステムチーム
- 1つのチーム、3名のメンバーが所属しています。
チームインタラクションモード
チームトポロジーでは、チーム構成について述べているだけでなく、チーム間の関わり方、インタラクションについても紹介しています。 インタラクションモードは、コラボレーション、X-as-a-Service、ファシリテーションの3つを定義しています。この概念も詳しくはチームトポロジーを参照ください。
感想と今後の課題
ここまではチームトポロジーの基本的な概念を、プロダクトチームの実例を踏まえつつ紹介しました。 ここからは実際に採用してみて直面した問題や感想、今後の課題について紹介します。
チームインタラクションはまだまだこれから
インタラクションモードに関しては、食べチョクではうまく実践できてはいません。
コラボレーションについては、2021年12月現在は1つのストリームアラインドチームとコンプリケイテッド・サブシステムチームが行っています。 これはまあ2つのチームが密に協力して機能開発に取り組んでいるというだけです。 朝会や日々の開発、レトロスペクティブは2つのチームで合同実施していますが、プランニングはそれぞれのチームで行っています。
ファシリテーションに関してはイネイブリングチームが行ってはいますが、うまく機能しているのかと聞かれるとそんなことはなく、まだまだこれからです。 ファシリテーションという概念になじみがなく、そもそも何をすればよいのか、チーム内でもうまく認識はとれていないのが実情です。
X-as-a-Serviceでのインタラクションは今の所できていません。
X-as-a-Serviceモデルがうまく機能するのは、サービス境界が正しく選択、実装され、サービスを提供するチームが優れたサービスマネジメントを実践している場合に限られる
とありますが、食べチョクではサービスの境界がまだまだ曖昧なために、運用はできていません。
イネイブリングチームは概念がわかりづらく、運用が難しい
イネイブリングチームは設置していますが、まだ名前だけという状態です。運用が難しい理由は2つあります。
- ファシリテーションがそもそも難しい
- イネイブリングチームとはどういうチームなのか? チーム内にもチーム外にもうまく理解されていない
ファシリテーションについては前述したとおり、まだまだこれからです。
イネイブリングチームとはそもそも何なのか、組織内で学習ができていないというのもあります。 2021年12月に日本語版チームトポロジーが出るまでは、英語の文献と一部の日本語サイトでの紹介しかされていなかったことも大きいと思っています。 今は日本語で読めるようになったため、12月からはチーム内でのTeam Topologies読み合わせ会をすすめて、少しずつ概念の学習をすすめています。
今はファシリテーション先のチームでは、手が回らない施策や機能実装、テストを変わりに担当する、便利なお助けチームになってしまっていることが多いのが実情です。
ストリームアラインドチームが複数のストリームを持っている
ストリームアラインドチームは、単一の仕事のストリームに沿って動くと定義されていますが、現状は複数のストリームを1つのチームが持ってしまっています。
これはストリームの境界がまだまだ曖昧であること、 すべてのストリーム分のチームが用意できるほどメンバーがいないこと、 やることが多くてフォーカスが絞れていないなどのプロダクトマネジメント上の課題など、さまざまな要因が重なっての結果です。
チームの認知負荷を下げるアーキテクチャになっていない
これからの技術課題です。 個人だけでなくチームの認知負荷に注意し、チームが扱うコードベース、アーキテクチャも扱いやすいよう適切に整理していく必要があります。
食べチョクは、今はまだ大きなモノリシックアプリケーションです。 「会員登録の機能を修正したら、なぜか注文画面が壊れた」といった問題が発生することもありました。 ドメインの境界が曖昧で、今は幅広くコードベースを把握していないと怖くて手を入れられない状態にあります。
チームがデリバリーしやすいように、認知負荷を下げて安全に手を加えられるようにするために、チームに合わせてアーキテクチャを整理していかなければなりません。
おわりに
わたしたちはまだチームトポロジーの概念を参考に、チームを整理しただけという段階です。 道半ば、チームとして組織としてスケールし成果を出していくためには、まだまだ改善の余地があります。
チームトポロジーは銀の弾丸ではないので、導入したから組織がうまくまわるというものではありません。 チームのあり方を変えるだけでなく、健全な組織文化の構築、技術やアーキテクチャの整理、プロダクトロードマップの整理やマネジメントの強化などもあわせて行っていく必要があります。
2022年も、よりよい価値のあるプロダクトを生産者・ユーザーに届けられるよう、そして食べチョクがさらなる成長を遂げられるよう、これからも精進していく次第です。
