2008_04_24－メンテナンスの見積り。

２００８年４月２４日発行

分割ラインです

　《　予算・実績管理編　》

　　
　メンテナンスの見積りってどうやって見積もっていますか？
　　
　　
　　既存システムのメンテナンスの見積りは、どうやって見積もっていますか？
　　非常に難しい見積りです。
　　
　　
　　
　　調査してみないことにはなんとも言えません。
　　　　・仕様書は、どこまで揃っていますか？
　　　　・最新版になっていますか？
　　　　・追加変更機能は、明確ですか？
　　　　・影響範囲の調査は、これからでしょうか？
　　
　　
　　
　　目に見えないだけに、調べる作業も大変になります。
　　既存箇所をどこまで残すのか、どこを修正するのか、
　　　　　　　　　　　　　　　　どのように追加するのか？
　　
　　
　　かなり昔からメンテナンスを手がけてきましたが、
　　　　　　　　　　　　　　　　　正しい答えは、ありません。
　　
　　
　　既存システムを知っているか否かで、見積り金額は大きく異なってきます。
　　だから、一度受注したシステムはメンテナンス需要がある限り、
　　　　　　　　　　　　　　　　　　つながりが切れることは少ないのです。
　　
　　
　　
　　
　　既存を知らない業者の場合は、既存を修正することは極力控えようとします。
　　メンテナンスの多くは、既存プログラムを可能なかぎり修正しないように
　　変更します。
　　それでも費用は高くつきます。
　　
　　
　　ＤＢやファイルをインターフェースにして機能追加という手法を使います。
　　　　これは、
　　　　　　　費用を少なくできる。
　　　　　　　既存システムへの影響を極力最小限にできる。
　　　　　　　既存システムからの品質影響を少なくできる
　　　　しかし
　　　　　　　希望する機能は実現できても、全てを一元化することは難しい。
　　　　　　　不要となった機能は、残ったままにゴミとなります。
　　　　　　　ＤＢやファイルと言えども、既存項目の内容を変更するとなると
　　　　　　　　　影響度は、ネットワークの先まで行きます。（世界中？？）
　　
　　
　　
　　今では、多くの企業情報システムは、
　　ゴミがたくさん残った状態で稼動しているといっても過言ではありません。
　　ゴミの整理にも、単純に削除できないため多くの工数が必要になります。
　　
　　
　　ただ、プラットホームが汎用機からＰＣに変わることにより整理される場合も
　　あります。
　　但し、年月が経てば同じことの繰り返しになりますが。
　　
　　
　　
　　
　　
　　既存システムの変更見積りは、
　　既存への影響度をどこまで見積りに組み込むかによって大きく変わります。
　　　　　・追加要望機能の対応工数見積り
　　　　　・既存システム調査工数（実績払いが多い）
　　　　　・既存システムの変更工数見積り
　　　　　・リスク分の見積り（実績払い？）
　　
　　
　　調査した結果が正しいのかは、誰にもわからないと言うのが現実なんです。
　　　　　・調査した範囲は明確にしておきましょう。
　　　　　・既存システムの変更に伴う根拠も明確にしておきましょう。
　　　　　・既存システムの試験範囲と試験内容を明確にしておきましょう。
　　　　　・トラブル発生時の対応についても明確にしておきましょう。
　　
　　
　　既存システムの箇所は、故障発生リスクの高い箇所です。
　　　　　・故障の切り分けが、大変になることを理解しましょう。
　　　　　・修正ミスなのか？修正忘れなのか、正しく切り分けましょう。
　　　　　・今回の見積り対象範囲内／外なのか？
　　
　　昔は、「お前たちプロだろう。」の一言で泣いていた時代もありました。
　　
　　
　　
　　
　　
　　故障が発生してもお客様からみると、よくわからないのが現実です。
　　しかし、至急対応しなければなりません。
　　
　　　前もって、対応策を検討して不慮の事故にも対応可能な体制と契約を
　　　　敷いておきましょう。
　　　　　突然、故障発生と言われてもお互いに迷惑になります。
　　　　　　考えられるリスクは事前に報告しておくべきです。
　　　　　　　報告内容が少ないほど、必ずもめて大問題となっています。
　　
　　
　　
　　メンテナンスほど、リスク管理が重要になってきます。