システム導入で失敗するパターン

私はこれまで多数のシステム導入・改善に関わってきました。

自分で開発したシステム

メーカーに開発を委託したシステム

パッケージシステム

など、導入の形も提供する業務内容も様々です。

長い経験の中でこれは失敗するな・・・というものがあります。

今回はアンチパターンとして、それらを書きたいと思います。

１．手段が目的化する

ITプロジェクトに関わることは、システム担当でない限り、

約40年の会社員生活においてもそう多くあるものではありません。

人生でいうと家を建てるような経験に似ています。

そうすると何がおきるかというと、夢が広がります。

折角だから、今まで困っていたことを一気に解決したい。

折角だから、すごい良いものを作ってシステムを使う人を喜ばせたい。

この「折角だから、・・・」が失敗への囁きになります。

「折角かかわったのだからできる限りのことをしたい」

「こうすればよくなる」

そう考えていると、楽しくなってきます。

そして、あれも、これも、とやりたいこと（要求）が増えてきます。

これ自体が悪いことではありません。

悪いのはシステムをつくることが目的になってしまうことです。

システムはあくまで手段であることを忘れてはいけません。

一つ一つの要求に対し、費用対効果があるのかを精査する事が重要です。

その要求はmustなのかbetterなのか。冷静に考えましょう。

２．ファンタジーに入り込む

限られた期間や予算に対して現実的でない機能を搭載しようとする。

何年に１回おきるかどうかのケースに対応しようとする。

これが出来れば課題の全てが解決すると思ってしまう。

特にAIやIoT、機械学習といった新しい技術を利用したDXの場合に多いように思います。

こういった場合は、実際にどの程度実現性があるか、現実的なレベルを見極める必要があります。

必要なら、開発よりも小さいコストでPOC（実証実験）を行うのも良いでしょう。

３．軌道修正が多い

開発を進めると議論が深まり、ユーザー側で気付きが増えていきます。

これは自然なことです。

見積りを行う前の段階で全て業務要求を洗い出せることは稀です。

必ず

「そういえば、こういうケースも・・・」

というイレギュラーパターンが出てきます。

この時、これも対応したい、このパターンもあるな・・・

と気づきの全てを詰め込もうとするケースがあります。

対応しないと業務が成り立たないようなケースは予算・期間を追加してでも起動修正するべきです。

ただ、そうでもないケースも多々あります。

物によっては、別スケジュールで行う、システム化を見送る、

など冷静な判断が必要になります。

経験することが少ないシステム導入だからこそ、思いや勢いだけでなく、

現実的で冷静な判断が必要になります。

家を建てる例を出しましたが、思いや勢いだけで建てた家・・・

あまり住みよいとは思えませんよね。

事業者は適切な専門家の意見を聞きながら、

効果的なシステム導入を目指しましょう