顧客の望み通りのシステムを開発したはずなのに，なぜか満足してもらえない。彼らが語った要求はすべて正確に実現しているのに，いったい何が不満だというのだ？ そんな割り切れない気持ちを抱いた経験を持つ読者も多いだろう。
その答えは「顧客を喜ばせようと思えば，彼らが望まないものを作ることだ」というパラドックスの中に隠されている。つまり，顧客が想像すらしなかった要求を発明して提供する必要がある。今回はそんな「要求の発明」について考えてみよう。
要求の価値判断基準の把握が難しい
筆者は20年以上にわたりシステム開発に携わってきたが，顧客に心から満足してもらえる価値の高い要求を，どうやれば識別できるのかが未だによくわからない。価値が高い要求だと考えて精魂込めて作り込んだ機能が，こちらが期待するほどには喜んでもらえない。逆に，あまり価値が高くないと値踏みしていた機能が，意外なほど喜んでもらえたりする。そんなちぐはぐなことを，性懲りもなく毎回繰り返している。
もちろん，限られた時間・資源の中で最大限に投資対効果を高めようと，価値の高い要求だけに絞り込んで実現する努力はしている。しかし，肝心の要求の価値判断基準が明確に把握できていないので，思ったほど成果を上げることができない。これが，筆者を長年悩ませ続けてきた問題の一つだ。
要求の価値判断に役立つ三つのアイデア
この問題を解決するために，開発の現場で自分なりにいろいろと試行錯誤を繰り返した結果，ようやく最近になって解決の糸口らしきものが見えてきた。それが以下の三つのアイデアだ。
(1)要求開発×アジャイル開発
|
(2)要求のトリアージ
|
(3)要求の発明
|
最初の二つのアイデアについては，ここ数年筆者が携わった実プロジェクトで実践する機会があり，これらのアプローチが投資対効果を高めることに役立つと確信することができた。しかし，それだけではパズルのすべてのピースが埋まりきっていない感覚が残ったのも確かだ。
既存システムの機能の焼き直しや手作業の更なる自動化といったありふれた要求をいくらひねり出してみたところで，顧客を満足させることは難しい。顧客が手放しで絶賛するようなキラー要求を何とかして見つけ出す必要がある。でも，どうすればそんな要求が見つかるのだろう？ そんなときに出会ったのが「要求の発明」というアイデアだった。
ソフトウエアの要求「発明」学との出会い
筆者が「要求の発明」というアイデアを強く意識するきっかけとなったのは『ソフトウエアの「要求」発明学』という1冊の本との出会いだ。同書は筆者が翻訳を担当し，日経BP社から2007年8月に発刊された。
 |
| ソフトウエアの「要求」発明学 誰も書かなかった要求仕様の勘違い Suzanne Robertson，James Robertson 著 河野 正幸 訳 日経BPソフトプレス 発行 2007年8月 2520円（税込） |
実は，本書の原題は“Requirements-Led Project Management”（直訳すると『要求主導のプロジェクトマネジメント』）である。そこをあえて『ソフトウエアの「要求」発明学』という邦題にしたのは，本書の核ともいえる第5章「要求を発明する」から発せられる強烈なメッセージに，編集を担当してくださった高畠知子さん（日経BP出版局）も筆者も完全にノックアウトされてしまったからだ。
特に個人的に強烈な印象を受けたのは「発明から生まれた製品は顧客が望むものをすべて備えていたわけではない。むしろ，顧客が望みもしなかったことを実現したからこそ成功したのだ」というメッセージだった。「顧客が望まないものを作るほど喜んでもらえる」。一見矛盾しているとも思えるこのフレーズを読んだとき，これこそ自分が捜し求めていたパズルの欠けたピースの一つだと直感した。
顧客が望むものを忠実に「早く，旨く，安く」提供することが，顧客に喜んでもらうための唯一の王道だと信じていた筆者にとって，これは踏み込みざまに強烈なカウンタ・パンチを食らったような衝撃だった。しかし，本書の著者ロバートソン（Robertson）夫妻によると，歴史的に成功した製品を見てもこれは明らかなことだという。
顧客が望まないものを作って成功した製品
| 表1●登場前は誰一人そんなことを望んでいなかった発明品 | ||||||||||||||
|
まずはともかく表1を眺めてほしい。これが同書に示された顧客が望まないものを作って成功した発明品の例だ。
ロバートソン夫妻の言葉を借りると，これらの製品は「登場前は誰一人そんなことなど望んでいなかったが，いったんそれを手にすると『もうそれなしでは生きていけない』という気分にさせる製品」（『ソフトウエアの「要求」発明学』から。以下同じ）ということになる。
さて，このリストを見て読者はどんな感想を抱いただろうか。おそらく「自分たちが従事する企業向け情報システムの開発プロジェクトにおいて，この種の発明なんてできっこないし，そもそも顧客がそんなことをわれわれに期待しているとは思えない」と感じる方が大半だと思う。かくいう筆者も最初はそういった感想を持った。
ところが，よくよく考えてみると，ここには私たちが企業向け情報システムを構築する際にも適用できる重要な教訓が隠されているのではないかと思い至った。それは「顧客が容易に想像できる範囲の解決策を提供している限りは，彼らを心底満足させることは絶対にできない」ということだ。
それは，対象製品が自動車や家電などの消費財であろうが，私たちが取り組んでいる企業向けの情報システムだろうが同じことだ。もう一つ，ロバートソン夫妻の言葉を借りると「たとえ既存システムの再構築であっても発明の余地は必ずどこかにある」。
開発者が意図せずに要求を発明できた古き良き時代
さて，ここまでに「要求の発明」とは「顧客の想像だにしない要求を発見し，実現することで顧客満足度を高めること」だと位置付けた。実は，このような「要求の発明」を私たちは過去に幾度となく顧客に提供していた。もっとも，それは意図的な発明ではなく，どちらかというとフロックと呼ぶほうがふさわしい発明だったのだが…。この事実を企業における情報システム導入・活用の歴史を振り返りながら検証してみよう。
1960年代の半ばから1980年代にかけてのMIS（経営情報システム）ブームが，いわば一般企業のコンピュータ導入の黎明期である。その後1990年代の初頭までは，SIS（戦略情報システム），CIM（コンピュータ統合生産）など，ブームを牽引するはやり言葉は変わりこそすれ，基本的には手作業の自動化による効率化やペーパーレスによるコスト削減，情報のリアルタイム処理化などが情報システム導入の主目的だった。
この時代の顧客は，コンピュータに関する知識に乏しく，情報システムの導入によって自分たちの業務がどう変わるのかをおそらく明確に思い描くことは難しかったに違いない。だから，初めて情報システムを導入したときには，自分たちが想像だにしていなかった劇的な生産性改善がコンピュータで実現できることに心底驚き，次の瞬間に「もうそれなしでは生きてはいけない」という気分になったはずだ。これはある意味，顧客の想像の範囲をはるかに超えた要求を発明して成功した一例だと言えるだろう。
筆者がこの業界での最初の一歩を踏み出したのが1987年だから，この時代の最終段階（バッチ処理からリアルタイム処理への進化）は身を持って体験したと言える。その経験から言うと，この時代の開発者の技術知識＊1は顧客のそれを大幅に上回っていた。
だから「君たちのしゃべっている横文字言葉は全く訳がわからん。頼むから私にも理解できるようにしゃべってくれないか」とか「なぜ，コンピュータにはこんな簡単なこともできんのだね」と顧客から厳しく叱咤されながらも，実際にシステムをリリースして使ってもらう段になると，システムがもたらす高い付加価値に心から喜んでもらえることが多かったように感じる。
つまり，開発者自身には発明なんて発想は全くなかったのだが，その圧倒的な技術知識の格差ゆえに，顧客が想像すらしなかった価値の高い要求を，まるで開発者が悠々と「発明して提供している」ように顧客には見えていたのだと思う。そういった意味では，本当に古き良き時代だった。
| ＊1 本稿でいうところの「技術知識」とは，プログラミング言語やデータベース管理システムなどの実装技術や構造化設計やオブジェクト指向設計のような設計技術のことではなく，あくまでもコンピュータを業務にどう活用できるのかという「利用技術」に限った知識を指していることを念頭に読み進めていただければ幸いだ。 |
これからは意図的に要求を発明していかないと喜ばれない
その後，ダウンサイジング/オープン化の波と一人一台のパソコン時代の到来，インターネット革命，B2BやB2Cの形態によるeコマースの普及など幾多の技術革新を経る中で，顧客がITを日常的に活用する機会も格段に増えていき，それとともに彼らの技術知識レベルも急激に向上していった。それでも21世紀に入ってしばらくの間は（かなりその格差は縮まったとはいえ）開発者の技術知識が顧客のそれを上回ることによる無作為の要求の発明（高付加価値の提供）の恩恵を，かつかつ享受できていた時代だったように思う。
ひるがえって2007年現在，もはやコンピュータ化されていない業務を探すほうが難しい状況になった。ほとんどのシステム開発プロジェクトは「レガシーシステム」の何度目かの再構築プロジェクトだといっても構わないほどだ。つまり，何もないところにITを導入することで無作為の発明を成し遂げ，圧倒的な高付加価値を提供して満足してもらえた時代は完全に終焉を遂げた。
加えて，現代の顧客の技術知識レベルは一昔前とは比べものにならないほど向上している。下手をすると駆け出しのシステムエンジニアや，10年前に進化することを自ら放棄したベテランエンジニアが太刀打ちできないほどの技術知識を持つヘビー・ユーザーが，システム開発プロジェクトに数多く参加する時代になった。顧客は開発者が想像する以上に成長を遂げている。システム開発者が，この事実を正しく認識せずに従来どおりに顧客と接していると，手痛いしっぺ返しをくらうことになる。
これからの時代は，顧客の既存の技術知識を遥かに超越した，彼らの想像もつかないような差別化された高付加価値の要求を意図的に発明することが，私たちにはより強く求められるようになるだろう。「顧客を喜ばせようと思えば，彼らが望まないものを作ることだ」というテーマに真剣に取り組まないと，その要求を満たすことは難しいと筆者は危機感を募らせている。
顧客は要求ではなくソリューションを語りたがる
しかし，私たちが「要求の発明」に取り組む上で，何としても乗り越えなければならない大きな障害が一つある。それは，顧客は要求ではなくソリューションを語りたがるということだ。これを，ロバートソン夫妻は「ソリューション重視思考」と呼んでいる。
顧客の技術知識が豊富になったせいか，最近は彼らの語るシステムへの要望が非常に具体的な内容になってきた。例えば「代理店のクレーム申請画面で申請ボタンを押すと同時に品質管理担当者に電子メールで通知してほしい」「製造指令書に品番やロット番号の情報をバーコード化して印刷してほしい」といった具体的なソリューションを顧客に指定されることが多くなった。
私たちは，これら顧客が提示するソリューションを大して深く考えもせずに，無条件に受け入れていないだろうか？ 一度，自分の胸に手をあてて自問してみてほしい。筆者などは思い当たることが多すぎて息苦しくなるほどだ。
ここでの問題は，顧客が語るソリューションが解決対象問題の本質をつかみ取った優れた解決策ばかりとは限らないことだ。問題の本質からずれていたり，自部門の利益だけを追求した部分最適なソリューションだった場合には，それをそのまま実現することには大きなリスクがある。このリスクを回避するためには，いったんソリューションから離れてみることが必要だ。
例えば，上記の二つの要求を「代理店がクレーム申請をすると同時に，工場の品質管理担当者が異常発生原因の調査と2次災害の防止のアクションを迅速に実施できるようにする」「生産ラインで作業者が仕掛ロットの現品識別を容易にできるようにする」というふうに，具体的なソリューションから離れて，もう少し抽象的に表現してみよう。
このレベルで要求をとらえると，電子メールで品質管理担当者に市場クレームの発生を通知するよりも，クレーム申請画面から直接，生産管理システムの異常ロット網掛け検索機能を呼び出して別の異常ロットが存在しないかを調査し，それらが間違って出荷されて被害を拡大しないように即時にストップをかけるという，より優れた解決策を発見できるかもしれない。あるいは，生産ラインのレイアウトや工程間の搬送方法，置き場での管理方法などを考慮すると，仕掛ロットの現品識別のためには紙に印刷したバーコードよりも，ICタグを採用するほうがより高い効果が期待できることがわかるかもしれない。
要求とは本来このような抽象的な内容であるべきだ。少なくとも技術用語が入らない程度には抽象化しなければならない。そうすることで，具体的なソリューションに引きずられることなく，問題の本質を見極めることが容易になる。だから，顧客が提示する具体的なソリューションを要求だと勘違いして飛びつくことは，問題の本質を見誤らせたり，より優れた解決策の発明の機会を失わせたりするリスクがあることを，私たち開発者は常に肝に銘じておく必要がある。
いくら技術知識が向上したとはいっても，顧客の知識は所詮素人の手習いであり，ITの専門家には及ぶべくもない。また，及ぶようなことがあってはならない。前述のクレーム申請の例のように，販売管理システム（クレーム申請機能）と生産管理システム（異常ロット網掛け機能，ロット即時ストップ機能）のサービスをリアルタイムに連携して問題を解決できるなどとは，専門家ではない顧客には想像もつかないソリューションだ。そういった顧客自身の想像が及ばない要求を私たちが発明して提示すると，顧客はそこに大きな価値を感じて満足してくれるのである。
こういった内容が，まさしく私たちが取り組むべき「要求の発明」だと筆者は考えている。システム開発のプロフェッショナルとして，顧客から受け取るフィーに見合うだけの価値を提供するには，言われたものそのまま作るだけでは満足してもらえないことは明白だ。
「顧客を喜ばせようと思えば，彼らが望まないものを作ることだ」。今後，システム開発者には，このような「要求の発明」的な思考・行動がより強く求められるようになるだろう。そして，これが冒頭で述べた「パズルの足りないピース」を埋めていくことにつながると確信している。
今回は「要求の発明とは何か？」「なぜそれが必要なのか？」について，筆者の考えを語った。今まで通り，あるいは今まで以上に顧客の満足度を高めていくためには「要求の発明」が不可欠だというメッセージが，多少なりとも読者の心に届いていれば幸いだ。
次回は引き続き「何を発明すれば良いのか？」「どうやって発明すれば良いのか？」について考察してみたいと考えている。
| （河野 正幸＝要求開発アライアンス理事） |
