qm劇
NewsJetterfromSoftwareEngfneerSAssociation

V。1．14，N。mbe，6May，2005

目

次
1

編集部から

2

メタ設計論による設計行為の理解

蔵川圭

つ ﹂

0

新谷勝利

1

17thSEPGConference2005参加報告e

1

玉井哲雄
鈴木裕信

7

プログラミングと文章技法
DebianMini−Conf2005／CodeFest2005報告

ソフトウェア技術者協会
SoftwareEngineersAsociation
ソフトウェア技術者協会（SEA）は，ソフトウェアハウス，コンピュータメーカ，計算センタ，エンドユーザ，大学，研究所など，それぞれ異なった環境に置かれているソフトウェア技術者または研究者が，そうした社会組織の壁を越えて，各自の種族や技術を自由に交流しあうための「場」として，1985年12月に設立されました．

その主な活動は，槻閑話SEAMAILの発行，支部および研究分科会の運営，セミナー／ワークショップ／シンポジウムなどのイ
ベントの開催，および内外の関係諸団体との交流です．発足当初約200人にすぎなかった会員数もその後増加し，現在，北は北海

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

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

熊谷車

高瑞光裕

幹事：

石川雅彦 大場充 落水浩一郎 窪田芳夫 小林修 小林允 桜井麻里
洒匂寛 塩谷和乾 篠崎直二郎 新谷勝利 新森昭宏 杉田義明
中来田秀樹 奈良隆正野中曹 野村行意 野呂昌満 祐山故
平尾一浩

田中一夫

深瀬弘恭

玉井哲雄中野秀男

藤野誠治

松原友夫

渡遺族一

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

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

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

支部世話人 関西支部：

小林修 中野秀男 横山博司

横浜支部： 野中菅 藤野晃延 北條正顕
名古屋支部 ：石川雅彦 角谷裕司 野呂昌満
九州支部： 荒木啓二郎 武田洋男 平尾一浩

広島支部： 大場充 佐藤康臣 谷純一郎
東北支部： 布川博士 野村行意
賛助会員会社：ジェーエムエーシステムズ
オムロンソフトウェア

ダイキン工業
リコー

オムロン

NTTデータ

SRA西日本

テブコシステムズ富士通

新日鉄ソリェーションズ

盲士電機

ヤマハ

SRA東北

SRA PFU

キヤノン

ブラザー工業

オープンテクノロジーズ

エフビクス（以上19杜）SEAMAIL

Vol．14，No．6

2005年5月10日発行

編集人岸田孝一

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

東京都新宿区四谷3−12

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

印刷所市田印刷株式会社

丸正ビル5F

E−mail：Sea＠sea．orjp〒114−0014

定価 500円（禁無断転載）

URL：http：〟www・SeaJp

東京都北区田端2−3−25Me岱agefhImEditor

SeamailⅥ）1．14，No．5

編集部から

☆

あいかわらず原稿集めに苦労しています．

☆☆
巻頭の蔵川先生のエッセイは，6月に富山で開催されるSS2005でのパネル討論の企画案です．興味深い討論が展開されるものと予想されます．みなさんもぜひ富山へお出かけください．
☆☆☆

玉井先生からは，ものを「書く」職業としてのプログラミングについて文章技法の観点からの分析を試みたエッセイをお寄せいただきました．

☆☆☆☆

鈴木裕信さん＆新谷勝利さんからの投稿は，中国およびアメリカで開かれた国際会議の参加報告です．
SEA会員のみなさんもいろいろな会議に参加される機会が多いと思います．簡単なメモ程度で結構ですから，その報告をお寄せいただけると，編集部はたいへん幸せです．
☆☆☆☆☆

次号は2月末に行われたデザインワークショップの報告を特集する予定です．
☆☆☆☆☆☆

これから夏にかけては，さまざまなイベントが国の内外で予定されています．それらの報告も次々号には載せたいと考えています．

☆☆☆☆☆☆☆

Es8aySeamanⅥ）1．14，No．6

メタ設計論による設計行為の理解− SS2005in宮山におけるパネル討論の企画−

鹿川圭（NAは汀）

来る6月8〜10日に富山国際会議場で開催される予定のソフトウェア・シン
ポジウム2005では，一昨年のSS2003クロージングおよび昨年のSS2004におけるパネルの後を受けて，表題のようなパネル討論が計画されています．コーディ

ネータはNAは汀の蔵川圭先生，パネル・メンバーは，伊藤昌夫（ニルソフトウェア），落水清一郎（JAIST），酒匂寛（Designers，Den），佐原伸（JFITS）の4人です．

以下に載せるのは，蔵川先生がまとめられたパネル企画の趣意書です．きわめて内容の濃い充実した討論が期待されます．SS2005への参加をお考えの方々はぜ

ひこれをお読みになって，フロアからの活発な発言を期待します． （編集部）

1．はじめに日本のソフトウェア産業の技術にかかる国際競争力の一面を捉えることのできるデータがある．総務省統計局科学技術研究調査統計表を見ると，2003年度産業別技術輸出対価受取額および輸入対価支払額（企業等）について，製造業が1，469，012億円および1，317，629億円であるのに対し，ソフトウェア・情報処理業では5，801億円および8，744億円である．

技術輸出入対価とは，パテントや技術指導などの対価であるという．ソフトウェア技術は輸入超過であり，わが国独自技術の向上がいっそう必要であることが見て取れる．

木村英紀はこれまでのソフトウェア振興策が，わが国のソフトウェアの弱きを表面的に捉え，企業の目先のニーズのみに注目して場当たり的に対処してきたことに根本的な問題があると指摘する【11．また，藤本隆宏は，モジュラー設計思想のデジタル財で米国経済が躍進し，この分野で日本企業が不振だったことから，逆に，一部日本企業の得意技が「統合型もの造り能力」と「擦り合わせ製品」であるという歴史的構図が浮き彫りになってきたと指摘する【2】．ソフトウェア技術を向上させるような本質的なわが国における展開が必要であるということであろう．

2

SeamailⅥ）1．14，No．6

E88ay

さて，ソフトウェア技術を向上させ，ひいてはソフトウェア産業の活性化を図るためには，ソフトウェア独自の知識体系を理解しなければならない．計算論から始まり，計算機アーキテクチャ，OS，プログラミング言語，言語処理系，データ構造とアルゴリズム，ネットワーク，ソフトウェア構成論などであろう．我々はこれらのことがわかることと同時に，ソフトウェアを製品としてQCDを意識して市場に投入しなければならない・ソフトウ
ェアを対象としたエンジニアリングを指向しなければならないのである．
ソフトウェアエンジニアリング技術向上のためには，哲学的議論から具体論まで様々なレベルで，要求定義，設計，コーディング，テストなどの技術論から，品質保証，組織論まで産業構造のすべてを網羅して攻略する必要がある．特にそのエンジニアリングの中心にある設計を対象として，ソフトウェアの設計とは何かを問うことは独自技術を獲得するには必要不可欠な理解である．そこで，本パネルでは，ソフトウェア設計の本質を議論に
よって明らかにすることを目指す．
なお，本パネルのテーマは一昨年（SS2003）の熊谷による基調講演「実践的なソフトウェ

ア開発方法論」の問いかけと昨年（SS2004）の「メタ設計論による設計行為の改善」と題したパネルの続編である．

2．議論のアプローチ
ある概念を理解するためには，ある概念と同時に対としてある概念でないものを想起する必要がある．たとえば，「いす」と「いすでないもの」，「自動車」と「自動車でないもの」という具合であろう．すると，ここでは「ソフトウェア」と「ソフトウェアでないもの」の区別をつける必要があろう．さらに設計というコンテキストを枠組みとして規定して，「ソフトウェアの設計」と「ソフトウェアではない設計」の双方を理解することによって，よりソフトウェアの設計とは何かという本質に迫ることが期待できる．ソフトウェアの設計とは何かという問いに対し，ソフトウェアの構成要素を基礎として既存の設計方法を比較して議論することを外延的理解，ソフトウェアの設計と他の設計を比較して議論することを内包的理解と呼ぶことができよう．本質に迫るためには，この両側面からの理解が必要である．

パネル討論のために，まず，蔵川より，ものづくり・人工物設計という視点から僻徹してソフトウェア設計について内包的理解を提供する．そして，伊藤，落水，酒匂，佐原，各氏より各自のソフトウェア設計についての外延的理解を提供する．討論では，蔵川の問

いかけに応じて，伊藤，落水，酒匂，佐原の各氏が答えつつ，全体として議論を深める．

3

E88aySeama止Ⅵ）1．14，No．6

3．ソフトウェア設計の内包的理解から外延的理解へ
人工物一般を対象とした設計についての議論は，1968年に経済学者であるH．A．Simon
がTheSciencesoftheArtificial【3】に著わしたのがはじめであろう．Simonは，広範囲にわたる膨大な文献を参考としながら，設計とは意思決定過程であることを基礎として，設計
対象を設計対象とその環境とに分割して捉え，設計者の認識について議論している．設計

対象そのものは，設計者の認識の中で複雑性を帯びたものであり，複雑性に対処する方法
として階層的構造をとる場合が多いことを述べている．

また，工学者である吉川弘之は1979年に，設計を機能集合から属性集合への写像として
位相空間論を用いて数学的に定式化した【41．数学者の角田譲は一般設計学を数学的に基礎付け，BarWise＆Seligmanの情報の流れの理論であるチャンネル理論を用いて，設計を観念の世界と現実世界を結ぶ情報の流れとして定式化した【51．

ソフトウェアの設計を他の工学分野における設計と比較するときに，設計対象の性質に注目することもできる．玉井哲雄によれば【6】，ソフトウェアという対象は機械や電気のような物理性をもたず，抽象的なものである点が大きな特徴であり，ソフトウェア工学は理学としての計算機科学や数学との距離が近いという．また，プログラミング言語による記述や要求仕様・設計の記述という点で言語表現行為に近いという特性もあり，人文科学とも親近性を持つという．
ソフトウェア実体の本質をIBMOS／360を主とする実務体験からRP．BrookSは言い当てている．BrooksがTheMythicalManMonthl71の著作で根源的に言いたかったことは，ソフトウェア実体の本質であり，それによってソフトウェアにかかわるエンジニアが他の工学設計に比べて対処すべき特徴点についてであろうと思われる．ソフトウェア実体の本質とは，データセットやデータ項目間の関係，アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたもので，同じ概念構造体が多くの異なる表現で表されるという点で抽象的であるが，それにもかかわらず，非常に正確で十分に詳細なものであるという．これによって，ソフトウェアの本質的性質は，複雑性，同調性，可変性，不可視性を持つと結論付けられる．
現代のより大規模・複雑化したソフトウェアシステムにおいても，Bmoksのいうソフト

ウェア実体の本質的性質は変わらない．ソフトウェア設計方法論の変遷は，このようなソ
フトウェア実体の特徴的性質に対面して，QCDにかかる市場の要求の変化やソフトウェアの利用方法の変化というエンジニアの置かれた状況に呼応している．歴史的に見れば，1968
年にNATO会議においてソフトウェア危機が叫ばれ，ソフトウェア工学の必要性が認識さESSaySeamanⅥ）1．14，No．6

れるのを期に，構造化分析・設計・プログラミング，オブジェクト指向分析・設計・プロ
グラミング，アスペクト指向プログラミングと徐々に以前の技術を基盤として発展してきている．

たとえば，構造化手法に関していえば，D毎kstraによる構造化プログラミング，JacksonによるJSDがある．より複雑性や再利用性に対処するためのオブジェクト指向法には，ShlaerとMellorのObject・0rientedSyStemanalySis，WhssermanのObject・0riented

StruCtureddesign，CoadとYburdonの00A／00D，RumbaughのOMT，Boochの00D，Jacobsonの00SE／Objectory，それらの統合した表記法としてのUMLおよび開発プロセスとしてのUPをあげることができる．
再利用性を考慮して様々なモデリングの粒度を捉えれば，フレームワークやアーキテク
チャ，コンポーネントという概念が生まれ，それらにおける典型例としてソフトウエアパ
ターンがあるのであろう．より上位レベルのモデリングからソフトウェア自動生成を考えれば，Model・drivenarchitecture（MDA）となり，MDAを指向した再利用性の向上はソフトウェア適用範囲を限定する一方で効率性を追及するDomain engineeringやSoftware
productlineにつながる．

また，開発プロセスという視点からすれば，一つの典型としてUPがとりあげられUse
CaSedrivenobjectmodelingということに成るのだろうが，Agilemethod／ⅩPやTbst−driven

developmentという方向性もある．クリティカルソフトウェアのようなより設計の完全性を追及する必要のあるシステムのためには，要求仕様の完全性や平行プロセスを含むような複雑な状態遷移を対象とした安全性を検査するFormalmethodsやModelcheckingの技術は必要となる．
与えられた要求仕様をどのように作るかだけでなく，顧客の必要とする要求を正確に捉えるための方法も必要であり，要求工学においてはGoal・Orientedrequirementsanalysis

やScenario・baseddesignをあげることができる．さらに，顧客満足度を向上させるためにはソフトウェア使い勝手を向上させるUsabilityengineeringへと対象は拡大されるのであ

る．

4．論点
SS2003における熊谷の問いかけは次の5つであった．「ソフトウェアの作り方は何から影響を受け変化するか？」，「現在多く使用されているソフトウェア開発方法にはどんなものがあるか？」，「コンピュータによる開発方法の支援は本質的か？」，「他の分野とソフト

Seama止Ⅵ）1．14，No．6

Es8ay

ウェア開発方法との関係は何か？」，「近未来のソフトウェア開発方法に求められるものは
何か？」
SS2004におけるパネルにおいて設定した質問は次の5つであった．「『設計方法論』の最低構成要素は何か」，「設計方法論の構成要素の適切なバランスとは何か」，「ツールは設計行為の何を効率化できるのか」，「概念モデリングにも『アーキテクチャ』は有効か」，「ソフトウェア開発における適切な抽象化の段階はどれほどか」，「ソフトウェア開発に必要な抽象化能力とは何か、またその能力はどのように訓練されるのか」

本パネルではこれらの質問を念頭に置き，自らの考えを述べ，ソフトウェア設計とは何かという本質的な問いに対し何らかの知見を得たい．
1．木村英紀，モノつくりからコトつくりへ一・一横断型基幹科学技術がめざすもの，設計工学シンポジウム講演論文集，pp．23・30，（2004）2．

藤本隆宏，r設計」概念と産業競争力，設計工学シンポジウム講演論文集，pp．79・84，（2004）

3．HASimon，TheScience80ftheArtificial（3rded．），MITPre88，（1996）（邦訳：サイモン「システムの科学（第3版）」パーソナルメディア，1999．）
4．

吉川弘之「一般設計学序鋭」精密機械Ⅵ）1．45No．8，pp20−26（1979）．

5．Kaknda，Y，Amathematicaldefinitionof8yntheticemergence，Proc．ofIWES

6．

99，pp13−20（1999）・

玉井哲雄，ソフトウェア工学の基礎，岩波書店，（2004）

7．F．PIBrookSJr．，TheMythicalMon−Month（20thanniversaryedition），AddiBOn・WeSley，（1995）（邦訳：ブルックス「人月の神話【新装版】−狼人間を撃つ銀の弾は無い・」ピアソン・エデュケーション，2002）

6

SeamailⅥ止14，No．6

E88ay

プログラミングと文章技法
玉井哲雄（東京大学）

以下は（株）日立製作所が実業出版株式会社と共同で発行している「スクールCOBOL
Report」という雑誌から依頼を受けて書いた原稿を，編集者の許可を得てはぼそのまま
SEAMai1にも投稿するものである．「スクールCOBOL」とは，日立が主に高校などの学校の実習で使われることを意識して製品化しているCOBOLのようである．その広報用にきれいな冊子を出していて，そこにこれまでも湯浅太一（京大），大岩元（慶大），黒川利明（CSE），

西村恕彦（元農工大），中田育男（法大），植村俊亮（奈良先端大），寛捷彦（早大）といった人達が，
大体プログラミングを話題にした文章を寄せている．依頼元は私の場合もそうだったが，いずれも元日立，現東京国際大の今城哲二氏であるらしい．
以下の文章がのった雑誌は，2005年3月に発行済みである．
1．3つのメタファー

ソフトウェア開発のメタファーとして，「書く」「作る」「育てる」のいずれが適切か，という議論がある．あるいは「記述」「工学」「育成」のいずれか，と言いかえてもよい．

歴史的にはまず「書く」があった．確かにプログラミングはプログラミング言語という人工言語による記述作業であり，一種の言語表現行為であるといえよう．プログラムをキーボードで入力し，あるいは視覚的プログラミング言語を用いてマウスによる図形操作でプログラムを作成する現在でも，「プログラムを書く」という表現は生き残っている．
バベッジの解析エンジンのためのプログラムを作り，世界最初のプログラマといわれる

エイダ・バイロン（ラブリス夫人）は，その作業を編み物を「編む」ようだと言ったという．
また，1960年代から70年代のプログラマは「プログラムを組む」という表現をよく使った．これはもしかすると「活字を組む」作業の連想ではないだろうか．とにかく，これら「編む」や「組む」というメタファーも，「書く」に近い発想である．
これに対して，「工学」として製品を「作る」のがソフトウェア開発だとする見方は，「書く」メタファーへのアンチテーゼとして出てきたものと言えるだろう．言語による記述とSeama且Vbl．14，No．6

E8Say

はあくまでも個人的な営みである．しかし工業製品としてのソフトウェアは，確立された方法論に基づき，組織によって系統的に開発されなければならない．すなわち従来の機械工学や電気工学と同じようなエンジニアリングであるべきだ，八七いうわけである．こうして1960年代末に「ソフトウェア工学」と命名された分野が誕生した．

しかし，ソフトウェア「工学」が伝統的な工学に追いつこうと努力を重ねるうちに，やはりソフトウェアというしろものは，機械やトランジスタとはだいぶ違うのではないかという疑念も生じてきた．ソフトウェアは抽象的であり，物理的な実体がないという特徴を持つ点で機械やトランジスタと違うということは，初めから分っていた．その上で，ソフ
トウェアには手を加えやすい，後から機能を追加することが日常茶飯事である，という性質のあることが強く意識されるようになる．機能追加ならよいが，もともと潜んでいる欠陥（バグ）を，運用に入ってから気づいて取り除くということもこれまた普通のことで，他の工業製品では考えられないことだが，このようなバグの修正も「保守」と呼ぶ．しかしこ
れも，ソフトウェアに手を加えやすいという性質の一面を示すものともいえる．
そこでソフトウェアは，全体の設計を一度にすませて丸ごと開発し提供するというよりは，少しずつ手を加え，機能を高め，使いやすくなるように「育て」ていくというメタフ
ァーが有効ではないか，という議論が生れてくる．そうして成長した大きなシステムの内部は，入り組んだ構造となる．それにさらに手を加えていくには，中がどう仕切られその間がどうつながっているか，どこに何が置いてあるか，というような生活的な知識が必要となる．そこでソフトウェアを家や巣に見立て，そこに「住む」あるいは「棲む」というメタファーを考えることもできる．これも家の修理，改築，増築を念頭においているという意味で，「育てる」に近い発想である．

筆者は昨年「ソフトウェア工学の基礎」という本を出し，日頃ソフトウェア工学を研究し教育している立場ゆえ，「工学」メタファーがもっとも適切といいそうなものであるが，実はこの3つのメタファーはいずれもある面の真実を表していると思う．中でも一番古い「書く」というメタファーは，いまだにその意義を失っていないと考えるので，ここからは話をそこに絞ってみたい．

2．文章読本プログラミングが文章を書くという行為に似ているとすれば，よいプログラムを書くにはよい文章を書く技術が参考になるに違いない．こういう考えは昔からあり，有名な文章作成法の本，ストランク＆ホワイト著一一The Element80fStyle一一（初版は1959年．現在第4版が出版されている）を下敷きとして，カーニハンとブローガの一一The Elements of8

E88aySeamanⅥ）1．14，No．6

ProgrammingStyle一．が書かれたことは，よく知られている．

しかし，これは英語の文章法の話をもとにした話である．日本人であるわれわれは，日本語の文章法を参考にしたほうがよいのではないか．筆者は，「文章読本」の類を昔からかなり読んできた．同じ文章読本という表題を持つ書物を，多くの人が書いている．たとえば，谷崎潤一郎，川端康成，三島由紀夫，中村真一郎，丸谷才一，井上ひさしといった作家達が出していて，これらをすべて愛読してきた．そこへ斎藤美奈子「文章読本さん江」（筑摩書房，2002年）という本が登場した．これは世の文章読本を並べてまとめて料理してみせようという，人が考えなかった企みで作られた書である．そこで取り上げられるのは作家達の文章読本だけでなく，清水幾太郎「論文の書き方」，木下是雄「理科系の作文技術」，本多勝一「日本語の作文技術」のような，文学的な作品より論文や実用文をどう善くか，というものもかなり含まれる．これらもまた，筆者はかなり読んできた．さらに知人が書いたもの，したがってプログラミング畑に近い人によるこの手の本を挙げておくと，

木村泉「ワープロ作文技術」，杉原厚吉「どう善くか−理科系のための論文作法」がある．
しかし，斎藤はさらにおびただしい文章読本・作文技術本を捜してきて，その徹底振りは驚嘆に値する．このように汗牛充棟の文章読本ものが共通に勧めるのは，・簡明に書け・起承転結を大事にせよ
・文のリズムを大事にせよ

といったあたりである．プログラミングにとっても簡明に書くこと，全体をきちんと構成
することは，もちろん重要である．文のリズムに直接相当するものはあるいはプログラミ
ングにないかもしれないが，モジュール分割の歯切れよさなどが思い浮かぶ．
また，文章の修練方法でだれもが挙げるのが・名文を読めである．よいプログラムを読むことがプログラミングの学習にとってきわめて有効である

ことは，多くの人が主張することであるが，それほど広く実践されてはいないようだ．すぐれたプログラムを鑑賞するには，それなりの読解力と審美眼を必要とする．しかし，プログラマが読まなければいけないのは，残念ながら名プログラムばかりではない．プログ
ラムの保守のためには，およそ駄作・愚作と思われるものも，動いて役に立っている以上，読んで理解する必要が生じうる．その場合でも，読む力が高ければ作業の効率は増す．さ9Seama止Vbl．14，No．6

E88ay

らに審美眼があれば，そのプログラムをどう書き直すべきかという指針も自ずから生れてこよう．

3．文芸とプログラミング
ちょっとこじつけ臭いと思う読者もおられよう．しかし，プログラムは計算機が読むものでコンパイラに通りさえすればよい，というものではない．やはり自分自身も含めた人
間が読むものでもある．それを強調したのが，ドナルド・クヌースのLiterateProgrammingである．これは文芸的プログラミングと訳されたことがあったが，ここでいうlibrateは「人が読める」というほどの意味ではなかろうか．もちろんそれには，人が読んで楽しめる，鑑賞できる，というニュアンスが含まれているから，「文芸的」というのもあながちおかし

くはないかもしれない．で，「文芸」であればまさに「文章読本」の世界ということになる．
クヌースには聖書についての著作もあるし，小説も書いている．しかし文学に造藷の深い計算機科学者はクヌースばかりではない．チューリング賞受賞者のトニー・ホアも，ジャクソン法で著名なマイケル・ジャクソンも，ともにオクスフォード大学の文学部の出身である．かつて筆者はマイケル・ジャクソンの著書を翻訳する機会があったが，イギリス文学が縦横に引用されるので苦労した．とくにすでに古典となっている文学作品の場合，書名や登場人物の表記には定訳があるだろうから，勝手なものをひねり出す訳にいかない．
幸い，筆者の勤務先の同僚にディケンズ研究者がいて教えを乞うことができた．
別にプログラマに文学の素養が必要だと言いたいわけではない．しかし，プログラマが書かなければならないのはプログラムだけではない．仕様書，マニュアル，解説書，報告書など，書くことを要求される文書は山ほどある．それを書くのに，簡にして要をえた文章をものす力は，やはり必須のものだろう．

10

MeetingReport

Seama止Ⅵ）1．14，No．6

DebianMimi−Conf2005／CodeFeSt2005報告〜ちょっとに北京に行って来ました〜鈴木裕膚

（フリーソフトウェアイニシアティブ）
1．はじめに2005年2月28から3月3日まで北京で開催されたDebianMini・Conf2005（2／28・3／1）とCodeFest2005（3／1・3／2）へ参加してきました。備忘録がわりにランダムに書いていきます。

この旅は、「花粉だらけの日本を抜け出す」ということではなく、ちょっと真面目に次の2点に関してチェックを入れてこようかと思ったからです。
（1）運営状況のチェック（2）CJK圏での草の根的活動の動向チェック

第一点目は今後FSIJがアジア圏内で協力をどうすべきなのかの考慮材料とするためのものです。北京で開催される草の根ボランティアの運営状況を観察することで、同様な趣旨の会合をわれわれが開催する時に参考となるでしょう。そもそも、アジア圏内でこのようなボランティアベースのカンファレンスが開かれることは、滅多にありません。日本以外の国ではどう対応しているのか観察するのには、よい機会だと考えました。
第二点目は、アジアのCJK圏内の草の根レベルの活動の動向を調べることです。国ではなく意図的に言語圏で区別しています。中国語圏（中国／台湾／香港）の経済規模は、既にかなり大きいことを認識しなければなりません。2003年のGDP比較で比較すると、中国語圏の経済規模は日本の約4割強になります。経済規模的にはかなり大きなマーケット
だといえます。しかし、これまでCJK匪lでのLinuxの状況は，政府や企業の観点からだ

け語られてきており、草の根的な情報は，きわめて断片的な形でしか上がって来ていませんでした。今回は、ボランティアベースの内容を知るには絶好のチャンスでした。

2．概要
2月27日から3月4日までの期間，中国政府は，中国OpenSourceWeek2005という

ことで、

11

MeetingReport

Seama止Ⅵ）1．14，No．6

AsiaDebianMini・Conf2005（2／28・3／1）
AsiaCodeFest2005（3／1・3／2）

The5thAsiaOpenSourceSoftwareSympoSium2005（3／2・3／4）という3つの会合を主宰しました。実行委員長はRogerSoというDebian方面ではよく知られている人でしたが、私はDebianな人ではないので、その辺はよくわかりません．オーストラリア出身で現在は香港にいるとのこと。
会場はADMC2005とAOSSS2005が、北京市内にある北京新世紀日航飯店でした。
CodeFest2005は、北京郊外にある中国のシリコンバレーこと中関村ソフトウェアパーク

の国家応用軟件産品質量監督検査中心でした。そこにあるビジネスコンプレックスのビルの中に入っています。このビルにはベンチャー企業のオフィスやインテルなど有名企業のブランチも入っていました。

なお、3月2〜4日に開催されたThe5thAsiaOpenSourceSoRwareSymposiumには、筆者は参加しませんでした。理由は、この会は各国から政府と業界が集まるPoliticalIsSue

な内容の会議なので、参加するだけ時間の無駄だと思ったからです。

以下はAsiaDebianMini・Conf2005のスケジュールです。

Dayl：（Monday，28February2005）

09：00・09：30

Registration

O9：30・09：45

ⅥねlcomeO9：45・10：45

TbwardSaSystematicQualityAssuranceApproachinDebian・MartinMichlmayr
lO：45−11：45

HowTbHelpDebianWithoutDeeperKnowledge
・AlexanderSchmehl

ll：45・13：15

13：15・14：15

Lunch

StatusReportofDebianinTaiwan

・AndrewLee
14：15・15：15

RAYSinstaller・・aCuStOmizeddebian・installer−StanleyPeng
15：15・15：30

Break

15：30−17：00

Key・SigningSession

12

SeamailVbl．14，No．6

MeethgRepo鵬

Day2：（Tuesday，1March2005）

09：00・10：00

CuStOmDebianDistributions
・AndreasTille

10：00・11：00

MaSSManagementOfI）ebianDesktops
・ScottDier

11：00・12：00

SearchingandCJK・TakatsuguNokubi

12：00・13：30

Lunch

13：30・14：30

TheDebianLinuxKernel
・SimonHorman

14：30・15：00

TheLinuxPublicPlatform
・ⅥねiChen

15：00・15：15

Break

15：15・16：15

BootStraplngtheM32RAnchitecture
・％kataNiibe

16：15・17：15

TheManyUSe80fApt・Listbug
・MasatoTaruishi

17：15−17：30

日本からの発表者は、Closing

産総研・FSIJ理事長のg新部裕氏、凸版印刷・FSIJの野首貴嗣

氏、VALinuxの樽石将人氏の3人でした。ADMCとCodeFestの日本人参加者は全部で10名でした。Debianの中心人物であるMartinMichlmayrらがドイツから招かれていました。

メインスポンサーはDebianベースの商用DiStributionを開発している新華科技（南京）系統軟件有限公司です。RogerSoはここの会社の香港ブランチに勤めているとのこと。日
本企業であるm Dataもスポンサーとなっていました。他に日本の組織が1つ。これはスポンサー名に名前が出ていませんでしたが、産総研です。会議の実態はといえば、中国
OpenSourceWbekの一環として開催されたという運営方法ではなく、いつものDebian

Confの規模の小さいものをこのタイミングで行ったという感じでした。このタイミングに会わせたのは新華科技が中国政府へのアピールするためではなかったかと考えられます。

http：〟www．swhss．com．cn月p／13

MeetingReport

SeamanⅥ）1．14，No．6★ADMC2005

http：〟debian．org．cn／en／events／admc2005

スクール形式で40名程度の部屋を使っていましたが、後の方に椅子席をずいぶん追加していたので実際には60名以上の参加者がいたと思います。登録は80名ぐらいだったということです。
Debianメンバーのプレゼンテーションは、主にDebianとは何かという初歩的な内容でした。どの内容も基本的なというか、導入的な話題と紹介を中心にしていたので、内容的に特にこれはといったものはありませんでした。

私が一番面白かったのはTheLinuxPublicPlatformの時に出た質問です。プレゼンの内容は、中国政府が御墨付で開発しているLinux関連の状況紹介でした。Dr．WeiChenが、

いやにテンションの高い演説口調でプレゼンを行いました。超早口の中国語、間違わない、
よどまない。「あなた100回はそのネタ話していませんか？」という感じで、ほぼ30分間

スピーチが続きました。立て板に水というのはこのことでしょう。内容的には、中国政府
もいろいろ開発支援に力を入れているという事実をアピールしたものでした。質問の時間がきてすぐに、広東省の公営Linuxセンターから来たという高級工程師（シニアエンジニア）の人がばっと手をあげました。
「unuxの開発はコミュニティとの関わりが大切である。そうやって国の支援で開発した

コードはどのようにコミュニティに還元するのか？」
これには思わず、g新部氏と筆者は拍手し、親指をたててGoodJob！

と声援を送りました。質問を受けた側は「100回このネタを話したが、今まで、こんな質問は一度として受けたことはない！」みたいな顔をしています。ようやく返ってきた回答は役人的なものでしかありませんでしたが、まあ、それは仕方がない。しかし「コミュニティへの遼元」と真面目に突込みを入れる姿を見て、中国も上意下達でやっているのではなく、本当の意味
での草の根的な広がりが出てきているのだな、と感心しました。
3．セッションの合間に

今回のADMC2005は、所詮は中国におけるDebianの顔見世興業でした。プレゼンの内容はあまり重要ではありません（プレゼンした人ごめんなさい）。重要なのは、アジアCJK
圏の有力なDebianデベロツ／iがFace to Faceでコミュニケーションできる機会を持った

14

MeethgRepo鵬

SeamaⅡⅥ）1．14，No．6ということです。ですから、セッションの合間や、セッション後が最も重要な時間です。
今回私は特定非営利活動法人フリーソフトウェアイニシアティブの最高執行責任者という肩書で参加していたので、台湾と香港からきたコミュニティ組織運営に携わる人たちといろいろと話しました。

香港は、せっかく立ち上げようとしてもスポンサーがみつからないという問題があるようです。何かイベントを企画しようにも、先立つ資金が集まらない。香港という土地柄は流通ばかりで生産がないため、開発への投資がない。そうした状況でスポンサーを集めよ
うと思っても、どうにも集まらないという話です。中国にしても、台湾にしても、開発を行っている企業があるので、その流れでスポンサーを集めることはできる、しかし香港はそれがない。開発のために畑を耕す必要も種を撒く必要もないというのは、いかにも香港らしい悩みでした。
台湾は、愛好者的ユーザ会が多く、個々の活動が小さく閉鎖的な傾向にあるというのが問題なようです。そこそこに資源や資金を投入（といっても個人負担できる程度ですが）できるので、小さなコミュニティ活動には支障がない。一方、個人の趣味をちょっと大き
くした程度のコミュニティでは、活動自体を大きく発展させていくことができない。こじんまりとやっていれば、そこそこにユーザ会は回り、それなりのおもしろさ（個人的興味の充足）が得られる。しかし、さらに規模を大きくしようとすると、組織化のための労力が必要で、趣味の範囲を越えてしまう（つまらないことが多くなる）ので、やっぱり小さなままでいようとする力が働く、といった状況のようです。そこそこに満足できているという贅沢な悩みが、この間題の底流にはあり、それは日本の状況とよく似ています。

中国本土の人の問題は「英語をまともに話せる人間が見当たらない」ことでしょう。台湾人、香港人は，ちゃんと欧米の人たちとコミュニケーションができるのに、あの名門！
清華大学の学生でも、その英語たるや，何をいっているか全然わからない。ちなみに去年
アメリカで開催されたCmTO2004でセンセーショナルな発表をした山東大学の助教授も同じだったことを思い出します。私の回りにいる中国本土出身者はみんな英語がうまいのにどうしてでしょうか？

また、積極的にコミュニケーションしようという姿勢がないという姿勢も問題だと思われます。自国の中で閉じていても独自でやっていけるから、苦労して国際的なコミュニケーションをする必要がないということなのでしょうか。よくわかりませんが、このコミュ
ニケーションの問題は、日本とよく似ているように感じました。

15

Seama止Ⅵ）1．14，No．6

MeethgReport

韓国については、少なくとも今回私は、韓国からの参加者と話をする機会がなかったので、よくわかりません。
ADMC2005だけではなく、日本での会議もそうですが、アジア圏のカンファレンスに参加して思うことは、ソーシャルプログラムが弱いということです。お互いが集まって情報交換することがこの種の集まりの主目的であるという意識は、まだまだ薄いように感じられます。つまりリストアップすれば次の通り：− ソーシャルプログラムがきわめて重要なのに貧弱である
一

前日に簡単なウェルカムパーティがあればよかったな− レセプションも前後の時間に余裕が欲しい
一

昼食も前後に時間的な余裕が欲しい

4．大陸中国的時間尺度

勝手に私はCTSP（ChineSeTimeScaleProblem）と呼んでいました。ADMC2005初日

夜のレセプションではペキンダックのレストラン店に行きました。レストラン自体はとてもよかったのですが、そこまでの移動が大変。ホテルからバスで移動したのですが、まず、バスが来ない。結局1時間ぐらい遅れてやっと到着しました。CodeFest2005の会場に向かうバスもそうでした。集合時間はあってなきがごとし。噂に聞く中国時間です。集合時間
ぴったりに集まるのは日本人とドイツ人のグループだけでした。さらに、観光スケジュー

ルとかも、行きあたりばったり。レセプションの後で、夜の天安門まで観光に出たはいいのですが、そもそも、天安門は夜間は閉鎖されています（そりゃそうだよな）。北京のくそ寒い夜気の中、天安門の周辺を流浪するしかない。翌日も同じようにトライして、やっぱりダメでした。
他の日本人が不満をぐちる中、私自身はこのいい加減さ、時間のルーズさ加減はぜんぜん苦になりませんでした、むしろ馴染んでいるくらい。私の中の大陸的な北海道人の血がそうさせているのでしょうか。ただし、北海道人なので寒さには弱い。正確にいえば、寒くてもいいけれど、ちゃんと室内で身体が温まる所がないと幸い。実は、北京ではこれが一番辛かったです。

5．CodeFe8t2005

ハッカーが集まってみんなでプログラムをしよう！FacetoFaceで相談しながらやればあっというまに問題解決さ！という主旨の集まりです。こちらの方は、私自身は、敵状視

16

MeetingReport

Seama止Ⅵ）1．14，No．6

寮が主目的だったので，自分の手でコードを書く予定はありませんでした。

朝8時30分が集合時間。でも出発したのは9時30分近くになってから。バスに30分
ちょい揺られます。幹線道路の広告パネルにはAMDやVIAの広告が延々と続きます。中国では「この通り全部」とかバルクで広告を売っているんだろうか？
さて、清華大学の前を通って、着いたのは中開村軟件園贈化器という建物。周囲はつくば学園都市のような感じで、のっぺらぼ−な敷地に、モダンな建物がぽつぽつあるという風景。まわりには立派なレノボのキャンパスがあったり、中開村軟件固形化器の別の棟には甲骨文（Oracle）が入っていたりしています。同じ建物の中には、IBMRationalSoRware

軟件工程技術実験室という看板をかかげている部屋などがありました。
コンピュータ教室をCodeFestの会場に使いました。席数（PC数）は35。といっても、参加者のほとんどは自分のノートPCを持参し、それで開発しているので、あまり関係ありません。一応、入口付近には立派なCodeflest2005のスケジュールが掲げられていたのですが、あまり関係なく、一度部屋に入るとあとは自分のペースで作業を進めていきます。
PCには新華科技のRAYLEというディスクトップ用Linuxが入っています。参加者はrootのパスワードをもらって使えます。私は開発をする気がなかったので、自前のハード
ウェアを持参せず、ここのLinux環境を使わせてもらいました。

g新部氏がM32Rのハードウェアを持ち込んで組み込みをハック。半田さん（m17n．org）と守岡さん（CHISE）は多言語ライブラリをハック。ark・田中さん（ruby・dev）はRuby本体をハックと、それぞれ思い思いにハッキングしています。
まあ暇潰しにと、自分の作品であるサーバプログラムをOpenPKSD．ORGからダウンロ

ードしてインストールしてみました。ところが、思いのほか簡単にインストールできずに悪戦苦闘。自分のインストールマニュアルに追加事項やトラブルシューティングを書き始
めてしまいました。こんなはずじゃなかったのだけど…
小一時間もすると11時30分になり、混まないうちに社員食堂にいって早めの昼食。ビュッフェスタイルで、もちろん、いうまでもなく中華です。麺類のコーナーでは、刀削麺を目の前で作っています。私は、いろいろプレートに盛り付けて、ガツガツ食べましたが、社員食堂だと考えれば、けっこう美味しかったと思います。毎日食べてもOKです。

さて、部屋に戻り、今度は、サーバが実際に動くかどうかのチェック。うまく動いて一

17

MeetingReport

Seama止Ⅵ）1．14，No．6

安心。でも、それだけではつまらないので、鍵の登録を若干早くするためのハックを開始。
「ほんとうは視察だけで、午後からは一人で市内観光する予定だったのになあ」とか思いつつ、プログラムのパフォーマンスのチューンをしている自分がいました。

ここで日本人約1名リタイヤ。来た時から体調が悪く休憩室で寝ていたのですが、体調は回復せず、残念ながらタクシを呼んでもらってホテルに帰りました。後で病院へ行って対処してもらったようです。ホテルに帰ってから電話をした所、急性胃腸炎だという診断だったそうです。病院で点滴を打ってもらい回復し翌日無事日本に戻られました。
気が着くと、すでに夕食の時間。残業食を出しているので、そこでまた食事。帰ってくると「夜食のために」と大袋リッツクラッカー、カップ麺、そして6本入ソーセージが主催側から配布されました。このソーセージは、日本の魚肉ソーセージではなく、鳥・豚・牛の肉を使っているので、全然味が違います。これまで中国圏で口にしたもので食べられないものはありませんでしたが、唯一これは例外でした。

また、ふと気が着くと、既に8時を回っているのではないですか。ちょっとやるだけだったのに。ちなみに、他の参加者は会場で徹夜です。寝袋と休憩室が用意されているので、寝ることもできます。「みんながんばれ！私は帰るけど」。残業帰りの客待ちしているタク
シーが何台もメインゲート前に止まっているので、それに乗ってホテルへ戻りました。29

元。
気がついた点を箇条書きにすると次の通り：− やっぱり自分の開発環境を持って行くべきだった− 作業場所は、もっと自由に使えるタイプの方がいい− 海外への高速ネットワークはMUST− 24時間以上ぶっ続けなので深夜の飲食が大切− ちゃんとした休憩場所の確保− シャワーがあるとハッピー

ー 病気の人が出た時のためなどホスピタリティスタッフの確保
一 最初の1・2時間は、方向性やグループを作るためのディスカッションをすべき
一

来る前にWikiで企画をたてておこう

一

来てからもWkiで情報交換しよう

6．雑感・まとめ18

SeamailⅥ）1．14，No．6

MeethgReporL

今回は、中国で始めてのユーザ側から立ち上げたオープンソース関連のカンファレンスだったので、様子見の雰囲気もなきにしもあらずだったのですが、小規模な会議とはいえ色々な人が集まったので、なかなか面白かったです。ただADMC2005に韓国からの積極的な参加がなかったのは残念。

香港、台湾にはアクティブなデベロツパがいることをあまり知らなかったので、今回、それが大きな収穫でした。中国でも、われわれの感覚と同じようなセンスを持った人たち

が草の根的にはいるんだなあと、少しうれしく思いました。
AsiaOpenSourceの方はアジア圏内の各国から政府からの御声がかかりの参加者が会議をしていたみたいなのですが、まあ、かんぼってくださいということで。
ADMC2005によってアジア圏内の草の根レベルの交流は、確実に第一歩を踏み出したのではないでしょうか。ⅥSA問題があるので，中国人に参加してもらうということを考えると、中国国内で開催するのがベターというのはわかるのですが、しかし、3月の北京はあまりにも寒いので、もう勘弁してほしい。次回はぜひとも暖かい広州あたりで・！・
追記

北京の首都国際空港の正規のタクシー乗り場で、ちゃんとディスパッチャーに従って乗り込んだタクシーが白タクでした。国の表玄関で規則正しく乗り込んでいるのに「それはいくらなんでも反則だろう」です。案の定、請求金額は予想の倍ぐらいふっかけて来ました。国の代表的な空港にもかかわらず、ライセンスなしのタクシーが待つことができるタ
クシー乗り場があるというのは、世界中でここだけじゃないでしょうか。うーむ・市場の自由化だ（ちがうって！）。

19

Meet血gReport

SeamaⅡⅥ瓜14，No．6

17thSEPGConference2005参加報告

新谷

勝利

0m・SEC）

1．コンファレンス概要
1）会期・場所：2005年3月7−11日
＠Washington State Convention Center，Seattle

2）参加者数（全体合計：1800名）
一日本からは30名弱
一韓国からは30名強−インドおよび中国からも多数

3）セッション

ー以下のトラックにて10時半から17時まで並列発表（全体合計：106）−プロセス改善：32−特別セッション：8−CMMI：31−TSP／PSP：19−測定と分析：16−基調講演が2日目、3日目の朝8時半から10時までそれぞれ2セッション、計4−全体的な印象SEPGはプロセス改善を目的とする専門家集団あるいは組織を意味する．しがたってれぞれの体験・経験・知見を共有するセッションが一番多く、具体的なツールであるCMMIそのものに関するものがはば同数。プロセス改善への「人の動機付け」の観点からTSP／PSP、「データによる裏付け」の観点から測定と分析のセッションが準備され、セッション選択に当たっても全体的に統一された観点からできるように配慮されていた。

2．参加したセッションからの報告
2・l・RelectiononProce88lmprovement（JolmⅥ1，Boeing）

So氏wareIndustryBenchmarkingStudy2001を引用しながら現状を説明すると

ともに提案

20

MeetingReport

SeamanⅥ）1．14，No．6−なぜプロセス改善活動は失敗するか？

−「評価−＞改善」の順になされるが、「評価」そのものを強調し過ぎ
一明確な方向性および測定目標無しに、「成熟度」のみに焦点を当てる
一改善活動を推進する知見ある体制の欠如

一次から次へと世間で語られる「用語」と自分の現場との差に関する混乱一改善活動が適切に管理されていない＊ 失敗していることを示すベンチマーク
ー評価した後に、72％が改善の成果に結びついていないと報告

一改善活動にとりかかった組織の内、83％が3年以内に改善活動破棄
一上記活動破棄組織の内、57％がその後に再開

一改善はうまくいっていると称する組織でさえも、データと共に説明できるのは1％にも満たない−多くの組織において、「ある成熟度を達成」することのみを目標とし、それを達成すれば「問題が全て解決する」と誤解。
＊ 仮に「成熟度」達成を外的刺激として改善活動をするとしても、バランスス

コアカードで定義しているようなビジネス目標を達成することにどのように寄与しているかが説明される必要あり。

−ソフトウェア開発プロセスにおけるワークロード配分は、要求分析に5％、設計に10％、実装に40％、等となっているが、欠陥の発生源をしらべると、要求分析から45％、設計からは25％、実装からは15％、等となっている。長い間よく知られ、しかし、有効な対応策の適用が困難。
＊

個別のプロセスの改善というより、プロジェクト・組織全体にPSP／rSPを導入することにより、当該チームの次のリリース全体でプログラムの大きさが2．36倍になったにも関わらず、欠陥数は75％も削減＊ プロセスそのもの改善というより、「人」を如何に動機付けさせるか−IEEESo氏wareInduStryBenchmarkingStudy2001からの結論：−プロセス改善に取り組んでいない企業の内、80％は2006年までに倒産するか危機に陥る−（「組織成熟度」ではなく、）「プロセス能力」のレベルを上げられない企業の内、80％は2007年までに少なくとも開発予算の50％超過に陥る一組織が今後管理の対象とする5つの項目の提案

21

MeedngReport

SeamaⅡVbl．14，No．6−プロセス改善が実際のビジネス目標にどのように寄与？

一標準のプロセスに準拠している（していない）プロジェクトはどれ？

一標準のプロセスが個別のプロジェクトレベルに活用され効果を出しているか？

−日々の意思決定が適切な測定値をベースになされているか？

−ビジネス目標に優先位が設定され、グループ間衝突は回避されているか？

2．2．TheGreatMyth8AboutTSPandCMMI OimMcHale，SEI）−TSPとCMMIは、同時に実践できない−CMMIはモデルであり、TSPはプロジェクトレベルのプラクティスの集合で、CMMIが対象とするプロセス分野の殆どをカバー
ーTSPはモデルではないので、CMMIと矛盾せず、モデルとしてのCMMIからマッピングされるプロジェクトに参加するスタッフのプラクティスを計画
化するのに有効−TSPを実践するためには、現行のプラクティスを捨て去らなければならない−TSPチームは、以下をベースにチーム独自のプロセスを定義

一組織の標準を含む現行プラクティス

ーチーム員が「より効果的な仕事のためには、こうしなければならない」と考える方法
一上記の組み合わせ−3つの運用レペル

ーCMMI：組織としての能力向上のために−TSP：経費とスケジュールを考慮した高品質の製品開発のために−PSP：各人のスキルと規律を高めるために−TSP導入は難しすぎる−AnIntroductiontotheTbamSoftwareProcesS，Humphrey，2000）に説明されている用紙とその使用ガイドの多さからのコメント。しかし、−21説明ガイドー繰り返し使用されるものは7つに過ぎない−51ページの用紙−4〜5種類の用紙が定期的に使用されるに過ぎない−TSPを実践するためには、成熟度レベルXでなければならない
一TSPを初期導入するチームの多くは、（モデルに準拠していない）というレベ
ル1−実績を見ると、どのレベルからでもTSPの初期導入はされている
一TSPは十分アジヤイルではない

22

MeetingReport

Seama止Vbl．14，No．6−BalancingAgilityandDiscipline，Boehm，Turner，A・W2004によれば、アジ

ヤイル度評価においてⅩPとTSPは中程度で隣り合っている−アジヤイル信奉者の多くが、アジヤイル手法においてプロセス記述が簡略化されていることをカバーするためにプロセスに関して卓越した知識・経験を持つ人が必要であることに気付いていない−我々はTSPを導入するには大き過ぎる−TSPはプロジェクトレベルのプラクティス
ーCMMIは、プロジェクトを越えてより広い組織として、標準とデータに基づ

く管理を実施するために記述したもの−どんなプラクティスも、そのサイズに関係なく組織に応じた解釈がなされ、導入される必要あり−TSP信奉者はレベルをスキップする−TSPは成熟度レベルに関しては言及しないし、TSP信奉者はプロセスを目的と測定可能性で議論−レベルをスキップするということは組織評価に関連する表現であるが、TSP

はプロジェクトレベルにおいて導入
2．3

Le880nSLear眠dfronAdqptingCMMIforSma皿Organi2：ation8

0ackConway；

ASI＆SandraCapeda，CSSA）−Huntsvilleにある25〜250人の中小企業を対象にパイロットー2003年8月〜2004年4月における投入時間と経費

チーム会議

718時間（37％）＄52K（38％）

電話会議

520時間（27％）＄37K（26％）

プロセス定義200時間（10％）＄16K（11％）訓練：
導入：

84時間（4％）＄6Ⅸ（4％）

183時間（9％）＄13K（10％）

評価準備：

132時間（7％）＄9Ⅹ（6％）

評価：

104時間（5％）＄7K（5％）

合計

1941時間

2．4．Adopting So氏ware ProductLines‥

Getting

Improvement（LindaNorthrop，SEI）

23

Leveragefrom1mur ProceSS

MeetingReport

Seama止Ⅵ〉1．14，No．6−CMMIのレベルが高くなれば、「再利用」の比率が高まっていることは調査の結果分かっている。
−Product Linesは「戦略的な再利用」と位置付けられ、ライフサイクルの早い段階で再利用を取り入れればその効果は大きく、以下の分野における「コア資産」に対する投資を活用
一要求分析−ドメインモデルーソフトウェアアーキテクチャーと設計
一効率を上げるためのエンジニアリング
ー文書化
−テスト
ースタッフ

ープロセス

ー部品
−プロセス改善活動がProductLinesの導入の基礎

CMMIプロセス分野に対応するプラクティス分野を定義

24

名

ソフトウ土7技術者協会〒160東京都薪膚区四谷3−12丸正ビル5F¶≡」03−認詭−10Trl執X．03−3356−1072