鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）：The Rational Edge（1/4 ページ）

効果的ガバナンスは指揮統制ではなく、協調的で協力的なテクニックによる実現を重視する。これは、これはネコを先導するようなもので、何かを強制するのではなく、やる気にさせる方が一段と効率的であるはずだ。（本文より）

[Scott W. Ambler, Per Kroll，IBM]

チーム構造とアーキテクチャの適合

　Melvin Conwayが1960年代後半に定義したConwayの法則は、「どのソフトウェアも、それを作り出した団体の組織構造を反映している」としている。このようなことが起きるのは、人は自分たちがどのように組織化されているかを反映した形で作業をするためだ。つまり、分散したグループは分散アーキテクチャのシステムを作り出す可能性が高い。プロジェクトチームの組織構造にある長所や短所は、いずれも彼らに生み出されるシステムに必然的に反映されることになり、それは効率的なITアーキテクチャが目標ならITの組織構造が効率的でなくてはならないことを暗示している。

例：

1.　地域主導のアーキテクチャ。地理的に分散している組織は、各主要コンポーネント（フレームワーク、データベース、アプリケーションなど）の所有権を1カ所ずつ分散するエンタープライズアーキテクチャを検討する必要がある。例えば、インドのチームがデータウェアハウスを所有し、スイスのチームが複数のアプリケーションを所有し、米国のインフラチームがセキュリティフレームワークを所有するといった具合だ。コンポーネントの所有権を地理的に分散して整理することでコミュニケーションの障壁が減少する。

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

2.　品質主導の組織。システムで高いレベルの品質を達成したい場合は、進行中の作業を繰り返し審査し、勧告を行う品質エキスパートを開発チームの中に組み入れる必要がある（こうすることでコミュニケーションの時間が削減され、文書化による情報紛失の可能性が低下する）。プロジェクトチームの作業を外部から認証する独立したテストチームを置くこともできるが、品質エキスパートの大部分はチームに組み込まれる点に注意したい。品質が組織の最優先事項でなくても、特定の品質レベルに達した証拠が文書で必要な場合は、外部品質管理グループが開発チームの作業を審査するだけで十分だ。

3.　ユーザビリティ主導の組織。ユーザビリティがシステムにとって最大の関心事である場合は、必ず簡単にフィードバックを入手できるようエンドユーザーに近いところでチームを組織する必要がある。また、ユーザビリティ担当エンジニアもプロジェクトチームに組み入れる必要がある。

4.　再利用主導の組織。（コンポーネント技術やサービスベースの技術に基づいた）再利用が重要な要因である場合は、コンポーネントとほかのプロジェクトとの統合を支援するために用意されたこれらの再利用可能なアーキテクチャの要素を所有してサポートするチームが必要になる。

メリット

　組織構造と必要なアーキテクチャを適合させると以下のような大きなメリットがある。

• 開発チームが可能な限り簡単にアーキテクチャに適合できるよう開発作業を合理化する
• 反復作業を短縮するチャンスが生まれる（それによりプロジェクトのリスクが削減される）
• グループ間の受け渡し、審査、手直しなどの無限に繰り返されるサイクルが削減される
• チーム全体のコミュニケーションが向上する

トレードオフ

　この手法には次のようないくつかの代償が伴う。

　 矛盾したアーキテクチャの優先事項。場合によっては、セキュリティなどの1つのアーキテクチャの優先事項が1つの組織戦略の選択につながることがある一方で、配布などの同様に重要な優先事項が全く異なる組織戦略につながることもある。アーキテクチャで妥協が必要なように、組織的にも妥協の必要が出てくる。

　全社的制限。組織がはるか前から集中データアーキテクチャを決めていながら、データ運用チームが現在も世界中の開発チームとともに分散化されたシステムを開発中というケースもある。幸いにも、石で彫ったような変更の難しい組織構造は1つもなく、既存のニーズをより良く反映した新しい構造を決めることは可能だ。

　アーキテクチャだけが要因ではない。組織構造を定義する際に考慮すべき要因はアーキテクチャだけでなく数多く存在する。これらには、投入可能な人材、該当する規制や雇用関連法、個人の性格、文化、そして利用可能なオフィススペースなどの非常に基本的なものまである。

アンチパターン

　この手法には以下のようなアンチパターンがある。

　1つの組織の戦略がすべてに当てはまる。基盤アーキテクチャでシステムが異なるように、チームもその全体の組織構造によって異なってくる。例えば、1つの開発チームが1つの部屋に配置され、利害関係者と密接に協力する一方で、別の開発チームは複数のサイトにまたがる地域分散型になる。たとえ同じ組織であっても、各チームがそれぞれ異なる状況にあり、異なるシステムを異なる方法で開発している。1つの組織構造をすべてのチームに無理やり当てはめようとすると、組織やアーキテクチャの不一致によって、全部まではいかなくとも、いくつかのプロジェクトを危険にさらす可能性がある。

　組織によるアーキテクチャの抑制。組織構造は、システムの本当の要件を検討せずにアーキテクチャ面からアプローチを正当化するために利用される。例えば、一元管理されたデータ運用グループがあるために、複数のデータストアを各サイトに分散させた方が理にかなうアプリケーションがあるにもかかわらず、一元管理されたデータストアをすべてのシステムに強制する場合だ。このような判断は、比較的分かりやすい管理作業を合理化するため、全体の技術的リスクはもちろんのこと、開発や運用のコストを引き上げる可能性がある。

　アーキテクチャによる組織の抑制。1つ以上のシステムで構成されるアーキテクチャは、アーキテクチャ以外の問題を検討することなくIT部門のアプローチを正当化するために利用される。例えば、組織が分散アーキテクチャを採用したミッションクリティカルな顧客関係管理（CRM）システムを購入し、インストールし、運用しているとする。ここでは、IT部門を1カ所にまとめてIT関連コストを削減したくても、CRMシステムのアーキテクチャに柔軟性がないためそれができない。

推奨デフォルト

　デフォルトでは、アーキテクチャを中心に組織化を行い、部門間の枠を超えて協力できるチームに各主要コンポーネントを担当させる。もう1つの方法としては、複数の「ベース」チーム構造の中から出発点を選択し、それからチームに自己管理をさせて（「自己管理チーム」手法参照）具体的な状況に合致した構造を開発できるようにする。

［ポリシーと基準］

　このカテゴリの手法は、さまざまな開発関係者間の首尾一貫した業務をサポートする具体的な指標を説明する。アジャイルソフトウェア開発にとって第一の価値である「個人と対話はプロセスとツールを上回る」は、プロセスやツールが全く必要ないことを暗示するものではなく、これらが人や、その人々が協力する手法ほどは重要でないという意味にすぎない。組織を統治する高効率アプローチは、開発者が効果的にコラボレーションを行い、既存のインフラや資産の開発および再利用、そして品質の高い作業へとつながるツールやポリシーを採用することになる。ポリシーや基準に関連する手法には以下のようなものがある。

• 統合ライフサイクル環境
• 評価IT資産
• 柔軟なアーキテクチャ