Project

General

Profile

Coplienの組織パターン

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

出典

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