どのようなシステムが必要なのかを洗い出す「要求定義」は、システム開発で最後の難問といっても過言ではない。要求定義の失敗は、プロジェクトの納期遅れやコスト増に直結する。にもかかわらず、効果的に進める手法はいまだに確立されていない。
 システムが大規模化して経営との結びつきが強くなるにつれて、要求定義の難易度は高くなる一方だ。ここに来て、最後の難問にメスを入れようと果敢に挑むユーザー企業やシステム開発ベンダーがようやく登場。要求定義の“最適解”が少しずつ見えてきた。

(森側 真一)

 「やっと完成した」。電子機器の販売などを手がける美和電気工業の田澤正敏企画開発部長は、ほっと一息ついた。約1年半にわたり、かかわってきた営業管理支援システムの構築が5月末にようやく完了したからだ。

 社員約300人の同社には、情報システム部員が実質1人しかいない。情報システムの開発作業は、ほぼすべてをベンダーに外注している。田澤部長は情報システム部門を率いているわけではないにもかかわらず、システムでどのような機能を実現すべきかをまとめていく「要求定義」の責任者をみずから買って出た。作成したシステムの画面数は700近く。「さまざまな部門で現場の意見を聞いて調整を図るのは本当に大変だった」と田澤部長は振り返る。

「業務が変わっているじゃないか」

 美和電気工業は、なぜ要求定義を自前で進めることにこだわったのか。その裏には、営業管理支援システムの前身に当たる受発注管理システムの開発で味わった苦い経験がある。

 美和電気工業が受発注管理システムを構築したのは5年前の1999年。開発は、要求定義を含めて大手メーカー系ベンダーに依頼した。このベンダーは同社に対し、オフコン用業務パッケージをWindowsで動作可能にした製品を使うシステムを提案した。要求定義の段階では、ベンダーに聞かれる範囲で業務内容を説明した。「その時点では、まさか業務に合わないシステムになるとは思いもしなかった」と、同社の斉藤光男執行役員は述懐する。

 ところが、出来上がったシステムは同社の業務に合っていない部分が多々あった。例えば、同社が顧客から「システム一式」を受注した場合、発注書を複数の取引先に分けて出す必要がある。しかし、受発注システムで利用したパッケージは受注明細から発注明細を1対1で作る形になっており、発注を分割できなかった。

 パッケージの制約があり、受発注管理システムの改修は事実上不可能だった。同社は仕方なく、営業管理支援システムの利用を始めたつい最近まで、人手による運用でまかなってきた。

 「あの一件で、システムに対する要求は自分たちでまとめるべきだと悟った。営業管理支援システムでの作業は苦労したが、今回は希望通りのシステムが実現できたので満足している」。田澤部長の表情は明るい。

要求が膨らみコストが2倍以上に

 美和電気工業に限らず、要求定義の大変さを示すエピソードにはこと欠かない。リクルートは昨年9月ごろ、Webサイトのインフラ再構築プロジェクト「ガリレオ」で要求が予想以上に膨らみ、危うく頓挫しかけた。

 昨年4月に開始したガリレオは、Webサイト「ISIZE」の運用コスト削減を狙い、ネットワークやサーバー、ミドルウエア、認証などの共通サービスといったインフラ設計を共通化するプロジェクト。情報システム部門はインフラを開発するに当たり、約30サイトの担当者から要求を聞いて回った。

 すると、さまざまな要求が噴出した。ある担当者は「稼働率を重視したいので無停止を保証したい」と言い、別の担当者は「動画を含めたコンテンツを実現するために、新たなミドルウエアを入れたい」と希望した。こうした要求をインフラに盛り込んだ結果、昨年9月時点でコストが当初予定の2倍以上もかかる計算になっていた。

 報告を受けた情報システムの担当役員は急きょ、ガリレオの抜本的な見直しを決断した。約2カ月間検討を重ねた結果、要求を絞り込んだうえで仕様の共通部分とオプション部分を分けて設計する方法を採用。各サイトごとにオプションを選択して使う形にした。見直しは功を奏し、今年5月半ばには自動車に関する情報を提供するサイト「カーセンサー」が新インフラを使う第1号ユーザーとなった。

 要求定義の難しさが響き、社内システムを見直さざるを得なくなったのはNECフィールディングである。同社は「サービスの見積もりシステム」を昨年7月に運用開始した。ところが社内ユーザーの利用率は思うように上がらなかった。要求定義の段階で、「見積もり明細の記述内容をどこまで詳細にするか」といったシステムの細かい仕様をまとめ切れなかったからだ。

 約1500ページ、1億1500万円――独立行政法人の日本貿易保険が、オープン系システム開発のために作成した要求定義書のページ数と、作成に要したコストである。「システム担当者は3人だけ。25以上の関係組織から要求を自前で聞き出すのはとても無理」(総務部の畑幸宏システム室長)なので、要求定義を外注した結果だ。

要求定義の問題は“見てみぬ振り”

図1●厳しさを増す要求定義
 要求定義は、システム構築プロジェクトのなかで最初に実施する、重要な作業である。ユーザー企業もシステム開発企業も、その大切さや難しさは十分自覚している。要求定義のつまずきは、コスト超過や納期遅れ、さらに「システムが使われない」といったプロジェクトの失敗に直結するからだ。日経コンピュータが昨年実施した「情報化実態調査」では、プロジェクトのコスト超過の原因のトップは、要求定義の不備が招いた「追加の開発作業の発生」だった(図1[拡大表示])。

 ところがユーザー企業やベンダーの多くは、要求定義に真っ正面から立ち向かおうとしない。それどころか、「要求定義の問題に対し“見てみぬ振り”をしている」と、システム・インテグレータである構造計画研究所の富野壽会長は証言する。富野会長は、「これまではシステムを『どのように作るか』を重視し、『何を作るか』を軽く見ていたことが一因ではないか」と推測する。

 大手コンピュータ・メーカーやシステム・インテグレータが提供する開発方法論は、要求定義に相当する手順を規定している。しかし、いずれもシステムを正しく作ることに力点を置いており、「どんな目的でシステムを作るか」に関しては、ほとんど踏み込んでいない。結果として、「プロジェクトごと、あるいはエンジニアごとに勝手な流儀で要求定義を進めている」(システム・インテグレータ、エクサの児玉公信技術部担当部長)のが現状である。

図2●要求定義の問題への取り組みはこれまで“見てみぬふり”をされてきた
 個人がそれぞれの流儀で要求定義を進めること自体が、プロジェクトの失敗に直接つながるわけではない。しかし、手法として確立していないとユーザーやエンジニアに徹底させるのは難しいし、組織的なプロジェクトマネジメントも困難になる。ノウハウも継承しにくい(図2[拡大表示])。

経営との関係が深まるほど困難に

 そもそも、システムに対する「要求」を扱うのは難しい。人によってそれぞれ要求は異なるし、形になっていないだけにどうしてもあいまいになる。「ユーザーは、動くものを見て初めて『自分が欲しいものと同じ』あるいは『違う』と判断できる」と、NECフィールディングの阿部部長は語る。

 だからといって、要求定義の問題をこのまま放置するわけにはいかない。今後ますます困難になるからだ。

 その傾向を推し進めている大きな要因は、システムのオープン化である。オープン化が進むにつれて、ユーザー企業と開発ベンダーとの関係は、以前のように密でなくなりつつある。その結果、ユーザー企業、ベンダーともに要求定義の負担は増す一方だ。ユーザーはベンダーに要求を正しく伝えるために詳細なドキュメントをまとめる必要がある。ベンダーは、ユーザーの業務に精通していないなかで作業を進めなければならないケースが増えている。

 経営側の要求を達成するためにシステムを開発するケースが増えていることも、要求定義を困難にしている。「最近は『納期のリードタイムを3日短縮』といった経営レベルの要求が多い。目に見えるオペレーションの改善では達成できず、業務全体の中から改善ポイントを見つけ出してシステム化するスキルが求められている」と、システム・インテグレータであるウルシステムズの犬伏靖シニアコンサルタントは語る。

 経営側の要求を達成するシステムでは、特定の部門に向けたシステムよりもステークホルダー(利害関係者)が多くなる。加えて、ビジネスの変化に合わせる必要があるので、システムに対する要求が変わりやすい。こうしたことも、要求定義を難しくしている。

最後の難問への挑戦が始まる

 しかしここに来てようやく、システム構築の歴史が始まってから現在まで手付かずに近かった要求定義の問題に「正面から立ち向かわなければならない」と思い立つユーザー企業やベンダーが登場し始めた。

 こうした動きから、少しずつ要求定義の“最適解”が見えてきた。最適解を得るためのポイントは大きく三つにまとめられる。

 第1のポイントは、「ユーザーが積極的に参加する」。システムへの要求は、業務を担当するユーザーからしか引き出すことができない。ユーザーの参加意識が低ければ要求を正しくまとめることは不可能である。住友林業やNEC情報システムズは、このポイントを重視した取り組みを進めている。

 第2のポイントは「合意を獲得する」。ここでいう合意には2種類ある。

 一つ目は、業務やシステムに関係するステークホルダー間での合意。ウルシステムズの犬伏シニアコンサルタントは、「ステークホルダーごとに言うことが違うときに、ベンダーが口をはさんでもダメ。ユーザー同士で話し合う必要がある」と話す。ここに該当するのは清水建設やNTTデータなどだ。

 二つ目は、ユーザーと開発者との合意。これまでは、データ・フロー図やE-R図(エンティティ―リレーションシップ図)などシステム設計の図を使ってユーザーの要求を確認する方法が比較的多く使われていた。しかし、その方法では「システムで『だれが何をするのか』が分からず、業務設計の内容を理解できなかった」(清水建設情報システム部の安井昌男課長)。清水建設は、ユーザーと開発者の双方が理解できる図を考案した。

 第3のポイントは、「目的と離反していないかをチェックする」。要求定義を適切にやることはもちろん大切だが、その結果が設計や開発といった後工程に正しく反映されているかを常にチェックしなければならない。ベンダーやユーザー企業の有志が作ったビジネス・モデリング研究会は、ユーザーの要求を正しくシステムに反映するために、要求定義から設計・開発を一貫して進めるステップを体系化している。