大発明！？ソフトウェア保守工数の新見積り方法

このテーマは専門的な内容です。

システム開発の場合の見積りは、

どれだけのものを作るのかを確認・計測し

それに原単位を掛けて行います。

製造業の製品の見積りと同じ方法です。

ところが、今やシステム開発の数倍あるという

ソフトウェア保守の見積りは

何をしなければならないかを検討すると、

次はいきなりそのためにしなければならない作業工数を

見積るのです。

するべきことと作業の間の原単位がありませんから、

なぜその工数が必要かが第３者には分かりません。

例えて言えば、家の改修の際に

台所の床の張り替え、調理台の入れ替え、窓のサッシ化

トイレのうウォッシュレット化にいくらと

見積りが出るのが依頼者の納得がいく

一般的な見積り方法です。

それに対して、今の保守の見積りは、

全体で部品代がいくら、大工の日当がいくら、

工事代がいくら、とくるようなものです。

保守の依頼者は、

見積り者の言うことを信ずるしかないのです。

全体をするかやめるかの判断しかできません。

こんな理不尽なことはないでしょう？

そこで、保守の場合にも、

こういう窓のサッシ化ならいくら、

現状がこういう場合の調理台の入れ替えならいくら、

と見積りができるようにする、

というのが新方式です。

当たり前のことですが、

これをやってみようと思いつく人がいなかったようです。

コロンブスの卵的かもしれません。

その見積り法の流れは以下のとおりです。

ほぼ理論的設計は終り、

現在数社で実証実験中です。

間もなく、何社かでの試行結果が報告されると思います。

１．変更対象要望の内容確認

　　　↓

２．変更規模の把握・算定（テーブル使用）

　　　↓

３．実現難易度算定（テーブル使用）

　　　↓

４．工数原単位を掛けて工数算出

これができるためには

２．のためのテーブルと３．のためのテーブル、

４．の工数原単位が必要です。

そのテーブルのパラメータや工数原単位は、

システムごとに過去データを解析して設定します。

この解析は、かなりの知的作業です。

パラメータや工数原単位の設定が

適切でないと見積り値は使い物になりません。

だからこれまでできなかったのかもしれません。

ご関心ある方は、以下にお問い合わせください。

　　mind-pc@newspt.co.jp