プログラマの思索

初中級プロマネがIPAデータ白書の統計情報をどんな観点で活用できるか、説明した利用事例がとても良かった。
理解できた内容をラフなメモ。

【参考】
初中級プロマネのための　現場で活かせ！統計情報１

初中級プロマネのための　現場で活かせ！統計情報２

「ソフトウェア開発分析データ集2020」の発行：IPA 独立行政法人 情報処理推進機構

「ソフトウェア開発データ白書」のダウンロード：IPA 独立行政法人 情報処理推進機構

初中級プロマネのための現場で活かせ！統計情報 　2019年4月19日| CITP Community

CITPアニュアルレポート2018を公開しました | CITP Community

【0】「ソフトウェア開発分析データ集2020」をIPAデータ白書と呼ぶことにする。

【1】IPAのソフトウェア開発データ白書を使いたい動機は2つある。

1つ目は、プロマネとしてシステムの企画書や提案書を書いている時に、見積もりの妥当性を説明するために、日本の他社事例の数値を元に遜色ないことを理由として、見積もり工数や金額は妥当です、とロジカルに説明したいこと。
もう一つは、プロマネとしてリリース判定会議で、システムの開発やテストの結果が、日本の他社の成功した事例と遜色ないことを理由として、品質は妥当です、とロジカルに説明したいこと。

プロマネは、経営層が考えた戦略を受けてその内容をシステムとして実現する時に、自分が考えた企画内容の妥当性を説明したい。
その時に、経営層から聞かれるのは、投資効果が見込める妥当性はあるのか、初期投資の金額の妥当性はあるのか、という点だ。
この根拠を作るために、実際に業務システムの無駄な問題点を工数や金額で事前調査したり、削減できるコストがこれだけあるとか、売上や利益がこれだけ伸びるとか、色々話を膨らませる。

特に難しいのは、初期投資としての見積金額が本当にこれで妥当なのか、という点だ。
まだ実際に作ってもないし、あいまいな調査を元に機能一覧を洗い出して、その積み上げで工数を算出し、人月単価を元に見積金額を弾くわけだが、それを各工程に分けて積み上げて、本当に正しいのか、と言われると、正直難しい。
実際は、色んな前提条件をたくさん置いて、こうなります、という説明しかできない。

そんな時に、日本のSIで成功した事例では、こういうデータがあるので、工数や金額に妥当性があると言えれば、自分たちの会社も日本のSIで普通のレベルだと仮定できれば、こんな数値になるのは妥当でしょう、と言える。
そういうロジックに持ち込みたい。

つまり、プロマネの勘や度胸のような直感に頼らず、利害関係者にロジカルに説明するための根拠づくりに、IPAデータ白書を使いたいのだ。

【2】IPAデータ白書には、日本のトップレベルのSIが収集したソフトウェア開発における数多くの統計データが掲載されている。
その統計データが膨大であるために、どのように使えばよいか分かりにくい。
僕も正直悩んでいた。

しかし、初中級プロマネのための　現場で活かせ！統計情報１を読むと、初級者・中級者のプロマネはIPAデータ白書をこういう風に使うと役立つよ、という指針を書いてくれているのでとても役立つ。

IPAデータ白書の主な使い道は、見積り、生産性、品質の3つの観点で使うと良いだろう。

【3】企画提案の段階では、要件定義工程比率や工程別の工数比率、工程別の工期の比率が役立つ。

たとえば、要件定義工程は準委任、設計・開発・テストは請負契約でやる場合、トータルの工数や工期を提案段階である程度見積る。
その時に、要件定義フェーズはこれくらいの工数や工期が必要である根拠として、IPAデータ白書の数値を用いて算出するとよい。
なぜならば、経験上、要件定義フェーズをケチって実施してしまい、実際の開発フェーズに入ると要件がどんどん覆されて遅滞してしまい、最終的にプロジェクトが赤字になるか、失敗プロジェクトで終わってしまうという失敗事例がすごく多いからだ。
やはり、要件定義工程にある程度の工数や工期を割り当てて、メンバーも労力も割いた方が次の開発フェーズはスムーズに進みやすい。

あるいは、設計・開発・テストの各工程の工数別割合をIPAデータ白書の数値を用いて算出し、プロジェクトが成功するならこれくらいの比率の工数が必要だ、という根拠に使う。
なぜならば、開発工程の見積は実際にプログラマが見積もればある程度明確になりやすいので、その工数を元に設計やテスト工程の工数を算出できるからだ。
失敗プロジェクトでは、設計工程は十分に工数を取るが、テスト工程の工数をケチって、実際のプロジェクトで破綻する時も多いからだ。

【4】また、設計や開発工程の見積もりには、生産性の指標が役立つ。

たとえば、SLOC規模あたり設計書ページ数を使えば、プログラム規模を元に設計書ページ数を見積もれるので、設計書の規模感や設計書作成の工数の根拠を算出できる。
あるいは、SLOC 規模別 SLOC 生産性 や SLOC 規模と工数の関係を使えば、プログラム規模を元に各工程の工数をある程度見積もることができる。

つまり、設計、開発、テスト工程の工数の見積の精度を向上させることもできる。

【5】設計・開発工程がほぼ終わり、テスト工程に入る時には、レビュー指摘件数、SLOC 規模 テストケース数、SLOC 規模 検出バグ数を使えば、品質の妥当性をチェックすることに使える。

たとえば、設計工程のレビューの指摘件数を収集できれば、SLOC 規模/工数あたり/ページあたりの数値がIPAデータ白書にあるので、その基準値を元にレビュー指摘件数が妥当であるか、管理図を使って検査できる。
外れ値が出るならば、レビュープロセスに原因があるのか、設計書という成果物が悪いのか、さらに原因分析していく。

あるいは、開発が終わればプログラム行数は簡単に測定できるので、開発規模に応じたテスト工程ごとのテストケース数や検出バグ数を予測することができる。
IPAデータ白書の数値を元に、開発規模から妥当なテストケース数はこれくらいと分かれば、そのケース数から外れ値が出ていないかチェックすればいい。

そして、実際にテストしてみて、バグ数がIPAデータ白書の基準値よりも多く出るならば、品質が悪い可能性があるのでさらに原因分析していく。

つまり、設計・テスト工程の品質の妥当性にIPAデータ白書の数値は使えるはず。

ソフトウェア開発データ白書と定量データの活用方法を参考にすれば、ゾーン分析やトレンド分析、信頼度成長曲線など数多くの品質管理技法を適用することもできるだろう。

「ソフトウェア開発データ白書2018-2019」のご紹介～プロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果～も参考になる。

【6】IPAデータ白書の統計情報はたしかに、見積り、生産性、品質の観点で使えるし、それなりに役立つ。
しかし、いくつかの留意点はある。

1つ目は、WF型開発を前提としたメトリクスであること。
実際に収集した事例の数値では、ほとんどがWF型開発であり、アジャイル開発を前提としたメトリクスではない。

2つ目は、開発言語やシステムの種類、開発フレームワークをすべて混ぜ込んで、グロスで集計した数値であること。
以前は、JavaやCobolなど数多くの言語で分類されていたが、最近は言語の区別もなく、せいぜい、新規開発・改良開発・再構築の開発種別の違いだけしかない。
つまり、色んなシステムのデータを一つの数値でまとめているので、本当に精緻なデータなのか、という疑問はある。

3つ目は、IPAデータ白書に提出した日本の各SIの統計データは、工程の定義や開発規模、テストケース数、バグ数などの定義が各社でバラバラである可能性が大きいことだ。
この点はIPAのFAQサイトにも記載されていて、その点を考慮して色々精査されているみたい。

「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答：IPA 独立行政法人 情報処理推進機構

4つ目は、この数値を鵜呑みにして使わないように、IPA自身も注意喚起を記載している点だ。
あくまでも参考データであり、自分のソフトウェア企業がこの数値に当てはまるとは限らない。

とは言え、IPAデータ白書は10年以上の歴史があり、その統計データの推移を見ると、そんなに大きく変わっているわけではないようだ。
日本でDXが叫ばれていても、日本のSIではやはりWF型開発が主流であり、それなりの品質データや見積データを収集して蓄積しているみたいだ。

個人的には、日本で少しずつ浸透しつつあるアジャイル開発の統計データが収集されて、実際の統計データとして採用されると参考にしたいと思う。