第３回　プロジェクト結果の満足度と失敗要因

これまで、背景や目的など基幹システム再構築プロジェクトの入口についての話をしてきたが、今回は出口（満足度・成否）について紹介する。

経営と現場では満足度の尺度が異なる

　基本的に、基幹システム再構築プロジェクトの満足度は、前段で合意されたプロジェクト目的の達成度合いによって決まる。（もちろん、設定したプロジェクト目的以外に得られる満足もある。）従ってそもそも目的が不明確、共通認識化出来ていなければ、満たすべき条件が不明なまま取り組むことになるし、目的・目標が達成されなければ、不満足ということになる。

 また、プロジェクトに対する満足度の考え方は通常、経営側・現場側とで異なる。

　経営側の観点では、「データの一元管理を通じたデジタルマーケティング機能強化による売上●％増」、「月次決算公表の2営業日早期化（経営状況の把握・意思決定の早期化）」や、それら実現のためにシステム再構築でいくらかかったか（費用対効果）など、掲げられたプロジェクト目的・目標の内、定量的・客観的な成果が重視される。シンプルに言えば、目的・目標を、予算内でスケジュール通りに達成できると、満足度が高い。
定性的な観点では、システムの新規事業領域への柔軟な対応等の戦略実行に寄与することに加えて、従業員の満足度（仕事がやりやすくなった等）などがあり、昨今こちらも重視する経営者は多い。

　他方、現場側の満足度は、減らしたかった手入力やチェック作業が圧倒的に減った、操作方法が理解しやすく使いやすい等、実際に使用したことにより得た主観的な手応え・利便性など、感覚的に満足度を評価することが多い。

 満足度の尺度が異なる双方の立場について、それぞれの期待を満たす事ができた場合、その基幹システム再構築のプロジェクトは成功したと言えよう。従って、プロジェクトの運営を担う立場では、双方の期待を満たす・超えることを意識して活動に取り組む必要がある。

様々なプロジェクト失敗要因

　基幹システム再構築の失敗事例は、新聞記事、インターネットで検索するだけでも枚挙に暇がないが、概ねその要因は以下に集約される。

1. プロジェクトの目的・目標が不明確
2. 現行の業務手順・流れをそのまま踏襲したシステムの単なる置き換え
3. 各業務機能別（現場）のありたい姿（目指す状態）を描いていない
4. 必要性・優先度を評価せずに、社内の要望を聞き過ぎる
5. 経営陣とプロジェクト推進事務局の情報共有・合意不足（コミュニケーション不全）
6. ITインフラ、セキュリティやシステム間連携を含むIT戦略・方針が不明確
7. 開発ベンダーやそのPM（プロジェクトマネージャー）のスキル不足等、外部要因

　JMACが支援先でプロジェクトを開始する際も、既存システムの導入経緯などと合わせて、過去の失敗についてよくお聞きする。ここでは、多くの企業にとって共通の備えが考えられる、３と５のパターンについて、それぞれ事例を紹介する。

３．各業務機能別（現場）のありたい姿（目指す状態）を描いていない

　３については、プロジェクト推進事務局から各現場の巻き込みや、業務要件・課題確認が不十分で、ありたい姿が不明確なままプロジェクトを推進した場合に起きやすい。
A社では過去にある基幹システムを導入したが、その活用実態は、会計管理の都合上、既存帳票や手組みのシステムから必要最低限の項目を転記入力するだけに留まっていた。経理を除くいずれの部門においても、活用が不十分、当該システムで何がどこまで出来るかも分からないと不満の声が挙がっていた。

　この会社では、システムの導入に当たって社長と経営企画、情報システム部門のみでベンダー選定・開発まで完結させており、各業務機能の主管部門・キーマンは殆どプロジェクトに関与することがなかった。その結果、各部門の課題が把握されず、課題を解決した「あるべき姿（業務）」と「あるべき姿を実現するシステム機能要件」が設計されずに、システムの選定・要件定義・開発が進んだ結果の失敗である。
事例A社のプロジェクト体制図を表すと以下のようになる。

　システムの内容に殆ど関与できていない各現場からすると、自分たちの業務が良くなるかどうか実感が無いまま、習熟した方法を捨て新しいやり方を覚える煩雑さや、過去のやり方を踏襲しているため、転記入力による手間だけが増えることを強いられたように感じることになる。そうした経緯で導入されたシステムはいくら事後に啓蒙しても、本来有用な機能であってさえ、限られた人員にしか活用されることはない。

　なお、このような失敗・プロジェクト体制になるケースは、そもそも「他社での評判」「システムベンダーとの対外的な付き合い」「パッケージの標準価格」等の理由から自社に合ったパッケージを選定せずに、パッケージを選定していることが多い。

５．経営陣とプロジェクト推進事務局の情報共有・合意不足（コミュニケーション不全）

　５については、情報収集・共有の悪さにより意思決定層（経営）とプロジェクト事務局とで上手く合意ができないというものだ。わかりやすいのは、費用に関する合意だろう。

　B社では、事務局が各現場からメンバーを募り、現状の業務を把握、システム導入後のあるべき姿を踏まえ、カスタマイズ内容などもメンバーと合意を重ね要求仕様を確定させてきた。しかし、多忙な経営トップへの報告は、複数のシステムベンダーからの最終的な見積もりが出て初めて行われた。標準に対してどれほどのカスタマイズが想定され、それが何故必要なのかについて説明を受けていない経営トップは、想定よりも遥かに大きく膨らんだ見積もりを見て、首を縦に振らなかった。結果、経緯の説明や仕様の見直しで一度合意した内容に再度変更を重ねる必要が生じ、手戻りにより想定スケジュールを大きく後ろに倒してプロジェクトを進めることとなった。

　基幹システムの再構築にかかる最終的な費用は、ユーザ数やカスタマイズ内容・規模など、多くの変数が確定するにつれて徐々に明らかになっていく。何をどの程度行うとどの程度の金額になるのか、事例調査やシステムベンダーとのコミュニケーションを通じて逐次アップデート、経営層へ適時適切に伝えながらプロジェクトを進行することが重要だ。定量的・客観的な成果を重視する経営層にとって、多額の投資はその必要性や根拠に納得感がなければ、決してゴーサインを出せないからである。費用を認識するタイミングや程度によっては、プロジェクトが白紙に戻るようなケースさえある。

失敗を防ぐ鍵は、プロジェクト開始時の準備にある

　紹介した事例のような失敗（経営も現場も不満足）を避けるためには、以下の図のような全社的なプロジェクト体制を構築し、各役割を明確にすることが必要である。

体制上のポイント

• トップ層を責任者、最終意思決定者とする体制（プロジェクトオーナー）
• トップ層とのコミュニケーション機会の設定（ステアリングコミッティ）
• 各ユーザ部門の代表者のプロジェクト参画
   

　以上、今回はプロジェクトの満足度と失敗事例とその要因について紹介した。次回以降、JMACの考える基幹システム再構築プロジェクトを成功させるために必要なことや具体的な進め方・推進上のポイントについて発信していく。