パターン23:雇われ分析者

   

 

問題:

設計を技法にそって記述したり関連したプロジェクトドキュメントを書くのは、製品そのものを開発しようとしている人にとっては退屈すぎる仕事である。

コンテキスト:

組織の役割を担う担当者を集めている。現状の組織は、システムアーキテクチャとその内部動作を理解するためにプロジェクトドキュメントを利用しようとしている外部のレビューア、顧客、そして内部の開発者から成る(ユーザードキュメントは別に考えるとして)。

影響する事柄:

もし開発者が彼ら自身のドキュメントを書くと、本来の仕事のさまたげになる。

ドキュメント作成は、単に書くだけのことである。

エンジニアの情報交換のスキルは必ずしも高くない。

アーキテクチャ設計者は、図面の出来栄えに凝りすぎて、その犠牲者になってしまう可能性もある(論理的根拠参照)。

解決策:

必要とする分野で熟練しており、設計そのものには利害関係のないテクニカルライターを雇いなさい。この人は、適切な表記法で設計を把握し、設計ドキュメントを定型化し発行してくれる。そして、その設計ドキュメントはレビューなどによりその組織で利用される。

ドキュメントそのものは、できるかぎりオンラインで管理されるべきである。そして、常に最新の状態に保たれていなければならない(したがって雇われ分析者はフルタイムとなる)し、顧客のシナリオに関連付けられていなければならない(シナリオは問題を明らかにするのパターン参照)。

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

このパターンが成功するかどうかは、雇われ分析者の役割を担うスキルのある人を見つけられるかどうかにかかっている。もし成功したら、プロジェクトの外部の専門家達によって、進捗状況がレビュー(アーキテクチャをレビューしなさいのパターン参照)され監視されるようになる。

論理的根拠:

QPWで実証されている。多くのAT&Tのプロジェクトで証明されている(New Jerseyでのジョイントベンチャでのプロジェクト、交換支援部門での以前の組織でのプロジェクト、その他)。この役割を満たす人を見つけるのはむずかしい。

「もうひとつ陥りやすい傾向がある。きれいな図面そのものが目的となってしまうことがあるということである。図面は人を惑わすことがあるが、うっとりとして図面を人だけでなく、その図面を書いた人も惑わすことが少なくない。その場合、その人は自分自身の作品の犠牲者である。Albetiはこの危険を理解し、アーキテクチャ設計者は絵描きのまねをしてはならないし、生きているような図面を書いてはならないと指摘している。彼によれば、アーキテクチャ図面の目的は、単にいろんな部品の間の関係を図示するだけのものである。多くの今日のアーキテクチャ設計者は理解していないが、Albrtiは、図面を書くためのルールとものを作るためのルールは1つではなく同じものでもなく、前者のマスターが後者における成功を保証するものではない、ということを理解している。」-- [Rybczynski, p. 121].