お客さまのニーズを満たすことと、お客さまの指示に従うことは、根本的に違う
先日、少々「お客さま」との付き合い方について触れました。
ですが、ＩＴ現場ではこの対策が本当に機能しないままの現場と言うのがなくなりません。ビックリするほど、まかり通っているのです。
ソフトウェア開発を生業としている、ＩＴ企業…なかでもＢ２Ｂで請負開発をしている会社では、いわゆる
お客さまのニーズ
を聞き取り、現在抱えている問題や不満をＩＴと言うツールを使って解消したり、これから行おうとしている事業をＩＴの導入によって実現しようとすることがビジネスであり、仕事の大前提となっています。
ですから、仕事の初期段階では必ず「お客さまの声」を可能な限り吸い上げます。ここで、必要な情報を入手できていなければ、後々作られるものは、絶対にお客さまが望むものになっていません。
そして、お客さまの声を吸い上げる作業は、手段はどうあれ、必ず『コミュニケーション』によって実現されます。コミュニケーション抜きに仕事は絶対に成立しません。
これは、いわば
「オーダーメイド」
で何かしらプロダクトを提供している業態であれば、どこの企業様でも同じことだと思います。服を仕立てるにしても、家を建てるにしても、必ず避けては通れない道となっています。
で。
そこで、ついつい勘違いしてしまうのが「お客さまの声」の定義です。
「お客さまの声」そのものは必ずしも、
お客さまが本当に望むものと一致しているとは限らない
という大前提を皆忘れてしまっています。これは希望していることに対する「言語化」の難しさからくるもので、お客さまに問題があるわけではありません（問題があることもあります）。
たとえばみなさん、「カレーが食べたい」という欲求を持っているとします。そして、ある店舗にて
「具体的に、どんな色で、どんな味で、どんな辛さで、どんな量で、
どんな具材が入ってて、具材ごとにどんな煮込み加減で、
どんな盛り付けが良いのか、事細かにお教えいただければ、
寸分たがわず、希望通りのカレーをおつくりします！！
（値段、応相談）」
と書かれていたとしましょう。
みなさんは、自分が思い描く、今もっとも食べたいカレーの味を、完璧に、具体的に、作り手が理解できるように、説明することが可能ですか？
なかにはカレーの作り方なんて知らない人もいるかもしれません。それでも正確に伝えなければ作ってくれないか、作ったところで希望通りのカレーではないかもしれません。
これと同じコトが現場では起きているのです。
そう、作り手はその道のプロなので、専門知識を持っていて、作り方についての情報さえそろえば、大抵のものは作れるのかもしれません。ですが、依頼する客は、作成のノウハウを持っていないかもしれません。そんな状態で、正確に、齟齬なく作り手に、自分の意思を伝えるのは至難なのです。
これは、そのほとんどにおいて「客」側の責任ではありません。作り手…提供する店側は
客は素人（知っててくれたらラッキー）
と思ってファーストコンタクトを取るべきなのです。そして、そんなお客さまを相手にすることを前提とした接し方や妥協点の模索が必要になってくるのです。
こうしたスキルの修得や、修得した人材の配置を、ＩＴ業界においては必須としていません。エンジニアやリーダー、マネージャーに義務化していないのです。そのため、ＩＴ業界では、プロダクト開発のスキルに長けてはいても、肝心の仕様を抽出し、整理するスキルに長けておらず、結果的に期待する者とは異なる形でお客さまに提供することも珍しくはありません。
「コミュニケーションが苦手だから」という理由で黙々とＰＣと向き合っていられる（と誤解されがちな）ＩＴ業界の門戸をたたく学生も多いと思います。
実際、お客さまと接点を持つのは開発チームの中でもごく少数の方たちだとおもいます。10人チームで10人が全員でお客様とお話しする…なんてことはないでしょう。
しかし、そうやって客前に出ない期間は、一生続いてくれるのでしょうか。
比較的、歴史がある…そうですね、20～30年以上の歴史を持つＩＴ企業であれば、未だに年功序列制のキャリアパスを敷いているところは多いと思います。
派遣中心の企業であれば、「エンジニア」と名乗らせていながらも、教育なんて一切していないか、したところでプログラミングのさわりだけ…なんてことも珍しくありません。中小企業にしても、教育予算まで手が回らず、プログラミングだけ多少できれば「エンジニア」を名乗らせているところは多いでしょう。
今はさすがに無いかもしれませんが、10年以上前であれば、開発履歴などを記載した「スキルシート」などに、新人であっても業歴を詐称し、３年生扱いにしてSIerに提案する営業などもいました。いわゆる「詐欺」「詐称」ですが、業界全体で横行していたので、大手SIerとの間ではお互いに見て見ぬ振りをしていたように思います。
実際に、そういう会社をいくつも見てきましたし、わずかながらそういう会社にいたこともあります。
そうして、プログラミングに毛が生えた程度の実力のまま現場に放り込まれ、右も左もわからないままオロオロしていたら、とにかくリーダーやマネージャーが「あれやって」「これやって」と指示をしてくれるので、目の前のことだけに追われていた…そうやって30代に突入してしまった方も多いと思います。
で、ちょっとほかの人より頭一つくらい飛び出てくると、リーダーやマネージャーをやらされるわけです。個人にその適性があるかどうかもわからず、また具体的にどうやってリーダーシップを発揮すればいいのか、マネジメントを実施すればいいのか、そんなことも教えてもらえずに…です。
だって、仕方ありませんよね。
そんな仕事の仕方しかさせないトップマネジメントで満足している会社ってことは、上司の人たちもみんなその環境下で育ってきたってことなので、部下に適切な指導ができるはずもありません。
こうして、入社した当時は「お客さまの前に出る」なんてことは意識しなくてよかったとしても、20代後半～30代前半に差し掛かったころには、すでに多くの後輩も増えていて、その後輩たちが「お客さまの前に出ない」代わりに、自分たちが「お客さまの前に出る」しかなくなってくるわけです。
この時、今まで顧客要件の抽出にせよ、顧客要件の整理にせよ、顧客折衝にせよ、コミュニケーションの一切にかかわってこないまま過ごしてきたエンジニアたちが、「お客さまの声」を適切に、そして十分に引き出して、お客さまのニーズを真に満たすことができるようなプロダクト開発ができるか？と言うと、そんなの
無理
に決まっています。
結果、「お客さまの言うこと」にただただ従うだけで、その背景にある本当の「ニーズ」には気づかないまま、開発が進んでいってしまいます。お客さまは、作り手に対して、本当のニーズを正確に伝える術を持っていないかもしれないのに…です。
特にＩＴは、こうしたオーダーメイドで作成する業界の中でも、ひときわ難しい分野を専攻していると思います。
服や家であれば、素材一つ、工法一つとっても、ある程度詳しく説明が可能ですし、メリット／デメリットなどもわかりやすいと思います。「〇〇工法」と言ってもチンプンカンプンですが、「そうすることによって、夏も快適！」と図や絵などを用いて言われれば、「なるほどー」となります。
ですが、ＩＴの場合「PHPで作るよりも、Javaで作った方が～」「このフレームワークがですね…」「シングルサインオンの充実によって、セキュリティ上の…」「これによってターンアラウンドタイムが従来の1.3倍向上し…」
正直、伝わる気がしません！！
いえ、まぁ私は比較的慣れているので、お客さまにイメージしやすく多くの比喩表現を用いて説明することが可能です。けれども、プログラムとしか向き合ってこなかったエンジニアの多くは、お客さま目線で言語化する術を知りません。自分たちが普段用いている、エンジニアとの間でのみ通用する会話しかできないのです。
それに、プロダクト開発ばかりに集中しすぎて、エンジニアの多くは、お客さまがＩＴ企業に「なぜ、話を持ち込んできたのか」「どんな事業を担っているのか」「どんな課題があるのだろうか」なんて背景をあまり知りたがりません。
「彼を知り己を知れば百戦殆うからず」
と言われていても、それでも何も知らない状態、…いわば、裸一貫で敵陣に飛び込むようなことを平気で行います。
結果、交渉権（というか話の主導権？）は自らになく、「お客さまの言うこと」を鵜呑みにし、真のニーズがどこにあるのかも理解しようとせず、言われたことを言われたとおりにただ遂行しようとします。
先日、ある開発部署で少々問題になっている請負プロジェクトがありました。請負契約ですので、まず"見積り"を行い、納期が決まっていて、それまでに要望通りのプロダクトを引き渡さなければなりません（請負契約は、成果物責任が伴い、成果物を納め、検収されることにより、対価（支払い義務）が生じる契約形態です）。
にも関わらず、どうやら次のような問題があって、期日が守れていない状態のようです。
・お客さまのニーズが全て拾い切れていない
・そんな状態で設計だけ無理に進めたから、品質が相当悪い
まだ、実際のプロダクトを納めるのはずいぶん先ですが、設計完了時点で納めなければならない成果物に対しては、お客さまが相当お怒り…と言うか、心配がこじれて信頼をも失いつつあるような状況でした。
そんな中、次の納品まで半年足らず…というところで、お客さま（の現場寄りの利用者たち）から、
「自分たちでも触りたいから、出来たところから納めてほしい」
と言われたのだそうです。当初の契約であればそれもかまいません。むしろそれが叶うように計画を立てなければなりません。ですが、たった今、プログラミング中で、次の納品は所詮「単体テスト」完了の状態…いってしまえば、個々の部品ごとの作成者が「セルフチェック」を完了したようなもので、まだ全体を組み合わせて不具合が無いか確認できていないような状態です。
そんな品質状態のプロダクトを、結合してテストする前に、無理やり結合して納めろというのです。これは言ってしまえば、カレーを作っている最中に、
「味見させてー」
と言っているのと変わりません。作ってる本人たちでさえ味見していないうえに、現段階では、まだ"カレールーすら入れていない！"という状況です。ただ肉と野菜を煮込んだ汁なんて、味見してもうっすい塩味が付いたお湯でしかありません。これで
「マッズイ！」
とクレームを言われても、そんなのどうしようもありません。
ですが、「お客さまの声」に言いなりになってしまって、この件を二つ返事で「ＹＥＳ」と言ってしまったのだそうです。ただでさえ大幅にスケジュールが遅れているというのに。理由は
「だって、お客さまがそう言ったから」
「お客さまが、そうしないと困るっていうので」
だそうです。マネージャーを名乗っていても、適切なコミュニケーション経験や教育課程を踏んでいなければこうなってしまいます。
通常であれば、事情を説明してお断りするところです。
私なら
あらかじめそのようなスケジュールになっていない状態で、限られた予算の中から進行していますので、これを無理に変更すると当初の計画に支障をきたし、納期に間に合わない…あるいは、無理やり納期に間に合わせるために品質が劣化する…ということになりかねませんが、いかがいたしましょうか。
とまずは社交辞令的なテンプレートで言ってみます。
それでも相手が折れない様なら、あるいは折れられない理由として、ある程度、情状酌量の理由があるようなら、
…そうですか。
わかりました。お客さまにも、お客さま内のご事情があると思いますので、極力ご要望に沿いたいとは思います。
ただし、あくまでお客さまの真のご希望は「納期までに、当初予定のプロダクトが、適切な品質で納品されること」だと思います。この契約当初のご希望を元にして私共も計画しておりますので、そこから変更を加えるとなると、スケジュールやコストを改めてご相談させていただくことになります。
まぁ、それは最後の手段としておいて。
従来の納期やコストに悪影響が出ないようにするためにも、どうしても割り込みを入れるのであれば、いくつか条件がございます。
１つ、あくまで開発の工程は単体テストです。単体テスト品質までしか、
現時点では保証できません。いきなり業務に沿って確認しようと
しても、それは次工程以降の品質対象ですので、ご了承ください。
（単体テストレベルの不良でもない限り、即対はできかねます。）
１つ、問い合わせ等については、すべて管理台帳など、記録化したもので
やり取りを行います。これは、対応時期の調整を行う際、忘れたり
誤認することを防ぐための最低限の対策になります。
個別に口頭などにとって依頼を行うのは止めてください。
１つ、基本的に、レビューいただいた設計書通りに作成していますので、
「なんか違う」「もっとこうして欲しい」などのご要望は、すべて
仕様変更扱いになります。
対応の要否については、極力ご協力いたしますが、それで当初の
スケジュールが遅延するような場合は、責任を負えません。
その際は、ご相談とさせてください。
１つ、お客さまがお試しに運用するための初期データ等はございません。
お客さまご自身で作成いただくか…こちらでテストした際のデータ
でよろしければご提供することは可能です。テストデータの作成は
当初計画分のみスケジュール化しておりますが、お客さまの確認用
データの作成は含まれておりませんのでご了承ください。
これらのことをご承諾いただけるようであれば、可能な限り調整させていただきます。
と言います。あくまで決定は相手にパスします。こちらは現実的に可能とするための条件を提示するだけです（言わないのは、（他部署の）私自身にその決定権も交渉権もないから）。
これは、こちらが断ったときの相手の心象と、相手自身が諦める時の相手の心象に大きな違いがあるため、私は常にこのような「条件付きＹＥＳ」を提示するようにしています。
さらに言うと、こんな開発ど真ん中の時点で、急にお客さまがスケジュールに口出ししてきたのは、おそらくこちら側にも責任があるのでしょう。
「前半のスケジュール管理で信用を失った」
「結果、設計の品質にもやや問題が見受けられた」
「ひょっとすると、ニーズに沿わないものが納品されるかもしれない」
「だから、納品前にできるだけ早く確認して、何かあれば
するに変更してもらおう」
なんてことを考えているのだと思われます。もっと背景を深く覗けば、ひょっとすると以前、お客さまに同じような経験があったのかもしれませんね。その結果、何千万、何億という支払いだけして、まったく使い物にならないプロダクトを押し付けられたのかもしれません。
こうした事故はよくあることです。
国のシステム相手に、大手SIer企業ですら、やらかしてしまうことです。もちろん、入札に参加できなくなる等のペナルティはあるかもしれませんが、このようなゴミと化すシステムを納品して、大金をせしめた後に逃げていく事例と言うのは、意外と多いのです。
それもこれも、お客さまのニーズや背景を知ろうとせず、守ろうとせず、お客さまの声だけを聞いて、声にただ従っていればビジネスが成立すると思い込んでいるＩＴ企業やマネージャーがいるために起きていることです。
「お客さまは、作り手の事情や作り方、その大変さに詳しくない。
本当に望むニーズを叶える仕事はするべきだが
お客さまが言葉にした内容は、まず疑ってかかれ。
『それは真のニーズに合致しているのか？』と。」
「言葉に従うのではなく、ニーズに従え。
ニーズ（希望）と言葉は別物だ。」
「ニーズは契約時にある程度決まる。
間違っていたと判断して、変更を加える時は、仕様変更だ。
それ以外で変更が加わることなんて、原則ない。
あったとしても、それは言いなりになってすることではなく、
我々のサービス精神が、契約の許容範囲の中ですることだ。」
私がよく、現場の若手の子たちに言っていることです。ほんの少しでも、こうした悲しいコミュニケーション起因の開発事故が起きないように、なってくれればいいなと、心の底から思う次第です。ていうか、こんな問題で呼び出されても、何事もなかったかのように解決するの、超大変なので。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。