見える開発現場
のためのメトリクス
で始めるソフトウェア開発
〜I
O
T
と
AI時代
を生き抜く
定量データ
の
活用のコツ
と
その掟〜
五味 弘 IPA/JEITA/OKI 2017/11/17 ver 1.0 組込みソフトウェアデータ白書2017 2017年11月15日発行 ・組込み分野のプロジェクトデータ416件 ・エンタープライズ系データ白書と同様の構成 1● 五味 弘（ごみ ひろし） (2017.10) 所属：沖電気工業株式会社 シニアスペシャリスト/エバンジェリスト 仕事：言語処理系や人工知能マシン，金融系システム開発，ソフトウェア開発支援や教育に従事 講師：三重大学，名古屋商科大学，群馬高専で非常勤講師（ソフトウェア工学，ソフト開発PBL他） 三重大学リサーチフェロー，高度ポリテクセンターや日本テクノセンターなどで講師 外部：電子情報技術産業協会(JEITA) ソフトウェア基盤専門委員会委員長，情報処理学会 シニア会員， IPA/SEC製品・制御システム高信頼化部会など3件の委員，BOSS-COM，SESSAME 他 受賞：情報処理学会研究賞，LODChallenge2013プロジェクト賞など 著書：はじめてのLisp関数型プログラミング(技術評論社,2016)， 共著：まるわかりAI開発最前線2018（日経BP社, 2017/10），IoTセキュリティ(日経BP社,2016)， プログラミング言語論(コロナ社,2008)，品質予測のススメ(オーム社,2008)， 組込みJavaプログラミング入門 (SRC,2008)，Jakartaプロジェクト徹底攻略2(技術評論社,2004)など9冊 雑誌：ゼロから始める人工知能の作り方(日経コンピュータ連載)，人工知能時代のLispのススメ（Software Design 連
載)，汎用機のLISP 大文字でタイプライタで会話していたあのころ(Software Design)，今こそ Lisp 入門 (Software Design)，プログラミング言語を作る(日経ソフトウェア)，新聞コラム連載（電経新聞）など Web：IoT時代の組み込み系ソフトウェア品質(TechFactory), ゼロから挑戦！IoT開発(ITpro)，IoTとAI、ビッグデータ 時代のソフトウェアテスト（TechFactory)，人工知能のつくりかた(ITpro)，現場で使うためのオールペア法、 直交法の基本(@IT)，プロジェクトを成功させるモデリングの極意」(MONOist)など 学位：博士（工学） 個人ページ http://gomi.info/ リサーチマップ http://researchmap.jp/gomihiroshi
講師紹介
2内容
1. ソフトウェア開発と定量データで見える開発現場
・定量データとメトリクスとソフトウェア開発 ・ソフトウェア開発の定量データ ・閑話：組込み業界でささやかれている噂話 FAQ ・定量データとメトリクスの活用こそIOTやAI時代の生き抜く道2. 組込み系ソフトウェア業界での定量データ
・組込み系ソフトウェアの定量データの紹介 ・・組込み系ソフトウェアの実態 ・・組込み系ソフトウェアの生産性 ・・組込み系ソフトウェアの信頼性 ・本当はおもしろい組込みソフトウェアのデータ ・噂話：定量データの組込み業界での評判 ・閑話：統計で騙されない3. I
OTとAI時代の定量データの活用とその掟
・定量データをソフトウェア開発に役立てる ・・定量データを使いこなすコツ ・・定量データを使うときの掟 ・閑話：本当は怖いデータ白書の掟 ・プロジェクト管理のお供に、そしてIOTとAI開発の羅針盤に 31. ソフトウェア開発と定量データで見える開発現場
導入編：
ソフトウェア開発に定量データを導入する
⇒
見える開発現場に
・定量データとメトリクスとソフトウェア開発
・ソフトウェア開発の定量データ
・閑話：組込み業界でささやかれている噂話 FAQ
4 2006年にエンタープライズ系のソフトウェア開発データ白書を題材に講演 「ソフトウェア開発データ白書2005 正しい読み方と賢い使い方」 セミナー（2006年2月開催） なんと10年以上前から定量データの重要性がソフト開発で認識されていた？ これに対して、組込み系ソフトウェア開発は・・・遅れている？ エンタープライズ系のデータ白書の成果と反省を元に、組込み系に定量データを 組込み系、 大丈夫なの？定量データ
と
メトリクス
と
ソフトウェア開発
・定量データ
Q
UANTITATIVED
ATA数値化されたデータ
・メトリクス
M
ETRICS計測基準
メトリクスは定量データを基に基準を定義
定量データがないとメトリクスは始まらない
定量データ
メトリクス
ソフトウェア開発
定量データに基づくソフトウェア開発
この
光
と
影
を紹介
定量データとメトリクスをプロジェクト運営における
各種の運営・判断基準にしたソフトウェア開発
5見える開発現場
ソフトウェア開発の定量データのいろいろ
生産性
信頼性
コスト
規模
工数
LOC
FP
ページ数規模
欠陥
現象数
原因数
エンタープライズ系のソフトウェア開発 データ白書で収集しているデータの種類 は400種類を越える 定量データには大量のデータがある 千差万別、多種多様、魑魅魍魎測定にはコストが掛かる
工程別
言語別
新旧別
外部委託
具体的な 計測データ 層別のためのプロファイルデータ 知りたいもの 計測すべきもの 6要員経験
実時間性
自然環境
影
お金、足 りるの？閑話
・・・ 実は開発現場の本音？
組込み業界でささやかれている
定量データにまつわる噂話 (FAQ)
• 定量データそのもの
• データ収集・分析活動
• エンタープライズ系と比較
7影
噂話って本音 が多いわよね いや、あくま でも噂だから定量データそのもの
に関して
組込みソフトウェア界隈でよく聞かれる言葉
噂1.
「うちは特殊だから」「領域が違うから」
データ白書に掲載されているデータとその分析は
→「そのデータは使えない」
「参考程度にしかできない」
「うちには当てはまらない」
8 特殊ってスペシャ ルってこと？ いや、そんな にいいもん じゃないしデータ収集・分析活動
に関して
組込みソフトウェア界隈でよく聞かれる言葉
噂2.
「やらなくてはいけないけど」「参考になるけど」
→「コスト的、文化的にできない」
噂3.
「強制的にやらされているけど」
→「役に立っていない」「儀式になっている」
噂4.
「どんなデータを収集し」「どう分析するのか」
「どう役立てるのか」
→「わからない」
9エンタープライズ系と比較
して
組込みソフトウェア界隈でよく聞かれる言葉
噂5.
「あちらは典型的に作れる」
「あちらはフレームワークがある」
→「こちらは手作り」「モノによって全然違う」
噂6.
「こちらは職人が作る」「個人依存が大きい」
→「定量データは役に立たない」「ばらつく」
「定性データの方が役立つ」
噂7.
「ドメインで全然違う」
→「組込み全体で括るのが問題」
10噂を信じてはいけない話
噂を信じて定量データを活用しないのは間違っている
噂1. うちは特殊だから使えない 共通のところ、使えるところがきっとあるはず、そこだけ使う 噂2. コスト高でやれない 小さく少なく安く始める、いきなり全部入りにしない 噂3. 強制されているけど役に立っていない 権利として使えるところを使う、使う権利がある 噂4. どんなデータを集めるのかわからない 小さく始めて必要なものだけ、将来に備えない（ここ大事） 噂5. あちらは典型的に作れるから こちらも共通部がある、抽象化して見つける、いつまでも手作業では駄目 噂6. 職人が作るから個人依存が大きい 大規模になれば統計的になる、定量データが役立つ、積み重ねれば使える 噂7. ドメインで違う ドメイン別で集めて分析する、近いドメインのデータも役立つ 11光
これって、 言い訳？閑話休題 – 本題に戻って
定量データとメトリクスの活用こそ
I
O
TやAI時代の生き抜く道
• 動作が説明できないブラックボックスな人工知能
• つながる I
O
T はビッグデータとともにいつも変化
• こんな時代を、定量データの活用で生き抜く
• メトリクスと定量データは混沌の中の唯一の道標
AI IoT Metrics 12• 使える武器は、定量データによる統計的判断
光
• もちろん、経験と勘も
次からはいよいよ組込み開発のデータを見ていきます！13
2. 組込み系ソフトウェア業界での定量データ
データ編：
主要な定量データを見ていく
・組込み系ソフトウェアの定量データの紹介
・・組込み系ソフトウェアの
実態
・・組込み系ソフトウェアの
生産性
・・組込み系ソフトウェアの
信頼性
・本当はおもしろい組込みソフトウェアのデータ
・定量データの組込み業界での評判
・閑話：統計で騙されない
14 やっと、データが 出てくるのね もったいぶるのは 嫌われるわよ組込みソフトウェアの実態（工程別工期の比率）
改良開発のときの工程別工期
組込み系データ白書2017 p.79 図表6.4-2 参考：エンタープライズ系 (ソフトウェアデータ白書2016-2017 p.187)
設計：製造：試験 = 2:1:2
設計：製造：試験 = 3:2:3
15 エンタープライズ系と比較して設計と試験工期が長い
(参考) 合計工期に対する比率 アーキテクチャ設計 23% 詳細設計 18% 実装・単体テスト 19% 結合テスト 20% 総合テスト 20% 全体工期に対する比率 基本設計 19% 詳細設計 17% 製作 25% 結合テスト 18% 総合テスト 16% 全体工期に対する比率 アーキテクチャ設計 41% 詳細設計 33% 実装・単体テスト 34% 結合テスト 36% 総合テスト 36% 合計 180% 注意：そもそもウォーターフォールで開発している のか？組込み系はエンタープライズと比較してア ジャイル率が高い（データ白書を見ればわかる！） それに上左図の180%からわかるように工程の重な りが大きい え？組込みソフトウェアの実態（工程別工数の比率）
設計:製造:試験=35:25:40 = 7:5:8
設計：製造：試験 = 1:1:1
伝説では設計：製造：試験 = 3:4:3 16設計と試験工数が大きい
アーキテクチャ設計 19% 詳細設計 16% 実装・単体テスト 24% 結合テスト 22% 総合テスト 18% 基本設計 15% 詳細設計 16% 製作 31% 結合テスト 19% 総合テスト 14% 改良開発のときの工程別工数 (組込み系データ白書2017 p.80 図表6.4-4)
参考：エンタープライズ系 (ソフトウェアデータ白書2016-2017 p.191)
この比率っ て覚えられ ないわよ(参考) 2015年版のときの
組込みソフトウェアの実態（工期や工数）
改良開発のときの工程別工期
(何故か中央値) アーキテクチャ設計 23%、詳細設計 16%、実装・単体テスト 17%、結合テ スト 19%、総合テスト 21% 組込み系データ白書2015 p.127 改良開発のときの工程別工数
(何故か中央値) アーキテクチャ設計 20%、詳細設計 13%、実装・単体テスト 26%、結合テ スト 22%、総合テスト 15% 組込み系データ白書2015 p.128設計：製造：試験=3:3:4
設計：製造：試験=2:1:2
172015年より設計工数の比率が増えた
2015年と変動なし
ふーん組込みソフトウェアの実態（テストケース密度）
改良開発のときの規模当たりのテストケース数(C/C++)
組込み系データ白書2017 p.108 図表8.3-3
結合テスト
135
件/KSLOC
総合テスト
71
件/KSLOC
（参考）エンタープライズ系
ソフトウェアデータ白書2016-2017 p.214 結合テスト
58
件/KSLOC
総合テスト
16
件/KSLOC
18エンタープライズ系と比較して
テストケース数は多い
組込み系って心配 性なのかしら ページと図表番号の訂正(参考) 2015年版のときの
組込みソフトウェアの実態（テストケース密度）
改良開発のときのテストケース数(C/C++)
結合テスト
156
件/KSLOC
総合テスト
83
件/KSLOC
組込み系データ白書2015 p.130 192015年よりは少なくなった
（有意な差ではないかも） ではないかもって、 ヘタレなの？組込みソフトウェアの生産性
改良開発のときの生産性 (SLOC/人時)
組込み系データ白書2017 p.85 図表7.2-4 1.86
(C)
(
298
SLOC/人月)
1.93
(C++)
(
309
SLOC/人月)
参考：エンタープライズ系
3.5
(C, エンタープライズ系)
(560 SLOC/人月) 参考:エンタープライズ系データ白書2014 p.347 参考:エンタープライズ系データ白書2016 では未掲載 （Java 新規開発のときは 約1KSLOC/人月） 20エンタープライズ系と比較して生産性は悪い
(参考) データ白書2015のときの
組込みソフトウェアの生産性
改良開発のときの生産性
(SLOC/人時)
1.32
(C)
(211 SLOC/人月) 3.76
(C++)
(602 SLOC/人月) 組込み系データ白書2015 p.139 21C++の生産性が変動
ふーん組込みソフトウェアの信頼性
改良開発のときの総合テスト検出バグ密度 (件/KSLOC)
組込み系データ白書2017 p.101 図表8.2-16 0.51
(C)
0.08
(C++)
参考：エンタープライズ系
0.152 (C, エンタープライズ系2016年)
参考:エンタープライズ系データ白書2016 p.214 0.315 (C, エンタープライズ系2014年)
参考:エンタープライズ系データ白書2014 p.248 22エンタープライズ系と比較して
バグ検出が高い
こちらも変動が大きいのが気になる ページと図表番号の訂正(参考) データ白書2015のときの
組込みソフトウェアの信頼性
改良開発のときの総合テスト検出バグ密度 (件/KSLOC)
0.44
(C)
0.09
(C++)
組込み系データ白書2015 p.121 232015年より多くのバグを検出
しかし有意な差ではない
かも ではないかもって、 ヘタレなの？本当はおもしろい組込みソフトウェアのデータ
リアルタイム性（時間制約）で生産性は変わるのか？
組込みデータ白書 p.133 図表10.2-16 にその答えが！！ 自然環境からの影響度合い
組込みデータ白書 p.143 図表10.3-14 ユーザの多様性
組込みデータ白書 p.153 図表10.4-14 法規制
組込みデータ白書 p.163 図表10.5-14 他にM2Mの有無(p.177)、ネットワークの有無(p.187)、稼働状況(非 停止／オンデマンド)(p.197)、オンライン保守の有無(p.207)、障害リ スク別(社会的影響を4段階で区分)(p.214) 24生産性に影響を与えそうな要因
ちなみにエンタープライズ系では対 象の業種で生産性に大きな差が！！ なにこれ？ ステマなの？ ページの訂正噂話：組込み業界での評判
収集データ
こんなに集めているとコストが掛かる
過去のデータがなく、その延長上で収集
生産性
炎上プロジェクトを除いたデータとしても
良すぎるのでは？
いいプロジェクトのデータしか集めていないのでは？
見積もりのときにこれが基準となるのはおかしい
信頼性
こんなものだろう
個々のプロダクトやプロジェクトによって桁違いになる
統計的に扱うのではなく、リスク管理として使う 25影
ふーん、 そうかもね閑話：統計で騙されない
結局は収集した定量データを統計的に分析している
プロダクトやプロジェクトの各種の相場観を得て
該当するプロダクトやプロジェクトの行動を予測する
この活動の中心にある「統計」
だから統計は重要！でも・・・
統計で騙されない
統計で騙す
26影
光
統計って、 詐欺なの？ いや、統計は 科学だよ。信 じて。（まずは）データ白書FAQ – 統計編
データ白書の中央値と平均値は使い分けは？代表値は？
データの検定はどうすればいいの？偶然か必然か？
正規分布しているの？正規分布を仮定していないか？
対数グラフにするのはなぜ？見やすくなるのだけれども
層別に分析しているけれど、他の関係が影響しているの
では？例.ユーザーの多様性と規模
背景因子の検定は？
統計数値の一人歩きは大丈夫なの？
グラフより、生の数値が大事だよね？
統計的に色々な問題が・・・
統計に騙されないように・・・
27 統計って、 面倒そうデータ白書FAQ - 統計編 (解答) これが
コツ
！
データ白書の中央値と平均値は使い分け
対称分布していないときは中央値の方が実感に合う 例．平均貯蓄額、生産性、信頼性 データの検定はどうすればいいの？
検定をして有意な差があるときは、その理由を探る 正規分布しているの？
多くのデータが集まっても多くの場合、正規分布していない しかし正規分布を仮定する方が話が進めやすい 対数グラフにするのはなぜ？
見やすくするため、両対数グラフや片対数グラフも使い分ける 層別に分析しているけれど、他の関係が影響しているのでは？
他の背景因子がある、独立でない 統計数値の一人歩きは大丈夫なの？
確実に一人歩きするので注意が必要 グラフより、生の数値が大事だよね？
原理的にはそうであるが、現実的にはグラフの方が使える 28 これって、 コツなの？ 言い訳なの？統計で騙されない・統計で騙す これが
コツ
！
統計は過去の大量のデータを分析したもの
未来の技術変動は組み込まれていない
しかしソフトウェア開発は漸近的発展が多いので過去のデータは役立つ 個別のプロジェクトの未来を予想するものではない
個別のプロジェクトは作為的に運営され、無作為な運営は不可能 しかし現在のプロジェクトの傾向性は知れる、対策が打てる 統計は隠れた関係（背景因子）を炙り出せない
無関係であるものに相関があるときは、隠れた関係がある
AIは生産性が悪い ⇒ AI にまつわる何かと生産性が関係している 例. 戦時中の軍人よりもニューヨーク市民の方が死亡率が高い ⇒ 年齢 29 使えねぇー パシリにする わよ閑話休題： 本題に戻って
相場観を知っていると得する
例えば生産性の相場を知っていると
プロジェクトが危険なのか安全なのか、見積もりが妥当なのかチャレンジブ ルなのかを見透かすことができる （参考）例えばスマホの相場を知っていると
「セール」とともに売り出されていたスマホが本当に安いのか、ただ単にそ のスマホを売っているだけなのかが瞬時に分かる データ白書で相場観は養われるのか？
所詮は他人のデータ。自分のデータではない。⇒ 前の閑話を思い出せ！ データ白書のデータを自分の持つデータで補正する ⇒ 相場観を養う 30 次はいよいよ、この定量データをどのように活用していくのか 相場観・・・ いい言葉かも31
