どうも、大曲です。仕事で使うディスプレイを4kの27インチから4kの32インチに変更しました。

今回は、チームトポロジーの読書会をやっていて新しい組織改善で活用できそうだなと感じた部分があったので書きました。

伝えたいこと

プロダクト開発でペルソナ策定やデータ分析の高度化に伴い、開発組織が扱う課題が変わってきた
- 大きな組織改善から2年近く経ったため、そろそろまた大きな改善しないといけなそう
チームトポロジーの活用の余地がありそうな部分をまとめてみた
- チームトポロジーの基本的な説明はせずに組織の課題を多めに書く

組織の簡単な説明

組織の前提情報

開発人数（30名）に対して扱うサービス（5~8）が多い
- JANet,Smart-C,AppDriver,Oct-pass...etc
- 全てのサービスで常に開発をしているわけではない
ビジネスの状況によって、サービスごとで開発優先度が異なるタイミングがある
- 前期はJANetが最注力だったが、今期はSmart-Cに注力したい..etc
オンプレからクラウドへの移行作業を実施中
- 20年近くの歴史があるため古いアーキテクチャの改善も実施する必要がある
開発組織として、事業貢献を目指している
- アドウェイズ技術部門・エンジニアリング領域が進める、新しい価値創造について

役割説明

役割名	説明
GM（ジェネラルマネージャー）VGM（バイスジェネラルマネージャー）	開発組織全般（3~4チーム）のエンジニアリングマネージャー
UM（ユニットマネージャー）	1チーム（4~7名）のエンジアリングマネージャースクラムマスターであり、ピープルマネジメントの責任を持つ
テクニカルマネージャー	組織的な課題に対して技術力を活用して解決する事業・サービス貢献を伴う組織の開発プロセス改善やメンバーの技術力向上の責任を持つ
PdM（プロダクトマネージャー）	事業責任者と連携し、プロダクトの方針を明確化するプロダクトで何を作るかを決定し、プロダクトの成長に責任を持つスクラムではPO（プロダクトオーナー）に該当する役割になる
PL（プロジェクトリーダー）	ステークホルダーと連携を取りながら、無理なく遅延なく開発案件の仮説検証の達成に責任を持つ
テックリード	開発要件の企画から携わり、要件定義を行い、機能要求を満たすシステムアーキテクチャの設計・開発を行うまた開発、運用をより良くするための開発プロセスの継続的改善を行う責任がある

テックリードの詳細はこちら

PLが行う具体的なことはこちら

組織としての変化

時系列での変化を少しでも理解してもらうために図を作成しました。

組織改善前（2018/08~）

サービスごとにリソースが固定化されており、各チームで新機能開発と技術改善のバランス判断を迫られていました。どこまで新機能を開発するのか、どこまで改善するのかのバランスをチームの半期目標設計で考える必要があり、目標が決まるまでに3週間かかったチームもありました。（1日合宿を3回くらいやったりして大変でした）

開発案件の要望をPdMから、組織の解決（スクラム）をVGMからチームのエンジニアリングマネージャーであるUMが受け止めていました。開発内容の難易度が高かったりする場合などは、UMがかなり大変です。また後継者を育てようにもスーパーマンでないといけない状況がありました。このとき自分が複数サービスを担当する10名規模チームのUMでしたが、技術的な判断からビジネス的な要件判断（仮説検証をどうするか）を全てやってましたので大変でした。

組織改善後（2020/08~）

「ビジネス状況に応じて柔軟に対応したい」と「技術改善に集中したい」の2点を考えたときにサービスごとのリソース固定をやめて人材の流動性を高めたいと考えました。そのため、サービスの案件ごとや技術改善ごとでチームを編成して、チームの役割をシンプルにしました。また、各分野（スクラム、開発ルール）で各チームごとの横軸でのつながりが増えていたので組織として文化の統一に向けて動き、メンバーを入れ替えても影響が少なくなる取り組みを行いました。

UMがスーパーマンでないといけない状態を無くすために、UMをスクラムマスターに専念してもらい、PLの役割を立ててビジネス的な要件をPdMと整理したり、仮説検証を遂行する責任を持たせました。マネジメントとしてのビジネス側のコミニケーションはUMがサポートするのでPLはより技術的な判断などに注力できることで、タスク管理や調整が苦手なエンジニアでもやり易いようにしました。

この当時のチーム毎の目標はこちらです。

現在（2022/08~）

まず、PdMに特化した役割がなくなりました。 PdMは自分も含めて3名ほどいましたが、そもそもエンジニア側と営業側で兼務しているメンバーだらけで、組織改善後は自分1人になりました。。。そして、GMである自分ともう1人のVGMが兼務してPdMが成立するように動きました。

PdMが決めた仮説検証をベースにチーム編成をしてきましたが、今年に入ってサービスのペルソナ策定やサービスの全体分析（LTV分析）などが活発になりました。開発チームに参加していたUI/UXデザイナーやデータサイエンティストがある機能の仮説検証の領域を大きく超えたことをやるようになったので、タスクやスプリントを一緒に回しづらくなりました。結果としてUXチームとデータ分析チームを設立して、サービス全体に影響するタスクに集中してもらうことにしました。ただ案件で引き続き開発チームと連携してもらっています。

サービス全体のデザインや分析はPdMを兼務していた自分としてはずっとやりたかったことなのでついに辿り着いたか〜と感慨深かったです。（それに伴い組織的な課題が出てきましたが。。。）

サービス全体を考えるペルソナ策定の記事はこちら

ほとんどのチームでPLという明確な役割は無くなりました。UMが中心となってPLの負担をチームでカバーできるようにするためにPL民主化という動きを行なったためです。またUMがPdMに近い動きができないかと挑戦しましたが、断念しました。仮説検証の目的と何を学びとするべきか、学びとするためにどんなことを分析として押さえるべきかという部分の譲渡が困難でした。ただ自分も含めたGM・VGMがPdMとしてやってますが、自分たちの能力としても仮説検証の品質においても世間一般と比較して品質が良いのかは不安です！！

過去の体制からの課題感

現組織体制での課題は沢山ありますが、
今回はチームトポロジーで活用できそうな課題をピックアップしました。

開発チームとしての責任や改善範囲の線引き
- 仮説のアイディア出し・分析結果の議論を営業と一緒にスプリントレビューで実施しており、開発としての事業貢献への意識や価値の重要性は高まっている
- 事業への意識が高まったからこそ、より開発チームとしてどうあるべきかどのような強いチームであるべきかの議論が発生はしているが、どこまでやるかの落としどころを見つけるのが難しい
- 四半期の単位で開発したい案件でビジネスドメインが異なる機能を１つのチームで開発することで、集中しづらい環境になる（障害発生での対応も含め）
他チームとの連携
- 専門チームが設立しており、必然的に連携が必要となった
- 他チームとの関わり合いの定義が存在しないことで何を誰にどこまで共有すべきかの判断が難しい状態がある（難しいというよりも最適解が分からないというほうが近しい）

二つの課題はどちらもより高度な仕事や高い成果を出すために組織のスキルアップが求められている状態なので非常に前向きに捉えています。

課題の内訳の比較表

組織改善前後と現状での比較表をまとめました。

	組織改善前（2018/08~）	組織改善後（2020/08~）	現在（2022/08~）
人材の流動性	×	◯	▲
サービス責任の明確化	◯	▲	× ※1 優先度や担当割り振りで無茶がある
事業貢献への意識	×	▲	◯
Div文化統一	×	▲	◯
チームとしての役割明確化	×	▲	▲ ※2 チームとして特性をどう改善するかが課題
メンバーの役割定義化（PdM、SM、PL..etc）	×	◯	▲
チーム外連携	×	◯（必要な人材はチーム内にいる）	▲ ※3 専門家チーム設立での変化

補足説明

先ほどあげた二つの課題を各項目で分解して説明していきます。

サービス責任の明確化　※1 優先度や担当割り振りで無茶がある

組織改善前のサービス毎の固定リソースでは、サービス責任が明確でした。現状はプロジェクトベースに近い組織になるため、障害が発生した場合に誰が責任を持って改善に取り組むのかが不明確になります。そのためサービス責任者という役割を立て、大きな開発でのアーキテクチャ変更の判断や障害対応での恒久対応のリードを行ってもらうことにしました。

実際担当の割り振りはAWSなどのベンダー単位での分け方にしてました。

サービス	クラウドベンダー	担当者
サービスA	オンプレかつ全体	担当A
サービスA	AWS	担当B
サービスA	GCP	担当C
サービスB	オンプレかつ全体	担当D
サービスB	AWS	担当E
サービスB	GCP	担当F
サービスC	全体	担当G

結論として、この分け方が適切ではなかったです。2年近く運用はしましたが、最近になって廃止する判断をしました。理由については後述します。

チームとしての役割明確化 ※2 チームとして特性をどう改善するかが課題

チームが抱えるサービス開発のミッションがどんどん高度化しています。
2018/07~2021/01までの目標

直近の開発チームのObjective

リテンションレート10%増加
メディア分析のハードルを下げ、条件アップに繋げる
ユーザの充実したひとときの為に今までにはないユーザー体験を提供する！
価値につながる技術貢献

チームが立ち向かう課題は事業数値アップ、ユーザー体験改善、技術改善など切り口様々です。チーム改善やプロダクトの仮説に対して誰かに任せっきりではなく、チームとして解決するためにメンバーが自主的に動けています。ただ、組織としては最低限守るべき基準は出来ている認識はありますが、チームの底力としての解決力はまだまだ高められると思っています。この課題にどこまでチームとしてやるべきなのか？全ての理想的な状態のためにどこまで向かえば良いのだろうかと課題に対しての動くべきポイントや線引きで悩むことが多くなってきました。

チーム外連携 ※3 専門家チーム設立での変化

UXとデータ分析が専門家チームとして設立していますが、開発チームとはよしなに適宜連携するスタンスです。 UXでは新機能開発でUIのプロトタイプ模索を進めて、結果を開発チームへと共有しています。データ分析では仮説に対してのどんな分析であるべきかを一緒に議論したり、指標の設計を一緒に決めたりしてます。現在、専門家チームとして開発チームに関わっているメンバーは、元は開発チームのメンバーだったため、ある種の信頼関係があるため成り立っている部分が強いです。そのため、組織として信頼や感覚をベースにする連携に頼りきりなのはよくないかもと思っています。（ものすごくヤバいという危機感はないですが、手はつけておきたいよね〜くらいです）

チームトポロジーの考えの活用模索

ここまでで、組織の変化と課題感の説明を行いました。それらに対して以下の組み合わせでチームトポロジーが活用できそうかなと考えています。

課題	組織項目	活用できそうなチームトポロジーの考え
開発チームとしての責任や改善範囲の線引き	サービス責任の明確化	節理面
	チームとしての役割明確化	チームタイプ
他チームとの連携	チーム外連携	インタラクションモード

サービス責任の明確化

節理面（技術面やビジネスドメイン）の考慮が適切だなと感じました。

そもそも人数が足りないため、全てのチームで理想的な節理面通りに責任は分けられないです。ただ組織として優先度の高い開発チームでは出来るだけ認知的負荷を減らすなどのメリハリのある割り振りは可能であると思いました。

あるサービスでは節理面は「to C」、「to B」、「プラットフォーム」の3つで明確に分けられると思いました。そこに直近の案件を当て込んでみると、見事にチームAが節理面を跨いだ形での開発を強いられていました。

今は仮説検証ではなく基盤の構築や刷新がメインですのでビジネスドメインの影響は少ないです。ただ、今後は基盤を軸に仮説検証をやりたいと考えており、その場合の「toC」「toB」の両方同時の仮説検証はチームに対して負荷を掛け過ぎる、すなわち無茶振りになるだろうと感じました。今後は仮説検証に注力する際は「toC」に絞った割り振り（開発案件や障害対応も含め）でチームを編成し進めるべきだろうと考えています。開発起因の障害対応も発生する可能性があるため、節理面に沿った任せ方を考えています。

チームとしての役割明確化

チームタイプを各チームで定義付けすることで自チームや他チームの役割の理解しやすさは高まり、役割に沿った改善をチーム自身が推進できるとも考えています。ただ、基本的にはストリームアラインドチームがほとんどだと思っています。

チームタイプにはチームタイプにはそれぞれ期待される振る舞いが本に記載されていました。その中で安定したフローや実験的なアプローチをすべきだとあり、これらは開発チームとしてのチェックリストとして使いたいと思いました。全ての開発チームが扱う案件や状況が異なるため全てこの期待される振る舞いを実行に移せないでしょうが、チームで取捨選択はすると良いかもしれません。

取捨選択の例： - 案件を通して技術力を伸ばすきっかけにしたいから、メンバーの自主性・自律性を高める動きをチームとして活発にさせよう - 基盤の構築を通してより機能の安定性を高めるべきだから、技術負債に対する時間は適切に取ろう

チームタイプでの定義付けも良いですが、期待される振る舞いも十分活用できそうです。