INDEX
ソフトウェア開発チームの改善において大きな課題の一つとなるのが組織設計です。
これまでに高速なソフトウェア開発を実現する手法として、短い開発期間単位を採用し、すばやく価値を届ける「アジャイル開発」やソフトウェア開発チームとオペレーションチームのコミュニケーションを円滑化し、互いに協力し合うことで柔軟で迅速な開発を実現する「DevOps」などが広く活用されてきました。
そうした中で、組織設計の新たなモデルを提示したのが『チームトポロジー: 価値あるソフトウェアをすばやく届ける適応型組織設計』です。
本書の著者であるマシュー・スケルトンとマニュエル・バイスは、DevOpsのコンサルティングなど、開発や組織設計、運用に関わってきたプロフェッショナルです。
DX（デジタルトランスフォーメーション）が叫ばれ、あらゆるモノ・サービスがIT技術を基盤にする現代において、言わずもがな、ソフトウェア設計の重要性は高まってきています。
不適切なソフトウェア設計や顧客ニーズとのミスマッチに伴う影響が大きくなる中、安定性と速度を兼ね備えたソフトウェア開発が求められています。
安定性を出すためには、さまざまなプラットフォームをまたいで、さまざまなスキルを持つ人たちの力を結集する必要があり、速度を出すには、システムをすばやく安全に提供、運用すると同時に、成長を続け、ビジネスや規制環境の変化や圧力に適応させる必要があります。
一方で組織図に依存した仕事の分割・管理では、スキルや職種で知見が偏るようになり、管理コストも高いため、安定性と速度を両立することが難しい、という課題が。
そこで本書では、単一で静的な組織図から抜け出し、より今の時代にあった複雑で動的な構造を持つ技術組織をつくることを試みています。
それでは、組織図に基づかない組織構造にはどのようなものがあるのでしょうか？
組織図の構造から抜け出すためには「非公式な構造」と「価値創造構造」が重要になると本書では、語られています。
【非公式な構造】
チームに権限を与え、チームを基本的な構成要素として扱うことで、チーム内の個人は、単なる人の集まりとしてではなくチームとして密接に連携しながら進むように
【価値創造構造】
他のチームとのインタラクションモードを明示的に合意することで、期待するふるまいが明確になり、チーム間の信頼関係が育まれる
本書において重要なコンセプトになるのが、コンピューターシステムの研究者、メルヴィン・コンウェイが1968年に考案したコンウェイの法則です。
コンウェイの法則とは「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というもので、「同形力」とも呼ばれます。
コンウェイの法則は、ソフトウェア構造設計とチーム構造に不一致がある場合、意図しない設計を生み出すことにつながるリスクを指摘しています。
そして、本書では、すばやく、安定的なシステムに反映したいアーキテクチャに合うようなチーム構造を作るために本書で提案したのが、「逆コンウェイ戦略」というものです。
これは、今ある組織からシステムの設計をブレイクダウンするのではなく、望ましいシステムの設計を考慮した上で、組織の編成を調整するという戦略です。
そしてこの逆コンウェイ戦略を実行するための一つの手法が、4つのチームタイプと3つのインタラクションモードからなる「チームトポロジー」です。
チームトポロジーのアプローチでは、組織設計において状況に応じて、適応できるモデルを重視し、チーム間の相互関係に積極的に優先順位をつけます。そこで活用されるのが以下の4つのチームタイプと3つのモードです。
ストリームアラインドチーム | 組織で中心となるチームタイプ。価値のある単一の仕事のストリーム（サービス、機能など）に沿って働く。すばやく安全に顧客に価値を届けるように、顧客の要望探索から本番運用まで、作業を進めるのに必要な能力を兼ね備えており、チームには権限が委譲されている。 |
プラットフォームチーム | ストリームアラインドチームが自律的に仕事を届けられるように手助けするチーム。ストリームアラインドチームが開発するサービスの内部サービスを提供する |
イネイブリングチーム | ストリームアラインドチームに欠けている技術や情報を補助するチーム。チームに役に立つ情報を調査したり必要な技術を獲得するのを支援する。 |
コンプリケイテッド・サブシステムチーム | システムの中で動画処理や、金融サービスのトランザクションレポートシステムなどスペシャリストの知識が必要となるパーツを開発、保守するチーム。複雑なサブシステムを担うことでストリームアラインドチームの認知負荷を下げる。 |
コラボレーション | 他のチームと密接に協力して作業する。引き継ぎが少なく、すばやくイノベーションと探索ができるが、チームをまたぎ広く共有されるため、コミュニケーションコストが高く、責任が大きくなる |
X-as-a-Service | 最小限のコラボレーションで何かを利用、または提供する。責任境界やオーナーシップが明確。コミュニケーションコストが低く、認知負荷が低いというメリットがある。一方で、境界やAPIにおけるイノベーションが遅くなり、ボトルネックになることも |
ファシリテーション | ストリームアラインドチームの障害を取り除く。プラットフォームにおいてギャップや整合性の取れていない機能を検出できる。しかし、「構築」や「運用」に従事しないスタッフを配置する必要があり、「構築」や「運用」に従事していない状態に慣れるのが難しい |
組織は社会技術的なエコシステムであり、その中にいる個人やチームの相互作用の影響を受けるものであり、ソフトウェアアーキテクチャはチームから独立した概念として切り離せるものではない、という思想に本書は支えられています。
したがって、チームは固定の組織図で描ける取り替え可能な個人の集合ではなく、そこにいる人と技術が混ざり合い、常に変化していきます。
変化に適応し、アウトカムを生み出すためにも、「チームトポロジー」が提案するコンセプトは非常に有用です。ソフトウェア開発でより早く、より多くのアウトカムを求めるとき、ぜひ本書に目を通してみてください。
【参考引用文献・サイト】 ・DevOps とは何か? | Atlassian ・アジャイル開発 - NECソリューションイノベータ ・マシュー・スケルトン、マニュエル・パイス （原田 騎郎、永瀬 美穂 、吉羽 龍太郎 訳)『チームトポロジー: 価値あるソフトウェアをすばやく届ける適応型組織設計』
（大藤ヨシヲ）
メルマガ登録をしていただくと、記事やイベントなどの最新情報をお届けいたします。
30秒で理解！インフォグラフィックや動画で解説！フォローして『1日1記事』インプットしよう！
メール会員でできること
