TUNAGのプロダクトチーム
開発組織
TUNAGを運営する事業部には開発部と企画部があります。 開発部にはエンジニア、企画部にはプロダクトオーナーとプロジェクトマネージャー、デザイナーが所属しており、この2つの部署が連携してTUNAGの企画・開発を担当しています。
開発プロセスとしてスクラムを採用しており、次の図のように組織は3つのフィーチャーチームと1つのモバイルチームの合計4チームで構成されています。このフィーチャーチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキル(バックエンド・フロントエンド)を備えています。
事業が成長するに従い、開発組織が直面する課題や求められる能力は、刻々と変化してきました。現在はフィーチャーチーム体制としていますが、事業の成長段階に合わせて開発組織も変化させてきました。
例えば、TUNAGリリース後の1〜2年間は、プロダクトの仮説を検証する段階だったからこそ、手段を問わずとりあえずカタチにして素早くリリースすることが求められていたフェーズでした。少人数でお互いの作業を詳しく把握できていたため、チーム分けなどの組織化の必要性はありませんでした。
その後順調に開発組織とプロダクトの規模が大きくなっていきました。またテクノロジートレンドが移り変わるにつれて、技術のベストプラクティスから外れたまま開発をしていくことが、プロダクトの価値向上にブレーキをかけ始めました。このフェーズでは、開発部に「高い専門性」が求められていました。
バックエンド領域では、スケーラビリティの課題を解決するためにサーバレスやコンテナなどを活用したアーキテクチャに更新しました。 クライアント領域では、エンドユーザーの体験価値を最大化できるように技術的負債の返済やフレームワークの導入を進めてきました。チーム構成をバックエンドチームやフロントエンドチームのように技術領域ごとに分け、各技術領域の学習効率を最大化して事業成長を支えました。
しかし、技術的な課題を乗り越えた後には、組織のスケーラビリティの問題に直面しました。
技術領域でチームを分けたことで、1つの機能をデリバリーするまでに「チーム間の依存関係」により開発時のコミュニケーションコストが増えてしまうことが顕著になっていきました。 この組織規模が大きくなったフェーズでは、組織全体として大きな力を出せるような仕組みが求められます。
ユーザーに価値を届けるために必要なコミュニケーションがチーム内で完結するように、全てのスキルをもった機能横断型のチーム体制と、それを支える開発プロセス(大規模スクラムLeSS)への転換を決定しました。
フィーチャーチーム
TUNAG開発部の主体となるフィーチャーチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキル(バックエンド・フロントエンド)を備えたチームです。そして、「ソフトウェアの価値を最速でユーザーに届ける」ために、自律したアジリティの高いチームを目指しています。
理想としては現時点での「できる」「できない」は別として、「全てのエンジニアがプロダクト全体のオーナーである」という意識を持ち、次のような項目を実現できるようになりたいと考えています。
- ユーザー目線での開発
- 当たり前品質を支えるSRE活動
- 価値を遅延なく届けるためのプロジェクトマネジメント
- プロダクトの拡張性・スケーラビリティを見越したコーディング・アーキテクト
- ユーザーの損失を最小限に抑える障害対応
- 開発体験・開発効率向上への取り組み
足りないギャップを徐々に埋めて、お互いに学び合える組織を目指して、モブプログラミングなどのさまざまな取り組みをしています。
その結果、今までのマネージャーやSREなどの個人のロールへ依存していた状態から、多くの機能をもつ自律したチームへと徐々に変化していきました。 例えば、TUNAG開発部のエンジニアには、バックエンド領域(Ruby on Rails)とフロントエンド領域(React)の両方を担当できるメンバーが増えてきました。
自分自身でプロジェクトマネジメントをするのは当然のこと、リリースした機能のパフォーマンスを自ら監視し、必要があれば自分でパフォーマンスチューニングをすることもしています。 また、開発者がAWSなどのクラウドのアラート対応などのSRE業務をしたり、開発フェーズだけでなく運用フェーズも担当できるエンジニアの比率が大きくなってきました。
一人のエンジニアの活躍の範囲が広がれば、当然認知負荷も大きくなります。そのため、コンテナ化やサーバーレス化など、アーキテクチャのモダン化などによる運用コストの圧縮や、社内勉強会の積極的な開催やモブプログラミングによる組織学習がこのアジリティ向上の取り組みを支えています。
一方でフィーチャーチーム体制は、プロダクト開発におけるコミュニケーションを最優先することになり、技術領域ごとにおけるコミュニケーションの優先順位が下がってしまうことを意味します。ただ、そのコミュニケーションの優先順位が下がってしまうことを意識した上で、それをカバーできるような動きを取れば対処できると考えています。例えばSRE領域やフロントエンド領域などは、今まで以上に標準化の推進や分科会などの会議体設計の工夫をしています。
また、大切な点は、プロダクト開発に最適化されたフィーチャーチームを開発組織の主体にしていきたいということであり、全てをフィーチャーチームで統一したいというわけではありません。事業をプロダクトで伸ばすためには、各技術領域のエキスパートの力が不可欠です。今後はモバイルアプリチーム含めて必要に応じて専門チームを追加していくなど、上手くバランスを取っていきたいと考えています。
開発プロセスについて
技術領域でチームを分けていた頃は、開発プロジェクトごとに必要なスキルを持ったメンバーが各チームから集められ、完了するとチームを解散するといったように「プロジェクト」を中心に開発を進めてきました。 そのため、「納期」や「担当」といったようなプロジェクト自体の関心事が大きくなりがちで、プロダクト全体の価値を考える機会が多くはありませんでした。
プロジェクト中心ではなく、プロダクト全体の優先順位に関心を向け、「なぜこれが重要なのか」「誰のためなのか」というようにプロダクト全体の価値を追求する「プロダクト文化」を醸成していきたいと考えています。
また、今までは開発タスクに個人が割り当てられていたため、「個人vs課題」という構図になりやすく、同じチームだったとしてもメンバーの開発内容や困っていることを把握しづらいという状況がありました。そのため、今後は開発タスクをチームに割り当てることで「チームvs課題」という構図に変え、より一体感を持って課題に向き合えるような「チーム文化」を醸成できる土台をつくっていきたいと考えています。
2021年冬、これらの狙いを実現できそうな開発プロセスを調査しました。プロダクト全体の価値を追求するため、「施策の優先順位が明瞭になること」、そして「シンプルであること」という観点で、最終的に大規模スクラム(LeSS)を採用しました。
2022年2月から大規模スクラム(LeSS)への移行を開始したものの、開発部にはこれまでスクラム自体の経験がありません。さらに大規模スクラム(LeSS)ともなると導入難易度も高いので、社外の支援経験が豊富なスクラムコーチに協力を仰ぎ、短期間でスクラムの良さを引き出せる状態になることを目指しています。
まだまだ手探りの状態なので、大規模スクラムの導入とその後については、適宜更新していきます。