ソフトウェアタグ・ガイドブック 2010
Software Tag Guide Book 2010

z ソフトウェアタグ技術解説・日本語篇
Overview of Software Tag (in Japanese)z ソフトウェアタグ技術解説・英語篇
Overview of Software Tag (in English)

z ソフトウェアタグ規格 第 1.0 版
Software Tag Standard Revision 1.0(in Japanese)

StagE プロジェクト
StagE Project

奈良先端科学技術大学院大学
Nara Institute of Science and Technology

大阪大学
Osaka University

Part1. ソフトウェアタグ技術解説・日本語編

技術解説「事故前提社会に向けたユーザ/ベンダ間での開発データ共有」（全三回）「StagE プロジェクトとソフトウェアタグ」
SEC ジャーナル 2009 年 6 月号掲載
「ソフトウェアタグ規格とソフトウェアタグ支援ツール」
SEC ジャーナル 2009 年 7 月号掲載
「ソフトウェアタグ普及に向けた法的議論と利用技術基盤」
SEC ジャーナル 2009 年 8 月号掲載

P52-57-技術解説 09.6.25 6:02 PM ページ 198 (1,1)

技術解説

事故前提社会に向けた
ユーザ・ベンダ間での開発データ共有

第1回−StagEプロジェクトとソフトウェアタグ−奈良先端科学技術大学院大学 ソフトウェア工学講座
文部科学省StagEプロジェクト研究代表者

松本 健一
この技術解説では、ユーザ・ベンダ間でのソフトウェア開発データの共有を通じて、
安心・安全なIT社会の実現を目指す、文部科学省StagE ※ 1 プロジェクトの活動とこれまでに得られた主な成果を数回にわたって紹介していく。
第1回となる本稿では、プロジェクトの概要、とくに、ソフトウェアタグとタグを用いた情報共有の基本概念、タグ普及に向けて研究開発を進めている基本技術のあらましと今後の取組み予定について紹介する。

いる」と白書では述べられている。電子情報技術産業協

1. はじめに
1. はじめに会（JEITA）が2006年に発表した「海外・国内企業におけるソフトウェアのオフショア開発についての調査・分
析と提言」でも、『日本企業のオフショア開発能力レベル

米国商務省国立標準技術研究所（NIST）が2002年に実の平均は、「オフショア活用方針・基準」、「計画・契約」、

施した調査によると、ソフトウェアのバグによる米国内「実行管理」、「評価」すべてにおいて、米国企業を下回る』

での損失額は年間595億ドル、国内総生産の0.6%にも上と指摘されている。

る[NIST2002]。日米間でソフトウェア開発プロジェクト「ユーザとの関係」、とくに、ユーザ・ベンダ間のコミの成功率に大きな差が無いことから、日本の国内総生産

ュニケーションが良好でないと、オフショア開発でなく

515.8兆円（2007年、名目）を基に単純計算すると、ソフ

とも、コスト／スケジュール超過、品質低下、モチベー

トウェアバグによる日本国内での損失額は年間約3兆円

ション／モラル低下、といったソフトウェア開発リスクにも達しているということになる。

が増大する場合がある。例えば、ユーザ・ベンダ間で非日米間で状況が異なる面もある。総務省が発表した情機能要件に関する事前合意が十分になされていなかった

報通信白書平成20年版によると、日本の主要ITベンダの
表1

営業利益率は、日本国内で6.4%、海外ではわずか1.8%でITベンダ営業利益率ある（表１）[MIC2008]。一方、米国ITベンダは、米国内

国内で15.6%、海外で13.7%である。日米間で営業利益率に数倍の差があることも問題であるが、日本ベンダの海外での利益率の低さは際立っている。
「ユーザとの関係が確立されていない海外市場で日本ベンダは苦戦を強いられて

海外

日本

6.4%

1.8%

米国

15.6%

13.7%

出典：情報通信白書平成20年版（総務省）※1 StagE：Software traceability and accountability for global software Engineering

198

SEC journal Vol.5 No.3 Jun.2009

P52-57-技術解説 09.6.25 6:02 PM ページ 199 (1,1)

ために、設計レビューにおけるバグの見逃し件数がおよ

発：ソフトウェア構築状況の可視化技術の普及：エンピ

そ3倍になったという事例もある。

リカルデータに基づくソフトウェアタグ技術の開発と普ユーザ・ベンダ間で良好なコミュニケーションを実現及」である。その目的は、ソフトウェア開発が適正な手する1つのアプローチは、ソフトウェアの開発状況を示順で行われたかどうかを表す実証データをユーザ・ベン

す実証データ（開発データ）の共有である。これにより、ダ間で共有する枠組みを構築し、その基盤となる技術をユーザは、ベンダが提示する開発・管理計画や進捗報告

世界に先駆けて開発することである。ユーザ・ベンダ間の妥当性を確認することが出来、自らのソフトウェア要でのデータ共有のメディアとして提案されているのが求が、開発プロジェクトの進捗と共に、どのように実装、「ソフトウェアタグ」である。

検証されていくのかを実感出来るようになる。一方、ベ

ソフトウェアタグとは、ソフトウェア開発に関する実

ンダも、ユーザと共同で開発リスクの低減に取組むこと

証データから、ソフトウェアやその開発プロジェクトのが出来、自らの説明責任やコンプライアンスを明確にす

特徴量を算出し、ユーザにも理解しやすく、可視化や評ることも容易になる。

価にも利用しやすい形式でとりまとめた情報パッケージ

内閣官房情報セキュリティセンターが2009年2月に発である。ソフトウェア開発終了後にソフトウェア製品に表した「第2次情報セキュリティ基本計画」においても、添付され、ベンダからユーザへ提供されることになるが、「事故前提社会」への対応力強化のため、「冷静で迅速な

開発途中に進捗報告書に添付するといった利用形態も考対応、説明責任の明確化」、「利用者にとっての安全・安えられる。

心の確保」等を実現すべきであり、とくに、重要インフ

ソフトウェアタグの基となる実証データは、次の3種

ラ分野においては、「IT障害の発生は隠すべきものではな類に大別される。

く、関係者間で共有すべき」とある[NISC2009]。我々が① 開発期間、開発規模、開発工数、総不具合数等、開発行ったアンケート調査でも、「ユーザの95%、ベンダの92%が、開発データ共有の有用性を強く認識している」との結果が得られている[StagE]。

プロジェクトのプロファイルデータ② 構成管理システムや不具合（障害）管理システムの記録（ログ）、進捗会議資料

本技術解説では、ユーザ・ベンダ間でのソフトウェア③ 要求仕様書、設計ドキュメント、プログラムコード、

開発データの共有を通じて、安心・安全なIT社会の実現

テスト報告書等中間成果物や最終成果物の作成・更新を目指す、文部科学省StagEプロジェクトの活動とこれ履歴までに得られた主な成果を数回にわたって紹介していく。

いずれも、今日のソフトウェア開発プロジェクトでは、第1回の本稿では、StagEプロジェクトが提案するソフト

開発管理のために一般的に収集され電子的に保存されてウェアタグとタグを用いた情報共有の基本概念、タグ普いるデータである。ソフトウェアタグ生成のためのデー及に向けた取組み等について概説する。

タ収集コストは比較的小さいと考えられる。
ソフトウェアタグは、ベンダからユーザへの一方的な

2.

ソフトウェアタグ

2. ソフトウェアタグ

情報提供の手段と考えられがちであるが、必ずしもそうではない。例えば上記③には、ユーザから開発当初に出された仕様要求に関するデータが含まれ、②には、開発

StagEプロジェクトとは、文部科学省からの委託により途中にユーザから出された仕様変更依頼とその結果発生

奈良先端科学技術大学院大学と大阪大学が2007年8月かした構成変更や不具合に関するデータが含まれる。他に

ら5年計画で実施している研究開発プロジェクトであるも、受け入れテスト等において、ユーザ主導で行われる[StagE]。正式名称は、「次世代IT基盤構築のための研究開作業があれば、それらの実証データからは、ベンダより

SEC journal Vol.5 No.3 Jun.2009199

P52-57-技術解説 09.6.25 6:02 PM ページ 200 (1,1)

技術解説

もむしろユーザに関する特徴量が算出されることになる。

報告に対して、ベンダはユーザと同様の立場となる。もソフトウェアタグが実現する安心・安全なソフトウェ

し妥当性の確認出来ない進捗報告があれば、その原因をア開発のあらましを図１に示す。プロジェクト計画時、究明し、対策を講じることで、説明責任やコンプライア

ベンダは、当該プロジェクトと類似するプロジェクトでンスの体制を強化することが出来る。

生成されたソフトウェアタグを、自らの開発・管理能力を示す実績データとして開発・管理計画書に添付することが出来る。一方、ユーザも、保有するソフトウェア

3.

ソフトウェアタグ技術
3. ソフトウェアタグ技術（ソフトウェア資産）に添付されているソフトウェアタグの情報と開発・管理計画書を比較することで、自らの組

StagEプロジェクトでは、ソフトウェアタグによる開発

織や業務領域（ドメイン）において、開発・管理計画がデータの共有を実現する基本技術として、「ソフトウェア

妥当かどうかを確認することが出来る。

タグ規格」、「ソフトウェアタグ利用シナリオ」、「ソフト

プロジェクト実行時、ベンダは、当該プロジェクトでウェアタグ支援ツール」の研究開発を進めている。更に、その時点までに生成されたソフトウェアタグを進捗報告

それら3つの技術によって実現されるソフトウェアタグ

書に添付することで、報告書に嘘偽りはなく、自らの業の法的意義についての検討も行っている（図2）。詳細に界や社内標準に照らして妥当であると示すことが出来る。

ついては次回以降で解説するとして、ここではそのあら一方、ユーザも、自らの業界や社内標準に照らして進捗

ましを簡単に紹介する。

報告書の妥当性を確認することが出来るだけでなく、開発リスクを早期に検知し、必要な改善要求をベンダに出

3.1 ソフトウェアタグ規格

すことが可能となる。なお、ベンダが開発作業の一部をソフトウェアタグ規格は、タグの構造やタグ情報とし外部ベンダに委託している場合、外部ベンダからの進捗て含めるべき項目や形式を定義したドキュメントである。

プロジェクト計画時

ソフトウェア要求

ソフトウェアタグ

ベンダ

ソフトウェア開発に関する実証データから、
ソフトウェアやその開発プロジェクトの特ユーザ

徴量を算出し、ユーザにもタグ付
開発・管理計画書

理解しやすく、可視化や評価にも利用しやすい形式でソフトウェア資産の開発・管理実績

プロジェクト実行時

妥当性の確認

とりまとめた情報パッケージ。
類似プロジェクトでの開発・管理実績

承認
改善要求

OK

ベンダ

NG
ユーザ

業界や社内標準

タグ付
進捗報告書
妥当性確認
リスク原因究明
明確化プロセス実感

業界や社内標準OK
オフショアを含む
外部ベンダ
妥当性確認
リスク原因究明

図1 ソフトウェアタグが実現する安心・安全なソフトウェア開発

200

SEC journal Vol.5 No.3 Jun.2009

P52-57-技術解説 09.6.25 6:02 PM ページ 201 (1,1)

13組織31名からなる「ソフトウェアタグ規格技術委員会」

グ規格で規定された具体的なデータに対応付けると共に、での議論を経て、2008年10月に「ソフトウェアタグ規格

開発データを収集するタイミング、解釈方法や評価基準

第1.0版」が公開された（表2）[StagE]。

等を記したドキュメントである。タグ利用を効率良く、

ソフトウェアタグ規格第1.0版は、対象ソフトウェアがまた、効果的に実施するためのドキュメントであるが、開発されたプロジェクトの特性と開発時の進捗状況を表

ユーザ・ベンダ間での合意形成を助ける道具とも言える。

す計41個のタグ項目で構成されている。タグ項目ごとに、

現在、ソフトウェアタグ利用シナリオに求められる要

具体化例や基となる実証データ例が記載されており、ソ件を明らかにするための実証実験を、株式会社東京証券

フトウェアタグ利用シナリオやソフトウェアタグ支援ツ取引所と株式会社日立製作所の協力を得て実施中であるールのベースと言える。

（図3）。

3.2 ソフトウェアタグ利用シナリオ

3.3 ソフトウェアタグ支援ツール

ソフトウェアタグ利用シナリオとは、開発データ共有

ソフトウェアタグ支援ツールは、ソフトウェアタグ規の目的や目標といった抽象的な概念を、ソフトウェアタ

格やソフトウェアタグ利用シナリオに準拠したデータ収集を容易にし、「見える化」や「開発計画策定」といったソフトウェア開発管理への応用を助ける道具である。
現在開発を進めているタグデータ収集システムの概要を図4に示す。システムへの入力は、開発データ履歴とソフトウェア
タグ規格

収集設定である。開発データ履歴とは、IPA/SECで検証
プロジェクトが実施されているEPM※2[EASE][EPM]等で収ソフトウェアタグ
利用シナリオ

ソフトウェアタグ
支援ツール

法的意義

ユーザ
発注
（株式会社東京証券取引所）

統括ベンダ（株式会社日立製作所）

重要インフラのため、品質要求が高い。
外部システムとの連携が多く、要件が複雑。

大規模システム開発では、外部要員（組織）の活用が必須。
開発体制が複雑で、品質確保が困難。

発注

独立系
ソフトハウス関連会社
ベンダ

独自の企業文化や開発スタイル
流動的な要員

海外ベンダ（韓国、中国）シナリオ１：外部委託での仕様伝達（オフショア管理）
シナリオ２：要件定義・変更管理（ユーザ・ベンダ間調整）

図2 ソフトウェアタグ技術

図3 ソフトウェアタグ利用シナリオ構築に向けた実証実験

表2 ソフトウェアタグ規格第1.0版（一部）
分類

項番

タグ項目

具体化例
ユーザヒアリング実施件数（回）

要件定義
13

ユーザヒアリング情報

ユーザヒアリング項目数（件）、
ユーザヒアリング回答率（ユーザヒアリング回答数
÷ユーザヒアリング項目数）等

14

規模[推移]

画面、機能項目、ユースケース、
アクター、顧客要件、機能、FP等

15

変更[推移]

規模の計測単位に依存

規模[推移]

機能設計（ページ数・帳票数・画面数・ファイル数・
項目数・UML図の数、クラス数、バッチプログラム数、重要な機能数等）
構造設計（データ項目数、DFDデータ数、DFDプロ
セス数、DBテーブル数 等）
等

予定・実績
の要否

収集方法特定収集設定

収集したいタグ項目○

収集対象

対象データ特定○タグ項目算出開発データ履歴
タグ項目値

設計
16

17

変更[推移]

規模の計測単位に依存

18

要件の網羅率設計に取り入れられた要件数÷要件数

タグ集計○

ソフトウェアタグ支援データ

データ収集システム

図4 タグデータ収集システム概要

SEC journal Vol.5 No.3 Jun.2009201

P52-57-技術解説 09.6.25 6:02 PM ページ 202 (1,1)

技術解説

集されたデータや、プロジェクト開発フォルダのバック

理を分析することによって、未然に紛争を防止する。

アップ（の系列）等である。収集設定とは、開発データ② ソフトウェア開発において、ソフトウェアタグをプロ

履歴と収集すべきタグ項目の対応関係を示すものである。

ジェクトマネジメントに利用するだけでなく、ユーザ

タグデータ可視化ツールTagReplayerの画面例を図5にとベンダで共有し、これを活用することによって、紛示す。TagReplayerは、「ある時点」でのプロジェクトの争処理に係る労力を軽減し、ひいては、動かないコン状態をあたかも録画したビデオを再生するように提示すピュータを減らす。

ることが出来る。先述のタグデータ収集システムと同様

具体的には、ソフトウェア構築における紛争や失敗事に、EPMで収集されたデータを入力とすることが出来例について、文献・判例分析、ソフトウェア開発企業にる。

対するヒアリング／アンケート等を行い、ソフトウェア
開発におけるトラブルの実態を明らかにすると共に、弁3.4 ソフトウェアタグによる可視化に伴う法的諸問題

護士等法律の専門家とソフトウェア技術の専門家の文理

StagEプロジェクトにおける法的な議論の目的は次の2融合領域からなる法的問題検討委員会を設立し、研究の方向性を定めている。

つである。
① コンピュータが動かなかったときに、事後的な紛争処

以上のように、ソフトウェアタグによる開発データの共有は、「見える化」に代表される定量的アプローチの１つである。ただし、ユーザ・ベンダ双方の視点を取り入れる等、新しい点も多い。関連する既存の組織・プロジ
ェクトでの取組みとStagEプロジェクトとの違いを表3にまとめる。

図5 タグデータ可視化ツール TagReplayer
表3 既存組織・プロジェクトでの取組みとStagEプロジェクトとの比較関連研究を行っている組織・プロジェクト

StagEプロジェクト

ISGSG

ベンチマーキングデータの提供。

タグ規格準拠ツールを開発中。

（オーストラリア）

データ収集ツールが提供されておらず、組織間でのデータ共有が目的。

組織間でのデータの整合性に問題あり。
NASA Metrics

プログラムコードレベルのメトリクス、

プロジェクトのプロファイルやData Program

障害データ、要求に関するデータが蓄積、公開されている。

進捗状況に関するデータも対象。

（米国）

開発プロセスを把握出来るデータは含まれていない。

Fraunhofer

ドイツ最大の研究機関の一研究所で、研究開発の成果を、
ソフトウェアタグ規格、IESE

産学連携を通じたエンピリカルソフトウェア工学を推進している。

ツール、利用シナリオ等として公開。

（ドイツ）

データや分析結果が広く公開されることはない。

HackyStat（米国）、

ベンダ、
もしくは、ユーザの視点でデータが収集、ベンダ・ユーザ双方の視点での、

IPA/SEC、蓄積されている。

ソフトウェア開発の見える化。

。。。
経済産業省

情報システム・モデル取引・契約書等により、

ユーザ・ベンダ間でやり取りされる（日本）

ユーザ・ベンダ間でやり取りすべきドキュメントやドキュメントの評価や組織間比較を可能に手順を規定している。

（左記とは補完関係）。

法的観点からも議論。

JUAS（日本）、…

※2 EPM：Empirical Project Monitor

202

SEC journal Vol.5 No.3 Jun.2009

P52-57-技術解説 09.6.25 6:02 PM ページ 203 (1,1)

4. 実用化・普及に向けてに向けて
2007年8月のプロジェクト開始から約2年が経過し、様々な技術的検討を経て、「ソフトウェアタグ規格第1.0

ークAPSERN ※ 3 の設立に向けた準備会議を、オーストラ
リアNICTA※4、中国ISCAS※5の研究者と共に開催し、活動
基本方針の策定、具体的な活動内容の検討を始めている。
2009年12月には、APSERN設立記念ワークショップをマレーシアで開催する予定である。

版」を始めとする具体的な成果も得られてきている。今後は、ソフトウェアタグの実用化・普及に向けた次のよ
うな取組みにより注力する予定である。

5.

おわりに
5 おわりに① ソフトウェアタグ規格やツールの標準化
ソフトウェアタグを一般的なものとし、多くのユー以上が、文部科学省StagEプロジェクトとソフトウェ

ザ・ベンダで共有するためには、タグ規格やツールの標

アタグの概要である。プロジェクトを進めるに当たり、準化が必要である。StagEプロジェクトが実施したアンケ

多くのユーザ・ベンダ企業にご協力いただいてきたこと

ート調査の結果でも、多くのユーザが、開発データの共もあり、最近では、国の戦略的取組みへの波及も見られ有の実用化・普及の方策として、「データやその共有方法

るようになってきている。例えば、経済産業省商務情報の標準化」を挙げている。ソフトウェアタグ規格につい政策局情報処理振興課が2009年3月に意見公募の対象とてはJIS化やISO化に向けた取組みをIPA/SEC等と、ツーして公表した「高度情報化社会における情報システム・ルについてはデファクトスタンダードに向けた取組みを

ソフトウェアの信頼性及びセキュリティに関する研究会

ツールベンダと、それぞれ行っていく予定である。

の中間報告書（案）」では、「複雑化する情報システム・② ソフトウェアタグ実証実験の推進

ソフトウェアの信頼性及びセキュリティ水準を高度化す

ソフトウェアタグの有用性をユーザ・ベンダに具体的るためには、ソフトウェアタグの高度化と現場への適用に示すことも実用化・普及には必要である。StagEプロジを検討する必要がある」とソフトウェアタグの重要性がェクトが実施したアンケート調査の結果でも、多くのベ述べられている[METI2009]。

ンダが、開発データの共有の実用化・普及の方策として、

次回以降では、ソフトウェアタグによる開発データの「開発データの共有（ユーザへの開示）のメリットの明確共有を実現する基本技術「ソフトウェアタグ規格」、「ソ化」を挙げている。開発データの共有に対するユーザ・

フトウェアタグ利用シナリオ」、「ソフトウェアタグ支援

ベンダニーズに基づくソフトウェアタグ利用シナリオ案

ツール」、及び、それらによって実現されるソフトウェア

を幾つか作成し、実際のソフトウェア開発プロジェクト

タグの「法的意義」について、具体的な成果を交えて詳に適用することで、タグ利用の具体的なイメージやメリしく紹介していく。

ットを明確にしていく予定である。

参考文献③ 国際連携の強化[EASE] http://www.empirical.jp/[EPM] http://sec.ipa.go.jp/tool/epm.html[JEITA2006] 電子情報技術産業協会：海外・国内企業におけるソフトウェアのオ
フショア開発についての調査・分析と提言，2006[METI2009] 経済産業省 商務情報政策局 情報処理振興課：高度情報化社会における情報システム・ソフトウェアの信頼性及びセキュリティに関する研究会の中間報告書（案），2009[MIC2008] 総務省：情報通信白書平成20年版，2008[NISC2009] 内閣官房情報セキュリティセンター：第2次情報セキュリティ基本計
画，2009[NIST2002] National Institute of Standards and Technology：The Economic Impacts of
Inadequate Infrastructure for Software Testing，2002[StagE] http://www.stage-project.jp/

オフショア開発は、ソフトウェアタグによる開発デー
タ共有の主要な適用対象の１つである。日本からのオフ
ショア開発圏となるアジア・太平洋諸国の研究開発機関と連携し、ソフトウェアタグの妥当性や有用性を検討す
ることは、実用化・普及に大きく貢献すると考えられる。
既に、アジア・太平洋圏ソフトウェア工学研究ネットワ※3 APSERN：Asia-Pacific Software Engineering Research Network※4 NICTA：National Information/Communication Technology Australia※5 ISCAS：Institute of Software Chinese Academy of Sciences

SEC journal Vol.5 No.3 Jun.2009

203

技術解説

事故前提社会に向けた
ユーザ・ベンダ間での開発データ共有

第2回−ソフトウェアタグ規格とソフトウェアタグ支援ツール−
大阪大学
大学院情報科学研究科 教授

大阪大学
大学院情報科学研究科 教授

奈良先端科学技術大学院大学
情報科学研究科 教授

井上 克郎

楠本 真二

飯田 元

第１回は、「ソフトウェアタグ」と、ソフトウェアタグの開発、普及を目指す「StagE ※1 プロジェクト」の概要について述べた。
第2回である今回は、ソフトウェアタグの規格の第1.0版の詳細と、ソフトウェアタ
グを効率良く作成するためのデータ収集支援ツール及びソフトウェアタグのデータを可視化し分析するツールについて述べる。

等が可能となる。

1. はじめに

今回は、ソフトウェアタグの規格の第1.0版の詳細と、ソフトウェアタグを効率良く作成するためのデータ収集
支援ツール及びソフトウェアタグのデータを可視化し、

前回第1回（SEC journal No.17）は、「ソフトウェアタ

分析するツールについて述べる。

グ」と、ソフトウェアタグの開発、普及を目指す「StagE
プロジェクト」の概要について述べた[松本2009]。
ソフトウェアタグは、ソフトウェアシステムのユーザ

2.

ソフトウェアタグ規格第1.0版
2．ソフトウェアタグ規格第1.0版（発注者、購入者、利用者）が、納品された、あるいは購入・流用したシステムを安心して安全に用いるために、

2.1 ソフトウェアタグの規格化

ソフトウェアの開発プロセスやソフトウェア製品（プロ我々は、ユーザが購入し利用しようとするソフトウェダクト）に関する情報をベンダ（開発者、販売者）と共

アシステムの品質や性能に関して、定量的な評価を行え有する仕組みである。このように開発時に得られる種々るようにするために、ソフトウェアタグをソフトウェアのデータ（実証的（エンピリカル）データ）をユーザに取引に導入することを提案している。

提供することにより、どのような指標があれば、ユーザが定量的な評価を行・ユーザによるソフトウェア品質の検証

えるようになるかに関して、ソフトウェアのベンダ企業、・ユーザによる適正なソフトウェア製品の選択促進

ユーザ企業、及び大学や政府機関等の13機関31名が集ま・問題発生時の対応の迅速化って、計13回の委員会（ソフトウェアタグ規格技術委員

・透明性の拡大による法的問題の発生の予防と早期の公会）を開き、議論を積み重ねてきた（参加組織について

正な解決の促進※1 StagE：Software traceability and accountability for global software Engineering

234

SEC journal Vol.5 No.4 Sep.2009

は第1回を参照）。そして、この委員会で、2.2節で述べる

特集

実践活用へ向けて活発化するSECの『定量的アプローチ』

表2 タグ規格第1.0版（進捗情報）

41種類の指標（ここでは「タグ項目」と呼ぶ）の集合を
ソフトウェアタグ規格第1.0版とすることを決めた（2008分類

年10月14日）[StagE2008]。以降、本稿では、このソフト

項番

タグ項目

説明

13

ユーザヒアリング
情報要件に関してユーザに行ったヒアリングに関する情報

14

規模[推移]

開発側で作成した要件数

15

変更[推移]

変更された要件数

16

規模[推移]

設計成果物の規模※新規・改造・再利用(流用)毎に計測する

17

変更[推移]

変更された設計成果物の数、もしくは変更量18

要件の網羅率

要件定義で作成された要件の実装率19

規模[推移]

プログラミング成果物の規模※新規・改造・再利用(流用)毎に計測する

20

変更[推移]

変更されたプログラムの数、もしくは変更量

21

複雑度

プログラムの品質（保守性）

22

規模[推移]

テストの規模※新規・改造・再利用(流用)毎に計測する

要件定義

ウェアタグ規格第1.0版のことを単に「タグ規格」と呼ぶことにする。

設計

2.2 タグ規格の全体像
タグ規格は、プロジェクト情報として12項目（表1）、
進捗情報として29項目（表2）の合計41項目から構成さ
表1
分類

プログラミング

タグ規格第1.0版（プロジェクト情報）
項番

タグ項目

説明

23

変更[推移]

変更されたテスト項目数や変更量

1

プロジェクト名

プロジェクトを一意に決定するための識別名

24

密度

テストの品質2

開発組織の情報

当該プロジェクトの開発を担当する組織の情報。
一般には、受注者となる組織情報となる。

25

消化テストの進捗、
プログラムの品質

26

レビュー状況

成果物(仕様書、設計書、プログラムコード、
テスト仕様書など）のレビューに関する情報

3

開発プロジェクトの特徴や当該タグデータの対象
開発プロジェクト とするプロジェクトの種類を示す情報。タグデータ
情報の解釈や分析時に必要なデータ。

27

レビュー作業密度

レビュープロセスの品質、
もしくはレビュー対象の品質

28

レビュー指摘率[推移]

レビュープロセスの品質、
もしくはレビュー対象の品質

29

欠陥件数[推移]テスト設計の品質とコード品質30

欠陥対応件数欠陥の対応進捗、対応内容

31

欠陥密度

テスト設計の品質とコード品質

32

欠陥指摘率

テスト設計の品質

33

静的チェックの結果 プログラムの品質（保守性）

34

作業工数

作業に要する工数、仕様変更作業工数

35

生産性

工数に対する成果物の比率36

プロセス管理情報 開発プロセスの管理に関する情報

37

会議実施状況

38

累積リスク項目数 リスク認識が十分であったかを把握

39

リスク項目の滞留時間 リスク対策が適切になされていたかを把握

40

規模[推移]

対象成果物の規模※新規・改造・再利用(流用)毎に計測する

41

変更[推移]

変更された対象成果物の数、もしくは変更量。

テスト

基本情報

4

5

顧客情報

当該システムのユーザ、
もしくは第1発注者となる組織の情報。

システム構成開発システム構成の特徴や当該タグデータの対象とするシステムの種類を示す情報。タグデータの解釈や分析時に必要なデータ。

システム情報開発情報

6

システム規模開発システムの規模。計画値と最終実績値とする。
進捗情報に同じ情報が含まれる場合は、省略可。

7

開発手法

開発システム開発に用いたプロセスや手法についての情報。タグデータの解釈や分析時に必要
なデータ。

8

開発体制

開発側の要員に関する情報。タグデータの解釈や分析時に必要なデータ。

品質

工数※開示対象範囲は、発注者・受注者側での協議により決定する

プロジェクトの階層構造情報その他

9

プロジェクト期間

当該プロジェクトの開発期間に関する情報10

親プロジェクト情報

本プロジェクトが別のプロジェクトのサブ(子)プロ
ジェクトである場合、付加

11

サブ(子)
プロジェクト情報

本プロジェクトがサブ(子)プロジェクトを持つ場合、その数やサブ（子）プロジェクトに関する情報

特記事項

その他、
タグデータの解釈や分析時に必要、もしくは有用なデータ。

12

表3
分類

項番

タグ項目

ユーザ・ベンダ間、ベンダ間での情報共有状況を把握

計画・管理

その他成果物

具体化例や実証データ例(一部)
説明

具体化例

実証データ例

ユーザヒアリング実施件数（回）
ユーザヒアリング項目数（件）、ユーザヒアリング回
答率（ユーザヒアリング回答
数÷ユーザヒアリング項目数）など

予定・実績の要否

備考○
ユーザヒアリング議事録ユーザヒアリング質
問票など

13

ユーザヒアリング情報要件に関してユーザに行ったヒアリングに関
する情報

14

規模[推移]

開発側で作成した
要件数

画面、機能項目、ユースケー
ス、アクター、顧客要件、機 要件定義書など
能、FPなど15

変更[推移]

変更された要件数

規模の計測単位に依存

要件定義

○

何を要件の基本単位とする
かは、要合意事項

要件定義書
要件定義書の変更履歴など

SEC journal Vol.5 No.4 Sep.2009

235

技術解説

れる。

表4 あるプロジェクトのタグの例（一部）
分類

項番

基本情報

タグ項目

プロジェクト情報は、基本、システム、開発、プロジ

計測値

1

プロジェクト名

A大学新規教務システム

2

開発組織の情報

要求定義：B株式会社
設計、実装、
テスト：C株式会社3

開発プロジェクト情報開発プロジェクト種別：新規

4

顧客情報

開発プロジェクト形態：受託開発

ェクトの階層構造の情報とその他に分類され、それぞれは1〜4個のタグ項目を含んでいる。同様に、進捗情報は、
要件定義、設計、プログラミング、テスト、品質、工数、

顧客：A大学教務掛
5システム構成OS：Windows
ブラウザ：Internet Explorer
その他：Adobe Reader

6

システム規模26033行（Java、一部の実装サイズ）

7

開発手法

オブジェクト指向開発

8

開発体制

要求仕様作成チーム：B株式会社（5名）
設計仕様作成チーム：C株式会社（3名）

9

プロジェクト期間

要求・設計期間：2007年3月27日〜5月31日
実装期間：2007年12月3日〜2008年2月28日まで

10

親プロジェクト情報

11

サブ（子）プロジェクト情報

12

特記事項

システム情報開発情報

プロジェクトの階層構造情報その他

計画・管理、その他成果物に分類され、それぞれ2〜8のタグ項目を含んでいる。
各タグ項目は、それを表す名前（例えば「プロジェク
ト名」）とその簡単な説明（「プロジェクトを一意に決定するための識別名」）から構成されている。
タグ規格として決めているのはここまでで、具体的にどういう記述、メトリクス、データをタグ項目として開

分類

基本情報

設計

タグ項目

13

ユーザヒアリング情報

ヒアリング回数

414

規模[推移]

ユースケース図数1215変更[推移]

ユースケース図数4816規模[推移]

UML図数

128

17

変更[推移]

UML図数

434

18

要件の網羅率19

規模[推移]

行数（全体）

20

変更[推移]

変更量（追加＋削除行数）

プログラミング21

計測すべきメトリクス

計測値

26033
88841

WMC※２

6.277551

LCOM※310.955102

NOC※40.7387755

DIT※5

2.8081632

複雑度

CBO※6

10.43

RFC※7

12.995918

22

規模[推移]

テストケース数23

変更[推移]

テストケース数24

密度

テストケース数/全体行数

テスト

品質

発者からユーザに受け渡すのかは、二者間で取り決めて

項番

617
617

決定する。
本タグ規格では、この二者間の取り決めを容易にする
ため、表3のように、メトリクスの例を示している。また、そのメトリクスを収集するための実証データの例も示している。実際にはこの中から適当なものを選んで利用しても良いし、また、別のメトリクスを用いることも可能である。
「予定・実績の要否」は、対応する具体化例のデータを収集する前に、あらかじめ目標値（予定値）
を設定し、その予定と実績の管理をすることが望ましいものであることを示している。

0.023725

消化消化テスト数584

26

レビュー状況

レビュー回数

21

27

レビュー作業密度

レビュー時間/全体時間28

レビュー指摘率[推移]レビュー指摘数649

29

欠陥件数[推移]

全体欠陥件数1930

欠陥対応件数

全体欠陥対応件数

19

31

欠陥密度

全体欠陥件数/行数

0.000730

32

欠陥指摘率

全体欠陥件数/消化テスト数

33

静的チェックの結果

FindBugs指摘件数

34

作業工数

作業時間

35

生産性

行数/作業時間36

プロセス管理情報37

会議実施状況

38

累積リスク項目数

39

リスク項目の滞留時間40規模[推移]

41

変更[推移]

1

0.0325
52

25

20

15

152日

系列1

工数

計画・管理

その他成果物

※2 WMC：計測対象クラスの重み付きメソッド数※3 LCOM：計測対象クラスの凝集性の欠如※4 NOC：計測対象クラスのサブクラス数

236

SEC journal Vol.5 No.4 Sep.2009

171.3（行/日）

10

5

0

図１

レビュー回数（項番26）のデータの推移※5 DIT：計測対象クラスの継承の深さ※6 CBO：計測対象クラスに関係しているクラス数※7 RFC：計測対象クラスに関係しているメッセージ数

特集

2.3 タグの実例

実践活用へ向けて活発化するSECの『定量的アプローチ』（2）タグ項目の選定のポリシー

表4に実際のプロジェクトの情報から作成したタグのベンダ内で通常収集されている種々のデータの中で、例を示す。対象は、ある大学の教務システムの開発プロユーザにとって簡潔で理解しやすいものを、バランスにジェクトである。ここでは、具体的に計測したメトリク

配慮してタグ項目とした。ユーザが持つ「対象のソフト

スを決めて、計測を行ったデータを集計したものを示し

ウェアシステムはどんなものか？」、「どのように作られている。この表では、例えば、複雑度に関しては6つのたか？」という疑問に対して、タグ項目の大分類のプロ

メトリクス（WMC ※2、LCOM ※3、NOC ※4、DIT ※5、CBO ※6、

ジェクト情報と進捗情報を用意している。

RFC ）を計測することにして、プロジェクト終了時点「どんなものか？」に対応するプロジェクト情報は、のプログラムに対して計測した値を示している。実際に以下のような5種類の情報に分類し、対応するタグ項目

は、プロジェクト終了時、作成された29個のモジュール群を設けた。

それぞれの複雑度メトリクスを平均した値を示している。

・プロジェクトの基本情報→基本情報※7

この例で利用しなかった（計測しなかった）項目は斜・稼動するシステムの情報→システム情報

線を引いている。この例のように、二者間で合意すれば・開発の基本的な情報→開発情報

41項目すべてを利用する必要は無い。

・プロジェクト間の関連情報→プロジェクトの階層構造利用した各メトリクスの多くは、日単位で計測されており、そのデータもタグに含めている（大きくなるので

情報
・その他→その他

ここでは表示していない）。図1は、レビュー状況（項番

また、「どのように作られたか？」に対応する進捗情報

26）のメトリクスとしてレビュー回数を選び、その回数

は、主にISO/IEC 12207/SLCP ※ 8 の開発プロセスを元に、の増加をグラフ化したものである。ユーザは、このよう各工程の情報を用意すると共に、品質や工数の情報を加なグラフや値を見て、プロジェクトの進捗や品質を評価

えた。

する。

・要件定義、設計、プログラミング、テストの各情報
・品質の担保情報

2.4 タグ規格の考え方

・工数情報（1）ユーザ視点の実証的データの提供

・計画・管理情報

通常、ベンダは、プロダクトの品質向上や組織の生産・その他性向上等のために、種々のデータ（実証的データ）を収集し、フィードバックを行い、プロジェクトや組織を改（3）二者間の取り決め

善することが当たり前である。このようなフィードバッ

本タグ規格は、ソフトウェアタグとしてベンダからユ

クループは、もっぱらベンダ内に閉じているが、ソフト

ーザにどのようなデータ集合を提供するかを詳細に規定

ウェアタグの仕組みで目指すのは、ユーザを巻き込んだするものではない。提供すべき大枠を示しているのみで、

大きなフィードバックループによる改善である。ユーザ

詳細に関しては、ユーザ、ベンダの二者間で決める必要が提供される各タグ項目のデータを評価し、プロジェクがある。決める必要のあるものとしては、

トの品質について積極的に関与することで、プロジェク

・41項目のどのタグ項目を利用するか（全部の利用が前

トの透明性が向上し、安心・安全なソフトウェアシステ
ムの構築や運用につながる。

提ではない）
・各タグ項目として用いるメトリクス
・各メトリクスの計測対象（全システム一括、サブシス※8 SLCP：Software Life Cycle Process

SEC journal Vol.5 No.4 Sep.2009

237

技術解説

テムごと、各ファイルごと等）

これらと同様、ソフトウェアタグは、数十項目のソフ・計測頻度

トウェアプロジェクトやプロダクトに関するメトリクス

・タグとしてユーザに提供する時期（毎週、毎月、工程データをユーザに開示し、プロジェクトやプロダクトのごと等）

健全性、品質等の評価をする際の重要な指標になる。

等がある。
（4）タグ項目のデータが改ざんされるのでは？
2.5 議論
ここでは、ソフトウェアタグ及び本タグ規格に関する幾つかの論点を示す。

このような可能性はあり得るが、整合性のあるデータ
を複数の項目、複数の版にわたって偽造や改ざんするのは容易ではない。一方、3節で述べるように、開発環境
からデータを抽出しタグ化することは比較的容易である。

（1）もっと多くのタグ項目が必要では？
現実のソフトウェアの開発現場では、もっと多様なデ

このように、偽造や改ざんには大きなコストがかかる上に、発覚した場合のため一時は計りしれない。

ータを集め、分析を行って、改善活動を行っている。そタグ項目のデータの基礎となる開発時の詳細なデータのうちのごく一部だけをユーザに提示することに、どれ全体を第三者に預託しておき、紛争時にタグのデータのだけの効果が得られるかは、不明な部分も多い。しかし、正当性を検証出来るような枠組みを作っておくのも良い

規格として一般化する場合の、タグの収集・構成コスト

方法かもしれない。

や中小プロジェクトでの実現可能性等のバランスを考え、本規格を定義した。より大規模なプロジェクトでは、そ（5）タグ規格の今後の方向性については？

の他の項目をタグとして追加することも可能で、逆に小現在の第1.0版では、出来るだけ用途を広くするために、規模なプロジェクトでは、本規格の一部のみを利用する

具体的なメトリクスやその収集方法を規格として規定しことも可能である。

ていない。しかし、実際に対象とするプロジェクトを前（2）進捗報告会議との違いは？
ソフトウェアタグの仕組みとほぼ同様な情報提示を、ユーザと定期的に開く進捗報告会議で行っているベンダは多い。二者間できちんと情報交換して品質を担保しようとする場合、タグ項目のデータは当たり前のものと言えよう。従って、ソフトウェアタグとそのような会議での情報交換は、同様な効果をもたらす。本規格は、このようなユーザを含めた改善活動を普及させるための基礎となる。
（3）タグの仕組みの分かりやすいアナロジーは？
人間ドックは、対象者の健康度を知るために数十項目にして、どのようなメトリクスを利用するか、41項目のタ
グすべてユーザとベンダが協議することは簡単ではない。
従って、ある程度よく利用されるパターンを想定して、メトリクスやその計測方法を具体化した追補規定の設定を考えている。例えば、「中規模エンタープライズシステ
ム開発において、ベンダの開発活動を正しく伝えるための追補規定」、「新規開発案件において、要件の間違いや法的問題の発生を少なくするための追補規定」等が考えられる。また、メトリクスが具体化すれば、予想される標準値もSECのデータ等を参考にして盛り込むことも可能になる。さらにこれらの作成のために、タグ規格第1.0版を改良していくことも必要かもしれない。

のデータを収集、分析して対象者に示し、健康状態を知ることが出来るようにする。また、企業の決算報告等で用いられる財務諸表は、企業の資金や資本の大きさや動3. ソフトウェアタグ支援ツール

きを数十項目の金額で示し、投資家や取引先に開示し、その企業の健全性を示す。

238

SEC journal Vol.5 No.4 Sep.2009

ソフトウェアタグ支援ツールは、ソフトウェアタグ規特集

実践活用へ向けて活発化するSECの『定量的アプローチ』

格やソフトウェアタグ利用シナリオに準拠したデータ収

ソフトウェアタグ実用化サービス基盤

関連する
外部規格
等

規格・テンプレート群集を容易にし、見える化や開発計画策定といったソフト
ウェア開発管理への応用を助ける道具である。図2にソフトウェアタグ実用化技術俯瞰図を示す。図に示す通り、

タグ検証・監査基盤
タ
グ
の
運
用

タグ可視化・分析基盤

タグ公開基盤

アタグ実用のために重要な役割を果たす。
各ツールは機能的観点から、タグの生成のための基盤、

タ
グ
の
生
成

ソフトウェアタグ
記述言語

タグデータ収集基盤

開発データ計測基盤

図2

ソ
フ
ト
ウ
ェ
ア
タ
グ
規
格

プ
ロ
セ
規ス
格・
品
等質
関
連
JAZZ

支援ツールはタグ実用化サービス基盤の要素として位置付けられ、タグ規格やガイドラインと共に、ソフトウェ

ソフトウェアタグ
評価用標準書式

ツ
ー
ル
規
格
等

エンピリカル
データ記述言語

契
約
指
針
等

契
約
指
針
等

ラガ
イイ
ンド
サ
ン
プ
ル
シ
ナ
リ
オ
・
ケ
ー
ス
ス
タ
デ
ィ
・
教
材
等

受
益
者

取
得
者

開
発
者

利
用
者

供
給
者

ソフトウェアタグ実用化技術俯瞰図（簡略版）

及び運用のための基盤に大別されるが、本稿ではとくに重要である以下の2つのカテゴリに属するツールについて紹介する。

プロジェクト全体の構造を表示
個々のプロセスや収集するタグデータの定義を修
正可能① タグデータ収集基盤：ソフトウェアタグの生成に必要なデータを収集する仕組を提供する② タグ可視化・分析基盤：ソフトウェアタグを活用する
ために、その内容を可視化し、分析するための仕組を提供する
タグデータ項目を一覧表示

3.1 タグデータ収集基盤
タグデータ収集基盤には、開発プロジェクトで収集さ図3 タグデータ定義画面例

れデータを基にソフトウェアタグを作成するツールが含まれる。ここでは、タグデータの事前選定と計測計画立案ツール「タグ・プランナー」と実際にタグデータの収個々の作業と、その作業で収集するタグデータを可視化して表示集を行うツール「CollectTag」について述べる。
3.1.1 タグ・プランナー
タグ・プランナーは、タグデータの収集計画立案を支援するツールで、プロジェクトマネージャ等の役割を持
つ利用者が、システムの発注時等、開発着手前、データ

タグデータに関する詳細な情報を表示定義の閲覧者収集計画の作成、調整等の作業を容易に行えることを目的としている。対象プロジェクトで作成す

図4 策定したプロジェクト計画の閲覧画面例

るタグの内容をあらかじめ策定し、具体的な機能として
タグデータの構造や定義作成を支援し、可視化して表示

細を閲覧し、編集を行うことが出来る。また、WBSやタする機能を持つ。

グデータの構造自体をカスタマイズする機能も有する。

図3は、タグデータ定義画面の例である。対象プロジ

本ツールで作成したタグデータ収集計画の内容は後述す

ェクトの作業構造はWBS ※9 の形で画面左に表示されておるXMLスキーマに従った形式で保存されるので、他のタり、画面下部には、タグデータ項目が一覧表示されていグツールとの連携が可能である。

る。画面右側のエリアでは、個々のタグデータ定義の詳

図4は、策定したプロジェクト計画中で扱われるタグ※9 WBS：Work Breakdown Structure

SEC journal Vol.5 No.4 Sep.2009

239

技術解説

データをWBS中の各作業からたどって閲覧する画面の例

タグ収集ツールを、ユーザとベンダが契約時に取り決めである。画面下部には対象プロジェクトで収集するタグ

た個々のタグデータを適当なタイミングで入力し、そのデータの選択内容がチェックリスト形式で示されており、結果を標準タグデータフォーマットに変換するトランス

画面右には、各作業中で収集されるべきタグデータが表

レータと位置付ける。

示されている。このように、タグ・プランナーで作成し② 低コストでの収集た収集計画は、ユーザ・ベンダ間でタグ収集項目を検討

タグ作成のために利用される実証データは今日のソフ

し、合意を取る際に利用可能であると共に、プロジェク

トウェア開発組織では開発管理を行う上で一般的に収集

ト実行中のデータ収集やタグ生成の際のガイドラインとされ、電子的に保存されているデータであると考えられしても活用出来る。本ツールは、我々の開発したるため、ソフトウェアタグ生成のためのデータ収集コス

AQUAMarineツール[伏田2009]を基に試作を進めている。

トは比較的小さい。また、個々のメトリクスについても、ベンダは自社の定義に基づいて計測をしている。従って、3.1.2 Collect Tag（ソフトウェアタグデータ収集ツール）
本ツールは、開発プロジェクトで収集されている実証①で述べた方法であっても、タグ作成のコストは少ないと考える。

データを基にソフトウェアタグを実際に作成する。タグ

しかし、すべてのタグ項目をベンダが入力することは

データは、プロファイル情報と進捗情報に分けられる。

現実的では無い。そこで、典型的な開発環境やメトリク

プロファイル情報はプロジェクトを特徴付ける基本情報

スを利用する場合は、自動収集の機能を提供することをであるため、一度確定されるとほとんど修正が入らない目指す。例えば、ソースコードがCVSやSubversionのよと考えられる。一方、進捗情報は成果物や作業の進捗、

うな構成管理ツールで、またバグ情報がバグ管理ツール

成果物やプロセスの品質等を表すものであるため、適当でそれぞれ管理されているような場合は、これらに依存な頻度で計測をする必要がある。以降では、進捗情報のしたタグデータ項目は自動的に収集し、計測する機能をデータ収集を中心に話を進める。

提供する。

タグデータ収集ツールに求められる要求を次に示す。
① 汎用性が高い③ ソフトウェアタグの出力
ソフトウェアタグデータは、XML形式で出力し、本プ② 低コストでタグデータが収集可能である

ロジェクトあるいはツールベンダ等が開発する可視化・③ ソフトウェアタグを利用・分析しやすい形式で作成す分析ツールとの効率的な連携を目指す。

る
以降、これらに対する基本方針を述べる。
① 汎用性の要求

3.1.3 プロトタイプ（Collect Tag）の開発
本ツールは現在、ソフトウェアタグ規格Ver.1.0に準拠

ソフトウェアタグの内容（個々のタグ項目に対応するして試作中である。図5に開発中のプロトタイプシステ

メトリクス）は、契約時にユーザとベンダが協議して決ムの入力画面を示す。各タグ項目を順番に選べ、具体的めることになっているため、当然であるが個々のソフトなメトリクスを決めていく。

ウェアタグは特定のベンダの開発環境から収集されるデ

例えば、図5で「プログラミング」−「規模」を選択ータより作成することになる。また、使用されるメトリ

すると、図 6 の画面になる。規模のメトリクスとしてクスの名前が同じであっても、ベンダ間で定義が異なる「行数」と「ファンクションポイント」が選択可能になっ場合も多い（例えば、ソフトウェアの行数であっても、ており、「行数」を選ぶと図7の画面になる。この画面で、コメント行・空行を含むか含まないか等の違いがある）。

ツールが対応しているリポジトリから自動取得する場合

従って、あらゆる実証データの収集やメトリクスの計測は、必要な情報を入力する。ツールが対応していない場に対応することは難しい。そこで我々は、ソフトウェア

合は、「手動で入力」を選び、決められたタイミングで数240

SEC journal Vol.5 No.4 Sep.2009

特集

実践活用へ向けて活発化するSECの『定量的アプローチ』

表5 自動収集可能なタグデータ
分類

項番

タグ項目

タグデータ

14

規模[推移]

ユースケース・アクターの数

15

変更[推移]

追加，変更されたユースケース・アクターの数

16規模[推移]

UML図の数17

変更[推移]

追加，変更されたUML図の数

19規模[推移]

コード行数20

変更[推移]

追加，変更されたコード行数

21

複雑度

CKメトリクス29

欠陥件数[推移]

不具合数

30

欠陥対応件数

不具合消化数31

欠陥対応密度

不具合数÷コード行数

要件定義

設計

プログラミング

品質

図5 画面例1（初期画面）
ファイル

XMLで出力図6

画面例2（規模の設定）

図8

XML形式への出力イメージ

定することでプラグインとして導入可能になる。
現在のプロトタイプでは、進捗情報の10項目を対象とし、表5に示すデータが自動収集可能になっている。
要件定義ではユースケース図の構成要素であるユース
ケース・アクターの数を収集する。設計では、UML図の数を抽出する。要件定義、設計共に計測対象はXMI形式
で出力されたモデル図である。プログラミングでは、一図7 画面例3（規模の自動収集・手動入力設定）

般的に構成管理ツールで管理しているリポジトリよりデータを抽出する。現在、SubversionとCVSに対応してい値を入力することになる。

る。複雑度メトリクスは、2.3節で述べた6つのメトリク

個々のタグ項目に対しては、標準的なメトリクスを選ス（CKメトリクス）を計測可能であるが、対象はJavaプ

択出来るようにすることを考えている。また、利用者がログラムのみである。品質では、バグ管理ツールで収集

直接値を入力する項目については、その値の基となる実されているバグデータから不具合数、不具合消化数等を

証データ名を合わせて入力する。

計測する。

自動収集に対応していないメトリクスについては、シ

図8にタグデータのXML形式での出力イメージを示す。

ステム利用者が自分でメトリクスの計測プログラムを作

現在、分析・可視化ツール研究グループとの間でXMLに成すれば、収集システムが提供するAPIを通じて、収集よる標準タグ形式を検討中である。

方法の設定時に作成したメトリクス計測プログラムを指今後の課題としては、自動収集するタグ項目の充実、

SEC journal Vol.5 No.4 Sep.2009

241

技術解説

どのようなイベントが発生したか

プロジェクト全体の概要をグラフ化

どのようなメールがやり取りされている
この人が何をしたかプログラムの大きさ
がどれくらい変化しているか

表6 現在開発中のソフトウェアタグ活用支援ツール
ツール名

機能・用途

タグ・プランナー

タグ計測・利用計画策定支援

CollectTag

実証データからのタグ生成

タグ・リプレイヤー

タグデータを利用したプロジェクト可視化

タグ・シミュレータ

開発プロセスをシミュレートし、結果をタグとして出力

EPM/Core（仮称）個人作業環境での実証データ収集

任意の時間に巻き戻すためのタイムバー

以降では現在プロトタイプ開発中の可視化・分析ツー
図9

タグ・リプレイヤーのメイン画面

タグ項目に対する基本メトリクスの設定やユーザビリテ
ィの向上が考えられる。

ルとしてタグリプレイヤーを紹介する。
3.2.1 タグ・リプレイヤー
タグ・リプレイヤーは、タグデータに含まれる様々な進捗情報を複数の表示形式で再現する統合的な可視化ツ

3.2 ソフトウェアタグ可視化・分析基盤ールである。 ある時点 でのプロジェクトの状態を、録ソフトウェアタグ可視化・分析基盤にはソフトウェア

画ビデオを再生するように提示することが出来るため

タグデータ収集ツールに等により生成されたソフトウェ（図9）、プロジェクトのレビュー（事後分析）等に有効

アタグの内容を、利用シーンに応じて適切に提示するツである。

ール等が含まれる。タグに基づいた分析を行うに際しては、ソフトウェア信頼性予測モデルに代表されるような、（1）タグデータ可視化機能

様々な既存モデルの活用が想定されるが、既存の分析技

タグリプレイヤーは、ソフトウェアタグデータ中に含術を一つひとつ基盤ツールとして実装するのはリソース

まれる進捗に関する情報をプロジェクトにおいて発生しの制約上非現実的である。従って、StagEプロジェクト期たイベントとして捉え、時系列に沿って網羅的に表示す

間中のゴールとしては以下の2点を設定している。

ることが出来る。サマリ的な情報としては、プロジェク① タグの内容を元にプロジェクト推移に関する基本情報

ト中で計測された各種データをグラフとして重畳表示すを再構成して分かりやすく提示する基盤機能を開発することが出来る。また、分析のためにプロジェクトをさるらに深く閲覧する機能として、開発者間の対話や障害報② 幾つかの分析手法について①の機能を使ってサンプル的な実装を示す。

告等のテキスト情報をマイニングし、表示する機能も備える。

現在は①の基本可視化ツールを中心に開発を進めている。ソフトウェアタグは進捗情報にかかわるデータを数（2）プロトタイプの開発多く含むので、これを中心とした可視化を考える。すな

タグ・リプレイヤーはEASE ※ 10 プロジェクトで開発さわち、時系列による推移を基本軸として、成果物、作業、れた「プロジェクト・リプレイヤー」[OHKURA2006]を元組織等の視点による粒度を、可視化の用途に応じて変化に、ソフトウェアタグ規格1.0の様々なデータ項目への対させて提示出来る仕組みを、可視化の基盤として提供す

応や、XML形式のタグ情報の読み込み、ソフトウェアメ

る。

トリクスのグラフ表示、テキスト情報のマイニング機能※10 EASE：Empirical Approach to Software Engineering，ソフトウェア工学へのエンピリカルアプローチ

242

SEC journal Vol.5 No.4 Sep.2009

特集等、大幅に機能を追加して開発中である。

実践活用へ向けて活発化するSECの『定量的アプローチ』

4.

4.

おわりに おわりに
3.4 その他のツールと全体のフレームワーク
誌面の都合上、本稿で紹介出来なかったツールを含め、本稿ではStagEプロジェクトにおけるソフトウェアタ

現在開発を進めている支援ツールの一覧を表6に示す。

グ規格化の経緯とその内容、及び、ソフトウェアタグ利

これらのツールは来年度の適用実験を通じて評価され、用支援ツール群の設計と試作の現状について紹介を行っ最終的にはソフトウェアタグ支援基盤サービス群のリフた。

ァレンス実装として公開予定である。

初年度及び2年目までの期間を通じて、まずはタグ規

なお、図2に示したように、ソフトウェアタグ活用技格の策定とそれを活用するツール群の概要設計を行って術としては、タグデータの収集と可視化・分析の他に、きた。現在はこれらの成果を受けてツール群のより具体

タグの公開・運用や検証・監査のための基盤サービス等的な設計と試作を行っている段階である。このように、が必要である。これらについては今後開発を行っていく

理論と実践、規格と実装の間を短期間でフィードバック

予定であるが、タグデータの閲覧制御や改ざん防止等、するアプローチ自体もStagEプロジェクトの特徴である

セキュリティ管理に相当する仕組みについては、現在のと考えている。

プロジェクト期間中には利用シナリオ等を通じたサービス仕様の策定までを行う予定である。

タグ規格については、今後、ツールやサンプルシナリ
オの開発、実証実験等の結果を基に、規格の内容自体をソフトウェアタグ規格、及び具体的なタグデータの記見直したり、タグ規格本体ではあえて規定していない具述言語仕様は、これら基盤サービス群に共通して準拠す

体的情報の補足や実践のためのガイドライン作成等も検べき要素である。ソフトウェアタグの重要な目的の一つ討している。

はシステム開発プロジェクト中で計測されるデータの構

現在開発中のタグ実用化支援ツール群は、本プロジェ

成を一定の自由度を保ちつつ、標準化することである。

クトの運用・検証担当班で作成が進んでいる「ソフトウ

従って、一連のソフトウェアタグ支援ツールにおいても、ェアタグ利用シナリオ」において有効に活用されるよう流通するタグのデータ形式は一定の抽象度において（つに設計が行われている。また、これらのシナリオに基づ

まり、ソフトウェアタグ規格1.0相当の粒度において）互

いたソフトウェアタグ適用実験においては、これらの試換性を持って取り扱われることが大前提である。

作ツール群の有効性・可用性についても検証を行ってい

StagEでは、データ収集及び可視化・分析ツールの予備く予定である。

設計を通じて、XMLによる具体的なソフトウェアタグ記

次回は、ソフトウェアタグの利用シナリオ・普及に向述用のスキーマ（仮称、StagE/ML）のドラフトを定め、けての取り組み、法的意義について紹介する予定である。

標準エンピリカル形式の開発データや代表的な開発支援
ツールのリポジトリ形式のデータからStagE/MLへの変換
ライブラリ等の整備を進めている。今後、言語仕様の規格化・公開を行う予定である。また、プロジェクト外の開発ツール群との連携についても検討を進めており、例
えば、IBM Rationalで開発中のチーム開発支援ツール群
Jazzで収集されたデータによるソフトウェアタグの生成の可能性についても検討している。

参考文献[OHKURA2006] Ohkura, et al.：Project Replayer with Email Analysis -- Revealing
Contexts in Software Development，In Proceedings of the 13th Asia Pacific Software
Engineering Conference（APSEC06），pp. 453-460，December 2006
[StagE2008] StagEプロジェクト−ソフトウェアタグ規格技術委員会：ソフトウ
ェアタグ規格 第 1.0 版，2008 年 10 月 14 日，http://www.stage-project.jp/
seika_dl.php[伏田2009] 伏田 他：AQUAMarine：定量的管理計画立案システム，SEC journal,
to appear，2009[松本2009] 松本健一：事故前提社会に向けたユーザ・ベンダ間での開発データ
共有−StagEプロジェクトとソフトウェアタグ−，SEC journal, pp.198-203，2009

SEC journal Vol.5 No.4 Sep.2009243

P366-374-技術解説 09.12.21 7:34 PM ページ 368 (1,1)

3
技術解説●

事故前提社会に向けた
ユーザ・ベンダ間での開発データ共有

第3回−ソフトウェアタグ普及に向けた法的議論と利用技術基盤−
奈良先端科学技術大学院大学
先端科学技術研究調査センター教授

奈良先端科学技術大学院大学
先端科学技術研究調査センター
研究員

奈良先端科学技術大学院大学
情報科学研究科
特任助教

奈良先端科学技術大学院大学
情報科学研究科
研究員

久保 浩三

小柴 昌也

角田 雅照

松村 知子

この解説では、文部科学省StagEプロジェクト※ 1 の概要を紹介すると共に、同プロジェクトが作成したソフトウェアタグ規格と、ソフトウェアタグ支援ツールについて述べてきた。最終回となる今回は、ソフトウェアタグ普及に向けたより実践的な取り組み
として、ソフトウェアタグの意義と技術的課題についての法的観点からの議論、及び、
ソフトウェアタグ利用の技術基盤となるユーザ・ベンダ協調型プロジェクト管理とソフ
トウェア開発データ分析モデリング言語について解説する。

添付され、ベンダからユーザへ提供されることになるが、

1. はじめに
1. はじめに

開発途中に進捗報告書に添付するといった利用形態も考えられる。ユーザ・ベンダ間でのデータ共有のメディアとも言えるが、実開発プロジェクトに適用するためには、

ソフトウェアタグとは、ソフトウェア開発に関する実

開発データ共有の目的や目標といった抽象的な概念を、証データから、ソフトウェアやその開発プロジェクトのソフトウェアタグ規格で規定された具体的なデータに対特徴量を算出し、ユーザにも理解しやすく、可視化や評応付けたり、タグ収集・可視化・評価ツールを活用した価にも利用しやすい形式でとりまとめた情報パッケージ

りするためのより実践的な技術が必要となってくる。

である。ソフトウェア開発終了後にソフトウェア製品に

本技術解説では、ソフトウェアタグ普及に向けた法的観点からの議論と2つの利用技術基盤について概説する。

ユーザ・ベンダニーズ

これらは、主にソフトウェアタグ利用シナリオとして具実開発
プロジェクト

現化することになるが、ソフトウェアタグ規格やソフト
ウェアタグ支援ツールにも今後反映されていくものであ

ソフトウェア
タグ規格

タグ収集・
可視化・
評価ツール

利用
シナリオ

る（図1）
。

2. ソフトウェアタグに対する法的議論

2. ソフトウェアタグに対する法的議論
法的観点からのタグの意義と技術的課題

ユーザ・ベンダ
協調型
プロジェクト管理

ソフトウェア
開発データ分析
モデリング言語

利用技術基盤

図1

ソフトウェアタグ技術を支える法的観点からの議論と利用技術基盤

2.1 目的と背景
ソフトウェア開発を成功させるためには、要件定義、レビュー等、すべての段階で注意が必要であり、ユーザ※1 StagEプロジェクト：Software Traceability and Accountability for Global software Engineering：エンピリカルデータに基づくソフトウェアタグ技術の開発と普及

368

SEC journal Vol.5 No.6 Dec.2009

P366-374-技術解説 09.12.21 7:34 PM ページ 369 (1,1)とベンダの双方において、契約の明確化、プロセスの可化に伴う法的諸問題委員会」を設置している。

視化、人材育成等のいろいろな試みが行われている。しこのような技術と法律による連携は、一般的に見られかし、ソフトウェア開発において、品質、コスト、納期

るものではない。確かに、これまでも、建設に係る法、のすべてにおいてユーザ・ベンダ間での紛争が多発して通信に係る法、情報と法、原子力と法等にも技術と法律

おり、現状においては減少傾向にはなく、問題がますまの連携は見られる。しかし、これらは、新たな技術を社

す複雑化してきているようにも見受けられる。

会に適用する場合に生ずる種々の問題を調整するために、

ソフトウェアタグに対する法的観点からの議論の目的

法律を制定し、その交通整理を行うことが主である。

は、ソフトウェア不具合時の事後的な紛争処理を分析す今回用いた手法は、ソフトウェア開発における紛争をることで、紛争を未然に防止することにある。また、ソ紹介、分析することで法律家が関与し、新たな技術課題

フトウェアタグを、プロジェクト管理に用いるだけでな

解決による新技術の開発手法の提案を行うという新規なく、ユーザとベンダで共有し、これを活用することによものである（図2）。この手法が、他の技術分野でも応用って、紛争処理に係る労力を軽減することも目的の1つ

出来るかどうかの検討も今後行っていく。

である。
2.3 具体的な取り組み
2.3.1 裁判例の抽出と分析

2.2 技術と法律の連携
ここで紹介する法的議論は、ソフトウェアタグに関す分析対象としたのは、平成2年以後のソフトウェア開る技術的議論との連携を目指したものである。例えば、

発委託取引を巡る20件の裁判例である。裁判事例は、後述するように、ソフトウェア開発における紛争の分析

TKC法律情報データベースにおいて、以下のキーワード

結果に基づいて、ソフトウェアタグへの要望をまとめてにより抽出した。
か しいる。技術と法律の連携を深めるため、法学部教授、弁（瑕疵＋仕様＋開発）×プログラム＝41件

護士等の法律の専門家、そして、ソフトウェアタグの技（瑕疵＋仕様＋開発）×ソフトウェア＝26件

術的専門家の双方で構成される「ソフトウェア構築可視（瑕疵＋仕様＋開発）×ハードウェア＝13件

従来の技術と法律の連携
フィードバックの欠如

新技術

本プロジェクトのアプローチ

なる調査により4件を追加した。
これらの裁判例を分析すると、ユーザのシステ

新技術

建設
通信

適
用

原子力

ム開発要求をベンダに伝えることの困難さに紛争

ソフトウェア構築

情報

適用する際に生じる問題の「回避」

ここから知的財産権に係る紛争を除外し、さらの原因の1つがあることが分かった。通常、ソフト
調法
整律
に
よ
る

技術的課題
解決
適
用

紛争

紛争

実社会
問題の「回避」であって本質的な解決には至りにくい

法律家による
分析

実社会
現象の法的な分析から本質的な技術解決へのフィードバックルートを築くことが出来る

図2 法的分析から技術的課題解決へのループ形成

ウェア開発は、RFP ※ 2 により、ユーザの要求がベンダに伝えられる。また、RFPを更に具体化した要求仕様書が用いられることもあり、これに基づいてベンダが要件定義を作成する。しかし、ユーザの要求をすべて伝えることは容易ではない。
また、ユーザからベンダに対して、開発工程の段階でも仕様変更やユーザの要求が提示されることが多く、当初よりも見積りが大きく膨れ上がり、また納期も延びることとなる。ソフトウェア開発※2 RFP：Request For Proposal，提案依頼書

SEC journal Vol.5 No.6 Dec.2009369

P366-374-技術解説 09.12.21 7:34 PM ページ 370 (1,1)

3
技術解説●

委託契約は、いわゆる請負型で行われることが多く、ユ名から回答を受け取った。得られた主な結果は次の通り

ーザは、自分の要求が満たされないと、業務が完成してである。

いないとして支払いを拒むケースがあり、紛争の元とな・ベンダの回答によると、ソフトウェア開発における見積り差異は、人月計算で1.8倍、金額計算で2倍であっっているように見受けられた。

た
2.3.2 アンケート調査

・見積り差異が生じたプロジェクトでの見積り方法は、

以上のように、ソフトウェア開発委託取引を巡る裁判「大まかな業務の説明」に基づくものがベンダ41%（最事例は、非常に少ない。そこで、判例分析で導き出されも多い原因）、ユーザ24%（2番目に多い原因）であった観点である「ユーザの要求がベンダに正確に伝わってた（図3）

いるか」という点についてアンケート調査を行った。調・見積り差異の発見段階は、ベンダでは「詳細設計」

査では、ソフトウェア開発費の見積額と開発に実際に要（21%）を筆頭に、「基本設計」（19%）、「要件定義」

した経費との差異（見積り差異）に着目した。2008年12（13%）という意見が多く、プログラミングに着手

月から2009年3月にかけて、インターネットも活用した

するまでの早い段階で問題が発覚していることが多い

アンケートの結果、ユーザ91名、ベンダ224名、合計315

（図4）

その他2％
ユーザの金額
5％

その他2％
ユーザ受入
テスト
14％

大まかな
説明
24％

コンサル
タント
11％

システム
テスト
15％

ユーザの
RFPのみ
37％

プログラム
開発
16％

ベンダが
調査分析
21％

要件定義
13％
基本設計
19％

詳細設計
21％

ユーザ

図4 見積り差異の発見段階
その他0％
ユーザの
金額
14％

その他
9％
ユーザの
RFPのみ
20％
ベンダが
調査分析
20％

大まかな
説明
41％

ベンダ

図3

370

ユーザ要求額
36％

話し合い
46％

コンサルタント
5％

見積り差異が生じたプロジェクトでの見積り方法

SEC journal Vol.5 No.6 Dec.2009

ベンダ要求額6％

開発中断
3％

図5 見積り差異の解決手段

P366-374-技術解説 09.12.21 7:34 PM ページ 371 (1,1)

・見積り差異の原因は、ユーザ・ベンダ共に「現場からようなソフトウェアタグを必要とするかを検討する必要の予想外の要求」（ユーザ30%、ベンダ27%）が、最もがある。今後は、当事者自身が、ソフトウェアタグをど多いのように活用していくかの観点から契約とソフトウェア

・見積り差異の解決手段は、「話し合い」（46％）を除き、タグについて法的議論を深めていく予定である。

ベンダが「契約通りの金額しか請求しなかった」（36%）
3. ユーザ・ベンダ協調型プロジェクト管理
ユーザ・ベンダ協調型

が最も多かった（図5）
このように、アンケート全体を通じて、ユーザとベン

3. プロジェクト管理

ダ間には意見の隔たりがあることが分かった。また、見積り差異が生じる原因として、あいまいな受発注による本章では、ユーザ・ベンダにWin-Winの開発管理形態を実現するための枠組みの2つのポイント、ユーザ・ベ

契約が根底にあることも分かった。

ンダ協調型プロジェクト管理サイクルと、このサイクル
2.4 ソフトウェアタグの意義と技術的課題を実現するための管理プロセスの構築手順について説明

裁判例等の紛争やアンケート回答を分析していくと、する。前述した法的紛争の事例や現場アンケートからも、

ソフトウェア開発における紛争は大きく2つの型に分類

ユーザのプロジェクト管理における責任や役割の重要性

出来ることが分かった。そして、法的議論の1つの結果は明確であるが、既存のソフトウェア開発の定量的管理として、それら2つの型それぞれにおけるソフトウェアの規格やガイドライン［CMMI2007］［PMBOK2004］は、タグの意義と技術的課題（技術的議論への要望）が明ら

いずれも開発組織の視点で作成され、ユーザは管理の対かとなった。詳しくは表1を参照されたい。

象の一部として扱われている。紹介する枠組みは、双方

ソフトウェアタグの内容をどのように要求するかは、
契約書の一部分として定めることであり、例えば、段階

にとって透明性の高い管理プロセスを実現し、問題の早期発見・解決を支援する。

的な請負契約をすることを業界標準として定めたときに、その段階ごとに、当事者が内容を確定するために、どの

表1

ソフトウェア構築に関する法的諸問題の分析
ソフトウェアタグの
技術的課題

今後の課題

紛争の型

法的責任

ソフトウェアタグの意義

未完成または欠陥により使用不可

ユーザまたはベンダの債務不履行責任

・ユーザに進捗を見せ、相互に管理を行う。
・開発が順調に進んでいることをユーザに知らせる。
・開発が順調に進んでいな
い場合の軌道修正を容易にする。

・ユーザの要望（要求定義） ・実証実験により、基準値、標準曲線を作成し、ユーザがベンダに伝わっているかの視認性を高めること（例：
どうかを明らかにすること。
人 間ドックにおける基 準・実績が予定通り進んでい値）。
ること（予実管理）
を行えるようにすること。

使用可ではあるが、完成後のバグ発生または障害発生

ベンダの不法行為責任または債務不履行責任・事故があった場合のトレースを容易にする。
・早期復旧を容易にする。

・システムがダウンする前に、 ・システムがダウンした場合の原因、修正履歴を残し、どこにバグまたは欠陥があ障害の発生率を下げるこるかのおおよその当たりをとが出来るようにすること。
つけること。

SEC journal Vol.5 No.6 Dec.2009371

P366-374-技術解説 09.12.21 7:34 PM ページ 372 (1,1)

3
技術解説●

とを要求する。

3.1 協調型プロジェクト管理サイクル
図6はPMBOK［PMBOK2004］に基づく従来のプロジェ
クト管理サイクルである。ユーザは、サイクル外に位置

3.2 管理プロセスの構築手順

付けられ、ベンダから提供されるデータに対してチェッ

次に、合意形成プロセスについて、我々は CMMI

クや要望を出す。これに対して、図7の我々が提案する［CMMI2007］のプロセス領域「定量的プロジェクト管理」

協調型プロジェクト管理サイクルでは、計画・監視・コを参考に以下のような定量的プロジェクト管理プロセス

ントロールのプロセスに関して、両者の合意・相互確の構築手順を提案する（図8）。

認・各組織での合意に基づいた適切な是正処置を行うこ① プロジェクト管理目標を設定し、両者で合意② ユーザ・ベンダ別に、目標に関わる作業（サブプロセ

プロジェクト・フェーズ

ス）を定義

計画プロセス群(Plan)③ 作業でユーザ・ベンダ間のコミュニケーションや共有

立ち上げプロセス群

される（べき）データを明確化

終結プロセス群④ ②③に基づき、定量的に管理するフェーズを構成

実行プロセス群(Do)
監視コントロール・
プロセス群
ベンダ
（受注者）

Act

Check
進品
捗質
報報
告告

要
望
・
依
頼

ユーザ(発注者)

成
果
物
・
品
質
報
告

⑤ 管理フェーズごとに定量的管理に関する目標、尺度、データの収集と格納方法、分析方法等で測定モデルを作成。このステップについては、前号で紹介したタグ
データの事前選定と計測計画立案ツール「タグ・プラ

リスク・課題Checkンナー」を適用可能
図6

従来のプロジェクト管理サイクル
プロジェクト・フェーズ
計画プロセス群(Plan)

ユーザ（発注者）
立ち上げプロセス群

終結プロセス群
実行プロセス群(Do)

ベンダ
（受注者）

監視
コントロール・
プロセス群

Act

Check

【合意形成】
計画プロセス群（Plan）【相互確認】
Check【是正措置】
Act

プロジェクト・フェーズ
計画プロセス群(Plan)
立ち上げプロセス群

終結プロセス群
実行プロセス群(Do)

ベンダ
（受注者）

監視
コントロール・
プロセス群

Act

Check

ベンダ（受注者）
図7 提案する協調型プロジェクト管理サイクル

372

SEC journal Vol.5 No.6 Dec.2009

P366-374-技術解説 09.12.21 7:34 PM ページ 373 (1,1)①プロジェクトの管理目標
管理プロセス

②ユーザ作業群
作業1

作業2④管理フェーズA
作業3
3

作業1

オフショア開発での仕様伝達
作業2

データ1
③共有データ・コミュニケーション
データ1
データ2

コミュニケーション1

コミュニケー
ション2

作業1

作業2

④管理フェーズB
作業3②ベンダ作業群
作業3

発注

ユーザ

⑤測定モデル

統括ベンダ

発注

要件定義・変更管理作業3

コミュニケー
ション2

関連会社
ベンダ
独立系
ソフトハウス⑤測定モデル

図8

海外ベンダ（韓国、中国）図9 実プロジェクトでの検証

定量的プロジェクト管理プロセスの構築手順

析の活動を記述するための記法である［角田 2009］。

3.3 実プロジェクト開発情報に基づく検証
上記の枠組みについて、数社から実プロジェクトのデ

SDAMLの利点は以下の3つである。

ータをご提供頂き、定量的データ分析とその結果に基づ・データ分析方法のノウハウの共有が容易になる

いた開発関係者へのヒアリングを繰り返し、管理プロセ

・データ分析の目的と方法を明確に示すことが出来るた

スの構築と実用性の検証を行った（詳細は、［松村2009-1］

め、ユーザとベンダ間でのデータ共有に関する合意が［松村2009-2］）。図9は検証に用いた2つのプロジェクト

しやすくなる体制（プロジェクトは異なる）と、おのおののプロジェ

・テンプレートの機能を果たすため、全くテンプレート

クトの管理目標を示す。対象プロジェクトでは、データが無い状態に比べ、記述するコストが低い

共有やコミュニケーションは十分に行われていて、既にSDAMLの役割は、直感的にはソフトウェアの仕様記述

定量的な管理に活用出来る基盤があり、実際に第3 者法であるUML ※4 の役割に、プログラム設計パターンのカ（StagEスタッフ）でも既存データの定量的分析からプロ

タログであるデザインパターンの役割を加えたものであ

ジェクトの状況を把握出来ることを確認した。また、検ると考えると分かりやすい。

証過程で、実プロジェクトへの適用のための幾つかの要件が抽出され、次章のモデリング言語へも反映された。

SDAMLは、データ計測・分析プロセスを記述するために、次の8つの要件を満たすように定義されている。
（R1） データ分析の目的と、目的を果たすために着目すべきデータ項目を記述出来ること

4. ソフトウェア開発データ分析モデリング言語

4.

ソフトウェア開発データ
分析モデリング言語（R2） 各データ項目の計測方法を記述出来ること（R3） 各データ項目の分析方法を記述出来ること（R4） 分析結果に基づいた、実施すべき対応策を記述出4.1 要件と構造
ソフトウェア開発データ分析モデリング言語SDAML※3とは、ソフトウェア開発における定量的データ計測・分

来ること（R5） データ計測・分析・共有の手順やタイミングを記※3 SDAML：Software development Data Analysis Modeling Language※4 UML：Unified Modeling Language

SEC journal Vol.5 No.6 Dec.2009373

P366-374-技術解説 09.12.21 7:34 PM ページ 374 (1,1)

3
技術解説●

の場合）ベンダのみの分析目的としかならず、それぞれ述出来ること（R6） ユーザ、ベンダそれぞれの分析目的を個別に記述を明確に区別して記述する必要がある。
（R7）はユーザとベンダでデータを共有し、かつプロジ出来ること（R7） プロジェクト進行中、及びプロジェクト完了時の

ェクト進行中とプロジェクト完了時の両方でデータ分析

データ分析方法を区別して記述出来ることを行う場合に必要となる要件である。例えば、「高い品質（R8） データ分析モデルの適用条件を記述出来ることのソフトウェアを開発する」ことを目的として、「出荷後（R1）〜（R5）は、一般的なデータ計測・分析プロセ

欠陥密度」に着目して分析しても、プロジェクト進行中

スの活動を記述するための要件である。
（R1）はデータに目的が達成出来そうかを判断することが出来ない。逆収集計画立案活動（PDCA※5サイクルのPlan）を記述するに、同じ目的で、プロジェクト進行中に「結合テスト欠陥ための要件、（R2）はデータ計測活動（PDCAサイクルの密度」と「システムテスト欠陥密度」に着目して分析する

Do）を記述するための要件、（R3）はデータ分析活動

ことを決めても、最終的に目的が達成されたかを判断す（PDCA サイクルの Check）、（R4）は対応策実施活動る基準を決めていなければ、ユーザとベンダで目的が達（PDCAサイクルのAct）を記述するための要件、（R5）は成されたかどうかの認識が一致しなくなる可能性がある。

データ計測・分析プロセスのフロー（PDCAサイクルの（R8）はデータ分析モデルをカタログ化する際に必要とフロー）を記述するための要件である。

なる要件である。過去のプロジェクトで作成されたデー（R6）はユーザとベンダでデータを共有する場合に必タ分析モデルを、新たなプロジェクトに適用する際、誤要となる要件である。ユーザとベンダのデータ分析目的

った評価をすること避けるためには、「どのようなプロジ

は完全に一致しない場合がある。例えば、「ソフトウェア

ェクトに適用出来るのか」、「プロジェクト実施中にどうの出荷後の欠陥数を抑える」はユーザ、ベンダ共通の分

いったことが起こると正しい評価が行えないのか」等が析目的となるが、「テスト効率を高める」は、（請負開発

明らかになっている必要がある。
SDAMLは、ISO/IEC 15939で定義されている測定情報モデル［ISO/IEC 15939］をベースにした記述法であり、測

(R8)

(R5)

定情報モデルと同様に、階層構造を持ったモデルである。
アウト
ライン

利用
タイミング

開始時
条件

測定情報モデルとは、データの計測から分析方法までを終了時
条件

ベンダゴールユーザゴール

解釈モデル

解釈モデル

管理指標(KGI)

管理指標(KGI)

階層構造により表したモデルである。図10にSDAMLの構
(R6)

(R1)
(R7)

解釈モデル

解釈モデル

管理指標(KPI)

管理指標(KPI)⁝造を示す。図では各要素と要件との対応関係、及び測定情報モデルに該当する部分を示している。
次節では、SDAMLの構成要素について説明する（誌面の都合上、主要な構成要素のみ説明する）
。

(R3)

対応策

分析モデル

⁝
(R2)

基本測定量

(R4)

測定情報
モデル

図10

SDAMLの構造と要件との関係※5 PDCA：Plan Do Check Action374

SEC journal Vol.5 No.6 Dec.2009

4.2 主要構成要素（1）アウトライン、利用タイミング
アウトライン、利用タイミングは、「データ計測・分析・共有の手順やタイミング（R5）」を記述するための要素である。アウトラインでは、利用シナリオ（分析モP366-374-技術解説 09.12.21 7:34 PM ページ 375 (1,1)

デル）の適用場面、ユーザ/ベンダの要求、データ計測、分析手順を具体的に記述する。要求分析におけるユース

高品質のソフトウェア
を開発する

Goal

ケースと類似した内容を記述すると考えるとよい。利用タイミングは、データの計測、データのユーザへの受け渡し、データ分析のタイミングを示した図であり、UML

Question

品質に影響する
要因は何か

高い品質は
得られたか

Metrics

欠陥密度

出荷後
欠陥密度

のアクティビティ図を使って表記する。
（2）基本測定量、分析モデル、管理指標、解釈モデル
基本測定量、分析モデル、管理指標、解釈モデルは（a）GQMによる記述例「各データ項目の計測方法（R2）」と「各データ項目の分
析方法（R3）」を記述するための要素であり、ISO/IEC
15939で定義されている測定情報モデルに基づいている。

解釈モデル

as<欠陥密度<ae
ならば正常

出荷後欠陥密度>cs
ならば正常

管理指標

欠陥密度

出荷後欠陥密度分析モデル

発見欠陥数÷開発規模

出荷後欠陥数÷開発規模

各要素の役割は以下の通りである。
・基本測定量：測定対象から直接計測される数値
・分析モデル：基本測定量に基づいて管理指標を計算する方法を示したモデル
・管 理 指 標 ：分析モデルに基本測定量を与えることにより求められる数値
・解釈モデル：管理指標の分析方法を示したモデル
基本
測定量

発見
欠陥数

（3）ユーザゴール、ベンダゴール

開発
規模

出荷後
欠陥数

開発
規模

（b）測定情報モデルによる記述例

ゴールは、「データ分析の目的と、目的を果たすために着目すべきデータ項目（R1）」を記述するための要素であり、GQMパラダイム［BASILI1984］のゴールの概念にコードを再レビューする

アウトライン:・・・

開始時条件:・
・・

利用タイミング:・・・

開始時条件:・・・

as<欠陥密度<ae
ならば正常

出荷後欠陥密度>cs
ならば正常

対応策

基づいている。GQMパラダイムとは、データ収集の目標
設定からデータ収集のメトリクス決定までをモデル化したものであり、ゴールとは、計測の目標、計測対象、計解釈
モデル

測理由等を明確にした文である。ゴールと管理指標を対応付けて記述する。
ゴールにはユーザゴールとベンダゴールの2種類が存在する。これらは、「ユーザ、ベンダそれぞれの分析目的を個別に記述（R6）」するための要素である。

KGI

KPI

分析
モデル
基本
測定量

欠陥密度

出荷後
欠陥密度

発見欠陥数
÷開発規模

出荷後欠陥数
÷開発規模

発見
欠陥数

開発
規模

出荷後
欠陥数

高品質の
ソフトウェアを開発する
ユーザゴールベンダゴール開発規模（c）SDAMLによる記述例（4）KGI 、KPI
※6※7

管理指標にはKGIとKPIの2種類が存在し、ゴール、

図11

モデル記述例※6 KGI：Key Goal Indicator，重要目標達成指標※7 KPI：Key Performance Indicator，重要業績評価指標

SEC journal Vol.5 No.6 Dec.2009375

P366-374-技術解説 09.12.21 7:34 PM ページ 376 (1,1)

3
技術解説●

KGI、KPIは階層構造となっている。これにより、「プロ

クトは、ちょうど折り返し地点を迎えたことになる。先ジェクト進行中、及びプロジェクト完了時のデータ分析

日開催したプロジェクト主催の研究会での議論等を拝聴方法 （R7）」を記述出来るようになっている。KGIとKPIしていると、開発データの共有に対するユーザ・ベンダ

はビジネスマネジメントの分野で用いられている概念での関心は、プロジェクト開始当初に比べて高まっており、あり、KGIはゴールを達成したか否かを判断するためのソフトウェアタグの具体的な利用イメージも明確になり

指標、KPIはプロジェクト進行中にプロセスを評価するつつある。ソフトウェア開発管理力に自信のあるユー

ための指標である。KPIが目標値をクリアするようにプ

ザ・ベンダにとって、開発データの共有によるデメリッ

ロジェクトを遂行することにより、KGIも目標値をクリトは少なく、その一方で、メリットを拡大する余地があ

ア出来るような関係となる。なお、（「テスト工程の進捗ると考えられ始めているのかもしれない。

を把握する」等）進捗を把握することが目的のゴール場

現在のところ、同様の取り組みは海外では見られない。

合は、KGIを設定しない。それ以外では、まずゴールに

IPA/SECによるプロジェクトベンチマーキングや経済産対して1つのKGIを設定し、KGIに対して1つ以上のKPIを業省によるソフトウェアメトリックス高度化の取り組み設定する。

等と連携をとり、そして何より、ユーザ・ベンダ企業との連携の輪を広げることで、日本独自のソフトウェア技

4.3 SDAMLと従来法によるモデル記述例

術としてソフトウェアタグの研究開発を推進していく予GQM、測定情報モデル、SDAMLそれぞれを用いてモデ定である。なお、ソフトウェアタグ規格を始めとして、ルを記述した例を図11に示す。GQMは、測定情報モデル、

本技術解説で取り上げた取り組みの詳細やその他の研究

SDAMLに比べ、記述出来る情報量が少ないことが分かる。

成果については StagE プロジェクトのウェブページ

SDAMLと測定情報モデルで記述出来る情報量の差は大き［STAGE Web］にて公開中である。参照いただければ幸くはない。しかし、測定情報モデルの場合、ユーザゴー

甚である。最後に、技術解説の機会を頂いた、SEC

ル・ベンダゴール、KGI、KPIの関係を表すことが出来な

journal編集委員会に心から感謝致します。

いため、管理指標を何のために利用するのかが非常に分かりにくい。更に、測定情報モデルでは、開始時条件、終了時条件を記述出来ないため、データ分析モデルをカタログ化することが出来ない。
このように、SDAMLを用いてモデルを記述することにより、データ分析の目的と方法を明確に示すことが出来る。また、テンプレートの機能を果たすため、GQMや測定情報モデルを用いるよりも、モデル記述が容易となる。
更に、データ分析モデルをカタログ化することが出来る。

5.

おわりに
5. おわりに
本技術解説では、文部科学省StagEプロジェクトの活動とこれまでに得られた主な成果を3回にわたって紹介してきた。2007年8月から5年計画の始まった同プロジェ

376

SEC journal Vol.5 No.6 Dec.2009

参考文献［AMBLER1984］ Ambler, S.W.：Process Patterns：Building Large-Scale Systems
Using Object Technology, Cambridge University Press, 1998
［BASILI1984］ Basili, V. and Weiss, D.：A Methodology for Collecting Valid Software
Engineering Data, IEEE Trans. On Software Eng., vol.10, No.3, pp.728-738, 1984
［CMMI2007］ CMMI 成果物チーム：開発のためのCMMI （CMMI-DEV）1.2版
公式日本語翻訳版，技術報告書 CMU/SEI-2006-TR-008，2007［ISO/IEC 15939］ International Organization for Standardization：ISO/IEC 15939:2002,
Software Engineering - Software Measurement Process, International Organization forStandardization, Geneva, Switzerland, 2002
［PMBOK2004］ Project Management Institute：プロジェクトマネジメント知識体
系ガイド（第3版）PMBOKガイド，2004［STAGE Web］ http://www.stage-project.jp/［角田2009］ 角田雅照，松村知子，松本健一：ソフトウェア開発データ分析モ
デリング言語の提案，ソフトウェアエンジニアリングシンポジウム2009 併設ワークショップ 「ソフトウェア開発マネジメントのための測定と分析」，2009年9月［松村2009-1］ 松村知子，大平雅雄，森崎修司，松本健一：オフショア開発におけるユーザ・ベンダ間コミュニケーション情報の分析による仕様伝達の評価，
奈良先端科学技術大学院大学情報科学研究科テクニカルレポート，NAIST-ISTR2009005，2009年10月［松村2009-2］ 松村知子，松本健一：ユーザとベンダ間の協調による要求品質確保のための定量化事例，奈良先端科学技術大学院大学情報科学研究科テクニカ
ルレポート，NAIST-IS-TR2009006，2009年11月

Part2. ソフトウェアタグ技術解説・英語編“Standardizing the Software Tag in Japan forTransparency of Development”

Reprint of NAIST Technical Report 2010001(http://isw3.naist.jp/IS/TechReport/report/2010001.pdf)

Standardizing the Software Tag in Japanfor Transparency of Development
Masateru Tsunoda†, Tomoko Matsumura†, Hajimu Iida†, Kozo Kubo‡,
Shinji Kusumoto††, Katsuro Inoue††, Ken-ichi Matsumoto††Graduate School of Information Science, Nara Institute of Science and Technology{masate-t@is, tomoko-m@is, iida@itc, matumoto@is}.naist.jp‡Research Center for Advanced Science and Technology, Nara Institute of Science and Technology; kubo@rsc.naist.jp††Graduate School of Information Science and Technology, Osaka University; {kusumoto, inoue}@ist.osaka-u.ac.jp

ABSTRACT

confident of their knowledge about information technologies [7].

In this paper, we describe the Software Tag which makes softwaredevelopment visible to software purchasers (users). A software
tag is a partial set of empirical data about a software development
project shared between the purchaser and developer. The
purchaser uses the software tag to evaluate the software project,
allowing them to recognize the quality level of the processes andproducts involved. With Japanese government support, we havesuccessfully standardized the software tag named Software Tag
Standard 1.0, and have developed various associated tools for tag
data collection and visualization. For its initial evaluation, thesoftware tag has been applied to several projects. This paper alsopresents various activities aimed at promoting the use of thesoftware tag in Japan and the world.

Without a sufficient understanding of software quality andsoftware projects, many companies try to purchase softwaresystems from software developers (vendors). This produces a veryrisky situation. For example, purchasers cannot specify system
requirements very well, and they do not oversee the projectproperly. Such situations often lead to project failures. It isreported that only 31.1% of software projects are recognized as‘successful projects’ in Japan [8]. To confront these issues, there
is strong demand to provide transparency of software projects tothe software purchaser and improve communications between
purchaser and developer.

Categories and Subject Descriptors

D.2.8 [Software Engineering]: Metrics – process metrics,
product metrics.

General Terms
Management, Measurement.

Keywords
Information sharing, empirical data, project management, offshoredevelopment.

1. INTRODUCTION
Software systems are becoming huge and complex, with our
everyday life heavily dependent on such software systems. One of
the major concerns of software purchasers (users) in Japan is thequality of the software systems. Japanese society generally
demands high-quality software systems with low fault rates andhigh operability levels.
On the other hand, many software purchasers in Japan are notknowledgeable about the nature of software. It is reported that
only 40% of Japanese major companies employ a full-time Chief
Information Officer (CIO) and that only 20% of all CIOs are

The Software Tag is a new scheme to provide information
feedback about the project from the developer to the purchaser. It
establishes transparency of the software development project by
allowing purchasers to view and analyze the elements of the tag. It
also provides support for quantitative and qualitative
communications between stakeholders. The Software Traceability
and Accountability for Global Software Engineering (StagE)project [1] is a government-supported project that pursues
standardization and promotion of the software tag scheme. In thisproject, we have defined the detailed structure of the software tag
and developed various support tools. The software tag has been
applied to real projects of major Japanese organizations. Alongwith technical development, we have also started various
promotion activities, such as formal standardization of thesoftware tag in both domestic and international standards, andexploration of new trade laws for software using the software tag
scheme.
An early concept of how software tags could be used for software
maintenance was shown in [4]. In this paper, we mainly explainuse of the software tag for software development, together withactivities and outcomes from the StagE project. In section 2, we
describe an overview of the software tag scheme, and in section 3
explain the details of the software tag structure. In section 4, we
describe activities of the project. In section 5 we provide somediscussion, while in section 6 we outline conclusions and future
research topics.

2. OVERVIEW OF THE SOFTWARE TAGSCHEMEA software tag is a packaged data set about a software project. It
is currently composed of 41 characteristic elements of project dataand progress data, as defined in section 3.1. Figure 1 shows an
overview of the software tag scheme.

1. Purchase Order

5. Delivery

Software Developer

Software Purchaser
SoftwareProducts

3. Process
Improvement

2. Data
Collection

Standardizing the software tag will help to establish a minimum
baseline for project quality, and to improve negotiations oversoftware development contracts. Evaluation of software products
and projects based on the objective empirical data contained in thesoftware tag will lead to more healthy use of software in society.

3. DEVELOPMENT OF SOFTWARE TAGTECHNOLOGIES
3.1 Software Tag Standard 1.0

Software Tag

4. TagComposition

Empirical
data

Figure 1. Overview of Software Tag Scheme
1. A software purchaser orders development of a software system.
The purchaser includes both the final products and the software
tag in their requirements.
2. During software development, various kinds of empirical data
are created and generated. For example, requirements documents,
software design documents, source code, test cases, issue tracking
logs, manual documents, review logs, and quality analysis records
may be produced. These are collected and archived. Note that wecollect not only the final data at the end, but also interim snapshot
data during development.
3. The collected data is analyzed for process improvement of thedevelopment organization, as is the usual process improvement
scheme for software development organizations.
4. The collected data is used to construct the software tag. Parts ofthe empirical data are selected and abstracted into the software tag
format.
5. The software tag is delivered to the software purchaser
periodically during the development and/or finally at the end of
the development together with the final software product. The
software purchaser evaluates the software development byviewing and analyzing the tag, and accepts the delivered software
product.
If a controversy such as a question about the quality of the
product occurs between the software purchaser and the developer,
the delivered software tag and (if necessary) the empirical data are
analyzed, providing a basis for exploring a resolution to thecontroversy.

We have defined the elements of the software tag as shown in
Table 1, named Software Tag Standard 1.0. It is composed of 41
tag elements, which are categorized into project information andprogress information. The project information depicts the overallsketch of the project with various basic pieces of information. The
progress information provides qualitative and quantitative indicesof project achievement with various measures of the development
phases. The tag standard provides more precise explanations andexample metrics for each tag element which are not presented
here.
It is not mandatory to use all 41 elements in the software tag in allcases. The purchaser and the developer can negotiate and selectelements to use. Also, they can discuss and determine the detailsof the metrics. For example, #19, Scale of Programming, might beagreed to be measured by lines of code without comments.
In this standard, we have included various kinds of informationthat are considered important to the purchasers. The overall
structure should be simple for the purchaser to understand, so wehave tried to keep it as simple as possible. Also, we have tried tokeep in mind the balance of the tag elements. This standard does
not include tag elements that are computable from other tag
elements. There are a number of standards and reports such as
SWEBOK, CMMI, ISO/IEC 15939, and reports by the Software
Engineering Center in Japan (SEC) which can help interpret the
tag elements.
The definition process was based on discussions with industry andacademic collaborators such as:
Purchasers: Tokyo Stock Exchange, Japan Aerospace
Exploration Agency, DENSO.
Developers: Fujitsu Lab, Hitachi, NEC, SHARP, SRA Key-Tech
Lab, Toshiba, NTT Data.
Others: Information Technology Promotion Agency, Ministry of
Economy, Trade and Industry, Japan (IPA), Nara Institute of
Science and Technology, Osaka University.

The software tag is a key to improving transparency of software
projects. By examining the software tag, the software purchaser
can identify and understand the development process, which has
been mostly hidden from the purchaser. The purchaser canevaluate the quality of the processes and products of the project.

3.2 Support Tools

For the software developer, the software tag is useful to prove thatthey have conducted the proper activities in the software project.
Also, it can be used to trace the quality of the activities of subcontractors and sub-sub-contractors... (such contracting chains arevery popular in Japan).

(1) Software tag data collection tool (CollectTag)

This scheme can be very useful for offshore and global
development, because transparency and traceability of softwaredevelopment can be established with a fairly low overhead for thedevelopers.

We are developing various support tools to promote the softwaretags scheme. In this paper, we introduce two essential tool
prototypes that have been created for collection and visualizationof the software tag.

CollectTag supports collection of empirical data from software
projects and creation of a software tag. CollectTag uses a wizard
as a user interface, allowing the user (developer) to easily input
the necessary data for the software tag.
For each project, the purchasers and developers determine themetrics for the tag elements. To provide generality, we
implemented CollectTag as a translator that converts a set of

Table 1. Software Tag Standard 1.0
Classification

CategoryNo.
Tag Element
1 Project Name
2

Basic
Information

3
4

SystemInformation

5
6

Project
Information

7
Development
Information

8
9

Project
Organization
Other

10
11
12
13

Requirements

Design

14
15
16
17
18

19
Programming 20
21
22
23
Test
24
25
26
27
28
Progress
Information

Quality

29
30
31
32
33
34

Development
Cost
35
36
Schedule andManagement

37
38
39

Other
Products

40
41

Explanation
Unique name of project
Information of development
Organization
organization
Information needed to identify the
Project Information
project characteristics
Information identifying theCustomerpurchaser or ownerInformation
Information identifying system
Systemconfiguration to label the type ofConfiguration
systemDevelopment system scale
System Scale
Development process type orDevelopment
techniques
Approach
Structure of development
Organizationalorganization
Structure
Information of development length
Project Duration
Name of super project which creates
Super-Project
this project
Information
Name of sub projects which is
Sub-Project
created by this project
Information
Other necessary or useful data forSpecial Notes
interpreting or analyzing tag data
Information of user-requirements
User Hearing
hearing
Information
Amount of requirements
Scale
Amount of changed requirement
Revisions
Amount of design products
Scale
Amount of changed design
Revisions
Design Coverage by Implementation ratio of design forrequirements
Requirements
Amount of programming products
Scale
Amount of changed programs
Revisions
Complexity of programs
Complexity
Amount of testing
Scale
Amount of changed test
Revisions
Ratio of test to system size
Density
Test progress to plan
Progress Status
Quantity information of review
Review Status
Ratio of review to system size
Review Density
Ration of found defects to amount ofReview Effectiveness
review
Number of defects found by test
Defect Count
Fixed Defect Count Number of fixed defects
Ratio of defects to system size
Defect Density
Ratio of detected defects to
Defect Detection
consumed test
Rate
Static Check Results Report of static checker
Development and maintenance cost
Overall Cost
Ratio of amount of products to
Productivity
overall cost
Information on management ofProcess Management
development process
Purchaser-Developer Amount of user-vendor
communication
Meeting Status
Number of risk items in the
Total Risk Item
development
Count
Risk Item Existence Time length between a risk item
creation and deletion
PeriodAmount of product metrics not listed
Scale
above
Amount of change in products not
Revisionslisted above

empirical data provided by the developer into the standard
software tag format. That is, the developer periodically inputs
values for each tag element, and then CollectTag outputs asoftware tag.
To reduce the effort of data input, CollectTag provides automatic
data collection mechanisms for 11 of the tag elements in the
progress information, if the target project uses common softwaredevelopment tools for configuration management and bugtracking. For example, LOC (#19: Scale) and CK (#21:
Complexity) metrics [3] can be automatically collected andcalculated from configuration management tools such as CVS or
Subversion.
Finally, CollectTag generates the software tag elements in XML
format (named standard software tag format). This makes it easy

to provide the output to other visualization and analysis tools forfurther processing.
(2) Software tag visualization tool (TagReplayer)
TagReplayer provides fundamental features for integrated
visualization of various historical data included in the software tag.
TagReplayer employs the metaphor of video player manipulation
for its user interface so that users can replay the progress of the
project just like watching video on TV. Users can also instantly
recall the details of any points along the timeline based on thesoftware tag as shown in Figure 2. Our experience shows that thisfeature is very useful for postmortem project reviews.
TagReplayer aligns progress information from the software tag as
a series of events. As a project summary, it displays multiple
views including line charts, progress bars, and plain lists. For
more details, clicking the items or points in the summary view caninstantly recall empirical data such as problem descriptions orcommunicated messages. The tool also provides natural text
mining and clustering that is useful for deeper analysis of humanactivity records, such as the problem reports or developers’communication messages, if the information is associated with thesoftware tag.

3.3 Applications of the Software Tag
We present here three case studies of application of the softwaretags scheme to real software projects.
(1) A course registration system for a university with 26K LOC in
Java was developed for five months by a medium-sized software
company in Japan. 32 elements of tag data were collected andused to analyze the project status, e.g., refactoring and theprobability of insufficient testing density, by comparing theelement values with the publicly available benchmark values fromthe Software Engineering Center in Japan (SEC).
(2) A medium-sized stock exchange system for a stock market
was enhanced by a Japanese major software development
company for more than two years. Using tag elements related to
the requirements phase such as requirements revisions (#15),
defect count (#29), and review status (#26), the purchaser anddeveloper were able to identify problems with the requirementscompleteness caused by frequent changes.
(3) A Japanese software development company ordered several
small-sized projects such as development of a project
management support system from various offshore companies in
China and Korea. Although remotely located from each other, thepurchasers and developers could understand the progress of thespecifications using tag elements such as the review status (#26),
user hearing information (#13), and defect count (#29).

4. ACTIVITIES FOR PROMOTION AND
DIFFUSIONThe StagE project is also actively promoting and diffusing thesoftware tags scheme in industry as follows.
(1) International/Domestic Standardization
Interviews with several Japanese software purchasers anddevelopers, along with offshore software developers for Japanesecompanies in some countries, convinced us that most softwarepurchasers and developers would strongly demand that thesoftware tag and tools should be international and/or domestic
technical standards in software engineering. To support this, weList of events

Summary chart (LOC, mail topics, etc.)

List of eventssummarized bydevelopers

Problem reportlisting

File sizes at the time of playing

Contents ofmail groups“Replay” buttons & time slider

Figure 2. TagReplayer Screenshot
are now serving ISO as a committee member of the working
group on process assessment, ISO/ITC JTC1/SC7/WG10. We arealso working with some software tool developers to construct a defacto standard software project management system that includes
the tag support tools mentioned in Sec. 3.2.
(2) International Collaboration
Offshore software development is one of the most useful
application areas of the software tag scheme. To encourage andaccelerate international collaboration to have various kinds of casestudies and experiments of the software tag in offshore softwaredevelopment, we established Asia-Pacific Software Engineering
Research Network (APSERN) in 2008 with software engineeringresearchers in NICTA (National ICT Australia), ISCAS (TheInstitute of Software, Chinese Academy of Sciences), and so on.
(3) Professional discussion of Legal issues
In the case of a legal dispute between software purchasers anddevelopers, the software tag can clarify their liabilities and has thepotential to help resolve such legal issues in softwaredevelopment. The StagE project has a committee examining thelegal issues of software development. Members of this committee
include lawyers, patent attorneys, and software engineers. The
committee has interviewed many software developers in Japanand China to compile data about troubles between softwarepurchasers and developers. It also distributed questionnaires tomore than a hundred software developers in Japan to analyze thetrends of such troubles. The software tag provides an opportunity
for collaboration between software engineering and software tradelaw.

5. DISCUSSION(1) There are metrics repositories aimed at improving andbenchmarking development organizations [5], along with some
software measurement paradigms [2] [6]. However, the software
tag provides a unique approach to involve software purchasers in
the quality improvement framework by providing development
transparency. As far as we know, there is no similar approachpresented in the technical literature.
(2) We believe that the benefits of the software tag scheme forsoftware purchasers will be substantial because the development
processes and the developed products become more visible andunderstandable. However, purchasers will need to collaborate

more closely with developers, providing effort and enthusiasm tocreate successful projects.
(3) We have presented the first standard of the software tag with
41 elements. In some sense, these are very basic data forindicating development quality, and they may be insufficient toperform detailed analysis. However, as a standard used for various
software development projects, the set should be minimal and low
cost. As presented in Sec. 3.1 and 3.2, our tag standard 1.0 is alightweight set with low collection and assembly cost. It is
important to continue practical applications of the software tag,and to get feedback for further improvement of the standard.

6. CONCLUSIONS
We have introduced our activities for standardization of thesoftware tag in Japan. Through these activities, the concept of thesoftware tag is becoming well understood in Japan.
Our future work will focus on making international/domestic
standards of the software tag. With such standardization, thesoftware tag is expected to be used in various software industries,
where we think it will strongly promote participation andunderstanding of software development by purchasers.

7. ACKNOWLEDGMENTS
This work is being conducted as a part of the StagE project, The
Development of Next-Generation IT Infrastructure, supported by
the Ministry of Education, Culture, Sports, Science andTechnology. We are grateful to the members of the StagE project,
especially to Michael Barker, Akito Monden, Makoto Matsushita,
and Shuji Morisaki.

8. REFERENCES[1] Barker, M., Matsumoto, M., and Inoue, K. 2008. Putting a
TAG on Software: Purchaser-Centered Software Engineering.
In Handbook of Research on Software Engineering and
Productivity Technologies: Implications of Globalization,
Ramachandran, M., and Carvalho R. A., Eds. Information
Science Reference, Hershey, PA, 38-48.
[2] Basili, V.R., and Rombach, H.D. 1988. The TAME Project:
Towards Improvement-Oriented Software Environments.
IEEE Trans. Softw. Eng. 14, 6 (June 1988), 758-773.
[3] Chidamber, S. R., and Kemerer, C. F. 1994. A Metrics Suite
for Object Oriented Design. IEEE Trans. Softw. Eng. 20, 6(June 1994), 476-493.
[4] Inoue, K. 2008. Software Tag for Traceability andTransparency of Maintenance. In Proceedings of, 24th IEEE
International Conference on Software Maintenance (Beijing,
China, Sep. 28 - Oct. 4, 2008). ICSM 2008, 476-477.
[5] International Software Benchmarking Standards Group(ISBSG) 2004. ISBSG Estimating: Benchmarking andresearch suite.
[6] Kitchenham, B. A. Hughes, R. T., and Linkman, S. G. 2001.
Modeling Software Measurement Data. IEEE Trans. Softw.
Eng. 27, 9 (Sep. 2001), 788-804.
[7] Nikkei Business Publications, Inc. 2008. Survey Report on
IT Investment and CTO in Japan. Nikkei Information
Strategy. March (in Japanese).
[8] Nikkei Business Publications, Inc. 2008. Second Survey ofJapanese Software Projects. Nikkei Computer. Dec. 1, 36-53(in Japanese).

ソフトウェアタグ規格

第1.0版
2008年10月14日

ＳｔａｇＥプロジェクト
奈良先端科学技術大学院大学
大阪大学

目次
前文 ...................................................................................................................................... 1(1) 経緯 ............................................................................................................................. 1(2) 目的 ............................................................................................................................. 1(3) 用語定義...................................................................................................................... 3(4) 留意事項...................................................................................................................... 5(5) 本規格が支援するポイント ......................................................................................... 5(6) 本規格による効果 ....................................................................................................... 5(7) 信頼性ガイドライン等とソフトウェアタグの関連 ..................................................... 6(8) まとめ ......................................................................................................................... 71．本規格の構成................................................................................................................... 92．規格の使用方法（運用ガイドライン） ........................................................................... 9
3．データ共有の目的と関連タグ項目例 ............................................................................... 93.1 製品品質の把握 ........................................................................................................ 9
3.2 開発状況の把握 ........................................................................................................ 9
3.3 紛争処理 ................................................................................................................... 9
4．タグの構造 .................................................................................................................... 10
4.1 階層構造 ................................................................................................................. 10
4.2 項目の繰り返し ...................................................................................................... 11
5．標準タグ項目一覧の概要 ............................................................................................... 11
5.1 一覧表の見方 .......................................................................................................... 11
5.2 標準タグ項目の位置づけ ........................................................................................ 11
6．標準タグ項目一覧表 ...................................................................................................... 13
付録 .................................................................................................................................... 16
体制 ............................................................................................................................. 16
参考文献 .......................................................................................................................... 17

前文(1) 経緯近年，ソフトウェア開発プロジェクトにおいて，ソフトウェア発注者（ユーザ 1 ）の参画が重要視されてきている．従来，ソフトウェア発注者（ユーザ）は要件定義など上流工程からソフトウェア受注者（ベンダ）まかせであるケースが多かった．しかし，ユーザ不在の開発では，要件のあいまいさから設計ミスや頻繁な仕様変更が発生し，品質低下，重大な不具合によるシステムダウン，コスト増大，納期遅れなどの原因となっている．また，障害発生時には，ユーザによる原因や責任所在の追及が困難で，障害対応が遅れ，甚大な損害が発生するケースも多い．さらに，法的な係争に発展すると，裁判が長期化し，解決までユーザ・ベンダ双方の損害が増大する．一方，多重請負・オフショア開発などの複雑な開発体制や多重の受発注関係では，潜在的発注者（ユーザ）が多く存在し，統制されたプロジェクトの管理を困難にし，管理コストを増大させている．
一方，携帯電話や家電製品への組込ソフトウェアの分野では，社内ソフトウェア部品を流用した派生開発が頻繁に行われている．また，ソフトウェア開発ベンダが，品質の確保や納期短縮のため外部からパッケージソフトウェアを購入し，システムに組込む事例も多い．このようなケースでは，長期にわたる流用・改造によって設計情報などが散逸したり，開発した組織が異なるため必要な情報を得られないなどの理由で，開発が困難になったり，予期しない品質問題によってダメージを受けることも多い．
これまで，ソフトウェア開発におけるデータの収集・分析は，当該組織でのプロセス改善やプロジェクト内部の進捗・品質管理を目的とし，組織間共有や一般ユーザの視点に立って行われてこなかった．しかし，ソフトウェアの問題の社会的な影響度の拡大や，マルチベン
ダ開発やオフショア開発など開発組織の複雑化に対して，
このような開発プロジェクトデー
タのより幅広い活用が求められてきている．例えば，ソフトウェアの不具合による法的紛争
では，様々な開発データに基づいて責任の所在が追及される．
(2) 目的StagE（Software Traceability and Accountability of Global Software Engineering)プロ
ジェクト 2 では，ソフトウェア開発データのユーザとの共有のための基盤研究開発を目的とし，ソフトウェアの品質や由来をユーザに示すための技術として「ソフトウェアタグ」の研究・開発を行っている．ソフトウェアタグは，ソフトウェアの開発中に収集された管理デー
タや品質情報など複数のデータから構成され，各データ種類をタグ項目と呼ぶ．タグ項目に従って，開発成果物や副次的に発生するデータ（実証データ/エンピリカルデータ）からタ
グデータが開発中，もしくは開発完了時に作成され，ソフトウェアに付随して流通する．ソフトウェアユーザは，タグの内容を見ることによって，対象ソフトウェアの開発過程や品質保証のプロセス，設計書やプログラムなどの成果物の品質情報を入手でき，安心して安全なソフトウェアを利用することが可能になる．ソフトウェアタグは，プロジェクト進行中にプ
本規格では，ソフトウェア開発関係者として，主に「ユーザ」「ベンダ」という 2 つの言
葉を用いる．特記しない限り，「ユーザ」はソフトウェア発注者，ソフトウェア利用者（エンドユーザ）などを含み，「ベンダ」はソフトウェア受注者，ソフトウェア開発者などソフ
トウェアを供給する人・組織を示す．（詳細は，「用語定義」参照）
2 文部科学省のプロジェクト 次世代 IT 基盤構築のための研究開発「エンピリカルデータに基づくソフトウェアタグ技術の開発と普及」の略称
11

ロジェクト管理のための定量的データを共有するために用いることも可能で，プロジェクト
進行中に発生する問題の早期発見・解決が可能になる．また，ユーザ・ベンダ間の紛争処理
では実際の開発データに基づいた詳細かつ正確な検証が可能になる．
「ソフトウェアタグ規格」は，ソフトウェアタグに含まれることが望ましい標準的なデー
タ項目とタグの運用ガイドラインを提供する．例えば，ソフトウェア発注者（ユーザ）と受注者（ベンダ）は，本規格に基づいて，両者で共有するべきデータを取り決め，どのように運用・管理するかといった具体的な活用方法を検討することができ，ユーザ・ベンダ両者が参画する定量データによるプロジェクト管理の導入が容易になる．また，収集データの標準化によりデータの組織間の共有が容易になり，統一基準による適正な評価も促進される．
以下に，本規格の構築に先立って検討されたソフトウェアタグの具体的な利用目的を挙げる．利用目的は，プロジェクトやシステムに応じて異なり，下記に限定されるものではないが，産業界において必要性の高い場面を想定している．
zzz

製品品質の把握¾ 流用資産の保証書／部品として使う製品と高信頼システム全体の信頼性認証：開発プロセスとプロダクトの動作に関する試験結果を監査し，製品及び高信頼システムを認証するために用いる．（図 1 参照）¾ 製品情報：工業製品や農業製品についているプロファイル情報（生産者，原産地，
原材料，添加物など）のソフトウェア版．使っている基盤ソフト，パッケージソフ
ト，開発言語，開発規模，開発者（企業名），サービス提供者などのほかに，試験結果など品質情報もオプションとして加えても良い．
開発状況の把握¾ 要件定義の充実度：要件定義が曖昧であることがプロジェクトの成否の鍵を握るといわれているが，定量的な分析はあまりない．要件定義の充実度を図るメトリクス
及びプロジェクトの成功/失敗についてのカテゴリを定義することで，どのような要件定義をすればよいか，明らかにする．仕様変更などもプロジェクトの成否にかかわる有益な情報である．
¾ 開発中の情報共有：開発中や検収時に，ユーザ（顧客）に対して示すプロジェクト
データをタグとして共有する．納品時の事後分析だけでなく，開発中の進捗状況の把握などにも用いことができる．（図 2 参照）
紛争処理¾ 事故調査：ハードウェアの世界では一般的な事故調査委員会（飛行機/電車事故など）が検査するためのデータのソフトウェア版．原因を究明して，プロセス問題に帰着させ，プロセス改善に結びつける．
¾ 法的係争時のプロセスの証拠： 障害や事故の責任の所在を明らかにする．プロセス遵守度・プロセス規定度・プロセス管理度など．（図 3 参照）

2

再利用プロダクトの検索再利用可能なソフトウェア
プロダクト リポジトリ

ソフトウェア
プロダクト

ソフトウェア開発者

ソフトウェアシステム

ソフトウェア
プロダクト
ソフトウェアプロダクト

信頼性の高いプロダクト選定

信頼性検査

図 1

流用資産の保証書／部品として使う製品と高信頼システム全体の信頼性認証
発注

開発データ 記録

納品
ソフトウェア開発者
ソフトウェア発注者
ソフトウェア
プロダクト

データ収集

フィードバック添付
エンピリカル

抽出

データ

ソフトウェア タグ

図 2

開発中の情報共有
発注
開発データ記録
納品
ソフトウェア開発者

ソフトウェア発注者
ソフトウェア製品

フィードバック

データ収集

抽出
添付
エンピリカル
データ

ソフトウェア タグ

検査

検査
ソフトウェアライアビリティ
調停・仲裁人図 3

法的係争時のプロセスの証拠(3) 用語定義
データ
記録の形態や方法にかかわらず，記録された情報，もしくはそれらから加工・抽出・算出された情報．
定量的データ
数値化されたデータ．規模や件数など対象物の計測で得られるデータのほか，欠陥密度など複数のデータから導出されるデータを含む．また，重要度，難易度などの定性的な属性も，集計などによって定量的に扱われる場合，定量的データに含まれる．

3

実証データ（エンピリカルデータ）
対象の実測により得られるデータ．ソフトウェア開発プロジェクトにおいては，最終成果物であるシステムから得られるデータだけでなく，開発過程で生じる副次的なデータ，
例えば議事録，欠陥レポート，工程管理表なども含まれる．
メトリクス
定量的な評価尺度．
プロジェクト
一般的には，目標達成のための計画から実施を含む作業の単位．本文中では，ソフトウ
ェア開発プロジェクトの意味で用いるが，必ずしもシステムの構築が目標ではなく，要件定義，設計など工程別に行われるプロジェクトも対象とする．標準タグ項目での「プロジェクト名」「サブプロジェクト」などは，タグの作成・流通単位としてのプロジェクトであり，ソフトウェア開発プロジェクト全体とは異なる狭義の意味を持つ．
プロダクト（成果物／製品）
ソフトウェア開発プロジェクトでは，顧客や最終利用者への納入のための作業成果物．
プログラム，品質保証データ，設計書，マニュアルなど，プロジェクトによってプロダ
クトは異なる．
ベンダ
ソフトウェア開発における狭義のベンダを意味する．ソフトウェア開発における「ベンダ」は，ソフトウェア受注者，ソフトウェア開発者などソフトウェアを供給する人・組織を示す．本文中では，パッケージソフトウェアの販売代理店など，実際に開発過程にかかわらない組織は，対象としない．
ユーザ
委託開発における発注者，システムのエンドユーザ，パッケージソフトウェアの利用者，
ソフトウェア部品を流用・改造するソフトウェア開発者などが挙げられる．
発注者・受注者
２者間契約による委託開発における受発注関係にある組織を指す．これは，ユーザと１次請けベンダの関係だけではなく，ベンダからの外部委託などの関係も含む．従って，
１組織が２つの立場（発注者であり，受注者）になる場合もある．
ソフトウェアタグ
ソフトウェアの開発中に収集された管理データや品質情報をパッケージ化したもの．ソフトウェア製品に付随して流通し，ソフトウェアユーザは，タグの内容を見ることによって，対象ソフトウェアの開発過程や品質保証のプロセス，設計書やプログラムなどの成果物の品質情報を入手することができる．
タグ項目
ソフトウェアタグを構成する個々のデータ種類．
タグデータ
ソフトウェアタグに含まれる実際の値や情報．基本的に，実証データ（エンピリカルデータ）から抽出されるが，実証データそのものを用いることも可能である．タグデータ
は，実証データによって裏づけが可能なデータであることを前提とする．

4

(4) 留意事項
汎用性
本規格は，できるだけ汎用的な枠組みとするため，特定のプロジェクト・分野の個別性の高い内容は含めない．タグ項目などに具体性に欠ける場合，説明のための詳細情報として，具体例を示す．特定の目的・分野ごとに必要な具体化は，利用シナリオで行う．
強制力
本規格は，ユーザ・ベンダ間（受発注者間）での協議のベースなどに用いる枠組みを提供するものであり，そのまますべてのプロジェクトやソフトウェアに導入を強制するものではない．また，本規格の利用者による追加・変更・削除などを制限しない．
具体例の活用本規格には，汎用性を保つため抽象的なレベルでとどめている記述がある．プロジェク
トでの活用を容易にするため，データの具体的なデータ収集・加工の手法/手段として具体化例や実証データ例を示す．ただし，例示するにとどめ，すべての具体化方法を網羅するものではない．
(5) 本規格が支援するポイント① データ収集
ソフトウェア開発プロジェクトにおいて，収集するべきデータを明確にする．このデータは，プロジェクトの進捗やコストをリアルタイムに管理し，納期の遅延やコスト超過を防止したり要求されている品質を保証したりするために，開発側（ベンダ）が必要とする情報をベースとするが，特にユーザと共有することが望まれるデータ（紛争時の解決に有効なデータなど）についても取り上げる．
② データ加工・可視化
本規格では，ユーザと効果的にデータを共有するために，収集されたデータを加工・可視化する方法や技術の例を示す．収集されるデータは膨大な量であり，そのま
ま開示しても分析や解釈のコストが増大し，効率的・効果的にデータが共有できない．
そのため，ユーザと共有するデータは，双方の目的に応じて必要最小限の量であることが望ましい．本規格では，開発中の収集データからどのような定量的データを加工し，そのデータをどのようにユーザに見せるかといった点について，例を提供する．
③ ユーザ・ベンダ間のデータ運用
本規格では，ユーザ・ベンダの目的やプロジェクトの特性に合わせたデータ運用の枠組みを提供し，ユーザ・ベンダ間でどのようにデータを用いたプロジェクト・ソフ
トウェア管理を行うか，その手順を明確にする．具体的には，目的に応じた収集デー
タの選択，契約への記載，データ共有タイミング，データ授受方法，それに伴うコストなどである．
(6) 本規格による効果① データ収集の促進とデータ項目の標準化
一般的なデータ項目と収集・加工方法などの情報の利用により，データ収集の導入が容易になり，定量的プロジェクト管理・プロセス改善が促進される．データ項目の標準化によって，ツール・計測技術の開発が促進され，計測や分析のコストが低減する．
② ユーザ・ベンダ間のデータ共有の促進
組織間のデータ項目の統一により，データ共有・流通が容易になる．統一基準による組織・プロジェクト・システム評価により，適正競争が促進され，国際競争力が強
化される．

5

③

ユーザのデータ収集・分析への理解・協力
データ共有の目的の明確化やプロジェクト管理への理解向上により，ユーザの協力（コスト負担など）が得やすくなる．

④

障害対応や紛争処理
あらかじめ収集されているデータが明確になり，要約されたデータが共有されていることによって，障害発生時には，ユーザ・ベンダ間の協力による迅速な原因究明・問題解決が可能になる．また，ユーザ・ベンダ間の紛争に発展した場合にも，公正かつ迅速な解決が図れる．

(7) 信頼性ガイドライン等とソフトウェアタグの関連
経済産業省は，情報産業強化施策の一環として，「産業構造・市場取引の可視化」 3 を挙げ，ユーザ・ベンダ一体となった生産性向上の促進を目指している．「情報システムの信頼性向上に関するガイドライン」4（以降，信頼性ガイドライン）では，“情報システムの利用者及び供給者の双方が応分の責務を担う”とし，「企画・開発における，信頼性・安全性の水準検討」「障害発生時の手順の文書化・記録」「定量的な手法を取り入れたプロジェクト
マネジメントの実行」などについて，受発注者双方の果たすべき役割について述べている．
それを受けて，「情報システムの信頼性向上に関する評価指標（試行版）」 5 （以降，信頼性評価指標）では，ユーザ・ベンダ双方のガイドラインの遵守状況を評価のための評価指標を示し，具体的なチェックリストを公開している．一方，「情報システム信頼性向上のための取引慣行・契約に関する研究会」最終報告書 6 （以降，モデル契約書）では，ユーザの主体的なプロジェクトへのかかわりを促進することを目的として，契約書にユーザやベンダの役割・責任分担を明確に示すことが重要である，と述べている．契約に明記することによって，ユーザによるベンダへの“丸投げ”を防ぎ，仕様の固まりにくいプロジェクトの円滑な進行を促進するという効果を期待している．また，モデル契約書では，ユーザ・ベンダ間でのソフトウェア開発に関する紛争解決方法として，裁判外紛争処理（ADR）の活用を推奨している．専門的・技術的視点による詳細な事実認定や当事者間の話し合いによって，紛争処理を迅速かつ柔軟に行うことが可能である，と考えられている．
ソフトウェアタグは，これらのガイドライン等に対して，それぞれの目的に応じて具体的なデータに基づいて支援することが可能である（図 4 参照）．信頼性ガイドラインに挙げられている「定量データを活用した管理」は，本規格の標準タグ項目をベースにユーザ・ベ
ンダ間で検討することによって，導入が容易になると考えられる．また，ソフトウェアタグとして収集されたデータを用いて，ガイドラインの遵守状況をより詳細に評価することが可能になる．一方，ソフトウェアタグに関する条項を契約書に盛り込むことによって，プロジ
ェクト管理に関するユーザ・ベンダ双方の責任・役割を明確にすることができ，データ収集に伴うコストなども契約時に協議することが可能になる．一方，ADR による紛争処理がおこなわれる際には，実際の開発データに基づいた詳細かつ正確な検証が可能になる．

http://www.meti.go.jp/policy/it_policy/softseibi/index.html
2006 年 6 月 15 日公表，経済産業省
5 2007 年 4 月 13 日公表，経済産業省
6 2007 年 4 月 13 日公表，経済産業省
3
4

6

情報システムの信頼性向上に関する評価指標

主要事項の取り組みレベルの診断・可視化

ガイドラインの遵守状況を測定するための評価指標

信頼性ガイドライン
定量的プロジェクト
管理の導入支援

ADR（裁判外紛争処理）

エンピリカルデータに基づく詳細検証や証拠の提示

契約事項の明確化・取引関係の可視化

紛争処理の原則

モデル契約書定量的プロジェクト管理についての契約支援

エンピリカルデータに基づく，より詳細な評価技
術・評価指標の提供

ソフトウェアタグ
図 4

情報政策とソフトウェアタグの関連

一方，JISA(社団法人情報サービス産業協会)では，「信頼性向上ベストプラクティスを実現する管理指標調査報告書」 7 を刊行し，ベンダ視点から信頼性向上のための具体的な指標の効果や活用方法を示した．この中で，顧客や協力会社との対話における指標活用のポイン
トとして，「活用目的と意義の共有」「活用する指標の早期合意の重要性」「定例会議での指標の報告・確認と議論の効果」などが挙げられている．
ソフトウェアタグ規格は，ユーザに重点を置いた指標を選択することによって，組織間のデータ共有・活用を支援すると考えられる．
(8) まとめ
上記のとおり，ソフトウェアタグは，これまでのソフトウェア開発プロジェクト管理を大きく変更するものではなく，ユーザ視点によるデータ活用を促進するために，既存の技術や知識を再構成することによって実現される．本規格は，その具体的な方法，すなわちデータの種類や活用方法を検討するために，ユーザ・ベンダ間で用いられる 1 つの指針として作成される．
ソフトウェアタグに含まれるデータ項目やデータ構造などは，本規格で具体的に示されているが，今後の課題として以下のことが考えられる．
z
z

z
z
z

実プロジェクトにおいてどんなタイミングで情報を取るのかなど，本規格のユーザが運用の具体的なイメージを持つための，利用シナリオの充実
本規格に準じたソフトウェアタグの普及を促進するため，
ユーザサイドへの啓発活動の促進（経済産業省，SEC などとの連携や，タグの認証や検証を行う第三者機関の設立
など）
国際規格化
データ収集・分析ツールの開発や既存ツールを活用した導入や普及の支援
本規格を保守・運用・管理する体制の整備

2008 年 4 月，社団法人情報サービス協会．概要は，以下 URL 参照．
http://www.jisa.or.jp/report/2007/19-J009.pdf
7

7

8

1．本規格の構成(1) 規格の使用方法（運用ガイドライン）
ソフトウェア開発プロジェクトの企画段階で，ユーザ・ベンダ間でのデータ共有に関する取り決めを行うにあたっての観点・手順を示す．
(2) データ共有の目的と関連タグ項目
ユーザ・ベンダ間で共有するデータの項目を決定するために，データ共有の主要な目
的とそれに関連する標準的なタグ項目の例を示す．実際には，より詳細な目的を設定し，目的に応じた具体的なタグ項目を選択することが必要である．
(3) タグの構造
開発プロジェクトの管理や部品の流用・再利用を考慮した，推奨するソフトウェアタ
グ構造を示す．
(4) 標準タグ項目一覧の概要(5)の標準タグ項目一覧表の見方と，運用上の位置づけを示す．
(5) 標準タグ項目一覧表
標準的にプロジェクト管理に用いられるタグ項目の一覧表を示す．

2．規格の使用方法（運用ガイドライン）
ソフトウェア開発プロジェクトの企画段階で，ユーザ・ベンダ間でのデータ共有に関する取り決めを行うにあたっての観点・手順を示す．また，各ステップで参照するべき本規格の章を示す．
(1) データ収集・共有目的の設定「3．データ共有の目的と関連タグ項目例」参照(2) 目的に応じたデータ項目の選択「3．データ共有の目的と関連タグ項目例」「5．標準タグ項目一覧の概要」「6．標準タグ項目一覧表」参照(3) データ定義・収集方法・開示データレベルの決定「5．標準タグ項目一覧の概要」「6．標準タグ項目一覧表」参照(4) システム・プロジェクト構成に応じたタグ構造の決定「4．タグの構造」参照(5) データの収集・計測・開示タイミングの決定(6) 開示データの活用方法（説明，議論，解釈/判定，フィードバック）の決定(7) 開発完了後（保守，運用，再利用等)におけるタグ活用の検討

3．データ共有の目的と関連タグ項目例
ユーザ・ベンダ間で共有するデータの項目を決定するために，データ共有の主要な目的とそれに関連する標準的なデータ項目の例を示す．実際には，より詳細な目的を設定し，目的に応じた具体的なデータ項目を選択することが必要である．
3.1 製品品質の把握
z 品質の把握に関する項目：バグ数，レビュー状況，静的解析結果など
z ソフトウェアを部品としての再利用するために必要な情報に関する項目 ：システ
ム構成，テスト項目数，リスク項目数など
3.2 開発状況の把握
z 開発環境（リソース等）に関する項目 ：開発体制，開発手法など
z プロセス情報に関する項目 ：要件/設計変更，テスト消化，プロセス管理情報など
3.3 紛争処理
z 試験に関する項目：バグ数，レビュー状況，テスト項目数など
9z

ユーザ・ベンダ間合意に関する項目：ユーザヒアリング情報，要件変更，会議実施状況など

4．タグの構造開発プロジェクトの管理や部品の流用・再利用を考慮した，推奨するソフトウェアタ
グ構造を示す．
4.1 階層構造
ソフトウェアタグは，システムの構成やプロジェクトの契約単位，開発チーム構成などに応じて階層構造で持つ．
図 5(a)のシステム A のように 2 つのサブシステム X,Y から構成されるシステムの場
合，ソフトウェアタグは１つのメインタグとそれにリンクする 2 つのサブ（子）タグから構成することができる．このように進捗管理や品質管理の単位で構成すると，収集・分析データの流用も容易であり，タグの管理コストが低減できる．
また，タグを階層構造にすると，サブシステムの再利用や流用も容易になる．図 5(b)は，サブシステム Y を他のシステム B の部品として流用する際のタグの構造を示している．濃い網掛けのタグが同一タグになる．薄い網掛けのタグは，流用するサブシステ
ムのタグ(濃い網掛け)から新規に作成され，システム B への組込み作業のデータを持つ．
このような構造をとることによって，流用部品の過去のデータ管理が容易になり，ソフ
トウェア部品のトレーサビリティを確保できる．
開発されたシステムの運用・保守を別契約で行う際も，図 5(c)のようにタグを階層構造にすることが望ましい．この場合，メインタグとサブタグで重複する情報を省略し，各サブタグは，運用・保守プロセス作業で発生するデータのみを持つことになる．
(a)

(c)

システムA
サブ
システムX

サブ
システムY

メインタグ
（プロジェクトA）
サブ(子)タグ（プロジェクトX）

サブ
システムX

サブシステムの
流用

サブ
システムY

サブ
システムY

システムA

メインタグ
（プロジェクトA）

運用プロセス

システムA

メインタグ
（プロジェクトA）

サブ(子)タグ（プロジェクトY）

(b)
システムA

開発プロセスサブ(子)タグ（プロジェクトA・
運用）

メインタグ
（プロジェクトA）
サブ(子)タグ（プロジェクトX）

サブ(子)タグ（プロジェクトY）

保守プロセス

システムA

メインタグ
（プロジェクトA）
サブ(子)タグ（プロジェクトA・
運用）

メインタグ
（プロジェクトY）

サブ(子)タグ（プロジェクトA・
保守）

システムB
サブ
システムX

サブ
システムY

メインタグ
（プロジェクトB）

サブ(子)タグ（プロジェクトY）

サブ(子)タグ（プロジェクトX）

メインタグ（プロジェクトY）(a)システム構成時のタグ構造

図 5 タグの構造(b)流用時のタグ構造

10(c)保守・運用時のタグ構造

4.2 項目の繰り返し
タグ項目は，開発工程やプロダクトの性質に応じて，複数持つことが適切な場合，同一項目の繰り返しを許容する．例えば，進捗情報の「設計」分類に関して，基本設計，
詳細設計などの工程が存在する場合，「設計」は同一タグ内に複数存在するのが適切と考えられる．また，進捗情報の「プログラミング->規模」についても，派生開発などで新規作成・改造・再利用（流用）など種別に計測することが必要な場合，「プログラミ
ング->規模」項目が３つ存在することを許す．

5．標準タグ項目一覧の概要
標準的にプロジェクト管理に用いられるタグ項目の一覧と，運用上の位置づけを示す．
5.1 一覧表の見方

ソフトウェアタグを構成する個々のデータ種類・タ
グデータのインデックス

各タグ項目の意味や活用方法などタグデータを抽出する元となるプロジェクト情報やドキュメント・生データ
タグデータの例
予定・実績値の差分による管理を行うデータ
工程別に管理を行うデータ(*注)*注）進捗情報タグ項目には，「工程別の要否」欄はない．進捗情報は，管理単位を自由に設定することが可能で，工程別・日次・週次などが考えられる．
5.2 標準タグ項目の位置づけ
z 利用目的やプロジェクトの特性に応じたカスタマイズを前提としている．従って，すべての項目がすべてのプロジェクトにおいて網羅的にタグ化されることを求めない．また，必要なデータの追加も可能とする．
z データ収集の対象物，対象範囲，粒度，収集期間（工程）は，別途ユーザ・ベンダ間で取り決めなどに準じ，本規格では特に規定しない．
z 収集データのタグ化のタイミングやユーザへの開示タイミングは，ユーザ・ベンダ間の協議などにより決定されるものとする．納品時，工程毎，一定時間ごと(週次，日次）などが考えられる．
z タグの階層や項目の繰り返しなどのタグの具体的構造については，システムやプロジェ
クトに応じてカスタマイズをする．（「4．タグの構造」参照）

11

z

z
z

ソフトウェアタグとするデータの具体化レベルは，選択可能とする．エンピリカルデー
タ・生データ，一次加工データ（数値化されたデータ），二次加工データ（2 つの測定値の比率など）が考えられる．たとえば，進捗情報の「プログラミング->規模」は，プログラムコードそのもの，時系列のステップ数，予定規模に対する完成割合などが考えられる．この点についても，ユーザ・ベンダ間で協議などにより決定されるものとする．
他の項目から算出可能な数値は，項目から除外する．ただし，欠陥密度など一般的なものは１項目として挙げている．
他の文書（契約書等）に記載され，ユーザ・ベンダ間ですでに共有されている内容（品質要件，受発注金額など）は標準タグ項目から除外しているが，変更管理などのため追加することも可能である．

12

タグ項目一覧

プロジェクト情報
プロジェクトに関する情報・プロジェクト中に不変なデータ・プロジェクトを特徴付けるタグ※下記一覧は，ユーザ・ベンダ間で共有するタグ項目の候補である．このなかから目的に応じてタグ項目を選択し，ソフトウェアタグを構成する．
※タグのデータを解釈・分析するために必要なデータや他のプロジェクトと比較するための情報を含む．
※必要に応じて，具体的なデータの取り方の情報を含む．

分類

項番 タグ項目
1

2

基本情報

3

4

説明

具体化例

実証データ例

予定・実績 工程別の 備考の要否
要否

プロジェクトを一意に決定する

プロジェクト計画書など

当該プロジェクトの開発を担当する組織の情報．一般には，受注者となる組織情報となる．

ISO/IEC 15504 Process Assessment，米カーネギメ 発注仕様書
ロン大CMMI®などを用いたアセスメント結果のプロセ アセスメント結果にス達成度一覧または組織成熟度レベル
関する情報
体制表
キャリアシートなど
開発組織名，対象業種の経験 など

類似対象業種のプロジェクトに関するプロセス領域ごとの能力レベルの達成度など，合意のもとに詳細を共有することも可能

開発プロジェクトの特徴や当 開発プロジェクト種別：新規・改造・保守・運用・流用 要件定義書
該タグデータの対象とするプ など
プロジェクト計画書
ロジェクトの種類を示す情報．
品質計画書
タグデータの解釈や分析時に 設計書再利用率・ソースコード再利用率・コンポーネ 設計ドキュメント
開発プロジェ 必要なデータ．
ント再利用率など
ソースコードクト情報
テスト計画書開発プロジェクト形態 (商用パッケージ，受託開発)， など
利用パッケージ など

開発作業を伴わない場合も入力

プロジェクト名 ための識別名

開発組織の
情報

顧客情報

当該システムのユーザ，もしく 顧客名，新規顧客か否か など
は第1発注者となる組織の情報．

顧客との議事録
プロジェクト計画書
など

必須項目

○

進捗情報の各成果物の規模から導出可能な場合もある

通常は，発注者自身なので不要．ただし，受注者からの外部委託を行う場合，最終顧客(エンドユーザ)情報を記入

開発システム構成の特徴や 利用したサブシステムの安定度：利用ハードウェア、 基本設計書
当該タグデータの対象とする ライブラリ、OS等、調達したサブシステムの安定度 プロジェクト計画書
システムの種類を示す情報． 合い（初回、不安定等）
工程管理表
タグデータの解釈や分析時に勤務実績データ
必要なデータ．
など
5

はじめて使うサブシステムに
は学習工数が必要なため

サブシステムの検証期間/工数：利用を検討したサブシステムの検証期間と工数

システム構成検証時に性能把握や設計情報の細部を詰めることができるため、検証期間/工数から設計、テスト品質を推測するため

システム情報利用したサブシステムに関する法的要件 など

67

開発システムの規模．計画値 受注者側の想定する顧客要件の数，実装した要件 基本設計書と最終実績値とする．進捗情 数など
ソースコードシステム規模 報に同じ情報が含まれる場合
工程終了時のソースコード行数,機能,FP,処理データ 要件定義書
は，省略可．
など
量,処理データ数など

開発手法

8

開発体制

体制表
発注書
キャリアシート
勤務実績データ
工程管理表
など

○

○

経験年数，レベル別割合(上級・中級・初級)，新人比率，類似プロジェクトの経験(開発、ユーザともに類似プ
ロジェクト参加の経験があるか：経験なし、3回未満、5回以上），
要員スキル（PM,業務，分析・設計，言語・ツール，開発プラットフォーム：ITSSなどに準拠） など
当該プロジェクトの開発期間

9

SLOCはプログラム単位，その他はプロジェクト単位○

開発システム開発に用いたプ 適用プロセスタイプ (ウォーターフォール・アジャイ
プロジェクト計画書
ロセスや手法についての情
ル・プロトタイプ)，適用手法 (OOAD，SASD，DDE) な プロジェクト生産管
報．タグデータの解釈や分析 ど
理計画書
時に必要なデータ．
など
開発側の要員に関する情報． 組織図・人員配置図
タグデータの解釈や分析時に 作業体制の複雑さ・親密さ(結合度・分散度)：組織
図・人員配置図から計測必要なデータ．
※開示対象範囲は，発注者・ プロジェクト体制の階層数 など受注者側での協議により決定
する
外注率，ピーク時の開発人員，延べ開発人員，チーム別の開発要員 など

開発情報

○

プロジェクト期 に関する情報
間

稼働時期、開始、終了を含む（時間、日、月) など
工期 など○
担当機能毎，担当職務毎
メンバの学習工数を推測する
ため○

勤務実績データ
工程管理表
など

○

○

○

○

発注から納品までのリードタイ
ム(=全体工期)

本プロジェクトが別のプロジェ 親プロジェクトのプロジェクト名
クトのサブ(子)プロジェクトで親プロジェクト ある場合，付加
10

情報

プロジェク
トの階層構
造情報
11

その他

サブ(子)プロ
ジェクト情報12 特記事項

本プロジェクトがサブ(子)プロ サブ（子）プロジェクトの数，プロジェクト名など
ジェクトを持つ場合，その数やサブ（子）プロジェクトに関する情報
その他，タグデータの解釈や分析時に必要，もしくは有用なデータ．

プロジェクト計画書
機能設計書
構造設計書
など

「No.1 プロジェクト名」と一致するプロジェクトのタグが存在しなければならない

プロジェクト計画書
機能設計書
構造設計書
など
タグデータ管理情報(適用管理指標、収集データ群)など

タグ項目 一覧

進捗情報
成果物や作業の進捗状況，成果物やプロセスの品質を表すタグ※下記一覧は，ユーザ・ベンダ間で共有するタグ項目の候補である．このなかから目的に応じてタグ項目を選択し，ソフトウェアタグを構成する．
※[推移]は，時系列もしくは一定間隔で計測された連続データも想定される．
計測間隔は，工程毎・日次・週次・開発のm/n(m=0,1,2,・・n-1 / n=16 or 32 ….)などが考えられる※進捗に関する各計測項目は，必要に応じて全体／工程毎／タスク毎に測定する．
※必要に応じて，具体的なデータの取り方の情報を含む．

分類

項番 タグ項目要件定義
13 ユーザヒアリング情報

14 規模[推移]

説明

具体化例

要件に関してユーザに行ったヒア ユーザヒアリング実施件数(回)
ユーザヒアリング議
リングに関する情報
事録
ユーザヒアリング項目数(件)，
ユーザヒアリング回答率 (ユーザヒアリング回答数÷ ユーザヒアリング質
問票
ユーザヒアリング項目数)などなど
開発側で作成した要件数
画面、機能項目、ユースケース、アクター，顧客要要件定義書
件，機能，FPなどなど変更された要件数

規模の計測単位に依存

15 変更[推移]設計
16 規模[推移]

17 変更[推移]要件定義で作成された要件の実 設計に取り入れられた要件数÷要件数
装率

予定・実績 備考
の要否
○

○

要件定義書
要件定義書の変更
履歴など

設計成果物の規模
機能設計 (ページ数・帳票数・画面数・ファイル数・項 基本設計書※新規・改造・再利用(流用)毎に 目数・UML図の数、クラス数、バッチプログラム数， 機能設計書
計測する
重要な機能数など)
構造設計書
構造設計 (データ項目数，DFDデータ数，DFDプロセ 詳細設計書
ス数，DBテーブル数 など)などなど変更された設計成果物の数，もし 規模の計測単位に依存
くは変更量

18 要件の網羅率

実証データ例

基本設計書
機能設計書
構造設計書
詳細設計書
各設計書の変更履
歴
など
要件定義書
基本設計書
機能設計書
構造設計書
詳細設計書
など

○

何を要件の基本単位とするかは、要合意事項

プログラミング
19 規模[推移]

プログラミング成果物の規模
LOCなど※新規・改造・再利用(流用)毎に計測する

ソースコードなど変更されたプログラムの数，もしく 変更回数，削除行数，追加行数など
は変更量

ソースコードリポジトリ更新履歴など

20 変更[推移]プログラムの品質（保守性）○

ファイル別・モジュール別

Halstead，McCabe，CK，クローン含有率，コメント平 ソースコード
均利用率などなど

21 複雑度テスト
22 規模[推移]ファイル別・モジュール別テストの規模テスト項目数など※新規・改造・再利用(流用)毎に計測する

テストケース
テスト計画書など変更されたテスト項目数や変更量 追加テスト項目数，変更テスト項目数など

テストケース
変更履歴など

テストの品質テストケース
テスト結果
ソースコード
要件定義書など

23 変更[推移]24 密度

テスト項目数÷システム規模（ソースコード行数など）
C0(命令網羅)，C1(分岐網羅)，要件に対するカバ
レッジ率（結合/受け入れテスト） など

テストの進捗，プログラムの品質 テストケース進捗，消化テスト項目推移，テストプロ
グラム消化率，クリティカルパス進捗など
25 消化

品質
26 レビュー状況

27 レビュー作業密度

ファイル別・モジュール別

成果物(仕様書，設計書，プログラ レビュー回数，対象規模，実績回数，ユーザ参画のムコード，テスト仕様書など）のレ 有無，レビュー時間など
ビューに関する情報
レビュープロセスの品質，もしくは レビュー工数率，レビュー密度など
レビュー対象の品質

テストケース
テスト計画書
テスト結果
工程管理表
など
レビュー議事録など
レビュー議事録
レビュー対象(ソースコード，
各設計書)
など

○

○

○

○

○

「No.6 システム規模」と「No.22 規模」から導出可28 レビュー指摘率[推移]レビュープロセスの品質，もしくは レビュー指摘数，指摘密度，不具合指摘数推移など レビュー議事録
レビュー対象の品質
レビュー対象(ソースコード，
各設計書)など
テスト設計の品質とコード品質

テスト結果
障害管理票
品質管理表
など

29 欠陥件数[推移]欠陥の対応進捗，対応内容

不具合消化数，障害滞留時間，検出欠陥の分析実 テスト結果
施回数，類似欠陥調査実施回数など
障害管理票
品質管理表
など

テスト設計の品質とコード品質

検出欠陥数をシステム規模で割る：不良摘出件数÷ テスト結果
ステップ数など
障害管理票
品質管理表
ソースコードなど

30 欠陥対応件数

31 欠陥密度テスト設計の品質

不良摘出件数÷テストケース消化数

32 欠陥指摘率

プログラムの品質（保守性）

チェッカによる総エラー数，チェッカによる総警告数など

テスト計画書テストケース
テスト結果
障害管理表
品質管理表
など

○

○

欠陥が発生した工程別，原因ごとにも集計「No.6 システム規模」と「No.29 欠陥件数」から導出
可「No.25 消化」と「No.29 欠陥件数」から導出可○

ソースコードなど

33 静的チェックの結果

工数

作業に要する工数，仕様変更作
業工数

工程管理表
勤務実績データなど

34 作業工数

工数に対する成果物の比率
35 生産性

規模（画面数・帳票数）÷工数
頁÷工数(設計工程)
ステップ数÷工数（製造工程）
不良摘出件数÷工数(テスト工程) など

構造設計書
勤務実績データ
ソースコード
テスト結果など○「No.34 作業工数」と各成果物の規模などから導出可○計画・管理開発プロセスの管理に関する情報

プロセス規定度 (提出されたプロセス記述の詳細さ プロジェクト計画書に基づく：WBSのタスク数など），
プロジェクト生産管
標準プロセスに対する網羅度，プロセス遵守度 (プロ 理計画書
セス記述と実際の作業間の適合の度合いに基づ
勤務実績データ
く)，
工程管理表
プロセス管理度 (各ステップごとに設定された会議体 議事録の数や提供された管理指標の数に基づく)などなど

ユーザ・ベンダ間，ベンダ間での情報共有状況を把握

各会議の時間、参加人数、資料量、議事数、議事録 議事録
量、情報共有者数などなど

36 プロセス管理情報

会議：要件検討会，進捗会
議，納入/検収など

37 会議実施状況

38 累積リスク項目数

リスク認識が十分であったかを把 進捗会議で挙げられたリスク項目数の累積、軽微、 議事録
握重大、その他の項目でわける
リスク管理表など

リスク対策が適切になされていた リスク管理項目の最長、平均滞留時間
かを把握

議事録
リスク管理表など

対象成果物の規模※新規・改造・再利用(流用)毎に計測する

ドキュメント
計画書など変更された対象成果物の数，もし 変更回数，変更ページ数など
くは変更量．

ドキュメント変更履歴など

39 リスク項目の滞留時間

その他成果
物
40 規模[推移]

41 変更[推移]○○
対象成果物：マニュアル，計画
書，スケジュール表など

付録
体制
z

ソフトウェアタグ規格技術委員会
第 1 回（2007 年 7 月 9 日） ～構成員 14 組織 31 人

第 13 回（2008 年 10 月 14 日）

アドバイザー（50 音順・敬称略）
大杉 直樹
株式会社 NTT データ
木谷 強株式会社 NTT データ
鶴保 征城
独立行政法人情報処理推進機構
ソフトウェアエンジニアリングセンター（IPA SEC）
神谷 芳樹
独立行政法人情報処理推進機構
ソフトウェアエンジニアリングセンター（IPA SEC）
村山 浩之
株式会社デンソー
企業（50 音順・敬称略）
岩崎 新一
日本電気株式会社
片平 真史
独立行政法人宇宙航空研究開発機構（JAXA）
清田 辰巳
株式会社東京証券取引所
阪井 誠株式会社 SRA 先端技術研究所
高木 富士雄 シャープ株式会社
福地 豊
株式会社日立製作所
松尾 昭彦
株式会社富士通研究所
松村 好高
株式会社 SRA 先端技術研究所
宮本 祐子
独立行政法人宇宙航空研究開発機構（JAXA）
森俊樹
株式会社東芝山田 淳
株式会社東芝大学（50 音順・敬称略）
飯田 元
奈良先端科学技術大学院大学
井上 克郎
大阪大学
川口 真司
奈良先端科学技術大学院大学
楠本 真二
大阪大学
久保 浩三
奈良先端科学技術大学院大学
黒崎 章
元 奈良先端科学技術大学院大学
小柴 昌也
奈良先端科学技術大学院大学角田 雅照
奈良先端科学技術大学院大学
鳥居 宏次
奈良先端科学技術大学院大学
名倉 正剛
奈良先端科学技術大学院大学
松村 知子
奈良先端科学技術大学院大学
松本 健一
奈良先端科学技術大学院大学
森崎 修司
奈良先端科学技術大学院大学
門田 暁人
奈良先端科学技術大学院大学
リビエリ・シモネ
大阪大学

16

z

ソフトウェア構築可視化法的問題検討委員会
第 1 回（2007 年 11 月 16 日） ～第 5 回（2008 年 10 月 8 日）
構成員 7 組織 11 名（50 音順・敬称略）
青江
飯田
井上
江口
大西
楠本
久保
小柴
茶園
松田
松本

秀史
元
克郎
順一
幸男
真二
浩三
昌也
成樹
貴典
健一

大阪大学
奈良先端科学技術大学院大学
大阪大学
帝塚山大学
西銀座法律事務所
大阪大学
奈良先端科学技術大学院大学
奈良先端科学技術大学院大学
大阪大学
大阪成蹊大学奈良先端科学技術大学院大学

参考文献[1] ISO9001：2000（JIS Q 9001/2000） 品質マネジメントシステム[2] 開発のための CMMIⓇ(CMMI-DEV) 1.2 版 公式日本語翻訳版，CMMI 成果物チーム，技術報告書 CMU/SEI-2006-TR-008．
http://www.sei.cmu.edu/cmmi/translations/japanese/models/dev-v12-abstract-j.html[3] 保田勝通，ソフトウェア品質保証の考え方と実際，日科技連，1995 年 11 月
[4] IPA/SEC，ＩＴプロジェクトの見える化

下流工程編，日経 BP，2007 年 6 月[5] IPA/SEC，IT プロジェクトの見える化 上流工程編，日経 BP，2007 年 5 月[6] IPA/SEC 著作監修，「ソフトウェア開発データ白書 2005～IT 企業 1000 プロジェ
クトの定量データを徹底分析」，日経コンピュータ[7] IPA/SEC，ソフトウェア開発データ白書 2007，日経 BP，2007 年 7 月[8] XBRL FACTBOOK：
http://www.xbrl-jp.org/download/pdf/factbook/2007/XBRLFACTBOOK_ver.9.pdf[9] 飯塚悦功編：“ソフトウェアの品質保証-ISO9000-3 対訳と解説-”，日本規格協会(1992)．
[10] “品質を考える技術”，組込みプレス，5, pp.13-34(2007)．
[11] 「情報システムの信頼性向上のための取引慣行・契約に関する研究会～情報システ
ム・モデル取引・契約書～（受託開発（一部企画を含む），保守運用）＜第一版＞」（2007 年 4 月 13 日公表，経済産業省）[12] 「情報システムの信頼性向上に関するガイドライン」（2006 年 6 月 15 日公表，経済産業省）[13] 「情報システムの信頼性向上に関する評価指標（試行版）」（2007 年 4 月 13 日公表，経済産業省）[14] 「信頼性向上ベストプラクティスを実現する管理指標調査報告書」（2008 年 4 月
社団法人情報サービス協会）

17ソフトウェアタグ規格 第 1.0 版
2008 年 10 月 14 日
StagE プロジェクト
奈良先端科学技術大学院大学 情報科学研究科
StagE プロジェクト研究代表者
松 本 健 一大阪大学 大学院情報科学研究科
ソフトウェアタグ規格技術委員会委員長
井 上 克 郎E-mail:stage-contact@is.naist.jp
URL:www.stage-project.jp

本規格は，文部科学省の科学技術試験研究委託事業による委託業
務として，奈良先端科学技術大学院大学と大阪大学が共同で実施
した，平成２０年度の「エンピリカルデータに基づくソフトウェ
アタグ技術の開発と普及」の成果を取りまとめたものです．従って，本規格の著作権は，文部科学省に帰属しており，本規格の全部または一部の無断複製等の行為は，法律で認められたときを除き，著作権の侵害にあたるので，これらの利用行為を行うときは，
文部科学省の承認手続きが必要です．

注）StagE プロジェクトは，文部科学省の委託業務「次世代 IT 基盤構築のための研究開発：ソフトウェア構築状況の可視化技術の開発普及」として，奈良先端科学技術大学院大学と大阪大学が共同で実施する研究開発プロジェクト「エンピリカルデータに基づくソフトウェアタグ技術の開発と普及」の略称です．

18

ソフトウェアタグ・ガイドブック 20102010 年 1 月 31 日
StagE プロジェクト

奈良先端科学技術大学院大学 情報科学研究科
StagE プロジェクト研究代表者
松本健一
E-mail: stage-contact@is.naist.jp
URL: http://www.stage-project.jp

本冊子は，文部科学省の委託業務「次世代 IT 基盤構築のための研究開発：ソフトウェア構
築状況の可視化技術の開発普及」として，奈良先端科学技術大学院大学と大阪大学が共同で実施する研究開発プロジェクト「エンピリカルデータに基づくソフトウェアタグ技術の開発と普及」の成果をとりまとめたものです．StagE は，本研究開発プロジェクトの略称です．
本冊子またはその一部の複製・転載・引用等には，文部科学省の承認手続きが必要です．
Copyright (C) by StagE Project, All Rights Reserved