Coplienの開発工程の生成的パターン言語を読むpart1

コプリエンの組織パターンを読み直している。
XPやScrumが生まれる前に、アジャイル開発の構造をパターンという形で既に明確に定義しているように思えた。
理解できたパターンをラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
生成的開発プロセス・パターンランゲージ　Introduction

生成的開発プロセス・パターンランゲージ　patternindex.htm - info

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

パターンランゲージの形式と正当性: プログラマの思索

組織パターンとプロセスパターン: プログラマの思索

【1】組織と環境の依存関係

アーキテクチャは組織に従う　Conway's Lawが一番有名だろう。
コンウェイの法則が出てきた由来としては、コンパイラを4つのチームで作ったら、4パスコンパイラで作られてしまい、複雑な構造になってしまった、という話が有名だ。

「もし、早すぎる時機に組織をアーキテクチャに合わせると、アーキテクチャの変化の流れは個々人の統制の範囲の間での干渉を引き起こす。」という言葉は、アーキテクチャ設計が固まる前に大人数で開発に取り掛かると、その組織構造を反映した複雑なソフトウェアを作ってしまう、という意味だろうと思う。
つまり、アーキテクチャが固まるまでは少数精鋭で設計し、アーキテクチャが固まった後に開発チームを組むといいことを示唆しているのだろう。

他に組織と関連するパターンとして、組織は場所にしたがう　Organization Follows Locationや組織は市場にしたがう　Organization Follows Marketがある。

【2】組織に必要な役割

コプリエンの組織パターンで面白いと思った点は、象徴的な役割を抽出していること。
パトロン　Patronとは、開発チームには擁護者が必要というパターン。
パトロンの役割は、「パトロンは進捗を妨げるようなプロジェクトレベルでの障壁を取り除く責任があり、組織の“戦意”（うまくいっているという感じ）維持の責任を持つ」。
開発チームを保護する経営者ないしプロマネが相当するだろう。

ファイアーウォール　Firewallsとは、開発チームを邪魔する害虫から守る守護者が必要というパターン。
「この役割の責任は“病原菌を遠ざける”ことである」という言葉がとても分かりやすい。
スクラムマスタがその役割に相当するだろう。

門番　Gatekeeperとは、開発者・顧客・上司の間で情報を翻訳して説明する役割。
「この人は、外部からの最新の情報や雑多な情報をプロジェクトに関連する言葉に翻訳してプロジェクトメンバーに広める。(中略)この役割は、開発とマーケティングや全社管理組織とのインタフェースを管理することもできる。」という言葉から、ソフトウェアプロダクトラインのアーキテクトという役割を連想させる。
システムをユーザ目線で顧客価値の観点で話すときもあれば、開発者目線で実装レベルで話すときもあるし、上司にはコスト面やアーキテクチャ設計の観点で話すときもある。
それぞれの立場の人に複数の観点で情報を翻訳する能力を必要とする。

「ゲートキーパーは有用な情報の流れを促進するパターンである。一方、ファイアーウオールは価値のない情報の流れを制限する。」という指摘から、小規模チームではプロジェクトリーダーがアーキテクトの役割も担う時が多いため、プロジェクトリーダーは数多くの役割を果たさなければならない事が分かる。

【3】開発者の役割を重視

開発者はプロセスを統制する　Developer Controls Processとは、機能別に開発者をプロセスの中心に置くこと。
つまり、システムの機能ごとに担当された開発者が責任と大きな権限を持つことを意味する。

「設計は作業全体のことであり、設計者と呼ばれるような役割はない。」「完全に理解できていない設計分野であり、開発にとって繰返しがキーとなっている。」というコンテキストから、設計・開発・テストのような工程ごとに分断した開発スタイルはソフトウェア組織に向いていないことを示唆している。
XPやScrumから始まったアジャイル開発では、開発者が開発チームの中心であり原動力であることを強調しているが、それはこのパターンでも裏付けられる。

【4】アーキテクトの役割

とはいえ、開発者とは異なるアーキテクトという役割もソフトウェア組織では必要とされる。
開発者はプロセスを統制する　Developer Controls Processとアーキテクチャ設計者は製品を統制する　Architect Controls Productのパターンは表裏一体。
「経験的にいえば、彼らは危機的な状態を除けばプロセスを統制しているようには見えない。開発者はプロセスを統制し、一方、アーキテクチャ設計者は製品を統制する。」という言葉は、アーキテクトは正しい製品を作る役割であり、開発者は製品を正しく作る役割であることを示唆している。

「彼らは、要求仕様を理解し、システム構成の大枠を決め、その構成の長期的な進化を統制する責任を持つ。」という言葉から、アーキテクトはアーキテクチャ設計に大きな役割を持つ。

但し、この2つのパターンだけを強調すると、アーキテクトは開発チームでかなり大きな権限を持ち、開発者との間で緊張関係をもたらす。
そのため、アーキテクチャ設計者もソフトウエア実装に参加する　Architect Also Implementsやアーキテクチャをレビューしなさい　Review the Architectureのパターンで、その緊張関係を柔らげるように組織パターンでは勧めている。
「全体主義的なアーキテクチャ設計者に対して恨みが発生することもある。このような傾向をやわらげるためには、アーキテクチャをレビューしなさいのパターンなどを利用しなさい。」

【5】名前が付けられた安定したバージョン　Named Stable Basesは、ブランチ上のリリースタグやリリースバージョンを意味しているように思う。
「結合と結合の間の時間が長すぎると、以前の結合バージョンの制約により、開発者の進捗が滞ってしまう。」ために、1週間ごとにリリース可能な品質のバージョンを用意することを勧めている。
「安定の度合いに応じて、同時に複数個の結合バージョンを持つことが有効である場合がある。」
「例えば、あるAT&Tのプロジェクトは、毎晩ビルドし（コンパイルされたことが保証されているのみ）、週毎に結合テストのためにビルドし（システム全体に渡る確認テストが保証されている）、そして（隔週程度で）テスト完了版のビルド（QAのシステムテストに対しても十分安定なもの）を提供した。」

XPのイテレーション、Scrumのスプリントの源流は、このパターンにあるのではないか？
なぜなら、「変更が１週間に１回を超えないように、システムインタフェース（アーキテクチャ）を安定させなさい。システムインタフェース以外の部分についてはそれより頻繁に変更があってもいいし、結合されてもよい。」という言葉から、安定した開発を行うには、定期的な間隔でシステムインタフェース（アーキテクチャ）を安定させる必要があるからだ。
そうでなければ、デグレードなどの症状が多発して品質が劣化しやすくなり、いつまで経っても安定したソフトウェアにならないことを示唆しているように思える。

【感想】
僕はまだコプリエンの組織パターン42個を全て理解はしていない。
でも、幾つかのパターンを読んでみると、自分の経験上、過去にこんな場面があったな、とか、過去にこんな問題があったな、とか、過去にこんな解決方法を知っていればもっと明確に説明できたのに、というデジャブ(既視感)を感じた。

Scrum: 超生産的ソフトウェア開発のための拡張パターン言語を読むと、Scrumが編み出したスクラムマスタ・プロダクトオーナ・バックログ・スプリントレビュー・デイリースクラムが有効である理由は、組織パターンから説明できると簡単ではあるが概略が示されている。
読んでいてとても面白い。

【追記】
2013年1月にCoplienが来日するらしい。
時間が取れれば行きたいなあ。

Scrum Alliance Regional Gathering Tokyo 2013

【追記2】
2004年に続編「Organizational Patterns of Agile Software Development」が出版されている。

Organizational Patterns of Agile Software Development pdf free ebook download from artax.karlin.mff.cuni.cz