61
第
7 章 ソフトウェアの品質保証
ソフトウェアの品質保証の内容 「ソフトウェアの品質とは何か」という問題については、既に第5 章で述べた。それでは「保 証」とは何か。広辞苑第六版によれば、保証とは「大丈夫だ、確かだとうけあうこと」とある。 これに従えばソフトウェアの品質保証とは、「今対象としているソフトウェアについて、その品 質を誰かが使用する人などに大丈夫だ、確かだとうけあうこと」であることを意味している。 それではこれは、誰が、どのようにして行うのだろうか。あるいは、こんなことがそもそも可 能なのだろうか。この章ではこういった立場から、ソフトウェアの品質保証の問題を考えてみ たい。 ソフトウェアを作るための作業の内容を定義した国際規格がある。ISO／IEC 12207：2008 と呼ばれるものである。これはJIS 化されて、JIS X 0160：2012 になっている。日本ではこ のJIS 規格の他に、この国際規格を基に「共通フレーム 2013」と呼ばれる別の標準が作られて いる。これらの規格では、単にソフトウェアを作る作業だけでなく、ソフトウェア作りを支援 する作業も併せて定義されている。この支援作業の中に、「ソフトウェアの品質保証」が含まれ ている。これによれば、ソフトウェアの品質保証は次の３つの作業から構成される[IPA13a]。 1. 製品の保証 2. プロセスの保証 3. 品質システムの保証 「製品の保証」は、理解できる。それでは「プロセスの保証」や、「品質システムの保証」と は、何を意味するのだろうか。 まず、この段階での議論を最も簡単にすませることができる「品質システムの保証」から検 討を始めたい。 品質システムの保証 「共通フレーム2013」によれば、「品質システムの保証」とは、「ソフトウェアを開発する組 織がその品質管理活動を行う際、ISO 9001（現時点の規格は ISO 9001：2015、該当する JIS 規格はJIS Q 9001：2015）をその基準として適用すること」としている1。先でも述べたとお り共通フレーム2013 の大元は ISO／IEC 12207：2008 であるから、ここで同じ ISO 規格で あるISO 9001 をその品質活動の基準にあげていることは当然といえる。 ISO 9001 の目的は、これをベースにして企業内に優れた品質マネジメントシステムを構築・ 維持し、全てのステークホールダ（利害関係者）のニーズの実現に取り組むこと、特に顧客を 重視することである。この目的から、ISO 9001 の適用が品質保証の一部に組み込まれている ことはよく理解できる。 しかし私にいわせれば、ISO 9001 だけでなく、ISO 9001 と同じようにソフトウェアの品質 システムを作ることができる「開発のためのCMMI（Capability Maturity Model Integration-DEV：能力成熟度モデル統合）v-3[CMM10a]」2やISO／IEC 155043（現在の最新の版はISO
1 ISO 9001 のソフトウェア開発への摘要については、第 39 章で述べる。 2 「開発のための CMMI」については、第 40 章で述べる。
3 ISO／IEC 15504 については、第 41 章で述べる。（なお現在 ISO と IEC は、プロセスアセ
62 ／IEC 15504-1：2004）[ISO04d]などがその組織の規格であっても良いように思える。 プロセスの保証 これまで何度かこの原稿の中でも述べたように、現在あらゆる工業製品の品質保証のベース にある考え方は、「製品を作る作り方（プロセス）が良ければ、その結果作られる製品の品質が 良い」とするものである。この考え方は自動車やテレビ、工作機械などに広く適用される。こ の考え方をソフトウェアに摘要したものが、ここでいう「プロセスの保証」である。 何年か前に私がソフトウェアの品質保証について始めて学んだ時、当時ソフトウェアの品質 保証はこの「プロセスの保証」が全てだった。少なくとも私は、そう受け止めた。この考え方 はその時の私にとって、非常に斬新で、ある意味で衝撃的だった。 ソフトウェア工学の世界に、かっては IEEE の用語集があった。“IEEE std 610.12-1990(R2002)、IEEE Standard Glossary of Software Engineering Terminology”と呼ばれて いたものだった。それがIEEE に加えて ISO と IEC も参画して、ISO／IEC／IEEE 24765： 2010 という新しい国際規格になった。 その新しい規格では、「品質保証」について最初に次のように記述されている [ISO10a]。 1. 品種や製品が技術的な要求を満たすことについての適切な自信を持つために必要な、 システマティックで、かつ計画された全ての活動に関するパターン 2. 製品が開発され、あるいは製造されるプロセスを評価するためにデザインされた、一 連の活動 この部分は、この前のIEEE の規程から変更されていない。その IEEE の規程は 1990 年に 作られたものであるが、ここには「製品の品質保証」についての記述がない。 その時点での「プロセスの保証」とは、「以下の２つのことを同時に保証することで達成でき る」としていた。 1. 今品質の保証をしようとするソフトウェアを開発する組織（プロジェクト、など）が 持っているソフトウェア開発の基準書／手順書が、品質の高いソフトウェアを開発す る上で充分なものであること。 2. ソフトウェアを開発している期間中、その開発組織はその基準書／手順書に記載され ている通りに作業を行っていたこと。 この方法でソフトウェアの品質を保証するチームは、ソフトウェアを開発する組織の外側に いて、開発する人たちの作業を冷静に観察している、ということになる。このようなチームを 「品質保証チーム」と呼んでいる。品質保証チームについては、また後で述べる。 私が始めてソフトウェアの品質保証を勉強した 1995 年頃と今とでこの「プロセスの保証」 について変わったところは、基準書／手順書についてである。私が勉強した時は、この基準書 ／手順書は既に何らかの形で用意されているもの、というところからスタートした。 共通フレーム2013 では、この基準書／手順書は「契約に従ったものであること」と明記され ている。共通フレーム2013 のベースである ISO／IEC 12207：2008（JIS X 0160：2012）は ソフトウェア産業／会社の立場を念頭に置いて作られたという経緯があるので、ここでは「契 約に基づいた品質保証」、「契約の内容を満足する品質保証］という考え方が明確になっている のは当然といえる。一般の企業の中に位置するソフトウェア部門を対象に考えた場合には、そ のソフトウェアのユーザとなる組織との間で、架空の、あるいは明示されていない契約がある はまだ進行中の作業であるので、この原稿ではISO／IEC 15504 のまま話を進める。
63 と考えればよい。いずれにせよ、「ソフトウェアの開発は何らかの契約に従うもの」という考え 方が、この場合開発の根底にある。そしてそこで開発されるソフトウェアは契約ごとに異なる 内容と性格のものであるから、そのソフトウェアの内容と性格は契約の中に充分反映されてい るべきである。そして、「ソフトウェアの内容と性格ごとに、開発の手順（プロセス）が異なる べきである」、あるいは「ある内容と性格のソフトウェアを開発するためには、それに適した開 発のプロセスがあるべきである」ということが、この共通フレーム2013 の考え方の背景にあ ることになる。 「開発のためのCMMI」の中で定義されている品質保証4では、「プロセスの保証」で使用す る基準書／手順書は、「プロジェクトの開始時点に、ソフトウェアの品質保証チームが参画して そのプロジェクトの手順書を作成し、あるいは別途その開発組織全体が持っている基準書／手 順書をそのプロジェクト用に手直しして、そのプロジェクト専用の基準書／手順書を用意し、 それに基づいて品質保証活動を行う」と記されている[CMM10a]。ここでの手順書／基準書に ついての考え方も、共通フレーム2013 と変わらない。繰り返しになるが「ソフトウェアのプ ロセスは、これから開発しようとするソフトウェアの内容と性格を反映してそれぞれ異なるべ き」ということになる。 プロジェクトごとに、あるいは開発するソフトウェアごとに、そこで開発しようとするソフ トウェアの内容と性質を見て開発の手順や品質保証の作業などを修正することを、「テラーリ ング」と呼ぶ。日本語では、「修整」という文字が使われる。テラーリングは、いうのは簡単だ が、適切に実行するのはたいへんに難しい。しかしその考え方は、たいへんに良く理解できる。 我々はソフトウェア開発のレベルを上げて、必要に応じて適切にテラーリングができる状態に 到達しておく必要がある。 もし、手順書／基準書に記載されていないことが行われた場合はどうするか。あるいは、記 載されていることが行われなかったらどうするか。この問題は、「開発のための CMMI」の品 質保証のプロセスの中で述べられている。「開発のための CMMI」では、この不一致を「非遵 守（ひじゅんしゅ、英語では“noncompliance”という単語が使われている）事項」と呼んで いる。そしてこの事例が発見されると品質保証チームは、まず「プロジェクトのメンバーと協 力してその解決を図る。それでも解決できない場合は、その問題を解決できるレベルの管理者 に通告して解決を図る」としている。 なおISO／IEC 12207：2008（JIS X 0160：2012）と共通フレーム 2013 では、品質保証の 活動に、それ自身の支援ライフサイクルプロセスの中に位置づけされている検証、妥当性確認、 共同レビュー、監査、問題解決の各プロセスに依存することが明記されている。 製品の保証 製品の品質保証は、例えばISO／IEC TR 9126-2、-3、-45で示されていたようなソフトウェ アの品質に関わる測定項目を定義し、あるいはその趣旨に基づいた項目を選定して、顧客に納 品する前にそれを測定して結果をユーザに提示する、あるいはそれに基づいたテストケースを 設定してテストを行う、というのが１つの考え方である。 4 「開発のための CMMI」では、ソフトウェアの品質保証は「プロセスと成果物の品質保 証」プロセスの中で行う。 5 ISO／IEC 9126 のシリーズは、ISO／IEC 25000 シリーズの発行に伴い廃止されてしまっ た。
64 共通フレーム2013 では、ここでも「契約」という言葉が表面に出ている。開発するソフトウ ェアごとにその内容と性格が異なるので、その内容と性格に見合った測定項目を定義／選定し、 あるいはテストケースを設定して、それを契約の中に明記し、測定やテストを実施するという 考え方である。 「開発のためのCMMI」では「契約」という言葉は使われていないが、同じような考え方を 取っている。つまり「開発のためのCMMI」では、「プロジェクトの初期段階で、評価する作 業成果物と基準を定め、顧客の納入前にこれらを評価する」としている。 ただソフトウェアの場合、最終製品が複雑な上、実態が容易に目に見えるものではなく、さ らに限られた項目の測定やテストの実施だけで必要とするソフトウェアの幅広い品質全部を保 証できるものではないということなどから、「製品の品質保証」より「プロセスの品質保証」の 方が、ソフトウェアの品質保証として適切なように、私には思える。 その理由として、「開発のためのCMMI」では「プロセスの品質保証」を「製品の品質保証」 より先に記述してあり、「Encyclopedia of Software Engineering」の品質保証の記述でもプロ セスの品質基準の方がより丁寧に記述されていることをあげたい[MARC02]。 積極的な品質保証と消極的な品質保証 まだ品質保証チームの活動について記述していないが、品質保証チームが受け身の立場で終 始するような品質保証を「消極的な品質保証」、逆に積極的に他のプロジェクトやチームの活動 に参画してソフトウェアの品質を向上させる品質保証活動を「積極的な品質保証」と呼んでい る。前述の「プロセスの保証」で述べた２つのことを保証するだけの活動は、消極的な品質保 証の典型である。 一般に、積極的な品質保証が消極的な品質保証に勝ることは、いうまでもない。 品質保証チームの活動 ソフトウェアの開発組織がソフトウェアの品質保証を行う場合には、この「品質保証チーム」 を編成し、機能させなければならない6。 この品質保証チームは、ソフトウェア開発組織を指揮している管理者より上位の管理者に直 属し、報告する形にするべきと、アメリカ生まれの教科書には記述されている[JON96b]。ソフ トウェアの開発がぎりぎりの状態に至って、品質を犠牲にしてスケジュールを守るか、スケジ ュール遅れが発生しても品質を重視するかの選択を迫られたとき、開発に責任を持っている普 通の管理者（プロジェクト・マネージャ、など）は、品質を犠牲にしてスケジュールの方を取 ることが一般的であるというところに、この記述の背景がある。だから高い品質のソフトウェ アを開発するためには、開発に責任を持っている管理者より高いレベルの管理者に品質に関わ る問題を報告し、開発に責任を持つ管理者に適切な指示命令をしなければならない。そうしな ければ、高い品質のソフトウェアを開発することはできない、という考え方である。 品質保証チームの開発組織内での活動は、多岐にわたる。それはこのチームを構成している メンバーの人数、レベル、組織内での位置づけ、管理者の支援状況などによって異なることに なる。 最低限のこのチームの活動は、繰り返しになるが、プロセスの保証のところで述べたように、 以下の2 つの事項を保証することである。 6 ソフトウェア技術者の専門職化については、第 46 章で述べる。
65 1. 今品質の保証をしようとするソフトウェアを開発する組織（プロジェクト、など）が 持っているソフトウェア開発の基準書／手順書が、高い品質のソフトウェアを開発す る上で充分なものであること。 2. ソフトウェアを開発している期間中、その開発組織はその基準書／手順書に記載され ている通りに作業を行っていたこと。 これが品質保証活動の出発点であり、最低限の品質保証活動である。 これに加えて、品質保証チームは以下のようなことを行うことができる。 以下のような事項が開発組織内で、適切に行われていることを保証する。 全てのテストの計画が妥当なものであり、その計画に基づいてテストが実施され ていること。 使用されているツールや手法が適切なものであり、正しく使用されていること。 エラー処理の手順が妥当であり、問題への対応だけでなく、その原因究明もなさ れていること。 「品質」について、要員への教育を実施する。 「品質」についてのデータを測定し、結果を分析する（「製品の保証」を含む）。 欠陥発生を予測する。 ケイパース・ジョーンズ（Capers Jones）は、品質保証チームの規模は全開発要員の 5％程 度が必要と述べている[JON96b]。確かにこれだけの数のレベルの高いメンバーがいれば、その 活動はかなり多岐にわたり、しかも内容が濃いことが期待できて、その組織が作るソフトウェ アの品質を高いものにすることができる。 一方チームの人数が少ない、あるいはレベルが低い、などというようなことがあれば、この チームの活動は限られたものにならざるを得ず、その結果としてこの開発組織は充分な品質の ソフトウェアを作ることができないかもしれない。 しかし問題は、チームの規模やレベルだけにあるのではない。仮に強力なチームがあっても、 その活動が制約されるようなことがあれば、結果として高いレベルのソフトウェアを開発する ことが難しくなる。ポイントは、開発組織の文化がこのような活動を受け入れるかどうか、も っと一般的ないい方をすれば、開発組織が本当に高い品質のソフトウェアを開発する必要性を 認識し、それを実践しようとしているのか、ということにある。 開発組織の文化がこのようなものでない場合、文化をこのように変え、維持してゆくのは、 いうまでもなく管理者の責任である。このことから、ソフトウェアの品質について管理者の責 任はたいへんに重い。 ソフトウェア品質保証活動の計画 何もソフトウェア作りに限る話ではないが、ソフトウェア作りでは最初に、これから行おう とすることについてしっかりした計画を立て、その計画のレビューまで行って、それから実際 に行動を起こすことを習慣にするべきとしている。 ソフトウェアの品質保証活動を始めるに当たっての計画について、IEEE に規格がある。こ の規格名をIEEE Std 730TM-2014 というが、この規格の内容は、記述するべき計画の推奨例 である[IEEE14]。当然その計画の内容は、現実に実施される品質保証活動の内容を正確に反映 したものでなければならない。そのためにここに記載されている内容をベースに、適切に修整 を行って自社に合ったものにしなければならない。
66 再び「ソフトウェアの品質保証」という言葉について 「ソフトウェアの品質保証」という言葉は、3 つの意味で使われることがあるという。その 3 つとは、 1. 「ソフトウェアの品質を保証する」という意味の、素直な概念 2. 開発組織内の、あるチームなどの名称 3. テストやレビューなど、ソフトウェアの品質を高めるための作業 ケイパース・ジョーンズは、3 の立場でこの言葉を使うのは間違いだと指摘している[JON96b]。 私もこの考え方に賛同し、先に述べた「品質保証チームの活動」にこれに関わるものを除外 した。テストやレビューなどソフトウェアの品質を高めるための直接の活動は、やはりそのソ フトウェアを開発しているプロジェクトの責任である 7。そのプロジェクトの活動を支援し、 結果としてプロジェクトが品質の高いソフトウェアの開発を実現することが品質保証チームの 役割であり、責任であると私も考えるからである。 ソフトウェアの品質保証の位置づけ ソフトウェアの品質保証の作業は、ISO／IEC 12207：2008（JIS X 0160：2012）の国際規 格の中では「支援プロセス」の１つとして位置づけされている。またそれを背景にした共通フ レーム2013 では、ソフトウェアの品質保証は「2．支援ライフサイクルプロセス」の「2.3 品 質保証プロセス」として位置づけされている[IPA13a]。
カーネギー・メロン大学ソフトウェア工学研究所（SEI：Software Engineering Institute） が設定した「開発のためのCMMI」の段階表現では、ソフトウェアの品質保証はレベル 2（「管 理された」）でのプロセスに位置づけされている8[CMM10a]。 これらのことは、ソフトウェアの品質保証活動はソフトウェア工学全体の中で、非常に基本 的なものであることを意味している。 ソフトウェアの品質保証は可能か 私が「ソフトウェアの品質保証」という言葉を初めて聞いたのは、私が一般企業のソフトウ ェア開発部門で働いていた時のことだった。その時に私が反射的に考えたことは、「ソフトウェ アの品質など、保証できるわけがない」というものだった。私が働いていた開発組織は、ソフ トウェア危機のあらゆる症状で苦しんでいた、CMM でいうレベル 1 の、当時として「普通の」 開発組織だった。 今私は、その時の私の考えが間違いであったことを知っている。必ずしも容易ではないけれ ど、ソフトウェアの品質を保証することは、これまで述べてきたように可能である。今でも以 前の私と同じような考えを持っている人がいれば、その考えを是非ここで改めてほしい。そし て、ここで述べたようなソフトウェアの品質保証活動を通して、品質の高いソフトウェアを開 発してほしい。それを私は、切望している。 キィワード 製品の保証、プロセスの保証、品質システムの保証、開発のためのCMMI、能力成熟度モデ 7 ソフトウェアのテストについては第 30 章と第 31 章で、レビューについては第 18 章で、そ れぞれ述べる。 8 既に記したことだが、「開発のための CMMI」については第 40 章で述べる。
67
ル統合、品質保証チーム、テラーリング、修整、非遵守事項、積極的な品質保証、消極的な 品質保証
略語
CMMI：Capability Maturity Model Integration
人名
ケイパース・ジョーンズ（Capers Jones）
規格
ISO 9001：2015、JIS Q 9001：2015、CMMI-DEV v-3、ISO／IEC／IEEE 24765：2010、 ISO／IEC 12207：2008、JIS X 0160：2012
参考文献とリンク先
[CMM10a] CMMI 成果物チーム、「開発のためのCMMI® 1.3 版 CMMI-DEV, V1.23 CMU/SEI-2010-TR-033 ESC-TR-2010-033 より良い成果物のためのプロセス改善」、カ ーネギー・メロン大学ソフトウェア工学研究所、2010年 この資料は、次のURL からダウンロードできる（確認日：2017 年（平成 29 年）1 月 25 日）。 http://cmmiinstitute.com/resource/japanese-language-translation-of-cmmi-for-development-v1-3/
[IEEE14] IEEE Computer Society Standards Coordinating Committee, “IEEE Standards for Software Quality Assurance Plans IEEE Std 730TM-2014,” IEEE, 2014．
[IPA13a] 情報処理推進機構ソフトウェア・エンジニアリング・センター編、「共通フレーム2013 経営者、業務部門が参画するシステム開発及び取引のために ソフトウェアライフサイクル プロセス 共通フレーム 2013」、オーム社、平成 25 年．
[ISO04d] 日本規格協会、「ISO／IEC 15504-1 First edition 2004-11-1 Information technology – Process assessment – 情報技術－プロセスアセスメント－ Part 1： Concept and vocabulary 第 1 部：概念及び用語 英和対訳版」、日本規格協会、2004.
[ISO10a] ISO/IEC/IEEE, “System and software engineering – Vocabulary－ISO/IEC/IEEE 24765:2010(E),” ISO/IEC, 2010-12-15．
[JIS12a] 日本工業標準調査会審議、「ソフトウェアライフサイクルプロセス JIS X 0160-2012 （ISO／IEC 12207：2008）」、日本規格協会、平成 24 年．
[JON96b] Capers Jones 著、富野壽監訳、「ソフトウェア品質のガイドライン」、（株）構造計 画研究所、1999 年．
[MARC02] John J. Marciniak Ed. “Encyclopedia of Software Engineering Second Edition,” John Wiley & Sons, 2002．
（2004 年（平成 16 年）6 月 8 日 初稿作成） （2007 年（平成 19 年）6 月 26 日 一部修正） （2007 年（平成 19 年）8 月 30 日 一部修正）
68
（2010 年（平成 22 年）7 月 15 日 一部修正） （2014 年（平成 26 年）3 月 2 日 一部修正） （2017 年（平成 29 年）1 月 5 日 一部修正）
