顧客が本当に必要だったもの

突然ですが、あなたは以下の画像をご存知でしょうか？ "顧客が本当に必要だったもの"を実現することの難しさを表した風刺画

dic.nicovideo.jp

顧客が本当に必要としているシステムを実現することの難しさを端的に表したIT業界では非常に有名な風刺画です。右下にある顧客が本当に必要だったものを、顧客含め誰も正しく理解できておらず最終的に残ったものは使い物にならないシステムと高額な請求という何とも残念なオチです。

実はこの風刺画は、1970年代アメリカの産業界で既に広まっていた有名な風刺画が大元になっていて、それがIT業界向けにアレンジされたもののようです。

では何故元々別業界で産まれたこの風刺画がIT業界では非常に有名で、かつシステム開発に携わる多くの人々が共感に至るのでしょうか。それは単に顧客自身が、自身にとって必要なものを正しく把握していないという点を出発点として、関連する人々の理解に誤りが生まれることをシステム開発に携わる人々は理解しているためである。とHapInS株式会社は考えております。

実際のところ、システム開発の失敗原因の約4割が要件定義関連という調査結果もあり、開発会社である我々HapInSの感覚値と乖離はありません。

開発失敗の最大要因は要件定義に関わるものという示唆①

開発失敗の最大要因は要件定義に関わるものという示唆②

システム開発が失敗する理由、「動かないコンピュータ」から分かったこと | 日経クロステック（xTECH）

そしてこの図に加えて、あなたが次に意識すべきことは要件定義の最終責任は顧客側にあるという点です。実際に情報処理推進機構が提供する超上流から攻めるIT化の原理原則17ヶ条 No.9においても要件定義は発注者の責任であると明記されています。

なぜ要件定義で失敗するのか

では何故要件定義はこれほど失敗してしまうのでしょうか。あなたが発注者側としてシステム開発プロジェクトに携わった経験が無い、または経験が乏しいという前提で説明してみたいと思います。

あなたは医者ではない

「熱が出ました。インフルエンザだと思います。タミフルください」と患者に言われ、ただ「分かりました。ではタミフルを処方します」と言う医者をあなたはどう思うでしょうか？医者でも無い患者の言うことを鵜呑みにし、ただ薬を提供するだけの医者に存在価値を感じることができたでしょうか。多くの場合、「症状聞かないの？」「検査しないの？」と感じたのではないかと思います。

システム開発においても同様のことが言え、顧客に「在庫不備が多発し失注に繋がっています。在庫管理システムを作ってください」と言われて、「はい分かりました。在庫管理システム作りますね」という開発会社では、あなたにとって本当に必要なシステムを提供することは難しいでしょう。

あなたは医者である開発会社に症状を伝え、何が本当の問題なのか診断するよう依頼し、解決のための治療方針を徹底的に聞くようにすることが失敗しないシステム開発への第一歩です。

あなたは自分が本当に欲しいものを理解していない

もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。

この言葉は、初めてガソリン自動車を製作したヘンリー・フォードが残した言葉とされており、自動車を知らない顧客は自動車を作ってくれと言うことは出来ないということを示唆しています。ヘンリー・フォードは目的地に「もっと速く到着したい」という本質的なニーズに着目することで、顧客が望む「馬より速い車」を提供することができたのではないでしょうか。

ただ実は、顧客の真のニーズは「大切な人」と会話したいから「もっと速く到着したい」のかもしれないし、「魚が腐る」から「もっと速く到着したい」のかもしれないですよね。あなたが本当に必要としていたのは「もっと速く到着する手段」ではなく「電話」や「防腐/冷凍技術」だったのではないでしょうか。

あなたには現場の本当の声が届いていない

さて、ここまでの説明であなたは「システム開発のスペシャリスト（≒医者）」でもなく、そして「本当に欲しいものを理解していない可能性」すらあることが理解できたかと思います。

ここで考えていただきたいのは発注者側の担当であるあなたと同様に、現場の人たちもこれらの事実を理解していない可能性があるという点です。そのような状況下においては、現場の人 → 現場責任者 → あなたと伝言ゲームのように伝えられた情報が、本当の意味で信頼に足る情報である可能性は低いと考えた方が良いです。

纏めると、現場の人たちは「本当に必要なもの」を言語化できておらず、そもそもそれが「本当に必要なもの」なのかも分からず、そしてあなたに「歪んで届く」可能性に富んでいるのがシステム開発であるということです。

よくある失敗例

現場で全く使われない機能

アメリカの調査会社が発表したあるレポートによると完成した機能の64%は使われないという衝撃的な事実が記されています。この調査は社内利用向けの4つのシステムを分析したものであり、分析内容としては少々弱いですが、開発した機能の多くは使われないことが推察できるかと思います。

仕様変更に要した多大な労力と費用

システム開発では、発注時の仕様に基づき仕事を完了させる（≒完成したシステムを納品する）請負契約が一般的です。しかし、請負契約では発注時の仕様を変更することが難しく、仕様の変更には多大な労力と費用がかかるリスクが存在します。当然顧客側と開発会社間での調整が必要になるのですが、費用のかかる話なので拗れてしまう可能性も十分に存在します。

少々規模が大きい話ですが、旭川医科大学とNTT東日本や野村総研とIBMによる開発失敗の責任が誰にあったかを問う裁判にて、顧客側が全面敗訴となった事例なども存在し、要件定義や仕様変更の難しさを改めて考えさせられます。

開発経験の無い or 少ないあなたが本当に必要なシステムを手に入れるには

さて、システム開発における要件定義の難しさとその理由について、ある程度ご理解いただけたのではないかと思います。では具体的にどうすればシステム開発経験の無い or 少ないあなたが、あなたのミッションであるシステム開発を成功させることができるのでしょうか。

我々HapInSは要件定義工程をお客様と同等以上の当事者意識を持って対応してくれる会社であるか、要件変更に対し柔軟に対応できるアジャイル開発が可能で、それを実現する契約形態であるラボ型契約プランを持つ開発会社を選ぶべき。と考えております。

HapInSなら、あなたに本当に必要なシステムを提供できる理由

HapInS株式会社の強みは、お客様の本質的な課題を特定し解決に導くコンサルティング能力に加え、確かな技術力も兼ね備えたエンジニアが多数在籍している点です。そのため、お客様と同等以上の当事者意識を持ち、お客様以上にお客様の事業に詳しくなることを目標としつつ、変わりゆく事業環境やご要望を適切にシステムへ反映することが可能です。

お客様にとって最も価値のあるシステムを提供するため、基本的にアジャイル開発&ラボ型契約での対応を推奨しておりますが、会社のご事情や案件特性に応じて請負開発を行うことも可能ですので、是非お気軽にご相談いただければと思います。