皆さんはRFP（提案依頼書）を読むとき、どこに注目されるでしょうか。正直なところ、IT技術者であれば、提案依頼者(ユーザ）がITにどんな機能を求めているかが気になるところで、それより前に書かれている「目的・主旨」については、サラっと読むだけで、それ以降はもうあまり見ないかも知れません。私自身も以前、エンジニアや提案をする営業職だった頃はそうでした。RFPを見るときには、どうしてもユーザがどんな機能を求めているのか、それを実現するのに具体的にどんな技術要素を組み合わせ、どんなプログラムを想定しているのかという部分が気になり、それより前の部分は、飾りか枕詞程度にしか認識していなかったというのが正直なところです。
ユーザが欲しいのは「要件を満たすIT」なのか？
ただ、ここでちょっと考えていただきたいのは、果たして本当にユーザがほしいのは、「要件を満たすIT」なのかということです。
例えば通販サイトにおいてお客さんのこれまでの購買傾向から興味を持ってくれそうな商品を人工知能が判断して自動的にプロモーションをかけてくれるような機能であれば、ユーザもそれなりに興味を示し作る側にとっても技術的な挑戦心を刺激する楽しいモノづくりになるかもしれません。しかし本当にユーザはそうしたプロモーション機能がほしいのでしょうか？あるいは人工知能という先進技術を自分のものにしたいのでしょうか？おそらくそんなことはないでしょう。ユーザにはもっとほしいものがあるはずです
この例で言えば、ユーザがほしいのは、結局のところ、”売上”あるいは効率の良いセールスを実現すること、つまり営業の“生産性”といったところでしょう。決して機能や技術がほしいわけではなく、突き詰めれば、財務諸表に並ぶ売上やコスト利益と言った数字が目的なのかもしれませんし、企業イメージのアップや 社員の働きやすさといったもう少し柔らかいものを目的としているかもしれません。それさえ出来れば、人工知能であろうとEXCELであろうと、購買傾向の把握やプロモーションであろうと単なるアンケートであろうと、つまり技術や機能は問わないはずです。ユーザがほしいのは IT自体ではなくそれによって実現される経営の目的やKGIであるはずです。
RFPを読む際には、こうしたITの裏側にある本当の目的を正確に捉えなければならないというわけです。ちょっと以下の判例を見てみましょう。
(東京地方裁判所八王子支部 平成15年11月5日判決)
あるスーパーマーケットがシステム開発会社に，ハンドヘルド端末等を利用した商品の仕入，買掛，支払管理システムの開発を委託したが、スーパーマーケット側は出来上がったシステムを使用に耐えないとして契約を解除し，既払いの開発費用の返還を求めて裁判となった。
(スーパーマーケットの主張する不具合)
- 商品コード桁数が多く，オーダーブックが厚くなり，発注対象商品の検索に手間取るほか，ハンドヘルド端末の使い勝手が悪い
- システム停止後に再起動すると大量のログリストが出力される
- 伝票を画面で確認する際，一枚の伝票が一画面に表示されず確認しにくい
- 発注集計表の追加・修正を一件ずつ行わなければならず，一括入力できない
- 数量の入力方法が煩雑である 他２点
この裁判の結果自体は論点ではありません。判決ではスーパーマーケットが”使用に耐えない”と主張するこれらの不具合については、いずれも損害賠償の対象となる瑕疵とまでは言えないと裁判所が判断し、システム開発会社の勝訴となりましたが、注目したいのは、判決文の中に以下の一文です。
