　プロジェクトチームは、コンカレントエンジニアリングの実現手段として、部品表を中心とした製品情報共有方式（PDMシステムの活用を前提）を採択しました。しかし、部品表システムに関するユーザーからの要求は、生産管理システムやCADシステム連携を含め、非常に多岐にわたり、要件定義工程に対して多くの時間を費やすことになりました。また、多岐にわたる要求は、システム実装上の費用超過や、システムリリース時期の遅延などの課題を引き起こし、さまざまな調整事項を発生させ、プロジェクトチーム、特に事務局を多忙にしました。

　プロジェクトチームの努力の末、部品表システムのリリースはできたのですが、コンカレントエンジニアリングの実現や、製品開発リードタイム短縮実現のための検討は十分実施されず、当初の目的であった製品開発リードタイムの短縮については、満足な成果が得られませんでした。

　当初実現したかった目的が煩雑な調整の中で置き去りにされ（見失われ）、手段（システムを稼働すること）の実現が最終目標にすり替わってしまったのです。

　目的の“ブレ”が、結果的にビジネス成果を得られない原因になった事例です。

パターン2：「すんなり導入できたのにユーザーが……」改革企画の評価が不十分

　2番目に紹介するのは、情報システム部門が起案した統合マスター改革プロジェクトの事例です。これは、起案した企画内容の正当性の評価が不十分な状態でプロジェクトを実行（この事例ではシステム構築）したことが、結果的にビジネス成果を得られない原因になった事例です。

　このプロジェクト起案のきっかけは、情報システムの老朽化によるシステムリプレースでした。情報システム部門を中心としたプロジェクトチームは、単なるシステムリプレースだけでは投資の理由としては弱いため、経営課題の解決も併せて提案することにしました。

　従来のシステム構成では、マスターが変更されるたびに、関連する複数のシステムのマスターを、同期を取って変更する必要がありました。ここでの問題認識は、整合が取れなかった場合に業務上の問題を引き起こす可能性があることと、業務複雑化に伴いマスターメンテナンスの工数が増加する傾向にあることでした。この起案は、この問題を統合マスターの構築により解決する点がポイントでした。

　システム開発段階までは順調に推移しましたが、運用テスト段階で問題が発覚しました。それは、ユーザーの操作が従来システムと大きく変化し、逆に業務効率が悪化するという問題でした。ユーザー部門から本プロジェクトに関する見直しが提案され、結果的にプロジェクトは中止になりました。当初の起案内容は、システム視点の評価は行われたのですが、ユーザー視点の評価が欠けていたのです。

　改革企画の評価不足による誤りが、プロジェクトを中止させる原因となった事例です。