LoginSignup
5
4

More than 5 years have passed since last update.

品質系エンジニアが統計学をまなぶとき

Last updated at Posted at 2017-12-16

はじめに

本稿はオープンストリーム Advent Calendar 2017の17日目の記事です。

自分自身が品質系エンジニアとして、「統計を学んだほうが良さそう」と思ったときに、どのあたりを学ぶべきかは手探りだったなぁと思ったので、本稿でまとめてみることにしました。統計的手法の計算式や考え方の説明はここではしません。
また、統計の手法について、具体的な使い方がイメージできないと言っている方もいたので、使い方の例もあげてみます。
ただし、あくまで、私の意見なので、「これも必要」とか「これは要らない」などご意見ありましたら、お寄せいただければ、幸いです。

業務別に書きます

業務によって必要なものも異なると考え、「テスト実施」「品質保証」「品質管理」という業務別にまとめてみます。

「品質保証」「品質管理」は、いろんな定義がありますが、
ここで各業務が指しているものは、以下のものとします。

  • テスト実施 テスト設計、テスト実装、テスト実施を含みます。
  • 品質保証 製品が決められた品質であることを保証する業務。テストの管理も含みます。
  • 品質管理 製品が必要なプロセスでつくられていることを管理する業務。プロセス改善なども含みます。

テスト実施

必要なものは以下の通り

  • 平均
  • 棒グラフ

平均

例えば、1日当たりのテストケース消化件数などに、平均を使うことで、
いつまでに対象のテストケースが消化できるか、予定を立てることができます。

棒グラフ

「バグの原因別件数」を作成し、バグの原因分析などに役に立つでしょう。
※バグの原因別の件数をグラフにする場合は、ヒストグラムではなく、棒グラフです。

品質保証

必要なものは以下の通り

  • テスト実施で書かれたもの
  • 分散
  • 箱ひげ図
  • ヒストグラム
  • 管理図

平均

プロジェクトごとの平均を出して、その他のプロジェクトの平均と比較することで、そのプロジェクトがどんなプロジェクトであるか判断することができます。
例えば、レビュー指摘件数、レビュー実績工数、規模当たりのテストケース数、規模当たりの検出バグ数などの平均を使います。

分散

分散を知ることで、その集団の技術力がわかると言われています。
例えば、ある組織の開発プロジェクトの「規模当たりの検出バグ数」の分散が大きいということは、「バグが沢山検出されるプロジェクト」もあれば、「あまりバグが検出されないプロジェクト」もあるということになります。
そのように、プロジェクトごとのブレが大きい場合は、技術力に幅があるとも考えられます。
しかし、その組織が多岐にわたったプロジェクトを扱っている場合もあるので、本当の状況を把握するためには、詳細データを見る必要があります。

箱ひげ図

例えば、「組織別のデータの分布の違い」や「ツールを使っている場合と使っていない場合の分布の違い」などを見ることができます。

ヒストグラム

例えば、「どの規模のプロジェクトがどれだけあるか」など、データの形を見ることができます。
平均や箱ひげ図だけを見ているとわからないデータの形も、ヒストグラムにすることでわかります(例えば、山が二つあるようなの分布の場合)

管理図

例えば、バグの検出数が管理指標の範囲内にあるかどうかを管理することができます。

品質管理

最低限必要なものは以下の通り
(プロセス改善をするなら、他にも必要なものはある)

  • 品質保証でかかれたもの
  • 散布図
  • 相関係数
  • 回帰分析
  • t検定

散布図

例えば、複数プロジェクトの「規模当たりのテストケース数と規模当たりの検出バグ数」のデータの分布をみるのに使うことができます。

相関係数

例えば、ある組織内の複数プロジェクトを対象として「レビューで指摘された欠陥数とテストで抽出されたバグ数」などの相関係数を出したりします。

回帰分析

予測に使うことができます。
「レビューにかけた時間数からバグ検出数を予測する」など。

t検定

例えば、「プロジェクトの規模当たりの検出バグ数」を「あるツールを利用した場合と利用しなかった場合」で統計的検定を行うときに使用します。
プロセス改善では「プロジェクトの何らかの値」について「ある施策を実施した場合」と「実施しなかった場合」の比較をするために使用します。

おまけ

最後の品質管理に関しては、正直、書ききれていません。
本当に状況を把握して、必要な検討をして、施策を打って、効果があったかを見るためには、実験計画法や、統計学の歴史的に知られてきた陥りやすい罠のようなもの(シンプソンのパラドックスとか)も含め学んだほうが、結果的には正しいことに近づける気がしています。
また、陥りやすい罠に対しては、業務で日々感じていることにより気づけることもあります。
統計学の知識を、品質系エンジニアが持つからこその気づきがあると思います。

さいごに

もしかしたら、棒グラフやヒストグラムなどが出てきて、意外に思われた方もいるかもしれません。
しかし、いろんな勉強会に行くと、統計を専門にしている方や、統計をちゃんと勉強している方ほど、「グラフにしてデータの形を見ることの重要性」を説かれます。

これから統計を勉強される方は、まずは、グラフを書いて、データの形を見るところから始めても良いと思います。
また、世の中にはいろんなデータのいろんなグラフがあり、間違ったグラフ、形を歪めているグラフもたくさんあります。日々、目にするグラフを、よーく見るようにするだけでも、グラフを見る力は上がるはずです。

私としては、第二弾が書けるように、統計学についても、業務についても学んでいきたいと思います。

5
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
4