「社内の開発者に価値を届けるチーム」という発想

DevOpsの考えが広まりつつあるなかで、たとえばある機能群もしくはプロダクト全体についてユーザストーリーの検討から実現までを一貫して行うチームも増えているように感じます。

このチームは職能横断的、つまりエンジニアだけではなくプロダクトオーナーやデザイナー、QAエンジニア、インフラエンジニアなど、すべての工程をチーム内の人員で達成できることを目指して組まれます。

「ユーザに価値を届けるための全てをやる」という発想は、さまざまなチームとの調整にリソースを割かれる立場にいる方であれば合理的にも感じますし、幅広いナレッジ・スキルが求められるのでメンバーの成長やモチベーション向上も期待できそうです。

一方で実際にこのようなチームが適切に存在して適切に動けているかを省みると、それぞれで個別の課題を持つこともあるのではないでしょうか。

フィーチャーチームの課題

『チームトポロジー』では、機能単位の職能横断的なチームをフィーチャーチームと呼び、次のようにその難しい点を述べています。

かなり長く引用してしまうのですが、それぐらい「わかりみ」ってのがあったので、まるっと引用します。

これ[フィーチャーチームの構造]はうまくいくパターンだろうか？　それともアンチパターンだろうか？　おわかりだろうが、状況次第だ。

職能横断型なフィーチャーチームは、コンポーネントを横断して顧客中心の機能をすばやくリリースすることで、組織に高い価値をもたらす。その速度は、複数のコンポーネントチームがそれぞれに変更を加えて１つのリリースにまとめるよりもかなり速い。だが、これができるのはフィーチャーチームが自給自足、つまり他のチームを待つことなく機能を本番にリリースできる場合に限る。

フィーチャーチームは通常複数のコードベースを触る必要があり、そのオーナーシップは他のコンポーネントチームにあることもある。チームのエンジニアリングの成熟度が高くない場合、ユーザーの新しいワークフローのテストを自動化しなかったり、「ボーイスカウトルール」（自分が来たときよりコードをきれいにしてから帰る）に従わなかったりといった近道をしてしまう。これによって、時間とともに技術的負債が増えデリバリーの速度が落ちるにつれて、チーム間の信頼が壊れていく。

また、チーム間の規律が保たれていないまま複数のチームが同じコードベースを扱うと、その悪影響が蓄積していき、共有コードに対するオーナーシップの欠如につながることもある。¹

（太字は筆者）

たとえばマイクロサービスが実現されておらず、ひとつの大きなプロダクトのある範囲を運用保守するチームを想定した場合、引用した懸念は現実味が増してきます。

たとえばある機能追加のリリースには他チームのレビューをはさむ必要があったり、複数のチームが利用する共有コードがぐちゃぐちゃになってきたり、結果として各チームが拾わないプロダクト全体の課題が積まれていくことは、よくありそうです。

プロダクトチームの課題

同様にフィーチャーチームではなく、プロダクト全体をまるっと開発運用するプロダクトチームではどうでしょうか。

プロダクトチームは、自分たちの成果をエンドユーザーに提供する上で、インフラストラクチャー、プラットフォーム、テスト環境、ビルドシステム、デリバリーパイプラインなどに依存する。これらの依存関係のうちのいくつかは自分たちですべて扱えるかもしれない。だがChapter3で説明したように、当然ながら、チームの認知や専門知識には限界があり、他の人たちの助けが必要なこともある。

チームが自律的でいるのに重要なのは、外部への依存関係をノンブロッキングにすることだ。すなわち、新機能はできているのに、外部の何かを待っているということがないようにする。たとえば、プロダクトチームが新機能を作り終わったら、確実にQAチームがすぐ評価に取りかかれるようにするのは極めて難しい。チームはそれぞれ異なる作業負荷、優先順位、問題を抱えている。また、一般的にソフトウェアシステムの構築と運用はとても不確実性が高いため、事前に決めたスケジュールに沿って、同じ仕事のストリームのなかで複数のチームが調整を行うのは難しい。このアプローチにこだわると、必然的に待ち時間や遅延が増えるのだ。²

(太字は筆者)

まずインフラやCI/CDなどプロダクトを運用するために必要なスキルを扱える前提を達成するのもなかなか難しそうです。スキルに不安のあるチームの場合、チームの中で仕事を進めたくてもそうはいかない瞬間が日々あることでしょう。

またそれらのスキルが備わっていたとしても、扱う範囲・規模が大きい以上、他チームに仕事を依頼することは絶対にあります。

このとき他チームはこのプロダクトのみに関与しているわけではないので、このスケジュールの調整が発生したり、最短のリリースは叶えられなくなります。

開発者を支えるためのチーム

ここまで見たような課題を解消するための考え方のひとつとして、フィーチャーチームやプロダクトチーム³を支援するためのチームを『チームトポロジー』は紹介しています。

ここでは2種類のチームを紹介します。どちらも(最初に)価値を届ける対象はユーザではなく、開発チームです。

必要な能力を効率的に身に付けさせるチーム(イネイブリングチーム)

ひとつは、チーム単位で欠けている能力を埋めることを目的に期間限定で活動するチームです。イネイブリングチームと呼ばれています。

たとえば単体テストが上手に書けないチームと協働してテストを充実させるよう働きかけたり、クラウド環境の構築を支援したり、新規開発におけるアーキテクチャの選定を手伝ったりするのが該当するでしょうか。

ポイントは2つで、イネイブリングチームと協働することで開発チームの成長が爆速になること、そしてイネイブリングチームとの協働は期間限定であることです。

価値提供がより素早くなるように内部サービスを提供するチーム(プラットフォームチーム)

もうひとつは、開発チームが利用する下位のサービスを開発するチームです。プラットフォームチームと呼ばれています。

たとえばベーシックなAPIやライブラリの提供や社内ツールの開発、インフラやネットワークに関連したタスクが挙げられます。

重要なことは、開発チームがすべてのオーナーシップを持っていることと、オーナーシップを持てるように認知負荷を下げるための内部サービスを提供することです。

感想

詳細は『チームトポロジー』を読むのがベストですが、この中から面白かった箇所をピックアップして紹介してみました。

どちらのチームも「ユーザに価値を届けるための開発チームに価値を届けること」が目標となっており、読んでいると納得感がありました。価値を届ける一連の流れがスムーズにならなければ、どれだけ頑張っても価値を届けるスピードはどんどん落ちていくからです。⁴

実際の現場では、イネイブリングチームやプラットフォームのような動きを、社内の誰かが有志で担っていたりすることが多いかと思います。

ある程度の規模の組織であれば、それらをチームとして組み立ててみるのもアリかなと感じました。

参照

マシュー・スケルトン,マニュエル・パイス『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』

マシュー・スケルトン,マニュエル・パイス『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』、p124(Kindle版) ↩
同、p125-126。 ↩
『チームトポロジー』では、他のチームに仕事を引き継ぐことなく、自分たちの権限で、すばやく・安全にユーザに価値を届けることを目的とするチームを「ストリームアラインドチーム」と定義したうえで、ストリームアラインドチームをエンパワーメントするためのチームとして、ここに紹介したイネイブリングチームやプラットフォームチームを定義しています。 ↩
一連の流れ＝ストリームに着目するからこそ「ストリームアラインドチーム」なのだな、と腑に落ちています。 ↩