ソフトウェアメトリクスと分析（２）－ 分析精度： データの信頼性と仮分析－

1．分析開始時の2つの留意事項

まずは分析の進め方を説明します。これを留意しておかないと、誤った分析をして正しい情報が得られなかったり、ニーズに合わないトンチンカンな分析をしたりすることに繋がります。

結論を先に示しますと、以下の2つが重要です。

• データを盲信しない
• 最初は粗くて良いので、手早く分析ビューをoutputする

「分析ビュー」とは、グラフや表など、さまざまな集計結果のことを指します。
以下、筆者が得意とするバグ分析を例にしながら説明します。

1-1　データを盲信しない

1つ目の留意事項は「データを盲信しない」ということです。

バグ分析では、色々なデータを使ってさまざまな分析をします。情報元はバグ票です。例えば、以下のようなデータを使います。

バグ分析で用いるデータ

• 各種日付（バグ発見日、バグ票発行日、対処完了の予定日と実績日 など）
• ステータス（発行中、解析中、対処中、改修確認中、完了など）
• バグ発生した機能
• バグの原因箇所
• バグの作り込み原因
• バグを検出したテストフェーズ
• 本来検出すべきテストフェーズ
• （他にもいろいろありますが、割愛）

バグ票は、さまざまな情報が集約されている宝の山で、実に多くのことが分かります。しかし、筆者の経験では、バグ分析で使うデータの精度はそれほど高くなく、「バグ票で入力すべき項目が入力されていない」「誤った情報が入力されている」といったものも少なくありませんでした。

データの内容が誤っていて実態とかけ離れているようであれば、当然ですが、そのデータをそのまま使うわけにはいきません。状況を表してない不正確なデータで分析した場合に、誤った状況認識をして必要な施策が打たれない、見当違いな施策をわざわざコストをかけて講じて効果も得られない、といったことに繋がるためです。

いい加減なデータを正確に集計しても、誤った状況認識をするだけです。手持ちのデータを鵜呑みにして盲信して分析してはならないのです。

1-2　最初は粗くて良いので、手早く分析ビューをoutputする

2つ目の留意事項は「最初は粗くて良いので、手早く分析ビューをoutputする」ということです。

分析を開始する際、最初から時間をかけて一揃いの分析ビューをoutputする必要はありません。

分析をやりはじめる初期段階では、小さく素早く、スピードを重視してoutputすることに重きを置きます。

この時、分析の内容の網羅性や緻密さは重要ではなく、基本的なもので構いません。

この初期段階の分析を、筆者は「仮分析」と呼んでいます。仮分析では質よりもスピードを重視する理由は、仮分析の目的に依るためです。次章で詳しく解説します。

2．仮分析の2つの目的

仮分析の目的は、大きく分けて二つあります。

• データの確からしさを確認する
• そのプロジェクトや組織で必要な分析ビューを掘り起こす

それぞれ解説していきます。

2-1　データの確からしさを確認する

仮分析の目的の一つは「データの確からしさを確認する」ことです。

分析を行うにあたって、各データの確からしさを確認し、各データがどの程度信頼できるかを見定めることを最初に行うべきでしょう。

前述しているとおり、いい加減なデータを正確に集計しても、あまり意味は無いからです。やや大袈裟に言えば、「データは正しくない」ことを前提にしておくのがちょうど良いくらいです。

バグ票はBTS（Bug Tracking System）で管理されていることが多いですが、BTSによっては、項目数が200以上もの多数に及ぶこともあります。各項目を分析に使うものと使わないものとに分けて、データの信頼性の程度を一つひとつ判断していきます。少し骨が折れる作業であるものの、ここは手が抜けないところなので頑張りどころです。

データの確からしさの確認ポイント

各データがどの程度確かなのかは、以下の観点で判断していきます。

• 各項目にデータが入力されているか。データが入力されておらず欠損があるとしたら、それはどの程度か。
• 各項目に入力されているデータは、実態を妥当に表しているものか。（いくつかサンプリングして確認する）
• 実際に基本的な分析データを試行的に出してみて、明らかにおかしいデータになっていないか、感覚的に合うか。

以上のように、データの確からしさを確認するのが、仮分析の目的の一つです。

したがって、仮分析ではあまり手間暇かけて細かく分析する必要はなく、むしろ、できるだけ手間をかけないでスピーディーに基本的な分析だけ行った方が、無駄が無くて良いのです。

2-2　そのプロジェクトや組織で必要な分析ビューを掘り起こす

初期分析のもう一つの目的は、「情報ニーズの明確化」です。

分析ビューには、どのプロジェクトでも共通的に必要とされる、一定の型というものがあります。しかし、お決まりの分析ビューだけでは不十分なこともあります。

プロジェクトにはそれぞれ、固有の背景やいきさつなどがあるもので、そのプロジェクト固有の課題があるものです。そのプロジェクト固有の問題や課題を解決するための情報を、分析から導き出す必要があります。

まずは基本的な分析ビューを手早く生成して関係者に共有してみましょう。

分析というものは、何かが分かると、その次にまた何かが知りたくなるものです。

例を以下に記します。

(例)　仮分析の結果、システムテストでバグが頻発していることが分かった

• どこのチームでシステムバグが多発しているのか？
• システムテストでバグが多発しているチームでは、システムテストの前段階でも同様にバグが多発していたのか？
• どこのチームではシステムテストバグが出ていないのか？
• システムテストではどの機能でバグが出ているのか？どの機能でバグが出ていないのか？

このように、仮分析を起点に、プロジェクトの状況に合わせて分析と対策の指針を定めていきます。

3．データ収集のプロセスを改善する2つのコツ

本記事の冒頭部分で、データを盲信してはならないことを説明しましたが、「データは正確無比でなければならない」ということではありません。

データが多少正確でなかったとしても、全体の傾向が掴めるのであればそれで良いのです。実際、データがすべて正しかったことなんて、筆者のこれまでの経験ではありませんでした。データに多少の不備があっても、大勢に影響が無いのであれば、そのまま分析に使っても問題ないでしょう。

一方、分析に耐えられないと判断されたデータは、当然の話ですが、そのままでは分析には使えません。例えば、筆者が扱ったデータの不備は、以下のパターンが多く見られました。

• そもそも、バグ票が起票されてなく、ローカルで情報のやり取りがされていて情報が散逸している、又は記録が残っていない。
• バグ票が起票されていてもデータが入力されていない、又は部分的にしか入力されてなく、欠損が多すぎる。
• バグ票の更新が後回しになっていて、情報が古い。
• データが安易に入力されていて、実態を表していない。

一つ、エピソードをご紹介します。

あるプロジェクトでは、バグの作り込み原因が、「コーディングミス」が大半を占める状況でした。

あまりにもコーディングミスが多すぎるため、該当するバグ票をチェックしたところ、本当は「設計ミス」などの別の原因なのに、「コーディングミス」と安直に入力されているものがかなりあることが分かりました。

これでは分析にならないので、コーディングミスとされているバグ票すべての内容を一件ずつ確認し、バグの作り込み原因を手作業で修正しました。かなりの数のバグ票の内容を確認する必要はありましたが、分析はほぼ正しい状況を表せるようになりました。

データが欠損していたり精度が悪くて実態を表していなかったりした場合には、別のデータ項目で代用できないか検討します。

または、データを入力・収集するプロセスを見直しし、分析に足る精度のデータが得られるように改善を図ります。

データ収集のプロセスを改善するコツの汎用的なものを二つご紹介します。

3-1　とにかくデータを使って会話する

データの精度があまりに悪い場合には、前述したようにそのままでは分析に使えません。しかしそのデータはお蔵入りにしないで、参考値として分析データを出します。正式な分析データとして扱うことはできないとしても、関係者と会話するようにします。

分析のアンチパターンとして、「データが集まらない」「データの精度が悪い」ために分析できない、というものがよくあります。しかし「データの精度が悪い」とそこで立ち止まらず、とにかくデータを使うことがポイントです。

そもそも、定量データを使う目的は何でしょうか。大きく分けて以下の四つが挙げられます。

• 数字という共通の尺度を使って関係者間で状況を共通認識し、意思疎通する。
• すでに分かっていることに対し、客観的な裏付けを取る。
• 未だ分かっていなかったことを、分析によって気づく。
• 過去から現在までの状況を知り、未来を予測する。

定量化そのものは手段であって、目的ではありません。

上記の目的を実現するために、必要だから定量データも使う、ただそれだけです。上掲の定量化の目的を意識しながら会話の中でデータを使っていくと、自然に、正確なデータが必要であることが、関係者で理解されていきます。　「もっと正確な情報を知りたい」「他にもこんな分析データを見たい」と、良い意味で欲が出てきます。

使われるデータはちゃんと集まりますし、精度も良くなっていくものです。
使われないデータは集まりませんし、精度も良くなりません。
『「そのデータが無いと不便」と思われているような状況を作る』と意識すると良いでしょう。

3-2　一度に良くしようとせず、悪いところを少なくする

データ収集は、ある程度は作業の習慣化に頼るところも大きいのですが、一気にプロジェクトや組織の全体を良くしようとしても、なかなかうまくいかないことも多いものです。

筆者が大規模プロジェクトで取った作戦をご紹介します。
そのプロジェクトでも、分析に使うデータがなかなか集まらなかったり精度が悪かったりしていました。プロジェクトの全体会議で周知・依頼しても、なかなか改善できませんでした。

そこで、プロジェクト全体に働きかけすることは継続しつつ、併行して個々のチームに個別に働きかけて、良いところを少しずつ多くしていきました。その結果、データ収集の状態が悪いチームがしだいに少なくなって悪目立するようになり、そのうち、プロジェクト全体でデータ収集が良好になりました。

このように、一度に良くしようとせず、「良いところを少しずつ増やす」ことで、「悪いところを少なくする」と考えてみてください。

まとめ

本記事のポイントを、以下にまとめます。

• 分析に用いるデータの精度は悪いことを前提にし、データの信頼性を確認しながら分析すること。
• データの信頼性を高めるためには、とにかくそのデータを使うこと。データを使って会話すること。
• 分析の初期段階は仮分析として位置付け、分析の質よりもスピードを重視すること。
• 仮分析を起点に、プロジェクトや組織の懸念事項をベースに、分析の指針を定めていくこと。
• 分析した情報によって、何をしたいのかを明確にすること。目的を曖昧にしたまま、方法論に傾かないこと。

今回の記事で解説したポイントをデータ分析の参考にしてみてください。