ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第1回と第2回では、「要求とは何か」について旅をしてきました。第3回は、要求の開発という世界を探求していきます。ここまでみなさん、楽しい旅ができていますか？この旅が、もっと楽しくなるように、さらに常識を崩していきましょう。創発号の出発です。

　次に挙げるのは、業務改善・業務改革ソリューションで失敗しないために、一般的に言われている常識です。ですが、大切なことは、これらをまずは疑ってみることです。

要求に伴う、疑うべき四つの常識

●常識１：要求はユーザーから聞き出すもの
今回までの“創発号”の旅の中ですでに、このことが「おかしいのかも」ということには気が付いたと思います。ユーザーの業務を知り、ユーザーがやりたいことを聞きだすことは、基本としては正しいでしょう。

　しかし、それだけではダメなのです。ITの使い方は、ITの専門家にしか分からないことが多いのです。また、業務を戦略的にどのように改革・改善していくかを考えている最中に、ITの活用を提案していく必要があります。実際には、要求開発の「コタツモデル」のような考え方が必要になります。コタツモデルについては、この後で説明します。

●常識2：正しい要求を聞きだすことが要件定義
正しい要求とは何でしょうか？一人のユーザーから聞き出したことが正しいのでしょうか？会社の戦略に応じた要求、現場の要求、そしてITのアイデアを入れた実現をセットにして要求を考えることが必要です。これもコタツモデルで説明します。

●常識3：要求の品質を高めるためにしっかり要件定義をやる
まず、この常識には、「正しくない要求の品質を高める可能性がある」ということを注意しなければなりません。下手をすると、要求はインプットの情報として疑わず、その品質を高めようとしてしまうからです。

　かつて、大規模プロジェクトでこんなことが起きました。業務改革をミッションであるべきプロジェクトなのに、業務改革を実施せず、業務の見える化も中途半端なまま、要求定義や設計をしているのです。その議事録は、プロジェクト管理者のほとんどが、「要件定義の品質を高めよ」と、なんとかの一つ覚えのように叫んでいるだけで、目を覆いたくなるようなものでした。

　このような場合は、インプットとなる要求自体を疑うことです。そして、要求の根拠を明確にするために次期業務を定め、無駄な要求を排除した後に、品質についてどうこう言うべきなのです。

●常識4：要求があってこそ、実現方法が考えられる
　これも見方によっては正しいのですが、見方を変えると怪しい言葉ですね。何が正しいかというと、ユーザーの要求はちゃんと聞きだして、実現方法を検討するということです。しかし、そのことに固着しすぎると、「そもそもユーザーの要求自体が、過去の実現方法の成功体験だったらどうします？」という第2回の話題になってしまいます。