PR

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

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

図1●要件定義/システム設計にかかわる火事の主な原因と対策<br />Part3では,要件定義/システム設計の不備が原因で起こった火事の火消し事例を紹介する
図1●要件定義/システム設計にかかわる火事の主な原因と対策
Part3では,要件定義/システム設計の不備が原因で起こった火事の火消し事例を紹介する
[画像のクリックで拡大表示]

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

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

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

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

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

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

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

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

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

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

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

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

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

図2●追加要件の連絡体制の例<br />産業技術大学院大学の酒森氏はベンダー在籍時,ある製造業向けシステムの開発で多発していた要件のふくらみを,追加要件の連絡体制を確立することで収束させた
図2●追加要件の連絡体制の例
産業技術大学院大学の酒森氏はベンダー在籍時,ある製造業向けシステムの開発で多発していた要件のふくらみを,追加要件の連絡体制を確立することで収束させた
[画像のクリックで拡大表示]

 例えば,すでに「需要予測計算を先行き6カ月にする」という要件が決まっていたにもかかわらず,利用部門から「需要予測計算を先行き12カ月分にしてほしい」という要望が上がってきた。

 そこでその要望をいったん「プロマネ預かり」にしたうえで,利用部門の責任者と検討。その結果,(1)需要予測計算を12カ月分にするとハードを含めたシステム増強のコストがかかる,(2)6カ月分でも十分需要予測できる,と利用部門の責任者が判断してくれた。結局,その要望はシステムに盛り込まずに済んだ。