ITシステムが失敗したときの原因構造
ITシステム開発を進めるプロジェクトは失敗することが多いと言われていますが、実際にはどのようなことになってしまうでしょうか。
独自に調査した失敗事例をもとに解説していきたいと思います。
まず失敗の結果としてどのような状態となっているか、という点です。
それは、IT導入・システム開発が終わらないという状態です。
もちろんいつかは終わるのでしょうが、終わりが見えない、というイメージになります。
IT導入・システム開発は目的があり、目的を達成するための予算と期間があるはずです。
その予算と期間を超えてしまい、超えた段階においても、まだまだお金がかかったり、期間もまだ１年や2年はかかる、といった状態となったとき、頓挫を意識するでしょう。このようなプロジェクトは実際に発生しています。
事例から見ると、最終段階において発生している事象は３つあります。
ひとつめは、作られるべきものが完成していない状態です。
２つめ、３つめは、完成していない原因でもあるのですが、システム仕様の決定が遅れている、ということと未解決な課題が蓄積されているという事象です。
このような頓挫を意識する状況に陥るには、実行段階で問題の兆候が表れています。
実行段階での問題の兆候
実行段階で見えてくる問題の原因としては、要件・仕様の問題と実行体制の問題があります。
要件はどのようなシステムにするのかということであり、仕様はどのように作るのかということです。
作る作業は進んでしまっているのに、要件や仕様が漏れていたり、増えたりということが発生してしまいます。
ITシステムは見えづらいためどうしても要件や仕様の漏れは発生しがちですが、この問題を加速するのは実行体制上の問題です。
実行体制としては、発注側と受注側があります。そして、問題はそのどちらにもある可能性はあります。
実行者が退職してしまうようなことから始まり、知見が足りないといったことや、プロジェクトマネジメントと言われる、いわゆるやることの管理ができていない、ということが発生します。もちろんこれらは、発注側と受注側どちらでもありえます。
発注側と受注側どちらかに問題があり、それを起因として問題が増幅することがありますが、二者の関係においても問題が発生する原因となります。
発注側はお金を払うほうですので力関係としては強いと思われますが、そうでもなく、受注者はプロなので見識はあり、素人をいいように扱っていることもあります。
力関係のアンバランスは、問題を増幅させるきっかけとなります。
あるいは2者間のコミュニケーション不全による問題も大きな要素です。
どのようなものを作るのか決めたとしても、認識が完全に一致しているとは限りません。都度コミュニケーションをとって確認していくことが必要となります。
ただし、いずれかの理由で、コミュニケーションを遮断してしまうことが発生します。
もう一つあえて挙げるとすると、意外かもしれませんがデータ移行の役割分担によるものが問題のとなることが多いです。
新しいITシステムを導入するにあたっては、発注側が使うためのデータを入れないと動きません。
データは発注側が持っているものです。ただし、大抵はデータに関する作業を受注側で行ってくれるものと思っています。
データを新しい仕組みに合わせて入れ込むのは結構大変な作業ではあるのですが、発注側、受注側ともに何故か後回しにしてしまうことがあります。
この問題がクローズアップされる理由としては、全く開発のないITベンダーの提供した業務パッケージソフトをそのまま使う、というプロジェクトにおいても問題として発生するからです。
これら実行段階での問題の兆候は、さらに遡って考えると、そもそもどのような背景でIT導入・システム開発が始められたか、どういうコンセプトのIT企画であったか、ということに根本原因があることがあります。
すなわち、始める前から失敗が予想できるということなります。
失敗を誘発するITシステムプロジェクトを始める背景
失敗を誘発する背景としては様々ありますが、代表的なものを挙げてみます。
まずは、予算やスケジュールが非常に厳しいというものです。
予算やスケジュールが厳しくてもやりたいことややるべきことは多くあるのが通例です。実施すべき範囲をコンロールしていくことが重要となりますが、コントロールしきれず、結果失敗に至ってしまうことがあります。
もう一つ挙げるとすると、今回の計画が他の計画の中の一つであるということです。
他の計画と含めて全体としての計画があり、ITシステムとしても繋がりがある、ということはよくあります。
全部を同時に進めることはさすがにリスクが高いということで、一つ一つ進めるということなりますが、それはそれでリスクはあるということです。
失敗を誘発するITシステム企画
事業の目的をIT導入・システム開発を通じて実現していく、ということではあるのですが、どのように進めていくかによりその難易度は大きく異なります。
ただ難易度が高いというからと言って避けることはできないものが多いです。
ここでもいくつか挙げていきます。
まずは、ITシステム統合を行う、という企画です。
ITシステムをいくつか導入していると、それぞれ使わないといけないし、システム運用も煩雑になっていることが多いです。
それであれば統合してしまえばいい、という発想が起きます。
しかし統合というのは、異なったものを一つにすることであり、かなり難易度の高いハイリスクな行為です。よほどよく考えて企画を練らないといけません。
もう一つ挙げるとすると、業務パッケージソフトの導入です。
特に何もせずそのまま業務パッケージソフトを導入するという企画は、本当にそれでいいか検討が必要です。
近年SaaSと言われるサービスも充実してきており、ノンカスタマイズで利用できるものも多いと思います。
しかし、選んだものがやはり事業や業務に合わない部分があると、非効率極まりないものになります。
すべての業務パッケージソフト導入プロジェクトが失敗するとは言いませんが、失敗の危険をはらんでいるということは、認識して進めないといけないでしょう。
企画を検討するのは自分では難しい場合も多く、企画策定の支援を発注することもあります。
しかしその発注に失敗の予兆が仕込まれてしまうこともあります。
結果的に企画倒れであったITシステム
IT導入・システム開発の先にあるものは、輝かしい未来のはずです。
今複雑で手間のかかっている作業が楽になる、取引先とも情報が連動できる、顧客にも分かり易く売り上げに直結する、等々の導入効果を狙って計画・実行されるものです。
導入効果を実現するためのITシステムは、実は本当は実現できるものではなかったという悲劇が起こってしまうこともあります。
しかも、企画策定にコンサルタントに依頼したにも関わらず、結果的にその企画が企画倒れになったという例があります。
あるいは、ITベンダーに提案を受け、発注側の希望に沿うものとしては発注したにもかかわらず、提案ミスが内包されていた、ということもあります。
まとめ
IT導入・システム開発は始める前から失敗の要素を多く含んでいるものがあります。
多くの問題を解決し、素晴らしい未来に見えるようなITシステムの企画はあるでしょうが、現実的にはデータや業務プロセス、取引ルール、個別要求などにより企画倒れになるリスクもあります。
ITシステムは目に見えない、最後に使ってみないとわからない、変更の影響がわからない、といった特徴がありますので、企画段階での現実とのずれがわかりづらく、発注側と受注側でこじれてくることが多くあります。
お互いがパートナーとして分かり合ったうえで、進めたいものです。
どういうものをどう実現していくのか、そしてどう進めるのか、その過程において起こりうることを予めわかっていることは、失敗のリスクを減らすことになるでしょう。
コメント