|
|
- ★ メンテナンス編 ★
本番後になって初めてわかる現実
どこのユーザーでも同じです。
あれだけ多くの時間、
・現場の意見の要望を聞き
・問題の改善案を考え
・運用イメージを確認して
・考慮モレがないことを確認して
・リハーサルを行って
・多くの苦労を重ねて
本運用にのせても
実際に運用してみると思わぬ所に新たな問題が発生します。
それは、直ぐに対応が可能な小さな変更、
大きな変更を迫られる変更
至急対応が必要な変更
いろいろ症状はあります。
今まで多くのプロジェクトに参加してきましたが、
現場が本番後に変更なしで、運用を継続したことは一度もありません。
たまたま私のユーザーは、ガマンしなかっただけかも知れませんが。
人間は、完璧じゃないんです。
つまりは、補正するメンテナンスが必ず必要なのです。
でないと長く使ってもらえるシステムにはならないのです。
大規模プロジェクトでは、
本番後の故障対応などの常駐要員確保を行うことは
当たり前になっています。
この中の予算で些細な要望対応も含んでしまっているのが現実です。
小規模プロジェクトになるほど、作成して本番で終了なのですが、
実際には、当初予定外の問題が多数発生してきます。
この費用配分が、当初見積り含まれているのか
事前確認をしておかなければならないのです。
問題対応が行われないと、結局使われないシステムが出来上がるのです。
ユーザー側責任による大きな変更が発生する場合もあるのです。
予算も組んでいなければならないという事です。
本番後になって発生する問題として
・機能の考慮モレ
・業務運用に漏れていた処理パターンの存在
・性能不良又は、当初予想を上回る処理件数による性能劣化
・入力項目モレや出力項目モレ
などがあげられます。
ユーザー側においても、
本番後の対応予算を、当初予算を削ってでも確保しておく必要が
あるのです。
機能レビューや仕様確認を行っていない場合は、なおさらです。
最初から完璧なものは、出来ないのです。
ここで
本番後の仕様変更対応工数は、当初見積りの計算式ではないことに
注意しましょう。
つまりは現実的であり、リスク分の見積りは排除可能なのです。
ユーザーにとって交渉の余地は、大きく残されていると言うことです。
|
