顧客の不満は、評価尺度の違いから生まれる

顧客とレビューや定例会をとおして仕様や課題を共有するとき、仕様書なら出来具合、課題なら進捗具合で顧客から不満をぶつけられることが間々あるものです。

例えば、開発上でトラブルが生じている場合、プロジェクトにインパクトを与えるような問題は顧客と問題管理又は課題管理などで共有することになります。顧客はその問題のプロジェクトに与える影響を見て、状況の進展を待つか、喫緊な対応が必要ならスポンサーとしての行動を取ることになります。状況の進展を待つ場合、顧客は受身の状態になります。一方、プロジェクトチームは、多くの課題を抱えつつプロジェクトを推進しているもので、喫緊な問題でなければ、その中での一つの課題として取り扱います。

顧客は何に苦痛を感じるか
顧客とプロジェクトチームとの間で共有される課題は、同じ課題一覧を共有しているし、同じ課題の情報を共有します。勿論、課題解決の当事者が事を当たることになるので、当事者の方が仔細な情報から顛末まで握っていることになります。情報の過多が問題になるかといえば、それは、情報の受け手が重要な課題であると識別するならその情報の仔細まで連携するように要求するでしょう。

問題なのは、必要な情報を適宜連携しているときに起きる問題解決に至るまでに受ける苦痛です。不思議なことに、幾つもの課題があって、重要な課題がそれなりに進捗しているときに、あまり重要視されない課題が変に脚光を浴び、想定を超えて関心を持たれ、追求されることがままあります。これは何に起因して苦痛を感じるのでしょうか。

時計が動く
もちろん、SIプロジェクトを動かしているならプロジェクトそのものに関心を持っているものです。維持管理のシステムなら、本番運用しているシステムの運行に最大の関心を持つでしょう。

SIプロジェクトの場合、プロジェクトを安全に確実に推進したいことから、プロジェクトの進行の障害になるものに最大の関心を払うことで、例えトラブルが生じても最小限に食い止めようとする力を働かせるものです。

顧客にとって、プロジェクトで頻繁に生じるトラブルは、その発生時点でプロジェクトのインパクトをはかり、先の喫緊のアクションが必要なものか、時間をかけてよいものか判断します。顧客にとっては、プロジェクトチームから報告を受けたときがファーストコンタクトであって、その時点から時計が動くことになります。

コントロールされているプロジェクトでは、課題や問題として取り上げられた事柄は、その問題の対応要求レベルによりリソースを割り当てして問題解決に当たり、進捗は顧客にアップデートされます。コントロールされているので、プロジェクトの中での問題の扱いは、顧客とも合意形成も経ており、ここの問題の管理とアクションは何ら問題がないと考え勝ちです。
ところが、顧客は顧客の立場があり、問題の進捗について別の視点を持っています。

“問題が発生してから解決するまでの時間”

も気にするのです。

小さな問題ほど時間が掛かる
顧客は、プロジェクト全体の進行に関心を持つため、プロジェクトチームより一段上の視点で物事を見ているものです。それは、プロジェクトのスポンサーである顧客も顧客の中でプロジェクトの進捗について報告する必要があることも一因です。

プロジェクトで発生する問題が生じたとき、その問題の大きさが大きければ誰もが自然と注意を払い、必要なリソースを振り分け対応するものですが、問題の大きさが大したことがなく、解決期限に余裕がある場合、その解決期限に近づくまで優先順位を自然と下げてしまい、その結果、放置されることが少なくありません。

ここが顧客と開発チームとの意識の差から生まれる評価尺度の差を生むことになります。大きな、重要な課題は、誰もが自然と注意を払い対応するため、対応の結果、進捗があるので、ある意味問題が生きているので事の成り行きを見ていればいいのですが、些細な問題は、問題が発生してから放置されるために、問題が発生してから解決までの時間が長くなる傾向があります。

小さな痛みを解決するには
指のささくれが気になって仕方がないように、プロジェクトでの小さな問題も発生してから時間が経てば気になるものです。
顧客は、プロジェクトへの影響が小さいとわかりながら、長い間、問題が小さいゆえに放置される痛みから開放されず、プロジェクトチームが予想する以上の関心を寄せることになります。

この長く小さな痛みを取り除くには、問題を解決するか問題を受容するとプロジェクトとして判断するほかなく、プロジェクトチームは例え小さな課題であってもそれがプロジェクトの問題であると識別したならリソースの振り分けと定期的な進捗の情報共有をするほかありません。