品質を説明するには(定量的指標編)

はじめまして、QAコンサルタントのしろです。

システムのステークホルダーやプロダクトオーナーから「品質ってどうなの？」って聞かれたとしたら、定量的なデータを示した説明をするのが良いですよね。「定量的」とはよく聞きますが、改めてソフトウェアの品質を説明するための定量的な指標をおさらいする意味で、色々なところで使われているソフトウェア品質の指標を一部ではありますが、ご紹介します！

品質を表すために使われる定量的指標たち

ソフトウェア開発の見積などで必要な指標など

コスト

• これは様々な活動に対する必要な金銭、時間などの事です。こちらは品質自身を表す指標として使う事はないですが、コスト対効果など様々な形で登場します。特にシステム開発コストは品質を作るうえでも必要になりますのでしっかりと把握・確認しておくことは必要です。コストに該当するものは金銭、時間以外に心理コスト、認知コスト、肉体コストもありますが、定量指標としては使用することは難しいと思います。

工期

• こちらは時間(期間)ですね。これも品質自身を表わす指標として使う事は余りないかと思います。しかしプロジェクトの期間は品質に影響を与える非常に重要な要素ですので明確にしておきたいです。
  特に工期の遅れや、延長した。などの場合、品質にも影響を与えている可能性が高いため、その理由を確認しシステムへの影響を把握しておくことは、後の振り返りなどで必要になります。

工数

• 人時、人日、人月: 実際に作成に関わった時間のことですね。期間、リソースなどの要素をかけ合わせて算出します。1人が1時間稼働すれば＝1人時ですね。後は掛け算です。
  勿論、これだけで品質の良し悪しが分かる訳ではありませんが、当初計画時の工数を大きく超えるような場合は、品質に何かしらの課題を抱えていると考えられます。

規模

• LOC (Line of Code): お馴染みのコードの行数です。KLOC(キロ:1000行)やMLOC(メガ:100万行)もありますね。これらは測定方法、使用言語、作成者の書き方でかなり行数が異なるので信頼性に欠ける事がありますので、継続的に測定し品質指標として使う場合コーディング規約や測定ツールを整備してこの指標の数値の信頼度を向上させる必要があります。
  LOC取得環境が整備されていれば最も使いやすい指標だと思います。是非とも活用することを検討してみてください。
• FP (Function Point): 実装する機能に基づいてシステム規模を数値化する、言わずと知れたFP法による規模の測定です。ISO/IEC 20926:2009で規格化されています。FP計測手法として、IFPUG法、COSMIC法、フルファンクションポイント法、フィーチャーポイント法、MarkⅡ法、NESMA概算法、SPR法などがあります。
  一番使われているIFPUB法によるFP計測の精度を向上させるには、設計仕様書が明確である必要があります。また更にFP計測を行うには工数もかかる。などもあり利用は簡単ではありません。しかしプログラムに実装される機能を一定の方法で数値化する事は、品質を測る上ではかなり有用な指標となります。

参考までにIFPUG法を使ったFPの計算手順は以下の通りです

1. 扱うデータを外部入力(EI）、外部出力(EO)、外部照会(EQ)、内部論理ファイル(ILF)、外部インタフェースファイル(EIF)の５つのタイプに分類する
2. 扱うデータごとに、「データ項目数」とそのデータに関連する「レコード種類数」を求め、それに従ってそのデータのファンクションの複雑さを３段階(低、中、高)に分ける
3. 各データに、ファンクションの複雑さに応じた重み係数を掛けて合計し、システム全体の未調整FPを求める
4. これまでの計算とは別に、対象とするシステムの特性を14の観点から０～５の６段階評価し、合計する(この合計値をXとする)
5. システム特性係数＝ 0.65 ＋X × 0.01 を計算する
6. FP ＝システム特性係数×未調整FP

• UCP (Use Case Point): 実装するユースケースから求めるポイントでシステム規模を計測する方法で、UML(Unified Modeling Language)で表されたシステムの機能的要求を利用します。
  既にUMLで開発するプロジェクトでは導入は比較的容易だと思います。過去の実績情報などが揃っている場合にUCPと他の指標と比較するなどで色々な角度から表すことができると面白いですね。
  • 作業の主体となるアクターとユースケースを洗い出し、アクターを利用してユースケースとアクターのインターフェースの複雑度を３段階(単純、普通、複雑)で評価します
  • インターフェースとユースケースのポイントを合計して「UUCP (Unadjusted Use Case Point): 未補正ユースケース・ポイント」とします
  • システムの技術的要因係数複雑度と，プロジェクトを取り巻く環境要因に関する複雑度(環境的な複雑度)を評価し、それをUUCPに反映しUCPを決定する
• 画面数、帳票数、ファイル数、バッチ数
  このまま画面の枚数などの数値ですが、画面や帳票に含まれる仕様の複雑度は表せていません。（ゆえにFP法などの利用が必要となる。）単なる表示だけの画面と、他画面/機能と連携したり、入力項目の多い画面や、データチェックが必要な項目の他にデザイン上の複雑さなどは、画面数だけでは表現できていません。指標の一つの参考には使用できるかもしれませんが、品質を説明するための指標としての使用は難しいと思います。しかし実際の見積の段階などで、画面数や帳票数から全体工数やFPの概算試算ができたりします[JUASレポート^※1]。実績値との差異などの比較対象や見積参考の利用など使えるシーンも多いので収集する事をお勧めします。

• 全体工数（人月）＝ 112.97 ＋ 0.81 × 画面数 + 0.42 × 帳票数
• FP ＝ 91.54 ＋ 13.41 × 画面数 ＋ 40.33 × 帳票数

• JFS (JUAS Function Scale): システムの規模を推定するためにJUASが独自に作成した指標。「画面数＋帳票数×2/3」で算出され、既存の見積もり方法に比べ簡易に規模を推計することができます。
  過去、私はこの指標を使った経験はありませんが指標となるものが何もない場合には参考としてみても良いかと思います。
• ストーリーポイント: 書籍『アジャイルな見積りと計画づくり ー 価値あるソフトウェアを育てる概念と技法』^※2では、「ストーリーポイントとは、ユーザーストーリーやフィーチャー、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような、ひとまとまりの作業に対してポイントを付ける。ポイントの数値そのものはあまり重要ではない。重要なのは、他の作業との相対値だ。2ポイントを付けられたストーリーは、1ポイントのストーリーの2倍の大きさであり、3ポイントのストーリーの3分の2の大きさとなる。 ストーリーポイントの数値は、ストーリー全体の規模をあらわす。ストーリーの規模を定義するための数式は存在しない。 ストーリーポイントによる見積りが示す値は、フィーチャーを実装するのに必要な作業、開発内容の複雑さ、開発に内在するリスクなどが渾然一体となったものである」と定義されています。
  アジャイル開発にてバックログにストーリーポイントを設定し、スプリントの中で作成できるストーリーポイントの合計をベロシティとして利用をしており、チームのスプリント工数＝ベロシティと理解することもできます。

ソフトウェア開発の作業に関わる指標など

レビューに関わる指標

レビューは、どの工程で何をレビューするのか。また何をもってレビューを完了とするのかを決めて実施する必要があります。ただ工程に組み込まれているからといって形式だけ実施しても意味はないでしょう。レビューによって得られる情報を説明します。

• レビュー回数、時間: レビューの実施回数、のべ時間です。ウォークスルーレビューなどは参加者の数だけレビュー時間(=工数)は増加します。例えば3人で3時間かけてレビューをすると、9人時のコストを消費します。「レビュー指摘のエラー修正コスト」と、「テストでバグとして修正されたコスト」が比較対象となり、「9人時」より大きなコストが削減されていれば良い訳です。レビューに時間をかけたから良いという事ではなく、「早期に問題を発見することでコスト削減に寄与する」ことが目的となります。
• レビュー対象規模: レビュー対象となるドキュメントをページ数で表すことが多かったですが、ここ最近はレビューの対象となるドキュメントもwikiだったり、NotionやMiroなどのSaaSで作成されることも増えておりページ数で表せない事も多くなりました。アジャイル開発では、機能単位でストーリーポイントを使うこともあります。
  「設計書」というドキュメントに囚われず、レビューの対象物の規模が適切に指標として利用できればよいと思います。指標を取得することが目的ではないのです。
• レビュー品質メトリクス: レビュー実施にて検出した指摘件数を利用して精度を測る指標です。
  • レビュー工数密度 =  レビュー時間 ÷ レビュー対象規模 (または規模) で算出します。
    短いとレビューの不足、長いとレビュー実施方法に課題があると推測されます。
  • レビュー指摘密度 = レビュー指摘数 ÷ レビュー対象規模 (または規模) で算出します。
    例えば、規模が大きいのにレビュー指摘数が少ない場合に、ドキュメントの品質が高いためなのか、レビュー実施で指摘ができていないのかを確認することで、再レビュー判断や後工程での品質予測に利用することができます。
  • レビュー指摘効率 ＝ レビュー指摘件数 ÷ レビュー時間 で算出します。
    レビュー工数に対してどれだけの指摘数の割合があるのかを示しています。レビュー指摘密度と合わせて判断することで、ドキュメント品質やレビュー実施方法の判定をすることができます。

テストに関わる指標

テストにより検出した不具合数は品質を測る上でQAエンジニアにとって非常に重要な要素・指標となります。ただ、いわゆるバグ情報だけではなくそれに属性や検出工程などが不可される事で深く分析することが可能になりますので、ここであらためて説明をします。

• テストケース数: 件数で表します。ケース数は内容の粒度によって件数のブレが生じる要因となります。ケースに記載するテスト観点(確認内容)の粒度で合わせることでブレはなくなるでしょう。
  開発プロセスで工程が明確に分けられている場合、テスト工程ごとに実行するテストケースが分かれていると思いますので、工程ごとにテストケース数を測定しましょう。それぞれ対象となる開発工程での品質を確認することにつながり、工程ごとに細かく対策を検討できるようになります。
• 不具合数、不具合起票数: いわゆるバグ数です。テスト実施中に検出したバグの数はプロジェクト内で管理されています。もし管理されていないならバグ起票の登録項目を含めたプロセスを作るチャンスです。後々の分析も考慮して作りましょう。
  こちらもテストケース数と同様に工程ごとに検出されたバグ数を計測しましょう。これでそれぞれの工程の分析はより完全なものに近づくでしょう。また起票数＝バグ数ではありません、またテストケース外で検出されるものもあります。これらの理由に品質改善の種が埋まっています。これを上手に使い改善に利用しましょう。
• 密度
  • テストケース密度 = テストケース数 ÷ 規模 で算出します。
  • 不具合密度 = 不具合数 ÷ 規模 で算出します。

上記の2つの指標により、開発システムの品質とテスト自体の品質も表すことができます。テスト密度が低く、不具合密度が高い場合に想定されるのは開発システムの品質に疑義がある状態になります。その逆はテスト密度が高く、不具合密度が高い場合はテスト自体の方法に問題がないかを確認する必要があると思います。

まとめ

プロジェクトに関わったQAエンジニアやプロダクトオーナー、プロジェクトマネージャーはこれらの定量的指標を上手く使って品質を説明できる様に、どれを使うのかを明確にして、指標の集計や収集を可能にしなければいけません。「品質が良くない」など漠然とした説明ではどこがどの様に良くないのか分かりません。何を改善するべきか分からないですね。定量的指標を知り、どう使うのかを考えてみてはいかがでしょうか。よりよいプロダクト開発のための一助となればと思います。

APPENDIX:参考資料

※1　一般社団法人 日本情報システム・ユーザー協会 ソフトウェアメトリックス

※2 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）