第7章　ソフトウェアの品質保証

Size: px

Start display at page:

Download "第7章　ソフトウェアの品質保証"

えのひろもり
6 years ago
Views:

1 第 7 章ソフトウェアの品質保証ソフトウェアの品質保証の内容ソフトウェアの品質とは何かという問題については既に第 5 章で述べたそれでは保証とは何か広辞苑第六版によれば保証とは大丈夫だ確かだとうけあうこととあるこれに従えばソフトウェアの品質保証とは今対象としているソフトウェアについてその品質を誰かが使用する人などに大丈夫だ確かだとうけあうことであることを意味しているそれではこれは誰がどのようにして行うのだろうかあるいはこんなことがそもそも可能なのだろうかこの章ではこういった立場からソフトウェアの品質保証の問題を考えてみたいソフトウェアを作るための作業の内容を定義した国際規格がある ISO/IEC 12207:2008 と呼ばれるものであるこれは JIS 化されて JIS X 0160:2012 になっている日本ではこの JIS 規格の他にこの国際規格を基に共通フレーム 2013 と呼ばれる別の標準が作られているこれらの規格では単にソフトウェアを作る作業だけでなくソフトウェア作りを支援する作業も併せて定義されているこの支援作業の中にソフトウェアの品質保証が含まれているこれによればソフトウェアの品質保証は次の3つの作業から構成される [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 ( 現在の最新の版は ISO 1 ISO 9001 のソフトウェア開発への摘要については第 39 章で述べる 2 開発のための CMMI については第 40 章で述べる 3 ISO/IEC については第 41 章で述べる ( なお現在 ISO と IEC はプロセスアセスメントの新しい規格群を ISO/IEC シリーズとして用意しているしかしこれら 61

2 /IEC :2004)[ISO04d] などがその組織の規格であっても良いように思えるプロセスの保証これまで何度かこの原稿の中でも述べたように現在あらゆる工業製品の品質保証のベースにある考え方は製品を作る作り方 ( プロセス ) が良ければその結果作られる製品の品質が良いとするものであるこの考え方は自動車やテレビ工作機械などに広く適用されるこの考え方をソフトウェアに摘要したものがここでいうプロセスの保証である何年か前に私がソフトウェアの品質保証について始めて学んだ時当時ソフトウェアの品質保証はこのプロセスの保証が全てだった少なくとも私はそう受け止めたこの考え方はその時の私にとって非常に斬新である意味で衝撃的だったソフトウェア工学の世界にかっては IEEE の用語集があった IEEE std (R2002) IEEE Standard Glossary of Software Engineering Terminology と呼ばれていたものだったそれが IEEE に加えて ISO と IEC も参画して ISO/IEC/IEEE 24765: 2010 という新しい国際規格になったその新しい規格では品質保証について最初に次のように記述されている [ISO10a] 1. 品種や製品が技術的な要求を満たすことについての適切な自信を持つために必要なシステマティックでかつ計画された全ての活動に関するパターン 2. 製品が開発されあるいは製造されるプロセスを評価するためにデザインされた一連の活動この部分はこの前の IEEE の規程から変更されていないその IEEE の規程は 1990 年に作られたものであるがここには製品の品質保証についての記述がないその時点でのプロセスの保証とは以下の 2つのことを同時に保証することで達成できるとしていた 1. 今品質の保証をしようとするソフトウェアを開発する組織 ( プロジェクトなど ) が持っているソフトウェア開発の基準書 / 手順書が品質の高いソフトウェアを開発する上で充分なものであること 2. ソフトウェアを開発している期間中その開発組織はその基準書 / 手順書に記載されている通りに作業を行っていたことこの方法でソフトウェアの品質を保証するチームはソフトウェアを開発する組織の外側にいて開発する人たちの作業を冷静に観察しているということになるこのようなチームを品質保証チームと呼んでいる品質保証チームについてはまた後で述べる私が始めてソフトウェアの品質保証を勉強した 1995 年頃と今とでこのプロセスの保証について変わったところは基準書 / 手順書についてである私が勉強した時はこの基準書 / 手順書は既に何らかの形で用意されているものというところからスタートした共通フレーム 2013 ではこの基準書 / 手順書は契約に従ったものであることと明記されている共通フレーム 2013 のベースである ISO/IEC 12207:2008(JIS X 0160:2012) はソフトウェア産業 / 会社の立場を念頭に置いて作られたという経緯があるのでここでは契約に基づいた品質保証契約の内容を満足する品質保証 ] という考え方が明確になっているのは当然といえる一般の企業の中に位置するソフトウェア部門を対象に考えた場合にはそのソフトウェアのユーザとなる組織との間で架空のあるいは明示されていない契約があるはまだ進行中の作業であるのでこの原稿では ISO/IEC のまま話を進める 62

3 と考えればよいいずれにせよソフトウェアの開発は何らかの契約に従うものという考え方がこの場合開発の根底にあるそしてそこで開発されるソフトウェアは契約ごとに異なる内容と性格のものであるからそのソフトウェアの内容と性格は契約の中に充分反映されているべきであるそしてソフトウェアの内容と性格ごとに開発の手順 ( プロセス ) が異なるべきであるあるいはある内容と性格のソフトウェアを開発するためにはそれに適した開発のプロセスがあるべきであるということがこの共通フレーム 2013 の考え方の背景にあることになる開発のための CMMI の中で定義されている品質保証 4ではプロセスの保証で使用する基準書 / 手順書はプロジェクトの開始時点にソフトウェアの品質保証チームが参画してそのプロジェクトの手順書を作成しあるいは別途その開発組織全体が持っている基準書 / 手順書をそのプロジェクト用に手直ししてそのプロジェクト専用の基準書 / 手順書を用意しそれに基づいて品質保証活動を行うと記されている [CMM10a] ここでの手順書/ 基準書についての考え方も共通フレーム 2013 と変わらない繰り返しになるがソフトウェアのプロセスはこれから開発しようとするソフトウェアの内容と性格を反映してそれぞれ異なるべきということになるプロジェクトごとにあるいは開発するソフトウェアごとにそこで開発しようとするソフトウェアの内容と性質を見て開発の手順や品質保証の作業などを修正することをテラーリングと呼ぶ日本語では修整という文字が使われるテラーリングはいうのは簡単だが適切に実行するのはたいへんに難しいしかしその考え方はたいへんに良く理解できる我々はソフトウェア開発のレベルを上げて必要に応じて適切にテラーリングができる状態に到達しておく必要があるもし手順書 / 基準書に記載されていないことが行われた場合はどうするかあるいは記載されていることが行われなかったらどうするかこの問題は開発のための CMMI の品質保証のプロセスの中で述べられている開発のための CMMI ではこの不一致を非遵守 ( ひじゅんしゅ英語では noncompliance という単語が使われている ) 事項と呼んでいるそしてこの事例が発見されると品質保証チームはまずプロジェクトのメンバーと協力してその解決を図るそれでも解決できない場合はその問題を解決できるレベルの管理者に通告して解決を図るとしているなお ISO/IEC 12207:2008(JIS X 0160:2012) と共通フレーム 2013 では品質保証の活動にそれ自身の支援ライフサイクルプロセスの中に位置づけされている検証妥当性確認共同レビュー監査問題解決の各プロセスに依存することが明記されている製品の保証製品の品質保証は例えば ISO/IEC TR で示されていたようなソフトウェアの品質に関わる測定項目を定義しあるいはその趣旨に基づいた項目を選定して顧客に納品する前にそれを測定して結果をユーザに提示するあるいはそれに基づいたテストケースを設定してテストを行うというのが 1つの考え方である 4 開発のための CMMI ではソフトウェアの品質保証はプロセスと成果物の品質保証プロセスの中で行う 5 ISO/IEC 9126 のシリーズは ISO/IEC シリーズの発行に伴い廃止されてしまった 63

4 共通フレーム 2013 ではここでも契約という言葉が表面に出ている開発するソフトウェアごとにその内容と性格が異なるのでその内容と性格に見合った測定項目を定義 / 選定しあるいはテストケースを設定してそれを契約の中に明記し測定やテストを実施するという考え方である開発のための CMMI では契約という言葉は使われていないが同じような考え方を取っているつまり開発のための CMMI ではプロジェクトの初期段階で評価する作業成果物と基準を定め顧客の納入前にこれらを評価するとしているただソフトウェアの場合最終製品が複雑な上実態が容易に目に見えるものではなくさらに限られた項目の測定やテストの実施だけで必要とするソフトウェアの幅広い品質全部を保証できるものではないということなどから製品の品質保証よりプロセスの品質保証の方がソフトウェアの品質保証として適切なように私には思えるその理由として開発のための CMMI ではプロセスの品質保証を製品の品質保証より先に記述してあり Encyclopedia of Software Engineering の品質保証の記述でもプロセスの品質基準の方がより丁寧に記述されていることをあげたい [MARC02] 積極的な品質保証と消極的な品質保証まだ品質保証チームの活動について記述していないが品質保証チームが受け身の立場で終始するような品質保証を消極的な品質保証逆に積極的に他のプロジェクトやチームの活動に参画してソフトウェアの品質を向上させる品質保証活動を積極的な品質保証と呼んでいる前述のプロセスの保証で述べた2 つのことを保証するだけの活動は消極的な品質保証の典型である一般に積極的な品質保証が消極的な品質保証に勝ることはいうまでもない品質保証チームの活動ソフトウェアの開発組織がソフトウェアの品質保証を行う場合にはこの品質保証チームを編成し機能させなければならない 6 この品質保証チームはソフトウェア開発組織を指揮している管理者より上位の管理者に直属し報告する形にするべきとアメリカ生まれの教科書には記述されている [JON96b] ソフトウェアの開発がぎりぎりの状態に至って品質を犠牲にしてスケジュールを守るかスケジュール遅れが発生しても品質を重視するかの選択を迫られたとき開発に責任を持っている普通の管理者 ( プロジェクトマネージャなど ) は品質を犠牲にしてスケジュールの方を取ることが一般的であるというところにこの記述の背景があるだから高い品質のソフトウェアを開発するためには開発に責任を持っている管理者より高いレベルの管理者に品質に関わる問題を報告し開発に責任を持つ管理者に適切な指示命令をしなければならないそうしなければ高い品質のソフトウェアを開発することはできないという考え方である品質保証チームの開発組織内での活動は多岐にわたるそれはこのチームを構成しているメンバーの人数レベル組織内での位置づけ管理者の支援状況などによって異なることになる最低限のこのチームの活動は繰り返しになるがプロセスの保証のところで述べたように以下の 2 つの事項を保証することである 6 ソフトウェア技術者の専門職化については第 46 章で述べる 64

5 1. 今品質の保証をしようとするソフトウェアを開発する組織 ( プロジェクトなど ) が持っているソフトウェア開発の基準書 / 手順書が高い品質のソフトウェアを開発する上で充分なものであること 2. ソフトウェアを開発している期間中その開発組織はその基準書 / 手順書に記載されている通りに作業を行っていたことこれが品質保証活動の出発点であり最低限の品質保証活動であるこれに加えて品質保証チームは以下のようなことを行うことができる以下のような事項が開発組織内で適切に行われていることを保証する全てのテストの計画が妥当なものでありその計画に基づいてテストが実施されていること使用されているツールや手法が適切なものであり正しく使用されていることエラー処理の手順が妥当であり問題への対応だけでなくその原因究明もなされていること品質について要員への教育を実施する品質についてのデータを測定し結果を分析する( 製品の保証を含む) 欠陥発生を予測するケイパースジョーンズ (Capers Jones) は品質保証チームの規模は全開発要員の 5% 程度が必要と述べている [JON96b] 確かにこれだけの数のレベルの高いメンバーがいればその活動はかなり多岐にわたりしかも内容が濃いことが期待できてその組織が作るソフトウェアの品質を高いものにすることができる一方チームの人数が少ないあるいはレベルが低いなどというようなことがあればこのチームの活動は限られたものにならざるを得ずその結果としてこの開発組織は充分な品質のソフトウェアを作ることができないかもしれないしかし問題はチームの規模やレベルだけにあるのではない仮に強力なチームがあってもその活動が制約されるようなことがあれば結果として高いレベルのソフトウェアを開発することが難しくなるポイントは開発組織の文化がこのような活動を受け入れるかどうかもっと一般的ないい方をすれば開発組織が本当に高い品質のソフトウェアを開発する必要性を認識しそれを実践しようとしているのかということにある開発組織の文化がこのようなものでない場合文化をこのように変え維持してゆくのはいうまでもなく管理者の責任であるこのことからソフトウェアの品質について管理者の責任はたいへんに重いソフトウェア品質保証活動の計画何もソフトウェア作りに限る話ではないがソフトウェア作りでは最初にこれから行おうとすることについてしっかりした計画を立てその計画のレビューまで行ってそれから実際に行動を起こすことを習慣にするべきとしているソフトウェアの品質保証活動を始めるに当たっての計画について IEEE に規格があるこの規格名を IEEE Std 730 TM というがこの規格の内容は記述するべき計画の推奨例である [IEEE14] 当然その計画の内容は現実に実施される品質保証活動の内容を正確に反映したものでなければならないそのためにここに記載されている内容をベースに適切に修整を行って自社に合ったものにしなければならない 65

6 再びソフトウェアの品質保証という言葉についてソフトウェアの品質保証という言葉は 3 つの意味で使われることがあるというその 3 つとは 1. ソフトウェアの品質を保証するという意味の素直な概念 2. 開発組織内のあるチームなどの名称 3. テストやレビューなどソフトウェアの品質を高めるための作業ケイパースジョーンズは 3の立場でこの言葉を使うのは間違いだと指摘している [JON96b] 私もこの考え方に賛同し先に述べた品質保証チームの活動にこれに関わるものを除外したテストやレビューなどソフトウェアの品質を高めるための直接の活動はやはりそのソフトウェアを開発しているプロジェクトの責任である 7 そのプロジェクトの活動を支援し結果としてプロジェクトが品質の高いソフトウェアの開発を実現することが品質保証チームの役割であり責任であると私も考えるからであるソフトウェアの品質保証の位置づけソフトウェアの品質保証の作業は ISO/IEC 12207:2008(JIS X 0160:2012) の国際規格の中では支援プロセスの1つとして位置づけされているまたそれを背景にした共通フレーム 2013 ではソフトウェアの品質保証は 2. 支援ライフサイクルプロセスの 2.3 品質保証プロセスとして位置づけされている [IPA13a] カーネギーメロン大学ソフトウェア工学研究所 (SEI:Software Engineering Institute) が設定した開発のための CMMI の段階表現ではソフトウェアの品質保証はレベル 2( 管理された ) でのプロセスに位置づけされている 8 [CMM10a] これらのことはソフトウェアの品質保証活動はソフトウェア工学全体の中で非常に基本的なものであることを意味しているソフトウェアの品質保証は可能か私がソフトウェアの品質保証という言葉を初めて聞いたのは私が一般企業のソフトウェア開発部門で働いていた時のことだったその時に私が反射的に考えたことはソフトウェアの品質など保証できるわけがないというものだった私が働いていた開発組織はソフトウェア危機のあらゆる症状で苦しんでいた CMM でいうレベル 1 の当時として普通の開発組織だった今私はその時の私の考えが間違いであったことを知っている必ずしも容易ではないけれどソフトウェアの品質を保証することはこれまで述べてきたように可能である今でも以前の私と同じような考えを持っている人がいればその考えを是非ここで改めてほしいそしてここで述べたようなソフトウェアの品質保証活動を通して品質の高いソフトウェアを開発してほしいそれを私は切望しているキィワード製品の保証プロセスの保証品質システムの保証開発のための CMMI 能力成熟度モデ 7 ソフトウェアのテストについては第 30 章と第 31 章でレビューについては第 18 章でそれぞれ述べる 8 既に記したことだが開発のための CMMI については第 40 章で述べる 66

7 ル統合品質保証チームテラーリング修整非遵守事項積極的な品質保証消極的な品質保証略語 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 年この資料は次の URL からダウンロードできる ( 確認日 :2017 年 ( 平成 29 年 )1 月 25 日 ) [IEEE14] IEEE Computer Society Standards Coordinating Committee, IEEE Standards for Software Quality Assurance Plans IEEE Std 730 TM -2014, IEEE, [IPA13a] 情報処理推進機構ソフトウェアエンジニアリングセンター編共通フレーム 2013 経営者業務部門が参画するシステム開発及び取引のためにソフトウェアライフサイクルプロセス共通フレーム 2013 オーム社平成 25 年. [ISO04d] 日本規格協会 ISO/IEC First edition Information technology Process assessment 情報技術 -プロセスアセスメント- Part 1: Concept and vocabulary 第 1 部 : 概念及び用語英和対訳版日本規格協会 [ISO10a] ISO/IEC/IEEE, System and software engineering Vocabulary-ISO/IEC/IEEE 24765:2010(E), ISO/IEC, [JIS12a] 日本工業標準調査会審議ソフトウェアライフサイクルプロセス JIS X (ISO/IEC 12207:2008) 日本規格協会平成 24 年. [JON96b] Capers Jones 著富野壽監訳ソフトウェア品質のガイドライン ( 株 ) 構造計画研究所 1999 年. [MARC02] John J. Marciniak Ed. Encyclopedia of Software Engineering Second Edition, John Wiley & Sons, (2004 年 ( 平成 16 年 )6 月 8 日初稿作成 ) (2007 年 ( 平成 19 年 )6 月 26 日一部修正 ) (2007 年 ( 平成 19 年 )8 月 30 日一部修正 ) 67

8 (2010 年 ( 平成 22 年 )7 月 15 日一部修正 ) (2014 年 ( 平成 26 年 )3 月 2 日一部修正 ) (2017 年 ( 平成 29 年 )1 月 5 日一部修正 ) 68

第39章　ISO 15504

第39章　ISO 15504 第 41 章 ISO/IEC 15504 ISO/IEC 15504 の経緯 ISO と IEC に開発のための CMMI(CMMI-DEV) によく似たプロセス改善のための規格群がある ISO/IEC 15504( 日本での JIS 規格は JIS X 0145) の規格群である 1 CMMI-DEV はアメリカ生まれだ 2 が ISO/IEC 15504 はヨーロッパ生まれで今でもヨーロッパで広く使われている

第7章 ソフトウェアの品質保証

第7章　ソフトウェアの品質保証