急拡大する組織で起きた複数回のチーム分割で学んだこと
小林氏：
改めて自己紹介させてください。テックタッチ株式会社の小林と申します。『Kobaan』というニックネームで呼んでいただければ幸いです。
今年40歳の厄年でして、何度か風邪を引いたり腰痛を経験したりと、意外と厄年って侮れないと思っています。皆様もお気を付けください。
職歴としては、今回のテックタッチが6社目で、SIerから事業会社まで様々な経験をしてきました。ただ、EMとしての役割は初めてで、奮闘しています。
テックタッチでは、開発やプロダクトに関するブログを公開しています。ぜひ見ていただければと思います。
Techtouch Developers Blog - テックタッチ
チーム分割について話す前に、まず前提として組織設計やチーム設計の正解は一つではないと思っています。私自身もウェビナーや他のイベントで勇気づけられた経験もありますので、私どもの経験から学んだことを共有し、悩んでいるEMやチームマネジメントを担当する方々の参考になればと思っています。
テックタッチ株式会社の紹介
弊社についてご紹介させてください。「全てのユーザーがシステムを使いこなせる世界に」をモットーに、デジタルアダプションプラットフォーム（DAP）というジャンルのプロダクトを提供しています。例えば、SalesforceやSAPのようなWebサービスに、自由度の高い操作ガイドを組み込むことが可能となるシステムを開発し、様々なシステムにおける使いやすさや業務効率化を提供しています。
製品リリース後4年弱でユーザー数は200万人を超え、最近では自治体の皆様などにも使っていただく機会が増えてきました。
会社規模は拡大を続け、ちょうど今月（2023年7月）で100人となりました。プロダクト部門も同様に拡大しています。
本題に入る前に、テックタッチの体制について紹介させていただきます。
テックタッチは職能と開発環境のマトリックス組織で、各技術スタックで設計されています。そこからスクラムやプロジェクトにアサインするという方法です。これにより、スクラムチームの再編成がしやすい構成であると考えています。
チーム分割は3回行っており、現在4回目の分割に着手するかという状況です。これから、その経験について話します。
経験に基づくチーム分割
ここからが本題です。チーム分割は難しく、悩みを持つ方も多いと思います。今日はその悩みに答えられるよう、私の経験を共有します。
実はかつて、私はチーム分割には否定的で、むしろチーム統合の方がよいと考え、統合したこともあります。
しかし、実際にチーム分割をしてみると、景色も変わり、メンバーの動きも変わりました。その点について詳しく話ができればと思います。
まず、チームの人数を5〜9人に絞ることが理想的であると考えています。
私自身が10人以上のチームを運営してきた経験から言えることは、チームが大きくなるとチームの機動性が低下する傾向にあるということです。
具体的には、人数が多くなるとスクラムイベントを時間内に終えるのが難しくなります。振り返りのトピックスが多くなり、メンバー一人ひとりの発言量も低下します。
また、多数のタスクを並行して進行することで、優先度の高いタスクが増え、チームとして一つのタスクに集中するのが困難な状況が生まれました。
これらの問題はスプリントゴールを設定する際にも影響を及ぼし、チームの進め方に迷いが生じてしまいました。
その結果、本来自立的に遂行すべきチーム活動も困難になり、チームの一体感が失われるという課題が浮き彫りになりました。
上の図は、私がチーム分割を行ったときのアンケートになります。
10人以上のチームを分割したことで、タスクの進めやすさや認知負荷、スクラムイベントが改善傾向になることがわかります。逆に人数が多かったときはデメリットの方が多かったということを、改めて認識するに至りました。
一方で、チーム分割だけが解決策ではありません。「どのようなチーム編成が最適なのか」という問題については、ストリームアラインドのチーム編成からチームトポロジーを応用した編成へと変更したときの話ができればと思います。
ストリームアラインドの編成は人数を分割することで一定の効果を上げましたが、チーム全体の認知負荷は依然として高いままでした。
案件中心で役割設計がなされる故に、チームの生産性があがりにくいというジレンマを抱えていました。
そのような悩みを抱えていたとき、今年1月に実施されていた「RSGT（Regional Scrum Gathering Tokyo）2023」というイベントに参加し、スケールする際の良い方法についてアドバイスを求めました。
その際、私に衝撃を与えたのは「そもそもスケールアウトよりもスケールインできるようにした方がいいよ」というアジャイルコーチのアドバイスでした。
初めは戸惑いましたが、理解するにつれてこの考え方の有効性を実感しました。スケールアウトした後でも生産性を上げることで、チームが減ってもプロダクトの開発スピードを維持でき、余ったリソースを新規事業に当てることが可能になるという視点は新鮮でした。
その考え方を踏襲しつつ、チームトポロジーを活用した体制設計を再設計しました。
その結果、各チームに役割を持たせて認知負荷を分散することで、より生産性の高い体制への移行を実現できたと感じています。
複雑なコンポーネントを扱うためには深い知識が必要で、それを一つのコンプリケイテッド・サブシステムチームに集中させることで、コンポーネントへの理解や案件への対応力が向上しました。
それと同時に、開発を支えるツール群として自動テストやFeature Toggleといった開発向上施策をPlatformが担うようになりました。
この新たな体制を2ヶ月前に採用したので、結果はまだ見えていません。しかし、チームメンバーの意識が開発の生産性を向上させるタスクに集中することができたため、動機づけとして有効でした。
次に、チーム分割は難しい点が多く、特に一定以上の規模を持つチームでは組織変更に近いと感じる人もいるかもしれません。私自身がそうでした。
私自身、しばしば少人数のリーダー的立場にいる人々と相談し、トップダウン方式でチームの構造を再設計しようと考えました。しかし、それについてメンバーと話し合った結果は撃沈でした（笑）。
メンバーからは「そんなの全く納得できない」という声があがりました。それは当然だと思います。彼らが毎日働くチームの環境が一方的に決定されるのは、納得できないことです。
チーム分割は新しいチームを作ることと同義だと思います。だからこそ、詳細な説明とチームをメンバーと作っていくプロセスは極めて重要であると認識しています。これについて少し詳しくお話ししたいと思います。
上記はチーム編成について記載したNotionの見出しになります。
まずは新しいチームの必要性についてメンバーと話し、互いに納得できることが大切です。
これらの課題について話をしていくと、良いアイディアをメンバーが持っていることがあります。そのため、説得の場というより、双方で洗練しながらチーム体制を構築することを目指した方が進めやすかったと実感しています。
実際にチームが稼働できる段階になった際には、上記のようなワークショップを行っていました。
このようなワークショップを開くことで、チームとしての目的の明確化や発足時の初速向上を期待しています。チームが自らの目標を設定し、どのタスクに取り組むべきか、また取り組むべきでないタスクは何かを決定することで、チームとして動きやすくなると思います。
次に、複数のチームを管理する際の最適なプロセスについて説明します。
私の経験からすると、LeSSというフレームワークの活用が有効です。
以前、テックタッチではチーム分割をする際にLeSS（Large-Scale Scrum）のフレームワークを用いて成功した経験があります。LeSSの具体的な内容はここでは省きますが、オーバーオールイベントという概念が要所にあるおかげでチームのコンテキストを共有できる一方で、チームの役割が定まってきた段階で冗長さを感じる場合もあるという、一長一短の面があります。
そのため、この体制に慣れてきたら1チームスクラムに分割するという戦略を実施していました。
この方法により、各スクラムチームが最適な改善活動に取り組むことが可能となります。
当初はそこまで目立たなかったのですが、チーム分割をする際には必ず「こぼれ球」が生じます。
各チームが自分たちのタスクを担当し、他のチームに特定のタスクを依頼する中で、混乱や食い違いが生じるというケースです。そのため、こぼれ球のリスク管理として、LeSSのようなフレームワークを利用するのも有効であると感じています。
まとめますと、最初に傾向を把握することが重要です。
10人以上のチームになることで人数の多さによる弊害が発生した場合、分割することによるメリットが大きくなると考えています。
私がチームを設計する際には、人数だけでなく、スケールインを意識したチーム設計を行うことをおすすめします。そして、移行する際には、チーム活動を止めないよう、チームメンバーと共に移行を進めることを大切にすると良いのではないでしょうか。
長くなりましたが、ご静聴ありがとうございました。
Chatwork株式会社について
本日お話しする内容についてです。現在、Chatworkが開発生産性向上の一環として取り組んでいるフィーチャーチーム化を目指しています。
その中でモバイルアプリケーション開発部がどのようなチーム構成で開発を進めてきたか、また課題に対してどのようなアクションを取ったのかについて話をさせていただきます。
私の話が、今後の組織開発の参考になればと思っています。
私たちのモバイルアプリ開発にはまだ改善すべき課題があります。もし良い取り組みや意見があれば、ぜひ参考にさせていただきたいと思います。
本日のアジェンダは以下の通りです。
①目指している組織構成
②モバイルアプリケーション開発部のチーム変遷
③まとめ
まず、我々が目指している組織の構成について説明します。
現在、Chatworkでは開発生産性向上の一環としてフィーチャーチーム化を目指しています。ここで言うフィーチャーチームとは、DevOpsを実現する職能横断型の自己管理されたチームを指します。
これをチームトポロジーではストリームアラインドのチームに該当します。ストリームアラインドチームの中には、モバイルアプリ開発の能力を持ったチームも存在します。詳細は「フィーチャーチーム化への取り組みと、それを支える組織マネジメント体制」というスライドにありますので、そちらを参考にしていただければと思います。
フィーチャーチーム化への取り組みと、それを支える組織マネジメント体制
モバイルアプリケーション開発部のチーム変遷について
モバイルアプリケーション開発部は、過去1年半で大きく2回チーム編成を変更しました。その都度、どのような課題があり、どのように改善を期待し、結果はどうだったのかについて説明します。
まずは、iOS/Android混合チームについて説明します。
元々は画像左のように、iOSチームとAndroidチームという形で2つのチームに分けていましたが、その後2つのiOS/Android混合チームに変更し、さらにその後、「ストリームアラインドチーム」「iOSプラットフォームチーム」「Androidプラットフォームチーム」の3つのチームに再編成しました。
この編成を行った背景には、iOSアプリとAndroidアプリの間に機能差が生まれていたという課題がありました。さらに、iOSとAndroidの実装スピードの違いにより、人員リソースに偏りが生じていました。
新しいチーム体制を導入することで、この課題が解消できることを期待していました。
iOSとAndroidのエンジニアがチーム内での仕様についての認識を合わせること。また、両方のプラットフォームを開発できるようになることで、リソースの偏りを吸収できるのではという思惑もありました。
例えば、一方のプロジェクトでリソースが余った場合、その余力をもう一方のプロジェクトの支援に使うといった動きが可能になるのではないかと思いました。
結果として、iOSとAndroidのエンジニア間でのコミュニケーションが活性化し、機能の差異が生まれないようにする取り組みが進展しました。すべての差異がすぐに消えるわけではないですが、できるだけその差を減らす方向に進めることができました。
一方、別のプラットフォームの開発に取り組むメンバーもいましたが、日常的に開発を行わないとなかなかそのスキルが身につかないことが明らかとなりました。
特にモバイル領域は変化が激しく、新しい情報をキャッチアップするのに大きな労力が必要であることを認識しました。さらに、機能開発が優先され、技術的負債の解消が後回しになる傾向も見られました。
新たな課題として、チーム間のコンフリクトを防いだり、リリース時期の調整や他チームのコードレビューを行ったりするためには、各チームがお互いの開発状況や機能開発についての理解が必要でした。
この課題解決のために、チームトポロジーを基盤とし、ストリームアラインドチームとiOS、Androidのプラットフォームチームという3つのチーム体制へと変革しました。
ストリームアラインドチームは、iOSエンジニアとAndroidエンジニアが混在するチームで、プラットフォームチームはそれぞれ専門のエンジニアが集まっています。
この体制変更は、チーム間のコンクリフト防止や情報共有にかかるコストと認知負荷の軽減を目指す目的で行いました。
具体的には、ストリームアラインドチームの認知負荷を軽減することを期待しており、組織全体としてもフィーチャーチームへの移行を目指し、将来的には部外のチームであってもモバイルアプリ開発がどんどん行われていく予定です。
各チームごとの作業内容の変遷とその結果
ストリームアラインドチームはユーザーへの価値提供という観点で機能開発を行います。
プラットフォームチームはストリームアラインドチームのコードレビューや開発サポート、リリース作業やモバイルアプリ開発基盤整備、アーキテクチャの主導、カスタマーサポートからの問い合わせ窓口などを担当しています。
結果として、ストリームアラインドチームの認知負荷は軽減し、機能開発への集中とリードタイムの短縮が実現しました。
ただし、いきなりチームトポロジーに基づくプラットフォームチームとしての振る舞いは難しく、モバイル領域の専門性、例えばオフライン対応やアクセシビリティ、審査のガイドラインなどの理解が必要です。
ストリームアラインドチームには上記のような専門知識が不足しているメンバーもいるため、プラットフォームチームがファシリテーションを行いつつチームの自立性を高める必要があります。
一部の領域ではルール化が可能ですが、アーキテクチャやコーディングルールだけでは網羅することは難しい専門領域がという印象です。
まとめると、チームトポロジーを参考にプラットフォームチームを設立し、ストリームアラインドチームの認知負荷を軽減することが一部できました。
しかし、モバイルアプリ開発の専門家が少ないチームでは他チームにコードレビューを依頼するため、リードタイムが長くなる問題が存在します。
ストリームアラインドチームとプラットフォームチームの責務の分割が難しかったというのが私の感想です。
あくまでチーム分割の目的はストリームアラインドチームの認知負荷を軽減し、機能開発の生産性を向上させることでした。しかし、認知負荷を軽減するために、機能開発以外のすべてをプラットフォームチームが担当するべきかというと、そうではないと思います。
自己管理された機能横断型のチームとして、私たちが目指しているDevOpsを実現するため、すべてをプラットフォームが引き受けるわけではありません。
ストリームアラインドチームもまた、運用と保守の責務を果たす必要があるため、この責務分割が難しく感じました。なので、モバイルアプリ開発における生産性向上のアイデアがあれば、ぜひ教えていただきたいと思っています。
最後にPRさせてください。Chatworkでは新しい仲間を募集しています。私たちのチームでモバイルアプリの機能開発や生産性向上を目指す仲間を探しています。もし興味がある方がいれば、ぜひご連絡いただければと思います。
Chatwork 採用ページ
林さんから福井さんの発表に対する感想
さて、パネルディスカッションに移りたいと思いますが、その前にまずは、それぞれのご登壇に関するお互いの感想をお聞きしたいと思います。まずは小林さんから福井さんの発表に対する感想を聞かせていただけますか？
小林氏：
素晴らしい発表をありがとうございました。私たちも新しいメンバーを募集していますので、興味がある方はぜひご連絡ください。
そして、プラットフォームチームの価値という点についても、私自身、非常に感じています。投資対効果はなかなか表しにくいと思いますが、その中でも、人数比を6:4で設定し、その6をプラットフォームチームに振るというのは大きなポイントだったと思います。その体制を構築する際、上層レイヤーに対しどのように交渉したのかが気になりました。
福井氏：
フィーチャーチームを組織する際、人材募集の観点を特に重視しています。フィーチャーチームに所属するエンジニアは、T型人材と称されるスキルセットを持つ人々で、主専門領域以外もできるだけ自己実装できるような人材を求めています。
そのような観点から人材を分割し、人員比率が形成されました。さらに、現在は過渡期でフィーチャーチーム側のファシリテーションが多く必要となるため、プラットフォームチームに多少のコストがかかる状況にあります。これがプラットフォームチームへの人員配分が多めになった理由でもあります。
小林氏：
参考になりました。ありがとうございました。
福井さんから小林さんの発表に対する感想
福井氏：
小林さんが取り上げた課題は私自身も経験してきたものなので、納得する点がとても多かったです。
特に、新しいチームを形成することが、既存のチーム分割をすることと同じだという点に強く共感しました。良好なチームが形成された時に再度チーム分割をすると、また混乱期間からやりなおすことになります。チームビルディングを行う理由やその共有は、今後も継続して行っていくべきだと感じました。
小林氏：
ありがとうございます。今回のプレゼンテーションでも触れましたが、私たちも最初の段階で失敗を経験しました。そのため、理由付けや共有の必要性を強く感じています。みなさんもチーム形成や分割を行う際は、ぜひ参考にしていただければと思います。
大西氏：
仰るとおり、チーム分割は賛同を得るプロセスが難しいですね。
また、今回は少し違った視点から質問させていただきたいのですが、「チームトポロジー」について調べた際、ストリームアラインドチームの概念はすぐにイメージできましたが、それ以外のチームの役割や概念については、ストリームアラインドチームと比べるとイメージが難しかった印象を受けました。
そこでお二方に質問なのですが、ストリームアラインドチーム以外のチームについて、どのように捉えていますか？また、なぜコンプリケイテッド・サブシステムチームとプラットフォームチームを選んだのか、その理由を教えていただけますか？まずは小林さんからお願いします。
小林氏：
私たちのチームでは、現在イネーブリングチームはまだありませんので、コンプリケイテッド・サブシステムチームとプラットフォームチームについて説明させていただきます。
コンプリケイテッド・サブシステムチームは、解しやすいです。私たちのプロダクトには、ブラウザの仕様やJavaScriptの詳細な部分を探索する必要性がありました。
その一方で、ストリームアラインドチームは通常のタスクと深いレベルのタスクに差があるため、深いレベルのタスクへのアプローチが困難でした。そのため、案件の深度によって対応するチームを分けました。
コンプリケイテッド・サブシステムチームは、特定のテーマに深く没頭できるチームだと考えています。
一方、プラットフォームチームは、正直なところ、まだ試行錯誤しながら進めています。福井さんが話されていたような視点に近いと感じます。例えば、ツール周りの確認やリアーキの下調べを担当するチームになると考えています。
プラットフォームチームは、ストリームアラインドチームを支える存在と捉えています。
大西氏：
非常に理解しやすい説明をありがとうございます。つまり、ストリームアラインドチームはビジネス要件に従ってアジャイルに開発を進め、コンプリケイテッド・サブシステムチームは特定の専門分野に深く特化し、プラットフォームチームはストリームアラインドチームをサポートする役割を担うということですね。
福井さんはいかがでしょうか。プラットフォームと銘打つにあたり、何か悩んだりはされましたか？
福井氏：
プラットフォームチームを設立したのは、ストリームアラインドチームの認知負荷を下げることを目的としていました。
理想はストリームアラインドチームとのコミュニケーションが必要ない状態、つまりX as a Serviceの状態を目指してプラットフォームチームを作りました。
しかし、実際には多くのファシリテーションが必要であり、イネーブリングチームの役割に近いことを行っていると感じました。将来的にはX as a Serviceを提供できればと思っていますが、現状ではイネーブリングとX as a Serviceの両方の役割を担っているようなチームだと感じています。
大西氏：
チームトポロジーの書籍を読んだとき、初期段階ではプラットフォームチームがストリームアラインドチムに対しどのようなサービスを提供すべきかを理解するために多くのコラボレーションを行い、その後は、サービスを提供するだけの関係性になると書かれていました。
そのお手本通りの動き方をしているという認識で話を聞いておりました。
福井氏：
確かに、いきなりサービスを提供するだけの役割にするのは難しかったですね。段階を踏んで行けばよかったと、今は思います。
大西氏：
お二人ともありがとうございました。
ディスカッション
「チームだけを変えるのか?それともコードも変えるのか？」
大西氏：
チーム分割をしたときに、コードの分割も一緒に考えられると思います。今回チームを分割するにあたって、コードも変えましたか？まず小林さんはいかがでしょうか。
小林氏：
実態としてはチーム分割をする際に、コードは大きくは変えていません。
大西氏：
まず初めに、「チームを変えるだけなのか、それともコードも変えるのか？」という質問から始めたいと思います。チーム分割を行うとき、同時にコードの分割も考える場面が出てくると思うんです。今回のチーム分割に当たり、コードにも変更があったか、小林さんに伺いたいです。
小林氏：
チーム分割を行うときに、コード自体に大きな変更は加えていません。ただし、いわゆるコードオーナーの変更は行っており、これはテックリードが設定しています。また、コードオーダーを変更する際には、コードレビューを必ず担当チームに依頼しています。
また、コンプリケイテッド・サブシステムチームについては、X as a Serviceとして提供できるように、依存度を少しずつ切り離しているところです。
大西氏：
なるほど、ありがとうございます。この件について福井さんからも意見を聞いてみたいのですが、いかがですか？
福井氏：
コードの分割については、現在のところ、チームの編成に紐付けはしていません。将来的には、フィーチャーごとにパッケージを切ったり、モジュール分割を行いたいと考えています。
しかし、現時点では、適切なコンテキストの境界が見つけられていません。ですので、いったんは大きな機能開発に基づいて分けているだけですね。
特にモバイルはモジュラーモノリスのものなので、依存する箇所が多く、共通で使うものも多いので、その分割方法も今後検討する必要があります。
大西氏：
なるほど、iOSとAndroidの開発においては、例えば共通のライブラリのようなものを用いることで、フィーチャーチームがそれを呼び出すだけで基盤部分は書かずに上の層だけ書けば良いように作り変えようとしている感じですね。
福井氏：
その通りです。ただ、その状態にすると、プロジェクトが別れたり、ワークスペースが分離したりするため、開発が難しくなる可能性があります。それはトレードオフと言えるでしょう。
一部のAST（非構造のタイムライン周り）の機能については、フレームワーク化されてSDKで提供されています。これらはコンプリケイテッド・サブシステムチームが管理する可能性があります。それ以外の部分は、現時点では一つのモジュラーモノリスで作っています。
大西氏：
ありがとうございます。とても興味深い話でしたが、次のトピックに移ろうと思います。
チーム分割を考えるにあたっての判断軸は？
チーム分割を考える際の判断軸についてお聞きしたいです。何を基準にしてチームを分割する判断がなされましたか？福井さんからお願いします。
福井氏：
チーム体制については機能単位ではなく、機能開発をするチームと、その活動を支えるプラットフォームチームという分け方をしていました。このような分割により、認知負荷が高くなっている課題があり、その解消を目指してチーム分割を行いました。
大西氏：なるほど、認知負荷が高まっている課題を踏まえて、チーム分割を行ったのですね。小林さんの意見はどうでしょうか？
小林氏：私は、分割する際のキーポイントとして人数を重要視しています。また、目的整理が容易であることも非常に大切だと思っています。
今回のようにコンプリケイテッド・サブシステムやプラットフォームといった部分を課題として切り出す場合、目的整理が容易です。
一方で、例えばストリームアラインドを2つに分ける場合などは、顧客への提供方法などを考慮する必要があり、その部分は戦略的に難しいと感じています。
そしてもう一つ、分割されたチームが持続性を持つこと、つまり普遍性が高いことが重要だと考えています。短期間だけのプロジェクトチームを組むよりも、できるだけ普遍性が高い状態を維持できるという観点で考えたいと思っています。
大西氏：なるほど、ありがとうございます。それぞれのチームが目的を持てるかどうか、という観点も重要ですね。それは、スクラムを用いて違うスプリントゴールを追求するような運用になるのでしょうか？
小林氏：はい、その通りです。基本的には各チームが異なる目的を追求します。
そして、各チームがどのようなチームであり、1年後に何を達成したいのかという目的を整理してから活動を開始します。その目的をきちんと定めることが、チームを組み上げる上での前提だと考えています。
大西氏：
ありがとうございます。それでは次のディスカッションテーマに移りましょう。
チーム間の意思疎通がとれるように工夫していることは？
大西氏：
様々な目的に応じてチームを分割していく中、チーム間で意思疎通が必要なタイミングがあると思います。その際にどのような工夫をしているかというテーマなのですが、まずは小林さんからお願いできますでしょうか。
小林氏：
これは難しい問題です。理想は、そもそもチーム間での意思疎通の必要がなく、各チームが自己機能する状態を維持することだと考えています。
しかし、現実的にはそれが難しいため、弊社では技術スタック別の組織で認識を合わせることを重視していたり、スクラムオブスクラムで情報共有を行っています。
大西氏：
意思疎通が必要なくなることが、チーム分割の理想ということですよね。その上で意思疎通をしなければならない内容が出てくると。実際にどのような内容で意思疎通が必要になるのでしょうか。
小林氏：
たとえばコード単位で考えた場合、チームの目的が分かれているとしても、コンフリクトすることや、他のチームにコードレビューをしてもらう必要があるシーンなど、どうしても意思疎通が避けられないことがあります。そのような場合には、各種調整が必要となることがあります。
また、一つの案件を実行するにあたり、さまざまなチームの協力が必要となる場面もそれなりに出てきます。例えば、ストリームアラインドチームが取り組んでいる案件に対して、一部のコードが他のチーム作成したコードと重複してしまい、それが影響を及ぼす場合など、共同で案件の進め方を考える必要が出てくるため、連携するための意思疎通が必要になります。
大西氏：
なるほど、詳しく説明していただきありがとうございます。コードが重複する部分などは、レビューをしてもらうなどの意思疎通は必要ですよね。
次に福井さん、こちらのテーマについていかがでしょう？
福井氏：
Chatworkには複数のストリームアラインドチームが存在しています。複数のチームがiOSアプリの同時開発などを行うと、先ほども話に出たようなコンフリクトが発生します。このようなケースがいくつかあるため、チーム間で複数のiOSエンジニア同士が意思疎通の機会を持ちたいことは少なくありません。
そこで、弊社ではiOSギルドやAndroidギルドといった「ギルド」というコミュニティを設立しました。
職能別に分割したコミュニティである「ギルド」では毎週ミーティングを開催し、例えば、「ある特定の実装をどうすれば良いのか」「リリースが必要な時期がある」「コードレビューのどの部分を対象にすべきか」「新機能の実装を始めるので、コンフリクトを避けるために注意が必要」など、具体的な話し合いを行っています。
大西氏：なるほど、チームが分割されても、ギルドという形で職能によってグループを形成し、その中でナレッジを共有しているわけですね。
福井氏：はい、その通りです。これが必要になるのは間違いありません。
大西氏：ありがとうございます。それでは次のテーマに移りましょう。
チームトポロジーを活用したチーム分割の現在の課題、今後考えていることは？
大西氏：
現在抱えている課題や、これからの考え方について聞かせていただけますか？まずは福井さんからお願いします。
福井氏：
現在の課題としては、チーム分割をしてみたものの、イネーブリング的に動いている箇所が出てきていることと、プラットフォームチームのコストが高すぎるという問題があります。
例えば現在のところ、プラットフォームチームがリリース作業等を担当していますが、本来であればストリームアラインドチームが行うべき作業もあるわけです。それぞれの役割と責任を明確化し、その上で今後はストリームアラインドチームとプラットフォームチームが協業しながら開発生産性を向上させられるような最適化を模索していきたいと考えています。
大西氏：
難しい問題ですね。小林さんはどう思いますか？
小林氏：
現状の課題としては、1つのプロダクトに対するストリームアラインドチームの分け方が難しい点が挙げられます。プラットフォームやコンプリケイテッド・サブシステムは明確に分割できますが、ストリームアラインドチームの切り分けは困難です。
例えば、会社の戦略に合致しないと、案件が突然なくなるなどの問題もあります。これは理想的な状況ではなく、ユースケースに基づく明確な分け方が必要です。
切り分けがわかりにくい場合、チームの役割が理解されにくくなってしまいますし、認知負担が下がらないため、この問題への対応が難しいです。
大西氏：
なるほど、今注目されているのは、ストリームをどう分割するかという問題ですよね。DDDのような考え方もあると思いますが、ストリームの分割や設備については、何か特に注目しているポイントはありますか？
小林氏：
私が考えるに、最も重要なのは戦略の部分だと思います。なぜなら、ユーザーが求めている機能をどう実現するかという問題が重要だからです。いわゆる顧客への提供価値を基にチームを分けなければ、「このチームはどの方向を向いているのか」が分かりにくくなってしまうため、そこを最優先に合わせていく必要があると考えています。
大西氏：
なるほど、顧客に対する価値をベースに設備面を見極めていくわけですね。ありがとうございました。さて、時間も迫ってきましたので、ここでパネルディスカッションを終了させていただきたいと思います。
