2011年11月29日火曜日

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

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

システム開発の場合の見積りは、
どれだけのものを作るのかを確認・計測し
それに原単位を掛けて行います。
製造業の製品の見積りと同じ方法です。

ところが、今やシステム開発の数倍あるという
ソフトウェア保守の見積りは
何をしなければならないかを検討すると、
次はいきなりそのためにしなければならない作業工数を
見積るのです。

するべきことと作業の間の原単位がありませんから、
なぜその工数が必要かが第3者には分かりません。

例えて言えば、家の改修の際に
台所の床の張り替え、調理台の入れ替え、窓のサッシ化
トイレのうウォッシュレット化にいくらと
見積りが出るのが依頼者の納得がいく
一般的な見積り方法です。

それに対して、今の保守の見積りは、
全体で部品代がいくら、大工の日当がいくら、
工事代がいくら、とくるようなものです。

保守の依頼者は、
見積り者の言うことを信ずるしかないのです。
全体をするかやめるかの判断しかできません。
こんな理不尽なことはないでしょう?

そこで、保守の場合にも、
こういう窓のサッシ化ならいくら、
現状がこういう場合の調理台の入れ替えならいくら、
と見積りができるようにする、
というのが新方式です。

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

コロンブスの卵的かもしれません。
その見積り法の流れは以下のとおりです。

ほぼ理論的設計は終り、
現在数社で実証実験中です。
間もなく、何社かでの試行結果が報告されると思います。

1.変更対象要望の内容確認
   ↓
2.変更規模の把握・算定(テーブル使用)
   ↓
3.実現難易度算定(テーブル使用)
   ↓
4.工数原単位を掛けて工数算出

これができるためには
2.のためのテーブルと3.のためのテーブル、
4.の工数原単位が必要です。

そのテーブルのパラメータや工数原単位は、
システムごとに過去データを解析して設定します。

この解析は、かなりの知的作業です。
パラメータや工数原単位の設定が
適切でないと見積り値は使い物になりません。
だからこれまでできなかったのかもしれません。

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

  mind-pc@newspt.co.jp

2 件のコメント:

匿名 さんのコメント...

状況が分からない中での質問ですが、

元の開発工数がどのくらいかかったソフトウェアなのかという
ことは保守工数推定に関係ないのでしょうか。

もっといえば、元のソフトウェアの論理明瞭性(出来の良し悪
し)は関係ないでしょうか。

匿名 さんのコメント...

ご質問ありがとうございます。
2問とも本質を突いたたいへん良いご質問です。

1.このモデルでは、元の開発工数がどのくらいかかったものかは、直接には関係しません。保守対象がどのくらいの規模のものかという点は「母体規模」(FP値等で把握)として関係します。
 ですが、このモデルでは特定のシステムごとに見積りパラメータを設定しますので、そのシステム内の各種案件に対しては母体規模は一定値です。 そのため、ご紹介記事では省略しています。
 他のシステムと生産性を比較する際には母体規模は関係してまいります(評価するようになっています)

2.仰るとおり、元のソフトウェアの論理明瞭性は、大いに関係いたします。その点は「実現難易度算定」の中で、重要な評価要素として評価するようになっています。

                    上野 則男