論 文
ソフトウェア開発プロジェクトのリアルタイム管理を目的とした支援
システム
大平

雅雄†

横森

小野

英治†††††

新海

励士††平††††††

阪井

誠†††

岩村

聡††††

横川 智教†††††††

Designing a System for Real-Time Software Development Management
Masao OHIRA† , Reishi YOKOMORI†† , Makoto SAKAI††† , Satoshi IWAMURA†††† , Eiji
ONO††††† , Taira SHINKAI†††††† , and Tomoyuki YOKOGAWA†††††††

あらまし 本研究は，信頼性や生産性に課題の多いソフトウェア開発の分野において，科学的根拠に基づく開発手法である実証的ソフトウェア工学 (Empirical Software Engineering) の確立を目指す EASE (Empirical
Approach to Software Engineering) プロジェクトの一環として行われたものである．本論文では，より実践的なプロセス改善の支援を目的として構築したシステム，EPM (Empirical Project Monitor) について述べる．
EPM は，現在広く普及している開発支援フリーウェア (CVS, Mailman, GNATS 等) と連携することによって開発履歴データをリアルタイムに収集し，定量的データ分析を可能にするシステムである．EPM を利用したソ
フトウェア開発では，管理者及び開発者は常時，プロジェクトの進捗状況や作業状況を客観的に把握することが可能となる．その効用として，プロジェクトの問題点を迅速に発見し的確なプロジェクト管理が行いやすくなる
ため，効果的なプロセス改善活動の実施を期待することができる．システムの有用性を検証するために，試作した EPM を現行の EPM 開発プロジェクトに適用した結果，開発者に大きな作業負荷を与えることなく当該プロ
ジェクトの状況を分析することができた．
キーワード

ソフトウェアプロセス改善，自動データ収集，定量的データ分析，実証的ソフトウェア工学

1. は じ め に†奈良先端科学技術大学院大学情報科学研究科，生駒市
Graduate School of Information Science, Nara Instituteof Science and Technology, 8916–5, Takayama, Ikoma,
Nara 630–0192, Japan††

大阪大学大学院情報科学研究科，豊中市
Graduate School of Information Science and Technology,
Osaka University, 1–3, Machikaneyama, Toyonaka, Os-†††

より安定した開発を実施する目的で開発標準を策定し，Shinjuku, Tokyo, 164–0004, Japan

同一の作業方法を実施可能とするための環境整備が行

NTT ソフトウェア株式会社，横浜市

われているものの，単に開発標準を定めただけでは開Yokohama, Kanagawa 231–8554, Japan

発者の能力や開発対象，さらにはスケジュールや予算

日立公共システムエンジニアリング株式会社，東京都等の制約条件によって，開発に要する期間や成果物のgineering, Ltd., 2–4–18, Toyo, Koto, Tokyo 135–8633,

品質は大きく異なってしまう．そのため，開発状況をJapan

随時把握しプロジェクトを管理することが必須となる．

(株) 日立システムアンドサービス 研究開発センタ，大阪市
Hitachi Systems & Services, Ltd., 2–10–70, Nanbanaka,†††††††

あっても，開発作業の実施方法は多種多様であり，ソフトウェアの品質や作業効率に大きな影響を与える．

Hitachi Government & Public Corporation System En-††††††

ことは容易ではない．たとえ成果物が明確な作業で株式会社 SRA 先端技術研究所，東京都

NTT Software Corporation, 223–1, Yamashita, Naka,†††††

高品質なソフトウェアを効率的かつ安定的に開発する

aka 560–8531, JapanSRA Key Technology Laboratory, Inc. 3–12, Yotsuya,††††

ソフトウェア開発は複雑な作業の組み合わせであり，開発状況の把握に基づくプロジェクト管理では，トNaniwa, Osaka 556-0011, Japan

ヨタ式カイゼン方法の一つである「視える化」が有名

岡山県立大学情報工学部情報システム工学科，総社市である [1]．視える化は一言で言えば，問題点が常にOkayama Prefectural University, 111, Kuboki, Soja,
Okayama 719–1197, Japan「視える」ようにしておく工夫のことであり，ソフト

電子情報通信学会論文誌 D–I Vol. Jxx–D–I No. xx pp. 1–12 xxxx 年 xx 月

1

電子情報通信学会論文誌 xxxx/xx Vol. Jxx–D–I No. xx
表 1 文書中心のプロジェクト管理の問題点
Table 1 Issues on document-based management
適用限界
情報遅延
情報操作

より詳細な情報を得ようとすると負荷が増大する
ため，適用の限界がある
開発状況の把握に必要となる情報を入手できるまでにある程度の時間を要する
客観性に欠ける状況報告など，人為的な情報操作が入る可能性があるのである [10]．
これまで我々は，実践的なプロセス改善支援を目的
として EPM (Empirical Project Monitor) [11]〜[13]を構築してきた．EPM は，現在広く普及している開発支援フリーウェア (CVS, Mailman, GNATS 等) と連携することによって開発履歴データをリアルタイムに収集し，定量的データ分析を可能にするシステムである．文献 [11]〜[13] では主に，プロセス改善に対す

ウェア開発にも適用することができる [2]．プロセス改る我々のアプローチ及び支援システム EPM の提案を善のプラクティスをまとめた CMM [3]/CMMI [4] に行った．本論文では，システムの有用性を検証するこ

おいても，レベル 4 及び 5 では定量的なプロジェクトとを目的として EPM を試作し，さらに現行の EPM管理を目的としてソフトウェア開発中のデータが収集・

開発プロジェクトに適用した結果とその考察を述べる．

分析され，ソフトウェアプロセスの改善に用いること

以下，2 章では，先行研究とのアプローチの違いにが要求される [5]．これらの方法では，GQM [6] と同ついて述べ，本研究の位置付けを明らかにする．3 章

様，プロセス改善のための目標を定め，ゴールと関連

では，EPM の実装について詳述する．4 章では，本するメトリクスデータを収集し改善活動に用いること研究が想定している EPM の分析結果利用例を説明し，が一般的である．しかしながら，収集されたデータが本システムの適用可能性を示す．5 章では，システム

プロジェクト管理にとって必ずしも効果的なデータにの評価結果とその考察について述べる．最後に 6 章になり得るとは限らない [7]．特に，従来用いられていた

おいて本論文をまとめる．

開発データは報告書等の文書が中心であるため，表 1に挙げるような問題点がある．

CMM/CMMI や文献 [7] 等で述べられているように，類似の開発プロセスが繰り返され，誰もが理解できる程度にプロセスが明確に定義され十分に成熟した

2. プロセス改善とプロジェクト管理
本章では，先行研究とのアプローチの違いを述べ本研究の位置付けを明らかにする．

2. 1 本研究におけるプロセス改善

組織を対象とした場合ならば，良いデータを収集できこれまで，ソフトウェアプロセスの改善を支援する

る可能性がある．しかし，このような組織であっても，ためのモデル (CMM [3], CMMI [4], IDEAL [14] 等)収集できるデータの粒度に限界があり，プロジェクトが提案され，企業において適用されてきている．これの規模や方法論等によってはデータ収集及びプロセス

らのモデルは共通して，段階的かつ継続的なプロセス改善の実施にかかる負荷が大きくなる [8]．また，報告改善を実施するための一連のガイドラインを提供して書等の情報は，次工程への移行を決定する会議等においる．現状プロセスの分析によって問題点を抽出し，いて利用されるが，そのような文書が必要となる工程改善へ向けた明確な目標を設定した上でプロセス改善の区切りまでは情報が作成されず，利用できない場合活動を実施するという，トップダウンの改善モデルをが多く，管理者が開発状況を把握するまでにはある程採用している点に特徴がある．しかしながら実際のソ度の時間的遅延が生じる．さらに，早く次の工程に進

フトウェア開発の現場では，プロセス改善を実施しよめることや人事評価を良くすることを意図した情報のうとしても目標の設定自体が困難な場合が少なくなく，加工や主観的な情報の混入等によって，不自然な運用

小規模な企業や組織的なプロセス改善を実施するゆとが行われる可能性がある．

りのない企業においては特に問題になる．

本研究は，文部科学省リーディングプロジェクト「e-図 1 にプロセス改善支援に対する我々の基本モデル

Society 基盤ソフトウェアの総合開発」の中の EASEを示す．プロセス改善のための実施方法や手順をトッ(Empirical Approach to Software Engineering) プ

プダウンに規定するのではなく，ボトムアップにプロ

ロジェクト [9] の一環として，信頼性や生産性に課題

セス改善を支援しようとする点で他の既存モデルとはの多いソフトウェア開発の分野において，科学的根異なる．本モデルは，(1) ソフトウェア開発データの大拠に基づく開発手法である実証的ソフトウェア工学

規模収集，(2) 集約的データ分析，(3) プロセス改善の(Empirical Software Engineering) の確立を目指すもためのフィードバックというサイクリックなプロセス2

論文／ソフトウェア開発プロジェクトのリアルタイム管理を目的とした支援システム
表2
問題点
適用限界
情報遅延
情報操作

支援システム構築のための本研究のアプローチ
Table 2 Our approach
対処方法
データを自動的に収集する機能の実装
リアルタイムにデータ分析する機能の実装
開発作業の中で生成される開発履歴データの利用作業の中でこれらのシステムに蓄積される履歴データを利用することによって，人為的に加工されにくい客
図 1 プロセス改善のための基本フェーズ
Fig. 1 Basic phases for process improvement

観性の高いデータを収集することができるだけでなく，開発規模や開発形態に依存しない支援システムを構築することができると考えた．

改善活動を想定している．特に，定量的データを収集

このような開発履歴データを自動収集する機能を支することに重点を置き，ソフトウェア開発プロジェク

援システムに実装することによって，開発者や管理者

ト及び組織の問題に沿って柔軟に改善活動を支援する．

にデータ収集のための特別な作業負荷を与えずにデー

本モデルを採用する理由は，進行中の開発プロジェ

タを収集することが可能となる．さらに，開発履歴

クトの中で生じる，品質，コスト，納期等に関連する

データをリアルタイムに分析する機能を実装すること

様々な問題を可能な限り迅速に発見し，的確にプロによって，開発状況を常に把握し問題が生じた場合にジェクト管理を行えるようにするためである．この意

迅速に適切な対処を行うことが可能になると考える．

味において，プロセス改善支援に対する本研究の立場

2. 3 関 連 研 究は，既存のものと相反するのではなく補完可能なもの

関連研究として，開発データの自動収集という側面であると考えることができる．粒度の整った一貫性のでは，開発者のキーストロークや視線移動等のデータ高いデータをあらかじめ収集しておくことで，データを収集する Ginger2 [15] がある．Ginger2 は，開発者分析を行いながら問題点を発見し，プロセス改善へつの作業や行動をきめ細かな粒度で記録・分析すること

なげるためのフィードバックを随時提供していくこと

で，ソフトウェア開発に関する諸特性を解明するためが可能となると考えている．

に開発されたシステムである．また，Hackystat [16]2. 2 プロジェクト管理支援システムの設計

は，開発支援環境にセンサーとなるものを付加する

前章，表 1 に挙げたプロジェクト管理に関する諸問ことで開発者の作業履歴を記録するシステムである．

題を解決するための我々のアプローチについて述べる．

Hackystat の開発目的は，ソフトウェア開発における適用限界に対処するためには，開発者及び管理者に内因特性 (サイズや時間等) と外因特性 (品質や信頼性

特別な作業負荷やコストを要さないデータ収集を行う

等) との関係を見出すことにある．これらの研究では，ことが必要である．次に，情報遅延の問題を解決する

いわゆる実験室実験 (統制実験) によって，ソフトウェには，収集データを必要に応じた任意のタイミングでア開発に関連する様々な仮説を検証することが主たる

参照・分析できるようにすることが重要である．最後目的である．本研究の目的は，開発データの収集，分に，情報操作を防止するためには，人為的な情報が混析，フィードバックというサイクリックなプロセスを入されにくい一貫性・客観性の高いデータを収集・計通したプロセス改善を支援することである．また，実測する必要がある．

際の開発現場でシステムを適用し，その効用を実証しこれらの要件を満たす支援システムを構築するためようとする点が研究の方法として異なるものである．

に，本研究では表 2 に挙げる対処方法を採用する．ま開発履歴データの分析の側面としては，開発作業

ず，データの人為的な情報操作を防ぐことを目的とし状況を可視化する Augur [17] や ROSE [18] 等がある．

て，構成管理，メーリングリスト管理，障害管理の各

これら以外にも，構成管理や障害管理システムに蓄積システムに残された開発履歴を開発データ収集源としされた履歴データを分析する研究が近年盛んに行われて利用することにした．これらは，ソフトウェア開発ている [19], [20]．これらの研究では，いずれか 1 種類

支援システムとして現在広く普及しており，多くの開の開発支援システムに蓄積された履歴データを分析し，発プロジェクトにおいて利用されている．日々の開発

ソフトウェアの変更理由の同定，分散環境下での情報
3

電子情報通信学会論文誌 xxxx/xx Vol. Jxx–D–I No. xx
Data
Analysis

Measurement of intra and inter projects

Data Store

Repository(PostgreSQL)

FormatTranslation

Standardized empirical
SE data (XML)

Analyzer

Results throughweb browsers
ImporterTranslator

Data
Collection Configuration
management( Project X )data

Mailing list
management
data

Issue
trucking
data

Project Y
Project Z

Developers

Managers
図 3 EPM のアーキテクチャ
Fig. 3 The Architecture of EPM

Common development
support systems
and GUI tools

図 2 Empirical Project Monitor の概要
Fig. 2 Overview of Empirical Project Monitor

表 3 EPM のサブシステム
Table 3 Subsystems of EPM
サブシステムTranslator

遅延の原因解明，潜在的変更箇所や不完全な変更箇所

Importerの検出等の支援を目的としている．本研究は，3 種類

Analyzerの開発支援システムから履歴データを収集し，それらを組み合わせた分析結果を提供することによってリア
ルタイムでのプロジェクト管理を支援する．複種類のLauncherCustomizer

履歴データを同時に分析利用する研究はまだほとんど

説明
収集データを標準エンピリカルデータフォー
マットと呼ぶ XML 形式のデータに変換
フォーマット変換したデータを PostgreSQL
データベースに格納格納されたプロセスデータをユーザ (管理者・開発者) の要求に応じて分析し結果を可視化
Translator・Importer・Analyzer を Web 経
由で実行Translator・Importer・Analyzer で使用する各種設定ファイルの作成・更新

見当たらず，本研究の新規性の高い部分である．

3. Empirical Project Monitor

可能なシステムであるため，EPM 導入にかかるコストは非常に低い．

本章では，2.2 節の設計指針に従って実装を行った

データ変換部では，Ruby で記述されたスクリプト

Empirical Project Monitor (EPM) を紹介する．
3. 1 EPM の概要
EPM は，リアルタイムでのプロジェクト管理を目によって，収集データを標準エンピリカルデータフォー

的とした開発データの自動収集・分析システムである．

とのインターフェースとして公開されている．XMLEPM は，ソフトウェア開発において一般的に利用さ形式のデータに変換する理由は，(1) 既存の開発環境れている開発支援システムから開発履歴データを収集で利用されている同種の様々なシステムへ対応するたし，プロジェクト管理を行うために有益な分析結果をめに入力データ形式を統一する必要があること，(2)

ユーザに提供する．EPM は，実際の開発現場では困分析対象データの入力データ形式を統一することで難がつきまとう一貫性のある定量的データ収集と収集

EPM 上での分析環境の実現が容易になることの 2 点

データの分析利用を容易にする．

である．

マットと呼ぶ XML 形式のデータに変換する．標準エンピリカルデータフォーマットは，各コンポーネント

図 2 は，EPM の概要図である．EPM は，データデータ蓄積部では，標準エンピリカルデータフォー

収集，データ変換，データ蓄積，データ分析・可視化

マットに変換されたデータを PostgreSQL データベーの 4 つの基本機能から成る．以下では，EPM が処理スに格納する．例えば，構成管理システム CVS からするデータの流れに沿って各機能を説明する．

は，ソースコードの修正，チェックイン，チェックア

データ収集部では，構成管理，メーリングリスト管

ウト等のイベント情報を取得可能である．これらのイ

理，障害管理など，ソフトウェア開発において広く普ベントには，CVS リポジトリ中のコンポーネントの及し利用されている開発支援システムからデータを収

サイズ，更新時期，バージョン等の遷移情報が含まれ集する．システムに保存される履歴データは，日常のており，それらの情報もデータベースに格納する．ま

開発作業の過程で蓄積されるものである．したがって，た，メーリングリスト管理及び障害管理システムから

管理者・開発者がデータ収集のために特別な作業を行

は，メールのヘッダや障害報告を元に，投稿時間，件う必要はない．また，すべてフリーソフトとして利用

名，差出人等の情報を格納する．同時に，話題ごとに

4

論文／ソフトウェア開発プロジェクトのリアルタイム管理を目的とした支援システム
表 4 カスタマイズ機能
Table 4 Customization of EPM
機能
環境設定

環境変数

機能追加

環境設定ファイル
標準エンピリカルデータ

分析機能

リポジトリ (DB)Translator
Importer
Analyzer
プロパティファイル
カスタマイズ分析履歴

カスタマイズ内容
EPM のインストール場所及びデータ保存場所の指定が可能．環境変数は Tomcat の引数経由
でサーブレットからも参照
プロジェクト毎の開発環境，履歴データ位置，出力位置を XML 形式で記述指定可能
XML 形式を用いて中間ファイルのデータ構造を規定しており，EXCEL 等の外部システムによる分析や他システムからのデータ取り込みが可能
データの間接参照により可変データ構造を実現
Ruby スクリプトの改造により各種開発システムに対応可能
サブクラスの追加により各種開発システムに対応可能
SQL 文の入力によりユーザ独自の分析 (カスタマイズ分析) ができ再実行も可能
ユーザが過去に実行したデータ分析を保存しており呼び出しによる再実行が可能．DB 構造に依存する部分を独立させているため属性名等の変更にも対応可能
記録された分析履歴は，標準分析機能の拡張設計に利用される

集計した一覧表も作成する．
データ分析・可視化部では，格納されたプロセスデー
タをユーザ (管理者・開発者) の要求に応じて分析し，結果を提示する．データは随時収集・蓄積・分析され，

表 5 開発者の振舞いと問題となる行為
Table 5 Developer’s behavior and problems
開発者の振舞い
要求仕様確認作業
プロダクト提供作業

プロジェクトを管理するために有益な分析結果をリア
ルタイムで得ることができる．分析は Java サーブレッ
トにより行われ，結果をグラフや表としてウェブブラ
ウザから閲覧することができ，プロジェクトの分析結障害報告及び対策作業問題となる行為
数少ない情報交換等
プロダクト提供が少ない・遅い，CVS
参照がない，CVS 更新連絡がない，
プロダクトに関する議論が少ない等
不具合報告が多い，一次対応が遅い，
不具合対応の更新・完了が多い，不具合対応に伴う仕様変更が多い等

果の共有を促進する．分析結果共有の簡便化は，分析
結果を理解するために行う議論の場で特に有効である．

のライブラリを利用している．

このように，EPM は定量的な開発データを低いコ

EPM の導入にかかるコストをできるだけ減らすた

ストで収集し，開発プロジェクトのリアルタイムでのめ，また，各組織の既存環境資産を有効に活用できる管理を支援する．基本的な 3 種類のシステムから人為ようにするために，表 4 に挙げるようなカスタマイズ

的操作のされにくいデータを収集することによって，機能を実装した．これらの機能によって既存環境への一貫性のある分析結果を提供することができる．

適応性の高いシステム構造となっている．

3. 2 基本アーキテクチャと既存環境への適応
図 3 に EPM の基本アーキテクチャを，表 3 に EPMの各サブシステムの説明を示す．EPM は Red Hat

4. EPM の分析結果利用例
本章では，本研究が想定している EPM の分析結果

Linux 上での動作を想定しており，Red Hat Linux

利用例を説明し，本システムの適用可能性を示す．

上にインストールした Ruby，PostgreSQL，Java，

4. 1 単一プロジェクトを対象とした可視化

Apache，Tomcat を用いて，EPM の 5 つのサブシス

以下では，我々の研究プロジェクト (EASE プロジェ

テム (Translator，Importer，Analyzer，Launcher，

クト [9]) における EPM 開発を例として利用し，EPM

Customizer) を実現している．

が可視化する 5 種類の標準分析結果を説明する．

図 3 中では，分析用データ収集源として CVS, Mail-

5 種類の分析方法を標準とした理由は，プロジェク

man, GNATS（注 1） の利用を想定した場合を示している

ト管理に必要となる，開発者の振舞いに関する情報をが，Majordomo，fml，Bugzilla（注 2） のデータも同様提供するためである．ここでいう開発者の振舞いとは，に収集・分析することが可能である．また，Java のライ

大きく分けて次の 3 つの作業の中で行われるものからブラリとして JFreeChart, Log4J 及び PostgreSQL

成る．(1) 要求仕様確認作業，(2) プロダクト提供作

用の JDBC ドライバを，Ruby には REXML，uconv

業，(3) 障害報告及び対策作業である．
これらの作業における問題は，プロダクトの品質，（注 1）：利便性を考慮し，Gnatsweb との併用を推奨（注 2）：Bugzilla を利用する場合は，MySQL 環境が必要

コスト，納期 (QCD) に大きな影響を与えるため，開発者の振舞いは常に管理者及び開発者自らがチェック
5電子情報通信学会論文誌 xxxx/xx Vol. Jxx–D–I No. xx

図6
図 4 ソースコードの規模推移
Fig. 4 Transition of LOC

メール投稿数の推移と障害発生・解決時期との関連
Fig. 6 Mails and bugs

図7
図5

チェックインとチェックアウトとの関連
Fig. 5 Check-in and Checkout

チェックインと障害件数との関係
Fig. 7 Check-in and bugs

開発者はローカルにある自らのファイルを更新するたできることが望ましい．表 5 に，プロダクトの QCD

めにチェックアウトの操作を行う．チェックイン後にに影響を与える開発者の振舞いを挙げる．5 種類の標

チェックアウト数が少ない場合は，CVS 中のファイル

準分析機能は，開発者の振舞いをリアルタイムで把握が更新されているにもかかわらず他の開発者がそれし，表 5 で挙げた問題となる行為を早期発見する上でを参照していないことになる．変更が局所的なもので必須の機能として実装された．

あり全体への影響が少ない場合と，開発者のコミュニ

ソースコードの規模推移：図 4 は，ソースコード

ケーションがうまくいかず変更が周知されていない場

規模の推移 (図中，黒の折線) を示すものである．図

合等が考えられるが，後者の場合は改善が必要となる．

中，灰色の垂線は開発者が CVS リポジトリを更新しメールの投稿数の推移とチェックイン/障害発生/障た (チェックインした) 時期を表しており，リポジトリ

害解決時期との関連：図 6 は，開発者用のメーリング

中のファイルに対する追加/修正/削除等の操作が行わリストを使用して投稿されたメールの累積 (図中，太れたことを示している．グラフの規模推移と更新時期

い黒の折線)，障害発生時期 (図中，細かい点線)，障害との関係から，何らかの原因で開発が停滞している事解決時期 (図中，粗い点線)，チェックインの時期 (図を確認できるだけではなく，例えば，順調な規模増加

中，灰色の垂線) との関係を表したものである．このと頻繁な更新が同時に起きていれば，開発が活発に行グラフから，障害発生/解決時期と開発者間のコミュわれていることを知ることができる．リアルタイムでニケーションの関係を知ることができる．通常，障害の開発状況の把握は，プロジェクト管理者だけではな

報告がなされた場合，開発者らはメーリングリストをく，定量的データを用いて開発状況の説明を行えるこ

通じて対応策等について議論を行う．グラフ中に，障とから，開発者にとっても有益である．

害が数多く報告されているにもかかわらず，開発者がチェックインとチェックアウトの関連：図 5 は，チェッ議論を行っていない (メールの投稿数が少ない) 状況がクインの時期 (図中，灰色の垂線) とチェックアウト回

存在すれば，開発者間のコミュニケーションに問題が数 (図中，黒の垂線) との関係を示している．CVS リある可能性が高い．開発者間のコミュニケーションのポジトリに開発者がチェックインした場合，通常他の問題はソフトウェア生産性や信頼性を減少させる原因

6

論文／ソフトウェア開発プロジェクトのリアルタイム管理を目的とした支援システム

図8

累積・未解決障害件数と平均障害滞留時間との関連
Fig. 8 Resolved and unresolved bugs

図9二つのプロジェクトの規模推移の比較
Fig. 9 Comparison of LOCとなる [19], [21]．また，このグラフ中に表示される障害発生時期，(バグフィックスを行った) チェックイン
時期，障害解決時期の対応関係から，プロジェクトの障害対応の状況も確認することができる．
チェックインと障害件数との関係：図 7 は障害報告の累積 (図中，黒の折線グラフ) とチェックインの時期(図中，灰色の垂線) との関係を示している．障害報告がなされた後，障害修正結果を反映するために開発者がチェックインする場合が多いが，このグラフはバー
ジョン毎の障害対応状況の確認に役立つ．
累積・未解決障害件数と平均障害滞留時間との関係：
図 8 は，障害報告の累積 (図中，上の折線)，未解決

図 10 多数の OSS プロジェクトの散布図
Fig. 10 Distribution map of 100 OSS projects

障害件数の推移 (図中，下の折線)，平均障害滞留時間(図中，真中の折線) との関係を示している．このグラフは，現在プロジェクトが抱えている障害の多寡や障害の解決状況を表しており，テスト段階において深刻な状況が発生しているか否かをプロジェクト管理者が把握するのに役立つ．また，プロジェクトが抱えている障害状況が一目できるため，開発者がバグを減らすための動機付けとしても利用することができる．

4. 2 複数プロジェクトを対象とした可視化
EPM は，前節で挙げた単一プロジェクトに対する分析のみならず，複数のプロジェクトを対象とした比較分析を行うことができる．過去の類似プロジェクトを比較することで，進捗見積もりや異常値の早期検出など，主に管理者にとって有益な分析を行える．
複数プロジェクト間の比較: 図 9 は，二つのプロジェ
クト間のソースコードの規模の変遷を比較したものである (上部の折れ線: SPARS プロジェクト [22], 下部の折れ線: EASE プロジェクト)．仮にこの二つのプ
ロジェクトが同様な開発形態や開発規模をとるのであ
れば，後発のプロジェクトの進捗状況や遅延の有無を大まかに見積もることができる．例えば，SPARS プ

ロジェクトはメジャーバージョンをリリースするために急激に進化する 2 つのフェーズが存在することが見て取れる．EASE プロジェクトはちょうど最初のメジャーバージョンをリリースしたところである．管理者は近い将来の EASE プロジェクトの進捗をある程度予想することができる (レビューやテストのために
ソースコード規模はしばらく増加しない等)．
複数プロジェクトの分布： 図 10 は，複数プロジェ
クト間の比較分析を目的としてオープンソースソフト
ウェア (OSS) 開発プロジェクト 100 件分のデータをSourceForge.net から収集し（注 3），EPM を用いて分析した散布図の例である．図 10 は，ソースコード規模(X 軸) とチェックインの数 (Y 軸) の関係を表したものである．図 10 から，同程度の規模を持つのプロジェクトであっても極端にチェックアウト数が多い/少ない
プロジェクトや，反対に，同程度のチェックアウト数であっても極端に規模の大きい/小さいプロジェクトを見て取ることができる．このような散布図を利用す（注 3）：SourceForge.net の active project list の上位 300 プロジェ
クトからデータ収集可能であったプロジェクト 100 件分の CVS データ．

7

電子情報通信学会論文誌 xxxx/xx Vol. Jxx–D–I No. xx
表 6 EPM 開発プロジェクトの概要と評価環境
Table 6 Evaluation of EPM development project
EPM 開発プロジェクトの概要
対象プロジェクト EPM 開発グループ (試作版完成後，次期版の EPM を開発)
利用言語
Ruby, Java
開発者数
企業派遣の開発者 4 名 (それぞれは異なる企業に所属)
分析対象システム CVS, Mailman, GNATS
EPM 導入期間
EPM 試作版完成後から約 3ヶ月 (2003年 11 月中旬から 2004 年 1 月)
評価に利用した計算機環境
EPM 導入 PC
CPU Pentium4 2.53GHZ, Memory
1GB, HDD 200GB
LAN 環境100Mbps で接続されたクライアント PC
から分析結果を表示であることから機会の多かった) インフォーマルな議論の中から得られた意見や感想による部分も大きい．

5. 2 評 価 方 法
本論文ではまず，2.2 節で述べたシステム設計時における以下の 3 つの要件が満たされていたかどうかを
評価する．

•

低い作業負荷とコストでのデータ収集•

任意のタイミングでのデータ分析•

人為的な情報操作の防止

これらの評価では，定量的な測定・分析結果を開発者に示し，研究者の評価結果についての妥当性に関して確認した．特に，人為的な情報操作の防止に関しては，履歴データの分析結果だけでは不十分と考えられたたることで，年間数百あるいは数千規模でプロジェクト

め，人為的情報操作の可能性について開発者を交えてを運営管理する必要のある企業では，異常値の早期発議論し考察を行った．

見が容易になると考えられる．

5. 評価と考察
本章では，試作した EPM を現行の EPM 開発プロ

次に，EPM の適用により得られる効用を以下の 2点について評価し考察する．

•

プロジェクト管理への効用•

プロセス改善への効用

ジェクトに適用した結果を考察し，システムの有用性

これらの評価では，開発者及び開発状況の詳細な観察を検証する．

による定性的な評価結果と，開発者へのインタビュー

5. 1 EPM 適用環境と評価環境
表 6 に，EPM 開発プロジェクトの概要とシステム結果を併せて考察し EPM 適用の有用性を判断した．

5. 3 EPM 適用結果の評価と考察の評価に利用した計算機環境を示す．今回のシステム

今回得られた EPM 適用の有用性評価結果を表 7 にの有用性評価は，エスノグラフィの手法 [23] を用いてまとめる．以下では，各評価項目の評価結果とその考得られたデータ (開発プロセスの詳細な観察結果と，察について述べる．

開発者からの意見及び感想) に基づくものである．

低い作業負荷とコストでのデータ収集：EPM 及び著者ら (4 名の開発者と 3 名の研究者) は，同じ職場関連するオープンソースソフトウェアのインストール

で共同研究をしており，研究者はプロジェクトの進捗には，約 2 人日要することがわかった．それらのシ状況や各開発者の作業状況を常に観察することができ

ステムの管理・運用技術を開発者全員が習得する (シた．週一回行われる開発進捗ミーティングにも研究者

ステムの利用に慣れるまで) には，約 1 週間が必要でが出席することが許可され，随時，質問や意見を述べあった．また，EPM 導入時には CVS 未経験者がいたることができ，さらに工程管理表やその他ドキュメン

が，類似のシステムの知識があったので 1〜2 時間程

ト類の閲覧も可能であった．

度の学習で操作できるようになった．EPM の導入後

このような物理環境の中で，EPM 開発プロジェク

は，(個々のプロジェクトが CVS 等のシステムを利用

トを細部に渡って観察・把握した研究者が，システム

していることが前提ではあるが) ネットワーク経由での有用性評価を行った．開発者には，次節で挙げる 5

組織内のすべての開発プロジェクトを管理可能である．

つの評価項目に沿って，(定量的測定結果が利用できる

また，新規プロジェクトの追加設定等は GUI ベース

場合はそれらを示し) インタビューを行い意見・感想の管理ツール (Customizer) を利用することができる．

を求めた．

これらを考慮すると，EPM 導入に際しての作業負荷

EPM の有用性について定性的な評価を行った部分は多少必要ではあるものの，特に運用面においては大については，研究者らの観察結果と，開発者らへのイ

きな作業負荷が生じないことを確認できた．コスト面ンタビュー結果を併せて行ったものである．5 つの評

では，ハードウェアとして EPM をインストールする

価項目に沿ったインタビューだけではなく，(同じ職場

PC が必要な他は，フリーソフトを利用するため特別

8

論文／ソフトウェア開発プロジェクトのリアルタイム管理を目的とした支援システム
表 7 EPM 適用の有用性評価
Table 7 Evaluation of EPM
評価軸
システム設計時の要件

システム適用の効用

評価項目
低い作業負荷とコストでのデータ収集
任意のタイミングでのデータ分析
人為的な情報操作の防止
プロジェクト管理への効用
プロセス改善への効用

表 8 リアルタイム性評価結果
Table 8 Result of Real-time performance
Translator によるデータフォーマット変換
Importer によるデータベースへのデータ格納
Analyzer による分析結果表示

約3秒
約 74 秒
平均約 4 秒

評価結果の概要
導入時の訓練等で多少の作業負荷は必要だが，運用面・コスト
面では要件を満たせることを確認
妥当なリアルタイム性を確認
情報操作の可能性は低いと考えられるが，さらに検証が必要
プロジェクトの状況理解・問題発見が容易に行える
共同作業のための規約が徐々に作成されたた PC 程度の性能では限界があることも事実である．

EPM の適用規模に対してどの程度のハードウェア性能が必要かについては今後さらに検討が必要である．
人為的情報操作の防止：すべての履歴データを分析した結果，EPM 開発プロジェクトでは人為的な情報
操作は発見されなかった．しかし，この結果から EPM

なコストはかからない．

が人為的情報操作を防止可能なシステムであると判断

データ分析のリアルタイム性：

することは困難である．ここでは，EPM を利用した

表 8 は，EPM 開発プロジェクト 1 件分 (ソース行

ソフトウェア開発において，個々の開発者が意図的に数：約 32,000 行，メール総数：約 800 通，障害報告：

情報操作を行えるかどうかについて考察する．

32 回) の履歴データから，Translator による標準エン

EPM は，開発者が日常頻繁に使用する開発支援シ

ピリカルデータフォーマット変換，Importer による

ステムに蓄積される履歴データを収集する．各工程終PostgreSQL データベースへのデータ格納にそれぞれ了時に開発者個々人に手作業で入力させる従来のシス要した時間，Analyzer による (4.1 節の 5 種類の) 分

テムとは異なり，蓄積された履歴データを EPM に取析結果表示に要した平均時間をまとめたものである．

り込む際には人為的な情報操作は行えない．従って，開発の進捗状況を数分単位で管理することは考えに

各工程終了時に情報操作を行い，開発の進捗をより良くく，通常は日単位でデータを格納すれば十分である

く見せようとするなどは基本的に不可能である．

ことから，表 8 の結果は，履歴データの変換・格納時

一方，悪意のある開発者が開発メンバの中に存在す間及び分析結果の表示時間ともにリアルタイム性を示るのであれば，開発支援システム使用中の意図的な情すものであるといえる．

報操作 (ソースコードの水増し，不適切な障害報告な

参考として，今回の検証では OSS 開発プロジェクト

ど) を完全には防ぐことはできない．しかしながら，100 件分の CVS データも合わせてデータベースに格

EPM を利用したソフトウェア開発では，個々人の開納した．それらを含めたデータ変換・格納に要した時

発者が意図的に不正を行おうとする動機を抑制する効間は約 7 時間であった．この結果は，市販の標準的な用があると考えられる．この理由には大きく二つを挙PC を利用したことを考慮すると妥当な値であると考げることができる．

えることもできるが，今回の実装ではプロジェクト毎

一つ目は，各工程終了時に開発者個々人が行っていにすべてのデータを一度にデータベースへ格納する方た従来の手作業のデータ入力システムとは異なり，多式を採っていたことも大きな原因である．現在，日々

人数参加型の開発支援システムを (履歴データ収集源の作業更新分 (差分) を適宜格納していく方式を実装として) 利用していることが挙げられる．一部の上司中であり，多数かつ大規模なプロジェクト管理を行う

が作業状況をチェックするのではなく，開発メンバ全場合のリアルタイム性確保に対応する予定である．

員が各開発工程の中でソースコードや障害報告をリア

また，図 10 のプロジェクト 100 件分の散布図を表

ルタイムで閲覧する機会が多数あるため，不正が発覚

示するのに要した時間は約 46 秒であった．分析結果しやすい．また，不正なコードの混入や不適切な障害の表示時間については，データベースのチューニング

報告を行うと，結果的に他の開発者及びプロジェクトやストアドプロシージャの定義によって，ある程度の全体の作業を阻害することになるため，故意に不正を処理時間の改善は可能であるが，今回 EPM を導入し働きにくい．
9電子情報通信学会論文誌 xxxx/xx Vol. Jxx–D–I No. xx

二つ目は，開発者が日常的に頻繁に使用する開発支援システムを利用している点である．短期的な情報操作 (生産性を一時的に高く見せることなど) は比較的容易であるが，EPM の分析機能によりリアルタイム
でソースコードの規模推移やファイルの更新回数・時期をチェックできるため，中長期的に見れば短期的な情報操作を行った時期のデータは不自然であることが一目瞭然となる (不正が発覚しやすい)．従って，一度不正を行うと，つじつまを合わせるために日々コメン
トを水増しするなどを継続する必要が生じる (手間がかかりすぎる)．
これらの理由から，EPM を利用したソフトウェア
開発では，人為的情報操作を行うメリットが開発者個人には少ないと考えられることから，情報操作の可能性は低いものと思われるが，今後様々なプロジェクトに EPM を適用し検証していく必要がある．
プロジェクト管理への効用：プロジェクトの状態は，グラフの特徴的な部分について確認することで容易に把握することができる．例えば，EPM 開発プロジェク
トの場合，図 4 中の中央やや右の部分では行数の成長が止まり水平になっている．この部分は担当者全員が出張し開発作業を行っていなかった期間である．実際の開発現場においても，他のプロジェクトのトラブルによって開発者の作業が中断するなど，同様の状況が生じる可能性がある．従来の方法では管理者が注視していない限り早くて週単位，場合によっては月単位でないと把握できない事象である．リアルタイムにデータを収集し可視化を行うことで，より容易に状況把握が可能になったといえる．
また，表示されるグラフからプロジェクトに問題が存在することも明らかになる．例えば，図 8 の中央の折れ線は，1 件あたりの障害に対して，障害の報告から解決までに要する時間を示しているが，日々増加していることがわかる．この原因は，次バージョンで解決方法を決定するとした障害を放置していたためである．現在は件数が少ないため大きな問題ではないが，他に障害が多数発生した場合に混乱が生じる恐れがある．このような問題をグラフから容易に発見することが可能になったことから，プロジェクトを適切に管理するための対策が講じやすくなることがわかった．
このような議論を行うためのデータ集計・分析・可視化は，従来の手作業によるデータ入力支援システムの利用のみでは容易な作業ではない．EPM は，プロ
ジェクトの状況理解・問題発見を行うための議論の場
10

図 11 CVS の運用方法の変更
Fig. 11 Change of CVS operation

で，客観的な情報を提供する有益なシステムであると考えることができる．
プロセス改善への効用：複数の企業の開発者によって開発が行われたこと，EPM 導入期間が約 3ヶ月であったこと，EPM 開発プロジェクトは研究的側面が強い (試行錯誤の過程が長く仕様も明確に決まりにくい) こと等から，アジャイルソフトウェア開発を行った．このため，従来のウォーターフォール開発プロセスとの比較がしづらく，今回の評価では開発プロセスの大幅な改善と結論付けるような事象を確認することはできなかった．
しかしながら，可視化された開発データに基づいて，

EPM 運用のために必要なルールを作成するなど，共同作業を円滑に進めるための規約が，徐々に開発チーム内に構築されていった．例えば，可視化結果の背景に示されるチェックイン縦線が予想以上に多く，各バー
ジョンと各種データとの関係の判別が困難になることがあった (図 11 のグラフ左から 3 分の 2 部分)．日々
チェックインを行う開発者がいたため縦線が多数表示されたたことが原因である．これは CVS の運用上の問題であり，チェックインのルールを予め決めておく必要があることが認識された．対処方法として，バッ
クアップ用とリリース用に CVS を分けておき，更新と参照の関係を見るにはリリースの CVS を，日々の規模の変化などを見るにはバックアップの CVS を参照するようになった（注 4）．この結果，バージョンごとの作業の状況把握 (図 11 のグラフ右 3 分の 1 部分) や日々の作業の把握が可能になった．
今回の例は小さな改善ではあるが，定量的データ収集に基づくプロセス改善では，このような積み重ねを行うことが問題点の「視える化」につながる．EPM（注 4）：2004 年 1 月中旬以降，CVS の運用方法を変更．

論文／ソフトウェア開発プロジェクトのリアルタイム管理を目的とした支援システム

文を適用することによって，開発者自らが問題点を視えるように工夫を行なった点については，今後のプロセ[1]ス改善へ向けて価値があるものであったと考えている．
具体的なプロセス改善の効用については，現在，約

若松義人, 近藤哲夫, “トヨタ式改善力,” ダイヤモンド社,
東京, 2003.

[2]

川又英紀, “IT 業界もトヨタ流企業改革から始めてみては？,” http://itpro.nikkeibp.co.jp/free/ITPro/

10 社の企業が実プロジェクトにおいて EPM を導入中
であり，これらの EPM 適用結果が得られ次第，検証

献

OPINION/20040123/138653/, 2004.
[3]

M. C. Paulk, B. Curtis, M. B. Chrissis and C. V. Weber, “Capability maturity model (version 1,1),” IEEEを行う予定である．

Software, vol.10, no.4, pp.18–27, 1993.

6. ま と め[4]“CMMI product team: capability maturity model
integration (CMMI) version 1.1,” CMMI for systems engineering and software engineering, continuous representation, (CMMI-SE/SW, v1.1, continu-

本研究は，信頼性や生産性に課題の多いソフトウェ
ア開発の分野において，科学的根拠に基づく開発手法
である実証的ソフトウェア工学 (Empirical Softwareous), CMU/SEI–2002–TR–001, 2002.
[5]

clopedia of Software Engineering, ed. J. J. Marciniak,

Engineering) の確立を目指し，EASE (Empirical Approach to Software Engineering) プロジェクトの一環として，産学官連携の共同研究として行われたもの

vol.2, pp.851–860, John Wiley and Sons, New York,
1994.
[6]

V. Basili,“Applying the goal question metricparadigm in the experience factory,” Presented at theである．

10th Annual Conf. of Software Metrics and Quality
Assurance in Industry, Amsterdam, 1993.

本論文では，実践的なプロセス改善支援を目的として構築した Empirical Project Monitor (EPM) につ[7]ment,” Technical Report ISERN-96-05, Department

管理者及び開発者は常時，プロジェクトの進捗状況や

of Computer Science, University of Kaiserslautern,
Germany, 1996.

作業状況を客観的に把握することが可能になる．その効用として，プロジェクトの問題点を的確に発見しや[8]

Proc. of the 16th intl. Conf. on Software Engineering

施を期待できる．試作した EPM を現行の EPM 開発
果，開発者に大きな作業負荷を与えることなく当該プ(ICSE’01), pp.331–340, Tronto, Canada, 1994.
[9]pp.722–728, 2004.
[11]

システム–お手軽にリアルタイムの生データ–,” ソフトウェ

また，プロセス改善に有効な様々なシステムを評価検

アシンポジウム 2004 論文集, pp.119–127, 2004.
[12]

M. Ohira, R. Yokomori, M. Sakai, K. Matsumoto,
K. Inoue and K. Torii, “Empirical project monitor:

実装し提供していく予定である．

A tool for mining multiple project data,” Proc. of

本研究の一部は文部科学省「e-Society 基盤

1st intl. Workshop on Mining Software Repositories

ソフトウェアの総合開発」の委託に基づいて行われた．

(MSR2004), pp.42–46, Scotland, UK, 2004.
[13]

M. Ohira, R. Yokomori, M. Sakai, K. Matsumoto,
K. Inoue and K. Torii, “Empirical project monitor:

研究提案公募制度による研究助成を受けて行われた．

automatic data collection and analysis toward soft-

本研究を遂行するにあたり多くの御協力を頂いた

ware process improvement,” 第 1 回ディペンダブルソ

EASE プロジェクト関係者諸氏に感謝します．特に，

フトウェアワークショップ (DSW2004) 論文集, pp.141–
150, 2004.

大阪大学の井上克郎教授，奈良先端科学技術大学院大学の松本健一教授、同客員教授の鶴保征城氏に深く感阪井誠, 大平雅雄, 横森励士, 松本健一, 井上克郎, 鳥居宏次, “EPM: 導入の容易な開発データ自動収集・分析支援

ス改善への効果をより詳細に明らかにする必要がある．

また，本研究の一部は文部科学省独創的革新技術開発

井上克郎, 松本健一, 鶴保征城, 鳥居宏次, “実証的ソフト
ウェア工学環境への取り組み,” 情報処理, vol.45, no.7,

今後の課題としては，EPM 適用企業からの結果を討し，EPM の分析・可視化用コンポーネントとして

The EASE (Empirical Approach to Software Engineering) project, http://www.empirical.jp/[10]

ロジェクトの状況を分析できることを確認した．
分析し，EPM のプロジェクト管理効果およびプロセ

J. G. Brodman and D. L. Johnson, “What small
businesses and small organizations say about CMM,”

すくなるため，より効果的なプロセス改善活動の実
プロジェクトに適用しシステムの有効性を検証した結L. Briand, C. Differding and D. Rombach, “Practicalguidelines for measurement-based process improve-

いて述べた．EPM を利用したソフトウェア開発では，

謝辞

W. S. Humphrey, “Process maturity model,” in Ency-[14]

J. Gremba and C. Myers, “The IDEAL model: apractical guide for improvement,” Appeared in the

謝致します．また，本論文をまとめるにあたり貴重な

Software Engineering Institute (SEI) Publication,

コメントを頂いた査読者の方々に感謝します．

Bridge, Issue 3, 1997.

11電子情報通信学会論文誌 xxxx/xx Vol. Jxx–D–I No. xx[15]

K. Torii, K. Matsumoto, K. Nakakoji, Y. Takada,
S. Takada and K. Shima, ”Ginger2: an environment
for CAESE (computer-aided empirical software engineering),” IEEE Trans. on Software Engineering,vol.25, no.4, pp.474–492, 1999.

[16]

P. M. Johnson, H. Kou, J. M. Agustin, Q. Zhang,
A. Kagawa and T. Yamashita, “Practical automated横森励士 （正員）1975 年生．1999 年大阪大学基礎工学部

情報工学科卒業．2003 年同大大学院博士課程修了．同年同大産学官連携研究員．博士 (工学)．プログラム構造解析の研究に従事．情報処理学会，IEEE 各会員．

process and product metric collection and analysis ina classroom setting: lessons learned from HackystatUH,” Proc. of the 2004 intl. Symposium on Empirical
Software Engineering (ISESE2004), pp.136–144, Redondo Beach, CA, 2004.
[17]

J. Froehlich and P. Dourish, “Unifying artifacts andactivities in a visual tool for distributed software development teams,” Proc. of the 26th intl. Conf. on
Software Engineering (ICSE’04), pp.387–396, Scotland, UK, 2004.

[18]

T. Zimmermann, P. Weissgerber, S. Diehl and
A. Zeller, “Mining version histories to guide software

阪井誠 （正員）

1962 年生．1984 年大阪電気通信大学工学部電子機械学科卒業．同年 SRA に入社．
以来，ソフトウェア開発・研究開発に従事．
2001 年奈良先端科学技術大学院大学情報科学研究科博士後期課程修了．同年 SRA
先端技術研究所シニア研究員．博士 (工学)．
開発支援環境，グループウェア，セキュリティに興味を持つ．情報処理学会，IEEE，ソフトウェア技術者協会各会員．

changes ,” Proc. of the 26th intl. Conf. on Software
Engineering (ICSE’04), pp.563–572, Scotland, UK,
2004.
[19]

J. D. Herbsleb, A. Mockus, T. A. Finholt and R. E.
Grinter, “An empirical study of global software development: distance and speed,” Proc. of the 23rd intl.
Conf. on Software Engineering (ICSE’01), pp.81–90,

岩村

聡1975 年生．1999 同志社大学工学部電子工学科卒業．同年 NTT ソフトウェア株式会社に入社．以来，ソフトウェア開発・研究開発に従事．

Toronto, Canada, 2001.
[20]

D. German and A. Mockus, “Automating the measurement of open source projects,” Proc. of the 3rdWorkshop on Open Source Software Engineering,
pp.63–67, Portland, Oregon, 2003.

[21]

A. H. Dutoit and B. Bruegge “Communication metrics for software development,” IEEE Trans. on Software Engineering, vol.24, no.8, pp.615–628, 1998.

[22]

The SPARS (Software Product Archiving and Retrieving System) project, http://iip-lab.ics.es.osakau.ac.jp/SPARS/index.html.en

[23]

新海

平

1974 年生．2001 年大阪大学大学院理学研究科博士後期課程中退，同年 (株) 日立
システムアンドサービスに入社．研究開発
センタ，生産技術センタで Web システム開発に従事．2003 年よりエンピリカル環
境における EPM 開発に従事．

茂呂雄二 (編著), “実践のエスノグラフィ,” 状況論的アプ
ローチ 3, 金子書房, 東京, 2001.
（平成 xx 年 xx 月 xx 日受付）小野英治

1975 年生．2000 年大阪大基礎工学部情報工学科卒業，同年日立公共システムエン
ジニアリング株式会社に入社，以来，ソフトウェア開発・研究開発に従事．

大平雅雄

1974 年生．1998 年京都工芸繊維大学工芸学部電子情報工学科卒業．2003 年奈良先端科学技術大学院大学情報科学研究科博士課程修了．同年同大学産学官連携研究員．
2004 年同大学情報科学研究科助手．博士(工学)．HCI, CSCW, CSCL 等の研究に従事．教育システム情報学会，ACM, IEEE 各会員．

横川智教

1977 年生．1999 年大阪大学基礎工学部

情報科学科中退．2001 年同大学院基礎工学研究科博士前期課程修了．2004 年同大学
院博士後期課程修了．同年岡山県立大学情報工学部助手．博士 (工学)．システムの形
式的検証に関する研究に従事．IEEE 会員．

12

Abstract The goal of our research project (the EASE project) is to establish Empirical Software Engineering, a development approach based on scientific evidence, in the field of software development where
there are many issues regarding reliability and productivity. We have been developing a computational environment for supporting practical software process improvement. This paper describes Empirical Project
Monitor (EPM) which is an automatic data collection and analysis system. EPM automatically collects andmeasures history data accumulated during everyday software development activities. By providing graphical views of measurement results, EPM helps developers and managers keep their projects under control inreal time without additional work.
Key words Software Process Improvement, Automatic Data Collection, Quantitative Data Analysis,
Empirical Software Engineering