SPI Japan 2012

全社的なソフトウェアプロセス改善活動の実践結果とその振り返り
Experiences of Software Process Improvement Activities in a Large-Scale Organization
株式会社 東芝
Toshiba Corporation○小笠原 秀人
藤巻 昇
艸薙 匠
會澤 実
Takumi Kusanagi
Minoru Aizawa○Hideto Ogasawara Noboru Fujimaki({hideto.ogasawara, noboru.fujimaki, takumi.kusanagi, minoru.aizawa}@toshiba.co.jp)
Abstract This paper shows the actual results and effectiveness of mechanism built based on 6 activities forpromoting process improvement activities in a company which consists of a large number of development
departments. The mechanism promotes the process improvement activities, and contributes to the improvementin process maturity of each development department greatly. Given this situation, it is clear that the quality of themechanism has a great influence on overall improvement activities, and that it is important to find the mosteffective method of constructing the mechanism. For nearly ten years, we have been constructing the mechanismand promoting process improvement activities using it. As a result, maturity level was improved in a large
number of development departments, where the applicability of the mechanism has been confirmed.

1. はじめにソフトウェアプロセスの持続的な改善を推進する方法論として、能力成熟度モデル CMMI（能力成熟度モデル統合：Capability Maturity Model Integration）が多くの組織で活用されている。
この CMMI を利用し、ソフトウェアプロセス改善（SPI：Software Process Improvement）活動をより効果的・効率的に推進するために、文献[1]では、推進体制や普及手段など 7 種類の広義の支援ツールが提案され、その支援ツールの適用による効果も示されている。組織のあるべき姿として CMMI を利用した SPI 活動を推進する際には、多くの場合、この活動を推進する専門の部門が、アセスメント手法などの支援ツールを準備し、複数の開発部門へ同時並行に展開することを計画する。同時並行に展開するために、一般的には、ひとつの部門で先行して試行し、そこで得られた知見をまとめ、他の部門へ展開するというアプローチを取ることが多い[1][3]。
しかしながら、試行対象の部門で成功した結果を他の部門へ展開する際には、試行時のような手厚い支援を多くの部門に同時並行で提供できないという難しさがある。大規模組織において、ソフトウェア開発のベストプラクティスである CMMI などを活用して SPI 活動を展開・推進するものの、期待された効果が得られない原因は、「組織横断的に SPI 活動を推進するための方法論が確立されていない」ということが大きな要因と考えられる[4]。
ソフトウェアプロセス改善活動カンファレンス(SEPG North America、SPI Japan など)に代表されるソフトウェアプロセスに関する会議では、主にソフトウェア成熟度モデルの構成や記載すべき項目、成熟度毎の改善活動の推進方法、改善活動を推進するために設置されるグループの役
割や機能、モチベーションの維持、管理手法や管理ツールの導入・展開方法、プロセス改善の効
果などに関しての研究や議論、紹介が行われている。
図 1 に、期間と対象とする組織数に対する従来の研究範囲と不足していると思われる研究領域を示す。従来の研究対象は、対象とする組織数が限定的であり、期間も比較的短いものが多い。
一方で、全社的な SPI 活動の普及・展開を考えると、対象とする組織数が多く、長期間にわたる活動に対するアプローチが必要となる1。
株式会社 東芝 ソフトウェア技術センター
Software Engineering Center, Toshiba Corporation1
本論文では、全社という意味で使用する。また、本論文では、おおよそ50 以上の開発部門を〒183-0046
神奈川県川崎市幸区小向東芝町 1
1, Komukai
Toshiba-cho, Saiwai-ku, Kasawaki Japan, 183-0046
持つ組織を大規模組織としている。

1

SPI Japan 2012

図1

SPI 活動に関する従来の研究範囲と不足している研究領域

SW-CMM（SW:Software）が非常に注目を集めていた 1990 年代後半、SPI 活動を全社的に推進するという計画が示された。この時、一番重要なポイントとして考えたことは、いかに多くの開発部門にこの活動を展開し定着2させることができるのか、ということであった。そこで、「SPI 活動を推進・定着させるための仕組み」を提案し、この仕組みを利用して、SPI 活動を推進するための枠組みである「SPI フレームワーク」を構築しながら、全社的な SPI 活動を 2000 年から継続してきた。この取り組みは、図 1 に示した“不足している研究課題”に対するアプローチのひとつである。
本論文では、2 章で「SPI 活動を推進・定着させるための仕組み」を説明し、3 章で、その仕組みを利用して実践してきた結果を示す。続く 4 章で、全社的な SPI 活動を推進しながら構築した「SPI フレームワーク」を説明する。最後に、5 章で「SPI フレームワーク」の実践における工夫
点、当初の予定どおりに推進できなかった項目について議論する。
2. SPI 活動を推進・定着させるための仕組み
1990 年代にいくつかの品質管理ツールを社内展開した際、ツールの利用が組織横断的に定着する組織とそうでない組織があることを認識していた[5]。「SPI 活動を推進・定着させるための仕組み」を検討する際、定着する組織の特徴を洗い出し、そこから得られた内容を仕組みに反映することを考えた。定着する組織の分析結果を図 2 に示す。
活動3改善モデルの理解

改善技術の習得

継続性

活動1

活動4

管理手法／管
理ツールの導入促進

現状の課題を適切に把握できている改善活動ができている手法やツールをタイミングよく導入している改善活動にリ
ソースが与えられている

効果が実感で
きている

実行力

カンパニー
レベルの支援がある
成功事例を他
部門へ展開

体制・展開

活動2

活動6

効果の見せ方活動5推進体制の構築

情報共有の促進

図 2 定着する組織の特徴
ツール利用が組織横断的に展開できている組織の特徴として、最も重要なポイントは、改善活動ができているということであった。また、改善活動を行うために、体制・展開の観点から重要
2

開発部門の中で定常的に SPI 活動が実施されている状態を定着と捉えている。

2

SPI Japan 2012
なポイントが見えてきた。さらに、継続的に実施するためのポイントが明らかになった。この分
析結果から、強化すべき 6 つの活動を定義した。さらに、これらの 6 つの活動を構成要素として捉え、それらの構成要素を有機的に機能させるための枠組みと、構成要素と推進部門を充実させるための手順をセットにした「SPI 活動を推進・定着させるための仕組み」として定義した（図 3）。
手順については、中長期的な視野を持って活動できるように、計画、実施、展開、定着の 4 つのフェーズを定義した。この仕組みでは、おおよそ 5～10 年の期間でこの 4 つのフェーズを回すことを想定している。

活動4

活動1

管理手法／
管理ツール

活動3
改善の技術とスキル改善のモデル

利用する
利用
する

利用する
推進体制を
ベースとした
SPI活動

活動2

構成要素と推進部門を充実させるための手順

提示する

改善活動の
成果と効果の可視化
活動6

各活動を有機的に連携

活動5

プロセス改善共有 活動推進のため
する
の情報基盤

フェーズ

計画

実施

展開

定着

項目
推進体制
スキル

構成要素を構築するための手順

サイクル1～
サイクルn

…
推進方法
人材育成計画推進部門側の計画立案の手順

リソース計画

図3

SPI 活動を推進・定着させるための仕組み

大規模組織の特性を考慮したうえで、多くの組織で SPI 活動を定着させるために定義した 6 つの活動の概要を以下に示す。
(1) 改善のモデル
組織の成熟度を高めるためには、中長期的な視点からのあるべき姿を持つことが大切である。
また、そのあるべき姿に到達するためには、改善のサイクルを回し続けなければならない。
企業全体で SPI 活動を実施するためには、中長期的な視点からのロードマップを示してくれるモデルの選定と、改善活動を効果的・効率的に回し続けるための方法論が必要である。
(2) 推進体制の構築
複数の開発部門における SPI 活動を支援するには、必然的に人的リソースが不可欠である。
また、製品、市場、事業などの特性を考慮した適切な SPI 活動を実践するためには、支援部門側と開発部門との間をつなぐ役割を持ったメンバを含めることが必要である。
(3) 改善技術の習得
製品の多種多様化に伴い、組織を横断したクロスファンクションチームを作り製品開発を進める機会が多くなってきている。開発プロセスの共通概念を持ち、改善活動に対して共通の理解を持つことは、プロジェクトを成功につなげる重要な要素である。また、開発部門間のSPI 活動にバラツキがでないように、企業全体での底上げを考慮する必要がある。
(4) 管理手法／管理ツールの導入促進開発部門では、製品開発に組織のリソースの多くを使うため、管理手法や管理ツールの有効性が理解できていても、導入・評価し、組織内へ定着させることが難しい。管理手法や管理ツールを実際の製品開発で使えるレベルのものに仕上げ、それを開発部門内に展開するための支援が必要である。
(5) 情報共有の促進
開発部門での SPI 活動は、自部門に閉じた活動になりがちである。したがって、さまざまな

3

SPI Japan 2012
解決方法の中から、適切なものを選択できるように、他部門の活動状況や開発プロセス、ベストプラクティスなどを参照できる情報基盤の整備が必要である。また、SPI 活動は成果が見えづらいという側面もあるため、推進担当者や開発部門のメンバのモチベーションを維持することが大きな課題である。
(6) 効果の見せ方
SPI 活動は、投資に対する効果がどちらかというと間接的・長中期的であることが多い。一方で、SPI 活動の投資対効果を経営層や管理者層に示すことが、コミットメントを維持するために重要である。したがって、活動の成果（プロセスの定着と成熟度の向上）と活動の効
果（品質・納期・コストの向上）を論理的に関係付けて捉え、可視化することが必要である。
3. 「SPI 活動を推進・定着させるための仕組み」をベースとした実践結果
2000 年から、図 3 で示した仕組みに基づいて構築した SPI フレームワークを活用して、全社的な SPI 活動を実践してきた。この活動を単なる“運動”としないために、全組織が必ず実施する
ものではなく、ミドルマネジメント（開発部門の部門長）のコミットメントが得られた組織が実施する活動としている。SPI フレームワークを構築するために立案した約 10 年間の計画の概要を
図 4 に示す。さらに、3.1 節以降で、SPI フレームワークを構成する各活動を実践する際の工夫点と効果について説明する。

活動1：改善のモデル

計画

実施

展開

定着

2000‐2002

2003‐20042005‐2007

2008‐2010

コア技術

コア技術の改善・拡張

試行評価

推進体制や
トレーニングコース
の確立

選定・準備

改善ソリューションとして提供／情報基盤
サービスの提供

活動2：推進体制をベースとしたSPI活動
活動3：改善の技術とスキル
活動4：管理手法／管理ツール
活動5：プロセス改善活動推進のための情報基盤
活動6：改善活動の成果と効果

図4

検討・準備

規定化／
標準化

改善・拡張

SPI活動レポート提供

SPI フレームワーク構築のための計画の概要

計画のフェーズでは、試行評価を確実なものとするために、改善のモデルとして選定したものに対する理解度を高め、そのモデルをより良く活用するためのガイドなどの開発が重要と考えた。
実施、展開のフェーズでは、試行評価に基づいた活動を行うことと、コア技術の改善・拡張に注力する計画とした。また、実施フェーズから、改善活動の成果と効果の可視化についての検討を開始することにした。これは、プロセスが未成熟な段階でデータの収集を行っても、精度のよいデータは収集できないと考えたからである。定着フェーズでは、実践してきた活動結果を全社レ
ベルでの規定化／標準化につなげることを計画した。
3.1 活動 1：「改善のモデル」の選択と習得改善のモデルとして CMM（活動開始当初は SW-CMM、途中から CMMI）を選択した。また、SPI 活動に
お け る PDCA （ Plan-Do-Check-Action） のサ イクル とし ては、Ｉ ＤＥ Ａ Ｌ（ Initiating 、 Diagnosing、
Establishing、Acting、Learning の 5 つのフェーズから構成されている）を選択した[2]。
ＣＭＭ、IDEAL ともに、ただ単にモデルをそのまま利用するのではなく、東芝グループの事例を交えたガイド（全 KPA（Key Process Area）毎のガイド、IDEAL ガイド）を、初期のフェーズで作成した。推進部門

4

SPI Japan 2012
側にとって、“自分たちの武器”を持つことが、以後の活動に対して大きな効果を発揮した。さらに、モデルの理解を深めるため、コアメンバをリードアセッサ／リードアプレイザとして育成した。専門家を複数人育成できたことで、専門家集団として認知してもらえるようになった。
3.2 活動 2:「推進体制をベースとした SPI 活動」の推進
改善活動の推進母体として SEPG（Software Engineering Process Group）の設置を必須とした。
また、開発部門の状況に合わせたきめ細かい支援を実施するには、事業分野毎に SPI 活動を支援する部門を設置することにした。さらに、SPI 先端技術の研究・開発や SPI 活動のノウハウ、ベストプラクティスの共有など SPI 活動のシナジー効果を創出し、全社的に SPI 活動を推進していくためには、
全社レベルで SPI 活動をとりまとめる SPI 推進部門を確立することが必要と考えた。
このような検討の結果、開発部門、事業部門（カンパニー）、全社（コーポレート）の 3 階層でSEPG 体制を構築することにした。
3.3 活動 3:「改善の技術とスキル」の習得
この活動の中心は、トレーニングの提供とカンパニーSEPG／コーポレート SEPG による支援活動である。トレーニングとしては SEPG メンバ向けのものと、SQAG（Software Quality AssuranceGroup）向けのものの 2 つを提供している。
図 5 に SEPG リーダコースの概要を示す。このリーダコースは、約 11 日間（各月 2～4 日、4 ヶ月）のトレーニングであり、CMMI と IDEAL を十分に理解してもらい、実践の場で活用できる能力を身に着けてもらうことが主目的である。カリキュラムとしては、成熟度モデル、プロセス改善
活動の進め方、一般スキル／関連技術、情報共有と知識共有というグループ毎に、必要なモジュールを定義している。SQAG は、組織やプロジェクトの活動が、決められたプロセスに遵守しているかどうかを確認するとともに、プロセスをよりうまく活用するためのサポートをすることが主な役割である。3 階層 SEPG をベースにした SPI 活動の進展に伴い、SQAG メンバに対するトレーニ
ングコースの要望が強くなってきた。そこで、2006 年から SQAG に対するトレーニングコースの開発を行い、2007 年から、SQAG 入門教育、SQAG リーダコースを提供している[6]。
スケジュール 各月2～4日で4ヶ月にわたるるカリキュラム
トレーニング

6月

7月

第1ターム

第2ターム

8月

9月

第3ターム

第4ターム
継続

SPI活動
Initiating &Diagnosing

Establishing& Acting

Acting&Leaning 発表

モジュール
・CMMI概論
・プロセス教育(レベル2～5)・メトリクス教育・TSP/PSP概論

・IDEAL方法論
・SEPG概論
・SQA/PPQAの実践・プロセス診断手法
・プロセス定義手法
・現場密着型の改善手法
・チームビルドの方法

・プレゼンテーション
技法
・ＩＳＯとの連携
・CMMIとPMBOKとの連携

・宿題結果報告
・受講者成果発表
・実践部門紹介

成熟度モデル

プロセス改善活動の進め方

一般スキル／関連技術

情報共有と知識共有

図5

SEPG リーダコースの概要

開発部門 SEPG への支援を行う際には、基本的に 2 人でペアを組み、定期的に開催する SEPG 会
議の場で議論や検討を行う。また、カンパニーSEPG やコーポレート SEPG では、各開発部門 SEPGに対して実施した支援内容（結果、工夫点、失敗点など）を定期的にまとめ共有化し、自分の経
験以外の支援技術が獲得できるようにしている。

5

SPI Japan 2012
3.4 活動 4:「管理手法／管理ツール」の選択と導入・展開
開発部門において、SPI 活動の推進者が一番悩むことは、“具体的に何をどう改善したらよいか分からない”、“どこから着手したらよいのか？”といったことである。また、組織のマネー
ジャや担当者からは、“何か効果的な手法やツールはないのか？”と求められることもよくある。
そこで、SPI 活動をスムーズにスタートさせるために、ある 1 つの具体的な改善活動の導入から定着までをサポートするための改善ソリューションを提供してきた（図 6 の活動 4 参照）。
3.5 活動 5:「プロセス改善活動推進のための情報基盤」の確立
SPI 活動に参画する開発部門や個人の質的・量的拡大をはかるとともに、SPI 活動を推進しているメンバのモチベーションを維持・向上させることを目的として、イベント、情報発信、推進施策検討の 3 つの仕組みを整備した（図 6 の活動 5 参照）。また、支援活動を継続するという安心感、信頼感を提供するために、定期的に開催することを心がけている。
3.6 活動 6:「改善活動の成果と効果」の可視化
SPI 活動の成果と効果を示すため、開発部門 SEPG から SEPG と SQAG の活動工数、プロセス領域
毎のプロセス定着具合、プロジェクトの期間・工数・不具合の予定と実績などのデータを提供してもらい、データベース化している。そのデータベースに蓄積された結果を分析し、全社レベルでの活動状況をまとめた SPI 活動レポートと個別フィードバックレポートを発行している。このレポートの中で、SPI 活動の成果は、定着状況や組織成熟度の達成状況を使って説明している。
また、SPI 活動の効果として、開発期間、開発工数、開発規模の予定と実績を毎期積み上げ、誤差率の傾向の推移を提示している。
データ収集に際しては、“第三者には生のデータを開示しない、組織を横並びで評価しない、
SPI 活動レポートでは絶対値の指標を出さない”ということを提示することで、データ提供への心理的負担を軽減するとともに、データ精度を維持することを心がけてきた。
4. SPI フレームワークの構築
2000 年から表 1 で示したステップで、強化すべき 6 つの活動の具体化を進め、計画、実施フェーズの最初の 5 年間で、SPI フレームワークを構築した（図 6 参照）。
作成したガイドをコンサルティング、トレーニングに利用「改善のモデル」の選択と習得「管理手法／管理ツール」の展開- メトリクスに基づく品質管理手法- ロードマップ：CMMI- 改善のサイクル：IDEAL

改善ソリュー - レビュー技法を用いた品質向上手法
ションとして - 静的解析ツール- 不具合管理ツール
提供
活動4

開発/
提供

- テスト管理ツール

使用

コンサルティング
- CMMIガイドブック- 改善ソリューション
- 推奨プロセス- プロセス診断

イベント

使用

使用
開発部門SEPG

開発/提供- SEPGリーダコース- CMMI関連トレーニ
ング- SQAG入門コース／
SQAGリーダコース

支援
使用

開発/提供
連携

開発/提供

情報

図6

支援

提供

活動2

活動6

- ソフトウェアフォーラム- SEPGワークショップ- SEPGリーダフォロー
アップ

‐ 掲示板
‐ ニューズレター‐ メーリングリスト- ユーザ会

推進施策検討

コーポレートSEPG

作成「改善の技術と1
スキル」の習得

活動5

情報発信／共有
情報

使用

カンパニーSEPG

トレーニング

使用「プロセス改善活動の推進体
制」の構築

活動3

活動1

使用

SPI活動レポート（全社レポートと個別フィードバック）

SPI推進委員会- SEPG分科会- SQAG分科会- ツール分科会「改善活動の成果と効果」の可視化

SPI 活動推進のために構築した SPI フレームワーク

6「プロセス改善活動推進のための情報基盤」の確立

SPI Japan 2012
その後、この枠組みを大きく変えることなく、個々の内容を充実させながら全社レベルでの SPI
活動を継続している。コーポレート SEPG、カンパニーSEPG の支援内容と頻度は、開発部門における SPI 活動の定着度合いや成熟度の達成状況に応じて変化する。個々の開発部門が自立的に SPI活動を推進できるようになると、活動 3～5 で提供しているさまざまな取り組みや成果物を有効活用できる。さらに、 活動 6 で提供する情報を利用し、さまざまな階層のメンバに活動状況や実績を適切に示すことができる。
5. 活動の振り返り
約 10 年間にわたり実践してきた SPI 活動では、さまざまな製品領域（デジタルプロダクツ、電子デバイス、社会インフラ、ソリューション、海外開発拠点、研究・開発部門）を持つ組織を対象にしてきた。また、それぞれの組織人員数も 20 人未満の小規模組織から 200 人以上の大規模組織までをカバーしている。このことは、本論文で示した実践結果が、筆者の所属する企業独特のものであるということではなく、ある程度の一般性を与えるものであることを示している。
また、本活動を実践した結果、活動開始時に SPI 活動を定着させる必要があると想定した開発部門のうちの約 80%の開発部門で SPI 活動が定着し、プロセス成熟度の向上が確認できた。また、構築した SPI フレームワークは維持・改善されていることから、本活動では、当初の目標に対して十分な成果が得られたと考えている（詳細は文献[7]を参照のこと）。以後、本活動を実践する
うえで工夫した点と、当初予定していたが達成できなかった項目とその要因について述べる。
5.1 本活動における工夫点
図 4 に示した 4 つのフェーズ毎に工夫したことを、以下に述べる。
(1) 計画フェーズ
全社レベルでの SPI 活動を推進するために、開発部門を支援するメンバの育成と、支援する際に必要となる道具（武器）の開発が重要となる。この点については、上述したとおりコアメンバ
を中心に、ガイド作成などと並行して、アセスメントを複数の部門で実施し、モデルの活用方法
や SPI 活動の推進方法に関する技術とノウハウを蓄積した。また、アセスメントを実施するためには予算が必要となるため、経営層に対する定期的な説明の場を作り、この活動に対するコミッ
トメントを確実なものとした。
(2) 実施（基礎固め）フェーズ
このフェーズでは、支援部門数が急増した。上述したとおり、開発部門に対しては、必ず二人ペアで支援するという方針をたてた。また、支援メンバの SPI に関連する技術とスキルを向上し、ノウハウを共有するため、毎週一回は全員が集まる日とし、その日に、推進部門として実施すべ
きさまざまな活動を集約して実施した。
(3) 展開フェーズ
各開発部門における SPI 活動の自立化を促すため、開発部門 SEPG とカンパニーSEPG を中心とした活動にシフトする方針をたてた。これを実現するため、最初に、カンパニーSEPG との連携を強化し、カンパニーSEPG メンバが中心となり開発部門を支援するという体制を確立した（コーポレート SEPG はカンパニーSEPG の支援が中心）。また、SPI 活動の進め方に関するバリエーションを増やすため、今までの実践結果を整理した[8][9]。
(4) 定着フェーズ
各開発部門の成熟度が向上し、より効果的・効率的な手法やツールの導入を求める声が多くなってきた。そこで、いくつかの部門で効果のあった品質管理手法／ツールを活用した SPI 活動を推進するために、品質管理技術を担う役割をコーポレート SEPG に追加した。また、カンパニーSEPG
メンバとコーポレート SEPG メンバとのローテーションの仕組みを確立した。

7

SPI Japan 2012
5.2 達成できなかった項目
本活動を進めるにあたり達成できなかった項目を以下に述べる。これらの項目は、今後の SPI活動を推進するうえでの大きな課題である。
(1) アセスメント手法
当初、CMMI に基づく診断を定期的に実施するために、アセスメント手法を構築し、開発担当者
が他の開発部門の診断に参加できる仕組みの構築を目指した。しかし、開発担当者が他部門の開発プロセスを診断することのメリットを十分に説明できなかったため、この仕組みを確立することができなかった。
(2) SPI 活動に対するスポンサー層の理解を深くしてもらうための活動
SPI 活動に対するスポンサー層の理解を深めてもらい、コミットメントを強固なものとするために、イベントにおいてスポンサーセッションの実施を試みたが、継続して実施してもらいたいという要望は少なく、数回で終わってしまった。
(3) カンパニーSEPG の構築と強化
カンパニーSEPG は、3 階層 SEPG を構成する非常に重要な役割を果たす部門であるが、ビジネス
環境の変化やカンパニーの人員計画などの影響によって、十分なリソースと資金が提供できない場合も少なくない。SPI 活動の必要性と効果を経営層により良く理解していただくとともに、コーポレート SEPG とのローテーション強化などをはかり、カンパニーSEPG の位置づけを強固なものにする必要がある。
(4) SPI 関連のスキル定義とキャリアパス
全社的な SPI 活動の実践によって、SPI 活動に関与するメンバが増えてきた。それにともない、組織の中で、SEPG や SQAG の役割は認知されてきたが、メンバのスキル定義やキャリアパスなど
は十分に示せていない。
6. まとめ大規模組織において、開発部門における SPI 活動の展開と定着を促進するために、「SPI フレームワーク」を構築し、実践してきた内容を提示した。ここに紹介した内容が、この種の活動を実施しようとする企業や組織の参考になれば幸いである。
参考文献[1] Fukuyama, S., Miyamura, S., Takagi, H. and Tanaka, R. : A Software Process Improvement Support System:
SPIS, ICISE Trans, Information and Systems, Special Issue on Knowledge-Based Software Engineering, Vol.4,
No.10, pp. 747-756 (2000).
[2] Robert McFeeley, IDEAL:A User's Guide for Software Process Improvement, CMU/SEI-96-HB-001,(1996).
[3] 福山峻一,高木英雄,田中僚史,渡辺道広,中林效： ソフトウェアプロセスの持続的な改善を誘導するチェックリストの実装手順,情報処理学会論文誌,Vol.42, No.3, pp. 529-541 (2001).
[4] Gargi Keeni, The Evolution of Quality Processes at Tata Consultancy Services, IEEE Software, vol.17, no.4,
pp. 79-88 (2000).
[5] Hideto Ogasawara, Takumi Kusanagi, Mikako Arami: Process Improvement Activities by High Quality
Software Creation Support Virtual Center, 2WCSQ(The Second World Congress for Software Quality) (2000).
[6] 小森真紀,藤巻昇: ソフトウェア品質保証活動を推進できる人材の育成～SQAG 教育コースの開発と実践～, SPI Japan, 2009.
[7] 小笠原秀人,藤巻昇,艸薙匠.田原康之,大須賀昭彦: 大規模組織におけるソフトウェアプロセス改善活動の適用評価－10 年間の実践に基づく考察,情報処理学会論文誌, Vol.51, No.9, pp.1805-1815, Sep. 2010.
[8] 小笠原秀人,青木裕伸,鷲見毅: ワークショップをベースにしたプロセス改善活活動～問題解決を出発点とするために～, SPI Japan, 2006.
[9] 丸屋宏二, 艸薙匠: 改善文化を創る SPI ～改善意識中心アプローチ～, SPI Japan, 2007.

8