Picture credit: Manu Cornet / www.bonkersworld.net

チームが初期に成熟し始め、スクラム チームの構築に向かい始めると、ビジネスのすべての機能をカバーできるように、都合よくひとつの組織単位として働ける人が増えてきます (リリース計画、開発、プロの成長など)。 しかし、成長と成熟は、チームが非正規雇用のシンプルな時代の非構造的な有効性に憧れるような、不快感も引き起こします。 しかし、成長し、市場で製品を適切に管理するためには、ある程度規律正しい組織構造と軽量なガバナンスが必要です。

文化には、全体を効率的に機能させるための構造が本質的に必要なのです。 最も効果的なコミュニケーションは常に身近な領域で局所的に行われるため、最も重要な組織の関心事に関わる意思決定プロセスを局所化することが極めて重要である。 その領域に関する情報が必要なとき、またはその領域で行動を起こす必要があるときに、人々が最も効率的な「行くべき場所」と任意の関心領域をすばやく関連付けることができることは、どんな非自明な社会組織においても重要である

分離可能な関心事の1セットだけを扱う必要がある単純な領域では、単純な組織分割（すなわち、階層）で十分である。 しかし、階層的なアプローチは、複数の懸念事項が重複している開発努力のより典型的なケースで破綻してしまいます。 そのため、より大きく、より複雑な組織単位へと押しやられ、範囲の経済性で問題を解決しようとする。 しかし、最も効果的な作業チームはスモールチームであり、何らかの方法で作業を分割する必要があります。

しかし、どのチームも島ではなく、開発国家は島の集合体以上のものなのです。 チームは個々に独自のアイデンティティを開発し、自然な外国人恐怖症（慣れ親しんだものが必要）の感覚により、チームは自分の社会的サークルの外から来る懸念に二次的な地位しか与えなくなるのである。 もし、企業を1つの単純なパーティションに基づく1組の社会的相互作用に制限するならば、イノベーションを促進する境界を越えたアイデアをシャットダウンすることになる。 ある問題は緊急であり（「我々は他の部族から攻撃を受けており、彼らに対する防御をしなければならない」）、他の問題は重要ではあるが、長い熟慮を許容するか、あるいは求める（「新しい会議場の最適な場所はどこか」）。 シアリングレイヤーという用語は、地震に至るまで互いに移動する地殻プレートの概念にならって、異なる速度で移動する関連プロセスを説明するものである。 建築家()やソフトウェアアーキテクチャ()の分野では、緊密に結合したシステムにおいて、変化の速度が異なる構造や関心事を表現するためにこの言葉が使われている。

もう1つのアジャイル原則は、私たちは外向きであるということです。つまり、私たちの焦点と関心は、仕事をするために使用するツールや技術よりも、エンドユーザー、市場、および顧客にあるということです。

結局のところ、組織の構造は製品の構造と同様にプロセスの構造にも関係するはずです。

したがって、労働力を、企業による価値の創造にとって最も重要な関心事にしたがって分割した、5人以上の小規模チームに組織化します。 これらの構造は、それ以外は制約のない協力のオープンな環境における最適化であることを決して忘れないでください。 彼らは、主要な成果物または購入可能なオプションの周りにスクラム チームを組織することがあります。 したがって、アドレス帳、カレンダー、およびより伝統的な電話機能 (価値領域を参照) を担当するチームがあるかもしれません。 これらは、ビジネスにおける主要な関心事です。 しかし、プラクティス、ポリシー、企業標準（ユーザーインターフェースのルック＆フィールなど）を定義するために、各スクラムチームからの代表者で構成されるグループが存在する場合もあります。 これらのグループは製品を作るわけではありませんが、情報交換の場として、また開発の指針となる標準の情報源として機能します。 健全な組織では、これらの後者のグループのメンバーと開発チームのメンバーはほぼ完全に重なっている。

ほとんどの環境では、主要な組織構造は主要な利害関係者の構造、つまり通常は市場を反映したものである。 このため、内部の成果物の分割やドメイン専門知識の所在に従ってスクラム チームを組織するのではなく、機能などの市場の成果物の線に沿って組織する。 機能などの市場成果物に沿って組織化することは、市場対応や市場投入までの時間短縮にも有効です。なぜなら、その機能を実装するために必要なすべての作業の拠点がチームにあるからです。 これにより、組織内の調整が保たれます。 これが唯一の構造である場合、それは市場の見方のみをサポートし、他の多くの有効なビジネス上の懸念事項を無視することになります。 この構造が機能するためには、第二レベルのコミュニケーション効率をサポートする横断的な構造、たとえば、コア・コンピテンシーに関連する構造によって補完されなければならない。 そのため、このパターンは、ほとんどの場合、「羽鳥」のようなパターンや、「役割におけるドメイン専門性」で説明したパターンと一緒に登場します。 組織の役割構造は、チーム間に自然に形成される壁を切り崩す。 企業内の製品取り組みが、メタスクラムを通じて互いに、そして経営陣とつながるようにする。 チームプライド（チームプライドを参照）をある程度身につけたチームは、これと同等の力が責任を促すので、より効果的である。 これは、チームメンバーの外国人嫌いの影響にもかかわらず、これらの構造が確実に維持されるのに役立つ。

壁やドアのないオープンな環境で、すべてを結びつけるのである。 開発チームは開発コミットメントだけのユニットであり、チームを超えた開発者間の自由な相互作業を制限する干渉があってはならない。

価値のあるあらゆる構成要素は、組織化基準として公正なゲームである。 たとえば、スクラムはチーム メンバーのコロケーションを非常に重視するので、最も基本的な組織の境界はコロケーション チームに対応する可能性が高い。

✥ ✥

優れたスクラムには、製品へのフォーカスによるものと、能力領域へのフォーカスによるものの2レベルのコンウェイ法則があることに注意されたい。 表面レベルでは、プロセスに従ってチームを組織します。それが、プロセスの内向きと外向きの両方の主要な関心事です。

• 開発チームは、製品を構築する際の技術および技法の適切な使用に関する決定を所有し、
• 製品オーナーは、製品の定義と方向性を所有し、
• スクラムマスターは、プロセスが開発チームの定期配送をサポートすることに責任を持つ。 すなわち、スクラムチームの主要な組織原則は、バリューストリームに沿った機能提供の列車と整合することである。 スクラムには弱く浅い階層的な組織があり、スクラム・オブ・スクラムと呼ばれる組織で、共通のプロダクトオーナーを共有する、各製品開発内の複数の開発チームを収容する。 1つの製品開発における各開発チームは、一度に1セットの機能を構築する。 時間の経過とともに、主要なビジネスドライバー、共有されたビジネス知識、およびバリューストリームの成果物がこれらの機能を結びつけます。 開発チーム内には、認識されたタイトルや下位区分はない。

  機能チームに作業を分割する方法は多くある。 開発チームは、特定の市場に機能を提供したり (「組織は市場に従う」を参照)、エンタープライズ技術スペクトルのいくつかのサブセットに対して製品を開発したりすることができます (電話用のチームとタブレット用のチームがありますが、両方とも同じソフトウェアの多くを共有しています)。 一般に、各チームは、企業価値の構成要素を占める何らかの製品を中心に形成されるべきである（「バリューストリームフォーク」の項も参照）。 しかし、スクラムは、各チームが製品の一部分、あるいは製品のサブアセンブリだけを所有するような開発チーム構造を推奨しない。 もし、あるチームのメンバーがシステムの一部分しか開発できないのであれば、他のチームとより多くの開発決定を調整する必要が出てくる。

  スクラムにおけるコンウェイの法則の第2レベルでは、人々は、熟練が価値を生む能力領域を中心に組織化される。 これらの羽鳥は、メンバーがアイデアを共有したり、トレーニングを受けたりしながら、何らかの専門的または技術的な領域で能力を深めていくのを助ける。 ほとんどの人は生来の向上心を持っており（参照）、これらのグループは、チームメンバーが学び、成長することで、個人のプライドを養うことができます。 しかし、これらのグループは報告構造を形成しておらず、どのチームメンバーも自分のスクラムチームだけでなく、複数の羽鳥に所属することができます。 役割のドメイン専門知識も参照してください。

  開発チームの境界とアイデンティティ、およびスクラム チームの境界とアイデンティティは明示されている。 チームのアイデンティティは、意思決定を最適化するのに役立つ社会的文脈をもたらすため、チームのプライドと組織の効率的な運用にとって重要な概念である。 この2つを超える組織アイデンティティの概念は、明示的または管理されたものではなく、暗黙のものであるべきです。 繰り返しになりますが、開発チーム内には「開発者」以外の正式な肩書きはありません。 もし唯一不可侵のルールがあるとすれば、「ゲームの精神」のように、個人が自分の暗黙の専門的地位を利用してチームの合意を覆すことや、その他の方法でチームワークの精神を低下させることはできないということです。

  個人レベルの役割に専門性がある場合もあるが、可能な限りクロスファンクショナルチームでこのパターンを完成させて、ローカルな意思決定の可能性を最適化することが重要である。 コンウェイの法則の起源と実践に関連する多くの神話がある。 オブジェクト指向は、市場の関心事をクラスの内部に局所化することによって、コンウェイの法則をサポートすると長い間信じられてきました。 これは半分事実で、クラスは組織のコア・コンピテンシーという長期的な関心事をカプセル化する傾向があります。 しかし、オブジェクト指向は、市場やユースケースとの関連よりも、開発者の専門知識と彼らが開発する成果物との関連に重点を置いているように思われる。 市場構造との整合性に対する懸念は、開発者のプロセスや製品に関する世界観に対する懸念よりも優先されるべきです。 ウォーターフォール型の組織では、主要な組織構造は要求分析、設計、実装、テストというプロセス段階に沿っていた（、pp.1-9）。 コンウェイの法則により、組織構造はそれらのプロセス上の関心事を反映したものとなっていました。 例えば、サービス指向アーキテクチャ（SOA）では、付加価値の高い要件のほとんどがサービス統合層にあり、個々のサービスは別の層にあることが証明されます。 ウォーターフォールでは、すべての機能が一度に開発者の手に渡るため、機能間の相互作用に関する推論がサポートされる。 ウォーターフォール時代のソフトウェア設計アプローチは、市場の関心事（ユースケース）をアーキテクチャと一致させようとする一方で、組織構造はその分類法を横断するものであった。 同じことが、工場における組立ラインの組織についても言えます。

  開発チームは機能チームであるため、（スワーミングのように）一度に 1 つの機能に集中すべきなのです。 スクラムの主要な市場成果物はフィーチャーであり、この意味で、チーム構造と市場との間の整合性は良好である。 スクラムは製品アーキテクチャの形式について沈黙しているが、アジャイルの精神に則り、個人のコード所有権を抑止する傾向がある。 どの開発チームも、製品のどの部分でも作業できるライセンスを持っています。 スクラムは、カプセル化という組織的なメリットと、チームと市場成果物の整合性というメリットのバランスを取っていると言えるでしょう。 製品オーナーは、開発チームのサポートを得て、時間の経過とともに生じる機能の相互作用をどのように扱うかを管理します。

  たとえば、あるチームがテレコム システムのコールウェイティング機能を実装し、別のチームがコールフォワーディングを実装しているとします。 出現のため、任意の 2 つの製品バックログ項目 (PBI) の間の依存関係を解決するコストを常に予測することはできませんので、一般に、PBI をチームに割り当てることによってこの問題を克服することは不可能です。 いずれにせよ、チームへの早すぎる割り当ては、人々がハードな部分（特に部分間の相互作用に関する部分）に効果的に取り組むことを不可能にし、スクラムチームレベルでの自己組織化を制限する可能性がある。 この2つの機能は高度に相互依存しているかもしれないが、スクラムの構造はそれらの相互作用に一流の身分を与えない。 この場合、おそらく単一のチームが両方の機能を開発した方が良いだろう。 どのようにチームに仕事を割り当てるかは、スプリントプランニングから始まる継続的な計画と共有された意思決定の上に成り立っている。 優れたスクラム チームは、プロダクト オーナーと開発チームの間の親密な、しかし時間的制約のある相互作用を通じて、開発チーム間で仕事を分割するように努めます。 ) スクラムの精神は、人と製品に焦点を当てる傾向があり、その焦点はスクラムの役割と、それらが代表する組織（開発チームやプロダクトオーナー・チームなど）に具現化されています。 既存の管理者がいる組織がスクラムを導入しようとすると、スクラムの取り組みでは、管理者の部分を別世界のものとして否定してしまいがちです。 このような、管理職のいない組織が選択肢にない状況では、管理職を巻き込むことが非常に重要です。

  Steven Johnson. 良いアイデアはどこから来るか. ニューヨーク 6391>

  スチュワート・ブランド.ニューヨーク: Riverhead Trade, 2011.

  スティーブン・ジョンソン. 建物はいかにして学ぶか。 建てた後に何が起こるか. New York: Penguin, 1995.

  Brian Foote and Joseph Yoder. また、”Big Ball of Mud.ˮ In Pattern Languages of Program Design 4, Brian Foote et als. London: Pearson, 2000.

  Daniel Pink. ドライブ 何が私たちを動機づけるかについての驚くべき真実。 New York: Riverhead Books, 2011.

  Melvin E. Conway. このような場合、「委員会はどのように発明するのか」、「Datamation 14(4), April, 1968, pp.28-31.

  Dr. Winston W. Royce. “Managing the Development of Large Software Systems.ˮ In Proceedings IEEE WESCON, August 1970, pp.1-9. (原著はTRW社)

  Bosch Software Innovations. “教訓 “である。 Bosch Software Innovations.ˮ YouTube.com, 15 June 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

  Picture credits.Boschソフトウェアイノベーションズのアジャイル組織(Bosch Software Innovationsのアジャイル組織)。 画像提供：PresenterMedia.com.。