顧客が欲しいのは「タイヤのブランコ」
コメントを返せなくて申し訳ございません。弊社サイトの焼き直しで更に申し訳ないですが、コメント代わりとして下さい。
前回、UIについてこそっと書きました。わたしがいいたかったのはこの漫画の内容です。
アメリカの自動車会社のフォードを作った Henry Ford も同じことを言ってます。
「もしわたしが顧客に、彼らの望むものを聞いていたら、彼らはもっと速い馬が欲しいと答えていただろう」
そう、顧客は「速く移動できる手段」が欲しいということを「もっと速い馬が欲しい」と表現するかも知れませんし、「タイヤのブランコ」が欲しいとき「三連のブランコ」と表現してしまうかも知れません。顧客がいった言葉そのものは、必ずしも正しくないのです。
さて、ここからものすごく細かくチープな話になりますが、日付入力について顧客側から「年を4桁入れたら、自動的にスラッシュを付加してくれないか」という要望が出てくることはよくあります。これは顧客が「速い馬が欲しい」というのと同じことをいってる可能性はないですか？
「年を4桁入れたら、自動的にスラッシュを付加してくれないか」という顧客の真意は何でしょう？
- 入力のキーパンチを極力減らしたい
- 見栄え良く分かり易くしたい
およそ、上の2種類になります。
業務システムの場合「入力のキーパンチを極力減らしたい」が真意の場合が多いですから、「当年当月であれば年月は入力しなくてもよい」という仕様の方が喜ばれることが多いでしょう。しかし、自動的にスラッシュを付加することはできなくなりますから、顧客が最初に言ったことと違うモノを作ることになります。が、何の問題もないですね。一方、ECサイトなどコンシューマ向けのWEBシステムのときは「見栄え良く分かり易くしたい」場合が多いですから、自動でスラッシュを付加する仕様の方がよいでしょう。
＃ WEBでよくある31個の日付のコンボボックスはいただけない。
＃ あれってセンスないと思うけどな……。
＃ フォーカスあるときにホイールを触ってしまったら、
＃ 意図しないで変わっているときがあるし、どう考えても
＃ 直接打った方が早くて正確やって。
＃ あと、住所の入力で「全角で！」って言ってくるヤツ！！
＃ ホンマ、絶望的にセンスないよな～。
＃ 「全角 → 半角」は完全に変換できないけれど、
＃ 「半角 → 全角」は変換できるし、技術者都合の仕様。
＃ それをこさえたSEに小1時間……。
ですから、業務システムの場合は「その理由はキーパンチを減らしたいためですか、見た目の問題ですか？」と聞いてもよいし、「弊社の標準はエクセル風になっているのですが」と説明してもよいです。もちろん、小さなことなので、反応が悪かったり、顧客が見た目にこだわっているなら、いうとおりにすればよい話で、そこで揉める必要はありません。
日付入力などどうでも良いことですが、ただ、こんな小さなことで「顧客の真意を測る努力をしているか？」ということが見えてくるように思います。他人の考えることなど分かるわけがないので最終的に真意を外してしまうことはあるでしょうが、努力することは非常に重要でしょう。
日付入力ぐらいで、顧客の言葉に直接的に反応する人は基本的な考え方がそうなのでしょう。そういう人は、余程気を付けない限り変わるチャンスがないから、永久的に「素の言葉」に直接的に反応し続けます。Henry Ford のいうとおり顧客は本当に欲しいモノをその通り言わない（ことの方がむしろ多い）のですが、その顧客の言葉を金科玉条と思って「三連のブランコ」の開発をしようとしてしまうと漫画になってしまいます。
たとえ顧客が「三連のブランコ」が欲しいといったとしても、それをそのまま欲している顧客はいないのですから、顧客の言葉をプロの技術を通して意訳して、了解を取るのが開発者の仕事だとわたしは考えています。
ところが、どう見ても顧客のいったことをオウム返しにまとめてるだけにしか見えない資料を作ってくる人も多い。特に大手の案件だったりすると、エンドユーザに直接会えないことも多く、さらにウォータフォールが正しいとされているから、上流の資料に戻ってやり直すことも難しい。そういう仕事に慣れている大手にこのタイプは多いと思う。
とにかく、「『年を4桁入れたら、自動的にスラッシュを付加してくれないか』と顧客がいってる。」と金科玉条のようにゴリ押ししてくる人が上流に何人かいると「タイヤのブランコ」は作れない。日付の入力ぐらいではさすがに流すけれど、そういうタイプと一緒に仕事をすると必ずどこかでぶつかるな～。ケンカしたい訳ではないのですけれど……。
日付の入力なんて本当に小さな話です。しかし、非常に考え方が出る。こんな小さな題材で差が出たらプロジェクト全体ではとんでもない差になるでしょう。上流の人がそんな人だったら（全く珍しくないけど）プロジェクトは本当に上の漫画みたいになってしまう。
開発仕事というのは、今そこにないモノを作り出す仕事ですから、要望する側が自身が欲しいものを正しく表現できなくって当然で、いきおい、「三連のブランコが欲しい」っていってしまうことは多々あるのです。
それを言葉と仕様書から完成を想像し、詰めていくのは限界があるので、仕様書で詰めると間違いが起きやすい。そのコミュニケーションギャップを埋めるには、何度も書いているけれど、ユーザの目に入る部分を先にアジャイルで作って、できる限り早く動きを見せることが必要です。しかし、内部（つまりDB部分）は、キャラクターベースのプログラムになりますから、じっくり時間を掛けるウォータフォールの方が向くのです。
ウォータフォールでは仕様は固まらないし、DB部分をアジャイルでやったらプロジェクトは迷走するしかない。
ウォータフォールが基本思想の大手の仕事は、漫画のような仕様書で承認をもらってしまって、承認後の変更によって「仕様変更と納期延長」ということを繰り返してきましたが、それは言葉のとおりしか受け取れない人がいかに多いかの証明です。上の漫画は40年近く前の海外のイラストのパロディです。
それが、今も笑えるなんて業界として成長がなさ過ぎじゃないでしょうか。しかし、この不況下ではいつまでもそんなことは言ってられません。工数（金額）も納期延長も厳しい状態になってきているのですから、そろそろ変わらないと……。
その解決策は「仕様をしっかり詰めること」、「承認をちゃんともらうこと」、ではないはずです。そんなもので解決するなら、何十年も前に解決しているのです。
多分、わたしは顧客の考えていることを理解するのはかなり早い方だと思うのですけれど、それを技術者に伝えたり、技術者が考えていることを理解するのが苦手です。なぜかというと、あるレベル以上の技術者を全員同格に見ているからです。わたしにできることはみんなできるはず、分かるはず。って心の底で思っている。ITの世界はコピーで済むのですから「1人ができたら既知の事実」ってね。全く難儀なやっちゃ。
格下・格上と思っていたら、過激には書きにくいし、いいにくい。本人は上から目線でいってるのではなく、同じラインで言い合ってるつもりなのです（笑）。
「できない人もいる」と頭では分かっているのですが、心の底でそう思っているからプロに対して説明するのは苦手です。これはわたしの欠点の中でもかなり巨大な欠点で、なんとかしないといけないのですけれど、なかなか直らない。
でも、セミナーはかなり分かりやすくなっているはずですけどね～。
コメント
しっぱ
こんにちは。しっぱと申します。
しかし、ITに留まらず全てのことをいい表してるようなイメージですねｗ
結局のところ言葉は言葉でしかなく、イメージとして頭に浮かべるものを言葉に出すのには労力がかかった上に、それが相手に正確に伝わるとは限りません。
某社研修で聞いたのですが、自分の理解したことを正確に相手に伝えるのには理解するまでにかかった10倍以上の労力が必要と聞きました。
そこを回避するためには実際に見てもらう、触ってもらう。
これが一番の早道ですね。
プロトタイプは何で作ってもかまわないと思いますが、クライアントに見える部分は早いうちに固めておきたいものです。
ちなみに私が上で受けた研修ってのは「リスニング」（ヒアリングでないところがミソ！）研修でした。
つまりブランコの絵をいかにクライアントから引き出せるかってところを埋める研修でした。
listen: 耳を傾ける、傾聴｛けいちょう｝する、聴く、聞く、耳を貸す
hear:聞く、聞こえる
生島様のご提示されました絵通りにならないためにまず
①耳を傾ける（hearではなくlisten）
②受け取ったものをイメージとしてアウトプットする
といった感じで私も心がけています！
いつも②に関わる部分については活発にお話しされていて楽しみに拝見していますが、ちょっと路線を変えて①の部分も生島様のお話を伺ってみたいです！
傾聴するのは最重要なのですけれど、傾聴するだけじゃなく、
「もっと速い馬が欲しい」→「もっと速く移動したい」
と言い換えれるかどうかも重要ですね。傾聴すればするほど、「もっと速い馬が欲しい」と強くすり込まれて、そこから抜け出れなくなる人も多いです。そういう人は傾聴してまじめにやっているだけにタチが悪い。すり込まれて「顧客が言ってる！！」ってのが、上流にいたら勝てなくなるのね……。
言い換えも Henry Ford の時代なら１通りでよかった。しかし、車を求める人は、「もっと速く移動したい」から、「安全」「快適」「ステータス」「見た目」「加速感」「ＥＣＯ」などなど。
と変化していますよね。
答えは１つじゃないから、いろんな車種を作って無限とも言えるオプションの組合せがある。
COBOLの時代なら（それでも失敗があったからあんな漫画ができているのですが）、画面も帳票も工夫の余地は少なく、顧客も仕様書で想像付いたけれど、ITの世界もお客様の要望はかなり変化していて、答えは１つじゃない。
なのにエクセルに貼り付けた絵（仕様書）で説明して「仕様を詰めた」っていうのよね。そういう人を見るたびに「君らはエスパーか！神か！」って思う。さらに、どちらかというと、
「もっと速い馬が欲しい」→「もっと速く移動したい」
の言い換えが下手糞な人ほど、仕様書で仕様が詰まると頑なに思っている。
本当に恐ろしい話だと思いませんか？
ちなみに、あの漫画は最近ではガンダムバージョンとかイロイロあるみたいで、相当に有名な漫画です。
私が最初にコラムに書いたのは、ネットで流行るかなり前の６年前。
それでも、まだ、ネタとして成立するのは本当に悲しいことです。
sunset
はじめまして。新米コラムニストのsunsetと申します。
>「年を4桁入れたら、自動的にスラッシュを付加してくれないか」という顧客の真意は何でしょう？
私のお客さんでも、こういった頑固なお客さんが多かったです。
#今はお客さん１件だけなのですが、昔も今も、頑固な人は頑固ですね～
新しいシステムの導入直後に、よく起こりえることですが、
「前のシステムでこういう入力をしていたから、新システムも同様のUIを備えているはず」
という顧客の思い込みから、生まれる齟齬もありますね。
顧客の固定概念を取り払って、システム会社が新システムを提案・開発・導入するハズなのですが、
・システム会社：「新しい入力のオペレーションをすることによって、業務効率が上がる「ハズ」です！」
・顧客：「いやいや、新システムにしてくれとは言ったけど、旧来のやり方を崩してとは言ってないよ（怒」
こうなるのは、まさに傾聴力と翻訳力（と言っていいのか？）が不足しているケースで、うちの会社は、毎度のごとくこのケースに悩まされています（ヒデェ。。。
>「もっと速い馬が欲しい」→「もっと速く移動したい」
>
>と言い換えれるかどうかも重要ですね。
かくいう私も、稚拙な例え・言い換えしか出来ないので、いつも困ってます。
ex) HDDの容量が足りなくなるのを、ペットボトルに水入れすぎたら溢れる、みたいなorz
シンプルに、かつ的を得た言い回しを探しながら日夜奮闘中です。。。
ユーザー側でも、ＩＴリテラシーを上げてほしいと思うのは、私だけスか。。。？
sunsetさん、おはようございます。
C/SをWEB化するとき、必ず言われますな。
そう言われるのは、そもそもC/SをWEB化する必要がないことの方が多い。
エンドユーザが自動でスラッシュが入ることに慣れていれば、そう作ればよいのですがね。ユーザのリテラシーを上げるのも我々の仕事だから、がんばらないといけませんが、まずは技術者の能力を上げる方が先で……。
seven
はじめまして。sevenと申します。
C/SからWEBではなく、ダム端の同等機能をWEB化した際に、顧客の業務部長から画面の操作性について、「ダム端同等の操作はできんのか。新しいものを作って使いにくくなるのか。」と指摘をされました。
ところが会議に出席していた元請のSIerが誰も回答しなかったので、あわてて「ダム端の同等機能は御社オペレーターが操作する機能で、このシステムのWEB化はエンドユーザの企業に広く入力機能を開放するものです。端末を展開するコストだけでも安く見積もって10倍以上の差が生じ…云々」と何を優先するのかを説明して納得いただきましたが、回答せずに指摘を受け入れていたら、オーバースペックによるパフォーマンス劣化で顧客が望んでいなかったシステムになってしまっていたと思います。
しっぱ
こんにちは。しっぱです。
＞言い換えも Henry Ford の時代なら１通りでよかった。しかし、車を求める人は、「もっと速く移動したい」から、「安全」「快適」「ステータス」「見た目」「加速感」「ＥＣＯ」などなど。
ここはなるほどーとなりました。
確かに多角的にものが見えない人だと危ないですね。
「根本に何があるのか」をしっかり把握する必要がありますね。
あと横レスですが、
＞フル桁入力されたら、タブキーもEnterもなしでも次の入力エリアへ移動するという仕様ですか……。
⇒こちらは実際作ってみまいたが、そんなに時間掛からずできました。
javascriptでkeydownイベントにリスナー張って監視してみたところできましたが、入力項目が多い場合は避けた方がいいかもしれませんね。。。
というより「出来る」「出来ない」だけに着目すること自体ナンセンスですねｗ
最近ちょっとプリセールスより技術者としての仕事が多かったので試してみたかっただけです＾＾；
余談でした。。。。。
次回のコラムも楽しみにしています！
seven
こんにちは。sevenです。
生島さん、しっぱさん、コメントありがとうございます。
＞フル桁入力されたら、タブキーもEnterもなしでも次の入力エリアへ移動するという仕様ですか……。
その要求もありました！
一番大きいのは、ダム端では一項目入力毎にリアルタイムチェックができることでした。項目相関チェックも含む業務的なチェックは最新の業務データを参照しないとできないので、実現できないわけではないでしょうが、まさにジェットコースターなみの予算で、幹と幹の間で数cmだけ揺らせる程度のブランコを作ることになっていたでしょうね。
それはさすがに避けることができたのですが、このシステムは「パワーポイントで作ったユーザインターフェースのプロトタイプで、エンドユーザに説明してしまったから」という理由で、その説明との矛盾を生じさせてはならないということで、システム的にはちょっと無理のあるユーザインターフェースになってしまいました。
SIerが作ったパワポでエンドユーザに説明する話があったときに「まだユーザインターフェースも固まってないから、あくまで概容のイメージということで説明してください。」とSIerには依頼していたし、その問題で設計を2週間止めて顧客とSIer交えてデメリットを説明したんですが、最終的には顧客判断で、あるべき姿にできませんでした。パワポのプロトタイプに対するSIerと顧客の認識が違っていたんでしょうね。
当然そのユーザインターフェースをなるべく無理のあるものと感じさせないために設計もゆがんだものになり、開発コストは無駄にかかったという印象でした。
いまも全国ネットで動いている現役のシステムです。
AC/DC
なんかここ何回かおもしろくないねえ。
よく知りもしないのに、「KVSは業務システムには使えません」なんて堂々と書いといて、「使える/使ってます」ってコメントは丸無視。ってか、うっかりコメント返して、知識のなさを露呈するのが怖いのかね。
ま、年度末で忙しいんだろうけどさ。
結局、自分が得意なＳＱＬっていう既得権益を守りたいだけじゃんね。
今までコラムで批判してきたことを、自分でやってるじゃん。
おいらの周りのちょっと目端の利く連中なら、使える/使えないの見極めも含めて、ＫＶＳとかクラウドとか研究してるし、実践してるやつもいる。
別に「これからはクラウドだぜ。RDBなんて過去の遺物さ」なんて言うつもりはないけどさ、頭ごなしに「使えねえ」って言うのはどうよ？
ああ、そうだ。
別のコラムニストの人が言ってたけど、ここのコメント削除はコラムニストが無断でできないように言われてるんだってね。
でも、生島さんは無視して、自分に都合の悪い意見は抹消しちゃってるわけだ。
そうだ、もうひとつ。
TokyoCabinetって初めて知ったよ。で、使ってみた。これすごいね。
数100万どころか、1億オーバーのレコードでも、全くスピード落ちない。
どゆこと？
flatlineさん、教えてくれてありがと。
AC/DCさんとか、flatlineさんの読解力では理解できない内容になっております。
あしからず、ご了承ください。
気分悪くなってまで読む必要はないかと思います。
もう少し簡単な文章から読んで、十分な読解力を付けられてからイラしていただければと思います。