今回もNick Tuneさんの記事「Visualising Socio-Technical Architecture with DDD and Team Topologies」(2020年)を要約してみる。（著者から、日本語での要約の許可を取っている最中）
※超要約しているので詳細が気になる方は記事のほうを読んでください。
※あと、鵜呑みにしないでください。他人の知識は情報なので実践・検証を踏まえないと自分の知識にならないので、今回は情報提供の一環ということでお願いします
何が問題か
【超要約】著者は、多くの企業が無計画にソフトウェア開発チームを編成していることに失望し、このような状況が「Spotifyモデル」のようなチーム編成モデルの普及を促したと指摘している。しかし、Spotifyモデルの単純な模倣ではなく、独自の「ソシオテクニカルアーキテクチャ」の設計が必要であるとも述べている。著者は、チームトポロジー、ウォードリー・マッピング、ダイナミック・リチーミング、ドメイン駆動設計などの組み合わせによる技術組織の効果的な設計ツールの開発に興奮している。
【意見/感想】チームトポロジーはウェブ業界ではよく聞くようになったが、ウォードリーマッピングはあまり知られていない気がする。
ソシオテクニカルアーキテクチャとは
ところで、ソシオテクニカルアーキテクチャとはなんだろう。馴染みがない。Qiitaに記事があったので貼っておく。
ソシオテクニカルアーキテクチャとは、「技術が組織に及ぼす影響」と「組織が技術に及ぼす影響」の双方を考慮したアーキテクチャのことである。
【意見/感想】ソシオテクニカルアーキテクチャは、戦略的な技術と組織を考慮したアーキテクチャという意味のようだ。Nick Tuneさんはソシオテクニカルアーキテクチャの推進者。 "ソフトウェアシステムを設計するとき、我々は組織内のチームへの影響、そしてその逆も考慮しなければならない"という問題意識があるようだ。『エンジニアのためのマジメント入門』でも以下を重要視している。この記事に通じるところはありそうだ。
組織は戦略に従い、戦略は組織に従う
システムは戦略に従う
システムは組織に従う
Visualising Sociotechnical Architecture as Strategy vs Investment(ソシオテクニカルアーキテクチャの戦略と投資としての視覚化)
【超要約】技術能力をコアドメインチャートに配置することで、企業の技術戦略とビジネス目標に関連する重要な能力が明示される。戦略とは、価値の信念だけでなく、資源の割り当てと選択についての決断であり、チャートにコミットメントの評価を追加することで、投資とビジョンの一致を視覚的に示すことができる。しかし、多くの企業はこのような視覚的かつ定量的な方法で技術戦略を表現するのに苦労している。
技術能力をコアドメインチャートに配置することで、技術戦略の側面を伝え、ビジネスの目標達成に重要な能力を示す
以下の図のキャプションは「Visualising your architecture as a portfolio of capabilities with varying strategic importance」。「さまざまな戦略的重要度を持つ各能力を一覧化し、それらを総合的に把握できるようにアーキテクチャを視覚的に表現すること」であり、これは企業やプロジェクトのアーキテクチャを、それぞれの部分がビジネス戦略においてどの程度重要かを示す方法で視覚化するという意味合いを含んでいる
水色は大きく投資するサブドメイン
黄色はプラットフォーム化するサブドメイン
緑色はSaaSやアウトソースするサブドメイン
コアドメインは競争における主戦場であり、一般的なサービスはチームがより効果的に価値を提供するためのプラットフォームを提供する
コアドメイン、汎用サブドメイン、支援サブドメインを視覚化することは価値に関する信念を単に表現しているだけであり、戦略は信念ではなく資源の割り当てと選択に基づいている
コアドメインチャートに各能力に対するコミットメントの評価を追加することで、実際の投資とビジョン、信念が一致しているかを視覚化する
以下の図のキャプションは「How does your allocation of effort align with your business vision of where value lies?」。「あなたのビジネスが重視する価値とその達成のために注力している領域は一致していますか？」という意味。これは、組織がどのようにリソースを割り当てているか、そしてそれがビジネスの目指す方向性や価値観とどのようにつながっているのかを考えるための問いかけになっている
黄色の四角はFTEでのチームサイズ(人数)
多くの企業は、このように視覚的で定量化された方法で技術戦略を明確に表現することができない
【意見/感想】ここで言いたいのは「コアドメインチャートを使うと、ビジネスの価値と技術的な能力の可視化が可能になる」ということだろう。
Optimising Investments(投資の最適化)
【超要約】技術ビジョンと投資を視覚化することで、支援サブドメインへの過剰なFTE（Full-Time Equivalent）割り当てが明らかになり、その原因としてレガシーコードの偶発的な複雑さが浮き彫りになることが示唆される。この偶発的な複雑さを削減することによって、リソースをコアドメインに再配分し、戦略的なリスクと報酬を効果的に評価することが重要だ。このようなシンプルな視覚化手法は多くの企業にとって大きな改善点となり、戦略的な意思決定を支援することができる。
※FTE（Full-Time Equivalent）は馴染みがない。「フルタイムと同等の」という意味らしい。→ Wikipedia
技術ビジョンと投資の視覚化は多くの疑問を提起し、支援サブドメインへのFTEの過割り当てを浮き彫りにする
以下の図のキャプションは「Why are we allocating more time and effort to supporting rather than core domains?」。「本来のコアドメインよりも、補助的な支援サブドメインに多くの時間と労力を使っている理由は何ですか？」という疑問を意味している。この疑問は組織のリソース配分において、最も重要な業務領域に対して十分な注力がされていない可能性を指摘している
視覚化はサポート機能の複雑さがコアドメインより高いことを示し、問題解決のための調査が必要であることを示唆する
ソフトウェアエンジニアとの議論は、レガシーコードベースの偶発的な複雑さが高いことを明らかにする
偶発的な複雑さを減らすことでFTEをコアドメインに再配分できる
以下の図のキャプションは「Visualising investment vs vision accentuates potential strategic optimisations」。「投資と(技術)ビジョンを視覚化することで、潜在的な戦略の最適化が強調される」という意味。投資とビジョンを視覚化することにより、戦略を最適化するための潜在的な機会が明確に浮かび上がる。この方法は、どこに投資すべきか、そして企業の将来的な目標と現在の投資がどのように一致している（または一致していない）かを理解するのに役立つ
偶発的な複雑さを減らすコストと期待される利益を予測し、リスクと報酬のバランスを取る必要がある
この図では支援サブドメインのAとBの偶発的な複雑度をさげて、CとDのコアドメインに投資を集中させることを示している
信念とコミットメントの視覚化により、戦略的な手法を共同で評価することに大きな利点がある
シンプルな視覚化アプローチは多くの企業にとって大きな改善をもたらす可能性がある
【意見/感想】ここで言いたいことは「技術ビジョンと投資を可視化すれば、偶発的な複雑さを減らし、コアドメインに集中できるようになる」ということだろう。
Analysing Relationships Between Teams(チーム間の関係分析)
【超要約】ソフトウェアコンポーネントとそれを管理するチーム間の依存関係は避けられず、大規模なビジネスイニシアチブにより複数のチームが関与する仕事が生まれる。これらのチーム間依存関係を視覚化し、戦略実行への影響を定量化することが重要であり、特にコアドメインへの投資の重要性が強調される。チームトポロジーを活用してチーム間の関係をコアドメインチャートに示すことで、普段は見落とされがちな問題や機会が明らかになる。
チーム間の関係には以下がある。
X-as-a-Service：あるチームがAPIのような技術的な能力を提供し、他のチームが最小限のサポートと協力でそれを利用する
Collaborating(協力)：複数のチームが密接に協力して、大きな作業を完成させる
Facilitating(支援)：あるチームが一時的に他のチームを支援して、その目標を達成する
以下の画像のキャプションは「依存関係は実行に大きな影響を与えます。それらを視覚化する努力をしてください」。プロジェクトやシステムの実行・運営において、異なる要素や部分間の依存関係が重要な影響を持つということを指摘している。そして、これらの依存関係を理解しやすくするために、それらを視覚的な形式で表現することが重要であると強調されている。視覚化によって、プロジェクトの計画や問題解決において、依存関係がもたらす影響をより明確に把握し、適切に対応することができるようになる。
【意見/感想】ここで言いたいことは「戦略の実行に影響がないか、チームトポロジーを考慮しつつ、組織全体としての効率性と各チームの生産性のバランスを取ることが重要」ということだろう。
Defining Team and Tribe Boundaries(チームとトライブの境界定義)
【超要約】チームとソフトウェアの境界間の依存関係の強調は組織デザインの基礎となり、ソフトウェア内の変更パターンの理解がチーム編成の鍵である。システムの共変化(システムの異なる部分が同時に変化すること、または互いに影響を及ぼしあうことを指す)は多次元的で、視覚化により戦略的な最適化が可能になる。加えて、チームの物理的結合やマインドセットに基づくグループ化は、戦略的選択に影響を与え、ソシオテクニカルアーキテクチャ全体を慎重に考える必要がある。
チームとソフトウェアの境界間の依存関係を強調することは、組織デザインの基盤となる
ソフトウェア内でどの部分が同時に変更されるかを理解することが、チームの編成方法を決定するための重要な要素となる
システム内の共変化は多次元的であり、視覚化することで最適化する共変化のタイプに関する戦略的決定が可能となる
チーム編成には物理的境界を超えたマインドセットの側面が重要である。
チームは物理的な結合または開発している製品のマインドセットによってグループ化されるべきかの問い
これらの関係を視覚化することで、戦略的選択への影響を考慮し、ソシオテクニカルアーキテクチャの全側面について慎重に考える必要がある。
【意見/感想】ここで言いたいことは「チーム間の依存関係を明確にし、コミュニケーションコストを考慮しながら、情報共有と調整を密にすることで、全体最適を目指す」ということだろう。
補足：トライブとは
『ユニコーン企業のひみつ』にトライブの解説がある。ご参考までに。
トライブとは、担当するミッションが類似、関連しているスクワッドがまと まったものだ。たとえば「決済」の領域を考えてみよう。これをこなすのに複数 のスクワッドが必要になったとする。登録、認証、支払い、といった分野を複 数のスクワッドで分担するなら、こうしたスクワッドのまとまりがトライブにな る。他にも、さまざまなハードウェア（自動車、テレビ、スピーカー）にソフトウェアを組み込む仕事をしているスクワッドがいるのなら、それが「ハードウェア」トライブになるかもしれない。
Evolving Sociotechnical Architecture Techniques(ソシオテクニカルアーキテクチャ技術の進化)
【超要約】技術戦略とビジネス戦略の整合、および開発チームの編成方法に対する長年の不満を抱いていたが、最近「チームトポロジー」の本やサイモン・ウォードリーの進化理論の影響で動きが見られるようになった。これらの新しいアプローチは、ドメイン駆動設計のような伝統的な概念と組み合わせて効果的であり、戦略的ドメイン駆動設計の真の力を解き放つ可能性があると考えており、これらの課題について意見交換を望んでいる。
技術戦略をビジネス戦略と整合させる方法や開発チームの編成に関して長い間不満を抱えていた
「チームトポロジー」の本が大きな影響を与え、サイモン・ウォードリーがすべての中心に進化を置いている
これらの新しいアプローチは、複雑さに重点を置くDDDなどの伝統的な概念と非常にうまく組み合わせることができる
チームトポロジーとウォードリーマッピングの影響により、戦略的ドメイン駆動設計の真の力を解き放つ可能性があり、これらの課題について意見交換を望んでいる
【意見/感想】ここで言いたいことは「チームトポロジーとサイモン・ウォードリーの理論は、ドメイン駆動設計と組み合わせて、戦略的な技術とビジネスの整合性を高められる」ということだろう。
---
この記事を通じて、ソフトウェア開発における技術戦略とビジネス戦略の整合、チーム編成、そしてソシオテクニカルアーキテクチャの最適化に関する考え方を理解した。また、チームトポロジーとサイモン・ウォードリーの理論が、ドメイン駆動設計と組み合わせが、実用的な戦略を生み出すツールとして参考になるかもしれない。
併せて読みたい