qm劇
NewsletterfromSoftwareEngJneerSAssociation

vbl．14，N。mber9rlOMay，2006

目

次

SEA名古屋ミニセミナー

石川雅彦

ヨーロッパ出張日記

岸田孝一

0

玉井哲雄

1

ソフトウェアエンジニアリングの発展シナリオ

1
つ J

1
つ J

0
q

／ L U

0
ノ

／ h ︶

7
7

田中一夫

′ L U

三輪東

4

岸田孝一

3

岸田孝一

／ h ︶

スライド（フラワー・モデル再び）
Forumを終わって考えたこと

2

伊藤昌夫

′ h ︶

Forumでの討論を終わって

0

伊藤昌夫

／ L U

平鍋健児

スライド（WaterfallModelについて考える）

7

落水浩一郎

スライド（WaterfallとAgile5

スライド（WaterfallModel再考）

2

落水浩一郎

8

0

参加者アンケートの分析
編集後記

8

ソフトウェア開発管理と開発方法論の融合について

WaterfallModel再考（最高？）に参加して0

SEAForumApri1

ソフトウェア技術者協会
SoftwareEngineersAsociation

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

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

代表幹事：

田中一夫

常任幹事：

荒木啓二郎

幹事：

石川雅彦 落水浩一郎 窪田芳夫 蔵川圭′J、林修小林允 近藤康二
桜井麻里 酒匂寛 塩谷和範 篠崎直二郎 新谷勝利 新森昭宏 杉田義明
鈴木裕信 中来田秀樹 奈良隆正野中哲 野村行恵 野呂昌満 端山毅
平尾一浩 藤野誠治 松原友夫 渡連雄一

熊谷章

高橋光裕

玉井哲雄中野秀男

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

環境分科会（SIGENV）：塩谷和範 田中慎一郎 渡達雄一
教育分科会（SJGEDU）：君島浩 篠崎直二郎 杉田義明 木島博司
ネットワーク分科会（SIGNET）：人見庸 松本理恵

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

岸田孝一

杉田義明

鈴木裕信

中野秀男

支部世話人 関西支部：小林修 中野秀男 横山博司
横浜支部：野中哲 藤野晃延 北條正顕

名古屋支部：石川雅彦 角谷裕司 野呂昌満
九州支部：荒木啓二郎 武田淳男 平尾一浩
広島支部：佐藤康臣 谷純一郎
束北支部：布川博士 野村行憲
賛助会員会社：ジェーエムエーシステムズ SRA PFU
オムロンソフトウェア キヤノン 新日鉄ソリューションズ

ダイキン工業
リコー

オムロン

NTTデータ

SRA西日本

富士電機リテイルシステムズ

ヤマハ

SRA東北

オープンテクノロジーズ

エフビクス

電盛社

（以上17社）

SEAMAILVol．14，No．9−10

2006年5月31日発行編集人岸田孝一

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

東京都新宿区四谷3−12

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

印刷所市田印刷株式会社

丸正ビル5F

E−mail：Sea＠sea．or．jp〒114−0014

定価1，000円（禁無断転載）

URL：http：／／www・Sea・jp／

東京都北区田端2−3−25

ソフトウェアエンジニアリングの発展シナリオ
玉井哲雄（東京大学）
たまにSeaMaHに投稿するのが，他の目的で書いた原稿の再利用ばかりで申し訳ない．柄にもな
く表題のような未来予測的な文章を書いたのは，文部科学省科学技術政策研究所というところから，「注目科学技術領域の発展的シナリオ調査」に協力し，ソフトウェアエンジニアリング領域の今後10
年から30年の発展シナリオを自由に書いてほしい，という依頼があったからである．1年先のことも分からないのに，10年先などとんでもないし，まして30年先の予想など冗談でしかないと思ったが，それだけに勝手なことが書けるかとつい引き受けた．それが2004年9月のことだから，いまやかなり古い話ではあるが，なにしろ30年先だから，1−2年の経過はあまり関係ないともいえる．きわめて短期間で書いたので，正直なところ，内容は思いつくまま書き散らした，という感がある．

この報告書は2005年5月に刊行されていて，その概要はhttD：／／www．nisteD．qO．iD／achiev／ftx／iDn／reDO96j／idxO96j．html

で見ることができる．この執筆に際し，文章を他で利用してよいか尋ねたところ，構わないとのことだったのでここに投稿する次第である．

（1） 現状分析［ソフトウェアの需要］

ソフトウェアの需要は増大し続けている．経済産業省の特定サービス実態調査では，情報サービス

産業の内のソフトウェア開発／プログラム作成の売上高は2003年度で6兆7千億円である．しかも，
これはソフトウェア専業者の統計で，コンピュータ・メーカやコンピュータ利用企業で生産・消費される
ソフトウェアは含まれていない．たとえば組込みソフトウェアはほとんど含まれていないが，その年間開発規模は別の統計から，約2兆円といわれている．
また，現在のソフトウェア市場の顕著な動向は，開発サイクルの短期化である．新しい機能が次々と求められ，それらの開発には数週間から数ヶ月という短い期間が割り当てられる．
［社会生活に及ぼす影響力の増大］
現代の生活の周囲にはソフトウェアが満ち溢れている．携帯電話だけでなく家庭内にあるあらゆる電気製品には膨大なソフトウェアが組み込まれている．またクルマには数10個のマイコンが積まれ，そこに載せられているソフトウェアは合計すると数百万行の規模に達する．Webサービスに代表されるインターネットの職場や家庭内での利用の増大も，大量のソフトウェアの開発に依存している．

このことは，ソフトウェアの信頼性や生産性の欠陥が一般社会生活に及ぼす影響力がきわめて大きなものであることを意味している．

［ソフトウェアの生産性］

ソフトウェア技術は進歩したが，生産性の伸びはハードウェアと比べれば低い．この30年でノ、−ドウェアの伸びは50′000倍であったのに対し，ソフトウェアの伸びは3（ノ10倍程度であったといわれる．ソフトウェア開発に多くの手法とツールが使われるようになり，プロジェクト管理技術も発達したが，一方でソフトウェア開発が労働集約的であるという実態は，相変わらず続いている．とくに携帯電話市場など，激しい競争条件下にある分野では，開発量の増大はソフトウェア技術者の長時間労働で対処されている．

［日本のソフトウェア産業］

日本のソフトウェア産業は，上からと下からの技術の空洞化という問題点を抱えている．基本ソフト
ウェアはマイクロソフトに代表される米国企業の製品に押さえられ，その追随に終始せざるをえない状
況がある．一方で，定常的に生産されるソフトウェアは，中国，インドなどへの外注（アウトソーシング）への依存度が高まっている．

日本のソフトウェアは輸入が輸出を上回る入超が常態化しているが，その超過量は圧倒的である．
従来，日本語の壁で国内市場をある程度守ってきた経緯があるが，それは裏返して言えば，日本のソフトウェアの輸出を妨げ，輸出意欲を発達させない要因となっている．

［ソフトウェアエンジニアリグ技術】

ソフトウェアエンジニアリングという概念は60年代末に提唱され，70年代は構造化プログラミング，

構造化分析・設計を主導概念として発展した．80年代はプロジェクト管理，品質管理，構成管理などの管理技術にシフトする一方，プロトタイピング，レヴューなどの実践的技術が普及した．90年代はオブジェクト指向技術が脚光を浴びるとともに，並行してソフトウェアプロセスのモデル化や評価が注目された．2000年代はプロセスからアーキテクチャへの関心の回帰が見られるとともに，コンポーネント技術などオブジェクト指向を発展させた新たな技術が展開してきている．

［現状のソフトウェアの性質と課題】

現在のソフトウェアの特徴は，遍在性（どこにでもある），発展性（常に変化する），多様性（多様な版とユーザが存在する）にある．ソフトウェアエンジニアリングは伝統的に大規模複雑化への対処ということを謳い文句にしてきたが，現在はこのような遍在性，発展性，多様性にいかに対応しつつ，信頼性を高め生産性を上げるかが課題となっている．
（2）

今後10〜30年程度の発展シナリオ［ハードウェア技術の予測］
ソフトウェアが載せられるハードウェアの情況をまず見ると，現状はギガ（10の9乗）の世界である．

すなわち，CPUはギガヘルツ，メモリはギガバイト，通信速度はギガビット／秒（bps）というオーダーの性能を持つ．これが，2015年にはテラ（10の12乗），2030年にはペタ（10の15乗）の世界になるだろう．

［ソフトウェアの需要］

2

過去のコンピュータの歴史では，ハードウェアの能力・容量が飛躍的に増大するたびに，それに見合う需要があるのか，との疑問が常に出されてきた・しかし，いつの場合もそれを上回る需要が生み出される結果となった・したがって，今後10年から30年の間についても，需要が拡大し続けることはほぼ自明である．

［ソフトウェアエンジニアリングの技術】（a）大量なコンポーネントのもたらす複雑性への対処

すでに相当量のソフトウェア・コンポーネントが作られ，一部流通しているが，2015年までには膨大な量のコンポーネントが投入され使用されることになろう．そのような大量のコンポーネントから構築されるシステムは，複雑性のボトルネックに直面することになる．
コンポーネントは，さまざまな技術者，組織により，長い期間にわたり，高い頻度で追加され変更されていく・そのようなコンポーネント群から，適切なものを検索し選択する技術，それをカスタム化し組み立てる技術が必須となる．
その検索，選択，変更，組立てをすべて人手で行うことは不可能となるため，なんらかの知能化，自動化が工夫されなければならない．具体的には
1・コンポーネントに知識を付加し，エージェント化

2・ノウハウとして設計パターン，要求パターンなどの部品化と知能化
3・コンポーネントの擦りあわせの自動化
4．人とェージェントの共同が行われていくだろう・そして2015年前後にはかなりのレベルで実現していると予想される．

（b）ソフトウェア開発の自動化
ソフトウェア開発の自動化は古くから追求されてきたテーマである．上に述べたコンポーネント

技術の知能化自動化をベースに，2015年には，モデルからのソフトウェアの自動生成が実用的なレベルで実現しているだろう・ただし，生成のもととなるモデルは，システムの構造や振舞いについて，ある程度の詳細を記述したものである必要がある．
さらに，2020年ごろには，ソフトウェアに対する要求，ポリシーからソフトウェアが自動生成されることになろう・さらに2025年ごろには，問題領域で普通に使われる言葉からの自動生成が可能となろう．
（C）自律性をもち環境に適応して自己組織化を行うソフトウェアの実現
ソフトウェアは常に環境に適応することを求められる・環境にはビジネス環境やシステム環境があり，それらが変化すればソフトウェアも変わらざるをえない・また，ソフトウェアが環境間を移動す

れば，それに適応してソフトウェア自身が変化しなければならない．さらに，新しく開発されるソフ
トウェアも，独立に存在するものでなく，すでにある環境に投入される．

これらの適応変化は，これまでは基本的に人間の手でなされてきた．しかし，ソフトウェア自身が自律的に適応し，また自己組織化する技術が今後30年の間には進展するだろう．
その発展には2つの段階が予想される．

3

1．動かしながら変える（動的な変更）2010−2015年ごろ
一部は自動化されても，変化を起こす主体はあくまでも人間であるような適応技術は，今後5年から10年の内に充分に実用化されよう．しかし，これは稼動しているシステム

を停止せずに行うという意味で，見かけほど簡単ではない．従来，コンパイル時やシス

テム生成時に行われてきた，システムの変更，追加，部分削除に関する技術が，すべて実行時に移行していく．この範囲では，とくに事故，故障に際してのソフトウェアの自己診断とそれにもとづく自己修復の機能の実現が達成されよう．

2．動きながら変わる（動的な変化）2030ごろ
ソフトウェア自身が，自己と外界を知りそれに応じて自己を変化させる能力を備える．
また，利用者のフィードバックが直接ソフトウェアを変えていくようになる．この段階で初めて，ソフトウェアの自己再生産，自己組織化ができるようになったと見なせよう．

（d）検証技術
ソフトウェアの信頼性，安全性，セキュリティを保証するための検証技術は，数段のレベルの向上が要求される．とくに上記の自己適応技術と関連し，自律的に変化したソフトウェアが正しく動作することも自動的に検証できなければならない．適応技術の発展段階に応じた検証技

術の発達が予想される．
【ソフトウェアエンジニアリングの理論】

上に述べた技術を実現するためには，その基盤の理論的強化が必要である．まず，すでに理論としてはかなりの成果が挙げられているが，その実用化は今後に期待されるものがいくつかある．たとえば，関数型プログラミング，論理型プログラミングのような明快な計算モデルに基づくプログラミング技

術は，5年後か10年後に何かのきっかけで急速に普及することがありうる．また，ソフトウェアの仕様技術の一つとして，形式仕様記述言語を用いることは，分野を特定しながら徐々に普及していくだろう．

さらに，定理証明技術による自動検証は，形式仕様技術と関連しながら，実用化されていこう．
技術の項で挙げた大量なコンポーネントからなるシステムの複雑性に対処していくには，エンジニ
アリグとして個々のコンポーネントと全体のアーキテクチャを設計し管理するだけでは不十分であることが予想される．そこで，人工物であるソフトウェア・システムを，あたかも自然物のように観測，分析する手法が求められよう．そこでは，統計力学に相当するようなマクロな分析手法と，その分析結果をソフトウェアのアーキテクチャやコンポーネントのミクロレベルにフィードバックする方法論が求められる．

そのような「科学的」アプローチとして，より大きな理論的枠組みを想定するとすれば，以下のようなものが考えられよう．

1．連続時間の導入（2015年ごろ）
計算は離散的な量を対象とするため，本質的に連続量である時間の扱いがこれまで困難であった．もちろん，応答型システム，実時間システムなどは時間を意識したシステムであるが，時間を理論的に扱うにはやはり離散化して対応するのが常であったと言える．しかし，ニュートン力学は連続時間を扱い，微分積分の概念を導入することで美しい理論をうち立てることができた．ニュートンの方程式に相当する計算理論の構築が求められるゆえんである．

4

2．連続空間の導入（2030年ごろ）
地球規模の互いにリンクされたおびただしい量の計算資源は，空間連続体として捉えることが可能である．これを理論的に扱うにはマックスウェルの電磁方程式に相当する時空間の計算理論が求められよう．

【他分野に学ぶ］
今後のソフトウェアは，計算機科学のみならず他の学問分野から学び，技術として発達させていく必要があろう．

1．生物学
すでに挙げた環境適応，自己組織化という概念からして生物学から導入されたものである．さらにたとえば，免疫系（とくにウイルス攻撃への対応などのセキュリティ対策），反射系と中枢神経系と脳との役割分担（とくにロボットソフトウェア），などが有用であろう．また，すでに述べた大量なコンポーネントがネットワーク上に生息し，生成，変化，分化，消滅を続けている状況の分析には，生態学的アプローチも有効であろう．

2．文献学，考古学
ソフトウェアも一種の文書であり，それを歴史的なパースペクティブで文献学的に研究することは，
新たなソフトウェアエンジニアリグ技術を発見するためにも有効であろう．

3．社会学，文化人類学
ソフトウェアの開発組織はきわめて人間的な組織である．その分析，改善，研究には社会学や文化人類学の手法が有効であろう．
（3） 作成した発展シナリオを踏まえた日本のとるべきアクション［教育，人材育成］
アクションの第一は教育，人材育成である．とくに次のような世代の特徴を活用することが有効であ
ろう．

1．生れたときからデジタル環境に育った世代のセンスの活用
これまでのユーザインタフェースの研究と実践は，機械を使い慣れないユーザにいかに使いやすいインタフェースを提供するか，ということであった．しかし，これから就業年齢に達していく世代

は，生れたときからデジタルな機器が身の回りにふんだんにある環境に育っている．そのような世代が使用し，また開発するインタフェースはこれまでとは異なるセンスのものになるだろう．それを積極的に育てていくべきである．

また，不法アクセスなどの問題を起こす「ハッカー」は，当然若い世代が多いが，彼らの多くは高い技術と関心をもっている．その力を創造的な方向へ向かわせることが望ましい．それには，情報
倫理教育も「しちゃだめ」でなく創造の芽を育てるようなものとしなければならない．

2．熟年世代の経験と時間の活用

5

団塊世代は情報科学／工学教育を受けた最初の世代であり，またその後多くが，業務での本格的なソフトウェア開発経験を豊富に持つことになった．今後，その世代以降が次々と定年に達するが，その経験と技術を生かす方策が有用であろう．その方向は，楽しみの開発と楽しみながらの開発ということになるのではなかろうか．

3．ソフトウェア技術者の地位向上

現状では，計算機科学分野を志望する学生の数が米国でもヨーロッパでも減少傾向にあり，問題となっている．日本ではむしろかなり以前からその傾向が見られた．将来のソフトウェアの需要から考えると，この事態は深刻である．これに対処するには，ソフトウェア技術者の成功物語，ヒーローの誕生が必要である．より卑近な策としては，ソフトウェア技術者の作業環境を改善し，処遇を高めることが望ましい．

4．デザイナの役割増大
WWWページに代表されるように，コンテンツ創造とソフトウェア開発の一体化しつつある．そこ

で広い意味でのデザイナの役割が増す．そのためにソフトウェア技術に高い素養があるデザイナの育成が肝要である．
5．他分野の専門家であると同時にソフトウェア技術者であるような人材の育成
生物，物理，化学，アート，経営学などの分野でエキスパートでありながら，片手間でなくきちんとしたソフトウェアエンジニアリング教育を受けた人材がますます必要となる．

［研究開発投資］
研究開発投資にはさまざまなテーマがありうるが，以下いくつかに絞って記述する．

1．知的財産処理の仕組み
知的財産権というととかく権利保護が全面に出がちがだが，オープンソースのような自由な開発
形態を阻害しない工夫も必要である．一方で，知的財産権で保護されているコンポーネントやソフト

ウェアを正当な対価を払って簡単に使える制度，システムを構築すれば，権利者，利用者ともに便益がある．

2．基盤研究の重視
UNIX′関係データベース，オブジェクト指向技術などに見られるように，ソフトウェアの研究成果が広く普及するには10年から20年以上の年月を必要とすることが多い．そこでやはり基盤的な研究を助成することは欠かせない．研究評価は重要であるが，その評価も長い期間にわたり追跡できる体制が必要である．
3．国際交流IT技術はもっとも国際的な分野である．途上国でもパソコンを1台買えば，最先端の技術にアクセスが可能となる・そして，今日開発された技術は，明日には全世界に拡がる・したがって，欧米とだけでなく，アジア，南米など多くの地域との人的交流が，今後ともますます重要となろう．そのためには，他の文化の人々と聞達にコミュニケーションができる人材が求められる．このことは，人材育6

成のあり方にも密接に関連してくることである．また，交流を促進する資金，制度が求められる．
［産学によるソフトウェアの大規模な実験の場の構築］

ソフトウェアは元来，実験が難しい．それは，ソフトウェア開発に人的な要素が大きく，実験をコン
トロールするのが難しいためである．企業は競争的な開発に追われ，実験をする余裕がない．一方，
大学にはアイディアをスケールアップして試す場とリソースがない．たとえばセキュリティ関連の技術

は実験が有効であるが，計画，管理が難しい分野である．そこで産学が共同して大規模な実験を行えるような場を作り，そこに資金を投入して他では見られないような実験を実施すれば，新たなソフトウェアエンジニアリング手法のきちんとした評価がなされ，大きなインパクトを与えることができるだろう．

SEA名古屋ミニセミナーレポート
石川雅彦
SRA

はじめに
2006年3月1日、SEA名古屋主催ミニセミナーを開催しました。このレポートでは、ミニセミナーの内容を中心に、セミナー前後の様子も合わせて報告します。
セミナーテーマ

今回のテーマは、「企業にとってのブログ」でした。ご存知のように、プログは情報発信ツールとしてまたコミュニケーションツールとして社会の動向にインパクトを与えるものになっています。更に、個人だけでなく企業もブログによって、カスタマーとのコミュニケーションを試みようとしています。しかし、企業ブログのケースでは失敗例も報告されるようになってきました。その中で、名古屋市に本社を置く企業、ブラザー工業の社員が企業ブログを始めて1年たち、様々なメディアに紹介されていることを、SEA名古屋企画運営委員（kiui）の一人が目をつけました。そこで、メーリングリスト上で2005年末に提案を行い、忘年会、新年会の場で打合せを行い、講師や会場の調整をkiuiメンバーで分担して行い実現となりました。
開催前

講師調整に際し、提案者から講師に対して、以下のような質問事項を送りました。
（1）なぜブログを始めようと思ったか？
（2）リスクもあるので社内の説得が結構大変だったのではないかと思うがどのようにクリアしていったのか？

（3）運用体制（記事を誰が善くか、内容チェックなど）（4）はじめてからの反響（5）ブログ前後で何が変わったか予測していたことと現実との違い（狙い通りだったところ、予想外だったところ）（6）時間経過によって何が変わってきたか。
（7）今後の取り組み
続ける場合：続けるパワーもいると思うし、やめる場合：やめるタイミングもあると思う。
（8）同様なことをはじめたいと思っている企業（または担当者）に対してのアドバイス。
（9）システム的な面の質問

8

・外部ブログを利用した理由（自社で立てなかった理由）
・多くのブログの中から今のブログを選択した理由

・使用感についてよかった点、よくなかった点（不足する機能など）

セミナーはこの質問への回答を盛り込みつつ進められることになりました。

内容

講師としてグループ・マネージャーの小久保雅俊さんにお話いただきました。また、実際にブログ作成に携わっている古橋雅彦さん、松原淳さんも同席されました。（古橋さん、松原さんは講演後の質疑応答の時に回答側としてお答えいただきました。）

以下、古橋さんから提供いただいたスライドを掲載しながら、一参加者としての私がメモした記録を基に再構成した内容をご紹介します。

SEA名古屋支部様2006年3月ミニセミナー『企業にとってのブログとはブラザー社員のブログBro廿帽rhood』

2006年3月1日

ブラザー工業株式会社＄21腑｝BrotkrlnduStrは雪．Ltd A‖R一ghtsRe冥rVed

9Brdhorhoodの原点■一人の社員の想いから生まれた『Brotherhood』
ぐ企業文化 Atyourside の追求 ぐインターネットの先端研究 、間■く■￣■一■〟 ￣ ぐ「環境変化、企業への不信感の増大

r￣・アメリカではブログを使って、会社に人間味を持たせている。
￠『我々もブログを使いrAtyoursidejに一歩でも近づけるのではないか？』

プログを使ったお客様との双方向コミi土ケーション

ゆ『誠実な会社であり続ける＋ちょっとはお客様に㊦開かれた会社があってもいいんじゃないの？』
中 日分速の考え方を少しずつオープンにしていくとともに、『もっとお客様に安心していただける会社になりたい』㊨2瞞Br血亡rlnd劇rks・ud・皿Righ−SRt駕md・′：1沌・（1）ブラザーブログ「Brotherhood」の原点
innovativeなoutputを求められた。

→Atyoursideの精神でインターネットを利用し、顔の見える形で製品に投射できな

い思いや悩みを双方向コミュニケーションで伝える。さらに、・自分たちだけではなくお客様に喜んでもらえるキャンペーン

・目標は具体化せず、継続だけを目標とした

基本コンセプトJ『Brotherhood』ブログの基本コンセプトぐ

Atyourside

社員がな想いを『顔の見える形』で発信

Atyoursideに根ざした日々の活動の中で抱いている想い、

情熱、意図、悩み、疑問などを『顔の見える形』で発信していく。
㍗＼Openな双方向コミュニケーション

トラックバック等を利用し、顧客との双方向コミュニケーションを図る。

◎別品8−dkrlm血はtrkS山d．AIIR軍加SR−kn亡d，；去Ⅶ■lllll■（2）サイトの体裁：
コンセプトしては、人間味・手作り感を目指した会社のコーポレートカラーは青であるのに対して、ブログサイトはオレンジを基調にしており、対比的である。

10スタイルデザイン■『Brothorhood』スタイルデザインのこだわり
やコンセプト「人間味あふれるブログ」

や㌃暖かさ：オレンジ

ヘッダーデザイン

新商品の発売に合わせて更新
b珊

ぐ手作り似顔絵、写真、挿絵
伽伽
や

ソ凛貞

似顔絵

ぐデザイナーが、自社商品ラヘルライタ（P−tOuChPC）に付属のソフトを使って作成

肴ののmn、一｛｛■〔｛（n■一・剃u仏僧織方ム弘一」■1▲1一一ユー一一・■一・・」11、．騰−1言∴∵いく−《巾の′ヽ巾巾だゝ命や 挿絵、写真■一＼こ￣

ぐ『技術をお客様にわかりやすく伝えたい』という想いから生まれた、手作りの挿絵。
ざ＿l①2川場Br仙町lld研柑I亡SuぬA】lR喝hbR亡兄TYd

・ブログヘッダには新製品の情報を置くようにした。サイト内には、ブログ記述者やブログの登場人物の似顔絵を掲載している。この似顔絵は、製品のバンドルソフトで作成した。

ブログ内には様々な説明を挿し絵と共に行っているが、これは、文章・技術用語での説明に限界を感じた結果であり、さし絵の有効性に気づいたことが大きい。
（3）はてな選定理由：
ブログサイトははてな内に置いている。理由としては、コミュニティとしての信頼感があったから。また、イントラに検索モジュールの提供を受けていたため、という理由もある。

（4）ブログチームの構成と立ち上げまでの経緯。
・運営チームとシンプルな運営フロー・承認を得るまでに紆余曲折があった。

ブログチーム立ち上げは2004年夏が原点だった。まず、2004年8月、マネージメントク

ラスに対して社内プレゼンを行ない、インターネットで起こっている事業の理解と共有を行なづた。このプレゼンを行った結果、インターネット利用に対して積極的推進論と慎重論があった。次いで、2004年11月、「ブラザー社員のブログ」企画の説明を第2回社内プレゼンとして行なった。そして、2005年1月に企画詰めと仲間作りを行った。

我々は、ブログ運用が主業務ではない。従って、実務クラスのキーマンの理解協力を取り付けることは重要だった。また、企画に賛同、協力してくれる仲間を見出すことも重要。

『必要なのは役者とやる気』だと思った。
2005年2月初め

経営層への報告を経て、2月15日

11

ブログを開始した。

（5）数字で見るブラザー社員のブログ
2005年2月15日から活動を始めて約1年の期間の間に、記事総数は約155記事。
カテゴリ別に見ると、最も多い話題は開発で25％、次いで商品12％、営業19％、動画3％（動画は最近始めた）、想い（6％）、研究（3％）と続く。

（6）プレゼントキャンペーン

ブログの中でプレゼントキャンペーンを展開した。最初は「HL−2040を5台プレゼン
ト」という企画。応募が一週間で800名はどあった。

次のキャンペーンは「『パソコンとプリンタのある風景』の写真を記載してください

企画」を実施し、コンパクトなモノクロレーザープリンタ複合機が本領発揮する所を教えて下さい。と読者に呼びかけた。この企画の中で、「複合機の上に猫が乗ってボタンを押してしまう。」といった写真が寄せられ、話題を呼んだ。
第3回プレゼントキャンペーンは、2005年6月16日から7月6日まで3週間の期間で行った。「勉強させてください〜ブラザー社員街角レポート編」企画として、コンパクトなレーザー複合機DCP−7010プレゼントキャンペーンを行った。
応募者は約1700名に上り、企画への提案数210件と大幅に人数が増えた。人数が増えた

理由は不明。
第4回プレゼントキャンペーンは2006年1月26日から2月8日の期間で実施。

企画テーマ「勉強させてください〜ブラザー社員実験編」で、MFC−9420CNを希望者にプレゼント。応募は約1170名、企画への提案数60件に上った。

実験編の内容は、レーザー複合機の良さがわかる実験方法のアイデアで、提案を参考に動画コンテンツを作成した。
（ここで作成した動画コンテンツをデモ）。
第3回から第4回まで間があいたがこれは、新しい企画にチャレンジするために時間が必要だったため。

（7）話題性
多くのメディアに取り上げていただいた。毎日新聞、NHKニュース10、日経PC21、AERA

他。最近では、2006．1HotwiredJapanの特集

web2．0信頼の構築が重要

で4社紹介の最後にとりあげてもらった。
（8）トラックバックの中でのわれわれの気づき
多種多様な視点からの意見に触れることができた。

12

従来のコミュニケーションチャネ

ルからは得られないものだった。商品レビュー、より具体的なニーズ、スペックを調べてのコメントより深い知識や体験からの辛口コメントや提案。 自社全般に関する思い出やイメージ、ブログに対する印象など。
（9）社内の反響

以外に社内読者が多いことがわかった。「何をするつもりだろう」といった、疑心暗鬼もあったが、おおむね、以下のような良好な反響をもらった。
・信頼性の高い製品を出せというプレッシャーを感じる
・よい評価が多い。信頼性のある高い製品を出す動機づけになる・もっと自社製晶を勉強しなければと感じた。
・技術者へのインタビューに好感を持った。

（10）ブログならではの発見

Openな双方向の対話から得られた気づきがある。
・一般人の常識と業界人の常識とのギャップ

・顧客が企業に求めていたもの。
・商品に対してロイヤルティの高いユーザー層を発見できたこと。
・ブログを通して直接いただいた声を社内共有することによる活性化
今後の展開■『ブラザー社員のブログ』のこだわり￠ブログで得られた経験を基に、これからも大切にしていきたいこと

P社員の想い＆顔の見える
個性（人間味）と現場の雰囲気￠−お客様に喜んでいただけるようにお客様も我々も楽しんで『僕も企業はもっとお客様と対話していくべきだと考えています。

言うほど簡単なことではありませんが、よりお客様の方を見て、お客様視点で考えて、行動すれば、きっといいものができていく筈。
そしてそういった活動にもインターネットは使えるんじゃないか…』⑬Zt〃鵬Brot

ぐ⊂お箸警霊芸慧㌘コミュニケ●ション

二や（11）社員のブログのこだわり

ブログで得られた経験を基に、これからも大切にしていきたいことがある。
・Atyourside

お客様視点での双方向コミュニケーション

13

・社員の思い

・お客様に喜んでいただけるように・企業はお客様と対話していくべき。
・また、通常はものづくりの意図（設計者の意図）は見えないが、ブログを通して見えない意図を伝えていくことができるのではないかと考えている。
以上が講演の話です。この話の最後にブログメンバーの自己紹介がありました。
セミナーはこの後、質疑応答に進みます。
以下は一参加者としての私がメモした記録を基に再構成した内容をご紹介します。
質疑応答
1．コメント

大学教員からのコメント。大学のケーススタディに使えそうだという感想を持った。
講義の中で印象に残った点が2点ある。まず一点目。はてなの機能を有効に使っていると思った。例えば、キーワード機能、トラックバック機能など。
この一点目のコメントに対して講師の回答があった。外部のトラックバックも受け付けている。はてなのキーワード検索の範囲でしか機能しない。本当はもっと広い範囲でやりた
いがうまい仕組みがない。個人情報を集めない範囲で他があれば使ってみたい、など。
次いで同じ人から二点目のコメントとして、ブラザー工業にまつわるリクルートの思い出を披露。会場からの笑いを誘っていた。
2．質問

自社サイトの情報発信を行っている参加者からの質問として、継続のこつに関する質問があった。講師回答は以下の通り。
・組織論よりも企画への興味を社員にもってもらえることがこつ。
・職権では動かないと思う。

・社内でよく読んでくれる人が協力してくれる。
3．質問

ブログによる商業的な成功を判断しているか？
・していない。

・社内の関心事ではない（には笑いがおこった）・成果についてトップから問われたことはない。

4．質問。双方向コミュニケーションについて回答。コメントはつけていない。始める時に議論があったが、双方向コミュニケーシ
ョンにはトラックバックだけで十分だろうという結論になった。

14

5．質問
40年前にブラザータイプライターを使っていた、という人から以下の質問があった。

質問1）海外に商品展開されているので英語のブログは？
回答1）考えてない。単に英語に訳せればよいというものではないだろうと思うので。
質問2）ある企業で、次期商品を考えている人が多いが、社内の横の情報交換がないというケースに遭遇したことがある。
回答2）そのようなケースもあるだろう。（中略）一般的に、組織内コミュニケーション

についてはどこでも改善の余地は見出せるだろう。
6．質問

殻に閉じこもりがちな技術者が多い中、顧客指向であることに感心した。顧客指向を感じたきっかけは？

回答）（会場の関係者から回答）私は技術者ではないので（会場から笑い）研究テーマ
がインターネットだったが…
講師から補足回答）「Atyourside」というポリシーと、彼の研究テーマを組み合わせ

るとブログという手段が浮かび、そのブログという手段と伝え手の幸せな出会いがあり、
とてもラッキーが重なっていたように思う。

セミナー終了後
セミナーは結局、参加者 25名を数えましした。 会場のキャパシティからすれば盛況と考えてよいでしょう。また、参加者からの質問も多くあり、参加者の関心の高いセミナーでした。参加者は名古屋地域だけでなく、関西方面からの方もいらっしゃいました。また、関東圏在住の方から「平日でなければ参加できた」という意見があったと伝え聴きました。
このように関心が高かった理由はこの後に掲載するアンケートにも表れていますが、・身近にある企業の話だったこと
・インターネット上の身近なツールがテーマだったこと。

・関係者から直接話しが聞ける機会だったこと。
などがあります。
また、セミナーの翌日、Brotherhoodにこのセミナーの様子が載りました。

URLをアンケートの後に掲載します。

15

アンケート
良かった点

悪かった点

・セ討ト〃新紋が遅かった・謙市塙勒ちd（血喝ま召二

両∝虫rの帰朝切鳴、つた、力爛腐知育容寸だ′（間桶勤ヽ豆ヨ言づn寸土・講醐脚遅れ・d（癌喝力動地

払いれま臼よ終了時刻佐早め

劫が乱Ⅵ境地鴫帥

の声甜鰍Y軋・内容お抽叫やすかった

・それなりの人数わ敵、とゴてモ励和親

1査ナ「払うこと軌遅週排 誹柑：
uヨまうが札いかなと思．耽
19‥（：D−20：30（1時刑務寅十3

醐＆刃
また、1時倣、上働幌頼
しゃれ切屯出軋耽1．5卜l毒舌
すのは闇値朽監16

参考URLhttp：／／sea．forumS．gr．jp／nagoya／

SEA名古屋支部WWWページ：セミナー案内を掲載。
http：噌ub・brother・COm／pub／comn）log／Brotherhood．pdf

ブラザー社員のブログ「Brotherhood」

このブログの2006年3月2日（セミナー翌日）のブログにセミナーの様子が掲載されています。

17

ヨーロッパ出張日記
いくつかの会議をきっかけに考えたこと

岸田孝一
SRA−KTL

l．発端
ことの始まりは去年の秋にブダペストで開かれたICSM（ソフトウェア・メインテナンスに関する国際会議）だった．SoftwareEvolutionDynamicsの提唱者M・M・Lehman先生にSpecialAwardをさしあげるイベントが会議の晩餐会の席であり，たまたま故郷のブダペストに帰っておられたbs
Beladyさんが表彰のことば（昔話をまじえた長めの演説）をされた・Beladyさんにお会いするのも久しぶり（前回は数年前にかれがボストンの三菱電機研究所MERLを退職しオーステインに戻って地元のソフトウェア協会のボランティアを始められたとき）だったので，日本に帰る日の軌ホテル
近くのカフェで久しぶりにいろいろな話をした．「11月のIWFST上海に来ませんか？」とお誘いしたら即座に「OK」という返事．こうして空白だったIWfST2005の基調講演が決まった・
さて，新しい年が明けてすぐ（1月3日）にそのBeladyさんからE−mail・年末に送った会社のカレンダーのお礼．「何年か前からクリスマスカードを出すのは止めたのでmailでハッピー・ニュー●
イヤーとあって，そのあとリクエストが1つ」：
JohnvonNeumanAssociation（ハンガリー・コンピュータ協会）で定期的に世界中からいろ

いろな人を招いてフォーラムを開いている．次回は3月の予定だが，東アジアから誰か呼びたいと思うので，適当な候補者を推薦してほしい．
とのこと．日本・中国・韓国とりまぜて何人かの名前をリストアップし，何回かmailをやりとりしたのだが，結局「面倒なのでお前自身が来い」をいうことになってしまった・
予定された期日は3月22日．ちょうどその翌週の土曜日から1週間，ウィーンでETAPS P11e
EuropeanJointConferenceofTheoryandPracticeofSoftware）という会議が予定されていた・「理論と実践」とタイトルではうたっているが，FormalMethodを中心として18もの併設ワークショップが集まった会議である．
sEA幹事の野中さんから「併設のSPINワークショップに参加するので岸田さんもどうですか？
玉井先生もETAfS本会議のPCメンバーだし，セッションの座長もされるみたいですよ」という誘惑・
1週間もFomal漬けにされるのはいやなので，最初の2日間のMBT（ModelBasedTbsting）のワ

ークショップだけおつきあいすることにした．

2．ブダペスト

出発は3月19日．前回ICSM参加のさい，リムジンバスが高速上でパンクし，あやうく飛行機に乗り遅れそうになったので，今回は早めに出かけたのだが．春休みのせいか，成田空港はものすごい混雑だった．
時差調整のためウィーン西駅前のホテルに1泊．値段が安い割りに部屋は広かったがLANの設

18

備はなし．チェックインのあと，すぐに駅へ行って，ブダペスト行きの切符を買う．「払い戻し不可だ

けど安い切符があるよ」と駅員さんは親切．駅のスーパーで飲み物と夜食用のスナック類を買って，とりあえず一眠り．深夜に目がさめたのでそのままブダペストで使う発表スライドを作っていると，

WBC準決勝の日本チームの勝利の短いニュースがCNNで流れた．
翌20日午後一番のブダペスト行きEuroCity特急に乗る．2等車だがJRのグリーンより快適．乗車率40％程度．すべての座席にPC用の電源コンセントがついているのは便利だ．国境通過の前にオーストリア，通過後にハンガリーの国境警察官が回ってきてパスポート検査．そのあとハンガリーの車掌さんの検札．窓外の風景は延々と畑が続く．オーストリア側の畑には，ところどころ発電用の風車が林立していたのが印象的だった．
ブダペストのホテルは去年ICSMの時に泊まったのと同じK＋KOpera．今回は最上階の部屋なので天井が半分屋根裏風でおもしろい．ここは無料のLANでインターネット接続ができる．ホスト役のブダペスト工科大学の先生からmailが入っていたので電話．明後日の朝迎えに来てくれる時間を打ち合わせる．
翌21日の朝食後，前日買い忘れたウィーン行きの切符を買いに地下鉄で駅へ行き，そのあとホテルへ戻る途中，広場で青空市場を散策．屋台のホットワインとソーセージで昼食を済ませ，ホテ
ルへ帰ってスライドを仕上げる．途中SEAForumの参加申込みmailが何通か届いたので返信．
まさか受け取ったほうはブダペストからとは思わないだろう．時差がまだ取れず眠くなったので寝る．
目覚めたのは深夜．スライドの見直しと修正をしているうちに朝が来た．
約束の8：30にBalintDomoliki先生がタクシーで迎えにきてくれる，途中でBeladyさんを拾ってブダペスト工科大学へ．フォーラム司会役のGymothyTibor先生，もう1人のスピーカ
Lisziewitz Zsoltさん，ハンガリーにおけるSPl関連活動の中心的な役割をしているMiklos

Biros先生，その他の人たちに紹介される．耳慣れない名前ばかりなのでなかなか覚えられない‥
わたしのプレゼンのタイトルはSoftwareSituationinJapanandFarEastAsia．先方からのリクエ

ストは，東アジア（中国・韓国・日本）のソフトウェア事情をなるべく幅広くという難しい注文だったが，あまり一般的な話をしても面白くないので，自分自身のこれまでの経験にもとづいて，プロセス改善，

アウトソーシング，組み込みシステム開発，オープンソース，産学連携，などの話題について話した．
そして最後に，ソフトウェア工学と儒教哲学との思考フレームワークの類似性について，荻生狙株
や富永仲基を引用して説明したのだが，これはかなり受けた．
一昨年イタリアのピサで開かれたフォーマル・メソッド会議（FM2003）でのInvitedTblkで似たような話をしてけっこう面白がられたので，柳の下の2匹目の泥鯖を狙ったのだが．まずは成功した
ようだ．講演が終わった後Biro先生がそばへきて「わたしもソフトウェアにおけるCulturalFact。rの問題には大いに関心を持っている・明日もう一度お会いするときにわたしが書いたPaperのコ
ピーをさしあげる」といってくれた．
わたしのあとに話をしたのはし＆Markという小さなソフト会社をやっているム01tさん．いきなり

漢字で書かれた「孫子の兵法」のスライドを出して，中国でのビジネスについて清酒と語りはじめた．
どうやらGIS関係のソフトを上海市政府に売り込んでうまくビジネスを展開しているみたいだ．日本のソフト会社も人件費の格差を利用したアウトソーシングにばかり熱中していないで，中国マーケッ
トの将来性を睨んだ本格的なビジネス展開をしてもらいたいものだと感じた．
このフォーラムの詳細は，2002年9月の第1回から今年5月の第15回まで（わたしがしゃべったのは第14回）の記録がすべて，次のWebPage：
http：〟ⅣWW・inf・u−SZeged．hu／stf／rendezveny−en．phpに載っているので，興味のある方は覗いてみられるとよい．
大学のカフェテリアでみなさん一緒にランチを食べて散会．Biro先生の車にBaladyさんも同19

乗して大学キャンパスの隣にある情報産業パークを見に行く．新しい建物が立ち並び，エリクソン
やIBMなどの会社の産学協同研究所の看板が出ている．インドの弧がここにも進出してきているのには驚いた．「今朝ベルリンでの国際ミーティングから帰ったばかりで疲れたから家に帰って寝る」というBiro先生に，ドナウ川をはさんで向こう側のブダペスト経済大学（いまは農業大学を吸収合併してCorvinUS大学と改名，かれはそこの情報学部の教授）まで送ってもらい，翌日の再会を約束して別れる，大学のすぐ裏手にある有名な市場を一回りぶらついてからホテルへ帰って昼寝をする．夜はBeradyさんと食事をしながら四方山話・
翌朝Biro先生が迎えに来てくれてCorvinus大学へ．学部長さんと儀礼的なお話をしたあと，かれの研究室へ行って約束の論文コピーを貰う．

（1）CulturalEnvironmentProtectionintheInformationSociety（2）TbelmpactofNationalCulturalFactorsontheEffectivenessofProcess

ImprovementMethods（1）は，有名なホフステッドの経営人類学モデルを下敷きにして，いくつかのケーススタディの紹介をまとめたもの．（2）はCMMI／SPICEの導入と民族的価値観との関係について，アイルランド

およびデンマークの研究者と協同で行ったフィールド調査のレポート（それほど大掛かりなものではない）．両方ともなかなか興味深い．日本でも海外の開発途上国へのアウトソーシングは盛んに行われているが，その背後でこうした研究がなされているという話はあまり聞かないが，どうなっているのだろうか．
「ところで，こんな会議があるのだがこんど来てみないか？」とかれが見せてくれたのはEuro SPI
c。n鮎renceのパンフレットだった．ホテルへ帰ったあと，ネットで調べてみると1944年から毎年開かれている会議だった．昨年は11月にブダペストで開催されてBiro先生はローカル・アレンジメントを担当されたとのこと．今年の会議は10月中旬にフィンランドのヨエンスウ市での開催が予定されている．詳しい案内は次のWtbに：http：〟2006．eurospi・net／

フィンランドには何年か前の夏にオウル市で開かれたPSOCOS会議に行った経験しかない・

あの時は蚊の大群に悩まされた．会議場の大学からホテルへ帰る途中の道に何本も蚊柱が立ち並び，そこを通り抜けるためにJacky高橋さんと2人でタバコを2本ずつふかし，ふだんはタバコ
キライな鳥居宏次先生がその煙幕に隠れるようにして早足で駆け抜けたというおかしな思い出がある．ヨエンスウというところ（大学町らしい）には行ったことがないし，いささか心惹かれるが，10月のフィンランドはもうかなり寒いだろう．

ネットサーフをすると，今年ヨーロッパで行われるソフトウェア・プロセス関連の国際会議はほかに，
SPICE2006（5／3−5，ルクセンブルグ）とEuropeanSEPG2006（6／12−15，アムステルダム）の2つが予定されているのだが，両方ともタイトルが示すようにSPICEやCMMI一辺倒の集まりなのであまり魅力的ではないように感じられる．
それにくらべるとEuorSPIのほうはWebに載っている過去の会議のProceedingsを見ても，かなり幅広い話題をカバーしているようだ．Biro先生の話では，近々ヨーロッパではアメリカの
cMU−SElの動きに対抗してISO／IEC15504（SPICE）のAきSeSSOrCertificationを本格的に始めるようだ．

学部長先生を交えてしばらくお話をしたあと，学生たちや大学のスタッフで混雑している近くのイ
タリアン・カフェで軽い昼食を取り，大学本館の建物に案内してもらう．正面玄関を入ったところに大きなホールがあり，左側の壁の前に，読書しているカール・マルクスの彫像が置かれている・共産主義政権が崩壊した後，関係する彫像はすべて取り払われたのだが，「ここは経済大学なのだ

20からマルクスをはずすわけには行かなかった」とのこと．イギリスのチャールズ皇太子がここを訪問しスピーチをしたとき，ふつうは右側の壁に演壇を設けるのだが，「自分と同じ名前の有名人と並んで話したい」（ドイツ語のカールは英語のチャールズ）という強い要望で，そのときだけマルクスの隣に演壇を作ったのだそうだ．
「どこか観光案内をしてあげよう」というBiro先生の申し出に甘えて，近くにある民族博物館へ行
き，10世紀以降現代までのハンガリーの歴史展示を，先生の解説つきで見てまわった．トルコ，オーストリア，ロシアという大国の狭間でもみくちゃにされた小国ハンガリーの苦難の歴史を，メーカや大ユーザそして政府機関にはさまれて苦労してきた独立ソフトハウスのこれまでと引き比べて，いささか感慨深いものがあった．博物館の最後の1室は，フォン・ノイマンをはじめとするハンガリー生まれの著名な科学者たち16人の写真と業績の展示．そのうち8人がノーベル賞受賞．「え，この人もハンガリー人だったの！」という驚きの連続．
ホテルへ帰って一休みしたあと，夕食は今日・明日の2日間で行われているドイツ・ハンガリー協同研究プロジェクト・ミーティングの晩餐会に招待される．迎えに来てくれたBeladyさんとタクシー

で市のブダ側（この街はブダとペストの2つに分かれている．わたしのホテルはペスト側）にドナウ川を渡り，王宮の下にあるレストランへ．ドイツ・サイドの研究代表者は，5月のICSE2006in上海のプログラム委員長であるDieter Rombach先生．お互いに「どうしてあなたがここにいるの？」と挨拶を交わす．かれらのプロジェクトは，やはりBeladyさんの「外交的努力」によってまとめられたものらしい．「金の鹿」という店の名前にちなんで鹿肉のステーキを食べ，上海での再会を約束して別れる．
3．ウィーン

3月24日，金曜日．遅い朝食を食べたあと，タクシーで駅へ．今度の車両はコンパートメント式だ
ったので，Smokingの席がある．6人用のコンパートメントに1人で座っていたら，あとからノ、ンガリーの若者（たぶん学生さん）がひとり入ってきて，タバコを1本せびられた．
ウィーン到着は予定通り．ホテルはミュージアム・クオーター裏のK＋K Maria Theresia．ここは，

9．11事件に遭遇したFSE＆ESEC2001のとき，そして2年前のCHI2004のときにも泊まった馴染

みの宿．西駅から地下鉄でフォルクス劇場前まで行き，通いなれた坂道を登ってチェックイン．今

度もまた最上階の半分屋根裏のような部屋．それはいいのだが，部屋に湯沸しがないことを発見．
たしか以前に泊まったときはあったはずだがと思いつつ，近くの大規模家庭用品ストアへ行って，
TEEARの湯沸しポットを見つけて買った，東京の家で使っているものより新しいモデル．値段は3，000円だからかなり割安．しかし電圧が違うので帰国したら変圧器を手に入れなければならない．
さっそく沸かしたコーヒーとスナックで昼食をすませ、インターネットに接続してたまっていたmailの処理．香港のスポーツTVの録画をネット上に見つけて，WBC決勝戦での川崎選手のスライディング・ホームインのシーンを見る‥

夕方，野中さん到着．かれはウィーンは初めてだというので，さっそく市内散歩に出る．オイゲン
皇太子の厩を改造したミュージアム・クオーターを通り抜け，マリア・テレジア女帝の彫像に敬意を表し，王宮からステファン教会，ザッハ・ホテル，オペラハウスあたりを歩く．夕食はどうしようかとしばらく迷ったあげく，ベルべデーレ宮殿正門脇の有名なビアホールSalmBrauまで歩くことにした．

暗い夜道でちょっと迷った末にたどりつく．満員だったがなんとか相席で座ることができた．ご当地

初めての野中さんは，当然ウィーナー・シュニッツェル，わたしは白ソーセージと白ビール．
翌25

日（土曜日）はワークショップの初日．会場のウィーン工科大学へはこの前FSFに通った

21

のと同じ道をぶらぶら歩いてゆく．ところが，ここが会場だろうとわたしが思い込んでいた建物には，

まったく会議などやっている雰囲気がない．土曜日なので学生さんたちの姿も見当たらず，しばらく

うろうろした後，受付のおじさんに訊くと，会場はどうやら少し離れた別の建物らしいことがわかり，
小雨の中をそちらへ向かう．

会場の情報科学の建物は2つに分かれていて，参加登録受付は新館の1階．受付は専門の会社に委託してあって，きわめてスムースである．ワークショップ1つしか申し込んでいないのに，フル参加の人たちと同じ立派なディバッグをくれる．われわれが参加するBMTⅥbrkshopは旧館2階の階段教室なので，雨の中を移動．これがまた旧世紀の立派な建物でエレベータはなし．幅広い
階段を上って会場へ．いつも参加する会議とは違うコミュニティなので知った顔がいない．1人だけ
中国の若い研究者に会っただけ．こういうミーティングは気楽でよい．
オープニング・セッションの講演者はHarry Robinsonさん．BellI．absからMicrosoft，そして現

在はG00deという経歴の持ち主．風貌はちょっとふとった陽気なカリフォルニア人という感じ．講演のタイトルぼ，Model−BasedTbstingforMasses（一般大衆のためのMBT）．そのプレゼンテーション・スライドは次のPage：httD：〟react．cs．umi−Sb．de／mbt2006／で見ることができるが，以下にリストアップした見出しからも想像されるように，きわめて実際的な内容で興味深かった：
IstheIndustryReadyforModel−BasedTbsting？
TheStateof¶さStingTbday

ButFormalityIntimidates

托stersAndBigModelIntimidates¶詣terS
And．．．

Modelingishard．

AGreatlndustrialTbclm0logyshouldbe…
Cheap，Easytoapply，andMeasurable．

FactorsinFavorofMBT：TimeandMachines

WhatsHappeningNow？

WhereCouldModels¶lketheIndustry？

MBTisEnteringtheMainstream
WhatNeedstoHappen？
HowCanYouHelp？

Robinsonさんは，テスティング一般およびMBTについて，次の2つのWtb Pageも運営されている．興味のある方はぜひ覗かれるとよい：
httD：／／www．EeOCities．com／model based testind
httD：／／www．だeOCities．comnlarrV rObinSon testinE／

コーヒー・ブレイクの場所は新館1階のロビーなので，休憩時間にはまた階段を下りて戻らなければならない．インターネット接続用のPCは，そのロビーと旧館3階の部屋に設置されていた．日本
語のニュースは見られるが，入力のローマ字・カナ漢字変換はできない．午前中の次のセッションの発表を2篇聴いたが，内容はあまり感心しなかった．1つはドイツ，もう1つはオランダの，いずれも組込みシステム開発の話だった．
昼食は，大学の裏手にあるナッシュ市場のファースト・シーフッドのチェーン・レストランNord See（北海）．そのあと，すぐ近くにあるセセッションの地下室でクリムトの壁画「ベートーベン・フリーズ」を

22

観る．
そのあとワークショップに戻るという野中さんと別れ，わたしは建築美術アカデミーのギャラリーへ
ここではCHI会議のとき，ディジタル・バウハウスの構築を目指したEU協同プロジェクト「アトリエ」の成果発表レセプションに招かれた建物である．あのときは夜だったのでギャラリーは閉まっていた．
以前から念願だったヒエロニムス・ボッシュの「最後の審判」の実物をようやく目にする．思ったほど大きな画面ではない．宗教的な寓意はともかくとして，化け物絵としてのできばえは，葛飾北斎の作品群に匹敵すると感じた．
夕方まで少し時間があったのでどこかでウィンナコーヒーでも飲もうかと思ったが，土曜日のせい
か，中心街は大混雑．ホテルへ戻ってmailの処理．夕食は，あまり遠出したくなかったので，ホテルの裏手にある上品なカフェLUXへ．やたら背の高いウェイトレスのサービスで，白そして赤のワ

イン．野中さんはウサギの腰肉．わたしは血のソーセージ．夜中にサマータイムがはじまるというので，寝る前に時計の時刻を1時間進める．
26日，日曜日．ワークショップの2日目．昨日とは違う道を歩き，マリアヒルファー通りの教会で日

曜礼拝の光景をちょっと覗いてから大学へ向かう．途中の商店や食堂は，市場も含めてほとんど閉まっている．最初の招待講演はIBMイスラエル研究所のAlanHartmanさん．，yrbnYearsofMBT
rASoberEvaluation．

というタイトルで，要するに失敗続きだったという経験談．ほとんど得るところがなかった．

ランチタイム．大学近くの食堂はほとんどお休みなので，地下鉄駅近くの公園に向かう．食事の前に，そばのカール教会に入ってみると，内部の修復工事用のエレベータで円天井のすぐ下まで上がれるようになっている．それに乗って天井のすぐ下まで行き，フレスコ画を間近に鑑賞して，さらに危なっかしい階段でドームの上まで行くことができる．高所恐怖症でもう足がすくんでいる野中さんをそこに残して，天辺まで上って街を一望した．
教会を出て，周辺で唯一開いていた公園のカフェで昼食．午後のプログラムはあまり面白くなさそうだったので，ホテルへ帰ってまたmailの処理．4月3日のSEAForumの参加申し込みが何通か．そしてICSE2006in上海のポスター・セッションについての問い合わせ．まだ2ケ月先の話なのだからそんなにあせらなくてもいいと思うのだが，やはりプレゼンターの方々は気になるのだろう．しかし，上海サイドの準備がもたもたしているので仕方がない．展示担当の委員にとりあえず質問を転送しておく．NTTデータの山本修一郎さん宛てにmailで，5月末に予定しているSEA
Fomm（システム・トラブル）にスピーカーをお願いする・

夕方，野中さんの帰りが遅かったのでどうしたのかと思ったら，市電でリングを一周してきたとのこと．「今日の最後の発表が岸田さん好みの哲学的な話でしたよ」という．それは，わたしもちょっと気になっていた論文で，中国での国際会議でいつもお会いしているUNU／ⅠIST（マカオにある国連大学ソフトウェア研究所）のChris Gerogeさんが共著者に名前を出していた．かれが会場にきていないようだったので発表を聴かずに失礼したのだが，残念なことをした．あとで論文をよく読んでみようということで，とりあえず街に出る．
映画フアンの野中さんの「ぜひに」という希望に応えて，地下鉄でプラッター公園の観覧車に乗りに行く．映画「第三の男」でオーソン・ウェルズとジョセフ・コットンとの有名な対話シーンに使われた

旧世紀の観覧車である．時代物だけに，現代の優雅なデザインとは違って，小ぶりの鉄道客車のような箱をぶらさげた不恰好なもの．スピードもときどき止まったりして，のんびりしている．

第2次大戦後のイギリス映画といえば，キャロル・リードとデイヴィッド・リーンの2人が代表的な監督だった．デイヴィッド・リーンは，カラー映画になってから「旅情」や「戦場に架ける橋」，そして「アラビアのロレンス」など，いくつもの話題作を撮っているが，わたしが熱心に洋画を観ていた1950

23

年代前半から半ばにかけては，圧倒的にキャロル・リードのほうが油がのっていたように思う．日本
での公開の順序でいうと，「邪魔者は殺せ」（1951），「第三の男」（1952），「落ちた偶像」（1953），「文化果つるところ」（1953）といった具合．わたしはその中では，ジョセフ・コンラッドの小説

OftheIslands0。t。aSt（島々の除け者）を題材にした4番目の映画が一番気に入っていた．原作をわざわ

ざ丸善で買って読んだりした・デイヴィッド・リーンの当時の作品としては，後の「旅情」の原型ともいうべき「逢引き」が有名だが，日本公開は1948年・まだ子どもだったわたしには少し早すぎた．飛行機マニアのはしくれとして1953年公開の「超音ジェット機」は封切りで観たが，老優ラルフ・リチャ
ードソンの名演技以外，ほとんど記憶に残っていない．
「第三の男」は，キャロル・リードの他のいくつかの映画と同じく，グレアム・グリーンの小説を下敷きにしている・いい映画だったとは思うが，第2次大戦直後の社会状況の表現としては，ヴォルフガ
ング・ボルヒェルト（戸口の外で）やハインリッヒ・ベル（アダムよお前はどこにいた），あるいはハンス・エリッヒ・ノサック（死神とのインタビュー）などの小説（アメリカ兵捕虜としてドレスデンの収容所にいたカート・ヴォネガットの小説「母なる夜」を加えてもよい）のほうが，空襲で廃墟と化した東京の風景とオーバーラップして，はるかに強烈な印象をわたしの心に与えた．しかし一般には，こうした戦後

ドイツ文学はほとんど関心を持たれなかったようだ・ウィーンの夜景を眼下に眺めながら，あらためて，戦後60年の時間の経過を感じる．
帰りは地上にしようと，ちょうどやってきた5番の市街電車に飛び乗ると，電車は中心街の外を大回りして，結局，西駅まで戻ってしまった．駅のコンビニで飲み物とおつまみを買い，地下鉄で一旦ホテルへ・夕食はホテル前の市電通りを少し歩いて見つけた「七つ星」という名前の地ビール・レス
トラン・看板通り7種類のビールがある・今夜もまたソーセージをつまみにビールを飲み，部屋に戻ったのは10時過ぎ・玉井先生がすでにチェックインされていたので，ブダペストで買ってきた
Tbkaiワインを開けて乾杯．

翌27日（月曜日）からETAfSの本会議が始まったのだが，わたしは無関係．野中さんも次のSPINWbrkshopまで暇だというので，2人とも休息日．上海の杉田義明さんからICSEに参加する人たちのための割安ホテルの交渉がまとまったというmailが届いたので，日本からの参加予定

者の人たちに案内を発信し，2人でシェーンブルン宮殿へ出かける．急に天候が回復して，散策にはもってこいの陽気になった・宮殿内部の部屋を一回りして庭園へ．後に「ルードウイヒ／神々の黄昏」や「暗殺者のメロディ」で演技派女優に成長したロミ一・シュナイダーがまだカワイコちゃんだったころに主演した映画「プリンセス・シシー」を思い出したのだが，野中さんは観ていないらしい（ひとつの世代間ギャップ）・ゲオルグ・トラークルやシュテフアン・ゲオルグがこの庭園を舞台にした美

しい拝情詩を何貨か書いているのだが，これもまた，ドイツ文学愛好家以外にはほとんど縁のない話である．
気温は急上昇して暑いくらいなのだが，庭園のはずれの池にはまだ氷が張っている．その先の丘に登り，カフェで休息・帰りはまた適当な市電に飛び乗り，途中で地下鉄に乗り換えて中心街へ．
もうドイツ風の料理には飽きたのでイタリアン・カフェの路上のテーブルでスパゲティと白ワインのランチ・月曜日なのでほとんどの美術館や博物館は閉館だが，カフェ近くのユダヤ博物館が開いていたので入り，これまで名前を知らなかった2人のユダヤ人音楽家についての展示を見て感心する．
そのあと，マリア・テレジアほか歴代のオーストリア帝国皇帝たちの棺が並べられた地下室へ，こういう場所を観光施設にする神経はどうもよくわからないが，大げさな彫刻群で飾られた巨大な鋼鉄の棺の列が歴史の重みを感じさせることはたしかである．
まだ夕方まで時間があったので，有名なチョコレート・ショップDemerへ．店の奥のテーブルに座って，ガラス越しに菓子職人さんたちの仕事振りを眺めながらコーヒーを飲んで，1日の散策終24

了．夕食は，会議を終えて帰ってこられた玉井先生，そして東京農工大の吉澤康文先生と一緒に
夕食．ホテル近くのレストランをいくつか見てまわったが，静かに話ができるところがよいだろうということで，また一昨日行ったLUXへ．ウェイトレスは同じ背高お姐さん．吉澤先生が日立時代に手がけておられたコンパイラのテストの話などで楽しい時間を過ごす．

28日，火曜日．ワークショップの中休みを利用してブダペストへ1泊旅行にでかけるという野中さんを見送ったあと，ゆっくりホテルをチェックアウトして，地下鉄で中央駅へ．そこで荷物をチェックイ

ンし，空港行きの快速電車に乗る．春休みを利用したツアー客が多いためか，フライトはほぼ満席
機内食のサービスが終わったあと，MBTWbrkshopの論文集を開いて，一昨日の野中さんの報告
で宿題になっていた次のPaperを読むことにする：
BernhardK，AichemigandChrisGeorge：
WhenSpecification−BasedTbstingFails，

第1著者のAichemigさんは，オーストリアのグラーツ工科大学の先生で，いまはUNUnlSTにVisiting Researcherとして赴任している人らしい．「仕様にもとづくテスティングが失敗するとき」というタイトルは別に何の変哲もない．思わず，ローレンス・ブロックの傑作ミステリ小説
Sacred GinmillCloses

when the（邦訳書名は「聖なる酒場の挽歌」，二見文庫）を思い出してしまった．しかし，Abstractには，次に訳したように，かなり過激な文章が書いてある：

AmandoHaebererは，科学哲学の成果をソフトウェア・テスティングに翻訳する上で大きな貢献をなしとげた．かれは，理論や仮説から導かれる観測結果にもとづいて理論の正しさを検証する標準的な方法論の限界がソフトウェア・テスティングの場合にも存在するということを示したのである．こうしてかれは，テスト・ケースの生成に関するGaudelの古典的アプローチを強く批判し，それに代わるものとして，Glymorのブートストラップ・アプローチにもとづく方法論を提示した．しかしながら，その後，この提案をめぐって当然沸き起こるものと予想された議論は起こらなかった．Model−Basedltstingのアプローチが，かれの批判した方法にしたがっていることからすれば，これは，まったく奇妙な現象だといわざるを得な
い．この論文は，Haebererの発見を新しい視点から見直すことによって，議論を再開させる

ことを目指す．
これでは，発表のあとのQ＆Aが侃々諾々の状況になったことは想像に難くない．故Haeberer先生の名前は，何年か前にZhouCaochen先生に続いてUNU／IISTの3代目の所長に就任され，しかしすぐに亡くなられたということだけしか知らなかった．Re氏renceを見ると，ここでいわれている論文は2001年のICSEinTbrontoで発表されたものだ．わたしがACMSIGSOFrからDistinguishedServiceAWardを貰ったときの会議である．日本に帰ったらすぐProceedingsを調べなければと思う．

また，Haeberer先生に批判された古典的テスト・ケース生成アプローチというのは，lCSEのプログ
ラム委員会で何度か顔をあわせたことのあるMarie−ClaudeGaudel女史の有名な論文
Can Be Formal，Tbo

Software，Tbo

を指しているようだ．これも，Lee Osterweilさんの恥stingSoftware ProcessIsをもじったタイトルだという程度の興味しか持っていなかったので，探し出して内容をよく読んでみなければいけない．
さて，さらに本文のIntroductionに読み進むとRudolfCamapやCarlPopperの名前が登場してくる．理論を現実に照らしてその検証が可能かどうかという問題を論じるのだから，当然といえば当然25

だが，これはちょっと困ったことになった．大学時代に詩の同人雑誌を一緒にやっていた友人が科

学史・科学哲学の専攻で，故・大森荘蔵先生に師事していた．その関係で十数年前に先生に会社で講演をお願いし，その夜新宿で飲み明かしたとき（大森先生は知る人ぞ知る大酒豪），弟子入りを希望したのだが，「きみがもう少し若ければOKと引き受けてもよいけれど，もう世俗の塵に染まってしまったからダメだね」と，あっさり断られた記憶がある．

わたしはもともと論理的にものごとを考えるのが苦手なのだ．自分のそうした欠点をなおすために
プログラミングという職業を選んではみたものの，本格的に科学哲学の世界に足を踏み入れることをこれまで意図的に避けてきた．しかし，こうなったら仕方がない．帰国したらいろいろな文献を集めてもう一度勉強しなければいけないと思いながら，ひとまずまた論文をバッグにしまって眠りについた．
4．Model−Based？

翌朝29日（火曜日）の8時半過ぎに成田着．とりあえず家に荷物を置いて，その夜はSEA幹事
会．翌日，会社の図書室でICSEのProceedingsやSpringerLNCSシリーズから次の2つの論文を探し出してコピーし，翌週月曜日（4／3）のSEAForumの発表スライドを準備しながら拾い読みすることにした．
AMHaebererandTSEMaibaum：付sciemificRigour，anAnswertoaPragmatic
Question：aLinguisticFrameworkforSoftwareEngineering（ProceedingsofICSE−2001inTbronto）

Marie−ClaudeGAUDEL：

TestingCanBeFormal，Too（ProceedingsofTAPSOFT

95，SpringerLNCS915）

この論文探し作業の思わぬ副産物は，TAPSOFr

95のProceedingsの中に，以前からわたしが気にかけていたChristianeFloyd女史の講演原稿が入っていたことである．
noydさんの名前を初めて知ったのは，1988年春，ACM／SIGSOFrのニュースレターに掲載された論文を読んだときだった．ちょうど産学協同の国際プロジェクトSDAで，ソフトウェア設計プロセスの支援環境をどうすればよいかについて，連続ワークショップ形式の討論を行っていたところだった．「ソフトウェア工学の世界でプロダクト指向からプロセス指向へというパラダイム・シフトが起こっている」というかの女の鋭い指摘は，わたしにとってひとつの衝撃だった，
MSOFrという会議は，もともと1985年に，当時ベルリン工科大学にいたかの女が，同僚のHartmutEhrig先生と一緒に，ソフトウェア工学における実践派とフォーマル派との間の交流のための場を作ることを意図して始めたものらしい．したがって，その10周年を記念する会議に，かの女が基調講演者の1人として招かれたようだ．この講演で，かの女は次のように述べている：
形式手法派の人たちはもっぱらComputationについての議論に熱中し，一方で実践派はComputingとくにその人間的・社会的側面を重視している．そして仲間同士だけでかたまり，お互い相手のグループを軽蔑または無視しているようだ．これではいけない．
ソフトウェア工学の進歩にとっては，2つのグループの間の継続的な対話や討論がどうしても必要なのだ．TAPSOFrその他の技術的な会議が，そういう意味でまだ十分に機能していないのは残念なことである．

26

たしかにその通りだと，（フォーマル手法にも興味を持っている）実践派の1人として，わたしも考える．もうひとつこの講演原稿で面白いと思ったのは：北欧のソフトウェア技術者・研究者たちの多くは，オブジェクト指向プログラミングの元祖といわれるSIMUIA63を用いて，社会システムのシミュレーション・プログラムを書くことから勉強を始めているので，ソフトウェア工学の社会的側面（ComputingProcessに関することがら）に強い．
という指摘であった．そういえば，わたしが最初に目にしたSIGSOFrニュースレターでのかの女の論文は，もともと「コンピュータと民主主義：スカンジナビアからの挑戦」という本から転載されたもの
だった．
さて，問題のHaeberer−Maibaumの論文「数学的厳密性，実践的質問へのひとつの回答：ソフトウェア工学のための言語論的フレームワーク」だが，そのAbstractは次の通り：

ソフトウェア工学における数学の役割についての議論は，これまで20年ほどの間，日常的に続けられてきたが，ほとんど何の成果もあげていない．現在では，ソフトウェア構築という仕事が持つ「直観的」な性質について多くのことが論じられ，グラフィック・デザインや（伝統的な）建築などとの（誤った）類推が語られている．そこでいわれている結論はといえば，数学は必要以上に賓沢であって，他の諸分野におけると同様に，日常の実践には不要だというものである．われわれは20世紀の「科学哲学」の分野で開発されてきたさまざまなアイ
デアを見直すことによって，そうした考え方に異議を唱えたいと思う．われわれは，これらのアイデアが活用できる理由を示し，ソフトウェア工学上の多くの中心的なアイデアを形式化し組織化するためのフレームワーク（哲学者カルナップがいう意味でのフレームワーク）を提示して，単純な「直観」の思想を反駁したいと考える．科学哲学によってもたらされる諸概念はソフトウェア工学の理論や実践を正しく評価するために必要な科学的・工学的なフレー
ムワークをわれわれに提供してくれる．
まるでフォーマル派一刀流の大太刀を真向上段に振りかぶったような筆致で，このままでは「恐れいりました」と膝を折るしかないように感じられるが，そこをぐっと我慢して，駆け足で本文に目を通して行く．
第1章は，ソフトウェア工学において数学が果たす役割について，さまざまなエピソードを交えたイントロダクション．そして第2章はカルナップほかの哲学者によって発展してきた科学哲学的意味論のソフトウェア工学問題への適用例．そのなかで，仕様からテストケースを自動生成するというGaudel女史のフォーマル・アプローチが批判されている．ただし，詳細な議論は別の論文【＊】を参照ということで，簡単にしか述べられていない．そして，第3章では一転して，ソフトウェア工学のための認識論的基盤の構築を詳しく論じている．
［＊】この論文はHaeberer先生がミュンヘン大学で1999年に書かれたもの：
M．V．CengarleandA．Haeberer：〃TowardsanEpistemology−BasedMethodologyforVerificationand
ValidationTesting．

27http：〟www・pSt・informatik・uni−muenChen・de／personen／cengarle／proceedings・P亭

ダウンロードしてみたら70ページもあるので，読むのはちょっと保留．

この第3章に載せられたダイアグラムには，いささか興味を惹かれるものがある，「ソフトウェア開発の認識論的フレームワーク」と名づけられたその図は：（1）

Reality（仮定されたユーザ・ニーズ）（2）

ModifiedReality（ソフトウェア・プロダクト）（3）RequlrementSpecification（4）

DesignSpecification（5）

RefinedDesignSpecificationという5つの頂点を持つ5角形の形をしている．そして，それらの5つの頂点のうちの3つを結ぶ10個の3角形がソフトウェア開発プロセスを構成する10のサブプロセスを表すようになっている．ソフト

ウェア・プロセスの分析に関して，この認識論図式は，これまでになかった新しい発見をもたらすのではないかという予感がする．
第2章で否定したGaudelの手法に代わるものとして，Glymorのブートストラップ・アプローチにもとづく手法というのが紹介されているのだが，これは初めて聞く名前である．ネットサーフして調べてみると，CMUの科学哲学の先生だということがわかった．Referenceに出ていた論文
Hypothetico−deductivismisHopeless（なんとなくセンセーショナルなタイトル）をダウンロードしてみたが，面倒な記号論理式が並んでいるので，これも読むのは保留．
MBTワークショップのAichemig−Georgeの論文の序論には次のように書かれている：

形式的仕様（モデル）にもとづくテスティングは，GaudelがTbstingcanbeformaltooとその論文で宣言して以来，アクティブな研究領域になった．それは仕様がブラックボックス
テスティングを可能にするからであった．仕様は，テストの結果を予測する上での福音であり，その構造を分析することによってテスト・ケースの生成が可能になる．現在の仕様記述
言語のほとんどにテストケース生成機能がついているのは，そうした研究の影響である（たとえばVDM，Z，B，CSP，Lotus，あるいはRAISEなど）．しかし，そうした研究は，認識論に根ざした深い基礎を考慮することを忘れていた．
AmandoHaebererは，20世紀科学哲学の成果がソフトウェア・テスティングと密接に関連していることを発見した．特に，有限な観測結果によって科学的仮説を検証することについての議論が，形式的モデルからテスト・ケースを生成する問題にそのまま当てはまることに，かれは気づいたのである．Camapは，Statement Viewと呼ばれる論理的フレームワークを考案した．考えるべき問題の1つは，仮説を記述するための理論的言語が無限の要素を含んでおり，一方，観測の世界は有限であることである．有限の観測によって無限の理論をいかにして検証できるか・この問題をめぐってのCamap対Popperの論争はよく知られている．そして，「テスト・ケースはバグの存在を証明することはできる．しかし不在証明にはなりえない」というDjkstraの有名なことばは，基本的にPopperの側に立っ発言であった・しかしながら，Haebererその他の人びとは，コンピュータ科学のコミュニティに対して，もう1つの重要な研究成果を報告した．clarkeGlymorが，仮説およびその背後にある理論から期待される観測結果を導き出すという古典的なアプローチには基本的な問題

28

点があり，この仮説演繹的（Hypothtico−deductive）アプローチの欠陥を補おうとするすべての試みが失敗に終わるということを，証明してみせたのである．
これは，われわれにとってきわめて重大な警告であろう．なぜなら，現在行われているほ
とんどのModel−BasedTbstingのアプローチは，Gaudelが代数的仕様記述について行った仕事も含めて，本質的に仮説演繹的だからである．
仕様は有限な記述であり，対象システムは無限の要素を含む現実世界に属しているということは，
ソフトウェア開発に携わる者ならだれでも知っている（しかし，時に忘れてしまうこともある）事実であろう．無限の要素から成る現実世界をわれわれが認識するための手段としての言語は，可能性としては無限の文を作り出す機能を持っている．しかし，現実に書かれる仕様は，可能な文の無限集
合のうちの有限な部分集合でしかない．無限に変化しうる可能性を秘めた対象システムを有限な記述でとらえるために，われわれはシステム分析にさいして，ある前提条件を仮定し，いくつかの要
素を切り捨てるしかない．
昨年のICSMに併設して開かれたSoftware Evolutionワークショップの基調講演で，M．M．bhman先生はシステム進化におけるこの間題を指摘している．当初のシステム設計が行われる時点でとりあえず切り捨てても問題のなかった要素が，時間の経過にともなってシステムにとって重要な影響をもたらすものに変わってくることがあり，それがいくつかの大規模システムのトラブ
ルの原因になる・このシステム・メインテナンスにおけるAssumptionManagementの問題は，テステ

ィングとは別の次元のことがらであるが，その背後に認識論（Epistemology）あるいは存在論（Ontology）の影がちらついているという点では同じカテゴリに属している．
さて，Haebererは，眼前の問題点を克服するために，Glymorのブートストラップ・テスティングのアプローチを提案したのだという．ブートストラップとは何か．要するに，仕様から生成されたテス
トケースを用いてプログラムの正しさを証明することは本質的に無理だから，他のやりかたを考えようというのだろうが，その代替手法とはどんなものなのだろうか．Aichemig−Georgeの論文に出ている簡単な解説は次の通り：
ブートストラップ技法は（仕様−＞テストとは）逆向きに働く．それはまずテスト結果から出発して，そこから演繹的に理論上の仮説を導き出す．たとえば，ソーティングのプログラムが入力データをきちんと並べ替えたものを出力したとすれば，その事実からわれわれは，その出力が入力の並べ替えであるという仮説を確認できる．こうしたアプローチは自然科学において日常的に行われている．たとえば，惑星の軌道の観測から，まず，それらの軌道が太陽を焦点とする楕円であるというケプラーの仮説が導き出され，さらに後年，同じ観測結果からニュートンの万有引力の仮説が導き出されている．
なるほど，そんなものかも知れないが，まだ何となくピンとこない．やはり，邦訳されているカルナ
ツプの論文をベースに，Haeberer先生の論文をじっくり読んでみる必要がありそうだ．しかし，これに続く次のパラグラフが興味深い：
Haebererが指摘したように，観測された事実が仮説と矛盾した場合，通常は仮説が捨てられるのである．それには長い時間がかかるが，上に上げた例の場合でいえば，われわれは最終的に観測された事実を受け入れ，真円軌道のエレガントさや単純さに対するわれわれの好みにもかかわらず，プトレマイオスの太陽系理論を捨てることにしたであ29

った．しかし，ソフトウェア・テスティングの場合には，そうした矛盾が生じると，われわれは，前提となった理論すなわち要求仕様を確認することができなかったプログラムのほうを捨ててしまう．そこでHaebererは，ある種の逆ブートストラップ・アプローチともいうべき方法を提案した：われわれは理論を検証したいのではなく，プログラムを検証したいのである．
うーむ，なにやら面白そうではあるのだが，いまはいろいろ雑用で忙しいので，これ以上この間
題に首を突っ込んで記号論理式と格闘している暇がないのは残念．ICSE2006で上海のホテルに1週間滞在している間にはなんとか時間が取れるかもしれない．フォーマル・メソッドが専門の先生方も何人かご一緒するので，論文のわからない個所も質問できるだろう．
ところで，ここでFloyd女史の指摘にしたがってComputationの視点からComputingの世界に足場を移して，ユーザ・プロセスという視点からこのテスティングを眺めると，様子が少し違ってくるように思われる．
4月3日に行われたSEAFommで「ソフトウェアが，仮説すなわち要求仕様（テスト仕様）通りには動かないという現実の結果が得られたとき，どうして仮説（仕様）のほうを捨てないでソフトウェアを直そうとするのか？」という素朴な質問を，なかば悪戯心でわたしが投げたとき，フロアの何人かの方から「われわれはそういう世界に住んでいるのだから仕方がない」という応答をいただいた．それは，ソフトウェア開発者の立場からは当然の答えだったと思う．

しかし，視点をちょっと変えて，開発プロセスとは切り離されたユーザの立場で，自分の仕事のプ
ロセスのツールとしてのソフトウェアを考えると，それが（自分の望んでいた）仕様通りには動かないという仮説を否定するたしかなテスト結果が得られたとき（つまりあらかじめ考えていた仮設が否定されたとき），その仮説（すなわち仕様）を捨てて，テスト結果から逆に再構成するかたちで（現実の）仕様を作り直し，それを前提として，そのソフトウェア・ツールを自分の作業プロセスのなかにどう組み入れるかを考えるほうが，実際的なのではないだろうか．
ユーザ・サイドのComputingProcessすなわちソフトウェアの開発倭託／購入そして運用までを含めたプロセスにおける受け入れテストの意味合いは，そんなものではないかと思われる．もちろん，テスト結果が示す現実の証拠を開発者に突きつけて，ソフトウェアがあらかじめ与えられた仕様を満足するよう改訂要求を出すことは当然であるが，現実のビジネス・プロセスは，その改良が終わるのを待ってはいられないことが多い．
実際われわれが市販のCOTSを使って仕事をするさいのComputingProcessはそうなっている（いろいろ文句をいいながらWindowsを使っているプロセスがその典型）．欧米では，数年前からCOTS−BasedSoftwareEngineeringと題された会議が毎年開かれているようだが，そうした問題も論議されているのだろうかと，ふと考えた．
COTSといえば，CMU／SEIのWebSiteに，毛沢東語録のスタイルを模した1篇のドキュメントが載っている．
QuotationsfromChairmanDavid−ALittleRedBookTruthstoEnlightenandGuideontheLengMarchTowards

COTSRevolution
http：〟ⅣWW・Sei・Cmu・edu／publications／documents／99．reports／lrbnittle−red−book．html

筆者のDavidCameyさんがどんな人なのかは知らないが，なかなか酒落たセンスの読み物である．このスタイルを真似ていろいろな分野の入門書が書けるような気がする．

30

SEAForumApril

WaterfallModel再考（最高？）主催：ソフトウェア技術者協会（SEA）
W．Royceが，いわゆるWaterfallModel

論文を1970年に発表してから，早いものでもう35年が過ぎました．その後いくつものソフトウェア開発プロセスモデルが発表されていますが，このモデルは，現在でも，特に大規模プロジェクトにおいては，基本となる開発モデルとして使われている
ようです．

しかしながら，原論文に提示されているフィードバック付の逐次型開発プロセスモデルは，その後の環境変化に応じてさまざま々な解釈がなされ，多様なプロセス実装が行われています．
今回は，このWaterfallModelの概念的フレームワークを，もう一度原論文に立ち戻って理解するとともに，その後の開発プロセスモデルの変遷を，最近のアジャイルプロセスまで含めて展望し，
ソフトウェア開発の現状と将来につい討論するフォーラムを企画しました．
『W．Royceがその論文で提起した大規模ソフトウェア開発管理の問題に対する提案を，その後の技術発展やコンセプトの進化をふまえて検討し，ソフトウェア工学40年の歴史で整理された見解を踏まえて，今そして明日何をなすべきかについて考え行動するかを，参加者のみ
なさんと一緒に考えてみたいと思います．（落水）』

春一番の楽しい討論が期待されます．多数の方々の参加をお待ちしています．
参考：W．Royceの原論文（スキャンイメージです）
httD：／／www．cs．umd．edu／class／sT）ring2003／cmsc838D／Pl・OCeSS／waterhll．Ddf☆如拙☆☆柚☆柚如拙★

開催要領☆柚加納☆柚☆☆☆如拙

1．日時：4月3日（月）16：00〜20：30

2．プログラム
15：30−16：00受付
16：00−17：30講演：

WaterfallModel

再考

落水浩一郎（北陸先端科学技術大学院大学）
17：30−17：45とりあえずの質疑応答
17：45−18：15休憩

18：15・20：30討論：ソフトウェア開発の現状と将来を考えるコーディネータ：田中一夫（SEA代表幹事）
パネリスト： 平鍋健児（チェンジビジョン）
伊藤昌夫（ニルソフトウェア）

落水浩一郎（北陸先端科学技術大学院大学）
岸田 孝ナ（SRA先端技術研究所）
3．会場：全国情報サービス産業厚生年金基金（JJK）会館2F B会議室
4．定員：50名

31

WERFALLModel再考
ソフトウェア開発管理とソフトウェア開発方法論の融合について
北陸先端科学技術大学院大学
落水

情報科学研究科清一郎

本フォーラムの目的は、W．Royceが論文［1］で提起した大規模ソフトウェア開発管理に関する問題を、ソフトウェア工学40年の歴史（その後の技術発展やコンセプトの進化）をふまえつつ、再度検討することにより、今、明日、何をすべきかについて考えることであると理解する。まず、W．Royceの論文内容を著者なりに要約する。つぎに、1970年のW．Royceの論文を基準点として考え、彼が提起した問題に対して、その後どのような解決が試みられたかを整理する。最後に著者なりの問題提起を行い、フォーラムにおける議論のきっかけの一つにしたいと思う。

1・WRoyceによるManagingtheDevelopmentofLargeSofLwareSystems（1970），，の紹介

彼の論文の主旨は、大規模ソフトウェアの開発管理をどのようにして実現するかという提案と、そのような開発手段を採用したときに起こる問題をどのように解決するかという2点である。まず、図1に彼が論文で導いた結論を示す（図1）。

図1

まとめ

1．分析とコーディングのl滴に日貨．汁を宗／せよ

2．又．巧は最新でかつ六合3．1】丁稚なら2J要行え

4．テスティングが．汁両され、制御され、l：訂祝されるべき

5．麒牛を合めよ

＝∴∴

一一一一」

図1にいたる、彼の思考の展開を論文の流れに沿って迫ってみよう。
（1）プログラムの規模や複雑さにかかわらず、どのようなプログラムをつくるべきかとい32

う「分析」と、それをどのように「コーディング」するかというステップは、プログラマにとって本質的なものである。また、最終プロダクトに直接貢献する創造的なステップとして、顧客はよろこんで報酬を出す。しかし、この簡単なモデルは、労力が十分に少なく、最終プロダクトが開発者によって稼動される場合のみ（すなわち内部
利用の場合のみ）有効である（図2）。

顧客：報酬

内部利用のみ有効

プログラマ：創造

図2

内部利用のための小規模なプログラムを引き渡すための実現ステップ（2）より規模の大きいシステムでは、この二つのステップのみではプロジェクトは失敗に終わるので、最終プロダクトに直接貢献しない多くの付加的な開発ステップが必要になる（訳注：最終プロダクトに直接に貢献しない付加的な開発ステップという表現の真意は不明である）。それらのステップはコスト増をまねく。また、顧客はあまり報酬を支払いたがらないし、開発担当者はそれらのステップを実行したがらない。管理の第一義の機能は、これらのコンセプトの必要性を双方のグループに納得させ、また、開発担
当者には従うことを強制することである。それらのステップは、順に「システム要求定義」、「ソフトウェア要求定義」、「分析」「プログラム設計」、「コーディング」、「テスト」となる。「システム要求定義」、「ソフトウェア要求定義」、「プログラム設計」、「テスティング」の付加的ステップは、実行される手段が「分析」や「コーディング」とは異なるので、分離して処理される（図3 実行順序を示す矢印ノを除く部分）。
（3）7つのステップに、「詳細化のために、順次実行する」、「一つ前のフェーズに後戻りする」という実行順序に関する情報を付加する（図3）。すなわち、「各ステップの進行につれて、設計内容はより詳細化される」、「一つ前のステップへの後戻りは起こるが、数ステップ前への後戻りはめったに起こらない」という仮定を置く。この考え方のよい33

点は、設計が進行するにつれ変更が管理可能な範囲に限定されることである。すなわ
ち、予期せぬ困難が発生した時、どこに戻るかを指示している、安定した、移動するベースラインが近距離にある。

（4）上記仮定をそのまま実現するのは危険であり、失敗をまねく（訳注：順次的なステップの実行、すなわち、ベースラインの移行が現実的な仮定ではないことを彼自身は認識していたことになる）。

34

何故なら、開発サイクルの最後にくるテスティングでは、タイミング、記憶容量、入出力転送などに関して、分析段階とは異なる現象が認知される。これらの現象を厳密に解析することはできない。さらに、これらの現象が様々な外部制約を充たすことに失敗した場
合は、再設計が必要となる。必要とされる設計変更は破壊的なものであり、これはさらに、設計に根拠を与えている要求に違反することになる。この結果、「テスティング」、「プログラム設計」、「ソフトウェア要求」という大幅な手戻りを生じ、要求が変更される場
合も、本質的な設計変更がある場合も、100％のオーバーランをコストやスケジュールに引き起こしてしまう（図4）。

（5）それにもかかわらずこれらのアプローチは基本的には健全なものであり、これらの開発上のリスクを除去するような以下の5つの特徴をつけ加えることで対応できる。
（5−1）「基本設計」フェーズの導入「ソフトウェア要求定義」と「分析」の間に基本設計を挿入する（図5）。

これは、「要求は存在するが分析結果が存在しないという相対的真空状態のなかで設計することをプログラム設計者に強制する」という批判を生み出しうる。この批判はあたっているが一つポイントをはずしている。基本設計を行うことにより、プログラム設計者が記
憶容量、タイミング、データの不安定さによっては失敗しないことを保証できる。なぜな

ら、次の分析フェーズで、プログラム設計者は記憶容量、タイミング、稼動に関する制約
を解析の課題に加えることができるからである。すなわち、タイミング、記憶容量、稼働に関する制約を考慮した「分析」を可能にする（訳注：これが納得のいくレベルで実施できる技術はまだ開発されていないと思う）。基本設計フェーズは以卜の3点からなる。

35

・基本設計プロセスを、分析者やプログラマとではなく、プログラム設計者と実施する
状況が悪いというリスク下でもデータ処理モードを設計し、定義し、割り当てる：処理と機能を割当、データベースを設計し、データベース処理を定義し、実行時間を割
当、オペレーティングシステムとのインタフェースと処理モードを定義し、入出力処理を記述し、基本的な稼動手順を定義する。
・理解容易であり、情報に富み、かつ最新のオーバービュードキュメントを書く：すべての作業者はシステムについての基本的な理解を持つべきである。少なくとも一人は、
オーバービュー文書を書き、システムについての深い理解を持つべきである。
（5−2）設計結果を文書化する

ここでドキュメントをどの程度書くべきかという問題を提起する。「かなり書く必要がある」というのが著者の考えである。「かなり」とは、プログラマ、分析者、プログラム
設計者が自身の工夫で書こうとするものより多いことを意味する。ソフトウェア開発を管理するための最初のルールは文書化要求を冷酷に課すことである。文書は受理できる水準にする必要がある。高水準の文書化なしにはソフトウェア開発管理は不可能である。5百万ドルのハードウェア装置には30ページの仕様書、5百万ドルのソフトウェアには1500ページの仕様書が必要である。何故そのように大量の文書が必要なのであろうか？
●

各設計者は、インタフェースをとるため、他の設計者とコミュニケーションする必要がある。また管理者、場合によっては顧客とコミュニケーションする必要がある。話し合いの記録だけでは決定事項を管理するのには不十分である。受理でき得る記述は設計者に明白な立場をとり、形ある完了の証拠を与えることを強制する。これにより90％シンドロームを回避できる。

●

ソフトウェア開発の初期のフェーズでは、文書は仕様であり設計である。コーディン

グが始まるまでこれらの3つの言葉（文書、仕様、設計）は単一のものを示す。文書が悪ければ、設計も悪い。もし文書がまだ存在しなければ、設計もまだ存在しない。
●

良い文書の値打ちは、テスティングから稼動、再設計にいたる開発工程の下流で認識される。

（ア）テスティングフェーズでは、良い文書は、管理者が担当者にプログラム中の誤りに集中することを可能にする。良い文書がない場合は、そのプログラムを理解している唯一の人間である誤りを犯した人によって、誤りは解析されることになる。

（イ）稼動フェーズでは、良い文書はオペレータを稼動に専念させうる。良い文書がない場合には、それを書いた人が稼動させることになる。一般にプログラムを書いた人はそのオペレーションに関心がないので仕事を効果的に実施できない。
（ウ）最初の稼動に引き続いて、システム改良の順番になったとき、良い文書は効果的な再設計、更新、改造などを可能にする。
図6に、各ステップのキーとなる文肘ヒプランを示す。6つの文書が生成され、引渡し36

時期に文書1、3、4、5、6が更新され最新化されることに注意して欲しい。

（5−3）基本設計以下を2度行えはじめてのシステムの場合、運用のために顧客に最終的に引き渡される版は第2版であるようにする。開発労力が30ケ月の場合は10ケ月、12ケ月の場合は3ケ月を開発のシミュレー

ションにあてる。設計における問題点を検知しモデル化せよ、代替案をモデル化せよ、不要な詳細を無視せよ、最終的には虫のないプログラムを達成せよ。この結果、タイミング、
記憶容量その他の判断事項はある程度正確に理解できる。このように一度目は問題発見に力を注ぎ、2度目に解決策を組み込む（図7）。
（5−4）テストの計画と制御と監視（マンパワーであれ、CPU時間であれ、管理者の判断であれ）プロジェクト資源の最大の消費者はテストフェーズである。テストは、コストやスケジュールに関して、最大のリスクを持つフェーズである。それはスケジュールの最終点でバックアップする代替物がほとんど利用できないときに起こる。5−3までに述べた3つの推奨：分析やコーディングのまえに基本設計を行う；文書化を完全に行う；パイロットモデルを構築する；はすべて、
テストフェーズに入る前に問題を発掘し解決することに狙いがあった。しかしながらこれらのことを行っていてもテストフェーズが残っており、そこでなされるべき重要なことがある。図8にテスティングに関する視点を示す。

37

テスト計画を立てるとき、以下の点を考慮することを奨める。
●

テストプロセスの多くの部分は、テストの専門家によって最もうまく処理される。テ

スト専門家は必ずしもオリジナルな設計に寄与していなくてもよい。もし、設計者しかテストをできないことが問題になる場合は、文告化が不1−分な兆候である。

38

● ほとんど甲誤りは、視覚的な検査により容易に特定できる。すべての分析結果やソースコードは第3者の視覚的検査を受けるべきである。コストがかかりすぎるので、この目的で計算機を利用しないほうがよい。
●

プログラム中のすべての論理パスをテストせよ。巨大で複雑なプログラムの場合、これは大変困難であり、ときには不可能な場合もある。しかし、カバレッジ100％の必要性を主張しておきたい。

● すべての単純な誤りを除去したのち（これがほとんどであるが）、点検のため、ソフトウェアをテストにまわせ。
（5−5）顧客を含めよ

最終引渡しの前、早い時点で顧客に責任を持たせるため、顧客を開発に公式にふくめることが重要である。「要求定義」と「稼動」の間で契約者に自由な裁量を与えることはトラブルを招く。要求定義の後にくる、顧客を含めるべき3箇所を図9に示す。

（6）まとめ

大規模ソフトウェア開発の経験に基づいた以上述べてきた考察の結果として、冒頭（図1）に示したウオーターフォール・モデルを提案する（図10に再掲）。図10に、リスキーな開発プロセスを所望の製品を提供する開発プロセスに変換するのに必要な5つのステップをまとめ、それらを統合したものを示す。それぞれが幾分かのコスト増をまねくことを強調しておく。より簡単なプロセスを採用すれば余分なコストはかからないが、大規模なソフトウェア開発ではうまくいかない。

39

図10

まとめ

1．分析とコーディングのl泊に，，姥．汁を読了せよ

2．文．号は昆新でかつ宗全3．可能なら2度行え
4．テスティングが．il・両され、制御され、監視されるべき

5．麒牛を合めよ
ヒ

￣

■

′

㌧1■￣

［］

つまり、彼は1970年の時点で、あとで問題になるかなりのことを意識的（あるいは無意識に）予想し、それなりの対応策を提案していたことになる。彼の提案にはウオータフオ
ール・モデルに限定されない、ソフトウェア開発が内蔵する様々な問題点が含まれている。

彼が論文中で提案した解の是非も含めて、その後のソフトウェア工学の発展（試行錯誤？）の歴史をたどってみよう。

2．それ以降の技術発展
ソフトウェア開発方法論とプロジェクト管理は、ソフトウェア開発プロジェクトの成功にとって、車の両輪の関係にある。それらをまとめるものがソフトウェア開発パラダイムである。ソフトウェア開発方法論の研究では、ソフトウェアの望ましい「構造」を模索しつつ、それらの構造を作りこむ手段を検討する。追求されてきた「構造」の属性として、正しさの確認容易性、変更波及の局所化、作業分担の容易性、再利用容易性、進化容易性などがあげられる。一方、プロジェクト管理は、方法論を遂行するプロジェクトチームのコスト、スケジュール、品質などに関して、それらを計画する、見積もる、寧問あ割当て
る、プロジェクト状況を監視し制御するための手法を追求する。
2．1プログラミング方法論（1970年代前半）
構造化プログラミング（1972）、情報隠蔽原理（1972）、JSP法（1975）により、全体の作業を、独立性を保証する作業車位へ分割する手段、作成中のプログラムが所望の動40作を行うことを確認する手段の提供などに力点を置いたプログラミング方法論が発展した。
2．2 設計方法論（1970年代後半）

複合設計（1978）、構造化設計（1979）などにより、変更の波及を局所化できるようなソフトウェア構造とその作りこみの手段が検討された。
2．3 要求定義（1970年代後半）「問題を定義する手段なしに、解を構築する手段を追求しても意味がない」という反省のもとに、70年代の後半（1977）に、ウオータフオール・モデルの出発点となる要求定義

フェーズの形式化が課題となり、機能要求や性能要求を記述し解析するための要求定義法に関する研究が始まった。要求定義法のみによっては、要求仕様を確定できないことがすぐに明らかになった。
2．4

定量的プロジェクト管理（1970年代後半から1980年代前半）

コスト見積り（COCOMO，1981）、危険要因の検出（MaCaveのV、1976，HalsteadのE、1977）、テスト時期の打ち切り（信頼性曲線、1982）などの定量的プロジェクト管理に関する試みが開始された。この段階で、ソフトウェア開発パラダイムとプロジェクト
管理の関係、ソフトウェア開発パラダイムとソフトウェア開発方法論の関係が検討されはじめたが、ソフトウェア開発方法論とプロジェクト管理の関係が検討されなかったのは問題であると考える。
2．5 システム工学の導入（1980年代中期から後半）

この時期にウオータフオール・モデルの様々な改良が試みられた。文献［2］の内容を引用することにより以下に説明する。
1．ウオーター・フォールモデルの派生型はそのほとんどがシステム工学の原則から生み出されたものである。システム工学は複雑なシステムのコンポーネント設計、仕様化、実装の検証を主な目的としたものであり、元々はスペース・シャトルのような航空宇宙システムやNATOの指揮制御システムといった、大規模システム構築時に発生する問題を解決するために開発されたものである。上記のようなシステムは、あまりにも規模が大きいため、開発そのものを複数の企業に分散させねばならない。まず、ある企業が元請業者となり、システム全体の設計と統合を担当し、そして、元請業者のシ
ステム・エンジニアが集まってシステム要求を分析し、その後、複数のサブシステム
へと分割してシステム設計を行なう。
2．システム工学的アプローチは：システム要求を定義する；システム要求をサブシステ
ムに配分する；詳細なコンポーネントを定義する；コンポーネントを検証する、サブシステムを検証する；といったⅤ字型のプロセスになる。

41

3．システム工学アプローチは一見すると、大規模なソフトウェア・システムを開発する

アプローチとして適切であるように思える。しかし、システム工学的アプローチが基としている前提は、ソフトウェア開発ではうまく適用できないものである。その前提とは、要求が安定していること、実装に先立ってインタフェースを適切に仕様化できることである。

4．ウオータフオール・アプローチによって、要求管理、アーキテクチャと設計、実装、テスト、運用、保守といった、プロジェクトの基本的なアクティビティが洗い出された。しかし、要求ドキュメントや設計ドキュメントを凍結できないというソフトウェ

ア開発特有の性質のため、近代的なソフトウェア・プロセスにおける詳細なアクティ
ビティや成果物は、システム工学プロジェクトのそれとは大きく異なっている。
2．6

反復型ウオータ・フォールモデル（1980年代前半）

これについても文献［2］の内容を以下に引用する。
WRoyceやB．Boehmといったソフトウェア開発管理の創始者達は、かなり初期から古典的なウオーターフォール・プロセスの問題に気付いていた。1980年代に彼らは、ミニウオ
ータフオール、あるいはBoehmスパイラルモデル（1988）といった、顧客とのやり取りを改善できる、ウオーター・フォールの改良版を考案している。

1．改良版では、開発サイクルを短い期間に分割し、それぞれの期間でウオーターフォー
ル・プロセスを実行し、要求のレビュー、ドキュメントの更新、コードの開発を行う。

ある反復での成果物は次の反復の入力になる。顧客レビューと仕様の更新といったプロセスを、連続しておこなうことによって、プロジェクトのリスク管理を可能にする。

2．古典的なウオータ・フォール管理アプローチにおけるいくつかのコンセプトは、適切に変更すれば、ソフトウェア・マネージャにとって有益なものとなる。中でも、プロジェクト計画と進捗管理の原則は常に重要である。特に、作業分割の構造、コストとスケジュールの変化、出来高といったものを理解することは有効である。アクティビ
ティに基づいた計画や厳格なタスク分割は、プロジェクトの本当の性質を反映したものでないために、各アクティビティにかかった時間を評価してもプロジェクトの実状すら把握することはできない（著者注：この言明を是とするならば、付録B「PMBOKの内容」における「計画プロセス群」、「プロジェクトタイム管理」における様々の技
法はあまり有効でないという結論になる）。

3．問題を早期に洞察すればするほど、それを修正できる可能性がましていくというのが大規模システム構築における基本原則である。修正コストというものは、プロジェク
トの進捗に従って劇的に増加していく。統合とテストを最終段階で行うウオータフオ
ール・アプローチは、統合段階に到達しなければ実際の作業状況を認識できないという問題がある。

42

2．7 プロトタイピング（1980年代前半）
Royceの論文ではライフサイクルでの「内なる繰り返し」が推奨されているが、1980年代

初頭（1985）におこったプロトタイピングは、利用者世界を含めてサイクルを回す必要があるとの認識に基づいている。この時代のプロトタイピングはどちらかというとイテレー

テイブイン（反復）開発であり、プロジェクト状況の学習にともなうプロセスの改善を目指すインクリメンタル開発ではなかったように思える（文献［3］の5．3節を引用して、両者の定義を付録Aで説明する）。後者の場合、固定的な標準化は学習の効果を無視することになり望ましくないように思える。しかし、プロジェクト進行中に頻繁にその進め方を変更することはある種の混乱を招く。プロセス改訂の頻度をタイミングが問題である。
2．8実行可能仕様（1980年代中期）
リアルタイムデータフロー（Ward1986）、JSD（M．Jackson，1983），PAISLey（P．Zave，1986），

PROTnet（Bruno，1986），UI（Wasserman，1986）など上流工程をフォーマルに書く技術が発展した。これらは、後に上流工程の各種プロダクトを表現する言語の発展につながった。しかし、コーディングを労働集約型として蔑視する動きを助長した問題点もあるように思える。
2．9

フォーマルメソッド（1980年代中期）

上流の文書化の質が下流のプロダクトの質に影響を与えるというW．Royceの見解に対して、上流の文書を数学的記法で厳密に記述すれば、人間が解析困難であるさまざまなソフ

トウェア性質の検証、証明、自動化が可能になり、検査フェーズのコスト減や最終プロダ
クトの品質につながるという認識が、1980年代の中頃におこり、モデル検査につながっている

2．10プロセスプログラミング（1980年代後半）
1987年、LOste川dlはソフトウェア開発プロセスを記述するプロセスプログラミング言語を開発することにより、プロセス改善の土台にできると考えたがあまり成功しなかった。
2．11プロセス改善（1990年代初頭）
CMM（1989）・1990年代にはいっておこり、PMBOXl4］その他の体系化として実を結びつつある、ソフトウェアプロセスの改善に関するフレームワークの確立とベストプラクティ

スの整備は開発管理手法の発展をうながした。付録Bに、文献【41における表3−45に、その他の部分の記述内容を、主に、ツールと技法に注目して埋めこんだ表を示す。ところ
で私見であるが、CMMはレベル3以上に実質上の意味があると考える。すなわち、コスト、
スケジュール、信頼性達成などの状況を、ファンクションポイント（FP）にもとづく様々なメジャー［5］（生産性に関する指標：FPあたりの費用、IT部門の生産性、開発速度、ユーザが利用する機能と開発された機能；品質に関する指標：機能要求の規模、完備性、変更率、欠陥除去率、欠陥密度、テストケースの網羅率、文書最；経済性に関する指標：

43

FP当りの費用、補修費率、ボートフォリオ資産価値；保守性に関する指標：保守性、信頼性、要員配置、成長率、ポートフォリオ規模、バックファイア値、安定度）や、CaperJonesが定義した意味でのベースラインやソフトウェアベンチマーク［6］などで（定性的に問題を把握し）、定量的に証拠だてることによりテクニカルプロジェクトマネージメントが可能になる。
2．12CASEツール（1990年代初頭）「上流工程で、早期に、コストのかかる誤りを除去する」などの目的のもとに、StP（1988）、PCrE（1993）などのCASEツールや統合環境が開発された。これについては興味深い意見がある［7］。文献［7］の内容は非常に興味深い、付録Cに文献［7］の要約引用を示すが、ぜひ［7］原本を一読されることを薦める。

真実5．開発ツールの大げさな宣伝はたちの悪い伝染病みたいなものだ。ツールや技法の大部分は、生産性や信頼性を5−35パーセント程度、改善するにすぎない。
真実6．新しいツールや技法を学習すると、最初は生産性や品質が下がる。実際に効果がでるのは、ツールや技法が完全に身についてからだ（習熟曲線）。オブジェクト指向は表面的には3ケ月、自由に使いこなすには3年かかる。ツールや技法の導入を効果的にするには、（1）効果が現実的である（2）気長に効果を待てる場合に限る。
真実7．ソフトウェア技術者は、ツールの話が大好きである。いくつものツールを買い、評価もしているが、開発で実際に使った人はほとんどいない。コンパイラ、デバ

ッガ、エディタ、リンクローダ（無意識）、構成管理ツールで十分である。
2．13

アーキテクチャ中心開発

W．Royceの「基本設計フェーズ」の導入の意図は、1990年代中頃におこったアーキテクチャパターンにより加速されアーキテクチャを評価し、検証する技術が進んでいる。しかし、必ずしも十分な成果が得られているとはいえない。
2．14

オブジェクト指向

再利用のメリットについての議論はともかく、プログラムの構成単位（オブジェクト）に再利用性や変更容易性に関する機構を内蔵させたこと、要求仕様、設計仕様、プログラ
ム、計算機内部の動作間の対応関係をシンプルにし、反復を容易にしたことは見逃せない。

2．15

UML

上流、中流における各種文書を記述するための言語を標準化しようとする努力は無視で
きない。

∠14

2．16

アジヤイル

Royceの論文にある、「テストの計画と制御と監視」、「顧客を含めよ」などの問題提起に形を与えた。また、このアプローチはウオータフオールに対して正反対のアプローチである。［役に立たない要求文書や設計文書のことなど、すべて忘れてしまおう。こういったものが正しくなることはないのだ。ただひたすらにコードのビルドを行おう］。このようなラビッドプロトタイピングのアプローチには利点と欠点がある［2］。

● 利点：チームの生産性が向上する。顧客とのやりとりが建設的なものになる。
●

欠点：プロジェクトを収束させることが難しくなる。スケジュールや予算が見積もりにくくなる。大規模ソフトウェア開発には適さない。成果物がプロトタイプでしかない危険性がある。
3．まとめと課題
いわずもがなであるが、W．Royceの話がすべての原点であるなどというつもりはない。

［2］によればウオータフオールモデルの欠点は以下の通りである。
●

ウオーターフォール・プロセスが機能しない理由を理解しよう。ウオーターフォ

ール・アプローチには、すべてのプロジェクトに適用可能な、重要な原則が含まれている。
① 開発におけるアクティビティを洗い出す。

② アクティビティ毎に工数計画を立案する。
③ マイルストーンを用いてアクティビティの進捗を管理する。
●

このような原則は、マネージメントがしっかりしているプロジェクトであれば、どのようなプロジェクトにも存在する要素である。このため、クリティカル㌧パス分析や細密マイルストーン（inchstone）管理といった、成熟した古典的プロジェ

クト管理テクニックが採用できると考えるのは自然なことである。
●

このアプローチの問題として、まず、ソフトウェア開発プロジェクトは建築プロ

ジェクトほど簡単に計画、評価できないと言う点をあげることができる。橋の塗装が半分完了したというのは、誰の目にも明らかだが、コードの半分がいつ完了したのかを知ることは難しい。また、橋の各部分を塗装する時間は簡単に見積もることができるが、コーディングやデバッグにかかる時間など、最終的なコードの規模が判らなければ誰にも判らない。
● 精密な進捗見積りと完了時間を要求することで、こういった不確実性に取り組もうとするマネージャもいる。しかし、これはマネージャに対して嘘をつくことを開発者に強要することになる。
●

2つ目の問題は、あるアクティビティが完了しないと次のアクティビティが始まらないという、アクティビィティの直列化によってひきおこされる。

●

アクティブティが完了するということは、成果物が完全なものとなったことを意45