2008_05_07－ユーザーからみたＩＴプロジェクト見積りの値引き。

２００８年５月７日発行

分割ラインです

　《　リーダー教育編　》

　★　契約編　★ 　　
　　
　ユーザーからみたＩＴプロジェクト見積もりの値引き。
　　
　　
　　ＩＴプロジェクトは
　　　・開発規模が大きい程、ＲＦＰに基づいてプレゼンテーションが
　　　　　行われ価格／内容によって選考されます。
　　　・規模が小さいものは、合い見積もりによる選考もあります。
　　　・お客様からの一方的な依頼によって決まる場合もあります。
　　
　　どれも価格競争力は、少なからず働いています。
　　
　　
　　この価格競争力が適正かどうかが、大きな問題になってきます。
　　お客様によっては、値引きを大きくして安く仕上げたい。
　　ＩＴ企業側は、売上目標達成するためになんとしても受注したい。
　　この様な思惑が、各社入り乱れたプレゼンテーションになります。
　　
　　
　　ＩＴ開発は建築によく似ていますが、大きな違いは
　　　　　・目に見えない。
　　　　　・問題が発生しても多くは簡単に修正が可能
　　　　　・重要な制御プログラムを除けば、生命に危険が及ぶことが少ない。
　　
　　
　　このような背景からダンピングが発生しやすいのです。
　　ユーザーにとっては、安値で発注できたように思いますが、
　　　　その分運用リスクも高いのです。
　　　　
　　目に見えないために運用動作状況だけを見ると
　　　　　うまくいっていたりします。
　　
　　
　　故障発生リスク以外にも
　　　　利用者増加に伴う性能リスク
　　　　機能追加に伴う仕様変更リスク
　　　　サードパーティソフトのレベルアップ対応リスク
　　　　災害対応リスク
　　
　　　などのリスクが増加してきます。
　　
　　
　　
　　さらに根が深いのは、
　　お客様の見えないところでのダンピングも発生していることです。
　　ＩＴ業界は建築業界と同様に下請け構造社会だからです。
　　
　　
　　極端な値引きは、お互いの将来を不幸にするものがあります。
　　かと言って、ＩＴ企業側の見積もりの根拠が不明確なのも事実です。
　　特に新規システムと既存システムの連携箇所は、
　　　　　一番費用見積もりが難しい点ではないでしょうか？
　　
　　大規模システム程、既存システムとの連携機能は非常に見積もりが難しく、
　　設計モレや故障の多発などで、結局最後は大赤字になってしまうケースが
　　多いのです。　　
　　
　　
　　お客様にとっては、安値で受注できているように思うのですが、
　　ごり押しした箇所は、受注者側も費用をかけない考えが大きく働いているため、
　　前述のようなリスクを抱え込んでしまい、
　　　　　　　　　お客様側につけが回って来やすいのです。
　　
　　
　　
　　私が考えるには、
　　　　・見積もりの分割（機能や既存連携箇所）
　　　　　　一長一短はありますが、複数企業参加によりどんぶり勘定は
　　　　　　避けられます。
　　　　・見積もり時点を複数回設定
　　　　　　難易度によって最終見積もり時点を変えてみるのも一考。
　　　　・品質目標値の設定
　　　　　　強化試験や再試験条件などを入れて、クリアすべき目標を設ける。
　　　　・性能目標値の設定
　　　　　　環境条件を設定して、性能目標をクリアするまで自主改善を行う。
　　　　・ＩＴ企業側の姿勢として、メンテナンス時の要員体制など
　　　　　　長いスパンで支援の考えがあるか
　　
　　
　　
　　金額だけで判断するのではなく、
　　　　　その後に抱え込むリスクも考慮しながら、
　　　　　　　　判断することが、長い目でみた場合は有効だと考えます。
　　
　　
　　
　　事前に目標設定する方法も対策の一つではないでしょうか。
　　見積もり承認後はお任せ、では成功などありえません。
　　　　　　適宜チェックと指導を織り交ぜていくことがミソです。