続 システムは高い
昨日書いたエントリの続き
まずシステムの価格が「高い」と感じるのはあくまでその感じた人の主観的な話である。
たとえば給料日前の1万円と給料日後の1万円では価値が違うと感じませんか？
ですから価格だけを見て「高い」とエンドユーザが言うのであれば「トリック」を使ってみる。
そのトリックとはエンドユーザのビジネスモデルを理解して懐具合を読んで
お金を持っているときに見積もりを持っていくのだ(^^;
でもこれは「トリック」なので一時的にはうまくいくかもしれないけど
根本的な解決にはつながりません。*1
次にシステムの価格が高いとエンドユーザが感じるシチュエーションを想定してみる。
タイミングとしては下の2通りだと私は思う。
A) システム開発前で見積もりを取った段階
B) システム開発後
A)については皆さんがおっしゃっているように合見積もりを取ることで解決できると思うけど
本当に問題なのはB)の方ではないかと思う。*2
話をわかりやすくするために飲食店を例に出してみよう。
たとえば店先にメニューが表示されていて
もし「高い」と利用客が感じれば他の店を選択することができる。
だから店に入る前に高いと感じる場合にはユーザも選択をすることが行えるわけだが
B)の場合はお店の前で価格をユーザが見て納得した上で中に入ったが
食事の後に満足ができないケースだと思う。
たとえば給料日後に飲食店に食事に行き1,600円のカツ丼がメニューにあったと仮定しよう。
カツ丼で1,600円ということは
・とても量があるか
・とても美味しいか
のどちらかだとユーザは判断して高いとは思いながら注文をしてみたが
対して美味しくなく量も少ない場合には不満を言って2度とその店には来ないだろう。
しかし例えば対して美味しくも無く量も少ないけれど600円のカツ丼であれば
「こんなものか、でも安いから良いだろう」となってもう一度店に来るかもしれない。
単に食事をするというコンテキストにおいても利用客の目的は複数に分かれると思う。
とてもおなかが減っている時に「とても美味しいけど量が少ない」カツ丼が出てきたって
あなたのおなかは満足できないでしょう？
逆にお腹には少ししか入らないしお金もそんなに無いので600円のカツ丼ではなく
ミニカツ丼にしたい利用者もいるかもしれない。
受託によるシステム開発が厄介なのはそのシステムが世界に一つのシステムであって*3
エンドユーザが作りたいシステムを明確にする点である。
上に上げたようにカツ丼であれば一般的なカツ丼に対する認識が双方で共有できると思うが
システムはエンドユーザの目的を相互理解をした上で共有できない限りは
B)の問題に対する問題解決につながらないと思う。
そういった問題が2003年に行われた日経コンピュータの調査で国内システム開発プロジェクトの成功率が26.7%という調査結果につながるのだと思う。
