Copyright 2011, Toshiba Corporation.

2011年1月18日株式会社東芝ソフトウェア技術センター小笠原 秀人（hideto.ogasawara@toshiba.co.jp）

SPIの動向と発表事例の概要紹介

2

目次

1. SPI関連の動向

2. モデルに基づくプロセス改善の強み

3. 故 ワッツ S. ハンフリー博士を偲んで

4. SPI活動推進上のモードや手法

5. 発表事例の概要

6. 最後に

3

1. SPI関連の動向

• この10年間をふり返ると、CMMIを中心として、いくつかのモデ

ルやプロセス改善活動推進のためのツールなどが提案されてきた

2000 20102005▲

CMMIVer.1.1

▲CMMIVer.1.2

▲CMMIVer.1.3

▲Automotive

SPICE

▲TSP/PSP

(TSPi)

▲ISO9001-

2008

▲SPEAK-IPA／SPINACH、

プロセス改善ナビガイド

▲VSE

4

日本でのSCAMPI評定の実施状況（公開分のみ）

出典: http://sas.sei.cmu.edu/pars/pars.aspxの情報を集計（主催者の意思で公開されない結果もある）

5

CMMIの特徴

• モデル／評定／トレーニングの3点セット

– モデル（教典）は公開で誰でも入手可能

• 現場経験の体系化（肯定）に役立つ

• 新たな観点、挑戦の機会（提言）を提供する

– SCAMPI手法は公開、CMU/SEIによる評定の品質管理／監査

– 入門コース、中級コースなどの研修コース群

• 制度– 管理者としてのCMU/SEI– スポンサーとして国防省（DoD）と防衛産業協会（NDIA）– インストラクタ、主任評定者の資格制度

– パートナー制度（代理店）

• コミュニティ– SEPGカンファレンス、CMMIカンファレンス、資格者ワークショップ

– 関連トレーニング、SPIN

環境

モデル自体以上に、モデルの環境が重要

出典: 端山毅、「CMMIに基づくプロセス改善の強みと高成熟度の意義」、ソフトウェア・シンポジウム2010

6

VSE（Very Small Entities）

• VSEの目標：

– 小組織での開発に着目したコンパクトな実用的な標準

– 小組織に過大な負担（コスト、資源）を強いない標準

– 段階的な作業能力向上を支援する標準

– 小組織のための公式アセスメントの定着と普及を目指す

• 対象組織

– 25人以下の小さなソフトウェア開発組織

– 企業内部門やプロジェクトも含む

• 対象プロセス → 業務に必要なプロセスだけに限定

– ソフトウェア実装（SI）プロセス

• ソフトウェア要件分析～製品納入

– プロジェクト管理（PM）プロセス

• SI実施のための必須アクティビティだけ

• ISO/IEC ISP 29110として発行予定

– 5部構成のISP標準出典: 第2回SRA技術セミナーhttp://www.sra.co.jp/public/sra/event_seminar/seminar2010/101203-h.shtml

7

プロセスと成果物

出典: 第2回SRA技術セミナーhttp://www.sra.co.jp/public/sra/event_seminar/seminar2010/101203-h.shtml

ISO/IEC 29110から引用

8

2. モデル（CMMI）に基づくプロセス改善の強み

• モデル／評定／トレーニング

– 現場に説明可能、推進者の養成が容易

– 評定の重要性（レベルをバカにしてはいけない）

• 現状分析の共通理解に基づくSPI推進

• 儀式を通じた全員参加と理解の醸成

– 暫定的なモデル理解で始めて、理解を深めながら、改善も高度化

• 制度

– CMU/SEIによるモデルの継続的維持改善

– 資格制度、パートナー制度による品質確保

– 資格制度（レベル、資格者）による権威付け

• コミュニティ

– モデル、資格など共通知識基盤の上に成り立つ情報流通

– 一面的実務経験者に翻弄されないプロフェッショナル

実践がフィードバックされる環境出典: 端山毅、「CMMIに基づくプロセス改善の強みと高成熟度の意義」、ソフトウェア・シンポジウム2010

評定は、幹部がモデルを理解する機会

モデル自体が進化する

改善推進者の箔付けも必要

9

モデルに基づくプロセス改善の強み(乗松さんの整理）

出典: 端山毅、「CMMIに基づくプロセス改善の強みと高成熟度の意義」、ソフトウェア・シンポジウム2010

出典：SEPG Japan 2005 チュートリアル「CMMIの活用」より

10

3. 故 ワッツ S. ハンフリー博士を偲んで

能力

計測と分析履行検証活動

コミットメント

制度化して組織の力とする制度化して組織の力とする

11

本当のCMM

• 書籍名：ソフトウェアプロセス成熟度の改善• 原著名：Managing the Software Process• 原著者：ワッツ S. ハンフリー• 監訳者：藤野 喜一• 訳者 ：日本電気ソフトウェアプロセス研究会• 出版 ：日本科学技術連盟

出典: ソフトウェア品質の本音（第2回）、本当のCMM ～故 ワッツ S.ハンフリー博士を偲んで～http://juse-sqip.jp/honne/backnumber_002.html

CMM／CMMIそのものは、規格書のようなもので無味乾燥な文書です。やるべきこ

とが淡々と書いてあるだけで、かつ記述量の多さから「本当にこれ全部やらなきゃダメなの？」というげっそりとした印象を抱くのも無理は有りません。ところが、CMMのコンセプトともなった以下の書籍を読めばCMM／CMMIに対する印象はガラリと変わるはずです。

付録Aには、ソフトウェア成熟度を改善するために組織が注意しつづけな

ければならない、たくさんの優先度の低い事柄についても包括的に要約する。（P75から引用）

12

約束の規律・作成・階層

• 第2部の最初が「ソフトウェア組織の管理」という章です。この冒頭で「約束の規律」という節が有ります。

• 続いて「約束の作成」、更に読み進めると、「約束の階層」という節があります。ここが一番実感し、感銘を受けた部分です。

• 約束に対する姿勢は、よく目に見えるものである。顧客との要求変更の交渉における管理者の強い支持は、ソフトウェア担当者を感動させる。この支持があればこそ、担当者は計画と見積りを満たすための最良の開発ができる。管理者の約束についてのもう１つの姿勢の例は、必要な設備とサービスの獲得に関する支持と、スケジュール通りに会議を行う一般的な慣習である。

• 約束は、生き方の問題である。約束をした組織は、どんな約束でも守らなければならない。組織が小さな約束をおろそかにすると担当者の関心度合いは低くなり、大きな約束にも注意を払わなくなる。Brooksが言うように、「スケジュールは、一時には1日しか遅れない」ものである。（P79から引用）

• 遅延プロジェクトを支援した経験上、そういうチームは、定例会が時間通りに始まらない、提出物が期日を過ぎていても誰も咎めない、などの兆候が有ります。「忙しい！」「このバグを片付けなければ！」などという常套句の前にあらゆる約束が反故にされ、またそれが容認されてしまうのです。

出典: ソフトウェア品質の本音（第2回）、本当のCMM ～故 ワッツ S.ハンフリー博士を偲んで～http://juse-sqip.jp/honne/backnumber_002.html

13

約束が守られなければ何も始まらない

能力

計測と分析履行検証活動

コミットメント（約束）

14

4. SPI活動推進上のモードや手法

• SPI活動のモード：6つのモード

出典: 乗松聡、「問題解決重視とモデル重視 ～組織に合ったプロセス改善モードを探す～」、SEPG Japan 2004

15

SPIモードの遷移

出典: 乗松聡、「問題解決重視とモデル重視 ～組織に合ったプロセス改善モードを探す～」、SEPG Japan 2004

16

SQAGの充実プロセスアーキテクチャの構築

SQAGの設置

組織全体活動へ

WG (Working Group)活動（手

厚い支援付き）

ファシリテーション

PJの振返り

SEPGの設置

施策例

（維持継続）

自主的、効果的な取り組み（オーナーシップ確立）

プロセス志向の改善

身近な課題の解決

信頼感醸成

場作り

コミュニケーション

チームビルド

モード遷移のトリガー

自分たちでプロセスを決めて、守る

プロセスはあるといい。作成に協力はするけど

SPI活動はいい

かも。でも、プロセスは邪魔、障壁

SPI活動は余計

な取り組み、どうせやらないオーラ

組織の状態

積極協調消極懐疑組織モード

出典：丸屋宏二、艸薙匠、「改善文化を創るSPI～改善意識中心アプローチ」、SPI Japan 2007

改善意識学習モードモデル

17

ワークシートを使ったプロセス改善のナビゲーション

現状課題の気づき

領域の絞り込み

ワークシートの選択

ワークシートの記載

改善へ着手

カイゼン気づきシート

ワークシート

＜2つから構成＞

出典：安倍秀二、「扱いやすいアセスメントモデルの追求 ～ワークシートを使ったプロセス改善のナビゲーション」、SPI Japan 2009

18

『カイゼン気づきシート』を使って発生している問題を粗くチェック

要求抽出要求管理

見積計画立案

進捗管理工程完了

リリース管理

要求分析要求定義

設計 実装 テスト

納品後対応

開発のライフサイクル編

一貫性の確保・フィードバック

■いつも計画と実績の乖離が大きい□進捗状況が見えない□急に大きな問題が発生する■超過・休日勤務が多い。疲弊している□進捗が遅れているときの対処が適切でない

□設計が進まない■レビューは実施してない・一部しかしていない□設計レビューで指摘事項が多数発生する■レビューで欠陥が発見できない□プロジェクトの途中で仕様変更が多く作業が翻弄されている

□過少見積が多い□最初から無理な計画になっている■計画の詳細が分からない

■テストで使える期間・時間が足りなくなる■テスト時たくさんの設計や実装のバグが見つかる□テストが不十分(テスト件数、網羅度) □テスト環境が不十分

■コスト超過□納期遅延が多い■製品品質が悪い■顧客のクレームが多い

□要求分析が不十分□要件定義プロセスが存在しない■要件定義が不十分（不明確）

□システム化目的が不明である■要求事項が不明確である

□実装の効率が悪い(時間がかかる)□実装環境が整備されていない

出典：安倍秀二、「扱いやすいアセスメントモデルの追求 ～ワークシートを使ったプロセス改善のナビゲーション」、SPI Japan 2009

19

過大解決のワークシート

今のやり方

今のやり方でうまくいっているところと悪いところ

改善点

対応方法

懸念事項

留意事項

表面WS-P31-1(顧客の要求を獲得する仕組みを確立する）

５ ．この 問 題 にどの ように対 処 したいか

３．現 在 の方 策 の 目 的に照 ら した実 効性 、有効 性 の 自 己評 価

※現在の方策に対して、どこがうまくいっていて、どこが悪いか記載する

顧客 の要求 を獲 得する仕 組み を確立 する

② このテ ーマ が解 決 すると何 が良 くな るか

顧客 要求が 明確 になる。あとから想定 しない仕様 変更が 少なくなる。

２．現 在 どの ような 方 策か

課題解決のワークシート

４．現在の方策の目的に照らした不十分点改善すべき点があるとすればどこか

※うまくいっていない内容で改善ができるものを記載してください

※例えば裏のソリューション例を参照して、考えてみてください

※制約事項、コスト、他への影響など

※例えば、協力者とか支援要望など

６．上 記 対 処 をす るにため の懸 念 事 項

７．上 記 対 処 をす るにため の留 意 事 項

１．テー マと課 題① 取り上 げたテーマ

出典：安倍秀二、「扱いやすいアセスメントモデルの追求 ～ワークシートを使ったプロセス改善のナビゲーション」、SPI Japan 2009

20

5. 発表事例の概要

• 組織学習理論の見地を利用したプロセス改善の実践– 串田 幸江（アッズーリ）

• アセスメント経験にもとづくSEPG人材育成と現場改善への展開– 倉田 智穂（アイシン・エンジニアリング）、

開 泰彰、小室 陽太郎（アイシン精機）、山本 幸弘（アイシン・エンジニアリング）

• 車載ソフトウェア開発におけるプロセス改善– 中田 武志、日高 建二（東海理化）

福原 綾介（日本電気）

• 製品、作業、人に着目した効率的な作業診断の実践– 飯田 卓郎（東芝）、丹羽 友治（東海理化）、

市川 知典（デンソークリエイト）、

村上 孝（システム 技術研究会）、

近藤 清久（三菱電機）、

北野 敏明 （新日鉄ソリューションズ）、

小川 清（名古屋市工業研究所）

• VSEプロセスアセスメント試行の考察– 竹内 元子、静永 誠、塩谷 和範（SRA）

• 宇宙機ソフトウェア開発におけるプロセス改善指向アセスメントモデルの開発と試行– 宮本 祐子（宇宙航空研究開発機構）、

古石 ゆみ（SRA）• 宇宙開発への改善指向アセスメントの

適用– 井上 禎一郎（三菱電機）、

宮本 祐子（宇宙航空研究開発機構）、小嶋 勉、静永 誠（SRA）

21

6. 最後に

• 数々の技術施策を実施するも、

課題が山積してしまう原因は？

「改善の責任」と、

「改善技術／改善ノウハウ」の

継続的な担い手がいない

推進責任の組織長も２年程度で異動

ＸＸＸ運動が終わると推進担当が交代

改善活動に戦略が無い

ライン業務の片手間での改善活動

新しい物好き

改善技術／ノウハウの蓄積が無い

22

どうすれば良いか？－ CMM/CMMIの解

• プロセス改善に責任を持つグループ、

SEPGSoftware Engineering Process Group を設置する

• SEPGを推進母体として、改善活動を常態化する

23

SEPGの役割と責任

• 永続的なプロセス改善活動の実行・推進（常態化）

– プロセス改善活動の推進、プロセス資産の開発・保守

– プロセス技術／ソフトウェア生産技術の担い手

組織の標準ｿﾌﾄｳｪｱﾌﾟﾛｾｽの記述ｿﾌﾄｳｪｱﾌﾟﾛｾｽｱｰｷﾃｸﾁｬ

ｿﾌﾄｳｪｱﾌﾟﾛｾｽ要素の記述

組織の標準ソフトウェアプロセス(OSSP)ｿﾌﾄｳｪｱﾌﾟﾛｾｽｱｰｷﾃｸﾁｬ

ソフトウェアプロセス要素の記述

⑤プロセス資産の確立・維持

⑥プロセスデータベースの確立・維持

④プロセス教育の提供

⑧技術変革活動の中心となる

⑦プロジェクトへのコンサルテーション

②定期的なアプレイザルと状況報告

SEPG③標準プロセスの確立・維持

①改善活動の推進

24

SEPGの位置付け

• 開発チーム／プロジェクト、SEPG、SQAGの体制を確立

• 機能/役割としての話。同じ人／グループが担ってもよい

開発チーム／プロジェクト

SQAG

レビュー・検証、監査報告

SEPG

組織横断的に調整（トレーニング含む）、改善サポート

標準プロセス、

PＤＢ／PＬＩＢ監査 作成、

改善

情報交流

利用、登録

アセスメント／アプレイザルで強み弱みの特定

25

さあ、プロセス改善を始めよう！