[ホームへもどる]

組織パターンとプロセスパターン

1999/06/11 石井 勝

はじめに

組織パターン(Organizational Pattern)，プロセスパターン(Process Pattern)はソフトウェア開発をすすめる上で開発チームや開発の進め方、開発者間のコニュニケーションをより円滑に行う方法など，ソフトウェア開発のマネージメントについて記述されたパターンです．このパターンは，James O.Coplienによって提唱され(1994年[文献A])，現在も引き続き研究が行われています[文献B]．

組織パターンは，開発チームをどう編成すればいいのかということについて，プロセスパターンは開発プロセスどう進めていくかについて言及されており，両者には密接な関係があります．しばしば両者を一まとめにして組織パターンあるいはプロセスパターンと呼ばれている場合もあるようです．

特徴としては，より建築家アレクサンダーのパターン・ランゲージに近いということがいえるでしょう．実際，Coplienの組織パターンでは、関連するパターンとしてアレクサンダーのパターンを挙げている個所がいくつかあります．GoFのデザインパターンは単なるカタログであるという側面が強いのですが，組織・プロセスパターンの多くはパターンどうしが密接に関連しあうパターン・ランゲージの形をとっています．

Coplienの組織パターンは、実際に何十という開発チームを調べ，その中で成功している開発チームにはどんなパターンが現われているかという調査にもとづいて書かれています．このパターン・ランゲージは全部で40程度のパターンから構成されています．

ソフトウェア分野におけるパターンはオブジェクト指向のコミュニティにおいて発生してきたものですが，Coplienのパターン・ランゲージはそれほどオブジェクト指向と関連しているとはいえません．強いて言えば，ユースケースについて書かれた"Scenarios Define Problem"のパターン，CRCカードセッションによるレビューを薦めている"Group Validation"のパターンが挙げられるだけでしょう．このことは，ある程度規模の大きいソフトウェア開発のマネージメントにおいては，オブジェクト指向かどうかということはさほど重要ではないということがいえると思います．

ここでは，Coplienのパターンの中からそのいくつかを紹介しましょう．

編成についてのパターン

開発チームをどう編成すべきかというパターンについては，以下のものがあります．まず，最初にチームの規模をどれぐらいにするかというものです．

Size the Organization

10人の開発者を選ぶ．経験上，適切に選ばれ訓練された小規模のチームは31ヶ月で150万行のコードを，15ヶ月で20万行のコードを，8ヶ月で6万行のコードを開発できる．開発の遅い段階で人を追加してはいけない．10人の開発者はスタート時には多すぎるかもしれないが，それはあとから補充された人の負担やコストを避けるためである．

Solo Virtuoso

全体の設計と実装を一人あるいは二人で行う．このパターンは，規模が2万5千行以下のコードに対して適用される．

"Solo Virtuoso"のパターンは，成功した開発パターンとして，優れたプログラマ個人による開発は，何人かを集めたチームより生産性が高いことを示しているといえるでしょう．

開発チームの編成を何を基準にすべきかということについてのパターンは以下のものが挙げられます．

Organization Follows Location

開発が複数の場所で行われるとき，アーキテクチャの分割とその役割は地理的条件を反映しなければならない．その逆も同様．

Organization Follows Market

いくつかの異なった市場に対して開発する開発チームは、市場の構造、顧客のニーズを反映していること．

Conway's Law

組織を製品のアーキテクチャに沿うようにする．

最後の"Conway's Law"のパターンは，「4つのグループでコンパイラを開発させたら、4パスコンパイラが出来るだろう」というConway's Lawにちなんで名づけられています．

開発チームは，開発が進むにつれ規模が大きくなっていく場合があります．次のパターンは，最初どういう具合に人を割り当て，補充していくかといった点について書かれたパターンです．

Phasing It In

エキスパートを最初に雇い、プロジェクトが大きくなるにしたがい段階的に新しい人を導入する．

規模が大きくなっていった場合，ある程度分割していかなくてはなりません．次のパターンは分割統治のパターンです．

Divide and Conquer（分割統治）

組織が大きくなりすぎ簡単には管理できない場合，組織とプロセスをロールのグループで分割する．

ロールについてのパターン

Coplienの組織パターンには，よくロールという言葉が出てきます．開発チームの編成を各担当者に割り当てられたロールという単位で眺め，特定のロールに比重が偏っていないか，ロール間のコミュニケーションがバランスよく保たれているかということについて書かれたパターンが多いといえるでしょう．

次のパターンは，そのロールをどう決めればよいかについて書かれたものです．

Form Follows Function

プロジェクトに明確なロールがないとき，関連する開発作業をグループ化して名前をつけ、ロールをつくる．ロールは、グループ化した開発作業に対する責任をもつ．

Domain Expertise In Roles

業績のあるドメインエキスパートを雇い、各分野に対するエキスパートがその分野の指導者となるようにする．こうして各ロールがうまく機能することを保証する．

各ロールの種類に応じてパターンが用意されています．まずは，デベロッパについてのパターンです．

Developer Controls Process

デベロッパを開発プロセスの中心に置く．

次に，開発マネージャについて書かれたパターンです．

Patron Role

プロジェクトの最終決定を行うパトロン・ロールを作る．パトロンは、プロジェクトの発展を妨げるプロジェクトレベルの壁を取り除いたり、チームのモラルについての責任を持つ．

Firewalls

マネージャ・ロールを作り，開発メンバを外部のロールからの情報や批判から保護する．

今度はアーキテクト・ロールについてです．

Architect Controls Product

多くの人によってデザインされた製品は、エレガントさと一貫性が失われてしまう．そこで，アーキテクト・ロールをつくり，アーキテクトは、デベロッパとも顧客とも親密にコミュニケーションをとる．

Architect Also Implements

アーキテクトは、デベロッパにアドバイスを与えコミュニケーションをとる以外に実装も行う．

マネージャが組織についてのロールであるのに対し、アーキテクトはアーキテクチャに関するロールであると言えます．次のものは，品質保証(Quality Assurance)チームのロールについて書かれたものです．

Engage Quality Assurance

品質保証・ロールを中心におき，開発でなんらかのテストが必要になればすぐ対応できるようにする．テストプランの開発はコーディングと平行して行われるが，デベロッパの方がシステムテストの準備ができたことを宣言する．QAチームは開発プロセスの外にあるべきで，開発チームはテストプラン・報告に関するの責任はもたない．

Coplienの組織パターンでは，顧客そのものもロールとして扱われています．次のパターンはこのカスタマ・ロールについて書かれたものです．

Engage Customers

顧客満足を維持するため，カスタマ・ロールを作る．このロールは，QAではなくデベロッパとアーキテクトに密接に結びついている．

最後に，開発におけるドキュメント作成について専用のロールを作るべき，というパターンがあります．

Mercenary Analyst

直接開発を行っている人にとっては，ドキュメント作成は実作業を妨げることになるので，テクニカルライターを雇う．ドキュメントはできるかぎりオンラインで，常に最新のものでなくてはならない．

プロセスについてのパターン

開発プロセスについて書かれたパターンには以下のものがあります．まずは，スケジューリングの規模についてのパターンです．

Size the Schedule

スケジュールに合うようにデベロッパに何らかの報酬（ボーナス、休暇）を与えること．また、外部スケジュールと内部スケジュールの２つを作り、外部スケジュールは顧客に対して、内部スケジュールはデベロッパに対して用意する．中規模のプロジェクトでは内部スケジュールは外部スケジュールより2,3週間短くする．

ユースケースなどシナリオ主導のプロセスについて書かれたパターンには，次のものがあります．

Scenarios Define Problem

開発資料は，顧客とのコミュニケーションにはあまり役に立たないので，システムの機能要求をユースケースとしてとらえる．

Application Design is Bounded by Test Design

シナリオ主導のテスト設計は，初めて顧客からシナリオ要求が受け入れられたときにスタートする．テスト設計の変更は，顧客のシナリオ要求が変わったときだけ行い，テスターはソースにアクセスできない（テスターは開発者ではなく顧客の視点をもたなければならない）．アーキテクチャに関するインターフェイスが固まってから低レベルのテスト設計・実装にすすめる．

次のパターンは，プロトタイプによる開発です．

Build Prototypes

要求仕様を理解するためにプロトタイプを作る．この目的が終われば，このプロトタイプを破棄すること．

システム設計のレビューや問題点の検証などについてのパターンには，以下のものがあります．

Review the Architecture

アーキテクチャの決定はアーキテクト全員でレビューする．アーキテクトは互いのコードをレビューして、このレビューはプロジェクトの早い時期に頻繁に行う．

Group Validation

顧客を含む開発チームは，CRCカードなどで設計の確認をする．

最後に

以上，Coplienのパターンからいくつかをごく簡単に紹介しました．注意していただきたいのは，これらのパターンはパターン・ランゲージを構成しているということです．つまり，ある一つのパターンだけを取り出してそれに固執すればいいというのではありません．パターンが他のパターンを補完しあっているので，どういうバランスで使うか，あるいはある特定のパターンが成り立つときにのみこのパターンを使うべきである，というようなパターンのコンテクストも知る必要があるでしょう．

Coplienのパターン以外では，プロセスパターンだけに限るとオブジェクト指向色の強いものもあります．

"Patterns for Evolving Frameworks" (Don Roberts and Ralph Johnson)[文献C]は，フレームワークを構築する際にどういうプロセスをとることになるかということについて書かれたパターン・ランゲージです．

このパターン・ランゲージは，まずフレームワークを構築する際に3つのアプリケーションを開発しようという"Three Examples"のパターンから始まり，ホワイト・ボックス再利用（継承による再利用）からブラック・ボックス再利用（オブジェクトの組合せの再利用）への進化の過程としてオブジェクト指向の開発プロセスをとらえています．

これからは，ある程度確立されたオブジェクト指向の開発プロセスをパターン・ランゲージの形式で表わし，プロセス・パターンとして書き直すという論文がどんどん出てくるかもしれません．

参考文献

• [A] Coplien J.O.(1995) "A Development Process Generative Pattern Language" Pattern Languages of Program Design, Addison Wesley Longman, Inc. pp. 183-237

• [B] http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?OrganizationalPatterns

• [C] D.Roberts and R.Johnson, "Patterns for Evolving Frameworks",Pattern Languages of Program Design 3,Chap26,Addison-Wesley,1997

[ホームへもどる] [先頭へもどる]