解説

実証的ソフトウェア工学環境への取り組み
近年，ソフトウェア開発に関するプロセスやプロダクトのデータを収集，分析し，改善を行うという実証的ソフトウェア工学の研究や実践が盛んになってきている．本稿では，実証的ソフトウェア工学の意味や動向を紹介する．また，文部科学省のリーディングプロジェクトの 1 つとして，実証的ソフトウェア工学の実践を支援する環境の構築を行っている EASE プロジェクトについて概説する．EASE プロジェクトでは，開発時のデータを収集し分析して開発者や管理者に提示するシステム EPM を構築している．EPM を用いることにより，対象となる組織のプロセス改善を少ない手間で効果的に行える．

井上克郎 *1 松本健一 *2 鶴保征城 *3 鳥居宏次 *4*1 大阪大学 inoue@ist.osaka-u.ac.jp*2, 4 奈良先端科学技術大学院大学 *2 matumoto@is.naist.jp *4 torii@is.naist.jp*3 独立行政法人 情報処理振興機構／高知工科大学 tsuruho@ipa.go.jp■ソフトウェア開発の現状と工学■

は，非常に不安定であり，事故と隣り合わせである．
では，ソフトウェアの分野はどのような状況なのだろ

現在，システム構築の遅延や予算オーバーの問題に悩うか．ソフトウェアの信頼性，生産性は，いわゆるソフ

まされていない SI 会社やソフト会社は皆無だと言ってトウェア工学という分野で研究され議論され続けているも過言ではなく，場合によっては経営の屋台骨を揺るがが，従来のソフトウェア工学は，方法論やツールを個別しかねない状況になってきている．顧客の要求が明確でに提示していたに過ぎない．社会や生活の隅々にまで入ない，カットオーバーまでの期日が短い，技術の進展にり込んだ巨大システムの構築を支えるには，あまりにも対して人材の育成が追いつかない，等々の問題がボディ脆弱な状況で，これが，現在多くの会社を直撃しているブローのようにシステム構築に大きな影響を与えていソフトウェアシステムのトラブル多発の要因と言えよう．

る．これらの条件は，今後ますます厳しく，難しくなる

本稿では，実証的ソフトウェア工学の研究動向を紹介ことはあっても，緩和される見込みはない．

し，それを推進する EASE プロジェクトについて述べる．

エンドユーザにとっても他人事ではない．システム構築の失敗が経営を直撃するのは，銀行システムの例を持ち出すまでもなく明らかである．ベンダ，ユーザにおけるこのような背景が，実証的ソフトウェア工学への大きな期待になっている．

■実証的ソフトウェア工学■
ソフトウェア工学
ソフトウェア工学は，1968 年に NATO の科学委員会でそもそも，どのような産業にも基盤となる工学があり，初めて用いられた言葉で，ソフトウェアの生産や品質に当然のこととして実証的・実験的（エンピリカル）アプ関する技術の総称として用いられている．今までに数多ローチがなされている．たとえば，構造物の材料の質･くのソフトウェア工学にかかわる技術（手法，ツール，量をどの程度落とせば，強度がどの程度落ちるのか，実方法論等）が提案されてきている．しかし，それらの中証的に明らかにされており，このような知見をベースとには，提案されるにはされたが，しばらく時間がたつとすることによって，企業は安心して限界ぎりぎりまで，誰も使わずに，忘れさられてしまうものも多い．工学と生産性向上やコスト削減に邁進できる．

呼ぶにはふさわしい積み上げもあまりない．

しかし，工学が確立されてなくても，構造物は作られソフトウェア工学の分野では質，量ともに最大であるてきている．たとえば，橋が比較的低速の風による振動

ソフトウェア工学国際会議（International Conference onで崩落するという事象は，1940 年の米国 Tacoma Narrows

Software Engineering：ICSE）
では，このようなソフトウェの事故以降解明されたが，それ以前のものは，破壊の危アに関する技術を評価する 1 つの試みとして，発表され険に常に曝されていた．工学に立脚せずに構築された物

る論文の評価をその時点で行うのではなく，10 年後に，

722

45 巻 7 号

情報処理2004 年 7 月

解説

実証的ソフトウェア工学環境への取り組み ■■実 証 的 ソ フ ト ウ ェ ア 工 学 国 際 会 議（International収集

Symposium on Empirical Software Engineering：ISESE）は，3 年目を迎える新しい実証的ソフトウェア工学に関する国際会議で，毎年 100 〜 200 名の参加者を企業や大学か分析

改善ら集めている．
また近年，いろいろな所で，実証的ソフトウェア工学

図 -1 工学におけるデータ収集・分析・改善モデルを専門に研究する組織が設立されてきている．
Institute for Experimental Software Engineering（IESE）はドイツの Fraunhofer 財団が作る実証的ソフトウェア工学最も影響を与えた論文（Most Influential Paper）として表の研究機関で，ドイツの東部の Kaiserslautern にある．現彰する制度を設けている．たとえば，2003 年の第 25 回

在 100 名余りの研究者がおり，大学と企業との研究連携，会議では，1993 年に開催された第 15 回大会の発表論文人材育成の場となっている．また，米国の Maryland 州の中から，要求仕様における複数視点に関する論文が選にも分室があり，20 名程度の研究員が在籍している．

1）

ばれている ．ソフトウェア技術は，直接の評価が困難

日本では，経済産業省のもとで，ソフトウェア工学セなため，長期間に渡る社会に対する普及度，影響度を調ンター（SEC）が間もなく設立され，実証的ソフトウェアべて間接的に評価しているのである．しかしこのような工学がその活動テーマの重要な 1 つとなる予定である ．

2）

悠長な手法では，現在のソフトウェアシステムに対する■ EASE プロジェクト■

社会的な要望に応えられないのは明白である．

実証的ソフトウェア工学

e-Society 産官学連携プロジェクト

通常，工学の多くの分野では，図 -1 のように，何か

平成 15 年度より始まった「e-Society 基盤ソフトウェア

新しい技術の提案が行われれば，まず，それが優れていの総合開発」
は，文部科学省が行うリーディングプロジェるものかどうかを評価するために，データの収集が行わクトで，世界最高水準の高度情報通信システム形成のたれ，定量的や定性的に分析される．さらにその分析結果めの鍵となるソフトウェア開発を実現させ，いつでもどに基づいて，技術の改善が行われる．

こでも誰でも安心して参加できる IT 社会を構築するこ
3）

ソフトウェア工学の技術に関しても，他の工学分野ととを目的としている ．この e-Society のもと，10 のプロ同様に，短期間かつ直接的な評価が行われることが望ま

ジェクトが 5 年計画で行われている．これらのプロジェれる．ある新しい技術が提案されても，それが本当にソクトでは，既存の大学的な研究ではなく，日本の産業育フトウェアの品質や生産性の向上につながるのか，きち成や活性化のキーになる成果を求められている．そのたんとした科学的な評価がなければ，現場に適用することめには，産官学の連携を推進し，企業や大学が単独ではは躊躇される．逆に説得力ある評価結果が示されれば，行いにくいソフトウェア開発を行い，作成したソフト積極的に導入しやすい．

ウェア製品を社会に広く流布させることが必要である．

このような考えに基づいて，ソフトウェア開発に関

e-Society の 1 つとして我々は「データ収集に基づくソするデータの収集を行い，その定量的（または時には定フトウェア開発支援システム」，通称 EASE（Empirical性的な）分析を行って，ソフトウェアの品質や生産性のApproach to Software Engineering）プロジェクトを推進し改善を行うことを，実証的ソフトウェア工学（Empiricalている ．

Software Engineering）と呼ぶ．

実証的ソフトウェア工学に関する動向
実証的ソフトウェア工学は，今までも通常のソフト

4）

EASE プロジェクトの目的
EASE プロジェクトでは，以下のようなことを目指している．

ウェア工学に関する雑誌や国際会議の中でも断片的に議

1. エンピリカルソフトウェア工学の研究と実践を行うた論されてきているが，近年，専門の雑誌や国際会議がでめの基盤として，ソフトウェア開発にかかわる種々きつつある．のデータの収集・分析・改善を行う開発管理支援シ

Empirical Software Engineering Journal（ESE）は，Kluwer社から年 4 回刊行されている国際学術誌で，厳密なデー
タ分析，評価に基づいた数多くの実証的ソフトウェア工学の論文が掲載されている．

ステム「実証的ソフトウェア工学環境 EPM（EmpiricalProject Monitor）」を構築する．
2. EPM を広く配布し，多くの開発現場で利用され得るように種々の支援を行う．
IPSJ Magazine Vol.45 No.7 July 2004

723

�

し，会社全体の改善につなげていけるようなアプローチ

結果の検証

実データは，あまり試みられていない．
プロジェクトラボ産業界

フィードバック

本プロジェクトでは，個人から会社全体まですべて大学を統一的に扱えるような，実証的ソフトウェア工学環境
EPM の開発を目指している

モデル，知見5），6）．

図-4にEPMをある会社とその関連会社に適用した場合の概念を示す．会社内のすべてのプロジェクトデータは，

図 -2 産学連携モデル

ネットワークを通じてリアルタイムに集める．また，外注先会社や請負先会社のデータも収集する．さらに，パ

3. EPMによって集められたデータを可能な限り共有し，ソブリックドメインソフトウェアやその関連データも必要

フトウェア開発における標準的なデータの蓄積を図る．に応じて収集する．そして，これらのデータを分析，加4. EPM を適用した組織が，これを利用したことによっ工し，改善に必要な情報を開発者や管理者にフィードバッて生産性や品質の向上が推進され，利益を得られる．

クする．

これらのことを推進するために，図 -2 のような大学■ EPM の概要■と企業との連携モデルに基づいて，大阪府の千里中央にラボを設け，奈良先端科学技術大学院大学と大阪大学のEPM の設計方針2 大学，そして NTT ソフトウェア，日立製作所，日立公共システム，SRA 先端技術研究所の 4 社からそれぞれ研EPM を実際のソフトウェア開発環境の 1 つとして実現

究者や開発者が集まり，研究開発活動を行っている．

するために以下のような方針を立てた．
1. データ収集に関しては，開発者の負担を最小にし，既■実証的ソフトウェア工学環境 EPM の概念■

存の開発環境の改変はしないで，できる限りリアルタイムに収集するようにする．

ソフトウェア工学の研究として，ソフトウェア開発者

2. 分析は，簡単な単一プロジェクトに対するメトリクス

個人の作業データを集め，それを分析し，改善につなげの計算機能の実装から行い，プロジェクト間のメトリる試みは，今までも多数ある．また，1 つのプロジェク

クス情報の計算，プロジェクトの分類，変遷の解析，トの開発データを収集，分析し，改善に導く手法や技術再利用部品の抽出，知見の再利用などの分析を，順次も多数あり，実際，そのような提案に基づいて，数多く追加していく．のツールが開発されてきている

3. 分析結果をどう改善に利用するかについては，その目

しかし，図 -3 に示すように，何百というプロジェク的によって必要な支援が大きく異なる．ここでは，分トが同時に走っているようなソフトウェア開発会社全体

析データを視覚化し，管理者や開発者が，容易にプロのデータ収集を行い，それらの比較や分類，現状把握をジェクト状況を理解できるようにする．

規模巨大

64
2

複数プロジェクトデータ

53

プロジェクト比較・知見抽出

組織的知識再利用

大

既存の技術 小単一プロジェクト進捗データ 進捗予測

プロセス・プロダクト改善

個人の活動問題検出

ツールの改善・作業誘導

収集

分析

改善

図 -3 実証 SE の対象の規模による分類

724

45 巻 7 号

情報処理2004 年 7 月

本
プロジ
ェ
ク
トのター
ゲット

解説

実証的ソフトウェア工学環境への取り組み ■■分析���� 群

収集

開発者
管理者

インターネット（パブリックドメインソフト、オープンソース開発データ）分析

個別プロジェクト，プロジェクト間メトリクス計測���������� ������������

改善

標準エンピリカル��
標準エンピリカル��データ形式（���）
データ形式（���）開発者
管理者

構成管理履歴
関連会社

メール履歴

障害履歴

その他�
メトリクス予測
他ツールのデータなど���������������������� ������ ������������������
ソフトウェア開発会社

既存の開発環境図 -4 EPM 適用の概念

図 -5 EPM のアーキテクチャ

EPM のアーキテクチャ

SE データ形式に変換するトランスレータを作成すれば，図-5に現在開発中のEPMのアーキテクチャを示す．

以降の処理を同様に行うことができる．

EPMでは，開発者が，構成管理ツールCVS ，メール管理ツー収集されたデータに対して，SQL のコマンド実行によルMailman ，障害管理ツールGNATSを使用することを前り種々のメトリクス情報を計算する．得られたメトリク提としている．それぞれのツールのデータベースには，開スは，ユーザの Web ブラウザ上にグラフ化して表示する．

発プロダクトの履歴，開発者の間でやりとりしたメール，そして障害管理情報などのデータが独自の形式で蓄積されEPM の機能ている．EPMでは，それらを，誰が，いつ，どのような現在，EPM には，対象とするプロジェクトを選択し，イベントを行った，かのタグ付けを行ったXML形式のデー

プログラムサイズ，バグ個数，メール数などのグラフをタに変換する．このデータを標準エンピリカルSEデータ表示する機能を標準として用意している．また個別の開と呼んでおり，PostGreSQLデータベースに格納している．

発形態に合わせて，プログラムサイズの予定成長曲線や現在の EPM では，これらの特定の開発ツールを使うバグの収束曲線を追加することもできる．

ことを前提としたが，これらは，近年，UNIX 系システ

実 際 の EPM の 出 力 を 図 -6 ，7 ，8 に 示 す． こ れ ら

ムのみならず，PC 系などいろいろな開発形態で頻繁には，EPM の開発自体を計測の対象とした例で，図 -6 は，用いられているものである．また，これらのツール以外

EPM の総行数の変遷を示している．縦線は，CVS に対すのツールを使う開発環境であっても，標準エンピリカルるチェックイン操作を行った時期を示す．このグラフに

行数

EmpiriPrjプロジェクト

25000

20000

15000

総行数
更新時期
10000

5000

089102003年

時間（月）図 -6 総行数の変遷

IPSJ Magazine Vol.45 No.7 July 2004

725

障害件数

EmpiriPrjプロジェクト

平均障害滞留日数251020815610452（折れ線）累積障害件数（折れ線）未解決障害件数（折れ線）平均障害滞留時間00910112003年

時間（月）図 -7 総障害数，残存障害数，平均障害除去時間の変遷

チェックアウト回数

EmpiriPrjプロジェクト

252015

チェックアウト回数
更新時期

10508910

2003年度時間（月）図 -8 チェックイン時刻とチェックアウト回数

より，たとえばプロジェクトがどのような状況にあるの害の滞留が増え解決時間が徐々に大きくなりつつある，か，すなわち，コーディングの初期の立ち上がり時期ななどが容易に分かる．のか，中盤の活発な開発時期なのか，終盤の収束期なのかを容易に把握できる．また，過去の同種のプロジェク
トや予定との比較により，進捗の遅れや進み具合を知る

EPM の運用
EPM を有効に使うためには以下のような簡単な制約ことができる．図 -7 は，生じた障害の累積数や未解決のもとに各作業者が開発作業を行う必要がある．の障害数，そして，障害を解消するのに要した平均時間• 各作業者は，日常作業の結果を定期的に決められた場を示している．これにより，発生している障害の状況の所の CVS レポジトリに保存する．たとえば，1 日の作推移を直感的に把握でき，開発者や管理者への障害解消業の終了時に，必ずその日の開発物を決められた場所への動機付けになろう．図 -8 は，CVS にチェックインしのレポジトリにチェックインする，という慣行を実行た時刻と，チェックインしたものをチェックアウトしたする．このチェックインの頻度が少なければ，得られ（取り出した）回数を示している．
これを見ることにより，るデータの実時間性が低下する．

更新したものが適切に参照されているかが分かる．

• プロジェクトに関する情報交換は，もっぱら決められこれらのグラフを見ることにより，たとえば，プロジェたメーリングリストで行い記録を残す．そのアドレスクトの進捗が 9 月下旬から 10 月上旬に停滞していた，障は，開発に関連することのみに用い，他の用途には別726

45 巻 7 号

情報処理2004 年 7 月

解説�������������������

実証的ソフトウェア工学環境への取り組み ■■�����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

図 -9 EPM の発展のアドレスを使用する．

が，今後，以下のような機能の追加を目指している．

• 障害の発生やその解決等の管理は，必ず障害管理ツー• プロジェクトの開始から現状までの推移データに基づルで行い，そこに障害の分類とその内容の記録を残す．

いて今後の推移を予測し，グラフ上にその予測曲線をこのような制約は，既存のプロジェクト慣行とは異な表示する機能．

る場合もあろうが，大規模なデータ収集を行うものとしては，比較的簡便で，適用しやすいものと考えている．

• 過去のプロジェクトや同時進行している多数のプロジェクトのデータを一覧表示する機能．

また，このデータ収集方式は，主にプロダクトデータをさらに，図 -9 のように，今後新たなレポジトリや分集め，そこから必要なプロセスデータを復元する，とい析ツールを追加していき，以下のようなより深い分析やう手法である．この方式では，詳細なプロセスデータを解析が行えるようにする．

得ることは困難であるが，既存の作業環境に特殊なデー• プロジェクトの自動分類タ収集ツールを組み込む，などの変更が不要で，導入しすべてのソフトウェア開発プロジェクトのデータを一やすいものと思われる．

元管理するレポジトリを用いて，プロジェクト間の類

この方式では，開発データの下流工程のデータは直接収

似度や距離を計測し，プロジェクトの分類の解析を行集できるが，仕様や設計などの上流工程のデータを収集す

う ．分類の手がかりとしては，ソースプログラムやるのには，工夫が必要である．これらの上流工程のデータ

ドキュメントに含まれる語彙分布などのメトリクス情に関しては，仕様書や設計書を何らかのツールで記述して報，文字列としての対応度，構造としての近さなどが電子化し，そのデータをレポジトリに保存するようにすれ考えられる．これらを目的に応じて使い分けるとともば，分析して，メトリクス表示することが可能になる．に，分類結果が直感的に把握できるような表示を行う．

EPM で用いている既存のツールは，基本的に分散開発

7）• 協調フィルタリングにも適用可能である．複数の拠点で行われる個々の開発プロジェクトの分類の一種とも考えられるが，与えら作業の情報も，1 つのレポジトリに集めることで複数のれたプロジェクトに最も近いプロジェクトを，複数の開発拠点の情報も一元管理することができる．
また，近年，メトリクス情報から得る．この際，すべてのメトリク普及し始めている開発プロセスの成熟度モデル CMMI

ス情報を全プロジェクトに渡って揃える必要はなく，（Capability Maturity Model Integration）のプロセス領域 KPA

一部のメトリクスに抜けがある場合でも，結果を得る（Key Process Area）との対応を考えることにより，EPM をことができる ．

CMMI のレベル向上の支援に用いることもできる．

8）• コードクローン分析
ソースコードの断片で，別の場所に同型の断片が存在■ EPM の発展■するものをコードクローンと呼び，その高速解析を行
9）

うツールが開発されている ．コードクローンを調べ
EPM は現状では，プロジェクトに関する種々のメトリクス情報をグラフ化して表示する機能を有しているることによって，ソフトウェアシステムの品質やその変遷を知ることができる．
IPSJ Magazine Vol.45 No.7 July 2004727

• ソフトウェア部品検索

イミングで把握することだけでも相当な効果が期待できすべてのプロジェクトのソースコードを分析し，同一るのではないか．地道にプロセスの改善を積み重ねる以部分や類似部分として繰り返し利用されているコード

外に現状を一挙に打破する銀の弾丸はないであろう．

断片を，再利用部品として取り出し，部品の利用率に比較的成熟した工学的な裏づけを有する自動車産業に基づいて，検索部品を提供するシステムが開発されておいては，毎年膨大な数の改善を測定されたデータに基いる

10）．本システムを EPM に組み込むことで，一度づいて実施し，膨大な金額の合理化を達成しているとい

作成したプログラムからソフトウェア部品の自動抽出う．これが巨大な利益の源泉になっている．逆説的に言が行え，部品としての再利用が促進される．

うと，自動車産業の足元にも及ばないソフトウェア産業

これらのツールを追加することによって，たとえば以は，合理化余地の大きい有望な産業だとも言える．

下のシナリオのような改善を期待することができる．

遅まきながら，まず着実にデータを集め，それを分

1. 進行中のプロジェクト X を EPM でモニタしていると，析し，その分析結果に基づいて，プロセス改善やプロ計画に対して実際の進捗が遅れていることに気づく．

ジェクトマネジメントを実証的に行うことが必須であ

2. 何が問題かを知るために，X と似た過去のプロジェクる．実証的ソフトウェア工学の研究がより進み，その実トをレポジトリから探す．これには，プロジェクトの践が広く普及して，そのようなデータを活用しながらソ分類や協調フィルタの技術を用いる．

フトウェア開発を行うことが，ごく当たり前になろう．

3. 検索の結果，過去のプロジェクト X と Y が類似していることが分かった．X と Y のいろいろなメトリクス情EASE プロジェクトがこのような動きを加速させることを期待する．

報を比較し，Y に比べて X のプログラム再利用率が極端に悪いことが判明した．

謝辞

EASEプロジェクトを支援していただいている文

4. ソフトウェア部品検索システムの利用をプロジェクト部科学省，協力いただいている各社に深謝する．EPMのX の中で促進し，再利用の向上に努め，生産性向上を設計や開発，展開に協力いただいている方々に感謝する．

目指す．

本研究は，文部科学省「e-Society基盤ソフトウェアの総合開発」の受託業務として，奈良先端科学技術大学院大学と■現状と今後の展望■
実証的ソフトウェア工学とそれを実践している EASEプロジェクトについて概説した．
現在，EPM は，α版の開発がほぼ完了し，実際の企業のプロジェクトに適用しようとしている．今後，適用する企業を増やすとともに，意見を集約して EPM の改良を行う予定である．また，海外の研究者や研究所との連携を強化していく予定である．
ソフトウェア工学という用語が使われ始めて 30 年を越える年月が過ぎているが，工学と呼ぶにはふさわしい積み上げもあまりなく，高度情報化社会という魅惑的な言葉の影に隠れて農産物にも負けないくらいの目に見えない庇護を受け，それ以降の進化をとどめてしまって現状の悲惨な技術レベルになってしまった，と言っても言い過ぎではないであろう．
ソフトウェア工学が機械工学や土木工学の水準に達し，見通しの良い方法論のもとでシステム構築が整然と進められるようになるには，まだかなりの時間を要すると思われる．しかし，ソフトウェアベンダもユーザも手をこまねいて，方法論の確立を待っているわけにはいかない．
今現場では，優秀なエンジニアが，後手になったトラブルプロジェクトの修復に走り回る光景がよく見られる．
トラブルの症状を，実証的データに基づいてより早いタ

728

45 巻 7 号

情報処理2004 年 7 月

大阪大学が行っている．
参考文献
1）Nuseibeh, B., Kramer, J. and Finkelstein, A. : Expressing the Relationships
between Multiple Views in Requirements Specification, 15th International
Conference on Software Engineering, pp.187-196, Baltimore, Maryland（1993）．
2）嶋田 隆，祝谷和宏：ソフトウェアエンジニアリングセンター構想について，情報処理，Vol.45, No. 4, pp.367-371（Apr. 2004）．
3）http://cif.iis.u-tokyo.ac.jp/e-society/index.html
4）EASE（Empirical Approach to Software Engineering）Project,
http://www.empirical.jp/
5）大 平 雅 雄，横 森 励 士，阪 井 誠，松 本 健 一，井 上 克 郎，鳥 居 宏 次：
Empirical Project Monitor： プロセス改善支援を目的とした定量的開発
データの自動収集・分析システムの試作 , 電子情報通信学会技術報告
SIGSS, Vol.103, No.708, SS2003-48, pp.13-18（Mar. 2004）．
6）Ohira, M., Yokomori, R., Sakai, M., Matsumoto, K., Inoue, K. and Torii, K.：
Empirical Project Monitor: Automatic Data Collection and Analysis toward
Software Process Improvement, 日本ソフトウェア科学会研究会資料シ
リーズ，No.28, 第 1 回ディペンダブルソフトウェアワークショップ（DSW2004）
論文集，pp. 141-150（Feb. 2004）．
7）川口真司，松下 誠，井上克郎，潜在的意味解析法 LSA を利用したソ
フトウェア分類システムの試作，情報処理学会研究報告，2003-SE-140,Vol.2003, No.22, pp.55-62（Mar. 2003）．
8）大杉直樹，門田暁人，森崎修司，松本健一：協調フィルタリングに基づ
くソフトウェア機能推薦システム，情報処理学会論文誌，Vol.45, No.1,pp.267-278（Jan. 2004）.
9）Kamiya, T., Kusumoto, S. and Inoue, K. : CCFinder: A Multilinguistic TokenBased Code Clone Detection System for Large Scale Source Code, IEEE
Transaction on Software Engineering, Vol. 28, No. 7, pp. 654-670（2002）．
10）Inoue, K., Yokomori, R., Fujiwara, H., Yamamoto, T., Matsushita, M. andKusumoto, S.: Component Rank: Relative Significance Rank for Software
Component Search, Proceedings of the 25th International Conference onSoftware Engineering（ICSE2003），pp.14-24, Portland, Oregon（2003）．
（平成 16 年 6 月 2 日受付）