パターン29:仕事は内向きに流れる   

図6 上図の組織は、内向きの入力の健全な分布を持つている。下図の組織は、中心部が過負荷となっており、仕事の要求が外に向かうことになる。上図の組織では、コアの役割の人達が仕事をするが、下図の組織では、コアの役割の人達は仕事を作り出す。

問題:

製品に直接的な価値を与えるような作業は、オーソライズされた役割によってなされるべきである。

コンテキスト:

情報の流れを分析できる既存の組織において。その組織は管理上の照査順を示している。

影響する事柄:

いくぶんかの統制と方向付けが必要である。

ソフトウエアの生産におけるシステムの作業上でのボトルネックは、あるとしたらシステムの中心になるに違いない(上記の2つの図の意味において;図の注釈参照)。もし組織の中心である情報交換の中心が、自分達がする以上の仕事を作り出したら、その組織のパフォーマンスは、予測できなくなくなり、偶発的になる。

開発者は、ファイアーウオールゲートキーパーのパターンによって、すでに市場の要求に敏感になっている(この機能のためには、中心となる役割は不要である)。

解決策:

仕事は顧客によって作られ、支援的な役割によってフィルタリングされ、そして中心の実装専門家によって開発されるべきである。マネージャーを相互作用グリッドダイアグラムの中心においてはならない。彼らは、過負荷になり、よく考えられていないような決定を下し、最後には日々の活動を考慮しないというような決定をするであろう。

結果として生じるコンテキスト:

相互作用グリッドダイアグラムの対角線の上よりも下に作用点が多いような組織になる(図は作成中)。

論理的根拠:

KatzとKahnの組織分析は、統制の行使はゼロサムゲームでないことを示している [Katz & Kahn, p. 314]。

仕事はプロセスの中心に焦点をあてるべきで、プロセスの中心は付加価値のある活動に焦点をあてるべきである(開発者はプロセスを統制するのパターン参照)。

プロのマネージャーによって運営される組織は、繰り返し可能なビジネスプロセスを持つ傾向があるが、エンジニアによって運営される組織と同等の生産性には達していないようである。プログラマーが中心的な役割を演ずる組織では、付加価値を作り出す役割はプロセスの中心にいる(開発者はプロセスを統制するアーキテクチャ設計者もソフトウエア実装に参加するのパターン参照)。マネージャーは、これらの役割を活用し支援すべきである(パトロンファイアーウオールのパターン参照)。

Mackenzieは、このパターンをMカーブを使って特徴付けている。Mカーブは、全作業プロセスの中に占める規約上の作業プロセス(計画、運営指揮、実行)のパーセンテージを、分類の関数としてモデル化したものである[Mackenzie]。

論理的根拠は、実際にあるプロジェクトの経験的な観察によって支持されている。

とはいうものの、マネージャーはビジネスプロセスにおいて日々の決定をしなければならないし、“病原菌から守る”ために責任にしたがわなければならない(ファイアーウオールのパターン参照)。