IT記者会Report

オリジナルな記事や送られてきたニュースリリース、セミナーのプレゼン資料など

プロセス論議の原点

 50年ほど前に,絵描き修行の世界からコンピュータ・プログラマに転進したとき,わたしにとって一番役に立ったのは「美術の目的は,目に見えるものを再現するのではなく,見えないものを見えるようにすることだ」という画家パウル・クレーのコトバだった.
 1921年バウハウスでの造形講義開講の挨拶で,かれは,芸術における「分析」の概念について次のように述べた:「自然科学における分析とは,対象物をその構成要素に分解しそれぞれの属性を調べることである.しかし,われわれアーティストはそのような行動はしない.われわれにとっての分析とは,作品がどのようなプロセスによって創造されたかを探求することなのだ」と.

 「プロセス」と「構造」とは,ソフトウェアを構成する2つの基本概念である.前者は当然のことながら時間を含み,後者は空間を意味している.したがって,ソフトウェア作りにあたってわれわれが心がけるべき要点は,どのように時空のバランスをとったらよいかということである.
 1960年代後半に,イタリア人数学者が CACM誌に発表した「プログラム構造化定理」をきっかけとして巻き起こった「構造化プログラミング」の運動は,ひとことでいえば,ソフトウェアにおけるこの時空バランスの問題を解決しようという動きだったのだとわたしは考えている.”GOTO Statement Considered Harmful” という刺激的なタイトルで世の中を騒がせたエドガー・ダイクストラの有名な書簡(CACM,1968 March)は,マシンの内部で展開される目に見えない計算プロセスをプログラムのソース・コード上ではっきりと目に見えるようにすべきだという提案であった. 

 当時のハードウェアはまだきわめて貧弱であり,ほとんどのプログラマは,計算速度や記憶容量の制約に悩まされながらシングル・スレッドのプロセス問題に気をとられていた.しかし,ダイクストラ先生の主要な関心は,将来実現するであろう高速なマシン上での複雑な並列プロセスをどう表現したらよいかということにあったらしい.
 わたしがそれに気づかされたのは,1972年にミュンヘン工大の F.L.Bauer 教授がまとめられた大著 “Advanced Course on Software Engineering” (Springer) 中に,並列処理における排他処理の記述に関して,交通制御におけるセマフォアのアイデアを転用した ダイクストラの小論文 “Co-Operating Sequential Processes” を目にしたときだった.
 「テスティングはバグの存在を証明することには使えるが、決してそのアリバイ(不在証明)にはなりえない」というダイクストラの指摘は現在でもなお生きていて,プログラマたちを悩ませている.巨大化し複雑化したハードウェア内部のプロセスだけでなく,その周辺にある社会プロセスまでを視野に入れたとき,システムの構造とのバランスをどうとればよいかは,さらに大きな難問としてわれわれの前に立ちはだかっている.