実録！製品設計・開発の業務改善 “失敗者”のパターン：グローバルPLM～世界同時開発を可能にする製品開発マネジメント（7）（1/2 ページ）

製品設計・開発環境やプロセスをイマドキに変更したいのに、どうしてもうまくいかない……。その理由はやっぱり……!?

[三河進／NECコンサルティング事業部，＠IT MONOist] PC用表示関連情報

LINE

Hatena

業務改革プロジェクトは意外と成功していない？悩めるプロジェクト担当者

　セミナーなどで、企業から多くの成功事例が発表されています。発表者の多くは、各企業の業務改革推進部門の方々であり、実際の苦労話に基づいた事例であるため、業務改革推進者にとってとても有益なお話です。

　しかし、成功事例の裏には、失敗事例も多く存在します。筆者も、以前は新規の業務改革企画の相談を受ける機会が多かったのですが、最近はうまくいかないプロジェクトの再建のご相談が増えてきています。改革プロジェクトの難易度が上がり、ビジネス環境の変化への追随が難しくなってきているのではないでしょうか。

　今回は、普段焦点が当てられることが少ない失敗プロジェクトについて考察してきたいと思います。筆者の経験から、失敗プロジェクトには共通した問題点・原因が存在します。それらを類型化し、業務プロセス改革における業務改革推進の留意点をまとめていきます（前回へ）。

パターン1：「あれ、このプロジェクト、なんでやってるんだっけ……？」目的を見失ってしまう（IT導入が目的に変化）

　1番目にご紹介するのは、プロジェクトの当初の目的を、調整業務などの多忙さとともに見失い、結果としてIT導入は実現できたが、当初想定していたビジネス成果が達成できなかった事例です。このプロジェクトの目的は、コンカレントエンジニアリングにより製品開発リードタイムを短縮することでした。

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

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

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

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

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

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

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

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

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

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