コンピュータソフトウェア Vol.14, No.1 pp.75-82 (1997)

( 2 )

1

トピックス

ICSE '96 会議報告

井上 克郎

1

佐伯 元司 鰺坂 恒夫
トリアル、ツール展示などへの参加を含め、多くの人がはじめに今年で 18 回目を迎えるソフトウェア工学国際会議(International Conference on Software Engineering)
は、ドイツのベルリンにある Technische Universit
atBerlin で開催された。

集まってきた。
現在は、ソフトウェア工学のメトリックス、プロセス、形式手法、オブジェクト指向、などそれぞれの分野に専門の会議がたくさんあり、参加者が分散してしまっている傾向が見られる。しかしこの会議では、各分野会期は、前後の併設ワークショップ、シンポジウムの優れた論文が発表され、また、興味ある基調講演やを含めて、 1996 年 3 月 25 日から 31 日までの７日間、パネル討議が聞けるので、米国開催の場合、 600 人程チュートリアルは 25,26 日、本会議は、 27 〜 29 日の度、海外開催の場合は 400-500 人程度の参加者が集ま間の３日間である。

る。しかし、今回は、 852 人という多くの参加者を集か れ る。開 催 地 は、 米国 と 米 国 以外 と が 交 互に 選 ばめた。参加者の内訳は以下の通りである。
351 人
ドイツ

れ、さらに、米国内での開催の場合は、東側、西側のドイツ以外のヨーロッパ場所が交互に選ばれている。 15 回会議は、東海岸の南北アメリカ

この会議は、毎年一度、３月から５月までの間に開Baltimore、一昨年の 16 回はイタリアの Sorrento で開催され、昨年は、西海岸の Seattle で開催された。来年は、 Boston、そして、 1998 年の第 20 回会議は京都で開催することが決定している（平成１０年４月１９日から２５日まで、国立京都国際会館）。
この会議では、過去、ソフトウェア工学の重要な論文が発表されてきている。例えば、 L. Osterweil が第９回会議の基調講演で発表した \Software Processes areSoftware Too" という論文は、その後のソフトウェアプロセスの研究や応用に大きな影響を与えた。また、ソフトウェア工学全般に関する最大の会議として、チュー268 人
173 人
60 人

アジア・オーストラリア
このうち、５３％が研究者（含む政府機関）、４７％が会社関係者である。
チュートリアルや併設ワークショップが２５、２６日の両日行なわれ、続いて２７〜２９日まで本会議が行なわれた。本会議では、３つの基調講演、５２の論文発表、３つのパネルの他、実務経験報告、解説、ミニチュートリアル、ワークショップレポートなどのセッションから構成されていた。本会議と並行して、ツールの展示会場が設けられ、本の展示や企業のシステムの展示が行なわれた。２９日の本会議の終了後、ワークショップが３１日の午前中まで引続き行なわれた。

Katsuro Inoue, 大 阪 大 学 基 礎 工 学 研 究 科, Graduate

以下、それらの内容や会議の運営について述べる。

School of Engineering Science, Osaka University
Motoshi Saeki, 東京工業大学情報理工学研究科, Graduate
School of ????, Tokyo Institute of Technology
Tsuneo Ajisaka, 京都大学工学研究科, Graduate Schoolof Engineering, Kyoto University

コンピュータソフトウェア, Vol.14, No.1(1997), pp.1{8.
1996 年 7 月 31 日受付.

2

基調講演

2.1

DeMarco\The role of software development methodologies: Past, current and future", by2

コンピュータソフトウェア

Tom DeMarco, The Atlantic System Guild,USA.
一番最初の基調講演では、 Tom DeMarco が、プロセスは有害である、という主題で話をし、フロアでかなり議論を巻き起こした。彼は、４つのパラドックスと称してプロセスの考えの問題点を指摘した。

( 3 )うまくいかなかったプロジェクトには管理上の問題があろう。特に、要求仕様に力を入れなかったものは失敗している。形式的手法は、その仕様作成の分野で成功している。
また、テストの技法は、ソフトウェアの信頼性を上げる上で大きな貢献をした。さらに、安全性を高める上

1. プロセスを改善すると、簡単な作業が自動化されで、 Over-Engineering （橋や建物で、実際かかる荷て、結局人間が深く介在しなければらない困難な問重の２倍とかに耐えるように設計すること）のための、題（エッセンス）しか残らない。

防御的なプログラミング (defensive programming) や

2. 戦争の歴史を見ると、重武装だが動きにくいものが、軽装備だが動きが軽いものに負けている。プロセスの考えは、この重装備にあたる。

データの正当性のチェックが役立ってきた。
計算機科学者は、現実から離れて先を行っている必要がある。純粋な科学的な興味が研究の将来を切り開いて

3. 銀行システムなど過去の大規模システムの再利用いく。一方、実務家は、研究成果のなかから役立つものはうまくいかなかった。再利用のプロセスを考えてを見つけて、現実に使えるようにするべきである。そのもだめで、再利用したくなるようなものを作る必要ための教育が重要である。

がある。

こ の Hoare の 講 演 に 関 し て、 突っ 込 み 方 が 足 り な

4. 人間はリスクを乗り越えて大きな変化をつくり出い、表層的な意見である、現実には基礎研究がほとんどす力がある。新しい技術で大きな利益を作り出すこ役立っていない、などの意見が、新聞で述べられていとを目的とすべきである。しかし IS9000, CMM

た。などは、リスクの小さくして安定した開発を目的としており、それでは、技術の発展は起こらない。
プロセスの問題の例としてあげたのは、ＡＴ＆Ｔな
ど CMM レベル３やそれ以上を得ている会社が、最近大量にレイオフを出しているという事実である。一方、Bohem の Win-win 理論、 mediation の技術などが将来重要になるという指摘を行なった。

2.3

Basili\The role of experimentation: Past,
present, and future" by Victor R. Basili,
University of Maryland, USA.
最終日の講演は、 Basili の実験的ソフトウェア工学の話であった。

こ の 講 演 に 関 し て、 賛 否 両 方 の 意 見 が、 会 議 発

ソフトウェア工学分野以外の、例えば医学研究などで行 の 新 聞 で 述 べ ら れ て い る。 (http://www.cs.tu-は、研究で得た新たなアイディアは、かならず実験を行berlin.de/~ icsewow) かなり一方的な講演ではあった

なって、それが良いか悪いか、効果があるかないかの評が、会議の冒頭で、参加者同士の会話のきっかけにな価を行なってきている。しかし、ソフトウェア工学の分る、面白い内容であった。

野では、多くの新たな提案は、そのような評価なしで論文として掲載されてきている。

2.2

Hoare

\How does software get so reliable without
proof?" by Anthony Hoare, Oxford, UK.

新たな提案を評価するためには、管理された実験が必須である。幾つかの被験者のグループのもとで、提案する方法と従来の方法とで実際に作業を行ない、その結果彼は、基礎的な研究の重要性を主に述べた。

を統計的に解析、検討する必要がある。このような実験

現在、非常に大きなプログラムも実用的に使われていを通じて、クリーンルーム手法やシナリオに基づくプロるが、それらのプログラムの作成に関して、形式的な手法は、直接的には大きな貢献はしなかったが、プログラミングの考え方の基礎に大きな影響を与えてきた。

グラム読みの効果が確かめられた。
一方、このような実験には、非常にコストがかかる。
一つのことを確認するために、多くの人間と時間がかか( 4 )

Vol. 14 No. 1 Jan. 1997

3

る。そのような実験の情報を交換しあい、効率を高める

System (CHCS) のスライサの設計に適用され，ための交流組織として ISERN を設けている。また、実その結果についての考察を行っている．

験的ソフトウェア工学のための雑誌も発行した。

要求に応じてプログラム表現を作る，余分な内部表

彼の話は、何度か日本でも紹介されており、比較的なじみのあるものであった。

現を捨てるなどはよくある話である．しかし，実際に百万行規模のシステムの解析を行いツールの方針が正しいことを示している．また、関数呼出の再計

3論文

今回、この会議には、 34ヶ国から 213 の論文投稿があって、そのうち 52 本が採録された。日本からは、２つの論文が採録されている。
今回は、ソフトウェア工学の各分野それぞれバランス

算の深さを 2,3 に制限しても，無制限にしたものとほとんど結果のスライスの大きさは変わらない、解析の際の繰り返しのはじめの 20 興味深い。

 How to Identify Binary Relations for DomainModels

良く採録されているように見える。要求仕様、メジャ

ソフトウェアシステムの分析ないし要求定義の初期メント、テスト、解析、形式的手法、構成管理、分散シ過程で用いられる実体 { 関連 (E-R) モデルやオブステム、再利用、プロセス、開発環境、保守などのセッジェクト構成モデルには，多くのさまざまな関係がションが作られた。

登場するが，与えられた要求から何を関係と同定す

これらの論文のなかからいくつかを紹介する。

べきかの指針は，これまでほとんど明確に示されてはいない．一方，多くの実システム例で，要求は自セッション 2A：プログラム理解と解析然言語で提示され，またそこで用いている用語定義

 The Design of Whole-Program Analysis Tools

集が整備されることが多い．本論文はこの用語定義

大規模なソフトウェアシステムを理解するための集を解析して，関係の候補を効果的に半自動抽出で効率的なツールを作るのは困難である．多くのプきることを示している．用語定義集は主に名詞を見

ログラム理解のためのツールはまずプログラムの出しとして整理されるため，動詞句よりも名詞すな表現 (control- ow 表現,data- ow 表現) を作るた

わちオブジェクトクラスの定義のされ方を中心に解め，大規模システムの解析の場合に非常に多くの空析を進めることになるが，これが動詞に注目するよ間と時間が必要となる．しかしこれらの表現の多くりもむしろ実態に近い関係を抽出する結果となる．

は解析の間に使用されない．

支援ツールを用いた実験，応用経験でも，二次的にそこで本論文で設計するツールでは，プログラムの導出可能な余計な関係もあわせて抽出してしまう傾表現をあらかじめ作っておくのではなく，それらを向はあるものの，拾わなければならない関係を落す

要求に応じて作る．これにより，時間・空間の節約ことは，深い対象知識を必要とするものを除き，あになる．また，空間の節約のためまれにしか使われまりなく，良好な結果を示している．

3.1

ない表現は使用後に捨て，必要であれば再計算すセッション 2B：要求獲得支援

る．これにより記憶装置の遅い階層を使わずにす

3.2

み，時間の節約にもなる．更に，解析の際の時間と An Analytic Framework for Specifying and

正確さの折り合いや終了条件についても，ユーザにAnalyzing Imprecise Requirements制御できるようにする．ここで，時間と正確さの折

こ の 論 文 は、 顧 客 か ら の 不 正 確 な 要 求 を Fuzzy

り合いとは関数呼出の際に再計算を行う深さについLogic を用いて数値化し、不正確な要求に対し、開ての設定で，終了条件とは解析の繰り返し回数であ発者側がどのような具体的な要求案を採用すればよる．

いかを決めるための手法について述べたものであ

これらの技術は MUMPS 言語で書かれた病院管る。まず、例えば「開発コストを小さくしたい」と

理 シ ス テ ム で あ る Comprehensive Health Care

いった不正確な要求が、採用する開発プロセスに4

コンピュータソフトウェア( 5 )よってどれだけ満足されるかの度合いを０〜１までうに用いられたかの概略が述べられ、彼らの経験の値を返す Fuzzy 関数でモデル化する。０はそのから得た知見が述べられている。それによると、プロセスでは全くこの要求を満たさない、１は完全に満たすことを表す。２つの不正確な要求があったとき、これらをモデル化した Fuzzy 関数の挙動の関係で Con ict の度合い（２つの関数をグラフとして見たとき、勾配が逆になっている区間が何割あるか）や Cooperation の度合い（勾配が同じになっている区間の割合）を定義し、これらの数値をもとに、顧客の不正確な要求に対する、開発者側の具体的な要求案をある種のトレードオフで優先順位をつけて求めようとするものである。

3.3

セッション 2C：テストと解析

1) Pattern は開発チームのメンバー間のコミュニケーションを向上させる、 2) Pattern は実際の設計より抽出される、 3) Pattern は設計の本質的な部分をコンパクトな形で捉えることができる、 4)
Pattern は最良の実践を記録し、かつそれを再利用することを促進してくれる、 5) Pattern は必ずしもオブジェクト指向である必要はない、 6) 組織の中に Pattern に関する助言者や指導者を置くことにより、 Pattern を用いた開発が開発者に受け入れられやすくなる、 7) 良い Pattern は書くのが難しく時間もかかる、 8) Pattern の実践は最も重要である、ということである。

 An Empirical Study of Static Call Graph Ex-tractors
call graph とは、プログラム中の関数の呼び出し関係を表現したものであり、主にプログラムを理解す3.5

セッション 4B：コンポーネントベースのソフトウェア

 Experience Assessing an Architectural Ap-るのを助ける目的で使われる。この論文では、 callproach to Large-Scale Systematic Reusegraph を作成するツールを 5 種類用いて、いくつ製品単位の大きさの部品を再利用して組み立てる，

かのソースに対し実際に call graph を抽出し、そいわゆるコンポーネントウェア開発の経験をまとの結果に基づき、ツールごとの特徴を分析していめている．部品を統合する仕掛けとして OLE，部る。

品として Visio と Access，部品を仲介するプログ抽出した call graph がツールごとにかなり異なっラミングシステムとして Visual Basic を用いていており、その原因は、マクロをどう扱うか、関数へる．基本的には， OLE のような統合機構によるのポインタを認識できるか、などである。それにアーキテクチャ不整合の解決，コンポーネントウェ

よって抽出された情報の量が時には 100 倍以上もア開発の生産性の良さや汎用性，実用性を認める論違っていたりしている。また、あるはずのない呼び調であるが，指摘された問題点の方がむしろ今後の出し関係を誤って抽出したりする原因も分析してい展開の参考になろう．問題点は統合機構の側の問題る。と部品の作られ方の問題の二つに分かれる．統合機

同じようなツールなのに顕著な違いがみられること

構と部品間仲介系の大きな問題として，部品間のイを示した本論文は、このようなツールを使うものにベントやメッセージの双方向の流れをすべて的確にとっては大変興味深いものである。

捉えきれないことがあげられている．一方，部品の方も，その内部状態の重要な変化を伝えるのに必要

3.4

セッション 3A：オブジェクト指向の実用 Industrial Experience with Design Patterns
７人の著者が Design Pattern を用いて、ソフトなイベントをそもそも適時に発生していないことがあるほか，統合機構に十分に対応していない，カスタマイズ可能性が不十分，といった問題がある．

ウェア開発を行ったときの経験をまとめた論文。まセッション 6A：形式的な設計手法

ず、６つの会社でソフトウェア開発（開発対象のソ3.6

フトウェアの分野も異なる）に Pattern がどのよ Executable Object Modeling with Statecharts( 6 )

Vol. 14 No. 1 Jan. 1997

5システムをオブジェクト指向的にモデル化するた体的な調査結果の数字を元に議論を行なっている．

めのチャート図の提案。 O-chart と呼ばれるクラ指摘された点については，ある程度予想できるものスとその間の関係（リンクと呼ぶ）を表す図と、著が多いが，実体をより反映している調査データを元者らが以前に開発した Statechart を用いて表現すに，具体的な数値を用いているために，説得力のある。 Statechart は、存在するオブジェクト間の通信だけでなく、オブジェクトやリンクの動的な生るものとなっている．

 DYNAMATE: Dynamic Task Nets for Soft-成・消滅といった振る舞いを記述するために用い

ware Process Management

られる。このため、従来の Statechart で用意されタスクネットと呼ばれるソフトウェアプロセスのている基本オペレーション（動作のトリガなど）にモデル化用のネットを提案。このネットは、制御フ加えて、生成・消滅を行うオペレーションが用意さローおよびデータフローの２つの見方でソフトウエれている。つまり、状態遷移が起こる際に、オブアプロセスを記述できる。ソフトウェア開発プロセ

ジェクトやリンクの生成・消滅が起こる。 O-chart

スをこのネットで記述しておくと、記述に応じて支は、いくつオブジェクトが存在するかや、オブジェ援系が開発プロセスの実施を管理してくれる。タス

クトの集約による階層構造（複合オブジェクト）をク（開発作業）は、ネット上のノードで表現され、図形の包含関係で記述できるようになっている。

あらかじめ用意された状態遷移図 (待ち状態、終了

Inheritance は、 Statechart に新たな状態遷移を状態、休止状態、実施中などの状態を持つ）にした追加することによってサブクラスを作り出す、いわがって実施されていく。また、生成されたプロダク

ゆる「記述の共有」の機構を持っている。また、テトもネットの枝にしたがって、伝播されていく。こキスト部分の記述を C++ の記述とできるだけ合のネットの最大の特徴は、プロセスが実施されるにわせることにより、 C++ プログラムへの変換のしたがって、状況に応じてプロセス記述も変化するしやすさもねらっている。というダイナミズムを、グラフ上の書き換え規則を用いてプロセス記述を書き換える枠組みを用意して

3.7

セッション 8A：プロセスの効果

 A Systematic Survey of CMM Experience andいる。つまり、メタレベルの記述として、あらかじめどのようにプロセスが変化していくかをグラフ上Resultsの書き換え規則でプログラムしておくことができ

本論文では，実際に CMM による評価を行なっる。

た組織を対象にして， CMM によるソフトウエア
プロセスの改善 (Software Process Inprovement,SPI) がどのように行なわれているかを調査した結果を詳細に報告している．この調査では SEI で管理されているデータベースから，過去 1 年から 3年の間に CMM による評価を行なった組織を対象

3.8

セッション 8C：環境

 Simplifying Data Integration: The Design of

the Desert Software Development Environment
ソフトウェア開発環境（プログラミングレベルを中心とする）におけるデータ統合を簡単かつ効果的ににしているため，特定の成功例に片寄らない，実際実現する方法に主眼をおいた論文． PCTE の導入の CMM による効果を類推することに成功していなどによる本格的なデータ統合は，既存環境の継承る．

が容易でないためリスクが大きい．本論文でいう

本論文では「評価実施後，各組織においてどのよう簡単なデータ統合は，ツールの扱うデータ（ファイなプロセスの改善が行なわれていたか」「プロセスル）全体を統合するのではなく，関数，型，変数との改善が成功もしくは失敗した原因はどこにあるのいった論理的要素（フラグメント）を集めてツールか」「プロセスがより成熟した組織の方がそうでは統合のための共有データとする．論理的要素は，そない組織より効率が良い」といった点について，具の定義 { 参照関係の連鎖追跡を主として集められ，

6

コンピュータソフトウェア( 7 )実プロダクトファイルを横断的に捉える仮想ファイに 300K 行の COBOL プログラムを対象に実験をル（フラグメントファイル）が作られる．このよう行っていて、良好な結果を得たそうである。米国特なフラグメント統合のほか，本論文の提唱する環許も申請中だそうである。

境は， ToolTalk をベースとする制御統合，および大規模システムでの使用を想定した包括的なツール

FrameMaker をベースとする共通エディタからなであり、しかも実用的な解決を提供している点は興る．この共通エディタの使用が環境の統合機能を最味深い。ただし、他の言語や他のクラスのアプリ大限に引き出す要となっているが，それが環境全体ケーションへの一般化には、問題が残ろう。の開放性を阻害することにならないか心配である．

3.9

セッション 10A：保守と改良

 A Scaleable, Automated Process for Year 2000

System Correction
2000 年問題とは：プログラムやデータにおいて、日付の年が 2 桁で管理されているために 2000
年の日付において生じる問題である。前年が 99 その次の年が 00 で表現されれば、不具合が起きる。
筆者らは、このような問題を抱える COBOL で記述されたシステムとそのデータについて、年の表現を 4 桁になるよう修正するツールを開発した。

4

経験報告とミニチュートリアル\An operating system development: Windows 3",
Chip Anderson (Microsoft, USA).と、いう題名で、 Windows 3.0 の開発にかかわる話を中心に、マイクロソフトのソフトウェア開発について報告があった。
開発に用いている環境は、 MS-C が８０％、残りがインテルのアセンブリ言語で、ソース管理、テスト管理、問題事項管理などのツールを使っている。また、バグ数のメトリクスを用いている。
総員５０名ぐらいのグループで、テストする人間と開そのアルゴリズムは、まず、プログラムのソースリ発者がそれぞれ１５名、８名が文書作成、４名がプログストから、年に関係ある変数を探し出す。探し出す

ラム管理者、３名がプロダクト管理者、２名が事務で、のは、変数名のパターンマッチングではなく、意味特にプロジェクト管理者はいない。こうすることによっ解析による。解析には、変数の型の概念を拡張したて、皆が製品に責任を持つようになる。

属性が用いられる。すなわち、ある変数が整数型で多 く の 内 容 は、 最 近 出 版 さ れ た 「マ イ ク ロあれば、その変数には、年に関係ない／時刻として

ソ フ ト シー ク レッ ト」 に 記 述 さ れ て い る よ

年を表す／期間として年を表す等の属性がつけられう な こ と が 多 かっ た。 用 い た ス ラ イ ド は、る。その変数が式に現れれば、その式に現れる他の

http://www.mindspring.com/~ chipa/icse96.html

変数や定数にも属性が伝播していく。これを繰り返に置かれている。

して、すべての年に関係ある変数を探し出す。最後ミニチュートリアルでは、ソフトウェア開発支援、に年に関係ある変数を含む式や文を、修正ルールにstatechart の歴史、大規模マルチメディアソフトウェ従って書き換える。

ア開発、ドメイン依存開発環境などについて解説が行な

筆者らのツールは、 COBOL プログラムをの変数の定義を修正して再コンパイルし、ファイルのデータを書き換えるための修正プログラムを生成し、修正が正しく行われたことを確認するためのテわれた。

5

その他のセッション、チュートリアル、ワークショップストデータまで生成する。さらに、筆者らの対象はソフトウェアの複雑度、ソフトウェア開発の工学的ア商用システムであるから、ツールはインクリメン

プローチ、なぜひどいソフトウェアが良く売れるのか、タルな修正を実現する。すなわち、修正対象のシの３つのテーマについてパネル討論が行なわれ、聴衆をステムとデータを、運用しながら、徐々に新しいシ数多く集めていた。

ステムとデータに変えていくことができる。実際

また、本会議の事前の２日間、１４種類のチュート

( 8 )

Vol. 14 No. 1 Jan. 1997

7

リア ルが それ ぞれ の分 野の 専門 家に よって 行な われに電子メールにて協議（調整といったほうがよい？）をた。例えば、 W. Humphrey による個人プロセス、 B.

行った。

Meyer と J. Nerson による Ei el によるオブジェクト指向ソフトウェア構成などがあった。
さらに本会議の前後に、９つのワークショップやシンポジウムが開催された。

6

このような事前協議は、本会議の時間短縮には有用であるが、今回は委員会の前にある FSE-3 の会議に出席する委員にとっては議論できる時間かわずか２日たらずしかなく、今後余裕のあるスケジュール策定が望まれる。

採択論文を選択し、プログラムを編成するためのプロ

FSE-3 の 後、１ ０月 １ ３、１ ４日 の ２日 間、 University of Maryland （ワシントンから電車とタクシーグラム委員会は、１年以上前から委員の選定が行われ、で３０分ぐらい）でプログラム委員会が開催され、どの世界各国から３３名（委員長は除く）の委員が選ばれ論文を採択するかが審議されていった。

プログラム委員会

た。
プ ロ グ ラ ム 委 員 長 は Imperial College （英 国） のTom Maibaum と University of Maryland （米 国）の Marvin Zelkowitz である。委員会の構成は、１４評価がある点以上の論文について担当の代表者１人がその論文のよい点、弱い点を説明し、他の２人が補足する、あるいは反対意見を述べるという形式で審議が進められていった。採否は全員の合議制で決められていった人が米国、１２人がヨーロッパ、４人がアジア（日本２が、意見がまとまらなかったものについては、新たにそ人、香港、インド各１人）であった。の場で査読者をボランティアベースで割り当て、最終的第１７回ソフトウェア工学国際会議（１９９５年米国な判断はその査読者の報告を加味して行った。

シアトルで 1995 年４月２６日に開催）のときに、第１従来の２０編程度しか採択しないＩＣＳＥと異なり、回のプログラム委員会が開催され、投稿論文の選択を行最初からかなりの数の論文を採択しようというプログラ

うための第２回のプログラム委員会の日程が検討され、ム委員長の意識が感じられた。その結果、５２編もの論それまでの作業手順が審議された。その結果、委員会は文が採択されるという結果にいたった。採択された論文１０月の初旬にワシントンで開催される Foundation ofの質は、実際に会議での発表を聞くと、採択論文数を増Software Engineering の第３回会議（以下、 FSE-3）やしたため、やはり玉石混合となってしまったという印に合わせて近郊で開催されることになった。

象であった。

論文の査読に関する手順としては、投稿論文締め切り

しかし、採択論文を従来のＩＣＳＥの２倍もとったこ

後、２週間ほどで全論文のアブストラクトを委員に送付とにより、参加者が増え、いっそう関心が高まってきた

し、委員がその中から、査読をぜひやりたいもの、査読ことは大きく評価できる。個人的には、参加者を増やできるもの、査読できないものを選択して、委員長に送し、活発な交流の場とするためにも、この方向を維持しることになった。委員長はこのデータをもとに、担当者ていくことがよいと思われる。の割り当てを行った。これらの作業は、アブストラクトの送付を除いてすべて電子メールで行われた。なお、査7

読報告の送付や後で述べる委員会の事前の議論もすべて

会場は、ベルリン工科大学のキャンパスの一角で、８電子メールを使って行われた。
論文投稿数は全部で２１３編あり、１編につき３人の会議の運営について００名収容のメインホール、２００人以上は入れそうな傾斜のきつい階段教室を５ー６つ使った。

委員が査読につくため、１人あたりの担当は２０編程度大学なので、通常の学生が、会場内をうろうろするのとなった。原則として委員のみが査読を行い、査読期間で、あまり落ち着かなかったが、しかし、食堂が幾つもは１か月半弱であった。査読結果が直ちに電子メールであり、インターネットアクセス用の計算機も大学の演習集められ、集計が行われ、委員会開催までの１週間の間室のものが使え、便利であった。

で、評価が分かれた論文に関して、担当者同士が事前レジストレーションが、８５２人と、近年になく大き8コンピュータソフトウェアな数字なったのは、以下のような理由であろう。

 い ろ い ろ な チュー ト リ ア ル、 ワー ク ショッ プ があった。

 採録論文数が５０ほど（今までは３０程度）に増えた。

 宣 伝が 行 き 届い て た （特に ヨー ロッ パに 対 し ては）。

 地元の会社にお願いして、寄付と同時に動員をかけてもらった。

 東欧の人に旅費を出して来てもらっている（旅費は企業からの寄付金）。
最初の会式の挨拶は、一部ＡＴＭのネットを使って、ボンにあるＧＭＤから行なわれた。
また、毎日朝、昨日の内容を反映するような６ { ８ページの新聞を発行していた（昨年の会議から）。今回は、かなり過激な内容になっていて、昨日の基調講演に対し、否定的なコメントを載せるなどしていた。また、

WWW で発行した内容をそのまま掲示し、会議に参加していない人も見れるようになっていた。

8むすび

本稿では、第 18 回ソフトウェア工学国際会議の内容を概説した。
次 回 は、 Boston で 1997 年 5 月 18{23 日 に 開 か れ( 9 )る。詳細は、

http://www.ics.uci.edu/icse97/cfp.html
から得ることができる。

1998 年の第 20 回は、４月１９日から２６日まで、京都の国立京都国際会館で開催されいることが決まっている。今回、その会議に向けて、いろいろな意見をもらった。例えば、基調講演には、日本に特有なもの（ゲームソフト開発とか、ソフトウェアの日本語化問題など）について聞きたい、新しいソフトウェア作成動向に対応した内容にしてもらいたい、今までの ICSE の威信や名声を保って欲しい、安い宿を提供して欲しい、など、非常に多岐に渡っている。今後、それらの要求にこたえるべく努力していく必要がある。
なお、本会議のプロシーディングスは、 IEEE Com-

puter Society Press より出版されている。
IEEE Computer Society Press Order Number PR07246
ISBN 0-8186-7246-3
ISSN 0270-5257
謝辞

論文の要約に御協力頂いた大阪大学基礎工学部大学院の松下、高田、神谷、大下各氏に感謝致します。