IoT時代の組み込み系ソフトウェア品質（3）

計測で組み込みソフトウェアの「品質」を丸裸にする（3/6 ページ）

公開 2017年10月24日 09時00分

更新 2018年02月23日 14時06分

[TechFactory]

印刷する連載新着通知を受け取る

　しかしこれでは新しいものが生まれない。測定ではこれでいいかもしれないが、計測では新しい発見が必要である。見落としの発見も必要である。このため、品質計測をするメンバーを定期的に入れ替えるなどの施策も実施する。この入れ替え施策は一時的に効率は落ちるが効果的である。ルーティンワークと入れ替えの施策をうまく組み合わせて、品質計測を継続させる。

バグは品質の夢を見るか

　品質計測は困難であり、茨の道を歩くようなものである。品質計測と聞いてすぐに思い浮かべるものにソフトウェアテストがある。テストをしてバグ件数を測定し、品質計測をする。テストケースで期待した出力が得られなかった件数をバグとしてカウントするのである。

　これだけ聞くと品質計測は簡単のように思えるが、そうたやすくはない。テストケースを作るのは大変であり、そのテストケースを実行するための準備と後片付けも大変である。また基本測定量のバグ件数だけでなく、ソースコード行数などの導出測定量も一緒に測定しなければならない。さらにバグ曲線（＊）を引きたくなると面倒である。Excelの手助けが必要になる。まったく面倒な仕事になる。

（＊）バグ曲線　バグ曲線とはジャーゴンで信頼度成長曲線のことである。横軸に実施したテストケース数（またはそれと相関のあるテスト時間）にし、縦軸に検出したバグ件数をプロットした曲線。統計的な近似曲線としてロジスティック曲線、ゴンペルツ曲線、指数形モデル、超指数形モデル、習熟S字形モデルなどがある。

　しかし品質計測はこれだけでは終わらない。そもそもバグを数えただけでは品質特性の何十分の一にも満たないというのが今の品質の考えである。品質特性の1つである性能効率性を計測するとすれば、最初から性能計測を計画して実装する必要がある。性能が満たないときはパフォーマンスチューニングをして、再度、性能計測をしなければならない。

　しかも品質計測はこれだけでは終わらない（重要だから2回目）。客観的かつ定量的に計測できるものばかりと限らないのである。品質には主観的もしくは定性的にしか計測できないものもある。そして敵の最終奥義「社長の鶴の一声」という主観評価にも耐える必要がある。品質計測の茨の道は続く。

　ユーザビリティなど魅力的品質の計測は面倒であり、その制御や作りこみは困難である。この結果、どうしても品質計測は機能要件に対するものになり、機能テストのみを実施し、検出したバグ関連の測定だけで済ませてしまう。これは怖い。品質の考えがゆがめられ、魅力的品質はないがしろにされ、バグゼロが究極の目的になってしまう。人はデバッグのみに生きるようになる。

　しかし品質計測を強制させる恐怖政治はいけない。部屋を掃除しなければGの逆襲があると脅して掃除をさせるのではなく、部屋がきれいになると人を部屋に呼ぶこともでき、そこから幸せが訪れる（かもしれない）。品質計測も楽しく毎日のルーティンワークにし、幸せが訪れる（ことを期待しよう）。

次ページへ組み込み系品質の計測

印刷する

IoT時代の組み込み系ソフトウェア品質

組み込みソフトウェアにおける「品質」とは、一体、何者であろうか。多用されている言葉であるがその実態はようとしてしれない。この連載ではIoT時代の組み込み系ソフトウェアの品質」をテーマに開発現場の目線で見ていく。出演者は情報系に籍を置く大学1年生の紅美香美（くみこうみ）と品質寛容（しなしちひろい）。

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

五味弘

OKI（沖電気工業）シニアスペシャリスト、エバンジェリスト。博士（工学）。ソフトウエアの開発支援・教育に従事。電子情報振興協会（JEITA）専門委員会の委員長や情報処理振興機構（IPA/SEC）などの委員多数。三重大学などの非常勤講師も務める。エンタープライズ系と組み込み系におけるソフトウエア開発の知見融合が関心事。共著書に『定量的品質予測のススメ』（オーム社、2008年）、『プログラミング言語論』（コロナ社、2008年）などがある。