Project

General

Profile

組織パターン

パターン 解決策
パターン１：組織の規模を決める
Size the Organization		 デフォルトとして10人を選びなさい。適切に選ばれた教育を受けた人の小さなチームは、31ケ月で1,500KSLOC、15ケ月で200KLOC、8ケ月で60KSLOCのソフトウエアを開発できることが経験上わかっている。開発の後の方の工程で人を増やしてはならない。最終期限を、完成日から計算しなおした日に合わせるように試みなさい。
パターン２：自己選抜チーム
Self-selecting team		 経歴と幅広い知識を基本として厳しくふるいにかけ、自己選抜チームを作りなさい。
パターン３：ソロ名音楽家
Solo Virtuoso		 すべての設計と実装を１人か２人の人にやらせなさい。
パターン４：スケジュールの期間を決める
Size the Schedule		 スケジュールが守れた時には金銭的なボーナス（あるいはリスク保証で；成功を補償するのパターンを参照）あるいは余分な休暇で開発者に報いなさい。２つのスケジュールを用意しなさい。１つは市場に対するもので、もう１つは開発者向けである。外部のスケジュールは顧客と交渉でき、内部のスケジュールは開発者と交渉できる。普通のプロジェクトであれば、内部スケジュールは外部スケジュールよりも２～３週間短くなければならない（この数字はソフトウエアコンサルティング会社のシニアスタッフによるものである）。もし２つのスケジュールが調停できない時は、顧客の要求あるいは組織のリソース（あるいはスケジュールそのもの）が再交渉されなければならない。
パターン５：形式は機能にしたがう
Form follows Function		 密接に関連のある活動をグルーピングしなさい（すなわち、実装においてお互いに関わり合いを持つもの、同一の成果物を操作するようなもの、あるいは意味論的にいって同一の分野に関連するものなどを）。グルーピングした活動から起因する抽象化した名前をつけ、それを役割にしなさい。関連する活動は、その役割の責任（職務分掌）となる。
パターン６：役割に合ったその分野での専門知識
Domain Expertise in Roles		 根拠のある経歴を持つ分野に合った専門家を雇いなさい。ある人は複数の役割を担当できるかもしれない。多くの場合、１つの役割のためには複数の人を必要とする。プロセスについてよりも分野についての訓練のほうがより重要である。アプリケーション専門知識から手法や言語の専門知識にいたるあらゆる分野において、職場のグル(guru：宗教教師)がいるといい。
パターン７：段階的な補充
Phasing it In		 採用計画を段階的にしなさい。専門家を最初に雇い、プロジェクトが成長するにしたがって人を増やしなさい。
パターン８：見習い
Apprentice		 見習い方式にしたがって新たに集めた人を専門家達の中に配置しなさい（役割に合ったその分野での専門知識のパターン参照）。ほとんどの場合、見習い期間は６ヶ月から１年間は必要である。パラダイムシフトを起こすのに必要となる時間だけ必要とする。
パターン９：組織は場所にしたがう
Organization Follows Location		 組織構成の分割は、地理的な分割を反映すべきである。逆も同様である。組織構成上の責任は、決定が（地理的に）ローカルに行えるように割り当てられるべきである。
パターン１０：組織は市場にしたがう
Organization Follows Market		 いくつかの異なった市場をカバーするように考えられた組織においては、市場構造を開発組織に反映することが重要である。すべての市場分野をまたがって共通な部分のみをサポートするような、“核”となる組織を意識的に作るという強力なパターンは、しばしば見落とされる。Ralph Johnsonは、これをフレームワークチームと呼んでいる。この組織を前面に置くことが重要である。
パターン１１：開発者はプロセスを統制する
Developer Controls Process		 ある機能に対して、開発担当をプロセスの中心におきなさい。機能とは、別々に市場に出すことができ、顧客が喜んで買うような製品単位（主としてソフトウエアとして実装されたもの）である。開発者は、プロセス情報についての手形交換所である。開発者の責任には、要求仕様を理解すること、解決策となるソフトウエア構成とアルゴリズムを仲間と一緒にレビューすること、実装を組み合わせること、単体テストを含む。
他にも中心があってもかまわない。
パターン１２：パトロン
Patron		 プロジェクトの要因を擁護してくれる明らかに高レベルのマネージャーにプロジェクト参加してもらいなさい。パトロンはプロジェクトにおける判断の最終調停者になり得るし、その判断は組織が迅速に判断するための加速力となる。パトロンは進捗を妨げるようなプロジェクトレベルでの障壁を取り除く責任があり、組織の“戦意”（うまくいっているという感じ）維持の責任を持つ。
パターン１３：アーキテクチャ設計者は製品を統制する
Architect Controls Product
Planning and Architecture		 アーキテクチャ設計担当者をアサインしなさい。アーキテクチャ設計担当者は開発者達にアドバイスし彼らを統制し、そして彼と密接に情報交換しなければならない。アーキテクチャ設計担当者は、顧客とも密接な関係でなければならない。
パターン１４：Conwayの法則
Conway's Law
Organization Follows Architecture
Architecture Follows Organization		 組織を製品のアーキテクチャに当てはまるようにしなさい。このパターンランゲージにおいて、ここでは、組織がアーキテクチャに影響をおよぼすべきであるというよりも、アーキテクチャが組織に影響をおよぼすべきであるといえるだろう。
パターン１５：アーキテクチャ設計者もソフトウエア実装に参加する
Architect Also Implements		 アーキテクチャ設計者は、開発者にアドバイスしたり情報交換するだけでなく、ソフトウエア実装にも参加すべきである。
パターン１６：アーキテクチャをレビューしなさい
Review the Architecture		 すべてのアーキテクチャ上の決定は、すべてのアーキテクチャ設計者によってレビューされるべきである。アーキテクチャ設計者は、お互いにコードをレビューし合うべきである。レビューは、たとえ毎日であろうと、プロジェクトの初期に頻繁に行われるべきである。レビューは、最低限の資料で非公式に行うべきである。
パターン１７：コード所有者
Code Ownership		 システムの中のそれぞれのモジュールを一人の開発者に所有させるようにする。例外的あるいは明確な状況である場合を除き、コードはその所有者によってのみ修正してよい。
パターン１８：アプリケーション設計はテスト設計の制約を受ける
Application Design is Bounded By Test Design		 要求仕様のシナリオが顧客に合意された時点で、シナリオに基づくテスト設計が始まる。テスト設計はソフトウエア設計と同時進行するが、顧客のシナリオにのみ対応すればよい。テスト者には、ソフトウエア自身を使用することはできないからである。アーキテクチャ上のインタフェースが安定したと開発者が決定した時に低レベルのテスト設計とテスト項目決定を進めることができる。
パターン１９：QAの参加
Engage QA		 QAに中心的な役割をさせなさい。何かテストできるようなものが出来次第、QAと開発とを強い関わり合いを持つようにしなさい。テスト計画の作成はコーディングと平行して進めることができるが、開発者はテストを開始していいかどうかを宣言しなければならない。
QA組織はプロジェクトの外側に位置づけるべきである。すなわち、テストの計画と報告の責任は開発組織にあってはならない。
パターン２０：顧客の参加
Engage Customers		 QAだけでなく開発者やアーキテクチャ設計者にも密接な関わり合いを持つような役割を顧客に与えなさい。
パターン２１：グループによる妥当性確認
Group Validation		 QAが参加する前であっても、開発チーム（顧客を含む）は設計の妥当性を確認することができる。CRC設計技法のような技法やグループによるデバッグは、問題を顕在化し解決するのに役に立つ。
妥当性確認チームのメンバーは、共通なソフトウエア欠陥の分類に帰因するような根本原因を解決するためにQAと協力することもできる。
パターン２２：シナリオは問題を明らかにする
Scenarios Define Problem		 Jacobson式に、システム要求仕様をユースケースとして取り込みなさい。
パターン２３：雇われ分析者
Mercenery Analyst		 必要とする分野で熟練しており、設計そのものには利害関係のないテクニカルライターを雇いなさい。この人は、適切な表記法で設計を把握し、設計ドキュメントを定型化し発行してくれる。そして、その設計ドキュメントはレビューなどによりその組織で利用される。
ドキュメントそのものは、できるかぎりオンラインで管理されるべきである。そして、常に最新の状態に保たれていなければならない（したがって雇われ分析者はフルタイムとなる）し、顧客のシナリオに関連付けられていなければならない（シナリオは問題を明らかにするのパターン参照）。
パターン２４：ファイアーウオール
Manager
Firewalls		 開発している人達に対しての外部からの干渉を防ぐような役割として、マネージャーを割り付けなさい。この役割の責任は“病原菌を遠ざける”ことである。
パターン２５：ゲートキーパー
Gatekeeper		 A型の性格を持つプロジェクトメンバーがゲートキーパーの役割として立ち上がる。この人は、外部からの最新の情報や雑多な情報をプロジェクトに関連する言葉に翻訳してプロジェクトメンバーに広める。そのゲートキーパーは、プロジェクト情報を関連する外部の人に漏らしてもよい。この役割は、開発とマーケティングや全社管理組織とのインタフェースを管理することもできる。
パターン２６：回覧の範囲を決める
Shaping Circulation Realms		 好ましい分類法を反映するような構成を持つ階層構成あるいは照査順を創り出すような肩書きを与えなさい。
役割の間での適切な相互作用が思い浮かぶような仕事上の責任を与えなさい（責任を移動も参照のこと）。
あなたが緊密な情報交換が必要であると望んでいる人達を物理的に同じ場所に配置しなさい（これは、組織は場所にしたがうのパターンと対をなす）。
皆に、何をすべきかと、誰と相互作用すべきかを話しなさい。もしあなたが彼らの権限と力の範囲内で理にかなった何かをしてもらうようにお願いすれば、ほとんどの場合、彼らはあなたの意志を尊重しようとするであろう。
パターン２７：責任を移動
Move Responsibilities
Load Balancing		 最も好ましくない関わり合いを作り出している役割から、他のプロセスでその好ましくない関わり合いに関係している役割に、責任を移動させなさい。簡単にいえば、これは負荷バランスをとることである。責任は任意に移動されるべきではない。チーフプログラマーチーム組織はこのパターンを実現するためのよい方法である（開発者としての責任という意味で）。
パターン２８：バッファローの山
Buffalo Mountain		 サブパターン１：プロジェクトに関するいかなる重要な相互関係においても、２つの協力関係にある役割の組織の中心からの距離の和は、組織の全体をカバーするのに必要な最短の距離以下でなければならない。
サブパターン２：もし組織の仕事に50％程度しか関与していない離れた立場にあるのなら、隣の位置にいる人（あなた自身のようにプロセスの中心から等距離にある人達、すなわち、全体としてあなたと同程度にプロセスに関わり合いを持つ人達）との関わりを避けなさい。
サブパターン３：いかなる相互関係の強さも、それぞれの役割のプロセスの中心からの距離の差の合計に逆比例すべきである。
手段A:上記の３つのサブパターンを効果的にするために、関連する協力関係が移動するように、役割の間で責任を入れ替えなさい（責任を移動のパターン参照）。これはRobert Laiのアイデアである。単純ではあるが大いに効果がある。
手段B:情報交換の機会を増すような物理的な位置に人々を配置しなさい（仕事は内向きに流れるパターン参照）。
手段C:プロジェクトにおける役割の統制の範囲を広げなさい（複数の役割を1つの役割に集めるということに似ている）。類似した責任を持つ役割を一緒にするというのは多分一番いいであろう。あるいは、類似した協力関係にある役割をいっしょにするのもよりよい方法であろう。そうだ、これらもパターンだ。
パターン２９：仕事は内向きに流れる
Work Flows Inward		 仕事は顧客によって作られ、支援的な役割によってフィルタリングされ、そして中心の実装専門家によって開発されるべきである。マネージャーを相互作用グリッドダイアグラムの中心においてはならない。彼らは、過負荷になり、よく考えられていないような決定を下し、最後には日々の活動を考慮しないというような決定をするであろう。
パターン３０：１つの役割に３人から７人の援助者
3 to 7 Helpers per Role		 各々の役割に対して、３人から７人の援助者になるようにしなさい。
パターン３１：名前が付けられた安定したバージョン
Named Stable Bases		 変更が１週間に１回を超えないように、システムインタフェース（アーキテクチャ）を安定させなさい。システムインタフェース以外の部分についてはそれより頻繁に変更があってもいいし、結合されてもよい。
パターン３２：分割統治
Divide and Conquer		 お互いに関わり合いの強い役割のあつまりで、組織の他の部分とは緩い関わり合いを持つような役割の集合を見つけなさい。そして、それらの役割のあつまりを囲むように別の組織とプロセスを形成しなさい。
パターン３３：工程の分割
De-Couple Stages		 よく知られた成熟した分野では、ステップをシリアルに並べなさい。ステップ間の境界は、よく知られたインタフェースにしたがわなければならない。このことにより、１つあるいはいくつかのステップを自動化することができるし、未熟なスタッフでもステップを遂行できるような形態を作り出すことができる。
パターン３４：ハブ・スポーク・リム
Hub-Spoke-and-Rim		 個々のプロセス活動を指揮できるように、それらのプロセスの役割と中心にいる役割をリンクしなさい。もし、中心にいる役割が活動をコントロールすれば、平行処理はさらに活発になる。
パターン３５：芸術的パターン
Aesthetic Pattern		 そのプロジェクトが市場を維持し、生き残り、成長するにつれて、それぞれの部分が１つの部門に成長できるように、その組織を分割しなさい。
パターン３６：関わり合いは遅延を少なくする
Coupling Decreases Latency		 役割当たりの関わり合いの比率を全般的に上げるように、役割の間でのオープンな情報交換の経路を確立しなさい。特にプロセスの中心にある役割との間での情報交換の経路が重要である。役割の間での情報交換は、仕事は内向きに流れるや責任を移動のパターンを用いて形成することができる。
パターン３７：プロトタイプ
Prototype		 要求仕様を理解するためのプロトタイプを作りなさい。プロトタイプは外部インタフェースにとっては非常に有用である。プロトタイプは使い終わったら捨てなさい。
パターン３８：小さなスケジュール変更をするな
Take No Small Slips		 「我々は、“人月の神話”から、小さなスケジュール変更をするなによってうまくやっていく方法を見つけた。毎週、クリティカルパス（最低限）の実績が、計画にどれだけ近いかどうかを計測しなさい。もし３日間の遅れなら、３日間の“幻の索引”を追跡しなさい。もし幻の索引がばかばかしすぎるようになったら、スケジュールをずらしなさい。これは、スケジュールをかき回すのを避けるのに役立つ。」･･･　1994年６月のPaul Chisholmとの個人的な議論から。
パターン３９：ペアで開発
Developping in Pairs
Two heads are better than one		 気の合った設計者をペアにし、一緒に仕事をさせなさい。一緒に仕事をすると、２人の能力の和以上の能力を発揮できる
パターン４０：割り込みは閉塞状況を解除する
Interrupts Unjam Blocking		 もし、あるクリティカルなリソースのためにある仕事が停滞しそうな時は、そのリソースを与えようとしている仕事に割り込みなさい。そうすれば、あなたは停滞から解法されるでしょう。もしオーバーヘッドが十分小さいのなら、スループットには影響しない。常に局所的な遅延を改善する。
パターン４１：割り込みをやめるな
Don't Interrupt an Interrupt		 もし、誰かが割り込みは閉塞状況を解除するのパターンによって引き起こされた仕事をしているのなら、その人は、その仕事が終わるまでは、さらなる割り込みのために仕事を中断してはならない。
パターン４２：成功を補償する
Compensate Success		 成功裏にプロジェクトを立ち上げたり終了させたりしたことに貢献した個々人のために、気前のいい報奨を用意しなさい。チーム全体（公的な単位）がそれなりの報奨を受けるべきである。さもなければ、自分の給与と仲間の給与と比較することによって自分の価値を判断してしまい、動機を失ってしまうかもしれないからである。
特別な人は、チームのパフォーマンスにはあまり関係なく、例外的な報奨をもらってもよい。
祝福は、特別に効果がある褒美である[Zuckerman and Hatala]。

出典

PLoPD1 @ James O. Coplien
生成的開発プロセス・パターンランゲージ