何故システム導入に失敗するのか？（その１）

『旅するお荷物 vol.11』
大原 欽也

金融大手の勘定系システム、行政府の感染対策アプリ、さらに大手食品メーカーの基幹システム等々、管理システム導入に失敗したというニュースが耳目を集めることが多いです。

実は上記は氷山の一角、世の中を見渡すと死屍累々の惨状といった有様です。思うに、これだけ多いと、これらの失敗はシステム導入の手はずが他と違っていた特殊事例とは言い切れない、逆に言うとシステム導入では偶発的にしろ起こり得ることと考えておくべきなのです。もちろん失敗例が山ほどあるのは、それよりはるかに多い導入事案があるせいですが、そうはいっても失敗が運に左右されるようにも見えるのは、なんとも気味が悪い。

今どき、なんのシステムにも頼らずに業務をこなしている企業などほとんどないでしょう。ならば、あらゆる企業に起こりうる失敗ととらえるべきです。

私はシステムに関して素人ですが、失敗や失敗や成功の経験から素人なりのお話をさせていただきます。

【どこで失敗しているのか】

・ベンダー
例えば、基幹システムを見てみると、ベンダーによる違いはなさそうです。というか、あってもダメなベンダーはすぐに淘汰されるでしょう。それどころか、世界的大手のベンダーでさえ失敗事例は多いように感じます。ただし、これは導入事例も多いこともあると思います。他のもっと小ぶりなシステム、例えば物流システムでも同様です。

・コンサルタント
間にコンサルタントを入れるケースも多いです。ユーザーとベンダーとで、互いの専門分野の理解が不十分なことも多いので、コンサルタントはそこをスムーズに通訳してくれます。だからといって安心は禁物で、上記事例でもコンサルタントは入っているのです。それに、ユーザーとコンサルの間より、コンサルとベンダーの間の距離の方が近いものです、その実、ものすごく近かったりします。意思疎通も距離感に応じたものになるでしょう。

・汎用品かオリジナルか
パッケージ（出来合いで汎用性のあるシステム）にするかスクラッチ（一からオリジナルとして開発するシステム）にするかでは、大きな違いがありそうです。パッケージは適合性に問題が残るとはいえ、カスタマイズして修正できます。スクラッチは適合性は高いですが、高い開発技術と十二分な意思疎通が必要です。そして残念ながらどちらの場合も失敗しています。

・新規導入とリプレイスと
すでに導入され使用されているシステムのリプレイスなら、同じようなものに替えるだけだから、全く新しく導入するよりは、難しいことはないように思えます。ところが、やはり失敗は多く、それどころかリプレイスならではの失敗というのもあります。

・ようするに…
ようするに成功を約束する魔法の杖はなさそうです。なにやら地雷原を進む最前線の歩兵のように思えてきます。いや、そう思って事に当たるべきなのでしょう。そうはいっても、成功を時の運にゆだねるわけにもいかないのだし、失敗するからには何か原因があるはずだ、と思いたくなるのも人情です。いや、その前に、なにゆえシステム導入などという危険な賭けにでるのか…自問しているのでしょうか。

【システム導入は何のため】
不思議なことに、導入の目的がぼんやりしていることが多いように思います。業務が効率化しそうだから、他部署とデータ連携したいから、データを残して活用したいから、はては、社長に言われたから、そろそろ入れ替えないといけないから、まで。このような焦点の定まらない動機こそが問題の発端かもしれません。

・業務効率化
これが一番多いと思いますが、どこをどう効率化するのでしょうか。それで本当に業務時間を削減できるでしょうか。部署全体に効果を発揮するでしょうか。

極端な話、ある部分的な業務をシステムにまかせられたからといって、少し手を休められるだけで、担当者がディスプレイの前に拘束されている時間は変わらないかもしれません。

そんなバカなと思うかもしれませんので物流の事例を紹介します。これはシステムというより、設備を含めた自動倉庫システムが分かりやすいです。商品コードを入力するだけで入出庫が自動でできます。オペレーターは、入庫時にコード入力すると自動で棚入れしてる間、次の棚入れまで待ち続けます。出庫時はコード入力してから商品が出てくるまで待ち続けます。当然その間、ほかの仕事はしませんし、初期のモデルは動作もフォークリフトよりかなりのろいものでした。

何も自動倉庫が悪いわけでもなんでもなくて、全体のオペレーションを考えたうえで導入した企業と、とりあえず他も入れてるからといって導入した企業では、効率化に大きな違いが生じました。

実際のシステム導入でも全体を視野に入れずに、あれをして欲しいこれもして欲しいのコマ切れ要求ばかりで、それらを全部合わせると整合性が取れなかったりするのです。

・データ連携
これも業務効率化の一環なのですが、データが連携できればとても便利です。だたし、あっちとこっちでデータ形式をそろえる必要があります。できなければ変換プログラムを実装しなくてはなりませんし、それも無理なら手修正することになり、これが場合によってはかえって手間だったりすることもあるし、ミスの原因にならないようにしなくてはなりません。さらに、部署間でセキュリティの問題があるとアクセス権限の仕組みも必要です。月末締めの時に担当が変わっていてデータを取りに行けない、などの悲劇が起きないようにしてください。

・データ活用
個人的には可能な範囲で粒度を細かく残せればいいのかと思っています。この時の許容しうる粒度設定はセンスの問題が大かなと･･･。思うに、日ごろから業務データを色々探しては活用している人はセンスが磨かれます。逆に普段活用していない人は、活用できるようになったとして活用しないでしょう。

物流データで事例を紹介します。輸送車両の仕事量を表す極めて重油な指標にトンキロ（輸送質量×走行距離）があります。ところが日々の締めでデータとして残るのは全輸送の総質量と総距離だけだとすると、この二つをかけても真のトンキロにはなりません。だから粒度を細かくして１運行ごとのデータを残せるようにしたいのです。

しかし、仮にそれができなくても、定点観測を何回かすれば、大抵はざっくりとしたトンキロの数値を得ることができたりします。細かな説明は省きますが、わかってほしいのは、データが不十分であっても、工夫次第である程度の事は把握できるものです。要はデータを活用するぞ！、の気合いが大切で、なんでもかんでもデータを残したがる人に限って利用しないような気もします。

・ツルの一声
ツルというのは社長あたりのことですが、これには従った方がいいです。ただ経営層の習性というものも知っておいて損はありません。何はともあれ業務の遂行状況を把握したがる方々なので、ベンダーに「居ながらにしてキーを叩けばすべての情報が監視できます」などといわれると、とても喜びます。

ところがそのために、余分な連携が必要になったり、末端の一部署だけのマスター（一覧表のようなもの）でいいものが基幹のマスターに組み入れられてしまったり、挙句の果てには情報の重複が起こったり、そのために重複ミスの検出機構を設けたり、となったりするようです。

ツルの希望に叶うようなシステムは中央集権的な立て付けになるのでしょうが、システムが大きくなれば、そのような構造では内部の連携が困難になるように思われます。詳しく述べるわけにもいきませんが、最近の基幹システムなどは、複雑化したあげく、構造的問題が生じてきているようにも思えます。

なお、先ほどの話と同じで、それまでデータを活用してこなかった人が、急に活用しだすとは思えません。本当に必要性を感じているなら、「これとそれのデータは取り込めるようにしておくように」と具体的に指示するはずです。また、トップが現場のオペレーションに口を挟むようでは、そもそも組織として如何なものかとも思います。

・リプレイスの罠
同じシステムも１０、２０年も使えば古くなってきます。そこで入れ替えるだけだからと、安易な気持になりがちです。これが失敗の元となります。

考えて欲しいのは、この１０年、２０年でシステムに何があったのかです。その時々で小さな改変がなされていて、一つ一つは小さくても１０年も立てば、ある程度違ったものになっているはずです。それぞれは業務遂行のためにどうしても必要なことではあったはずです。はずですが、追加した機能が元々実装されていなかったことから考えても、かなり無理のある改変でもあったのではないでしょうか。

そもそもシステムというものは論理的に出来上がっているものです（直近のＡＩが絡んだものはその限りではないかも）。そこへ無理やりの改変は、あたかも真直ぐに伸びる杉の木に松の枝を接木したり、伸びてきた松の枝を東から西へ曲げたりするようなものです。

それは悪いことではなく必要なことだったのです。ですが、すっきり感はどこかへいってしまっています。そのうえ多くの場合、正確な改変記録は残っていなかったりして全体は伏魔殿状態です。

そこへ装いも新たにすっきりした新システムを導入するわけです。多くはすっきり感の中身がちがう別のベンダーだったりもします。この状況で何も考えずに導入したら混乱しない方がおかしいのではないでしょうか。

だから、なにがなんでも現行の機能はっ全て残せ、は無理な注文だったりするです。システムの変化に無理解なまま盲信するユーザー側に混乱の原因があります。

その結果、運用テストで問題が表に出たりします。まともに稼働しないのです。その状態が続くと、やがてベンダーから提案がなされます。リモートによる監視体制を設けさせてください、と。１週間も徹夜が続くと、さすがに受け入れざるを得ないかと思ってしまいます。それは自動システムを手動で動かすという提案なのですが。またセキュリティ強化もリプレイスの目玉だったはずなのに。ユーザーの負荷も大きくなります。システムを使うはずがシステム維持も仕事になります。

だから目的をはっきりさせるところからはじめましょう。ですが、そもそもなぜ目的がぼんやりなのでしょうか。
（続きは10月15号）

【出典元】
・日経コンピュータ：動かないコンピュータ
・田村昇平：御社のシステム発注はなぜ「ベンダー選び」で失敗するのか
・白川克他：システムを作らせる技術
・田村昇平：システム発注から導入までを成功させる９０の鉄則