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

…山 2_3目

1989

次「フ。ロトタイピング特集号〈その l) J の発刊にあたって

環境分科会例会からプロトタイピングの場合わけに関してくP0 1. 1・01)

1

プロトタイピンク事佳感 (P0 1. 1 ・02)

渡漫雄一

プロトタイピングの役割(P01. 1・03)

塩谷和範

プロトタイピングの場合わけに関して (P0 1. 1-04)

田中慎一郎

2
5
7
8

ポジション・ベーパに対する感想、 (P0 1. 2・01)

田中儀一郎

1
1

1
2

中村昭雄

ポジション・ベーパに対する感想(p0 1. 2・02)

塩谷和範

第 1 回フ。ロトタイピング討論議事録 (P0 1. *
‑
0
1
)

田中慎一郎

フ。ロトタイピングまとめ(P02.1・01)

中村昭雄「骨格型」の解釈に関連しての私見(p02.1・02)

渡溢雄一

プロトタイピングの分類(P02.1・03)

田中慎一郎

プロトタイピングへの期待(P02.1・05)

近藤直文

プロトタイピング私見(P03.1・01)

近藤直文

1
3

1
4
1
5
1
6
1
8
1
9

プロトタイフ。/ フ。ロトタイピングに関する個人的な解釈/

言葉の定義 (P03.1・02)

渡主豊

雄一

有淳氏によるプロトタイピンク.の分類についてくP03.1・03)

塩谷和範

プロトタイピンク工関する言葉の定義について (P03.1・04)

田中慎一郎

第 3 回フ。ロトタイピング討論議事録 (P03. ・ -01)

田中慎一郎

第 3 回プロトタイピング討論 (9 月 7 日〉の覚書伊03. ・ -02)
プロトタイプについてくP05.1 ・01)

塩谷和箆

プロトタイピンク討論会への論点の整理 (P05.1・02)

渡主豊

第 5 回プロトタイピング討論議事録(P05. *
‑
0
1
)

渡塗雄一

SIGENV-Forum@MORIOKA 顛末記

田中慎一郎

九州支部設立一周年報告

海尻賢二
雄一

平尾一浩

2
6
2
8
3
0
3
2
3
5
3
7
3
8
4
0
4
7
5
2

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

ジニアのための団体であり，これまでに日本になかった新しいタイプのプロフェ ッ ショナル

ソサイエティたることを目指して.

1

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

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

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

代表幹事:

岸田孝一

常任幹事 :

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

幹事 .

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

会計監事:

辻淳二吉村成弘

常任委員長:

白井義美(技術研究)

一郎中園順三中野秀男西尾出野村敏次野村行憲針谷明深瀬弘恭藤本司郎村井進盛田政敏

久保宏志(企画総務)

藤野晃延(会誌編集)

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

J iI北秀夫芝原雄二野々下幸治

教育分科会 (SIGEDU) :大浦洋一杉田義明

中園)1阪三

再利用分科会 (SIGREUSE) :青島茂阿倍正平村井進
ネットワーク分科会 (SIGNET) :青島茂野中哲
法的保護分科会 (SIGSPL) :能登末之CAI 分科会 (SIGCAI) :大木幹雄寺嶋裕一中谷多哉子中西昌武
ドキュメント分科会 (SIGDOC) :田中慎一郎
支部世話人

野辺良一

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

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

九州支部.植村正伸小田七生藤本良子平尾一浩松本初美中島泰彦能見巧後藤芳美
SEAMAIL 編集グ.ルーフ・:岸田孝一佐原伸芝原雄二関崎邦夫田中慎一郎中村昭雄長井修治成沢知子野辺良一

藤野晃延渡塗雄一

SEAMAIL Vo1.4.

No.1

平成元年 5 月 15 日発行

編集人岸田孝一
発行人

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

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

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

〒 162

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

東京都新宿区築地町 8 番地
(禁転載)

SeamailVo1. 4 , No.2‑3

MessagefromSIGENV「プロトタイピング特集号(その 1) J の発刊にあたって

すでに予告のとおり，本号はここ 1 年ほど環境分判断からです.

科会( S 1GENV :S
pec
i
alI
nt
e
r
e
s
t Group on

さて.最初に問題になったのは，どのように討論

ENVironment )で進められてきた「プ ロ トタイビを開始するかということです.現在「プ ロ トタイ ピング」に関する資料 / 討論レポ ー トのうち整理のつング 」 という言葉はあまりにも多義的に使われていいたものをお届け し ます.

ます.どのようなことでも同じだと思われますが，200 余名て・キックオフした SEA の活動も ， 今

同 ー の用語に対 し て異なる意味 / ニュアンスを各人年でつい に 4 年に入るわけですが，とのような形でが持っていては意見交換の妨げになると考えられまの特集号が発 刊出 来るまでになったことは，ボラン

す個人個人が異なる意見を持つ」ということとティアベ ー スの活動の 1 つの夢が実現したと思えては 別 に，共通の理解を得るという意味では， 何 か 1

なりません.設立当初からの会員の皆さんは御存知つ輸になるものが必要です.そこで我々は.当面，でしょうが，

山 梨大学の有淫誠先生の書かれた「ソフトウェアプ

SIGENV は SEA 設立以来の伝統ある分科会の 1 つです.とくに最初の 1 年 目 は，初ロ トタイピング(ソフトウェア工学ライブラリ 1

6 ,代世話人の方の御努力で大変魅力的な話題が毎回議

近代科学社，

論されていて，そのいくつかは(あの伝説の黄色いにすることにいたしました.我々の内部で共通の基

表紙の)1986 年 7 月) J という本を出発点

S E AMA IL にも掲載さ れ ました .

盤ができるまでは，なるべくこの本にかかれている

し かし 2 年 目 は，初代の世話人の方が多 忙 のため

内容を通して討論することにしたわけです.具体的

退かれたため以前のような準々しいテ ー マが設定出

な 出 発点、 としてはプロトタイピング 」 のイメ ー

来ず.活動が停滞しかかったこともありました . そジ合わせをするという意味でプロトタイピング

こで 3 代 目 の 世 話人にスイッチしたこの 1 年ほどは，の場合わけ J をとり上げました.本でいうと ，ともかく地道に息の長い活動することを目標とし，

2 . 1 試作品としてのプロトタイプ ，

1 つのテ ー マに関して(時間的な間隔があいても良2.2 試用品としてのプロトタイプ，

いから)継続的に議論 / 検討をするという形で活動を続けてきました .
具体的には ，

それまでのように毎 月 ，

2. 3 使い捨てプ ロ トタイプと骨格プ ロト タイプ，が中心となりました .
日 を決めてプロ ト タ イ ピングは，言葉としては恰好良いので集まると い うのではなく，まず文書で各 自 の意見をすが，議論してみると現場でのどろどろとした問題

まとめ，それを交換しあった段階で次の開催日を決の葛藤から出てきた考え方のような気もしてなりまめるという形式をとることにしました .

こうせん.そのような意昧では，議論すべき点、は数多くした方針から「在宅会員制度 J も採用し，従来のよまた ，残されていますし，併せて実践の余地も多分にありうに会合に参加できなければ 一 切活動ができないとますので，幅広い分野の技術者に共通のテ ー マと言いうことがないようにと考えました.こう し た方針

えるのでないでしょうか?

の通り，きちんと運営ができているとは言い難いところもありますが，現在，かなりの量のポジション. べ ー パ と 毎 回 の議事録が手元に残っております

これらの資料は，我々がそれなりに時間と労力を割いてまとめてきたものでありますから，このまま捨て去ってしまうのはいかにも残念です . そこで，本特集号の編集方針として，そのような資料を原則として無修 正 で載せることとしました . それは，議論の過程で意見 / 立場が変わっている人も少なからずおられるのですが，折角の貴重な意見ですし，また

おわび

今回の

SEAMAIL

は，環境分科会で乗っ取ろうとしていたので，構成が少し特殊です.そこに九 州支部から原稿が届いたので，ホットなうちにと思い，この号に入れさせていただきましたが，構成の関係
上 ，付け足しのようになってしまって申し訳ありま
せん

関係者の皆様にお詫びいたします.

それでは手作りの SEAMAIL を，ごゆっくりとお楽しみ下さい.

もし意見が変わったのであっても ， その過程を記録しておくことはあながち無駄ではなかろう，という

‑
1
‑

P
o
s
i
t
i
o
nPaper(P01. 1 ・01)

SeamallVo1. 4 , N
o
.
2
‑
3

プロトタイピングの場合わけに関して
中村昭雄
プロトタイビングはどんなものか，言葉は知っていても分類についてとか，場合分けについてとか，理解はしていませんでしたので，有漂先生の本を読んでまとめてみました
完全に出来ませんでした.

[別紙 1 ，別紙 2 を参照]特に別紙 1 は(切り方が悪いのかつ)

現実に企業の情報処理部門がプロトタイピングを考えて実行するにはどうか考えてみました .
システム開発要求仕様書の詰めの甘さが結果としてプロトタイプになる.

1)

プロトタイピングを意識して作つてはいません，最終製品を作っているつもりです .

ところが出来上がったソフトウェアはカットオーバーの前に大幅な変更を受ける，結果として試用品のプロトタイプとなるし，骨格型であるといえます .

2)

このプロトタイプというか製品というか，ソフトウェアは使われれば何もありませんが.使えなければ結局，閣に葬られ，使い捨てのプロトタイプとなるしかないのです.

(日経コンビュータの動かないコンビュータのモデルにされないうちに素早く処分する)

別にこの様なことは，意識してプロトタイプを作っているわけではなく ， 最終製品を作 って いるつもりですが，ウォータフォール・モデルでは宿命とも言える上流工程のまずさが，そのまま下流工程に垂れ流されて来た結果なのです.

実際にプロトタイピングを意識して作るときが全然無いわけではありません.それを場合分けしてみると，.試作型プロトタイプとして目的は新しい処理方法の確認
DBMS の新しい DML のテスト
4GL 導入の評価

今までに使った事の無い命令を組合わせて DB を更新する.メーカーを信用していないわけではないのですが，

0 S のパージョンアップにより新しい命令が使えます，と言われて使ったらシステムクラッシュした，と言う例は多々有ります.これでは安心して全国オンライン
等は出来ません.無駄な様でも確認する必要が有ります.この様な時に簡単なプログラムを作成します-試 用型プロトタイプ

上記の様な技術的な意味でのプロトタイプを除けは，例えばオンラインの入力をチェックしながら操作性の確認をユーサ' と行い，画面のレイアウトを修正したり，他のオンラインプログラムとの接続をチェックしたりして作成する時は試用品であり，骨格型であると言えます.
以上の様に場合わけをしてみましたが，試用品は何等かのプラスをして実際のシステムに生かしていく(=
骨格型である)と思うし，前述のオンラインの例の様に修正したのだけれど結局修正出来なくて最後は捨ててしまう事もあると思います .

試作品でも，スケルトンは別のプログラムに使用していく(企業の場合試作でも設計時に転用を意識する事が多い)こういう事を考えると.試作，試用，使い捨て，骨格とかに分けるのは良いけれど，分けてどうするのか疑問です.そのような意味では学者の世界かなという気がします.
分ける目的，メリットは何か，私には不明確です.

現在のシステム開発を見ると使い分けは本当に存在し，又，使い分けられるかチヨ ッ ト疑問を感じます.
分けることを考えるよりも，この本で言われている様なシステム開発をすると，自然にプロトタイピングが行われる様な仕組みを考えたほうが良いと思います.
(なかむら

あきお・山武ハネウヱル)

88‑6‑20‑2‑

ト

タイピンゲ、 主とぶち

~I1いは
F華街

使用目的〈使用~函〉

関連するf!l! t~

実現の

可能性
試作型

試用型

-凶・

-未経験の要素を含むとき-波数の可能性のうちからひとつを選択する'1乍り方の j糞繁

使い捨て~-要求の妥当性の 終証-問題点の発!屈 と 解決策を得るために共通 の 認謎を
物場の 3量';t

骨絡型

利用者
E存要求
の

tg

思考錯誤
か

使用するのはいつか

言語、開発手f圭開発 1室崎早〈周意に削るならどんな言語|長島町体の開発闘で行実 I量 i宣型

でも可能

。

。

￨ 附 1 ・ ~rL 抗'g

。

今

MMoa国
se
M・
司白暗号(e司
M-eH)

[国
占深 同]

7フ 'cコ

IiOf?(j を試作しながら mJI|

|凡の…備して M

間醐程の州最終礼子時四する言問寸日ン:' {~?-ìr-~ や通関|り早い段階

(設計民階〉

。

。

。

。

。

。

言語 (OS .1 1 - トウ lì もI J-~- 要求+長 を入出カ機器で制約しない

な 11ー ト や OSIS
D i去、決定表-機能及び"?n'J:J'{:J9ーフ r-À
の TD ~ トレショJ

使い捨て型

骨格型

早〈安く 7日 ト 9イ7 を作る-早い時期に安い n トで作成し ト ト の 反応を見る

試作型
試用型

-i百十の段階 での1ートの害事加を 可能とし詳細を

試作型
試問雪，.

つ める

125十の骨絡自体に自由度が残され て いる状態

シ Z子ムの骨格が岡
まった状態
。

。

早〈周意巾 ωω 言語 |でも可能

BASI C. ~PL . WK

言需((1'; .11 ー トウ Iì も

。

I
S
I
[i去
• 1サ ー の試用の際に統計子ー?をとる事が可能

加 I ltal J..加試用~

-性能商の ftゆが可能-独立な7日以が相 E に干渉し

。

。

。

。

。

。

E
S
O
L
G
PS
S

]• :こ:n.:

7 日ワラ L 伺-→l

協調してヂサや情報とやりとりする王子 Jl
実環筏型

試作型

斗|門
一提融融臨
一今、 終和阿掌
~~バ刈
叫
vVF

田市回目白d四回
e--pze-N-u

シミョレゴョン型:|だせろ様SeamallVol.4 , N
o
.
2
‑
3

P
o
s
i
t
i
o
nPaper(P01. 1 ・01)

I~ /1/M.
Jl/~ m 入副[別 紙 2 ];円 三

川町存症ハNU'叩'\hパ U
い1hm
円以・hい

ム

百円 1

.m
̲
‑
‑T
T
T
"

m

γI I 副|

銀

I I地l

~L;
一一一 一 一 →

川

|!

」 :

L:i 収監督副 ;
J

‑
4
‑

S
e
a
m
a
i
lVol.4 , N
o
.
2
‑
3

P
o
s
i
t
i
o
nPaper(P0 1. 1・02)

プロトタイピング雑感
渡遺雄一
プロトタイピングについて，過去に 1 年ばかり富士通のユーザ会の研究会[ 2]に参加しながら検討を加えていく過程で，個人的には以下のようなたわいもないことを考えるようになった『プロトタイピングを支援する環境は何故 SE を対 象しているのであろうか?食堂でメニュ ーを見て，食 べたい物を注文するように，我々が実現出来るソフ トウェアをあらかじめ用意しておき，利用者がそれらを選ん で「プロトタイ ピ ング・ツー
lレ」に依頼すると，なかば自動的にソフ トウェアが生成され，それにユーザ自身 が「プ ロトタイピ ング-ツ ール」を通して改良を加えてゆくことで最終的なシステムが完成されないものかと.

. .A

プロトタイプとは言葉通り解釈すれば「鍵形」である.その ti 形を用いて利用者との意識のづれ(例えば要求仕様の設定記述の間違い，要求仕様内の矛盾の摘出.要求仕様には記述されていなかった事項など)などを発見し，取り敢えずまたそのプ ロトタイプを修正することにより最 終的な対象ソフトウェアを得ようとするアプローチである.特にここで重要と考えることは，

1)プロトタイプの変更 - 変形は意識的に意図的にそしてある種の計画性をもって」行われなければならない .

2)変更を加えることを通じて(時には元の要求仕様に修正を加えることをも恐れずに)要求仕様と実現される対象ソフトウェアとのズレを最小限にするべくという作業過程を体系的に整理することにより，手法としての確固たる地位を得ようとしている .
ということである.個人的な興味は，さらにこれらを支援するソフトウェア環境にあることは言うまでもない.
特に要求仕様に対する変更を如何に効率的に正確に記述するのかという「仕様の差分記述 J(こんなことほんとに出来るのだろうか? )と概念モデル」等の新しい MMI を組み合わて始めて実現されるアプローチに関心がある.
さて一種野蛮なその場しのぎなやり方を，実際の対象システムの「雛形」として正統化し用いることで，一応のステイタスを確立しつつあるプロトタイピングだが，冷静になって考えてみると，幾つもの問題があることが分かる.まずプロトタイプなるものは，如何なる物なのか?，そして知何に作られるものなのか?そしてどのような形で修正-変更を加えれば良いのか?その背景に思想や方法論は存在するのだろうか?).そして変更されてきたものは，いつプロトタイピングの過程を抜け出したと言えば良いのだろうか?，また過程での費用等の見積もりはどうすべきか?
個人的には，プロトタイプは対象ソフトウェアの範犠(個々の業務)に依存した内容を含まねばならないため，機能としてプロトタイプの持つ特性を論ずることは出来ても，その実現方法を特定することは極めて困難であると考える.そのようなことからも，対象分野に依存しないプロトタイプの共通的な特性を洗い出すとともに，その為のソフトウェア環境(プロトタイプの開発と本システムへの移行環境)の実現への用件を，具体的な開発事例を調査したり紹介しあうことでまとめられればと考えている.その為には，[3] のような先進的な研究成果・論文の詳細な解説を勉強することも重要だが，実践的にもう少し皆で共通に認識出来る事例を中心に，地道に議論検討を加えていくことを提案したい.特にプロトタイピング手法を用いて“失敗した"事

例の発表がないことは.方法論・手法として体系化していない現在，かなりの属人性をもっていることの裏返しである.ならば今後プロトタイピング手法がむやみに使われだしてからでは遅すぎやしないか?それまでに心ある人々の参加を求めて，少なくとも言葉のニュアンス位は統ーしておかなければ危険極まりない.実際，
今 回の 議論の 中心となる「使い捨て生き残り」とかについては通常生活のなかで用い られているニュアン

スでも通るが試作品試用品骨格」といった用語は一部の人には通用するが誤用誤解のもとになり，ひいてはプロトタイピングそのものの誤解にもつながりかねない.

またプロトタイピングを行う際のポイントが幾っか挙げられようが，その中で一番私が気になることは「はじめからどのようなプロトタイピングを進める積もりだったのか? J ということがプロトタイビングの事例に何も述べられていないからである.例えば「或る目的の為にプロトタイプを作りまして，何々の問題があったため修正を行いまして.

. .J といった資料を見ても，結果としてそのなったかも しれないけれど，何故そ のように進めようとしたのかいった決断(意志決定)したことが明確にされていない.このような重要な作業プ
ロセス の分岐点で，さほど理由もなく，ただ経験者の個人的な判断によるのならば，それはプ ロトタイピ ング

‑
5
‑

P
o
s
i
t
i
o
nPaper(
P
01
.1
‑
0
2
)

SeamailVo1. 4 , No.2・3の成功として認めるわけにはいかない . プロトタイピングが「手法」として定着する(させる)ためには何らかのソフトウェア工学で検討された「仕指け裏付け」が欲しいと思う.

その為には.現在挙げられているプロトタイピングの「分類」についてディスカ ッシ ョ ン して言葉の意味を

我々なりにハッキリ(出来れば定義)させたい.私はいろいろなパター ン のプロトタイピ ン グの進め方があると思う.但し，業種なりソフトウェア作成工程の部分でなり，それぞれ向き不向きはあると思 う. それを最低限でも整理してみたい.

気になる話を 1 つ.去年の夏のワークショ ッ プ(若手の会)に参加していろいろな話をしていたおり，佐原伸氏 (SRA) が「証券などの大規模システムはみんな最初から大掛かりなプロトタイビン グ をやっている . あ
んな巨大なものを，最初からちゃんと設計出来る人などいない . J という趣旨のことを言われた . そして先日のソフトウェアシンポジウムのパネルディスカッションで「このあいだの兜町の証券取引所の シ ステムのトラ

ブルはアルゴリズムそのものに問題があるのではないか? J という(具体的な予想)指摘をされていた.もしそうだとしたら ， プロトタイビングの進め方に問題があるのではないかと思 う .プロトタイビ ン グは概ね，対象システムの幹になる部分や，主要なサブセットを取り出してきてプロトタイプを作り評価するので，データ量は少なく，例外処理などもことごとくハショルのが相場である.つまり私が言いたいのは，プロトタイピ ン

グをすることで対象システムの仕様が明確になるとい う 利点がある反面.下手に骨格型のプロトタイピングを採用して，その時はなんとか耐えられるシステムを作っても，その問題点(レスポ ン ス ， 大容量への配慮)が設計の段階でおろそかにされたり検証段階で見逃されたりするのは ， かえってマイナスであろ う と思う .

また良く言われることだが，プロトタイピングを進めていくとドキュメントをおろそかにしがちであるということがある.たしかに不要なドキュメントはいらないが，上にも言ったように「なぜ不要と判断したのか」が記録として残っていないと困る場合も今後あろうかと思う . 但しそれらが全てプロトタイピング手法の責任というものではないが.

言い訳ですみませんが，以上思いつくままに書きました.あとの議論は SIGENVの 集 まりの席で楽しくワイ
ワイとやりましょう .

【参考文献】[1]有漂誠:ソフトウェアプロトタイピング，近代科学社 ， 1986
[2] r プロトタイピングによる シ ステム開発 J ， 富 士通 LS研 6 1 年度報告書，[3]伊藤ほか:プロトタイピングツール.啓学出版， 1987 . 91987 .

[4]花田牧悦:プロトタイビング技法を実践的に解説した書，日経エレクトロニクス，(No. 448) , pp. 233~234
(わたなべ

6

1988 . 5.30

ゅ う いち: 電 力計算セ ン ター)

88‑6‑20

‑
6
‑

P
o
s
l
t
l
o
nPaper(P01. 1 ・03)

SeamanVol.4 , No.2・3

プロトタイビングの役割
塩谷和範
1)基本的には“総てのソフト開発にプロトタイピングは有効である"
プロトタイピングは全体に適用するのが一番効果的である.が，部分的なプロトタイビングもその他の部
分との関係を充分考慮すれば，有効である.しかし，これを総合的に支媛する環境においてもっとも効果を発揮する .

2) 構造的手法による問題点

従来の構造的手法による開発において次のような問題点が発生していた.
最初から総ての要求を定義するのは不可能であり，要求定義が完全でなければ作成するソフトは不完全とならざるを得ず，
従って仕様変更・変更要求が発生する.
これを解決するには，

1.明確な要求か ら定義し適宜作成していく
2 不明な点に着目してこれを先に解決していく

3. 不明な点を含めて動くプロトタイプを作るなどの方法が考えられる.

ここで1.は後になってから問題が発生し手戻りが生じる可能性が高く，

2. は総ての不明な点を洗いだすのが難しく，しかも総てを明らかにするのは難しい.

3)プロトタイピ ング

その点 3. はユーサ' 要求を要求定義者の解釈でフ・ロトタイプを作成し，これを動かして見せる事によってユーサ' との聞の解釈の遣い・要求の漏れ・矛盾などが明確になる.かつ少なくともユーザインタフェース部分についてはユーザの承認を得ることができる.

しかし次のような問題点がある.
1.従来の要求定義より時間と工数がかかる.

2. プロトタイプが うまくできても 目的システムが成功する保証はない.
3. プロトタイピ ングのための支援ツ ール・環境が存在しないか使えない .
4. 既存システムの修正 ・改造などには適用しにくい .

1 については，プロトタイピ ングに 工数がかかっても手戻りがなければ総合的には効果がある.
2. は確かにそうだが同じことが従来の手法にも言 え，従来の手法より要求が明確でありかつユ ーザの承認を得ている分だけ失敗の可能性が少ない.

3 . 確かに現在までのところ総ての場合に有効なツールは存在しないが ，部分的にプロトタイピングすることは可能であり効果を挙げることができる.

4. 新規システム作成時には総てをプロトタイプできるため有効だが.既存システムの改造 サブシステムの追加などの場合，既存部と新規部をうまく分離できるケースは少ないため既存部分の扱いが問題となる.
3. の部分的プロトタイピングの場合も含めて ，対象システム全体を考慮する視点(方法論)が必要となる.

4)検討課題従ってこれらの問題点を踏まえて.
(1)対象システム(制御系/アプリケーション ・デ ータベース/シミュレ ー ション・図形 /文 書処理・会話処理/パッチ処理など)(2) 適用条件(全体/部分・新規/改造)を検討し各々の場合に有効な方法論とこれを支援するプロトタイピング環境を構築する必要がある.
(しおやかずのり

S RA)

88‑6‑20‑
7‑

SeamaﾟVol.4 , N
o
.
2
‑
3

P
o
s
i
t
i
o
nPaper(P01. 1・04)

プロトタイピングの場合わけに関して
田中慎一郎
1 .まじめに有淳氏はプロトタイプの場合わけを次の視点から行なっている .
試作品 / 試用品
使い姶て型 / 骨格型

シミュレーショ ン 型 / 実環境型

これらの分類は，作成されたプロトタイプ，あるいはプロトタイピングのために環境を考える場合にはある程度の意味をもっと思われるが，プロトタイピングそのものを考える場合にはさほど正しい視点とは思われな
いふしがある.これはプロトタイピングを考える際に最も重要なことは.その目的を考えることであり.手法 ，あるいはその後の利用云々はあくまでも二次的なものと思われるためである .
以下ではまずこの分類に対して感じる不自然さを提示した上で.

J.R.Johnson 氏のレベルわけを参考にした目的から考えたレベルわけ」に関する私見を述べる.

2.

有淳氏の分類に関する言い揖かり有淳氏の分類はプロトタイピングとは何か」を理解するための分類であり，プロトタイビングそのものを分類したものではないこと，および上記の目的としては非常に適切であると思われると言うことを先に述べた上で，半ば言い拐かり的にこれを否定してみたいと思う .

2. 1

試作品/試周品の分類

まずこれはプロトタイプの「使用目的』から考えると，開発者向けプロトタイプ / 利用者向けプロトタイプのようになると思われる.つまり，氏の言われることも良く理解できるのではあるが試用品」であってもそれがプロトタイプである限り「試作品」であることには間違いがなく試作品」であってもそれが「使われない 」 ことはあり得ないためである .

例えば，単に「試用」と言う意味であれば，完成品を宣伝やデモのために(すなわち「利用者」のために)使う / 使わせることはいくらでもある.また逆に「試作」されたと言うことは，何らかのデータをとるなど ，「開発者」が利用するために作られたと言うことを意味しているはずである.仮に「一度書いてみただけ J で，捨てられてしまうものだとしても，氏も言われているようにそれを書こうとして考えたことが新しいプロ

グラムを書くときに生かされるから J .開発者」にとっては立派に役に立っている(使われている)ことになる.
つまりこれは，開発者要求を満たすために試作する.
利用者要求を満たすために試作すると言 う 分類の方が妥当であるように感じられるのである .

2.2

使い捨て塑/骨格墾の分類

ついでこれはプロトタイプの「作成時期」から考えると，骨格ができている段階でのプロトタイプ / まだできていない段階でのプロトタイプのようになると思われる . つまりプロトタイプ」という言葉の指し示す範囲に関して，広義と狭義との聞で混同が起きているように思われるのである.

まず「骨格型」のプロトタイプの場合，それが完成品でない以上，それが全体として「広義 J でのプロトタイプであることには間違いがない .

しかし「プロトタイプ」は開発システムのごく一部を対象とするものであっても構わないわけで，この考え方で言うと ， 捨てられることのない「骨格」はすでに「確定された都分」であり捨てられる可能性のある部分」が「狭義」でのプロトタイプということになる .

もし「骨格」と「肉 J とは不可分であり肉」だけ削ぎ落すことができないとするならば，それは単に設
計が良 く ないだけであり，プロトタイビングの価値がない以前に，プロトタイピングですらないと思う.従って捨てられな ~)J のは「骨格」の方であり，プロトタイピング対象部分はいずれにせよ「捨てられる J のである.
反対に「使い捨て型」の方に関していえば骨格」がまだないので最低限必要な部分を「狭義」での「プ‑8‑SeamailVo 1. 4 , N
o
.
2
‑
3

P
o
s
i
t
i
o
nPaper(
P
01
.1
‑
0
4
)

ロトタイプ」と合わせて作っているだけで，もしこれが「プロトタイピング支援環境」のようなものでサポートされるとしたら不要」な部分である .
つまりこれも，まだ骨格ができていない段階での試作骨格ができている段階での試作.

という分類の方が妥当であるように感じられる.
ところでこれは当然のように時期や手順の問題になり，開発のごく初期の段階か ら骨格ができて いることはほとんど無いであろうし，内部処理の検討と並行して帳票や画面などのユーザ-イ ンタフ ェイスを確認しようとする場合なども当然のように骨格はできていない.逆に内部処理の細部を試作する場合などは，すでに骨格は決定していることが多い .

2.3

このあたりの混同はおきていないのであろうか .

シミヱレーション/実環境の分類

さらに ，記述言語 ないしはその開発環境に関してであるが，これ自体はプ ロト タイビングそのものとは本質的には関係が無い問題である.どちらが好ましいかというようなことであれば，それなりに 議論の 対象にもなるかもしれないが ， 分類としてはどうかと思う

これは例えば何らかのシステムを作 るとき に.

DB を使うか

使わないかで一般的にそれを分類しようとしているようなものである.

3.

レベルによる分類

以上のような点から，氏の分類は過去に作成されたプロトタイプ，あるいは行なわれたプロトタイピングの事 例を分類し，プロトタイピングをまず理解するためにはかなり有効であるが，一般的にプロトタイピ ング を論じるときの視点としてはやや好ましくないとして，次のようなJ. R. J
ohnson 氏[ 2] の分類をア レ ンジしたものを提案したい .
レベル 1

実物大模型

レベル 2:

模擬実行

レベル 3

動く模型

レベル 4 ・

研究開発型

3. 1

実物大模翌

「スクリ ー ン ・ レポート・フォーム等をサンプル ・ ファイル上に作成し ， 画面，プリンタ等に出力することにより，実物と同じイメージでユーザに評価させる.

J

手書きサンプルまで含めれば，プロトタイピングなどという言葉が登場する以前から行なわれていたことの延長ではある.但し当時は「早い段階から」などといった方法論が欠知していたと予想される.その意味であまり「プロトタイピング」らしくない . 全体的な裏付けとなる方法(論)が必要となる.
これは時期的にも，目的的にも.明らかに「使い捨て型」と言える . 早期に，他の設計 / 開発等と並行して行なわれる.

3.2

模援実行「主にスクリ ー ン・ サ ンプ ルに対し，処理過程に沿ったスクリー ンの涜 れをシミュレートする.個々のスク

リー ン だけでなく.業務の流れに応じた評価が可能となるファイルやデ ー タベースのアクセスは実現しない.

一般に持たれているプロトタイピ ング の一つのイメージであろう.これも明らかに早い段階から，ユ ー ザ要

求を確認するために行なわれるもので.従来のウォ ータフ ォ ール的な開発 プ ロセスに取り込む 場合もあるが，内部処理の設計 / 開発と並行して行なうような新しいプロセスとして適用する可能性もある
基本的に試用品 J .使い捨て型 J .シ ミュレーショ ン 型」と考えられる.

3.3

動く模型

「開発するシステムの一部または全部の範囲に対し，ファイルやデータベースへのアクセスおよび処理もある程度含めて作成する

内部処理に近いレベルの評価が可能となる」

一般に持たれているもう一つのイメージであろう . これは 実際 に近いかたちで作成 / 試用を行なうもので，実際に近い分だけその用途は広い.

基本的には「試用 / 骨格型 J .試作 / 骨格型 J . 場合によっては「試作/使い捨て型」にも使用される.

実環境における 何 らかの状況が問題になる場合に行なわれることが多く，作成段階は，内部処理がある程度確

‑
9
‑

膏司

P
o
s
i
t
i
o
nPaper(P01. 1 ・04)

SeamallVol.4 , N
o
.
2
‑
3

定した段階となる . 最初から「全体を捨てる」ことを予想しているケースは少ない.但し試作 / 使い捨て型」の場合は，早期に行なわれることも予想されるが，実際にはこれはレベル 4 に入れるべきであると思われ
る.

3.4

研究開発型

「全く新しい種類のシステムの開発といった場合や，ユーザ要求の変更が多く予想される場合などに，研究開発のような試行錯誤的フ・ロセスを経ながら，徐々に評価・改良をすすめる.これはむしろ，逐次改良型開発というべきかもしれない . J

一番広い意味でのプロトタイピングであろう. 1~3 のすべてのレベルのプロトタイプが作られる可能性がある.逆にいえば，全く新規なものの開発においては，従来からもこれに近いことは行なわれていたはずである.

早い段階において試作 / 使い捨て型 J .
試用 / 使い捨て型」が多用されることが予想される.また場合によっては，開発システムとは直接の関係がないが，設計方針などを確定する際の基礎データをとるための「実験装置 J を開発することもあり得る .

「実験装置 J (あるいは観測装置)を作成することは，広い意味での「プロトタイピング」だとは考えられるが，これ自体は「プロトタイプ J (原型)とは 言 い難い.何らかの名前付けを行ないたいものである.
4.

まとめ

かなり大まかなものではあるが ， プロトタイプの作成目的に応じて.上のようなレベルわけをすることは可能であろう . これはまだまだ借り物でよく考えられていない上，考えが及んでいないところも多々あるかと恩われる.しかしながら用語や概念の統ーを行なうことは非常に重要なことであるから，こうしたものに対して，
私たちなりの分類と定義と名前付けをまず第一に行なっていきたいと思う .
参考文蔵[1]有淳誠:ソフトウエアプロトタイピング，ソフトウェア工学ライブラリ 1 6. 近代科学社.

1986

年7 月

[2]ジェームス・ R ・ジョ ン ソン:ソフト開発期間を大幅に短縮するプロトタイプ手法 ， 日経コ ン ビュー
タ.

1 984 年 2 月 6 日(たなか

しんいちろうSRA)

88‑6‑20‑
1
0‑

SeamallVol.4 , No.2・3

P
o
s
l
t
l
o
nPaper(
P
01
.l
‑
0
1
)

ポジション・ペーパに対する感想
田中慎一郎(1)渡漫さんのペーパに関して『ユーザ・プログラミング」のための環境が必要かどうかはよくわからない一般ユーずにも使えるよ
うな」環境という意味では大賛成ではあるが，現状では難しいと思うし，いかに環境として優れたものが で
きょうとも，それなりの技術なり考え方なりを身につけていないものが使用するのであれば ，ますます「粗悪プログラム」の大量生産に拍車を書けることにもなりかねない.したがって「最終 シ ステムまで作れる環

境」ではなくユーサ'の求めるユーザ・インタフェイス部分を容易にシミュレートできる環境」というか ，「ユーザ-デザイン」のための(が可能な)環境でよいのではないか.
これは「プロトタイプ作成=機能(外部仕様)設計」という考え方になるかと思うが，このあと専門家が実現上の問題点等を整理 / 分析し，プログラム構成を決定するなどの「内部仕様設計」を行ない，実際に作成していくといいのではないか .
ただし，この時作成する資料を現在のようにそのまま残すためのものとして書 く の で は意味がない.

シス

テム完成後(確定後か? )に機能仕様書(あるいはユーザーズ・マニュアル)と内部仕様書をメインテナ ン

ス用に作成すべきであると思う . 現在ドキュメント書きはプログラマ (S E) がやっていることがほとんどだが ， それでは必要なことは大体記述されない.ある意味ではこの部分は切り離して別作業として，専門家を養成する方向に向かうべきなのかも知れない(別な意味でのアナリストになるか? ?)ほとんど思いつきでいってしまっているが，いずれにせよきちんと方法(論)を作り上げなければ，プロ

トタイピングは「単なる失敗プロジェクトのごまかし方」に過ぎないものとな っ てしまう .
同時に「見積りの方法」ということも重要になる.しかしこれも計画性があれば，プロトタイピング固有の問題ではなくなると恩われる .
(2) 中村さんのペーパに関して

確かに分類に関していえば，有津先生の分類は一つの視点で行なわれたものではないよ う なので，きれいに切り分けるのは無理なようである .

もう少し重複部分の少ない形で分類したい .

現状でのプロトタイビングに関していえば，プロトタイプを作るだけではプロトタイピ ン グではないことを明確にしなければいけないように思う.プロトタイビ ン グはプロトタイプを作成し，それをもとにして行
なわれる開発方法だとは考えられるが.プロトタイプが作られれば全てプロトタイピ ン グになるかといわれると，決してそうではないといいたい.

とにかく作られたプロトタイプを分類しても意味がないように思われるので，意味のある分類 / 定義をしていきたい.

(3) 塩谷さんのぺーパに関して

確かにプロトタイピングはその裏付けとなる有効な方法(論)を伴ってはじめて ， 意味のある手法になると思う.全体で議論していきたい.
(4) まとめとして要するに，用語の統一 / 定義，特性から見た分類，それに対応する方法論(方針 ， 計画)， などについてやっていきたいと思うが，ご意見をいただきたい.
(たなか

しんいちろうS RA)

88‑6‑29

‑
1
1
‑

P
o
s
i
t
i
o
DPaper(P01. 2・02)

SeamanVo1. 4 , No.2・3

ポジション・ぺーパに対する感想塩谷和範

私見ですが，プロトタイピ ン グというのは机上の議論ではダメで実験・経験が必要だと思います . ですから，
私としては具体的に何かをしてみることが重要だと思います .

しかしメンバだけの力ではプロトタイピングを実践することは難しいでしょうから(これが一番重要なのでア)全員で一つの方法を選んでせめて一つ一つ具体的に検証 思考掛川くことが必要だと考えていま

また手法とツール(特に現状の)は分けて考えなければツールの機能に制約されて本来の手法の意味を見失ってしまいます.逆にある手法を考えたときにはどんな支援ツール・環境があればこの手法を活かせるかを考え る必要が有ります .

私のセミナーの時にも触れましたがプロトタイピングを成功させるためには既存部分に対する考慮が必須です.これは大きな問題でまだどのシステム(ツール)も取り組んでいません.

」現実の問題の複雑さ・汚さを考えると元々この部分はシステム側(プログラム)では少な く とも当分の聞は鍛えない部分だと思います.そうは言ってもほっておけない問題ですのでシステム的な対処が必要てeす.例えばプ
ロトタイプ出来ない部分の特性の記述をプロトタイプに書けるようにするとか，その取り鍛いについて規定しておくことなど考えられます.

この問題はみんなで討議 ・ 検討したいところです.
(しおやかずのり: S RA)

88‑6‑29‑
1
2‑

SeamailVol.4 , N
o
.
2
‑
3

M
e
e
t
i
n
gSummary(
P
01
..
‑
0
1
)

第 1 回プロトタイピング討論議事録
日時:昭和 63 年 6 月 30 日

場

SRA

所

出席者:

18: 3 O~

ミーティング・ルーム

青島茂 (F X 1 S)

塩谷和範 (S RA)

田中慎一郎(S RA)

人数も少なかったので ，フリー ・ディスカッションの形式で行なった
有淳先生の分類に関して

1.

「試作品型 / 試用品型 ，実 環境型 / シミュレーション裂の 2 つの分類に関しては，一応独立の視点を持ち，その内部を 2 つに分けていると感じられるが，使い捨て型と骨格型という分類が同じ視点からのものとは思
われな ~\J という疑問を田中が提示した (その理由は P0 1. 1-04 参照)

これに対し骨格 J というのはスケルトンのようなものの意味ではなくnucleus(核とか心の意)の訳であるから，もとになる具体的な 何らかのもののこと.したが ってこれは「プロトタイピングの具体的成
果物(この場合はソース ・ コード)を一切使わないか，それとも涜用していくか」という視点であるという解釈を塩谷が説明した.

田中は「骨格」というのはスケルトンのようなものとして解釈していたので ，

しかし今後の方針を議論している際，有漂先生の本では(この説明で一応納得した.

p44) .形式的な仕様記述か ら実 行可能なコードを生成するようなことも含んでいることが指摘され，全員に新たな疑問が発生した.→次回に見送り.

2.

今後の方針に関して「有淳先生の分類を出発点にすることに間違いはないが，この分類は 3 視点 X 2 という大雑把なものであり，お互いの分類の間で重複部分が大き過ぎて議論に乗りに く いので，何らかの遣う分類をしたい」ということを田中が提案した.

目的から入っていくべきか，方法からはいっていくべきかに関して種々の意見が出たが，うまくまとまらない .

そこで目的と方法を考えなければいけないのだから，これでマトリ ックス をつくって考えていくのもいいかもしてない」という提案が青島からなされた .

しかしプロトタイプの目的は 1 つではないだろうし，対応する方法も 1 つではないだろ う から，実質上無理ではないか」という疑問が塩谷から提示される在宅会員の中村さんが作成した図を見ながらこれが利用できないかを考える .
一度 2 X 2 X 2 = 8 通りのパターンで検討してみてもいいのではないか.
現実にあり得るか，狙い ， 時期，言語等を考えてみる.→次回ぺーパ?

3.

まとめ

“適当にやるのがプロトタイピングでは悲しい

今後はプロトタイピングの方法論を何とかする 」 ということを目標とする

この際特にポイ ン トとしたいのは現実的なプロトタイビ ン グ・アプローチを考える 」 ということである.

例え lí. 現実的な場面を考えると，不明なところ全てに関してプロトタイプを作成することが，工期 / 工
数上許されないことが多い.そのため自然と特に問題になりそうなごくわずかの部分を対象にすることにな
る . この場合，プロトタイプした部分とそれができなかった部分との関係，例えばイ ンタ フェイス部分の整合性と いったものなどは非常に難しい問題とな る

整合性の検証はどのようにやるべきなのか ，またプロトタイプ側でやるべきか，それとも外側でやるべきか等々 ，いろいろ考えられ る.これらのことを片目で脱みながら討論を進めていきたい.

一方当面の目標としては，有漂先生の分類から単純に 8 パター ン を生成し，これをたたき台としてプロト
タイ ピ ングについて見識を深めていくことにする.これについては参照用の表を別途用意するので ，これに基づいて次回打ち合わせ前にまた文書により意見を交換したい.

4.

その他

現在存在するプロトタイピ ング支 媛環境等に関して，可能なものについてはデモを見せ て いただけるように設定したい.手始めとして.

PWB(
P
r
o
t
o
t
y
p
e
r
'
sWorkbench) をお願いしたい.
(記録:田中

‑
1
3
‑

慎一郎)

中村

昭雄

狙い
実現の

分類

可能性

利用者
要求の

思考錯
誤

具体的場面等

適用時期

言語/手法/環境等

確認

使
"
¥
捨
て

試

型

作
型

-F
】a
・

骨
格
型

システム開発4GL PL/ l

シミュレーション型。

。

。

新しい DBMS の確認

実環境型

。

。

。

モジュールの動作確認
4GL の導入ユ嗣面

シミュレーション型。

。

。

新しいサポートツールの
確認

基本設計
+詳細設計

COBOL

実環境型

。

。

。

オンライン処理の処理ス
ピードの確認

基本設計
十詳細設計

COBOL

要求定義
+基本設計
システム開発要求定義+基本設計

句。園田件目M
。唱
回同
e嗣
H
Me
白
。『M(
・ M)
・

プロトタイピングまとめ

COBOL

シス テム開発

使"¥捨

シミュレーション型。

。

。

あまりない?

型(フ。ログラム設

4GL
PL/ l

計)
システム開発

て

実環境型

。

。

シミュレーション型。

。

あまりない?

詳細設計(プログラム設
計)

COBOL

詳細設計
骨
格
型

。

オンライン操作性の確認+フ。 ロク' ラム

COBOL

作成
実環境型

。

。

手法，環境は特にプロトタイフ

画面，帳票のレイアウト

および出力項目の確認

詳細設計+フ。 ロ ク。ラム

設計

COBOL

mm
曲目白四国〈色pzeωN
・

試
用
型

詳細設計

SeamaUVo1. 4 , No.2・3

P
o
s
i
t
i
o
nPaper(P02.1・02)「骨格型 J の解釈に関連しての私見
渡遺雄一
前回の会合に出席できず申し訳ありませでした

小人数ながらかなり盛り上がったようですねェ.さてまたまた独断と偏見で雑文を書きます.

1) 前回のポジションペーパに関連して‑ 1) 中村さんのポジションペーパ (PO l.l -01) に関して
特に後半で出されていた疑問点「分ける目的，メリットは何か，私には不明確です」ということに関して，
私は効果の違いのように思います.例えば中村さんがその前で言われているように「試用品は何等かのプラス
をして実際のシステムに生かしていく=骨格型であると思うし ・・・ 」というのが出来れば理想、 だと思うのです.

しかしそれは開発規模にも左右されるでしょうし，予算などとの兼ね合いからも必ずしも理想のプロトタ

イビング環境で物事を進めえるとは限らないでしょう.そのような場合，例えば「ラピッド」プロトタイピ ン
グを狙うのかスケルトン」プロトタイピングを狙うのかは重要な選択と言えると思います.そして(個人的には田中さんなどとも話していることですが)同じ用語を使っていながら ，

この『プロトタイピング 』 という言葉ほど，そのニュアンスが幅広く，悪く言えば好き勝手に使われている(実際各種の論文・報告書ではそう です! )言葉もないような気がします.だから敢えて不適切な分類を踏襲していく必要はさらさらないと思いますが，用語の解釈は統ーしたいと思うのです.そのような意味で「理解するための分類」という田中さんの意見 (PO l.l・ 04) が妥当と思います.

‑ 2) 私のポジションペーパ (PO l.l -02) に関して
田中さんから指摘のあったように (P0 1. 2-01)

当面は「ユーザインタフェース部分をシミュレートできる環境」である意味で十分だと思います.ただここで意外と難しいのは ， 通常(特に汎用機やオフコ ン の世界では)ハードウェアの制限が厳しいことから，例えばパソコンのようなプロトタイプ作成支援環境を作りやすい物であっても ， そこでの自由度(色や罫緩など)をターグットにあわせて制限する必要が生じてくるということです.以前に大型汎用機のユーザ会で意見交換をしたときも生き残り型のプロトタイビ ン グを検討するな
ら最終段階は，実稼働機と相当のものでないと仕様の再変更が必ずあるだろう」という意見が多 く 出されました.
蛇足ですが，先日 SRA のセミナーで拝聴させていただきました PWB

(
P
r
o
t
o
t
y
p
e
r
'
sWorkBench)をもし

大型汎用機での事務アプリケーション開発に適用するのなら，ここらへんの人閣の感覚の誤差が問題になるのかな?という感じをいだきました . ただそれは逆に言えば極めて容易な解決方法をもっているともいえます.
なぜなら，ジョンソン[ 1]の主張する場合分けのぺインティングレベルで十分と考えられるので，PWB の世界のターゲットシステムのエミュレーション機能を取り込むことさえ出来ればかなりの効果があがるように思うからです.

2) 前回(第 1 回プロトタイピング討論会)への私見

ー「骨格型」の解釈ー

たしかに塩谷さんの言われる解釈がこの場ではあたっているように思う.しかし田中さんの言われる指摘も良くわかる.骨格という言葉に期待するものがイメージを広げ発想を豊かにしてくれることと，現実からの逃避とは別にしなければならない .

【参考文献】[1]ジェームス. R. ジョンソン:ソフト開発期間を大幅に短縮するプロトタイプ手法，日経コンビュータ，(1984.2.6)
(わたなべ

‑
1
5
‑

ゅういち:電力計算センター)

田中

慎一郎

狙い
分類

使

実現の
可能性

利用者
要求の
確認

シミュレ ー ション型

思考錯
具体的場面等

適用時期

言語/手法/環境等

ユーザと開発者が同ーか，
もしくはユーザ要求を開発者が非常によく理解している場合.

初期.
要求の細部が確定していない段
階.

扱い易いものであれば何
でも可.

初期.
具体的実現方法が確定していな
い段階.

本開発と同様に，なるべ
くきちんと作ることが大切.使い捨てだからといって，あまり適当に作るのは好ましくない.

誤

。

\,\

捨
て
-同臥・

型

実環境型

。

ム

向上.

試
作
型

全体の制御部分を簡易言語等で作成しておき，注
シミュレ ーション型

目部分から順次作成/確

。

よ円
!
!
.

認、をしていきたいような

格

場合.

型
。

。

逐次開発.
ボトム・アップ(??) .

特になし.

全般.

世の中のでたらめフ。ロト

タイピングの全てがこれに入るのでは??

mo
白目白山d
田e-・凶
ze-M
・a

実環境型

一部に具体的な実現方法の確定していないところがある場合.

全般.

同
Mg震 SMM80『(gNゐM凶)

プロトタイピングの分類(その 1 )

狙い
分類

実現の
可能性

利用者
要求の

思考錯
誤

具体的場面等

適用時期

言語/手法/環境等

確認

画面の動き，処理の流れ
シミュレーション型

。

ム

使
し、

イス部分を確認するよう
な場合.

て
-回寸・

早期.

簡単に早くできるものが
好ましい.

早期.

の使い捨て型というのは存在し得るのだろうか

処理速度等，マシン性能に関わる部分にユーザの要求が密接に関わる場合.

捨
型等のユーザ・インタフェ

実環境型

。

。

利用者要求=実現の可能性といった感じなので，ほとんど試作型といえる
ような気がする.

試
用
型

国
MgEe
e噌
M・
M0
回目唱。『(
・ 3

プロトタイピングの分類〈その 2)

しかしそもそも実環境型想定できない.なぜシミュレーション型でやらね
シミュレーション型。

ばならないのか.どんなメリットが考えられるのか.

格

試作か試用かの観点だけで無理矢理分けることしかできないのではないか.
現実的には実環境骨格型
では，試用/試作は常に両方起こるのではないか.

型
実環境型

。

mg 目白m-de--pz
ω e-N
・

骨

SeamaUVo1. 4 , No.2・3

P
o
s
i
t
i
o
nPaper(P02.1 ・05)

プロトタイピングへの期待
近藤直文
先ず最初に私の立場を説明します . 私は，主に中小企業や大企業の一部門といった所謂オフコンクラスの事

務処理のシステム設計からプログラム作成，運用コンサルタ ン トといった仕事をしています

端末数で数台から十数台，プログラム行数だと数万行とか，ソフトだけの金額だと数 M ￥から 10M ￥未満といった小規模な仕事です.当然 ， ユーサ'もプログラムはもとよりシステム設計が何かわからないといったレベルの人が殆どです.
この種のシステム設計で SE に要求されるのは ， ユーサ' の話を旨く引き出すテクニ ッ クです.現状分析，理想、システムから実現可能システムへのブレークダウン等々以前の問題として.経営者は現場の実務を知らず，現場は改善の方向を知らず，又隣の現場の実務を知らないといった具合です . プログラム完成後のテスト段階
で，社長や実務担当者の闘で SE そっちのけで現状の実務フローについての議論になってしまう事もめずらし
くありません.つまり，ユーザの誰も自社の実務について現状さえも把握していない場合が多いのです.かといって中小企業のオフコンクラスの小規模事務処理で専従者を置いてプロジェクトチームを作ったりしたのではコストパーフォーマンスが合わなくなります.
そこで考えられるありふれた一つの方法に，ユーザに参加者意識を持たせシステム設計に参加させる事です.

ユーザが一方的に SE に要求を述べ.

SE がシステム設計書を作ってくるといったスタイルではなく，ユーザ

自ら設計書なりプログラムの一部を自分の手で作る事によりシステム設計への参加意識を向上させる事です .
この為には ， 専門用語の羅列や動かないハードコピーではなく.実際に動作するモデルが必要であり.この点においてプロトタイビ ン グに期待しているわけです.
現在行なっている例をあげてみます . オフコンは対話型処理であり，通常ユーサ9 と数回打ち合わせをすれば，ポイントとなるデータ入力は検討がつきます .

したり.

す

そこで，手持ちのプログラムで比較的類似のものを若干手直し

D B アクセスのない画面だけを画面定義ツールで作ったりして，ともか く 動く画面を作ってしまいま

以後，打ち合わせはこの画面を動作させながら適宜ハードコピーをとったり簡単な変更はその場で行なったりしながら進めます.この方法のメリットは，文章よりわかりやすいとい う だけではな く ，ユーサ' の要求で画面がどんどん変わっていきますので自然にシステムの検討に熱が入り，データ入力という詳細設計にとどまらずシステム全体についてより深く真剣に検討を加えられるという事にあります . 又，コ ン ビュータ嫌いの人にもとっつきやすいデータ入力画面のモデルですので，社内の各部署の人の意見も集めやすく，通常見逃しがちな例外処理等も把握しやすくなります.
帳票出力も手書き仕様書ではなくワープロでもよいからプリ ン ト見本を作り，ユーサ' の修正をその場で書き込んでいくようにします

最近は SQL やレポータが使い易くなってきているので ， 可能な場合はユーザにも勉強してもらい，簡単なプログラム変更や検索位はユーザで出来るようにしていきます . X. 事務フローや運用管理マニュアル等もプロトタイプを SE が作成し ， 後は出来るだけユーザに書きこんでもらうよ う にしていきます.中小企業の事務処理クラスであれば，入力と出力を押え.運用ルールが決まれば ，システム設計はほぼ出来たようなものです.
さて，以上のよ う な要求や仕様をプロトタイプ分類から見直すとどういう事になるでしょうか .

まず ， 設計の最初の段階から見本となるモデルを作っていき主目的も要求仕様の確認とユーザの 参 加者意識の向上にあるという点で試用型といえるでしょうか.この場合のプロトタイプ自身は，次の 3 つのパター ン になります.
(1)他のシステムのプログラムを流用した単なる見本の場合.プロトタイプの分類外か?

(2)画面生成ツールを使用し.ファイルアクセスのない画面だけを作成するデモ的なもの 使い捨て型 .
(3)手直しを加えロジックを追加しながら最終製品にしていく場合 . 骨格型，試用型 .
(4)帳票出力で，レポータを使用しユーザの要求をその場で，可能ならユーザ自身で修正しながら作成していく.レポータの機能確認というユーザにとっての試作目的の面と，単なるユーザへのプログラム教育

や，システム設計上の注意点の説明という教育的な面，データペース設計の検証とい う 意味での試用的な面，参加者意識の向上といった面等を合わせもつ.
項目 3 以外は，プロトタイプの範囲ではないかも知れませんが目的は同じです.又.

1 と 2 の折衷で，既存のプログラムの画面まわりだけをツール等で変更して使用し，使い捨てとする場合もあります .
プロトタイプには，工数をかけずに模型を作るという事も必要ですので，ツールのみでなく既存のプログラ

ムを流用するプロトタイプ手法というのもあっていいのではないでしょうか . 又，プロトタイピングの目的がそのプログラム仕様の確認とい う 事よりも，(こんど う‑1
8‑

な お ふ み: ソフト工房)

P
o
s
i
t
i
o
nPaper(P03.1 ・01)

SeamallVo1. 4 , No.2・3

プロトタイピング私見
近藤直文
プ ロトタイピ ングについて私なりの意 見を 組めようと思って書き始めたのだが，例によって時間 切れになってしまい思いつくままに書き止めたメモになってしまった.

< 1 1 有沢議:ソフトウェアプロトタイピング-・・・・・・・・・・・・・・・----_.... ‑
‑
‑
‑
‑̲
.
.----_..・・・-----------------------------------

有沢氏の本は，各種のプロトタイピングに対する考え方や用語，手法について手際よく紹介した本になっている.しかし，第 2 章の分類については分類の定義や目的がやや不明確に思えるところがあるのでこの章に従って思いつくままに述べてみる.

1.試作塑/試周型プロトタイピング
氏は，プロトタイピングを，工業製品の試作品作成と 同 じアプロ ー チとしての『試作品としてのプロトタイ
プ』とユ ー ザの要求を確認する為の『試用品としてのプ ロト タイプ』に分類している

前者の試作品としてのプ ロトタイプは，従来から行なわれていた 事であり，ソフトウェア開発の第 3 世代としてわざわざ取り 上げ る

必要のないものであり，試作 / 試用と分ける事によりソフトウェア工学上の新しい思想としてのプロトタイビ
ングの概念が明確でなくなり，従来の試作・ 研究用プログラムと混同される おそれがあるのではないだろうか.
むしろ，従来の試作とは異なる新しい概念としてのプロトタイピングを強調した方がわかりやすいのではないだろうか.つまり，試作は. mock-up 又は breadboard (p. 30 参照)であり. proto

ty p e ではないと言い切ってしまった方が後の議論がすっきりすると思うのである.くどくなるが，試作は，ユーザ=試作作成者であり，エンドユーサ'の要求を確認するために行なうのは試作ではないと明確にすべきである.

2. 使い捨て翠/骨格 (nucleus) 型プロトタイプ『骨格 型』という名称が疑問だが，とりあえず 『 非使い捨て型 A
骨格型 』と い う理解としておく
先ず
r 使い捨てられるもの』が何なのか明確でない.使い捨てられるものとしては，機械実行形式，ソ ー
スコ ー ド，プログラム仕様書，要求仕様書，要求モデルや，要求の元となる背景といったものが考えられるが，氏の記述からみて.ソ ー スコ ー ドのように思われる.しかしこういった分類では，同じレベルのプロトタイピ
ングでも COBO L で記述すれば使い捨て で， 仕 様書言 語で 書けば使い捨てでない 即ち骨格型であるとい う事も生じるわけである.又，要求モデルの全てのサブシステム / モ ジュ ール がどちらかの分類に当てはまると言
うこ とは考え 難く ，実際は両者のまじったものになるはずである.したがって， 要求 モデル 全体のプロ ト タ イ
プ についてこのどち らかに分類しようと すること自体に無理がある.

次に，結果として不採用になったものも使い捨て型 に含めるのかが不明確で ある.氏は『使い捨てか骨格かの区別は，プロトタイプの試用結果が設計に及ぼす影響範囲によって決まることになる』と述べているが，もし氏がプロトタイピン グ結果によっての 分類も考えているとすればあまり意味の ない分類のように思う
あくまでも ， どういう目的で，どういう背景の上に行なうかという分類に終始すべきである .
骨格型 についても 『検査 より早い段階で，設計に選択枝が残されている段階 での参加』とだけ定義してしまうと，後述の『パラダイム』のようにユ ー ザの要求仕様とシステム作成者の設計仕様を突き合わせる為の共通の土俵としてのプロトタイピングといった，プロトタイピングの本来の定義と思われるものが抜けてしまうのではないだろうか.

結論として.使い捨てか否かの単なる分類はあまり意味のあることではなく，むしろ，見本型か核型 (n u
cle us) とか ，プ ロトタイピ ング言語の手動翻訳を 要するか，自動生成で 機械笑行形式に変換 出来 るかといった分類の方が意味があるように考える.
3 .

シミュレーション璽(/ 笑環境型}

この区分は，正直にいってよくわからなかった.タ ー ゲットマシーン上で動作させるか否かとか. 0 B の構成，デ ー タ量，負荷等の笑環境にどれだけ近付けられるか否かといった議論としてとらえてよいのであろうか.
その場合， 何でイ ンタプリタが中間にあたるのか不明で・ある . BASIC インタプ リ タで最終プ ロ グラムを作る人はあまりいないだろうが，レポ ー タ等でインタプリタ型で実働プログラムとして十分使えるものはある
し. L 1SP 等インタプリタのプログラムも増えていくのではないだろうか.

‑
1
9
‑

SeamailVol.4 , N
o
.
2
‑
3

P
o
s
i
t
i
o
DPaper(P03.1 ・01)

4.

ラピヲドプロトタイピング

早く安くという意味でだけとらえれば，氏のいう『使い捨て』と同じ分類になってしまうのではないだろうか又，

2~3 週間もかかるのがはたしてラピッドなのであろうか

むしろ，ユーザとの打ち合わせの時に目の前で仕様変更した結果のプロトタイプを提示するような事をラピッドプロトタイピングと言うべきではないだろうか.
5. プロトタイピング支援環境{大規模開発環境型/道具箱型}
氏も述べておられるように，両者の中間的なものもある.あまり意味のある分類には思えない.むしろ，具体的な手法で分類すべきであろう.

6 .構造的手法の補助手段型/オペレーショナル手法型
第 2 章の分類にはないが，3 章以降の従来型手法との対比にむしろ本質的なプロトタイビングの分類があるように思う.

【 2) 大野豊:ソフトウェア工学の背景と展望
首記文献の概要次の通りです.
人聞の概念の表現であるソフトウェアと物質的な製品の生産技術には基本的に相違があり，従来のものの工学とは異なった工学体系が展開されることが望まれる.ソフトウェア工学には，従来の工学で基礎とする自然界の科学的法則，絶対に守るべき物理・科学的法則が欠如している.人聞の知的働きの法則を基礎にした新たな原理を求める必要がある.
ライフサイクルモデル(ソフトウェアの動的発展特性も考慮したものもある)として次のものがある.

ウォータフォールモデル

理想であって現実は実行不可能に近い.

コストモデル
プロトタイプモデル

逐次改良版モデル又はスパイラルモデル
現実のハードウェアの制約にとらわれることなく，人聞の特性をより深く反映した新たなモデルに基づいた
ソフトウェア表現法と構成法を『ソフトウェアパラダイム』と称し，従来の手続き型に対して『新形態プログ
ラミング』という.

fH ラダイムという言葉は，

もともとモデル，パターン，例などを意味するが，ここでは問題を解くときに用いるモデル/アプローチをいう.ソフトウェアパラダイムというときには ，用いる言語クラス(関数型，論
理型，対象指向型など)，その言語をサポートするソフトウェア開発環境，その環境でシステムを作るのに用いるソフトウェア工学上の規律などの意味が含まれている.

ソフトウェアの定義:プトグラムだけでなく，プログラムを導入し，使用し，また開発-保守を行なうために必要なすべての文書を含んでいる.

< 3) tt 本吉弘:ソフトウェアに対する要求の形成
氏の意見の概要は次の通りである.
従来のライフサイクル論では，要求者の解釈(要求モデル)と，製作者の解釈(実現モデル)とが独立に作られるべきとした為，前者から後者に移行するときに問題を生じてきたとし，この解決の為に，ライフサイク
ルを通して要求者，製作者に共通なただひとつの解釈(モデル)を持つべきだとしている.

ここで重要なのは，要求者と製作者が交信し，改善するのはこのモデル只 1 つであり，モデルから実行可能
プログラムへの変換は自動化しこの過程に新しい要求や修正をもちこませないようにする仕組みにするとしている点である.

氏は，このような考えに基づいて設定される解釈(モデル)及びこれに基づいたプログラム生成過程/生成
方法をパラダイムと呼ぴ.次の三つのフェーズに分類している.

1 .プロトタイピングパラダイム
プロトタイピングとは.プロトタイプを作り実行することによりモデルの正当性を高めていく行為の事.で次の三つに分類される.

‑
2
0
‑

SeamallVol.4 , No.2・3

P
o
s
i
t
i
o
nPaper(
P
0
3
.
1
‑
0
1
)

(A) シナリオ型(紙芝居型)プロトタイプ

対話部分についてあたかも目的プログラムと同じような効果を使用者に与える為だけに作成するもの.使い捨てになる場合が多い . 強いて当てはめれば，有沢氏のいう『試用型+使い捨て型 』 であろうか.
(B) 原版型プロトタイプ
有沢氏のいう『骨格型』に当たる.
(C) 機能検証型

有沢氏のいう F 試作型 』 に近いのだろうか.
2. 操作的 (Operational) 仕様パラダイム，

JSD 法，PAISLey ，Gi st , Argus ，オブジェクト指向型操作的仕様，他.

3. 形式的仕様パラダイム

所謂歩行可能な仕様ではなく，文書-図表を読んだり見るものである.半自動的に実行可能仕様に変換される.

SAFE/TI システム，

PS 1 システム，

HavardPDS ，

Darco ，等のシステムが研究されている.

(4] プロトタイピング弘見

思いつくままに勝手な意見を述べてみます.とんちんかんな事や，矛盾した事も言っていると思いますが思いつきを書きなぐっただけですので読み涜して下さい.

1.新しい思想としてのプロトタイピングの!Ø-要性
コンビュータのハードウェア技術の急速な進歩によりその性能対価格比は桁遣いに向上し，従来採算のあわなかったような分野も含め，あらゆる分野でコンビュータが使われる事となった.即ち，従来コンビュータとは無縁であった人達迄コンビュータを使う又は使わざるおえなくなった.この為，

M M1 の高度化が求められるばかりでなくコンビュータに関する知識の全くない人や誤解をもっている人を含め経験や知識の大きく違う人がコンビュータシステムにかかわるようになってきた.
しかるに，要求仕様書作成からプログラム作成及び保守に至るソフトウェアの生産技術にはハードウェアに見れれるような画期的な向上はない.

1955 年から 1985 年の 30 年間にハードの生産性は 1 0 の 6 乗向上したのに対し，プログラマの生産性は僅かに 1 3 倍になったにすぎないという報告がある(注 1).この大きなギャッフ・が今日のソフトウェア危機を招いている.
つまり，単に需要が増えたので生産が追い付かないという次元の問題ではない

ハードに比べれば，ソフト

ウェアの生産性や生産技術はたいしてかわっていないといっても言い過ぎではないのに，世の中では『ハードの急激な進歩=コンビュータシステムの進歩(含むソフト)

A という誤解が一人歩きし，これが今日のソフト

ウェア危機の真の原因となっているのではないだろうか .

この問題を解決するには 2 つの道しかない.

1 つはハードウェア技術の進歩に匹敵するよ うなソフトウェア

技術の進歩を得る事である.もう 1 つはコンビュータシステムの片方の車輪であるソフトウェア技術は，

ハードのようには進歩していない 』 という共通認識のもとに，コンビュータシステムに於けるソフトウェアの位置付けを変えてしまう事である.
f走者は，ハード(工業製品)の製造技術とソフトのそれとは本質的に遠うものであるとういう考えである.

ハードウェアのように完成品としのソフトウェアがユーザに納入されるという幻想を捨ててしまい，ユーザとソフトウェア技術者が逐次改良・変更を続けながらソフトウェアを育てていくという考えに変える事である.
これは同時にウォーターフォールモデルを捨てる事である.
まず，完全な要求仕様が先に存在するという考えを捨てる .

汎用機が今日のパソコンよりも小さかった頃なら，コンビュータ化の対象も現実モデルの極く一部だけであり.仕様書化しやすく，又ユーザサイドも業務に精通したベテランを中心に十分に要求仕様検討をする余裕があったので，実用上十分といえる要求仕様書を先に作ることも可能であった.然し，今 日では ，コンビュ ータ

化の対象はあまりにも広範囲であり，アナリストは元より肝心のユーザ白身もコンビュータシステムに対する要求仕様そのものをつかみきれないの状況にある.又，コンビュータ化の為の事前準備にユーザ業務に精通しているベテランを割り当て多大の費用をかけられないようなケ ースが増加してきているのも ，要求仕様の把握を困難にしているともいえる.さらに，本質的な問題として，外部事情の変化や ， 時間経過とともに，或いはユーザの部分的要求がコンビュータシステムとして実現する事によりユーザの要求自身が変化する(潜在要求

‑
2
1
‑

SeamallVol.4 , No.2・3

P
o
s
l
t
l
o
nPaper(P03.1 ・01)の顕在化でなく文字通り変容する)という事がある .
次に，保守サイクルという考え方も捨てる.
ユーザの要求の変化やソフトの不具合は保守サイクルで吸収し，保守のコストが新規システムの作成コストを上まわるようになったら次期システムの作成にかかり新たなライフサイクルが始まるといった考えも捨てる .
コンビュータシステムは，最初から完成してものがあり，それを保守するのではない.ユーザの業務内容と同様，常に内部に問題点や矛盾を抱えており ， それをたえず改善し，経営ト ッ プの要求に応じて変更していける
ものでなければならない.
新しい手法は，コンビュータ化対象業務だけではなく，ユーザの業務内容そのものをモデル化するものである.

(1)現実モデルを作成する.業務マニュアルとか事務フローを集大成したものである.
(2)同モデルをコンビュータ化も一つの手段として，経営要求に合わせて改 善 する.ワークデザイン手法等が使用できる人，物，情報等の動きをシミュレーション出来るツールやワープロよりましな記述ツールがあると望ましい . 又 ， 改善案の内，コンビュータに関するもので問題になりそうな部分は，実行可能なモデルを作成し，コンビュータ化すべきか否か ， ハードを含めてどのような方式がよいかを評価し，又，発想、の転換の刺激材や仕様の漏れがないか等の確認にも使用する . 既存のプログラムを涜用したりプロト

タイピングツールを使用し ， 出来るだけ動作可能な部分モデル何通りか付け評価するる.ここで作成したプロトタイプを.そのまま又は改良する事によりボトムア ッ プ型のアプローチを部分的にとる事も可能である.

(3)コンビュータ化の対象とその周辺システムのモデルを作成する.データ構造や業務フローの大枠を決定する.又，エンドユーザが追加変更してよい部分と，データベースマネージャ等のシステム責任者の判断を要する部分を分ける.

(4)ラピッドプロトタイピングを併用して細部仕様の決定とプログラム作成を同時並行的に行な う.
プロトタイピ ン グは .

(2) の要求仕様作成及びその前作業といえる部分で主として使用され，後は，細部仕綴の決定に補助的に使われる.理想、 は，実行可能な仕様書言語によるモデル作成の実現であろう . 又，エンドユーサ'のプログラム作成や非定形業務の実行は.それ自体プロトタイビ ン グ の 一種といってもよいのではな
かろうか.

このモデルには，ウォーターフォールモデルでいう保守サイクルはない.つまり ， 経営要求等トップレベルの要求が変わった時は (2 )のモデル改善を実行し，その結果 (3 )のコンビュータモデルの変更になる場合と単なるプログラム追加になる場合と基幹システムには影響なくコ ン ビュータ以外の部分の改善で終わる場合とに分かれる.

肝心なポイントは.経営方針といったトップレベルの要 請 から業務マニュアルといった細部の規定迄をもモデル化してしまい，現実のシステムとモデルを一致させていく事である.このモデルを知識ベースやデータディクショナリ等コンビュータ処理可能なモデルにする事ができれば ， システム変更時の補助ツールとして大きな効果をもたらすだけでなく，将来は改善案のもたらす効果や問題点をシミュレーションできる可能性も開けるのではないだろうか.

以上かつてな事を述べてみたが，問題点は( 3)のコンビュータ シ ステムのモデルの変更にどの位の手聞がかかるかという事であり，函期的なツールが出来なければ ， システムの硬直化は避けられず，結局は現状のウォータフォールモデルと同じことになってしま う.

しりきれとんぼのような話になってしまったが，ソフトウェア危機の本質は ，ソフトウェア自身の生産性向上だけで解決する問題ではなく ， ユーザ自身が要求や問題点を的確につかみきれないでいるところにあり ， 今
後はこの部分を解決することにも目を向けていく必要があると考える .
2. プロトタイピングの問題点

有沢氏も 『 ユーザの潜在的要求をしることが大切だといわれる 』 と述べ客の措いた間取り図通りの家を建てても客から喜ばれることは少ない.と建築のたとえがよくひきあいにだされる』と述べているように，単にユーザの要求通りのシステムを作っただけではコンビュータ化の目的を達した事にはならない . むしろユーザの要求の先をどこまで読めるかがアナリストの腕のみせどころである .
つまり 『 経営者のト ッ プレベルの方針を如何に具現化するか 』 といった視点から の 検討が必要である . 従来の手法では先ずトップレベルのシステム化目標があってそれをモデル化する過程でエ ン ドユーザの要求と現状分析を参考にしていったので，結果としてはエ ン ドユーザにと っ て使いに く い失敗した シ ステムにな っ たとしてもト ッ プの方針，システム化の基本方針自身を忘れた訳ではなかった

しかし，エンドユーザによるプロトタイピングツール等が実用化したばあいともすれば ， 経営ト ッ プのシス

‑
2
2
‑

PosltionPaper(P03.1・01)

SeamaUVol.4 , No.2・3

テム化の方針を忘れさった現状拘泥型のシステムや過剰仕様の情報公害型のシステムになったり，又，セクショナリズムを助長し，従来手法より惑い結果に陥ることはないだろうか.

この心配は，プロトタイピングが所詮はマンマシーンインターフェースのプロトタイピングにすぎず.コン
ビュータシステムを含む事務システム全体をシミュレートするものではないからである.プロトタイピングのもつ強烈な印象の前にユーサ'もアナリストも本来の大きな目的を見失い小手先の MMI にとらわれてしまわな
いかという事である.

プロトタイピングは飽く迄も要求仕様作成のツールにすぎず，システムそののものの動機付けを行ない，発想を転換し，トップの要求に対する対処法を見つけるのは.プロトタイピングとは無縁のそれ以前のフェーズである事を忘れてはならない.

‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
{注 1 )

孫引きですが，大野に引用されていた表の抜粋です.

機械(ハードウェア)性能 1
プロフラマの生産性

1
9
5
5
1
9
6
5
10**2 10 ・ *4
1
2.
4

1
9
7
5

1
9
8
5

10 事事 6

5
.
6

1
3.
3

出所: ArtBenjaminA
s
s
o
c
i
a
t
e
sL
t
d
.
c
i
t
e
di
nElectronics , May8 , 1980 , p.
1
43."ComputerTechnology

S
h
i
f
t
sEmphasist
oSof
t
w
a
r
e
:
AA
p
e
c
i
a
lR
e
p
o
r
t
"
.

‑
‑
‑
‑
‑
̲
.
.
̲
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
̲
.
.
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
̲
.
.
{参考資斜}

‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
.
.
̲
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
‑
玉井哲雄『ソフトウェア開発におけるプロトタイピング A(1)

bit1983 年 1 2 月号

P. 1449(2) 牛島和夫他『日本語文章推こう支援ツールのプロトタイピング』第 40 回ソフトウェア工学研究会 P.
43(3)ジェームス . R ・ ジョンソン『ソフト開発基幹を大幅に短縮するプロトタイプ手法』日経コンビュー

タ 1984-2 .

(4) 大野45

6P.81

豊 『 ソフトウェア工学の背景と展望』情報処理1987 vol. 28 No.7 P.8(5) 松本吉弘『ソフトウェアに対する要求の形成』情報処理853@@@@@@@@@@@@@

*使い捨て

有沢氏の本

1987 vol. 28 No.7 P.

@@@@@@@@@@@@@

r 早く安く』・コストをかけないで早い時期に実現するために“使い捨て"にする.

→@使い捨てられるものはプロトタイプのどの部分か?
機械実行形式
ソースコード
仕様書
設計方針
要求仕様

文書化される前の原要求*骨格(反使い捨て設計段階てo ユーサ'に参加してもらおう』
SE がわの選択肢が複数あるときユーザの反応によって決める .
変更はしない設計方針は基本的には固まっており』
歩行可能な仕様書.標準部品化.
*変更:選択*試用結果が設計に及ぼす範囲により使い捨てか骨格か決まる.

‑
2
3
‑

SeamaHVo1. 4 , No.2・3

P
o
s
i
t
i
o
nPaper(
P
0
3
.
1
‑
0
1
)

→@単なる結果論では?たまたまなった事ではなくどういう方法を選択し，それが成功したか失敗したかという話にすべきである.単なる結果のプロトタイプなら従来と同じ.
*シミュレーション型 : 実環境型

シミュレーション:性能面も可.
試作:実環境のみ.

試用 : 何方でも*ラピ ッ ドプロトタイビング(第 3 章P.

47 から*構造的アプローチ

使い捨て

要求=問題の理解と実現をはっきり分けて，作る側にひきずられないようにする.
→@ここが問題.作る事を理解せずに要求が耀められるのか.そもそも要求仕織は存在しうるのか.
*オペレーショナル

骨格型*ユーザの追加要求は事前に推定出来ない.潜在要求も同じ .
(第 4 章P.

6 7~*構造的な手法とは独立*構造的手法にとりいれ欠陥を補う*失敗から多くを学び取るのであって無駄にはならない.
*試作品は殆どの場合使い捨て .
未経験の要素を含む時.
→@使い捨てられるもの:プログラムコードそのもの*ことばの問題

#[
G
r
e
g
o
r
y
8
4
]mock-up ,

b
r
e
a
d
b
o
a
r
d

*試用品

*要求試用書作成後システム完成迄ユーザが関与しないのが問題.関与出来るようにユーザにわかるものとして試用品を作りフィードパ ッ クさせる.

→@ユーザの要求自身の変化と要求仕様実現の失敗の区分.

*試用品としてのプロトタイプユーザの要求を設計製造の担当者たちが正しく理解しているかどうかを調ぺ，されにユーザの潜在要求を早い時点で察知して設計に取り込むことを目的とする .
機能面，A • 早期に実施要.

M M1. 性能面 ， 文書，エラー対策は含まない.

定常状懸でのデモンストレーション .
使い捨てとそうでない場合(=骨格 Du c1eus) の両方あり.

→@骨格は frame を想起させ誤訳.核型のほうがよい.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
既存品流用型
使い捨て / 骨格型

実際はその中間であり，単にどちらの要素が強いかにすぎない.

1. 変更型問題となるモジュールのみ他言語で書き変えるの迄含めるか?

2. 最終プログラム自動生成型
3. 使い捨て仕様書言語等

別の言語でかきなおす.

目的別分類

1 .ト ッ プダウン設計を否定.ユーザの要求はユーザ自身にも十分分かっていないとする立場.ユーザ要
求仕様を明確化 .
2. ユーザの思考と SE の恩考のギャップを埋める手段 .

3.

自己用 . ユーザはコ ン ビュータ専門家であり，プロトタイプ作成者自身をユーザとするもの . 研究型.

コンビュータシステムの発展

‑
2
4
‑

SeamallVol.4 , No.2・3

P
o
s
i
t
i
o
nPaper(P03.1・01)

第 1 世代コンビュータに出来る事だけを

第2

ユーザ要求を参考にコンビュータの専門家が実現可能な事だけを.最初に，コンビュータの
出力 / 入力があり，ユーザはそれに合わせるしかない

それしかハード / ソフト(OS / 言語)の能力なし.ユーザは，コンビュータ自身に触れる事はない.別室に隔擁されている .
第3コンビュータがユーザの居場所(部屋. f)1.)に近づき能力の向上により多様な要求に対応可能.だが，要求が何かわからなくなってきた.実世界のモデル化しやすい部分以外もコンビュータ化の対象になってきた.

工業製品の試作品からのプロトタイプ類推.
工業製品のプロトタイプには 2 つの種類がある.

1 つは技術的問題点を調査する為の試作品であり，研究的性格のものである.外観は二の次で，機能中心の動くモデルて'ある .

もう 1 つは，完成品からユーザが受けるイメージを類推する為に，設計図と実物のギャップを埋める為に作る模型である.建築物や土木構築物の模型.

自動車のクレーモデル等芸術的あるいは心理的反応を見る為のもので，外観や手触り等の人聞の 5 感にかんする事項を重要視する.動かない静的なモデルが多い.
これに対しソフトウェアのプロトタイプでは主に食ユーザには対立する要求がある.セクショナリズム.誰が擁めるのか.
モデルが大事か，動機付けが大事か.
色見本型

模型でなく実物の(素材)の小片

詳細な検討可.
全体との調和や ， 本来重要でない箇所に力がきかれる

郵便番号辞書は大量入力には無用

住宅建築の例
基礎知識習得モデルハウス
類似の家を見る
務店の評判を聞く
間取り図

概観図

図面
基礎工事立ち会い

色合わせ
上棟式立ち会い
完成検査引き渡し
3 か月点検・細部手直し

ライフサイクルルは本当にあるのか
単にソフト開発技法 / ツールに限界があるためそ う な っ ただけ.
現実モデル自体はライフはない.

仕様書=実行可能になれば，保守と新規作成の差はあいまい
ハード上の限界等による単純なリプレースは

例えばパグのないソフトウェアはない』という認識のもとに，虫とコンビュータシステムとの共存をはかろうという考えもそのーっと(こんどう

なおふみ:ソフト工房)

1988‑09‑06
I
T1 1989‑01‑26

‑
2
5
‑

SeamallVo1. 4 , No.2・3

P
o
s
i
t
i
o
nPaper(
P
0
3
.
1
‑
0
2
)

プロトタイプ/プロトタイピイングに関する個人的な解釈/言葉の定義
渡遺雄一は じめ に

前回の討論会での宿題であった表記の件について，取り敢えずはまず，有淳先生の本をもう 1 度注意深く読んでみた .

〔記号の説明〕~J

有津[ 1]からの引用を示す→:上記の引用に対する私の解釈

意見

食 : 私の主張【 試作品 】
『何らかの意味でこれまでにない新しい面をもっ製品を作るときに~ .何かこれまでに経験していない要素を含むとき』→試作の意図は概ね「新機能」の実現可能性の判断?
食試作目標

目的が設定された計画にそって，その意図を満たすための生産物

その生産物は最終製品ではない.
『試作品としてのプロトタイプは，ほとんどの場合，目的をはたしたあとは捨ててしまう . すなわち，使い捨て品である』→目的は事前に設定されていなければならない.
『試作品は，作りかたを模索するもの』→開発者による，開発者のための「プロトタイプ J
a の 考 えた幾つ か の切り口

〔適用時期・場面〕システム設計開始直後~詳細システム設計(プログラミング仕様)まで〔中間生成物〕なし(期待出来ない)〔最終成果物〕機能実現のための手法.それ相当のソースコード.

〔期待される効果〕- 具体的コ ー ドとして機能が示されているので，
1 システム作成時の誤解は原則として在りえない2 検証が用意なため，システム設計担当者の責任が明らかになる
3 当然，開発での生産性が従来手法に比べて上がる〔危慎される効果〕
機能実現の過程が評価し辛い〔その他〕-機能の実現可能性の評価は，プロトタイプ作成者の技量に依存するので，ある意味でシステム設計と同等である
・ プロトタイピイングの過程はさほど重要でない【 試用品 】

『試用品としてのプロトタイプは，ユーサ'の要求を設計製造の担当者たちが正しく理解しているかどうかを調べ.さらにユーサ'の潜在要求を早い時点で察知して設計にとり込むことを目的とする. ~→設計の補助・支援を意図する.プ ロ グラムやシステムとしての実現可能性の検討ではない.使い心地などの MM 1 (マン ・ マシン・インタフェース)の向上なども意図している.

‑
2
6
‑

Pos
1
t
i
onPaper(P03.1 ・02)

SeamailVo 1. 4 , No.2・3

目的は期待こそされ，結果として明確になる場合が多く，とかく唆昧(あいまい)になりがち?で設定しにくい .

『試用 品のほうは作り方自体は確立されている』→システムの内部構造よりも，最も基本的な要求仕様に対する(操作性含む)機能検証のために用いる.
→開発者による，開発者と利用者との接点のための「プロトタイフ・ J .
毛L の考えた幾つかの切り口〔適用時期・場面〕システム設計終了段階~詳細システム設計(プログラミング仕様)まで〔中間生成物〕部分的な仕様〔最終成果物〕機能検証されたシステム設計のための要求仕様〔期待される効果〕

・最終成果物(ターグットシステム)を期待したものを想定しているので，それの規模を計る目安が得られる・プロトタイプからの出力は，最終仕様に極めて近いものであるので，

l 最終仕様書，利用者向けドキュメントなどの事前作成が可能

・部分的な中間成果物からでも，システム開発に部分的に着手可能な場合がある〔危慎される効果〕-機能評価が中心となるので，

1 被験者が複数の場合にはその意見の取捨選択は微妙で・ある
2 時に同道巡りをすることにもなる

3 r 要求の定義ミス」と「要求の表現不足 J が，元要求仕様の変更を促すため ， 要求仕様の目標・欲求がなかなか確定しない.

プロトタイプとタ ー グットとの実行性能の差が，利用者に過大な期待を与えてしまうことがある
・被験者へのプレゼンテーションは，頻繁に行うと返って効果が薄れることもある〔その他〕

・機能の実現可能性の評価は ，プ ロトタイプとは別にされるべきである.

特に実際にインプリメントする際のアルゴリズムや例外処理など利用者・被験者とは直接関係ない(シス
テム屋の仕事の範略の)部分は慎重に検討すべきプロトタイピイングの過程は重要

(わたなべ

‑
2
7
‑

ゅういち:電力計算センター)

SeamaUVol.4 , No.2・3

P
o
s
i
t
i
o
nPaper(P03.1・03)

有津氏によるプロトタイビングの分類について
塩谷和範
分類

試作型

適用場面/注釈

目的

試作品を作る必要があるのは何かこれま

実現可能性の検討でに経験していない要素を含むとき 。

+要求定義段階で作る.

最適仕様の選択
性能評価'多くの場合目的を果たした後は捨てる 。
事実環境で作る事に意義がある.
試用型

ユーザによる機能確認(吟味)骨格が整った時点で主として機能面及び(ユーザ要求の解釈の確認)

MMI についてユーザに確認を求める 。

+設計段階で作る.
ユーサー 要求に幅があるとき。

ユーザの潜在要求の発掘

ユーザによる複数の実現案からの選択 。
-実環境で作る必要はない(両方可) 。
事骨格とすることは可能.

ホ試作 / 試用兼用型は使い捨てとなる.
使い捨て型

プロトタイプを早く安く作る .
複数の実現案の作成。

ユーサ' による試用から設計情報を得る .
-言語は何でもよい . (簡便な方が良い)
短期間に実現でき-手直しが出来る 。
例:

骨格型

目的システムの骨格となる 。

BASIC ,APL ,AWK ,Smal1 talk-80 , Simula-67
P
r
o
l
o
g(論理式に近い仕様の時)

基本的な設計方針は固まっていて、ユーザの反応による根本的な設計変更がない

事.
事システム骨格上に仮に実現した諸機能とイ ン タフェースをユーザに提供し 、 要求の満足度を調べる。

-目的システム記述言語と同一言語を使用
事仕様を作るのが目的では現場になじまない。仕様からの自動変換が出来ることが必要.

+設計段階でユーザに参加してもらう .
シミュレーション型

条件を変えて実験する.

様々な実験が出来る .
ユーザ試用の際の統計データ収集可 。

性能面をシミュレーションする.

独立なプロセスの協調としてモデル化する 。

要求仕様の自然なモデル化が出来る 。

(インタプリタ型)

仮想機械をシミュレートする .

シミュレーション型と同様な利点

実環境型

目的システムの環境で作る .
出典ソフトウェアプロトタイビング J /近代科学社

‑
2
8
‑

SeamailVol.4 , N
o
.
2
‑
3

P
o
s
i
t
i
o
nPaper(
P
0
3
.
1
‑
0
3
)

以上は有漂による分類だが ， 峻味な点があるので次のように解釈・定義した .
分類の分類

視点による分類:試作型 /試用型
手段による分類:使い捨て型/骨格型
環境による分類:実環境型/シミュレ ー ション型

当 然 プロトタイピングを行なおうとする時にはプロトタイピング計画 (P02 場。 1) を最初に作り，その中で目的・手段 ・ 環境を決定し，適切なプロトタイビングが行なわれなければならない . さもなければ"適当にやるのがプロトタイピング "(P O l.札 0 1) と言うことになってしまう

これでは悲しい.

まず一番問題となっている"骨格型"プ ロト タイピングだが，骨格の意味を最終システムあるいは目的システムの一部となるものと解釈した

そこで"骨格型"プロトタイピングとは，「成果物が最終システムの一部となることを目的に行なうプロトタイピング」と定義した . 従って，試用・骨格(・実環境)型で目的プログラム(最終システム記述用言語による成果物で最終システムの一部となる)を出力するケ ー スに 加 え，何らかの変換機能により目的プログラムを作成するケ ースも骨格型プロトタイピ ン グであると解釈する

例としては，前回ミーティングで発表のあった 山 本さんのケ ー ス (P 02 . 1-04) も最終システム記述用言語 (F OR­
TAN) を使ってプロトタイプしユーザによる試用後それを最終システムに発展されているので試用

骨格 ・ 実環境型のプ ロ トタイピングと言える.

"使い捨て型"は，手段としての使い捨てを意味する .

したがって「 プロトタイプを早く速くかっ安くたくさん作るために再利用を前提とせずに作ること」と定 義 する . 当然"もったいないから後で使う"ととも起こり得るが，これはあくまでも結果であるので骨格型に分類し直すことはしない .

次に"実環境型"は，「最終システムを実現する環境と同一環境・同一言語を使用するプロトタイピング」と定義する .

広義に解釈すれば，最終システム記述言語を使用しなくても実行環境さえ同じであればよいとも考えられるが，こういうケ ー スは " シミュレーション型"に分類した .

"シミュレ ー ショ ン 型"はr"実環境型"でない場合」とした.

この理由は ， 狭義のシミュレーショ ン 型は実動作環境を疑似 (Simulate) するものだが，実動作環境で 4GL . 高級言語など最終システム記述言語と遣う言語を使ってプロトタイピングをすることは最終システムの動作を疑似することに他ならないからである .

試作型/試用型については，特に畷昧とは考えないので再定義しない.
(しおや

‑
2
9
‑

かずおのり

SRA)

P
o
s
i
t
i
O
DPaper(P03.1 ・04)

SeamailVo1. 4 , No.2・3

プロトタイピングに関する言葉の定義について
田中慎一郎
1.

はじめに

挙げ足取りのようになってしまって嫌でもあるのだが ， 少し気になることの一つにプロトタイプ」と「プロトタイピング」というこつの言葉の聞での意味あるいは使用法の混同がある.

私の中の漠然としたイメージの中ではプロトタイプ」とは何らかの目的を持って試験的に作られた「もの」を指しプロトタイピング」とは，通常「プロトタイプ」を中心に，使用者 / 作成者が確認を繰り返しながら，より良いものを作り上げていくある種の手法を指している.

主題から少しはずれるが，ここでもう少し説明しておくと，プロトタイプを作れば(結果として存在すれば)必ずしも全てプロトタイピングになるわけではないし，プロトタイピング手法を採ったからといって，必ずしも明確なプロトタイプが存在するわけではないと思う.言い替えればプロトタイピング」と言うのは，開発手法として「明確な思想」を持っていて然るべきものであり，逆にその思想に従っている限り，必ずしも「プロトタイプ」を必要としないだろう.
このように少なくとも私にはこの二つの言葉はもの」と「手法 J とを表す明確に異なるものなのだが，それが意識されていない使われ方をかなり頻繁に耳にするのである.例えばプロトタイピングを作る J •「プロトタイプでやる」等々

後者はまだそれほどおかしくは感じられないのだが，それでもこれらの用法を採る人の意見を聞く時には，焦点を絞るのが難しいように思われる

つまり彼らの言う「プロトタイピング(

プロトタイプ)の問題点」とは，手法と試作物のどちらを指しているのかが全くわからなくなるためだ.
プロトタイプあるいはプロトタイピングという言葉が非常に一般的になってきた以上，まずこのあたりから押えていかなければならないと思う.

2.

有漂氏の分類に関して

2. 1

試作品/試用品

まず. PO l.l -04 で述べたよ うに，分類の用語としては用いたくない.もし使う場合は開発者が使 用して ，開発者が想定あるいは期待した性能を満たすことができるかを確認するためのプロトタイプ J / r 利用者に使わせて，利用者の要求が正しく反映されているかを確認するためのプロトタイプ」という分類ではなく，これら二つは「試作品」とし.

r(利用者に)使わせてみることによって.

(既出の要求の確認ではなく)これまで顕在化していなかった新たな要求を顕在化させるためのプロトタイプ」のみを「試用品」と呼びたい.しかしこれも適切だとは思えない.

つまり.もとの分類は利用者から見て J .単に作られただけか J / r 使 うことができたか」と いうだけの意味しか持たないように感じられ，分類としての意味があまりないため，上のような定義を持ち出したわ

けだ.しかし，もとの意味での「試用」の中からも新たな要求が顕在化することもあるし，言葉を涜用することは避けた方が好ましい . 従ってこのような意味で使うのであれば ， むしろ主目的によって明確に確認型
J/r 模索型」のよ うな言葉を 用いたい.

より適切な言葉はないだろうか.

2.2

使い捨て型/骨格塑

さて. P0 1. 1-04 で私は大きな誤解をしていたよ うだが ，これに関しては「骨格型」とい う言葉の選び方にも問題があるように思われる.ここは「拡張型 J のようなものにしていただきたかった.

もう一つ.何を捨てる / 捨てないといっているのかが良くわからないところも問題である.プロトタイプのソース・コードが少しでも残っていれば「使い捨て型」ではないように読みとれるが，一方，仕様からプログ

ラムが自動生成できるようなシステムは「骨格型」を支援するものであるようにも書かれている . この場合プロトタイプのソース・コード相当のものが，最終成果物に残っていることは少ない.これが「骨格型」である
こと自体にあまり違和感はないのだが，分類用語としての視点(基準)が良くわからない.

‑
3
0
‑

SeamailVol.4 , No.2・3

P
o
s
i
t
i
o
nPaper(P03.1 ・04)

ここには二つの視点が入り組んでいるようだ.つまり，捨てる/捨てないという視点と，本開発に入る前に行なう / 本開発自体を逐次開発的に行なうというような視点とが感じられる.必要があれば，別の言葉で分離させるか，より本質を明確にするような言葉で表したい .

2. 3

シミュレーション型/実環境墾

この言葉にも若干の疑問がある.これは「プロトタイビング周の簡易言語のようなものを用いるか J /r最終成果物と同じ言語 / 環境を用いるか」という様な意味合いだと考えられるが，実環境でもシミュレーション

は行なえるようにも思われるので，どうも落ち着かない .
ここでいうシミュレーションとは何だろうか.

2. 4

その他の分類

この他にもいくつかの視点を導入しなくてはならないのではなかろうか.例えば，同一マシン上で 4GL から 3GL に落して動かすような形態の時は，一体どのように分類すれば良いのだろうか.

この場合，シミュレーションも行なうような気がするし，実環境上で作成されると言えなくもないし使い捨て型 J / r 骨格型 J の分類上も問題がありそうだし ， 利用者が作成者だったりすることもある .

それでも

これはプロトタイビングの一つの典型のようにも恩われる . なかなか難しいものを感じる.

3.

方法論に聞してプ ロ トタイピングを考える上で，見過ごしてはならないのは方法論だと思う.ここで言ってるのは，教科書に載るようなきちんとしたものという意味ではなく，ある程度の方針 / 計画性がなくてはならないという意味である .計画性のないプロトタイピ ングがあまりにも多いような気がする .せめ て何のためにプロトタイ

ピングをするのか J .あるプ ロト タイプは具体的にはどういう目的のために作られたか J.それがどのように評 価され，どのよ うに反映されたか」程度はまとめられるものであって欲しい .

もう一つ.プロトタイプを「使い捨てにするつもりか J / r 核にするつもりか J というのは，かなり重要な方針だと思われる .

使い捨てるつもりで，なおかつ本当に使い捨てるのであれば，それは単なる仕様の確定であり，ある意味ではどのような作り方をしてもかまわないことになる.一方，核にするつもりであれば ， これは開発が始まっていることになるため，安易な「試み」はなるべく控えなくてはならない

適当でないものがそのまま最終成果物に残されてしまうことがあり得るからだ.
用語の定義とともに，いろいろな状況下における注意点 / 示唆なども徐々にためていくと面白いように感じ
る .
(たなか

‑
3
1
‑

しんいちろうSRA)SeamallVol.4 , N
o
.
2
‑
3

MeetingSummary(
P
0
3
.
*
‑
O
l
)

第 3 回プロトタイピング討論議事録
日時.昭和 63 年 9 月 7 日

場所

SRA

出席者:渡溢18:30~2300

3F
雄一(電力計算センター)

青島

近藤直文(ソフト工房)

茂(富士ゼロックス情報システム)塩谷和範 (S RA)

田中慎一郎 (S RA)

前回の集まりは，事例報告に終始し，本来の討論ができなかった.このため実質的には今回が討論第 2 回目
である.
さて今回はプロトタイピングに関する言葉の定義をする」ということになっていたが.そのあたりと関係して，一度有淳先生をおよびしてミニ・フォ ーラムでも開きたいという話もでた.また.プロトタイピング自体に関する捉え方などについても話が及んだが，時間の関係で充分には討論できなかった.次回に継続する.
以下ではこれら 3 点に関して，簡単にまとめてみる.

1.

ミニ・フォーラムに関して

1. 1

プロトタイピング・フォーラム

早急に我々なりの言葉の定義 / 解釈を行ない，

1 1 月のはじめ頃に有漂先生を招いてミニ・フォーラムを開催したい.長野支部などとも相談し，可能であれば合同で行ないたい.次団幹事会で佐藤千秋さんと相談し，受け入れ体制が固められれば，有漂先生に連絡をとってみる.

このフォーラムの結果を踏まえて，プロトタイビングに関するアンケート案を作成し，

1 1 月の環境ワーク

ショップで予備調査をする.

12 月中に本調査を行ない，

2 月中くらいにまとめ，その結果等を利用し，3 月頃に東京でフォーラムを開催したい.

{現設では十分な準備が出来そうもないので，フォーラムに闘しては-1!保留したい

9/9. 田中，

渡遺}1.2

O S 2 & L A N (もしくはJ'Cソヨンと LAN) フ才一ラム

9 月のデータ・ショウで，製品が出るようであれば，メーカの会員の方に相談し，

12 月あたりにフォーラムを聞きたい.

2.

有淳先生の周語に関する轟々の定義/解釈なるべくその言葉が示す本質的なところを取り出すこととし，それぞれの関連はまた別に考えることとした .
つまり試作型は使い捨て型であることが多い」と言った時点でその意味するところがぼやけてしまうので，これをできるだけ避けることとした.

2. 1

試作墾アロトタイプ{合意されたと恩われるもの}
試作型と試用型は，対立する概念ではない.

試作 / 試用の分類は，アプローチの決定にはあまり関係がない.
開発者による，開発者のためのプロトタイプ.
エンドユーザの要求を確認するために行なうのは試作ではない.

実現可能性の検討 / 最適仕様の選択/性能評価などに適用する{その他の関連意見}

モ ック・アップあるいはプレッドボードと呼ぴ，プ ロトタイプと明確に区別すべきで ないか.
プロトタイピングに対する考え方と関連する.

(近藤:

3 参照)

主目的によって，さらに確認型と模索(創造あるいは発見)型とにわかれるのではないか.

(つまり，分かっている(つもりの)要求を確認することが主目的か，何も分かっていないので(試行錯誤的に)要

‑
3
2
‑

SeamaﾟVol.4 , N
o
.
1
‑
3

M
e
e
t
i
n
gSummary(P03. 申 -01)

求を生み出すことが主目的か.

)むしろ試作 / 試用ではなく，その視点で分類した方がいいのではないか.

(田中)

2 . 2 試用型プロトタイプ(合意されたと恩われるもの}

開発者による，開発者と利用者との接点のためのプロトタイプ .
ユーザ要求の解釈の確認 / ユーザの潜在要求の発掘などに適用する.
{その他の関連意見)
このタイプがプロトタイビングの本質だと思う.

(近藤)

やはり主目的によって，確認型と模索(創造あるいは発見)型とにわかれるのではないか.

2. 3

(田中)

使い捨て塑プロトタイプ/骨格翌プロトタイプ{合意されたと思われるもの}

使い捨て型と骨格型は対立する概念であるから，どこで切り分けるかを明確にすればそれで良い.
「結果として 」使われたか / 使われなかったか，あるいは設計に影響を及ぼしたか / 及ぼさなかったかについては，この分類基礎とすべきでないはじめの目的がどうであったか」を輸にすべきである

使い捨て型は，再利用を「前提」としないプロトタイプ.
骨格型は，最終システムの一部となることを「前提」とするプロトタイプ.何らかの変換機能により目的プログラムを作成するケースも含める.
使い捨て型は，複数の実現案を早く速く安く作って，設計方針を固める必要がある時などに適用する.

骨格型は，基本的な設計方針が決まっていて.細部の調整等をする必要がある時などに適用する.
{その他の関連意見}「骨格型」という表現はあまり適当ではないように思われる.しかし新しい言葉を無閣に取り上げるべきでもないような気もする.

(核型の方が適当か? ?)この分類よりむしろ，見本型か / 核裂か，手動翻訳が必要か / 自動生成でき るか，というような分類の方が意味があるのではないか.

(近藤)

本開発前に行なうか / 本開発内で行なうかの分類ではどうか.

(田中)

使い捨て=本開発前 / 骨格=本開発内というようには分けられない.

2. 4

(塩谷)

シミュレーション霊プロトタイア/実環境翠プロトタイア{合意したと恩われるもの}

あいまいになるので笑環境 J というものをなるべく狭義に定義した方がいい.
実環境型は，最終システムを実現する環境と同一環境-同一言語を使用するプロトタイプ.
シミュレーション型は，実環境型でない全てのプロトタイプ

実環境型は，プロトタイピングのための環境が何もないような時，あるいはどうしても実環境でなければ目的が達成されない時などに適用する.

シミュレーション型は，条件を変えて実験をする / 性能面をシミュレートする / 独立なプロセスの協調としてモデル化する際などに適用する(この際，統計データの取得も可能)

3.

アロトタイピングとは何か.

これは今回のもともとのテーマではなかったが，一部言及されたので，簡単に記憶の範囲でまとめておく.
誤りがあれば全て田中の責任である.次回以降の討論で訂正願いたい.
(近藤)

ユーザの要求仕様とシステム作成者の設計仕様をつき合わせるための共通の土壌としてのプロトタイピング
が本来の定義.

つまり，ユーザの真の要求と作成者の理解との距離が大きいので，これをつめようとするのがプロトタイピ
ングであり.その意味で，開発者が自分のためにやるのはプロトタイピングではなく，ブレッド・ボードのよ

‑
3
3
‑

SeamallVol.4 , No.2・3

MeetlngSummary(
P
0
3
.
*
.
O
l
)

うな違う名前で呼ぶ方が好ましいと考える.
(渡漫)

ユーザの目の前で動かして見せられないようなケースでも，プロトタイピングと呼んでいいのか疑問.特にすぐ代替案が作れるようでないといけないのではないか .
(塩谷)

汎用機の世界でのプロトタイプはなかなかそういう風にはいかない.それでもパイロットシステムなどの作成がプロトタイピングでないとは思えない.ただし，代替案がいくつか用意できないようでは，適当ではない

と考える.
(青島)
プロトタイピングというものは. what に注目するもので，代替案云々はむしろ how であるから，それほど拘る必要はないのではないか.ただ. how のなしで what を語るのは自然ではないというだけではないか.
「物」がなければプロトタイビングではないのかというのは面白い問題ではある.
(田中)

P03.1‑04 )にあるが，プロトタイビングは手法として「明確な思想」を持っていなくてはな

今回のメモ(らないと思う .その「思想」がプロトタイビ ングであり.それにかなっていれば「物 J がなくてもプロトタイ
ピングだと思う.

その「思想」が何かというのはまだ良くわからないが，その根本はユーザとは打ち合せ / 確認を頻繁にしながら物作りをしなければいけない」というごくごく当り前のことではないだろうかと思う.今まではこれが難しかったのであまりやられていなかったが，ハードの進歩などによって次第にできるようになってきたのでよりうまくやるためには? J というような感じで「技法」として取り上げられるようになってきただけではないか.プロトタイプと同じで，物が出てきたので要求(理論?っ)も顕在化し始めたのではないかと思う.もちろんこれから成熟していくだろうが，この意味から手書きの画面イメージをユーザに見せながら打ち合せをするのもプロトタイビングだと思う.
(青島)
プロトタイビングによって扱われる物には.要求と作り方があって，その扱い方にはそれぞれ，
確認する
要求

明確にする

創造する
確認する
作り方

明確にする
創造する

ようなレベルがあるのではないか.このような分け方でもう少し考えてみたい .
{ここの表現に関しては. P03. ・ -02 (塩谷氏の覚書)も参照のこと}

4.

今後の予定，その他

次回は .1016
について J( 木)

18:30 から S R A 3F で開催予定.内容としてはプロト タイピングの指針 / 目的

.アプローチについて J.プロトタイプの評価基準 / 評価法」などについて検討するものとし，

この際，特に 3 であげた青島氏の提案を輸に考えてみることとする
また当議事録とは別に，塩谷氏が覚書 (P03 . ・ -02)

なお.

をまとめてくれたので，そちらも参照のこと.

9 / 30 までに田中まで届いたポジション・ぺーパに関しては，事前に全員に再配布する.在宅会員の方を含め，よろしくお願いする.
(記録:田中慎一郎)

.
3
4
.

M
e
e
t
i
n
gSummary(P03. ・ -02)

SeamaﾟVo1. 4, No.2・3

第 3 回プロトタイピング討論 (9月 7 日)の覚書
塩谷和範
言葉の解釈/定義
プロトタイプ"目的システムの一部または全部を表す模型または原形"
プロトタイピング"プロトタイプにより要求の確認/引き出しを繰り返し行なうことによって要求者の満足が得られるシステ
ムを作ろうとする手法"
試作(型)プロトタイピング"実現可能性の検討・最適仕様の選択 ・ 性能評価などのために開発者側で行なうプロトタイピング"
試用(型)プロトタイピング"ユーザ(要求者/使用者)側と開発者側の解釈の違いを埋めるため ・ ユーずの潜在要求を引き出すためにプ
ロトタイプをユーザに使ってもらうプロトタイピ ン グ手法"
使い捨て(型)プロトタイビング"再利用を前提とせず早く速く安く作るプロトタイビ ン グ手法"
骨格(型)プロトタイピング

拡張型(田中氏)/非使い捨て型(近藤氏)プロトタイビングの意味.

"成果物が目的システムの一部となることを前提にして行な う プロトタイピ ン グ"

これにはジェネレータなど何らかの変換機能を介して目的プログラムを成果物から生成するケースも含まれる.

笑環境(型)プロトタイビ ン グ"目的システムと同一実行環境を使用して行なうプロトタイビ ン グ"
シミュレーション(型)プロトタイピング"統計データの取得 ・ 性能要求の検証・さまざまな実験などを行なうためにシミュレータなどを使って実環境を疑似 (Simulate) して行なうプロトタイピ ン グ"

歩行可能要求仕様をプロトタイプとして実行させることも含む.
インタプリタ(型)プロトタイピング"イ ン タプリタを使用して統計データの取得などを行な う より柔軟なフ・ロトタイピ ン グ"
シミュレーション型に含む.
目的システム"プロトタイピングを通じて最終的に作成するシステム"
目的プログラム"目的システムを構成するプログラム"
プロトタイピングアアローチへのアアローチ

塩谷はプロトタイピングアプローチを検討するための切口として次のようなプロトタイピ ン グ手法の分類を行なってみた .

視点による分類:試作型/試用型

手段による分類:使い捨て型/骨格型(=非使い捨て/拡張型)
環境による分類:実環境型/シミュレーション型

‑
3
5
‑

SeamaﾟVol.4 , No.2・3

MeetingSummary(P03. 申 -02)

また，田中氏は試作型/試用型に替えて"確認型/模索型のような言葉を用いたい"と提案し，近藤氏もプロトタイ

ピング支掻環境を分類し"大規模開発環境型/道具箱型"及び従来手法との関連から構造的手法の補助手段型などの分類があることを指摘した.

またすでに田中・渡塗・近藤各氏は，各々ジョンソン ・松本 の次のようなプロトタイプの分類を紹介していた.
レベルによる分類(田中によるアレンジ):;実物大模型/模擬実行/動く模型/研究開発型

‑
‑J
.R.
J
o
h
n
s
o
n(日経コンビュータ 1984/2/6)
プロトタイピングパラダイム:シナリオ(紙芝居 )型/原版型/機能検証型 プロトタイプ
ー松本 (P02.1 ・ 51)

これらの分類及び前記の用語の定義はプロトタイピング手法を分類し，その意味を明らかにしようとする試み
であり，これによってプロトタイピング計画を立てる時の指針を得ることを目指した .

しかし全員で討論を重ねていくうちに，試作型/試用型プロトタイピングは対立概念ではないことが近藤氏により指摘され，有淳氏による 8種の分類はプロトタイピング手法を選択する際の指針としては有効ではないことがわかった.

そこで，青島氏により"要求の確定法/実現法の確定法"の組合せによる以下のような分類が提案されこれを検討することになった要求の確定法:発掘/明確/確認

実現法の確定法創造/明確/確認

なお討論を通じてプロトタイピングアプローチ(計画 )・ プロトタイプの評価基準/評価法なども重要であることが認識され，上記に加えて検討していくことになった.
また最終的には現実的なプロトタイピング手法・計画 ・ 評価基準などを確立していくことが必要であることが認識された.

(しおやかずのり)‑36‑

SeamailVo1. 4 , No.2・3

P
o
s
i
t
i
o
nPaper(P05.1 ・01)

プロトタイプについて
海尻賢二

まずは言い訳から:参加を表明しておきながら position paper は全 く書かず、おくられてくる資料も 忙しさにかまけてほおっておきました。

1 1 月になってようやく読んでみました 。

まずプロトタイプには関係あげませんが、環境という言葉について一言述べたいと思います。この 1 0 年程

環境をテーマに研究を進めてきましたが、(他の分野もそうかもしれませんが)環境というイメージも大幅に変わって来たようにおもいます.特に現実の大学教育の場にいますと、そのプログラミング環境は大きく変わってきています.

環境についても大学における理想的な環境と、企業に於ける環境とは違うでしょう。 ( programming-in -the-sm all と prog ramming -in-the-Iarge か)当然目的とするところも遣います.私の感覚はあくまで大学人としてのものであり、プロトタイプに関するいままでの議論も理解でき、そのような観点から考えていくことも可能ですが、いま一つ実感を持てま せん.

プロトタイプにつきましても p 03 .1-01で近藤さんが否定されているような意味でのものしか行っておりません 。 我々(私だけかも)が行なっているプロトタイピングとは、「アルゴリスムの現実問題への適用可能性をさぐるもの」とでも言ったらいいのでしょうか.我々はどこからかの要求があってソフトウェアを作るものではありません.ソフトウェア工学上の各種問題点を解決、または改良するためのモデルを考え、その現実問題への適用可能性を(デモとして示せるように)システムを試作(プロトタイプではない)します.

最近は少し(ソフトウェア工学を対象とした)エキスパートシステムにも頭をつっこんでいますが、これなども日本では典型的は試作のみで終っている例ではないでしょうか.ある人はこれを次の様に例えていました.

エキスパートシステムは鳥を作ろうとしている .アメ リカはカまかせでも ，鳥にみえるものを作る.しかし日本では M an Power が ないため最初から飛ばないことが分かっている鳥を作って満足していると.

けっして飛ばない鳥で満足しているわけではないのですが、色々な要素から飛ぶ烏に発展させる余裕が無い
わけです.

いままで行なわれている議論とほとんど関係のないはなし申し訳ありません.

1 1 月の神戸でのワーク ショ

ップには参 加の予定ですので 、全くな にも書かないと無視されるかとおもい 、感想を書きま した.

今後はできるだけコメント / 意見等を出していきたいと思いますので、宜しくお願い致します.

(かいじり

開37-

けんじ . 信州大学)

P
o
s
i
t
i
o
nPaper(P05.1 ・02)

SeamailVo1. 4 , N
o
.
2
‑
3

プロトタイピング討論会への論点、の整理
渡遺雄一

o.おことわり
この資料を早急に作ると宣言したにもかかわらず，たいへん遅れて申し訳ありません . 一応，

SIGENV@神戸のプ ロトタイピ ング討論会に 向けて，論点をも う 1 度整理するべく今までの資料をひっくり返してまとめてようと試みてみましたが，あえなく失敗しました.その罪滅ぼしというわけで，この間紹介した有津[ 1]から関連しそうなことを拾い集めて私見を述べることとします.

1 .有淳の主張のその後
前回の資料にも述べたが，有津[ 1]が出版されていた。それから我々の検討内容に密接に関係している部分を抜き書きする形で 5.
~5. 1

1 のみを(私見も含めて)整理してみた .

(()は波透が挿入した)

ソフトウェアプロトタイピングの背景

1)構造的な手法の欠点

1 ライフサイクルの発送はソフトウェア開発管理に都合の良いものであり ，開発自体〔特に生産性の向上〕に寄与していない

2 ライフサイクルの考え方では ，ユ ーザと開発者たちのコミュニケーショ ンの機会が要求分析の段階の初期から，受け入れテストの段階までの間，皆無に近い.

(中略)その結果，ユーザの真の要求を把握しないままでソフトウェア開発が進んでしまう恐れがある 。

3 ライフライクル方式は純粋にトップダウ ンであるため，重要な 判断を早い時点で下す必要があり，いったん高い水準で下した判断は，もし低い水準で不都合が生じても，修正することができないか，あるいは後戻りして修正するため時間と労力がかかる 。

4 (補足)ユーサ' の要求は要求書に書いである通りとは限らない.またユーザの要求は時間と共に変化していく.ライフライクルの考え方では，こうしたユーザの要求変化に追従することは極めて困難である。

これは 23の両方に関係しており ， 構造的なソフトウェア開発の最大の欠点である .
2) プロトタイプに関して

プロトタイプはシステムのもつ主要な機能だけを果たせばよく，データのエラーチェ ッ クや例外処理などは省いてもよい @ また実行速度については問題にせず，システム容量も実際より小さくてよい。いわは目標とするシステムのミニチュア版がプロトタイプである。

〔既存の工業製品での〕試作品は開発者の経験不足から生じる困難を解消することが目的である .

(後略(前略)ソフトウェアでも試作品作成の段階を明確に含めることにしようと考えたわけである.ここで作成した試作品がプロトタイフ・ (prototype) であり，これは最終製品を作る際には捨ててしまう . いわば使
い捨て，あるいは作り捨て (throw away) のプロトタイプ である.

( 試作品=使い捨て〕

食試作品プロトタイプ:-あまり時間や労力をかけず ， 短期間に速く作成すべき.長時間を費やすことは得策ではない

.r
a
p
i
dp
r
o
t
o
t
y
p
i
n
g
q
u
i
c
kp
r
o
t
o
t
y
p
i
n
g
-しかし〔時間を 気 にしていて〕あまりいいかげんな試作品では ，それを作ったことの意義が薄れてしまうため，適当なバランスが必要である.

(このための判断は逆に経験や勘によってしまう? !)・いかにしてソフトウェアを作ればよいかを調べるためのもの
食試用 品フ・ ロトタイプ :試作品プロトタイプを作ったとき，どのみち部分的な設計変更を行うのであるから ， そのプロトタイプ

をユーザに試用してもらって，ユーザからのフィードパ ッ クも含めた設計変更にすることを意図した・ソフトウェアの開発の比較的早期に行う必要がある 。 ユーサ.の潜在要求を設計に反映することがねらいである .

.e
a
r
l
yp
r
o
t
o
t
y
p
i
n
g

‑
3
8
‑

P
o
s
i
t
i
o
nPaper(P05.1・02)

S
e
a
m
a
i
lVo 1. 4, N
o
.
2
‑
3

-はやさの目安は，時期として 2 カ月以内，期間としては 3 週間いないといったところ
りは現場の状況と比較検討したい!

〔ここら当たJ・現実のプロトタイプによっては，試作品でもあり，また試用品としても役立てるという場合もある.
〔試作品と試用品は対立する概念ではない〕
・試用品としてのプロトタイプは，必ずしも使い捨てとは限らない。→骨格型
食骨格プロトタイプ:

プロトタイプを核としてそれに肉付けして，最終製品を仕上げることも可能である . このようなプロト
タイプを骨格プロトタイプあるいは単に骨格型とよぷ .

試作品プロトタイプが骨格型であることはほとんど考えられないが，試用品プロトタイプでは使い捨て型と骨格型のどちらもありうる .
食その他のプロトタイプ- ユーザとのインタフェースを適切に設計すの手段に限定したもの「言い訳プロトタイプ逃げ口上にプロトタイプとい う言葉をつかっている場合.いいかげんなソ
フトウェア
3) プロトタイプの実現方法について

試作型→実環境かそれに近い状態でプロトタイプを作成

試用型→まったく異なった環境に構築してもかまわない

作り捨て→最終製品と独立な環境でも作成可能

骨格型→最終製品と同じ環境か，それに近い環境で作成する必要あり

補足)

ソフトウェア開発のひとつの段階としてのプロトタイピングは，試作品としてのプロトタイプよりも，試用品としてのプロトタイプのほうがずっと意義が大きい 。 構造的なソフトウェア開発，あるし、はライフ
ライクルモデルでの欠陥である，ユーザの要求を的確に把握することのために，試用品プロトタイプは有力な方法である.これによってユーザからのフィードパックをソフトウェア開発段階に吸収できる。
私の感想:

前々回に議論し確認されたことが，簡潔な文章でより整理されていると思う。一部，頁数の関係のからか，
シミュレーション型や実環境型についてはプロトタイピングの実現という観点から数行述べてある程度で.

(有津自身も)特に重要な分類といて固執してはいないと思う 。

我々の討論で指摘されていたことは，いずれもこれら主張を補足する上での，重要な意味付けを与えるものであろう.だが，分類ということでは，理解するためのものでありプロトタイピングの指針 / 目的ア
プローチプロトタイプの評価基準 / 評価法」といった前々回の議事録の検討課題はそのまま放置されている.
そこで:

今回は特に PWB が tool展示であるので、塩谷さんにまず PWB の狙いを簡単に紹介していただいたあとで、PWB などのプロトタイプツールとしての印象を調べることを意図してアンケート用紙を作成することを主たる話題にしたいと思います.特に、 PWB を作成している立場からの「狙い期待する効果」が、初めてそのようなツールに接した人にも正しく受け入れられるであろうか?、また良い意味で正しい評価を受けてもらうために工夫するようなことは何かあるのか? 、 さらに他の様々な環境で仕事をしている人の考えているプロトタイピングやツールとこの PWB は方向性・考え方に大きなズレなどはないであろうか?といったことが得られるような問いかけができれば最高なのですが、 、、 :ー)【 参考文献 】[1]有津誠:ソフトウェア工学 ， 岩波コンビュータサイエンス，岩波書店. 1988
[2]田中:環境分科会議事録(第 3 回プロトタイピング討論
P 0 3. *ー o 1[3 ]塩谷:第 3 回プロトタイピング討論( 9 月 7 日)の覚書

P 0 3. *ー 02
(わたなべ

‑
3
9
‑

ゅういち:電力計算センター)

SeamaUVo1. 4 , N
o
.
2
‑
3

MeetingSummary(
P
0
5
.
*
‑
0
1
)

第 5 回プロトタイピング討論議事録
SIGENV@ 神戸

日時1 988 年 1 1 月 23 日(水

18

30~20

00

テーマ:プロトタイプとはつ

場

所:元町のうどんスキの中浜で!

出席者(敬称略塩谷，田中(慎)井川 (JIP)(SRA). 熊谷 (PFU).藤野 (FXIS).渡遜 (D C C) ほか多数

1 .は じめに
今回は，予定通り SIGENV@ 神戸ということで，いろいろな方と意 見 交換することが出来た。また環境

ワ ー クショップではツ ー ル展示もあり，別の意味で刺激的であった.結論から言えば「プロトタイピングは一筋縄にはいかないということが，色々な人の意見から分かった J ということになろうかと思う.以下では，記録係を名乗り出た渡迭の可能な範閤で印象的なことを書き綴る . 意見

解釈の食い違いなどもあろうが，取り敢えずここにまとめたので今後の意見交換のネタにでもなれば幸いである.なお会合はインフォーマルな形式で行われたこと，話題の傾向がそれぞれにおいて微妙に異なっていることなどから主な発言者の名前を勝手に掲げさせて頂いたことをお断りしておく.
[第 5 回討論となっておりますが，やはり問に一回プロトタイピング事例報告が入りましたので.実質討論としては 3 回 目になります.これら 2 回 の事例報告は，次回「プロトタイ ピ ング特集号(その 2)ていただきます .

(田中)

J で紹介させ]

2. プ ロ トタイピングと は ?

何故か鍋の具もほぼ片づいてきて，最後のうどんを入れょうかという頃になってきて，突然(いや必然的に?) f プ ロ トタイビングとは何か? A という議論が始まってしまった.只テ ー プを回すだけで(酔った勢いで)議論に参加してしまった記録係としては，お姐さんの声や鍋をつつく人を声の彼方から辛ろうじて聞こえてくる主役〔その実態は酒の席に似つかわぬ脇役? )の発言を苦労しておこすこととなった 。 結局大人数の(しかも酒が十分にはいった! )討論会の記録を取ろうなどということは無謀なことであり，それにアプロ ー チす
ることは悲惨であることがつくづく身に渉みた .

それにしても神戸説りのお姐さん声が中心的に録音されていたので，本当に悲惨だった .
まず SIGENV の今までの活動経緯〔特に有浮先生の本のことや言葉の定義を中心にプロトタイプについて考え直してきたことなど〕を田 中 さ ん が説明した.その後，参 加 者の 1 人の藤野さんから「プ ロ トタイピン

グは ，

まずその判断のための基準 (criter i a) をはっきり決めるべきである」という発言があり.以下ではそれについて議論している . みんなかなりお酒が入っているので，辛ろうじて討論内容が聞き取れる所から・

田中

c意見の遠いを明らかにしてから議論をするために)なるべく共通な言葉で話さないと，同じつもりで話していることが(実際には)違うことすら気付かないで話していることになるから，その“共通語"の 1 つとして有漂先生の本を読むことで，議論を詰めてきた

藤野 : ベ ー スがもともと違うのに(議論しでも噛み合わないのではつ)田中だからそれを 可 能にするために，個々の言葉について議論してみましようという・

渡透

だからその言葉について，現場の人聞が普段仕事をしながら考えているというか感じている気持ち(解釈)と，大学の人間である有浮先生などがイメージしていることとにズレがあるわけだから -田中:だから(そのような)つまらないような所から，やっていくしかないじゃないですか?
渡遺:例えばプ ロ トタイビングということについても色々な解釈があって，それをモ ッ クアップと呼べば良いという人もいるし-藤野 : モックアップと言う場合は ， オペレーショナルでないんじゃない
田中:だとすると，今，藤野さんはプロトタイプをオペレーショナルなものだと思っている訳でしょ.僕は必
ずしもそういう場合だけとは思わないもの藤野:エェ~!

オペレーショナルでないプロトタイピングなんて ・

田中 . 僕の主張は，プロトタイビングという言葉は，現象はどうであれ，その背後にプロトタイピングとしての何らかの思想があるか否かではないかということ.だからその思想がどんなものかを考えてみたいと思っている.でも，実際に行なわれる際の表現形はそれぞれに遣うものだと思う

‑
4
0
‑

M
e
e
t
i
n
gSummary(
P
0
5
.
*
.
0
1
)

SeamaUVol.4 , No.2・3

渡溢:オペレーショナルな情報をもっていなければいけない場合もあるかもしれないが，単に MM1 の情報を確認出来れば良いと思っている場合も少なくない

藤野:でもそれはオペレーショナルだよだって少なくとも，ある(ユーザからの入カといった)反応に対して-渡漫:それをオペレーショナルなアプローチとして，そのプロトタイプをインプリメントするかというのは，二の次の話でしょ!
藤野:えっ!

遣うじゃない田中:そうすると，今度は“オペレーショナル"という言葉の定義付けが違っているんですよ

藤野:オペレーショナルということは，操作出来るということで渡漫:だからそこまで進歩的な環境でなくとも，ある程度生産性に寄与するような(いわゆるモックアップ的な)アプローチは可能で・
藤野:それは(オペレーショナルでないからプロトタイプとして級うのは)おかしいョ

田中:じゃあ，例えば事務系のアプリケーションで.帳票なり画面なりに対して「これで良いですか? J といって，無意味なことかと言えば，そうじゃないでしょ?そしてそれをプロトタイプと考えちゃいけな
いか?といったら，非常に微妙なところでしょ?

藤野:だってそれは「貴方はこういう操作をしたら，これこれになりますが良いですか? J と言葉を使って操作して)いる訳でしょ?

田中・だってそこまで考えて，オペレーショナルという言葉を使っていれば話は別ですけれども

井川・それは (2 人の聞で考えている)オペレーショナルと言っている意味が遣うよ!
田中:そこまで言ってしまったら，オペレーショナルという言葉を使う必要性が全然ないんじゃないつ
藤野:ヱッ，どうして?

渡漫:通常オペレーショナルと言った場合は.

J SD のような記述言語があって，それによって操作されているというような状況を考えたくならない?

田中:どっちかというと.フォーマルスペック的な方向に行っちゃうでしょ，オペレーショナルという言葉を使うと藤野:違うよ.オペレーショナルというのはマニュピュレータと同じで，貴方はこうやったから(システムの動きは)こうなるのヨと教えてあげる ・田中 :だから，その言葉はどういう意味なのかなぁということを考えてみないと，話にならないでしょ，

といっている訳なのですよ

渡遺:例えば画面の 1 / 0 の確認の為に，ダミーのデータで良いからインプットを与えて，そのリアクション
が必ずしもあるとは限らないわけですよ藤野:でも，どういう形ですらアウトプットがあるわけでしょ ，

リアクションという言葉を使うからには.だって，入力があって何も状懸が変化しないというのは，異常なわけでしょ

渡漫:だから，ただ単に画面のデザインだけして，項目の位置がどうのこうのという場合もあるでしょ
藤野:いやそれはモックア ップ で(オペレーショナルなものでは無いから，それについては)プロトタイ
プと呼ぶべきじゃないよ

渡漫 : いや.だからモックアップも何も一緒にして「プロトタイプ」という言葉が走っちゃっているんだ
田中:僕が思うに，プロトタイプとプロトタイピングは違うわけだし

藤野 : いや，少なくともソフトウェアの場合は，プロトタイプとプロトタイピングは殆ど一致しているでしょ.
ユーサ'から見ればプロトタイプがあって，それを作ることがプロトタイピングでしょ
田中:いや，作ることがプロトタイピングではないと思うんですよ

藤野:僕に言わせると，プロトタイピングは.

(何からの明確なcriteriaがあって，その実現方法が分からな

かったり，あるいはそれをやった時の効果が分からない，という場合に，見えない部分があるから，この道はどう行ったら良いのかなあ，本当に(その先へ)行けるのかどうか分からないから，懐中電灯を照らしながら行って，駄目だったら戻りましょう，良かったらその道を行きましょうというのがプロト
タイビングだ.その道が抜けられるか抜けられないかの判断は

criteriaがはっきり定まっているから出来る話なのです

渡逮:いや，そういう場合もあるが.

(一方で)ユーザの仕様が不明確でそれらを確定させる為にやるプロト

タイプもあるでしょ藤野.それも同じで，ユーザの仕様を確認する criteriaがはっきり定まっているか否かの違いでしかない

田中

それは良く分かります.でも一緒くたにしてまずい事って，いっぱいあるでしょ

渡漫・実現方法は既に分かっているが. M M1 や，ちょっとした画面の推移が確定出来ないから，そのような

.
4
1
.

SeamallVol.4 , No.2・3

MeetlngSummary(
P
0
5
..
.
0
1
)

ものを確定させるためには・

藤野:ユーザとか自分たちとか分けるからおかしくなるんだよ
田中:え分けなければいけない所って多分にあるでしょ
藤野:遣うよだってプロトタイピングというのは criteria を設定して(プロトタイプ作成の)作業を進めるだけでしょ . それに対して評価をしながらチェ ッ クするとい う ことがプロトタイピ ン グでしょ田中:それはあまりにも自分中心的な考え方ではないですか?自分が分かっていることが，全て正しい情報
として，分析作業を進めることは凄く危険ではないです ?
藤野:自分の道が分からないときに，西も東も分からない時に.ただそこに黙って立っていても一行に問題の解決にはならない . だから場当たり的かもしれないが，しょうがないから行ってみて「あ~ダメだった.
じゃあ戻って別の道を進もう」と進むべき道を探すしかない.だから最初から criteriaすら分からないときにも.

1 つの仮想的 criteria を設けてそっちにぶつかってみようとする

田中:それがないときには.プロトタイピングと言うのは多分あまりにも間違っていると思 う
藤野:僕に言わせれば，プロトタイピングというのはたった 1 つで

criteriaの設定をきちんとしているか?

それに対する評価をきちんとフィードパ ッ クしているかということだけが問題なのだ

田中-その際にそれをどう設定するか?というのが出てこないとまずい.方法論なり何なりが出てこないとエンジニアリングという話に乗っからない
藤野:そう ，

それは大切よ. criteriaの設定が大切で，僕が常 々 不満に思っているのは，プロト タ イビ ン グについて. criteriaの設定について日本の場合にはほとんど皆な考えていないか ら 嫌いなのだ
田中:そこは(藤野さんの意見に)全く問題がないのだ

藤野:そのフィードパ ッ クのメカニズムが重要で，どの程度チェ 、ソクしてどうのこうのとい う ことをしないで，また最初から criteriaの設定すらしないで「これはプロトタイビングだ」などと言 う から嫌いなのだ
田中有淳先生の言うところの)r 言い訳プロトタイピ ン グ」ね(笑)

藤野: criteriaは変化しでも檎わないわけネ.一番初めの段階では自分の criteria はここでした . でも次の段階
ではこう移行しましたとはっきりさせれば問題ない

田中:そこは全く反論がないし，僕もそう思う
藤野:僕に言わせれば，ユーサ'だとかユーザの仕様の確認するためだとか ，

自分がアルゴリス' ムが分か ら なくて良いアルゴリズムを試すためだとか・

田中:でもこういう場合があるでしょ.ユーザ要求ははっきりしていて，ユーザ要求というのは早い話，外部仕様だから，こうなれば良いというのが書いてあったとして，それをど う 実現するか?というのが分からなくてやるプロトタイビ ン グというのがあるでしょ

藤野:それは，どう実現したら良いか分からないという，やり方を試してみたいということで，それは criteriaの質が違うだけで・
田中:だからその質が遣うから，その質の遣いに着目しなければいけないのでは ，とい う 議論をしている

藤野:僕は，前もってそのような criteria をきちんと設定しないこと自体が問題と主張している
田中:それは問題ですヨ.それは当然のようにしてです
藤野:でも ， 今まで(世間一般では)きちんと議論されていない で しょ田中:それは (S 1GENV の議論では)早い段階から批判として指摘されている.そんなものをプロトタイ
ピングと呼んで，学問的な級いをするのは間違っていると

藤野:ユーザ要求が明確でないとか，自分のインプリメ ン テーションのためにどうのこうのとい う ことは問題ではなくて・・・ . 例えばデータタイプが違うとかタイプの問題を議論しているよ う なレ ベ ルであって，それよりもっとデータタイプがあるとか必要だとかいう議論が重要なのと同じ田中

いや，そこまで認めたとして「あー，そうですね ， 良かったですね J で済ませる訳にいかなでしょ，という話をしている

藤野:だから僕は「その criteria をどうやって設定するか? J といったオペレーショ ン するためのとのためのメ
ソドロジー(方法論)というかフレームワーク(枠組み)みたいなものを考 え る方が先じゃないかと恩つ田中:だからそのことを議論しようとしているんですヨ
藤野:な~んだ . だった ら 同じじゃない笑)

田中:すごく感覚的に直観的にそうい う 風にやった方が良いにきま っ ている訳で，ただだか ら それをあまりにもいい加減にやりすぎたり.言い訳的にこれはあまり考 え ていないからプロト タ イプなんだとかいう行き方をしているのが現状だから，それは間違っていると思う

藤野:だからそこを「あんまり考えていなから」といってゴチャゴチャにしちゃうからイケナイ

.
4
2
.

自分の考え

MeetingSummary(POS..
.
0
1)

SeamailVo 1. 4 , No.2・3

がまとまらないことを，キチンとまとめるためにその方向づけをするために，

1 回は作 っ てみないと何が良くと何が惑いのか確かに分からないというのは(現 実 問題として)確かにあるんだもの

田中:それがはっきりしていれば良いんですヨ.分かっていないからやってみて・
渡遜 : 研究開発的な現場では，そういうことは許されるだろ う けれども，例えば実務的にあるものをイ ン プリ
メントしなければいけないと言う場合には，既に予算だとか納期だとかが決まっていである部分で妥協しなければいけないから ， ユーザから全部ニーズを言われても，ある部分では技術的に実現不可能であるから削らなければいけない.そういうような制限を，もし理想のプロトタイプツールがあったなら，
インプリメンテーションする時の実現性の条件として埋め込んでおいてやれば藤野:でも，それはプロトタイビングとは関係無くて.ただ設計とか requirement をどれだけ実 シ ステムとどれだけ近いところでやるのか?という，トレードオフをサポートするツールの話じゃないの?
田中:本当はそうなりますねェ.だけど・

藤野:それじゃプロトタイピングというのとは，やっぱり遺って・

田中:でも，両方とも考えなきゃいけないことじゃないですか?，現場に導入しようとした ら

藤野 : あくまでもトレードオフのディシジョン(判断)とい う のは，設計者の requiremen tation (要求分析)の(作り出した)仕稼として設計者が責任をとるべきであって，その為に(システム設計者が)自分がシミュレーションが必要だと思う人は，そのプロトタイプ使うか否かを判断すれば良い訳であって ， それ自身をプロトタイプの重要な要素と考えるのはおかしいのでは・

田中:勿論(そうだが) ，考えなきゃいけないことが一方向から考えていて宙に浮いてしまうよ う な話ばかりしていてもしょうがない，ということを言っている訳ですよ弁 )'1 :それはでも「誰かの requirement はいつも明確なものである J という前提に立っていません?現場から言えば「ユーザからの requirement というものは ， ほとんどいつも不明確なもの」なんですよねェ.
だからインプリメンテーションをユーサ'の SE がするようなものはプロトタイピングでないという意見だと思いますが，それだったらばユーサー の requirement は明確であれば確かにそ う ですけれど・
藤野:僕の言っているのはそうじゃなくて，トレードオフの責任というのは設計者にあるのであって・
田中藤野さんの言わんとしていることは)わかりますヨ . でも，それ(真の意味のプロトタイプツール)
を本当に使えるものとして，プロトタイピングの概念や方法論としてしっかりしたものを実際の開発の現場に持ち込もうとした時には，多分問題になるのは一番はそこ(トレードオフの責任を如何に軽減することを併せて支媛するということ)でしょ.そこをサポートする機能なりなんなりを(真の意味のプ
ロトタイビング支鑓織能と)いっしょにサポートしなければ導入しきれないでしょ!

藤野 : そうするとさあ，あなた方の言っているのは

requirement を作るときだけのrequirement-spec を作

る developer のトレードオフをサポートする為だけのツールとしてしか位置付けていないじゃない?

田中:要求仕様を作るために，プロトタイピングをすることは意味が無いと思いますよそこだけ』を考えるべきだなんでいっているわけではないですよ.

藤野:そうじゃなくて

requirement-spec を作る時に developer がトレードオフをディ シジ ョ ン (判断)しなくちゃいけない訳でしょ.そのサポートツールとしてとか捕らえていないんじゃないかと・

田中「そういう場合もありますよそういうことも考 え た方が良いですよ J といっているんですよそこ(トレードオフの判断材料)は関係ない話ですよ J と完全に切離してしまったら，(プロトタイピ ン

グツールとしては)いく ら 良いものでも結局使 え ないものなのではないだろ う か ?

藤野:だったら，そういうふ う にライフサイクルで言うところの，どのフェーズにいるのかによってプロトタ

イピングのタイプが遣うということならば，そのライフサイクルモデルと，対象であるのはユーザなのか自分たちであるのか， f!O ちインターナル(な利用)を考えているのか，より広範囲なものなのかを明
確にしなければならないのでは?
田中.それはそうだといっているんですよ?

藤野・でも ， そんな明確には言っていなかったじゃないだったら，ライフサイクルと各プロトタイプのタイ

プの聞にどんな相関があるのか明確になっていないじゃない(だからするべきじゃない? )少なくとも requirementのレベルで 一 番多いのは，トレードオフよりはシステムの分析してシステムを明確にす

ることのほうでしょ田中

そこはまたチヨ ッ ト違いますよ藤野 ・ エェどうして?

渡漫:だってオンライ ン のシステムなどでは.実現方法はほとんど確定しているけれども，そこでの MMI な

り画面の推移なり使い勝手を試そうと思ったらば，あくまで画面推移だけのプロトタイプの簡単なツールがあって，それで仕様が決まったならばゴリゴリ作りだせば良いじゃないという話があるじゃない.

.
4
3
.

SeamaUVol.4 , No.2・3

MeetingSummary(
P
0
5
.*
.
0
1
)

そこでの実現性のための環境は I 社の xxx とか F 社の yyy とか

藤野:えっ，そんな.それは仕様が明確になっているんじゃない.

F 社の yyy を使うとか.

DB/DC を使うとか渡漫 : でも現場では・

藤野:でもそれは，そこまで s p e c が明確になっているんだから

渡遜・でも，そういう所でも MMI の誤差は十分解消できる訳で・
藤野 . それはおかしいヨ!

渡漫・おかしいといったら(議論は)始まらないんで，そういう物をプロトタイプと言う人もいるわけだよ
藤野・それは構わない.それをそう呼ぶことに関しては.それには問題ないわけで，何故そのフェーズに限つてしまうの?

田中:限つてないですよそれも考えなきゃいけないそれも排除すべきではない」と言っているんです藤野 . さっきから言っているようにタイプ分けをちゃんとはっきりすべきじゃないの?
田中我々も)

r はっきりすべきだ」という主張をしているだけですよ・・

藤野:だっておかしいじゃない.さっき言っていた話では「ユーザの要求が明確でないために requirementspec を定義する場合で.そのトレードオフを決定する為に必要だ」と言っている訳でしょ?
田中その場合だけに固定している訳ではないという意味で)そこは遣うじゃない
熊谷:そういう場合“も"あるんだ田中:ユーザの要求をいつくら明確にしても，たとえユーザが本当にやりたいことはこうですよと明確になったとしても「これを実現するのにいくら機械がかかってどれくらい金がかかりますよ」といったら，ユーザはそんなものを作ってもらっても困るという場合もあるでしょう

藤野:そういうタイプのものがあって.もう一つはインターナルにデザイナー(システム設計者)が(システムの)デザイン・デシジョンする時に，トレードオフをするために自分自身のデシジョン決定の必要なもの(プロトタイプツール)があるでしょ!

田中:そういうものも“ある"という話をしているんです .

“ある"はずなのに，そこを明確にしないで，プロトタイビングなりプロトタイプなりみたいな話で言ってしまっているからいけない . プロトタイプと言われているものの中にも(様々あって) .プロトタイビングの検討にしっかり沿ったものと，単にそれ以前に「データ収集をしたいからその(目的に合うような)テストツールみたいなものを作ってそれを使ってデータを取りたいよ」というような物も，今ではプロトタイピングと呼んじゃっている訳です
ヨ(だから問題だと思っている)

藤野-少なくとも，さっき言ったように形式(タイプ)を明確に分けるつもりであれば，そのフェーズみたいな形で考えていくか，あと 1 つはそのプロトタイプを使って，その結果 (output) を必要とする人は誰なのか?ということをはっきりさせるべきではないか?

田中.現状を言うと，それ(藤野さんの指摘した場合分け)を考えるときに「自分の言葉だけで話をしていても，話が通じなくなるから 1 つあの有淳先生の(本で述べられている)言葉から入ってみよう」と進めてきた.それに対して一応，その言葉使いなりおかしな(矛盾)点が整理出来たところで，それと今の(藤野さんの指摘してくれたような本質的な問題)ところまで辿り着いていないのですよ.だから(その方向で)やらなきゃいけないという話は出ていて，一歩一歩それに向かつて進んでいる段階だと思って頂ければ良い

渡漫:だから今，藤野さんの話してくれたような(本質的な)プロトタイプの話をもっと聞きたい訳なのですよ田中:ただそこを一気に解決出来ないし-・・.また(有淳先生の本は)そういう視点でものを見ていないんですよネ!

渡遁:あれは研究者の立場でこれは試作型」だとか「試用型」だとか言っているにしか過ぎなくて.

(目

的と対するプロトタイプを)作る前の段階でそれが分かったら.それは理想な訳だけれど，それを分かるためにはどうしたら良いのかといった「工学的」な裏付けが(まだ現状では)無いわけなのです

田中.だから今出ている結論の 1 つとしては.

( :有淳先生の本のプロトタイプに関する)分類の仕方というのはプロトタイプとは何なのか?どういう物なのか? J ということをイメージを持つ為にはとっても良いものではあるけれども ・

渡漫:だからまったくプロトタイビングを理解していない人に「ああゅう考え方もありますこうゅう考え方もあります」と説明する場合は良いのだけれども，それらを予備知識として持った人か，これからプ
ロトタイピングをどう進めていったら良いのかと考える際に，また実践的にプロトタイピ ン グを進めて行くうえで「使い分けて」いくための場合分けでは無いことがどうもはっきりした訳

.
4
4
.

MeetingSummary(
P
0
5
.*
‑
0
1
)

SeamanVo1. 4 , No.2・3

田中:だから色々な(場合分けに関する)言葉があるのだけれども.それぞれがきっちりと(明確に)切れているわけでは無くて，微妙に重複している-

藤野:僕にはどうも ， みんなが話していることが.どうもプロトタイプを本末転倒をしているように思える.
何故なら“プロトタイピング"というのはあくまでも『手段』でしょ渡溢 . プロトタイピングは手段ですね

藤野:プロトタイプというのは，プロトタイピングするためのアウトプットでしょ?
渡遺:アウトプットというか.必ずしもアウトプットだけではなくて ・.

藤野それは)嘘だよ何故なら) r プロトタイピングする」ということは，さっきも言ったように，
criteria と比較評価して，そのフィードパックで新しい情報を二次的に得なくちゃならないんだ.それを確定するための行為で・

渡漫:そういう意味でアウトプットだけれども，そのアウトプットが，常にその実際の本番システムと作成作
業と・〔注:ここで“アウトプット"という言葉に関して誤解が発生していることは.賢明な読者諸兄はもうお気付きであろう.藤野さんは，プロトタイビングという 1 つのプロセスで得られる情報を総称して言っているのに対し，波遣の方は 1 つの帳棄のような物のイメージを持って話をしている〕

藤野:だからそれがおかしいんだって.プロトタイプとツールと一緒に考えるからおかしいんだって.もっと大切なのはデザイナというシステムディベロップメントを進めていく人が，どこでどういうトレードオ
フの判断(ディシジョン)をすべきか?とい う 話なんだよねえ.一番大切なのは，デサ' イナがシステム開発の際に「どこでどういう判断をしたか? J ということであって，その判断をサポートするためのツールとしてプロトタイピングとかプロトタイプを使ってフィードパックの情報を得る，という，つまり判断をするためのより良い確実な情報が欲しくて，そのプロトタイピングを使うか使わないかも，判断としてはまず開発者(ディペロッパ)の，まず最初のメタな判断な訳なんだよねえ. (システムを設定していく上での)情報が足りないから，この情報はプロトタイピングをすれば得られるのじゃあないか?と思って働き鈴けるのであって・ ・ ・.そのよう動機付け(モチベイション)が先にあって，その動機付けがあるということは，さきにこうしたいとい う 評価基準が先にあって(プロトタイピングということを)やっているはずなんだよネ

田中:仮のものでも(あらかじめ評価の対象として)置かなければ意味が無いと思いますよ . それがなければいけないというのは私はそ う 思うし，皆もそれで問題ないんじゃないですか?

藤野

そしたなら，その方向でずっと考えていけば，プロトタイピングが r~ 型」とい う のは殆ど関係ないんじゃない?

田中:それは，そう納得してしまったら.何にもならないんじゃない.つまり藤野さんの言ったことを ， 何か
らの形で(より具体的な)モデル化をしなければ何にもならないでしょ藤野:僕がもしモデル化するのであれば，今言ったようにそういう形で・
田中そういう形 J というのは，それは抽象的過ぎるじゃない

藤野 : そうでもないじゃない.さっき言ったようにフェーズで(プロトタイプの)タイプ分けをすれば良いじゃない

田中 : だからそういうことを言っているんです.だからどういう風に分けたら良いのか?ということを(議論して)やっている段階なのですよ藤野:少なくともウォータフォール・モデルが良いにしろ悪いにしろ ， ソフトウェアのライフサイクルが繰り返されるよ う に各工程が繰り返されることを前提としたとしても，少なくとも要求( r
e
q
u
i
r
e
m
e
n
t
)の確認をしたい 』 のか，それとも『設計段階での実現の為に，どっちの方向に行ったら良いのか分からなくて(プロトタイピングを)やる』というのと 2 通りがあるよねェ.それをウォータフォール・モ
デルのように，最初から固い殺のような枠組みで考えるのではなくて，繰り返しをすることによって ・

田中:だからそういうことを言っているつもりなんですが，どこが遣うのですか?だから(議論が)そこまで至っていないだけで，本当にやりたいのはそこ(藤野さんがいったようなことをきちんと整理すること)なんですよネ
藤野 : だからやれば(笑い)

田中 : そう言っても ， いきなり「やろう」といっても出来ないでしょ

藤野:それだったら ， プロトタイピ ン グの本なんか読まないで，もっと自分たちでフェーズとはどういう物なのか，どこでど う いう(プロトタイピ ン グに関する)一般的な捕らえ方をしているのか，ど う いうシス
テム設計の判断が行われているのかを

‑
4
5
‑

SeamaUVo1. 4 , N
o
.
2
‑
3

MeetingSu皿mary (POS. 申 -01)

井 J iI :それはやっぱり(議論として)偏りすぎますよ

藤野:ええ，そう?

井川:やっぱり自分たちとは距磁をおいたものをサンプルに取り上げるなら，それは正攻法だと思いますが，「自分たちが論じているものが何か? J ということを客観的に見るということは，自分違と距離のあるものを評価をして，そしてそれに対して自分の立場(スタ ン ス)を明確にすることが出来るかということだと思いますが藤野:でも(さきほどまで自分の主張していたことが)大切だということは ， はっきりさせるべきだと思いますよ田中

だから一つには，先ほどいったアンケートを配ってみよ う というのは.もろ現場の方から(プロトタイ
ピングについて)攻めてみたいということなのです.またそれとは別に(ソフトウェア工学などの多少理論的な)お話のほうから攻めたいネという状況なのです.だからやれば良いという(藤野さんの主張や)分からないわけではないが，そこを考えていくと，いきなり沢山のことを考えなければならなくなって，収拾がつかないでしょ.やっぱり 1 つづっ

1 つづっ，積み重ねていかなければな ら ない訳だか

ら，どの辺から当たりをつけていくか?という話なわけです

藤野:だから ， さっき言ったようにフェーズ分けをして，トレードオフとか ， そのディ シ ジョンされている所に焦点をあてて田中 : そうすると，その(そのような議論のための)叩き台が簡単に作れるか?とい う と凄 く 難しいでしょ?

「誰かチヨットやってみてヨ! J などと気軽に言えないでしょ.そうするとそこからはやれないことになってしまうのですよ . そうすると，いままで研究者が既にやっていた所から入っていくのは，取り合
えずのとっかかりとして仕方のないことだと思うんです.やっぱり基礎の無い所に，いきなり物を建てようとしてもどうしようも無いでしょっ.で，感覚的に「そうだなあ」と思っても，じゃあ何処からとっかかりを付けようとしても，どうしようも無いのですよ藤野:ソフトウェア・エンジニアリングの無い所で ， プロトタイピ ン グを論じても何も意味が無いと思うけど
田中 . でも今の日本の現状って，まさしくその通りでしょ藤野:やっぱりそうか全員笑い)

田中:だってプロトタイビング」とか「プロトタイプ」とか言う場合，殆どの場合は適当に作ってしまったから「これはプロトタイプだ」と言うのがほとんどでしょ渡漫:プログラムを作ったことの無い人が管理職をやっている(現場の)現状からするとそれは当たり前でしょ(笑い)

[かくして議論( ? ?)は続き，このあと近くのビサ。屋，田中の部屋，と渡りあるいたのですが，話は一向に収束しません.翌日藤野さんは風邪をひいてしまうし

いやあ，どうも済みませんでした.でも藤野さん，この話どこかでまとめて話してくれません? ?田中) ][因みにここの店の勘定はワリカ ン で 4 10 0 円也でした(渡遁) ]3 _おわりにかえてこの記録がどの程度の出来であるかについては，それぞれのミーティングに参加していた人の評価を得なければならないが，決して十分な記録が出来ているわけではないと深く反省している . どうも酒もはいる所での討論会には，絶対にテーフ・ を持ち込まなければダメそうである .

(酒を飲まずに記録などしているのが馬鹿らしくなるし，またそのような場のほうが参加者の本音の意見が早口でパシパシと出てきて面白いからつい自分も参加してしまうので・・・ )(記録:渡遺雄一)

‑
4
6
‑

S
e
a
m
a
i
lVol.4 , No.2・3

SIGENV‑Forum@MORIOKA

SIGENV-Forum@MORIOKA 顛末記
世話人代表:
1.

田中

慎一郎

はじめに

去る 3 月 4 日(土) .分科会レベルではおそらく初めてと思われる『ミニ・フォーラムの地方開催』という無謀な試みを行なってしまいました.どのくらい無謀であったかというと，関係者みんなが『実にいい経験をした』と思えるほどの無謀さでありました.この『いい経験』を記録に残しておかないと次回(あるいは他の分科会の)ためにならないということで .
フォーラムの本質とは関係のないところを中心に，ことの顛末を書き記してみます.

2.

企画についてそもそもこの企画はスキーにいきたい』という非常に『純粋な 』 動機に端を発するものでありました . つまりど

うせこのメンバでスキーにいくんなら，ついて'になんかやってみてもいいんじゃない」という感じで始まってしまったわけ
です.この発言自体は，はるか昭和の昔から出ていた話ではあったのですが，具体化に向けてことを起こしたのはなんと平成元年も 2 月にはいってからでありました .
企画が遅かったのですから，開催日程も遅くすれば良さそうなものなのですが，そこはそれから

r 今年は暖冬』であります

r スキーに行く 』 という第ーの行動原理に矛盾をきたすわけです.さて，そんなこんなで『各人の都合がつく範囲でもっとも早い金昭臼か土曜日』という条件だけを考えて.

3 月 4 日(土)という日程が決定したのでありました.

(賢明な読者はこの日程を聞いて，何が起こったかすでにおわかりでしょう. • • )3.

宿がとれない.

.

さてきて，無事チラシも作って会員に配り，さらには非会員の DM リストから東北地方の人を選び出してこれにも配り，『会場もス ピーカも OK . 宿は参加者が勝手にとる事にしたからこれで万全 .4 日の夜は市内に泊ま って.朝スキ ー場に移動だ.さあて一番繁華街に近いホテルはどこかな』っと，盛岡の人に紹介してもらったリストを見ながらもう一人の世話人が受話器をとる.一軒目，二軒目.

.. ちょっと不安がよぎる.十軒目，十一軒目宿がとれない! A .そう，何と 3 月 5 日というのは岩手大学の入試の日なのでありました

さあ大変.時刻表の後ろを見たりして何とか捜し当てたのがパス / トイレ別，ツイン 2 つのシングル 1 つ』という発表者人数丁度の部屋数.他が全て満室なのに空いているという事実と合わせてなんとなく不気味さが漂っている.それでもないよりはまだましと，とりあえずその数だけ押えて，他をあたったのであります.何しろ空いているホテルを見つけなけ

れば，宿泊を必要とする人に紹介もできない始末.しかもこの時点、ですでに，結果としては東京からの唯一の一般参加者シ
スプランの後藤さ んの申込があったのです .
さてさて，この電話問い合わせは延々と続きまして，ついにはホテルカイドまて。買いに行って 30 軒近くのホテルに電話をする事になるのでしたが，全てダメという悲惨な結果が待っているだけなのでした . まあ，最終的には先にビジネスホテ
ルにもう少し空きがあるということが判明し，ことなきを得ましたが，冷汗ものです.

(後で聞いたところによると，そのころ先の後藤さんは 50 軒目の宿に断られていたということでした . )教調:

4.

楽をしようとすると，かえって大変になる.

こ~ゆ~ことも.

時間は少しさかのぼるのですが，他の連絡のついでに他のメンバにホテルの状況を連絡すると高めのホテルならとれるんじゃない ?J という声ちょっとやってみるから』との意見に待つこと 5 分

r6 人分とれたよ場所がよくわかんないから. FAX 送ってもらうことにした.また連絡するから. J
10 分ほどして連絡があり，そこで場所を確認した私は，その近辺の宿は全て塞がっているのに，なぜそこだけ. • .とちょっと疑問に思いました.
F3 月 4 自の土曜日とってくれたんですよねえ . Jl『 えっ.

3 月 3 日の土曜日でしょ ?Ar

土曜日は 4 日ですけど.

..J

もしこの会話がなかったら，盛岡の夜を楽しもうと考えていた男 6 人が，盛岡の夜を楽しく走り回っていたことだけは間違いありません.暖冬とはいえ，北の国の夜はやっぱり寒かった.

5.

• . 危ない，危ない.

スキーは??

さてさて，この手の話はこれで終るわけではありませんスキーをやるんだ』と盛り上がっていた割には，スキー場に詳しいやつがいなかったりするわけです.
『安比でいいんじゃあないつ』

‑
4
7
‑

SeamaHVo1. 4, No.2・3

SIGENV・Forum@MORIOKA『ホテルはいっぱいだった.東八幡平だったらあるけどどうなのかな ?Jなどと暢気なことをいっていたのが 2 月の 23 日の木曜日.その週末には結構雪が降ったようで市内でも積雪 26 センチ』という情報を聞いて大事ぴで，月曜日を休んでまでスキーをする意思のあるものを確定して，やっと予約の電話なぞするわけです.

え~ところが雪が降ったのを聞いてスキーをする気になるのは何も私らに限るわけではないようで，くだんのホテルはすでにいっぱい.幸い比較的近くの『プータロ一村』というところがとれまして，しかもこれがこの展開からは考えられな
いくらいの『あたり』だったのと.盛岡の方々が車を出してくれて 5 日には安比で存分に滑べれたのが今回の企画の数少ない救いでした.

何しろ f26 センチのドカ雪』はそのすぐ後の『ドカ雨』で全て消えてしまったそうですし，さらに許し競いことには，

4 日夜にはスキー場まで全面雨が降ってしまって，私らの滑べったのはすでに本来の『岩手の雪』ではなかったのだそうな
のです.

6.

新幹穫にのってきて，フォーラム当日.上野朝 9 時発という『早朝』にも関わらず，乗る予定の人聞はみんな揃って一安心.今日使う O
HP を作らなくてはとビールを欽みながら考えていると，車内検札がやってきました.丁度真中近くの車両だった為に，車両の後ろから来た車場t と，前から来た車掌が出会うところのようでした.
前から来た車掌にドアの付近でさっきからウロチョロしていた若いのが話かけました.
『済みません.指定席空いてませんか ?J

『座りたいの?

じゃあこの空いているところに座って.券持っている人が来るまでね.はい切符見せて. J『はい . J

あ れ? ? あんた指定とってるじゃない.

r

...J

そのころ後ろから来た車掌が中ほどの席のオバタリアンと話をしていました.
『さっき.自分の席がここだという人が来てね.

.• J『はは.車両の間違いですか ?J『それが車両も席もあっててね.ちゃんと 9 時発のやまびこ 37 なんだけど，そ~ゆ~こと つであるのねr

そうですか. .. 普通そういうことはないんですけどねえ. . 変だなあ. ..

まあ切符見せて下さい. .

あれ~，これ，日月日の指定券ですよ. .• J

車両の間違い，列車の間違い，色々と実際にでくわしもしましたが，日にち遣いというのはさすがに初めてでした.しかも間違っている方が正しい方を追い返しちゃうなんてのは. ..

いやいやいい経験をさせていただいた.

まあこちらのホテル騒動も人のことをいえた義理ではありませんが. .

7.

生うに弁

さてさて，盛岡に着いてしまった以上，多少時期はずれだろうと何であろうと生うに井』を食べなければいけません.
ちょうど昼過ぎに盛岡駅におりたった我々は，前日の夜行で発ったメンバと合流し，早速駅ビルの地下にある店に直行したのであります.ところがところが，喜び勇んで出かけていった我々が見たものは，うまそうな『生うに弁』のサンプルと.

裏がえった料金表だったのであります . 夜行メンバが言うには.つい先ほど我々を向かえに来る前までは表だったそうなのだが. .. ことほどさようについていないのでありました.
開くところによると，この時期はもう盛岡ではうには取れず.北海道でしか取っていないとか . それも全体の一割くらいしか身がないということです.駅で食おうとかいう方はご注意のほどを. .

8.

さてフ才一ラム

うに弁を食うことが出来なかった我々は，カキフライ定食(生ガキ，椀付き 980 円，安い. )なぞを食い，あわててフォーラム会場に向かったのであります

1 時の約束だったのに 1 時半にならんとしていたので ，ほとんどの準備は岩手の方が済ませてくださっていました.どうも申し訳ありませんでした.
フォーラムの内容は別途報告書が出る予定ですので省略いたしますが，話題提供者を含めて総勢 21 名.

SEA 入会者も2 名出るなど，なかなかの成功と言えるものとなりました.しかし，皆が皆『話すことがあまりないなあ.時間が余ったらどうしよう. J などと言いながら予定をオーバーしまくりましたので，何と討論の時聞がほとんど取れないという不満もち
ょっと残ったりしたことも事実です来年』はこのあたりも気を付けなければ. ..

9.

商都百量生屋

さて. 2 時から 5 時半までの予定ではじめたフォーラムも.何だかんだで 7 時過ぎまでかかってしまいました.その後も，

一部のメンバが代表でチェ ック・インにいっている聞も非公式で続けられ. 9 時前にしてようやく夜の町へ出かけることに
あいなりました.

‑
4
8
‑

o
.
2
‑
3
SeamaﾟVol.4 , N

SIGENV‑Forum@MORIOKA『いかの一本づけが食いたい 』 という主張が通り，南部百姓屋という店につれていっていただきました.席に付くやいなや，ビール好きの メンバが 『 とりあえずビール 10 本 J . 13 人の席にビーlレ 10 本は喉をうるおす量としてはちょっと多かったので ， ここで酒を飲むために必死にビールを片付けるという作業が始まるのでした.しかし，いかの一本づけにボラとアイナメの刺身，• • . というつまみにではどうしても酒が飲みたい私は，まずビールを片付け，吟醸古酒を一杯たのみ . 生酒に移るころには，いつものように睡魔に襲われていたのでありました.

.

(次の日にずいぶんと私の食えなかったものの名前を聞いたような気がする . ..)

10̲

食堂園

一度寝てしまったからと~，ってそこで終りにならない私は，南部百姓屋をあがる時に起こされると，すかさず 『 冷麺が食いたい 』 と主張したのであります.もうろうとした意識の中でも，しっかりと r 特辛 』 を注文した私は ， 冷麺が来るまで引き続いて一眠りし，..たのでありますが，覚えているのは，最初に一口食って 『 うまい 』 と思ったのと，最後に麺を探っていたのと，金を払ったところだけという，見事にポイントを押えているというか ， 良くわけのわからないというか，まあ
いつものことだったのでありました.

(一言弁明しておくならば，これは酔っ払って覚えていないのではなく，限ってしまって覚えていないのであります.通常

眠る直前の記憶はかなり鮮明な方ですので，どうやら今回はほとんど限りながら冷麺を食ったようでありました. )1 1.

r さあみんなで滑べろう- ‑J

さて，いよいよ噂の 『 パス / トイレ JJIJ J のホテルへとたどり着きました.既に 1 1 時をちょっとまわっていたので.風呂には入ることができませんでしたが，今思えば，どんな風呂であったか見ておくべきでした.しかし思っていたよりもこぎ

れいなところで，ちょっとした研修宿泊施設といった 雰囲気のところでありました . ただ本来はシ ン グルで 4000 円たらずとガイドブックに出ていたのですが，ツインで 1 部屋 9000 円と，受験日値段になっていたようでした.おそらくは部
屋も，入っていた机をどけて，無理矢理ツインにしたのではないかと思います .
他の人は知りませんが.既に酔っていた(眠っていた? ?)私はす ぐ に眠りにつきました . 同室の人聞が 7 時に部屋の目覚しをセ ッ トしたのですが，デジタルであったため，何と夜 7 時にセ ッ トされており.まったく役にたちませんでした . ただ私はとってもとっても良く限ったので， JJIJ に何の問題もありませんでした.はい.
朝，水分を求めて部屋の外へ出ると，ホテルの入口脇の食堂は受験生らしき若者で溢れておりました.決して彼らが悪いわけではありませんが . ホテル騒動で大変だった私は，スキーの身支度を整えて再ひ'その前に立っと.上のセリフを大声でr さあみんなで. ..J .

叫びたい衝動にかられたのでありました

12.

安比高原へ

臼曜日は，岩手の方々の車に分乗させていただいて安比高原へと向か う ことになっておりました . 車のトランクに荷物をつめていると ， 一人が帽子と手袋を手に持って立っていました.ちょっと勘違いした私はあわてて帽子を取り出そうとしました.
『 あっ ， いけね，帽子出さなきゃ』『 大丈夫だよ.おれはあとでスキー靴出さなきゃいけないんだから. J『 ああそうか . A
するとドライパーの岩手の方が言いました .

『 あっ，いけない . 靴忘れちゃった. Jということで，我々は彼の家経由で，一路(? ? )安比高原へと向かったのであります.

13̲

貸スキー

やってきました ， 天下の安比高原.はっきりいって，ばかでっかいとしか言いようのない駐車場 (7000 台収容)とス
キーセ ン ター(貸スキー 1025 台保有他)が出迎えて く れました . しかし今年の雪不足は相当なもので，何とスキー場の駐車場にも雪が全くないという惨状.このドロドロにぬかった駐車場に止められた車は.とてもスキー帰りとは信じてもら
えないことでしょう .

さて私他 2 名は，今回は貸スキーですませてしまおうと考えていたもので，早速スキーを借りに出かけました.と，そこには田舎ものにはとても新鮮な風景が展開されておりました.オープ ン ・マーケ ッ ト方式とかいうようですが，なまじっかなスキー売場には負けていない量の，スキー ， 靴，ストックがズラ ッ と並ん でいたのです.
さて，まず一体どうしたらスキーが借り ら れるのか. ..

ここから始まってしまいます . 人を待たせていることも忘れて，感心しながらボー ッ と見ていると，どうやら入口に近いところの人だかりが申し込みのものらしいということがわかりました.そこでは，名前，住所，身長，体重 ， スキーレベル，板の長さ，靴の大きさ，ストックの長さ， ..

とい う 用なものを記入させられたあと，身分証明になるものを取り上げられました . 次に，その用紙を持ってずず っ と奥へ行き，自分で靴を履いてみて，その辺にあるいている兄ちゃんに良さそうなものを示すと，そこで靴にふつであるナンバーを記入され

‑
4
9
‑

SeamaUVo1. 4, No.2・3

SIGENV‑Forum@MORIOKA

ます.そのあとスキーのあるところにいって同じように選び，それを持ってドライパーを持っているおっちゃんのところへと進んでいくのでした.

いまではこういうところが多いのかもしれませんが，私は初めてだったのでなかなか混乱してしまいました

良く考えれば，せっかく選べるのですから，もっと真剣にスキーを選べば良かったのですが，そのときは全 く気 がつかず，一番近 く にあったものを選んでいました.ううむ.ちっとも仕組みが生かされていない .

1 4̲

リフト 券

ここはリフト券も r 新方式 』 だそうで，1 日券は裏がシ ールとなっており，これを二つ折にして ， フ ァ スナーの穴に通した針金を挟み込むようになっておりました . ホルダーがいらないので.便利といえば便利なのですが ， ど う にもこれが値札に見えて仕方がありません . 3500 円で売りに出されているような気がしてならないので，しばし考えた末 ， 手持ちのホルダー に入れ てしまうことにしました

ゲレンデに出てみると ， 多くの人はやはり手持ちのホル ダーに入れて使っておりました.まっ，新方式なんてものはどこでもそんなものです .

15̲

ゲレ ン デゲレンデは広い，というよりも 1 本が非常に長いという印象を受けました . また，今回は雪質が悪か ったせいか，はたま
た東京の 田舎もんが大挙して押し寄せるにはちょっと遠いせいか ， 我々にとってはかなりすいているとい う 感じでした . 何というか，

1 本のリフトに柱が 2 5 ~6 本あるという感じで ， 実際かなり長い.ぺアリフトがほとんどなので，女の子とでも乗り合わせて話でもしていればす ぐですが.結構すいているので慣れていないと一人になります.またやっぱり誰でもいいというわけではないですし .

. 途中リフトから落ちた女の子がいたそ う ですが ， 目撃者によると『きっと隣のおっさん..J ということでしたので，きっと 向 こうもそう考えていることでしょう . しかしリフト待ちがほとんどないので，結構ご機嫌に(気分だけは. .)滑べることができました.ただ，午前 中 はまだしも，午後も 3 時頃になると早くもガが手を .

チガチの斜面 になってしまい，地元の人もせっかく来たのに残念ですねといっていました来年』はきっともっといい 雪
で滑べることができるでしょう .

16̲

アータロ一村

色々あって，安比で滑べって東八幡平の近くに泊まるという，何というか岩手の方のご協力がなければ大変 う っとうしいことをしたわけですが，先ほどもいったようにここは『あたり 』 でした.

まあ大騒ぎするほどのところでもないかもしれませんが，ちょっとしたスペー スにコテージが点在しているような作りの場所なのです. 何がよかったかといいますと，まずおねえさんが可愛くて親切.

(これはもう一人の世話人がいいました .

わたしも賛成 し ます . )また，コテ ー ジに入るともう既に暖房が入れてあるという細かい気の使い方なども気に入りました.
夕食は ， 自炊でも，レストラ ン でも，はたまたそれをコテ ー ジに持って来てもらっても OK です . 我々は，持 っ てきてもらうと酒の追加注文ができないと聞いてレストランにしたのですが，一升瓶の一本も用意しておけばそんな心配いらないんですよね.実際レストランで食事をしたのは我々だ‘けだったということです.
用意して も らう場合，食事は予約制で，2000 円 ，3000 円， 4000 円というコースがありました.

3000 円のやつにしてみたのですが，はっきりいって食べきれないほど出てきました.
(ちなみに私は全部食べましたので田中が食べきれないほど. .• A と誤解して驚かないようにして く ださい. )ものはすきやきを中心に，刺身，焼き魚，味噌汁，ちゃわん蒸し，山菜 ， ええとその他に四品 く らいはあったと思います .
朝食は 1 00 0 円 て\これもまあまあちょっとしたものでした .

また温泉があり，もちろんコテ ー ジでも入れます(ただしこれはかなり狭い) .その他に受付のある建物にーっと，敷地内にもう 一つ大きいのがあります.単純泉のようですが，お湯は熱めで ， なかなか気持ちのいいものでした . 夏であればテニスコ ー ト，プール，ア ー チェリ ー ，フィ ールド ・ アスレチックの公認コ ー ス，野球場なども使えるよう ですし，マ ー ジャ
ン道具も借りられます.ちゃんと研修所もあるようですから ，SEA の若手の会などここでやってもいいのではないかなど考えました.が，盛岡駅からパスで 7 0 分ですから，さすがにちょっと遠いかもしれません.でも八ヶ岳よりはずいぶんき
れいな作りだし，温泉もあるし，食いものもうまいとは思うんだけど.
00 円 を 3 人で借りたのでちょっと割高になりましたが，

17.

• . ちなみに料金は， 4 人用のコテ ー ジ， 150

1 泊 2 食税 ・ サ込みで 10000 円チョイ で した.

東八幡平 の ゲ レン デヘ

さて明けて 6 日 ，泊まった 3 人のうち 1 人は滑べらずに帰ることになっていました.時刻表でプー タ ロ一 村に寄ってくれ
るパスは 日 に 4 本くらいしかないということを発見した我々は，近くのパスセンタ ー まて'送っても ら えるかどうかを飯の前におねえさんに聞きに行きました.前日，ゲレンデまではいつでも送ってもらえるとは聞いていたのですが，パスセンター
まではちょっとありそうなので時間指定だろうと思っていたのです . でも 2 人がチェ ッ クアウトしてしまうとパスが来るまで 2 時間もあって困ってしまう

いっそのこと 一緒にゲレンデまでいって，そこからパスに乗ろ う かなどといいながらご相談に行くと，いとも簡単 に OK の返事.良かったね，などといいながら飯を食って戻ってくると車の用意ができてます

‑
5
0
‑

SeamallVol.4 , No.2・3

SIGENV・Forum@MORIOKA

のでどうぞ』とのこと . 見ると車の脇に別のおねえさんがしっかりとお迎えのかっこてd立っている.こちらはというと一人がトイレにいっていてまだ戻っていなかったので.向こうを待たせる格好になってしまい，かえってビビッてしまいました.
じきに 3 人揃ったので，ほっとしながら車のところに行くと ， なんと運転手がいない.

かなと思いながらも，もしや.

• •何だ焦ることなはかったの. いや有り得るなと考えていると，案の定，我々をのせてドアを閉めるとおねえさんは運転席の方にまわったのでありました.トイレにいっていた男が，ご機嫌でおねえさんに話かけたのはいうまでもありません.
東八幡平のスキー場は，リフトを 2~3 本登ると一番上という比較的小さなところでしたが，やはりリフト 1 本はかなり長いものでした . 月曜日ということもあって，リフトは乗り放題でしたが. 2 時間で 10 本滑べるのがやっとでした

もちろんこちらが下手なせいもありますが，こちらは安比に較べて標高が低いせいか，雪質はさらに悪く，前日に滑べったあとがそのままガチガチに固まっていて滑べりにくいということもありました.
滑べりにくいといえば，最近のスキー靴の性能は大したものだということを再認識しました . 安比と遣ってこちらは昔ながらの貸しスキ ー だったのですが ， スキ ー 靴もかなり昔のというか，安いタイプのものだったのです.今の靴はすねの中ほどくらいまで高さがあり，前傾姿勢が保ち易くなっているのですが，ここで貸しているのはそうて。はなかったので，自分でかなりふんばって前傾を保たなければならないのです

斜面が惑いこともあって，かなりシンドイ思いをしました.

しかし 1 泊くらいで自分の lまろスキーをかついて'行く元気もないしなあ.

18.

うに 井の夢清え て

東京に 5 時頃帰りたかったので，残念ながらきっちり 2 時間滑べって，路議パスで盛岡駅に向かいました.
駅に着く予定だったのですが，さすがに路線パスだけあって.

1 時半頃盛岡

1 時間を過ぎるころから，乗ってくる方がものすごく増え出しました . とてもスキーの荷物を置いておくような場所はありません . 仕方なく無理矢理ひざに抱えておりました.しかし途中で高校生が大挙して乗ってきたのには驚きました.確かに高校の前か何かのようではありましたが，何であんな時間にあんなに帰る高校生がいたんだろうか .

盛岡駅に着いて，来た時に果たせなかったうに井を食うという作業に取り掛かろうとしたのですが.何と連れがまだ冷麹を食っていないというので ， 泣く泣く諦めました .

というのは冗談てにおそらくまたうに弁はなくなってしまっているだろうと思ったので，時間もなかったし，さっさと冷麺を食いにいったのでした.駅の向かいにあるビルの 2 階にある店でしたが，ここのやつもなかなかおいしいものでした.

しかしうに井が食えなかったのはやっぱり悲しい~来年 』 はきっと何とかするぞ.

19.

終りに か えて見事なまでに本題を外して書いてきましたが . 今回の最大の教訓は『とにかく準備期間をたっぷりとる』ということでした来年』もそうですが，とりあえずは今秋にやるはずの ~SIGENV@KOBE&JazzStreetA の時には注意をしなければ，と考えています.秋のものはフォーラムにするのかどうかまだ(当然のように)決まっていませんが，

S
o
f
t
w
a
r
eDocument ation を予定しています . 今度はなるべくはやめに案内を出しますので，是非ご参加ください .
いやいや，それでもまあ何とか無事に終って，良かった良かった.めでたし，めでたし .

2 o. ち ま けというような感じでこの文は終るはずだったのですがあわてるな，世間はそんなに甘くない 』 とばかりにまだ続きがあったりするわけです
翌 7 日，私がオフィスに顔を出すと，机の上に何かチラシのようなものが置いてあるのです .
『ふむふむ.

3 月の SEAForum の原案か.

『おお，ソフトウェア・プロトタイピングの効用ね.

.

『あれっ，コ ー ディネータ，田中? ?

『ん盛岡ミ ー ティングでの討論報告 .

• • Aというようなわけで，ほとんど討論ができなかった討論会の討論報告をどうしたらいいのだろうと ENV のメンバは現在パタパタしているのでした .
お~い，どうしよう.

.

[3 月のフォーラムは我々にとってはかなり悲惨なものでしたが，他のスピーカの方々に助けられて，そこそこのものにはなったと思っています . 次回「プロトタイピング特集号(その 2) J では，盛岡ミニ・フォ ー ラム .
報告を中心にお届けします.お楽しみに.

]

‑
5
1
‑

3 月月例フォ ー ラムのSeamaﾟVol.4 , No.2・3

Report 仕om K
yushuChapter

九州支部設立一周年報告
平尾一浩

ムを開催しました。参加者 160名という大きなもので、今4まじめに
関西、横浜、長野、名古屋に続く 5番目の支部として九までにない併置本ではなかった)技術者レベルの会合とな州支部が設立されたのは、昨年(昭和 63年)の 3 月 12 日でしりました.このシンポジウムはテーマを【情報産業のイ

た.

ンフラを考える】として開催し、特別講演、集中討論、

この一年間は試行錯誤の繰り返しでまとまったテーマ

フリーディスカッションの 3つを行ないました.特別講演

で何かをするということができませんでした.これは、としては熊本大学の山川先生(現在は九州工業大学)に『世話人である私の計画性のなさと実力のなさの現れでもファジィ情報処理のおもしろさ』を話していただきましあると反省しています. (本当は B型という素晴らしい血た.

液型のせいだと思って、あまり反省していない.ねっ! )集中討論としては、そのころは名前がまだ存在してい

しかし 、 SEA幹事の方々をはじめ、事務局、各支部、分たエサプセンターを題材に、その期待ということで、チ科会の方々に支えて頂き、なんとか一周年を迎えることェアマンに林氏 (SRA) 、パネリストとして岸田氏 (SRA) 、ができました.この一年で行なったいくつかのイベント

中野先生(阪大)、藤野氏 (FXIS) 、そして地元熊本から飯も多くの方々の協力と理解があって出来たことで、皆様

冨氏(システムイイトミ)、筏井氏 (HST) にそれぞれが考えるヱサプセンターへの期待を話題提供として語って頂き、にはほんとうに感謝の気持ちでいっぱいです.
今回はこの一年を振り返り、来年へ向けてのスタート

討論に入りました。(発表、及び討論内容は誌面都合にを切るということで、先日行ないました SEA 九州支部設より割愛させていただきます一)どうしても、ど~し

立一周年記念講演会の報告も合わせて、設立一周年報告でも詳しい内容を聞きたいと言われる方は平尾まで御連としたいと思います.

絡下さい)

1
. 活動状況

というテーマで、 チェアマンに深瀬氏 (ASC 1
I)をむかえ、日

フリーディスカッションでは、日中ソフトウェア事情

今のところ、熊本を中心に行なっています.しかし 、中ソフトウェアシンポジウムに参加された日本側団長の沖縄や鹿児島、宮崎、大分の方々には集まり鍵い思いを熊谷氏(富士通)をはじめとする、中心メンバー(岸田氏

していただいています.発足時は各県で持ち回り制にし(S 臥)、林氏 (SRA) 、中野先生(阪大)、藤野氏 (FXIS) の 5人ようという意見がありましたが 、 会員の少ない県では、の方々)にスライドを使用した話題提供を行って頂きましその受け入れ体制が作れず、実現できませんでした.
会員数はこの一年で、 35名から 67 名、賛助会員

た.参加者の中からは、 JUS (日本UNIXユーザ会)はアメリ
3社にカばかりを見て、 SEAは中国ばかりを見ているような感じまで増えました.しかし、この一年間に行なったイベンを受けるが 、 もっと足元を見た方が良いのではないか、

トに参加できた方は一握りの方だけです.各地区の活動などという意見も出され、なかなかの盛り上がりでした。

を主にしてはいますが、会員数の少ないところは活動自さらには熊谷氏が言われた『中国はとにかくスケールエ体が困難な状態です.

ラー 』 という言葉から 、 その後スケールエラーが涜行語になるくらいでした .
話題提供では中国のソフトウェア開発の実情や、開発

1.1. 支部活動
支部の活動、会合としては、 5 月に ICSE報告として代表

環境の紹介までをして頂き、今までほとんど無関心だっ

幹事の岸田氏においでいただき、講演をお願いしたのでた方々にも中国のソフトウェア開発、及び開発環境に興すが、内容は急きょ変更となり、味を持って頂けたようです.

F これからのソフトウ

ェア開発環境』というテーマで、講演が行われました。
これは、 2種類のビデオを基に、最新の開発環境の涜れをわかりやすく説明していただきました.事務局から中島さんにも参加して頂き、なかなかの盛り上がりでした.

z. 坦区活動1.

各地区の活動としては、福岡、佐賀、長崎 、 沖縄地区
がネットワークを中心に事例を基にした発表形式で例会

そのまま夜の部に突入し、歓迎の踊りなども披露され、を開いてきました.熊本、大分地区は全く統一的なテー九州支部らしい異常な世界が醸しだされました.

(参加者

マはなく、"設計\、"フリーソフトウェア\"汎用機に第 2 固として 11 月には、熊本県、熊本情産協、熊本テク

いてきました.宮崎、鹿児島は 、 会員数が少なく、活動

ノポリス財団の後媛で、九州ソフトウェア・シンポジウ

自体が困難な状況で、例会実績はありません . 福岡での数 :50人)よる開発環境"などまったくバラバラなテーマで例会を開

‑
5
2
‑

ReportfromKyushuChapter

SeamanVol.4 , N
o
.
2
‑
3

例会はいつも 10人位で行われ 、 熊本での例会は大体 20~

ープルウェア」をもとに講演して頂きました 。

30人で行っています.

内容に関して 、 残念ながら講演の録音が失敗していまして詳細にお伝えできないのが残念です . そこで、当日z. 平成元年使用された OHP の内容を御紹介することにします.

今年の計画としては、以下のものを予定しています.

〈人的資源の管理〉

1 : 九州支部全体の会合
年2 回 (4月 、 9 月)

食今日もどこかでトラプっている

4 月分は、九州支部設立一周年記念講演会を-ありふれたアプリケーションでも多い失敗ー技

開催.

術問題でない証拠.

2: 各地区活動

500 のプロジェクトを調べたら、毎月一回15%が動いていない

熊本 、 大分地区は第2土曜、福岡、佐賀 、 長

25人年以上のフ・ロ ジ ェクトでは 25%が未完

崎、沖縄地区は第3土略で、宮崎、鹿児島地. その原因は技術に非ず.

区は立ち上げを目標に動く .

-問題の本質3: その他イベント

・ 政治的要因と言うが 、実は社会学的要因

第2 回九州ソフトウェア ・ シンポジウム(1 0-難しいのは技術よりも人月)・管理者は 、 人の管理について教えられていない

4: SEA本体のイベ ント九州誘致. ハイテクの幻想

教育ワークショ ッ フ・ (9 月)

・ソフトウェア開発はハイテクとは程遠い

以上の計画を行っていますので、九州へお越しの際に. r 先端技術」ではなく「人間関係技術」

は、是非九州支部へお立ち寄り下さい.

昨年の熊本 、 大分地区活動は、まだ全員が不慣れとい合チーズバーガ一生産・販売基準書

うこともあり、受け取るだけで出すのもがなかなか無い.ファーストフードのやり方は開発作業では使えという状況でした . ですから、世話人中心の偏った内容ないになり、広がりというものが感じられませんでした.技術移転などというもののまだまだ前の段階で、人的交流-誤りの割当・品質のよくない部分は潔く捨てろ

が何とか出来たという具合です.しかし、一年が過ぎよ
うとしていた位に、多くの会員の方から、是非、例会の- 間違いは許されない雰囲気が間違いのもと.少々の間違いを大自に見る担当をしたいという話が出てきました . 皆さん、それぞ
れにいろんな経験や、知識 、 技術をお持ちなのですが 、
今まで SEA の会合に慣れずにおられたようです.そこで、今年は 2 ヶ月単位で担当制にし、担当月は統一テーマでそ・「特に問題なし J は最悪の答.管理とは尻を 叩くこと?

・尻叩きは頭を使う仕事には使えない.仕事への愛着を信じよ

れぞれの話題を提供しあうということになりました.こ-手配師

こえ来てやっと踏み込んだ議論や技術移転というものが・多くの管理者は人を取り替 え可能な部品としてできるようになるという期待をしています.

考えている-回り道して交換がきかないことを悟る

J. SE 血九州支部設立一周年記念講演会

・キーマンがやめるのが怖いのに、キーマンはい

4月 22 日、支部設立一周年を記念して 、 講演会を開催しないと思い込むました 。 講師として 、 松原氏(目立ソフトウェアエンジニ

・アリング)、加藤氏(東京工業大学)の両氏においで頂きま「ジョージ・ヌゲーテ'ンハイヤがくたぼったので 、新しいのを頼む.今度はあまり生意気でない方がした . その講演内容を簡単に紹介します.

いいな」

・

~原友夫氏

「金よりも欲しいものは自宅でのよい端末J.フ・ ロジェクトと死後硬直【ソフトウェア開発の人間的側面】

・プ ロジェクトの目的は製品を出して完了させる‑Peopleware ‑こと

プロジェクト管理の諸問題を論ずる場合 、 特にその人・安定するのは終ったとき

間的な側面を考慮することが重要です . 松原氏は最近邦・ プロジェクトの動的な面にこそ神経を集 中させ訳された T. DeMa rco と T.Listrt の名著「ビープルウェ

るア」の翻訳、監修を手指けられました . 今回 、 その「ピ・ 彼女が入ったフ・ロジェクトは必ず成功:その秘

‑
5
3
‑

SeamailVo1. 4 , N
o
.
2
‑
3

ReportfromKyushuChapter- 日本の例

密は??
・触媒の重要性-考える暇があったら仕事をしろ!

食パーキンソンの法則の復活-実質的に仕事をする時間として 、 どれ位を割当-与えられた仕事をするのに時間はいくらあって

るべきか?

も余らない

「その他」の重要性-パーキンソンの法買IJ とニュート ン の法則
人生はだらだらと仕事をやるにはあまりにも短「考えている暇があったら手を動かせ J.考える時聞を確保するのが大変-ソフトウェア開発者は本を読まない- 仲間にこんなことは言えるだろうか ?
-自然の欲求を持つ

食ウィーンがあなたを待っている.

.パーキンソ ン、流に扱 う な-チーム員の陵婚や子供の不良化を自慢する管理者の話-ニューサウスウエールズ大学のデータから.スペイン涜管理

・プログラマが目標を立てると生産性が高い. スペイン涜ーー富の量は一定一一一搾取.システムアナリストが立てるともっと高い- イギリス涜一富は作り出すもの産業革命.目標設定をしない場合はさらに高い!

. 今でも生きているスペイン涜の価値観

・ パーキンソンの法則をちょっと変えたら-タダ働きで生産性を上げるのはサギ-不要、不急業務の増大-家庭からの嘆き
・家庭ではまったく違うことを言われる

会獲によく効く?

.大切なものは一人一人の人生

r ラエトラル』

杏の種のエキス、ラエトラルは癌に効く 7.末期患者は藁をつかむ気持ちでこれを飲む-残業なんかくそくらえ!

.生産性向上に効く技術的ラエトラル-オーバータイムとアンダータイム(水増し時間)・見えない時間、サービス業 、 ア ン ダータイム-眠っているうちにやせられる.残業は全力疾走- 山程ある生産性倍増商品の広告-決定版は「限っているうちにやせられる」・ 仕事中毒

-技術面でおくれていても落胆する必要はない

・ 一種の一時的な病. もっと大切なものを犠牲にしていると気づいた.管理者が陥る 7 つの錯覚

時

-生産性を上げる方法がまだある-他のところでは 2倍も 3 倍も上げている-生産性試合に勝って勝負に負ける-生産性を改善すると退職を滑やす危険

・ 技術は進む 、 おいてきぼりにならにか.生産性を高水準にしたが全員やめた話.方法を変えれば上がる-積み残しが多いから生産性を上げよ.スペイン流管理のつけ. 何もかも自動化-せかせても良いものはできない.早くなるだけ.プレッシャーをかければよく働くだ.これこそ管理だ・ ふらふらで仕事をしているトムにシャロンが出

食品質第一・・時間さえ許せばしてくれた温かいスープ-感情を入れずに仕事はできない「人を働かせる」ではな く 「人を働く気にさせ-感情は自尊心が傷つけられることによって高ぶるJる-自尊心と仕事の質.品質第一主義からの逃避〈オフィス環境〉

遅れの原因限りなし 、 つける薬は何もなし-時間を節約すると品質を犠牲にする-品質と生産性は両立する . 日本にはこの二つのトレードオフいう考えはない-品質はタダ 、

しかし .

食施設監査役「本当のオフィス環境にはお構いな lJ.

-施設監査役の精神権造-タダなら絞り取れ 、 という誤解-見かけの素晴らしさ

・品質はタダ、しかし喜んで金を払う人に対して.品質第一は文化-いずこも同じプラスチ ッ クのオフィ ス-誰が窓際のいい席をとるか・ 出荷拒否権‑
54‑

ReportfromKyushuChapter

SeamaUVo1. 4 , No.2・3-気持ちが良さそうなところは廊下会頭脳タイムと肉体タイム.地下室も理想的.1人による作業・ガ リガリどなる社内放送

2人による作業

3
0
%
5
0
%

3人以上によ る作業 20%
食プログラムは夜聞く

神経集中・残業の真の目的は質の向上-フロー状態の幸福感-仕事がはかどるのは夜か早朝-割り込みで少なくとも 15 分はムダになる. 会社の言い訳.いつまでも続く騒音、割り込み・一番多い苦情にほほかむり

・勤務時間と精神集中・プ ログラミングゲーム:生産性の要因を探る.E計数= 割り込み無しの時間/机の前に座っていた時間-同一企業内の 2人で一組.オフィスは赤いパンダナの園-競技は別の場所 、チームであり個人の競技

・割り込みお断りのサイン、パンダナ. 仕様書からテストまで・考えごとは家で-延べ 600人が参加
・プ ログラマの個人差

食電話-トップとどん尻は 10倍の差. ト ップは平均の 2 .5倍・別世界にて-上半分は下半分の 2倍以上

- 電話してくる客の方が大事??
- ぺルが 3 回鳴るまでに受話器をとれ!

.生産性と無縁な要因

・言語、経験、残存不良、年収. 電話倫理の改訂-電子メイルシステム.誰 も番かなかった生産性要因-誰とチ ームを組んでいるか.Wt1 り込みお断りのボタン- 同一企業内の二人にバラツキはない.ベルに紙をつめる.企業におけるプログラマの能力さも.企業 自体の生産性も 10倍の開き

会ドアの奪回-企業文化が優秀なプロ グラマをひき寄せる・あきらめるのはまだ早い.オフィス効果. ケパケパしさの問題-作業環境と生産性の相関関係は顕著.機能性より概観が気になる・で 、 何がわかったか?

.創造的空間-オフィス環境の改善は管理者の責任

対症療法と根治療法.左脳と右脳食スペースに金をケチると-活力あるオフィス

ケチった金より大きな生産性低調による損失

会社のしきたりを破る.環境の破壕- 自由なレイアウト「解放型オフィス J という災難-考慮されないプログラマの生産性

tl 傘が聞くよう仁. 惑口は中断して数値を示そう-永久不滅の建築法• IBMのサンタテレサ研究所.アレキサ ンダーの組織均衡論-オフィスの良否とプ ログラムの品質-不良 o・会社組織も進化論的に変遷する

騒音レベルは我慢できる 66%

不良 1 以上:騒音レベルは我慢できる.組織的均衝のパターン

8%-よいオフィスにはよいバランスが必要.ノーベル賞級の大発見・ 第 l パターン:キットによる組立-人工密度と比例する騒音- 第 2パターン:窓.オフィスから雲隠れ-第 3パタ ー ン:屋 内と屋外
・第4パタ ー ン: 共通の場所. パターンのパターン. 現実に戻ってみると

‑
5
5
‑

SeamanVol.4 , N
o
.
2
‑
3

Report 仕om K
yushuChapter〈適材〉-低退職率の会社の共通した特徴:
ザ・ベストの追求

食ホーンプロワ一因子

コニュニティ感覚-フォレスターの海洋官険小説の主人公

再教育プログラムの充実

ホンプロワーは究極の管理者
食事故修復システム-先天性と後天性・最初に適材を獲得するべし-決定論的システムと非決定論的システム-決定論的システムは自己修復機能を失う.型にはまった人間-失敗の多くは外見にとらわれた採用

作業規模の弊害.画一性の要求は不吉な兆候-意味がなくても書いてある通りやる・考えるな、その通りやれ- 標準的な服装の悪影響

・狂気の作業規定-合言葉:それらしさ-書類の山は災いのもと「らしくない」ことはやっては困る.問題を解決しなくなる.企業のエントロビーも増え続ける.責任感が薄くなる

・違反すれば無能力者→意欲喪失

合奇術師を雇う.悪意、の追従.奇術を見ないで雇おうとするのはばかげている

・わざとその通りやる.成果一覧.赤ん坊の湯あみのように・面接指向の採用-強制は反発をもたらす-求められない候補者の成果物.穏やかに誘導する.能力テスト

・現場で検証されたものだけが規定となる(デュポン)

・役に立つのは愚初の仕事.ホーソン効果.左脳の能力のみ-ソフトウェアの生産性向上成果もホーソン効果.役立つが採用に使うのは良くない.オーディション開催のすすめ〈生産性の高いチームを育てる〉

合ここにいるのが楽しい

食チームは個人の和よりも強し-退職率、退職コストに答えられるのか. 結束チームとは.退職というムダなコスト

・個人の集合より大きな成果を生むチーム-アメリカの平均在転期間は約 2年.結束しはじめたら成功間違いなし.採用コストは1. 5~2 ヶ月分の給料

共通の目標が重要立ち上がりのムダ、交替のロスを加える

・感情的楽観主義とザッと 5 ヶ月分-放っておいても組織の目標を受け入ると信じる-退職の隠された害

楽観主義.短期的視野のツケ-ナバロンの要塞

・早過ぎる昇進・目標は勝手なもの 、 スポーツを見よ-頭でっかちの組織-結束チームは要塞さえ重量撃するものを作っているのは入って 1~2年の人-目標は達成でなく一体になれること.なぜ会社をやめるのか.結束チームの特徴-腰描けメンタリティ-人が入れ替わらない- 使い捨てにされる予感

不注意な配置転換は命取り.忠誠心強要への反抗.生産物共有意識.退職は伝染する・チームと派間

・会社の移転に伴う病理- そよ風とすきま風-一人の仕事を移すだけではすまない.昔はできたが今では愚行.ATT移転の悲劇- 永続性のメンタリティ

‑
5
6
‑

ReportfromKyushuChapter

SeamallVol.4 , No.2・3

食黒装束チームの伝言E-プロジェクトより共に働ける機会-唇を持つ鶏がわかるか.伝言誕のいわれ-もとは普通の出荷テストチーム-誰が本当の責任者?

. チームに起こった大きな変化-自然の権威・プログラムに試練を与える 喜び
食チーム形成の不思議な作用.哀れな地球人よ!
・プログラムが止まるとケタケタ笑う.品質至上主義「ほぽいいだろう J は弔いの鍾.後日談-品質至上主義はチーム結束の触媒

・人が入れ替わってもチームの個性は残った

カキの中の砂tl チーム穫しの 7 つの技法・結婚したから 愛している-終結による満足感.自己防衛的管理・ 部下を信頼しない管理者.エリートチーム. 管理者による技術的干渉「我社はエコノミークラスの会社ではない」-信頼されていないと感じれば結束しない-チームのアイデ ンティティ ー. 官僚主義.ヤンキースを解散させないで・ドキュメントの洪水は 目標意識を育てない-チ ームはネ ットワ ークモデル 、階層モデルではない. 作業場所の分散.中華料理メニューからの選択

・ チームの結束より周りの人と仲良しに・ 異分子の作用、女性のいるチーム

チームの文化は生まれない.全てを一つに収める-時間の分 断.小さな町の伝統的なコミュニテ ィ ーのように・ 1 人が2つ以上のフ・ロジェクトを分担するとチームは結束しない〈きっとそこは棄しいところ〉-品質低減製品

・早かろう悪かろ う、は自尊心を傷つける

食混乱と秩序-混乱状態をキチ ンとする快感.さばを読んだ期限-部下への信頼も上司への尊敬も生じない.進歩こそ大問題

・秩序が欠けていたか ら 新鮮

.派閥統制

.小さな混乱の建設的導入

・チームは終 ったら解体し、 一緒には動かさない傾向-新手法試行フ・ロジェクト
・期待されるホー ソン効果

-意識的にではないが結果的にチームを殺している- 全てを試行プロジェクトとする会社. 一度に一つの手法を会スパゲヲティディナーの効果

・チームリーダになる人から自宅での夕食の招待.プログラミングゲーム

を受けた-小さなプログラムを-チーム効果が現れる.全く普通の仕様書で.週末を利用する-みんなで買物や料理や片付けを分担

・ルールや目的を前もって知らせる.続いて起こったこと.居るのは参加者だけ.誰にも 何等かの賞を食オープンキモノ:問題をさらけだす.興味あるデータを記録する.信頼できる人に全てを委せる.プレ ーンストーミング-全てをさ らけ出すオープンキモノ経営

・教育、旅行、学会、お祭り、そ して保養

.合宿作業

・オフィスから逃れることの効果

食自由電子一会社の枠組みから飛び出す人達.規則は破るためにある.つまみ食い症候群・スカンクワ ークプロジェクト(閣の プロジェクト)・フェロー 、 グル一、インタープルナー. 否認されても生き残ったプロジェクト- 新しい雇用形怒-反抗賞のメ ダル‑
57‑

SeamaUVol.4 , N
o
.
2
‑
3

ReportfromKyushuChapter-おせっかいはやめて

はじめに
食 N1-NET .
.
..
..
..
...
..
..
..
.
JUNET 以前のアカデミ ック

食眠れる巨人、ホルガーダンクスーまとめ

ネットワーク.

-だが、なぜ私が?
-たった一つの変化でも一人ではできない

全国の大学の、-闘牛士エルコルドぺス

メインフレームを接続したネ ッ トワーク.

.それはみんなの問題

7 つの大型計算機セ ン ターにある

ロサービスとしてはリモートログオ ン、 ファイル
転送の 2 つ。

. 眠れる巨人-危機の際だけ目を覚ます

口高い課金制度であったが 、当時としては画期的-企業の中のホルガーダンスク

なネットワークであった.
口電子メール、電子ニュースのサービスはなし.

.ホルガーよ目を覚ませ!!

(最近電子メールのサービスがはじまった)ロ閉じたネ ットワ ーク他のネットワ ークとのイ ン

上に紹介しました OHPの内容を見てもわかるように、講タラクション

演全体がビーフ・ルウェアに沿って進められ、理解しやす
いものでした。
会員の中からは、はなかった.

「この本は僕のために書かれたよう

一方アメリカにはな気がする.読む度に涙が出そうになる」などというコメントが出され、笑いに包まれるという一幕もありました.その他に 、 チーム立ち上げ時に関して、チームの概念やベクトル合わせの必要性についての意見や、経験の積分値の利用法などが話されました . その他にも、【管理とは人を働く気にさせること】ということに関して、

APAN 口の構築がなされ 、主な大学の研究者逮は電子メールで情報交換を行なっていた。

ロ電子メール、電子ニュースの必要性 。
ロ海外の研究者との情報交換 。
ロネ ットワ ークの研究、開発の促進 .

•

実際の管理をされている方から「それl立働く気のある人

JUNET の誕生。

がいることが前提」といった意見も出され講師の松原さんをはじめ、多くの方が同意されていました.結局は管理する側もされる側も、お互いに対して多くの期待はす

JUIIET の動穣るなということだったようです 。
(ちなみに、 HSTでは、話の中で出た赤いパンダナをJ!O

食 JUNET 発足の三大動機

実行した人聞がいましたが 、 パンダナの意味に対する質問責めにあい、割り込みがさらにひどくなったと、止め口電子メール 、 電子ニュースによる情報交換。

てしまいました)

ロ海外のアカデミ ッ クネットワークとの接続。
ロネ ットワ ーク自身の研究活動をフ・ロモート .
公

加藍朗氏

JUNET の制約..... ... . .. . . . . ...... VAN 業者との競合を避ける.
ロ営利目的に使用し ない。

< The JUIIET >ロ不特定多数の使用に供しない .

ーその歴史、現状、将来一ロ専らネ ッ トワーク運営を行う組織ではない .

JUNE
T は、計算機研究者の情報交換の環境を確立する

あくまで片手間で行う 。

ため、また、ネ、y トワークの研究基盤として利用されることを目的とした実験ネットワークです。同ネットワー

公ボランティアベー スで行なう実験オ、ットワークとしてクの運用は 1984年 10 月から 3つのローカルエリアネットワ

運用開始。

ークのグートウェイである東京工業大学 、慶応義塾大学、

ロ計算機科学、社会科学、心理科学なと.のい ろい

東京大学を結合して開始されました . 現在はその範囲もろな実験を行なえなければ日本全国に広がっています.この JUNETの構築に初期の段いけない 。

階から携わってこられた加藤氏に、その歴史と現状 、 将ロ メッセ ージが fai 1

しても 責任を持てない。

来について講演して頂きました .
以下に加藤さんの講演内容を簡単に御紹介します 。

JUIIET の歴史

1
9
8
4/
0
c
t
..
. ー.. . . . ... . . . . 東工大、慶応、東大でスター
ト。

‑
5
8
‑

ReportfromKyushuChapter

ロ VAX.

4
.
2
B
S
D
.3
0
0
b
p
s (V . 21)

口通信プロトコルは UUCP

SeamaUVol.4 , N
o
.
2
‑
3

モデム .

大学等 . .
.
.• • .• .• .• .• .• .
..• .
..
.• • .
.
ac.jpを使った電子メールの- 政府関連機関 . . ... . . . . .. ....... . . .. g
o.
jp

実験開始.

- 企業. . . . . . . . • .• .•.•.•.•.•. . .• •. . • • co.
jp-非営利団体 . . . .... .. . . .... . .. . . . . .. or.jp1985/Jan.. . . . . .. . . . . . . . . KDD 研究所が USENET に接続 .

ネットワーク管理母体 . . • .
• .• .• • .• • • ad.jp

口電子ニュースを配送するネ ッ トワーク 。

食 ボラ ン ティア ベ ースの実験ネ ッ トワークとい う 正確はロ国際接続の開始 。

保持 。

1
9
8
5/Ma
y.
..
..
.
.
.
.
.
.
.
.
.
.
. ドメイン形式アドレスの採用 。

食ロ電子メ ールの fai 1 する数が減 っ た .

トラフィ ッ クが増えて管理が大変。

1
9
8
5/
A
u
t
o
m
n.
.
..
.
.
.
.
.
.
.
.
.電子ニュース 、 電子メールの日本語化 。

JUNET の現設

ロ当時は漢字 UNIX がなかったため 、 7 bit 表現 。

.J
I
SC
6
2
2
0
.J
I
SC
6
2
2
6

t! 参加組識 . . . . .. . . .. . 200
ロほとんどが東京と京阪神地区に集中している 。

ロ漢字端末が少なか っ たため PC 上にターミナル

ロ九州は 13 + 1 組縁 。

.エミュレー タ を

食 接続計算機

走 ら せて使っていた .

ロ不明

ロ ESC を通すように n e ws ソフトを改良 .

ロ推定では 2500 ー 3000

1
9
8
6/
M
a
r.
.
.
.
.
.
.. . . . .. . . . CSNET と の リ ン ク 。

食 平均的なリ ン ク

ロやや高信頼なリ ン ク .

960
0 bps 、ダイ アルア ッ プ ・ コネクショ ン、
UUCP ,
ロ

ロゲートウェイは東大 。
ロ課金制度 。

ロ 2 時間に 1 回程度のコ ネ クション 。

口利用は大学に限定 .

公 4. [
2
3]BSD 系の UNIX

1
9
8
7/Ma
y.
.
.
.
.
..
..
.
.
..・ ・ . INETCLUB 発足.

決 約 12 のパ ッ クボー ン ノード

ロ民間企業も利用でき る 国際リンク 。

ロ九州 では九大が 、 東京では東大や東工大などがロアメリカとヨーロ ッ パとの接続が確保された.

1
9
8
8
/0
c
t.
.
.
.
.
.
.
.
.
..
.
.
.
.
.東工大 、 東大が行なっている 。

I
n
t
e
r
ne
t

Protocol で接続 .

ロ

イーサ・ネ ッ トと同じプロトコルなので 、 イー

電子メール

サ同様のサービスが受けられる 。

JUNET の代表的なサービスである .

-リモート・ログイ ン

公 正確な数は測定不可.

-ファイル転送

食 着信メールの約 1 寄l は海外から.

口学術情報網の整備によるリンク .

食 囲内 メ ールの平均到達時聞は 3.2 時問 。

・ 東大 - N
S
F(
W
a
s
h
i
n
g
t
o
nD
.
C.
) (専用線

食 多くのメ←リ ン グリスト .
・東大ー阪大(専用線)

t! アドレス表記-京大 、 東北大、九大

k
a
t
o
@
c
s
.
t
i
t
e
c
h
.
a
c.
j
p

口公式 IP アドレスの取得促進 。

kato .. . . . . .... ..ローカルパート-バルク ・ アサイ ン メ ン ト

ユーザ名 、 メーリ ング リスト

ロ電子メール 、 電子ニュース以外 の サービスを 準

cs .. .. .. ... . . 第 4 ドメイ ン名

備中 。

組織内サブドメイ ン

1
9
8
9/
A
p
r
.
..
.
.
.
.
.
.
.
.
.
.
.
..アドレス表記の改訂 .

t
i
t
e
c
h . .. .. . . . . ..第 3ロ ISO 3166 国別 2 文字コード

ドメイン名

組織名

- 日 :本 ... . .. . . .. .. . .... . .. . JPac ... . .. . . ....第 2- イギリス . ..... . .. ..... .. . U
K

ドメイン名

組織の種類

- 鑓国 . . . . . ..... . . .. .... . .. K
R

か

など 。

.. .. ... .. . . 第 l ドメイ ン名
日本

ロ属性を表す第 2 レベル ド メイ ン名ロ JUNET で管理してい る のは 第 3 レ ベル(組織名

‑
5
9
‑

ReportfromKyushuChapter

SeamaUVo1. 4, No.2・3)まで.

JUNET の貢蔵

命日本にアカデミックネットワークを張った.
海外とのメール交換

î:l 大学だけではなく 、 民間企業とも接続 .
食電子メール、電子ニュースによる交流.

食現在 2 つのグートウェイが濠働中

食学会に比較して、ホットでタイムリーな議論の場。

ロ東京大学.. . . .. . . ... . .大学関係 、政府機関関会作業環境の整備.

係.

r
e
l
a
y
.
c
s.
n
e
t
ロ kddlab . .
.
KDD ではなく lNET が運営.
u
u
n
e
t
.
u
u
.
n
e
t
.I
I
c
v
a
x
.
c
w
i
.
n
l(
n
l は Neth ­ロ news 用のソフトの日本語化 。

口上に派生して諸々のソフトの日本語化 .
ロ PDS 、 Free Software の品質の向上 .

erLands オランダのこと)

食 UNIX コミュニティの広がり.

現在はユーザが陽に指定

食ネットワーク管理や設計のノウハウ交換。

l UUCP 、 PMDF によるパッチ式リンク .

食電子ニュ ースによる Q &A.

ある一定時間毎に電話で呼び出す.

命 名刺 、論文に電子メールアドレスが入るようになった 。

食 19 89/Apr より NSF との専用線上の X.25 lP 接続

食 研究会の開催案内 。

ロ Int色 rnet から 10 分程度でlD ail が到着.

食 LAN を通じて非常に多くの人に利用 .

ロ低廉価な課金額.
口氏. jp (大学) . go.
jp (政府関連機関)に使用が限定.

現在の JUNET の問題点

ロ 9.6kbpsのためlIai 1

で手一杯である. ftp 、

食低信頼性、高遅延なメール配送 。

telnet には解放不可 。

口実験ネ ッ トワークだから許される?
ロ専用線でつないでみる .

電子ニュース

食電子メール 、電子ニュースのみのサービス .
ロニ ッ クネーム・サーバ( メ ールアドレス情報) .

パソコン聞で行われている「電子掲示板」と基本は同じものである.パソコンの場合は中央のコンビュータに

食管理作業の噌大.

login

食 海外リ ン クの帯域 、費用 。

して、そこで news の読み書きを行なう . つまりメッセージのコピーは中央のコンビュータにのみ蓄積さ

口 9.6kbps というスピード .

れる .

ロ 企業が使えない。

J
U
N
E
T の場合はメッセージのコピーが動的に配布されロ料金が高い .

る。

など 。

食囲内分で 1 日に約 100 通が投稿されている .

食ユーザ、管理者の教育、育成 。

食海外分も合わせると 1 日に約 580 通が投稿されてい食潜在的ゲートウェイの不足.

る.

口大企業からの協力がない . 大学や小さな会社ば

食 園内分のほとんどは日本語で表現されている。

かりである .

食メ ーリ ングリストの再投稿が約 3 割.

公 日本人風コミュニケー ションサポート 。

ロ news に自動投稿することにより多くの人に読んロ表現の問題 .

でもらえる 。

(けんか になったり、意志が伝わらなかったり)例) X-Window 関係のメーリ ン グリストがあロ news の保存 .

るが、 news で配布するよ う

食東京、京阪神への集中 .

にした .

口東京 、 京阪神以外からの参加が少ない .

食投稿量が徐々に増加.

食大学の参加が少ない .

現在では 3000 を越える量が投稿されている 。

ロ全体の 1/3 程度 .

公電子メール、電子ニュース共、ユーザ ・イ ンターフェースは多数揃っている .

‑
6
0
‑

SeamallVo1. 4 , N
o
.
2
‑
3

ReportfromKyushuChapter

新しいサービス公

い止めるか。

InfoServer など、メールによるアーカイプ

ロ

分散環境へのアプローチ

あるドキュメントが欲しい場合、メ ー ルすると自動で送られてくる.

食アイツはどこの計算機で仕事をしている んだ?

• . など.

ロネームサーバに問い合わせるとつないて'くれる.

î:rニックネ ー ム-サーバ

ロアクセスコントロールも必要になってくる.

î:rリモート-ログイン、ファイル転送、 Phone.

公計算機を鍛っていない非業界人でも使えるようなインターフェース.

JUNET の今後

ロ UNIX は誰でも使いやすいというものではなく、使いやすいと思っている人

公 JUNETが使っている.
ロ UUCP のようなパッチ式リンクでは困難。
十である限りは、ボランティアベ ー スの実験ネッ

トワークの正確は保持.

食多くの人の笛カが必要.

ボランティア・ベースのネットワークであるか

ロネ ットワ ークの運営

ら、作ってくれる人がいるので

ロ研究開発はないかと期待.

ロユーザ教育Q &JUNET/曹 ide

AQ. ROS(Read 00ly Site)

食広域ネットワ ー ク環境の実験、研究プロジェクト.

の問題について加藤さん

はどのように考えられますか?

食組識ネットワーク閣を接続するインターネットワ ー クの構築.

A. これは電子ニュースにおいての話でして、会社や大食分散環境のサポー ト

学などで、電子ニュースの投稿を禁止しているところがロネームサーバあるんですね . そのようなところを ROS と呼んでいます。
で、どうしてこれが問題になってきたかといいますと 、

ロ経路制御

ロスクリーニング

みんなが協力してニュ ー スを投稿したり 、 ソフトを作っロセキュリティたりしているのに 、 自分のところばかり情報を収集してロアーカイプサーバ

おいて 、 一切外に情報を出さないというのはけしからんということなんです.

などの問題がある.

これが、今ニュ ー ス上で議論されていまして、 ROS

火種々の リンクのサポート.
ロ 9.6kbps 専用線

ロ 3. 4kHz 専用線+エラー訂正モデム X.25

それで、私の考えなんて'すが、 ROSというのがあること自体よくないとは思いますが、 ROSの人達も、ニュ ー

口 64kbps 専用線

スを投稿できるように、いろいろと努力しているので 、

ロダイアルアップコネクショ ン

そんなに責めることはないと思います.

ロ 64kbps

問題と呼ばれています.

I
S
D
N

それから、 JUN ETなど .

ですが、例えば 、っていうのにいろいろ誤解があるん「うちの計算機は JUNET に入っていま

す. J という言い方はあんまり正しくないんですよね 。
JUNET を通じてメ ールを出せる計算機を JUNET の計算
組織間リンク機かと言うと 、 そうではないんですね . それはあくまでその組織の計算機であって 、 決して JUNET の計算機では

î:r政治的問題が表面化ありません.

口組織外部の 資源へのアクセスは特に問題がない

JUNET を使っていく上では、各参加者の組織のポリシとしても、組織外部からのーと 、 全体のポリシ ー と受け取る側のポリシーとの共通アクセスに対して政治的、生理的に嫌悪する人点で運営していかなければいけないわけです .

が多い.

それで、私達のやるべきことはその共通点をなるべく広くするという努力をするということだと思います .

-セキュリティRO
S の人達もニュ ー スを投稿できるようにいろいろ努-イントルーダ(ハッカー)力しているわけですから、今 、 ニュースを簡単に投稿で悪意を持った人をどのようにして食

‑
6
1
‑

SeamailVo1. 4 , No.2・3

ReportfromKyushuChapter

きないからといって、いじめてしまうのはよくないですQ. 加藤さんは学校に行かれて、婦られるまでの問、ね.

何をやっていらっし守るのですか?

まあ、そういう問題があるっていうことはわかっていますが、あんまり悲観的に考えることはよくないと思いA. この質問の意味を「私が JUNET 関係でどれくらいのますし、時間をとられているか」と解釈しますと.

ROS と呼ばれている側の人達ががんばっている• • •ゲートウェイの管理と 、東工大を含む 、あるいは自分のに水をささないように、なるべく応援してあげるようにしてあげるのが大切ではないかと思います.

自身のローカルエリアネットワークも含めたネットワー

Q. INETCLUB へのアクセス位、どのよう仁すればいす。

クの管理というので、 1 日に 30 分とか 1 時間くらいで手間をかけずに高い管理レベルを維持できるという技

いのですか?

術を開発することが今、私に課せられた問題であると思

AI
N
E
T
C
L
U
B にもいくつか会員種別としてランクがあるいます.

わけですが、普通の会員は、ゲートウェイに電子メール

J
U
N
E
T が実験ネヲトワークから抜け出すというに登録しまして、このアドレスは、お金を払いますからQ.

通してください、と申請するわけです。

ことは考えられるでしょうか?

それから、もう

1 つ上のクラスに特別会員というのがありまして、こ れは 、会社のすべての人のメールを通してください、と申請します.
あと2 年くらいはこういう方向で運営されていくと思A. それはありません.
JUNE
T は運用ネットワークの性格もだ. いぶ持ってきてはいますけど、基本的には実験ネットワークです。
多分 J UNET という 名前はずっと実験ネッ トワークで あいます.

って、そ れを他のネ ットワ ークが、 今 JUNET が置かれてQ. 今後の活動として、専用緩を引く、というのがいる立場をテイク・オーバーするというのはあり得ます

あるんですが、なにか具体的な計画はないのですか?

けど、私たちは、あまりそんなことは考えていません。

A. それはむずかしいですね。

Q
. J
U
N
E
T はボランティアベースのネ 7 トワークとといいますのは、それにはお金がからんでくるんです
よね.

JUNET というのは 、基本的には隣の組識までの電話代を払うという以外は、特に課金というのをしなかっいうことなんですが、技術面でサポートできないようなところででも、できるボランティアというのはないでしょうか?

たんですよね.
それは、メールがデストネーションまで行くのにいろ
んな経路を通っていったり、場合によっては、経路上のA.

例えば、 JUNET

マシンが落ちているのて'迂回路を通っていったり、いろんな場合がありますので、それら

1 つ 1 つをトレース

ボランティア」というのをあまり堅く考えてほしくなかったんですけど.

.

に加入するさいに 、強力なボランティ

アを強制するようでは、誰も加入しませんよね.ですか
らそ れは 、 自分のできる範囲で構わないと思います .

して、課金データを作成してお金をもらうとかやっていもちろん、積極的にソフトを出すとか管理をやるとかたら、きりがないわけです.
ですから、圏内に関してはドンプリ勘定で、隣の組織

いった直接のボランティアもありますけど、ニュースをとの聞の電話代を出す、ということだけて'やってきまし

投稿するというだけでも充分ボランティアとして貢献すた。

ると思います。

専用線を使うとうことになりますと 、 近いところは安

私はあまり狭い意味でボランティアというのをとらえくおさまるんですが、ちょっと離れると高くなってしま

ていなくて、もっと広い意味でボランティアというをといます.月にらえています。

10 万とか 20 万円くらいかるくかかってさっきの ROS の議論なんかも、あれもニュースの中だしまいますから、非常にむずかしいですね.

私たちができることは、「専用線を使うとこんないいけのことなんですよね。もっと広いところから見れば、ことがありますよ、ですからお金を出してください J 、その人たちも何らかの形で貢献してくれているわけですということくらいなんですよね.

しね.

ということで、パラ色のモデルをつくるというのが、もし、ニュースを投稿しないことが罪悪だというので私たちに課せられた使命ですね.それが、ほんとうにパ

あれば、それくらいの小さいところはもっと他にいっぱ

ラ色であれば、上司も説得しやすいですからね。

いあるわけですよね。

というわけで、そういう狭い意味でのボランティアにですから、今のところ具体的な計画、例えば 3 年後に全部 IP 化してしまおうとかいうのはないて'すね.

貢献しなくちゃいけない、というふうには私たちはとらえていません。もっと広い意味で何らかの貢献をしてく

‑
6
2
‑

喧喧喧司

S
e
a
m
a
i
lVol.4 , No.l・3

ReportfromKyushuChapter

れればいいな 、 と、また貢献したいという気持ちを持っ

A
.

Q
.

r
J
U
I
I
E
T

の文化とはこういうものだよ』というとれはものすごいイ ン パクトがあると思います.

例えば熊本から東京まで

6
4
k
b
p
s クラスの専用 回線でつないだとして、それが、 1

方円くらいですむとしますていてくれたらいいなと 、そ れでいいと思っています 。

よね 。 そうなると、熊本の人は東京の人と1 フロア隣にのがあれば紹介していただきたいのですが.

いるような感じで仕事ができるよ う になりますね 。

A. JUNET の文化の 1 つは、みんな平等であるというこ

発なんかのしくみもできてきたりして 、 JUNETとではないでしょうか .

もそれで、今度は遠隔地との共同プロジェクトや共同開

お互い年格好がわかりませんから、誰か権威のある人があたか

LAN の一部になったかのごとく扱えるようになりますね.

がなんか言ったからといって、そこて'議論が終ってしま

そうすると、企業問を超えた分散環境システムといううわけではありませんし、漢字コードにしても、 00大話がでてきたり、それが急速に普及したりして、今まで学の x x 先生がこう言ったから 、 じゃそれにしようといの電子メールや電子ニュースてー は、考えられなかったコ

うふうに決まったわけではありませんし .

ミュニケーションの手段が出てきたりしますよね 。

それから、 Free Software や PDS を涜しているのも 、

私たちも、もしみんなに専用線が引けるようになった

ソフトウェアでゴハンを食べている人には変かもしれま

ときにどのようなことをやっていこうか 、 ということをせんけど、考えていきたいと思います .

「ソフトウェアはタダであるべきだ」という主張も少し入っているからなんですよね.

そういったところの融合が JUNET の 1 つの文化を創ってきたのではないかと思います .

仏

大学に

JUNET

を広げるために、大学に対して何か積極的なアプローチはなさっていますか?

割と自由な雰囲気というを保っていけたらな、と私はA. 積極的なアプローチというか、勧誘は行なっていま

思っています.

せん。

Q. 9 銅の電子メールが S 時間以内に着くというこ

仮に勧誘したとしたら、私たちに教育する義務が発生

g 銅が東京などの中央に集することになるんですが、今そこまでカプレませんね.

銅のサイトが地方というこ

向こうにそれなりのモティベーションがあるわけですよとになるんですが、堪方に出すメールは、どれくれいね.すると、こちらから roo を読んで 、 xx をインスとなんですが、サイトの中していますよね.

向こうから「つなぎたいんだけど」と言 ってくるのは、ということは、残り1の時間で到着するのでしょうか?

トールしてくださいね . J と言えば、向こうて'やってもらえるわけですよね.

A. この場合、距厳によって時間がどうだ、というのは

それをこちらから勧誘したりすると、人を派遣してイありません.

ン ストールしなければいけないかもしれません 。

距離よりも、メールが到着するまでに 、 一体何ホ ップ

それは私たちが行なう仕事ではないと思っています.

するかというのが問題になります.
あとHST の場合ですと、 SRA との聞は

ほんとうはいっぱいつながっている方が う れしいんで
1 ホップなん

すけど、そこまでして勧誘するほどのことではないな、

ですが、やはり 、 遠いからしょっちゅう電話をかけるということもできなくて、と思っています.

3 時間か 4 時間に 1 回ポール

Q
. 加.さんが電子メールを管理する上で、こういすることになっています 。
で、聞が悪かったりすると 、 メールが届くのに、その3 時間なりうことをやられたら困る、とか、こういう失敗談がある、というのをありましたら教えてください.

4 時間なり待たなければいけなくなってしまう、というのはありますね.
ワーストケースでは中継するマシンのクオリティといA.

うのが効いてきますし、平均ではポールするタイミング

すね.

というのが効いてきますね.そして、一番早いときは 、

困るメールは何かと言いますと 、「長いメール」でたとえば 、 よくネットワークを知っている人が 、 自分

その人に運があったということですね.

のマシンから相手先のマシンまで・の経路なんかも知って

Q
. J
U
I
I
E
T

中継に

いて 、 それで判断して送る分にはまだいいんですけど、をつないでいる因縁の使用料などが極諸

2
4
0
0
b
p
s

のモデムなんかを使っているのにに安くなったり、スピードが笹稽に上がったというこ

200kbyte のメールを送られるととを想定したとき、がれてしまうんですね 。

JUIIET にどういう展開が予想されますか?

30 分くらいそれでふさ

東工大は、専用のマシンはあるんですけど、電話回線
は 2 回線しかないので 、 1 個ふさがれると他に迷惑がかかってしまいます 。

‑
6
3
‑

SeamaﾟVol.4 , No.2・3

ReportfromKyushuChapter

Q
. J
U
I
I
E
T

それに、 200kbyte のメールが 199kbyte 送った後 、 残りの 1 kbyte のところで fail

したら、もう1 回はじにインターネヲト・ウ才一ムというものはなかったのでしょうか?

めから 200kbyte を送り直さなければいけません .

A. 幸いなことに現地時間の

そういうことで長いメールは 、 いくつかに分けて、 1

1
2/2 現在でアメリカの日に 1 個ずっとかにして送 っ ていただけるとうれしいな 、

APANETと思います .

んですね . そこは 、 たまたま CSNET がわりと早い時期にとIP をやっていたところは l つしかなかった

マ シ ンを落してしまったので 、 日本には上陸しなかったQ. 将来 JUIIET を IP 化したいというお話があったのですが、んですね . まあ 、 対策のための伝搬も遅れてしまいましI
P のアドレスがパンクするのはもう自たが.

に見えています.アドレスの確保は、どのように考え...

0

一応日本では被害はなかったと思います.

ていらっし令いますか?

ただ 、JUNET もIP 化すれば 、 いつでも起こり得ます

ね 。 事実sendmailにちゃんとパ ッ チをあてている人とA. 今 、 中クラス以上の大学は 、 クラス B のアドレスをいうは少ないしてすね . それから、メーカーの意識もイ

サブネ ッ トで分割して使っていますが、クラス B のアドマイチです.というのは、東京で 12 月に UNIX Fair とレスは世界でも約 6000 日程度しかとれなくて 、 近いうちいうのをやったのですが、そこで 、 Exhibition

パ ン クするのは目に見えています .

して 、 ネ ッ トワークを張っていました . その説明会のとそれで、クラス E というリザープされている領域を使の一環ときに「必ず対策を行なってください」と私が言って rOKって 、 可変長のアドレスをサポートしたらいいのではな」と言 っ てくれたところは少なかったんですね .

いかとかいう話もあります . あと、楽観的な見方で、じ

具体的な対策を持っていなかった、というのが実情だ

きに OSI になるのだか ら、 あれは最長 23 億テートまでったんですね.

サポートしていますから 、 無限にあると思っていいですよね .
ただ、今のところは日本でバルクでガメてきたといっ

最後にてもそんなにたくさんガメてきたわけではないので 、 ほんとうに今整合しておかないと困る 、 す ぐ に

SEA九州 2年目はすでに始まっています . 早く他の支部

IP でつなに負けない内容の会合を持ちたいと思っています . そのぐ可能性がある、というところを中心にやっています .

ためにまた 、 皆様のお力をお貸しいただけるよ う お願い

別に審査はやっていません.例えば 、 00マガジンや

xx 広報セ ン ターにIPすることもあると思います . その時には御協力をよろしアドレスを割り振りますから 、く お願いいたします .

メールください 、 という広報はやっていません .
SE 且九州の会員、 67名の方々へ.

Q. IPの上位屑{トランスポート・レイヤ}という

SEA九州支部は、より多くの会員の方々の参加をお待ちのは決まっているのですか?

しています . 皆様が抱えておられる様々な問題を出してA. 私たちは新たなトランスポート・プロトコルを開発

決に向けての議論なども行ないたいと考えています . 時する力に欠けているんですよね .

には東京などから講師をお招きし 、 最新の技術情報など

いただき 、 様々な分野の方途と話を交えながら 、 その解

私たちがとるアプローチとしては 、 多分 TCP をそのまも提供して頂いています . せっか く

SEAに入っておられ

ま使うか 、 あるいは VMTT みたいなものを使うか 、 といるのですから 、 SEA をもっと利用して頂きたいと願っていうところで、いずれにしても、既存のトラ ン スポート ・ます . 皆様の積極的な御参加をお願いします.

レイヤの上に、広域分散環境で使いやすいようなアプリ

SE且九州に関する要望や意見などどぎいましたら、ケーションを作るというゴールがあります .
あとは 、 その聞にど う いう

SEA九州支部連絡先の平尾 (TEL 096 - 344-2611:8ST 内

rpc が必要で、トラ ン スポ

}まで御連絡下さい.

ート・レイヤでは足りなかった部分をこうやって誤魔化

そうとか、

TCP の上にもう一つトラ ンポート・レイヤをフィードパ ッ クしようとか 、 ありますね .
能率という観点からはまだまだなんて'すが 、 一応動くという環境を提示しておいて 、 徐 々 に良いものにしていきたいと思います .

‑
6
4
‑

SeamallVo1. 4 , No.2‑3

Memberetc

SEA 会員状況(平成元年6月 10 日現在)
<男女分布>
1560

84

布

財域

地地 8015m11764
住住
居
居

お畷

=========戸=<年齢分布>
20以下

2024
2
52
9
3
03
4
3
53
9
4044
4
5
̲
4
9
5054
5
55
9
60以上

11521

日 ω ∞辺 %l 幻

812

0
3
7
3
1
5
4
4
4
380

2
8
4
1
1
5
3
2
1
9
1
6

<血液型分布>
A型

632

0型

479

B型

360

AB 型

173

333

賛助会員会社名
ジェ ーエムエー システムズ，日本システム，リコ ー システ
ム開発，

SRA ， 辻システム計画事務所，

PFU ，近畿日本ツーリスト，東電ソフトウェア，セントラル-コンビュー タ・サ ービス ，日本能率コンサルタント，檎造計画研究所，ケーシーエス，サンビルド印刷，日本システムサイエ
ンス，富士ゼ ロ ックス情報システム，

1N 情報センタ ー ，

富士通， エムテイ シ ー，クレオ，情報 システムサ ービス，
インターナショナル・データ・リサーチ.目立ビジネス機
器，アトラス情報サービス，三菱電機セミコンダクトソフ
トウェア，伊藤忠エレクトロニクス，三菱電機，富士通 B
SC ，千代田製作所，村田技研，ニコンシステム，日本ビジネスデータプロセ シングセンター，阪神計算センタ ー ，
昭和電工コンビュータサービス，エヌ・ティ・テイ・シス

却
6

臼 01151141

却 4 お 26Goo-25om6Moll51141

臼 8MH34叩目印 H626oo--250

乃 MlM343U2%2192

北青山富岩福秋新栃群茨埼千東神山長官回福石静岐愛和三滋京大奈丘ハ愛徳吉向香鳥島岡広山福大熊長{呂佐鹿沖韓米豪

山
一崎崎賞一郎縄国国州
一昨森形城手島田潟木川馬
城山玉
奈知
梨重野
井葉
川京
岡皐
歌
賀都阪良庫媛島川
知取根山島口岡分本

び員
よ即 9016m1176522M

地葱

の

員
A耳
正

臓

男

女

テム，日本情報システムサービス，ヒラタ・ソフトウェア
・テクノ ロジー ， 日本エム ・アイ・シ ー，日本電気ソフト
ウェア，ソニー，コマス，三菱電機コントロールソフトウ
ェア，インターフィールド-システムズ，ジャストシステ

ム，マイクロリサーチアソシエイツ，松下ソフトリサーチ.

シャープ，東洋エンジニアリング，日本ユニシス

ソフトウェア，消鳳オフィスメーション，新日鉄情報通信システ
ム，テツクシステムズ，熊本電子計装工業 ，NTT 九州技術開発センタ，立石ソフトウェア，三菱電機関西コ ン ビュ
ータシステム ， 目立エ ンジニアリング，スインク，テスク

‑
6
5
‑

r=、k

z.宝~~

TT

s
e
a

ソフトウェア技術者協会
干 1 02 東京都千代田区隼町会 1 2 穏和半蔵門コーフピル 505

TEL.
0
3
‑
2
3
4
‑
9
4
5
5 FAX.
0
3
‑
2
3
4
‑
9
4
5
4