要求定義の手法を見直す動きが活発になってきた。これまでの開発者視点の手法では，社外ユーザー向けのシステムなどが開発しづらくなってきたからだ。旧来の手法で無理に進めれば，使われないシステムや赤字プロジェクトが増すばかり。要求工学，ユーザー中心設計，超上流など，システマティックな手法を取り入れ，いち早く要求定義の問題解決に挑んだ現場から，実践のノウハウを探った。

　「システムの利用目的や対象ユーザーが大きく変わった。要求定義の認識を改める必要がある」──。30年間にわたり，情報システム部門，ユーザー，ベンダーと立場を変えながら金融システム開発の現場に携わってきたアイネスの菊島靖弘氏（金融システム本部 副本部長）は，こう警鐘を鳴らす。

　帳票作成などの定型業務をシステム化していた時代，システムの利用ユーザーは発注者そのものであり，きちんと要求を語ることができた。ところが「Webシステム全盛の今は，社外の一般ユーザーも巻き込んでいるため，ステークホルダーの数と要求の多様性は昔の比ではない」（菊島氏）。

　しかし要求定義の現場では，「とにかく機能優先という開発者の姿勢は変わらず，ユーザー視点が欠けている。開発標準のドキュメントを型通りに埋めていくだけだ」（野村総合研究所（NRI） 流通システム二部 主任システムエンジニア 後藤英司氏）。後藤氏は過去，オフショア開発で要求からテストへとつながるトレーサビリティを見失ったことで現場が混乱し，赤字と遅延に陥った経験を持つ。その失敗からトレーサビリティの必要性を明文化している「要求工学」に注目。その後のプロジェクトでは機能偏重の姿勢を改めるのに要求工学に解決策を求めた。要求を階層構造でとらえる考え方を応用して現場に導入し，バグを激減させるなどの成功を収めた（図1）。

図1●要求定義を巡る三つの大きな問題とその解決の糸口 要求定義が難しくなってきた。要求工学，UCD，超上流といったシステマティックな手法を導入することで，難局を乗り切ろうと試みるユーザーが増えている

ユーザー中心の視点に切り替える

　機能重視の要求定義の限界から，ユーザー中心に軸足を移す必要性が高まってきた。分かりやすい例は，一般ユーザーが利用するWebシステムの新規開発だ。こうしたシステムでは，開発者主導で進めてもユーザーの振る舞いが分からないので，使ってもらえるかどうか判断できない。これを解決するのが，仮想ユーザーを設定して振る舞いを導き出すなどの手法を採る「UCD（User Centered Design：ユーザー中心設計）＊1」による要求定義だ。

　UCDの考え方は社内システムの開発にも有効だ。利用ユーザーに実際に会えるので仮想ユーザーを設定することは少ないが，「開発ありきの視点ではなく，“どうしたらユーザーが利用しやすくなるか”とユーザー中心の視点に切り替える」（スターロジック 代表取締役兼CEO 羽生章洋氏）ことで，真の要求に迫りやすくなる。

　ただし，要求工学やUCDで開発しても，その企業の経営目標などに沿っていなければ，いずれは無用なシステムになってしまう。戦略的なシステム開発が増えてきた今，システムが成り立つ前提を固めずに突き進めば，開発者も利用者も不幸になるだけだ。

　こうした問題を解決するため，システム開発に先立って，経営層を巻き込んだ要求定義のプレ・プロジェクトを進めるフレームワーク作りが進んできた。「超上流」や「Openthology」などがそれに当たる。2000年に超上流の必要性にいち早く気がつき，2002年から5000万円以上のシステム開発については超上流プロセスでの要求定義を実践しているリクルートの森下哲成氏（FITセンターセキュリティグループ 兼 FIT企画室 開発運用統括グループ ゼネラルマネジャー）は，「200件弱を超上流で要求定義してきたが，コストが10％以上膨らんだのは2件。スケジュール遅延したのは1件だけ」とその有効性を数字で示した。

　以下，要求工学，UCD，超上流の順で，いち早く要求定義の問題解決に挑んだ現場の工夫を見ていく。