[12/2開催]チームトポロジーをヒントに組織設計を考える
2022年12月2日に開催されたCTO meetupのテーマは、「チームトポロジーをヒントに組織設計を考える」です。チームトポロジーは、価値あるソフトウェアを素早く安定的にデリバリーするためのアプローチとして注目されていますが、実際の組織ではどのように運用されているのでしょうか。
今回はチームトポロジーをの考えを取り入れてチーム運営をしている株式会社タイミー 執行役員 CTO 亀田さん、株式会社ビビッドガーデン 執行役員CTO 西尾さんの2名にご登壇いただき、チームの立ち上げ・運用時にどのような観点があるのかディスカッションしていただきました。ディスカッション後の質疑応答も全て掲載しておりますので、ぜひご覧ください。
目次
チームトポロジーとは | チームトポロジーに入る前に
そもそもチームトポロジーとは何か
亀田氏：
まずは、チームトポロジーについて解説させていただきます。チームトポロジーとは、チームのあるべき姿を何らかの図形やトポロジーで表したものです。ソフトウェアを開発する上では人を増やす必要がありますが、人を増やせば生産性が上がるわけではありません。限られた人数の中で価値あるものを安定的にデリバリーすべきなのかを突き詰めると、「チームはどうあるべきか」にたどり着きます。そのパターンを示したのが、チームトポロジーです。
例えば人が増えていくと、コミュニケーションパスが増え組み合わせ爆発が起こりますから、何かしらの方法でパスを制限しなければなりません。
亀田氏：
また、Web・アプリいずれにおいても、ソフトウェア開発は複雑化しています。その中にはさまざまなステークホルダーが混ざっています。タイミーとビビッドガーデンの場合はプラットフォームを運営しているので、バリューチェーンも多様です。
ビジネスドメインだけでも複雑なのに、さらに開発プロセスやテスト、監視などが関わるとチームが認識しなければいけないことが増えていきます。これをチームトポロジーでは「認知負荷」と呼んでいます。
亀田氏：
開発組織を立ち上げたばかりなら、全メンバーがオールマイティーに全体を認識しながら勢いよくソフトウェア開発をするのが通常ですが、人が増えるとこの複雑さにどう向き合うべきなのか、問題が発生します。そこに関して、コンウェイの法則に基づいた「逆コンウェイ戦略」を採り、チームにアプローチしていくのがチームトポロジーの考え方です。
理想的なアーキテクチャにするためにチームを組み、自分たちがビジネス上で提供したい形にアーキテクチャを寄せていく戦略を考えていくわけです。
4つのチームタイプと3つのインタラクションモード
亀田氏：
チームトポロジーには、4つのチームタイプと3つのインタラクションモードというものがあります。
まず、チームトポロジーのコアになるのが「ストリームアラインドチーム」です。バリューストリームに沿った形で価値を安定して届けるため、企画から設計、リリース、検査に至るまで全てを成し遂げられる権限や能力を持つのが、ストリームアラインドチームの定義です。
亀田氏：
とはいえ、安定して顧客価値を届けるためにストリームアラインドチームを大量に作ればいいかというと、そうではありません。一つのシステムに向き合うチームが複数存在すると、やはり複雑性が持ち込まれますから、そこを解決して支えるためにさらに3つのチームの在り方が存在します。
亀田氏：
一つが、コンプリケイティッド・サブシステムチーム。例えば動画配信のアプリを開発する上で必要なストリーミングやレコメンドなど、複雑な技術を担うチームです。
プラットフォームチームは、ストリームアラインドチームに対して何かしらの機能や価値を、APIなどのシステムを介して提供する役割を持ちます。イネーブリングチームは、開発プロセスの中で高めていくべき専門知識をインストールするためのチームです。
ストリームアラインドチームを横軸として、3つのチームがクロスしたりつながったりする形で関わります。このとき、各々がどういう「モード」でコミュニケーションを取るのかを定義しているのが、インタラクションモードという概念です。
亀田氏：
多くの方にとって馴染み深いモードは、コラボレーションです。お互いに依存関係を持ちながら一緒にプロジェクトに取り組みます。
もう一つがファシリテーションです。チームに教え、体感してもらう形で知識習得を支援する関わり方です。例えば輪読会や勉強会、モブプロなどが該当します。
最後がX-as-a-Serviceです。APIやSDKなど、何かしらのインターフェースを経由して利用できるようなプロセスや手続き、価値を提供する関わり方を指します。これらの概念を組み合わせて理想のサービスや良いチームを目指すのが、チームトポロジーです。
チームトポロジーをヒントに組織設計を考える
チームトポロジーに着目したきっかけと目指す姿：食べチョク
亀田氏：
では次に、私たちがどのようにチームについて考えているかをお伝えしていきます。西尾さんにお伺いしますが、まずは、チームトポロジーに着目したきっかけについて伺っても良いでしょうか？
西尾氏：
我々はスタートアップ企業で、2020年頃までエンジニアは数名しかいませんでした。今は20～30名規模になっています。もともとは1チームで運用しており、1人1施策を持つ形でしたが、2020年頃にサービスが急成長し、一気に開発者を増やす流れになったんです。そこでチームを分割することになり、チームトポロジーに着目しました。
スタートアップなので開発は素早いサイクルで回したかったのですが、チームを分割すると作業の受け渡しが発生して、どうしてもスピードが落ちてしまいます。人が増えても施策のデリバリーはなるべく1チームで完結させたほうがスピードは出るのではと思い、ストリームアラインドチームを導入しました。
食べチョクのサービス概要とチーム体制
亀田氏：
具体的にビビッドガーデンさんはどういうサービスを運営しており、どんなチーム分けになったのでしょうか？
西尾氏：
ビビッドガーデンは「食べチョク」というサービスを運営しています。ビビッドガーデン自体は主に農業や農家など一次産業の課題解決を目指す会社で、食べチョクは農家の方々がこだわって作った良い農作物を、適正価格で出品できるサービスとして立ち上げました。仕組みはいわゆる普通のECサイトです。生産者が商品を出品登録し、ユーザーが商品を探して注文します。
チームは、「商品提示」と「注文/配送/決済」という、注文の前後で切れると考えました。
西尾氏：
「定期便」が別チームになっているのは、いわゆる一般的な定期便とは異なるサービスだからです。お客様が好みの野菜に関する情報を入力したら、運営側がおすすめ農家を提案するコンシェルジュサービスがあり、当社ではそれを定期便と呼んでいます。
検索やレコメンドといった専門性が求められるシステムは、コンプリケイティッド・サブシステムチームとして切り出しました。そのチームが開発したシステムやAPIを、商品提示チームが使う形にしています。
亀田氏：
理想的なコンプリケイティッド・サブシステムチームですね。定期便が配送部分に接続されるなど、インタラクションはあるのでしょうか？
西尾氏：
そうですね、配送は同じ仕組みを使っています。
最後の「会社基盤/マーケティング/カスタマーサポート」のチームが難しくて、どちらかというと「残ったことをやる」チームになってしまっています。ミッションが多く認知負荷もかなり高いので、もう少し分けたいところです。
「インフラ」は、プロダクトチームがインフラを意識せずに使えるようにするためのプラットフォームチームです。そのほかには、モバイル関連やBI、イネーブリングチームも用意しています。デザインチームは、会社の性質上紙のデザインが必要なため、切り出しています。
チームトポロジーに着目したきっかけと目指す姿：タイミー
亀田氏：
タイミーとチームトポロジーの出会いについてもお話しさせていただきます。フェーズや規模感は食べチョクさんと似ていて、ちょうど20数名規模の頃にチームトポロジーを知りました。
当時タイミーは職能別にチームを分けていたため、1つの機能開発を行う際に2つのチームのコラボレーションが必要になること、マッチングプラットフォームの開発チームとして上手く価値創造ができていないことが課題でした。チームトポロジーを通して、1つのチームができる限り自立し、権限や裁量、アイデアを基にものづくりをする状況が作れればと思っていましたね。
タイミーのサービス概要とチーム体制
亀田氏：
タイミーは、空いた時間を使ってすぐに働けるスキマバイトアプリです。働き手から見るとアルバイト契約を結べるので安心安全に働けますし、働いた後はすぐに報酬を受け取れます。雇い手から見ると、困ったときにすぐに人材を集められて、縁があれば長期採用にもつなげられます。
人を雇用するとシフト管理や源泉徴収票、労働条件通知書の作成など労務コストも大きくなりますが、それらも全てタイミーのシステムが肩代わりしています。マッチングから出退勤、振込、請求書発行、労務管理までが一つのプロダクトで、バリューチェーンが長いのが特徴です。
チームは、働くまでの「マッチング領域」と、働いた後の「スポットワークシステム領域」という大きな2つのラインで分割されています。現在は、この領域の中にストリームアラインドチームが5ラインある形でものづくりをしています。
亀田氏：
マッチング領域の中には、マッチングに関してレコメンドやマーケティングをするためのツール提供を行うmarketing_enhanceチーム、ニーズに応じた案件の出稿をなめらかにするon-demand_employmentチーム、働き手と雇い手の良い関係値を作るworking_relationチームがあります。
スポットワークシステム領域の中には、なめらかな退勤や給与、請求、労務管理を行う縁の下の力持ち的なsmooth_opsチーム、タイミーのユーザーがアカウントを使い始めるまでに必要なバックエンドの手続きを自動化し、アカウント開設から即日でサービスを使えるようにすることを目指すzero_day_activationチームがあります。
これらのチームを支えるのが、開発プラットフォームチームです。デプロイのパイプラインやインフラの責任境界を上手く設計しながら、開発チームを支援しています。
チームを立ち上げる際の観点
事業価値との接続
亀田氏：
続いて、具体的にチームの立ち上げや運用についてディスカッションしたいと思います。
まず、ストリームアラインドチームを考えるときに何をストリームとして置くかは大事だと思うのですが、食べチョクさんはどのような視点でチームを切っていったのでしょうか？
西尾氏：
最初は注文前後で2チームに分けました。会社のKPIは購入率で追っていますし、注文・配送・決済はそもそも複雑なシステムなので、そこで分けられると考えたからです。
そこから定期便を切り分けたのは、実は最近です。会社のミッションとして定期便に注力したいと考え、価値を出すためにチームを切り出すことになりました。
亀田氏：
定期便が会社のミッションとして大事な要素だから、チームで切ってストリームを守ったイメージですね。もともとあるプロダクトの中で物理面を跨いで何かを考えたいときは、コラボレーションや別チームの立ち上げが必要だとすごく思います。
タイミーも以前は「ワーカー」と「クライアント」のような分け方をしていましたが、コラボレーションだと何も進まないフラストレーションを抱えていました。現在の切り方にしたからこそ、会社として目指したいことを目指しやすくなった部分があります。
認知負荷
亀田氏：
認知負荷というテーマもあると思います。プロダクトが持つEC部分から配送までの複雑さは、一人の専門性だけでは太刀打ちできません。そこで、タイミーはマッチングまでとマッチング後のプロセスで切りました。前半はABテストを回しながら進めますし、後半は可用性や整合性の議論になるため、専門性や採用の要件も変わります。チームを切っている場所の近さは、食べチョクさんに共感しましたね。
注文や配送、決済はデプロイ周りのプロセスも結構違うのではないかと思いますが、そのあたりはいかがですか？
西尾氏：
我々はモノリシックなアプリケーションなので、デプロイはみんな一緒にやっています。自分たちのチームの中で開発をしてコードレビューまで終えたら、チーム内の専用環境でテストを実施し、OKだったらプルリクエストをマージしてE2E環境に回し、デプロイは1日に2回一斉に行う形です。
亀田氏：
タイミーも似たような感じです。ただ、マッチング領域はアクセス負荷が高いんですよね。テレビCMを打つとスパイクされたりするので、デプロイのプロセスやその後の監視でメトリクス部分を重視して見ています。一方スポットワークシステム領域は結果や整合性重視なので、デプロイした機能が何かしらの計算をした後でチェックをして、問題がないかを見ています。
何に対しても、品質を上げていく部分ではチームの切れ目がいいと「いい感じ」になっていきますよね。
西尾氏：
ですね。整合性のチェックは我々も1日1回実施しています。
将来の人数拡大への備え
亀田氏：
チームを切っていくプロセスは人を増やしているからこそ起きる現象だと思います。組織拡大のタイミングで仕込んでいることや、着想していることはありますか？
西尾氏：
我々のよくない部分は、複数のミッションを持っているチームがあることです。
マーケティングは新規獲得で成果を出す必要がありますし、カスタマーサポートは購買後の顧客体験を向上して継続率や定着率に効果を出さなければいけませんが、人数が足りないので今は同じチームで異なるミッションを持ってしまっています。ここは将来的に分割できそうだなと。また、現在3～4名規模のチームはもう少し人数が増えても良さそうです。
亀田氏：
タイミーも似ています。例えば労務管理の部分はチームを切れば利益率や顧客体験に良い影響が出ると思うのですが、人材が足りていないのが課題です。
プラットフォーム開発も、テーマとしては重くなっています。チームが増えてきたので今は1日5回ほどデプロイしているものの、10チームに増えたときにこのまま維持できるかはわかりません。全チームがプロセスとしてうまく利用できるようなデプロイのパイプラインやステージング環境を作っていくのが、人員拡大におけるテーマだと考えています。
チームの運用時の観点
コラボレーションの捉え方
亀田氏：
次は、運用観点について話したいと思います。実際にコラボレーションが起きた際は組織的にどんな議論が起きて、どのような向き合い方をしていますか？
西尾氏：
コラボレーションは大体1チームごとに行うのですが、我々は最大3チームとコラボレーションしました。スクラムのイベントも一緒にやります。単純に人数が増えることによってスプリントレビューがものすごい量になってしまい、スピードは速いものの、運用は難しかったです。
亀田氏：
コラボレーションはやはりコストが高いですよね。食べチョクさんの場合はファシリテーションを行うイネーブリングチームがあるそうですが、どんなチームなんですか？
西尾氏：
我々は最近JavaScriptから、TypeScriptに移行しました。今後どのようにサービスを作っていけばいいのか、イネーブリングチームがライブラリの使い方の勉強会を開いたりして、ほかのチームに教えています。また、当社にはQAエンジニアが1名いて、その人がテストの仕方自体を、ほかのチームのメンバーに教えています。
あくまで「こういうやり方ができるから、あとはチームで頑張って」と教示するのが、ファシリテーションの動きだと認識して取り組んでいますね。
亀田氏：
新しい技術スタックを全ストリームアラインドチームにインストールする場面では、イネーブリングチームがすごく役立ちそうですね。
特定職種のリソース過不足
亀田氏：
次のテーマは、リソース不足についてです。チームの中にどうしてもリソース不足の業種は出てきますが、どう上手く回しているのでしょうか？
西尾氏：
上手くは回せていないですね（笑）。当社はアプリエンジニアが少なく、それぞれのストリームアラインドチームにメンバーを配置できていません。モバイルチームに切り出して、時期によって商品提示チームとコラボレーションしているため、認知負荷が高いと思います。注文のほうはWebViewにしているので、あまりコラボレーションすることはありませんが……。
亀田氏：
WebViewにするのは、課題解決の良いアイデアかもしれません。注文、配送、決済はWebエンジニアがいればある程度解決できるということなので、小さな1チームを構成できる気がします。
タイミーはチームトポロジーを導入する以前に職種でチームを切っていた名残で、どうしてもチームの職種が偏り、コラボレーションが発生していましたね。最近やっと全領域にアプリエンジニアを配置できる体制になってきました。
技術的負債の継続的解消
亀田氏：
最後のトピックは、技術的負債の継続的解消についてです。ストリームアラインドチームは顧客に素早く価値提供できるチームである一方、技術的負債はどんどん溜まっていきます。ストリームアラインドチームはここに向き合うのがすごく苦手だと思っているのですが、どうされていますか？
西尾氏：
ストリームアラインドチームが自分たちで技術改善できるのがベストなのですが、どうしてもミッションやKPIの達成を重視して、技術的負債の解消は後回しになってしまいます。
そこで、技術改善のような部分はストリームアラインドチームとは全く別の軸で切りました。例えば我々はいつかモノリスのアーキテクチャから脱却しなければいけませんが、そのためにテストのカバレッジを上げて品質向上をしようと専用チームを組んでいます。あとは、サイトのパフォーマンスを全体的に高めるためのチームも運用中です。
亀田氏：
ストリームアラインドチームのみでの取り組みに限界がくる要素として、モノリスかどうかはすごく影響しますよね。例えばRubyのバージョンを上げるとなると、自分のストリーム以外のチームにも影響が出ます。別のチームでも何かしらの品質検査はやっているはずですが、協力を仰がないとバージョンアップができないという問題が起きがちです。当社は別の会議体やチームを組成してプロジェクト管理を行い、今は無事Ruby3.1になりました。モノリスだと、共通部分へのアプローチが弱くなってしまう例ですね。
西尾氏：
技術的負債は直すのが大変で、下手したら半年以上もかかります。そうなると、やはり別でチームを切ることになりますね。
Q&A
組織と各チームのゴールを上手く優先順位付けするには？
組織のゴールと優先事項に対して、各チームとのゴール・優先順位との同期はどうするのでしょうか？（LeSSの全体バックログのようなものをどう使う？）
西尾氏：
当社はプロダクトのロードマップを考える時点で、チームミッションについて考えているかもしれません。あまり困ったことはありませんね。
亀田氏：
タイミーの場合は、会社の優先順位とチームのゴールはトレードオフだと思っています。組織の優先順位が高い事項を順番にやりたいのなら、全部プロジェクトベースで動かすのが速いのでしょうが、そうなるとチームのゴールがマイクロマネジメント寄りになってきます。
西尾氏：
全部プロジェクトにするのは厳しいですよね。
亀田氏：
プロジェクトが綺麗に定義されていて、なおかつ顧客課題に寄り添っていれば成り立つはずですが、それはウォーターフォール的な開発方法になってきます。結局プロジェクトをチームに対して分けていき、組織が干渉しなくてもチームが顧客解像度を高く持ってものづくりができる状態が始まるのではないでしょうか。
何をどう作るかはある程度チームに委ねながら、組織の行きたい方向を調整するアプローチに変わっていくはずです。食べチョクさんが定期便のチームを作った話は、まさしくそれですよね。
西尾氏：
そうですね。組織として次は定期便に注力することになりましたが、商品提示チームの中で同じ優先度の開発を両方同時にやるのは無理でした。きちんと追っていくなら、チームを切ろうと。
亀田氏：
全体のバックログはあるんですか？
西尾氏：
一応統一したバックログはありますが、そこから各ユニットに送る感じにしています。
メンバーがチームを兼任する場合に認知負荷を下げるには？
ミッションごとにストリームアラインドチームとして切っているが、構成するメンバーが兼任しているといった状態は生まれてしまうものでしょうか？また生まれてしまった場合、兼任者の認知負荷が高まると思うのですが、どのように下げたりするのでしょうか？
西尾氏：
当社の場合、アプリエンジニアとデザイナーはそもそも人数が少ないので、兼任は生まれてしまいます。ただ、なるべくストリームアラインドチームの兼任は出ないようにしています。ミーティングに出るだけでも精一杯になってしまいますし。
亀田氏：
認知負荷を下げる方法はある気がします。例えばチケットにしっかり文章を書いて、それを読み込めば理解ができるような状態を作るなどですね。ただ、書く側も大変で作る側も受託的になってしまい、モチベーションは下がりそうです。
西尾氏：
当社はプロダクトオーナーやプロダクトマネージャーが少なく、エンジニアが要件から考えるスタイルなので、使えないテクニックかもしれません。
亀田氏：
認知負荷を下げることとチームのオーナーシップを持つことは、ある程度トレードオフになります。なんとか兼任を外せるよう、バックログ管理を頑張る方法はあるのかもしれません。
チーム形成の成功度を測る組織センシングのポイントとは？
プロダクトのデリバリーはFour keysで測るとして、チーム（マイクロサービス）構造がうまく形成されているか測る指標はあるのでしょうか。（Team Cognitive Load Assessmentなどを行う？）
西尾氏：
Four keysは使われていますか？
亀田氏：
まだしっかりとした運用はできていませんが、結果を見るために使っています。これぐらいの頻度でデプロイできているからOK、障害が少ないからOK程度の解像度です。
西尾氏：
当社も同じような感じです。チームが上手く形成されているか測る指標はあるのでしょうか？
亀田氏：
チームトポロジーでは、組織センシングの話がいくつかありますね。良いミッションを持てているか、チーム内外のコミュニケーションがどれぐらい合っているのかを見ると、ヒントになるのではないでしょうか。
Spotifyでは、エンジニアリングマネージャーやアジャイルコーチが、チーム間のコミュニケーションの依存関係を全部表にまとめているそうです。ブロッキングしている・していないなどを全部整理して、重たいところから解決していくらしく、安定して速いストリームを作る上で寄与しそうだと思いました。
プロダクトチーム外のステークホルダーとのコミュニケーション管理の手法は？
チーム外のステークホルダーのコミュニケーションの依存性は、どのように管理されるのでしょうか？（オニオン図のようなもので別途考える？）
西尾氏：
大前提として、当社のプロダクトチームはチームトポロジーで考えていますが、会社全体はそうではありません。マーケティングやカスタマーサポート、生産者チームが別に存在しています。
例えばストリームアラインドチームがマーケティングチームとやり取りする場合、何かあったら相談すべきところは定義していますが、そのぐらいです。
亀田氏：
タイミーもここはあまり管理されていません。プロダクトマネージャーの方々に良きように運用していただいています。あとはスクラムマスターにも上手く支援してもらっていますね。
チーム構造のリアーキテクチャが発生するきっかけとは？
チーム構造（マイクロサービス単位）をリアーキテクチャする場合は、どのようなことを契機にしてどのように進めますか？
亀田氏：
メンバーが増えるとチームの構造が変わるので、採用を頑張るとリアーキテクチャが進んだりしますね。
西尾氏：
我々はマーケティングのツールやLPをリリースする際、別のシステムに切り出しました。マーケティングとはデプロイのサイクルが違うからです。マーケティングサイドが「今日の12時に出したい」と言っても、こちらはまだテストが終わっていないから待ってほしいといった状況が頻繁に起こってしまったので、個別にデプロイできるようにしました。
各社が今後目指すアーキテクチャやチーム構成の展望とは？
チームメンバーが増えた上でデプロイが全体でしかできないと、ステージング環境での確認などに時間がかかりそうだと思います。その点でアーキテクチャやチーム構成を変えていきたいなどの展望はありますか？
亀田氏：
タイミーのマイクロサービス化はだいぶ先だと思います。一つの大きなシステムがきちんと動いている状況を守っていく方向性なので、モジュラーモノリス化を予定しています。
ただ、何かしら工夫をしないと10チームがデプロイし続ける状況は継続できません。チームごとにステージング環境が出せるような状態を目指して、開発プラットフォームのメンバーと議論中です。
西尾氏：
我々の場合はプルリクエストを投げると専用の環境が立ち上がるので、そこでテストをしています。最後はステージング環境に上げて本番デプロイする形で時間がかかりますから、もう少しレビュー環境を上手く使いたいとは思っています。
亀田氏：
本日のCTOmeetupは以上です。ありがとうございました！
（番外編）当日取り上げられなかった質問と回答を一挙公開！
Spotifyの組織作りの考えも今後部分適用することはあるのか？
EMやPdMを組織化する(Squad組織のドライブ？の概念)みたいな世界観は成長の先にありえたりするのでしょうか？
亀田氏：
弊社では、PdMの組織化が進んでいます。人数が増えるに応じて専門性の強い人と一緒に働くことができるようになっていくなと感じています。
西尾氏：
弊社ではEM/PdMともに数が少ないので未検討ではありますが、もしメンバーが増えたらストリームアラインドチームなどチームトポロジーの概念とは別でチームを作ることはあり得るとは思います。
チームトポロジーと評価/目標設定との関連
目標設定や評価制度とチームトポロジーが関係している部分はありますか？
亀田氏：
弊社だと、チームでミッションや目標数値を保つようにしていますが、それとは別に個人の目標を保つようにしています。
チームの目標はチームトポロジーが直接関係する箇所になります。個人の目標は「チームの目標を達成する過程」において個人の技術力をいかに成長させるか？ということに主眼が置かれており、直接チームトポロジーと関係はない状態になっています。
西尾氏：
チームごとにミッションを持っており、所属するメンバーの個人目標設定はチームミッションと重なるところがあります。ただ、弊社では今のところ評価制度とチームトポロジーは切り離して考えています。
チームトポロジーで定義したチームとは別に組織図上の所属があり、評価は組織図の所属ごとに行っております。
まとめ
チームトポロジーの考えをもとに組織/チーム運営をしているタイミー様、ビビッドガーデン様の事例はいかがでしたか。
どのスタートアップ組織でもエンジニア数の増加に伴って、チーム設計を考えるタイミングが必ずきます。
今回取り上げたチームトポロジーも1つのヒントにしながら、チーム立ち上げやチーム運用時に意識するポイントについても是非参考にしてみてください。
