SQuBOKユーザー会の取り組みについて、これまで３回の記事をお届けしましたが、今回が最終回です。

前回までの内容を簡単に振り返ってみます。
本記事の１回目では、ソフトウェア品質に関する知見は非常に広くて深淵であることを、私の実体験を交えながら紹介しました。

本記事の２回目では、SQuBOKに記載されている事項を単に参照するだけでなく、ソフトウェア品質に関する知見を、SQuBOKユーザー会のメンバー達で集約・共有化していくことを提案しました。

• 新たに出された知見を整理し、体系付けるのに、SQuBOKを軸として利用する。
• 勉強会等で出された意見等を、その場限りでなく、一個の体系に記録し、蓄えていく。
• それらを使って、更に議論を深めていき、新たな知見を産み出していく。

本記事の３回目では、ソフトウェア品質に関わる「書籍」「論文」「記事」「規格」「トピック」をまとめていく指針を示し、そのインフラとしてGoogleドキュメントを活用することを示しました。

このような活動を行っていこうと考えた理由と、現在の活動状況を以降に記します。

SQuBOKには、大きく分けて二つの価値があると思います。

まず一つ目は、SQuBOKにはソフトウェア品質に関する知見が要約されていることです。
ソフトウェア品質管理で扱う事項は範囲が非常に広く、それらの内容を知るには様々な方面を調査しなければなりませんが、SQuBOKの該当する箇所を読めば、おおよそを把握できます。

二つ目は、SQuBOKではその事項に関する書籍やISO等の規格類を中心に、参考文献を厳選して紹介していることです。

SQuBOKの本文に記載されている内容は要約であるため、そのテーマの詳細を知るには文献を当たらなければなりませんが、巷では多数の書籍や情報で溢れていて、どれを読めば良いか分からなくなることがあります。　こんな時には、SQuBOKで紹介されている参考文献は良い道しるべになります。

SQuBOK自体も書籍ですので、掲載できる参考文献には限りがあります。よって、SQuBOKには厳選された参考文献が掲載されていますが、SQuBOKに掲載されているもの以外にも、当然ながら優れた文献がたくさんあります。また、SQuBOKが発刊された後にも、優れた文献が次々に出版されています。

書籍以外のwebや技術情報誌に掲載されている記事にも、有益なものがたくさんあります。

もう一つ重要なものとして、"論文"があります。
日本科学技術連盟（以降は"日科技連"と略記）では毎年、「ソフトウェア品質シンポジウム（SQiPシンポジウム）」を開催しています。ここでは各企業・団体で培われたノウハウなどを紹介する論文が活発に発表されています。

SQiPシンポジウム以外のシンポジウムや研究発表会でも、様々な問題・課題を解決するための新たな創意工夫、実践事例が報告されています。

これらは、もっとより広く認知され、共有されるべきだと思うのです。

本記事の筆者は、SQiPシンポジウムの企画・運営に５年ほど前から関わってきています。
毎年、有益な論文が発表されており、近年の論文は日科技連のwebサイトで一般公開しています。
これらの論文は、シンポジウムの開催期間中から直後にかけては巷で話題になるのですが、その後にはあまり広く読まれていないように感じます。これは非常にもったいない話であると思っています。

企業やプロジェクトは、程度の差はあれども何処もソフトウェア品質に関する問題・課題を抱えているものです。
中には、それら問題・課題に対して手立てを講じることもなく、同じような失敗を繰り返してしまい、問題意識は持っていながらも突破口が見出せない状態が長々と続いてしまっている組織もあるようです。

これら問題・課題に対する解決策のヒントは、従来から共有されている書籍や論文等で示されていることが多いものです。

これら解決策へのヒントに気づくことが出来ていれば、状況は全く違ったものになることでしょう。
先人が切り開いた知見を元に、自分の組織に合った形で解決策を適用し、更に新たな創意工夫を施して、それをソフトウェア業界で共有することが出来れば、産業全体の進化にも繋がっていくことになります。

ですから我々は、常に学び続ける姿勢を持ち続けなければならないのです。

上記ではSQiPシンポジウムの論文を例にしましたが、このようなことは日科技連の「SQiP研究会」にも当てはまります。
SQiP研究会は、一年間かけて研究活動を実施しています。このSQiP研究会の研究成果は、研究会内部に留まらず、webを通じて一般公開しています。この研究会の活動は1985年から継続して取り組まれているものであり、優れた研究成果が出されています。しかしもったいないことに、これらの研究成果が知られていないところも多いように思います。

書籍、記事、論文。これらをもっと広く認知して活用していくことが必要です。
こういった問題意識から、ソフトウェア品質に関する情報や知見を皆で持ち寄り、SQuBOKの樹形図を軸にして体系化する仕組みを構築しようと考えたのです。

私自身の感触ですが、ソフトウェア品質に関わるエンジニアは、組織の垣根を越えた交流が盛んで、横の繋がりが強いように思います。例えば、「SQiPコミュニティ」や「ソフトウェアテスト技術者交流会」等のコミュニティを母体に、各地域で自主的に、活発に勉強会等が催されています。私自身、このような勉強会や研究会活動をこれまで一生懸命にやってきましたが、その過程で多くの方々に育てていただいたと思っています。

このSQuBOKユーザー会の新しい活動を通じ，ソフトウェア品質に関わる者同士が組織の垣根を越えて交流し，意見交換・情報交換する過程で新たな気づきを得，それを共有することで，そこからまた新たな知見を産み出すことに繋がっていけばと願っています。

上記に記載している旨を、日科技連のフリーコミュニティである「SQiPコミュニティ」に案内を出し、賛同者を募ったところ、10名ほどの方からコンテンツ登録の意志を示していただきました。
2012年1月末現在、SQuBOKコレクションに登録されているコンテンツは、17個です。まだまだ絶対数が少ない状況です。

このコンテンツの登録・共有化を通じて、ソフトウェア品質に関わるエンジニア同士が盛んに交流し、活発に議論していくことも大きな狙いとしています。この流れを作り出し、少しずつ育てていきたいと思っています。

ここまで，SQuBOKユーザー会の新活動の狙いと現状を書いてきました。
この活動は賛同者を募りながら継続して取り組んでいきますが、SQiPシンポジウムの論文やSQiP研究会の研究成果は、その数はかなり多いので、有志による持ち寄り合いで紹介コンテンツを登録・蓄積するには、かなりの時間もかかりますし、漏れなく網羅することも難しいと考えています。
そこで、SQiP事業の成果物に関しては、計画的に役割分担して整理していくことを検討しています。

また、ソフトウェア品質に関わる者同士がよりコミュニケーションを取りやすいように、facebook等を活用することも検討しています。

上記の【現在の「SQiPコレクション」の状況】で説明したように、有志の間でアイディアを出しあい試行錯誤を始めたばかりです。 QualityOneの読者のなかで、コミュニケーションを活発にすることや、コミュニティでの情報交流に興味またはアイディアをお持ちの方は下記のSQiPコミュニティ事務局までご連絡をいただければ幸いです。

【連絡先】
財団法人日本科学技術連盟　教育推進部　第二課
SQiPコミュニティ事務局 E-mail ： sqip＠juse.or.jp

SQuBOKユーザー会の取り組みについて、これまで２回の記事を書いてきました。
今回の３回目の記事では具体的な取り組み方法を記していきますが、その前に，前回までを簡単に振り返っておきたいと思います。

SQuBOKには、今まで先人が切り開いてきた知見が体系的にまとめられています。
本記事の１回目では、ソフトウェア品質に関する知見は非常に広くて深淵であることを、私の実体験を交えながら紹介しました。

SQuBOKは、”樹形図”を軸にしてソフトウェア品質に関する知見が凝縮されてまとめられていますが、ソフトウェア品質に関する知見は常に進化し事例も積み重ねられて来ています。
本記事の２回目では、SQuBOKに記載されている事項を単に参照するだけでなく、ソフトウェア品質に関する知見をSQuBOKユーザー会のメンバー達で集約・共有化していくことを提案しました。

• 新たに出された知見を整理し体系付けるのに、SQuBOKを軸として利用する。
• 勉強会等で出された意見等を、その場限りでなく一個の体系に記録し、蓄えていく。
• それらを使って更に議論を深めていき、新たな知見を産み出していく。

具体的には、ソフトウェア品質に関わる「書籍」「論文」「記事」「規格」「トピック」をまとめていきたいと考えています。

SQuBOKには、今まで先人が切り開いてきた知見が体系的にまとめられています。
SQuBOKユーザー会を発足させた時には、これらの知見を蓄えたSQuBOKの活用の仕方を共有する、ということを目指していました。
つまり、今までのSQuBOKユーザー会は、色々な知見が書かれているSQuBOKをどう利用するか、という観点で捉えていました。

ソフトウェア品質に関する知見、事例は常に進化しています。
これらを、SQuBOKユーザー会で積極的に扱っていきたいと考えています。

• 新たに出された知見を整理し、体系付けるのに、SQuBOKを軸として利用する。
• 勉強会等で出された意見等を、その場限りでなく、一個の体系に記録し、蓄えていく。
• それらを使って、更に議論を深めていき、新たな知見を産み出していく。

提案したいことは、SQuBOKで整理されている樹形図を利用して関連事項を集約・充実させ、過程の中で議論をしていこうよ、というものです。

これらを行うには、internet上で何らかのインフラが必要と考えています。
どんなインフラか、その運用方法はどうか。　これらをSQuBOKユーザー会で議論していきたいと思っています。

SQuBOKでは「樹形図」を軸にして、ソフトウェア品質に関する知見を整理しています。

この樹形図は、SQuBOKでは目次として機能しています。
例えば、「第1章 ソフトウェア品質の基本概念」は、以下のように構成されています。

第1章 ソフトウェア品質の基本概念

1.1 KA：品質の概念
1.1.1 S－KA：品質の定義（品質の考え方の変遷）
1.1.1.1 T：品質の定義（Gerald M. Weinberg）
1.1.1.2 T：品質の定義（James Martin）
1.1.1.3 T：品質の定義（Joseph M. Juran）
1.1.1.4 T：品質の定義（Philip B. Crosby）
1.1.1.5 T：品質の定義（Roger S. Pressman）
1.1.1.6 T：品質の定義（Robert L. Glass）
1.1.1.7 T：品質の定義
1.1.1.8 T：品質の定義（IEEE Std 610）
1.1.1.9 T：品質の定義（ISO 9000）
1.1.1.10 T：品質の定義（ISO/IEC 25000）

このように、SQuBOKの樹形図は、最大４階層で構成されています。上記のそれぞれには「本文」「関連トピックス／知識領域」「参考文献」「関連文献」が記載されていて、ソフトウェア品質に関する知見が要約されています。

SQuBOKでソフトウェア品質に関する調べ物をする際には、樹形図で関連する箇所を探し、そこの「本文」に書かれている内容を読んで概要を理解し、更に詳細を知りたい時には「参考文献」に記載されている文献にあたる、といったことがされていると思います。

現在のSQuBOKの「参考文献」で紹介されているものは、「書籍」や、ISO・IEC・IEEE等の「規格」が中心です。
SQuBOKユーザー会では、これらSQuBOKからポイントされている「書籍」「規格」を更に充実化させると共に、更に加えて、ソフトウェア品質に関わる「記事」「論文」「トピック」といったものをも扱っていくことを考えています。

以下、詳細を記します。

「書籍」「規格」「記事」「論文」「トピック」と、SQuBOKユーザー会の新活動で扱う事項についてご説明してきました。

この活動を行うには、internet上で情報を蓄え、共有するための器（インフラ）が必要ですが、クラウドサービスを活用するよう、現在 準備を進めています。
この原稿を執筆しているのは8月1日ですが、この時点でinternet上のインフラ準備はほぼ整っており、まもなくSQiPコミュニティに案内を出せるところまで来ています。

次回のこの記事では、本取り組みをどのように実践しているか、報告出来ると思います。

なお、SQuBOKユーザー会にはどなたでもご参加いただけます。
SQuBOKユーザー会の詳細は以下に情報がありますので、興味をお持ちの方は是非ご参加ください。
お待ちしております。（SQuBOKユーザー会のwebサイトも、近々に公開する予定です。）

http://www.juse.or.jp/software/142/

皆さんは、SQuBOKをどのように使っているでしょうか。

「SQuBOKを傍らに置き、何か不明な点が出てきたらSQuBOKを取り出して調べ物をする」というように、多くの方はSQuBOKをソフトウェア品質に関する"辞書"として使っていることと思います。この使い方は非常に正しいと思います。
今やinternetで、ありとあらゆることが検索出来てしまいます。情報はまさに「無尽蔵」であり、そこから必要な情報だけを抜き取ることが難しくなってきています。SQuBOKは、ソフトウェア品質に関する重要な事柄の、そのエッセンスをギュッと凝縮してまとめられたものです。　何か調べ物をする際に、まずは「SQuBOK先生」に問うてみたら、大枠の情報が簡単に得られるものと思います。

SQuBOKは「ソフトウェア品質に関する重要な事柄の、そのエッセンスをギュッと凝縮してまとめられたもの」です。（この定義は私が勝手に作ったものです）
しかし当然のことながら、SQuBOKでソフトウェア品質の何から何まで、全てが得られるわけではありません。

話はここで本筋から一旦離れ、私の経験談に移ります。
私は現在、ソフトウェア品質に関する専門職にいますが、元々は組み込み系プログラマーでした。
私はプログラマー時代からテストが好きで、ボーリス・バイザーの「ソフトウェアテスト技法」を自腹で買って読んでいました。しかし当時は、ソフトウェアテストに関する本はこれくらいしか知りませんでした。
その後、ソフトウェア品質を専門にした職種に就き、最初にやらせていただいた仕事は、ソフトウェア品質システムの開発・維持・管理でした。ソフトウェア品質を専門としていながらも、その当時にしていた勉強と言えば、ISO9001やCMMに書かれている内容を理解したり、それに関連した情報を少しばかり仕入れる、こんなことくらいしか、やっていませんでした。

今思うと当時は、分野がごく限られた範囲内でしかなく、しかも勉強の量も全く足りていなかったと思います。

もう10年くらい前の話ですが、当時私は、CMMを自社の品質システムに取り込む仕事をしていました。自分なりにCMMの読み込みはしていましたが、知識・理解を深めるために、CMMそのものを一通りレクチャーする研修に参加しました。
その研修は私にとって、非常に新鮮に映りました。だって、その研修ではCMMの説明は少ししかされなかったのですから。
その研修の中心は、ソフトウェア品質・プロジェクト管理に関する説明であり、それぞれの内容をCMMに紐付けてレクチャーする、というスタイルが取られていました。　参考文献もたくさん紹介していただきました。
その研修を受講するまでは、私はソフトウェアエンジニアリングでどんな分野があり、どんな本があるのか、ほとんど知らない状態でいました。その研修をきっかけに、私はプロジェクト管理、テスト、レビュー、モチベーション等々、ソフトウェア品質管理に関連する本を、片っ端から貪るように読んでいきました。　仕事のために、勉強のために本を読んでいる、という感覚は、全くありませんでした。　自分は今まで何も知らないでいたことを恥じつつも、先人が切り開いてきた道を辿っていくことは、楽しくもあり、とにかく無我夢中でした。
色々と勉強していくうちに、一言でソフトウェア品質管理と言っても、為すべきことは非常に多岐に渡っていること、品質管理の仕事は、実に創造的な活動であることを知りました。

そんな取り組みを何年か続けたのですが、ソフトウェアエンジニアリングの全体がどうなっているか、ぼんやりとした輪郭が見えているようで見えていないようで、私の中ではまだ漠然としたままでいました。

そんな状態の時に、SQuBOKが出版されてきました。

SQuBOKは、よく設計された書籍だと思います。
SQuBOKの目次と言うべき「樹形図」により、ソフトウェア品質に関する知見が、体系的に、読みやすく、検索しやすく整理されていると思います。

私にとって、SQuBOKは辞書的な位置づけにもあります。
SQuBOKはその他にも、自分が今までどんなことをしてきて、まだ何が分かっていないのかを整理し、これから先は何に取り組むべきなのかを考える、”道しるべ”のような存在でいます。そういった意味で、まさに「ソフトウェア品質知識体系ガイド」というネーミングは言い得て妙であると思います。

特にソフトウェア品質技術者は、SQuBOKの隅から隅まで一通り目を通し、何処に何が書かれているかは、ちゃんと把握しておきましょう。　何か必要が生じた時には直ぐにSQuBOKで調べられるよう、備えになります。

SQuBOKはソフトウェア品質に関するエッセンスが書かれたものであり、ソフトウェア品質に関する知見へのガイドです。　当該項目に関する書籍や論文、規格などが丁寧に整理されています。

SQuBOKで紹介されているこれらのエッセンスをくみ取り、更に咀嚼するためには、SQuBOKで紹介されている文献等に当たる必要があるのです。

そういった意味で、SQuBOKは「ソフトウェア品質知識体系ガイド」と銘打たれてはいますが、この本を読み進めば、どこかに自動的に連れて行ってくれる類のガイドではありません。
これらの情報を使って、自分の仕事にどう活かすことが出来るか、それは読み手にかかっているのです。何でもそうですが、目的意識をちゃんと持っていなければ、道具は使いこなせないものです。

ソフトウェア品質に関する知見は、常に進化してきています。
世にある様々な研究発表会、シンポジウム等では、新たな創意工夫、実践事例が送り出され、共有されています。　新しい文献も、多々出版されてきています。　internet上では、SNSやML、BLOG等で、活発に意見交換されています。
SQuBOKにまとめられている内容は、日常的に拡大・進化してきているのです。

SQuBOKには、今まで先人が切り開いてきた知見が体系的にまとめられています。
SQuBOKユーザー会を発足させた時には、これら知見を蓄えたSQuBOKの活用の仕方を共有する、ということを目指していました。
つまり、今までのSQuBOKユーザー会は、色々な知見が書かれているSQuBOKをどう利用するか、という観点で捉えていました。

上述しているように、ソフトウェア品質に関する知見、事例は常に進化しています。
これを、SQuBOKユーザー会で積極的に扱っていきたいと考えています。

新たに出された知見を整理し、体系付けるのに、SQuBOKを軸として利用する。
勉強会等で出された意見等を、その場限りでなく、一個の体系に記録し、蓄えていく。
それらを使って、更に議論を深めていき、新たな知見を産み出していく。

これから提案したいのは、今までと目線を変えて、SQuBOKという体系を利用して、その内容を如何に充実させていくか、その充実化させる過程で議論をしていこうよ、というものです。

これらを行うには、internet上で何らかのインフラが必要と考えています。
どんなインフラか、その運用方法はどうか。　これらをSQuBOKユーザー会で議論していきたいと思っています。

次回の記事では、これらの活動結果がどうなったか、報告したいと思います。

以上

SQuBOKガイドには、ソフトウェア品質に関する非常に多くの情報が盛り込まれていますが、皆さんは、これらの情報をどのようにお使いでしょうか。今回は、SQuBOKガイドの使い方について、再度考えてみることにしましょう。

SQuBOKは、その名の通り、ソフトウェア品質に関する知識を体系化したものです。その体系を表したものが、SQuBOKガイドの序章にもある樹形図です。数多くあるソフトウェア開発の技術要素の中から、ソフトウェア品質に関連するものを選び出し、それらを分類、体系化したものをツリー状に表現しています。

この樹形図は、SQuBOK（ガイド）のオリジナルですが、樹形図以外の内容は、基本的には他の文献から知ることができる情報がほとんどです。こう書いてしまうと、SQuBOKガイドの価値が下がってしまうような気がするかもしれませんが、そんなことはありません。SQuBOKの目的の一つは「ソフトウェア品質に関する日本の暗黙知を形式知化する」ということです（ソフトウェア品質知識体系ガイド－SQuBOK Guide－ viiページ参照）。つまり、この「体系化したこと」と「他の文献の情報を集約したこと」こそが、SQuBOKガイドの大きな価値なのです。

SQuBOKガイドを読めば、ソフトウェア品質に関することが“ある程度は”理解できますが、さらに専門的な知識を得るためには、それだけでは足りません。SQuBOKガイドを入口として、さらに知識を広げていくことが必要になります。

身近な例で考えてみましょう。例えば、先ごろ行われたサッカーのアジア杯で日本代表が優勝したことでサッカーに興味を持った方が、より深くサッカーを知ろうと思ったら、どのようなことができるでしょう。

• ルールや戦術を知る（なぜ4-2-3-1のフォーメーションにしたの？）
• 過去の歴史を知る（過去のアジア杯の激闘、アジア杯の開催地ドーハの悲劇、など）
• 代表選手が所属するクラブチームを知る（あの選手はどのチーム？活躍してる？）

など、知識の幅は様々な方向にあります。

これをSQuBOKガイドに置き換えてみると（やや強引ですが）以下のようになります。

• 各知識領域やトピックスの定義、理論などを知る。
  →基本的な考え方を知って、応用に活かす。
• 各知識領域やトピックスのルーツを知る。
  →現在の技術が確立するまでの裏付けを知る。
• 各知識領域やトピックスの活用事例を知る。
  →本当に有効な技術かどうかを確認する。

これらを知る上で助けになるのが、SQuBOKガイドに記載されている参考文献、関連文献や、付録にある推奨書籍、規格、論文などです。SQuBOKガイドを、これらの文献へのポインタとして活用することは、SQuBOKガイドの有効な活用法の一つです。

それでは、文献を「書籍」「論文」「規格」の3つに分けて、それぞれの入手方法や特徴などについて見ていきましょう。

書籍は一般の方が最も入手しやすい文献でしょう。大型書店のコンピュータ書籍コーナーに行けば、ソフトウェア開発関連の多くの書籍（和書）が陳列されています。SQuBOKガイドの第1版が出版されてから約3年が経ちましたが、その間にも数多くの書籍が新たに出版されました。改訂中のSQuBOKガイドでは、新しい書籍を関連・参考文献に追加する際には、複数のSQuBOK策定部会メンバが読んだ上で、追加の可否を判断しています。従って、単に情報が新しくなったというだけではなく、読者の方にとって有益な書籍のみが掲載されます。

また、SQuBOKガイドに記載されている書籍の中には、絶版本や洋書など、入手が難しいものもあります。洋書はちょっと頑張ればオンライン書店などで手に入りますが、絶版本は古書店などでないと入手は難しいかもしれません。そのようなときは、図書館を利用するのもお勧めです。絶版になるような古い本にこそ、技術の真髄が書かれていることもありますので、より深い知識を得たい方は諦めずに探してみてください。

いわゆる学術論文は、研究をしている方でないとあまり接する機会はないかもしれませんが、最新の技術を知る、あるいは現在の技術のルーツを知る上では非常に有用な情報源です。

SQuBOKガイドの付録Dには、ソフトウェア品質に関係が深い論文として、以下の3つのシンポジウム、ジャーナルの表彰論文を掲載しています。

• ソフトウェア品質シンポジウム（日本科学技術連盟）
• 世界ソフトウェア品質会議（European Organization for Quality, American Society for Quality, 日本科学技術連盟）
• ジャーナル「品質」（品質管理学会）

これらの表彰論文は、発表、掲載された論文の中でも特に優れたものということで、代表として掲載していますが、実際には表彰論文以外にも多くの論文があります。また、上記以外にも、ソフトウェア開発やソフトウェア品質に関する論文は、情報処理学会や電子情報通信学会、IEEEなどにも多く投稿されています。これらの学会の論文は、学会に入会すれば（会員種別にもよりますが）、無料で入手できる場合が多いです 。また、入会しない場合でも、有料になりますが、論文を購入することもできます。

論文には、最後に必ず参考文献が掲載されています。論文は、ページ数が限られているために、参考文献で述べられていることは既知の事実として、根拠や詳細などは省略していることも多くあります。そのため、より正しい理解のためには、参考文献をさかのぼって見ていくことが必要になりますし、その中で新たな気づきが生まれることもあります。この参考文献の活用は書籍でも同様ですので、ぜひお試しください。

ISOやJISなどの規格は、名称は聞いたことはあっても、実際に現物を見たことがあるという方は少ないかもしれません。組織の品質保証部門などの方であれば、国際規格標準や業界標準に準拠するために参照することはあると思いますが、通常の開発に携わっている方にはなじみがないかもしれません。

例えば、ご自身の会社における開発標準があるとします。それが国際規格に準拠しているものとして提供されているのであれば、その開発標準を作った方は、国際規格を読んで、それを会社の特性に合わせて標準化したのだと思います。この場合、開発標準を見た方は、間接的に国際規格を参照していることになります。

しかし、国際規格に準拠しているとは言っても、加工されてしまったものを見ているわけです。好奇心の旺盛な方であれば、オリジナルの定義を知りたいと思うことでしょう。

ただ、この規格は非常に高額なので、個人で購入するのは難しいかもしれません。業務で必要ならば、その必要性を訴え、会社の予算を工面して購入を検討していただきたいのですが、それが無理であれば、国立国会図書館などで閲覧することもできます。いずれにせよ、ご興味のある方は、規格とは実際どんなものなのか、一度ご覧になることをお勧めします。

今回は、改訂の話から少しはずれて、SQuBOKガイドを元に、ソフトウェア品質に関する理解をより深めるためのテクニックについて紹介しました。 今回紹介した書籍、論文、規格といったものは、どんどんと更新、追加されています。新たなSQuBOKガイドでは、それらの最新情報を取り込んでブラッシュアップするのと同時に、「温故知新」の言葉通り、古典的でかつ現在の技術の基礎となる情報も大切にしながら改訂を進めています。

※2011年10月31日～11月4日に第5回世界ソフトウェア品質会議（5WCSQ）が上海で開催されます。
　ソフトウェア品質シンポジウムの発表論文は、日本科学技術連盟のWebサイトで公開されています。

http://www.juse.or.jp/software/29/

SQuBOK® ガイドの第1版が2007年11月に出版されてから約3年が経ち、この間にIT業界には様々な変化がありました。身近なところでは、iPhone 、Android携帯などのスマートフォンやiPad、Kindleなどの新たなデバイスの登場、Twitterという新たなコミュニケーション手段の流行、クラウドコンピューティングを使った新たなビジネスモデルの確立といったことがありました。このように、ITの技術は日々進歩しています。そして、それらの技術を使った製品やサービスの品質を確保するための技術や考え方も追従して変化していかなければなりません

SQuBOK® ガイドの目的の一つには、これまで日本で培われてきたソフトウェア品質に関する暗黙知を形式知化するというものがあります。これは普遍的なものであり、技術が進化しても変わることのない品質に対する考えになります。一方で、SQuBOK® ガイドのもう一つの目的として、ソフトウェア品質に関する最新のテーマを整理、体系化することがあります。従って、SQuBOK® ガイドは、新たな技術の登場に伴って変化するソフトウェア品質に関する情報を取り入れて、不定期に更新していく予定になっています。

2008年10月にはSQuBOK® ガイドのアメンドメントをWebで公開しました。ここでは、第1版では対応できなかったパブリックコメントへの対応や、参考文献や論文の最新化を行いました。それからさらに2年が経ち、このたびSQuBOK® 策定部会では、SQuBOK® ガイドのメジャーバージョンアップ（第2版）に向けて作業を開始しました。まだ改訂に向けた議論の途中段階ということもあり、確定の情報ではありませんが、検討している改訂内容の一部を紹介したいと思います。

SQuBOK® ガイドの第1版で扱えなかった領域として、ソフトウェア開発プロセスの上流から中流にあたる、要求分析、設計、実装の部分があります。これらの作業におけるマネジメントや技法については、SQuBOK® ガイド第1版の樹形図には含めていたものの、詳しい解説はペンディングとなっていました。次版では、これらの部分についての解説を含める予定です。これにより、ソフトウェア開発プロセスの全体がカバーされることになりますので、実装を担当するプログラマの方、アーキテクチャ設計を行うソフトウェアアーキテクトの方、要求分析を担当する要求アナリストやビジネスアナリストといった、これまでSQuBOKとはあまり縁のなかった方々にも興味をもっていただけることと思います。

ただ、これらの領域はSWEBOK（ソフトウェアエンジニアリング知識体系）でも知識体系として整理されており、内容に重複が出てしまうことを懸念しています。SQuBOK® ガイドは、SWEBOKを否定や排除するものではなく、その中からソフトウェア品質に関する要素を抽出したものです。従って、SQuBOK® ガイドでは、「品質」という視点で、これらの領域におけるマネジメントや技法について解説していく予定です。

• ※ iPhone、iPad はApple Inc.の商標です。その他本文中の製品名は各社及び商標権者の登録商標あるいは商標です。

SQuBOK® ガイドに記載されている技術や考え方は、業界での認知度もあり、ある程度成熟しているものが基本となっています。ただし、中にはやや新しめのキーワードをあえて載せているものもあります。たとえば「ディペンダビリティ」などはそれにあたるかもしれません。これは、SQuBOK® 策定部会として、ソフトウェア品質技術者や開発者の皆さんに知っておいていただきたいという思いが入っているものです。そういった一部の例外を除けば、目新しい技術などが世の中で一時的に流行しても、まだ技術として確立していないもの、現場に根付いていないものは掲載を見送ることがあります。

たとえばSQuBOK® ガイドの第1版にはトピックスとして「Vモデル」はありますが、「Wモデル」はありません。これは、第1版の執筆当時は「Wモデル」は認知度が徐々に高まりつつあるぐらいの段階であり、まだ開発現場では一般的でないという理由から、時期尚早ということで掲載を見送りました。しかし、この3年の間に「Wモデル」は（適用している、していないは別にして）かなり認知度が高まり、多くの文献にも当たり前のように記述されるようになったと感じています。従って、次版では「Wモデル」を新たなトピックスとして追加することが検討されています。このように、日々新しくなるソフトウェア開発の技術を取り込むことで、SQuBOK® ガイドの鮮度を保っていこうとしています。

SQuBOK® ガイドでは、付録としてISO、IECやIEEEなどの規格の一覧を掲載しています。それらの規格はトピックスとして解説されていたり、他のトピックスで参照されたりしています。国際標準や業界標準の規格に基づいていることは、SQuBOK® ガイドの記載内容の信頼性を高める一つの要因になっています。しかし、これらの規格は頻繁に改訂されたり、JIS化されたりしています。SQuBOK® ガイドの信頼性を確保するためには、これらの規格は最新のものを参照し、それに基づいた記述に改める必要があります。これも次版での改訂のポイントの一つです。

たとえば、テストドキュメントに関する規格であるIEEE Std 829は、SQuBOK® ガイド第1版では1998年版を参照していましたが、この規格は2008年に改訂されました。そこで、2008年に公開したSQuBOK® ガイドのアメンドメントでは、付録の規格一覧を更新し、さらにこの規格を解説、参照しているトピックスの解説文への影響を確認しました（影響はないということで解説文の変更はありませんでした）。今回のSQuBOK® ガイドの改訂にあたっても、改訂のあった規格を確認し、関連する解説文の見直しをする予定です。

今回取り上げた以外にも、SQuBOK® ガイド全体を通しての不整合の修正や、第1版で取りこぼしていた情報の追加、読者や有識者からの要望やコメントの反映などを行って、より充実したガイドに改訂する予定です。

改訂版の出版は来年2011年の1月頃を予定しております。是非お楽しみにしていてください。

• ※ iPhone、iPad はApple Inc.の商標です。その他本文中の製品名は各社及び商標権者の登録商標あるいは商標です。

連載４回目は，「ライフサイクルにおけるプロセス評価と改善」です．ソフトウェアライフサイクルにおけるプロセス評価と改善はどのような目的でどう行われるのか，ソフトウェアの品質を考える上でどのような意味を持つのかなどを，古河課長と熊川さん[第1回「本連載の進め方」]に語って貰います．

熊川さんは，課長に呼ばれて次の調査を命じられました．
「Y取締役が，『わが社のソフトウェアライフサイクルプロセスが，標準に概ね整合していることはよく分かった．しかしプロセスが規定されているだけでは絵に描いた餅だ．日々の仕事がプロセスどおりに行われ，期待される成果を上げているのか，継続的な改善を進めているのか，についても知りたい．』とおっしゃっている．熊川君，社内のプロセス評価と改善の現状を至急調査して改修すべき点があれば報告してくれ．」
熊川さんは，どう手をつけてよいか分からなかったので古河課長に聞きました．「課長，この仕事にどう取り組んだらよいか分かりません．私の今の知識と経験では手に負えそうにないのですが･･･．」古河課長は「一人で抱え込んだまま時間を無為に過ごしてしまわなくなったのは良いことだ．これは大きなテーマなので，少し長くなるが詳しく説明するからよく聞いてくれ．」と言って説明を始めました．
「ソフトウェアプロセスを評価する目的は，現状を体系的に把握して改善を進めることにある．そして結果として製品品質や開発効率を向上させるためだ．そのきっかけはざっくりいって2つある．一つは，実際に発生した品質問題を引き起こした根本原因を究明し，再発防止策を立案する過程でソフトウェアプロセスを評価する．もう一つは，ベストプラクティスの体系に照らしてプロセスを評価して，足りない部分を改善していく場合だ．この両方をバランスよく実施していくことが必要だ．」古河課長は本論に入って行きます．
「プロセス評価については，SQuBOK® の「2.3 プロセスアセスメント・プロセス改善のマネジメント」の記述と参考文献を参照すると全体のイメージがつかめる．また体系的なプロセス評価については，歴史的な背景を少し知っておくとよいだろう．(コラム参照)
代表的なプロセス評価モデルであるCMMIとISO/IEC15504には大きな違いがある．CMMIはソフトウェアのベストプラクティスで構成されるアセスメントモデルであり，業種固有の要件などを取り込むカスタマイズは認めていない．15504はそれ自体がアセスメントモデルではなく，アセスメントモデルとアセスメントを規定するメタモデルだ．その要件を満たせば自由に固有の要件を取り込んでいくことが可能なため，業界や業種ごとのアセスメントモデルが次々に開発されてきている．」
熊川さんはすぐに疑問が浮かんできました．「CMMIやISO/IEC 15504と，先日伺った『ISO/IEC 12207（JIS X 0160）ソフトウェアライフサイクルプロセス』や，これを下敷きにして日本独自に作成したモデルである『共通フレーム2007』（共に連載第2回を参照）とは，どのような関係になるのですか?」古河課長はうれしそうに答えました．「良い質問だ．ただ結論から言うと直接の関係はない．CMMIは独自に定義している固有ゴールと共通ゴールを達成しているかどうかに関心があるからだが，結果としてかなりの部分をそれらのプロセスモデルはカバーしている．ISO/IEC 15504はメタモデルだが，実はそこで想定されている標準的なプロセス参照モデルは，ISO/IEC 12207やISO/IEC 15288だ．だからこれまで作られたアセスメントモデル(コラム参照)の多くはISO/IEC 12207を下敷きにして，そこに業種固有の要件を反映している．」
最後に古河課長はこう締めくくりました．「『プロセス評価と改善』というテーマへのアプローチは選択肢が多い．君はまずそれらの選択肢を評価して，結果を報告したらどうだろうか?アプローチによっては，すぐに億単位の予算が必要になるからだ．」
熊川さんは「全体が何とか見えてきました．何か特に注意すべき事項はありますか?」と聞きました．古河課長は「『プロセス評価と改善』というテーマへ取り組む際の重要な留意事項が２つある．1つ目はよく言われる形骸化だ．これは会社の大きな無駄につながるので，なぜそうしたことが起きるのかを自分でよく考えながら進めてくれ．ポイントは，経営層から現場までが一貫して「プロセス改善を本気で進める」という意識を共有し続けることができるかどうかだ．現場が「上位層の本音は，手をかけずに形を整えることだ」と考えるとか，上位層が必要な予算を出し渋ると，言い訳材料ができて簡単に形骸化してしまう．2つ目は，改善は継続的であることだ．我々の仕事の外部環境(市場，顧客，競合･･･)も内部環境(組織体制，要員，能力，方針･･･)も常に変化しているので，仮にある時点で最適化を達成できたとしても，次の瞬間から最適ではなくなっているからだ．」と答えました．熊川さんはこの2つのポイントを肝に銘じながら調査に着手しました．

「ライフサイクルにおけるプロセス評価と改善からSQuBOK® を読み解く」シリーズは今回で終わりです．SQuBOK®はソフトウェア開発のいろいろな場面で活用できることを知っていただけたでしょうか．SQuBOK® には先人たちのさまざまな知恵がいっぱい詰まっています．ぜひ一度手にとってみてください

連載３回目は，「ライフサイクルと品質技術」です．品質技術には様々なものがあります．
ソフトウェアライフサイクルにおいて品質技術をどのように使えば良いのか，古河課長と熊川さん[">第1回「本連載の進め方」]に語って貰います．

熊川さんは，自社のソフトウェアライフサイクルプロセスが世の中の標準とどのように整合しているか，SQuBOK® を使って報告することができました．そんな，ちょっぴり鼻がぴくぴくしていた熊川さんですが，そんな時に古河課長に呼ばれました．
「熊川君，君もプロセスのことが大分わかって来たようだね．ところで今度，A社にソフトウェア開発を発注するのだが，発注仕様で要求すべき品質のレベルとそれを実現するための品質技術に関する要求をまとめてくれないか．」
「品質レベルですか？」
「そうだよ．製品とプロセスの具体的な指標を目標値として示してほしい．」

熊川さんは，またまた頭を抱えてしまいました．でも今までとちょっと違うのは，彼はSQuBOK® の使い方が分かってきたということです．
「課長，それはソフトウェアの測定や評価について要求をまとめるとういことですね．」
「そうだね．でもそれだけではなく，ソフトウェアの品質技術を考慮して，それに沿ったメトリクスとその具体的な基準,すなわち数値目標を決めて欲しい．」
「そういえば，前にB社に開発を依頼したときは，具体的な品質に関する目標を指示しなかったため，受入れ検査で不良が大量に発生し，結果として4週間も納期遅延して酷い目にあったな．そのうえ，稼動後も品質が不安定でお客様に大きな迷惑をかけてしまった．あんなことを二度と繰り返さないために，明確な品質レベルの要求が必須なのだな．」

SQuBOK® では，カテゴリ2のソフトウェア品質マネジメントにおいて，ソフトェアの開発工程に沿って"プロジェクトレベル（個別）のソフトウェア品質マネジメント（2.13～2.17）"として，その内容が解説されています．また，それに対応した形で品質技術が第3のカテゴリの"ソフトウェア品質技術"に記載されています．そこでは，ソフトウェア開発の各工程に対応した代表的な品質技術が取り上げられています．

熊川さんはSQuBOK® を開きながら，開発を依頼するシステムが必要とする品質レベルを基に品質要求仕様を作り始めました．
「品質計画，要求分析，レビュー，テスト，品質分析･評価,運用･保守の各工程のマネジメントと技法が掲載されているので，これらを活用してメトリクスを決めればよいな．」
熊川さん，まずはソフトウェア品質マネジメントの各知識エリアの内容を参考に，A社に要求すべき品質要求を検討することにしました．
「今回は品質計画，レビュー，テスト，品質分析･評価とそれらのメトリクスについて要求しよう．」
熊川さんは，品質要求として以下のようにまとめました．

1. 品質目標の設定
   具体的なメトリクと目標値は，参考文献の「TS X 0111-2第2部：JIS X 0129-1による外部測定法」を参考に信頼性や効率性のメトリクスを決めて要求する．具体的な目標値は自社の実績から決める．
2. 方針
   品質を作りこむために，どのようなプロセス，アーキテクチャ，基準等を採用するか方針を定めることを要求する．
3. レビュー
   レビュー計画では，レビューの詳細な実施方法は任せることにし，A社との共同のレビューはインスペクションを要求することにしました．レビューのメトリクスは，レビュー対象の規模当たりの不具合の摘出率とする．
4. テスト
   テスト計画では，同値分割や境界値テストの実施を要求しました．具体的な指標として，プログラム規模あたりのテスト項目件数，異常値テストの割合，プログラム規模あたりの不具合件数の目標値を自社の実績からを設定して要求する．
5. 報告
   それぞれの工程の完了時には計画通りに完了したことの報告を，最終的には総合的な品質の評価を提出してもらう．

ここまでまとめて，古河課長にみてもらいました．
「テストの進捗マネジメントの部分が欠けているな．SQuBOKのテスト進捗マネジメントを参考に，この要求に追加して欲しい．また，A社から納入されたソフトウェアの受け入れテストについても追加して欲しい．」
熊川さんは，テストカバレッジとテストの進捗と不具合の収束状況の管理を追記しました．また，納品されたソフトウェアの受け入れテストに関しては，新規システムなので全面的な支援を要求することにしました．

こうして熊川さんはSQuBOK® とその参考文献，自社の実績を使いながら，知恵を振り絞ってA社に要求する品質目標とそのレベルをまとめることができました．

次回は，それぞれのプロセスがうまく行われているかを確認する「ライフサイクルにおけるプロセス評価と改善」です．

連載２回目は，「ライフサイクルに関連する規格・標準」です．ソフトウェアライフサイクルの規格･標準はどのような目的で作られているのか，どう活用したらよいのか，ソフトウェアの品質を考える上でどのような意味を持つのかなどを，古河課長と熊川さんに語って貰います．

熊川さんは，昨日から頭を抱えています．部長と課長に呼ばれて次の調査を命じられたのですが，どう手をつけてよいか分からないからです．
「Y取締役が，『うちのソフトウェアライフサイクルプロセスは，世の中の標準に整合しているのかどうかを至急報告してくれ．海外生産を一気に立ち上げることが決まったので，海外新工場のIT要員とも間違いの無いようにコミュニケーションできないと困るし，現地ITベンダーとも同じだ．』とおっしゃっている．熊川君，社内プロセスを大至急調査して報告してくれ．」
熊川さんの考え込んでしまっている様子を見て，古河課長が声をかけてきました．
「熊川君，調査を始めたかね？」
「それがそもそも『世の中の標準』が何なのかよく分からなくて困っています･･･」
古河課長は苦笑しながら話し始めました．
「ライフサイクルという言葉はいろいろな分野で使われていて，たとえばマーケティング分野では製品ライフサイクルとして，導入期，成長期，成熟期，衰退期，の4段階を経るS字カーブとして描かれる．セーフティ･クリティカル・システムと呼ばれる安全重視の製品では，製品構想から廃棄に至るまでのセーフティ･クリティカル・ライフサイクルモデルと呼ばれるライフサイクル全てにおいて安全性確保が求められて，機能安全規格がIEC（国際電気標準会議）で定められている．ソフトウェアについてもライフサイクルとして語られるモデルは実は結構多いので，まず２種類に分けてみよう．」

　「1つには，開発方法論によらず中立的に作られたソフトウェアライフサイクルモデルがある．これは，ソフトウェアを企画し，要求と要件を定義し，設計し，プログラミングし，テストし，運用･保守し，廃棄するまでの活動を網羅的に示したものだ．その代表的なものが『ISO/IEC 12207（JIS X 0160）ソフトウェアライフサイクルプロセス』で，最新版は2008年に出ている．対象をソフトウェアからシステムに範囲を広げた規格には『ISO/IEC 15288（JIS X 0170） システムライフサイクルプロセス』がある．関連規格としては12207の保守プロセス部分を詳細化した『ISO/IEC 14764（JIS X0161） ソフトウェアライフサイクルプロセス－保守』等がある．さらに国際標準を下敷きにして日本独自に作成したモデルに『共通フレーム2007』がある．」
「標準と冠がついているモデルのグループですね．もう一つのモデルはどういうものですか？」
「もう一つは反復型やウォーターフォール型等の各種開発方法論やCMMI等のアセスメントに対応したプロセスモデルのことだ．これらもライフサイクルをカバーしていることから，ライフサイクルモデルと呼ばれているけれど，それぞれの目的に即したモデルなので今回は調査対象外だね．」
「世の中の標準というと，今回の場合は前者のモデルですね．前者のソフトウェアライフサイクルプロセスの国際標準や日本の共通フレーム2007は，一体何のために作られたのでしょうか？」
「いい質問だ．その目的は，ソフトウェア開発や運用･保守において発注者や受注者など関係者に，①共通の言語，および②役割を含む共通の開発マップ，を提供するという2点に集約できる．」
「はい．」
「君も知っているようにソフトウェア開発取引の世界では，責任分担や範囲が曖昧でトラブルが生じる，発注内容の品質･機能などの理解が食い違って仕様変更と手戻りが多発する，などの問題が発注者と受注者の間に絶えない．その一方でソフトウェアビジネスはグローバル化が一気に進んでいて，中国やインドで，開発のみならず運用･保守まで行われることも現実になってきている．このままではソフトウェア取引の混乱はますます深刻になりかねない．だから共通言語や標準のライフサイクルモデルが近年注目を集めている．」
「そういうことでしたか．ではITベンダーやITユーザは皆この標準をそのまま社内用語や社内プロセスに取り込むことが期待されているのですか？」
「いやそこまでは期待されていないし，そのような実例もほとんど存在しない．そもそも社内用語や社内プロセスは長い歴史を経てきていることが多いし，メインフレームからの歴史がある組織ならなおさらだ．期待されるのは，社内用語や社内プロセスと標準の間のマッピングができていることだ．これができていると，社内用語や社内プロセスが異なる複数の組織間でも正確に意思疎通できる．もう一つの効用は，社内用語や社内プロセスが異なる組織同士が対話しようとすると力関係が表に出て，一方が他方に合わせる形になりがちだが，これも回避できる．」
「ITベンダーと協力会社の間も同じでしょうね？」
「その通り．特に海外発注であるオフショア開発はコミュニケーションのリスクが高いので要注意だ．国内外共に言えることだが，注意すべきは表面的な用語のずればかりを気にするのでは不十分であるということだ．意味する本質的な内容にずれが生じていないか，お互いに絶えず気を配ることが肝心だ．」
「形式的なことだけで無く，内実にも注意を払うということですね．」
「あうんの呼吸で・・・，というコミュニケーション方法は人間の機微を踏まえたやり方で，これができる人間関係というのはすばらしいと思う．ただこの方法は，共通の社会文化基盤，人間性まで含めた深い信頼関係，を共有していることが前提になる．今のグローバル化したビジネス環境ではとても難しいことは明らかだ．行き違いが生じたときの双方のダメージの例は，君もいくつか思い当たるだろう．」

「そういえば去年夏にA社の担当SEのZさんは，画面インターフェース設計要件の誤解をエンドユーザテストで大量に指摘されて，夏休みが吹っ飛んでいました．」
「夏休みが吹っ飛ぶのもつらいが，仕様の行き違いが基で会社が大損害を出してしまい，合併に追い込まれたケースが最近話題になったね．ソフトウェアライフサイクルの話はここまでにしておこう．
ところで熊川君，君は職場で中堅といわれる立場に近付いているのだから，調査報告はすぐにできないと困る．ソフトウェア品質とその関連事項であれば，まずSQuBOK® ガイドに当たるのが定石だ．
今回の調査なら，

1. SQuBOK® ガイドの『２．２　KA：ライフサイクルプロセスのマネジメント』を読んで概要と参考文献を把握する，
2. 必要に応じて参考文献を読んで詳細情報を得る，
3. 評価基準あるいは参照モデルを決める，
4. 自社プロセスを評価する，
5. 報告書を作成してレビューを受ける，
6. 報告する，

という手順になるだろう．ちなみに今回の評価のための参照モデルはISO/IEC12207：2008が適切だと思う．SQuBOK® ガイドの該当ページに直行できないときは，目次，樹形図，索引を利用して該当ページを探すとよい．SQuBOK® ガイドはソフトウェア品質に関する知識・知見の体系に対する最新ガイドとして作られているから，今回のような場合にとても役に立つよ．」
「はい，分かりました．」

というわけで、熊川さんは調査にとりかかり，無事報告をすることができました．

次回は、「ライフサイクルと品質技術」についてです．

これから4回に渡って，SQuBOK® のポイント解説ということで重要な語句や難解な知識の説明をします．SQuBOK® は，ソフトウェア品質に関する日本の暗黙知を形式知化したものであり，またソフトウェア品質に関する最新のテーマを整理し，体系化したものです．既にご存知かも知れませんが，SQuBOK® はソフトウェア品質に関する知識を「SQuBOK® 樹形図」として体系化しています．この樹形図は，知識を3つのカテゴリ「1.ソフトウェア品質の基本概念」「2.ソフトウェア品質マネジメント」「3.ソフトウェア品質技術」に分けています．Vol.3～6の連載では，これらのカテゴリに関して説明をしました．
本連載では，これらのカテゴリで記述されている知識をソフトウェアライフサイクルという視点を通じて考えてみたいと思います．ソフトウェアは，企画，開発，運用・保守という期間を経て，最後は廃棄されます．ソフトウェアエンジニアは，ソフトウェアのライフサイクルに渡ってさまざまな活動を実施します．そのライフサイクルにおける活動で，SQuBOK® に記述されているソフトウェア品質の知識を利用して，ソフトウェア製品の品質を社会，顧客，利用者の期待するレベルに維持する一助としていただきたいと思い，本連載を進めます．

この連載には，二人の人物が登場します．ソフトウェア品質のご意見番ともいえる，ご隠居こと古河課長とソフトウェア品質保証の担当者で，元気はあるけれど，よく失敗する熊さんこと熊川さんです．この二人にSQuBOK® のポイントとなる知識を語って貰うことにしましょう．

本連載は次のように進めていきたいと思います．

• ソフトウェアのライフサイクルとは
• ライフサイクルに関連する規格・標準
• ライフサイクルと品質技術
• ライフサイクルにおけるプロセス評価と改善

今回は，「ソフトウェアのライフサイクルとは」ということで，まずはソフトウェアライフサイクルとは，どういったものなのか，ソフトウェアの品質を考える上でどのような意味を持つのか，二人の人物にさっそく語って貰います．

熊川さんは，朝から悩んでいます．
「うーん，ソフトウェアって，いろいろな開発方法があるし，開発した後は保守もあるし，ドキュメントの管理もあるなあ．また，いろいろな問題の解決もしないといけないし，なんだか複雑に入り組んでいて，全体をどうやって考えればいいのだろう」
そんな熊川さんをみていたご意見番の古河課長，
「ソフトウェアライフサイクルって言葉を知っている？」
と後ろにSQuBOK® ガイドを持ちながら熊川さんに聞いてみました．
「課長，何ですか？ ソフトウェアライフサイクルって？」
「ソフトウェアの企画・開発から保守を経て破棄されるまでの期間をソフトウェアライフサイクルと言うんだよ．ソフトウェアの開発や保守には，いろいろなプロセスがあるだろ？だから，それに適したプロセスを選択する必要があるんだ．SQuBOK® にもライフサイクルプロセスのマネジメントが記述されているよ」
と言って，課長は後ろに持っていたSQuBOK® を熊川さんに渡しました．
「ソフトウェアのプロセスをライフサイクルモデルで整理すると，自分たちに足りないプロセスや知識がはっきりするんですね」
目から鱗が少し落ちたような顔をしていた熊川さんをみて，課長は
「それでは，ライフサイクルを通じてソフトウェアの品質に関係するキーワードや知識をSQuBOK® を使って少し説明しようか？」．
熊川さんは古河課長からの思わぬ言葉に嬉しそうにうなずきました．

ソフトウェアの開発や保守には，さまざまなプロセスが複雑に関連します．プロセスとは，「入力を出力に変換するアクティビティやタスクの集合」と定義できます．もちろん，プロセスを実行するためには様々な知識や技術が必要です．ソフトウェアの開発が，複雑化，多様化，グローバル化というキーワードで表される今日において，ソフトウェアのプロセスを共通の言葉やモデルで記述，定義することはますます重要となります．例えば，複数の会社でソフトウェアを開発する場合，別の会社にソフトウェア開発を委託する場合，海外のエンジニアと一緒にソフトウェアの開発を行う場合など，ソフトウェアのライフサイクルに関する共通のモデルや言葉がなければ，スムーズな開発を行うことはできません．ライフサイクルの一連のプロセスの理解や記述は，ソフトウェアの品質向上を考える上で重要なポイントです．
ソフトウェアのライフサイクルに関する知識は，ライフサイクルモデルやプロセスモデルとしてSQuBOK® に記述されています．私たちがよく耳にするウォータフォールモデルは，プロセスモデルの1つです．その他にもスパイラルモデルやアジャイルモデルなど様々なプロセスモデルがあります．プロセスモデルは，ソフトウェアの開発工程や手順など，ソフトウェア開発の本質的な部分を取り出して表現したものです．どんなプロセスモデルを用いてソフトウェアの開発を行うのか，それによって実施する作業や作成する成果物が異なります．それぞれのプロセスモデルには長所、短所があります。実際の開発に適したプロセスを定義して、適用してください．ここで注意しなければいけないのは，各モデルの特徴をきちんと理解することです．

「フーン、なるほど!?　ライフサイクルモデルやプロセスモデルを利用して，自分たちに適したプロセスを定義して活用すれば，やるべきことの漏れが防げて，手戻りの削減や品質向上につなげることができるんですね．でもプロセスってどんなものがあるのかな．もう少し具体的な内容を知りたいナ……」と熊川さん．

そういうわけで、次回は，ライフサイクルプロセスに関連する規格や標準の説明をすることにします．

前々回(第2回)と前回(第3回)で、SQuBOK® ガイドの第1章「ソフトウェア品質の基本概念」と第3章「ソフトウェア品質技術」について解説しました。最終回となる今回は第2章の「ソフトウェア品質マネジメント」について解説します。
このコーナーは新人を含めた初心者の方々を対象にしていますので、「マネジメント」と聞いてもピンとこない方も多いかもしれません。それもそのはずで、マネジメントは一般的にはマネージャ、つまり管理者が行うものです。今はマネジメントされる立場にある読者の方が多いと思いますが、今の自分の作業がどのような目的で、どのようにマネジメントされているのかを知るために、そしていずれ自分自身がマネジメントするべき立場となったときのために、その全体像と概略を理解しておきましょう。

この「ソフトウェア品質マネジメント」カテゴリは、他の2つのカテゴリと構成が異なっており、カテゴリの下に副カテゴリがあります。これは、一口に「ソフトウェア品質マネジメント」と言ってもいくつかのレベルがあるためです。ソフトウェア品質マネジメントは、まず「組織」と「プロジェクト」という視点で分類され、さらにプロジェクトの中でも工程に依存するかしないかという視点で分類されます。ソフトウェア品質マネジメントというのは、それだけ多岐にわたるものだということがこれだけでもお分かりいただけるでしょう。SQuBOK® ガイドでは、この分類（レベル）に沿って以下の3つの副カテゴリを設けています。

1. 組織レベルのソフトウェア品質マネジメント
   組織内で共通、あるいは組織全体を対象としたアクティビティ
2. プロジェクトレベル（共通）のソフトウェア品質マネジメント
   プロジェクトで遂行されるアクティビティのうち、工程に依存せずライフサイクルを通して遂行されるアクティビティ
3. プロジェクトレベル（個別）のソフトウェア品質マネジメント
   プロジェクトで遂行されるアクティビティのうち、工程に応じて遂行されるアクティビティ

以降では副カテゴリ別に、それぞれのポイントを見ていくことにしましょう。

「マネジメント」と聞くと、プロジェクトの中で行われるものという印象を持たれる方が多いかもしれませんが、企業全体や企業の中のある部門といった組織のレベルでの品質マネジメントというものがあります。

企業に勤務されている皆さんの中には「QCサークル活動」に取り組んだことのある方も多いのではないでしょうか。「QCサークル活動」自体はソフトウェア開発に特化したものではなく、製造業などで先に始められて成果を挙げていたため、ソフトウェア開発にも取り入れられたものです。SQuBOK® ガイドでは「ソフトウェア品質推進活動」副知識領域の「QCサークル」というトピックスでその活動方法に関する説明があります。組織のトップマネジメントにより方向付けされた品質活動やこの「QCサークル」のような現場中心の活動によって、組織として品質をマネジメントする仕組みを「品質マネジメントシステム」と呼びます。

品質マネジメントシステムは国際規格であるISO 9000ファミリーとして標準化されています。その審査に通れば、品質マネジメントシステムが正しく構築されていると認められるのですが、これはプロセスを定義してその通りに実行しているかどうかを確認するという欧米流の考え方です。一方、日本的な品質マネジメントシステムの考え方では、「顧客満足の達成」という目的を全員が共有し、QCサークルのような活動に組織内の全員が参加して今より高いところを目指してプロセスそのものを改善しながら進めるというところが特徴的です。

この副カテゴリには、工程に依存せずに開発全体にわたって共通して行われる活動が含まれます。これらの活動は、プロジェクトマネージャが行うプロジェクトマネジメント（プロジェクト管理）と重なる部分もありますが、SQuBOK® ガイドでは、その中でもソフトウェア品質と関連の深いものを取り上げています。

プロジェクトマネジメントには、SQuBOK® の先輩とも言える「PMBOK® 」という知識体系があります。SQuBOK® ガイドのこの副カテゴリにある「調達マネジメント」と「リスクマネジメント」の2つの知識領域はPMBOK® の知識領域にも含まれているものです。つまりこれら2つの知識領域は、プロジェクトを遂行する上で必要な活動というだけでなく、品質の高いソフトウェアを開発するためにも重要な活動であることが分かるでしょう。

また、PMBOK® にはない知識領域として「構成管理」があります。これはソフトウェア開発をしているSEやプログラマの方にはおなじみの作業でしょう。構成管理には、ソースコードなどの成果物の変更履歴やバージョン・リビジョンを管理する「バージョン管理」、テスト中やリリース後に見つかった不具合と、それに対する対応状況を管理する「不具合管理」などがあります。これらは構成管理（バージョン管理）ツールやバグトラッキング（バグ追跡）ツールなどを使って管理するのが一般的ですが、単にツールを使えば勝手に管理してくれるというものではありません。バージョンの付与ルールや不具合の解析フローといった管理方針や手順とセットで使うことで正しい管理ができるようになります。

最後の3つ目の副カテゴリは、工程に依存した品質マネジメント活動です。これは、前回(第3回)説明した「ソフトウェア品質技術」カテゴリの知識領域に対応しています。

例えば、「レビューの技法」知識領域に対応して「レビューのマネジメント」知識領域があります。「レビューの技法」知識領域では「インスペクション」や「ウォークスルー」といったレビューの技法を取り上げていましたが、その技法を理解すれば実際のプロジェクトの中でレビューができるというわけではありません。複数ある技法のうち、どれをどういう順番で用いるか、どのようなメンバーがどのタイミングで行うか、レビューした結果をどう扱うか、などについてしっかりと計画を立て、遂行しなければなりません。

同様に、「テストの技法」知識領域に対しては「テストのマネジメント」知識領域があります。「テストの技法」知識領域では、テストケースを作るための様々な技法について主に取り上げていました。しかし、その技法をマスターしただけでテストが完璧にこなせるかと言うと、そんなことはありません。実際のテストを進めていく上では、「単体テスト」「結合テスト」「システムテスト」といった「テストレベル」を段階的に進めていかなければなりませんし、さらに各テストレベルの中でも、テストの計画を立て、その計画通りに作業が進んでいるかを監視・統制する必要があります。

今回は「ソフトウェア品質マネジメント」カテゴリについて紹介しました。品質マネジメント活動は組織レベルからプロジェクトレベルまで多岐にわたるものですから、すべてを一度に実現させようとするのは難しいと思います。トピックスも数多くありますので、まずは自分にとって身近なものから理解し、徐々に幅を広げていくようにするのがよいでしょう。

4回にわたって解説してきたSQuBOK® ガイドの連載は今回で最後となります。最後までお付き合いいただきありがとうございました。紙面の都合上、重要な部分や特徴的な部分に絞った解説となりましたが、SQuBOK® ガイドの全体像は掴んでいただけたでしょうか。初めてSQuBOK® ガイドを見た時は、そのボリュームの多さと難しそうな内容に圧倒されてしまったかもしれませんが、この連載記事を読んで、ガイドがどのように構成され、どのようなトピックスについて書かれているかを理解し、活用いただけたら幸いです。

第1回でもお話しましたが、SQuBOK® ガイドは「品質技術のカタログ」のようなものです。従って、まずはどこにどのようなことが書かれているかを知っていただければよいと思います。そして、自分の必要な情報についてSQuBOK® ガイドの解説文を読み、さらに理解を深めたい方は参考文献を調べて、より詳細に学んでみてください。

また、このSQuBOK® ガイドをベースにした資格試験「ソフトウェア品質技術者資格認定」ができました。SQuBOK® ガイドを読み込んで、どのぐらい理解したかを確認したい方は力試しに是非チャレンジしてみてはいかがでしょうか。

2007年11月に第1版が発刊されたSQuBOK® ガイドは、2008年10月に一部改訂(アメンドメント)され、改訂箇所がWeb公開されました。今後は第1版では扱わなかった設計や実装に関する記述の追加や、既存の記述内容の見直し、拡充などを行って、改版する予定です。Quality OneでもSQuBOK® に関する最新情報を引き続きお知らせしますので、楽しみにしていてください。

前回(第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版では開発フェーズの品質技術を紹介する予定ですので期待してください。

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

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

1. テストの実施者（誰がテストをするか）
2. 網羅性（どの程度のテストを行うか）
3. 問題やリスク（発見したい問題やリスクは何か）
4. 作業内容（どのようなアプローチでテストするか）
5. 結果の判定方法。

この五大要素がテスト技法を選択する上で大いに参考になるはずです。

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

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

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

QualityOneをご覧になっている方々はすでにご存じかもしれませんが、本連載で取り上げているSQuBOK® ガイドが、2008年度の日経品質管理文献賞を受賞しました。このような栄誉ある賞をいただき、策定部会メンバも、よりいっそう気を引き締めて取り組んでいく決意を新たにしております。今後とも皆様のご指導ご鞭撻をいただければ幸甚でございます。
（参考：2008年度 デミング賞本賞・実施賞・日経品質管理文献賞 受賞者一覧）

さて、第1回ではSQuBOK® およびSQuBOK® ガイドがどういうものであるかを解説しました。今回からは、いよいよ実際のSQuBOK® ガイドの中身に入っていきたいと思います。
第2回は、SQuBOK® ガイドの1つめのカテゴリである「ソフトウェア品質の基本概念」について解説します。と言っても、カテゴリ内のすべてをとりあげるわけにもいきませんので、読み進める上で、意識すべきことや重要な部分を中心に解説します。

このカテゴリは、基本概念というだけあって、「品質」「品質管理」といった、普段何気なく使っている用語の定義や考え方について整理をしています。
そもそも、「品質」という言葉自体が漠然としたものです。皆さんも普段から「このシステムの品質はボロボロだ」とか「ちゃんと品質を満たしているのか」などという会話をすることがあるでしょう。こんなとき、その「品質」という言葉が何を指しているのか、会話の相手と認識が合っているでしょうか。この意識が組織でブレてしまうと、目指すべき品質のベクトルが決まらないどころか、気がついてみたら全く別のところを目指していたという事態にもなりかねません。また、顧客やユーザとの間でも、求められる品質について早い段階で意識合わせをしておくことが非常に大切です。
まずは、このカテゴリに書かれた品質の概念をしっかりと理解し、それを踏まえた上で共通の認識をもつこと（決めていくこと）が重要となります。

さて、「ソフトウェア品質の基本概念」カテゴリの樹形図を見てみると、「品質の定義」というトピックスがなんと10個もあります。先ほど、「品質」の認識を合わせましょうという話をしましたが、これでは、「じゃあどの定義に従えばいいの」と逆に混乱してしまうかもしれません。

SQuBOK® ガイドは、読者を混乱させようとして10個もの定義を載せているわけではありませんし、どれかの定義を選ばなければいけないということでもありません。
では何故それだけの定義を載せているのでしょうか？
その答えの一つは「様々な視点により品質の考え方は異なる」ということです。また、言葉は時代によって変わると言われますが、品質についても、その時代の社会環境や技術の進展にともなって考え方や概念は変わります。
先人たちが考え、そして実践してきた定義は皆さんにとってきっと品質に関するベースを作ってくれることでしょう。そして、これらの定義を皆さんの組織で、かみ砕いて、よりわかりやすく、より具体的に表現することで、品質に対する認識の共有を図ることができるでしょう。

これら10個の品質の定義をよく読んでみると、共通して言えるのは「顧客やユーザの要求・ニーズを満たしているかどうか」であると言えそうです。ソフトウェア開発に携わる人は、どうしても作り手の視点になってしまいがちです。使う側の視点を常に意識することで、品質の高いソフトウェアを開発することができるでしょう。

さて、品質の定義に共通した概念はユーザのニーズに対する満足度だということが見えてきましたが、一口にユーザのニーズといっても様々なものがあります。また、「品質の定義」知識領域の解説には次のように書かれています。『例えば、1950年代は正しく動くことがユーザにとって重要であったが、その後、信頼性や処理時間に焦点が移り、1980年代には信頼性は当たり前品質と言われてユーザビリティに目が向けられた。そして現在はセキュリティがユーザの大きな関心事の一つになっている。』このように、求められる品質は時代とともに変化していることが伺えます。

この「品質」を、より具体的な「品質特性」として表したものにソフトウェア品質モデルがあります。有名なものにISO/IEC 9126シリーズがあり、SQuBOK® でもトピックスとして取り上げています。このモデルではソフトウェアの品質を「内部品質」「外部品質」「利用時の品質」の3つに分け、開発の途中段階、完成段階、および利用状況下での品質評価に対応させています。また、外部及び内部品質を「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」の6つの品質特性、利用時の品質を「有効性」「生産性」「安全性」「満足性」という4つの品質特性で表しています。

このように「○○性」という言葉まで具体化されると、品質というものがよりイメージしやすくなったのではないでしょうか。顧客やユーザによって、どの品質特性を重視するかは異なることが多いものです。これらの具体化された品質特性を基に、顧客と合意を得ることで、より高い品質、すなわち顧客満足度の向上につながるでしょう。

SQuBOK® ガイドでは「品質マネジメント」「品質コントロール」という用語が使われています。なぜ「品質管理」と言わないのだろうと不思議に思った人がいるかもしれませんね。

日本では、controlとmanagementの訳語としてどちらも「管理」が使われてきましたが、別の単語であることから明らかなように欧米では異なる概念です。SQuBOK® ガイドではこの違いを明確に意識できるように「管理」とは訳さず、「マネジメント」「コントロール」のままとしています。
では、それぞれどういう意味なのでしょうか。

ISO9000では、「品質マネジメント」は『品質に関して組織を指揮し、管理するための調整された活動』と定義されています。また、「品質コントロール」は『品質要求事項を満たすことに焦点を合わせた品質マネジメントの一部』と定義され、品質マネジメントの下位の概念になっています。

品質管理（品質コントロール）や品質保証という言葉を、特に違いを意識せずに使っている方も多いのではないでしょうか。

SQuBOK® では「ソフトウェア品質の基本概念」カテゴリの2つ目の知識領域「品質のマネジメント」で、それぞれISO9000の定義を引用して解説を加えています。「品質コントロール」の定義は前述したとおりです。一方、「品質保証」は『品質要求事項が満たされるという確信を与えることに焦点を合わせた品質マネジメントの一部』と定義されています。

これらの定義を読むと、まず「品質マネジメント」の中に「品質コントロール」と「品質保証」があることが分かりますね。ただ、両者の違いを、品質要求事項を「満たすこと」か「満たされるという確信を与えること」という表現の違いだけで理解するのは難しいかもしれません。
「品質保証」の具体的な方法には、副知識領域にもなっている「検査」や「V&V」「ソフトウェア測定」などがあります。これらの方法が、「確信を与える」ための手段ということになります。一方、これらの方法を使って品質を保証するために、求められる品質の基準が満たされるように活動を進めていくことが「品質コントロール」と言えます。

皆さんの組織では、「品質マネジメント」つまり品質に関する一連の活動を指して「品質管理」と言っていることが多いのではないでしょうか。それ自体は悪いことではありませんが、その中で「品質保証」と「品質コントロール」を正しく行うことが大切です。

最後に、このカテゴリの中で重要なキーワードを１つとりあげましょう。それは「ディペンダビリティ」です。同じ知識領域にある「セキュリティ」や「ユーザビリティ」はご存じの方も多いと思いますが、この「ディペンダビリティ」という言葉はなじみのない方が多いのではないでしょうか。

「ディペンダビリティ」については副知識領域の説明が最もわかりやすいと思います。ディペンダビリティは信頼性と訳されることもありますが、同じく信頼性と訳されるReliabilityやAvailability(可用性)、Maintainability(保守性)の上位に位置付けられ、時間的な経過や様々な利用状況の下での品質までを含めた包括的な概念です。

私たちの身の回りは、その大部分がIT化され、ソフトウェアなしでは生活できないのが現状です。そういった中で利用しているソフトウェアには、作られてから何十年も経ってしまい、それに伴う品質問題が起こりうる可能性があることを意識する必要がでてきました。
この考えは、ソフトウェアが一部の人のためのものだった時代にはなかったもので、現代ならではの新しいものです。これも、品質の考え方が時代によって変わることの例と言えるでしょう。今後は、ソフトウェアの作り手として、長期的な利用も意識した品質保証が必要になるということに注意しましょう。

このカテゴリは、「そもそも品質とは」というかなりお堅いテーマなので、理解に時間がかかるかもしれません。SQuBOK®ガイドでは、実際の定義が書かれている規格を引用しつつ、それらをよりわかりやすく解説していますので、皆さんの理解の手助けになると思います。

次回は残り2つのカテゴリのうち、開発者の方にとってより身近な「ソフトウェア品質技術」を取り上げる予定です。

読者の皆さんこんにちは、SQuBOK® 策定部会の辰巳、町田、池田です。
このたび、クオリティワンがWebマガジンに移行するのに伴い、SQuBOK® 策定部会でもコーナーをいただきました。
全4回にわたって、2007年11月に第一版が刊行された「ソフトウェア品質知識体系ガイド－SQuBOK® Guide」について解説します。
こう書くと堅苦しく思われるかもしれませんが、新人を含めた初心者の方々向けに、できるだけやさしく解説していきますので、どうぞお気軽にお読みください。

さて早速中身にはいりますが、この第1回では「SQuBOK®ってなあに？」というお話しから始めたいと思います。
SQuBOK® の体系図や具体的な技術は第2回以降で解説することにして、まずはBOK、そしてSQuBOK® についてのおおまかなイメージをもっていただければと思います。

冒頭からSQuBOK® という単語が繰り返し出てきました。皆さんの中には、今までにPMBOKやSWEBOKという似たような単語を見聞きしたことがあるという方もいらっしゃることでしょう。
PMBOKは「Project Management Body of Knowledge」、SWEBOKは「Software Engineering Body of Knowledge」の略で、それぞれ「ピンボック」「スウェボック」と呼ばれることが多いようです。同様に、SQuBOK® は「Software Quality Body of Knowledge」の略で「スクボック」と読みます。
このSQuBOK® 、PMBOK、SWEBOKに共通するのは"BOK(Body of Knowledge)"という部分ですが、BOKは日本語では知識体系と訳されています。
つまり、SQuBOK® はソフトウェア品質の知識体系、PMBOKはプロジェクトマネジメントの知識体系、SWEBOKはソフトウェアエンジニアリングの知識体系ということになるわけですね。

もう少しBOKのお話にお付き合いください。
PMBOKやSWEBOKと呼ばれている書籍をよく見ると、そのタイトルに"Guide to the"がついています。例えば、PMBOKは"A Guide to the Project Management Body of Knowledge"（プロジェクトマネジメント知識体系ガイド）が正式な書籍の名称です。 BOKという言葉は「ある専門領域の知識の総和」という意味で、その分野の実務者や研究者がもっている知識全体を指しています。この膨大な知識の中から、一般的に認められたものを整理・紹介し、それらへ簡単にアクセスできるようにしたのがBOKガイドです。
ここでは簡単に、私たちの先輩達が地道に積み上げてきた"実績のある"ノウハウ、しかも現在においても生き残ってきたベストプラクティスを集めたものがBOKガイドであると理解してもらうといいでしょう。

簡単な例を挙げてみましょう。
例えば、部屋のインテリアを改善したいとします。
地道にお店を回って調査しても良いでしょうが、様々な情報、しかもお勧め商品がたくさん掲載されたカタログが手元にあったとしたらどうでしょうか？
インテリアを改善するための整理された有益な情報が、部屋を出なくても入手することができます（それはカテゴリや一覧という形で整理されています）。
もちろん連絡先も記載されていますから、気になった情報についてはその詳細を問い合わせることができます。
カタログを活用すれば、お店を回るための交通費はかかりませんし体力もいりません。
これは初期の検討に非常に効率的です。
また、カタログが充実していれば、自分の知らなかった（思いも付かなかった）製品の情報も知ることができ、新たなアイデアを得ることもできることでしょう。

皆さんおわかりのとおり、技術調査というものは非常に大変です。
このようなときに、技術カタログがあったらどうでしょうか？
そして、そこにはすでに何らかの実績があるもの"だけ"が記載されているとしたらどうでしょうか？
詳細な情報が書かれている書籍や論文にアクセスできる手段が記載されていたらどうでしょうか？
きっと皆さんの調査作業は、高品質かつ効率的になるはずです。
そして、技術カタログに自分や組織が今まで知らなかった情報が載っていたら、新たな知見を得ることにもつながります。

前置きがずいぶんと長くなりましたが、ではSQuBOK® ガイドとはどのようなものなのでしょうか？
もちろん、名前が示すとおりSoftware Quality、つまりソフトウェア品質を専門に取り扱っていますが、他のBOKガイドと異なるのは日本国内の産学、つまりソフトウェアを開発する企業の現場担当者やソフトウェア開発の研究者が策定した日本"発"のものであるというところです。
これまで、ソフトウェア品質に関しては各人の頭の中に閉じたノウハウ、つまり暗黙知のものも多かったのですが、SQuBOK® ガイドではそれらを形式知化するとともに体系化し、日本で培われた技術や国内企業の固有技術などを数多く紹介しています。
また、米国を中心に策定されたPMBOKやSWEBOKは参考文献も米欧のものが中心ですが、SQuBOK® ガイドでは翻訳書を含め日本語のものを中心に紹介し、現場の方々が入手し易く、すぐ業務に役立てられるよう配慮しています。

"カタログ"では知りたいことに素早くたどり着けることが重要ですよね。
SQuBOK® ガイドでは、ソフトウェア品質に関する知識を、「品質の基本概念」、高品質なソフトウェア開発を達成するための両輪である「品質マネジメント」、「品質技術」の3つのカテゴリに大別して書籍の章に対応させ、更にカテゴリの中を知識領域、トピックへ詳細化する形でまとめていますので、必要な情報へのアクセスも容易です。

このSQuBOK® ガイド（第1版）を策定するにあたり、策定部会では次の5つを目的として取り組みました。

＜以下、引用＞

SQuBOK® ガイドは、決して「このとおりにしなきゃダメだ」というマニュアルの類ではなく、品質に関する活動に取り組む際の助けとなる情報を提供するものです。
第1版では目的1にあるとおり、まずは品質保証に携わるエンジニアを対象としていますが、設計やプログラミングに携わるエンジニアに無関係なものではありません。そのような方々においても、設計品質やプログラミングの品質を向上するための観点やヒントを得ることができます。
ソフトウェアの品質は、ソフトウェアプロジェクトにかかわる全ての人がそれぞれになんらかの形でかかわるものです。ソフトウェアテストや品質保証のエンジニアでなくても、是非参照していただければと思います。

いろいろと説明してきましたが、SQuBOK®ガイドがどのようなものであるか、おおまかなイメージをもてたでしょうか？
次回からは、いよいよ詳しい中身に入っていきます。
よろしければ、出版されているSQuBOK® ガイドを手にとっていただき、次回までにさらりと目を通していただけるとより理解がすすむかと思います。

SQiPは、ソフトウェア品質管理技術・施策の調査・研究・教育を通じて、実践的・実証的な
ソフトウェア品質方法論を確立・普及することにより、ソフトウェア品質の継続的な向上を目指します。