Go to Qiita Advent Calendar 2024 Top
LoginSignup
29
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

LITALICOAdvent Calendar 2023

Day 2
@s12i(Hiroyuki Suzuki)in株式会社LITALICO

公開情報を使って見積を客観視してみよう

Last updated at Posted at 2023-12-01

この記事はLITALICO Engineers Advent Calendar 2023 カレンダー2の2日目の記事です。

2023年3月に入社したQAエンジニアの鈴木です。
入社前に読んでいたアドカレ記事を書くことになりブルブル震えております。

はじめに

ソフトウェア開発プロジェクトにおける大きな関心事として「どのくらいの期間がかかりそうなのか、またその見積は妥当なのか」といったことがあげられると思います。
この記事ではソフトウェア開発分析データ集、ソフトウェアメトリックス調査といった公開されている統計情報をもとに工程別の工数や工期見積の妥当性を確かめることで不安を（少し）減らす取り組みについて書いてみたいと思います。

ソフトウェア開発分析データ集

IPA（情報処理推進機構）が発行している、エンタプライズ分野のソフトウェア開発データを収集・分析してまとめたデータ集です。
https://www.ipa.go.jp/digital/chousa/metrics/hjuojm000000c6it-att/000102171.pdf
多くの情報が載っていますが、ここでは「A3.3 工期と工数」にある工程別工数比率を使ってみます。
プロジェクトの種別として新規開発、改良開発、再開発に分かれているので適したものを選びます。
以下は改良開発の工程別工数比率です。

image.png
引用：ソフトウェア開発分析データ集2022 / 独立行政法人情報処理推進機構 (IPA) 社会基盤センター
p169「A3.3.9 工程別工数：改良開発」

なお、p193「A5. データ項目の定義」において各工程とSLCPとの対応関係について記載があります。
たとえば製作工程はSLCPプロセス/アクティビティの「ソフトウェアコード作成及びテスト」に対応すると書かれています。

ソフトウェアメトリックス調査

JUAS（日本情報システム・ユーザー協会）が発行している、ユーザー企業から開発・保守・運用プロジェクトの実態を収集した調査報告書です。
https://juas.or.jp/cms/media/2020/05/20swm_pr.pdf
こちらも多くの情報が載っていますが、ここでは全体工期と全体工数の関係で説明されている「全体工期は全体工数の3乗根（立方根）の2.70倍」1という計算式を使います。

具体的な使いどころ

それでは、改良開発プロジェクトにおいて製作（PG/UT）工程の積上見積を行ったところ、100人日（5人月）だった場合を例にしてみます。

工程全体の工数はどのくらいになりそうなのか

工程別工数を見ると製作工程の比率の中央値2は0.297となっているため、以下の式で全体工数を求めることができます。
100/0.297 = 336.70 人日（16.84人月）
全体工数がわかれば各工程の比率と全体工数を掛けることで工程別の工数も計算することができます。

工程 比率 人日 人月
基本設計 0.153 53.95 2.58
詳細設計 0.152 52.96 2.56
製作 0.297 100.00 5.00
結合テスト 0.200 68.75 3.37
総合テスト 0.142 53.62 2.39
合計 336.70 16.84

工数に対して適切な工期はどのくらいか

次に全体工数が16.84人月の開発プロジェクトにどのくらいの期間がかかりそうか見てみます。
「全体工期は全体工数の3乗根（立方根）の2.70倍」にあてはめると以下の式になります。
16.84^(1/3)*2.70 = 6.92 ヶ月
16.84人月の開発を行うには標準的には6.92ヶ月ほどかかるということがわかります。

工期はどのくらい縮められそうか

標準的な工期は6.92ヶ月とわかったうえで、工期はどのくらい縮められる余地があるでしょうか。
2008年の記事ですが、標準工期よりも30%以上短いとデスマーチの危険が高まるという指摘があります。
https://www.itmedia.co.jp/im/articles/0806/26/news125.html

短縮率を25%と置いた場合、以下の式から少なくとも5.19ヶ月ほどはかかりそうということがわかります。
6.92*0.75 = 5.19 ヶ月
条件が整っていたり工夫をしたりしてもこのくらいはかかるだろうという工期です。
リリース日の都合などでこれよりも短い工期で作業しなければいけない場合はスコープの調整を検討することになるでしょう。

利用にあたって

ソフトウェア開発分析データ集の場合、p191「A4.4.3 データの危うい使い方の例」、p192「A4.5 本書利用にあたっての注意事項」に危うい使い方とその対処法、注意事項が書かれています。
ソフトウェアメトリックス調査の場合、2014年のものですがソフトウェアメトリックス 要点ハンドブックに使い方や注意点が書かれています。
https://www.juas.or.jp/cms/media/2017/02/swm_hb445042_Ver3.2.2.pdf
また、経験上ですが標準工期を求める際は総工数が5人月以上くらいからだと参考にしやすいと感じています。
たとえば総工数を1人月とした場合、標準工期は2.7ヶ月となりますが実態とのブレがあることが多いのではと思います。

式にあてはめて出した結果を鵜吞みにせず、チームの熟練度や品質要求といった目の前のプロジェクトの特性とあわせて数字を利用するよう気をつけています。

おわりに

この記事では公開情報を使った簡易的なベンチマーキングについて紹介しました。
決してこのやり方で見積カンペキというものではないですが、客観的な目安があることで見積の妥当性評価の助けになるのではないでしょうか。

おわりになりますが、貴重なデータを提供いただいている各プロジェクト関係者の方々と集計・分析結果を公開いただいているIPA、JUASの方々にお礼を申し上げたいと思います、ありがとうございます。

組織の内外を問わず上手くいっている、いいなと思えるやり方をインプットし、納得感のある品質づくりに貢献していきたいと思っています。

参考

  1. 直近3年間（2018-2020）だけのデータでは、3乗根（立方根）の3.03倍だそうです。 ↩

  2. ソフトウェア開発における定量的管理の主な手法において、「代表値としては、中央値を採用」との記載があり、特別なこだわりがない場合は中央値を使っています。 ↩

29
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
29
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?