玉置ソフトウェア工学事務所はじめにソフトウェアの変化これまで、ソフトウェアそのものは大きく変化してきた。その変化は、これからも継続するだろう。ここでは、そのソフトウェアの変化から考えてみたい。我々は既に、ユビキタス・コンピュータの時代を迎えている。ユビキタス・コンピュータとは、我々の身の回りのそこら中にコンピュータが存在する状態をいう。年を超えて成立し続けてきた。この結果、最初は空調の効いたコンピュータ・ルームの奥に鎮座していたコンピュータがオフィスの中に現れ、さらに我々の机の上に載った。して我々の鞄の中に入っていたり、携帯電話やスマートフォンの形になって我々のポケットやハンドバッグの中に入っていたりする。化が、どんどん進んできた訳である。計など身につけるものの中に存在したり、テレビや冷蔵庫など今我々がコンピュータとは無縁と考えている家庭用の電気製品の中に存在したりするようになる。タグ」と呼ばれる一種のコンピュータが付いたりするようになる。年は成立し続けるだろう」と予言する。ユビキタス・コンピュータの時代は既に始まっているが、これからのこの本格的な到来は必至である。「コンピュータ、ソフトがなければただの箱」という川柳がある。問だが、この言葉をコンピュータのハードウェアとソフトウェアの関係を簡潔に述べたものと考えたい。ユビキタス・コンピュータの時代になっても、これは変わらない。ユビキタス・コンピュータの時代とは、ユビキタス・ソフトウェアの時代でもある。ソフトウェアの世界でも、既に変化が始まっている。これまで手作りのものが主流だったある種のソフトウェアに、パッケージが多く使われるようになってきた。今でもまだ人が徹夜と休日出勤を繰り返して作っているある種のソフトウェアは、そのうち人が作るのはそのソフトウェアの“仕様書”だけになり、プログラムそのものはその仕様書を基にコンピュータが生成するようになるだろう。このような変化は、広がりと奥行きを伴って今後一層進むだろう。ユビキタス・ソフトウェアの時代になって、最初から全てのソフトウェアがパッケージや自動生成の対象になるとは考えにくい。パッケージ化の進展や自動生成の対象が広がっても、対象になるコンピュータの種類と数の増加によって、人が作らなければならないソフトウェアの需要は今以上に増大するだろう。その時にソフトウェアの品質が今のような状態であれば、この世の中はたいへんなことになる。ユビキタス・コンピュータの時代は、ユビキタス・トラブルの時代にもなりかねない。私は今それを、懸念している。ソフトウェア工学の勧め今のソフトウェアの品質に問題があることは、残念ながらソフトウェアに関わりを持っている人たちの“常識”になっている。日経コンピュータ誌の記事を待つまでもなく「動1はじめにかないコンピュータ」が頻発している。月の再度のみずほ銀行の例を出すまでもなく、金融機関などでのシステム障害はまだ頻発している。最近は病院の情報システム化が進んだこともあって、病院でのシステム障害をマスコミが報じることも多くなってきた。我々がソフトウェアについて心配しなければならない対象が、我々の財産に関わる部分から我々の生命に関わる分野まで広がってきたことになる。これは、何も日本だけの話ではない。アメリカにもこの問題が多く存在している。このことについては、また本文の中でも述べる。“良い”ソフトウェアもいっぱい存在している。イラク戦争でまた我々が目にすることになったアメリカ軍の兵器の素晴らしさは、それについてのソフトウェアの素晴らしさの証明でもある。日本の場合このような形でソフトウェアの素晴らしさを目にすることはないけれど、しかし頻発するシステム障害とは無縁の金融機関がやはり存在している。アメリカや日本のようなソフトウェアの先進国では、ソフトウェアは良いものと良くないものに二極化している。この原因は、ソフトウェア作りの二極化にある。あるところでは素晴らしいソフトウェアを作ることができ、別のところでは残念ながらそれができない。学への取り組みの違いによるものである。永年のソフトウェア工学の分野での研究によって、良いソフトウェアの作り方を我々は既に知っている。その内容は改めて本文で述べるが、端的にいえば良いソフトウェアを作るための方法は、ソフトウェア工学のこれまでの成果をソフトウェア開発の現場にしっかりと適用することである。言葉でいえば簡単なことだが、これがたいへんに難しい。理由は、いくつかある。目は、我々の本質的な弱さから来る。早寝早起きは健康に良いと知りながら、我々はよく夜更かしをする。たばこは身体に悪いと知りながら、喫煙を止められない人が多い。学生は勉強するのが本分であるのに、学期のはじめから勉強を積み上げることができる学生も少ない。ソフトウェア工学の成果を開発現場に適用することが大切と分かっていてもなかなかこれが適用できないことには、このようなことと同じ我々の本質的な弱さから来るものがある。目は、ソフトウェア工学の成果が、特に日本で、実際にソフトウェアを開発している人たちの間で広がっていないことがある。日本で今、本格的にソフトウェア工学を教えることができる大学の数はたいへんに少ない。そのような大学でも、ソフトウェア工学を自分の専門分野として取り組む学生の数はさらに少ない。多くの学生は映像や音響のコンピュータ処理などに大いに興味を示し、ネットワークにも関心が高い。体は、悪いことではない。卒業後にソフトウェア開発に従事している。大学で情報関係を専攻してきた学生でも、ソフトウェア工学のバックグランドを充分に持っている学生は非常に少ないというのが、日本の現実である。大学で情報関係を専攻してこなかった学生については、いうまでもない。組み込み系の世界では、元々ハードウェアの技術者だった人がソフトウェアも手がけるようになり、経験だけをベースに今ではソフトウェア開発を業としている人がいる。ソフトウェアの開発現場で働いている技術者たちは、忙しすぎてこの分野の勉強に割く時間がない。ソフトウェア工学を知らなくても今のところ毎日の仕事には困らない。受験のために他の領域と合わせてやむなくこの領域も少しは勉強するけれど、勉強したことを実際の毎日の仕事に生かそうとするつもりはない。この勉強2はじめには試験を受験するのための勉強であって、仕事のやり方を変え、その成果を仕事に生かすための勉強ではない。日本の現役のソフトウェア技術者の現状は、こういったところだろうか。繰り返しになるが、今のソフトウェアの問題を解決するための方法を我々は既によく知っている。入し、定着させることにある。「ソフトウェア工学の勧め」と呼んでおく。この原稿の目的この原稿の目的は、ソフトウェア工学のこれまでの成果を広く多くの人に知って頂くことにある。この「多くの人」には、次のような人たちを想定している。その他、ソフトウェア工学に興味と関心を持っている人たち多くの人たちにソフトウェア工学の成果を広く知って頂くためには、この原稿の入手が容易で、安価でなければならない。そのためこの原稿は、インターネット上で容易にアクセスして頂ける形にして、置いておきたい。この原稿をインターネット上に置くことで、いつでも気楽にその内容を改訂/変更できるということが私自身にも可能になる。立ち上がり段階では、完成した範囲と順序で、気楽にアップロードできるという側面もある。術を伝えきることはできない。この原稿は、単なる紹介のためのものでしかない。「広く、浅く」がこの原稿の持ち味である。したがって、この原稿で広くソフトウェア工学の成果を捉え、関連しているソフトウェア開発組織の問題解決のためにどの知識/技術、あるいはどの標準が役立つかを把握して、別の方法でそれに関連する知識と技術をより深めて、その上で開発現場の問題解決に役立てて頂きたい。これが私の望みである。そのためこの原稿には、インターネット上のページやいろんな文献など関連するものへの情報を極力充実させたい。ソフトウェア工学全般にわたってこれまで、特に欧米の学者やコンサルタント、技術者などを中心に、すばらしい本が何冊も書かれてきた。今でもこれまで書いたものを定期的に改訂して、常に最新の情報を提供してくれる人もいる。我々日本人も容易に読むことができるようになっている。それにも関わらず、なぜ私がこの原稿を書こうと考えたのか。目は、ほとんどの著者が最新の成果を紹介することに注力し、既存の、どちらかといえば古くなった、それでもソフトウェアの開発現場で今まだ盛んに使われている技術について、ほとんど何も書いていないことについての私自身の疑問から来ている。ついてはほとんど、あるいは全く書かれていない。勉強しなければならない。この本ではプログラム言語についてほとんどふれないけれど、ソフトウェア工学の技術全般にわたってそのようなことが多く見られる。それを、私なりに改めたいと思う。目は、ソフトウェア工学の標準について書かれた本が少ないことである。参画して共同で決めている国際標準が、ソフトウェア工学の領域をすでに広くカバーしている。年以上遅れているといわれている。良いことをいっており、導入することで何らかの成果を上げることができるものが多い。この本では、そのような標準を多く紹介してゆきたい。楽に、小さめに定めることにした。ここでは章ごとの議論では話が細かくなるので、部ごとの議論をしておきたい。囲/領域、ソフトウェア危機の典型的な症状、そのソフトウェア危機を引き起こす原因などについて述べる。本文でも記述するが、私はソフトウェア工学の基本は品質への配慮にあると考えている。部では、品質保証を含めてその品質の問題を取り上げる。部ではソフトウェアとソフトウェア作りの計測(メトリクス)を取り上げる。これらはどのような考え方や方法でソフトウェアを開発するにしても、いずれもしっかりと対応しなければならない事項であると私は捉えている。部は開発方法論について述べる。部では、レビューを取り上げる。つの部で、ソフトウェアを開発する上での各作業について、順次述べる。部は保守について取り上げる。法でソフトウェアの仕様を提示するフォーマル・メソッドと、それを活用して高信頼性ソフトウェアを開発する方であるクリーンルーム開発を取り上げる。部では、ソフトウェアの購入に関わる問題について述べる。部では、ソフトウェアプロセス改善について記す。ソフトウェアプロセス改善は、ソフトウェア工学の成果全体の集大成とでもいうべきものであると私は捉えており、技術についての全体の話の後にこの議論をすることにしたい。部でソフトウェア技術者の資格について考えてみたい。部で、プロジェクト管理の問題を述べる。プロジェクト管理がソフトウェア工学の一部に位置づけされるのかということについて議論があるだろう。仮にその範囲に含まれないとしても、ソフトウェアの開発プロジェクトへの固有の問題があると私は考えている。ここではそれを中心に考えてみたい。部では、ツールについて述べる。部は教育の問題を取り上げる。部で、ソフトウェアとソフトウェア工学の将来について考えることにした4はじめにい。当初計画したこの本の構成は、以上のようなものだった。最近は情報システムのセキュリティの問題が、大きく取り扱われている。部に、ソフトウェアの安全性の問題を付け加えることにしたい。年)のアメリカ出張にさかのぼることができる。