佐藤 三智子
A社は，「利用部門に活用されるシステムとは，利用部門の意見を全面的に取り入れたシステム」と誤解して収拾がつかなくなった事例である。プロトタイピング手法を導入する意味は，仕様変更の最小化と参画意識の向上にある。けっして利用部門の意見を全面的に反映するためではない。
システムの仕様を固めていくと，どんなに注意していても，検討や配慮が不足している仕様が浮かび上がってくる。並行して，業務の変化を最小限にとどめたいとする利用部門からの仕様変更の要求，さらに理由が明確でない新たな要望などが紛れ込んで来る。
収拾がつかない時は「目標」に戻れ
「最重要達成目標」（MVO，Most Valuable Object）という言葉がある。MVOとは，新システムで最低限何ができなければいけないかを指す。収拾がつかなくなった時は，新システムのMVOを再確認してみることである。
現状の課題を解決し，将来に備える機能を整備することが新システムの目標だったはずなのだから，このMVOの達成に無関係な仕様変更はしてはならない。こうした視点をベンダーに求めるのは無理である。ユーザー企業のプロジェクト管理者が自分で仕様を絞り込んでいくしかない。
A 社の生産管理課長は事態を打開するため，各部門のリーダーを集めて現状を詳しく説明した。「このままでは予算を超過するし，開発作業そのものも遅れかねない」と率直に話した。そして，「今回のシステム開発の目標だけをとにかく実現したい」と，利用者側へ協力を要請した。紆余曲折はあったが，仕様変更の範囲を全体の日程になんとか影響を与えない程度にとどめることができた。
ユーザー企業もプロジェクト管理を
B社のようにシステム開発を全面的に外部へ委託するケースは多い。この場合，注意すべきは，開発委託先のベンダーとユーザー企業でそれぞれプロジェクトのどの範囲を担当するのかをきちんと調整することである。
全面委託したからといって，ユーザー企業が受け身の姿勢のままではまずい。ベンダーから進み具合の報告を受けるだけで，「問題が出たので対処してほしい」とベンダーから言われて，初めてユーザー企業が動くようでは，決してシステム構築はうまくいかない。
ベンダーのプロジェクト管理とは，「あらかじめ合意を得た機能の情報システムを定められた期限までに，定められた品質で開発して納入する」ものである。新システムがB社にとって有用なものになっているか，運用上不都合をきたすことはないかといった視点をベンダーに求めてもなかなか難しい。
つまり，プロジェクト管理といっても二つの立場が存在する。第一は，目標とする機能仕様の情報システムが予定通りの期日までに，性能，安定性，使いやすさといった「品質目標」を満たして完成するように管理するもの。いわば技術面のプロジェクト管理で，ベンダーが受け持つことが多い。
第二は，プロジェクト全体を経営の立場から見渡して，問題がないかどうかをチェックするものである。こちらはユーザー企業のプロジェクト担当者が担当すべきだろう（表1参照）。
(1) 予算の見通し |
予算に関係する仕様変更やユーザーが分担している作業の進み具合も管理 |
|---|---|
(2) システム構築目標 |
新システムで狙った目標と効果に，その後変化が起こっていないかどうかをチェック |
(3) 構築日程 |
予定されたカット・オーバー時期を守れる日程になっているかどうかを常に確認 |
(4) ベンダーの作業内容 |
ベンダーが分担している作業の進み具合と，作業成果物の確認 |
