パターン25:ゲートキーパー

   

 

問題:

典型的に内向的であるエンジニアタイプの人との情報交換の必要性については、バランスをとらなければならない。

コンテキスト:

会社あるいは社会的な位置づけで開発者の組織が形成され、開発者達は、仲間、資金提供者、顧客そして他の部外者から細かく調べられている。

影響する事柄:

孤立主義はうまく行かない。情報の流れは重要である。

情報交換のオーバーヘッドは、外部の協力者に数の増加につれて非線形的に増大する。

多くの割り込みは雑音である。

統制されていない状態である時よりも統制されている状態の時の方が、完成度と進捗の相関が強い。

解決策:

A型の性格を持つプロジェクトメンバーがゲートキーパーの役割として立ち上がる。この人は、外部からの最新の情報や雑多な情報をプロジェクトに関連する言葉に翻訳してプロジェクトメンバーに広める。そのゲートキーパーは、プロジェクト情報を関連する外部の人に漏らしてもよい。この役割は、開発とマーケティングや全社管理組織とのインタフェースを管理することもできる。

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

このパターンはファイアーウオールのパターンと平衡し、顧客の参加のパターンを補う(ある意味では、顧客は部外者である)。マーケティングが開発スケジュールを煽るような文化を持つ組織から開発者を守るには、ゲートキーパーファイアーウオールだけでは十分でない。

論理的根拠:

ゲートキーパーは有用な情報の流れを促進するパターンである。一方、ファイアーウオールは価値のない情報の流れを制限する。

ゲートキーパーのパターンの価値は、実際に証明されている。PLoP/94でのこのパターンについての議論では、多くの参加者がゲートキーパーの役割を作ったことが役に立ったといっている。

たいがいは、エンジニアは話下手である。もし効率的な情報交換ができる人が見つかったなら、その人の能力を活用することは重要である。

Alexanderは、ある社会でサブ文化を作るのは重要であるが(たいがいは、我々は、会社あるいはソフトウエア産業のフレームワークの中でサブ文化を作ろうとしている)、そのようなサブ文化は終わらせてはならない、と注意している("Mosaic of Subcultures", [Alexander 8])。 また、Alexanderのパターン"Main Gateways" [Alexander 53]と比較してみてください。Alexanderの''Entrance Transition''のパターンの類推から、ゲートキーパーは もっと密接な接触のために、必要となる入構許可を与えて部外者を開発チームに連れてこようと考える人もいるかもしれない[Alexander 112]。

ゲートキーパーは、Alexanderのパターン''Network of Learning''でのように、“物知り”の役割を果たすことができる[Alexander 18]。

Maranzanoは、多くの場合、同一の人がマネージャーとゲートキーパーの両方の役割を果たさなければならないといっている。なぜなら、マネージャーとゲートキーパーは、情報を必要としている外部の人々との関係が深いからである。