今年ロンドンで開催されたDevOps Enterprise Summitでは、組織設計のための実用的と適応性を備えたモデルの提供を目的として、近く出版予定の"Team Topologies"の著者であるMatthew Skelton氏とManuel Pais氏が登壇して、自身の考えを公開した。
Skelton、Pais両氏は、私たちの頭脳で処理できないほど巨大なソフトウェアは組織のアジリティにとってマイナスである、と説明した上で、リーダに対して、サービスやプロダクトの規模をチームが処理できる認知負荷(cognitive load )に見合ったものにするようにアドバイスするとともに、それぞれのサービスは、それを開発および運用可能な認知容量を備えたチームによって完全に所有されなくてはならない、と主張した。氏らが認知負荷として考えるものには、内部的(スキル)、外部的(メカニズム)、ゲルマン(germane, ドメインフォーカス)の3種類だ。
氏らは、内部と外部の負荷を軽減してゲルマン負荷のための余裕を確保することで、より多くの、あるいはより大規模なサービスをチームが所有可能であるとした上で、そのために有効な手法として、モビング、ドメイン駆動設計(DDD)、開発者および運用担当者のエクスペリエンス、Thinnest Viable Platform(TVP、実行可能な最低限のプラットフォーム)を挙げた。さらに、自ら実施した調査から、次の4つの基本的なチームトポロジを特定すると同時に、最後の3つが最初の手法におけるチームの認知負荷を軽減するように設計されていることを指摘した。
- ストリーム構成チーム(Stream aligned team)
- 実現化チーム(Enabling team)
- 複合サブシステムチーム(Complicated subsystem team)
プラットフォームチーム(Platform team)
ストリーム構成チームは機能横断的なプロダクトチームではあるが、大規模なプロダクトの一部を所有することしかできない。その理由について氏らは、次のように説明している。
チーム間のインタラクションを非常に明確にする必要があります。他のチームと関係する方法や理由を理解していないからです。
Pais氏はいくつかのケーススタディを紹介して、その進化のきっかけになったものについて説明した。ソフトウェアが大き過ぎる、専門性が過剰である、コーディネーションの必要性の増加、煩雑なインタラクション、人材に対する投資不足やバーンアウト、頻繁な状況変化などといったものだ。InfoQは今回、この著者らと、同書のテーマについてより詳しく議論する機会を持つことができた。
InfoQ: リーダにとって、チームメンバの頭の中で何が起こっているのかを、認知的および神経学的なレベルで理解するという行為は、どの程度重要なことなのでしょうか？
Skelton＆Pais: 有益ではあるかも知れませんが、必須ではありません。認知負荷は、外部からでも、非常に簡単に理解でるからです。組織の多くは、認知負荷が適切かどうかを問題にしていません。そのため、成功したチームに対してますます多くを求めることで、認知負荷の限界を越えてしまう傾向が見られます。
InfoQ: ソフトウェアの規模や複雑さを、許容可能な認知負荷に合わせるための方法はありますか？
Skelton＆Pais: 正確な尺度はありませんが、相対的な尺度ならば、ドメインの複雑さを比較することで可能です。発明(大変な仕事です)が必要なドメインもあれば、反復的なタスクが中心のドメインもあります。無関係な作業と密接に関連する作業、あるいは認知の流れを考慮すれば、複雑なテクノロジの使用を求めることが重荷になる場合もあります。システムをどの程度理解できるかを１から5点のスコアで採点する作業を、いくつかの状況において質問を混じえながら、毎週ないしもっと頻繁に行う、という方法も可能です。リーダがその答を見ることで、もっと支援する価値のある個人が明らかになるかも知れません。あるいは、ソフトウェアでアーキテクチャ的に何かを行う必要がある、ということが分かる場合もあります。チームが絶えずコンテキストスイッチを行っていると、作業メモリが無関係なタスクで占められてしまいます — 関係のない認知負荷は、最小限に抑えなくてはなりません。ひとつのサービスを長く担当するチーム構成は、これらの目標を達成する上では有効ですが。同時にそれは、他のチームが手を入れることができなくなる、という意味にもなります。
InfoQ: 社会技術的および神経技術的なパターンは、組織にどの程度受け入れられていると思いますか？
Skelton＆Pais: すでに完了しているところもあります。Twilioのプラットフォーム責任者であるJustin Kitagawa氏は、認知負荷の軽減を明確な目標とする手段としての、開発者の有効性の開放について講演しています。内部ユーザと外部ユーザのどちらであっても、対話をユーザビリティやユーザエクスペリエンスに拡張することは可能です。ユーザビリティは非常に重要ですが、開発者エクスペリエンスと運用者エクスペリエンスのように、非常に多くのギャップが存在するのも事実です。
InfoQ: チーム規模が拡大する、進化論的な理由はどこにあるのでしょう？
Skelton＆Pais： Dunbarの挙げた数値が参考になるでしょう — 心理学者のRobert Dunbarは、人々の直感的な識別に関する調査を行う中で、信頼を基盤とする自然なグループの人数があることを見出しました。信頼や親密さを十分に持つことのできる限界は150人程度です。グループの規模がこれを越えた時には、"私たちと彼ら"という立場が発生する瞬間があります。WL Gore(ゴアテックス)は、工場が一定のサイズ(150人)に達すると、信頼限度に達することに気付いたため、そこで規模の拡張を止めて、別の工場を開くようにしました。この方法で、極めて効率的に規模を拡大したのです。
InfoQ: チームトポロジを決定する責任は誰にあるのでしょうか？
Skelton＆Pais:一般論としては、アーキテクトが担う必要があります。ただし、組織設計とテクノロジの権限を持ったアーキテクトでなければなりません。システムのシリコンの部分ばかり考えて、社会的部分を顧みない、これまでのソリューションアーキテクトは、問題の根源である可能性があります。重要なのは、Conwayの法則に則って、現在のチーム構造による制限のために、実施可能な解決策が見逃されることのないようにすることです。多くの場合、チーム構造は経営陣が決定するのですが、彼らは必ずしも技術的な境界を理解しているわけではありません。ダイナミクスを理解できる人が必要なのです。それは、ビジネスとシステムという、２つのドライバを理解している人々による共同作業です。彼らは"Conway対応"でなければなりません。
InfoQ: 進化のトリガは、どの程度の頻度で聞くべきですか？
Skelton＆Pais: 変化の速度によります。環境が急速に変わっている場合は、より頻繁に行う必要があります。誰かが議論を促して、センサを聞く必要があります。チームリーダは概要を把握してシグナルを見ることができますが、もっと意図的な検査を行うことも可能です。本書には、何かが機能していないことを示す一連のヒューリスティックあるいはトリガが紹介されています。何かが機能しないのは、そのような状況が存在するからなのです。多くの組織は、集中砲火のように届くシグナルにも耳を貸しません。それらを認識できるような信号のスキーマを作成することで、より良い結果と、より改善されたチームのインタラクションモードが実現できるのです。明確に定義されたチームと、明確に定義されたインタラクションモードがあれば、シグナルをもっとよく検出できるようになって、組織の革新と発展に有益なものになります。