最後に、予告どおりに品質管理の話をして終わりにしようと思います。　

 

　ソフトウェアのバグは先にも書いたように２つに大別して考えることが大切です。
　ひとつめは「プログラムとしての間違い」です。
　プログラミングは厳密な手順の定義作業とも考えられます。このため、コンピュータに与える命令はひとつのミスをすることも許されません。そこで、プログラマがミスをすることでプログラムに起因するバグが埋め込まれることになります。プログラマのミスはいろいろな場面で起きそうにも思えますが、実はミスしやすい作業とミスしにくい作業が存在します。一般的に、間違いやすいプログラム文法、例えばＣ言語における比較と代入の書き方のような仕様はミスを誘発させます。また、似たような領域名称は長時間のプログラム作業時に名称の混同を引き起こします。これらは例ですが、似たような罠がプログラムという作業の中に多数あるわけです。そこで、次のようなプロセスで間違いを減らすようにします。　

 

　ステップ１：プログラムをする
　ステップ２：プログラムを検証・テストする
　ステップ３：検証・テストした結果から間違ったポイントを解析する
　ステップ４：解析結果から間違いにくいプログラミングルール（コーディング規約）を作る
　ステップ５：間違いやすいポイントについてプログラマを教育する（レビューや勉強会などで）
　※たぶん、ステップ１に戻る

　
　バグというとなにを思い浮かべるでしょうか？　
　
　漠然とバグを考えていると、バグとはいつの間にやら入り込む間違いを思い浮かべます。よく「バグは避けることはできない」などといいますが、いつの間にやら入り込む虫のようなイメージです。これは日本語ではよく「蛆がわく」「ボウフラがわく」など、虫がなにもないところから勝手に生まれてくる表現がありますが、それと同じようなイメージがバグに関してもあるようです。ただし、実際には蠅や蚊はその卵があるから幼虫が生まれているわけです。もちろん、ソフトウェアのバグにも同様に原因が存在します。封を切っていないペットボトルの水の中からボウフラが生まれることはないのです。　
　
　この様相を脱出するためには、まず、ソフトウェアに存在するバグを「ソフトウェアの実装に起因するバグ」と「システムの仕様に起因するバグ」に大別することが大切です。
　ソフトウェアの実装に起因するバグは、実装時の間違いが主な原因になります。これは実は一般的な品質管理における生産・製造に関する品質向上対策を地道に実施することにより無くすことが可能であることが、１９８０年代にソフトウェア工場の取り組みの中で実証されています。
　一方で、システムの仕様に起因するバグは要求されるシステムの仕様に対する考慮漏れ、定義漏れ、理解不足などが原因です。これはシステムを構成する層について、すべての検討が漏れてしまったり、一部の条件が検討不足だったりといったことが原因になり、多くの場合、一部の機能条件にバグが遍在する特徴があります。　

 

　静的解析ツールや形式記述プログラミングなどは前の「実装に起因するバグ」に対する対策です。アルファテスト、ベータテストなどの顧客テストの目的は後者の「仕様に起因するバグ」に対する数少ない評価方法の例です。
　ひとつひとつの品質向上手法を眺めていくと、前者に関する対策ばかりで後者に関する対策が少ないことに気づくでしょう。これは、バグの自然発生説と無関係ではありません。しかし、実際のソフトウェアや情報システムなどでやっかいなのは、実装におけるバグではなく、仕様の漏れなどに基づくバグの存在です。まあ、実装におけるバグも確率論の問題ではなく、間違いが起きるべきところに起きるものなのではありますが。　

 

　仕様に関するバグを防止するには必要とされる仕様の検討（システムにおけるモデル定義）を確実に行う必要があります。特にモデルの整理が十分でなかったり、表現するパラダイムの選定が的確でないと、仕様に基づくバグが埋め込まれることになります。それは、そもそも考慮されていないので、実際に利用されるまで発覚する機会も少なく、いきなり本番でドカンと時限爆弾よろしく爆発することになります。
　これが、ウォータフォールモデル開発における上流工程において仕様の検討やレビュー、有識者の参加などが重視される理由です。もちろん、アジャイル開発においても仕様の検討不足や顧客からの引出し不足は致命的なロスを引き起こす原因になるでしょう。
　過去のシステム化の経験がある程度蓄積されている組織では、こうした仕様検討上の視点は設計ドキュメントの中に項目としてまとまっています。漫然とドキュメントをコピーしたり、穴埋めするのではなく、ドキュメントの意図に沿って検討していくことで仕様の検討漏れを避けられることに注意すべきでしょう。なお、過去に事例のないシステムや時代の変化によって利用環境における常識が変化してしまっているような場合には、漏れが生じる可能性が高いですから、設計ドキュメントのテンプレートなどは定期的に見直すなど注意が必要です。　

 

　古くから存在する組織やこうした問題に古くから取り組んできた組織では複雑なバグを混入させないためのシステムが構築されています。これがＱＭＳ（Quality Management System）、日本語だと品質管理システムや品質保証システム、品質マネジメントシステムなどと呼ばれるものです。これは、多くの組織で明文化された規則と明文化されていないルール（多くの場合は現場で先輩や上司から教わる）で構成されています。　

 

　例としてみることのできるＱＭＳの例としては保田 勝通著の「ソフトウェア品質保証の考え方と実際」（日科技連出版）が挙げられます。この本の１章から６章までにある組織におけるＱＭＳの例が示されています。また、プロセス成熟度モデルやISO/IEC 90003のようなプロセス規格もＱＭＳの１例ですが、プロセスの目的や必要可否の判断基準、因果関係などについて解説がないので実際に組織に適用するには、本当にそのプロセスが組織に必要なのか、どのように利用することで組織の持つ問題が解消されるのかなどについて注意が必要です。むしろ、システムに包括されるものと考えれば、以前紹介したセージの「システムズエンジニアリング」を参考にされるとよいでしょう。

　大学時代、社会学の授業の副読本は竹宮恵子の「地球（テラ）へ」でした。
　その竹宮恵子の1980年代の代表作のひとつは同じSFの「私を月に連れてって！」で、結構、多種多様なSFの手法がちりばめられたコミックです。この後日談が今回、お話のきっかけになる「ブライトの憂鬱」という本になります。この本の中で、ブライトの友人のサーベンタインは地球の環境をほかの惑星や衛星、人工衛星などの上に構築しようというテラフォーミングの研究をしているのですが、テラフォーミングという技術は実は幅広い生態系研究から導き出されるシステムを指します。

　その生態系ですが、実際の森林は様々な要因が組み合わさってできあがっています。
例えば、エネルギーは食物連鎖の中で繋がっていますが、それと同時に様々な元素がそれぞれの連鎖に基いて固定と解放を繰り返しています。また、ずっと同じ形に見える植物も、いわゆる教科書的な生態遷移があり、また、教科書にはない遷移もまた繰り返します。例えば、南アルプスの川原にある天然のカラマツ林は、中央地溝帯の崩れやすい地形の影響で、極相にはならずカラマツ林のまま維持されているのが知られていますし、北アルプスの上高地は湿地のボーリング調査から、定期的な焼岳の噴火の影響を受けて、天然のダム湖が徐々に干上がって、湿原から森になり、また噴火によってダム湖に戻るといった変化を周期的に繰り返してきたことが分かっています。また、信州に局地的に生育しているスミレの一種であるタデスミレはおそらく数億年の地勢変化、環境変化の中で日本の1箇所と大陸に隔離分布しています。また、秋に農地の土手などに良く見かけるヒガンバナはもともとは日本に自生せず、大昔に大陸から人が運び込んだものだと言われています。
　私はスミレの季節、タデスミレの咲く森に入ると「なぜ、ここだったのか？」という疑問と同時に、そこに残るに至った悠久の歴史に思いを寄せるのです。
　要はひとつひとつの要素を見ると多種多様なものが、ひとつの森という環境の中で一体になっているわけで、これを人為的にシステムとして管理すること、もっと夢を膨らますと、サーベンタイン君のように人工のシステムに構築して制御することは非常に挑戦的な研究のように思えます。実際に、コンピュータソフトウェアの業界に入らなかったら、私は大学でこんな研究をしたかったわけです。

　要は森を解析して個々の仕組みをモデル化することは、実はテラフォーミングというシステム化に通じるのです。本来であれば、生物多様化の議論は情緒ではなく、こうした解析前、もしくは様々な背景を持った仕組みの保全という見方で語られるべきなのかもしれません。まあ、多くの自称エコロジストは、論理やシステム思考ではなく、感情でものを書きますけれども。

　さて、システムを構成する要素のモデル化は、それぞれの属すドメインの枠組みに従う必要があります。そして、それぞれの構成要素に適したモデル化手法を使用することで、漏れのない仕様を、より適したモデルに定義することが可能になるのです。

　すでに第一回目で「パラダイム」という単語を使ってしまっていますが、ソフトウェアの世界でモデル化する際の世界観をパラダイムと呼んでいます。
　オブジェクト指向はひとつのパラダイムです。状態遷移モデルもまたひとつのパラダイムです。そして、おそらく帳票操作の流れをそのまま表現できるCOBOLもひとつのパラダイムだったのでしょう。

　ひとつの世界はいくつかの異なるパラダイムでそれぞれ表現可能かもしれませんが、実際には、それら全ての手法のうちで、モデリングの難易度が低い（より表現しやすい）パラダイムを採用するのが一般的です。例えば、通信のプロトコルは通常は状態遷移表で表現をします。しかし、やろうと思えば、オブジェクト指向でも可能でしょう。ただし、「できる」ことが必ずしも正しいことだとは言えません。オブジェクト指向で表現をした通信プロトコルは非常に難解な構造をしています。そして難解であることは、読む側の理解を妨げ、作る側の難易度を無用に上げることになるのです。もしかすると、ここ20年近くのもっとも不幸だったことのひとつは、オブジェクト指向に全てのモデリングを集約しようとしたことなのかもしれません。

　最適なパラダイムを選ぶと、モデリングが容易になり、パラダイムの持つ制約がモデルの的確さの実現の助けになります。

　昔、数学の実験授業で、行列で扱う数学の授業を全てベクトルで解説する授業を受けたことがあります。おそろしくややこしい解説に辟易としましたが、そのときの先生が語った授業の目的は数学的な問題は別の手法（パラダイム）でも証明できることを理解するだったと思います。ただし、そこで私の得た結論は、例え使えるにしてもパラダイムはそれぞれの理解が容易になるように使えという教訓でした。問題は扱うパラダイム次第で難しくもなり、やさしくもなります。そして、モデル化の容易さが仕様に関する漏れを防止し、モデル化に関する制約がモデルに混入する過ちを防止するのです。

　そして、ソフトウェア開発の方法もまたシステムです。

　システムをキーワードに品質を探る論考の次回は品質管理です。

 

●　「ソフトウェア品質技術者資格認定制度（JCSQE）」対応
　　当セミナーオリジナル「ソフトウェア品質一連の演習」にて教育効果が倍増します！　
　　→　「ソフトウェア品質技術者初級セミナー」

 

　さて、今回はシステムを捉える視点：システム思考とシステムを構築するための体系であるシステム工学について説明します。　
　面白いことに、日本では本当に重要な本や役に立つ本が売れない、もしくはすぐに廃版になってしまう傾向があるようです。今回ご紹介する2冊の本もそうしたものの一例ですね。　
　
　ジェラルド・Ｍ・ワインバーグと聞くと多くの私のようなオールド・ソフト技術者は無性に読み漁った経験を持つのではないでしょうか？
　すでに廃版になった「技術レビューハンドブック（原版は入手可能だったはずですが）」のような本もありますが、現役の著作の中では「一般システム思考入門」（紀伊国屋書店）は取り付きにくい印象を持つ本です。おそらく、一連の著作を読む中で途中で挫折した経験を持つ方もいらっしゃるかもしれません。
　一方で、東京駅前の書店最上階にある松丸本舗（本のセレクトショップ）のコンセプトとなった松岡正剛氏のエッセイ「千夜千冊」の中では、自らの思想に影響を与えた一冊に選ばれていたりもします。（１２３０夜）　
　
　システム思考とは、現代の科学（自然科学のみならず社会科学も）の研究の基本となっている考え方で、ある事象を見る際に、その事象全てをひとつのものとして捉えるのではなく、それが持つ複数の特徴に着目して、それぞれの構造を明らかにし、それを積み重ねることによって全体の構造を理解しようとする方法論です。いわゆる物理学の法則も、経済学の理論も、通信規格であるＯＳＩの構造も、数学の体系すらもこの見方で構築されています。
　簡単な例を挙げると、たとえば、図のような図形の集合があった場合、全体を見るとばらばらで訳がわからなくなってしまいますが、「色」という特徴と「形」という特徴に着目すると、それぞれ2種類のものから構成されていることがわかります。こうした構造を理解することで、全体の理解が容易になるわけです。これが一般システム思考の基本的な考え方で、実はＧ．Ｍ．ワインバーグの著作全体を貫く思想であったりもします。
　なぜ、ワインバーグ氏がこの考え方を繰り返し提示したのかといえば、この考え方自体がシステムを構築する際の仕様の考え方と全体の構築方法を理解する道だからなのだと考えます。実はシステムの構築は、長い間、先人たちが解析してきた数々のパラダイムを用いて、私たちが新しいものを構築する作業に過ぎないのです。　

　
　開発の対象になる「システム」という概念について漠然と理解されていることが多いように感じます。しかし、システムをきちんと理解することがよりよいシステム構築のヒントに繋がります。　システムと言われてどのようなものを想像するでしょうか？
　漠然と、コンピュータと周辺機器がネットワークで繋がれたものを思いつくでしょうか？それとも、多くのＰＣがネットワークで繋がれたものを思い起こすでしょうか？

　「システム」に関する研究は非常に古く、一般システム理論が科学者ルートヴィヒ・フォン・ベルタランフィらによって提唱されたのは１９５０年代にまで遡ることができます。その研究範囲は哲学から始まり、生物学、物理学、組織論、経済学など多岐に渡っていることが特徴です。私はこの現象を、１９世紀から２０世紀にかけて研究、解析、発見された多くの分野の知見を元に、それらを人為的に体系化し、モデル化し、再構築することを目的にしたものと考えています。コンピュータ科学者にして、ノーベル経済学賞を受賞したハーバート・Ａ・サイモンは名著「システムの科学」の中で「人工物の科学」と称しました。

　システムを漠然とではなく、人間が構築すべき人工物として理解するといくつかの点に気付くでしょう。
　１つ目は、それが全体を通してひとつの人工的な構築物であるという点です。狭義のコンピュータソフトウェアだけでなく、ハードウェアからネットワーク、果ては運用などの利用形態までを含んだ諸々でひとつのシステムを形作っています。そして、人工物ですから、もちろんそれらを定義するのも人工物＝システムの構築者の責任です。
　２つ目は、それぞれのシステムに関してもとになる原理＝モデルが存在するという点です。物理学には物理学の理論があり、経済学には経済学の理論があります。また、組織の意思決定にも意思決定のための理論があり、それがモデル化されています。
　３つ目は、システム自体が非常に複雑であることです。そもそも、人工的に整理、モデル化する以前の要求は様々な階層や事実によって複雑化したものですから、それを人工的に整理したシステムへの要求も当然複雑化します。しかし、それでは理解を阻害するだけですから理解のために複雑さを減らす努力をします。このため、あるレベルのモデルは非常に複雑度が軽減されますが、一方でそれのもとになる動作は複雑度を増します。これに対して、階層のモデルに対する複雑度の軽減を繰り返すことになります。
　４つ目は、結果として、システムのモデルは階層化しています。特に対象が複雑なシステムの場合にはシステムを形成するモデルの階層は深くなる傾向があります。
　５つ目は、各モデルには単一ではなく、それぞれの階層を表現するのに適したモデル理論＝パラダイムが存在するということです。システム、特に複雑なシステムは単独のモデルにより形成されるのではなく、複数のパラダイムにより概念化されたモデルの積層によりできあがっています。逆に言えば、システム構築のヒントは、階層化した上でその階層を表現するのにもっともふさわしいパラダイムを用いることが望ましいと言えるでしょう。

　さて、システムが２０世紀中盤に注目されたのには世の中に多くの巨大システムが構築され始めたことがあげられるでしょう。アポロ計画を初めとして、いままで人類が経験したことのなかった複雑なシステムの構築が計画され、その実現が望まれたことが原因のひとつであることは間違いないです。そして、２０世紀の終盤はそれに加えて電子計算機の発達と利用範囲の広がりがシステムの巨大化に拍車をかけました。コンピュータソフトウェアのコード行数は、アポロ計画の頃と比較すると、スペースシャトルで５倍程度まで肥大化しています。また、近年では多くの製品がハードウェアの簡素化と機能性の向上を目的にソフトウェア化が進んでおり、これが組込ソフトウェアにおける問題を引き起こしているのはご存知の通りです。

　実は、構築側もそのような状況に手をこまねいていたわけではなく、すでに早い時期からシステム工学が体系化されてきていますが、これは次に説明することにしましょう。

　システムという学際的な分野を扱うことは、哲学を中心に多くの隣接する学問を学ぶ必要があります。しかし、闇雲に要求仕様を考えてプログラムを書くのではなく、きちんとした理論を学ぶことで新たなブレイクスルーが得られるように思います。

　思えば、オブジェクト指向以来、新たなパラダイムを得られなかったことがソフトウェア分野の停滞を招いた大きな問題のように感じます。例えば、古い言語ですがCOBOLは事務分野の組織間のワークフローを記述するのに非常に適したモデル化言語でした。

　さて、あなたの問題を相応しいパラダイムでモデル化していますか？

　次回はシステムを構築するための体系、システム工学について紹介します。

■SQiPという名称に込めた思い
　2007年8月、日本科学技術連盟（JUSE）ソフトウェア生産管理研究会（SPC：Software Production Control）は、その名称をソフトウェア品質委員会（SQiP：Software Quality Profession）へと変更した。そして直後の同年9月に開催されたシンポジウムにおいて、名称変更した研究会の目的、活動範囲、活動方針、ビジョンなどをご紹介するかたちでお披露目をした。
　SPCが、JUSEに産声をあげたのは1980年である。SPCでは、わが国におけるソフトウェア製品の品質向上と効果的開発の方法論の確立をめざして、日本的品質管理をソフトウェア生産に適用するための調査・研究・普及を行ってきた。ソフトウェア産業への日本的TQMの考え方、方法論、手法等の普及を行い、TQMとソフトウェア工学の「結婚」による新たなパラダイムの構築を目指し、産・官・学による相互研鑽の場を提供し活動してきた。
　時が流れ、身の回りに様々なコンピュータシステムがあふれ、システムの肥大化、複雑化が進み、今やソフトウェアは多くの製品・システム、社会・経済・産業の基盤となった。ソフトウェアの重要性は増す一方であろう。設立当初から「ソフトウェア品質」を軸に活動を行ってきたSPCは、原点に立ち返り、SPCの存在意義、SPCの位置づけ、これからのSPCについて検討し、あわせて長く親しまれてきたSPCという呼称についても、説明なしではその意味をなかなか理解してもらえない現状に鑑み、呼称を変更することにした。
　実は、SQiP (Software Quality Profession；スキップ)という名称には特別の思いがある。研究会の主題はソフトウェア品質であるから、“software”“quality”の2つの単語は自然である。私たちが特別の思いを込めたのは“profession”という用語に対してである。どんな思いを込めたのか、背景から説明させてほしい。

 

■ソフトウェア産業競争力
　日本のソフトウェア産業は、1980年代までは、メインフレームを中心として世界に恥ずかしくないレベルにあった。ところがその地位は「ネオダマ」という用語が広まる1990年代半ばにはガタガタと崩れる。「ネオダマ」という用語は2～3年はやっただけであったが、ソフトウェアのパラダイムシフトを的確に表現していた。「ネ」はネットワーク、「オ」はオープン、「ダ」はダウンサイジング、「マ」はマルチメディア。「ネオダマ」の波に乗って普通の人がソフトウェアを大量に使うようになった。ソフトウェアは、自分でプログラムを組む代物から、使うものに変わっていった。
　こうしたなかで、日本のソフトウェア産業競争力は低下していった。ある産業分野の国際競争力を計る尺度は輸出入比率であろう。どの程度なのだろうか。この問いに正確に答えるのはなかなか難しい。確かなデータがないのだ。
　一つにJISA（情報サービス産業協会）の調査があり、年によって違うが、輸出が輸入の10～30倍程度と報告されている。しかし、この調査はアンケート調査の集計であり、全貌を表しているとは言えない。JEITA（電子情報技術産業協会）の調査もある。少し古く2000年のものだが、輸出入比率は約100倍と報告されている。JISAの調査より信頼できるだろうが、何せ古く、残念ながら、その後は本格的な調査がなされていない。
　正確な数字は分からないが、輸出入比率という点で日本のソフトウェア産業の国際競争力は惨憺たる状況にあるといえる。だが嘆くことはない。石油を例にとれば、輸入100%だが石油を原料とした高付加価値製品を産出できれば、経済的には問題ない。輸入が圧倒的なソフトウェアは、果たしてそのような製品なのだろうか。

 

■ソフトウェアは国力を左右する
　日本のGDPは約500兆円と考えてよい。幸か不幸か、低成長・安定成長が続き、リーマンショック以降、東日本大震災、超円高などの影響でさらに下がっているが、この20年ほどはバカの一つ覚えで500兆と言っていれば間違いない。そのうち情報サービス産業の売り上げは20兆円程度だろう。ソフトウェア生産高はその7～8割だろう。輸入が多くて、GDP比率がこの程度ということは、情報化社会だと騒がれ、ちょっと賢そうな若者がソフトウェア会社で人生を切り開こうとする現代において、極めてまずいのではないだろうか。
　いやそんなことはない。輸入が多くてもよい。ソフトウェアの生産高が高くなくてもよい。そのソフトウェアによって製品、システムの付加価値がどれほど増しているかが重要なのだ。鉄鋼は１トン数万円、これを主材料とする自動車にすると１トン100～200万円以上になる。ソフトウェアもそうなっていればよい。
　ソフトウェアそのものの生産高でなく、ソフトウェアが社会・経済に及ぼす影響力の大きさに注目すべきである。ソフトウェアは、生活、社会、経済のインフラになっている様々な製品に組み込まれている。現代の多くの製品は、ソフトウェアでその特徴が決定づけられるようになっているのだ。
　家電製品を例にしたらよく分かる。現代のテレビには大変なソフトウェアが内在している。デジタル化して相当きれいな画像が見られるようになったが、ソフトウェアでさまざまな機能を付加して、また動く絵をきれいに見せるようにしている。車もすごい。最初はエンジン制御に使って無駄のない効率的な燃焼、それゆえに環境に優しい燃焼を可能にした。走行性能についても、ABSがもはや基本の基本になるくらい高度な車両制御をし、最適な駆動力、姿勢で走行できるようにした。ナビも進化した。地図情報を使いこなすことによって、これからの世界は想像を絶することが可能になるだろう。携帯電話、携帯端末もしかり。これらは昔のスーパーコンピューター以上の能力を持っているのだから、まさにお化けソフトウェアと言ってよい。
　このように、ソフトウェアは経済・社会インフラとしても、製品・サービスの質を左右するものとしても非常に重要である。生産高はGDPのせいぜい3%程度かもしれないが、影響力は少なくともその10倍はあるだろう。現代のソフトウェアは国力を左右するといって過言でない。ソフトウェアによって様々なものが効率的になり、また価値あるものが生まれやすくなるという意味で重要である。

 

■プロフェッション
　現代社会においてこれほど重要なソフトウェアに対して、その品質を主題にした研究会の名称に、私たちは“profession”という用語を使ったことになる。辞書を調べてみると、「知的職業（弁護士、医師など）」「（一般に）専門的職業」と説明されている。英英辞書では、例えば“an occupation requiring considerable training and specialized study”（かなりの教育訓練と専門的な学問を必要とする職業）などと説明されている。これら一般的な辞書で説明されるprofessionの意味からは、私たちが何にこだわったかは分からないだろう。
　職業に貴賤はないというが、古来より西欧社会において、profession（専門的職業）として特別扱いされてきた職業が3つある。それは、聖職者religionist、弁護士lawyer、医師medical doctorである。プロフェッションに共通の側面は、第一に、それが重要な分野の職業であるということである。宗教、法律、医療というように、信仰を、法を、生命を司る重要な分野の専門家である。第二に、正しさが要求される。重要であるからこそ、公正性と正統性が求められる。正統性という概念を理解できるだろうか。“integrity”が対応する概念だが、正直、誠実、高潔、廉直、完全無欠、真っ当、まともというような意味合いである。第三に、自治的であることが求められる。状況によっては、俗世間・現世のしがらみを超越した治外法権的な扱いを受ける身であるからこそ、自律が求められ、自己規制が求められる。典型的なものは自治的懲戒制度であろうか。自ら職業団体を構成し、その内部において相互に規制する制度を運用して正しさを維持しようとする。ちなみに、日本の医師会は、残念なことに本来は有すべきその機能を失っている。
　さて、ソフトウェアを生業とする人は、その重要性に鑑みて、聖職者、弁護士、医師に次ぐ第4のプロフェッションとしての自覚を持つべきではないだろうか。それは言い過ぎだ、その前に教師こそが第4だろうとの鋭い指摘が飛んできそうである。確かに、教育の名のもとに人間を変える職業だから、治療と称して生体にメスを入れる医師と同等の責任を持つべきだろう。第4でも第5でもよい、現代の経済・社会インフラを、そして製品・サービスのフィーチャーを決定づけ、国力・産業競争力を左右してしまうソフトウェア産業に携わる人々は、プロフェッションと呼ばれてしかるべき職業に就いていることを自覚すべきである。その思いが、SQiPという名称には込められている。
　私たちは、ソフトウェアを通して、安全・安心社会を実現しなければならない。産業や生活の質的レベルと効率を上げなければならない。これらによってこの経済社会を活性化させなければならない。こうしたソフトウェア技術者・管理者には、高潔な倫理観、価値観の持ち主であり、コトを進めるにおいて基本的能力に優れ、もちろん高い専門性を持ち、自律的かつ自治的でなければなるまい。

1. はじめに

　3回に渡ってソフトウェア品質技術の歴史をご紹介しました。ここ10～20年(1990年以降)の状況についてはあまり調査をしていないのでご紹介できませんでしたが、このあたりは私よりも現役の方のほうがよくご存知でしょう。
　ところで、みなさん、以下の発表があるシンポジウムが開催されると聞いたら聴講したくなりませんか?

　　1. 制御用ソフトウェア一貫生産支援システムによる品質向上効果
　　2. UNIXを用いた対話型テスト・ベッドによる品質保証
　　3. バグ原因の究明と対策を指向した品質向上活動
　　4. ソフトウェアの品質向上を指向したバグ分析の一方法
　　5. ソフトウェアテスト項目の系統的作成技法と効果
　　6. ソフトウェア構造とドキュメントの改善による品質向上の事例
　　7. ユーザ要求分析の品質向上
　　8. 外注における工程管理の事例
　　9. ソフトウェアハウスにおける知的プログラミング装置の開発と評価
　　10. 管理図（Ｃ及びＵ）を応用したソフトウェアの品質解析
　　11. ワークシートを中心としたシステム開発作業要領の作成と適用
　　12. ソフトウェアの開発履歴の分析による品質管理
　　13. ソフトウェア設計仕様の系統的レビュー技法
　　14. 製造業・建設業における品質管理の考え方および手法のソフトウェア産業への活用

2. 温故知新のススメ

　実はこのプログラム、今から30年前の1981年7月9日～10日に開催された「第一回ソフトウェア生産における品質管理(SPC)シンポジウム」(現在のSQiPシンポジウム)のものです。タイトルは現在でも通用しそうです。おそらく内容的にも現在のヒントになるものがあると思います。「年寄りの懐古主義」との謗りを受けるかもしれませんが、みなさんが現在取り組まれている課題は本質のところでは昔検討されていたこととあまり変わらず、それを知らずに対策を「再発見」しているようなことがあるのではないでしょうか。
　私がソフトウェア検査業務の一環でテスト設計ツールの開発やテスト技法の社内教育を担当していた1980年代に比べると、いろいろな電子ドキュメントがインターネット検索エンジンを通じて入手できる現在の環境は夢のようです。当時は会社の図書室で書籍を借りて勉強したり、資料英訳の際はIEEE論文集を閲覧して”テスト項目”は”test case”と訳せばよいのかなどと技術用語を調べたりしていたものでした。このようにソフトウェアテスト技術の歴史をみなさんに紹介できるのもインターネット技術の賜物です。私の歴史調査の方法は、①調べるテーマを決める、②テーマに関する論文や書籍を読む、③その論文や書籍に書かれている先行研究や関連研究を調べる、④参考文献リストから先行文献を調べる、⑤ルーツに辿りつくまで②～④を繰り返す、というものですが、これは検索エンジンと電子ドキュメントがないととてもできません。
　品質技術に関して当時の検討状況や歴史に興味をもたれた方は是非いろいろな文献を調べたり先輩や上司の方々に尋ねたりしてみてください。きっと何かしらの気づきやヒントが得られる筈です。

3. 文献の入手方法

　ソフトウェア品質技術の歴史を調べるために私が利用している文献入手先をご紹介します。
(1)インターネット古書サイト
　　海外(米国)では、amazon market place 、AbeBooksやalibrisなど
　の古書サイトがあります。また、BookFinderで古書サイトの横断検索ができます。
　　日本では、amazonマーケットプレイスなどの古書サイトやYahooオークションなどのオークションサイトが利用できます。
(2)論文のダウンロードサイト
　• IEEE Xplore (契約必要)
　　　IEEEのシンポジウムで発表された論文、IEEEの雑誌(COMPUTER, Softwareなど)に掲載された論文などがダウンロー
　　ドできます。また、IBM社のJournal of Research and Development とSystems JournalがIBMサイトからIEEE Xploreに移管
　　されたのでダウンロードできます(IBMサイトの時はフリーだったのですがIEEE Xploreになったので有料になってしまいま
　　した)。
　• ACM Digital Library (契約必要)
　　　米国計算機学会(ACM)関係のオンラインジャーナル、論文などがダウンロードできます。
　• DTIC Online
　　　米国国防総省のDTIC(Defense Technical Information Center、国防技術情報センター)のテクニカルリポート(ADリポー
　　ト)のデータベースです。私はここでMcCallの品質モデルの文献”Factors in Software Quality, RADC-TR-77-369″のPDF
　　文書を入手しました。
　• CiNii (NII論文情報ナビゲータ[サイニィ])
　　　国立情報学研究所が運営している論文や図書・雑誌などの学術情報を検索できるデータベース・サービスです。前回ま
　　での記事で紹介した情報処理学会の「情報処理」「情報処理学会論文誌」の論文もダウンロード可能です(古いものは無
　　料)。
　• 情報処理学会電子図書館
　　　情報処理学会の会誌(情報処理)、シンポジウム論文集、研究会の研究報告などのPDF文書がダウンロードできます(非
　　会員でも無料で読める文書もあります)。
　• IEICE Transactions Online
　　　電子情報通信学会の論文がダウンロードできます(会員のみ)。
(3)図書館、論文などの複写サービス
　• 国立国会図書館
　　　利用者登録しておけば、蔵書検索・申込システムを通じて「遠隔複写サービス」を申し込むことにより、郵送又は宅配便
　　でコピーを送付してもらえます。海外の雑誌や論文なども所蔵されています。前述の米国DTICのテクニカル・リポート
　　(ADリポート)も所蔵されているものがあります。
　• 大学図書館
　　　大学図書館は外部の人も利用可能です。前述のCiNiiで全国の大学図書館等が所蔵する本の情報を検索できます。
　• ビジコミ図書館
　　　日本電信電話公社(現NTT)が専用線サービスの普及拡大を目的に1964年に創刊した月刊誌「ビジネスコミュニケーショ
　　ン」のコピーが入手可能です。私はこの雑誌で1967年～1968年に書かれたテストに関する記事をみつけましたが、私が入
　　手した資料の中で日本でテストの方法が書かれた最も早期のものです。

4. 日科技連ライブラリ

　日科技連ソフトウェア品質シンポジウム(SQiPシンポジウム)は、2008年開催から講演資料がWebサイトで公開されていますが、それ以前のものは著作権の関係で資料の掲載ができないようです。また、シンポジウムのプログラムのWebサイトでの公開も2004年の第23回ソフトウェア生産における品質管理シンポジウムからですので、それ以前の開催状況はWebサイトでは把握できない状況です。
　冒頭ご紹介した第1回SPCシンポジウムのように過去のシンポジウムで多くの興味深い発表が行われています。今回の「ソフトウェア品質のホンネ」の執筆にあたり、SPCシンポジウムの第1回～10回(1981年～1990年)までの発表プログラムを電子文書化してみました。日科技連の以下のWebサイトに掲載していただくことになりましたので是非ご覧ください。発表者の中には現在のソフトウェア品質技術コミュニティの重鎮の方のお名前もあります。みなさんの上司や先輩の方のお名前も見つかるかもしれません。

　　　日科技連ソフトウェア品質シンポジウム
　　　過去のプログラム概要（第1回～第10回)

　SPCシンポジウムの発表報文集は日科技連ライブラリに所蔵されていますので、発表タイトルで興味をもたれたものがあれば日科技連で閲覧できます。

5. おわりに

　ソフトウェア品質技術の歴史を振り返ってきましたが、これをみなさんが新しいことにチャレンジし新たな歴史をつくるための糧にしていただけると幸いです。
　なお、拙ブログでもソフトウェアテストの歴史の参考文献や歴史年表などを掲載していますので参考にしてください。

 

1. はじめに

　ソフトウェアテストシンポジウム(JaSST)は来年2012年1月で開催10周年、またDevelopers Summit(デブサミ)も同じく2月で10周年を迎えるそうです。2000年に入って組織の壁を越えたソフトウェア技術者のコミュニティ活動が活発になり、この数年さらに活発になってきたように感じます。Blog、各種SNS、twitterなどコミュニケーション手段の進化も活動の活発化を促進しているのでしょう。
　日本のコンピュータ産業の歴史において、業界横断の活動としては、国家主導すなわち通商産業省のコンピュータ産業育成政策の推進の一環で1958年に発足した日本電子工業振興協会(電子協)によるものが最初だと思われます。電子協はコンピュータメーカを目指す会社を会員とし、各社のコンピュータを集めた計算機センターの設置、各種の調査活動、さらにソフトウェアの共同開発なども推進しました。トップダウンによるものではありますが、この分野のコミュニティ活動の嚆矢と言えるのではないでしょうか。
　ソフトウェア品質技術の歴史においても、いろいろなコミュニティの活動が技術の発展に寄与してきました。今回はソフトウェアの品質やテストに関するコミュニティの歴史を紹介します。

2. ソフトウェア品質技術コミュニティ事始め

(1)日本電子工業振興協会(電子協)
　　電子協ではソフトウェアの品質技術に関する調査活動も実施されています。国内の図書館の目録の検索結果から1970
　年代に以下のソフトウェアの信頼性に関する調査報告書が発行されていることが分かりました(残念ながら私は内容未確
　認)。
　　　　1974年「ソフトウェアの信頼性に関する調査」(国際動向専門委員会報告書)
　　　　1976年「ソフトウェア信頼性に関する調査－設計・製造技術と測定評価技術－」
　　　　　　　　　(ソフトウェア信頼性専門委員会報告書)
　　　　1977年「ソフトウェア信頼性に関する調査－保守技術とプロジェクト管理技術－」
　　　　　　　　　(ソフトウェア信頼性専門委員会報告書)
　　1977年にはソフトウェアエンジニアリング専門委員会が設置され、各社の委員が協力して米欧の技術調査を行い「ソフト
　ウェアエンジニアリングに関する調査」の発行を開始しています。ソフトウェアの品質技術に関しては、1978年度にテスト支
　援ツールの調査(これも私は内容未確認)、1979年度に米欧の当時の最新文献に基づいてソフトウェアの生産性の定量的
　評価、品質特性ごとの定量的評価の定義や尺度がまとめられています[1] 。これらの報告書は書籍ではないので国会図書
　館でも所蔵されておらず現在は内容を確認することができないのが非常に残念です(1979年度の報告書は筆者所属企業
　で所蔵)。私は特に1978年度のテスト支援ツールの調査報告を閲覧したいと思っているのですが、所蔵されている企業など
　ありましたら情報提供いただけると幸いです。

(2)情報処理学会
　　1960年に情報処理学会が設立されたことは前回ご紹介しました。その後、1970年代に入ってソフトウェア工学が注目され
　るようになり1977年に学会内にソフトウェア工学研究会が設置されています。この研究会では産学の研究者や技術者から
　ソフトウェア工学に関する研究報告が行われており(研究報告論文は情報処理学会のWebサイト[2]で閲覧できます)、テス
　ト技術に関しては1980年代に原因結果グラフや直交表によるテストなどが報告されています。

(3)日本科学技術連盟(日科技連)[3][4]
　　日科技連は1946年に発足し1951年にデミング賞を制定するなど日本の品質管理技術向上の推進役となっています。ソフ
　トウェアに関する取り組みは1970年代後半から始まり、1980年にソフトウェア生産管理(SPC)研究委員会が発足しました。
　[5]によると「これをもって、日本の産業界におけるソフトウェア品質管理の活動が開始されたといってよい。委員会設立に尽
　力したのは、菅野文友(東京理科大学＝以下いずれも当時)、水野幸男(NEC)、吉澤正(筑波大学)、森口繁一(東京大学)、
　石井康雄(富士通)、花田収悦(NTT)などそうそうたる顔ぶれであった。」とのことです。 以来、産学官の品質管理推進の専
　門家の協力により、SPCシンポジウム(ソフトウェア生産における品質管理シンポジウム)、セミナー、研究会の開催、ソフトウ
　ェアの品質に関する書籍の出版などの活動が進められています。なお、SPC研究委員会は2007年9月にSQiPソフトウェア
　品質委員会と改称されました。

(4)日本品質管理学会
　　日本品質管理学会は1971年に設立されました。ソフトウェアに関する活動を学会誌「品質」の論文掲載状況でみると、ソフ
　トウェアに関する論文の最初は1981年4月の”ソフトウェア生産とTQC”[6]です。1982年4月にはソフトウェアの品質管理と生
　産性の特集[7]が組まれており、日科技連SPC研究委員会とほぼ同時期に日本品質管理学会でもソフトウェア品質への取
　り組みが開始されています。

(5)ソフトウェア技術者協会(SEA)[8]
　　1980年12月に第1回のソフトウェアシンポジウムが開催されました。当時はソフトウェア産業振興協会の技術委員会の主
　催で開催されましたが、1985年のソフトウェア技術者協会(SEA)の設立後はSEA主催の技術シンポジウムとして毎年開催さ
　れています。

(6)ソフトウェアテスト技術者交流会(TEF)[9]
　　1998年9月にソフトウェアテスト技術者交流会(TEF:Testing Engineer’s Forum)が発足しメーリングリストをつかった技術交
　流が始まりました。その後、2003年3月に第1回ソフトウェアテストシンポジウム(JaSST)を開催するなど活動の枠を広げ、日
　本におけるソフトウェアテスト技術向上活動の中心となっています。

3. 日科技連コミュニティと直交表テスト

　実験計画法で用いられる直交表を利用してソフトウェアのテストケースを作成する技法「直交表テスト」は日本では1980年代前半に考案され、米国においては1990年代に普及が始まっていますが、この直交表によるテスト技術開発や普及に日科技連コミュニティが(結果として)一役買っていたことをご紹介します。
　ソフトウェアテストへの直交表の利用は1983年頃に富士通で開始され、1984年の日科技連の第4回 SPCシンポジウムで”実験計画法を用いたソフトウェアのテスト項目設定法”[10]が報告されました。その後、1980年代後半に他社での適用報告がありましたが大きくは広がりませんでした。現在のようにわが国の多くの企業で直交表テストが実施されるようになったのは、2003年になって富士ゼロックスのHAYST法が発表されてからのことです。
　一方、米国では1992年にAT&T社が直交表を利用したツール(OATS: Orthogonal Array Test System)の適用成果を発表[11]して以降、多くの研究者や技術者により直交表やPairwiseテストの技法が研究開発され広く活用されるようになりました。AT&T社は1980年代初めから田口玄一博士を招いて品質工学(タグチメソッド)の導入に取り組んでいましたが、[12]によるとソフトウェアテストへ直交表を適用することは富士通の取り組みを知ったのがきっかけのようです。1989年に日科技連SPC研究委員会は第1次ソフトウェア製品品質管理調査団(1SPCT)を組織して初の海外視察を行いましたが、その視察途中、事前に富士通に説明要請があったAT&T社Bellcoreを訪問し、富士通の視察メンバー2名と実験計画法に暁通されていた視察団長の菅野先生から技術紹介を行ったそうです。私はこの技術紹介がAT&T社でのOATSの開発につながったのではないかと考えています。
　ところで、筆者はソフトウェアテストへの直交表の適用が書かれた最初の文献は富士通のもの[10]だと思っていたのですが、数年前に1979年発刊の菅野先生の”ソフトウェア・エンジニアリング” [13]にソフトウェアテストへ実験計画法を適用する旨の記述があることを知りました。この記述を見たとき、お釈迦様の手のひらの上の孫悟空の心境になりましたが、私はこの実験計画法の適用のアイデアが日科技連SPCコミュニティで共有され、1983年～84年にかけて富士通が具体化したということではないかと推測しています。
　直交表テストは日科技連コミュニティで生まれたものと考えてよいと思いますが、その後は米国で発展・成長したということになります。当時は技術を成長させる点においてコミュニティの力に差があったということかもしれません。現在の日本のコミュニティではこのようなことはないと信じています。

　次回の最終回はソフトウェア品質技術の歴史の辿り方についてお話しします。

 
＜参考文献＞
[1] ソフトウェアエンジニアリング専門委員会, ソフトウェアエンジニアリングに関する調査－ソフトウェアの生産性と品質の評
　　価方法－－ソフトウェア技術者の効果的教育－, 日本電子工業振興協会, 55-C-395, 昭和55年3月(1980)
[2] 情報処理学会電子図書館→研究報告→ソフトウェア工学(SE)
　　http://www.bookpark.ne.jp/cm/ipsj/select_signotes2.asp?category2=SE
[3] 菅野文友, SPC活動の思い出(日科技連 創立50年史 第3部 思い出の記), 日本科学技術連盟, p.287, 1997
　　http://www.juse.or.jp/about/407/
[4] ソフトウェア生産における品質管理(日科技連 創立50年史 第1部 50年の歩み), 日本科学技術連盟, pp.211-213, 1997
　　http://www.juse.or.jp/about/407/
[5] 川田恵三, 第220回 ソフトウェア品質管理の歴史(その１)(コンピュ－タ産業発展史), BCN This Week 1999年11月8日, 　　　　
　　vol.817, 1999
[6] 小林龍一, ソフトウェア生産のTQC, 品質/日本品質管理学会, 11(2), p.45, 1981
[7] 小林龍一, ソフトウェアの品質管理と生産性, 品質/日本品質管理学会, 12(2), pp.3-7, 1982
[8] SEA ソフトウェアシンポジウムの歴史
　　http://www.sea.or.jp/Events/symposium/sshist.html
[9] ソフトウェアテスト技術者交流会(TEF)
　　http://www.swtest.jp/wiki/index.php?swtest.jp%2Fwiki%2Fforum
[10] 佐藤忍, 下川浩樹, “実験計画法を用いたソフトウェアのテスト項目設定法,” 第4 回ソフトウェア生産における品質管理
　　シンポジウム発表報文集, pp.1-8, 1984
[11] R. Brownlie, J. Prowse and M. S. Phadke, “Robust testing of AT&T PMX/StarMAIL using OATS,” AT&T Technical
　　Journal, vol.71, no.3, pp.41-47, 1992
[12] 吉田征, 技術の伝承と移転, 日科技連, 1994
[13] 菅野文友, ソフトウェア・エンジニアリング －ソフトウェアの開発・生産と品質保証－, 日科技連, 1979

 

 

1. はじめに

日本でコンピュータ・プログラムの「テスト」という文字が現れた最も早期の文献は、私が調べた範囲では、1958年に気象庁の方が書かれた”大型電子計算機 IBM 704をプログラムテストして”[1]です。

わが国では1959年春に気象庁が官公庁として初めて科学計算用の大型コンピュータIBM 704を導入し世界で4番目に数値予報業務を開始しました。この文献では、導入の前年1958年夏に米国でIBM 704を借りてプログラムのテストをしたときの状況が書かれています。ちなみに、数値予報というのは、物理学の方程式をもちいて風や気温などの時間変化をコンピュータで計算し将来の大気の状態を予測する方法で、業務を開始した1959年の7月に上陸した台風5号の進路を的確に予想したそうです。

日本初の商用コンピュータの導入は、1955年にUNIVAC 120が設置された東京証券取引所と野村證券と言われています。その後、1959年3月に三和銀行が銀行として初めてコンピュータ(IBM 650)を導入、国鉄が1960年1月に座席予約システムMARS-1のサービスを開始するなど1960年頃からコンピュータが本格的に社会に入り始めました。

2. ソフトウェア検査の黎明

1960年に情報処理学会が設立されました。設立当初から学会誌「情報処理」の発行が始まっており、この内容から日本の情報処理技術やソフトウェア技術の進展状況を見ることができます。

1964年11月に「情報処理」誌で初めてソフトウェア特集が組まれました。当時は国産メーカの第一世代のOSの開発や、ユーザ企業の初期のオンラインシステムが構築された時期であり、大規模なソフトウェア開発における課題が認識され始めていました。そのような時期のソフトウェア特集の座談会記事[2]の中にプログラムの検査に関する興味深い発言があります。発言は矢島敬二氏(当時、日本科学技術研修所)です。

—————————————————————————————————————————————————

プログラムの検査ということの中にある問題として、そろそろプログラムを検査する組織というものを考えていかなければならないんじゃないかと考えているわけです。特にシステム・プログラムというようなものを作りあげたときに、それのでき具合を調べる機能というものは、つくった人と別の機能で行われるべきじゃないかと思うわけです。仕様を決める段階からその検査をやる組織というものが加わって、最終製品についてつくった側とは独立に、いろいろなテスト・プログラムをかけて検査するというようなことをやっていかなければいけないんじゃないかと思います。それはいくつかのコンパイラーを使ったり、あるいは、つくっていく過程を見て感ずることなんですけれども。

—————————————————————————————————————————————————

1960年代半ばには、既に第三者による検査の必要性が認識され、さらに上流工程への検査部門の関与についても言及されていることに私は驚きました。

座談会ではこの発言に対して、「検査から製造部門に圧力がかかるのは問題だ、大勢かかればスピードが落ちてくる、検査はつくっている最中から横から口出しはしないほうがいい」という主旨の異論が提起されます。これに対して、「非常に先端の領域では、検査と製作を分けたら能率が落ちることもある。しかし、関数ルーチンなどはやっぱり検査が必要。何らかの形で別の人間が検査をやるというような形にしたほうがいい面がある」と議論は続きます。最後に森口繁一教授が次のようにまとめられました。

—————————————————————————————————————————————————

むしろ、検査部門というのは工程の状況を把握するための情報をとる感覚器官なんだと、それを工程に正しくフィードバックして初めて工程をよい状態に維持できるし、ときには改善も可能になるんだというような解釈が、近代的品質管理における検査の職能である。だから、そういう位置づけにおいて、製造部門が工程内でやるのよりはもっと組織的に、もっと根本的に検査することができるような検査の方法をもつ、そういう意味の検査機能は、やはり考慮してもいいんじゃないかという気がするね。

—————————————————————————————————————————————————

森口教授のお話しはソフトウェア検査部門のあり方として今でも通用する基本的な考え方だと思います。

3. 企業のソフトウェア検査への取組み[3]

企業の組織的なソフトウェア検査への取り組みは、前述の「情報処理」誌の議論より少し時間を経て始まりました。

1960年代半ばに、まずソフトウェア開発部門自身がハードウェア部門から独立した部門となります。たとえば、日立製作所では1965年に社内に分散していたソフトウェアエンジニアを招集してシステムプログラム部が創設されました。また、富士通でも1966年にソフトウェア開発部ができハードウェア部門の中の一つの課(プログラム課)からソフトウェアを開発する独立した部門となりました。

その後、日立製作所では1969年2月にソフトウェア工場が開設され、工場制度におけるソフトウェアの検査機能が確立していきました。富士通では1968年にプログラム試験課が設けられ、開発者のデバッグ支援の役割から脱却してユーザマニュアルに基づいてソフトウェア製品の評価を行うようになり、1971年には出荷前の製品検査も制度化されました。

4. ソフトウェア検査の確立

ソフトウェア検査に関する最初の文献は1972年5月の「情報処理」誌で発表された菅野文友氏(当時、日立製作所ソフトウェア工場)の”ソフトウェアの検査の考え方”[4]だと思われます。この論文では、1969年に開設された日立製作所ソフトウェア工場で新たに開始されたソフトウェア検査業務が2～3年を経て軌道に乗った状況が書かれています。

—————————————————————————————————————————————————

われわれは、過去数年間ソフトウェア検査の確立に努力してきた。当初ソフトウェアにおいては、検査という語は存在していなかった。単に言葉がなかったばかりではなく、検査という行為もそれまではなかったといってよかろう。このような周辺事情のなかで、ソフトウェアは製品であるという認識のもとに、近代的ソフトウェア・エンジニアリング確立の一つとして、現在まで検査技術の設定に努力し、一応軌道に乗った様相で、ソフトウェア検査業務を遂行している現状である。

—————————————————————————————————————————————————

開発された検査技術の中には、成長曲線やゴンペルツ曲線などを使った品質予測手法[5]や先取り評価手法(QP:Quaity Prove)(現在は探針と呼ばれている)[6]など、現在も活用されている重要な技術があります。

この日立製作所のソフトウェア検査の考え方は国内他メーカでも参考にされ、日本独自のソフトウェア検査活動として発展しました。菅野文友先生は1983年に出版された「ソフトウェアの信頼性」で次のように書かれています[7]。

—————————————————————————————————————————————————

わが国におけるソフトウェアの生産活動の場合、欧米各国と大きくその様相を異にするものの1つが、検査部門の活動である。わが国における検査部門の主目的は、品質保証(quality assurance, QA)にある。すなわち、たんなる試験(test)でもなければ、合否判定だけの狭義の検査(inspection)だけでもない。また製品出荷時のチェックアウト(check out)でもない。当該製品生産企業において、ユーザ側の観点に立脚して品質評価を行う部門が検査部門である。そして、その品質評価は、その製品のライフサイクルを念頭においたものである。

—————————————————————————————————————————————————

Gelperinらが論文”The Growth of Software Testing”で整理した米国のソフトウェアテストの成長過程では1983年からソフトウェアのライフサイクルを通じた評価活動の中にテストが位置付けられましたが、1972年5月の「情報処理」誌で書かれた日立製作所のソフトウェア検査のプロセス(図1)を見ると、既に1970年前後にはライフサイクルを念頭においた活動が開始されていたことが分かります。

図1　ソフトウェア検査のプロセス

(菅野文友, ソフトウェアの検査の考え方[4] 図2を引用)

5. ソフトウェア検査部門[8]

米国では，1960年代後半から1970年代に軍や原子力システムでのソフトウェア開発の増加にともなってV&Vの概念が現れてきたのですが、同時期に日本では「源流管理」や「品質の作り込み」などの日本的品質管理の考え方をソフトウェアに適用してソフトウェアの品質保証や検査の実践が始まりました。組織の中でその推進役を担ったのが検査部門（あるいは品質保証部門）です。

独立した部門が検査を実施するという点は米国のIV＆V（Independent V&V）と同様ですが、IV&Vでは開発部門とV&V実施部門が分業的な関係であるのに対して、検査では開発部門に最終テスト工程までの責任をもたせた上で、中間段階で検査部門による工程監査を行うとともに、最終テスト工程の後に検査部門の製品検査工程を追加するところに特徴があります。

日本では広義の意味のソフトウェアの「検査」は単なる用語の域を超えて，日本におけるソフトウェア品質マネジメントの文化を象徴する概念のひとつだと思います。

次回は日本のソフトウェア品質技術に関するコミュニティの歴史をお話しします。

 

＜参考文献＞

[1] 藤原滋水, 大型電子計算機IBM704をプログラムテストして, 電子工業/小峰電子工業, 7(10), pp.38-45, 1958

[2] 森口繁一 他, ソフトウェアの動向(座談会), 情報処理/情報処理学会, 5(6), pp.354-368, 1964

http://ci.nii.ac.jp/Detail/detail.do?LOCALID=ART0003003626&lang=ja

[3] M. A. Cusumano, “Japan’s Software Factories: A Challenge to U.S. Management”, Oxford University Press, 1991 (日本のソフトウェア戦略, 三田出版会, 1993)

[4] 菅野文友, ソフトウェアの検査の考え方, 情報処理/情報処理学会, 13(5), pp.294-301, 1972

http://ci.nii.ac.jp/Detail/detail.do?LOCALID=ART0003045096&lang=ja

[5] 坂田一志, ソフトウェアの生産管理における予測技法の定式化-静的な予測および故障率推移モデル, 電子通信学会論文誌Ｄ, 57(5), pp.277-283, 1974

http://search.ieice.org/bin/summary.php?id=j57-d_5_277&category=D&year=1974&lang=J&abst=

[6] 坂田一志, ソフトウェアの生産管理における予測技法の定式化-動的な予測:先取評価手法, 電子通信学会論文誌Ｄ, 57(5), pp.284-291, 1974

http://search.ieice.org/bin/summary.php?id=j57-d_5_284&category=D&year=1974&lang=J&abst=

[7] 菅野文友，ソフトウェアの信頼性，日科技連出版社, p.64，1983

[8] SQuBOK策定部会, ソフトウェア品質知識体系ガイド SQuBOK Guide, オーム社, 2007

 

 

1. はじめに

　6年ほど前からソフトウェアテスト技術に関する歴史を調べ始めました。昔の文献を探し出して自分なりに技術のミッシングリンクをつなぐのが面白くなり、今ではテストだけでなく品質技術全般へ調査範囲をひろげています。
　ものごとの歴史や由来を調べる目的はいろいろあると思いますが、私はソフトウェア品質技術の歴史についてはつぎのようなことに意義を感じています。

●自分の解釈や理解が正しいのかを確認する

　　いろいろな技術用語やＸＸ技法といった名称が数多く使われていますが、名称だけが一人歩きしていろいろな解釈をされ
　ていることがよくあります。歴史や由来に立ち返って本来の意味を理解しておきたいものです。

●技術が生み出された背景を知る

　　技術は何らかの課題や問題を解決するために考え出されたものなので、出現背景をたどることで、その技術の目的やあ
　りがたみが理解できる筈です。背景や目的が分かれば、場合によっては新たな解決手段(技術)も生み出せるかもしれませ
　ん。

●社会/時代背景や他分野とのつながりを知る

　　技術は単独で進化するものではなく社会や他分野の技術との相互影響を通じて変遷するものです。ソフトウェア品質技
　術もソフトウェア(システム)の利活用形態の変化や開発技術の進化に伴って変遷している筈であり、大きな流れの中で品
　質技術を理解することが大事だと思います。

本コラムでは、みなさんに知っておいていただきたい、あるいは再認識していただきたいソフトウェア品質技術の歴史をいくつかご紹介します。
最初はテストの歴史です。

2. テストの考え方の歴史的変化

　プログラムを書いたら何らかの確認をするだろうと考えると、ソフトウェアテストはコンピュータの出現と同時に生まれた作業と言えるかもしれません。
　GelperinとHetzelは1988年に”The Growth of Software Testing”[1]という論文で、テストの考え方の成長過程をつぎの5つの時代に区分しました。各々の時代の始まりを象徴する文献が発行された年を時代の区切りとしています。

      　　　　～1956年: デバッグ指向の時代(The Debugging-Oriented Period)

　　1957年～1978年: 論証指向の時代(The Demonstration-Oriented Period)

　　1979年～1982年: 破壊指向の時代(The Destruction-Oriented Period)

　　1983年～1987年: 評価指向の時代(The Evaluation-Oriented Period)

　　1988年～　　　　 : 予防指向の時代(The Prevention-Oriented Period)

(1) デバッグ指向の時代(～1956年)

　　まだデバッグとテストの区別がない時代です。ソフトウェアはハードウェアの一部として考えられていましたし、そもそも「ソ
　フトウェア」という言葉もなかった時代です。「テスト」に関しても、プログラムを書いたらチェック(checkout)するという程度で
　あり、checkout、debugging、testingという用語の定義も明確ではありませんでした。

(2) 論証指向の時代(1957年～1978年)

　　テストはプログラムが仕様を満足しているか否かの確証を得るためのものとされていた時代です。この時代の幕開けは、
　1957年に出版された”DigitalComputer Programming”[2]に対して同年にRand社のBakerが書いた書評[3]です。Bakerは
　program checkoutにはデバッグとテストという二つのフェーズがあるがこの書籍では区別して書かれていないと批判しまし
　た。書評の中でこの二つのフェーズはつぎのように説明されています。
　　『デバッグはコーダ(coder)の目論見どおりにプログラムが動くことを確認するプロセス、テストは解決しようとした問題をプ
　　ログラムが解決していることを確認するプロセスである』
　　この説明は、現在ではテストとデバッグの定義というよりも、検証(verification)と妥当性確認(validation)の定義に近いもの
　です。そして、Bakerは『区別は明確だが、情けないことに経験あるプログラマでもしばしばテストフェーズを無視している』と
　続けています。
　　この時代は「テストでプログラムが正しいことを確認する」、このために「徹底的なテスト(exhaustive testing)の技術を追求
　する」というスタンスで、いろいろなテスト技術の研究が進んだ時代でもあります。

(3) 破壊指向の時代(1979年～1982年)

　　テストの考え方のパラダイムシフトを促し、長い論証指向の時代を終わらせたのは1979年に出版されたIBM社のMyers
　の”The Art of Software Testing(ソフトウェア・テストの技法)”[4]です。
　　Myersは、テストでは経済学的・心理学的な観点が大切であり『エラーがないことを示していく過程である』という定義は誤
　っていると断じ、『エラーをみつけるつもりでプログラムを実行する過程である』と定義しなおしました。そして、『完全なテスト
　は不可能であるから、いかなるプログラムのテストも不完全にならざるを得ない。だから、作戦としては、この不完全さをで
　きる限り減らすことであることが明らかである』として、きちんとテストを設計することの重要性を説いています。
　　この破壊的な活動へのシフトは、テストを他のバグ検出活動と関連させることにつながり、Myersの本やこの時代の他の
　文献ではテスト技法とともに解析技法やレビュー技法も書かれるようになったとGelperinは指摘しています。確かに、”The
　Art of Software Testing”では、テスト・ケース設計の章の前にインスペクション、ウォークスルー、レビューの章があります。

(4) 評価指向の時代(1983年～1987年)

　　ソフトウェアのライフサイクルに渡る評価活動のひとつとしてテストが位置付けられるようになった時代です。
　　1983年に米国標準局(NBS)が発行した規格”FIPS 101 Guideline for Lifecycle Validation, Verification, and Testing of
　Computer Software”[5]では、ライフサイクルの中で、解析、レビュー、テストの活動を統合する方法論、および各フェーズの
　生産物と用いるべき技法が示されています。この背景には、ソフトウェアの品質は単一の技法で保証できるというものでは
　なく、個々のプロジェクトで吟味して選んだ技法群を使うことにより品質のよいソフトウェアの開発・保守が可能になるとの認
　識があります。

(5) 予防指向の時代(1988年～)

　　Gelperinらの論文は1988年に書かれたものなので1988年以降は彼らが開発した予防指向の方法論が説明されていま
　す。これは、ソフトウェアライフサイクルと並行してテスト活動を実施するというもので、現在”Wモデル”と呼ばれて実践が提
　唱されている考え方と同様のものだと思います。
　　Gelperinらは、上流工程でテスト活動を開始する効果は既に1975年にIBM社のDukeが『開発の早い段階でテストを計画
　し、開発者と異なる目でテスターが仕様を見ることで、よりよい製品が開発できる』[6]と書いていると指摘しています。また、
　Beizerも1983年の”Software Testing Techniques”で、『テストの第1目標はバグの未然防止である』『テストを実行するよりも
　テストを設計する方が、バグ防止という点では効率的である』と書いています。昔から効果があることは認識されていました
　が、組織的にきちんと実践していくことは難しいということかもしれません。

3. テスト担当者やテスト組織の成長のステップ

　　これまでテストの考え方の歴史的変化を紹介しましたが、個人(テスト担当者)や組織の成長の段階を示したものもありま
　す。

(1) Beizerのテスト道

　　Beizerは”ソフトウェアテスト技法”[7]で「テスト担当者の精神面による区分(Phases in a Tester’s Mental Life)」と題して、テ
　スト担当者の姿勢の進歩の段階を示しています(電気通信大学の西先生はこれを「テスト道」と命名されています)。

　　フェーズ0 : テストとデバグには何の差もない。デバグ以外にはテストには特別な目的はない。

　　フェーズ1 : テストの目的は、ソフトウェアが動くことを示すことである。

　　フェーズ2 : テストの目的は、ソフトウェアが動かないということを示すことにある。

　　フェーズ3 : テストの目的は、何かを証明することではなく、プログラムが動かないことによって発生する危険性を
　　　　　　　　　 ある許容範囲にまで減らすことである。

　　フェーズ4 : テストは行動ではない。テストをしないで品質の高いソフトウェアを作るための精神的な訓練である。

(2) ソフトウェアの検査組織の成長過程[8]

　　日本における品質保証の考え方は、出荷前の検査を厳重に行えばよいという「検査重点主義」から「製造工程の管理」、さ
　らに「設計と工程での品質作り込み」「消費者指向」へと進化しました。ソフトウェアにおいても、例えばソフトウェア検査のス
　タンスは、初期の「開発部門のデバッグ支援」から「検査強権」「生産技術支援・品質評価指向」「広義の品質の評価」
　「TQC/TQMの一環としての検査」という段階を経て高度化してきました。
　　テストの歴史的な成長の過程とテスト担当者や検査(テスト)組織が成長する過程とは概ね符合するように思います。新た
　に品質保証の組織をつくったり、テスト担当者を育成する際にはこのような成長段階があるということを踏まえて具体的なロ
　ードマップを考えるのがよいのではないでしょうか。

　　次回は日本のソフトウェア検査の歴史をお話しします。

<参考文献>

[1] D. Gelperin and B. Hetzel, “The Growth of Software Testing,” Communications of the ACM, Volume 31 Issue 6, June
　　1988, pp. 687-695

[2] D. McCracken, “Digital Computer Programming,” John Wiley & Sons, 1957

[3] C. Baker, Review of D. D. McCracken’s “Digital Computer Programming, “ Mathematical Tables and Other Aids to
　　Computation, Volume 11,Number 60, October, 1957

[4] G. Myers, “The Art of Software Testing,” John Wiley & Sons, New York, 1979(松尾正信(訳), 長尾真(監訳), ソフトウ
　　ェア・テストの技法, 近代科学社, 1980)

[5] “Guideline for Lifecycle Validation, Verification, and Testing of Computer Software,” National Bureau of Standards Report
　　NBS FIPS 101,Washington, D.C., 1983

[6] M. Duke, “Testing in a complex systems environment,” IBM Systems Journal, Volume 14, Number 4, Page 353, 1975

[7] B. Beizer, “Software Testing Techniques,” 2nd Ed., Van Nostrand Reinhold, 1990 (小野間彰・山浦恒央(訳), ソフトウェアテ
　　スト技法, 日経ＢＰ社, 1994)

[8] 石井康雄(編) , ソフトウェアの検査と品質保証, 日科技連出版社, 1986