Facebook x

ジャンル

テスト技法・工程 2023.08.28
x hatenabookmark

ソフトウェアメトリクスと分析(1)-情報ニーズ・分析の目的を明確にする-

執筆: 堀 明広

バルテス・ホールディングス株式会社 R&C部 部長

ソフトウェアメトリクスと分析(1)-情報ニーズ・分析の目的を明確にする-

「何処にどんな問題があるのか、定量的に示せ」、「その効果を定量的に示せ」。

ソフトウェアメトリクスを使って、モノ・コトを定量的に捉えるのは是非にすべきことです。定量的にモノ・コトを表わすことには、曖昧でなく具体的になる、共通の尺度でコミュニケーションできる、といったメリットがあるためです。

しかし、「どんなデータをどう使えば良いのか分からない」「品質分析はどのようにやれば良いのか分からない」という声もよく聞きます。

本稿では、品質分析を実施するにあたっての考え方を、筆者の経験談を踏まえながら、いくつかの回に分けて解説します。初回は、分析を始めるにあたっての基本的な考え方「情報ニーズ」を取り上げます。

「何のために、何をしたいのか」「そのためにはどんな情報が必要なのか」。これが分析の起点になり、分析データの作り方や、分析データの見方に繋がります。

もくじ
  1. 「このデータから何が言えるのだろうか?」では上手くいかない
  2. 何のために、何をしたいのか?分析を見る視点を変える
  3. 分析の方法論より先に、情報ニーズを明確にする
  4. まとめ

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

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

その当時、私が所属していた品質管理の専門部署には、大きく分けて「品質管理グループ」と「データ管理グループ」の2つのグループがありました。

「品質管理グループ」は、開発プロジェクトに品質管理担当として参画する者たちで構成していて、私はこの「品質管理グループ」に属していました。

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

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

「品質管理グループ」に属していた者たちは、私を含めて、「データ管理グループ」から提供された色々な棒グラフや円グラフや折れ線グラフなどを見て、「これらのグラフから、いったい何が言えるのか?」と、グラフたちをジーッと睨んでずいぶん悩んだものでした。

悩む男.png

しかし残念ながら、グラフ等々から分かることと言えば、「○○機能の開発進捗が遅れている」「△△機能でバグが多発している」といったような、プロジェクト内のメンバーだったら誰もが知っている、既に分かりきっていることがほとんどです。既知情報でも、分析してみてそれが定量的に裏付けされることや、遅れや悪さの程度が数字で分かることには大きな意義はありました。しかし、既知情報から更に突っ込んで分析し、新たな情報を得ようとするのですが、そういったものはなかなか導き出せませんでした。

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

2.何のために、何をしたいのか?分析を見る視点を変える

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

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

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

  →状況って何?

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

    →テストの進捗状況

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

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

       →それは・・・

考える男.png

今思うと、この時の一人ブレストの内容は、別に高度なものでもなんでもなかったように思いますが、分析から一旦離れて、「そもそも何をやりたいのか?」ということを整理したのは、当時の私にとって、とても重要なことでした。一人ブレストをやってみた結果、どんなデータをどのように見るべきかがだんだん分かってきて、データを見る目が少し変わりました。

ごく簡単な例を、レビュー指摘件数というメトリクスを取り上げて示します。従来はレビュー指摘件数の計画値と実績値を並べて、計画よりも多いか少ないかくらいしか見ていませんでしたが、以下のようにデータを見るようになりました。

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

分析データを見る目が少しずつ養われるにつれ、それまで「データ管理グループ」からお仕着せ的に提供されたデータでは足りない点も分かってきて、こういうデータを提供して欲しいと、すり合わせをするようになりました。

「データ管理グループ」はプロジェクト横断でデータ収集・集計するシステムを構築していたので、均一な分析データを生成できるという利点はあったのですが、小回りが利かないという面もあり、そういった所は独自で集計・分析する環境を作って品質管理業務に便利に使っていました。

そのうちに、痒いところに手が届くような分析データが簡単に素早く生成できる分析環境が整ってきて、それが他のプロジェクトでも共通的に使われるようになりました。

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

分析.png

その延長線で、開発リーダやステークホルダから「堀さん、〇〇の情報が欲しいのだけれど、お願いできますか?急ぎで明日までに欲しいのですが、間に合いますか?」といった要望にも応えられるようになりました。

以前には四苦八苦して、場合によっては深夜残業して何とか使い捨て的な分析データを作っていましたが、分析データを診る目が充実してくると、「はい、そのデータでしたら、サーバに最新情報を毎日アップしています。△△というデータを見てみてください。その件は品質担当からも開発現場にサポート実施中です」といった具合に、ニーズを先回りできるようになりました。

こんなことが出来るのは、ある意味当たり前のことで、前のプロジェクトで必要があったものを、現在のプロジェクトでも必要になるだろうと、最初から準備していただけのことです。

このような対応ができるようになった大きな要因は、分析データを見る目が変わったことです。以前はとおり一遍の分析データを見て、ここから語れるものが何か無いか、という目で見て、結局は特別なことは見いだせなかったのですが、まずやりたいこと・知りたいことがあり、その答えを得るために、一連のデータを通してプロジェクトやプロダクトを診るようになりました。

つまり、考えの順番が入れ替わったのです。少しオーバーに書くと、以下のようになります。

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

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

さまざまなメトリクスや分析データは、いわば飛行機のコックピットに並べられている計器類のようなものです。飛行機が計画どおりに安全に目的地に到着できるよう、飛行機が今(又は今まで)、どこを飛んでいて、高度・速度はどうかを計測し、思ったとおりに巡行できているかどうかをチェックするのに、計器類は用いられます。

天候や風向きなどによって計画から外れそうになったら早めに対処して、計画どおりのルートを維持します。行く手に嵐が発生する予兆があれば、ルートを変え、新たな運航計画に沿って運行管理は続けられます。

ソフトウェア開発も同じことです。品質管理の原則は、「作り込む不具合は極力少なくする」「作り込んでしまった欠陥は、レビューやテストで可能な限り早く、可能な限り多く抽出して修正する」です。

この原則から外れてしまっているところはどこか、それは何故か、その情報を得るためには、どんなメトリクスをどう診たら分かるのか。

「ソフトウェア開発プロジェクト」という名の飛行機の運行に必要な計器類を作り、それら計器の針が示す内容から、自分の飛行機に何が起きているかを把握して、さまざまな施策に繋げるのです。

この計器の示す内容からして、何が言えるのだろうか、というのは、ある意味、本末転倒な話なのです。

どんなデータをどう使えば良いのか、品質分析はどのようにやれば良いのか、といった分析の方法論よりも先に、まず、「何のために、何をしたいのか」「そのためにはどんな情報が必要なのか」、この情報の必要性、すなわち情報ニーズがとても大切なのです。

まとめ

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

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

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

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

次回は、分析を開始する際に留意すべき事項、ニーズに合った分析を行うコツ、データ収集を円滑に進めるコツについて解説します。

テスト技法・工程
x hatenabookmark

執筆: 堀 明広

バルテス・ホールディングス株式会社 R&C部 部長

組込み系プログラマー、ソフトウェア品質管理を経て、現職はバルテス株式会社 R&C部 部長 兼 上席研究員。担当業務は社内人材育成、検証・分析の技術開発、標準化、セミナー講師。訳書は『ソフトウェアテスト293の鉄則』(日経BP、共訳)、『ISO/IEC/IEEE 29119 ソフトウェアテスト規格の教科書』(バルテス、監訳)。著書は『ソフトウェア見積りガイドブック』(オーム社、共著)、『続・定量的品質予測のススメ』(佐伯印刷、共著)、『IT業界の病理学』(技術評論社、共著)。得意分野はバグ分析。