「要求定義をするとき，ユーザー側の体制が整っていないことが多い。直接の利用者が参加していなかったり，ユーザー側の担当者が途中で交代するといったことがよくある」（35歳男性）

　「要求定義に積極的に関与しなかったユーザー部門が，システム・レビューやテストの段階になって意見を言ってくる」（41歳男性）

　「合意したはずの要求定義の内容を棚上げにして，ユーザーが変更を求めてくることがある。何のための要求定義だろうかと感じることが多い」（37歳女性）──

　日経ITプロフェッショナルは現在，ITエンジニアの方を対象に，要求定義の実態を調査するアンケートを実施している。開始後4日で，すでに900件あまりの回答をいただいた。その内容を見て気になったことがある。

　それは，利用者（ユーザー）への不満を訴える声が多いことだ。冒頭のコメントは，アンケートの最後に設けたフリー・コメントの欄の回答から抜粋したものである。ITエンジニアではない筆者から見ても「要求定義はかくも大変なのか」と共感させられるコメントが多かった。

　利用者への不満が多いことを感じさせられたのは，フリー・コメントだけでない。「要求定義における利用者側の問題」として選択肢を5つ挙げたところ，そのうち3つは過半数の回答者が選択した。その3つの選択肢とは，「利用者自身が何をしたいのか分かっていない」「利用者の間で意見調整ができておらず，求めてくる要求が大きく異なる」「利用者の要求がめまぐるしく変わる」である。「利用者自身が何をしたいのか分かっていない」に至っては，8割近い選択率だった。

問題視するのは解決策を持たないから

　正直，ITエンジニアがここまで利用者側に対して不満を持っているとは予想外だった。利用者側にそうした問題があるのは，日ごろの取材を通じて認識していた。しかしそれを問題視するITエンジニアがこれほど多いとは思わなかったのである。

　問題だととらえるのは，ITエンジニアの側に有効な解決策がないことの裏返しと言えるだろう。システムの設計・開発と違って，要求定義の作業は利用者とのコミュニケーションが中心である。それだけに，決まり切った方策では対処できず，悩んでいるITエンジニアが多いようだ。実際に，フリー・コメントには以下のような悩みも多数寄せられた。

　「要件を確定したつもりでも，ユーザーとの意識のずれが発生して結局，要件を変更せざるを得ないときがある。意識のずれを防ぐ方法があれば知りたい」（29歳男性）

　「どうすれば必要十分な要求定義ができるのかはケース・バイ・ケースだとしても，どのような切り口で考えるのが効果的なのか」（29歳男性）

　「開発しながら細かい要求に応えて修正作業を行うという，およそ開発手法とはほど遠いやり方でうんざりします。何とかしたいとは思いつつも，これまでそれでやって来たのだからという流れに甘んじてしまっている自分も情けないです・・・」（28歳女性）

設計・開発に問題を先送りしない

　最後のコメントにある「これまでそれでやって来たのだからという流れに甘んじてしまっている」という言葉が象徴するように，要求定義が不十分であっても設計・開発の段階に進み，そこでしわ寄せが発生するという事態が繰り返されている。これは，設計・開発への問題の先送りにほかならない。

　一方で，要求定義が一筋縄ではいかない困難な作業であるのは，誰もが認めるところ。ではどうすればよいのか。どんな方法があり得るのか。

　そこで日経ITプロフェッショナルでは，2004年1月号（1月1日発行）において要求定義に関する特集を企画している。参考にすべき方法論やテクニックなどを解説し，アンケートの結果についても報告する予定だ。IT Proサイトでも概要をお伝えしようと考えている。

　この記事で回答の一部を紹介したアンケートは，現在も実施中である（ご回答はこちらのページから）。記事の執筆編集をシステム開発になぞらえれば，読者へのアンケート調査はユーザーへのヒアリングに相当する。読者（ユーザー）の方にとって，真に役に立つ記事にするためにも，ぜひご協力いただきたい。

（中山　秀夫＝日経ITプロフェッショナル）