コンセプチュアル・マネジメント

◆顧客に対する認識

顧客は要求をする存在であり、コストを発生させる存在である。その中で、どれだけ適切に顧客の要求を把握するかが、プロジェクトの成功と顧客満足の両立につながると考えることが多い。顧客はプロジェクトの対極にいる存在で、プロジェクトの制約と顧客満足の間にはトレードオフがあるのだ。

顧客価値を実現するという活動は、顧客を対極においていると常にトレードオフが付きまとうことになる。そしてそれは、プロジェクトの進む方向にとって大きな制約になる。たとえば、アジャイル開発で折角、要求を開発しているにも関わらず、出てきた要求をコスト的な制約で実現できないといったことが起こる。

顧客価値を実現するには、まず、この構造を考え直す必要がある。顧客はプロジェクトの外ではなく、内にいるものだと考える。つまり、顧客が要求を与え、プロジェクトが実現するというのではなく、顧客も含めたプロジェクトとして必要な製品を考え、それを実現していく。


◆制約に対する責任を共有する

もちろん、スケジュールやコストの制約がある。それは、開発者の問題としてとらえるのではなく、プロジェクトの問題としてとらえ、解決していく。従来の方法であれば、顧客が要求することはビジネスの中での権利であった。顧客が要求すれば、要求の合理性の範囲において、開発者は開発する責任があった。

しかし、顧客と一体化するアプローチの中では、双方に制約をクリアするために努力する責任がある。顧客の要求には、顧客の優先度ではなく、「プロジェクトとしての優先度」が付けられる。そして、優先度の高いものから、制約の範囲で実現していく。

これは、現在の取引、つまり、顧客は要求する権利というやり方からすると、顧客の立場が後退しているように見えるかもしれないが、それは誤解である。このようなアプローチで作られた製品は、顧客にとって不必要なものは排除され、リーンである。言い換えると、顧客価値は目減りしていないのだ。


◆リスクの問題

そして、これまでの両極に分かれて、コミュニケーションで進んでいくという方法と比べると、コミュニケーションの質が高く、製品の品質が高くなる。これは、単にプロダクトの仕様だけではなく、プロセスが改善される効果もある。

ただし、このようなアプローチには、リスクがついて回る。顧客を対極に置いておきたい理由は、一にも二にもリスクの問題である。顧客と一線を引いておかなくと、プロジェクトのスコープがどれだけ大きくなってしまうか分からないというリスクがある。

ここで考えてみてほしい。このリスクの対応策は何か？本来、顧客との取引は、顧客価値に対して行われるものである。たとえば、ＩＴのプロジェクトで追加要求があるケースというのは、顧客側は当初想定していた顧客価値が実現されていないから、要求する。ベンダー側は工数で価値を見るので、それはできないという話になる。

つまり、価値の計測方法が異なっているところに、リスクの原因がある。だとすれば、価値の指標を統一すればよいだけの話である。たとえば、アジャイルのように顧客価値に統一する。これにより、顧客はコスト発生源であるという認識が変わるだろう。顧客をプロジェクトの内に入れるというのは本質的にはそういうことだ。

まず、顧客価値云々以前に顧客に対する認識を変える必要がある。