／＼

嘲伽劇

NewsletterfromSoftwareEngJneerSAssociation

V。1．14，N。mbe，lApril，2004

目次

自己組織化するプロセスを作る−SPOへの招待
YetAnotherViewofSPIBaseduponActtlVityTheory

伊藤昌夫

2

岸田孝一

19

新森昭宏

25

自然言語処理技術を用いて特許請求項の可読性を向上させる手法に関する研究について
華東師範大学軟件学院訪問
キューバ危機とソフトウェア危機

荒木啓二郎

30

佐原伸

34

ソフトウエア技術者協会
SoftWareEngineersAsociation

ソフトウェア技術者協会（SEA）は，ソフトウェアハウス，コンビュ〟タメーカ，計算センタ，エンドユーザ，大学，研究所など，それぞれ異なった環境に置かれているソフトウェア技術者または研究者が，そうした社会組織の壁を越えて，【各自の経験や技術を自由に交流しあうための「場」として，1985年12月に設立されました・
その主な活動は，織閑話SEAMAILの発行，支部および研究分科会の運営，セミナー／ワークショップ／シンポジウムなどのイ

ベントの開催，および内外の関係諸団体との交流です．発足当初約200人にすぎなかった会員数もその後増加し，現在，北は北海
道から南は沖縄まで，450余名を越えるメンバーを擁するにいたりました．法人賛助会員も20社を数えます・支部は，東京以外に，関西，横浜，名古屋，九州，広島，東北の各地区で設立されており，その他の地域でも設立準備をしています・分科会は・東京，関西，名古屋で，それぞれいくつかが活動しており，その他の支部でも，月例会やフォーラムが定期的に儒催されています・「現在のソフトウェア界における最大の課寛は，技術移転の促進である」といわれています・これまでわが国には，そのための適切な社会的メカニズムが欠けていたように思われます・SEAは，そうした欠落を補うべく，これからますます活発な活動を展開して行きたいと考えています．いままで日本にはなかったこの新しいプロフェッショナル・ソサイエティの発展のために，ぜひとも，あなたのお力を貸してください．

代表幹事： 荒木啓二郎
常任幹事：熊谷車

幹事：

高横光裕

田中一夫

玉井哲雄中野秀男

石川雅彦大場充落水浩一郎

深瀬弘恭

窪田芳夫小林修小林允桜井麻里

酒匂寛 塩谷和乾 篠崎直二郎 新谷勝利 新森昭宏 杉田義明
中来田秀樹 野中菅 野村行意 野呂昌満 増山穀 平尾一浩
藤野誠治 松原友夫 渡遺雄一

事務局長： 岸田孝一
会計監事： 橋本勝 書相成弘分科会世話人

環境分科会（SIGENV）：塩谷和範

田中棋一郎 渡達雄一
致育分科会（SIGEDU）：君島活 篠崎直二郎 杉田義明 中圃順三
ネットワーク分科会（SIGNET）：人見庸 松本理恵

プロセス分科会（SEA−SPIN））：伊藤昌夫塩谷和範高橋光裕 田中一夫端山毅藤野誠治
フォーマルメソッド分科会（SIGFM）：荒木啓二郎伊藤昌夫熊谷章佐原伸 張湊明 山崎利治
オープンソース分科会（SIGOSS）：石川雅彦

支部世話人 関西支部：

横浜支部：

岸田孝一

杉田義明

鈴木裕信

テブコシステムズ

盲士通

中野秀男

小林修 中野秀男 横山博司
野中曹

藤野晃延

北條正顕

名古屋支部 ：石川雅彦 角谷裕司 野呂昌滞

九州支部： 杉田義明 武田淳男 平尾一浩
広島支部： 大場充 佐藤康臣 谷純一郎
東北支部： 布川博士 野村行憲
賛助会員会社：ジェーエムエーシステムズ
オムロンソフトウェア

ダイキン工業
リコー

オムロン

NITデータ

SRA西日本SRA PFU

キヤノン

新日鉄ソリューションズ

音士電機

ヤマハ

ブラザー工業

オリンパス

オープンテクノロジーズ

El本紀合研究所

SRA東北（以上20社）

SEAMAIL

Vol．14，No．1

2004年4月1日発行

編集人岸田孝一

発行人ソフトウェア技術者協会（SEA）〒160−0004

東京都新宿区四谷3−12

T：03−3356−1077F：03−3356−1072

丸正ビル5F

E−mai1：Sea＠sea．orjp URL：http：／／www・SeaJp

印刷所有限会社錦正社 〒130−0013東京都墨田区錦糸町4−3−14
定価 500円（禁無断転載）

TbchnicalContribution

Vol．14，No．1

自己組織イヒするフPロゼスを作る」亭POノ＼グフ招待−

伊藤昌夫
株式会社ニルソフトウェア◎2003NilSoftwareCorp．

＿1．

Ⅵ）1．14，No．1

恥chnicalContributiom

旦迭
1．はじめに
4 4

1．1．SPOvs．SPl

4

1．2．何が新しいのか

5

1．3．ソフトウェア開発におけるカイゼンとは何か？そしてSPO

6

1．4．SPOによって健全な組織とソフトウェアを作る

6

2．モノとコト

7

2．1．コト中心の世界観
2．2．プロダクトの良し悪し7

2．2．1．プロセスはモノではない
2．2．2．プロダクトの良し悪しもプロセスによってしか分からない

8

2．2．3．物象化による錯視

89

3．プロセス最適化の一つのある例

91

O

3．1．ある物語
3．2．物語と真実l1

14．組織のプロセス最適化
12

4．1．ボトムアップによる新たな組織化
4．2．SPOは誰が実行するのか．

1

2
1

2

4．2．1．SPt視点：プロセスグループ

1
1

4．2．3．SPO視点：実行主体は明らか

1
1

＿2．

8

⑥2003NilSo氏wareCo叩．

1

サイドバー「SPIでないもの」

7

C．

1

B．サイドバー「プロセスの成熟」

6

A．サイドバー「SPA：ソフトウェアプロセス評価」

4

5．まとめ

2

4．2．2．バランスするQCD

TbchnicalContribution

Vol．14，Noこ1朗，さ物鹿‥
多々の効だ偽甜できない．
そうだ

発菊地ゲルだ
そしてそれば新一ぶ「巨二大で邸平助できる一
二勿つろ命鰍．
男臭だ

薪離縁にある．
オククビオ・パス（実切札「予行綴裟／腰オククビオ・パス親上土 美美軒踏

楯
（プ毎グデマばプbクワ仏メ好きで紗襟い．ノ
ウセクワやば怠け者で㍉見好に対す石窟戯牝受tい．ノ
よタぴと知らず
テレビを見ている嬰児
何かを見つけ叫ぶ

激しい動きの中で 全身を緊張させてフロイドの糸車 彼をはこぶ
そおっと
そおっと
そして気付かぬよう

あなたは やはらかな胸に 銀の刃物を突き刺す

宇宙を超えた身体は 小さな人間のサイズに胸に大きな穴を開けた灰色の大人たち
さむい
さむい

胸の暗黒の空洞を みなあせる
あせる（おわかりでしょう）
大人の胸の空洞にモノで埋める

いつも モノはこぼれおちる

いま赤い血を滴らせた 穴を持つこともが わらっている◎2003NilSoftwareCorp．

膿TbchnicalContributionⅥ）1．14，No．1

エJ．ぷRワγ乱」汀y
SPOというのは筆者の造語になります．ソフトウェアプロセス最適化（So氏WareProcessOptimization）の略になります．対概念として，ソフトウェアの世界でよく知られた言葉にSPIがあります．先ず，SPIの説明から始めます．
SPIという言葉は，ソフトウェア開発の現場において知る人ぞ知るというものから，もう少し拡がりを持ってきたように思います1．ちなみに，−SPTは，So氏WareProcessImprovementの略語になります．一般にはソフトウェア

プロセス改善（活動）と訳されることが多いようです．
もともと，このSPIの議論が面白いのは，ソフトウェアが置かれている特殊な状況があって，それになんとか対応しようとしていることだと思います．その特殊性というのは次のことになります．一つには，ソフトウェアは，
所謂ハードウェアのような製造工程を持たない．次にソフトウェアは単品である，即ち一回限りでしか作られないこと，最後に，周辺技術の進化が激しいこと（プログラム言語，基本ソフトウェア，手法…）が挙げられると思います．
しかし，ハードウェアも大変化に対する対応が必要である，という備向を持つようにも思います．その意味でソフトウェア開発の問題というのは，極めて現代的な状況を，先取りしているのかもしれません．
その中で我々ソフトウェアに関わる人間ははどうしているのか？ということをご説明したいと患います．更には，これまでにSPIを通して，分かってきたこと，解決できてないことも合わせてご紹介できればと考えています．

ノ．且新功もいのか
さて，ソフトウェア開発に対して，他の分野の人はどのように考えるでしょうか．ある人は，進んでいるように思うでしょうし，別の人はとんでもない仕事の仕方をしていると思っていることでしょう．殆どの人は後者でしょう

か．多分に専門化が進んでいないという意味で，そういう批判を受ける余地は多々あるでしょう．それには，
ソフトウェア産業が主たる部分でゼネコンと同様なピラミッド構造をしているとか，教育を受けることなく参入する人が多いといったことを挙げることができます（多くの場合，人月でコスト計算がされるもいう事実がそれを証明しています）．

しかし，ここではそのように暗い話は脇において，ソフトウェア開発においてSPlが切り開いた新たな地平の話をしたいと思います．それはものつくりに係る様々な分野において，有効に機能すると信じています．ちょっと遠回りの説明をします．しかし，ここで迂遠な道を通らない限り，単なる他分野の視点でしかSPIを見ることができなくなります2．そうだとすると，少なくとも他分野の人にとっては，何のメリットもない議論になりますか

J．ユノアクエア屏君にお力カイセシせぼ角形JPそして5托）SPIは先にも書いたように，ソフトウェアプロセス改善と訳されることが多いようです．しかし，私は余りこの訳語が好きではありません．プロセスはモノではないので，改善（カイゼン）しょうがない．このようにいうと，そん
なことはないだろう．君は製造現場のQC活動を知らないのか？といわれそうです．ただ，ソフトウェアの場
合は違うと思っています．ハードウェアの製造過程のように同じものを生産する場合には，歩数を数えたり，
ストップウオッチを持つことの意味はあります．しかし，ソフトウェアでは同一のものが生産されることは決して！ありません．また，同様にソフトウェアを取り巻く技術的環境は急速に変化します．例えば，数年前にだれがここまでWebベースのシステムが広まることを予想しえたでしょう．
このようなソフトウェアの世界において，カイゼンは古いパラダイムにおける成功体験でしかありません．カイゼンというよりは，環境へ適応可能な柔軟で健全な組織を作ること，これが現代の新しいパラダイムでのキー

1例えば．経済産業省の次の新聞発喪参照「ソフトウエアプロセスの改古に向けて、SRへの今後の取組み〜」
rht持ノー／■酬∬e書L節．1以来血野甘旬は組付〔㌫墨執加ぬ小雨

2なんと多くのSPIの議論が，製造メタファのもとになされてきたことか！

◎2003NilSo什wareCorp．

．4．

臣1tchnicalContribution

Wl．14，No．1

ワードになるだろうと思います．即ち，個々の一回限りのプロセスはもとより，自己組織化を可能とする（メタな）プロセスを作ることが重要になります．
そしてそのことが，カイゼン概念を引きずるSPIという言葉よりも，ソフトウェアプロセス最適化（SPO）という言

葉を使用する理由になります．

エ45托）によって鰍クェアを伊方
この健全なというのは，SPINのメーリングリストで色々話をしていた中で，新谷さんがおっしゃった言葉です．
この健全というのは，もとの趣旨とは違っているのですが，とても気に入りました．SPO（ソフトウェアプロセス

最適化活動）とは健全な組織とソフトウェアを作る行為だとも云えるのではと思います．このことについては後でまた述べることにしたいと思います．

SPOはもちろんたった一人でも始めることができます．しかし，最終的には組織が変化しなくてはなりません．
変化によって環境に適合する形を組織が得たときを良とします．ただ，注意が必要なのは，不断に衆境は変化するわけですから，常によい状態にいる必要があり，そのことをここでは「健全」と呼んでいます．

◎2003NilSoftwareCorp．

．5．

TbchnicAIContributionⅥ）1．14，No．1

SPOという時に注意しなくてはいけないことがあります．あくまでプロセスをみるのだということです．お客様にお渡しするのは，プロダクトなのですが，あえてプロセスを見る．或いは，プロセスを見るしかない．ここに最初の難しさがあります．
√最初に，プロセスを見るということの意味を考えます．次に，SPOが合意するようにプロセスを変更するということは，プロダクトにど甲ような影響を与えるかということです・

迂遠ですが，先ずはその点から考えてみたいと思います．

之エコ中心の燈葬野物事という言葉があります．辞書によれば，「一切の有形・無形の事柄」とあります．或いは「事物」と云う言葉もあります．この時は，物事と同じ意味で使われる場合もありますし，ある特定の事象における，事件（起こったこと）と関連する物を指します．

このように事物ないしは物事からは分解を通して，「こと」と「もの」を得ることができます．廣松氏の言葉を借りると［2］次のようになります．先ず暫定的にモノも「 名詞類 で表される与件」であり，こ』は「 文章態 で表わされる事態」である．「ウシが逃げる」というとき，ウシはモノで，「ウシは逃げる」というのがコトに相当します
なんとなく，分かったような気になります．
、
廣松氏は，精緻に分析をするのですが，それはさておき，ウシは絶対的にウシではないのだということを理解する必要があるのではと思います（多くの場合，ウシの代わりにcattleでも良い）．良い例として，「コレは逃げる」というときに，コレは何であるかということは，ある意味どうでも良いわけです．少なくともコレというモノはないのですから．
それは指示子の話である．便宜上コレといっているだけで，それはウシをポイントしている．しかし，これもそう簡単ではないだろうと思います．クリプキ流の指示に関する議論を待たなくとも，この発話で言われるコレ
は，逃げるものとして措定されているからです．指をさしてコレといっているかもしれませんが，指さなくとも逃げるという言葉でコレは（走っている）物体だということが分かる．

モノ的に見れば，ウシというものが厳然としてあり，それが走っているということになります．しかし，コト的に見れば，走っているというコトがあって，その事態の一部としてコレやウシがあるということになります．

このことは我々の認識が先ずはコト的であろうということに起因しています．反省的にコレは（このスピードでこの大きさならば）ウシだというのはあっても，「走っている」ということが先ずあるのだろうと思います．
先にお話したように，お客様にお渡しするのはプロダクト（モノ）であって，プロセス（コト）ではありません．しかし，認識的にはプロセスが常に優先します．このことは，認識論だけに限りません．ソフトウェア自体が，そもそも（岸田さんがよくおっしゃるように）プロセスを内在しています．

給与計算をするプログラムは，給与を作っているわけではなくて，ある給与計算のプロセスを（人間に代わり）実行しています．ソフトウェアというプロダクトもユーザのプロセス（それは新たに作られる場合もありますが）をなぞっているということになります．
開発プロセスと製品が内在するプロセスはもちろん別です．しかし，ソフトウェアがお客さんのプロセスを観察し，場合によっては新プロセスに変更することを企画し作るものである．そのことは我々自身の開発プロセスにおいても同様であるということは，最低限いえると思っています．
3この文は昔オブジェクト指向について書いたところを殆どそのまま使っています．オブジェクトとというとモノだと考えるし，多くの入門書の類もそのような現明をします．しかし，それでは確実に行き詰ります．理由は簡単で世界はコト的にみるべきだからです．
あなたの周りを見渡して，だまったまま居る机やイス，白いだけの部屋，こんなものを計算機の中にモデルとしてもちこんでもしかたがないでしょう．
◎2003NilSoftwareCorp．

．6．

TbchnicalContribution

Vol．14，No，1ZAプ物の良風
プロセス改善に関して，以前，次のような議論がありました．「プロセスを良くしたら本当にプロダクトは良くなるのか」．
これは主として品質に関する問いだろうと思います．もし，プロセスを良くしたところで，プロダクトが良くなるという保証ができないのならば，何のためにするのだ，というのは，云わばプロセスに関わる人間にとって，常に気にかかる頭の上の重石のような存在であったわけです．

これに関して幾つかの説明があります．それは，私がその証拠を持っている，ということではありません．プロ
セスについて考えるということは，一見ただプロセスを見るということのように思いますけれど，プロセス思考とでもいうべき意識が必要になります．

之AJ．フ17セスぼモ／でぼない
先にも書いたようにプロセスはモノではありません．ですから，良いプロセスという云い方はそもそもが錯覚になります．ソフトウェア開発には多くの人が関わります．従って，このような錯視が生じやすくなります．典型的には，あなたのプロセスはと聞かれて，キャビネットを占領している社標準を示すようなものです．

プロセスは，そこに関わる人々の関係によって定まります．例えば複数の人が集まれば，何か暗黙のルールができますが，そのルールに従って人は行動するようになります．活動理論における我々の活動の説明はこのことを良く表現しています．
、

現実世界

こゝ

コミュニティ

規則「二二一図1．人間の活動システムの構造（Engestr蝕1，Y．1987）

現実世界の中で，私はツールを用いて対象に働きかけることによって何かを作ります（もちろん，ここでの何かは私にとってはソフトウェアです）．私は一人でソフトウェアを作ることはなく，何らかのコミュニティに属しています．そこでは，分業と規則があります．
ですから，良いプロセスは何かというのは，多くの場合問題の立て方が間違っていきす．ある与件の中で，結果がどうだったかしかいえません．A組織のプロセスは成功したから，私もそうしようといって，仮にそのマネができたとします（それすらも何をしてマネというかがありますが）．多くの場合望む結果を得ることはできません．そこには別のコミュニティがあり，人間が異なりますから，当然違った規則を持ちます．また働きかけるべき対象も異なりますから分業（作業分担）も異なります．他でのプロセス（活動）がそのまま移入できないということは，当然の結果です．このことは良く理解しておく必要があります．

例えば，ある変更をプロセスに加えようとする時，通常は抵抗に出会います．抵抗があるというのは，上記で説明したようにごく自然な反応です．そこをトップダウンでというやり方もあるでしょうが，一番良いのは，その変更が直ぐに効果を持つことを説明できる理解が得られることであると思います．もちろん，プロセスの変更◎2003NilSo抒WareCorp．

．7．

TbchnicalContribution

Vol．14，No．1

は，非常に小幅な変更を繰り返すのでない限り，理解を得がたい．それによる効果が想像できないから．その場合でも，パイロット的に特定のプロジェクトで実施するなどを通して，最終的には理解を得るべきだろうと考えています．逆にそれができないのであれば，そこには新しい規則と作業分担を持ったコミュニティは生まれないのではと思います．

22之プ柳の虐凰邑フせせス仁よってLガ幼jらない
一方で，プロダクトというのは，何かしらそれだけで直ぐに良いか悪いかが判定できるように思います．ソフト
ウェアはそれができないから難しいという云い方も良く聞きます．
しかし，よく考えてみると，プロダクトの良し悪しの判定というのは，今では殆どプロセスを見るしかないわけです．このことはハードウェアでもソフトウェアでも同様です．

例えば，ソフトウェアが仕様に対してある妥当性を持っているかということは，多くの場合テストによって判定することになります．そこでの不具合の数によって，出荷判定をすることになります．もし，テストを実施なけ
れば不具合もゼロなわけです4．
テストというプロセスがあるからこそ，プロダクトの良し悪しが分かります．このことは，もちろん，多くのハード
ウェアの検査においても，それが検査という「プロセス」である以上，同様です．

ええ工物象此皿働
物象化という言葉によって示される代表的なものに，貨幣があります．紙幣は紙に過ぎないのに，大事に持ち歩きます．それは，その紙が大事なわけではなくて，それが何かと交換可能であるという点において，大事なわけです．逆に云えば安心して何かと交換可能である場合にのみ，大事なモノとなります（スーパインフ
レにならなければ通常は）．またそこには軽重があります．殆どの人にとって，一万円札は，千円札よりも立派に見えるでしょう．もちろん，原価は多少違うのでしょうけれど，それが立派なのは，より多くのものと交換可能であるという点においてのみそのような上下関係がつきます．
コトだけで生活するのはつらいので，必ずモノで代表させます．我々の認識も多くの場合そのモノに頼ります．それはそうすることが通常は楽だからであって，組織のプロセスを変革しようとする場合に，そのモノに頼ることは，錯視を正とするという意味において（つまり幻を扱おうとすることになるので），多くの場合間違えることになります．その良い例を上記に2つ挙げました．

4もちろん，ある一定以上の不具合が出てこないと，テストプロセスが不十分であるという判定を下す方法もあります．実際にそのような組織もあると思います．しかし，対象が常にあるレベルの品質を持たない限り，そのことに妥当性がないのは同様です．ここでも，ソフトウェアが一回しか作られないものであることが関係しています．

⑥2003NilSoftwareCorp．

・8・lTbchnicalContributionⅥ）1．14，No．1

こんな声が聞こえそうです．抽象的な話ばかりで分かりにくい．それで，かなり簡略化しますが，一つの物語を作ることにします．

且エある勿夢受託の開発をしているA社の若い人は，いらだっています．毎日のように残業が続きます．それでもプロジェ
クトの終わりが見えてきません．本当は良いものを作りたいのだけれど，仕事に追われて十分なテストをすることもできません．なんとかしないと燃えつきそうです．
一方で，プロジェクトマネージャや会社の上層部もいらだちを隠せません．次から次へとプロジェクトはオー

バーランするし，コストは超過，リリース後の不具合で，お客さんからは叱られっぱなしです．
みんな，それぞれの立場でなんとかしたいと思っています．しかし，品質を重視しようとすれば，納期はもっと遅れますし，コストもかかります．コストを絞ろうとすれば，倒れる人もでてくるでしょうし，品質が悪くなるのは目に見えています．結局のところ，QCDはトレードオフで，それぞれを解決する良い策が思いつきません．

行き詰っているところで，社内向けに開発ツールを作っているBさんはふと思って，遅れに着目することにしました．いつも遅れているのに何故お客さんは嫌にならないのだろう．確かに機嫌よくはない，いつも叱られるけれど，終わればまた次の仕事を発注してくれています．それはコストが安いから？他ではない技術を自分たちが持っているから？もともと納期を気にしていないから？どうもそんなことはないようです．

では，見積りがいい加減だからでしょうか．確かにソフトウェアの見積りを完全にする方法などありません．しかし，本当に曖昧ならば，プロジェクトの半分は納期を超えたとしても，残りの半分は納期以内に収まるはずです．自然界はそのようになっているはずです5．では，なぜ，いつも遅れるのか．・
何かお客さんが満足している点があるに違いありません．よくよくプロジェクトの人から話を聞いてみると，最初は曖昧な要求で，それは開発が進むにつれて決まったかと思うと，また変わるということがおきているようです．それはお客さんのビジネス要件で，そのことを否定できない．お客さんに向かって，仕様を凍結していただかないと作れませんとはいえない．何れはそういうのだけれど，それだとそのソフトウェアの存在価値がなくなると云われれば，仕方がない．その変更を最後まで飲むことによって，お客さんには満足があった

わけです．
ここでもまたトレードオフの問題になりましたが，これを与えられた条件として，解決することをBさんは考えた
いと思います．そうすると問題のある細部が見えてきました．次々来る要求に対して，情報がきちんとみんなに伝わっていない．ある人は要求が変わったということで，他の部署とのインターフェイスを変更します・しかし，その部署では変えられたことを意識していません．もともとその変更は自分たちに関係ないと思っていましたから．テストをしている人たちは人たちで，混乱しています．なにせ，次から次へと似たようなものが開発側から吐き出されてくるのです．何をどうテストすれば良いのかが，分かりません．今テスト中のものを一旦終了し終えてから，変更箇所だけを新しいモジュールでテストするのか？それとも古いものはテスト途中でも捨ててしまうのか？それだとテストがいつ終わるのか分からない．
このことが，問題として大きいということが分かりました．QCDの劣化という現象に対して，すこし様子が分かってきたことになります．

：
−
．
．
−
1
﹄
一
﹄
−

どうもお客さんの頻繁な変更要求に対応できていないようです．そこで次のように規則を決めることにしました．先ずはある段階のものを基準とします．これにバージョンゼロと名前をつけます．お客さんから変更して欲しいという要求があったところで，はい分かりましたと返事するのではなくて，みんなで（各サブシステムの担当者やマネージャが全て出席する場でという意味です），その情報に関して議論することにします．ここでお客さんの希望を聞くか，どうかを決めます．それによる影響範囲はどこまで及ぶかといった調査や，どの時5もちろん．我マは人為的な世界に住んでいるので．必ず営業的な圧力がかかるたれ平均はオフセノトLます．二二では圧力がかかるまでとしています．

◎2003NilSo舟wareCorp．

TbchnicalContributionⅥ）1．14，No．1

点から反映するかを決めます．
変更指示は個々に差分として管理します．変更がまとまったある時点で，リセットをしてノバージョン1と名づける一連の要求やモジュールを作ることにします．
これによって，自分たちが何を対象に仕事をしているか（例えば，どの仕様書に従って設計したり，実装しているか）が分かるようになりました．また，お客さんにとって小さな変更でも，影響範囲が広いのでとといった形で要求自身も整理され，お客さんに説明しやすいものとなりました．
相変わらずの忙しさには変わらないものの，より納期に対しては確実になりましたし，テストが整然と行われるようになり，重大障害も総じて少なくなっていきました．Bさんは，よりこういった要求の整理が楽になるようにツールを提供しようと思い始めました．

且且挽麦芽
先の物語は物語として，勝手に作ったものです．所謂，ソフトウェア変更要求や技術指示書に基づく変更管理の採用により，何が変わるかを示したものです．
この物語の中では，実に簡単に要点が分かったように書いていますけれど，たった一つのプロジェクトでも規模が大きくなると，数ヶ月の調査が必要になる場合があります．なぜならば，複数の要因が絡み合っているからです．定性的に，XXXをすればよいというのは，簡単ですけれど，それでは損失の方が大きくなるかもしれない．上記の場合ですと，みんなで変更要求を議論する場（これは教科書的にはソフトウェア構成管

理委員会：SCCBと呼ばれるものです）を作って議論したりする時間や，流通させる変更・構成情報の管理にかかる手間になります．お客さんからみても，何かレスポンスが悪くなったように感じるかもしれません．全て
はトレードオフなのです．利点が大きくなければ，単にコストをかけることはムダです．

様々な現象から，原因を見つけ，対処の損得を考えた上で，どうするかを決めることが，実際のプロセス最適化では必要になります．

⑥2003NilSoRw訂eCo叩．

．10．

TbchnicalContributionⅥ）1．14，No．1

AJ．ポムアブプ よよ 虜虜 髄励
先の例は，あるプロジェクトに関してでした．個々のプロジェクトを成功させるというのはもちろん重要な問題￣です．しかし，ここで得た知見をモトに，ボトムアップ的に組織そのものを変えていくことができます．
Basiliさんの経験工場［3］の概念を借りて，パッケージングを行います．パッケージングとは，あるプロジェクトで得られた経験（そこには様々な条件と実行されたプロセス）をできるだけ数値化し整理することを示します6．
これによって，あるところでの経験が（そのまま使えるというわけではないものの），他のプロジェクトで再利用できる可能性が高まります．
もし，そこに傾向があれば，それに応じた形に組織を変えたほうがよいことになります．この変えるということの意味は，場合によっては単純な組織の変更かもしれませんが，通常は対顧客との関係や開発者の教育といったことも含みます．

何らかの傾向は存在する可能性が高いといえます．ある組織を考えたときに，常に全く異なる製品をいつも作っているわけではありません．全く同じではなくても，類似の製品を作っている．その時には，必ず何らかの傾向を見つけることができます．
ここまでが，ボトムアップでのアプローチになります．もう一つは，トップダウンの方法です．全て決めうちで変革してしまう．ある特定のプロセスモデルに合うように，既存のプロセスを一律変更する．よいやり方のようには思いませんが，一般的にはこちらの方が多いように思います．導入までの時間が少ない，いきなり全社レベルで変更できるといったことが利点といえば，利点でしょうか．

どちらがよいかは勿論その企業おかれている立場によります．ただ，最適化ということを中心に考えるならば，
ボトムアップしかないように思います．
次に示す図は，Agile系の開発手法の一つである適応型ソフトウェア開発［4］にある図を援用します．
もともとの

ゴール

新しい
ゴ・一ル

図2．変化するゴール
組織のゴールが今関心を持っている時間フレームに対して，固定と考えることができる場合．ある定まったプ
ロセスモデルを導入すれば，何とかゴールにたどり着けるでしょう．しかし，環境の変化によってゴールも変化するのだとすると，固定することは阻害にこそなれ，役には立たないことになります．
最初に健全と書いたのは，SPOにおいてバイアスをかけないという意味で上記のことをお伝えしたかったのb単純なプロジェクトの掛値りを示す幾つもの言葉があります．PIR（PosT rmplemenTcEnOn RevleW

実装後のレビュー）．PosImorlem（事後分析）．

PosTrロUdlI（事後監査）．IoopbqCk−nmlysIS（祈（）返し分析）．しかし．ここでは単なる分析だけではなくて．それを次につなげるための整理も含んでいます．

◎2003NilSoRwareCorp．

．11・

TbchmicalContribution

Vol．14，No．1

4且 5托）膨嘆声行すち功一．
まま．．Y弟点／フせせスグループ
ソフトウェアのプロセスの変更は，最終的にはプロジェクトに閉じることなく，個々のプロジェクトを横断し，組織に広がる必要があります．この時に，プロセスに関心を持って組織を見る人々のことを，一般にプロセスグ
ループ或いはSEPG（SoRwareEngineeringProcessGroup）と呼びます．この他には，ソフトウェア開発側で構成管理を行う人や，品新保証（管理）をする人が必要ですが，プロセスに関しては先ずはプロセスグルー
プに属する人たちが対応するとします．［1］に従えば，彼らのアクティビティは次になります．
●●

総てのレベルの管理者の支持を得て，維持する．
現状のプロセスの様子を分かりやすくする．

● あるやり方を変更した時に，その意味を伝えるなど，現場の手助けを行う．
● 開発者と協力して，新しいやり方や技術を入手したり導入するのに協力する．
●

●
●
●

プロセスの向上のためにトレーニングや教育を手配する．

特定のプロセス向上が行われているか否かを検査し，その状況を報告する．
管理者や開発者と協力してプロセス定義を作り，維持する．
プロセスデータベース7を維持する．

● プロジェクトや管理を進めるにあたり，プロセスに係るところで，相談にのる．
［1］では開発人員に対して∴ト3％がこの役割を担うとしています．

4．ええバランスするOCp
先に述べたとおり，実際のプロジェクトでQCDはバランスしている．今，それぞれをあるレベルに維持するためにかけることのできる費用をINV。，INV。，INV。とすると，与えられたプロジェクトに関して以下が成立します．
INV。＋INVc＋INV。＝一定

例えば，納期を短くしようとすれば，lNV。は増加しますから，品質を犠牲にするか，見合うだけ製造コストを変更しなくてはなりません．例えば，調達の仕方を変えることによって実現するということになります．ところが，

このことは決して容易ではありません．部品の調達ではなくて人間が対象ですから，開発者を変える，長時間労働を強いるということは，当然の帰結として，新たな教育が必要という別のコストを生んだり，品質の劣化を招く可能性があります，後者の場合，更に品質維持のためにコストをかけようとすると，ますますINVcが増加することになりますから，更に別の手段をとらないといけないということで，破綻に向かうことになります．

先の例でプロセスグループに対してト3％とはいえ，コストが増大するとすると，それはハイリスクの投資であると考えない限り，個々のプロジェクトは，余計に苦しむことになります．また，開発のやり方の変更は，それが上記の費用のいずれかに効果があるということが明らかでない場合，受け入れがたいものとなります．

ままエ

PP

粛点∴寿行書体ぼ労らか

プロセスグループがなくても，実行の主体は明らかです．開発プロセスにおいての実行主体は開発者です一
しかし，幾つかの注意が必要です．
SPIが持っている製造業的カイゼンの隠喩は，その帰結が明らかな場合においてのみ，実行主体にとってプロセス変更が納得のいくものとなります．ラインで，Aというボルトの入っている良く使うバケットを，Bという余り使用しないバケットの前に持ってくる．ボルトを手にするまでの所要時間が一回あたり0．5秒縮まった．
これによりラインスピードのアップに貢献できたとすれば，目に見える結果ですし，因果関係も納得できます．
7プロセスデータベースとは．プロセスに係る情報を集めたものです．具体的には．個々のプロジェクトに対してプロセス及びプロダクトメトリ

クスとなるものを集約します．例えば．レビューの東施回数や時間．プログラムの行数等が相当します．

◎2003NilSoRwareCorp．

＿12＿

TbchnicalContributionⅥ）1．14，No．1

かつ，これに要するコストはバケットの位置を一回変更するだけに過ぎません．

一方で，ソフトウェア開発の場合は，原因一結果がそれほど容易ではありません．単純に，キーボードのスト
ロークを短くすることで，生産性が上がることは考えられません．或いは，もっと大胆にデータベースの設計
方法を変えたからといってそれが有効か否かは俄かには判定できません．
もともとがかように難しい問題であり，故に答えが常に見つかるわけではありません．これはプロセスグルー
プが居たとしても同様です．

そこで，自身が開発者であるとして何がプロセスに対してできるかを考えてみることにします．
手段は大きく分けて次の2つになります（ここでは，やさしいお客さんが機能を落としてくれたとか，できる新人がふと入ってきて彼は研修期間中でコストに繰り入れなくて良いという億倖はないものとします）．
［対処第−1］プロセスの変更
プロセスの変更は次の三つに限られます．（a）分離するか，（b）併合するか，（C）省略するか，（d）追加するの何れかです．分離の場合は，主として並列的に動作する場合に有効です．単一のアクティビティやタスクSでは当然並行動作ができませんから．併合するのは，不要なオーバヘッドをなくすために取られます．あるプ
ロジェクトで，異なるチームが同様のことを行っている．この時に併合することで，全体の効率を上げるという場合です．省略するというのは，もちろん何かの犠牲を伴います．しかし，その犠牲が省略によるメリットよりごく小さいと見なせる時に省略することが可能になります，例えば，十分なコードレビューがなされていて，かつ動作に関してはモジュール組み合わせで確認でき，カバレッジもこの時に取得できるという場合に，ホワイトボックスによる単体試験を省略するという場合が相当します．最後の追加するは，一般にはかなり高度なプロセスの変更になります．直接的に，原因一結果が見えないという意味においてそうなります．例えば，総ての設計アクティビティに対して，ウオークスルーというタスクを義務付ける．ここではコストが掛かるけれど

それは品質の向上を伴い，結果的に不具合修正に要する時間を大幅に削減できるというのが，このケースに相当します．しかし，本当にそうかというのは，昔あった月着陸船のゲームと同じで，効果が遅れて現れてくる分，判断がしづらいということになります．

［対処策−2］ツールの導入或いは製作
活動理論の図（図1）にあるように，我々が活動するとき必ず道具を使用します．ソフトウェア開発者は特殊な立場にいます．それは，ツールもまた多くの場合ソフトウェアであり，自分達で作れるということです．機械を製造している人たちが，治具を作ることができるのに似ています．それほど，大規模なものでなくても，マクロを書いてみてといったエンドユーザで加工できる環境もありますから，ツール作りにかけるコストはそれほど大きくないかもしれません．

ツールは自動化しますから，その製作コストを下回る自動化効果があれば，十分にQCDに対して貢献するということになります．

一方で，注意がないわけではありません．プロセスに適合しないツールの利用によって，余分なコストがかかる．或いは，個別のツールが増え，組織として一貫したデータ取得が出来ない（誰でも自分の作ったツー
ルがかわいいですから）．

どちらにしろ，実行の主体は，開発者であったり，品質保証（QA）に携わったりしている人であって，プロセ
スグループの人間ではありません．プロセスグループの人間は，単にそのサポートができたり，横どおしの視点を持てるということに過ぎません．決して，機械のように開発者のあなたを動かすわけではありません．
先ずは，当事者である開発者やQAの人がプロセスに対して関心を持つということが重要だろうと思います．

8習慣的に．プロセスはアクティビティに分解され．アクティビティはタスクに分割できるとします．この時．プロセスは開発プロセス．保守プロ
セスといった大きなくくりであり．タスクは．それ以上分解できち・い最小単位であるとします．アクティビティはその中間になります．

◎2003NilSoftwareCorp．

・13・

Vol．14，No．1

恥chmicalContributiom

今回は，ソフトウェア開発におけるプロセス改善の基本的な考え方についてご説明しました・何度も書いてますようにかなり迂遠な説明ですので，お分かりにくかったかもしれません・
しかし，10年以上ソフトウェア開発プロセスに関わってきた人間として，昨今のプロセスをめぐる議論が，レベルの取得とか，何かの認証を取得するといった議論に終始していることをさびしく思っています・もし，プロセスの議論がそこにとどまるのであれば，他の分野の方にも何かしら役に立つという拡がりや力は持ち得ないと思っています．

少し根本的なところからプロセスを考える始めること．次にそのことを踏まえた様々な側面について考察する
こと．そうすることで，最終的にみなさんの仕事のお役に立つだろうことを，私自身は確信しております・▲良一◎2003NilSo氏wareCorp．

駄馳i

●14．

TbchnicalContributionⅥ）1．14，No．1【参考文献】［1］Fowler，P．，Rifkin，S．，

SoRwareEnglneeringProcessGroupGuide，CMU／SEI−90−TR−24，SEI，Sep．，

1990［2］廣松渉，世界の共同主観的存在構造，廉松渉著作集，第一巻，岩波書店［3］Basill，VictorR．，Caldiera，GianluigiandRombach，DieterH．TheExperienceFactory，Encyclopedia−

OfSoRwareEngineering−2VolumeSet，pp469−476，CopyrightbyJohnWiley＆Sons，Znc．，1994．

［4］HighSmith，J．ADAPTIVESOFTWAREDEVELOPMENT：ACollaborativeApproachtoManaging
ComplexSystems，DorsetHouse，2000．

◎2003NilSoftwareCorp．

TbchnicalContributionⅥ）1．14，No．1

SPIという時に，注意しないとSPAの話をして済ますことがある．SPAとはSo允WareProcessAssessmentの略

で，良く知られたものに，CMM（CapabilityMaturityModel一能力成熟度モデルと訳されることが多い）がある．メンテナンスをしているのは米国のSEI（ソフトウェア工学研究所）である．初出は1986年である．

この他に欧州を中心とした幾つかのSPAがある．CMMと同時期から活動しているものとしては，SPICE（SoRwareProcesslmprovementandCapabilitydEtermination）という活動がある．英国がISOに提出した15504という番号のものに対して，試行の意味を兼ねて作られたグループの名前である．かつての欧州共同体のEspritプロジェクトの一つとして実施されたものである．

公式には，ISO／IEC15504が標準であるから，それに従うということになるのだが，これはSPAに対する規格であることを忘れるべきではない．決して，SPIではない．

評価をすれば，自分の位置が分かる．従ってよい点を取れるように努力すれば，いつかは良いソフトウェア
開発ができるようになる．というのも一つの考え方である．しかし，それでも注意が必要である．SElはDoD（米国国防総省）から資金を得ることによってできた組織であり，SPICEに関わる活動も基を辿れば，やはり軍需関係が主体となっている．本来は，彼らがベンダを選別するという意図を持って作られたことを覚えておくべきである．
ちなみに，良く似た概念として，SCE（SoRwareCapabilityEvaluation：ソフトウェア能力評価）というのがある．

図．SPIとSPA，そしてSPO［図の説明：lSt，2nd，3rdはそれぞれ， プロセスの評価を行うのが，第一者，第二着，第三者であることをあらわしている．SPOは先ず自律的な活動であり，深い評価を必要とする．］
これは，SPIとSPAの関係を表したものである．CMMでは，誰の評価かによって区別をつけている・SCEでは第二着ないしは第三者による評定（Evaluation）を指している．第一着（当事者）も関与する評価は，
CBA−IPI（CMMbasedAppraisalfbrInternalProcessImprovement：内部プロセス改善のためのCMMに基づく査定）であり，CMMIの枠組みでは，SCAMPI（StandardCMMlAssessmentMethodfbrProcess

Improvement：プロセス改善のための標準的なCMMIの評価手法）と呼ぶ．

⑥2003NilSoRwareCorp．

＿16．

TbchnicalContributionⅥ）1．14，No．1

下表に示すとおり9，CMMは（その成熟度に関する）原型を辿るとCrosbyに行き着く

表 品質向上活動におけるプロセス成熟度の起源
時期
1930年代
1956年

内容

提唱者

統計的品質管理

Shewhart原則の展開

Shewhart，W．
Deming，E．，Juran，J．

1979年

品質管理成熟度格子

Crosby，P．

1986年

成熟度レベル

Humphrey，W．

1987年−

成熟度フレームワーク，成熟度質問表

SEI

Crosbyの品質管理成熟度格子の一部を以下に示す．

表
測定カテゴリ

売上に対す

2．Awakening

不確実である

目覚めている

みんなが品 質向上につ いての正しい 知識を持って いる計上

未定

る品質のコス ト

会社の態度

品質管理成熟度格子

1．Uncertainty

実際：20％

どうして品質に問題があるのかが分からない

計上：3％

3．Enligtenme nt

計上：8％

実際：18％

5．Cerainty

継続的に品 質向上に努 めている

計上：6．5％

実際：12％

品質に関して
管理者の関
常に問題を
与や品質向
抱えるていな
上活動によっ

くてはならな いのか．

4．Wisdom

実際：8％

確実である

計上：2．5％
実際：2．5％

欠陥防止が，
どうして品質我々の・業務に問題がなの一部となっ
いかを分かって問題を特 定し，解決で きる

ているノ

ている．

［表の説明：初期の段階でのコストは，主として手戻りや不具合対策に大して思いもかけない費用がかかることを示している．品質を維持することを皆が意識することによって予期しない品質維持のための支出はなくなる．これを象徴的に表しているのが書名「品質確保にコストはかからない（QualityisFree）」である．もちろん，品質維持に費用はかかるのである．それは，問題がなくなれば今まで支出していた分をキャンセルできる，或いは非常に小額で済むという意味で，コストはがからないとしている］
1，5に大きな意味がある．1は品質に関する状態が分かっていない．謎ばかりである．5は逆に問題がない理由を分かっゼいる．2から4はその過程できわめて自然といえる．たまたま品質に問題がないことが分かった
りはしないからである．
また，確かに品質は成熟する．完全なる品質！とは，不具合がないソフトウェアと定義できれば，完全なるソ
フトウェアに向かって，成熟するのである（それは漸近線でしかないだろうが）．しかし，CMMが置き換えたよ
うに，プロセスは品質の代替にはならない．開発プロセスは成熟しないからである．そもそも良いプロセスがあったり悪いプロセスがあったりするわけではないのだから．
この品質管理成熟度格子に基づいたCMMにおけるレベルが良く話題になる．これもプロセスがモノでない
以上或いはプロセスとはそこに関与する要素が複雑であるがゆえに，レベルないしは段階そのものに余り意味がない．そもそも，Crosbyも次のように述べている（QualityisFree．pp．111）．

許多家老がβ分点ぼけお血廃ると考点ている．しかしあなたβ身ばそんなことばか1
月廟の削ぎないよぎったとしええとかLそんなことて湘すべきでばか、．虎屋をでて品質脾上のために耕一をしなきい．
9zohrcLn，S．．SOFTWAREPROCESSMPROVEMENTProcIlCOIGuldeilneSforBusLneSSSuccess，AddtSOnWesleY．1998．

⑥2003NilSo允wareCo叩．

Ⅵ）1．14，No．1

TbchnicalContribution

すこしこういうものはSPIではないというのを挙げておく（或いはSPOでないということでも本論では良いかもしれないが）．以下は先の経済省の協議会レポートから．ちょっと長が，引用します．
問題例1）A社では、最近必要充分な品質が確保されたソフトウエアが提供できない。
対応例）A社では、ソフトウエア開発に関連するプロセスを明確にするために、プロセスを定義し、品質が確保できない原因を特定できるようにした。
問題例2）B社では、作業のやり直し（手戻り）が頻繁に発生し、予定よりも多額のコストが発生している。■
対応例）B社では、プロジェクト初期における要件定義の方法がこの間題の主な原因であることを調査により明らかにした。そこで、顧客対応をする営業部門の社員も含めて、要件定義の技術を教育し、また、高いスキルをもっ社員がプロジェクト初期段階で定義された顧客の要件を厳しくチェックすることにより、その後の作業のやり直し（手戻り）を減らし、コスト低減を図った。
問題例3）C杜では、慢性的にプロジェクト遅延が発生し、予定の納期に間に合わない。
対応例）C社では、見謙り技術及びプロジェクトマネジメントの方法が主な原因であることを調査により明らかにした。そこで、信頼性の高い見積り支援ツールを導入し、プロジェクト実施期間をより適切に算出するとともに、プロジェクトマネジメントの高いスキルを持った人材を配置し、プロジェクトの進捗状況を適切に把握・管理することにより、納期遵守の確保を図った。

これは，SPlのすぼらしさを伝えるという例とのこと．明らかに旧世代のパラダイムになる．なんとなれば，Pという問題がある．Pに対して手段Mを行った．上手くいった．という良くできた，ただ単純な物語である・それも手段というのが，無条件にプロセスを定義したとか，教育をしたとかのレベルである．よしんば，これは例だからということにしよう．それでもやはりSPlの本質とはかけ離れているように思う．即ち，コトではなくてモノにしか着目しない．或いは，QCDはトレードオフであり，その止揚にあたってはプロセスを精緻に観察することが必要ということを示していない．問題例3のツールにいたっては，一昔前のCASEブームを想い起こさせる

ような楽天的云い方になっている．そもそも信頼性の高い見積りツールなど，この世にたった一つも存在していない！

SPlに関わる最大の注意事項は以下に尽きる．
自らのプロセスを詳細に観察することなく，あるモデル（手順・ツール・教育・手法）を導入してはいけない・⑤2003NilSoRwareCorp．

．18・

TbchnicalContribution

Vol．14，No．1

WhatisActivityTheory？

活動理論とは？
何らかの文化的・歴史的背景を持つ人間の集団的活動を研究するための概念的枠組みを提供する複合的理論．
教育（発達）心理学＞＞社会学・経営学＞＞CSCW．HCI

WhatisACtivityTheory？
（続き・その2）、

WhatisActivityTheory？

（続き・その1）
分析の基本単位は人間のAd：ivitY．
ActivitYは何らかの目的によって動機

TooLRule，およびDivisio110fLaborがSubjed．Community′およびObjedの相互関係をづけられたSubjed：によって行われ．
Objed：をOutl：Omeに変換する．

mediate（調停）する．

ActivitYは一連のAdionによって行われ．
Actionはまた一連のOperationに0叫ectは目的とするOutく：Omeを目指

よって具体化される．

して一緒に活動するSubjed（Actor）のCdmmuni叫こよって共有される．

】

WhatisActivityTheory？

r（続き・その3）

ActivitYTheoryの発展
・PhHosophy：Marx．Engels

Subjed−Objod−Subjodという相互関係には・PSyChoIogy：Vygotsky，LeOntiv，and

次の3つのレベルがある：

Luria

ーC00rdination：

・Sot：io−Computing：．個々のACtOrにフォーカスr

ーC00POration：

SharodObjodにフォーカスh恍p；／／WW．●du．hもlS】nkL爪／adlv町／P00Ple／eng
出汁ro／−Co−Configuration：

WorkPraCtiC○のフォーカス

YrjoEngdstrnm

80nnioNardi

R色一〇laborationに

h枕P：／／www．darrou王Qt−nardLnet／bonnlo／

5

．19．

6

TbchnicalContribution

ⅥIl．14，No．1

参考資料

5PrinciplesofAT■HiorarchcalStrud：u帽OfAdiv叫

LVigotskY，居着と粛好（紺，新談義社，2002．

Acrfv咋hAc如〃′qPeJ融／OJl】．Engestrom，威名打＝よi輝5：屋敷助1右のアカー■Objod一〇riontodnQSS

汽薪曜社，1999．

00巧0058四才をい／

B．Naadi（ed）′ConkX亡andCondouSneSSニAcが招け

meoγ即d〃uJ¶∂nCompurer加始帽C的∩′MIT■Znternalizatjon／Externalization

働∠ガ脚を局辞に疲穿すること粥必要

Press．1996．

B．Nardi＆D．Redmiles（ed），5PeciaILssueon■

Ac打∨／けmeOJy∂nd的e加C打Ce〆DeSJ卯′

Modiation

人ノ野の一着勤御伽ed伽eJする古のとして■のツ「ル（CSCW誌′Vo111′No・1−2′2002・
WebPage：（Colorado大学Denver校教育学払）■DeVdopmont

轟轟柳ととる／コ駄夢（避此ノダ葛加印ご′′GJ′bo几亡〃鵬〟作れ○血〝仰坤J′仙L由ね′■
dルJ帆hmIJ

8

7

TeChnicalTerrTlの比較（続き）
TooI SE：人間に役立つアプリケーション

AT：主体一対象間の調停を行う物理的または心理的な仕掛けAgent SE：活動を行う人間またはアプリケーション
AT：あるObjectを共有するコミュニティの要

素CommunitY SE：開発チーム

AT：あるObjectを共有するSL巾JeCtの集

まり

工ンゲストロームのモデル

ソフトウェア・メインテナンスの例
J′ゆ（お†（対ねdT，hgn■∫小叩．■l■■蛾霊芝l
見血細田2．，￣叫￣0旬柑≡

琵認諾

⊂加呵t・

慧諾㌻叫仰ア如′宗野

11

．20・

劇血加周Ⅶ血肝邦…

￣

12■カスタマ・サボ⊥トの例▲叫丁鵬W血丁場

伽叫細胞■如票／＼忠 孟≡。畿転
Q唱和由血叫1二lⅥ）1．14，No．1

TbchniealContribution

ATModelforSPIATModeIforSPI−Subjed：−−ObjeCト△、∠泡．．＿1二二二＝−＿＿＿．；：＿．＿1−−∴這ゾ≠＝Xp〝加1＿＿1二．．lL∵∴γ一つ‥．−：W．r久一霊一％ノ九dq−：■一仁〜−〜1−ソ■ノ・脚：′ノ■■■■1

それぞれの役割ごとの予定通りの職能別エンジニア

開発スケジュール

VS

行きあたりばったりの
仕事の進行

万能の
スーパー■プログラマ

C01laborative Activityとしてのソフトウェア開発−Co伯bo帽と／OJlの、βつのレベル

■C00rdination■プロセスモデリング言語■組織のモデル化■ユーザインタラクション
・パラダイム／強鋼／ツール統合■Cooperation■コミュニケーション■アーティファクトの共有
・l尋時世嘱榊■Co−Construction

CoordinatedLeveL

現在の開発支援環境グループまたは組織によって行われる日常的・反lovdに焦点を当てている．

ソフトウェア・プロセスすなわちCOOrdinated

復的な作業に対応する．

ソフトウェア工学のProduction−Orjentod

そうした作業は，あらかじめ計画された順序に、そ れぞれの役割を担うエージェントによって実行される・な思想にうまくマッチしている・：・

現実の作業におけるパターンや定型性を最大限

それらの役割が何かは，なんらかの規則の形で記述されるか．あるいは暗黙の了解事項として認められている．
各エージェントの行動は，あたかも見えない神の手に活用しうる．■しかし，逆に．CdIh■borationの別の個面に関してr盲目」になっているきらいがある．

が餉いているかのように，共通の目標達成を目指して．自然に統合される．

2】

．22．

2●

TbchnicalContribution

Vol．14，No・1

CooperativeLeveL

における障害CooperativeLevel
エージェントのグループの間のインタラクションを含むレベル．このレベルでは，仕事はもはやそれだ
けで独立したものではない．

ソフトウェア工学の背後にあるProdudon−
Orientedな思想が第1の障害である．

それぞれのエージェントの行動は他のエージェント

それは「設計とはCollaborativeな学習・の行動に影響を与え，ある種のシナジー効果をもたらす．

問題解決活動である」という一般の認識と矛盾する．
第2の障害は技術的な間粗である．たとえば，
分散構成管理の技術はまだ確立されていない．

エージェントの関心は．みんなが共有していること
がらにフォーカスされ，相互に受け入れることが可能な概念的枠組みや同類解決手段を捜し求める．

26

Co−COnStruCtive Level

現実作美の再構築に対応するレベル．

このレベルでは．作美それ自体が検討・考察の対象である．
新しい，そしてよりよい仕事のやり方を考えることが主愚である．
Co−COnStrud：ionの結果は，組織および共有オブジェクトとのインタラクションに関する

概念的枠組みの再構築をもたらす．

発達的学習活動としてのSPI
現在のソフトウェア工学の弱点（エンゲストローム）

Production−OrientedProcessという考え■発達は，習得の達成にとどまるのではなく．与えられたものを部分的に破壊してゆく一種の「拒絶」である．
■発達は，学習する個人の転換にとどまるのではなく，その個人が所属する組織の集団的転換である．
■発達は．レベルを垂直的に超えて行くことにとどまるのではなく，社会組織の境界を水平的に横切って行くことでもある．

方に寺されている．
−CooperationSupportが弱いのは．技術的 理由もあるが．それ以前の原因も大きい．
−Co−ConstructionSupportが欠けてい

ることはCSCWやInteractionDesignを考えると致命的．

29
30

．23−

恥chnicalContribution

Vol．14，No．1

モデルの歴史的タイプ
Resourcesdntheweb（追加）（エンゲストローム）

伊藤昌夫さんのコラム：

1．自然発生的な典型

2．分類的・唯名論的

1b地

エンゲストローム先生のVldeoIntervtew：

3．手続き的4．システム的CSCWMagazlneのWebPage：ll■ 山▲．．▲−●1−● ●● ●e XP（KentBeCk）対InteradjonDesjgn（AlanCooper）のディぺ−

5．胚細胞型

ト：

さて．CMMはどのタイプか？
たぶん2と3のあいだ？

日本活動理繍学会のWebPage：

31

h仕P：／／www．jarat．0rg／

．封．

32

恥hnicalContributionⅥ）1．14，No．1

自然言語処理技術を用いて、特許請求項の可読性を向上させる手法に関する研究について
新森昭宏一（インテック・ウェブ・アンド・ゲノム・インフォマテイクス）

1．まえがき1983年に就職して以来、1990年代末に至るまで、ソフトウエア開発環境、ヒューマンコンピュー

タインタラクション、グループウエア／電子メール、ソフトウエア障害対応に関する研究や開発の仕事に従事してきた。2000年秋からは、東京工業大学の社会人博士課程に所属し、会社の仕事を行いながら、自然言語処理の研究、特に特許文書を対象としてその可読性向上に関する研究を行っている。

本稿は、2000年秋以降にこの研究を行ってきた動機、現在までの到達点、これからの方向性についての考察を報告するものである。この研究は、SEA所属会員の関心の中心であると思われるソフトウ

エア工学とは分野を異にするものであるが、私自身は、
1）今後、自然言語処理は、ソフトウエア技術者が活躍すべき・活躍できる有望な分野の一つである
2）好むと好まざるとに関わらず、ソフトウエア技術者は特許というものを意識せざるを得ない状況になっている

3）しかし、特許文書、特に特許請求項の部分は、極めて読みにくく敷居の高いものになっており、
自然言語処理によってその敷居を下げることができれば、ソフトウエア技術者にとっても朗報となるだろうと考えており、本稿として報告するものである。

2．なぜ、自然言語処理か
1993年頃からパソコン向けのパッケージソフトの開発・販売支援・トラブル対応支援に従事し、Microsoft、Novell、Lotus（当時）などのプラットフォームベンダーが提供する「事例ベース」を活用しながら仕事を行っていた。事例ベースの中から状況に適合した事例をうまく発見することができれば仕事をうまく進められること、しかし自然言語で記述された事例が膨大に蓄積された事例ベースの検索は容易でないこと等を実感していた［1］。そこで、BayeSian Networkの形式で不確実な知識を蓄積し、事例ベース検索に利用することを考えた［2］。しかし、自然言語で記述された膨大な事例だけがまず存在する中で、不確実なままでもよいとは言え、どうやって知識を形式化・蓄積するかの課題

は残ったままであった。結局のところ、誰かが（人間またはコンピュータが）自然言語で記述された膨大な事例を読んで理解し、コンピュータ利用可能な形に変換しなければならないのである。
ちょうどその頃ぐらいから、「ナレッジマネジメント」ということが言われはじめ、組織内の知識をどのように収集・蓄積し、有効活用するかが議論されるようになった。私自身も、JavaHouseメーリ

ングリストなど、ソフトウエア開発者向けのメーリングリストに参加し、そこから有用な情報を得ていたこともあって、メーリングリストを対象としてそこから自動的または半自動的に情報抽出・知識獲得ができないかということを考えはじめた。
ちょうどその頃に出会ったのが、北陸先端科学技術大学院大学（当時）の奥村学先生による、テキスト自動要御こ関する一連のサーベイ論文【3］と解説記事【4］であった。これらを読んで、自然言語処理の研究には長い歴史があること、そこには難しい問題が残されていること、しかし着実な進歩もある
ことなどを改めて認識した次第である。そして、ちょうど2000年から東京工業大学に移籍された奥村学先生のもとで研究指導を受けることになった。

ⅥIl．14，No．1

TbchnicalContribution

3．なぜ、特許文書か
かつて特許は、機械・製薬・化学など特定分野の企業において、知的財産権担当者や研究者が主に関わるものであったと思う。しかし、ビジネスやサービスの方法を権利の対象とする「ビジネスモデ
ル特許」の出現や、コンピュータプログラムを対象とした「ソフトウエア特許」の認知により、広い範囲の企業関係者が特許に関わらざるを得ない状況が生まれている。大学においても、研究成果や技術移転のコアとしての特許の重要性が認識されるようになっているようである。
こうした状況の中で、好むと好まざるとに関わらず、ソフトウエア技術者も特許という ものを意識せざるを得ない状況になっていると思う。実際、情報サービス産業協会からもソフトウエア技術者を対象とした啓蒙的なブックレットが出版されている【5】【6】。ソフトウエア特許に関しては、その弊害を指摘する声も多いが、多くのソフトウエア特許が既に成立しており、また日々多くの●ソフトウエア特許が出願されているという現実がある。

特許文書は一種の法的文書であり、以下のような構造を持っている。
・明細書＞ 発明の名称＞ 特許請求の範囲＞ 発明の詳細な説明＞ 図面の簡単な説明
・図面・要約

特許明細書中で最も重要な箇所である「特許請求の範囲」には、「特許請求項1（クレーム）が列挙される。特許請求項の記述は、1文で発明内容を記述するという制約と、記述の長さ、そして独特の記述スタイルにより、専門家以外の人にとっては極めて読みにくいものになっているのが通例である。
図一1に実際の特許請求項の例を示すが、これを一読してその意味するところを理解できる人はいるだろうか？

各種情報を蓄積し掲示用情報として出力するホストコンピュータと、このホストコンピ
ュータと大学構内に付設されたデータ回線網を介して接続し∴前記掲示用情報を入力あるいは受信して表示し、前記掲示用情報に含まれる各種サービスの要求と任意の情報の入力および出力とを行う複数の端末とからなる大学構内掲示板サービスシステムにおいて、前記端末として各種掲示用情報を入力し利用者の要求を受付ける事務端末および図書端末と、前記利用者が使用し前記掲示用情報の取得と前記掲示用情報に含まれる各種サービスの要求と登録と予約とこれらの入力に対応する回答とを表示し出力する利用者端末とを備えることを特徴とする大学構内掲示板サービスシステム。
図−1特許計求項の例（特開平10−11007の第一諦求項より引用）（304文字）

過去に出願された特許明細書の電子データは膨大に蓄積されている。さらに、年間40万件以上と言われる新規出願に伴い、データ量は日々増加している。企業関係者は本来、これらの膨大な特許明細書群を監視し、自分の業務に関連するものがないかどうかをチェックする必要があるが、量の膨大性という面と、記述の特殊性という面の両面において、これは現実には困難である。
自然言語処理技術によって、特許請求項の可読性を向上させることができれば、上記のような監視業務も少しは楽になるはずである。また、特許明細書を学会論文と同様の技術文書であると考えるな
らば、これを統合的に解析することで技術動向の把握ができるようになるはずである。

．26・

TbchnicalContributionⅥ）1．14，No．1

自然言語処理に関する研究を行うにあたり、特許文書を対象とすることにしたのは上記のような理由からである。

4．現在までの到達点
弁理士によって書かれた文献［7］【8］や、実際の特許明細書データ（国立情報学研究所が主催して開催された評価型ワークショップNTCIR3【91の参加者に配布された「特許データコレクション」）一を調査分析し、特許請求項の記述スタイルを表一1のように類型化した。

表−1特許請求項の記述スタイルの類型
名称

順次列挙形式説明「〜し、〜し、〜した、〜」のように、処理を順序的に記述する形式

構成要素列挙形式「〜と、〜と、〜とからなる、〜」のように、構成要素を列挙する形で記述する形式

ジ土プソン（Jepson）的形式「〜において、〜を特徴とする〜」、「〜であって、〜を特徴とする〜」のように、最初に＿公知部分（既に知られている内容）または前提条件を述べたうえで、新規部分（この発明の特徴となる部分）または本論部分を記述する形式

そして、これらの類型にそれぞれ特徴的に出現する記述パターン（手がかり句）を収集し、それを用いて、特許請求項の構造を解析する手法を考案した。その際、特許請求項は複数の要素や処理の説
明を1文の中に詰め込んだ形で記述されていること［81を考慮し、複数の文・節から構成された談話の構造を解析するための理論である修辞構造理論（RST‥RhetoricalStruCtureTheory）を応用することを考えた。特許請求項の構造を表現するために、6つの関係を定義し、字句解析と構文解析から構成されるコンパイラの手法をベースとした構造解析アルゴリズムを設計し、プログラムを実装した【10】【11】。
図−2に、図−1の特許請求項の構造を解析し、RST解析のために開発されたRSTlbolというツール
を利用して視覚表示した結果を示す。
PleCOn亜10n

1−4

Elabo18l10n

大学精肉絶示帳サーヒスシステム

5−9を精微とする．

」塑㌔ゝ＿＿＿＿讐竺妄軍A
1・2

各種憐輔を■

大学構内に付するホストコ 致されたデー

ツビュータと5−7こと

Lr空聖二＝ 」
を■える

このホストコ

縫し縮示用憤＝ ■ンビュータと報として出力ノーー塑聖−一二二三」からなる

タ田鶴綱を介して撫流し、
肘‡己絡示用惜
l嚢を入力ある

いは受信して
裏示し、竹i己嘉l示用情報に．了、、含、、
惰茫利用者が南記端末としても穫緒示月

償属し餉記絶憤欄を入力し示用憐蟻のセ利用書の要求得と餉記Il示

を受付ける事
務端末および

用傷報に義よれる各檀サー

匠はH鼠末と、ビスの要求と璧鐘と予約とこれらの入力食まれる各種
サーヒスの要求と饉貴の情緒の入力および出力とを行
う繊数の犠末に対応する匝l

宇とを裏示し出力する利用
竃揃末と

と

図−2

特許請求項の構造解析結果（図−1の特許請求項の構造を解析し、視覚表示した結果）．27●

TbchnicalComtribution

Vol．14，No．1

また、こうした構造解析の結果を利用して、簡単な操作を行うことで、自動言い換え処理を行うプ
ログラムも実装した。図−3に、図−1の特許請求項を自動言い換え処理した結果を示す。

以下からなっている大学構内掲示板サービスシステム：
各種情報を蓄積し掲示用情報として出力するホストコンピュータ
複数の端末
このホストコンピュータと大学構内に付設されたデータ回線網を介して接続する。

掲示用情報を入力あるいは受信して表示する。
掲示用情報に含まれる各種サービスの要求と任意の情報の入力および出力とを行う。
以下を備えていることを特徴とする大学構内掲示板サービスシステム：端末として各種掲示用情報を入力し利用者の要求を受付ける事務端末および図書端末
利用者が使用し掲示用情報の取得と掲示用情報に含まれる各種サービスの要求と登録と予約とこれらの入力に対応する回答とを表示し出力する利用者端末
図−3

特許請求項の自動言い換えの例（図−1の特許請求項に対して自動言い換えを行った結果）

5．これからの方向性
特許請求項の低可読性の問題については、前章で述べたような構造解析とその結果の視覚的表示により、かなり緩和されたと考えている。しかし、特許明細書が読みにくいという問題を解決するには、
更にいくつかの山を越える必要がある。

その一つには、用語の問題がある。特許請求項中に使われる用語は、発明の範囲をできるだけ拡張するために、できるだけ上位概念の用語が使われる傾向がある（例：「プリンタ」ではなく、「印字装置」等）。また、当該分野に固有の専門用語が何の説明も無く使用されることも多い。これらの問題に対しては、「発明の詳細な説明」中の記述を利用してその注釈付けを行うことを考えている【12】。
また、1つの特許明細書中に複数の特許請求項が記述される「多項制」という形態がとられる中で、特許請求項間の関係の把握が困難なものも多い。また、1つの特許明細書中の特許請求項数が異常に多いものもある。たとえば、私が遭遇した特許明細書の中には、185個の特許請求項を含むものがあった！コンピュータによる支援無しに、いったい誰が185個の特許請求項を解読して理解できるというのであろうか？

もちろん、私が自然言語処理の研究に着手することになったもともとの動機、すなわち、ソフトウ
エアに関する様々な文書やメールデータを自動解析するという仕事にもいずれは着手したいと考えている。今後、自然言語処理は、ソフトウエア技術者が活躍すべき・活躍できる有望な分野の一つであるというのが私の現在の考えである。

謝辞
本研究では、mCIR3ワークショップで配布された「特許データコレクション」を使用しました。

．28．

Ⅵ止14，No．1

TbchnicalContribution

参考文献【1】新森昭宏，柴垣ゆかり，「パソコン環境におけるソフトウエア障害対応プロセスの分析とそれに基づく業務改善アプローチについて」，ソフトウエアシンポジウムー97，ソフトウエア技術者協会，
pp．123・130，1997．

［2】新森昭宏，「BayesianNetworkによるソフトウエア障害対応知識のモデル化と事例ベース検索への応用」，ソフトウエアシンポジウムー98，ソフトウエア技術者協会，pp．127・134，1998・［3】奥村学、難波英嗣、「テキスト自動要約に関する研究動向」、自然言語処理、Vbl．6，No．6，pp．1−26，
1999．

【4】奥村学、望月源、「連載：テキストを自動的に要約する技術、第一回テキスト中の重要な文を抜き出す」、bit、Vbl．32，No．2、2000．

【5】JISAブックレッツ・1、「ソフトウエア特許入門」、（社）情報サービス産業協会編、1998．
【6】JISAブックレッツ・5、「SEのための特許入門」、（社）情報サービス産業協会編、2003．
［7］葛西泰二、「特許明細書のクレーム作成マニュアル」、工業調査会、1999．
［8】糟谷洋治、「『請求の範囲』の文体と作文技法の考察」、パテント、1999．

【9】岩山真、藤井敦、高野明彦、神門典子、「特許コーパスを用いた検索タスクの提案」、情報処理学会
研究報告，F1−63−007，2001．

［10］新森昭宏，奥村学，丸川雄三，岩山真，「手がかり句を用いた特許請求項の修辞構造解析」，情報処理学会第149回自然言語処理研究会，2002−NL・149，千葉大学，pp．65・72，2002年5月．
［11】Akihiro SHINMORI，Manabu OKUMURA，Yuzo MARUKAWA，MakotoIWAnMA，
HRhetoricalStructureAnalysisofJapanesePatentClaimsusingCuePhrasesH，Proceedingsofthe

ThirdNTCIRWorkshoponresearchininformationRetrieval，AutomaticTbxtSummarizationand
QuestionAnswering，NationalInstituteofInformatics，2003・［12】AkihiroSHINMORI，ManabuOKUMURA，YuzoMARUKAWA，MakotoIWAMA，l−Patent
Claim Processingfor Readability・Structure Analysis and Tbrm Explanation−■一，ACL−2003

WorkshoponPatentCorpusProcessing，AssociationforComputationalLinguistics，2003・＿29＿

SeamailⅥ）1．14，No．1

Essay

華東師範大学軟件学院訪問

荒木啓二郎（九州大学）
1．1．激変の街，上海

昨年（2003年）12月に1年振りで中国の上海を訪問しました．SEAが毎年中国で開催しております
ISFST（InternationalSymposiumonFutureSoftwareTbchnologies）というソフトウェアに関する国際会議に参加するために，ここ十年以上の間，ほぼ毎年中国に行っておりましたが，昨年は，新型肺炎
sARSのためにこのISFSTの開催延期が決定されましたので，この1年間は中国に行っておりませんでした．

私は福岡に住んでおりますので，ISFST等で中国に行く時は，上海経由にします．福岡／上海間
は，飛行機で1時間15分程度ですので，東京に出張するのと変わらないか，却って早いくらいです・
これまで，上海に行く度に，半年振りであっても，その変化の速さに驚いておりましたが，今回は1年振りでしたので，その変わりように改めて驚きました．
上海に着いたとたんに，まずは，自動車の数の多きと車種の豊富さに驚きました．十二年前のことでしたでしょうか，その時上海では，小型の中国製の（たいがい赤く塗装されて排気ガスをまきちらして走っていた）車や日本製のポロポロの中古車に交じってフォルクスワーゲンのサンタナが走っていました．その直前にやっとの思いでフォルクスワーゲンのジェッタを3年ローンで声った私としては，自分の車より高級な車種であるサンタナが中国でタクシーとして使われているのを見て苦いたりがっかりしたのですが，上海にフォルクスワーゲンの工場ができたと聞いて，（当時はまだ「へ〜，へ、，へ〜，…」と右手は動かなかったものの‥−）なるほどと思いました．今回は，赤い小型の中国車は全く見ませんでした．フォルクスワーゲンもサンタナだけではなくて，ポロやパッソートさらには

サンタナのステーションワゴンも走っているのでした．ゼネラルモータースも上海に工場を造ったそうで，ビュイックも沢山走っていました．ホンダ，日産などなど日本の草も走っていました¶・おかげ

で環状の自動車専用道路も，従来の一般道も大渋滞です．

上海のことは，また最後に少し触れるとして，表選に挙げています華東師範大学軟件学院（ソフトウェア学部）訪問の話をしましょう．

2．華東師範大学軟件学院
HeJiFengという人が，マカオにあります国連大学国際ソフトウェア技術研究所（UNUnIST）で主任研究員をしています．彼は，英国オックスフォード大のC．A．R．Hoareのもとで長年研究をしてきており，形式手法（formalmethods）の分野では知る人ぞ知る研究者です．一昨年，彼が福岡に来るから会いたいと言うので，会って，中洲に席を移してから，いろいろと話を開くと，上海の華東師範大学（EastChinaNormalUniversity）にソフトウェアだけの学部を作った，自分が学部長をやっている，日本と連携したい，と言うのです．

その時は，それで終って，特に具体的な話も出なかったのですが，昨年の9月に，私がプログラム
委員長を務めたFomalMe山ds2003という形式手法の国際会議がイタリアのピサや開催されて，それに参加しましたら，JiFengも参加していて，件の軟件学院の話になりました・

学部の学生が各学年200名程度在籍していて，修士課程にも各学年100名以上いるというのです・そんなに沢山卒業生を出して，仕事はあるのか，と訊くと，即座に，あると，自信たっぷりに答えるのです．どこにあるんだ，と訊くと，日本だというのです−．
以下に，JiFengの話や，実際に上海で見聞したことを基に，上海のソフトウェア学部やソフトウェ
ア会社の状況の一端をお話しいたします．

現在，中国で35枚の大学に軟件学院というかソフトウェア学部が新設されたそうです・上海では，
上海交通大学，復旦大学，同済大学と華東師範大学の4枚だそうです．師範大学としては，この華東．30−

SeamailⅥIl．14，No．1

Essay

師範大学が中国で1校だけ指定されたと，誇らしげに言っていました．
いずれも華東師範大学と同じ規模の学部だとすると，毎年1万人ものソフトウェア技術者が社会に輩出されることになります．日本でも情報関連の学部学科や大学院から，毎年それくらいの卒業生は出ているかと思いますが，日本の大学の場合は，情報何々という名称でも学科や学部の設立の経緯から，必ずしも情報専門となっていないことが多いので，ソフトウェアだけで各学年200名の専門学部というのは，日本から観ると脅威的な人数といえます．ちなみに，九州大学工学部電気情報工学科で．
は，各学年160名の定員のうち，ソフトウェアに関係する研究室に所属するのは20名くらいでしょうか．
そもそも，このように中国にソフトウェアの学部が一時に沢山できたのは，中国の御偉方がインドを視察して，これはいける，中国でもやれという鶴の一声があったからだというような話をききました．
華東師範大学軟件学院について，もう少し詳しく述べましょう．ホームページによると，設立は2002年1月だそうです．学部長は，前述のHeJiFengです．彼は，2002年度の国家自然科学貴を受賞したとかで，応接室には，大勢の受賞者たちに交じってJiFengが江澤民のわりと近くで写った写真と賞状とが飾ってありました．
学生数は，学部と修士課程併せて現在1000名程度ですが，じきに1500名に増やすそうです・学部が各学年150から220名で，4学年合計で約700名です．2002年1月設立のわりには，2000年度の学生が155名いるという説明が気になりましたが，まあ中国のことですので，そんなことは気にしてはいけないのでしょう．この軟件学院に直接入学した学生以外にも，他学部からの転入学生がけっこう沢山いるそうです．大学院の修士課程には，2002年度に72名，2003年度春に127名，2003年度秋に95名入ったそうですが，これも他学部からの転入を含んでいるそうです．ちなみに，学部卒業生の大学院進学率は5％程度だそうです．修士課程には，社会人学生も沢山いるそうです．
上述の学部長の話によると，仕事は日本から取って来るという訳ですから，日本語教育にも力を入れていて，現在は，日本語検定を目標に，日本語は必須科目となっています．しかし，今はまだ，一般的な日本語教育だけなので，次の段階では，専門科目を日本語で教えたいということです．
このようなことを私の目をじっと見つめて言うものですから，気の弱い私は，う〜ん，わかった，
私にできることは協力しましょうなどと言ってしまった訳です‥一）

もっとも，前述のように大量のソフトウェア技術者が輩出されて日本のソフトウェア開発に乗り込んで来るのですから，その大きな流れは防ぐべくもないと感じて，それなら日本の言葉は勿論のこと，歴史や文化や社会的な背景も理解したうえで，日本向けのソフトウェアを開発して貰うのが顧客となる我々日本人にとってせめてもの仕合わせになるのではないか．そのための中国人ソフトウェア

技術者教育に少しでも協力しようなどとも考えた次第です．もっとも，それは，私には荷が重すぎることですが，SEAで岸田さんをはじめ皆様方から教えて頂いたことを基にできることをやろうと考えています．

さて，華東師範大学を訪問して，対応してくれた若い教員と具体的な打ち合せをしましたが，実際に私に求めることは何なのかが解るまでに随分時間がかかりました．日本では情報処理学＿会が1997年にJ＿97という理工系の情報専門学科に対するカリキュラムの案を提示しています．一応，それを彼らに提示し，日本の大学の一般的な学期や授業のやりかたを説明したところ，一応，ソフトウェア工学関連の科目を私が担当しようということになりました．ちなみに，このJ−97のソフトウェア工学の項目は荒木が担当しています．
日本の大学では，lコマ90分の授業を週に1回，期末試験を￣入れて15週というのが，よくある授業
形態です．ところが，華東師範大学では，欧米の大学でよく見られるように1コマ45−60分の講義を週に5コマ程度実施するそうです．今回は，初めての試行ということもあって，華東師範大学の通常の学期の中で1週間特別の時間割にして貰って，日本の細切れ授業の1科目相当分を集中講義で実施することにいたしました．

．31．

EssaySeamailⅥ止14，No．1

ところで，問題は，何をどのように教えるかです．これに関して私に対する要求が，今ひとつはっ
きりしないのです．専門の内容を日本語で教えるということに重点があるのならば，ソフトウェア工学概論のような内容で，日本語で一通りの内容を教えても良いのですが，この案を提示しても先方は乗ってきません．この提案自体の意味あいも理解して貰っていないようでした．何を教えてくれるのかと繰り返し質問します．日本語での専門教育をしなくてはいけないという先入観をもつ私は，また同じような提案をします．最初の2時間程度，概論めいたことを話して，それから特定の科目の具体的な内容を詳しく教えましょうか，などといっても，やはり腑におちない様子です．

しばらく膠着状態が続いたところで，華東師範大学軟件学院の授業内容を見せて貰うことにしました．科目一覧のコピーを見ると，ソフトウェア関連の科目がびっしり並んでいます．但し，科目のいくつかに印が付いています．これらは，まだ開講していない科目なのだそうです．後で数えてみると，約50の専門科目のうち，ほぼ半数が未開講です．
だんだん分かってきました．前述のように，中国で急にソフ▼トウェア学部を沢山つくったため，どうやら教員不足になっているようです．日本語での講義云々の以前に，専門科目の講義が求められている訳です．私が日本語で授業をしようと英語で授業しようと，どうでも良いことで，未開講の科目を補ってくれれば彼らにとって有難い訳です．JiFengの話を最初に聞いた時に感じた高邁な思い
は，ガタガタと崩れて，なんだか，お人好しの日本人が葱を背負って自ら飛び込んで行ったという感
じもしてきました．しかし，まあ，何でも良いけど，何か面白そうでもあるし，なかなか体験できないことでしょうから，最後まで付き合ってみることにします．

という次第で，形式手法の大御所であるJiFengが学部長をしているにも拘らず，形式手法の講義を荒木が自分の教科書を使って教えることにしました．3月下旬に上海を1週間訪問して，集中講義
をしてきます．JiFeng自身は月に2回程度来るけど，授業は担当していないそうです．

華東師範大学軟件学院では，専門科目の8割9割は英語の教科書を使って中国語で授業をしているそうです．上海の他の大学では，当然のことながら英語の教育に力を入れているけれども，日本語教育を重視しているのは華東師範大学だけだと言っていました．九大の他の先生を上海に招いて講義をして貰う他に，九大へ学生を数カ月派遣して，授業への参加や研修なども実施したいと言っていました．ソフトウェア技術者の専門教育を日本の大学にアウトソーシングしたいということでしょうか．

ところで，中国のこれらのソフトウェア学部は，産学合作で設立運営するという制約が課せられているそうです．華東師範大学の場合は，復星（FuXin）グループというのがパートナーとなって，上海
師策教育投資管理有限公司（ShanghaiSEIEdu甲tionHoldingLtd．）を作っています．軟件学院のロゴとこの会社のロゴとは，同じ形で配色が違うだけですので，混乱します．しかも，同じ形で別の色のロゴを持つShanghaiEmbeddedSystemsInstitute（上海組み込みシステム研究所）という組織もあります．

同じ人の名刺の裏表にこれらの組織が記載してあったりして，いよいよ混乱します．産学合作というよりは，産学合体といった印象を受けました．
3．ソフトウェア会社訪問
FuXinグループのソフトウェア会社も見学させて貰いました．100−200名程度の従業員が働いていて，上海では有数のソフトウェア会社だということです．

日本の大手企業からの発注を請けていて，職場に入ってまず目についたホワイトボードに貼られているビラや書かれた進捗表が日本語だったりして，一瞬ここは日本かと思うくらいです．プログラマが使っているパソコンには日本語版Windowsが載っていて，部屋の隅に置かれたプリンタの廻りには日本語文書の反古紙が散乱しています．まるっきり日本のソフトウェア会社の光景です．日本語の文書では湊字を使っているので，読み書きは間蔑ない，でも，会話はできない，と言っていました．
中国人のプログラマ達は，お昼休みに日本語の勉強をしているとのことです．
始まって間もないプロジェクトを担当しているマネジャーの話を聞くことができました．日本の企業から詳細設計書を貰って，それを見てプログラムを作っているそうです．形式仕様記述なんてなことをやっている関係上，詳細設計書見ても良く分らないでしょうと質問したら，意外にも，いえ，以前は分らなかったけれども，最近ようやく分るようになりましたとの返事でした．このマネジャー．32．

EssaySeamailⅥ）1．14，No．1

は，日本留学経験があり，日本語に堪能で，彼が担当しているプロジェクトの上海側の窓口になっていて，日本側とのメイルのやりとりを常にしているようでした．

最初に日本から担当者が上海にやって来て，詳細設計書を渡して，1−2週間かけて説明をするそうです・以後は，この設計書を見てプログラム開発を進めて行くのだそうです．もちろん，詳細設計書
だけで全てが分る訳ではないので，インターネットを活用して，電子メイルやオンラインチャットや場合によってはNetMeetingを使って，日本との間での技術的な確認を行ない，また，意思の疎通を図っているのだそうです．それらを前述のマネジャーがメイルできちんと記録に残すのだそうです．
コミュニケーションが一番大事ですと，このマネジャーは言っていました．ちなみに，プログラミン

グの対象は，300−500行程度のモジュール単位になっているそうです．

上海のソフトウェア産業にとっては，日本からの下請けというのは，今の所，美味しい仕事なのだ
そうです．安定して仕事が来るし，設計後のコーディングが主体だから，自分達で新規にシステム開発を請け負うのに較べるとリスクが少ないからだそうです．

これらの話を聞いて，私は，残念な思いをし，また，不安な気持になりました。今は詳細設計書が分るようになりましたと言ったマネジャーの言葉から，日本企業の安易なアウトソーシングのやり方を想像したからです．外国の下請け企業にまで，行間を読ませ，特定の企業文化を押しつけて，せっかくの異文化交流の機会に文書や開発プロセスを見直す好機を逸したと思うからです．
今は，中国にコーディング中心の下請けをやらせていますが，その内に中国のソフトウェア技術者
が力をつけて上流工程まで彼らがやって日本企業の出る幕がなくなったり，下請け依存体質の日本企業が中国の下請け企業からしっぺ返しをくらって，彼らのいいなりにならざるを得なかったり，というような状況が早晩おこりはしないでしょうか．

4．若者の街，上海

夜になって，大学というか，会社というか，産学合作の活動を支えている若い人に食事に誘って貰いました．秘書をやっている女性と，ソフトウェアの教育に携わっている青年です．この青年は，医学部を卒業したけど，医者よりはソフトウェア技術者になる道を選んだそうです．
上海の浦東地区にある酒落た中華レストランに連れて行って貰いました．明るくモダンな内装で，とってもトレンディな雰囲気です．小綺麗な身なりの20歳台30歳台の人達で賑わっていました．西洋人も沢山来ていました．これまで岸田さんに連れて行って貰ったところとは大違いです‥−）
食事の後で，川岸のStarbacksCo能eに行こうということになりました．StarbacksCoffeeといっても侮ること勿れ．以前上海といえば必ず出て来た外灘のちょうど対岸が，若者たちの人気スポットなのだそうです．日本で言うと，東京の御台場のような感じでしょうか（博多もんには良くわかりませんが＝−）若者のグル⊥ブヤカップルで賑わっていました．私の相手をしてくれた若い人達も，休みの日にはよくこの辺に遊びに来るそうです．StarbacksCo飴eは，ガラス張りの酒落た建物で，外灘の眺めが良く，浦東の中でも一番人気で，当日も満員で入ることができませんでした．しかたなく，隣の類似のカフェに入りましたが，ここも間もなく客で一杯になってきました．アメリカのオールディーズの曲が流れて，皆，カクテルなんかを気取って飲んでいます．アメリカの古い曲といえば，林香さんや酒匂さんの得意とするところで私には食傷気味ですが（俺にもマイクを渡してくれ‥−）上海の若者には新鮮で好まれているそうです．
某ANAの機内誌に北京は東京のライバルとかいったような言葉が載っていました．日本企業が中国の巨大な市場への参入を目指すといったような新開記事なども時々目にします．どうも，認識が甘いように思います．私を浦東に案内してくれた上海の二人の若者も，日本は「大鍋飯」だとか言って，日本社会の非効率さや理不尽さに言及していました．中国は，日本なんか既に相手にしていないような気がLlます．

いずれにしましても，3月下旬に1週間上海に行って，上述の集中講義をする予定ですので，上海で何が起きているのかとか，大学生のレベルや気質を見て参ります．面白い話があれば，また報告いた
します．

．33＿

1tchniealContribution

Wl．14，No．1

October2，2003

キューバ危機とソフトウエア危機
佐原伸
日本フイツツ（株）
日本では「事実に基づかない常識」が横行している。キューバ危機とソフ
トウェア危機を例に、その実体を明らかにし、結論として形式手法を勧めつ
つ、朝鮮半島危機の解決策はすでに提示されていることを指摘するのが本稿の狙いである。

なぜキューバ危機とソフトウェア危機なのかといえば、キューバ危機は人類の歴史上もっとも解明された歴史的事象であり、ソフトウェア危機は我々ソフ
トウェア技術者がその渦中で苦闘している現在進行形の危機であり、ともに「解明された事実」があるにもかかわらず、その事美を無視した「常識」に従って危機を拡大しているからである。

手ユーパ危機
日本ではキューバ危機の真相はほとんど知られていないが、1964年10月27日我々は核戦争10分前を体験した。ソ連フルシチョフ書記長のミサイル撤去受諾があと10分遅れていれば、米軍がキューバ上陸を開始し、米軍の予想していなかったキューバ駐留陸海空ソ連正規軍4万2千が、現地司令官の裁量で使用できる戦術核兵器をもって反撃したはすなのである。もちろん、その後は米軍上陸部隊の全滅、米軍の核による反撃でキューバが全滅、米ソの核戦争によって日本を含む主要国が壊滅的な打撃を受けることとなっていた。

問題は、米国・ソ連・キューバのいずれもが核戦争を望まず、危機の拡大も望んでいなかったにも関わらず、上記の事態が発生したことだ。3カ国がお互いの意図を誤解し、危機を拡大してしまったのである。
この間の経緯は、米国ブラウン大学の主導で、キューバ危機30周年にあたる1992年に、当時の米国・ソ連・キューバの政府・軍の主脳（マクナマラ元米国防長官やシュレジンジャー元補佐官、カストロ・キューバ書記長、グリコフ元ワルシャワ条約機構軍参謀長など）や学者達（旧ソ連のフルシチョフ書記長とミコヤン第一副首相の阜子達が、米国の大学の研究者として参加している．34．

TbchnicalContribution

Vol．14，No．1

ソフトウェア危機のも興味深い）がハバナに集まってキューバ危機を再検証する中で明らかになった1。キューバ危機から得られる教訓は、● 危機は制御できない・核の傘は、核戦争を招く● 軍事力は、戦争を招くである。考えてみれば「核の傘」以外の2つの教訓は、すでに、旧日本軍による中国侵略でも証明されている。

しかし・最近の日本では「核の傘」と「軍事力」で「日本を守る」のが常識
かのように「宣伝」されている。事実に基づかない考え方であり「宣伝」である。

ソフトウェア危機
ソフトウェア危機もキューバ危機と同じように、ユーザーもソフトウェア会
社もソフトウェア危機を拡大させる意図はないにも関わらず、筆者がソフトウェア開発会社に就職した1975年以来、ソフトウェア危機は常に「今そこにある危機」であった。対処法は、常に● テストを十分にせよ●

開発プロセスを遵守せよ

であったが、危機は深まるばかりである。原因は、筆者から見ればはっきりしている。
● 30年前のソフトウェア工学に基づく開発プロセスに従って、● 欠陥の多いソフトウェアをいくら十分にテストしても、信頼性の高いソフトウェアは作成できないのである；
信頼性の高いソフトウェアを作るための形式手法については、以下のような「常識」が存在する2。
● 形式手法は役立たない● 形式手法は難しい●

形式手法は金がかかる

このあと本稿は上記「常識」に反論していく訳である。

1・JameS・GBlight・BruCeJ・創lyn；DavidA・Welch：CubaontheBrink，2002，
Rownan＆LittlefieldPublishingInc．

2・本当は・J・A・Hal1＝SevenMythsofFormalMethods，IEEESoftware，Vol．7，

No・5・pp・1ト19，1990・に示されている＿ように、もっと存在するが、ここでは主要なものにとどめた。

手ユーパ危虞とソフトウェア危機

ー35．

Vol．14，No．1

TbchnicalContribution

ソフトウェア危機

形式手法は役立つ

一緒に仕事をしている洒匂寛さんの新刊書（「課題、仕様、設計」、インプレ
ス、2003年10月か11月出版予定）の草稿を校正をしていて、VDM＋＋仕様の部分をVMDTooIsの構文チェックと型チェックツールを使ってチェックした。
FIGUREl．草稿の「診嚢受付J仕様

CldSS r診察受付」ls sub⊂ldSS Of「業務論理」
OPerCltions

publi⊂適用（ある患者：「患者」，ある予約：「予約」）
ある診察記録：「診察記録」＝尤is not speCtfied yet（isofCloss（「再診予約」，ある予約）≡＞ある予約insetある患者・予約）ond

not（ある予約．状態＝「予約」、く受付済＞）
POSt

ある予約．状態∃「予約」、く受付済＞Ondnot（ある診察記録in setある患者〜，予約）ond

ある診察記録．患者＝ある患者ond

ある診察記録．診療科＝ある予約．診療科ond
ある診察記録．診察状態長「診察記録」、く受付済＞dnd

ある診察記録．初診再診区分0＝患者区分
end「診察受付」

上記の仕様には、2ヶ所の間違いと、数カ所の用語の統一上の問題と、数カ所の文法違反があった。
間違いは以下の通りである。
●

nOt（ある診察記録insetある患者〜．予約）

で、「ある診察記録」ではなく、「ある予約」でなければならない●

患者区分が未定義

用語統一上の問題は以下の通りである。
● 操作を通して値を得るはすが、属性を直接参照している● 予約状態は「状態」として参照しているのに、診察状態は「診察状態」として参照している

文法違反も修正した仕様は、以下のようになる。
FtGURE2．診察受付の「鯵正した」仕様

Closs r診察受付」is sub⊂lcLSS Of業務論理

手ユーバ危機とソフトウェア危虎・36・ltchmicalContributiom

Vol．14，No．1

ソフトウェア危機

OPer。tions

publi⊂適用（ある患者：「患者」，ある予約：「予約」）
ある診察記録：「診察記録」＝＝is not yet spe⊂ified
Pre（isof⊂loss（「再診予約」，ある予約）＝＞ある予約In setある患者．予約（））qnd

not（ある予約．状態0ごく受付済＞）
POSt

ある予約．状態0＝く受付済＞dnd
not（ある予約in setある患者．予約ple（））dnd

ある診察記録．患者0＝ある患者dnd

ある診察記録．診療科（）＝ある予約．診療科08nd
ある診察記録．状態0＝く受付済＞8nd
let患者区分＝ifisof⊂loss（「新患予約」，ある予約）then＜新患＞else＜再診＞ln

ある診察記録．初診再診区分（）＝患者区分
end r診察受付」

Closs「患者」
lnst（ln⊂e VCLrlicLbl．es

publiC予約集合：Set Of「予約」：＝ti；
OPer8ttOnS

publiC予約pre：（）＝＝＝＞Set Of「予約」
予約preo＝＝is not yet spe⊂ified
POSt

RESULT＝予約集合−；
end r患者」

筆者の場合、上記のような間違いは酒匂さんのおよそ10倍の確率で発生させる可能性が強い。にもかかわらず、実際のプロジェクトの中で、高い信頼性のある仕様を書けた1のは、VDM＋＋の構文チェック・型チェック・インター
プリタ・コードカバレージ機能・証明課題生成機能といったツール群を使用したからである。さもなければ、仕様段階で数千のエラーを包含したモデルを作ってしまっただろう。
実際に、弘の経験した形式手法を使わない多くの開発現場のシステムでは、上流工程で埋め込まれた数千のエラーを、テスト工程で必死に除去しようとして、多大な努力を払い、それでもリリース後にトラブルを発生させることが多かった。

1．「共通機能の括り出しが不十分でしたよ」と同僚の佐藤圭さんが言っているが手ユーパ危機とソフトウェア危虎Ⅵ）1．14，No．1

1tchmit：alColltribution

ソフトウェア危機

以上から明らかなように、形式手法ツールは、開発の早い段階でエラーを見つけるのに役立つ。結果として、下流工程に引き継ぐエラーが少なくなり、作業の手戻りが少なくなり、「泥沼化したプロジェクト」になる可能性が低くなる。
l

ページ数の関係で、形式手法ツールだけでなく形式手法も役立つことの証明は省略するが、上記仕様中のPOSt以下で示される事後条件を記述するだけでも、開発現場の品質向上に大いに寄与することを指摘して串きたい。
また、形式手法は各種の大規模システムで適用され、役に立つことが報告されている。NASAの全宇宙システム1はSPIN2でモデルを記述しチェックされている。ロシアの人工衛星制御システムとオランダの花市場システムはVDM3で記述され、後者はVDMからC＋＋を生成し1人年で完成した。パリの地下

鉄制御システムはB4で記述され、いずれも、エラーが0または極めて少ない
ことが報告されている。
もちろん、形式手法だけが役立つと言っている訳ではない。実際に、ソフト
ウェア・シンポジウム2003で報告したプロジェクトの例5では、形式手法以

外に、ソフトウェア工学のうち「開発現場で容易に使える」あらゆる技術を動員した。コードカバレージによるテストやCOCOMO81による見積もりなど、20年前にも使っていた技術もある。回帰テスト用のライブラリーは、オブジェクト指向技術の流用であり、形式仕様の記述スタイルは、今、流行りらしいXPに近いものがあった。CVSによる構成管理と版管理がなければ、形式手法の威力も半減しただろう。
形式手法は難しくない

次の攻撃目標は「形式手法は難しい」という「常識」である。
形式手法は確かに難しい。しかし、形式手法を使わないソフトウェア開発は「難しくない」のだろうか？筆者の28年間にわたる「開発現場」経験では、「ソフトウェア開発は常に難しい」というのが実感である。そして、「手を抜けば抜くほど難しさが増す」というのが経験則である。
従って、「形式手法が難しい」という命題が成り立つためには、「現在の開発
手法は、形式手法にくらべれば難しくない」ことを立証しなければならない。
寡聞にして、そのような報告を聞いたことがない。
具体的に、システムが何をすべきかの仕様を書く場面に絞って考えてみよう。ここで、日本語で仕様を書く場合と、VDMやCafeOBJ6といった形式仕1．FM2003ディナーでのGerardJ．Hokmann博士との会話
2．http：／／spinroot．com／spin／whatispin．hthl1

3．http：／／shinsahara．com／www／vdm／index．htm1

4．http：／／www．afm．lsbu．ac．uk／b／

5．佐原伸：大規模事務処理システムにおける形式手法の適用経験、ソフトウェア・シンポジウム2003事例報告
6．http：／／www．ldl．jaist．acjp／cafeobj／

手ユーパ危機とソフトウェア危機＿38・

TbchnicaIContributionⅥ）1．14，No．1

ソフトウェア危機様記述言語で仕様を書く場合とを比べてみよう。以下は、最初のVDM＋＋仕様の一部を日本語で書いたものである。
FIGURE3．日本音による仕様例

もし、予約が新患予約なら患者区分を「新患」とし、再診なら「再診」とする。

人によっては、構造化日本語を考え、以下のように書くかも知れない。
FIGURE4．構造化日本喬による仕様例

if予約＝新患予約then

患者区分＝‖新患，■
else

患者区分コ‖再診■■

問題は、上記の2通りの書き方は、仕様を書く人が「その場の雰囲気」で決めることが多いことである。筆者の経験では、「この場面ではどう表記しようか」と考えている時間がかなりある。仕様の内容以外に時間を使うことは、考えてみれば無駄なことである。しかし、「日本語という曖昧な仕様記述言語」
を使う限り、この時間の浪費は避けられない。しかも、書いた仕様に曖昧さが残り、構文チェックや型チェックもできない。
結局、文法が決まっていて、構文チェックや型チェックなどもできる形式仕様記述言語で仕様を書く方が簡単なのだ。VDM＋＋の場合、言語仕様の複雑さはせいぜいJava程度である。UML2．0を勉強するより易しい。

形式手法も、証明などで一部に難しい部分も残っているが、開発現場の泥沼状態のプロジェクトで苦労することを思えば、大したことではない。いや、本当に難しければ、その部分だけ使わなければ良いだけである。

形式手法は金がかからない

次は、r形式手法は金がかかる」という「常識」を攻撃する。
確かに、VDMTooIsの場合1本100万円近いコストがかかる。しかし、筆者の周りで常に見聞きする「開発現場のトラブル」は数千万円から数億円のコストを浪費している。顧客の信用の低下を考えれば、実際のコストはもっと大きいだろう。
形式手法を学習するコストもかかる。多分、ツールを買う値段以上にコストがかかる。しかし、大規模システムの泥沼状態の中で、1件のエラーを修正するコストは高くないのだろうか？筆者の経験では、少なくとも1件10万円以上のコストはかかり、平均で言えば1件100万円は下らず、中には億円単位のエラーもある。最近の携帯電話システムなどでは、1件が数百億円に値するようなエラーもあるようである。

手ユーバ危虎とソフトウェア危機

・3，・

Vol．14，No．1

TbchnicalContritIution

ソフトウェア危機がキューバ危機から学ぶこと

つまり、形式手法などの新しい技術に仮に一人当り300万円かかったとしても、その技術を使うことで、高々数個のエラー発生を防ぐことができれば、十分元が取れるのである。ソフトウェア開発での最大のコスト削減策は、高品質ソフトウェアを作ることである。決して、コピーに裏紙を使うことなどではない。

ソフトウェア点綴がヰユーパ危機から学ぶこと
ソフトウェア危機が形式手法によって幾分か緩和されるとしても、キューバ危機の教訓と比べて足りないことがある。キューバ危機では「何が起きたかJ
r誰が何をしたか」が場合によっては分単位で明らかにされている1。

ソフトウェア危機は、多くの「現場」が経験しているにも関わらず、その詳細は当事者達の「記憶」ないしは「酒飲み話し」でしかない。もちろん、世界が絶滅するか否かの瀬戸際の事件と、高々数百億円の捜害の発生でしかないプ
ロジェクトで、同じ密度で記録が存在する必要はないが、やはり「過去の経験に学ぶ」基礎となるデータは保存されるべきではないだろうか？大きな社会的トラブルを起こしたプロジェクトの実態や履歴は公表されるべきであろう。
さもなければ、数百年後のSEAMAIL編集長が、現SEAMAIL編集長のFM20032におけるスピーチ「Backtothefuture」に類する話ができないことになる。

手ユーバ危機から日本人が学ぶべきこと
最近の日本人の多くは、朝鮮半島危機について「北朝鮮なんかやっつければよい」という気持ちがあるらしい。しかし、米軍の予測でさえ、戦争が起これ
ば、死者は米軍5万人、韓国人100万人、北朝鮮の人々にいたっては何人が犠牲になるか分からない。このような悲劇を肯定するのは「狂気」としか言いようがない。戦争は、ソフトウェアのエラーとは比較にならないくらい大きな
コストがかかる。「コスト削減」命の日本人が、勇ましいことを言うのは自己矛盾としか思えない。
キューバ危機の教訓からもr危機を起こしてはいけない」のである。方針ははっきりしている。韓国の言う「太陽政策J Lかないのである。58年前に米国に対し一億玉砕を叫んでいた日本は、韓国に従うしかないではないか。

1．http：／／www．gwu．edu／〜nSarChiv／nsa／cuba＿miS＿Cri／chron．htm
2．http：／／fmeO3．isti．cnr．it／

手ユーパ危機とソフトウェア危虎．40．

MessagehomEditor

SeamauVol．14，No．1

編集後記

☆

あいかわらず原稿が集まりません．
☆☆
そうした状況のなか，佐原さん，新森さん，そして荒木先生の3人からお寄せいただいた原稿を材料に編集にとりかかったのですが，いささかページ数が足りません．

☆☆☆
そこで先日（3／11）に開催されたSEA−SPINMeetingのスピーカだった伊藤昌夫さんにお願いして，当日の参考資料として配付された力作論文を転載することのお許しを得ました．ついでに埋め草として，わたし（岸田）が発表に使ったスライドのコピーも載せることにしました．

☆☆☆☆
次号は，2月にSOBAFrameworkをテーマに行われたSEAForumの記録を渡連雄一さんがまとめてくだ

きっていますので，それを中心にまとめるつもりです．
また，4月初めに大阪で開催予定のSEAForumonPLSEのために講師のK．C．Kang先生が用意してくださったスライドが，かなり情報量の多い力作なので，SEAMAILに掲載することの了承をお願いしてみようと考えています．

☆☆☆☆☆
それにしても，原稿が欲しいです．SEAMAILは，ふつうの雑誌ではなく，会員相互の交流と情報交換のためにあるのですから，みなさんぜひ何か書いてください。

☆☆☆☆☆☆
岸田孝一＠SEAOmce

．4ト

名

ソフトウゴア技術者協会〒160東京都新宿区四谷3−12丸正ビル5F
TEL．03−3356−1077

FAX．03−3356−1072