顧客の継続的な便益を考えているか

　前回、顧客からこういったシステムを作ってほしいと言われたら、言われた通りのシステムを作って納入だけで終わってしまうのではなく、顧客の便益を考えて求めた以上のシステムを提案し作る様にすれば、顧客の心象と信頼は違ってくるという話をしました。

　システムを使うことによって受注が増える、生産性が上がる、業務効率が上がる、といった効果が得られ始めることで、顧客は満足しているかもしれません。

　しかし、顧客の便益は一過性のものではありません。一年経ったら動かなくなってしまったら、当初の満足は張子の虎だったということになってしまいます。これは極端な例としても、システムが動く環境や背景は変化していくものです。問題は、そういった変化があることを想定してシステムを作っているかということです。

　もちろん、顧客から要求の無かった仕様を、良かれと思って製作コストも考えずにシステムに盛り込んでおくことはできません。ここで差が生まれるのは、システムの専門用語で言うと「非機能要件」と名のつく、顧客が直接的には意識しない部分への気配りです。

　システムを使用していたら、ある特定の操作をしていたときに異常が発生した。こんな報告を顧客から受けたときに、調査しますといって自社内でシステムのソースコードを点検したり、同じ操作を繰り返して再現を試みるなどという対応をしていては、顧客の不便の解消に時間を要してしまいます。

　こんなとき、システムの中にどの様な操作が行われたのかと、その時にシステムがどう動いたのかという履歴の記録を一緒に残しておく仕掛けが作り込まれていれば、その蓄積されているデータの中身をチェックすることにより、システム内で何が起きたのか瞬時にわかります。あるいは直ちにわからなくとも異常のきっかけを突き止めることができます。この様なことは、初めから意図を持っていないと作り込んでおけないものです。

　より表面的に見える例を挙げれば、顧客が将来変更する可能性のあるパラメータは、できるだけ容易に変更できる様にしておく必要があるのは、作る側としては当然考慮の対象になるべきものです。例えば、商品の”割引率”、”税率”といったものです。

　こういったことが考慮されていないシステムを作ってしまうと、使い始めた当初は便益を提供できても、それを将来的に継続することができなくなります。

　プロジェクトは成果物を提供することで目的を達成し終わるかもしれません。しかし、その成果物はプロジェクト終了後も動き続けます。成果物は、プロジェクト終了時点だけで評価できるものではなく、その後何年もかかって評価され続けるという側面もあるものです。

　高いコストを掛けて作ったシステムだったが、世の中の変化に簡単に対応できず、他社に乗り換えることになった、という報告を後から聞きたくありませんね。

　あなたのそのプロジェクトでは、顧客の継続的な便益に目が向けられているでしょうか。ゴールに到達した後のことを想像できていますか。

 

関連提言；プロジェクト成功の定義