【雑記】 機械（メカ）を相手にするということ

今回は思いつきでＩＴリテラシーについての記事です。
題して、『機械（メカ）を相手にするということ』。

最初に事例を二つほど書き連ねます。
この二つの事例がどのように効いてくるかは後述します。

ケースＡ：食べ終わってから現金で会計するラーメン屋
ケースＢ：券売機で食券を先に買ってから席に着くラーメン屋

ケースＡのお店では３つのメニューがあります。

・ラーメン　５００円
・ギョーザ　３００円
・ラーメンセット（ラーメン＋ギョーザ）　６００円

客が「ラーメン」と発言した時はラーメンが出されて５００円の支払いとなります。
客が「ラーメンセット」と発言した時はラーメンとギョーザが出されて６００円の支払いとなります。

さて、ここで客が「ラーメンとギョーザ」と発言したらどうなるでしょうか？
ラーメンとギョーザが出される。

ここまではいいのですが、会計はいくら？

気の利いた店員なら裏で自動的に６００円に丸め込んで請求するでしょう。
でも、厳しい店員なら利潤を追求するあまり８００円を請求するかもしれません。

客がセット価格に気付かずに８００円を支払って店を去れば問題ないのですが
途中で気付いて「６００円でいいだろ」と言ってきたら大抵の店員は折れて
セット価格を適用して６００円にしてくれるでしょう。

そんなケチなことでリピーターを逃すのは得策ではありませんし
気の弱い店員なら「自分が間違えた」と思って罪悪感を抱くかもしれません。

ここで重要なのは、客の相手をするのは人間（ヒューマン）だということです。

次にケースＢを見ていきましょう。

ケースＢのお店でも３つのメニューがあります。

・ラーメン　５００円
・ギョーザ　３００円
・ラーメンセット（ラーメン＋ギョーザ）　６００円

客が「ラーメン」のボタンを押した時は５００円の支払いとなります。
客が「ラーメンセット」のボタンを押した時は６００円の支払いとなります。

さて、ここで客が「ラーメンとギョーザ」のボタンを押したらどうなるでしょうか？
８００円の支払いです。

相手は機械なので自動で丸め込みをしてくれません。
額面通りの金額を請求をされます。

考えてみれば当たり前のことなのですが、
これで文句を言う客もいるかもしれませんね。

ここで重要なのは、客の相手をするのは機械（メカ）だということです。

人間のように気の利いたことはしてくれません。
ボタンを押された通りのにしか処理しないです。

コンピュータシステムの開発においては、これは客の押しミスということで突っぱねることができます。
「あなたがそうボタンを押したのだから、８００円とられるのは仕様です」と。

でも、一般の人はコンピュータシステムを使い慣れていません。
人間同士のやり取りに慣れています。
なので、こうしたことでもトラブルになりやすいのです。

「だったら、裏で自動で丸め込むようにシステム化すればいいじゃないか」
と思うかもしれませんが、下手にそういう便利機能を入れると
システムを導入した顧客が逆ギレしてくることもあるので難しいです。

大抵、こういう場合はシステムを導入する顧客自身が
・システムで業務をどう簡略化したいのか
・システムにどのような機能が欲しいのか
・システムがどこまで仕事をすればいいのか
という明確な“要件”を持っていないことが多いのですが。

コメント 6

>>大抵、こういう場合はシステムを導入する顧客自身が
>>・システムで業務をどう簡略化したいのか
>>・システムにどのような機能が欲しいのか
>>・システムがどこまで仕事をすればいいのか
>>という明確な“要件”を持っていないことが多いのですが。

更に、「最初に求めていたシステムを要望通り作って納品しても文句を言う奴は居る」ってのも追加してもOKですｗ
by Aya (2010-01-06 01:11) 

はじめまして。
客が押し間違えないようなボタン配置、はシステム設計の要件に含まれるんでしょうか。
素人丸出しの質問ですみません。
by chokusin (2010-01-06 21:33) 

◆ Aya さん
◇ コメントありがとうございます

＞ 最初に求めていたシステムを要望通り作って納品しても文句を言う奴は居る

さすがに文句を言ってくるような図々しい人はそんなにいないですが
希望通りに作ったのに、「使えねぇ」と言い出して放置している客はこの前いましたね・・・。
　
by Lunamaria (2010-01-07 01:04) 

◆ chokusin さん
◇ nice & コメントありがとうございます

＞ 客が押し間違えないようなボタン配置、はシステム設計の要件に含まれるんでしょうか。

画面設計やユーザーインターフェースも顧客に合わせて作るのは大事ですね。
おそらく“要件”よりも“仕様”を決めるフェーズで話が出てくることが多いと思います。
　
by Lunamaria (2010-01-07 01:06) 

もう、システムの仕事を離れて４年になるのでなんですが、仕様もしくは導入前
コンサルの段階から、当該システム構築の話に入れてないと、あらゆる意味で
厳しいと思います。

昔、日経コンピュータで「動かないコンピュータ」という人気シリーズがありました
が、2000年頃までは、この手の予算やシステム化の手順（コンサルはＡ社で、
仕様の策定他はＢ社、予算でポシャってＣ社と再スタートで延々稼動しない）と
か、そんな話が多く、比較的最近はアプリやパフォーマンスの技術論が多くな
ってた気がします。

基本的に、企業内のユーザー部門等は仕様を決められない事が多いので、社内
システム部門とうまくやるか、コンサル段階から過去の仕様を洗い出したり、パッ
ケージ中心でアドオンはどの程度かと、明確にしておくしかないのでしょうね。
それでも不満は出ますが、いつまでの発注分以降は追加料金とはっきりさせて
おく（それも厳しいときもある）しかないでしょう。
結局のところ、予算立案前からユーザーの懐に入り込めていないと、とばっちりは
ＳＥ会社の方に降りかかると思います。
でも、金が無いので御社に頼みたい・・・という企業は多いのですよね（笑
それで泥沼に踏み込んでいくのでせう。

最近は内部統制なんかがあるので、ユーザー側も仕様をある程度理解して無いと、
結局は自分に火の粉が降りかかるんですが、なかなか理解はしないでしょうなぁ。

by kesagake (2010-01-07 12:49) 

◆ kesagake さん
◇ コメントありがとうございます

＞ 企業内のユーザー部門等は仕様を決められない事が多いので

自分たちの業務なのに、自分たちが説明できないことが多いですが
実世界のことをコンピュータに置き換えて、というのに慣れていないと思います。

となると、キーになってくるのはＳＥの“提案力”と“発掘力”だと思います。

実績のあるパッケージをベースにして安価に導入するのがいいのか
最低限のカスタマイズシステムを作ってから改修を繰り返していくのか。

このユーザーはまだなにか問題を抱えているのではないか。
問題の根本を正確に把握くできているのか。

あとは、どうしてもＳＥに頼ってしまうというか任せてしまう傾向もありますね。
んで、あとでＳＥのせいにして責任逃れをするという。

専門用語を並べたてるＳＥが自分より“上位”だと思ってしまうのかなぁ・・・。
　
by Lunamaria (2010-01-08 00:46)