このブログでは、中小企業経営者（ＩＴ企業）が、中小企業経営者に向けて、知った気になれるＩＴネタを発信しています。課題解決の気付きに、ここで発信するネタが少しでもお役に立てれば幸いです。ＩＴをどんどん活用して、我々の手で豊かなニッポンを取り戻しましょう！！
さて、５回目となる今回は、「なぜシステム導入に失敗するのか」にフォーカスしようと思います。ただ、非常に広範囲なテーマになるため、何回かに分割して書いていきたいと思います。
失敗するシステム導入
「これじゃないんだよなぁ・・・。」
「え、請求書を２つに分けるにはどうすればいいの？」
「〇〇さんの所は専用伝票なのに、使えないじゃん！！」
新システムを導入してからこの一ヵ月、現場からは悲鳴にも似た声が上がり続けている。ついには、
「こんなの使えねぇよ！！」
こんな言葉まで飛び出す始末に・・・。
仕方なく、業務が回るように、最低限必要な機能の変更をシステム会社に依頼すると、
「これは仕様なので、料金を頂かなければ変更はできません。」
と、冷たくあしらわれる・・・。
最初に聞いた要望は漏れなく反映されているのに・・・。
請求書発行画面のイメージを見せた時はＯＫだと言っていたのに・・・。
専用伝票が必要なんて一言も言っていなかったのに・・・。
この私が言うのも何ですが、使い手が笑顔になるような、素晴らしいシステムの開発に立ち会った事がありません。数十年間、大手ベンダーの人間として、フリーランスとして、零細企業経営者として、大小さまざまな開発案件に携わってきましたが、使い手が納得する場面を見たことがないのです。
「エンドユーザー（使い手）が完全に納得するシステムなんか作れる訳ないよ。
相手が慣れるまで、不満を上手にコントロールするのがお前の仕事なんだよ。」
その昔、こんな事を言われた事があります。
「確かに、使い慣れないから不満なのであって、慣れてしまえば落ち着くよね。」
使い手が笑顔になるようなシステムを作ることは、そもそも不可能なんだと、妙に納得してしまい、それ以来、相手が様々な不満を持ちかけてきても、
- 合意を頂いている設計書には、その通り書いてありますから、これは仕様です。変更できません。
- 確かにその方が便利になるかと思いますが、実装が進んでいますので、今から取り込むのは無理ですねぇ。予算と期間を増やして頂ければ、検討できなくもないですが・・・。
と、まあ、これを読んで下さっている方々がいつも、「何だ、コイツは！！」と思っているシステム屋の例にもれず、同じような対応を続けていました。
数年前までは、数十人以上の開発者が携わる、中規模以上の開発案件に歯車として携わる事が多かったため、使い手と開発者の間に立ち、不満が発生しても、やんわりとコントロールする事に、何の違和感も感じていませんでした。
しかし、地元のお客さまに対し、コンサルからシステムの開発・導入、その後の運用保守まで主体的に携わるようになってくると、使い手の顔が近い事もあり、お客さまが苦虫を潰したようなお顔をされながら、弊社で開発したシステムをお使いになられている姿を見ていると、胸が押しつぶされるような気持ちになる事が増えました。
『どうにかして、使い手が笑顔になれるシステム導入をできないだろうか・・・』
こうして私は、お客さまにとっては当然の、だが、システム屋にとっては永遠のテーマに取り組む決意をしたのです。
なぜ、イメージと違うものが出来上がってしまうのか？
システムを導入する場合、概ね下記の手順に沿って開発が進みます。
- 使い手（経営層等も含めた）のシステムに対する要求を明確化する
- 要求を実現する機能の見た目（画面や文言等）を設計する
- 見た目や使い勝手の部分について、使い手との合意を得る
- 見た目や使い勝手を実現する内部機能を設計する
- 設計に基づいてテストコードとプログラムコードを書く
- 技術者の手で、プログラムが設計通りに正しく動くかテストする
- 使い手の手で、プログラムが要求通りに正しく動くかテストする
一部、古典的な手順じゃないかと指摘されてしまいそうですが、上記のサイクルを回す期間や回数、規模の違いはあれど、基本的なアプローチに変わりは無いと思います。
さて、問題の多くは下記のタイミングで発生します。
7.使い手の手で、プログラムが要求通りに正しく動くかテストする
仕上がったシステムを実際に触ってみて初めて、使い手が、自分がイメージしていたものと違う事を認識し、要望やクレームへと発展する訳です。
しかし、このようなギャップが発生しないように、敢えて下記の手順を取り入れています。
1.使い手（経営層等も含めた）のシステムに対する要求を明確化する
3.見た目や使い勝手の部分について、使い手との合意を得る
逐次、システムの仕上がりイメージを共有する手順を経ているのです。
ですので、テストのタイミングで発生する様々な問題は、単なるワガママじゃないか、と考える技術者も少なくありません。
「合意を得て要望通り作ったのに、今更なんでこんな事を言い出すんだ！！」と。
通常、調整役の技術者が、使い手と作り手の双方に文句を言われながらも色々と調整するのですが、自分が調整役と作り手の立場を兼務するようになると、ある事に気が付きました。
『これはワガママで言っている訳ではない。本当に困っている・・・』と。
機能や動きについて、紙芝居等を使ってレビューした時には、ニコやかに、かつ、新しいシステムに期待の言葉さえかけてくれていた方が、今、目の前で、困惑した表情を向けているのです。
この方がイメージしていた新システムと、今、目の前で使おうとしている新システムとの間に大きなギャップがある事は明確でした。しかし私には、何がそんなに違うのか理解できない。
『なぜ、事前に内容を見てもらっているにも関わらず、こうなるのだろう・・・』
私は、不思議に思い、その方に質問をしてみました。
私：「何にお困りですか？」
Ａ：「請求書を出すとき、このお客さまは日付を和暦にしないといけないんです。
でも、西暦でしか出ないので・・・」
私：「ご要望をお伺いした時、請求書のサンプルをお見せしたと思いますが、
その時には、気になりませんでしたか？」
Ａ：「お客さま毎に、請求書の形式を変えなければならないのは当たり前だと
思っていたので、特に思いませんでした。
それと、単価の小数点を１桁までのお客さまと２桁のお客さまも・・・」
なるほど、そういう事か・・・、と思った瞬間でした。
原因１：人は、当たり前の事を語らない
新システムに対する要求をヒアリングする際に、現在発行している請求書のサンプルを提供してもらったものの、その時は、日付が和暦になっているものを確認できませんでした。
使い手も、『出し先に応じて、請求書のフォーマットを自由に変更できる』という要求は当たり前だと思い込んでいたため、この要求が設計に盛り込まれる事が無かったわけです。
確かに、人は当たり前と思っている事を確認する事はありません。
『新システムでは文字入力できるようにしてください』と、聞くまでもない当たり前の内容を敢えて、要望としてあげる事はないでしょう。
この当たり前が、使い手と作り手とで共通の認識であれば問題ないのですが、ここに少しでもギャップがあると、大きな問題が発生する事が良くわかりました。
業界では常識で通っている事が、別業界に行くと『何、それ！？』になる場合が多いのと同じように、自分の会社での常識が、ＩＴ屋には通じない場合が多々あります。
是非ともこの点を意識して、貴社を担当するＩＴ屋さんとお付き合いしてみてください。イラッとする事が減ると思いますよ。
次回も引き続き、「失敗するシステム導入」にフォーカスしていきたいと思います。
ここで、結論。
ＩＴ屋に要望を伝える際は、
敢えて、当たり前の事柄も伝えてみること。
如何でしたでしょうか。
システム開発が失敗する要因について、少しでも分かった気になって頂けたでしょうか。
これからも、このような形でＩＴネタを発信していきますので、ご愛顧のほど、よろしくお願い致します。
