« Redmine for ITILが解決するもの | トップページ | Antを見直すpart2 »

2013/08/08

コプリエン著のアジャイルソフトウェア開発の「組織パターン」の感想part2

和智さん翻訳・コプリエン著のアジャイルソフトウェア開発の「組織パターン」を読んでいると、気づくことが多い。
ラフなメモ書き。

【参考】
生成的開発プロセス・パターンランゲージ

コプリエン著のアジャイルソフトウェア開発の「組織パターン」の感想: プログラマの思索

【1】コプリエンは、モデルとして安定しないプロセスよりも、モデルとして安定しているロールに着目して、組織パターンを書いた。
何故、ロールに着目したのか?

7.3節「ロールとコミュニケーション」で、組織におけるロールの重要性について述べている。

【1-1】組織の中で何が行われているか、をロールが定義する

組織の中のプロセスは誰かが担当していて、それはロールによって抽象化されて定義される。
担当する作業を組織内の誰にでも実施できるように、アサインできるようにするならば、ロールの定義が作業内容になる。

【1-2】人はロールによってアイデンティティを得て行動できる

開発者、テスター、プロジェクトマネージャなどのロールを与えられて、初めて、その組織内でそのロールを使って振る舞える。

人にふさわしいロールを与えることで、生き生きと見違えるように、能力を伸ばす人もいる。
僕の経験では、若手にはロールを意識的に付与させると、仕事していくうちにそのロールに必要な能力を身につける。

特に、管理職や経営層のように、組織内で権力が大きくなるほど、ロールの影響力は大きくなる。
ロールを付与されることで、ノブレス・オブリージュのように、その社会的地位にふさわしい能力を自然に身に付けるパターンが多いと思う。

それらロールは、プロジェクトや組織を離れても、その人について回る時がある。
その人の能力や性格に見合ったロールはある。
プロセスよりもロールの方が安定している。

【1-3】組織の情報はロールの間を流れる

コミュニケーションは、ロールの間を流れる。
情報の流れは組織の成功・失敗の起因の一つ。

コプリエンによると、調査した組織では、あるロールが存在すること、あるいは、存在しないことに気づいたと言う。
ロールが足りない組織は、そのロールを組織が必要としていないことを意味しているわけだ。

例えば、組織の中で、顧客をロールに組み込んでいない場合、その組織は顧客の問題に対してどれくらい認識しているか、疑問に思える。
これは、顧客の代理人パターンを指すのだろう。

あるいは、アーキテクトというロールがない組織がある。その組織は、ソフトウェアアーキテクチャを軽視している組織なのだろう。
これは、アーキテクトが製品を統制する、アーキテクトもまた実装する、アーキテクチャチームのパターンに相当するだろう。

【1-4】ロールを取り巻くコミュニケーションパスも重要

開発者ロールを中心に組織のコミュニケーションが回っていることが大事。
もし、マネージャのロールを中心に結びついていたら、その組織はマネージャが管理者として干渉しすぎていることを示唆している。

品質管理者のロールが他のロールと結びついていなかったら、きちんとしたシステムテストが行われていないだろう。
その場合、開発組織がシステムテストに価値を見出していない可能性がある。
そうだとすれば、かなりの問題だ。

【2】組織パターンのほとんどは、ロールの性質を説明している。

防火壁(FireWall)、門番(Gateway)、顧客の代理(Proxy)、パトロン、アーキテクト、品質管理者というロールがない組織があったとしたら、そのロールに付随するパターンの効果が実現されていないことになる。
つまり、そのロールが果たすべき作業を、開発組織は軽視しているか、その作業の工程そのものの品質が悪いことを意味しているのだろう。

個人的には、防火壁(FireWall)、門番(Gateway)、顧客の代理(Proxy)というパターン名は、ネットワーク機器を連想させる。
それらのパターンの意味は、まさにネットワーク機器の特徴と同じ。

ファイアウォールは、外部からの不要なアクセスを防ぐ。
防火壁(FireWall)は、ニワトリとブタというScrumの格言の通り、スクラムチーム外の利害関係者からの割り込みや干渉を防ぐ。

ゲートウェイは、通信媒体やプロトコルが異なるデータ(情報)を相互に変換して通信する。
門番(Gateway)は、スクラムチーム外の利害関係者と、適切なプロトコル(外部インターフェイス)を通して、対話できるパイプラインを作る。
門番(Gateway)は、プロジェクトの情報やシステムに関係する用語を、利害関係者とチームの間で翻訳する。

プロキシサーバーは、ネットワークに出入りするアクセスを一元管理し、内部から特定の種類の接続のみを許可したり、外部からの不正なアクセスを遮断する。
顧客の代理(Proxy)は、チームが顧客と頻繁に会えない場合、プロジェクト内に顧客の代理人というロールを作り、課題を明確化したり、解決策のアイデアを出し合う。

このように、防火壁(FireWall)、門番(Gateway)、顧客の代理(Proxy)というロールは、コミュニケーションを遮断したり、促進するために用いられる。
それらロールがあるからこそ、開発者は自分たちの仕事に集中できる。
そうでなければ、外部からの利害関係者やマネージャが常に開発者へ干渉して、開発の生産性や製品の品質に悪い影響をもたらしているだろう。

他にも気づいた点があれば書いてみる。

【追記】
コプリエンさんのつぶやきを見つけた。

Twitter / jcoplien: Nice summary / overview of what org patterns are all about in the new Japanese translation. https://forza.cocolog-nifty.com/blog/2013/08/part2-e61b.html …

|

« Redmine for ITILが解決するもの | トップページ | Antを見直すpart2 »

プロジェクトマネジメント」カテゴリの記事

ソフトウェア工学」カテゴリの記事

プロジェクトファシリテーション」カテゴリの記事

Agile」カテゴリの記事

パターン言語」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« Redmine for ITILが解決するもの | トップページ | Antを見直すpart2 »