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

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

2.  プロジェクトの失敗原因は様々です。これをアンケート、集計
したような図表を目にされている方も少なくないと思います。
 （一部を除き）内容にそんな違いがないことがわかります。
WEBサイトや雑誌等でみられる、プロジェクト失敗に関するアンケート集計結果・統計データ 27

3.  広告タイアップの記事は中身に偏りがあるような気がします
が、それでも大体の傾向はつかめるはずです。
 プロジェクトマネジメントが出来ていない
 従業員に十分なスキルがない
 計画や目標があいまい
 トップの関与が足りない
 こんなところでしょうか？
 単純に、これの原因を裏返して
 プロジェクトマネジメントスキルを身につける
 従業員に役割に応じた専門知識を身につけさせる
 計画や目標をしっかり立てましょう
 トップが積極的に関与しましょう
 では、あまりにも綺麗事すぎる気がしませんか？
28

4.  もっとどろくさいプロジェクトの失敗理由の一例を挙げます。
 プロジェクトに慣れていない企業で見られる「構造」です。
プロジェクト初期はエグゼクティブが強く関与しているが、リスク認識は低く、問題があっても発見はなかなかできない。
中盤になり、序盤のリスク放置が影響して問題が発生するも、上級管理職の関与は薄く、メンバーの責任として認識する。
その場しのぎでなんとか後半に突入するも、形になってきたシステムが当初の思いと異ったものとなり、プロジェクト失敗となる。
29

5.  ビジネスは常にリスクと隣り合わせです。
 プロジェクトもしかりです。プロジェクトを失敗させないために
は、 （広義の）リスクを顕在化させないことです。
 そのための（広義の）リスクマネジメント手法は、何も特別なも
のでなく、以下の一般的な体系で示すことができます。
 「そんなのはわかってるよ」との声が聞こえそうですが、 多く
の企業おそらく７割の企業は、これができていないはずです。
リスクファイナンス
リスクコントロール
30
一般的なリスクマネジメントの体系

6.  ここで用いた「リスク」という言葉は、プロジェクトマネジメント
体系（ＰＭＢＯＫ）の構成要素である、（狭義の）リスク管理と
は、違います。
 ビジネスレベルでの広義の意味でのリスクです。
 プロジェクトそのものにマイナスの影響を及ぼす可能性のあ
る事象です。
31

7.  さて、どの部分が失敗の原因になっているのでしょうか？
 どんな企業でも、それなりにやっているはずなんですが・・・
 例えば、
 リスクの洗い出しに漏れはないか？
 リスク管理の手法は適切なのか？
 漏れがない、適切であることをどうやって説明できるのか？
 その説明が正しいことを、誰が証明できるのか？
 それはしかるべき者に承認されているか？
 その承認にはどういう意味があるのか？
 担当するメンバーは頑張って考えるでしょう。いろいろな資料
やサイトを参考に検討もするでしょう。
 管理者はチェックもするでしょう。
32

8.  しかし、ちょっとまってください。
 その方々は、リスクアセスメントのプロではなく、システム開
発の十分な経験があるわけでもありませんよね？
 「出来る限りのことはやったはず」
 「自分のわかる範囲ではこれで大丈夫だと思います」
 とは言えても、「完全です」とは言えないでしょう。
 要は、逃げ道をちょっと作っておくのです。
 責任が所在をあいまいにしておくのは、ある意味日本文化そ
のものなので、これだけをフォーカスして否定するつもりはあ
りません。
33

9.  プロジェクトの主たる関係者である人たちが、同時にプロジェ
クトのリスクを発生させる原因を作る人たちでもあります。
 プロジェクト期間中、自分達をコントロールできない理由、つ
まりジレンマが常に発生します。
 ですから、頑張って策定した計画に対し、どうしても実行段階
で、リスクコントロールの完全性は崩れていくのです。
34
リスクコントロールのジレンマ

10.  特に、プロジェクトマネージャのプレッシャーは半端ありませ
ん。経験された事のある方であれば、プロジェクトの大小問
わず、家に帰っても消えない、休日になっても消えない緊張
感に悩まされたはずです。
 まして経験の無い方が、ちょっとセミナーに行きました、書籍
で知識は身につけました、管理資料のフォーマットは手にい
れました、だけでITプロジェクトを成功させられるほど、現実
は甘くありません。
 スキルだけでなく、性格、カリスマ性、センス、そういったもの
が必要となる職業だけに、なかなか一朝一夕ではその仕事
を完遂できないのが実情です。
35

11.  他にも理由はあります。
 プロジェクトメンバーには、自分の役割、仕事の範囲がありま
す。最近の若い人には、あまり他人の事に興味を持たない、
関わりを持ちたくないと考える人が多いようです。
 ただでさえ、自分の仕事が忙しいのに他人の間違いなんて
指摘して、手伝えなんて言われたらとんでもない。
 他人の事なんて放っておこう・・・。
 プロジェクトマネージャの間違いを指摘したら逆切れされそう
だし・・・
 責任者の考え方もなんか違うみたいだけど、指摘したら心象
悪くしそうだし・・・
36

12.  まだまだあります。
 プロジェクトの責任者が部長（中小企業の部長は取締役かも
しれません。）というケースは少なくないと思います。
 彼らが失敗の責任を取るということは一大事です。
 「若いやつらにまかせる。」聞こえはいいですが、成功率３割
の面倒なことはやりたくないのでしょう。
 「どうせなら失敗は部下のせいにしておきたい。」絶対口には
しませんが、腹のうちでそう思って無いとは言い切れません。
 そもそも、エグゼクティブな方は、忙しいでしょうから、常時監
視しているわけにはいかないでしょう。
37

13.  更にあります。
 ＰＭＯにしても現場を見ていません。というか中小企業で仮に、
ＰＭＯを設置できたとしても、なかなかうまく機能しません。
 論理的に駄目“そう”なところを指摘できたとしても、所詮実行
まで責任を持てない（持ちたくない）でしょう。
 具体的改善策も示すこともなく、ましてＰＭＯ自ら仕事を手
伝ってあげましょうなんてことは、まずありえません。
 そもそも中小企業では、臨時と言えどもＰＭＯを設置できるほ
ど人的資源に余裕はないように思います。
38

14.  また、良くないことに、一度発生した問題（顕在化したリスク）
は、時間の経過とともに凶悪になるという性質を持ちます。
 プロジェクトのひとつひとつの作業には、基本的にはかなら
ず先行作業がありますので、先行作業での問題は、それ以
降の工程すべてに影響を及ぼします。
39
先行作業の問題は後工程すべてに蓄積される

15.  ここまでの話をまとめてみましょう。大きく分けて以下のような
３つに集約できるはずです。
 ①リスク計画の中身はそこそこのレベル
 ②せっかくたてた計画もなかなか守れない状況に陥る
 ③プロジェクトマネジメントやその他の機能（ＰＭＯ等）が形骸
化してしまう
 以上のような事に起因して、想定されたリスクが顕在化し、そ
れが適切に解決されないと、プロジェクトの成功確率は確実
に減少します。
40