本来の目的が確認されない
提案段階では、お客様の要望をヒアリングし、システム化の要件として定義し、開発へと進みます。
一見、なんの問題もないように思われるこの進め方に、大きな問題が潜んでいます。多くのお客様が、そのことに気づくことなく、失敗プロジェクトに突入してしまっています。
その一つは、システム化する本来の目的がしっかりと確認されないことです。
耳障りのいいシステム会社の提案には要注意！
お客さまからは、「こんなことがしたい」「あんなことができないか」といった、要望が出されます。あるいは、「○○システムを導入したい」という場合もあります。
システム会社からは、それなら、「□□というパッケージがあります」「オーダーメイドで開発しましょう」といった提案がされます。提案には、売上アップや、コストダウン、経費削減といった耳障りのいい謳い文句が並びます。
それならお願いしますと、システム導入へと進みます。この時点では、お客様は、システムができれば、全て上手くいくはず、と思います。こうして、システム化すること自体が目的化し、開発へと進んでいきます。
しかし、これでは上手くいきません。
本来の目的が何であるかを見定めることが不可欠
お客様の要望は全てのはじまりでとても大切です。しっかりと耳を傾ける必要があります。しかし、だからと言って、その要望の通りに実現することが、お客様のためになるとは限りません。むしろそうではないことが多いのです。
お客様の要望の中には、矛盾していることもあれば、実現が難しいこともあります。優先順位をつけて、何からどう実現すべきなのかを整理するのが、提案段階に必要な作業です。その判断をするためには、本来の目的が何であるかを見定めることが不可欠です。判断基軸がなければ、取捨選択や優先順位がつけられないからです。
本来の目的が何であるかを見定めることができれば、自ずと必要なこととそうでないこと、優先すべきこととそうではないことが明らかになります。何のために何からどうするかが明確になれば、本来の目的に合致した要件を定義することができます。
”本来の目的”がはっきりせずゴールが見えない
しかし、一般的に提案段階では、こうした本来の目的が見定められることなく、システム化が提案され、要件が定義されています。本来の目的が見定められていないということは、一体、何のためにシステム投資するのかがはっきりしていないことに他なりません。
本来の目的がはっきりしないまま開発に進めば、ゴールが分からなくなります。従って、出来上がったシステムは、評価することさえ難しいものになります。
多くの一般的なシステム開発では、開発が始まる前の提案段階で、既にこうした根本的なボタンの掛け違いをしているケースが多く発生しています。
業務の見直しが行なわれない
システムの提案段階には、もう一つ大きな落とし穴があります。それは、業務の見直しが行なわれていないことです。
お客様として、業務の見直しが必要という認識があれば、見直しをしたいという要望を出されているでしょうし、あるいは、既に変更している筈です。そもそも業務改善についてはシステム化を相談している開発会社に期待していない、ということもあるでしょう。お客様としては、結果的に今の業務でいいという判断の元、その業務を行なっているわけですから、潜在的に問題認識を持たれていても、顕在化できずに見過ごされています。
システム会社としても、業務的なことはお客様の仕事と考えている場合がほとんどです。その責任はお客様にあると考えていますし、踏み込んで提案しようと考えていません。
しかし、そもそもシステム化したいという要望がある時点で、それは業務的に困っている証しで、そこには必ずといっていいほどシステム以前の潜在的な業務上の課題が潜んでいます。
システム化しても業務的な改善は実現されない
現行業務のままシステムが導入されても、業務自体が見直されていなければ、潜在的な業務課題は残ったままです。
業務的な面に目を向けずにシステムが導入された場合、元々の業務に問題があるのに、その問題のある業務がシステム化されても、業務としての効果は上がりません。結局、システム化した分、余計に仕事が増えたり、それが負荷となって効率が悪くなったり、結局使われなくなったりすることさえあります。
これでは、何のためのシステム化投資かわからなくなってしまいます。
