要求は定義可能か

SONYの「ウォークマン」は1970年代の後半に初めて発売された。電池駆動で、ステレオ・カセットテープで、ポケットに入りそうなくらいに小さかった（でも実際にはそこまで小さくなかったので、ストラップで肩から下げるか腰のベルトに通して使ったが）。テープなのに録音はできずに再生専用、そして、スピーカはなく軽量ヘッドフォンのみで聴く方式だ。

こんな偏った機能を持つ奇妙な機械は、それまで誰も考えたことがなかった。風変わりなこのオーディオ機器は、実際には既存の技術だけを組み合わせて作られたものだった。が、市場に現れてから、はじめは徐々に、しかし次第に爆発的に売れるようになり、最終的にそれは新しい一つの音響機器のジャンルの代名詞になった。

私は要求定義の仕事に向かうごとに、このウォークマンのことを思い出す。私も普及しはじめた頃に買って、すぐに気に入った。もともと音楽が大好きな人間なのだ。とはいえ、“持って歩ける個人用音楽環境”というものが、どれほど自分の風景を変えてみせるものか。それは体験してみるまでは分からなかった。私はそのような道具を求め、欲していた。そう、『要求』していたのだ。しかし、自分で実際に手に入れるまでは、自分の『要求』の中身を具体的に定義することができなかったことも、確かなのである。

システム開発の仕事は、知っての通り、アナリストによる『要求定義』の作業からはじまる。エンドユーザの要求事項を分析し、どのような機能を持つシステムが必要かを、客観的に定義してみる作業だ。しかし、はたして、要求定義は本当に可能だろうか？

こんなことをいうのも、ＥＲＰパッケージをベースにしてしか発想しない「業務コンサルタント」が、あちこちでAs isとTo beを振り回してフィット＆ギャップ分析をやる光景が、この5年、いや10年くらい前から定着してしまったからだ。

ユーザの要件を定義し、それがパッケージの提供できる機能範囲とどう重なり、どうずれるかを判断する。それがフィット＆ギャップだ。そして、パッケージでカバーできない要求は、あきらめるか（これを彼らは「ＢＰＲ」と呼ぶ）、別の方法で回り道をして実現するか（「ワークアラウンド」）、さもなくばプログラムを追加開発するか（アドオン）、どれかを選ぶことになる。

なるほど、けっこうだ。だが、ユーザが要求するものを実現し提供することが、システム・ベンダーの役割だという無言の前提が、そこにはある。しかし、ユーザが求めている（と言っている）モノは、本当にユーザが必要としているものなのだろうか。ユーザはそれほど、自分が何を必要としているのか正しく認識できるのだろうか。

ウォークマン出現以前の人たちは、ラジカセや携帯できるテープデッキを買っていた。それが自分たちのほしいものだと思っていたのだ。しかし、本当に何がほしかったのかは、それが具体的な姿をとって目の前に現れてみるまでは、いや、それどころか自分で実際に使ってみるまでは、分かっていなかったのだ。

システム・アナリストやコンサルタントの仕事とは、機能のメニューをユーザに見せて、その中からほしいもの選ばせることで終わっていいのだろうか？　それはパッケージという釈迦の掌の上で踊っているだけではないか。ファミリーレストランのウェイトレスと、どこに違いがあるというのだろう。

有能なアナリストとは、ユーザが「ほしい」と言ったものではなく、ユーザが真に必要としているものを提示できる人でなければならない。しばしば顧客は、自分が本当に欲しいものを知らない。要求と必要は、実はちがうのだ。

たとえば、自分は'70年代はじめの人間に向かって、「ウォークマン」を要求定義できるだろうか。相手はその価値を、実物経験抜きで、理解できるだろうか。新しいジャンルを創造するような仕事は、顧客の意識の中に浮かんでいる要求を分析するだけでは決して出てこないことを、私たちは覚えておいた方がいいと思う。ウォークマンを定義することとは、つまり新しいウォークマンを発明することなのだ。