顧客の理解を大事にする

システムを作る上では、顧客が望むことを正しく理解することが欠かせません。

「そんなことはわかっているよ」と思っていても、意外にそうでもないことが起きがちです。

まず気をつけたいのが「顧客がわかる言葉」を使うことです。

専門用語を使って説明したりすれば、同じ理解をしていないかもしれませんし、そもそも言葉の意味を正確に知らないけれど、文脈で何とか理解しようとするかもしれません。

言葉の理解の違いによる解釈のズレをなくすことが重要で、そのためには「顧客が使う言葉」で話し合うのが良いです。

顧客の言葉というと、専門家にとっては正しい用語の意味でなかったり、正しい使われ方でない場合もあり、こちら側も使い肉言葉になってしまうこともあります。

それでも、その使い方は間違っているからと専門家の正しい使い方を押しつけると、顧客は間違いを指摘されたようで不愉快に感じたり、素人扱いされて嬉しくはないわけです。

ITの専門家から見れば正しくないと思える使い方でも、顧客が普段使っている言葉で語ってもらうことの方が大事です。

顧客の会社用語を理解する

会話が通常成り立たせるためには、言葉の意味を双方同じ理解をすることが必要なのは上に書いたとおりです。

顧客の会社の中で使われている独自の用語であったり、社内でみんなが使っている言葉の意味も共通理解をしなければなりません。

専門家である以上、知らないとは言わずに進めたいかもしれませんが、知らない言葉をそのままにしておいては会話がすれ違うことも起きてきます。

ですから、はじめて聞いて知らない言葉はその場で確認していくようにしましょう。

なるべく早い段階で言葉の意味を聞いておかないと、ある程度話が進んでから意味を聞くのでは「今さら何を言っているんだ」と思われかねません。

わからない用語については早いうちに確認して、双方の理解のズレをなくしておくことがよりよい理解になります。

もちろん、こういう意味だと理解して聞いていた言葉が、あるときの会話で違う意味だったと理解することもあるので、すべての言葉の意味を同じ理解にすることは難しいですが、なるべく早く同じ理解になるように努めましょう。

意味の伝わりにくい専門用語を使わない

顧客との会話をスムーズに進めていくためには、ある程度専門用語を使っていくことは良いでしょう。

しかし、例えばですが、CRMといった用語を使うことは話を難しくします。

ITの専門家なら、CRMと言われてシステムのイメージをつかむことはできますが、そうでない人にはCRMと言われてピンと来る人はいないでしょう。

言葉としてCRMの意味を知っていたとしても、だからといって同じ理解ができたというのはかなり難しいでしょう。

CRMの代表的なものにSalesforceがありますが、これを使ったことがある人は顧客との関係を管理するシステムのことだなということがなんとなくイメージできますが、CRMを言葉づらしか知らない人はこのイメージがつきません。

同じ会話をしているようでも、イメージしているものが全く違うかもしれないのです。

他にもシステム運用とか冗長性ということなどもなかなか正しく伝わりません。

極力そのような専門用語を使わずに説明すると良いでしょう。

ただし、何度も使わなければならない言葉であれば、一度しっかりと意味を理解してもらうようしましょう。

一旦その言葉を理解してもらえば、その後はその専門用語を使っていくことで会話をスムーズに進めることはできます。

わかりやすく解説することを忘れない

ITを専門にする人は、背景知識が十分にあるので、簡単な言葉で言ってもその背景にこういう意味を含んでいるな、と理解することができます。

何を主に伝えたいかによって変わってきますが、システム運用なら「システムが正常に動くようにすること」とかそのために「人が張り付く必要があってお金がかかる」とか、その用語を使う背景まで正しく理解してもらうことが必要です。

自分が説明したいことが相手にとってちゃんと理解してもらうためにも、顧客にとっての利益不利益がわかるように、「何が起きるか」ということを正しく伝える努力をしましょう。

常にお客様の理解が第一なのです。

お客様の言葉を鵜呑みにしてはいけない

お客様の「こんなものを作りたい」という言葉を起点として作るべきシステムを機能分解していきます。

そのとき、目に見える機能の実現だけをゴールにすると、できあがったときに足下をすくわれることがあります。

それは、お客様の言葉や業務からは直接聞こえてこなかった要求が実現できていなかったというようような場合です。

性能が足りないとか、かえって業務が増えてしまったとか、技術レベルが高くて今の人材では対応できないとか、あまり想定していなかったことが起こります。

例えば、性能の面でいうと、1年に数回しかないけれどもとても注文が多くなる日があって、その日に処理するには性能が足りなかったというような場合。

「そんなこと聞いてないよ」

といいたいところでしょうが、求められる処理性能について質問していなかったから、最も処理が多くなる日について考え及ばなかったとも言えます。

こういう機能要件でないものを「非機能要件」と呼びます。

非機能要件を満たしていない場合、顧客満足が下がることもあるので結構重要です。

どんな業務にも見えない要件がある

業務をシステム化するときに、今の業務がどのように流れているか、ということを把握する必要があります。

そのために、現場がどんな手順でやっているのかをヒアリングしながら理解し、どういうシステムにすればいいかを考えています。

業務をやっている人はシステム構築のプロではありませんから、システムの要件として話ができる人はおらず、「こういうことをやっています」という説明を聞くことになります。

なるほどやっていることはわかるのですが、そこにはあまり出てこない話もあります。

どんな頻度でやるのか、どのくらいのスピードでやるのか、どのくらいのスキルがあるのか、など意識して聞いておかないと把握が難しいことも少なくありません。

例えば、「システム化するので私は別の作業をする予定になってます」となれば、人が全く不要になる仕組みを作らなければなりません。

そうすると、その会社ではなくリモートで保守できるような仕組みが必要になるかもしれません。

そうするとずいぶんと新しいものが必要になりそうです。

そういうことを引き出していくことが求められます。

今までの業務を変えていいところ、いけないところ

非機能要件の難しさは、現場で行われる業務を知ってはじめて出てくるものも少なくないことが理由としてあります。

今まで、エラーが起きるとすぐにお客様に連絡して確認していたとすると、システム化してそのエラーを即座に通知して、従来と同じようにお客様に聞いてもらえるような仕掛けが必要です。

また、お客様に聞いて間違いの箇所がわかったら、すぐに修正できるようなUIも必要になります。

「1日分まとめてエラーファイルを作り、修正した内容翌日一括して読み込むつもりでいたので、1つずつ変更するUIを用意していなかった」

ということになれば、お客様も会社も困るわけです。

システム化によって便利になる反面、従来できていたことができなくなってしまっては元も子もありません。

同じことをより効率的にやれるようにするのがシステム化です。

新しい業務には何らかの業務支援機能が必要になる

新しい業務を設計してシステム化すると、そのシステムに満足しがちですが、何か穴がないかをよく考えることが必要です。

頭で考えると非の打ち所のないシステムに見えても、実際に使うとボロボロだったり、ぼろくそに言われたりということも決して少なくありません。

人は新しいものを使うのにどうしても抵抗感がありますし、慣れるにも時間がかかります。

これまでならコピペできていたのに、コピペできなくなったらとても効率が下がります。

画面を開くと戻らないといけない分だけ面倒だと言われるかもしれません。

それを回避するため、一括でCSVでダウンロードやアップロードする機能が必要かもしれませんし、一覧性の良い画面レイアウトが解決策かもしれません。

システム化は一つ一つの現場の要求を拾い上げながら、業務上の最適化も実現しなければなりません。

それ以外にも、納期や予算もありますから、非機能要件を拾い上げて、そこも含めた機能を実現することがなかなか大変なことであります。

仕様変更を管理する重要性

仕様変更とは、もともと「こういう動作にしよう」と決めていたものをある理由によって変更しなければならなくなることを言います。

ところが、仕様変更をきちんと管理して関係者に共有しておかないと、例えば次のような問題が起こりえます。

• 仕様変更が影響する箇所を見落とし矛盾が起きる
• テストをする人が仕様変更を知らずテストされない
• マニュアルを書く人が変更に気づかず、マニュアルに反映されない

仕様変更を例えばメールや会議などで連絡しても、周知されないことも発生します。

特に開発途中の場合、あとでまた変わるでしょ」と思われてあまり真剣に受け取られなかったりすることもあるからです。

テストを担当する人から見れば、「どのバージョンからその仕様変更がされたか」ということも大事になります。

ですから、後できちんと追跡できるように、開発チームとして仕様変更をきちんと管理し、履歴を残しておくことはとても重要な仕事になります。

なぜ仕様変更は発生するのか？

そもそも仕様変更はどうして起きてしまうのでしょうか？

ありがちなのが、要求そのものが変わったり、あっちとこっちで仕様の矛盾が発覚したり、いざできあがってみると使い勝手が悪かったりということを解消するために起こります。

要求の変更とは、「こういう風にしてほしい」と要望を出した側が変更することです。

• 開発に入って仕様を詳細にするために話を聞いていくと、そもそも考えていたことに間違いがあることに気づき、そのまま作っても問題があるので、要求を変更することになった。
• 納期に間に合わないなどの理由で、影響のない部分の仕様を初期段階ではカットしようと考え、それに伴い仕様が変更なった。

などがあります。

仕様の矛盾とは、

• ある機能を実現するために決めた仕様が、別の機能と相反することが発覚した

というような場合に起こります。

他にも、

• UIをこのようにしようと考えていたが、いざできてみると思ったように使いやすくはなくて改良したい。
• 実装上の都合でもともと狙っていた仕様は実現に時間がかかるので、仕様変更して納期に間に合うようにする

などもあります。

仕様変更を安易に判断してはいけない理由

仕様変更しよう！と要求されたときに、「はいわかりました」と安易に引き受けてはいけません。

あなたがプロジェクトマネージャーやチームリーダーであればなおさらです。

というのは、要求というのは常に「ある切り口から見たときに改善したいこと」でありますが、別の局面から見ると、改悪になるようなこともあります。

そういうことは、違う部門で目線が全く異なる人から出ることが多いからです。

例えば、

• こういう操作にした方が使いやすい、このような表現がわかりやすい、と思っていたが、全く別の使い方を考えたらかえって使い勝手が悪くなったり、ユーザーに誤解を与えることがわかった
• 期間短縮しようと機能を落とそうとしたら、かえって修正に時間がかかり納期が遅れる
• ユーザーの利便性は上がる機能だが、セキュリティリスクが上がるため情報システム部から反対された

などです。

一面だけしか見ずに仕様変更を判断していたら、後々大きな問題になることもあります。

仕様変更は関係者が集まって判断する

仕様変更は、当初に仕様を決めたときより重い判断が求められることがあります。

上に書いた例のように、納期に間に合わなくなるとか、セキュリティリスクが新たに発覚するとなると、かえって問題が大きくなるからです。

その割に緊急度が高く、すぐに判断しなければならないことがあるとなおさらです。

開発の側から見れば小さな変更にしか見えないことも、別の立場から見れば大きいものですし、小さな変更と思われるような機能が実装上は大きな変更を伴うこともあります。

そんなことがありますので、仕様変更をするかどうかを考えるときは、関係する部門の人を集めて協議するなど、広い視点で確認することが欠かせません。

そういう多方面の分野の人の目で判断することが確実な商品開発につながります。

まとめ

仕様変更はいろいろなタイミングで要望されます。

要求するつもりだったが入れ忘れた、仕様の問題点に気づいたなど、仕様変更したい理由はさまざまでしょうが、安易な思いで受け入れた結果、納期が遅れたり、別の問題を生むことがあります。

「このくらいの変更ならたいしたことないだろうし、何とかしてあげたい」

そういう技術者の良心もあって受け入れてしまいがちですが、グッと踏みとどまり広い視点で見ることが大事と思います。

技術ばかりに注力すると失敗する

エンジニアとして技術を磨くことは不可欠ですので、ついつい技術ばかりに目が向けがちです。

しかし、本当に技術者として成功したいなら、経営やマーケティングなどの知識を持つことが不可欠です。

なぜかといえば、お客様の課題を理解しないでお客様の望むようなものは作れないからです。経営やマーケティングの素養がないと、お客様の課題を正しく理解できないことが多いです。

お客様の困りごとの理解が足りないと、「要求仕様」だけ見てを作ることになり、結果的にお客様の困りごとを解決できないシステムを作ることがあります。

そこで経営の本を読む、マーケティングについて学ぶことで、お客様の困りごとにまで目配りしたり、お客様の課題をより現実的に理解できるようになります。

これがあってはじめて、お客様の望むシステムを作れるようになります。

言われたように作って失敗した日々

僕がプログラマとしてシステム開発に携わっていた頃、こんなことがよくありました。

見積もりしたら納期に間に合わない、納期短縮は難しく、納期の延期も了承されない。

何とか、目標の納期に間に合うようにしなければならない、という状況に追い込まれたとき、開発チームは納期に間に合うように機能を削減して納期に間に合うように調整を始めました。

各機能の見積が出ていますので、どの機能を減らすとどのくらい工数が削減できて納期に間に合うかをシミュレーションしていきます。

そして数字上ちょうど良くなる機能の削減を提案していきました。

その結果、目標の納期に提供することはできましたが、使うお客さんからは期待通りのものではないと苦情が来ました。

問題は現場での使われ方を考えずに、納期に間に合うような機能を削ったことでした。

こういうプロジェクトを数個経験し、お客様の事情を理解しないシステムの提供に無理があると悟りました。

人を仲介すると知りたいことが聞けない

エンジニアといえば、開発拠点にこもって毎日パソコンに向かって仕事をしている人は多いと思います。

営業の人や企画の人と打ち合わせをするのは一部の限られた上層部の人であり、ましてやお客様のところに顔を出す機会が少ない人も多いでしょう。

僕はまさにそのタイプでした。

営業の人とディスカッションするとか、お客様に出向くのは自分の仕事じゃないと思ってました。

ところがそうなると、営業や企画の人が聞いた要望を「間接的に」聞くことになります。

仕様を決めるに当たって

僕：「こういう使い方になると思うので、このような仕様でいいでしょうか？」

営業：「顧客に確認します。」

というやりとりをします。

もちろん、営業だからといっていつでもお客様に会いに行けるわけではなく、数週間後、時に1，2ヶ月後に答えが返ってきます。

営業：「お客様は、それで大丈夫だと言っています」

僕：「それは良かった。その仕様で進めます。」

とまぁ、こんな感じで作るんですが、できあがって使ってもらうと想定していたお客様の使い方が全然違ったりします。

質問した仕様の部分はもちろん、それ以外もダメだったりします。

要は、人を仲介して質問に行ってもらっても子供の使いのようになり、本来知りたいことを持って帰ってくれていないということです。

お客様に向き合えるようになる

こんなことを繰り返していてもなかなか本当のお客様の困りごとを聞くことはできません。

お客様との窓口になっている人にはもう少しこちらの聞きたいことを理解してほしいと思うものの、彼らはシステム構築のプロではなく、あくまで営業パーソン。

どうがんばっても、技術者が求めることを正確に伝えることなどできません。

そうなると、自分で言って聞いた方が早くて確実！という気持ちになります。

そう思って、自分でお客様のところに出向くようになりました。

ところが、そうやってお客様に話しを聞きに行くと、僕が聞きたいこととは全く別の課題をあれこれ言われて、「ええ？今まで聞いていることと違う！」ということにちょくちょく遭遇します。

実際問題、お客様の課題を正しく拾うのは難しいんですね。

対応するお客様も、営業の人が対面していた人と、僕が話を聞くような現場の人では、そもそも困りごとのレベルが違う、という問題もあります。

とにかく、自分で聞くと情報の正確さが違うことを実感します。

お客様のところに行くには準備が必要

直接お客様のところで話を聞くようになるには、それなりに準備が必要です。

準備というのは、何を聞くかとかそういうことの他に、お客様との話し方や、質問の仕方などのビジネス的な基本スキルに加え、担当者がやっている業務への理解する力や、困りごとを把握する力などが求められます。

こういったものは一朝一夕には身につきませんので、時間をかけて少しずつ身につけておくことが必要です。

僕自身エンジニアとしてやっていたので、最初はお客様のところに行っても必要な質問ができずに戻ってから再度聞かなければならないこともしばしばでした。

あとで聞くというのはお客様にとっても面倒ですしすぐに答えが返ってきません。質問内容を上手に伝えることも難しいです。

その点で、どれだけ現場できちんと情報を把握しておくかが大事になります。

その力を身につけるためにも、技術以外の本を読んだりセミナーに参加して知見を広げておくと良いです。

この人が実現したいことは何だろうか？

この人が大事にしているのは機能だろうか？コストだろうか？納期だろうか？

社内の説得に困っているのだろうか。

そういった、相手が解決して欲しいことを的確につかみそれを解決できるように進めて行くことは相手の信頼を得ることにつながります。

「あの人に頼んでおけば、私のやりたいことを実現してくれる」

そう思われたら勝ちです。

相手が望むことがつかめなければ仕事にならない

相手の望むことをつかむ、と聞けば、そんなの当たり前でしょう、と思うと思います。

ただ、本当に相手の望むことを聞き出してつかむ能力は一朝一夕には身に付きません。

それどころか、下手をすれば「あいつはわかってない」と思われかねません。

世の中には相手のことを敏感に感じ取って、それはこうやって解決できますとという提案をできる人たちがいますが、誰でもできるわけではありません。

特にエンジニアは、どうやって実現するかばかりを考えてしまって、本当にお客さんが望んでいることを見落としがちです。

どうやって実現するかはエンジニアの大事な仕事ではありますが、その前に相手の望むことに添えるような能力を身に付けましょう。

システムの都合を理由にしない

ITエンジニアはついついシステムのせいにして理由を言いがちです。

例えば、

OSが・・なので△△できません。

クラウドサービスが××なので、○○できないです。

こんなことを言っていませんでしょうか？

お客さんは「できない」理由を聞きたいわけではないのです。

どうしたらできるか知りたいのです。

ですので、できないことや懸念があるなら、「できます！ですが、こういう懸念があります」という風に制約や難しい理由をあとで付けるのです。

○○すればできます、ただし時間がかかります。

今使っているものだと××できませんが、△△に変更することでできるようになります。ただ、かなり手戻りになります。

といった感じです。

前提条件はに縛られすぎてはいけない

相手が望むことが「できる」か「できない」かを考えるとき、実現の前提条件が自然と頭の中にあります。

それには「リリース納期」「開発予算」「投入できるリソース」などがありますが、これらはプロジェクトにとってどうやっても変えられないものではありません。

エンジニアの立場で言えば、納期などは絶対に変更できないものだと思うことも多いのですが、立場が違う人から見るとそれは全く制約でなかったりします。

ましてやどんな技術を使うか、どんなサービスを利用して実現するか、といったことはエンジニアが勝手に思っていることも少なくありません。

一旦、自分の中に勝手に思っている制約を取っ払って、何が制約条件かを聞くところから始めることも必要です。

要求を確認しながら進める

相手が実現したいことに対し、自分の理解が正しいかをちょくちょく確認しましょう。

理解しているつもりでいても、細部で違うことがよくあるからです。

実現方法を少しずつ明らかにしていく過程で、開発にかかるコストやできあがる納期に加え、実運用にかかる費用なども少しずつ見えてきます。

開発費がこのくらいになりそうとか、Webサービスやアプリのイメージはこんな感じですとか、作った後もこのように改良していきますとか、いろいろなことを決めていきます。

その中で、自分が理解していてこの実現方法でいいと思っていても、具体的にすればするほど相手の理解とのずれが見つかってきます。

なぜかと言えば、これまで非常に簡単な言葉でしか相手の要求を聞いていないからです。

ところが、具体的に実現方法を決めていくと、「それは考えていることと違うなぁ」とか「それだとダメなんだよ」というような話がいろいろと出てきます。

これを適宜聞いて軌道修正していくことが欠かせません。

よくあるケースは、できあがってから「それは違う」と言われること。

こうなったらプロジェクトは大失敗です。

望まれていることと実現できたものにズレがあるのは避けられませんが、そのズレをいかに小さくするかが大事です。

そのためにも、都度確認していくことが欠かせない作業です。

そうやって相手の望みと自分の理解のズレを修正していくのです。

要求者の求めることを明確にすることから始める

何か新しいサービスを作ろうとしたとき、要求をとりまとめる作業はとても重要です。

わかったつもりになってどんどん作り始めることも多く、できあがってみるとどうにも要求者の求めるものになっていないことも起こりうるのです。

ですので、要求者が何を求めているのか、そこを明確にしていく作業からはじめる必要があるのです。

そこで問題になるのは、実は要求者自身でも自分の求めるものがちゃんとわかっていないことも多いという事実なのです。

そこを一つ一つ解きほぐしていく、そんな作業が欠かせません。

要求を整理する重要性

商品やサービスを作っていくとき、売れる商品に作り上げるためには、求められているものを正しく知る必要があります。

求められているものが明確にならない限り、ものづくりは正しい方向に進まないのです。

あるいは正しいと思っていたのに、作り上がってから「それはオレが欲しいといったものと違うぞ」と言われてミスマッチに気づき大きな損害を出してしまうのです。

製品ができあがってからその間違いに気づくことほど、残念なことはありません。

その製品を望んだ人にとっても、製品作りに情熱をかけた開発者にとっても、不幸なことなのです。

しかも、間違った認識で作り始めた製品の間違いに気づいても、正しい方向に修正するのは簡単なことではありません。

なぜかと言えば、製品の開発に着手しある程度完成するところまで進んだら、誰もそれをゼロから作り直すことを望まず、なんとか問題のあるところだけ軌道修正して目的に沿うように作り替えたいと思うのが常なのです。

そのとき、無理矢理つじつまを合わせようと改修するので、何とか使えるものにはなっていても、望むような使い勝手の良いものには仕上がらないことが多いからなのです。

要求とは不便や不満の裏返し

このように要求をしっかりつかむことはとても大事なことです。

では、要求って何でしょうか？聞くまでもなくみなさん理解していることと思います。

人がこうして欲しいと思うことが要求ですね。

多くの製品やサービスでは、「オレはこういうものが欲しい」とか「こういう風にできるようにしてくれ」といった要望を元にすることが重要です。

なんとなく「こんなものがあれば売れるんじゃないか？」という根拠のないアイデアではなく、「こういうものが欲しい」とある程度の人が思っていることが大事です。

それは、そういう要望がないと売れないからです。

要望というのは、そこには不便や不満があるから生まれるのです。

そういった不便や不満を解消するものが製品やサービスなのです。

そしてその不便や不満が大きいほど、解消する製品やサービスの価値は高まるのです。

すごく当たり前のことですが、作ることが主目的になり意外と要求を見落としがちなのです。

要求の前に知るべきこと

要求をしっかりつかむことが大事なことはおわかりいただけたかもしれませんが、意外と忘れがちなことがあります。

それは「誰のどんな悩みを解決するのか？」という視点です。

誰のどんな悩みを解決するのかを知らずに作ると、作り方を間違えてしまいかねないのです。

たとえば、薬を飲み忘れるので忘れないようにするサービスを考える場合、健常者であればスマホのアプリを作って通知機能で飲み忘れを防止するというのはひとつの解決方法になりますが、

痴呆の人が薬を飲み忘れるのを防止したいのであれば、スマホ自体を見てもらえずもっと違う解決方法が必要になります。

具体的な利用者のイメージをしっかり持つことが、要求をまとめる際には重要になります。

要求者の思いをしっかり引き出す

要求をまとめる過程で注意したいのは、要求者から要求をしっかりと引き出すことです。

私の体験でも、製品やサービスができてから（できあがりが近づいてから）、「これだと○○の時に使いにくいので良くないです」といった意見が出てくることが少なくないのです。

テレビのCMではないですが、「早く言ってよ！」と言いたいところです。

ところが、そうはいっても要求者がすべての思いを出し切れるかというと、それは結構難しいのです。

要求する人と、その要求をまとめる人、実際に開発する人など、いろいろな立場の人がそれぞれの立場で「こういうときはどうするの？」といったことを聞き出すことで、隠れていた要求が見つかることも多いのです。

「要求者は要求のほんの一部しか言わない」ということを理解した上で、「要求を要求者から引き出す」という意識が欠かせません。