こんにちは。プラットフォーム開発部 EMのchika (@chika-mirai) です。
以前（もう半年近く前ですが）、こちら↓のエントリで書籍「チームトポロジー」の感想を書かせていただきました。
miraitranslate-tech.hatenablog.jp
この中で以下のようなことを発していたのですが、
今の自社の開発チーム編成は4つのチームタイプと3つのインタラクションモードに当てはめるとするならどう表現されるだろうか？というのは読者なら気になるところです。今度自分も描いてみてチーム内で話してみようかなと思います。
これを個人的な宿題にしたままだったので、今回はこの宿題提出のためのエントリです。
あらためて、チームトポロジーとは
↑のエントリにも貼っていますが、聞いたことがない方、あまり覚えていないよ、という方は以下の神スライドをご覧ください。
チーム設計のためのテンプレート
チームトポロジー図のテンプレートは、GitHubにて Miro 、Figma、パワポ など様々なお絵描きツールに対応したものが公開されています。
弊社ではMiroを導入しているので、今回は コピペで使えるMiro用のテンプレを使って描いてみることにしました。 （Miroに組み込めるテンプレートもあったのですが、こちら気づけず。まぁ次の機会に。）
書籍で描かれている図とイメージが少し異なりますが、このテンプレートでは下の図のように表現されています。
描いてみた
さて、上記のテンプレートを使って、今のMirai Translator®︎の開発チーム体制を表現してみたのがこちらです。
以下、チームタイプごとに補足説明をします。
ストリームアラインドチーム
- プロダクトチーム：Mirai Translator®︎の機能開発を行うメインチーム
フロントエンド刷新チーム：フロントエンドのリアーキテクチャを行う目的で結成されたプロジェクトチーム
- プロジェクトチームのため正しくはストリームアラインドチームではないが、便宜的に当てはめて表現
- UI/UXチームとはガッツリ協業している
認証認可基盤チーム：認証認可基盤を構築しているチーム
- 将来的にプラットフォームチームになる
イネイブリングチーム
- QAチーム：ストリームアラインドチームにE2Eツールを提供したりテスト観点・ケースレビューを行う
- アーキテクチャチーム：バックエンドのリアーキテクチャを推進するチーム
- SREチーム：CI/CDパイプラインの構築や開発プロセスに沿った環境整備を行うチーム
- 現在はIaCのサポートや環境周りの相談などでリソースとしての開発支援が多い
- アーキテクチャチームにはマイクロサービス基盤の構築面で協業
コンプリケイティッド・サブシステムチーム
- 翻訳エンジンチーム：自然言語処理、機械学習などの専門領域の技術を扱うチーム（プラットフォーム開発部とは別部署のエンジニアリング部）
- アプリケーション（プロダクトチーム）からは利用するだけの状態（X-as-a-Serviceモード）
- デプロイについてはインフラチームに依頼する形で、ここだけ3つのインタラクションモードに当てはまらない状態
直近の課題
UI/UXチームが独立している
UI/UXチームがプロダクトチームとは別チームとして介入したり依頼を受けたりする立場になっていますが、本来はストリームアラインドチームの一員であるはずと考えています。
SREチーム、QAチームはプラットフォームチームにしたい
現在のSREチームはメンバーの稼働を割いて他チームを支援することがまだ多いためイネイブリングチームで表現しましたが、CI/CDパイプラインを強化したりコンテナ基盤を整備したりで徐々に「ツール提供」による支援範囲を広げていますが、これをより進めてプラットフォームチームとして機能させられたらと思っています。
またQAチームも開発の最後の「QAフェーズ」を担っている状態ですが、この「QAフェーズ」は開発のボトルネックになることがあるので、E2Eテストほか各種自動テストツールをストリームアラインドチームに提供し、エンジニア主導で必要十分なテストを実施できるようにするプラットフォームチームとなるのが理想です。
一方でQAはテスト以外にも要件・設計段階での品質観点のレビューや探索的テストなどの専門的スキルを開発サイクルの中で発揮するという役割もあるため、最近はプロダクトチームのスクラムの一員としても活動し始めています。
逆に独立したQAチームは必要なの？という疑問がよく出るQAですが、このあたりは今回の話題と離れてしまうので別の機会に触れられたらと思います。
少し先の展望
ここから先はあくまで私個人の想像や案であり、会社の具体的な方針を表したものなどではないことを先にお断りしておきます。
上記の課題などを踏まえて少し先の体制案を表したのがこちらです。
フロントエンド刷新を行っていたメンバーのほか、UI/UXもプロダクトチームの一員として活動し、プロダクトチームが他の外部のチームに依頼せずとも開発サイクルを回せるようになる状態（フルサイクルな開発チーム）を目指しているイメージです。
SREとQAはプラットフォームチームになっています。
さらに先の将来の展望
組織構造はチームの成熟度、メンバーの入れ替わり、ビジネス環境の変化などにより適切なタイミングで進化させる必要があります。
今後このチームがどのような進化を遂げるかはまだ分かりませんが、せっかくなので少しだけ進化系を表現してみたいと思います。（こちらも先と同じく個人的な案です）
進化のポイントは大きく2つです。
1つは新しいプロダクトが増えることに伴い、専任で開発するストリームアラインドチームが増えるという、ごく自然な進化です。具体的にどんなプロダクトが増えるかによってチームの形は異なると思いますが、ここではプロダクトチームと同じとみなして重ねて表現しました。
チームトポロジーの考え方として、このような二層にわたる表現をするようなチームがあり得るのかというのは定かではないですが、このような表現をしてみると私の想像した形に近いのであえてこのままにしました。
もう1つは、翻訳エンジンチームとコラボレーションするストリームアラインドチーム（翻訳API開発チーム(仮称)）と共にプラットフォームチームを形成するという進化です。
これは、翻訳エンジンチーム自体がインフラチームに依存していたり、一方でプロダクトチームとのインタラクションが不足することによりデリバリー速度が上がらないという課題が顕在化する可能性があるため、翻訳に関するDevOpsを推進していくことが近い将来必要になるだろうと考えて表現しました。
描いてみた感想
これまで開発チーム体制をドキュメントで表現する際の描き方は特にテンプレートがなくチーム間の連携も表現しようとするとセンスが要るなぁと感じていましたが、チームトポロジーでの表現を用いれば、そのチームの役割や他チームとの関わり方もスッキリと分かりやすく描けるので、チームタイプやインタラクションモードの共通理解さえあれば、ツールとして非常に便利ですね。
（ただ慣れないと「このチームはどっちのタイプだろうか？インタラクションは...」と本質的でないところので悩みがちw）
なお前回の投稿でも触れましたが、チームトポロジーで表現するチームは前提として「スモールチームでアジリティのある動き方が出来ていること」が必要なので、チームトポロジーで表現することが相応しいかどうかという問題はあります。
私たちMirai Translator®︎開発チームではリーンな開発を目指してスクラムやリアーキテクチャなどに取り組んでいますが、早くこれらが実を結び理想的なチームトポロジーに沿って進化させていけると良いなと思っています！
We're hiring!
みらい翻訳では、私たちと一緒に開発チームを進化させていけるエンジニアを募集しています！ ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
