見える開発現場のための

メトリクスで始めるソフトウェア開発〜IOTと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. IOTとAI時代の定量データの活用とその掟・定量データをソフトウェア開発に役立てる・・定量データを使いこなすコツ・・定量データを使うときの掟・閑話：本当は怖いデータ白書の掟・プロジェクト管理のお供に、そしてIOTとAI開発の羅針盤に

3

1. ソフトウェア開発と定量データで見える開発現場

導入編：ソフトウェア開発に定量データを導入する⇒ 見える開発現場に

・定量データとメトリクスとソフトウェア開発・ソフトウェア開発の定量データ・閑話：組込み業界でささやかれている噂話 FAQ

4

2006年にエンタープライズ系のソフトウェア開発データ白書を題材に講演

「ソフトウェア開発データ白書2005 正しい読み方と賢い使い方」セミナー（2006年2月開催）

なんと10年以上前から定量データの重要性がソフト開発で認識されていた？これに対して、組込み系ソフトウェア開発は・・・遅れている？

エンタープライズ系のデータ白書の成果と反省を元に、組込み系に定量データを

組込み系、大丈夫なの？

定量データとメトリクスとソフトウェア開発

・定量データ QUANTITATIVE DATA 数値化されたデータ・メトリクス METRICS 計測基準

メトリクスは定量データを基に基準を定義定量データがないとメトリクスは始まらない

定量データ

メトリクス

ソフトウェア開発

定量データに基づくソフトウェア開発

この光と影を紹介

定量データとメトリクスをプロジェクト運営における各種の運営・判断基準にしたソフトウェア開発

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光

これって、言い訳？

閑話休題 – 本題に戻って定量データとメトリクスの活用こそ

IOTやAI時代の生き抜く道

• 動作が説明できないブラックボックスな人工知能• つながる IOT はビッグデータとともにいつも変化• こんな時代を、定量データの活用で生き抜く• メトリクスと定量データは混沌の中の唯一の道標

AI IoTMetrics

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 件/KSLOC18

エンタープライズ系と比較してテストケース数は多い

組込み系って心配性なのかしら

ページと図表番号の訂正

(参考) 2015年版のときの組込みソフトウェアの実態（テストケース密度）

改良開発のときのテストケース数(C/C++)

結合テスト 156 件/KSLOC

総合テスト 83 件/KSLOC 組込み系データ白書2015 p.130

19

2015年よりは少なくなった（有意な差ではないかも）

ではないかもって、ヘタレなの？

組込みソフトウェアの生産性

改良開発のときの生産性 (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

21

C++の生産性が変動 ふーん

組込みソフトウェアの信頼性

改良開発のときの総合テスト検出バグ密度 (件/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

23

2015年より多くのバグを検出しかし有意な差ではないかも

ではないかもって、ヘタレなの？

本当はおもしろい組込みソフトウェアのデータ

リアルタイム性（時間制約）で生産性は変わるのか？ 組込みデータ白書 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

赤画面

3. IOTとAI時代の定量データの活用とその掟

活用実践編：実践的な定量データの活用を見ていくデータは活用してこそ価値がある 運用が命

定量データは収集しただけでは役に立たない役に立たないデータは収集しない・定量データをソフトウェア開発に役立てる・・定量データを使いこなすコツ・・定量データを使うときの掟・閑話：本当は怖いデータ白書の掟

32ここからビシバシいくわよ いや、休んで

てください

定量データを使いこなすコツ

33

無理をしない

少しずつ

使うデータだけ、使えるデータだけ

使わないデータは集めない

ダメ出しだけでなく評価にも使う

リスク対策だけでなく

評価し、参照すべき点を他に広める

現場の共感

定量データの活用で現場の共感

目的の明確化と活用方法の啓蒙

定量データを使うときの掟

34

データに振り回されるな

現場の実感も重要な判断「理由を聞け」

違和感があるデータが現れたら現場に聞け

定性的なデータ（感覚）も重要

逆に安全なデータでも危険が潜んでいる

偶然という悪魔

隠れた関係に注意

データにない背景因子を見つける「犯人は常に見えないところにいる」

現場の反感

現場のコストを考慮 – 自動化が望ましい

現場の精神的コストも考慮

自らをイジメるためにデータを集めているのではない

影

こんな掟も守れないようでは駄目ね

閑話：本当は怖いデータ白書の掟

• 発注者側からの攻撃に耐えろ• 世の中を知れ• 管理の強制力にしろ

35

影

なにこれ？怖いんだけど え？いつものこ

とじゃないの？

発注側に生産性の数値と信頼性の数値を知られてしまっている！

・データ白書を読まれている・データ白書の実際の読者は

開発現場よりユーザや管理部門！？→開発側はデータ白書の情報を知り、自分の実力（ベンチマーク）を知らないと

・・・負けてしまう「敵を知り、己を知る」

データ白書を読んだ発注側からの攻撃に耐えろ

36

負けないわ、私

• 組込み系ソフトウェアは• 大規模化、短納期化、複雑化• 複数機種並行開発、派生開発• IoT, AI, ビッグデータ

• 多種多様なデバイスがつながり• 不確定で大量のデータが駆け巡り• プログラムは非決定的に動く

• この波に飲まれてしまう→ 世の中を知るためのデータ白書データ白書のデータで「世の中の動きを知る」データは嘘をつかない（講演者は嘘をつく）

データ白書で世の中を知れ

37私も嘘をつかないわ、暴言は吐くけど

データ白書をプロジェクト管理の強制力にそして IOTとAI開発の羅針盤に

データで機械的にシステマティックに管理• 初心者から使える• プロジェクト管理• 製品（プロダクト）管理• （上司やユーザ、企画部門を管理）

→ 強制力としてのデータ白書・データは見本、指針、言い訳、現実、根拠・五里霧中の IOT と AI 開発の羅針盤

迷ったときの占い、人生相談 38

閑話休題：過激な言い回しは止めて

定量データを使いこなせ

39

• データは集めただけではゴミ• 使ってこそ宝物• 見える開発現場に• コツ：無理をしない、評価にも、共感• 掟：振り回さるな、隠れた関係、反感

• データ白書を使いこなすためには、実際の現場との乖離を埋める必要があり、そのために最初は振り回される覚悟が必要

なにこれ？抽象的すぎるんだけど

最後の一言だし、そこは分かって

今日のまとめ• 「うちは特殊だから、データ白書は使えな

い」ことはない• 「コスト的に使えない」ことはない• データは必要なものだけ集める• 使えるところを見つける• 生産性と信頼性のデータの見方• 統計で騙されるな• 敵を知り、己を知れ（データ的に）• 組込み系は変化している• 管理の手助け

40

感謝するわ

ありがとうございました