システムの必要性は前回述べましたので、今回は「システム開発の弱点」を語ってみようと思います。
「業務システム導入しましょう！」
開発会社からこんな話をされたとき、大半の方は「どうせ高いしなぁ。。。」とか、
「みんな使ってくれないしなぁ。。。」「本当に業務効率上がるの？」など、否定的なイメージを持ってしまいませんか？
恐らく古くから続くシステム開発の在り方が、「システム＝高くて実用的じゃない」というイメージを植え付けてしまったのだと思います。
では、古くから続くシステム開発の在り方とはいったいなんでしょうか？
弊社ではクライアントとベンダーの「目的の相違」であったと考えています。
システム導入に対する目的
クライアントがシステムを導入する目的
・システム導入で業務課題を解決したい
ベンダー（開発会社）がシステムを導入する目的
・クライアントから依頼された課題を解決したい
どちらも同じ目的を共有できてますね。
では、なぜ「目的の相違」と述べたのかといいますと。
初期目的は同じでも、開発工程が進むにつれ、ベンダーの目的が変わるからです。
従来の開発手法では、以下の流れで開発を進めていきます。
・要件定義（☆初期目的はここ）
・基本（詳細）設計
・コーディング
・試験
・リリース
この開発手法には、前工程が完了しなければ先に進めないというルールがあります。
（この手法をウォーターフォールといいます）
このルール自体は問題ではないんですが、もう一つの「約束」が融合することで、
開発会社の「目的」が変わるのです。
その約束とは、「リリース日」です。
実際のシステム開発において、要件定義通りにすべての工程が恙なく進むことは「まれ」です。
設計段階でクライアントにとって無意味な機能であると判明することもあります。
試験段階で大きなシステムの見落としから手戻りになることもあります。
ですが、その変更を認めることは開発会社の不手際を認めることになりますし、
見落としに関しては工程の巻き戻しが発生します。
前工程を終わらせるために、
リリース日を予定通り迎えるために、
この想いが本来の目的を見失わせてしまうのです。
システム導入の目的が「課題を解決すること」から「システムを作り上げること」に変わる瞬間です。
開発を請け負うベンダーは、いわばその道のプロです。
でも人間なんです。神じゃありません。
要件定義の段階で、実際に使ってもいない業務システムを完璧に作ることは至難の業なのです。
クライアントが自らの課題を１００％伝えきること。
ベンダーがクライアントの抱える課題を１００％理解すること。
２つが揃って初めて成しえることです。
システム開発は、クライアント本位で進めるものでもなく、ベンダー本位で進めるものでもありません。
ましてや「作ること」を目的にしては、本末転倒になってしまいます。
実運用を通して共に問題提議し、共に改善していくことで「本来の目的」に近づくのではないでしょうか？