MonthlyN
e
w
s
l
e
t
t
e
rfrom
SoftwareEngi
neersA
s
s
o
c
i
a
t
i
o
n

wω …r

…

4
A

7

目次

編集部から

1
2

長岡ワ ー クショ ッ プ報告・その 1

S
es
s
i
o
n1
: プロセス・プログラミング

2

ソフトウェア・プロセス・モデルの変遷

岸田孝一

討諭記録

野村敏次

S
es
s
i
o
n2
:技術移転

2
5
10

環境の稿集・利用と技術移転

杉田義明

1
0

討論記録

盛岡政敏

1
2

要求定重量支鑓ツ ー ル

松本吉弘 / 渡辺経 ー

設計方法論の比較評価

手書水浴一郎 / 村井進

1
8
1
8
22

OA を取り巻く運営管理の諸問題

芝原縫二

26

長野支剖設立報告

佐藤千明

28
3
0

野村行憲

34
3
7

春のセミナ一・ウィーク報告 ・ その 1

会員の声

<夏のプログラミング ・ ワークショップ> へ のお誘い
会員状況

ソフトウェア技術者筒会 (SEA) は，ソフトウェア・エンジニアの，ソフトウェア・エンジニアによる，ソフトウェア - エン

ジニアのための団体であり，これまでに日本になかった新しいタイプのプロフェッショナル・ソサイヱティたることを目指して， 1
985 年 12 月 20 日に設立されました.

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

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

代表総事:

鈴木弘

常任幹事:

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

幹事 :稲田縛臼弁護美大木幹雄岡本音晴落水浩一郎柿下尚武木村高志久保宏志熊谷章斎藤信男佐藤千明芝原雄二杉図書量明鳥居宏次中園順三西尾出能登末之針谷明藤野晃延松本崇純松原友夫丸
尾治ー水谷時雄三浦信之村井進
会計監事:

辻淳二吉村成弘

常任委員長:

岸田孝一{会誌編集)

盛岡政敏(企画総務)

吉村鉄太郎(技術研究)杉田義明(セミナー-ワークショ ッ プ)

分科会世話人環境分科会 (SIGENV) :歌代和正北村昌人回中慎一郎
管理分科会 (SIGMAN) :相沢圭一芝原縫二野々下幸治

教育分科会 (SIGEDU) :大浦洋一杉図書量明

中国順三

再利用分科会 (SIGREUSE) :青島茂阿倍正平村井進

AI 分科会 (SIGAI) :安倍昭敬梅林信之広川昭八野辺良一藤野晃延横山憲ー
ネットワーク分科会 (SIGNE可:青島茂鈴木弘野中哲

法的保護分科会 (SIGSPL) :能登末之CAI 分科会 (SIGCAI) :大木勝経寺嶋裕一

中谷多音量子中西昌武

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

丸尾治ー

CAD 分科会 (SIGCAD) : 柿下尚武
支部世話人

関西支部:白井議美盛田政敏
横浜支鄭:熊谷章林香藤野晃延松下和隆
長野支部:青柳和男佐際千明
名古屋支部 : 岩田康鈴木智西村亨

SEAMAIL 編集グループ : 大槻売人岸田孝一佐原伸沢図努実芝原緯二関崎邦夫田中慎一郎長井修治野辺良一.野晃延山内徽渡遁雄一

SEAMAIL Vo1.2 ,NO.4

昭和 62 年 4 月 1 日発行

編集人岸田孝一

発行人

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

東京都杉並区高円寺南 1-5-4

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

〒 162
500 円

高円寺サンハイツ 404

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

MessagefromE
d
i
t
o
r

SeamaUVol.2No.4

編集部から
例によっていいわけが出ていますが，多くの会員の方は読んでおられないとお待たせしました. 3 ヶ月おくれの船便です.今度は思いますので.各セッションから.チェアマンのまとめ

どんないいわけをしょうかと考えていたら，まわりからと討論記録を抜き出し，編集部で整理することにしまし

声あり:

た.

「ヤクルトのホーナーがホームランを打ちすぎて.阪

もともと，この号はそれだけを特集するはずだったの

神優勝の望みが完全に消え失せ.編集長がやる気をなくですが，懲り屋の編集長のアンカーとしての筆が進まず，した，というのはどうかしら ?J

全体で 5 セッションのうち.第 1 部として. 2 セッショ

ちなみに，事務局の N さんと関西支部屈指の暴走族 U

ンだけを収録しました(残りは次号).

さんは，熱烈なヤクルト・ファンです.
春のセミナーG∞d ~ews そして.お願い恒例のセミナー・ウィークのレポートですが，こちら

6 月中旬，ついに会員数が待望の 1000 人を突破しました(7 月 9 日現在 1035 人) .次の目僚は 2000 人です.実は.

SEA の運営予算は. 2000 人規のほうは，担当した各レポータからの原稿がなかなか出てきません.とりあえず.今回は 2 セッション分だけです.次号以降に御期待ください.

模をベースに組んであるので.そのラインに到達するまでは，赤字をイベント収入で埋めなければならないので設積す.

会員からの投稿は 2 篇.

1 つは，管理分科会の世話人

そういえば.昨年度の赤字を補うべく.急処企画され・芝原さ んからの報告です.他の分科会の方々も.なるた七夕(マネジメント)セミナーは.みなさんの御協力べくマメに報告をまとめるよう，この場を借りてお願いのおかげで大成功に終わりました.

しておきます.もう 1 つは，長野の佐藤さんからの支部

次のメジャー・イベントは. 9 月のセミナー・ウィー
クです.気紛れなセミナー委員長が.また少し.新しい設立報告です.地方支部としては.続いて.名古屋でキックオフ・ミーティングが行われました.

試み(パネルとチュートリアルの 2 本立て)を取り入れました.同封のチラシを御覧の上.

7 月末までに予約申会員の声込をぜひ (2'J引きです I ).

いくつかのアンケートや.入会申込書に書かれた会員
からのメッセージをまとめてみました(女性技術者問題

もうひとつ G∞ d ~ewsについての第 2 回アンケート.環境アンケートの結果は.

今月中に.事務局が杉並の田舎 (N さんの表現)から.

あらためて別の号にのせます)

都心(千代田区隼町)に移転します.いまのところ.

.

7

月 24 日の月例フォーラムが終わった後の週末に引っ越若手の会

し.遅くとも 8 月 1 日からは完全に新事務所で業務を始

ポジション・べーパ募集の鼠終案内です.よろしく.

めます .

新住所:干 102 東京都千代田区隼町 2 ・ 12

次号予告

藤和半蔵門コープビル 505号
電話: 03 ・ 234 ・ 9455

(FAXの番号は未定)

いままでより.ずっと便利になります.お近くへお越しの節は.お立ち寄りください.

次号は .8 月中旬(? )発行の予定.いままでの遅れを取り戻すべく.

5~6 月合併号とし.ページ数を倍唱して，長岡レポート.

1C SE 参加記，セミナー記録，会員からの投稿と.盛り沢山の内容を考えています.これで，手持ちの原稿在庫のかなりの分を消費してしまい長岡レポートますので，その補充になにとぞ御協力ください.

2 月の環境ワークショ ップについては.すでに報告書‑
1‑

ReportfromNagaokaWO
l
'k
shop

l
.2N
o.4
SeamallVo

第 2 回実霞的関発環境に関する集中討論也長岡

S
e
s
s
i
o
n1
: プロセス・プログラミング

ソフトウェア・プロセス・モデルの変遷
チェアマン

岸田孝
1.はじめにツールを統合化した「環境」の概念が多くの人々の関心

このセッションでは，米国コロラド大学の L. オスタを集めるようになり，環境を構築するさいのアーキテクーワイル教授が昨年提唱したプロセス・プログラミング

チャ ・ デザインの土台としてのプロセス・モデルについの概念[ 1 , 2] をテーマとして取り上げ，それが何をて，新しい角度からの議論が多角的に展開されるように意味しているのか，またわれわれの環境改善にとってどなった .

んな効果をもたらすのなどについて，討論することを意図した .

1984 年春以降，約 1 年半の周期でこれまでに 3 回開かれた「ソフトウェア・プロセスに関する国際ワーク

プロセス・プログラミングの根本思想はソフトウ

ショップ J(略称

1 SPW) は，そうした議論の重要

ェア開発プロセスそれ自身が 1 つのソフトウェアであり，な舞台であり，進化論モデルの新しい形である PW モデ

プログラム可能である J という一言につきる.ある意味

ル(第 1 回)や契約モデル(第 3 回) ，あるいはスパイ

でそれは，これまでに提唱されてきた一群のソフトウェ

ラルモデル(第 2 回)など，いくつかの重要なモデルがア・プロセス・モデルを統合化し，ソフトウェア ・ エン

その席上で提案されてきた .

ジニアリングの方法論に，統一的かつ具象的なフレーム

プロセス・プログラミングの概念は.昨年 1 1 月の第ワークを与えようとする野心的な試みだとみなすことが3 回 ISPWで発表され.多くの論議を呼んだきわめてできょう.

ホットなトピックである [6 ，2. なぜプロセス・モデルか?

3. プロセス・プログラミングの背景

ソフトウェア開発プロセスを形式的にモデル化することの重要性が初めて認識されたのは，

1070 年代初頭のことであった.そうしたモデル化の動機づけは.主と

7 ，

8].

「プロセス自身がソフトウェアである」というオスターワイル教授のテーゼは，一見ごくあたりまえのように聞こえる.
たとえば多くの組織で作られている標準開発手順

して.米国における大規模システム開発において続発したプロジェクト ・ トラブルを回避するためであり，こう番は，

1 つのプロセス・プログラムではないのか ?J としてまず， W . ロイス(ロッキード)や B. ぺーム (Tいった素朴な質問が，RW) によって古典的なウォータフォール・モデル [3プでも，ちらほら出たりした.

1SPWでも今回のワークショッ

たしかに，そうした古典的マニュアルの類も，きわめ]が提唱され，一般に普及した.

しかし，このモデルの現実との不適合性は.やがてメて原始的な形のプロセス・プログラムの崩芽であるにはインテナンス問題の顕在化とともに明らかになり，以後.

ちがいないのだが.プロセス・プログラミングのほんとそれに代わるものとして， L . ぺラディおよび M. レー

うのねらいは.コンカレントなマルチ・プログラムとし

B.

ての開発プロセスを，自然語ではなく，厳密でフォーマぺームのスパイラル・モデル [5] などの代案が提唱さルな言語を用いて記述し.それについていろいろな分析

れたが .決定的な解はまだ見つかっていない.

をおこなったり ， できればその支媛環境を半自動的に生マンによるソフトウェア進化論のモデル [4] や，

一方，

70 年代終わりから 80 年代前半にかけては，成しよう，というあたりにある .
その背景には.オスタ ー ワイル教授自身が 80 年代前

ソフトウェア・プロセス全体の効率化を支綴するための‑2‑

ReportfromNagaokaWorkshop

S
e
a
m
a
i
lV
o
l
.2No.4半の 5 年間を費やして行った TOOLPACK プロジェ

だの一種感情的な対立関係(あるいは反発関係)を不必

クトでの環境アーキテクチャ・デザインの経験が.しっ要に増幅してしまう危険が.常につきまとっているよう

かりと踏まえられている.

に思われる.そのことは.今回のワークショップの議論

TOOLPACK の技術的特徴は.環境を f構成する要でも，ときどき感じられた(下回参照).

素ツールや，それらが扱うさまざまなファイルの取り扱
いを.オブジェクト指向の概念で統合化しようとしたこ

4. おわりにとだと思われるが.プロセス・プログラミングでは.そ今回のセッションでは . 斎藤先生のキーノートで，この考え方をさらに 1 歩進めて，ソフトウェア・プロセスの新しい概念について，チュートリアルを兼ねた紹介をを 1 つのオブジェクトとしてとらえようとしているわけ

していただき，参加者の方々の新鮮な反応を得て . できである.

れば日本的なプロセス ・ プログラミングの可能性を探る

環境の設計とは，つまるところ.それが支録するプロ

ところまでいけたらよいと考えていた . このねらいは .

セスの設計にほかならないのであり，その意味で，オブ

ほぽ 60%程度は達成することができたと思っている .

ジェクト指向アプローチの導入によって.プロセスを目最後に，プロセス・プログラミングについての個人的に見えるよう形式化することがきわめて重要であること

感想を 2 点述べておきたい.

は，いまさら論を待たない .

わたし自身 ， 時間的にほぼ TOOLPACK と並行し

ただし，そこには.プロセスの設計者(ソフトウェアてすすめられた JSD の SMEF プロジェクトを技術的に管理する立場にあった・ エンジニア)と実行者(ソフトウェア開発者)のあい

PROCESSPROGRAMSOFTWARE
ENGINEER

9人ハ

文

国
OTHER
INSTANCESAPPLICATION。r>:件付SMEF は，わが国ソフト 業

CODE DATA

三田SW
PRACTITIONε 尺

USER

‑
3
‑

SeamaUVol.1No.4

ReportfromNagaokaWorkshop

界にとって最初の UNIX プロジェクトであり，その社

5. 参考文献

会的な成功が今のシグマ計画を生みだしたことは.よく(1)L. J.Osterweil , "
S
o
f
t
w
a
r
eP
r
o
c
e
s
sI
n
t
e
r
p
r
e
t
a
t
i
o
n

知られている . しかし，にもかかわらず. SMEF の技

f
t
w
a
r
eEnvironments" , T
e
c
h
n
i
c
a
lReportandSo

術的な遺産が，シグマにはほとんど引き継がれていない

CU.c
:
s
.324・ 86 ， University of Colorado , April

ことも事実である.

1
9
8
6 (ソフトウェア・シンポジウム 87 論文集に

それには，もちろん，さまざまな政治的理由がある[

9] .

しかし，また，一方において，われわれ SMEF

収録).

(
2
)L. J.Os terweil , "
S
o
f
t
w
a
r
eP
r
o
c
e
s
s
e
sAr
eSo
f
t
w
a
r
e
T∞"， Pr凹 . o
f9
t
hICSE

の関係者が，プロジェクトの技術的な成果を.個々のツ, March1987.

ールや環境プロダクトとは別に.もう一段抽象的に昇華(
3)W .W.Royce , "Ma
n
a
g
i
n
g t
h
e Development of

したかたちでまとめることができなかったことも，大きLarge Softw釘e 匂Istems: Co
n
c
e
p
t
s andTech.

な問題だと反省せざるをえない.

f IEEE WESCON , Au忠則
niques" , PRoc.o1
9
70(岳民. of9出 ICSE に再録) •TOOLPACK が研究開発プロジェクトだったのに

UN1X をわが業界に技術移転す

(
4
)L
.A Be
l
a
d
y& M .M .Lelunan , "ProgramE
v
o
l
u
t
i
o
n

るというハンディキャップを負っていたのだからという

f So
f
t
w
a
r
e Change", Acadernic. Pr∞esses oのは，単なる慰めのための言い訳にしかならない.

Press , 19白目

対して. SMEF は.

われわれプログラマにとって，すべてのプロジェクト(
5)B . W. 勘ehrn ，

"A S
p
i
r
a
l Model o
f So
f
t
w
a
r
e

はひとつの例題にすぎず，われわれは，その例題の解決

development

を通じて ， もっと別の抽象化されたシステムの構築の実

Softw釘e

So
f
t
w
a
r
eP
r
o
c
e
s
sWorkshop" , IEEECo
mputerSoci ety , 1984.

に与えるであろう彫響に関していえば.わたし個人は.

~

E
n
g
i
n
e
e
r
i
n
g Notes , Vol. ll , No.
4(6)M. Lelunan(ed.) , "
P
r
o
c
e
e
d
i
n
g
so
f1
s
tI
n
t
e
m
a
t
i
o
n
a
l

プロセス ・ プログラミングが今後われわれ自身の仕事

マネージャとプロセス ・ プログラムとの関係を重視した

Enhancement" , in ACM(Au忠盛t 1
986).

現をめざしているのだという命題は.国家プロジェクト
や協同開発の場合にも，やはり真実なのである .

釦d), "Pr開 edings o
f2ndI
n
t
e
m
a
t
i
o
n
a
l
(
7
)J.
W
i
l
e
d
e
n
(ed.

'
.

So
f
t
w
a
r
epr∞ess Workshop", inACMSoftw
are

ほとんどのソフトウェア・マネージャは.もともとプ

E
n
g
i
n
e
e
r
i
n
g Notes , Vol. ll , No.
4 (Au忠1St

ログラマであった . かれらは，年齢や過去の業績によっ19邸).

て現在の地位に昇進(? )し，不慣れな管理業務に従事(
8)M .Dowson(ed.) , "Pr∞eedings o
f3
r
dI
n
t
e
r
n
a
t
i
o
n
a
l

させられている.しかしながら.もし，ソフトウェア開

So
f
t
w
a
r
eP
r
o
c
e
s
sWorkshop" , IEEECo
mputer

発プロセスがひとつのプログラムとして形式的にモデル

Soci ety , 1987.

化できるなら.マネ ージ ャたちは ， 自らが熱練したプロ(
9)S.Wright , "
I
n
t
e
r
v
i
e
ww
i
t
hK
o
u
i
c
h
iK
is
h
i
d
a
", i
n
UN民 Review ， F
e
b
r
u
a
r
y1
9
8
7
.

グラミング技術を駆使して ， そのプログラムを処理(解釈あるいは具体化)することができるだろう .
もちろん，プロセス ・ プログラムは ， ふつうのプログ
ラムと同様に.たえずメインテナンスされて行かなけれ

ば実用には耐えない.実際のプロジェクトの進行をモニターしながら . このプログラム ・ メインテナンスを行なうのは，当然マネ ー ジャの仕事て'ある.何らかの高水準言語を用いたプロセス・プログラムの形式化は，相異なるプロジェクト聞における管理技術の移転をより容易なものにするであろう .

‑
4
‑

.2N
o.4
SeamailVol

ReportfromNagaokaWorkshop

第2 回

実霞的開発環境に関する集中討論

S
e
s
s
i
o
n1
: プロセス・プログラミング

討論記録
レポータ

野村敏次
をやりとりして，自分が目的とする問題を解決している

1.はじめにまずは，司会の岸田さんの挨拶から:のである.このエンド・ユーザが使うプログラム(正確には，そのインスタンス)は .デー タの処理手順をあらこのセッションの狙いは.

6 月のソフトウェア・シン

ポジウムに招待講演者として来日が予定されているオス

わすコード部分と.データをいれておくためのストレー
ジという.

2 つの部分から構成されている.

ターワイルさんが，昨年の 1 1 月にロッキ一山中で行わプログラム(より正確にいえば ，個々のエンド ・ユ ー

れたワークショップで発表し.多くの議論を呼んだプロ

ザが使うインスタンスを生成するもとになるジェネリッ

セス・プログラミングの概念について，少し詰めてみよ

クなプログラム)は，プログラマ(オスタワイルの定義

うということです.そのワークショップには.私と鳥居によれば「ソフトウェア・プラクティショナ j )の手に先生，斎藤先生の 3 人が出席しましたが，英語での討論

よって作られる.

になかなか参加できなくてイライラしました.今日は日

かれは，プログラム(すなわちエンド ・ユーザが直接本語で話せるので，楽な気持ちで議論できるのではない

利用する実行可能コード)だけを作るのではなく，各種かと考えています(笑い) .

の仕様書やテスト・データ，ソース・コ ードなど .たく

あらかじめ.みなさんの御手もとにオスターワイルささんの要素から構成されるソフトウェア・フ・ ロダクトをんが去年の春に書かれたテクニカル・レポートをお配り作っている.そのプロダクトが.

1 人のユ ー サ'によってしておきましたが，なにせ英語ですから.まだ読んでお1 回だけ使われたらおしまいになるわけではなく，何度られない方も多いと思います.そこで，最初に 30 分く

でも再利用できるのは，それが.ジェネリックなオブジ

らいの時間で，斎藤先生に解説をお願いし，その後いろェクト(対象)の形をしており，個々のユーサ'の希望にいろ質問をフロアの方から出していただいて，コーヒー

応じて，いくらでも必要なインスタンスを生成できるか・ プレークまでに全体的な概念の定義をまとめたいと考らである.

えています.そして，あと残された 1 時間半の枠内で，ところで，ソフトウェア・プラクティショナがプロダ

これからわれわれが開発環境の構築や改善を考えていく

クトを開発する過程は，けっして行き当たりばったりのとき，プロセス・プログラミングの思想がどのような彰

ランダム・プロセスて'はない.過去のいろいろな経験に響をもたらすかについて.自由に討論していきたいと思裏付けられて，標準的なプロダクトの繕造(必要な各要

います.

素とそれらの相互関係のパターン)や，それらを作って行く具体的な手順は，あらかじめ決まっている.
しかし，ふつう，そうしたプロセス(およびプロダク

2. 基調講演斎藤先生のお話の概要は次の通りであった:

ト構造)のモデルは.経験あるプロジェクト・リーダの脳細胞のなかにたくわえられており，他人にはアクセス

プロセス・プログラミングとはできない.ときには.それを他人に伝達するために，標ソフトウェアは，一度作ればみんなが利用できる.

準工程や標準ドキュメントに関するマニュアル類の作成

この場合，エンド・ユーザは，実行可能なプログラムが試みられるが.それらは不完全なものであり ， また，の l つのインスタンスとのあいだで，いろいろなデータ

自然語で書いてあるために，多くのあいまいさを含んで

2. 1

‑
5
‑

S
e
a
m
a
i
lV
o
l
.2No.4

ReportfromNagaokaWorkshop

ス ・ プログラムのプロトタイプを書こうと考えているよいる .

プロセス・プログラミングが意図しているのは，このうだが，それは，あくまで実験であり，その目標は，プ

ソフトウェア開発プロセス自体を 1 つのジェネリックな

ロセス・プログラミング言語の仕様を洗い出すことにあ

オブジェクト(すなわちソフトウェア)として客体化し，る.もちろん ，希望はある.プロセス ・フ・ログラミ ング

何らかの言語を用いて厳密かつ形式的に記述することには，このところやや停滞気味だった言語研究の分野にとよって，その再利用を容易にしようということである .

っても，きわめてよい刺激になるであろう .

いいかえれば.それは，われわれがこれまで使ってきたプログラミングという方法論を，エンド・ユーザの問

2. 3 プロセス・プログラミングの意味

題解決プロセスにではなく，われわれ自身のソフトウェ

さて.環境開発というわれわれの関心に照らしていえア開発プロセスに適用しよう ということに他ならない .

ば，プロセス・プログラミングは，次のような意味を持オスターワイルによれば.それこそが「ソフトウェアっている.

・エンジニア」のなすべき仕事であり，もしそれがうま

まず，第 1 に，それは，環境のアーキテクチャ設計にくいけばプラクティショナ」は.汎用的なプロセス

対して，プロセス指向という統一的な枠組みを与える .

. オブジェクトの特定のインスタンスを操作するかたち

これまでの環境は， U N1X でもそうだが.ツールの寄で ， いままでより効率的に開発作業を進めることができ

せ集めという感じが強かった.プロセス・プログラムを解釈し実行するのが環境の使命であるという視点は . そるようになる.

うした状況下で.環境設計者に正しい方向を指し示すも

2. 2 その可髭佐と言語のである.

ふつうのプログラムのステートメントは，すべてコン

第 2 に，プロセス ・ オブジェクトをインスタンシエイ

ビュータによって実行されるが，プロセス・プログラム

トすることで実際の開発プロセスを進めて行くとい う考の場合には.あるステートメントは搬械(ツール)によ

え方は，ツールのカスタマイゼーション機能を論ずる場って，また， }JIJのステートメントは人間によって実行さ合に，きわめて有用である .

れる.そして，ときには.こうした実行媒体のパインデ第 3 に，これからの環境は当然のことながら，分散型

ィングがダイナミックに行われる.多くの場合 ， 開発プになって行くだろうが，プロセス ・ プログラムの各サプ

ロセスを構成するサププロセスは同時並行的に実行されプロセスを解釈・実行するのは.そうした分散環境におる . もちろん，実行媒体(人間および機械)は複数存在

けるサーバ ・ ノードの役割だと考えられる.環境のなか

し，プロセスの実行は分散型で行われる.

で，どこにどんなサーバを配置するかは.きわめて重要プロセスのなかて'鍛われるオブジェクトには，いろい

な設計上の問題であるが，その答えは.その環境で実行

ろな種類がある . コードやデータ.ドキュメントなどはすべきプロセス ・ プログラムがどんなものであるか，に当然そうである.ツールもオブジェクトの一種だと考えよって決まる.

られる.ところで，ッ- ~か実行すべき機能は，何らかのサププロセスをあらわしている.サププロセスと実行

2. 4 われわれは何をなすべきか

媒体とのパインディングや.ときにはサププロセスの生

アメリカでは.すでに ARCADIA と呼ばれる共同

成が.プロセスの実行中に動的に行われるとすれば，プ研究プロジェクトがスタートし ， プロセス・プログラミ

ログラム中にそのことを記述する必要がある.すなわち，ングの概念を実用化する方向で.いくつかの大学や企業

プロセスもまた，

が実験を始めようとしている.これまで，ソフトウェア

1 つのオブジェクトである .

したがって.プロセス・プログラミング言語は.こう

技術の日米格差について，いろいろいわれてきたが，こした多種類のオブジェクトのタイプを区別して取り掻うのままほうっておけば.ますます差が開くことが予想さことができなければならない.

れる.

現存するプログラミング言語は.どれもこのような機

今回のワークショップでの強輸をきっかけに，われわ

能を十分に備えてはいない.オスターワイルは，さしあれもカを合わせて，何とか独自性を持った「日本的」プ

たり， ADA と UNIX シェルの組み合わせで，プロセ

ロセス・プログラムを作りあげて行きたいと考える .

‑6‑

ReportfromNagaokaWorkshop

SeamallVol.2No.4

3. 討論

こうして作られたプロセス・オブジェクトが，個々の以下，ほぽ時間的な経過を追いながら.今回のワーク

プロジェクトに対してインスタンシエイトされるわけだ

ショップで，どんな問題がとりあげられ，どのような意が.その前に，当然ある種のスタティックなチェックが見がたたかわされたかを中心に.討論の内容を要約して行われるだろう.プロセス ・ オブジェクトが厳密な言語

報告する.

を用いて記述してあれば.そうしたチェックは容易になる.

3. 1 最初の素符な質問

正当性の証明ができるかどうかは.プロセス・プログ

ワークショップ参加者のほとんどにとって，プロセス

ラミング以前の.ソフトウェア開発に対するわれわれの・プログラミングという「奇妙な」ことばを耳にするのリクワイヤメントが，どれだけきちんとまとめられるかは，初めてであった.そこで，当然のことながら，次のどうか』こかかっている.

ような素朴な質問が，次々と投げかけられた:

ソフトウェア・プラクティショナが.実際にプロジェクトを進めて行くさいには，ダイナミ ッ クなモニタリンー

一すべてのプログラムには.パグがある.もし，プグが行なわれる.これまで，定量的なプロジェクト管理

ロセス・プログラムにパグがあったら，開発プロセということがいわれてきたが ， どこで何をどう定量化す

スに取り返しのつかない被害を与えるだろう . いっ

べかが，はっきりしていなかった.プロセス・プログラ

たい，そのデバッグは.どのようにして行われるのミングが，もし，完全な形で書けるな ら ，その実行プロ

か?

セスのモニタリングこそが.一番正確な定量化指僚にな

現実のソフト開発では，特にトラブル発生時に，プロジェクトをどうやって終わらせるかが問題になプロセス・プログラムが無限ル ー フ・ を含む危険性につる.プロセス・プログラムの終了条件はどうなるのいては.何ともいえない . そこには，おそらくリカーシ

だろう . 無限ループすることはないのだろうか?
ー

るにちがいない.

プロセス・プログラムという形での開発工程のモ

デリングは，論理的には可能かもしれない . しかし.

プ・コールが含まれるだろうし ， あるステートメントは機械でなく，人聞によって実行されるわけだから.従来のプログラムとは話が少し異なる.

そのインプリメンテーション，つまり現実のフ・ロジ

プロセスを「プログラムする」という表現は.どちら

ェクトにおけるプロセス ・ プログラムの解釈・実行

かといえば ， 誤解を生みやすい.人間とハードとソフト

メカニズムの実現は.きわめてむずかしいのではなと一体になった仮想憶械がプロセス・プログラムを実行

いか?

するといわれると，何か . 人聞がロボットになったかのような感じを受ける.

これらに対して.斎藤先生および岸田さんからのコメ
ントをまとめると，おおよそ次のような趣旨になる :しかし設計上の意志決定を下す」とかテストの妥当性を判断する J とかいったプロセス・ステップは ，
まさに人聞がそのもっとも人間的な知性をもって行うべ

オスターワイルは ， 環浸問題を手がける以前はテスト

き仕事であり，プロセス・プログラム上では 1 種の入カ・ツールの専門家であり.彼が学界で名前を上げたのは ，ステートメントとして表現されるというのが，オスター

DAVE と呼ばれる FORTRAN のデータ ・ フロー・ワイルの考えである.

アナライザの開発によってである . したがって，プロセ
ス・プログラミングについても，テスティングとのアナ

3. 2

ロジーでものを考えているように思われる.

歴史的経鍵

プロセス・プログラミングの概念が出てきた背景を環ソフトウェア ・ エンジニアがプロセス・プログラムを境の歴史的発展の中で位置づけるとどうなるかについて ，書くとき.何もないところから仕事を始めるわけではな

昨年暮れの PSDE シンポジウムに多加した方々から.

く.何らかのリクワイアメントをもとに，過去における

次のようなコメントがあった:

開発経験を集約する形で，プロセスのアルゴリズムやプ

ロダクトの構造を設計して行く.

第 1 世代の環境といえば.まず UNIX があげられる‑
7‑

ReportfromNagaokaWorkshop

SeamallVol.2No.4が，そのアーキテクチャ上の特徴は「ツール指向」の一生を使って実験を行うということは.何等かのイメージ

言で表現できょう.つまり，環療はツールの集まりであがすでにあるのだろうが，テクニカル・レポートに出てり，それらの機能をどのように分解し統合化するかといいる例題は，単純なものばかりであり，実際のプロセス

う観点に立って.インタフェイスの統一(単純化)を図記述が.こういったアルゴリズミックな言語だけでうまり，それなり( !)の成功をおさめた.しかし，ツール

く行くのかどうかは，はなはだ疑問である.

の機能的統合という面から見ると. U N1X はあまりにアナーキーである.

3. 4

プロセス・モデルとの関係

そこで. 80 年代になって.第 2 世代の環境構築があ

ソフトウェア開発環境を構築する際に ，支媛対象としちこちで試みられた.オスターワイルたちの TOOLPてのプロセスはきわめて重要な基盤的要素である.プロ

ACK は，その代表的な例である.これらの第 2 世代のセスを的確に表現できなければ，有効な環境f構築は望め

環境における主涜のアーキテクチャはデータ指向 Jない.

であった.たとえば. TOOLPACK では，ユーザ・コマンドの名前は，ツールの徴能ではなく，ユーザが最

この，プロセス・モデルとプロセス・プログラミングの関係については，次のような意見が出された:

終的に必要とするもの(オブジェクトまたはファイルの種類)になっている.環境が，そうしたユーザの要求を

開発プロセスのモデル化については.いままでにも，解釈して，必要なツールを自動的に起動してくれるのでウォーターフォールを初めとして，進化論，スパイラル，ある.

フラワーなど.いろいろ提案されているが.どのモデル

プロセス・プログラミングの概念は，明らかにこの延も十分に現実を表現できずに行き詰まっているのが，現長線上にあるが，環境アーキテクチャの考え方は「プロ状であろう.そういう意味からすれば，どんなモデルでセス指向」に変わってきている.すなわち，ソース・コ

も自由に表現できるプロセス・プログラミングのアプロ

ードやテスト仕様のようなデータと同様に，コンパイラ

ーチは，かなり魅力的に見える.

やパーサ・ジェネレータも，環境を構成するオブジェク

オスターワイルの考えは. TOOLPACK における

トであり，それらの論理的な相互関係をあらわすプロセ

オブジェクト指向型ユーザ・インタフェースを発展させ

ス・モデルを中心に，環境を組み立てて行こうというわて，プロセス-オブジェクトをうまく整理し，コントロ

けである.

ールできれば.モデル化のフレキシビリティを高められるということであろう.

3. 3

現状では，プロセス・モデルを一意的に定めるのはむ

実体はあるのか?

ところで，このような新しい考え方は，見方によってずかしいので，プロセスの表現手段を確立することは，はハッタリに見えるし.何となく眉唾的な印象を与える

それに対する支媛環境を作る上からも，きわめて有用だものである.今回の参加者の多くも.半信半疑で討論にと思われる.

参加していたのて'はないかと恩われる.こうした人々の意見を集約すると，おおよそ次のようになる :3. 5

プロセスのメインテナンス

ジェネリックなプロセス ・ オブジェクトというアイデプロセス・プログラミングの概念は，話題性を狙った

アは.一種のメタ・プログラムを書くということに通じだけで.実体はまだほとんど存在しないのではないか.

ると恩われるが.それはだれかが 1 度だけ書いてしまえ

ただ. A 1 やオブジェクト指向に関連する重要なポイン

ばおしまいになる.

トは大部分押さられえており，その意味では非常におもただし.最終プロダクトとしてのプログラムですら満

しろい.うまく行けば.ソフトウェア工学がほんとうに足に作れないような技術の現状からいって.はたしてそ学問として認められるきっかけになるだろう.

うしたメタ・プログラムがうまく作れるのか.責任の所その意味で，オスターワイルの頭の中で，プロセス・
プログラミング言語の仕様がどの程度固まっているのか

在を雲の上に棚上げして，何だかわけがわからなくしてしまうだけではないのか，といった意見が出された.
これに対して，メタ・プログラムを 1 度書けばおしまが.興味深い.すでに，この 1 月からコロラド大学の学‑8‑

I!!!里里ReportfromNagaokaWorkshop

いという考え方は，メインテナンスを無視しているといSeamailVol.2No.4

こまでの記述が可能かにかかっていよう.

う反論があった . ふつうのプログラムの場合と同様に.

開発環境のアーキテクチャ・デザインについては.まプロセス・プログラムにもメインテナンスは発生する .

だよくわかっていないことが多いが.逆にプロセス・プ

テクニカル・レポートを読んだかぎりでは.オスター

ログラムを実行するための環境を試作することを通じて，ワイル自身，次の 3 種類のメンテナンスを区別して考え

ア ー キテクチャがわかってくるということもあり得る.

ているようだ:

いずれにせよ，これからの環境構築を考える上で.なか

なかおもしろい問題を含んでいる .
1 つは，ユーザが使うソフトウェア・プロダクトそのもののメインテナンスであり . これはふつうの意味での

4. おわりに

メインテナンスに他ならない.

以上にあげたことがら以外にも，

第 2 は，ソフトウェア ・ プラクティショナが実際にプロダクトを開発するさいに.与えられたソフトウェア・ー

プロダクトの額準構造 (S P S) が現実と一致しないという場合であり.

プロセス ・ プログラムのインスタンシェーション

とは何か?

3 番目は ， 指定されたプロセス・アルーカストマイズをどのように行うのか?

ー

ゴリズムが実際の開発作業とくいちがった場合である.

メイン・フレーマのソフトウェア-ファクトリにおける設計 ・ 製造の分難とプロセス・プログラムと逆にいえば.これら 3 種類のメンテナンスをしっかりの関連‑行うためにも，プロセス ・ プログラミングの考え方は重要だということである .

3. 6 プロセス・プログラミングの目的は?

ラム的解釈など.多彩な話題に関して.かなり白熱した討論が展 開プロセス・プログラムがなんらかの言語できちんと書され.

けたとした場合，それは人間が読むばかりでなく，当然た.

その辺のところをオスターワイル自身がどのように考えているのか . テクニカル・レポ ー トから類推すると.

3 時間が非常に短く感じられたセ ッ ションであっ新しい話題の割に.討論がかなり細かな部分にまで踏

コンビュータで処理して何かをやらせることになると思われるが，いったい何が起こるのか.

UNIX の MAKE コマンドのプロセス・プログ

み込んだ形で盛り上がったのは.わが国でも，ソフトウ
ェア開発のパラダイム変革やプロセス・モデルの改善に対する技術者の関心が高まっているからであろう .
報告者である私自身.

次のようにいえるだろう:

JSO の SMEF プロジェクトの発足当初から TOOLPACK との情報交換を通じて，プロセス・プログラムを書くことの目的の第 1 は，プ

オスターワイル教授のこれまでの仕事のついては，ある

ロセスに関する関係者間のコミュニケーションの改善で程度知っていたのだが ， プロセス・プログラミングといある . 第 2 は，プロセスの善し悪しに関する分析や計測う概念に接するのは初めてであり.いくらか戸惑いながができること，そして第 3 に.ツールの利用形態や環境

らも.何か新鮮な感動を受けた .

アーキテクチャについてのガイダンスが得られることである.

今後も，こうしたワークショ ッ プのプログラムのなかに.その時点での世界の最先端のトピックスをとりあげて，積極的な討論を行う僚会を持つことが望まれる.

これは，オスターワイルの夢であろうが，プロセス・
プログラムの記述から.環境を自動的に生成しようと考えているものと思われる.おそらく GANOALF 等のパラメトリ ッ クな環境生成のコンセプトが頭にあるものと思われる.はたしてそこまで行けるのかどうかは.オ

ペレーションの解釈・実行者としての人聞について.ど‑9‑

ReportfromNagaokaWorkshop

SeamaUVol.2No.4

第 2 回笑民的関発環境に関する集中討論泊長岡

S
e
s
s
i
o
n2
: 技術移転環境の構築-利用と技術移転
チェアマン

杉田義明
1.はじめにんどをガイドしてくれるという神話があって，上級ソフ

1970 年代における各種方法論の提唱を受けて .8

0 年代は.より具体的なソフトウェア-エンジニアリン

トウェア技術者になるためには，六法全書を活用できる
弁護士なみのスキルが要求されるといわれている.

グの実践，つまり技術移転の時代になるだろうと期待されていた.

これらは，いささか極端で特殊な事例なのかもしれな

い.しかし，全体的に見て，ソフトウェア・エンジニア

しかしながら.ワークステーションの急速な高性能化

リング研究の最前線と，現実世界の開発現場におけるそA 1 .知識工の応用や実践の状況とのあいだに，かなりのへだたりがに代表されるハードウェア技術の進歩や.

学を初めとする周辺技術の話題の豊富さに比較すると，あるというのが実態であろう.

実践的ソフトウェア技術の展開スピードはきわめて遅く，また地味なかたちであって.一般の目からは.技術その2. 環境における銭術移転

ものの進歩があたかも停滞しているかのように.見える.

一般に，技術の成熟には. < 研究 ・開発移転>といわずかに，デマゴーキッシュなプログラマ 60 万人不う 3 つの段階がある . そしてまた.移転段階は. <選択足説が一人歩きをはじめ，産業界・教育界にさまざまな・導入 ・統合 ・広報>という 4 つの段階に分かれる.教思惑を抱かせながら ， ソフトウェア産業の未来に対する育訓練や各種マニュアルの整備は.技術移転プロセスの社会的な関心をいくらか高めているだけにすぎない.

最後の部分であるく広報 > のなかにに位置づけられる.

10 年前と比べて，ど統合的ソフトウェア開発支綴環境を機築し利用するたんな新しい技術が導入されて，作業工程がどのように改めに必要な要素技術は，これまで数年にわたって研究・善され，品質や生産性がどれだけ向上してきたのだろう

開発され.現在は明らかに移転段階に入っている .

ソフトウェア開発の現場では.

技術移転とは.ある意味で「経験の経済学 」だ といっか.

現在のソフトウェア需要に大きな割合を占めている第3 次金融オンライン ・ システムの開発現場における技術
課題を.あるワークショップで取り上げたことがある.

てよい.今回のワ

クショップ参加者は，それぞれ，環境関連技術の教育や移転について.なんらかの経験があり.意見を持っているものと予想される.このセ ッショ

ほとんど信じられないような人数の技術者を動員してンでは ， それらの経験や意見を，おたがいに評価しあい，

実施されているそれらのプロジェクトにおける開発作業交換するためのフリー・マーケ ッ トがうまく檎成できれ

手順や支媛環境を，過去の第 1~2 次プロジェクトと詳ばと考えた.

一応，チェアマンとして用意した討論の話題は次のよ細に比較して得られた結論は.ユ ー ザ要求が指数的なt曽加を見せている反面.ソフトウェア開発の環境は，コン

うなものであった:

ビュータの利用形態がパッチから TSS に代わっただけ一で.そこで使われているツールや工程モデルは，まった
く 1 0 年前と変わらないということであった.

また.通信業界の某大手ユーザでは.

対象とすべき技術:いま技術移転の対象として.

どんな技術を取り上げるべきか.その成黙の度合い
は.など.

10 数年がかり一で整備されたシステム開発の篠準マニュアルがまるで六技術移転プロセス:そのモデルはどうなるのか .
プロセス・プログラミングは可能か .

法全書のように部厚くなり，それが創造的な仕事のほと

‑
1
0
‑

ReportfromNagaokaWorkshop

一

一

国家プロジェクトの役割

SeamailVol.2No.4

ICOT.JSD.S

えば，返す万で企業内での技術管理の問題点を切り.採IGMA などを，技術移転という観点から見直す.

用問題とからめて現代学生気質を論ずるといった.大変

大学・研究所に望むこと:産学の分業・協力体制

楽しいお話であった .

はいまのままでよいのか.その日米比較など.
一

人間的側面:技術移転のグループ・ダイナミクス.

3. 2

日本的社会構造は技術移転に敵しているか.
一

討論

その後の討論は，初めのうち.教育問題だけに焦点が技術促進の加速メカニズム:ショーケイス・プロ

合ってしまって.それだけで時間切れになってしま うのジェクトや企業内遊園地などの概念の有用性についではないかと.いささか心配した. 実は，昨年 10 月 のて.

UNIX ワークショ ッ プ (b it 臨時増刊「最新 UNI

XJ 参照)でも.斎藤先生が司会された開発環境の セッ
しかし，実際のセッション運営は.これらの話題にとションで，教育の問題をだれかが提起したところ.

3時

らわれることなく.会場からの発言や問題提起を中心に，間の討論時間のほとんどがそれで終始してしまった苦い

いわば成り行きまかせで行おうと考えていた.ソフトウ

経験があるからである.

ェア・プロジェクト運営における成功のための第 1 原則
「メンバー性善説」にしたがったわけである.

一般に，教育についての議論は.全員が参加できる反面，ほとんど皆にとってうなづけるステート メントばかりが続出して.盛り上がりに欠けることが 多いが ， 今回
3. 討論結果を振り返って
これまで，わたし自身，技術移転をテーマとするパネ

は企業サイドと大学人との論争がリアルタイムで行 われ ，きわめておもしろかった.

ル討論を，チェアマンとして 2 回，スピーカとして 2 回

また.大学教育に期待する以前に(いや.教育一般にほど経験していたが，今回のワークショップが，最もエ期待する以前に) .広い意味での開発支援環境を整備し，キサイティングであった.

充実させることの重要性が認識できたのは，はなはだ有意義であった.

3. 1 基調講演

討論後半の話題として，ソース・コードを取り上げた

まず，君島浩さん(富士通)に，企業内で教育を担当のは，休憩時聞の何気ない立ち話の中で.ヒントを 得た

しておられる観点から.ソフトウェア技術一般の移転のからであるが，単純なソース ・ コード論 議を経て，パブ問題について，日頃実行したり，考えたりしていること

リックドメイン・ビジネス戦略・特許問題と. 議論がどをお話いただいた.概要は次の通りであった:

んどん進展し，活発な意見交燥が行われたのはうれしかった .

今になって振り返ると.ソース・コ ードより上位の設

1.背景

2. 技術移転の才構成要素

計や要求定義に関する知識やノウハウの移転をどうする

3. 現在のソフトウェア企業の技術水準かについて.あるいは，環境そのものに 関するノウハウ

4 . 先端技術と実践技術の格差についても.もう少し突っ込んで議論してみたかった.

5.Í支術移転を限害する要因

たとえば，メインフレーム上での開 発環境 と今後実用

6. 技術移転作法 :7 つの心得

化が進むであろう高性能なワークステ ーション上の環境

7. 技術移転の体験:ソフトウェア設計の自動化とを.どんな風に使い分け組み合わせるかが.これか ら

8 . 技術の利用容易性:タスク指向の移転方法のかなり重要な技術的課題になると恩われる.

9 . 技術移転の回毎管理とボトムアップ運動
10 . まとめこうした課題に対して.また来年以降のワークショ・yプで，ぜひ討論してみたいと思う .

君島さんのポジション・ぺーパの内容を，こうやって目次ふうに整理すると，何となく堅いレクチャーのように見えるが，実際は.大学教育の現状を批判したかと思

‑
1
1
‑

SeamailVol.2No.4

ReportfromNagaokaWorkshop

第 2 回実践的開発環境に関する集中討論泊長岡

S
e
s
s
i
o
n2
: 技術移転

討論記録
レポータ

盛田政敏

1.大学に怠ける教育と研究視しているわけですね?笑い)杉田譲明 (SRA)

君島:

それでは，君島さんのキーノー

そうです(大爆笑).

.

トを受けて，これから自由討論に入りたいと思います .

片山卓也(東工大

鳥居宏次(阪大

積極的に研究資金を集める努力をしないのは.志が低い

大学教育について説明された OHというようなニュアンスのお話があったが.. . .

P をもう一度見せて下さい.

君島:

これでしょうか?

大学のソフトウェア研究者が，これは，大学でのコンビュ

君島:

アメリカとくらべると，日本の大学は，気迫やータ教育に対する一般的な批判を箇条書きにしたもので意気込みの点で，やや欠けるような気がします.

す.要点をまとめれば，おおよそ次のようになる:片山 :底の浅いプログラミング教育に終始しがちであ(1)

メリカと遣って.お金があっても人(研究開発に必要なる .

(2) 現実のソフト開発との関連や応用についての説

学生アルバイトやプログラマ)を雇えないからです.
研究用の篠械装置を買うことも必要だが，それ以前に，

日月なしに，むずかしい理論だけを教えている.

(3)

(4)

しかし.お金ばかり集めてもソフトの研究はできません.なぜかといえば，日本の大学の制度では，ア

ソフトウェアとあまり関係のないシステム工学

問題はいかに良い人材(学生)を研究室に残しておくかやハードウェアの教育がかなりの部分を占めていということなのてすが.それがなかなかむずかしい . ソる.

フトウェアの研究は，ご承知のように，概念をいじるよ

どうも日本語の文章教育がなっていない.大学
でもっと教えてほしい.

私は上の 3 つには同感ですが，最後のドキュメンテー

うな仕事が多いので，ただ頭数だけそろえてもしかたがない.私はそんな風に考えていますが . ...
君島:

たしかにそうでしょうが，歳近，新しい形の産ション教育は.企業でやるべきだと考えます.技術文書

学共同方式で何とか現状を打破してみようという動きもの書き方は，学習院大学の木下先生などが熱心にやられあるようです.そのへんに注目したいと思っています.

ていますが，こういう基本的な教育は大学というよりむ

片山:

しろ小中学校段階の問題だと思います.

てきたので，理論が役に立たないということについて ，

ところで，こうした批判が出る裏側には，逆に，大学それから.私自身いままで理論的な研究をやっ一言いわせてください(笑い) .

役に立つことがはじめからわかっていれば，本来，技の情報学科で何を教えて欲しいのか.企業サイドの要求がはっきりしていないということがあるでしょう.望ま術移転などということは問題にならない

しい講座のタイトルを 5 つ挙げよといわれて，さっと答的な研究の成果は，直接現場の仕事には使えないので，えを出せる人はほとんどいません.

我々としては ， 一歩退がって哲学を教え，間接的な波及鳥居:効果として.世の中のお役に立てばよいのではないかと最近の新入社員の知的能力が低下したといわれましたが，能力評価の基準は?

考えているのですが . .，・

君島:

君島

あまりよくないかも知れませんが，出身大学のもともと理論

CMU のウ 1レフたちが奮いた計算機科学の入門

偏差値でマクロに傾向を見ています.入試の時に使われ書を見ると，ソフト開発のどんな所にどんな理論が使えている偏差値です.

るかが，きわめてわかりやすく示しである.私がいいた

鳥居:

かったのは，研究レベルの話ではなく.教育のなかで，ということは，入学から卒業までの 4 年間は無

‑
1
2
‑

R
e
p
o
r
tfromNagaokaWorkshop

SeamailVol.2No.4

理論をどこでどう応用するかを，明らかにしたらどうか

中野:ということです.

とだと思うのですが.斎藤先生いかがでしょう?

片山:斎藤信男(慶大

リクルートの話ですが，最近うちの大学でも.

それは，簡単にいえば論文にならないというこ

あまり論文を書いていないので，やはり，大企業へ行く人が減っている.学生時代からソ

よくわかりません(笑い) .たしかに，大学では論文をフトハウスを作ったりして，小さいところで能力を発揮

書く事も重要かも知れないが，ほんとうに大切なのは人しようと考えている人が割合多いようです.かと思えば.

材教育だと思います.

そういう意味では，本来.大学で C 言語の構文なんかマスターを優秀な成績で出て.銀行へいった人もいるし，を教える必要はない.どうやってプログラムを設計する

N 社へ行った人もいる.
鳥居:ということは，F 社の魅力が減っているのではかとか.ソフトウェアの要求仕様とは何かを教えなけれ? (笑い) .

ばならないが.なかなかむずかしく，準備も大変なので.

君島:

とりあえずプログラミング言語の文法を教えているとい

たしかに給料や勤務場所の点では不利になってうのが現状ではないかと思います.

います.問題は，仕事の内容に魅力がなくなっているの

日米の大学教育を比較した調査結果によると.日本のかどうかです.もっと.特許や論文の数を増やすよう.
尻を叩かなければいけないと感じています.

大学は無用の長物であり，大学院はもっと惑いといわれ

杉田:

大学の先生に一言文句をいうと，こういう具合ている(笑い) .それに対して誰も反論できない.私のいにいろいろな反論がはね返って来るので.気をつけて大学でも.コンビュータの教育はマシンに電源を入れる下さい(爆笑).

中野秀男(阪大所から始めなければという頑迷な信念にもとづく教育を

10 年以上続けている先生がいます.こういう所から.

杉田さんのポジション・ペーパに.

日本の大学ではソフトウェア・エンジニアリングよりコ

世の中に役立つ人材は決して育たないわけで.情報学科

ンビュータ・サイエンスに重点が置かれていると書いてなんかなくても大丈夫という産業界の人たちの意見も十ありましたが.具体的にどういうことなのて寸か?

分理解できる.

それから，ソフトウェア設計につながらない基礎理論教育

そういう意味では.偉い先生方はいろいろ反論されましたが，私は，君島さんや杉田さんの意見に全面的に賛が多い，といわれでもよくわからないのですが...目杉田:

それは私への質問ですか?

困ったな(笑い) .

成です(爆笑).

実は，今年の正月にハワイで行われたソフトウェア工学
に関する日米ワークショップに.オブザーバとして出席

2. アロはどうすれば育っか?

しました.

佐原伸(野村コンビュ ータ ・システム

日米それぞれの大学の先生方が，自分たちの研究の概

議論で，

いままでの

1 つ疑問があります.つまり，よい教育をすれ

要を紹介し合い，新しい共同研究の可能性を考えようとば自動的に技術移転が進むという暗黙の前提で話が進ん

いろいろ議論したのですが，その時の率直な感想として，でいるようですが，私自身のサッカーや囲碁の世界での日本での研究がコンビュータ・サイエンスに偏っている

経験に照らしてみると.教育にはそれほどの効用は期待と思ったわけです.

できないと思います.

具体的にいえば，今回のワークショップのテーマであプロフェッショナルを養成するには教えてはいけない.

る開発環境とか，プロジェクト管理(これはちょっと鍵

彼らが自分で何かを学ぼうとするさいの環境を整えてやしいかも知れませんが)を研究されている先生はほとん

ることは必要だが.教えてしまうとプロは育たない.せA 1 ，オ

いぜい，ょくできるアマチュアにしかならない.ソフト

ブジェクト指向，自然言語処理などの分野には，研究者

ウェア・エンジニアリングでもそうだと思うのですが，が集中している.

皆さんのお考えは?

どいない.逆に，コンパイラの基礎理論とか，エンジニアリングには.研究の成果を何らかの形で実

柿下尚武(カスタム・テクノロジー

プロになれる験をし，その結果を反映して次のモデルを作るというよ

人間の数には限度があります.どう考えても人口比 3%

うなフィード J ， 'Y ク・ループが必要ですが， 研究と実務くらいでしょう.ソフトウェアが産業になるには，このとのあいだのそういった連機が，ほとんどとれていない.

3 % の枠からはみだした人聞をどれだけ集められるかが

‑
1
3
‑

ReportfromNagaokaWorkshop

問題で，そこでは.プロとアマチュアをいかにうまく使SeamailVol.2No.4ョン・エンジニアリングの 2 種類に分かれています.

いわけるかを考える必要があると思います.

ところが，日本ではこうした体系化の動きがなく，た

建築業界を見ると，いわゆるデザイン・ハウスとゼネだあちこちの大学の理・工学部に.次から次へと，情報

コンの 2 種類の会社がある.前者の方は.徒弟制度で(関連の学科が作られているだけなのです.

人間のローテーションの)サイクルは 10 年位てす.一

杉田 :方後者の場合は，サイクルが短く人の出入りが多く，組的に賛成します.ところで，残りの 97% の人をどうや織も大きなピラミット型になっている.仕組みの遣う会ってチームの中に組み入れて，生産性の高い仕事をして社が二重構造を構成しています.

もらうか，そのための具体的な仕揚けや戦略が.非常にオリジナルなアイデアにもとづいてまったく新しいソフ

大切だと思うのですが，..・トを創り出そうという場合と.とにかくお金を穆ごうと鳥居いう場合とでは.状況が遣うのではないでしょうか?

いからやらせてみれば.除々に仕事のやり方を覚えて行

ソフトウェアを十把ーからげにする時代はそろそろ終

さきほど柿下さんがいわれた 3%の話に.基本

OJT のような話ですか?

まず.下手でもよ

くだろうという.もちろん，できる人はすぐできるようわりで.どういう種類のソフトをどんな組織で作るか，になるでしょうが，できない人はどうなるのか?

またそのための人材をどういうメカニズムで育てるかを，

3 % の人を選 んでいることになりませんか?

明確にしなくてはならないのではないでしょうか?
たとえば，金敵オンライン・システムと.

CAD/C

AM では，必要な技術がまったく遣うでしょう.道具と今後.もし，平均的な技術者の人数をふやさなければ，と企業サイドが考えているのだとしたら. ~IJなアプロー
チを取らざるをえないのではないですか?

してのソフトウェアにも，きわめてプリティブなものから.素人向けツ結局.

大学教育でも同じような問題があります . 私の教室で

ルまでいろいろあります.そうすると，

は.何も教えないでまずプログラムを作らせ，その後で情報学科でしかソフトウェアを教えられないというのは設計法をもう一度教えていますが.他の先生からは，そおかしい.

んな無駄なことをするな，初めか ら教えておけば時間がもっと細かく分けて考えた方がよいのではないか，単節約できるではないか，と批判されています.その辺の純に「技術」の一言ではかたづけられないような気がしことを聞かせてほしい.

ているのですが.目・・

佐原

君島:

達していない，

お二人の話に対してコメントさせていただくと，まず，プログラミングの技能教育をするのはよくないと

3 % の話.日本ではとてもプロの比率が 3% に
1% ぐらいしか育たずに，残りの 2 % は

途中でつぶされてしまう(笑い)

,思います.やはり理論的な面の教育にとどめて.応用面

それは，明らかに.鳥居先生がいまおっしゃった.時は各自が考える.そういう風にしないと，高度な技術は間をかけないで合理的に教えた方がよいという.生産性

習得できません.私は.理論教育がだめといっているわ

至上主義の弊害でしょう.小学校からしてそうですが.

けではなく，どこでどう使うかをはっきりさせた形で，人聞の促成栽培を目指した結果，レベルの低いアマチュ

理論教育を強化すべきだと思うのです.

アしか育てられない.全体の底上げを狙った教育で.は次に，いろいろな学科で情報教育を充実しなければな

たして何が解決できるのか，という問題だと思います.

らないという点は.まさにそのとおりだと思いますが.

ソフトウェア・プロフェッショナルを育てるには，底あまりそのことを強調しすぎると，情報学科プ ロパ ーの上げ教育ではなくて，岸田さんあたりが主張され.自分教育の印象が薄くなってしまう.両方やらなければならの会社や JSD で実践して来られた「企業内遊園地」のないでしょう.しかし，一方では，生産性がもっと上が考え方，かなり誤解を招きそうな危険な呼び名ですが(れば，専門プログラマの人数はもっと少なくてすむとい笑い) .こっちのほうが効果があるでしょう.ともかく，う皮肉な意見もあります .

若い人をそういう環境にほうりこめば.おそらくあるレ

日本ではソフトウェア・エンジニアリング教育の彫が薄いという杉田さんの話に関連していえば，アメリカのベルまではスーツと伸びることはたしかです . そこから先はまた別の問題ですが....

ACM のカリキュラムが，普は 1 種類だけだったのですが，いまはコンビュータ・サイエンスとインフォメーシ

第二種情報処理技術者受験講座というのが，最近テレ

ビで放送されていますが，見ていると，どう考えても.

‑
1
4
‑

R
e
p
o
r
tfro皿 Nagaoka Workshop

SeamailVol.2No.4

底上げというより，むしろ底を下げている感じしかしな

3. 銭術移転とソース・コ ード

い(笑い) .これが，いまの日本の教育の典型的なパタ

杉田:ーンのように思われます.

開発環境に関する実践的な技術の移転を取り上げてみた

企業内(あるいは大学内)遊園地の概念は，昔の旧制l

さて，ここで話題を教育問題から一転させて.

いと思います.それでは，話のきっかけを.

1PA の永高校なんかと相通ずるところがありますが，ある意味で島さんからお願いします.

本来の目的と無関係なことをして遊びながら，実は平均

永島晃 (1 PA)

レベルがスーツとあがって行く.もちろん，その中でもを構成する各種の支掻ツールを開発するために.いろい

シグマ・プロジェクトでは，環境

本当にプロになるのは小人数しかいないでしょうが.いろな会社からアイデアを募集し，提案された内容の検討

まは.教育制度とは別な所で技術レベルの向上がなされや調整を行っています . その中で.ソース・コードの問ていて，教育は逆にレベルを下げている.

題がでてきました.

柿下:

私の所のような小さい会社は，別に優秀な人がつまり，ツールをソース・コード付きでユーサ'に提供

集まっているわけではありませんが，不思議なことに .

しようと考えて，何社かに相談したところ.開発者およ開発チームのなかに一種の興奮状態ができると，能力がび利用者の双方から ，こちらが期待していたのとは逆に，急に上がることがある.

拒否反応がありました.このことについて ， みなさんは

3% の人が意外に身近で発見されたりします .

どうお考えですか?

いずれにしても，技術者を育てるには，かなり時聞がかかるものだというのが，私の実感です.私の会社では，ソフトだけでなく .

LS1 の設計もやっていますが小泡幸徳(日本システム ・サイエンス

私も，ソ ー

ス・コードを受け取ってもしかたがないと思います . ソ

1

フトウェア・プロダクトを開発する場合.できるだけ自0 年ぐらい同じ仕事を技術屋としてやらせてあげると.

分たちだけの知恵で仕事を進めるのが，正しいやり方で大企業にはいないような人材が育って来る.技術の熟成

しょう.

には時聞がかかるので，途中で担当を変えたりすると，

結果的に.その内容がノウハウとして残り.技術の付だめになってしまう.むしろ.そういう点では小さい会

加価値を高めていくことになります . 他人のアイデアを社の方がやりやすいかも知れません.

盗むことを考えない限り.ソース・コードをわざわざ見大企業からうちへ来た人のなかには.管理臓にさせらる必要はありません.

れるのがいやだから，ずっと技術屋を続けていたいから，

梓香 (S RA)という理由の人が結構います.そういう人たちを.大きルの利用者に提供されるべきだと思います.その理由は ，な会社て'は救ってあげられないのか?

使ってみてすばらしいと思ったソフトウェアについて.

もっとも，下手に救われたら.こちらが困りますが(笑い)

.

我々のような小さな会社は.仕事の枠組をそんなに広いや.ソース・コードは絶対にツ ー

そのソース-コードを見ると.また更に感動が深まる場
合があるからです.

げることはできませんが，逆に.あるひとつの領媛に特

ソース・コードを読むと，開発者の考えた筋書が読め化して，それ一筋に 10 年間ずっと同じことに取り組めてきます.このことは.また，プログラムの再利用を推る.というより.それしかできないのです.ところが，進する上でも.きわめて重要です.

そんなことをやっている人はあまりいないから.自然に岸田孝一 (SRA)

他人より優位に立てるということになります.

なる前.画家を志して勉強したことがあります.そのと私は，若いとき.プログラマに3% と 97% の議論は，だれが 3% かと血眼き.現代美術の新しい世界を切りひらいた先駆者の一人で探すのではなく，仕事の組み立て方しだいで .3% のである函家パウル・クレエの造型講義テキストを読みまだから.

人間を育てられるような気がし ています .

した.その冒頭に芸術における分析は，自然科学の杉田:

どうもありがとうございました.一応この辺でそれとちがって，単に作品を構成要素に分解することでコーヒー・プレイクにしましょう.そして.また気分をはなく，作品が創造された道程を再びたどってみること

変えて議論を続けたいと思います .

だ J という趣旨のことが書いてありました.
ソフトウェアは芸術作品ではありませんが，その成り

一一一一一休憩一一一一一

立ちを分析するにあたって，ソース・コードが貴重な手

‑
1
5
‑

SeamaUVol.2No.4

ReportfromNagaokaWorkshop

象にせず，そのソフトウェアの良さを理解してくれそう

がかりになることはたしかです.

既存の環境やツールを実際の開発現場に生かすためには，それぞれのプロジェクトの状況に応じたカストマイな人だけを対象にして，使用結果の評価と交換に配布するという形です.

GNU の場合ほど自由ではありませんが，多分.こうゼイションが必要になりますが.その場合.移転対象の環療やツルが，もともと，どんな考えで開発されてきすればそのソフトウェアの真の理解者が増え，着実に利たのかを知るのに，それ以外に有用なドキュメントが存

用者層が拡大して行くものと予想されます.

在しない現在の一般的状況を考えれば，ソース・コード

斎車 :はきわめて重要な材料だと思います.

われるものの 1 つに.文字フォントがあります .

パブリック・ドメインに涜通させたらよいと思

SMAL

デスクトップ・パブリッシングと呼ばれる，ワークス

LTALK の場合も.全般的な技術移転をスムースにすテーションを活用しての電子出版技術が話題になっておるために，一応はライセンスの保護メカニズムを設定しり.我々の研究室でも， TeX の応用についていろいろ.野晃延(富士ゼロックス情報システム

た上で，ソース・コードを利用者に提供するようになっと研究開発を行っています.しかし.日本語での電子出ています.

版を考えた場合，どうしてもそのフォントの入手が問題

伊野議(日本ユニパック

SMALLTALK を使ってユーサ'が開発したソフトウェア ・ プロダクトも.ほになります.
通常は，レーザ・プリンタのファームウエア上の RO

とんどが，そのポリシーを引き継いで.商品としてソーM 内に格納されていますが.それぞれのハードウエア・

ス・コードを提供するのが原則になっているようです.

メーカごとに，その体系や，書体が異なっており，一般

プログラミング言語としての SMALLTALK の魅力に電子出版を普及させるためにはどうしてもパブリックは，このことによって随分大きくなっているように感じ.ドメ イ ンのフォン トが必要です.
この問題を 1 度，シグマの技術委員会で提案したのでられます.

すが.まだ返事が返ってきません.
4. パプリヲク・ドメイン

永島 :二木厚吉(電総研

レベルではよくわかりませんが，提案審を御提出いただ

たしか，オーランドで開催された第 7 回 ICSE の時に，フリー・ソフトウェアという斎藤先生の提案が今どうなっているのか，私のいてあれば.検討が進んでいるに遣いありません.

考えをハーバード大学 AI ラボのリチヤード・ストールマンという人が提案していました.これは，すぐれた基5. ソース公聞とビジネス

本ソフトウェアを無料でドンドン配布し.それに関する

片山 :技術情報の交換を進めようという，非常にラデイカルなんどん普及していった場合 ，それを販売しようとしていアイデアです.

るソフトウェア会社は.商売がなりたたなくなるのでは

パブリック-ドメイン級いでソフトウェアがど

かれは.その後その信念にもとづいて自由ソフトウェ

ないかと心配するのですが.実際にソフトウェア・ハウ

ア財団を起こし， GNU プロジェクトをスタートさせて.

スの方々はこの問題に対してどのようにお考えなのでし自分が開発した EMACS エディタの無料配布を始めてょうか.

います.いずれは， C コンパイラや OS カーネルも無料

岸田:

で配るそうです" 1 ユーザの立場からすれば.歓迎すべ

題を考えると， 2 つのとらえ方があると思います.

ビジネスに関連してパブリック-ドメインの問

1 つは.研究開発の段階で一応できあがったフ・ロトタ

き動きですが，こんなことが一般化したら.問題は起きイプの評価や改善を行うための場として，パブリック・ないのでしょうか?
この問題は，パプリ "Y ク・ドメイ

ドメインを活用することです.つまり，テスト・マーケ

ン ・ソフトウェアを具体的にど う活用し，自らも広げて

ティングおよび β ーテストを.パブリック・ドメインのいく努力をするかという問題につながると思います.

ユーザを対象に実施し.その結果をペースに，商品を完

村井純(東工大

この点については.津田塾大の小川先生が開発した S

成させていくという戦略です.

SE エディタのパブリック・ドメインとしての普及方法

こうすれば，最終商品が世の中に出たときには.そのが参考になるかも知れません.これは.不特定多数を対

評判はクチコミですでに広まっており，余計な宣伝は不

‑
1
6
‑

SeamaUVol.2No.4ReportfromNagaokaWorkshop

要になります . また，プロトタイプのテスト・ユーザも，

6. ソフトウェアの特許

当然.より徳能が充実した本番の商品を買ってくれるで

二本:

しょう.

開やライセンシングとビジネス戦略との関係は，おおよ

いままでの議論を聞いて.ソース・コードの公2 番目のより重要な戦略は.ソース・コードを一般にそ理解できました.それに関連して，さきほど君島さん

公開することによって.単にビジネスそのプロダクトのがソフトウェアの「特許」のことをいわれたような気が販売だけに終わらせることなく.より大きな，新しいマ

しますが，ちょっと解説してください .

ー ケットの創造を狙うという考え方てす. SUN マイク

君島:ロシステムは，オープン ・ システム・アーキテキチャと心になっていて.それ以外に特許を使う方法があるこという旗印のもとに，そうしたマーケティングを展開しては.一般にはあまり知られていません.

ソフトウェアの権利保護は.いま，著作権が中これは.

かなり成功しているようですが.この点については，村1976 年から出願の受付が始まっていて，井さんに補足していただければ幸いです.

いまでは，毎月何十件かが公告されています.この中の村井

SUN は.無条件にすべてのソースを公開して相当部分が 1992 年ごろに特許になるでしょう.出願いるわけではありません.ひとつの技術戦略にもとづいは月千件ぐらいだと聞いています.現在は，計算機メーてやっています.このことをよく理解する必要があるでカが主に出願していますが，ソフトハウスの方もぜひ特しょう.

許を出願するようにおすすめします.

ソース・ライセンシングに関しては.

UN1X の場合

二本:ソフトの特許というのは.たとえばどんなものと同様に，大学向けと企業向けとでは，価格や制約条件

ですか?

なと'の点ではっきり差別をしています.カーネルとのか

君島:

かわりある微妙な部分は，巧妙にそのノウハウの公開をおいて，画面上で何かを移動するときに，背景が隠れる

隠しているようです.

ので一時的に隠れる部分の絵を退避する.そのときに排パソコンやグーム ・マシンのアニメーション に

現在 SUN の主力ソフトウェア商品である NFS (ネ

他的論理和を 3 回繰り返してデ ー タを交換するという有ット ワーク ・ ファイル・システム)については.ソース

名なテクニックがありますが.これは特許になっていて ，・ コードをはじめ.ほとんどすべてのノウハウを公開しもしこの方法を使いたければ，特許使用契約をしてお金て，そのアーキテクチュアに合致す関連関プロダクトを，を払う必要があります.

周辺のハード / ソフト ・ メーカにどんどん開発してもら

鳥居:

おうとしています.これは.一見ボランティア風の，単アや商品があるのなら，それをどうして論文の形でまと純に気の合う仲間を婚やそうという動きのように見えまめようとしないのですか?

特許として認められるようなすばらしいアイデ

すが，もちろん，それだけではありません.その奥には，

大体，いろいろなコンファレンスやシンポジウムに産SUN 独自のビジネス戦略があるようにうかがわれます.

業界からの論文が少なすぎるということが.現在の日本

1 つは ， いわゆる第 3 世界コンビューティング，つまにおけるソフトウェアの技術移転を困難にしている大きり ， ソフト非公開のクローズド・アーキテクチャ戦略て'な原因だと思います.開発現場における現状の問題点のこれまでの世の中を支配してきた 1 B M (第 1 世界)や分析や.実践の中から生まれたいろいろなアイデアを，第 2 世界 (DEC) を，オープン-アーキテクチャ思想

積極的に論文にまとめて発表していただきたいと.強くに共鳴する同志を集めて包囲するという長期的な狙いで希望します.

す.

杉田:

また，短期的には，当面の競合プロダクトである AT

ちょうど予定の時聞が近づいたところで，鳥居先生からクロージングにふさわしいお言葉が出ました.

&T の RFS が市場に出て来る以前に. NFS の絶対的

どうも ， 我々産業界の人聞は「論文を書け! J といわれ優位を確立し.その結果として，ワークステーションやると.ギャフンとなってしまいますが(笑い) .この辺

その他のソフトウェア・プロダクトの今後のマーケッテ

で討論を終わりにしたいと思います .

ィングを有利に進められるようにしようと考えているよ
うです.

‑
1
7
‑

ReportfromSpringSeminarWeek

SeamaUVol.2No.4

春のセミナー・ウィーク:

缶ssion A1

要求定義支援ツール講師:

松本吉弘{東芝}

報告者:

渡遁

雄一{電力計算センター}

1.はじめに

2. 観点( view) の重要性

ふだん仕事をしていて思うことがある.
エンド・ユーザが出してくるさまざまな要求(それは現在，我々がソフトウェアを作っている手順を振り返ってみると，図 1 のようになる.

要求というより ，むしろ“ぐち"に近いものが多い)を

この図は.一見あたりまえのように見えて，実は，現ワープロみたいな徴械を使って順番に入力しておく.そ状におけるシステム開発の問題点を示す重要な意味を持してある日みんなの勝手なわがままも聞きあきたかっている.なかでも.ポイントは，中央に位置する抽象

ら，そろそろシステム作りに取りかかろうか」と，おも徳械作成過程である.

むろに特殊なコマンドを入力するといくつかのシスすなわち.この過程で.システム分析者あるいは設計

テム・デザインを試みてみましたので，お好きなものを者は与えられた要求をどうやって実現するか ?J と選んで，機能の修正または追加をして下さい」と問い返

いう抽象的なモデル化の作業を繰り返すわけだが，これしてくれる.

らの実現モデルは，その時点では人聞の頭の中にしか存

究極の要求定義支媛ツールとは.そんなものだろうという期待が，いつも心のどこかにある.今回の松本さん在せず.たとえ外部に出力されたとしても，あくまで非
公式なメモの形でしかない.

の講義のなかにも，きっとそうした夢のツールが出てく

次の資源割り付けの過程に入ると.ようやく前段階でるものと.勝手に思い込んでいたのだが.やはり現実はの成果が.基本設計奮の形にまとめられ，詳細設計書か

きびしく，甘い夢物語は聞かせてもらえなかった.

らプログラムへと，機械にのせるための記述手段を用いでは.セミナーに参加しても無意味だったかといえば，て表現される.

答は「ノー J だ.結論としてウ~ン，要求定義って

以上 2 つの過程は，その性格が本質的に大きく異なっ

やっぱりむずしいんだなあ! J というごく平凡な事実をている.実際，これらの聞のギャップは非常に大きく.

再認識しただけではあるが，むずかしさの中身について

その聞の変換はきわめてむずかしい.

の理解を.以前よりずっと深めることができたと感じている.

ー一一一 III-ー一一+{質調思割付け}

以下.今回の講義の，主として前半の内容をまとめた
個人的なノートを.恥ずかしながら披露することで.レ
ポータとしての責務にかえさせていただきたい.

また，ことわりしておくが.当日説明された内容は.
講師自らの筆による参考文献 [2J ~ [5J に詳しく書かれてある.しかし詳細はそちらを読めばよい」といってしまっては.身もふたもない.実際.論文を読むだけで理解できるなら.何も苦労はしない .
私自身.このセミナーで直媛に松本さんのお話をお聞
きして.やっとその真館が理解できたという気がする.

テストへ

ー一一同固定捷一一一一一 実現制

あらためて，人の文章の行聞を読み取ることのむずかしさを痛感させられた.

国

‑
1
8
‑

1

SeamallVol.2No.4

ReportfromSpringSeminarWeek

それでは実際にこれらの過程をもう少し詳しく見てみそのさい.個々の観点からの記述が.それぞれ 1 つの要求モデルとして，コンビュータ上に保持されているとよう .

まず，利用者からの要求はどのようにして決まるか?

便利である.それらの要求モデルは.システム分析者の一般に，目的システムに対する制約と，システムによ指定に応じて，必要な情報を印刷表示してくれる.それってもたらされる効用とを折衷したものが，利用者のニが「要求定義支媛ツール J として望ましい.

ー ズであると考えられる.それにもとづいて，計算機内で処理し:なければならないことがらをまとめたものが，3. 現実の問題要求である . それは.利用者が与える入力から目的とすモデルだけでは要求は記述出来ない.また顧客(ユーる出カを得る過程での ， さまざまな制約条件や計算微環

ザ)の側からは . 自然言語で書かれた仕様書を求められ境上の規制を，何らかの形で含んでいる.

ることも.一般的である.講師は，以下の 4 点を，現実

こうして一応は定められた利用者要求を.次に，さまの問題点として指摘された:ざまな観点から分析することが.きわめて重要である .
今回の講義では.有名な酒倉庫問題 [8] をとりあげ .

一

いくつかの典型的な観点による分析の例が示された:

要求が外の世界.例えばプロセス制御のように他の機械(例えば発電徴，タービン等)と強く関連する場
合には.それらの仕様が決まらないためにソフトウェ

(
1
)M
o
r
p
h
o
l
o
g
i
c
a
lView(形態的観点)

アの要求定義が.それに付随して非常に決まりにくい

絵による表現を用いる.きわめて初歩的なアプロ
ー チではあるが，文章でごちゃごちゃ書いてあるよ

ことがある.
一

顧客の持っている知識やノウハウが，ソフトウェア

りはわかりやすい.記述に関する形式上のルールは開発者側になかなか伝達できない.そのため . 仕後決

存在しない.

定作業に.顧客が立ち入ってこなければならず.責任

(
2
)FW
l
C
t
ﾎo
n
a
lView(機能的観点)の境界があいまいになる.システムの規模が大きくな

ればなるほど，この問題は大きくなってくる.

まず，システムの持つべき機能を洗い出して.それぞれに対する入力データ.出力データ.動作の起一的要因)がますます重要になってきているが，それら動条件，機能を実現するための資源を図に示す.代を十分に取り込むことができない.

表的なシステムとして SADT がある .

(
3
)C
o
n
t
e
x
u
a
lView(前後関係的観点)

一目的としている対象の中に，どのような単位があるか?

要求仕様ばかりいくら作ってみても始まらない.その意味てぺ実現可能性を持った要求をいかに形成して行くか，後の工程との整合性を持った要求仕様をいか

そしてそれら単位間には.どういう相互関

係 ， 前後関係があるかを記述する . 代表的なシステ
ムとして PSL / PSA や SREM がある .

愚近のシステムでは，ヒューマン ・ ファクタ(人間に作るか，ということが問題である .

ER(

実体関係)モデルとも呼ばれる.

4. 既存の手法に対する疑問等

(
4
)D
y
n
a
m
i
cView(動的観点)
事象とその時間関係.論理関係を明らかにしよう

ここまでに示した手法を.講師は「古典的手法 J と呼ぴ.参考文献 [2] で . 次のように総括している:とする観点である . タイミング ・ チャ ー トや状態遷F これら一連の思想、の流れのなかには，構造化プログ移図がよく知られている .

ラミングや段階的詳細化.実務向けの設計方法論に代表

ここで重要なことは.どのような問題(対象)に対しされるトップダウン思想、と.コードとの対応を明確にしても . 万能な観点は存在しないということである . したながら抽象度を高めていこうとするボトムアップ思想、ががって，我々としては.つねに複数の観点から ， 利用者

共存していた.

の要求を記述し分析してみる必要性が生じる.さまざま

典的アプローチと考えているが，その残念な点は.トッ

な観点からの「展開と縮約の繰り返し」が行われるわけ

プダウンとボトムアップが個々にそれぞれ独立に進めらである .

れていて.どちらも要求からプログラミングまでをカパ

‑
1
9
‑

(中時〕

以上に述べたようなものを古SeamaUVol.2No.4

ReportfromSpringSeminarWeek

ーするような一貫性のある方法論にまでは到達できず，みよう.きて，ユニーク・セマンティックスに耐えるこ

中途半端なものに終わっているということである.実務とのできるセマンティックスが現実に存在するであろう

では.かならず途中のどこかで.トップダウンとボトム

か.さきに.種々のモデルや仕様について紹介してきたアップの接合点が現われ，そこで相互の聞の編み合わせが，これらのもつセマンティ"/クスはいずれも帯に短し.

が行われているが，これに関するまともな級いが後回したすきに長しで適当なものがない.あるものは実現伎はにされている点が残念である』

十分であるが.要求レベルでの記述にはあまりにも綿密過ぎて適当でないし.あるものは検証可能性や理論的裏

このような主張に対して.私は次のような疑問を抱い付けにはすぐれているが，実現性には乏しい』

た.

しかし，また一方でインプリメントする言語によ「古典的 J 手法という割には.それらに対する適当なガイドブック(参考書)が世の中に見当たらない.またり.システムの設計{例えばオプシェクトの選び方，タ

ここに示されたモデルに限らず.一般に要求定穏や設計

スクの設計の仕方)が変わってくる」という意見も.世に関する情報が計算徳化されていない.

の中には根強く存在する.理想的には.ボトムアップにそういしたことが，これらの手法の一般への普及を妨げているのではなかろうか?

コンビュータ化されてい関する情報を知識ペースとして取り込んでおくような何らかの仕揚けが必要なのであろうか?

ない手法に対しては，それを採用しようとした場合のリ

なお，蛇足ながら，私には「古典的」という言葉があスクに対する経営者側の態度は一般に厳しくなりがちで

まりふさわしくないように思えた従来型」くらいのある.

ほうが自然のような気がする.

我々がプログラミング言語を習得するときにも，まず.
コンパイラなりインタプリタなりを入手し.それを使っ

5. これからのアアローチ

さて，図 1 に示したソフトウェア開発手順の問題点をて簡単な例題を作成し，ミスを繰り返しながら言語の特徴や機能を学習得して行く.それと同じように.特定の改善することから，現代的アプローチが始まる.

r こういうすなわち.図 2 に示すように，まず.実現モデル作り

書き方はまずい」と指導してくれる人聞や支媛環境が存において，いままで非公式メモでしかなかったものを.

在しない限り.その習得は困難である.

綿密化し，厳密なセマンティックスで記述する.そして，モデル化手法についてああ書けば良い J「古典的」手法が，あくまで審物の上での手法にとどそれを何らかの形で実行して.実現モデルとして顧客にまっているかのように見えるのは，実にもったいないこ

見せる . 今まではコンセプトだけを説明していたものを.

とだと思う.

抽象機械作成段階で顧客にデモンストレーションし.隠

この問題に関連して.松本さんは.要求定穫を完全にするにはどうしたらよいかという立場で.文献 [3J でれたニーズをすべて吸い上げてしまおうという考え方である.

次のように主張されている:‑ ‑1 ーー一一ーー‑

n 一一一一一一一ー"I-m 一ー一一一ー...........抽象岨帽{修正) I

賀郡割付け}『これまでは.要求仕様を書く際に用いられた観点，

すなわちセマンティックスが実現体のそれとは異なることを前提としてきている.

(中略〕

これだけ生産性の向上が厳しくなった今日.ひとつのライフサイクルのなかで，複数のセマンティックスを仕様記述に際して許すことは好ましくない.全ライフサイクル・フェーズを一本のユニークなセマンティックスで押し通すことを考えなければならない.したがって.一歩進めて，要求仕様+一一一ー一一間固定蝿

ーー一一一一 実現問旭一一一+を含めてすべての仕様書が.唯ひとつのセマンティック
国スで記述できないかということについてこれから考えて

‑
2
0
‑

2

R
e
p
o
r
tfromSpringSeminarWeek

こうして要求仕様がまとまった後は，それを「出来る

S
e
a
m
a
i
lV
o
l
.2No.4を実際に綱策することは，至難の技である.

だけ手をかけずに」プログラムに変換して行くことが指「関係型データベースを用いて，いろいろな観点から向されている . 完全な自動変倹はすぐには不可能だけれ定義した結果をしまっておき.所定の観点について必要

ども，できるだけ後械の助けを借りて変換を行なうやりなデータだけを編集して取り出してくる」というのが，方が，かなり将来性があると考えられている.

要求定猿ツールの一般的なものである.よって要求定義

いいかえれ lí. ここで作られるプロトタイプや操作的を実現するためには，非常に大きなデ ータベース徳能と.

仕様，あるいは形式的仕様は.要求そのものではなくて.

それの上に皮をかぶせた“仕俗け"が必要となってくる.

その実現までを考えた 1 つの機構である . ただ，それを顧客が見て内容を修正することができるという仕鋳けを.

7. おわりに

セミナーの後半では ，実際に松本さ んたちが開発-運

要求分析の段階における分析者と顧客とのインタフェー
スとして採用していることになる.

用している要求定義支鑓ツールの一部が紹介された .

私のように，要求定義にしろシステム設計にしろ.あ

以下にそれら機構の特徴を示す.

る意味でいい加減に仕事を片付けていてそれですんでし
まう環境で暮らしているものの目には.初めのうち.セ(1) プロトタイピング
一動作可能なモデルである .

ミナーの内容が何となく堅苦しいものに映ったことは事ーデモ.改良そして変更を繰り返す.

実である.しかし.講義を聞いているうちにいろい

一以下の 3 種類に大きく分類される:ろな観点からのシステム・イメージを整理し保持して行(a) シナリオ型(紙芝居型)

く」ことの重要さが，よく理解できた.
いままで . 現場では.形式的 ・ 理論的な話をしても実(b) 原版型(パージョン O 型)

りが少ないからと，目先の成果にとらわれた行動が少な(c) 機能検証型

くなかったように思う.インフォーマル ・ スペックの実(2) 操作的仕様
一

資源割り付けを考えたものであってはならない(
その必要はない)一.

践にもそれなりの進歩は見られるが.ここで話のあったような王道をいくアプローチこそ.これから積極的に試実現したいシステムの振る舞いがわかるものでな

みていかねばならないということを強く認識させられた .

ければならない.
一実行可能.

【参考文献】

一[1] 松本:ソフトウェア工学演習.朝倉書店.

設計のように聞こえるがそうではない(設計では

(
1
9
8
4
)

.

[2] 松本 :オブジ ェクト ・モデルに基づいたソフトウェア「このパラダイムはプロトタイピングと次の点で設計 (1) ， bit , Vo1.17 , pp . 1157・ 1168 (
1
9
8
5.
1
0
)

資源割り付けを考慮する)異なる.プロトタイプはコードであり，プロトタイ[3] 松本:向上 (2) ，同誌. pp . 1331・ 1336 (19邸 .11)

ピングを通じて，それ自体が目的コードへと転換さ[4] 松本:向上 (3). 同誌.

れる.操作的仕様の場合には，正当性の検証を終わ[5] 松本，田中:データ補遺指向の要求分析技法.情報処
理， V oL .27 , No.2 , ppl品 1河， (
1
9
8
6
.
2
)

った仕様が，設計仕様.またはプログラミング仕様
へ形式的に変換される J[7][6] 松本ほか:要求技術の目指すべき方向{パネル討論会) .情報処理， Vo1. 27 , pp.1415・ 1429 ， (
1
9
8
6
.
1
2
)

(3) 形式的仕様
要求定義段階で.実現へ向けて変換可能な形式的

p
p
.
1
4
36
‑1448(19邸 .12)

[7]松本:要求定穣 ・プロトタイ ピング技術の現状と課題，仕様を作成し.これを一定の変換規則を用いて目的

ソフトウェア工学の現状と動向.

コードへ逐次変換していこうとする方式.

会. pp.11・ 22 (19邸 .12)

(社)情報処理学[8] 山崎:共通問題によるプログラム設計技法解説 . 情報処理， Vol. 25 , pp.934 , (
1
9
8
4
.
9
)

6. ツール橋祭の実際

先に示したような個々の独立した観点を計算憶がそな
えていて，それから要求モデルを形成するようなツール

‑
2
1
‑

ReportfromSpringSeminarWeek

SeamaUVol.2No.4

立A 春のセミナー・ウィーク: S
es
s
i
o
nA2

設計方法論の比較講師:

落水浩一郎{静岡大学}

報告者:

村井進{フリー}1.はじめにソフトウェア開発プロセスの中でこの距離を埋める作

このセッションでは，まず，言語 ・ 環境 ・ 設計方法論

業は.いまのところ.もっぱら人聞の知恵に委ねられての定義から始まって.ソフトウェア開発プロセスの中でおり.そのさい制御すべき対象は，質・量どちらの面での設計方法論の位置づけ，も，明確に限定されてはいない .

70 年代の方法論の特徴， 8

現在，ソフトウェア・エンジニアは.自分に許された

0 年代における新しい動向 . さらには環袋構築のための設計方法論の適用例と . 涜れるように話が進み，震後に，範囲内で，与えられた言語や環境などの道具を使って，最近話題になっている F . プル ッ クスの「銀の弾丸」論

設計作業に従事している . そして，先にも述べたように.

文を取り上げて.その概要が紹介された.

それらの道具を使いこなすためのノウハウを「方法論」

AB 裂の熱血漢(よく考えると矛盾した表現だ!

?
)と呼んでいる.

として知られる落水先生の雄弁にのせられて，そのときそれぞれの会社，プロジェクト，あるいはエンジニアは何となく，世の中の動きすべてが理解できたような気個人が，現実世界のイメージをコンビュータの内部にマになったのだが，いざこのレポートを書こうと思って講ッピングするために，独自の工夫をこらしている.そう義ノートを読み直してみると.短い時間の富IJ には ， きわした努力の中で，個別的な成功の事例が除々に積み上げ

めて幅広い話題がとりあげられており ， その 1 つ 1 つをられ.しだいに会社内あるいはプロジェクト内での標準理解することさえ，いまの自分には容易でないことが明的方法論として，整理されてきつつある.

らかになってきた.
したがって ， 以下のレポートは ， あくまで.私という設計方法論とは要求分析・定穫」の工程と「言語・環境 J とをつなぐための一種のブリッジである.過去

偏光フィルターを通した講義内容のエ ッ センスでしかなに試みられたさまざまなアプローチの中から，何度でもL 、-再現することができ.そうすることによって必ず一定の効果を達成できるものだけが，現在名前のついた」

2. 言語・環境・設計方法論

方法論として，いくつか残っているのだと考えられる .

プログラミ ン グ言語は.ソフトウェア開発のための最ところで.環境としての UNIX の特徴は.すべてのも重要かつ基本的な道具だとい う のが.落水先生の考え

資源を C という一つの言語で使用できるようにしてあるであるという意味で，環境の中での言語の位置づけが非常には方法論は.言語の不備を補う徳能を果たすことを目的としている . そして.環境とは.開発・検査・管っきりしていることである.
たしかに.プログラミング支媛環境としては有効であ理等の工程に含まれる作業の一部を ， 入手からソフトウェア・ツールに置き換えるための仕鎗けである.
プログラミングとという仕事の目的は，比ゆ的にいえり.静岡大学の場合でいえば.以前のハード・ソフト環
境では，

1 人の学生が 2 年聞の時間を必要とした作業(

ば，コンビュータと問題世界とをつなぐ何らかの「回路演習課題)が， VAX / UNIX の導入後は，」を設計することである .

でできるようになった.

1 年以内

しかし.現在のソフトウェア工学技術のレベルでは.
現実世界の問題が.十分には定義しきれない.つまり.

3. 70 年代の方法論の特徴

一応の問題定義がなされたとしても，まだ，それは.コ

70 年代におけるソフトウェア技術の特徴は.コンビ

ンビュータからの距磁が，かなり遠いところに放置されュータの側(つまり言語と環演のまわり)で，機械が持ている .

つはたらきを仮想、化し，少しでも問題世界に近づけよう

‑
2
2
‑

ReportfromSpringSeminarWeek

SeamaUVol.2No.4という努力が，さかんに行われたことである.

ブルーチン，または言語に落とすかということである.

その結果.各種の高水準言語(コンパイラ言語から第下回に. 70 年代における設計方法論関連のテクノ ロ

4 世代言語まで) .制御f構造またはデータ構造の整理を

ジー・マップを示す.

ベースとする設計技法群.抽象データ型やオブジェクト

4. 80 年代の訴しい動向

指向の概念にもとづく新しいプログラミング・パラダイ

ムなどが登場し，そのうちのいくつかは実用化のレベル

80 年代になると. 70 年代の研究および実践の結果に到達して，数多くの技法 ・ ツール・環績などが開発さ(あるいは失敗の反省)を踏まえて.さらに数々の新しれ.利用されるにいたった.

い試みが.次々に登場してきた.

一方，現実世界の側，つまり要求分析や定義に関しでそれらをランダムにリスト・アップすれば:も，問題世界をそれに密着した記述で書きとめ.解析し安定化させるための努力が，ある程度は行われた.そのーオペレーショナル ・ アプローチ

結果，疑似自然語，データフロー図式.事象/反応図式

ー図式プログラミングなど，やはり数多くの新しい記述技法が提唱されたが，一論浬型フ・ログラミング

笑用化という意味からすれば，いま一歩の感は否定でき

一関数型プログラミング

ない.

ー

オブジェクト指向プログラミング

そうした動きの中で.設計方法論もいくつか提案されー

マルチ・パラダイム・プログラミング

たが.その役割は，上述の 2 つの記述の聞のギャップを一

知識工学アプローチ

何らかの形で埋めるための手続きを定式化することであー

ルールベース・エキスパ ー トシステムった.つまり.機能構造あるいはソフトウェア構造の形で記述された内容を.どういう過程を経て，マクロやサ

基礎理論などである.

方法論

仕様化・言語

支鑓環境

SADT

要求分析

ISDOS
要求定義

実体関係モデル

PSA

P乱

SREM
確認

RSL( RßEτ7

シミュレ ーシ ョン

GAP

Pamas法分解

情報隠蔽仮想、機械設計

強度・結合度

Pamas仕様
複合設計

PUI

複合分析

構造化プログラミング

高水準言語

プログラミング

真珠のネックレス

PASCALUnixC

構文エディタ

段階的詳細化Jacksor怯
検査

構造テスト

変更・再利用+ その支媛環境

COBOL
T
e
s
tl弘mess
構成管浬

‑
2
3
‑

ReportfromSprlngSemlnarWeek

S
e
a
m
a
i
lVo
l
.2No.4

これらについては，すでに，昨年の秋のセミナー・ウ

るか否かをテストするには.かなりの労力を必要とする

ィークでも，落水先生自身がお話されており.そのときが，それらは，しかし，あくまて'偶然的な困難であって，のレポートも.すでに昨年 12 月号の本誌に錫載されて決して本質的なものではない.

いるので.ここでは詳細は触れない.

銀の弾丸とは.当然.ソフトウェア開発にともなう本

80 年代の方法論の特徴をひとことでいえば.それは，きわめて量豊かなハードウェア資源を持つ支媛環境を前提

質的な困鍵を解決してくれるような技法，ツール.環境
あるいは方法論のことである.

CP

プルックスは，ソフトウェアが持つ複雑性，調和性，

70 年代

変更性.不可視位からいって，現在のソフトウェア工学とは比較にならないほど強力であり，ユーザ・インタフ

技術の中からは.まだ，銀の弾丸は見出せないという分

ェイスも涜練されてきている .

析を，ていねいに展開している.

5. 銀の弾丸5. 2としていることであろう.今日の設計支媛環境は.
U 能力においても.また . 記憶容量の面でも.

いくつかの候補と欠陥

かれによれば.

講義の愚後の部分で，手喜水先生は.最近話題になって70 年代以降続けられてきた努力の大いる F. ブルックスの論文「銀の持丸は存在しない:ソ

半は.偶然的困雛を解消するためのものであった.以下

フトウェア工学における本質と偶然、 J をとりあげて.そに.銀の発丸の候補と考えうる各種の技法・ツールに関の概要を紹介された.プルックスについては.

OS36するプルックスの分析を要約しておく :0 の開発-管理に燐わったときの経験にもとづく名著「ソフトウェア開発の神話」が邦訳されているので.御存(1)A血その他の高級言語
特徴としては，モジュール化，抽象データ型，階層じの方も多いだろう.

この「銀の弾丸」論文は，昨年 8 月アイルランドで開構造の導入などがあげられる.従来の言語では.方法

かれた IFIP86 で発表され.世界中にきわめて大き論がカバーしていた内容を.檎文に取り込んでいる .

な反響を呼んだものである.原文でお読みになりたい方

したがって.近代的なプログラミング技法を訓練する

IEEE Computer 誌の 4 月号(今年)にのには，有効に使えるだろう . しかし.基本的には偶は.

再録されているので.御覧になられるとよい.

然的困難の緩和にしかならない.
(2) オブジェクト指向プログラミング

5. 1

抽象データ型あるいは階層的データ型の概念を，さそれはなぜ必要か?

「銀の弾丸」とは.ドラキュラや狼男などの怪物を退らに一歩押し進めたのが特徴である.それは，たしか治するための.必殺の武器を指す.つまり.プルックスに.設計者が余分な構文上の苦労なしに自分のアイデ

は.ソフトウェアという「生き物」を.ふだんはおとな

アを表現することを可能にするが.よく考えてみると.

しいが.ある日突然変身してわれわれに厳いかかってく

それは.鏑象的なレベルでの偶然的な困難を解決してる狼男にたとえているわけである.

いるだけのことである.

かれは，ソフトウェア開発の仕事.特にその過程でわ(3) エキスパート・システム

アプリケーション独立な推論エンジンや.現実世界

れわれが遭遇する困難を，古代ギリシャの哲学者アリス
トテレスにならって本質的」なものと「偶然的」なを正確に反映した知識ベースなど.実現性はともかく ，

ものとに区分して考える .

夢を持たせるアイデアは多い.期待効果としては，ア

ソフトウェア開発における本質的なむずかしさは.複

プリケーションの持つむずかしさと.フ・ログラムの複雑な構造を持つ抽象実体(データセ ッ ト，データ項目聞

雑さとを分隊することの可能性があげられる . 未熱なの関係.アルゴリズム.関数呼び出し等の相互関連)をプログラマを ， 経験豊かなプログラマのレベルに近付

記述し，設計し.その概念構成の妥当性を検証することけるのには.役立つだろう.銀色の孫丸足りうるか否にある .

かは.疑問である.

もちろん.そうした抽象的記述を何らかのコンビュー(4) 自動プログラミング

タ言語で表現し.その表現が仕様をきちんと反映していごく少数の例外的な問題に対しては，簡単なパラメ

‑
2
4
‑

R
e
p
o
r
tfromSprlngSemlnarWeek

S
e
a
m
a
i
lV
o
l
.2No.4

ータ指定によってプログラムを自動的に生成すること

6. 質疑応答が可能になった

Q : 本質的な困難を克服する能力は.教育あるいはテ

しかし.汎用の自動プログラミング

は，いつになったら実現するかわからない.
(5) グラフイカル・プログラミング
ビットマップ ・ ディスプレイの普及にともなって，

クノロジ・トランスファ可能か.当然ある程度の能力や経験が必要だと思うが.もし基本的に教育不可能なものだとすると.その代替としてどうすればよいのか .
40 人の学生がいるとすると，そのうちの 1 0

さまざまな図式を用いる視覚的フ・ログラミング ・ ツー

務水ルの試作や研究が花盛りであるが.成果は疑わしい.

人は偶然、的困難をこなすという意味で素晴らしい能力をソフトウェアはハードエウェアに比較して複雑すぎる持っている.

ので， CAD や VLSI 設計のアナロジ ーは成り立ちレベルだろう . 上位 10 人のうち.本質的な仕事がやれ

そうにない .
(6) プログラム

10 人は全く駄目で， 20 人はまあまあのる潜在能力をそなえた人聞は，
ベリフィケーション

安全性の高い OS を開発するような，特殊ケースを除いて ， 一般的には役立たない.つまり.プログラム

伸ばすことはできるが.教えることはできないような気がする.

が仕様と一致しているか否かの証明以前に，仕様そのものの「デバッグ」が問題である .

(7) 環境とツール
階層ファイル.ファイル・フォーマットの統一，プ

1 回見本をみせてやると.

次からは自分でできるようになる.その意味で，選別し.

ソフトウェアの本質的な問題に取り組むためには，何か総合的な知的能力が必要とされるように思う.そうい

う学生は，毎年.せいぜい 1 人か 2 人しかいない.しかし.毎年の卒業生のうち，15 人位はち~んとした SE

ログラム・インターフェースの統一.汎用ツールの使になっているので，割合はもう少し高いのかも知れない.

用などにより.開発の生産性や信頼性は，たしかに向Q上してきた.今後は，データペースの統合化により重例に対する質問)保守時に.設計時点の判断材料を使う(このレポートでは省略したが，適用事例で級った点が置かれるべきであろう.しかし.環境やツール(

ことに関してはどう思うか . また，新しいプログラミン

あるいはワークステーション)は.あくまで補助的な

グ・パラダイムは.具体化する言語によって変わるとい手段であって，それ自体だけで.本質的な問題が解決われたが.データの構造もあわせて考える必要があるのするわけではない.

か.データ独立にはできないのか.

務水:

5.3

グレート・デザイナ待望論

プルックスは.論文の最後で.将来の希望について触設計時の判断材料は残せると思う.確定的なことはいえないが.構築上の具体的な情報と打ち合わせの情報をまとめたものが必要だと思う.

れ，既成ソフトの積極的活用.ラピッド・プロトタイビ

新しいプログラミング・パラダイムに関しては.イメ

ング. 段階的開発(進化論的アプローチ)など，ソフト

ージするデータ構造の全体は同じだと思うが.そのまとウェア開発の綴念的本質に攻撃をかけるための.いくつ

め方が異なってくると思う.私個人は.ル ー ル指向はもかの見込みがありそうなアイデアについてのべたのち.

うあきたので.これからは論理型かオブジェクト指向で結局は「人間 J の問題がもっとも重要なので.われわれやってみようと思っている.

としては.偉大な設計者になりうる可能性をもった若手技術者を.早期に発見し，かれ(またはかの女)にしかるべき知的刺激を与えて.その成長を促進したらどうか，と提言している.

設計方法論の比較・評価を行うにあたって，そうい う
観点から考えてみるのも.ひとつのおもしろい比較になると.講義を聞きながら感じた.つまり.単に設計作業の生産性向上だけを考えるのではなく，その方法論を利用することで.設計者がどれだけの刺激を受け ， どれだ
け成長するか . という視点である .

‑
2
5
‑

SeamallV
o
l
.
2No.4

ReportfromSIGMANOA を取り巻く運営管理の諸問題
芝原雄二
沖ソフトウェア

(1)人について

1.はじめに管理分科会では.毎回，メンバの 1 人が，コーディネT さんの経験によれば.人に関する問題のポイントは.

ータ兼スピーカとして，話題を提供することになってい

管理者や経営者に対して，コンビュータ導入の理由やメます.今年 2 月の会合では， T さんが.表記のテーマをリットをどう説明するか.ということでした.
T さんの会社では，以前は.個々の部門単位で機種を取り上げられました.

T さんは，かつて.会社の EDP 部門にいて.オフコ

選定し，部門長の主導のもとにシステム開発が行なわれン等を社内に導入し業務の OA 化を行なう仕事を.担当ていたのですが，人事移動などによって生ずる混乱を避されていたそうです.そうした経験を踏まえたお話をうけるため，何年か前に， OA 推進を専門に担当する人聞

かがい，その後，参加者全員で討論しました.

を決め，この推進者の手で ， 運営ルール規定やサンプル集の作成.人の教育などを，統一的 ・ 集中的に行なわれ私自身は.メーカの OA 部門に属していますが.ふだ

るようにしたのだそうです.

んはあまりユーザと接触する機会が多くないので， OAマシンの導入に関しては，現場でいろいろ検討してい利用現場の御意見がいろいろうかがえて，たいへん参考になりました.このレポートは， T さんの当日のお話のた結果が，上層部の鶴の一声で勝手にひっくり返され.

要旨と ， 討論のポイントをまとめたものです.

現場を白けさせることがあるという経験談が，他の参加者から披露されました.
現場主導型でものごとを進めるには ， 管理者や経営者

2. 特性要因。 A の運営管理を取り巻く主な問題点を， T さんは「に対して，ソフトウェアを含めたシステム化の摘想を，人，物.金 J の 3 要素の観点から分析され，さまざまな

わかりやすくプレゼンテーションし，納得してもらうこ檎成要因のあいだの関係を.下に示すような特性要因図とが大切だというのが.みんなの討論の結論でした.
ここで，筆者が興味を持ったのは，コンビュータや 0で説明されました .

①

経営者

推進者
規定(運営ルール)

サンプル集

教育
/ ¥ ¥
集中
分散

算
採

性

定定

量性

\>//

受講者

信頼性

①
コスト・パフォ ーマ ンス

/(\
ソフト

ハード

‑
2
6
‑

OA を取り巻く
運営管理の諸問題

非 EDP 部門

企業内の社内開発

SeamailVo
l
.2N
o.4

R
e
p
o
r
tfromSIGMAN

以上に膨大な費用がかかるからです.

A 機器の企業への導入が，経営者の手で企画されるのか?

それとも現場から上がってくるのか?

ちらのケースが多いのだろうか?

技術者数育については.教育分科会や CAI 分科

ど会でいろいろ討論されているですが，これからは，ということです.

組織が大きくなればなるほど.経営側と現場との意

こうしたエンド・ユーザ教育も.大きな問題になる識の差は大きくなるでしょうから，一概にはいえなのではないでしょうか?

いかも知れませんが，どちらが主導権をとったほう

運営に関しては.もうひとつ，マシン・トラブルが徴械化がスムースに進行するかは，十分に比較・の問題が取り上げられました.事務の OA 化が進み.

検討する価値がある問題ではないかと思います.

機械なしではやっていけない状態に到達したあと.
マシンの故障修理をどれだけ迅速にやってくれるか(2) 金についてが重要になります.一般ユーサ' は.コンビュータは

OA 儀器の導入にさいして，採算性はどれだけ真故障するものだという「常識」をほとんど持ってい剣に考えられているのだろうか?

ないので，何度も故障が繰り返されると，システムという単純な疑そのものに不信感を持ってしまうからです.

問から出発して，いろいろな議論がランダムにとびかいました.
たとえば，ワープロを例にとってみても.最近は

3. まとめにかえてやたらと何でもワープロで「清書」したがる傾向が筆者は，最初にも触れたように.メーカの OA 部

あり.書類の作成に要以上の時聞がかかってしまう.

門にいる関係上，ともかく売ることが第一で.今回

この傾向は.特にふだん採算や経費削減に口うるさ議論されたようなことがらは.日常ほとんど考えたい年配者によくみられる，という若者らしい愚痴もことありませんでした .OA 機器導入のメリットや出たりしました.

先例は，われわれメーカ側で，きちんと整理し.ユーザに提供する必要があることを，今回の議論を通ともあれ，マシン導入時には.採算性がどうか，じて，感じさせられました.

どれだけの合理化ができるかを明確なデータで示す
ようにいわれることが多いのですが .OA 化・綾城

ここにあげられたような問題は .OA 機器の導入化によって仕事のやり方がまったく変わってしまうだけでなく，大型コンビュータの場合も同様です(

ような新しい環境の設定を計画している場合には.

むしろ.費用面てはるかに高価であることからす

こうしたデータを作ることがきわめてむずかしくな

れば.よりシビアに考えられなくてはならないと思ります.

います) .
コンビュータを作るメーカ，その上で動くシステ

したがって，そんなときには，将来もたらされるであろうメリット.他社または他部門での類似シス

ムを作るソフトハウスの人間と.そうしたハド­

テムの導入例，現状システムの問題点や改善の方向

ソフトを購入して利用する側の人間とのコミュニケ

付けなどを.素直に示したほうが効果があるのでは.

ーションが.これからは，ますます重要になってくということになりました.

るのではないて'しょうか?

(3) 物について謀せられた期待も.また.それだけ大きくなるよう

ここでの話題の中心は.マシン導入後のアフターに感じ.られます.まだまだ低空飛行中の SIGMA・ケアでした.特にメーカのサービスについての議N ですが.今後.より多くの方々の参加を得て，こ既存の会社組織の壁をこえた SEA のような場にうした境界領威の問題を積極的に取り上げて行くつ論がかなり行われました.

もりです.よろしく.

ユーサeがマシンを導入するとき，しかもそれを全図的な規模で採用するときには.メーカ側に全国ネットワークの教育・サービス体制があることが絶対の粂件になるという話が出ました.なぜなら.ユー
ザが自前で要員を中央に集めて教育するには.予想、

‑
2
7
‑

MessagefromNaganoChapter

SeamaUV
o
l
.
2No.4

長野支部設立報告佐藤千明
長野県協同電算

1.支部設立.みんなでやれば恋くない

議題:

設立経過報告と自己紹介

これからの地方での SEA の活動のプロトタイプとい

事前に各メンバの仕事の環境や関心あるテーマ.発表

う使命を背負って(?) .長野支部が 5 月中旬に設立さ材料の有無等について.アンケートを集めました . そしれました.なぜ?

て，当日はそれをもとに自己紹介を一巡させ，課題の揺と疑問に思われる方もいるでしょうから，ここで長野が先行した理由をあげると:り起こしと研究テーマの絞り込みを行うというつもりだ

一

信州という閉じた県民意識によるまとまり .

ったのて'すが.ふたを開けて見たら，なんと最初の 3 人

一

理屈っぽく議論好きな県民性.

の自己紹介だけで 6 時間が過ぎてしまいました(この辺一県当局が，重厚長大型から知識集約型て'軽薄短小が，信州人の議論好きのあらわれ!)な産業への転換を目指しており，ソフトウェアに対

東京でのイベントに毎回顔を出す経涜的 ・ 時間的ロスを軽減させたいという単純な要求.

一

そこで急拠方針を変えて，当分はこの調子で各メンバの自己紹介と問題提起を続けて行い，その中から今後のする過大なる期待がある .

一

週末は信州に遊びに行けるということで中央から研究テーマを抽出することにしました.現在の支部会員

数が 25 名なので，年内はスピーカの手配という厄介な仕事から逃れることができると，世話人は内心大事ぴ.

の支鑓があるのではないかという甘い期待.

一.

本当は忙しいが.暇そうに見られている世話人.

といったところです.

以下に.

1 回目の討論内容を整理してみましたが.これらが長野県の特殊事情を反映しているものか否かは.
定かではありません:(
1)SEANET はいつどんな形で動くのか?
パソコンネットも可能にして欲しい.

2. 活動方針

将来は SNNET(SEA . NAGANO ・ NET)5 月のキックオフ ・ ミーティングでは，活動の基本方を作りたいが.今は池田屋の二階で我慢.

針と.メンバ ー 獲得作戦を協議しました . そして.芋づJUNET サイトを支部会員に巻き込もう!

る式に一本釣りを展開した結果 . 支部会員数は 25 名にふえて，なんとか体裁だけは登えることができました.

(2) 開発生産性の定量的犯鐸がむずかしい.

当面の活動方針は ， 以下の通りです:

まず額準化，機械化の推進が必要.

一

毎月第 1 土曜日の午後に月例会を開催する.

個人の能力差をどう評価したらよいか?

ー

テーマは . まず「身近な情報交換 J ・一

場所は長野市(ときには松本市) .

一

会費は場所代とコーヒー( ?)代で 1000 円 .

(3) 工数見積を勘でやっているための弊害.
基本設計後でなければ工数は捉えられないのに.
概要設計段階で営業が受注額を決めてしまう(決め一活動内容は SEAMA 1
L.NAGANO (毎月

ざるをえない)ため.納期や予算がオーバーする.
発注者側の見積もりはあてにならない.

発行)で支部会員に知らせる.

一

中央からのスピ ー カの押しかけは大歓迎 .

一

自然環境のいい時期には合宿もやりたい.

設計完了後に.再度努酌し直せるだけの力を業界として持つ必要がある.
経験したシステム開発のデータ収集と分析.
ファンクション・ポイント等の新しい見積り技法

3 . 第 1 四月例会

1
5:伎ト 21: ∞日時:

昭和 62年 6月 13 日

場所:

長野市ケイケン研修センタ

参加者:支部会員 10名をカストマイズして使いこなそう.
建築でいう意匠設計のように . 概要設計や工数見+ 新聞記者

積もりを専門に行うビジオ、スが成立するのでは?

ただし，客観性と技術に裏付けされた権威が必要.

(翌日の経済面に写真入りで宣伝)

‑
2
8
‑

M
e
s
s
a
g
efromNagaDoChapter

SeamaUV
o
l
.
2No.4

(4) ステップ数と工数に相関関係はあるか?

プログラマとは別のチェッカーがいて，コード・

1K ステップ以内なら大体比例する.

インスペクションやウオーク・スルーを専門に受け低級言語と高級言語とでは.ステップ単価に差が持つ体制が必要 .

あって然るべきだが，実感はそうなっていない.

kWS 上で，本当にメインフレーム向けのプログ

高級言語のステップ数の裏にはかなりの投資が隠

ラム・テストができるのか?

されている .

メインフレームのプログラムには DB / DC 環境(5) 部品化・再利用の遅れ.

が必要であり，乏に繋がるテスト用メインフレーム

1 回しか使われない部品が多い.つまり.モジュはその環境をオープンにしてくれるのか?

ール化はされているが，部品化になっていない.
客先での開発のため自社内での部品の蓄積が進ま

4. 今後の計画

ない .

メンバの自己紹介が一巡した後は.次のようなことを

部品化の前に標準化をすべきだ.

しようと，いまのところ考えています:

部品化とパターン化は別個に考えるべきだ.事務一

情報処理学会の「酒屋の在庫管理 J みたいな共通

処理では.ロジックのパターン化の方が有効ではな問題を設定し，各社が実際に使っている方法論 - 技

L 、か.

法・ツールを用いてプログラムを開発するコンペを(6) プログラマめキャリアパス

生涯 1 プログラマでいたい人間にも.

開きたい.

SE になれー

発現場を相互に訪問し合う.

と強制するのはよくない.
プログラマとコーダは区別されるべきだ.

一

プログラマに業務知識.外部仕様記述能力は不要
か?

そのプログラミングの環境説明も兼ねて，各社の開

自己紹介を通じて浮き彫りにされたいくつかの間題
点やテーマに関して.中央から専門家を招へいして答えはノーだろう .

解説してもらう.

SE とプログラマの分担は，ハードの世界の論理屋さんと回路屋さんに対比できる.

5. おわりに一億総プログラマ時代にプロとして生きる道は?

きて，何はともあれ.支部はスタートしました . ここ

経営者は.く SE →プログラマ→コーダ→パンチ

までは ， そんなにむずかしくないのです.問題は.これ

ャ > という単価のハイアラキを有効活用しようと考からどうやって一定レベルの活動を継続して行くか，いえている.

かにして魅力ある支部に仕立て上げるか.です.
長野県内には，いま.大中小合わせて 100 社を越えワープロは女子職員に清書させるといった発想と同じか?
新人にいきなり SE 教育をして.単価の高い仕事をさせるという発想、もあるらしい .
経営者と技術者の観点の遣いをどう調整するかが問題だ.
(7) 非メインフレームでの開発環境
メインフレームとは世界が少し遣うようだ.

る情報処理関連会社が存在するようですが，幸いにして，県内のソフトウェア業界をリードされている中堅技術者の方々が.多数 SEA の会員になってくださいました.
ということは，大袈裟に表現すれば.長野でソフトの商売をする限り，この支部の集まりに顔を出していないと.
貴重な情報を取り逃がす可能性が大きいということにほかなりません.
そのうち.

総じてまともな仕様書やドキュメントが残っていないらしい .
シンボリ ッ ク・デバッガなしの環境なんて考えら

rSEA-NAGANO に行けば，儲かるかどうかは別として，とにかくおもしろい話が聞けるらしい」という噂が立つよう.心がけたいと思っています.

れない .
一方，メインフレームの世界では，シンボリック

・デバッガはあまり使われていない.
(8) テスト，そしてエ

‑
2
9
‑

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

V
o
i
c
e
sfromMembers

会員の声

もやりにくいのです.

安西宏[編集部注 :SIGNET で考えてください]

現在走っている分科会全部に関心がある.時々刻々重点も変わる.情報処理に携わる人は皆そうなのではなかろうか.全部に顔は出せないないので，結局ユーレイ会

小川昌邦

員になりそうだ.困るネ.

私は社内の EDP の仕事をしていますが，自分の仕事に直接関係のない(役に立たない)話しが聞きたいものです.名古屋地区での会員の交涜の場がほしい.

石井信[編集部注:名古屋支部設立へ向けて.去る 6 月 26

先日. 32 ビット開発環境をテーマにして，日本パーソナル・コンビュータ・ソフトウェア協会主催のセミナ

日，キックオフ・ミーティングが開かれました]ーを企画して，開催しました.ところが，このセミナーに対して，お上からクレームがついてしまいました.セ加藤朗

ミナー自体はたいへん盛況で，アンケートの結果も好評

SEA のイベント lまことごとく 1 万円単位の参加費がでした . しかし，分散環境の実演に用いたマシンが.お必要で，これでは私のような学生で自腹を切って行く人

上のお気に召さなかったようです.この分では.プログが困る.領収書はいらないから，もっと安価で参加でき

ラムの使い捨てと，税金の無駄使いがまだまだ続きそうるようにしてほしい.学生は SEA にはお呼びでない，です .

というのならそれでも結構 . 更新しないだけだけど[編集部注:御要望に応えて.

6 月のフォーラムか ら，きわめて安い学生料金が設定されました]

伊藤案

レベルの高い話しばかりでなく，初心者用，入門用といった話しも. SEAMAI し誌上でたまには取り上げ.谷章てほしい.ハイレベルな話しは.情報処理学会で十分す

A 1. 分散環浸，ディスクトップ・パブリッシング等，我々を囲む環境は複雑化の一途をたどっている.読者のぎる位である.

[編集部注 :SEAMAIL は商業雑誌でなく，会員立場に立っていま何が重要で何をなすべきか」とい相互の情報交換メディアです.いまのところ，編集部企うアンケートが面白いような気がする.これは編集部へ

画の入門講座風のページをつくる余裕は，印刷費の面での提案です.意外と.多くの人々は.最近の涜行のもの

も，また，編集ボランティアの人的資源の面でも ， 残念をなにひとつ必要としていないような気がする .
[編集部注:早速実施してみたいと思います

ながらありません.唯一の可能性はセミナー・レポート

アンケです.セミナー委員会宛に，必要と思われる入門講座トート案を作ってください . また，結果の集計と分析もよ

ピックスのアイデアをお寄せください]

ろしく]

一井生也

河村一樹

管理職の在り方についてもっとご意見を最近ソフトウェア工学の限界を感じている.

[編集部注 :SIGMAN にぜひ御参加を! ]1960

年代後半に叫ばれたソフトウェア危機は，あいかわらず続いている.企業内 EDP 部門のパックログはたまる 一
大久保功

方 . 業界全体が泥沼にのめりこんでいるような状態だ .

パソコン・ネ・y トワーク上で.諸問題のディスカッシ

どうもみんながプロセス指向になりすぎているのではな

ョン.特に各分科会で現在行なわれているディスカッシ

いか.ユーずは ， 格造化されたプログラムよりも正しい

ョンができるといいな!

情報のほうが結果としてほしがっているのではないか.

当社は，そのような社内ネットワークがあるけれど，アメリカ製で英語だから.どう

そのためには.プロセス指向でなくデータ指向になるべ

‑
3
0
‑

V
o
i
c
e
sfromMembers

SeamailV
o
l
.
2No.4

きである.ソフトウェア工学から情報工学への転換が.

ありましたら，是非教えを請いたいと思っております .

これから必要とされると恩われる.そうした技術的なア[編集部注 :SIGENVへぜひリ

プローチを行なう人聞を. SE でなく 1 E (
I
n
f
o
n
n
a
t
i
o
n
Engineer) と名付けたい.

咲悶纂

A という仕様に対してプログラム a を作成し .B とい木村一郎

う仕様に対してプログラム b を作成しているのが現状でSEAMAIL には. SEA 主催.共催のフォーラム

ある.早くこの手作り的な工程から脱出し.大量生産をやシンポジウムの内容がかなりあり，なかなか出席でき図りたい.その方法は?

ない会員としてはよろこんでいます.しかし，紙面の制約もあり全てを掲載してもらえない「うらみ」もありま

鈴木裕信

す(編集部にはきっと全てを掲載できない「うらみ」が最近思っていることは「すべては個人の問題意識に還残っているでしょう) .そこで.フォーラムやシンポジ

元される」ということです.ツ ー ルがどうの OS がどう

ュムにビデオを持ち込み収録をしてはいかがでしょうか .

のなんて，実は小さいことなんじゃないかな?

後日，希望者に実費でダビングしてもらえるとありがた
いと思います.

曾根浩士[編集部注 : たいへんよいアイデアで思いますが，い86 年 12 月に.

SEA に加入しましたが ，静 岡県 のまのセミナ一委員会には.そのための余裕がありません .

加入者が少ないのには驚きました.長野支部の記事は大どなたか，ボランティアしていただけませんか ?J

変参考になりました.静岡のソフトウェア産業の発展のためにも，静岡支部をぜひっくりたいものです .

栗本幸男[編集部注:がんばってください .まずは，身近の会

DWB. PWB について一言 .これらのツールがドキ員鉱大からリュメント作成，保守工数を削減し，プログラム自動生成につながる有効なものであることはわかっていても，ソ

回中康和

フトやコード(漢字を含む)などの統一化・領準化がさ

現在.色々なシンポジウムが大都会でたくさん開催されていないために . なかなか導入に路みきれない.また，れています .私は参加したいのですが.福岡という地方

練準か待ちきれず，どんどん自社流のやり方を押し進め都市に住んでいるために.なかなか参加できないのが現ていったあとで.ハード・ソフトの仕様標準が決定した状です.たまには福岡地区でも開催してもらえたら.九

場合に，メーカーはどこまでそうした先行投資の面倒を州の人々にとってプラスになるのではないでしょうか?

みてくれるのだろうか.

[編集部注:イベントの地方開催を実現する上では，
やはり採算が問題て寸.つまり，いくらの参加費でどの

小祭信子

画像処理.

くらいの人数が集められるか，適当なスポンサーをみつ

CAD. CAE 等についての情報があまりないようですね .SIGCAD に期待しています.

けられるか，といったことですが.そのへんを調べて 事
務局宛に具体的な提案をお寄せいただければ，セミナ 一
委員会で検討します]小林伸二
ソフトウェアは科学か芸術か.そこが問題だ

高尾猛
OA の普及・鉱大が進み，非 EDP 部門の磁場にもい佐々木重量博ろいろな機器が設置され.利用者の関心度合も年々高ま入社して足鎗け 5 年目の若輩ですが.憲近は「ソフトっています . そこで.さまざまな問題点，失敗/成功例

ウェアの生産環境」に興味を持ちはじめました.この分

等を，エンド・ユーザ(非 EDP 部門)活用事例分科会

野の勉強をはじめましたが.なにしろ言葉が量産しくて，(仮称)を作って交涜できるようにしたら，新しい庖のなかなか前進しない毎日です . この分野で面白い話しが会員も増えるのではないでしょうか?

‑
3
1
‑

非 EDP 部門の

SeamaUV
o
l
.
2No.4

V
o
i
c
e
.frOIll恥lembers

人々からみた場合. SEA に入会しづらいということが野中哲あるようです.専門家集団についていけないと感じる人

私は.マイクロ・コンビュータで装置制御をおこなうも多いように思われます.専門家と一般利用者とのあい

ソフトの開発をやっていますが，我々のような者の立場

だの相互理解を深める必要はないでしょうか?

からみると .OS や言語処理のようなソフトをやってい[編集部注:これ以外にも.先日のアンケートで，こる人は，たいへん高級な仕事をしているように思えてしんな分科会が欲しいという御希望が.いくつか寄せられ

まうのて寸.数ミリ秒という制限のもとでは.プログラ

ました. SEA は「草の穣」型の組織ですから.分科会

ムの美しさなどは，あまり追求できません.

は.すべて，いいだした人が「この指止まれ」方式でス

主に Y-DOC に出席していますが.

L1SP とか S

タートさせるルールになっています.具体的企画を立て

MALLTALK とかで飯を食べている人がけっこう多た上で，幹事会に提案するか. SEAMA1L 誌上で直いのにおどろきました.自分の仕事に全く関係のないい接会員に呼びかけてください (Vo 12. No2 掲裁のろいろな人と会えるのが. SEA の楽しみのひとつです.

SIGDOC 設立の呼びかけ参照) .もし，あなたにそ個人的には.労働時間.タイムカード.フレックス・

れだけのエネルギーがないというのであれば，いつの日

タイム.残業，休暇，給与，評価，在宅勤務.転職など，か.だれかが自分の希望をかなえてくれるのを待つ以外

広い意味での作業環境について議論したいと思います.

にありません]野々下幸治
岡村霊以前，池沢忠男さんから.年間の文献をまとめてくれ

地方会員という表現に少し低抗はあるが，自分としてるとことはありませんか.というメッセージがありましは東京から地方( ?)に移った者には. SEAMA1 したが. J O1S (日本科学技術情報セ ンターのオンライは唯一の中央(? )とのパイプであることはカクセナイ

ン・データベース)を利用すると便利です.特に特定のことである.また.自分のソフトウェア環境が大きく変テーマに関して，継続的に調査がしたい場合は. SD 1化した (UN 1X 系から IBM 大型に)者にとっては，検索を利用すれば，最新から 2-3 ヶ月程遅れますが.

世界の動き(情報)がわからないので.船便であっても定期的に情報を手に入れることができます.月々のお金

とても必要な情報源である.

は使用しなければとられません.無料で講習会も開いていますから，一度行ってみてはいかかでしょうか.
辻英夫
車庫利略

SEAMA1しの記事の内容がアカデミックすぎてす

いま.私の会社に待望の NEWS ワークステーション

こし違和惑があります.技術者の労務問題，作業環境，
キャリアパスなどもとりあげていただきたいが導入され. FRANZ L1 SP をゴチョゴチョいじ[編集部注 :SEAMA1L の記事は，基本的に会員っているのですが.マニュアルが全部横文字で悪戦苦闘からの自発的投稿で成り立っており，セミナーやイベン

しています.何かいい本(方法)があれば教えて下さい.

トの記録以外に.編集部企画の記事はありません.もし，
御自分の期待と遣うようでしたら，期待される内容の記

網野広水

事を柑やすために，まず，そのきっかけとな る原稿をお地方の会員としては，都会(? )で開かれる SEA の寄せください]各種の会に参加するのが.やや困雛であるが，それは単に個人の都合である.会が地方で開かれたら，東京・大
中小路久美代阪の方は困るでしょう?

これまで，自分が計算織に関わっていたにもかかわら

EAMA1 しに感謝.感謝.船便でも定期であれば文句ず.ソフトウェア業界というと.なんとなく関係ないとそれよりも，毎月(? )の S

なし.

いう目でみていた私ですが. SEA 会員になって半年，

今までこの偏見で随分損をしていたことに気がつきまし

重原千尋

た.

まだ駆け出しの私は.将来のために先量産方の意見を間

‑
3
2
‑

V
o
i
c
e
sfromMembers

S
e
a
m
a
i
lVo
l
.2No.4き，日進月歩のこの世界で目穫を見失わないために入会'岡俊一しました.当然行事への参加や原稿を送ることは無理な現状てすが.今後もよろしくお願いします.

東京以外の地で.東京と同等レベルの仕事をこなしていくためにはどのようにしていったらよいのかを，真剣に考えています . このテーマについての誌上討論会をぜ
水谷哲也

ひともお願いします.東京で仕事をしている人からの上要求定義.概念設計の段階で，いかにうまくエンド・記テーマについてのアドバイスも期待しています.ただユーザの要望を引き出すか.またエンド・ユーザ自身のし，ぱくぜんとした討論では意味がないので，テーマをもやもやとしたシステム・イメージを固めることができ

次のようにしぼってみたらいかがでしょうか?

るかが.その後のシステム開発の経費(期間・コスト)(1)必要とされる環境

短縮の一番大きな要因になるのではと感じています.イ(
2)東京に出先機関を設けることは必要か?

ンタビュー技術等に関するセミナーは開催されないので(3) 東京の SEA 会員の東京に対する満足-不満足度

しょうか?

(
4)東京との情報伝達ルート運用のノウハウ[編集部注:前述の熊谷さんの提案と同様ですが ， ぜ[編集部注:どんな講師のどんな話が聞きたいのですか?

ひ，具体的にアンケートの質問をデザインしてください.

事務局宛に具体的なリクエストをどうぞ]

そして，回答の分析もよろしく]
宮内興治
山崎佳

いろいろなイベントがありますが.平日の昼間に行なわれているものが多いように思います.なるべく.

19:00 以降にして頂くと参加しやすくなるのではないで

JUNET を用いて.

SEA のニュース・グル ー プを作ったらどうですか?

[編集部注:これもまた SIGNET へ]

しょうか?
[編集部注:分科会はそうなっています.セミナーやフォーラムは，会員サービスの他に，一般への活動 PR.

山城英彦

および会の運営のための資金調達を兼ねていますので，ハードな環境て'作業を行なっている技術者が多いと思どうしても通常の時間帯にならざるを得ません.ぜひ，いますが，個人のライフ - スタイルをどう守っていくべ

会社の教育予算を使って.堂々と出席してください]

きか悩んでいる人もいると思います . そこで，このようなテーマを取り上げて誌上討論をされたらいかがでしょう.管理上のポイントとなる項目が浮き上がってくるの

水野誠一

SEA 内部連続用に.パソコン・ネットワークを利用

ではないて'しょうか.

すでに運用しているオ、[編集部注 :SEA は労働組合ではないので，取り上ッ トワークの一部を間借りするとかすれば，技術的な問

げ方がむずかしいと思いますが.プロフェッショナル・

題もないと考えますが.

エンジニアの自己管理は.たしかに重要なテーマです.

する予定はないのでしょうか?

SEA 会員の方々ならば，かな

り多くの方々がこのようなネットワークを利用できると具体的にどんなテーマでみなさんの原稿を集めたらいい思うのですが.それとも，パソコン・ネットワークの普でしょうか?

及率はまだまだ低いのでしょうか?

けますか?][編集部注:ぜひ，ネットワーク分科会に参加して.
具体化を図ってください]

材置E嗣.

データフロー ・ モデルを利用したシステム設計支媛エ
キスパートシステムを設計中てす.よいアイデアがあったらお聞かせください.

‑
3
3
‑

そのきっかけになる一文をお寄せいただSeamanVol.2No.4

I
n
v
i
t
a
t
i
o
nt
oMorioka

第5回

夏のプログラミング・ワークショップへのお誘い
実行餐員長

野村行憲
岩手電子計算センター

第 3 回 (60 年 9 月)

1.はじめにこれからのソフトウェア開発を考える

第 5 回目を迎える夏のプログラミング・ワークショッ

三浦信之

プ(略称:若手の会 in 盛岡)が.今年は『パクのないソ

フトウェアの実現を目指して』をテーマとして，例年ど

61 名

第 4 回 (6 1 年 9 月)

プロジェクト ・ プランニングのケース・スタディ

おり夏の終わり (9 月 2 日 ~5 日)に開催されます.

堀江進

ワークショップの環境として，すなわち.エネルギッ

41 名

シュな若手プログラマたちが.日頃の業務を離れ.何かひとつの問題について.じっくりと議論を闘わせる場所

3. 今年の企画の特徴

としては，わがホーム・タウン盛岡こそ.もっともふさ

今年は，今までと趣を異にして.このワークショップ

わしいと考えます.きわやかな空気.静かな町並み.おの 08 (つまり 30 代のエンジニア)だけで運営スタッ

いしい食べ物，そして甘 ð なる酒・・・これだけそろえフを編成しました.それは，参加者との世代ギャップがば，あとは集まるメンバーの質だけが問題です.

ほとんどないことを意味します.しかも.それぞれソフ

みなさんも，ソフトウェア界の宮沢賢治や石川啄木になったつもりで. 9 月の虫に心を馳せてみませんか!
といっても.残念ながら. SEA の会員の平均年齢は.

トウェア・エンジニアとして，いろいろな分野の第一線で活擢中の強者ぞろいです.ですから.討論が，いままで以上に盛り上がるのではないかと期待されます .

今回のワークショッフ・の参加制限条件をやや(? )オー

討論の基調テーマとして.今年は，プログラマにとっバーしています.あなたが.もし.無資格である場合は，てもっとも基本的な問題である「パク J の問題をとりあどうぞ身近にいる若い方々に.この案内文と参加案内パ

げました.パクについてはすでに語りつくされたと思っンフレット (36 ページ)を至急回覧してください.

ている方が多いなかで，あえてこの問題を取り上げたのは.新しいプログラミング言語・パラダイム・ツール・環境などが次々に登場し，虫の穣息する環境も様変わり

2. 若手の会の歴史

若手の会のこれまでの輝かしい実績をご存じでない方のために，少しその足跡を紹介しておきます.

してきた今こそ.あらためてパグについて考え直す時期だと思ったからです .

このワークショップは.毎年 1m: 同じ時期.同じ場所

で過去 4 年間開催され，今年で 5 回目を迎えます.第 1

4. 予備的考案

回から第 4 固までの開催年月.基調テーマ.チェアマン(1)その分類と参加人数は.次の通りでした:

さて.ここでパグについて少し考えてみることにしま
しょう.パグはこの世にコンビュータが登場したのと岡

第 l 回 (58 年 8 月)崎に生まれ，以来，プログラマとのよき(? )隣人また

特定テーマなし

はライバルとして.~のようにつきまとってきたことは.
岸田孝一

47 名

いまさらいうまでもありません.
英語での bug という単語は「昆虫」という意味のほか

第 2 回 (59 年 8 月)

もしも私がプロジェクト ・ リーダになったらに.もともと「故障」とか「欠点」などの意味があり.

野村散次

本来こちらの意味で使われていると思いますが，日本で

50 名

‑
3
4
‑

I
n
v
i
t
a
t
i
o
nt
oMorioka

S
e
a
m
a
i
lV
o
l
.2No.4は「虫」と訳されていますので.その名にこだわって普うか?

通の昆虫と比較してみたいと思います.

(7)それぞれの分野で
昆虫

パグ

オブジェクト・オリエンテッドなプログラミングと従来の徳能オリエンテッドなプログラミングの場合では，デバッグ上の問題点はどう変わるか?また . A 1 を利用

よく移動する

ほとんど移動しない

役に立つものもいる

百害あって一利なし

したプログラミングの自動化やデバ ッ ギング ・ ツールな

五分の魂有り自我なし

ども.興味深いテーマでしょう . さらに. A 1 プログラ

殺虫剤で死ぬ特効系なし

ム自身のデバッグや保守をどうするかも.おもしろそう

単独で生きている

必ず何かに寄生するです.

生態解明が進んでいる

生態が鋼めていない
5. まとめ(2) バグの誕生?

このようにいろいろ考えてみると，話題がどんどん発

いうまでもなく，パグは生まれて来るものではなく，散して，議論のまとまりがつかなくなってきそうですが.

プログラマ自身が作り出し，プログラム中に埋め込んで参加される方々のポジション・ぺーパを拝見してから ，いるものにほかなりません.でも.どうして作り込んだ

ある程度の方向性を定めて，多角的で実りの多い討論がプログラマ自身が.そのことに気がつかないのでしょう

行えるようなプログラムを作りたいと考えています.

か?

このあたりにも解決の糸口がありそうです.

ワークショップのフォーマットについて，全員でのパネルとグループ討論との時間的バランスをどう取ってい(3) バグはいつ作られる?

くか，招待講演のテ ー マや時間配分をどうするかなどをパグの作り込まれるタイミングとしては，主として設

あれこれ考えていると.頭がだんだんパギーになってパ計時とコーディング時の 2 つが考えられます.それぞれ

グ・ハウスにお邪魔したくなりそうですが.各プログラの時点での対策は?

ム委員にご協力をいただいて，今まで以上の成功を達成

レビューの効果と限界は?

できることは.ほぼまちがいないでしょう .

(4)害虫駆除
デバックの方法にはいろいろありますが.それぞれの長所.短所は?

6. 始まりに向かつて

たとえば.開発用のマシンと笑行用のポジション・ぺーパの締め切りも.

7 月 27 日に迫っマシンが違う場合の効果的なデバックのやり方は?

てきました.

(5) 虫のないプログラム f

楽しみにしています.例年約 2 倍以上の狭き門ですので .

虫が緩んでいないプログラムは存在するだろうか?

くれぐれも遅れることのないように..目・30 歳未満のパリパリ・エンジニアたちからの自由で過激なポジション・ぺーパを.スタッフ一同

また.動く機会がほとんど来ないような虫がいたとしても，それは虫のないプログラムと呼んでいいか?

それでは 9 月の盛岡のさわやかな空気の中でお会いしましょう.

(6) 網戸プログラムの作成時にパグが入り込まないようにするための方策として.簡単なものでは，ロジック・スケル
トンの利用や既存モジュールの再利用などが.比較的多く利用されているのではないて' しょうか.また，ランゲージ・オリエンテッドなプログラム・エディタの利用も，
シンタクス ・ レベルのパグには効果があります.これらの 「 網戸」の自の大きさは一体どれくらいのものでしょ

‑
3
5
‑

C
a
l
lf
o
rP
o
s
i
t
i
o
nPapers
第5 回

夏のプログラミング・ワークショップ「バグのないソフトウェア」の実現を目指して
主催:ソフトウェア技術者也会 (SEA)
後媛社}情報サービス産業箇会{耳SA)

第 5 回目を迎える恒例の「若手の会in 盛岡」です.今年は.過去にこのワークショップに参加した 08 (つまり 30 代の現役

エンジニア)だけで運営スタッフを f構成し，ソフトウェア開発の現状が抱える問題点について，より生々しい議論を展開したいと考えています.

設定された討論テーマは広い意味でのパグのないソフトウェアはどうすれば実現できるか ?J というマクロな視点から.現状
を多角的にとらえることを意図したものです.具体的な論点としては，たとえば:・保守の困難さやパックログの増加をどう解消して行くか?
-パグの発生を防ぐために開発環境やツールをどう工夫しているか?
.AI やその他の新パラダイムはどのように役立つだろうか?

-要員の資質や教育訓練は製品の品質とどう関わってくるか?

・ プロダクトあるいはプロジェクト・マネジメントのあり方は?
. ソフトウェアの保護あるいはセキュリティとパグとの関係は?
など.いろいろ考えられるでしょう.

これまでの仕事の中での経験を踏まえた意見や提言を.なるべく具体的な形でポジション・ぺーパにまとめてください.多くの若手技術者からの積極的な御応募をお待ちしています.
開催要領
1.期日:

昭和 62年 9月

2. 会場:

ホテル・ニューカリーナ(岩手県・盛岡市)

3. 定員

25 名

4. 参加資裕:
5. 費用

2 日(水)午後から 5 日(土)正午まで (3ì自 4 日)

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

65.000 円( SEA会員. JISA会員入75.000 円(一般〕

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

実行委員長:

野村行憲(岩手電子計算センター)

プログラム委員長:

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

プログラム委員:

沢田寿美 (SRA)

月岡義範(中央システム)

松下和|逢(三菱電気東部コンビュータ)
7. 申込方法:

上述の要領でまとめたポジション・ぺーパ (A村井進(テクニカル・ライタ)他

4判 2~ 5枚)を 5部コピーの上.下記の申込票を添えて.昭

和 62年 7月 27 日(月}必着までに .フ・ログラム委員長宛お送り下さい.申込多数の場合(例年定員の 2~ 3倍の応募があります)には.プログラム委員会でポジション・ぺーパの内容を審査の上8月初旬には参加者を決定し.結果を全員に御連絡します.
ポジション・ぺ ー パ送付先:

干 160

東京都新宿区西新宿 3‑1
6 ‑ 6 西新宿水野ビル

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

技術部

藤野晃延

T
el
.
:0
3‑3
7
8 ‑8
0
1
0F
a
x
:0
3‑3
7
8 ‑7
2
9
8

第 5回

氏

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

名:一一一一一一一ーーー一一一ーーー一一一ー(年齢:一一一ー歳，位月 IJ: 男

女)

参加申込票

申込種別 (SEA

J1
SA 一般)

会社名:一一一一一一一一一一一一一一一一一一一一所属:一一一一一一一一一一一一一一一
住所〒

T
E
L
: 一一一一一一一 一一一一一一一ー一一ー一一一一一一一一一一一一一一一

C.J阻白rete.

S個øiaI Vo
I.
2N，・.4

SEA 会員状況(昭和 62 年 6 月 30 日現在)
1032名 (5月 1 日から 134名増〉

2

27社 (5月 1 日から悦日督。

主

4協道=

山形
宮城

=

岩手
福島

新潟
積木;

理事局

=

業績=

埼玉

写E

手量廃

=

京耳障

=

神奈川=
長野

z

g富山

石m
静岡

宮邑Z

時
震知=
泊ま山=

三.
滋賀
家信

"
"

大原
奈良

兵庫
震媛

徳‘

=
事=

岡山

広島

福岡

=

鰻本

=

大分
佐賀
宮崎

=

2
1

f=ちL

E~-y-~~

TT

卿

ソフトウェア按術者協会