…3…r.

N
e
w
s
l
e
t
t
e
rf
r
o
mS
o
f
t
w
a
r
eE
n
g
i
n
e
e
r
sA
s
s
o
c
i
a
t
i
o
n
Volume11

1997

目次
編集部 か らソフ トウェ ア産業とソ フトウ ェア 研究の沈滞状況につい て玉井哲雄

2

狩猟民族的技術者の世界

野中哲

6野 呂昌満 ・ 酒匂寛

8高木徳生・ 小泉毅

1
8

ソフ ト ウェアデザインワークショップ報告

組込みソフ ト ウェア分野のプ ロセ ス改善活動

に関する情報交 換会・ 報告
論文募集.ソフトウェア・シンポジウ ム '9 8

3
8

SEA 入会案内40

合 ソフトウェア技術者協会
SoftwareEngineersA
s
o
c
i
a
t
i
o
n
ソフトウェア技術者協会 (SEA ) は，ソフトウェアハウス，コンビュ ー タメーカ，計算センタ，エ ン ドユーザ，大学，研究所など，それぞれ異なった環境に置かれているソフトウェア技術者または研究者が，そうした社会組織の壁 を越 えて ，各 自 の経験や技術を自由に交流しあうための「場」として. 1985 年 1 2 月に設立されました.
その主な活動は，機関誌 SEAMA且 の発行，支部および研究分科会の運営 ， セミナー / ワーク シ ョ ップ/シンポジ ウムなどのイ ベントの開催，および内外の関係諸団体との交流です . 発足当初約 2∞人にすぎなかった会員数もその後飛躍的に増加し，現在，北は北海道から南は沖縄まで. 7∞ 余名を超えるメンバーを擁するにいたりました . 法人賛助会員も 30 社を数えます.支部は，東京以外に，

関西，横浜，長野，名古屋，九州，広島，東北の各地区で設立されており，その他の地域でも設立準備をしています.分科会は，東京，関西，名古屋で，それぞれいくつかが活動しており ，そ の他の支部でも，月例会やフォラムが定期的に開催されています.

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

坂本啓司

常任訴事 :

荒木啓 二郎高橋光裕田中 一夫玉井哲雄中野秀男深瀬弘恭

彰彦:

市川 寛伊藤昌夫大場充河村 一樹窪田芳夫熊谷章小林修桜井麻里
酒匂寛塩谷和範篠崎直 二 郎新谷勝利杉田義明武田淳男中来田秀樹
布川博士野中哲野村行憲野呂昌満端山主主平尾一浩藤野誠治二木厚吉
堀江進松原友夫山崎利治和田喜久男

事務局長 :

岸田孝 一

会計監事:

辻淳二

吉村成弘

分科会世話人環境分科会 (SIGENV) :塩谷和範田中慎 一郎渡漫雄 一

教育分科会 (SIGEDU ) :君島浩篠崎直 二 郎杉田義明中園}I頃 三
ネ ッ トワーク分科会 (SIGNET) :小林俊明人見庸松本理恵
プロセス分科会 (SEA-SPIN)) :青山幹雄伊藤昌夫坂本啓司高橋光裕田中 一夫増井和也

支部世話人

関西支部 ・ 白井義美中野秀男横山博司

横浜支部 : 野中哲藤野晃延北俊正顕
長野支部 : 市川 寛小林俊明佐藤千明
名古屋支部筏井美枝子石川雅彦角谷裕司野巴昌満

九州支部:武田淳男平尾 一 浩
広島支部:大場充佐藤康臣谷純一郎
東北支部:河村 一樹布川博士野村行憲和田勇

SRA PFU

賛助会員会社 :ジェーエムエーシステムズ東芝アドパンストシステム

東電ソフトウェア機造計画研究所さくらケーシーエス
富士通ジャストシステム新日鉄情報通信システム

カシオ計算機キヤノン

サン ・ピルド印刷

オム ロ ンソフ トウ ェア

中失システム安川電機富士通エフ ・ アイ ・ ピー

SRA 東北アスキー新日本製鉄エレクト ロニクス研究所ダイキン工 業

東北コンピュータ・サーピス

富士電機プラザー工業

ア イシーエス

SRA 中国プ ロダ ク ト ・ソリュ ー シ ョン

オムロン

(以上 29 社)

SEAMAIL Vo1. 11. No.3

日本電気ソフトウェア

1997 年 1 1 月 1 1 日発行

編集人岸田孝一

発行人

ソフトウェア技術者協会 (S EA)〒 160

東京都新宿区四谷 3-12

T:
03・ 3356・ 1077

F: 03・ 3356・ 1072

印刷所サンピ Jレド印刷株式会社

定価

丸正ピル 5Fse噌 @sea.or.jp

〒 162

500 円

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

(禁無断転載)

S
e
a
m
a
i
lVol.ll , N
o
.
3

M
e
s
s
a
g
efromE
d
i
t
o
r

編集部から

*

ふたたび船便シンドロームに陥りかけている SEAMAIL Vo1.1 1 ですが…
会食

巻頭の玉井先生のエッセイは，ソフトウェア工学およびソフトウェア産業の現状についての問題提起です.先生が最後に書いておられるように，これを読んだ上での会員の方々の御意見をお待ちします. e-mail で
sea@sea.or.jp まで，投稿をお寄せください.

女大*
続いて，新宿からシリコンヴアレイへトラバーユした野中さんのエッセイも，期せずして，日米ソフトウエ
ア・ビジネスの比較分析になっています.

1令交1今大
一昨年から始まったソフトウェアデザインワークショップですが，順序がちょっと逆になって，昨年の第 2回のレポートが先にまとまりました.第 3 回はいま企画中です.実施はたぶん来年(?).

***大大
プロセス分科会 (SEA-SP町)に集まった人たちのうち，組み込みシステムを仕事としている方々が，この夏，

情報・ 意見交換のワークショップを開催しました .それをきっかけに，組み込み ソフト分科会 (SIG・EMS) も生
まれようとしています .

**"jた*"j年*
次号は， 10 月末に中国・アモイで開催される ISFST・97 の論文特集を予定しています.

***大女大*

‑
1
‑

S
e
a
m
a
i
lVo l. ll , N
O
.
3

Es蝿y

ソフトウェア産業とソフトウェア研究の沈滞状況について
玉井哲雄(東京大学大学院総合文化研究科)
1.はじめにて，後にはソフトウェア産業政策の正当化のための合言葉として，長らく呪文のように唱えられてきたが，それSEA の幹事のメーリン グリスト上で，幹事の新谷さん

が世の中のソフトウェアに対する需要の増大に対して供が「情報処理J にのった大須賀論文 (r 日本のソフトウェ

給体制が追いつかないということを意味していたとすれア問題についてー現状分析と将来対策ー J ， 1997 年 8 月

ば，ソフトウェア業界にとってはこれほど歓迎すべきこ号)を取り上げて問題提起をされた.それでしばらく前とはなかったはずである.問題はプログラマの確保で，に書いて放ってあった文章を思い出した.この元は，仕事を確保するための営業を必要とするような会社は，

1995 年の 12 月に日本ソフトウェア科学会のソフトウェ

よっぽどおかしな会社だと思われていた.通産省による

ア工学の基礎研究会の招待講演で， r何がソフトウェア

ソフトウェア技術者の 97 万人不足説(西暦 2{削年時点

工学の基礎となり得るか:ソフトウェア工学の沈滞を打の予測)も，こうした背景で出された.

開するには」と題して話した内容の前半部分である.そしかしパプル経

済ははじけ， 1990 年代に入ってこれまでにない長い不の時は OHP を使ってしゃべっただけだが，後でそれを況が続いている.この不況はまた，コンピュータやソフ

材料に一部を文章化してみた.その後の動きを若干捕捉

トウェアという不況の影響を受けにくかった産業に，きしてあるが，それでも時機を失っている感があるかも知

わめて大きな打撃を与えた点でも，これまでの景気後退れない.しかし，これまでどこにも発表していないので，や不況と異なる性格のものである.

SEAMAll..，に投稿してフィードパックを得るのも意味があるかと考えた.発表していない理由の一つは，最後に経済のパフキル化現象が顕著だった時期，並行してソフ「ではどうしたらよいか」という自分なりの展望と提言

トウェアのバブJレも大きく膨らみ，それがやはり 90 年を書こうと思ったからである.しかし，とりあえずこの

前後にはじけたのではないだろうか.つまり，ソフト

まま出して，皆さんの意見を聞き，私の考えるところはウェアの需要は次のような理由により，実需よりみかけ

別の機会に譲るとほぞを固めた.未完成なものをあえてがはるかに増大していた可能性がある.

皆さんの目に晒すことになるが，お許しいただきたい.

同じようなソフトウェアを別々の組織が重複して大須賀論文や新谷さんの問題提起とは必ずしも対応し作る.同じ業界の各社が横並びに，しかしそれぞれていないかも知れないが，議論のきっかけになれば幸い

別に，同じような機能の業務システムを作るようなである.

ケースである.

2. ソフトウェア産業と研究の現状

閉じようなソフトウェアを同じ組織が何度も繰り返し作る.業務内容，利用環境，技術の変化に応じ

現在，日本のソフトウェア産業にもソフトウェア研究て，ソフトウェアシステムも変化せざるをえないが，にも，停滞感が漂っている.世上では目覚ましい製品も設計技術や保守・再利用技術のまずさから，むだに革新的な研究も，日本から生まれてこないといわれてい作りなおしているケースである.

る.産業では，二重の意味での空洞化が進んでいる.すなわち，核となるようなソフトウェアは米国に支配され，下請構造により全体の売り上げ高が増大する.ソ

大量の入手を投入して作られる適用型のソフトウェアは，

フトウェア産業は非常に多くの企業を抱えるが，そ技術力があって労働コストの安い国への生産の委託が進れらは階層的な下請構造を作っている.ソフトウェ

んでいる.企業では「作らずに買う」というのが，方針

アの開発委託が，ユーザー企業からコンビュータになっているという.買いにいく先は，米国やヨーロッメーカーや大手のソフトウェア会社に出されると，パだったり，中国やインドだったりするわけだ.

多くの場合，階層の上から下に何層にもわたって外注委託が流れていく.これらは経済活動としては重日本のソフトウェア産業は， 1990 年頃まではともかく複して数えられ，みかけの産業規模は増大する.

も拡大を続けてきた.ソフトウェア危機という言葉が，初めはソフトウェア工学の必要性を叫ぶための枕詞としこれらの要因の原因でもあり結果でもあるが，日‑2‑SeamailVol.ll , NO.3

Essay

いということをハンフリーは強調した.それにもかかわ本におけるパッケージ型のソフトウェアの流通は，個別発注型のソフトウェアの開発と比べてきわめてらず，比較すれば米国の方がプロセスの成熟度が高いと小さい.売上高でいえば，いまだにソフトウェア産

読める結果に対して，米国人の聴衆が「その結果はおか業の 15 %程度を占めるに過ぎない.正確な比較

しい j とする反応の激しさは驚くほどだった.その頃，

データはないが，米国ではパッケージ型のソフト

米国で常識化していた日本のソフトウェア開発力の強さという思い込みとは，ずいぶん異なるメッセージだった

ウェアの売り上げ比率は 60% 程度と言われる .

からである.その認識がまったく逆転した今となっては，個々のソフトウェアの規模自体が，いたずらに増大

この 6 年前の状態が信じられないくらいである.

している傾向もある.冗長な作り方，使われない機能などで水脹れになっているソフトウェアが多い.

明らかにこの時の米国側は，日本の実力を過大視した.
同時に脅威論を煽ることにより産業への補助政策や研究

日本の大学や研究機関におけるソフトウェア研究についても，風当たりが強い .

への予算拡大をねらう政治的な意図もあっただろう.現

ここでも，産業界と並行する

在では，このような認識はまったく逆転した.たとえば，

ように「空洞化」現象が見られる.新たな研究分野や基1994 年にスタンフォード大学の Feigenbaum 等が日米の本的な概念は，米国から持ち込まれる.革新的な構想、やソフトウェア企業 50 社あまりを調査して作ったレポー

研究成果が海外に向けて発信されることは少ない . そも

トでは，日本の企業が品質を重視するあまり，売れる製

そも，研究の道具として用いる基本的なソフトウェアも品を市場に出すスピードに遅れを取っているという結論

多くが米国製である.そしてよく批判されるように，大を導きだしているが，全体に米国の産業に対する自信に

学における研究は実践との結びつきが希薄である.日本

満ちあふれでいる.一方， 1993 年に出された棟上レポー

では 一般にベンチャ型の企業があまり育っていないとよ

トは，やはり日米のソフトウェア産業を比較して見事なく言われるが，とくに大学から生まれたペンチヤ・ピジ

分析を行っているが，総じて日本の状況に対してきわめ

ネスはほとんどない.さらに，産業が元気をなくしていて悲観的である.

るために，肝心の人材育成の面でも，たとい質の高い教育ができていたとしてもそれを産業界が受け入れてくれ

5 年前の米国における現象と，昨今の日本における悲るかどうかに大いなる不安があるという有様である.総

観的な見方とを重ねあわせてみると，現状認識が極端かじて，日本のソフトウェアの産業界も学界も，自信を喪ら極端に振れる傾向が見てとれる.確かに日本のソフト失しているようにみえる.

ウェア産業と研究か羽在大きな問題を抱えていることは，
認識しなければならない.しかし，必要以上に悲観視す

3. 悲観論の蔓延ることも，生産的ではない.

このような認識は基本的に間違っていないだろうが，

ソフトウェアが問題だという認識は，実は日本に限っ

あまりに悲観論に傾きすぎているようにも思われる.

た現象ではない.非専門家向けに解説されるソフトウェ

5.6 年前を振り返ってみるとよい.当時，米国では日本

アの現状は，その供給力や信頼性に関しておそろしく否のソフトウェアの信頼性，生産性の高さが一つの脅威と定的である.たとえば， S
c
i
e
n
t
i
f
i
cAmericn 誌の 1992 年

して論じられていた.たとえば， M.Cusumano による日

11 月号に， í ソフトウェアのリスク」と題する解説があ本の「ソフトウェア工場」についての報告は，その脅威るが，ソフトウェアの信頼性が不確実であるという事態に対して警鐘を鳴らしたものとして受け止められた.こに対し，可能な対処法としてあげているのが次のようなのままでは，鉄鋼，家電，自動車のように，ソフトウエものである.

アも日本にやられるという論調がよく聞かれたものであ

1) ソフトウェアに対しては要求仕様を定義するのを避る.

ける.たとえば米国連邦航空管理顧問会議の出して筆者にとって印象深いのは， 1991 年のテ.キサス州オーいる回状では，航空機の種々の構成要素の重大故障

ステインにおける ICSE である.そこで， W.Humphrey

発生確率を飛行時間当たり$1O"{ -9}$ とすることをが CMM の日本と米国における調査結果を発表した.こ

取り決めているが，この対象からソフトウェアは定の 2 つの調査は，日米それぞれで聞いたセミナーの参加

量的なエラ ー評価か不可能だとして明示的に除外さ者に，アンケートを取るという方法で行われたものであれているという.

る.対象者が，米国の場合は主に防衛関連を中心とした

2) システム内でソフトウェアの果たす役割をあまり重埋め込みソフトウェアの開発に携わる企業の技術者，管­理者で，日本の場合はほとんどが事務処理システムに携大なものでないようにする.

わる企業からの参加者だったから，単純には比較できな

-3・

S
e
a
m
a
i
lVol.ll, N
O
.
3

Es姐y

3) 現状のソフトウェアの信頼性の限界を認めて，シスで起こる専門分化の現象の 一 つであったかもしれない.

テム全体の安全性のレベ Jレが多少甘くなるのを許容

実際， たとえば ACM では SIGSO町、が 1976 年にできて，する .

SIGPLAN とは路線を明確に分けることになった.

しかし，この棲み分けのために， ソ フトウェア工学は技術的

さらにその 2 年後の Scientific American 誌 (1994 年 9

な拠り所のかなり 大 きな部分を 失 ったのではないだろう

月号) では ， W.Gibbs と い う科学記者による「ソフトか.

ウェアの慢性的危機状況J と い う記事があり，デンバー空港事件を始めとする多くのソフトウェア開発の失敗プ

80 年代における 実践的成果には，インスペクションやロジェクトを例にあげて ， 危機状況は↑劃主化しているとプロトタイピングがあり，これらはそれなりの効果をあいうことを，ややセンセーショナ Jレに報じている.ソフげた.

トウェア業界で元気がいいのは，極言すれば米国でも W.

ける.新しい技術，とくに AI との連携はやはり 80 年代

Gates だけかもしれないのである.

の大きな話題だったが， 結局のところそれほど目覚まし

しかし，技術的な革新性という点での魅力には欠い結果を生んでいない.

4. ソフトウェア工学は何をしてきたか

80 年代の後半にはソフトウェアプロセスが多くの関

ここで，ソフトウェア 工学 の状況に目を転じてみよう .

心を呼んだ.続いて 90 年代に入るとソフトウェアアー

よく知られるように，ソフトウェア工学は 19ω 年代のキテクチャという概念とその研究の普及に一部の研究者

終わりに興り， 70 年代は構造化プログラミングというが力を入れだした.これらは，プログラミングレベルで主導概念のもとに，理論面と実践面の相補的関係がかなはなく，システムレベルで，あるいは開発管理という面

りよく機能して，活発な研究，実践活動を展開した.

で，なんとか理論的なアプローチをしようとする研究者

80 年代に入ると，ソフトウェアの大規模化，複雑化にの苦肉の策と見ることもできる.ソフトウェア工学は管対処しなければならないという掛け声とともに，ソフト理であるとしてしまうと，理論の方ではやることがなく

ウェア工学の重心が管理技術の方に移行していった. 7
0

なってしまう.そこでプロセスという管理面を含みなが年代のソフトウェア工学の枠内で進められた，段階的詳

ら技術的な対象となりうる分野とか，アーキテクチャと細化などのプログラミング方法論， モジュール化，抽象

いったマクロな設計対象を相手にして，そこに形式的なデータ型， などの分野は，次第にソフトウェア工学からモデル化手法を持ち込み，理論的な取り扱いを試みよう

外れていった.そのことで思い出すのが， 1987 年にカリというわけである.プロセスの方は， CMM や ISωα犯

フォルニア州モンタレイで聞かれた第 9 回 ICSE である.

のお陰で，同じ言葉を使いながら異なるものを想定してこの時の基調講演者の一人がLee Osterwei1で，その後のいる気味はあるものの，実務者の興味をもひくことにあ

ソフトウェアプロセス研究隆盛のきっかけとなった「ソる程度成功した .

フトウェアプロセスもソフトウェアである」という題でが難しそうだ.

講演をした.この講演は，後に与えた影響の大きさから，
ICSE が毎年行っている 10 年前に開催された同会議の論文から選ばれる最優秀論文として， 1997 年の ICSE で表彰を受けている.きて 10 年前の当日の講演後，第一に質問したのが Harlan Mills で，まず会場にチューリング

同じく 80 年代後半から，オブジェクト指向技術の分

析や設計への適用が大いに関心を集めた.この動きは，形としては構造化プログラミングから構造化設計や構造化分析が生まれた 70 年代の流れと類似する.さらに，オ

ブジェクト指向には，再利用・部品化というこれまたソ賞の授賞者がいたら手を挙げてくれといい，一つの手も挙がらないことを確認した後， rDijkstra, Hoare 達はどこへいってしまったのか.ソフトウェア工学の分野で，われわれはもう彼らから学ぶことはないのか J と発言した. IBM の中にあっては理論派であった当時のMills としては，管理技術に偏向して「反知性化」したソフトウエ
ア工学の状況に我慢がならないという感じであった.
80 年代のソフトウェア工学は，プログラミング言語や

フトウェア工学の長年の課題に，解決の糸口をつけるという期待もかけられた. 70 年代のソフトウェア工学が
栴造化プログラミングを指導原理として活況を呈したとすれば， 90 年代はオブジェクト指向技術を指導原理として閉じような活気を取り戻せるかもしれないという期

待を抱かせるに十分なものがあったといえよう.、 90 年
代も半ばを過ぎた現在，この期待は実現したといえるであろうか.

プログラミング方法論に関するテーマを，すでに解決済

オブジェクト指向は確かに豊かな概念であり，現在でみのものとするか，あるいは小規摸ソフトウェアにのみ通用する技術で，大規模なものには役立たないとして，意識的に遠ざけた.これは発展段階にあるあらゆる分野

しかし，アーキテクチヤの方はその点も分散オブジェクト，設計パターンやフレームワークといった高レベルの部品化，ピジネスオブジェクトなど，活

‑
4
‑

S
e
a
m
a
i
lVol.ll, NO
.3

E
s
s
a
y

しかし 一方で， 90 年

トでは大学で一生懸命やってはいけないと教えているこ

代はもはや 70 年代のように，単 一 の原理ですべてをくとを常にやっているのではないか」というものである.

くれるほど単純ではなくなっているともいえよう.さら聴衆が少し湧いたが，マイクロソフトの技術や商売のや気のあるテーマを産み出している.

に学会の細分化傾向も関連する. SIGSOFT と SIGPLANり方を批判したい気持ちはよく分かる.とくに情報としの棲み分けについて述べたが， OOPSLA を主催するのはて目新しいものはないが，マイクロソフトを持ち上げる

SIGPLAN である. OOPSLA は相変わらず多くの参加者

内容の講演の後であってみれば.しかし 一方で，筆者にを集める派手な学会となっているが， SIGSOFT としては変な質問のようにも思えた.そもそもクスマノはほとはよい商品を先に取られたというところであろう.意地

んど技術の話をしていないので，ソフトウェア工学土好のせいか，棲み分け原理が働くのか， SIGSOFT 主催のましからざることをマクロソフトがやっているかどうか

オブジェクト指向をテーマにした会議は目にしないし，判断できるような内容はなかったと思う . だから，このICSE や FSE(ACM SIGSOFTS
ymposiumont
h
eF
o
u
n
d
a
ｭ

質問は講演内容によらず質問者が先入観念として持って

t
i
o
n
so
fS
o
f
t
w
a
r
eEngineering) でオブジェクト指向をキーいるものに違いない，というのがおかしく感じた理由のワードに入れたような論文はきわめて少ない.ただし，一つである.向調者も同様の発想であろう.また，この日本やヨーロッパでは，もともとソフトウェア人口が少質問者の意図は，大学で正しく教えているソフトウェア

ないし，米国の学会の暗黙の錠(そのようなものが実際

工学からすると，マイクロソフトの開発プロセスは劣悪に存在しているかどうか確かではないが)にとらわれるであるという主張であるが，皮肉にとれば，大学で教え必要もないので，ソフトウェア工学関連の研究会やシンているようなやり方ではソフトウェア企業としては成功

ポジウムにオブジェクト指向の話が出てくるのは珍しくしない，ともいえないことはない.質問者とその同調者

ないどころか，むしろ目立つて多い.

がそれに気づかないのもおかしく思った.

ソフトウェア工学が，ソフトウェア生産の現実に追いS. これから の ソフトウェア工学

ついていない面もあるかもしれない.大規摸化，複雑化という合言葉が，ソフトウェア工学の存在意義を説明するのに使われ続けてきたが，現実は，小規模多品種のソ
フトウェアの生産など，さまざま異なる性質の要求があるだろう.また，ソフトウエア工学か暫定レていた対象
システムは，米固ならたとえば防衛関連の巨大システム，
日本ならたとえば銀行システムのような民間の巨大シス

テムで，いずれにせよ特定の顧客向けの受注型システム

ここを書く予定であった.実際書こうとしているのだが，理由があって少し先になる.そこで，最初にも述べたように，狭滑な戦略に出ることにした.このままでSEAMAIL に出し，幸 U吋可らかのフィードパックが得られれば，これから書くものに参考にしようというのである.というわけで尻切れとんぼのようだが，ご意見を賜わりたい.

であった.たとえばシュリンクラップ型のソフトウェアをどう作ったらよいかという問題は，旧来のソフトウェ

ア工学が真正面から取り組んでこなかったものいえるだ
ろっ .

その点で，マイクロソフトのお膝元たるシアトルで関かれた 1995 年の ICSE はある意味では象徴的であった.

当初はピル・ゲイツを基調講演者にという話もあったが，最終的にはマイクロソフトの関係者の発表や展示はほとんどなかった.そのかわり基調講演の一人が M .
Cusumano で，その題目がなんとマイクロソフトであった. 5 年前は日本のソフトウェア工場に目をつけ，今度はマイクロソフトというのはビジネススクールの教師らしく目端がきくというべきか.

しかし，マイクロソフト

ほど一般のマスコミで取材されている対象に対して，新たな情報や知見を披濯するのはクスマノにしても荷が重い . 話としてはつまらなかった.聴衆の反応も冷やや.かだったが，印象に残った質問が一つある.質問者は大学の人らしく， r クスマノ氏の話によれば，マイクロソフ

‑
5
‑

S
e
a
m
a
i
lVol. ll, N
O
.
3

Es姐y

野中哲

(
A
p
p
l
eComputer)
米国のシリコンバレーに本社を置く A 社の日本法人に入社

よすぎる気もするが，このガンマンの姿が，プロジェクトごして 6 年半が経過した.この程度の経験で，米国のように多とに会社を転々とする，技術者たちの姿と頭の中で 2 重写し

様な国についてなにか普遍的なことを述べられるとは到底思になったのである.

えないが，それでもシリコンパレーと呼ばれる地域のソフト

教育という点に関していえば，会社が人材を育てるという

ウエアエンジニアの生態は多少理解したつもりである.それケースはほとんどない.必要なスキ Jレセットを持っている人を，どこかから探してくるのがふつうである.人材の募集に

ほんの 6 年で半数以上の社員は私より後の入社になり，私関しては，必要な知識，技術，経験，担当する仕事に関して，は古参の部類に属するようになってしまった.米国の本社でかなり詳細な要求仕様が示されている.ただし，これは会社

は近々，私にとって 4 人目の社長を迎えることになる.慣れで教育を受ける機会が少ないということではなく，むしろ日たとはいえ，この人の流動性の高さには，驚くことが多い.

本に比べるとかなり充実しているといってもよいのではない

3 年程前，まだ A 社の経営危機が現在ほど表面化していな

かったころ， A 社は米国内で，数百人単位の大規模な求人広告をとある雑誌に掲載した.この求人には「基本ソフト第 8
版という次世代のオペレーテ ィングシステ ムの開発のための非常に驚いたものである.驚いた第 l の理由は， A 社はそれを遡ることほんの 2 年程前に，大規模なレイオフを実行していたばかりだったから.第 2 の理由は，これだけ大量の人聞を採用したとしても，次世代オペレーティングシステムがみ当違いであることがわかる.どうやら，かれらは速い未来の前のプロジェクトを成功させることが先決で，その先のことを今あれこれ考えても意味がない，と思っており，また，職を求めてやってくる人間の側も，取り敢えずこの数年の聞に，水準を高めるという目的もあろうが，第 l の理由は有能な人
材を会社に繋ぎとめるための，いわば福利厚生の面が強いよ

うに感ぜられる.教育機会を充実させるのは，日本でいえば会社が社員の ための保養所を建てるようなものではないだろうか.
人の異動が激しいので必然的に安定した組織が発達しない.

組織変更は日常茶飯事だ.日本に比べて，会社の組織が平坦
かといえば，必ずしもそうではない.平社員から CEO までの階層の数は，日米ともそれほどかわらないように思える.ただ，直属の上司の裁量の範囲は，比較にならないほど広い.極
端にいえば「ボスが OK といえばなんでもあり」である.

プロジェクトにおける責任の所在は明確である.だから，などのような経験を積み，それをどう次へつなげるか，ということのみを考えているようだ.
会社の将来性とか安定性などまったく眼中にない未来のことはあまり考えない"と書いたが，これはやや不正確な 書き方である.みんな無鉄砲ではないから，未来のこと，将来いないのは， r将来自分の会社がどうなるかJ ということについてである.自分の将来は考えても，会社の将来は考えない.

責任という 唆昧なものは存在しない.あるのはあくまでも個人の功績と失敗である .こ の個人主義は米国にかなり，普遍れては担当者を名指しで指名する.その人のサーピスがよければれる

客とチップはふえ，悪ければへる.したがって会社の方針というのは，実は社長の方針である.社長がかわれば，会社も180 度変わる.

この状況は，私に昔見た西部劇を思い起こさせた.腕利きのガンマンが，西部のとある町に流れ着く.一宿一飯の恩義を受けたかれは，その町の悪者を退治して，最後にまたよその町へ流れていく，といったパターンのものだ.少々格好がソ的であるようだ.医者でも，床屋でも，旅行代理店でも，客転職のうちおよそ半分は，よりよい待遇を求めて移る人々

だったり，家族の事情などによるもので，これらは，いわば前向きの転職といえるだろう.しかし，あとの半分は与えられた責任を成し遂げることができず，夜逃げのようにやめて‑
6‑

つ一ド'重る上
いコなと尊すきの人生設計は優秀な技術者ほどちゃんと考えている.考えてにか失敗があれば，それは特定の個人の責任になる.組織の店舗 42Et 噌迫・フことはあまり考えないらしいのだ.採用する側はとにかく，目を負担するといった条件がついているものもある.会社がこのようなプログラムを用意するのは，もちろん，社員の技術

t-のやら，私は不審に思った.しかし，暫くしてこれは私の見とえばコースの終了試験に合格した場合のみ，会社が授業料る主 4T-

このような状況で，最初ははたして技術者は応募してくる

本人に本当にやる気があるかどうかを確認する手段として，た

V-J

だ.

ずなく，個人の自発的な意志で参加するケースが大半である.

較行利へヨ狩とのがるでイオフが繰り返されることが既定の事実のように思えたからしかし，上司の勧めや，命令で講習会に参加するということはま

封斗ごと完成した暁には，また大量に技術者が余り，大規模なレなコースに参加するプログラムが各種用意されている.

と人はいな募集」というお題目が掲げられていた.当時それを見た私はかと恩十社内のみならず，社外の講習会や，大学の短期的のれと人あ土と違らの 一 部を紹介してみようと思う.

行わりむ大を日明い私恥然狩猟民族的技術者の世界

E
!

S
e
a
m
a
i
lVol. ll , N
O
.
3

E
s
s
a
y

行く人間たちである.製品のリリースが近くなったにもかかしまうからだ.プログラムの内容を解説するドキュメント，たわらず，機能が実現できていない，あるいは山ほどパグがあとえばモジュール構成図のようなドキュメントが書かれるこり，とても動きそうもない，といったケース.その問題が火ともまずない.開発方法論や CASE といったものについても，を噴く直前に辞めてしまうのだ.

もちろん，そこはみなさん

各技術者が個人的興味で使うケースを除いて，ほとんど使用

大人であるから「おめでとう，次の職場でも頑張って」と 声されていない.組織的に CASE ツールを採用して，開発効率をかけるが，同僚はたまったものではない.担当者が去るとを向上させようなどという話は. CASE ブームのまっただ中「責任・ 約束J もかれらとともにどこかへ行ってしまう . 新しのころでさえ，耳にすることはなかった .

い担 当 者が来て「それは前任者が勝手に約束したことです.

が速効的にあらわれるものでないと，狩猟民族の曙好には合もっと，導入効果

私は知らないj というのは，よく聞かれる台詞である.口約わないのであろう.どちらかといえば「何を作るか ?J を必束ほど当てにならないものはない.契約書が発達するのも当死に考えている. r どうやって作るか」はあまり気にかけてい然だろう.

ないようだ.

「今夜は残業してパグを直す」か「今夜は家族と夕食をとる」

一 方，ソースコード以外のドキュメントが一切書かれないのどちらを選択するかも完全に個人の自由な選択にまかせらかというと，そのようなことはなく，大量に書かれ，かつ品れる.この選択に関して同僚や上司が干渉するのは，見たこ

質もよく，読みやすしきちんと保守もされるドキュメントとがない.つきあいの残業など想像もつかない.ただ「米国がある.それらは，主に外部から見える仕様に関連したドキュ

人はみんな 9 時に来て 5 時に帰ってしまう」というのは嘘でメント類である.これは，利用目的が非常に明確だからであある.リリース直前は，やはりみんな必死でデバ ッ グする.

る.第 一 に企画書，提案書としての性格を持っているもの.

土日も出勤，連日徹夜というのも日本人と同じただそのあ

これは外部仕様がきちんと書かれているかどうかで，そのプとかれらは，大胆に(一 ヶ月とか)休暇をとる.これは大きな

ロジ、 エクトにゴーサインがでるかどうかの判断材料となるからである.第 二 には，そのソフトウエアがライブラリであっ違いだろう.
従業員を採用するときは，かれらの言葉では· offer を出す'という.それを受けるかどうか，最終的な決定を下すのは個人だ. よって「あなたはめでたく採用の運びとなりました J ではなく「あなたが offer を受けてくれて，とてもうれしいJ と

たり. A
P
I
(
a
p
p
l
i
c
a
t
i
o
nprograminterface) を持っていたりする
場合，当然そのインターフェースを利用してくれるソフトウ
エアがふえてくれなければ，そのプロジ、 エクトは成功とは呼べないので，そうなってくれるように，外部仕様書はきちんと書かれるいういい方がなされる .これは 「会社と個人がまったく対等

企画書や提案書のたぐいは，雨後の竹の子のごとくに大量な立場にある」という事実を象徴していると思う.
準備から収穫まで，最低でも数ヶ月を必要とする農耕に比較すると，狩猟での仕事の周期は，はるかに短い.何ごとを行うにしても結果がでるのが非常に早いのである.長期的な利益よりも，短期的な利益が優先される.台北の故宮博物館へ行くと親子 三代かけて作った工芸品が展示されている.

に書かれている.ふつうのエンジニアたちが自分のアイデアをどんどん提案書，企画書というかたちにして，周囲や上層部にどんどん売り込む姿には，当初はずいぶん驚かされたものだ.ちょっとでもチャンスがあれば，どんどんスピンアウ
トして行く.みんな一応サラリーマンとはいえ，なにか個人

ヨーロッパへ行けば 150 年かけて建築された教会がある.

商店の集まりのようにさえ思える.

狩猟民族にはこういうものは作れないだろうと思う.ものごさて以上を乱暴にまとめてみるととを考える時間の単位が，根本的に異なっているのだ.経営
の目標の設定と評価のサイクルは 3 ヶ月が基本である .

-定住しない.

目標

・超個人主義の集団が達成されなければ，直ちに軌道修正のアクションがとられ

目先利益追求型

る.一年経っても改善されなければ，社長か官になる.まるでプロ野球の外人選手のようだ.
ソフトウエアの開発でも，このような文化的特徴が反映されている . プロセスは重視されない.とにかく現物が尊重される.いわゆる概要設計書であるとか，詳細設計書であるとといったところだろうか.このような特徴が，変化の激しい，パソコンやインタ ーネ ットの世界で強味を発揮 した結果，現在のところ，シリコンバレーに生息する人間たちが，この業界をリードしている原因のような気がする.はたして，かれらのリードはいつまでつづくのであろうか?

いったドキュメントは，ほとんど書かれない.設計だけしてコーデイングしないエンジニアなどはいないから，そのようなドキュメントの必要性はないのだ.設計はかれらの頭の中と，ノートの上に存在する.とにかく実際に動作する現物が尊重され，開発が決まれは，すぐにコーデイングがスタート

最後に余談ではあるが，最初に紹介した'基本ソフト第 8
版'は，ついに完成することなく終わった.最近発売された'
基本ソフト第 8 版'は名前こそ受け継いではいるが，内容は当初計画されていたものとは，まったく異なるものとなった .

する.数ヶ月以内に何らかの形で動作するプロトタイプができ上がらないと，プロジェクトそのものがキャンセルされて

‑
7
‑

S
e
a
m
a
i
lVol. ll , NO.3

WorkshopR
e
p
o
r
t

EH

d

・

ソフトウェアデザイン ワークショップ報告1

野呂昌満&酒匂寛

言RSD96WorkshopReport

主(8D96 プログラム・実行委員長)

考えています.

第 2 回ソフトウェアデザインワークショップは仕様，設計から実装への流れを実践的に議論する"との副題のもなお ML に関する事前の知識は必要ありません!

とに，四96 年 11 月 28 日(木)から 30 日(土)まで株式会社

ワークショップの最初に簡単な講義を行います.これはオムロンの保養施設であるLaLa GOTENBA を会場としてあくまでも同じ土俵でソフトウェア設計の議論をするた開催された.本稿は，当該ワークショップに参加されなめの手段に過ぎません.

かった会員に内容の 一端を紹介することを目的とする.

多くの方々の積極的な参加をお待ちしています.

1.開催までの経鍵とワークショップの趣旨
第 2 回ソフトウェアデザインワークショ ッ プ(以下S096 と略す)開催の趣旨は，参加者募集に以下のように述べられている.

ここには，第 1 回ワークショップ(S095) の後を受けて，さらに具体的に設計とはいかなる行為かを理解するために，ML を使つての設計を考えてみようと記されている. S095

は，"設計とはいかなる行為か"ということに的を絞った議論
中心のワークショップであった . 横道にそれるが， S095 のジェクト指向 ， イントラネ ッ ト， etc) ァ 辺倒に偏りがち

報告はそのプログラム委員長であった伊藤昌夫氏から近々な昨今のソフトウェア技術論の現状を見据えつつ，仕様

この SEAMAIL 誌上でなされると思うので，詳細の紹介は

ここでは控える.今回の実行・ プログラム委員長であった

めるべき「ソフトウェアの設計」を議論する場として企

酒匂・野呂 2 人とも S095 に参加し，それが終った時点で，画されました.

-CASE ツー Jレを使って設計をしてみる

こともままなりません.教科書に書かれた設計方法論を‑ Smalltalk-80 で実装まで考えてみる

読みこなすにも，時間と個人的努力が必要です.

‑ Java でプログラミングする等々可能性のあるものは広く考慮の対象とした.

とはいかなる行為か"というテーマで議論し，広く深い

その結果，

τ

ソフトウェア設計の世界についての概要を垣間見ること

3) 抽象データの記述が可能である題材を用いて，仕様の定義を行い，その仕様に基づくソ

4) ポータプJレで無償の処理系が存在する

フトウェアの設計と実装のプロセスを体験・理解・議論す2. なぜ ML だったか?

つ内容的にもきちんとした記述方法をペースに議論する

S096 の目的は，実際にソフトウェアの設計作業を疑似必要があります.現在の予定では，プログラミング言語

体験して見ることを通じて設計とはいかなる行為か?"ML を共通記述として，それによって仕様を定義し，さらということを理解しようということであった.

に実装への橋渡しの過程を体験することで理解しようと‑
8‑

右-フ委副官・カ

このような目的のためには，参加者が同じ土俵に上らなければなりません.それはとりもなおさず，簡潔でかなどの理由により， ML を設計について議論する共通の基盤として選ぶことになった.

参右

手を動かしてみようと考えています.すなわち具体的な，

1) 高水準の計算モデルを持つ

2) 詳細設計仕様記述に向く

beを試みました.今年度は，さらにソフトウェア設計について理解を深めるために，議論主体ではなく，積極的にることを目標にしたいと思います.

トt
HdMJ包

昨年度の本ワークショ ッ プでは"ソフトウェアの設計

EGEt-

なる行為であり，どうすればよいかをじっくり考察する，

からなされた.すなわち:

Lw

オブジェクト指向万能のようにいわれている昨今の状況の中で，多くの技術者はソフトウェアの設計とはいかS096 は議論中心ではなく設計コンテスト等の"手を動かす"企画を含むものにしてはどうかとの提案が，酒匂さん

B医品目生タト(やりたいこと)と実装 ( できたもの)の簡をきちんと埋ヌ

J

このワークショ ッ プは，とかく目先の実装技術(オブ,

S個mail Vol.ll N
O
.
3

W
o
r
k
s
h
o
pR
e
p
o
r
t

3. 設計課題

企画時点での，酒匂・野呂の打合せでは， "SD96 で大きな視点から (top-down に)設計について議論をしたことを捕捉す

SD96 では ，る意味で，実装(プログラミング)の視点から (bottom-up に)

2 つの設計課題を出し，それらを各グルー

プが選択し解くという形式で，会議が進められた.課題の設計 について考えみよう J・

1 つは，前代表幹事の山崎利治さん作の"酒屋の在庫問題九

もう 1 つは"グラフ上で最短経路を求める問題"であった.

これに基づいて，実習(手を動かす作業)を行なうならば，
以下の機能を満たすソフトウェアツールが必要になると考前者は，その原典が山崎さんの手で，参考文献 [1 ，2] に警えられた:

かれている . ここでその内容をそのまま書くことは，著作

1) プログラムの仕様記述

権の関係上好ましくないので，その要約だけを載せる.詳2) データ構造，アリゴリズムの設計・記述

細は原典を参照されたい.

3) モジュール(抽象データモジュー Jレ)の定義

酒屋の在庫問題要約:

ある酒屋では，コンテナで複数銘柄のお酒を搬入し，単一銘柄の出庫依頼を受けつける.毎

さらに，絵に書いた餅で終らせないためには:

日数個のコンテナの搬入，数十件の出庫依頼がある.コン4) 設計結果が容易に実装に結びつけられる

テナはその番号，搬入日時，銘柄とその数量の組の集まりを記述した積荷表とともに搬入される.出庫依頼は銘柄，ことが要求される.

数量 ，および送り先名を添えて行われる.受付係と倉庫係以上の条件を満たすものとして ML が選ばれたのである.

がいて，受付係は，在庫なしの連絡， 出庫指示書作成およML は関数型プログラミング言語である . その計算モデ

び在庫不足リスト作成を行なう.倉庫係は，鍛入のさいにルは参照の透明性が保証され，副作用がないことを前提に

は積荷表を受付係に渡し，お酒を倉庫に搬入し，受付係か定義されている.すなわち，同じ記号に束縛される値はあらの出庫依頼に従ってお酒を倉庫から鍍出する.出庫依頼

るプログラム部分の中では同じものである . われわれの多は，出庫指示書または電話による.受付係の仕事を自動化

くが慣れ親しんでいる，フォンノイマン型コンピュータのするシステムを作る.

ハードウェアを素直に抽象化した命令型の計算モデルは，副作用を前提としている .

グラフ上で般短経路を求める問題に関しては，弧に重み

ここで副作用とは，ある変数にのついた有向グラフの単一出発点からすべての節点 (node)

値を代入しその値を後から使うことを指すが，命令型の計までの最短距離を求めるアルゴリズムが Dijkstra によって算モデルではそれは意図した行為なので，副作用と呼ぶの提案されている [3 ，4] . このアルゴリズムを使って最短距離はふさわしくないかも知れない.命令型の計算モデルは，を求めるプログラムを作ることを課題とした.

フォンノイマン型コンビュータから見れば自然なものであアルゴリズムの要約はつぎの通りである :るが，人聞から見れば関数型の計算モデルの方が自然である.

1.出発点節点を注目する節点とする.
2. すべての節点を走査するまで以下を繰り返す.

アルゴリズムの記述に関しでも，関数型の計算モデルでは，再婦を用いて繰り返しに関する計算手順を記述する.

2. 1 注目する節点を走査済みとする.

命令型の計算モデルにおける繰り返しは ， 再帰式の不動点

2. 2 注目する節点からすべての隣接節点までの距離を求めを繰り返し内の不変式として記述したものになる.命令型

る.

2.3未定査節点から最短節点を抜きだし注目する節点とす

プログラミング言語で繰り返しを記述するさいに現れる繰
り返しの制御変数や，繰り返し脱出制御のためのスイッチる.

変数などの，計算(問題解決アルゴリズム)の本質とは関係

詳しくは参考文献 [3 ，4]を参照されたい.

ないものは，関数型プログラミング言語では必要がない.

4.S096 進行概略

抽象データモジュールが定義できることも， ML の大き

SD96 で行なったことの概略を時間を追って示せば，以な特徴の 1 つである. SD96 では，与えられた問題を抽象

下の通りである :データ翻惜またはオブジェクト指向設計法に基づき設計

実装することも，視野に入れていた.その抽象データ定義

11 月 28 日

機能を用いて問題の解を記述することも念頭に置いて， ML

13:ω-18:00

が選ばれた.

ML の講義，講師佐原伸 (SRA)

抽象データモジュー Jレの定義方法を中心に ML による関数仕様の記述方法，-9・

S伺mail Vol.ll

WorkshopReport

文法とその意味について例を用いて説明.

1) 設計か不完全 なまま 実装に移ろうとすると多くの歪み

9:00 ・ 18: 側グループに分かれて ML で設計

務がコード上 に現れる.それを力任せにねじ伏せようとするとさらに悪い結果になる.

複数グループに分かれて上記 2 課題の内 l つを選ん
で設計・実装 .

19:30 ・ 22:00

v

SD96 でも起こったようである.以下例を挙げる :11 月 29 日

2) 問題の大きさに応じた解決法をとらないと，結果とし成果発表・議論て不要な人月を必要とすることになる.

各グループの設計過程および結果について発表内容

一 方で計算の本質的なところだけを考える習慣をつけ，について議論.

それを自分の本能 (secand nature) にしてしまえば，実装を

11 月 30 日

9:側・ 12:伺, NO.3通してよい設計が見えてくるのではないかという期待も持SD96 を振り返っててた気がする . ワークショ ッ プでも実務に ML を使えるか

各グループから代表者を出し， SD96 に参加しての否かの議論があった.

感想と意見を含め設計について議論した .

のような"よい" 関数型プログラミング言語でのよい実装方

しかし，そういうことよりも， ML

法を自分の技術とすることで，プログラミング言語に捕らS. 設計をしてみてわれない問題解決・設計技術を持つ素養が身につくと考えられる .

5 つのグループに分けて設計・実装を行なった.グループ
毎におもにプログラム委員から責任者を決めて指導的役割

SD96 では実装に力点が置かれ，設計 に関する議論がでを割り当てた.グループの構成員については付録-2 に示す.

きなかったとの意見もあったが，昨今の"分析・設計が重要

3 つのグループがグラフの最短距離問題を l つが酒屋のであり実装は付け足しの人足仕事である"というような風

在庫問題を設計・実装した.もう 1 つのグループは全体の監

潮に 一石を投じることができたのではないかと考えている.

督役ということで実際に課題を解くこと・は行なわなかった

プログラミング技術の軽視，ソフトウェア工学研究におけが，作業中に助言を与えたり，まとめの発表を行なったりるプログラミング言語研究が軽んじられる，という風潮がとの役割を果たした.

あるが，これは危険である.実はプログラミング言語がその背景に持つ計算モデルは問題の解決方法に少なからず影

グラフの最短距離問題においては，グラフを表現する

響を与える.また，計算モデルに基づく 言語機能がよい解

データ構造をどのようにするかが鍵であった.グループ 1

決方法は何かというソフトウェア開発の根幹に関わる問題

は節点に番号をつけそれを参照 (reference) にする形式でグラフを表現した .

の答を示唆しているのである.

グループ 2 は節点を，隣接点をたどる等のメソッドを持つオブジェクトと考え抽象データ型として最後に，このような報告書はワークショップ終了直後に書実装した.グループ 4 はグラフの弧を出発点と到達点距離

くものであるということが身に染みて解った設計しての 3 つ組で表現する方法をとった.関数型言語でのプログ

みて"の 一部の詳細として ML による最短経路問題の解法

ラミングという観点からはグループ 1 とグループ 4 のデーに関する解説論文を佐原さんが近々 SEAMAll...に寄稿され

タ構造表現方法が適切であり，実装も素直に行なえたようる予定である.技術的詳細の 一 端はそちらを読まれたい.

である. 一方グループ 2 のアプローチは汎用性を狙い過ぎ

SD97 を含め，今後のソフトウェアデザインワークショッ

たあまり問題が大きくなり過ぎ結局実装には至らなかった.

プの発展を祈りたい.
参考文献

グループ 3 は唯一酒屋の在庫問題を解いた.課題文を読んでオブジェクトを抜き出すという，オブジェクト指向設l.山崎利治他共通問題によるプログラム設計技法解説

計のアプローチに基づき設計を試みた.しかし，オブジェ(その 1)" ，情報処理第 25 巻 9 号.

クトの同定か不完全なままコード記述に移り，力任せに完

2. 山崎利治他共通問題によるプログラム設計技法解説

成しようとしたことがたたって，実装は未完成，設計は手(その 2)" ，情報処理第 25 巻 11 号.

続き指向に基づいたものとなってしまった.

3.E.W.Dijkstra , "ANoteonTwo針。blems i
nC
o
n
n
e
c
t
i
o
n

6. まとめwithGraphs" , NumerischeMathematic1:269・271 ，. 1959.
4. 島内剛一他編，アルゴリズム辞典， pp.
4
55Dijkstra 法(最以上述べたように，一見，よく定義された問題を設計・実装

短経路)の項，共立出版， 1994.

してみただけのワークショップであったかのように考えられるが，日頃開発現場で直面するようないくつかの間題が

-10・

車

W
o
r
k
s
h
o
pR
e
p
o
r
t

S伺mail Vo l. ll, NO.3

現場では常に納期に追われていて，分析，設計の工程

付録-1 参加者の主張(抑制on p
a
p
e
r
)

を省略しがちである.管理者も開発者も，開発期間が短

赤間智朗(ネクストファウンデーション)

いと，すぐにコーデイングに入りたがる.そのため，ソ(1) これまでに開発してきた主なソフトウェア・システム

フトウェア構造が悪くなり，テスト工程でパグが収束しは?

ていかないという結果に落ちいている.しかし，そうHDLC 通信制御

いった開発工程はすでに定着してしまっていて，変える

ATM 交換機 (NTI 試作版)制御にはかなりの労力が必要であり，簡単ではないと思う.

OpenL∞kGUI ピルダー

上国鉄雄(中日電子)

ページ記述言語開発(1)これまでに開発してきた主なソフトウェア・システム(2) ソフトウェア設計とは何をすることか?また，実際どは?

のような行為を fÿ なっているか?

組み込みシステムのソフトウエア

ソフトウェア設計とは抽象化されていたもの(企画，構想)をより具体化させるための工程であり，通常はこの負荷心電計(ストレステストシステム)のデータ構造設工程で必要となる仕様書は全て作成されるべきであり，計，まとめ，保守，サポート.

この後の工程(実装)で円滑に作業を行なわせる上で非常成.

に重要なものと認識しています.

麻酔(血圧)プロッタのファームウエア.血圧計との通(3) その他，ソフトウェア設計に関して考えていること

信部，全体構成のまとめ .

(何でも自由にお書きください)

1部のモジュー lレの作

4 機種ほど(現在も作成中) .

68α)().

1 機種のみ

6
8
0
3
0
.6
8
0
3
1
.

現在， 各種の支援ツールや言語等が出回っていますが，

SH7043(現在進行中) .

このようなツールや言語等を使用する前に，まずどのよ

C およびアセンプラ.

する必要があります.当然といえば当然なのですが，その昔は. 8
0
8
5
.8
0
8
6
. ASM80. ASM86. PLJM.
PLJM86. S/pLH も使っていました.

ツールや言語仕様の理解ばかりに時間をとられ，設計自自の当たることのなかったいくつかの間発品のファー

体がおろそかになるケースも少なくないのです.

ムウエア

うなことをやろう(設計しよう)としているのかを明確に

市販 AD ボード+専用 AMP+ 制御 BOX + DOSN

あと，各自のコミニュケーションの少なさという問題もあります.よほど，簡単なプロジェクトでない限り，設機による 3枇h 心電収録機(単品)

計作業は複数人数(例外もありますが)で行なわれます.

市販 AD ボード +PC・98 によるアナログデータ収録

作業を円滑に進める上でもコミニュケーションをとるこ機(単品)とは重要であると思います.

いづれもハード制御と簡単な収録&表示のみ

MS‑C6
.
0
.VC++1.0

昨年のワークショップでは，さまざまな現場担当者からの活発な意見がだされ.

(2) ソフトウェア設計とは何をすることか?また，実際ど

1 年たった今，どのような改のような行為を行なっているか?

善がなされているかが非常に興味のある所です .

顧客とのあいだで要求仕様(ハード，ソフト込みの仕朝倉鉄也(リコー)

様)をはっきりさせること.どのような，ハード，ソフト(1)これまでに開発してきた主なソフトウェア・システムとしたら，要求仕様を満足させられるか考えること.

は?

ハードウエアの設計段階から，口出しして，どうやっページプリンタの組み込みソフトウェア

たら，性能がでるか，考えること，制限のなかで，でき(2) ソフトウェア設計とは何をすることか?また，実際どるだけたくさんの CPU パワー，メモリを使えるようにのような行為を行なっているか?

してもらうこと.

実装されるハードウェア .OS 等の制約を考慮して，い機能のモジュール分け，階層分け.

かに要求仕様を満たすかを決定する工程.それにより，開発環境の整備

ソフトウェアの構造，使用するアルゴリズム等を選択す

232c デバッガ，クロスコンパイル

環境る.

ハードウエアテストプログラムの作成.

(3) その他，ソフトウェア設計に関して考えていること

モジュール間I/Fの設計.

(何でも自由にお書きください)

各モジュー Jレの設計(担当者ごと).

.
1
1
.

WorkshopR
e
p
o
r
t

S
e
a
m
a
i
lVol. ll , NO.
3

モジュー jレを組み合わせてのデバッグ.

小田朋安 (SRA)

評価.

(1)これまでに開発してきた主なソフトウェア・システム

顧客評価.

は?

ドキュメント:

流体の熱伝達のシミュレータ.

トップダウン&ボトムアップで作成しています.

(2) ソフトウェア設計とは何をすることか?また，実際どのような行為を行なっているか?

(3) その他，ソフトウェア設計に関して考えていること(何でも自由にお書きください)
現在の課題は:システムの仕様記述を基にしてシステムの構成要素とそれぞれの構成要素の責任を明確にすることによって，自社におけるソフトウエアの正しい見積もりの仕方，自社用のソフトウエア部品化(組み込そのシステムがどのように問題を解決し，処理するかをみシステム用)， IS09∞1 対応.

定義すること .
(3) その他，ソフトウェア設計に関して考えていること

組み込みソフト開発環境，もっと低価格にならないも(何でも自由にお書きください)のか.市販 RτM のライセンス料，少量生産に向いていない.

実行可能仕様の構成要素延長でシステムの構成要素を大きく変更しながら実際に動作させることができるよう

毎回専用ハードに作り込みなので，工数がすごくかな設計環境が望ましいと思う.

かっている.実際には，ハードウエアの設計工数の数倍に達している.これは，正しいことか?

加藤隆夫(エドモンドピ ジネス)

上田秀樹(オムロン)(1)これまでに開発してきた主なソフトウェア・システム
は?

(1) これまでに開発してきた主なソフトウェア・システム
は?

経理・財務.

資材管理.

ATM のソフトウェア移植:アーキテクチャが違うコン

人事・給与.

ピュータへの移植のため，自動変換ツ~)レを C++ を用いて開発している.

(2) ソフトウェア設計とは何をすることか?また，実際どのような行為を行なっているか?

(2) ソフトウェア設計とは何をすることか?また，実際どのような行為を行なっているか?

業務ソフトウェアを前提として J'設君十"をシステム設計とソフトウェア設計とプログラム設計という分け方にし

まだ私の中では漠然としていて抽象的ですが，考えていることは，与えられた仕様に対して，それをモデル化た場合.ソフトウェア設計とは，コンピユータという機すること.また，そのモデルに対して，論理的構造に組

械と特定の業務(システム)を結びつける橋渡しの役割をみ立て上げること.

するものを品質とコストを意識してデザインすることである.

(3) その他，ソフトウェア設計に関して考えていること(3) その他，ソフトウェア設計に関して考えていること(何でも自由にお書きください)(何でも自由にお書きください)

ソフトウェアの開発能力は人によって違いますから，当然理解力も異なるでしょう.そのギャップをうめるの

1) 組織向けから個人向けへ

は，個人の努力でしかないのでしょうか?

2) 部品開発と組立製造の分離思想の導入

センスが絡

3) ネットワーク市場に乗せられるような設計

むのでしたら，個人の能力になってくるので，どうしようもないのかとも思っています.

東原茂 (PFU)

また，動けばいいソフト開発というのは，結局避けら(1)これまでに開発してきた主なソフトウェア・システムれないのでしょうか.もちろん納期の関係で妥協しなけ

は?

ればならない点があるのは理解できます.ただ，後々の日本語入力ソフトことを考えると，後から利用できるようなことを埋め込

Lisp 処理系の移植開発む必要もあるのではないか，とも思います.

構造化言語の開発ソフト (YPS の UNIX 版)

とりとめがありませんが，他の人がどのように考えて(2) ソフトウェア設計とは何をすることか?また，実際どいるのかも知りたいです.

のような行為を行なっているか?
再利用性，一貫性，簡易性，効率性を考慮し， p
r
o
d
u
c
t

‑
1
2
‑

'

W
o
r
k
s
h
o
pR
e
p
o
r
t

S
e
a
m
a
i
lVol. l1, NO.
3の青写真をきちんと定義し，下流工程に繋げることだとている.

思っています.

(3) その他，ソフトウェア設計に関して考えていること

最近は設計を行っていませんが，再利用を前提とした(何でも自由におかきください)

オブジェクト指向技術の導入が必要であると思っていま

元来ソフトウェアは目にみえないことを理由に実行さす.

れて初めて判断される傾向にあると考える.現在，オブ(3) その他，ソフトウェア設計に関して考えていること

ジェクト指向中心で開発をおこない，モデル化で見えるようにしようとしているが，思ったように効果がでない.

(何でも自由にお書きください)

原因としては，

ライフサイク Jレにおいて，設計フェーズは，っきつめ

1) モデル，設計者，レピュアの質がなかなか向上しな

ると最もコスト的に重要であると認識しています.また，設計のよし悪しは，設計者の能力やさじ加減により大きU、く左右される思っています.つまり，設計フェーズでは，

2) 企業か望む(管理のしやすさ，実は錯覚)決められた

いまだに人間の頭に頼っている部分が大であると思って工程問(ウォータフォー Jレ)でチェックしようとする

います.この知的作業を支援する，ある程度の自動化をと抽象化されているはずのモデルが情報量過多とな含む sm回な設計支援ツー Jレや，設計の善し悪しを定量り，判断しずらくなる.

的に測定できるメトリクスが特に重要だと思っています.

今後の方向として，
1) モデル，設計者，レピュアにたいする教育の方法論

繁田雅11 (富士電機)

または支援(1)これまでに開発してきた主なソフトウェア・システム

2) 開発プロセスのピッグウォータフォール→多回転ス

は?

パイラル化を進めて行きたい.

1) 飲料自動販売機制御ソフトウェア
2) 自動調理装置制御ソフト

嶋中徹 (PFU)

3) 自販機設計支援・合理化システム(1) これまでに開発してきた主なソフトウェア・システム(図面作成合理化)

は?

4) 組み込み機器用 OS

インストーラ(オフコン)

5) 自販機ソフト開発支援システム

現在は画像処理屋(修行中)(2) ソフトウェア設計とは何をすることか?また，実際(2) ソフトウェア設計とは何をすることか?また，実際ど

どのような行為を行っているか?
ソフ トウェア設計とは:のような行為を行なっているか?

機能に対する要求(多くの目的の集合 A とその具現化たるソフトウェアの集合 B

場合情報が少ない)を的確に分析・把握し，最適な実現手という 2 つの集合を考えた場合に，集合 A から集合 B へ

段を表現すること.

の l 対多写像から，拘束条件(金，人，環境，保守， e
t
c
.
.
)

具体的には，

下において最適(何が最適なのだか…)となるような写像(1)要求(課題)の発掘(モデル化)

を l つ選択する作業.

(2) アーキテクチャ，アルゴリズムの考案と決定(表現)

実際は目的自体の変更がしばしばであるため，或る写(3) 実現のプロセスの設計

像を設計段階で決定することは困難!

付)実生産であるプログラミング工程に (1)(2) のプロ(3) その他，ソフトウェア設計に関して考えていること

ダクトを的確におくること
実際の行為:(何でも自由にお書きください)

オブジェクト指向中心の開発をおこ考えたことがない.

なっている. (下記番号は上記番号に対応).
(1)ooA(主な手法としては Bαx:h ， OMT) による要求のモデル化

関口直利 (SRA)(1)これまでに開発してきた主なソフトウェア・システム
は?

(2) 上記の延長で OOD によるアーキテクチャ，アルゴ

リズムのモデル化

電気メーカ 一部品管理システム(3)00 により開発における情報モデルを作成し，整流，

衛星データ地上利用システム

合理化視点で再構築(4) 抽象データによるプログラミングを励行し， OOD!

ガス会社自動検針システム(2) ソフトウェア設計とは何をすることか?また，実際どのの結果をできるかぎり忠実にプログラムに反映させ

‑
1
3
‑

S
e
a
m
a
i
lVo l. ll , NO.
3WorkshopR
e
p
o
r
t

ような行為を行なっているか?

(1)これまでに開発してきた主なソフトウェア・システム
は?

-こういうプログラムを作るよ .いいですか?と確認するもの.

機器組み込み型ソフトウェアの開発です.より具体

・ お客様の要求と作成するシステムの機能差を説明/的には，金融機関向け自動入出金機 (ATM) のドライ合意するもの.

パソフ ト・アプリケーションソフトを開発しました.

・ システム実装の最適化を考える作業.

(2) ソフトウェア設計とは何をすることか?また，実際ど(3) その他，ソフトウェア設計に関して考えでいることのような行為を行なっているか?

(何でも自由にお書きください)

私共の会社・部門においては. r設計」とは機能設計~

設計方法や手法は，開発する環境(主に人)によってプログラミング完了までを意味します . また「設計者J

様々であるので，いろいろな方法の共通点とは何かを考は普通，設計したソフトのデバッグまでを担当します.

えてみたい.それを見つけることによって方法が変わっ「設計」とは与えられた要求仕様を最適な品質(プログても最適な設計ができると思う.

ラム容量処理速度・変更容易性・ 納期等々)で実現するた

また，設計の重要性や必要性の認識についてエンジニ

めにソフトウェア全体を分解し，配置し，組み立てる行

アとお客様の聞で異なることがあるが，予算や技術の未為すべてと考えます.

熟さなどによって必ずしも合意できて仕事をすることは(3) その他，ソフトウェア設計に関して考えていること稀である.その際の事実の説明力と説得力を見につけた(何でも自由にお書きください)

いと思う .

設計者は要求仕様の分析者やプロジェクトの管理者より低レベルの仕事とみられており，入社後数年の経験を

高橋正一 (SRA)経てようやく「よい設計」が可能なレベルに到達するや(1) これまでに開発してきた主なソフトウェア・システム

いなや分析・管理の仕事に担当が変わります.有能な設は?

計者にそれなりのキャリアパスを用意することと早く一UNIX をリレーショナル・データベースのサーバと定レベル以上の設計ができるような方法論を見出すこと

し. Windows パソコンをクライアントとする ，業務向の両面がよい設計によって作られたソフトを蓄積するたけクライアント・サーパ・システム .

めに必要と考えています.

(2) ソフトウェア設計とは何をすることか?また，実際どのような行為を行なっているか?

友校教 (SRA)(1) これまでに開発してきた主なソフトウェア・システム

ユーザの雑多な要求を取りまとめて一旦抽象化し，目は?

的と手段を明確に分離する.さらに，情報の流れと機能，人の役割を明確にし，物理・論理の両面で実現可能なレラスターグラフィックスレイトレーシング，テクス

ベルにまで詳細にアーキテクチャを定めること .

チャーマッピング
アナログ L S1 レイアウト CAD 回路図→ LSI レイ

実際には，順に，概念定義，要求定義，基本設計，詳
細設計を行なう.各作業で実現可能性を検証し，問題がアウト図展開あれば前作業を再度行なう .

ソフトウェア自動合成システムフレームによる内部表

現.

(3) その他，ソフトウェア設計に関して考えていること

R
e
a
d
e
r
f
P
r
in
t
e
r

Smalltalk 動的メトリクス計測ツール(何でも自由にお書きください)(2) ソフトウェア設計とは何をするところか?また，実設計に関する理論や手法は巷に数多くありますが，実際どのような行為を行っているか?

際に，開発現場で採用されることは少ないです.多くの場合，忙しさに紛れて，一部の人の経験にたよって，ス問題を具体的に解決するためのアーキテクチャを考案

ケジュー Jレ優先で進められるのが現状です.この状況が，するところだと考えます.で，"解決"ってえところが肝で少しでも改善されればと考えています.

すね.様々な状況というか制約というかを考慮に入れな
がらやんなきゃなので，一筋縄ではないですね.さ・ら・

私の担当プロジェクトですが，基本設計から始めて半に・解決する対象や解決された後の望まれる姿も唆昧だっ

年間やってきたこ 。とが，実現不可能ということで，全てたりしますし.解決のための資源時間は限られてるし，白紙に戻して，要求定義からやり直しになりました.上

そりゃもうてんやわんやですわ.

流工程の重要さを，しみじみと実感する毎日です.

で，僕としては有史以前的な仕様確定を前提とする"設出野徹(オムロン)

計"はナンセンスだと考えます.なんたって，新規開発に

‑
1
4
‑

明

S
e
a
m
a
i
lVo l. ll, NO.
3WorkshopReport

は公然の秘密:る.なお，ここでいうアーキテクチャとはオブジェクト
モデルに代表されるような各種モデルやコードなどの実(h叩://www.sra.co .jp/pωple/tom田da/reuse/

現の仕掛け，記述といったものである.

witchcrafν'productibity/secret- work.html)がありますからね.

第三世代では第二世代での抽象クラスに対し，抽象だからコンピニシステムは例外として，"設計"は変更をアーキテクチャがある意味で重要な関心事，ということ前提とする設計を行うことが肝要と考えます.この考えになる.これに伴い継承も，属性やサーピスという一次を押し進めていくと，仕様の変更に対する強き免震性や元的なものからアーキテクチャという二次元的なものへ再利用に向かうのは自然の成り行きです .従ってこれかと移行，進化する必要が有る.

らの時代の"設計"は免震構造や再利用構造(!?)を考案す

この時，アプリケーション(のアーキテクチヤ)がそのるところと捉えます.

ドメインという方向に抽象化された抽象アーキテクチャ

で，僕としてはできるだけ問題(領域のへソを捉える

様に意識/努力していると.その具体的内容は…

が，ドメインモデル，いわゆる俗にいうフレ一ムワ一クう~ということになろう(個人的にはこのフレ一ムワ一クのんどうしてんだろ.よくわかりません.ぺただかような定義は気に入らないが…...)

ことをやっていると当然のことですが，立ち上がり時に当然第四世代では第三世代ドメ インモデJルレに，ドメイコストがかかることがネックですね.でもまあ私は同じ

ン固有の開発のやり方やノウハウ，方法論(! ?)が加味

蕎麦でも，駅前の立ち食いよりも評判のいい手打ちを食
べたいし，世間もそうあって欲しいと思う今日この頃なのであります.

されることになる.

友田稔(ダイキン工業)(1)これまでに開発してきた主なソフトウェア・システム(3) その他，ソ フトウェア設計に関して考えていること

は?

6可でも自由にお書きください)

UN医(8VR4 なめ， X-Window のポーティング#さ~再利用するぞ!

UNIX の 08 の改造，各種デバイスドライパ開発(2) に関連して川オプジェクト指向に期待しています.

CAD システムの開発 (WindowsNT/95 対応)

現状のオブジェクト指向がこの問題に対する解を与えて社内ツールの開発(WindowsNT/95 対応)

いるとは考えないが，最も近似解であると思われるので .

(2) ソフトウェア設計とは何をすることか?また，実際ど

なぜなら，再利用のためには"ソフトウェアに関するのような行為を行なっているか?

知識"を表現する必要がある.関数などに比しオブ

フトウェア設計とは何か? (エンドユーザが触れるア

ジェクト(フレ ーム)はソフト知識の表現形式として優プリケーション開発の場合) :れている.

対象を理解し，コンビュータ化する物の抽出(理解・

私は，オブジェクト指向は再利用(ソフト資産化)へと分析)

向かうものと捉えている.つまりオブジェクト指向は次

ソフトウェア構造の検討(プログラミングのためののような進化を遂げていくと考える.

分析設計)

第一世代:再利用に適したソフト表現(いわゆるモデ

プラットホーム，開発環境の利用方法の検討

ル化)

実際どの ような行為を行なって いるか

第 二世代;ボトムアップ，汎用的(水平)部品利用
第三世代:トップダウン，専用的(垂直)部品利用

オブジェクト指向 (OMn 手法で，対象を分析

第四世代:これらに加えプロセスの知識が統合，組織

プラットホーム(開発環境)の利用方法の検討(工夫)化

最近行なっているソフトウェア設計の傾向として，第五世代:第四世代に形式技術 AI 技術が融合した開Windows 専用のアプリであるにもかかわらず，プラ ッ ト

発環境

ホームに依存する部分と非依存部分を完全に分離し，その掛け渡しとして仮想の機能(インターフェース)を設定

大雑把に見て現状は， OOA，OOD が第一世代， OOP が第二世代，デザインパターンが第 二 .五世代(抽象部品

して，プラットホームを意識しない設計(ただし，言語化)フレームワークが第三世代に入らんとするところ，とには多少依存)とプラットホームの利用を検討する設計

いったところであろうか.

に分けて作業している.

(3) その他，ソフトウェア設計に関して考えていること

個人的には，第三世代に移行する際に重要になるのが，(何でも自由にお書きください)

クラスからアーキテクチャへの視点の変化だと考えてい

‑
1
5
‑

S
e
a
m
a
i
lVol. ll , NO.
3WorkshopR
e
p
o
r
t

ソフトウェア設計とは，要求(対象)と計算機をどう結

3 . いろんな設計方法を検証して，その方法に適用な対び付けるかで，現在， 00 など対象を扱うことがもては

象領域を分類して，これらの方法はお互いに補い合やされているが，それと同じレベルで，プラットホーム

い，増強し合うこともできます事例を会社の財産として蓄積しているところがありますか.

の利用技術や，言語に関する知識，開発環境などが重要であると考える.実際， 00 が分かっていてもこれらが4. モデルを記述手段として，メモや図式なんでも，いないと役に立たない.さらに，着眼点や，アイデア(利いです ， 自由にシステム構造のモデルを簡単に描く用技術)の絞り出し方も重要で，これらの技術の育成なことができ，そのは設計の起源と思います.それをどがむずかしい.

支援するツールがご存知ですか.

現状，仕事の関係で， Windows の利用技術を含めた設

堀茂樹(富士電機)

計を 00 を用いて行なっているが，以前の仕事のデバイ(1) これまでに開発してきた 主 なソフトウェア・システム

スドライパ開発や， UN医のポーテイングなどでは，対は?

象に対するソフトウェア設計というより，与えられた環

自動販売機の制御， OS- マルチタスクリアルタイム OS ，境(ハードやソフトウェアの API: インターフェース)のアプリーアセンプラ. 8 ピット CPU，スツテプ数一利用の検討(利用技術の追求)がほとんどであった.

約 6 万.処理内容は，通信 を用いたマスタースレー

ソフトウェア設計の技術を語るとき， 一般に暗黙のう

プ制御・ダイナミ ツ ク1/0 制御のシーケンス制御・

ちにビジネス系ソフト (OS の上で動作する，最もユーザ

LCD/キーボードの MMI.

に近いアプリケーション)を ペ ースに語られているが，イ

自動販売機の制御， OS ーマルチタスクリ。 アルタイム

ンフラ側の OS そのものやミドルウェアなど，ジャンル

OS ，アプリ -c 言語， 16 ピ ッ ト CPU ，ステップ数一によって，手法や，考え方 ， 実際の作業方法はかなり異約 15 万.処理内容は，通信を用いたスレープ制御-なっているように思う.これらジャンルでのソフトウェ

1/0 制御・データペース制御 .

ア設計も議論してみたい .

自動販売機の制御ボードのテスト装置， PC98 を用いたテスト装置， OS は MS・DOS ，アプリは C 言 語，ス

方学券 (SRA)(1)これまでに開発してきた 主 なソフトウェア・システム

テップ数は約 3 千，処理内容は回線制御・1/0 のシーは?

ケンス制御.

(2) ソフトウェア設計とは何をすることか?また，実際ど

言語解析 (COBOL， JCL など)システムのような行為を行なっているか?

リパースツールの GUI システム

[1]位置付け(2) ソフトウェア設計とは何をすることか?また，実際ど顧客と営業の仕様打合せー〉のような行為を行なっているか?

制御仕様書作成(担当業務)

ソフトウェア設計はモデリングとモデル構築の問題とー〉

ペースソフトに新規・変更分を組込みー〉

思います.個人として図を書いたり，メモをとったりしテスト機でプラックボックステストー〉て，モデJレをはっきり見えるまで，繰り返します.明確出荷

できたモデルは正式に図式にしていません.その人間精自販機の機種と仕様の相違

神能力を半分放棄していると思いながらも，適切な記述法もなし，重視されていないので，そうしかないとあきらめています.コードさえできれば，どう成り立てたのは開発時点で誰も関心がないです.

↓仕様機種→機種 l

仕様

A を B する

. 機種 50
A を C する

(3) その他，ソフトウェア設計に関して考えていること
仕様 _n(何でも自由にお書きください)
1.有名な設計方法はいくつか提唱され，そのソフト

L[2] 何をすることか?

ウェア設計方法の選択を取り巻いている宗教的な熱ー

狂がありますが，本当に万全でしょうか.万全でな

ソフトウェア設計の 1 側面はお客の要求を仕事に変換することければ，設計支援ツールの有用性に疑問があります.

•

カップ自動販売機(カップに飲料が入って出てくるタイプ)の場合， r粉原料をど

2. 設計の目的は，複雑なことを簡単なものにしたいで

う混ぜて溶かすか」がノウハウで顧客により要求がすが，簡単になれるはずがないために，簡単に見せ変化する.例えばコーヒーとクリームを同時に混ぜる仕組もつけるでしょうか?

たいお客もいれ 11，クリームは後から混ぜたいお客

‑
1
6
‑

W

S
e
a
m
a
i
lVol. l1, N
O
.
3

W
o
r
k
s
h
o
pR
e
p
o
r
t

もいる . これらの要求をまともに聞くと顧客毎にプ少なくとも「制御仕様書J r プログラム J rチェック

ログラムを作る必要があるこれをもともにやるとリスト」の構成を同一化し，連携の取れる形にし，仕様作る労力 ・ 管理・試験の労力で利益がなくなる.この要書の変更がプログラムに反映される ようにしていきた

求とやることのバランスをとるための仕様を作成す

U、るのがソフト設計 と考える.

松島弘幸(リコー)

そこで， リソース(ベ ースソフト)を見て要求の内(1) これまでに開発してきた主なソフトウェア ・ システ

容 をまとめプレゼンし .(相手 は営業)OK となって制ムは?

御仕様を作成する . また，実験が必要なものは実験計

入社 2 年固なので，まだシステム開発の経験はあ画の中でプラッシュア ッ プしている.問題としては，りません.ソフトウェアの開発支援に関する研究とお客からの仕様変更・我々の理解不足・ 我々のリソープロトタイプ開発を行っております.

スがどうなっているのかが理解・整頓・分析されてい学生時代は，ロポットピジョン のシステムを開発

なくて，もので確認する段階で変更に変更を重ねて

しました.

いる.

ー

(2) ソフトウェア設計とは何をすることか?また，実際

ソフトウェア設計の 2 番目の側面は機械のクセを織り込むこと•どのような行為を行なっているか?

自販機で飲料を調理する時いろ

いろな原料を混ぜる.シロップ飲料(例えばコーラな

現在，オプジェクト指向 言語を使用しておりますのめでは炭酸水・冷水・ シロ ッ プ・氷が混ぜ合わされるで，ソフトウェア設計=クラス設計ということになりが，この順番・タイミングが自販機の種類によってますが，開発したクラスをフレームワークとして提供違ってくる .このクセを顧客から隠し，制御の中にできるよう，再利用性，モジュール性を重視しており閉じ込め異なる機械でも同じ味になるように仕様をます.また，クラスの役割を明確にした設計も重要で作るのがソフト設計と考える .

あると考えております.これに関してはデザインパ

これは前述の内容と矛盾しており，この調整は個ターンの考え方を参考にして，取り入れております.

人のスキルによってやり方が変わる.この個人のス(3) その他，ソフトウェア設計に関して考えているこ

キルを均一にすることがおおきな課題と考えている.

と(何でも自由にお書きください)‑ 3 番目には過去の資産(ベースソフト)を 生 かしな
がら新しい機能を付加することを考えること •オブジェクト指向においては，分析→設計→実装という開発フェイズをシームレスに行うことができるの

自販機のソフ トは「ペースソフト+新規仕様一時代が利点であるといわれますが，実際には各フェイズの遅れ仕様」からなり，ペ ースの ソフトは今までのノ間の溝は大きいように思えます.また，ソフトウェア

ウハウの積み重ねの結果であり，大事にする必要がの再利用性を考えた場合，よい分析を行えばそれで再

もちろんあるが，新しい機構・機能にも対応する必要

利用が得られるかということこれも疑問で，私はよいがあり ， このバランスをとることが必要になる.そフレームワーク設計がキーポイントになると考えておこでまずやっていることは，ベースソフトの仕組み

ります.

をソースから追い，その上で制御仕様に逆展開して

付録-2 SD96グループ栂成褒

いる.制御仕様の作成者，それを受けてプログラミン
グする方の両方の担当は固定しておらず，最も信頼グループ 1できるドキュメントから新しい制御仕犠を作る.

: 佐原伸(責任者)赤間智朗加藤隆夫関口直利友田稔(3) その他，ソフトウェア設計に関して考えていること

グループ 2(何でも自由にお書きください): 小田朋宏(責任者)朝倉鉄也栗原茂繁田雅信方学芽

現在，自販機のソフトドキュメントで大きなものにグループ 3「制御仕様書J r プログラム設計書J rチェックリスト」: 野呂昌満(責任者)

上回鉄雄高橋正一出野徹松島弘幸の大きく 3 つある.

グループ 4

これらは各々独自の視点(あってないようなもの)で: 伊藤昌夫(責任者)

上田秀樹久保田益則友校教堀茂樹

作成されており，ドキュメント上は何の因果関係もな

PC グループ:

いがそれぞれがそれぞれを参照して作られている . そ山崎利治(責任者)

岸田孝一熊谷章のため，プログラムのあるモジュー Jレは複数の「制御仕様書J をみなければ作成できず混乱杭轡にあるとい

える .

‑
1
7
‑

SeamailVol. ll , NO.3

WorkshopReport「組込みソフトウエア分野のプロセス改善活動に関する情報交換会j 報告高木徳生(. 1) 、(.1)オムロン株式会社

1
1
:1
5
1
1:
4
5

小泉毅 (.2)

ソーシアル事業グループ開発・生産センタ(.2) キヤノン株式会社

Wo

ソフトウエア開発部

ソフトウエア技術開発部

3
.
本章ートメ

8/29 (金)はじめに去る 1 997 年 8 月 2 9 日から 3 0 日の 2 日間に渡り 、主に組み込みソフトウエア分野の会社 8 社計 2 3 名が集まって

1
3
:
0
0‑ 1
3:
1
5 オープニング
1
3
:
1
5‑ 1
3:
3
0 富士フィルム(株)、大同信号(株)自己紹介

それぞれの会社でのプロセス改善活動に関わる情報交換会が静岡県御殿場 LaLaGOTENBA (オムロン(株)保養所)で行わ

1
3
:
3
0‑

14:30

進める上で実際に抱えている問題なとe についてじっくりと議

発表&デイスカッショ論をしたいという声が最近増えてくるなか、関係している会

íIS09001 を ベースとしたプ ロセス改善j社が一同に集まって意見交換をする場を設けたらどうかとい(グループウエアを使ったプロジェクト管理事例も含めて )士制士ヤ同一ム

1
4
:
3
0‑ 1
5
:
3
0 山一情報システム(株)富仲富キ大山オ

現場でどのような活動が行われているのか、あるいは活動を

発表&デイスカッション(92 年度からの活動概要 )J

でプロセス改善活動に従事している人たちがプロセス改善の

8 千土 2
ダイ株)リコー「組込み型ソフトウエアのプロセス改善の概要れた。この集まりは、特に組み込みソフトウエア分野の会社

紹介メ

1
5
:
3
0‑ 1
5
:
4
5 <CoffeeBreak>う話が持ち上がり開催するに至った。
本会の目的は、単なる情報の交換の場だけではなく、今後

1
5
:
4
5‑ 1
6
:
4
5 オムロン(株)発表&デイスカッション「オムロンにおけるプロセス改善活動 5 年目のの現場でのプロセス改善活動に活かすことができる知識を参

参加者間で意見交換しながら準備を進めてきた。当初は興味

1
6
:
4
5‑ 1
7
:
4
5 富士ゼロックス(株)る方向で検討を進めてきたが、参加者の興味分野が広くテー「富士ゼロ ッ クスにおける Assessment の実際1マを絞ることが難しいことなどから参加各社での取り組み紹

1
7
:
4
5‑ 1
8:
3
0 休憩

介を行って意見交換をするという進め方をすることになった。

1
8
:
3
0‑ 2
0
:
0
0 懇親会

また個別に議論したいテーマがある人が発表する場も一部設

2
0
:
0
0‑ 2
2
:
0
0 個別テーマ発表&デイスカッションの改がき費実フリーデイスカッション

いま性ス制置開聞

2
2
:
0
0‑

会社名

電

/マネジメントグループデイスカッショ

けた。本稿では、情報交換会の内容を紹介するために各社か

-尾本

司EA

発表&デイスカッショ ン)(

あるテーマを決めてグループデイスカッション中心の会とす

らの発表概要と参加者のポジシヨンペーパー及び参加後の感

以下、ターニングポイント 1

加者が持ち帰ることができることとし、当日の進め方な ども

想などをもとに報告する。また、会終了後も本メンバーの意
見交換用に開設しているメーリングリスト上で議論が続いて8/30 (土)いるため、その内容についても紹介する。

9
:
0
0 ‑1
0
:
0
0 ダイキン工業(株)発表&デイスカッショ

ところ:オムロン(株)LaLa 御殿場

技術移転について J +プログラム自動生成ツールのデモ

1
0:
0
0‑ 1
1:
0
0 キヤノン(株)発表&デイスカッショ ン

志ι「キヤノンにおけるソフトウエア生産性改善活動の展開

静岡県御殿場市深沢字長尾 257 1

手開プ

1997 年 8 月 2 9 日 13:00-30 日 1 2 :00

いう~辻 μvnIとき:「構造化手法を中心としたソフト生産性向上の取り組みとl

2. 情報交換会スケジュール

1
1
:
0
0‑ 1
1
:
1
5<CoffeeBreak>

スケジュール:

ファ

‑
1
8
‑

W
o
r
k
s
h
o
pR
e
p
o
r
t

S飽mailVo l. ll , N
O
.
3

1
1:
4
5 全体デイスカッションの基本ソフト移植研究に携わっていたことから、マイコン

1
2:
0
0 今後の進め方、クロージング

ソフトから WS/PC アプリまでソフト開発力という面から
空調設計部門のソフト技術者に比べ一日の長がありますし、
逆に空調機制御と言う面からはほとんど素人です。このこポジションペーパー本章では、本情報交換会参加者を中心にポジション・ステ

とが、現場への技術移転、空調製品の共同開発場面でいろ

いろな問題を生みます。その問題の整理も含め、今は手探ートメントと参加した感想について紹介する。

り、試行錯誤の状態で、現場への本格的な定着までまだま
紹介メンバー (敬称略、順不同) :だ道は険しいといったところです。ちなみに上記技術を活8杜 2 4 名

かして 、 空調部門のマイコンソフト開発は構造化手法をベ(括弧内は、情報交換会へは不参加の方)

ースに行ってますが、我々自身の自動化ツールそのものはダイキン工業(株) :尾本林貞、新田武史、友田稔、

オブジェクト指向で開発しています。

(小幡健司 )

(2)参加した感想

富士写真フィルム(株) :鈴木圭 一 、菅原耕一

今回参加するまではどんな情報交換が出来るのか若干の(株)リコー:松瀬健司、小田利彦、近藤満、山村隆
富士ゼロ ッ クス(株) :中村淳

不安と大きな期待がありましたが、御陰様で有意義な時聞

キヤノン (株) :小泉毅、山田潤二が過ごせたと有り雛く ，思っています。感想を一言で言うと、

大同信号(株) :菊池実

情報交換会で皆さんのプロセス改善の取り組みを聞かせて

山ー情報システム(株) :田淵秀之、小笠原正人

頂いて、さらにその後の私の疑問にメールで答えて頂いた

オムロン(株) :坂本啓司、板嶋敏男、丹羽徹、朝見昇、お話を伺って、プロセス改善に対する自分の不勉強さを痛唐鳥めぐみ、稲垣勝巳、新原直樹、高木徳生

感した次第です。(何せ、坂本さんがオムロンのメンバーの方達に rCMM の勉強不足だ! J とおっしゃってたくら

以下、上記名簿順に紹介する 。 (敬称略)いですから、我々はなおさらです。)

11本林貞(おもとしげさだ)

会社名&所属:ダイキン工業株式会社..野田武史(にったたけし)

電子技術研究所

会社名&所属:ダイキン工業株式会社電子技術研究所(1) 自己紹介
電子技術研究所のソフトウエア技術グループに所属して(1)自己紹介います 。 4 年ほど前から「マイコンソフトの生産性・信頼2 年ほど前から社内の組み込みソフト開発の支援をして性の向上J を目指した取り組みを行ってますが、「プロセいます。昨年は大型空調機の、今年は小型空調機の組み込ス改善J という切り口から言うと直接その役目を担った体みソフトを対象としています。それまでは空調機とは関係制があるわけではなく、プロセス改善ということを念頭にの無い仕事をしていました(尾本の紹介にもありましたが置きながら、具体的には「開発手法による標準化J 、「自社入社以来グラフィックス関連一筋でした)。当初はソフト開発ツールによる自動化j を推進して、結果としてソフト

ウエア作り、という観点で開発プロセスを見て、その部分

闘発の効率化、ひいてはプロセスの改善に結びつけようとの改善に注目していました。ところが我々が対象とするドいう取り組みになっています。我々は研究部門ですがここ

メインではソフトウエア開発は製品開発のほんの l 部であ

1-2 年は、より設計部門への寄与度を高めるこ主と上記り、この部分の工数を最少にして最高の品質にするだけで手法やツールの布教活動も兼ねて、設計部門との製品共同

は片手落ち、との考えを持つに至りました。最近はソフト

開発への参画度合が高まって来ています。また、我グルー

ウエアを含む物づくり(軸足はソフトウ玉アですが)といプを構成する技術者が以前、グラフィックスターミナルのう観点で開発プロセスを見るようにしていこうと考えてい77 ームウエア開発やグラフィックスワークステーション

ます(まだまだ現状調査段階ですが . .
.)。もちろん現実に

‑
1
9
‑

W,

S
e
a
m
a
i
lVo l. ll, NO.
3Wor肱shopReport

な背景もあり、私自身は組み込みマイコンのソフト開

まだまだ悩み事も絶えず、手探りの状態を脱しません。

術者と言うより、アプリケーションソフト開発の(2)参加した感想

す。現在の取り組みでは、マイコンソフト開発を支援す」院軍司寸司寸

進めています。その中でいろいろと得たこともありますが、

上・・・・なプ用しベースのアプリケーションを開発していました。このよ)41/信頼性向上を目指して、主に開発手法/ツールの導入を，sz、

イタワークステーションの OS 部分の移植/開発や、胃11はその第一歩として、開発現場に対してソフト開発効率化

形で、今回デモを予定している自動化ツールなどの開発、更に他社の技術者の方々との交流も深めることができ、私サポートを担当しています。今回の技術交流会では、としては大変刺激的な満足のいく 2 日間でした。

したツールのデモと共に、手法やツールの導入に関する-今後の私たちの取り組みのヒントのようなものをたくさ論ができればと思っています。

ん得たように思います。

※現場の開発者が自ら手法やツールを導入する場合は、.
r プロセス改善J と言えば、最初は「管理技術J が中心

比較的スムーズに導入できると思いますが、ある種、第 jとなる為か、我々が主に取組んでいる「開発技術J はある者的立場から手法やツールの導入を推進すると、それ種毛色が違うという感じもありました。

いものであっても何らかの抵抗を受けるように思います。

し、 E-他社では全社的に「ソフトウエアのプロセス改善」に取

私のようにツールを開発し導入しようとしている立場と

法4組んでおられるようで、当社においてもその必要性を感じでは、この抵抗を和らげスムーズに導入するノウハウをる反面、積しなければならないと考えています。

-鈴d1)他社ではソフトの規模(も開発している陣容)も我々

(2)

会社 4

より大きく、ソフト開発のコストに与えるインパクトも大きい。

2) そのため、開発手法以前のルールづくり等の管理の充参加した感想itEl1-他社におけるいろいろな取り組みについてのお話を聞け、同じ立場の技術者の方とインフォーマルな形で情できた事は大変有意義でした。また、その後のメーリン(1)

リスト上での議論も、大変参考になっています。

・業1

印象に残った事を 1 つ 2 つ.. .

実がより大切。
という事情があり我々と取り組みのスタンスが異なってい「プロセス改善J は理解されにくいという事について、すJる、とも感じました 0「見えにくい J のではなく、「見えるようにしていな

グJ

・ちなみに当社の生産本部では、 1Sω001 への取り組み(工けJ と言う意見は、当たり前といえばそれまでですが、内t

場として取得済み)により、製品開発全体での管理面では分に当てはめてみると「理解されにくい」事を前提に周を2それなりに充実してきておりますが、特にソフトの開発工に理解を求めていたようで、もう少し考え方をシフト・参1程だけで見ましでもまだまだ課題は多いと思っています。

ければと感じました。また、同じ組み込み系のソフトで・最後に事務局の皆様はじめ参加、サポートの皆さまには急激に変化している情報産業に用いられている製品と、たc

色々お世話になりました。どうもありがとうございました。

祉のように関係が浅い製品では、ソフト開発に求めら

キ・

今後ともよろしくお願いします。

ものも異なり、それに合ったアプローチが必要で、我#の .

アプローチである技術面からの取り組みは、当社にとっ菅lは有効な手段の 1 つであると再認識できました。

を4

今後、日常の環境から離れてリフレッシュし、発想はや、きっかけの作れる場となる事を期待します。

よ.

-友田槍{ともだみのる)
会社名&所属:ダイキン工業株式会社

電子技術研究所

ソフトウエア技術グループ

(1)

.参j

自己紹介

-小幅値司(おばたけんじ)

電子技術研究所のソフトウエア技術グループに所属し、2 年ほど前から「マイコンソフトの生産性・信頼性の向上J

会社名&所属:ダイキン工業株式会社電子技術研究所

持を目指した取り組みを行っています。それまでは、グラフ

ソフトウェア技術グル

が.

‑
2
0
‑

S
e
a
m
a
i
lVol.ll , NO.
3WorkshopReport(仕事)をしていないので、皆様方からの情報が設計・開発(1)自己紹介

4 年ほど前から「マイコンソフトの生産性・信頼性の向は、サイドの立場で参考になる(活かせる)ことを楽しみにして上J をテーマにしています。取り組んできた内容は、います。弊社には組織としてプロセス改善を推進する部署

・開発手法(リアルタイム構造化手法)の勉強、評価がありません。尾本さんのメイルで言われている点(ソフ・製品のソフトを試作しながら手法のカスタマイズ

ト開発に対してほとんど理解できてない経営トップに、ど・手法で作成したモデルからソースコードへの変換法検討のようにしたらプロセス改善の重要度を実感として理解さ・手法、自動化ツールを実際の製品開発へ適用(開発現場せることができるのか、成功された先人の苦労話、ノウハに入つての共同開発)

ウ等を聞き、それを我が社(何も着手出来ていない)に当などです。現在は、適用範囲の拡大に取り組んでいます。

てはめながら、意見交換をしたい。)について興味があり

プロセス改善とも関係すると思いますが、新しいことを適ます。しかし、経営トップ云々はトップダウンで会社が進用した効果を定量的に評価することに苦労してます。収集

めていく場合であって、現状を考えると担当者個々が組織した開発データから人的な要因を排除することができずに的にプロセス改善をする必要性の認識をもつようになるこいますので、正しく評価できているとは思えないまま、手とがまず必要だと思っています。またそのためには、どの法やツールの導入効果の数字をたたき出しております。

ような取り組みが有効か参考になる事例紹介が聞けたらと思っています。また、現状の開発スタイルを大きく変える-鈴木圭一(すずきことなくプロセス改善できる(していける)開発ツールの紹

けいいち)

介が聞けたらと思っています。

会社名&所属:富士写真フィルム株式会社(2)参加した感想

宮台技術開発センタ}

2 日間;各社の事例紹介を聴講して、弊社の組織として(1)自己紹介のプロセス改善への取組みが非常に遅れていることを痛感

・業務内容

現在の職場では組込み系のソフトウエアの設計・開発をしました。まずは、機会ある毎に上位の人に刺激を与え、するグループに所属しています。また、職場内の品質技術

少しでも組織としてプロセス改善に取組んでいけるよう意

グループにも所属し、主に 15ω001 認証取得に向けて職場識づくりを推し進めるとともに、個人的には更なる学習を内の事務局員として活動しています。(事業所で認証取得進めていくつもりです。私はプロセス改善・プロセス管理を考えています)屋という点では素人なので、みなさんへのインパクトある-参加のきっかけ

意見がなかなか言えませんが、プロセス改善活動はこれか

弊社、菅原の紹介で参加させていただくことになりました。そもそも菅原からの誘いに OK したのは rCMMJ がら益々重要になると思っている人間なので、これからもよろしくお願いします。

キーワードになっています。昨年 1 年間 CMM のレベル 2の KPA について社外の方と勉強会をしていたこともあり、-菅原麟ー(すがはらこういち)

菅原君の昨年のシンポジュームの参加報告を目にして、声

会社名&所属:富士写真フィルム株式会社を掛けたのがきっかけだったと思います。 CMM について

宮台技術開発センター

はレベル 2 の KPA の意図くらいしか知識がありませんが、(1)自己紹介
宮台技術開発センターの中の、感材機器開発グループのよろしくお願いします。

ソフトウエア開発グループに属しております。
現場でのプロセス改善活動に活かすことができる知識をプロセス改善については、我々の所属部隊で特に何かを行持ち帰るというより、知識が深まることを期待していますっているわけではありませんし、また SEPG のようなサが、プロセス改善活動というような位置付けで現在は活動

ポート部隊があるわけでもありません。典型的な CMM レ・21-

WorkshopR
e
p
o
r
t

S
e
a
m
a
i
lVol. ll , NO.3

W

ペル 1 の組織であります。プロセス改善については、全く動を実施しています。

9 6 年にソフトウエアの生産性を向トで個人的な興味で勉強しているような状態であり、組織の成上するための全社的な組織として P-PT が発足し、全社

加オ

熟度を上げて自分たちの仕事をやりやすくしたいと「個人的な展開活動も実施してます。 CMM をベースに改善を行スラ的に」思っている状況です。しかし、「組み込み系J におってますが、‑/J{
3

いては、ソフト屋だけが「プロセス改善だj と叫んでも、善活動とメトリクス活動を中心に実施してます。

レf

結局はハード屋のわがままに振り回されていたりで、ソフ(2) 参加した感想

技祈CMM のレベル評価は重視せず、具体的な改ト屋だけのプロセス改善を考えていても限界があるように他社さんの取り組みをいろいろ認識することができ、非の七思えます。「ハードとソフトを含めた組織全体に対するプ

常に感謝しております 。 また、企業の中でのソフトウエア

要t

ロセス改善」の第一歩を踏み出すためには、何が必要なの

プロセス改善への取り組みは、必ずピジョンと執念を持っ(2)

かについて、ヒントが得られたらいいなと考えています。

た 1 人、

2 人のキーマンにより実施されていることが伺えモソフトウエアの生産性向上の取り組みとしては、5-6 年ました 。 現場での問題意識から改善活動をされているケーのカくらい前に、構造化手法にチャレンジし、 Teamwork といス、スタッフのポジションで幅広く改善されているケース、

啓蒙

う市販ソフトを用いて DFD 等を書きましたが、それがうま各社さんともそれぞれ企業の問題意識にマッチした、活動

く設計やコーデイングの工程につながらず、不満を持ったができている事も感じました。

-近圃

ベストプラクティスを同じ仕事にたずさわっている方々

経験があります。

って、長期間活動されてきた成果はなかなかまねのできな

構造化手法はすたれてしまい、オブジェクト指向ばかりがいものです。ソフトウエアプロセス改善への取り組み方法

脚光を浴び、どんどんと我々のような組み込み系のソフトが、いかに多種多様であり、どれが正解か、ということも環境は置き去りにされていった感があります 。

なく、しかも、企業の中のいろいろな圧力に負けない馬力(
2)参加した感想が必要である、ということも改めて認識できました。ソフ

今回の情報交換会に参加して 、 皆さんのさまざまな取り

トウエアのプロセス改善の仕事においては、一企業の中で組みの話を聞き、たいへん参考になりました 。 と同時に、情報交換したり、課題認識を確認したり、するにはメンバ

何も取り組んでいない我々の現状が、たいへんはずかしく、ーの数など非常に無理なことが言えます。その意味では、

また危機感を持ちました。これからも、皆さんの経験を聞

他社さんとの数々の情報交換の場は重要な機会であるともかせていただいて、失敗するメカニズムを理解し、成功へおもえます。今回の場は非常に有意義な場であったと感じの作戦を充分練った上で、何かに取り組んでいきたいと思ております。

にゼウエ自生ですロ

ルは現れるだろうと思っていました。ところが、その後、，ていこうと考えていました。しかし、ピジョンと信念を持

σードに変換できるはずと思い、しばらくすればそんなツー)選ま・刀から学ぶこと、そして、それを参考にプロセス改善を進め

ハリりつ部特まトウしの中上プす

DFD や DD をうま《記述してやれば、そのままソースコ

会社宅います。その際は、ぜひ皆さんの助言をいただきたいと思-小田利彦(おだとしひこ)っています。

-事長掴健司 (t っせけんじ)

会社名&所属:株式会社リコー(1)

研究開発本部

ソフトウエア研究所&システムソリューション事業本部
1 PP 事業部技術統括室

(1)

自己紹介

o

会社名&所属株式会社リコー(2)
当

かつては石油探査のための地層解析システムをLi sp でして開発することから，故障診断エキスパートシステムの開発

換は推進を実施しています。当初は 3 名のメンパーでプロセスを経て，数年前よりメトリクス，

ドメインエンジニアリンの保改善をスタートし、徐々に成果を出しながら現在、メンパ

グ，オブジェクト指向開発等に関する研究開発や社内展開ってー 6 人とともにソフトウエアの生産性と品質を向上する活に携わってきた.現在は組込みソフトウエアにおけるソ 7

互い

自己紹介

92 年度から組込み型ソフトウエア分野のプロセス改善

‑
2
2
‑

W
o
r
k
s
h
o
pR
e
p
o
r
t

S
e
a
m
a
i
lVol.ll , NO.
3

トウエア再利用の促進を Systematic に進めていく活動に

く 、ベ ストのアプロ ー チが出来るのだと思っていますが、加わっている . 世の中の技術の動きに対して，組込み型シ

未だ会社レベルのコンセンサスを得るまでに至ってません。

ステムの開発はいつまでも旧態依然でよいのかという疑問

今回の情報交換会では、多く の会社の、必ずしも組織形がある.また，職人的な集約的であるがゆえの強みも技術

態に拘らない改善活動に対する取り組み、実態 、現場の情

レ ベル が低ければ，今後は他国に容易に取 っ て代わられる熱を知る事が出来、当社が学ぶこと大でした。頂いた情報技術(生産? )分野になる恐れがあり，組込みソフトウエアに学び、私どもが成長した結果を発表させて頂きお返しがの技術インフラを確立・蓄積・パッケージ化することが重出来るようにしていかなくてはと思っています。先ずは個要と考えている.

人レベルでの情報発信から開始出来ればと思っています。

(
2) 参加した感想#白熱した議論をメールで実施するのはなかなか大変そう、え

1 ‑ 2 回/年の、課題を絞った直接の交換会も良い

社内に比較対象の少ない同業者同士の集まりは，得るもです。

のが多く貴重な機会でした 。 今後ますます，情報交換の場，ですね。

啓蒙を受け与える場として発展することを願います 。

-山村隆(やまむらたかし).0 満(とんどう

みつる)

会社名&所属:株式会社リコー
兼

会社名&所属:株式会社リコーシステムソリューション

事業本部 P-PT (P プロジェクトチーム)

画像事業統括センター

IPP 事業部兼

S . S. 事業部 P-PT

現在の仕事に就く前は、(1)自己紹介

組織変更の多い弊社で、(1)自己紹介PC 用のピジネスアプリケーションソフトの開発現場におりました。そのころから CMM

りました。現在は特に所定の部署に所属ずることなく、幾やソフトウエア工学には興味があり、勉強会などをやってもつかの事業部を取りまとめたセンターに、そしてその事業いましたが、昨年全社的な規模で、ソフトウエアの生産性

力部の 一つである IPP 事業部に兼務で所属しています 。

を向上させようという気運が高まり、現在の P プロジェク

特にソフトウエアのプロセスを専門としている訳ではあり

トチームが発足し、この仕事を始めました (P プロジェク

ませんが、 4 年 -5 年程前から組み込み型システムのソフ

トの P は Productivity の P です)。私の主な担当は PC/

トウエア品質問題の多発、評価期間の肥大化、類似ソフト

ws 向けの業務ソフトですが、プロジェクトとしては、全ウエアの繰り返し開発、各事業部での重複開発、等に注目社を対象としており、組み込みを含め、様々なソフトウエもし改善活動に参加してきました。

アを対象としています(とはいってもそれほどパワーはなじの生産性に注目したプロジェクトの発足に漕ぎ着け、そのく、絞り込まざるを得ない状態です)。

中で特に組込み型のソフトウエアの生産性は知何にしたらCMM をベースに活動していますが、改善活動の指針とし上がるのか、その実践、また知何にしたら設計の現場に新て利用しようと考えています。開発現場にいかに問題意識プロセスを抵抗少なく浸透させられるのかと格闘していまを醸成するかが現在の関心事です。

フで1 年弱前からに現在の所属とな/'¥

1 年程前にソフトウエア(2)参加した感想
思いを同じくする方たちが一堂に会し、本音で話し合え(
2)参加した感想
当社では、設計現場に近い所のプロセスや成果発表に対たという事は、大変すばらしいことだと思いました 。 今ま

して保守的であり、社外発表は限られてきました。情報交

で 、 例えば CMM についても自分の経験を元に自己流に解

換は基本的にギプ・アンド・テイクが礼儀との思いと、こ釈していた部分がありましたが、今回皆さんのご意見をうンの保守的な社内文化故に他社との交流に消極的な姿勢を採かがっている内に、そういう解釈をするのかという新鮮な開って来たと言えます。個人的には情報交換により学ぴ、お発見がたくさんありました。なかなか成果の現れにくい地

フ

互いを刺激しあうことで、つまらない遠回りをすることな味な仕事ではありますが、横の連携を強くし、相互に刺激

‑
2
3
‑

S
e
a
m
a
i
lVol.ll , NO.3w

かつ広範囲におよぶような改善活動の推進は、時間-山 Eるし結果もなかなか見えに く い 。 そういった意味で、

L>..全斗 A

WorkshopReport

しあう機会が今後も継続することを期待します。

-中村滞(なかむら

短くなった TOP の風当 たりも強いものになりがちである。

(1)

開発計画部

(今回集まられた方々は、上記のような環境下で活動

支持

C刷推進 G

進されているというのが私の認識です 。 焦らず、し か

自J

実に活動を継続されるよう期待しています 。 私も微力

ン4

あっし)

会社名&所属:富士ゼロ ッ クス株式会社

Zコi\ l ム~ 寸(1)自己紹介:80 年代の終わり頃米国 Xerox と共同で 400 人くらいら皆さんがたの仲間という認識です 。 )(2)fの Project に参加し、 Project 管理の具体な進め方を学ん-小県般(こいずみつよし)て 1

開発部門長のもとで Project 管理ならびに品質/生産性向

会社名&所属:キヤノン株式会社ソフトウエア技術

せ:上のための改善活動を推進した。結果としては、(1)だ。これをきっかけとして、

9 0 年代前半はソフトウエア

巻き込みが弱く思うような改善はできず 。

トップの

9 5 年になって

自己紹介

し ・

私どもの場合は、事業部制の中、本社部門の中に担当役員が変わり、本格的に品質/生産性向上のための改ス改善支援/技術導入/教育/人材育成などの機-菊3

善活動を推進することとなった。改善のためのモデル選定

わけですが参加される各社のみなさまは、同種

L>..圭，.l- A

から始まり、

9 5 年 1 0 月から C刷よる改善活動を開始し会社の中でどのように位置づけられているのかおのお(1)た 。 現在 Formal なLevel -2 の認定取得に向け活動推進中位置づけでどのような利点/難点があるのかなど大枠

担2

(
P
il
o
t Project による標準手順の試行中)。現在の課題を、一度全体でしたいと思います。

弊社よりご紹介できる内容という点でみると、としては、どのようにして関係者を巻き込むか。

一社内の標準化活動、 CMMへの取り組みなどの経緯(2)参加した感想
各社ともこの改善領域に対して意識の高い方々が出席さー現在取り組んでいる改善活動(プロセス標準化

:
Z
:
;
;1
:
.
L
.1

現司
コ二.

(2)

れており、活発な意見交換がされたことは成果であったと

・メトリクスの導入

思う 。 この種の改善活動に対してのアプローチはいろいろ.ハード開発プロセスから分離のためのシミュレータ

非7とあり、各社各様で大変興味深く聞くことができた。 C刷.ソフトエンジニアの育成制度

こ6

では、アセスメントを改善活動のトリガーとして位置づけなど、弊社での経験をまとめてお話するということにてLており 、 その意味で、弊社のアセスメントをベースにしたと思います。

活動内容はフォーマルなアプローチの一例として参考にな(2)参加した感想

~

-各千

各千

同じ機器組み込み分野のかたがたが集まり、各社でったのではないかと考えている。

この種の改善活動はなかなか先が見とおせない。計画を立ような取り組みがなされているかを知ることができと!

てても、他の突発的な作業が発生したりするため、なかなに有意義な時間を過ごすことができました。今回は計』年'

か計画が守れない 。 従って 、 コミットをすることが難しい。

が集まったわけですが、これだけのさまざまな分野か

まj

これは、自身のグループといった限定された範囲の改善活

まってなおかつ、問題意識を共有した密度の波い動ではなく、組織としての改善活動であるため、対象が不きたということは機器組み込み系開発というフ ニ

特定で範囲も広く、また進捗管理が非常に難しいといったは、企業の中での、 SEPG、技術支援部門というも三点に起因しているものと思われる。 SEI も自身のセルフア共通する「何か」があるのだと感じました。

分車セスメントの結果は、 Level -2 前後といっていることから

SIG-EMS の発足にあたり、弊社から継続的

社 qも推測できる。

きるかどうかの不安もありますが、まずは、そのび支

改善活動は、会社にとって非常に大事な活動として位置づを発見し、知恵を出し合えるようなコミュニティになけられているが、このような対象があまりはっきりせず、とを期待しています。

‑
2
4
‑

(石

.グ J

各4

W
o
r
k
s
h
o
pR
e
p
o
r
t

-山田潤ニ(ゃまだ

S
e
a
m
a
i
lVo l.l1, N
O
.
3

じゅんじ)

いる会社であっても、新技術の導入・技術移転となると、

会社名&所属:キヤノン株式会社ソフトウエア技術開発部

個人のスキル不足が大きな問題となり、なかなかうまくい(1)自己紹介

かないとの話が聞け、少しほっとした。当社と同じ( ?)対象業務分野:組み込み系中心

状況でもプロセス改善を行い、効果を上げ定着しつつある

自身の業務内容:社内各事業における、∞IA/∞D 導入コのである。しかし、個人のスキルアップは早急に取り組まンサルタント的な仕事分析/設計技術教育担当など

なければならない当社の問題でもある。

(
2)参加した感想-フリーデイスカッションについて皆さんのお話しを伺っている中で、自分にとっては、と各自立場をはなれ、本音( ?)の会話ができ、非常に有意ても新鮮な視点といくつも出会えて、有意義な時間を過ご義であった。どの会社でも同じような(顧客からの要求仕せました。どうもありがとうございました。今後ともよろ様の分析・表現方法、仕様が不明確なままでの見積もり、

しくお願いいたします。

不確定要素を含みながらの工程計画、メトリクスの設定・評価基準など)問題を抱え、悩み苦しんでいるという話をIl臨池実(きくちみのる)
会社名&所属:大同信号株式会社(
1)

聞け、安心した(安心している場合ではないのだが…)。

第二技術部

このようなデイスカッションを行っている中で、自分はた

自己紹介

だ C刷の要求を満足させるだけの活動(規則類の改定等)

担当業務:システムおよびソフトウエアの設計・製造を行ってきたのではないかと考えさせられ、「新たな気持(組込および DOS アプリケーション)

ちで取り組んでいかなければならないのではJ という気持

現在は、上記の製品開発業務のほか、業務改善(ソフトウ

ちにさせられた 。

エア開発プロセスの改善)活動に携わっています。

(
2)参加した感想-田淵秀之(た:ぷちひでゆき)

今回参加した情報交換会のような場に初めて参加したが、会社名&所属:山一情報システム株式会社

非常に有益な情報が得られたと感じています 。 また今後もこのような情報交換会に積極的に参加していきたいと考えています 。

システム統括部
品質保証グループ

(1)

自己紹介

現在、品質管理グループで、 1S09000 の推進を行ってい-各社発表についてます。今年 2 月に認証取得しました。品質関係の経験とし各社の実例 ( プロセス改善の過程)を聞くと、例外なく SEPGては、 1S09000 の関係で 2 年ほとe行っており、その前は、(ソフトウエア技術グループなど各社名称は違う)が専任

システム監査を l 年と汎用系基幹システムの開発を 6 年ほとして発足され、そのグループが中心となり推進し、“ 3ど行っていました。 1Sω000 、 ー システム監査という世界は、

年 -5 年で効果が現れ、定着してきた"とのことであった。

プロセス改善の世界ではどうも嫌われているようで、先のまた非常に大変であったことも実感として伝わってきた。

シンポジウムでも、 rCMM が 1Sω000 のようになっては(確認したところ、専任グループは 3 名 -6 名であり、各いけない」とのお話もありました。 1S09000 についてはい

フェーズ、重要ポイントでは、各プロジェクトのキーマン

ろいろ言われているようですが、私はプロセス改善のアプも参加していたとのことであった。また、社内の状況調査・

ローチ方法の 1 つとして、有効な手段と考えています。こ

分析段階より、社外からの専任アドパイザを置いていた会のあたりについて、情報交換会でお話したいと思っていま社もあった 。 )我が杜では、今の体制でより良い改善およす。また、情報交換会で期待していることは、高木@オム

び定着化というものが行っていけるか非常に不安になった 0

ロンさんと同様に、プロセス改善の推進者として、プロセ.グループデイスカッションについて

スをどのように定着、改善させるのかについて、皆さんと各社発表においては、効果が現れ、定着しつつあるとして議論したいと思っています。他に、品質に良〈効くプロセ・25-

WorkshopReport

S
e
a
m
a
i
lVol.ll , NO.
3ス(アクティピティかな? )についても議論したいですね。

題に対するヒントが得られないかといった期待をもっ(2) 参加した感想

加させていただきますので、よろしくお願いします。

品質を良くすために社内で何かを推進しているという同じ立場にいる多くの人々のお話が聞け、大変有意義な時を(2) 参加した感想
SEPG という立場、役割についてよく理解しないままの fったというのが正直な感想でした。しかしながら、日ものと感じています。ところが、いろいろ推進を行ってい

取組みゃ情報交換の場での皆さんの前向きで積極的なると、この信念とか信じるものが疑問に思える時がありまには大いに感動させられました。また情報交換会を終えす。また、時々、自分のやっていることが良いことなのか

後、改めてデイスカッションの内容を振り返ってみるこ t

悪いことなのか客観的に見つめたくなります。こんな時に、により、自分なりにプロセス改善の取組み方、考え方

他社の取組みゃ同じ立場にいる人を聞きたくなるのですが、してのヒントが掴めた様に感じ始めており、これをもとに今回の情報交換会+その後のメールでの議論は、私にとっ今後の活動に活かしていけるのではと考えています。そて大変有意義でした。

意味で自分なりに大きな成果が得られたと感じている

特に収穫としては、私の信念はある意味・範囲では共感しです。このような素晴らしい会に参加させて頂き、本当てもらえたことと、 IS09000 では保守的なり改善に向かな

有り難うございました。

し、 A

3

,‘

F

h

仕事は、何か信念や信じるものがなければやっていけない

っf

のけつプう

過ごすことができたと感謝しております。私は、この手の

ち t
こ 6

りすシ

-』ノ。

いかも知れないというお話しが聞けたことです。

-坂本啓司(さかもと

けいし)

会社名&所属:オムロン株式会社

まさひと)

ソーシアル事業グルー

自己紹介

私の仕事はプロセス改善以外に実際の開発プロジェク

自己紹介ており、提案・導入・保守窓口の統括、および C/S 系プロのプロジェクトをまずまず成功と言うレベルで完成さジェクトでのプロジェクト管理、品質管理、といったマネ

ことが出来ました。この成功の原因は、これまでのプ

ジメント系の作業を主に行っています。

スに関する知識が役立つたこと、

プロセス改善については、これといった取組みをしている

多くの方に助けていただいたこと、そして最後に訳ではありませんが、弊社田淵の話にあったように、ったこと、であると思っています。このプロジェクト

IS09001 の認証取得に向けての取組みに参加し、そこでの杜的な注目を受けたテーマで、本社筋からは「順調に成果を部門内の他のプロジェクトに伝播させるという活動中と報告があるがそんなに順調なのはおかしい。

を進めており、その中でプロセス改善の必要性を感じ、模ているのではないか ?J と疑われたりしたテーマでした.

索しているといったところです。今時点の関心事としては、

ところで、私が今回のワークショップの仕掛け人です。

プロジェクト活動における作業プロセスや管理プロセスのいくつかの会社の方とそのうち情報交換会をやり?しよ改善ということで、特にプロジェクトをコントロールしてといいながら長らく不義理をしていたのですが、いく上でのルールやメカニズム、それらのインフラ整備と高木君のおかげでやっと実現する運びになりました。

いったテーマにあります。

はオムロンとどちらかの会社と個別に情報交換会をとプロジェクト管理におけるグループウェア(Lo tusNotes)ていたのですが、ついでなら全部いっぺんにというこ等の管理ツールの活用と利用推進といった点で何か情報の盛大なワークショップとなりました。プロセス改善に発信が出来ればと思っておりますが、まずは先にのべた課

でに 1 0 年ほと・関わっています。

SEA で培った人脈か
ろ'
ク
つ 7

良・

会4

f
!
U
でJ
』-、

う思はのをと

1E

‑
2
6
‑

が

も受け持っており、昨年はこれまでの私の経験の中M

現在、新規事業関連の S 1 業務を担当する部署に所属し

にも化

(1)

システムソリューション第一部

ソフトウエア開発部

M

開発・生産センタ

会社名&所属:山一情報システム株式会社

(1)

設

よ J

加したこともあり、今一つ話についていけないところ-小笠原正人(おがさわら

W

S
e
a
m
a
i
lVol.ll , NO.3

WorkshopReport

振り返って見ますとこの 1 0 年間は前半の 5 年間と後半の責任範囲を明確にするということをしています。ソフトの 5 年間に別れ、さらに後半の 5 年間も踊り場に来ている

ウエアというのはなかなかやっている人以外に理解してもように思います。それぞれの 5 年間はそれなりに成果があらえず、一見訳のわからないような要求が突き付けられまったが成果が飽和状態になり新しい取り組みが求められてすが、結局企業の中でプロセス改善をするというのはマクいると言う気がしています。現在の状況変化のポイントは

ロで見ると経営課題を解決するために実行するわけで、経二つあると思っています。

営課題解決のストーリを説明できないプロセス改善は支持

一つは我々のプロセス改善の取り組み方法の限界というもしてもらえないのは当然です。そこで現在の私の最大の関のと、もう一つは経営謀題解決とプロセス改善との関係づ心事は、けをますます強く求められてきているということです。一

題解決型プロセス改善をいかにして繋いでいくかというこ

つ目の取り組み方法のことですが、我々は CMM ベースのとです。

プロセス改善を 5 年以上やっていますが、我流の限界とい(2) 参加した感想

トップダウンの経営課題とボトムアップの現場問(CMM で言うところのワークショップの進め方をグループデイスカッションに

I
n
s
ti
t
u
ti
o
n
a
li
z
a
tion が不十分でレベル 2 からのずり落

しょうか全体議論にしょうかといろいろ迷ったのですが、ちを防ぐのに必死になってしがみついていると言う感じ)

その心は「せっかく多くの方が集まっていただくのでそれ

この閉塞感を打破するためにもう少し CMM の基本的なやぞれの方々に満足してかえっていただきたい。それぞれ のり方に立ち戻った方がいいのではないかと最近思っていま

人に今回のワークショップのゴールを明確にしていただいす。つまりもう少しアセスメントペースのプロセス改善にてそれを達成して帰っていただきたい。漫然と集まったと

シフトすべきではないかと。そのためには SEPG が CMいうだけのワークショップにしたくない。そこで興味の対

M をもう一度しっかりと勉強し直すことと、SEPG 以外

象が違うかもしれないのでグループデイスカッションと言にもプロセス改善に関わる人達に幅広く CMM を勉強してうのはどうか ?J というものでした。結論は多くの参加者もらう必要があります。それには CMM の教科書の日本語の「広く各社の活動を知りたい j という意見を入れて全体化が必須。ということで、今、SEA の有志の方々と CM

会議としました。この種のワークショップとしては異例の

M 日本語化の活動をしています。(いろいろと大変です

まじめな議論がされ、おまけに全くの異例なことに時間進が・・・)

行もぴったり予定通りというものでした。参加後のみなさ

うか行き詰まり感があります。

もう一つの経営課題とのリンクですが、今年我々のとこんの感想からも満足してもらえたようです。私自身もいろろではすごい金額のソフトウエア設計費用の削減プロジェ

いろなお話が聞けて大変勉強になりました。それだけではクトが進んでいます。これはツールを入れて作業が楽にななくワークショップを機会に、ここの所もやもやしていた

ったとか設計効率が何ステップ良くなったとか計画精度がプロセス改善に対する閉塞感について考えをまとめる事が良くなったと言った話しでは全く相手にしてもらえない、出来ました。これを元に先日、経営トップへのプロセス改会社の利益がいくら上がったかという話しです。ソフトを善への取り組み体制再構築を提言し、これから具体策を検担当している人から見ると、これをソフトのプロセス改善

討するこ ・とになりました。大変いいタイミングのワークシ

でやれと言う経営トップの指示は全く無茶苦茶のものと思

ョップとなりました。

うはずですが、一般的に各社ともこんなことは良くあるとこれからは SEA-SPIN のサプグループとしての S思います。そこで今我々がもっとも力を注いでいるところ

IGEMS で継続して技術交流をしていきたいと思います。

は、ソフトウエア設計費用が決定される要素を整理し、どの部分が本当にソフトウエア設計部隊の責任範囲であるか-桓嶋敏男(いたじまを明確にし、その部分の改善成果をキチッと計測すること

会社名&所属:オムロン株式会社技術本部と、例えば営業、企画、SE といった設計部隊以外の部門

‑
2
7
‑

としお)

IT 研究所

ソフトウエアラボ

S
e
a
m
a
i
lVol.ll , NO.
3WorkshopR
e
p
o
r
t

(1)

現在は、

自己紹介

5 年間継続してきた、 S P 1 の取り組みも、 曲

過去 1 5 年以上、オムロン全社のソフトウエア生産性・がり角にきており、プロセス成熟度レベルならびにプロダ

品質の向上に取り組んできました。ライン(実際の商品開

クトの QCD 向上ができるように、打ち手が必要な時期 t

発を担当)ではなくスタッフ(本社)です。他社でも同じ思っています。まだまだ、書きたいのですが、本番に取っと思いますが、オムロンも、ソフトに関する技術及び取りておきます。

組みを統括する組織があり、そこに所属しています 。 過去、(2)参加した感想

15 年の取り組みを振り返ってみると、ターニングポイン

今回、このような形で他社との交流会に参加したのは、トが 3 つあります。

初めてですが、大変良かったと思っています。この会合で.

1) 82 年スタートの AS プロジェクト

私は、他社の取り組み状況をしることにより、自社の取 り-抜本的なソフトウエアの生産性・品質向上の取り組み

組みを客観的に評価(我々の取り組みについて、ベース(I BM の IPT をベース)

考え方は妥当かまた我々のレベルは他社に比べてどうか)

技法、ツール、 OS の 3 本柱 (UN 1X 、 C 言語、社

したいと思っていました。進め方については、最初とい内開発のリアルタイムモニタなど)一→他社に追いつことで、まじめでかつ内容にも良かったと，思っています。

き、追い趨す各社ともに特長があり、また参考となる情報をえること

各:

再t

1
1
'
とi
千土 t
U、:

をf

だe
u、

-朝J
会社 :

(1)

できました。特に、我々と同じ組み込み分野でプロセ

2) 87 年からの WS を中心とする分散開発環境

善に取り組んでいる人とフォーマル、インフォーマル-先進の技術導入

報交換ができて、大変有意義でした。

今後は、さらに突っ込んだ議論ができる場となり、そ(ITRON 、構造化技法、 CASE ツール)

-っ

はの力と

.UNIX 、 C 言語による開発が本格化での成果を持ち帰り、各社のプロセス改善に活用できる・ソフトの規模が増大 (64 KB の制限なし

うになればと考えています。よろしくお願いします 。

3) 92 年スタートの S P1 プロジェクト.CMM ペースに開発管理技術向上(ソフトの巨大化)
1)、

司有

し、 -

2 )に関しては、生産技術が中心で、品質、管理技術については、注力していなかったように思います(本音-丹羽徹(にわとおる)

SI

会社名&所属:オムロン株式会社技術本部 IT 研究所

でいえば、技術、ノウハウなどはそれほど必要ない。やることをきっちりやれば問題はないはず)。この年代は、本社の力(金と技術)が使えたことと新しい技術への取り組

(1)

自己紹介

学生時代と入社後しばらくは PC/WS 上のソフトウエア
開発に携わっておりました。根はプログラマですが、みなどができ、良い経験をさせてもらいました。

しかし、管理技術の取り組みが薄かったというつけは、

後、上流工程の設計品質向上の取組みゃ、オブジェクト

8 7 年から 9 2 年にかけて、次々と大きな P J で失敗する

向などの技術にも関わりながら、所属部署のミッショという形で現れました。ソフトの巨大化に対して、従来技もある、マネジメントを中心としたプロセス改善活動

術では、対応できなくなったのです。これに対して、経営わって来ました。

者から打ち手を考えるように指示があり、有識者も含めて(2)参加した感想

立案し取り組んだのが、 SPI-PJ でした。ですから、組込み開発を抱える他社様のプロセス改善活動事例を

プロセス改善には、かれこれ 5 年間くらい取り組んでいまれだけ一度に伺う事ができて、非常に参考になります。 2 年間は、リソースを投入して取り組んだので(パイ特に各社様ともソフトウエア開発者に対しである

た効果もあったと感じています。また、

9 5 年度からは、率の SEPG の部門(あるいは担当者)が存在したこと、た、各社が改善活動の方向性がそれぞれ異なっているこ

‑
2
8
‑

(2)

J山

が印象的でした。その中で、各社の改善活動の

OOT の導入に注力しています。

こ F

4AV 措信S P 1 という知名度もあがり、ま

ど4

る刺し

ロット事業部と共同)、て7 ;S個mail Vo l. ll N
O.
3

WorkshopReport,

曲ダと各社がおかれている事業環境が大きく影響していることを今後のプロセス改善の取り組みの参考にします。今後もこ再確認することができました。その異なる事業環境の中で、のような機会が継続して持たれることを期待します。

いかにソフトウエアの改善活動を経営が認識している課題-つと結び付けるかが成否の分かれ目になると感じました。当-店島めぐみ(からしま社の改善活動もまだまだ成熟しているわけではないので、

会社名&所属:オムロン株式会社

、久りの

+品「

いかに現状の課題を正しく認識して、だことを今後の自分への戒めとして日々の業務に役立てていきたいと考えます。どうもありがとうございました。

インダストリアル事業

グループ技術統括センタ

トップから改善活動を実践していくことが重要かを再認識しました。今回学ん

めぐみ)

(1)

技術開発センタ

自己紹介

コントローラなどの組み込み系のソフトウエア開発、 WS

上での C/S アプリのソフトウエア開発を担当して、 3 年ほど前から所属事業部門を対象とした専任の SEPG となりました。当初から、特定の組織の改善活動に(主にプロジェ-制見鼻(あさみのぼる)
会社名&所属:オムロン株式会社

グループ開発センタ

(
1
)

第一開発部

というスタッフ的な役割と、ソフトウエア設計技術の導入・ソフトウエア開発ノウハウの普及という役割をもって

自己紹介

4 年ほど前から SEPG としてソフト開発の標準化を行取り組んできました。特に、 1 年ほど前からは後者に力点ってきました。現場が困っていないとスタッフの言うことを移し、パイロットプロジェクトの開発に参加しながらテは聞いてくれないので、(困つてないから聞く必要は無い

スト技術や C/S アプリの開発プロセスの技術検証を進めてSEPG としての限界(自分の能いるところです。この成果をどのようにまとめ、これをど力の限界かもしれません)を感じていました。今は SQAのようにして他のプロジェクトへ移管していくかが、現在としてあるテーマに張り付いて、ソフト開発の品質を見ての課題です。

います。

(2)参加した感想のは当然と思いますが)るよ

クト管理的観点から)取り組んでいる SEPG を支援する SEPG

インダストリアル事業

SEPG の立場で思うのは、

ちょうど今後の自部門のプロセス改善活動の進め方に思-現場の人間は毎日の業務をこなすのに精一杯。

い悩んでいた時期で、もやもやしたものを抱えながら参加-問題や疑問を感じても、今までのやり方から抜したのですが、それを思い切るヒントになるようなものを持って帰ることができました。それと同時に、中途半端なけ出すための勇気やそのための時間が無い。

.SEPG は問題の指摘や改善の方向の検討はでパワーのかけ方や取り組み方ではプロセス改善を進めるこ

きても、金や時間を与えるスポンサーにはなれとは難しい、と改めて思いました。

ない。充分な動機付けもできない。

個別の話では、自由度をもたせたしくみ(開発手順など)-改善のトリガーや、改善のための金や時間を与が開発者の創意工夫を引き出してうまく回っている(自分なりに解釈した言葉にしているので直接の発言と違うかもえることができるはマネージャー。
マネージャをいかに動かすかが SEPG の能力の一つ。けしれませんが)というのが印象に残っています。

ども、感性のないマネージャは動かない。いつも最後のと

次回は、対象を絞った議論もやりたいです。今後とも、よころでデッドロックしてます。

ろしくお願いします。

(
2) 参加した感想
各社で様々なプロセス改善の取り組みを実施されてい-稲垣島巴(いなが曾かつみ)る状況を伺って、最近少々マンネリ気味であった私は良い

会社名&所属:オムロン株式会社

開発・生産センタ

刺激になりました。組織に合わせた取り組みは狭い範囲でしか物を見れていなかった私には非常に参考になりました。
・29・

ソーシアル事業グループ

(1)

自己紹介

ソフトウエア開発部

S
e
a
m
a
i
lVol.ll , NO.
3WorksbopR
e
p
o
r
t

W

そ

等の間)、銀行システム等の通信ソフトウエアの開発を担

次の機会がありましたら、もっと多くの方の話をお聞きしベ

当していました。その後、たいと共に、さらに的を絞り突っ込んだ話もできればとい

SEPG 担当者となり、現在にう欲張った思いを持っております。

至っています。最近はソフトウエアの開発からはすっかり遠ざかっています。

-高木徳生(たかぎやすなり)(2)参加した感想
同じ分野のソフトウエア開発に携わる人の集まりという会社名&所属:オムロン(株)ソーシアル事業グループ

ことで、それぞれの環境も比較的似ており、効率的で相互開発・生産センタに理解しやすい議論ができたと思います。また、私の想像(1)

対境即必の組役しパックグラウンドが広いですね。)

入社から約 5 年間、駅務機器(券売機、精算機、改札機

ソフトウエア開発部

自己紹介

より多くの会社で専任のプロセス改善メンバがいたこと、

弊社ソーシアル事業グループのソフトウエア開発に対すCMM を十分に理解して取り組みのベースにしている(自るプロセス改善の推進グループ (SEPG) に所属してお分の理解の不足を痛感した)こと、発表させていただいたります。

内容について、鋭いご指摘をいただけたことなど、とてもが、最近社内/外ともにプロセス改善の重要性がますます刺激になりました。今後ともよろしくお願いいたします。

ます盛んに問われ出している雰囲気を感じています。今回、

4.
4.

多くの会社の方々にご賛問いただけたことはとてもうれし ・(1-新車直樹(にいはら

さて、プロセス改善を進めている立場から、プロセス改

ソーシアル事業グループ

開発・生産センタ

善を組織の中に根づかせるためには、プロセス改善自体のソフトウエア開発部

技術移転が必要であると思っております。プロセス改善と

自己紹介

ア

た活研

(1)

3 年ほどまえからこの分野に関わり始めたのです

く感じています。

なおさ)

会社名&所属:オムロン株式会社カf

入社後 POS や CAT (クレジットカード認証端末)の開発

いっても、各現場でいろいろな手法があると思いますが、に携わり、 93 年に SEPG の専任となりました。以来 4 年間

効率的にプロセス改善を推進するやりかたは何か?そこではメトリクスや計画の充実、プロセス改善などに取り組ん

SEPG の役割とは何か?また、組み込み系会社の特撮をで現在に至っています。私共の部門では過去にもプロセス

プロセス改善推進に活かしていけないか?などということし、改善に取り組んだことから、私も昨年は特定プロジェクトに関し議論できればと思っています。

つのプロセス改善にべったりと入ったのですが、これがなか(2) 参加した感想

し本会の事務局を担当させていただいた私としては、今回

ソ

かをはっきりさせることが、今の私達の課題の一つです。

急な設定であった本会に多くの企業から多数の参加をしててコ(
2) 参加した感想

いただけたことを大変うれしく思っております。当日の議ように見えるものの、皆さんの話を聞いていると、取組み

たが)非常に熱のこもった議論ができ、とても有意義な会や抱える問題、立場、環境、仕事への思いなど実にさまざになったのではないかとおもっております。この場を借り

まな人遣の集まりであると感じました。自分自身の疑問にて皆さんにお札を申し上げたいと思います。本会で感じま対して直接的に答を得られた人もおられるかもしれません。

したのは、組み込み系ソフトという分野の企業でのプロセ

私はといいますと、皆さんの知識の深さを感じる反面、たス改善の取り組みがだいたい弊社が取り組み始めた時期とだただ自分の知識の貧弱さ(それすらないかもしれません

同じ時期に取り組まれてること、また取り組み内容は各社

が)にかなり打ちのめされています。しかし、これが今回さまざまですが課題と感じている点は同じであるというこの私の最大の収穫であると思っていますし、大変勉強になとです。つまり、プロセス改善を企業ですすめていく場合

ったことは言うまでもありません。(皆さん本当に知識のの現場や経営にどのようにその有効性を理解してもらう

・30・

ソ

ス

ム一品
定施化

論も(一部ではちょっと雰囲気が堅いという声もありまし向

色々な会社の中で、一見同じような業務に携わっている00

なかうまく行きません。なぜ今回は思うように進まないの,WorkshopR
e
p
o
r
t

S伺mail Vol.ll NO.
3

その為にプロセス改善推進者はどのように考え行動をする

上策としましては、従来から実施しておりました品質保証

べきかということが共通の課題であると思います。これにテスト

対してはこうすればいいというものはなく、その時代の環体制を構築しました(総合評価体制確立)。さらには、今境や状況、また企業の風土や事業分野などによって異なる、後のソフトウエアプロセスを構築(改善)していくにあた

即ち常にプロセス改善の取り組みプロセスも改善していくって、ソフトウエアマネージャーの意識改革が重要であり、必要があるのだということを感じました。これまで SP1N

同時、品質管理、メトリクス、開発管理、構造化分析手のワークショ ッ プにも参加させていただいておりますが、法、オブジェクト指向に代表されるソフトウエア設計手

組み込みソフト系という分野を絞った企業での同じような法・管理技術の変革などの教育・啓蒙活動を展開してきま役割の人たちとの交流はまた違った新鮮な雰囲気を感じました。

した 。 是非、今後ともこのネットワークが継続しさらに広がっていくことを期待します。

(QA テスト)とは別に設計内テストのプロセスとこれらの活動が効果的に働き、コピア等に組み込まれる
ソフトウエアの品質を大幅に向上することができました。

94 年度以後は、ファクシミリ分野、プリンタ一分野など

4
.

各発表概要

弊社を代表する商品群全体に活動範囲を広げ、現在に至っ4. 1 各社発表概要(
1)ております 。

r組込み型ソフトウエアのプロセス改普の概要.発表に関する感想(92 年度からの活動概要)J

今回は、初めての 8 社合同の情報交換会ともあって各社

発費者: (株)リコー松満健司のプロセス改善に対する取り組みを理解することから始め弊社におきましては 9 2 年後半より、コピア、マルチフ

なくては詳細な議論に発展することは難しいと思いました。

ァンクションコピア (F AX やプリンター機能が搭載されそんなこよもあって、事務局の方に、「まず、各社のプロた商品)に組み込まれるソフトウエアの開発プロセス改善

セス改善への取り組みを発表してもらい、お Eいの状況を活動を、

CMM( カーネギーメロン大学ソフトウエア工学

確認するところから始めた方がよい J と、提案させて頂き研究所によるソフトウエアプロセス成熟度モデル)に基づました。結果的に、各社の会社事情とそれに適した取り組

いて積極的に展開してまいりました。この活動を始めるきみ内容の大筋を理解することができ、非常によかったかとっかけとなったことには、商品機能が多機能に発展するに思ってます。また、自分たちが詳しく知りたい内容や詳細

したがってソフトウエアの開発量が急敢に増大し、従来のな改善ポイント、苦労話の数々について、細かく情報交換

ソフトウエア開発のスタイルでは QCD の達成が困難となをできる相手もわかりました。弊社から発表させてもらっってきたこと、弊社におきまして 9 2 年度後半に 1509

た内容は、ソフトウエアプロセス改善の全体的な取り組み

001 を受信すること、などがあげられます 。

に関する内容でしたが、多くの意見や15090質問があり、やはo1 の対応整備、並びにソフトウエア開発の QCD の精度り関心が高い内容であったかと・・・解釈させてもらって向上を目標に、ます。いろいろな会社の方々からの意見を、

9 2 年度に CMM において提案されている

l 人で聞いソフトウエアプロセス改善実施組織として 5EPGていると一見、話が発散し、ポイントが絞れないような感

(
S
o
f
t
w
a
r
eE
n
g
i
n
e
e
r
i
n
gP
r
o
c
e
s
sGroup)

想を抱きました。しかし、関心事が会社毎(担当者毎)にを発足しプロセス活動を開始しました。

異なるからだと理解しております。会社内でそれほどたく

SEPG 組織を中心に、ソフト改善 PG 、構造改革委員

さんの人材を抱えられない、ソフトウエアプロセス改善の会などの委員会活動を通じてソフトウエア開発プロセスの分野で、各企業の方々とのローカルな交流会は、プロセス

定義付け(標準化)活動や設計ツールの導入検討などを実

改善エンジニアの育成の場、自社の成果の客観的な評価の施してきました( 1 次標準化、場、プロセス改善方法の情報源の場として活用することが2 次標準化、3 次標準化・・・・)。また、大規模ソフトウエアの急場の品質向

‑
3
1
‑

重要なことだと感じてます。

S
e
a
m
a
i
lVol. ll , NO.
3WorksbopR
e
p
o
r
t

(2)

rlS09001 をベースとしたプロセス改普jr オムロンにおけるプロセス改善活動 5 年自の(3)

発費者:山一情報システム(株)田淵秀之

ターニングポイントJ

弊社では、 95 年から IS09000 をベースにしたプロセス

発表者:オムロン(練)坂本啓司

改善の検討を開始したが当時、社内では IS09000 より CM
M でやるべきだとの意見もあり、 IS0 派と CMM 派の 2 グ

ループで熱い議論を交わした。論点は、運用(手順の実行)
徹底方法、認証取得のタイミングであった。 CMM 派の意

プロセス改善活動の経過~盟・・ 金続可F......胸胴・・"・V 釜本手順の制定

見は、意識改革により運用を徹底方法させるべきであり、

V開発環舗のa章一

認証取得はレベル 2 に達成してから(当社はレベル l であV再利用の鎗途

，.，.定プロジ z クト
への a普支.

Vデザインレビューの9凶った)目指すべきであるというものに対して、 IS0 派は、

可Vヱ程附置の充実

マ開発管理指a・の滋入運用徹底には外部審査が必要であり、先ず認証取得が必要との意見であった。最終的には経営判断により IS09000 を

V開発管理指観の遠路
'
8
7

'
8
8

'89

明ヲ 1

・92

・93

・圃圃圃圃・ー.........

選択し、 97 年 2 月に認証を取得した。

.何とか仕上げる・~ r;四回目白

上記経緯の通り、ルールを作っても守られないという課-・E・...，...

題に対し IS09000 という強制力でもって対処するという方法を選択した。 IS09000 の弊害?必ず手順に準拠しなけ
ればならない。これに対して CMM は必ずしも手順通りで

開発言晒予期青蔚古l上ある必要はなくゴールを満たしてれば良いことになってい(4:る)については、手順作りそのものをプロジェクトの裁量にまがせる部分を多くする、という工夫を行い、ソフトウ
開法解

エア開発でも IS09000 を適用しやすい環境を作った。

(点ro/人月 )As~

これまでの活動効果はまだこれといって言えるものはな

C
M
I
l

いが、プロセス改善という観点からは、プロジェクトの裁しJ量にまかせた仕組みがプロジェクトの創意工夫を生み出し、
良い結果を出している。具体的には、すばらしい手順が作られたり、前向きに(同じゃるなら良い方法でやろう!と積極的に)取組むプロジェクトが多く発生するといった結果を出している。

!県?均官官|.主な質疑応答

Q:IS09000 は規定を守ることが重要であり、改善つまり規定を変更するという考えとは相反するのでは?

2)

A: 言われて見れば、その懸念はある。しかし、認証取得の目的が、純粋に品質向上であり、そのためには規定の見直し(プロセス改善)が必要であり、 IS09000 でもプ
ロセス改善は可能と考えている。審査の観点も、是正(品3)質システムの見直し)に力点を置いている。
制。，両陣。輔副。司開聞圃組問..-咽 t

‑
3
2
‑

S
e
a
m
a
i
lVol. l1, NO.3

WorkshopReport(5) r構造化手法を中心としたソフト生産性向上のどんな変化があったか.

取り組みと按術移転についてj&r プログラム自動生成ツールのデモj-取組み肉容の限界.特定の人たち (SEPG) のインタープリットの限界

発褒者ダイキン工揖(株)新田武史、友田槍.人が変わればまたーから鋭明が必要-改費量成果の歯止めが重量しい

1)当社技術開発ロードマップ-実 Iま CMM のことをあまり勉強していない.経営課題の変化

マイコンソフトの生産性、信頼性向上を目指したソフト

・約束が守れるようになるとそれは当たり前になる

開発の標準化(ダイキン版リアルタイム構造化手法)、.次 lま開発コストの問題がクローズアップ
・しかし期実コスト lま問題.鎗のペースが不明i1

自動化(ダイキン版マイコンソフト開発支援環境)に取・しかも開先コスト{玄関鍵飾門だけの悶・ではない

り組んでいる。

河町戸、?

[

2) 開発現場への技術導入の流れ
I・ 92 からの取り組みにより、製品への適用が徐々に進ん-取組み内容の限界

できている。

.Instìtutionaüzation(制度化}3)手法、ツール連用により解決された従来のソフト開発

・レベル 3 達成を会社方針としてもらう.CMM の湾勉強における問題点

・ CMM 日本信化に積鍾・加.経営課題の変化

・ソフトウエアの設計仕様書では、全体像および各機能

・プロセス成娘度の改普成果をアピール.ビジネスプロセス全体を.浬

の関連が分かり難い

開発以外の問題を明確化-手作業によるコーデイングのため、ミスが発生しがち 0

・ソフ トウエア鎗能の開発 量計湖、 FPA のXlI組み.ソフトウェア股針カの強化(
4)

・後工程重視(とにかく作って試験で確認)の為、手戻r富士ゼロックスにおける郎繊細館、t の実際J
発表者:富士ゼロックス(株)中村漕C刷の Formal Assessment を実施した企業として、その

A
s
s
e
s
s
m
e
n
t Process について具体的に説明した 。弊社がりも多，い・コードと設計仕様書の不一致が発生しがち。

4)技術移転上の苦労話-開発現場は忙しく、製品開発業務に新手法勉強の時聞

C刷コンサルタントを呼びフォーマルなアプローチを採用がつぶされる

した理由は、主に次の 3 点。

1
) 改善活動を推進する核となるメンバーの、ソフトウ
エアエンジニアリング技術に対しての知識ベースを高める必要があった 。 そのためには実績のあるモデルならびにコンサルタントを採用することが手っ取り早いと考えた。

2) TOP を説得していくには、それなりの経験を積んだ
コンサルタントの立場を有効活用すべきと考えた。

-開発期間、コストが厳しい・ソフトウエアに対する現場の認識が低い

・設計ノウハウが仕様書として残っていない.これまでのやり方へのこだわり-推進する側の製品に関する知識不足-改善が進むと現場の人間は仕事を失う?

5)今後の課題(技術的及び導入推進上課題について説明)
6) プログラム自動生成ツールの紹介

SEPG で検討した結果をコンサルタントに説明し、コンサルタ ン トから TOP に伝えてもらう 。 C刷には

P
r
o
f
e
s
s
i
o
n
a
l Judgmentという都合のいい言葉があ(モデル記述方法、生成コード等)

7)当日の質疑応答-自動生成されたコードに手を入れる必要はあるのかる。

3) 改善活動を最初からカスタマイズしていく自信が無
かった。

→ない

-なぜ汎用のツールを使わないのか。

→汎用のツールも評価したが、我々のニーズに合ったものが無かった。

‑
3
3‑

WorkshopR
e
p
o
r
t

S
e
a
m
a
i
lVol.ll , N
O
.
3

P
e
n
d
i
n
g
(6) r キヤノンにおけるソフトウエア生産性改善活動-製品領域の変化が激しくプロセスの再現性を求めてもの展開j

Pay しない

発費者:キヤノン(株)小康鼠・マクロなデータ把握と大きなプロセス分割 ( ex.

開発 v

s 評価)がまず先決-取り組み< PhaseI (1990‑1992) >分;-電気技術者からソフトウエア技術者への技術教育

4. 2 個別テーマ発表.WS(1) r ソフトウエア按術潟入について思うことーパイロッ

1 台/人体制、高級言語とリアルタイム os 導入

e;

ト PJ へのテストチーム制湧入g例をペースとして j.ウォータフォール型開発工程の導入 /C刷への接近

発費者:オムロン(練)鹿島めぐみ→開発領域の問題一非常に多彩なドメイン、工程技術が未成熟(設計/製造/テスト)、(改善推進側の)要員不足.発表内容(議論のポイント)などの理由により開発工程導入は失敗/C刷からの撤退。

現在、パイロット PJ(PC 上のアプリケーションソフト

<PhaseII (1 993‑1995) >開発)にて、開発メンバの一員となり、インクリメンタ ル・ソフトウエア技術者教育体系の確立

開発・テストチーム制など開発プロセスを改善するため の・ソフトウエアエンジニア育成制度(*)の開始

技術を検証しています。今後、検証結果を ぺ ースに技術移(申)ソフトエン ジ ニア育成制度:情報系以外を中心とした新入社員を 2 年間、ソフト技術開発部(本社組織)に配属し、体転する際に、どのように効果をアピールするか、どのよ う
な形で移転するか、を悩んでいます 。

dte系的技術者数育 /事業部からの依頼テーマによる実習を行う 。

e
R

.感想

由明

取り組みの目的・目標や期待効果が不明確とのご指摘 をその後、事業部へ再配属となる 。

day ヲ屯川口-アプリケーション製品の普及、シミュレータによるハー受けました。将来困るであろう問題として設定して取 り組
んでいることに甘えて、あいまいにしてきた部分を指摘 さ

ドとの並行開発・ソフトウエア開発の専任組織化れてしまったと思いました 。 質疑応答の中で、技術移転に<Phaseill (1 996‑) >ついては各社それぞれの考え・方法で取り組んでおられる印象を受けましたので、次回はぜひ具体的な内容(事例)

一部品化によるピルデイングプロック式開発、ネットワー

について議論させていただきたいです。

・ソフトウエアメトリクスの導入(2) r全社的なプロセス改普活動をいかに鍵観するか?

一開発状況可視化と計画精度向上、新技術導入の効果計測

本社スタッフのプロセス改普活動の.りかたについて J

発聾者:オムロン{椋)丹羽.

・今後の課題.発表内容(議論のポイント)

しさ

すただ

1)製品技術領減の激しい変化に対応することが危急の課

4九
e庁
e札は

ク製品対応

,

とも

-オブジェクト指向設計/製造技法の導入

r・ひとたび行き渡った改善活動を維持するには相当のパワー

題 (Windows/ インターネット、分散オブジェクト技
術、ソフト開発技術:分析/設計/実装/テスト/評が必要
6

・しかし経営層からは改善活動を継続させることはあま り評

価技術などへの対応)

2) 人材育成

価されない・製品開発部隊には新技術導入の情報源も時間もない

・いかに現場に改善活動を根づかせるか?

・最新の技術を取り込み使いこなすセンスを身につけた人

.感想

(
4

私の今回の発表は、当社だけの悩みのようでした 。 た見材の供給が必要

改善活動が一通り浸透した何杜かは、次に直面する自3) 標準プロセスの確立ー C刷ベースの改善はとりあえず
-34・

.発

WorkshopReport

も

S
e
a
m
a
i
lVol.ll , NO.
3

ちの問題として真剣に捉えて頂けたようです。トップと現-我々の部門では、メトリクス評価分析フィードパックやマ場に対する改善活動のバランスよくアピールしていくこと

ネージャへの技術啓蒙などの組織全体的な取り組みと共にが重要であることを認識しました。

特定プロジェクトのプロセスを分析し改善するという取り組みを行っている。

v(3) r ソフトウエア開発プロジェクトにおける開発計画の(AsIsMap) 、問題を抽出し、改善されたプロセスを定義し骨折~品質、生産性との関連性......J
発費者:オムロン(株)稲垣島巳

ソフトウエアプロジェクトの開発計画の充実度が、コスみト

重要なポイントである。

ト予測精度(見積もりコストに対する実績コスト)に影響

・ソフトウエア開発プロセスの現状を把握するためには、開を与えること、コスト予測精度がソフトウエアの生産性お

発工数や不具合数といったデータやプロダクト(ドキュメ

よび品質(製品出荷後の市場品質)との関係をデータ分析

ント、ソースコードなど)と実設計者への作業のヒヤリンにより紹介した。

グなどを通じて行うことになる。ここでの問題は、プロセ

ス粒度や現場設計者の協力をいかに引き出すかである。

・感想
紹介させていただいた内容について、分析が不十分な点を(Shoul dBeMap) 実行、評価するという改善サイクルを実行する。ここで現状をいかに把握するかというのが非常に.発表内容(議論のポイント)ツ・特定プロジェクトのプロセス改善の為には、現状を把握し・過去の経験から、このようなプロセス改善を行う場合にはに関して率直なご意見をいただけたことが最も大きな成果

以下のポイントに注意する必要があると考える。

でした。また、データ分析の着眼点についても新たな観点

1)目に見える取り組み…ゴールを明確にする。プロセスを教えていただくことができ、有意義な場となりました。

改善計画を立てる。ゴールと計画を関係者全員で了解紹介させていただいた分析では、当然と考えていることをする。アウトプットは図表で残す。など

さにる

実データを用いて証明しようとしたものであり、よく考え

2)改善サイクルは早くまわす…手をつけられる部分からると十分な分析ができていないままに、それらしい傾向が分析、改善をすすめる。時間をかければいいというも出ていればそこで結論に結び付けてしまい中途半端に終わのではない。

っていた感がありました。本当の問題は何か、その問題は

3)役割分担を明確にする…必ずしも SEPGが主導権をにぎどうすれば解決できるのかという分析の目的を達成できる

つでもうまく進むとは限らない。ベストプラクティス

もに変えていきたいと思います。今後の分析を進めるにあは現場から。

たって、たいへん参考となりました。また、今回の参加者

4)情報の整理と活用…因果関係に着目した情報整理に注の方々は組み込み機器の開発に従事しておられる点、方法

意する 0は違うと言えども大きく捉えるとほぼ同じ活動をなさって.感想いる方がほとんどであったため、仮説の意味や背景を説明

・プロセス改善活動といっても、具体的には違う取り組みのするまでもなく直感的な議論できた点は非常に効率的でしことを指していっている場合が多い。今回説明した弊社でた。最後に、次の機会にはまた何らかの紹介をさせていたの取り組みは C刷などを活用して組織的にというとのは違

だき、ぜひ皆さんのご意見を伺いたいと思います。今後とった(どちらかといえば TQC 的)取り組みである。あまり

6 よろしくお願いいたします。

このような取り組み事例を他では耳にしたことがないため、

今回こちらからの発表に対してどう思われるかを伺えるき(
4)r プロセス改普推進のポイント

っかけとして良い場であった。

ープロセス改普プロセスの分析からーJ-今回の改善ポイントについてはまだ自分でも実証できたも発褒者:オムロン(株)高木徳生のではなく半分アイデアレベルのものである。このような悩みを持っているのは自分だけかという少し不安もあった.発表内容(議論のポイント)

‑
3
5
‑

S
e
a
m
a
i
lVo l. ll , NO.
3WorkshopR
e
p
o
r
t

が、面白い分析観点とのご意見も頂けうれしかった。今後要がある」と述べられています 。 そういうことから 言うと 、より具体的なプロセス改善プロセスの改善ノウハウを掴め

我々はそれに逆らったアプローチを取っているとも言える

るよう取り組んでいこうと思っている。

わけですが、しかし私には、「人と組織に起因するソフト

ウエアプロセスの問題を、人と組織の改善によって解決す5.

ポスト・情報交換会るというプロセス改善の取り組みは、解き方自体に無理がある」のではないかと思える部分があります 。

「管理指向か按術指向かーメーリングリストの.酋からーJ
今回のワークショップでは、参加した 8 社のうち 6 社か<

‑snlp‑

ら、何らかの形で C刷を参照し、あるいは IS09000 認証取

私としては、人間が介在することによって生じるソフト 開得を契機として、組織的改善の取り組みが発表された。こ発上の問題は、人聞が介在する限り解消しないと思います

れには、プロセス改善をテーマとしたワークショップであので、人間の介在を無くす(=自動化)か、あるいは人間ったことと、最初の会合でもあり、企業としての取り組みの介在を事実上なくしてしまうための機械的支援による自の全体像の紹介が期待されていたことなど、特殊な条件も由度の排除(=標準化)を目指す技術的アプローチが重要あるのだが、それを差しヲ|いても、管理指向の改善活動がだと思っています 。

広〈行われていることを印象付けることになった。

-snlp 一

さて、このワークショップの後、メーリングリストでは、

そしてそれは、事務処理系の多種多様なドメインを対象 とさかんな議論が展開されている。テーマを要約するとすれする場合はさておき、対象分野、製品が限定できる組み込

ば、「管理指向か技術指向か」ということになるだろう 。

み系の場合にその実現の可能性が高いと思っています 。 t

その発端は以下の A 氏の発言である。

いうことで、組み込み系とそうでない場合でプロセス改善のアプローチに自ずと 違いはあると思いますが、早い話「自<A 氏>動化によって問題のあるプロセスそのものを無くしてしま‑ Snlp ‑うことがプロセス改善の最高の解」だという乱暴な見方 に

我々は rr プロセス改善 J という切り口から言うと直接そついて皆さんはどう思われるでしょうか?

の役目を担った体制があるわけではなく、プロセス改善と‑snlp‑<

いうことを念頭に置きながら、具体的には「開発手法によこの発言をきっかけとして、 C刷とは何か、 SEPG の仕事る標準化」、「自社開発ツールによる自動化」を推進して、結果としてソフト開発の効率化、ひいてはプロセスの改善とは何かという問題が、改めて議論されることになった 。

に結びつけようという取り組み j をしているわけですが、

以下、その要旨を追ってみよう。

皆さんの取り組みと順序が逆というか、切り口が違ってるように感じた点です。

<B 氏>

確かに、ハンフリーさんの本にも「技術的に高度なツール

・ソフトウエア開発には、技術導入や自動化に還元でき なや手法がソフトウエア危機に対し魔術的な効果を発揮する

い、人間そのものの問題がある。それは、本来、工学的だろう考えるのは、間違いだけでなく危険であり、プロセ

な(再現性のある)解決策のないものだ。

ス改善から注意を逸らせてしまう J と害かれていますし、.C刷の LEVEL2 へ至るプロセスは、人閉そのものの問題

坂本さん達が監訳された「ソフトウエアプロセスのトレンを、うまく工学的な枠組みに取り込んで、人間そのも のド」の中で紹介されているオムロンさんの取り組みも「初の問題を解決する糸口、つまり、説得の材料を提供し て期の成熟度の組織は、たとえば CASE ツールを用いた SAノSDいる。

技法のように高度な設計技法の推進というより、むしろ混.
C刷が改善の順序として、管理的側面を第ーにあげて い

乱プロジェクトを取り除くという初歩的なことから行う必るのは、人間そのものの問題を、最低限、改善の障害 1:

‑
3
6
‑

<1

S
e
a
m
a
i
lVo I. ll, NO.
3WorkshopReport

ならないようにクリアするためであって、技術的アプロとではない 。 C刷は、一般的に下位レベル(つまり管理ーチを否定しているわけではないのではないか。

の問題)の即A から取り組んだ方がリスクが少ないとい-人間そのものの問題をどう扱うかによって、改善活動のスタンスが変わってくる。

っていると解釈できないか。

-管理にも技術がある。計画を立てる、進捗管理するということは、過去からの研究や経験の積み重ねで得られた<C 氏>

知識(技術)である 。

閉す問自・混乱プロ ジ ェクトを取り除くという初歩的なことか ら は・ ソ フトウエア開発は 、コンピュータと人間の共同作業でじめなければならない組織は、現に混乱プロジェクトを行うものである 。 つまり、ソフトウエア開発を改善する抱えている組織にかぎられる 。 初歩的問題を抱えていな(プロセスを改善する)場合には人間とコンピュータ両い組織では、技術指向のアプローチをとることは当然だ4面から考える必要がある 。

それぞれの組織の問題分析に基づいて戦略を考えるべきだ。

この議論に明確な結論が出たわけではない。しかし、「ソ. c刷の最大のポイントは「ソフトウエ ア を人閥系の難し

フトウエアの品質、生産性を向上するという目的は同じでい問題として改善の第一歩を踏み出す べ きである」といも、改善のアプローチには、各企業の事情によってさまざっているところだと思 い ます 。 レ ベ ル 3 以上の内容は別

まなものが考えられうる」ということには、一応 の共通 コに CMM でなくてもいろいろな改善の取組みパラダイム

理解が成立しているようである。この議論は現伝も、組織はある 。

を構成する個人の問題、管理者のモラル、技術の問題へと移り、さらに続いている 。
<D 氏>

ここで議論されている問題は、一見して、機器組み込み

・目的は、ソフトウエアの生産性と品質の向上であり、そ型という世領域に限られたことではない 。 しかし、その背れを実施するにあたっては、各社の事情による。各社が景 には、共通の領域で類似の問題意識を共有しているといもっともやりやすい体制、組織の課題解決にもっとも短う 実感があり、だからこそ、活発な議論ができるのかも知

期間で到達できる策をとればよい 。

れない 。

-生産性と品質を向上するためにツールは必要である 。

しかし、一般にツールから入ることは危険である。ツール
は手段であって、導入する際に目的に置き換わっている

6.

おわりに

本情報交換会は、

7 月中旬に話が持ち上がるという急な設ようであれば、ツールをいれでも何も効果が得られない 0

定にも関わらず 2 3 名もの参加者があったということは各社・改善対象が大きく、一気に改善を行うためには組織の位

ともプロセス改善が重要でかつ現実的な取り組みになってい置付けも考えなくてはならないこともある。なんらかのることを実感させるものである。今後本会への参加メンバー

機能で改善ツール(電子化ツールに限らず改善の種といを中心に組み込み系ソフトにおけるプロセス改善活動を議論う意味)をもてることと、それを定着させるために必要する場として、本年 1 0 月から SEA-SPIN の SIG(SIG-EMS) をならば人への教育と組織の位置付け、組織への働きかけ、発足し活動を継続していくことになっている。今回の情報交も考えなくてはならないこともある。 SEPG はこれらす

換会での熱のこもった議論のように、参加者全員が何かを与べてが仕事となる。

え、得られるような議論が今後も継続して行っていけることを期待したい。

最後に、お忙しい中、本稿編集の為に多大なご協力いただ<E 氏>
・全ての組織に対し、技術指向アプローチでないとだめだとか、管理指向アプローチでないとだめだとかというこ

‑
3
7
‑

いた参加者各位に感謝する。

論文/報告/ツール展示募集

ソフトウェア・シンポジウム '98
1998 年 6 月 17 日(水) -19 日(金)於:大阪市立大学(大阪市・住吉区)

A
s
e
a
主催:

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

K!賛(予定) : 日本ソフトウェア科学会情報処理学会情報サーピス産業協会電子情報通信学会
今度で 18 回目を迎えるこのソフトウエア・シンポジウムは，さまざまな場で活躍している技術者や研究者.管理者などが一堂に会し.ソフ

トウェア技術に関する多面的な経験や知識を交流するユニークで貴重な場を，これまで徒供し続けてきました.今回は.

3 年ぶり関西エリアに戻り，元 S臥代表幹事の中野秀男先生の本拠地である大阪市立大学・学術情報総合センターを会場として，来年 6 月中旬に開催の予定です.

新しい世紀の閉幕を目前に控え，インターネットの急激な発展に伴って，コンピュータの応用領減は大きく広がっています.それは，一方で新しい市湯やビジネスの機会を創り出すとともに，他方では，社会得造や生活パラダイムの変革を促す波となって，われわれの日常に押し寄せてきつつあります.ソフトウエア技術に対する期待はますます大きしまた責任もますます重くなってきたように恩われます.
そこで，今回のシンポジウムでは共鳴による発展"を基調テーマとし，それによって，産・官・学その他さまざまなコミュニティに属する
人ぴとの問でのコミュニケーションの拡大を図り，技術やビジネスの新たな発展のきっかけを作ることを意図しています.

前回に引き続き.産業界での地道な研究・改善治動を広〈ご発表いただく場として.通常の研究論文・経験論文に加えて.事例報告のカテゴ
リも募集します.事例報告は発表を主体とするカテゴリで.OHP 原稿で審査しますので.論文を執筆する必要はありません.応募論文/報告のテーマは.ソフトウエア関連技術全般にわたります.たとえば・分析/設計技法

・ツール

・開発環境

・ネットワーク

教育

・メトリクス・プロジェクト管理

・ CSCW

品質管理

・プロセス改善・保守・標準化-人間的要因・構成管理

・新パラダイム・アーキテクチヤ

・マルチメディア

セキュリテイなど，ソフトウェアに関連する領域のテーマであれば何でも権いません.先進的な研究テーマはもちろん.開発現場での苦労・努力をまとめた
経験論文.事例報告も大歓迎です.奮ってご応募ください .
なお.論文/報告発表セッションは.今回も 2 トラック構成で，各カテゴリからそれぞれ 10 編程度を採録する予定です.シンポジウム最終日には.採録された論文の中から最優秀論文貨を選定し.表彰します(賞金 20 万円，ただし，事例報告は選考の対象になりませんL[シンポジウムスタッフ]
実行委員長:

中野秀男(大阪市立大学).田中一夫(山一情報システム)

プログラム委員長:

落水浩一郎(北陸先端科学技術大学院大学).伊藤昌夫(ニル・ソフトウェア)

プログラム委員:現在選定中です.
ローカルアレンジメント:小林修(ダダ).阪弁書式 (SRA)[応募要領1
応募論文/報告は未発表のものに限ります.他への重複投稿もど遠慮ください.論文コOHP は，下記の要領で作成し所定のカバーシートを添付したものを 7 部，ツール展示についてはカバーシートとツールの内容を紹介する資料を 3 部，所定の送付先宛に 1998 年 1 月 31 日(必青島までに鄭送にてお送りください.プログラム委員会による採否審査結果は .3 月下旬に応募者会員に通知します.

<<，研究/経験愉文日:論文にて審査します.論文の書式は自由ですが.用紙は A4 サイズに限ります.分量は 5-10 ページ程度を目安としてください.なお.論文の冒頭に必ず要旨を書いて下さい.
<<司E例報告>>:

0即原稿(紙に白黒印刷して下さい}にて審査します.発表時間は 15 分を予定していますので.OHP は 10 枚程度が目安となるでしょう.発表要旨 (A4 用紙で 1 ページ以内)を添付してください.Ol雷原稿に要点などを注記していただけ民査読者の理解が深まると思われます.

なお.曲面文はできるだけ日本蹄で執筆して下さい.英文の論文も受け付けます玖 OHP および発表は日本語に限ります.その他不明な点、は.
プログラム委員長までお問い合わせください.

主要スケジュール

1998 年 1 月 31 日

険文/報告/ツール展示応募締切

1998 年 3 月 31 日

諭文/報告採否通知1998 年 4 月 30 日

カメラレディ原稿締切"“・応募論文カバー・シートは次ページにあります

"
'
'
'
'
'
'
'
'
'
'
'
'
'

ソフトウェア技術者協会
S
o
f
t
w
a
r
eE
n
g
i
n
e
e
r
sA
s
s
o
c
i
a
t
i
o
n

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

ムなどのイベントの開催，および内外の関係諸国体との交流です.発足当初約 2∞人 にすぎなかった会員数もその後飛躍的に増加し ， 現在，北は北海道から南は沖縄まで， 700 余名を越えるメンバ ーを擁す るにいたりました. 法人賛助会
員も 30 社を数えます.支部は，東京以外に，関西横浜 ，長野 ，名古屋 ，九州，東北，広島の各地区で設立さ れてお り，
その他の地域でも設立準備をしています . 分科会は，東京，関西，名古屋で，それぞれいくつかが活動しており，その他 の支部でも，月例会やフォーラムが定期的に開催されています.

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

なお，会費は次の通りです:

個人正会員一年間 8 ，0∞円(入会金 3 ，αm 円) . 法人賛助会員一年間 l 口あたり 100，αm円(入会金なし，賛助会員会社の社員は各種イベントに正会員に準ずる割引価格で参加できます ).
代表幹事 :

坂本啓司

常任幹事 :

荒木啓二 郎高橋光裕田中 一夫玉井哲雄中野秀男深瀬弘恭

幹事 :市 川 寛伊藤昌夫大場充河村 一樹窪田芳夫熊谷章小林修桜井麻里酒匂寛
塩谷和範篠崎直 二郎新谷勝利
野日 昌満

端山毅

杉田義明武田淳男中来田秀樹布 川 博士野中哲野村行憲

平尾 一浩藤野誠治

二 木厚吉堀江進松原友夫山崎利治和田喜久男

事務局長:

岸田孝一

会計監事 :

辻淳 二

分科会世話人

環境分科会 (SIGE N V) : 田中慎 一郎渡通雄 一

吉村成弘

教育分科会 (S IGED U) :杉田義明中園順 三篠崎直二郎君島浩

ネットワーク分科会 (SIGNET) :松本理恵小林俊明人見庸

プ ロ セス分科会 (SEA- SPIN)) : 青山幹雄伊藤昌夫坂本啓司高橋光裕田中一夫増井和 也
支部世話人

関西支部:白井義美中野秀男横山博司
横浜支部:野中哲藤野晃延北係正顕
長野支部:市川 寛佐藤千明小林俊明

名古屋支部:筏井美枝子石 川 雅彦角谷裕司野呂昌満
九州 支部 : 武田淳男平尾 一浩

東北支部 : 7可村一樹布 川 博士野村行憲
広島支部 : 大場充佐藤康臣谷純 一郎
賛助会員会社: ジェーエム エ ーシステムズ東芝アドバンス ト システム

P FU 東電ソフ ト ウェア構造計菌研究所

S RA

さくらケーシー エス

サン ・ ピ Jレド印刷富士通ジャス ト シス テ ム新日鉄情報通信システム

オム ロ ンソフトウェア

カシオ計算機富士通エフ ・ア イ・ピー

SRA 東北キ ヤノン中央システム安 川 電機

アス キ ー新日本製鉄エレ クトロニクス研究所

ダイキン工業東北 コンピ ュー タ ・ サーピス

SRA 中国事務局:

日本電気ソ フトウ ェア富士電機

オム ロ ン

アイシーエ スブラザー工業プ ロ ダク ト ・ソリュ ー ション( 以上 29 社)

干 160 東京都新宿区四谷 3- 12 丸正ピル 5F

TEL:
03
‑
3
35
6
‑1
0
7
7 FAX:
03・ 33 56・ 1072

E‑
m
a
i
l:sea@ sea店.J P

SEA1996 年'" 1998 年の主なイベン卜(実績と予定)
1
9
9
6

1
9
9
7

9
/1
7~ 1
8
1
0
/
9~ 1
1

Workshopa
tMCC
I
n
t
'
lSymposiumonF
u
t
u
r
eS
o
f
t
w
a
r
eT
e
c
h
n
o
l
o
g
y'
9
6

米国・ Austin

1
0
/
2
4~ 26
1
1
1
2
8~ 3
0
1
1
1
2
9
1
2
/
1
6~ 1
7
5
1
/
2
2~ 2
1
/
2
4
2
1
2
7
3
/
1
4
4
1
2
4~ 26
5
/
1
5
6
/
1
8~ 20
6
/
2
0~ 2
1
6
/
2
1
6
/
2
4
9
/
2
5
1
0
/
16~ 1
8
1
0
/
2
7
1
0
/
2
9~ 3
1

第 10 回教育ワークショップ
第 2 回ソフトウェア・デザイン・ワークショップ

八丈島
御殿場

分散オプジェクト指向 Forum

e
c
h
n
o
l
o
g
yo
fS
o
f
t
w
a
r
e
I
n
t
'
lSymposiumonS
c
i
e
n
c
eo
fComputing& T

神戸
東京

第 13 回若手技術者ワークショップ

静岡

Forum(モバイ Jレ時代のサイノ T ーラーニング)
Forum(オブジェクト指向の新しい設計方法論)
Forum(ソフトウェア・プロセスと開発支援環境)

東京
東京

中国・西安

東京

第 9 回テクニカル・マネジメントワークショップ

隠岐Forum(これからの Software E
n
t
e
r
p
r
i
s
eManagement)

東京

ソフトウェア・シンポジウム '97

博多
博多
熊本

開発ツール&環境ワークショップ
SIGENV ワークショップ '97

Forum(ソフトウェア・アーキテクチヤ)
Forum(インターネット時代のセキュリティを考える)

東京

第 11 回教育ワークショップ

神戸
東京

東京

/1
0& 18 も)Forum(PGPN
i
g
h
t
s
:11
I
n
t
'
lSymposiumonF
u
t
u
r
eS
o
f
t
w
a
r
eT
e
c
h
n
o
l
o
g
y'
9
7

中国・毘門

*ホ*****ホ***ホ**取*判~**ホ********

1
1
/
1
2~ 1
4
11β5

1
9
9
8

1
2
/
1
9
6
/
1
7~ 1

1E
n
g
i
n
e
e
r
i
n
gMeth叫S
I
n
t
e
m
a
t
i
o
n
a
lC
o
n
f
e
r
e
n
c
eonForma
Forum(ファンクションポイント法の導入と活用)
A
s
i
a
‑
P
a
s
i
f
i
cSP別 Workshop

広島

ソフトウェア・シンポジウム '98

大阪

東京
香港

入会申し込み先〒 160 東京都新宿区四谷 3 ・ 12 丸正ビル 5F
ソフトウェア技術者協会 (TEL03 ・ 3356 ・ 1077， FAX03 ・ 3356 ・ 1072)

SEA 入会申込書(正会員:入会金 3，ωo 円，年会費 &ωo 円

97-11

氏名ふりがな:

生年月日

19 一一一年一一一月 一一一日

性別(男女)血液型 (AOBAB)

勤務先名:

所属・役職:

勤務先住所(〒

勤務先百L: 一一一一ー一一一一'一一一一一(内線一一一一 ) FAX: 一一一一 .一一一一一. 一一一一一
自宅住所〒

)

自宅 TEL:E‑mail:

資料送付先&連絡先(どちらかにチェック)口勤務先口自宅

SEA 入会申込書(賛助会員:年会費 1 口 100，00。円司何回でも可97・ 11

会社・団体名:

代表者氏名:(ふりがな:

連絡担当者:(ふりがな:

所属・役職:
住所〒(内線一一一一) FAX:一一一

TEL:
申込口数:

口

s
e
a
ソフトウェア技術者協会