システム導入成功率は依然３割。 失敗するなら、やらないほうがマシ・・・、とならずに 確実にシステム導入を成功させるためのポイントを解説します。 中小企業診断士　システム監査技術者　小島規彰 http://www.asahi-bs.com/

1. 綺麗事だけじゃプロジェクトは成功しない
小島規彰
（中小企業診断士、システム監査技術者）

2. 「これからの成長にはＩＴ化は絶対に必要だ。」
10年前にはこのような声がどの企業でも聞けたことでしょう。
しかし、どうでしたでしょうか？企業のＩＴ導入プロジェクトは７割
が失敗だそうです。決して安くない投資だったはずです。この経
済的な損失がどれほどのインパクトを与えているのでしょうか？
その期の赤字だけにとどまらず、銀行の融資姿勢が変わったり、
株主の厳しい追求があったりするかもしれません。また従業員
は失敗プロジェクトのせいで精神的にも肉体的にも健康を蝕ま
れているかもしれません。事実、システムエンジニアは、３K（き
つい、きびしい、帰れない）なんて言われてたりもします。
1

3. 更には、プロジェクトの失敗のせいで、ライバル企業との競争
力に差がついてしまったかもしれません。たった一度の失敗が
その後の業績に大きくかかわることにもなりかねません。そん
なことにならないためにも、ITプロジェクトの失敗原因を深く分
析し、どうすれば（次は）失敗しないで済むのかを、考察したい
と思います。
資料の前半ではプロジェクトの失敗原因を明らかにするととも
に、失敗させないための方法を記載しています。後半ではそれ
らを実践していただき、さらに誰が行っても一定の成果があが
るように、チェックリスト化しています。
2

4. 本資料では、よくあるプロジェクトマネジメント関連の教科書の
ような綺麗事だけでなく、組織、人間関係には絶対存在する暗
部にも触れています。この部分を冷静に捉えることで、より実践
的な対応ができるものと考えています。
本資料を、参考にしていただき、中小企業のパッケージ導入プ
ロジェクトの成功確率が、少しでも向上すれば幸いです。
3

5. 1. ＩＴプロジェクトは失敗するものだ ・・・・・・・・・・・・・・・・・・・・・・・ 5
2. パッケージ商品の現状 ・・・・・・・・・・・・・・・・・・・・・・・ 9
3. ＩＴプロジェクトの失敗とは ・・・・・・・・・・・・・・・・・・・・・・・ 17
4. なぜ失敗するのか ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 26
5. 失敗しないために何をすべきか ・・・・・・・・・・・・・・・・・・・・・・・ 41
6. チェックの対象と視点 ・・・・・・・・・・・・・・・・・・・・・・・ 59
7. Ⅰ初期検討とプロジェクト立ち上げ準備 ・・・・・・・・・・・・・・・ 66
8. Ⅱ現状分析と要求仕様・RFP作成 ・・・・・・・・・・・・・・・ 75
9. Ⅲパッケージソフトとベンダーの選択 ・・・・・・・・・・・・・・・ 83
10. Ⅳキックオフまでの準備 ・・・・・・・・・・・・・・・・・・・・・・・ 95
11. Ⅴ導入フェーズ（前半） ・・・・・・・・・・・・・・・・・・・・・・・106
12. Ⅵ導入フェーズ（後半） ・・・・・・・・・・・・・・・・・・・・・・・115
13. Ⅶプロジェクトマネジメント ・・・・・・・・・・・・・・・・・・・・・・・123
14. Ⅷプロジェクト完了 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・133
15. おわりに ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・139
4

6. 1. ＩＴプロジェクトは失敗するものだ
2. パッケージ商品の現状
3. ＩＴプロジェクトの失敗とは
4. なぜ失敗するのか
5. 失敗しないために何をすべきか
6. チェックの対象と視点
7. Ⅰ初期検討とプロジェクト立ち上げ準備
8. Ⅱ現状分析と要求仕様・RFP作成
9. Ⅲパッケージソフトとベンダーの選択
10. Ⅳキックオフまでの準備
11. Ⅴ導入フェーズ（前半）
12. Ⅵ導入フェーズ（後半）
13. Ⅶプロジェクトマネジメント
14. Ⅷプロジェクト完了
15. おわりに 5

7.  とある有名機関の調査によると、ITプロジェクトの成功率
31.1%で、それよりも数年前の別の調査でもほとんど変化のな
い数値でした。つまりあまり進化していないということです。
（この場合、Ｑ（品質）、Ｃ（コスト）、Ｄ（納期）がすべて予定通
りだったものを「成功」としています。）
 プロジェクトマネジメント手法やシステム開発技法は、徐々に
浸透し、システム開発の失敗要素は確実に認識され、適切な
対応がされているはずなのに、です。
 この７割の中には、使えないシステムになってしまった、プロ
ジェクトが頓挫した、といった内容が含まれている事を考える
と、会社っていうのはそんなにお金に余裕があるのかと邪推
してしまいます。
6

8.  コア事業以外のところで、人的資源に余剰がありそれを維持
したいと考える中小企業はないでしょう。
 そもそもユーザ企業の情報システム部の仕事は、（業種にも
よりますが）コア事業ではありません。情報システム部が無い
中小企業もあります。
 中小企業にとってパッケージ導入のＩＴプロジェクトは、短期的
にそう何度もあるものではありません。
 今日でも、情報システムは技術も手法も日進月歩で進化して
いますから、そのようなスキルを常に勉強し習得するのは、
ユーザ企業では時間的にもコスト的にも難しいはずです。
 ＩＴ技術の進化に対応しつつ、めったにないＩＴ導入プロジェクト
を成功させることが難しいのも当然と言えば当然です。
 だからと言って、７割の側に甘んじてはいませんよね？ 7

9.  以下は、中小企業のＩＴ普及によってもたらされた結果です。
 ＩＴ導入を推進していかなければ、競争すらさせてもらえず、
市場から撤退ということにもなりかねないということでしょうか。
 しかしＩＴ導入に成功したところで、競争優位になるというわけ
ではありませんから、決して安くない投資は確実に成功させ
て、回収したいものです。
上位３つはあまり
前向きな内容では
ないのが特徴です。
8
ITの普及に伴う経営環境の変化 （中小企業白書2008年版より）

10. 1. ＩＴプロジェクトは失敗するものだ
2. パッケージ商品の現状
3. ＩＴプロジェクトの失敗とは
4. なぜ失敗するのか
5. 失敗しないために何をすべきか
6. チェックの対象と視点
7. Ⅰ初期検討とプロジェクト立ち上げ準備
8. Ⅱ現状分析と要求仕様・RFP作成
9. Ⅲパッケージソフトとベンダーの選択
10. Ⅳキックオフまでの準備
11. Ⅴ導入フェーズ（前半）
12. Ⅵ導入フェーズ（後半）
13. Ⅶプロジェクトマネジメント
14. Ⅷプロジェクト完了
15. おわりに 9

11.  パッケージベンダーのセールストークを聞いていると変化に
気づきます。
 一昔前、中堅中小企業にも導入が進み出したころ、「パッ
ケージに詰まった先進企業のノウハウを適用できる。」でした。
 最近は「短期間で導入できる」を強くアピールしているように
思えます。
 昨今は、自社をとりまく環境の変化を即座に捉え、ビジネスを
変化させていく、その速さが鍵を握る時代ですから、このセー
ルストークの変化もうなずけます。
10

12.  「クラウド」と言う言葉がＩＴ業界を飛び出し、ビジネス用語に
なった今、システム環境構築のリードタイム短縮化は、皆の
共通理解になっています。
 ますます、業務そのものであるアプリケーションの導入スピー
ドも重要視されることでしょう。
 アプリケーションもクラウド（SaaS）を利用すれば良いじゃない
か？ということになりますが、これはそうなっていないのが現
状です。（寡占が進む分野のアプリケーションは、ベンダー側
の意図があるかもしれません・・・）
 一方、よほどのことで無い限りこれからオーダーメイドで自社
の業務アプリを作ろうとする中小企業は、チャレンジャーなの
か・・・
（そのほうが良いアプリケーションは確かにありますが。）
11

13.  昨今では、どの企業でもさほど業務のやり方に違いがでない、
または差別化が強みの源になりづらい分野の製品は、ほと
んどがパッケージによるＩＴ導入になっています。
 上記製品に比べ、企業独自のやり方、差別化が強みの源に
なり得る販売管理や生産管理でも、60%を超えています。
12
ITPro 中堅・中小企業のITアプリ導入実態調査（2008年版）

14.  多くの分野のアプリケーションでパッケージ化が進みました。
 シェア上位を占める製品は導入実績も相当数に上り、バグや
不具合等で全く使えないということもなくなっています。
 ですので、システム導入の際には必ずと言っていいほど、
オーダーメイド開発とパッケージ導入の比較がなされる事で
しょう。
パッケージ導入とオーダーメイド開発のメリット・デメリット
13

15.  パッケージ導入のメリットである、導入期間の短縮や安定稼
働、初期に提示されたコスト優位性等のメリットを重視し、結
果的にはパッケージ導入に決める企業でも・・・
 導入の成功率はやはり、３割のようです。
 なぜでしょう？
 どうやらパッケージとオーダーメイド開発のメリットデメリットに
起因する理由だけではなさそうですね。
14

16.  現在のパッケージ機能の多くは、標準機能＋オプションと
いった提供の仕方です。
 標準機能は導入実績から共通仕様と思われる部分、オプ
ション機能は過去の少数の特定企業での開発実績をもとに
した部分。そういう経緯があるはずです。
 大抵は、標準機能だけでは要求を満たせずに、プラスアル
ファの機能が必要になります。つまりカスタマイズかアドオン
です。
 オプション機能でこれを吸収できれば良いのですが、なかな
かこれが難しいのです。
 結局、追加開発になった部分の扱いは、独自開発と同じにな
ります。
15

17.  更に大抵どこのベンダ企業でもそうですが、優秀なコンサル
タント、エースと呼ばれるＳＥ、凄腕のプロジェクトマネージャ
というのはごく一部です。
 パッケージ導入といえども、システムプロジェクトですから、
“人”によって成否が大きく左右されます。
 ベンダ側の最強チームにあたれなかった企業は・・・
 またユーザ企業側にしても、対象パッケージの導入経験は
“無い”または“１回だけ”が大半を占めるのではないでしょう
か？
 はじめて取り組むことに対し、ましては自分の専門外（かもし
れない）の事を担当するのですから、成功は容易いとは言え
ません。
16

18. 1. ＩＴプロジェクトは失敗するものだ
2. パッケージ商品の現状
3. ＩＴプロジェクトの失敗とは
4. なぜ失敗するのか
5. 失敗しないために何をすべきか
6. チェックの対象と視点
7. Ⅰ初期検討とプロジェクト立ち上げ準備
8. Ⅱ現状分析と要求仕様・RFP作成
9. Ⅲパッケージソフトとベンダーの選択
10. Ⅳキックオフまでの準備
11. Ⅴ導入フェーズ（前半）
12. Ⅵ導入フェーズ（後半）
13. Ⅶプロジェクトマネジメント
14. Ⅷプロジェクト完了
15. おわりに 17

19.  ここで失敗プロジェクトとは何かをきちんと定義しておきましょ
う。
① 品質粗悪
② 予算超過
③ 納期遅れ
④ 利用されない
⑤ 目的達成されない
⑥ プロジェクト頓挫
⑦ 経験によって得るものがなかった
⑧ 関係者の心身疲弊困憊
18

20.  まずは「品質粗悪」です。
 そもそも品質とはなんの事でしょうか？何を品質と呼ぶかに
ついて、関係者の共通認識を持つことが極めて重要です。
 パッケージそのものではありませんが、ソフトウェア品質を表
す特性を定めた国際規格ISO9126を参考にすると、品質は以
下で表わされます。
ISO9126で定められるソフトウェア品質 19

21.  これらを前提とすると、
 新しいパッケージを導入してもプロジェクトの目的を達成できない
 システム障害が著しく業務に影響を及ぼす
 ほとんどの使用者が操作を理解しづらいと感じる
 当初決めた制限時間、応答時間内で機能が実行できない
 ソフトウェアの不具合が生じたときに切り分け、問題特定できない
 などが、「品質粗悪」によるプロジェクトの失敗と言えるでしょ
う。
 ユーザ側の立場で明確に定義できるものと、そうでないもの
があります（特に保守性）。
20

22.  次は「納期遅れ」です。
 なぜ納期遅れを失敗とするのか？
 「機会損失」
本来得られる効果が、遅れている期間享受できない
 「二重のコスト」
旧システムのライセンス、保守料、電気量等と並行して、新シ
ステムのコストがかかる
 「人件費増加」
プロジェクトメンバーの待機時間等は、余計な人件費となる
 「メンバー通常業務への影響」
メンバーの抜けた穴は誰かがフォローしている。残業代、臨
時人件費等が増加している
21

23.  「利用されない」、「目的達成されない」
 これらは「品質粗悪」に含まれる内容ですが、プロジェクトの
失敗の中では、最悪の失敗に分類されるものですので、あえ
て抜き出しておきます。
 システムは飾り物ではありませんし、その導入自体が目的に
なることは決してありえません。
 長い時間とコストを費やした結果が、使われない、使っても意
味が無いのであれば、そもそも初めから何もしないほうがま
し、ということになってしまいます。
22

24.  「プロジェクト頓挫」も、当然失敗です。
 一つの問題が次の問題を引き起こして、問題がどんどん大き
くなっていくのが、プロジェクトの特性でもあります。
 このままいけば必ず失敗すると冷静に判断し、途中で終わら
せるのはある意味英断ですが・・・
23

25.  「経験によって得るものが無かった」
 プロジェクト終了後、メンバーがこのような事を思うようなら、
プロジェクトはある意味失敗と言えます。
 パッケージ導入は中小企業にとって、そう多くないイベントだ
というのは先にも書きました。
 現状業務の問題の洗い出し、経営戦略を実現するための新
業務の整理、社内の他部署とのとの共同作業、様々なドキュ
メンテーションの作成、外部企業との密なコミュニケーション、
こういった経験から学べることは山ほどあります。
 これらを貴重な経験として自分のスキルを高めるか、または、
ただのタイトスケジュールのハードワークだったと思うか、意
識の持ち方ひとつで変わります。
 次の仕事に活かせるのはどちらか、言うまでもありません。 24

26.  最後の失敗は「関係者の心身疲労困憊」です。
 疲労くらいならよいのでしょうが、精神的にダメージを蓄積し
てうつになってしまったり、入院等が必要になるくらいの体調
不良はいただけません。
 そもそもプロジェクトメンバーがここまで追い詰められるような
ら、プロジェクトは相当ひどい状況であることが想像できます。
25