要求定義は，システム開発プロジェクトを成功させる重要なカギの1つ。このことに異論を挟む人はいないだろう。一方で，要求定義がうまく行かないことが原因で，手戻りが発生したり，利用者（ユーザー）が満足しないシステムを構築してしまうといった問題が頻発しているのもご存じの通りだ。

　ではITエンジニアは要求定義に関して，どんな悩みや問題を抱えているのか。拠り所となるような手法や方法論を持っているのか。どんな成果物を作っているのか──。

　そうしたことを調べるために，日経ITプロフェッショナルは11月4日～18日にかけてWebサイト上で「要求定義に関する実態調査」を実施した。途中経過として，一部を11月11日付けのこのコラムで報告した（記事へ）。今回は，調査全体の最終結果をお伝えする。なお期間が短かったにもかかわらず，1398人の方にご協力いただいた。この場を借りて，感謝の意を表したい。

悩みの上位3位を「利用者側の問題」が独占

　まずは「要求定義に関する悩みや問題」から。象徴的だったのは，利用者側の問題を指摘する声が大きかったことだ。途中経過のコラムでも報告したことだが，最終結果でも変わらなかった。

図1●要求定義に関して，困っていることや問題を感じていることは何か（回答数1398，複数回答）
「利用者側の問題」は赤，「開発者側の問題」は青で示した。上位3位までを，すべて「利用者側の問題」が占めた
　それを示す調査結果が図1[拡大表示]である。「要求定義に関して，困っていることや問題を感じていることは何か（複数回答可）」という問いに対する回答を示した。分かりやすいように，「利用者側の問題」は赤い棒，「ITエンジニア自身の問題」は青い棒で色分けしている。

　一目瞭然だが，「利用者側の問題」が上位3位までを独占した。内容は，「利用者の間で意見調整ができておらず，求めてくる要求が大きくことなる」（75.8％），「利用者自身が何をしたいのか分かっていない」（59.6％），「利用者の要求がめまぐるしく変わる」（56.4％）である。

　「ITエンジニア自身の問題」である「設計開発に引き継ぐときに情報の漏れや誤解が生じる」（50.6％）や「要求変更の管理が難しい」（48.5％）といった回答も少なくなかったが，上記の「利用者側の問題」に比べると数字に明らかな開きがある。

　フリー・コメントでも「利用者側の問題」を訴える声が多かった。「最近はユーザー企業の企画部門が主導する案件が多いが，彼らは理想論に近い要求を出してくるため，現場の利用部門と食い違う。結果として，要求定義後に利用部門から改善要求が多発し，ベンダーにとって悲惨な状況が続く」（40歳SE），「完成したシステムを見てから要求を追加すればいいと考えている利用者がいる。何のための要求定義かむなしくなる」（40歳プロジェクト・マネジャー）といった具合である。

実践的ノウハウが不足している

図2●あなたが属している会社や部門に，要求定義の標準的な方法論（手順や成果物）はあるか（回答数1398）
過半数が，会社または部門に「標準的な方法論がある」。特にその割合が高かったのは，コンピュータ・メーカー（74.7％）とシステム・インテグレータ（62.8％）だ

図3●実際に全社標準や部門標準の方法論を利用しているか（回答数736）
「利用しないケースの方が多い」という回答が約4分の1あった。企業に標準があっても，万能ではないようだ
　「ITエンジニア自身の問題」よりも「利用者側の問題」を指摘する声が大きかったのはなぜか。その要因の1つは，別の質問に関する回答結果から見えてくる。

　「あなたが属している会社や部門に，要求定義の標準的な方法論（手順や成果物）はあるか」という質問に対して，会社か部門のいずれかで「標準的な方法論を持っている」と答えた人の割合は52.7％だった（図2[拡大表示]）。さらに「標準的な方法論を持っている」と答えた人に「実際に利用しているか」を聞いたところ，「すべてのケースで利用している」が13.1％，「すべてのケースで利用するわけではないが利用する方が多い」が60.2％だった（図3[拡大表示]）。一方で，「利用しないケースの方が多い」は25.1％，「まったく利用しない」は1.6％に過ぎない。つまり過半数の人は標準的な方法論を持っており，その大半は実際に利用している。

　この結果から，多くの回答者が“それなりに使える”方法論を身に付けているため，「ITエンジニア自身の問題」をある程度クリアできており，方法論では解決しがたい「利用者側の問題」が相対的に浮かび上がった，と考えられる。方法論が“それなりに使える”ことの裏付けとして，「全社または部門で，要求定義に関する方法論を標準化した方がよいと思うか」という質問に90.4％が「標準化した方がよい」と答えたことも挙げておく。

　ただし逆の見方をすれば，標準的な方法論を持っていても，「利用者側の問題」を解決する実践的ノウハウは不足していると言える。ここで言う実践的ノウハウとは，利用者とのコミュニケーション・ギャップを埋める，利用者のやる気を引き出して積極的に協力してもらうといったこと。方法論を実践するためのコミュニケーション基盤となるもので，いわば「ヒアリング・テクニック」である。このノウハウを身に付けることがITエンジニアにとって極めて重要だ。

方法論の整備が急務の課題

　実践的ノウハウの修得だけでなく，方法論の整備も急務の課題である。半数近くの人が標準的な方法論を持っていないのに加えて，たとえ標準的な方法論を持っていたとしても合計で26.7％が「利用しないケースの方が多い」または「まったく利用していない」と答えた（図3[拡大表示]）。方法論そのものに改善の余地が大きいと言える。

図4●要求定義の現場では，主としてどんな方法を利用しているか（回答数1398）
最も多かったのは「社内標準や部門標準をカスタマイズして利用している」（31.8％）。「方法と呼べるものはない」という答えも18.6％に上った

図5●要求定義で，どんな種類のドキュメントを作成しているか（回答数1398，複数回答）
「外部インタフェース」，「業務ルール」，「性能や運用性，信頼性などの非機能要求」は，要求定義の段階でまとめておくべき重要な要求だが，それぞれ44.0％，38.8％，35.6％にとどまった
　方法論に改善の余地が大きいのは，他の2つの質問に対する回答からも分かる。1つは，「要求定義の現場では，主としてどんな方法を利用しているか」という質問。これに対して，「社内標準や部門標準の方法論をカスタマイズして利用している」という答えが31.8％で最も多かった（図4[拡大表示]）。

　もう1つは，「要求定義で，どんな種類のドキュメントを作成しているか」という質問だ。他システムとの接続方法をまとめた「外部インタフェースの仕様書」，業種・業務およびユーザー企業固有の慣習や規則などを表した「業務ルールを定義した文書」，応答速度や信頼性などの「非機能要求」の3つのドキュメントに関して，「作成している」と答えたのはそれぞれ4割前後に過ぎなかった（図5[拡大表示]）。

　これらの成果物に関する情報の多くは，要求定義の段階で利用者から聞き出したり調べたりするため，要求定義書の一部として作成しておくべきである。にもかかわらず作成している回答者が4割前後にとどまったのは，要求定義の成果物が明確に定まっていないこと意味している。

現場のノウハウを生かす

　結論を整理すると，要求定義のためにITエンジニアが特に高めるべきスキルとして，「ヒアリング・テクニック」と「確立された方法論」が浮かび上がった。そこで日経ITプロフェッショナルは2004年1月号（1月1日発行）の特集「要求定義の“定石”」で，それらのスキルについて解説した。取り上げたのは，データ中心型アプローチに基づいた日本IBMの「ADSG」という方法論，オブジェクト指向の考え方に則った「RUP（Rational Unified Process）」の方法論，ベテランITエンジニア50人以上への取材を通じて明らかになった「ヒアリング・テクニック」などだ。

　このうち「ヒアリング・テクニック」について，一部を抜粋して紹介しよう。「ユーザー企業にシステム化の目的を明確にしてもらい，経営トップから現場に周知徹底してもらう」「現行業務の大まかな流れや問題点などの基本的な質問事項についてはアンケート形式で事前に回答してもらう」「キーパーソンが参加する全体会議はなるべく研修所やホテルの会議室などに場所を移して実施する」「業界紙を読んだり，ユーザー企業から業務マニュアルや現行システムの仕様書，伝票類などを借り受けたりして，業種・業務知識を深めておく」「利用者と議論しながらその場で図を作成する」といった具合である。

　こうしたヒアリング・テクニックは，現場で活躍している読者の皆さんも豊富にお持ちのことと思う。ぜひコメントとして書き込んでいただきたい。このコラムが情報共有の場になれば幸いである。

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