定量データの傾向性
五味弘氏：ということで最初の一歩です。前振りがやっと終わりました。
（スライドを示して）私たちは『ソフトウェア開発分析データ集2022』というものを、9月26日に公開しています。昔の名前は「ソフトウェア開発データ白書」で、知っている人が99パーセントいてくれればうれしいなと思うのですが、その後継が「分析データ集」で、2022年版を9月26日に公開したばかりです。今日はこれを紹介したいと思います。
最初に結論です。2年に1回（「分析データ集」を）出していますが、信頼性も下がった。ここで言う信頼性は、正確にはリリース後のバグの数、バグ密度のことで、リリース後のバグ密度は大きくなった。ということは、一言で言えば、生産性も信頼性も両方とも2年前と比べて下がったことになっています。
生産性が下がったのはだいたい5、6年前でしたが、その時に大きな事件になってしまいました。今まで、生産性と信頼性はどんどん向上していくものだと日本人は信じていました。それが下がって、いろいろなところで取り上げられました。
「生産性はIoTやDXが出てきて、要求変更が多いアジャイル開発が出てきて大変になったから、生産性が落ちるのは仕方がない」というのはありますが、とうとう日本人が誇りに思っていた品質も、今回初めて下がりました。まぁ微妙な下がりなので統計的には有意ではないですが、上がらなかった。向上しませんでした。これがちょっと事件で、またWebメディアでもいろいろ取り上げられてしまいました。
ソフトウェア開発データのプロファイル
（スライドを示して）ということで、分析データ集の紹介をしたいと思います。信頼性が下がった大事件のあとですが、プロファイルを集めています。どういう言語、どういう新規開発が多いかというと、ほとんど改良開発で、Javaが多いということが出ています。
このデータ白書、分析データ集がどういうことを集めているかというと、日本の大手ソフトウェアベンダー、だいたい30社からのデータを集めています。これはもちろん日本の平均ではなくて、どちらかというと大手ソフトウェアベンダーの平均値です。なので、COBOL（Common Business Oriented Language）はいまだに残っています。
リリース後の不具合密度のデータ
そして信頼性、リリース後の不具合密度です。（スライドを示して）この結果で、例えば中央値は0.00で意味がないです。75パーセント地点を見てもらうと、0.077ということで。これはキロステップ、1,000行書いてなので、1万行書いて0.7個、10万行書いて7個出るというぐらいの間隔が、75パーセント地点です。
平均値で見ると0.1です。平均値は悪いやつに引きずられるので、平均値以下であれば安心ということではありません。本来は中央値で見てほしかったんですが、中央値が0なので、75パーセント地点でやっています。平均値でいけば1万行あたりに1個出ています。これは悪いやつに引っ張られるので注意してほしいデータになっています。
こういうデータがあるので、ぜひみなさんに見てもらえればと思います。実はこの「データ白書」または「分析データ集」は、実はユーザー企業さんがよく見ているものなので、SEや営業の方が見積もりする時にこのデータを使って「お前のところは高すぎるぞ」と言われます。
ですので、みなさまの会社でベンチマークする時も「まぁ、ここにある中央値よりはいいな」「平均値よりはいいな」「70パーセント超えてないから、まぁ許容範囲だな」と見てもらえればと思います。
先ほどのは（2016年度から2021年度の）6年分のデータですが、「データ白書」は2005年から出しているので、2005年からやった場合のSLOC信頼値は、中央値が0.010、平均値が0.109となっています。ということは、やはり生産性はどんどん上がっていたので、全部（を比較して）やると、6年間（の中）でもっとも悪い。
落ちたといっても最初の頃はもっと悪かったので、最近はどんどん良くなっている傾向にあって。前年度にするとやはり悪くなり、中央値でも0.1という数字が出るようになっています。
レビュー指摘のデータ
（スライドを示して）ここには、こういうデータが山のように出ています。レビューの時にはどれぐらい指摘すればいいのか。例えば、1,000行あたりどれだけ指摘すればいいのか。これはファンクションポイントでもやっているので、1ファンクションポイントでどれだけ指摘が平均的にあるのか、中央値はどれぐらいなのか、それからドキュメントではシステム仕様書のページ数あたりどれだけ指摘があるのかなど、データが山のようにあるので見てもらえればと思います。
特に品質保証部の人、ここはユーザーさんがあまり見ないので、品質管理部の人が現場の人に「まだレビューが足らない。もっとレビュー指摘があるべきだ」という指摘に使えるものになっています。
テスト検出バグのデータ
（スライドを示して）テスト検出バグです。こちらはインプロセス、開発中のバグですが、結合テスト時、総合テスト中のバグは、これだけ平均（的に）出ています。統合テストの時には（バグが）出たらダメだし、（バグが）あまりにも出なければ、テストそのものが悪いということです。
変数が2つあるので、みなさまの会社ではだいたい「ここからここまでのバグが出ればいい」というふうにやると思います。例えば25パーセント地点と75パーセント地点で四分位（の）表になっているので、その範囲にあれば、世間一般、大手ソフトウェアベンダーとだいたい同じぐらいだと見てもらうのも1つの手です。
みなさんはテストデータなどの計測データを集めて財産、資産にしていると思いますが、そのほうがもちろん絶対にいいです。ただ、もしそういうのがない会社は、こういうのをぜひ参考にしてもらえればなと思います。
SLOC生産性のデータ
（スライドを示して）次に生産性に関しても書いています。グラフで表示していますが、これは予測値の信頼区間です。次に新しくプロジェクトをやった時に、50パーセントの中に入っていれば半分ぐらいは入っていますと。95パーセントは「そこから外れるようではダメですよ」という感じで、世間一般の生産性と見てもらうのがあります。
近似曲線の式が書いてありますが、何乗、累乗のところを見てもらうと、0.56乗になっています。当然ながら規模が大きくなればなるほど生産性は良くなると言われていて、1乗ではなく0.56乗。だいたいルート、平方根ぐらいのものになっています。つまり4倍になれば2倍、生産やお金がかかるというぐらいになっています。
今はこれがだんだん崩れてきているというのが、R2乗、信頼変数を見てもらうと（わかります）。0.55、統計的には悪くて、どんどん外れています。この散布図を見てもらうとわかるように、そんなに固まっていないですよね。これは変数変換もしていなくて、生の数値でやっています。
（スライドを示して）先ほどは全部のやつ、今度は新規と改良を入れた時のものです。
SLOC（Source Lines Of Code）生産性の規模別の具体的な数値が挙げられています。ここに中央値は3.76と出ているので、1人時、1人が1時間かけて3.76行作るという数字になっています。人月計算されているところは、そこから人月に直してもらえればと思います。
（スライドを示して）これも全部のSLOC生産性が書いてあります。
2022年は生産性も信頼性も両方とも下がった
ということで、3本立ての1本（目）のまとめです。先ほど言ったように生産性は5、6年前から落ちていて、品質は（2022年に）初めて落ちてしまいました。全体の傾向性や相場感の具体的な数字はここに書いてあります。無料でダウンロードできるので、（資料を）見てもらえればあります。
ここで、みなさまというか日本全員ですが、品質が落ちた、信頼性が落ちていることに対してどういうメッセージを与えればいいのかということを、IPA内部でも議論しています。
「今DX時代でアジリティ、価値が大事だから、もうリリース後のバグはそんなに気にしなくてもいい」派や、「そんなことはない。品質あって、かつ価値を見つけるんだ」という、やや原理主義の方。両方います。みなさんはいかがでしょうかね。
質疑応答 あえて旧来の指標を計測して分析する意図
ここで1本目が終わるので、質問またはコメントなどないでしょうか？ オンラインから何かコメントや質問は入っていませんか？ 誰も反応しないか（笑）。ここでいるかなと思ったんですけれど、いないか。会場のみなさんはいかがでしょう？ 何か質問とかコメントとかいちゃもんとか、何かありませんか？
あ、（質問が）入っていますね。「『ソフトウェア開発分析データ集2022』で計測されている指標は、アジャイル開発にシフトしていく中であまり意味を持たない指標になっているように感じます。あえて旧来の指標を計測して分析するのには、どのような意図があるのでしょうか？」。
ありがとうございます。この質問はよくくるものなので、最初に「いい質問ですね」と言っています。まず生産性に関してです。生産性は明らかにアジャイル開発では意味がなくなってきていますよね。要求がどんどん変化して、仕様が変化して、作り直しなどがいっぱい入るので、最終結果のコード行数、ファンクションポイントだけでは、それを工数で割った生産性は意味がないんじゃないかなという意見です。
これはイエスだと思っています。だから、分析データ集は信頼性を中心にして分析しています。生産性は実は付録にしてあって、そういう立場にしています。が、実は需要はいっぱいあります。
つまり、今ウォーターフォールで開発している会社がだんだん減ってはきているんですけれど……。「けれど」と言ったのが大事なんですね。ウォーターフォールで管理をされている会社はまだまだあります。
だから、中身はアジャイル開発でやっているけれど、ウォーターフォールで管理しているというちぐはぐな会社があり、（また）もちろんウォーターフォールで開発していてウォーターフォールで管理している会社もあるので、需要はけっこうあるということで付録として残しています。
一方、信頼性に関してですが、リリース後のバグについては開発手法に依存せずに重要なことだと捉えていて、インプロセスじゃなくてリリース後のバグについては、アジャイルであろうが別の開発プロセスであろうが、これからもリリース後のバグ（を測ること）はやっていこうかなと思っています。
DXになって、バグの数よりも品質よりも価値だという時代が出てきつつあるので、それがどんどん進歩すれば残るものは絶対残ると思いますが、リリース後のバグも分析することの意味がだんだん減ってくる気がしています。
けれど、今のところリリース後のバグについては重要事項。命に関わる……いや、そこまでいきませんが、重要事項だと思っています。
質疑応答 到底的な意味が疑問視された時の分析
あ、いっぱい（質問が）来ていますね。「（ソフトウェア）開発ではスキルに大きな変動要素があり、組織で持っているデータを標本として採用しようと（すると）かなり狭くなり、統計的な意味があるのか疑問を持つ時があります。そういう時はどのように分析なさいますか？」ということです。
確かに、この分析データ集もいわゆるプロファイル情報をいっぱい集めていて、どういうプロジェクトマネージャーか、経験豊かな人がやっているかどうか、新規の分野なのかどうかを結局、400項目ぐらい集めています。
それを深く分析していくと、いわゆる信頼区間というか、統計でp値というものがありますよね。あれが5パーセントを超えるどころじゃなくて、10パーセントを超えてしまうということがあります。
2022年版ではやっていませんが、前に1回やったものでは10パーセント有意という意味において統計的に分析できるところまでやって、「統計的に意味があった」ということを論文に書いています。例えば、生産性に与えるものはどれか、信頼性に与える要因はどれかということを紹介しているので、見てもらえればと思います。
そういう意味では、結局データ分析集は統計とは切り離せないので、サンプル集にならないように、統計的に意味のあるように、数を集めてどこまで細かくするかというバランスをとって届けたいと思っています。そういう意味では、これはだんだん難しくなってくるかなと思います。
だから個社、1社の会社でやっていくと、専業メーカーであれば同じようなデータが集まって大丈夫かもしれませんが、そうでないとなかなか統計的な意味を持つことができず、標本というかたちになって、統計的な手法はだんだん使いにくくはなるかなと思います。また、最初の質問でもあったように、品質、リリース後のバグも意味を持たなくなれば、別のもの、価値をとにかく見える化するという話になってくるかなと思います。実はこれは後段に書いてあることになります。
（次回につづく）
