「SQuBOKの利用法：参照スタイルから進化スタイルへの提案（その2）」

株式会社NTTデータMSE
ソリューションサービス事業部
コンサルティンググループ 堀　明広

　「SQuBOK」とは「Guide to the Software Quality Body of Knowledge」の略で、正式名称は「ソフトウェア品質知識体系ガイド」です。

　対して「SQuBOKユーザー会」は、以下を目的に、2009年に設立されました。
・ 先人が切り開き、培ってきた品質技術を伝承し、それらを有効利用して、更には発展させるため、
SQuBOK活用の事例を共有する。また、SQuBOKをより密に活用する方策・方法を模索し、共有する。
・ ソフトウェア開発に関係する者にとって、SQuBOKがより価値ある知識体系に進化し続けることに、
SQuBOKのユーザー自身も参画し、これを実現する。

　従来の「SQuBOKユーザー会」の活動のメインは、メーリングリストを通じての議論・情報交換を主としていました。

　前回の記事では、ソフトウェア品質に関する知見は非常に広くて深淵であることを、私の実体験を交えて紹介しました。また、SQuBOKをより活用してソフトウェア品質向上活動に繋げる一つの手段として、「SQuBOKユーザー会」で今後取り組んでいきたいことの概要に触れました。今回は、それらをもう少し詳しく記します。

【SQuBOKユーザー会 新活動の概要】

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

　ソフトウェア品質に関する知見、事例は常に進化しています。
これらを、SQuBOKユーザー会で積極的に扱っていきたいと考えています。
・ 新たに出された知見を整理し、体系付けるのに、SQuBOKを軸として利用する。
・ 勉強会等で出された意見等を、その場限りでなく、一個の体系に記録し、蓄えていく。
・ それらを使って、更に議論を深めていき、新たな知見を産み出していく。

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

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

【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はその名は「ソフトウェア品質知識体系ガイド」です。
SQuBOKの本文中に記載されているのは要約であるため、その中身をより理解を深めるためには、「参考文献」をあたる必要があります。

　SQuBOKの「参考文献」には、その記載量の制限から厳選されていますが、「参考文献」でポイントされていないものにも、良書はたくさんあります。また、SQuBOKが出版されて以降にもソフトウェア品質に関わる多数の書籍が出版されています。更に視野を広げ、ソフトウェア品質に直接的に関連しないものにも参考にすべき書籍は非常に多く、これらを紹介し合うことには、大きな意義があると思います。
書籍を紹介する際には、単に書籍名・著者・出版年月等のデータだけではなく、紹介者による感想や内容に関する意見も含めておくと、議論もしやすくなると思います。

●規格
SQuBOKの出版後にも、ISO・IEC・IEEE・JIS等の規格は新規策定・改訂・廃止がなされています。現状に合わせて状況を俯瞰・整理することを考えています。
また、ソフトウェア品質の観点で、その規格で記載されている内容の意図、複数の規格の関連・相違点などが議論できると良いと思います。

●記事
ここで言う「記事」とは、技術情報誌やビジネス誌や、新聞・ニュースの記事と、これらに関連するinternetサイト、webマガジン、blog等を指しています。
ソフトウェア品質に関する調査は、書籍や論文だけでなく、上述の「記事」を検索サイトで調べることも頻繁に行いますが、ここで言うまでもなく、各種メディアやinternet上での情報は爆発的に増加してきているため、目的の情報を得るのが難しくなってきています。

　こういった情報を抽出・整理・共有すると、知見の発掘・整理に大いに役立つと考えています。

●論文
今回提案している中で、一番重視したいのは、この「論文」です。
論文と言うと、何か堅苦しい、敷居が高いイメージもあるためか、論文を読んだことが無いエンジニアが多いように思います。
まったく、もったいない話です。どうか食わず嫌いをしないで、一度、論文を読んでみることを、強くお勧めします。

　例えば、日本科学技術連盟主催の「ソフトウェア品質シンポジウム（通称：SQiPシンポジウム）、ASTER主催の「ソフトウェアテストシンポジウム（通称：JaSST）」では、実務者が執筆した事例報告が数多く報告されています。
これら論文では、その組織やプロジェクトで抱えている問題・課題を整理し、それを解決するための方法を考察してそれを実施し、その結果がどうだったのか検証するまで、分かりやすく整理されており、書籍等だけは得られにくい実践事例を知ることができます。
為すべきことは分かっているが、具体的にはどう手をつけていけば良いのか分からないといったケースや、取り組みはしているが、壁に当たって行き詰まり・手詰まりし、悩んでいる方も多いかもしれません。こういった時には、論文でヒントになる事柄が見つかることが多いものです。
また、論文を読むことで、各組織ではどんな取り組みがなされているか、トレンドも把握でき、視野を広げることにも役立ちます。

　しかし、どこで、どんな論文が発表されているか、その入手方法が分からない方も多いことでしょう。
これらをSQuBOKの樹形図を軸にして整理し、その情報を共有したいと考えています。

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

　こういった活動の存在そのものを紹介し合うこと、また、そこでディスカッションで交わされた意見や得られた知見、整理された事項等を持ち寄って蓄積・共有することが出来れば、互いに大きなメリットになると思っています。

　また、これらの情報共有をする過程で、互いに持ち寄った情報に対して意見・補足情報等を加えるようにして、いったら、別の議論が生まれ、それが新たな知見の創出に繋がるものと思っています。

【準備はほぼ整いました】

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

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

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

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

SQuBOKガイドの改訂に向けた活動について（参考文献の活用方法）

(株)NTTデータ 技術開発本部
プロジェクトマネジメント・イノベーションセンタ
町田　欣史

■はじめに

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

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

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

■SQuBOKガイドから知識を広げる

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

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

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

これを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ガイドの改訂に向けた活動について（途中報告）

(株)NTTデータ 技術開発本部
プロジェクトマネジメント・イノベーションセンタ
町田　欣史

前号でもお伝えした通り、現在SQuBOK®策定部会では、SQuBOK®ガイドの改訂作業を実施中です。読者の皆様に最新かつ洗練された情報をお届けするべく執筆、レビューを繰り返しています。

前号で改訂のポイントをいくつかご紹介しましたが、今回はその中でも改訂の目玉の一つになる設計領域について、どのような解説が記述されるのか、ほんの一部だけ先行してお知らせしたいと思います。

SQuBOK®ガイド第1版では、レビューやテストなどの品質保証技術や、プロジェクトマネジメント的要素に関する解説が充実していましたが、設計や実装などの品質を作り込む技術に関する解説はありませんでした。今回の改訂ではそれらの解説が追加される予定ですが、SQuBOK®ガイドですから、あくまで「品質」という視点を切り口にして設計や実装を語っています。

世の中一般にある書籍などでは、設計であればUMLを使った設計書の書き方、実装であればプログラミング言語の入門書のようなものがあります。ただ、これらは設計や実装をする上での手段を解説しているにすぎず、それらをマスターしたからといって品質の高い設計、バグのない実装ができるわけではありません。そこで、SQuBOK®ガイドでは、設計や実装において品質を作り込むための基本概念や技法を取り上げています。

たとえば設計においては、複雑さをできる限り下げることで、信頼性や保守性、移植性といった品質特性を向上させることができます。従って、設計の複雑さを低減させるための基本概念や技法が、品質の視点からは重要になってきます。その例としては、オブジェクト指向でおなじみの「抽象化」や、構造化設計の「モジュール化」といった概念があります。あまり書きすぎるとネタばれしてしまいますので、今回はここまでにしておきますが、このようにアーキテクトの方にも興味を持っていただけるような内容が含まれています。

また、実装においても、プログラマが好き勝手に実装してバグを埋め込んだり、保守性の低い（読みにくい）コードを書いたりしないようにするための技法として、コーディング規約を活用することを取り上げています。それによって、プログラマのスキルに依存しがちな品質を向上、もしくは均一化することが実現できます。他にも、プログラマの方にも有益な技法を取り上げていますので、こちらも改訂版の公開をお待ちいただければと思います。

さらに、設計、実装に関しては、技法だけではなく、「ソフトウェア品質マネジメント」カテゴリで、それらのマネジメントに関する知識領域も追加しています。こちらでは、設計や実装の作業の計画、方針決定から、作業プロセスや成果物の評価について解説していますので、マネージャの方や開発リーダクラスの方に参考にしていただけることと思います。また、マネジメントについては、設計の前の要求分析に関する知識領域が第1版では未執筆となっていました。こちらについても今回の改訂で追加されることになりますので、楽しみにしていてください。

公開前ということもあって、なかなか情報が出せなくて申し訳ありません。今回紹介できるのはここまでとなります。改訂版については、現在改訂の検討・作業を進めているところであります。出版した際には、また皆様からのご意見をいただき、皆様にご活用いただけるSQuBOK®ガイドへと発展させていきたいと考えております。

SQuBOKガイドの改訂に向けた活動について

(株)NTTデータ 技術開発本部
プロジェクトマネジメント・イノベーションセンタ
町田　欣史

はじめに

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.の商標です。その他本文中の製品名は各社及び商標権者の登録商標あるいは商標です。

ライフサイクルにおけるプロセス評価と改善からSQuBOK^® を読み解く　第4回

株式会社日立システムアンドサービス　シニアコンサルタント
古賀　惠子
日本ユニシス株式会社　品質保証部
大川　鉄太郎
プロムス　代表
河合　一夫

第４回の内容

　連載４回目は，「ライフサイクルにおけるプロセス評価と改善」です．ソフトウェアライフサイクルにおけるプロセス評価と改善はどのような目的でどう行われるのか，ソフトウェアの品質を考える上でどのような意味を持つのかなどを，古河課長と熊川さん[第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^®には先人たちのさまざまな知恵がいっぱい詰まっています．ぜひ一度手にとってみてください．

ソフトウェアライフサイクルからSQuBOK^® を読み解く　第3回

株式会社日立システムアンドサービス　シニアコンサルタント
古賀　惠子
日本ユニシス株式会社　品質保証部
大川　鉄太郎
株式会社ニルソフトウェア　シニアコンサルタント
河合　一夫

第３回の内容

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

ライフサイクルと品質技術

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

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

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

　熊川さんはSQuBOK^® を開きながら，開発を依頼するシステムが必要とする品質レベルを基に品質要求仕様を作り始めました．
「品質計画，要求分析，レビュー，テスト，品質分析･評価,運用･保守の各工程のマネジメントと技法が掲載されているので，これらを活用してメトリクスを決めればよいな．」
熊川さん，まずはソフトウェア品質マネジメントの各知識エリアの内容を参考に，A社に要求すべき品質要求を検討することにしました．
「今回は品質計画，レビュー，テスト，品質分析･評価とそれらのメトリクスについて要求しよう．」
熊川さんは，品質要求として以下のようにまとめました．
（１）品質目標の設定：具体的なメトリクと目標値は，参考文献の「TS X 0111-2第2部：JIS X 0129-1による外部測定法」を参考に信頼性や効率性のメトリクスを決めて要求する．具体的な目標値は自社の実績から決める．
（２）方針：品質を作りこむために，どのようなプロセス，アーキテクチャ，基準等を採用するか方針を定めることを要求する．
（３）レビュー：レビュー計画では，レビューの詳細な実施方法は任せることにし，A社との共同のレビューはインスペクションを要求することにしました．レビューのメトリクスは，レビュー対象の規模当たりの不具合の摘出率とする．
（４）テスト：テスト計画では，同値分割や境界値テストの実施を要求しました．具体的な指標として，プログラム規模あたりのテスト項目件数，異常値テストの割合，プログラム規模あたりの不具合件数の目標値を自社の実績からを設定して要求する．
（５）報告：それぞれの工程の完了時には計画通りに完了したことの報告を，最終的には総合的な品質の評価を提出してもらう．

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

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

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

ソフトウェアライフサイクルからSQuBOK^® を読み解く　第2回

株式会社日立システムアンドサービス　シニアコンサルタント
古賀　惠子
日本ユニシス株式会社　品質保証部
大川　鉄太郎
株式会社ニルソフトウェア　シニアコンサルタント
河合　一夫

第２回の内容

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

ソフトウェアライフサイクルとは

　熊川さんは，昨日から頭を抱えています．部長と課長に呼ばれて次の調査を命じられたのですが，どう手をつけてよいか分からないからです．
「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^®ガイドに当たるのが定石だ．
今回の調査なら，

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

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

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

ソフトウェアライフサイクルからSQuBOK^® を読み解く　第1回

株式会社日立システムアンドサービス　シニアコンサルタント
古賀　惠子
日本ユニシス株式会社　品質保証部
大川　鉄太郎
株式会社ニルソフトウェア　シニアコンサルタント
河合　一夫

はじめに

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

本連載の進め方

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

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

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

第1回の内容

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

ソフトウェアライフサイクルとは

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

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

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

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

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

SQuBOK^® 編集チーム

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

■はじめに

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

■「ソフトウェア品質マネジメント」カテゴリの概要

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

ソフトウェア品質知識体系ガイド－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^®ガイドの付録に参考文献の一覧がありますので活用してください。
次回はこのシリーズの最終回として、経営層から現場に至る全てのレイヤの品質マネジメントのアクティビティをまとめた「ソフトウェア品質マネジメント」を解説する予定です。

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

SQuBOK^® 編集チーム

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

はじめに

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

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

「ソフトウェア品質の基本概念」カテゴリの概要

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

「品質の定義」が10個もある！

　さて、「ソフトウェア品質の基本概念」カテゴリの樹形図を見てみると、「品質の定義」というトピックスがなんと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^® Guideについて　第1回

SQuBOK^® 編集チーム

はじめに

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

第1回の内容

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

BOKってなんだろう？

冒頭から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とBOKガイド

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

BOKガイドは技術のカタログ

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

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

SQuBOK^®ガイドは品質技術のカタログ

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

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

SQuBOK^®ガイドの目的

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

＜以下、引用＞
1．品質保証に携わる方の育成に役立つものにする
2．ソフトウェア品質に関する日本の暗黙知を形式知化する
3．ソフトウェア品質に関する最新のテーマを整理し、体系化する
4．ソフトウェア品質技術の認知度向上を図る
5．ソフトウェア品質保証プロセスを確立したい組織の助けとなる
＜以上、引用＞

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

終わりに

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