パターン5:形式は機能にしたがう

  

 

別名:活動の寄せ集めがある役割に集中

 

問題:

プロジェクトの中の役割がうまく定義されていない。

コンテキスト:

キーとなる個々のプロセス活動はわかっている。

影響する事柄:

プロセスを作り上げるには、個々の活動は小さすぎ、活動間の関係は動的すぎる。

活動は、多くの場合、関連した製品や他の分野での相互関係などによって集合をなす。

解決策:

密接に関連のある活動をグルーピングしなさい(すなわち、実装においてお互いに関わり合いを持つもの、同一の成果物を操作するようなもの、あるいは意味論的にいって同一の分野に関連するものなどを)。グルーピングした活動から起因する抽象化した名前をつけ、それを役割にしなさい。関連する活動は、その役割の責任(職務分掌)となる。

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

プロジェクトの部分ごとの役割の定義ができる。ある役割は(例えば、雇われ分析者、開発者)は、このパターンによって導き出されたものというよりも、元からある役割であるといってよい。

論理的根拠:

このパターンの品質はレビューされる必要がある。このアイデアは、1994年の3月に私が参加していた大きなリエンジニアリング作業のプロジェクトで採用されたアプローチから生まれた。

Louis Sullivanは、原始アーキテクチャ・パターンの命名者として賞賛されている建築家である [Rybczynski, p. 162]。

このパターンは、組織は場所にしたがう組織は市場にしたがうアーキテクチャ設計者もソフトウエア実装に参加するなどの構造に関するパターンと相互作用を持っている。顧客の参加のパターンも参照してください。

あるマネージャーは、「プロジェクト管理の監査での私の経験では、あるプロジェクトでは役割(例えばアーキテクチャ設計者という名前の役割)の割り付けが欠けており、あるプロジェクトでは同じ役割に複数の人を割り付けている。後者は、スタッフの混乱を引き起こすので、時に問題が大きい。経験のないマネージャーによるプロジェクトでは、役割の欠落が発生しうる。特にシステムエンジニアについて、このような問題がある。」といっている。