［要件定義/システム設計編］要件のふくらみ

日経SYSTEMS

2008.09.01

　要件定義やシステム設計の不具合も，プロジェクトマネジメントの不備に次いで，プロジェクトが火を噴く大きな原因である。例えば，システム要件が当初の予定よりもふくらんだり，要件定義/システム設計が甘いために手戻りが発生してプロジェクトが遅延する，といったケースだ。

　そこで，（1）要件のふくらみ，（2）要件定義の遅れ，（3）設計/アーキテクチャの不備，といった理由による火事の火消し術を事例を基に紹介していこう（図1）。

図1●要件定義/システム設計にかかわる火事の主な原因と対策

Part3では，要件定義/システム設計の不備が原因で起こった火事の火消し事例を紹介する

[画像のクリックで拡大表示]

（1）要件のふくらみ
ギブ・アンド・テイクで削減

　利用部門の追加要件を受け入れて，システム要件が当初の予定よりもふくらんでしまうことは多い。読者も経験したことがあるのではないだろうか。実際，利用部門とプロジェクト・メンバーがその場の話し合いで要件の追加を決めるケースは少なくない。プロジェクト支援などを手がけるテクノサージの佐藤義男氏（ビジネスコンサルティング事業部長）も「利用部門から『こういう業務をやりたいのだが技術的にできますか』と聞かれて『できます』と業務に詳しいSEが答える。それがそのまま追加要件になってしまうことは多い」と話す。

　システム要件がふくらむと，当然ながらスケジュールや品質，コスト面でプロジェクトは火を噴く可能性が高い。　だからといって，「追加要件をすべて断れば済む」という単純な話ではない。日本IBMで危機プロジェクトを支援した経験がある産業技術大学院大学の酒森潔氏（産業技術研究科情報アーキテクチャ専攻教授）も，「『追加要件は受け付けられません』と言い張るばかりでは，利用部門との関係はうまくいかずプロジェクトは破綻する」と指摘する。

　ではどう対処すればよいのか。システム・コンサルティングを手がけるシステムコーディネートの山谷茂氏（代表取締役）は「利用部門の担当者と開発担当者がギブ・アンド・テイクの関係になればよい」と言う。

　この方法を実践したのが東レだ。同社は2002年に購買システム開発プロジェクトを開始してまもなく，予定よりもはるかに要件がふくれあがる問題が発生した。明らかな火事である。

　このプロジェクトでは，モーターなどの設備用の部品や製造した糸を巻く芯といった資材と原料の集中購買を実現するために，ERPパッケージ「SAP R/3」の在庫購買管理モジュール「MM」と，繊維業界向けのBtoB型ECサイト「ファイバーフロンティア」を連動させる予定だった。

　ところがプロジェクト開始後すぐに「『工場設備の工事や修理』もECサイト経由で発注できるようにしたい」と，利用部門から強い要望が寄せられた。当初ECサイトで扱う予定だったのは，資材/原料のみ。工場設備の工事/修理は扱わない予定だった。「利用部門の要望をまともに受け入れると工数が膨大になる。プロジェクトの大きな危機だった」と，東レの重松直氏（情報システム部門長）は当時を振り返る。

　このとき，東レのシステム部門の担当者は，あえて「工場の現場にとって価値がある要件なら積極的に取り込む」という姿勢を取った。「システム部門の担当者が『これ以上要件をふくらませられない』とガードを固めて打ち合わせをしても，プロジェクトを円滑に進めるための協力関係は築けない」（重松氏）と考えたからだ。

　しかし，追加要件をただ取り込むだけでは，工数はふくらんだまま。そこで「こちらが追加要件を受け入れる代わりに，別の部分で我慢してもらうことにした」と，プロジェクトのシステム部門側のリーダーだった蒔田利彦氏（情報システム運用部システム運用第1課長）は話す。

　例えば，工場設備の工事や修理をECサイトから発注できるようにする一方，当初予定していた過去の工事/修理案件の情報を新システムで閲覧する機能は削減した。過去の工事/修理案件は既存システムで閲覧してもらうようにしたのである。その結果，無事2003年10月にシステムを稼働できた。

追加案件は「プロマネ預かり」に

　要件がふくらんだときの火消し術としては，追加要件をうまく管理する体制を再構築することも大切だ。

　前出の産業技術大学院大学の酒森氏は，要件がふくらみすぎた製造業のSCMプロジェクトをプロジェクト・マネージャとして支援した際，追加要件の連絡体制を新しく確立した（図2）。現場で要件の追加/変更が発生したときには，必ずリーダーを経由して，プロジェクト・マネージャである酒森氏に連絡することを徹底させたのだ。