PR

 ムラウチドットコムの橋本昌巳氏(取締役システム担当)は,自社のECサイトの構築で,かつて次のような経験をした。

 ある業務担当者に新機能が欲しいと言われて開発した。しかし,その機能を使うのはその人だけで,他の人は使わない。業務改善に寄与したかどうかも結局,分からなかった。担当者が異動すると,また「違うものを作ってくれ」という要求が出てきた。要求通りの機能を追加するうちにシステムはどんどん複雑化し,保守性が悪くなった。改修のコストも徐々にかさむようになってしまった…。 。

 現場を取材していると,こうした要求定義(注1)にまつわる話は事欠かない(図1)。IPA(情報処理推進機構)のアンケート調査(注2)によると,9割の企業が「失敗プロジェクトの原因は要求定義にある」と考えている。野村総合研究所の堀崎修一氏(ITアーキテクチャーコンサルティング部 主任テクニカルエンジニア)は「業務要件の詰めの甘さが目立つ。そのツケは後工程で噴出する」と指摘する。そこには三つの問題がある。

図1●要求定義をめぐるトラブルの例。要求が決まらなかったり,膨らんでいったりする
図1●要求定義をめぐるトラブルの例。要求が決まらなかったり,膨らんでいったりする。イラスト:ミオササノッチ
[画像のクリックで拡大表示]

問題1:要求には矛盾がある

 GMOインターネット証券の田島利充氏(システム部長)は証券取引システムを開発する際,エンドユーザーにヒアリングするなどして約400項目の要求をまとめた。要求は整理されず断片的に出てくるので,「同じような業務が複数あったときに,要求が少しずつ違っていることがあった。一方にはあるのに一方にはない要求が出てくることもある」(田島氏)。要求に矛盾があるわけだ。そのまま仕様にまとめると,テスト工程などで手戻りの原因になる可能性が高い。

 エンドユーザーの語る要求は整合性が取れているわけではない。これが一つ目の問題だ。

 複数の担当者にヒアリングすると,要求の不整合は顕著に出やすい。データを分析するシステムであれば,たくさんのデータを自由に活用したいと思う人もいれば,データ量は少なくていいので性能を上げてほしいと考える人もいる。実際の案件に数多く携わる日立システム&サービスの高橋修一氏(産業システムサービス事業部 第2システム部 部長)は「最近は複数の部門にまたがるシステムが多いので,部門間で利害が一致せず,要求にも矛盾が出てきやすい」と語る。