ソフトウェア品質知識体系ガイド－SQuBOK^® Guideについて　第3回

SQuBOK^® 編集チーム

富士通株式会社　辰巳　敬三
株式会社NTTデータ　町田　欣史
日立情報通信エンジニアリング株式会社　池田　暁

■はじめに

前回(第2回)はSQuBOK^®ガイド第1章の「ソフトウェア品質の基本概念」を解説しました。SQuBOK^®ガイドでは第2章「ソフトウェア品質マネジメント」と続くのですが、このコーナーは新人を含めた初心者の方々を対象にしていますので、今回は一つ章をとばして、読者のみなさんにとってより身近な第3章「ソフトウェア品質技術」を解説します。第3章を理解した上で、次回の「ソフトウェア品質マネジメント」の解説を読んでいただくと、組織やプロジェクトの品質マネジメントと個々の品質技術の関係など全体的な理解を深めやすいと思います。

■「ソフトウェア品質技術」カテゴリの概要

「ソフトウェア品質技術」ではソフトウェア開発の各工程で適用できる技術を紹介しています。構成は、工程全体を通して活用される「メトリクス」の解説の後、第2章のサブカテゴリである「プロジェクト(個別)のソフトウェア品質マネジメント」の構成と対応させて「計画」「要求」「開発」「レビュー」「テスト」「品質分析・評価」「運用・保守」の各工程の技術解説となっています。
個々の技術はそれだけで一冊の書籍ができるほど解説が必要なので、SQuBOK^®ガイドでは、最低限知っていただきたい概要レベルの紹介にとどめていますが、詳細を解説した良書を参考文献として示していますので、より深く学びたい方はそちらを参照するとよいでしょう。それでも、第3章の「ソフトウェア品質技術」はかなりのページ数になっていますので、以降では各工程の技術に関して「ここがポイント!」というものに絞って解説していきます。

■メトリクス～見える化の要～

「測定できないものは制御できない」(デマルコ)と言われるように、ソフトウェアの品質をコントロールするためには測定作業が不可欠です。では、何をどのように測ればよいのでしょうか? ここで登場するのが「メトリクス」です。
読者のみなさんは「プログラム規模あたりの障害件数」という用語を聞いたことがありませんか。メトリクスは測定方法と尺度を合わせた概念です。規模の単位、測り方、障害集計方法などをきちんと定義すると、これが「プログラム規模あたりの障害件数」というメトリック（メトリクスの単数形）になります。
注意が必要なのは、品質のコントロールのためには，ソフトウェアそのものだけでなく，開発プロセスや開発基盤など品質に影響する要因の測定も大切だということです。この観点から、メトリクスもプロダクトメトリクスとプロセスメトリクスに分類され、さらにプロダクトメトリクスは品質メトリクスと規模メトリクスに分類されています。
適切なメトリクスを選定し、きちんと測定することでソフトウェアの品質を"見える化"することができます。つまり、メトリクスが見える化の要と言えます。メトリクスを使ってソフトウェアの品質を評価し、PDCAを回すことがソフトウェア開発を成功に導く鍵となります。

■品質計画～計画なくして成功なし～

みなさんは日々の生活の中で「計画」を立てることがあると思います。やりたいことをどのような段取りで実現するかということですね(たまには、計画を立てない行き当たりばったりの旅行というのもいいですが・・・)。目に見えないという特徴をもつソフトウェアの開発では、この「計画を立てる」ことが特に重要です。この中で品質に着目した計画を「品質計画」といいます。
ISO 9000では、品質計画は『品質目標を設定すること，並びにその品質目標を達成するために必要な運用プロセス及び関連する資源を規定することに焦点を合わせた品質マネジメントの一部』と定義されています。簡単に言うと、目標(やりたいこと)とそれを達成するための施策(段取り)をあらかじめ決めておくということです。
もう少し具体的に言うと、品質計画では次のような内容を検討し、文書化しておきます。
(1)品質方針・品質目標
(2)品質作り込み手段の計画(開発プロセス・基準・規約など)
(3)品質確認手段の計画(レビュー・テスト・検査・監査など)
(4)収集する指標(メトリクス)、評価基準
(5)各工程の合否判定基準
(6)必要な記録(客観的証拠)の保管
品質計画を明確にしておけば、実行段階では計画との差異を分析することにより、成功への道筋が見えてくるはずです。

■要求分析～要求を明確にしないと始まらない～

「要求分析」は文字通り開発するソフトウェアへの要求を分析して明確にする作業です。つくるべきものを明らかにするというと当たり前のように聞こえますが、これがなかなか難しいのです。SQuBOK^®ガイド第1版では「要求分析」のうち「品質要求定義」を解説していますが、品質については更に取り扱いが難しくなります。たとえば「使いやすさ」のように定量化が難しく主観的なものがあったり、同じ品質水準でもシステムや業界の違いにより許容されないことがあったりします。また、品質要求の間にはトレードオフ、つまり一方の要求を満たそうとするともう一方の要求が満たされなくなるといった関係のものもあります。
このようなことから、品質要求を定義するときには、ある目標を設定してその管理指標を用意することで客観性をもたせるようにすることが大切です。このときに使える技法として、SQuBOKガイドではGQM(Goal-Question-Metric)と品質機能展開を紹介しています。

■開発～品質は設計と工程で作り込め～

SQuBOK^®ガイド第1版では、設計や実装はスコープ外としましたが、「品質は設計と工程で作り込む」という品質マネジメントの基本はソフトウェア開発でも同じです。第2版では開発フェーズの品質技術を紹介する予定ですので期待してください。

■レビュー～レビューとは再び(re)見る(view)こと～

一般にソフトウェア開発工程全般で行われる見直し作業のことを一括りにしてレビューと呼んでいますが、レビューの目的や方法にはいろいろなものがあることに注意してください。たとえば、レビューの目的には、「組織やプロジェクトのマネジメント」「進捗状況の確認」「成果物の改善」「障害の除去」「関係者間の合意形成」「参加者の教育」などがあります。
「レビューの技法」知識領域では、これらのうちソフトウェア開発の成果物の障害を検出・除去し、ソフトウェアの信頼性を確保するためのレビュー技法を解説しています。レビュー技法は、レビューの進め方と具体的なレビュー観点の設定・確認手法から構成されますので、前者を「レビュー方法」、後者を「仕様・コードに基づいた技法」と「フォールトに基づいた技法」の副知識領域で解説しています。レビューと言った時に、ウォークスルーやインスペクションという技法が思い浮かぶかもしれませんが、これらは「レビュー方法」に分類されます。レビュー方法には、インスペクションのように進め方や参加者の役割が厳密に決まっているものから，アドホックレビューのように職場の同僚間で気軽に実施できるものまでいろいろありますので、目的に応じてレビュー方法を選択する必要があります。

■テスト～テストは最後の砦～

みなさんはブラックボックステストやホワイトボックステストというテスト技法の名称は聞いたことがあるのではないでしょうか。では、探索的テストやリスクベースドテストはどうでしょう？
テストは品質保証の最後の砦としていろいろな観点から確認していく使命をもっています。このため、これまでに多くのテスト技法が考案されてきました。では、いったいどのくらいの数があると思いますか？これがなんと120種類以上あるのです（ISTQBテスト技術者資格制度の標準用語集に現れる「xxテスト」という名称の数です）。SQuBOK^®ガイドでもかなりの数のテスト技法を紹介していますので、それらの整理は大変でしたが、最終的にはSWEBOK（ソフトウェアエンジニアリング基礎知識体系）に合わせた分類・整理を行い、読者のみなさんが混乱しないようにしています。
でも、これだけの種類のテスト技法があるとやはり困惑しますよね。
そういうときには「テスト技法の選択と組み合わせ」副知識領域を読んでみてください。この解説では『ソフトウェアテスト293の鉄則（Kaner、他(著)）』(日経BP社)を参考文献として、次の「テストを構成する五大要素」を紹介しています。
(1)テストの実施者（誰がテストをするか）
(2)網羅性（どの程度のテストを行うか）
(3)問題やリスク（発見したい問題やリスクは何か）
(4)作業内容（どのようなアプローチでテストするか）
(5)結果の判定方法。
この五大要素がテスト技法を選択する上で大いに参考になるはずです。

■品質分析・評価～兆候を見逃すな～

ソフトウェア開発の成功の鍵はPDCAサイクルをうまく回すことですが、このサイクルの核となるのがCheck（評価）です。評価では「データ、事実でものを言う」「データに語らせる」ことが大切です。そして、データに基づいて真の要因を解析することで適切なAction（改善）に結びつけることができます。
「品質分析・評価の技法」知識領域ではデータに語らせるための技法として、確率や統計を利用した「信頼性予測」、品質計画に対する進捗状況を把握する「品質進捗管理」、根本的な問題を発見するための「障害分析」、分析の目的にあった適切な解析を行う「データ解析・表現」の技法が解説されています。これらの技法を駆使して兆候を見逃すことなく、製品やプロセスにフィードバックしましょう。

■運用・保守～ソフトウェアも劣化する!?～

ハードウェアと異なりソフトウェアは物理的な実体がないため劣化しませんが、ソフトウェアにおいても時間経過に伴って発生する「劣化」に相当する事象があります。たとえば、ソフトウェアを長時間にわたって稼働し続けたことにより、メモリーリーク障害が顕在化して動作が遅くなったり、長い年月利用されるうちに開発当初の仕様が陳腐化、つまり時代遅れになったりすることが「劣化」にあたります。
「運用・保守の技法」知識領域では、運用段階での障害を未然に防止するための技法や、古くなったソフトウェア資産を作り変えたり、流用したりする際に利用できる技法を紹介しています。

■終わりに

今回は紙面の関係で「ソフトウェア品質技術」の個々の知識領域についてのポイント解説となりましたが、みなさんが個々の技法を現場で実践していくことで、より理解が深まると思います。是非、実践してみてください。詳細が知りたくなったときはSQuBOK^®ガイドの付録に参考文献の一覧がありますので活用してください。
次回はこのシリーズの最終回として、経営層から現場に至る全てのレイヤの品質マネジメントのアクティビティをまとめた「ソフトウェア品質マネジメント」を解説する予定です。