1
.

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
Volume9 , Number

November, 1994

一一

目次
渡遁雄一

1

ソフトウェアシン ポ ジウム ' 94 最優秀論文賞 を授賞 して

田中敏文

2

ソフトウェア・シンポジウム '94 を振り返って渡遁雄一「ソフトウェア・シンポジウム特集号」の発行にあたって

3
6

S
o
f
t
w
a
r
eLe
m
m
i
n
g
i
n
e
e
r
i
n
g!
?
塩谷和 範

22

ソフトウェア・シンポジウム '95 にむけて

中野秀男

56

ソフトウェアシンポジウム '95 論文の書き方

佐伯元司

5
7

ソフトウェアシンポジウム '95 に期待すること

坂本啓司

5
8

SS95 ツール展示

佐藤正道

6
1

BOF の守・破・離

江谷典子

62

ロ ー カルアレンジメントチェアからのメッセー ジ

田中敏文

6
3

So食ware L
e
m
m
i
n
g
i
n
e
e
r
i
n
gSummary

これからのソフトウェア ・ プロセス・マネージメント

32

C
a
l
lf
o
rP叩ers
S
o
f
t
w
a
r
eSymposium'
9
5

6
4

ぬ ソフトウェア技術者協会
卿

So
f
t
w
a
r
eEnginωrs A
s
o
ci
a
t
i
o
n

ソフトウェア技術者協会 (SEA) は，ソフトウェアハウス，コンピュータメーカ，計算センタ，エンドユーザ，大学，研究所など，それぞれ異なった環境に置かれているソフトウェア技術者または研究者が，そうした社会組織の壁を纏えて，各自の経験や技術を自由に交流しあうための「場」として. 1985 年 12 月に設立されました.
その主な活動は，機関誌 SEAMAIL の発行，支部および研究分科会の運営，セミナー/ワークショップ/シンポジウムなどのイベン
トの開催，および内外の関係諸団体との交流です.発足当初釣 2∞人にすぎなかった会員数もその後飛躍的に増加し，現在，北は北海道から南は沖縄まで. 8∞余名を踏えるメンバーを擁するにいたりました.法人賛助会員も 40 社を数えます.支部は，東京以外に，
関西，横浜，長野，名古屋，九州，東北の各地区で設立されており，その他の地域でも設立準備をしています.分科会は，東京，関西，名古屋で，それぞれいくつかが活動しており，その他の支部でも，月例会やフォーラムが定期的に開催されています.

「現在のソフトウェア界における最大の課題は，技術移転の促進である J といわれています.これまでわが国には，そのための適切な社会的メカニズムが欠けていたように思われます. SEA は，そうした欠絡を補うぺ< .これからますます活発な活動を展開して行きたいと考えています.いままで日本にはなかったとの新しいプロフェッショナル・ソサイエティの発展のために，ぜひとも，あなたのお力を貸してください.
代表総事:

中野秀男

常任総司1 :

大場充熊谷章深瀕弘恭堀江進山崎和j 治

総司1:

青山幹雄市川寛伊藤昌夫白井義美江谷典子大塚理恵、菊地俊彰君島浩窪田芳夫小林俊明

坂本啓司酒匂寛篠崎直二郎杉田義明武田淳男田中一夫鳥居宏次中来田秀樹中谷多哉子西武進
野中哲野村敏次野村行憲平尾一浩平山伸一二木厚吉増井和也松原友夫山崎朝昭渡遁雄一
.務局長:

岸田孝一

会計監司1:

辻淳二吉村成弘分科会世話人環境分科会 (SIG聞V) :田中慎一郎渡溢雄一
教育分科会 (SIGEDU) :君島浩篠崎直二郎杉田畿明中園順三

ネットワーク分科会 (SIGNET) :大塚理恵小林俊明人見膚
支部世話人

関西支部:白井義美江谷典子中野秀男盛田政敏績山博司
横浜支都:藤野晃延北俊正顕野中哲松下和隆
長野支部:市川貧小林俊明佐藤千明
名古屋支部:筏井美枝子伊藤昌夫鈴木智平田淳史

九州支部: î武田淳男平尾一浩
東北支部: j菊地俊彰野村行憲和田勇
賛助会員会社岩手電子計算センタ-

NTT ソフトウェア研究所

アスキーエスケーデイ
さくらケーシーエス

オムロンソフトウェア

サン・ピルド印刷

NTT 九州技術開発センタ

PFU SRA

カシオ計算機キャノン新川崎事業所

ジェーエムエーシステムズ

ダイキン工業ニコンシステムニッセイコンピユータ

ジャストシステム

ムラタシステム

リコーシステム開発安川電機古河インフォメーション・テクノロジー構造計画研究所

三菱電機セミコンダクタソフトウェア三菱電機関西コンピュータシステム
新日鉄情報通信システム新日本製鉄エレクトロニクス研究所池上通信機中央システム

東芝アドバンストシステム
SRA東北

日本 NCD

東電ソフトウェア東北コンピュータ・サーピス

日本ユニシス・ソフトウェア

日本情報システムサーピス

日本電気ソフトウェア富士ぜロックス情報システム富士写真フィルム

富士通エフ・アイ・ピー

オムロン

富士通

SRA 中国(以上 41 宇土)

SEAMA1L V0 1
. 9 , No
.6ー7

1994 年 1 1 月 26 日発行

編集人岸田孝一

発行人ソフトウェア技術者協会 (S EA)〒 160 東京都新宿区四谷 3-12
τ'EL: 03-3356回 1077

丸正ピル 5F

FAX:03・3356- 1072

印刷所サンピルド印刷株式会社
干 162 東京都新宿区築地町 8 番地
定価 1 , 000 円 (禁無断転載)

MessagefromtheExecutiveEditor

8eamailVol.9 No.6‑
7『ソフトウェア・シンポジウム特集号』の発行にあたって
渡 i豊雄一*(8894 プログラム委員長)

8EA 恒例のイベントであるソフトウェア・シンポジウムも，今年で 14 回目となった 。 函館という北の地での開催というととで，参加者の減少が少からず心配されたが御蔭様で 100 余名の参加者を得て無事成功裡に終わった。関係者を代表して厚く御礼申し上げたい 。

今回，何故か私がプログラム委員長の 1 人にかつぎ出された訳だが，その理由は単に「事務局の手が少ないので，雑務経験が多少あって力仕事も出来そうな 30 代の 8EA の幹事の 1 人」ということであったようだ。そのよ
うな訳で，プログラムの構成や技術的な内容に関しては玉井先生(東京大学)にすべて面倒をみて頂いた 。 では，その他の仕事が出来たかというととれも疑問で，事務的なととでは相変わらず 8EA 事務局の中島嬢の手を煩わせ，進捗の管理や各種準備などについて経験豊富な他の PC の指導を仰いで，という体たらくであった。その替わりというにはおとがましいが，とのような多少なりともまとまった形の記録を残すととも意義があろうかと思って取り組んでみた次第である。だが，とのような記録が 8EAMAIL に掲載されるは，とれが初めてでは無い。最近では，市川さん(電算)が長野で開催された 8892 のパネルディスカッションの膨大な記録を 8EAMAIL

Vol.7, No.3 K ，しかも独力で残されている。只々感服するばかりである。今回はそのような過去の記録も参考にしながら， OOP8LA といった他の活発なシンポジウムの補遺集も横目で院みながら取り組んでみた次第である。とは言え，遅々として捗らないテープ起こしがなんとか終わってまとめの作業に入ると，結局は御発表

頂いたパネリスト諸氏及びフロアから発言して下さった方々の手を煩わせて文章の校正をして頂くという，万事が全てとの始末である。ど協力頂いた方々のお名前は誌面の関係で割愛させて頂くが，感謝申し上げる。
さて，余計な説明はとれくらいにして，以下に本編の構成を簡単に紹介して序に代えさせて頂く。

まず今回最優秀論文賞を授賞された田中敏文さん(オムロン)に感想を寄せて頂いたので，最初にそれを配置した。続いて，簡単だが今回シンポジウムの論文の傾向や発表の様子などを撮り返ってみる。
そして，今回の特集の中心にはシンポジウムでの 2 つのパネルセッション
イブニング・パネル

クロージング・パネル

8
0
f
t
w
a
r
eLemmingineering!
?
とれからのソフトウェア・プロセス・マネージメントの記録を据えた。とくに，イフ・ニシグパネルの方はその中でも紹介されたアンケートの集計を含む総括と， S
8のあと川崎で開催された討論会の報告を塩谷さん (8RA) が寄稿して下さった。今回の特集の目的の 1 つは，地理的な制約から参加出来なかった会員諸兄への情報の補完と考えているが，その面でも非常に有益な資料と言えよう。もっともパネノレディスカッションに関して言えば，本来は，きちんと要点を整理し箇条書にまとめて収録するのがスジであろうが私の力量ではとてもそこまで出来ず，とのような記録という冗長な形になった。その分，少しでも会場の雰囲気がお伝え出来れば，というのは言い逃れだが，何卒御容赦頂きたい。
なお，当初は『補遺集』として企画されたとの号が『シンポジウム特集』となったのは，例年以上にハイペー

スで準備が始まっている来年の 8895 の関係者から，熱いメッセージが多数寄せられているからにほかならない。是非とも奮って積極的な論文投稿/参加を会員諸兄にお願いする次第である。

.(株)アスキー OA システム郁

15‑17June1994‑1‑

AddendumtotheProceedingsof8894

最優秀論文賞を授賞してSeamailVol.9 No.6‑1

ソフトウェアシンポジウム '94 最優秀論文賞を授賞して
田中敏文ホ(2) 何故現場の人聞を説得 し巻き込めたのか?

“内容があまりにも泥臭かったので，最初(発表前)
はどうかと，思っていたのですが，発表で結構ウケてい→改善スタ ッ フとして，決して腰の退けた活動

たので，ひょっとしたらと ，思ってました。"

ではなかったし，また逆に技術の単なる押しつ
けでもなかった 。 現場に入り込んでいっしょに函館で，最優秀論文の発表と表彰があり，その直後

問題点を見つけるという姿勢で，今回の改善にに PC 委員長のアスキーの渡遁さんからマイクを差取り組んだから 。

し向けられ，最初に私の口から出た言葉です。後で(3) 何故効果を数値化できたのか?

同僚から“ひょっとしたらもらえるかも，なんて言う→改善プロセスの中に効果が測定できるようか一?"と言われてしまいました。

な仕組みを組み込んだから。

でも，発表中の開発現場の混乱状況の説明に対する聴衆の笑い交じりの反応もさることながら，発表後

K ，多くの方々が歩み寄って来られて，質問やら“面白かった"と言う感想やらを頂いて，なんとなく手応えを感じていました。中でも，今シンポジウムのパネノレで仙人と紹介された某氏から，面白いというか手厳

とれらに関する技術的な内容については発表の中で触れていましたが，スタ ッ フとしての姿勢の問題としてい )~(3) K 対しでもう少し突っ込むと，次のよ
うなととが言えると思います。すなわち，

しいコメントを頂きました。

“発表ネタとして脚光を浴びる多くのテーマは，比較的レベルの高い組織(プロセス成熟度で言うとレベ“オムロンさんほどの会社でも，まだあんなととろで苦しんでいるの?うちの 08 グループでは 1970 年
代に解決している問題だよ。ハー。でもまー，うちの会社だってまだまだの所もあるけどね。ハー。"

自分自身で自分の成果を分析するのは恥ずかしくてくすぐったいものがあるのですが，今あらためて，
何故最優秀論文賞という栄誉が頂けたのかをじっく
り考えてみますと，

ル 3 以上)に対して効果のある高度かつ先進的な技術を取り上げたものなのですが，実は多くの組織(たぶん 9 割以上の組織)では当たり前と思われる技術の移転がなかなかできていなくて，発表したような泥臭い問題で苦しんでいるわけです。今回発表した内容は，
この部分に対し目をそむける ζ となく，結果に対する責任を負う立場でプロジェクトに参画し，成果を挙げたスタッフとしての改善活動事例なのです。"(a) 現場-の混乱したプロセスを図や数字で示し，多ととまで，自分で書いてしまうと，読んでる皆さん

くの現場で苦労した経験のある人の共感を得た。

はさぞかしうんざりなさる ζ とでしょうが，実は先述(b) 理論的には目新しくもない技術を，現場に導入・定着させるためにプロセスの図式化や数値化(メトリクス化)をし，現場の人聞を説得し巻き込んでいる。

の仙人さんのコメントを，読み返して下さい。 000。

どうです，同じととをおっしゃていたというととがお分かりになるでしょう。ハー 1 。
ζ れで私の独断と偏見に満ちた授賞の言葉は終りたいと思いますが，最後に，発表の準備のために，唯(c) その効果を，数値でもって証明している。

一函館山にガスのか かっていなかったシンホ・ジウムなどが挙げられると思います。さらに，とれらの要因

初日の夜に，夜景を見るととが出来なかった怨み 2 ををもっと突き詰めると，次のようなととが見えてき申し上げておきます。

ます。

(1) 何故共感を得たのか?

1 イ山人さん，勝手に解釈してどめんなさい。
2 誰に対するものでもないのですが→まさに皆とういうレベノレの低いととろで苦しんでいるから・オムロン(株)EFTS 統鯖事業部開発センタ第 2 開発室

SoftwareSymposium'94‑2‑

北海道，函館

8894Impression

8eamailVol.9 No.6・ 7

ソフトウェア・シンポジウム '94 を振り返って
渡遁雄一本(8894 プログラム委員長)

O
.

はじめに

も，その分，夜の情報交換パーティ 3 で盛り上がっていたようだ。まあ，シンポジウムの最初のセッションとソフトウ ェアシンポジウム '94 を簡単に撮り返ってみる。立場上，一個人としての感想を述べると言う無いうのは誰でも緊張するのだろうが。

責任なととでは済まされないようだが，かといって大とのセッションでは，小室さん(日立ソフト)の，論文

層なととを書けるわけでもない。また誌面の関係もに書かれていない適用例の具体的な部分の話が興味あるので，何から何まで網羅してとと細かに，という深かった。

わけにもいかない。まあ，ともかく滅多に出来ないプ
2.

ログラム委員長という立場から，その自に映ったとと第 2 日 (6 月 16 日)
昨日と同じく良い天気。 北海道というととろは日を ， 思いつくままに記そう 。

本の一番北に位置しているとともに東に振れている1. 初日 (6 月 15 日)とともあって，朝が早い。そのせいか，町全体が動き

ちょっと汗ばむような日射しの函館空港 K 降り立っ出すのがとても早いように感じた。今回の 88 は，実て五稜郭の辺りを散策してから市電に乗って会場近質 ζ の 1 日に詰め込まれていて，集中出来る反面，緊くの停留所まで行き，そとから徒歩で 5 分弱の港に面張を維持出来るかちょっと不安である。資料を持っしたレンガ作りの倉庫街にある会場(金森ホール)にてセッションの開始 (9:30) に遅れないように歩いて辿り着く。しかしさすが(?)北海道，風がそよぐと暑15 分ほどの会場に向かう。

くもなく寒くもなく調度良い。

2.
1
1.1 オープニング，招待講演

セッション 2 :プロセスとのセッションには，いずれも水準以上の，そして型通りのオープニングで順調な滑り出し。続いてまたそれぞれに個性的なものが集まった。青山さん

玉井先生の司会で，槙上先生の講演。とれも本当は詳(富士通)のものは，経験報告の書き方の 1 つのお手

細にレポートすべきなのだろうが，講演の内容は論本とでも言えるだろう。自分でも何人かの人に論文文集に書いて下さった内容1 に沿ったものであったのの投稿をお願いしたが，で，テープ起 ζ しのボランティアの手が足りないとと書きにくい。特に状況をある程度説明しないと読者もあって割愛させて頂くととにした。 2 特 K ，棟上先に伝わらないであろうし，それではそれを書いてしま生の話は，一部の限られた所では同様の講演などもさうと機密の保持などとの絡みもあって」というにとれているようだが， ζ のように開かれた場で，喋ってとを少からず言われた。氏の場合には，自社で中心に頂くことは少く，その意味で良かったと思っている。

1.2

セッション 1[""色々とまずいととがあってなってやっておられるととで，このような制約は下請けの者と比べれば，はるかに少ないであろうが…。

:CASE

しかし，それを差し引いても話のディフォルメの仕方

初日に組まれたペーパセッションはとの 1 つだけというようなととも含めて的確に読者に読ませる素である。いずれも興味があったがちょっとした進行

晴らしいものだと思う。

のもたつきもあって，時間不足になって議論が十分

一方，田中さん(オムロン)ほかのものも，青山さにされなかったととと，最後に発表に立った伊藤さん

んのとは違った意味で経験報告の民力を示した一級(MA8C) K しわ寄せが行ってしまったのが残念。でのものと言える。特 K ，ある箇所に意図して摘要した‘(株)アスキーOA システム部

1 今回は，との講演も 2 つのパネルセ ッシ ョンも全てあらかじめ改善が予想しなかった所に波及し，それが全体として予定されていた方々には，お忙しいにも関らず論文集のために奮より良い効果を得たというデータを適宜示している

いて下さった収録するととが出来た。

のは，会場から少なからず共感の意志表明があった。

2 講演の後の質疑応答が面白かったとの声も聞かれたが，マイクまた当然ながら，今回の論文の中で扱われているととできちんと拾えていないので今から記録として整理するのは大変な労力が必要となる .

1
5‑
1
7June1994

3 隣の棟にあるピアホーんで行なわれた.

‑3‑

AddendumtotheProceedingsofS894

5594Impression

5eamailVol.9 No.6‑7の 土台にな っ ている も の前には，最低でも 1 年の表にた ， ゃったものでないとわからない難しさが潜んでいとのようなるからだろう 。 また，今までどちらかと言うと表舞台

問題にアプローチしている現場の実務者には，大変貴に登場しなかった分野から の 論文投稿や参加があ っ

重なデー タ が盛られている 。 また，発表もとても素晴

たととは喜ばしい 。

は出な い データの蓄積があろうと思う 。

しかし，その分野に造詣のある者でも，個々に使用

らしか っ た 。

されている用語のニュア ン スの解釈には少からず違

2.
2 セッション 3: 品質・見積りいがあったようだ 。 仕様の話は，真面目にやると本当ととにも高水準のものが集まった 。

しかしどうもに時間がかかる 。 発表者らが，厳密にある種の代表的といって，他 κ 得

な手法を使つてのととならばいざ知らず，大抵はそれ意な分野がある訳でもないが・・・ 。 その理由の 1 つらを現場に併せて修正摘要したり，また新たな提案は，ある程度の規模のプロジェクトに参加した経験がだったりするわけで，それを短い説明の中でどの程度無いので，そとでの品質管理の問題が皮膚感覚として伝えられるのか…。

私は個人的にはとの分野が苦手だ 。

今一つ理解しきれていないととにあると，思 っ ている 。

一方，技術論文としては形式仕様記述に関する 2 点

三宅さん (NTT) ほかの論文は，かなり大きな規模だった 。 今回の SS での発表の中で元気のあったのはと高品質を要求されている立場での，ソフトウェア作

いずれも，数少い女性の方の発表だった 。 しかしそれりにおける提案である。論文も発表も立派であった 。

でも形式的な手法の発表は(今回の SS に限らず)会

特にど本人は， 1 つの提案なので討論をされたいとの場が重苦しくなる 。 今回もその傾向はみられた。厳ζ とで，発表も簡潔にまとめられたが，裁ききれない密な議論や証明は予稿集にきちんと盛り込んで，発ほどの質問や意見が飛び交うという所までは残念な

表は観点の筋道を説明するととを中心にした方が良がら至らなかった。思うに，そのようなととを議論すいだろうと思うのは素人の浅はかさな了見だろうか?

るほどの品質を求めずに漫然と仕事をしている ソ フ
トウェアの現場が少なくないのでなかろうか?。

2.
4

セッション 5 :人間的要因

一方，高橋さん(電力中研)ほかの論文は，彼が長最後のセ ッ ションのタイトノレはちょっと ζ じつけといこと取り組んでいるテーマの 1 つの中開発表的なも言えなくないが，今までのセッションの枠組みでは色彩が強いものと言える。それは， Cobol 系の言語の捕らえきれない領域のもの。 ζ の中では，今回採録さFPA による実践的な適用に答を携えてきた，とでもれた唯一の英語の論文である Reeves さん (SRA) ほ

表現すれば良かろうか。論文としては経験報告の色かのものが高い評価を受けていた。ただ残念なのは，彩が強いとの声もあったが，表現の的確さなど書き方発表された共著者の中小路さん(コロラド大)が久々は一級品。

の日本語で緊張されたのか，やや導入部の説明が冗長

こんな 2 つの論文に負けじと出てきたのが，岡田さん(富士ゼロックス)のもの。乙の論文は，失敗をきちんとまとめて下さった ζ とである。質疑応答では，いくつか的外れな意見も飛び出したが，現場の苦だったので，肝心の後半の説明が駆け足気味になったととだろう。

2.
5

塩谷さんの総括を参照して頂とれとのイフ.ニン

労を立派にまとめている点で，敬服する。但し，分析のアプローチがこれで本当に適当だったのかとか，さらにとれだけのデータでもっと別の分析がや予測が出来たのでは，との声も一部にあった。いずれも，今後への成果の期待へのエーノレと受けとって欲しい。

イブニング・パネル

グ・セッションは，今回の SS での初めての試みであった。パネルの出来としては，まあまあではなかったかと思っている。

が，セッションが終わってから繰り出した先で店に入って一息つくと，もうラストオーダだと言われたの

2.
3

セッション 4: 仕様

経験報告として出てきた 2 つは，ともにマイコン制御分野からのものであった。そのためか，会場から出は参った。函館の町の時間の流れをもっと調べてプ
ログラムを編成すべきだったと後悔することしきりである。

た質問/コメントは発表そのものの周辺を捕らえたものが少なからずあったのが印象深い。査読段階では

3. 最終日 (6 月 17 日)
特に天気が悪いとは思えないが，よくよく回りを眺

出されなかった無かった視点での意見交換が一番なされていたように思うからである。特に，組み込みソ

めると山で会うのとは違った不思議な感覚を覚える

フトというのは，モジュールサイズや応答速度といっ霧に覆われている。そのため，空港に飛行機が降りらSoftwareSymposium'
9
4

‑4‑

北海道，函館

SS94Irnpression

S
e
a
r
n
a
i
lVol
. 9 No.6‑
7

れず千接空港に行っているという。というととは帰しかし，最優秀論文に選ばれたものを改めて読み返しれないじなんて心配をよそに最終日の唯一のプログてみると， 88 のための経験報告のネタはみんなの足

ラムがスタートする。

元にとろがっているととが良く分かる 。 そして，ネタ

3.
1はきっかけにしか過ぎず，そのネタを育て成果 K 結び

クロージングパネル

付けるよう努力せねばならないととも。

乙のパネルは，当初は I809000・ 3 などの規格の周辺に関与/精通している数名を招いて‘一発触発'の議論になるかとも思われた。しかし，残念ながら，丁度同じ時期にカナダで開催された国際会議と重なったために謂整がつかなかった。そのため当初の目論見とは視点を変えたパネノレになった。テーマの設定及び人選に関しては，司会をお願いした大場先生(広島市立大)にす っかりお 世話になった。
会場からの反応は，兼子先生と桑名さんという普段の
8EA のイベントではお目にかかれない 2 人の発言が予測出来ないことと，パネラそれらの話に説得力があって，それをフォローするのに精一杯といった感が無いではなかった。しかし，ちょっと長いかなあ~と

そんなととを考えながら読んだ論文 K ついて言及

しておくと， (まあ投稿されたものを読んだというのが初めての経験だったとともあるのであろうが)書き急いだものが少くなかった。それが文章としてこなれていないという程度ならまだしも，文章として推敵してから他人に見せるものにするのは，最低の礼犠かと思う。査読を依頼された方は，行聞を読みとるべく対するわけであるのだから。逆 K ，例え部分的 K 至ら
ない点、があったとしても 3 査読者からのコメントをもとにより良い論文に改訂されてくればなんら問題ない。そのような論文がカメラレディ原稿を届けて頂いたときは，委員として苦労した甲斐があったかなあと喜ぼしかった。

考えて設定した時聞が短く感ぜられる，充実したパネルだったと思う。

5
.

おわりに

ある雑誌の広告に，秋山仁さん(数学者)のエッセ

4. 全体を振り返ってイが載っていた 。

今回のシンポジウムの特徴の 1 つに“シングノレト
ラ ック"のプ ログラム編成が上げられる。結論から言日本人は高度経済成長の頃から子供達のうと，とっても良かったと思っている。 1 番のメリ ッ

教育に関しでも，合理性と効率性を追求

トは，聴きたいセッションがパッティングする ζ となした結果，平均水準の高い能力を育てる

く，自分の聴きたいものをすべて出席できるからであことには成功しました。ユネスコの調査

る。まあ，普段だったら聴かないようなセッションにでも日本の中学生の計算能力，正答率等

参加するというのも，年に 1 回くらいはあっても良いは世界中のトップです。

なあという感じである。もっともそれも，厳しい査読

けれども，日本が「とれは， ζ う解く」とを経て採録論文ばかりだからなのかもしれない。今決めて，天下り的に知識を丸暗記するマ

回，初めて“全論文のみ"で審査という英断をされた

ニュアル人聞から脱却して自分の目で見，玉井先生に対して，また，忙しい中で投稿して下さっ

心で不思議を感じる感性を養わなくては，た各位に感謝する。

とれからの世界のリーダーにはなれない

さて，全体を通して聴いてみて遅蒔きながら解った
ζ とは，と思います。

r みんな同じようなととで悩んでいて，それぞれ特徴あるアプローチで問題解決を試みているの本号の後半に見られるように来年の 8895 は積極だなあ」という ζ とである。そういうととも含めて，的かつ順調に準備が進んでいる。目先の技術も仕事

技術者が交流する場として特定の狭いテーマで開催のためには必要だが，それ以上に技術者の交流を通されるのとは別の，しかも査読のされたペーパを中心

じて“感性を磨く場"として， 88 が来年以降も 8EAに進行してゆく会識は貴重なんだと改めて思った。そのメインイベントとしてさらなる成長を遂げてくれのような訳で，逆に気になったのが，経験論文におけるだろうととを願って，拙い回想録の筆を置く。

る題材の表現の仕方である。題材としておもしろい
のに，分析のドフオノレメの仕方で(極端に言えぽ)そのでの成果が結果として物足りないといったととも出てくる。他人に訴えるというととは難しいものだと改めて感じた。

15・ 17 June1
994

‑5‑

AddendumtotheProceedingsof8894

SeamailVol.9 No.6・ 7

イブニング. /，ネル

SoftwareLemmingineering!
?*
パネリスト:長崎祥 f

伊藤昌夫 5

熊谷章 I

Gerhard Fischer 旬

塩谷和範 11

司会:

司会(塩谷)

ゲスト

まずテーマ の Software L
emmingineerｭています 。 AI 畑と いっ て いいの ですよね ? まず最初

irig ですが， IEEESoftware の咋年 9 月号 K 出て い た，に，彼の視点から Software Lemmingineering につい

4 ペ ージ の コラムで， 筆者は Alan Davis です [1] 。元て，意見を聞いてみたいと思 い ます 。

のペーパを読んでら っ しゃらない方も多いと思いまは日本語でなされるわけです 。 それを逐 次通訳するのすが，大ざ っ ぽに，表1 があれば，一応，概要だけは分

はパネリストの顔ぶれをみても不可能じ ゃ ないかとかっていただけると思 い ます。

との表の Davis さん

思いますので，フィ ッ シャーさんは，最初 K コメ ン トをの評価が絶対だと主張するつもりはありません。単

頂いた時点で取り敢えず解放してしてあげるととになる 1 つのネ タ にした い と思います。

しましょう 。 次に，壇上に並んでいるパネラの方 々 に ，しかし， パ ネル

で，今さらながら ， 私の解釈を簡単に説明します。

御自分の主張を展開していただきます。 そのあとは，

Davis さん自身は，との表以外I'C [1] の中で説明して会場のみなさんの御意見を，たっぷりと時聞をと っ ているのですが ， 例えば(表では)上から，構造化， 00

聞きたいと思います。ただ，司会者の私が言うのもな.

と分類されていますが，との分類そのものも 1 つんですが，個人的に，乙の話はまとまらないんじゃなの視点から切った分類でないのは，お分かりだと思いいかと思っているんですが，とにかく始めましょう。

ます。 そういった意味で，何が危険度 (risk) なのかとそれではフィッシャーさん，コメントをお願いします。

か，何が引合い度 (pay- off) なのかとかは， Davis さん

フィッシャ _2 (コロラド大)のペーパでも厳密に定義していません。

本語が出来なくて恐縮しています。 日本に来て，困るζ ちらに来てから，日

また，昨日お願いしたアンケートには「あなた/私度に「今度とそ，日本語を勉強するぞ」と固い決意で，は，どれくらいレミングに近いのかなあ ?J という意

ポールダーに帰るのですが，日々の雑事に追われて，味あいで「レミング度」という分類を付けてみましまたポールダーで日本語を喋らなければいけない必た。約 40 人の方からど回答頂きました。細かい集計

要性は非常に低いので，ついついサボ ッ ています。

まず，最初に， ζ の Davis の記事 [1] に関してコメは終っていませんが，相対的に皆さんのレミング度ントさせて頂きます。まず，初めにこの記事を読んだは低かったように思います。

当然ですけれども，アンケート項目にある「構造ときに思い出したのが， FredBrooks が 4-5 年前に化」というのは昔の話で「構造化なんて当り前の時書いた「ソフトウェア工学に，銀の弾丸は無い (No代からやっているので私は知らない」と書いておら

S
i
l
v
e
rB
u
l
l
e
t
)
J [2] でした。で，との Brooks の記事れる方もいらっしゃいます。 つまり，当り前になってに書いてあったととは，ソフトウェア工学というのは，いるので，それを自分のレミング度が高いと書いた方非常に難しくて，どんなメソ ッ ドを用いようが ， どんもいますし，逆に当り前になっているので書けないなツールを用いようが，絶対にソフトウェアエンジニ
アリ シグが簡単になるというととは無い，というととと記入した方もありました。
あまり私だけが喋ってもしょうがないので，会場に，でした。

もう 1 冊，本を紹介させて頂きます。トーマス・クー

GerhardFischer さんが，コロラドからいらっしゃっ• 1994 年 6 月 16 日

ンというアメリカ人の書いた「科学革命の構造 (The

18:30 ‑ 20:
50t(旅)ピジョシ・コーポレーシヨン

S
t
r
u
c
t
u
r
eo
fS
c
i
e
n
t
i
f
i
cR怠volutions) J という本の中SMHI エアロスペースシステムズ(株)で，人類の歴史を振り返ると，人々は何かパラダイム*(妹)PFU'

Prof・ ssor ，Ins也 i官U官・Departm・ nt

of Cogni色 iv・of Compu七・ r S輅en and
Dir ・ çtor of C・ nt ・r

Sçi ・ nç ・，for Lif ・ long L・ arning 回d D・ sign (L3D) ，百niv・ rsityof Colorado at Bould・ r
1
1(株)8RA
1 [編集部注18894 論文集 pp . 175 あるいはそれを補足した本号
のき匝谷氏の記事の表 .1 レミングの軌跡を指す

S
o
f
t
w
a
r
eSymposium'94を作り上げて，そのパラダイムに従うわけですが，時間が経つうちに，そのパラダイムが変ってゆくとが書いであります。ですから，との「レミンジニアリング」
2 通訳は，フイツシャーさんの所で研究されている，中小路久美
代さんにお廠いした‑6‑

北海道，函館

8eamailVol.9 No.6‑
7

イブニング・パネルという傾向は，ソフトウェア工学に限らず，あらゆる面白くなってゆくのではないかと現時点で思われて人類の歴史に於てみられる傾向なわけです。

いる分野です。

ですから，問題となるのは，他の人がするから自分

例えば，との右端の列は，コンピュータが“どとに在っr 宗教」なのか，それとも「科学」たか?"という変遷です。まず，メインフレームがあっ的な前提に基づいたものなのか 73 そのどちらなのかて，ワークステーションがあって，ラ ップ トップに変っというととを考えるととだと思います。その観点かて，そして今日，ペン・ベースのパーム・ト ップ・ コン

もするというのが，ら，ソフトウ ェア工学 の歴史を振り返ってみ ますと，

ピュータなども出てきています。例えば，アメリカで確かにある種，宗教的な傾向がある。例えば，ある偉

すと，将来どうなるかというと，ととにも，そとにも，い先生が“あるメソッドを使うと，またあるパラダイというように点在する (ubiquitous computing) のでムを使うと，ソフトウェア工学の問題が解決します"

す。結局，コンピュータが見えなくなってしまってとと言うととによって，みんなそれに飛びついてしまいう状況に今後なるであろうと思われています。

また，一番左はじのドメイン指向型 (domain oriｭい，そのパラダイムを使ってきてしまったというととented) の言語環境ですが，とれはコンピュータそのもです。

例えば， 1 つの宗教的傾向の例が，プロセス・プロのが，業務の後ろ側に隠れてしまい，コンピュータを

グラミングにみられます。 7~8 年前に， ICSE で言わ使っているという感じではなくなり，単に業務を遂行れ始めたプロセス・プログラミングというパラダイ

しているというふうに変ってくると思われます。

ムに沢山の人が賛同して，コミュニティーを作り上げ

ζ れまで，私どもの研究室では，ドメイン指向型のました。そのコミュニティーの内側の人達は，ある種，

設計環境というものをずっと研究してまいりました。

宗教的な信仰者になってしまって，一方でそのコミュ

ここに 1 つのスクリーンの例を持ってまいりました。

ニティに属していない人達が，そのプロセス・プログ

何人かの人達は「台所設計」というのを永い閉してきラミングの是非に対して科学的に論争しようとするましたので，それを期待されるかもしれませんが，どと，宗教的なパワーに押されて，なかなかその科学的めんなさい。とれはネットワークデザインです。 1990

論議が出来ませんでした。

年に，京都でのソフトウェア・シンポジウムにお招き

先にも，申し上げましたように，との傾向は，ソフ

頂いて，その際に詳しく，とのドメイン指向型の設計

トウェア工学に限らず，他の科学分野でも言えるとと環境のアイディアについては述べさせて頂きましたです。例えば，私が属してきました AI の分野では，[3 ， 4] ので， ζ とでは，簡単に説明します。との設計

10 年程前に，エキスパートシステムが現れて，r 何か

環境では，コンピュータネットワークを設計します。

難しい問題があったら，全てエキスパートシステムをとの左下の部分にカタログという部分があり，既に作りましょう」と，みんな信じてきた訳ですが，今に設計したものを貯めておくライブラ P のようなものなって，“とれとれとうしてとうなる"と，完全によです。

く分かっているドメインでやっと作れるくらいで，他能です。とのアプローチを用いて，いくつかのドメイの実際に難しい部分の問題では，エキスパート・シス

ンに構築してきましたが，それを改めて解析して，どういうアプローチで我々が環境を作ったかのプロセ

テムは完全に失敗しているわけです。
とういうととを踏まえて“じゃあ私達がどういうととを信じているか?"というととについて，少しお話

とれを使うととによって，例えば再利用が可

スを解析した結果が，ととにお見せしているプロセス
モデノレです。

したいと思います。そして最後 K ， A
lanDavis 氏の“種を蒔いて，それが徐々に進化していって，もう 1

書かれましたレミンジニアリングの記事について触

回種を蒔き直す。"というプロセスです。それについれたいと思います。

て簡単にど説明申し上げます。

との表3 は，過去に渡って 4 つの角度から見た計算

皆さん，もうど承知のととかと思いますが，ソフト機環境の変化についてまとめた表です。言語，ユーザ，

ウェア開発にかかる，一番のコストというのは，実は，

メタファ，どとに物理的にコンピュータが存在するの新規に開発する部分ではなくて，ソフトウェアを Pか?，というととの変化をまとめたものです。との線

P ースした後に，ずっと断続的に生じる t改善とか保より上が今まで歴史的に起とってきた進化，それか守という作業にかかるコストの方が大きなわけです。

ら今日の状況を表しています。との線から下の部分とのシステムを解析するに従って，多くのソフトウェ

が，とれから起とるであろう新しい方向性ですとか，

ア・システムの開発プロセスに応用するととが出来

3 フィッシャ一氏が用意した OHP は、残念ながら編集作業に間るととが分かりました。それでは UNIX を例にとっに合わなかった。

1
5‑
1
7June1994‑7‑

Addendumt
otheProceedingsof8894

SeamailVol.9 N
o.6・ 7

イブニング・パネルて簡単に説明します。

で もなく，質の高いソフトウェア エ ンジ ニアを見 つけUNIX の例では種蒔き (seeding) のプロセスは，る とと だ，という結論でした 。両方の調査 で，そのよUNIX を開発した AT &T の人と (UNIX を作って出うな同じ結論が出ていました。

来たアプリケーションのユーザではなくて) UNIX 自青山(富士通)体のユーザである我々研究者との共同作業で UNIX

グラミングなどの ように ，小さ なコミュニティを追っシステムが出来上が って来ました。過去， 15 年以上て いっ てしまったのでし ょうか?

何故， 産業界は簡単にプ ロセスプロ

にわたって USENIX なるユーザコミュニティが形成

フィッシャークーン が言っているように，人 聞は誰され，その中で UNIX を使ってゆくうちに，徐々にか他の人がしているパラダイムをどんどん追いかけてツ ール群と かコ マ ンド等を構築してきました。

ゆく，という性質があります。例えば，あるコミュニ

再種蒔き( re-seeding) のプロセ スではusenix など

テ ィ に属しているととが，何 か知的な家庭 (intelligentのコミュニティで構築されたツールのどの部分を次

home) に属しているように感じられ，そのコミュニのパージョンの UNIX のカーネノレとして装備するか?

ティに属していないと，ま るでホー ムレスのような感といった ζ とを検討す るという re-seeding のプロセ

じられてしまいます。ちょうど小さい子供が両親のスがサポートされます。

する ζ とをずっと真似してゆくように，ポスとか前任との， UNIX の場合はユーザがコンピュータのエキ者があるパラダイムに従っていると，その通りにして

スパート/プロフェッショナノレでしたから UNIX ユー

いないと不安に感じてしまうという ζ とです。人聞

ザ自身が自分でプロ グラミングをし て UNIX の環境

は，そういうものだと思います。

を徐々に進化させてゆ く ζ とが 出来たわけです。しか

青山科学と工学の違いは，科学では，定理を打立てしこのモデルを実際に他のアプリケ← シ ョ ン ドメイてそれを証明するということがありますが，工学のンに応用した場合には，そのドメイ ンの エキスパート

中には，そのような正しい答とか間違った答とかを証はコ ンピ ュータのエキスパートではありません 。と明する手段が無いので，レミング効果が生じ易いのでの場合，とのプロセスが 徐々に進化する( e
v
o
l
u
t
i
o
n
a
l

はないしょうか?

growth) 過程で，エンドユーサ・フ・ログラミングですとフィッシャー

か，エンドユーザコンビューティングといった手法が

S
c
i
e
n
c
e
so
fArtificial という本があるのですが，それ非常に重要になります。

を例にとりまして説明します 。

ハーパート・サイモンが書いた The

AlanDavis の記事に戻りますが，正直申し上げて

自然科学とコンピュータなどを使った The S
c
i
e
n
c
e
s

との記事はあまり大したことは無いと思 い ます。FredofArtificial とでは，設計 (design) という違いがあっ

Brooks の書いた「銀の弾丸は無い」の記事の方が，て，設計に於ては，正しいとか間違っているといったもっと深く問題を追求して広い範囲で語っていたの証明はありません。したがって，レミング効果についですが，との Alan Davis の記事は，まあまあかなあて，哲学者のカール・ポ ッパ ーの言葉を引用します。

という感じです。

“例え自然科学であっても，科学の発達というのは間

例えば，との表を見て頂 く と判りますように，ま違いを排除するととで発展している。アインシュタ

ずとの low /mid/high という危険度 (risk) と見返り

インがニュートンを越えたのは，その間違いを発見し(benefit) ですが，好き勝手に付けてあるなぁと思いまたからだ。"

すし，第一，誰にとって危険で誰にとって見返りがあ藤野(富士ゼロックス情報システム)

るのかが，そもそも明確でないのです。一番費同しがインシュタインが登場したので， ζ こでソシュー Jレ

たい点は，記事全体が“機掛から見たソフトウェア工を出したいと思います。

ポ ッパ ーやア

学"という形で書かれているように思えるととです。

結局今，フイツシャーさんが“パラダイム"として私達の経験から，ソフトウェア工学というのは“人本言及した部分というのは，すでにソシュールが言及し位"であるべきだと思います。

ていて“言語共同体というのが形成出来ない限りは，

私が 3--4 年前に出席した会合で，玉井先生(東京そ ζ で新しいムープメントは無いのだ"というとと大学)と野村さん (JIP) だったと思いますが，何がソを，彼は随分前に言っています。したがって，ある言

フトウェアエンジニアりングの生産性を上げるのか，語自体が，自然に思えるようになるのと同様に，ある

どういうプロジェクトが成功したかという調査があパラダイムが自然に思えるようになるには，そのパラ

りましたが，そのときの結論では，一番キーとなる要

ダイムを信じるという，言語共同体が出来ないとしょ素は，プログラミシグ言語でも，プロセスでもマシンうがない訳です。最近では，その言語共同体というの

S
o
f
t
w
a
r
eSymposium'
9
4

‑8‑

北海道，函館イブニング・パネル

SeamailVol.9 No.6‑1は，乙と 10 年くらいの問に生物学的な見地からの研は)当り前のように考えていました。ですから，との究で Autopoiesis という考え方が出てきているので表の中の，再利用は，オブジェクト指向の中に取り込すが・・・

まれてよいのではないか?と思いました。

フィッシャ一確かに，仰るように共通の話題に興したがって 3 オブジェクト指向を取り入れた時 K ，味を持つ人々が共 同体を形成する 際には，共通の言語

まず開発コストが劇的に下がるのではないか?。とれを開発し，概念の共有化を図ります。 しかし，問題は，は当然，部品の再利用という ζ と，オブジェクトの再

我々の経験を越えるような大きな変革に対してどう利用というととに絡んできているんだろうと思いま

対処していけばよいのか，追従していけるのかというす。しかし，ただオブジェクト指向を取り入れたからととです 。

といって，すぐに再利用性が高くなって開発コストが私が 1974 年の IFIP コンフアレンスに出席したと下がるか?というと，答は多分“No" であろう。

き，勺 980 年 K FORTRAN は生き残っているか?"というパネルがあり，誰もが私は， Smalltalk という言語を使っていたのですけ「そ んなととあるわけがれども，その言語に於て，例えばオブジェクトの色々ない 」 という結論が出ました。そとで興味深いのは，なクラスを使って Pad などを作ってゆきますが，再トップクラスのサイエンテイスト達が，頭を寄せ合っ利用可能なクラスを作ってゆくというのは，最初はて考えて，存続を否定する結論を出したにも関わら中々一度で再利用可能なものを作るのは非常に難しず，皆さん御存知のように FORTRAN90 まで出現しく，まず作ってそれを使ってそのサブク ラスを作ったて います。つ まり「どうしてその時 ，その ト ップクラ

時に，インタフェースが適当ではないとか，機能の分スのサイエンテイスト達が，それを予言出来なかった

割がうまくいっていないとかの理由で，再利用が旨くのかりというととを考えるととが大切なのではないできない。そとで，かと思います。

というととを何度か繰り返さないと，本当に再利用性

司会r もう 1 度クラスを作り直して」

それぞれの分野の専門家をパネラ方々に御招の高いクラスというかオブジェクトは出来てとない，

きしていますので，各分野の立場から，コメントしてというととを感じました。再利用可能なオブジェク

いただきます。では，長崎さんからお願い致します。

トがあれば，開発コストは(多分)劇的に下がると思

長崎私は，との春まで大学院生でした。まだ就職しいますが，まずそれを作るのが難しい，というととがて問もないので，プログラムを開発してきたプログラ

あると思います。とれは Smalltalk K 限らないと思マの人達とは少し意見が違うというか，見方が理想的います。

な部分に定ってしまい，現実を見ていないということ

また，再利用可能なクラス/オブジェクトがあり，そになるかもしれませんけれども，御容赦頂きたいと思れを沢山，色々な種類を揃えれば揃えるほど，全く新います。

しく作る部分は競ってきます。けれども，部品が増え

私に与えられたテーマは，オブジェクト指向についててくると，今度は，その必要な部品をどのように探すです。私は，大学の時に， I
n
t
e
l
l
i
g
e
n
tPad というシスのか?というととがきっと問題になってくると思いま

テムの研究/開発に携わっていました。多分，そういす。との部品を探してくるというのは，今までのデー

うととからオブジェクト指向のテーマを頂いたのだ

タペースなどに，ほうりとんでおけばよいのか?デーと思います。

タペ ースには，オブジェクト指向のデータペースとかまずとの表4 を見た時にですね，オブジェクト指向

色々ありますが，まあ“キーワ- J-""なり“クラス"の他に“再利用"という部分がありますが，オブジェ

なりで引いてくるととになると思います。実際には，

クト指向の中の有益な/ありがたいというととの 1 つ(データペース中に)色々な部品が 蓄積され てきて，まに再利用があるのではないかなあ，というととを思いたその部品を豊富にする為に，他人が作ったクラスやました。特にIntelligent Pad は，もともと画面上にオブジェクトを貰ってきたり，自分の作ったものをあ見える視覚的なオブジェクトをユーザが(画面上で)げたりしてゆくと，段々，その，統一された考え方で，重ね合わせて貼ってゆくというととによって，新しいキーワード付けなどを行うととが難しくなってくる

Pad を作り出す。つまり，プログラムあるいは，ツーのではないかと思います。

ルを作り出してゆく。とういう考えに基づいて，そのそうなってくると，キーワードからの検索は段々困出来上がった Pad を，また別なものに再利用すると難になってきて，必要な部品が，きっとどとかにあるいう ζ とを，大学に於て研究している聞は， (再利用のだろうけれども，それが見つからないというとと~ Davis の掲げた表を指す.

になってくると思います。つまり，雑多な部品が在る

1
5‑
1
1June1994‑9‑

Addendumt
otheProceedingsof8894

SeamailVol.9 No.6‑
7

イブニング・パネル

ときに，その中から本当に自分が必要とするものをどというのがコンピュータ関係のエンジニアには一番うやって見つけてくるかというととが十分に支援さ重要だと，思っています。 そのためにはですね，最近私れていないと，再利用性を高めて，必要な部品とか新がやっている方法はですね，課題をまあ，少なくともしいツールなりプログラムなりを，簡単に組み合せに一晩寝かせておく。寝かせておくと私の頭の中ではよって作り出すというのは難しいのではないかと考ですね，意識と無意識が協調するんですよね。協調しえています。

て色々なととをある課題に対して次の臼に目覚めた

ちなみに， I
n
t
e
l
l
i
g
e
n
tPad というものでは，どうい時に解を出しておく，という何と言いますか，頭で考う方法を考えているかというと，まずカタログ集をえるのじゃあなくて，体で物事を考えて解を出すと 。

作ってパラパラめくって，それから見つける。あるいだから， ζ とらへんをコンピュータとすごくスムー

は Browsing によって捜し出す。

ズな形でやるのが重要じゃないかと思っていますけ

その次には， Hyper-Link などの構造を使って目的れども。えっと，アンケートについて私の，思ったのは，のものを捜し出す。とれはあらかじめその Pad を開リスク (risk) というのは，手ムは低いとかいうものでは発した人なりが link 構造を使って関連性のある部品

なくて， O( ゼロ)だと思うのですよね。例えば，色々なを登録しておくわけです。

道具があってそれを使うか使わないかは，本人の責任

その他 K ， I
n
t
e
l
l
i
g
e
n
tPad では， Pad という視覚的なわけね 。 「道具が悪いから」なんでいうのは，なんなオブジェクトの重ね合わせた構造で機能が決ってたる自己主彊の無さ，というか情けない生き方であっきますので，その貼り合わせの構造をキーとして，構てですね，私はどういうメソドロジーでも道具でもリ造から検索するととが出来ないか?という研究が今行

スクは多分 O だと思います。

われています。

それと，あとはですねえ， '思ったのは，私はプロトタ

但し，この方法，唯とれだけあれば，どんな場合すイプですけれども， pay-off の度とか lemming の度とべての場合をカバーするとは当然思えないわけで，そいうのは，やはり∞(無限大)だと思います。私が好の他にも別の何か方法があるのではないかと考えら

きなのはタオイストですから，タオというのは，あれれています。

ですよね，色々な物事を 2 つで考えるという。きしく

私の視点としては，とのようにオブジェクト指向とも，とれは西洋の考え方と一緒なんですよね。色々な再利用性というのは，密接に絡んでいると思います。

物事があったら二項分類して，その差を比べてやりま

そのためには再利用出来る部品をまずどうやって作しようというのは，ほとんど同じなんですけれども，るのかという問題もありますが，それをどうやって見タオの凄い所はですねえ， 2 つに分けるでしょう。分

つけ出してくるのか?ということも，しっかり考えてけて，それは本当はそれは，その 2 つは通じているん

おかないといけないのではないかと，当り前かもしれだという所が凄いととろですね。

西洋はずっと分かれつぼなしですね。だから離婚ませんが，思っています。

司会

どうもありがとうどざいました。後で，会場率は高いですね。東洋の方では， 2 つに分けるのは，からの声も含めて，まとめてコメント頂きたいと思い

まあよいのですけれども，分けたあとが全然違うんでます。では，次は熊谷さん，お願いします。

すよね。その極まると， f也に移っちゃうと。

熊谷

今晩は。えっ，かなり会場が硬いので，柔らか流行を追うというととは，とっても良いことでです

くしたいと思います。フィッシャーが結構柔らかい話

ね，流行を全然知らない人は話になりませんよね。そをしてくれたと私は思っています。

の意味で， A
lanDavis みたいに「流行を追うな」な

一応，自己紹介代りに最近思っているととは，世どというのは，全然ノッていない過去の人の話で，この中には，色々な制度があって，例えぼ有名な話では，

こに挙げられた項目は，全部やらなくちゃいけないと病院が無ければ病気という状態は生じていない，と思います。だから，その，各立場で全部流行を追っていうととがあって，私はとれは正しいと思うんですよ

ですねえ，中に C とか追ってもしょうがないやっとね。制度が如何に我々を害しているかというのは，そかプロセスとか追いようのないやっとか，とういうのの“病気"という 1 つの状態をとってみてもよく分かがありますけれども，そうでないやつは，私は徹底的ると思います。全世界から病院を無くせぽ，我々，全に追うべきで，まあ，後はとういうカテゴ P がおかし

人類からは，病気が全部無くなる。本当ですか?(笑)

いから評価のしょうが無いやつは，私は O だと思いそれぐらいがあってですね~，私が最近感じているますけれども， re-use とか Comquats とかは当たりのは，制度を如何に越えて，自然な行識をするのか?

前の話であってね，議論する必要が無いような気がし

S
o
f
t
w
a
r
eSymposium'V4‑10‑

北海道，函館

SeamailVol.9 No.6‑
7

イブニング・パネル

タイピングは ですね え， i
n
c
r
e
m
e
n
t
a
lK スケルトンかます。

で，ポジションペーパに，私は，との場で答えるといらどんどんやってゆけばよいという考えもあります

うととを幾っか書いてあってですね，一応，私はミーが，私の考えだとプロトタイピングはですねん分析

ハですから一応全部をやっているのです よね 。一応とか設計そのものをやる artifact というか道具だとStructured は最初からやりました 。とれは Assembler

思っているんですよね 1 。それを incremental してでもやったし C でも FORTRAN でも全てでやれるといって最後にその現場で使おうなんでいう，ある意味とは全部やりました。とれは，私は普通でよいなぁとで意識が低いというか，セコイ考えで物事にあたって

思っています。 Structured は，究めるとカオス (chaos)は駄目だ。もともとプロトタイプは私の考えではでになるんですよ。

すよ，スケルトン型となんとか型であるというのは，それから OOP とか OOA とかは，とれはもう 8 年

私は全然意味がなくて，色々な人が沢山いるのでです

くらい前になりますかねえ，自分の会社 K Sma
1
1
ta
l
k

ね，物を分析したり設計したりするための道具としとか移植したりとかを，やってですね，うまくいきまてプロトタイピングの技術を持ってきて，それに対すせんでした。(笑)。私は，そういう意味でレミングでる artifact を作ってですね，とれを見ててですね，生したね，完全に 。 断崖絶壁に走 っ ていっちゃったと い

きる勇気を養おうというのが，正しいというか，タオ

う感じで 。 仲間の何人かを一緒に連れて海に入ったというか，自然な生き方として見て，より良いと思っととは確かです。

ています。ですから Alan Davis がですねえ，とれを

それから，プロセスは随分試しましたけれど\ 乙う

使って ，と う，みんな楽しむ訳ですよね。それ，だかした Alan の話す通り，今，コメントのしょうが無い

ら“quick a
nddirty" でいいんですよね。とても良いですね。

と思います。

で，別の人が言っていますが，プロトタイピングとC は，当然，ほとんどの人が使っているから，特にいうのは CASE の一種で，上流工程だろうと思いま

コメントは不要ですね。
あと，プロトタイピングはですねえ，とれはツール

す。 で，結論としてはですね， Alan Davis は“全然物を作って売ったんですけれども，確か今まで 2......3 年を分かっていない!，彼の小論は，全然議論するに値しになりますかねえ，うまくいきませんでした。

ない"というのが私の意見です。どうもありがとうございます。

それから CASE はですね，先ほど中小路さんのhyper-media と methodology とがどういう関係があ

司会じゃあ，伊藤さんお願いします。最後の突っ込

るかなぁと，ちょっと思ったんですけれども，質問すみを期待していますので・・・。

ると失礼かなぁと，思って控えたんですけれども。と伊藤

え~，一応，打ち合せでは，役割分担というの+methodology という形でやっが出来ていまして，熊谷さんがポケて，私が一応突っていて，とれはまだあまり売っていませんので，とれ込むというととになっていましたので，そういう風にはまだ海にはつっとんでいないという状態です。

振舞いたいと思いますが，これはけっして私の本意でれは， hyper・media

それでですね，私のペーパの所にですね，あの不易はないんですが， role(役割)としてまあそうしたい。

と流行を話さないと，話にならないよ，というのを書で ， 今，熊谷さんのお話の中で， Al組 Davis は分かっいてありますので，一応，不易と流行を書いて見ましていないなんでいう話が出てきましたが，え~，熊谷た。 80 年代と 90 年代と 2000 年代の不易という変らさんも分かっていない訳ですね。実はですね，パネラ

ないものと，流行次々と変ってゆくもの。で，私の老は自分の担当分の統計は自分でとるという約束になっ子の考えに基づくと，とれととれとは密接に関係してていまして，私の方はとのようにとっています。

いて，本当は相通じている理論なんですけれども，とそれで，とれが今回の皆さんのアンケート結果でとでちょっと話したいんですけれども，時間ですので，す。で，今回奇数/偶数という話が電中研の高橋さもしあとで時聞があれぽ話してみたいと思います。

んの発表中で出てきましたが，高い/中間/低いとい

それから最後に，私の立場としてプロトタイピ ・ング

うのがありましたが， ζζ では 2/1/0 と点数付けしというのが，結構あっちとっちで引用されていました

た結果がとれです。え......， return と書いてあるのはけれど，で， Al姐 Davis はですね，

"
1q
u
i
c
ka
I
idd
i
r
t
y

だから，もう今のプロトタイピングは，もう駄目よ」

pay-off のととろですかね。そうすると CASE IC 関
わる所はどういうふうになっているかというと，と書いていますよね。で，ちょっと私，非常にその，嫌いと言うかおかしいなぁと思っていまして。プロト

r
i
s
k
r
e
t
u
r
n
レミング度

1
5
‑
1
7June1994

‑11‑

0
.
8
0
6
0
.
7
1
0
0
.
7
5
9

Addendumt
otheProceedingsofSS94

SeamailVol
.9 N
o.6‑7

イブニング・パネル

ζ れは高橋さん，どういう ζ となんでしょうねじやした。

はり，悲観的というととなんでしょうかね?。よく分

じゃあ，タオの話を熊谷さんがされたので，さっきからないですね。え~， 1 つ言えるのはですね，平均

書いた絵をちょっと 見 たいと思い ます。まあ，フイ ツが l ですから CASE というのは関心が低いと。

シ ャーさんの見方 とか，熊谷さんのお話 とかとも関係て\CASE の方はですね，ちょっととれは色々な人してくるんだろうと思うんですが，とれに類似したがいて，まとめきれなかったんですが…。大きく 4ととは S IGENV の長野のワ ー クショップの報告書 [5]

項目ありまして，最初の 2 つというのが生産性に関の中でも書いてますので，細かな話はそちらを見て頂わる話，あとの 2 つというのは品質 K 関わる話です。

くと もっと よ く分かると思うのですけれども … 。 西Davis の話は， CASE と言った場合，生産性の向上と洋的念物の見方は， 何 かと 言うと 「上からの 見方」 。

品質 の 向上と いうのが 主要なポイ ント なわけですね 。

例えば， へ ーゲ ノレの弁証法的念物の 見方というのはそれが最初はちょ っと生産性が上がる。 ととすごかっ

完全に自分は他人な訳ですね。どとか外から見ると。

たですね。次は， .i劇的に生産性が向上する，と書いてで，それは科学的な言葉，技術者が使 う言葉で言うと，ありましたね 。 それからドキュメ ント 品質を向上さ“客観的"と言うわけですね。自分はそ ζ に居ないわせる。それから品質を向上させる。

けです。

それで，皆さんの項目毎に書かれた人を見ると，とがら，どとか遠くに離れてウンウンとうなずきなí 俺は客観的に見ている」 と 言うわけです。

の生産性という所は risky だという回答が多かった

先ほど，ニュートンとアインシュタインの話がありです。 risky だけれど，当然のととですが何せ劇的なましたが，今までこう い う物の見方をしてきたと。所

生産性ですから当然劇的な high-return があるはずが，とういう事例に関しては 矛盾があると。で，こうなんですね 。とと ろが何を勘違いされたか，との劇的考えたら 。「と う考えたら」というのは一歩下がるわ

な生産性は low-risk なのにも関わらず low-return だ

けですね。そとから，物の見方としては，その矛盾がと書かれた方がいて，それはちょっと理解出来なかっうまく説明出来るというのがいわゆる「弁証法」でたんですが… 。 まあ ，と ういう結果になっています。

す。とれは非常に西洋的なものの見方(図 .2) で，当然とれを見てですね，との会に参加された皆さんが，との見方には限界があると 。

とれを究極的に続ける

如何にすばらしいソフトウェア技術者かというとととどこに行くかと言うと，それはへーゲルが言ったよが判ってしまったわけですね。何故判ったかといううに絶対他，神の世界に近付くわけですね。で，そ証明を次にしたいと思 い ますが…。

んなととあると思う人は幸せですけれども，多分無えっと，次に示すグラフというのは IEEE の SPEC­くて。

TRUMK 載っていた表(表 .2) なんですが， 3 年くら東洋的念物の見方というのは，どういうととかと言い前ですかね，ちょっと古いんですが。との中で何をうと，私は曹洞宗なんですが，曹洞宗の人はととには言っているか。ポイントは，品質の向上にあるという非常に少なくてですね 。 SEA の主流はどとでしたつととです。生産性そのものは， CASE を導入した直け，臨済ですね。で，曹洞宗，大本山永平寺の開祖道後は下がると 。 そして，しばらくすると向上するんだ

元という人がいますが ，彼 の「正法眼蔵」という本

けれども，それはけっして劇的に向上するわけではなの中に，ある言葉を引きましたが，くて，ある一定の規模でしか向上しないというわけ「万法はとびて修証をなす」

です。向上し続けるのは(し続けるかどうかは判りませんが)品質と保守ですね。とれは，高いレベルになとれはどういうことかと言うと「求めると得られなると。

い」というととです。例えば，あるものを求めるとで

で，とういうのを見ますと，皆さんのアンケート結

すね，逃げられるわけですね~。ととろが，ある状態

果というのは，非常に良い所を突いているわけですに自分を達するととによってそういうものは，自然とね。品質に関しては low-risk で，それなりの効果が自分に来る。それをちょっと絵に 書 くと，どういうとあるよ，と皆さんお答えになったわけですね。劇的なとかと言うととうなる。(図 .3) つまり，客観的，そ ζ

生産性というのは， high-risk で，もしあったら high­から一歩離れて何か物を見るのではなくて，その対return かもしれないけれども，それは非常に risky な象そのものになりきるというととです。で，とれの非話だよね，というととで。ゃっぽり皆さんの CASE を

常に良い話を。えっと，私，名古屋でローカルな会

見る目というのも，生産性よりも品質にあるんだといをやっているのですが，以前，塩谷さんに来て頂いた

うととで，さすが SEA の皆さんだ!と私は感動しま

ときにですね，以前彼が仕事をしていた時にですね，
コーディングリストが頭の中でスクロールしたとい

S
o
f
t
w
a
r
eSymposium'
9
4

‑1
2‑

北海道，函館

SeamailVol. 9 No.6‑
7

イブニング・パネル

う訳ですね。とれが多分 1 つの ζ の絵のような状態のであるべきだという)ととに反しているから。といになるのではないかと思います(笑) 。 もう 3 凄いです

うととで，.t:;-わります。

よね。頭の中ですから，もうマルチウインドウでもな

司会

んでもありですから。

進むというととはなかなか珍しいんですが，時聞が押どうもありがとうどざいました。計画通りにで，そのものになってみるという見方が，東洋的なしている以外は役割分担が巧くいったようです。で物の見方，多分それはタオにも通じるんだろうと思は，残り時間一杯，会場の方からコメントとか御意見

うんですが，それは例えば，あの私はもともとハードとか頂きたいと思います。

ウェア設計だったんですが，例えば 3 次元というの平野(中央システム)

は図面では書けないわけですね。三角法とか一角法が，今回のレミング (lemming) という話を聞きながとかを使って書くわけです。所が，慣れてくるとです

ら最初に思ったのは，ソフトウェアはハードウェアよね，図面を書くと 3 次元の図形が頭の中に出来るん

りも宗教に近いなというととです。今回は lemming

常日頃から感じていたんですですね。例えば，核磁気共鳴装置というのがありますの後ろに engineering と付いていますから，本来，技よね 。あ れに熟練したお医者さんというのは，要は，術論に絞ったはずなんでしょうけれども，もっと広くある断面図を見てゆくととによって，その愚者の全体

ソフトウェアを使う人まで考えてみると，私のまわり像が頭の中にイメージ出来ると。つまり何を言いたには非常 K Macintosh レミ ングが多いんで す。ユー

いかをいいますと，

rCASE は所詮ツールだ」という

ザがそれだけレミング化するというととは，エンジニととです。それを使うのは人なわけです。で，今回のアリングがレミング化するのは当り前じゃなかろう

タイトルを私のポジションも「道具としての CASEJ

かと思います。ある意味で，先ほどフィッシャーさんというタイトノレにしました。 CASE は所詮ツールでのおっしゃられた宗教的な部分と似ています。ソフ

す。それを使うのは人です。で，道具はあくまでテートウェアが，自に見えない，触れないものだから宗教

ラプルで使いやすくて，我々が直接 K は見えないものと同じなんじゃないかと思うんですが，特に熊谷さを見せてくれればよいわけです。ただ，それを使いこん，どう思いますか?，タオの発想、から見て。

なすのも我々です。で，その見えないものを見せるん熊谷だけれども，そのツーノレの在り方というのは，実はそアに限らず，科学でも工学でもありますよね。例えば

れとは全然逆だというととです。で，とれで最後にしアインシュタインのようなすどい人が出てくると，哲

レミングとか流行というのは，5jIJK ソフトウェ

ますが，私の翻訳した ACM の interactions [6J の中

学や人間の生き方にまで影響を与えてしまった。そうで，“道具の関わり"という話があって「見えないとという意味では，ソフトウェアだけに限らず，常に不易が大事だ」というわけです。例えば，近眼の人が使うと流行というのは，ずっと続いていると思いますね。

眼鏡がありますね。眼鏡は非常に有用な道具だけれですから，“とりたててソフトウェアだから"っていど，我々は眼鏡を使って外を見る時に，眼鏡を意識しうのはあんまり面白くない議論のように，私には思いていないですよね。眼鏡を意識したら，外は見えなくますけどね。

なりますよね。つまり道具の本当の在るべき姿とい伊藤

うのは，見えないことにある。そうすると，今の，多に同調して，半分反対です。

私はもともとハード出身なんで，半分御意見
ソフトウェアは見えな分ですね，私，つっとみですので，皆さんに嫌われるいから，と言うんですが，プ P ントアウトすれば，“立ように言わないといけないんですが，例えば「マノレチ派に"見えます。一方，私はもともとトラックのミッメディア」とかですね，先ほどフィッシャーさんのおションの設計をやっていましたけれども， ØlJ えば実際話にあったような「どとにでもあるコンピュータ」。

に，新型ミッションを作って実験するとき，ミッショ

それはどとかに埋め込まれて直接的には見えないか

ンの中で自分の設計したギヤがどうなっているのかもわからないけれども，例えぽスタートレックにあるは，ハードであっても見えないんです。それを見ょう

ように，とのへんを“ピッ"と叩くと，どとからか通とすると，ミッションを壊すしか手段は無い。だから，信が出来て，どとからか音が聞とえるようなものでソフトだから見えないという言い方は，それは正しくすね。それから「知的エージェント」。で，とれらは，ない。「ハードでも見ない部分は一杯ある」というこ

CASE を道具だとすると“解"にはならない。一言とです。ただし，ハードと比べて，ソフトウェアが対で言います。『まがいもの』です。良心的なレミング

象とするドメインは非常に広い。例えば，私が自動車とならない，真面目なソフトウェア技術者の扱うべき会社にいたときに，対象としたのは自動車だけなんでものでは無い。それは何故かと言うと，見えない(もす。ととろがソフトウェアに転職して私が経験した

15・ 17 J
une1994

司 13 ‑

Addendumt
otheProceedingsofSS94

SeamailVol.9 No.6‑
1

イブニング・パネル

ものは，事務計算もありますし，技術計算もあります

いるかいないか，というようなととを，日々，まあ何

し，今やっているような環境の仕事もある。で，そうとなく /ち ょっと意識しながら進んで行く 。

いう意味で，ソフトは，ハードと違って非常に広い範ようなととぐらいなんだろうか，というととを考えま囲を扱うメタなエンジニアリングであると考えていした。いかがでしょうか?

といったますから，その点では宗教に近いというど意見に同熊谷意しますというととです。

よ， fiction と fact というのはね，ほんとはあまり差

平野分かりました。 1 つだけフォローしますと，ちょが無いんですよね。

うどアインシュタインが出てきましたが，“ソフトウェ

酒匂

そう言いました。
そう言いましたよね。そう言ったときに，日々酒匂さんに，逆に質問しますが，私はあれです

アというのは物理的な法則から自由"なんですね。そ熊谷れが人間を非常に不安感に導く。あるいは逆に，喜悦の我々の行動が“論理的"とか言わなかった?

に導くと。そんなととをちょっと考えたからでした。

酒匂長崎

らですね，レミンジニアリングだ言って切捨てられな

今仰られたととと同じで，ソフトは自由度がえ~，だから，せいぜい，例えば西洋の人達か

ノ、ードに比べて非常に高くて，作ったなりにそれなりいために，私達が彼らに対しての出来るととで言えに動いてしまうんで，どれがベストかというのがなかば，自分達がロジカルな対応をしているかを意識してなか分かり難い所があると思います。だから，宗教といるフリをするというか，そのような態度を見せると同じで，誰かが示した道を皆が取り敢えずついていっいったようなととしかないのかと思った訳です。

てしまうのだと思います。

熊谷司会

あるんですかねじさきほどの 2 つの fiction と fact

どうもありがとうございました。それでは酒匂さん。
酒匂 (SRA)

その時の“ロジカノレな"という基準はどとにの聞にある基準を設けて，それを認めているのでロジ

コメントなんですけれども。最近，私カルだ，というのは分かるのだけれども，それがほとが読んだレミンジニアリングの話なんですけれども，

んど同じような形だと言ってしまうと，そのロジカル「相対性理論は間違っているんじゃないか」という話というのは，どうなってしまいますかねえ?

が広がりつつあるのだけれども，何しろ 90 年間も信酒匂今ととでは，単なる「三段論法」以上の ζ とはじられてきた理論だし，大アインシュタイン博士の言っていないんです。世の中には，言ったととだから間違いなかろうというようなととから DJ なんて言い方がありますけれども，例えばそiA ならば B ，だで，との動きに関しては黙殺という雰囲気が流れていういう問題には陥らないといった程度の話です。

るという話を聞きました。だからレミンジニアリン

司会

では，次の方どうぞ。

グがいけないと言いたいのではなくて，相対性理論は

宮田 (SRA)ちゃんと世の中の役に立っている。先ほど，宗教と科話が飛ぶんですけれど，今年の 1 月に「オラクル・オー

現役プログラマのつもりの宮田です。

学という話があって，両者を二項対立で捉えてきたわ

プン・ワールド」という大々的なショーが，横浜パシ

けですね。私の考えでも，宗教と科学というのは，構

アイコで行われました。との時のオラクルの宣伝は，造的にも似かよっているし，少ない原理/原則から，そ日本経済新聞を 2 面ぶち抜きでしたけれども，書いてれ以上の体系を演躍するという所も非常に似かよってある日本語はたった一言「その日，あっと驚く」。実いると思います。ただ，一番最初の所の公理(拡iom)

際に会場に行っても，イメージフィルムを流しているというととろが，科学は fact (事実)，宗教は fiction

だけで，商品がどうだとか，どんなものを売っている(空想)という両方とも“f" で始まるものです。そとかという説明がまったく無いんです。私は主催者側

で，西洋の哲学者/科学者は“最初がつまずくと後がにいて，彼らが何をしているのか全く解らなかった。

全部違ってしまう"ときっと言うでしょう。しかし，

もう 1 つ，マイクロソフトがテレピで，

iWindows ,例えぽ熊谷さんの考え方では， fact と fiction はあま

Windows , Windows ，…」と喋りっぽなしのコマー

り区別が付かないんですね。そうすると私達がレミ

シャルをさんざん流している。何の広告なのか素人

ンジニア P ングだと言って切捨てられないための方にはまったく解らないんですけど，延々流している。

策は，との最初の“f' が fact もしくは fiction のうち，

で，とれも彼らが何をしているんだか私には全然解

少なくとも今の時点で，どちらに近いかを，多分大学らなかった。けれども，昨日，予稿集をめくってレにいる人達とかが考える。そして，技術者は，そとかミンジニアリングという言葉を見て，彼らが何を狙っら演鱒されている体系，もしくは帰納的に導かれる体ていたかやっと理解出来たんです。彼らは，なんとレ

系に関して少なくとも自分達が，論理的態度をとってミングを作り出しているんですね。そとでお願いが

S
o
f
t
w
a
r
eSymposium'
9
4

‑1
4‑

北海道，函館

SeamailVol.9 No.6‑
1

イブニング. /~ネJL，あるんですけれども，レミングを作り出すととは，お聞で協調して出てきたことというのは，それは本当のそらく資本主義社会の中では簡単に成功するのだと答でなくて，トリガーだと思いますね。だから，それ思います。アメリカの企業は既に始めています。今，が，色々うねうねと曲っていってようやく最後の答に

I
n
t
e
l
l
i
g
e
n
tPad が出ていますし TRON とか色々ななる。だから，一晩寝たぐらいでは，ちゃんとした答アーキテクチャが提案されていますが，黙っているとは出てとない。きっとそれは，熊谷さんが無意識と意消滅すると思うんですよ 。 で， I
n
t
e
l
l
i
g
e
n
tPad レミン

識と書いてあるけれども，“酔っぽらってふっと気がグというのを作り出すような努力を是非やって頂き付いたら何かを思い出した，それは何かのトリガーにたいというお願いです。

長時なったんじゃない"という風に話をして頂きたい 。 結

I
n
t
e
l
l
i
g
e
n
tPad レミングを作っているという論は何かと言うと，その OHP はあまり使わないよう話ではありませんが，今，既にコンソーシアムがありに!

ます。 まず色々な所でデモをして，サンプルを使って熊谷

色々とデモをしています。その他にも，評価版という“一晩とは限らないけれども"と。あれは 1 年から 10のを配ってまず使ってもらって，というととで色々と年のとともあるんですよ。例えば，私の経験でいくと努力はしています。まあ， I
n
t
e
l
l
i
g
e
n
tPad みたいなシ

ですね，これはある 1 つの場合なんですけれども，凄ステムの場合だと，言つでもなかなか判ってもらえ

い難しいパグがあってですね， XX 石油さんに納めたない，とにかく見せて，如何にも簡単だという所を見システムが 1 年 K1 回ぐらいシステムダウンするん

せなくてはいけません。そういった意味で，今は一生です。それがどうしても解らなかった。でも，あると懸命レミングをつくろうとしているととろです。

き夢の中でパグを見iつけて，本当にやってみたらその伊藤せいだったというのがあって…。私が“寝かせる"と最初の話でí わからないコマーシャノレが多い」という話をされたので，

だって，そんな単純なもんじゃないって。

さっき，説明の時に言ったじゃあないですか，

íパネラの話は解らんか

いったのは，みんな寝かせずにシステム作りをやるか

らなんとかせい」というお叱りの言葉かと思った，とら，みんなギスギスして正解が見つからない。寝かいう話は置いといて，私は「それはやっぽりいけない

せておくというのは，今でも重要だと思っています。

よね」という立場です。

中野

レミングがお金になるというのは，それで儲けよう

じゃあ，その「一晩」という所に，“1 年"と“ 10 年"というのを入れておいて下さい。(笑)

とされるのならよいんじゃないでしょうか。けれど

司会次は高橋さん。

も， SEA としてソフトウェア技術者として儲けるた

高橋(電力中研)

めに，何かを求めるならよいんですが，そうでないとなあ?みんな同じ方向に走るんだけれど，実は，川がしたら，追いかけるとと自体意味が無いように思う

来たら止まっているんじゃないかなと，思っています。

んですが…。

過去にも例えぽ構造化00 とか“FORTRAN はも

富田ととにおられる方には，レミングになって貰レミングだったら，何故悪いのかう駄目だ"神話に乗って走って行った人達で，今とけいたくないです。客観的に見ていて欲しいですね。

ている人がどれだけいるんですかね。自分が過ちを熊谷

レミングは，あれはみんな死ぬんだよ。だか

気がついたら，そおっとよそを向いて違う方向に走っら，行く先は，断崖絶壁の海か何か知らないんだけれて行けばいいんだから，結局誰も溺れ死なないじゃな

ども，そとまでパーツと定って気付いても遅いんです

いですか。自信のない人聞は，人が走っている中を一よ。もう死ぬしかないから。唯，みんな人聞は死ぬた

緒に定って行くと，すごい安心感があるんですよね。

めに生きていますから，それでもよいとは思いますけ

とにかく，我々はいつも真っ暗な中で歩いてるみたいれどもね。

なものです。で，誰かがパッとランプを当てたら，皆司会

じゃあ，中野先生。

中野(大阪大学)

でそっちに走って行く。とっちにランプが点灯すれ熊谷さんから「課題を一晩寝かせてば，そっちに走って行く。

おくと，意識と無意識の問で協調してそれが解ける」

だから，レミングみたいに定ってゆくのは構わないという話があって，熊谷さんは，その OHP を非常にと思うけれども，いざとなった時に，方向転換出来る

気に入っておられるようなので，誤りを訂正しておきように次のととを考える人がいなきゃあいけない。日たいと思います。え~っと，最近色々なととをやって本がアメリカや中国と戦争をやったときに，どんどんいるので，私の専門がわかってもらえていないと思う

追い込まれていって，引き返そうと，思ったんだけれどのですが，私は一応基本は「アノレゴ P ズム屋さん」なも，引き際をしくじったんだと思うんですよ。だから，ので。課題を一晩寝かせておいて，意識と無意識のソフトウェアの世界も，引き際をしくじっちゃあいけ15‑
1
1June1994‑1
5‑

AddendumtotheProceedingsofSS94

SeamailVol.9 No.6‑
7

イブニング・パネル

ないなあ っ と思うんですよ。

来ないんですけれども，比較的西洋というか向とう司会の establishment アカデミズムの establishment

でもね~，レミ ング になって，わっと走り出す

K

ような人達がいるとして，で，その中で冷静になって付き合う機会があって，見てると，彼らは自信を持っパッ と 「 止まろうよ」って言う人がいると思います?

ている 。 死ぬの死なないの言 っ ても，死に方にも自信高橋がある 。 かなり覚悟を決めてやっているという面が「止まろう」って言う必要は無い。「とっちの方が明るいよ」っと言えばよい 。

熊谷

あります。

そうそう，逆なんだよね。どんどん行って，もっそとがちょっと，その迫力が違うというか，淋しい

と別の所に行けばよいんですよ 。

なあという感じがして・・・ 。 で，それはどうしてか高橋だから「あれが失敗したから，とれをやろう

なぁと言 っ たら，先ほど言ったレミングで走る，信ずよ」と誰かが声をあげるでしょ，そうしたら，みんなる先がですね，今日のは，曹洞宗でしたっけ，臨済宗，

ワァーとそっちに走って行くじゃあないですか 。 エキ

曹洞宗の話が出てきたから心強いですけれども。今スパートシステムだ，オーフンだ， 81 だ，とか。あっち日話題になったアイテムが，全部向とうの人が言っのパラダイムがうまくゆかないから，とっちに走ろう

たととなんで，次回，とういう時にやるときにはです

よという流れをね，同じ l つの会社がやっている訳でね，伊藤さんの曹洞宗と熊さんのタオイズムをですはないでしょうけれども，どっかがやったら，ね~，タネに出来るかなぁと ， そういうととをちょっI ワー 」とみんなそっちに走って行く。その聞に，とっちは貯と夢見てます。

め込んでおいて，次のパラダイムを出せば，またとっ藤野

ちに人が来るという，そういうような順繰りが出来てだと言いましたが，確かにそうで，わざわざ言わせているんじゃあないかなぁと思うんだけれども。

頂ければ，レミンジニアリングという形の中の 1 つに

司会

でも，それは崖から落ちなかったから出来た。

しようとして，色々と企んできていたわけですからね。

そうなっただけであって，もし本当に崖まで行って落で，それはそれでピジネスとして成立すればよいわけ

ちていたら・・・?

で。で，もう 1 つは，その， 1 つはその pretend 5 して高橋やっているんだ，という部分は，前もってきちんとわ

いや，落ちる時には，ユーザも含めて皆一連托

先ほど，オブジェクト指向というのがレミング生ですよ。今，ソフトウェアハウスが亡びたら，ユー

きまえておいた方がよいと思いますね。

ザは皆困るんですよ。生かさず殺さずしなけりゃあ岸田 (SRA)

いけないんだから，落ちたりはしないんです。

の人は，みんなオブジェクト指向レミングを作りたい

熊谷臨済宗の岸田です。そとにいる 3 人

いや~，高橋さんのそばには良い人がいるじゃあ

ように聴きましたが，伊藤さんが，ほら，客観的に物ない。私の周りには，断崖から落ちて死んだ人が一杯を見るのは間違いだ，と西洋的な。でも，客観的に物いますよ。だから，そういう人は，人知れず死んでいを見るのが，オブジェクト指向なわけでしょ?。熊谷I死人は出さんも，タオイズムだとか言いながら，オブジェクトてない」というのは間違いで，もう少し彼らの挽歌をるんですよ。だから生きている人達がね，指向が好きとかいうのは，どうも自己矛盾しているの聴かなければ駄目ですよ~。

じゃないかと思いますが…(笑)。

司会伊藤

じゃあ，二木先生。

二木(北陸先端大学院)

何時まで経つでも，臨済は曹洞に勝てないととI死ぬ J I死なない」というろでして…(笑)。私がお話したのはですね，客観的話ではないですが。ちょっと哀しいなぁと思うのは，念物の見方というのは，近代科学を作ってきた 1 つのみんな冒頭の表にあるのは皆外国で出てきたアイディ

重要な見方です。で，私が言ったのは，単にですね，そアなんですよね。日本人が踊らされて死ぬの死なない

ういうへーゲノレの弁証法的な物の見方，いわゆる我々のと言っているのがなんか淋しいですね。我々がプロが客観的な物の見方の他に，もう 1 つの物の見方，そジェクトを起てる時も，日本独自のアイディアではな

れは「対象そのものに自分がなりきって，その対象そく，向 ζ うのアイディアでやっているととが多いですのものを把握する」という見方があるんじゃないでよね。で，最近，“東洋思想"だとれ“全体主義(トーしょうか，ということをお話しただけです。

タりズム)"だとか出てきて。まあ，ソフトもそうい熊谷

うととでね。日本の思想が，とう，タオかもしれない

じなんですよね，私も見方としては。ですから，さっ

けれども，本当言うと，

I 出来るかなあ」と思うわけき中野先生に誤解された“寝かせておく"というのは，ですよね。で，私は所詮プログラムだって，せいぜい別に何もしないわけではない。ものごとの見方を客Lisp を 1 万行くらい書いたとか，そんなととしか出

5 …のふりをするS
oftwareSymposium'
9
4

‑1
6‑

その点というのは，私のタオの考え方も全く同

北海道，函館

SeamailVol.9 No.6‑7

イブニング・パネル

観的だとか，客観的，科学的，分析的，とかじゃなくて，熊谷

主観的 3 なおかつ，その自然な形で見るというととのた所なんですけれども。藤野さんがですね，言葉とい方が重要だという意味ですから。

うのは 1 つの共 同 幻想社会で，言葉のコ ー ドがなけ岸田

れば，例えば議論とかコミュニケーションが成り立た

そうするとさあ，オブジェクト指向の成果ってまあ，そ ζ らへんが，私はさっき言わなかっ再利用出来ないよね，主観的だから…(笑)。

ないと言っていました。

熊谷なんですか，その“再利用"ってれど，本当は，そのコ ー ド系から抜けて》さっき言っ岸田

オブジェクト指向の“売り"は，“再利用"なたように，その物に成り切るというのはそれに殆ど近あれはあれでよいんですけんでしょ。

いんです。その コー ド系を抜けた形で理解をシェア

熊谷“売り"はどうでもよいですけれども，我々人(共有)出来るかどうか，じゃあないかと思うんですよ

生というか我々の社会全てが再利用で生きています

ね 。 ですから，制度とかコードを介してしか理解出来よね。その意味で，再利用でない物は殆どありません

ない場合は，本当は，それは理解し合っていないから，よね。人類の， ζ とら辺のフィジカル念物もそうだし，

しょうがないんですよね，もう。

メンタルなものもそうだし，文化とか文明とかいうも

酒匂のも，みんなそうですしね。そういう意味では，再利oriental と呼んで，西洋に向かつて宣伝してゆきたい

用は，ただ単に私の理解によると 「 組み替え」に過ぎと思います。 どちらかと言うと， i
n
s
c
r
u
t
a
b
l
e6 o
b
j
e
c
t
ｭ

伊藤さんと熊谷さんには，との道を object ­ないですから。だから，生産というのは，そもそも組

oriented という感じですけれどもね。

み替えなんですよね。原料から組み立てているだけ

司会に過ぎないので，そういうのは全て再利用なのて\“何ているんですけれども，そろそろ一応締め括らなけれを今更再利用"という感じで，それは，殆どもう議論ばいけません。当初予想したようにですね，全然締め喋りたいだけ何時までもやってよいと言われの余地が無い所 だと，私は，思っていますけれども…。

括れませんので，締め括り方の 1 つとして， 一 番最初

伊藤今の熊谷さんの発言は，多分暴論だと思うので

K フィッシャ ー さんが上げて下さった「銀の弾丸はあすけれども， í 対象そのものに成り切る」というのは，るのか? Jí 銀の弾丸は何なのかりという話を一言ず

どういうととかと言うと，ととに缶がありますね。とつして欲しい と 思います。まずフィッシャ ー さんかれは缶として認識していますが，私の方から見て(フらお願い出来 ま すか?。つまり，銀の弾丸というのは，ロアーの方から見えているような)アルミの形状があ

理想を追い求めた良い面で， Davis 流のレ ミ ンジ ニ ア

るなぁと想像するわけです。また，あるいは「今，とリングというのは，

í ととまで行くと悪いよ」というの中にジ ュー スが入っているな」と想像するわけで例だと解釈したときに，じゃあ，銀の弾丸は 何 なのだ

す。つまり ， 客観的な物の見方というのは「客観」 とろうという話に し てみたいと思うんですけれども。

いう言葉にだ ま されそうですが，実はそとに色々な憶

フィッシャ 一測というのを取り込んでいるわけです。て\「その対です。もしも誰かが見つけてしまったら我々は皆，職象に成る」という見方というのは，とれは本当 K 東洋を失ってしまうし。しかし，ソフトウェア エ ンジニア

的な物の 見方なんですが，ちょっと抽象的な物の言い

リングは広範囲な問題を様々な観点から様々なアプ方をしますが，

í 自 分を殺す J (滅私)という言い方をロ ー チで取り扱うことができるのがいいととろです。

します，え~，禅の世界では。それはどういう事かと

アメ リ カには“千の華を咲かそう"という言葉があり

銀の弾丸がないというのはそのとおり

言うと， 自 分の憶測 と いうのを全部除外し て ，見えるますが，私もそのとおりだと思います。

ありのま ま を 自 分が受け 止 め認識するというととな司会んです。で，それは，あるがままに物を受け 止 め認識

いきましょうか，伊藤さんの方から。一言。

するというととなんですね。

伊藤ありがとうございました。じゃ，今度は逆順 K

単一の解は，多分無いでしょう。で，あれば皆高橋

それは ユー ザの言いなりになるってととなの?

さん，ととに集まっていないはずです。 個々の努力の伊藤

いや。 ユー ザがとう望んでいるというととで組み合せとして，多分，全ての工学がそうであるようあれば，それは，

í ユ ーザが ζ ういう事を言っているに…。だからもしあるとすれば， SEA が銀の弾丸?

時は，との ユー ザは 何時も嘘ばっかり喋っているから，

熊谷格好良すぎる。格好良すぎて，隣で私は気恥ず

きっと ζ んなとと望んでいないだろう」 と いった憶

かしくて何も言葉を言えませんが・・・。私の解釈で測を取り除い て ， 自 然な素直な気持ちでユ ー ザの話をは，銀の弾丸というオ ー ルマイティがあるかという設聞くという。だから，それが所謂「悟の境地 」 という問は，それ自体がナンセンスだと思います。私の感じ訳で。

6 探索出来ない，不可解な

15‑17June1994‑17‑AddendumtotheProceedingsofSS94

SeamailVol.9 No.6‑
7

イブニング ・パネル

だと常に，“問題のある時にはソリュー シ ョンがある"

参考文献と思います。 無ければ全然つまらないし 3 もう死んだ[1] Alan Davis , S
o
f
t
w
a
r
eLemmingineeringIEEE

方がよ い ような気もあるから常に問題があるという

Soβ wαre ， S
ep.1993p
p
.
7
9
‑
8
4

ζ とを認識した時点て九常にソリューションが有ると

[
2
]F
r
ed Brooks , No Silver Bullet , IEEE Comｭ思 ってい ます。 そういう意味では，そういうオールマ

puter, April1987pp.10‑19

イテ ィの銀の 弾丸じゃないんだけれども，細分化された銀 の弾丸はあると思いますね。それはまるでファー[
3] GerhardFisher , CooperativeKnowledge‑Basedストの‘メンアイストフェレス'と“人間"の対応のよeandDesignEnvironmentsfortheDesign , Us

うな，私は気がしています。

Maintenanceo
fSoftware ，ソフトウェア シンポ

長崎

ジウムラO 論文集， June , 1
990pp.2-22 ，ソフト

私は一応オブジェクト指向というテーマを与えられていましたけれども，そのオブジェクト指ウェア技術者協会

向の分野での銀の弾丸，その色々な問題を一気に解決[
4] Kurr匂o Nakakoji( 中小路久美代)， Gerhard

して く れるような方法というか，それが私は IP I'C関Fisher , CooperativeKnowledge‑BasedDesign

わっていますから，それが IP であればよいんですけ

EnvironmentsfortheDesign , UseandMainte司

れども 。

司会

nanceofSoftware ，

どうも，ありがとうございました。え~， 長崎

ソ フトウェアシンポジウム

ラ0 論文集， June , 1
990pp.264・ 270 ，ソフトウェ

さんが，あまりハ ッ キリ仰らないので「日本で生まれ

ア技術者協会

た技術である IP が銀の弾丸になるのかなあ ?J という ζ とで，締めたいと思います。どうも夜遅くまであ[5] 伊藤昌夫，青空の彼方から (2) ， SEAMAIL , Vo.
19

りがとうございました。

NO.2・ 3 (1 994) , p
p.54‑58[
6] MarcWeiser (伊藤訳)，実世界は，机上のようなちっぽけなものではない ，NO . 2・ 3 (1994)

SEAMAIL , Vo1.9, pp.61‑62

5 以上の文献は，本文中に登場したものから，編集部の判断で関連すると思われるものを SEA の出版物を中心にポイシトした。原典にあたられる方は，とれらから孫引きして頂きたい。

丁目 il

R
i
s
k P
a
y
o
f
f L
e
m
m
i
n
g
i
n
e
e
r
i
n
g

s
t
u
r
u
c
t
u
r
e
d

。

OO-D , P,A

。

。。

p
r
o
c
e
s
s

。

。

C

。

medi

p
r
o
t
o
t
y
p
e

medi

現時点における Trail の居場所

cxコ

assembler , C, fortran , BASIC ，仕様記述， etc・ .

。。

Smalltalk-80 , C++ ，設計方法，物の考え方!
? (現場では未)。

ほとんど全員が使用

PWB+ ActiveBook(売れていない)

。。

。。

。。

CASE

。

。。

。。

Hypermedia+ methodology(未)

r
e
‑
u
s
e

。

l
o
w

。

当然

comquats

。

l
o
w

。

表 1. レミング度一覧と現時点におけるTrail の居場所(熊谷)SoftwareSymposium'
9
4

‑1
8‑

北海道，画館イブニング・パネル

SearnailVol.9No.6・ 7~...l.: "PV'Oゐ七ypeMhz 乞ー今何， tuf 色企しい

、

ー.

., ''

A~い，fads:Zoud 弘ゅ之、ゎ場'.，."，.旬、~ t'" 恥ゆ"ゆいー~.e . ~ 々し、キ~t.~も‘μ

れ仰をYfが'ωム・Aぷ ω舟fいす~ •晶、 JJaadadfvW C宅;. c
.
'.

鳥"で:

(
r
M
'~-.. ...-一，似俳句 l~ C似の ~Ai ，1
図 1 .Prototyping に関して(熊谷)15・ 17 June1
994

‑1
9‑

AddendurntotheProceedingsof8894

SeamailVol.9 No.6‑
7

イブニング・パネル

CASE効果の iIl11.
ss ・94 @H
a
k
o
d
a
l
e

c
)Masao10
1/111114194(

表 2. CASE 効果の波及(伊藤)λ /lIJfIタ話身の支援 -WM.、 EM

8

WM(ï!ff~言殿j

E M(.東法的ノム

よからの据点-経験、行持-合成と分解・推移助. /説卿ザる j.r.る.lJがままに分.lJ J
図 2. 人間的活動の支援 -w 型， E 型(伊藤)

SoftW
l
U
"
eSymposium'
9
4

‑20‑

北海道，函館

SeaInailVol.9 No.6‑7

イブニング・パネル

rtb~iがままに分~J のためにoプログラマ中心主義

長Jに居せ才j の擁立ーソ 7 1- ヲェア工学の課題。
庁ず家j"道具"と L での CASE

-どラ足せるか!Jtf若者

f停を原液すぺ5 .:óリーメ介ヅックス、鹿式表示H ・ H ・..!l;とをいアーノルへ
図 3.

r あるがままに分る」のために(伊藤)結議 -CASE の É/j!i すべ、さ方舟-

o

第一世代 CASE
符定方法話支援符定Z膏身 f符定ヅポジ兵ヅj

巳主

句

お話会却さ
チェック

「五支のぐるぷ程度の〉配

秀吉二世代 CASE
複毅方法論支援複翠ti青葉 f標準ヅポジ介ヅノ
メタ CA 5E .:óミらの事出句

プロ~ス中心持軍虚度ツーノルによ.0持薬|織のぐ紛程度の〉鰍

o 第三世代 CA 5E (Nir附ω".!l えをい"アーノルと現身図 4. 結輸- CASE の目指すべき方向一(伊藤)15・ 17 June1
994

‑2
1‑

AddendumtotheProceedingsof8894

SoftwareLemmingineeringSummary

SeamailVol.9 No.6‑
7

SoftwareLemmingineeringSummary
塩谷和範*

1. はじめにそもそものはじまりは，昨年 (93 年) 9 月号の IEEE Software 誌に“ Software Lemmingineering" という面白そうなコラムを見つけた事だった。とのコラムでは， Software 誌編集委員の Alan Davis と TRW 社の Winston

Royce が， ζ れまでにブームになった技術を取り上げて超辛口の批評1 を行なっていた。
ζ れに触発されて，本年 (94 年) 6 月 K 函館で行われた第 14 回ソフトウェアシンポジウム(以下 SS94) のイ
ブニングパネル [1] のテーマとして取り上げ，活発な討論を行った 2 。 この報告には，との時のミニアンケート分

析結果の報告と，来日した Alan Davis を囲んで行った“ Software L
emmingineeringDebate" の討論状況をまとめた。

2. SoftwareLemmingineering とは?
実は，アンケートそのものに十分な説明を付けなかったためと， SS94 論文集の“ Software L
emmingineering"

パネルの説明自体も Davis らがまとめた表と，簡単な言葉の説明を載せただけであったので，回答に際してはかなりの混乱があったようだ。そとで，いまさらながらの感もあるが，まず補足説明をする。
Lemmingineering “レミンジニア 9 y グ" , A
lanDavis の造語。

一般大衆 (The masses) が従っている技術に，それが適切であるかの考慮
抜きで盲目的に従う工学システムのプロセス。

Lemming

短尾の柔毛足の醤歯(げっし)類の極地方の小動物。

ある欧州種のしぼしぼ海に続いて飛び込み，多数が溺死する周期的な集団
移住で有名。

2.
1(Webster 第 9 版より)Lemmingineering 要約

ζ のコラムの副題を直訳すると，「子供のように誰かが知らないととを知っていると羨む。
レミングの様に，我々はりーダーに従う傾向にある。」

つまり，自分が知らない新技術を誰かが知っていると我々は，それを羨むし，さらに，レミングの様に我々は，ともすれば(半ば)盲目的にいまだ有効性が実証されていない新技術，あるいはそれを提唱するリーダに従う傾向にある。という危慎を，レミングという言葉とエンジニアりングという言葉を合成した造語によって提起したのが Davis のコラムの主旨だ。

Davis は，レミングの滅亡への軌跡 (trail) になぞらえ，過去に我々がたどったブームとなった新技術の幾っかを，その効能(達成目標)とそれに対する評価についてまとめている。なかなか辛掠な評価となっているが，各項目(軌跡)どとに以下のような解説が付いていた。

2
.
2

構造化軌跡

70 年代，構造化技術はソフトウェア産業の明らかに増大し続けるコストム増加を続ける顧客の不満足に対する一つの解決策として売られた。 10 年間，我々は隊列を組んで構造化ドラムのピートに向けて盲目的に行進.(株 )SRA

技術部システム技術グループ

1 正確に言えぽ， ζ れら技術の受け入れ盗努についての問題点の指摘
2 SS'94 論文集ならびに，本稔イブニングパネル報告参照

SoftwareSymposium'
9
4

‑2
2‑

北海道，函館

SeamailVol.9 No.6‑7

SoftwareLemmingineeringSummary

した 。 70 年代末には“構造化"は，“良い"というととと同義語になってしまっていた。我々は，“構造化"という形容詞の集中放火を浴びせられた。振り返ってみれば，色々な時代で“構造化"と呼ばれてきた，広範な異なるプログラミング慣行は，我々の専門文化の中に溶け込んでしまった。今日，我々は構造化プログラミングとは呼ばず，単にプログラミングと言う様になった。

構造化設計/分析については， ζ のようにはうまくいっていない。初期の構造化分析は，過剰分析で我々を混乱させると共 K ，複雑なリアルタイムシステム向きではなかった。後期の版では， PaulWard , DerekHatley，および Edward Yourdon の提案により，過剰分析問題と，より簡単にリアノレタイムシステムをモデル化するための制御機構を追加した。
しかし誰も，我々はなぜ最初に構造化分析を行っているのかと言う聞をしなかった。もしそうしていたら，目的である要求仕様ーシステムをブラックボックスで記述する文書ーが階層的なデータフローあるいは制御フロー
では書けないととに気づいたかもしれない。

構造化設計は，構造化分析(結果)を呼び出し階層に変換する単純なやり方の集合であり，ただ構造化分析と同程度に有効だった。

未だ，構造化軌跡を集団暴走するレミングにはほとんど選択がない。もうどとにも行き先がない!今や，多数の生き残りたちは新たな群れを作り他の道を目指している。

2.
3 オブジェク卜軌跡
80 年代後半から 90 年代にかけて，オブジェクト指向技術は，コストと顧客満足度問題を解決する方法として売られた。今や“オブジェクト指向"は“良い"と同義語となり，我々はとの形容詞の集中放火を浴びせられている。

オブジェクト指向プログラミングは， 20 から 30 年前に発見された，データ抽象化，情報隠蔽，カプセノレ化，継承などの品質を向上させるプログラミング技術の健全な原理に基づいている。とれら実証された原理が広まるのは嬉しいととである。 2000 年までには，オブジェクト指向プログラミング (OOP 3 ) は，単にプログラミングと呼ばれるようになるだろう。

オブジェクト指向設計(とにかくその大多数の流派)は，同様な確固たる基礎に基づいている。オブジェクト指向設計 (OOD 4 ) は， 20 年前 K MichaelJakson が説いた:“実世界の構造をまねるととに失敗する設計は，単に悪いばかりではなく間違っている!"の特徴を明示した。

それでは， OOP と OOD と記された軌跡の終端には 何 があるだろう?保守性と信頼性の向上，および，おそらく開発コストの低減だろう。とれらは確かに ζ の道にとどまるだけの 十分な理由である。しかしながら，劇的な生産性の向上と再利用における信じられないくらいの成功という標識は盲信するな!本当かもしれないがそうでないかもしれない!大多数のとの道を選んだ者は非現実的な期待を抱いている。

オブジェクト指向分析 OOA5 については別の話だ。要求分析段階の目標・仕様ーを忘れずに，それが OOAの実施で可能かを自問してみよう。答は，“否"である。要求分析に適用できる OOA 技術はない。たとえ状態と援る舞いの記述でオブジェクトを改良しでも，構造化のときと同じ問題が残る:“全体システムのブラックボッ
クスの撮る舞いをオブジェク ト の集合の個々の振る舞いによって調査できるか?"OOA は， OOD への移行を容易にするという主張は馬鹿げている，いかなる工学原理も要求から設計への変換を容易にするととを主張していない 。 要求定義において，保守性と信頼性の向上に つ いては，ほとんど意味が無い。(可能ではあるが)証明されていないうたい文句の生産性の劇的向 上 ，およびオブジェクト指向プログラ
ミングと設計技術を使用するととからの再利用は，要求定義時においては正当化されるととは少ない。

2.
4 プロセス成熟化軌跡
今年 (93 年)の ICSE6 では，誰もが少なくとも片足をとの集団暴定に置いているようだった。目標は，顧客とそのニーズを満足させる，高品質(信頼性，保守性，使用性…)ソフトウェアの，予算とスケジューノレ内での一貫した製造である。とのためには，適切な背景(知識)，訓練，技術を持つ技術者と，与えられたプロジェクトに合つ
3O
OP:Object- Orien七 ed Programming
4O
OD:O
b
j
e
c
t
‑
O
r
i
e
n
t
e
dD
e
s
i
g
n
5O
OA:O
b
j
e
c
t
‑
O
r
i
e
n
t
e
dA
n
a
l
y
s
i
s

6I
C
S
E
:I
n
t
e
r
n
a
t
i
o
n
a
lC
o
n
f
e
r
e
n
c
eonS
o
f
t
w
a
r
eE
n
g
i
n
e
e
r
i
n
g

15‑17June1994‑23‑

Addendu皿 to t
heProceedingsof8894

SeamailVol.9 No.6‑7

SoftwareLemmingineeringSummary

た適切な開発プロセスを選択する能力と，その仕事を終わらせるための十分な資源(期間，予算，道具)を持った管理者を必要とする 。 とのようなモデルは，繰り返し可能な，測定可能な開発プロセスの重要性を強調する。 ζ
れらは，目標達成のための 2 つの重要な要素であるが，とれ単独では十分ではないし，必要でさえ無いかもしれない。適切な人々を得れば，繰り返し可能な測定可能なプロセスなしに成功できる 。 適切な人々なしでは，繰り返し可能な測定可能なプロセスであっても成功はおぼつかない。

現時点では，適切なプロセスを各々のプロジェクト毎に選択するととの方が，ある組織の全てのプロジェクトに有効な汎用プロセスを， (そのプロジェクトに)合わせたものを期待するととより重要である。
簡単に言えば，プロセス成熟化の道は，長い高品質ソフトウェア K 至る旅程の第一歩にしか過ぎないし，それ以上ではない。

2.
5

C 言語軌跡とれは人気のある道のひとつである。そして，我々を証明済の品質を浸透させるプログラミングから，ハッキ

ングへと導く非常に危険な道である。 C で高品質のプログラムを作成する ζ とが不可能とは言わないが， C を好むプログラマーは，ソフトウェアを早く作成するととの方に興味がある。彼らは， (Ada プログラマと比較して)エラーを起としがちな構造を避けるための時聞を取ろうとしない傾向にあるし，ピットあるいはポインタレ
ベルで遊ぶととを気にしない。 C が人気があるのは， Unix の普及によるととろが大きい。 C によるコーディン

グは企業に，発展するハードウェアに対しての最大の柔軟性を与えている。
C の道を離れる理由は今のと ζ ろ無い。しかしながら，との道をとるととについて自分を欺くな。 (C が人気があるのは)市場ニーズのためであり，可搬性のためであり，短期収入のためである(いずれも立派な理由だが)。

それは，高品質製品のためではないし，長期の市場侵入(確保)のためでも無いし，長期の利益のためでも無い。

2.
6

プロトタイピング軌跡

ソフトウェアプロトタイピングが人気が出始めたのは， 80 年代中期から後期にかけてであった。プロトタイ

プは，必要なあるいは不必要な機能，あるいは，ユーザインタフェースの有効性のような事がらを発き出すのを助けるために，システムの初期パージョンをユーザに提供した。今日作成される多くのソフトウェアがユーザの問題の解決に失敗しているから，プロトタイピングは，完全なシステム作成前 K ユーザ要求が明らかになっているととを保証する手助けをする。
プロトタイプは，素早く作成されてとそ役立つ。それゆえ，過度のテクニックとツーノレが現われ敏速なプロト

タイプ作成を助けた。しかしながら， 90 年まで，“早いが汚い 7" プロトタイプもソフトウェアコストとずれ込
む納期の増大への対策として用いられるようになった。その論理は，“もしソフトウェアのプロトタイプを素早く作成できるなら，単に，プロトタイプを製品と呼ぶととよって，全てのソフトウェアを素早く出荷するととができる J' だった。

考えてみてほしい。もし我々が高品質ソフトウェア製造の試みにも関わらず効率的でないとしたら，試みもしない製品はいかに酷くなるだろうか?どのようにすれば適切なコストで高品質に製造するか知らなければ，高品質かつ無視できるコストでいかにして製造できょうか?我々は，いかに品質をプロトタイプに付加するか明らかに分かっていない。

レミンジニアリング流儀の典型として，重要なアイデアを取りだしながら，応用を間違えてしまった。プロト

タイピングは，ユーザ満足を保証するのを助ける重要な手法であり，それゆえコスト低減ができる。品質を保証する全ての技術を除去するととによって開発コストを減らそうというのは，とてもまずいやり方である。
プロトタイピング軌跡上のレミングは，突然崖に向かつてそれで行ってしまった。

2.
7 CASE 軌跡
元は，ほとんどの CASE ツールは，初歩的な構文チェック能力を持つ図形エディタであった。 CASE ツール
は，ワードプロセッサが物書きを助けるのと同様に，ソフトウェア技術者を助ける。 CASE ツールは，劣っている技術者を良くはしないが，各技術者を効率的にし，かれらの製品を見栄え良くする。
不幸なととに，その市場競争が激しいがために， CASE ツーノレは主たる価値ではなく，幾多の他の機能:自動
7q
u
i
c
k
‑
a
n
d
‑
d
i
r
t
y

SoftwareSymposium'
9
4

‑24‑

北海道，函館

80ftwareLemmingineering8ummary.9 No.6‑
7
8eamailVoI

コード生成，自動プロトタイプ生成，自動テスト生成などで売られている。 CASE ツールの評価時には，“只飯(freelunch)" は無いととに気を付けよう 。
との道のレミングは，暴走している。しかし，多くは売りすぎてしまった道の行方に何があるか気づいてい
ない。

2
.
8

再利用軌跡

全ての工学分野では，組み立てブロックの使用による製造を奨励している。とれら分野では，とのやり方は“利用 (use)" あるいは，“工作する( engineering)" といいい‘再利用する (re-use)" とはけっして言わない。ただ，われわれの分野だけで“再利用"が，流行り言葉 (buzzword) になっている 。
明らかに，もし我々が新たなシステムを構築するときに，組み立て式のソフトウエアコンポーネント(セグメン トより大きな)が利用できるとしたら，開発コ ストと工期は減少し，製品品質は向上するだろう。我々は今 や，

潜在的に再利用可能なコンポーネントのリポジトリの普及と，最終的な再利用に向けての視点から新たなコン
ポーネントの構築 r忙しい。そして，驚くほど大量の努力が ζ れらの未熟な技術に費やされている。
我々は，何が組み立て式か，再利用可能なコンポーネントがどのようなものか本当に分かっているのだろう
か?もちろんリポジトリ販売者は肯定するだろう。我々は，そのようなコンポーネントが何であるか，いかに保存し，検索し 3 組み立てるかを学ぶ前 K ，明らかに沢山のコンポーネントとたくさんのリポジトリを経験しなけ
ればならないだろう。私 (Davis) は，研究者及び実践者による広範囲な実験を支持する。しかしながら，技術はいまだ非常に新しい。

他の多くの道と異なり，ととにおいての目標は極めて現実的であり，最終的には達成されるであろう。しかし，道はまだ舗装されていない。足下に注意，短期的には自信を持ちすぎることなかれ。

2.
9COMQUATS[SIC)軌跡

注文生産によるアフ. Y ケーションでのコスト削減と品質向上の努力は，ユーザ満足を得られない結果の繰り返しに終わっているため，もう一つの道として， COTS(
Commercial0住 the-shelf) つまり，市販製品を使う道を提案8 している。
既存の完全なシステムに，市販のカスタマイズ可能なソフトウェアを追加するととにより，高品質かつ低コス
トのシステムを構築可能だとしている。との場合，分野により，あるいは，どの程度カ スタマイズが 可能か?どの程度の品質か?にでき上がったシステムが依存するととになる。むろんとれだけで完全なシステムができ上がるとは限らない。

したがって， COMQUATS とは， C
ommercialo
f
f
‑
t
h
e
‑
s
h
e
l
fq
u
a
l
i
t
ysoftware のととである。

(しかしながら，後述する Davis との討論会で，単なる冗談と言われてしまった。)

図 1. 討論会時の Alan Davis 氏(左から田中，青山，新谷， Davis ，荒木，鳥居，塩谷，渡濯の各氏)

8ζ とで，“COTS は究極の再利用だ吋 COTS i
st
h
eu
l
t
i
m
a
t
ei
nreuse.) と述べているので，とれが有望な道と Davis が評価しているのかと筆者は考えていた。

1
5‑
1
7June1994‑25‑

Addendumt
otheProceedingsof8894

Softw町e L
emmingineeringSummary

SeamailVol.9 No.6‑
7

3.

ソフトウェアレミングの軌跡

Davis らの表にアンケート結果の 一 部を合わせたものを表 .1K 示す。

軌跡
構造化

オブジェクト|活発な期間|
1
9
6
5
‑
1
9
8
6

1
9
8
0‑
2000

(OOD&OOP)(OOA)
プロセス成熟度

C

プロトタイピング

CASE

再利用

1
9
9
0
‑
2
0
0
5

1980‑2000+

1985・ 2000+

達成目標

￨達成年

開発コスト低減

1975

低(低+)

低(中)

ドキュメ ン ト品質向上

1
9
7
5

低(低+)

低(中 一 )

1975

低(低+)

低(中)

開発コスト低減1990

低(中 一 )

中(中一)

信頼性向上

1990

低(中一)

中(中)

保守性向上

1990

低(中 一 )

中 ~高(中+)開発コスト低減

1993

高(中)

低(中一)

顧客満足度向上

1993

高(中)

低(中)

プロセス向上1993

低(中 一 )

中(中)顧客満足度向上

1
9
9
3

高(中)

低(中)

品質向上

1993

高(中)

高(中+)

開発コスト低減

1
9
9
3

高(中+)

中(中一)

開発コスト低減

1980

中(中)

中(低+)

移植性向上

1
9
8
5

低(中一)

高(中)

品質向上

無理

高(中+)

無し(低十)

保守性向上

無理

高(中)

無し(低+)

顧客満足度向上

1993

低(中一)

高(中+)

開発コスト低減9

無理

高(中+)

無し(中)

1
9
9
3

低(中一)

中(中)

劇的生産性向上

2013+

高(中+)

高(中一)

ドキュメント品質向上

1
9
9
3

低(中 一 )

中(中)

品質向上

1
9
9
3

低(中一)

低(中)

開発コスト低減

品質向上

Comquats10

1988- ∞

|見返り度

顧客満足度向上1988‑2000+ ほどほどの生産性向上

1988- ∞

|危険度

開発コスト低減

品質向上

1
9
9
6
‑
2
0
0
3 高(中+)
1
9
9
6
‑
2
0
0
3 高(中)

応用依存(中+)

1
9
9
6
‑
2
0
0
3 高(中)
1
9
9
6
‑
2
0
0
3 高(中)

応用依存(中+)

応用依存(中)

応用依存(中)表 1. ソフトウェアレミングの軌跡

低ととで， Davis の評価と併記して，後述するアンケート結果を， 0 内に，(0 ,,-, 8%)

低+

(
9
"
‑
'
2
4
%
)

中ー

(25 ,,-, 41 %
)

中

(
4
2
"
‑
'
5
8
%
) に分けて示して

中+

(
5
9
"
‑
'
7
5
%)

高

(
7
6
"
‑
'
9
2
%
)

高

(
9
3
"
‑
'
1
0
0
%
)

いる。

9 使い捨て版の配布によって
1
0C
o
n
u
n
e
r
c
i
a
lo
f
f
‑
t
h
e
‑
s
h
e
l
fq
u
a
l
i
t
ysoftware ・ Davis の造語

COTS:C
o
n
u
n
e
r
c
i
a
lo
f
f
‑
t
h
e
‑
s
h
e
l
f

Sof wareSymposium'
9
4

‑2
6‑

北海道，函館

Sof王ware L
emmingineeringSummary4.

SeamailVol
.9 No
.6
‑
7

ソフトウェアレミングアンケート

5594 での“ソフトウェアレミ ンジニア リ ング・パネル"に先立ち ， 事前に同一項目について のシンポジウム

参加者の評価を記入して いただいた。との結果を表 .2K 示す。

軌跡

構造化

|危険度(%) I 見返り度(%) I レミ ング度 (%) I

達成目標

6/3
1
(
1
0
)
7/3
1
(
1
1
)
9/3
2
(
1
4
)

2
7/3
2
(
4
2
)
2
5/3
2
(
3
9
)
1
9/2
9
(
3
2
)

2
8/2
9
(
4
8
)
2
6/2
9
(
4
4
)

2
5/3
1
(
4
0
)
1
9/3
1
(
3
0
)

2
5/
3
2
(
3
9
)
3
2/
3
2
(
5
0
)

2
6
/
2
9
(
4
4
)

顧客満足度向上

2
4
/
3
1
(
3
8
)
3
3/2
9
(
5
6
)
3
0
/
2
9
(
5
1
)

3
9/
3
2
(
6
0
)
2
1/
3
0
(
3
5
)
2
6
/
3
0
(
4
3
)

プロセス向上

1
7
/
2
8
(
3
0
)

2
8/2
8
(
5
0
)

顧客満足度 向上

2
5
/
2
7
(
4
6
)
2
9
/
2
8
(
5
1
)
3
6
/
2
8
(
6
4
)

1
6
/
2
7
(
2
9
)
3
6
/
2
8
(
6
4
)
2
1
/
2
8
(
37
)

3
0
/
2
9
(
5
1
)
2
3
/
3
0
(
3
8
)

1
3/3
0
(
2
1
)
2
7
/
3
1
(
4
3
)

3
5
/
2
9
(
6
0
)
3
4
/
2
9
(
5
8
)

8
/
2
9
(
1
3
)
6
/
2
9
(
1
0
)

8
/
2
5
(
1
6
)

2
3
/
3
1
(
3
7
)
3
8
/
3
1
(
6
1
)

4
4
/
3
2
(
6
8
)
2
6
/
3
0
(
4
3
)

3
3
/
2
8
(
5
8
)
2
5
/
2
7
(
4
6
)

2
1
/
3
0
(
3
5
)
3
6
/
2
8
(
6
4
)

2
8
/
3
0
(
4
6
)
2
0
/
2
9
(
3
4
)

品質向上

2
2
/
3
0
(
3
6
)
2
3
/
3
0
(
3
8
)

3
0
/
3
0
(
5
0
)
2
6
/
3
0
(
4
3
)

2
2
/
2
6
(
4
2
)
1
3
/
2
5
(
2
6
)
2
6
/
2
6
(
5
0
)

開発コスト低減

3
7
/
3
0
(
6
1
)

4
3
/
3
1
(
6
9
)

品質向上

3
4
/
3
0
(
5
6
)

3
6
/
3
1
(
5
8
)

2
9
/
2
8
(
5
1
)
2
8
/
2
8
(
5
0
)

開発コスト低減

品質向上

2
9
/
2
7
(
5
3
)
2
7
/
2
7
(
5
0
)

3
1
/
2
5
(
6
2
)
2
9
/
2
6
(
5
5
)

1
5
/
2
1
(
3
5
)
1
4
/
2
1
(
3
3
)

情報入手容易化

4
/
2
(
1
0
0
)
。 /1 (
0
)

1
/
2(
2
5
)
2
/
1
(
1
0
0
)

1
/
2(
2
5
)
1
/
1(
5
0
)

開発コスト低減ドキュ メン ト品質向上

顧客満足度向上オブジェ ク ト

開発コ ス ト低減

(000&OOP)

信頼性向上
保守性向上

(
O
O
A
)
プロセス成熟度

開発コスト低減

品質向上
開発コスト低減

C

開発コスト低減

移植性向上
品質向上
保守性向上
プロトタイピング

顧客満足度向上
開発コスト低減 11CASE

ほどほどの生産性向上

劇的生産性向上ドキュメント品質向上

再利用

C
o
m
q
u
a
t
s
F
o
r
m
a
lA
p
p
r
o
a
c
h
I
n
t
e
r
n
e
t

2
0/
2
6
(
3
8
)
2
6/
2
8
(
4
6
)
3
7
/
2
9
(
6
3
)
2
0/
2
6
(
3
8
)
2
2
/
2
6
(
4
2
)
2
0
/
2
7
(
37
)
1
4
/
2
6
(
2
6
)
2
5
/
2
7
(
4
6
)
1
2
/
2
7
(
2
2
)
1
3
/
2
7
(
2
4
)
2
0
/
2
7
(
3
7
)
1
0
/
2
5
(
2
0
)

2
3
/
2
6
(4
4
)

表 2 . ソフトウェアレミングアンケート集計結果

アンケート方法は， Davis の表の評価欄(危険度，見返り度)を空欄にし，さらに回答者自身のレミング度(自分自身がどの程度その技術に入れ込んだか?)も併せて記入していただいた。加えて ， 目標達成年度のうち“無理"あるいは，未来日付になっているものについても空欄とした。最後に，空欄 の 1 項目を設け，つけ加えたい
技術についても記入していただいた。

10 使い捨て版の配布によって

15‑
17June1994‑27‑

Addendumt
otheProceedingso
f8894

SeamailVoI.9 No.6‑
7

4.
1

Sofも ware L
emmingineeringSummary

アンケート評価方法

評価方法は， D
avisにならって，高中低の 3 段階評価とし，それぞれ 2 ， 1 ， 0 を割 り当てて集計し，平均値(%)を出した。表中の分数の分母が有効回答数，分子が評価合計値， 0 内が平均値(%)を示している。
とのデ ー タを縦軸に軌跡 (技術項目)をとり，横軸に危険度，見返り度， レミ ング度をとり，折れ線グラフ(図 . 2)で示した。軌跡毎にグラフは切れている。

レミングの軌跡・アンケー卜集計結果
コスト:情進化文書:情進化
顧客:栂進化

f
ﾇ
:
:
'
.
:
:
.
:
:
.
:
:
:
.;;.~~3S 戸 :ーづ: : 市検仁… 一…升一週了一 一一 ー 一一一一一一一…ーー ー…旦返りー

レミング-E}--

j……… ・・ +-+ι … .9 ナ……

コスト :OODP

十一一戸北 3・.... . ， .. .. . ....

慣頼性 :OODP

供ご一一 ..~. ..... 13-::.可子ζ

保守性 :OODP」…... ~ .!一一一一 三竺半白一一…;一一一

コスト :OOA

一 一一一一 一 i一一.. . . .十 一一一一 一十:::;::: ?忘〆 ::::::::: ::;:::::::;:: :;顧客 :OOA

向上:プロセス。長よ二;.8-' +一一 二日+一一 ー …ー十一一 一

顧客 : プロセス....:一一一 '8:，封ち二え:三戸、-十一一十 一 一

コスト:プロセス~' G"~:':'~ 干:一一 +~~:-::-::::二一 一 一 一 一宇古令

コスト :C

移植性 :C
品質 :C
保守性 :C.

十一一:二三三日四一予三~;;4"~斗 一一ふ一一一一

品質:プロセス-ーー '1+-t3;，;.:;.::.1'一一一-…?一一 二戸ポ ーー…ー ーす

ゲザ♂f二一一一三マーサ - ・ ・・-ー ギ 一一・ 6 …;一一一一一・ 4

一一ー÷…一一…… φ ート

顧客:プロ卜令宇ぷζご十一二:.: ..~.:与二五~-← i一一一一一一一一 j.

コスト:プロト…-← - ←包町一一.~ゆほどほど :CASE

令岨~ヨ 2・ト

劇的 :CASE

一一一一ート一 一 一一 一;一一 一 一一一 ←..".…e.-，そん・ ヤミヒ 十……ーイー…三三~文書 :CASE

ーヤデ?フ$ ... .… 十 一一…!

晶質 :CASE一一。÷ 一週二一 十一-……ート一一

コスト :再利用
品質 :再利用;:::;: ::二;:::::::;::二二Z::ぷ~:::.:;;1

コスト :Comquats-伊品質 :Comquats
0:低i

7 ・ -þ '……ドキ .. . _. _ .-十・…・ ・

-,

.", -

.

… ・・，;"，8 ……→. . . ・ H ・….. …・ -+'・ー…トー... ・ H ・.{ ・ ・・……

10

20

30

40

50: 中

%

60

70

80

90

100:高

図 2 . レミングの軌跡・アンケート集計結果

SoftwareSymposium'
9
4

‑2
8‑

北海道，函館

S
o
f
t
w
a
r
eLemmingineeringSummary

5.

SeamailVol.9 No.6‑
1

アンケート結果について

まず，表 .1 で， Davis の評価とアンケート結果を比べると，およそ 30 人からの回答を集計したため平均化され，ほぼ“中"の評価となっている。しかしながら，おおむねその傾向は，中に集中しているとはいえ， Davis の評価に近いようだ 110

構造化については， Davis の指摘どおり既に実践しているため，リスクは非常に低く見返りも“中"程度と好意的に評価している。

OOD& OOP については，危険度は“中"で高め，見返り度については“中"で，意外に冷めた目で見ている様だ。 OOA については，むしろ好意的で，危険度見返り度とも“中"と評価している。
プロセスについては J‘中"に偏っているが，ほぼ Davis の評価と同様だ。
C については， Davis 同様に厳しい見方となっている 。 元の評価では，“見返りなし"となっていたととろをあえて評価 して頂いたが，“低+"と いう結果になっている。 CK よる製品の 品質向上と保守性向上 に 問題意識を抱いているととの現われだろうか?それにしても，コストと移植性についてはもう少し高い評価があっても良いのではないだろうか。

プロトタイピングは，開発コスト低減については，“使い捨て版を配布するととによって"という厳しい条件がついていて，さらに“見返りなし"となっているが，“中"程度の見返りがあると回答している。とれは， Davis
よりも積極的にプロトタイピングの利用を考えでの積極的な回答の様に思われる。
CA8E については， 8894 のパネル時にもパネラーの伊藤氏からも指摘があったが，劇的な生産性向上に対して，危険度を高めに評価するのは理解できるが，劇的な生産性向上つまり見返りが大きいととが保証されていると考えられるのに，見返り度は，危険度に比べて低めになっている。見返りを期待したいが，現実はそううまくは行かないという，過去の手痛い経験の反映なのか?あるいは， CA8E ペンダーが主張する過剰な宣伝の裏を冷静に読んでいるととの証明なのだろうか?との点以外は，“ほどほどの危険度でほどほどの見返りが得られる"と，冷静に得失を考えている様に見える。

再利用と， Comauats については，後述。
最後にアンケ ー ト結果のグラフ(図 . 2) で，筆者が突然，思い付いてつけ加えた“レミング度"に着目すると，見

返り度とほぼ比例する結果が出ている。見返りが多いと思うからとそ熱中するというのは，まさにそのとおりではないかと思う。ただ，と ζ に上げた全ての技術を実践できる人，あるいは実践した人は，少ないと思われる。

よって，レミング度(見返り度も同様か?)には，かなりの期待値が入っており，特に比較的新しい技術について
は期待度の方が大きいように思える。その例が，再利用と Comquats というわけの分からない新技術に対しての，“リスクも見返り度も高いが，レミング度は低い"になって現われていると考える。

なお，表 . 2 の最後の 2 項目は，回答者がつけ加えた項目である。 Formal approach が 2 名，話題のインターネッ
トが 1 名だった。もう少し，色々な追加があるかと期待していたが，件数が少なかったためグラフには加えていない。

6. SoftwareLeIllIllingineeringDebate
8894 が終わり，ほっとするのもつかの間， 6 月 23 日夕刻，川崎の富士通クロスカルチャーセンターに，メー
ルで希望者を募った結果総勢 15 名が集まり， A
lanDavis を含む IEEE 80ftware 誌編集委員会委員 5 名の参加を得てソフトウェアレミ ンジニア リ ング 討論会を開催した 。との時のもょうを以下に簡単にまとめる。

6.
1 Eagle‑eyeperspective
8894 のパネノレでも話題になっていたととだが，何もレミングの様に皆が崖から落ちてしまわなくても，気がついた人が方向転換して知らせれば良いではないか?という話が出ていたが，ととでの Davis の回答は，“ヘリコプターからの視点つまり鳥観(僻服)による展望 (Eagle-eye perspective)" を用いるととを勧めている [5] 。 ζの展望は，実際には各軌跡を辿っている人々に聞いたり，他の軌跡と比べたり，実証された技術であるのかなどを調査したりするととによってのみ得られる。同様に，軌跡を辿り始めたら先行者の動きをよく見たり，斥候を出したり(プロトタイピン グのととか?)するととによって，危険を察知できる。
11 注:未記入項目， 0 あるいは無限大など，指示したもの以外の回答は集計からはずしている。そのため項目毎に母数が違っている。表 215‑11June1994‑29‑

Addendumt
otheProceedingsofSS94

SeamailVol.9 No.6・ 7

6.
2

SoftwareLemmingineeringSummary

ハメルーンの笛吹きとの討論会に参加された東大の玉井先生が，ハメルーンの笛吹き 12 の様に，誰かが笛を吹いて新技術を知らせるととも必要だ。との指摘をしたが， ζ れについても「新技術の存在を知らせるととは重要だ。しかし，ハメ
ノレーンの笛吹きに踊らされて，水に飛び込まされたのは，レミングではなくてどぷねずみ (rat) だ 。ど ぶねずみ
は理由を知らずについてくる 。 レミ ングは 概念についてくるととろが違う。」と言っていた 。 (とのレミングは，人を指すのか?あるいは，死ななければならぬ宿命を悟っているととを指すのだろうか?)6.
3

5 ，，-， 10% の生産性増加で十分

CASE ベンダーなどが，大きな生産性向上を宣伝しているが，誇大宣伝だ。実際には， 5"-'10% の生産性増加で十分だと考えるべきだ 。

6.
4

AI レミングは未だ崖に達していない?

AI が表に載っていないととを指摘するとI 少数の年寄り AI レミングはずっと以前からゆっくりゆっくり歩み続けているが，未だ崖には達して いない。 まだまだ当分かかるだろう。」

6.
5

よく見て飛べ (Look b
eforeYOULeap!)

Davis の 7 つの助言 [3J-現実的な目標設定。

ー成功についても現実的であれ0.宣伝を盲信するな 0.納得できる技術を選べ。
・危険と確度，および効果を評価せよ。

・注意せよ。しかし(余裕がないからといって)無視するな。
-当初の目的を忘れるな。ー初心忘るるべからず。手段が目的になってしまってはまずい 0

・“皆で渡れば怖く無い"は止めよ!・数に頼るな。
との助言は， BobGlass による反論記事 [4J に対しての反証として反論記事内のコラムとして掲載されている。

6.
6 ThePathLess'I旨 aveled
また，ソフトウェアレミンジニアりングコラムの反響が大きかった様で，更に，別の号でも低コストかつ低 P
スクの 6 手法 [5J も提案している 。
-顧客との対話・プロトタイプによる事前検証ととではけなすととなしに，本来の意味でのプロトタイピングの活用を奨励している。

・Trade・ off analysis の実施• Formalmethod の部分的使用
部分的にでも，仕様の一部を形式記述するととにより，矛盾点・不整合などが発見できるので，取り入れるととを勧めている。

・レビュー，ウォークスルー，コード検証の実施

・技術の掘り出し(聞いて回れ)
Davis も，アンケートの回答にあった様 K ，形式記述の利用を認めている。また，辛練な批評では悪く書いていたプロトタイピングについても，正当に評価しているととが分かる。
12 “ The P
i
e
dP
i
p
e
ro
fH
a
m
e
l
i
n
"b
yR
o
b
e
r
tB
r
o
w
n
i
n
g

SoftwareSymposium'
9
4

‑30‑

北海道，函館

SoftwareLemmingineeringSummary

7.

SeamailVol.9 No.6‑
7

あとカt きもう大分たってしまい，テープ起としをする気力も無いので，当日のメモから拾ってみたが，案の定大したととは書けない。そとで，記憶と Davis のコラムを参考にまとめてみた。 Alan Davis 氏は快活な大男て\多少下
品な言葉を使う傾向にあるが，人の良い気さくな人柄で，実務経験もある様で博識であり，ていねいに解説していただいた。 IEEE 80ftware 誌の次期編集長に決まったという話を後で知った。

先にも書いたが， C
ornquats (とれも Davis の造語)については，コラム中で“ COT8 は究極の再利用だ。
(COT8i
st
h
eu
l
t
i
r
n
a
t
ei
nr
e
u
s
e
.
) "と書いているが，乙の件について聞くと，「 そんなととを書いたはずは無い。」と否定するので，「 “ultirnate inreuse" と書いて い るだろう ?J と問うと，「 英語の“ultirnate" には，二つの意味があって，否定的には，大ぶろしきれ00 bigjfar) の意味だ。」と笑われてしまい，自分の理解の足りなさが露呈し少なからずショックだった。との項目については，現編集長にも載せるべきではないと言われたそうで，少し安心はしたが。 00 。

7.
1

アンケー卜についての反省

常々思っているととではあるが ， アンケートというのは難しい。今回の様にできるだけ簡単に読んで回答できる様にと，記入方法を簡略化しでも，項目自体についての説明が十分でないと，“定義が不明なので回答不能"となってしまう。今回に限っていえば， 8894 論文集のレミンジ ニ ア P ングパネルの説明 K 各項目について十分な説明をしておくべきだった 。
とはいえ， Davis のコラムにも説明が無いものについては， (自明な疑問については，あらかじめ解釈法を明記できるが， )それを参照する者が各自推定するととによって補うしかない。今回も大多数の回答者が 自 主的に判断して回答していた 。

もともと，全員が回答したとして 100 名ほどであるので，統計データとしての信頼度は低い。しかしながら，それなりにグラフを見ると興味深い結果が得られる様に思う。次回は，経験の知識の有無，現在の仕事分野などを加えると，また別の傾向が見えてくるのではないかと考えている。

7
.
2

謝辞

解説が不十分なアンケートに関わらず回答していただいた，多数の回答者の皆さんのご協力に感謝する。またパネラーとして貴重など経験とど意見を発表していただいた， GerhardFischer( コロラド大)，伊藤氏 (MA8C) ，
熊谷氏 (PFU) ，長崎氏(ピジョン・コ ー ポレーション) ，および Davis 氏との討論会参加者(氏名は省略させていただいた)諸氏のど協力に感謝する。

最後に，快く翻訳引用するととを許可していただいた Alan Davis 氏に感謝する。
1994.10.18 塩谷

参考文献

[
1
] :塩谷和範， Software Lemmingineering !?，ソフトウェアシンポジウム切論文集 Jun 1994 , pp.
1
7
3
‑
1
81
.
[
2]AlanDavis , Software Lemmingineering , IEEESoβωαre 8ep1993 , p
p
.
7
9
‑
8
4
.
[
3
] Alan DavÏS , Counterpoint: There 訂 e no B
A
D guys , and No one has the "Truth' ヘIEEE

Soβware May1994 , pp
.
9
2
.

[
4
] BobGlass , From Wonderland to the Real Problem , IEEESo.βware May1994 , pp.90・ 92.

[
5]AlanDavis , Rewards of Taking The Path Less Traveled , IEEESoftwareJuly1994 , pp.100‑103.

15‑1
7June1994‑3
1‑

Addendumt
otheProceedingsofSS94

SeamailVol.9 No.6‑7

ククロージング・パネル

てて

1
.

坂本啓司 I桑名 栄 二 5プロセスの位置づけ

兼子毅明

司会:大場充 11

ソフトウ ェア プ ロセ ス と い うのは必要で，何の為に管ぬんと沢山色々なキーワードを耳にいたします。とて: ま あ 月並なととろでは，ユーザの為，より良いれは特 K ，咋年とか一昨年 ぐ ら いか ら，と の 傾向が強ソ フトを作るというかですね，そういう感じもある

く な っ て来ている訳ですね。 とういう物が話題にな っと思 い ます 。 それから，技術者のため，より簡単に仕て い る背 景 には，そ の 後 ろ にある共通したコ ン セ プ

事 をしたい，経済ですけれども楽に仕事をしたいと

ト / キーワードとして「 プ ロセス」が非常に重要なよ

か ，管理者だ っ たら，より高い効率というのは，少い

2

AM 老

司会(大場) 最近， 1S09000 と か， CMM , SP1CE ,EXPER1ENCEFACTORY ですと か ，う ん ぬ んかん

理し なき ゃい けないのか 73 というような ζ とを，色々1な側面から考えてみたいと思っております。

リ ソ ー ス でやりたいとかですね 。 まあ「科学，人類の焦 点を当てて議論したいと思います。

為」というふうに大きく言いましたけれども，ソフト

1 プ ロセス」は今回の SS94 でも， 議論があ りの 開発工程って，いったいどうなっているんだろう，

ましたけれども，どのレベル(あるいは立場)で捉えとい う ととをもう少し深 く 知りたい 。 「何故，失敗するの か ?J だとか「何故，失敗したか」ですとかです

極端な抽象化というか単純化をすれば，要求が入ってね，そういう ζ とを説明したい。というような様々なきて ， 最終的にプロ グ ラムとかドキュメ ン トとかを観点や考え方があると思います。
そ と で，とういうパネルを形成するにあたって，こ

それを生成する工程をプロセスと非常に大き く 見る

こにおられる非常に御高名な方々にお願いしたととととも出来るし，それをさらにプロセ ス のプロセス

ろ，御快諾を頂きましてパネルを形成するととになりとして細分化していったととろを見るととも出来るました 。 簡単にパネリストの面々を発表順に紹介し

ユノ

しの立

含めて ソ フトウェアというものを出すわけです。 で，G

るかによって非常に変ってくると思うんです。 まあ，

2 久志す間てとれしうな感じがします。 で，今日は ， その「プロセ ス J K
で，

さ覇てと

パネリス卜:久保宏志↑ν

これからのソフトウェア・プロセス・マネージメンド

たいと思います。

求"も勿論ですけれども，“技術者"それから“利用

最初は，富士通の久保さんです。え -1 仙人」と書き移者"というものもあります。あと勿論“管理者"もあましたけれども，そういう超越した立場での発言を期レ3りますね。で，“管理者"の側面から見ると，プロセス

待しております 。 今回の SS でも，初日から色々と積そを改善したりするというととは，非常に興味がある 。

極的に発言されておられますので， ζ れは十分に期待

レ、

一方，ソフトウェア自身，ユーザから見る，その品質，に沿って頂けるだろうと考えております。

コスト ， デリパりなどと い うととも問題になります 。

で， 2 番目 。 オムロンの坂本さんです。 「 メンター J 4 と“技術者"から見れば，当然，それを実行するのか?と書きましたが，皆さんを導いてくれる，非常 K パラン

いうととが問題になりますね。例えば，レビューをす

ス のとれた方ですので，理性的な発言があるのではな

る。デザインをする。どうやってデザインをするか?，

いかと。特に管理面，プロセスと管理というととに関と。そういうことですね。で， ζ とでは，一応「とれしましでは，現場でずっと指導されておりますので，からのソフトウェアマネージ メ ント」というととで，色々な経験を通して得られた知見を披露して頂ける

ソフトウェアプロセスの管理3 という側面。何の為にと期待しております。

• 1994 年 6 月 17 日
f 富士通(株)9 : 30 ‑ 1
2:
00

シ ステム本部

次に NTT ソフトウェア研究所の桑名さんです。桑名さんは ， 現役のバリバリでやっておりますので，

1親t オムロ ン (株) EFTS 開発セン タ ー第二開発室
5 日本電信電話(株) ソフトウェア研究所
明東京大学 工学部化学システム 工学科

方的」と書きましたけれども“最先端で働いている人

H 広島市立大学 情報科学部
1Capability Ma七uri屯 Y Mod・1
2So:t主vare Process Improy・E・n七 and Capability

ういう意識を持っているか?"というととをお聞きし

dEt ・ rmination

として，プロセス K 対してどういう反感ですとか，ど最後に，東大の兼子さんです。 I ]Jサーチャ」としてさい。スケジューんを‘管理する'とか，そういう意味ではありま

4mentor

せん。

SoftwareSymposium'
9
4

5

たい，と。

‑32‑

良き指導者，助言者

北海道，函館記;>tν ，，、3 ととで‘管理'という言葉は，非常に メタ なものだと解釈して下出で出うの出のと減で注とむと。で，とれに影響を与えるものとして，例えば“要h615クロージング・パネル

ですね，

SeamailVol. 9 No.6‑
7

r 書生的」と書きましたけれども，良い意味

ポートの第 l 版が 3 その 5 .1 の出荷直前になって書かですから。そういう観点でですねお話をお願いした

れたわけです。その時は， 16MB で動くようなものに

いと思います。

しないと競争力が無いというととでやってきたが実で，基本的な精神はですね， 50 代を代表 し て久保

際の製 品ではとてもそ んなメモリ容量では動作不可

さん。 40 代の技術者を代表して坂本さん 。 30 代の能 。 で，かつ memory leak7 その他にもコマンドの現役を代表して桑名さん 。で ，ちょっと‘とう'が立 っ

レスポンスタイムが 4.0.5 から比べると 40%位増えていますけれども， 20 代の意見を代表して兼子さんている，というふうに色々な問題が見つかってきた。

というふうにアサイ ン しました 。 それでは，久保さん

で，そういう状態のまま出荷予定を迎えた 。 で最終から， パ ネリストの面々 K 最初にお話を頂いて，その的にととで一般出荷は取り止めて，限定出荷だけ行

あとフロアの方に展開したいと思います。

なった。その段階でも，パグは沢山あって，それらにプライオリティを付けをみると，修正しなければなら2.

SGI のパニックを例にない大事なパグがおよそ 500 個くらい残ったようで

久保 50 代を代表する，と 1ハうのはちょっと無茶で，かす。 けれどもなり外れていると思うので，典型的ではないと思いまだ」と偽って出荷しちゃっているんですね。とれが 5すけれども，よろしくお願いします。で，私が貰った月の出荷の話。

「それは例外である。パグは O( ゼロ)

問題は「プロセスの標準化改善という課題をどう考え

そして，乙のレポートが書かれた 10 月に至ってもて，どういう態度で立ち向かうべきかりです。 その殆ど事態は改善されていない。やっぽり，その年のときに“技術者として"というのがあるんですね。そ初めに提案したと同じように混乱が続いている。で，れを考えるために，皆さんのお手元に資料5 をお配り

Tom 達はしました。とれは シリコングラフィックス社 (Silicon

そういうととでもやらないと残っているパグのフィッ

G
r
a
p
h
i
c
sInc. ，以下 SGI) で同社のワークステーショ

クスは不可能だ。絞り込んで，あとはど ζ か的を絞っ

ンIndy 用の OS IRIX の開発で発生した問題点を記てコードウォークスルーとデザインレピューをやりしたものです。著者は TomDavis という SGI の中ましょう。そうやってなんとか 5. 1. 2 の出荷を実現しの開発者で，社内で偉くはないようですが，会社を創ましょう」と提案している。また，それからその後，立した Co-founder の 1 人のようです。

長期的にどういうととをしましょうか，というととも

昨年 (1993 年 )10 月の段階での SGI の中に場面を

r5. 1. 2 の機能範囲を絞り込みましょう。

とう書いてあります。が，それで 12 月にどうなった

移して，その中で与えられた課題を考えてみようと思のか?というのは私はまだ知らない。現在，それからいます。その時 IRIX 4.0.5 というのが市場にあるが，8 ヶ月ないし 9 ヶ月経っているんですけれども，今そそれだと競争力が無いので 5.1 というのを開発してのプロジェクトがどうなり SGI がとうなったかは知いるのですが，結果的にとれは出荷できる品質に到達らない。

出来ず， 5 月に出荷停止6 という判断をしています。

以上のような場面の中で，与えられた課題を考え

で， 12 月に，それのリカバリの為I'C 5 . 1. 2 というのをてみたいと思います。まあ，色々にエクササイズを使出荷しようとしている。出荷するためには freez とい

うととは出来ると思うんですけれども，まずとういうう段階が入るんですけれども，その間近になってと状況の中で，そとに働いている人達の意識や行動がどのレポートは書かれている。で，要するに「そのままうだったのか?というのを，ちょっと振り返ってみま

出荷するのはヤパイよ!Jという話です。 93 年の初め

しょう。

の段階で Tom Davis 達は 5.1 の出荷は殆ど不可能だ

全体としては，もうどう考えたってうまくいってなと，そのまま行ったら不可能だと。だから，機能の削

くてパニック状態なんですけれども，何が悪いのか誰減をやったらどうですか?という提案をしているんも解っていない。要するに，事実が無しで，色々な犯ですけれども，それは会社の意志にはならなくて，外人捜しですね。「あいつが悪いんだ」とかいう憶測だ

注の導入というととが行なわれ，まあ，性能が悪いととかが飛び交うわけですけれども，事実が解らない。

とは分っていたので，その性能改良の為に人をつぎ込

で，多分，相当に長時間労働も強いられただろうと思むというディシジョンがなされた。で ，:ta配りしたレ

うんです。まあ，少々高い技術目標というなら技術

5 comp.os.research からの記事を持参された。興味深い
記事だがそれをそのまま予稿集や SEAMAIL IC 転献するのは適当ではないのでしない。興味ある読者は，久保さん屋というのは頑張るでしょうけれども，あまりにも無(hkubo~fhl . fujitsu.co . jp) に直接連絡をとられたい。

ると 16MB を越えてしますといったカーネルのバグ。だから毎日

6 一般出荷は止めて，やむを得ない所にだけ出荷をする

re-boot しないといけない!

1
5‑
1
7June1994

7 動かしているとどんどん常駐が増えていって 1 週間もしてい‑3
3‑

Addendumt
otheProceedingsof8894

クロージング・パネル

S
e
a
r
n
a
i
lV
o
l
.9 No.6‑
7

茶苦茶やらされるとやる気を無くすでしょう。そう

まあそういった物を見直し，それから freezing が来いう状態も発生したであろうと想像できます。そのたから freezing を始めるという事態になっているん

一方で，ハッピーになる人がいるわけです。要するにですけれども，それの時期ですね。そういったものも「俺に任せれば，ちゃんとやってやる」と言って偉く

合理的に行なえるでしょう。また，先程の性能問題のなっていって，だけどその通りにならなくたって「何時のように，何かしらの対処をしなければいけないん

故ならなかった」という ζ とが錯綜して原因が解らだろうけれど，そのために色んな意見が出る。で，そないので，偉くなったままという・・・。まあ，そうい

ういった色々な選択枝の中で，まあ一番良かろうと思うととも起 ζ る。

うものを選択するというそういう合理性ですね。マまた，不具合が多々あるのは解っていますから，色ネージメントの判断に合理性をもたらすというそう

んな人が色んなことを言う。だけれど「とっちに行いうととが効果として期待できる。そういうととがきましょう」という意志は固まらない。で，例に挙げ

MUST であろうと思います。

たのが性能ですが，非常に悪い訳ですから，なんとか

しな h といかんわけです。それなのに，そんな時に

2.
2「まず性能分析しないといけない。その為にはツールが要る」などという悠長な議論が始まってみたり，I
read-only の部分だけをど ζ かにまとめてキャッシングする」だとか，そういう暫定対処的な大技を主張するようなのが出てきたりして，なかなか意見が定まらない。それからもっと悲劇的なととは，売る方と作る方とで全然意見が一致しないまま，時間だけが経過している。売る方は 16MB でないと売れないと言っている。作る方は 16MB でなんか収まらないと言い続けている。

とのように，色々な教材になりうると思いますが，ととではプロセスの‘標準化'と‘改善 'K 絞って考えてみます。私の持っている情報は皆さんの御手元にあるレポートだけで，本当はもっともっと，事実調査(factfinding) をやる必要があって，それから色々な分析をしなければあまり核心的な確信を持てるような案は出ないのですけれども，一応仮説を立てて見るととは出来ると思います。

2.
1 MUST( 必須)項目
まず，予想、のプロセスが必須と言えるでしょう。要するに「今とうだ。で，且つ予定している ζ とをやっていくと，とうにしかならない」っと。そして，それをやる人は，プロジェクトメンバでもなく営業でもなくて，調わぼマネージメントのスタッフ的なととろに持つというととが MUST に近い。とういうパニッ

ク状態になりますと， 2 人の人だと，とにかく話がつかない。で勿論，もう 1 つの MUST は，そのマネージ

メントプロセスの中で，その予想のプロセスからの情報を尊重してプロセスの改善を計る。それは，計画の見直し，削減だとかという判断も助けてくれますし，

あるいは予想の精度の為に正しい情報を提供するというという効果を持ちます。それからマーケティン

グの人達は，戦略ですね。競合戦略，あるいは戦術。

SoftwareSymposium'
9
4

SHOULD 項目

次に， SHOULD 項目ですね。プロジェクト管理ツーノレと見積りツーノレ。とれなんかも，導入しているのか
いないか分りませんけれども，もしも導入していないのならした方が良い。)JJjにその，導入したから仕事が早く出来るわけでもなんでも無いですけれども，色々な精度が高まるというととですね。それから，シミュレーションが出来るようになるという。「とういう前提だととうなる」というシミュレーションが出来るようになる。それから，見積りツール。とれも，ツー

ノレの中に，それなりに経験値が入っているわけで，さらに足らないものは ζ れからどんどんデータを蓄積してゆくというペースとしても入れた方が良いだろうと…。まあ，とういう事が，I長期的にはどうすれば良いのか ?J への仮説ですね。

2.
3 ソフトウェア技術者としてソフトウェア技術者としてどう考え，どう立ち向かうべきか?というととですが。 1 つは， SPICE ですね。まあ， ISO があり， CMM があってそれらをガ
チャっとくっつける感じで SPICE の活動が行なわれている。それに対して，貢献をしてゆくというんです
かね，というととが 1 つあるな，と。

それから「ちょっとくらいついてみたいなあ」と思っているのは，昨年の 10 月から今日まで，一体何が起とっているのか?という SGI の動きをフォローしてみたいなぁと。そのためには，元のレポートが投稿された comp.risks のアーカイブを探せば，その周辺のスレッドが見つかる可能性がある。それを見れば， 10月の段階で NetNews で，どういう議論が行なわれたかというのが分る。それから勿論，現在の段階までを知れば，現在どとにあって，どういう方向に向かっているのかが分るのではと思っています。勿論，今の私の仮説と，実際に彼等に起とっているととを対比してみるのもとれはまた面白いでしょう。で，レポートの‑34‑

北海道，函館

クロージング・パネル

SeamailVoI.9 No.6・ 7

著者である Tom Davis と意見の交換をするという，

司会

ありがとうどざいました。それじゃ，坂本さん。

そういうふうにしたいなぁと思っています。まだ残念ながら彼のメイルアドレスは判っていないんです

3
.

が， c
o
m
p
.risks に記事を投稿した J erryLeichter さ坂本まず，私に与えられた討論のス タンスですがんとはメイルを交換しています。彼からの情報では，現場のマネージャとして(1) 現場のマネージャとしての意見を述べて欲しい 。

幸 K して Tom Davis さんはクピになっていないん→ 40 代すなわち“現場のマネ ー ジャ"だろうですね。僕は，クピになっているのではなかろうかとというとと非常に心配していたんですけれども，幸にしてクピに(2) 企業の開発現場にいる者からみて，標準化の動はならないで，まだしっとくとれを追究しているようきをどう 見て いるか?

です。まあ，ととまでが「どうあるべきか」。私が考→それらの良い点と悪い点。

えてみたととですね。

(3) プロセスの標準化や改善とか ISO-9000 の認証

てら 「 どう立ち向かうべきか ?J というのが，皆さん

取得について，どういうふうな戦略を取れば良K 対するメッセージになりますかねじまず「私と一いのか?

緒にやりましょう」というのが一番ですね。それと，→現実的な話を。

その Tom Davis さんのレポートというのは，色々な点で学ぶべきととが沢山あるだろうと思うんです。で，という 3 つです。

彼が何故ああいうものを流したか解りませんけれど

で，先に結論を言ってしまいます。私の本パネルでのも，もし“Help Me!" あるいは“ Call forComment"

ポジションですけれども，まず 1 つ目は，標準化といとして流したとすれば，ちょっとコンテキスト情報はうのをガイドラインとして使うと。‘ガイドライン'

足りないと思います。そういう「助けてくれ .......J とを別の言葉でいうといったときに，どういうコンテキストをくっつけるべの為の標準化というのは大いに賛成である。また，あ「技術移転の道具」ですね。そきかというようなととをコメント/アドノf イスしてありがたいととである。

げるととも，僕多分出来ると思うんですよ。そうい

それから，そのガイドラインを間違って何かの規準にしようという動きがある。とれに対しては反対であう ζ とをちょっとやってみようと考えています。

それと，一番学ばなければいけないのは，とういうる 。 反対の理由は，効果の割にはロスが多いと。要す

事例を，社会の共通の経験として蓄積していくっているに，“審査を受ける為のパワーというのは大変だが，うんですかね。まあ，そういうととは，なかなか決意

それによって得られるものは，はっきり見えない"としでも出来るととじゃなくて，日本だと確実にクピにいうととです。

なるだろうと思うんですけれども，やっぽり若干の固で， 3 つ目が，プロセスは何のために議論しているの

有名詞を伏せても失敗体験とその P カパリの体験でか?という，そのピジネスゴーノレをもう少し考えない

すね， ζ れが大事なんじゃないかと。

とダメなんじゃないかというととです。

それから，何の為のプロセスかという投げかけが大

まず，今の 3 つについて 1 つずつお話します。

場さんからありましたけれど，とういった経験知を科

プロセス標準化というのは，技術移転の 1 つだと思っ学にしてゆくというととも大事だろうと。

ております。で，例えば IS0-9000 K しでも CMM にしても，それから，我々は一応技術者というととで SEA に

I プロセスを改善していくためにはどんな入っているんですけれど，プロセスは，エンジニアのととをしないとダメか ?J という一般論としての項目プロセスとマネジャーのプロセスがある。で，どちらは，ほとんど洩れなく出ていると思います。そういうが悪いかというと，多分マネジャーのプロセスの方

意味では，非常に役に立つと思います。もちろん，そが悪いと思うんですね。ですから，やはり経営者とれをそのまま開発現場に落せませんが，いずれの規格

か管理者によるマネージメントプロセスの質を良くも項目的には洩れが無く出ていますので，それを社することが，結果的に技術者がノ、ッピーになるための

内標準の作成のペースとして利用し，現場に適用する道であると思います。とういう態度に，すぐ管理者とととは十分に可能です。さらに，とれは会社を跨つていうと嫌う人が大勢いらっしゃるんですけれど，嫌わの標準というととになりますから，社外の人とコミュないでですね~，管理者を助けてゆくと。そうするのニケーションをする上で非常に有効なツーノレになりが，正しい態度である。というととで，私のポジショます。それと，ちょっと泥臭い話なんですけれども，プ

ンを終ります。

ロセスというのは，開発設計者，マネージメントとかそういったととろの従来のスタイルを変えてゆくと

15・ 11 J
une1994‑35‑

Addendumt
otheProceedingsofSS94

クロージング・パネル

SeamailVol.9 No.6‑7

いうととが必要だと思います 。 しかし，それらを変えれぞれのレベルの感覚，現場の感覚というのは非常にるには，すごいエネルギーが必要です。そのツールと適合していると思います。また， CMM を推進していして使えると。とれは「葵の御紋」みたいなもので，る著名な方が色々な資料を作られていますので，そう「 世界標準ですよ」と言って，わけのわからないなん

いった資料が経営層をはじめとして色々な立場の人

か抵抗する人をゴソッと抑えつけられるという，といに説得するための非常に良い材料になっています。例

うメリ ッ トがあるというととです。で，具体的には，

えば，ヨードンさんがプロセス成熟度モデルを紹介しその関係者全員 K í まあ，みんな世界標準に乗ろう

たものがあります [1] 。 また他にも，成熟度レベルがよ」と言 って意識の方向付けが出来るというととで1 から 5 まで上がってゆくと，それぞれのプロジェク

すね 。 改善意欲が非常に低い，いわば「ほっておいてトの状態，実績の分布が良く符く様子を非常に感覚的くれ」という者 K 対しでも「お前，それでは商売になにも説得し易く説明したもの [2] など多数あります。

らんよ」という話で圧力がかけられる。で，エネノレギ

それから，現場レベルにあって，無理の無い意識付けというととでは，やはり改善をするためには，経営的が出来る。レベノレ 1 の人には，レベノレ 1 なりに大変なりソースが必要なわけで，そのととを経営サイドにですねえと言って相談に乗ってあげられる 。 また，そ対して説得するのにも「世界的に通用するためには

ういう現場レベルに合ったものだと。但し，とれは 5とのぐらいは」というようなととで説得材料になる段階というのは，私は粗いと思っているんですけれどというととです。で，それで ， 今，主に議論になるのも，非常に一所懸命改善努力をして 1 ランク上がる

は， 1809000・ 3 ， CMM それから 8PICE といったと

のにまあ 2 年から 3 年，まあ非常にラッキーにいっころになると思います 。

ても 1 年くら いはかかると思います。そういった，しつこく，ねばり強く改善して行くという，そういう取3.
1 ガイドラインとして標準をみる

り組み，まあ，それだけのエネルギーがもつかどうか

私の基本的なポジションとして，ガイドラインとしというととろですね。また，各レベノレ，そこの組織はて標準を見た時にどうなのか?と いうととでお話をレベル 2 ですよとかいうアセスメントする時に，非したいと思います。

常にディジタル的なアセスメント項目になっている

3.
1.
1 IS09000‑3
1809000-3 をガイドライ ンとし て見た場合に，項目的には殆ど網羅していますから ，非常 K 参考になると思います。イE し，

í との項目をやりなさい」というととしか書いてないので，どのくらい深くやりなさい

とかいうこと。それから，もう 1 つは，殆どの未成熟ます。で，そのアセスメント項目を裏返せば「レペル
2 になるためには，何をしたら良いのか ?J というととになるので，それを誤解してしまって，ディジタノレ

的に改善項目を理解するなんていう人もいたりして，との辺りはちょっと問題だな，と思います。

.3 SPICE
3.1な組織にとっては， IS09000-3 の書いている内容といそれに対して SPICE というのは，今までの色々なうのは，ほんとに宇宙に飛び出すほど大変なエネル

議論をととに集約しようという動きがあるというとギーが要る。それに対して，一歩一歩着実にというとで非常に良いととですね。例えば，アセスメント内と ζ ろのガイドが無い 。で，優先順位付けをしていな容が実態に適合しています。 ζ れは先ほど CMM の

いというととろが問題かと思います。というような場合は非常にディジタノレ的なアセスメントでしたが，ところから，成熟度レベル 1 ですね。最近， SPICE でSPICE の場合，例えば「メトリ ックスの ためのデー

は成熟度レベル O というのが定義されているんです

タを収集していますか ?J というアセスメント項目にけれども， 1 というよりむしろ 0 かもしれないです。

対しでも，レペノレ 1 はレベノレ 1 なりに，レベル 5 はレ

O というのは結構多いと思いますけれども 0 の未成

ベル 5 なりに設定されています。 ζ れは非常に実態熟な組織にとっては，かえって混乱する可能性があるチェックに適合しているように思います。で，そういと。要するに，もう少し後でも良いやつを取り込もう

う実態に適合するために，アセスメント項目が 8601

として，余計にひどい自に会うということは考えられ項目という非常に多量になる。で「とれは問題じゃある，というととです。

ないか」という意見もあります。ですが，私は「問題

3
.
1
.
2 CMM
次に CMM 。プロセス成熟度ですね。 ζ の成熟度
モデルというのは 5 段階になっているのですが，そSoftwareSymposium'
94

かなあ?。いや，むしろそのくらいあっても良いんじゃないの ?J という気もします。また， SPICE は CMMと同様にアセスメピトの結果によってレベル分けをしております(図 .1) が， CMM は 1 から 5 まであり

‑3
6‑

北海道，函館

SeamailVol.9 No.6‑
1

クロージング・パネル

ます。 SP1CE は，との 1 から 5 にほぼ対応している

ソフトウェアの開発の場合には 。 そう思います。で，んですけれども，さらに 0 を設定しています。実はとその中で ， Pe( 明示知)の中で判ったととだけを規格のあたりは，ワインパーグさんが同じようにレベルにして MUST 項目にしたのでそれで良いのかという0 を設定していて [3] 面白いなぁと思ったんですが，話があって，それはうまいとと Pe は Pi でくるんでその後 SP1CE がとういうのをやってきたと。で，う現場で活用するというととが無いと，うまいととゆか

ちのメンパーの田中敏文さんが，同じようにレベルないと思っています 。 て\我々がやるべきとととして

O もあって，さらにレベルー 1( マイナス 1) も定義しは，とういう式があるんだけれども ， Pe のあたりのています。そのレベルー 1 というのは，先ほどの久保

定量化を一生懸命しているんだけれども，結果のプロさんのど紹介にあったような，ああいうパニックした

ダクトをどう計測するんだという議論無しにされてプロジェク‘トになると俄然と元気になる，火事場が生いて，ちょっと片手落ちだなあと思っています。それ

きがいという，そういう人達がいる組織だいうととでから，暗黙知を如何に明示知にしてゆくかという ， j

す。まあ，そういうふうにレベル分けしているんですの内容の分析ですね。との関数の中身をもっとはっき

けれども，私としては，まあ，先ほどの CMM も同様りとさせてゆくというととが必要だというととです。

に 2---3 年もかかつて 1 つ点があがるというよりも，

司会

8601 を満点、としておいて

次 K ，桑名さん，お願いします。

「今月は 10 点上がった」

はい，どうもありがとうどざいました 。 ではだとかいうほうが，皆のインセンティプドとしては良桑名私自身は，個人的にはプロセスの研究には絡んいのかなあ，などと勝手に思ったりしています。

でいないんですが，大場先生から「プロセスの標準化や改善に対する考え方と 1S09000 の意義を述べて下3.
2 審査基準としての標準をみる

さい J ，条件としては「開発現場の視点，また現場監

まあ，ガイドラインとして見る時には，そういう ζ と督の立場で述べて 下さい」とスタンスを与えられまで良いと思うんです。けれども，審査基準として見るしたので プロジ ェ ク トの経験などを通じて感じていときにですね，私は，技術者としても，またマネージャ
としても，こんなととやっても効果無いと思っていて反対です。理由は色々あるんですけれども。

CMMるととを述べたいと思います。また 3 私の最近の研究に関連して“とれからの"というととろも述べたいと思います。

は国防省の仕事をしない限り関係無い。我々が「審査してくれ」と言っても多分審査してくれないのではな

4.

品質保証システムその解釈範囲の拡大

いかと思います。で，色々あるんですけれども，何故

まず最初に，私自身の経験の話を少しさせていた反対か?というのは，要求仕様 (Req山内ment) があっだきます。私の基本的に考え方としては，坂本さんもてプロセスを通してプロダクト/最終成果 (Product)

おっしゃられたように，こういったいろんな作業標準を作り出す。それを式で書いてみました。

ですとか品質標準に関して，ガイドラインとして使う ζ とは全く私は異論を持っていません。もう 10 年

P
r
o
d
u
c
t= Requirement*j(Pe , Pi)

くらい前になるんですけれども， NTT 入社以来ずっf は関数 (function) です。 Pe というのは明示知8 。
はっきりと，とうやれば，とうなるよ，と判っている部分。一方 ， Pi は，暗黙知9 です。誰かにノウハウはあるんだけれども，きちっと外に伝わっていないよう準」といわれるものです。私は，大学でソフトウェア

れると思います。例えば 1S09000 だとか SP1CE なエ ンジニアリングを勉強してきたのですが，最初にそんかが，とんな領境だと思います。とういう領壊に対して，現場の工夫だとかノウハウという類の経験値とれを見たときは，r なんだ，とれは?。なんでとういうのがなけゃいけないじただ良いプログラムを書けばかそういうものがあると。そして，これは残念ながら

それでいいのでは ?J というふうに思っていたわけな

プロセス全体の中では圧倒的に Pi( 暗黙知)の方が多いし，その占める割合も大きい。

んです。ところが，いざプロジェクトで仕事を始めますと，とのような作業標準が無いととにはどうしようもない，というのが段々わかってきました。そしてそ必Ue。

規格，標準，手順，

」u

ee

o

首

••

‑ｭ

。

目 可ム
可市

W

い
w

eu
1

-

1

羽4

附刷

・­

工

vava

nn

puvp

令h--・

l

・

4T
胃

'A

E

pp ム

、“‘“

首

eu

C

工

夫

WC

・町

9

令u，

c

0 笥冒

論

文

‑‑‑‑
Z
&b
se‑
‑
M籍叶噌

8

o
r
'r
.
P
P

15‑17June1994

ばらく DIPS というメインフレームの部隊に属しておりました。そこでのガイドラインが rD1PS 作業標

な領域です。まあ，明示知の中には，規格とかも含ま

Pe~Piとガイドラインというものを使ってきました。数年前にプロジェクトは無くなったんですが，入社してしノウハウ，現場のれ以後，私は l 個の自分で核となる作業標準をやっぽ

り持っております。それは今申し上げました DIPS

作業標準ですね (DIPS 作業標準というものは，現在，‑37‑

AddendumtotheProceedingsof8894

SeamailVol.9 No.6 ・ 7

実在 しませ ん が) 。

クロージング・パネル

今日の発表のスタンドポイントの 1 点目は『開発標で ， 今まで様 々な， Ø1J えば Internet を 使っ たネ ッ ト

準というのはガイドラインとして使うべきであ っ て，

ワー クの設計 ですと か， そう いっ た作業を 幾度も経験

しかもフレキシプノレでなければならない 。 そして，そしてき た わけですが，い ず れもず っ とと の中 で使 っ てれは使う側にまかせて良い』ということです。
もう 1 点のポイ ン トとしてはI 何をプロセスの業標準に 基づいた考え方を使 っ てきまし た。 特 K ，そペー ス にしてものを考えるのか ?J

というととです。

の 中でもドキュメ ン トの フォ ーマ ッ トの考え方 / 位置

例えば開発では，ドキュメ ン ト中心に考えるという考付け への 影響というのは ， 非常に大 き か った かなぁとえ方もありますし， ソ ースコードを中心にして考える

思って い ます。例えば ，設 計文書 の中には何を書かなとか，色々な考え方があると思うんですけれども，とねばならな い とか，詳細設計には何を書かなきゃいけもかく何か基本となるものを定めて，それで開発をな い といったととですね 。 また，ドキュ メン トには，

してゆけば良いんじゃないだろうか，またプロセスを

フォーマ Jレなドキュメ ン トとインフォーマノレなドキュ

見てゆけば良いんじゃないだろうかと思います。 で，メントの 2 つがあると思 い ますが， ζ の IDIPS 作業

そとに，ぐちゃぐちゃと色々な物があるんですけれどきた標準の核になるもの(考え方) は，との DIPS 作

I 検討項目表 J I コメ ン ト表 J I 問題票」

も，その大きな物を色々な物を適用して考えるからか「議事録」といった種々のインフォーマルなドキュメ

えって複雑になるので，何か 1 本，すじ道を定めて，そントまで規定しています 。 例えぽ 「 コメ ン ト表」とれでやってゆけば，うまくゆくと。で，しかもやり方

は ， ドキュメントに対して自分が思ったコメントを書としては，今までのプロセスに関しての経験から言う

いてドキュメント記述者に送ると，それからフィードと，大きなプロジェクトにいきなり提供しでもパ ッ クがかかってくるというものです。 また「問題はぜんぜん駄目で，まずはスモールスタートで，サク票」 。 とれは IPQR 票」と呼んでいますけれども， P

セスストーリを作るととが一番大事じゃないかと。私標準 」 では，

ζれは Problem ， Q は Question ， R は Request という意

自身，入社以来，今までずっと色々なプロジェクトで味です。とれは，何かあるルーチンを使おうとしたとやってきましたが，その度に，上司から「常にスモー

きにI とれ，何かおかしいなあ」と思ったり，ある

ノレスタートで行け。サクセスストーリを作れ」といういは「こういった形で改造してくれないか」といっととを，ず~と言われてきたました。で，最初のうちた要望がある場合には IRequest 票」を出すんです。

は「何かなあ ?J と，その言われる本当の意味が良くで，そういった色々なイ ン フォーマルなドキュメント

実感出来なかったんですけれども，それはサクセススの形態が，実は作業標準の中に決められていて，それトーリを作るととによって，実はそのやり方というのを個々のフェーズで使います。とのような作業標準

が，広まっちゃうんですね。 1 つの部門の中でのやりを，例えば， Unix の GUI の設計/開発でも TSS の開方が，サクセススト-1)であるという評判によってそ発にしてもそうですけれども，開発のフェーズの中でのほかの部署も真似をし始める。それが段々と広まっ

ずっと使ってきました 。

てゆく。とのような進め方というのが，組織の中で大だけど，使ってきたやり方が違っていまして，個々の事だと考えます。そして， ζ れは組織構造の多様化だ

場合に応じてそれを revise してきました 。 revise ととか，協調的な開発だとか，技術者管理的側面，利用はどういうととかと具体的に説明しましょう。例え者なりの統合とか使い分けも必要だと考えます。

ば， 10 年位前は，情報はみんな紙ペースでメンパにそれから，グレイゾーンが増大してきているという流していました。けれども今は，もうほとんど電子メ

考え方があります。実はその今までプロセスの中に，イルであったり， Unix のプリテンボードの News シ

考え方として，先ほど坂本さんがステムを改造して使ったりと。とのような工夫は，現

Produd=R
e
q
u
i
r
e
m
e
n
t*
f(Pe ,Pi)

場の人聞にとっては簡単なととが少くありません。ほ
とんど Emacs の mlisp をちょとちょこつと改善すという式を出してくださって，なるほどと思って感心

れば，すぐ出来てしまう話なんですね。で，そういっしたんです。だけど私は， Requirement をかけていたものを活用して現実に開発をしています。もちろる部分に，そもそも間違いがあるんじゃないかと，思っん，開発をしているのですから，その基本となるものているんです。要求技術，獲得技術なんてゅうととが，が必要でそれをきちんと定める必要はあります。し昨今言われていますけれども，そもそも，獲得するとかし，その基本となるものを定めた上では，それを現いう考え方が問遣いで，実は Requirement を“書い場で revise していっても良いんじゃないかと。私のてあげるとと"が大事であると思っています。で，ととの部分が，そもそも成り立たないのに，こんなとと

SoftwareSymposium'
9
4

‑3
8‑

北海道，函館

8eamailVol.9 No.6‑
7

クロージング・パネル

やっててもしょうがな い んじゃないかなあっていう気らないだろう，というふうに思っています。

で，今私たちは 3 つの大きな目標があるんじゃなも実はしてます。それはどういうととかと言うと，先ほどグレイゾーンの増大といったのは，ミシガン大学

いか考えています 。 それはの Olson 教授らを含めた多くの研究者が主張したり(1) 生産物のまず品質を上げる[5 ], IFIP でも 13.2 というのが約 2 年前に出来まし(2) 組織効果を上げるて，その中で User C
e
n
t
e
r
e
dDesign というのを最近(3) モラル

やり始めています。以前から言われているととですがユーザの要求獲得というのは，本当に難しい仕事という話におちつくんじゃないか?。との 3 つが，実です。 で，とれを，もっととうもう少し cyclic K.進めはプロセスという物になるかもしれませんけれども。

よう 。 l 回作ってユーザに使ってもらって，もしくはで，との中で当然モラルというととに対しては，色々なユーザに実際にそのプロジェクトの中に入っ て もらっ

従来からやられている研究があるし，とれからも続けて，それを繰り返しながら，要求を明確にして行くだていかなきゃいけないテーマであるととは自明だと考とか，システムを作ってゆくという考え方なんです。

えています。例えば，杉村先生が面白い本を書かれてとのような User C
enteredDesign でやらなきゃならいますけれども，乙の QVVL(Quality

ない，といった ζ とが出てくると，もはやプロセス自Life) というような形で言われている，色々な研究がof Working

身も明確に規定したり，要求定義からベースにして考あります。また，デマルコさんのピーフ. ルウェアにしえるというととが，うまくゆかないんじゃないだろうてもそうだろうと。で，とういう考え方のもとに，プかと考えています。

ロジェクトをその担当者に任せるととによってモラ

そのような観点からも，品質保証システムの解釈範囲

ルが向上も期待できますでしょうし，プロジェクトのがフレキシプノレじゃないとうまくゆかない，と考えて志気の高揚も期待できると思います。
モラルに関しては，それはそれなりの人に任せておいます。

いて，私たち(ソフトウェア工学研究者)は，今，何を5.

ポスト資本主義とソフトウェアプロセス管理

やらなければならないか?というととで，今 向 かって

最近読んだドラガーの「ポスト資本主義社会」といるのが， VVor
kGroupComputingf
o
rI
n
t
e
l
l
e
c
t
u
a
l

いう本が頭にずっと残ってまして。ソフトウェア開

TeamVVork です。先ほども申し上げましたけれども，発というのは，工場の中で作るような考え方もあるん

ある何かを基本にして定ってかなきゃいけない。そだろうけれども，もう 1 つの考えとしては，やっぽりの走ってゆくというのは ， データ中心でも良いし，ス

知識的な労働者/専門家というのがどんどんどんどん

ケジュ ー ル中心にしても良いんですけれども，その，増えてくるだろう。そうすると「それをどういうふ

何かを中心にして走ってかなきゃならない。

うに支援してゆくのかりというととをそろそろ考え

で，私は， C
orporateVVide(全社大の)な Information

る必要があろうと思っています。

Sharing , DocumentationSharing というのを中心に

実は今まで知識というのは，道具とか工程とか製品して Comunication a
ndC
o
l
l
a
b
o
l
a
t
i
o
nSupportto…

に対して適用されてきたが，今後は，その，ダイナミッ

とか，マネ ー ジメン ト テクノロジを支える技術が必要クに増えたり変わったりする知識自身に，適用されるだろうと考えています。そしてそれにトライしてゆくべきであると考えています。で，そうなると，プロセ方向が，とれからのソフトウェア開発者を教う道になスというか，その問題同定だとかは，問題解決型タス

るんじゃないだろうか，と思って研究しております。

クへ移行するだろう。とれはどういうととかと言う

司会と，問題自身が分かっていれば，それは時間をかけて，さん。

どうもありがとうございました。じゃあ，兼子

人をかけてやれば何とかすれば解けるんですね。ととろが最近は問題自身が分からなくなってきている。

6. QC 屋からみたソフトウェア屋のプロセス観

先ほども久保さんがおっしゃっていたように「何が問兼子まず，乙のテ ー マの前に，私そのもののポジショ

題か ?J というのが実は解らない状態です。皆，よっンについて，簡単に紹介させていただきますと，私はて集まって色々と議論する。「お前が悪いんだ」とか

ソフトウェア技術者ではありません。ソフトウェア「あいつが悪いんだ」と，皆誰でも言いたいととを言

でお金をとっていたのは，大学 4 年生の時に，ある雑

うんだけれども，それは実は問題自身が同定出来てい誌の編集部で 2-3 ヶ月に 1 回記事を書いてプログラ

ないからじゃないか?。で，それを同定するような，何ムを載せるというアルバイトを 1 年間だけやりましかツールだとか環境なんかを整備しでかなければなた。ですから，バイトしていた時も，基本的に主人で15・ 17 J
une1994‑39‑Addendumt
otheProceedingsof8S94

SeamailVoI.9 No.6・ 7

クロージング・パネル作っていたと。て\あるプログラムの時 K ，友達 2--3

うになってると。そうなってれば，どんなプロセスで人使ってプログラム作ったととがあるんですけれど

やっても良いわけですよ。だから，プロセスがとういも，とれは例えば「グラフィックのデータを f乍ってね」

うプロセスで動いてたらプロセスの成熟度がどうだとか「音楽のデータ，打ち込んでね」とか，そんなことか，じゃあプロセスレベノレが l だからレベル 2 にしとでしたから，基本的にチームで仕事をしたととも無ましょう，とかね。レベル 2 だからレベル 3 K しま

いわけです，ソフトを作るのに。だから，そういう意

しょうっていう，その発想自身が，大体僕は気に入ら

味では，皆さんと全然違う，というか肌では，多分わない。良いんですよ，レベノレ O でもレベル 1 でも。そかっていないんだろうなぁと思います 。 で，なんでそれでお客さん，困つてなきゃ良い 。

んな私がパネラとしてととにいるかというと，もとでも， è 客さんが，困 っ ているんだったら，レベル 5

もと私は東京大学で品質管理や応用統計をやっていだって，レベル 6 だって駄目なわけです 。

る講座にいて，それが修士ぐらいからソフトウェアのそういう発想の逆転が無いんだろうか?。何か自分のどうして

品質管理をやろうというととで研究をずっとやって事ばっかり言っている 。
また，ソフトウェア屋さんで思うのは，誰か他の人います。それで，私のポジションは，“ 20 代で"といr顔は二十歳，腹四十」というのがうまいとと考えてくれて，その成果をスホ・ンと自が昔から続いていまして，実は 33 歳ですので，お間分のとこに取り入れてやれば，自分のととろの問題は違えのないように。で， r書生論」というか，“リサー全部片付くという，昨日あたり出た Silver Bullet 10 を

うととなんですが，チャの立場から"というととになるわけです。

まず，どうしてとのソフトウェア屋さんというの求めているような人達が，どこに行っても多いような気がします。ある所にとっての Sillver Bullet は，別は，他人に評価してもらいたがるのだろうか?というの所の Silv町 Bullet であるわけがない。

のが非常に気になる。例えば，例のハンフリーの成熟

大体，ソフトウェアと一言で言っていますけれども，度の 5 段階のレベノレにしても「何でレベルなんとか

世の中には色々なソフトがあるわけですよね。で，例と他人に言われなくちゃいけないの ?J 。非常に気にえぽ，ととにいる皆さんがどんなソフトを作っていなります。物を作る時に，お客さんがハッピーであっ

るか知りませんけれども ， A というソフトと B というたらぼ，要するに，皆さんが作った物を，お客さんがソフトをうまく作る作り方というのが，どれもとれも受け取ってハッピーであったならば，なんのマネージ同じわけがないじゃないですからだって例えば，車，

メシトなんか要らないわけですね。それは QC 屋か

CD ラジカセ，テレピそれにロケ ッ ト作るのが，全部

ら見ると，そう思うわけです。ともかく，約束の納期

同じプロセスでいくと思います?。よく，ソフトウェまでに約束のお金で，そとそとお客さんが納得する品

ア屋さんは，メタなプロセスの話をすぐしたがりま質のものが手に渡っていたならば，お客さんはそれですけれども，そんなとと考えるの止めた方が良い。そハッピーなわけですね。で，皆さんが例えば何日残んなとと，出来るわけが無い，と，思った方が良い。で，業しょうが，休日出動しようが，それはお客さんに関頭の良いやつは，すぐにメタなプロセスを持ち出して係無いわけです。お客さんは，成果物だけを見ている

抽象化しようとしますけれど，そんなととしたってう

わけです。

まくいくわけがない。今，自分のやっているプロセス

で，とういうとと言うと，色々言う方がいて「いや，を，自分の所で作っているプロダクトが良い物出来るNTT なんか作り方も言うよ」

ように改善してけば良いんですよ。そう思いません

とか言うわけです。

rxx というドキュメントの標準を使って， yy とかやか?。だって，例えば，トヨタは，非常にきっちりと精りなさい」などと，作り方まで指示すると。でもそ密なプロセスを作り上げています。ととろが，あのトれは，プロがプロに対して仕事を出す時'に「とうやっヨタの人達が，てやれば多分うまくいくだろう」という慨然性の高

セスは如何にあるべきか ?J というのを語ったととは

いととを知っているからそういう指示をするわけで1 回も無いわけですよ。彼らが語っているのは，例えあって，それでやって欲しいというのは，要するにメぽ車だったら，とういう問題があると。それをちゃん

ンテナンスのとと考えてるからだけです。だから，要と作り込むためには，どないしたら良いの?というとはどんなプロセスで物を作っても構わなくって，成果とを，ず~っとやってきてるわけですよね。で，それ物が，お客さんの要求をちゃんとあるいはそとそと満がきれいになってくると，もしかすると参考になるか

たして，お客さんにハッピーなものが届いて。また後もしれない?，他の人遥にとって。そのプロセス自身

日「直してね」っと言ったらすぐ直っている/直すよ

10 銀の弾丸

SoftwareSymposium'
9
4

‑40‑

r一般的な乗り物を作るため工業プロ

北海道，函館

SeamailVol.9 No.6‑
7

クロージング・パネル

を JIS 化するという動きはあ っ て ， 秋 ぐ らいには JISが 。 だけども，彼らは 1 回もメタ の ，工業製品を作る

とか，乗り物を作るとか鉄を曲げて何か物を作るとかになると思います。 で も ，ととにいら っ しゃる皆さんというメタなプロセスのイ ンフ.ル ー プ メントをや っは ， はっきり言って認証なんか受けなくても，商売殆たっていうととは 1 回も無 い はずです。 だから，とのど困らないですよね? 。一部のメカトロ屋さんとか別中でメタの話をしたがる性向の 人 が多 い で す けれどにすると，所詮ドメスティ ッ クな中 で 商売して い るわも，アカデミアの人もいるのかなあ 7 3 そういう人で 。

けですから 。 IS09000-3 の認証をとるというととで，止めた方が良いと僕は思います 。 あまり望 み がな い

それで例えば社内の品質 シ ステムを良くするというですから。その，極端な話を言うと，何でも良いんで為に使うんなら，引JK 構わな い と思 い ますけれども，すよね。

認証をとるととだけが目的ならば，止めた方が良いと
思います。

7
.

IS09000-3 と第 3 者認証について

8.

まず， IS09000-3 について言うと，あれは物を作る

これからどういうアプロ ー チをすれば…?

それじゃあ，とれからどうしたら良いのか?と 。 まプロセスについて一言も触れている積もりは無い 。 だから，あれでプロセスマネージメ ン ト云々の話題にのず，皆さんは，今，ともかく何か作り方を知っていまぼってくるのはおかしいんじゃないか 。 あれはあく

すよね，物を作る時に 。 その作り方をまず，きちんと，まで， Qua1itySystem の element を書いたに過ぎな

紙に書かなくとも良いけれど，少なくともメ ン バ内い。だから，どういうふうに物を作れ，というととにでは伝わるような形にはした方が良い。で，その通り

ついては触れてない。だから，作る時に，品質を気にやって，仕事がうまく行かなかった時には，その仕事するならとういうととやっといた方が良いよ，といの仕方のどとに問題があるかフィードパックをかけう ζ とを言っている。それで果たしてプロセスってなければいけない。で，それがドキュメント化されて定義できるんでしょうか?。で，それとは違う所で，プいるというのは，必ずしも本質じゃあないような気がロセスって定義出来るような気がします。だから，単するんですけれども，ともかく皆がどうなっていると純に物作りのプロセスとして IS09000-3 を持ち出いうのがわかってるシステムがあって，仕組みがあっ

すのはちょっとおかしいと思っています。で，なんだて，そしてそれに基づいて作って，問題があったらそかの物を作るプロセスの中で，í 品質を気にする」との作り方に改良のフィードバックをかける。とれが，いう状況が生じた時に， IS09000・ 3 というのは役に立多分物を作る時に，今良い物が出来ないけれど今後

つかなあ?という程度ですね。

良い物を作るという時の常道ではないかと思います。

それから，第 3 者認証について言うと，品質システ

咋日，何かの時に，要するに優秀なエンジニアを集めムがどうなっているかによって取引の条件になる/

れば良い物が出来るという話がありましたけれども，しうるというととは，とれは避けようが無いと，思っておっしゃる通りです。優秀なエンジニアを集めれば，います。それは，何故第 3 者認証みたいな話が出てまあ多分良い物が出来るという慨然性は高くなる。けきたかという背景には，やはりヨーロッパ経済統合のれども，残念ながら優秀なエンジニアだけを集めて物話があって，他の新しい人達が商売に参入する時 K ，作れるほど，世の中悠長じゃないですよね。だから，その Quality どうやって担保すれば良いのか?という優秀なエンジニアだけを集めれば良い物が作れるとととを考えた末 K ，あれを持ち出してきている訳です

いうのは当り前だけれども，優秀なエンジニアだけ集よね。そうすると，今までの経験ではなくて「今，とめて仕事出来ないという前提があるんだから，要する

ういう作り方しているから良い物を作れるに違いなに九人使って良い物，あるいはあんまり大けがしないいから入札に入れてよ」というととを担保出来なく物を作るには，どないすればいいんだ?ってととを考てはいけない。だから， f乍った物ではなくて， f'乍るプえるのが当たり前であって，今でも「やっぽり優秀な

ロセスのようなもので取引に応じるか応じないかをエンジニアを集めれば良いね」なんて夢を語ってい決めるという，という仕組みは多分無くせない。そるんではとても駄目ですね。で，九人でも，と ζ にい

れが IS09000-3 とか 9000 シ P ーズに基づくかどうらっしゃる方の何割かはすごく優秀な人がいて，で，かは別ですけれども。そういうシステムは，人聞が 1

やや優秀な人がいて，ちょっと普通の人かな位の人が回そういうシステムがあるというととを覚えてしま

何人かいるんだろうと思うんですけれどもね。とんいましたから，多分消せませんし，とれからも消えて

なととろへ，わざわざ来るくらいですから。で，そう無くならないと思います。

いう人達だけをメ ン バにして物作る時にどうやってで，ソフトウェアの認証については，今日 09000・ 3

1
5‑1
7June1994

作るんですか?。で，その為には，やっぽり身の振る舞‑4
1‑

Addendumt
otheProceedingsofSS94

SeamailVol.9 No.6・ 7

クロージング・パネル

い方というのをきちんと決めて，その握る 舞 い 方を 直見ますと ， プロセスあるいは 1809000 等に関して，私すという形でな い と良い物は作れない 。 だ から ， と とが一番感じているととは， プ ロセスの標準化というのにいら っ し ゃ る方が，すご く 優秀な人たちばっかりだは非常に難しい 。 特に，下手な適用の仕方をすると，と，実は僕の言 っ ているととは ， 殆ど届いてくれない

現場から反発を食らうだけ，という感じがするととがような気がしているんですけれども 。 だから「何をあります 。 それは，今議論されている規格の個々の言 っ ているんだ」と思うような人は致し方無いと思点について何が悪いというととではなくて，むしろ，いますが，私はそう思う。

ソフト ウ ェ ア というものをひとかたまりで扱おうとで，やはりプロセスというのは自分のと と ろで ， 自するととが無理で ， も っ と細分化しなければうま く ゆ

分の所で作っている プ ロダクトに合 っ た プ ロセ ス がかないのではなかろうかと思うわけです。例えば，久あって，それをぐるぐる改良してゆく 。 それは自分保さんが例として示された 08 を作るようなソフト

達がどう失敗したかと い うのを分析して，きち ん とウェアの作業と，それから比べてずっと小規模のアプ

フィードパ ッ クするととである 。 で ， 実際に失敗のリケーショ ン ・システムを作るととを，無理に同じレ

フィードパ ッ クが全然されて無いように，私は思 い ま

ベ ルて・議論をしてしまう可能性・危険性があるのです。 どの会社に行っても，バグ情報を山のように取つはなかろうかと考えているんですけれども。

でありますけれども，あれを 2 度と見ないですよね 。

司会久保さん，どうでし ょ う。

以前，ある会社の開発部門に行って í1 人 1000 件持っ

久保てますよ」とか「見たきゃ，どうぞ」とか言われてびっね?。色んなソフトの種類というか，パッケージか，カ

くりしたととがありますが，まあ，との手の話は，幾スタムかと い うのもありますし，それからドメイン

らでも聞くわけです。 で，大きい会社では，もう電子も違うし，さらにプラ ッ トフォームも違う。だけど的な帳票にして貯めているし，小さい会社でも，とも1809000 は 1 つですね。それは，色々と違っていてかく紙に書くなり電子的なメモ書き程度にはどもかも人がチームを作って作業をするというのは同じ。

く残っているわけですね。それは，やっぽりオープン

仕事をするためには，何かしら計画というのを作る。

なパグをきちんと修正したというととをトレースし計画の中には，達成したいゴールがある。ゴールは品とういうふうに考えるととは出来ないですか

なくちゃいけないから，普通は残っているわけです。

質というので表現する。それで，作ったらぽトラッキ

でもオープンパグをフィックスした瞬間 K ，そんな情ングしていって，達成を確かめて，納めると。と ζ い

報は誰も見なくなるわけですよ。一体何が悪かった

らは，同じに出来るんじゃないの?，という提案じゃあのか?。技術的な問題なのか，プロセスの問題なのか，なかろうかと思うんですけど。それではなかなか納それともたまたま前の日，麻雀してて徹夜しててね，

得しないですか?

頭がクラクラしてただけなのか?。そういう分析を全平野要するに，そとで止めれば良いんじゃないかとくやらないままに。要するに過去の反省が一切され思うんですけれど。気がつくと，もっと前へ前へと進ていないなまに，漫然と仕事が続けられている。そんまされるのが人間の常でありまして。

な状況なのに，誰かが「とんなプロセスどお ?J って坂本自部門に合わないと思えぽ，止めればいいと思

言うと，パァーと行っちゃう 。 ζ んな愚かな，それとうんですよ。で，自部門に役に立つと思うととろを，そレミングのようなやり方は止めて欲しいと思いま

利用すれば良いんで。実は，私の会社の中でも，ハンす。そろそろ時間だと思いますんで，野次って終わり

フリーさんの書かれたものは，非常に利用させてもらにしたいと思います。どうも失礼しました。

いました。例えばこんなふうにです。「ソフトウェア

司会

どうもありがとうございました。以上で，パネは何故いつも失敗ぽっかりしてる ?J と経営トップ層

リストからの提言を終わります。とれからフロアのがいろいろと言う。それに対してハンフ P ーさんの皆さんに識輪なりコメントなり，思うととろを語っ本を持って行って「との本に書いてあるようにプロて頂きたいと思います。積極的に識論に参加して下セス成熟度の改善に取り組みましょう」と言っていさい。それではどうぞ。

ます。平野さんのご質問は，ソフトウェアのドメインによって標準化というのは役に立たないか?という

9. ソフトウェアの対象を考慮しなくて良いのか?

ととだったと思うんですが，先ほどハンフリーさんの平野(中央システム)

私は，社員 200 名ほどのソフ本を利用させて頂いた時に，経営トップの方から「あトノ、ウスで，十数年仕事をしていまして，咋今，研究の本に書いてあるのは，要するにホスト系で，我々の開発部門に移ったわけなんです。で，ドロドロの泥沼やっている組み込みソフトには関係無いんじゃないを這いずりまわるような開発をやっていた人聞から

SoftwareSymposium'
9
4

‑42‑

北海道，函館

SeamailVol.9 No.6‑1

クローヅング・パネル

か ?J というのがまず最初にありました。で，それにけれども違うものもあります。で，それはやはり個々

対する回答として「いや，ととで言っているのは経の場所で，そとの設備のそのやり方でないと，うまく営者が決心して経営資源を投入しきちっとプロセスゆかない。て\例えば，釜石というのは線材という針改善を実行するととが唯一の道だと言っているわけ

金の材料を作っているととろなんですけれど，だんだ

で，それは組み込みソフトだろうが，ホスト系だろう

ん製造を縮小する方向にあって，で，スチ ー ルコードが関係ないです」と言っています。要するに世間でというタイヤのラジアルタイヤに使うコ ー ドを，別の議論されているととや，標準化の動きについてその通製鉄所の方が製造するととにして，その移転をやってりにする必要は全く無く，自分で判断して“いいとといる時 K ，私は丁度入社したんですね。で，そとの部

取り"をすれば良いと思います。

門の話を聞くと，どうしてもうまく作れない，と。だ

桑名私も，別々であって良いんじゃないかと思ってから，そういうものであって，標準書をいくら移転しいますし，過去に自分もそうしてきました。だけど，でも駄目な世界もあるし，で，そうは言っても，そ ζ

スタートホ.イントとして核になるものはあったんでの場所での標準というのは必ず存在していて，これをすが，それはどんどん年月が経つ ζ とによって，時々やると逆に誰が来ても，つまり転勤者が来ても，そのに他から色々なものを吸収して変わっているんで通りやれば何故かうまく仕事が進むというような世すよね。だから，吸収したなりにカスタマイズして界があるわけですね。

revision が出来ています。「とれは使えるかなあ」とで，言いたいととは何かと言うと，別に我社でも，思ってやってみて，うまくいかなければまた直せば本社がとういうような作業標準あるいは製造標準で良い，と思っています。

物を作れって言っている訳ではありません。それなら

兼子先程，久保さんが言われた，うんと generic な意

ば，それはソフトでも多分同じであって，極端な話を味で，例えば，設計してコード書いてテストして云々

すれば，プロジェクト毎に多分違うやり方があって，という generic な意味では，多分有り得ると思うんでそのやり方でうまくゆく，というような場合も多い

すけれども。でも，ある特定の何かの物に，良い物をんじゃないかと思いますね。そうすると，じゃあ，標作ろう!と作り込んだ時には，その物を実現するため

準というのは何のためにあるのかと言うと，素人のに必要な技術的な何かによって，プロセスが決まる

プロジェクトマネ ー ジャーが，取りあえず何とかフ.ロ

部分はあるはずで，そとからさらに本当に日々の仕事

ジェクトをやるためにあるんじゃないかと，私個人はに役に立つようにプロセスを書とうとすると，ゃっぽ思ってます。と言うのは，私が入社して 1 年半位してり，ターゲットですとかそういう物を分けざるを得なから，工場の自動化のあるプロジェクトに行って，いいと思います。また，そういうふうにすべきだと私もきなりプロジ ェ クトマネージャ ー をやらされたんで言ったつもりです。

す。で，ソフトを作ったとともないし，そもそも何か

司会良いですかね?では，次の方。

スケジューノレを引けと，ポスに言われでも，そもそも一番初めに分析をやって設計をしてコ ー ディングし10.

標準は何のためにあるのか?

野口(新日本製識)てというプロセスを全く知らなかったんです。で，取私は，実は初めは鉄の製造の世り敢えず，昔のプロジェクトをやったものとかあるい

界にいたんです。で，そとからソフトに来ているもは，標準書らしきものを見ると，何かそういうととがんですから，何かとう，今更プロセスだ，標準化だと書いてあるんで，なんか見積りのやり方も書いてある言われでも，どうもなんか変な感じだなあというふう

んで，取り敢えずそれに沿って見積りをやって，そしに思うわけです。例えば，兼子先生が言われた「一てそうしたら，システムが 1 年後には出来上 がってい般的なプロセスなんて言っても意味が無い。 ~J えば，たと・・・。まあ，とういうような経験がありまして，

トヨタが自動車の作り方のプロセスとかを持っていで，何で出来たか良〈判らないけど\とにかくその通るけれど，あれを一般化するようなものを持っているりゃったらうまく行ったと。で，それはまあ typical

わけでは無い」という話をされていましたけれど，確な例じゃないのかもしれませんけれど，しかしまあ，

かにハードウェアの世界ではその通りです。例えぽそういうのが標準であって，そのあと何回か，まあそ

我社の場合， 10 の製鉄所があって，その中で同じよ

ういうプロジェクトを積み重ねてゆけば，そとから今

うなプロダクトをイ乍っている製鉄所というのは幾つ

度は工夫をして，自分が段々そとから逸脱してゆくともあるのですけれども，それぞれの製鉄所がそれぞれいう世界もあるんじゃないかなあ，というふうに思うの製造の標準を持っています。そして，それぞれの現わけです。だとすると，[""標準というのは， 一体何の場の作業標準を見てみると，同じようなととろもある

15‑11June1994‑43‑

AddendumtotheProceedingsofSS94

S
e
a
m
a
i
lVol
.9 N
o.6
‑
7

クロージング・パネル

ために作って，そしてそれを認証するというのは，一いのと。要する に ，なんとかのなんとかプ ロジェ クト

体何のためにあるのか ?J 。

チームで OS を作るのは，通信管理作るのは，例えば

どうも何か今 ひ とつよ く

分からないなあ，というのがコメ ン 卜 です。

Windows のライブラリを作る のには， どういうプロ

で，兼子先生から「ソフトウェア屋さんはプロセス

セスでやったら良いんですかという議論が 100 個もについて議論するのが異様に好きだと 。 で，外の人が200 個も集まってくると，なんとなくソフトってとん

自分達 のプロセスがどういうふうになっているかな

なふうに作ってくのかなってゅうのが出てくりや良んて，へんちくりんな話だ」とおっしゃいましたが，いんであって，いき なりメ タの話から始めたっ てね ，実は，鉄の世界でもあるんですよね 。“パ イプ"と い

抽象的なアジテーション以外の何物でもなくて，実のうのは，あれは，外から検査官が来て，どういうふう

あるようなプ ロセスがそとか ら出 て くる ようには思に作っているかを検査するんです。だから，ああ い う

えないというととを言っただけです 。

ような鉄みたいな，汎用品みた いな世界でもそういう壊本先ほどの兼子先生の話，私としては異論がありのはあるんで，別にソフトウェア屋さんだけが好きなます。それは，先生がポジションペーパに書かれていんじゃないでしょうけれど，多分ソフトウェアの場合

る内容についても，現実には必ずしもそうなっていな

は，どうも，なんか ，外から見るとブラックボックスでいんじゃないか というととで ，ちょっと気に なってい何だか良 く分から ないから，とに かく製造プ ロセ スまるととろがあるんです。

で，良 く 見ておかないと不安な感じにかられる んじゃ

例えば具体的に言うと， ISO を受診しようと思った

ないか，というふうに思います 。

ら，最低 6 ヶ月間(多分本当はもっと期聞が要ると

兼子

今のととに関しては，それはやっぽりプロセ思うんですが)データを貯めな い と駄目なんですね。

スとマテリアルというカテゴリというのは，ハードで，例えば，メ ッ キのプロセスが妥当かどうかという

ウェアにあって，破捜検査をしな い 限り，中の，例えのは，パッとやってみればそれで分かるわけですよ 。

ぽ， Quality が分からないというものに関しては ， 当ととろが，ソフトウェアを評価するためにはそうはい

然，作り方を見るわけですよね 。今のパイプ もそうでかないわけです。だったら，プロダクトで検査したっ

すし，メ ッ キなんというのも，実は表面検査しでも，中てた い して違わないんじゃないかと思うんです。

のあれとか分からない 。 あれはきれいな所で，ちゃ ん

司会司会が意見を言うのもなんですけれども，今，とやっていますか?

というのを見るという，確かに兼子さんが言われた，メタなプロセスの議論で，とれプロセスとマテリアル。プロセスを見るととによ っはちょっとポイントをそろそろ変えた方が良いんじゃて，というのはあるというととはあります。で，ちょ っないかと思 ってい るんです。それは，どういうととかと，もしかすると僕の言ったととが誤解されてたのかと言いますと，その個々の物作りのプロセスが違うとも知れないんですけれども，僕はその，ソフトウェア

いうのは当然で，それに対して最適化してゆくといで，プロセスを見るということは，やらざるを得ない

うのは当然の話で，それが取りも直さず日本が今まというふうに思っているんですよ 。 というのは，標準でピジネスで成功してきた理由だと思うんです。と品を売るのではなくて新しく契約して作りましょう，とろが，それで良いかと言うと僕は，もう 一歩進まなと言ったときに，そとの実力を評価する，で，商売のいといけないんじゃないかと。何故，メタな議論をす

入札の条件に入れる，といった時に，

I 今までとんなるかと言うと，例えぽ，僕が臼本の品質管理に対してこと作ってきましたよ」というととは，実は機会平

disappointing なところがあると思っているのは，世等の原則に反しているわけです。だから，今，こうい界に対して「とういうようなプロセスで，品質管理

う物を作り得る，プロバピリティー，パシピリティー

をすれば良いですよ」というような，非常にクリアーがあるよ，というととだけで，商売に参入するととをカットな議論がされていなかったと。そういう意味

認めざるを得ない，というシチュエーションに今なっで，メタな議論をするというととは，知識を日本の中ていて，で，そのシチュエーションで相手を評価するに閉じさせてないで，外に持って行くという ζ とに関時に，今，アイディアとして持っているのはプロセス

しては，非常に重要な役割をする。そうしないと，通を見るというととだけだから，そのプロセスで評価じない話がある。そういう意味で，僕は重要だと思いせざるを得ないというととは，多分無くならないだろます。で，とれは，知識を貯めるとか，伝達するという。で ， 僕が言っていたのは，

I ソフトウェア屋さん

う意味で，そして科学という意味で重要だというととが，すく\メタの話をしたがっちゃうのが異様だなあ」

です。

と。要するに，そんなメタな話をしなくていいじゃな

久保

S
o
f
t
w
a
r
eSymposium'
g
4

‑4
4‑

じゃあ，僕にもちょっと喋らせて。

北海道，函館

SeamailVol.9 No.6‑7

クロージング・パネル

司会どうぞ 。

の品質管理って何か，というととを説明した方が良

久保

やっぱり兼子さんにちょっと教えてあげなきゃいんじゃないか と いうととで，私の方から提案さしていけないからなあ~。多分，言葉使いの問題かなぁと頂いて，飯塚先生にも快くお引き受け頂いて，いくつ思うんですけれども，やっぽり 180 にしたって CMM

かのととろで喋っていただいたんです。で，非常に良にしたってメタだか ら利用 価値があるんですよね 。 そいパ ッ ケージが出来ているんですけれども，それは実

れから 3 兼子さんたちがや っている 品質管理だと横はですね~，彼が一生懸命，土日も休まず作ったとい展開，水平展開という 。あれもメタになるから伝わるう… 。 非常に良いパッケージがありますんで，再利のだろうと思います 。 それから，僕らが知らぬうちに用して頂ければと思います。次は君島さんですね。

使っている道具がありますけれども，品質保証体系図
だとか。あれだって，ょうは，どつか の工場で発明され11.

工程の捉え方についてたものが汎用品 K なってい ったという。だから，まあ，

君島(富士通)まだ統計的品質管理やってるほうが，そういうふうにメタにな っていってる というか 。それ

よっぽどメタだと思うんですけどね。僕が言っていとまあ，ととまでは意見でしかないですけれどもね 。

る，個別品質管理 [6J さえゃりゃあ良いんですから。

ちょっと，効き目あるのは，彼は久米先生というと ζ

もう，品質管理の研究なんてやめちまえば良い。

ろの助手ですよね。て\久米先生から聞いたんですけ

それはともかく，ちょっとメタな話をいたします。

れども，溜外から日本の QC を見学 K 来たいと いうで，今，標準工程と個別工程は相矛盾するような捉えんで，おみえになる 。 そ ζ で，まあ企業は受け入れる方しているというのが，そもそもおかしくて，もう一んですけれども，そとで来た人は勉強して帰りた い。

回プロジェクト管理の勉強をした方が良いと思うん

それから迎える方も ， 何か勉強材料を用意するのですですけれども，工程というのは固定の標準を守るとけれども，その時にや っ ぽり材料を提供出来ないんだ

いうのが間違いなんですね。まず Work B
reak‑down

そうですね。何があるかというと， QC サークルのと

8tructure という，あの 8LCP みたいなものがあって，としか出ない，極端なととを言うと。経営はどうや っ

あれは順序はまったく規定していません。あの中からているか?というと，成功しているはずなのに，それ選ぴなさいと。で，選ぶ時 K ，白紙の状態からやるとを伝えられないというととをもどかしがっていた，と大変ですから，雛型工程というのがあります。とれはいうの話があります。

ウォータフォーノレとかス ノ〈イラノレとか，あるいは，そ司会当然のととながら，兼子さん，反論があると思のアプリケーションドメイン毎の過去の事例でも良うので・・・。

いですけれども，それはパラパラで良いわけですね。

兼子メタな議論をするなとか，今おっしゃっていた

それの適当な近いのを見ながら，納期とか新規性とかみたいな意味で，メタな議論に意味が無いというふを考えて，工程計画というのを立てるわけですよね。

うに言ったつもりは無い。やれば良いんです。だけ

標準工程を守るんじゃないんですよ。プロジェクト

ど，今のソフトウェア屋さんのレペルというのはメタ

毎 K 決めるんですよ，リーダが。最も納期が短くなるの話をする前に specifìc な話をするのが先じゃあない

ように。という，の?，と言っているだけですから，それは勘違いしない型工程」そして「工程デザイン」という 3 つのファで頂きたいと思います。だから何人かの，そとら辺にクタがあると。標準工程を守るなんでいうのは，全く座ってらっしゃるウンと頭の良Ir>，どっちかと言うと初歩的な理解ですね。それから，昨日言いましたけれrWor
kbreak‑downs
t
r
u
c
t
u
r
e
Jr雛

浮世離れした人は，メタな話をすれば良いんですよ。

ど，プロセスというのは完全に決めるのじゃなくて，で，そういうととをしなくちゃいけない，するととがオペレーションしながら細かいととろはスケジュー

大事だというのはわかるけれど，誰かが先，三歩ぐら

リ ング してゆくと。そんなの誰か休むかもしれない

い，ふわふわ浮かびながら先を歩いている必要はあっのに工程期間をピシ ッと決めるわけじゃあない。そうて，そういう人達がいなくちゃ困るんだけれども，皆いうスケジューリングという概念もみんな知ら念いがずるずるとそれにヲ|っ張られる ζ とは無い，と思いと。とれは無理もないととで，通産省のプロジェクトます。

リーダーの標準カリキュラムを見て頂くと分かりま

司会兼子さんの名誉のために言っておきますけれ

すけれど，そんなとと一切書いてないですね。非常にども，昨年，私と飯塚先生とか何人かで世界一周した

レベノレが低いです。まあ，あと，レ ベルが低い例で言んですけれども，その時，日本から是非前から色々うと，その通産省のカリキュラムは品質管理のととろ

聞かれていますので，日本の品質管理，ソフトウェア

を，兼子先生なんかはやってるかもしれないが，統計的品質管理ぽっかりやっている 。個 別品質管理を全15‑17June1994‑45‑Addendumt
otheProceedingsof8894

SeamailVol.9 No.6‑
7

クロージング・パネル

然載せて い ない。それから，テスト技術の所に，テスに なっ て 動け るの は 2 年生しか い ない 」 という返事。

ト項目設計基準書に従えと い う乙とが一言も書 い て

他 は 主任と課長がポロ ポ ロといるとい う。 まあ，昔のあ り ません 。 まあ，そういう意味で我々のこの学会の空洞化なんて言 っ て い ましたけれ ど も，そのころの部

レベルがまだ，そとのレベルにしかい っ ていないと 。

隊で ， あとは協力会社の 人 が一杯 い ると い う 。「 まあ ，成熟度が 1 くらいしかないと 。 だから，僕は，標準工と う いう ふ うにしたら」という幾っか ア ド バ イスを程という概念と個別工程という概念は全 く 矛盾しなしてやりましたら，途中色々と私もフォローしました

いと思います。

けれども， パッ チリ成功して 。 で， 書 け 書 けと一生懸

司会ありますか? 。 はい 。

命 も のを 書 かせた ん だけ れ ども全然社内 へ広がらな

坂本

さすが君島さんで，まったく私も同意見です。

い。 オムロ ン さ ん も ，今， 一生懸命頑張 っ てら っ しゃ

社内に，標準工程があっても，それがそのまま現場にい ま すけれども，これを全事業部にや っ たら大変な パ

活用出来ていない，というととなんですけれども，そ

ワーがかかるだろ う。 Ø1J え ば，とういう ソ フトウェア

れは，今，君島さんが言われたように，社内の標準工

シン ポジ ウ ムのような場で成功事例を発表するとと程と，現場で使う個別の WBS を落とし込んでやるは，それはそれで意義 が あ ります 。 が， そ うするととというのは違うんで，そとの聞のギャップを埋めるとと 社 内から注目をされ，広ま っ て，自分 の ととろの全いう作業を，我々としてしていなかったという反省が体レペルの向上に結びつ く というとと は まず無いとあったということです。で，ちなみに，我々の部門で思うわけです。 そういう意味で，サクセスストーリは使 っ てる標準は， パ イプファイル 1 冊ほどの分量 があ

本当に企業内で ， 一事業部を成功させて全部に広げる

るんですけれど，とれは 6-7 年前に私が中心になっにはどうしたら良いだろうか?というととあたりをて作ったんですが ， 私の部下には「あれを現場では無おイ司 い したいなぁと 。

視しなさい」と言っています。 勿論それにはちょっと

桑名先ほどのサクセスストーリの話ですが，詳細は前振りがあって，良く勉強して無視しなさい，ととうNTT ソフトウェア研究所の長野が書いています [4] 。

言っています。その通りにはいかないでしょう，と。

それはどういうプロジェクトかと言いますと，交換機現場でうまく使うことが大事だというととを言ってソフトの開発環境を構築したり，交換機のソフトウェます。

ア自身を改良するというもので，もう 4-5 年前から

司会他にありますか?。良いですね。じゃあ，次，堀

スタートしていました。サクセススト -9 ーが広ま

江さん，どおぞ。

るか広まらないか?というととに関してですが。「何故うまく広まっていったか ?J という質問に対して

1
2. .fナクセスストーリが広まらないが…

は，ト ッ プダウン管理の問題に帰着すると考えていま堀江(日本電気ソフトウェア)

私も DIPS だったんす。 各プロジェクトの上にいるマネージャがどういうで，桑名さんに伺いたいのですが。サクセススト -9

アクショ ン を起 ζ すかだと思うんです。 交換機ソフを作れという話についてなんですが，先ほどのメタのトの開発環境やソフトウェア開発自身のプロジェク

話とも若干関係するかもしれませんけれども。私がトの例で言いますと，数千人という開発者を持つ組織

DIPS 関連の仕事を終わったあとで，小さな 7-8 人の長が ， 組織の中で成功したとと(スモールスタートで 1 年弱くらいのプロジェクトを頼まれました。で，でやって成功したとと)に非常に理解を示して下さっ

とれが凄いもので製品を P リースしたら 1 件もパグて「じゃあ，みんなでとれやろう」という大号令が上が出ない。

9 9 ースどとろか， 8 ヶ月目ぐらいから全からかか っ ちゃう 。 意志の流通をするだとか，ドキュ体を集めて各種のテストをしましたけれど，全然バグ

メントや情報の共有とかというのをそのサクセススが出ない。皆メシ バ が，遊んでいるという状態で，非トーりで用いた方式に習ってやっちゃうんですね。

常にラッキーなプロジェクトだったんですが， ζ れも

それまで，他の部署の人達は良いサクセススト -9

確かにいろんな標準を作ってやってたわけですけれがあるととをみんな知らな。しかし-ß.それを知っども，と・れがどこにも広まらなかったという一例があたら「じゃあこれ真似ょう」というので。しかもマります。

ネージャクラスが，その上から 「 とれをやって成功しまた，とれはつい最近当社での十数億のプロジェクトたから」という話を聞いていますので，それに刺激さの事例ですが ， 指揮されたのは，純粋のピジネス系のれて ， みんなでやっちゃうわけです。素直ですから。

アプリケーションの方で，初めて 50-60 人を使ってそとがうまくいく点なんじゃないかと思います。要

やらなければいけない。「どうしたら良いだろうか ?Jするに，言いたかったのは『ト ッ プの意識の問題。理と相談がきまして「メンパーは ?J と聞いたら「主力SoftwareSymposium'
9
4

‑46‑

北海道，画館

. 9 No. ふ 78eamailVol

クロージング・パネル

解のあるマネージャが，如何にそのサクセスストーリ

いっちゃったという 。プ ロセスをどう持ってゆくのか 3を取り入れて，社内に広めるかっていう意思決定の問最終的 K は桑名さんの言われた

題』かと思います。

と意識してそとから引き上げてゆく」という改善を

í ト ッ プがちゃん

あと，とれは最近のグループウェアなんかにしても，してゆくようなととをしないと，プロセスを広めると

実は，まさにそれがあてはまると思っています。一例

いうのはちょっときついのかなあ，という感じがしてを挙げますと“ロータスノーツ"という製品がありまいます。

す。会場の方で，お使いになられている会社の方，い桑名

ツールに関してなんですけれども「ツ ールはらっしゃいますか?。え~と，ちょっとおききしたいん

広まるけれども」という話があったんですけれども，ですけれど\全社でお使いになられていますか?

僕は，ツールの中 K 実はアイディアが隠れていると考

会場はいえています。

桑名そうですね。

ロー タスノ ー ツを伊IJ f'C 説明しますと，実はツ ールがた

実は，組織にいかに浸透させるかというととでは，とだ出来たわけではなくて，あれだけのツールが出来たれと同じように，とれも 4~5 年前からグループウェととろには，もう十数年前からグループのデータシェ

アの世界で「何故グループウェアがうまくいかない

アリングに関する研究成果が反映されているわけなのだろう?。今だに電子メイルばかりじゃないか」とんですね。

いう議論があります。で，色々分析していってわかっで，今もメタな議論が出ましたけれど"メタなてきたのは，その管理の問題であるというととです。

議論"とはどういうととか，というととを言わさ

良いものは，とにかく，トップが判断して全社的にいせて下さい。それは，もともと最初色々なケ ース

れなきゃならないと。そうするととによって，それをがあります。そのケースに対して次の段階と してみんなが使うととによって，ドキュメントシェアリン

オプザペーションという形がある。そのオプザペー

グも進むし，さらに新しいツールが入ってきて，それションで，何が 同じな んだろうと考えて，その次に，によってプロセス/作業工程が改善されてゆくという

実はそれをさらに抽象化するアブストラクションと話になると思います。そういう点からも，まさにとれいう段階があって，さらにそれが上 K 上に進むにしたからツールを導入するととに関しては，トップの判断がって，例えば理論が出来たり，科学が出来たり，法律が非常に重要になってくると思います。

が出来たりする。とういった一連の，何か世の中不堀江私も，全く同意見です。私が反省してみると，上変の考え方というのがあると思っています。で，そうにもう少しアピールする努力が足りなかったかなあ，

いう抽象化されたレベノレの上がった考え方というのと思っています。トップから落としていかないとやっが，実はツ ールの中に埋め込まれて いるのではない

ぱり広がっていかない。

か。また，そういうツールを使っていかなければいけ

ただ，ツール類は比較的簡単に広まってゆくけれ

ない，と華ムは思っています。

ど，本当にプロセスといったととが本当に広がって坂本我社ではそんなに格好良く発表している以外

ゆくか?っていうのは，ちょっと見えない所がありまの，非常に泥臭い話があって，そんなにうまく行ってすね。

いるわけでは決しでありません。で，我々は，特にホとれは，某社の 08 なんか作っている事業部，そとは

スト系の先進的な会社の方の後を一生懸命追いかけ

もう I80 を取りましたけれども，そとはパッチリとている，という認識をしているんです。で，その追いした管理標準を作って使っています 。で， 他の事業部かける中でですね，何をどういうととで心掛けているも「是非欲しい」という。そとから，どちらかというかと言うム要するに，知識の移転，技術の移転なんとアプリケーションを作っている事業部が持って行ですね。技術の移転というのは，何なのかというとときましたけれど，ととは全然死んじゃったという。とを考えて，それを如何に効率良くやるかっていうととれは，やはり 08 を作っている部隊とアプリケーショ

だと思うんですよ。で，技術の移転というのは放ってンを作っている部隊の仕事の特性の違いを考慮しなおいても出来るわけじゃないんで，もし放っておいてかったととによるのかなぁと思っています。アプリ

出来るんなら，学校なんて，大学なんて成り立たない

ケーションの部隊は，個々に仕様を区切ってみんなんで，それは，それなりのパワーが要るんだというとバラバラでやっていますが， 08 は全員一 団となってとを皆認めていると思うんですね。で，それは社内で走って，ゴポっとくっつけますから。そういった特性あっても同じであって，社内でそういう技術の移転，を全然やはりトップが理解しないで，ポンと持って知識の移転をするのには，それはそれなりの経営資源

15‑17June1994‑47‑

AddendumtotheProceedingsof8894

SeamailVol.9 No.6・ 7

クロージング・パネルが必要だというととを経営ト ッ プの方にわかってもというものがやってきてですね，なんかやれという。

らうととが必要だと思っています。で，私が 上の方をで，勿論，それ自身は良いととかもしれないけれど，

説得しているのは，ソフトウェアがおかしくなるのは

それをやるととによ っ て，自分自身が日々，なんかと色々あるんだけれども，やらんとあかんととは 4 つあ

う進んで行く実感が，あるいはあなたは進んでいます

りますと言っ ています 。それは，よというような，要するに reward みたいなものがく

ると非常に良いんじゃないかと思います 。 で，昨日の(1) 標準プロセスモデルをきちんと教育すること

セッションでも会場からコメントがありましたが，一(2) 個別のプロジェクトの計画をきちっと立てられる ， それを立てる技術も身につけるとと度，一生懸命体系を整備しでも，何年かすると，段々
志気が下がっていって元の黙阿弥になって，もう 1 回(3) その状況を visual 化するためのメトリックス
をきちっと現場に落とすとと全部再構成し直すとい っ たととがあると思うんです。
けれども，それは継続的な reward のシステムが無い(4) 以上のようなととが，現場の人達，皆に分かるから，最初は要するに，生産性が向上するとと自体が，ように技術移転をしないと駄目なんですが，そ

つまり，何か，要するに，プロセスを整備すれば，生産のためには経営資源が要り ます

性が，一瞬でも向上したら品質は向上しますから，そと 。 で，とれは，本当はお恥ずかしい話なんですが，と の 1~2 年，初めて社内でそれだけを行う専属部隊

が持 てるようになりました 。という状況で，少しづつに reward がないですね 。 もし， product( 汎用製品)を作っている会社ならばまわり始めたかなあ~というのが現実です。
司会良いですか?

れ自身が reward になって，その瞬間はうまく行くんですけれども，それが当たり前になってしまうと，他

rproduct が良い J r社会的な評判が良い」というととで社会的な認知度が上がじゃあ，酒匂さん。

る。そして，そのととで個々の社員が reward を感じ

1
3.

るというととはあると思うんです。しかし，受託が中継続的な reward のシステムが必要では?

よその部署に，どう展開して行くかと心のソフトウェアハウスの場合なんかは，それを維い っ た話を考えてプロセスの話を聞いた時に，確かに持するのは難しいんじゃないかと思っています。と私も坂本さんがおっしゃったように，プロセスは標いうわけで『精神論 K 陥らないシステマティックな準的なガイドラインとして用いるのは構わないと思

rewarding システムはどうしたら良いでしょうか?~

います。て\それを如何に浸透させるかなんですけれというととに関してど意見をお聞かせ頂けると。

酒匂 (SRA)ども，私は日本の状況が具体的にどうなっているの司会久保さん，どうでしょう 。

0

久保あまり参考にならないとは思いますけれど。今，個 々人 に対するですね reward のシステムを考えて

私は富士通のシステム本部というと ζ ろにいますけも，もうそろそろ良いのじゃないかなぁと思います。

れども，で， 180 の認証を取得する動きだとか，それrewardI土現在は，個々人のやる気の問題とかにとから CMM のモデルをカスタマイズしているんです

どまっているようです。ですから「自己研鎖の度が足けれども。そういうものを出して，今，階段上がりな

りない」と言ってみたれまた，管理者が「お前らたさいとかいう，基本的に嫌がっているのをやらせていか分からないですけれども， systematic な rewardll

るんでるから」と判断すると関係者を集めて「みんるっていうね。で，その時 K ，やっぽり，なんちゅうん

な頑張ろ~!Jとかやっているわけですけれども，例

ですかねえ~， reward ではなくて脅迫かもわかんな

えば良く出来る人つてなにかというと，自分自身に如いんだけれど，要はね，要するに，認証って，もらわな

何に reward を出すか?というととを良く知っていいと商売からシャットアウトされるぞ，という脅迫。

る人だと私は思っているんですね。要するに，自分自ですから，そういう勲章，認証を欲しがるっていうの

身がとれをやるととによって，どういう見返りを得るを，なんとか作り出している 。 ですから，それなんかかというととを良く知っていて，で，それに対して自も reward K なっているんじゃないんですかね?。

分に対して，ある区切り区切りで「私はとれだけの ζ

司会それはネガティプな reward ですよ!

とを達成した」とかですね，もしくは，それ自身を維

酒匂例えば， 180 の認証を取るという目標がある聞持するとと K 喜びを感じているという。でも，まあ，は，それに進むとと自体が 1 つのドライピングフォー

人間だから，いつもそういうわけになかなかいかなくスになりますから良いんですけれども，もしそれだて ， 日々会社の中で仕事をしていて，例えばプロセスけだとすると，それをとっちゃったらどうなるんだろ

1
1r
e
w
a
r
d

報酬，見返りSoftwareSymposium'
94う?と疑問に思うわけです。最初は，脅迫で始めても‑48‑

北海道，函館

クロージング・パネル.9 No.6‑7
SeamailVol

良いと思うんですけれども，でも，企業は一過性に商とか「一緒に勉強会しょうか 」とかなるし ，月に 1 回売をやっているわけじゃありませんから，むしろ大きはゼミがあって研究の進行状況をチェックしてますけ

なドライピングフォースではなくて，日々のまあ，勿れど，基本的 K 手取り足 取りというのは一 切無くて，論，個々人によって何を楽しみ，もしくはやる気とテーマ丸投げしておしま いなんです。そうすると ，考えるかというのは，全然ちがう問題なんですけれど

受験勉強的なととをやってきた者は，いきなり途方にも，それにしても，何かを導入しようと思った時 K は，

暮れちゃう。で，そうでない人っていうのは，毎日来そういった，如何にそれを自に見える形で評価してやて「今日は，自分は ζ とだけやる」と言って。で，終るか?というととと表裏一対だと思うんです。

わったら「よ~し，酒呑みに行くぞ」とか言って帰っで，その表裏も，押しつけ的な評価じゃなくて「とて行く。だから，必ずしもシステマティックではなれをやる ζ とによって，確かに自分が何かをやり遂げいんだけれど，自分自身に対して達成可能な小さなていっている」といったものが必要になるんだと思ターゲッ トとい うのをきちんと作れて，それを継続的います。同じ様な例は，多分，ツーノレだとか環境にもに与え続けるととが出来れば，実は当てはまっていて，そもそも使う気にもならない環境と J rl 年かけないと」といった long lenge の前に，だと，大体，進化のしようも無いし，使う気にもなら短いミッションをやり終えたという reward って言うないツールも進歩しない。同じように ， 使う気にもなのは与えられるんじゃないかな 。で，それ を，組織とらないプロセスだと，そもそも標準化と決めておい

して与えるか，あるいはそういう仕事の仕方というのても，それ自身は，標準化を決めた段階が一番良くて，を身体で覚えてもらって，自分で self マネージメント

で段々と使えなくなって腐っていくというととになしてもらうのは?。多分，僕は self マネージメントのりますね。ですから，最初の段階で，ある程度使う気方がはるかに効率良いし，そっちの方が麗しいと思っになるようなシステムであって，なお且つ，人聞に対ているんですけれども。

しでもそれなりの配慮があれば，放っておいてもうま

酒匂私も全くそう考えていて，多分システマティッ

く行くんじゃないかと。とれは一種の理想論で，書生クと言ったので，組織としてどうやって，人を盛り立

r 半年かけないの書生論というような形になってきましたけれどもてるかとか，さらに管理的な側面で誤解されたかもし(笑)。で，私が「システマティックな reward システ

れませんけれども。私も，今おっしゃられたように，ム」と言ったのは，そういったような意味です。

個人が自分自身の細かい目標を日々設定してゆくの

久保システマティックな reward system と言っちゃが良いと思っています。けれど，じゃあそれに対し

えば， 1 つ，やっぽり日本の TQC というのは，それがて，ただ漫然と期待しているのかというととですよシステムになっているんじゃないですか? 。好き嫌いね。つまり，管理する側(というとまた誤解を招くかはあるかもしれませんが。結構，それ，うまくシステもしれませんが)がそれに対して，じゃあ何が出来ムにしたという例じゃないかなあ~。だから事例を探るか?もしくは，例えぽ自分の小さい目標設定をしすとすれば，僕は，まあ日本の中で，デミング賞なんたいと思ったり，色々な細かい試みをしたいと思ったかを受けていて，且つ，外に対してメッセ ージを発信

時に，それを受け入れられるだけの受け皿があって可しているようなととろは，結構そういうような面で，能になるのではないかと思うわけです。「じゃあ私はうまく上から下までやっているってゅうか…。とい

ちょっととれでやってみよう」とやった時に「確かにう例になると思いますけれども。システマティックとあなたとうやりましたね」という形で，小さなもので言われると，そんな感じかなあ，僕は。

も良いから何か認められるようなものが， (今具体的兼子大学で学生を見てると，自分でどんどんやる奴

なやり方は思いつきませんけれども)あれば良いなぁと， ζ の間学校に来たの何時だっけ?みたいな奴にと，思いました。

分れるんですね。そして「良くやっているね」というで， TQC のととを久保さんがおっしゃって。私も奴を良く観てみると，その日にやるべき事というの

TQC のイメージは持っていましたけれど，あの場合，を自分で決めて学校に来ているんですよ。で，うちのあれは TQC の結果作られた製品が社会的な貢献をす

研究室では， 4 年生が配属されると，初めの 2 週間ぐるというようなととが，で，しかも個 々の職場 の中でらいはインストラクションをしますけれども，それがお互い高め合うような運動があったと思うんですね。

済むと研究テーマを列べて「好きなの持ってけ」とと，すると，逆に私は問いたいのですけれども，今と言って，後は卒論まで何も指導しないんです。勿論，とで話題になっているソフトウェアプロセスを TQC

学生が何か勉強したいって言ったらでやれば良くなるんでしょうか?

15‑11June1994「 ζ の本読め」‑49‑

AddendumtotheProceedingsof8894

S
e
a
r
n
a
i
lVol
.9 No.6‑7

クロージング・パネル

司会それはちょっとうまく行かないんじゃないんで

ぽ，各開発の工程毎の比率に対して，そのプロジェク

しょうかね。時間も迫っていますので，次に行きます。

トの成功率との相関をとるとかですね。で，それは結構，パッと，グラフにして見せれば。例えば，横軸に14.

失敗をきちんとまとめることこそが重要では?

丸田(東京電力)

review 比でも良いです。レビュー比とフィールドパ

実は，私共の会社では，今まで，事グの数だとか，レピュー比と開発効率だとか。という

務系や業務系のソフトウェアは何年かの歴史がある

ふうに，まとめていっているんですね。で，それは結んですけれど，制御系という今までほとんど経験の構，説得力があります。何をすれば良いかというのは，なかったドメインに対して，新しく自分達で開発して今までそういう概念の無かった人にも，わりと早く技

ゆとうという取り組みを，私をはじめとするグルー

術移転が出来る方向だと，思っています。

プで始め ようとしているととろです。で，とれから新

久保極端な言い方をしますけれども，教えるというしく始めようということを逆手に取るという意味ものは止めた方が良いと思いますね。それから，勉強しあって，本格的に着手する前に，色々な標準を調べた

たくなる状態を作るというか。だから，やっぽり，失り，事例を学んだり，マニュアル作りとか環境の整備

敗させるのが一番良くて，その時，失敗した時に，如という ζ とを始めていると ζ ろですけれども，兼子さ

何に学習に結び付けるか?。そ ζ じゃないだろうかとんの話の中にもありましたように，多少なりとも経験思うんですけれど。だから，教育議論って，みなさんを持った人は，例えばメタな議論をした結果であると好きですけれども，大抵，何を教えるのか，という ζ

か標準みたいなものを見た時に「ああなるほど」ととばかり議論をしているようにですが，それは間違っいうふうに，行問を理解するような能力があるようでているんじゃないだろうか，と思っています。むしろ，す。ととろが比較的経験の浅い人とや，今回私達の学習するととを，どうやってその気にさせるか?といプロジェクトに初めて入る人というのは，そういうとうふうに考えるのが正しいと，僕は思っていますね。

とを一生懸命教えようとしても，なかなか伝わらな

極端ですけれども，教えるなんでいうのは思わ念い方

いととが多くて，今，そういうことでも苦労していまが良い。

す。で，私はかつて別の部署でソフトウェアを作っ

兼子物を作っている現場で QC サークルみたいな

たとともあって，成功もあるのですがかなりの失敗の，ありますよね。ああいう所で，新しく取り込もうもして来ました。で，そういうネガティプな経験とと，思ったら，サクセススト -9 を広めるっていうとというのが，きちんとまとめられたり，外部に発表されをやるんですよね，一般的には。だけども，もう少しするというととがどうも少ないような気がするんで上のレベルのエンジニアぐらいが，きちんとした技術す。例えば，プロセスだとかメタな議論を始めると，標準を作ろうだとか，あるいは自分達の仕組みについどうしてもサクセススト -9 のことを広めようとか，て改善しようといった時だとかには，ゃっぽり失敗をうまくいったととを説明しようという方にどうして書くんですよ。というのは，サクセスというのは再現も向きがちで「とういうととを疎かにすると， ζ んな性が無いですけれども，失敗は再現性があるんですよ，

ひどい惨めな結果に終わるんだ」というような，例え多分。だから，何で失敗したのかを見ると，自分達がば標準書+惨めなサプ読本とか，そういったやり方

何でどとが弱かったのかっていうのが判る。それは多で一種の脅しになるのかもしれませんけれども，うま分， 2 度も 3 度も同じ失敗をしてるんですよね。だか

く標準ないしプロセスを理解させるとか，まわりにら，プロセスをインプループメントをしようとか，ど広めさせるとか，そういった，ちょっとえげつないやんなムープメントでも良いんですけれども，何かムーり方でやる ζ とは効果は無いのか?，あるいは，そう

プメントを誰かがワッと起として仲間作りの時には，いったととをやっている事例とかを御存知ではない

サクセスストーリが要るんですけれど，それを本当にでしょうか?

形のあるものにして強固なものに組み上げてゆく為

坂本そんなに立派なととやってないんですけれども，には，失敗を解析してゆかないと。サクセスストーリ

個別のプロジェクトというよりも，先ほど私が言ったを解析したって，多分，プロセスなんか良くならない

3 つ目のキーワードのメトリックスなんですけれどんじゃないかなって思いますけれども。

も。何故メト P ックスをやるかと言うと，それは，技司会僕も 1 つコメントがあるんですけれども。一

術移転をし易くする為に，メタにしておけば技術移番良い，一番理想的な方法は，ゃっぽり“失敗を出来

転は早いと d思っているんです。その為に，メトリック

る環境を作るとと"だと思います。なぜ大学教育が必スを計測して，とういうととをやればとういう結果

要かというと，大学教育というアイソレートされた環が出ますよ，というととを言っているんですね。例え

SoftwareSyrnposium'
9
4

‑50‑

北海道，函館

クロージング・パネル.9 No.6‑7
SeamailVol

境の中で失敗しでも良いですよという環境の中で技司会皆さん考えていますんで，時間稼ぎをしますけ

術を学ぶととが出来るという所が，理論を学ぶことがれども。多分ですね，今，玉井先生が言われたのが，標重要だと思います。で，それが実社会で出来るか?と準の良いところでもあり，功罪であるととろだと思う

いうと ， なかなかそうはならないと思います。良い会んですよね。例えば，私の元居た IBM でも，非常に社は，そういうことをやってきたし，やってとれた 。

沢山の標準がありまして，会社に入った時に最初に読で，とれからどうか判りませんけれども，出来なくな

まされたのが，そういう，どうやってプロジェクトをるでしょう 。 そうしたらやはり，その，他の失敗例かやるかという標準なんですけれども，それは何も知らら学ぶ 。 とういう SEA の会議で，お互い失敗例をあない人のためのものですが，それまで学生としてアルまり隠さずに交換を出来れば良いなぁと，僕も思いま

パイトでかなり長いプロジェクトを何回も経験してす 。 賛成です。

きた私でもすごく学ぶところが多かったです。で，そ

で，次，時間もおしてますので，玉井先生。

玉井(東京大学

ういう意味では非常に役に立つ。との会社でどうやっr 標準化を推進する」議論で，例たら仕事が出来るのかというととを学ぶ。それは，一えば兼子さんの議論が典型的だと思うんですけれど

般的な generic なノウハウを持って入ってきた人間

も ， その根拠は 「 平均的な人聞を」と。で，その“平で，それを ζ のシチュエーションで何をしなきゃいけ均的な"と言ったときに“出来の良くない人も含む"ないか?というのを知るために役に立ったと。ととというのが前提になっているのでしょうけれども，そろが，それが， ØU えぽ 5 年経って，同じ物が同じようういう人達を集めてなんとか生産をするときに，やっに役に立っかというと，まったく無いでしょうね。だぽり標準的なものは要る，という議論ですよね。

から，そうなってくると，今度，逆にとうしたいのに，

一方

r 標準というのは役に立たない」という議

とこではとういう特殊な処理をしないと，マネージャ

論で，さきほど少し出てきていたのは，個々の現場のあるいは社長さんの所に行って説明しなければいけ

specific な問題なり作業に対して，標準あるいは共通

ない，というような足かせになってくるわけです。そ化したプロセスというのはやっぱり役に立たない，とういう面と 2 つあると思いますね。それは，もうどいうネガティプな意見があったと思うんです。

うしようもなくて，パランスの問題でどとに出来るかけれども，どちらの考え方も非常に良く似ているとというのは，やはり企業としては，非常に抽象的なプ

思うんですよ。どとが似ているかと言うと，ある作業

ロセスを取らざるを得ないし，個々の事業部とか，さにとっては，少し共通化された少し違う分野のプロセ

らに個々の部門になったら，かなりの specific なプロスというのは参考にならない。基本的には，他から学セスを定義せざるを得ないと思います。で，それをうぶ ζ とは出来ないと。あるいは極端に言えば，自分自まく活用してやっていく。で，それがですね~，その，身のインスタンスで過去でやっている ζ とからも学

自分が日本人で悪いなぁと感じたのは，そういうもの

ばない，という考え方ですね。とれは『個々の人聞が，が，一度与えられると，与えられでもう変えられない

学習してゆくとか，知識が増えてゆくとか，あるいはものだというふうに，なんとなく思い込んでしまうわ

知識が移転してゆくとか，能力が向上するとかというけですね。で，教えられたら，そのままやらざるを得ととがあまりあてにならない』というととが前提にない，と決めつけてしまう。そのあたりが，アメリカ

なっています。

人と一緒に仕事をすると違っていて，で，昨日の Alan Davis のレミンジニアリングは「いるけど，とういうふうに話を持っていて，誰かさんにろんな技術，ファッショナプルな技術というのは現場話をして，で，承認してもらえば良いじゃないか」とじゃ，役に立たないよ」と主張していて，非常に説得いう話になって，誰かが出て行って話をして，とにか力があるんだけれども。しかし，ある意味では非常くそれで良いっていうふうにしてしまうという。そにマッチョなというか，反技術的な，あるいは反知性

ういった臨機応変さというのは，我々にはちょっと無的なものが明らかに根底にあるわけです。そとまで

いなあという気がしました。そして，そのへんも非常r とうなっていそういわれちゃうと，ちょっとインテリはもうどうしに大事なもんだと思います。すごく時聞がおしていようもなくて，無言のまま引き下がらずを得ないととますけれど，誰かありますか?

ろもあるんだけれども。でも，どうもその，標準に賛久保成の立場も反対の立場も，根はそ ζ でつながっている

かなあ~，という気がしないでも無いですけれども。

ようなととろがあるように見えるんですけれど，それ

やっぽり，経験を知識にして，で，どんどん知識が硬に対して何かコメントがあれば。

くなってゆくと，本になったりして，最後はツールに

15‑17June1994‑5
1‑

なんだろう，とう，標準と言葉が不適当なの

AddendumtotheProceedingsofSS94

クロージング・パネル

SeamailVoI.9 No.6‑
7

なったりする。で，標準なんて言われているものは，

セスの中で組織が知識を蓄えてゆくととになるんじゃ

ツールにまでいかないんだけれど ， やはり経験から学ないかと思うんですけど。

んだととを表現しているんじゃなかろうかと思うん

司会時聞になりました。最後は当たり前の結論にですが 。

なってしま い ましたけれども，長い間，皆さん積極的司会そうですね 。

に議論に参加して頂いてありがとうございました。最久保だから，標準というと，すごく後に，パネりストの方々に感謝の意を表したいと思い

司会権成があるみたいにね…

ます。拍手をお願い致します 。 どうもありがとうご

久保なんか，そうなっちゃって。

ざいました 。

司会そうじゃないですよね 。

久保だから，“知識の再利用の 1 つの形態"という参考文献

ふうに思っちゃったほうが，気楽だと僕は思うんです[lJ E. ヨードン(松原訳)，ソフトウェア管理の落し穴，トッパンけれども。

司会僕もそう思いますね。最近，非常にそう思って[
2
J M.C .Paulk , B.Curtis , M.B.Chrissis , Capabi
1ityいるルですけれども，桑名さんがちょっと言っていた，

Maturity Model ,Version 1. 1 , IEEESo.βωαre，

知識の話を最近好きでやっているんですけれど，そうJuly.(1993) , p
p
.
1
8‑2
7

いう観点から見ると，標準というのは，それは企業の標準とか組織の標準とかそういう意味ですけれども，[
3
J G.M . ワインパーグ(大野訳)，ワインパーグのシステム思考法，共立出版

そういうものを今言った知識という観点で見ると，知識を持った色々な人が，その会社にはいるわけですけ
れど，個々の人はエンジニアリングを学ぶわけですけ
れども，企業とか組織というものが学ぶ為の手段とし[
4
J NAGANOHironobu(長野宏宣)， C
r
e
a
t
i
n
gAn
r
o
g
r
a
m
ｭ
ExemplaryOrganization , Americαn P
mηJan. (1994)て，そういう形に結晶/結実してゆくっていうととが, pp.33‑41

f
[
5
JG
. Olson , J. Olson , “User-Centered Designo

非常に重要だ，と僕は思います。

兼子標単だとか，なんか，その類ですよね。まあ，ド

Co
l
1
a
b
o
r
a
t
i
v
eTechnology人 Jo
u
r
n
a
l0
1Orgα­

キュメント化されていてもいなくてもなんでも良いん

n
i
z
a
t
i
o
n
a
lComputing , VoL1, No.1 , (
1
9
9
1
)

ですけれ E も。それは，やはり組織が何か目的を達成

しようとする集団として，知識を蓄えるための枠組み[6J 君島浩，障害 1 件だけで根本原因を究明する方法，第 12 回ソフトウェア信頼性シンポジウム論というか入れ物。で，少なくとも，とうやればうまく

文集， (1991) , p
p.24‑27

ゆく，という類の積極的なものか，少なくともとれでやれば大失敗しないよ，というネガティブなものかもしれないが，それを貯め込んでゆくための入れ物じゃないかなぁと。で，標準というのは，改訂されているととに意義がある。だから例えば ISO だって 5 年に1 回改訂するというのが決められているわけだし，企業の標準もやっぽり改訂されてなかったら意味が無い。だから，改訂されていない標準を使っているっていう ζ とは，標準どおりに仕事をしていないか，つまんない標単で誰も見ていないかのどっちかなんだから。要するに，そんなものは止めちゃえば良い。で，やっぽり標準の良いととろというのは，

r あいつが」とか「そいつが」という話を，組織が持っている知識，
不十分な組織が持っている知識に還元することが出来る。で，必ず，個々人というのは標準を越えている

わけで，ゃっぽりあいつがやるとうまくゆく，あいつがやるとどうもうまくゆかない，というのがあるけれ

ど，それはやっぽり標準に反映させてゆくというプロ

So氏ware S
ymposium'
9
4

‑5
2‑

北海道，函館

クロージング・パネル

8eamailVol.9 No.6‑7/'Cターン 5

適合/'Cターン 4

認恒• • • •• • • •

一 3
一ン

一タ取

一パ能

予知

-・ ・ ・・・・ ・ .._.....
・.

・.

-レベル E: :M:a~a9凶:

ゾキタ・ーン 2・

慣習・

E

ハンフリー教授
プロセス成熟度

CMM

応09∞0・3

ソフトウェアS P IC E

ワインパーグ

田中敏文

セーフティ

図 1 . レベル分けの比較(坂本)15‑17June1994

司 53 ‑

AddendumtotheProceedingsof8894

SeamailVol.9 No.6・ 7

クロージング・パネル

プロセスの管理/改善: 3 つの重要な目標-噂法、ツールなど〉.人〈知識、経酸、ノウハウ〉.手順(揮準、プロセス管理、など〉

モラール管理: QWL(
Q
u
a
l
i
t
yo
fWorkinoLife) 論など

SoftwareSymposium'
9
4

‑54‑

北海道， 画館

SeamailVol.9 No.6・ 7

クロージング・パネル

ポスト資本主義社会とソフトウェアプロセス管理

おわりに

15‑17June1994‑55‑

AddendumtotheProceedingsofSS94

MessagefromtheS895GeneralChair

8eamailVoI.9 No.6‑7

ソフトウェア・シンポジウム '95 にむけて
中野秀男*
(8895 実行委員長)

今回，実行委員長をやります大阪大学の中野です。 8895 は琵琶湖のほとりの眺めの良い所で行なうととになりました。ローカルな設定はオムロンの坂本さんの部隊を中心にしていますが，全体的な話しは 8EA 関西が全面的に支援するすることになりましたので，その統括責任者という事で私が実行委員長の肩書で動きます。参加者を集める ζ とと会計的な事が大きな仕事ですが今までにも 88 では，ツール担当もチュートリアノレ担当もプログラム委員長もまがりなりにもやって来ましたのでその経験を生かして無事勤めたいとおもいます。わた

し以外の両プログラム委員長や各担当の方からはりっぽな所信表明がでていますので，それらの事が実行出来るいろいろな環境作りをやらないといけないと考えています。

会場は琵琶湖大橋のほとりのリゾートホテルです。ホテノレにあるプラネタリウムの部屋もセッション会場になりますので家族で来ても楽しいシンポジウムになりそうです。体育設備も揃っているようなので，今から来年度の予定に入れて貰えればと思います。

-大阪大学工学部

80ftwareSympos
.
ium'
9
5

‑56‑

滋賀，守山

MessagefroIn theSS95PrograIn Co‑Chair

SeaInailVol.9 No.6‑7

ソフトウェアシンポジウムヲ 95 論文の書き方
佐伯元司*(8895 プログラム委員長)

ソフトウェアシンポジウムラ 5 では，技術論文および経験論文を募集しております。

技術論文は，ソフトウェア開発に関わる新しい技術について論じたもので，提案している技術の本質が独創的で，技術的にも矛盾がないものでなければいけません。

経験論文は，ソフトウェア開発における自分の経験をまとめて報告するわけですが，その経験がある程度の一般性を持ち，他のソフトウェア技術者にとっても有効なものでなければなりません。

どちらのタイプの論文も，まず他人が読んで理解できるものになっていなければなりません。自分の持っている知識を他人も持っているだろう，自分が抱いている疑問や問題をも他人も同様に抱いているだろう，などという他人が自分と同じ環境にあるという前提を置くことは，論文をわかりにくくする大きな原因の一つです。

技術論文，経験論文，その性格は異なりますが，論文を書くときの出発点は同じです。まず，書き始めるにあたって，自分が主張しようとしている問題は何なのかを明らかにしましょう。つまり，現状がどうなっていて，その中のどこに問題点や疑問を感じているのかを，自分自身でちゃんと把握する必要があります。これができていないと，航路を見失った船のように，ふらふらとした，何を言いたいのか読み手には理解不可能な論文になっています。技術論文では，提起した問題に対して自分はどのようなアプローチや考え方をとったか，それらのどとが新しいのかを明確に述べ，最後にその効果の評価，ど ζ まで自分の考えていたとおりになったか，またそのとおりにならなかったとしたらその原因は何かを，自分の主張として明記していきます。経験論文では，論文で述べている自分の経験からどのようにして問題点や疑問点を発見したか，あるいはこれらを解決するのに自分の経験がどのように役立つのかを明確にしなければなりません。論文というからには，技術論文/経験論文とも話が論理的に展開されなければなりません。話の展開が論理的に飛躍している論文をよくみかけますが，事実とそれに関する自分の考え(そとから推論・推測されるとと)をきちんと区別し，無理がないかどうかをよく吟味しましょう 。 また，書いた論文を投稿する前I'C.，他人に読んでもらいましょう。他人からのコメントはわかりや
すい論文を書く上で必須です。

論文はひとつの芸術作品です。自分がやったととをひとつの作品として，他人にわかるように公開しない限り，何もやっていないととと同じです。論文の書き方によって何をやったのかが評価されます。何をやったかのだけを列挙するのは，アサガオの観察日記をつけているのと同じです。十分に推敵して，自分のやったととを芸術作品として仕上げましょう。

-東京工業大学工学部

14‑16June1995

‑57‑

Callf
o
rPaperMessagefromthe8895ProgramCo‑Chair

8eamailVol.9 N
o.6・ 7

ソフトウェアシンポジウム '95 に期待すること
坂本啓司*(SS95 プログラム委員長)

第 15 回ソフトウェアシンポジウム (SS95) のプログラム委員長を東工大の佐伯先生とともにさせていただくととになりましたオムロンの坂本です 。 「論文を通すためのハウツウを SEAMAIL に書いてはどうですか」という話しがあり，今年はまだ SEAMAIL K 一度も投稿していないので，とれを機会に Call forPaper の補足のような話しを書かせていただとうと思いました。「論文を通すためのハウツウ」などというのは私に原稿を書かすためにある人が冗談ぼく言ったのですが，ととでは真面目 K ，どんなととを考えていてどんなシンポジウムにしたいと思っているのか，またそのためにはどんな論文を期待しているかを書いてみたいと思います。
今年の第 14 回シンポジウムのプログラムに rSoftware L
e
m
i
n
g
i
n
e
e
r
i
n
g
!
?J というパネルディスカッションがありました。詳しい内容はテープおこしされた SEAMAIL の記事を見ていただきたいのですが，プロシーディ

ングの中に Lem泊gineering と いう 造語の元になった Lemming について次のような説明が載っていました。
Lemming 一定数以上に固体が増え過ぎると，突然やみくもに見える集団暴定を起 ζ し，水に飛び込むなどして個体数の調整を行う小動物 。

ととからの話しはパネノレの議論内容と余り関係無くなるのですが，実はとの Lemming の意味をごく最近まで

全く誤解していました。どのように誤解をしていたかと言いますと，

r小動物が多かれ少なかれ持っている一

般的な属性」というように思い込んでいたのです。広辞苑でレミングを引くと「ネズミ科ノ、タネズミ亜科のうちレミング属，クピワレミング属などのネズミの総称」と説明があります。なぜそのように誤解したのかを考えてみたのですが，以前 ζ んな話しを聞いたととがあったためだろうと思います。「アフリカの砂漠にすんでいるある種のア P はア P 塚を作って普段はその中で平和に暮らしているが，一定数以上に個体が増え過ぎると，突然みんながアリ塚を出て砂漠の中を定りまわり死んでしまう。との集団としての行動は特定のアリに限ったととではなく，広く一般に動物が持っている基本的な属性であると思われる。」というものです。そしてこれに続いて聞いた話も思い出しました。それは「動物が持っている基本的な属性なら人間も同じく持っているはずである。世界的な人口増加は指数関数的であり，地球環境の悪化と相まって人類は最悪の場合あと 150 年ほどでとのような状態になる可能性がある。」との話はかなりショッキングでした。ネズミやアりと人聞を同じに扱うのはおかしいと思う人がいると思いますが，逆に否定する根拠もありません。有名な「パプロフの犬」のような動物実験が心理学の世界でよく行われすが，動物の例を人聞に当てはめるととの出来る場合とそうでない場
合を判断する基準がほぼ出来ているそうです。さらに「字宙の全ては同じ物質から出来ているので，宇宙全体

も星雲も星も生物も同じ属性を持っていて同じような変化をするりという人もいたりします。ととまで行くと，にわかにはうなづき難いのですが，ネズミやア P と同じかもしれないというのは少し考えてみる必要があるように思います。

ととろで 150 年先と言うと今生きている人たちは確実に経験しない世界です。そとでとの話しを聞いたときの人々の反応はだいたい 2 つに分かれます。 1 つは「どうせ自分がいなくなってからのととだから知ったととではない。それよりも今日の稼ぎが大事。」というもので，もう 1 つは「そのような意見が当たっているか否かは分からないが，もし自分の努力不足でそのようになったとしたら子孫に対して申し訳ない。自分なりの努力をしなければ。」というものです。最悪の場合あと 150 年ほどと言った人(著名な科学者ですが)はとんなふうに言っていました。「人間も他の動物と同じである可能性は高い。しかし人聞は他の動物と違って文明を持っている。文明の発達によって人類はとの危機をプレイクスルー出来るかもしれない。そのために，単に物質的なものだけでなく本当の意味で社会を豊かにするととと，科学技術の発展に貢献していかなけれぽならない。」
なんか，宗教の話のようになってしまいましたが，私は決して宗教かぶれではありません。とりあえず私は「自-オムロン(株)EFTS 開発センター第二開発室

8
0
f
t
w
a
r
eSymposium'
9
5

‑5
8‑

滋賀，守山

MessagefromtheSS95ProgramCo‑Chair

SeamailVol.9 No.6‑1

分なりの努力をしなければ。 」 と思 っ ています。そして具体的 K は，ごくごく平凡 K 1"今の仕事を頑張らなくっちゃ。」と思っています。 1
さて，ながながと前置きを書いてしまいましたが，ととからがプログラム委員長としての抱負です。プログラ
ム委員長などという初め ての大役を気軽に引受たのですが，その大変さに驚いています 。 とれまで一見，淡々ととなされていた歴代のプログラム委員長 K は敬服するばかりです 。 その大変な役割l をなぜ引受たかと言いますと「今の仕事の頑張り J K 繋がると思っているからです。北海道がいいからとか琵琶湖に待ってみたかったと
かといっても 2 それはあくまで冗談で，論文発表する人も一般参加者弘社外の人との情報交換で 「 自分の仕事の頑張り」になんらかの形で繋がるものを得られると思うから出てとられていると思います。 そして私は，参加の度合いの 2 乗に比例して得られるものが多くなる，と信じています 。 それでプログラム委員長もや っ てみようと思った次第です。今まで 一 般参加しかされていない方も，一度論文応募をしてみると， ζ の 2 乗の法則が実感として感じられるはずです。 ぜひとも， 1 人でも多く，より深い関わりを持った参画をお願いしたいと思います。

ととろでとのような情報交換の場であるシンポジウムについて少し考えてみたいと思います 。 百科事典で 「 シンポジウム」を調べますととんな ζ と が載っています。
シンポジウム公開討論会の一つの形式。

一緒 K syn- 飲む posis の意のギリシャ語 symposion( 饗宴)が語源。特定のテーマに関して討論を行う

際，異なった立場や角度からの分析や論究が深まるよう，学識経験者などの専門家を数名選ぴ，参加者 κ
対してそれぞれが意見を述べ，それらの専門的な知見に基づき，質疑応答が主の全体討論会に移行する形式を取る。とのよ うな専門家集団に よる形式は，正しくは シンポジウム・フォーラムという。

参加者と同じ立場の人が壇上てー討議する場合には，形式はほとんど変わらないがパネル・ディスカッショ
ンとかパネル・フォーラムと呼ばれる。講師の講演に続いて講師問の討論が行われ，次に一般公衆との聞の討論に進み，最後に議長がまとめる。議長のまとめや公衆とのやりとりが省略されるととが多 い が，とれだと効果が少ない。公衆に広い視野と多くの意見を能率的に与えるとともに，公衆の討論参加によって多くの人 K ，それぞれ独自の意見を形成させるうえで重要な役割をはたす 。
とうやって改めて元の意味を調べてみると1"そうだったのか」というととろと「とれは少し違ってきているな」というととろがあるようです。とくにお酒を飲みながらの討論などは 8EA の集まりにぴったりで， 8895

でもイブ ニ ングパネル，懇親会などが楽しみです。「異なった立場や角度」とか「専門家」というととろは必ずしもそのようには思いませんが1"議長のま とめや公衆とのやりとり」の大切さはやは りそうだなと実感します。いずれにしろ，意見交換をし 「 それぞれ独自の意見を形成させる」ととを目的に集まるのだというととをまず認識していただきた いと思います。とのために，一般参加者はただ話を聞くだけのために集まるのではな

く， 3 日間の聞に最低 1 回は発言をするように心掛けて見ては如何でしょうか。また発表者は自分の 「 知見」を披露し，他の参加者を啓蒙すると同時 K ，討論のなかでさらに知見に磨きをかけていただきたいと思います。

ζ のために論文応募者に 2 つのお願いがあります。 1 つは発表内容が他の人にとってなんらかの形で役に立つ，または興味を抱く対象であるとと。発表者の個人的興味だけのテーマではシンポジウムの目的は達成できないと思います。 2 つ目は発表内容が読む人なり，聞く人なりに理解できるものであるとと。いくら立派な内容

でも受け手が理解できないものであれば，全く情報発信をしていないに等し いと思います。文学的文書と違って，科学技術文書にはサーピス精神が必要であるというととを書いていた人が いましたが全くその通りだと思います。発表者が，発表するととのみを目的としたような発表 K ，決してならないようにお願いする次第です。
要するに，一人よがりにならず，自分の発表内容は周りの人にとってどんな価値があるのかを理解し，きちっと自分の主張を伝え，意見交換によ ってお互いの知見をさらに 向上させていただきたいと思 います。私の聞きかじりの知識によると，とのととを社会心理学の領域では社会的状況認知と社会的相互学習というのだと思います。 8895 をそのための場として，ぜひとも活用していただきたいと思います。

1 t.の部分は論理の飛踊があると恩われるかも知れませんが，ととではとても説明し切れませんので，ど容赦ください。

14・ 16 J
une1994

‑5
9‑

Callf
o
rPaperSeamailVol.9 No.6‑7

MessagefromtheSS95ProgramCo‑Chair

最後に，プログラム委員長をさせていただいている特権として， SS95 をどんな特色あるものにしたいかというととを述べさせていただきます。論文募集は咋年のものをペースに一部変更して作っていますが，とくに意図して入れた言葉があります。それは「組み込み機器メーカー」という言葉です。私自身が 20 年以上も組み込みソフトに関わってきたというのが一番の理由ですが，それだけではなく世の中のソフトウェア全体の中で，組み込みソフトの比重が今後益々増えていくだろうと思っているからです。従来，組み込みソフトは小規模ソフトの代表のように言われてきました が，最近は開発量が急激に大きくなってき ており， 1M step を越えるもの
も珍しくなくなってきました。 ζ のため少し前のビジネス系ソフトが遭遇した「規模の拡大」という問題に遭遇し始めています。しかし「規模の拡大」を克服するための管理技術がなかなか組み込みソフト系には移転されておらず，いわゆる古典的な開発のトラフ.ルが多々見受けられます。とのうえに，組み込みソフト特有のハードウェア性能やリアルタイム性と いった制約による技術的課題 や，ハード開発込みのプロジェクト管理が必要

といった管理的課題をあわせて持っています。とのように多くの課題を抱えているにも関わらず，商品ごとの特質を強く意識するためか組み込みソフト K ついての技術交流があまりされていなかったのが実情です。そとで SS95 のプログラム委員には組み込みソフトを担当されている方に特に多くなっていただいており，多くの論文集めと活発な議論を期待しています。皆さんも大いにど期待ください。

tsgSoftwareSymposium'
95

ー 60 ‑

滋賀，守山

8eamailVol.9 No.6‑7

Messagefromthe8895ToolsChair

SS95 ツール展示
佐藤正道 本(8895 ツーノレ展示委員長)

はじめまして，オムロンの佐藤と申します。 8EA とは，オム ロンの坂本に紹介されて 8893 I'C論文を投稿させてもらって以来のおつきあいです。 8EA を通して業界の大先輩から様々な考えを聞かせて頂く機会ができた ζとを，大変感謝しています。

今回坂本がプログラム委員長に就任するにあたり，その兵隊の一人としてツ ール 展示を担当させて頂くととになりました。『せっかくやるなら，論文発表に負けない，面白いコーナに u を基本方針に取り組んでみたいと思っています。(どとまでやれるかは???ですが 。 o )8895 ツール展示コンセプト図

今考えているコンセプトは"，従来のツール展示に +a して，

w ツールを使いこなして築き 上げた仕事環境』の展示をやってみたいと患っています。見に来て下さった方と，将来の環境の夢を語れれば最高ですね。
誰が出典してくれるの?，インフラ環境の準備はうま くいくか?，予算は 足りるの?など課題は山積みなのですが，きっと皆さんが協力して下さるだろう。。。と，楽観的に考えています。

とんなツール展示を見てみたい!と思われた方，是非協力をお願いします。実現のためにはあなたの協力が必要です。
sato~lsa.ncl.omron.co.jp
まで連絡を下さい。一緒にやりましょう。
ではでは。
験オ ムロン(株)技術開発本部開発支援センタ SPI 推進課

14‑16June1995

‑6
1‑

Callf
o
rPaperSeamailVol.9 No.6‑
7

MessagefromtheSS95T
u
t
o
r
i
a
lChair

BOF の守・破・離
江谷典子*(8895 チュートリアル実行委員長)

仏教の言葉に「守・破・離」というのがあります 。「守」というのは ，物事はすべてが定石というものがあるから，始めは，まずとの定石を徹底的にマスターするようにする。との定石が身についたら，とんどは定石を破り，応用を試みるようにする。最後は，定石や応用の意識からはなれ，その時その場に応じた調整をする「離」となる 。との守 ・破・離 の発展は単に経験の積み重ねだけでなく，人との出会いや出会いによる知的触発が推進させるといわれます 。また ，人が集まる場とは，最初は互いの情報を交換し，その中から同じ志を持った集まり

(
B
O
F
:
b
i
r
d
so
fafeather) が生まれ，その集まりはやがて共通の目標 K 向けて行動を起とす集団へと成長していきます 。 15 年前，通常 のアカ デミ ック なコンフアレンスとはちがって，開発現場で働くソフトウェア技術者たちが自らの経験を通じて獲得した実践的な技術や知識を交換する場が必要だという認識から シンポ ジウムが誕生しました 1 。そろそろ，情報交換のための BOF から事を起とせる BOF K 向けて「破」の段階にさしかかっているのではないでし ょうか ?

ソフトウエア産業はまだまだ若い産業といわれつつ，との 15 年の聞に「ソフトウェア技術者」や「開発現場」の意味が多様化してきました 。
-コードを書いている人・システム設計をしている人・システム分析をしている人・要求分析やコ ン サルテーションをしている人・ソフトウェア開発組織を管理している人・研究をしている人
・ソフトウエア開発環境の整備をしている人・ソフトウエア保守をしている人
・ネットワーク管理をしている人・ソフトウエアの品質管理をしている人
・情報システムあるいはコ ン ピュータシステムを利用している人など様々な技術者がおり，産業構造の変換とともに開発する対象も社会の要求，サーピス，システム，プログラ
ムなど一言で共有しきれないほどのソフトウエア技術者の開発現場があります。

ζ の多様化したソフトウエア

技術者が一同に集まる シン ポジウムは異文化コミュニケーションの場であり，一つの組織の中ではありえない

新しい発見や出会いが生まれる場でもあり，アカデミズムと産業界の本音の交流ができる場でもあるといえる
でしょう。

まずは，

í発言をしましょう!J í 心に思うととを言ってみましょう!J。論文として表現し発表するのもいいでしょう。同じ関心あるいは専門領域の方同志で問題を掘り下げる議論も大いにやりましょう。そして，今は携わっていない，あるいはあまり関係がないように一見みえる領域にも，あなたの観点から意見を言いましょう。
ソフトウエア・シポジウムの定石を大切にしつつ，新しい一歩を皆様とともに築くことができれば幸いです。そとで，今回のシンポジウムでの期待は … -…
琵琶湖のほとりで多くの BOF が結成され，多くの ML( m
a
i
l
i
n
glist) が作られる ζ とシンポジウムは，誰かが作ってくれるものではなくて参加者の方々がどれだけ意見を出し議論を行い盛り上
げてくださるかが命であります。今回，若輩者である私がチュートリアル実行委員長を務めさせて頂く上に，企画および運営を 8EA 関西支部で行うととになりました。どのようなチュートリアルにするかは 8EA 関西のメンバだけでなく， 8EA の先輩方々， シン ホ・ジウムに参加しようと考えておられる方々との“participatory
desigrピ'によって成功するものだと思います。皆様の御力添えを頂きたく存じます。 8EA 関西のメ -9 ングリス
トseakansaiØcornm.eng.osaka-u.ac . jp

へ御一報頂ければ幸いです。宜しくお願い申し上げます0

・富士ゼロックス情報システム(株) 技術部
1 1994 年 ソフト ウェア・ シンポジウム論文集岸 田さん御執筆 :ソ フトウエア・シンポジウムの歴史より

S
o
f
t
w
a
r
eSymposium'
9
5

‑62‑

滋賀，守山

MessagefromtheSS95LocalArrangement Chair.9 No.6‑7
SeamailVoI

ローカルアレンジメントチェアからのメッセージ
田中敏 文ホ(SS95 ローカ ノレ・ アレンジメント)

私がローカノレアレンジメ ン トチェア K 任命され た理由はいくつかありますが，その中で一番納得性の高い理由は，私が SS94 の最優秀論文賞を戴いてしまった ζ とのようです。「あいつに賞金をやっておけば後々いろい

ろ使えるだろう」という，人なのか神なのかは知らな いですが， 何 らかの意志が働いたと見るべきでしょう。
「はめられた」という気持ちが全 くないわけではないですが ，その 賞金を一晩でものの見事に使い切ってしまった私は，さらに「業務多忙やさかいそんな んやめ とけ 」 と いう心ない上 司に恵ま れていない私はI やるっ

きゃない」状態に陥ってるわけです。 (ちなみに，実は ツ ー ル展示チェア K 任命された某 S 氏もその賞金を使い切るととに加胆したのであります。 )まー，慣れないととばかりですので“すった もんだ"も ありましょうが， SS95 に参加される皆さんには，ローカノレアレンジメントに関しては，不自由を感じさせるととな く，さらには快適さと楽しさを感じて頂けるような配慮と企画をしていきたいと思いますので， SEA 会員の皆様からの 御協力をよ ろしくお願いします。
ローカルアレ ンジメン トチェア就任 K 関する経緯と挨拶はとのくらいにして，以下に「今とんなととを考えている」という内容を紹介して，抱負に変えさせて いただき ます 。

まず，会場についてですが，ホテルの会議室以外にプラネ タ P ウムが使用可能ですので，ひとつのセッション
会場として使ってみょうかなと思っています。 字宙空聞に飛 び 出したよ うな雰囲気の中での発表と議論が，未来のソフトウェア技術に対する 夢 にまで広がってい くと とでし ょう。

次に，直例となっております皆さん御期待の懇親会につ いてで す が，せっかく皆さん湖固にまでお来し下さるのですから，湖上遊覧船でのパーティ(ディナーオ ンクル ーズ)でも ，と ，思 ったのですが予算的にきついものがあります。プログラムとも相談しながらですが，参加者負担によるオ プション化とするか断念するかを余犠なくされそうです。代わりに，リーズナプノレな子算の 範囲 内で 懇親会の趣 向を 検討していきます。

最後に，プログラムを離れた自由時間の有効な過 ご し方について ですが，会場が Y ゾートホテノレということで，結構いろいろな施設が揃っています。 当然 シンポジウムで熱心に議論するととが本分ではありますが，それ以外の時間で，テニスコート，体育館，ゴルフ練習場，屋内プー ノレ ， ク ロ ッケ ーコリレフ，浴場・サウナ(以上無料) ，レンタサイクル，ピューテイサロン ，ブライダル施設，レストラン(以上有料)などのホテル施設を有効に活用していただくために，ホテルやシンポジウムプログラムとの調整と参加者への情報提供に注力した いと 思 います。

以上，簡単ではありますが， SS95 ローカルアレ ンジメン トチェアとしての抱負を述 べさせていただきました。

- オムロン(株)EFTS 開発センター第 2 開発 室

14‑16June1995

(
t
o
s
h
i
ﾘe
f
t
s
e
s
.
k
r
c.
o
m
r
o
n.
c
o
.
j
p
)

‑63‑

Callf
o
rPaper

C
a
l
lf
o
rP
a
p
e
r
s

S
e
a
m
a
i
lVo I. 9, No.6・7

論文募集

ソフトウェア・シンポジウム '95
1995 年 6 月 14 日(水) -16 日(金)於:ラフォーレ琵琶湖(滋賀県守山市)

s
e
a
主催:
協賛(予定)

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

日本ソフトウェア科学会

情報処理学会

情報サービス産業協会

ソフトウェア・シンポジウムは、ソフトウェアハウス、コンビュータおよび組込み機器メーカ、エンドユーザ、大学、研究所などさまざ
まな場で活躍している技術者、管理者および研究者が一堂に会し、ソフトウェア技術に関する多面的な経験や知識を交流するユニークで貴重な場を提供してきました。一つの区切りとも言える第 1 5 回を迎える.

95 年のシンポジウムは、北上を続けてきた開催地を一転し日本の真ん中、琵琶湖のほとりで開催します。さらに今回はツール展示を併設し、技術交流をより充実したものとします。
毎年、現場に立脚した質の高い論文が集まるこのシンポジウムのレベルは、回を重ねる毎に着実に上がっております。今回も第 1 4 固と同様に単一トラックでセッションを構成しますが、そのため採録可能な論文は 1 5 編程度と少なくなる見通しで、高レベルの論文採用基準になると予想されます。皆様の積極的な御応募を期待いたします。
なお、従来通り最も優秀な論文に送られる最優秀論文貨は、シンポジウム開催時に選定します。論文は日本語の他、英語による投稿も可としますが、発表は日本語に限ります。応募論文テーマとしては、たとえば

CASE

・

開発環境

ネットワークCSCW/ グループウェア

プロジェクト管理

品質管理

・プロセス改善

メトリックス

ソフトウェア産業の新パラダイム

標準化対応

人間的要因

・技術者教育マルティメディア

ドメインエンジニアリング‑ 分析/設計技法などさまざまなものが考えられますが、必ずしもこれらにとらわれる必要はなく、ソフトウェアの領域で他の人に参考となるテーマであれば何でも構いません。先進的な研究テーマの発表はもちろん歓迎しますが、開発現場での苦労・努力をまとめた経験報告も大歓迎です。
奮って御応、募下きい。

応募要領
応募論文は未発表のものに限ります。また、他への二重投稿はご遠慮下さい。今回もプログラム委員会での審査は本論文にて行ないますが、応募予定の方は論文概要を記入したカバーシートにより 1994 年 12 月 20 日までにエントリをしてください。カバーシートは必要事
項を記入の上、極力電子メールで、電子メールカ勾吏えない場合は FAX または郵送で 2 人のプログラム委員長のいずれか宛にお送り下さい。
本論文の嫌式は自由ですが、 A4 サイズで 5 -10 ページ程度を目安とし、 7 部を郵送で 1995 年 1 月 31 日までにプログラム委員長宛にお送り下さい。プログラム委員会で内容の審査を行い、結果を 3 月下旬までに応募者全員に通知します。その他不明な点がありましたらプロ
グラム委員長までお問い合わせ下さい。

主要スケジュール:1 卯4 年 12 月 20 日(均

論文概要によるエントリ締切り

1995 年 1 月 31 日(火)本論文、及ぴツール展示応募締切り

1995 年 3 月下旬

採否通知送付、及ぴツール展示依頼送付

1995 年 4 月下旬

カメラレディ原稿締切り

シンポジウムスタッフ
実行委員長

中野秀男(大阪大学)

プログラム委員長

佐伯元司(東京工業大学)

坂本啓司(オムロン)

プログラム委員

青山幹雄(富士通)

鯵坂恒夫(京都大学)

荒木啓二郎(奈良先端大)伊藤邑夫。1ASC)

江谷典子 σχIS)

大場充{広島市立大学)

尾本林貞(ダイキン)

岸田孝一 (SRA)

楠本真二(大阪大学)

熊谷章伊町)

小泉叡(キヤノン)

小林允(日本ユニシス)

酒匂寛 (SRA)

砂塚利彦(問。

高橋光裕(電力中研)

田中敏幸(シャープ)

谷津行穂(日本 IBM)

玉井哲雄(東京大学)

中来田秀樹 (Next F
o
u
n
d
a
t
i
o
n
)

中谷多吉元子 σXIS)

布川博士(宮城教育大学)

野中哲 (ATJ)

平山伸一(さくら KCS)

二本厚吉(北陸先端大)古川善吾(九州大学)

古山恒夫(日本電信電話)

増子泰弘(松下通信)

婚井和也(東芝 AS)

松原友夫(p回pleware)

松本健一(奈良先端大)

ツール展示委員

佐藤正道(オムロン)

ローカル・アレンジメント

田中敏文(オムロン)

‑
64‑

C
a
l
lf
o
rP
a
p
e
r
s

Se
amailVoL9, No.6・7

ソフトウェア・シンポジウム '95
酋文応募カバーシート(ふりがな)

氏名(筆頭著者) :所属(会社・大学・組織) :役聴:部門伴部) :

住所: (〒

FAX:

(内線

τa:

E
‑
m
a
i
l:
輸文タイトル:(ツール名) :共同執筆者: (もしいれば。ツー Jレの場合不要)

氏名:

所属:

氏名:

所属:

氏名:

所属:

論文概要(ツール概要) :応募カテゴリ: (いずれかに チ ェック)口:経験報告口:技術論文口: ツ ール展示

キーワード: (最大 5 つのキーワード挙げてください。)

2:

4:

3:
5:

一一一一一…一首文応募送付先
干 152&応募締切り: 1994 年 12 月 20 日(火)一一一
または

東京都目黒区大岡山 2・ 12・ 1

佐伯元司

滋賀県草津市西草津 2 丁目 2・ 1

坂本啓司

E・mail : s
a
e
k
i
@
c
s.
t
i
t
e
c
h.
a
c.
j
p

FAX:03 ・ 3729 ‑1
3
9
9 TEL:03 ・ 3726 ・ 1111

一一一ツール展示応募送付先
〒 617

〒 525

オムロン(株)EFTS 統轄事業部開発センタ第 2 開発室

東京工業大学工学部情報理工学科計算工学専攻

E-ma
必ail : sa
紘
k且却
mわ削
o3況tω
o@ eft岱se
釘s.krc . onrron . ∞c o .j

e
x
t2192

FAX:0
7
7
5‑6
5‑5579τ玄L
じ: 0
7
7
5‑6
5‑5
0
4
8

& 応募締切り: 1995 年 1 月 31 日(火)……・・

京都府長岡京市下海印寺

オムロン(株)技術本部開発支援センタ SPI 推進課

佐藤正道

E-mail: satc噌lsa.ncl.omron.∞.jp-65・

FAX:075 ・ 953 ・ 7ω4

τ芭L:075-951-5111 e
xt3407

AO汁-協部
者事

関蹴m

euT 市

d・ 4 東

Z 都町
-'R京工

・

3

EPoJ

ソ

フヨ