ソフトウェア品質保証の本の紹介。バグにも焦点を当てる。
コンピュータ業界に、藤原博文さんという有名な方がいらっしゃる。 その方の書評に取り上げられていたので読んでみた。 藤原さんの感想では、「内容は、はじめは楽しかったのであるが，後半は、 ボロボロであった。」とある。私の推測では，前半というのが 第１章から第３章、後半が第４章と第５章であろう。 前半に関しては藤原さんと同じ感想をもつ。 後半は、ボロボロであるとは考えていない。 ただ、前半とは質の異なる話題であり、とっつきにくい章ではあると思う。
前半は個々のバグの有名な事例について原因と対策を述べているのにたいし、 後半はバグを横断的にとらえ、バグを全体で管理するさまざまな手法と その事例について述べている。
藤原さんがボロボロとまでいう、その理由は藤原さんの書評にある、 「こういうことを書いた本は、もう、本屋で充分に腐っていて」 「現実の ソフトウェア開発現場におけるバグ対策は、恐ろしい程にお寒い」 ことからきているのだろう。 その気持ちもわかる。後半は学者側、管理側の 立場が強く、現場の泥臭さが伝わってこない。 著者たちが後半を設けた理由は、泥臭くかいただけでは、本としての体裁を なさないと考えたからではないか，とも邪推する。
私がソフトウェアの業界に入って役に立った本の３冊に入る。いわゆるソフトウェアの管理のイロハから、 かなり高級なことまで（たとえば下のクリーンルーム手法まで）触れられている。 この本に書いてあることの1/10も、そしてこの著者の厳しさの1/100もない私であったが、 直接にプログラムを書くだけではすまなくなったベテランの人には強くお勧めする。
この本のあちこちで「背中の痛み」が出てくるが、これはおそらく backache の訳であろう。 そうだとすると、むしろ「腰痛」とするとぴったりくる。
この本の扉には、色鮮やかなスケジュール管理表が載せられている。これを見ると、 私が率いたプロジェクトでこれを使って失敗したことを思い出す。
あるページで、ヴェルディの肺病のミミ、というのが出てくる。 オペラの作者はヴェルディではなくて、プッチーニであろう。もし、ヴェルディが正しければ、 ヒロインはミミではなくてヴィオレッタとなる。これくらいは大目に見ないといけないな。
この本の書評をある Web サイトで見た。この方が曰く、 「アジル・コンペティションの現代においては このレベルの考え方ができない人は仕事にならないんじゃないかと思います。」 その通り。私がその「仕事にならない」人の一例である。だから役に立つ。
この方はこうも言っている。「アナログ時代の話なのではないか。 冗長な内容にしか思えなくなっているのです。」そう、 今でもアナログ時代に生きている人は多い。 付け加えれば、情報の伝達はデジタルで賄える部分は多くなってきたけれど、それでおもアナログ部分は残る。 確実なのは、最先端と最後尾の距離は確実に広がってきているということだ。
ワインバーグは、管理の大切さを何度も解いている。そして、この管理というのは、一筋縄ではいかないものだ。 だからこそ、冗長を覚悟で、いろいろな例を出し、確かめている （本当の意味のない冗長とは、武者小路実篤の晩年の著作をいうのだ）。 また、ワインバーグの意図している層は、トップではない。ボトムにある。底辺を引き上げようとしている。
アジルな経営とは何か。単に映画のコマを早回ししただけではないのか。デジタルだかアナログだかの分類とは 異なるのではないか。
最後に私から付け加えておこう。 この方は、この本に対する評価を保留するといっている。私ももう少し考えてみる。
副題は「使い勝手を考える．ISO 13407 への具体的アプローチ」である。
世に○○工学と名のつく分野は数多い。 本書は○○にユーザを当てはめた、類書がありそうでない本である。 以前、私は「要求定義工学」という本を読んだ。 この本では、ユーザが行なう定義をどのように実現するかに重きが置かれていた。 これに対し、「ユーザ工学入門」では、実験や観察を通して、ユーザの視点を正確に得る手段を 知らせてくれる（なお、ユーザ工学入門では、要求定義工学の原著を文献としてあげている）。
この本を読むと、「ユーザが使いやすい製品を実現する」ということが、いかに大変なことであるかがわかる。 こういう感想を抱いてしまったため、すぐには自分の仕事では生かせないのではないかと思ってしまう。 しかし、自分一人でできることもある。それは、本書の 4.4.6 にある、WEB ユーザビリティチェックリスト である。原文は UPAのホームページにあるというので、 英語のできる方はそちらを見るといいだろう。 少しでもいいから、このチェックリストに照らして、よいページにすべく努力していこうと思う。
なお、副題に「ISO 13407 への具体的アプローチ」とあるが、 ISO 13407 について直接解説している個所は最後の 9 ページのみである。 できれば、この ISO 13407 のそれぞれの節に対応する具体的な解説のもとで本文が構成されていれば （あるいは対応表がつけられていれば）さらによかった。
私のようにいいかげんな仕事しかできない人間にとって、 あまりに痛いことばかり（特に最初と最後）書かれている。 何も実践せずに読みましたで終わることは著者の希望ではないだろう。 そこで、一つぐらいは実践してみることにした。 プログラミング言語 Perl について自分のおかしたミスを振り返ってみて、 Perl 失敗集としてまとめ、公開した。 公開すると宣言してからもうすぐ２年が経過しようとしていたことに、我ながら呆れる。
上で PSP に関するハンフリー氏の著書を紹介した。ハンフリー氏は、 PSP 以外にも多くの体系を提唱している。その中で最も有名で影響を多く与えたのが、 能力成熟度モデル(CMM)である。
このガイドブックは、 ソフトウェアに関する能力成熟度モデルを導入するときに必要となるいろいろな活動を、 豊富なイラストで示した入門書である。 イラストのフリーハンドがどことなく長新太を思い起こさせる。もちろん、 CMM は抽象的であるが厳密な定義のもとで記述されているので、 イラストも個々の絵文字レベルでは正確に定義されている。 読んで実践することで、多くの効果が上がるのではないか。
なお、この本の正式書名は、 「CMM(SM)ガイドブック」のようになっている。SM とは、 私のイニシャルではなく、ましてはその種の略語でもなく、 単に（SEIという組織の）サービスマークという意味である。 原著発行は1995年である。7 年後に邦訳が出たということは、 プロセス改善を体系的に取り組むことについては、日本はアメリカに比べて 7 年遅れている、 ということかもしれない。
この本は、あるメーリングリストからの紹介で読んだ。 私の最初の感想は「どの章の扉にもデマルコさん本人の顔写真があってうっとうしい」というもので、 これをそのメーリングリストで語ったら「原著でもそうなっています」という答がベテラン技術者から 返ってきた。私も実に下らないことを語ったものだ。
他のWebページでもこの本の評判はよく、その中では「計測で気が触れた」とか、 「ソフトウェア開発−その先端技術と実態水準」などの章がよく引用される。 私は別の観点で興味深いと思ったことがある。「プログラム文書化へのビデオ利用」の章である。 保守・運用の文書化は大変な話である。実際書く者の苦労は並大抵ではない。 ある開発者は、「運用者が俺の話を聞いてくれて、それをまねてくれればいいのに」 とこぼしたほどだ。この理由もわかる。 この救世主として、ビデオ録画という方法があると紹介している。
これはいいかもしれない。私はプログラム文書化へで試したことはないけれど、 お客さんが使うソフトウェアをビデオ化したことはあった。画面を録画しつつ、 アフレコで説明を入れていくのである。これは、かなり役に立ったと思う。 問題は技術者同士で使えるかどうかだ。ここに出ている例はアルダス社 （デスクトップパブリッシング用ソフト「ページメーカー」などで有名だった）であり、 おおっぴらに技術を伝えるアメリカだからできることかもしれない。 日本ではどうか、私が挑戦したいとも思ったのだが， どうだろうか。
ISO 9001 (1994年版) をソフトウェアの業務に適用するためには、 どのようなことをすればよいのかが解説されている。 数は多くないが、様式の例も出ている。 現在は ISO 9001 は 2000 年版になっているので、 要求事項の解説という意味では古くなっているかもしれない。 しかし、1994 年と 2000 年版の中身はそれほど違わないという考えも成り立つ。 また、2000 年版広範な産業分野に適用できるように記述が抽象的になったので、 むしろ 1994 年版の記述がISO 9001 初心者にはわかりやすい、という人もいる。 それゆえ、この本を古本屋で見つけたら買ってもいいだろう。
あまり役に立たなかった。抽象的な話が多いためである。
高品質なソフトウェアを作るための原理と手法が述べられている。 何度か読み返してみたが、そのたびごとに絵空事という気がしてならなかった。 特に、最終章の形式論理を駆使する章ではそのように感じた。 プログラマが形式的な証明手法を完全に身につければできるのかもしれないが、 実際に適用することができるのかどうか、極めて疑わしい。
まりんきょ学問所 ＞ コンピュータの部屋 ＞ コンピュータの本の部屋 ＞ ソフトウェア品質保証
