チームトポロジー Vol. 2 「組織をチームトポロジーで振り返るメリット」タイミー 亀田 彗

チームトポロジーを組織に活用したいと考えている方に朗報です。株式会社タイミー　執行役員CTOの亀田さんがチームトポロジーを組織に適用して良かったこと、発生した課題、今後組織をスケールさせていく計画をタイミーの事例として紹介します。

今日は「組織をチームトポロジーで振り返ると、よりより未来が見えてくる」というお話をします。よろしくお願いします。

私は現在タイミーでCTOを務めておりますkameikeと申します。本名は亀田といいます。新卒でピクシブ株式会社にエンジニアとして入社して、様々なサービスの立ち上げや採用などにも携わっていました。

一時期、ピクシブでは新卒採用強化の一環でアントレプレナーシップ支援プログラムを実施していました。スタートアップに机を貸したり、メンタリングしたりしていて、私はメンターとして携わっていました。そこでタイミー創業者の小川くんに出会うのですが、意気投合して会社としての支援が終了した後も個人的に週1ペースで小川くんの手伝いをしていました。結果的にピクシブの採用強化の一環で始めたにも関わらず、ピクシブから引き抜かれてしまうオチでタイミーに入社しました。

最初はプロダクトマネージャー・CPOとして様々な業務に携わり、途中からよりエンジニアリングであったり、技術組織と向き合いたいということでCTOにロールチェンジして現在に至ります。

自己紹介として好きな本をスライドに載せているのですが、今回の主題である『TEAM TOPOLOGIES』や左下の『人が成長するとは、どういうことか』が好きです。

この二冊はいずれも日本能率協会マネジメントセンターさんから出ている本なので少し媚びてる感が強いですが、今回の企画の前から長らく自己紹介スライドに貼っているということはお伝えしておきます（笑）

経緯と思惑

今回のイベントの経緯と思惑についてお話します。

「タイミーの組織について多くのエンジニアさんに知ってもらいたい」とForkwellさんに相談したところイベント開催のご提案を頂き、企画がスタートしました。

その際にどういったイベントをやりたいですか？　と聞かれチームトポロジーにハマっていることをお伝えしたら、Forkwellさんから吉羽さんに登壇を打診して頂き、吉羽さんにもご快諾頂いて、今日を迎えることが出来ました。とても嬉しい気持ちでいっぱいです。

私は本当にチームトポロジーを推していて、もっと皆に布教していきたいのでこのイベントに際して50冊プレゼント企画を実施します。既に持っている方も多いと思いますが良い本は何冊あっても困らないと思うので布教用や上司の机にこっそり置いたりする用途でも是非プレゼント企画に応募頂ければ嬉しいです。

ちなみにこの50冊は既にオフィスに届いています。50冊本が積まれるとこんな感じになるんだな〜と思いながら眺めていました。壮観ですね。

今回のイベントは吉羽さんがお話された理論パートとこれから私がお話する実践パートという構成になっています。チームトポロジーを実際に組織に適用したら起こったことなどをお話する過程で副次的な効果としてタイミーの開発組織についても理解を深めてもらえれば嬉しいです。面白そうと思ったらカジュアル面談等の応募もお待ちしております！

チームトポロジーは共通言語

本題に戻ります。

僕はチームトポロジーを推していますが、何処に価値を感じているかというと共通言語としての役割に強い価値を感じています。吉羽さんの発表でもトポロジーが1枚の図になっていて、皆様にとっても分かりやすかったと思いますが、そういった分かりやすさの価値が非常に高いと思っています。

これは私たちもそう伝えてしまうのですがよくある話として「あなたの組織を説明してください」と言われると「立ち上げ期は自律的に開発ができていたのですが、組織のスケールで成長痛を感じてるんですよね」みたいな表現で伝えてしまいがちです。皆様は優しいので「あるあるですよね」とか「頑張ってますね」という言葉を掛けてくれます。

ただ、実はこれってそう言いつつも基本的には何も分かり合えてなくて、相互理解が全く進んでない状況なんですね。では、一方でソフトウェアについての会話ならどうなるでしょうか？

ソフトウェアなら僕たちエンジニアはこの様に会話しますよね。

「MVCで作っていたのですが、コントローラーが少し大きくなってしまったのでユースケース層を作ろうと思っているんですよ」

この様に伝えれば「テスタビリティ上がりそうでいいね」ってコメントがあったり「コントローラーが大きくなってしまったの？　モデルの方に逃がせなかったのかな？」とコメントをしてくれる人もいるでしょう。この様に共通言語を使うことで理解や対話を深めることが可能です。

チームトポロジーは組織に関する共通言語になります。組織論の話になるとCTOやVPoE、EM等の役職者やマネージャーに閉じた話に思われがちですが、僕はチームトポロジーは決してそういったものではないと考えています。

吉羽さんの発表の中でも「組織的センシング」の話がありましたが、日々のDevOpsの中で組織は様々な情報や変化に晒されており、それらの変化に対して対応していかなければいけません。

チームトポロジーが共通言語としての役割を果たすことでメンバー全員が組織に向き合える様になり変化に強い、良い組織になれることを僕は期待しています。

今回はタイミーの組織をチームトポロジーを用いて説明します。この説明を通じて、タイミーの組織への理解が深まれば、チームトポロジーが共通言語として強力であることを実感して貰えるはずです。

チームトポロジーの変遷

これがタイミーにおけるトポロジーの変遷のオーバービューです。早速これを用いてチームトポロジーに沿った説明をしたいのですが、タイミーの事業について前提知識がないと説明が難しい部分があります。

ですので、最初に私たちの時間軸や事業の前提となる会社・組織の話をします。その後に組織の振り返りをチームトポロジーで表現して、未来をチームトポロジーで考えるという構成で進めていきます。

前提となる事業や組織の取り組み

私たちは

「働く」を通じて人生の可能性を広げるインフラをつくる

というミッションを掲げてサービスを開発しています。特にアルバイト領域でアルバイト2.0と言える様な革新を産むべく挑戦しています。

サービスの仕組み

その一歩目となっているのがTimeeというスキマバイトアプリです。明日にでもすぐ働きたい人と急に人手が必要になった事業者を結ぶ、プラットフォームサービスです。

利用イメージ

タイミーのサービスでは2人のステークホルダーが登場します。

人を雇用する事業者と実際に働く人が登場するのですがタイミーでは事業者のことをクライアント、働く人のことをワーカーと呼称しています。

ワーカーの体験は皆様でもイメージし易いですね。アプリをダウンロードすると明日や明後日でも面接なしで入れる仕事が見つかります。暇な時に申し込みをして、現場に行って、アプリのQRコードを使って出退勤を行う。そしてお金が振り込まれる。暇な時にすぐ働けて、すぐお金が貰えるという分かり易い体験です。

一方のクライアント側は少しイメージが難しいのですが、アルバイト契約を結ぶのに必要な労務的なコストをサービス上で自動化して実質、労務コストゼロで人が雇えるという体験を提供しています。

実はアルバイト契約一つ結ぶのも大変なことが多く、働く前には労働条件通知書が必要だったり、場合によっては源泉徴収票の発行義務があったりその他様々な書類の管理が必要になります。これらのコストが掛からないことがクライアントからTimeeが支持されている理由の一つになっています。

サービスのステークホルダー

ワーカーとクライアントの他にもう1名ステークホルダーがいます。タイミーの社員です。ワーカーとクライアントが気持ちよくサービスを利用出来る様にカスタマーサクセス的な働きをしたり、請求等のオペレーションを回したりする役割を担っています。

インターフェースはクライアントと社員がWeb、ワーカーはモバイルアプリをiOS/Androidそれぞれネイティブで開発をしています。

サービスの成長変化

事業の時間軸のお話をするとサービスローンチから3.5年の会社です。所謂、スタートアップと呼べる急成長を遂げています。サービス初期比較で数千倍、YoYでも3.6倍の成長を遂げており今年も同様の成長を見込んでいます。

成長に伴い、サービスが拡大すると、どんどんコンテキストが変わってきます。今はそれに合わせたチームに進化が求められているフェーズです。

会社の変化

サービスの成長に伴い、会社も変化しました。

立ち上げ期は代表もまだ大学3年生で21歳、役員も全員、大学生で「とにかく頑張ります！」といった状況で1ヶ月先ぐらいまでのことで精一杯でした。それが最近では大手CEO経験者が役員として参画したり、累計の資金調達額も90億円を超え、サービスも会社も大きくなってきました。

この変化で個人的に嬉しいことがあります。最初は1ヶ月先とか長くても半年先を見据えて開発を行っていたのですが、最近は2年スパンや5年スパンで考えた経営判断が行われる様になりました。

ソフトウェア開発や組織開発で大きな取り組みを行うには少なくとも2年は必要なのでその時間軸と経営の時間軸がマッチしてきたのは良いことだなと感じています。

開発に携わる人の遷移

人の変化です。

社員は全体では300名くらい在籍していますが、エンジニアやプロダクトマネージャーといったプロダクト開発に携わる人員は25名くらいです。

2018年の最初期の開発チームは4名体制で未経験の学生とベテランの業務委託が2LDKのアパートで開発する学生ベンチャーらしい雰囲気でした。

幸いなことにサービスが成長した結果、2019年ぐらいから2-3年の開発経験のあるメンバーや、ベンチャーマインドの高いシニアエンジニアの入社が増えてきます。

2020年頃になるとシニアエンジニアの比率も増え、創業期は未経験だった学生も2年間で技術が習熟し大きな戦力になったことでチームとして出来る幅が広がってきます。またこの頃から給与の面でも業界標準的な金額を支払える様になってきました。

そして2021年にはEMを採用して、チーム体制の確立を図れる様にまでなりました。

技術スタックの遷移

それに伴う、技術の遷移です。

サーバーサイドはRailsで開発しており、ワーカーの方が利用するアプリはそれぞれネイティブで開発をしています。2020年頃に技術的な転換期を迎えて、SPA化が進んだり、2019年12月頃にTVCMを実施したタイミングでECS Fargateへの移行などを実行しました。

サービスの成長に伴って、技術的にも成長していると言えるのではないかなと思います。

組織の今までの振り返り

これらの前提の下、これまで起きてきたチームの変化や組織の在り様についてチームトポロジーを用いてお話していきたいと思います。

Phase1 ワンチームの時代

最初はPhase1、ワンチームの時代ですね。これについてはお話することは少ないです。

期間としては1年半ぐらいなのですが、Just Do Itなワンチームの状態で正直、チームと呼べるのかも怪しい、有機体の様な開発組織でした。

ただ、人が増えるにつれ、コミュニケーションが増えてきたのでバックログをきちんと管理するなどの開発プロセスが少しずつ整備されていきました。チームの拡大に伴って、課題が発生します。

サービスのステークホルダーと技術

Railsは全てに共通しているのですが、モバイルアプリはワーカーのみが影響範囲になっています。

その中でクライアント向けの開発や社員向けの開発比重が増えてきました。比率でいうと2:8ぐらいの割合になってしまいました。チーム内で話されている内容の8割がモバイルアプリの開発メンバーにとって関係ない状態です。

これは辛い、ということでチームを分割しようということになりました。

まずは技術軸でチームを切りました。節理面が技術の状態ですね。これはチームトポロジーを読むと分かるのですが、結構アンチパターンな切り方をしています。

Phase2 コンポーネントチームの時代

ここからPhase2のコンポーネントチームの時代が始まります。2019年の中頃から2020年の9月頃までが該当します。この時代の各チームをそれぞれチームトポロジーで説明します。

Phase2のチームトポロジー：Backend

ストリームの中心にいるのがRailsのバックエンド開発チームです。

Railsはバリューストリームに対して開発サイクルを回し易い特徴があります。クライアント向けの開発や社員向けの開発においてはチームで完結出来るので積極的にサイクルを回せる様になりました。

またチーム分割による増員の実現や節理面を技術にしたことで技術的な品質の向上も発生し、良い状態にありました。

Phase2のチームトポロジー：Mobile App

一方で辛かったのがモバイルアプリのチームです。

Swaggerで接続されていて、この場所に置かれているチームに対して適切な表現ではないと思いますがcomplicated sub-systemなチームになっています。技術が節理面となっている為、このチームでもBack-endのチーム同様、技術の習熟が進みました。

例えばViewアーキテクチャを刷新したり、マルチモジュール化を進めたり、パッケージ管理ソフトのアップグレードなどが達成されました。一方でバリューストリームに沿っていないのでモバイルアプリユーザーの課題フィードバックに対して対応出来ないといったことが発生しました。

ユーザーが困っていそうでもバックエンド側が忙しかったりすると対応が劣後する状況です。自分たちで早くて安定したデリバリーが出来ない状態になってしまい、サービスに対しての自立性が阻害されています。チームとしては目的がない状態になり、エンゲージメントもどんどん下がっていく辛い状況に陥ってしまいました。

Phase2のチームトポロジー：SRE

SREのチームはこの時期に立ち上がりました。

TVCMが始まる時期に合わせて、可用性を担保する為にコンテナ化を進めてFargateに移行したり、デプロイのパイプラインの整備を進めたりといったことに取り組んでいました。このチームも振り返るとcomplicated sub-systemなチームの要素が多いと思います。

オンコール対応やTV出演・CM等で発生するアクセスに対して事前に備えるアクションの責任が分散してしまいました。当時はチームトポロジーに出会う前で「当事者意識」や「プロ意識」といった精神論でなんとか乗り越えていった時代でした。今でこそトポロジーで振り返るとチームのインタラクションが悪かったよね、という反省があります。

Phase2のチームトポロジー：Data

最後にDataチームですね。結論から言うとこのチームは上手くいきました。

タイミーのプロダクション環境はAWS上にあるのですが、分析の為のデータをGCP側に転送してBigQueryに繋ぐことでモバイルアプリの行動データとjoin出来てより精緻な分析が出来る様になっています。チームとしては更にその上にデータポータルやLookerを乗せて、分析基盤を作り上げることに取り組んでいます。

このチームに関してはチーム間APIを規約的に設けることが出来ました。ReadonlyのDBで参照するであったり、指定のS3にデータを置いておけばデータ基盤に転送される等の規約を元にチーム間のインタラクションが設計されました。境界が明確化しその後、チームとしてもデータ転送のパイプラインを強化したりETLからELTという話でチーム内でSLOを設定したりするなど習熟が進みました。

これはコンウェイの法則がそのまま上手く働いた事例ではないかと思います。そもそもAWSとGCPの様に技術的な強い境界がある中にデータエンジニアがバリューストリームが完成している状態で関わることが出来たのが良い結果に繋がりました。この後もDREはバリューストリームに沿ってうまく回ったチームになったので以降の資料では省略しています。

DRE以外はバリューストリームに沿ったチームには程遠い状況でした。やはり1年ぐらい経過するとモバイルチームからは施策に制限がかかりすぎるという声が出てきて、サーバーサイドエンジニアチームからは可用性にも責任を持ちたいという声が上がっていました。そして僕は経営として組織をもっと自律的にしたい、と考えていました。

その時にチームの分け方を再考するべきではと考え探索を開始します。そして、顧客が重要だからステークホルダーでチームを切るのが良いのではないか、という仮説が生まれました。

当時の資料

当時の組織の資料です。

僕はその時点ではプロダクトマネージャーを務めていたのでステークホルダーとのコミュニケーションは僕が担っていて、その結果を開発チーム向けに変換して落とし込む体制でした。

この場合、どうしても真ん中に位置する僕がボトルネックと化してしまうのでステークホルダーとチームを直接くっつけることでチームで完結して小さい課題を解決していける体制に変更しました。

経営は大きい課題にフォーカスして考えたり、チームのパフォーマンス測定にリソースを割くことでよりスケールし易い体制にする狙いがありました。

Phase3 ステークホルダーのバリューストリームに沿ったチーム構成

節理面がステークホルダーになり、バリューストリームに沿ったチーム構成をコンセプトにPhase3に入ります。

これは2020年10月から2021年12月までのチーム運用です。2021年の12月までといっても現在（2021年3月16日）もチーム体制移行中につき一部残っているチーム体制となります。

当時のチーム構成

図にすると少し不穏な感じがしますが、クライアント側の体験を向上するクライアントチームとワーカー側の体験を向上するワーカーチームの定義でチームを運用していました。

例えば当時のチーム構成ですが、チームが自律的にそれぞれのステークホルダーに対して価値をデリバリー出来る様にする為、PdMやRailsエンジニア、デザイナーやアナリストといった幅広い職種のメンバーを抱える形で運用を始めました。この結果、チーム主導で課題回収から解決、運用まで回る様になりました。

例えば、ワーカー側では出退勤にまつわるUIの根本的な改善が実行されたり、クライアント側ではSPA移行やドメイン言語の張り替えなどが達成され、多くの価値を届けることができました。

経営の狙い通り、チームも自律的になりました。なので今後もステークホルダーを節理面としてチーム分割を進めていけば安心だと考えていました。

でも、本当に？

果たして本当にそうなのかを検証する為にも組織的センシングを意識してチームコミュニケーションの観察を行います。

起きたこと：クライアントに閉じた改修がワーカーチームのSLOに影響を与えた

観察していくと、クライアントに閉じた改修がワーカーチームのSLOに影響を与えてしまったという事態が発生していました。DevOps的に考えると由々しき事態です。

詳細をお伝えすると、クライアントチームが新機能をリリースする際、当該リリースがワーカー側が使う「検索」のパフォーマンスに影響を与えることが判明しました。なので、段階的にリリースを進めたのですが結果的にワーカーチーム側でSLO違反が発生してしまいました。

この影響でクライアントチームではパフォーマンスなどの懸念からリリーススケジュールの見直しが迫られ、ワーカーチーム側はSLO違反によるバックログの優先順位変更などがありました。

組織で起きていたことの解釈

これを個々に発生したトラブルの一つとして片付けることも可能なのですが、組織に何が起きていたかを考えると重要な運用領域をコラボレーションモードでケアしていたのではないか、という仮説が生まれました。吉羽さんの講演でもお話があった様にコラボレーションモードは認知負荷が増え、生産性が落ちるという特徴があります。

タイミーではワーカーとクライアントチームが協力しないといけない領域が多くあります。

例えば、出退勤の機能はワーカーの為でもあるし、クライアントの為にもあります。この体験を改善するには両方のことを知らないといけません。しかし、ワーカーチームとクライアントチームといったチームの切り方をしているので解決するにはコラボレーションを組むしかない状況になります。よって、DevOpsを進めるコストがこの領域において急速に肥大化し、品質の不安定化が発生します。

それを回避する為にコラボレーションを適切に行うとリリースサイクルが遅くなり、コミュニケーションコストも大きくなってしまいます。

色々おきました

その他にもスライドに書いてある様な様々なトラブルが発生しました。

色々なことが起きたのですが、これらは全てワーカーチーム、クライアントチームに跨る課題を全てコラボレーションモードで解決しようとしたことによる認知負荷の増大が原因でチームが上手く機能しなかったことが原因だと思っています。

チームトポロジーで未来を考える

こうした経験から節理面を変化させる必要性、チームの変化の必要性を感じる様になりました。ちなみにこのタイミングでチームトポロジーに出会っています。

そしてここからが未来の話です。チームトポロジーで未来を考える、Phase4に入ります。

Phase4 節理面を探して

チームトポロジーをベースとして逆コンウェイ戦略に則った節理面の探し方が良いと考えました。

事業としてありたい姿から逆算して組織を分割し、DevOpsを通じて、節理面の強化を実現したい。

では、適切な節理面は何かを色々と考えました。

節理面の評価

現時点ではマッチングまでとそれ以降で切るのが良いと考えています。

バリューチェーンの左側をマッチング領域、右側をスポットワークシステム領域と名付けているのですが、何故、節理面として適切と判断したかをお話をします。節理面を分ける際に大切にした問いがあります。

この4つの問いに対して適切に答えられるかどうかで判断しました。

個々に説明をします。まずはバリューストリームが事業成果に繋がるか？ですね。チームが自律的に開発して、自由に運用する形が事業成果に繋がっていれば非常に理想的です。なので、バリューストリームが事業成果に繋がる様に節理面を探そう、となります。

タイミーはマッチング領域とスポットワークシステム領域で切る判断をしました。

マッチング領域は正にここがビジネスの原動力になっており、サービスの根幹なので重要領域に定めました。ここを最適化し、稼働率を高めることは事業価値に繋がりますのでバリューストリームが事業価値に繋がっていると判断出来ます。

もう一つのスポットワークシステム領域ですが、タイミーのサービスは個人経営の飲食店から全国に多数の拠点を抱える物流大手みたいな上場企業まで広く利用頂いています。この幅広い業態・規模のクライアントから給与計算や労務管理といった責務をサービスに預けて頂いておりますので信頼性の担保は事業価値を損なわない為にも重要です。

それぞれ目指すものは異なりますが、目指す先が事業成果に繋がっていることが確認できました。

次は技術的な戦略と一致するか？ですね。

節理面でリスクや可用性の要求に変化があるか、技術的な方向性が変化するかどうか、という問いになります。

マッチング領域は試行回数の多さが重要になります。データ基盤とも接続して、データのフィードバックループの形成などが技術的にトライしたい事項です。

それに対してスポットワークシステム領域の出退勤は24時間365日、しっかりと動くことが重要です。労務管理に直結する部分で技術的な要求事項として可用性が外せません。給与計算等の労務管理そのものについては参照される頻度こそ低いものの「過去のデータを書き換えられない様にする」などの結果整合性が強く求められます。

トライアンドエラーの色合いが強いマッチング領域と可用性・信頼性が求められるスポットワークシステム領域ということで技術的にも境界があることが分かります。

次は再帰的に分割しうることです。規模が10倍になってもこの節理面が生き残っているかは節理面を考える上で重要です。

私が最初にステークホルダーを節理面とした際、チームの間に出退勤領域などが溢れてしまう予測はしていました。しかし、その時点では間にチームを置けばなんとかなるぐらいの認識でした。

ただ、実際にやってみて節理面の隙間で何かをすることは難しいと痛感しました。なので、一度切った節理面はスケール後も保持して問題ないか、チームとして継続的に正しく成熟していくかを確認しました。

チェックポイントは認知負荷や技術的な要求です。例えば認知負荷だと、領域によって求められる知識は異なりますが仮にチームがスケールしても更にその中で認知負荷を分散させる為にチームを分けることは可能と考え、この節理面で問題ないと評価しました。

最後に認知負荷の軽減です。折角、チームを切ったのにDevは切れてたけどOpsで認知負荷が繋がっているといったことでは勿体ないので切ったボリュームに応じて認知負荷が分割される見通しが立っているのかを確認しました。

例えばタイミーは事業的に労働基準法等、守らないといけない法律が多くあります。これらの法律はあくまでもマッチング後に実際に働く際に必要なものなのでこの節理面であればマッチング領域側にとってそれらの知識は不要になります。

逆にマーケティング的な視点やレコメンドエンジン的なものの開発等に関する知識はスポットワークシステム側には関係のないものです。知識的な境界が正しく設けられ、認知負荷の軽減に繋がっていることが分かるのでやはりこの節理面で大丈夫そう、ということが確認出来ました。

これからの想定

節理面は問題なさそう、というところでこれからの想定です。

吉羽さんの基調講演でもありましたがチームの移行は徐々に行うことが大事です。このプラクティスに則ってタイミーもチームの移行をする予定です。現在あるクライアント&アドミンチームとワーカーチームはそれぞれ徐々にスポットワークシステムチームとマッチングチームに変換していきます。

加えて、バリューストリームに沿ったチームは認知負荷が高まりがちなのでその認知負荷を軽減出来る様なプラットフォームチームの組成も行っていきます。具体的にはSREをプラットフォームチーム化してX-as-a-Serviceモードで利用出来る様にしたり、QAについてイネイブリングするチームなどを考えています。

チーム数については3チームに限定する訳ではなく、インタラクションの中で再帰的に節理面の探索を進められれば良いと考えています。この様に理想に向かって、組織センシングを行いながら、探索を続けていくつもりです。

タイミーの組織に関して伝わったでしょうか？

「この課題は明確だね」「こういうアプローチはなかったのかな？」という話が出来るのであればそれこそがチームトポロジーが共通言語として機能した結果だと思います。そして、冒頭にも申し上げた通り、それがチームトポロジーの良さだと思っています。

本日はありがとうございました！

---