自分自身の業務なので、システムを作りながら軌道修正することは、いくらでもできます。技術的にできないことはあるかもしれませんが、作ったシステムに不満は出ないと思います。
しかし、開発者と利用者が異なる場合は、「イメージと違う！」ということが、たまに起こります。失敗原因の多くは、開発工程の初期段階で、開発者とユーザーの間に、認識の違いがあったためです。
開発者は技術の専門家で、利用者はその業務の専門家です。もちろん両方に詳しい人が作るのが一番良いのですが、普通はどちらかが歩み寄ることになります。
つまり、開発者が業務について学ぶか、ユーザーがシステム開発に詳しくなるかです。一般的にシステムを外注する場合は、前者のパターンです。
開発者と利用者の両者にとって、システム開発で失敗しないためには、初期の打ち合わせが非常に重要です。
開発者の視点から見ると、打ち合わせの中で、いかにユーザーのシステムに対するイメージを引き出すかが勝負です。
逆にユーザーの視点から見ると、自分が欲しいシステムのイメージを、いかに開発者に伝えるかということになります。
この時に頭に入れておきたいことがあります。それは、
・ユーザーにしかわからない画面イメージがある
・開発者でなければわからない画面イメージがある
ということです。
どんなシステムを作りたいのかは、ユーザーにしかわかりません。でもシステムに詳しくないユーザーの場合、システム自体をイメージすることができません。したがって、どういうふうに伝えたらいいのか分からないのです。
また一般的なシステムの画面構成というのは、開発者にしかわからないものです。
そこで両者で協力して、システムのイメージを作り上げる必要があります。
通常、業務システムは、大体以下の流れになります。
入力画面 → 処理 → 出力画面(または帳票)
「入力」と「出力」がユーザーの満足するものであれば、システム開発で失敗する可能性はかなり低くなります。
そこで最初は手書きでもよいので、ユーザーがわかる範囲で、画面のイメージをデザインしてくれれば、開発者としては非常にやりやすいです。
または、現在使っている書類に書き込んで、イメージを伝えてもかまいません。
どんなデータを入力して、どんな出力が得たいのかがわかれば、開発者はそれにシステム上で必要なボタンなどをプラスして、ユーザーに画面イメージを伝えやすくなります。
もちろん「処理」も大事ですが、システム上はユーザーから見えない部分になります。
一度イメージの土台ができれば、今度はユーザーのほうから、「ここはこうしたい」といった要望が出てくるようになります。
そして最終的には、「そう！こんなものを作りたかったんです。」とか、「イメージ通りです。」といってもらえます。
システム開発者は、『聞き上手』になって、ユーザーの漠然としたイメージを、具体化できるようになりましょう。
【ワンポイント】
開発者も全ての分野に詳しいわけではなく、得意分野があるものです。
もし開発者が、システム化の対象となる業務に詳しい場合は、最初から開発者が提案しても大丈夫です。
