3
‑
.
4

N
e
w
s
l
e
t
t
e
rfromSoftwareE
n
g
i
n
e
e
r
sA
s
s
o
c
i
a
t
i
o
n
Volume3 , Number

1988

目次
1
2

編集部から
第 6 回 ソフトウェア信頼性シンポジ ウ ム〈報告 ・ その 1)
鳥居宏次 / 岸 田 孝一

日本的品質管理とソフトウェア

保田勝通

ソフトウェア大場充

メトリクスとモデル

第 3 回実践的ソフ ト ウェア開発環境に関する集中討論〈報告 ・ その 1 )Su m m it の発想

青木淳

発表 2

ユ ー ザ-インタフェイスに関する一考察

吉村智香子

発表 3

ERAS について

新 田稔

参加者アンケ ー ト

討論
討論を聞いての感想、

参 加 者アンケ ー ト
平尾一浩

Hacker に関する考察

浜野剛至

不純人工知能礼賛

柳田

ウォータ フ ォールモデルの変形表現

細野広水

'1

幹事会/総会/その他の報告

C
a
l
lf
o
rPaperslParticip副 onForuminYokohaka:" H yp e r -Te xt をめぐっての論議

P
a
r
t2"

ソフトウェア技術交涜会 i n 徳島

勾

1
1
t
hI
nt
er
na
t
i
o
n
a
lConf
e
r
e
nc
eonSof
twar
eEngi
n
e
e
ri
ng

'

第4回

俊一

『バ U

九州支部設立報告'uζUA 『 nunuA

発表を聞いての感想、

RUA 『 00

発表 1

守ーム司 U 337aQJ141Jqd
1 2 2 3司 3 4 5 6 6 6 67ム7
7 7 7『，7
77888

S
es
s
i
o
n1 マン・マシン・インタフェイスの改善

4EA4EA

ソフトウェア品質指鎮の標準化に関する IEEE 試案の位置づけと評価

44rO 司JUnxu

Openi
ngS
es
si
on

A

ソフトウェア-シンポジウム ' 89

ソフトウェア信頼性の定量的管理に関するワ ー クショップ

第 6回

夏のプログラミング

第 2回

ソフトウェア教育に関するワ ー クショップ

ワ ー クショップ(若手の会 i n 八 γ 岳)

第 B回

ソフトウェア信頼性シンポジウム

第 4回

実践的ソフトウェア開発環境に関する集中討論

会員状況

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

1985

年 1 2 月 20 日に設立されました.

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

なお SEA は.個人参加を原則とする専門家団体です

その運営は.つねに中立かつ技術オリエンテ ッ ドな視点に立 って 行われ . 特定の企業や組織あるいは業界の利益を代表することはありません.

代表幹事 .

岸田孝一

常任幹事・

白井義美久保宏志熊谷章佐藤千明藤野晃延松原友夫吉村鉄太郎

幹事:

青島茂稲田博岡田正志落水浩一郎片山禎昭川北秀夫杉田義明鈴木弘武田知久

会計監事:

辻淳二

常任委員長:

白井義美(技術研究)

一 郎中園順三中野秀男西尾出野村敏次野村行憲針谷明深瀬弘恭

田中慎一郎

長井剛

藤本司 郎村井進盛田政敏

吉村成弘

久保宏志(企画総務)

藤野晃延(会誌編集)

杉田義明(セミナ ー ワ

クショップ)

分科会世話人環境分科会 (SIGENV) : 田中慎一郎渡澄雄一
管理分科会 ( SIGMAN): ;相沢圭一川北秀夫芝原雄二野々下幸治

教育分科会 (SIGEDU):大浦洋一杉田義明中国順三
再利用分科会 (SIGREUSE) :青島茂阿倍正平村井進
ネ ッ トワ ー ク分科会 (SIGNET) : 青島茂野中哲
法的保護分科 会 (SIGSPL): 能登末之支部世話人

CAI 分科会 (SIGCAI): 大木幹雄寺嶋裕一

中谷多哉子中西昌武

ドキュメント分科会 (SIGDOC): 田中慎一郎

野辺良一

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

横浜支部:熊谷章林香藤野晃延松下和隆
長野支部:小林貞幸佐藤千明細野広水
名古屋支部:岩田康鈴木智西村亨

九州支部 : 穂村正伸小田七生藤本良子平尾一治松本初美中島泰彦能見巧後藤芳美
SEAMAIL 編集グル ー プ:大槻売人岸田孝一佐原伸芝原雄 二

関崎邦夫田中慎一郎長井修治野辺良一藤野晃延

渡遁雄一

SEAMAIL Vo1.3. No.3‑4

昭和 63 年 6 月 23 日発行

編集人岸田孝一

発行人

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

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

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

〒 162

1
. 000 円藤和半蔵門コ ー プビル 505

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

SeamailVol.3 , No.3・4

MessagefromE
d
i
t
o
r

編集部から

興味のある方は.

1.蔽後のいいわけ

創刊以来これまで SEAMAIL の編集を担当してきた岸7 5~7 6 ページの参加案内を見て.

お申込みください.

田です.新年度の役員改選てぺ鈴木弘さんにかわって代表
幹事に選はl1.. 編集長のポストは藤野晃延さんにゆずるこ

3. 環境ワークシ ョッ プとになりました.自白 l吏シンドローム解決のメドがまだ立っ2 月に長野でおこなわれた(暖冬のため残念ながら去年ていないので，しば ら くは，まだ.

1 編集ボランティアとの長岡に続いて雪見酒はできませんでした)第 3 回環境ワー クショップ(実践的ソフトウェア開発環境に関する集中

して新編集長のお手伝いをさせていただきます.
この号は，最初 の 予定では. fJ..がシンガポー ルの ICSE

討論)の記録から.第 l セッション 「 マンマシン・インに行っているあいだに材料を l前え終わり，帰国後すぐ編集

タフェイスの改善 J についての発表・討論・および参加者にかかって，コールデ ン・ ウィーク明けには発行の子定だ

アンケ ー トをレポー トにまとめました.
このワ ー クショップの場合は.長野支部のボランティア

ったのですが ， テープから起こされた原稿の整理に予想外
5~6 月は.総会やシン・メンバ ー の努力で，すでに全セッションの記録がコンビ

ポジウムなどイベントも多く.編集作業のための時聞がな

ュ ー タに入っており.あとは編集の手間だけです(これが，の時間がかかってしまいました

かなかとれなかったこともありますが，基本的には，テ ー

笑は大変) .生の記録と参加者のポジションーペ ー パを集

プから完全原稿までの距離が遠いということです.

めたワ ー クショップ・レポ ー トは近く刊行されます

2 . 信 頼性 シン ポ ジ ウム

お急

さのかたは，そちらをお読みください.

なお，ここで発表された S山町凶t およびロボット ・ プロ

去年 10 月の第 6 団信頼性シンポジウムから . オ ー プニ
ング・セ γ ションの記録を，とりあえずお届けします原グラミング環演は . それぞれ先日のソフトウェア-シンポ

稿作成にあたっては，シンポジウム参加者の 1 人佐藤貴司

ジウム，さんにテ ー プ起こしをしていただきました.

知りたい方は，論文集をお求めください .

88 に，論文の形でまとめられています . 詳細を

残りのセ ッ ション(品質定量化指僚の設定-計 i!l!J の具体

次回の環境ワ ー クショップは.この秋神戸で開催の予定

化結果の評価に関する述続パヰ、 ル)は，いま.何人かので，いま炎表者を募集中です (8 3~8 4 ペー ジ参照、 ) •ボランティアの方々にお願いして.磁気から紙への媒体変換プロセスの途中段階にあります . この春行われた第 7 図

4. 最後にふたたび . 原稲をよろしく!

のテープも，大阪大学でやはり音ー から文字へのコ ン バージ

この号では.九州支部のキックオフまでの事情を描いた

ョンが進行中です(だれか ， 早く音声入力のワ ー プロを製

平尾さんの力作ほか 3 篇を掲載しました

品化してくれませんか ? ) .欠号以降に!却期待ください.

原稿はほぼ底をつきました.

なお.このシンポ ジ ウムは. 1却下子じのように，大阪大学の鳥居先生が主宰されている高信頼性研究会とSAE 関西支部が協力して.約半年ごとの周期で開催しているものです.次回(第 8 回)は.

藤野新編集長のもとでの今後の SAEMAIL 発行予定も.

会員のみなさんからの原稿がどしどし寄せられないかぎり，
これまでのペ ー スを大幅に改善できるとは忠、えません.

10 月の末に子定されており.現

在.一般からの発表者を募集しています

81~82 ページの案内をお読みの上.ふる っ て lðP 応募 く ださい .

支部や分科会の議論の記録.技術的な小論文，随筆，書評 .i号、痴，呼びかけ等，何でも結構です

よろしくまた.高信頼性研究会 (とい う より.その母体になっている日本線倍協 会の 鳥居委員会)では，いまソフトウェア
信頼性:7)定量的管理のための標準的ガイドライ ン を策定中

ですが，その試案の 妥 当 性を現実 の プロジェクトの状況と照らしあわせて議論するワークショ ップ が，夏の終わりに計画されています ( SEAI針重)

これで手持ちの.

‑1‑

なにぷんともに，SeamaUVol.3No.3‑4

6thSoftwareR
e
l
i
a
b
i
l
i
t
ySymposium

第 6 回 ソフトウェア 信頼性シンポジウム〈報告 ・そ の 1)

OpeningS
e
s
s
i
o
n
AM 10:∞~ 12:001987 年 10 月 23 日

於大阪ガ ー デンパレス

チェアマン

報告者

浦野義頼 (国際電信電話). 鳥居宏次 (大阪大学)
岸 田孝一(ソフ ト ウェア・リサ ー チ

アソシヱイツ)保田勝通 (日立製作所)
大場

浦野 :

充 (日本アイ・ビー・エム)

ことを話しあって，あちらでいま検討中の試案(この 1 月

このシンポジウムも今回が第 6 回目，東京から大阪へ会場を移して 4 回目になります . あとで主催者の，鳥居に作られた Vers ion 12) をもらってきました.たまたま.

先生から こ'紹介いただきますが，ソフトウェア品質指僚に私がやっているソフトウェア信頼性委員会の活動テ ー マと関 する IEEE の標準化試案というものが.アメリカで作ら

うまくフィットするような感じなので.今年これを取り上れておりまして，鳥居先生がやっておられる日本規格協会

げてみょうかということになりました.

の委員会のメンバーを中心に，

8 月の末に伊豆でその内容

IEEE のこの試案作引;すでに 3~4 年から始まってを 検討するワークショップを開きました.今回のシンポジいるようです先々週.東京で開かれた COMPSAC の会

ウムは，このワ ー クショ ッ プの成泉を踏まえて，

IEEE 試場で， NBS の Os borne という黒人女性に会いました.か

案を肴 に . ソフトウェア品質の定量 的管理について.いろの女がたまたま Schine i dewi nd 委員会のメンバでして.そい ろ討論しようと考えています.

の後 2 月に出た Version 12b を持っていました.両方を 比セッションでは.まず，鳥居先生他の方

べると，内容はかなり変わっています.そして，かの女の々にチュートリアル風のお話をしていただき.その後の討話では，いま，さらにもう 1 つ新しいパ ー ジョンが走って論の話題を提供をしていただこ う と思います.

いるそうですオ ープニ ング

「 なぜそんなに変わるのか ? J と聞くと，委員会といっ

ソフトウェアの 品質指標の標準化に関するても，要するにボランティアの集まりですから.お互いにIEEE 試案 の位置 づけと評価

E-mai l で意見をどしどし交換しあう . そして，誰かが幹事役になってみんなの意見を編集し，適当なタイミングで鳥居宏次/岸 田孝一

全員に配布するという，私どもからすると考えられないよ

うなスタイルてヘ作業が進んでいるようです鳥居

来年の春までに.試案としては 一応完成させる目標だっおはようございます.これだけたくさんの方が集
1 9 68 年に，有たらしいのですが，いまの状況では.いつ終わるのか誰に

名な NATO のソフトウェア工学ワ ー クショップがありまもわからないと， Os borne 女史はいっていました.私ども

したが，この会合が，それに似たものになって，ひょ っ ととしては.別に.そうした向こうの作業ペースは気にする

したら何かこう将来に対するイ ン パクトを与えられるかな

ことなく，あくまで l つのたたき台として利用させてもら

まら れ ることは . まったく予想外でした .

って.日本なりのソフトウェア信頼性定量化試案を作り上と.さっさから思っております.
今年の春にモントレ ー の I CSE へ行ったときに，

IEEE

げていこうと思っています.

で品質定量化のワ ー キング・グル ー プを主宰されている
Schnei dewi nd 先生にお目にかかり，お互いにやっている

いま，お手もとに原文のコピ ー をお配りしたこの試案を .
はじめて見た方は繁かれると思いますが， 阪念的なフレ ー

‑
2
‑

6
t
hS
o
f
t
w
a
r
eR
e
l
i
a
b
i
l
i
t
ySymposium

SeamailVol.3No.3・4

ムワークの絵は描いてあるのだけれど，内容はまだほとん

後者の方の立場，つまり，ソフトウェアを作ったり，テス

ど詰っていません.例題などもきわめて不十分です 目 伊豆トしたり.あるいは動かしたりする環境や.そ ういう仕事のワークショップでも ，そのことがかなり問題になりましをするプロセスとの絡み合いで ，品質というもの を考えよた

うという立場 をとっているよ うにおもわれます.

フレ

ムワークは.図 1 ・ 1 に示す通りですが，参加者それぞれの環境や背景の遠いから，この図の解釈についても.ずいぶんいろいろな意見が出ました.

ユーザの視点

今回，みなさんにお配りしたワークショップ

レポート

は.そうした討論の結果を含めて，参加者全員にポジショ

度合い

ン・ぺーパを整理をしていただいたものです.

開発者の視点私のこの場での担当は，伊豆ワ ー クショップでの討論のソフトウェアの購入，開発，検証(検査).および稼 働のための環境や関連するプロセスの関概要を報告することなのですが.この仕事は，おそらく私数より.ワークショップの世話人をやられた岸田さんのほうが適任だと思います

ソフトウェア製品が.望ましい
属性の組み合せをそなえている

よろしくお願いします.

表 1-2 ソフトウェアの品質

rA::TO~

ソフトウェアの開発-稼働環境，あるいは，それに関連するプロセスと，そこから作り出されるソフトウェアの品質との関連は.非常に複雑であり ，したがって，こうしたc : で士 :.ION

C?I"ERION

Ci.: てτ P. 10li

観点からは，品質というものを . なかなか.はっきり定義
することができません.それは. ~ ¥~、かえれば，品質に関する要求仕様がきちんと書けないということになります.
|

町一一

l

このように土台が固まっていない状態では，いくらいろIN 訂主 IC I

I

~つ， 1:

いろなデータを取ってみても，デ ー タそのものの信滋性，あるいはデータを加工して得られる統計的指標の妥当性が

u

『d

.E

‑ ‑ ￨ll

‑‑

--

‑

旬

内d

司-­
‑一.
‑‑.

.-

--

.-'』

.‑D

‑1 ‑

‑.‑id
‑
.
‑

l

•

よくわからない.という銀本的な問題が生じます .
一 口にソフトウェアといっても.パソコンのソフトウェ

アから，大型憾のソフトウェアまでいろいろありますし，
そのソフトウェアをつくるプロセスもさまざまです.プロ

国 1-1

ジェクトにもいろいろな形態があります.ということから，品質に関するわれわれの議論はいつもかみ合わない.

岸田 :という突然の御指名ですので，しかたなく報告させていただきます

いいかげんな大学の先生とつきあっているとひどい自にあうという，格好なサンフ.ルになったよ

うな感じがします(笑い) •しかし.いつまでもこのままではいけないので，なんらかの共通の考え方.少なくとも概念上の共通の枠組みを設定しておく必要があるのではないかというのが，この試案を検討している人たちの姿勢であるよ うに思われますー
その共通の枠組みとはい ったい 何かといえば.

(
1)IEEE の試薬の視点

質の要求仕様をきちんと定め.

まず.ソフトウェアの品質に関して，この IEEE の試案

が，どういう立場でものを考えているのかということから，お話したいと思います

一 般的にいえば，ソフトウェアを使うユーザの視点と.ソフトウェアを作る開発者の視点の2 つがあります.

表 1・2 は，試案の中に書いてある文意を取りだして.日(1)品(2) その仕様にもとづいて適当な指標を設定し.その指標の計測を実際に実施する

そして.

(3) 測ってみた結果.その指僚が妥当かどうかをきちんと検証する.こ う い う 3 つのステップは，ど んな
場合にも必要だろうし.そういうことをやるための方法論を領準的に考えて，そのためのガイドライ ンを与えよう ，ということが目的のようです

本語に訳してみたものですが. IEEE の試案は，ど う やら‑3‑

SeamailVo
l
.3N
o.3‑4

6
t
hS
o
f
t
w
a
r
eR
e
l
i
a
b
i
l
i
t
ySymposium(
2)IEEE 試案のフレ ー ムワ ー ク

録 A には，

図 1 ・ 1 に示してあるのが概念上のフレ ー ムワ ー クです.
これは普からある

McCall や， Boe防n のモデルと同じもCompleteExamples と いう立派な見出しがついています.これは， IEEE の方法論にもとづいて実施されたプロジェクトの完全な実例集ということ です.

その A・ 1 は .国防省関連のあるシステムの実例です.

のですけれども，ソフトウェアの品質を 3 段階にわけています.トップレベルに要因 (Faαor ) があって，それをいしかし， A・2 以下はありません(笑い) . A・ 1 自体もしり

くつかの判 断基準 (Criteria) に分割し，そしてそれぞれ

き れ とんぼで'終わっていて，後ろの方は空白ですの Cri teria に対していくつかの指標 (Metrics ) が対応す

この状態では，る.という階層構造を考えています.

(笑い)

Factor とは.い ってみれば，マネ ー ジャが品質とい うものを考える場合のコンセプトです

Criteria とまだ，IncompleteExample といったほうがよい.作業途中だからしょうがないのですけれども，そういう状況です

Metricsというのは，実際に開発にあたる エ ンジニア ー レベルの問(3) 伊豆で の討論

題です.これ らの 3 つの階層の項目の 聞に.マ ッ ピング(

そうした不満はあっても.この試案を作ろうとしている

対応づけ)を行なっていくのですが，そのための標準的な人たちの意気込みはなかなかよいし，全体の方向もそんなガイドライ ン を示そ うという意気込みは，大変よ いことのに狂っていないという認識のもとに.伊豆でいろいろと議ように思えます.

論をしました.

ただ，伊豆でもいろいろ議論があったのですが，この図

ワークショップの冒頭では . 早稲田大学の東先生におい1 ・ 1 の意味することは理解できる.しかし.実際に品質のでいただいて ， IS0 で現在進められている僚準化の話をしFa ctor として何と何を考えるのか，その Factor はど のよて いた だき，それを IEEE 案と比較しました.参加メンバ

うな Criteri a に分解されるのかが.現在の段階の試案では ，ーの なかには.日本的なソフトウェア QC をや ら れている

まだ具体的なかたちでは述べられていません.

方が何人かいて，そ れ と IEEE 試案との対比とし寸議論もたとえば， Fa ctor に関しては.このようなものがありうありました.

るという例しか示されていません.これもたくさんあり 過

また.伊豆に集まる前に鳥居先生から出されていた宿題

C
r
i
t
e
r
i
a

は，それぞれ自分の身のまわりのプロジェクトを取り上げ，ぎて，素人は困るんじゃないかなと思いますし，に関しても，同じような実例が.何ペ ー ジかにわたって列

そのプロジェクトにおいて，仮にこの 正EE のフレームワ

挙されているだけです.それぞれの間のマッピングは，まークで品質の定量化を 実絡したらどうなるのか.思考実験

だ全然示されていません.

をしてみて，その結果を持ち寄手りましょうとい うこと にな

手続き上のフレームワークは，-品質要求の Establishrnent (確立・設定)っていました.何人かの方が.非常に まじめにそれをやってこられました .

.Metrics 計測の Implimentation (具体化 ー 実施 )・品質 Metrics の Validation (妥当 性検証)という 3 つのことの標準的な方法論上の方イドラインを与たとえば. SRA の松村さんのものは，IEEE 試案の付録 A・ 1 と全く同じことを ， 銀行オンライ ンのアプ リケ ーションについて展 開してみたとい う ものです (SEAMAll..

えることを意図しています.試案の第 5 章に，手続き上のVol2 , No10-12 参照)

ステップ(の名前)だけは，かなりきちんと書いてありまた結果として，当然のことですが.現状のこの骨組みだけすしかないガイドラインでは非常にやりにくい.でき ればガ

伊豆ワークショップの報告書の中では.日本電子計算 の野村さんが，これに従 ってやってみようということから，

イドラインとしてはこの点を充実して欲しい .とい う具 体

的 な要望事項が 何人かの方から出ました

日本語に訳されていますが.しかし，試案の本文を読んでみると，

1 つの項目について l 行ぐらいしか説明が書いて.そういう試みを実際にやってみしかし，それにもかかわらず，こういうふうな標準的な枠組みの存在は，品質に関する議論を展開するためのコミないところが多かったりして，実際のカ'イドラインとしてュニケーション・プロトコ l レとして手ド常にょいということは.まだ不十分だということがわかると思います.

てみなさんの意見が一致したと思います.

試案の最後には，付録がいくつかついています.先ほどの Factor や Criteria の例は付録 B に入 っていますが.付

(
4
)ISO
/
TC97/
SC7

‑
4
‑

.,....

6
t
hS
o
f
t
w
a
r
eR
e
l
i
a
bi
U
t
ySymposium

SeamailVo
l
.3N
o.3‑4

本的 QC はご存じのように.撃の根の QC サークルから少し個々について触れます.

ISO で現在作業しているのは，基本的にユ
立って，ソフトウェアの品質特性 (Fa ctor

ザの視点に出発するボトムアップ形式です.どちらがよいのかというでなく.

ことで.日本の風土では.やはり，ボトムアップのほうがCharaαeristics と呼んでいますが)の標準化をしようというものです.

似合っているという意見が支配的でした.

IEEE 試案よりも数を少なく整理して，次の日本的 QC では.品質特性とか代用特性といったガイド

6 項目にまとめています.

ラインがありますが.それと IEEE の Faαor や Criteria

.F
u
n
c
t
i
o
n
a
l
i
t
y

が.

.Re
l
i
a
b
i
l
i
t
y

た.先ほどいいましたよ う に . IEEE 試案は，現状ではま

.Ea
s
eo
fUse

だ，こうした点で具体性に欠けています .

.Effici 巴ncy

鳥居先生の委員会で，今後日本的な標準化試案を作られ

.Mai
n
t
a
i
na
b
i
l
i
t
y

るとしたら.豊富な具体例をつけてほしい.という要望が

.Po
r
t
a
b
i
l
i
t
y

でました . こうしたガイドブックを読むとき.現場では.

これらの 6 項目を，それぞれさらに複数のCharacteristics に展開し ，

1 対 1 にマッピングできるのかどうかも論議されましS
ub‑

例題編から先に読みはじめます.大学の先生がトップダウ

きちんと標準を決めようというン だとすれば . 現場はどうしてもボトムアップなので，そわけです.手続き上のフレ ー ムワ ー クとしてはCharac­

ういうふうな人たちに使えるような試案にしてほしいといteristics の定義(D efinition).計測 (Me asuremem).

うことでした.

Rating. アセスメント( As sessmem ) というようなモデルを考えています.品質のChara ct eri sti cs の定義を標準( 6)フレ ー ムワ ー クの 重要性化しておいて，そこから後の方は.プロジェクトによって異なるというアプロ ー チです.

といった具合いに. IEEE 試案の現状についてみんなが文句をいったわけですけれども，たとえ不完全ではあってですから.ここでのポイントは，品質の問題を考える場

も，こうした 概念的な枠組み上のたたき台があると.その合に . ISO のようにユ ー ザの観点に立つのがよいのか，あ

上にのっかつて，大学の先生も，メ ー カの OS 開発者も，るいは IEEE のように開発者の観点に立つのが適切か.もパソコン-ソフト屋さんも，あるいはエンド・ユ ー ザのわちろん最終的には両方とも必要なのでしょうけれども.そけのわからない要求に日夜振り回されているアプリケーシ

れぞれの立場にどういう特徴があるのかを，よく見極めて

ョン開発者も . いろいろな立場の人々が，それぞれ自分のおく必要があるということです

事情は事情として，お互いに技術的なコミュニケーションができる(5)日本 的 QC

そのことが証明されたというのが，こんどのワー クショップの最大の収穫だったと思います.

日本的な品質管理との絡み合いでは. IEEE 試案にのっ

じゃあこれからどうするということですが.もちろん.

ている国防省関連の例題(しかも.これが現状では唯一の鳥居先生や'IEE&7)方にがんばっていただきたいのですが .

例題です)が，非常に問題になりました

やっぱりアメリわれわれとしても，いずれは何か出てくるだろうと，ただカでは.何でもかんでもみんな国防省ではないか.同じ受受け身で待っているだけではいけない.みんなの意見をど託開発でも ， 日本では民間企業が相手だし，まして，ソフ

んどん出して，それを IEEE とか.鳥居先生の委員会になトハウスが自分でプロダクトを作る場合だとか，メーカがるべく幅広く吸収してもらおう.今回のシンポジウムも.

OS を開発する場合とかは，かなり事情が異なる.とりあ

そのための場として設定されているのではなし、かと思いま

えずの例題が DOD 1 つしかないということは，どうもこす.

の試案の狙いが少しわれわれの考えているものとは違うのではないか，という話が出ました.日本の QC はもっと幅

鳥居:

が広い.

いただいたのですが，今回のこのシンポジウムで.現場かありがとうございました.いま最後におっしゃてIEEE の試案はどちらかとい う と，ニュアンスとして，らの声をなんらかの格好で吸い上げていきたいと思っていマネ ー ジャの意志決定のもとづいて，ト ッ プダウンに品質ますので，単にお話を聞いて帰るだけでなくて.何でも結の定量化を実施するという形になっています.しかし，日構ですから積極的にコメン卜してくださいー‑5‑SeamallVo1
.3N
o.3‑4

6
t
hS
o
f
t
w
a
r
eR
e
l
i
a
b
i
l
i
t
ySymposium

日本的品質管理とソフトウェア

う少し簡単にすると.石川肇先生の表現を借りれば 「 品質とはユ ー ザの満足度の度合である 」 ということになります.

保田跨通

品質のよしあしを考えるとき ， ハ ー ドの場合ですと，製品の規格がかなり明確になっていて.その通りに製品がで目立の保田(やす だ) で ございます . タイトルがきているか ， ということがポイ ン トです.ところが.規絡

ちょ っ と大きすぎたと思 うのですが.私なりに.わが国にとい う のは ， たいてい後追いになるわけでして . それがでおけるソフトウェア00乃現状を整理させていただきます .

きた頃には，ユ ー ザ

自民国:

ニ ー ズはもっと先の方へ進んでいるといったことが ， よ く 起こります .
ハ ー ドウェアでい う 製品規格は，ソフトウェアの場合に(1) ソフトウェア QC の現状

昨年の今頃です が . 日経コ ン ビュ ー タに掲載されたソフ

は ， 仕様にあたります . プログラムの品質のよしあしは，

トウェア品質管理実態調査とい う 中か ら， 適当に抜き書き

それが仕様書通りに動いているかどうかで判断される . た

してみた の が図 2・ 1 です .

だ.ほんと う の要求仕様が ， ユ ー ザ自身にもよくわかっていないとい う ことがありますので，ユ ー ザ・ニーズがうま
SW 品質管理部門 あり

シ ステム部門 で TQC 実施
小集団活動 の 導入
シ ステ ム 開発 の工程管理

ドキュメ ン テ ーション管理

レビュ ー

基本設計レビュ ー
構造化プログラミ ン グ
プログラムの部品化テストカバレ ージ測定
パグ曲線等でエ ラ ー 統計分析
本稼働後のエラ 一 発生 件数を記録

17%
36%
12%
25%
27%
37%
30%
24%
5%
3%
5%

く 仕様書に取り込まれているかが.かなり大きな問題だと思います

日本的 QC の特徴を ， 石川先生は全員参加 ， 品質第一， 消費者指向.事実

デ ー タで物をい う

欠工程はお客様 」 という一連のキャッチフレ ー ズで示されています

まずは全員参加 」 とい う ことですが.

QC 部門 だけ

でなくて，間接部門 ， 管理部門.それからト ッ プからも積極的な指示も必要だし.担当者からのボトムア ッ プの参加も重要です . これは，いわゆる QC サ ー クルの形て' す .

2 番目の 「 品質第一 J ・よく自動車とかが例にあげられ一稼働後 の平均エラ 一 発生件数 = 0 . 2 件 / KS

ますが，アメリカなどでは.短期的な成果特に利益が優先

国 2・ 1 ソフトウェア品質管理実慾調査されすぎて，長期的にはうまくいかないとい う ことがあります.ソフトウェアの場合，特にそ う した傾向が強いと思

この調査は， 一部上場企業の シ ステム部門を主な対象にしたものです . 総論的にいえば.

.約 3 分の l の会社でいます.不良品の発生による手直しは . 場合によっては，全体コストの半分く ら い占めている場合もあるわけで.手TQC を実施しており ， 品質管理専任者がいるところが 2

直しが少なくすめば生産性は向上するし，納期もきちんと

jlfIJ弱 . 基本設計レビ ュ ー ， 構造化プ ログラミング ，守れるとい う ことで.日本的 QC では.品質第ーが重要なドキュ

メ ン テ ー シ ョン 管理とかは ， 他の にく ら べると高い数字が合い言葉になっています.

でていて.まあまあ進んでいる ， とい う ことができます.
しかし，統計的品質管理 の基本となるよ う な，たとえば，

3 番目 の「 消費者指 I古l J は，マ ー ケ ッ ト・イ ン ともいわ
れます

この反対綴念として.プロダクト・アウトという

本番稜働後のエラ 一 発生件数の記録とか ， パグ曲線とエラいい方があります.メ ー カの技術者は， 一般に自信過剰で ，ー 分析とかの実施度合いが低いのは.ち ょっ と気になるとオレがつ くっ た物はいいのだか ら 使えとい う 傾向があり .

こ ろ ですえてして市場の反発を買います

本当にお客様がなにを欲しているのかをよ く 調べなければな ら ないということです(2) 日本 的 QC のアアロ ー チ

ソフトウェアの品質 と は何 か とい え ば ， それは 「 ソフトウェアまたはそれがもた ら すサ ー ビスが利用者の目的を満

4 番目の 「 事実 ・ デ ー タで物を 言う」 は . ソ フトウェアの 場合はなかなかむずか し いと思いますが.事実をよく見るのは大切なことだと思います .

たしているかど う かを決定す る ための評価 の対象となる固有の特質および性能の全 体 」だ と定義されます ー これをも

それか ら 最後の次工程はお客様 J とい う のは . お客と直接接触している営業第一 線 の 人以外にも.マ ー ケ ッ ト

‑
6
‑

6
t
hS
o
r
t
w
a
r
eR
e
l
i
a
b
i
l
i
t
ySymposium

SeamailVol.
3No.3・4

日本では，ソフトウェアを作るときに工場制 度を 導入し指向の感覚を身につけさせるために，次の工程をお客様だ

ハています.いわゆるソフトウェア・ファクトリです.このード ウェアの場合ですと.明確に ， 設計-製造 - 検査とか特徴は，品質 ・工程-原価の 3 要素を，それぞれ別の部署分かれていますが，ソフトウェアの場合は.多少手工業的で管理できるということです.それに対して典型的な欧米に自分て'やってしまいますので，次工程というのがピンとでのやり方は，プロジェクト制度でして，日本でもソフトこないのかもしれませんが.少なくともやるべきことをや

ウェア・ハウスて'はかなり取り入れられているようですが .

るべき時にきちんとやっていく.という意味にとらえればほとんどの管理をプロジェクト・マネージャが統括していいいのではないか.と思います.

ますと思って責任を持ってやりなさい.ということですね

管理とはどういうことかを.正面き って いうのは難しい

ソフトウェアの検査は，最近かなり普及してきているよ

わけですが目的を継続的に効率よく達成するための活うですが，これにもいろんなレベルがあります.ここで検動 J とい う ふ う に考えます . そのために . いわゆるデミン

査というのは . 日本的 QC の枠組みにおける検査 を 意味し

グ・サークル Pl a n- Do・Check-Action を う まく回していくており.開発部門や設計部門とは別に.検査部門で行なうことが必要です . 特に. Plan- Do は当然やらなくてはなり

もののことです . この検査部門がラインの最終過程を担っCheck & Acti on をするとい うのが .日本的ませんが.

ており.品質保証活動の要になります.
次に中間品質管理ですが，テスト工程において，不良率

QC ミソだと思われます

を中心に考えた QC 的な管理が，日本ではけっこううまくやられているよ うです. 欧米の場合は個人主義的な色彩が( 3) 日 本的ソフトウェア QC の特徴

以上はふつ うの QC 談義てぺ格別問題はないと思いますが ，ソ フトウェアにおける日本的 QC ということになると，さまざまな意見がありえます

強く，個人が不良率を出したがらない，デ ー タがなかなか集めにくいという話を聞いたことがあります .
それから，先ほどいいましたように，日本的 QC は，ラ

以下に申し上げるのは.私

イン部門の全員参加という形で進められますが，欧米の場なりの少し独断が入った考えて'す
日本的なソフトウェアの QC は，どちらかといえば，メ

合には，品質管理スタッフという専門職がいます.その人

ー カが従来の品質管理を 導入したのとおなじような状況を .

たちは非常によく勉強しているのですが，いわゆるスタッ

あえて想定した上で進められています

フ意識が強いように思います.

図 2・ 2 に，ソフトウェアの品質管理の特徴を，欧米と日本とで簡単に比較してみました.

( 4) 検査のあり方

JIS で定義している検査は，非常に限定的な意味になっ日本ていまして，最終的に合否の判定をすることを指していま

欧米

工場制度の導入

プロジェクト制度

3 権分立

プロジェクト

マネージヤ

すが.テストと検査はどうちがうのかという 質問 をよく受けることがあります.これは，図 2・ 3 を見ていただけれ ば(品質 . 工程，原価 )

検査の導入

す.ソフトウェアの場合には，テストという言葉があり ま

日本的検査の 概念なし

わかるでしょう.

-実 際の検査行為によるテストも検査も，その技術的な内容は，プログラムの静合否の判定

的または動的な特性を調べることです.ここに.パグとい-品質保証活動のかなめ

中間品質管理うものが絡んできます.テストの目的は.それをなおすこ
品質デ ータ 収集が困難- テスト工程の不良管理ライン部門の活動が主体

品質管理スタッフ主体

QC サクルの導入なし?

国 2・2 ソフトウェアの品質管理の特徴とです .一方，検査の場合は，最終的に合否を判定すること，つまり悪い製品は外へ出さないという 判定が目的です.
ここが違うんだと患います.
したがって，検査がどうあるべきかを考えると.合否判定を公正にするために，検査部門を設計・製造部門から独立した組織にしないといけない.この独立組織のよい点は，お客さんの観点に立った検査を行なうことができることで‑7‑

SeamaUVol.3No.3・4

6
t
hS
o
f
t
w
a
r
eR
e
l
i
a
b
i
l
i
t
ySymposium

す.所定の基準をクリヤーできない製品は合格させないわ

いえます

図

2・4

に例をあげましたがPlan-Do­

けです.

Ch
e
c
k
‑Action で，テスト工程だけで閉じた形で書いてい
ます.
項目

説明

検査組織

製品の合否判定を公正にするため，設計製造部門から独立した
組織とする
検査の職務

1
) 顧客の立場に立った検査を行い，所定の品質に適合しない製品を合格，納入させないこと
2) 製品納入後も，顧客の立場に立って，品質を保証するための活動を行なうこと
検査の活動範囲

1) 社内
工程別検査
-基本設計から最終検査までの品質管理の総まとめ

2) 社外
品質保証活動顧客ニズ，クレームの窓口
国 2・4 品質目標値管理の 概念

国 2-3 ソフトウェア検査のあり方
積軸に日程を取っていますので ，コンパイルが終わって検査部門に.このように強い権限を持たせた場合には.

テストをはじめるという時点が，工完となっています.縦それなりの責任も与えなければいけません.たとえば，目軸は累積のパグ件数をとっています.そうしますと.かな

立の場合には，ソフトウェアの出荷を承認した検査部門が.

らず上 昇曲線になるわけです .

顧客に対する責任を取るようになっています.品質保証の窓口としての役割を担当しているわけです.

ここでは不良だけに限定していますが.最初の Plan の段階では，目標値を決めなくてはいけません.どう決める

もちろん.パグ(クレ ーム)が出たら，そ れを実際になかは少し難しい 問題 ですが，まあ，エイヤでもいいから.

おすという作業は.あくまでも設計・製造部門がやります.

ともかく「不良摘出目標値」を決めなければいけない.

検査部門は，ソフトウェアを自分でいじってはいけません.

その後.実際の管理作業には.工程がかなり長いですか

お客さんに対して一定の品質を約束し，迷惑をかけないよら，ガ イドライ ンが必要になります.ハードウェアでよくうにするために，社内でのフィードパックをきちんと組織やっている管理図や管理限界とに相当する考え方をとって.

的におこなう部署として，存在しているのです.

管理曲線を設定します

パターンとしては S 字形です . こ

社内における工程別検査は，ハ ー ドウェアの場合は，いこにある程度幅をもたせて，上限-下限というように目標

ろいろな部品の検査に相当しますが，ソフトウェアの場合値に対してカーブを摘きます .ここまでが Planning にあには，たとえば，設計段階での中間生産物としての各種ドたります

キュメントを検査するという形になります.最終的な検査

そして.テストが始まったら，結果をプロットして行きとしては，単なる選別検査でなく.基本設計から寂終検査ます.その後.結果をどう評 価 して行くかですが.管理限までの品質管理の総まとめをおこないます.

界を飛び出ている場合は 警告を出します.ここで難しいの社外に対しては.品質保証活動があります.本来顧客のは，品質がよいからパグが出ないのか，それともテストをニーズを聞くためには別の部門があるのですが.クレーム

さぼっているのかが.よく判断できないということです.

処理に関連して，お客さんと折衝することになりますから，ニーズも含めてあわせて吸収していくようにしています.

ただ，実際には，デ ー タをちゃんと取っていれば，だいたいわかります

中間工程の品質管理というのは ， 比較的分かりやすいと‑
8‑

それでも水郷け論になってきて，検査・SeamaUVol.3No . 3・4

6
t
hS
o
f
t
w
a
r
eR
e
U
a
b
i
l
i
t
ySymposium

設計両部門聞の力関係で決着がついたりします.そのさい.

といって，それを簡単に技術力の不足だと総括するのは，一種の抜取り検査を事前にしておき，これだけあるじゃな

いけないと思います.

いか，と証拠を見せて納得させるやり方も考えられます.
いずれにせよ ， ここでCheck をしているわけですね.

( 6)品質偲能展開の考 え 方

よいソフトウェアとは何だろうと ， 正面きっていわれる

最終的には，さ ら にActi on が必要なのですが，それは品質向上施策になります.ここで諦めてはいけないので，パと，なかなか答えにくいものです.さきほど ， 品質の定義

グが出てきた ら ばいろいろとフ ォ ロ ー をします

は，ユサ'の満足度だと申し上げました.それでは満足度

図 2・4 に示した例程度な ら いいの ですが，すっと気持ちとは何か，とさらに突っ込んで考える場合に.日本の oc

よくパグが伸びて行く場合は問題で(笑い) ， 不良目標値

運動のなかで発明されたのが，品質機能展開といわれるやがおかしかったのではないか，フ・ ロセスの過程に問題があり方です .

品質検査あるいは保証をしっかりやって，ユーサ'からのったのではないかとか，いろいろフィ ー ドパックして行かなければなりません

これが典型的なソフトウェア開発に

クレ ー ムを う まく組織内にフィ ー ドパ ッ クし，不良の再発を防止することは，たしかに大切ですが ， それだけでは .

おける品質管理です .

たとえば新製品開発のよ う な場合には.ちょっと困ってしまいます . そうしたことから考え出されたのが，品質展開(め再 発防止

不良の再発防止が大切です . 私の考えて'は ， 日本的 oc

です .

これは.基本的には.図 2・ 5 に示したような設計アプロのポイントはこのあたりにあると思います.

要するに，フィ ー ドパ ッ クをきちんとして，本質的な原ー チにたよって，ユ因をきちんと直していこうということです.どういうふう

うという考え方です .

ザ ・ ニ ー ズをきちんと把復して行こに考えればいいかといいますと，プログラムの問題ではな

く ，プログラマの問題ではないかと考える.さらにいえば，' " ・".1Jfi'J2.:ï12L ! ::t ~ I.J:"ι77- r:l_ニ二三とプロセスをきちんとなお し ておかないと ， 類似の不良が再発することは防げません.
そのときの基本的なアプロ ー チは，不良をどうして作り込んでしまったのかを徹底的に追求して行くことです事

ふ旦U!})， !I

前に発見できなかったことに問題があるわけですから，そ守~)j ~ =:.~,', ~ ，I) :J ;1' 己 1 こ i i:'苛 111

I: '， t 口 1 1"1 '. ， J 二守7- ' コ ニ=. -:1子

れはなぜか?という問いかけが必要なのです . そのさい，

三予五己2二!主主 1"1 :) アプ口ーチ， 向子 I)Îf~~二乙コ':'t:1_二ニヌー

あまり精神論にならず ， 制度や仕組みのレベルで改善していけるほうが望ましい.

国 2-5 品質展開のアプロ ー チとはいっても，ソフトウェア開発の現状を見ると，非常に人聞に依存している部分が多く.いくら仕組みゃ規則をチェックリ

ソフトウェアにおける品質機能展開の具体的な手順も，ストは立派なものがあるのに.いいかげんに O をつけると最近いくつか試みられています . ここでは，今年の 3 月.

い う ようなぐあい(笑い) . 規則なんて，作り出したらき

IPA 技術セ ン タから出された報告をご紹介しておきましょりがない.あまりないほ う がいいわけて'すう . 図 2・ 6 がその概念図です

作っても，すぐ抜け道を見つけられてしまう

まず，ユ ー ザの品質に対する要求を定め.それをユ ー ザとすると，基本的にやらなければならないのは，規則以前の問題になります . いわゆる 「 しつけ J だとか，教育とが理解できるコトパで書くことから始まります.これはいった側面も重要になってきます .

IEEE 試案でいっている Fa ctor ， または ISO でいってい個人で仕事をしているな ら. これは単に技術力の問題でるCharaαeristics と同じレベルて'す.

しかし . 組織て'やっている場合には . 制

次に . それらを.実際にソフトウェア開発者が計測でき度とか仕指けとか技法だとか ， いろいろなカバ ー の仕方がる特性に置き換えてやる必要があります.代用特性を決め.

あるはずです.個人ができなか っ たり . 知らなかったから

その一覧表を作ります . ユ ー サ'視点からみた要求品質またしかありません

‑
9
‑

6
t
hS
o
f
t
w
a
r
eReUabil1tySymposium

SeamaUV
o
l
.
3N
o
.
3
‑
4

は品質特性と，代用特性とは，そもそも見方が違うわけでベルまでプレークダウンすれば.ユーザにもわかりやすい

すから，一般的には，両者は M:N の関係にある.つまり，Metrics への対応づけが可能だろ う と考えています

マトリックスによる表現が必要になってきます.

ろん，それは必ずしもツリー構造ではなく. M:N のマト

それをあらわしたものが，品質表といわれている も のでもち

リクス形式になるでしょ う.

して . 要求品質を 縦軸に.代用特性を 横輸に書 くことによって，それらの関係を示します.また.特定の工程において.代用特性はどうい う ふ う に測定し，チェ ッ クするかを

dち q堅，そ-ノ v 左竺 Cて):;>寸".-:

S:
) '
r
:D

具体的に管理項目によって示したものを . αご工程表とか，
期日管理工程表といいます .

" 'l:' ':"':'

CI'! .. 1 :"r . IS ' i:!

f 品-:;: )宜埠ε')1

1. J(喰百島お

広竺J 人

品宜呈

邑豆三三

ここまでくると，あとは ， それらを実際の開発工程に適( ;，;寛容 かラ。た 埠 宝 }用して行くだけです .

o. ・ !; :
'Y

十戸

~

( 品 宜 副主尺左 }ー-:是【主 。 )

ソフトウヱアの ~ rú :~ !~ !Hl 些 !i自己主!三 !jn

( ë:)

正

J毛

. '司

:
S
O0?912) :'0士\(a:1! ;)u&!
.
!
:y f-'\I' : ' C:' II:.U :J,e.s

守主

長量管理

μ; ニ酷
二i'!'ヲ z )sに坦/7:;115=7月二 J )ニ.0 円 051 "'.:2J. 0・tτ ~:..na . rd : ・ :5 ，:-:" . ;-・ h ・ ~，: y'1 .:::,.:.:.

(i三:: :)..，1 ・ lJ. : ylla:::- ，:，:， S :... nO ar r!二 0 :'; 1:':'.. )[奴]

国 2・7 品質モデル悶の対比[;ロ](7) 終りに

ソフトウェアにおける品質管理の歩みを振り返って見ると，最初は品質なんて考えずにとにかくものを作っていた.
そうすると，いろいろ故障やクレ ー ムが出てきて，これは大変だということになった.そこで ， いろいろな対応の仕方があるわけですが. 1 つの対策として，ハードウェアの製造と同じよ う に，検査をきちんとやろ う じゃないか，というアプロ ー チが考えられた .
国 2・6 品質徳 能展開の手順

検査の目的は出荷品質の 向 上て'あり.選別検査的な色彩が強 い

それを 最終工程でやり . 悪いものは関所を通さな

さて . IEEE 試案のフレ ー ムワ ー クと，この品質徳能展

いようにする.そうすると，工程遅延だとか，開発効率の開との関係はどうかといえば. Factorはほぼユ ー サ'のレベ低下という現象が出てきます. 一応品質だけはよくなるが ，ルの品質要求に近いという対応づけができそ う です .

Cri‑

それでは企業として困るし ， お客さんにも迷惑をかける

teria はあんまりはっきりしませんが.開発者向けというそこで，もう少し前工程でやろうじゃないか，というこ意味でほぼ代用特性と同じではないかと思われ ます . そしとになります.かなり前のほうから不良を摘出して品質をて. Me出cs は具体的に計測するものですから，管理項目上げて行くに対応するのではないか . こんな対応づけができそうな気品質も向上する . ただし，不良を作りだすプロセスには目がします .

をつぶっておいて ， 結果を漏らさずチェ ッ クしようという一方 . IS0 でいまやっている作業は.

IEEE 試案のやり方とは違って.ソフトウェア品質とい う ものの内容を .
ユ ー ザの視点に立って標準化しようとい う アプロ

そ う すると，かなり工程的にも安定してきて.

ことですから ， ライフサイクル全体で見れば別ですが，各工程の開発効率は逆に落ちる場合もある.

チです .

したが っ て.その次のステ ップとし ては . 設計の品質をそこでは.品質特性つまりCharaαeris ti cs を 6 つに絞上げて行こうということになります.つまり，事後のチェ

りこんでいますしかし，これだけではあまりにも大まか

ッ クではなく ， 事前にあるレベル以上の品質を作りこんですぎるので ， 直接扱いに く い .そ こで，いま日本案では.

行こうという考え方です.こうすれば，かなり開発効率は21 個 の上がってきます.

Sub- Charaαeristics に展開しています . このレ

‑
1
0
‑

SeamaUVol.3No.3・4

6
t
hS
o
f
t
w
a
r
eR
e
l
i
a
b
i
l
l
t
ySymposium

しかし，問題は一番最初にいったように，ユーザの満足度を満たすということですから.それだけではまずいわけて必要でしょう

ただ単にユ ー ザ満足度といっているだけ

では無理じゃないかと思うのですが .

で，品質 機能展開のような形でユーザ ・ ニーズの正確な把握に努力して行く必要があります

そうすれば.いろいろ

A: ISO の 6 つの Charaαeristics には.

Mai
n
t
a
i
n
a
b
i
l
ｭ

付加価値を含めて，多少の円高ても売れるような製品が作

ity とか Portability が入 っている.これはやはりライフサ

れるようになるでしょう.

イクル的にみて，最終的にたぶんそういうものがいるだろうという考えて'す.ただ，具体的にどう展開するかは ，これからの課題になっています( 8) 質疑応答

Q: プログラム品質のチェ ッ クについてですが.日本でも，プログラマとい うの は ， 自分が作ったプログラムのソー ス・コードをチェ ッ クされることを非常にいやがる傾向がある.そうしたことに関して ， 何かお考えがありました
ら お聞かせください.

A: ユーザの満足度を得るとい う のは . 確かに大切なことではありますが.ユーザがもし完全に満足しきってしまう と.企業としてはも う その次の製品が売れなくなる

それでは会社が潰れてしまうという困った状況が生じるわけで(笑い) .会社を長続きさせながら.そ れなりのユ ー ザの満足を得て，社会に貢献していかなければいけない .
たとえば ， 保守性を問題に するときには，どちらかとい

えば，ユーザ視点というよりは.開発者の立場からみて .
表面に出てきていない特性をどういうふうに扱って行くかということになります.これは，メーカ側としてはかなり真剣に考えなければいけないことです.

しかし，保守のことを考えてうまく 構造設計をやりなさいということを.あんまりしつこくいってソース

コー ドを点検したりすると ， プログラマたちは，たしかにいやがります . 問題は.それにどんな意味があるかということを.
う まく動機付けして.かれ ら 自身が . これは何とかしなければならない.と思うようにも っ て行ければいいわけです .
それが QC サ ー クルなどで可能になる.ただ，漫然とサロン的にやっているだけですと.企業目的に合わなくなってくるといけないので，ト ップ ダウン的な方針は必要だろうと 思います .

Q: ユーサ'の満足度についてて'すが，ただ満足度といってもよくわからない . そ う すると.何 ら かの代用特性を考
えて行かなければな ら ない恥πτRまその 1 例でしょうが，

他にも.システムの生存率(どのくらいの期間 ， 際能とか性能とかが満足できるか)とい っ たもので . 長期的にユ ー

ザの満足を高めるとい っ た配慮も.高信頼性システムとし

‑
1
1
‑

6thSoftwareR
e
l
i
a
b
l
l
i
t
ySymposium

ソフトウェア・メトリクスとモデル

SeamaUVol.3No.3‑4

アルゴリズム)ほど複雑 だという単純な考え方です . メモ

リ・スペースも ， ときには問題にされますが.だいたいは大場充

計算時聞が尺度として用いられます .
この評価は，アルゴリズムを記述する言語のレベルに依大場 ;私の用意してきた プ レゼ ン テーションのタイトル

は ， 事前の案内とは少しちが っ てソフトウェア・メト

存しないことが必要です . たとえば，チュ ー リング

マシンを用いて ， アルゴリズムの動的な複雑さを評価するといリクスとモデル 」 です . そ う い う ことでお話しさせていた

った具合いです . 実際.ソ ー ティングとかのアルゴリズム

だきます .

になると.たぶんこうした方法でしか評価できないて'しょっ .

( 1) プロ グラムの大きさと復縁さ次に ， 少しいいかげんでもいいから.ともかく，人聞がメトリクスは ， 基本的には管理のためのツ ー ルですが.

どれくらいの労力(頭)を使ってそのプログラムを作ったも う 1 つ大きな目的があ ります . 何か新しいアイデアが浮かを， 簡単に知 ることはできないかとい う ことで出てきた

かんだとき . それにもとづ くプ ロセスやそこか ら 作られるのが，静的な複雑性の考え方です.

ソフトウェアが ， どれ くら いよ い も の になりうるかを，き

これは，ふつ う の文章の評価 とまったく同じよ う な啓じ

ちんと評価することが必要になります . メトリクスは，そで，プログラムを評 価 してみよ う というアプロ ー チだという した評価のためのツ ー ルでもあるのです.

えます.その裏にある考え方は.見た自に複雑なプログラ

そ う い う 観点か ら 考えると，重要なメトリクスの第 1 は ，

ムは複雑だ.ということです . つまり. LOC を この観点プログラムの大きさです . ここでいうプログラムとは.単で解釈すれば.行数が 多ければ多いほど難しいプ ログ ラム

なるソースコードよりも う 少し広い意味で.その裏にあるだということになります.

ものも含んだソフトウェアの大きさをど う やって測るか，

この種の評価は .プログラムをどういう言語で書 くかでということです . 大きさという 概念も少し比喰的で.複雑

大きく変わってしまいます. Pro10g で書けば 3 行ですむ

さとか，そういったものも含んでいます . 生産性や品質のプ ログ ラムが . Pasca1 でば 1∞ 行になるといったことは，

メトリクスも，この大きさにもとづいて定義されます.

ごく自然に起こります.だから，言語が変わると 簡単にはプログラムの大きさについては，いくつかの古典的なメ
トリクスがあります . たとえば.

適用できない.言語別に考えて行かなければなりません .

LOC(
L
in
eo
fCode) とか ， ステ ッ プ数などです.生産性て' いえば .

1 日に何行書(2) 複緯さの尺度

けるか ( LOC/Programmer Day) とか.品質でいえば，動的な複雑さは少 しむずかしい問題を含んでいる ので，lα)() 行当りのエラ ー 数 (Eηor/KLOC) などがおなじみ

ここでは省略しま す静的な複雑さ の尺度として，こ れまです .

でどんなものが考えられてきたか，有名なものをいくつか

しかし.これらはあまりに古典的すぎて.その有用性は，紹介します.

今日ではも う .ほとんど疑問視されています.それでは，
他にいったい何があるかということになりますが.大きく(
a)Halstead のソフトウェア・サイエンス指額

分けて，次の 2 つのものがあると思います.

あるプログラミング言語で用意されているオペレータ(
足し算記号の+その他)の種類を n とします.そして実-動的 な複雑性
アルゴリズムの評 価
静的な複雑性:プログラムの評価

際にプログラム中におけるオペレ ー タの出現個数を m とします . 一方.オペランド(つまり変数とか定数とか，プログラマが勝手に作り出す記号)の種類を N とし，その出現個数を M とすれば ， プログラム複雑さ C は次の式で与えられます:第 1 は昔からある考え方で動的な複雑性 」 という表

C= m 10
gn+M 10gN

現を使っていますが， 一般的には ， アルゴリズムがよし、か悪いかを評価するものです . 計算時聞が長いフ・ ログラム(

‑
1
2
‑

SeamailVol.3No.3‑4

6thSoftwareR
e
l
i
a
b
i
l
i
t
ySymposium

この式を基本として，ほかにもいくつかのパリ エ イションはあり ますが，これが Ha lstead のソフトウェア・サイ

オ ペレータ

出現個数

be
g
i
n

4
4

巴 ns

エンス指標と呼ばれるものです.背後にある考え方は，プ

f
o
r
i
f
t
h
e
n

ログラムの中で . どれくらいの語いを使っているか，語いが豊富であ ればあるほどむずかしい プ ログラムだというこ

巴lse

とです

1
l

1
1
3
l

たしかに.ある意味でそれはいえるでしょう.変数の種類が多ければ，それを頭の中 に考慮に入れながら.プログ

ラミングし なければならない のは たしかです.

+

1

[
]

l

1
8

図 3・ 1 に 示す Pascal の 簡単な プ ログラムを見てみまし表 3・2 オペレ ー タの出現個数

ょっ

b巴gin

一方 オペラ ンド とは，先ほどい ったよう に ，プ ログラマ

0;xが勝手に定義した変数名やコ ンスタン トを指します

図3 ・ 1 のプログラムでは x とか a とか y とかです

それらの出現個数は.表 3 ・ 3 のようになります.

f
o
ri= 1
beg
i
n
y;= a
[
i
J
;

i
f ..t
h
en
be
g
in

オペランド

出現個数

x
a
y

3
l
2
2

1
。

1

l

l

1
0

x;
= x+y
;

表 3.3 オペラ ン ド出現 個数

end
e
l
s
e
beg
in

以上の 価 を先ほどの式にあてはめて.プログラムの復雑性 C を求めると :

e
nd;
C =1
8l
o
g1
0+1
0l
og6
e
n
d;
となります
この Halstea d の指標については，これまでさまざまなend;
国 3.1 簡単な P a s cal のプログラム

実験 が行われ，いくつかの相反する結果が導 き出さ れ ています .

この場合，オペレータとは.たとえば beginとか end とか，言語のしたがって ， その有用性については，まだ . いろい

ろな議論があるところですS卯tax で決め ら れているものを指します.

for , if , then , else ,+, []，などもそ うです . 出現個数(b)McCabe のサイクロマチヲク重量
次に .

とは，そ れ らが 何回 プ ログ ラム 中にあ らわ れるか ， その個数を勘定したものです.表 3 ・2 に 示すよう に，その合計は18 に なり ます

もう 1 つ有名な指標は， McCabe のサイクロマチ

ッ ク数と呼ばれるものです . これは ，グラフ 理論でい う オ

イラ ーの定義を鉱張して使ったものです .プ ログラムを無向グラフであ ら わしたときの ，辺の数を e ，ノ ー ドの数を

‑
1
3
‑

6thSoftwareReUabl
UtySymposium

SeamaUVol.3No.3‑4v とすれは，プログラムの複雑度 C は，次の式であらわさ

その点でちょっと正確さに欠けるのではないかというのが，れます.

多くの人々の実感でしょう

C=e‑v+2(3) 生産性や品質の尺度

生産性というのは非常にむずかしい問題て\いまのとこ
図 3・ 1 のプログラムを例にとって考えると，図 3・4 のようなグラフが書 けます .

ろは，プログラムの行数を開発にかかった工数で割るぐら
いしか表現手段はないんじゃな L 、かと思いますが，本来は，ある生産工程に投入した資源と，得られるアウトプットの比が.生産性の定義ですから ，次のよう な式であらわされなければなりません:

生産性 = 成果物/投入資源

問J

しかし，ここで分子のほうが問題で .ソフ トウェア開発における成果物の量をど うやって 測ればよいかが，まだわ
かっていない.オブジェクト ・ コ ー ドの大きさとか.

LOCとか ， いろいろな指標はあるが.どれも適切でない.そこで. Halstea d や McCabe など. ~、くつかの提案がなされてきたが，まだ ，どれをとっても問題は残るというのが現状です .

そして.次に品質ですけれども，保田さんのお話にもあったように，品質というのは，徳能性.信頼性.操作性，
国 3・4 プログ ラ ム・グラフ

効率性 . 保守性，移値性，導入容易性といったいろいろな要素からなっています.

ここには.辺の数が 7 つ，ノードが 6 つあります.これを先ほどの式にあてはめると.

これらのうち. 11霊能性とか，信頼性，操作性が品質の才構成要因だということは ， 誰がみてもわかる.ユ ー サ' にとってもはっきりしています.また，保守性や移植性も，比較C = 7 ・ 6+2

的わかりやすい概念です .しかし. 導入容易性になると，前の 4 つ程クリア ーではありません.

ですから，複雑度は 3 ということになります

この複雑効率については，先ほど代用特性というお話がありまし

度 3 の意味ですが.オイラ ーの定義によれば，外側にたが.そういう目で見ると，スループットとか応答時間.

Bound されない面を含めて，図 3・4 に示したように 3 個

またはメモリの使用量などの指標を用いて，より具体的定の面があるということです.

義できます

構造化プログラミングの場合には，この解釈があてはまというより.開発者の立場から，このような評 価 が可能なわけです.

りますが ， オペレーティング・システムなんかのように
あんまり構造化されておらず.

GOTO 文がいっぱい入っ( 4) 信額性の評価たプログラムでは，グラフがよじれたりして平面になりませんから，視覚的な解釈はむずかしくなります .

ところで ，今 回のシ ンポジウ ムのテーマである信頼性についていえば，プログラムの複雑さは.その信頼性を測る

このモデルの問題点は，プログラムを無向グラフとしてCriteria または代用特性だと考えられます.つまり，複雑考えているので. if 文も do 文も for 文も，全く同じよ う

なものほど信頼性が低くなるという経験則があるからです.

に評価さ れ てしまうということです.エラを引き起こす具体的なメトリクスとして何があるかといえば ， 先ほど可能性は. if よりも do とか for とか whil e のほうが高い.

紹介したサイクロマチ ック数があります. これは IBM に

‑
1
4
‑

6
t
hS
o
f
t
w
a
r
eR
e
U
a
b
i
l
i
t
ySymposium

おける経験ですけれども.

1 モジュSeamaUVo
l
.3N
o
.
3
‑
4

ル当りのサイクロマ

います.そ う すると ， 最初のリリース時点で，大体何個ぐ

チ ッ ク数が 30 以上になったら危ないとか，そういうこと

らいの残存パグ数て' あればユ ー サ。が満足て'きるか . というがい え る .

ことがわかっているわけです

テストがどれくらい行なわれたかとい う ことも，信頼性

ユ ー ザが限定されいる場合や . 稼働環境が限定されていを計測するメトリクスとして.非常に大切だと考えられまる場合 ， たとえば，軍用システムとか銀行のアプリケー シ

すもちろん，テストだけで信頼性を保証することはできョンとか ， 電話の交換機のソフトなどは.一般に.かなりませんが ， 信頼性の向上にはかなり寄与しています .

M口下 が長いよ う です . Bell あたりの交換機のソフトのこ の テスト充分性とい う 指標の裏にあるのは何かといえ場合，恥πτ下 が 20 年とい う よ うな 規定になっているといば ， それは . テストが不充分だと信頼性が悪くなるとい う

う 話を聞きました .

仮定 です . これはきわめて自然な 考え方ですね.もちろん，

いずれにせよ.メ ー カやソフトウェア ・ ハウスの立場で最初か ら プログラムがよければ別ですが， 一般 的にはそう

は ， 何らかの形てヘ 自分たちが作っているソフ ト の信頼性でもないので，テストが不十分だと.ど う してもエラ ー がを予測しなければいけない.そのさい.何が手がかりにな

残 っ てしまい ， 信頼性が悪 く なります.

るかといえば，開発途中で測定した島町τ下 とか，発見さそれでは ， テストの充分性をど う や っ て測るかといえば ，れたパグの数が，時間と共にど う 変化してきたかを見るぐ

みなさんよく御存じのテ ス ト・カバレ ー ジ指標です.ブラら いしか，今のところは手がかりがなさそ う です . ひょっ

ンチとしたら ， 将来もっとよい信頼性推定指療が見つかるかも

テストのカバレー ジ指標が 85% 以上にならなければ ， エラ ー が残る危険率が高いという経験則があります.

しれませんが，現在 は こ う したものに頼らざるを得ない.

また，ユー ザの観点か ら よ く 使われているメトリクスの先ほどの保田さんのチャの 1 つに ， ~灯τTごがあります . これは . ある故障が起きても，その 1 つですね .

か ら.つ まりあるバグが発見されてか ら， 次のパグが発見

開発過程の中で.テスト・フェイズを考えて見ると，テされるまでの時聞を測 る ものです .

ストが始まった時期はエラ ー がたくさん出ますから.エラ

これは ， 単にパグの数だけでなく ， ユーザの数やフ・ ログ
ラム の 使用頻度に関係します

トにあった累積パグ数というの

い くら パグがあっても，ー が発見される時間間隔(恥訂τF) は短い . そして，テス

1

トが進むにつれて.残存パグはだんだん減ってきますから，

年に 1 回しか使われない プ ログラムな ら ，パグは 1 年に 1

その発見間隔は長くなってきます.ほとんど理想的なテス

回しか見つからない.しかし，

トができれば， MTτ下 は無限大に近くなり，まあ次の 1 0

1 万のユ ー ザがいて.それぞれが毎日 8 時間とか 1 2 時間使 う プログラムだと.パグ

0 年くらいは新しいパグは見つからないだろ う というのがの数がかなり少なくても，毎日のよ う に新しいパグが出てソフトウェアの世界ですね.ハ ー ドウェアの場合はそれとくるはちがって，!VπτEごはテスト時間に関係な く だいたい一定

明 ら かに ， ユ ー ザの立場か ら すれば.

恥πτ下 が一番わ

かりやすい信頼性指鎮でしょ う. しかし ， !VπT下 は各ユ

ですね . ある時期がくると部品の劣化でわ っ と唱える ， こ
れがハ ー ドウェアの信頼性の特徴です .

ザ特有の環境に依存する の で ， メ ー カとかソフトウェア ・
ハ ウスとか，ソフトウェアを供給する立場か ら 見ると，か(5)モデ ルについてならず しもよい指僚とはいえません.特に ， 不特定多数の
ユ ー ザが存在する場合には，非常に危険です

たとえば os のように，不特定多数のユーザ向けにたく

メトリクスを考えるさいに重要なことがらは，ただやみ
くもにデ ー タを収集し，そのデ ー タに合うような適当なモデルを探してきて . それで問題を論じるとい う 慾度は，非さん出荷されるソフトウェアの場合には ， 将来を通して何

常に危険だということです . H.Mi lls は.それを個 くら いエラ ー が発見されるだろ う か，ということが問題

Metrics と呼んでいます . 何かわからないけれどこ う なる.

になります . 愚初にリリースするとき，何が手がかりになでもグラフを錨くと線がこう引けるから，こんなことカ旬、

るかといえば，過去の経験です .

os には，

15 年とか 20 年といった長い寿命がありまえるのではないか . といった議論は ， 結局何にも説明していないのと同じだ，というわけです.

すの で ， 以前の os が ， リリースされてか ら 20 年の聞に.
何個 く らいのエラがみつかったかとい う デー タが残って

Psude

やはり ， そこには何かの理由づけが必要なのです . たと

えば ， ふつ う にプログラムのテストが終わった時には，

‑
1
5
‑

1

6
t
hS
o
f
t
w
a
r
eR
e
l
i
a
bi
U
t
ySymposium

SeamailVol.
3No.3‑4000 行あたり 20 行のエラーが残っているといわれます.

雷相互の聞に独立性が仮定されていますが.現実はそうで

それは，確かに今までの経験ではそうかもしれないけれどはありません.

も，いま自分がやっているプロジェクトにとって.何の説

os をテストする場合を考えてみて下さい，たくさんの明にもなっていない.そこで，モデルという概念が必要にバグがありますが ， まず IPL のテストを終わって.そのパなってくるのです

グを取り除かない限り，他のテストには進めません.この簡単な比倫で説明しましょう

敵陣と味方の陣地の聞にように，パグのありかたに関係がある.あるパグが発見さ地雷原があり，この地雷i原をわたって敵陣を攻撃することれない限り，次のものが見つからない.プログラムのあるを想定してください.

実行経路の上に 3 つのパグがあったとします . 一番エント

ここで，いくつかの仮定をします . 攻撃の兵隊さんは 1

人ずつ出ていきます.そのさい.前に行った兵隊さんと次リーポイントに近いパグがとれない限り，残りのパグはとれないのですねこういうふうに，パグの見つかる順序がにい行く兵隊さんは関係がない.どういうふうな道をたどある.それぞれのパグは独立ではないのです.しかし.テるかというのは.基本的に独立であると考えます.また.

ストが進んで，パグの数が減ってくると独立性が高くなっ兵隊さんは任意の瞬間どちらを向いていてもよい.しかし.

てきます.

ある時間間隔をおいてスナップショットをとったとき，常つまり.ここて'何がいいたかったのかといえば ， 定量 的に前進していなければならない.こういった仮定を立てま指標の意味づけとしてのモデルの重要性，それも単に数学

す.

的にきれいなモデルを作ってやるだけでは駄目で.どうし実は，これらの仮定の裏に.いろいろな意味(からくり)があるのですが.今日は時聞がないので，詳細は説明してそのモデルでいいのかを現実ときちんと対応させなければならない，ということを申し上げたかったわけです .

ません

以上で予定の時間もきましたので，私の話を終わります

さて.第 1 の兵隊さんが出発します.途中で.残念ながら.地雷に触れて爆死します.しかし.兵隊さんも死にますが，地雷もなくなるわけですね.

2 番目の人が行くとき(1) 質疑応答

Q: 現在の信頼性推定モデルはどの程度現実的なのです

は，地雷が 1 個減った状態になります.当然まだ他にたくか?

さん地雷が残っていますから，2 人自の兵隊さんも多分死

A: 非常にシビアな質問ですが.今のほとんと'のモデル

こういう攻撃を繰り返して行くとどうなるは.パグが見つかったときに，それを完全に取り除き. 新

ぬ確率が多いでしょうか?

しいパグを作り出すことはないと仮定しています.しかし，

まあ，日露戦争の乃木将軍みたいな心境ですけれども(現実はどうかといえば.たぶん 1~3 宮内の場合に.古いパ

笑 L 、) ，時聞がたつにつれて，たくさんの兵隊さんが死にグの修正とともに新しいパグが入ってくると思うのですね.

しかし，それとともに.巌後のほうになってくると，そうすると.今の信頼性推定モデルはあてはまらない.実ほとんど地雷がなくなってくる.そうすると，ほとんどのます

際に 3111の確率で新しいパグが入ってきたら.今のほとん

兵隊さんは，地雷に当たらずに.敵陣に到達できるように

ど全てのモデルの推定は狂ってしまいます.

なる.

信頼性モデルによる推定がどのくらい当たるかを，実際

このプロセスを神様が上から眺めていたらどう見えるか ，

それが，MTIF の考え方なのです.地雷がパグて\兵隊さんがテストケ

スだと思えばよい.同じ状況を，まった

く違う観点から見ると，何人兵隊さんが死に，その聞にどのプロジェクトで調べたところ，誤差が.大きいもので 3~4 寄l ありました.一般的にいえば，推定値よりも現実の値のほうが大きいですから，まだモデルとしてはかなり貧弱だというのが，正直なところでしょう.

れくらい時聞が経っていくか，といったモデルを作ること

Q: 誤りが完全には除去できないという仮定にもとづくもできます.

モデルはむずかしいのですか?

本当は，ここにはもっと重要な仮定が隠されています

A: それをやろうとすると，ふつうは.マルコフ 過程の考

簡単にいえば，いまのたとえばなしの地雷源では，兵隊のえ方を導入する必要があります.あるパグを修正したとき，通る道が決まっていません.しかし，プログラムの場合は.

どれくらいの確率で新しいパグが入ってくるか考えて.そ道が存在します

れを無限に連鎖させるわけです

もう少し数学的にいえば，ここでは，地

‑
1
6
‑

そうするとモデルがきわSeamailVol
.3N
o
.
3
‑
4

6
t
hS
o
f
t
w
a
r
eR
e
l
i
a
b
i
l
i
t
ySymposium

めてむずかしくなって，ほとんど一般的には計算不可能に

トとでは，同じテストでも，全然内容が遣うわけですね.

なってしまう.いままで，あまり成功した例は聞いていま

テストのやり方も遠いますし.本質的に遣 う作業ですから，

せん.

まとめてデ ー タを取って.システム・テストの初めからリ

しかし，私がいま吟味している新しいモデルて-は，たぶグレッションテストの終わりまでを.一遍に分析するのはんこれまでの仮定をはずしてもよいと思います.このモデ

少し乱暴だと思います.

ルが成立するとすれば，もしパグが完全に取り除けない場

Q: 先ほどの地雷原モデルですが，このモデルを見て不合でも，ある変数変換を行なうだけで同じモデル(数学的満に思うのは.パグの重みづけが考慮されていないことでにいえば同型のモデル)が得られるはずで，そうすると，

す . 大きい地雷だと 1 つ爆発したら，周りの人聞がたくさ

たぶん推定は同じ方向でうまくいきます.

ん死ぬし(笑い) .かんしゃく玉みたいものなら，たとえ

ただ，こうした形をしているデ ータ はそう多くないので，爆発しても.痛いなあと思う程度でそのまま前進できるとそれをうまく当てはめられるケ ースが どのくらいあるかはいうことがあると思 うのです.それに.パグというのは，少し問題です.交換線系のソフトだと結格これでいけるの

ふつう.プログラムの正しさだけが問題にされるのですが.

かな.と思っています

たとえばある操作を 10 秒以内にやらなければいけないの

アプリケーションならいいのですが . OS みたいな基本ソフトの場合はほとんどあてはまらに.

20 秒かかってしまったとした ら.それも 1 つのパグ

ないて'しょうと考えていらしゃるのでしょうか?

Q: いま.交倹線系といわれましたが.それはどうして

A: 後半の御質問の答えは簡単で，それはあき らかにパですか?

グです.それから，地雷の重みづけは.発見されたパグにA:

OS の場合は，システム・ジェオ、レーションという対してそれぞれランクをつけることで処理できます.たと用語があるように.インスト ー ルされる環境によって違っえば.あんまりたいしたことないパグと，重要な(むずかてきます.そうすると名目的には 1 つのソフトなのですけしい)パグとに分けて考える

れど.実際は，全然違ったソフトがたくさん動いているの

なぜそうした総別が必要かといえば，パグを処理(修正)するスピ ー ドをモデルのなかてす及うようにしたいからでと同じことになります.
一方，交換線系のソフトは ，だい たい似たような使われ方をする.そうすると.ある程度まで行けば.メインラインのパグが取れてなくなるので ，パ グ相互聞の独立性とす

簡単なパグと難しいパグとでは.そのスピ ー ドがものすごく遣うんですね .

したがって，どうしてもそうした区別をせざるを得ないというのが現実です .

いう仮定が成立しやすくなる.ですから ， 必然的にモデル化が容易になってくるのです .

泊野 :Q: 日本では，パグの累積幽綴に S 字形が多いといわれびてしまったのですけれども.これでオープニング

どうもありがとうございました.かなり時間が延ていますが.それは，テストのやり方とかに関係があるのションを終わりにさせていただきます(拍手)セッ.

でしょうか?

A:

はい，ものすごく関係していると思います .

Adh
o
c

このレポートは，昨年秋，大阪で開かれた第 6 回ソフトにテストを行なうと，絶対 S 字形の累積幽線になるといっ

ウェア信頼性シンポジウムから，第 1 日午前のチュ ー トリてもいいでしょう.

アル-セッションにおける 3 つのプレゼンテーションをま

Q: その場合 ， 原点をどこに取るかが問題になると思う

とめたものです.テープ起こしは，シ ン ポジウム参加者ののですが.... ?

l 人であった佐藤貴司さんにお願いし.段終原稿は編集部

A: ふつうは，システム・テストの開始時点、を取ります

で整理しました.したがって ， 文責はすべて編集部にありある場合には，システム・テストの後で .

リグレッション

ます.引き続き行われた討論セッションの記録は，いま編・テストのデ ー タを分析することもある.そうすると，先集ボラ ンティアの手で整理中です.次号をお待ちください

ほどのように，たくさんのパグが残っているという状況ではないので.

s 字形の曲線にはならない.

したがって，どこからデータをとりはじめるかということは大切です.リグレッション・テストとシステム・テス

‑
1
7
‑

3rdSEAEnvironmentWorkshop

l
.3N
o
.
3
‑
4
SeamailVo

第 3 回実践的開発環境に関する集中討論〈報告・その 1 )

S
e
s
s
i
o
n1

マン-マシン-インタフェイスの改善
1988 年 1 月 27 日

PM2:∞ ~ 5:00

於長野国際会館

チェアマン:
スピ ーカ

坂下

: 青木

秀(アステック)
淳 (富士ゼロックス情報システム: FX1S)

吉村智香子(ヒラタソフトウエアテクノロジー: HS1)
新田

レポータ

坂下:

: 小林

稔 (ソフトウエア・リサー チ・アソシエイツ : S孔幻貞幸(電算)

いまや，開発環境をささえる土台は. TSS + キャあります.

ラクタ一端末の時代から.ワークステーション+ビットマ

私は 言語屋です. いまは富士ゼロ ックス 情報システムにップ・ デ ィスプレイの時代へと移り変わりつつあります.

いますが，その前は富士通ビーエスシーで ，ア セ ンプラやウインドゥ・システムもいくつか登場し.どれがメジャー

C の処理系を作っていましたになるか興味が持たれています.

( PFU)に 派遣されて，外注として働きました.その時に.

このよ うな変 化に伴い.従来のツ ールのユー ザ-インタ
フェイスを改良したり，斬新なアイデアに基づいたマン・

L
i
s
p
.P
r
o
l
o
g
. Smalltalk の処理系を作るという仕事をしました .

マンシン・インタフェイスを基礎にして.開発環境を再構

築するな どの活動が行な われているも のと思われます.
このセッショ ンで は，マン ・マシン

その.後熊谷さんのところ

イ ンタフェ イスの

そんなわけで，マン・マシン・インタフェイスについて，

言語屋としての立場から.考えをお話してみたいと思います.

アイデアの提示や，ユーザ，インタフェイスの改良事例の発表などを通じて，人とマシンとの 「 親和性 」の本 質に迫(1) よいアログラミング言語とはれるよ うな議論ができ れば .と考えています

まずよいマン・マシン・インタフェイスは，よいプ

みなさんのポジション・ぺーパを審査した結果.プログ

ログラム 言語 とともにある J と申し上げたい. よいプログ

ラム委員会で 3 人の発表者を選んであります.まず最初に.

ラム言語とは何かといえ l.f .自動メモリ管理が，その第 1

富士ゼロックス情報システム仔χ1S) の青木さん.お願い番目の条件です .こ れは，農地解放のよ う に.プログラマ

します

を平等にするための根本だと思います .この 機構を持っていない言語は，近い将来に亡びるでしょう. ALOC とか

Summit の発想、FREE とかい うコマンドを，プログラマがわざわざ使わな
ければいけないような言語は， もうダメだと思います .

青木淳

対話的で自己鉱張的であるというのが.

2 番目の条件です.つまり.コンパイル言語は，やっぱりもうおしまいで，「 磁波と建設を繰り返して 美が生ま れ る J というのが.

イ ンタプリタのほうがいいということですが.実行速度がソフトウェア作りにさいしての私の美学です.既存のもの問題になるので . その辺を何とか解決して，コンパイラとをできるかぎり犠 して，その中からまた新しいもの.美しイ ンタプ リタのあいの子みたいなものを作ればいいのでは

いものを作り出してゆこうということが，いつも心の底にないか，と思っています

‑
1
8
‑

3
r
dSEAEnvironmentWorkshop

ソースを書いて一括コンパイルしてメモリに乗せて走らせるような 言語は.

もはやナ ンセンスだという感じです.

SeamailVo1.3No.3・4

才一ムな檎遣に特徴があります. NTI の竹内さんあたり
は.

S
m
a
l
l
ta
l
k はイ ンタフェイス言語だといいきって いま

少なくとも.そういう言語の場合には.インクルメンタル

すが，私もそれに賛成です.ものとものとが話しあうよう

ローダを自分て'作っておいて， 動的リ ンク をしなが らやなことを，根底からきれいに記述するのに向いていると思っていくようにすべきでしょう.そうすれば.プログラム

います.そのユニフォ ー ムな檎造がどんなものかというこがまちが っ ていた ら .そ の部分だけ入れ 換 えることができとを，少しお話します

ます.マ ン・マシン ・イ ンタフェイスを作っていくときに.
これはきわめて重要なこ とだと思います.

‑
"
"t

User

〆 \ー/

3 番目には ， アルゴリズムをデータとして扱えるというノ メ!

特性が ， 特にマ ン・マシン・ イ ンタフェイスにとっては ，

J

ノノ'
〆

I

/

重要になります . ユニバーサル ・メ ソッド. Lisp の万能関数のことなんですが，それが簡単に 実現できる言語 情造が必要だろうと，思います.プログラマプル・アイコン.可視的なイメ ー ジに対してプログラムを束縛できるような性質
が.マン・マシン・インタフェイスを作っていく時に必要だと考えていますアルゴリズム自体をデータとして鍛える 言語としては，

L
is
p.P
ro
l
og
. Small talk があげ ら れます .

C にも関数へのポインタがありますが，環与を自体が存在しない.つまり，スタックの内容を保持して動くようなことができません.
アセンプラは問題外です .
それから.

4 番目には .対象物が自然に表現できる こと ，

国 1

MVC の概念

すんなりモデル化できて鍛えることが重要です.これは.
Smalltalk が得意だといわれていることですけど， 一応 オ

ブジェクト指向の考え方です.
オブジェクトがい っ ぱいあると ，対象物問の 関係を表現

Smalltalk の中には，すべてのオブジェクトを見るためのツ ールがそろ っています.たとえば.整数を見るためのウインドゥすらあります.実際には.インスベクタと呼ばできることが必要になります.つまり.あるマシンとマシれるものです.それを専用化していくと.システム

ンの聞のネットワークとかがスンナリ表現できる言語体系

ウザとかファイ j レ・リスタとかになっていきます.よくいが必要だろうと思 っています. Smalltalk で対象物を自 然

われる :MVC つまりモデル ・ ヒ'ュー - コントローラとは，に表現することは.勉強すればそれなりにできるよ うにな

あるものをある視点から見ている，そのビュ ー にはコント

るんですが.そ う やってで き たオブジェクト聞 の関係を記

ローラがついていて，ユーザは.レバー録作によって.モ

述するのはむずかしい

デルを見る観点を変えられる.

ですから，この 2 つができるよ うな言語が，こ れか ら望

ブラふつう .Nれ'C に ついては.このことばかりが強調さ れ

まれる ん じゃないかと思います .てそう い う言語の 上に.

ていて .

初めて . よりよいマ ン ・マ シン・ イ ンタフェ イスが作 ら れます.これを鉱張すると ， エンカプセレータとかデーモンるだろうとい うのが，私の持論です.

になっていくわけですが，そのことを無視した長fV C の解

1 番大事な「依存性 」の 概念が抜けていると思い説蓄が多いのは.困りものです .

(2)Smalltalk の h仏位

どういうことかといえば.閉じものを.複数の人が遣う

それで私，このところず っと Smalltalk をや っています.

視点から見ている.そのときに.ある人がコントローラを

普は処理系を作 っ ていたんですけ ど， 最近は .そ れを使 っいじれば.モデルの内容が変ります.同時に . 違う視点かて，いろいろなツールを作 っています.
Smallt alkのマン-マシン・インタフェイスは，ユニフ

ら同じものを見ていた人に対しても.眺めが変化して欲し

いわけです

‑
1
9
‑

そうすると，ふつ うの MVC ではだめで.モ

SeamailVo1
.3N
o
.
3
‑
4

3rdSEAEnvironmentWorkshop

デルに対してヒ'ュー，コントローラが依存しているようなるだけではなくて . これをひっぱたたくと，クラス形態が必要になります.

ウザが開きます.つまり，このアイコンにプラウサ'を

それが， Sma llt alk の中には用意されています

ブラ

コント

開く J というプログラムがパインドしてある . ここをダブ

ローラによって変化が起こると.自分が変化したよと伝え

ル・クリックすると.コントローラを持ったクラス・ブラて，それが見ている人達にブロードキャストされていくとウザが開いてくるようになっているのです .

いう形です. MV C 自体はそんなに大したことはなくて.
その先にある依存性とか，それをもっと発展させますとカ

プセル化の 概念になるんですが.オブジェクト悶の関係を記述するものです.オブ.ジェクト指向に関係の概念、まで取り入れたような考え方です. Sma llta lk のマン・マシン・
インタフェイスは，すべてこの方式で作 ら れています(3) よりよいl\-岱E のために
私は，よいマン-マシ ン

インタフェイスのためには，鉱張性と親和性が重要だろうと思っています

先程から述べてきたプログラマブル・アイコン(プログ
ラマプル・イメ ー ジ)では.視覚的なものにプログラムを束縛できることが.この鉱張性を生み出しています.

1 つの絵を描き.それに対して何かのプログラムを作ってバインドできる仕組みが必要です.その背後には.アルゴリズ
国 2

ムをデー タとして級える言語檎造が必要だと思います .

Sma lltalk の宇宙

それともう l 点，ダイレクト・マニュピレ ー ション，直接操作牲と呼ばれているものが重要です . 対象となるもの

この図の中には.たくさんのものが指いてありますが.

を 選 択 して そ れに対して動作を指定できるということです.

そのうちのどれかを選択し，その後て\それに対して動作

私は家に

Ma c を持っているんですけど，フライト・シミを指定する.実際には.ポップアップ・メニューを使うのュレータ を 動かすと，何か自分で飛行 織 を操縦しているよがふつうです.メニューを開けて，たとえばブラウザ ー をうな 奮 囲気になりますね.このように，対象物を直接操作

開 くという順序です.

している感じが . やっぱり大事だろうと思います

Smalltalk における 恥仏但 は，ほとんどこの形態で統ー

それは.

ユ ー ザが本当にそのものに触っているという感覚を与えてさ れ てい ま す

くれます. CPl均パワーが上がったら， þ.岱位では.まず.

なるということがほとんどなく.この原則!を犯すこともタ

ここをがんばるべきだと思います.

Ma c と同 様 に，ツ ー ルによって使い方が異ブー とさ れ ています.ある意味では，非常にプログラマが次の図は， Smallt al k の小宇宙を示しています.オフジ

苦労する . つまり，ときにはそのタブ ー を破ることが，本エクトを中心にして，これが 1 番抽象的なものですが，そ当 は 必要な ん だけど.やっぱり皆に使ってもらうためには，れを どんどん具 体 化していったクラスの階層 楠 造を示してそのフ レ ームワ ー クを守らなければいけない，というジレいます. オ ブジェク ト とコントロ ー ラの間には，サブクランマに陥ることもあるのです

スという関係があるんですけれども，この関係を線で結んで示してあります.しかし.そ れ をただ線でつながってい(4) 視覚的 Unix の試みると考えるだけでは無意味であり.オブジェクト聞にサブ

そ れ では，

S
m
a
l
l
ta
lk を使って，いったいどんなものをクラスという関係があるということが処理できなければい

作ったか ，

け ない

きるだけ視覚 的に見せてあげようという試みて'す

1 つの事例をお話します.それは ， Unix

をで

S山n­

ここに出ている文字列は，それ自体.プログラマブル・rrut と呼んでいます.絶頂とか頂上とかいう意味ですが.

アイコンになっています.ただ単に文字がそこに書いてあ

実は Smalltalk で Unix の恥⑪包 を作ったというだけのこ

‑
2
0
‑

SeamailVo
l
.3N
o
.
3
‑
4

3rdSEAEnvironmentWorkshop

ですからこの Unix を通して IPC で 他の Unix アプ リとです.

このアイディアの 鍵 になっているのは. Smallt a lk の 中

ケ ー ションの 結果 を Smalltalk の中に 取 り込 む こ とも で き

Sm
a
l
l
ta
l
k

ますし. (也の Unix アプリケ ー ションから Smalltalk の中にある Uni x のシステムコ ー ル

クラスです .

の中から Unix のシステムコ ー ルをオブジェクト 指 向風にを呼び出すこともできます.ソケットとか 何 か を使 え ば ，

使えるようにしたものです.システムコ ー ルの中では， 最

それはもうネットワ ー クに出て行きます.残念ながら

近話題の IPC を使ってあって，ソケ ッ ト.メッセージ

1161 にはソケットがついていないので. 最近では Sun をキュ ー ，共有メモリなど，いろいろ使っているんですけれども(笑い)

IPC のやり方はある.その場合には.こ れと思うんですけど.そうしたものが全部使えます.いまま自体が何か Smalltalk の仮想マシンに見え.そ れ が 他のマて'ずっと C て'やってきたけれど，なにも Unix のシステム

シンと交信をし合うという形になります.

プログラミング言語は C ばかりではない. Sma ll ta lk で書(5)ファイル・ホルダとエディタ

けは記述力が 100 倍になる(笑い)

視覚 的 Unix のツール携にどんな も のがあるか，全部 は無理ですので.目 新 しいところだけをご紹 介 し ま す.

GUni x の特徴は，プロセスとファイルにあると思う ん ですけれど. 1161というマシンは ， その辺があまり 強 くな

い.プロセスを視覚的にしようと思うとパワ ー が足りない.
今後は.そっちに手をつけて行こうと思って いますが.とりあえず安易にできるものはファ イ ルなので.そ れを できるだけ視覚的に 鍛 えるようにしようと考えてみまし た .
I
I
I

1
l
l
!
q
J

圃マ ンン

まず，ファ イ ル ・ ホルダとエディタ を作 ってみ ま し た.

1
.
1
l

エディタは.ほとんど Smallta lk のパラグラフ- エ ディタです.

v

Uni x の世界 では.ふつう.フォン ト の幅が一定ですから.そういう風にしただけのものです.

図 3S山町ni t

先程のブラウザがいっぱい出てきた (土治けも . 本質的に
o' F'I ' Z2 : ~ .r.a・，. ， ・・胴 ) ， /b ， .，は 2~3 日で作れます

これから説明するシステムも.実

'Y・

..・
¥AOQ)

際にアイディアを考えついてから動き出す ま で . 数日しかかかっていない.その後の時聞は.チュ ー ンナップやこまJJ ・・・・. - 、"' ・-輔 ) . I\nrIU:SfT'

・・・・・l- ~ l"" Þ輔 、I\nf"'/ t. O開. ~ 1・・・b 凶..c ø( "岨 I
f
l1
"/
u
.
.
a
:
:p

I
¥
n
r

同創印

‘ a ・"か凶..c p( M・・ ) lusr / lJ)OCl l 九NCO<昆~ 1 ‘ c ・ ^"， ，，掴1b， .../U"

prl ,...

かいパグつぶしにかかっているだけで，とりあえず動くものができるのは.非常に早い.これが Sma llt a lk の特徴で

V唱~

J U同 区'・9・ "・ TT Cl.l; l・・ " ・・ .. . )..，. _ 1

す.
国 4

さて. S山町nit の内部的な 構 造ですが. Xerox の 1161

ファイル・ホルダというマシンに Unix (SystemV) が乗っていて.その上
一方，こちらはホルダですが.たとえば ， パスワ ー ド・の l プロセスとして Smallta l k が走っています . その中には，仮思マシン.仮想、イメージ，その上にこの視覚的ファ イ ルなんかが入っている /etc のディレクトリは こ のパ

Unix ツ ー ルを乗せています.こことやりとりしているの

タ ー ンで表さ れ ます.ファイルの内容がここ に出 て い て.

が Unix S
ystemC all クラスと呼ばれているものです

その中から適当に選べば，下に ' ls - 1' コマンドで得ら れ る

仮想イメ ー ジの中にあるんですけれども.仮想マシンの中はほとんど素通して，そのままUnix に伝えられます . で，その機能を待って上がってきます .

詳細情報が表示されます.ものを選 ん で . ポップアップ・

メニュ ー を開け，編集という操作を選ぶと.望みのファ イ

ルのウイ ンド ゥが開いてくるという感覚です.

‑
2
1
‑

3r
dSEAEnvironmentWorkshop

SeamailVol
.3N
o.3‑
4

日常，ファイルを探して内容を見る.エディタにかけるという一連動作を.コマンドて'やっていますと，いくらス

す.選択ができないところはシェードカfかかっていて選べません.一応，ユーザをガイドしているわけです.

クロー 1レバーをつけても.出力が上に逃げて行ってしまいます.そこで，それらをウインドヮとしてホールドするこ(η 直 接操作とが大事だと思います.これからの l~ 風コマンドは，こう

今度はダイレクト

マニュピレーションの話です.ディいう形であるべきじゃないか.と思って作ってみたものでレクトリ階層全体の移動をどうやって実現するかを例とし

すて，お話しますSy~tem V では ' t ar' コマンドを使うんですが(笑い) •(6)ファイ Jレ・ツリー

Surnmit では.対象物となるものをマウスでクリックする

それから，ファイル-ツリーですけれども，とにかくだけです.この図では Sma lltalk という文字列のちょっと人間は 5 階層以上.相当な天才でも 7 階層以上のイメージ

下の部分です.皆が集まったところをクリックする，こ れ

は頭の中にないという話です . それくらいが.記憶の限界

で.そこにつながっているサブディレクトリ全部が選択さらしいですね.そこで.ディレクトリの階層梢造を視覚的れます .次 にメニューを開き.選択したものを移 動 した いに表現してあげようと考えました.ここに.枠で因われてという意志を指示します

いるのが，実際に fl が作業しているディレクトリ構造です.

図 6

直接操作(選択)で，いったい何が起こるかというと ， この木全体がア イ
国 5コンから離れ出します

ファイル ・ ツリー

それを望みの場所へ移動するだ けでいいのです.

この上で何かを選んで.マウスをクリックすると.あたかもチェ ンジ

ディレクトリしたような効果が得られます.

もう 'cd' なんてコマ ンドはいらない.この中のアイ コ ンに，そのための プログラムがパインドされています，そ れをパチッとやると動作が起こる

つまりおれはいまここに行きたい! J っていう感じですね.
今度は，こいつをダブル-クリックすると，また遣うプ
ログラムが動き出して.自分のホル ダ ーを開く，先程の/etc というファイル，そこをパチパチッとダブル

クリッ

クするとホルダーが開いて，中にあるファイル群が見える .
図 7

そのプログラムがこのアイコ ンに束縛されているのです.
このメニューは. Smalltalk と h必c を足したよ うな感じで

‑
2
2
‑

直接操作(移動)3
rdSEAEnvironmentW orkshop

SeamailVo1
.3N
o
.
3
‑
4

(8) ファイル-リスタとコマンド・イン タ アリ タにウインドゥ・システムを乗せたといっても，本質的にはファイル・リスタと呼ばれるものがあります.これは.

この機能を提供しているだけです.インタフェイスの立場

前述のホルダとツリーをくっつけたようなものですここからすれば. Uni x のコマンド群の寿命は，もう尽きていをパシッとやると.その中のファイル群がこちらに現われると思います.しかし，これからもやっぱり過去を引きずる.それを選んでポップアップ・メニューを開け.編集そって行かなければならないのなら，それをウインドゥ・シの他の操作ができますすステムに合うような形に変えなきゃいけないと思ったわけ

ツリーとホルダーの統合.一連のコマンドのスムーズな涜れを笑現したものです .

です(笑い)

以上て\私の発表を終りますが，ハイパーカードをはじめとして，非常に ~IMI のすぐれたソフトが最近出て来ていますけれども，その基本的な技術は，プログラマブル・
アイコンと.アルゴリズムをデ ー タとして使える構造の 構
築にかかっていると思います.そうすれば.ダイレクト ・
マニュピレーションみたいなものがスンナリ記述できます

ので，そういう方向で，これから努力して行くべきだと考
えています

飯下 :

どうもありがとうございました(拍手) ，もし.

いまどうしても聞きたいという質問があればうかがいます
図 8が，ありませんか.

ファイル・リスタ

それでは，引き続いて. HST の吉村さんに発表をお願
ツールの紹介の最後になりますけれども.とりあえずのコマンド・インタプリタがこれです，

いします.

S
m
a
l
l
t
a
l
k の世界には.コマンドを入れて復改キーを押すという概念が愚初からないので，こうしたシェ/レを作ること自体が ナンセンス
ではあるのですが(笑い)

• 1161 自体がそんなに強力ではなく.プロセスを視覚化できないので.仕方なくとりあ
えずシェルを作ったというわけです(笑い)

,

国E

.

• ¥s ‑1 .rro.，~

ー同

lJ‘'、

・同

1

・ 押ー'‘

1 J凶J凶

1咽‘ J U"I 14 曲目 JA-ν吻.. ， ~ . 1n
押~Ii J." 回目 : N J "-~内町 ..-1 抗日"1) Ja" 日目 zl JÂ- b-守司 er2

Sl

‘，咽

ω.，.八岨
a布0<リ引掴 ，つJ 肌，川g 岨 1川、 u
凶'凡"向川.，世2 . 2 川円,

c・ tJA- 6r可，.....相-一.
.
一-- sr.旬，努宅.噂暗...Fc叩y"司哩，、時巴 (C叫】 a曽. 向F uJ I 先肺
w、吻。肺玄 1n' 0"、、引. .“巴'憎伊、 5
)
"
'c
.
e
‑s(0.. I.
.
lC 川À、 、 a
削‘9"、色" 傍..，開
.
.
.
.
帽@
.F
酔
円、江"酬町 J 凶“，挑‘ 1 . Fu
吋J I 抱v
同。刷玄'"耐，.，噛口。伊肉 'y戸，巴師""己= 臼
t4 . . L. 凶t..， 由1 製50 局l/U
民国 、 ，‘園町 J凹似:Jk i ， f
UJi xe司友 w 司日開 5Y" lr叫 (0 " L回 ， 1 喫到8 吊1114

.

'¥

(
.
.
唱。F 時

.....
由 10 同胞.0 ' ・c1l由 〉
1"・ 1 輔 ・ ((F 刊凶U、... . 01* れ e崎間栂 : ' J ,f.-'tC'I i 曲目 。) ， il el.叶 l(S-I1 U H.. 、哩 h店.r..y・t UCl問問 }1fhl 問 。 ((F 竹e5 v唱 U oldfnt岨回。

. JA
‑‑
‑
.
.
a
..
s
t')(n ・"')1

(
5
.
.1
1u \k. 同 h雌叫可・"'"・ 11 x
Ytntrellet")， ff ・ 3 首 ・ ((F t1e3四 UI oldfU 山由 : ' J ‘ー缶、ol l1.Sl.') fi
1dn)1

図 9

コマンド・インタプリタ

これはもう.通常のウインドゥ ・ システムの h仏但と変わりません.たとえば .X とか SunView とかは.

Unix

‑
2
3
‑

3rdSEAEnvironment、司rorkshop

SeamailVo1
.3N
o
.
3
‑
4

考えました.また，構築したシステムを従来のものと比べユーザ・インタフェイスに関する一考察てみて考えたこと.できあがったシステムに対するユ ーザ
評価などをまじえて.お話したいと思います .

吉村智香子

本当に.まだ考えただけで.まったく笑践は伴っていないのですが，これから.それを具体化する方法についての

SEA のワ ークシ ョップに参加するのは今回が初めてでヒントを，討論のなかで得られたら幸いです.

す.どうぞよろしくお願いしますー

では，まず簡単に，従来のものとMa c 版の方のシステ

ポジショ ン・ぺ ーパにも書きましたが，わが社て\ロポ

ムを比較説明したいと思います.

ット・プログラミング開発支銭システムの再楠築という仕事をやりましたその中で.ユーザ・インタフェイスに関(2) 従来システムのユーザ・インタフェイス

していろいろ考えたことを，これからお話したいと思います.

これが.従来のffiM- PC 版のユーザ・インタフェイス

ですが.すべてのメニューが階層構造になっています.メ

まず，仕事の内容について申し上げると. HST とい う
会社は，自動化省力機メーカーの平田憾工から. FAにおけるソフト部門の強化を目的として独立した会社です

まニュ ー の入力は，ファンクション-キ ーによるキーボードからの入力のみです.たとえば.システムを立ち上げると.
ここに示すような初期メニュ ー画面が現われます

だ独立して約 1 年ですが.これまでに FA 関連のソフトウ

ェアの開発.主に製造管理システムなどをいくつか手がけてきています.

(1) ロポ 7 ト・プロ グ ラミング 開発支燈シス テム
私自身，昨年の夏.ロポ ッ ト

C恒例 1 . .

U Il ‑

1 ‑ 1・I ・，

I仲 町'f' u .l ・ 1

11
1
1 ICl lt.
l
I 11 '1'、， ・ e ・ ・. ， ".d ・ v
椅"・ R ・ t 内，. ・ 也"・ I .・"・ R・".. to.
. L巴， .

プログラミング開発支媛

システムの再構築というプロジェクトに携わりました.
これは，従来平田機工で

陶叫-fI

"

ffiM-PC 上に構築されてきた

円

:

"

‘

'1

四円 ・ 剖・ ー一 -- Cr..te 11 岬1. -11 pr 同 r. . ... 1 叫， .". 町 ・ 岨 IC
(O" 'II.( 叩・- - C _ "ll ・ "岨ι-1 r P'01..
.
.
.

.
1 "
1
¥.
1 '
'
'
O
o
t

1. 11"， ・ oÙ" --ー1
.
.
"
1 ‑11
l̲
I O(・ uc _・-- o. 刷・・ a 珂 . p. t e: r、''''1.・ M ・ ・ rll 'l'‘叫嗣"'''1. -11 P ' 叫 e ・・
叫ぃ-- tdll po l 川酬山 tl. SC d ・ u 0. 0. 11 川 U 制 h ・ 1.

'‘ ,, 'II.(S
S
-U ,
r
a
LLIST
r,
. 11
:
1
.
.
'
'10 I
['f

システムですが.それを今回新たに h匂c に移値するといrJt

う仕事でした.名前が示す通り.ロボット ・プ ログラムのU，げ,S II<'(

開発におけるコーディングからテストまでを支侵するシス. 06・

t\... ・~t 10"』四門店制 Pl L

テムです ー 対象となるユーザは.主に工場の作業員ですね.

図 1---T舗内 ・

s

,,_

v ・.，

I ・.

.‘~

br
.
1 ....""",..

I CU tI除q・・ t-.. "，(11.

-一 ーー ーー"
"
'
1
1 ‑11
111. .. ...・ ・柄引 ， .0 ，
-一一 一 - 1'，，"( ・.，州 11 1. -11 "'f 四 ・ ・・ ，.山 ._ 0
一一一ー- 1. 0 "， 1 ・ M ‘，... . ・角川叫 -11 c: _ ", II .
.
・ーーー一-lI ttll ， ..to ，.，.同国g,‘_, (rl‑ rl Q ) ''1. 1 岡崎 U国

H 口 -1"

U tT‑U' 1 ， a. ロ・ t.1.1S T

1
.
'

'U(

従来システムのユ ー ザ-インタフェイス

これまでコンビュータに 一度も触れたことがない.コン
ビュータって恐いと思っているような人たちです.また.

ロボ ッ ト ・プ ログラムを編集する場合は.

Fl キーを押平田機工で生産ラインを作っている技術者たち.いままですと.編集モ ー ドのメニュ ー 画面が現われて，そこで仕事E込4・ PC 版のシステムを使って仕事をしてきた人たち.そをします.終了したら.そこで EXIT(FlO)キ ーを押 して.

ういうユ ーザも対象と しています

初期メニュー画面に戻ります

開発環境としては，ユーザ・インタフェイスおよび通信

次は当然コンパイルでしょうから.コンパイル・ モード

部分を除いて，すべてSony NEWS 上で開発しましたをここで選びます.するとまた，同じようなコンパイル・

そこには，御存じのよ う に，ビ y トマップ・ディスプレイ，

メニュー画面が現われます.コンパイルが終了したらメイ

X ウインドゥ.マウスといったユーザ ・ イ ン タフェイスがン・メニュ ーに戻 って，次は，リンクのた めに，また閉じ提供されています.この仕事は. HST で Mac に 触る仕事

ような操作を繰り返すわけです.

として初めてのもので.かっユーザ・インタフェイスを作成するという意味でも，初めてのプロジェクトでした.

リンクをしようと思ってリンク・モードに入った時に.

もう 1 つプログラムの編集を忘れていたとかいう場合，まそういう環境の中でシステムを梢築していったのですが，た元に戻って，そこへ行ってというように.非常に面倒でそれを通して.たとえば，まず自分たちのための開発環噴

複雑な操作を繰り返さなければなりません.ユーサ'にとっを作るさいに.いろいろユーザ・インタフェースについてては.やりたいことがすぐやれるというのが一番いいので

‑
2
4
‑

SeamailV
o
l
.
3N
o
.
3
‑
4

3
r
dSEAEnvironmentW orkshop

はな L 、かと思いますが，これでは.やりたいことに行きつ(4) ユーずは 十 人十色くまでの道 が ， 非常に長くて苦痛です

以上のように ， ロボット開発支燭 シ ステムを再構築したわけですが，その中でい ろ い ろ ユーザ ・ イ ン タフェイスに(3) 新システムのユ ーザ・インタフェイス
一方. Mac 版の方ですが，これはビ ッ トマ ッ プディス
プレイとマウスを駆使しています

メニュ ー ・システムは，ついて考えたこと(先程もい L 、 ましたが本当に考えただけ
なんて'すが)を以下に述べたいと思います.まあ ， 雑感を述べるとい う よ う な感じですね.

Mac のメ ニ ュ ー ・マネージャ ー を利用して，プルダウン式になっています.

まず.第 l に.ユーザはさまざまだとい う ことです . ょ
くいわれるんですが . 初心者だったり . 経験者だったり，

スク リー ン上では，このように . いくつかのウイン ド ゥを重ね合せ ることができ. ~ IJのウインドゥを通して 遣 うメ

頭のやわらかい場合 も あれば，逆にモノスゴク頭が堅い人であったり(笑い) .本当にさまざまなんですね.

ニ ュ ーを いつで も 起動することができます.自分がいまど

たとえば，今 回 の ロ ボ ッ ト開発支燭システムですが.わういうこ とを やっているのかを，いって' も把思することがが社の新入社員は「メニュー-ガイド方式じゃないと非常できます ーにやりにくい J とかい う んですねところが.以前 IBMPC を使っていた人は. Mac を見て 「 わあ，こいつは可愛
い J ですとか 「 こいつはすごい，面白い 」 とか 「 工場で作業するのには，こうい う 可愛いのが必要て'すね 」 とか.結構 そうい う ことをいったりする .
56?8g

.,

でも.長い間プ ロ グラムを組んできたような人になりま抽・ 暗 唱 e

すと「やっぱり キー ボー ドから自分で入力をしてリタ ー ン

v
&
o
o
V
'
8.
e.
8

川 H 内MUH 市掲 げ 崎 市昂引E

z
e‑
z
e
.
ee

U
8
‑
¥
.
.
6.
ee
r<M ・ . . 防司 '. 2

.
.
.
.
.
・何唱抱 ・ 色附句炉開" ".喝 ) . .

x
e‑
x‑
ee
YO・ 馴ら4 ・- キー をポ ン と 押 したら.そのコマンドが起動される.そう L 、う方がいいね」などと.本当にユ ー ザ ー が思、うことというのはさまざまなんて'すね.

r司臥.( ・ e 附1U1JfD ， J ， 2 . 肉
SPC 刷

そういう こ と を 考えると，やはり，ユーサ'の好みに応じ..

向、" -向、".石関，， ) ・ eて変更できるようなイ ン タフェイスを提供していく必要が国 2

新システムのユ ー ザ・インタフェイス

あるんじゃないかと思います . それは.非常に大変なこと

か も 知 れ ませんが， . "た とえ ば . ある ウ インドゥでソ ー ス・プログラムを 編 集

また ， 使いながら自然とユ ー ザ自身が成長して行 け るよ

して い て. 月 IJ のウインドヮ で . そのソ ー スプ ロ グラムをコう な イ ンタフェ イ スですとか . 逆にユーサ'の成長に合せてンパ イ ル・リンク

インタフェイスそのものも成長していくよ う になってい れ

ダウンロ ー ドして . 笑行させながら .

別の ウ インドゥでは . ロボットの位置決めデ ー タの編集 をば ， なお素晴らしいんじゃないかなと思います .

ユー ザにとって . 習得しやすく，信頼性が高く，発展性

やってダ ウ ン ロー ドさせるといった具合いですつまり.いま ま でのロボ ッ ト の動きが， 新 らしくダ ウ ン
ロー ド されたデー タにしたがって変わってきます.マルチがあって.しか も 自分の好みに合うというインタフェイス

を .今後提供して行かなければならないと思います .

ウ イン ドゥ ですので . そう い うことが.同 時 に行えるわ け(5)利用目的/状況です

ま た ，ユー ザがそのシステムをいったいど う 使うのかを.

この よ うに ， 関連する事 柄 をいつも一 緒 に 見 ておきた いとか.気分転I負に他の作業をしたいとか . やりたいこと を

しっかり 把侵しておかなければいけないと思います.

すぐやり た いとかい う のが . ふつ う の人間の気持ちだと思今回のシステムでは . 我が社の方でハードも選択したのいます . マルチウイ ン ドゥのモ ー ドレス・メニュ ー は.そですが.たとえば. IBM7532 とい う 非常に大きな工業用

ういう意味で，私たちの気分を満足させてく れ るもののよのマシンがありまして，過去に . そ う いうものにこのシス

うに思います.

テムを乗せたわけですね.そ う すると.実際の生産ライン

とい う のは.長いものになると 2~300m あって，その

‑
2
5
‑

S
e
a
m
a
i
lV
o
l
.
3N
o
.
3
‑
4

3rdSEAEDvlroDmeDtWorkshop

中にロボットが 2~30 台くつついている.その個々のロのです .

ボット向けにプログラミングをしていくんですが ， ある場

所で作業していて，今度は向こうへ行かなきゃいけないと(7)ユーザ・インタフェイスと手順・ 4走況

いう時には.何と 3 人滑りで田N7532 を運んて'行ってま

最後に . ユーザ ・ インタフェイスというのは手順・状況

した(笑い).

何でそのときそのものだろうと思います.人聞は，内容は忘れても状況

B部4 のマシンを選んだのかというと.

IBM は大会社だからだというそれだけの理由だったらしいんです(笑い).

、 それが長{ac になれば.首にマウスをちょっと引っかけとか手順とかは覚えていることが結構多い.たとえば.あの書類はあそこに斜めにして置いたとか，そういう状況は ，覚えていたりする . ユーザ・インタフェイスは，この手順
・状況そのもののように思います .

て両手でこう持って行けるわけですね.そういうことを考つまりユーザ・インタフェイスというのは，覚え易いよ

えてあげるだけで.ユーザさんというのは結権喜んだりしうに考慮されていなければならないと思います.そのためますので ， そこまで考えなければいけないと.最近大声でに，はユーザ・インタフェイスには統ーした全体的な思想

いってるんですけど.

というのが.

1 つ必ず貧かれていかなければならないと思います.たとえば.首尾一貫した操作ができるとか.視覚(めヱーザ心理的な連続性が保たれるとかですね.

それと手順・状況によって検索ができるようなユーザ・

それから.当然のことですが ， ユーザの心理を忘れてはいけません.

インタフェースが望ましい.それには，ユーザとの対話が.

たとえば，マルチウインドゥを例にとれば.これはたし

常に保存されていないといけません.そうした過去の記録

かにいいんですけど，欠点といったら悪いんですが.ちょを学習して.ユーザ好みのインタフェイスに変わっていく

っと嫌なところがありますね . それは.仕事をしているうようなシステムが夢です.

ちに.ウインドヴが山のように重なってくるんですね.
その状況は . 机の上にいっぱい書類を重ねているのと何(8) 終わりにら変らない . あるウインドゥでテスト仕鎌書を書いたはず以上.いろいろ雑惑を述べてきましたが.いいたいことだと思いながら.それを探すのにマウスを何回もカチカチ

は . どうもふだん私たちは.ユーザ・インタフェース開発

カチやりながら.自分でイライラすることがある .

する場合に，らめているような気がして，本当にユーザのことを考えて

曜日の午後になると山のようにちらかつてしまう . それをいるんだろうか.という反省がいつも心のどこかにありま

整理してまた月曜の朝キレイになってというサイクルを繰す.

最後に.わが社としては . 先程も述べたように.この仕り返しているんですが.何かその状況と全然変わらないよ
うな気がする .
でもマルチウインドゥの本来の徳能は.それなんですね .
机の上の書類をそのままディスプレイにポンと入れるよう事がユーザ・インタフェイスを作るという初めての仕事でした . その後 ， いまもう 1 つ別のシステムを作っているんですが.まだその 2 つしか経験がありません .

どうも会社では.ユーザ・インタフェイスがメジャーじな τV コマーシャルがありますが.まったくそれでしかな
L、-‘川、まはこれしかない」とかいうふうにあき

私の机の上は，月曜日の靭はキレイに片づいていて ， 土

ゃなくて他の部分で一生懸命がんばっていてユーザ ・

私たちは ， もっとそれを整理したのが欲しいといつも思インタフェイスは適当に作ればいいや J なんでいうようなっていて.たとえばファイル ・ キャビネ ッ トをつけたりす

意識で皆が仕事している . というより，むしろそこまで手るわけですから，マルチウインドゥに対しても.それを管がまわらないというような感じを受けています.

理するもう 1 つ上のレベルの何かを考えて行くべきでしょっ .

書類の山の中に手を突っこんで.いろいろ探しまわるのでもよく考えれば，どんなに綴能が充実していても，ユーザ・インタフェイスの使い勝手が悪ければ ， 使ってもらえない.今後わが社でも，ユーザ・インタフェース専門のと，マルチウインドゥのなかをマウスで探しまわるのも，

グルーフ・ を作って ， エキスパートを育てて行かなければい

何となく同じことですから，もうちょっと何とかしたいもけないと思います .

‑
2
6
‑

もちろん，セ ン スのない人や.根気のSeamaHVol.
3No.3‑
4

3
r
dSEAEnvlronmentWorkshopない人は，いくら教えてもダメでしょうが(笑い) . そうまして . それで実際にロボ ッ トを動かすプログラムを書きいうエキスパートの養成を是非やりたいなという考えています.この言語は. Ba sic によく似ていて .IF 文とかが使ます.

えます(笑い)また，ユーザ ・ インタフェイスのライブラリ化も.是非

坂下 :

.

なかなか面白かったんですが，さっきの行番号な

やって行く必要がある.ユーザ ・ インタフェイスの設計かんか.いろいろなユーサ'がいるというよい例だと思います

らテストまでに要する時聞は，かなり莫大なものです .

ね.

いまのところ.うちは各システムごとに 1 品生産をして吉村:

平田機工が . 元来Basic しか使わない会社だったいるために ， 時聞がかかっていますが . ライブラリ化によんですね .

って，時間が大幅に短縮され，その分より高品質のユーザ

坂下:

すでに汚染されていたわけですね(笑い)

. インタフェイスを考える時聞がとれることになります .

吉村:

もう「言語はBasicJ という固定観念がありましまたライブラリ化されていますと品質面のバラツキも減って.絶対に行番号をつけてほしいといわれ(笑い) . 仕方てくるでしょう.

なくつけているわけです.
坂下 :それでは最後に . SRA の新田さんにお願いします .

どうもありがとうございました . 何かここで質問がありましたら，どうぞ .

Q: ソース・フ・ ログラム編集画面の OHP で.横に行番号がついていたのですが.なぜあんなものがついているのでしょうか?また，ロボ ッ トがコントロールされるようすが .
画面上でグラフイカルに見れたりすると面白いと思うのですが.そのあたりについてはいかがですか?
吉村:

まずこの行番号のことですが.

Mac のテキスト. エディタにどうしても行番号をつけて欲しいという要求がありましたので{笑い) .ニューライ ン を判別して，そこに入れこんで行くようにしました.たとえば，第 16 行の次に何かを挿入したいときは.ここでリターンキーを打つと，次に 17 という行番号があらわれて，以下の行全部がインクリメントされるように.いまは作つであります.

これはずいぶん苦労しました(笑い) .
それから.ロボットを画面で動かすという話ですが.いろいろ考えはしましたが時聞が足りなくてまだ具体化はしていません.この種のプログラムは . コンパイルした後，特殊なコントローラにダウンロードして実行されます .
今回の開発に際しては . News 上にコントローラのシュ
ミレーション・プログラムを作りました.それは，いまの段階では.ただ何かを受け取って何かを返すということしかやっていません . 今後は .X ウインドゥを使って.いかにもロボットがアームを動かすようなシミュレーショ ン をやって行こうという計画を立てています .

Q : プログラム言語は特殊なものなのですか?
吉村:

なるほど.なかなか現実の例としては面白かったと思います.どうもありがとうございました(拍手) .

(9) 質慶応答緩下:.

名前は. HARI.2コンパイラです . すなわちヒラ

タ ・ アセンブリ・ロボット・ランゲー ジ という言語があり

‑
2
7
‑

SeamaUV
o
l
.
3N
o
.
3
‑
4

3rdSEAEnvironmentWorkshop

じゃないかと . 私は思 う のです .

ERAS について

Mac のことをもう少し話しますと.人生というのは，いろんな人との出合いとか 1 冊の本を読むとかで変わると思新田誌

うんですけれども.私の場合はMacintosh を買ったことで.すべてが変わってしまった(笑い)

.

用意してある OHP の数が少ないので，なるべくど う いうふ う に変わったかというと，あれを買ったこと節約して使って行きます(笑い) .なぜかとい う と.今回で私のプログラマとしての芳命がかなり縮まってしまった.

新聞:

発表対象のツールが ， 実はまだ未完成で. 一昨夜も，

Mac

どうしてといえば ， Mac が世の中に存在しなければ，ああを今回のワーク シ ョ ッ プのデモ用に送り出す直前まで.コ

いうものを開発するために.あと何年か仕事ができたわけ

ンパイルしていました( 笑 い) . そ う い う わけで ， ウソのですけれども . その分が減ってしまった.そろそろ私のプ

絵を見せるよりは明日デモを見ていただいた方がいいと思

ログラマ寿命も尽きるんじゃないかなと思うので ， ここらうのです .

で最終兵器を作っておこ う と思っています，

その最終兵器こそが ， いまからお話しする ERAS とい(
1)Mac についてう ツールです .

最初の OHP をお見せする前に， Ma c について少しお話しようと思います . たとえば.一般には， Smalltalk がよ(2) 背景くユーザ ・ インタフェイスのよい例に上げられるんですが.

この ERAS の歴史をちょっと述べると，

Mac を持って感じたのは ， Smalltalk のユーザ

インタフ

ェイスはとてもヒドかったなとい う ことです(笑い)

.

3~4 年前にハワイ大学で仕事をしていた時に ERA (時代)という名前のエディタを作りました .

Unix を初めて触ったとき，普の(? )大型機の OS っどういうエディタかというと，いろんなものを絵(アイてヒドかったなあと思うのと同じように， Mac を使ってみコン)であらわして . エンティティ(実体)と呼びます.

ると Smalltalk はヒドイと感じます.どこがヒドイんだといろんなエンティティとその間に成り立っているリレーシ

反論される方が多分いらっしゃると思うので，例を上げて

ョン(関係)

おきましょう .

表現したアトリビュート{属性)の 3 つを使って . 世の中

ファイル ・ アウトという処理があります . Smalltalk の， それとそれらの佐賀を数値とか言葉とかでのものを何でもあらわしてしまおうというものです.

イメージの中に持っているプログラムなりデータをディス

この.エンティティ・リレーション・アトリビュートのクに書き込む作業です.それをやろうとして ， メニューか

頭文字をとって， ERA と名付けました.このエディタのらファイル・アウトを選びます.すると，フロ ッ ビー ・ デ

もう 1 つの特徴は.何だったかというと，絵の鋪き方に関ィスクを入れなさいといわれる . そこで.フロッピー ・ デする規則をユーザが指定できるという点でした .
どうして.そんなことを考えたかというと，ハワイ大学

ィスクを入れる . すると . このフロ ッ ピーはフォーマ ッ トに宮本勲先生という人がいて.学生に対しても無茶苦茶なしてない ， ダメだといって，やらしてくれないフォーマ ッ ティングは Smalltalk の中からはできない(要求を出す人ですが{笑い), CMU に ALOE という構笑い) .しかたなく.一旦 Smalltalk を抜けて，上の OS

文エディタ・ジェネレータがある.そのグラフィック販をに戻る . ところが.ディスクを何枚フォーマ ッ トしていい

作ってほしいという.ほとんど不可能ともいえることを.

のか.その時点では私にはわからない(笑い) ， 適当に 4

私に要求して来たのです(笑い) .

枚位でいいだろうと思ってフォーマ ッ トして ， 再びファイ
ルアウトを始める . すると， 4 枚では入り切れずに，5枚目を入れなさいといってくる(大笑い) .
つまり.概念的に閉じた世界でユーザ

イ ン タフェイス

ところが . はじめは不可能のように思ったんですけれど
も， Ma c を使っていろいろ試行錯誤している内に.これはできると確信できるようになった . そこで，作ってみたと
い う わけです .

もう一度 ERA の特徴をいえば ， エンティティとリレーのよしあしを論ずるのではなくて . これか ら は周辺機器その他 . 人間が手に触れるものはすべてシステムの要素としションとアトリビュートでものを記述しようということ，て.イ ン タフェイスのことを考 え て行かなきゃいけないん

ただのお絵描きツールではなく.絵を描く上でのルールに

‑
2
8
‑

SeamaﾟVol.
3No.3‑4

3r
dSEAEnvironmentW orkshop

照らして，正しく描いてあるかどうかのチェックもしてく-メニュー+ウインドゥ.キーボード+マウス

れる.その判断ルールは.ユーザが自分で定義できるとい-有効なコマンドだけ選べる+いって'も全部のコマンドが見える

う ものでした .

これが.だんだん発展してきて.先程熊谷さんがちょっ・極力モードレス . モードへの出入りを意識させないとおっしゃったプロタイパーズ ・ ワークベ ン チというプロ-コマンドの数を少なく.操作の種類+操作対象の組み合わせ

ジェクトの中てぺユーサ'の要求を絵でモデル化し，それをこれらは，実は.恥l3c のアプリケーションの作り方に，

プロトタイビングと呼ぼうと考えました.

こういうことを守りなさいと.きつく書かれているもので

しかし ， どういう絵を繍いたらいいか，最初のうちはわ

す.

からなかった . その時に，この ERA という汎用のモデリ

ERA

まず，ユーサ'がわかるものはメニューとウインドゥ，そはMa c の上でしか動いていなかったんですが，宮本先生

れから手で触るものはキーボードとマウス，もちろんフロの真似をして.

1 人の学生にソースコードを見せて「これッピーも触ります . Mac の場合は，フォーマットが必要なを Smalltalk に書き直せ J と要求した ら. す く司ってくれ

場合はフォーマットをしてくれます(笑い) .プロセスのング-エディタを使ったわけです.その時点では.

ました(笑い)途中でフォーマットをしてくれて.続いて仕事をやってく.

れるということです.
メニューについてですが，ユーザがこのツールを使って(3)ERAS の狙い
以上が ERA の歴史ですが.どうしてそれに S がついた

いて.ある所に来ています，そこではすべてのコマンドがかというと.さっきいったように，もうそろそろ最後のツ使えるわけではない.使えるコマンドだけが選べる.先程.

ールをと思って. ERA のスー パー ・ パージョンという意

青木さんの Smalltalk のメニューでシェードがかかってい味で，お手持の資料には. SUPERAて選べないというのがありましたが. Mac ても同じです .

と書いてありますけ

しかし.いつでもすべてのコマンドが見えている.つまり，れども.あま語呂がよくないて. ERAS にしました(笑いこれだけのコマンドが用意されているけれど . いまは使えませんよ.ということがユーザにわかるようになっていま

この S の意味は.明日のデモをご覧になればわかるはずす.

ですが ， 本当はScene (場面)の S です.いろんなものをERAで摘くと.ごちゃごちゃしてくるんですね . そこで，それから.いわゆるモードをなくします.たとえば，い「場面』という概念を新たに導入して .この シ ー ンではこまから名前とかテキストを書検えるからテキスト・編集のれとこれだけが見えるようにしようというふうな意味合い

モードに入る.いまからエンティティを作るからエンティ
ティを作るモードに入る.終ったらモードから出てくる，です . いずれは.もっと発展して S の後に A とか O がつき偉そう J とか「偉さ」に結びつくはずです{笑い).

といった切り倹えをなくしました.ユーザから見えないだ

何をしようとしているかといえば ， いまはただ静的な絵

けで . プログラムの中ではちゃんと区別があり.あることを描いているだけですが . いずれは . 描いた絵をそのままをしようとすると自然にそのモードに入るようにしてあり動かしてしまおうと考えています . そのアルゴリズムは.

ます .
コマンドの数は.できるだけ少なくしようと考えていま

大体も う わかかっています .

そうすると. ERAS は ，それ自体がエディタであり.プ

す . たとえば，ファイルを消去するのとディレクトリを消ログラミング環境であり.実行軽量檎にもなる.それを作つ去するのと. 2 種類のコマンドは必要ない.ファイルに消てしまえば，あとはも う 何もいらないというようにしよう.

えろといえばファイ I レが消えるし.ディレクトリにi首えろと考えています.

といえばディレクトりが消えればいい . そういうふうにしてコマンドの数を減らす.その代り操作の種類と対象物で.

(4) ユーザ・インタフェイス設計の基本方針

何をするかということを判断する.

ERAS にもユーザ・インタフェイスがあります. どうい

以上は.基本と思っていることで.既にやっていること

う考えを基本にして.それを作ったかというと.次の 4 つです . これからいっぱいしたいことがあるんですけど，そです:の中の 1 つでマウスの利用ということを.ちょっと説明し

‑
2
9
‑

3rdSEAEnvironmentWorkshop

SeamaUVol.
3No.3‑
4

たいと思います .

ニューを選ぶのと同じような操作ができればいい .
マ今;>.骨 T・周

イペ:l tt!.τ 且. P ，. .. . A.I. ・・・ ， 1/・・・(5)マウスについて

陣停と ι "t: U. Clld..O・""・ .Clld..On ，

マウスには，ご存じの通りボタンがあって ， ボタンを仰睡彊降停と ιτ . 遭 (pr...LτClld:. O..・0 ・ -Clld.. Of ・・

日区量制作…匂う時打州γす，はなす，それからマウスを動かすという 3 つの操作(
イベ ン ト)を起こすことができます . それを ， 人間の目で分類すると，クリック.ダブルクリ ッ ク ，

ドラ ッ グという

国 1

マウスの動き操作になる . つまり，コンビュータのイベントと ， 人聞のものの見方は異なる .

つまり . ユーザ ・ インタフェイスとしての人聞がいろん

すでに， Mac や釦lalltalk がやっていることの他に.鉱張徳能として.速く押すとか，ゆっくり押すとかの区別をなことができるのに，その選択の編を切ってしまわないで，違いをコンビュータに伝えたいということです.

取入れてみました . 人聞はそういうことができる.実際身の回りにある徴械を操作する時には ， そ う している . たと

(6)終わりにえば，織れそうなものは軽く持っとか . 重いものはしっか

いままでお話ししたことは.ツールの操作という面でのり持つとかしています . それが ， マウスやキーボードにな

ユーザ ・ インタフェースの話題でしたが ， 最後にもっと大ると，持っか持たないか . 押すか押さないかという単純なきな視点で ， つまりわれわれ人聞の世界にツールがどう入

コードに変換されてしまう .

ってくるか，逆にいえば . たとえばソフトウェア開発の環

これはどうもまずいのではないか . われわれの仕事の手境があって ， その中に人聞がどういうふうに入って行くか回\助けをするはずのコンピュータが.逆に仕事を制限していという意味で.ちょっと意見をいいたいと思います .

る.そこで，速く押すとかゆっくり押すとかいうことを考えました.本当はマウス自体，というかハードウェアがもっと進歩して.そのスピードを検出してくれればいいんですけれども.いまはまだ.そういうことをしてくれません
ので.自分の中で押された時間と縫された時間を見て ， 区

u
s
e

別する.

u
s
e

実際にどう使うかといえば.たとえば，あるアイコンを速くカチッと押してパッと持ってくると ， ここに移動する.
今度は ， ゆっくり押す.するとカーソルの形が変わる . で，ピッと持ってくるとここにリレーションが張れる.つまり，持って来るのとつなく'のとは， }J 11 の動作だという使い分けcreate.
generate ,makeができるわけです.

, oOoO

将来は，さらにマウスの動きによって動作の種類まで表現してしまいたい.いまは.対象物を選んでメニューから動作を選んでいますが，われわれはふつうの生活の中では.
そんなことは特に意識していません .
たとえば . 字を消したい時は消したい字を選んでから消しぜムを取るかとい う と，そうじゃない(笑い) ，消しゴ
ムを持って来て適当にガチャガチャやる . 同じように人聞

国 2

ツールと方法論の動作そのものを . やりたいことに変換してしまいたい .
つまり，ものを包むように動かすと.選んでそれから包む

ユーザがツールを使う . 方法論を使う.ツールと方法論というメニューを選ぶ . 消したい時には ， IJ シャガシャガ

が密接に結びついている場合もあれば ， 全然無関係な場合

シャとマウスを動かすと，その文字列を選んで消去するメもある.たとえば，開発の能率を上げるために，それを目

‑
3
0
‑

3rdSEAEnvironmentWorkshop

SeamallV
o
l
.
3N
o
.
3
‑
4

練にしたツールが多くなって来ています . 技術者がそれら分のメタルールを自分のデータ部分に持っている .

を使おうとするとき . 自分のいままでの仕事のやり方とまそれで.さっきいいましたブート・ルールで新しいルー

ったく別の方法論を支f愛するツールを使いなさいといわれ

ルを作って cat する . これは Unix の cat と同じで.するても，なかなかむずかしい.

と新しい ERAS ができて . それでいま作ったメタルール

ERAS では，そこをど う するかといえば ， さっきいった

ように . ユーサ' 自身がルールを定義する . つまりを読み込んで，構文チェックをやる.そういうふうなデバ

ERAS

ッグをしています.

は ， メ夕方法論しか提供しません . あなたがいままて'やっ

Q: 具体化で特殊なことをしているのですか?

てきたノウハウをここに入れて下さい . それで.全体をあ書店回:

なたの仕事の役に立てて下さい . という方針です.多分こ

独立の部分に分かれて ， ユーザ・インタフェイスはどんなの徳能は.これからのツールにとって 1 つの大切な方向でルールになっても一定.ということになっています.最初はないかと考えています.

に ERAS が動くと自分自身をもう一度読むんですけれどプログラムの部分では . ルールに依存する部分とそれで，いま. ERAS の開発が遅れているのはなぜかとも ， その時にルールをもう一度コンパイルするんです . 自

いうと，ツールとメソ ッ ドを切り縦してしまった.ツール

分で自分をコンパイルして動き出すんですけれども，そのを美しくするために . 自分自身をルール(メタルール)でコンパイラの部分がメタルールに依存しているだけで . あ

定義してしまおう.つまり自分で自分をモデル化してしまとは全部フリーです .

おうと考えているのです . 蛇が自分の尻尾を食べているよ

Q: そのことと ， ユーザが自分のルールを定義できるこ

うなものなんですけれども，いろいろむずかしいことが起ととの関係は?

りまして，あっちを直すとこっちも直さないといけない.

新国

それで遅れているんですけれども.方針としてはなるべく殺するといいましたけど.どうやって定議するかというと，ツールと方法論を切り隠してしまう，つまりペンチで釘をそれを ERA のダイアグラムで鋪く，ということです .

打ってもいいんではないかとい う ふうな考えです(笑い) .

ちょっと話が中途半端で終ってしまいましたが.以上で
す.

(拍手)

ERAS については，ユーザが自分でルールを定それで . ERA が立ち上がった時にまず自分自身のメタルールを読んで.コンパイルして.自分自身の動作を決めます.それからユーザに「あなたがいまから書きたい図式
は.どのルールにのっとっていますか」と聞いて来ますか(7)質疑応答坂下 :なかなか面白いお話でしたが，何ら，ユーザは自分て'作ったルールを指定して . これで書きか質問はございませんでしょうか.

ますと指定するわけです .

Q: ERAS のルールを ERAS で記述するということで坂下:それでは約 10 分間休憩を入れてから，討論に移りすが ， もう少し詳しく説明してください.

たいと思います .

頼回 :実はブート・ルールがあり ， それで自分が作った

メタルールを読み込みます.するとある程度のメタルールができる.つまり.すべてのことは書けないが.ある種のことは正確に書けるというルールをまず作ります.それでいまから作ろうとするものをデバ ッ グするわけです .
Mac の上て'作っているのですが. Ma c 上のアプリケー

ションというかファイルはトリ ッ キーで，すべてのファイルが 2 つの部分から成り立っているんですね.
ス部分.

1 つはソー

1 つはデータ部分と呼んでいます.ソース部分の中にプログラムが入っています . データ部分は.ふつうわ

れわれがデータと呼んでいるものが入 っている
アプリケーションはふつう.データは空つぼで，ソース部分がいっぱい . ふつ う のデータ - ファイルはデータがいっぱいで.ソース部分はゼロなんですけれど. ERAS は自

‑
3
1
‑

3
r
dSEAEnvironmentWorkshop

SeamaﾟV
o
l
.
3N
o
.
3
‑
4

とは!

発表をきいての感想{参加者アンケート)

田中慎一郎 (SRA)

事務局の手伝いでちょろちよろしていたので，あまりよく聞いていなかったが.ほんとうの雑感を記すと... ..青山漏恒央(目立 SK)

木さん :SU勘岱佐T の命名に感心.吉村さん:ウインドゥの

吉村さんの発表は.ユーザ ・ インタフェイスの本質をつ

汚い重なりは私も嫌いです.新田さん:マウスの利用法のくもので，現場とプログラマのギャップの例がおもしろく，は同感 .

興味深かった.しかし.雑感で述べられたことは，ソフトウェア工学の教科書に書いてある範囲を出ていないた事tft和正 (SRA)

とえばこういう方法はどうだろう J といった形で.たたき吉村さんの発表は.現場をこの間見てきたので.おもし台的なものを提案してほしかった.

「方法論とツールを分割し，使用者が方法論に適合した

ろく聞かせていただきました. HST は若い人が多いので，ユニークな考えがあふれているようですね.

環境を構築する」という新聞さんのアプローチは.私自身

新田さんの ERAS は，内容的にはおもしろかったのでの考えとまったく異なっており.新鮮であった . ただ.マ

すが，何に使うのか{使えるのか)がまだよくわかりませ

ウスの徳能を拡大して ， いろいろなオペレーションを行わん.

せるというのには，反対 .マ ウスが大きくなりすぎると，
結局は ， キーボードと同じになってしまう?

加E喜朗(東工大)がよい(または悪い) j は.すべてのこと(対象，
杉田義明 (SRA)

領域 ， 分野 etc.) についていえるのでしょうか.もし，そ青木さんの発表は. Smalltalk 屋さんたちに固有の閉じ

うでないとしたら目..の場合には」という前提を明確た世界を感じた.もう少し専門用語を省略して，一般人ににすべきでしょう . 吉村さんのいうように.話は「ユーザ

わかりやすく話してほしかった.しかし . 着想 ( Smalltalk

ごとに異なる」わけなのですから .

と Unix をつなぐブリッジ・ツール)はきわめてユニーク

rxx で00 というのがありますが」すみません .0。

であり，成果が期待される . 吉村さんの話には.まさに「を知らないものでわかりません . 10 秒程度でもいいから，現場」の匂いを感じた . このような個々の改善を積み上げ説明してほしかった.ところで .青木さんのシステムですていけば，実践的な環療の塗備が進むと思われる.新田君がほんとうに J ユーザ・インタフェイスは.改善されの ERAS のプレゼンテーションはおもしろかったが.究ているのでしょうか?

極のインタフェイスを目ざすという狙いがよく伝わらなかったように感じた.

吉村さんの雑感(? )は.

(性的ではあるが)するどい指摘だと感じました.学習するユーザ ・ インタフェイスの実現には.プログラムの実行部と.ユーザ・インタフェイ
佐 11千明(長野県協同 電算)スを分雌することが必要でしょう.行番号の件でいじめら

ツールと方法論の分障は疑問.何らかの方法論を支持すれましたが.やはり.あれは便利 . それほどヒドイものでるツールが必要だと思います.

S
m
a
l
l
t
a
l
ko
nUNIX の操はないと思います.

作性はすばらしい . j-Star(MESA) ても似たようなことが

時間輸の導入という新固さんのアイデアは鋭い . が ，慣できます . これらのツールは.何気なく当たり前に使ってれていないとうまくいかないかな，という気がします

い ますが，ビジュアルなイ ン タフェイスは . これから必須

ユーザ・インタフェイスは単純に.作業内容は複雑に」とでしょうね.

いう正反対の要求のトレード・オフは?

佐原仲 (SRA)

吉村鉄太郎(管理工学研究所)

自分にない考え方や発想、を聞けておもしろかった . しか個々のユーザの好みや要求に応じて勘仏fl をチューンナ

し，行番号付のエディタが. Mac の上にも生き残っていたッフ・することが，もっと行われるとよいと思う.

‑
3
2
‑

SeamaUVo
1
.3N
o
.
3
‑
4

3
r
dSEAEnvlronmentWorkshop

Smalltalk や恥fac など.いま世の中で「よい 」 といわれ

村川貴広(HS1)

コマンドの涜れを可視的にした Sm.⑪rrr のユーザ・イているユーザ・インタフヱイスについてよい点 Jr惑&Formatting の話のよ

ンタフェイスや . ERAS のように.エンティティーやそのい点」を.新田君があげたDi sk

リレーションもグラフィックに表わすユーザ・インタフェ

うに.具体的な例をあげて討論してほしい.

イスは.なかなかおもしろいと思ったが.やはり.ビ ッ ト
マ ップディスプレイ+マウスの威は出られないのだろうか

井川裕基 (JIP)?実践的という意味ではいいと思うが) . これから ， わ青木さ んのい うように. UNIX コマンドの作り直し(?)

れわれのところでも.こうしたビジュアル化を試みて行きは，必要だと思います . どのよ う な形でやればいいのでしたい .

ょうか?新田さんの ERAS は，動きがわからないので，デモに期待します.

三語あさ子 (SRA)「ユーザの好みに合わせて，違ったユーザ ・ インタフェ

小林貞幸(電算)

イスが提供できる」という考え方は.すごいと思った.し話を聞いていて.

かし，動作の「対象」と 「 動作 J区別できるか?

r 動作の仕方」でうまくr
Smalltalk を使ってみたい. Mac を使ってみたい」と思ったところで，汎用機の「は J の字 ，コボルの「コ J の字も触れられていなかったのは，ショ ッ

これはむずかしい .

ク!

にもかかわらず，話の内容は共通の概念として理解できる.不思議.

簸谷章 (PFU)

青木さんの話の前半はよかったが.後半はターゲットが
梓香 (SRA)

UN医というのが気に入らない.したがって，前半から後

青木さんの話は，英語にすれば USEN民向きのプレゼ

半への議論の連続性が，少し ， 希薄になったような気がする.オブジェクト表現にさいして ， リレーションをどう表

ンテーションだと思う .

マルチウインドゥ・システムの限界に関する吉村さんの現するのか?

吉村さんの話は.ユーザ・インタフェイスとして何を作ったのかが.よくわからなかった . OSと開発者とのあい

だのインタフェイスのように聞こえたが.そうなのだろう
か?

指摘は正しい.まさに.机の上の混乱をディスプレイ上に移動しただけ.ユーザ・インタフェイスは「手順と状況」
だという考え方は，おもしろい.人聞がおぼえやすい .
新田君の話は.現在の新しいユーザ・インタフェイスのロボ ット自体のユーザ ・ インタフェイスの周辺には，動向を非常にうまくまとめている . いまやユーザ・インタ

問題はないのだろうか?

新聞さんの話は，内容が実におもしろかった. ERAS のフェイスを論ずるとき. Mac や Smalltalk が話題の中心であり.キャラクタ端末は死んでしまった(満足!) .ユー

用途は.どこら辺なのだろうか?

ザ・インタフェイスのメタ化というアイデアはすごい .
臼弁護美 (JIP)
中野秀男(阪大)

オブジェクト間の関連を的確に表現できるようなデーモ
ンも，マルチウインドゥによる書類の山も ， 現実の世界の(1) 思っていること :混乱をコンビュータの世界に持ち込むことになる . 新たなマルチウインドゥ上の各ウインドゥの優遇配置は，後ろでフ・ロセスが走って，勝手に(もちろん各人の好みに合わ

パラダイムが必要ではないか?
吉村さんの話で，マルチウインドヮを管理するウインド

せて)変える .

対象としているもの(文章中の 1 つの単語など)をクリ

ゥを作ることは.メニューに戻るのと同じではなかろうか? 現実世界の「もの J のイメージを画面にとりこむことックすると，関連する他のウインドゥの内容も 自動的に変が.ほんとうに最もよい環境なのだろうか?

わる仕櫛けはできないか(どうやら . Hypercard のスイ ッ

ことは事実だけれど... ・

かなりよい

チのしかけや，青木さんのいうように ， データにメソッドを哩め込めばいいみたいだ) .
(2) 感じたこと:

岸田孝一 (SRA)

‑
3
3
‑

3rdSEAEnvironmentWorkshop

SeamaUVo
l
.3N
o
.
3
‑
4

いろいろすぐれたインタフェイスができてくるが.ユー"喜家賃子 (YHP)

ザが好みのものを選択できるようになるのか.それとも標準化するのか，どっちだろう?

マウスのボタン操作の早さ(速い /遅い)で，ユーザの気持ちが伝わると いうのは，とても興味がある.おもしろ
いなあ .

寺井

孝(目立ビジネ ス徴器)

3 氏の発言をお聞きすると.共通点として，各ユーザか認証尻賢二(信州大)らのさまざまな要求に答えるために，マシンをより人間に近づけることを目指しているように感じました.

やはり日本語が大切だと感じた.遅れてはいるが，通常の CRT 上のユーザ・インタフェイスは?

井上尚司(ソフトパンク総研)

根川縛史(三菱電機)

コンビュータが人聞の行動を制限しないような機械とし

青木氏 : 参考になった . 実行速度はどんなものか?

明て実現されるのは，まだまだ先のことだと思っています.

日のデモが楽しみ.吉村さん:実践的な話で.こういう世

マン・マシン・インタフェイスの飯終目標が達成されるの界もあるのか(こういう世界ばかりかも知れないが)と思は.いつの日のことだろう?

った.新田氏:斬新で.おもしろかった.
セッションを通じて，発表者にバラエティがあり.たい

西岡鍵自(横河電機)

へんよかったと思う.

青木さんの発表がおもしろかった.絵にして動かすときの一般的戦略があれば聞きたい .

市川寛(電算)マン・マシン・インタフェイスの話はよくわかるが，マ

盛岡政儀 (K岱)シンとマシンとのあいだのインタフェイスはどうなっていユニークな話ばかりででたいへんおもしろい .

るのか.もっと，システム全体(開発環境全体)のことを考えてくれる人(グループ)はいないのだろうか.

鍾友良 (FχIS)

3 つの発表は .いずれも.マルチウインドゥを用いて.

小泡幸徳(日本システムサイエ ンス)

インタフェイスの改善を試みているが .他にだれか 何かい

い方法を知りませんか?

アイデアがあれば聞きたい.

これからは，ユーザのレベルに合わせた勘岱位が重要となってくるものと思われる.たとえば.キーボード，マウス，マルチウインドゥ，タッチセンサーなどの選択.こう藤野晃Jt仔χIS)したM}v位の選択をどのような方法で行えばよいかが.よ

青木君:もう 1 つ上のレベル ， つまり，メタ-レベルへ

くわからない.

の普遍性を求めることが，今後の課題でしょう.
吉村さん:おもしろい . 長Ia c はたしかにユーザ・インタ

田中一夫(山一コンビュータ)

フェイスに革命を起こし うるポテンシャルを持っているし.
進むべき方法としては，よい .

青木氏:わから ん . 吉村さん:いっているとおりだと思う . 新田氏:おもしろかった.

新固さん:メタ定義，かつ自己内包的な汎用化の指向で，すばらしいと思う.ただ，ユーザが定義するルールの意味

中村

論的な正しさのチェックをどうするかは，問題だと思う.

エディタって何?

民(シャーフ・ )ソフト作りの仕事は所詮は「もの書き」だから，ただ文房具として，よい鉛筆が必要だといっ、 小林明彦(東電ソフトウェア)ているのと同じだよね!

私の興味は，エンド・ユーサ'への提供をどのようにした

らよいかというあたりににある . その意味で.エンド・ユ

近藤康二(ソニー)

ーザよりのマン・マシ ン・インタフェイスの発表がなかっ青木さん: Smalltalk-8(たは以前から興味があったので，たのが残念.

とてもおもしろかった.内容はまったく同感. UNIX も時

‑
3
4
‑

3
r
dSEAEnvironmentWorkshop

S
e
a
m
a
i
lV
o
l
.
3N
o
.
3
‑
4

代に合わせて変わらなければ取り残されてしまうという感あり，楽しく聞かせていただきました.が，耳に訴える話を強くした.

はなかったようですね . いま.私の職場では ， この「耳」

吉村さん:ロボット・プログラムの現実的な話題(特に質問に関連して)は.苦労がよく感じられた.私も会社にを中心としたアプローチを試みている若者がいて，机が隣接している私は，毎日非常に迷惑しています .

戻るとそうだなあ .

こんな話を参加者の皆さんから聞けるといいですね .

ERAS : とても理論的な話のように聞こえた . 自分で自分を作るというパラダイムは.なかなかのものだと思う .

桜井腐里 (SRA)

明日のデモが楽しみ.

青木さんの発表は，整理されてわかりやすかった.吉村

久保宏志(富士通)

聞ができることをコンビュータによって制限されたくない

r Algori出m を value に持てる変数の概念、が恥岱但言という新田さんの発想は.とても自然だと思 う が，それがさんの発表も . 現場の苦労がわかっておもしろかった . 人

語にとって本質的だ J との意見は ， 傾聴に値する.

夢でなく現実 になりつつある点が凄いなぁと感じた.

酒勾寛 (SRA)

北野義明 (KCS)

青木さん: Srnalltalk を UI 言語とする考え方は，正しMa c が実務の場で.こんなに使われているとは思わなかいアプローチでしょう.よくいわれる言語の閉鎖性を打ちった

破る鍵の 1 つがここにあるように思われます.

作っている環境と. COBOL を使ってホスト上でプログラ

吉村さん人間が実際に使う」という視点、にたったイ

やはり . C や Srnall talk-80 でアプリケーショ ンをミングせざるを得ない環境との差を痛感した .

ンタフェイスを忘れてはいけないと感じました.

ド仏fl のすぐれたシステムを持つマシン (OS) の上で動新田さん: ERAS の将来に期待しています . ERA モデリ

く COBOL コ ンパイラが欲しい!

ングの極限を見てみたいと思いますといわれそうだが.，..

欲しければ自ら作れ，荻生準ー{日本システム)

義幸一 (PFU)

私自身の仕事は，電力供給システムの要求定義やシステ

アイコ ン にパインドされるプログラムの種類は.マウス

ム設計が主であるが.このセ ッ ションで発表された開発環のクリック操作に限定されるのか?

境における恥岱但の考え方は ， これからの客先との加⑪包

ーザ - インタフェイスの上で ， かなりの制約になるのでは

機能仕鎌決定に参考になるものが多く.興味深かった.

ないか?

現在の電力供給システムでは.まだマルチウインドゥのそうだとすると，ユ

成長するユーザ・インタフェイスの考え方には賛成.

概念すら取り入れられていない状況である . 次のシステムの機能仕様決定には，このセッションでの発表の内容をぜ

伊野誠 (SRA)

ひ取り入れてみたい

MMI

はむずかしいが ， いろいろな考え方 . アプローチ

を聞けておもしろかった . しかし.もっと基本的な問題が落水浩一郎(静岡大)青木さん:勉強になった . Smalltalk

あると思う . つまり.恥仏但に関する基本的な作法とカサ宇を持っていないのり方の指針が存在しないという点である.

てやはり欲しいと思った.吉村さん : がんばってください.ただ.もう少し，話の妓術的内容に具体性がほしかった.新国さん : マウスの移動速度等のあいまいなもの(人によって遣う)を基準にしてよいのか.どうかつ

少し疑問に思う .

岡本陸一 (KCS)

3 人の方々から.人聞の 5!惑に触れるユニークな発表が

‑
3
5
‑

3rdSEAEnvironmentWorkshop

SeamaDVo
l
.3N
o
.
3
‑
4

新田:

討論

たしかに，マウスは石鹸です(笑い) .去年，

τRON シンポジウムに行ったら，ワイヤレスのぺンで書くタブレットが展示されていて，関心しました.

TRON

チップに次いで，すぼらしい発明だと思います.
坂下 :それでは，これから討論に入ります御意見またしかし.マウスを使うのは原始人だという悪口に対しては御質問をお持ちの方は，会場のマイクの前に並んでくだ反論すると .τ主主ON のあのキーボードは，人間以前の代さい.

物です(笑い).

なせ'かといえば.人間工学を考えて設計したというので(1) マウスをめぐる論議

すが，入閣を肉体的にしかとらえていない.ところが.人

事事

発表全体を通じて，もはや CRT 端

間には精神というものがある.そうした観点から見ると，末を前提にしてユーザ-インタフェイスを語るのは江戸時

あのキーボードは非常に使いにくい.あれを使って，ちゃ香 (SRA)代の人間だ，という感じがしました(笑い)

.

んとタイプしている人を見たことがない .

大変よいことだと思いますが.一方では， TRON の坂

坂下 :

その ， 精神工学的によくないという点を，もう少村健さんみたいにマウスは原始人の道具だ.まるで石し説明してください .

で絵を描いているのと同じではないか ?J という意見もあ

新聞 :

ります.

にあるというのは，肉体的工学から見ればよいことですが，発表者 3 人は，それぞれ.マウスを用いたインタフェイ

精神的な目で見ると，文字がアイウエオ順に並んでいる方スのお話をされたので.その点についてどう思われるかを，が.よほど使いやすいわけですね.

お聞きしたい.

青木:

たとえば，この指とこの指が交互に打ちやすい所

もし， τRON

さきほど MVC のお話をしましたが，

S
m
a
l
l
t
a
l
k

が専門タイピストを回線とするプロジェ

クトなら，あのキーボードは，すばらしいといえるでしょ

TRONは，もっと広く一般の人が使えるコの中には.ユーザ・インタフェイスをつかさどるコントロ

う.しかし，ーラと呼ばれる部分がある.それが，ただ単に .いまはマンビュータを提唱しています.そういう人たちに とっては ，

ウスにパインドされているというだけにすぎません.

少しぐらい指の動きが遅くても，キ ーがアイウエオ順や A

将来 ， もしマウスよりもすぐれたインタフェイスが，ハード的に開発されれば ，そこを置換えるだけですむ.です

BC 順に並んでいるほうが.親しみやすいのではないかと思います.

から，マウスうんぬんは，あまりたいした問題ではないんですね.どんなものでも，オブジェクトとしてとらえてい(2) 現実世界の混乱をどう整理するか?

るので，統一的な形で級うことができます .

白井義美 (JIP)

吉村{智マルチウインドヴを使ってマン ・ マシン ・ イ ンタフ ェイス

いま，世の中の風潮としてはビ ッ トマ

ップ・ディスプレイとマウスさえあれば.たちどころに .

3 人の発表者のお話は，いずれも.

をよくしよう，という趣旨のように聞こえました.世の中

よいユーザ・インタフェイスが提供される」というようなにある実物と同じようなものを，画面の上で操作して動かムードがあるみたいですが，それはちょっとまちがっていせる.そういうのが使いやすいインタフェイスじゃないか

ると思います.

という方向へ ， 何となく議論が収束して行くように思われ

たとえば，たくさんのウインドゥを開いて仕事をしています.

るとき.さっきもいいましたが.何かをやりたい場所にいしかし，世の中にすでに実在するものを，わざわざコン

ちいちマウスを持って行かねばならないのは.ものすごく，ビュータの中に.絵画的なイメージで再現しなければなら

均ずらわしいもうちょっと，たとえば音声で判断するとないというのは.まったく.進歩したことにはなっていな

か，視線のやり方でできるだとか.そういう仕櫛けができいと思うんですね.さきほど吉村さんがいわれたように，

たらスゴイなぁと思うんですけど "' "スクリーンの上が，いつのまにか.机の上のゴミの山と変車両国 :τ主主ON の悪口をいってもいいのかな?

わらないようになって行くのは，防ぎょうがない.

坂下 :

どうぞ，別に，かまなわいんじゃないて'すか?

笑い)また.いろいろなオブジェクトの聞をつなぐ(関係づける)デーモンについても.大変面倒な問題があると思いま

‑
3
6
‑

S
e
a
m
a
i
lVo
l
.3N
o
.
3
‑
4

3
r
dSEAEnvlronmentWorkshop

聞にうまくいかなくなるのはなぜか?

す.

私が思うには.現実世界のオブジェクトのあいだの境目

たとえば，私がいまこうやって話しているというのは.
1 人 1 人の人間というは，ディジタルではなく，もっとあいまいです.境界領域

オブジェクトに.何らかのメッセージを送っていることにでは.あるオブジェクトの浪度がだんだん薄くなり，そのほかなりません.

うちに他のオブジェクトに変わって行く.そんなふうにな

ここにおられるみなさん，つまり.

そのとき.受け手であるみなさん(各オブジェクト)は.

っていると思うんですね.

同じ私の話を聞いて.それぞれ少しずつ異なった解釈をしそれをモデル化して，コンビュータの世界に入れるときているにちがいない.そうした関係づけをどうするかは.

には.ここからここまでが 1 つのオブジェクトというふう

非常にむずかしい . 仮に何とか関連づけができたとしても.

に.はっきり区別しなければならない.

1 つのオブジェクトを取りあげたら何千何百という糸がつ現実世界では，混乱しながらも何とかうまくやっている

いてくるようでは.ほんとうにシステム全体の整合性をデことを.コンビュータの中へ持ち込んだ時に，あいまいさ

バッグできるとは思えません .

を取り除きすぎて失敗しているということだと思います.

つまり.図式化されて一見使いやすそうなマン-マシン
・インタフェイスを，機械の中に組み込もうとしているの(3) 人聞の動作のモデル化

だけれど，よく考えると.現実世界の混乱をそのままコン

落水浩一郎(静岡大ビュータに放り込もうとしているのではないか.という気の中で.人間には不器用な人も器用な人もいるので，それがしてならない(笑い)

新田さんのプレゼンテーションに合せて調整するというお話はわかるのですが.マウスの.

これまで.われわれはそういう現実の混乱した姿を無視

動かし方のように.基準のはっきりしないものをマン・マ

して.というか拍象化して.コンビュータで動く数学的に

シン・インタフェイスに取り込むのは，いささか危険では

きれいなモデルを作り上げ，なるべく理論的な，ロジカル

ないて'しょうか?

な話に持って行こうとしてきた . 現実世界の混乱をどんど

マウスを動かす速度は.人によって違うから判定がむずん取り込んでも，ほんとうに役に立つコンビュータ・シス

かしいでしょうし，また.マウスをガシャガシャ動かしてテムができるのかな?

モノを消すということてすが.何かの加減でカーソルがどという銀本的な疑問を感じます.

そのあたりのことをどう思われているのでしょうか?

こかへ飛んで行ってしまった場合.それを戻そうとしたと青木・きに画面が全部消えてしまわないのですか?笑い)

たしかに，オブジェクトをたくさん作って行くと.

それらのあいだの関係を選り分けることができる何らかの新聞:機構が必要になるでしょう

がちがっても標準化されているのに.なぜコンビュータは

τRON の坂村先生は自動車の運転はメーカ

つまり.それぞれのオブジェクトが.自分のテリトリ，

そうなっていないのか? J とおっしゃるのですが，ハンド自分が見ることのできる鈍図をはっきりわかっていて.そルを同じ角度だけ幽げたとき.すべての車が同じだけ幽がの中でさまざまな関係を操作できるような仕傍けです.
そうした関係の操作という場面では.

P
l
o
r
o
g みたいな

るかといえば.そうではない . アクセルを同じ角度だけ踏むと，同じだけスピードが出るかというと.そうでもない.

言語が，これからカを発揮してくるのではないかと，言語そういう意味においては.自動車は.

屋としては，考えています .

んですね.

適時国:

ところが人聞は.そういうバラバラな特性を持った自動直後の答にはならないのですが.私の考えていることをお話します.
現実世界とコンビュータの世界とのちがいは，たとえば，

1 台 1 台バラバラな車をうまく乗りこなしています.それは，人聞に学習能力があり.フィードパックの能力があるからだと思います.

私の机の上がどんなにちらかっていても，欲しいファイル

私が ERAS に組み込もうとしているマウスの動作速度

はちょっと探すだけで手に入るわけですね . ところがそれやパターンの認識についても.人間がその働きをうまく学

をコンビュータの中へ入れてしまうと . なかなか探すのが習できるということが.

1 つのポイントです.

つまり，マウスをガシャガシャやって.自分としてはたむずかしい，というあたりにあります .
現実の世界にはいろいろな混乱があるけれども.人聞はだ向こうに持って行くつもりだったのに，画面が消えてし

何とかうまくやっている.それを.コンビュータ化した瞬まったあ.これは間違いだ」と気づく . もちろん.そ

‑
3
7
‑

3
r
dSEAEnvlronmentWorkshop

SeamanV
o
l
.
3N
o
.
3
‑
4

う気づいたら.すぐ元へ戻す徴能 (Undo) が用意されて現実の社会の中でも.ときには靴に足を合わせ，また，います.

別の場合には足に革止を合せるという状況が存在して，それ今度は.意図的に tJ シャガシャゃったら.うまく消えた.

ぞれ一長一短ありますそれなら両方選べるようにして「なるほど，こういうふうにやれば消えるんだな」と学習

しまえ J というのは.乱暴ないい方でしょうか?

できる.マウスのスピードについても，同じように，ゆっ

いま.マン・マシン ・ インタフェイスは非常に多種多彩くり動かすとカーソルの形が変わって.これだけのスピーなものが出てきて.たしかにそれぞれ便利そうに見えるん

ドならこうなるんだなということをユーザが発見し.学習ですが，はたして.ほんとうに仕事をする時に便利なのかできるような，そういうユーザ・インタフェイスを作りたどうか.疑問を感じることがあります.そのあたりをどういと思っているのです .

お考えなのか，うかがいたいと思います.

井上尚司(ソフトパンク総研

青木:

その話の続きなんて'すまったく.いまおっしゃったのと同じ考え方です . マン・が，コンビュータの方には学習後能はないんですか?

たとえば，消しゴムが A. B2 種類あって，実際に消してみたら A の消しゴムはよく消え.

私がお話したプログラマブル・アイコンの概念は，

マシン・インタフェイスの鉱張という見方からすれば.

B は消えが惑いとすれ

1

つのアイコンの中にパインドできるプログラムの質，それば，人聞は A のほうしか使わなくなると思うんですが，コが一万彫りであったり.多様なセットであったりします.

ンビュータの上には B タイプの消しゴムしか用意されていそれをユーザが選べるような仕掛けを持ったシステムをなかったりすると.何となく「そんな環境に馴らされるの作り ， そういうものを使って ， その上に一万彫りのインタはいやだ」という人が出てくると思うんでが ， そういうこフェイスをつけて出すのが，現状で考えられるベストだろとは考えていませんか?

う と思います .

車両回:

新聞:

その問題には，ある種の対処法を考えてあります.

私は.さっきMac の上で仕事をしているといい

いま作っている ERAS では.たとえばマウスのスピードましたが，実はMa c の上でShell と vi と C コンパイラに関するパラメータを，手の感覚で何となく違うなというを動かして，コマンド・インタプリタで仕事をしています.

3 っか 4 つの種類の中から.

1 つだけ選択するようふうに

要するに一万彫りでやっているということですね.基本的しています.そんなふうに，自分の好みを機械に伝えられには.人はそれぞれ自分の好きなものを選べばいい . だれるわけです.

からも選ばれないツールは消えて行く.そういうことでは坂下 :ないでしょうか?

その選択にさいしても，インタフェイスがあるん

ですか.

佐原

適時国Ma c には.コントロール ・パオ、ルというものがこかまだおかしいけれど.取りあえず使いやすいからいいあって，マウスの動作速度とかキーの反復のスピードとかのではないか，という論議のようですね.

を.ユーザが自分の好みに合せてある程度調節できるんで体 (SRA)

マルチウインドゥとマウスは.ど

私はいま恥fac と Unix の両方を使っていて感じるのは.

すが，その仕指けを利用しています .

どちらもたしかに使いやすいんですが ，使いにくいところもある . それは ， 目的によって違っていて，たとえばMac(4) r マウス=鉛筆』論中村真(シャープは，頭にひらめいたことをすぐに具体化するときは使いや

これまでの議論を聞いていると.

マウスは.いわばわれわれにとっての鉛量産てe あ り.それがすいけれど，いわゆるパッチ処理的に，大量に同じことをやるのには向いていない .

つまり，ユーザ・インタフェイスには.大きく分けて 2:ft近なかなか使いやすくなったというお話のように聞こえます.

種類のものがあり.その片方の話しか.みなさんしていな

ことばを変えていえば ， 木彫りをやるのに.一刀彫りで行くか.各種セットの揃ったのを使うか.

いんじゃないかと思います .

さきほど白井さんが，人聞のモデルを混乱状態のまま取2 通りあるわけですね.非常にセンスのよいツールを作って，かゆいとこ

り込むのはいけないといわれましたが，現在のユーザ・イ

ろの隅々にまで手がとどくような機能を持たせるのか，あンタフェイスのほとんどは.しっかりしたモデルなしで作

るいは，もっとシンプルなものにして.人聞の方がそれにられています . それよりは.人聞が頭のなかに持っている適応するか，ということです.

モデルの方がまだマシだ.そこで.一刀彫りのかたちで，

‑
3
8
‑

SeamaUVo
l
.3N
o
.
3
‑
4

3
r
dSEAEnvironmentWorkshop

人聞のモデルを利用しよう ， ということになっているのでものはいらないといっても，これまでずっとBasic に慣れはないでしょうか?

親しんで来た人たちですから，どうしても 'GOTO lO'を混乱を持ち込むのは人聞の方が悪いので，コンビュータ

したいとか.

'GOSUB1α氾'と書きたいという(笑い) .

そういう要求がまず 1 番目に出てきたので，あえて今回やソフトウェアが悪いわけではないという気がします .

は，システムとしての整合性に目をつぶって行番号をつけ(め Smallta1kと U凶X. そして行番号の問題

ました .

佐原:

佐原:

ところで.青木さんにうかがいたいのは，どうしそうした表面的なユーザの要求に応じても，開発てSmalltalk で Dnix をいじろうとしたのかということで生産性の向上は.せいぜい 2 倍がいいところです.しかも，す.

'GOSUB 1α)()'というのは，初期のマイクロソフト系

私が考えるに. Dnix はそれなりに使いやすいけれど，Ba sic の話で.現在はそうしたステートメントを使わなくすでに過去の異物になりつつある(笑い) .だったら，別てもすむように. Basic ですら改良されて来ています.そに Smalltalk で一生懸命 Dnix の面倒を見る必要はないん

れを元に戻してしまうのでは，せっかくMac を使うのにじゃないかと思います .

悲しいんじゃないかな

それから，吉村さんへの質問は.さきほどの行番号のことか説き伏せて欲しかった.
私も，むかしとですが.やっぱり.ああいうところで妥協してはいけな
いんじゃないか(笑い)と思うのですが.いかがでしょう

もう少しがんばって.ユーザを何

COBOL の構文エディタを作るプロジェ

クトをやったとき.行番号をつけろという圧力がありましたがダメだ.たとえこのツールが使われなくてもいい.

か?

行番号をなくすというのが . Mac や Dnix の 1 つの基本思想であるわけで.そこを曲げちゃったら.ユーザ・イン

行番号はっけない」とつっぱって.結局.そのエディタはあまり使われなかった(笑い)

.

それは，かれらが行番号と一緒にそのうち滅亡して行く

タフェイスの基礎としてのモデル自体が ， 意味をなくして.

しまうんではないかという気がします.

んだから.それでもかまわないと思っています(笑い)

青木

それくらい過激にやっったほうがよいのではないでしょう

Xerox 自体は独自の岱を持っていて.全然

Unix なんかに目もくれなかったというのが.過去の歴史

か?

です.ところが.いつのまにか Dnix が世の中にはびこっ吉村{智てしまい，このままでは Xerox のマシンが売れなくなっなんていりませんよ J という説得が通用しませんでした .

た(笑い) .そんな涜れの中で Dnix の上に Smalltalk の次はもう少し強硬にやってみます.

仮想マシンを乗せようか，などというプロジェクトが起こ

新聞:ってくるわけです.

今回は，たしかに私の力不足で行番号

私は少し佐原さんとちがう考えで，たとえば.デ

ジタル・ウオッチの時代になっても，やはりアナログにこひとことでいえば，世の中に涜されているわけですが，だわる人がいるように.むかしながらの習慣を好む人がい

私個人にとってのモティペーションは何だったかといえば.

つもいるんだと思います.そういう人たちのことを.少し周囲にこれまで Smalltalk や J-Star の環境に慣れ親しんだは考えてあげなければいけないという気がします .

人たちが大勢いて，かれらがなかなか Dnix になじめなかところで.行番号をなくすにはどうすればいいかというったんですね . 佐原さんのように Dnix もMac も両方好とこのツールはとても便利ですが.行番号を使っていきという人ばかりだといいんですが.ふつうはそうではな

ると，時々落ちることがあります J

い . そこで.その人たちのために，むかし Dnix を経験しな仕働けを組み込んでおけば，自然にみんな行番号を使わてなくなると思います.

C 言語が分る人間が一肌脱ごうということで ， たまた(笑い)という意地悪ま手がけた仕事です.

深草E弘泰(アスキー

吉村{智ュータて' あった立場から(笑い) .いまのお話の状況説明

行番号の話ですが，開発しながら，たしかにMac の思想と行番号は一致しないなと感じていました.

かつて. Basic のディストリビ

をさせていただきます.

でも，ユーザの要求をまず第一義に考えてあげたいとい

たぶん，お使いになっているBasic は，もともと小さくう気持ちがありまして.そうするとあちらは，どうしても作られたシステムなんですよね.あれは 8 バイトだからこ

行番号をつけて欲しいというわけですね.こちらがそんな

そ，ああせざるを得なかったという事情がある.一方，

‑
3
9
‑

3
r
dSEAEnvlronmentWorkshop

恥1ac の上で動くBa sic のインタフ・リタやコンパイラの場

S
e
a
m
a
l
lV
o
l
.
3No.3‑
4

もう.そんな機能が試みられているのかも知れませんが合.そんな制約はまったくないわけです .構造化Basic を

ちゃんとサポートできるわけですから ， なければしょうが務水:ないけれども.あるものを使わないというのは，私もちょではないかと思います .

っとおかしいなと思います.

率直な感想をいわせてもらぱ，ちょっと凝りすぎ

さきほど吉村さんがおっしゃった，状況とか手順によっ

そういう歴史的な背景はあるんですが.言語もコンパイて情報にアクセスするというのは.非常に面白と思いましラも単なる商品ですから . よくないと思えば捨てればいい

たが，視線の動きにつれて画面がスススと動く仕鑓けは.

(笑い) .いまあるものの中から.何を選ぶかということ

作るのに苦労する 111には.あまり効果はないんじゃないかだと思うんです.

と思います.ひとことでいえば.あまりよくないといって(6)ウインドヴとユーザ・モデル

岸田孝一 (SRA)

S震源 :ワークショップのレポート(証AMAIL Vo1. 2, No.9) のるんですが.... (笑い) .

それから，私からの問題提起ですが.みなさん「マルチウインドゥを開いてマウスで仕事をするのが便利だ

お手元に配布したアメリカの環境

34 ページに，ユーザ ・ インタフェイスの項目があって，」といわれますが，私自身Ma c を使ってみて.必ずしも

さっき白井さんが出された問題と，いまの中野先生のお話

そうは思いません.

の両方に関連するような指摘があります .

Mac のスクリーンの情報量は非常に小さいので.あの上マウスとかビットマップとかウインドゥは，単なる仕鋳でウインドゥを開いて仕事をするのは，机に書類が山と積けというか，ユーザ ・ インタフェイスを実現するためのメ

まれている . そのどこか片隅にすきまを見つけてメモをとディアに過ぎないわけで，インタフェイスを考える上で 1

る(笑い)というイメージに近い .

番大切なことは，ここに書いてあるようにシステムがもちろんMac には他に，サイドキ ッ クなどのように.
画面を全部入換えてしまう仕鍋けも用意されていますが.

ユーサ'の行動をどんなモデルとしてとらえているか ?J だと思います.

ユーザに提供できるインタフェイスの環境は.どんな場合

つまり.ユーザがワークステーションを使って仕事をすにも程度の制約があるので.その中から何を選ぶかは ， かるプロセスや.結果として得られる(ドキュメントとかプなり重要なファクターだと思うのです .

ログラムとかテスト・データなどの)プロダクト全体の体中野秀男(阪大系をきちんとモデル化しなければ，よいユーザ・インタフ

悲しいことに，うちの大学ではまだもσro 1∞'を教えています(笑い) •ェイスは作れないだろうということです.

それはそれとして，いま.卒研のテーマで学生が 1 人.

ただ問題は，モデルというのはある種のスタンダードでウインドゥの話をやっていますので，もしよろしければ，

すから，それが確立されると，ユーザの行動はかくあるべ

みなさんの御意見をお聞かせいただければと思います.

しだとか，開発工程はこういう順序でなければならないとまず . ウインドゥが見にくい . これについては，かなりかいった形で，何らかの強制力が働いてくる.

お節介なウインドゥ・マネージャを考えて.ウインドゥの

いまSmalltalk とかMac とかの評判がいいのは.そう

最適配置を行おうとしています . 最適配置というのはちょいう意味でのモデルを持たないシステムだから，ユーザがっといいすぎで，各ユーザ固有のルールに合せて，画面に勝手に自分の頭の中にあるモデルに合わせて.ユーザ・イ

触っているうちに.ウインドゥが自然に動いてくれればい

ンタフェイスの仕織を使えるからでしょう . そういう特徴

L、-が，ごく一部の人たち(ハッカーたち? )に非常に好まれそれから.ちらかった書類については. 一種の電子秘書ているのではないて'しょうか?

ぷたいなプロセスを，パックグラウンドで動かせばいいん
じゃないかと考えています.

もう 1 つのアイディアは ， ユーザが視点(つまり目)を動かすと，関連するウイ ン ドゥが(お節介マネージャーと

しかしふつう」のユーザにとっては，あらかじめシ
ステムの中に仕事の手順についての大まかな領掌モデルが存在し，その細部は自分でカストマイズできるようになっていたほうが . 便利だろうと思います .

か電子秘書の手で)自動的に連動するようにしたらどうか

いまの中野先生のお話は ， その 1 つの具体例のように感な(笑い) . ということです . ハイパーテキストなんかで，じました.また.さっき白井さんがいわれたことに私は賛

‑
4
0
‑

SeamallVol.
3No.3‑
4

3
r
dSEAEnvironmentWorkshop

成します.この世の混乱をモデル化せずにそのまま持ち込

流れてしまう.たとえば ， 行番号があってはいけないといむのではなく.少し義理すれば.ユーザ-インタフェイス

う人と.欲しい(または必要だ)という人とのあいだの哲

はずいぶん改善されるのではないでしょうか?

学論争になってしまうわけですね(笑い)

佐原:.

行番号があってはいけないという人は，なぜあってはい

たぶん，事実関係をまちがえていたと思うので訂けないかを具体的かつ定量的に説明すべきであり，それが正しておきます.
私や青木さんがいっているマウスとかマルチウインドヴ

できないなら両方用意しておくのがツール提供者としてはとかは . オブジェクト指向風の一種のモデルをペースとす

正しい . ですから.吉村さんはそれ程いじめられる必要はるものであり.そうしたソフトウェアと密接に結びついてない{笑い)というのが私の意見です.

います.ひょっとして，一部の人(たとえば . むかしの佐原:

PCl∞ユーザとか)は.物理的にウインドゥが複数になれな評価が行われていて.たとえば. Xerox での分析結果にば，それだけで使いやすくなると誤解しておられるようなよれば，行番号つきのコマンドを主にするようなエディタ

気がする .

の場合，エラーの発生率が非常に高いという数字が . すで

Smalltalk やMac のように，何らかのモデルをベースにプログラム・エディタについては ， かなり定量的に出ています . その数字をどこまで信用するかは別として，

マルチウインドゥやマウスを使っているシステムと.そう

大体 5 倍位の開きがあるといわれています.

ではないものとは ， はつりり区別しなければいけません.

加轟:プログラムの作り方にもよりますが

1 つの手続ところで.中野先生のいわれた視線の動きを追うというきが長いものを作る人は，行番号があると自分がいま手続試みですが，これはすでに誰かやっています . それによるきのどの辺にいるかがよくわかる(笑い) . だから ， フラと.人聞の視線というのは.きちんと 1 点だけを見ていなッ トテキストの場合なんかよくないんだろうけど，うまくいらしいですね.ウインドゥを見ていながら.ときどき遠使えばそれなりに使える.使いたい人は.たぶん.そうい

くの女性に目を走らせたりとかで(笑い) .どうもその線

うところがうれしいから使っているのでしょう.そういうはダメなようです .

人がいるかぎり，やはり行番号が必要だと私は思います .
そういう人は.多少効率が悪いのを容認しつつやっぱ(η 定量的分析の必要性
加.

ﾘ
I (東工大りいいもんね」といってるわけですから.
ユーザ ・ インタフェイスを考える

時に.提供しているシステムのモデルの話はもちろん重要(8) リレーション仁ついてで，いままで議論されていたところですが.もっと大きな費量谷問題は.たぶん.ユーザのモデルのほうにあると思います .

章 (PFl乃:

これまでの討論を聞いて感じたことは，コンビュータをビジュアルに使おうという考えが.

ところが，そうした研究はこれまであまりされていない.

これからますます重要になってくるということですね.人きわめて原始的な問題.たとえば，ある入力を受けつける

聞は.他人に意味を伝える時に，あらゆるメディアを使っのに ， メニューを出してマウスでたたかせるべきか.キーていますが ， マシンとの意志伝達も.それと同じようにマボードから遊ばせるべきかというような場合に，設計者のルチメディアで考えるべきでしょう.

趣味で，ゃっぽりマウスの方がいいだろうとマウスにしてしまうというのが現状でしょう .
しかし，この程度のレベルでは.それなりにきっちり研

また ， コンビュータ自体も ， 単なる計算篠械ではなく，マルチメディアのコミュニケーション装置である.そう考
えると，コンビュータの中に何を入れてあるかによって，究している学者が何人かいて，ユーザがキーを打つのにどマン・マシン ・ イ ン タフェイスを議論すべきであり.当然れくらい時聞がかかるとか，キーボードから手をはなして話の切り口が変ってくる.青木さんのシステムも，ただマウスをつかみ，さらにポインティングするまでにはどれ

Unix の上に Smalltalk の皮をかぶせたという観点だけかくらい時聞がかかるかといった定量的な測定や分析がなさら論じても，あまりおもしろくありません.それでは.

れている

Unix にできることしか表現できない.本来，マウスとかそうなってくると.ユーザ ・ インタフェイスの評価の方法もだいぶ変ってきます .
ところが.もう少し複雑な問題になると，いまのところ，

マルチウインドゥは，マン ・ マシ ン・ インタフェイスを論じる場合のメインテーマではないはずです.

そういう定量的な分析がないので ， 議論が宗教的な方向に

ところで.

‑
4
1
‑

1 つ単純な質問なんですが，リレーションを

3rdSEAEnvlronmentWorkshop

SeamallV
o
l
.
3N
o
.
3
‑
4

どうプログラミングすればいいか.工夫があったら聞かせているものがそれ自身だということです.ユーザの白からて下さい.

何かをかくして，ほんとうにあるものじゃないものを見せ青木:るようなやり方は.いけないんじゃないかと思っています.

要は.関係性だけを操作できるものを，オブジェ

クトの世界の上に持つんです.そこからいろいろ操作する

叢野:という形でリレーションを具体化しています.オブジェクせるというのは.それも 1 つのモデルなわけで，ユーザにト指向でリレーションを扱って行くと，結局はオブジェク

幻想を見せるという Smalltalk のやり方も，また 1 つのモトになっちゃうんですけれども，私自身は，リレーション

デルです.さらにまた，さきほど落水先生がいわれたジェはオブジェクトではないと考えていますので，そういう具ネリックなモデルも考えられる.これもまた 1 つメタ・モ

体化をして行きたいと思います .

デルだと思います.

務水:

たぶん新田さんのいうあるものをあるがままに見その点に関して.どういうリレーションを中に埋要は.どこからスタートするかということだけで.基本

め込まれているのか.人聞にまかせる問題は何で，ユーザ的には，ユーサ'が自分でカスタマイズできるジェネリック

・インタフェイスで処理する問題は何で，どういうタイプなものが必要でしょうね.

のものがユーザ・インタフェイスの改善に貢献するのか，

まだよくわかっていない.さきほど，コンビュータの世界

1 番最初にどこから始めるかが.

というお話をおうかがいしたい .

へ現実の混乱を持ちこむことのよしあしが議論されました

それから，吉村さんには，ユーザ-フレンドりというのが.実は，コンビュータの上では，現実の世界ではできなはわかるんですが.個別にいちいち対応していたらきりがいこともできるわけで，そこまで考えて踏みこんで行かなない.だから.何かジェネリックな仕治けを用意して.カ

いといけないと思います.

スタマイズして行くことになるのでしょうが，メカニズム中村:の話に入る以前に何らかのポリシーが必要だと思います.

やっていたんですが.われわれ人聞は.たとえば，歩行す

私は，いまの仕事に入る前は，大学で脳の研究をそのあたりに関して，大学の人間にはわからないような，

るとかものを掴むとかいう動作を，意識せずにやっていま開発現場での実感をお聞かせ下さい.

す.それは，小脳の部分に内在したモデルを持っており.

青木:

そのへんが下位の神経組織とフィードパックをやりながら本質的には，オブジェクトがなくとも関係性だけはこの世の中に存在するだろう.関係からすべてのものを動いて行くんです.

起こせるんじゃないかという考えを.自分の線底に待って

マン・マシン・インタフェイスに関する議論では，よく.

います.実際にものを級う時には，対象世界へ落しオブジ

ユーザ・フレンドリであること(つまりある意味でユーザ

ェクト化して，みんなに見せる.ですから.さきほどお見にこびること)が大切だといわれますが，しかし，実は，せした Unix も，その 1 つのアプリケーションに過ぎませこれが人間のほんとうの姿ですよと押しつけても，ほんとん .本質的には.関係とかオブジェクトの方向へ，自分でうにそれが正しければ.それを使い慣れると使いやすいとはどんどん行きたいなと思っています.それをどうやっていうことカfある.

作るかは，いま模索中です.

だから，いまここでいろいろと論じられている問題のな
かで大切なのは.いったいどういうモデルが人聞の行動を(9) ユーザ・モデルについて正しくとらえているかを考えることであり.また，いかに

吉村{智してユーサ'にそうしたモデルを認識させ，それに移行させ

ほんとうは，ユーザ 1 人 1 人の好みに合ったものを作りたいんですが .現状としては ，ジェネリック

て行くかが ，ポイントになるのではないかと思うのです.

なものをいくつか提供して，それをカスタマイズするアプ

さきほど，キーボードを打つのに何秒かかるかといったローチしかできません .そうした過程で，ユ ーサ'が使って話がありましたが，それよりは.人間に内在するモデルをいくうちに.

いかにして構築できるかということのほうが，ユーザと織1 人 1 人のくせや作業スタイルに応じてユー

ザ・インタフェイス自体が変化していく，というようなも械とのあいだのインタフェイスを豊かなものにする上で，のを提供したいと考えています.

重要だと思います.そのへんで，最適なモデルが何かにつ新田:

いては，自分自身もまだ.答を出せずにいるわけですけれ

私のERAS の開発方針は.青木さんと逆で.

"WhatYouS
ea15 羽市at 1
t1
5.
" つまり変なモデルを持ちども.・・・-込んで(笑い)何かの皮をかぶせるのでなく.ユーザが見緑川侍史(三菱電織‑
42‑

インタフェイスがユーザごとにSeamaUV
o
l
.
3N
o
.
3
‑
4

3
r
dSEAEnvlronmentWorkshop

たとえば . そのことが顕著に出ているのがどんどん変るというのは，アプローチとしてはよくないのではないかという気がします .
ユーザは，スイ ッ チを入れただけで，自分の好きな環境が動きだすようになっていて欲しいわけで，わざわざ苦労

X ウインドゥです . 何でもかんでも変えられるようにしてあって.それをがしかも簡単にできるようになっているから.みんなが文句もいわずに使うんですね.

して.いろいろな定義を変えたりしたくない.ユーザ・イ

だいたい.ユーザ・インタフェイスの基礎は.フィーリ

ンタフェイスが自由に変えられるような綴檎を用意し.個

ングとか感性ですから.十人十色でバラエティがあるほう々のユーザに対し，その ジ ェネリックな徳織を使って，バが自然で.変に統一されたら気持ちが悪い(笑い) .やっラエティに富むインタフェイスを提供した場合 ， あとのおぱり，自由に変えられるようにするしかないだろ う と思い守りがきわめて大変になるでしょう .

ます.

したがって，システムに内在すべき本質的なモデルを，たとえ若干まちがっている部分があっても.あらかじめ作(10) ふたたび Sm瓜lta1kと Unix についてっておくことが本筋ではないかと考えています.ユーザの林:

目的とその作業のモデル化がまずあって . その上でインタ

Smalltalk の皮をかぶせたのでは. Unix にできることしかフェイスというのを考えるべきであり.個々のユーザの恋表現できない」という否定的な発言がありました .

ru凶x の上にしかし，いま Unix の上でウインドゥ・システムを作っ

意的な要求にしたがって流されて行くのは，決して正しいやり方とはいえないように思います.

ところで.さきほど熊谷さんからている人たちが大勢いて，大変なお金と時間をかけて仕事

ただ，モデル化の議論のなかで，ジェネリックなユーザをしているわけです . ところが .青木さんのアプローチで・インタフェイスのモデルというのは.どうもよくわからは.わずか 4.....5 日の労力で.ほとんどそれらと同じ成果ない . もう少し個別的なモデルの話を徹底すべきだと考えを途成してしまった . これはスゴイことじゃないかと私はます .

思います .

しかも. Unix の上にSmallt叫k のよさまで取り入れてわれわれのところでツールを作るときどうやってユーザ・インタフェイスを決めるかといえば，ターゲ ッ ト ・ マシ

いる . いまや ， 単に Unix の上にウインドヴ・システムをンの上で利用可能なインタフェイスのメカニズムを，一通作るだけでは . あまりおもしろくない(笑い) .坂下さん.

り使ってみてから，適当に選択・組み合わせを行なうといすみません.別に GMW がつまらないというわけじゃあう形になります.あくまで，コンビュータあってのインタ

りません(爆笑) .ただ.青木さんのやったことは.それフェイスですから，対象とする機械に依存して変わって行

よりスゴイんじゃないかと私には思えるんですが ..，. .

く .

費量谷 :

どうも誤解されているようですが，私は別に.青そういう風に考えると.ユーザ ・ インタフェイスという木さんのお仕事をそんなに否定しているわけじゃありませのは . これが基本だという確固としたよりどころがない領ん.何を隠そそう，実はうちでも同じようなことをやって織ではないでしょうか . 頼りになるのは人間だけ.ユーザ

いますから(笑い)

.

ただ . Smalltalk を介したときの Unix のプロセスの取としての人間だけではないかという気がします.

最後の御指摘はまさにその通りで.ユーザ・インタ

り級いなどは ， ある意味でおもしろくない.なぜつまらなフェイスという名前の示す通り.ユーザしか頼るところは

いかといえば. Smalltalk 自体の制約が結構あって，たと

事事:

ない .
しかし，人聞をモデル化して，それに合わせてインタフ
ェイスを作ればいいといっても . はたして人聞は人聞をモえマルチ ・ ウインドゥで動いたとしても .X ウインドゥには遥かに及 lまないことが，想像すればすぐわかることでしょっ.

デル化できるのだろうかという疑問がある . それができな

全面的に否定しているのではなくて，いろんなことをやいから，いろいろとジェネリ ッ クな仕俗けやメタ ・ ツール

らなくちゃいけないというのは，よくわかっているんです.

が作られるのでしょう . そうすれば.ユーザがどんなにわ

私がいいたかったのは.最初に . 何をどう表現するかとい

がままなことをいいだしても . 何とか対応しうる . それでう 》岱但の基本思想、のほうが重要だということです.そう

いいとはいいませんが，それしか道はないんじゃないかと

い う コ ン テクストのなかでの発言だと理解してください.

思います.

岡本:

‑
4
3
‑

私自身は Unix が好きで ， 自分に 1 番フィットす3r
dSEAEnvlronmentWorkshop

SeamanV
o
l
.
3N
o
.
3
‑
4

る》岱11 のような気がしています.ところが.おそらく日
頃 Jstar だとか Sma Lltalk マシンだとかを使われている人

討論をきいての感想

たちは.そちらのインタフェイスのほうが気に入っている{参加者アンケート}のでしょう.

音楽にたとえると .

15 年ぐらい前に，ジャズ・ロック

とかロック・ジャズという話があって，それが何年かたつ

田中正則 (SRA)と，フュージョンという呼び方に変わり，それぞれ分化しM聞はやはり.ユーザ自身が作成することが望ました独自の世界を作り上げてきています.そういった意味で .

い.このセッションを聞き，そのための方策としては，ジ

これからは，いろんな世界観をうまく組み合せて，どんどェネリックな恥岱但を提供し.それをユーザにカスタマイ

ん新しい試みをやって行くことが重要て'はないかな，といズさせるのがよいと思った . その場合 . ジェネリックな仕

うふうに思います.

鈴けをどう作るかがわかったとして.残るのはユーサ'教育の問題である . どうしたら.ユーサ'をその気(カスタマイ(11) まとめズをやる気)にさせることができるか?

坂下:

しい.

ありがとうございました.なかなかいまのはいい

だれか教えてほ

まとめだったと思います(笑い) .私がチェアマンとしていおうと思っていたことを，いわれてしまいました.

11野晃延 (FχIS)

たしかに，ユーザ・インタフェイスについてみなさんい
ろいろな意見を持っておられる.その多様性を，この場で恥⑪包のモデルをジェネリックなものにすると，以下のような問題が起こるだろう:の討論を通じて強烈に意識しました . いままて'のユーザ ・(1) カスタマイズ容易性と一貫性とのトレード・オフ.

インタフェイスというのは.未熟なモデルというか ， 多様(2
) カストマイズは.ユーザに自分の仕事をあらためて性があるようでないようなシステムを.どっちゃりとぶち「意識」しなおすことを強制する.

まけて来たものであるような感じがします.

(3) カストマイズしたあと.それがセマンティクスにおなかなか楽しいセッションでした . 3 人のスピーカの方

よぽす変化や正当性を，だれがどう保証するのか?

々.また討論参加者のみなさん，どうもありがとうございこれらの問題をある種のメタモデルとして定義する試み

ました(拍手).

を，だれかがやってみるべきだろう.

佐11千明(長野県協同電算)

これから MMI は.マン・モデルまたはマン ・ メソッドのインタフェイスと解釈することにしよう.

吉村智香子ほiS1)

ビットマ ッ プとマウスがあれば ， それだけでよいユーザ.インタフェイスが提供されたと誤解する風潮があるように思います.

「ユーザの好みにあった」インタフェイスを提供すればよいのか人聞の内在するモテ'ル」を作っていけばよいのかで，議論はかなり盛り上がりましたが，結局は，いまあるものを積み上げながら . ユーザ ・ インタフェイスは進化して行くということのようです.

田中慎一郎 (SRA)

τ"RON のキーボードの話.あれがいいものかどうかは

‑
4
4
‑

SeamaUVo
l
.3N
o
.
3
‑
4

3
r
dSEAEnvironmentWorkshop

知らないが ， アイウエオ JI肢はどう かと思う.ほんとうに普タとのコミュニケーション(=メッセージの交換)という及させるつもりであれば.最初おぼえるのが大変でも人間視点が必要だと思う.メディアとしてのビットマップ+マ

工学的に使いやすい配置になっているほうがよいこともた

ウスやメッセージの手段としてのグラフィックだけでは不しかである.

充分である.コードとコンテクトへの考慮が今後必要だとだれにも選ばれないツールは消えて行くという考え方は，感じる.

危険.人間は ， 食わずぎらいが多いので.ょいと思われる

ものは，それを使わせる努力なり方法を考えることも重要

北野重量明 (KCS)である .

キャラクタ一端末+キーボード

ユーザに涜されるのはよくないが，ユーサ' に任せる部分があるほうがよいと思う.

JCIã:編集してから，

Home キーを押し(コマンド行ヘカーソルが移る) ,"SUB"(
Submit =実行)と入力してリターン ・キ ーをた
たくのは，慣れた人ならよそ見してでもできる.
メニュー+ビットマップ+マウス:

桜井麻里 (SRA)「材料は豊富に，組み合わせ選択はいろいろできるようメニューの項目を

よく選ぴ損ねる(すぐ上や下の項目を選んでしまうことが』こ」といっても，モデルは必要である . どんなに便利なカある) .よくメニュ ーの項目を見ていないとダメ.手先のスタマイズ機能があっても . 自分では何もしない人がほと細かな動きが苦手だと.編集のさい 1 文字ずれた所をポイ

んどだから.使いやすいインタフェイスの基本形も必要だ .

ンティングしてしまう.
τ"ss

それにしても，みんな同じことを悩んでいますね.私も悩んでいます.

のダム端末や，

I-Star , J-Star上でのエミュレータを使って思うこと:だれが何をするのか.どの程度."，といった観点から恥⑪包の要求を探すとキリがない.好きな三泊あさ子 (SRA)

ものを各々が選ぶのが一番のような気がします.

中村さん，佐原さんが話した 2 種類のユーザ・インタフ
古田とおる(富士通 BSC)ェイス.
一口にユ ーザ ・インタフェイスといっても，あまりに多Mac , Smalltalkなど，マウスとウインドゥによる勘岱位様で，話についていくのはけっこう大変だ.私もいま， X

だけでなく.キーボード.タッチペン，ジョイ・スティッ

ウインドゥの上でユーザ・インタフェイスを作っていて.

ク.さらに今後新しいポインティング装置が登場したとき

カスタマイズ機能が 1 つのポイントだと感じている .

の恥仏但も考えたいと思います.

コンテクストの重要性は理解できるのだが.それがうまく結びつかない.

井上尚司(ソフトパンク総研)
コンビュータを使うだけのユーザ.ソフトを作るために小椋明彦(東電ソフト)

使うユーザをはっきり区別して》岱但を考える必要が.少聞いている分には.大変おもしろい議論でした . 私も，なくとも現在では，ある.

ユーザ - インタフェイスは好みが強いと思っています.結「いまのマウスやビットマップを前提にソフトを作る」

局 ， 声の大きい人聞が力説したものがその組織での標準とという思想を惑いとは思わない . これに対してマウスして取り入れられるようです.

でがまんできるか ?J という質問は，的を得ていない.

しかし.いますぐにそのためのソフトを作れなくてもよ西岡健自(横河電線)

L 、から.考えうる理想、のハード環境を想像してみることもM恥日はソフトウェア本体と独立に存在しうるのか . そ

意味があるのでは?

の目的は何なのか.試行錯誤の遠鏡とモデル不在の焦りを感じる.けれども，とてもおもしろそうだ.

寺井孝(目立ビジネス線器)
今回の討論に参加された方々は，みなさん ， それぞれ開義幸一 (PFU)

発者の立場に立って，ユーザの感じ方，考え方を自分なり

ユーザ ・ インタフェイスを考えるとき，人とコンビューに勝手に判断しておられますが，かなり思い込みも入って

‑
4
5
‑

3
r
dSEAEnvlronmentWorkshop

S
e
a
m
a
l
lV
o
l
.
3N
o
.
3
‑
4

いるように感じました.さらに.使い勝手のよいものを開現実とのギャップについての議論はおもしろかった.

発するためにもユーザの考え方を積極的に聞くようにしてインタフェイスがユーザの手で自由に変えられるようないただければ，と思います.

ものでなければいけないという点では.多くの人の意見は一致している.では，具体的にどうしたらよいのか?

い小漣幸徳(日本システム・サイエンス)

くつかのアイデアをプロトタイプしてみる必要性を感じる .

h仏狙をそのユーザの技術レベルで考えれば.明らかにその意味で ， 青木さんの成果はすばらしいと思いました.

開発者とエンド・ユーザが同じ b⑪包を持つのは.最適ではないと思う .

久保安志(富士通)

また，利用目的に則して考えると.ポインティ ン グ装置

ユーザ・イ ン タフェイスつまりお岱但の概念を構造的にとしてドット(ピクセル)レベルのポインティングを必要理解することが，もっと行われてよい.考察対象の全体モとするか否かによって.マウス，ライトペン.タッチセン

デルについてのコンセンサスを持つ必要がある，といってサーなどいろいろな種類がある.しかし ， これはらの選択もよいのかもしれない .

の幅はまだ狭く.人聞の日常生活におきかえて見るとなん

レスポンスタイムは ， 加岱包め特性の一部である .

となく「かたわ J のような感じがする.音声など.もっと

親しみやすさも特性の一部である .

ちがったメディアを飯える装置 を考慮しなくてはならない

マウス，電子ぺン等は，人がマシンに語りかけるのではないかと思う .

ための恥岱但言語仕様の一部である .
マルチウインドゥは，人が知的生産を行うときに

海尻賢二(信州大)

使う仕事場という》仏fl の一つである .

ユーザ・インタフェイスとそのボディとなるソフトウェ

個人の好みにあったお岱但というのは .M恥g のアとの関係は?

具体化に関係する .
Smalltalk の MVC+ 依存関係は ， 世界を人が対

鍾友良仔χIS)

象化するためのフレームワークという意味での MMI

島⑪包の中心テーマは . 熊谷さんのおっしゃった通りだ

である.

と思う . 人聞がマシンに何を入れたいか ， どうい う ふうに

Smalltalk

この「入れたい」ものを簡単に表現するか . 逆に.マシ ン

ないという欠陥は，が何を出せるか，どういうふうに人聞がよく理解できるよの問題にかかわっている .

うに表現するか，さらには.人間とマシンとの対話を人間

が，フロ ッ ピーの初期化をやってくれ
島仏fl の具体化における情報隠蔽

ユーザ-インタフェイスがツール聞で整合性が取どうしの対話のようにすべきであるか.など.

れているかどうかも，島⑪包の特性の一部である.

以上，全体に包括されるであろう断片を思いつくままに
盛岡政敏 (KCS)

書 いた .

「 使う人によって変わる . また，使う人の成長によって変わるインタフェイス」というアイデアは重要である.ど2事灘弘泰(アスキー)

うすれば実現できるのか . また，そのためのフレームワー

ジェネリックなインタフェイスは . 一般のユーサ'にとっクは?

て，逆に使いにくいのではないかと思う.適応可能な部分と骨格となる部分の切り分け作業に，かなりの時聞を費や村川貴広ほIST)

したほ う が.よいのではなかろうか?

討論の内容が ， 発表者に対する質問に終始した.もう少し，フロアの参加者のあいだでの質疑や討論があってもよ

近Jl隆彦(通産省)

かった.もっとも，そんな環境づくりを，われわれ自身がお⑪但の多様性やむずかしさがよくわかりました . また.

しなければならなかったのだが目， ...

それぞれの技術者が第一線でさまざまな工夫をしておられることに.感銘いたしました.

近叢康二(ソニー)

‑
4
6
‑

3
r
dSEAEnvironmentWorkshop

S
e
a
m
a
l
lV
o
l
.
3N
o
.
3
‑
4

手筈水浩一郎(静岡大)に内在するモデルが好きなのだろうか?

おもしろかった.ラ ン ダムに，心に引っかかったキーワが持つユーザ・モデルやプロセス・モデルは.あまりにもードを列挙すると :私には . それら

ナイープ(原始的)すぎるように見える .

- 加仏fIの議論の範囲.操作

ま代和正 (SRA)・ らくに操作できるオブジェクト間の関係がキーとなっているとの指摘は.

-関係のマネジメント

どうもそのようである.でも.関係をメタなレベルで定義.視点するというのはどうであろうか?

- オブジェクト管理

自然界は，だれかがまとめて管理しているのではなくて .
すべてのオブジェクトがそれぞれ独特の性質を持ち，それ

市川寛(電算)にもとづいて行動している.やはり.オブジェクトが個々

もう少し討論を続けたかった.最新の恥lli但を持つツーにもっている他のオブジェクトとの関係にもとづいてコンルを試用してみたい .

トロールしなければ，最終的には無理なような気がする .
そこで，中野先生がいっていたウインドゥ・マネージャ

田中一夫(山一コンビュータ)

について思いついたことがあるが.ウインドゥの 1 つ 1 つ加岱位をどうやって作るかは非常にむずかしい . でも何に佐賀を与えて，それぞれのウインドゥが自立的に行動するようなモデルてペウインドゥ ・ マネージャを考えてみてとなくわかったよ う な気がする.

はどうか?
場川博史(三菱電機)

たとえば.ウインドゥ A は， 8 について動きたがるとか .

リレーションの話とモデルの話が概念的で.十分理解できなかった.その他は，非常に有意義だった.

Cはきらいなので近づいたら逃げる，といったぐあいである.当然，その時どきの状況なども彫響するわけで.ウイ
ンドゥ聞の力関係は . 時間とともに変化して行く.

佐原伸 (SRA)「マルチメディア - アーキテクチャのユーザ ・ インタフ

加藤朗(東工大)ェイス，どうすべきか ?J という問題を発見できた . 近来
まれに見るおもしろいセ ッ ションだった.

ユーザ - インタフェイスの問題があまりに広いので ， 議論が散失してしまいがちである.
プログラム(システム)が提供するモデルと，モデルが山浦恒央(目立 SK)固定された時点での入出力の技術 . この 2 つの議論のどち

いろいろな意見を聞いて . 自分の考えの狭さを思い知りらを好むかは，あきらかに「人種」によってちがうようだ .

ました . 今日は . ずいぶん勉強になり.少し自分が大きくなったような気がします .

場内泰鰭(長野工専)
加岱但を考える場合.われわれ々ソフトウェア技術者が事事

開発作業を行う場面でのそれと，エンド・ユーザにとって

香 (SRA)

rsm.⑪rrrのアプローチでは UNIX のできることしかできない J とは，

ほんとうか?

Sma Lltalkのよい部分とUnix との融合とは考えられないだろ う か ?

のそれとは，別個に考えなければいけないと思う(たぶん.

両者が一致することはないだろう) .

しかも.簡

このセ ッ ションでは，ワークショップの性格上，前者に単に実現できたのなら . X ウインドゥや GMW よりす ぐ

ついての話が中心であったが.エンドユーザ向けの》岱包

れたアプローチかも .，.. とはいいすぎかな?

についても討論する場がほしい.

言語のユーザ ・ インタフェイスは，シンタ ッ クスかな?
白井遺産美 (JIP)

岸田孝一 (SRA)

Smalltalk やMa c が好きな人たちは，これらのシステム

よいマン ・ マシン・インタフェイスとは.生産性や信頼性なのか，気持ちがよく楽しいことなのか?

‑
4
7
‑

両方であれ

SeamaﾟVol.
3No.3‑
4

3rdSEAEnvlronmentWorkshop

ばいいのは当然だが .

ての操作」をキーボードから手を雌さずに行いたいのである.エンド・ユーザのためのインタフェイスと，プログ

杉田重量明 (SRA)

ラマのためのそれとを.ハッキリ区別して討論すべきだっ》⑪E を討論する場合，よくハードウェア上の問題とソたと思う.

フトウェア上のそれとの混乱が起こるが，今回も一部そうしたことがあった.キーボードやマウスとそのウインドゥ

井川裕基 (JIP)表現などがそうである .
私が一番興味を持っているのは.ソフトウェアの可視的インタフェイスはユーザの好みに合わせて:ユーザのモデリング.
抽象的なモデル:な表現であり.どんな表現方法がユーザにとって大切か.

コンビュータ化しやすいが，まちっ

そのメカニズムや定量的な評価手段はどうか ， などの問題ていたら.もうおしまいちょっとした例外処理」がうであるが.あまり議論がはずまなかった.

まく表現できない.

多彩( ?)なモデル:

コンビュータ化しにくい(要素酒勾寛 (SRA)が多いから) .ユーザは.自分が何をどうしてよいのか.

マウスは，位置を決め.ボタン・イベントを起こし，移わからない.

動を表現することしかしていない.より進んだ入力装置とは何か?

さて.これらの中聞の位置で，どんなものを選べばいいのか?

この選択はむずかしい .

ウインドゥが多いと使いにくい.何とか，仕事の本質に関係ない作業を自動化できないだろうか?

11谷章 (PF1J)

セクレタリ・システム，つまり.勝手に整理される電子(1) マルチウインドゥとマウスの使い方
それなりにおもしろい.やはり， Mac の彫響は大であ

手帳があれば，いまのオンライン・ドキュメントの大部分

る . ロボット作成にもMac が使われている.

はいらない .

ユーザ・インタフェイスに関しては，個々のツールの出(2) マルチウインドゥの改善案

来・不出来は，あまり問題(重要)ではないような気がす

具体策は.連動するメカニズムが必要.

る.それらを整理.統合する仕鍋けと思想、のほうが重要でbr(3) 為仏，fiのモデルはないだろうか?

リレーションの操作と表現.オブジェクトとリレーシ

すべての構造を平たく見せようとするところに問題があョンは別物と考える.

Wha
tYouS
ee1
sWha
t1
t1s だ

る.紙を漉くところから始めたくはない.私たちの「ぺンと，リレーションはオブジェクトの属性になる.

と紙 J の徳準は何か?

(4) 勘仏，fiの方向

マルチメディアと自然指向 .

3 人の発表者の意見は:新田ぺンの作り方」を与える方法論
吉村新しいぺンを作った J

小林貞幸(電算)

青木ぺンの作り方」

やはり，みんながそれぞれ，自分で使っているツール(といったところか?

ハード.ソフトともに)の話に終始してしまった.討論に参加するには.使った経験がなくともよいはずであるが，荻生準ー(日本システム)

つい汎用機ユーザは，こういう場では弱気になってしまう.

Unix を使い始めたばかりで.いまいち話がつかめない.
参考資料のつもりで聞いています.

汎用織のCobol の世界から見たゆ但についても，話したり意見を聞きたかった .

吉村鉄太郎(管理工学研究所)

中野秀男(大阪大)キーボードとマウスは.本質的に異質なものであり.そマウスはいいのか?

マウスに視点を代表させ.お絵かの 2 種類を併用することをユーザに強制するシステムはききをさせているいま.ポインティング装置がマウス，お絵

らいだ.たとえば，タッチ・タイプができる人はすぺ

かきはぺン.耳と鼻と皮膚は?

‑
4
8
‑

3rdSEAEnvironmentWorkshop

加⑪包の定量評価 :SeamaUV
o
l
.
3N
o
.
3
‑
4

各ユーザの能力の差をどう取り込

SEA 刊行

めばよいか.などの問題はともかく ， 定量評価は . どんど

報告書・論文集のご案内

ん試みてほしい . ただし ， プログラムの複雑性論議の二の舞にならなければよいが .. . ..

Mlv但のモデル化:
L仏fl の多様性 :正直いってよくわかりません .
大賛成です .

現実世界の混乱をコンビュータの中へ持ち込むと，人間とコンビュータのどちらにアダプ

トすべきか?

好きなほうを選べばよいのではないか?

行番号:

古い人たちのことも考えてあげたい.人が慣れてくれるまで待っか?

ポートやシンポジウム・プロシーディングスのうち.次のものはまだ若干在庫が残っています.ご希望の方にお頒けしますので.事務局まで郵便または FAX でお申込

新聞怠 (SRA)

オブジェクトの境界:

これまでに SEA から刊行されたワークショ ッ プ・レ

み下さい . なお . 定価はいずれも 3α氾円(郵送科込み

)です .

第1 回
実践的ソフトウェア開発環境に関する集中討論

インタフェイスの基本は.叫ぶ

1986 年 2 月

新潟県長岡市ことだと思う.
第2 回

実践的ソフトウヱア開発環境に関する集中討論

御喜家賃子 (YHP)

1987 年 2 月

人間すなわちユーザというのは.いろいろと勝手なことをいいだすものだと思った . たとえば.マルチウインドゥ

新潟県長岡市

第4 回ができたことにより，同時にいろいろな情報を入手できて夏のプログラミング・ワークシヨヲア

ープロジェクト ・ プランニングのケース ・ スタディ

嬉しいといいながら，ウインドゥが多すぎると.整理がつ1986 年 9 月

かないと文句をいいだす .

岩手県盛岡市

あーいえばこーという感じで，とても対応しきれない.
第5回

やはり ， そうなってくると，何でもユーザの希望を聞いて夏のプログラミング・ワークシヨヴプ

あげるようなインタフェイスじゃなくて，ユーザの目的とーパグのないソフトウェアを目指してモデルに合わせて，ユーザに自分のワガママを気づかせて1987 年 9 月

岩手県盛岡市

やる必要がありそうだ .
第1 回

強制的に.ワガママは許さないという態度で，マン・マ

ソフトウェア数育に関するワークシヨヲプ

シン ・ インタフェイスを提供すべきだ . それは，たとえば.

実践的ソフトウェア技術者教育を考える

車に乗るためには教習所で訓練しなければならず ， スピー

1987 年 11 月

山梨県八ヶ岳高原

ドを出しすぎると 「 ビュービュー 」 と注意のブザーが鳴り出すのに似ている.

ソフトウェア・シンポジウム '87 論文集

基調講演: "
S
of
t
w
a
r
eP
r
o
c
e
s
sP
r
o
g
r
a
n
u
n
i
n
g
"

車の場合.そうした仕組みは.ユーサ' を守る目的や ， 安P
rof.L.Ost
e
r
w
e
i
l(
U
n
i
v
.o
fCo
l
o
r
a
d
o
)

全のために，さらにはまたマナーを指導するために考えら1987 年 6 月

れている . このような配慮こそが.喜ばれるマン ・ マシン.インタフェイスを生みだすのではないかしら?

東京虎の門パストラル

ソフトウェア・シンポジウム '88 論文集

基調講演 : "USC 勾stem Faαory Projeα"
このレポートは.去る 2 月に行われたワークショップの

Pro
f
.W.S
c
ac
c
h
i(USC)

討論記録および参加者アンケートを編集部で整理したもの

1988 年 6 月

です.残りのセッションは次号以降に

‑
4
9
‑

東京虎の門パストラル

Seama Vo1. 3 , N
o
.
3
‑
4

MessagefromKyusyuI
s
l
a
n
d

九州支部設立報告平尾一浩
ヒラタ・ソフトウェア - テクノロジー

こうした案内状だけで，忙しい( !?)みなさ んが集ま

1.はじめにSEA としては ，関西，横浜，長野，名古屋に続く 5 番れるとは思っていないので，当然電話での勧誘もしました.

目の支部として.九州支部が 3 月 12 日(土)に設立されそして.長野支部の例をみならってプレスにも載せました.

ました .
調脚吻司~ ..布市*ホ刻，...*ホ$司隊司~..‘h ・p ・・吻司加市市・ e ・・・*司脚蜘..命綱脚九州の地にも立A の支部をという声や動きは，かなり(熊本日日新聞:昭和 63 年 3 月 10 日)前からあったのですが，ともかく動きはじめましたので ，その報告をしたいと思います . どういう形で報告しょうか

九州のソフトウェア技術者

企業ワク越え交流ということでいろいろ考えたのですが.これまでのSeamail の方向を踏製するものと ，九州支部らいしいもの県内を中心に九州のソフトウェア技術者が，企業の枠を(世話人の趣味)を合わせて.裁せてもらうことにしまし越えて参加する研究会を結成する.技術者が個人の資格でた.

特に，ドキュメンタリ ー・ タッチのものは.私と藤本さ参加をし.技術と情報の交涜を図るのが目的.各県単位でん(彼女が支部設立に一番熱心でした)がかいたものを.

は県やテクノポリスなどを中心に.企業同士の交涜の場はHST の 20 歳になる福島という内職(? )で小説を書いあるが，技術者同士が研究会を結成するのは九州で初めて.

ている者にまとめてもらいました.

研究会は.

Seamail にも軽い読物

60 年 12 月に全国のソフトウェア技術者でを求める会員の方がいるようなので.そんな要望に答えらつくった「ソフトウェア技術者協会(略称・ SEA. 約

れるかもしれません .

1.2'∞人) J の九州支部として 12 日発足する.
平田機工(熊本市)の関連企業「ヒラタソフトウェアテ
クノロジー J の技術者らが発起人となっており.県内から

2. 設立の呼びかけ

2 月 19 日の日付で，九州の SEA 会員を中心に設立の13 人が参加するのをはじめとして.福岡県 ・ 大分県 18人など合わせて 31 人の技術者で結成する.

呼びかけをしました.

12 日は発足式を兼ねた第 1 回会合を熊本市のヒラタビ-・・..吻司脚刻h ・・・・・・・*測h ・・・・・・......・ e ・刻脚.事調h ・・

九州の会員も福岡

12. 熊本 :13(+33 月入会

予定) .大分: 4. 佐賀: 1. 宮崎 :縄:

1.鹿児島: 3. i中

ルで開くが，年 1-2 回の支部会合を開くほか.各県単位で定期的に会合やセミナーを開催，ソフトウェアの開発技
術や情報を交換するーなどの活動計画を決める.

1 の 35 名 (38 名)となりましたが.その活動へ

ソフトウェア業界は情報化社会の進展を背景に急成長しの参加の場は東京をとる場合が多く，地理的問題で参加がているが，入手不足から深夜に及ぶ勤務を要求されること

鍵しいものとなっています . そこで，九州支部の設立を行が多い.加えて，世界的な技術の進歩には目覚しいものがない.独自の活動形態を確立し，セミナー.ワークショッ

あるため技術者は情報不足に陥り企業という壁の中でプなどの企画.技術活動の活発化などにより，情報の中央取り残される不安感がある」という .
同支部は企業内技術者のほか大学.研究際関の研究者に集権を意識することなく最新情報 . 最先端の技術を我々のものとしていきたいと考えます.

も参加を呼びかけており.広く技術レベルの交涜を図る方

つきましては設立のための第 1 回ミーティングを下記の

針 . 推進役の平尾一浩さん(ヒラタソフトウェアテクノロ

要領で開催いたします.関心のある皆様方の積極的な参加ジー)は「企業の枠を超えた勉強は技術者はもちろん企業をお待ち申し上げます .

にもプラスになる」と話している .
割隣調h 市羽働市$ホ ホ申刻~.. ..・司h ・・h ・祖伝割前調，......・‘h ・測胸訓h ・・・割...・

調R ・・・・..吻跡調h ・・・・・・蜘 羽h ・・訓，.....当h ・・....跡調h ・ e

‑
5
0
‑

SeamallVol.3 , No . 3・4

MessagefromKyusyuI
s
l
a
n
d

(2) プログラム

向けて活動して行くことになった . この報告は，この後に設立ミーティングのプログラムと内容に関しては，この世話人にしていただきます

後の F 熱きこころにおくる』を参考にしてください . また.

その他の意見としては . 次のよ う なものがありました .

参加された方々がどう受け取ったかというのも，この後の・会合の会場は各地区で持ち回りとし，ラフな形で行なr 会員の声』を読めば，わかっていただけるとおもいます.

う .

・ 各県にある情産協のよ う なものと協力してやっていく( 3 ) これからの運営ことはできないか .

いろいろな心配も終ってみれば，ただの妃憂，とばかり・世話人に任期を決め . 全員一度は世話人をやってみるのもいいのでは.

に元気がでてきます.ともかく.当面は次にあげた体制で九州支部を運営していくことになりました .

これらは，今後の課題ということになりました.

九州支部の最大の特徴は.ほかの支部と遣い 8 県を対象

(4) 運営資金としているところにあり . それゆえ謀題も多い.支部内で運営資金は，当面は次のよ う にして行ないます.長野かの情報交換と全会員が集まるには.九州は広すぎて時間的らのカンパ金 3 万+第一回ミ ー テ ィン グ夜の部からのカン問題などもあってそう簡単には集まれない . これではアクパ金 1 万 2 百円は郵送代などに使い.会合での会場費など

ティプな活動はむずかしい.これを受けて.九州支部でははその都度集める.

九州を 3 地区に分け，それぞれ 3 名の世話人を置くことになった.

3 . 会員 の声

当日参加された方々か ら 「声」を寄せていただきました
福 岡，佐賀 ， 長崎 ， 沖縄旭 区

世話人 :

(順不同)

能見，松本，小田*i中縄は九州で一番飛行機の 1更が多い福岡が最適~t Jlf 清 介とのやl断 .

新しい動き(九州の若い技術者たちの交涜)が始まった

策本.大分地 区
世話人:

ことを大変うれしく思っています.こだわりや立場などを中島.後藤，平尾

はずして ， 色々な話が出来 ， お互いに楽しい仕事( ?)が*ちなみに後藤さんは 24 歳の SE 兼.主婦 .
宮崎，鹿児島世話人:

出来ることを期待しております

健区

植村 . 森，藤本

後藤芳美*藤本さんは宮崎，鹿児島地区会員 3 名の助っ人として参加の主婦 .

大分という小さな地域でソフト開発を行っていると.どう してもグロ ー パルに物を見る儀会を持てないというのが現状です . そういった状懸の中てヘ SEA は大きな情報源

あとは，各地区の世話人を中心に活発な活動を行ない ，でした .

しかし.結局 SEAMA正を読むだけで ， 受け身

年 1~2 回予定している支部会合の席において ， ワ ー クシの 一年を過ごして来ました.又その内容もレベルが高く，

ョップ ・ タイプの地区活動報告を行なうこととなった . 年

読んでも興味をもっていたのは会員の声でした.九州支部

1~ 2 回の支部活動では . 充分な意見交換は行なえないとが設立したからには.もっと受け身ではない参加をしたいの声に.オ、ットワークを張りませんかと声が返る .

HSTと思います.

にホストを置き.伝言板形式でとにかくやってみようという意見もあったが . ネ ッ トワーク事情(ネットワーク情事というのも還があっていいなあ)として悶泊寿.

junet の状況や.

たいへんおもしろそ う なのでぜひ成功させたいと思いまYOU‑NET. QUEENS の説明後，とにかく分科会を作りす . ただ，個人的な意見としてあまりシ ス テマティックに検討することになった .

SIGNET は既にあるので . 名称する必要は無いと思います .

を SIGQNET として.

SEA 初の支部内ネ ッ トワークに

‑
5
1
‑

SeamaﾟVol.3 , No.3・4

MessagefromKyusyuI
s
l
a
n
d

舗悶真理子
SEA の会員に入 らせていただきます.

竹内正幸

第一回目にしては盛り上がったと思います.今後の方針，
進め方，次回の議題等についても決まっており.今後が楽

永田和也

SEA の地方支部第 5 番目として九州支部が設立された

しみで期待できると思います.私個人としてもネットワー
クに興味があるので.色々聞きたいと患っています .

わけだが，中央の後追い，他の地方支部のまねをしたりして.九州支部独特の色を失うようなことはしたくない.

久保宏志「太いが短い」の生命を燃えつきさせることなく細中島泰彦

九州のソフトウェア技術者が集まり何かいいこと話してくとも長い」生命の総持を期待します . 横浜に在住して東京に勤務している会員からのメッセージです.

います .
今別府芳僑

キックオフのためにご苦労願いました HST の方々ごく箆見巧
やっとスタートになりました.さぼっていてもうしわけ

ろう織でした.このような会合がほしかった.今後の活動

ない.熱い熱い九州支部にしたい.

に協力して大きく育てていきたい(ほしい) .

飯冨章博

桑原たか子

技術者の方々の意見が聞ける有意義な会だと思う.どん

なかなかおもしろそうな集まりだと思います.次回の集

どん参加して，利用させて頂きたいと思います.知人にもまりにも期待したいと思います.しかし ， 時間的なものが紹介します.

(予定通りに行くのは難しいですが)ちょっと気になります.又，もっとリラックスした場所というか.雰囲気をつ

上妻健一郎

どんどん交流の輸を鉱げて欲しい.

小田七生

くればいいですね(次第にそうなるでしょうカ{) .何か手伝うことがあればやりたいと思います.

杉野緑

今回の九州支部設立を非常に喜んでいます.常々.地方

いろんな興味深い内容で，とても刺激になりました.ソにいるため.業界情報の不足に悩んでいただけに.九州支

フトウェアに対して.問題意識をみなさんもたれていて，部設立に期待します.会合に参加して，他の人々の活発なただなんとなく仕事をこなしている自分を少しはずかしく意見を聞くことが出来，自分自身をリフレッシュできまし思いました.これからの活動を期待します.

た.これから，支部運営のために頑張りたいと思います.
笹村正伸

非常に有意義な一日でした . 今まで.他の支部や本部の松本初美

いろいろな人の集まりで.かつ.どこかで結びついている.ストレスの解消の場であり，我々ソフトウェアにたず

ワークショップやセミナ ー 参加していたが.九州内で.こういうことができてうれしく思います.

さわる者のComm山活 cation の場であり.我々の仕事をもっと分かり易く，世間に認知させたく，努力したいと思っ

義カンナ

興味深く.おもしろい集まりだと思います . 企業を越えてます.今日の会合で，その様な活動の芽が出てきた事を共に慶びます.今日はどうもありがとう.

たつながりを目的としているので，会社単位の集まりでなく.もっと.個人のつながりを作ってもらいたいと思いま

上川清士

す.

東京との差があるとの事でしたが.九州の地域住を利点として拡大していってほしいと思う

門岡春.

‑
5
2
‑

SeamaUVol.3 , N
o
.
3
‑
4

MessagefromKyusyuI
s
l
a
n
d

九州にソフトウェアの首都をおきたい訟村幸一
大変面白い「会」になりそうなので今後が楽しみです.

ただ大分のため水前寺公園発 16:50 しかありませんの

富永伸議
さあ，今から何をやろうかな!

で，時間的に問題があります. HST の関係者各位 ， 大変
お世話になりました .

吉村智香子
今度は，一杯飲みながらやりましょう .

BOF が大事で問中期嘉す.

自己紹介において少しばかりのプログラマの方々の問題点が見うけられた.が，具体的なものが意見として出され内田京子

る事をこれからも期待しております.

様々な分野の方々{企業 ， 学校関係など)が多くてたい
へん勉強になりました.しかし，個人的な希望としては，

平尾一浩

もっと大学関係の方などが参加されると.もっと ， 刺激さ

正直に言います.今日は，緊張をやわらげるため昼に焼れると思うので.そのような方にも参加していただきたい

酎のんでしまいました.ごめんなさい .

と思いました . 何度か話はあったと思いますが.

'すっごい男がいたもんだあ~~

立A というのは，ソフトウェア技術者の集まりなので.企業とか立A でばったり出会ったら

企業名というカべがなくなって技術的な交流が深まればと西南の役もちだしたあ~~ても素晴らしいと思います.今回は.初めてということもビールを回せっ朝まで飲もお~~~あって肩書き+ 名前"という親交がありましたが ，

あんたが 1 番

今後，名前同士で話ができるとよいと思います.

SEA は 2 番~はあっ.どんどん! .
.

中島宣彦
うまい料理を作る為によい材料を集めようと思った

田村
今日は，証A の方の貴重な声を聞くことができまして

ありがとうごð'いました.なごやかで楽しい雰囲気でよか

叢本良子

九州支部設立パンザ一一イ!

主婦のストレスを立A

ったとおもいます .

で解消するわ4. 九州旭区ネ守トワーク (SIGQ~ET) 発足について

村川貴広
SEA でも，雑用{系(環境整備)をやりたいな

去る 3 月 12 日の証A 九州支部設立総会で，九州地区の BBS を作ろうという提案があり.現在発足に向けて H

ST の鏡沼和友氏と私を中心にして準備活動を行なってい
古閑幸一

ます

今.九州が熱いと言われたい実現方法として

jW1et を使う ， オリジナルの B酪を作る等の.提案がなされましたが.誰にも負担をかけない
野口幸一
種々の業種を持つ人が同じソフトウェアという共通した方法として，既存の BBS を使う方針で検討がなされました.とりあえず熊本市の NIT がホスト局をしている

ツールをいかに生かすかということで会を持ったことは.

YOU.NET という BBS に間借りすることを考えており.

非常に有意義なことだと思います . これからは，いかに発

既に内諾は得てあります.他県の方には，電話代の面でご展させていくかということに焦られてくると考えます . 相

迷惑をおかけすることになりますが，会員の熱気がさめな

互にメリットがあること . 問題点を提起し合い，皆て'考え

いうちに，発言の場.連絡の場を作っておくことが大事とる会であって欲しい .

考えています .

九州地区会員の方に配布するアンケートを現在作成して

‑
5
3
‑

SeamaUVol.3 , No.3・4

MessagefromKyusyuI
s
l
a
n
d

おりますが.この文が読まれる頃にはもうお手元に届いて会の運営，セミナ・ワークショップなどイベントの開催.

いると思います.どうぞご意見をお送りください.ボード

内外の関係諸国体との交涜などを主な活動としている.

SEAMAIL 誌上でお知らせしますので，九州地区からも約 40 人が参加しているが，活動の場はどうぞ九州地区以外の方も気軽にアクセスしてください.

東京が中心になるため.個人の資格では地理適に参加が鍵開設の際には，皆さんのこ理解とご支掻をお願いします .

しく.九州独自に活動する目的で九州支部を設立したもの
で，横浜，関西，長野，名古屋に続き全国 5 番目の支部結

上妻健一郎

成となった.平尾一浩氏(ヒラタソフトウェア-テクノロ

電子応用機械技術研究所

ジー)は「企業の枠を超えた勉強は，技術者はもちろん企業にもプラスになる」と話している.
吻測隊蜘測，.割前市命刻h ・..訓，..司幹事・ a脚..刻，.刻働市駒市ホ*測，....・・跡調脚測h 測".*.

5. 事後プレス
事前プレスがあれば.事後プレスもありました.
...ホ刻，..ホ廟車市申刻，.働市刻脚蜘.蜘司ド$訓"...割前..市康司h ・ e 市場噂吻ホ司h ・

熱きこころにおくる(電波新聞:昭和 63 年 3 月 16 日)

ソフト技術者交涜組.

九州でも支部設立

原作:平尾一浩・藤本良子
作:福島光則ソフトウェア技術者および研究者が，社会組織の壁を超食 1988 年 3月 12 日

えて経験や技術を交涜しあう.ソフトウェア技術者協会(

市内ヒラタビルに関係者約 50 人が参加して開催，九州支部の発足を決めるとともに，世話人の選出.年間活動計画.
ネットワーク構築などについて話し合った.

一旗本一その日.平尾一浩は浅い夜の眠りから目覚めた.熊本のSEA) 九州支部設立のための第 1 回会合は 12 日.熊本

春は早い.
「おはようございます J「あっ，おはよう .. . J

会合では.通産省の情報処理振興課近藤隆彦課長が r2

いつのも時間に出社したものの，朝の挨拶もどことなく元

000 年の推計では .少なくとも 4 0 万人以上のソフトウ

気がない . いつもは熊本の荒技師と呼ばれている彼なのだ

ェア技術者の不足が予測されている.このような状況の中.

が.

SEA の活動には非常に関心があり.注目している J とあ

いしれぬ不安がこころを占めてくる.

いさつ.続いて悶協会東京本部代表幹事の鈴木弘氏(熊本「やることはやったが.目・・ J

構造計画研究所長)が.東京一点中心主義はやがて崩れる

煙草に火をつけながら.数キロ先に煙る熊本減の勇姿をみーなど「情報の中央集中から分散へ J の題で講演した.

つめながら独り言ちたさしずめ.媛軍待ちの篭城主と続いて長崎，沖縄を除く九州 6 県から集まった約 50 人

(とうとう今日か ...

うまくいくだろうか....).い

いうところカ汀が自己紹介した後.参加者全員で今後の活動計画を協議
公 Welcom(1)九州支部連絡先をヒラタソフトウェア-テクノロジ (H

平尾一浩)

SEAK
y
u
s
h
u
us
t
a
r
t
.
u
pmeeting へ!

ST ，平尾一治代表)とする(2)九州を 3 地区に区分.

「ょうこそそれぞれ 3 人の世話人を選出.

(3)会費を取らないボラン

本日は私のような弱筆者の呼びかけに対して.これほどティア団体とするーなどを決定.今後の支部活動.ネット

たくさんのかたにお集まりいただき，誠に感謝しています.
九州支部設立の動きは，昨年秋， HST の藤本が皆様のワークの構築問題については.世話人で検討，次回の会合

を 5 月中旬にする，などを決定した .
SEA は，ソフトウェアハウス，コ ンビュータメーカ.

ところへお手紙をだしたのがきっかけとなっています.しかし返事の手紙.電話などはひとつもなく九州の方?J などと計算センタ.エンドユーサ\大学，研究所など，それぞれ

逮は何も問題意識がないんじゃないだろうか!

異なった環境に置かれているソフトウェア技術者または研話しておりました.そこで.気の短い私としましては究者が個人の資格で参加.技術と情報の交流を図る場としええ~い.かけてしまえ! J と電話をかけてしまい，今日て 60 年 12 月発足.機関誌の発行.支部および研究分科

こうして皆様に集まっていただきました.はじめ疑ってい

‑
5
4
‑

SeamaUVol.3 , N
o
.
3
‑
4

MessagefromKyusyuI
s
l
a
n
d

ました皆様の問題意識の大きさや，また.なんとかしたい

公独自というその気持ちが.今日の会合でだされることを期待しちっちっちっちっち目目 ・ ・ ・・ます .

目覚まし時計の律儀で世話しない音を BGM に，一本の現在伍A の活動は.どうしても東京 ， 大阪を中心としジュ ー スの空き缶を前にして，この原稿を書いている . べたものが多く，われわれ九州の人間にとって，地理的条件

ンが止まる . あのときのジュースがそもそも間違いのもとからどうしても受け身の参加しかできないのが現状です .

だった.

しかしわれわれは ， なにも中央ばかり見続ける必要はない「よお.おごるから.ちょっとジュースでも飲みにいこうと思います . 身近なところでも . 興味ある研究や仕事をさぜ」

れてる方々がたくさんい ら っしゃいます . われわれ独自で，いつもはけして.そんなことはいわない平尾一浩 26 歳

中央に遅れ，負けることなく，セミナーやワークショップ

既婚が.わたしを誘ったのは 2 目前のことだ.その数分ほなどを企画し . 大学や，研究機関，企業の人間がそれらのど前に，彼が r Semail の原稿は ...... J という言葉をもら

組織の壁を取りはらった形で ， 多分野にわたる話や議論をしていたのを偶然にも耳にしていた . とっさに防御体制にして，最新の情報 . 掻先端の技術をわれわれのものにしてはいった.

いくことが可能であり，またそうしてこそHappy になる「え，いや，今仕事が . . .. Jことができるんじゃないかと思います.ちなみに，いま注

カのある人聞にはかなわない.山法師のあだ名は伊達には目されてますファジ一理論の山川先生(熊本大学)も付けられていない . 数分後.ジュ ー スの自動販売纏の前に

SEA にお誘いしたところ ， 先生のほうでも興味を持たれ立たされていたたよ う で ， 資料を下さいといわれてますので，近いうちに「さっ，どれがいい」彼の不気味な笑顔におびえていたも御返事がいただけると思います.

のの，私の右手は 100 円のボタンへ伸びていた .

さてここで会員状況をみていただきたいのですが.ご覧のように九州全県あわせますと.

35 名の会員が登録されあのときはっきりと断つでさえおけば.いくら悔やんでも悔やみきれない . たかだかジュース 1 本のために.

ています . 領岡一 12. 熊本一 13 と争っていますが.今立A の会員でもないのに.なあんでこんな自にあわなけ

日すでに熊本からは 6 名のかたが入会申込書をだされ，今ればならないのだ.

日中には 20 名を越えそうです.福岡の方にはすみません
が.熊本が勝ったな，と内心喜んでいます.ということで.

仕方がない.次の資料は....と.今回の支部設立のきっかけを作った藤本良子主婦による「手紙 J .か.

鹿児島 ， 大分，宮崎のかたも頑張ってください .

今回の九州支部設立の話を聞かれた通産省のほうから.

食手紙(藤本良子)

是非参加したいとの連絡が一昨日ありまして，情報処理振興課の近藤課長さんがいらっしゃってます.近藤さんにはことは. 1986年 6月のソフトウェア・シンポジウムに始まりました.

後ほどご挨拶をお願いしてあります.

夜の情報交換パーティで.

さて，今日これからのプログラムですが.なんといっても今後の活動に対するミーティングが.今日のメインとなっていますので，よろしくお願いいたします.
ところで.みなさま気付かれたと思いますが . 部屋のう

SEA の会員の人たちに，長野支部設立の影響もあって ，「九州支部つくってくださいよ J っていったら，「証A は ， ボランティアだから，自分たちで動かないとダメ」なんて冷たく( !?)突き放されてしまった .

しろにコ ッ プを手でだしてセットするという，最新鋭のコそうでした . そうでした.世話人って人がいるんですよーヒ一自動販売篠が用意してあります . 今日はオープ ン にね . 次の日のチュ ー トリアルで.

していますのでご自由にお飲みください

んな刺激を受けて，地方でもなにかやりたいって意気込み

は.

このコ ー ヒ 一 代

1 月に行なわれました長野でのワークショ ッ プの際.

TRON のことでもいろはできた .

有志の方々のビールもう一杯という誘惑を押さえ.カンパ

熊本に帰ってさあっ J と恩つてはいたものの，プロしていただいて集まった鑓助金を使わさせていただいていジェクトに追われ.一日は，あっという聞に一週間 ， そします(有志のみなさんありがとうございました) .それでて 一 ヶ月 . そこへ . 福岡の能見さんが.

は次のプログラムに移りたいと思います.・ ・ J

rSEA 会員の熊谷さんに HST に行ってみたらどうか J

‑
5
5
‑

SeamaﾟVol.3 , No.3‑
4

MessagetromKyusyuI
s
l
a
n
d

といわれたそ うで，遠路はるばるやってきた . 話を聞いてみると.福岡では 1 人 l 人と会って.

SEA 福岡支部設立

そして全く同じ内容を HST の SEA 会員にもメイル .
後は.返事を待つだけ.そして，わたしは最後の出張に東にがんばっているらしい .今度.ミーティングも開くらし

京にでかけた.

い.実をいうと私，その前の夏の盛岡のワークショ ップで.

帰るころには，返事がたーくさん届いているだろうって楽2 週間ながーいホテル暮らしもなんのその.

熊谷さんのグループにいて風土って言葉を学んだのでした .

しみにして帰ってきました . 仕事も一段落.思うところあそのときの熱い想いもよみがえり遅れてはいけない，って今年いっぱいで退隠するけど.

熊本支部をつくろ 一」 と初心を思い出したのでした . でも.

たし.退陣量までにはなんとか形にして.残りは HST の誰考えてみると，福岡地区とはかなり違って.熊本の会員はかに押しつけてって考えながら.

ほとんど HST ばかりだし .こ れでは. SEA の趣旨でもを入れる準備をしたのです . さあ，後は証A 九州支部設ある ， さまざまな職場で働く人々が技術的文化的交流を立にむけてがんばるだけ .

証A の会員は更新しSEA 九州支部設立に力

結果は電子メイルが 2 通きました . まあ ， とっても明る行なう.がむずかしい .うー ん . よし.どうせつくるんだ
ったら九州支部だ . なにから始めよう.福岡支部設立の様いメイルで九州支部設立後は ， 年に 4 回は温泉でセミ子をみながらなんとかしなくっちゃ.

ナ ー やワ ー クショップをして親墜をふかめましょう " ってしかし.その意気込みもむなしく ，時 間だけがたって季書いてきたのは，なにを隠そう H さんです . でも . 返事の節は夏が過ぎ ，気づいた ら秋 も深まってきていた . そんな手紙は一通もありませんでした.まだ . 2 週間しかたってフ・ロ ジ ェクトも終わりに近い一 日 ， 席検えもあって気分もないしね.みなさん .

一新したことだし.

う.まっ. ~、っか.

SEA の会員の人たちに九州支部設立についてのお手紙でもと思って書きはじめた.

(また.

(拝啓.って硬い言葉うまく使えないのよねえ.突然だ

じっくり考えていらっしゃるのだろ

2 週間経過)まだ.一ヶ月しかたってないしね.手紙の文面が惑かっ

し.顔も知らない人々になんて 書 いたらいいのかな?

たのかしら.突然すぎて失礼だったかしら.まっ.いつか .

なんて思いながら .

年末で.みなさん忙しいんだろうしなあ.いまごろ暇なのは，わたしだけかな?

って思いつつ.少しづっ退峨する

SEA 会員の皆様へ

日は近づいてきたのです.そして，とうとう . 来年はなん

拝啓.初冬の候益 々 ご清祥の段 . お慶び申し上げまとかなるかなあ，今度は往復ハガキでだしてみょうかなあ ，す.

なんて考えながら.心は SEA 九州支部設立より専業主婦

SEA の九州地区会員も 30 名をこえ . 福岡地区では独自に支部結成を行いつつある中.熊本ても何か支の方へと傾きつつ.

87 年は暮れて，鴎年になってしまったのでした .

部を結成して，分科会なるものを行いたいと.日々.
思っていました . ところが.ここ熊本においては .

2 人の会員のなか.

10 名ほどが弊社 .

1

食 独自

(ヒラタ ・ ソ

そういうことだったのか.こういうきっかけから.

SE

フトウエア ・ テクノロジ ー )所属ということで，どうA 九州支部設立の会合 ， ひいてはこの原稿書きの苦しみへしても内部構成となってしまいます . そのため.証Aとつながってきたのだな.うむむ.とりあえず初心をまっの目的である"技術者の，既存の社会組織の壁をこえとうしたということか.それでいつに似合わず優しい雰囲

た相互の"交涜"という商で.効果をあげることがで気だったのか .なるほどなるほど .

きにくくなります.そこで.熊本だけでなく九州全体

まあそれはいいとして，人の文のつなぎつなぎを書くな

で ， 支部を結成し . 相互の交流を行いたいと思っていんて，初めてのことだから，書くことも試行錯誤になってます .

しまう . 人はいつでも初体験.

つきましては .会員の 皆様のご意見.ご要望を承り

まあ.今までの資料に目を通してみると，なかなかたく.ここにお便りした次第です .率直なご意見.ごSEA というのもおもしろそうではないか.ボランティア

要望をお待ちしております .

て'やってる.なんてところがかっこいい .
敬具

生臭い金や権威の話しになってきたら.いっきに興醒めするところだが，どうもそれらしき話はないみたいであるし ， なかなかよい

‑
5
6
‑

SeamaﾟVol.3 , N
o
.
3
‑
4

MessagefromKyusyuI
s
l
a
n
d

熊本の会員に電話をかけはじめたのが 1 月の中旬 .

のではないだろ う か.

手順としては九州支部設立に向けて動いている，ぜひ参加して欲しい」という内容と.

食 1988 年某日「返事来ました?

おや ， 何むくれてんです?

なにつ.

全然来てないの!

二 ヶ月になろうとしてるのに!

「 第 1 回会合を開きたいが ， 日時に対する希望は?

平日? 休日 ?J などを聞いて . より多くの人が参加できる日

そっじゃ.あんまなさけなか . 返事いっち

時を選ぼうと.とにかく電話しまくった.しかし.みなさょでけんごたるやつばかりじゃ九州はすくわれんばい . みんとても忙しらしく，なかなかっかまらない.こんなとき

んななんいっちょ考えとらんとだろか?

電子メイルが使えたら，と思ったことが随分あった.

そらでけん!

おつが.どぎゃ

退服されて連絡が取れない 2 名の方を除いて，どうにかんかせんといかん . 藤本さん.続きば俺にさしてくれんね

ひととおりかけ終えて，やっとのことで日時を選択した .
次はその日時を知らせて確認を取らなければいけない.しかし ， 私もこれぽっかりやっているわけにもいかない . 本

tl 独自

いま.わたしの心は無である .

来の仕事であるプロジェクトの客先立会は迫るし.パグ対

いくら元は他人が書いたものとはいえ.このまま載せて応もしなくちゃいけない.おまけに ， 論文も書かなければしまってよいのだろうか . 確かに「どんなことを書いてもならない . 結局すべての電話をかけ終わったのは ， 一ヶ月

いいから J ということで引受けたのだが.いくらなんでも半後の 2 月も終わりの頃となっていた.はじめに作った名

これはまずい . わたしの良心までが疑われてしまう.せめ簿は，真黒になるほど個人個人の情報が書き込まれていた.
何人かの人は ， 返事を前日まで待ってくれとのこと.そて訳をつけることにしよう.

れでも.

しは安心した . 一番恐れていたのは.熊本だけの会合にな

tl 再び 1988 年某日

平尾一樹立前々から気になっていた.

30 人位の方が出席できるとの返事をもらい，少SEA 九州支部設立の動きを確かめるべく . そのいいだしの藤本の所まで足ってしまうのではということだったが.それがなくなっただけ気が楽になった .
これで準備が終ったわけでは当然ない . 会場の選択や会を運んだ.
「返事来ました?

おや，何むくれてんです?

なにつ，全然来てないの!

二ヶ月になろうとしてるのに!

員以外の方へ配る資料作りなど.やることは予想より結構多かった . 東京の本部のボランティアの苦労が実感としてそれはいけないことだなあ . ふっ，そんなことでは.あまやl ったのが，妙な感激としてこころに残った.ボランティ

りにもなさけないて'はありませんか . 返事ひとつできない

ア活動は ， 一体感を伴った熱きころこをたぎらせてくれる.
会場の選択では，いろんな所へ問い合わせをおこなった

ような人ばかりでは，九州はすくわれないですよ . みんな何ひとつ問題意識はないのだろうか.私が何とかしなけれ

が，どこも高い!

どこかいい場所はないものか?

ある，

ば.藤本さん ， 続きを私にやらせてくださいませんか.

ある，熊本城がみえ . 市内が一望でき . 阿蘇さえもよくみえる.そう，会社の会議室があるじゃないか . そこで会社との交渉がはじまる . なんと.意外にもと早くに OK がで

tl 独自

これでよし.と.これならきれいで完壁な標準語だ . さたただで使える」初めての会合だから.できたら参加

すがに"あれが噂のゴ ー ストライタ"と噂されている(陰費無料でやりたいと思っていただけに婚しさひとしおだっ

口を叩かれる)ことはある.

た.よし，もう一踏ん張り ，.."

まさか「みんななんいっちょ考えとらんとだろか? J を，

「平尾さん電話ですよ J

困ったなあ.みんななにひとつ考えていないのじゃないだ「はい，平尾ですが .... えっ.これなくなった ...J 電話な

ろうか?

んか鎌いだ

やはりこの世で信頼できるのは自分と金だけだ

な.はつはつは J と，正直に訳しては.むざむざ自分の身食 独自に危険がおよぶことになる . さっさと次に移ってと .. . .

電話が惑いわけではないと判っていても，最後の言葉がtl 電話(平尾一浩)

でるところに.平尾の全てが表れているような気もする.

‑
5
7
‑

,

MessagefromKyusyuIsland

食前夜(平尾一浩)

SeamaUVol.3 No.3・4

だろうか. " 目設立後は "会場のセッティングは終わった.スピーチの依頼もちゃ

とにかく焼酎飲んで帰ろう.

んとやった.そうそう.幹事の鈴木さんに明日のスピーチの題名をしらせなきゃ .

食 独自

roff-f拭.と.

わたしは焼酎よりも.ビールのほうが好きである .だかはあ~もうこんな時間だ . 資料のコピーはあすの朝一番にらどうだというのではない.のどがかわいただとかおなかやろう.でも，どうもプログラムがしっくりこない.企業がすいただとか.そんなことをいうきはこれっぽっちもなの壁をとって ， といいながらちょっと竪すぎる感じがする.

いのである . それにしてはすこしかんじがすくなくなって

SEA の持っているラフな感じでやりたいが.

きてる.かんじょうがおもてにでやすいたちはかわらない.

九州支部活動計画

さて，次は肝心の当日の部分.はてさていったいどうなることやら.

九州支部活動計画だよ
これじゃ霊建買いそうだしな一.

食 さて(平尾一治)「そんなときは英語でやってみたら」と短の向こうから声 .

さて当日 .

さすが，回った時のMr . I
k
ad
a
i
.

コピーは終わった . 会場案内も手配した.駐車場の案内(はあ.はあ，う，はあ，はあ".)「ついて'に司会も全部英語て'ゃっちゃったら」

も手配した.受付も頼んだ.

r
o
d
a
m
a
r
in
a
s
a
i !J それこそ，パグがあるとわかってプ

あ ". )

ログラムを納品にいくようなものでしょうが.で.結果出
来上がったプログラムは以下の通り.

(はあ.はあ.う，はあ，は引き出しに手が延びる.手には徹夜用にとっておいた焼酎が鐙られている . う~ぷつ.知らず知らずのうちに 2 杯
目へと"心地よい酔いが私の体を包み始めたとき

r2

SEAKyushuuStart‑UpMeeting

人みえられました J と受付からの知らせ.まずは挨拶.と

(
p
r
e
l
i
m
i
n
a
r
yp
r
o
g
r
a
m
)

ころが.開始予定時聞の 5 分前になってもほかのかたがこ

1:∞ Wel∞me(by Mr
.
h
i
r
a
o
)

1
:
1
0Wha
t
'
sSEAandWhatωnwe e却ext f
r
o
m
?
(
b
yMr .S田uki)ない.

なぜ，どうして.，..よぎる不吉な思い.そこへ突然の人の群れ.よかった.

1
:
2
5Gr
e
e
t
i
n
gfrom 勘rrn (byMr.
Kondo)

種々の理由により.

1
:
3
0S
p
e
a
c
h1(
b
yM
r
.
S
u
z
u
k
i
)

トした .

30 分遅れの 1 : 30 . 九州支部はスター

Towardst
h
ed
i
s
t
r
i
b
u
t
e
dp
a
r
a
d
i
g
r
n
2:10 ∞ffee break

食 Welcome K
yusyuuSEA

2:
2
0Discussing 立AKyushuu

代表幹事の鈴木氏より.

立A とはどのようなもので.

3:30 ∞，ffee break

われわれは SEA になにを期待できるのか，という内容で4:∞ Speach I
I(by 恥fr .Ikadai)

SEA の紹介が行なわれた.

"Am
e
r
i
c
a
nP
r
o
g
r
a
m
m
e
r
"
4
:
5
0c
l
o
s
e

続いて.通産省情報処理娠輿謀の近藤課長より挨拶
九州の技術者の方々の熱い意気込みを感じ参加した.
2αlO年には.

なるほど，堅くなくてなかなかいいじゃないか . どうし97 万人ものソフトウェア技術者が不足するといわれている.ゆくゆくは自動プログラミングが出てくて漢字を使うと.堅い感じを与えてしまうのだろうか?

るだろう.しかし.その自動化の中心となるものはやはり

やっぱり日本は肩書き社会なんだな，とへんに納得してしソフトであり，ソフトは人聞の課題としていつまでものこ

まう自分がおかしい .

り ， ますます問題は深刻化してくる . そのような中てヘ技

準備がひととおり終ったと思ったら.今度は急に極度の術者が企業の壁をとった結合をおこなうことはたいへん興

緊張感に襲われる.みんなちゃんと集まってくれるだろう

味あるところで，今は通産省としては直接お手伝いできなか""うまく進行できるだろうか目 ". 会議が盛り上がる

いが，このような SEA の活動に期待する」

‑
5
8
‑

SeamallVol.3 , No.3‑4

MessagefromKyusyuIsland

続いて代表幹事の鈴木氏より情報の集中から分散へ「証Ayou again...目 J」と題したスピーチが行なわれた情報の一点中心主義はやがて崩れる . 物理的(土地，通勤)問題から，地方で食独自の開発が注目されてきている.そこで.地域的.広滅的な

実際には参加しなかったため，当日の様子はよく分から

分散開発環境と開発管理をスムーズにおこなうことで.地ないのだが，この資料を見るに限つてはなかなか盛り上が方でも技術者が満足のいく仕事ができる体制を.ネ'"トワったみたいだ.そういえば.ミーティングを終えた後のークなどを活用し作り上げていく必要がある J

SEA の会員の面々が ，えらく高揚してたような気がしな

質疑では某会員から " L 批判"がでて場内をわかせた.

いでもない.なにはともあれ，無事に終わったことはいい

すべて順調に進み，いよいよ活動形態のミーティングにことだ.今後の活動についてなどなかなか具体的な所まで入った.やっぱりはじまった，自己紹介，自己紹介.初め

決まっているみたいではあるし.竜頭蛇尾にならなそうだ .

の予想、 に反して話すわ話すわ.日頃の不満から自分の夢ま

今後に期待がもてるのかな . 今度のミーティングの予定がで.しかし共通していたことは，地方でもいい仕事がした

5 月か . 個人的に参加してみょうかなという気がおきなくい.新しい情報をいちはやくつかみたい . それらを可能にもない.うむ.そう書いたら本当にそんな気がしてきた.

するために.

よし.今度はのぞくだけでものぞいてみることしよう，と .

SEA 九州支部をアクティブな支部にしたい.

そしてすばらしい仲間を持ちたい.

平尾氏の結びを BGM にして，わたしも.

SEAy
o
ua
g
a
i
n
..
.
.
公九州はいま，集くなってきている
討議は終わった.すでに予定から 1 時間 30 分の遅れだ.

食 結び

最後に予定していた HST 筏弁氏のスピーチ"American(平尾一浩)

さてきて，とにかく動きだした九州支部.あとは B 型特Programmer "ができない.しかし.そこは筏井氏 . さっと

有の飽きっぽい性絡を克服し.なんとか軌道にのせていき前にでるがはやいか，話すがはやいか，電光石火.ささったいと思っている.現段階では東京，関西，そして他支部と要約を話し，コメントをエドワード氏に送りたいと岸田との厚さ，カの差，は歴然としている.ひとつだけ，たっさんがいわれてますので.それぞれお配りした資料を読またひとつだけ勝てるのは変なやつ"の多さだけだろう.

れたあと ， コメントを岸田さんまで送ってくださいと業務

その変なやつら約 50 人が九州でなにかやろうとしている.

連絡.さすが B 型.素早い機転かくゅう私も同型) .

各支部.分科会.そしてすべての SEA 会員の方々のご支

すべて終わった.かくして，今夜の熊本組 1 7 人は

媛.アドバイスをお願いします.

馬刺し.馬東11 1...-"と吃きながら，夜の街へと消えていく.

また，九州支部設立に際し，多大なるご支媛をいただいた常任幹事の岸田さん.事務局の中島さんに心から感謝し，
食 1988 年深夜一熊本一

そして今後も九州支部に対して熱い期待を持って見守って.の後.一浩は夜の街に一人たたずんでいた . 早春の夜

くださることをお願いして，終わりにしたいと思います.

気が疲れた身体に気持ちがいい . 冷たいコンクリートの壁

録後に.とんでもない原稿をまとめ上げてくれた，福島君にもたれかかると，心地よい疲労!惑が全身を包んでいく.

の労にたいして.紙面を借りて一言いわせていただきます.

思わずもれる溜息も.いまはもうない.静かな微笑が.一

忙しい中，ご苦労さまでした . どうもありがとう .

治を一事をなしとげた男の顔にしている.
ついさきほどまで互いの意見を交わし，熱論を交わしあった新たな友たちは.それぞれの宿へと帰っていった.またね.また会おう .，. ，再会の言葉は疲れをいやし，こころにしみ渡る.
「またね，か J

一浩は思い返し.また笑みが顔にひろがっていく . 静けさのなか-7舎のもらした言葉が.夜の街に溶けこんでいっ

た.

‑
5
9
‑

E
a
s
s
y
s

SeamaUVol.
3No.3・4

Hacker に関する考察
浜野剛至
ソフトウェア・リサ ー チ ・ アソシエイツ

1. Hacker の定義-凶 es sedandawkw
i
t
hc
o
m
f
o
r
t

コンビュータとしばらく付き合っていますと私はハ. 凶 es u
ndodwnentedf
e
a
t
u
r
eo
fv
i

ッ カーでありません」とかあなたはハ ッ カーだ! j と

i
t
h"!∞"
.w
r
i
t
e
sC ∞de with"ωt >"and∞mpiles w

かいったやりとりを，会話のなかにみかけますし，ハ ッ カ

.u
s
e
sa
d
bb
e
c
a
u
s
es
h
ed
o
e
s
n
'
tt
r
u
s
ts
o
u
r
c
ed
e
b
u
g
g
e
r
s

ーに関する本もいくつか書店でみかけますが ， ハ ッ カーと

.f
i
g
u
r
e
do
u
t how environm巴nt v
a
r
i
a
b
l
e
sa
r
e pro・

は一体どんな存在なのでしょうか?

ハ ッ カーと問いただ

p
a
g
a
t
e
d

けでいろいろな感じを受けるのではないて' しょ う か?

os
u
p
p
l
e
m
e
n
tt
h
es
t
a
n
.
.w
r
i
t
e
sh
e
rownnroff ロ1.1α・os t
d
a
r
do
n
e
s

なんかうっとうしい存在だ.現代社会はハ ッ カー抜きで

.w
r
i
t
e
sBo
u
r
n
es
h
e
l
ls
c
r
i
p
t
s

は語れない . ハ ッ カーは反社会的である，常識人ではない.

綬暗だ，お人好しだ.運動神経が O だ.ポルノ映画には興

.i
n
s
t
a
l
l
sb
u
gf
i
x
e
sfromthenet

味がないがアニメーションで舞血をだす，スニーカーを履.凶 es e
g
r
e
pb
e
c
a
u
s
es
h
et
i
m
e
di
t

いている.子供がいればそれは女の子だとか.定時に会社に来る事は稀である . いわれていることを数え上げるとき

wizard になると名前に Dennis とかBill とか Ken とりがないくらい.いろいろな断片的特徴が報告されていまかあるなんていうのは笑ってしまいました(くわしくはす.そのような愛すべきハッカーについて.気楽にあるいbit地刊「愚新 UNIXj に掲議されましたので.興味のあは真剣に考えてみたいと思います(ちなみに私はハ ッ カー

るかたはどうぞ)ではありません) •.

また glJの記事には，ハッカ ー を次ぎのように定義してい
ます .

(
1
)MIT の周辺 (by S
.
L
e
v
y
'
s~Hackers 関)
Hacker という表現は .

1950 年代のおσr の鉄道模型ク- 一般のユーザが.必要最小限ですませたがるのに対し，ラブあたりから使われるようになった.配線を巧みに繋ぎ

プログラミング ・ システムの細部を学び.

変える.鍵のかかったものはかたっばしからはずそうと試ングの)能力を伸ばすことを楽しむ人 .

(プログラミ

みるといった，好奇心の塊のようなパ ー ソナリティを持っ・楽しんでプログラムを作る人.または.プログラミングている . しかし :ながら運動神経等は人並以下と，アンバラの理論をこねまわすよりも，プログラムを作る方が楽し

ンスな感じの学生たち.

い人.

Hack の本来の意味は.樵などが斧で木を叩き切るところからきている .

.Hac
kvalue が正しく認識できる人.
. プログラミングが非常に早い人.

(
2)U~IX の世界( ~ews fromJ
u
n
e
t
)

- ある特定のフ・ログラムのエキスパート，またはその上でハッカーについての定義が.国内外からネット ・ ワーク

頻繁に作業を行う人 .

のニュースに涜れていた.アメリカから涜れてきたものに- あちこち覗きまわることによって.情報を発見しようとおもしろいものがあったので. 一部を紹介しますが.それする悪意の.または単純な好奇心の覗き見屋 . 転じて

によると.

"
p
a
s
s
w
o
r
dhacker". 、etwork h
a
c
k
e
r
".

Hacker にいたるまでには ， いろいろな呼称のついたレベルが存在するよ う だ.まず .

b
e
g
i
n
n
e
r
.n
o
v
i
c
e.

u
s
e
r.k
n
o
w
l
e
d
g
e
a
b
l
eu
s
e
r
.e
x
p
e
r
t
. hacker.
上があって

さらにその

guru ， wizard となっています . その記事にまた. glJ の記事では.

.HAPPYHACKING : 別れの挨移(じゃあね . またね .

よる hacker の特徴として次ぎのことがあげられてます .

‑
6
0
‑

S
e
a
m
a
i
lV
o
l
.
3N
o
.
3
‑
4

E
a
s
s
y
s

.HO
W'SHACKING?: ハ ッ カ一同士の親しげな挨拶.

ッ カー狩りが起こったらどうしてくれるねん . ネ ッ トワー

・ HACK HACK: 深い意味はないが，綴しい聞で使うコクの維持だって，みんなのボランティアでなりたってんの

メント .

しばしば，一般的な別れの挨拶に用いられる .

だぞ.こういった誤解を拭うことにマスコミの人はたちは関心があるのか?

というハッカ 一 言葉を紹介しています . どれも愉快な記事ですし，思わず納得してしまいます .

どうやらハッカー

私はとにかく，日本のマスコミのセン

セーショナリズムを煽るような報道は好きになれません.
といっても，もともとマスコミはイエロウ・ジャーナリズ

の元祖というのは，アメリカのコンビュ ー タを触っている

ムから起こってきたもので.それに振りまわされるわれわ

連中から生まれてきたよ う なもののようです.ヒッピ一発

れ受け手の問題かもしれませんが .

祥の地 UCB のあたりなんかは，ハッカ ー がうじゃうじゃ

事故があったとして，その損害賠償とか責任とかにマスコ

いるような感じて'すね.

ミはよく言及しますが.マスコミが侵した事故とか.責任• ..どこかで飛行機というのはきちんととられているのでしょうか?

2. Hacker 鎗理( byS
.Le
v
y
'
sRHACKERSR)"HACKERS" という本を読んで感じることは.ハッカーというのは建設的な無政府主義というのか.コスモポリ

こういったマスコミの功罪については.もっと考えなくてはいけないたとえば，情報処理業界は暗いというイメージを定着させたのはどこのだれだ，とか .

タリズムというか.そんなものを感じることが出来ます.
いくつか抜き出してみますが，私個人としては最後の二つ(2) ネヲトワークを利用した犯罪とHacker との相関はの項目は好きです.

あるのか?
銀行のオンラインなどから.大量の現金が瞬時にして引- コンビュータへのアクセス.加えて ， 何であれ.世界のき出されたりする事件は記憶に新しいですが，これらのほ機能の仕方について.教えてくれるものへのアクセスは.

とんどが内部からのものが多く，惑いことの仕方が時代と無制限かつ全面的でなければならない.実地体験の要求

共に変わってきたということではないでしょうか?

を決して拒んではならない .

ろんネ ッ トワ ー クを通して惑いことをする人もいるでしょ-情報はすべて自由に利用できなければな らない.
・ 権威を信用するな(反中央集権を進めよう)

もちうが ， これをハッカーと呼んでは困りますよね.

•.Hacker は ， 成績，年齢 . 地位のような，まやかしの基3. セキュリテ 4 の問題

準ではなく，そのハ ッ キングによって判断されなければならない .

ハッカーとセキュリティとはあまりり相関がない話とは思いますが，セキュリティを守るも破るもハッカ ー さんは-芸術や美をコンビュータで作り出すことは可能である .

その気になればなんでも童文しますというところでしょうか.

.コンビュータは人生を良いほうに変えうる.

(1) トロイの木馬

3. マス・コミの功罪

そのなかで有名なものとして.トロイの木馬というので，(
1) Hacker という 言葉のイメ ー ジの固定化・側面的なパスワードなどを盗むのに古典的な方法(トリック )があ

破る側のテクニックとしていろいろあるとは思いますが，解釈ります.社内で，私もやられたことがあります.最初は何

なんといっても「高エオ、ル ギ ー 研究所」のアクセス事件が起こっているのか全く見当がつかなかったのですが，今に対しての報道のしかたは，納得が行くものて'はなかった.

になってみるとなかなか楽しいものです . だまされたこと

この報道のあとに尺別ET で ，こ の事件 . あるいは報道にのない人は.一度だまされてみて下さい.そのトリックに対する活発な議論が起こっていました.その多くはハッカ

はいろんなレベルがあるので結構おもしろい .

ーたちの嘆きにも聞こえました.
「筑波高エネ研に西独のハッカー侵入 J と書けば，世間(2) 守るための方法の人はハ ッ カー=悪人」という理解をしてしまうので(a) パスワードの選択(推測が容易では何の為のパスワーはないか?私はハッカ ーです J と表明したら . ただち

ド? )に逮摘されるとい う ことがおこったり.魔女狩りならぬハ

銀行のキャシュ-ディスぺンサーの暗証番号は，生年月

‑
6
1
‑

E
a
s
s
y
s

SeamaUVol.
3No.3‑
4

日が多いとききます.そうでなかったとしても，その個人

4. G:SU についての属性に関わるものが多いようです.定期的にかえればよ(1) 最後の真の Hacker R
.M.S
t
a
1
l
ma
n
(
b
yS
.Le
v
y
)

り安全でしょうが，その分忘れやすい，とかいって端末の外見も.することもハッカーの手本のような感じのする所にメモでも張り付けたりすると ， なんのためのパスワー

彼.仕草は大阪弁でいうと「けったいな」です最後のドか分からなくなってしまうし . .

真のハッカーの Stallman J なんでいうのは.

(b) コールパック方式

手にいっているだけだと，あっさりいってのけるのはさす

Levy が勝電話回線を通じて，コンビュータにアクセスすることをがに Stallman という感じです . こういうような感じの人

制限する方法で，アメリカの大学・企業ではこの方式にし聞が.次々と生まれているというのがアメリカの怖さといている所が唱えているらしい .具 体的には，電話でこっちうか.強さの感じがしますが.いかがなものでしょうか?

からアクセスしようとすれば，コンビュターがその人の所に電話をかけ直して，接続をしてくれるもの.日本では電話料金などが高くてまだまだ無理だとは思うが ， 今後t曽え

(
1
)G:
SUM
a
n
i
f
e
a
t
o

そうな方法ではある.

ぜひ一読をすすめます.彼の主張はもっともだと肯づか(c) スタンド・アロン(ネットワークに繋がない)されることが多い文章です.コピーは自由に行ってよい，

とにかく，線密を保持しなければならないマシンは，外

しかしいかなる所有も許されない.彼はこれを，コピー・界との接触を一切断ち切った状態で使えば一応大丈夫なはフリーと呼んでいます.彼は信念のもとに独自の運動を行ずである.つまりマシンルームには鍵がかかっており.常っているわけですが.これは私が説明できるものではないに監視され，マシンそのものもネットワークには繋がってので.彼のManifesto を読んで欲しいと思います.

おらず . 端末も同じく管理されているといった運用状況.
逆に.ネット ・ ワークなどにいったんつなげれば，ある程

(
3
)F
r
e
eS
o
f
t
w
a
r
eF
u
n
d
a
t
i
o
n

度事故は覚悟すべきものではないか .シ ステムもいろいろ

ボランティア・ベースの組織で数名のスタッフで構成さなパニックを通じて成長と変化をし続けるものでしょう.

れており，パートタイムで仕事をしているメンバーもいる(d) システムの弱点を明らかにする(オープンなシステム

ようです . 彼は自分の作ったソフトウェアで億万長者にな

内緒.内緒としてしまうほうが，かえってなにかやんち

彼なりに危機的なものを感じることがあったのだろうと思ろうと思えばなれたと思います.でもそうしなかったのは.

ゃしてやろう，という動織づけを促す場合が多いのではな

います.

いか?

りました.

また. UNIX のマニュアルの中にあるように .セキュリティはこういう所が弱いと，はっきり書いてしまう

HACKERS の中にも彼の焦りのような描写があ

しかし，アメリカのソフトウェア工学をやっている人たほうが.かえって安全ではないか?

ちには.彼の思想を危険なものだという評価があるのも事(e) 暗号化実です.

古くて新しいアプローチ

このへんの話は大阪大学の中野先生にお話して頂くとよいかと思います.

5.Hacker へ愛を込めて(f) いじりたがりはシステムの味方にしてしまう. 良心に忠実であること

なにかとシステムにちょっかいを出したがる人聞は，シ山を超すフ・ログラムがあっても，愛が無ければ無に等ステム側の人間にしてしまうとなにかと便利である . 少な

くともうちわで悪献をするような人聞はいなくなると思いしい(ホンマかいな) .

-人聞が好きであることます.

コンビュータの向こうには生身の人聞がいる.その人達の存在を忘れていてはだめなのではないか?

いずれにしろ.技術の進歩と共に新たな道具が生活に入-日本的な企業文化との闘い

り込んでくるわけですが.問題は，それらを使って生きて日本的ということに関しては，さまざまな見解や議論いる人聞の心持ち次第ではないでしょうか.なんだって制がなされていますが，そもそも日本人的なんてことをい約と可能性の両面を持っていますものね

うこと自体，とっても日本的な感じがします.そういっ

‑
6
2
‑

E
a
s
s
y
s

SeamaUV
o
l
.
3N
o
.
3
‑
4

た議論がどうであろうと.とにかく日本の社会はホモジ

セキュリティを高めようとするなら，まずセキュリテ

ニアスであるわけで.その中では同じであることとか，

ィに問題はないかと.自分のところのシステムをチェッ

全体のなんやらかんやらといった話になりがちで，議論クすればよいといっても.相手とは違うということを明確にしていく

れなりに投資も必要になってくるので，真剣にやると大プロセスとは違う.ヘテロジニアスなことに対して.な変なものになる.

んとなく恐れがあるのではないか

無関心・無責任が一番よろしくない.そそういった風土は効

率的にはなるだろうが，創造的なものが生まれにくいの(2) 管理者の鼠次第ではないか.

御承知のように，高性能なハードウェアが低価格で市

いわゆる日本的な企業.組織はハッカーにとって生き場に出現しています.近い将来，かなり大規模なネット

やすく.ハッカーたちの自己実現が可能なところなのかワークが機策されていくことになると思いますが，従来? 学校の先生.ハッカーを育成しましょう.上司のみのような中央集中裂のマシン環境であれば，状況を把鐸なさん，ハッカーの芽をその人にみつけたなら捕まないするのは比較的容易だったわけて'すが，何十台，何百台で下さい.経営者のみなさん，ハッカーを大事にしましというネットワーク上のマシンを管理するのはとてもとょっ.

ても大変 .

そこで何らかのアイデアが必要になってくるわけですが，このあたりの所が，今後の管理，更には分散環境を

6. 社内では?
私が現在所属をしている会社での状況を少しみてみます

構築する上での要点になるように思えます.また.個人
が 1 台のワークステーションを占有していれば，当然そ

と.

-勝手気侭

のマシンはその個人が使用者であり管理者でもあるので.

これはいい意味での自由があります.

ワークステーションを手に入れた人は，管理者になることを拒否できないことになると思います.

.セキュリテ ィ

無関心では無いが，比較的イージーなようです.どうなっているのでしょうか?

あまり深刻に考えていない(3) グマイントシャフト or グゼルシャフト??

のではないかと思います

社会学でしばしば使われる概念ですが，われわれが生-いいだしっペがやる

きているこの社会・企業・組織というのは，グマイント「これがあったほうが便利じゃない? J r じゃー.お前シャフト (共肉体社会)なのか，あるいはグセルシャフゃれよ」

ト(利益社会)なのか.その中聞なのか.

「こんなツールがあるよ Jr ううー，シプイ! J

ソフトウェアの開発においてあなたは工房派エンジニ

こんな会話がよく聞こえます.

アなのか.あるいは工場派エンジニアなのかという話が，.Hack する事に理解を示す上司，人々Seamail のセミナー・ウィークの報告のなかにありましたが(Seamail Vo
.
12N
o
.
l
) .工房派・工場派という分ハッカーだった(現在も? )役員.上司がいる.
・やっぱり UNIX はHacker 好み

ハッカーたちは.

類と，この概念とは，対応しているように思います.ハUNIX が一番良いとは考えていな

いが.その本質的な良さを認めているッカーがその本質を生かせるには，一体どのような組織が望ましいのでしょうか?

また UNIX のスタイルというか.カルチャーはハッカーが作り上げていったものだと思います . こんなことを書くと.

を導入することをためらってはいけません .

UNIXUNIX は

7. おわりに
昨年 5 月に大阪でおこなわれた関西 Fonun(そこで

自分のところの技術者のレベルを示してくれるバロメーのパネル討論が Vo1. 2 No.8 に掲載されています)で思タにもなります.

いつくままに話した内容を，書き直したものです . まとまりのない話になりました.なにか御意見・御質問のある方は，編集部にお寄せください.

6. エピローグ(1) セキュリティの意義の高まり

‑
6
3
‑

S
e
a
m
a
l
lVol.3 , No.3‑
4

E
s
s
a
y

不純人工知能礼賛

E
s
s
:

とく ，

頭だI

柳田俊一

まし ，

日本コンビュ ー タ・システム?

と思われるかたが多いと不純人工知能=手続き型言語+ A 1 + データベース+ イメージ処理 + etc

R+ 統合 OA

最近，ドレイフュスという合衆国の哲学者が純粋人

そそ

この題はいったいなんだ!

思います.その説明から.

お引似い引制攻

不純人工知能方程式:

1.はじめに

工知能批判 J という.イマニュヱル-カントも飛び上がっ

1

ソトメ錫

純

て繁いた.という批判の書物を著し.いちはやくわが国にも翻訳され，書店の AI コーナーに並んでいますから . ご・覧になった人もいると思います . 関西 SEA の AI 分科会
でも，白井氏と中野先生のお二人に，内容を紹介していただきました.かくいう私は今 .AI

トウールのベンダー側

その概念図を書きますならば:"7"-~ シコー，. ax "t'

事

、ー

非きだ
の

r
AI 賛成一反••』，

しかし.そんなことはどうでもよろしい.

H ・町圃 7 ログラム「・ '1 PlI、， rlt't

Mr . ドレイフュスの意見には真っ向から反対です .

カ> .

C
S

らも.

rc渇・ Olc‑Aに立って仕事をしています . 仕事上からも，個人的感想か

対 J の議論には.私は全く興味がありません .AI トウー

ルを使ってシステムを作ったらこれのどこが AI なのですか? J. rCOBOL でも作れなかったのて'すか? J とつ

COBOL でも作れたかも知-処れません .AI トウールを使って作るのに要した工数の 5手iいう意見がかならずでます.

ACS

中国のある人の言葉に「 黒い猫でも白い猫でも ，ネズミJ、 』， E 、，， aE ，

c‑‑‑

-6 倍，かければね.

をとる猫はよい猫だ」とい うのがあるそうです.私の考え(考えなんて大層なものじゃない，カンカクとでもいったほうがよい)も，それに近いところにあります.
「純粋人工知能」について私はうんぬんしたくありませ古典的言んし，その資格もありません.これから私が述べさせて頂こうと思っているのは.不純極まりない，カッコウの悪い.
プサイクな人工知能へのアプローチの 1 方法です.

2. 不純人工知能とは?

ここで.大胆な予想を申し上げましょう.

不純人工知能の大黒柱は図の中央を上から下に力強く走

ハシこる 2 重線です.まず.手続き型言語で書いたプログラムか- てコてら .AI 言語で奮いたプログラムをサブルーチンコールの・繰そ感覚で呼び出さなければなりません.次に .AI 言語で書・決定いたプログラムからも.手続き型言語で書いたプログラム.処弓をサブルーチンコールの感覚で呼び出さなければなりませ今後 2-3 年は.

ん.
この 2 方向のリンクのないものを「不純人工知能 J と呼いう状況

ぶことは ， たとえ，もう一枚舌が生えてきたとしても許さー、~)とこれることではありません . さらに，これらのプログラムのモチはモどこからでも. DB. 統合 OA 等のモデュールを手足のご~型で，不純人工知慌の全盛期となるであろう

これは.私の勝手な予想、ではありません.

IBM の動きをみて下さい.不純人工知能の定務を申し上げましょう.

このよ

‑
6
4
‑

E
s
s
a
y

Seam~n Vol.3, No.3‑4

とく，自由自在に呼び出すことが出来なければなりません.

ータ蓄積は DB で.そして ， 全てをリンクして統合.とい頭だけいくら立派でも，手足なしでは何程のことが出来え

うように進んでいくのは.実に自然な歴史の涜れでは ， とましょうや?

お思いになりませんか?

3. なぜ，このようなワイザツ‘まるものが必要なのか?
そもそも，人間は不純な世界に傾いていくものなのだ，

それが自然の姿なのだ.と一発で片付けたいところですが ，それでは納得していただけないでしょうね.
純潔

AI 世界と古典的言語世界(例えば ， COBOL,

FOR'τRAN) の比較をしてみましょう .

γ ゃく 刊のヰ長久 1: をtl fL 1
..
.
.
.
.
1

純潔 AI は:-トロい!
-メモリーをメチャ食いする-繰り返し機構の実現方法が不自然(パ ッ クトラックと4. そんな AI トウールあるのか?

現在のところ.このようなコンセプトにはもう 1 歩 ， とか，再帰とか) .
この方が自然なんだ，という人もいますがいうのは ， 私の知る限りでは，

rGURUJ というパソコン

・非決定的制御(つまり.何をしでかすかわからん.糸AIのきれた凧みたい)

向を目指していますが . 発売が 1988 年 9 月まで延びて•だからすばらしいのだ.という議論ももちろん成り立

トウールだけです大創玄 J というのでは，この方しまいました.残念です .
IBM は既に PUI と統合できる推論エンジンを，たしか ，

4つ.

- 処理が柔軟手続き型の言語みたいにガチガチに組んでないからも う 発表したはずです . COBOL (このラテン語のごとき，
永遠なる崇高，神聖なる言語に栄あれ! )との統合の実現
も

p
j
f
j
i
g@

IBM のことだから，時間の問題でしょう.国産メイ ン

フレーム・メ ー カ各社からも，そのうち雪崩のごとく ， 同種のものがでてくるものと，予想しています.

5. 終わりに余談ですが，
古典的言語世界は:3 年後には.イメージと音声がヒューマン・インタフェイスの主涜になると思います.推論結果は音

ハシコい!

声の説明付きで ， アニメーション，または静止画像で表示- つつましやか(爪に火をともしてメモリ 一 節約)

されることになるでしょう.推論途中の質問も，質問内容

・ 繰り返しは実に自然(と思うのは私だけかな?)

がイメージにより表示され.音声による説明が行われた後.

・ 決定的制御(安心してみとれる? )ユーザからも音声で答える.といった形になるでしょう(- 処理が硬直的(キメ打ちしてるからなあ)

文字をエンエンと画面に連ねても，だれも読んでくれなくなるのではないか)

このように，両者，一長一短あり，優劣つけがたし ， という状況て寸.すると . 人間って欲張りですから.両方の.3 年後にそなえて ， Seamail の媒体を何にするか . ということも，そろそろ考えておいたほうがいいのではないか ，

いいところを取って，なんて考える人がすぐでてきますね .
モチはモチ屋 . AI の得意な問題は AI 言語で.他の手続き型で，ヒューマン ・ インターフェースは統合 OA で.デ

‑
6
5
‑

という気もしています.

SeamaDVol.3 , N
o
.
3‑
4

E
s
s
a
y

E

ウォータフォールモデルの変形表現

細野広 7k(徐)エム・ケー・ シ ー

ソフトウェアの開発作業を倹討するとき地象化したモデルを用いることが多いが、その一つにウォータフォーということになろう。ここまでについては通常のウ才ー

タフォールモデルの表現で何等支障はないが 、ここに作

ルモデルがある。このモデルでは、分析~設計~プログ

業の複雑さ 、 泊象度、

ラミング~. ..… という滞留期間を伴った作業進行をうまストの包置づけといったものを付加して適切な表現を求WHAT と HOW などの概念、 テ

めた塊合、加えて出来たのが次の図である。

(紙の上では)非常に理解し易いモデルであり 、

新入社員教育などではウォータフォール

ちょっと手を

ここでは、従来、 線形に表現ぢれていたものを U 字形

また他の業草野(事務処理等)との対応をとり易いなどの長所もあって 、

どうも不足感がある。そこで 、に変形しである。その結果、要求定義等の人間臭い世界(WHAT の世界と言えるかな)とブロクラミング等のモデルを用いることが多いようだ。だが、ウォータフォ

緩繍的な世界( HOW の世界と言えるかな)との関連、でのフィードバックの状況や、設計とテストの関連など

設計段階とテスト段階を対応させるドキュメントの短いをうまく表現する他のモデルが求められる。そしてフラなどが旨く表現されたような気がする。この表現方法のワーモデル、 スパイダーモデルといった爆実がなされる

妥当性の評価や 、ことになる。しかしここでは 、

立派なことは私ごときに出きるはずがな く、

ウォータフ

また全 く 考を確実なものにするために 、 チェックポイントの明確化せる場合などに賃宝しており 、 なかなか使える図であるという気がするので、と適切なフィードバックが必要となる。つまり 、

ここ に提案してみた。

ついでに言わせてもらえば、生理面によっては Y 字型 (報ガ加た日文

その管理

K..プログラマー不重論とまでは言わないが…ーを理解さ

ソフトウェアの開発作業を企業レ ベ ルで考えるときの本質は「管理された作業 j であろう.そして 、それに関する工学的な研究などとい う

えてもいないが、 例えば、 新入社員に「機械化の波 J .

ォールモデルの「変形表現 J で対応を試みる。

LU

ールモデルと現実との大きなズレは幾つかあり、名工程

11 く考えず、

鑑て片(村く線形に表現している。現実の作業は当然もっと纏維なのだが、プログラミングのレ ベ ルの完全線繍化)や 、 逆 N~ ( 一・一連の作業の細分

過性のもので、運用開始後 l事政警などをいっさい考えず。多数のチェックポイントに単純に運用するバカチヨンシステム〉なども有効かも知れない。

ー争「管理された作業 jα~短いパス でのフィードパック

•

加名

mw

定、戸』

度臭度な
象聞雑
抱入国傾

運用・評価

-1・'1111111111

(
4
)

告ゑ

的的と
前一間画期な
州人直

参j

ω

的的ど

a 』EEEEEa14hIψ

ω械理な
同縫翠調

\ー~デ
ー令

図

ウォータフォールモデルの変形表現

‑
6
6
‑

( V 字型)時期(工程)

4
SeamaUVol.3 , No.3‑

BOD , GeneralMeetlng , andOtherE
v
e
n
t
s

幹事会-総会・その他の報告-ソフトウェア信頼性ワークショップ

8 月下旬に八 γ 岳で開催.

4 月の幹事会

高信頼性研究会主催，証At愛媛.
(去年の伊豆ws と同じ}
-第 6 回夏のプログラミング・ワ ークショップ
8 月 31 日 ~9 月 3 日の予定.

4 月の幹事会は .4 月 27 日(水)に東京・機械振興会
館で. 62 年度幹事と 63 年度幹事候補者の双方が参加し今年は場所を盛岡から八ヶ岳に移す.

て行なわれた.出席者は以下の通り:青島.大木，岡田，プログラム委員会を編成中.

片山，川北，岸田，熊谷，芝原，杉田.武田.田中，野村-第 4 回ソフトウェア技術交流会(敏) .野村(行) .針谷，深淵，藤野，藤本，松原.吉村，林[シンポジウム委] .中島[事務局]

9 月 6 日 ~7 日に.徳島大学で開催.

プログラムはパネルを中心にする .

.

1.イベント報告-第 2 回数育ワークショップ(
1)1仇hICSE 研修ツア ー

9 月 29 日 ~1 0 月 1 日に東北地方で .
.第 2 四日中ソフトウェア-シンポジウム

4 月 10 日 ~16 日にシンガポールにおける第 1 0 回

ICSE への証A 研修ソア ーは.

53 名の参加があった(

現在 1 5 名の申込みがある.

・第 8 回ソフトウェア信頼性シンポジウム

報告は次号で) .会議全体の参加者は約 6 00 名 .内シン

10 月 28 日 ~29 日-

ガポール以外からの参加者は約 300 名で，日本からの参加は.米国(1 00 名強)に次いで多く，約 80 名であった.次回の米国Pittsbergh での第 1 1 回会議も.立A は

いつもの通り，大阪ガーデンパレスで開催.
(3) 今後の月例フォーラム

6 月以降の月例フォ ーラムについての討論が行われ，開日:本を代表する後媛団体として協力することとなった . 論

催期日とテーマがおよそ以下のように決まった:文の締切りは 9 月 15 日，詳細は 73 ページ参照.

. 6月 : H
y
p
e
rM
e
d
i
a(
27 日)

(幻第 3 岡ソフトウェア銭術交涜会.7 月:テーマ未定 (29 日に横浜で開催)

4 月 19 日 ~20 日に大阪大学工学部で行なわれた .参
加者は 5 1 名.内訳は ，企業から 3 3 名 (SEA
弘一般 3 名) .大学関係者 9 名(うち阪大 9 名)

会員 30

. 8 月:夏休み

・ 9 月:セミナー・ウィークと重なるので休み.

.10 月:漢字コードと日本語処理 (21 日)(お第 7 回ソフトウェア信型貫性シンポジウム.11 月:

4 月 21 日 ~22 日に大阪ガーデンパレスで行なわれた.

教育 (16 日)

参加者は 49 名.

3. その他(
4)4 月フ才ーラム(1) 常任委員長選出

4 月 25 日に東京 ・機械振興会館で.

1抽 ICSE の報常任委員長の分担は.一応次のように決まった:

告を兼ねて行なわれた.参加者は 38 名.

総務:久保

セミナー:杉田2. これからのイベント{予定.計画.その他}

会誌:藤野

技術研究:白井(1)Il会およびシンポジウム(2) 支部・分科会について

目前にせまった 5 月 10 日夜の第 3 回総会(同日午後に各分科会や支部のこれからの活動について，次回以降には月例フォーラム) .お よび 6 月初句のソフトウェア ・シ

報告を受け.もし何か問題があれば検討することになった.

ンポジウム 88 について準備状況および参加申込みの中間報告がなされた.
(2) 夏以降に計画されているイベント

以下の各イベントについて.おおよその計画が企画に関係している幹事から説明された:

‑
6
7
‑

SeamaUVol.3 , No.3‑
4

BOD , GeneralMeetlng , andOtherE
v
e
n
t
s

貸借対照表

E

3

昭和 63 年 3 月 31 日現在

新年度総会

j置

資産の部
流動資産
SEA 昭和 63 年度総会は，

5 月 9 日夜，機械掻興会館(東京)で開催された.出席者は 31 名，他に委任状 1 1
7 通.

現預金

3 , 612 , 696

未収入金

2 ，215 ，α)()

固定資産

1.昨年度決算

敷金

2 ，4∞，α氾

合計

8 ,227 , 696

昨年度の決算案(辻 ・ 吉村両監事の監査済)が.次のように事務局から提示され，満場一致で承認された.

負債及び正味財産の都
収支計算書
涜動負債

白昭和 62 年 4 月 1 日
至昭和 63 年 3 月 31 日

725 ， 1∞

借入金

4 ，α)() ，α)()

正味財産

支出の部
人件費

506 , 813

事務所費

4 ,510 ,791

印刷費

3 ， 556 ，7∞

通信費

2 ,290 , 611

会議費

362 ，α氾

広報費

129 , 926

消耗品費

232 , 140

雑費

未払金

正味財産

3 ， 5但， 596(当期収支差額

5 , 814 , 837)

合計

8 ,227 , 696

2. 豊百年度役員
次の役員候補案が鈴木代表総事から提案され.満場一致で承認された.

2∞， 658

当期収支差額5 , 814 , 837

合計17,“)4, 476

代表幹事岸田孝一
常任幹事白井義美久保宏志熊谷章
佐藤千明藤野晃延松原友夫
吉村鉄太郎

収入の都
幹

5 ， 495 ，α)()

賛助会費

1 ， 8∞，α)(}

寄付金

4 , 656 , 332

量産収入

2 , 113 , 144

合計

手喜水浩一郎片山積昭川北秀夫
杉田義明鈴木弘武田知久
田中慎一郎長井則一郎中国順三
中野秀男西尾出野村敏次
野村行憲針谷明深淵弘恭

藤本司郎村井進盛岡政敏

17 , 604 ,476

会計監事辻淳二吉村成弘
この収支計算書は.公益法人会計基準に示されているよ

うな収支ペースのものではなく，領益ペースによって作成してある(企業会計の損益計算書に該当するものである) .

‑
6
8
‑

似たな「加まク関批れム参一にわ

更新会費

4

3 ， 540 ，α)()

4

新入会費

事青島茂稲田 1奪岡田正志

SeamanVol.3 , No.3‑
4

BOD , GeneralMeetlng , andOtherE
v
e
n
t
s

3. 今年度予算
引き続き，次のような新年度予算案が提案され，やはり5 月の幹事会

満場一致て啄認された.

予算書

5 月の幹事会は.

自昭和 63 年 4 月 1 日
至昭和 64 年 3 月 3 1 日

5 月 26 日(木)夜，織械振興会館で開催された.出席者は以下の通り:岸田，熊谷.佐藤，松原，青島 ， 岡田 ， 片山，川北.杉田.田中.中園.針谷，
支出の都

深瀬，盛田 ， 高田[シンポジウム委] .中島[事務局] .

人件費

1 ， 2∞，αlO

事務所費

4 ， 200 ，αm

印刷費

4 ， 8∞，αlO

通信費

3 ，氏氾，α)Q

会議費

5∞，α)Q

広報費3∞，α)Q

消耗品費3∞，α)Q

雑費

2∞，α)Q

当期収支差額2 ，氏氾，αlO

合計17 ， 7∞，α)Q

1.報告

5 月 10 日の総会および月例フォーラムについての報告があった.フォーラムの収支は引き続き好調で，約 5 万円の収益が本体に寄付された.
2.6 月のイベント
高田委員長から.シンポジウムの最終準備状況の報告があった . 参加申込みは採算ラインを突破，回復の 300 人

まであと一息ということで，各自さらに追い込みの勧誘を行なうことを申し合わせた .
また. 6 月フォーラム「ハイパーメディア J は.テーマの選定がタイムリーだったせいか，これまでの月例フォー
ラムのなかでは参加予約の出足が最高であることが，事務収入の部局から報告された .
新入会費

4 ， 2∞，α)Q

更新会費

5 ，α)Q，α)Q

賛助会費

2 ，α)Q，α氾

寄付金

4 ， 5∞，α)Q雑収入

2 ，α)Q，α)Q

合計

3. 夏以降のイベント企画
次の各イベントの企画の詳細が説明された(ただし本印の 2 つについては，担当幹事欠席のため概要のみ). 7 月フォーラム(勺-信頼性ワークショップ. 第 6 回若手の会(・)

17 ， 7∞，α)Q-第 4 田技術交流会. 第 2 回教育ワークショップ
4. その他.第 8 回信頼性シンポジウム

以上で正式の議題を終わり.続いて.新常任事宇事に選ば-第 4 回実践的開発環境に関する集中討論

これらの各イベントについては，論文または多加者募集れた各氏からそれぞれ挨拶があって . 総会を終了した.
なお，総会に先立ち.同日午後同じ会場で月例フォーラのチラシをシンポジウムの会場で配布し，また全会員に郵

ム rcASE ツールの現状と動向」が開催され ， 約 40 名が送することが決まった(会員への配布はすでに終わってい参加して，熱心な討論が行われた.

るが.念のため ， 本誌 71 ページ以降に再録してある) .

また.総会終了後.機械振興会館 6 回のレストラン ・ パ

また.熊谷幹事から，来年 1 月に盛岡で，中年管理者のークヒルで，第 4 回環境ワークショ ッ プ(実践的開発環境

ためのワークショップ(若手に対抗する会? )を行いたいに関する集中討論)の企画ミーティングが有志を集めて行という提案があり，基本的に了承された.詳細は後日あらわれた .

ためて討論する.
4. 款のセミナー-ウィーク

9 月下旬に開催の予定.現在会場を機械振興会館に予約してあるが.月~水の 3 日間なので ， 別の場所(青年会議

‑
6
9
‑

BOD , GeneralMeeting , andOtherE
v
e
n
t
s

所会館)に移し，火~木に変更を考えている旨，事務局かSeamaUVol.3 , No.3‑
4

た.いずれ本誌上でレポートできるだろう.

ら報告があった.プログラムの詳細は，来月の幹事会で検討することになった .
5. 分科会および支部の活動扶況

日中シンポジウム

出席の各幹事から，それぞれが関係している分科会や支部の最近の活動状況や今後の計画について.説明があった.

現在いくつかの分科会の活動が低迷し，休眠状態にある
10 月に予定されている第 2 回日中ソフトウェア・シン

が，その立て直しをどうするかについては . 来月以降あらポジウムの参加者打ち合わせ会(顔合わせと最初の企画ミ

ためて検討することになった .

ーティング)が，ソフトウェア・シンポジウム，

88 第 2日目の昼食休憩時間に，来日中の張然先生(上海・復 E大学)を交えて，虎の門パストラルで開かれた.日本側 20

ソフトウェア・シンポジウム '88

名の参加者を 4 名ずつ 5 つの討論グループに分けることで ，でした

ほぽ意見の一致を見た.

当協会の主要年中行事であるソフトウェア-シンポジウ
ム，

88 は，

6 月 8~9 日に東京 ・ 虎の門パストラルで開催された.有料参加者は約 300 名(うちSEA および振興会館で行われた併設チュートリアルは， 4 セ ッ ション‘

とりあえず.全員がそれぞれのグループ討論テーマに関Hyp

する簡単なポジション・ステートメントを書き.別件で 6

イメー

月末に上海を訪問する岸田・杉田両総事が，中国側と最終的な打ち合わせをすることになった .

側の基調報告者は，落水浩一郎(静岡大)

おそ

例にな

また，シンポジウム冒頭の全体セッションにおける日本

JISA 会員はそれぞれ 45% ，一般 10%) ， 他に招待者を含めて合計 350 人が参加した.シ ン ポジウムの前日に織械

7~・野村敏次(JIP) の両氏に決まった .

千円~
は，通

L
e
t

あわせて 110 名が受講した .

今回のプログラムは ， 米国から W. sca∞凶 (USC) ，中(1)

国から張然の両氏を招待講演者としてお迎えし.また.一

6-7 月のフォーラム

般応募論文の発表の他に， 8 大学 ・ 1 研究所からのツール

(2 )

(3)

展示およびプレゼンテーショ ン をあわせて ， 3 トラック併列の形で構成された.例年に比較して論文の粒もそろい .
6 月 27 日夜に開催が予定されている月例フォーラム「

内容的にもかなり充実したものであった.

Hyper-Te双と hyper-MediaJ は，とりあげたテーマがき(4 )氏を記念して 1983 年から制定された)には . 大阪大学

わめてホットな話題であるせいか.参加申込みは，これま(5 )Iの松本健一 - 井上克郎 ・ 菊野~ .鳥 居宏次共同執筆 によるでの月例フォーラムで最高の 62 人に途した (6 月 21 日

「ソフトウェアの残存エラー数推定モテツレの定量的比較 J

現在)

最優秀論文貧 (1 日ソフト協の会長であられた故・服部正なお.引き続いて同じテーマでの討論 (P訂t ll)を考え(発表者は松本健一氏)が遊ばれた.大学関係者の受賞は初めてである.ちなみに ， これまでの受賞者は:.

ている 7 月の横浜ブルーナイト ・ フォーラムも，すでに申83 年白井議美 (JIP)

込みが 20 人を越えている.参加希望者はお早めに事務局

84 年佐原伸 (NCC)

宛 FAX を!

85 年伊藤春男(リコーシステム開発)

氏名(86 年西山総 (MRI) および渡辺益秀 (NES)
87 年大形和宏 (NES)

シンポジウムの論文集は ， まだ若干の在庫があるので.

m入を希望される方は事務局まで申し込まれたい . なお.
会社(

基調講演および 2 つのパネル討論の模様はテー プ に収録し

郵門 :
住所:

‑
7
0
‑

TEL

S
E
A
.Forum July'88 初 Yolt:ohama

Part1
1

Hyper・Text をめぐっての論議

VuualProgrammlng のあるべき姿を求めてまたは‑ HyperCard~ 5GL! ‑ふW卿

主催:ソフトウェア技術者協会

7 月の Forum は，会場を横浜に移して， Y 以犯の主催により開催します.もともとは鉛を借り切って洋上 Forum にする積りでしたが.費用その他の関係て\通常の Y 以)c例会の形式を雌鐙します.討給テーマは，

6 月の Forum の続きで， Ma c のHyper Card によるさまざまなアプリケーション・システムのデモンストレーションを交えて，これからのソフトウェア開発のイメージを探ることにしました .

おそらく，語論は予定の時間内には終わらないでしょうが， Y ∞C では.話の続きを中華街のどこかで深夜まで行なうことが恒例になっています.それに参加し.ミナト ・ ヨコハマで 1 夜を過ごしたいという方は，

6 月末までにお申込みいただければ，1泊 5千円 --1 万円のシングル ・ ルームをどこかのホテルに予約できるだろうと.世話人の蔵野さんがいっています(横浜の週末のホテル

11.通常どこも満員てす) .希望者はお早めにどうぞ .

Let's ta~k together in the 'B~ue Light ・ Yokoha閥!
開催要領

(
1)日時:

昭和

(
2)会

神奈川県労働福祉センター (JR 関内駅徒歩場:

63 年 7 月(3)コーディネータ :29 日(金蔵野

パネリスト(予定

19:00 ‑

20:30
4分，横浜球場並び)

晃延 (FXlS)

青島茂 (FXlS)

熊谷章( PFU)

佐原伸

杉原誠(日本シュルンベルジュ)(SRA)

野中哲(日本電気}(
4)参加費

3000 円 (SEA会員(
5)申し込み及び参加方法:

6000 円{一般

1000 円(学生)

下記の申込書にご記入の上.郷便またはFAXでお送り下さい . 折り返し受講ハガキをお送りします . 受檎料は，当日現金で受付にてお支払下さい.ただし，定員 (40 名)になり次第，締め切らせていただきますので.あしからずご了承下さい.申込後のキャンセルはお断わりします .
申込先:〒

102 東京書官千代田区隼町 2 ‑ 12 .和半蔵門コープビル 505
ソフトウェア技術者協会・ 7 月フォーラム係

TEL 03 ‑ 234 ‑ 9455 ,FAX 03 ‑ 234 ‑ 9454

SEAFOTumJuly ・ 88 i
nYokohama 参加申込書{申込日 :一一一月一一一日)(ふりがな)
種別(いずれかにチェ・y ク口 SEA会員

参加費 :宿泊:口希望する(NO._____

円

口希望しない(学絞)名:
役臓 :(〒L: 一一一.一一ー.

(内録

)

口一般

口学生

第 4 回

ソフトウェア技術交流会

主催
ソフトウヱア銭術者也会 (SEA)

ソフトウェア分野におけるテクノロジー・トランスファの促進を目指す

SEA ならではのこのユニークなイベントも， 4 回目をむかえます .今 回は.徳島大学の山本米雄先生にコーディネーションをお願いし，また「一太郎」のジャスト・システム社のご悔力

4ESE

参加者募集

を得て，会場を四国に移し.下記の要領により開催します.これまで通り . 企業サイドからの多数の参加をお待ちします .

1.期日:

昭和 63 年 9 月

2. 会場:

徳島大学工学部知能情報工学科 C10 教室
50 名
SEA 会員6 日(火 )~7 日{水)15 ， 000 円，一般 20 ， 000 円.大学関係者 2 ， 000 円(宿泊費は含みません)

l
H
刊

3. 定員
4. 会費

un 創ぱ釦比
CLSCP

開催要領

9 月

Rkd
PRSGF

5. プログラム予定)

13;00 ‑ 20;00

6 日(火)[基調講演]ソフトウェア国富論:

岸田孝一 (SRA)

中村正三郎(管理工学)

神田泰典(富士通

西林瑞夫(エルゴソフト)

Edgar

Cooke (SRA)

安田知弘(東海クリエイト)Hau

浮川和宣(ジャストシステム)

DDLL[パネリスト]り[コーディネータ]

DTP。

1 : ワープロ，日本語処理，

申 剖ゆ・パネル討論浮川和宣(ジャストシステム).徳島大学知能情報工学科の紹介

CAI (山本研究室).

付

自然言語処理(育江研究室

[講演]

cnzuh

7 日(水)

τGR. 懇親パーティ

9 月

09;30 ‑ 15:00

Hyper Card 孟

藤野晃延 (FXIS)

熊谷章 (PFU)
他とソフトウェア技術者教育
山本米経{徳島大)山[コーディネータ]

山口高平(阪大)

U04

CAI

大木幹雄 (J I
P
)

TN&CP

伊野誠 (SRA)

ゆ[パネリスト]

副エキスパート ・シス テムの応用[コーディネータ]

・パネル討論 3:

?:

広 Lω

・ パオ、ル討論 2:

5GL

戸 5

並列処理(高橋研究室)a

落水浩一郎(静岡大)君島浩(富士通)

寺嶋祐一{日電ソフト)‑1

徳島大学工学部知能情報工学科山本米雄

ので，あらかじめ御承知おきください.会費は当日会場で申し受けます.

川内FAX) でお申込ください.ただし，受付は先着順とし，定員オーバーの場合はお断りすることがあります-t'i

宛に郵便(またはFAX 0886 ‑ 23 ‑ 2761

日H

TEL 0886 ‑ 23 ‑ 2311 (内 4712)

1MMh・

干 770 徳島市南常三島町 2

向

下記の申込書に御記入の上

UMRRumm‑ 17:00)

1

会議終了後，希望者はジャストシステム見学 (15:30

6. 申込方法:

杉図書豊明 (SRA)

有湾博(積浜田大)はセマンティック・データベース・モデル:

は[パネリスト][講演]To
第 1 回技術交流会参加申込書

氏名:

(口

SEA 会員口一般口大学)

会社(大学)名 :
所属 :
住所:〒(

O
t
J
電話

)一(

)一(

C
a
l
lf
o
rP
a
p
e
r
s
』 VEL

胤川 EG

RR

mbR 山川
附印AR

花モ M 曹に」
山川 TN
mαEE ミ J

日

4EOY

4ES

を

CHAIR
L
a
r
r
yDruf
T
e
l
S
o
f
t
w
a
r
eE
n
g
i
n
e
e
r
i
n
gI
n
s
t
i
t
u
t
e
C
a
r
n
e
g
i
eM
e
l
l
o
nU
n
i
v
e
r
s
i
t
y
Pittsburgh , PA15213-3890, USA
(
4
1
2)2
6
8
‑
7
7
4
0
PROGRAMCO・ CHAIRS
R
i
c
h
a
r
dF
a
i
r
l
e
y
S
c
h
o
o
lo
fI
n
f
o
r
m
a
t
i
o
nT
e
c
h
n
o
l
o
g
y
G
e
o
r
g
eMasonU
n
i
v
e
r
s
i
t
y
Fairfax , VA22030 , USA
(
7
0
3)7
6
4
‑
6
1
9
5
D
i
n
e
sB
jr
n
e
r
DanskDatamatikC
e
n
t
e
r
L
u
n
d
t
o
f
t
e
v
e
j1C
L
y
n
g
b
yDK・ 2800 ， Denmark(
45)2-872・622
TOOLSFAIRCHAIRGradyBooch
R
at
i
o
n
a
l
8
3
5SouthMooreS
t
r
e
e
t
Lakewood , CO80226 , USA
(
3
0
3)9
8
6
‑
2
4
0
5
TUTORIALSCHAIR
NormanG
i
b
b
s
S
o
f
t
w
a
r
eE
n
g
i
n
e
e
r
i
n
gI
n
s
t
i
t
u
t
e
C
a
r
n
e
g
i
eM
e
l
l
o
nU
n
i
v
e
r
s
i
t
y
Pittsburgh , PA15213-3890 , USA
(
4
1
2)2
6
8
‑
7
7
0
3

ます

lOCALARRANGEMENTSCHAIR
M
i
l
e
sB
a
r
e
l
n
c
F
o
r
m
a
t
i
v
eTechnologies , I
F
o
s
t
e
rP
l
a
z
aV
I
I
6
6
1AndersonD
rivePittsburgh , PA15220 , USA
(
4
1
2
)9
3
7
‑
4
9
4
2
T
oBeSponsoredBy

的…GSOFT

Pittsburgh , Pennsylvania , USA May15-18 , 1989

Theterm “software e
n
g
i
n
e
e
r
i
n
g
"wascoinedi
n1968todenoteanewd
i
s
c
i
p
l
i
n
econcerned
w
i
t
ht
h
et
e
c
h
n
o
l
o
g
i
c
a
laspectso
fdevelopingandm
o
d
i
f
y
i
n
gcomputers
o
f
t
w
a
r
esys
.
t
ems.
Twentyyearshaveelapseds
i
n
c
et
h
e1968‑69NATOWorkshopsonSoftwareEngineering ,whichareg
e
n
e
r
a
l
l
yacknowledgedt
obetheseminalmeetings.t
Ii
snowa
p
p
r
o
p
r
i
a
t
et
o
commemoratethepas
ttwentyyearso
fs
o
f
t
w
a
r
ee
n
g
i
n
e
e
r
i
n
gandt
ol
o
o
kf
o
r
w
a
r
dt
ot
h
en
e
x
t
twentyyears.
heConferencew
i
l
la
t
t
e
m
p
tt
o
I
ns
u
r
v
e
y
i
n
gt
h
eaccomplishmentso
ft
h
ep
a
s
ttwentyyears , t
i
d
e
n
t
i
f
yr
e
c
u
r
r
i
n
gthemesandl
a
s
t
i
n
gc
o
n
t
r
i
b
u
t
i
o
n
s.I
nl
o
o
k
i
n
gf
o
r
w
a
r
dt
ot
h
en
e
x
tt
w
e
n
t
y
i
l
lbemadet
oi
d
e
n
t
i
f
yt
h
emajortrendsinhardware , software , andyears , anattemptw
s
o
c
i
e
t
yt
h
a
tw
i
l
lshapet
h
ef
u
t
u
r
eo
fs
o
f
t
w
a
r
ee
n
g
i
n
e
e
r
i
n
g
.
TheConferenceprogramw
i
l
li
n
c
l
u
d
ebothi
n
v
i
t
e
dandc
o
n
t
r
i
b
u
t
e
dpapers. Authorsfroma
l
l
c
o
u
n
t
r
i
e
sareencouragedt
osubmith
i
g
h
‑
q
u
a
l
i
t
yc
o
n
t
r
i
b
u
t
i
o
n
si
nt
h
emainstreamt
o
p
i
c
a
l
areaso
fs
o
f
t
w
a
r
ee
n
g
i
n
e
e
r
i
n
gandi
nareast
h
a
ta
r
eo
fc
o
n
s
i
d
e
r
a
b
l
er
e
l
e
v
a
n
c
et
os
o
f
t
w
a
r
e
x
p
e
r
tsystems , userinterfaces , andhardware
engineering , suchasdatabasetechnology , esuppo パ for s
o
f
t
w
a
r
ee
n
g
i
n
e
e
r
i
n
genvironments. Eachsubmissionw
i
l
lbee
v
a
l
u
a
t
e
dbyt
h
e
ProgramCommittee , whowillassesst
h
eq
u
a
l
i
t
yandr
e
l
e
v
a
n
c
eo
ft
h
es
u
b
m
i
t
t
e
dpapers.
heConferencew
i
l
lf
e
a
t
u
r
ea
Proposalsforpanelsessionsarealsowelcome. I
naddition , t
SoftwareToolsFairandat
o
o
l
sp
r
e
s
e
n
t
a
t
i
o
nt
r
a
c
k.

SubmittingaPaper: Fourcopies(
i
nE
n
g
l
i
s
h
)shouldbes
u
b
m
i
t
t
e
dbySeptember15 ,1988 , toeitherProgramC
o
‑
C
h
a
i
r
:
• RichardF
a
i
r
l
e
y
Schoolo
fI
n
f
o
r
m
a
t
i
o
nTechnology
GeorgeMasonU
n
i
v
e
r
s
i
t
y
Fairfax , VA22030USA

u
l
l
‑
p
a
g
ef
i
g
u
r
e
sbeingcountedas300words.
Papersshouldbel
i
m
i
t
e
dt
o6000words , f
Eachpapershouldi
n
c
l
u
d
eas
h
o
r
ta
b
s
t
r
a
c
tandalistofkeywordsi
n
d
i
c
a
t
i
n
gs
u
b
j
e
c
tc
l
a
s
s
i
f
i
ｭ
c
a
t
i
o
n.N
o
t
i
f
i
c
a
t
i
o
no
facceptancew
i
l
lbes
e
n
tbyDecember15 , 1988 , andcamera‑ready
copyo
ft
h
ef
i
n
a
lv
e
r
s
i
o
nw
i
l
lbedueonFebruary15 , 1989.

ToolsFair: ASoftwareToolsFairw
i
l
lbeh
e
l
di
np
a
r
a
l
l
e
lw
i
t
ht
h
eConference.The
ToolsF
a
i
rw
i
l
la
l
l
o
wconferenceattendeest
oseeandlearnaboutc
u
r
r
e
n
ts
o
f
t
w
a
r
et
o
o
l
s.
Bothe
x
p
e
r
i
m
e
n
t
a
landcommercialt
o
o
l
sw
i
l
lbedemonstrated.I
naddition , theconference
fs
o
f
t
w
a
r
et
o
o
l
s
w
i
l
lf
e
a
t
u
r
eaprogramtrac
kdedicatedt
opresentatぬ n anddemonstrationo
s
p
e
c
i
a
l
l
y
s
e
l
e
c
t
e
dbyt
h
eToolsFairCommittee.Thosei
n
t
e
r
e
s
t
e
di
ne
x
h
i
b
i
t
i
n
gatool , ande
thosea
u
t
h
o
r
si
n
t
e
r
e
s
t
e
di
np
r
e
s
e
n
t
i
n
gapaperd
e
s
c
r
i
b
i
n
gap
a
r
t
i
c
u
l
a
rt
o
o
landd
e
m
o
n
s
t
r
a
t
ｭ
i
n
gt
h
a
tt
o
o
lshouldc
o
n
t
a
c
tt
h
eToolsFai
rChair.
• GradyBooch
R
a
t
i
o
n
a
l
835SouthMooreS
t
r
e
e
t
Lakewood , CO80226USA

F
u
r
t
h
e
rI
n
f
o
r
m
a
t
i
o
n
: Forfurtherinformationand/oracopyoftheadvanceprogram
whenavailable , writetoICSE11 , c/oIEEEComputerSociety , 1730MassachusettsAve.,
N
Washington D.
C.20036USA.w.,,

Impo同ant D
a
t
e
s
:

SubmissionDeadline:September15 , 1988
AcceptanceN
o
t
i
f
i
c
a
t
i
o
n:December15 , 1988

町
@Tm"Ec∞。MP附E聞R蹴ωIETY凶 OFTHEIEEE

O
t
h
e
rs
p
o
n
s
o
r
s
h
i
psh
a
v
eb
e
e
nr
e
q
u
e
s
t
e
d

• DinesBjrner
DanskDatamatikCenter
L
u
n
d
t
o
f
t
e
v
e
j1C
LyngbyDK・ 2800 ， DenmarkFinalVersionsDue:February15 , 1989
IEEE(

THE INSTITUTEOFELECTRICALANDE印刷 ICS ENGINEERS , INC

集

百聞

募

吾ム

文

ェア・シンポジウム '89
年

1989

14‑15 日(予定)

6月く〉

農林年金会館(東京・虎ノ門)
共催: (社)情報サーピス産業協会 (JISA)
ソフトウェア技術者協会 (SEA)

1: ゃいもので、ソフトウェア.シンポジウムも第 9 回目を迎えます.

産業界の ft 前線で、日頃忙しくソフ

トウエアの開発.保守 ・運用・管理に従事しているエンジニアたちが、それぞれの仕事のなかから得た経験や知絵、アイデア、あるいは意見を交豊島しあうための貴重な場として、多くの方々の賛同を頂き、内容もますま
す充実してまい句ました.
ここ 1 ・2年、ネヲトワークの整備や高機能ワークステーションの普及、あるいはマルチ・メディアなど、各種先進的筏法/ツールの実用化など、ソフトウェア業界をとりまく状況は急速に変わりつつあ句ます.今回のシンポジウムでは、こうした新しい社会的・筏術的環境への対応を発表や肘愉の主題として、従来にもまして魅力的なプログラムを組みたいと考えております.

実践的筏術の経験、先進的筏術の伏行結果、基礎研究の成果等に関して、ヴ 7 ライテイに富む多数の倫文がょせられることを期待いたします.

…………

,..,..,,J"""'N""".̲
̲
NI#'~.....'.'.
.

・.:.:.:.:.:.:.::.

:ぷこさふ募集5鉱之ニニzJi:ぶ滋;
特に限定はしていませんが、たとえば、次のような話

題がセ 7 ションーテーマの候補として考えられます:-ソフトウェア開発における AI 関連筏衡の応用
・実際のプロジェクト支援環境における問題点

ゑぷ繁二二広義裁ぶ;二込~lli~綴応募険文の概要を 4千字 -6千字程度にまとめたもの(ワープロまたはコンピュータ出力で A4版 4-5 ページ}の

コピー 10郡を、

1988 年 11 月 30 日までに・新しい開発/保守方法齢の笑践とその評価

2 人のプログラム委員長{藤野晃延または飯沢包}のいず・ユニークなアプリケーション開発の事例

れか宛にお送りくだきい.

・筏術者教育のケース.スタデイ

・ドキュメンテーションの機俗化/合理化
・ネヲトワークのセキュリテイ/維持/管理
・プロジェクトにおける授術移伝プログラム委員会で応募倫文の審査を行い、結果を

1
98
9~手 1 月末までに、応募者会員にお知らせします.
審査を通過した方々には、発表用の最終検文(予稿集に<<lせるためのカメラ.レディ原稿)を 1989 年 3 月末までに.LAN を用いた分散型環境の総祭・利用・先進的ソフトウェア ・ ツールの伏作 ・ 実験

仕上げていただくことになります.

・ソフトウユア.プロダクトの流通と徳利保Ii

アルなどに関して、何かアイデアがあ句ましたら、実行・定量的マネジメント.各種モデルの適用と評価

委員長までご連絡ください.

等身.

その他、パネル討除のテーマや招待..演、チュートリ

総務 ー ジン殺す玄でてZZ芝鴻議~
実行事告員長プログラム委員長

林香

飯沢恒

ソフトウェア・リサーチ.アソシエイツ

三蓑電機束郡コンピュータ・システム

環境開発本航干 102 千代田区平河町 1 ・ 1 ・ 1

干 247 鎌倉市大船 2-19 ・ 28

2
6
1
1
T
e
l
.
0
3‑234‑
ツール展示委員長

コントロール第一郎

T
e
l
.0
4
6
7‑45‑7316

藤里子晃延

高田佳彦

富士ゼロックス情報システム

日本電子計算科学筏術事業部〒 160 新宿区西新宿 3 ・ 16 ・ 6 西新宿水野ピル〒 103 中央区日本縫兜町 6 ・ 7
Tel.03 ・ 668-6171

筏術推進室企画限Tel.
0
3‑378‑
80
1
0

ソフトウェア信頼性の定量的管理に関する
ワークショップ
参加者募集

主催:高信額佐ソフトウェア研究会
後媛:ソフトウェア技術者也会 (SEA)

昨年の夏，高信頼性ソフトウェア研究会では .

lEEE Draft Standard for software Qua.
lity Metricsの内容を検討するワークショップを伊豆高原で開催し ， 大きな成果を収めました(報告書は昨年 1 0 月に

SEA

から

刊行ずみ)

今回のワークショ ッ プでは.議論をさらに一歩進めて，当研究会メンバーの手で現在取りまとめているソフトウェ
ア信頼性管理{各種の定量化指標をどのように設定し . 現実のプロジェクトにおいてどのように計測を実施し.結果の妥当性をどうやって評価するか)に関するガイドライン試案を現実のプロジェクトに適用した場合.どのような問題点が生じるか，それはどうすれば回避できるか，等などのことがらを . さまざまな角度から検討したいと考えています.
具体的には.参加者の方々にそれぞれ ， 身のまわりにある実際のプロジェクトをサンプルとして持ち寄っていただ

き.それらのプロジェクトにおいて.このガイドラインにもとづく信頼性の管理を実施したらどうなるかを ， ケース・スタディ方式で考えてみようということです .

討論の性格上，参加者の人数は25

名(当研究会メンバーを含めて)に限定させていただきます.関心ある方々の積極的な御多加をお待ちします.

開催要領

1.期日:

昭和 63 年 8 月

2. 会場:

八ヶ岳高原・泉郷(山梨県北巨摩郡 ・ JR 中央本銀小淵沢駅からパス

24 日{水)午後から 26 日{金}正午まで (2 泊 3 日)

3. 定員

25 名

4. 費用

50.000 円

10 分}

現地集合 ・ 現地解散とし.期間中の宿泊費 (3 食付き}および資料代を含みます.
5. スタヲフ{高信銀位ソフトウェア研究会}代表:

鳥居宏次(大阪大学)

僻事:

浦野義頼 (KDD 上福岡研究所)

会員 :

天池学(沖電気)飯沢恒{三菱電気東部コンビュータ)

岸田孝一 (SRA)

久保宏志(富士通)

花田収鋭 (NTI)

保田勝通{目立)

7. 申込方法:

岩丸良明(三井銀総研)

春原猛(三菱電機)

大場充(I酬)寺本稚則(日本電気)

山田淳(東芝)裏面の参加申込用紙に必要事項を記入の上.昭和 63 年 7 月

18 日(月}までに，郵便または FAX で，下記宛お送り下さい.申込者多数の場合には . ポジション・ステートメントの内容を審査の上 ， 参加者を選考させていただ

きますので.あらかじめ御了承ください
申込み先:
〒 356

埼玉県上福岡市大原 2‑ 1 ‑ 15

KDD 上福岡研究所主幹研究員
浦野義頼

Tel
.
: 0492 ‑ 66 ‑ 7304
Fax: 0492 ‑ 66 ‑ 7510

紳・.面に申込用紙があります榊吻

送付先:
干 356

申込日付:

月

日

埼玉県上福岡市大原 2 ‑ 1 ‑ 1
5KDD 上福岡研究所主幹研究員浦野義頼

Fax: 0492 ‑ 66 ‑ 7510

ソフトウェア信頼性の定量的管理に関するワークショップ

参加申込用紙氏名:

くふりがな)

年齢---(和性別:口男口女

血液型:

会社名:
部門:

役職:

住所(〒

TEL: (

)‑ (

)‑ (

〉内線〈

ポジション・ステートメント:
信頼性定量化のケース・スタディとして.どのようなプロジェクトをワークショップで提示できますか?
のプロジェクトは ， すでに完了したものですか?

定のものですか?

プロジェクトの特性は?

現在進行中ですか?

そそれとも，これからスタートする予開発チームのサイズ，メンバー構成，開発期間，開発内容-手順，信煩性やその他の品質上のリクワイヤメントなど.なるべく具体的にお書きください . 紙面が足りない場
合は.別紙を追加していただいてかまいません .

第 6 回夏のフ。 ログラミング・ワークショップ

ソフトウェア-エンジニアリング技法のケース・スタディーソフトウェア開発の「銀の弾丸 J を求めて

ー

参加者募集
主催:ソフトウェア技術者協会f愛媛祉}情報サービス産業也会

これまで 5 年間「若手の会

in盛岡」として開催されてきたこのワークショップも，いまではすっかり定着し，業界各社からも，次世代のエースを鍛える格好なトレーニングの「場 J として高く評価されています .

第 6 回目を迎える今年は . 会場を八 ヶ 岳山麓の別荘村に移し.運営スタイルも「若手の会 J 0 B を中心とするケース ・ スタディ方式を採用して.より具体的な課題を全員参加のグループ討論を通じて徹底追求することにしました.
今回の討論テーマとしては，ややもすれば名前だけが先行し現場への浸透が遅れている開発技法のいくつかを取り上げ ， それ ぞ れの長所 ・ 短所を十分に比較検討しようと考えています .

具体的には:- 形式的仕線記述を用いたアプローチ. オブジェクト指向の ア プローチ

- エキスパート・システムによるアプローチ
・ CASE

ツールを用いたアプローチ

・プロトタイピングによるアプローチなどを用いて現実的な例題にアタ ッ クし.

f.Brooksの高名なエッセイに述べられた「鎮の弾丸 J(ソフトウェアという魔物を倒す最終兵器)の可能性を探ろうというのが ， その狙いです.
多くの若手技術者方々の積極的な御参加をお待ちします .

開催要領
1.期日:

昭和 63 年 8 月

2. 会場:

八ヶ岳高原・泉郷(山梨県北巨摩郡・ JR 中央本線小淵沢駅からパス

3. 定員

35 名

4. 参加資絡:
5. 費用

31

日(水)午後から 9 月

3 日{土)正午まで (3 泊 4 日)
10 分)

年齢 30 歳未満，経験 2 年以上のソフトウェア技術者

60 ， 000 円 (SEA 会員. JISA 会員)，

80 ， 000 円(一般〉

現地集合 ・ 現地解散とし ， 期間中の宿泊費 (3 食付き)および資料代を含みます.
6. スタヲフ:

実行委員長 :

藤野晃延(富士ゼロ ッ クス情報システム)

プログラム委員長 .

坂下秀(アステ ッ ク)

プログラム委員:

岡芹晃(東芝エンジニアリング)

沢田寿美 (SRA)

松下和隆(三菱電気東部コンビュータ)
招待講演者(予定柴山悦哉(東京工業大学)

7. 申込方法:

渡辺雄一(電力計算センター)

他・数名

寺野隆雄(電力中央研究所)

裏面の参加申込用紙に必要事項を記入の上 . 昭和 63 年 7 月

18 日{月)までに ， 郵便または fAX で，実行委員長宛お送り下さい.申込者多数の場合には，プログラム委員会でポジション ・ ステートメントの内容を審査の上，参加者を選定させていただきますので，あらかじめ御了承ください
申込み先:

〒 160

東京都新宿区西新宿 3 ‑ 1
6 ‑ 6 西新宿水野ビル

富士ゼロ ッ クス情報システム(株)技術推進室企画課

藤野晃延

T
e
L
: 03 ‑ 378 ‑ 8010 (ext 6791) fax:03 ‑ 378 ‑ 7298

料市裏面に巾込用紙があります"。

送付先:
〒 160

申込日付:

月

日

東京都新宿区西新宿 3 ‑ 1
6 ‑ 6 西新宿水野ピル
富士ゼロックス情報システム(株)技術推進室企画課

藤野晃延

Fax: 03 ‑ 378 ‑ 7298

第 6 回夏のフ。ログラミング・ワークショップ

参加申込用紙

氏名:(ふりがな〉

年齢---(請。

性別:口男口女

血液型:

会社名:
部門:

役職:

住所(干

TEL: (

)一(

)一〈

〉内線(

これまでの主な開発経験:

ポジション・ステートメント:
ソフトウェア開発工程(特にシステム分析や設計などの上流工程)の生産性や品質の改善について，今後どんな方策を講じるべきかを，自分のこれまでの経験や知識に則して.なるべく具体的に書いてください .

C
a
l
lf
o
rP
o
s
i
t
i
O
DPapers
第 2 回

ソフトウェア教育に関するワークショ'"プ

ソフトウェア教育への技術的接近
主催
ft 育分科会 (SIGEDU)
ソフトウェア銭術者也会 (SEA)SEA SIGEDU は分科会の発足以来、各社の歓育活動の情報交線や各種の見学会を開催し、活発に活動してまいりました.昨年のワークショ・y プにおいては，さいわいにも第一線でソフトウェア教育に関心のある個性豊かな参加者に恵まれ、率直で新鮮な鎗論をすることができました.

今回は、さらに一歩突っ込んで、より具体的で実際的なテーマを取り上げ強論を行ないたいと思います.特に数育の手法、

テクニックや現場の妓術マ'"プと教育体系との対比や、新しい教育のスタイルなどについても議論してみたいと考えています.教育体系を中心として、それをどうやって導き出すか、どんな形で教えるかを技術的に究明しようという方や新しい技術の開発現場への移転を試みておられる方々の参加を募ります . 今回のサプテーマとして、-教育銭法 ・テクニック、.C A1. マルチメディア教育.A 1 . オブジェクト指向、環境技術教育
・教育評価 、 効果測定

取り上げたいと考えていますが、以下の分野について問題意識を持っておられる方や話題を提供して下さる方も歓迎致します.気軽にお申込をしてくださるようお願いします .
- 新入社員教育

・入門教育- 先進的ソフトウェア工学と教育・中堅社員教育・ ソフトウェア技術移転

・管理者数育・ 学校教育と企業内数育・ キャリアパスの設定と教育

・経営戦略と教育活動

開催要領
1 . 期日:昭和 63年 9月 29 日{木)午後から 10月 1 日{土)正午まで (2泊 3 日)

2. 会場:

滝の湯ホテル{山形県・天童市

3. 定員

30 名

4. 費用:

τEL: 但 3 6-54- 2211){スタヲフ}

白，脚円( SEA会員) ,75 ，α湖司{一般)

現地集合( 9月 29 臼(木)日(土)12:∞)とし、期間中の宿泊費{食事付き)およの内容を報告書にまとめ、参加された方に配布致します.
5 . 申込方法:

参加を希望される1rは、事面のポジション・アンケート
付きの参加申込書に必要事項を記入の上、プログラム餐員長宛てに、 FAX または郵送にてお送り下さい.折り返し、

君島渚[プログラム委員長]

大泊洋一(シーイーシー)

大木幹産(日本電子計算)大久保功{横河ヒューレ 'Y トパッカード)

河村一樹{日本電子専門学絞}

逆濁川明宏{月島綴械)

篠崎直二郎(日本電気ソフトウエア)

中国順三(富士通 BSC)

中山照章(富士通 SSL)

平本車(電力計算センター)

平山伸一(神戸コンビューターサービス)

山口圭一

(SRA)

うご案内を差し上げます.申込が多数の掲合には、プログ

9月上旬までに参加者を決定し、結果を応募された方全員にお知らせします .
申込書送付先:「一一一一ー〒 410- 03

静岡県沼津市宮本 140(富士通)[プログラム委員]

ポジション ・ ぺーパを 8月 19 日(金)までに書いて頂くよラム餐員会でポジション ・ ぺーパの内容を審査の上、(SRA)[実行餐員長]13:30) ・現地解散( 10.月 1

び資料代を含みます . なお、ワークショッフ・終了後、討議

(敬称略)

杉田透明

富士通(株)

ソフトウェア開発本部・教育課

君島浩

T
e
l:0559・ 23・ 2222 伍X.5730) F広 : 0559・23・ 1991
6. その他:昨年実施したワークショ・y プの報告書を 1 冊 3. 000 円にて頒布しております . 希望される方は SEA 事
務局 (03-234-9455) まで.お問い合わせください.

{ワークシヨヲプ参加申込書は)1{面にあります . )宛先:

富士通・ソフトウエア開発本部・教育課
第2回 SEA 教育ワークショップ
プログラム委員長

昭和年月

日

君島浩椋

(FAX:0
5
5
9
‑
2
3
‑
1
9
9
1
)
l寧夕日封書ワークシ司噌プ・奉加1 由込書 l
参加を希望される方はこの申込書に配入の上、プログラム餐員長宛に.このまま FAX にて申込んでください.

(年齢:一一歳，性別:男女〉

氏名:申込種別 (SEA

寸お

所属:

会社名:
住所(〒

FAX:

τEL:

J 、業務. ~矧(.

現在の職種(
興味のあるテーマ($羽~****・羽ド$牢

ポジション・アンケート

寧寧$刻隊司B ・ 8 ・~ *寧$l. ft育銭法・テクニヲク:教育そのものの内容を有効でかつおもしろく、エキサイティングなものにするためにさまざまな試みが考えられます.妓術として教育をとらえた場合、あなたの意見は:2. CA1. マルチメディアの活用:

伝統的・教室スタイルの研修方法から、個人の特性に応じた新しいタイプの数育に人気が高まっているようてす.教育環境としてさらに有効なものにするためにあなたの意見は:3. A 1. オブジェクト指向、環境銭街など新しい銭衡の敬育に関して:

ソフトウエア開発の諸問題を解決するために、新しい技術の現場への導入が期待されています . 特に笑践的な環療技術の普及について、具体的な方針・方策を考えると?

4. 敬育の評価、効果測定一連の活動をどのように評価するか、評価のためのメカニズム、ツールは?定量的なアプローチを前提に 、あ なたの経験、アイデア、意見は?

5. オフレコ・セヴション:討論の内容を記録に残さないて'、自由に話し合おうということで昨年は採用問題を取り上げました.
今回も同じ形式にて笑鈍したいと思います.ついては、期待される話題、狙いについてお書きください.

第 8 回

ソフトウェア信頼性シンポジウム
発表者募集
主催:高信領佐ソフトウェア研究会

ソフトウェア技術者也会関西支趨
電子情報通信学会 FTCS 研究専門委員会{予定}

ソフトウェア開発の信頼性向上に関するさまざまなトピ'"クスをめぐって，インフォーマルな(しかし . だからこそ核心を突いた)議論を展開できるユニークな 1 つの場として運営されてきたこのシンポジウムも，回を重ねること

すでに 8 回目を迎えることになりました.

開催要領

1 .期日:

昭和

2. 会渇:

大阪ガーデンパレス (JR 新大阪駅から徒歩 1 0 分)

3 .定員

70 名

63 年

4. 費用{予定10月

SEA 会員28日(金) ~

7.000 円，

一般

29

日(土)

10.000 円，

学生

3. 000 円

6 .スタヲフ:鳥居宏次(阪大)実行委員長 :
プログラム委員長:

白井毅美 (J 1P)

浦野義頼( K
DD)

プログラム委員:

天池学(沖電気)飯沢恒(三菱電気東部コンビュータ)

大場充 (1 BM)

岸田孝一 (SRA)

寺本雅買IJ (日本電気)

久保宏志(富士通)

花回収悦 (NTT)

昨秋と今春は，ソフトウェア品質の定量化指標に関する

岩丸良明(三井銀総研)
春原猛(三菱電機)

保田勝通(目立)

山田淳(東芝)IEEE 穣準化試案を題材として.品質管理のフレームワ

ークについての議論を 2 回続けて行いましたが，今回は.ふたたび以前の自由なスタイルに戻って.一般参加者からの事例発表を中心にプログラムを構成したいと考えています .
たとえば:- ソフトウェア信頼性向上を目指して何らかの方策を講じたプロジェクトの事例(成功例，失敗例いずれでも)-信頼性の定量的な把握のための試みや提案- 各種設計技法やテスト技法の有効性に関する経験的評価.プログラム・パグの分類や原因追跡など，何でも結構です.身近な経験にもとづく具体的な報告を.ふるってお寄せください.

発表希望者は，裏面の応募用紙に必要事項を記入の上 ， 昭和63 年 8 月

22日(月)までに ， 郵便またはFAX

で ， プログラム委員長宛お送り下さい.応募者多数の場合には，プログラム委員会で応募内容を検討した上，プログ
ラム全体でのバランスを考慮して . 採否を決めさせていただきます.
審査結果の応募者への通知と.確定したプログラムにもとづく一般参加者の募集は. 9 月下旬になる予定です.

申込み先:
〒 356

t奇玉県上福岡市大原2‑ 1 ‑ 15

KDD 上福岡研究所
主勝研究員
Te~ :

浦野義頼

0492 ‑ 66 ‑ 7304

Fax: 0492 ‑ 66 ‑ 7510

-・・裏面に申込用紙があります"・

申込日付:

送付先:

月日

埼玉県上福岡市大原 2 ‑ 1 ‑ 1
5

〒 356

KDD 上福岡研究所主幹研究員浦野義頼

Fax: 0492 ‑ 66 ‑ 7510

第 8 回ソフトウェア儲貫性シンポジウム

発表応募用紙(ふりがな〉

氏名:

年齢---(歳)

性別:口男口女

血液型:

会社名:
役職:

部門:
住所(〒
、
〆E、

、 3ノ

TEL: ()‑ (〉内線〈

発表の題目:

発表の要旨:
紙面が足りない場合は別紙を追加していただいてかまいません .
りましたら，添付してください.

また . 関連する論文または技術資料などがあ第 4 回 SEA 環境ワークショップ

実践的ソフトウェア開発環境に関する集中討論
発表者募集
主催:ソフトウェア技術者也会

今度で第 4 回目を迎える恒例のSEA

環境ワークショップは.開催時期を冬から秋に.また会場をこれまでの雪国から異国情緒豊かな港町・神戸に移して.気分を新たに，熱気あふれる集中討論を展開したいと考えています.

開催要領

1 .期日:

昭和

2. 会場:

神戸国際会議場(神戸市ポートアイランド)

3 .宿泊:

新神戸オリエンタル・ホテル (JR 新神戸駅前に今秋オープン)

4. 定員

50 名

5. 費用{予定

63 年

11

24

SEA 会員一般

6.

月日(木) ~

11

月

26

日(土)

70 ， 000 円(宿泊含む) / 30 ， 000 円(宿泊なし)

80 , 000 円(宿泊含む) / 40 ， 000 円(宿泊なし)

スタ守フ:

実行委員長:

盛田政敏( K
CS)

プログラム委員長:

白井義美 (J 1
P)

プログラム委員:青木

中野秀男(阪大)

淳 (FXIS)

久保宏志(富士通)

坂下秀(アステック)高野重(松下電器)君事瀬弘恭(アスキー)

熊谷章( PFU)

佐藤千明(長野県協同電算)
野村行憲( 1
CS)松浦敏雄(阪大)

塩谷和範 (SRA)

平尾一治 (HST)他

運営形悠は，第 2~3 回目と同じように，いくつかのテーマを中心とする連続パネル形式を採用します.先日開かれた企画ミーティングでは .

これまでのワークショップにおける討論がいくらか「とぴすぎて J いたことが反省され，より地に足のついた具体的な議論ができるようにという配慮のもとに，次の 4 つのセッション ・ テーマが選ばれました:(1) Hyper Mediaのソフトウェア開発への応用(2) Man‑Machine Interface(3) Micro‑Mainframe Link
(4) Workstation

上での

の改善
の構築と利用CASE

ツールの活用各 3 時間ずつのセッションでは.まず.これらのテーマに関連するいくつかの技術発表または問題提起をお聞きしたあと.アトランダムな自由討論に入る予定です .
ステーションまたはPC

また.前回初めて試みてたいへん好評だったツール展示(ワークを会場に持ち込んでのデモ)も引き続きプログラムに組み入れたいと思います.

そこで.上記 4 つのテーマに関する発表および関連ツール展示のプロポーザルを募集します.裏面の応募用紙に必要事項を記入の上.昭和

63

年

8

月

1 日(月)までに，郵便またはFAX で，実行委員長宛お送り下さい.応募者多数の場合には ， プログラム委員会で応募内容を審査の上，採否を決めさせていただきます.

審査結果の応募者への通知と.確定したプログラムにもとづく一般参加者の募集は， 9 月中旬になる予定です.
申込み先:

干 650

神戸市中央区浪花町

64 三宮電電ビル

6F(株)神戸コンビューターサービス

ソフトウェア事業部

盛田政敏

Te1
.
: 078 ‑ 391 ‑ 8291

Fax: 078 ‑ 391 ‑ 5452

-・・裏面に申込用紙があります"・

送付先:
〒 650

申込日付:

月日

神戸市中央区浪花町 64 三宮電電ピル 6F(株)神戸コンビューターサービス

ソフトウェア事業部盛田政敏

Fax: 078 ‑ 391 ‑ 5452

第 4 回実践的ソフトウェア開発環境に関する集中討論

発表/ ツール展示応募用紙〈ふりがな〉

氏名:

年齢---(歳〉

性別:口男口女

血液型:

会社名:
役職:

部門:
住所(〒

TEL: (

種別:

)‑ (

口技術発表

)‑ (

〉内線〈

口ツール展示

発表の題固またはツールの名称:発表の要旨またはツールの概要:
紙面が足りない場合は別紙を追加していただいてかまいません . また . 関連する論文または技術資料などがありましたら .添 付してください.

SeamaUVol.3 , No.3‑
4

Membersetc.

SEA 会員状況(昭和 63 年 6 月 22 日現在)
く男女分布〉

1425 名付月 4 日から 66 名増〉

49 社 (4 月 4 日から 7 社増〉

岐阜

=
3-3n
勾

愛知

和歌山=
三重

岡山
鳥取

熊本
佐賀
宮崎

鹿児島=
神縄

守噌 A'i'o'A'A

大分

3'oaa
勾

福岡

4
胃・・内

島穣

品守 'A'A

広島

3'Aa
何，.勾

徳島

4nuoO

変緩

うι-a-y'A 『 d兵庫

お 2314012U411611

奈良

3

大阪

ヲ勾，弓

京書官

口鴎

滋賀

く血濠塑分布>
A型
O型

B 型=

AB 型=

・A

静岡

印以上

εJa 晶守内4

石川

50~

5539

お Mω 柑

富山
福井

4
0
̲
4
4
4
5
̲
4
9

M

=

3539

内4

長野

勾3

神奈川=

弓3

=

-3

東京

却1_34

421

千葉

20
‑
2
4
‑
2
9
25

om 出制泊目別沼口

埼玉

勾3 内4a 且守nsoo'O『， nヲ内 3'420
内3AU
官--nu'au 守'ζdqdtE-qd

茨城

7
4

20 以下

『I20

群馬

-属。0 ・A 勾3zonu--

栃木

住

新渇

即

秋田

居

福島

t8146117738UU596344825
219
3141

岩手

制打叩

動

宮城

務

山形

1
3
5
1

く年・分布>

く正会員の勤.抱8 よぴ居住抱緩分布>

北海道=

男

女

く貧励会員会主t名〉
IN 情報センター. PFU. インターナショナル・データ・リ

サーチ.エヌ・ティ・ティ ・ システム.エムテイシー.サン ・ ビ
ルト印刷.ジェーエムエーシステムズ，セントラル・コン

ビュータ・サービス，センチュリーリサーチセンター(大阪にソフトウェア ・ リサーチ・アソシヱイツ，ニコンシステム.
ニッポンダイナミツクシステムズ.ヒラタ・ソフトウェア ・

テクノロジー.マイクロキャビン.リクルート，リコーシス

テム開発，旭化成工業.伊.忠エレクトロニクス，構造計画研究所，神戸コンビューターサービス，近自民日本ツーリス

ト.経調 . 三菱電鍍，三菱電憾セミコンダクトソフトウェア，
村田銭研.千代田製作所.辻システム計画事務所.情報システムサービス，東海クリエイト.東電ソフトウェア.昭和電
工コンビュータサービス.阪神計算センター.日進ソフト
ウェア.日本ヱム・アイ・シー.日本システム，日本システム
サイエンス，日本情報システムサービス，日本能率コンサル
タント.日本ビジネスデータプロセシングセンター，目立製作所.目立ビジネス織器.富士ゼ口 、y クス情報システム，富士通.富士通ビジネスシステム.富士通ビ ー ・ヱス・シー
{アイウヱオ順}

鍵園

‑
8
5
‑

f=ちL

Z~-y-~~

TT

卿

ソフトウェア技術者協会〒 102 東京都千代田区隼町2-12 腹和半蔵門コー プビル 505

TEL.
0
3
‑
2
3
4
‑
9
4
5
5 FAX.
0
3
‑
2
3
4
‑
9
4
5
4