トレンド情報 / 記事を探すCOLUMN

ソフトウェアメトリクスと分析(1)- 情報ニーズ:何のために、何をしたいのか -

更新日|2019.02.06

堀 明広

ソフトウェアメトリクスと分析(1)- 情報ニーズ:何のために、何をしたいのか -

はじめに

 「何処にどんな問題があるのか、定量的に示せ」「その効果を定量的に示せ」
ソフトウェアメトリクスを使って、モノ・コトを定量的に捉えるのは是非にすべきことです。定量的にモノ・コトを表わすことには、曖昧でなく具体的になる、共通の尺度でコミュニケーションできる、といったメリットがあるためです。
しかし、「どんなデータをどう使えば良いのか分からない」、「品質分析はどのようにやれば良いのか分からない」、という声もよく聞きます。
 本稿では、品質分析を実施するにあたっての考え方を、筆者の経験談を踏まえながら、いくつかの回に分けて解説します。
 初回は、分析を始めるにあたっての基本的な考え方「情報ニーズ」を取り上げます。
 「何のために、何をしたいのか」「そのためにはどんな情報が必要なのか」。これが分析の起点になり、分析データの作り方や、分析データの見方に繋がります。

「このデータから何が言えるのだろうか?」では上手くいかない

mv2

 私も品質管理の仕事を何年か積み重ねてきました。(関連記事:「QA」とは?ソフトウェア品質を守るQAエンジニアの役割

 品質管理の仕事と言ってもさまざまなものがありますが、今回は、ソフトウェア開発プロジェクトに「品質管理担当」として携わった際の、分析に関わる私の失敗経験のご紹介から話に入っていきます。

 その当時、私が所属していた品質管理の専門部署には、大きく分けて「品質管理グループ」と「データ管理グループ」の2つのグループがありました。
「品質管理グループ」は、開発プロジェクトに品質管理担当として参画する者たちで構成していて、私はこの「品質管理グループ」に属していました。
品質管理担当は、1人1つのプロジェクトを受け持って、そのプロジェクト内の品質管理業務を行っていました。具体的には、各種品質指標の計画値の策定、実績の収集と予実績分析、各開発チームのレビュー計画やテスト計画の立案推進とそれらのレビュー、Quality Gateを通過させるための要件を満たすための各種サポート、品質分析を行って開発リーダに報告、改善のサポート、といったものです。その一環で、上級管理者層やお客様に報告するネタ元を作成したりもしていました。

 もう一つのグループ「データ管理グループ」は、複数のプロジェクトを横断し、データの収集・集計を一手に扱っていました。データを収集して集計するのもかなりの手間がかかるので、それを各々の品質管理担当が行うのではなく、少人数のデータ管理グループが一括して担当していました。複数のプロジェクトのデータを一括して処理していたため、グラフ化の内容も粒度もプロジェクトごとにバラついたりせず、均一な質で行われていました。より新鮮なデータをより正確に管理できるよう、さまざまな集計・分析ツールも開発していました。データ管理グループは、定期的に収集したデータをプロジェクトごとに集計して品質管理グループに提供していました。各種集計データを受け取った品質管理グループの品質担当は、自分のプロジェクトの品質管理業務や報告資料の作成に用いていました。

 「品質管理グループ」に属していた者たちは、私を含めて、「データ管理グループ」から提供された色々な棒グラフや円グラフや折れ線グラフなどを見て、「これらのグラフから、いったい何が言えるのか?」と、グラフたちをジーッと睨んでずいぶん悩んだものでした。しかし残念ながら、グラフ等々から分かることと言えば、「○○機能の開発進捗が遅れている」「△△機能でバグが多発している」といったような、プロジェクト内のメンバーだったら誰もが知っている、既に分かりきっていることがほとんどでした。既知情報でも、分析してみてそれが定量的に裏付けされることや、遅れや悪さの程度が数字で分かることには大きな意義はありました。しかし、既知情報から更に突っ込んで分析し、新たな情報を得ようとするのですが、そういったものはなかなか導き出せませんでした。

 そんな中でも「これはどうだ」と思える情報を導き出せたこともありました。少し得意な気持ちになって開発リーダに知らせたところ、「はい、正解です。よく出来ました」と言われたことがありました。ちょっと突っ込んで分析して新たな情報を引き出した、と思ったものは、リーダ達には既に分かっていたことで、私はそれを後から知っただけのことでした。この時にはずいぶん悔しい思いをし、また同時に、このままではダメだと、行き詰まりを感じたものでした。

何のために、何をしたいのか

 何かを変えなければ、現状追認型(既に分かっていることをデータで裏付ける)の分析から抜け出せないような気がして、分析作業から一旦離れ、私は一人でブレーンストーミングをポツリポツリとやり始めました。PCに向かって、今の悩み事を一つ一つ、書き出してみて、自問自答してみたのです。

自分はそもそも、何をしたいのだろう?

 →品質管理面で、各開発チームの状況を把握したい。

  →状況って何?

   →レビューの進捗状況や指摘の対応状況、指摘の中身

    →テストの進捗状況

     →バグの発生状況、バグ対処の進捗状況、指摘の中身

      →レビューやテストの進捗状況やバグの発生状況を把握したいのはなぜ?

       →それは・・・

 今思うと、この時の一人ブレストの内容は、別に高度なものでもなんでもなかったように思いますが、分析から一旦離れて、「そもそも何をやりたいのか?」ということを整理したのは、当時の私にとって、とても重要なことでした。一人ブレストをやってみた結果、どんなデータをどのように見るべきかがだんだん分かってきて、データを見る目が少し変わりました。
 ごく簡単な例を、レビュー指摘件数というメトリクスを取り上げて示します。
 従来はレビュー指摘件数の計画値と実績値を並べて、計画よりも多いか少ないかくらいしか見ていませんでしたが、以下のようにデータを見るようになりました。

・レビュー指摘件数の工程別推移
開発の初期段階ではレビューに十分な力を割いて実施していても、時間の経過とともにだんだん進捗遅れが出てきてその結果レビューがおざなりになり、指摘件数が少なってきてはいないかどうか。
・レビュー指摘件数と、テストで検出されたバグ件数の対比
レビューが不十分なままテストを実施したことにより、レビューで検出すべき欠陥が、テストでバグとして過多に検出されていないかどうか。

 分析データを見る目が少しずつ養われるにつれ、それまで「データ管理グループ」からお仕着せ的に提供されたデータでは足りない点も分かってきて、こういうデータを提供して欲しいと、すり合わせをするようになりました。「データ管理グループ」はプロジェクト横断でデータ収集・集計するシステムを構築していたので、均一な分析データを生成できるという利点はあったのですが、小回りが利かないという面もあり、そういった所は独自で集計・分析する環境を作って品質管理業務に便利に使っていました。そのうちに、痒いところに手が届くような分析データが簡単に素早く生成できる分析環境が整ってきて、それが他のプロジェクトでも共通的に使われるようになりました。

 こんなことを繰り返しているうちに、自分たちが担当するどのプロジェクトでも共通的に必要とする分析データはこういうものだと、「分析のスタイル」が定まってきました。この基礎的な分析スタイルをベースにして、プロジェクトごとに持っている課題や特性の違いから、こんな分析データも必要だ、といったものを新たに付け加え、分析データがだんだん充実したものになってきました。

 その延長線で、開発リーダやステークホルダから「堀さん、〇〇の情報が欲しいのだけれど、お願いできますか? 急ぎで明日までに欲しいのでですが、間に合いますか?」といった要望には、以前には四苦八苦して、場合によっては深夜残業して何とか使い捨て的な分析データを作っていたのですが、分析データを診る目が充実してくると、「はい、そのデータでしたら、サーバに最新情報を毎日アップしています。△△というデータを見てみてください。その件は品質担当からも開発現場にサポート実施中です」といった具合に、ニーズを先回りできるようになりました。こんなことが出来るのはある意味 当たり前のことで、前のプロジェクトで必要があったものを、現在のプロジェクトでも必要になるだろうと、最初から準備していただけのことでした。

 こういったことが出来るようになった大きな要因は、繰り返しになりますが、分析データを見る目が変わったことでした。以前はとおり一遍の分析データを見て、ここから語れるものが何か無いか、という目で見て、結局は特別なことは見いだせなかったのですが、まずやりたいこと・知りたいことがあり、その答えを得るために、一連のデータを通してプロジェクトやプロダクトを診るようになりました。
つまり、考えの順番が入れ替わったのです。少しオーバーに書くと、以下のような具合にです。

 以前:〇〇データを見て、そこから何か気が利いたことが言えないかを探す。
 現在:何かやりたいこと・知りたいことがあって、それに用いるために、〇〇データを△△という視点で診る。

分析の方法論より先に、情報ニーズを明確に

mv3

 さまざまなメトリクスや分析データは、いわば飛行機のコックピットに並べられている計器類のようなものです。飛行機が計画どおりに安全に目的地に到着できるよう、飛行機が今(又は今まで)、どこを飛んでいて、高度・速度はどうかを計測し、思ったとおりに巡行できているかどうかをチェックするのに、計器類は用いられます。天候や風向きなどによって計画から外れそうになったら早めに対処して、計画どおりのルートを維持します。行く手に嵐が発生する予兆があれば、ルートを変え、新たな運航計画に沿って運行管理は続けられます。

 ソフトウェア開発も同じことです。品質管理の原則は、「作り込む不具合は極力少なくする」「作り込んでしまった欠陥は、レビューやテストで可能な限り早く、可能な限り多く抽出して修正する」です。
この原則から外れてしまっているところはどこか、それは何故か。その情報を得るためには、どんなメトリクスをどう診たら分かるのか。「ソフトウェア開発プロジェクト」という名の飛行機の運行に必要な計器類を作り、それら計器の針が示す内容から、自分の飛行機に何が起きているかを把握して、さまざまな施策に繋げるのです。

 この計器の示す内容からして、何が言えるのだろうか、というのは、ある意味、本末転倒な話なのです。
どんなデータをどう使えば良いのか、品質分析はどのようにやれば良いのか、といった分析の方法論よりも先に、まず、「何のために、何をしたいのか」「そのためにはどんな情報が必要なのか」、この情報の必要性、すなわち情報ニーズがとても大切なのです。

終わりに

 分析で一番大事なのは情報ニーズ、すなわち、「何のために、何をしたいのか」「そのためにはどんな情報が必要なのか」です。

 このことは今では当たり前のことのようにも思うのですが、当時の私はずいぶん悩んだものでした。思い返すと、分析で何か良さそうなoutputしたいがために、そもそもの目的を忘れてしまっていたのだと思います。

 今では、どんな分析データが必要なのか、その分析データは何に用いるためのものなのか、その分析データをどう診たら何が分かるのか、いくつかパターンが蓄積できています。

 「どんなデータをどう使えば良いのか分からない」、「品質分析はどのようにやれば良いのか分からない」。こんな時には、分析から一旦離れて、「そもそも何をしたいのか」に立ち返るようにしてみてください。

資料ダウンロード

ライター:堀 明広

バルテス株式会社 第3ソフトウェアテスト事業部 R&C部 部長

組込み系プログラマー、ソフトウェア品質管理を経て、現職はバルテス株式会社 R&C部 部長 兼 上席研究員。担当業務は社内人材育成、検証・分析の技術開発、標準化、セミナー講師。訳書は『ソフトウェアテスト...