…

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
Vol

目

次

編集部から

1

第 6 回夏のプログラミング ・ワー クショップ特集

2

C
a
l
lf
o
rPaper

2

プログラム

3

参加者名簿

4

グループ別討論5

ポジション・ペーパ&感想、

24

5
t
hI
n
t
e
r
n
a
t
i
o
n
a
lS
o
f
t
w
a
r
eP
r
o
c
e
sWorkshop

6
2

ソフトウェア・プロセス ・ワーク ショップ参加者募集

63

会員状況

65

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

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

術の特徴は，他の工学諸分野の技術 K くらべて属人性がきわめて強い点、にあります.

ソフトウェア技

したがって，そうしたテクノロジー・トランス

ファの成否の鍵は，研究者や技術者抗既存の社会組織の壁を越えて，相互の交流を効果的に行うためのメカニズムが確立できるか否かにかかっています.

SEA は，ソフトウェア・ハウス，計算センタ，システム・ハウス，コンピュータ・メーカ， 一般ユーザ，大学，研究所など，さまざまな験場で働〈人々が， 技術的・人間的交流を行うための自由念く揚>である ζ とをを目指しています.
SEA の具体的な活動としては，特定のテーマに関する研究分科会 (S 1G) や地方支部の運営，月明j後関誌 (SEAMAIL)の発行，各種のセミナー，ワークショ y プ，シンポジウムなどのイベントの開他既存の学会や業界団体の活動への協力，また，さなざまな国際交流の促進等があげられます.

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

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

代表幹事:

岸田孝一

常任幹事:

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

焼事:

青島茂稲田博岡田正志落水浩一郎片山被昭川北秀夫杉田義明鈴木弘武田知久田中慎一郎長弁
剛一郎中園順三中野秀男西尾出野村敏次野村行憲針谷明深瀬弘恭藤本司郎村弁進盛田政敏

会計監掌:

辻淳二吉村成弘

常任委員長:

白井義美(技術研究)

久保宏志(企画総務)

藤野晃延(会誌編集)

杉田義明(セミナー・ワークショップ)分科会世話人環境分科会 (SIGENV) :田中慎一郎渡議雄一

管理分科会 (SIGMAN) : 相沢圭一川北秀夫芝原雄二野 h 下幸治
教育分科会 (SIGEDU) : :大浦洋一杉田義明中国順三
再利用分科会 (SIGREUSE) :青島茂阿倍正平村井進
ネ ッ トワーク分科会 (SIGNET) :青島茂野中哲
法的保護分科会 (SIGSPL) :能登末之CAI 分科会 (SIGCAI) :大木幹雄寺嶋裕一中谷多哉子中西昌武
ドキュメント分科会 (SIGDOC) :田中慎一郎野辺良一

支部世話人

関西支部:白井義美盛田政敏
横浜支部:熊谷章林香藤野晃延松下和隆
長野支部:小林貞幸佐藤千明細野広水

名古屋支部:岩田康鈴木智西村亨
九州支部:植村正伸小田七生藤本良子平尾一浩松本初美中島泰彦能見巧後藤芳美

SEAMAILi編集グループ俸閏孝一 佐原伸芝原雄二関崎邦夫田中慎一郎中村昭雄長弁修治成沢知子野辺良一
藤野晃延渡溢雄一

SEAMAIL Vo 1
. 3,

No. 9

昭和 6 3 年 1 2 月 1 日発行

編集人岸田孝一
発行人

ソフトウェア技術者協会 (S EA)
干 102

印刷所

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

サンピルト印刷株式会社
特価

藤和半蔵門コープピル 6 06

〒 1 62 東京都新宿区築地町 8 番地

1, 000 同(禁転車~)

SeamaUVol.3 , No.9

MessagefromE
d
i
t
o
r

編集部から

1.ふたたび，ワークショヲプ特集
編集長が変わっても ，相変わらず船便シンドロームから抜け出せず， 事務 局の中島小姐のストレス性胃炎の原因となっている

SEAMAIL です . なにせ.この夏から秋にかけて，イベントが立て続けにあり，編集ボラ

ンティアのほとんどがそれに巻き込まれているために，なかなか材料の整理がつきません.
何人かの在宅編 集員のご協力のおかげで，以前に行われ たセミナーやシ ンポジウムの記録が，少しずつ， 音

声磁気テープからディジタル磁気フロッピーに変換されてきていますが，最後の手直しとフォーマッティング
がいま一歩です.
そこで，この号は，一応の記録と参加者のポジション・ペーパ (Rewrite 版)がまとまった「夏のプログラ

ミング・ワークショッ プ J(第 6 回若手の会)の報告特集の形でまとめることにしました.これで 2 号つづけてワークショップ・レポートになってしまいましたが，どうか慈しからず.

2. 次号以降のとりあえずの予定

現在，この夏に行った環境実態調査アンケートの報告を，分析 WG のチーフ野村敏次さん (JIP) が取りまとめている最中です.多分年内には印刷にまで漕ぎ着けられるでしょう.また.

9 月末の教育ワークショップおよび十月初めの日中 シンポジウム・ツア ーの報告も ，やは り年末を目標に原稿 整理中です.これらの報 告特集
は，完成次第順次お手元にお届けします

それ以外の原稿としては

6 月のシンポジウムの招待講演者 w. Sc acchi 教授の原論文の日本語訳が，ケー

シーエスの平山さんの手で出来上がっています.また，前号にのせた信頼性シンポジウムのセッション・レポ
ートの続きや，いくつかのセミナー / チュ ー トリアル / フォーラムの記録も，あと一歩で完成の状態にあります

こうした原稿も.

1 冊分のボリュームにまとまり次第，迷わず印刷に回します .

といった具合いで，来春までには，船便症候郡から脱却し.中島さんの愁眉を開いてさしあげられるのではないか，と思うのですが，甘いかな?

3. とにかく，

野菜でも，お肉でも，魚でもいいから，お料理の材料を持って来て下さい.というのがキッチンからのシェ
フの悲痛な( ?)叫びです.できれば，そのまま 電子レンジに入れてテ ープルに出せるような.レトルト原稿(つまりワープロで A4 版にフォ ー マットしてあるもの)が，毎月何篇か欲しいな!

プログラマって，お酒を飲むとあんなにおしゃべりなんだから，月に 1 度くらい，ウイスキー片手にワープ
ロの前に座って見るのもいいんじゃない?とこれは.

‑
1‑

2 代目編集長の気取った嘆き節でした.

SeamaﾟVol.3 , No.9

C
a
l
lf
o
rPaper

第 6 回夏のフ。ログラミング・ワークショップ

ソフトウェア-エンジニアリング技法のケース・スタディーソフトウェア開発の「銀の弾丸」を求めて

一

参加者募集
主催:ソフトウェア技術者也会
後援祉}情報サービス産業也会

これまで 5 年間「若手の会 in 盛岡」として開催されてきたこのワークショップも，いまではすっかり定着し，業界各社からも，次世代のエースを鍛える絡好なトレーニングの「場 J として高く評価されています.
第 6 回目を迎える今年は，会場を八ヶ岳山麓の別荘村に移し，運営スタイルも「若手の会 J 0 B を中心とするケース・スタディ方式を採用して，より具体的な課題を全員参加のグループ討論を通じて徹底追求することにしました.今回の討論テーマとしては.ややもすれば名前だけが先行し現場への浸透が遅れている開発技法のいくつかを取り上げ ，それぞれの長所・短所を十分に比較検討しようと考えています.

具体的には:

・形式的仕様記述を用いたアプローチ.オブジェクト指向のアプローチ- エキスパート・システムによるアプローチ.CASE ツールを用いたアプローチ
・プロトタイビングによるアプローチなどを用いて現実的な例題にアタックし， F.Brooksの高名なエ ッセ イに述べられた「銀の弾丸 J(ソフトウ

ェアという魔物を倒す最終兵器)の可能性を探ろうというのが ， その狙いです.
多くの若手技術者方々の積極的な御参加をお待ちします.

開催要領
1.期日:

昭和 63 年 8 月 31 日(水)午後から 9 月 3 日(土)正午まで (3 泊 4 日)

2. 会場:

八ヶ岳高原・泉郷(山梨県北巨摩郡・ JR 中央本線小淵沢駅からパス 10 分)

3. 定員

35 名

4. 参加資格:

5. 費用:

年齢 30 歳未満.経験 2 年以上のソフトウェア技術者

伺，0∞円(立A 会員 ， JlSA 会員)，

80 ，αxl円(一般)

現地集合-現地解散とし，期間中の宿泊費 (3 食付き)および資料代を含みます.
6. スタヲフ:

実行委員長:

藤野晃延(富士ゼロックス情報システム)

プログラム委員長:

坂下秀(アステック)

プログラム委員:

岡芹晃(東芝エ ンジニアリング)
中川中(電子技術総合研究所)
山本一成 (KC S)

藤本良子(フリー)

渡辺雄一(電力計算センター)

招待講演者(予定柴山悦哉(東京工業大学)

7. 申込方法:

佐藤千明(長野県協同電算)

沢田寿美 (SRA)

松下和隆(三菱電気東部コンビュ ー タ)他

寺野隆雄(電力中央研究所)

裏面の参加申込用紙に必要事項を記入の上，昭和 63 年 7 月末日までに，郵便または FAX で，実行委員長宛お送り下さい.申込者多数の場合には ， プログラム委員会でポジション・ステートメントの内容を審査の上，参加者を選定させていただきますので，あらかじめ御了承ください‑2‑

ー口、 wh y~ーー:12:00:
・

..‑

第

l

註 13:00

1

八ヶ岳高原泉郷制(フロ ント前(水)β51 ・32・3242): 1 マ :00 ・

1
3
:
0
0

1
4
:
0
0

1
8:
00

・・

2
1
:
0
0

1:

受付

オリエン

チュートリアル 1

パネ}~

グル

l
I

案内

キーノート

{エキ スパ ート システムテーマ毎)(1 80)( 川存

t1

会場 テー γ1 :(30) I(
30)(電中研寺野氏)

MU

プログラム委員

ホール

第
2

9:
00

チュー

-ω・

(9木/日1)

トリアル 2，い(司東会イ工UhUム大凹，、Z際g罷際 h一柴t 山働国点内氏、，

ホール

目 1r3ー:0ー0ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー -11

1
1

I:

ホール

‑

l

3 I 9:00 ーーーーーーーーーーーー・晦ーーー帽ーーーーーーーーしーーーーーーーーーーーーーーーーーーーーーーーーーーー1ー5:00

i

グループ別討論9/2
トーーー------一一-----ー・ーーーーーーーーーー-ー・ーー(金) I l_____ 一一一一一一一一 .5ftJL号三一一一一一一一一一一一ー

9/3

f一一一一一ト Coffe-Break
成果発表 1

成果発表 2

解

散

中開発表

1
8
:
0
0

ホール
CoffeBr叫

居室

仰 の PM3:00
9/1 の AM10:00
9/3 の AM10:00 の 3 回

食事…朝3 回 (9/1-3) AM8:00(土)昼2 回 (9/1-2) PMO:OO

」ーー

ホール

グ九;;一C.7反1Fコ リの

夜2 回 (8/31 ， 9/2) P
M5:00

Z 。・@
∞g 自白出〈。戸帥T附
日懇親ベーテイlL- ーーーーーーーーーーー一ーー屋ー外ーーーoーrーー居ー室ーーーーーーーーーーーーーーー _.fE

第

日

18・00

ト一一一一一一グ一ル一ー一プ一別一討一論一一一一一 4
i

t
￨

)

•

SeamailVo1
.
3No.9

参加者名簿

実行委員

藤野晃延

プログラム委員

坂下秀

アステック

佐藤千明

長野協同電算テクニカル・スタップ

岡芹義範

東芝エンジニアリング

湾問寿美

SRA

松下和隆

三菱電気東部コンピュータ

渡辺雄一

電力計算センター

佐原伸

SRA

藤本良子

フリー・ランサー

中川中

SRA

山本一成

KCS

板倉重和l

呉電子計算センター

中沢賢光

日本電気ソフトウェア

山田良一

日本情報開発

井上文人

早稲田大学

伊藤達哉

早稲田大学

前野貴志

小松ソフトウェア開発

王生幸雄

小松ソフトウェア開発

香西哲也

ランド・コンピュータ

平尾一浩

ヒラタ・ソフトウェア・テクノロジ

中山聡

日本タイムシェア

立木勲

三井銀ソフトウェアサーピス

田中慎一郎

SRA

後藤浩

シスプラン

林好一

SRA

桜井麻里

SRA

西川典子

SRA

岡田正之

SRA

森博幸

目立ピジネス機器

ままだ健

ディーエム情報システム

嵯峨山亨

三菱電機セミコンダクいソフトウェア

望月好光

ユニテック

藤村洋

岩手電子計算センター

吉田慎哉

岩手電子計算センター

笠原幸夫

システム・プランニング

末次興之

システム・プランニング

秘メ IJ

招待講演

富士ゼロックス情報システム

顕

日本テクニカルシステム

中村伸博

三菱電機コントロール・ソフトウェア

内海保

三菱電機コントロール・ソフトウェア

方学分

静岡大学

深野寛子

日本情報開発

太田剛

静岡大学

寺野隆雄

電力中央研究所

柴山悦哉

東京工業大学‑4‑

GroupReport

S
e
a
m
a
i
lV01
.
3N0.9

グループ別討論
第 1 グループ太田剛

第 2 グループ板倉重利

第 3 グループ

山田良一

第 4 グループ

内海保

第 5 グループ岡田正之

第 6 グループ

嵯峨山亨

‑
5
‑

ーーーーー，圃ー骨ーーーーー

ーーーーーーーーーーーーーー

ーーーーーーーーーーーーーー

ー-ー-ーーーー--・-ーー

ー・ーーーーーーーーーーーー

ーーーーーーーーーーーーーー

6
9

13
16
20
2
1

仕様を用いれば、設計の段階でその正しさを確認できることになる。こうして正しい

第 1 グループ討論報告

ことを確認した仕織をもとに、自動生成するなり、人削手でコーディングするな

側ソフトウェア・リサ ーチ ・アソシ エイツ

中川!

巾

鮒?富士ゼ ロックス情報システム

滋野晃延

鮒日本情報開発深野寛子

静岡大学大学院電子科学研究科

太田剛

して、既存のプログラミング言語に滋とせばよい.

p

3
岡
市

上に述べた特長はあるも のの 、現在のところ形式的仕様 言 語の中で時間の観念を扱うこ

旬
。

.
円

とは困難であり、時間の制御を主としているシステム、例えば銀行のオンラインシステムのようなリアルタイムシステムを記述するととができない。との点は今後の研究課題であろう。

3. Q丘L2. [1]
1.並」迎』二第 6 回 .J:のプログラミング・ワークシ ョ ップは、ソフトウェアというモンスタ ーを倒すための銀の弾丸を探るというテーマのもと、 8 月 31 日から 4 日間、八ヶ岳高原泉郷に於いて開催された。

;fli q 第 1 グル ープでは、 銀の弾ljL の候補とし て形 式的仕様のアプロ ーチを とりあげた .
そして、代数的仕様記述法に基づいて設計開発された代数型 言 筒 OBJ2 を用い、具体的やな問題を OBJ2 で記述することにより、その有用性を後かめ実感し、銀の弾丸となり得るかどうかを検討した。

我々第 一 グループでは、民i立並』三でも述べたように、形式的 ftl竣 言 語として OBJ2 を用いることになっていたので、まず最初にグループリーダーの中川氏より、 OBJ2 についての 講義を受け た 。

OBJ2 は代数型の 言 語である。すなわち、 OBJ2 が持っている数学的背景想論は、代数である。

代数裂の 言 昔話で問題世界を記述 するには 、まず問題世界を構成している対象をその積類(ソート)によっていくつかの集合に分刻することから始める。次に、同じソートに属す
る複数 の対 象の聞 に 同等関係を定義することによって、記述したい問題世界に意味を与える.各ソ ート に属するすべての対象は、定対象 (c 0 n ぉ t a n t) に対して適当なオペ

2. 監孟血盆盛

形式的仕様とは、数学的理論を背景に持ち 、 シンタックスおよびセマンテイクスが iF. 確に定められた人 工言 訴を周いて仕様を書くものである。そのために、次に示すような特長を持つ。

① シンタックスもセマンティクスも決まって いる がゆえに、通常のプログラミング 言言語と同様に、この仕様はそのままの j診で解釈実行することができる.そのため、仕様の段階でシステ ムの動 作や効率の良さを確認することができる。

@数学的理論を背放に持つためにその正 当 性の証明ができる 。 現在のところ、仕織が正
しいかどうかは、問題領域に関する経験や知識を多く持っている専門家の総力に依存しており、その正しさはシステムが出来上がるまで確認ができない 。 しかし、形式的レーターを適用して得ることができる.例えば、自然数というソートに属する任意の対象
は、r1 を加えた次の自然数を備とする 』 後者関数というオペレ ー タ

を定数 O に対して何回か適用して得ることができる.

簡単な例として、自然数とその上のいくつかの関数を OBJ2 で記述したものを示 す.
自然数における定数(定数オペレーター)として O を定殺し、

r1 を 加えた次の 自然数を他とする J 後者関数と加算および乗算をオペレ ー ターとして定義する。次に、これらのオベレータ ー を用 いて 、自然数聞の同等関係を等式で与える。伊l えば、「ある自然数と定数

常g

O とを加算したものはもとの自然数に等しい J r ある自然数と定数 O との積は O に等しいJ 色等を等式で 書 き並八るこ とにな る。

<

手

COI・

2

=
。

ペ ージほどで あった。他のグ Jレ

s
o
r
tI
n
t
.
o
p

。

プではマシンを持ち込んで体験 学常 (? )していたところもあったようだが、我々のところでは処理系を持ち込んだわけではないので、正しい記
ー)

I
nt
.

述がなされているとは必ずしも 言 えない。しかし、この程度の 設 の記述で ー 巡りの動作を

o
ps
u
c

I
n
t‑)I
n
t
.

o
p̲+

l
n
tI
n
t‑)I
n
t
.

o
p̲
*

J
n
tI
nt‑)I
n
t.

書 き下すととができたとい う点 で、形式的な仕様 記述 の威力を感じた .手続き的 に 記述 した場合、との何倍ほどの 設 にな る であろうか 。 おそ らく 10 倍程度では済 まないに 追 いな

い 。処理系 があれば、この記述 (0 B J 2 で記述された 設計書 )を解釈 笑行 して動作在 確v
ar N, H I
nt
eq l
n
t

N+ 0=N
.

eq l
n
t

N+ s
u
c
(
M
)

eq I
n
t

N 本 o

eq I
n
t

N*s
uc(
M
)

の円。M
民m
国
帽噌ez

ob
jI
N
T
E
G
E
Ri
s

かめることができたはずであり.さらにその威力を 実感 できたであ ろうが 、 残念 ながら 今聞はできなかった 。

s
u
c
(
N +M
)
.

=O
.

5. 主L盛(N 本 M) + N.

jb 。

こうした課題を通して 、o B;I 2 で仕様(設計書)を書くことに関して我なが感じたととを以下にまとめる 。

-叫・・-戸惑 いの問題
以上、簡単に OBJ2 の紹介をしたが、 詳線 については 参考文献 その他にゆず るこ ととする 。

手続 き的な 記述 に慣れてい る者 にとっての 宣言 的 記述 をす る こと へ の戸惑いがあったが、これは純粋に 慣 れの問題であり、また背景理 諭 の教育の問題である 。 よ って、致 命的な欠点ではない 。

4. 設題

記述量の少なさ

さて、このような特徴を持つ OBJ2 を用いて 、実際 に問題を記述してみて、その有周性を確かめることが我身第 一グ ループの謙題であった.問題としては、

手続き的記述に比べて ß: tj・ 的記述をしたときの記述 主主 は少ない。とれは、宣 言 的記述をサポートする 言 務処理系の中に、各宣言の実行 I，!J{序の制御戦略が組み込まれているた① ビール製造過穫のプロセス・コントロール

め、その分だけ記述が少なくてすむからである 。と の 記 述 設 の少なさは、プログラミン② 簡単なプロダクション・システム

グ時間を減少させることにもなり、大きな利点であるといえる。

の 2 つが与えられ、 ①を深野 が、 ② を太田がそれぞれ担 当 した.

続き的な記述に慣れている者・ としては、はじめ 戸惑 いを感じた 。

ヵt 、慣 れるにしたがって、

記述量の少なさおよび簡明さを感じるようになった。

示すことができるということであり、設計者の知識や経験に依存している現在の設計方

課題を解決 した結巣としての OBJ2 プロ グラムは、最終日の成果発表でも述べたし、スペスの関係上ここには示さないが、結局のところ記述 訟と しては、

OBJ2 は、数学的理論に基づい て 設計・実現されたイ士機記述言語である。したがって 、記 述の正当性を証明するととができる.これは、システムを開発する前に正しさをB5 ノートに換算

して、 ① のプロセス・コントロールで 2 ページほど、 ② のプロダクション・システムで 4法と比較して大きな利点となる 。

-仕織の解釈・実行
OBJ2 で記述された仕様は、処理系によって解釈 ・実 行することができる。とれにωg国民}〈eF帥 Ze・@

- 正当性の問題

OBJ2 の記述訟は、手続き的ではなく宣 言 的に性質を 書き 並べる方法をとるので、手よって、仕様の段階でシステムの動作や効率等を確認することができる。この点は、あとれがソフトウェア開発の蔽も難しい点である。

の『。

る意味で、プロトタイピンクのアプローチをも含むことになるのではないか.

巨司=おj)---.IJ ζﾞ:I
今回のプログラミング ワークショップに参加するにあたって、実行委員のかたがたに号

6.

-プ ログラムの 自動生成
正当性を確かめ、動作を確認した形式的仕微からは、(シンタックスもセマンテイク

スも定まっているために)機械的作業によって、プログラムを自動生成することができ

種 4 の点でお世話になりました.紙上を借りて深謝いたします。

.

円る(はずである) .また、人Ifìl が手でコ ーデイン グするにしても、正しいことがわかっている仕様から生成されるプログラムに虫が 含まれることはないであろう 。 スペルミス
等は別にして、設計上の族りからくる!lt は根絶できるのではないか。

愛笠玄盤

[
1
] "始象データ型と o B J 2" , bit Vo 1. 20 , No.9 , Sep. 1988 , p
p
.
6
7
‑
8
0
.

起時間に関する!問題OBJ2 に限らず、形式的仕様記述言言語は、現在のところ時間の概念を取り込むまでにはいたっていない。したがって、時間に対して大きな制約を受けているリアルタイム
システムをとれによって記述することは、今のところできない。との点は大きな欠点であり、今後の研究が待たれる点である"-∞・以上の点を考慮して、塾生且~墜主主的盆盆皇LZ旦ニ乏丘二ーユ上9~よ主主主二(22.

一一ζ盆主主与鎧lD~色温主主:L.2ムと盆誼iι左L ただし、以下の点に注意する必要がある.

まず第一に、上でも述べたが、リアルタイムシステムを記述できるような形式的仕様記
述言語を開発することである.リアルタイムシステムの設計は、どれだけうまくタイミン
グを調整できるかにかかっており、熱練設計者の 3豊富な知識と経験に頼っていることが多

いため、これが開発できれば大きな意味がある.そのためには.時間の概念を総み込んだ理論を構築する必要があり、今後の研究誠題である。
そして第 二 に、このアプローチが成功したとしても、プログラマーが必要なくなるのでマル)な形に書き下さなくては、計算機で実行することはできない。形式的仕様のアプローチは、現在の設計者が行なっている設計のうち、実現レベルに近い作業による負荷を軽減するものではあっても、決して非形式的な問題を形式的なものに変換してくれるものではない.この点は人間の創造的活動に任せるしかなく、

、。戸一
Z世
e・@
∞ g 目色 -d

はなく、あくまでも 主 役は人間であるということである。非形式的(インフォーマル)な
現実世界の閃Iß!を形式的(フォ~Jレーーコア=

冒す命倫レオマーート

1.グループ活動の経線

進化型アプローチによるアプリケーション開発
一一ー一-4GL によるプロトタイピング一一一一

1 日目:

パネルディスカッション後にグループ編成された第 2 グループは 、

LINC

E という新しい言頼と進化型プロトタイピングというアプリケーション開発に(検)呉電子計算センター

板倉重利

興味を持つ 8 名で構成された.

自己紹介で各人の仕事環境を話した後、 LINcn の機能餓明 、今後の作業z市唱。
の円。回同》同多勝 2.

確偲を行い、入ヶ岳の一日を終えた .
メンバ (50音順敬称略)

作成システムは得怠先マス夕、仕入先マスタ他からなる在庫管理システムで

-@・

板倉重利

(棟)呉電子計算センター

桜井麻里(練)ソフトウェア・リサーチ・アソシェイツ

佐.千明(棟)長野悔同..

高山

日本ユニシス(橡)プログラムの入力を一部終え費量親会へと向かった.ほぼ予定通りの作業進捗で

立木目白(稼)三井銀ソフトウェア

ある.懲親会後もマニュアルを見ながら、夜遅くまでキーボードをたたくメン

草書苅顕

日本テクニカルシステム(椋)

パもいた.

信回.

(稼)ディーエム情報システム

望月普先{棟)ユニテック

2 日目:

ある .3健機を使って本格的にプログラミングを開始、初めて使う鎗末のため操作説明を受けながら瓢職普闘である.慣れるに従って、キータッチも軽くなり、

P. C.

3 日目:

午前中にプログラミングを終えた.午後は在庫管理の実演である . ディスプ
レイにデータ入力用、在庫問い合わせ周画面市t表示されると、メンバのほっとした表情が感じられた.

はじめに一通りの処理を終え LINcn (4GL) の実感を携えて中間報告へ踏んだ.

会場を仙台から λ ヶ~に移して、初めて行われる夏のプログラムワークショップ、全国から.加者が集まってくる.初事告加の人が多いせいか耳障.した顧が目立つ.受付を済ませると中間報告後、最終日の成果発表へ向けてのグループ討諭は、潤滑酒も手伝い

プログラム蚕員長の銭拶のあと、チュートリアル“エキスパートシステム入門"から予定通

活発な槍自民が展開され、発表周の原稿が完成したとき、窓から小鳥のさえずりりのスケジュールでワークショップはスター卜した.

が聞とえた.

PC 佐 Eーさんの会婦に実機まで持ち込んで来るという.U~ と、これまで使ったことのない傷械と言需を操作したいという欲望から、前述のメンバが集まり ~2 グル}プが誕生した.

4 日目:

いよいよグループ発表である.発表者二人は、.分、緊張気味である.当初

打合せとは多少異なった発表内容であったが、質疑応答も無事に終え、大役をグループ活動に入り、自己紹介するが、まだ、これから始まる未知への不安のためか表情果たした二人には、安待感と満足感が伺えた. 8 月 31 日に誕生した第 2 グルは硬い. PC 佐Eーさん、日本ユエシス高山さんによる LINcn の鋭明が進んで〈ると.ソープはグループ発表を終えて解散した.メンバはワークショップの成果を土産フト屋としての習性からか LINcn に対する興味も織し、質問も出始めグループ内の雰囲にそれぞれの職楊に戻った.

気もなどんできた.とうして、最終日の成果発表に向けてグループ前鎗はスタートした.

ωg自色}〈 eF帥 Z 。・@

パネルディスカッションにおける、

2‑2 プロトタイピングの怠義

4GL (LINCD) によるプロトタイピングを体感してのグループ討輸は、まず 4
G L (LINCD) の感想を述べ以下の内容でまとめた.

システム構築する上で、いかにユーザ・ニーズを取り込み.ユーザ・ライタに要求定量島が容易にできたらと、どのシステム・エンジニアも考えるだろう.

4GL (LINCD) に対する感想の 2EMM
岡市旬z。

2. グループ樹首のまとめ

品質向上を目指しても、品質不良の愚大の要因は 11lIt 仕織の検討段階にある.

(1)画面上に項目を置いていくだけでできてしまうのはすごい.
(2) 現状でやっていることはやっている.

こうした中で、プロトタイピング手法に期待が持たれる!

o(3) 手経にできてしまうことがデメリットになってしまう環境もありそうで疑問.
(4) システムが大規模になったとき耐えられるか疑問.

(
5)要求定‘のモデル化に対する解決が欲しかった.
(6) ユーザ、SE 、プログラマの定様、役割l 分担が変わってくるのではないか、SE がプログラマを兼ねなければならないかという不安を感じた.

今までのシステム開発は、本格的に動いてみないと、その評価があいまいである.

2‑1 4GL の定‘
-回。.

。

ニo
-鏑象度が.ぃ言顕である.
-非手続き型記述も可能である.
-データベースも扱っている.
そこで-対&!i型である.
-鋪末の有効利用を図っている.

実僚のプロトタイピングにより、体感し、よりコミュニケーシヨンを図り易くし、また、流動的なユーザ・ニーズを効率良〈シュミレーションする.

-エンド・ユーザが参加できる.

レポートの出力が容.
互庄工.ta 随.
司~表現E タ色王星ヲ'

再担E 竺主ifi!量 4金つ'プロトタイピングへの期待①使い捨てアプローチ:

システムの表面的な動きを検証②進化型アプローチ

システムの検征・拡張そして実システムへの進化

個。・@∞ g 自民同〈。戸一Z。

-プロトタイピングが容易である.

の円。回唱岡市旬。ュ

2‑3 プロトタイピング実現とその期待

2‑4 成長型プロトタイピングによる成長型システムの徳鎮

やりたくてできなかったのは?
シ

3GL (COBOL. FORTRAN. …… )では、アプローチしていくには、ス

工費t. 時聞が膨大で.プロトタイプしていくリスクが大き過ぎた.

‑
r

の

成
il!11

長

時間

・

4GL か

B

O

N
O

それが、

一

こんな夢みたいな仕掛けが今までにあったか.進化型プロトタイピングの実現

一

‑yd

o

ム

-M
同・

①早〈、簡単に動いてしまうものを作ってしまうということでユーザとのコミュニケーションが容易にできる.

開発←一一一一ー保守・メンテー一一一ー→②ユーザニーズの隻更を容易にでき.尚かつダイナミックにシステム全体に反映する.

の成長) 務協珍⑧工費t. 時間の程滅⑥刻々と変化する社会情"を容易にシステムに反映できる .

プロトタイプによる要件・ニーズの

応
対

早
事情

yl|

ク境

ナ代

イ時
ダの

へ動

の後

化穆
隻本

∞ g 国民}〈 eF帥 Z 。・@の環変化へのダイナミック・素早い対応

の旬a
。 -M
帽m
旬。吋酔

2‑5 4 G L (LINCU) の際題(1)パターン内臓のため柔軟性にかける.
(2) オープンアーキテクチャでない.

(3) DB 依存のため、利用方法が限定されている.
(4) 既存システムとのインタフェースがない.

(汎周でない)tJわりに

1J 2 グループは実機在使用してプログラムを作成しなげればならないこともあり、他グループにJtパ実磁的な 4事案が多かった.その分、目棟も明確になっており前‘も自然したものとなった.

今回のテーマになった“ 4GL は銀の現丸になるか"については、 4GL と成長型プロト-MM・

タイピングにより“銀の型車丸"に少し近付いたのではないかということで 、 グループ討.の結・ーとした.
3 泊 4 日で行われた夏のプログラムワークショップ.ハードなスケジュールでしたが 、A:後まで也力と頑頚りを忘れなかった第 2 グループのメンパの管織お鐙れさまでした.

一以上ー

ze・@
ωgE 園出〈。戸伺

の町内
z
Mm帽唱。
wg
同

第6回

エキスパートシステムについて!!

夏のプロ グラミング・ワーク

ンヨ

ツ

プ

第 3 グループ報告書

我々第 3 グループの面々は、初日 ( 8月 3 1 日)の、
アル 1(株) 日本情報開発
山田良一

チュートリ

寺野孝雄氏(電力中央研究所)の講義を拝聴し更に、グループリーダである山本一成氏(プログラム委員)の説明会にて、興味又は、好奇心を持った人たちが集まり
f エキスパートシステム j
について語り合う事になりました。

アーマ[エキス パートシステムは"銀の弾丸 "になり得るか]
I エキスパートシステム l について討論すると言いましても、グループ構成7名

グループ 7名中 4名は、『エキスパートシステムとはイ可??? J-M
帥・

雑誌等で、言葉は知ってはいても、いざ討論するぞと言われ1.

山本一成(ケーシーエス)ても、何を話して良いかわからないといった人が過半数を占

2
.

藤本良子

めており、

3
.

前野貴志(小松ソフトウエア開発)

テーマ選定が、4.

笠原幸夫(システムプランニング)(清里等一一清里のソフトクリームは美味しい)時には、気5.

末次真之(システムプランニング)

分を替えやっとグループ内のテーマが形をみせたのが、

6.

中沢賢光(日本電機ソフトウエア)

3 日目 (9/2 )の中開発表の直前でした。

7.

山田良 一 (日本情報開発)

この様な中でグループ討論を行う訳ですから、
なかなか想う様に進まず、時には場所を替え

1. I エキスパートシステムは銀の弾丸になり得るか勿? J

はじめに
今回、 3 日間にわたり行われた、プログラミング・ワークショップにおいて、我々第3 グループの、『 エキスパートシステムは"銀の弾丸"

2. r ソフトウエアの開発支援ツールとしてのに成り得るか J を テーマとした、デイスカッションの様子を報告書としてまとめました。

エキスパートシステム構築 lでありました 。

ωg目色}〈eF帥 ze・@

そこでまとまったのが、

まず、

なぜこの様な問題がほぼ毎日発生するかについて語り

前述した通り我々のグループの過半数が、 エキスパートシ

ステム一一一???であり、
カf 、合いま した 。

それでは実際に、構築し 実体験 した方

エキス パ ート システ ムとは何であるか多少なりとも理解の度合いが違うのではと 言 う事で、本テーマに決定致しま

出てきた 結果が簡単 に申しますと、

1.要求仕様が流動的である事(仕様変更等がランダムに発生する)

した 。

さて、

テーマが決定すると次は本題に対し討論を行う訳ですが、討論を行うに際し何に対し討論を行うかで、討論をおこない、

2. 物理(ハー ド的 )環境等がシステム毎に変わる為、

の吋。回
岡市旬。ユ
MM

これらの問題を解決(又は、問題発生の軽減)して行く為に、そこで持ち上がったのが、皆が共通でかかえている、

ソフトウエア開発上の共通の問題について語り合う事でした。

固定的な知識のみでは、要求をクリアする事が出来
ない事
-同島・

皆がかかえる共通の問題点とは大別して、3. 組織 及び 人的要因において プロジェクト毎(システム毎)に開発メンパーが、流動的であり、更にメ ン

1.見 積りノ f ーへの新 人等の参加によりプロ ジェクト リー ダ ーの心労に計り知れない物がある事

4. 工程 においては、前記致しましたそれぞれの条件が、

2. 納期

3 . 開発環境からみ合い当初予定していた 工程 がなかなかまもれが上げられました 。

Ze・@
切帽園田弘同e〈-一世

ない事が良くある事

項目に 含 まれる様な事であり、この様に我々第 3 グルー プ のそれらの要因に対し少しでも解決の糸口をみつけて上げ様とする目的で、目指したシステム

I 指摘 マン lが、は、

I 指摘マン l

これから世に羽ばたこうとした直前に時間切れとなり未完

成のまま、の円。居間》岡市剛志旦

等 その他様々な要因は上がりましたが、総合すると以上の 4

ソフトウエア開発史にその名を残す事は、 出来ませんでした。

であった訳です 。

でも、

f 八ヶ岳のワークショップ j に参加致しました、数十名の方々には、深く心に残っているものと信じて疑いません、

本システム I 指摘マン l は、問題の発生防止を主目的として、開発されるものであります 。

以上まとまりに欠ける点が、多々あると思いますが、

これを

胴・
-M

もって第 3 グルー プ のレ ポ ートと致します 。

そろそろまとめに入りますが、我々第 3 グループが構築しょうとした I 指摘マン j は、エキス パ ート シ ステムの推論機能を用いる事により過去に体験したあやまちを知識 ベ ースとし、それを基に、

これから開発しようとするプロジェクトの各条件

をイ ンプッ トし、推論し、結果としてソフトウエアの開発における問題となるであろう 点 を 事 前に指摘し対応をうながす為のものであります 。
切市曲目弘同〈e--u。
z・@"オブジェクト指向"による銀の弾丸探し
三菱電機コトロールソフトウェア(株)内海

保

数種の DB にアクセスするプログラムを複数製作したが 、 tIt計が個別に行なわれたために、 DBへのアクセス方法がプログラムにより異なっている. DB の形懸が変更されたときの既存プログラムのメンテナンスが大変である .

1. 現在抱える問題と解決策

この問題に対しては、まずデータ抽象の概念に基づきプログラムを再構築すべきであ

現在、各グループ員がどのような問題を抱えているのかを S/ W開発環袋、対象分野と共にまとめたものが表 1 .

1.である.

表1 .

N 悶

os I言語(2)UNIX上のドキュメント管理が煩雑

!対象

問題点

-回。.

I
COBOL I; ・プログラム・データ ・ 多 : 1 の

I
"
‑
‑
U
'!

!
‑
̲
.
.
̲
‑
‑!

!
. デ-タの変更に対する応答

i 矛盾の発生!11frr引
frr1;: 1\:問1r店i7:1a; l(A:;1:E: ij区
堅号引
j:zιえJiLιJil
……
U…'山~

1.
.

藤 I HIUC ! 3
村 1 .~ぞリイ ! ~~~;7

II
.
.
.
;
I'}‑ﾄ' l. ...~u.

I
HITAC I
VOSl

各DB を操作する手続きを明確に定援し 、 各プログラムは定おした DB操作手続きによって1. 開発環境 ・ 対象分野と抱える問題点

上 1;:∞S4 j MVXAOCOBO凶 j 事務

尾山b

るとの結論であった.具体的には、使用する言語がCOBOLであるとのことであるから 、のみDB を操作するようにするということである.

弁 I ACOS.
6j.
.
.̲.•• •

平 I ~.~::'S

の円。
aMM
岡M
崎回吉町骨

(1 )数種DB にアクセスする複数プログラムのメンテナス位の向上(飾 4 グループ肘槍まとめ}

I

<

ド

i
ICOBOL

現在UNIX上にて作成したドキュメントを管理しているが、この管理が煩雑である.
例え 1;( 、管理しているドキュメントを出力しようとした場合、出力コマンド
がドキュメント毎に異なっており 、 素人では出力できない.

これについては、 UNJX の既存コマンドにて問題解決できる.

; ロボット制御 ;・ ロボ y トの進化への対応! ライン制御j(3)ドキュメント作成 ・ 管理の効率化

;

市町村業務

I
COBOL I 盲j

; 先進技術からの遅れに対する
危纏感

ドキュメントを如何に効率良〈作成し、管理するにはどうすれば良いのか.

!・ システム分析 、 設計の標準化

とにかく計算織にて作成・管理を行いたいのだがという声に対して、次の二つの環境が示された.
この表に示す通り各自の抱える問題が様々であったため 、 まずは 、 オブジェクト指向の概念が問題解決に役立つかどうかを考えながら、各問題の解決策の検討を行なった.以下 、各問題毎にその結果をまとめておく.

日 。・@
ωgEm凶〈。戸一Z

ドキュメントの問題は、レベルの遣いはあれどもグループ員共通の問題であった.

どころに、深刻な問題を解決することができた.つまり、情報交換のためのネットワーク
が大いに役立つというわけである.

ここでいうネットワークは、次の二つのネットワーク両方を指す.

H八H(1) コンビュータネットワーク.Macinloshの環演
SハN
H八H

mail . BBS を使用して必要な情報を得ることができるし、他の人のアドバイスを受ける

EgBook.EgWord ,M acDraw .... .
Ic.

岡国市剛志吋骨の円。M回がある.このような場合には、前者は後者よりアドバイスしてもらうことにより、たちど

roffの環境

ことができる.

M
a
c
i
n
l
o
s
h
(2)人とのネットワーク

大量の、あるいは 、 同じ書式のドキュメントを何回も作成する場合には 、 S/Wエンジ

情報を交換し合ったり、アドバイスを受けたりして、普段からいろいろな人と話すことにより、視野を広くしておける.

ニアとしては、 roffの環境のほうが便利である.

次に情報だけを得られたとしても、物理的な問題{例え I! 、問題解決に必要なWSがない) ， により問題を解決することができない場合がある.このような渇合には、当然物理的な問題を解決しなければならないが 、 この時に問題になるのは以下のことである.

2. 「鉄の号車丸』探し-同叫・

各自の抱える問題の解決策を検討した結果 、 オブジェクト指向を用いた効果的な解決策の存在する問題はひとつもなかった.この原因としては 、 次の二つが挙げられる.

(1)政策的な問題

提携関係がどうのこうのといった問題や、構築したい環境が決定された環境楊策方針に合わないといった問題.

(1)問題領減が 、 もともとオブジェクト指向を適用しなくても解決できる領域であった.
(2)金銭的な問題

例)ドキュメンテーションの問題.

この場合、本当に余裕がない場合に限る.単に予算が降りないのは 、 (1) に含める.

(2)オブジェクト指向に対する参加者の理解不足で、解決策に適用しきれない.

システム分析 ・ 設計の標態化という問題に対しては、適用可能な気はするが 、 どのよ
うに適用していけばよいのかわからない.

マネージャーは、この他にも重要なキーとなる.何か新しいことをやるには 、 時間がか

ここで、我々は (1)のような問題領域に対しては、現時点での知識・技術レベルにて実施
できる対策がいくつもあることを再確認した.それらの対策を実施することにより、 S/W

しに熱中する.

かるし、必ずしも成功するとは限らない(最善はもちろん尽くすが. ). こんなときに 、マネージャーの理解がなければ 、 思う存分に極めていくことはできない .

ーエンジニアとして必要な「鉄の弾丸』をもう一度列挙すると、次の二つである .

「鉄の弾丸 」 探((2)の問題については、 3 . で触れる . )(1)情報交換のためのネットワーク寸
ト良い環境(2)理解あるマネージャー

2.1 目指す「鉄の弾丸 J
グループ員を取り巻く環境(表1. 1 . 参照)の遣いから 、 あるところでは解決の糸口さえ見つからないないような問題であっても 、 別のところでは解決潰みの問題であること」

F制 Z 。・@∞市回目m出 d、。

の生産性を少しでも高める事ができるであろうということから、それらを「鉄の弼丸 J と称することとした.以後、しばらくは「オブジェクト指向 」 からはなれ、

問題 (2) は仕方ないにしても 、 問題 (1) を解決するためのキーとなるのがマネージャ(権力者)である.マネージャーの同意がなければ 、 解決することはできない.

の 2E-M岡市5岡1

3. オブジェクト指向

オブジェクト指向の話題に戻り、オブ ジ ェクト指向とはどのようなものであり、どのよ
うな分野に応用できるかについて話合った結果をまとめる .

。一

3.
1 オブジェクト指向適用の試み
グループ員からロポ ッ ト制御プログラムの製作にオブジェクト指向を適用しようとしているとの提示があった.この話題は 、 第一日目に 討 論したものであり、 2 章の「鉄 の強丸 J 探しと前後するものである.
図 3.

2 制御プログラム部のモデル化(1)適用対象のロボット制御プログラム

この図のオブジェクトに対するクラスを設定することにより、制御パラメータが適用しようとしているのは、 4 舶のアームロポットの制御プログラムであり 、 このプログラムは、図 3 .

1 で示される構造をしている .

少し違っているような場合に迅速に対応できる.例えば、紬計算のクラスでは、軸計算の手続きをメソッドとし、制御パラメータをそのクラスのインスタンスのデータとすれば良いであろう.

また 、 この部分にオブジェクト指向を適用すれば、ロポットの形態が異なっても-同∞・(例えば 、 軸が 6 舶になっても)、クラス閣の継承関係を利用することにより迅速Eに対応できると思われる .

…

3.2 オブジェクト鎗向に対する疑問
オブジェクト指向の適用を考えたが 、 オブジェクト指向そのものがよくわからないという意見があり、オブジェクト指向の体験学習と言うことで、 HyperTa1kによるプログラ
図3 .

1 ロポ ッ ト制御プログラムの構造

ミング実習を行なった . HyperTa1kは、 Macintoshで動くオブジェクト指向言語である .
それと合わせて 、 オブジェクト指向に対する疑問点を浅いだし 、 その解答を PCの佐原氏に行なってもらった.

ロポ ッ ト制御プログラムは、大きく分けて、実際にロボットの動きを制御する制御

以下、オブジェクト指向に対する疑問点とその解答を簡単にまとめる.

な部分の二つに分けられる .

( 1)オブジェクト指向の適用が有効な分野は?

また、各部分は機能のかたまりにて分割されている .

同じようなアプリケーションを何度も開発する分野 . このような分野では 、 プログ(2)オブジェクト指向の適用の可能性

制御プログラム部分にオブジェクト指向の適用を考えると 、 この部分は次のようにモデル化できる.

ラムジェネレータの適用も有効であるが 、 メンテナンスを考えたとき 、 オブジェクト指向では 、 個々のプログラムでなく一つの枠(クラス)を手直しすればよいという点
でオブジェクト指向の方が勝っている.

∞ gE 包-d、。
F制 Z 。・
eプログラム部分と、その部分をデバッグ ・ 試験したり、メンテナンスするときに必要

プログラミング言語によっては、オブジェクト指向を実現するようなプログラム作法が存在する.例えば、 c++はCのプリプロセッサであるので、 Cでオブジェクト指向を実現するプログラムを作成することができる.

の吋。回匂岡市旬。旦(2)オブジェクト指向型言語が利用できない環境のときにはどうするのか?

4. 今回のケーススタディで得たもの.後に今回のケーススタディでの結論と成果をまとめる.
(1)人と話すだけで解決する問題もある.そのためには、情報交換のためのチャネルを持たなければならない.
{コンビュータネットワーク、友達の絵、 SEA)

-He・(2)新しい銭術により、 S/W の生産性を向上させられる.そのためには、新技術の試使用ができる環境でなければならない.

(キーパーソンの抱き込み、マネージャやユーザの IU盤改革、密かなE隆積を積み~ねての説得)(3) オブジェクト指向がどのようなものか、うっすらとではあるが理解できた.今回、受けた刺激を減衰させることなく、今後に生かしたい.

第 4 グループ

上尾村海
弁株平藤森内メンバー

佐原

伸 (SRA)文人(早稲田大学事務システムセンター)
好一 (SRA)一治(ヒラタ・ソフトウェア ・ テクノロジー(稼) )洋( (株)岩手電子計算センター)
博望書( (稼)目立ビジネス織器)
保(三菱電機コントロールソフトウェア(株) )∞幅削岡田弘同〈
ω己
z・
eb

pc

私途のグループは、今回のテーマである、 ソ フトウェ 7 開発の「銀の弼丸Jを求めて、オブジェクト指向+ α によるアプローチを行いグループ討鎗を行いました。
まずは、各自がどうしてこのグループを選んだのかと、今の自分の仕事で抱えている問題は何かということを発表し、その問題点を解決する為にはどうすればいいのかをみんなで考えてみました。
王生さんは、ソフトウェ 7 の利用者が、まったくの素人の為に、間違 っ た
オベレーションを行ってしまった時のリカ パ リー担盟がとても多く、気を使っていると云っておられました。私は、いつも感じている、ユ ーザとの対応の問題を提鎗しました。
各自の問題点の討論が白書み、私途のグループでは、ワープ ロ の設計をしてみることになりました。ワープロ設計の目的としては、今まで自分たちがさて、.後に手1i童カ雫サ論 と 3署員の方々のお話を伺って感じた事は、
田中さん、
・ 予想必L上に時間がかかって細かい話まで獲理できなかった。
.文章モデルを考えずに始めたのは良くなかった。

王生さん、・発想の違いを感じた。
・ 自分の考えてものは、絶対動かないというよりも基本的に作れるのか否か
疑問を感じた。
「機骨凶句に分割する 」 という事が、雛しいということ地哨! っ た。

私、・型にはまった考え方ではなく、柔軟な考え方を持たなくてはいけない
事を実感しました。

の『。ロ喝岡市剛志吋骨

委臥町

船柿

山崎帥

(郎

げげ向

備…

秀一時一 軸 砕 政 政 問

重喜加者

肝畑珪一昨一剛一附…

羽.******....毒事専念寺'*'--ー』・ーーー-~ーー合合合岳会**喝阻・・・・・・・・B・・・噂-・守争φ..守→【-司-グループ討論
くオブ ジ ェクト指向 + a >ということでした。

行ってきた方法をもって作業を割り振り、その割り振り方に間短はないのか
なぜその織な設計方法をと勺ているのかをメン パー聞で討論してみようというものでした。さらに、プログラム蚕員の方々が考えてみたオブジェクト指向的-N0・

アプローチによる設計との比較を行い、メ ン パー聞の討論で発生した問題点が解消されるかを考えてみようというものです。
まず各自が、よく使うワープロ等を頭に浮かべて、ワープ ロ の設計を始めました。しかし、これが普段使っているワ ー プロでも、いざ設計するとなると時聞が短かったせいもありますが、なかなかみんな苦労していたようでした。各自の槌十がとりあえず一段落したところで、 3 人の設計を 1 つにまとめることになり、各自の設針案を順番に説明し、わからない所とかを質問して 3 人により統一した投Z村寵を作成してみました。
この段階に入り、各自の想い浮かべたワープロのイメ ー ジが既に違う事や舘十による糊掛け等も既に違うことがわかりました。
さて 3 人により統一された設針案ができた所で、プログラム委員の方々が考えたオブジェク ト 指向的アプローチによるワ ー プロ設計との比較検討を行いました。私逮が考えた設計の特色は、機能分けによりアプローチであ っ たということで、まだまだ、細部まで考えていく段備で多くの矛盾を含んでいるということでした。

した。

~員の方々が、設計をやってみて、感じたと言っておられたことは、文書の編集が自然にできる、自由度が高いのでいろいろな発想ができる、シュミ
レートがしやすい等の利点をあげられていました。また、欠点としては、実現が重量しい、抽象度が高い等をあげられていました。

mg目色}〈 eF一個
ze・@

プ ロ グラム委員の方々の投針は、私達が考えたものとはま った く違い、
ワープ ロを作成するという考え方からの 7 ブローチではなく、文書作成をうまく行うにはどうしたらよいかという 7 プローチの仕方でした。
プログラム餐員の方々は、まず、文書モデルを考えて、実際の文書作成にあてはめて必要な機能が実現できるか確かめるという手順で進められていま

香西

後目車
中林
中山

一哉也陽子事故
雌遺曾滞情鴫典掌慎亨m遁伊厳

三夜明E 楓セミコンダタタソフトウエア練式会社嵯峨山,

ヨーディ卓}ター

グループ 9-'-

西川

方
吉田

3.
2.
2

データフロー図の作成

lIl ~J 匹、概略データフロー図(レベル 0 図 2) を作成した. t.c.で位、図書館 システ ムを中
心 K 窓口および図・管理者との問 K 発生するデータの ìlll~ を杷掴する1:.1:忙した.
~ICI干納在データフロー図(レベル 1:図 3) を作成した.す在わち、図 2 で library 8y叫刷n とした郁分の鮮側在データフロー図を作成した.データフロー図 K よる仕様股附では、 E のよう
K 、まず概略のデータフロー図を作成する E とでシステム全体仕傑の見通しを立て、順次各プ
ロセスの鮮側データフロー図を作成してい< .

StP を用いると、レベル 1 のデータフロー図を作成する際、レベル O で作成したデータフの EEMM
岡市岡呂町骨第 6 グノレーフ官サ輪レポート
作成

ローと矛盾が生じれば、 StP からその旨の嘗告が宛せられるので、修正をかける E と K 止る.
E れにより、初め K 縫えた図書館 システ ムの慨略イメージ(レベル O のデータフロー図}と矛

盾のない鮮網仕健股耐を符う E とができる.

鑓由里山

1

はじめに

当グループでは、 "CASE ツール，オプジ"'?ト指向 K ついて考える"止いうテーマで 11 簡を
お E 在った.

2 討論の概要-MM・

近年の Y フトウェ 7 開発手法 K 関する眼目白怯、従来のよう IC :I フトウェアの肝価やドキ a メ

シ ト墜仰といったソフトウェア開発の下流工程だ"で在〈、仕傑股It lt よぴ要求分初等 ソフ ト
ウェア開発の上流工程 K 対しても行われるよう K 在ってきている.

11
1
2 i既唖ち .r- ~ 7 口一回

特 K 、 CASE(Comput町 Aid.d S
o
f
t
w
a
r
.Engin..ring) ツーんを利用した仕槻殴針金よぴオ
ブジェタト指向の概念を取り入れた仕様股針は近年量も注目を集めている分野であり、今回の~，帯号:t::'ワークシ・ップでも公園テーマとして取り上げられている.しかし、 CASE ツール.オブ ジ ェ
クト指向とも開発現鋤でほまだまだ馴lIlOみの剤いものであり、それぞれの有効性は未知数である.

そ E で当グループでほ、下配の 2 点について肘目白および実習を行い、 CASE ツ ー ルおよびオl‑v
1ノ J/も奈川ト
督促')スト

4れ:しプジヱタト指向が :1 7 トウ"， 7 開売の"銀の殉丸・'I:~るかどうか倹制した.

(
1).CASE ツール StP を用いた図書館 システ ムの仕様 rw(2)

オブジェクト指向 K よる図書館システムの仕傑股附

以下 K 活動の鮮細について報告する.

~

CASE"J ーんの 1 つである StP(SoCtwar. t
h
r
o
u
g
hPicture) を机上で使用 L 、 CASE ";Jールの有効性を傑ってみた.鰻初 IC StP を使用した経験のある方氏 IC StPIC ついて概脱していた
だき、続いて方氏の指鴻のもとに(人間 StP) 図書館 システ ムの仕織I'W を行ってみた.

歳、怠 1削目、
国 3 規制守 二 77 ロー I~ωg 目色同〈 evuz。・@

3 StP によるシステム仕様設計

の g 回同v岡市剛志ユ

3̲
2̲
3

E-R 図の作成

デ ー タフロー図では、データ柵過の IF細を捉えきれ在いと E ろがある.そのため、 StP では、
デ -!J フロー図以外 K データ E- R 図主たはデータ柵過図を舵述し、データ構造 K 矛膚が生じていないかどうかをチ z ックする懐陥を持っている.

そ E で図書館システム K 闘する E・R 図を作成した.図 4 はその一例である.1:1:ろで、図 4の例 K おいて、貸出年月目，返却予定日.返却日，借り手 K ついてはその本が貸し出しさ札る
たび K 繰り返し記録が追加されるものである。しかし、 E のよう在鰻り返し処理 K 対す晶表現
方法を E- R 図は持ってい在いI:I: IC 気がついた.
そ E で 、デ ータ柵造図 (Data Struc\ ure) を作成する E と忙した.作成例を図 5 . 図 6 1<:示す.

以上のよう在過程で StP 1<:よる図書館システムの仕傑霞Itを行った.レベル O のデータフロー図を配述する限 K 多少の戸感いがあったものの、案外順調 ICrut を行えたものと思 っ て
ν、る.

l
A
)1t-:!，，-fオι
国6(B) 噴 B\ ~坦

qdLI栴に問ヲ~ -'Y---1 格企図-MM・

4 オブジェクト指向によるアプローチ|現 4

2 日自の閥横で " オプジヱエクト指向 '・ についてうかがったのを懐会 K 、問じ図書館 シ ステム

E-RIヨをオプジヱタト指向の考え方を用いて段附する E とを獄みた.

4̲1 オプジェクトの抽出(その 1)
まず、 StP で考損したデータフローモデんを適用する E とを考えた.廃棄 H スト . 督促リス
ト，検索表示当事の"物"に嫡目 L 、 E れらをオプジヱクトとして抽出する E とを献みたが 、 オプ

ジ ヱク'の階層 I構造をうま〈表現しきれなかった.原因を考えた結果、オプ ジ ェクトの持つアトリぜ~ートについて金〈考慮せず、データフローのみ K 泊目していたため、仕傑の表現ができ在〈在ってしまっていた E とに気がついた.つまり、オブ ジ ェクトの包合するデ - !J セ ッ ト
そ E で、再度オプ ジ z タトの仙出を符うととからやり直し始めた.

4̲
2

オプジェクトの抽出(その 2)

l司 5

メミ I ~ 関するす L ヴ桶 ltlヨジ ェクトを シ ステム仕傑股耐の中心 K 纏えればオブジェクトの階層 1構造がきれいに表現できるのではないかと考えたわげである.

しかし、やはりオプ ジ ェタ与の階層情造をうま〈夜現しきれてい在いようで、延々と眼目曲が続りられたが、決定的在情造図は得られなかった.

-

今度位 、 "本 " IC 嫡回し、本を中心 K 顧客と管理者との相関関係を捉えようと考えた.図硲館
シ ステムでは本 K 関する関するデータを中心 K システムの運用が在される。従って、"本 " オブ

ωSEa-〈。戸ωze ・@についての吟味が不十分であったのである.

佐原氏より"ライプヲ 97'" をオプジ z クルの中K 本やヲイプラ 97 '" といったオブジェクトが持つデータセットを考えているが、 1 つのオプ
ジ z クトとしてまとまりのあ るデ ータセット K 絞り切れてい在かったのでは、と思う。共通情

7 のよう在階層榊過を考えてみた.

報は何か、他のオブジェクトから完全 K 隠ベいされる情報は何か、というととに対する時味がしかし、結局すっきりした構造 K 宣とめるととがで曹ず時間切れと在ってしまった.

不足していたととは否め 在い 。

5 まとめ
今回のワ ー クシ，ップでは、 CASE ツーんの使用を体験し、オプ ジ ェクト指向的アプローチを獄みたという点で有意穫であったと思う.ただし、程度の差 E モあれ各メ y バーは次のようの『。ロ喝岡市剛志ユ

c:c:で、首l4 グループのヨーディヰータ

心 K すえてみてはどうか"とのアドバイスを受け、ヲイプヲ 97'" オブジェク F を場入 L 、図在ことを考えていたのでは在いかと恩われる.

(
1).CASE ツーんを利用すれば 、データフロー図等の線々企図が CRT 上 ICf~述できるため、図の変更が大変容易である. t の点では殴針の効率化が図れるであろう.ただし、デ一
声 7 ロー図等を情策する E とは、人間が考察すべき E とであり、 シ ステムに最適在仕傑
敵Z十を行うにはその開発者の能力によると E ろが大きいのでは在いか。
(2) . オブジェクト指向的アプローチを符う K 位、従来のよう IC I&うデータの相関関係 K 滞日するのでは在〈、むしろ各データとそれを処理するプロセスといった捉え方をする E とが必要と在るようだが、 E れが在か在か隠しい.やはり 、開発者 の能力 K よると E ろが大きいのでは在いか.

-M帥・つまるととろ、"銀の弾丸"があるのかどうかわから在い、というのが現状であろう.

図 7 オプジヱクト摘出例

4.
3 討愉内容の反省
今回のオブジェクト指1句 K よる rw がなぜうまくいか在っかたのだろうか.その原因の l っとして"オプジ%?ト"の提え方が良〈在かったという点があると恩われる.

私たち位、オプジェクトを単 IC 1 つのデ ータセットと手続きとして捉えてしまっていたのではないだろうか.つまり、オブジェク'とは(1) . 自分の持つ内郁情報が、腕み出 L. 変更の対象 K 在る

(2)

自分自身主主怯他のオプジ%クト K メッセージを送る(何らかの作用を行う}

ものであるという概念をいま一つのみとめてい在かったからではないだろうか.従って、た〈さんの"物"を抽出したものの、個々のデータセットの取彼いにぽかり注意が払われてしまっ

ように配録すれば良いのか、といった具合いである.その結果、各オプジ z クトの関係が混乱してしまったのでは在いだろうか.

また、データセットのクラス化をうま〈行えてい在かったととも原因と考えられる.磁かaていたのである.例えば、本の名川をどのよう K 処廻すれば良いのか、とか貸出 Lf~録をどのωg 目弘同 〈e-一-個
ze・@(3) . メッセージの送り主にあるオブジェク b を応答として返す

S
e
a
m
a
i
lVoUNo.9

ポジション・ベーパ&感想、

ポジション・ペーパ&感想、

八ヶ岳夏のプログラミング・ワークショッブ

津田寿美ーーーー--ーーーー

25

ワークショッフ.の印象

渡辺雄一

ーーーーーーーー・・ー

26

ソフトウェア工学は役に立たないか?

佐原伸

ー・ーーーーーーーーー

28

ポジショシ・ペーパ

藤本良子

ーーーー 圃 ーーーーー

30

八ヶ岳ワークショップにて山本一成

ーーーーーーーー--

30

夏のプログラムワークショップに参加して板倉重利，ーーー ・・ーーー ー ー

32

分かりやすいソフトウェア

中沢賢光-・ーーーーーーーーー

33

夏のプログラムワークショ ッ フ

山田良一

ーーーーーーーーーー

34

人を中心に

井上文人

ーーーーーーーーー ・・

35

銀の弾丸とは伊藤達哉

ーーー 骨 ・ーー---

36

問題設定の視角

立木勲

ーーーーーーーーーー

37

香西哲也

ー----ーーーーー

38

ソフトウェア・エンジニアリング技法のケース・スタディ

平尾一浩

ーーーーーーーーーー

40

つれずれなるままに中山聡

ーー ・ーーーーーーーー

42

若手最後の年に若手の会に参加して

田中慎一郎

ーーーーーーー圃ーー

44

ポジショシペーパー

岡田正之

ーーーーーーーーーー

45

ワークショップ参加の後 K 思うとと

林好ーーーーーーーーーーー

46

ワークショップに参加して

森博幸

ーーーー ー ー，ーーー

47

異文化体験

桜井麻里

ーーーーーーーーーー

48

ソフトウェア開発プロセスの探求

嵯峨山亨ーーーーーーーーーー

50

夏のプログラミシグ・ワークショップを終えて望月

好光ーーーーーーーーーー

51

要求仕様定義からの自動コーデイングを求めて

藤村洋

ー ・・ーーーー ー ーーー

52

ワークショップに参加してみて

吉田慎哉

ーーーーーーーーーー

54

夏のプログラミングワークショップに参加して末吉真之

ーーーーーーーーーー

55

ホ・ジショシベーパ

中村伸博

ーーーーーーーーー，

56

形式仕様の将来

太田剛

ーーーーーーーー ー ー

57

銀の弾丸探しから得た鉄の弾丸銀メッキの弾丸

内海保ー ーー ー ーーーーーー

58

夏のプログラミングワークショップに参加して

深野寛子

ソフトウェア開発における生産性の向上
及び品質の改善について

‑
2
4
‑

ー

..___4・ーーーー

60

4.L プログラマの使う 富豪するモデル化手法平方法槍がなんであるにせよ。アログラ

多〈のプログラマは.システムやプログラムを眠計すると事に.表現形態として絵とテキト丹両方を使勺て(他にも

とです

SRA

あるのかもしれませんが L いろいろなモデルをつくります .

スとなりうる，プロダラマプルな環境を提供することです

量終的には ，こ れらの鳳t化の結果を .あるプ ログラム 冒語

C国母戸国l Progr岨皿ing 町stem'ι 革本軍費として自{複散の場合もあると思いますが}に変挽しなければなりま

己低強的であり.どんどん問題傾威内『雷語』を n り入れてせん . さらに，開発の造中では.プログラムテキストとそ

いくものとも宥えられます

L ワークショヲア町テーマ

弘のグループでは.

.C四隅伊国1 Proara血血血r とい う

ネタを出発点にして ， プログラミング雷樋 ， パラダイム.環

これらは白生度道具と利用健衛の進歩.~くの新しい情"が.

.'"問わず浪遣するようになったことによる相乗効果

による歯車分が多いというのが.真相であると思います .

境について..加者の方々に考えてもらいたいと思います .
今回のワークショヲプのメインテーマは.いろいろなパラ

ダイムを飼いて例圃を解~ . それをもとにして . 具体的に検討しようというものです

マが制勺た康志モデルを，直績に掻うことを可能とするこ湾図書賓

れらに対応する観念的なモデル町表現との閣を.行勺たりきりする必要があります多〈的問周がここで発生するこι ワータ シ，.， 7 では

それでは . このような奪え方を実際にサポートするシスとは，よく知られたことです .
1 優れた冨置 と聞売寝境が畳"量要
最近は ， 簡単な手持ちのパタ ー ンでこなすことのできる

また新たなモデル化手法や方法輸を実験するベー

テムは，どのようなものになるでしょうか他のプログラ

4.2. B吋ond 由e Proara皿皿凪，LoqI岨酔

これは，これまでの r 若手の企る仕事は.かなり少なくなっているのではないでしょうか .

このため.できるだけ問周傾幡圭自然に表現できる拍車

ミング・パラダイムキ按法は.どのように位置付けられるのでしょうかひそかに隠れたベースとするパラダイムがあ

ワークショッアJ が。ともすると，焦点がはっきりせず.拍

飼大規..複纏な組込h形システムという最近司傾向もあ度の高いレベルでプログラミングできないものかと . 努力

るのではないでしょうか . ワークショ .， プで考えてもらい

車的で.直績には仕事に役立たない掻拾に終わることがりますが，比較的小さなシステムでも，今までの経験や技法されてきたわけです。より高値なプログラミング言語.新

たいのはこれらのことです

あったのではないか.という反省もい〈ぶんか含めてあるでは.iI:指対処できないものが多くなってきています.

ように思えますしいパラダイム.統合化されたプログラミング環境.自動 7

もちろん反対意見がだされたり.異な った考え方がでてプログラマの仕事をーロでいえば対象とする問聞傾幡

ログラミ ング帯 . 大枠では目指すところあまり変わらないくるとしたら，若手のワークショァアとしてこれ以上の喜びはありません

町モデルを正確に補償し . これを計算楓の世界に実現する.

のではないかと思います.しかし.それにしても量終的に拍車的世テーマにな勺てしまいがちで.いささか気がひけということです

は.特定のテキストベースの冨随で表現しなければなりまるのですが.

思われますが.一般的にいって . 今までの延長上にある枠組

そ うしたなかにあうて . 弘のグループではややもすると

1 グループくらいは勘弁してください

これは今後もあまり変わることはないとせん

これはいやだ，という免懇です-M馴・

きて.このネタ撮りを.かなり鐘にスケッチすると.当固

みによ っては.満足のいく品賓と効車ではこなせな 〈な勺まで本人的気が変わらない{変えられない}限り.以下のよていきそうです.なにか革新的な物がでてくるまでは φ

うになるものと想定されます

扱々凡人にとってのソフトウエア開発は.さらによい冒鱈

唐突ですが .プログラミ ングは . 療しいものでな 6対1 ばな{パラダイム}と.優れたプログラミング環境を頼りとするらない，という主Eーがあり，これを相殺するような冒編や環ものになります.

境は ， 優れているとはいえないという見解がありそうです.

2 . 生産性位向上したか?

ただけると思いますでは.何がこれをもたらしでいるのか?

4. 3 . 轟 L いプログラミング『援しもりというのは.究めて主観的な ~llですから.全て

少しずつではありますが，ソフトウ z アの生産性が向上してきているということについては，大筋では首肯してい4. C。盛時ptu凪 Pr叫V.皿血血， 51st恒温
それでは .優れた冒 11. 環境とはいったいどのようなものでしょうか?

タフな質問で.一意な解答はありませんの人を満足させるような鞠はあり得ません

各自嘗みの冒踊や環境を使勺て.プログラミングすればよろしいのですが，蹄々の事情によ っ てこれは併されません

プログラミング・プロセスに重点をおいて，ソフトウェア

具体的(? )なアプローチのひとつとして有望だな，と宥

これはひとつの例なのですが.単一の梅内で.ソフトウェの生産性を上げるという.旧来のソフトウエア工牢で主張えているのが. cor明戸国1 Programr圃 ng とい うキ ーワー

アのような複緯なものを組み立てることは.不可能だといされていた方法は.思った程効果がないことが解今ていまドです.これは当織ながら.弘のオリジナルな宥止方ではうことは明らかです実阪上回蝿をもたらすのは.智理やす{遺勺ていたらど免なさい) .ソ 7 トウェアを生産していありませんし.取り立てて新しい宥え方でもありません .

コストとい今た軍時音いも含めて . ベースとしているもの

より問題傾楓に近いレベルでのプログラミングを目指すとが全く異質であったり.他的拘への愛情合租鰻であると，対いう点では，他的涜行のパラダイムとなんらちがいはない

話や統合が不可鍵に近くな勺てくるとい勺た 目 本質的な理面も含めて蓄積されてきています.つまり ， その世界でのと思います.

由であると思います .

ただいえるのは.プログラマの持つ概念モデルを ， 特定的

こうしたことによって ，ひとつの誕盤に立勺たカスタマ

冒踊に町駅することを強いず，それらを重鎮的に飯うこと

イズや砿張が可能な冒笥や環境が盟ましい.という考え方

として.それなりに開発現場に普且してきています.また.

を可能にしようとしている.ということが特徴だと思いまがでて~ます{姐絡的ですが).

新しい考え方を鍵供する冒踊や環境という形で.あるいはす . 従.，て . ある特定のそデ，レ化手法や.方法愉を鍵唱する

一方.研究成果も.それらを具体的に反映した冒箇や環境

.

Z個
e・@
切 g 目色同 〈。戸一る現場に目を向けてみると.長年に量l~. 似たパターンのシ
ステムを開発して畢たことによゥて，突風的な銭術が.管理『常・』が形成されてきています

斗内ψUW川副Y ・入 lLhN 嬬猫

八ヶ岳夏のプログラミング・ワークショッフ'

いろいろなメディアを通した情報の涜過という形で.開発

ものではありません ー むしろ実民的世アログラミ ングに対現場に多くの刻司自を与えてきています .

するアプローチであると嫡えています

4.3. C岨叫pt岨lPr司V.皿血凪， 51山皿C園田伊国1 proar町盟国na 幼時国の目的は.ベースと以下に私が CASE を用いた要求定義支援において，個人的に興味のあることを列挙して
おく。
i

hh
海猫

とアりはきつるて良いがよ必感
実 つ グ 見いでがと気のはたこリ有く
たトに多充りのをおまチどなそてい
い-んのをな私}にい一なうもしてにる来てユヘム身〈で?階なロ向よでとせらよ出しチらテ中多形!段かプ指の野例まさに感

く

R析
こ

ω をと
E 分た

・の

ア ト話分体済'向実実のこ ス のがる減のいシ そ人
充んどれ加計はうクのの具 でで指をがきはトにいきさ設とい￡人 議'いとト性
ム野題一何な激カ)論 と ジ の定が織あ ク 様
パ え法す ブ 界求たずたェ多フ
寺 問 パ 如て刺
ジ の
グ。
のス '
持に
=終方かオ世要いわいのル{をだ生際ぅ・て食間ブ現
突 い 論 れ ・りオ 表ロう当キプ
よ本エな味アさ義まに〈え・だは興リす定{計・と勿さに通チ ののに墜ただ でつつるたシ

な門て言 にたでもトや
求 に設
一 でム
の
ど
。
摘
め
に入いとけ
代ら一け要たしのなる指たをとテ。
でムっただた時かユ受(新理もス」 あかたかあ
まテにつるつう質「

まス向ああかい性の響ムかをいム情幾かあえる
シ 指でつ良とも向影テな様はテ実は無で考よいトトりつがうら指のスの仕てスのとは何をにシ モ 求 つ シ 人こでが析)は一ク通りのこか。ト私
パ エ待なたうさかク.
徴。 。要わト個るの向分化
特 ル ス ジ 期に来ど深うエはがたで伝一私あも指る変。
のアキブ・ 火 出てのろ ジ のたつ方〈 パ がでなトよのう番リエオり下がつ容あブたつあえなスの用うクに点よ
一ト::あがと使内でオつあが考もキた有よエル視えジ デ{ 言の一)でムこ・ 'けのいも論なとエいつる
プ ユ研)の一〈てでだんでく法的らやてかすブモ方とツチ中大もブ聴つの私さつし方向かいしで進オ)れた逮要促際切らっヨのカ工い I に作なは山まか計指こ
AM
シ
つ
電
東
深
A
併
で
代
の
柴
鈴
ず
設
ト
ど
敬
重
を
実
取あ
J
m ので
ク 2((
味で冷裸時た・に恥のク・!ぃ・解しU 事果-に雄哉興中をううじでればかエはだつが理か

自めヨ

分に
ツ

パ 準なは
h い

M 通は

つ自ワいてなんいは)てしか臨・そくれ関もにの年と定マ昨分
も 今 こ予一'
S

ハ の方 r とか

0

「

当辛つ口て

ωg 自民国〈。FMZ 。・@

フを因のうフななまなりのてえ強のののら成で議ソれ原そいソう学)う取いしゅを私度分な作離とのそだアといよ工らよてな用れ性・程自のアらっ在)んでつ悪のアかるしい応そ効はの(る子たも?

癒合7善'たト輩規環り成えが恩がけっ7い立

現も生ウょにこエやすとてを。即のどばいウつを。〈をトし待。ウ(定境得果る'ぅ・れてトだて的闘いけ上うぎてが。のでれ雑観情-・を。
グ たそ

かも都ソ改らっ7くををな術
言 うにだな思ソ ら手うく不がをかかソ吐語 能と技とろうじれと'くる
ろ良の応境由な「を言 機打の務かよ同〈いらるすか(際対環理はて論にた定在責無いもてなか来服
なと突な発うでげ
暴 ちい決現のはなししわプ出克
はるでがうりのとわにいちれもうもきかは変てルがれの上恩たそどい栂とぎ漏れろたべ聞のにれい来に当ゃななをど・らどあれすどう狼くたってな出う渇J言。 し冠急近いとて譜表'J〈)ながかのでら下ほ恩ててしあしい 務 そ)せにきとしい論がそJ?らがよるアい全!
か入アるす品なも害!なのにエあ対ウせの弊いれでるかを早愚し果つを発かう手ウがにトかも=なしまいあ名をが欲結回ムな故しJ 7傾結ソはと果過るかでれ証い評功境い飛ス安はまはト向果フ欠る{ぎ。も今て(う価値帽を。びテ易何シ うのて丸 ソ るのな価を成かいい方さなとの果環なに一な的学そ成るはてトいい
し弾度めそう評動いしてし「にの程戒'ょの活なにつ苦たが後工'的。来でつ-とな
パ い来
男銀るらくので究少学ま堅まみ聞もは体?出かか
猿 あかなこ面研の工し少'試のとみ具かの定きス良出
然ぱ'てと「務なろ験て多りるさこ試のうとは好キぱ際「

突れはしこ。実うこ経つ'たす深すのへろこか)エけ実
をけでをるるよとるならみりの出種野あうのも。い。
者な喝さすいものるなとかでた奥を各分で行るでるてう

心を発せ)箱アのすのるなを規ェ近たてけ十んど易をる

いえ現悪求て学の得単と省っしの解のるのにいであめ思
易考のて迫め工もれはこ反取定ア似めいな分でこで貯とがと開きどをAそともれうチをウにうれだを望ら安醜いにこアきほ命ウアこうわよ一とト題狙ら足トをなも知てなのエ歩さ寿トェついらのロこフ簡をめ不スト外にのっ時目勉でい 大 造ケんたにチS。対皮わなルで開るのる歩若と。
。A?にのい的一上のれもよ進「こうも一ジ 発がうた'ウソはよ工
ブ関とよかはドのにのア
ン 内善そエ

にに

ヨ

ン

-Y

り否こは技手の E になはそとや的

ソ

P

も

-こル型

t

S 前きと
S

ウえりいのウの的うトれいCの-7て極在もル現郎あソ発れ無う下あカがい程
ロソし日現る7今ので(開さのい況がで換て過チト考まE えはリ・でし

プの通商いいのら程況をで殺態と状浬一交れる
アでを真なて応か工状程カ鎌実どい無イ見わなの味ド不いれ対だ集な工リでんななりテ意

3

S 雷やタ治学渡
今いワしれ化ツいのよ計ア現ん.広一とさ品マ多々い設・・かAは'イ肘工橋
キ員用商トが個なムてにいCとはパにアの年憲一でできプ。作うのメ濁せ

書 と・た一来ツの'のチ在分ろ7きていもでつパ出るで一 品るなた多イ国改。ウたるA以いこした一典

オアこいしくクおらあいまどトりなで評聞くすトAな実筆のに孟にねでないな7成う学の多関7Cめに特法法

いとよそろミツ る一りでまウえと一なそが言味Yツ よま踏ト与どツうしルと意ぜ点たもかたす
だ題っそなっ応・ ・今を 7 をな・よか一るる上向問あソ 唆 論 7のしツすす凱'はあ対アが・果
指るでがででヘェるで成'示議ェ
E 。の値足るS い際に補よトけいるのま)ウう中のはのるウ

一決
一 だCかルめと局
ツ たアくうにりをいよらレ
ー解うもう一たル大のえェていルよこなえかユ

策にこつの E 現しをれ見と)発もは際的手な今要

いよが実て被て地は支をの虚発なのど回求E
委利て ツのもはテし題ら・るに・発ェへS
うムてしピもてでスと問がにいとさ活ウ計
シ ルうな特てこ若ずト設A
いラしとにいみきCと グ とル特なをべや一いし。れるるせフム
ツ とかるわすあもソテ
J ロ 」 一(ぎくす議E プえ ツ I す多は定のかしあ行論でと・スでS とま
EM かの価求用意。でに強権普はシとAくりSM しの 評 要汎べたの分を特るでらこ
C 書 たAのにものなるすつも十ルのた諭かう「にあC新たるら質すうあいら一Jし討義行
ツ会さの定をてう「に鰻せいか異援どでしす

ト一を物ソト目どでア込は現完〈勉テ所余保も.こウ人(のフウ立とあそプむソ実霊求強テス以り守や4。単 く み' パだ・酒江るらをぜが備状'れう果ネ以をる

だはルモ現れあルよ今もいうしうずがジ 噂 I い方のし比物成ワ特隆悦ものかもい感方そ半つLM'の。れ世のはとう一も・幾ブうAつえ私。
なr てき
年う野山ず'なでかよのプででオい「・考もい
今ろ寺柴いはう在るるそ-うま)ととてなし抽置はし大るに教ろりとと2

Ma・-.ポ意強のそ人しを行川ルし l デ泉はむはんにつなの勉プ
2 ら況実はグたル「後飲とな純くん

今 ジ 見に当の(き相陸委回一て日イ郷グこ・と計て方P る
くな決輔副るけかも
E をれ
0 あル利とつ自のS 後崎県日でトを度あに私江いべ「に。のすだとめ!〈@手たC席い何勧A以を:始ボ気
2 でプ・式てメ書い園町つ P 欠な「のCて何5 開ンがにと-し正つ
ザをなとま・もいでんでしのM の一パいこルだ。知判パれJしは)てのさしと
EP ンリンつるグ人
・を
S{
ヨグメ ・
小てり!て食下きた野と役
知の 5 ・力はペめだっ昼松てい脹材話A食シう・りぞ私も魁・
そンとんなの'しての題世Cタツいプなみ
・てらの
こヨま〈と日芹をし長をのにのカと一とのたしたん
年 シ が行日初岡事験員)プ私自ス」ルと神ま算いき『んめ合とになあ印過と~るのかこた人よCの銀と込わい'るつ叩ごい目。地しの)もうでは弾けでを幕心J'h山この O はが買をさ ン どな?
の情んせう内さて仰すう:私酒て酒メなはあ

丸無{兼開

パ
いと予もな困ち(d るいさごてるりまうω な ・まののきす通集よでな 」 のたとと持ん
一 しの
はい何ねけタ気事削と?で然口てに
一が
パ うい。

“
をい・でたてp 岡れ(い〈米れとこてなル』恩習のつつで鯵旬。ゃにと純くこのつも・不グ の E かは食でで磁八済つ始ももた困っC P ピ
みつ備つ今 まの)刊と私 " ん」「くがま眠つ準あ。しC大同何や夕飲酒たなとしいス
睡た「る・テが一め'すがのたルω 刊はに){いルあ
グ 加るて
プ pm 見しる。おア を' 参 ましtM 論 強ある変用昏で@集 をのこなさに年けば昭威主の突しコとル者わい

M} 功たあはか一に一会けな

こ分一たはりだ山えの
P
時
・
り
こ
け
頭
いに
・
入 る分のなのe考ただ・のた
Uをしのとこっルす
プ 員もいに惨私時とがのんがのとなか高なにた シン
うのクメ特悲。刊るだ)C飲だ
Jとに数と'

い}面い切ここで帥反ろ「たす

P はす

しはもいなっ記を Mうでう残を事 ω ど味ょに見仕 m{ 意の象私
と日 ・
たC印る

然時・っ

l

漫 LH・遠ので関だじがは他下に・以]た作だとに員の年らでえムぃ・なそ』ず委た昨がこ[考ラてはと。いもグってこたな
何ロ思しのつはらプとと然ま丸
かにう人当し弾
段織こ個しての。
普同頂私かっ銀〈・とて。し困『だが年せ) 。〈のたい昨さ!るなスいなか退だいはクて釈放辞うてでツせ
し何はよしけルさ
申'年る樹わブとてが今い感るたパ
けJOてといっ­こマたれたであベ
もつラっきけせ・ン「指師と札及で・の旧名の勉」び私

じけ代れ制さ持加ポ
はつ世事役抽置を参のずグま待頂わにヨにらロし期て合領シ
ジ
めかプてをせち要側電力計算セ ン ター

・マルチウインドウの上での rÿ ルチ シ ート」による仕様およびプロ グラ ムの記述
・フロー図や ブ ロック図などの 「 トポロ ジ カルな パ ター ン 情報」の検 索-仕機変更の正確な記述支援{特に安求変更とその~響の差分と合成の表現と表現情報の管理}

川丸M
山W 刷 Y ・入|二ツ ールの必要性・有用性に対する廊織を深めるというアプローチをとることが出来たと 言う点で.非常に有意豊島であったと私は膨手に解釈しているが. グル ープ ・ メ ン パ路氏はいかがであったろうか?。

ップの印象
渡遺雄一
ヨ
、ノ

ワーク

ン

い信討はらら度え麦味じをて〈)てがけ程言喬地感 箪

たらのか滑る就だ食あがく
っじ論・{れのるをでた置られ掲な里と寝ろべっ・ことてなう荘園咽時のか
いせぺょっ別いの手い暑さ選たみ・なそ若はてをにつしはた。.兄。
し沢経か楽で持たの諮る
パす
反賀気し応点もつのにいを苦 一う備。行もンと意な所りもい設うにたメと斗向なぐ凶Y ・入 lLhh 泊滑油

つ取スおもめ表的
立'一てのたに定にでペしるのみ暫役のタをい築巧').る一理て構をが!
にあデ管しン」いで時がののとヨ制なムた要来タマシ時いウ
き必将一チ一「はジ
てく・デマケ'てポ
出おはたチリはせがてとめをプの出シ
語しこ合けアる見・
言理いもだ務いはア
述墜な味備事てえエ

記とら意墜'え答ウ

ったてつな続ルとでそにら
恩っしとえしテ題
C こうが
P 容よな
とまとに変論ホ課
か・別プを議ス討た内たち
ろはは一所でネ検つはい待
こて中ル場まジのだプてに

後
S

くさ

た{
れん

て西
きた

川〕れ実現文

けいにこ'

たあと

・るは

悦)こ・・論E

MJ
時 ω
間引で係のム
H4
ん関モウ

8
8

ジ

シ

ン

つノ、

てれ

fJJ

れれ込幻完'
旬仏)ち札補しポ
持"にだ

取て

札容のウ

HH
oi “に
共
険
uhu
場院に危ア
叩乱(の・
MM
的はエ
.

は
l 社論上

しに

rIU
をカ
)協

e
ル」キ

・っ・り

もに

こ理
ろ舗

ωh 学討・弁"内るトAL 科)りた 'u ・す 7
M 川代 J かっ法社でにソa}M 近 M つあ述ム本み
日iM' 刊しで記一た呑・察叩れ同 グ {をの様オげ織!考
目印は ン 店れも仕・上をう
一

いに荘い度遅・今てル功しし年別な適夜が'ねグ成楽
源今{たはたうで兼のてをとしのグに〈ピ後主-しみ

うたは持プま恩のを々来ト

'-フパ
〈プン

〕{ほ

遅スメ
夜シか

・プス設 い分エl 私ロテ計がかア[[務掲[集手]]-上叩]片 45 デので
6

ンン でレなもmgE 包同dFF帥 Z0・@

結は日にク極なも)能タトを一らをと実際た述張いくも特ツ。的てなもスク線デか練こ提実ま記肘グ ェ仕なて訓るぎ〔。の肩良しと(ルい論い近のももく前ブな理て身る
ンジ求う
し似れわい
何(な以'いがつのいイブ要よ定媛入ぎながたな
は時少発際てB 言私てデオのる固な仕わもだのん
良発だ開実れD り{つ一・でうがうを'で題そそ改開たも。らやかが待コ準場し語よ報もの問ふ意いもて切ぱ痴。処漫構作にに①験か言感速なのので。くるれ語つ系と{基現換言た情でもがば?
ア味る惑い触言ぱ理然造成・変はしら語い度れかし 患う語だののうスち体誌なう理とう
ウいてくつ一ト良じ良思はぱでよ言たム)よ一う回総んそ処とまを感・とにしこしきしラ々なべの今りどうやこし
7
ソ題〈ではと'そ震べかグ等能タら'な際そ性るい問強のでこて。披るしロジ可一れら会実'頼すつ

3

か一て-いヨいでパ問段プいな体ま①再る②③おのしテしテ良シな

て

・い

だにで語

な諸といのなれるを然。プ一と述デこか習。ら信待一戻しの」ないうらあ』・るいケこ記た。い請うかは期に決守いいなよ去で手はあしツくもしるな'ろ
解保なてかのれ念一策でわパおでチいがてあいうま言を・られい僅忘残の応とさ'てつツてうつでら使チび
題用江きて問がてげ対こふロしいマえよ使いくで一一再関連ば理れの庖つ遺のるにクにでに考しをなる務ロの「れ墜さ機関至『〈え語マか語語とはりにれ実プと守はけく映仕のはのら耐
脅 (ら言言要でな外さ'アう

8

あ個ツ題階ロがら的私で然利か然然〈.

用う的し正にラ現い'しっぺ郎りベペとがそヨ〈ヨだルとシ いシのナ。
還ろ人クが)グ・ななのじる用ぎるるこ点し保になし反ム縄の私ばとき品明毒事重れン以ンが〕 めにをれ国語のな景よ算江ル勘定理を議ソよれいに語てパ にさ使②言つ果そ本-百ス嶋背し計がイの整タもお的出なトンとて畠思えら)はの中方になのそジ等
ン てイ地し周溝た前でどのい楯がに。モ法て系百も以内な話言をう級ぃ・理し体論コって心関を身いドの定のなく具るは剖来て。スグは-らな-ら制でれす'れに分出しうク
しイれの用しゃでくめルをと備ろ一ニメ点べばてはフそ格運もいのでた一)こ準なワ一リうオねく
しに・規にか使いつの品々くにとりレプいもせな

参 lJ 邦 28[

]]l

1L山川町
7誠誠解諭正一中はげ'
献 Pいω ソ津漂の議本内をら上遁
文 RE-- 有有]に国情掴タかき渡∞町ト::説を明:心[ら高snh
発エエメら中心スりは7
hJ 開ゥゥ ・けタ中 シ入 にソドい叫アトトむ出国-タてが人:JJ 孟 77 合ちデ一し]た山
bm ウソ ソ も民間:デと 5 れ手

同ぺ王プ工パてのシムすぐウ
けし川にアアンれ心のテや直ト

rJ 道ロ学のhnhなト・川刊しタ岩人はグムを'る郎

M 寸'イ波は冷ラ綾取全だ品

泡引開ピ書こ汗ム計りてろの

けな て 努よた針重では様んなののな考のト仕ち。に報タうが善7にき!駄情一よ私鰻ソ
次をう無・デると。の.報こがにになだる年
ぱ情お力うずと要あ来

おタめゃな持指でと細度気ト'もま盤。
9 あ
適の ツもであタるかつを度マて時・-いいつ
報程一え何しデてなり情のオ考に但'し来な
でそ 7ろう。で酎出にス。一いよるの検が能一かリろいあいをと可ののような気がする。例えて言えば，古代エジプトで ， 測量の技術として型車何学が発展したことと.現在の豊島何学の対象(例えば代数曲面論などというもの)を比鮫しようというJ
べい 7 い しでなルこは

黍)
劃大
玉図
ざ稲。
わ早す

にさ謝
め車庫感
た伊に
の)位

考]問訳

ことが無理であるのと同じことである。そして現代の幾何学で使っている道具は，ホモロジー代数などの他の数学の分野の成果である。

叫・-M

私の言いたいことは『鎮の弾丸は “ 今はまだ " はい』ということである。これはブルックスに言わせれば「だから『銀の弾丸はない』と言ったんだ J ということなのかもしれない
が.

ぎ(ま
わんし

てメ貯ず能ものここ詳えでき必可標為そう(
蓄ち.来検自のにい。

私ン各【[時〔[[をしかしブルックスは，個々の銭術を取り上げて云々している。しかし私が思うにまだソ
フトウェアに関する技術はそこまでとても到達していない。人類が過去に得た科学技術の知見を素直に応用出来た範.の技術は.確かにコ ン ビュータの世界でもすぐにその効果を表した。しかしそのようなもの以外の要素を含む難問に計算繊科学は立ち向かおうとしている。そこで最終的に役に立つ ソフ トウ&ア技術というのはもっと我々の考えを越えたもに持で将変り備特とる

い候。とてるもなが限意?

それのを-e はい食我出一
いきう段ルたとな昼構がポ
たかい手グ来いは'結検レ'泣と動の出なでて・交のはで村移々がはけしは報人の順荘う設とくわ了で情各う不別いはこ惑い終り見。

辞ん)
副聞きA

そのような状況で.銀の弾丸を議論すること自体が間違っているのである。例えばエキ

〔康 R

ない。

こもいだっラ所に会がくれるかもしれない。つまり，銀の事事丸を打ち込むべき対象である『狼男」の実態が良〈分かっていないから，銀の弥丸が手に入らないのではないか?。また 一 方で，弾丸の製造
およびその周辺技術(例えて言えば，弾丸があってもそれに耐えられる銃が無ければしょうがない! )が発展途上にあるのに..終目標である銀の弾丸がすぐには得られるわけが

7

スパートシステムに関する研究成果が十分に出れば.自分で考える弥丸が生まれるかもし
れな~ \.言わば万飽叢的な弾丸である。 li はいうものは ， 通常医師が患者を診察して後っかの判断をして適当なものを処方して渡す。そしてその投薬効果を再び医師が評価してこそ薬の意味がある。(駄目ならほかの叢を処方する必要がある! )と天が車しすのもプたにか荘。だは関中も者ツい的うに別たけでに集ううヨ聞極ろ
シ を積た
りのつわ点点にいら
わ岳あたうの論と食ク話くつ
おケでえいそ酎
7面一々しあ・八ろらと。)イにワ色らで。

だが弾をかなり使った倒したので食べられるところがほとんど無〈なってしまった J では
つまらない。また ， 肉はとても食えたものではないかもしれないが.毛皮は給機上等かもしれないから安いミンクよりは，貴重な狼の毛皮のほうが(下手物好きの)彼女も喜んでンなずら応とせデる応
シはえか相こさモす対?で敢だにくなの現な

しれい

用けで
応なん
しいい

〈か込

正て思
をしに

・な L

学を手
計)腸
統どか
は消な
に掠は
理ので
整磁の
の知い
量要な

(是対

)不来
線・出
情正処

(ダ

訟のは
知現に
な表報
大輪情
英知の

。のる

は理一
私整オ
た闘え
っ知越
かにを

た的乗 ・
い画 6
ら計の
も・ 0 が
てらーだ

しが・の
輸なばる

5. 何が銀の弾丸なのか?
時にはサイレンサも必要だし，部丸は l 発より数百発のほうが良いかもしれないし.散弾のようは仕働けが必要かもしれない。
r 狼を捕まえてみたら，以外と肉がおいしかったエディター

である目変微量使用で~.桁.も普通の電...より 大事いものが 11 える佐原伸

電車 としての楓健はほとんど同じなのに . 33 舗の生産性

鼠A

ヨマ ン ド官掴

このふたつのプログラムを比帳してみると.

.ツール聴などに優秀なものが事<.プログラムを眠階的に少しずつの釜がある作り.それをすぐに司箆することができたが含まれている可範性がある

1.はじめ位
『ソフトウェア工学は役に立たない』という窓見をよ く 聞

簡単にみてきたように.住所録 .CO桜丸パーザー. 電皐(l:准扇・プログラム

うよりは.これらのツールを通して優れた方法槍を暖眠1.- .

よっては千備を旭えている，何故このような釜が発生する

生.
.
性が飛彊的に;:r..勺たともいえる

褒 -1 町中で.開発アプリケ ー シ，ンの"で A血勧田S とてみた.錨畢はソフトウェア工学は役に立つ」というこあるのは.前述したよ うに住所録管理プ ログラムであるが.

のか . 以下に見てみるとにな勺た

4 行自のものを除いて，書店者の個人的要京に基づいて作ら(1澗"雷冨れており，晦与の年賀状の宛名書~に使われる予定だった(注 1) ものである

ウェア工学 J という話置で話す

その軍時で.生度性を比峨するのに.

告がよい

l.'/7 トウ :r. ア工学は優位立つ

この住所録プログラムの生産性の比敏したものが国ー l『ソフトウェア工宇が伎に立つのか立たないのか』という・・は.個人的にはだいぶ前から繍愉が出ていた

すなわ

ち . ソフトウェア工牢のおか、げで.筆者の・人的開発環境・生産性は飛属的に向上した . というもので島る .
しかし，ソフトウェア工牢は役に立たない.理蛤など投にである.領楓グラ 7 の節分は開発時閣の比較を示1.-.値グ

ラフの節分はそれを・健量で修正したものである

縦舶は開発時間.横輸は開発冒箇である.

用.コンパイラー理愉の使用などを主慢してくれた . といプログラムによる生産性的釜が . 置t+儲から散百倍.場合にく.実臓にはどうなのかを.個人的な経圏直をも とに董理しそこで八が岳町ワークシヨヴアでは役に立つソフト

これらのツー

ルは .補遺化III計.ツールキッ ト方式によるツールの再利

3 . 何が生血性向上をもたら L たのか

4 . まとめ仁かえて最大の要因は . プログラム宵騒の進化だろう
思い7 ログラム冒箇は F町官阻.

生産性的(町ソ 7 トウ ェア工学は優に立つ上述したように『ソフトウェア工学的進歩』で生産性は向Buic.CO猷)L揮で .

モジュール化上しているのに目どうして『ソフトウェア工学は役に立たな

情相周蔵

い J という声が出るのだろうか?

ー補遺化プログラミング

ウェア工牢の研究者は.ほとんど co桜丸. PlJIやBasic.

車因は簡単で . ソフト

そしてそれらが動〈開発環境を研究していないからであるーが..にできなかった
その結果.既存のライブラリ ーがほとんどなく.自ら手作

これらを研究しても生産性平信領性を . 2 借や 3 倍にあげ

この図をみると.生データ町方で量大 200 倍.修正デー

りしな』対Lばならなか勺た例えば. co副主d パーザーのることは何とかできるだろうが . 100 情 .200 備，ある

タの方で畳大 1200 情あまりの生産性の差がある.しかBasic 厭(注 2) は. unix 上であれば概観関取として利用で

いは 1000 倍に引き上げることはとてもできない相様であるという正反対の声を.メインフレーム上でも ， この中でも勺とも開発時間的短い E骨perT且k によるプ

きる書徴的関散を，相当な工歎をかけて . 自前で開発しなけ

co猷コL を使勺てシステムを開発する人からよ く 聞 くこと

ログラムが .も勺とも 楓健があり .使いやすく. 遭い

ればならなか勺たが多かうた . そこで.・人的に開発したプログラムの属性

F田官岨による量初のプログラムが .カー ドを観み込んで一方で.生産性の高い雷留は.モジュール化や情報同車あマルチメディアといった，劇的な改薯を図ることができる

を時系列的に量ベ .今と昔とで.何がどう変わっているかを

一覧表を打つだけのバッチ処理アログラムだったのに対しるいは欄遭化プログラミング能力は当然備えているが ， 他

かもしれない遭が見えている時に.憶が CO猷)L を研究す

飼べてみたて .l骨perTalk のそれは，すべて対話的に検*1.-.書調のにも住所管理や CO政コL 解析や電患に関する知"を.宮崎

るだろうかつまりソフトウ z ア工牢は役に立たない』

キーでソート1.-.郷便番号から住所を自動付加をす晶

11健として持 っていた.例えば.

のではなくメインフレーム上で COBOι で欄売をして

立たない.

-M
∞・

さ

一方でオプジェクト指向やハイパーテキストーあるいは

1 ・人的生皇位らに.過去に作勺た awk と inf，四百店 によるプログラムかー文字列の鼠いいる限り . ソフトウェア工牢は役に立たない』ということな( 1) 橿Eらデータ をIlみ込み ， 週択した錨畢を一覧表と住所ラベル-文字列パターン町一致

のである

検*

(l)現実

.-1 をみていただきたい

これは筆者が作成したプロ

グラムの主なものの置屋である

縦に作民年度 ， 舗には .

os・開発曹舗開発時 間.能量ステ ヲプ敵対 量アプリにアリントする

ついでに ， 電憶の自動発信もする(3)C OBOL パーザー

しかし，現実にはメインフレーム上で CO猷)L で開発し-対話楓健

表 -1 でAp酬慣に白F田ε と書いてあるのは(1 0 行

ケーションー開発方法槍を列唱した.開発時間には，純粋に目と 12 行目とでふたつ存在する).ほほ同じ楓健を持ったプログラムを作成した時間だけでな<.会・などの時間もCO猷)L解析プログラムである

こ のふたつを比鞍して注な6対tl!ならない，という声が聞こえてきそうであるが.も・リレ ー シ，ナルモデル録作.
os とのインタ 7 :r. ース

う一度表ー l を見て歓しい.この中町プログラムで . メイなどに . 生産性的鳳い冒樋よりも遥かに優れた楓能を持ち，ンフレーム上で CO猷)L で開発しなければ現実的ではな含まれている .ま た . ステヲア憶には注釈文も含まれてい目して歓しいのは. 3 幡町生度性がある後者向プログラム

る . 11健量は .対 .アプリグーショ ンが A抽出 . すなわの方が.

ち住所管理プログラムであるものについて ， 主賓な楓健司

てのものであ勺たことでる.また.前者のプログラム町方次に量璽だったのが開発環境とツールである .

インフレームで COBOL でも仕方ないかもしれない

量 を比車で捜したものである

が.品質は圧倒的に良〈な<.処理速度が遣い .

優れた冒筒が働 〈 開発環境 ・ツ ールの方が.よくない言語

かし.他的プログラムはそんな必買はない.これは特殊な(4)電車プログラム

また，プログラムの走ート 1 でApμ ・にCalc と書いてある電卓プログラム

行環境となるコンビュータは，パソコンからミニコン ，ワーは，コンビュータ町岨京円前で旬U~ を使勺て .8 進 16 進

クステーション . メインフレームまで各種ある . 古いデー

10 進歎字の変織を行なっていたプログラマへの剛りもの

個人的な鍾睡で作今たものもある

タのー績は .2憧に願勺て配述したので .211 くらいの鼠差

注 1: まだ一度も出したことがない.今年こそは ・

しかもその楓能的実行動車も優れていた

いのは.

(l)聞".檀 ・ ツ ール

データを樟日処理する必要のあるこのアログラムでは。メが鋤〈開発環境・ツールよりも温かに 置れていた{注 3)例

7 行目的プログラムだけである.約 40 万件のし例ではなく . 今までに開発してきたプログラムないしシス
テムで.本当にメイ ン フレームで処理することが必裏だっ

えば，

注2

それでも C 上の普通のBasi c よりはずいぶんといいBasic だ勺た .
注 3 : 実際はよくない冒踊に，開発環境ツールはほ
とんどないといってよかった

たものは 1 割もない，。)八が曇

八が岳のワーク>'. ッ アでは . ソフトウェア工牢の役に

mg固曲凶〈。Fuz。・@

これらのプログラム IJ:.会祉の仕事として作勺たものも.

os(Unix)も開発冒簡は..ex， Yacc ，。 も ，初め

流山Mの、刷Y
幽 ・入 lLhh 泊滑油

ソフトウェア工学は役に立たないか?

CASE ツールとアロトタイピ ング富国としての;otプジェクト指向ライブラリー曹を持つ ob炉Ct P回・曲l

均poflalk- 時poflalk 壷中心と したオプ ジ ェクト指向アログラ

ハイパF テキストとマルチメディアとオブ ジ ェクト
指向をうま〈まとめた E骨poflalk

ミング

・ 伝E量的ハ ッ カーRichanl SrallI皿a の ONUE皿畠国を取り上げ醤したい .

0NU0++ . }Ü岨{の佳昆
筆者の自宅と金祉のaの上にあるワークステー シ ，ンとをど.ひとつとしてメインフレーム上では手に入らないもパソコンの 5 台は.合計で官M の CPU パワー.メモリーのばかりである16 . 5MB.デ ィスタ 3剖5MBを持勺ている

274 ドルで.買い取りー餌ソース付事

フトウ z アは.

その上で・〈ソである.

しかも以上 3 ソフトウェアの合計値摘は .
ONU 関係はタダ

斗内丸山、Y凶 ・入 lLhh 泊滑油

つい 2".は伝.であ勺た島田11皿lk

立ちそうな歯周から .

-Me
・
.

ωg 国弘同 〈。F帥 Ze・@KCS 山本

八ヶ岳ワーク シ ョ ッ プにて一成

ポジシ，ン ・ ベーバ

1918 年 11 月 g 目(水、旗本良子
『銀の襖丸』があるか?
1.はじめに .... ..

ワーク ν 習 ツ プには、以前怠加したことはあったのですが、はじめて pc として怠加した

ここで『無い』といってしまうことは、やはり淋しい.せめて『銀の玉の基』ぐらいはその感想とワーヲ シ ョ 'Y プを終えての感想をここに.いてみたいと思います。

欲しいもんです.

2.

ると実感しました.今回のグループ討穫のテー 7 となっているものは 、 全てそれに値する

それから ....

まず、反省すべきことは、今回参加した理由があいまいで、なにもプレゼ ン テー シ ョンするべきものの持たず、多加者と同じ感覚で、いえ、それ以下で、出席していたことです。
(みなさん、御迷感をおかけしました。すみません〉

まず、 わたしは、エキス パ ートにおける技法を使ってというグループにはいったわけですが、
わたし自身エキスパートの事は 、 全くわからず、最初から困鍵が待ち受けていたわけです。
でも、ソフトウエア開発、それも設計におけるエキスパート ・ システムのアプローチという-制。.

ことで、いままでの経験をはなすことで、少しは 、 役にたつことができるのではないかという甘い期待で、二日めにのぞみました。グループの中の人たちは、やっていることはいろい
ろ遣ったことを行なっていましたがだいたいみんな年齢も同じくらいで、かかえている問題
は、どこも同じで少し安心しました。その機々な問題をあまりよく理解していないエキス パートの手法で解くということは、大変、鍵しい事ではあったのですが、なかに、その手法を用いて仕事をしている人がいて、最終的に、少しでもエキスパートの技法に触れた事は、大変、勉強になったと恩います。自分の勉強にはなったものの、参加者の人たちのお役にあま

4 日間いろいろな人の話を聞いていて 、『 銀の粉』と呼べるものは 、 あ

ものと思います.

ソフトウェアは幾つもの工程を経て開発が行われています.そこで、私は、ソフトウェアの開発における問題には、

1. 各工程における問題

2. 工程聞における問題があるように思います.
現在ソウトウェアを開発するにあたっての微々な問題は、『要求分析をするときはこん

りたてなかったことをふかく反省しています。

な問題がある 』、S.

れていることが多いように思います.そして 、 そのような問題に対する解決策として幾つところで. . ..

今回、?シ y を持ち込んでグループ討論を行なっているところがあったわけですが、二 固めの夜、興味があったので、 (GL 、 LINC のグループを覗いて見ました。

『 設計書を作るときにはあんな問題がある』など、各工程ごとに捉えらもの手法が考えられ、 それらは、100% の解決策とは言えないまでも、従来の方法に比ちょうど、そのころ 7 ルパイトで、 COBOL をやっていまして、どうにかして、あの同じようなプログラムを簡単に処理室できないものかと思っていましたので、簡単にプロトタイプでき

ベてとっても良いものです.おかげで、各工程における作業効率は随分良くなってきていてそれが商品化できるのには、大変興味を持ちました。

ます.それゆえに、各工程における問題は解消されてきています.

しかし、はたしてどれくらい現状のエーズに答えられるかは少々疑問が残っています。今後、どう発展していくか興味あるひとつになっています。
'-お わり に.......

わたしも、今は、働いていませんので、役立てる事は鍵しいのですが、いろんな会社の人々と交流でき、ふだんの生活では得られないような、刺激を得られたことは、事実で、視野も広げる事ができたと思います。

次に 、 工程間における問題はどう解決すればよいのか.まず、浮かんでくることは工程の数をできるだけ減らすということです.工程の数が減ることで、当然問題の発生する数は減るからです.このことは、第一の問題と同様に現在では、自動プログラミング等に見られる周に 、 ドキュメント = ソースということで 、 コーディング工程を無くすといった具合に 、 徐々に実現されてきています.しかし 、 後ら工程を減らすことができるとしても、ソフトウェアの開発を一つの工程で実現できるとは思えません.一つの工程で開発できな
い限り、この工程聞における問聞は残ってしまいます.各工程ごとの『鍍の粉』があっても、それらを『玉』にするなにか、
ように 、
思います.

『 小麦粉』を『団子』にするには『水』が必要であ る『銀の粉』を『銀の玉』にする何か『ソフトウェア開発における水』が必要だと

戸伺 Z 。・@∞g 田弘 同〈。

各グループとも、違う 7 プローチで、 [銀の薄丸]を求めたわけですが、この期間だけでは、.終結論まで導くのは、大変むずかしく、途中までのところが多かったと感じています。
しかし、これを足鋳りに、今後、自社にあった 7 プローチ法で、 [銀の弾丸]を求めていく
ことは大切であると思います。

流なの、山 V ・λlLhN 泊鴨池

夏のプログラミング・ワークシ，ヲプ〈若手の会 i ・八ヶ岳〉

このよ う な理由から 、 AI 的手法が 『ソフ 卜ウェア開発における水 』 に成りえるかも知

しているのかどうか.コレゾというまでのものは無いにしろ、その基となるものくらいはあるのかどうか、 UN I X 上で実現しているネ ッ トワーク環境を利用することで 『 水』と『 粉 』 を 『 玉 』 にすることができ

そして 、 いずれ『銀の弾丸 』 することができる で だろうと思います.

これは、私の推測というよりは 、 ほとんど希望であり、できればこうな ってく れた らな
あ、というものです.

弘は 、 ここ 3 年あまり AI という分野であれこれと仕事をやってきましたが、 そのひいしかし、実際に今このことが実現できるとは思っていません.

f ソ フトウェア開発①

如何にして知訟を種得するのか

における水の基』ぐらいになるものを干構築できるもののように思います.それは 、 主に次②

どのように知識を笠理すれば良いのかの理由からです.

③

f構築するためにはどのような環境を用意すればよいのか④

既存 シ ステムとの融合①

エキスパートシステムに 代表するように 、 成長するシステムを t構築できるということです.現在では、 工程間にあ、 ける問題がどういうものであるのかが、明確に理解でなど 、 やはり多くの問題を抱えています.弘にとっては、この閉館の解決が先です.そしきていないこと、そして、その問題も常に変化しています.このようなことに対してて 、 それが『銀の郵丸 』 のための 一 歩でもあると思います.

嬬描

き目で見て 、 この AI と呼ばれているもので使っている開発手法は、『水』が見つかったならば、、4 hh

なりえるものができるのか、本当に分かりません.

れないと思ったわけです.

川丸ψMW凶 V ・入|では、 どこに F ソフトウェア開発における水』があるのか?

~は、私にはさっぱり分かりません.現在すでに 、 このような良いものが世の中に存在通しているのではないかということです.現段階で明確な部分をシステム化すること-帥M・により 、 基礎となる部分の槍築を行ない、その後、 発生した問題に対応していくというアプローチでシステム化が実現できる点です.
②

シ ステム織築の大部分が知自民 ベ ースを t構築することであり 、 この知識 ベ ースというものが、 共有できるということです.一度情築した知織 ベ ー スは 、 たとえ利用形態が変化したとしても 、 集 め た知識は、再利用できるからです.
③

これまで シ ステム 化 の鍵しかった分野に対して、 A I 的手法を 用 いることで、シス

テム化を実現している例が幾つもあるということです.それは 、 過大評価して、『とてつもない凄いことができる』とかいうことではなく、これまでに実現できなかったことを 、 少しでも可能性のある手法を周いて試みるということです. A I 的手法はそ∞帽節目色}〈。戸4師0
団・@の可能性のある手法の 一 つであると思うからです.

ワークショップは、人脈の拡大、 知'眠、 情報を吸収するためのアンテナを持つことで、 自分

夏のプログラムワークショップに$加して自身の飽力向上に役立てることです .
(練}呉包子計算センター

It倉重利

今回のワークショップ参加で、 人脈鉱大、知E眠、情報、 情報吸収がどこまでできたか、効果の種はすぐに出るものではないが、 多種多織な環境で働 <SE を知ることができたこと、またソフト面では、新しい銭衡が近いうちに、重量々の職場にも浸透してくるようなうねりを感じた.

r.の型車丸』を求めて) 、 具体的には、形式的仕織記述を周いたアプローチ、オブジェクト指向の多"の中で.話題を持って会磁を進めるには、 コンピュータ技術に関するものだけでなくアプローチなどとなっていた.

“ニーベルンクの指嶋"と“ OBJ 2" との関係など、他の分野での知'眠、情報の必要性を改

続しいシステムエンジニアリング技術の、 実用度に対する剣符と、ワークショップ初診加というめて.じるなど.今回のワークショップ多加は有意重量なものであった.

泊滑油

今回のテーマは、ソフトウェア・エンジニアリング銭訟のケーススタディ(ソフトウェア開発の認なや、幽Y ・入 l 、hhNH

.6 回不安と戸惑いが.受鎗した中で過ごしたλヶ昏の 4 日間でした.
3. 今後の銀題

今回のテーマであるソフトウェア生産性向上のためのアプロ ーチは、現実に直面している問

1.グループ活動について
これまで使用したととのないシステム(合ハード)と 4GL (LINCD) 、および進化型

プロトタイピングによるアプリケーション開発に対する興味方、ら第 2 グループに参加した .

-UM・

LINCD の健飽a明から始まり 、 在庫管理モデルシステム実績を終えてのグループの鎗体的な反応は、これまでのソフトウ z ア開発手法に対する変革の喚起を予・ーしたようだった.
DB の自動生成鎗筒、プロファイルの考えなど、これまでの言偏仕織、 データ管理と異なる題であり、今後のソフトウェア開発に対して積極的に活用を図りたい.

しかし、システム開発、 ソフトウェア開発の生産性向上のみに目を琢われるのでなく、開発されたソフトウェアの運用面における生.位向上(処理時間.人件費など)をも考慮したもの
でなければ、 真のシステムの生産性向上とはいえないだろう .
大規.オンラインの降客処理が、すべてホスト側に依存されているため.ハード、ソフト、入、般信負担の槽大や大量のパッチデ}タ在処理するための 、 処理時聞の延長など、運用面に節分を随所にみることができた.

グループ討自白は、実織を使用してのモデルシステム作成であったこと 、 メンバがシステム開~に鎗わっており、それぞれの磯楊環境における現実問題を鐙示したことで、より具体的な鎗
自骨量求めようとする凄鈴から活発な前歯が展開され、.:終日の成果発表へとつながった.

おげる問題を多く抱えている.

これらを解決するには、従来の発想を隻えた新緩衝(ハード、ソフト)に対してのアプロー
チにも傾注すべきだと考える.

前述のように明確なかたちで、成長型プロトタイピングを実感できたのは、ワークショップに実織を持ち込み、献身的な努力をしていただいた、 PC の佐.さん、日本ユニシス(検)高2. ワークショップに多加しての.忽

グループ宛議後、プログラム愛貝長より次のような検拶があった.
なことはネットワークを強ることです
ひとつは、人とのネットワーク .

ひとつは.知'風情報のネットワーク.

“ワークショップで大事

-deF
∞帽回目包
帥 Z 。・@

山さんの也力、及びメンパ方の頑張りのおかげです.本当にあ世話になりました.

一以上ー人聞は言語だけで考えるのではなくイメージや音などいろいろな表現で考える。複数の表現でプログラムを記述できるのは、人間の考え方にあっている。

最近は要求記速を目的とした言語やツールがいろいろでてきたが、日本電気ソ 7 トウェ 7 株式会社

中沢賢光

は非常に難しいので形式的な 言語 で記述するものがある。

しかし、あるため人聞の考え方とかけ隠れていて普通の人聞には扱えない 。

1 はじめに人聞の要求を コ ンピュータに分かる形に表現したものである。

え方とコンピュータに理解できる表現には大きな開きがある。
トウェ 7 開発における生産性の向上に役立つ。

人間の考

この開きを絡めることがソフ

人間の考えていることがそのままソフトウェ

7 になれば、維でもソフトウェアを作れるようになり SE は要らなくなる。

プログラムを記述る。

人間の知識を表わそうという試みは考慮すべきだが、シス テムがあ適用できる範囲が狭いという問題がある。

以上の流れを見ると、表現法の性質がコンピュータをどのように動かすか(動作中心)から人聞の要求をどのように表わすか(要求中心)に移ってきているのが分かる 。

2 表現の変遷

3 作業の変遷

下図は人聞の要求とコンピュータに理解できる表現との開きを表わしている。
ヒ・ュータの動かし方を直篠書いていたのが、初めはコン

段々人閣の表現に近づいてきて、今は人聞の考動作中心と要求中心とでは開発形態も異なってくる。
現在の一般的な開発形態はウォータホール型である。

ング)が一番重要な仕事となる。この過程でドキュメントを大量に生産するが、このドキュメ

L+
n
人周の要京

ントはほとんど無駄になる。要求者は基本的な仕械が分かればよい、

コンビ Aータ玖渇かし方を表わすい。
人聞の罰事に近い棄現でコンビュ

保守者には役に立ちそうで役に立たない。

る)、量が多すぎる(何千ページもあるドキュメントなんて見る気がしない)等の問題がある。
扇尋頑蚕豪語すドキュメント作成は、この開発形態における大きな問題である。
要求中心の表現法に対する開発形態では、ピュータに分かる形に観訳する作業(設計、マシン Z苦やアセンプラでは命令を一つずつ記述する。

これらはコンピ s ータの動作を直接記述するから人聞の考え方とは大きな聞きがある。

その命令形式は手続き的である。

こ

手続き型の表現形式は人聞の考え方とは異なる。人聞は手続き的には考えない。

なるドキ品メントは少なくなりドキュメント作成の自動化も容易になる 。

プ ロ トタイピングは普から行われてきたが、要求をコン

ドキュメントが減人間の考え方には入力と出力は出てこないから、関数型の言語も人聞の考え方とは開きがある。

また、関数型の経験的にデ ー タを中心に設計したほうがよいことが分かつてきた。

また、動作中心のときは動作が正確に行われることの確認、

すなわちテストが重きをなしていたが、要求中心になると要求が実現されることの確認を行

わねばならなくなり、そのためにはプロトタイピ ン グしてみるのが 一番良い 。

もっと進んでデータとそれに関する関数をまとめてオブジェクトとしオブ ジ ェデトに

知識工学の分野では人間の考

4 人聞の問題新しい技術がいろいろと開発されてきたが 、を取り入れることができない。

はほとんど区別されていない。オブ ジ ェクト指向は人聞の考え方に近いといえる。

考え方に変われば、

データ・ベースの記述やまた、憲近の開発支援ツ ー ルにはフローや絵をソフトウェアの開発技術を向上させる上での撮大の問題点は人間である。古い技術(考え方)にしがみついている人は、新しい技術(考え方)

え方のモデルとしてフレ ー ム・モデルが提唱された。現在オプジェクト指向とフレーム ・ モデル

第四世代言認はこれまでの一つの言語により記述するものと違い、要求中心になってきたので、プロトタイピングが盛んになってきたのではないだろうか。

データに対し低レ ベルのアクセス関数を用意しこれを通してのみデータの 7 クセスをするというデータ抽象の考え

同時に、

普は

今はプログラムの作成が容易になって意識の変革が必要である 。

動作中心の考え方から要求中心の

自然に新しい開発技術を身に付けるようになる。逆に新しい技術を取り入れる人は要求中心の考え方が自然と身に付〈。

∞ g 田弘同〈。戸帥ze-e

言語の内部は手続き的なので、手続き型の言語の特徴を引きずることになる。

今盛んになってきたのはなぜだろうか。

きちっと設計しないとプログラムは作れなかったが、きたのですぐ動くものが作れる。

関数型の言語は入力と出力を中心にコンビュータの動作を記述する。

画面の記述のために複数の表現法からなる。

要求を記述することが中心になり、

コ ー ヂインタヲはほとんど自動化される。無駄にり大幅に作業の効率化が望める。

れを人聞の言語に近い形にしたものが手続き型言語である。

よりプログラムを作るオブジェク ト 指向が現われた。

詳しいことは必要無

実際のプログラムとこのドキ s メントの聞には食い遣いが生じやすい、分かりにくい(ソフトウェ 7 技術者はドキュメント記述が苦手であ-~<r.働かし方を褒わす

コンビュータコンピュータは 一 時に一つのこと し かできないので、ウォータホール型の作業はプログラ

ムの作成を中心とし、人聞の要求をコンピュ ー タに分かる形に捌訳すること(設計、コ ー デイ

え方を表現することが問題になってきているのが分かる。

方や、

あまりに論理的な言語でまた、するものとは少し遣うが、人間の知識を表わすことを目的としてエキス パ ート

ソフトウェアは、.““.

問題を持つものも多い。たとえば、要求を記述するための言語は自然 言語 が一 番良いが、自然言径 を処理するのψMW山 Y ・入 lLhh 嬬描
斗内

描けるも白が多い。

分かりやすいソフトウェア

またまた考えさせられましたがしかし、現時点では自分なりの知夏のプログラミンングワークショップ

ln 八ヶ岳'88

識で十分に業務をこなしているという自負もあり複雑な気持ちで
した。

期

間

863.8.31( 水)863.9.
3(土)但し、現時点での自身の業務にはあまり関係ないけれど新しい知識を吸収するんだという気持ちに切り替えるとわからない言葉(株)日本情報開発山田

良 一に対しでも反応が良くなった様な気がしました。話の内容(チユートリアルの内容)にしましでも、今日においても部分々々ではありますが講義の内容が鮮明に思い出されます。 それだけ、嬬描
弘、 ψ、山岨Y ・入|、 hhN

第 6 回

イン

パク トが強かったものと思われます。

今後、続けて参加しようとは正直思いませんが、 でも若い人達
今回のワークショップに参加して実感した事は、雑誌等で言葉を知っているだけではだめだと言う事でした 。
-“血・

まず最初に思った事はこれにつきました。
初日、 2 日目に行われたチュートリアルにおけるが数多く参加する上では意義が有る事と思います 。
今後の運営に期待致します。
最後に私事ではありますが私感を述べさせて頂きます。

ワー

クショップ 2 日目 ， 3 日目のメインでありますグルー プ 別討論にエキスパ ー トシステム

おいて討論参加に対する強制に対し何を期待しているのか、個人

オブジェクト指向

的には自分でテーマを選んだ訳であり各人目的をもっての参加でについて各々、寺野孝雄氏( 電力中央 研究所)、柴山悦哉氏(東はあると思いますが、

京工業大学 ) 両氏の講義を拝聴致しましたが、部分々々でとう理しているのか今回のワークショ ップ の姿からはあまり感じられま

角卒、解釈 し て良いのか判断に苦しむ機な言葉が出ると表面上だけ

せ ん でした。

の知識だけではこれからのソフトウエア開発業務は成立しないのグループ全体 ・ プログラム委員が何を期待

この様な感想、 を持ったのは参加者中私 一 人かもしれませ ん が、
それでも一人いたという事実は認めて頂きたいと思います 。

マ毎のパネルデイスカッションにおいても追い打ちをかけられ 、

以上今後の運営に期待して終わりとさせて頂きます。

ωg目白凶40F帥 Z 。・@

かなとふと考えさせられました。更にプログラム委員によるテー

管理に役立つ情報 シ ステムは、間聞と直結した形で、意思決定支媛を 志 向するものである.情報システムは利用者が理解でき、手元の意思決定に結びっく情報を作り出す必要がある.情報 シ ステムは、機械中心ではなく、人間中心に考える必要が早稲田大学

事務システムセンター

井

上

文

人

一 昔前のデータ処理の適用業務は、ほとんどが数字をザクザク踏み砕く、記録保ある.システム設計者は、えてして峨係とお友達になり、人間の設偉から遥げようとしがちである.

おわりに一一一一一一一一管の適用業務だった o ft近の適用業務はデータ処理というよりも、もっと情報処理を志向したものになってきた.そうした適用業務は依然として記録保管の適用業務

今回のワークシ a ッ プにおいては、専門的な言葉を理解するのがやっとで、オプであったが、かなりの説明が必要なデータではなく、管理周の情報を鍵供するもの

ジ ェタト指向や 4GL 等を使って、システム磁針云々までは、到達できなかったがだった.

どのような方法にせよ機械の入口だけは、人間味溢れる人聞にしてしまうまで、さ管理面でのすぐれた意思決定を支緩するには、当初は利用できるデータが少な過W 凶 Y ・、んlLhh 泊鴨池'
斗向M山J久司佳o=þ -c，、事こまざまな問題が緩くでしょう.

-個胴・ぎた.情報の急糟 lとともなって、利用できるデータは豊富になり、多すぎることも少なくない.だが、すぐれた意思決定の支優に向いた形にはなっていないデータである.データは管理上の意思決定に役立つよう、圧繍して正確な情報にする必要が

以

上

ある.
データ処理に1ftわる人々は、データの収集・貯蔵・表示について比較的うまくこなしてきている.しかし、意思決定のためのデータを作り出す面では、それほどう
まくいっていない.これは、必要性を上回るデータを管理者が得ていること、受け取ったヂータについて彼らが理解していないこと、本当に必要なデータを得ていな
いことなどによる.

表した形式ばらないデータがあると助かるというのが典型的なケースである.コ ン
ピータの作る報告書は、大型の、鋪象的な内容の、表形式のものが普通で、これは問題の解決や保留しているものに役立ったとしても、ほんのわずかしか役立たないものである.こういう行き遣いがあっては、コンビュータの報告.を使う気にはならなくなる.

ωg田弘 -deF
制 ze・@

管理者にとっては、手元の意思決定にすぐ応用できるような、個人的な、 言葉でテムが、エンドユーザの眼にふれるまでに、かなりの期間を必婆としている。この結果、出来上がったシステムはエンドユーザにとって使いにくく、したがって期待はず

早稲田大 学れの シ ステムとなる.この 点 をみても、エ ンド ユーザの要求を シ ステムに反映させる

事務 シ ステムセンター
伊1.銀の弾丸とは•連のは 、相 当 に困費量な作業であることが理解できる.

吉宮

今回のグループ討鎗では、上流工程において要求定義を作成する STP という CA
SE ツ ールを周いて、図書 館 シス テムの要求仕緩を作成してみた.

従来の文字中 心のドキュメ ン トと異なり、視覚にう ったえ るような銭法 (デ ータ
今回のワークシ a ップのテー 7 であった「銀の弼丸 J とは、どのようなものであろ

ので、要求をまとめるまでの剣聞はそれ相応に短縮されると思う.また、修正等はうか.

現在のソ 7 トウ ε7 は、 4GL というような愈新の 言語が紹介されている反面、実際には、いぜんとして COBOL 、 FORTRAN といった 言語 が作業現渇で周いられている.いわば、新旧入り乱れての、混乱の織相を 呈 しているように思えるのであ比較的容易にできそうなので、この時点でプロトタイプを行い、下流 工程に引き継ぐ
ことにより、かなりの効果が得られるものと期待できる.
STP では、 上流工程までしかサポートしていないが、今後、 下 流 工程 において
4GL 等と 一 体となった形のツールが鐙供されれば、 全工程 におけるプロトタイプが

る.

"。.

•

フローチャート等〉を周い、しかも作成の際に編集やチェ ック などがかかる ツ ー ル な

流山MW 凶 Y ・λlLhh 海猫

貧艮 0::> 弓司匝ヌL と t<l:

しかし、コ ン ビュータの出現はそれ自体まぎれもない「銀の弾丸J であったはずで可能となり、「銀の弾丸」に 一 歩近づくように思える，ある.こういった観点に立てば、 COBOL でさえ、出現 当 初は「銀の弾丸」であっ
たに遭いない.それならば、何敏今「銀の型車丸J なのか .

3. ft後にコンピュータはこれまで、 一部の専門家か、それ相 当 の知a・をもった者にしか録えなかった.その対象が、現在では徐々に広がり、あらゆる人々がコンピュータとのコ

まるで異次元の世界にでもいたかのようなワーク シ a ッ プの 4 日 聞を終え、.渇に戻 ると、そこには厳然と、現実というものが存在し、ワーヲ シ a ッ プで聞いたり、対ミ ュニケ-:，;' ø ン を求めている.

したがって、今求められている「鎮の薄丸」とは、こういったエンドユーザが銭え治したエキス パ ート シ ステムやオブジェクト指向などというものは、その~さえも見るソフトウェアのことをある 一面では指していると思うのである。今の状況は、そこえないように思える.しかし、このような環演にいるからこそ「銀の獅丸」を求める

へ向かつての 過獲期と考えられるのではないだろうか.

ことが大切なのであろう.そういった意味において、今回のワーク νg ッ プは、自分

エキス パ ート シ ステムやオプ ジ ェクト指向とい っ たものは、過 11期において淘汰さ「エ ン ドユーザが鍛えるソフトウェア」への 着実 なl ステ ッ プであると思う.

2. CASE ツ ール (S TP) について

従来のシステム開発の問題点として、.昧な要求をシステムエン ジ ニアの経厳や能力に願って シ ステム化しているという 一 面があった.しかも、術祭しようとする シ ス

以上mg 目 m出 deF帥 Ze・@れてしまうものかもしれないが、にとって非常に意味深いものであり、また復野を広くもてるようになったと思う.

4 技術.課題と問題状況.あるべき姿と現状(テーマとしてとりあげられた技術を通じて)

SEA88][ 町ワーク シ a ヲプ AFTERPOSIT1 0N

問題紋定の視角
三井銀ゾフ ト ウエアサーピス酬

立木勲
このたぴのワークショップに怠加した結果を跨まえて(
1) エキスパートシステム①フレーム『知繊 j を個々人から抽出し、断片的、部分的なそれを整理し統合し公共のものとし、錐もが再利用可能なかたちにする筏術

今回の怠加を大まかに再整理しました.
②『エキスパートシステム』の現水準

省略

1
. 目的

川丸M
山W 凶 Y ・入 lLhh 泊滑油

88年 1 0J! 1
38

。ゆくさき

ソフトウェ 7 開発の先進的な技術研究の動向に援しそのような技術研究を促している I 背景=時代 l とそれにより解決を はかろうとしている I 問 題状況 I をとらえる.
~ r 問題状 況 l の 一般化在 行い、日常業務の 中にそれらを見て取れるようにすることで日常黛務の質的向上をはかる

その思想と妓術の向上と普及は 、 一人一人が自らのノウハウを普遍化し再利用

可能なように整理統合し公開することを可能とし、人々の問題解決能力が飛属的に向上している社会を想定することができる。
④あしもとから問題解決におわれる日常業務では、解決の手段としての『知織』は問組が解決されるや

-U
『A
・

埋もれる傾向にある.一方で多額の資本を必要とする『エキスパートシステム』@問題解決の方 向に社会が進むものとしの追求をみるならば『知般』の一般化は潜在的には時代のニーズである。

10年 20年先のシステム開発の姿がとらえられるようになり、

いや、まさに個々の職場、経営にとって こそ死活的とも いえる課題である.

意般的な追求が出来るようになる

であればそこにみをおく私は、個々の現実をどうとらえ対処していくのか、
これからの課題とする。

2. 今回の位置づけ
フレームワークができるようにする
自分の位置 を測定 する(
2) プロトタイピング①感想

職場において今回のワークシヨ 7 プの自分なりの成果を最も感じているのが4GL をもちいたこの パー トである。

ここでふれたいくつかのものは 、 今未来にむけて業務を考えるときのポイントのいくつかをかたちづくっている。これも以降の課題としておきたい.

来整理

以上

ωg 目卸値〈 eF帥 Ze・@3
. 給総

エンティティ機遊園

斗内
Y-AlLhN 泊滑油
ψMW幽

八ヶ岳Workshop' 8
8'1 ヲト守 '::i"Y 開発におけ.æ;生産性@向上:&び品質の改善につい で骨晴ラ JFコンピ~- ~T町SUYA K
A
N
I
S
H
I

1988 . ω.30

Workshopl:多加者る前世.n トウx7開発工程町生産性仰向上j).品質町改善t'J\.!且，現在幌支~紡考えて. '17 トウ:s.7VJ欠陥を防化比要求分析紡シì.'i!.役古代総t~上滅工程t.量度!:t[(~c~ - を行う事はり可能!:tIJ.側主意点としτ 以下岬崎糊1::.

1. W~ - ~加者世資料を事前E自伝置L!欠陥fr思うところを一覧表Eしてお<.
2. ~c~ - 中E全τ町問題点を解決はうté!:.思bIll.t. PENDING事項として次回討に解決お.
3 . チエヲ ヲ以防用意してお<.
Workshopl:重量加l止後世， リ7 トウェ7開発工程院主産性田向上j). 品質町改善t:めて世.上記Lk初島-帥∞・

大変重要な切さ耐， 総りに人的負荷語大加.初人的負荷を減少さ蹴肱CASE 川明 l的，

4GL を周 l切7~':s.T.fn ト世イピシデを行或想 .1初i- ~ ~~7~を使用LkI'J . ォ i'i:s.'I ト f旨向はり 1n狗ミンf を行
去り 当事嚇特技法を駆使す.ti!Iiと感t:J::次第加.

初中古特E今国側。rkshopl:参加して学習ほCASE小島を周 ll/<技法に'J\.!述"<ðl<l.(~頁に情報処理学会肱『車両l.lヴロヅラミンチ. 削イはよ挟通問題噌針 J t取り上げ州k酒倉庫問題捌E
とり図形表現してðI<)今国側orkshoptl也STP(So ftware T
b
r
o
u
g
hP
i
c
t
u
r
e
) 1:¥"; n 怜d開発工程の上波工程凶1吃
要求定重量針宇成宮るCASE ヲー 防学習l.JWH. .:øJSTP と世今まて既E開発猛反使用組司、る DFD(Data

以上自ょう咽を.'"細分化路事はり，トヲ11j'JU)'j~7ι開発桁われ，要求仕様雌立制.

F
l
o
wD
i
a
g
r
a
l
l
l
).E
R
(
E
n
t
it
yR
e
r
a
t
i
o
n
s
h
i
p
).
S
t
r
u
c
t
u
r
eC
h
a
r
tt段使用して. Visual に表現

こうい剖ASE 小島幸周 l婦は旬 1JFl柑鏑肱要求仕様書昨成台.図形表現してl明治理解L怜< . 修正色容易Z必.こうして作成杭主要求仕様書F 槻能仕機奮を元t.4GLtc段周 l'! '7 トウェ71
n~~イピンチを行うほよ旬. 1ロタ弘司 IØU t掛仕織はる ミ胸(ttJl 明 L. 害(t対処台設考柑1る.

初他に考えhる事国CASEヲー 品在使用材際t D
F
Dj)ERté知らな{戎討;ui- トシ~7~j)人工知能t 自然E解釈して作成羽1るよ沫証役tきて紛.
結輸とL! n~ ，x7開発工程の生産性田向上j) . 品質田改善t'J\ .!U. 今まさ述々銑織々民主法華組
品会悦ζはより ， 早期実現f可能に証役恩納る.

∞帽自国留d出FF帥 ze・@

L!. 要求仕織書針午成Lτl吋むVJt紛.

川克也約、Y幽・入 lLhN 悌治

酒倉庫問題
DFD と世4 種類の基本素子f約， tlt句組み合bl!t図面を構成お矢印→ IU- 9 岬流h損害.デー世7ローと呼&:.
丸印O国チ-9 町処理を表害.10l!^と呼~.

二重線ー省一時的にずー'を格納口事〈場所 . 77 イ此呼ぷ
正方形口白況対外都線量織F人を表守. 1ン7i7iè呼ぶ
体文脈図(トップレベル)

-個@・

DFD
出庫指示書

積荷票

る

ωg 目色}〈。戸胸Z 。・喧

ー ソフトウ z ア開発的 r .の現丸J を求めて ーロ生産実績管理機能
ロラインモエタ一機能
ロエラー ・ リカパリー機能

加えて、これら 4 つの基本機能にも共通点がある。画面部分(グラフィ y ク部分)と外部通信部分{対 シ ーケ ン サ)である。

昭和 63 年 9 月

ここで通信を主に今の HST で得策している 2基本機能事構成を挙げてみる 。

平尾 一 浩
削岡崎 Iut .J附，Hira佃 Soft伽are T
e
c
h
nol
o
g
yCo. , L
t
d
.

1
.

私 の お仕事斗向M
山V 出 Y- 入 l L hh犠 描

ソフトウェア・エンジニア リ ング技法 のケース・ス タ ディ

はじめに、私自身がどのような環境でどのような仕事をしているのかを知っていただきたい。

環境

ワークステー シ ョン (SONY

N
E
I
S
;S
U
N

MAC)l 人 l 台を基本として、全ての7 シ ー ンはイーサネ ッ トにより接続されている。開発は全てこのワーヲス
テーションを開発機として使用し、実機での開発は行なっていない 。

業務内容
制御系を主として、ロポ ッ ト制御 ν ステム、生産ライン制御、生産管理シ

アプリケーション・レイヤー

ステム、開発支後環境開発、を行なっている。
-匹
A。.

!抽象化

というような理想的(一般的に見て)な環境にいながら、数多くの問題を抱えている。その問題群の解決の糸口がオブジェクト指向的アプローチに潜んでいるのではと期待をしている。

2.

ワ ー ク シヨヲプ

今回のワ ー クショップで私はオブジェタト指向の続念を頭にたたき込みたいということだけを考えていた。本などを読んだだけでは、どうしても自分の仕事に直結させることができず、私の中では表面的な"流行 Z害 " として留まっていた。

しかし、東工大の柴山先生のチュー ト リアルとグループ ・ リーダをされた佐原 (SRA)
さんとのグループ討論で少しだけ鮮明になったように感じる。以下は自分の業務を例に挙げ、感じたことをまとめていきたい。

3. 私 の お仕事 と オ ブ ジェ タト 指向

私がこれまで経験した生産管理 シ ステムはそのオーダーによりさまざまであ っ たが、釜本的な機能として{共通機能として)以下のものを挙げることができる 。

口生産条件設定機能
事実際のグループ討論ではロポット伽胸プログラム{システム)を例に挙げ、プレゼンテー

ションを行なったのだが、その話は私と同じグループの方は聞かれているのであえて違う伊lを挙げる。

図 1 を見るとわかるように通信部分を 2 階層に分けることで、デ パ イスが変わった
場合、例えば通信相手のシーケンサの機種や構成が変わ っ た場合でも社内では通常使用している通信 7 プリケー シ ョン部分を使用することで、 ハ ードを意識しない開発を行なうことができる 。 後はこれと並行して物理レイヤ一部分を.き直すだけでよい。

この考えは通信だけでなく、画面を作成するグラフィ ッ ク ・ ツ ール部分やプリ ン
ター出力部分などにも利用できる。{既に実現させている)

このようにソフト開発のなかでデパイスや特殊部分を全て抽象化することでソフト開発自体への影響を鰻小にすること ( 末端部分を抽象化する)で、その特殊部分のハード的変更や、その部分から独立した開発、テストが効 率 的に行なえるといったωg 自己}〈。戸帥20・@

ここで伊!として、生産管理システムを挙げる。事図 1 一生産管理基本構成

( 一番の収穫 }グループ討論では、各メンパーのおかれている環境とそれぞれが抱える問題の差があったため、実際は踏み込んだオブジェクト指向の話しは出来なかった。しかし、私が行ったグループ内でのわずかなプレゼンテーションに対する佐原さんとメ ンパーの方々からのコメ ン トで随分頭の中がクリ 7 ーにな っ たように思う 。

Lとにか く 、まとめが行っている業務分野はオブジェクト指向的 7 プロー

加えて、実機と開発機を完全に分けた開発(クロス開発)を行っているとそれが自然

嬬描

HST

h

とにかくまとめると、チが非常にしやすく{同じものの繰り返しが多いため}、有効な分野だとわかった 。

htv 出 Y ・ぇ lLh
斗

ことが、結局はオブジェクト指向的なアプローチだとわかった。

とオブ ジェク ト指向型になってくる。始めに、自分がオブ ジ ェクト指向を理解できないのを繍に上げ、オブジェクト指向なんて現渇の泥臭さが感じられないなどと生意気をグループ ・ リーダの佐原さんに対し言 って しまったが、ま っ たく逆で非常に泥臭い部分をスマートに 、 楽に開発しようとした時にオブ ジ ェクト指向型が自然と入ったシステムに構築されるものと実感した。
今後の課題は ロ ポ ッ トの進 化 に伴うソフトウェアの拡張性と、同じような生産管理、生産制御をもう 11支オプジェクト指 向 的に見直し、特殊部分だけではなく 、もっと上層部までを対象として再利用できるオブ ジェタ トの作成を積み重ね、オブ ジ ェクトの組み合わせで 、 ある程度の シ ステムを構築できるように考えて行きたいと恩

-品回・

う。

一 共通基本機能部分の梼成をオブジェクト化できるように考えていきたい ー

また、これにはオブジェクト指向型言語を使用することでデータの鏑象化、情報徳蔽の強化も考えていかなければならないと考える。
結画面-Ilの弼丸がすこぉ~しだけ見 え たような気がするー

独自
ワータショップなどというものは、いかに自分の持つ問題点を解決するか 、 解決の方向をさぐるかだと誰かが言われていたが、正しくそう思う。人の話ばかり聞いていて、その話を自分に置換え、自分の抱える問題の解決まで持っていける能力のある人間であればいいが、私のような凡人には非常に難しすぎる。やはり、とんでもない事を言いながら恥を蜜き領き進んで行くしかない。

今回もグルーフ可申槍では随分晶をかいたと 喜んでいる .

ふ勺ふっふ勺 、 . ワーク シ ョッアの聡は掴事 情て ・ というやっき 11( このポジション ・ ペ ーωg目r 白凶dFFMZe-e

パーは そ れを完全に実行し て いるなあ)PAD , SPD , HCPなどの綾法を支援するためのチャート ・ エディタなどはソース フ百グラムとのトラ ンスレータを鳳意 L て 、 ソース・コードの自動生成、またソースからチャート~η逆変織までやっ てく

日本タイムシェア{練}中山聡れる . これらのチャートを設計ドキュメントとして実際に手書きで作成している者にとっては 、 樹Ullf有効なものとなる . チャート 、 ダイヤグラムなどと閉まれている以内直加、移動、変更、 開l勝ーなど哨臨作

草創立手書きではぱ糾Zかしいだけの苦痛で退屈>;cl恒業であるからだ.そのうえ 、 ソースにまて梨花F付けてく①『ソフトウエア""膨ηた民以球強ま』をどうするれるとなると{懸にの上ない.
ここ何年か DFD をサポートする CASE ツールがたくさん出てきた . DFD は要求仕様から設計の上.il

英語と日本語の摘文の遣いとして剖噛ずられることは 、 英語が「どうする、何々を J と動作をまず世齢にもってくるのに対して 、 日本語孟「何々をどうする J と事物を先に持ってくることである . この言語の栂
文の遣いを各々の民族の恩湾方法の遣いに起因するものとしてとらえたとき 、 人周の思湾によって作り出されるソフトウエアやそ杭測発技法にも遣いがあってい、いように号、ってしまう .
ソフトウエア開発のための鎌々な考え方州匂齢、ら謝1てくる . ここでもまた日本は米国の後畠を持することになる .

オブジェクト指向なる考え方も米置から鎗入されてきたわけだが 、 オブジェクト指向こそは日本から世界に向けて発せられるべき考え方て1まなかったのか?

データ欄臓、クラス、メッセージ、 メ

工程までを記述するのに有効なダイヤグラム技法である . 米国て~，;u副書生産性を上げているらしい. そこで
日本でも ・となるわけだが 、 果たしてソフトウエア・クライシスに有努除蕩となりえるだろうか?

米酒て怯 DFD をサポートする CASE ツールが登場する前から 、 事L上で DFD などのダイヤグラム技法
が使われていた . そして、その手書き夜湖傑作業の煩わしさはソフトウエア技術者の思J孝次湖utをしばしば中断させていた . だから、 DFD などをサポートする CASE ツールの登場お寺ち望まれていたわけで、 出るべくしてぞろぞろ出てきた CASE ツールであると言える . そのうえ、コンビュータを使うことでディスプレイ上でドキュメントを階層価輔由化して連関表現することができたり 、 ドキュメント上の、またはドキ

ソッドなどオブジェクト指向を語るときの単語まいろいろあるが、 ここて1恰孟大まカ糾ヰ: r ものを中ュメント聞の矛盾耳奮合をチェックしてもくれる . また 、 エディタで作成された要求・設計工程段階の情報

え方 J と定槍することにすると、は 、 辞書とか百科事典とカ塀ばれるデータ ・ ベースに蓄えられ、I!々な観点から開発中、開猪量のシステム『何々をどうする J と事物計舶に持ってくる 日本語を日常使っている日

本人がます句技化してもよかったのて'はないだろうか.

M・
-陣
A

を分析したり麟めるということも可能となる .

また 、 XEROX社の STAR とかAPPLE社の Macintosh のマンマシン ・ イ ンターフェース

だが、 日本では DFD という技法自体カ朝発現場で広まる前に、 DFD という妓法がCASE ツールに詰のひとつに「ディスプレイ上のオブジェクト(図形、テキストなど)をマウスで選択してからそれに対して

め込まれて綿入されてしまった患がある . この手のCASE ツールを導入するためには、 現状杭瀞腕湯tI、動作を指示する」というのがあるが、これなども日本語的な(? )操作方法だ.

開発体制、開発方法、 ドキュメント体系を改めなけオUまならないところも多いと思tコれる . きあ明日からこいろいろな偶発銭御坊笥妙ら謝1込んでくる . よくよく考えてみると 、 それらは考え方自体決して目新の CASE'/ールを尊入して使っていこうというわけにはL 功拾い . 何段階カめステ ッ フ・を鰭む必要がありしいようには理ゐれないもの胡まとんどである . 現実の備段での入閣の思考過程や開発方法を種々の技法にそうである . 例えば、 社内のある4規模のプロジェクトをテスト周プロジェクトにして試してみるとか、 社

照らし合わせてみると類似点を見いだせる場合も少令くない. ただ、技法・手法という形て種種して論理的内において CASE ツールて吋ポートされているダイヤグラム銭法夜放育を実給するとカめ社内努力が必要に明文化してあるかどうカ功遣いである .

である.

このように考えてみると、ソフトウエア開発の青い劇￡掛身近にいるのかも樹1ない.

しかし、こうも予想できる . tII造化手法がストラクチヤード・プログラミング言語を使うことによって浸ソフトウエアの世界においては、 OS を頑として飴来品で占められている (TRON がある?) .

透し今となっては当り前になったように、諸々のダイヤグラム技法もそれらをインプリメントした CASE

ソフトウエア産業界の「カンサイツールを使うことて官睡し当り前となってしまうのかも樹1ない .

ヤマモト Jr ハナエ ・ モリ」出でよ!

lLhN 泊鴨池'
川丸M
山Wω ぃ、.入

つれづれなるままに

新入社員数曹に DFD を取り入れている企業も出てきている昨今、 験入されてきた CASE ツール欝が今~CASE ツールについて
CASE の次にくるもの

CASE ツールと呼ばれているものには、事L上で人間がやっていること(銀法 ・ 手法に基づいた作業)をコンビュータにのせただけというものカり勺なくない.

今は事L上の銀法をコンビュータで支媛させるも叫まかりだが、 CASE の次にくるものは、 コンビュータを用いな肘l.lf成り立たないような妓法を嫌えてソフトウエア技術者たち哨附に現れてほしい.

ωg 固 m凶〈 eF帥 Ze・@

後どのように日本のソフトウエア'情を変えていくのカ嘆しみである .

発の大きな壁となって立ちはだかる .
ソフトウエアをIJ滋などと同じように人周の創作物と見なしたとき 、 プログラミング言語やコンパイラや

本質的な意妹でのソフトウエア玖湖腕プロセスというも叫シト説を書き上げるプロセスに近いと考えている . また、私の埋懇とするソフトウエア技術者創立芸術家と呼ぶべきものでなけオUまならない.

コンバータなどのツー川ま重要ではなくた式無力な休をさらすてfけである . そのとき必要となってくるツ­M立、人周知思考を助け考えを董理して匿めることを支援するものでなけオUまならない. アウトライン・プ

テーマ{ユーザカ‘らの要求、またi立パッケージ ・ ソフト伏潮発要件)が出る . 崎臨(ソフトウエア技術

ロセッサ、アイデア ・プロセッサと呼ばれるものがそれに該当する . もちろん、 このツールはソフトウエア

者)は 、 それに基づいてひとつ夜潮騒(ソフト、システム}を.き上げるわけである.登喝人物(エンテイ棚拶枕'けに使われるというものがまなく、思考を作業とするあらゆる険業の人たちに使われるべきものでティ}の設定、受婦人物煩悶郁{リレーションシップ)、登場人物の性格(アトリビュート}付けなどをある .

考えたりし:なくてはならない. イメージを匿めるためには絵コンテ(ダイヤグラム}を繍くことも必要である . 大まカ沿話の涜れを決め(篠要設計)、話と話と d澗をうまくつなぎながら(モジュール間インターフェース)、徐々に話を具体化(詳細駁計)していく . そして一応・き上がったら 、 推厳や校正をしたりスト

人間が思才活動を停止しわ曜夜り使われるべきツール.それは時代号唱臓を鍾えて存在する.
ブローチマートから始まった図表による種々の銭法は、 よりよいアイデア ・ プロセッサを生み出すて:めのhqw 幽 Y ・入|、 hhN斗
泊情論@本当のソフトウエア・ツール4拶寺1tと国境を鍾える

様々な試みとしてとらえたい.

ーリー{プログラム)に矛盾がないかチェックする(テスト 、 デバッグ) .

以上のようにソフトウエア繍開館IÞN旗のそれと厨似している.このことがソフトウエア開発においては悩みの種になってくる .

@ニューソフトウエア?

原稿依頼{システム開発依頼)が出版社(ユーザ)から入る.締め切り(納期)は来月末で、しかも原稿量(ステッフ敬) :が多い . これを書き上げるには、どうしても入手が必要だ. そこでアシスタントを雇って、VisiCalc (スプレ ッ ド・シート

ソフト)がコンビュータ上でデビューを華々しく飾ったとき、-島個・彼らに指示を出しながら作業を進めることにしたのだが、アシスタントといってもズプの素人からある程度人々はその使い易さに鴛いた.しかし、それをどういうふうに別府すれば有型炉Jのかという開閣は残った .

経般のある者までいろいろである.うまくいくだろうかと不安になる . しかし、また今後もこのような作業

そこで、量の大きな仕事が入るかも樹lないし、そのときにまた彼らに手伝ってもらわ制まならない. 今回は彼らのドウエア幌明技術と定車産されるなら 、 このようにソフトウエアを利用する妓衡を何と呼べ'í~'~ 切だろう

敏育も鮒司てやってみるか、 と備艇に取り鎗かるのだが、一人で書いていたときのようにはいカ沿い. 複Itか?

でやるのだから、まず作業分担をしなけオ1.I!ならない.そのためには愚初からストーリーを匿淀化する必要はすぐには使えない. そうしたソフトウエアを利用する技術、ソフトウエアのソフトウエアと言ったところがある . こうしたぼうカ稲がおもしろくなると思っても、途中で変更を加えることはメンバー全員の作業のか.

「いますぐ使えるビジネス・フォーム集」などというものが出されたりする .ソフ トウエアがハー

ソフトウエアとして仕組みだけは用意されていてハードウエアを意書店しなくてもいいが、 そのままでやり直しとなる場合が多い.一人て書くときにはイメージ次掴まったところから寄討齢制まよかったが今VisiCalc の次に登場したのがHyperCard であった. テキスト号喰や音などて'表現される

回はそうはいカ喝なくなった . 抱いている登場人物のイメージがアシスタントたちにうまく伝わらない. それ

分散した情報を 、 入閣の好奇心4こ基づいて結び付けるのに適したシステム・ソフトである . HyperCa

どころ材購したまま.いている者、話を勝手に変えてしまう者もいる . 締め切りだけが気になってひとりrd を利用して作られたものはスタ ッ クウエアと閉まれている . スプレ ッ ド・シートでのフォーム集に当たひとりの作業状況を把録する暇もない.

るものである .

何と坤肋切りに聞に合ったものの、 そこにはもはや芸術W泊細さなど糾すらもない. 矛盾だらけの登場人物が支鍵減製のストーリーの中をただ無網に動き回る.出版社は謝1果て、畿者は耐1る .こ んなこと

ι比のようなことは、 崎臨杭刈『合このような側まないが(二人で合作という側まあるが、その場合お互い無心も尉1ていて一心同体という感じなので一人と貝冷してもよいと考える) 、 ソフトウエア関知立プロ

ジェクト・チームでのグループ作業となるケース糾まとんどなので、そのことから発生する様々な!IIIIIカ明

つくづく使い易いアイデア・プロセッサが必要であると考えてしまう .

切帽健闘包}〈eF帥 ze・@なら緩め切りを臨ましてもらってでも量齢から一人で劃、て吋1.I!よかったと思ったときに出航成ハードウエアは電子銭衡が、 ソフトウエアはプログラミング銭衡が支えていた.スタ ッ クウエアて~j:アイ
デアが支えとなっている .

若手最後の年に若手の会に参加してただ念んとなく面白モうだったんで. C CIC決めてしまったんだけど，普段あまり考えてないととについて討愉(になるかどうかはjJlJIC して，考えてみるととが)できるのではと思ったわけ.
(鎌)SRA

実療にどん念話が出たかというととは，グループ封書店・レポートに自由っちゃうとして，問題は，

問中慎一郎『これじ φ ポジシ.ン・ベーパの・ tt il:しなんかできないじ φ ないかあ』という E と

ふと気がつ〈と 30 目的.

r若手の会にも#加してみたかったなあ』と「チラシ」をみると，今年はいつにも相して面白そう . オブジェクト指向だのエキスパート・システムだのの話を積極的にする E とはできないけど.

それで，ポジショ Y の方は別にどうも変化しなかったというととに(勝手 IC) して，

ワーク

ショップそ のものについて感じた E とをまとめてみたりする .

rC れは何とか#加しなければ』とばかりに書いたポジショ y ・ス

テートメ Y トが C tL.私や今回の PC の一人のi!l過さん逮でやっている r SEA 環境分科会(SIGENV)J の現在のテーマ「プロトタイピ y グ」から，ちょっと今考えているととをならベたててどまかそうと思ったわけね.

1. あまりた〈さんの人と結せなかった .
ワークショップにはか念りた〈さんの人間がいたはずなんだけど，あんまりたくさんの人と話した印象がないんだよね緯般はそれなりにしたんだけど，ワークショ ップ らし〈突っ込んだ毒菌

斗向
ψM
的、山Y
岨 ・入 lLhN 泊滑油. で.実際に私が#加したのはというと. rオブジェクト指向 + aJ というタイトルが絵かによって付けられていたグループ.ま，大体そんなもんでしょう.

を満足いくまでできたという感じはしてないな.

プロトタイピングについて一つにはうちのグループが小さかったため企んだろうけど...

もう少しうま〈配分できる方法はないのかなあ.でも ，強制 しては全く意味がないしね ι"
もう一つは.たぶん多加者が妙 に大人しかったためかな全体セツショ Y の時でも何かいうの軸になるととは以下の 3 点であると考える .

は大体決まってたし(それもほとんど PC だったりする).夜の呑み会にいたっては. (え-.途
中で仮眠をとったものがいうのも何ですが) r一体在んだってみんな揃って， あんf.I:早くから寝分野気機等の収集およびその体系化てしまうんだ』と思うほど人がいなかった.

プロトタイピ y グ手法およびモの方法(自由)の盤側-色色・

E れらに基づく支援環境の盤備
まず.

'/7 トウェア開発は基本的 K プロトタイピ y グ ・アプローチをとるべきであると考える.

しかし実際にはまだきちんとした方法(自由)の裏付けがあるわけではない

現状では「適当にやるのがプロトタイピ Y グ」と言うのもあながち的外れではなく，特にうまくでき念かったシステムは全て「プロトタイプ」であると言ってすませる傾向が顕著である.とのため.目的あるいは特性から見たプロトタイピ y グの分類/整理を行

ない，かっそれに呼応した方法(倫)を墜備する必要がある .
また現実的な 11商を考えると，不明なと E ろ全てに関してプロトタイプを作成するととが，工期/工数よ併されないととが多い.
わずかの部分を対象にするととになる

そのため自然と特 K 問題になりモうなどくとの場合， プロトタイプした部分とそれができなかった部分との関係，例えばイ ;/If. フェイス部分の盤合性といったものなどは非常 K.しい問題となる.

C れに対処するための支媛環境といったものが是非必要となる.

もちろん一般的な開発支援環境/ プロトタイピ y グ支媛環境の盤備も当然必要であう.

しかし E れらの情報をどう収集し， どう体系化するかというととを一朝一夕 K決め
現在できるととは，実際のソフトウェア開発がどのように行在われているのかを客観的に見つめ，どく低レベルf.I:誤験環境を作成し，誤用を繰り返すととのみと恩われる.
プロトタイピ y グ環境の作成自体が，プロトタイピ y グ手法の擁立に貢献するととになろう .

E のあたりに関して多 〈 の方の考えを聞いてみたい.

グループによって多少違ったんだろうけど，うちのグループでいえば，封書店 K持ってくきっか
けがいつまでも絞れなかったという感じ傾られた時間しかないんだから，グループ討自由にはいった瞬間から，すぐに討泌が立ち上がるように . PC がもっと方向付けをしてしまってもよ
かったんじゃあないのか念.

(それをひっくり返すやつがいるんなら，それはその方がいいわけ

だし .. )

ただ E れはやってみたからわかったととで. j
Jl
JI
CPCIC 責任は在いんだと思う . むしろみん在が大人し過ぎる方が問題なんだな案外 PC が引っ張ると，今度は結論まで PC が用意した通りになってしまったりするかもしれ在い.

(憶かに下手 K何かいうと，何でもみんな納得されそう

在恐さはあった)
あと，全体テーマが何かあって，それをそれぞれ違う方向からまとめていって . .後に全体で討自白するみたいなやり方の方が，他のグループの話を聞く価値も高いんじゃ在いかな.今回のまとめはどとも中途半端だったみたいなんだけど

OBJ2 も LINC も HyperC町d も StP もやっ

ぽり自分でやってみなくちやわから在いから，ゃった話だけ聞いても，自分のとととどう結び付ければいいかわかんないもんなあとなかったし .

ほとんどのグループでは「銀の弾丸J まんて，言葉すら出てゃっぽり統一テ ーマが欲しい在.

3. 場所がよ〈ない最大の問題は c tL.いくらなんでも，もうちょっと夜中 K遊びにでれると E の方がい加.部屋

ん中で呑んでるだけだから安上がりだったんだけど，ゃ っぽり何か間違ってる .新鮮な環境での呑みニケーショ Y は，園陸自由をずっと進めると思う.来年はもう私は関係な〈なっちゃうけど，どとかもっといいとと見つけて欲しいな(第 2 の盛岡を見つけるんだ日

またとられたりして :ー)).

切帽曲目色}〈F。Uz 。・@り .C の際もっとも有効とされるものは現在非常 K属人性の高い各種匁臓の活用であろ
るととは不可能である

とれって，ジェネレーショ y ・ギャ ッ プなのかしら???

2. 封筒ポイントが漠然としす!!ていた.

育開発すべきシステム内容を「舗能的に分割する J ということと， r オブジェクト指向」ということは相容れないのか .

我グループでは「普段自分は，一体どのような観点から霞計を符ない，複数の人間に作業を割り撮ろうとしているのか」というととを見つめ直すととを討自由の出発点にした一つの結君臨として，

r働能的の分割するととはあまりよ〈ない」というよう在ものも出た. それに付け加えられる形で，rやはりオブジェクト指向的危方がいいJ というものもあったと思う .

c.c.の疑問が解消されないのだ.一体「彼自E的に分割する」という E とは， r オブジェ
クトを考える J というとととそれほどかけ隠れてしまうととなのだろうか.
彼自ト Cunction ..関数...

要するに， いつまでたっても「オブジェタト」だとか「オブジェクト指向」だとかいったもののイメージが，自分の中にできな〈て困っているだけの話なのだが，関数だとかCunction だとかいう場合 K は，r オプジェクト指向」とは相容れ老いものだとはいわれないよう在気がする.なぜ「彼自tiJ はダメなのだろうか.

作表する彼自色作図する俊青色編集する自民能，表涼する相豊能-色刷・

E ういったものはどうして「オブジェクト」としてみなせないのだろう.
はわからない.

c.れが私にとれは「もの」ではないからだろうか.

すると ，

ソフトウェア開発工程の生産性や品質改善について、まず第ーに上げられるのは、システム分街、舘惜樹脂博の人材の育成にあると思います。現段階では、システム分街等をはじめるにあ勺たて、該当分野の専門的システム技柿渚を置かないため(置けないというところかもしれません古今、たまたま仕事のあいた人などを当てる場合が多いようです。この様な現状では開発工程の生産性は望めないのではないでしょうか。
そこで、各専門分野のシステム分析、諮情を長期に育成することが必要になり、各システム技術者が問題解決(今回の議題として取り上げられてた多くの開発技法なども含めて〉の方法をより多く身につける事が要求されると思います。そのためにも、仕事に追われる事なく充分な焔畠習得の時間や機会を設けることや、このような開発技法をソフトウェア開発に積極的に取り入れていく餐勢が大事になると恩われます。さらに、品質改善を望むのなら、問題解決の按衡を身につけた専門の ν ステム分析技樟f者による、ディスカ y シ ョンを行
えばよりよいもの申可尋られるのではないでしょうか。
また一方では、ユーザとのミーティングを重視することにより、ユーザがソフトウェìIこ対して何を望んでいるのかをはっきりさせる事が必要だと思います。例えば、ユーザが、強いて必要とは恩われない機能を噂してくれと言うことがありますが、その機能を増やすことによって、処理速度が運くなったり、ディスクの使用量が地えてしまい、システムがユーザの考えていたものと大き
くかけはなれてしまうことが、ままあります。その様な事がないように γ ステ
ムの分析、設計時にユーザとのミーティングを充分に重ねて、機能を噌やす事
によって発生するだろう問題点をユーザに指摘すれば、ユーザの考えているものにより近いものを作れるのはないでしょうか。
このように、これからの生産性や品質の改善には、ユーザの考えているもの

川丸U
山W 凶 V・入 lLhN 泊滑油

さて，規定の 2 ベージをタ 97 したととろで，さすがにとれじゃああんまり なんで，肘織内容に関するコメ y トを最後に少し.

を うまく引き出す環境や技術が大切になり、また、その要求を実現する為の多くの開発技法を身につけて妓術者の養成が必要になることでしょう。

作表する様能を持つもの，作図する相豊能を持つもの.. .
のように言い替えればそれは「オブ ジェクト」 になるのだろうか.そうだとすれば，単なる言葉の遊び K 在ってしまう

6置かに下手 ICII能分割しでもいいシステムはできないとは思うが，それは単在る実現方法の問題在のではないのだろうか.

とのあたりをすっきりさせる E とが.当面の源題といえる .

とかいう感じで，ちょっと真面白ぶってみたけど， c.れって要するに自分の無知をさらけだしただけだったりするわけだな

まあそれはモれでいいんだけど， 何かどうもあんまりまとまった感じのしないワークショップ(チュートリアルはとってもよかったけど，)何かすど〈楽しかったという印象も在いし，すど〈勉強になったという感じでもないし ..
か在ぁ.

出張帰りでっかれてたからとりあえずは他の人がどんな rewrite してくるのかとても楽しみだったりする(と 言うか，愚初のやつみて在いから何ともいえ在いんだけど...) .
まあとにかく，実行委員長/ プログラム委員長をはじめ PC の方々，本当 K ど苦労さまでした.

参加者の方々，いずれまたどとかでお会いしましょう .

̲̲ c れってど E がポジシ."・ペーバ在ん疋ろう 固

まあいいや

e
ωg田弘}〈 eF制 Z 。・というのが私の本当の感想.

5. 情報 ネヲ ト ワー クは人間ネヲ トワ ーク
林

好一. (練) SRA

yosik回u@町a .作net

人に聞くだけで問題が解決する場合.解決までいかなくても，同織な経験を聞いて，参考にできる
渇合， そ れを傍らで聞いていて .
がある .

も し かすると自分の問題にも適用できるかも知れないと気づく場合こういったことが起きるためには，社内外での普段からの無駄話. SEA のセ ミ ナーやフォー

ラムのような場， 組織の枠を超えたネ ッ トワーク上での掲示仮 シ ステム( BBS) などが，重要な役割を

1. はじ めにこのワーク シ ョ ッ プに重量加申し込みをする際.生産性向上のためにどんな技術品t必要かを述べるポジ ション ・ ステートメントを求められた. そこで私は，プ ロ トタイピング，ひいてはものごとを試すという段階が当り前になることが，鍵であると書いた. ワーヲショ ッ プを終えた今，この考えは少しも婿るがないどころか，かえって強 く そう信じるようになった.

果たす実際，ワーク シ ョ ッ プで上記のような伊l をまのあたりにしたものである . (詳 し く は，第 4 グ

Jレープの討論報告を重量照されたいJ
現在，開発とは直後関係ない仕事をしているが， 一時期開発笥稼の人たちと交流がとだえてしまっ

流山M山、出Y ・λl 二停泊滑油を知ったりするのには，どうしたら良いのだろう .
ワーク シ賓ヲ プ 重量 加の 後に恩うことたとき，自社のシステムの7' '1 プデートの内容さえ理解できなくなり，自分の持 っ ている技術情報の少なさに浪損したことがある . 疏丘は社内の BBS システムを通じて. GNU の何なにのベ ー タ・

1. 巻の新設街

ワークショ ッ プ期間中，寺野孝雄氏による rE却ert System 入門J. 柴山悦哉氏による「 オブ ジ ェク
ト指向入門」と 二つのテ昌一 ト リアルを受けた.どちらの話題も近年興味を持ちながら . 勉強を怠 っ

パー ジョンが'* '1 トワークのどこどこにあるとか，あるプロ ジ ェ ク トのためにこんな ツ ールを作 っ たがほしければあげるとかの情報が， 座して手に入るようにな っ た.

だ尚昆然，細かい情報はメイル. ~苦，直接会うなど L て確かめなければならない.その時.人間ていたものだったので.たいへん興味深く拝聴した.
しかし，である.こういった最新技術をどうやって現湯に活かせば良いのだろう.

と し てのつながり /ネ ッ トワークが必要になる.これがなければ，メイルも胃臨も無視される可能性-品。.

がある.結局のところ . 自分一人でできることばかりではないのだから.この人間本 γ トワークの実
3 . プ ロ トタイピ ン グ

践は.オブ ジ ェタト指向の考え方や， 分散環境の構築法とも通じるところがあり . r モチはモチ屋J. あ

プロトタイピングと呼ばれる手法がある . ユーザ要求を見極めるためにユーザ ・ イ ン タフェイスの部分だけを作ってみるとか，リスクが大きいシステムの沼舌的な笥扮だけを試作してその実現可能性を見るなど，その内容は多岐にわたるが. 共通 し ているのは .r 部分だけとりあえず作って動かし，実際のシステム修築に必要な情報を得る J という こ とである . つまりタメシである .

ここに，新技術を，研究開発でない現場の開発に持ち込める可修性がある.

4.，メ シ の必然性
近頃はやりのポージョレー . )(ーボ ー. これは，通常収穫の翌年にならないとできないワインを，特殊な方法で年内に作り上げてしまったものである . 作り方はわかっている.だが日本のメーカが問機なものを作るとき，いきなり大量生産をはじめただろうか.否.まず少しだけタメしてみなければな

開発では.なおさらである .
そこでプロトタイピングの登場である.ユーザや 7 ネ ジ ャの目をかいくぐり，タメシをやるのには絶好の口実となる .

ところで.そのプロトタイピングを当然とする風潮を作ったり.そもそもそこでタメすべき新校術

種々の「モチ屋」 の知合いを抱える.これは暮らしやすい環境を確保するための重要事項である.

「モチ屋J の中にはマネ ジ ャ〈意志決定者〉も含まれる.理解と先見の明のある 7 ネ ジ ャと話せるようになってお く ことは.エン ジ ニアにと っ て〈そして組織にとって〉良い環境を得るために必須と言 っ て

良い. つまるところ.<ネジャが首を縦に振らなければ， 基本的に金も手間暇もかけられないのだ.
6. おわりにプロトタイピングをはやらせよう . だがそれは，単なる隠れみのである.本当に大事なのは，プ ロ
トタイピングを許す環境なのだ. それがエン ジ ニ 7 にとってd 暮らしやすさ Jであり，これがなくては，個人も環境も恒常的な進歩は望めない.

ωg 自民国〈。Fωze・@

らなかったはずだ. 大軍生産ではなく，そのIi:に違うものを作らなければならない受託ソフトウェア

るいは「適材適所」 という，個人の良さを最も有効に引き出す組織のー形態に当てはまる.

3.

ソフトウエアの生窟性向上について(糠)目立ビジネス彼自E

討治ではオブジェクト指向、プロトタイピング指向といった新技術について具体的に論

第 2開発部第 1 グループ

ぜられなかったが、今後のソフトウエア生産はとうした新技術を取り入れたものになって森博幸いくと考える.私の会社では数年前よりシステム設計からプログラム開発、システム保守
聞でを 一 括管理するシステム開発支鍾ツールを使い開発を行い、成果を上げている.しかし、とれも COBOL 、

PL/l といった 手 続型言穏を対象としているため、生産性向上にも限界あるのではないか思う.そこで、今回の q ークショップの中でも話題に出てきた

1.はじめに第 4 世代 言 絡が必要になると考える . 私は、近い将来 (5 年後位)には新規システム開発に
近年、高度情報社会の発達により、ソフトウエアのパックログが糟大しているといわれている.そのため、ソフトウエア生産性向上は我々ソフトウエア開発者の急務な練題であるとおいて、第 4t世代言鰭 とプロトタイピング指向を組み合わせた開発方法が主 流になり 、 ソ

込山M山W 凶 Y ・入 lLhN 泊滑油

ワーク v ヨッコ;>"/，.二番酔方口し吃ご

ソトウエア開発の生i'i性.品質は確実に向 上 するものと思う.

いえる.私は、ソフトウエア開発に湧わる l 人として各種の新しい開発技法に興味を持ち、

しかし 、 現実的な問題としてこれらの新技法を社内及びユーザーにいかにして定着させ

本ワークショップに参加した.ここでは、ワークショップでの討前内容および怠加後の視点

るかがある.ベテラン SE 、プログラマーには職人的気質が見受けられ、新技法に消極的でのソフトウエアの生産性向上について述べる.

なととろがあると思う.従って 、 我々若手が率先して新技法を取り入れていかなければならいと思う.

2.グループ前輸を通して
-A
『m
・A

4.

おわりに

本ワークショップはテーマが「銀の型車丸」というととで.各種の具体的な新技訟について
グループ討輸およびディスカッションを行ってきた . その中で私のグループはリーダ佐原伸
さんもとでオブジェタト指向、プロトタイピング指向について討険した.

私は入社以来、メインフレームのユーザプログラムの開発、保守に従事してきた為 、 ソフ
トウエアの生産性向上については興味があり、参加したわけであるがオブジェクト指向、プ

残念ながら本ワークショップでは、私の仕事にすぐに役立つものはなかった.しかし 、

現在考えられているソフトウエアエンジニアリングの掻先織の技法について学びまた、他社の方々と交流出来たことは大きな成果であった.
また 、 私を含めメーカ一系の参加者はごく僅かである反面.ソフトハウス系の方々の参

ロトタイピング指向とは何かということを十分に理解せずに参加したため討論についていけ加が多かったと思う.今後は、メーカーの方々も積極的に参加してメーカーの立ーーから.

るか内心不安であった . しかし、グループ討諭は私の不安に反して、交流が主な目的の様な新技術について意見を交換してほしいと思う.

気軽なものであった.

最後に、ソフトウエアエンジニアリングはこれからますます進んでいくと思われる.私第 1 日目は、各人の現状の仕事から問題点在鐙起しその中から新技術が使えるものを望書しは既存の技術にとらわれることなく前向きに新しい技術を取り入れていきたい.

たが、全員とも新技術を使う以前の問題に直面していることがわかりテーマとは少し雌れた方に討自由は展開した.

一以上ー

第 2 日目は.気分を変えてレンタカーを使い清里方面へ出かげ討自由した.討諭内容は前日Card の講習を佐原さんから受けた.感想としては「メインフレームではこう簡単にプログラムは出来ないのに、ワークステーションは進んでいるなあ J が実感であった.

最終日は各グループの発表であり、当グループはテーマを若干無視して討論過程と結論について発表し、最後に Hiper

Card の感想を私が発表した.

私は全体の肘輸を通じ.また各人の問題点からソフトウエア生産方法はまだまだ発展途上であるなと感じた.本討自白では「銀の弥丸 J は見つからなかったが、今後の仕事に参考になるものであった .

∞帽困層包-4己・帥Z0・@のつづきで問題点への対応についてで、テーマとはあまり関係ないため、明日の発表について少し不安になった.その夜 、 テーマに関係のある Hiper

においである。だから、ネ ッ トワークが落ちたり、自分に関係のあるマ シ Y が落ちたりするととても困る。でも、普段はそんなととちっとも気 ICL ていない。

各種文書作成、プログラムの作成、デバッグ、テスト、各種情報交換、スケ ジュール管理、勤SEA 夏のプログラミングワークショ ップ '88 に参加して株式会社 S貼環境開発部
桜井麻里
m 町 iOsra.junet

1.概要

今回のワークショ ップ は、テーマがあって在いようなものだった。私は、そう いうのも好きである。

参加前には、ソフトウェア開発の方法書店と、 CASE -;t ールについて見知らぬ人と怒り合おうと務報告書の管理念ど日頃の作業はほとんどワークステーショ y上で行なっている 。
2 .2 . 業務内容

私は、入社以来4 年半、ず っ と UNIX 環境下で、事務アプ P ケー シヨンの開発支援ツールの作
成/保守/デモ y ストレーショ y をしてきた。現在は、米国の企業で作られたリアルタイム情造化分析手法を支援した CASE -;t ーん の日本語化/デモ Y ストレ -Y3 Y /サポートを担当している。

要するに、私は UNIX と MS-DOS しかさわったととがなく、 UNIX 文化にド ッ 7・ 9 つ かって

流山MW 凶 Y・入 lLhh 婦描ているし、プ 9 y !J も別のマシ Y についている。情報交換に欠かせないニュースもjJ lJ のマシ y

異文化体験いたわけである。ただし、 HyperC町d や SmaUTalk など、最近話題になっているものは、身近に使っている人がいて、実物もよく見ていたので文化と L ては知っていた。

思っていたのだが、結局、rLINC の実習を通して 4GL を使ったプロトタイピ Y グについて考える』というグループに参加して、 LINC を使った 。 informix-4GL を使ったプロトタイピ ングなら、仕事で体験して、有用性も鴛めていたので、 4GL を使ったプロトタイピ y グについては、いまさらE量輸するととはなかったが 、 LD河C には興味があ ったし、一度ぐらい訊用後を使ってみるのもいいだろうと思って、とのグループを選んだ。

結果的には、私は、参加したグループの中で異端児となってしまったし、グループ討論を在地、在かかみ合わないものにさせる E とになってしまった。グループの皆さん K は 大変申し訳ない E と

‑
A
R
‑
‑

をしたが、日頃、自分が味わうととのできない異文化を体験したととは、私にと って有意義て・あった。

とのペーパーでは、モの異文化体験のー織と感想を思いつくままに述ベ、ワーク ショップの参加報告とする。

2. 会社における私の作業環境と業務内容

異文化について路るためには、まず、私の属している文化を説明しなければ在らな い。 それを いちいち説明するととはと とでは無理なので、私の作業環境と業君事内容について、簡単 K紹介する 。
2 . 1. 作業環境

私がいるフロアには、 1988 年9 月 20 日現在、机 72 偲、 SONY- NEWS37 台、 SUN3 台、そ の他のUNIX ワークステーショ y5 台 、 Macintosh シ 9 ーズ 10 台、 SmaUTalk 用マシ y4 台、 LJSP マシ y

人ぐらいが仕事をしている。
私は、モの中の一台の NEWS のピ ット マ ップディスプレイを占有して いる。主在コマンドはとの NEWS にあるが、プロジェクトの 9 "J -Ã は別 ~NEWS にあるし、かな 漢字変換のサーバーはまた別の NEWS だし、パックアップをとるのに必要なストリーマも別の NEWS につい'いうまでも在〈 、 電子メイル、電子ユユースの E とである .ミーティングのお知らせや報告、 各積質問事項のやりとり、意見交換在ど、きまざま牢情報交換は、たいていメイんやニ~ースで行在われる.今や E 札を在〈して、仕事はでき tν、.

上記の よう在わけ で、私は、汎用機も半二軍端末も使ったととがなかった。今回、汎用後で
LJNC を使うというわけで、 LJNC 以前にいろんなととに感動してしまった。思 いつくままにあげてみると以下のように在る。

3.1.半=量骨量末と汎用恨のこと・キーボードにキーがた くさんついている t

処理録作のための重要なキーが、たいてい、ホームポジシヨ Y から遠 くはな れたとと ろにある 。 あれでは、疲れてしょうがない。

- 頼みもしないのに行番号がついて く るテキスいエディ夕、デ ィスプレイの右下端に必ず表示されるカー ソルの位置は、"符番号や桁位置に重要な意味のある 言憶を対象としているんだ
ゾ"という自己主張をしていた。 C ， Pascal , L阻p ， SmaU同Ik ， Prolog ，日本語，英癒在どを編集するのには、行番号や桁位置は不要だからだ。ゃっぽり、汎用僚というのは、事務処理!アプリ
ケーショ Y実行専用慢だ。

・ 半二重端末であるというととが、アプリケーショ y のユーサ・ィ y ターフェースの構築 K 多大
在影響を及ぼしているというととがわかった。あれで、快適なユーザイ y !J ーフ ェースを持った開発環境を倒築するのには、か在り無理があると感じた。

3.
2. L1NC のこと

・よ 〈考えられて作られている。あの前援に乗っ取った作業をする限り、使い易 ν、。 LJNC の考
え方は、どととなく UNIX IC通じるものがあるように感じて、私には、在じみ易か った。きっと、 L目、IC は、使いたい人が自分たちのために、作った ツ ーんなのではないかと思 った。そう思って資料をよく読んだらやっぽりモうだった。 10年ιL上前から、モの核はあ ったそうだ。
・少な くとも、旧バロースのマシ yJ司土の環境の中で使われる分には 、 とてもよくできている。

あれで、機末非依存、メーカ非依存であれば、すどいのに。 でも、そうな ったら、あそと まで一貫したサポートはできないでしょうね。

・はじめて使った汎用慢のソフトが LINC で幸せだねとグループリーダの佐藤氏にいわれた。
私も、そん在気がする 。

∞市回目mロ〈己・“z 。・@

l 台、 PC9800 シリーズ 28 台、レーザプリ y !J 3 台、レーザライタ l 台があり、乙れらの多 くはイー
サネットで結ぼれている。 PC98 は VAX や NEWS ~ど UNIX マシ y の端末として使われている。社内の他都円、社外ともつながっていて、 JUNET を通じてメイルやニュー ス 1て'tì"ri事交換ができる。コピー俊一台、ミニコピー俊一台もあって、いつでも使える。とのフロアでは、常時 50

3. 異文化体験

グループ肘倫のまとめは、他でやっているはず在ので、 LL では省時。

幸ム以外の全メ Yバは、 4GL 初体験だった。プロトタイピ Y グの効用も知らなかった。みんな、
LINC のよさは øめたものの、自分が関わっているような大規模システムの開発には使えそうも在いと感じていた。モ E で、私は、大鋸模システムだと何が大変なのか、どうして LINC のよう嬬描

の OHP が完成した。朝の 5 時だった。

、A hN

なものでは使えないと感じるのか、という E とに関して質問して、問題点を引き出す役をするととになってしまった。か〈して、輸点は、だんだんずれてい君、一時アプナイ雰囲気に在ってしまった。どうなるととかと心配したものの、みんなの努力 κ よれやっと合意が見られ、発表用

流山MW 凶 Y -九|

U . グループ討歯車の こ と

4. おわ りに

グループ前理由には、 LINC の実習のためについてきて下さった、日本ユユシスの営業の片山氏
も、ずっとつきあって下さった。調陣織の方向修正守、 OHP 作成についての適切なアドバイ Z をいただき、本当 K助かりました。どうもありがとうどざいました。

無料で LINC を使わせて下さった日本ユ ニ シ Z の方々、 LINC を使えるように交渉して下さった
長野協同電算の佐藤さん、ワークショップを運営して下さったプログラム養員の方々、どうもありがとうどざいました。そして、ー絡に肘諭 K つきあって下さったグループの皆様、おつかれさまでした。また、何かの僚会にお会いするととがございましたら、気軽に声をかけて下さい。

それから、私にとって一番面白かったのは、実は、はじめのチュートリアルでした。面白いお話-陣
A@・

を聞かせて下さった電力中研の寺野氏、東工大の柴山氏、ありがとうどざいました。

5. おまけ. ワークショップは、ゃ っ ぽり、おいしいど飯が食べられるととろがいい!!全員一緒の食事も悪〈はないけど、メユューが決められているのは、ゃっぽりつかれます。自にー食は、好き主食事をしたかった。来年は、ゃっぽり、盛岡 K しましょうよ。

・ ワークショップのーヶ月後に行主われたデータショウの会場で、偶然、あの片山氏 K お会いしました。グループ前輸の感想をお聞きしたら、「いやあ、だんだん自分の立場がわから在くなっていきましてね土、疲れましたよ。」とおっしゃっていました。片山さん、本当にど苦労さまでした。

@
切 gE 包}〈。FMZ 。・

流山MW 山岨Y ・入 lLhN 泊滑油

ソフトウェア開発プロセスの探求
三重E電信セミコ Y~ クタソアトウエア株式会社

鰐ー技術部ツール眼健峨山亨

はじめに

1

私の所属するグループの寮君事 位、マイ ク ロコンピ ュータ用アプ H ケーシ~ Y プログラム開発

支慢ツーんの開発および技術サポートを行う E とである.本レポートで位、開発業島の現状および開発効率向上への取り組み方について述べる.

2 開発の現状
マイクロ コ y ピュータ用開発支援ツール開発除、 IX の点で汎用マイクロヨ y ピュ-~用のそれと大曹〈異在っている。
(1)

マイクロコ γ ピュータの 9 9 ー スと同時 K :;Iーんもリリース L 在ければならない(2) . 限価かっー定レベルの懐舵を有す1:1:
従って、 '/7 トウェア開発を非常に短期間で完了し在けれぽ在ら在い。マイクロョ y ビ ュー

図 1 開発プロセスモデルの精進図

タ用のツール開発で は 、実際 K マイクロコ y ピュ ータを 動作させ在がら ツーんの評価を符わね-me・ばなら在い鋤合もあるので、量盛附のマイタロョ y ピュータを使用して半ば航行錯際的 K 開発

4 効率化の手段を符わねば在ら在い E ともある.また、守イクロコ Y ピ a ータ量E量的からアプ 9 ケー ションプ
ロ グラム開発 K 入る 顧客のため、 ツールの方も間に合わせの未完成品を出荷する楊合もでて〈る。

E の ように問 K 合わせ的 K :;I ーんを開発してい〈と、開発行程 K 書Lれが生じ結果的 K 生 m性が低下する E とに在 り 、製品の品質低下 K もつ在がる E と K 在る 。そ E で、私遣は、ソフトウェア開発のプ ロセスを的障に把狸 L 、 '/7 トウ %7 の生m性.信頼性を高める E とを考えた。

従来、私遣が '/7~ ウェア開発手法を園自国ーする楊合、その主題はデバ ッグ方法であった.つまり、コーデイ Y?'完了後いか K してバグを収束させるかという E とが重I!~テーマであ った.しかし、 '/7 トウェアの品質を向上させるためには仕線i&1tから入念 Kfj わねば在らない 。
E の E と K 気づいた E とが、プロセスモデルの噂入につ在がったといえる。
仕織設計の段階で開発物の品質を決めるI!図は何であろうか. 1 つにはプロトタイピ ングがあげられると思う。新規開発の多い私遣のグループで位、プロ'タイピ Y?' が開発プロセスの3 開発プロセスの把握
実際 K 私遣が11(みようとしているのは、図 1K 示すよう在プロセスモデルをつ〈りましょ在かで特に重要であると考えている。そのためにはどのよう在ツーんを用いるととができるのだろうか。

E の解はまだつかめてい在い。現在模索中であるというのが、正1Il~と E ろである。

う、そして各開発符程の在かで在すベき E とを明 .K しまし￡う、というものである.従来は 、各開発工程が明衝で在かったため、 '/7 トウェア仕様の検肘や評価についても充分 K 時間をか
吋てい在かった.また、各工程で何を在すベきかという E とすら各人が Z耳目白していなかった。
E れでは '/7 トウェアの品質位、向上しない.まず、開発工程をピジュ 7"'K するととが大切

細目40∞市節目包}〈
F。
・@であると考えたわけである.

側ユニテック

3.

LINC を体験しての感想

東京営業所

4GL を飽織する為に LINC という開発環境を体験しました.DISPLAYIこ画面を、第 2 システム課望月好光

伽戎していく、それによって DB の定義体及びトランザクション舵哩周プログラム、トランザ

クション管理ソフトウエ 7 を生成し、オブジェクトまで作ってしまう.まずは・凄い'と思いました.

これならばプログラ 7 ーは必要なく 、 コンビュータを知らないエンドユーザーカt

ワークショップに重量加するにあたって

システム開発してしまう事が LINC では可能ではないカ\私自身プログラム開発の 7 ネジメ

ワークショップに重量加するにあたって、ポジション・ステートメントを書く為に重量加募集内だろう、と感じました.

ント作業を行っているものとして、こういった作業ゆ必要なくなり、ヵ、なりの工数IJIJ減になる

川丸h
山ψ、 山 V ・入 lLhh 為猶

主芝 α-:>7- ロクーラミンク'・ワークシ冨ツフ・省壬爺冬えι てご

容に 5 つの 7 プローチカ寝泊iされていました.しかしこの 5 つのアプローチの意味蝿揮できませんでした.開発技法という事で記述されていたので、現樹予っている金融・領保などの、

4. 進化型プロトタイピングの課題

汎周憾にアプリケーションの開封触というより、工程の中の l つであるテスト仕様書につい
LINC に象徴されるように進化型プロトタイピシグの必朝生というものを、プログラム委ていかに効率化していくカヰこついて書きました.

員でありリーダーである佐藤さんカ苛錨期されていましたカt 私自身プロトタイピングというよ

しかし、後で送られてきたテキストの中のエキスパート ・ ~ステム及びオブジェクト指向を読んでいる内に、 5 つのアプロ ー チがどのレベルのものであるかカ電磁軍でき、自分カ匂書いたポり雛形というイメージのものしか使った事がないので、理解するのに時間カ切かりました.

ジション ・ ステートメントとは全く違うレベルのものであると気がつきました.

自分なりに考えてみて、最終的に進化型プロトタイピング =実システムであるならば、プロ
トタイピングにかなりの柔制凱泊要になってくるだろうし、 4GL がどこまで対応し、 3G

胴回・-

L より簡素化していけるカ\という事が今後の課題になっていくような気がします.

COBOL の7 プリケーションの世界しカ知らない自分にとって技術の失織を行く 5 つのア
プローチについて、全〈未知の世界であるカ<ì!iい将来必要になってくるものであるので、このワークショップでそれに携わっている人途の話を聞き、どれか 1 つでも窓拐し視野を少しでも

5.

4GL の未来

広げていく事を目掻に重量加しました.
近い将来必ず 4GL の時代は来ると思います.しかし、今は一部のマシンでしカ側発できな
い、 DB の利用方法カ報られている、既存とのインターフェースの陪盟、柔制主に欠ける点、

2. デスカッションにおいてなと宮輔は多々有ります.これから改良されて全ての課題がクリ 7 された時、 4G しが『銀の弾丸J の如くこの世界に殴り込みを賭けて来る事は間違いないでしょう.

グルーフ唱す諭を行うにあたり、プログラム委員による 6 つのテーマについて説明がありました.各テー 7 ともにプログラム委員の方の確カ:した考え方があり、どれも面白そうだったので

私は今例凋憾による 3GL でのシステム開発を行っています均九すぐ後ろには 4GL が迫っ

すカt その反函テー 7 が大きすぎてつかみどころがないようにも感じられました。

ているといっても過言ではないような気がします。

また質疑応答など自然してきで各アプローチで専門周語カ領ぴ交い、私自身理拐に苦しむ内

容カ多々ありました.

6.

ワークショップを終えて的に話がまとまりきれてなかったように思いました。グループ討論する時間が足りなすぎたよ今回ワークショ ッ プを終えて一番印象に残った事は、同じコンビュ ー タの世界で仕事をしても自分の知らない分野で仕事している人達の話カ吻近で聞けた事です。しかし、聞くばかりでうな気がします。

その人途の話の中に入り込む事ができず、自分だけカ~り残されているような気がしました。
私はユニシスのマシンで LINC を体験したいと思い r4GL によるプロトタイピイング』に重量加させてもらいました.

LINC を体験し 4GL 及びプロトタイピング G創出!)について話合う渇に重量加できた事など、有意義なグループ討論でした.

これからは、もっと先を見ていかなければ 4G しなど次の世代に対応して行けなくなるのではないカ\と自分に対して危捕憾を感じました.
以上ωg 目 色 -deF帥 Z0・@

討槍後の内容を聞いてみて思った事は、まずオブジェクト指向 +a のテーマの中で +aカt

何であったのカ\オブジェ H の現状及び今後の課題はどうなのかが明確でなかったなど、全体

要求仕種定義からの白書コーディングを2!t;Jτ(稼)岩手電子計算センター
藤村洋

4まじめに

(1)プログラム仕様書で記述した内容とほとんど同じ内容をプログラムにコーディン

グするようなものであり、漏れなくコード化しているか不安であるし、記述漏れが発生する可能性がある .

(2)プログラム作成時に追加記述した内容をプログラム仕様書にフ ィ ードパックする
さいに意識的に人聞がメ ン テナ ン スをしなければならないため記述漏れが発生する可私は過去に日立製作所の SPDS を利用してあるシステムを開発したことがある . 定め

泊滑油
流山MW 出 V・入|、 hhN

2 プログラム仕穣書からプログラム作成時の問題，'/õ';i.〆:シ g ンズデー;.〆ン メ

能性がある .

られたフォーマ ッ トのドキュメントをまとめていくだけで設計書ができ上がることは大変効率的ではあったが 、 手書きをベースに作業をするため、信頼性とメンテナンス性に

3 システム開発中の顧客対応時の問題問題があるように思う . また 、 設計内容を顧客に確認してもらうためには、プログラム-胴M・を作成して、テストフェーズを経てからでないと出来ないため 、 かなり時聞がかかり問(1)開発の途中経過を仕様書として顧客に提示しにくいし、その資料を作成しでも開題である.ここでは、いくつかの間題をピックアップして、期待する開発環境を考えて発は進行中なので 、 すぐに陳腐化してしまう .

見る .

(2)設計内容を顧客に確認してもらうためには 、 テストフェーズを経てからでないと

1 要求仕援定着書からプログラム仕様書作成時の問題(1)要求仕様定議書で記述した内容とほとんど同じ内容をプログラム仕様書にも転記出来ないため 、 開発期間待ってもらう必要がある 。

4 要求仕援定重量からの自動コーディングシステム

している . そのため記述量が多いし、記述漏れが発生する可能性がある .

すぐに、実現できるかどうかはともかくとして 、 望まれる開発環境システムを次ペー(
2)織能単位に記述されている要求仕鎌定義奮の内容をプログラム単位に分解する作ジの図をもとにを考えてみる .

(1)基本とする考え方(3) プログラム仕緩書に追加記述した内容を要求仕様定義書にフィードパ ッ クするさ(a) 情報(システム仕様)は 、 データベース化する .

いに意識的に人聞がメンテナンスをしなければならないため記述漏れが発生する可能(b) 情報(システム仕様)は、それぞれのドキュメ ン トに変換される .

性がある.

(c)情報(システム仕機)は、プログラムとして生成される .

ωg 目"巳ぐ eF"ze-e

業が繁雑であり分類漏れが発生する可能性がある.

(自動コーディング)

最後に要求仕後定義をもとに 、 プログラム仕後書、システム仕様書を作成するためにはエキスパートシステム的な考えを必要とするであろうし 、 自動コーディングのためには 4
GL の発展が必要であろう .
現在の、鉛筆による力仕事の SE という環境から 、 仕鋳けをスマートに創造する環

法なぐ剛圃Y ・入|、 AhN
泊滑油(c) プログラムを出力する.

境へと、 1 日も早く脱皮したいものである.

-胴個・(2)入力について(a)要求仕畿を入力する.
(b)プログラム仕様書を入力する.

(c) コーディング内容を入力する .

(3)処理について(a)入力された要求仕様定義書のそれぞれの内容をプログラム単位に分類し、仕様書を作成する.

(c)要求仕犠定義書，プログラム仕様書、プログラムへの修正はお互いに反映される.

(データペース化)(4)出力について(a)要求仕様定義奮を編集して打ち出す.
(b) プログラム仕様書を編集して出力する.

個。・@
ωg 目色目〈。戸一Z(b)仕鎌書からプログラムを作成する.

私達のグループでは.
側

岩手電子計算センター
吉田健裁

CASE ツールの 1 つである上流工種開発支援の StP を使用し、図書鎗システム開発を行った.しかし、StP は、実際には NEWS のピットマップディ

スプレイ上で作動するということだが、今回は装置が費量いことから、机上で StP の手法で行った.そのために、 StP のメリットの 1 つである録作性や自動生成の面を見ることはできなかったが、要求定縫決定における上流工種での多方面からの妥当性のチ z ック等

はじめに

ワークショップ."目前に鐙出したポジシヨンペーパでは、『ソフトウェア開発工種の生産性や品質の改善について、今後どんな方策を傷じるべきか』というテーマで、いろいろな梅飽があり.それらによって上流工組におげる生産性及び品質の向上に効果が期待されることがわかった. .書いて StP とオブジヱクト指向の比較まで手を伸ばしたが、白書唱した討蛤により(酒のせいという話もあるが. ..).ìl れが発散方向に向い、つい-システム分割干に怠けるユーザを含む .u・化したプロジ z クトの編成と、メンパーの役
割の明確化.

に結果を見るには歪らなかった.しかし、ワークショップの鍾旨である『結果ではなくそ

Hπo、
u山ψ
Y ・入 lLhN 鵠描岨③グループ討諭 (CAS E ツール)

ワークショップに怠加してみてのプロセスが重要である』ということからすれば、良かった. . .ことにしよう.

・プロトタイプシステムの作成.

・システム開発方法鈴、システム開発支援ツールの倹針プロジ z クトの発足.
娠後にという 3 つの方策を上げ、中でも、検討プロジェクトの発足が重要と考えていることを述べた.今回のワークショップは、いくつかの開発後訟を取り上げそれぞれの長所・短所に今回のワークショップは、0'.の殉丸』の可能性を錬ろうと、いくつかの開発技法が取り上げられた.しかし.私自身『銀の孫丸』の可飽伎を繰る前の段階で 、 開発技法のー僚-胴晶・ついてグループ肘鎗によって比鮫倹討を行うといういわばこの検討プロジ z クト的な内容を体験したに過ぎないが、現状の開発環境の把鍾に役立ち、書発されたことに..があっで行われ、その中で実際に開発主主法を体験することによって改めて重要性を再偲鎗するこ

た.また、これからは、いかにして開発環境を使いとなしていくかにあると感じづにはいととなった.

られなかった.

①プロトタイピング

前回のポジションペーパでは、プロトタイプシステムの作成によって実際にシステムを道入したイメージをユーザに示し、ユーザの滞在的な要求の引出し及びシステム分続 .ø
Itの磁留ができることを述べた.しかし、作成に当っては現状でどのような支援ツールがあるか知織を持たない私にとって、プロトタイピングの 1 つである 4GL の LINC など
は.容易に実働モデルを作成でき、仕織変更による修正も容易で、なおかつジ z ネレーシ

ョンによって自鋤コーディングしてしまうのを見て改めて知織の覇軍さを感じた.ただし、使用できる華軽量及ぴ灘入できるシステムに制限があるという汎用伎の面と、レスポンスの②オプジ z クト指向

既存の銭衡の集合であるオプジ z クト指向は、ソフトウェアの緑豊担化及ぴ再利用という面からも考えて有効な方滋鎗である.しかし、応用範囲が広〈、また.応用によって発展していくと言えるが、オブジェクトとインヘリタンスの関係のような相反する考えや、インヘリタンスの決め手になる方式が無いことなど開発要員のスキルによるところが大きく、また、プラックボックス化にも問題があるように感じた.

mg自民国〈eF帥 Ze・@面に問題があるように思った.

末次真之〔徐式会社システムプランニング〕

もっとも，これは一般的な詣で 4GLカ税五こそうなる可能性もありますが .
技術の劉ヒ唯歩? )が直狼防J ものでなくランダムなものだとすれば.結局は何をやってても危ない訳で， つまみぐい程度でい、ろんな方爾に首を突っ込んだ方が.私(たち)の延命の手

このワークショップに多加された方々は.大きく色分けすると二つに分カ寸Lると恩ゐれます .
一方は . 現在のソフトウエア業界内て1孟.最先婚と思Jわれる第四世代言語やエキスパートシステム

等の考え方に81こ-んでいるグループ.他方は.制御系 ， 事務系の逮L ヰまあるにしても従来の立てになるのではないかと今回痛感しました.

い判lにしても，自分の繍.技術，アイデアを雌(ある川靖信)すると.そ繍問カ‘ら
その人筑波蜘械化(進歩)柑W糊制変更科砂うなくなる倒，事実のようてす.

ソフトウエアの箆鳴のなかで仕事をしてきたグループ.

但し私自身この業界に入って三割こも満たない人間なので， 上のような区分古色妥当かどうか事断できませんがところで，そのようなつまみく、、をするには，今回のワークショップはな悦か良L 帳会だったと思います'/J{.初日にいきなりハイプローな話をプログラム婆員の方にされると.私と同様に.

しかし.ワークショッアのテーマとなった 4GL. エキスパートシステム.オブジェクト指向等の考え方にすんなり入っていける人と，そうでない人に大きく分カ寸lていたことは.確カ温なようで

流丸山、凶Y ・入 lLhN 泊滑油

夏のプログラミングワークショップに多加して蹟が混乱してしまう方々がいるようなので.意気込みl:tbかるのてす功久もうすこし従来の人間にとっカ功きりやすいように，共通の土俵から話をはじめてもらえればょっかたとおもいます .

す.

なお.今回のワークショ ッ プの内容そのものについては.私の顕の縛をはす守1たことで.ついて私自身は.もちろん後者のグループに属する訳ですが， 今回このワークショップに参加して-明胴・

もっとも震いたことは.先端を走っているように見えるこの業界でもこのような階層カ?できてしまうということ自体です.

いくの押ト杯でしたのて棉謹想といったも叫孟，ありません

ただ， エキスパートシステムもすでにAI 研究d減産物となるつつあるという話から.て官主一休AI とは.具体的には何をやっているのか?という疑問がわいた程度寸す .

今後もこの業界に当分いるつもりでまたコンビュータ一般の幅広吋閣で仕事をするつもりである私にとっては.大きな東織となる一方で，このままてt孟とり残されるのではという焦りも感じさせられました.

最近.日々杭湖鴫およびそれにまつわる勉強に埋もれつつあった私にとっては.今回のワーク
ショップ.""場吻国立，タイムリーな東聞置となったと思います

後暗や同僚にもぜひ多加を組めようと思いますので.ワークショップがますます耳目脳的なものとところで.従来のソフトウエアの考え方で仕事をしてきた人々は ， 今回そうであったようになるようプログラム餐員の方々の餅甜置を願っております.

なぜ.詳しい(ある川劫ゆく的役)説明を聞いても考え方のとっ州当りすらな古冷州齢なかったのでしょうか .

(私のことて寸'IJ{)

ます.

しかも ， 当事者自身(どちらの倒ともに)は.意殺して L 沿いことカ惨いとおもわれるので.
その人が，使っているソフトウエアの方法そのものによって二つのグループが.自然とできてまうことは.私(たち)にとってカ捻り重要なことだと思います.鑑婚なことを考えると.その人の仕事次糟須によっては ， いつ￠澗にその人制摘が， ほカ明立まったく通用しなくなっているという事恕もありえます.

e。・
ωg田弘同deF一個目唱

おそらく.ソフトウエアに対する考え方の基本的な持組み自体が.異なる{古い)のだと思い三菱 電機コントロールソフトウェア(検)も大きいのだが、ソフトウエア開発のためのこれらの技法に閲して殆ど知識がなか っ たの

中林 f申陣が実状である.このような状況では C A S E ツールを導入しても、成巣を上げるまでには
私は今回初めてこのワークショップに参加させて頂いたわけだが .

ワークショップという多くの金と時間が必要となる .

ものを体験したのはこれが初めてである.講演会やシンポジウム .

セミナ ー とは異なりけではなんの成果もないだろうということで.

C A S E ツールを体験してみようということになり、(Software

自由な雰囲気で移加メンバーと一緒に討論するというワークショップのあり方は素晴らし

グループの活勘方針としては.ただ穏を聞いただ

CASE ツールの 一 つである StP

through P

cture) にメンバ自身がツールになりかわり、何かある例 1111 を波宮「をしてみようといものだと思う.夜遅くまで討論したことがとても印織的なものとして心に綴っている.

いうことになった .

今後も織会があればどんどん移加してみたいと思っている.

そとで 、これにより CASE ツールの有用性を探ろうとした訳である .

とのことは私にとっては願ってもないエとであり.この作業を過して、このようなソフトウェア

今回のグループ討論では、私は第 6 グル ー プに参加し" C A S E ツール、オブジエクト
指向について考える"というテーマで討諭を行った .

私がこのテーマを選択した理由は、テーマにもあるように CASE ツールについてとても興味をもっていたからである .

S E ツールはソフトウェアのライフサイクルにおいて.要求分析.要求定義、

CA

さて 、

私の仕事の内容も会社に入った頃から比べると.上流 工 程の定めた仕傑に基づいてプロ

い る.

関して、このようなソフトウエア開発の手法を取り入れて、設 計 フェーズに対して実践して H きたいと，患っている.

f士繊綬計といったソフトウェア開発の上波工程をサポートするツールである .

グラムを惣計 、の手法があるのだということを実体験できたことがよい経験になった.今後の私の業務に製作していく業務から、上流工程の仕織を決定する業務へと変わってきてこのような上流工程の仕事は始めたばかりなので、なかなかうまく行かない事が多

もう一つのグループのテーマであるオブジェクト指向だが 、会 社のなかでも試しに二、三取り組んだ事例があるだけで、私自身の業務の中にはこのような考え方はなかった.

だたなんとなく興味があったので .

どのようなグループ活動ができるのかとてもたのしみであった.結果としては、メンバの大半がオブジェクト指向というのの考え方をきちく苦労している.その理由としては.私自身、客先の要求をうまくまとめる能力がまだまんとつかんでいなかったため、活動も中途半端なところで終わってしまったが .

だ足りないためであると考えている .

グループ活動の中で繰り返された鉱行錯鋲というものは、私にとって 、としなかったためである .

また、そのような能力をつけるような働会を得ょう

エのような時に 、CASE ツールの存在を知リ 、その内容につ-明。.

いて詳しい話を聞く栂会を嫁していた.そして今回偶然にもエのワークショ ッ プで CAS体験であったと思っている .

エのグループ活動で得られた体験を基にして、オブジェクト指向による殻計をやってみようと考えているからである .

よせ集めであり、その定義は流動的なものである .
グループ討論の中で簡単に CASE ツールについてのレヲチャを受けたのが、C A SEツ ー ルについてもう少し詳しく説明すると、今まで考案されてきた数々のソフトウェア開には、デー担フ ロ ー図

Relat

(Dataflowonsh

そして理論もほとんどないに等しいので、私にオブジェクト舟向による ill!It 作業が出来るのかは不明だが、とにかく何かを始めようという気持ちで取り組んで行エうと考えている .

従来のソフトウェア開発の方法論

Chart). デ ー タ E-R 図p) 、デ-~構造図 (Data(EntryStru c tur e ) などがある.従来は、これらの方法論を用いて人が机上で紙に絵を書きながらソフ ト ウェアの級針を行ってきたわけである.

しかし.

今後のためになる

チュ ー トリアルでも話があったように、オブジェクト指向は、いままでの既存の技術のE ツールについて知る機会があったので、迷わずこのグループに参加した.

発の方法論(銭法)の有機的な集まりであるといえる .

斗向M
山W 凶 V・入 lLh N婦噌'

ポジシヨンペーパ

C A S E ツールやオブジェク卜指向が 、私の業務に対して果して 『 銀の持丸 』 になりえ

るかどうかは、私のこれからの仕事の進め方吹第なのだが.願わくば、『 銀の梯丸 』 になって欲しいものだと期待している .

C A S E ツ ー ルは絵を書くという作業を、紙の上からワークス

テ ー シヨン上のピットマップ CRT に移したものである .
して、ある程度のチェックを行ってくれるものである .

また人が設計したその内容に対エの CASE ツールは現在 S

un ワークステーション上にて使用することが出来るそう(バイナリ

300 万円)

値段のことはさておき、エの CASE ツールが日本で広まるかという事について、討論の鍋で話題となったのだがまだまだ CASE ツールは日本では普及しないだろうという結自由になった .

というのは先程述べたようなソフ ト ウェア開発の方法論自身が日本ではあまり普及しておらず、現場の実作業に使われていないため、

CASE ツールを導入しても、それを使いこなす土績がな

いのではないかというのがその理由である.私自身の掛合を考えても.当然勉強不足の点

ωg自民国〈。F帥 Z 。・@

没頭できるので.能率的であると考えられる.

であるが、非常に高価なものである.

以上

エれにより人は設計作業だけに、)な形に 書 き下す作業が不 可 欠であり、とれは.t1"1r.機にはできない人 H日間有の活動である

形式的仕様の将来ということである 。 そして これができてはじめて形式的刊のアプローチ(あるいはそ 之の他のアプローチ )静岡大学大学院電子科学研究科

太悶

同4

lJ、生きてくるのである 。 形式的仕様のアプローチが成功して、世の中

88 夏のプログラミンクワークショップは、ソフトウェアというモンスターを倒すた

めの銀の弾丸を考・えるというテーマのもとで行なわれた . 鋭の抑丸になりそうないくつかのテーマごとのグループに分かれて討稔を行なったが.ぬは形式的行: 織のアプローチをとるグル ー プに参加l した .

山

すべてがとの方法を使ってソフトウエアを作成することにな っ たと仮定したとき、現在の 3~:p.までのプログラマーは存イL しなくなってもなお、ソフトウェア技術者(現在の意味での

,

法

設 計者、

S F
.)が起りないと叫ばれることになるのではないかと考えている e そういった.S 味で、本 当 の銀の併i 丸 l主 、能力のある人併の教育のし方なのかもしれない

入
、

〆、

~

構
描

ソフトウェアの開発の 上 流工桜・の中で、作成された設計が正しいかどうか、あるいは効
司障が良いかどうかといったことは、殺 す |・対象領械のことをよく知り、 E理解している専門の設計者の飽カに依存しており、それを評価することは尖際に稼働するシステムができあがるまではわからないのが現状である 。

この問題点を解決すベ〈能型軽されたのが形式的仕様-明日アのアプロ ー チであると考えている.形式的である、すなわち 、

シンタックスとセマンテイ

クスが正確に決められているために、形式的イ士繊はそのまま実行(インタ ー プリット)するととができ、正しさあるいは効率の良さ等が、 2宣 言 「の段階で評価できる。また、形式的であるがゆえに、設計普からプログラムを自動生成することも可能である 。 この場合、コー デイング時に侵入するパグを防ぐことにもなる 。 このような点が、形式的仕織の特長であり、十分に銀 の 弾丸 と なりえるものと思う。

しかしながら、現在のところ 、 形式的仕織の中で時間の仮念を取り倣うことが悶燦であり、銀行のオンラインシステム等のリア jレタイムシステムを記述できないという問題点がある。これは、今後の研究線題であろう 。

また、形式的であるがために、書きにくいとか説みにくいとかいう点もあるだろうが、これは慣れの問題であろう " それよりは、形式的いずれにせよ、銀の嚇丸ができたからといって、ソフトウェアというモンス世ーがそれだけで完全に伺l れるよとはないだろうと思う.銀の仰\ j.L を{占うのが人 llfl である以上、それを間違えて使うことも起こるだろう。また、それ以上に護軍基なことは‘現実世界にある非形式的(インフォーマル)な問題を計算機を使って解決するために、形式的(フォーマ jレ

FBE 島〈 egg-@

仕織 言 語の背景にある理翁の教育のほうが大切だと思う.

「銀メッキの費丸」

3. 「銀メッキの号車丸」

三菱電線コントロールソフトウェア(株)技術統括部開発課

ここで、

保"オブジェクト指向"については、今回チュートリアルとグループ討論にてその概念を自分なりに E監理することができた.それに加えて"オブジェクト指向"に対して、次の点で認識-オブジェクト指向の概念は、 C言語のまうな曾舗でのS/W開発にも注入することがで『銀の5薄軍丸」候補として"形式的仕様記述

きる.

"オブジェクト指向"を挙げ 、各候補が本当に「銀の費丸」と成りうるかの討論が行なわれた.ここで自分を取り巻く S/W生産環境を考えてみると 、 たとえ「銀の現丸」が見つかったとしても、それを発射できるピストルもなくガンマンもおらず 、 多分発射することができないのではないだろうかと考えさせられた . それなら、現状で誰にでも発射できる「鉄の現丸J(=現在の技術レベルでも有効な S/W開発支媛手段)でまずは武装したい .

・府県描

今回のワークショップでは、を新たにした .

、4

1. 「銀の費丸 J 探しから「鉄の募丸」探しへ

・λl

内海

「銀の弾丸」祭しについて少し触れておきたい.

「銀の弼丸」候補の中で、私が一番興味があったのが"オブジェクト指向"である . この法化的、幽Y「銀の弾丸』探しから得た「鉄の弾丸 J •ここで、"オブジェクト指向"の" S/W の節晶化・再利用"への適用について少し触れたい.

" S/W の部品化 ・ 再利用"にて重要と思われるのは、次の二点だと考える .
1)部品化において、いかに個々のプログラムを一つの涜とするか.
2)再利用において、必要な部品をいかに同定するか.

2 . 私の「鉄の費丸」

-胴
mw
・

「鉄の薄丸 J による武装対象として、まずはドキュメンテーションを考えたい . このドキュメント作成には結構な時聞を捌いているので、その 1 制でも時間短縮ができればしめたものである.

ドキュメンテーションに対する「鉄の弼丸」は、 UNIX ワークステーションを用いた廿off

この問題をうまく解決するのが"オブジェクト指向"の概念だと思う.
そこで、 S/Wの部品化・再利用への"オブジェクト指向"の応用を「銀メッキの弾丸」(なぜ銀メッキかというと、「鉄の現丸」より「銀の号車丸」に少しは近いのではないかと、自分自身で決め込んでいるため)として位置づけたい.

環境である.現在のところ、 S/W開発に伴うドキュメント作成は、手書き、あるいは、ワー

プロにて行なっている.修正の容易き、流用ということだけを考えればワープロでも用は足りるが、大量のドキ A メントの管理

4. 「銀メ ッキの弾丸」を用いた S/W 開発

検索という点でワープロ i主役不足である.この点に関「銀メッキ J の弾丸の材質は 、 C言語とする . この時の S/W 開発のイメージ図を次に示して 、 troff;環境では UNIX の検索コマンド、パージョン管理ツールと言ったものが使用でき 、
ワープロより数段優れている.それに加え、甘off環境の何よりもの魅力は、 S/W製作環境とドキュメント作成環境が統合化されることである.

次なる「鉄の弾丸 J I立 、 情報交換のためのネットワークである.今回のワークショップでる問題に対する解答のヒントや、今後の開発環境を考える上で大いに役立つ情報が 、 多く含

陸自{…;|]制化

まれていた.グループ討論での結論を引用するなら、 ' 人に聞くだけで解決する問題もある 'というところである.
二番目の「鉄の現丸 J を手に入れるためには、情報の入手経路が絶対に必要であるのである . そういう意味で 、 今回のワークショップで他の技術者の人との交涜をもてたことは、口径 3mm ぐらいの「鉄の弾丸 J を手に入れられたも同然である .

ι インスタンス生成=再利用|目的プログラム|ωg田島 40FωZe・@は、情報の僻地にいる私にとって魅力的な情報をいろいろと得た.この中には、直面していす.

5 . 最後に

今回のワークショップでは、「銀の現丸」を見いだすことは非常に図書量であるがゆえに 、斗htv 山 Y ・九 lLhh

ここでインスタンス生成のためのメカニズムをどうすればよいかについては 、 具体的なイメージが浮かばないので今後の課題としたい.

見いだすためには旭道な努力が必要であることを痛感した.今後 i立、今回のワークショップで受けた刺激を忘れず、微力ながら「銀の型車丸」銀しを行なってみたい.

店協
描

-胴守
個
一 Ze・@
ωg目白凶ぐ。戸'88 に参加して生産性と品質時制日本情報開発側日本情報開発

制御システム部ソフト第 2Ø

車IJ御システム節ソフト第 2線
深野寛子

深野

寛子

中央線に乗り込み、 3;自 4 日の合宿生活に参加した感想を書書留めてみました.

生産性

今回のワ-'}ショップが終了して社会生活に復帰した今、狙になったものは何だろうと思い①原材料の 置や労働者の数に対し て、製品の生産される割合.
②どれだけ多く生産するかという割合.

返しています.
一日目 、 二日目の、チュートリアル I エキスパートシステム i 、

品質

I オブジエクト指向 l を…[良・不良が問題になる]

品物の性質.
ー三省堂

拝聴しながら、(樽々な単騎の意味不明な点も有りましたが、自己流の解釈をさせていただきました}

業務上にどのようなに、関わるのかと考えました.

問}ソフトウェアの品質とは?生産性とは?

答}

無駄が無〈、早〈、パダが煩い。

確かに、競み物、聞き物としては、興味も覚えましたし、維総司事を 、自主 み返すこともしましhtw 刷出Y ・入 lLhh 嬬猫斗

SEA 夏のプログラミングワークショップ in 八ヶ岳

新明解国信辞典よりー

外部環境に左右され無い.

たが. .

-ae
・

業務上 、 すぐに役立つ内容ではありませんでしたし 、 取りあえずは 、 業務上必要に駆られて得

短期決厳.

ノウハウの蓄積.

t.lれない.

消えない o000

た知総があれば業務には支障をきたすことはありません .
この為 言葉として 、 知ることは出来ましたが、知機としての蓄積にはまだ成り得ません.

鍵

<

起

>

プラン卜の開発において、短剣聞に一定の水準のシステムを作成するという目僚が掲げられ
また 、 色々な方々と箆をして分野が同じでも 、 立喝の違いを感じました.

る.

自爆を実現する際に要求されるのが 、 効率よく作業を進めることです .
いかに、手際よく作換を進めていくかにより品質等にも・5 ・がででき ます.

今回のテーマが、前 回 、 前々回に比べ、プログラム委員会の要求するものが明確にしにくいように感じました 。

グループの成果発表の際、感じたことは、グループリーダーと着眼点が違うというものがあったようでしたが 、 何故グループリーダーは、軌道修正をしないかったのでしょうか .

グループリ -'J ーの、位置付けが、テーマの提供者だけ主のか理解できませんでした.

効率を上げる為に 、 過去のシステムで実績があるパッケージやツールを使用するのも有効なことです。
しかし 、むやみやたらにパッケージやツールの継ぎ はぎでは 、 良品と呼ばれるものはできない。
与えられた内容に対して 、 どこに着服しなければいけないか.

f司に注意しなければいけないのか 、 何を必要としているのか 、 といった点もきをつけなければならない.

そうしないと 、 せっかく苦労して生み出したものでも 、不 良品のレ ッテ ルがはられる可能性もあ取り合えず、色々な事を 、 考える嫌会にはなりました.
iU量に 、 ポ ジシ ョン・ベーパの 、 観点からは変更が有りませんので.規定のマー ジン で 、 作成
し直したものを送ります.

1列え li 、 生産性やメンテナンス性等から 、過去のシステムで実績があるパ ッケ ー ジ やツールを組込んだところ 、 新線湿のために有効な支嫌には、ならない状態となり 、 かえってデパッ 7 等に時間を浪費してしまったケースもありました .

このように 、 工数に大きな問題を与える唱合もありますが、どんなに、短いプログラムにおいても繊々な 、 問題を含んでいます.

その、問題をできるだけ的確に掴むことが要求されてきます。

ωg国広岡dFF帥 Z 。・@

るのです.

>

<

プログラムの開発手順を左に示す.一般的な問題解決について考察

慌時仕繊.

②

3基本仕織書③

詳細仕嫌.(段計書}(1) f司を実現しようとしているか 、 機能的にとらえること .
(2) どの織に後能分割されているかわかること .

③から⑤までの、工程はここでは、考えから外すことにします.

(3) 世スク聞のデ一世の涜れが明確であること.

①と②で大切なのは、要旨と目的の明瞭化 、 共有磁の定豊富、問題解(4) 9 スウ聞の制御の流れが明確であること.

決の方法ではないかと考えます.

(5) 9 スウの線量bll 因{{ プログラムを組む人でなくても蛾めるもの}(1) 全体の中のどの部分であるか明確であること

全体のデパッヲ

基本 E宣言十・と共通(
2) どの械なモ ジ ュールにより偶成されているか明砲であること.

(
3) デ -9 の入出 、 流れがアイテムレベルで明確であること。

この作集は 、 山道を歩いていて躍にある村へ行きたいのだけれど(
4) Programの液れが明確であること .

も 、 分かれ過に道しるべがなくてどちらへいったらよいのかわから⑤}が明確であること.

詳細段針②の段階では 、 実際のプログラムに則した問題解決の方法が必要
プログラミング外部(
6) 9 スクのシステムから見た位置づけが明確であること.

①の段階では、要旨と目的の明瞭化が要求される.

となってくる.

④

>

基本政計

します。

①

ソフトウェアの設計段階での考察

川完
ψhw凶 Y ・λlLhh 泊滑油問題解決とは<(5) Coding方法がみえること.

ないような気がする.

(6) Program レベルでの特異な点が明記されていること。

目標が明確であるにもかかわらず、そのための手段や方法が不明
である。

-eM
・

⑥

完成

この時、再生的に作自慢するので u なく、創造的に作業していくことが大切だと恩います.

プロずラム完成までの手順

何故ならば 、 再生的作爆は、過去の経験における方法や知織のなかから当面の問題にあてはまるものを選び出すやり方なので 、 ノウハ
ウだけが要求されることになる.

また、他人のやり方を真似するだけに成りかねない.

創造的作業とは、過去の経般に頼ることはもちろんであるが 、 そ<結自由にかえて>仕織作成の段階で 、 ムリのない仕織で 、 ムダのない位計を心がけることが大切です.

{ こ こ で 言 うムりとは 、 時間的・技術的の双方を含む

れをもとにしてまった〈街しい方法を作り出すというやり方です.

}

ムリとムダのある物を強引に進めていくと 、 その結果、ムラのある製品ができてしまう 。
具体的な方法は提示できませんが 、 常に問題点を意織して 、 慣例に鱒られないことです 。

無意識におこなうのではなく 、 自分なりの考え方を 、 意自離して作業すること 、 又 、 自己満
足で終わらせずに 、 改普しつずけていくことだと思います.
ソ フトウェアを作り続けていく上で、生産性と品質の向上は、追求されつづけるテーマだ

問題 11 面に出会ったときと考えます.

適度に量bll づけること{ モチベーション②

喝の位置を変えること{遣った角度から問題をみること③

積鍾的に録作すること④

対象の俄能的性質を吟味すること⑤

固着をさけること}

ωg自色}〈。戸帥ze・@①

言 い換えれば 、 明確な答えのないテーマだと考えます.

5thINTERNATIONALSOFTWAREPROCESSWORKSHOP
ExperiencewithSoftwareProcessMode/s
Kennebunkport , Maine , USA , 10 ・ 13 October1
989(Sρ onsored bytheRockyMountainI
n
s
t
i
t
u
t
eofSoftwareEnglneerlngincooρ eration withACMSigSoftandIEEE‑TCSE)

MarkDowson
DavidNotkin

ORGANIZINGCOMMITTEE
TakuyaKatayama MasatoshiMatsuo
DewaynePerry
ColinTully

The5thI
n
t
e
r
n
a
t
i
o
n
a
lSoftwareProcessWorkshopw
illfocusonexperienceusing(andevaluationsof)softwareprocessmodels, pa同 Icularly enactable(thatis , executableorI
n
t
e
r
p
r
e
t
a
b
l
e
)models.
Thlsexperiencew
l
l
lr
e
v
e
a
la numberofc
r
u
c
i
a
lIssuesi
nthep
r
e
s
c
r
i
p
t
i
v
eandd
e
s
c
r
i
p
t
i
v
euseo
f
theseprocessmodelsandIntheirunderlyingsupport. Amongthemoreimpo 同ant Issuesarethe
f
o
l
l
o
w
l
n
g
:
S
u
l
t
a
b
l
l
i
t
yo
fE
x
i
s
t
i
n
gModelsA.mod~l. s
h
o
u
l
db~ .
e
1
1
e
c
t
i
v
ei
n
.des.~r!~ing a~~. p
r
e
s
c
r
i
b
i
n
gaw
i
d
.
er.an~e 0
1.
a
c
t
u
a
!
.s
o
.
f
t
w
a
!
e.pr.o.ce~ses;. t
imust
a
l
s
oa
d
d
r
e
s
s̲
awide r
a
n
g
e0
1a
c
t
i
v
i
t
i
e
s
‑w
i
t
h
i
neach process includìng , in particular , i
n
dv
i
d
u
a
land group
I
n
t
e
r
a
c
t
l
o
n
s
.E
x
p
e
r
i
e
n
c
eu
s
l
n
gt
h
emodels
h
o
u
l
dr
e
v
e
a
l
:
• howusablearethemodels1
0
rg
u
i
d
i
n
gandc
o
n
t
r
o
l
l
i
n
gs
o
f
t
w
a
r
edevelopmentandmaintenance?
・ how welldothemodelss
c
a
/
e1
r
o
mp
r
o
c
e
s
s
e
s
‑
i
n
‑
t
h
e
‑
s
m
a
l
lt
op
r
o
c
e
s
s
e
s
‑
i
n
‑
t
h
e
‑
I
a
r
g
e
?
1
1
e
‑
c
y
c
l
e
?
• whata
c
t
i
v
i
t
l
e
sa
r
ecoveredInthedevelopmentandmalntenancei• whatp
o
l
l
c
i
e
s0
1i
n
d
i
v
l
d
u
a
landgroupc
o
o
r
d
l
n
a
t
l
o
nandc
o
o
p
e
r
a
t
l
o
na
r
ep
r
e
s
c
r
i
b
e
dbyt
h
emodels
and what mechanisms (
t
o
o
l
s
) andstructures are needed f
o
rs
u
p
p
o
r
t
l
n
gand/ore
n
f
o
r
c
l
n
gt
h
e
s
e
p
o
l
i
c
i
e
s
?
I
n
s
t
a
n
t
i
a
t
l
o
no
fProcessModels
As
o
f
t
w
a
r
ep
r
o
c
e
s
smodelmustbe1
u
l
l
yo
rp
a
r
t
i
a
l
l
yI
n
s
t
a
n
t
l
a
t
e
dt
oo
b
t
a
i
nas
p
e
c
i
1
i
cp
r
o
c
e
s
sd
e
1
i
n
i
t
i
o
n1
0
ra
l
l
o
rpa同 01a p
r
o
j
e
c
.
tGenerlcprocess models , which canbecustomlzed1rp
a
r
t
i
c
u
l
a
rp
r
o
j
e
c
t
sbyb
e
i
n
g
I
n
s
t
a
n
t
i
a
t
e
di
nv
a
r
i
o
u
sways , enhancet
h
ep
o
t
e
n
t
i
a
l1
0
rp
r
o
c
e
s
smodelreuse.
• whata
r
et
h
ec
h
a
r
a
c
t
e
r
l
s
t
l
c
s0
1w
i
d
e
l
ya
p
p
l
i
c
a
b
l
ep
r
o
c
e
s
smodels?
• howi
sana
p
p
r
o
p
r
i
a
t
emodel(
o
ra
p
p
r
o
p
r
i
a
t
ec
u
s
t
o
m
i
z
a
t
i
o
n0
1ag
e
n
e
r
i
cm
o
d
e
l
)s
e
/
e
c
t
e
dt
omeett
h
e
s
p
e
c
i
1
i
cneeds0
1ap
a
r
t
l
c
u
l
a
ro
r
g
a
n
i
z
a
t
i
o
no
rp
r
o
j
e
c
t
?
• whatarethemechanismsneeded1
0
rc
u
s
t
o
m
l
z
l
n
gandc
r
e
a
t
l
n
ge
n
a
c
t
a
b
l
emodelI
n
s
t
a
n
c
e
s
?
Dynamlcso
fProcessModelsandModellnstances
Process mod~ls w
i
l
le
v
o
l
v
eo
v
e
rt
i
m
e
.a
se
x
p
e
r
l
e
n
c
e accumulates , t
h
er
e
q
u
l
r
e
m
e
n
t
s change , and the
ap'pllcabi.li~y 01.a.Q,i ven. m
o
d
e
l
.
.
i
s ~~ten~ed; pr~~e~s .
.
m
o
d
e
l.I.nstance~ . .~ay ~hà~ge dl
:
.
r
¥
n
gt
h
e
.
i
fe.na~tm.~nt，
e
i
t
h
e
ra
d
d
i
n
gd
e
t
al n
o
tI
H
e
s
c
r
i
b
e
dbyt
h
emodel(
r
e
1
i
n
e
m
e
n
t
)o
rm
o
d
i
1
y
i
n
g(
a
n
do
s
s
i
b
l
y‑
c
r
e
a
t
i
n
g
)d
e
t
a
i
lt
o
accommodafeu
n
p
r
e
d
i
c
t
a
b
l
ec
o
n
t
i
n
g
e
n
c
i
e
s
.
• t
owhate
x
t
e
n
tcans
o
f
t
w
a
r
ep
r
o
c
e
s
smodelsbeevolvedo
radapted?
• ~ow..are. t
h
em
o
d
e
.
l
sv
e
r
l
f
l
!
Jd andv
a
l
l
d
a
t
e
dand whatarethemechanisms1
0
rg
a
i
n
i
n
g and uslng
feedbackonmodelusage?
• howa
r
ei
n
s
t
a
n
c
e
sr
e
f
l
n
e
dandmodlfledd
y
n
a
m
i
c
a
l
l
y
?
l
l
lbe h
e
l
da
tTheShawmutInn , Kennebunkport , Malne , w
l
l
lc
o
n
s
i
s
t0
1
Thet
h
r
e
edayworkshop , whlchw
i
n
t
e
n
s
i
v
ed
l
s
c
u
s
s
l
o
n0
1t
h
e
s
ei
s
s
u
e
sby , atmost, 35p
a
r
t
i
c
i
p
a
n
t
s
.P
r
o
s
p
e
c
t
i
v
ep
a
r
t
l
c
l
p
a
n
t
ss
h
o
u
l
ds
u
b
m
i
ta
maximum3 pagep
o
s
l
t
l
o
npaperby1March 1989 , e
x
p
l
i
c
i
t
l
ya
d
d
r
e
s
s
i
n
gone0
1t
h
eworkshopi
s
s
u
e
sand
s
u
l
t
a
b
l
e1
0
rp
u
b
l
i
c
a
t
l
o
ni
nt
h
ep
r
o
c
e
e
d
i
n
g
s
. As
m
a
l
lnumber0
1p
a
r
t
i
c
i
p
a
n
t
sw
i
l
lber
e
q
u
e
s
t
e
dt
op
r
e
p
a
r
es
h
o
r
t
k
e
y
n
o
t
ep
r
e
s
e
n
t
a
t
i
o
n
st
oI
n
i
t
i
a
t
ed
i
s
c
u
s
s
i
o
n
.P
o
s
i
t
i
o
np
a
p
e
r
s(
6c
o
p
i
e
so
re
l
e
c
t
r
o
n
l
cm
a
i
l
)s
h
o
u
l
dbes
e
n
tt
o
:
DewayneE
.P
e
r
r
y
e
l
lLaboratories , Room3D ・454
AT&T8
600MountainAve , MurrayHill , NJ07974 , USA
t
e
l
:2
0
1582・ 2529
e
m
a
i
l
:d
e
p
@
a
l
l
e
g
r
a
.
a
t
.
tcom
E
l
e
c
t
r
o
n
i
cm
a
i
ls
u
b
m
i
s
s
i
o
n
ss
h
o
u
l
di
n
c
l
u
d
ea
u
t
h
o
r
'
s1
u
l
lp
o
s
t
a
laddressandt
e
l
e
p
h
o
n
enumber.

第1回

ソフトウェア・プロセス・ワークショッフ。
参加者募集

主

催 : 日本ソフトウェア科学会ソフトウェア ・ プロセス研究会
情報処理学会

ソフトウェア工学研究会(予定)

ソフトウェア技術者協会

期日1989 年 2 月 2 日(木) ~4 日(土)

会

定員

30 名

参加費(予定実行委員長:

機械振興也会伊豆研修所(静岡県伊東市)

3 万円(一般)

8 千円(学生)

片山卓也(東京工業大学): 阿草消滋(京都大学)

実行委員

場:

落水浩一郎(静岡大学)

岸田孝一 (SRA)

熊谷章 (P FU)

久保宏志(富士通)

紫合治(日本電気)

野村敏次(日本電子計算)

二木厚吉(電総研)

松本吉弘(東芝)

ソフトウェア開発の生産性や品質を考えるさいには ， まず.いったいわれわれがどんな工程(プロセス)でどんな製品(プロダクト)を作っているのかを，はっきり認識することが必要です .

国際的なソフトウェア・エンジニアリング・コミュニティでは.ここ数年.とくにソフトウェア ・ プロセスを形式的にモデル化し，その特性を解明することに多くの関心が寄せられています.第 8~9 回のICSE では.連続して「プロセス」が会議の基調テーマ

として取り上げられ，それと関連して，ソフトウェア・プロセスに関する国際ワークショップ( ISPW) が1984年以降すでに 4 回も開催されてきました.

このワークショップから生まれた主な成果としては，たとえば，開発にともなうさまざまなリスクの管理を含んだ渦巻型のプロセ

ス ・ モデル (9. W.Bo ehm) や ， 木構造の契約型モデルにもとづくプロジェクト管理支媛環境 ISTAR (M.M.Lehman) .あるいは.

厳密なアルゴリズムによるプロセス記述を目指したプロセス・プログラミングのアイデア{し Osterwei 1.)などがあげられます .

次回のISPW は来年秋に米国Ma ine州 Kennebunkport で開かれます.また，その次の第 6 回は1990年のやはり秋に ， 今

度は日本での開催が予定されています.討論テーマの候補としては.既存の各種モデルと現実のプロセスとの対比.特定の問題やプロジェクトに対するモデルの適応のメカニズム，モデルの進化とその支緩メカニズム，モデルの自動的な解釈/実行およびそれルをペースとするプロジェクト管理，プロジェクト運営の途中での動的なモデルの変更，などがあげられています.いずれにせよ，モデルの現実への適用に関する実際の経験を参加者各自が持ち寄って.地に足のついた討論を展開しようというのが.当面のISPWの基本的運営方針です.

そういう意味では，さまざまな工業分野において，すでに世界に冠たる製造技術-品質管理技術を持ち，そのソフトウェア領域への応用を推進しつつある(? )日本からの技術的な貢献が，かなり期待されているといえましょう . そこで，今回，第 6 回の日本開催のための準備活動の出発点として.また，第 5 回

ISPW

ISPW への参加申込みを Encourage する (Position Paper の

締切りは来年 3 月 1 日)という 2 重の目的を持って.日本で初めてのプロセス ・ ワークショップを開催したいと思います.

ソフトウェア・プロセスに関心を持ち.何らかの実践あるいは研究を心鋳けておられる方々の積極的な参加をお待ちします.

参加希望者は裏面の申込用紙 (Identification +簡単なアンケート形式の Position statement) に御記入の上 .

FAXまたは郵便で，実行委員の岸田孝一氏 (SRA) 宛お送りください.筒切りは 12 月 10 日{必着}です.ただし，申込み多数の場

合には，実行委員会で Position Statement の内容を審査の上，参加者を選考させていただきますので，あらかじめ御了承ください(選考結果は.

12 月 25 日までに全申込者にお知らせします) .

制榊榊脚"裏面に申込用紙があります..........

送付先:
干 102

締切 :12月 10 日

‑ 1‑ 1 (株) SRA 専務取締役岸田孝一
TEL:0
3 ‑234 ‑2610 Fax:0
3 ‑237 ‑7006

千代田区平河町 1

第1 回

ソフトウェア・プロセス・ワークショップ

参加申込用紙

氏名:〈ふりがな〉

年齢---(あ性別:口男口女

会社〈大学〉

部門〈学剖D
住所(干

役職:

>

T
E
L
:[

内線

]

FAX: [

P
o
s
i
t
l
o
nS
t
a
t
e
m
e
n
t
:
次の 3 つの問いのいずれかに，簡単にお答えください.紙面が足りない場合は，別紙を追加していただいてかまいません.

Q 1.あなたは，ソフトウェア・プロセスの形式的モデル化や，そのモデルの現実への適用にどのような関心をお持ちですか?

Ql. あなたは，既存のいろいろなプロセス ・ モデルのうち.どれが最も現実的だ{あるいは興味深い)と思われますか?

それはなぜですか?

Q3. あなた自身の周囲にある現実のプロジェクトにおける開発プロセスは.どんな風にモデル化できそうですか?
ロセスにおいて.改善を要する主な問題点は何ですか?

また.そのプ

司、

S
e
a
m
a
i
lVoU, N0.
9

Memberetc

SEA会員状況(昭和 63 年 11 月 19 日現在)
米国

4

4

豪州

1

1

<男女分布>

ι町晶E'Aaazq

男

1451

女

78

20 以下=

20̲24
25̲29
30̲34
35̲39
40̲44
45̲49
50̲54
55̲59

=

。町組側mmwM げ時<年齢分布>

60 島L上=，a1。。唱 An4

お初81370177317@8 9 1 7 3 3 3 8 8 0 3 3 0
峻』喧
1099631412516

居ιuz

域 81471177 4 m m m

鵬<血液型分布>
A型

591

0型

447

B 型=

331

AB 型=

1
6
1

賛助会員会社名
ジェーエムエーシステムズ，日本システム.
渇
噌i111251124U4m11611

幻 343M2m219mω4M250124m4n11611

山

P2働側誤認主鯨官詑齢制酬罫主糊楚楚誌腕酬仙川棚幼僻輔

正会員の勤務地および居住地域分布

システム開発，辻システム計画事君事所.

SRA. ]}コー

PFU. 近畿日本

ツ-]}スト，東電ソフトウェア，セントラル・コンビュー
タ・サーピス，構造計画研究所， ケーシーエス ， サンピルト

印刷，日 :本システムサイエンス，富士ゼロックス情報シス

テム.

1N 情報センター，富封!.富士通ピジネス シ ステ

ム，エムテイシー，マイクロ・キャピン，東海ク P エイト，
情報 シ ステムサーピス，インターナショナル・データ・ 9

サーチ，目立ピジネス後器， アトラス情報サーピス，三菱電後セミコンダクトソフトウェア，伊藤忠エレクトロニクス，

三菱電枇富士通 B SC. 千代田製作所，村田技研，ニコシ
シ ステム，日本ピジネスデータプロセシングセンター，阪神計算センター，昭和電工コンピュータサーピス，エヌ・-m

ティ・ティ・システム，

日本情報システムサーピス，

ヒラ

タ・ソフトウェア・テクノロジー，日本エム・アイ・シー，日本電気ソフトウェア，ソニー，コマス ， 三菱電複コントロー
ルソフトウェア，インターフィールド・システムズ，ジャス
ト シ ステム，サンマイクロリサーチアソシエイツ，松下ソ
アトリサーチf~z:..-y_~

TT

s
e
a

ソフトウェア技術者協会
干 102 東京都千代田区隼町 2-12 ~科目半蔵門コーフヒ J レ 505

TEL0
3
‑2
3
4
‑
9
4
5
5 FAX0
3
‑2
3
4‑
9
4
5
4