MonthlyN
e
w
s
l
e
t
t
e
rfrom
SoftwareEngineersA
s
s
o
c
i
a
t
i
o
n
Volume2…9 …
sr 1987

目次

rMISE ソフトウェア環境ワークショップ
1.はじめに

2.1990 年代ソフトウェア技術の予測
2.1 現在(1 985 年)の妓術状況
2.2 将来(1 990 年半ば)の技術状況

3. 技術ワーキング・グループでの討論

3.2 分散化

3.3 デー タペ ース 支援
3 .4鉱 張 佐

3 . 5 人工知能
4. 横断的ワーキング-グループでの討論
4 . 1 統合化
4.2 プロトタイピング
4.3 計測4.4 単一言語環境と多重言語環境
4. 5 ユーザ-インタフェイス
4.6 斬新的改善と革新的改善
5. 全体セッションでの討論
5.1 実行組織の特 徴

5.2 ランチョ・サンタフェ再訪
6. 全体的な関心事項
7. まとめ8 . 謝辞9 . 参考文献

会員状況

1 3 445
3 5
1
44 4
17
12
25
25
27
21
33
34
35
37
379 3 344

3.1 ツール

1 2255799

編集部からソフトウェア技術者協会 (SEA) は，ソフトウェア・エンジニアの，ソフトウェア・エンジニアによる，ソフトウェア・エン
ジニアのための団体であり，これまでに日本になかった新しいタイプのプロフェッショナル・ソサイエティたることを目指して，

1

985 年 12 月 20 日に設立されました.

現在のソフトウェア技術が抱える最大の課題は，ソフトウェア・エンジニアリング研究の重量前線(ステイト・オブ・アート)と ，その実践状況(ステイト・オプ・プラクティス)との聞に横たわる大きなギャップを埋めることだといわれています

ソフトウェア

技術の特徴は，他の工学諸分野の技術にくらべて属人性がきわめて強い点にあります.したがって，そうしたテクノロジー・トラン
スファの成否の鍵は，研究者や技術者が，既存の社会組織の壁を越えて，相互の交涜を効果的に行うためのメカニズムか守重立できるか否かにかかっています. SEA は.ソフトウェア・ハウス.計算センタ.システム・ハウス.コンビュータ・メ ー カ.一般ユ ー ザ.
大学，研究所など，さまざまな駿場で働く人々が，技術的・人間的交涜を行うための自由な<場>であることをを目指しています .
SEA の具体的な活動としては，特定のテーマに関する研究分科会 (S 1
G) や地方支部の運営，月刊機関誌 (SEAMAIL)の発行，各種のセミナー，ワークショップ，シンポジウムなどのイベントの開催，既存の学会や業界団体の活動への協力，また，
さなざまな国際交涜の促進等があげられます.

なお SEA は，個人参加を原則とする専門家団体です.その運営は，つねに中立かつ技術オリエンテッドな視点に立って行われ，特定の企業や組級あるいは業界の利 ぷ を代表することはありません.

代表総事:

鈴木弘

鍛任幹事:

岸田孝一長井剛一郎盛田政敏吉村鉄太郎

幹事:

稲田博白井義美大木幹雄岡本吉晴落水浩一郎柿下尚武木村高志久保宏志熊谷章斎藤信男佐藤千明芝原縫二杉田義明田中慎一郎鳥居宏次中園順三西尾出能登末之針谷日月藤野晃延松原友夫
丸尾浩一水谷時雄三浦信之村井進

会計監事:

辻淳二吉村成弘

常任委員長:

岸田孝一(会誌編集)

盛田政敏(企画総務)

吉村鉄太郎(技術研究)杉田義明(セミナー・ワークショップ)分科会世話人環境分科会 (SIGENV) :歌代和正北村昌人田中慎一郎
管理分科会 (SIGMAN) :相沢圭一芝原雄二野々下幸治
教育分科会 (SIGEDU) :大浦洋一杉田義明中国順三
再利用分科会 (SIGREUSE) :青島茂阿倍正平村井進
AI 分科会 (SIGAI) :安倍昭敬梅林信之広川昭八野辺良一蔵野晃延

ネットワーク分科会 (SIGNE司:青島茂鈴木弘野中哲
法的保護分科会 (SIGSPL) :能登末之CAI 分科会 (SIGCAI) :大木幹雄寺嶋裕一中谷多哉子中西昌武

ドキュメント分科会 (SIGDOC) :田中慎一郎丸尾治ー
CAD 分科会 (SIGCAD) :柿下尚武
支部世話人

関西支部:白井義美盛田政敏

横浜支部:熊谷章林香藤野晃延松下和隆
長野支部:青柳和男佐藤千明細野広水

名古屋支部:岩田康鈴木智西村亨
SEAMAIL 編集グループ:大槻売人岸田孝一佐原伸芝原雄二関崎邦夫田中僕一郎長弁修治野辺良一藤野晃延

渡逸雄一

SEAMAIL Vol.2 ,NO.9

昭和 62 年 9 月 1 日発行

編集人岸田孝一
発行人

ソフトウェア技術者協会 (SEA)〒 102

東京都千代田区隼町 2-12

印刷所サンビルト印刷株式会社
定価

〒 162
500 円

藤和半蔵門コープビル 505

東京都新宿区築地町 8 番地

MessagefromEditor.2No.9
SeamaUVol

編集部から
1.特集について

セミナ ー やワークショ ップなどの活動を実施する非営利団

すでに予告した通り.この号では.

1985 年の秋にア

体として.

B.Boelun , L. Druffel , W . Ri ddle の 3 氏によメリカで開かれた環境ワークショップの報告書全文の日本って，数年前に設立された. 84 年から 86 年にかけて毎語訳を.特集として掲載する.

年夏にコロラドで開かれた集中セミナーには，日本からもオリジナルは，主催団体である rþ.，rrSE からテクニカル・ レポ

多くの方々が参加されている.

トとして刊行され.また. ACM/SIGSOFT の機

今回ここに報告されたワークショップは.

1985 年の関誌Software E
n
g
i
n
e
e
r
i
n
gNotes の 1986 年 1 月号に11 月に .NSF の後j妥を得て. Ri ddle 氏が中心になっても，ほぼそのままの形で転載されている.

企画 ・運営したものであ る.

日本語への翻訳許可は.

rMISE の主宰考であり.このレポートの執筆者の l 人である

「 環境 J をテーマとするワ ー クショップは.このレポー

W. E. Ri ddle 氏の御好意

トにも述べられているが.

1980 年の初夏にカリフ才ル

により ， 約 2 年前に.氏が第 l 回春のセミナー・ウィーク

ニアで開かれたもの(主催は NBS ・米連邦標準局)が最初に基調講演者として来日された折り. SEA1v仏L か取 得しである . このワークショップは.

た.実際の翻訳がここまで遅れたのは .単純に編集部サイロジェクトを発足させるきっかけとなり . また，プロトタ

ドのパワー不足のためであって，別に他意はない.

イピングやプロセスに関するワ ー クショ ップ をその副産物

ただし，このワ ー クショップの討論内容は，ソフトウェ

TOOLPACK などのプとして生み出すなど. 80 年代前半のソフトウェア技術に

ア開発支緩環境の摘築に関する技術動向を広くサーベイし，

大きな影響を与えた .

90 年代半ばへ向けての技術戦略を採るというものであっ日本でも，たとえば 80 年代前半の代表的環境プロジェて，現在のわれわれにとって，依然と して数多くの有益なクトである JSD のSMl三F フ・ロジェクトは ， このワークシ

示唆を含んでいる

ョップの影響のもとに.

たとえば.このワークショップが聞かれたのは，偶然にもあの」シグマ

TOOLPACK などアメリカの同世代プロジェクトと連携を取りつつ進められた .

プロジェクトが正式に発足し.開発

rMISE のワークショップは，そうした 80 年代前半の本部内て\プロジェクトのポリシーや計画をめぐって，さ開発成果を総括し.今後の 10 年間の開発の枠組みを設定

まざまな論議が闘わされていた時期と 一 致する.

することを目的として ，計画された . そこには，また.惜そうした観点から，いわばこのレポートを 1 枚の海図としくも(政治的な理由で?)中断された DOD/STARS プ

して，シグマのこれまでの航跡をふりかえってみると，個ロジェクトで摘かれた新環境構築のプランを，より一般的々の技術項目についても，また，全体的 な開発戦略や組滋

また現実的な形にパラフレ上の問題についても，考えさせらる れことがいくつもあるていたと推測される. rr.，但SE の関係者 3 氏は，いずれもように感じられる .

STARS 立案の中心人物であった.その壮大な(いささかズしようという意図も含まれそうした反省は.シグマだけに限らない.個々の組織内壮大に過ぎる)計画の全容については.

において.ソフトウェア環境の問題に関心を抱き.それぞ誌 1983 年 1 1 月号を参照されたい .

れの立場での改善努力を心がけておられる方々とって.こ

I
E
EECom
p
u
t
e
r

現在アメリカで推進されている 大規模な環境プロジェクの レポ ー トは.これまでの技術 開発のあり方を再検討し，ト(たとえば.

今後の進路を設定するさいに，大いに参考になるものと信)の狙いが.いずれもここに報告された討論の延長線上にずる.

あることは.明かである.また ， 昨年から日米共同で開始

MCC や SEI あるいは SPC におけるそれされた 釦A プロジェクトも同様であると考えられる.
2. ちょっ左余計なコメント
ここで，蛇足ながら.

この原稿が印刷所にまわっている頃.長野市で第 3 回

r
.
r
r
r
S
E とこのワ ー クショ ッフ・のSEA 環境ワ ークショップが開かれている周辺について，多少解説を加えておく.

入った討論と成果に期待したい.

rMISE (
R
o
c
k
y M
o
u
n
t
a
i
n I
n
s
t
i
t
u
e o
f Sof
t
w
a
r
e
E
n
g
i
ne
e
r
i
n
g) は.ソフトウェア工学の普及を目的とする‑
1‑

そこでの熟の

S
e
a
m
a
i
lVo
l
.2N
o.9

rMISEEnvironmentWorkshop

環境構築技術の現状と未来を探る

rMISE ソフトウェア環境ワークショップ
討

論

記

録

WilliamE
.
R
i
d
d
l
e • L10ydG.WilIIams

編

岸 田孝一 ・村井進訳

1. はじめ に1985 年 1 1 月 12~15 日の 4 日悶，米国コロラド州ボールダーにおいて. NSF (Nat
i
o
n
a
l S
ci
e
n
c
e
Fo u ndation) および rMI SE(
RockeyMount
a
inI
ns
ti
tut
eofSoftw
areE nginee ri ng) をスポンサーとして.

ソフトウェア開発環境に関するワ ー クショップが IJflf監されたワークショッフ・の中心的な議題は.もちろん .
において，(自動化 さ れた)

ソフトウェア環境 であったが，討論の過程

ソ フ トウ ェ ア ・ プ ロ セス の 概 念、 もまた，きわめて重要なテーマとして浮かび上がってきた

ここで，プロセスとは，ソフトウェア ・ システムの開発 ・ 進化の過程で行われる一連の活動を指す.プロセスと環
境は，明らかに，お互いに深い関係を持っている.プロセスに関する 1 つのパラダイム は ，それ を 支媛する特定の環境を必要とするし.逆に .13: 演は l つまたは複数のパラダイムを支媛している.今回のワークショップ

では，環境に関するさまざまな問題点、を討論する過程で.プロセスについても間接的な言及がなされた.しかし，プロセス自体の改善は . 直接の話題としては取り上げられなかった.

このワ ークショッ プの目的は.

ソフ トウェア環境に関するいくつかの重要な問題領域における基本的な課題を洗い出し，技術の改善や高度化 の ために行うべき特定の活動を明らかにすることであったの改善提案がなるべく広範囲な応用分野をカバーできるように ，

討論は，これら

ソフトウェア環境の一般的な(応用分野と独立した)側面に焦点を当てる形で進められた.

会議の全体的構成は，図 1 に示す通りであった.すなわち.

19 85 年の現状から出発して .

90 年代半ばにおける望ましい状況に到達するための改善プロセスが，かなり詳細に討論された.討論の枠組みを統一する
ために，まず.この改善プロセスに彰響を及ぼすであろういくつかの要因の確認が，ある程度の時間をさいて行われた.これは，主として，現在および 1 0 年後の状況 を 特徴づけるソフ ト ウェア開発のパラダイム，成果
物.開発-管理組織，支媛環境，基礎技術などの各項目について.それぞれの属性に関する討論上の仮定を立てるという形であった.将 来の予測 にあたっては， 何 が望ましいかではなく ，何 が実現可能かという観点からの検討がなされた.影響要因を決定するためには.当然，この改善プロ セ ス自体が持つ一般的性格に関する議論や，改普の具体化のための周辺条件に関する仮説の設定を行わなければならないが，後者の話題はそれほど真剣には論じられなかった.

改善プロセスの 一 般的性格については.かなり の 時閣をさいて討論が行われた.そこでは.とりあえず，プ
ロセス改善のための諸活動が.きわめて革新的なパラダイムへの切り替えや.革命的な新技術の導入によって.
現状からの大幅な飛躍を図るのではなく，現在の環境がそなえている能力を徐々に鉱張して行く進化論的また.
2.

rMISEEnvironmentWorkshop.2N
o.9
SeamailVolは漸進的な考え方にもとづいて行われるという仮説が採用された.短期的には.そうした漸進的なアプローチのほうが，成功の可能性が高いと思わ れたからである.

改善プロセスの特徴-システムおよび-システ ムおよび

ソフトウェア製品

ソフトウェア製品

・ソフトウェア開 発・.ソフトウェア開発・

進化のパラダイム-自動化支媛環境-ソフ トウェア開発組織/¥

進化のパラダイム-自動化支媛環境

中期活動

短期活動

-ソフトウェア開発組織

.基礎技術

.基礎技術

1985年の技術状況

1995年の技術状況
国 1

改善プロセス

しかしながら.ソフトウェアの開発 ・ 保守に対する革命的なアプローチや新技術がまったく無視されていた

わけではない . 実際.いくつかの研究開発活動，すなわち.近い将来において.漸進的なアプローチをガイドし，新しいプロセス・パラダイムやソフトウェア技術への転換を容易にしてくれることが期待されるようなものに対しては.特別な関心が寄せられた.漸進的な改善プロセスと箪命的なそれとの対比.そしてまた.両者をいかにして統合するかという問題は.以下のレポートを読めばわかるように，ワークショップ全体を通じて.
何回となく論議の対象として取り上げられた.

望書加者の分布は.大学・産業界・政府機関の 3 者にほぼ等分にわかれ.かれらの関心事も，環境改善に関する高次元な計画の問題と.具体的な環境の設計・構築上の問題とに，ほぽ同程度にわかれていた.ワークショ
ップの開 催に先立って，い くつかの話 題についての予備的な議論の材料が ，あらかじめ全参加者に配布された.

それぞれの参加者は，これらの話題に関するポジション・ぺーパを執筆し，討論のグループ分けは，このポジ
ション・ぺーパにもとづいて行われた.

ワーキング・グループでは，ツール，分散環境，データベース支媛.環境の鉱張性. AI技術の利用，という5 つの技術的な話題について，討論が行われた.各グループは，まず.それぞれの分野で今後 1 0 年間に起こるであろう変化についての予測を行い，次に，その中て'特に注目すべき問題点が何であるかを議論した.そして，録後に，それらの問題点を解決するために必要な短期および中期の活動項目を決い出した.

これらの個別的な話題に加えて，すべての技術課題に最多響を及ぼすようないくつかの「横断的話題 J に焦点を絞ったワーキング・グル ープ も作られた.これらの横断的グループは，実際.それぞれの技術グループのメンバーを必ず含むような形で構成された.横断的な話題として取り上げられたものは.以下の通りである:環療の統合，環境構築におけるプロトタイピング・アプロ ー チ，計測と評価，単一言語環境と多重言語環境，人間とのインタフェイス，改善への漸進的アプローチと革命的アプロ

‑
3
‑

チ.

SeamailV
o
l
.
2No.9

rMISEEnvironmentWorkshop

ワークショップの冒頭で，まず.これらの個別的および横断的話題が，ここで取り上げるにふさわしいものかど う か，が議論された . 図 2 に示 すように ， その他の話題も数多く提案されたが，それらはあまり重要なものとは見なされなかった . とはい え .それぞれの話題のあいだには.強い相互関係があるので ， こうした付加的な話題も.全体討論やワ ー キ ン グ・グループの討論の中で.少なくとも部分的には取り上げられた . 全体セッ ションは.各ワ ー キング・グループからの報 告 の場として用いられた.また.特に全員で考えるにふさわしい話題は.ここで取り上げられた.たとえば.現在および 90 年代半ばの状況の性格づけ.いろいろな改善活動を実行する組織 / 機構の問題 .

5 年前にカリフォルニア州ランチョ・サンタフェで開かれた類似の環境ワー

クショ ッ プの回顧 ， などである .

-アニメ ー ション:

開 充途中のソフトウェア-システムの動作を自に見えるようにする .

・ソフトウェア・プロ セス :・雇座管理:

ソフトウェア開発-進化のための基本パラダイム .

パックア ッ プ，再スタ ー ト，取消等の動作を含むセッション情報の管理.

・ソフトウェア・プロセス管理:
ソフトウェア開発/保守の過程に関する情報の管理，方法論上での制約の強制.パックア ッ プなど の 録作を含む，チーム活動に対する配慮が重要である .
・グラフィ γ クス.

グラフィ ッ クス技術を用いたソフトウェア・プロセス支媛.

-特定目的の環境:

・タイミング/位置づけ:

特定目的の環境の開発を，どのようにして，一般的な環境構築

技術の研究開発の枠組みの中に組入れるか.

.s分集合:

特定 目的の環境と汎用環境はどうか.たとえば.特定目的の環境は，汎用環筏

の一部であるかどうか.
・調整と応用:

汎用環境から特定目的の環境を作り出す技術.汎用環境の部品のプールの中から必要に応じて」特定の環境をどのように構築するか .

-ソフトウェア・プロセスからの独立性:

環境とそれが支媛するソフトウェア・プロセスとの間の関係についての諸問題.独立性を保つための技術.独立性を維持しながら ， 特定のプロセスに関する知識を そ の上に盛り込むことによってもたらされるメリット .

・移値性 :

異な っ た環境問て'人間 ・ ツ ー ル-情報を移動させることを可能にする.異なったホストに環境を移動できるようにする.
-再利用性 :

環境の 部品がどれだけ再利用できるか .

-ツ ー ルの分解:大規模でモノリシックなツールを，具体化に則した部分に分解する .

・部品のカタログ化:

部品集合の保守 .

・再利用にもとずく開発;

部品の再利用をして環境を開発する . 再利用を支t愛するアーキテクチ‑¥'.

-環績のための部品:再利用にもとずく環噴開発，特定のパラダイムを支援する環境の需要に応じた開発. パ ラダイムの独立性の維持等のさまざまな目的のために.どのような部品をどのように使えばよいか .

・ツール橋祭ツール:

ツ ー ル・ジェネレータや宣言的表現等を用いて環境構築者を支t愛する.

国2

以下の各章では，このワ直接取り上げられなかった話題

ク シ ョップでの討論を体系的に報告する.すなわち.まず第 2. では.ソフトウ

ェア環境の現状と今後 1 0 年間になされるであろう改善に関する参加者全体の意見を要約し.環境技術が抱えている現在の問題点とそれ ら を解決すぺく提案された諸活動を理解するための基礎を設定する.各技術ワーキン グ・グル ー プ，横断的ワ ー キ ング ・グル ー プ.および全体セッションでの討論は，それぞれ，第 3.4.5
章にまとめてある . 以上のまとめは，ほぽワークショ ッ プ自体の構成に対応している . 続く第 6 主主では，これらの個別討論の中から浮び上がってきた 一 般的な問題点について報告する.最後に，第 7 章では，今回のワー

クショップの総括的な結論を述べる .

.
4.

rおnSE E
nvironmentWorkshop

SeamailVol
.2N
o.9

2
. 1990 年代ソフトウェア妓術の特徴予測
今回のワークショップでは，現在および将来の技術的状況について，さまざまな次元からの特徴づけが試みられた.

ここで取り上げられた諸次元は.システムおよびソフトウェア製品，ソフトウェア開発・進化のパ

ラダイム，自動化支媛環境.ソフトウェア開発組織.およ び基礎技術.の 5 つであった. 一 般に，そうした特
徴づけはきわめて困艇であり.参加者の意見の一致は到底期待できないのではないかと予想されたが，結果的には，かなりの合意が得られた.

この章では，技術の現状評価および将来予測に関する参加者全体の意見を要約する.それぞれの技術ワーキ

ング・グループおよびいくつかの横 断的ワ ー キ ング・グループでは， 担当分野での問題点を認識し活動項目を洗い出すために，それぞれの立場からの現状評価と未来予測を行った.ここでは.それらの成果もあわせて報告する.

2.1 現在( 1985 年 )の技術状況(1) システムおよびソフトウェア製品

今日のシステムおよびソフトウェア製品は，その複雑さの点で . 大きな幅を持っている

他のシステムに埋め込まれ，その制御機能を提供するような形になっているものも多い.しかし.大多数は.スタンドアロン型

である.製品の信頼性にはかなりの差があり.保守性や鉱張 性は限られている移植性にも ， やはり限界があり，分散処理の機能はほとんど用いられていない.製 品の規模はバラエティに富んでいるものの ，非常に大規模なものはまれである.多数のパージョンを作成し，保守することは，比較的よく行われている.

(2) ソフトウェア開発 - 進化のパラダイム

研究開発の最前線で考えられているパラダイムと.現場で実践されているものとの聞には，大きなへだたりがある.いま 研究コミ ュニティで検討されている辰先 端のパラダイムは，旧来のウォ ータフォール・ モデルにプロトタイピングの概念を補強した変形版だとみなすことができ ょ う.一 方，実践の現場は.かなり無秩序な状況にあり，はっきりと定義された方法論を採用している組織は，ほと んど 存在しない.一応の方法論が用いられている場合には.たいがい.プロジェクト m 棋がかなり大きく. そこでは，ウォ ータフォール・ モデルにもとづく管理指標が採用されている.新しい応用分野や要求が不確定な場合など.特殊な状況下では，リスクを減少させるために，ラピッド・プロトタイピングも利用されている.

現在のソフトウェア

いう特徴を持っているプロセスは， 研究開発段階 のもの も ， また ，実 践段階のものも，すべて 「集 中型 J と集中型のプ ロセスは ，集中裂のシステムと閉じく.かなり 可視性が高い

すべてのものがすべての人聞の口に見えるということが基準であり，こうした可 規性を除去するためには .特 別な手順を踏まなければならない.並行作業の管理.一貫性の維持，可変な情報への過度の依存などの理由から.必要以上に多くの情報が.複数の人間によって共有されている.

(3) 自動化支怨環境

現存するほとんどの自動化されたソフトウェア環境は‑5‑

Uni x や Lisp またはこれらのシステムから派生し

S
e
a
m
a
i
lVo1
.2N
o.9

r
MISEEnvironmentWorkshop

た基本概念、にもとづいている . そして，全休として， Fortran , Modula.Smalltalk.Ada など.広範囲の言語を支援している

現在の環境は.データベースに閃しては，最低限の支媛しか提供していない.原始 的 な履歴管理の 機 構は存在し，また，並手IJ 性・統一性

一貫性に関する制仰が得られる場合もある.しかし.大小さまざまな単位で モ

ジュール化されたオブジエクトを総合的に管理する仕 鍋 けは.ほとんど存在しない.さらにまた.大部分の環
境デ ー タペ ー スは，格納されたデ ー タに対して，ただ l つの視点しか支媛していない.一般的にいえば，現在の環境データベースは「受動的」であり，その制御は，主として自動化ツールや人間など.データベ ー ス自身の外部で行われている(4) ソフトウ ェ ア開発組織

現在のソフトウェア開発組織は，その規模も tú~長さもまちまちである.規模については.数人の技術者が集まった小規模なカスタム ・ ソフトハウスから，複 維 な大規模システムの開発を担当する 数 百人規模の企業内組
織に至るまで，さまざまなバラエティがある.組織上の複雑さは.大まかにいって，その規模に比例しているが ， 会社の構造やプロジェクト管理のやり方などによって，複雑さが噌す場合もあるても，その構造や管理は.理想的な状怒にはなっていないように思われる

どんな形の組織におい一言でいえば.現在の状況は.かなり「チ ー ム・エントロビ ー 」が高いといえよう.

( 5) 基 礎技術

現在のソフトウェア環涜は.主として.中央のメインフレーム ・ コンビュータとダム端末を通じて対話する
ような形で具体化されているいろいろなワ ー クステーションも使えるようにはなってきたが，まだ一般には普及していない

分散型の環境もいくつか存在するが.分散の程度はきわめて限定されている

複数のホスト(メンフレーム

およびワークステーション)にまたがるような環境を支媛するためのネットワーク技術も 利 用できるようにはなったが，まだその応用範凹は m~ られている . 現在のネットワーク構造は.大きくいって， LAN と WAN の2 つのカテゴリに分かれる.前者は，近距縫での高速なコミュニケーションとファイル転送を提供し ， 後者は.
地理的に分散した開発者に対して.原始的なコミュニテーションと情報の共有手段を与える. LAN と WANの主なちがいは，コミュニケーションの周波数帯 l或と情報の分割単位とである.

人工知能は，ユーザ・インタフェイスなどいくつかの分野で，現在のソフトウェア 環 境に間 接 的に貢献している.しかしながら，ソフトウェア・プロセスへの支媛という面では， A 1 技術はまだ十分に成熟しておらず，大幅な直接的貢献をもたらすには至っていない

また.現在の A 1 技術は ， 大規模プロジェクトに応用するには，まだいろいろ問題があり，そ の 意味で，ソフトウェアの開発・進化パラダイムの面での利用も限定されて
いる.

‑
6
‑

rMISEEnvironmentWorksbop

.2N
o.9
S
e
a
m
a
i
lVol

2.2 将来(1 990 年代半ば}の銭術状況(1) システムむよぴソフトウェア製品

1990 年代半ばのソフトウェア製品が，その複維さのバラエティや，埋め込み型要素としての利用のされ方，あるいはスタンドアロン型としての特性などの点において，極端に現在と異なっているとは考えにくい.
最も大きな変化は，おそらく.複雑さの程度が飛斑的に噌大するという形で発生するだろう.過りが許されな
いような分野でのソフトウェアの利用が拡大することで，信頼性に対する要求がより強くなり.製品の信頼性はそれだけ向上する.しかし.それでもなお，信頼性にはかなりのバラツキが存在するものと予想される.保

守性や拡張性も改善されるだろう. 1990 年代半ばにおける応用システムおよびソフトウェアは，高度な分散化の傾向を示すようになり，また.エキスパート・システム技術がかなり利用されるようになるものと考えられる

しかし，ホスト・システムの種類が噌加するために，移植性は今日のシステムよりも悪くなるだろう.

1990 年代のシステムでは，却様のバラツキが広がり.きわめて大規模な応用がより一般的になってくる.

また，開発・保守の対象となるパージョン数は，現在のシステムよりもさらに多くなるだろう.
(2) ソフトウェア閲発・進化のパラダイム

1990 年代半ばにおい ても，ソフ トウエア の開発・進 化の諸活動が無秩序な形で行われることは，やはり一 般的であるだろ うが，より多くの 組織が，系 統的なアプローチを採用するようになるにちがいない.その意

味では，研究開発と笑践との差は.いくらか絡まるものと期待される. 10 年後に一般的になっているであろうパラダイムの有力候補としては，プロトタイピングで補強された現実的なウォータフォール・モデル，プロ
グラム変換を中心とするフォーマル・アプローチ.再利用にもとづくソフトウェア・プロセス・アプローチなどが考えられる.

ソフトウェア・プロセスに対する将来のアプローチは.集中型ではなく.分散型のシステムに近くなるであろう.それらのアプローチでは，プロセスの可視性はいまより低くなる.情報の共有形態は，各個人やチームがそれぞれ固有の情報を管理し.プロセスおよび成果物の特定の局面に関する情報を別々に格納する形の，ゆるやかに結合されたソフトウェア・システムのスタイルに近くなるだろう.情報は，十分に定義されたプロトコルにしたがって共有され，並行性の管理や，一貫性および完全性の維持などの問題が軽減される

また，共有すべき情報を注意深く選択することにより，成果物の変更による塁手響を，より効率的に局所化することが可能になる .

(3) 自動化支媛環境

将来のソフトウエア環後は.ワークステーションを基本とするものに変わって行くだろう.個人用ワークス
テーションの採用により.それぞれの作業に合わせて環境をカストマイズすることが容易になり.特殊目的の専用環境がどんどん作られるようになる.これらの専用環境で.プロジェクトの管理や，システム設計.保守などの.専門的な活動が支 tll されるようになる.こうしてワークステーションを専用化するためには，分散型の異機種アーキテクチャが環境のホストとして想定される必要がある.

1990 年代の初期から半ばにかけてのソフトウェア環境では，より高度なデータベ ー ス支緩が可能になる

すなわち，より複雑なデータ

モデル，一貫性および並列制御のメカニズム.ユーザに対する複数の視点の提‑7‑

SeamaUV
o
l
.
lNo.9

rMISEEnvironmentWorkshop

供，モジュール化のレベルが異なるオブジェクトの一括管理，主要なプロセスおよび成果物の履歴管理支媛.

などの機能が一般的に利用できるようになる . デ ー モンやトリガなどのメカニズムを利用して，ツールとデ ー
タベ ー スをより密接に統合化することにより，環境デ ー タベ ー スは受動的な存在ではなく.能動的にデータベー スの内容および構成の管理に 「参 加」するようになる.

(4) ソ フトウェア 開発組織

1990 年代半ばのソフトウェア開発組織の規模や複雑さは，たぶん現在と問機にまちまちであろう . しかし，高度なコミュニケーション手段など，あちこちに散らばった開発者グループを支媛する技術が実用化されることによって.プロジェク ト・ チームは， 地 理的により分散化するようになるものと考えられる.こうした分散型のプロジェクト編成は，

1 990 年代の前半にはまだかなり高いまま残る「チーム・エントロビー』の改善に役立つだろう.

(5 ) 基礎銭 街

中央のメインフレーム・コンビュ ー タを使用して環境を具体化する方法は，やはり，基本的なアプローチとして残っているだろう.しかし.ワークステーションをスタンドアロン・コンビュータとして，あるいは中央システムのインテリジェント端末として利用することが.より重要な意味を持ってくる.将来のワークステー

ションは，高解像度カラー・グラフィックスや音声入力.より大きなスクリ ー ンなど，ユーザ

インタフェイスの面で大幅に改善されるだろう . 人間とコンビュータのコミュニケ ー ションに対する理解も進み，これらの機能が効果的に使用できるようになるものと期待される .

将来の環境では.分散システム技術がより広範囲に利用されるようになるだろう.ユーザとワークステーシ

ョンの作業を支娠するための機能は，いちじるしく改善されよう.しかし， LAN と WAN のちがいは残り.

同じオフィス内の人間と対話するのと，遠隔地の人間と対話するのとでは，やはり明らかに事情が異なるだろっ.

1 990 年代半ばの環境では，人工知能妓術がより直接的に利用されよう.最も有望なのは . 知識表現と設計モデルの 2 つである.知識表現は，プログラミング技術だけでなく，問題分析や仕織化にも有用である.また ， 完成度の高い設計モデルは.ユーザに対する環境側からの支媛機能を改善する.

1990 年代半ばまでには，各応用分野別の特殊な仕鎌記述言語が.完成の域に達するだろう.これらの言語によって.高水準言語によるシステム仕様の記述と.その仕鎌 を 効率てきなコードへ変 換 することが可能になる.小規模から中規模プロジェクトで.そうした半自動的な変 換 を支媛するツールが現実の も のになるだろ
っ .

‑
8
‑

rMISEEnvlronmentWorkshop

SeamaUV
o
l
.
2No.9

3. 技術ワーキング・グループでの討論

技術ワーキング・グループでは.それぞれの話題に関連して，特定の活動項目を洗い出すための討論が行われた.各グループは，短期 (80 年代後半)および中期 (90 年代前半)の活動項目を区分して確認するとともに，それらの背景にある基本的な問題点を明らかにし.各項目の実施時期や優先順位についても検討を加えた.

3.1 ‘';1 ‑ ""現在利用できる個々の環境は.比較的範囲が限定されている . 一般的に.既存の環境は.ソフトウェア・ライフサイクルの一部をカバーするだけであり.ソフトウェア・プロセス関係者のうち.ほんの一部の要求に応えているにすぎない

また.ソフトウェア・システムの諸特性のうち，限られた側面についての意志決定を支援しているだけである.

しかし.現存する自動化ツールを集大成すれば，ソフトウェア・ライフサイクル.要員..志決定ニーズなどに関して.非常に広い範囲をカバーしている.したがって，現状における問題は，実用的なツール集合がカバーする範囲の幅を広げることではなく，利用可能なツール群をどんな形で統合すれば，それらが全体として広範囲な一貫した自動化支 I還を提供しうるかを，考えることである.

3. 1. 1 問題点

ここでの重要な活動項目は，ツール群を集めて環境を構成するプロセスを容易にすることに関連している.

拡張容易佐や統合化のレベルなと，環境の持つ個々の特性は.このプロセスおよびそれに対するわれわれのア
プローチに.かなりの影響を与える.しかし，これらのことがらから派生する問題点は，他の技術グループおよび積断的グループの報告で鼠われる.ここでは.どのような自動化ツールが利用可能であるか，および.別々に開発されたツール群を 1 つの環境にまとめあげるための能力をどうすれば改善できるかという点に焦点を絞った形で，討論が進められた .

(1)どのようにツールを禍造化し汎用的なユーティリティ都品に分解するか

環境ユーザの自に見えるツー JL 訴は，一般に.数多くの共通な内部機能を持っている.たとえば.大部分のツールでは，ソフトウェア記述を解析して.何らかの内部表現に変換している.したがって，ツール・フラグ
メントを環境全体で再利用できる可能性は.比較的高い .

UNIX 環境は，多数のツール・フラグメントを用意し，それらを鉱張し.相互に組み合わせるための手段を提供するという形で.この点の改普にカを注いでいる.

ここでの問題点は.分解の単位，ツール・フラグメントの汎用性および機能性，ツール・フラグメント集合の摘成管理のメカニズム.新規ツールの開発に関連して再利用できるツール・フラグメントの識別を可能にするようなぞれらの記述法 ， などに関連している.このことは，単にツールの徳能分解のみならず，環境開発にさいして高度の再利用伎をどうやって達成・支媛するか，あるいは，さまざまな環境開発アプローチを意味のある形で支怨するにはどうした ら よいかという.一般的な問題をも含んでいる.

‑
9
‑

l
.lN
o.9
SeamaUVorMISEEnvironmentWorkshop(2) ツール・フラグメント，ツ ー ル.およびツ ー ル集合聞のインタフェイス

ツール

フラグメント.ツール.およびツール集合をうまくまとめあげるためには.インタフェイスに関する取り決めが必要になる.また.いくつかの環境(たとえば開発用環境と保守用環境)を一緒に使うためには，それらの環浅間で成果物のインタフェイスに関する取り決めが必要になる.この取り決めは，やりとりされる

データの構造を決定するものである.また，情報交換の方法(たとえば.パラメー夕方式かメッセージ交換か，など)を確立し，ツール

フラグメント.ツール.ツール集合，および環境の聞の一般的な時間制御の涜れ(たとえば.起動順序の制御か，非同期的なメッセージ・フローか，など)を決定するものである.

(3) どのような自動化ツ ール を設計工程以前の作業に提供すべきか

現在のツールの大部分は.ソフトウェア・ライフサイクルの下流工程を支媛するものである.その中で，いくつかのツールは要求定義や設計用に拡張されており，また，これらの上涜工程を支媛する新しいツールも開発されつつある.しかし.要求定義や設計工程において.具体化工程で現在行われているのと同程度の支媛を提供するためには.より一層の :労力が必要である.それには ，もちろん.既存のツールをどのようにして変更

または鉱張すればよいかが.検討される必要があるだろう.また，さまざまなソフトウヱア ・ プロセス・パラ

ダイムのもとで，どのような自動化支媛が上涜工程において最も効果的であるかも，十分考えられなければならない.さらに，既存ツールの鉱狭や新規ツールの情築とは無関係に.われわれは.上流工程における問題を解決する上で役立つようなソフトウェア抽象化技法を開発し，そうした技法に対する自動化支媛の基礎を確立
し，ツール集合の高度な統 一位が達 成できるように.努力する必要がある.

(4) 他のツールや環境の楊築支 J~ にはどんなツ ー ルやアプローチが必要か

ツールや環境の構築を支 t~ するために，これまで.数多くの技術(たとえばパーサ-ジェネレータ，宣言型

記述の利用，階層型アーキテクチャなど)が開発されてきた.しかし，より一層の支緩が必要である.パーサ・ ジェネレータなど，現存するいくつかの機能は.鉱張して他のツールの f構築に利用することができる.しかし.環境の構築・進化に関する新しいパラダイムの出現とともに，より高度なツール構築支媛機能が必要になってくるであろう .

(5) ツ ー ルおよび環境の費用対効果をどうやって決定するか

現在，ツールや環境が広 く 使われていない最大の陣害は，それらの利用効果が必要な費用を上回ることを，われわれがうまく説明できないでいることである.今後，より高度な新技術が開発されるにつれて，この問題はより深刻になるだろう.経験にもとづく説明は.もちろん重要である.しかし，費用対効果の算定をより明確に行なう方法が開発されなければならない.費用は，単純に経済的なものだけではない(たとえば，極端な習熟曲線を持つツールもある).したがって，経済的な要因も含めて，ツールや環境の導入にともなう「苦痛」と，それによってもたらされるさまざまな利益とが.正確に把握されなければならない .

効果対苦痛の定量的評価は.いくつかの要因が組み合わさった複雑なものになるだろう . たとえば.目的の応用分野やソフトウェア・プロセス・パラダイム，ユーザや管理者および組織の期待などが，いろいろな影響を与える.これらの要素はお互い複雑に関連しあい，要求や期待の高度化につれて変化する

また.すでに認識されたコミュニティ ・ ニ ー ズ(いわゆる Technology "Pull") に対し，どちらかといえば消極的な形でデモ

‑
1
0
‑

rMISEEnvironmentWorkshop

S
e
a
m
a
l
lV
o
l
.
2No.9

ンストレーションを行うのに加えて.技術を積極的に売り込む(いわゆる Technology "Push") ためにも効果

対苦痛の評価機能が必要になることで.この複雑さはさらに噌加する.したがって，定量的な尺度の開発は，それだけでは十分ではない.その評価機能は.本質的に定性的な要因も説明できるものでなければならない.
また.時間の経過とともに評価をより洗練されたものにするプロセスも，考えられなければならない .

3. 1. 2 活動項目

どのような活動項目が必要かを洗い出すにあたって，このワーキング・グループでは.現在利用可能なツールの機能を段階的に改善することに焦点を絞った.上に述べた基本的な問題点に関する進歩は，中期の目標と見なすしかないと考えられた.集中的な改善活動を開始する以前に，より多くの経験を蓄積する必要があるた
め，短期の活動項目によってもたらされる成果は少ない.

したがって.

5 年聞の短期目僚は ， 既存の自動!と支鑓ツールの改良に置かれる.

10 年間の中期目標は，支媛対象フ・ロジェクトの箆図を鉱大して，複車産・大規模・高信頼性 ・ 多パージョンのシステムを吸えるようにし，現実のプロセスをより適切に反映するようなパラダイムを支鑓できるようにすることである .

活動項目は，その結果としてもたらされるツールの種類にしたがって. 3 つのグループに分類できる.最初のグループには以下のものが入る:

テスト環境: !動的解析によってソフトウェア・システムの動作を分析するツールの集合.

バージョン管理:複 数パージョンのソフトウェア・システムを管理するツールの集合.

進化遺U:~よぴ調査型のプロトタイピング : 段階的なソフトウェア・システムの開発と要求定義確定のためのプロトタイビング支鍛ツールの集合 .

ツール楊集ツール:他のツールや環境の構築を支 t還するツールの集合.

復量言語による開発:ソフトウェア ・ システム中の異なる部分を異なる言語で開発するための支媛ツールの集合.

これらの作業を支撮する自動化ツールで，かなりの機能を持つものが，すでに存在する . しかし.上にあげた短期活動項目は，それらのツール機能を改良し，使用評価の経験を積み，不足している機能に対する要求条
件を確定し，現状でどのツールがこれらの要求をどの程度満たしているかを確認するために，どうしても必要である.また.より広範囲なソフトウェア・システムに対する効果的に支媛を確立するための基礎でもある.

第 2 のグループに属する活動項目に関しては，短期の調査研究も可能であり.また有益であると考えられる .

しかし，実用的なツールなど，具体的な成果があらわれるには. 4 ないし 6 年の期間が必要だ思われる:
笑圏直翠プロトタイピング : いろいろな代答案に関する経町史的な調査を行うためのプロトタイピング支
援ツールの集合.

再利用性 :再利用可能なソフト ウェア部品の作成 ・ 管理・検索・収集を支媛するツールの集合.

仕緩解析:具体化以前の 記述を検査してソフトウェア・システムの特徴や佐賀の分析を支媛するツールの集合 .

ツールの統合化:ツ ー ル集合や環境の統一位を高めるためのツールや技法.

‑
1
1
‑

SeamaUV
o
l
.
lNo.9

rMISEEnvironmentWorkshop

集秩序への支疲:かなり無秩序な形で進められる自然なソフトウェア・プロセス・パラダイムを支援するツール群.

荻窪の計測と情報収集:ソフトウェア開発-進化の過程をモニタし評価する作業を支媛するツール群 .

最後のグループに属する活動項目は，方法論やコンビュータ・サイエンスの理論など.他の分野の発展を待たなければ，本格的な検討ができないようなものである.したがって，これらの活動項目は，今後約 8 ないし

10 年は中心的なものにはならないと思われる:
抽象化支援:特にソフトウェア・システムの要求定援と設計における.抽象的記述の作成と解析を支媛する技法と関連ツール.

信額性評価符に高い信頼性を要求されるソフトウェア・システムの開発や進化を支 f憂する技法とツール群.

変換ツール:さまざまな関係者からの相異なる要求に対応して，開発あるいは進化途上のソフトウェア.システムに対する異なる視点からの記述を提供するツール欝.

方法諭ドライパ:特定のソフトウェア・プロセス・パラダイムの使用を積極的に奨励あるいは強制する
自動化ツール群 .

3. 1. 3 優先順位とタイミング

活動項目のグループ化によってある程度の優先順位は定まっている.ワーキング・グループでは.さらに一歩進んで，各グループ内の活動項目の優先順位を定めた.その結果を図 3 に示す.ここでは.各活動項目を，
それらがどのタイミングで最も効果的に実行できるかを大まかに評価した結果にもとづいて，優先順位および実行可能性の順序に並べてある.
'AnynmM23(e) ツール f構築ツール(e) 進化型プロトタイピング

短期的実現可能性減少(i ， e) テスト環境(i ， e) 探索型プロトタイピング(e) パージョン管理(e) 複数言語開発(i) 再利用性(i) 仕様解析(i) 実験型プロトタイピング(i) ツール結合(i) 無秩序への支媛(i) 状態の計測と情報収集

優先度減少

EA-nw'nu，、Jd噌(i) 方法論ドライブ(i) 抽象化支懐(i) 信頼性評価(i) 変換ツ ー ル

優先度減少

凡例

e- 現在の技術を鉱張することで実現する

i 一基本的問題として研究を行う

国3

ツール分野における活動の優先順位とタイミング

‑
1
2
‑

rMISEEnvironmentWorkshop

S
e
a
m
a
l
lV
o
l
.
lNo.9

3.2 分散化

このグループでは.ソフトウェア環境の分散化を議論するにあたって，関連項目を次の 3 つに分類した:

分散システムの開発・進化を支 t遣する環境磁能の提供

環境機能自体の(論理的または物理的)分散化の実現とその支援(論理的または物理的に) 分 散化された環境を用いて分散システムを構築するさいに，ホストと環境機
能をどのように組み合わせるべきかについての問題

時間的な制約のため，ここでは . 2 番目の話題に絞って討論が行われた.したがって.以下に述べる問題点
および活動項目は，環境を 1 つの分散システムとして論理的に認識する方法.および.分散型のホストをソフ
トウェア環境に利用する方法に 関す るものである .

3.2.1 問題点

(1) ワークステーションのネヴトワーク

1990 年代における環 i克の多くは.ワークステーションにもとづくものになる.ここでの主な問題点は.
卓上型のコンビュ ー タ資源を用い て 複数メンバ の プロジェクトを支鑓することである.そのさい配慮すべき重要 なことがらは，チームの大 き さ で ある . 6 人. 60 人 . 600 人のチームに対して.それぞれ，ワークステー ションにもとづく開発を支媛 する ことができるだろうか . また ， 関連する問題点として . ワークステーショ

ンの特殊化と専用環境の派生とい う ことがある.ワークステーション群(または複数のワークステーション集合)によって提供されるハードウェアおよびソフトウェア環境は ， ソフトウェア ・ プロセス内の特定の役割にあわせてカスタマイズされ るべ き で あろうか .

(2) 異根種間ネヲトワ ー クの支媛

個々のワークステーションを特定の目的に利用し，それぞれの専用環境を構築して行こうとすると，どうしても異纏種間ネ ッ トワ ー クが必要になってくる . ここでの主な問題点は，メインフレームや特殊なプロセッサ .
および専用ワークステーショ ン か ら 成る雑多なハ ー ドウェアの集合を，どうやってネットワーク内で支媛するかである .

(3) 分散環境のア ー キテクチャ

論理的または物浬的に 契 機種コ ン ビュータ資源の集合から構成された環境には.基本的にどのような構造が適しているのだろうか.たと え ば，階層型アーキテクチャは，分散環境に適切であろうか . いろいろなアプロ
ー チを比較するには.アーキテク チ ャの適切伎を測るための評価基準を.分散という特性に則して定める必要がある . また，分散化 の 支 t~ は . 完 全性や拡張性 な ど，環境が持つ他の特性にも~響を与える . 分散化を支媛する活動にさいしては，これ ら の こ とがらも考慮しなければならない .

‑
1
3
‑

SeamaUV
o
l
.
2No.9

rMISEEnvlronmentWorkshop(4) 環境掻箆の分散資源への配 置

これは，環境の持つべき綴能を，分散された(おそらくは異織種の)ホストによって提供されるプロセッサに，どうやって割り当てるかという問題である . たとえば，環境は，ツールの起動に関して，分散型のプロセ

ス・スケジューリングを支 t還すべきだろうか.その場合，スケジューリングは.プロセスやユーザから可視的にすべきだろうか.また論理的なことがらも考慮して設計する必要がある.たとえば ， ユーザの役割などの基準にしたがって事前に機能割り当てを行なうべきか，あるいは与えられた機能に対するニーズにしたがって動的な割り当てを行なうべきか.それとも，両者の混合で行くべきか.など.

(5) 柔敏性

ここでの柔軟性とは，ソフトウェア開発プロセスの変化や環境を織成する分散資源の変化に対応して，分散環境を論理的に再清成する能力をいう.もう 1 つの注目すべき徳能は，それが論理的に分散裂であるかどうかにかかわらず

1 つの環境を集中型のホストから分散型のホストへ移行する機能である.ここで中心となる問

題点は，どの程度の柔軟性を支媛すべきかということ.および，そこでの分散化アプローチの役割およびメカ
ニズムである.

(6) 分散環境上に怠ける共同作業

分散環境の各構成要素聞の相互 調整 を行うには，どのような徳能が必要であろうか.環境ユーザ聞のコミュ
ニケーションに対しては，どのようなモデルや手法，メカニズムが最適なのだろうか.電子メイル，複数のユ

ー ザ聞の同期的コミュニケーショ ン (オンライン・ミーティング) . 共有オブジェクトの変更などが，その候補として考えられる.どのような種類のコミュニケーションが適切かは，待ち時間によっても影響される.したがって.

WAN 上の分散型環境は.

LAN だけを利用したそれとは必然的に異なった機能を持つことになる.

3.2.2 活動項目

分散環境に関する活動項目を検討するにあたって，このグループでは.次のような特徴を持つ分散環境のプ
ロトタイプを開発するプロジェクトを設定するのが.最も有用であると考えた:

電理的に分散したノード :そのプロトタイプは.

LAN だけでなく.

(UUCP や ARPA などの )W

AN 上に分散した環境も支撮する.

高度な再構成徳 c と適応性:そのプロトタイプは.下部精進としてのハードウェアのバラエティを支媛すると同様に ，さまざまなソフトウェア ・プ ロセスやプロジェクト組織を支鑓メカニズムを持つ.

以下にあげる 3 系列のプロ ジェク トが提案された:(1) 環境アーキテクチャの研究

分散環境アーキテクチャを研究 す るプロジェクトが明確にすべき項目としては，以下のものが考えられる:-環 境の機能および資源の分散

.
1
4
‑

rMISEEnvironmentWorkshop

SeamaUV
o
l
.
lNo.9

- 環境資源の再構成

ソフトウェア ・ プロセスの分散型支 I還のモデル.特定プロジェクトの分散型支 ti のモデル

(2) コミュニターション ・ モデルとメカニズムの研究

この分野のプロジェクトでは，ユーザ相互およびユーザと環境問における高度なコミュニケーションを可能にするモデルやメカニズムを研究すべきである .

(3) 柔放なアーキテクチャと高度なコミュ二ケ ー ションfIカを持つ環境震の構築と評価

ここでのプロジェクトは，上記 2 つの分散環境構築プロジェクトの流れにしたがった各種のアプローチを統合化するものであり，そうした評価は1 つの現実的なプロジヱクトを通じて行われるのがよい.

3.2.3 優先順位とタイミング

最初の 2 系列のプロジェクトが，第 3 系列のプロジェクトの前提として，まず実施されなければならない.

グループ討論のなかでは，最初の 2 系列のプロ ジ ェクトを並行的に進めることで5 年以内にかなりの成果が得られるものと考えられた.その 後 で ， それらの成果を統合して，柔軟なアーキテクチャを持ち，高度なコミュニケーション能力を持つ環境群を作り出すことが可能になる.

3.3 データペース支屡

最近まで.データペース支 I創立 ， ソフトウエア環境がいったん構築された後の追加機能程度に扱われてきた.

したがって，この分野における改善活動の目僚は，データペース支媛が，ソフトウェア環境開発の中心的な課

題として考えられるようにすることである.この分野におけるプロジェクトでは.対象とする問題，問題領域，
解決法，ソフトウェア・プロセス，プロジェクトの資源や思歴.開発組織など，非常に幅広い範囲の情報に関する格納・管理・アクセスを支緩する機能が開発されなければならない.
3.3.1 問題点

(1) 適切なデータ・モデル

データペース支媛の提供にさいして，まず第 1 に重要なのは，ソフトウエア環境において使用すべき適切なデータ ・ モデルが何かをはっきりさせることである . 関係型データ ・ モデルなど，現在の多くのデータ ・ モデ
ルは，エンティティの種類が比較的少なく，これらのエンティティに対するインスタンスが多い場合に，最も有用である.こうした条件は . MIS や ADP の分野では十分に成立し，したがって，既存のデータ・モデルが活用されている.一方 ， ソフトウェア環境におけるデータは，エンティティの種類が多く，各エンティティに対するインスタンスの数は1 ないし数個の場合もあれば，多数の場合もあって.さまざまである.したがって，全体的に見て.既存のデ ー タ・モデルは，ソフトウェア環境にとっては十分ではない .

データ・モデルに関する一般的 な 問題点は ， 以下の通りである.もちろん，これらは相互に関連している:

‑
1
5
‑

SeamaUV
o
l
.
lNo.9

rMISEEnvlronmentWorkshop
CAD/CAM とソフトウェア環境の類似 点{相違点

CAD/CAM 環境は.ソフトウェア開発環境

よりもかなり進んでいる.これらの環境は.多くの場合，特殊なデータペース支緩機能を持っている.はたして . CAD/CAM 環境のデータベース・モデルは，ソフトウェア環境でも有効に利用できるだろうか.
汎周データモデル : 関係データ・モデルは. MIS や ADP に対しては.よい汎用データ・モデルである.ソフトウェア環境に適した汎用データ ・モデ ルは存在するのだろうか.ソフトウェア環境固有の要求に合うように.既存の汎用モデルを拡張・制限・変更することができるだろうか.

多援なユーザ『視点』の支箆:ユーザが異なれば，環境に保存されているデータに対する見方も異なってくる.これらの視点は.マネジャ，アナリスト ， プログラマ.保守要員など.ユーザの役割に依存している.環境ユ ー ザ全体を支慢するためには，どのような概念データ・モデルが必要であろうか.

概念モデルと具体化モデル :概念データ・モデルは.具体化のさいに使用される下部のデータ ・モデルとは異なるであろう . 概念モデルと具体化モデルの模本的な相違点.類似点，相互関係はどうなっているのだろうか.

複量産さ:ソフトウェア環境の支 tl に必要なデータは非常に複雑である.大きさが異なる数多くのオブジ
ェクトが存在し.これらの悶の関係も複雑である.ほとんど変化しない永続的な性質を持っていると考えてよいものもあれば，たびたび変化し動的に取り級うべきものもある.データ処理内容の複鎗さも大きく異なっていて.しかも，これらの異なった処理を行うツールが.すべて同ーの論理データペースをアクセ
スしなければならない.このような極織な複雄さをうまく処理するには.どんな汎用メカニズムやアプローチが有効だろうか.ツールの統合化とデータベ ー スの統合化の関係はどうなっていて，どうすればこの2 つの問題を同時に解決できるのだろうか .

制約メカニズム: 多くのユーザが異なる視点からデータにアクセスするため，データの一貫性や完全性が失われる可能性がある.これは ， 分散型環境では特にむずかしい問題になる.データの一貫性や完全牲を保つためには，適切な制約 条件 と，デーモンやトリガなど，関連するメカニズムを開発する必要がある.

(2) データペース支媛の役割

もう一つの重要なことがらは，ソフトウェア環境内におけるデータベース支援の役割である . データペースと他の環境線能とを論理的に 統合 [じすることが， 重要な課題であ る.強い統合化を行うには ，ソフトウェア・

プロセスを制約し，同時にまたプロセスによって制約されるような.何らかの新しい技術が必要になる.弱い
統合化の場合には，多少とも煤準的なデータベース技術が利用できるが . 支 t震できる機能はその分だけ小さくなる . その他の問題点としては.次のようなものがある:どのように情報を分解すべきか，どんな情報を獲得
し管理すべきか，分解の大きさはどの程度が妥当か，ツールや環境問の情報交換を容易にするにはどんな情報構造やインタフェイスが最適か.

(3) その他の問題点

その他.特にソフトウェア環境に固有とはいえないような問題点も，いくつか取り上げられた.データ管理の作業を.ソフトウェア環境から分権することはむずかしい . 論理的に集中化されたデータと個々のユーザデータの悶には，一般的な組織のデータとプロジェクト特有のデータの聞と問機に，ある穫の競合関係が存在す
る . また.性能や.ハ ー ドウェア支緩.惚密保護，安全性などの問題も.考慮しなければならない .

これらの問題点を明確にする上での 1 つの大きな陣容は，われわれ自身に . ソフトウェア環境上で本格的なデータペース支援を試みた経験がないことである.データ ・ モデルのプロトタイピングや，核となるデータ・

‑
1
6
‑

rMISEEnv
1ronmentWorkshop

SeamaUVol.lN
o.9

操作・制約条件の識別に関しては，ほとんどガイドラインらしきものが存在しない.

3.3 . 2 活動項目

ソフトウェア環境におけるデータペース支援機能を強化するための活動は，分散化および集中化という 2 つの方法で，同時に試行する必要がある.ここでいう分散化と集中化は，概念データ ・ モデルに関するそれである .実際 に具体化された形態は，どちらの場合も.もとのモデルとはかなり異なってくる.

分散化および集中化の双方のアプローチによって試行しうるプロジェクトの案をいくつか示しておく:

一貫性の維持や並列制御などのデータペース機能を支媛するツールの開発.
データペース機能のソフトウェア環境への統合化.

ソフトウェア環境に適したデータ・モデルと，それを支媛するデータベース徳能の開発 .
複数の視点をユーザに提供する徳能の開発.
デタ・モデルの統合化.

ソフトウェア環境で利用するための汎用データペース・ツールのカストマイズと，結果の環境への統合.

3.3.3 優先順位左タイミング(1) 短期目標

今後 5 年間に有用な研究開発成 J裂をもたらしそうな活動項目を以下に示す :ソフトウェア環 II 向けのデ ー タベース・ツールの開発.

データペース・ツールのソフトウェア環境への統合化.
ソフトウェア環境のための単純なデータ ・ モデルの開発.

(2) 長期日銀

かなり大規模な研究が必要であり，したがって 1 995 年以前には有用な成果が得られそうにないとおもわれるものを以下に示す :ユーザに対する複数視 点、の支 短より複雑なデ ー タ・モデルの開発
データ・モデルの統合化

データペ ー ス ・ツールの 特殊化または統合化

3.4 鉱張性

要求や技術の変化に対して，環 I克やその構成要素を適応させることは.必要不可欠である .また ，そうした適応性によって，いくつかの潜在的なメリットがもたらされる . その第 1 は，新しいツールをーから作るのではなく，既存のツールや環境の大部分が再利用できることである . 環境の適応性が高ければ，将来要求や技術

‑
1
7
‑

SeamaUV
o
l
.
2No.9

rMISEEnvlronmentWorkshopの変化があっても.投資効果が無駄にならないことが保証され，それによって，多額の初期投資が可能になる.

さまざまな変化の源泉が，相異なる適応性要求をもたらす.図 4([Keen[80] から抜粋)に示すように.変化には 3 つの大きな領主義がある.

ツールや環境のユーザの側における要求の変化.たとえば，リアルタイム・システム分野への移行など.
ホスト・システムの能力の変化.たとえば，新しいハードウェアの出現など.

環境およびツールの檎築者が利用できる技術の変化.たとえば，新しいパージョンのツールの出現など .

ユーザ

環境

(ホスト)
図 4

変化の領緩

この図は，ある領域における変化が，他の領域で 2 次的な変化を引き起こす可能性があることを示している
たとえば，ユーサ'の要求の変化によって，新しいより高性能のホスト・システムが必要になる.さらに，その次には.環境を構築するために.より高度な技術を開発し利用することが必要になってくる.

ホスト・システムの変更に適応する能力は，ふつう，移益性と呼ばれており

1 つの環境を何種類かのホス

ト・システム上で利用する必要がある場合.基本的に重要な特性である.すべての問題が解決されてはいない
が，移植性を向上させるためのいろいろなメカニズムやシステム・アーキテクチャは実用化されている.

ユーザや環境構築者の側におりる変化に適応するための能力の開発は.ずっと遅れている.これらの変化によって必要となる修正が.それほど大きなものでなく.比較的ちいきな改良である場合は.適応性は比較的容易に達成できる.カスタム化 u濃度やツールの応答をユーザ特有のスタイルに修正する)は，その 1 つの例
である.別な例としては，チューニング(環境やツールの信頼性 ・ 性能・堅牢性などを改良する)がある .
カスタム化やチューニングの能力を処理し強化するためのメカニズムやアーキテクチャは，これまでいくつか開発されてきたが，機能的に十分成熟しているとはいえない.

環境やツール徳能に大きな変更をもたらすような.ユーザや環境構築者側の変化に対する適応性，すなわち鉱張佐は，適応性の諸側面の中で，もっともわれわれの理解が遅れている部分である.この種の変更は.開発
または進化の過程にあるソフトウェアに対して，何らかの新しい.これまでとはちがった視点が必要になることによって生じる(たとえば ，プロジェクト要員の交代.要員の役割の変更.組織変更.業務内容の変化など

が，その原因である).また.新しいユーザの活動を支援するために，あるいは，開発上 のまったく新しいパ

ラダイムを支媛するために，新しい機能を提供する必要が生じ，それによって変更が行われることもある.録後に，新しい高度な技術を用いて環境やツールの機能を作り出すために，変更が必要になることもある.

‑
1
8
‑

SeamaUV
o
l
.
2No.9

rMISEEnvlronmentWorkshop

3.4.1 問題点

上に述べたすべての種類の適応性を支媛できるようになるまでには.かなりの技術進歩を待たなければならない.現在 ， 最も要求が大きいのは，環境やツールの鉱張性である.拡張性に関する一般の関心やニ ー ズの高まりは，それを支援するための技 術 が，移布直性 . fJ スタム化，チューニングなどと比較して，未成黙なためであろう . また.さらに重要なことは，この種の適応性を改善することの見返りがきわめて大きいことである .
したがって ， 以下に定義する問題点は，環境およびツールの砿張性強化を中心としたものになっている.

(1) 拡張性を強化するようなアーキテクチャとその特徴ほ何か

移植性を高める伝統的な方法は ， 階層型の ア ーキテクチ ャ を用いて ， 機械依存部分を最下層のカ ー ネル内部に局所化することである . 他の階層でも，それ ぞ れ密接に関連しあう要素やフラグメントのカプセル化が行われている.これにより.変更の箆図や膨響を局所化できるため，構成要素の交換がやりやすくなり，その結果 ，拡張性が改善される . たとえば，いくつかの環境は情報管理のための階層を持っており ， その基礎を構成しているデータベ ー ス管理システムを 変 更しでも，システムの他の部分へ混乱をもたらすことはない .
重要な問題点の第 1 は ，

ここで最もどんな階層構造が最も適切かということであり，第 2 は，階層型アーキテクチャに付随するトラブルを解消し，しかも，システムの 拡 張性を同程度に保てるやり方が他にあるかということである.

(1) 基本的な環境やツール要素はどうすれば再利用できるか

環境やツールの強化に必要な労力は ， 主な部品が再利用できれば，いちじるしく軽減される .

また ， 環境アーキテクチャを変更する必要がなければ . やはり，かなりの労力削減になる . 基本的に必要なのは，新しい状
況下でもそのまま利用できるような.十分に汎用的な部品(またはツール全体 ， あるいは環境)を持つことである.たとえば ， 基本設計や詳細設計の評価にさいして，もしスタティク・プログラム ・ アナライザが再利用できれば，それは明らかに望ましいことだが，そのためには，スタティク ・ プログラム・アナライザを定義し具体化する時点で，かなりの先見の明が必要になる . その他に必要な項目としては，再利用可能な部品を識別しカプセル化する技術 ， 部品の利用可能性を判定し部品格納庫から検察できるようにそれを記述するスキーマ ，
既存の部品や新しく作った部品を用いてツールや環境を構築する作業を支媛するためのツ ー ル ， などがある.

(3) ツール集合を相対的に重量立に保つにはどうするか

階層型のアーキテクチャは，仮想線級と具体化のための境界緩を独立に保っている.しかし . これらの境界

銀は ， ツールの具体化にさいしては.必ずしも適切なものではない . 個々のツールやツール集合が ， この境界をクロスするといったことも，ときには起こりうる.ツール機能のカプセル化が.環境機能のカプセル化と矛盾する場合もありうる.

ツール機能のカプセル化によって得られる交倹可能性は，個々のツールやツール集合を相対的に分隠することによって，より強化される.単純なアプロ ー チは ， ツール閉またはツール集合聞のデータ交換インタフェイ
スを定援することである.しかし，かなり洗練された定義徳能があったとしても，単に同一機能のツルを交娩できるだけであり.したがって十分とはいえない . その他に必要な項目としては ， ツールやツール 集 合を適
切に抽象化した集合，動的交線を支 t援するツール，環境の使い勝手.や環境の支損するソフトウェア ・ プロセスをほとんど(あるいはまったく)績なうことなしに，ツールの交換を行う方法論，などがある.

‑
1
9
‑

SeamanV
o
l
.
2No.9

rMISEEnvironmentWorkshop(4) ユーザを混乱から蓋査するにほどうしたらよいか

現在の環境は，ほとんどがコマンド形式のインタフェイスを用いており.環境の詳細が，ツ ー ルの集合として外部から見えてしまう.個々のツールはユーザの自に見え，その結果，ツール部品の変更も自に見えるようになっている . ある意味で破れかぶれである.こうした 事 慾を避ける方法に，オブジェクト指向インタフェイ
スがある.この型のインタフェイスでは.ユーザは，環境との対話を ， ツールの名前ではなく ， オブジェクトの名前で考える.この方法によれば.環境内部の詳細なツール構成を外部の目から隠すことができ，ユーザ ・レベルの操作は自動的にツール の 起動へ変換で き る.こうした高度なカプセル化は.ツール部品の変更などによって生じる不必要な混乱から，ユーザを守る働きをする.特に高い優先度を持つ活動ではないが，オブジェ
クト指向インタフェイスをはじめとするユーザ遮蔽のためのアプローチを研究することは.鉱張性の問題に，
完全かつ効果的な回答をもたら す ためには，ど う しても必要である .

(5) どうやってヱーザ・インタフェイスを拡張可箆にするか

ここまでに述べてきた項目は，ユーザ・インタフェイスの拡張という，より一般的な問題の一部である.鉱猿可能な記述法や仕婚けを提供することにより.ユーザ自身が環境を自分の要求やスタイルに合うように.カスタム化できるようになっているのが望ましい.また ， インタフェイス自身.対話のメディアが変わっても(たとえば ， メニューにもとづくのインタフェイスからアイコンにもとづくのインタフェイスへ) .その余波が環境自体へ及ばないような形になっていなければならない.

(6) ツールやツール集合の変更を迅速にするための支掻虫歯E とはなにか

コンパイラ技術は.コンパイルされる言語やターゲット・マシンが変わっても.コンパイラの実際の具体化を大幅に変更しないでもすむような支媛機能を提供している.この支 t翼線能の中心的要素は，命令裂記述とは対照的な宣言型記述(テープルなど)である(命令型の記述では.記述情報はコードに埋め込まれ.その中に分散されている) . もう l つの鍵は，宣言型の記述を読み込んでコンパイラの一部または全部を自動的に生成するジェネレータである . これらの機能は.他の種類のツール周にも ， 開発される必要がある . さらに，鉱張性のもたらす利益を広い範囲で引き出すためには ， プロセス中の個々の活動に対してではなく，ソフトウェア
・ プロセス自身に対する宣 言 的 な 記述を目指す必要がある.

3.4.2 活重量項目

一般的な適応性，特にそのうちでも鉱張位を強化するための活動項目を淡い出すにあたって，このグループ

では.

1985 年の状況から 1995 年への発展は，重要な新機能の追加によるものではなく，現在利用できる機能の拡大によってもたらされると考えた.それには ， ソフトウェア ・ プロセス ・ パラダイムに対する自動化支媛の拡大.呉儀種分散型ホスト・システムのより日徴的な活用 . 環境ユーザ聞でさまざまなオブジェクト(コードやドキュメント)を共 有 する機能，個 々 の活動を支鑓するより汎用的なツール，などが含まれている .

したがって ， グループ討 論 では，今後 1 0 年間にわたって，環境の段階的な手直しを支媛する機能に焦点を当て，特定の活動項目ではなく，いくつかの関心のレベルを明確にすることに力を注いだ.また.これらの各レベルにおける改善のための一般的な「グームプラン J を明確にした .

‑
2
0
‑

SeamanV
o
l
.
2No.9

rMISEEnvironmentWorkshop

関心のレベルは，ユーザや環境情築者，ホスト・システムなどの領域でもたらされる変化の「範囲」と，密接な関連を持っている.こうした変化の範囲は.環境の基本郷造(アーキテクチャ)をどの程度まで考えなおす必要があるかということと，大まかに対応している.関心のレベルが高いことは.環境の基本的な構造や設計が変更される可能性が大きいことを意、味している.

最も高いレベルは，環境が支 t~ すべきソフトウェア製品やソフトウェア・プロセスに対する視点に関連している.このレベルにおける変化は，ユーザ領域に由来するものであり，プロジェクト・チームの変更，組織上の変更，最終あるいは中間成果物の変更，対象応用分野の一般的なまたは特定の性質の変更，対象応用システ
ムの「 ・・性」に対する要求の変更，などにもとづいて発生する.これらの変化は，環境機能の大幅な手直しにつながり，したがって，環境アーキテクチャの再構成をもたらす可能性が，非常に大きい.

次のレベルは，環境によって支媛されるソフトウェア・プロセス・パラダイムに関連している.このレベルにおける関心は.何人かの人聞のグループ(プロジェクト・チーム)が実行する活動や，それらの優先度や実行順序に置かれている.このレベルでの変化は，やはりユーザ領滅に由来しており.環境全体に対する手直しに結びつきやすい.しかし，そ うし た変更は.

1 つあるいは少数のツールの集合に局所化することができ，環境アーキテクチャ全体に混乱をもたらすことは，まずありえない.

次のレベルにおける関心の焦点は.個々のプロジェクト・メンバが行なうべき業務を反映する個々の活動である.変化を吸収するために必要な環境の手直しは.ふつう.

1 つのツール(たかだか 1 組のツール集合)に局所化できる .

その次のレベルは.環 I克禍築者の領織での技術の変化に関連している.その変化が.

(エキスパート・シス

テム技術の利用などのように)まったく新しい基本技術に関するものであるならば，それにともなう手直しは環境全体に及ぶものになり.新しい環境アーキテクチャが必要となる.しかし，一般的には，その種の変化が起こる可能性は少なく，特に今後 1 0 年間のソフトウェア環境技術に関しては.そうした大きな衝撃的変化は起こりそうにない.またその変化が.環境の構造化や構築に関するまったく新しいアプローチをもたらすものであるならば，手直しの範囲も全体的なものになる.しかし.この種の変化も.一般的にも特定の場合でも，
今後 1 0 年の聞には.あまり起こりそうもない .11 も可能性の高い技術的変化は.ソフトウェア・プロセス内の特定の作業で使われる技法や，ツールの具体化技術に関するものであり，したがって.それにもとづく環境の手直しは，特定のツールに局所化することが容易である.

最後に，最下位のレベルは.ホスト・システムの領域における変化に由来するものである.そうした変化の例としては，環境の具体化言語 の変 更，ホスト・システムの os の変更，ハードウェア-アーキテクテャの変更などがある.この種の変化に対応する環境の手直しは.変化を吸収するために，さまざまな既存の(または新)技術を利用しさえすれば，環境の基本的な f荷造に彫響することはありえない.

以上のすべてのレベルにおいて，環境改善のためのいろいろな活動が必要である.あるレベルの変化は，それより下位のレベルに影響を及ぼす.たとえば，新しい応用分野への移行は，開発パラダイムに変更をもたらし.実行すべき作業を変化させる.したがって，活動項目は.いくつかのレベルにまたがるのがふつうである.

3.4.3 優先順位とタイミング

‑
2
1
‑

,
SeamaﾟV
o
l
.
2No.9

rMISEEnvironmentWorkshop

一般的には，最下位の 2 レベルの作業は優先順位が低いと考えられる.これらの 2 つのレベルにおける変化に適応するための技術は.すでにかなりの程度整備されており，今後起こりうるであろう避けがたい変化に対応するには ， 既存の技術を発展 ・ 鉱張するだけ で 十分である.

しかし.最上位の 3 レベルにおける拡張性に関しては ， 基本的な問題点に対する調査研究と新しいアプロー

チや技術の開発が必要である . 既 存 の技術の進{じだけでは不十分であり，きわめて重要な意味をもっこれらのレベルでの鉱張佐の問題に対して ， 直接的かつ 集 中的に注意を向けて行く必要がある.

最上位の 3 レベルにおける鉱張位は . 今後 5 年間に.まず.小規模な短期的実験を行って.問題についての理解を深め.いくつかの解決ア プ ローチに関する経験を積むことにより，かなり改善することができょう.実験対象として取り上げるべき一般的アプローチには，いくつかの鉱張性支鑓メカニズムの設定.それらのメカ

ニズムのために有用なツールの 部 分集合の識別 (PD L ツールなど) .関連するいくつかのレベルでの変化に対応して既存のツールをどのよ う に変更すればよいかの実験 ， 鉱張性支援メカニズムを組み込んだツールの構
築 ， それらのメカニズムによる 以 演の徳能鉱張，などがある.

こうした短期間の実験に続い て ，そこで得られた経験を整理し一般化するための活動を行うべきである . こ

れらの中期的活動項目としては，いくつかの短期的実験結果の総合評価，鉱張性支媛メカニズムの一般化.

5

つの関心レベルにおける適応性・鉱張性に対するニーズの完全な理解 ， 複数レベルにまたがる変化に対応できる新しい汎用メカニズムの適用 笑 験.などがある.これらの活動にあたっては，特定のレベルにおける変更ニーズを適切に処理するためには.複数のメカニズムを並列に用いる必要があるという事実を，十分に考慮しなければならない .

3.5 人工知箆

AIは，半自動的な問題解 決の ために有用な技術を.数多く生み出してきた . これらの技術は，たとえば，
知識表現，推論，自然言語コミュニケーション，計画立案，設計，認知モデルなど，いろいろなことを支媛してくれる.これらの技術によってもたらされる支銭に特徴的な傾向は，ソフトウェア環境の内部に，プロセス特有の問題解決知識を内蔵すること.また，ユ ー ザを細部の戦術的な仕事から解放して，より高度な戦略的問
題解決に専念させること，などである.この分野での活動項目は.
ウェア環境構築に取り込み ，A 1 技術およびその特徴的傾向を.ソフト

そ の 研究開発の最前線をより発展させることを目指すものである.

3.5.1 問題点

すでに述べたよ う に，現状に お ける最先端のソフトウェア環境技術は，直接的には.人工知能研究の成果をほとんどあるいはまったく反映していない .

しかし，数多くの間接的な寄与は受けている.近い将来においても，引続き間接的な成果利用が 主 '*になるであろう.いくらかの直接的な貢献が期待できないわけではないが ，
しかし ， 今後 1 0 年間に A 1 技術がどう発展し.その影響力がどの程度鉱大するかを.正確に予測することはむずかしい . 冒頭にあげた技術 のう ちで，今後.中期的にソフトウェア環境構築に対して.もっとも大きな影響を与える潜在的な可能性を持 っ ているのは ， 知識表現および設計支援の 2 つである.

「知識」を.ソフトウェア・ プ ロセスにおいて生成される成果物に関する情報と考えれば.知識表現の問題
は比較的単純であり，本質的には.

(伝統的な)デ ー タ構造化や体系化の問題に帰着させることができる.事

‑
2
2
‑

置置

SeamaUVol.2N
o.9

rMISEEnvironmentWorkshop

懲が複雑になるのは自然な形」では提供されないような情報を獲得したいと考えた場合である.たとえば，
要求分析時には重要ではないよ う に見えて，設計段階になって初めてその重要さがわかるようなデータを獲得
するにはどうすべきか，といった問題がある.

「知識」がソフトウェア・プロセス自身に関係する場合には，その情報を記号化し自動的に解釈するための問題がある . これまで，プロセスに関係する知 識 は.ソフトウェア ・ システムのコ ー ドの中に壕め込まれ ， 分
散されていた . ここでのむずかしい問題は ， この情報を手続き的にではなく宣言的に獲得し，ソフトウェア ­システムの基本的なコードを変 更す ることなしに，それらを変更し追加したいということである.

ソフトウェア環境に関連する知識表現において巌も重要な問題点は.成果物についての情報をコンビュータの支鑓によって獲得する方法，および.ソフトウェア工学のいろいろな領域に対して，プロセスに関する情報をコンビュータが解釈できる形で記号化することである . ここでいう領域には.各種応用分野や ， 特定の問題，
設計戦略 ， 具体化技術などが含まれる.

設計支鑓とは，

A 1 分野で開 発 された技術やアプローチを利用し，プログラミング言語による具体化に先立って，ソフトウェア-システムの大まかな論理および構造を開発することを意味する.ここでは，な問題点がある.

2 つの大き1 つは，どうやってソフトウェア設計プロセスをモデル化するかということであり，もう 1

つは.どうやって設計履歴を格納し整理するかである.これらの項目は.ソフトウェア設計プロセスの支援にとっても.また，設計関連情報を以降の工程で役に立つ形で獲得するという意味でも.きわめて重要である .

3.5.2 活動項目

グループ討論では，知識表現および設計支援のための A 1 技術導入に関して，

3 つの活動系列が提案され，ソフトウェアの開発および進化を支媛するための A 1 技術の効果的な活用法が論じられた .

(1)エキスパート・システムによるソフトウェア工学実霞の支媛

エキスパート・システム技術が成功しそうな分野としては ， 構成管理およびパ ージ ョン管理.プロジェクト

計画立案，データ構造の選択.小規模なプログラム変換などがある.いずれにせよ，いくつかのプロジェクトで実際に適用して，どの点が不十分であるかを明確にし.どのような改善が必要かを指摘する必要がある.

(2) 設計モデル

A 1 技術を利用して，ソフトウェア設計モデルの研究開発を発展させて行くためには，次のような活動が必要である:

開発過程にまヨ lt る設計上の意志決定をインタラクティプに記録し，その記録を保守支掻に使用する.

設計プロセスの形式化:ここでの研究課題は，明らかにソフトウェア ・ プロセス・モデルの研究一般に彬響を与え，また逆にそこから影響を受ける .

設計の方法論および軍略の分析と表現 : この課題は ， 明らかに前の 2 っと関連しているが.しかし ，高度な能力を持つソフトウェア設計者の行動研究という形で，それらとは独立に進めることもできる.そ

‑
2
3
‑

SeamaUV
o
l
.
2No.9

rMISEEnvlronmentWorkshop

うした研究では.設計指標を明示的に設定しておくことが重要である.

(3) 知議表現

ソフトウェア環演構築に利用できるように.最先端の知識表現技術を発展させるためには，以下の活動が必要である:

要求情報の痩得 :これは重要な分野であり，かなりの研究を必要とす る.十分なケース・スタディを行わなければならない.また推論技術を開発して.要求に対する質問を可能にし，要求仕様作成や設計，コーディング中に答えが得られるようにする必要がある.最後に，解析技術(要求の一貫性検査など)も研究する必要がある .

形式的仕穣言語:この分野で最も重要な プロジェクトは，現実のシステムの形式仕織のケース ・スタデ
ィである.

プログラミング知義の表現:特定のプログラミング技法を表現する技術を開発すべきである.これらの表現に基づいて.小規模なプロジェクトを対象とした助言システムや自動合成システムが開発できる.

3.5.3 優先順位とタイミング(1) 短期

以下に，今後 5 年間で有用な成果が得られそうな研究開発の活動項目を列挙する:

現在実用化されているエキスパート・システム技術を用いて，現実のソフトウェア工学実践活動を支援
する.

開発過程における人間の設計意志決定をインタラクティプに記録し.それを保守支 f震に使用する.
形式的仕様言語.

プログラミング知識の表現 .

(2) 中耳目

設計方法論や設計戦略の分析と記述に関する研究は. 5 年から 1 0 年後にかけて有益な成果をもたらすであろう.

(3) 長期

まだかなりの調査研究を必要とし.

1995 年までには，ぞれほど衝撃的な成果が得られそうにないものとしては，以下のものがある:

設計プロセスの形式化
要求情報の獲得‑
2
4‑

SeamaUV
o
l
.
2No.9

rMISEEnv
1ronmentWorkshop

4. 横断的ワーキング・グループでの討論

横断的ワーキング・グループでは，すべての技術項目にまたがる話題について，討論を行った . そのため.

各グループは.全技術グル ー プから代表者を集める形で摘成された.いくつかのグループでは，問題点，活動項目，優先順位およびタイミングの明確化を行ったが.なかには，問題設定があいまいだったため.時間の大部分を問題自体の理解に 消 費してしまったところらあった.

4.1 統合化

統合化の本質は一貫性である.ソフトウェア環境に関していえば，統合化とは.環境の徳能，ユーザの目から見える構成要素，内部構成要素，その環境を用いて作られた製品などの間での一貫性に関する問題として.
とらえることができる.このグループでは，これ ら の問題の中から，次の 3 つに着目した.

まず第 1 は.外語的な統合化 で ある .

これは.ユーザの白から見て，環境が持っさまざまな機能の問に ， 外

見上の高い均一位が保たれていることを意味す る .外部的な統合化の単純な側面としては.ユーザ-インタフ
ェイスを介して各種機能を使う場 合 の一貫性や.ユーザに情報を表示する場合の一貫性などがある.情報表示の 一 貫性には，表示に使用 す るメディア(グラフィックやテキストなど)が含まれる.また，単に同種の情報を同じメディアで表示する(たと え ばツリー構 造 の情報はすべてグラフィックで表示する)だけでなく，同じ形態で表示する(たとえばツリ ーの 表示て'はル ー トを必ず画面の上端におく)必要がある.情報表示の一貫性
は，また，情報交燥に用い ら れる 言 語や開発対 象 のソフトウェア・システムを記述し理解するために用いられる抽象化のやり方にも関 係 しているたとえば.デバッグの結果は . プログラミング言語の文法に合わせた形でユーザに表示されるべきだし. 設計 やプログラミングにさいして用いられる抽象化は.逐次的なプロセス聞の情報交換という意味で ， ソフトウェアについての情報に関連している.

外部的な統合化は明らかに重要である.

r~ き最小化の原理 J を適用すれば.当面の開発(保守)作業で何が起こっているかについてのユ ー ザの思考を中断 さ せることなく.環境とユーザとの聞の情報交織が円滑に進行する .

第 2 は，周辺関係の統合化で あ る.これは，ソフトウェアの開発や進化を管絡する組織やマネジメントなど.

より広い範囲の周辺組織と ， 開発 環 境との間の 一 貫性を意味する.これもまた重要である . この一貫性が存在しなければ，環境のユーザは.周辺の(人間)組織で用いられていることばで表現された要求や行動を.環境
を用いて実行できる行動に 翻訳する という作業を.つねに強いられることになる .

3 番目は ， 環境の内部的な構成 要 素の一貫性を意味する内部的な統合化である . この型の統合化を正確に定義するためには.環境の内部構成 要 素の種類やその相互作用の形態を記述したモデルが必要になる.そうしたモデルを用いることによって.内 部 的な統合化を.さまぎまな種類の構成要素が相互作用における一貫性として，定義することができる . また.内部的な統 合 化は.
容 易にし.

(標準的な摘造を与えることを通じて)環境の設計を(相互作用のモ ー ドを 少 数に限定することによって)具体化を容易にし.

を単純化にすることによ っ て)鉱 張 を容易にする.

‑
2
5
‑

(環場の構成要素の交換

S
e
a
m
a
l
lV
o
l
.
2No.9

rMISEEnvlronmentWorkshop

4. 1. 1 問題点

統合化を行うためには，環境に対する認識を統一する必要がある.したがって.短期および中期にわたって第一義的に考えられるべきことは.高度の統合化を達成するための認識を開発することである.この一般的な目標から，いくつかの特殊な問題点が浮かび上がってくる.ただし，以下に上げる問題点は，主に外部的統合
化と内部的統合化を目指したものである.それらは周辺関係の統合化にも関係しているが，直接にはそのことに触れていない.

(1) ソフトウェア・システムの刻l 象化をどのように行えば.環境が提侯する穏健を銃ーできるか

ソフトウェア・システムの抽象化は.環境ユーザが，自分の考えを表現し.ソフトウェア・システムの性質に対する疑問を定式化し，解析結果を解釈してそれらの疑問を解決するための手段である.プログラミング言
語は，このような抽象化を実現したものであり.設計言語もまた同様である.問題は.ソフトウェア・プロセ

ス全体をカバーできるような抽象化技法(群)を選択することである.単一の普遍的な抽象化が理想的であるが，まず不可能である.したがって，われわれとしては.一貫した特性を持つ抽象化技法の集合を見つけ出し，各技法がそれぞれソフトウェア・プロセスのある部分に対して適切であり，すべてを合わせれば，ソフトウェ

ア・プロセス全体がカバーできるようにしなければならない.相異なるプロセス・パラダイムは，相異なる抽象化技法の集合を必要とするであろう.したがって.いろいろなパラダイムの相互関連を考慮して，拍象化技法の開発を進めなければならない.また，これら抽象化技法どうしの一貫性も確保しなければならない.ソフ
トウェア・プロセス中の異なる部分では抽象化のニーズが異なり，均質性を損ないやすい.構文上あるいは意味論上は無害なように見えるちがいが，全体の均質性を達成する上ではほとんど致命的な場合もある.

(2) 内部的な一貫性の達成を容易にする環境モデルとはどんなものか

一貫性を持った抽象化技法の適切な集合は，外部的な統合化を達成する助けになる.一方，内部的な統合化を達成するためには，適切な環境モデル(群)が開発されなければならない.一般に，そうしたモデルは，一連のオブジェクトのタイプと.それらのオブジェクト聞の相互作用を定義する.各モデルにおけるオブジェク
ト集合は，環境内の操作型オブジェクト(ツール)と情報型オブジェクト(データ項目)の両方を含んでいなければならない.したがって.特定のオブジェクトやその相互作用に関して，あらかじめ予備的なモデルが定義されると，いくつかの副次的な問題が生じてくる.すなわち.操作型オブジェクト聞の制御インタフェイスの定義や.操作型オブジェクトと情報型オブジェクト閣のアクセス・インタフェイスの定義，一般的なオブジ
ェクト間の構造的関係の定義，操作型オブジェクト聞の情報交換を支援する一時的な情報型オブジェクトの級
い，あるオブジェクトに複数の外見を与えて(何らかの時間的制約のもとで)他のオブジェクトと簡単に相互作用できるようにすること.などの問題である.こうした環境モデルは，たとえば環境構築費用を予測可能にするなど，いくつかの理由から重要な意味を持っているが，また，なんらかの判定基準を持ったモデルの概念
を関係者に植え付けるという観点からも，きわめて重要である.少なくとも，ちがった目的のために開発されたモデル間の相互関係を十分理解することが必要である.

(3) 高度の統合化と高度の適応性はどうすれば同時に達成できるか

統合化と適応性はお互い矛盾する関係にある . 統合化は環境構成要素閑に強い単一性を要求するし，適応性

は構成要素聞に分離性を要求する.しかし，両者は.同じ技術(環境モデル.一貫した抽象化.十分に定義さ

‑
2
6
‑

SeamanV
o
l
.
2No.9

rMISEEnvironmentWorkshop

れたインタフェイス.汎用ツール，ツール部品など)を使って達成される.ここでの問題点は，一貫した抽象化技法(群)および環境モデル(野)の適切な集合を開発することによって，環境の統合化を達成すると同時に.一般的な適応性や個々の特殊ケースに対する鉱張位を支 t還することが，はたして可能かどうかである.

(4) 統合化の尺度

統合化は， 0 か 1 かで測れる佐賀のものではない.少なくとも，相異なるアプローチを，その統合化の度合に関して比較できるような尺度が必要である.

一貫した抽象化技法の集合や環境モデルなどの考え方は.

1 つのオブジェクトに対して複数の視点を必要とする.したがって.統合化の程度を計量化するアプローチとしては，そうした異なる視点を提供する変換機能の個数を数えること，一連の変換惚能聞の相互関係の「整合性」を評価すること.ツルのちがいに対する変換徳能の透明度を評価すること，などが考えられる.しかし，ふつうは.これらの単純な尺度では不十分である.たとえば. UNIX のように，雑多なツール を寄せ集めて作ら れた環境では.変換機能の個数は.統合化の度合とは逆比例の関係にある.しかし. Inter Li sp のように，きわめて均質的な単一言語環境では.変換徳能の個数は，統合化の度合に比例する.さらに事怨を複雑にしているのは，統合化の種類が異なると，その尺度も異なってくることである.たとえば，外部的な統合化を評価する尺度は，内部的な統合化を評価する尺度とli.まったく異なる.
高度の統合化はつねに望ましいが.必ずしもそれは，つねに必要だというわけではなく，また.費用対効果がよいわけでもない.したがって，どの程度の統合化が必要なのかを.定量的に評価できなければならない.
そして，汎用の環境でも.特殊な環境でも.統合化を達成するさまざまなアプローチ(たとえば，既存のツー

ル集合にある変換徳能を付加すべきか.それとも，一貫した抽象化集合を与えるツールないしは何らかの環境モデルに適合したツールを構築するか)について.それらの費用対効果のトレードオフが計算できなければな
らない.

4.2 プロトタイピング

プロトタイピングとは，システムの未整なパージョンを用意することである.ふつう，プロトタイプは.シ

ステムの機能の一部分を正確に表現し実現するが，性能や人間工学的側面など，システムの品質属性を正確に反映するものではない.プロトタイビングは.目的や解決法を明確にすること(調査型プロトタイピング)
いくつかの解決アプローチを研究すること(実験型プロトタイピング)

うこと(進化型プロトタイピング).システムの開発や進化を繰り返し行.などを目的として使用される.

一般に，調査型および進化型のプロトタイビングは.ソフトウェア開発・進化の上涜工程を支怨するには，かなり有効である.ソフトウェア環境の場合.そうしたプロトタイピングは.環境が必要とする機能や，新しい環境の f構築に既存のツールが活用できる度合い.環境の基本的なアーキテクチャ構造，などを決定するさいの助けになる.

現在ポピュラーなソフトウェア開発アプローチのうち.全体の「ゲームプラン」としてプロトタイピングを用いているものは.ほとんどない(しかし，このことは.現実にはしばしば行なわれている)

タイピングは，以下にあげる理由から，ソフトウェア環境開発にさいして特に重要である.

‑
2
7
‑

.進化型プロ ト

SeamanV
o
l
.
2No.9

rMISEEnvrronmentWorkshop

環境開発は.多くの場合.まだだれも試していない技術の利用を含んだ開拓型の作業である.

環境の設計や構築に対する新しいアプローチの可能性を実証するには.しばしば続念を証明する J
ための仕婚けが必要である .

環境が実稼働される以前に，その具体化を完成させるのに十分な資源や時聞が得られることは，現実には稀である .

これと全く同じ理由で，進化型プロトタイビングは，段階的なアプローチによってソフトウェア環境構築のための最先端技術を発展させる上でも，きわめて重要である.

4.2.1 問題点

プロトタイピングと環境とを考えるにあたっては. 2 つの観点がある.第 1 は.ソフトウェア環境の中に，どのようなプロトタイビング支媛機能を盛り込む(ぺき)か，ということであり，そして第 2 は，ソフトウエ
ア環境構築技術の研究開発を発展させるには.プロトタイピングをどのように使えば有効か.ということである.

このグループで洗い出した問題点や活動項目は第 2 の観点に焦点を当てているが，討論は主として第 1 の観点からなされた.プロトタイピングを通じて最先端技術を発展させるには，特定の環境を進化させるより以上の能力を必要とし，また，環境開 発 に対するプロトタイビング支援には，一般のソフトウェア開発の場合と同じ機能を必要とするというのが，グループ参加者の基本的な感覚であった.プロトタイピングによる最先端技
術の高度化を特に重点的に考えれば，あるいは異なった問題点.異なった活動項目，異なったタイミングや優先順位が導き出されたかもしれない.しかし，ワーキング・グループには，そのための十分な時聞がなかった.

つまり，このグループは ， 環境開発に主要な関心を抱きつつ ， プロトタイビング技術一般について検討を行ったわけである . したがって，以下に列挙する問題点と活動項目は一般的な性格のものではあるが，これにもとづいて何か特定のプロジェクトを定義しようとする場合には，ここで想定されている成果物が環境そのものであるという点を考慮して，もう一度見直しをする必要があるだろう.

(1)ソフトウェアの開発や進化を支媛するのに.どうすればアロトタイプを掻も有効に使えるか

プロトタイプはシステムのモデルであり.その基本的な価値は.システムの佐賀に対する疑問に回答を与える手助けをするところにある.モデルに要求される正確性や，対象とするシステムの佐賀.使用される解析手法などのちがいに応じて，プロトタイピングには数多くの異なるアプローチが存在する.たとえば，特別に開発したモデルを用いたシミュレーションは 1 つのアプローチであり，手近な部品を再利用した「早くて維な J

具体化もまた 1 つのアプローチである.プロトタイピングにさいしては，まず最初に，明確にすべき問題点が何かをはっきりさせなければならない . その上で，各種の疑問に対する回答を得るのに最も適切なアプローチが定まるのである.

(2) 一連のプロトタイプで明確にすべき項目をどうやって語別するか

プロトタイピングを用いてシステムを開発して行く場合，中間的なプロトタイプ(審判を考えておく必要がある.それ(ら)は，最終的な成果物を生成するための踏み台でもあり，また.プロトタイプ(群)を用いて

‑
2
8
‑

.
.
SeamaUV
o
l
.
2No.9

rMISEEnvlronmentWorkshop

解決すべき問題をどうすれば最も論理的に整理できるか.ということにも関係している.一方で，開発者の側には，要求の変化や新妓術の登場に応じて最終目僚を変更できるように，柔軟性を雄持しておきたいという願望もある.プロトタイピングにもとづく段階的開発にさいしては.あらかじめ，何らかの方法によって，一連の意志決定事項を確認しておき，開発途中の任意の時点で.いま何が可能かの状勢判断にもとづいてそれらを整理しなおし，その結果としての意志決定の流れを支媛する中間的プロトタイプの仕織を考えることができなければならない.また，最終製品に対する要求の変化や新技術の出現に対応して.意志決定の涜れやプロトタ
イピングの順序を変更するための技術も必要である.

(3) 進化翠のプロトタイピングに有効な方法論とは何か

上にあげた問題点は.実は.プロトタイピングにもとづくソフトウェア ・ プロセス ・パラ ダイムにおける，

技術上および管理上の総合的問題点の一部分である.今日まで，ソフトウェア・システムの構築にプロトタイ
ピングを利用した経験や，開発や保守に関係する疑問に回答を見いだすためにプロトタイプを評価した経験は，あまり蓄積されていない(少なくとも記録されてはいない).また.進化型プロトタイピングのマネジメントについて，たとえば全体的な管理や資源の割り当て，進移管理，終了時期の判定などの経験も，ほとんど得られていない.そしてまた，プロトタイビングを他のソフトウェア・プロセス・パラダイムとどう組み合わせるかについても，それほど経験を積んではいない.たとえば.もし全面的にプロトタイピングを採用しようと思ったとしても，個々のプロトタイプは，旧来の「ウォーターフォール J アプローチで開発したりする場合がある.したがって，今後いっそう経験を積み，それにもとづいて.ソフトウェア・プロセスの指針となりうるよ

うな(技術上および管理上の)方法論を確立しなければならない.

(4) プロトタイピングの支媛にはどんなツールが必要か

プロトタイピングの方法論がよく理解できて，初めて，その方法論を支媛するツールを開発することが可能になる .

しかし，現実のソフトウェア・プロジェクトで，プロトタイピングがさかんに(おそらくアドホック

的に)行われるようになるまで待つ必要はない.実際問題として，プロトタイピング支媛の出現を不必要に遅らさないためには.方法論の探求と支援ツールの開発を並行して行なうべきである.れには，まず，いままでに作られたプロトタイピング支銭ツールを確認し，収集し. I盛理する必要がある.そうしたツールの数は少な
いので.さらに追加のツールを開発し，それらの使用経験を蓄積し.

3 種類のプロトタイピングをすべて有効に支媛するツール集合を作り上げて行くことが必要である.

(5) どんなソフトウェア・ア ーキ テクチャがプロトタイピングを支援するか

ソフトウェア・システムの基本情造あるいはアーキテクチャは，システムを高度化する際の簸易度に大きな~響を及ぼし.したがって，プロトタイピング・アプローチを実行するさいにも大きな彫響を与える.ここでの問題点は，プロトタイピング支婦のむずかしさがアーキテクチャによってどう変わるか，そして，どのアー
キテクチャが最も支媛性にすぐれ てい るか.ということである.

(6) プロトタイプの評価にはどの技法が忌も役立つか

すでに述べたように，プロトタイプは，開発途上のソフトウェア・システムに関する疑問に回答を与えるた

めの土台を提供するものである .

しかし，また，プロトタイピングの機能自体の進化を支鑓するためにも，プ

‑
2
9
‑

SeamaUV
o
l
.
2No.9

曲目SE E
nvlronmentWorkshop

ロトタイプを評価しなければならない.その両方の理由から.プロトタイプを使って解明すべき項目の理解や，モデル化の支媛，解析技法の開発などを進めなければならない.さらに.プロトタイプは，しばしば，技術者以外の人々によって.それぞれの立場からの疑問解明に利用されるので{たとえば要求確定時など) .そうした人々によるプロトタイプ評価を(人聞によって.あるいは半自動的に)支鑓するアプローチも開発しなければならない.

(7) 鉱張性とプロトタイピングはどんな相互作用を持っか

この 2 つの話題は，多くの問題点を共有している.適応化技術のどの部分がプロトタイピング支媛に役立つかを解明する必要がある.そして，適応性一般(その中でも特に鉱張佐)に関する最先端の技術開発に，どうすればプロトタイビングを効果的に利用できるかを解明しなければならない.特に重要な検討項目は，複数のソフトウェア・プロセス・パラダイムを交互に.または並列に支織するような環療を開発する場合.プロトタ
イピングと適応性とが，どのように相互作用するかということである.

(8) 人工知1It技術を使用してプロトタイピングを支録するにはどうするか

エキスパート・システム技術を利用したシステムの半自動生成は，プロトタイピングの支援にはきわめて有効であるように見える.疑問点は，いっそしてどんな形で，この技術を使うかである.さらに.プロトタイピ

ングは，今日の人工知能システムの開発にさいして，きわめて広箆聞に利用されてきた.われわれは，この経験をふまえ，そこでこれまでに作られてきた各種の支媛ツールを，ソフトウェア・システムの開発や進化に応用できるよう変更または鉱張して行かなければならない.

4.2.2 活動項目

今後 1 0 年聞に開発され る可能性のあるプロトタイピング支媛徳能に ついての討論が行われたが ，十分な時聞がなかったので.活動項目.タイミング.優先順位の決定には至らなかった.パーサ・ジェネレータ.属性

文法，第 4 世代言語，オブジェクト指向環境など.現在よく利用されているプロトタイピング支媛機能からさらに一歩進んで，宣言的記述をもっと広髄図に利用できるようにし，いくつかの重要な応用分野で現在活用されているような再利用支鑓機能を j準備し，未完成パージョンのソフトウェア・システムを用いたいろいろな実

験ができるようにしなければならないことが指摘された.

プロトタイピング・プロジェクトに関する指摘事項は.次の通りである:

すなわち，調査型および実験型のプロトタイピングにさいしては.まず第 1 に，ソフトウェア・システムの正確なモデル化を心がけ，次に，そのモデルを使ってシステムの特性解析や設計上のトレードオフ分析を行なうようにしなければならない.一方.進化型プロトタイビングでは.まず，プロトタイピング・パラダイムの厳密な定義を明らかにし，次に.
必要とされる機能を必要な時点で一貫性を保ちながら作りだして.開発費用を時間的に分散させるというこの新しいパラダイムの価値を明示しなければならない.

また，プロトタイピングの 3 種頒の用途は，それぞれソフトウェア・ライフサイクル中の長い過程をカバーできるが，それらの聞には.調査型プロトタイピングは実験型プロトタイピングの一部であり，実験型プロト
タイピングは進化型プロトタイピングの一部であるという，自然な包含関係が存在することが指摘された.この包含関係は，実験型フ・ロトタイピングは進化型プロトタイビングより単純であるという事実を反映したもの

‑
3
0
‑

S
e
a
m
a
l
lV
o
l
.
lNo.9

rMISEEnvlronmentWorkshop

であり，プロトタイピング機能を開発する順序と成果の達成が期待される程度を暗示している.

愚後に.どんなアプローチが適切であるかは，対象ソフトウェア・システムの種類によって異なること.また，特定の狭い範囲で定義された応用分野のプロトタイピング支媛機能を開発することは，一般的な問題を解決するより容易であることが指摘された.したがって.プロトタイピング徳能の改善にさいしては.まず最初にいくつかの特定の分野を支 t遣する徳能を開発してみるのがよいと恩われる . そこで得られた経験を収集・分析し，結果を整理して一般化することにより，一層の改善を図ることが可能になるのである.

4.3 計濁ソフトウェア環境における計測の問題点を考察するにあたっては，次の 2 つの点が重要である.まず第 1 は，
ソフトウェア環境自体が持つ特性(たとえば統合化のレベル)を計測できることである . そして第 2 は.環境の特性がソフトウェア・プロセスや作成される成果物に与える効果{たとえば，統合化のレベルによって，あるプロセスを実行するのに要する時聞がどの程度異なるか.ある程度の保守性を持つシステムを開発するには ，
ライフサイクル全体のどの部分をどの程度を統合化すればよいか，等など)を計測できることである .

もちろん，この 2 番目の機能のためには ， ソフトウェア成果物とソアトウェア・プロセスを計測することが必要であるが，その要求事項はここでは直接には議論されていない.

定量的計測は，いくつかの選択枝を比較して進化の方向をガイドする上で.明らかに重要である.しかし.

いつも「数値」を引き出すのが可能だとは限らないし，また必要でもない.たとえどのような評価でも，それが単に直感的あるいは経験的なものであろうとも，発展の方向をガイドし制御するのに必要な判断を行う上で ，価値を持つであろう . 事実，無理に定量的な評価に固執することは，ときに{計測が簡単だからという理由で)誤った性質を重視したり.

(定量的な結果を待つことによる)評価の不必要な遅れをもたらしたりすることもある.まったく新しいソフトウェア開発アプローチの採用など，革命的に新しいものへの移行の可能性を探るときには，特に，定性的評価や「勘」による評価に頼ることが重要になる .

4.3.1 問題点

ここでの関心は.進化型の段階的な改善によって環有権構築技術の発展の方向をガイドするための計測であった.他の活動(たとえば新技術を広く普及するといったこと)を支媛するための計測を考えた場合の問題点や活動項目は，もしかしたら，以下にあげるものと異なるかもしれない.ここにあげた問題点や活動項目は，さまざまな研究開発活動の支媛に貢献しうるように感じられる.しかし，グループ討論では，その可能性については検討されなかった.

しかしながら，このグループは.計測の結果が技術進歩のガイダンスに用いられる場合には.費用対利益に対する期待は，通常とは異なるべきだということを指摘している.計測にかかる費用は，どの場合にも当然のことながら大きい.しかし，十分に開発された技術と比較して ， 開発途上にある技術の評価には，ずっと多くの費用を要する.計測によって得られる利益もまた，どんな場合にも大きいが.ただし，開発現場での狭い範囲の計測と比較すれば ，リスクはずっと大きい .

したがって，開発途上の技術を評価する場合には，期待される利益に対する費用の比率がかなり高くなることをあらかじめ覚悟しておかなければならない.

‑
3
1
‑

SeamaDV
o
l
.
2No.9

rMISEEnvlronmentWorkshop(1) 環境の属性.ツール.プロトタイプ{ツールまたは環境).環境全体などを評価する量善の方法とは何か

これは自明な問題点である.環境の全体あるいは一部を評価するよいアプローチとはどんなものだろうか.

直接経験することは .

1 つのアプローチである(たとえば，だれかがあるツールまたは環境を使って.これまでより早くプログラムやシステムが作れることを実際に体験する)
行うのも.

.十分に制御された状況で科学的な実験を

1 つの方法である.しかし ， この方法は，意味のあるシステムを対象にした場合には，途方もなく経費がかかり，制御が非常にむずかしく.また，規模の問題にきわめて大きく依存する(結果の規模もあるし.
大規模システムの実験を取り級う能力の規模もある) . 3 番目は.観察と推論にもとづくアプローチである .
これは，何をどのように計測すべきかについての思考を鋭くするが，有用な成果を得るためには，かなり目的指向でなければならない.これらの相異なるアプローチを.いつどのような場合に使うか，また他のアプロー
チがないのか，を研究する必要がある.

(2) どうすれば鐙乱を避けることができるか

計測によって対象を変えてしまうのは望ましくない . 計測はエラーを隠してしまうこともあるし，対象が実際よりもよく見えるようにしてしまうこともある.計測用の命令を縛入することによって，まちがいなくシス

テムサイズは増加し.その意味では惑い結果をもたらす.また，計測対象の作業をゆがめたくはない.生産性の向上は.単にそれを計測するだけで達成される(ホーソン効果)というのは，悪名高い事実である.そして，システムのリアルタイム性を損なわずに，その動作を計測するのは非傭にむずかしい.計測の彫響を最少化し，結果を解釈するときに.その最多響を分隠する方法を研究する必要がある.

(3) どうすれば計酒手段を目立たないようにできるか

上記の例は，計測手段そのものが往々にしてトラブルの原因であることを示している.しかし，計測手段の組み込みは，それがプロセスの進捗状況を遺跡し，観測データや履歴レコードを収集し，システムの性能や人間的な要素の特性を調整する唯一の効果的な方法であり，たいていの評価アプローチにおいて不可欠な要素である.計測手段を組み込んだことによって.計測値が変動するような悪'惨事F は，なるべく減少させなければならないし.ツールや環境のユーザに強い惑彰響を与えないような計測方法が開発されなければならない .

(4) 笑般を行うための研究室をどうやって確保するか

経験，実験あるいは観測と推論という 3 種類のアプローチのどれを用いる場合にも，評価や比較のための『研究室」を持つメリットは大きい.そうした研究室は，他の科学や工学の分野では，成果物の計測に用いるツールを登理し統合化するのに有効であることが分かっている.究室の物理的な属性(規模など)は重要ではない.また，ソフトウェア技術自体の進歩(コミュニケーション技術など)によって，分散型の機能が実現可能になったことから.従来の慣習(たとえば，テストを行う部屋，オシロスコープなど)にとらわれて考える必要はない.それよりも，憲新の技術を活用した研究室的な機能の得策に重点をおいて考えることのほうが，重要なのである . このような機能を実現するには，以下にあげるきわめて図鍵な問題を解決する必要がある:

習要性曲.への対応:十分な配慮と学習支 tll 教材の開発なしには.習勲幽線はかなり急になり，実験結果を疑問なものにしてしまう.

‑
3
2
‑

rMISEEnvlronmentWorkshop

SeamaUV
o
l
.
lN
o
.9

技術左その使い方との相互作用の lUl い:自動化支媛のための新しい技術は，必ず作業の実行方法に影響を及ぼす.これらの相互作用は，十分に制御された実験を行うことを非常にむずかしくし，実験結果
自身やその解釈，または結果の価値に重大な悪影響を及ぼす.
構成要素の組み合わせ方:実験に使われるツールや調査対象は，多くの異なる源泉から集められており.それを互いに組み合わせる有効なアプローチやメカニズムが必要になる.一般に，これらのツールや対象を，それらが埋め込まれているシステム全体から分権することがむずかしいという点が，事態を恵化させている.

これらの問題はいずれも困難ではあるが.克服できないわけではない.既存の技術を利用すれば，以下の機能はとりあえず提供することができる:

環境の構成要素のうち，さしあたり実験に関係ないものを分際する.
習熟曲線を平らにする .
進化型プロトタイピング.

実験計画の作成 .

各種の完成した環境あるいはプロトタイプ環境を実験に取り込む，あるいはアクセスする.
ツール，ツール集合 ， 環境全体，またはソフトウェア・パラダイムを評価するためのテストベッドを構築する.

以上の織能は明らかに原始的でなものではあるが.しかし.かなり有用である.それは，近い将来における進化型の改善のための適切な基盤となりうるものであり，とりあえず必要な織能.および，より進歩したパージョンを開発するための経験や知識を獲得する方法を，われわれに提供してくれる.

(短期的ならびに長期的な観点において)研究室がどんな機能を持つべきかをはっきりさせる必要がある.また，どうやって基礎的な初期徳能を確保し，それをどうやって時間とともに進化させてゆくかも ， きちんと計画しておかなければならない . 端的にいえば.研究所は笑際には 1 つの特殊なソフトウェア環境であるから，この報告のあちこちで述べられている問題点について，すべて検討を行えばよい.とはいえ，研究室という特殊性のおかげで，検討の内容は，一般的な解答を求める場合と比べれば.かなり簡単であろう .

4.4 単一言語環境と多重言語環境

単一言語環境は，すべての作業を支媛するただ 1 つの表記法を提供する.この種の環績が作られた動機は.
構築の容易性および . 複数の開発工程で使用する場合の一貫性である.

InterLisp や Smalltalk は，単一言語環境の典型的な例である.

多重言語環境は，互換性のある一連の表記法を提供し，それぞれ軒法は，異なった作業集合を対象としている.これらの表記法は，いろいろな形の抽象化手段を提供し，それぞれ特定の作業向けにカスタム化されている.

DCDS[DCDS84] は，多重 言 語環演の 1 つの例であり，そこではソフトウェア・ライフサイクルの各局面を.異なる記述法で支援している.

Gandalf[Gand85] は.やはり，異なる表記法で異なる作業(プログラミ ン グ. t書成管理，プロジェクト管理など)を支 I浸している環境の例である.表記法が特定の作業向けに調整しであるので.ほとんどの場合.多重言語環境は単一言語環境よりもユーザの{時には環境の}の作業効率が
高い.

‑
3
3
‑

l
.2N
o.9
SeamaUVorMISEEnvironmentWorkshop

現在の単一言語環演は

1 つの表記法に焦点を絞ることによって.環境の持つ諸機能を強く統合化し，使いやすさの点ですぐれていることを実証している.しかし，このアプロチの欠点もまた，明らかになっている.

この種の環境は，ソフトウェア・ライフサイクルの下流工程に対する支援に偏る傾向があり，ライフサイクル

全体をうまく支媛できない.そして ， 個人の作業だけを支織する傾向が強い.現在の多重言語環境は，これらの問題のいくつかを解決しているが.また別の問題を持っている . それは.複数の表記法の間で互換性をとるのが困難なことであり.また，ある表記法による記述から他の表記法への(半自動的な)変換を支媛するのがむずかしいことである . その結果.弱く統合化されたいくつかの機能を提供するだけに終わってしまうきらいがある.

いずれの型の環境に対しても，改善活動項目を設定する必要がある.単一言語環境における主要な問題点は，広範囲のソフトウェア開発の作業をどうやって支 I還するかということである .

したがって.現在の単一言語環

境を拡張して， (1)複数の異なる種類の人聞を開発保守作業に取り込む， (2) ライフサイクルの上涜工程を支媛
する，という 2 つのことをカバーする必要がある.

多重言語環境における主要な問題点は，環境の中に存在する各種の表記法や支媛機能について，高度の統合化を達成することである.

4.5 ユ ー ザ・インタフェイス

これまでの宣伝で述べてきたことから，

1990 年代の環境はワー クステーションを基本とするものになると想定してよい.ソフトウェア環境へのワークステーションの普及は，その上で各種の有用なツールが出現し，高解像度カラー・グラフィクス，音声入力(編集機能っき)，広い作業領域を提供する大規模スクリーンなど.

ハードウェアの機能が発展することによって，ますます加速されるだろう.これらの高性能ワークステーショ
ンの機能を効果的に活用するには，ユーザ・インタフェイスのメディアや.ソフトウェア開発と進化の過程における人問機械間の情報交換モードに対する理解を，十分に深める必要がある.

4.5.1 問題点

ユーザ・インタフェイスに関する問題点は，大きく 3 つに分けられる.

(1) システムのユーザ-モデル

ユーザと環境との聞のやりとりに関して，適切なモデルを見つけ出す必要がある.モデル開発のアプローチには，認知科学的なモデル化の方法にもとづく「トップダウン型」と.人間的要素に関する実験にもとづく「ボトムアップ型」の 2 通りがある.

関連する問題点としては.インタフェイスをカスタム化すべきか，標準化すべきかということがある.ある
面では.カスタム化は個人レベル ・ 組織レベルのいずれか(またはその両方)で実絡されるものであるから.
これは管理上の問題だといえる.ある程度のカスタム化は望ましいとしても，

2 つの大きな疑問点が残る.それは.どうやってツールや環境向けにカスタム化可能なインタフェイスを構築するかということと，システム

がユーザを「観察」しカスタム化に関して助言を行えるか(行うべきか)ということである.

‑
3
4
‑

SeamanV
o
l
.
2N
o
.9

rMISEEnvlronmentWorkshop(2) システムのプロセス・モデル

環境の内部にソフトウェア ・ プロセス・モデルを構築する主な動織は，システム自身がユーザの支 t還を行うことにある .

システムは ， 特定の作業に対して(前後関係に依存した)チェック・リストをユーザに提供し，また実際に(ある方法論にもとづく)特定の作業をユーザに強制するなどの支媛を行う.この種の支媛は . ユーザ・インタフェイスにとって，明らかな意味を持っている . 可視性や強制度の面で，どのような支援を行う
べきかに関する考察が，特に重要である .

このようなモデルが実現可能かどうかについては，なお研究の余地がある.ソフトウェア・プロセス一般についてのモデルも ，また，プロセス中の個々の工程に対する特定のモデルも研究されねばならない .

特定のツールが起動された前後関係をシステムが「理解」できるためには，より「かしこい J

.

さらに，

より統合化されたツール集合の開発が必要である.

(3) ユーずのプロダクト・モデル

ここでの主要な関心は，ソフトウェアを『可視化」するための支媛を行うことにある.この点については，
ソフトウェア環境は CAD/CAM 環境に比べて か なり遅れている.可能なアプローチとしては，システムの動作をアニメーション表示することや，システムを複数の特殊な視点から眺められるようにすること，などが考えられる.

4.6 書店進的改善~革新的改善

今後 1 0 年聞にわたって，ソフトウェア環境技術を改善して行くためには 2 つのアプローチがありうる . 革新的アプローチでは ， 先進的な技術を利用して.強制的に新しい開発パラダイム(たとえば革命的に新しいソ

フトウェア・プロセス・モデル}に移行し，また高度な自動化支撮(たとえば，高度に自動化されたプログラ
ム変換)を行なう( [Balz83] 参照).このアプローチの鍵となる特徴は ， 革命的に新しい技術を導入することによって，開発環境に不連続的な変化がもたらされることである.一方..進的アアロ ー チは，環境構築技術の着実な{かっ迅速な)成熟を基礎として，段階的な改善をもたらす新技術をたえず(頻繁に)取り入れ.それらを既存の環境に統合化することによって達成される.

([Boeh83]参照).このアプローチの鍵となる特徴

は，変化の単位が小さいことである.段階的な変化は危険も小さいが，しかしまた効果も少ない.

過去 5 年間におけるソフトウェア環境改善の多くの部分は.漸進的アプローチによってもたらされた . 一般
的にいえば.その理由は.危険度が小さく，ユ ー ザの作業パターンの変更度が小さかったからである . このグ
ループでは.

1990 年代に突入するにあたって，実践状況の改善にはやはり漸進的アプローチが適切だが，最先端技術の進歩に最も貢献するのは革新的アプローチだと感じている.

革新的アプローチの採用が何らかの理由{資金の不足，危険の大きさ)で不可能だとすると，効果的にこの2 つのアプローチを統合する道筋が考えられる.この道筋は.次のごく単純な観察にもとづいている.それは，変化が革新的か漸進的かの評価は，評価の時点によるのではなく . 変化が起こった時点によるということである.今日の状況からすれば革新的なアイデアでも.

1990 年の状況に投影すれば.単なる漸進的なアイデアにすぎないこともありうる.これは，たとえ漸進的アプローチをとっていても，革新的アイデアを避ける必要はない(避けてはならない! )ことを 意 味している.実際に，現時点ではまだ革命的すぎると恩われる技術に

‑
3
5
‑

SeamaﾟV
o
l
.
lNo.9

rMISEEnvlronmentWorkshop

ついては，その技術自身やまわりの技術が成熱し.その導入が単に漸進的な 1 ステップになった時点で，速やかに導入できるよう計爾しておく必要がある.

現在は革命的だと思われている技術も.漸進的アプローチによって環境構築技術を改善する上で.多くの役割を果たすことができる:

長期的に見て実現されるべき環境線能を定義すること.

十分に成熟しており，すぐに環境に統合化できるような先進技術に注目を促すこと.

中期および長期にわたって漸進的アプローチをガイドし，将来革命的な新技術を導入しやすくすること .

本質的には.革命的技術は，その時点における「技術的な水平線』を定義するものである . 漸進的発展はその方向に向かつて行われ水平線 J に向かつてしだいに速度をあげ，そこに到達したときにその銭術を吸収できる素地を作って行く.

‑
3
6
‑

rMISEEnvlron
皿ent Workshop

SeamaHV
o
l
.
lNo.9

5. 全体セヲションでの討論

オープニング・セッションでは，ワークショツプで取り上げるべき話題の決定と.

1990 年代半ばの技術

状況の予測が行われた.その結論は，第 1 ~2j誌で述べた通りである.最後の全体会議では，グループの関心

は. (1)提案された活動項目を成功穫に遂行できるような組織の特徴を決い出すこと.そして (2) 5 年前にカリフォルニア州ランチョ・サンタフェで開催された同趣旨のワークショップの成果をあらためて見直すこと，の 2 点に絞られた.そこでの討論の顕要を本章で報告する.

5.1 実行組織の特憶

さまざまな分野での活動項目の提言を作成している過程で，現在の組織構造は.必ずしもこれらの活動を実錯する上で適切とはいえないということが指摘された.特に，ここで提案されたようなソフトウェア工学的な活動においては，従来からあった研究線開と開発組織との問の区別が.ほとんど不鮮明になってきている.概念の証明を行なうシステムを構築しなければならないことで，多くの研究プロジェクトは明らかに開発的な色彩を帯びてくるし，一方，各種のツールを実用的な環境へと統合して行くさいに発生する模本的な疑問を調査しているうちに.開発フ・ロジェクトには自然に研究的要素が入り込んでくる.

録終全体討論の一部として.ここで提案された活動項目を実行する組織が持つべき特徴についての自由討論が行われた.討論の焦点は，環筏開発プロジェクトの一般的構造，プロジェクト・チームの構成，プロジェク
ト・メンバの能力や経験などのことがらであった.その結果.このワークショツプで取り上げられた各分野でのプロジェクト提案の評価に使えるような.非技術的な判定基準のリス ト(の一部分)ができあがった.

このワークシヨツツプで洗い出された問題点を眺めて，すぐに感じられるのは，これらの課題に銚戦するには多くの資源が必要だということである.問題は.一見きわめて困難であり，それらを完全な形で解決するにはお金のかかる」大規模プロジェクトをいくつも打ちださなければならない.また，プロジェクト.プロ

ジェクト ・チーム，およびプロ ジェクト・メンバに要求される特性(以下に述べる )を満足するには，やはり ，
非常に大きな財政的資源を必要とするように思われる .

そうしたプロジェクトは.単に成果物(ツール.環境の一部または全体}を開発するだけでなく.その利用も促進する必要がある.つまり，それらのプロジェクトは，ただアイデアを作るだけではすまないということである.アイデアは，ちゃんと使える形の成果物になっていなければならない(ただし，必ずしも製品としての完成度は要求されない) .概 念の正しさを実証し . 実現可能性やそれによってもたらされるメリッ トなどを例示するために，何らかの形あるものが必要になる.また ，これらの成果物は，長期的な技術進歩の方向を明らかにするとともに.探求すべきいくつかの新しい可能性を示唆する.成果物の実際的活用をプロジェクトの不可欠な要素として取り込むことにより .いくつかのよい結果が得られる.そうしたデモンストレーションにもとづく評価は.その成果物の価値を最もよく認識できるような人聞が評価作業に積極的に参加した場合にのみ ， 初めて最大の効果を上げるものからである .ま た，それは.プロジェクトの成果物が，頑丈さや性能など
いくつかの函で高品質になるという ，波 及効果をもたらす.

プロジェクト・チームは，研究者，現場の実践技術者，ツール開発者の 3 者から成る混成チームであることが望ましい.研究者は，必然的に発生する基本的な問題点について，高度で知的な検討を保証するために必要である.ツール開発の専門家は.成果物が工学的見地から見て十分な品質をそなえていることを保証するため

‑
3
7
‑

rMISEEnvironmentWorkshop

S
e
a
m
a
l
lV
o
l
.
2No.9

に必要である.また，現場技術者ー は，成果物が十分実用的であり，評価のためのデモンストレーションが.実

世界の要求や関心を反映していることを保証するために必要である .

混成チームがもたらすメリ ッ トは数多いが，そのうちのいくつかを以下に示す:

現実の典型的なソフトウェア開発・進化の状況を反映した形で成果の開発が行われる可能性が高まる .
開発から普及までの時間 差 を短縮する .

成果物が現実世界の関心(会社の方針，組織構造，組織の変更など)を反映する可能性が高まる.
現場で実際に用いられているソフトウェア・プロセスの影響下で開発を進める可能性が高まる.
開発の成果を大規模システムで利用するさいの規模の問題について.正しい認識や理解が深まる.
成果物を実際にする人 々 に 高 い信頼感を与 え る.
成果物が本当の要求に合致 す る可能性が高まる.

現状の組織構造では，このようなプロジェクト ・ チームの編成はなかなかむずかしいことが.多くの多加者から指摘された.

研究者. 実 践技術者，ツール・スペシャリストが同一組織内に存在することは滅多にない.

もし.いたとしても ， 組織内部 の 壁によって，効果的な協力関係は阻害されている.少なくとも近い将来においては ， ここで提案された問題点や活動項目を 消 化して行くためのプロジェクトは，学界・産業界 ・ 政府機関の共同体によって実行されるしか な いであろう.

プロジェクトメンバは.個人的にもまた全体としても，重要であるにもかかわらずしばしば忘れられている
ソフトウェア・プロセスの 2 つ の特 徴を ， 正しく認識していなければならない . まず第 1 に ， ソフトウェアの開発や進化は ， ソフトウェア・ハ ー ドウェア・人間という 3 つの要素から成るシステム全体を開発・進化させるもっと大きなプロセスの 一 部だということである.システム全体に対する直接の関心をプロジェクトの一部として取り込む必要は必ずしもないが，ソフトウェア・プロセスの外側にあってそれを包含ずるシステムの概念は.つねに心にとめて 置か なければならない.第 2 に，プロ ジ ェクト ・ メンバは.ハ ー ドウェア・ソフトウ
ェア・人聞の各要素聞の相互作用 や トレードオフ関係を，正しく認識していなければならない.再び . すべてのプロジェクトがこの問題(たとえば，システムを実現するためのいろいろな代替案の選択を支綴するプロダクトを開発するといったこと)に 直 接取り組む必要はないが，つねにより広範囲な問題を念頭にとどめておくことによって，開発の成果がより広い応用範囲をもっという(望ましい)波及効果が得られるだろう .

最後に ， プロジェクト・メ ン バは.個人的にもまた全体としても，優先端のソフトウェア技術についての正しい認識を持っていなければな らな い.実際に.最先端技術の研究開発に携わった経験や知識を持っているかどうかは.あまり重要なではない . 重要なことはモダン J な進取の精神を持ち ， 技術の水平線がどこに位置しているかを理解し，その価値や限界.現実との隔たりをわかっていることである . このワークショップで提示された活動項目は，それぞれ独自の有効性を持つ中間的成果物を作り出すことを意図してはいるが，本質的には ， より長期的に見て ， 技術 の 進歩に大きく 貢 献することを目的としたものである . したがって，それぞれのプロジェクトは.この 目 標に 沿 った成果物をもたらさなければならない

特に，最終成果物が，プロジェ

クト開始時の最先端技術(最 悪の場 合はその当時 の 実用技術)をなんら改善することなく 実 現したようなものであってはならない.

‑
3
8
‑

rMISEEnvlronmentWorkshop

SeamanVol.2No.9

5.2 ランチョ・サンタフェ再訪

今回とほぼ同じ目的で5 年前にランチョ・サンタフェで行われたワークショツプの 1 つの成果として，ソフトウェア環境が持つ次の 5 つの 重 要な特性を指摘した論文が発表されている [Oste81] .

支掻範囲:ソフトウェア要員あるいはチ ー ムに対して，ソフトウェア ・ プロセス全体にわたる強力な支鑓を提供する.
ユーザ緩和住:ユーザ側 の 作業手続きやスタイルが変わっても有用さを保てるような適応性を持つとともに，強力な，しかし強制的はでない快適な支媛を提供する.
柔敏性モノリシックな)ツールではなくツール ・ フラグメントを利用して，柔軟性や再利用性を高める.

統合化:ツール間の相互 作 用や協力関係をより密接にし，スムース . かつ連続的，かっ非強制的な支援を提供する.

情報の集中化 : 中央の情報貯蔵庫へのアクセスによって，ツ ー ルやプロ ジ ェクト活動の相互調整と集中管理を図る.

また，このワークショ '" プでは.次に述べるような 2 段階のアプローチが提案された . 第 1 段階は，既存システムの調査研究とあわせて，ツ ー ル ・ フラグメ ン トと中央データペース支媛を実験的に構築する . そして第2 段階は ， 第 1 段階で開発された技術を利用して.与えられた仕様に対する汎用的な環境を開発することである .

このアプローチは.

TOOLPACK[Oste83] やSo ftware P
r
o
d
u
c
t
i
v
i
t
yS
y
s
t
e
m[Boeh84] などの例に見られるように，かなりの成果をおさめた.これらの環境が持つ諸特性やその意援について，われわれの考え方がより洗練されてきたことも ， その成果の一部である.最終全体討論では5 年前になされた技術評価の内容が再検討され，新しい考察がいくつか追加されした.これらの議論の要約を以下で報告する.

5.2.1 支鑓範聞

ソフトウェア環境が広範囲のソフトウェア開発活動を支鑓しなければならないことについては，依然として疑問の余地はない .

しかしながら.これまでの 5 年間に.要求される「範囲 J に関するわれわれの考え方はかなり進化しソフトウェア開発要員」に対する考え方も大きく変わってきた . ソフトウェア開発要員や開発チームは.単にソフトウェアだけに関心を持つだけでなく，ハ

ドウェア・ソフトウェア間のトレードオフな

ど，システム全体の問題に取り組んで行く必要がある.

Sふ Z ユーザ a 和性

5 年前には，環境は強制j 的なものであってはならず，また，ユーザ ・ インタフェイスは快適なものでなければならないということがユーザ緩和性 J に関する 2 つの重要な必要条件だと考えられていた.これらの要求条件は依然として重要であるが.他の目僚に比較して.こうした意味での「ユーザ親和性」が 2 次的なものでしかという状況が存在することも，確認されている.ときには，ユ ー ザに環境の持つ徳能をはっきり意識させるようにした方がよい場合もある . たとえば，環境にある種の強制l カを持たせた典型的な例として.

Lisp の DWIM や織文指向エデ ィ タにおけるアドバイスの提供と方法論強制の 2 つがある.

‑
3
9
‑

I
n
t
e
r
ｭ

SeamaUV
o
l
.
2No.9

rMISEEnvlronmentWorkshop

同様に，快適さの概念、についても ， 環境やその構成要素の利用に関して.特に学習段階においては，利益対苦痛のトレ ー ドオフ関係が存在することがわかってきた . 環境は，これまでより広い範囲の支媛機能を提供しなければならず，そうなれば ， 統合的な親しみやすいインタフェイスを提供する上で.新しい問題が発生する.
有用な付加価値が得られるならば，ユーザは多少の不便は喜んで我慢するに違いない.

5.2.3 柔敏性

環境の柔軟性に関する問題点は.もはや ， 単に新しいツ ー ルを取り込む能力だけに限らない.同様に，新しいパラダイムも取り込めなくてはならない.さらに.柔軟性の範囲は個々のユーザの要求を越えて拡張きれなければならない . チームの規模や，組織の方針，組織構造.その他多くの「外的な」要因の変化についても，
支媛しなければならない .

5.2.4 主主合化

統合化の問題は ， 環境の持つ徳能をお互いどのように適合させるかという意味では.ユーザ緩和性と非常に強く関係している . 統合化が. 0 か 1 かで判定で き る性質でないことは明かである . 実際に.異なるユーザに対しては，異なるレベルの統合化が必要である.また，一枚岩の環境から，部分環境の集合であるような環境への移行も行われている . この移行によって.

4.1 節で議論した 3 種類の統合化(外部的統合化，周辺関係の統合化，内部的統合化)を踏まえた統合化戦略が必要になり，また，方法論的な統合化(たとえば.環境が支媛する機能と，特定のソフトウェア・プロセス・パラダイムに関連する自動化されていないその他の機能との一貫性)も重要になってくる.

5.2.5 情報の集中化

すべてのデータを格納する中央データペースの綴念(論理的なものであり，物理的である必要はない)は，

長い間ソフトウェア環境の設計において基本的なことだと考えられてきた.しかし，この概念がもはや環境を設計する上で真の「駆動力」にならないことは明らかである . 本当に検討すべき問題点は.ソフトウェア・プ

ロセスおよびそのプロダクト集合である.この観点に立てば.次にあげる各次元に沿って，論理的に異なる何種類かの情報格納庫を持つのがよいと思われる:
革E 閤

情報の利用者プロセスの各段階からの情報
プロジェクト情報
時間に依存する属性(たとえばシステム・パ ー ジョン)

‑
4
0
‑

rMISEEnvironmentWorkshop

SeamanV
o
l
.
lNo.9

6. 全体的な関心事項

ワークショツプでは.数多くの「全体的な関心事項」が現れた.これらは，ほとんどの技術グループや共通技術グループにわたっているという意味で全体的である.これらは，ワークショップで考察されたすべての分
野での進歩を達成する上で重要で あ り.したがって . 直接 ・ 迅速・集中的な注目に値することがらである.

(1) 利益対苦痛

ソフトウェア・ツ ー ルや環境を利用する上での主な障害は，それを学習し活用するための労カの大きさである . この労力は，ときに，ツールの利用によって得られる利益をはるかに越えてしまう.実験または開発期間

中なら ， ユーザは ， 高い苦痛の書11 に得られる利益が小さくても耐えられるだろう.しかし，実際の使用段階に入った後は，環境の構成要 素 がユ ー ザに受け入れられるためには，なるべく少ない労力で高い機能を提供しなければならない.ツールおよび環 境 の開発や利用に関する意志決定を適切にガイドするためには，利益対苦痛の比率を測定し最適化する方法を開 発 する必要が あ る.

(2) 抽象化

ソフトウェア・プロセスの各工程を支鑓するための一貫した適切な抽象化技法の集合を見つけ出す必要がある

こうした抽象化技法群の必 要 性は.統合化グル ー プによって指摘されたが，それらは，他のグループが提案した活動を実施するさいにも き わめて重要である(たとえば，拡張性およびユーザ・インタフェイス ・ グルー プが提案した活動項目)(3) 視点システムに対するさまざまな視 点 は.ユーザが果たす一連の役割の抽象化に関係しており.したがって.ソ

フトウェア環境に関する幅広い活動項目の全体にまたがっている.それぞれの活動分野において，適切なユー

ザ視点を洗い出す必要があり.またそれらの視点を提供する支媛徳能を開発する必要がある .
(4) モデル

ソフトウェア環境の世界で重要 な一 般的改善が 達 成できるかどうかは . ソフトウェア ・ プロセス.環境のユー ザ ， プロセスとユーザの関係などを反映した ， 有用なモデルを作れるかどうかにかかっている.
(5) 柔軟性/拡張性/カスタム化容易佐

これは，基本的にはあるグル ープ が指摘した関心事項であるが ， 他のグループが検討した分野での改善を成功させる上でも，きわめて重要で あ る .

(6) 統合化のレベルとスタイル

統合化はモノリシ ッ クに考えることはできない.それは ， 統合化グループが明らかにしたように，いくつかのレベルやスタイルに分解されるべきものである . この分解によって，環境の高度な統合化が達成できるよう

‑
4
1
‑

SeamaﾟV
o
l
.
2No.9

rMISEEnvlronmentWorkshopになる.また，広い意味での統合化の達成と矛盾する可能性のある他の目療を，同時に達成するための枠組みが用意される .

(7) コミュニケーションの賓と量将来の技術では.ユーザ悶のコミュニケーションや，環境の構成要素聞のコミュニケーション，またユーザと環境要素聞のコミュニケーションの幅を広げることが可能となる.しかし，この幅広いコミュニケーション

手段を利用して.ユーザ・インタフェイスの改善や，分散機能の利用促進，拡張性の支緩などの波及効果を得るまでには，かなりの調査研究が必要である.

(8) 変化の大きさ

1990 年代に向かつて進ん で行くさいの個々の変化の大きさは，ソフトウェア環境改善のすべての面において，重要な関心事である.すでに指摘したように.小さな変化量は漸進的改善を意味し，大きな変化は革新
的改善を意味している.どのような大きさの変化が.段階的な改善にとって理想的であり，また実行可能であるかを見分ける感覚を養う必要がある.

‑
4
2
‑

rMISEEnvironmentWorkshop

SeamaﾟV
o
l
.
2No.9

7. まとめ今回のソフトウェア環境ワーク シ ョツプで，各技術ワ ー キング ・ グループおよび横断的ワ ー キング ・ グルー
プは，今後 1 0 年聞にわたって ソ フトウェア環境構築技術を改善するための基本的な問題点を ， 広い範聞にわたって明らかにした . また ， とりあえず今後の 5 年間に(場合によっては.その次の 5 年間も含めた中期にわたって) . これらの問題点を解決するためのさまざまな活動項目を決い出し，それらの活動を実施すべきタイ

ミングと優先順位を検討した.

1990 年代半ばまでに何が達成できるかについての全員の評価を総合すると.

環境の機能は現在に比べて大きく改善されていることが予想される.また.ここで合意された提案は.短期的および中期的の改善は，主として，漸進的かつ段階的に行われるべきであり，それにより妥当なコストでかなりの成功が得られる可能性が高い.

ここで作成された問題点および活動項目のリストは ， 完全なものではない . いわば，それは ， 相異なる知識を持つ研究者および実践技術者のグループが.

2 日半にわたる集中討議で作成した可能性のスナップショット

である.それは，環境構築技術の 発 展には何が必 要 かということについての，ソフトウェア ・ コミュニティ全体の考え方の種子となるものであり . 今後いろいろな開発フ・ ロジェクトを計画し，そうしたプロジェクト問の調整を行い，長期目標を設定するさいに，大いに役立つであろう .

ワークショツプの全体討論は，ここで確認された問題点の解決を目指して提案された諸活動を実施する組織，

プロジェクト，およびプロジェクト・チーム・メンバがそなえているべき，いくつかの重要な特性を明らかにした . 成功するために最も重要な要素は，プロジェクト・チームのメンバやその背後にある組級が，たとえ能力的には無理であるとしても，考え方の上では技術の水平線にできるだけ接近することである .

5 年前の類似のワークショツプでは，単に環境の技術的側面だけが論じられたが，今回の全体討論では，状況が明らかに変わったことが指摘された.すなわち ， ソフトウェア環境によって支媛されるプロセスにもっと力点が置かれるべきことが提案された.この点に関していえば，現実のソフトウェア・プロセスが実際にどうなっているか，高い生産性や品質をもたらす管理しやすいソフトウェア・プロセスのモデルとはどんなものか ，
ソフトウェア・プロセスを有効に支 1還するためには技術をどう統合化すればよいか，などのことがらを理解することが重要である .

このワークショップの最も重要な結論は，ソフトウェア環境構築技術を大きく発展させるためには，基本的に関心の焦点を移動することが必要だという点にある . 過去 5 年聞に試みられたいくつかのプロジェクトは ，一定の範囲や機能を意図した環境を作り上げるために，基本的な問題点を理解し . 新しい技術を開発し ， 既存の技術をまとめあげることに力を注いできた{これは，たしかに正しかった) . しかし，現在われわれが直面している問題は，環境が満足すべき目的やニーズに焦点を当てることを必要としている .

したがって，今後 5年聞に実施されるプロジェクトは.既存の環境が持つ機能を段階的に拡張し，対費用効果を実例で証明し，われわれの経験や既存技術の主主張に役立つ実験を行なう，といった形のものでなければならない.こうした努力の結果 .

1990 年代の初頭には . ふたたび新たに基本的問題(統合化.拡張性.プロトタイピングなど)を検討し，正しい先見的知識をもって新技術を開発する次のサイクルに入るための，基礎が確立できるだろう.

このワークショツプは，過去 5 年間における大幅な進歩にもかかわらず ， まだなすべきことがたくさん残っていることを明らかにした.たとえば ， ここでは取り上げられなかった重要項目のリスト(図 2 )を見ても，なすべきことの規模は想定できるだろう.このレポートは，来る 5 年間に何をなすべきかについて考えるさい

‑
4
3
‑

SeamaUVol.lNo.9

rMISEEnvlronmentWorkshopに.

1 つのガイドラインとして役立つであろう .

8. 謝若手このワークショップに参加したのは.

RickA
d
r
i
o
n
. MarkA
r
d
i
s
.B
e
s
t
yB
a
i
l
e
y. DaveB
a
r
s
t
o
w
. FrankBelz. GeoffClemm.EdComer. WardCunningham. DennisHeimbigner.JackKramer. Roger
M
i
l
l
e
r.G
i
lMyers. LoloPenedo. C
h
a
r
l
i
eR
i
c
h
t
e
r.DaveW
h
i
l
e
.J
a
c
kW
i
l
e
d
e
n
. JimWinchester の各氏であった .

編者 2 人は，上記の参加者全員の貢献に対して.深い敬意と感謝を簿げるものである.討論の過程で提示された数多くの先進的なアイデアや材料は，このレポ ー トの作成をきわめてやりがいのある楽しい作業にしてくれた . また，レポートの原稿を査 読 し ， 有益な 意 見や助言を与えてくれた Bob E
l
l
i
s
o
n
.P
e
t
e
rHenderson.

DickT
a
y
l
e
r
.M
i
c
h
a
e
lYoung の各氏にも，ここで感謝の意を表する.
9 .参考文怠

[
B
a
l
z
8
3
] R .Balzer , T.E.Cheatham , andC .Green , "
S
of
t
w
a
r
eTechnologyinthe1990・ s : UsingaNew
983.
Paradigm , "Computer , vo 1.1 6 , no.11 , pp.39-45 , 1
[
B
o
e
h
8
3
] B.W.
BoehmandT.A .Standish , "
S
of
t
w
a
r
eTechnologyinthe1990 ・ s: Usinga
nE
v
o
l
u
t
i
o
n
a
r
y
9
8
3
.
Paradigm , "Computer , vo l. 16 , no .11 , pp30・38 ， 1
t
w
a
r
e
[
B
o
e
h
8
4
] B.W .Boehm , M .H .Penedo , E .D .Stuckle , R.D.Williams , andA.B.Pyster , "ASof984.
DevelopmentEnvironmentforImprovingProductivity ," Computer , vo l. 17 , no.6 , pp .30-44 , 1[DCDS84] "DCDSF
inalReport ," TRWReport38392-G950心46 ， TRW , Huntsville , Alabama , J
u
l
y
1
9
8
4
.
[
G
a
n
d
8
5
]S
p
e
c
ia
1I
s
s
u
eonGandslf , TheJ
o
u
r
n
a
lo
fS
y
s
t
e
m
sandSo ftware , vo 1. 5 , no.2 , May1
9
8
5
.
A
d
a
p
t
i
v
eD
e
s
i
g
nf
o
rD
e
c
i
s
i
o
nS
u
p
p
o
r
tSystem ," SIGOAN
e
w
s
l
e
t
t
e
r.vo l. l ,
[
K
e
e
n
8
0
] P.G.W.Keen , "nos.4/5 , S
eptemberlNovember1
9
8
0
.

S
of
t
w
a
r
eEnvironmentResearchD
i
r
e
c
t
i
o
nf
o
rt
h
eNextFiv
eYears ," Comｭ
[
O
s
t
e
8
1
] L.J.Osterweil , "981.
puter , vo l. 14 , no.4 , pp.35・43 ， 1
[
O
s
t
e
8
3
] L. J. Osterweil , "TOOlPACK‑AnE
x
p
e
r
i
m
e
n
t
a
lSof
t
w
a
r
eDevelopmentEnvironment ," IEEEtw
areEngineering , Vo l. SE ・9 ， no.6 , pp . 673 ・685 ， 1
9
8
3
.
T
r
a
n
s
a
c
t
i
o
n
sonSof‑4
4‑

S岨皿副1 V
o
l
.
2No.9

C
a
l
e
n
d
a
re
t
c
.

SEA 会員状況(昭和 63 年 1 月 20 日現在)
1213名 (11月 17 日から lS名増〉

大分

4

3S社 (11月 17 日から2社増〉

佐賀

'A'i

4

1
1

宮崎
勾3

鹿児島=
神縄

居 住地域
唱A

l

42o'A
内

3

6
4

却却お却話相

噌A

6
5

6

1134

く年・分布>

1
l

男

女

19

唱ム

AnU
『，

3
2

2
9
5
1
4
2
噌

2
2
3

今ゐ

J
F

3
2
8

内4

,‘‘

2
8
5

εJ

'A

nw

o
ω

『F

MW却話回

押

ロ目初

『，

7
9
4却

1d

く血濠ヨE分布>31 2 U 2mm21

肝MPUJPHFm批
yuJ3

6

1

く男女分布>

9

9

ζu'A

川山

A型

1
2

特3

Ea.
・

4
晶マ 20

‘‘
d

司
3

0塁

349

B型

2
6
1

AB 型=

1
2
1

124n

く賛助会員会社名>

IN 情報センタ旭化成工業，インターナショナル ・1
4

データ・リサーチ，伊藤忠エレクトロニクス. SBC ソ

A

8

内，&

特

3

唱

1
3
7

伺

3

2314

勾，内，&笥 3

・4

4
。

1
2
1
2

フトウェア，エムテイシー，サン ・ ビルト印刷.情報シ

ステムサービス.ジェーエムエーシステムズ，セントラ
ル・コンビュータ・サービス，ソフトウェア・リサーチ・アソシエイツ，ニッポンダイナミツクシステムズ.マ
イクロキャビン，三菱電搬セミコンダクトソフトウェア，
PFU.

ーロ日

峨峨峨評価細糊琳概繍結時鯨締賭劃僻訓側騨蜘楠宝糊蜘嬬娘婦蛾紬蜘描腕鯛鮮

勤務地域

3

・i

<正会員の勤重量増および居住建域分布〉

リクルート，リコーシステム開発，近健日本ツーリスト.構造計菌研究所，神戸コンビュ ー ターサービ

ス.経調，辻システム計画事務所.東海クリエイト，東電ソフトウェア，日進ソフトウェア.日本システム，日本システムサイエンス，日本能率コンサルタント，目立製作所，目立ビジネス機器，富士ゼロックス情報システ
ム，富士通，富士通ビジネスシステム(アイウエオ順)

‑
4
5
‑

r=ちL

E:" Y:~~

TT

鵬

ソフトウェア技術者協会〒 102 東京都千代田区隼町会 12 康和半蔵門コープビル 505
TE L. 03・ 234-9455

F
A
X.
0
3
‑
2
3
4
‑
9
4
5
4