この記事はJames Coplien氏の記事「Organizational Patterns: Building on the Agile Pattern Foundations」を、氏の許可を得て翻訳したものです（元の記事が長いため抄訳としています）。（原文最終更新日：2006年7月9日）
- 目的の統一性（"Unity of Purpose"）
- 顧客の参画 ("Engage Customers")
- ドメイン専門家という役割 （"Domain Expertise in Roles"）
- アーキテクトがプロダクトをコントロールする （"Architect controls Product"）
- 作業の均等な分配（"Distribute Work Evenly"）
- 関数の所有者とコンポーネントの所有者 （"Function Owner and Component Owner"）
- 雇われアナリスト （"Mercenary Analyst"）
- 実装するアーキテクト （"Architect also implements"）
- ファイアウォール （"Firewalls"）
- 開発者がプロセスをコントロールする （"Developer controls Process"）
目的の統一性（"Unity of Purpose"）
...チームがまさに共同作業を始めようとしているとします。チームメンバは異なるバックグラウンドを持ち、全く別の経験をしてきているかもしれません。
* * *
多くのプロジェクトは始まりでつまづきます。メンバが一緒に作業するために苦労するからです。
最終的なプロダクトがどうあるべきかということについて、メンバが異なる考え方をしているということはよくあります。実際、最終的なプロダクトがきわめてあいまいな概念であることもよくあるのです。しかし、そのプロダクトを実現する望みがわずかでもあるならば、メンバはプロダクトに関する一貫したイメージを持たなければなりません。
人はそれぞれ違い、異なるとらえ方と意見を持っています。異なる背景と経験を持っているのです。そういう人たちが一緒に働くことを学ばなければなりません。
いいスタートを切ることは重要です。第一印象はいいものであっても悪いものであっても、続いてしまうものだからです。
したがって、
プロジェクトのリーダは共通のビジョンと目的を、チームのメンバ全員にインストールしなければなりません。この「リーダ」はマネージャや「後援者というロール（"Patron Role"）」、顧客の支援者などであるかもしれませんが、チームから尊敬され、チームの思考に対して影響を与えられる人物であるべきです。これは意図して行われる行為であり、自然に起きることを期待することはできません。リーダは、次のことについて全員を合意させる必要があります。すなわち、「このプロジェクトは何をするべきなのか」ということについてです。顧客が誰で、このプロジェクトがどう役に立つのか。スケジュールはどうなっているのか。また、スケジュールについては全員が個人的にコミットするものでなければなりません。さらに、誰と競合するのか。
この活動において重要なのは、チームの強みを認識し、それをチームの求心力として使うことです。これは、課題と競争相手とを認識し、課題を克服して競争相手を上回るために団結することにもつながります。
時間が経つにつれて、この目的の統一性（"Unity Of Purpose"）は、チーム内の対話や、顧客やその他のステークホルダとの対話においても登場し続けます。チームリーダはこれを推進しますが、チームのダイナミクスがこれを引き受け、進めていくことになります。
顧客の参画（"Engage Customers"）
店員が洋服を仕立てるために、顧客の採寸をしている。テキサス州サンアントニオ
著者の友人の一人が以前、巨大なシステムのためのユーザインタフェースを設計、実装したことがあります。使いやすくするためにどうすればいいのかということについて、友人は顧客からのインプットをもらいました。残念なことに、要件を記述していた人はそれとは別の考えを持っており、顧客が望んだ機能を削除させました。しかし、後でこの削った機能を顧客が要求し、この要件を記述していた人は折れざるを得ませんでした。友人と要件を記述していた人との仲は悪くなったのではないかと思います。
組織が整ってくると、品質保証（"QA"）の機能も徐々に整備され、特権を与えられます。品質保証の機能はその仕事を進めるにあたって、インプットを必要とします。企業内の多くの人が、品質について気にかけます。
* * *
開発組織内で主要な役割を担う人と顧客との間のコミュニケーションを促進することによって、開発組織が顧客満足度を高め、維持することは重要です。これはどこか一つの「顧客満足度」組織に課すべきものではなく、組織構造全体で担うべきものです。ほとんどの組織は、開発者と顧客との直接的な交渉を嫌いますが、これは開発者が「何をしでかすか分からない危険人物」で、仕事の範囲をこえたものを作ると約束してしまうことを恐れてのことです。
しかし、全ての要件をアップフロントに知ることはできないため、開発者はより多くの情報を得るために顧客の所へ戻って行く必要があります。また顧客も自分たちが持つ洞察を携えて開発者の所に戻って行かなければなりません。これは特に開発者が「プロトタイプを作る（"Build Prototypes"）」時には言えることです。要件の変更は設計のレビューが完了し、実装が始まった後にも起こるのです。
多くの組織では、要件と要求を引き出すにあたって、マーケティング組織に依存しています。しかし、マーケティングは設計情報を提供しません。マーケティングができる（あるいはすべき）なのは、せいぜい、何が売れ、どうしてそれが買われるのかを理解することです。一方で、設計する人は、そのプロダクトが、どうやってユーザに取っての価値を生むような仕方で使われるのかを理解しなければなりません。優れた価値は、時に優れたマーケット上の可能性につながります。しかしマーケティングは設計者があまり気にしない要素に目を向けるものなのです（ブランド名の認知度、製品名、アピールなど）。
顧客の要件が失われてしまうことは重要な問題です。ソフトウェアシステムにおける問題のほとんどが、要件の問題に端を発するからです。しかし、この問題を引きずり出すのは大変な労力です。市場に出すことができるものを直接生み出す仕事ではないため、無駄な仕事を作るオーバーヘッドに見えてしまいます。
伝統的に、顧客は開発の主流に関わってきませんでした。そのために、顧客が持つ洞察を発見し、取り込むことが難しかったのです。しかし、顧客との結びつきはプロジェクトの成功と関係しています。
マネージャとコーダとの信頼関係はしばしばぎくしゃくするものです。したがって、それを開発者と顧客との関係に持ち込みたくはないでしょう。
したがって、
顧客というロールを開発者やアーキテクトと密接に関係づけなさい。QAやマーケティングとだけではいけません。一言で言えば、開発者やアーキテクトは顧客と自由に、そして頻繁に話すことができなければならないのです。可能であれば、顧客にあなたたちの環境に来てもらうのではなく、向こうの環境で参画してもらいなさい。
このために必要なものが２つあります。それがチャンスと文化です。開発者は顧客とコミュニケーションする機会（と方法）を持たなければなりません。開発者は顧客の信頼を得て、自由にコミュニケーションするために、個人的に会わなければならないのです。
しかし、もし組織の文化が顧客と開発者との間に見えない壁を作っていたら、こうした訪問は表層的なものになるでしょう。特に、システムの要件が承認されるために、時間のかかる正式なプロセスを踏まなければならないのだとしたら、開発者は顧客の要求に応えることができず、身動きがとれなくなるでしょう。したがって、組織は開発者が顧客の要求にある程度自由に応えられるような文化を育てる必要があります。だからといって、要件のコントロールをすべて開発者に明け渡さなければならないということではありません。秩序は必要です。
Bayer氏とHoltzblatt氏は「顧客と一緒に仕事をする一般的な方法の多くが、顧客をその仕事から遠ざけてしまう」と語っています。これを解消する方法の一つに「設計する人とエンジニアを直接顧客が仕事をするコンテキストに放り込む」というものがあります。これは、既存の仕事を改善するのではなく、全く新しい市場の方向性を企業のために生み出そうとして顧客に参画してもらっている場合には、特に重要になります。開発者を顧客が仕事をする環境に放り込むことは、優れた設計、優れたヒューマンインタフェースに関する開発者の直感を鍛えます。そしてこの直感によって、はっきりとした詳細な要求が得られない時にそれを埋めることができるようになります。
言語はこうした文化における主要な要素で、適切に扱われれば顧客の参画をスムーズにすることができますし、間違って扱えばうまく行かなくなります。顧客にUMLやその他の技術的な記法を学ばせようとするのはやめなさい。顧客の言語を学び、顧客の文化が持っている用語でコミュニケーションすることに最善を尽くしなさい。
品質保証はこの関係を監視し、進む方向が契約に関わる業務上の制限を超えないように保つことができます。こうしたコミュニケーションは妨げられることなく行われがちですが、これについては「門番（"GateKeeper"）」パターンを参照して下さい。
このパターンが人間関係と文化に関わるものであることには注意が必要です。コミュニケーションを効果的にするのは、顧客に対する尊敬と顧客とのコミュニケーションを持った文化です。例えば、「参加型の聴衆（"Participating Audience"）」において説明されているように、ユースケースを書いている時のコミュニケーションが考えられます。
ドメイン専門家という役割（"Domain Expertise in Roles"）
テキサス州コーパスクリスティ、海軍航空基地。一流のメカニックであるMary Josephine Farley氏が飛行機のエンジンを巧みに組み立てている。まだ20歳だが、彼女はプライベートなパイロットの免許を持っており、都市の横断飛行を何度か行った経験がある。
...開発者という役割を特徴づけることを含む、アトミックなプロセス内での主要な役割（「型は機能に従う（"Form Follows Function"）」）について、あなた方は知っているはずです。
* * *
成長するダイナミックな組織において、色々な役割にスタッフを割り当てることは、最も難しい課題の一つです。あらゆる役割にはスタッフが割り当てられる必要がありますし、さらに言えば、あらゆる役割には適切な個人が割り当てられなければいけないのです。演劇と同じように、数人の役者（"actor"）にはある１つの役が与えられますが、それ以外の役者はいくつかの役を演じるかもしれません。
ある人がその仕事に対して適任かどうかを判断する上で、ドメインに特化しない基準を使いたいと思うかもしれません。たとえば、大学の成績や、経験年数などです。こうしたアプローチを取ることで、プロジェクトはスタッフを柔軟に割り当てることができるようになります。つまり、個人のスキルセットと経験に過度に依存することを避けられるのです。こうした基準がうまく働くだろうと期待することで、プロジェクトマネージャは、プロジェクトが特定の個人に過度に依存しないようにするための基盤を手に入れられます。特定の個人は、会社を辞めてしまうかもしれませんし、給料アップを求めて組織を人質にとるかもしれません。また、独自のポリシーを一方的に実装してしまうかもしれません。しかし、成功したプロジェクトは、成功したプロジェクトで仕事をしたことがある人から構成される傾向にあるのです。
専門知識が複数の役割に散らばってしまうと、コミュニケーションパターンが複雑になります。これによって、ドメインに特化した要求や設計上の疑問について誰が答えるべきかということが、開発者やその他のプロジェクトメンバから分かりにくくなってしまうのです。
したがって、
実績のあるドメインエキスパートを雇い、役割に組み込まれた専門知識を軸にスタッフを割り当てなさい。そうすることで、ドメインに対する共通の関心や焦点の領域を取り巻いて、チームやグループが形作られるようになるのです。複数の役割を果たす役者は何人いてもかまいません。多くの場合、複数の役者がある特定の役割を演じることもあるでしょう。
ドメインのトレーニングはプロセスのトレーニングよりも重要です。
ローカルなグルを作ることは良いことです。このことはアプリケーションの専門家から、手法や言語の専門家に至るまで、あらゆる領域について当てはまります。
アーキテクトがプロダクトをコントロールする（"Architect controls Product"）
...開発者の組織がある以上、技術的に向かうべき方向を決める戦略が必要です。
* * *
プロダクトが多くの個人によって設計されていたとしても、プロダクトが正確で一貫したものになるように、プロジェクトは努力しなければなりません。これを中央集権によって実現しようとする人もいるかもしれませんが、全体主義的なコントロールは多くの開発チームから見ると厳格すぎる手法です。１人がすべてを行うことはできませんし、先のことが完全に読める人も存在しません。しかし、正しい情報は適切な役割を持った人のところを流れなければなりません。コンピテンシーや専門性といった個人的な領域が相変わらず必要だとしてもです。
さらに、一定のレベルでアーキテクチャ的なビジョンも必要です。ドメインに関する専門知識がいくつかの開発者チームで分散されたとしても（「ドメイン専門家という役割」）、システムの見方、特に対話と構築に関する共通の文化を生み出すような設計の原則は、概念的な統一性（"conceptual integrity"）がとれていることでうまく行きます。こうした概念的な統一性を、私たちは特定の人や小さいグループと関係づけます。
したがって、
アーキテクトという役割を作りなさい。その役割はプロジェクトのアーキテクチャスタイルを定義するアーキテクチャ上の原則と、そうしたスタイルを正当化するような、ドメインに対する広い専門知識が埋め込まれたものとしなさい。アーキテクトという役割は、開発者という役割に対してアドバイスと影響を与えるものでなければなりません。また開発者と密接にコミュニケーションを取らなければなりません。アーキテクトはインタフェースに関して命令はしません（調停が必要な時は別ですが）。そのかわり、アーキテクトは各開発者やサブチーム、また必要であれば全開発スタッフと、アーキテクチャスタイルに関するコンセンサスを形成します。アーキテクトは、開発チームメンバ間の主要な橋渡し役です。
また、アーキテクトはドメインに関する専門知識が、最新かつ詳細で整合性が取れたものになっているよう、顧客とも密接に関わらなければなりません。
作業の均等な分配（"Distribute Work Evenly"）
20頭のラバで構成されたチームが作業とコミュニケーションを均等に分配している。
...組織は、人的資源を有効活用するため、可能な限り楽しい環境をつくるよう努力しています。
* * *
組織内の負荷の多くを、数人に負わせるのは容易です。マネージャがこれを好むのは、管理しなければならないインタフェースの数を最小化できるからです。さらに、従業員によっては、こうしたヒロイックな責任という勘違いから、できる限りのことをやろうと苦労します。実際、「プロデューサという役割（"Producer Roles"）」がそれを支援する他の役割よりも強いコミュニケーションネットワークを構成しがちだということも分かっています。
しかし、この不平等が続けば、負荷の強い役割を負う人にとって、企業全体として健全に機能するのに必要なコミュニケーションネットワークを維持するのが難しくなります。組織の活動の中心にいると感じない従業員の間で、ねたみのような感情が生まれるでしょう。そして、中心となる人々も簡単に疲れ切ってしまうかもしれません。
役割当たりの平均的なコミュニケーションパスの数に対する、最も強い役割が持つコミュニケーションパスの数の比率をコミュニケーション強度比率として定義しなさい。経験的には、この比率が大きくなり過ぎる場合、組織は何らかの不健康さという問題を抱えているようです。
したがって
コミュニケーション強度比率を２以下に保つようにしなさい。（２を大きく下回るのは容易ではないことも分かっています。）そのための最も簡単な方法は、「役割の数を少なくすること（"FewRoles"）」です。また、「プロデューサという役割（"Producer Roles"）」を識別し、疲弊した役割を無くすことも役立ちます。最も中心的な役割へのコミュニケーションを識別し、本当に必要なものは何かを確認することも同じように役に立ちます。
コミュニケーションオーバーヘッドは些細なものではなく、こうしたことが起こっていることを識別するのは容易です。シンプルで直接的な方法により、冗長で誤ったコミュニケーションを無くすことができます。この場合、深い構造や組織の原則といった深いレベルに行く必要はありません。
これ以外の状況はより巧妙で多発的であり、このパターンランゲージにおける別のパターンで検討します。
関数の所有者とコンポーネントの所有者（"Function Owner and Component Owner"）
プロジェクトにおける関数は、コンポーネントをまたいで使用される傾向にあります。プロジェクトのアーキテクチャ（「コンウェイの法則（"ConwaysLaw"）」）にしたがって組織化することの重要性は認識しているでしょうが、事はそう単純ではありません。
* * *
コンポーネントによってチームを組織すれば、関数が被害を受けますし、逆もまた然りです。
コンポーネントの所有者を決めなければ、関数かユースケースによってチームが編成されるでしょう。あるいは、関数やユースケースの所有者を決めなければ、クラスかコンポーネントによってチームが編成されるでしょう。どちらの場合でも、同じ疑問を持つことになります。「２人が同時に同じ関数をプログラミングしたいと思った場合には何が起こるのだろうか？」と。
関数についての所有権と一貫性が求められますし、コンポーネントについても同じ事が言えます。そして、コンポーネントはチームをまたいで共有されなければなりません。
関数の所有者しか割り当てなければ、コンポーネントが複数人で共有され、一意性と一貫性が失われてしまいます。しかし、コンポーネントの所有者しかいなければ、関数は親を失ってしまいます。関数が完成したことを誰が保証するのでしょうか？
したがって、
全ての関数が確実に所有者を持ち、全てのコンポーネントも確実に所有者を持つようにしなさい。
全てのコンポーネントに責任を持った所有者がいること、そして、全ての関数に責任を持った所有者がいることを保証して下さい。コンポーネントの所有者はコンポーネントの一貫性と品質に関する質問に答えますし、関数の所有者は関数が完成することを保証します。コンポーネントの所有者が皆、末端の機能に必要な何かを組み込むことを断った場合には、関数の所有者は必要なコードを関数に特化した場所に置くことになります。
雇われアナリスト（"Mercenary Analyst"）
各国をまわって民謡を収集しているJohn Jacob Niles氏は、アパラチア山脈へ何度も旅したうちのある時、ある女性が特別に美しい歌を歌っているのを聞きました。Niles氏は自分で覚えるまで彼女にその歌を繰り返してもらいました。それが今は有名なクリスマスソングの「I Wonder as I Wander」です。Niles氏は後にこう語りました。「その後、もう一度彼女に会うことはありませんでした。」
...組織のために役割を整理しているとしましょう。その組織が置かれているコンテキストでは、外部のレビューア、顧客、内部の開発者がシステムのアーキテクチャを理解するためにプロジェクトの文書を使おうと期待しています。（ユーザマニュアルは別とします。）設計の記法やそれに関連するプロジェクトのドキュメントを支えるのは、プロダクトの成果物に直接的に貢献している人にとってはあまりに退屈な仕事です。
* * *
技術ドキュメントの作成は、どのプロジェクトもやらなければならない汚れ仕事です。優れたドキュメントを作り、さらにそれをメンテナンスして、そのプロジェクトが後で使えるようにすることは、重要なことです。しかし、こうしたドキュメントを誰が書くのでしょうか。
開発者が自分たちでドキュメントを書こうとすれば、「本当の」仕事の妨げになります。ソフトウェアの納期を守ることは組織にとってお金を意味します。そこで、技術ドキュメントはしかるべき時まで作るのを先延ばしできるものと考えがちです。しかし、「しかるべき時」が来ることは滅多になく、組織がシステムについての優れた技術ドキュメントを内部で持っていなければ、それは重大なハンデになります。
ドキュメントは、書かれるだけで読まれないこともよくあります。
また、エンジニアが優れたコミュニケーションスキルを持っていないこともよくあります。
多くのプロジェクトは設計をするのに、Roseのようなきれいな絵が描けるツールを使用します。優れた絵は優れた設計にとって必要ではありませんが、アーキテクトは巧く描かなければと悩んでしまう可能性があります。
したがって、
必要なドメインについて詳しいテクニカルライターを雇いなさい。しかし、設計自体には関与させないようにしなさい。
この人は適切な記法を用いて設計をとらえ、レビューや利用のために設計を整形して公開してくれるでしょう。
実装するアーキテクト（"Architect also implements"）
現地で作業する、住宅開発の建築家、1942年
...ある組織が、１つまたは複数のマーケットに仕えるため（「組織はマーケットに従う（"Organization Follows Market"）」）に作られたとしましょう。時間が経つにつれて、プロジェクトはそのマーケットをカバーし、スムーズな進化を保証するのに必要なアーキテクチャ上の広がりを求めますが、そうしたものは、実践的なエンジニアリングや実装の関心に目をつぶることができません。さらに言えば、概念的な一貫性を保とうとすれば、プロジェクトは実装を理解した上で、アーキテクチャ上のビジョンを実行する必要があります。
* * *
ソフトウェアプロジェクトは、深みや実践的な注意を犠牲にすることなくリーダーシップのスコープを広げなければなりません。開発者は個別の設計や実装上の意思決定を行うことは得意かもしれませんが、プロジェクトには全体を導くような技術的方向性に関する戦略が必要です。これは通常アーキテクトによってもたらされます。しかし、あまりに多くのソフトウェアアーキテクトは、自身の思考や方向性を抽象的なものに限定してしまいます。しかし、抽象的なものというのは、無知の訓練された形式にすぎません。あまりに多くのプロジェクトはパフォーマンスやAPIの巧拙、コンポーネント間の相互作用といった「詳細」で失敗するのですし、良くてもこうした問題を後になって見つけるのです。
もし、計画で全て分かっていれば、こうした問題を全体主義的なコントロールによって解決できるでしょう。しかし、もしそれが可能であったとしても、全体主義的コントロールは、ほとんどの開発チームから過酷すぎる手法と見られています。
正しい情報が適切な役割を持った人の間を流れなければなりません。特に、開発者は戦略的なビジョンを理解し、実装に関する責任を持たなければならないのです。アーキテクトはアプリケーションの必要性を理解し、さらに長い目で見た時に、システムの構造に対してそれが何をもたらすかを理解しなければなりません。同じことはある程度開発者にも言えます。しかし、戦略的な方向性という中心的な軸がなければなりません。それによってプロジェクトが停滞するのを防いだり、必要な詳細に手が入れられることを保証したり、あらゆるピースを全体へと統合するような「調和」が現れてくるのを追跡できなければならないのです。この「調和」には、コンポーネント間の相互作用やプロトコル、API、性能、信頼性への関心といった低水準の詳細を理解することが必要であることもあります。
したがって、
アーキテクトは開発者にアドバイスしたり、コミュニケーションしたりするだけでなく、実装に参加しなければなりません。
アーキテクトは組織的に開発者と結びつき、自分自身でコードを書かなければなりません。開発者に混じって「ペアプログラミング（"Developing in Pairs"）」をするのもよいでしょう。
私の許可なしには、誰もここを通しませんよ！
「マネージャは、カーリングにおけるスイーパのようなものでなければなりません。スイーパは石の前を走り、石が妨げられず、スムーズに進めるように進路からゴミを取り除くのです。あなたのマネージャはこういうことをやっていますか？」
残念ながら、これと同じ領域で人間を酷使すると、困った人と普通の人が干渉し合って普通の人が傷つき、マネージメントは困った人に対してアクションを取らなければなりません。-- ボールダーマウンテンパーク入り口でのサイン、コロラド州ボールダー
...開発者の組織が、社内や社会的コンテキストの内部で形成されたとしましょう。そこで開発者は同僚や出資者、顧客、その他「外部の人」によってあれこれ見られます。プロジェクトの実装者はインプットを与えたり批判したりしなければならないと感じる外部の人によって、よく妨害されます。
* * *
プロジェクトにおける低水準の場所に関係することによって「手伝う」必要があると感じているステークホルダをなだめることが重要です。それによってプロジェクトの完成に向けて動いている開発者やその他の人の邪魔になることを防げます。
孤立していてはうまく行きません。したがって情報の流れは重要です。しかし、コミュニケーションオーバーヘッドは外部の協力者が増えるに従って加速的に上昇します。
多くの中断はノイズになります。
成熟と進捗は、効果的にコントロールされていることよりも、コントロールしていることと強く関係します。
したがって、
外部の役割から個人的に干渉されないよう、開発している個人を守る「マネージャという役割（"ManagerRole"）」を作りなさい。このロールが持つ責任は「害虫を寄せ付けないこと」です。
開発者がプロセスをコントロールする（"Developer controls Process"）
熟練した職人がワンタッチ式燃料タンクを作るための効果的で効率的なプロセスを考案している。第二次世界大戦
...まだ成熟していないドメインに、ある新しいマーケットのためのソフトウェアを構築しようと、組織がつくられたとします。進捗は「非形式的な労働計画（"InformalLaborPlan"）」によって、指標化されます。必要な役割が定義され、最初にスタッフが割り当てられます。
* * *
開発文化は、他の文化と同様、プロジェクトの方向性とコミュニケーションに関する焦点を認識することで恩恵を受けます。うまく行っている組織は中央集権化されたコントロールを最小限にして、有機的なやり方で機能しています。しかし、役割に埋め込まれた重要な焦点は存在します。これは考え方、要件、制約を相互に結びつけ、テスト、パッケージング、マーケティングしてユーザの元に届く成果物を作り出すものです。
全体主義的コントロールは、ほとんどの開発チームから厳格すぎる手法だと考えられます。正しい情報が適切な役割の間を流れなければなりません。分析、設計、実装を通じて情報の流れをサポートする必要があるのです。
開発者はエンドユーザから見える成果物に直接貢献しますので、プロダクトに責任を持つのに最適な地位にいます。あらゆる役割の中で、開発者はプロダクト開発における最大の利害を、他のどんな役割よりも多くのフェーズにおいて持っているのです。そして、コントロールなしに責任はありません。同じように「マネージャという役割（"Manager Role"）」にも、ある程度の責任がありますが、それはユーザから見える成果物を届けるのを間接的に支援するという役割の程度に応じたものです。これらはプロセスの課題となります。
したがって、
開発者をプロセスに関する情報の焦点としなさい。「組織がマーケットに従う（"Organization Follows Market"）」の精神に基いて与えられた機能について、開発者をプロセスのハブに置きなさい。機能というものはシステムの機能性（ソフトウェアにおいて広く実装されたもの）を構成する単位であり、個別にマーケティングされ、顧客が買おうと思うものです。開発者が担うべき責任には、要件を理解し、ソリューションの構造とアルゴリズムについて同僚とレビューし、実装を構築し、ユニットテストを行うというものです。
このエンドツーエンドのソフトウェア開発プロセスにおいて、開発者は全活動の中心となっているのです。
「マネージャという役割（"Manager Role"）」のような、別のハブも存在しますが、開発者ほどには中心的な役割を果たさないということを付記しておきます。
この組織パターンのJames O. Coplien氏は、
DCIアーキテクチャでも有名な方です。そのCoplien氏によるScrumの
セミナーが今年12月に予定されています。
このセミナーについては、以下のブログに詳しい情報が紹介されています。
