同氏はこの3月に亡くなられた．情報処理学会の機関誌「情報処理」7月号（Vol. 50, No. 7）で「『あの時代』に想いをはせて―証言者達からのメッセージ」という小特集が組まれているが，次のような追悼記事からなっている．

編集にあたって （中川晋一・川合慧）
そこにはいつも，先生の本がありました―出版を通じてのご貢献― （小山透）
情報化時代の幕開け―みんながコンピュータに熱中した時代からのメッセージ― （青山幹雄）
「情報処理」大変革の夜明け前―石田編集長の誕生に向けて― （諏訪基）
INET91，ISOC，INTEROP，IAJ―石田晴久先生とともに （高橋徹）
石田先生から受け継いだもの （砂原秀樹・村井純）

私は同氏と面識もないが，名前を知ったのは大学生の頃で，ブライアン・カーニハンとデニス・リッチーの著書の日本語訳『プログラミング言語 C』を読んだことによる．カーニハンとリッチーの頭文字から K&R と呼ばれる有名な本であるが，前にも書いたように最初は原書を読み，手元に置いてプログラミングをしたいと思い訳書を大学生協で購入した．Cに精通している訳者だけあって読みやすかった．同氏の著作や翻訳はたくさんあるが，専門書であっても読者を惹きつける魅力があった．

ところで，このエントリのタイトル「村井君。3つ以上つながってはじめてネットワークと言うのだよ」という JUNET に関する同氏の発言について，小特集の最後の記事「石田先生から受け継いだもの」にその真意が書かれている（ｐ．658）．

村井はJUNETにいろんな組織を参加させようと奔走していたのであるが，「東京大学がやっていないものは研究じゃないでしょ．そんな実験には参加できないよ」と言われて困っていたのだそうである．そんな話を聞きつけた石田先生が，「じゃあ村井君，東大をつなごう」とおっしゃられたのである．

このあたりの事情は，村井純『インターネット「宣言」―急膨張する超モンスターネットワーク』（講談社，1995）にも書かれているが，慶應と東工大の間を接続したところに東大も接続して JUNET が成立したというわけである．同書には初期の JUNET が電気通信事業法のうえで合法的なものかどうか郵政省から明確な回答が得られていなかったとも書かれているのだが，石田氏はそういった実験にも積極的に協力する人物であった．

ここで今になってお悔やみの言葉を述べても意味はないだろうが，同氏の著作は優れているので読んだことのない人にはおすすめしたい．

ここでとりあげる論文は，Craig Larman and Victor R. Basili, Iterative and Incremental Development: A Brief History, Computer, Vol. 36, No. 6, pp. 47-56, (June 2003) である．ここで pp. というのは p. の複数形で，複数ページにまたがる文献を特定するために用いられる記号である．卒業論文は単著が普通だが，この論文はソフトウェア開発の歴史に触れたもので，よく読まれている有益性の高いものであるからとりあげる（Agile Alliance のページから本文へのリンクがあるようだが，これを書いている時点で www2.umassd.edu へのアクセスができないため，図書館で読むか IEEE Computer Society のサイトで入手する必要がある）．

論文やレポートは誰に読んでもらうのかを意識して書かなければならない．この論文が掲載された雑誌 Computer は IEEE Computer Society の会員はみな受け取るようになっているもので，広い範囲におよぶコンピュータの専門家が対象読者である．したがって，ある程度専門的ではあるがソフトウェア工学の専門家だけを対象として書かれているわけではなく，学術論文というより技術的な解説記事という性格が強い．

内容・構成は次のように，序論と時代別の本論，そして結論へと結びつくかたちとなっている．
(Introduction) — 何について論じるのかを明確にしている
PRE-1970
THE SEVENTIES
THE EIGHTIES
1990 TO THE PRESENT
(Conclusion) — 結論
References — 参考文献リスト

この論文では独自の視点でソフトウェア開発の歴史をとらえている．ソフトウェア開発の方法として反復型開発 (interactive and incremental development, IID) が単純にウォーターフォール開発に単純にとってかわるものではなく，実は初期のソフトウェア開発でとられていた方法であることを明らかにしている．そして，ウォーターフォール開発がアメリカ国防総省の標準化によって固定化され，それによって生じた行き詰まりを打開するために再び反復型開発が用いられるようになったというわけである．

10ページの論文において45の文献が参照されている．歴史的事実や論拠を明らかにするために必要なものが選びぬかれており，十分な調査にもとづくものであることがわかる．

なお，専門家が読むことを前提とした論文では参考文献リストに記す雑誌名を略記することがしばしばある．たとえば次のようなものである．対象読者が専門家でない場合にはこのように略記しないほうがよい．
Proceedings → Proc.
Journal of Systems and Software → J. Systems and Software
IBM Systems Journal → IBM Systems J.
Communications of the ACM → Comm. ACM
IEEE Transactions on Software Engineering → IEEE Trans. Software Eng.
ACM Software Engineering → ACM Software Eng.
IEEE Annals of the History of Computing → IEEE Ann. Hist. Comput.
情報処理学会論文誌 → 情処論
情報処理学会研究報告 → 情処技報
電子情報通信学会誌 → 信学誌
電子情報通信学会論文誌 → 信学論
電子情報通信学会技術研究報告 → 信学技報
電気学会誌 → 電学誌
電気学会論文誌 → 電学論

参考文献は多ければよいというものではなく，ましてや「こんなにたくさんの文献を読みました」と自慢するためのリストでもない．ただ，確かな議論を展開するために必要なものを使えばよいのである．ウィキペディアでも，論拠がはっきりしない記述に [要出典] のタグが付けられているのを見かけるが，それと同じことである．

最後に，英語で書いてあるから読めませんという声が聞こえそうなのだが，辞書があればそれほど難しい英語で書かれているわけではないので努力してほしい．ソフトウェア開発の現場でも，あることを調べようとしたときに英語の文献しか存在しないことは珍しくないのが実態である．

これがけっこう大変な作業である。編集されていないテープをいちど全部見てメモをとり、それにもとづいて映像を取り込んでチャプターを設定し、完結したDVDをつくるという作業。

アナログの映像が、同期のとれた状態でなければ映像の取り込みはできないということで、しかたなく最初の数フレームを捨てることもしばしばある。

作業中は集中していなければならないので、ほかのことができない。ブログの更新頻度が低下しているのはこのためである。

彼女自身がブログで告知していたように、2009年3月9日から放送された「丘の上から愛をこめて」篇（メイキング映像あり）では、手旗信号が使われている。手旗信号はおそらく初めての経験と思うが、上手である。

私としてはここで終わってしまうわけにはいかない。話を展開しよう。

手旗信号はヒトの体を動かすことによって文字を表現する、いわば簡素化された腕木通信である。腕木通信は人力で動かす装置であり、目視によって信号の伝達をおこなうものである。

手旗信号も、両手に持った手旗の動きで信号伝達をするという点では同じである。どのように信号伝達をするのかといえば、先に見た壇れいによる「ハルダゼ…」という文の送信を、手旗信号FLASH5というページで試してみて、前述のCMと比較すればよくわかるであろう。日本語の手旗信号は、基本的に受信側から見てカタカナの形に近い動作をするようになっている。

また、起信、応信などの信号はいわば制御信号で、簡単な通信規約（プロトコル）をそなえているともいえる。

腕木通信は手旗信号に比べると大がかりであるが、通信網すなわちネットワークを形成したというところが重要である。詳しいことは中野明による腕木通信って、ご存じですか？というページを読んでいただきたい。腕木通信は telegraph あるいは semaphore と呼ばれ、telegraph は後に電信を意味するようになった。また semaphore という言葉は、Edsger W. Dijkstra によってプログラミング用語となり、現在でも使われている（たとえば Perl には semctl、semget、semop というセマフォを扱う関数が実装されている）。

かつて職場の同僚（山本さん以外は私を含めて全員退職したし、山本さんの近況はわからないが巻末の著者紹介に「将来はジャズのベース弾きおよびポリグロットを目指している」などと書かれているので、その道に進んでいるのかもしれない。まあ、元気だったら連絡ください。）と共著で出版した『GNOMEプログラミング－GNOMEアプリケーション開発の基礎』（セレンディップ, 2001年）は GNOME 1.4を前提としたもので、現在の最新版2.26あるいはそれ以前の2.xではうまくいかない場合がある。当時は@IT のレビューやlinux.or.jp のレビューなどで比較的よい評価をいただいていたのだが、なにぶん時が過ぎた。

対応策として、この本の2章と現行のAPIを比較し、新しいAPIに対応したプログラミングをすればよいのである。たとえば Pango などは GNOME 2.0 以降で採用されたものであって、文字列の表示についてこの本は対応していないので、その部分について自分で補えば事足りる。そういうことにしてしまうと新しい解説書は不要になってしまうが、この本を読みこなした読者にはそれも不可能ではないように思われる。

現在使われている GNOME のバージョンであるが、私の手元にあるDebian GNU/Linuxの安定板（これもつい最近2009年4月に etch から lenny へバージョンアップした）では今のところこんなぐあいである。

ktanaka@sputnik:~$ uname -a ; dpkg -l | grep gnome-session
Linux sputnik 2.6.26-2-686 #1 SMP Thu May 28 15:39:35 UTC 2009 i686 GNU/Linux
ii gnome-session 2.22.3-2 The GNOME 2 Session Manager

プログラミングをしないエンドユーザとして見ても、ずいぶん変化したように感じられる。

ところで、日本医師会 ORCA プロジェクトで開発されたレセプトソフトも Debian GNU/Linux に GNOME の上で動いているが、パッチ提供の頻度などを見ると、開発もそれなりに大変そうではある。ただ、使う側としてはあまり困難はないのではないだろうか。

さて、公開されているGNOMEのロードマップによれば、2010年3月にはGNOME 2.30すなわち3.0がリリースされる予定になっている。ここにいたるまで、APIの大幅な廃止・変更が予告されている。プログラマ向けに新たな解説書を書くとしたら、GNOME 3.0を前提とすべきであろう。2001年に出版した本の著作権は会社にあるので、書くとしたら改訂版ではなく当然のことながらフルスクラッチとなる。個人的には書きたいが、プライオリティの高い課題があるので、いつになるのかわからない。