日本ソフトウェア科学会第 31 回大会 (2014 年度) 講演論文集

開発のための CMMI の成熟度レベルごとの関連プロセ
ス領域ネットワークの中心性可視化
日下部 茂

林 信宏

大森 洋一

荒木 啓二郎実際のソフトウェア開発に新しい技術を導入する際に関係者の合意を得ることは必ずしも容易ではない．我々は特に形式手法の導入におけるこのような問題に対し，ソフトウェア開発のベストプラクティスを体系化したとされるプロ
セス改善モデルを用いた取り組みを行っている．形式手法と総称されていても，具体的な手法としては，形式手法群と呼べるほど様々な手法がある上に，導入対象の実開発プロセスも様々なものがあり得る．そのため，形式手法導入
による効果を一律に述べたり，既報告の導入事例と自らの開発事例を直接比較することも容易ではない．実際の開発に形式手法を導入する場合，開発プロセスに何らかの変更を加える必要があるため，技術的な難易度に加え，プ
ロセスのテーラリングの難易度も考慮する必要がある．各開発現場のプロセスの確立の度合いや，テーラリング能
力にばらつきもある状況においてはモデルを介しての検討も有効と考える．本稿では，プロセス改善モデルの一つ
CMMI-DEV の成熟度ごとのプロセス領域集合に対して，関連プロセス領域の関係に着目しネットワークの中心性を分析・視覚化することについて論じる．そのような試みの結果，導入推進経験者の経験則と合致するベストプラク
ティスを視覚化することができた．

スに着目し，プロセスのアセスメントや，アセスメ

1 はじめにント結果にもとづくプロセス改善といった活動も行

社会基盤に相当する領域やミッションクリティカル

われている．ソフトウェア開発に限定されないもの

な領域も含め，ソフトウェアの利用範囲は拡大を続けの，品質の高い製品の開発を目指すものとして，品質ており，ソフトウェアの信頼性・安全性は以前にも増マネジメントシステムの構築を目的とした ISO 9000

して重要となっている．その一方で，ソフトウェアシシリーズ [2] がある．また，ソフトウェア開発のプロ

ステムの開発にかける期間やコストの短縮が求めら

セスを改善して高品質のソフトウェアを作る代表的れる傾向もある [1]．

なプロセス改善のフレームワークとして能力成熟度
モデル CMM（Capability Maturity Model) やその

1. 1 開発プロセスの改善

発展版の能力成熟度モデル統合 CMMI（Capability

ソフトウェアの品質に関して，個別の要素技術でMaturity Model Integration）フレームワーク [3] がはなく開発のプロセスが重要とする考えがある．ソある．そのフレームワークにもとづく開発のための

フトウェアの品質はその開発に用いられたプロセス

CMMI-DEV は，ソフトウェア開発のプラクティス，に影響を受けるといった考えの下，高い品質のソフ

つまり日々の業務で必要とされる概念や原則，必要なトウェアを効率よく開発するために，開発のプロセ

技術，手法，ツール ，管理ノウハウといったものの集合から，ベストプラクティスを体系化したモデルとVisualizing Centrality of Related Process Areas by
Maturity Levels in a Process Improvement Model
CMMI-DEV
Shigeru Kusakabe, 九州大学, Kyushu University.
Hsin-Hung Lin, 九州大学, Kyushu University.
Yoichi Omori, 九州大学, Kyushu University.
Keijiro Araki, 九州大学, Kyushu University.

されている．CMMI-DEV は，システム開発の調達条件として受発注の提案依頼書にその成熟度レベルが記載されることもあるため，遵守やレベルの獲得が重視されることも多いが，本来はそういったことに限定されずプロセス改善に有効なツールとして使えるモデルである．

発プロセスを変更する難易度も考慮する必要がある．

CMMI フレームワークは一般に公開され参照は容こういったことを考慮すると，形式手法導入による効

易である一方，カーネギーメロン大学ソフトウェア研

果を一律に述べることは事実上不可能である．また，究所の知的財産であり，国ごと産業ごとのような第三ソフトウェア開発プロセスに関する知見がない状態

者によるカスタマイズはできない．ソフトウェアプ

で，既報告の導入成功事例と自らの開発プロセスを直ロセスアセスメントの標準化の取り組みとして，通接比較することも容易ではない．

称 SPICE(Software Process Improvement and Ca-

pability dEtermination) と呼ばれる ISO/IEC 15504

1. 3 形式手法の導入とプロセス改善があり，特定のアセスメントモデルの使用を要求しなプロセスの確立・改善のフレームワークでは，効果

い，アセスメントモデルの枠組みと実施のための基本的なプロセスは新しい技術を導入し使用するための的な要求事項などを定めている．ISO/IEC 15504 は，手段も提供する，とされており，我々は，この新しいソフトウェアの開発や保守といった，ソフトウェアの技術として特に形式手法を想定した取り組みを行って

ライフサイクル全般に関わる活動の標準として定めいる．我々は，実際の開発現場への形式手法導入の障られている ISO 12207 への対応だけでなく，特定業

壁を解消するために，既存のプロセスアセスメントや界向けのモデルのベースとしても利用できる．例え

プロセス改善のモデルと形式手法の導入を関連付け

ば自動車に組込まれる電子制御ユニットのソフトウェる試みを行っている．図 1 のように，直接的な比較

アの品質改善を目的として，欧州の主要完成車メーが困難な個別のプロセスへの形式手法導入の知見も，カーが共同で策定した，AutomotiveSPICE といった標準的なプロセス改善モデルを介することで，参照やものがある．

比較が容易になると考える．
我々は，これまでの産学連携の取り組みで，形式手

1. 2 形式手法の普及

法の導入を契機としたプロセス改善が可能との経験をソフトウェアの開発手法という観点では，ソフト持っている．その一方，開発プロセスの観点からは，ウェアの機能や安全性を保証しながら，より高い，もプロセスが一定のレベルに達していないと形式手法導しくはある一定の品質ソフトウェアを効率よく開発入は円滑にいかず，形式手法導入前に他に改善すべきするために有効な手法として形式手法 (formal meth-点がある場合が多いという経験も持っている．機能安ods) が活用されている [4] [5]．日本においても，形式全の規格である ISO 26262 では形式手法の利用が推手法に関しては，様々な研究活動だけでなく，事例報

奨されているが，ISO 26262 でもプロセス改善活動

告による知見の共有やテキストの公開，セミナーの実があっての機能安全であり，その第一段階が SPICE施といった実際の開発現場での活用を促進するためののような改善活動であるといわれている．このような普及活動も行われている [6] [7] [8]．しかしながら，実ことから，改善を意図して，実際の開発プロセスに形際の開発現場への形式手法の導入はその推進者が期式手法を導入して何らかの変更を加える際に，プロセ待するほどは進んでいない．

ス改善フレームワークを活用することは有用と考え実際の開発への形式手法導入の難易度や利害得失る．プロセス改善フレームワークを活用することで，に対しては同一組織の中であっても様々な見方があり

各開発現場でのプロセスの確立の度合いやプロセス得るため，導入の合意形成が難しいことのその理由のテーラリング能力のばらつきによる，形式手法導入の一つと考える．形式手法と総称されていても，実の効果に対する評価の困難さに対して系統的な見通際には具体的な手法として形式手法群と呼べるほどしを示すことができると考える．

様々な手法があり，それぞれ長所・短所が異なる．さ

本稿では，開発のための CMMI における成熟度ごらに，実際の開発で用いられる開発プロセスにも様々との関連プロセス領域ネットワーク中の中心性を解析なものがあり得る．形式手法自体の難易度に加え，開し，視覚化することによって形式手法導入の見通しに

表1
長所
短所

課題ベースのプロセス改善の長所と短所-

図1

改善の初心者も始めやすい改善の効果を体感しやすい
組織全体で見ると取り上げる課題に網羅性がない
プロセス改善活動の結果が個別の現場内に閉じやすい
喫緊の課題に着目し過ぎやるべき事に網羅性がない
将来を見越した課題解決につながりにく
く，次々に課題が発生する可能性

標準プロセスモデルを介した比較検討を進める．実際の開発プロセスでの改善の優先度の高ついて検討する方法について論じる．CMMI はチー

い課題から着手できるため，高い動機付けで着手しやムレベルのプロセスとの対応関係も議論されている

すく効果も上げやすいとされている．課題ベースのプ[9]．そのため図 1 の中で上下方向に位置する，組織，ロセス改善は，具体的な改善に直接対応する技術やチーム，個人のレベルのプロセス [10] [11] の対応も取ツールが利用可能な場合，特に着手が容易と考える．

りやすいと考え，既にいくつかの取り組みも行っていプロジェクトの規模やドメインの範囲が小さいほど，る [12] [13] [14] [15]．

機動性良く課題解決に有効な具体的技術やツールを対応付けることが容易であり，課題ベースのプロセス

2 プロセス改善のアプローチ

改善は比較的小規模なプロセス改善と相性が良いと実際の開発に形式手法を導入する場合，何らかの改考える．しかし，改善に際して主観や独善が入る可能善を期待した上で，既存の開発プロセスに必要な変更性があり，客観的根拠にもとづかず場当たり的で，系を加える．この開発プロセスの変更にあたって，ベー統的でない改善になってしまう可能性もある．

スラインとなるプロセスの確立の度合いや，プロセ

形式手法が開発上の課題を解決するために導入さスのテーラリング能力のばらつきも形式手法導入のれ，課題ベースのプロセス改善として導入する形式手

効果に対する見通しを難しくしている可能性がある．

法に合わせて開発時の実践や作業成果物が必要に応

しかしながら，プロセスの確立やテーラリング能力

じて変更されることが考えられる．

の問題はプロセス改善一般に共通する問題でもあり，

我々は，課題ベースのアプローチをとる場合でも，

形式手法導入に際してもプロセス改善の知見は有用課題の分析にあたり，俯瞰的な視点を併用することでと考える．

より広範な効果をもつプロセス領域を優先しやすく

プロセス改善にはモデルにもとづくトップダウンのものと，課題にもとづく課題ベースのものがある．

することで課題ベースのアプローチの問題を緩和しより有効なプロセス改善とすることを目指す．

モデルベースのプロセス改善と課題ベースのプロセ
ス改善は必ずしも排他的なものではなく，適切なプロ
セスの発展モデルの下では，モデルベースのプロセス
改善と課題ベースのプロセス改善を関連付けることも可能と考える．

2. 2 モデルベースのプロセス改善の観点による形式手法導入
プロセス改善活動には，CMMI や ISO/IEC 15504，

AutomotiveSPICE，SPEAK-IPA といった，標準的なモデルを参照しながら，各自の強味と弱味を診断

2. 1 課題ベースのプロセス改善の観点による形式
手法導入

し，強い点をより強く，弱い点を強くするといった，モデルベースのプロセス改善活動がある．モデルベー

課題ベースのプロセス改善では，開発プロセスの課スの改善法では，アセスメントモデルを意識した規定

題をまず洗い出し，その優先順位の高いものから改善

や標準を重視した形式主義に陥り，認定の取得やレベ表2
長所

課題ベースのプロセス改善の長所と短所

-

短所

-

-

業界で良いと認められたプロセスを自組織に取り入れることができる
ソフトウェア開発としてやるべきこととして網羅的に改善ができる
モデルを十分に理解せずそのまま実装してしまうことも多く，その場合，現場には負担になりやすい
モデルの広範囲にわたる多量のプラクティ
スを一度に示されると導入が敬遠される
直接的な効果が体感しにくい
レベル到達ありきになってしまうことが多い
推進側が現場不在のまま進めてしまう状
況に陥りやすい3. 1 モデルの構成要素
CMMI-DEV には，表 3 に示す 22 のプロセス領域が含まれている．段階表現での成熟度レベル，連続表
現でのカテゴリー (区分) については後述する．これらのプロセス領域のうち，16 個は CMMI の他のモデルにも共通する中核のプロセス領域である．それ以外のプロセス領域のうち，1 つは共有のプロセス領域
で，5 つは開発固有のプロセス領域である．この 5 つの開発固有のプロセス領域は，開発に固有のプラク
ティスに焦点を合わせたもので，「要件開発」，「技術解」，「成果物統合」，「検証」，および「妥当性確認」
である．

ル達成といった，本来は手段であったものが目的化し各プロセス領域を構成する要素は，Required Com-てしまうおそれもある．しかしながら，モデルベース

ponents(必要とされる構成要素)—あるプロセス領域の改善法では，参照すべきモデルがあるため，系統立

におけるプロセス改善を達成するために必須の CMMIてた活動につなげやすく，場当たり的な活動になりに

構成要素，Expected Components(期待される構成要

くいとされている．形式手法の導入にあたっても，導素)—必要とされる CMMI 構成要素を達成するにあ入自体に意識が行くあまり，何を改善するかという意

たって重要である活動を記述した CMMI 構成要素，

識が希薄になって手段として採用した形式手法の導入

Informative Components(参考の構成要素)—CMMIが目的化しまうといったことを避ける必要がある．まの必要とされる構成要素および期待される構成要素

た，形式手法の導入を，場当たり的な活動ではなく，をモデル利用者が理解することを助ける CMMI 構成

系統立てた活動にすることも重要である．

要素，に分けられる．具体的には，各プロセス領域は

我々は，モデルベースのアプローチであっても，指定されたプロセス領域の集合の中での優先度を決める指針を示すことで，モデルベースアプローチの問題を緩和し，より有効なものとすることを目指す．

次の要素を含んでいる．

• 目的の記述文 (Purpose Statements: Informative)• 導入説明 (Introductory Notes: Informative)• 関連プロセス領域 (Related Process Areas: In-3 ソ フ ト ウェア 開 発 プ ロ セ ス モ デ ル 例：
CMMI-DEV
ここでは，ソフトウェア開発のための代表的なプロ
セスモデルとして CMMI-DEV 1.3 を用い，特にそのプロセス領域に着目して考える．CMMI でのプロセス領域とは，ある領域における関連するプラクティ
スのひとまとまりであり，それらがひとまとまりとして実装されると，その領域で改善を行うために重formative)• 固有ゴール (Specific Goals: Required)• 固 有 プ ラ ク ティス (Specific Practices:
pected)• 固有プラクティスのサブプラクティス (SpecificSub-practices: Informative)• 作業成果物の例 (Example Work Products: Informative)

要であると見なされている一連のゴールが満たされ• 共通ゴール (Generic Goals: Required)るというものである．CMMI-DEV 1.3 版モデルは，• 共 通 プ ラ ク ティス (Generic Practices:『CMMI 1.3 版のアーキテクチャと枠組み』から生成された，政府や産業界からの開発のベストプラクティ
スの集まりである．

Ex-

Ex-

pected)• 共通プラクティスのサブプラクティス (GenericSub-practices: Informative)

表3開発のための能力成熟度モデル統合 (CMMI-DEV) のプロセス領域

段階表現での成熟度レベルとプロセス領域
2: 要件管理 (REQM: Requirements Management)
2: プロジェクト計画策定 (PP: Project Planning)
2: プロジェクトの監視と制御 (PMC: Project Monitoring and Control)
2: 供給者合意管理 (SAM: Supplier Agreement Management)
2: 測定と分析 (MA: Measurement and Analysis)
2: プロセスと成果物の品質保証 (PPQA: Process and Product Quality Assurance)
2: 構成管理 (CM: Configuration Management)
3: 要件開発 (RD: Requirements Development)
3: 技術解 (TS: Technical Solution)
3: 成果物統合 (PI: Product Integration)
3: 検証 (VER: Verification)
3: 妥当性確認 (VAL: Validation)
3: 組織プロセス重視 (OPF: Organizational Process Focus)
3: 組織プロセス定義 (OPD: Organizational Process Definition)
3: 組織トレーニング (OT: Organizational Training)
3: 統合プロジェクト管理 (IPM: Integrated Project Management)
3: リスク管理 (RSKM: Risk Management)
3: 決定分析と解決 (DAR: Decision Analysis and Resolution)
4: 組織プロセス実績 (OPP: Organizational Process Performance)
4: 定量的プロジェクト管理 (QPM: Quantitative Project Management)
5: 組織実績管理 (OPM: Organizational Performance Management)
5: 原因分析と解決 (CAR: Causal Analysis and Resolution)• 共通プラクティスの詳細説明 (Generic Practices
Elaborations: Informative)

連続表現での区分
プロジェクト管理
プロジェクト管理
プロジェクト管理
プロジェクト管理
支援
支援
支援
エンジニアリングエンジニアリングエンジニアリングエンジニアリングエンジニアリング
プロセス管理プロセス管理プロセス管理プロジェクト管理
プロジェクト管理
支援
プロセス管理プロジェクト管理
プロセス管理支援3. 2 段階表現と連続表現
CMMI のモデルには段階表現と連続表現の二種類

例えば，ある固有ゴール (SG: Specific Goal) は一の表現がある．どちらの表現も，目標を達成するため

つのプロセス領域に適用され，そのプロセス領域を満にプロセス改善を実装する方法を提供し，同じモデル

たすために存在しなければならない特有の性質を記述

構成要素を使って本質的には同じ内容を提供していする，必要とされる構成要素である．固有プラクティ

るが，異なる方法で編成されている．段階表現では，ス (SP: Specific Practice) は，必要とされる構成要素

プロセス領域は成熟度レベルにより編成され，連続で，プロセス領域の固有ゴールの達成につながること

表現では，プロセス領域は，プロセス管理，プロジェが期待される活動である．共通ゴール (GG: Generic

クト管理，エンジニアリング，支援，という四つの区

Goal) は，プロセス領域を実装するプロセスを制度化

分により編成される．段階表現では，あらかじめ定義するために存在しなければならない特性を記述してされたプロセス領域の集合に一つ一つ順番に取り組いる，必要とされる構成要素で，複数のプロセス領域

むことにより，関連するプロセスの集合を改善するこに同じゴール記述文が現れる．共通ゴールの達成は，とを可能にする．連続表現では，モデルで選択された

そのプロセス領域に関連するプロセスの計画と実装

個々のプロセス領域もしくはプロセス領域の集合に対における改善された制御を意味している．共通プラク

応する，実プロセスを一つ一つ改善していくことを可ティス (GP: Generic Practice) は，プロセス領域と能にする．段階表現には，成熟度レベルというレベル

関連するプロセスが効果的で，反復でき，持続的なもを，連続表現には，能力レベルというレベルを用いるのであることを確実なものにする活動で，期待される(表 4)．

構成要素である．関連プロセス領域は，関連するプロ

形式手法も具体的には形式手法群と呼ばれるほど多セス領域への参照を列挙し，プロセス領域間の高いレ

種多様なものがあり，期待できる効果も様々である．

ベルの関係を表す，参考の構成要素である．

ソフトウェア開発プロセスを形式手法で改善すると

表4

能力レベルと成熟度レベルの比較

4

連続表現
能力レベル
Incomplete(不完全な)
Performed(実施された)Managed(管理された)Defined(定義された)
—

5

—

レベル
0

1
2
3

ゴリーを明記して示す．グラフ化には Graphviz ツー

段階表現
成熟度レベル—ル [16] を用いた．図では，エンジニアリングカテゴ

Initial(初期)
Managed(管理された)Defined(定義された)Quantitatively Managed(定量的に管理された)
Optimizing(最適化している)

アリングカテゴリーにも効果や影響を与え得ること

リーのプロセス領域に形式手法を導入した場合でも，プロセス領域間の関連により，その導入が非エンジニが示されている．例えば，プロジェクト計画策定は要件開発 RD や技術解 RD を参照している．また，要件管理 REQM は，要件開発 RD や技術解 RD と相互に参照しあっている．

4. 2 段階表現の成熟度レベルごとのプロセス領域間の関係した場合，例えば，改善の目的に応じて連続表現の編成を参考にプロセス領域もしくはプロセス領域群に

4. 2. 1 関連プロセス領域ネットワークでの入次数
中心性着目し適切な手法や技術を選ぶのことが考えられる．

モデル要素である関連プロセス領域に着目し，プロもしくは，段階表現の成熟度の向上に有効な形式手法

セス領域間の参照関係をもとにネットワーク分析によを選ぶことが考えられる．

る中心性を求めた．入次数 (in-degree) による中心性の結果を表 5 に示す．表では成熟度レベル 3 での値

4 プロセス領域に着目したプロセス領域間の分析が降順となるようにプロセス領域をソートしている．
要件開発 RD は ML3 から含まれ，以降 ML5 まで高実際のプロジェクトは，形式手法のような特定の技

い入次数中心性の値をもち，関連プロセス領域という術のみで成功できるわけではない．一方，形式手法

関係で構成されたネットワークの中心的な存在と言えを導入すると，その手法が直接的に対象とするプラ

る．段階表現を用いたプロセス改善では，あらかじめクティスや作業成果物に対する効果だけでなく，それ定義されたプロセス領域の集合に一つ一つ順番に取以外のものに対する間接的な効果もプロジェクトもり組むことにより，関連するプロセスの集合を改善す

成功に寄与するという報告もある [5]．このような形ることを可能にする．その際に要件開発 RD にまず式手法導入の効果をプロセスモデルで検討する場合，取り組むことが，関連するプロセス領域の改善に対し直接的な効果に関しては固有ゴールや固有プラクティて波及効果が大きいのではないかと推測できる．

スに主に焦点を当てて形式手法の導入を検討することが考えられる．間接的な効果に関しては，関連プロ

4. 2. 2 関連プロセス領域ネットワークでの媒介中
心性

セス領域 (群) の間の関係に着目して形式手法を導入

形式手法を導入することで，その直接的な効用だすることが考えられる．プロセス領域間の関連付けで

けでなく，間接的な効用もあるといわれている．場合

どのようなグループ化を行うかは，前述の段階表現に

によってはポジティブなものだけでなくネガティブなおける成熟度レベルごとの編成や，連続表現における影響もあり得る．例えば，プロジェクト計画策定 PP

プロセス領域の区分など様々な観点のものを考えるこ

は要件開発 RD を参照しており，形式手法を導入すとができる．

ることで要件開発 RD プロセス領域が変更されると，プロジェクト計画策定 PP も変更がある可能性があ

4. 1 連続表現のカテゴリー間の関係

る．プロジェクトの監視と制御 PMC はプロジェクト

モデル要素である関連プロセス領域の記述をもと計画策定 PP を参照しており，プロジェクト計画策定に，図 2 に，22 個のプロセス領域の間の関連を，カテPP に変更があるとプロジェクトの監視と制御に変更

図2カテゴリーをまたがるプロセス領域間の関連

成熟度レベルごとの関連プロセス領域ネットワーク

め，その結果を表 6 に示す．この表でも成熟度レベル

中のプロセス領域の入次数中心性の値．(各成熟度レベルの3 での値が降順となるようにプロセス領域をソートしプロセス領域数で標準化し成熟度レベル 3 の値でソート)ている．入次数中心性の分析結果と同様に，要件開表5

プロセス領域
RD
PP
PMC
REQM
TS
VER
RSKM
OPD
DAR
CM
MA
VAL
SAM
IPM
OPF
PI
OT
PPQA
OPP
QPM
OPM
CAR

ML2
0.571
0.571
0.429

0.286
0.286
0.000

0.000

ML3
0.444
0.389
0.333
0.333
0.333
0.333
0.278
0.222
0.222
0.222
0.167
0.167
0.056
0.056
0.056
0.056
0.000
0.000

ML4
0.400
0.350
0.350
0.300
0.300
0.300
0.250
0.250
0.200
0.200
0.250
0.150
0.100
0.100
0.050
0.050
0.000
0.000
0.050
0.050

ML5
0.364
0.318
0.318
0.273
0.273
0.273
0.227
0.227
0.227
0.182
0.318
0.136
0.091
0.091
0.091
0.045
0.045
0.000
0.091
0.091
0.182
0.091

発 RD は ML ３では高い値を持っており，要件開発

RD にまず取り組むことが，関連するプロセス領域の改善に対して波及効果が大きいのではないかと推測できる．しかしながら，入次数中心性の分析結果と異なる点もある．ML4 以降では要件開発 RD は必ずしも最も高い値ではない．ML4 や ML5 で重視されている観点では，重点を置くべき他のプロセス領域がある可能性がある．
このような傾向をより把握しやすくするために，成熟度レベルごとの関連プロセス領域のネットワークとその中心性の分析結果を視覚化する．

4. 3 成熟度レベルごとの関連プロセス領域ネット
ワークの視覚化
成熟度に合わせて，重視すべきプロセス領域を分析し，形式手法の導入を検討する．中心性の分析結果の傾向をより把握しやすくするために，成熟度レベルごがある可能性がある．こういった関係を分析するためとの関連プロセス領域ネットワークとその中心性のに，モデル要素である関連プロセス領域の記述され分析結果を視覚化する．視覚化にはツール Gephi [17]た，プロセス領域間の参照関係をもとにネットワーク

を用いた．

分析による媒介中心性 (Betweenness centrality) を求

4. 3. 1 関連プロセス領域ネットワークでの入次数

表6

成熟度レベルごとの関連プロセス領域ネットワーク

中のプロセス領域の媒介中心性の値．(成熟度レベル 3 の値
でソート)
プロセス領域
RD
PP
MA
REQM
DAR
VER
IPM
TS
OPD
PI
RSKM
PMC
CM
VAL
SAM
OT
OPF
PPQA
QPM
OPP
OPM
CAR

ML2
0.119
0.119
0.119

0.119
0.000
0.000

0.000

ML3
0.347
0.342
0.173
0.163
0.156
0.137
0.126
0.121
0.105
0.104
0.092
0.087
0.021
0.009
0.005
0.000
0.000
0.000

ML4
0.281
0.318
0.433
0.173
0.117
0.122
0.129
0.101
0.095
0.050
0.077
0.133
0.026
0.007
0.027
0.000
0.000
0.000
0.143
0.000

ML5
0.261
0.283
0.387
0.122
0.084
0.111
0.092
0.296
0.032
0.040
0.056
0.070
0.010
0.020
0.018
0.007
0.004
0.000
0.144
0.000
0.265
0.014

中心性
図 3 は，関連プロセス領域ネットワークでの入次数中心性を成熟度レベルごとに視覚化したものである．図中の円形のノードはプロセス領域に相当し，中図3

CMMI-DEV 1.3 における成熟度レベルごとの，プロセスエリアネットワーク中の入次数中心性の視覚化．

心性の値に比例した大きさを持つ．ノードにはプロセス領域名も併記されており，その文字の大きさも中心

リーのプロセス領域よりも他のプロセス領域を性の値の大きさに比例している．

強化する方が効果が高いと推測される．

図 4 は，関連プロセス領域ネットワークでの媒介• 成熟度レベル ML3 で定義されたプロセス領域

中心性を図 3 同様に成熟度レベルごとに視覚化した群では，エンジニアリングカテゴリーの中で強調ものである．

すべきプロセス領域の識別の手掛かりが得られこのような傾向をより把握しやすくするために，成る．入次数中心性での一ホップの参照関係を考慮

熟とレベルごとの関連プロセス領域ネットワークとそした分析では，要件開発 RD に加え，検証 VERの中心性の分析結果を視覚化する．

と技術解 TS のプロセス領域も大きな値を持っている．一方，媒介中心性の解析では要件開発 RD

4. 4 考察以外は必ずしも大きな値を持っておらず，より広視覚化の結果をもとに，以下のような考察を行った．.

い範囲でのつながりを重視する場合はまず要件• 成熟度レベルが ML3 より低いと，エンジニアリ

開発 RD に着手するのが良いと考えられる．

ングカテゴリーのプロセスは他のプロセス領域• 実装に近いレベルの検証に有効な形式手法といに影響を与えるかはわからない．形式手法の導入

うより，上位レベルの仕様の記述に有効な形式手が直接関連するようなエンジニアリングカテゴ

法を用い，要件開発 RD のプロセス領域が改善

プロジェクト計画策定 PP，検証 VER，技術解

TS，要件管理 REQM は，成熟度レベル 3 から5 まで大きな値を持つ．一方，測定と分析 MA，
組織プロセス定義 OPD と決定分析と解決 DAR
は成熟度 4 から 5 に進むに従い大きな値となっている．
上記のような考察は，これまでの筆者らの経験と符合するものが多い．書くべき仕様を明確に抽出，管理できていない状況では，形式手法導入以前に行うべきことが多い可能性が高い．形式手法の導入に関して，コストを厳密に比較した上で判断したい場合は，
まずベースラインの測定結果が必要であることを認識していないことが多い．こういった状況だと，形式手法導入に関する建設的な議論ができない可能性があるが，上記のような，これまでのベストプラクティ
スを反映したモデルであり，客観的にアセスメント可能なモデルでの考察結果を示すことで建設的な議論につながる可能性がある．

4. 5 関連研究
関連する既存研究として，CMMI のモデル構成要素を分析した ?[] ?[] がある．
図4

CMMI-DEV 1.3 における成熟度レベルごとの，プロセスエリアネットワーク中の媒介中心性の視覚化

研究 ?[] では，モデルの構成要素のうち固有プラク
ティスに焦点を当てている．CMMI-DEV の公式ドキュメントでは，固有プラクティスのうち，どれをどされると，その効果が他のプロセス領域に波及すの順番で実装するといったことが明記されていないた

る可能性がある．

め，固有プラクティスの依存関係を示すことで実装の• 測定と分析 MA プロセス領域は，入次数中心性

順序関係の指針を示そうとるものである．公式モデ

分析の結果では ML5 まで大きな値を持たない．

ルのテキストを分析し，各作業成果物とそれを生成，

媒介中心性の分析結果では，ML3 から ML4 へ利用する固有プラクティスを識別した上で，プロセスの遷移で要件開発 RD とプロジェクト計画策定

領域内，プロセス領域間での，固有プラクティスの間

PP の値が小さくなる一方 MA は大きな値を持っの依存関係を識別している．しかしながら，対象は成ている．より広い範囲での定量的な管理や最適化

熟度レベル ML2 のプロセス領域だけであり，より多を重視する場合は測定と分析 MA プロセス領域

くのプロセス領域を含みより高い成熟度のレベルでの重要度が高いことが推測される．

は分析していない．

• 媒介中心性分析のレベル 4 から 5 への遷移では，

図 5 は文献 ?[] からのもので，構成管理 CM プロセ

技術解 TS の値が大きくなっており，最適化を目

ス領域の固有プラクティス間の依存関係を示したもの

指す状態では技術解のプロセス領域の重要性がである．黄色のボックスは固有プラクティスを表し，高まっている．

それらの間の依存関係を矢印で表している．このよう• 入次数の中心性分析の結果では，要件開発 RD，な図は，個別のプロセス領域内だけでも，ネットワー

ク図は煩雑になる可能性があり，多数のプロセス領域

つ CMMI-DEV を対象に，モデル構成要素のひとつ，に対して俯瞰的な分析を行おうとしても対応が困難

関連プロセス領域に着目した，俯瞰的な観点からの分になることが予想される．

析や視覚化を行った．モデルレベルの俯瞰的な観点により，形式手法導入の効果について系統的に考察することができた．例えば，エンジニアリンク区分のプロセス領域に形式手法を導入したとしても，その効果・影響が，他の区分，支援，プロジェクト管理，プロセ
ス管理の区分にも及ぶ可能性をモデルで示すことができた．また，成熟度ごとのプロセス領域の集合に対して，関連プロセス領域に指定された関係を用いて構成したネットワークの中心性を分析し視覚化することで，導入推進経験者の経験則がベストプラクティスを反映したモデル上での分析結果と合致することを示すことができた．このような結果を利用することで，形式手法導入についてより建設的な検討ができると
考える．

図5

構成管理 CM プロセス領域における固有プラクティ
ス間の依存関係 (文献 ?[] より)

本稿では，必ずしもエンジニアに限定せず管理者層も含めたステークホルダーの間で形式手法のような新しい技術を導入する際の認識を共有することも想定し，鳥瞰的な視点での分析を指向している．鳥瞰的な手法で範囲を限定した後，対象範囲を詳細に分析する，といった際には，上記の関連研究のようなアプローチが有効な可能性がある．そのような，複合的なアプローチについては今後の研究課題とする．

5 おわりに我々は，形式手法の普及の阻害要因のひとつとして，実際のソフトウェア開発のプロセスに新規な手法を導入したりその利用を継続するためのプロセス
テーラリングの難しさがあるためと考える．このような問題に対し，効果的なプロセスは新しい技術を導入し使用するための手段を提供する，という考えの下，
ソフトウェア開発のベストプラクティスを体系化した
開発プロセスモデルを用い，形式手法の普及を促進す
る方法に取り組んでいる．
本研究では，抽象度の高いプロセス改善モデルの一参 考 文 献[ 1 ] 独 立 行 政 法 人 情 報 処 理 推 進 機 構, ソ フ ト ウェア
開 発 デ ー タ 白 書, http://sec.ipa.go.jp/publish/
whitepaper (2014 年 7 月 22 日閲覧)
[ 2 ] The International Organization for Standardization, ISO 9000 - Quality management, http://www.
iso.org/iso/home/standards/management-standards/
iso_9000.htm (2014 年 7 月 22 日閲覧)
[ 3 ] CMMI, http://cmmiinstitute.com/[ 4 ] Jim Woodcock, Peter Gorm Larsen, Juan Bicarregui, and John Fitzgerald. Formal methods: Practice and experience. ACM Comput. Surv. 41, 4,
2009.
[ 5 ] 栗田太郎, 太田豊一, 中津川泰正：携帯電話組み込み
用 モバイル FeliCaIC チップ 開発における形式仕様
記述手法の適用とその効果, ソフトウェア・シンポジウ
ム 2006, pp. 49–66, 2006.
[ 6 ] 荒木啓二郎：ソフトウェア開発現場への形式手法導入 −形式手法適用の実経験から得られた知見−, SEC
journal, Vol.6, No.2, pp.104-107, 2010.
[ 7 ] 実務家のための形式手法教材「厳密な仕様記述を志すための形式手法入門」，独立行政法人情報処理推進機
構 ソフトウェア・エンジニアリング・センター報告書,
2012.
[ 8 ] 厳密な仕様記述における形式手法成功事例調査報告書，独立行政法人情報処理推進機構 ソフトウェア・エ
ンジニアリング・センター報告書, 2013.
[ 9 ] J. McHale, and D. Wall, ”Mapping TSP to
CMMI,” Software Engineering Institute, Carnegie
Mellon University, Pittsburgh, Pennsylvania, Technical Report CMU/SEI-2004-TR-014, 2005.
[10] Team Software Process, http://www.sei.cmu.
edu/tsp/[11] Humphrey, W. S.: PSP: A Self-improvement
Process For Software Engineers, Addison-Wesley
Pub, 2005.
[12] [13] [14] [15][12] 小材健，日下部茂，大森洋一，荒木啓二郎：測定可
能な個人プロセスを対象とした形式手法導入に関する提案，情報処理学会ソフトウェア工学研究会研究報告，
2009-SE-163-21 pp.17-24, 2009.
[13] 日下部茂，大森洋一，荒木啓二郎：規律を重視した
ソフトウェア開発プロセストレーニングコースを利用した個人レベルでの形式手法導入の試み，ソフトウェアシ
ンポジウム SS2011 予稿集, 2011.
[14] 山田真也，日下部茂，大森洋一，荒木啓二郎：ソフ
トウェア開発チームプロセス演習 TSPi へのモデル指向

形式手法 VDM の導入事例，ソフトウェアシンポジウ
ム SS2012 予稿集, 2012.
[15] 金丸将平，岡部正臣，山本大輔，三善浩司，青山慎二，松村成樹，荒木啓二郎，日下部茂，大森洋一，
吉武浩，岩崎孝司，山田浩，日下部雄三，規範的チー
ム開発プロセス TSPi に基づく産学連携 PBL の事例
報告〜Openflow コントローラ開発への形式手法導入〜，情報処理学会研究報告・ソフトウェア工学 (SE)，Vol.2013-SE-179, No.26, 2013.
[16] Graphviz - Graph Visualization Software, http://www.graphviz.org (2014 年 7 月 22 日閲覧)
[17] Gephi, The Open Graph Viz Platform, https://gephi.github.io/ (2014 年 7 月 22 日閲覧)