パターン20:顧客の参加

   

 

問題:

顧客満足を維持する。

コンテキスト:

品質保証機能は存在している。そして、仕事を進めるための源泉を必要としている。

影響する事柄:

開発者は、「甲板の上のぐらぐらして固定されていない大砲」とよく言われる。

設計レビューが終わりコーディングが始まった時でさえ、要求仕様の変更が発生する。

顧客の要求仕様が欠けていることは重大な問題である。

顧客は、歴史的に見て開発の主たる活動に関与していない。そのことは、顧客の洞察を発見したり取り入れたりすることを困難にしている。

マネージャーとコーダーの間の関係を信用しなさい。

解決策:

QAだけでなく開発者やアーキテクチャ設計者にも密接な関わり合いを持つような役割を顧客に与えなさい。

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

シナリオは問題を明らかにするプロトタイプのパターンで必要とされるような要求仕様を顧客から発見できるようになる。ファイアーウオールやここであげられていないようなパターンも、このパターンをベースとしている。

論理的根拠:

QPWでの実績がある。[Floyd]、特にその中のReisinとFloydの研究も参照してください。

IBMのJAD(Joint Application Development)のように、いくつかのプロセスや手法は、顧客参加を前提としている。BeckのCRC設計技法のように、顧客参加につながる手法もある。他の手法、特に多くのCASEベースの手法は顧客参加とは無関係であるか、顧客参加が害になる。

このパターン顧客の参加(Engage Customers)での顧客は複数形である。分野全般をサポートし、単一顧客による偏見を避けるためである。

プロジェクトは、結果として生じるコンテキストで説明されたパターンを利用し、顧客と開発者の間の相互干渉を和らげるように注意しなければならない。

“製品の品質を維持”することは、ここで解決する問題ではないことに注意してください。製品の品質は顧客満足の1つの要素であるにすぎない。無視されていると感じた時(時間にして20%)、あるいは対応が乱暴で役に立たないと感じた時(時間にして50%)、顧客は他の会社に移ってしまうということが研究によってわかっている。修理するのに100ドル以上かかるような問題を持つている顧客がいるとして、もし会社がその問題を解決しなければ、たった9%の顧客しか再びその会社からは買わない。また、その問題が伝えられた後すぐに解決できれば、82%の顧客がその会社とビジネスを続ける。(前半はThe Forum Corporationから引用、後半はTraveler's Insurance Company [Zuckerman]から引用。)

Maranzanoは、多分このパターンはこのパターンランゲージの中で、前の方に置かれるべきであろうと注釈している。しかしながら、プロジェクトの役割は最初に決められるということは重要である。特に、顧客と応対する役割や顧客からの入力により仕事をする役割(例えばQA)についてそのようなことがいえる。組織は顧客にサービスするためにあるのだから、顧客が参加する前に組織はできていなければならない、と言い替えることができる。