「期待していたほどではなかった」「もっとやってくれると思っていた」―——。プロジェクトの終了時に、システムを利用する現場からこのように言われたとしたら、たとえQCD(品質、予算、期日)を満たしていたとしても、そのプロジェクトは失敗です。少なくとも、現場は「予算を投じただけの価値はなかった」と考えていることになります。
プロジェクトリーダーからすれば、現場の要求に可能な限り応え、メンバーが高い負荷の中でなんとかやり切ってくれたと考えているかもしれません。しかし、それは現場には理解されず、評価もされません。そこには「“システム開発側が考える”現場が欲していること」と「現場が真に欲していること」とのギャップが存在します。
また、最終的に現場にどれだけ満足してもらえるかを大きく左右するのが「現場の事前期待値」です。苦労してQCDを満たしたにもかかわらず、現場に満足してもらえない。現場、システム開発側、双方にとって不幸な結果になってしまいます。
システム開発やシステム導入といったプロジェクトにおいて、現場はシステム開発担当者に何を求めているのでしょうか。それを知るには「サービス」というものが持つ特徴を知る必要があります。ここでサービスとしたのは、システム開発やシステム導入は、服やクルマのような「モノ」とは明らかに異なるものだということを認識する必要があるからです。形があり、姿が見える「モノ」とは違い、サービスは触れたり、見たりすることができません。
米国の経営学者、フィリップ・コトラー氏は著書『コトラーのプロフェッショナル・サービス・マーケティング』において、サービスが持つ特徴として以下の6つを挙げています。
(1)無形性
ソフトウエアやシステムには形がありません。触ることも、見ることもできません。また、システムを導入する場合は、要求分析や要件定義、研修などのプロセス、さらに導入後のサポートが存在します。それらは確かに存在するものの、形があるわけではありません。
(2)不可分性
クルマを買うとき、「このクルマはどんな人が作ったのだろう?」と考える人はまれでしょう。ユーザーの関心は、そのクルマのデザインや性能、居住性などに関心があるのであって、作り手への関心は強くありません。
一方、サービスを受けようとするとき、顧客はそれを提供する「人」に関心を向けます。例えば、コンサルタントに仕事を依頼するとき、顧客にとって一番の関心は「どんな人が担当してくれるのか」です。システムの導入においても、エンジニアがいかに優れた技術を持っていたとしても、コミュニケーションに難があれば顧客がそのサービスに満足することはありません。サービスはそれを提供する人と切っても切り離せないのです。
(3)変動性
サービスは機械ではなく、人が提供するものですから、その提供品質にバラツキが出ることは避けられません。同じ会社、部門であっても、担当者の質にはそれぞれ開きがありますし、たとえ同じ人であってもその時々で調子の良いとき、悪いときがあります。
しかし、サービスにお金を払う顧客にとっては、このバラツキは好ましいものではありません。レストランに行って、毎回味が違ったり、サービスが良いときと悪いときがあったりすれば、そのレストランにはいずれ行かなくなってしまうでしょう。「お金を払っている以上、これくらいはやってもらわないと」と、顧客は一定以上の提供品質を期待します。
(4)消滅性
一度パソコンを買えば、捨てない限りそれは存在し続けます。しかし、サービスは提供されると同時に消えてなくなります。タクシーを利用したからといって、何か形のあるものが残るわけではありません。サービスは提供されると同時に消費されるという性質を持っているのです。システム導入におけるそれぞれのプロセスも同じです。
要件定義、要件分析、設計、実装、テスト、導入、サポートなど、これらのプロセスは提供されると同時に消えてなくなるのです。形あるモノが存在すれば、品質に満足できなかったり、不具合があったりすれば、取り換えたり修理したりできます。しかし、消えてなくなってしまうサービスは、それができないのです。
(5)満足度の基準の違い
ここまで見てきた「無形性」「不可分性」「変動性」「消滅性」の特徴を持つサービスは、当然、形あるモノとでは顧客が評価する基準が違ってきます。特にシステム開発やシステム導入といった専門的なサービスにおいては、顧客は品質を測る術を持っていないため、「自分は満足に足るサービスを受けられたのか」を別の方法で測ることになるのです。
(6)顧客もサービス提供プロセスに参加する
モノとサービスを分ける最も大きな違いは、サービスはその提供プロセスに顧客が参加するということです。モノは顧客がいなくてもそこに存在し続けます。しかし、サービスは顧客がそこにいて初めて成立します。レストランのサービスはそれを受ける顧客がそこにいなければ始まりません。システム開発ではさらに、顧客が積極的に提供プロセスにかかわります。要求分析は、顧客(現場)がどのような困りごとを持っているのか、それをどうしたいのかを、顧客(現場)から提供してもらわないといけません。提供プロセスの顧客への依存度が非常に高いのです。
サービスには2つの品質がある
ここまで、形を持たない「サービス」というものが持つ特徴を見てきました。ここでさらに、サービスを提供する者として常に意識しておく必要があるのが、2つの「品質」についてです。
私がコンサルティングの現場で見かける「顧客の不満」の多くは、サービスには2つの品質があるということを、提供者が理解していないことによって起こっています。
2つの品質のうち、1つ目は「成果の品質」です。ここでいう成果とは「サービスを受けた結果得られたベネフィット」です。レストランへ食事に行くとき、ほとんどの人はただおなかを満たすためだけに行くのではありません。それならコンビニで弁当を買って食べればいいのです。「もてなしを受けた気分」「家では食べられない料理を食べられた満足感」を求めて行きます。
システムの導入も同じです。現場はシステムが欲しいわけではなく、「効率化された業務」や「楽になった自分たちの姿」を求めています。つまり、成果の品質とは、サービスを受ける前と、受けた後で、どれだけの「変化」があったかということです。
しかし、この変化を厳密に測るのは難しいことが多いのも事実です。どれだけ業務が効率化されたかを測るには、導入前にデータが蓄積されている必要がありますが、そもそもデータがないからシステムを導入するといったケースも多いでしょう。どれだけ自分たちの仕事が楽になったかは、主観的な要素も多く、実際には楽になっているのに、「慣れたやり方と違う」という理由で楽になっていないと感じる人もいます。
成果の品質を測ることが難しいサービスというものの特徴から、顧客はもう1つの品質で満足度を測ろうとします。それが2つ目の「プロセスの品質」です。例えば、レストランで料理が出てくるまでに15分待たされたとしましょう。このとき、何も声をかけられないまま15 分待たされるのと、「今少しお時間をいただいております。もう少々お待ちください」と言われて待つのとでは、顧客の気持ちはまったく違うものになるでしょう。
システム開発においても、いくら仕様通りにシステムを作り、予算、期日を満たしたとしても、その提供プロセスに納得性がなければ、現場は決して満足しません。逆に、QCD を満たせなかったとしても、提供プロセスに納得していれば、現場は「よくがんばってくれたね」と言ってくれるものなのです。
提供者側であるエンジニア、プロジェクトリーダーは、「良いシステムを作る」ことだけにフォーカスしてしまいがちです。しかし、それでは片方の品質しか満たせません。顧客にとって重要なのは、むしろ「提供プロセスの品質」です。なぜなら、顧客は「自分たちが納得できるかどうか」が最も重要な基準だからです。
日経SYSTEMS/芝本秀徳(プロセスデザインエージェント)