失敗しないシステム開発

ともするとシステム導入は、トップダウンの意思決定により導入され 現場レベルでの被害者意識を招くことにもになりかねません。また発注側が予め知っておくことでトラブルを防止したり、その後の導入・運用を効果的に行うこともできます。

ここでは「失敗しないシステム開発」のために考慮すべきポイントをまとめました。

100%システム化は逆効果の場合も

完全にシステム化しようとすると膨大なプログラムや難易度の高いアルゴリズム（処理）が必要となり、それを完全に仕様として作り上げることが困難になります。また開発コストも高騰します。

手作業やアナログのフローを一部残すことで、シンプルで使い勝手の良いシステムを費用を抑えて構築できる場合があります。

今までの業務フローを一気に変えない

システム化を機に今までの業務フローをゼロから再構築し直し、システムを前提とした効率的な業務フローに一気に改革しようとするケースも見受けられますが、これはお勧めできません。

まだ誰も運用したことのない改革後の業務を、あらゆる可能性を想定して事前に仕様レベルにまとめることは不可能に近く、運用開始後に「こんなハズじゃなかった」と気がつくことが容易に想定できます。

また現場レベルでは、今までやっていた業務が刷新され不慣れな新しい業務フローに対応しなければならなくなると同時に、システムの操作も覚えるなければならない、二重の「新しいこと」に取り組まなければなりません。現場が混乱・疲弊し、反発や抵抗を招く恐れもあります。

既存業務フローの「見える化」がポイント

システム化する際に最初に重要となるのが『既存業務フローの「見える化」』です。一口に「業務フローの見える化」と言っても、業務内容を精査し それを書き出す＝見える化するのは簡単なことではありません。

しかし見える化ができれば、そのど部分でどんな問題があるのか、またそれに応じた対策などの議論がスムーズにできるようになります。また、システム化する際の基本的な流れ・概要も見えてきますので、まずはぜひ既存業務フローの「見える化」をしてみてください。

開発（プログラミング）開始後は仕様変更しない

開発＝プログラミングを開始してから、思い出したように顧客（クライアント）から機能追加の要望などが五月雨式に上がってくることがあります。しかし例えば たった1行表示内容を増やすだけでも、データベースの設計から変更しなければならないケースもあります。また当初考えていた効率的なプログラミングに、追加プログラミングせざるを得なくなり、非効率な処理だったり思わぬバグの温床になったりする可能性もあります。

従って仕様検討段階でしっかりと要求仕様を洗い出し、機能に反映させることが重要です。また仕様確定後に生じた要望等は、完成後に改めて機能追加として対応し、途中で変更や手戻りがなくなるように進めていくようにしてください。