＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
顧客要求と「本当の」要求との乖離について
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-10-17 16:16
どもでし。がると申します。
んっと。あちこちで耳にする話と気になることをつらつら っと書きながら、どちらかというと雑談風味に皆さんで 話し合いなど出来ればと思いまして。 趣旨 顧客が「言葉によって伝えてくる」要求と、顧客が 「本当に欲しいと願っている」要求は、かなりの乖離 がある場合がある。 この乖離について認識すると共に「ど〜やってそれを 顧客に伝え、納得させるか」について話をしてみたい。 詳細 システム構築において、お客様から何らかの要求が ある。これ自体はむしろ歓迎すべきことだと思うんですが。 時々、どうも色々と勘違いされているような発言を されるケースってのがあるです。 実例としては。 CGI作成において、お客様から「Cookieは絶対に使うな」 との要求がありました。 その当時、確かにCookieのセキュリティについて色々と 意見が活発な時期ではあったのですが。 認証系Pageにおいて、Cookieを使わないで実装することは、 場合によっては「Cookieを使う以上に」セキュリティ的な 危険を孕むことになります。 でまぁお客様に確認したところ、「Cookie使用禁止」 の根っこにあるのはやはり「セキュリティ上の不安」でした。 つまり、顧客要求は「Cookieを使わない」でしたが、 本心は「セキュリティの向上」だったんです。 お客様への詳細な説明などの過程を経て、要求を「セキュリティ の向上。特にCookieなどを用いる際は十分な配慮をする と共に、顧客へ説明を必ず行う」というふうに変えて 頂きました。 ここで、顧客要求の「Cookieを使わない」を鵜呑みにして、 例えば(その当時はやっていた)REFERERを使った認証などに していた場合、Cookieを使う以上のセキュリティ問題を孕む 可能性が生じ、結果的に「顧客要求は満たせたが、本当の 要求からは乖離しまくったブツを作成する」ところです。 ーー お客様は「自分のやりたい事」ってのを持っていることが 多いかと思います。 ただ、問題は「正しく伝達してくれるかどうかがわからない」 上に、場合によっては「自分でもちゃんとやりたい事を 認識しきれていない」など、表現的に難がある場合が多々 あるです(苦笑 でまぁ「そういった不整合をどこで整えるか」なのですが。 可能性のひとつとして、ヒアリングする技術者が行う、 という可能性があると思うでし。 いやまぁ「コンサルティングだよねぇもはや」とかいう 話もあるですが。 でも「技術力を基準にしたコンサルティング」って案外に 便利ですし重宝がられるです。 ーー ってなわけで。 成功例、失敗例、今困っていること、質問その他。 皆さんでつれづれと話し合ってみませんか？ | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-10-17 17:17
とりあえず貼っておきますね。
# オリジナルも見た記憶があるのですがすぐに見つけられませんでした。きっとどなたかが貼ってくださるでしょう。 Typical Project Life http://weblog.cemper.com/a/200309/09-typical-project-life.php 顧客が本当に必要だったもの http://www.dashiblog.com/blog/archives/project_comedy_l.gif で本題の話ですが、 私の経験ではXPのように「簡単なプロトタイプをどんどん作って、いちいち確認しながら仕様を煮詰めていく」ことを本当にやったとき、出来上がりにとても満足してもらえました。 毎回そうできる(技術者が直接、または技術に詳しい人がヒアリングする)のが理想なんでしょうけれどなかなかできませんね。だからこそコミュニケーションが大事だと言われるのでしょう。いい案があれば私も知りたいです。 例に挙げられた「Cookie 禁止」のような、不要で理不尽な仕様をはねのけられないときにどうするか、という件もいろいろ伺いたいですね。 | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-10-17 17:22
こんにちは。
「最初から」がよいですね。 そもそもシステム化には目的があり、システムを使って行う業務自体にも目的を 持っています。最初からそれに沿って開発（設計含む）を行うのがベストかと思い ます。 ＵＩ等の細かいところに入ってからだと、ユーザーは「便利」とか「楽」とか言 う言葉に惑わされて本来の目的を見失ってしまう可能性があります。 ＃ と書くと元も子もないですか．．． | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-10-17 17:41
コナンです。
お客様が技術者に相談する時は、「自分のやりたい事はきっと技術的なことで 解決できるはずだ。」と思ってるような気がします。 なので、やりたい事は認識してるけど頭の中では「この技術で解決可能！」というように 答えが出てしまってるから、「本当のやりたい事」を引き出すのが難しいのでは ないでしょうか。 僕の体験では、顧客企業の担当者本人が思いついたことは何の気なしに相談してくれるので 引き出すのは楽なのですが、その担当者が役員レベルの人から要望を受けた場合などは、 担当者なりに考えをまとめてから相談にくるので、ちゃんとヒアリングしないと 変な方向に行ってしまいます。 解決策らしい解決策は思いつかないのですが、ホームページの場合だと マーケティングの考え方を基準にして、最終的にお客さんが言ってきた要望が導かれる 出発点を見つけるのがいいのかなと思います。 | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-10-17 21:29
こんばんわ．
コンサルティングって，ある程度は「必須」ではないかと考えています． がるがる様の記述にもあるように， 本末転倒なことを仰るお客様（或いはその周辺）は 概ね「自分は詳しい」という理解の下に「あとは技術的になんとかして」 な場合が多かろうかと． そういう場合，「お客さん，それは違います，むしろこうです」 と切り返しながら要件を「均す」ことが必要だったりするのではないかと． もう一方で，「こんなことやりたいんだけど，どうすれば？」な お客様もいると思います． その場合，要件を積み上げていきながら「こうは？こうは？」と ある程度導きながら行かないと「じゃこれも，あとこれも」な 話になりかねないでしょう． なので，自分もラフィン様同様「最初から」スキルの高く， お客さんとのやり取りに長けた技術者に要件定義の導入部分をお願いして， 徐々に sub system を組み立てていくのが良いのではないかと考えます． ただ，上述の「技術者」の如き人が「使いまわされる」ことにより 負荷が高くなったりして精神的疲労が蓄積したりすることも多いようです． 逆にそういう人に頼り切って他が育たなくなってしまうことも． そうなると「人と話し合うスキル」が育たなくなって困ることも．．． と，堂々巡りになるために， お客様へのコンサルテーションが疎かになるんですかね．．． | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-10-17 22:32
思うことが2点あります。
＃以下、顧客やお客様は、単に「客」と呼ぶ。 
ひとつは、常々思いますが、ソフトウェア製品は他の物理的な製品とは違い、変な製品だということです。たとえば、自動車だったら、客が車の設計に口を挟むことなんてまずないですよね。オプションに何を付けるかは選択する位ですよね。また、住宅だったら、客は建築設計士に要求はいろいろと出しますが、最終的にはそんなに奇抜な設計にはならないですよね。どこかで自制が働きます。客が防犯のためには玄関は3階に付けたい、と言い出しても、やっぱり出来上がりを想像すれば、客自身が変だと気づけます。ソフトウェアは、どこまでが奇抜かが分かりにくいので、いろいろと夢が広がるんでしょうね。 もうひとつは、客はやっぱりコンピューターの素人です。エンドユーザーコンピューティングの延長でなまじコンピューター(プログラム)の知識を持っていたとしても、それは使う立場としての知識です。作る立場の知識はないはずです。 患者が医師に、この薬を処方してほしいと頼んでも、あなたには合わないからダメです、と言われても納得するのが普通です。しかし、コンピューター屋が客の偏屈な要望を、コンピューター屋が確固として持った設計理念に基づいて拒んでも、顧客の要望を聞かないダメSEだ、という評価になってしまいます。そして、玄関が3階にできてしまうのです。 | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-10-18 00:37
しかし、2chで@ITのスレが見事なぐらいに
延びてますね。 ＠IT会議室に痛い奴がいます http://pc8.2ch.net/test/read.cgi/prog/1126325993/ みなさん、気をつけましょう。 | ||||||||||||||||||||||||||||||||||||||||||||
|
投稿日時: 2005-10-18 10:36
がるでふ。
To びしばしさん
むむぅすっかり忘れてました。昔見たはずなのに(苦笑 貼り付けていただいてありがとうございます。まさにこんな感じなんですよね。
たしかに。XPの「短期間リリースのスパイラル」だと、ずれが修正しやすいので楽ですよね。 私もあのやり方はとても好きです。
おいらの場合ですと、お客様にはとにかく「夢」を語ってもらうです。「予算度外視で、取り合えず理想形を少しうかがってもいいですか？」って感じで。 そうすると、まさにどんどんと「夢が膨らみます」(笑 で。そういった会話を注意深く聞いていると、だんだんとお客様の本音とかそーゆー部分が見えてくるので。 おいらはそうやってやるのですが…結局のところ「技術者が直接」な方法なので(苦笑 ただ、出来れば初期設計のタイミングは、可能な限り「技術者同行」で打ち合わせられるようなスケジューリングにしたいですよねぇ。 そのあたり、 ラフィンさんの
に全面的に同意です。
まぁそんなものなんだと思うです(笑 個人的には「目的に対する最短距離を切り壊してでも進む」のが好きなほうなので(笑 「技術者が打ち合わせにいけないからどうしよう」よりも「じゃぁ技術者に打ち合わせに出てもらおう」って方向性が大切なんだと思うです。 To コナンさん
ですねぇ。このケースも結構あると思うです。 で、このケースと双璧を成す(んだろうなぁと推測している)のが「本人もよくわかってないモヤモヤした理想」がある場合です(笑 どちらもまぁ、手前の分厚いベールを引っぺがす作業がしんどいのですが(苦笑
思い当たりまくり(苦笑 まぁ、可能なら複数の人たちにヒアリングかましたいところなのですが。…なにぶん自社の話ではないだけに、より一層面倒なんですよねぇ。 基本的にコネ発想は嫌いなのですが、こーゆー時だけは「クライアント会社の上のほうの役職を知っている人」が身内にいると楽だなぁと思います(笑 kaz
うい。おいらもそういいたいのですが。言い切っちゃうと敷居が高いのかなぁとか少し躊躇してましたが。でも、まぁ実際ほぼ「必須」ではあるんですよね。特にお客様とやり取りをするうえで筆頭に立つような立場にいる場合。
この辺も結構憂慮すべき問題ですよねぇ。 個人的に、このあたりの「中堅クラス以上」の人たちには ・自分の後続を育てる：そのために、目をつけた新人を打ち合わせに連れて行き、且つ前後に教育を入れる ・他人に仕事を振ることを覚える：使える人間を見つける。いなきゃ教育する ってあたりを徹底させていくです。 …で「教育スキル」に話がつながっていくわけでし。おいらの場合。 To unibonさん
でしねぇ。ただ、だからこそ「一緒に夢を追いたい」なぁ、とも思うです。 イメージは…御仕立て(和服)とかフルオーダー(スーツ)とかですかねぇ？ 「その方にあった一着」というプログラムを仕立てたいなぁって思うです。
多分「拒絶」するとお客様も「意地に」なって挙句の果てに「札束で頬をはる」ような行為に出るんだと思うです。 そのあたりは説得とか誘導とかそういう技術になってくるんですかねぇ？ ほんの少し間違えると微妙黒い話になるのですが(笑 でも、やぱし「当初からの打ち合わせの参加」が不可欠っぽい感じであると共に、なんとなく「でも打ち合わせになかなか参加できない」現状が横たわっていることが多いような感じでしねぇ。 そのあたりとかどうなんでしょう？ | ||||||||||||||||||||||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.