現状業務分析をきちんとやらずに失敗するプロジェクトが、いまだに多いのは残念なことです。
システム開発ライフサイクルは通常、企画・業務設計・システム設計・製造・テスト・運用・保守から成り立っています。
業務設計は、さらに現状業務分析と新規業務設計の２つに区分けできます。
この現状業務分析という工程を手抜きするために、多くの問題が噴出することになります。
近年のプロジェクトでは、開発期間が短く・予算も少ないため、必要と思われる工程をショートカットしてシステムを構築したくなります。「現状業務については普段から運用・保守している担当者が知っているはずだから、現状業務分析を省略しても問題ないのでは・・・・」と考えるわけです。
あるいはユーザ部門から「現状業務については情報システム部門が把握しているはずだ。設計ドキュメントだってあるはずだ。だから省略して、一刻も早く新しい業務の話に入ろう」と言われることもあります。
しかし、現状業務分析工程を手抜きすると、次のような問題が出る確率が高まります。
- 現状業務の主な流れ・データ構造を把握することはできますが、細かいバリエーション・例外処理を把握できないまま工程が進みます。結果として、テスト工程で対処できないことが発覚し、大幅な後戻りが発生します。最悪の場合、テスト工程でバグを発見できずに、本番稼動後にユーザやお客様に迷惑をかけることになります。
- 現状のデータ構造を理解せずに新規データ構造を作成するため、データ移行設計に手間取ることになります。最悪の場合、現状データを新規システムに移行できないことになります。この点は、ERPパッケージ導入の際にも注意すべきことです。
- 現状業務を知っている人が限られるため、その人がボトルネックになり、作業が滞るようになります。現状業務分析をプロジェクトメンバ全員が実施していれば、現状のナレッジが広く共有されることになり、多くの質問が特定の人に集中するリスクを避けることができます。
- 現状業務を可視化した図面を見ながらコミュニケーションする、あるいは新規業務設計することが、実は一番確実で早いのです。データ構造でいえば、現状と新規の差は２０％もありません。せいぜい５％程度です。すなわち、現状データ構造を先に押さえ、新規データ設計で５％分だけ修正する方式が、品質も高いしリスクも少ないのです。
ほかにもいくつかありますが、
要するに現状業務分析は省略して良い工程ではなく、むしろ積極的に工数を使うべき工程なのです。
ぜひ、システム開発の際には、現状業務分析工程を手抜きすることなく、きちんと実施していただきたいと思っています。
« 業務アプリケーションの大きさEDW 2011に参加します »
