システム構築のための調整力向上講座（第6回） 現場の「真の要求」を知り期待値をマネジメントする

　前回、システム開発はサービスの提供であり、それにはモノの提供とは違った特徴があること、その品質には「成果」と「提供プロセス」の2つがあることを説明しました。「成果」と「提供プロセス」、この2つの品質に対して顧客（現場）の満足を引き出せるかどうかは、現場が事前にどれだけ期待しているかに大きく左右されます。

　同じ品質であっても、それ以上に顧客が成果を期待していたら「期待はずれ」になってしまいますし、期待以上の品質であれば「いい買い物をした」と思ってもらえます。

　コトラー氏は、顧客の期待度を高める要素として、9つの要素を紹介しています。

　例えば、1つめにある「明確な約束」では、プロジェクトのスタートまでのプロセスの中で交わされた約束は、それが口約束であっても、むしろ口約束のほうこそ、守られることを現場は期待します。

　また、サービスは形がなく、触れられないため、現場はサービスを購入する前に「手がかり」を探します。システム開発担当者が自信満々に振る舞っていれば、「当然、能力が高く、サービス品質も高いだろう」と現場は期待します。それは現場にとっては「暗黙の約束」として期待度を高めるのです。

期待値をマネジメントする

　品質と期待値との関係を考えると、現場にとって良いサービスとは「現場の期待を上回るレベルのサービスが提供されること」だといえます。ということは、現場に満足を引き出すためには、現場の期待値がどのように決まるのかを知り、それをうまくマネジメントする必要があるのです。

　現場の「真の要求」を知り、期待値をマネジメントするアプローチとして、以下の5つを紹介します。

どのような期待をしているのかを聞く

　現場の真の要求、何を期待しているのかを知っているのは、現場だけです。それを知るためには現場に聞くほかありません。しかし、現場自身も要求や期待を明確な言葉で表現できるほど自覚していないのがほとんどです。そこで、以下のポイントについて質問するとよいでしょう。

（1）プロジェクト終了後、自分たちの業務はどうなっていたいか
（2）プロジェクト終了後、プロジェクトのステークホルダーはどのような成長を遂げていたいか
（3）プロジェクト終了後、自分たちの組織はどのような成熟を遂げていたいか
（4）プロジェクトを進める際、現場自身はどのようなかかわり方をしたいか
（5）過去のプロジェクトで、システム開発担当者に不満を感じたことは何か

　（1）～（3）の質問は「成果の品質」を問うものです。（1）は業務の「Before/After」について問い掛けます。（2）と（3）は派生的な要求を問うものですが、実際には現場の要求度はこちらのほうが高い場合も少なくありません。

　（4）と（5）は「提供プロセスの品質」に関する質問です。現場によっては「できるだけ一緒に良いものを作りたい」というタイプと、「任せるから適当にやってよ」というタイプがいます。

　後者の場合、プロジェクトが失敗する可能性があるため、現場を巻き込むプロセスを考える必要があります。現場が過去にシステム導入の経験があるなら、そのプロジェクトの結果はどうだったのか、発生した問題を聞いておくことで、現場がプロジェクトに何を求めているのかが分かります。

できることだけを約束する

　現場の期待度を高める要素の一つとして「明確な約束」があるように、現場は「期待してください」と言われれば期待します。プロジェクトの実務スタートまでは、システム部の上長が「できる、やれる」を連発して、なんでも対応しそうなことを言っているケースもあります。

　プロジェクトの決定プロセスにシステム開発担当者が関与していなければ、上長がどのような口約束をしたのかなど分かりません。しかし、現場はしっかり覚えていますから「言ってたことと違うじゃないか」という事態に陥ってしまうのです。これでは、顧客満足を引き出すどころか、下手をするともめることになりかねません。システム開発側は、現場に対して「現実的、かつ実現できること」だけを約束しなければなりません。

プロセスを共有する

　モノとサービスの違いの一つに「サービスは提供プロセスに顧客が参加する」ことがあったように、サービスは現場の参加なくして成り立ちません。しかし、そのプロセスについて現場としっかり共通認識を確立できているプロジェクトは多くありません。

　よくあるのが現場から変更要求が出されて、システム開発側が「このタイミングで、変更要求を出されても対応できません」といってもめるケースです。現場はシステム開発のプロセスについて知識はありません。どのタイミングまでは仕様の変更要望を出しても吸収できるのか、変更要求は開発プロセスにどのような影響を与えるのかは、分からないのです。分からなければ、「一度、投げかけてみよう」とするほかありません。

　システム開発側としては、ギリギリのタイミングまで変更要求を吸収しているという認識でしょう。しかし、それが仇（あだ）となります。現場からすると「柔軟に対応してくれるといったのに、急に対応してくれなくなった」と不満に感じてしまいます。

　変更要求にかぎらず、プロジェクトの各フェーズで何をするのか、各フェーズの完了基準は何なのか、上流から下流に至るまでの成果物のインプット・アウトプットの流れを現場と共有することが重要です。

プロセスに現場の要求を取り入れる

　現場とプロセスを共有するとき、進め方に対する現場の要望を考慮しましょう。現場はあくまでも社内事情の中で生きています。組織によって異なる事情を考慮し、プロセスに盛り込むことで、現場の満足度は高まります。

トップ品質より、ボトムラインの品質を担保する

　サービスは人と不可分であり、サービスの品質はそのときどきによって変動します。人間ですから、調子のよいときもあれば、調子の悪いときもあります。

　しかし、現場は変動を嫌います。専門家として安定した品質でサービスを提供し続けるためには、調子のよいときに最高のパフォーマンスを発揮するより、調子が悪くても最低限の品質を保証できるほうが重要です。調子がよいときのトップ品質を高めるより、調子が悪いときでも発揮できるボトムラインの品質を高めるほうが変動性は小さくなります。

　サービスはその提供プロセスを現場と共有します。特に、システム開発や導入においては、サービスを提供する側、受ける側といった区別はなく、一体になって進める必要があります。それだけプロセスを共有するということは、常に現場に見られていることを意味します。プロジェクトリーダー、エンジニアには、一貫性が求められるのです。

まとめ

●現場が求めているものを知るために自分たちの仕事は「サービス」だと自覚する。
●サービスの品質には、「成果の品質」と「提供プロセスの品質」の2つがある。
●現場の期待値がどのように決まるのかを知り、期待値を超える。

日経SYSTEMS／芝本秀徳（プロセスデザインエージェント）