プロセスモデルを用いたプロセス改善ソリューションの事例紹介 · 2011-11-28 · 自己紹介. 臼井孝雄（うすいたかお）所属：日立ソリューションズ技術開発本部

© Hitachi Solutions, Ltd. 2011. All rights reserved.

株式会社日立ソリューションズエンベデッドシステム事業部

2011/9/9

プロセスモデルを用いたプロセス改善ソリューションの事例紹介

© Hitachi Solutions, Ltd. 2011. All rights reserved. 1

自己紹介☆

臼井孝雄（うすいたかお）所属：日立ソリューションズ技術開発本部担当部長

SEISM認定 SCAMPISMリードアプレイザ資格SEI認定 CMMI入門インストラクタ資格

略歴：1977～電電公社病院管理システム開発1983～日立機械翻訳システム製品開発1992～携帯電話営業支援システム開発1994～日立ソフトヨーロッパ出向(海外向け製品販売)1996～ ICカードアプリケーション(電子マネー)開発1999～ﾋｭｰﾚｯﾄﾊﾟｯｶｰﾄﾞ出向(ソリューション開発)2003～ CMMIコンサルティング業務


１. プロセスとは

２. プロセス改善事例

Contents


１. プロセスとは・プロセスの重要性・プロセスモデル・成功する（かもしれない）プロジェクト・低い能力のプロセスと高い能力のプロセス・プロセスと能力度・開発プロセスの関連


１-１プロセスの重要性

4

求める結果を得るため人・手順・方法・機器やツールを統合

プロセスは

品質、コスト、スケジュールを支える3つの主要な要因の1つ

PEOPLE TECHNOLOGY

PROCESS

機器、ツール

PROCESS

スキル、訓練(教育)動機付け、ﾏﾈｰｼﾞﾒﾝﾄ

内規、基準作業の関連性

AB

CD


１-２プロセスモデル

5

大前提：「システムや製品の品質は、システムや製品を調達し、開発し、保守するために使用されたプロセスの品質に強く影響を受ける。」

ソフトウェア開発のモデル：シックスシグマアジャイルTSP/PSPISO 9000/9001IEEE標準RUPバランススコアカード


１-３成功する（かもしれない）プロジェクト

6

Ａさんの力が及ぶ範囲で、プロジェクトは成功する

…でも、Ａさんが入院したらプロジェクトは終りかもしれない

Ａさんはいわゆる「達人」：・要件定義から設計、テストまで、すべてを高い水準でこなすスーパーエンジニア・プロジェクトリーダーやメンバからの信頼は厚い・問題が発生しても、人並み外れた集中力で、遅れを取り戻すこともしばしば


１-４低い能力のプロセスと高い能力のプロセス

7

• 現在の担当者に強く依存している

• 担当者と管理者により、即席で作られている

• 厳格に従われていない

• 予測困難な結果

• 進捗と品質に対する低い可視性

• 新技術を使用することは危険

• 開発と保守のための規格化されたアプローチ

• 定義され、常に改善されている

• 管理者と他の人々によりサポートされている

• よく制御されている

• 測定値によってサポートされている

• 常なる改善が制度化されている


１-５プロセスと能力度 - 1

8

3．定義された段階

4．定量的に管理された段階

5．最適化している段階

レベルパフォーマンス予測

目標

値目

標値

+a

目標

値-y

頻度

時間／費用．．．

目標

値-z

目標

値-x

2．管理された段階

1．初期段階

© Carnegie Mellon University

頻度

頻度

頻度

頻度





能力度が高まると

① 目標と実績の乖離が減少する

② 実績値のバラツキが減少する

③ 目標の値そのものが改善される


１-６プロセスと能力度 - 2

9

能力度レベル１能力度レベル２能力度レベル３

能力度レベル４能力度レベル５

x xx

x xx

x xx

x

x

x

xx

x

x xx

x

x

x x

xx

x

x

xx

xx

xxx xx

x

xxx

xxxxxx

x xxx


１-７開発プロセスの関連

10

プロセス重視

プロセス定義

革新策と展開

トレーニング統合のための

環境プロセス

実績定量的管理

プロセスの成熟度

組織プロセス管理

成果物検証

測定と分析

妥当性確認

評価と保証

供給者合意管理

契約

プロジェクト計画策定

活動計画

要件開発

要求定義

決定分析と解決

事業計画事業優先付け

プロジェクトの監視と制御

プロジェクト管理

リスク管理

統合プロジェクト管理

要件管理

成果物制御

構成管理

プロセスと成果物の品質保証

原因分析と解決

技術解

設計・製造

成果物統合

指示・指図、制約

製品納入

事業欠陥

欠陥

結果&フィードバック

成果物・製品

並行したフロントエンド

活動


２. プロセス改善事例・改善事例の分野・プロセス資産・組織を改善する体制・標準を適用するための仕掛け・プロセスQA・ピアレビュー・プロセスの安定化・プロセス実績モデル・改善効果の定量化


２-１改善事例の分野

12

標準

実査改善

適用

④ ピアレビュー上流工程での品質確保

⑤ 定量的管理プロセスの安定化

⑥統計的手法改善効果の定量化

⑦フィードバック組織を改善する仕掛け

① 標準の整備暗黙の標準を明示化

② テーラリングガイド標準をプロジェクトに

適用するための仕掛け（適用基準明確化）

③ プロセスQA実施状況を確認するための

仕掛け


２-２プロセス資産

13

作業環境標準

プロジェクトAの定義されたプロセス

プロジェクトBの定義されたプロセス

プロジェクトAのプロジェクト計画

プロジェクトCの定義されたプロセス

プロジェクトBのプロジェクト計画

プロジェクトCのプロジェクト計画

テーラリング指針

ライフサイクルモデルの記述組織の

測定リポジトリ

組織のプロセス資産ライブラリ

組織の標準プロセスの集合

プロセスアーキテクチャ

プロジェクトの環境

組織側

プロジェクト側


２-３組織を改善する体制

14

プロセス改善活動の体制

事業部アプレイザルプロセス改善技術センター

アドバイス

全社合同SEPG委員会

SQAグループ

プロセスQA指摘票

プロジェクト

プロセス改善提案書

開発計画書/完了報告書

プロセス資産・内規（標準プロセス、ガイドライン）・基準書・手順書・ノウハウ・テンプレート・開発計画書/完了報告書、改善提案書・プロセス改善活動状況

WEB公開

審議・承認

全社標準化委員会

全社各種分科会連携

改善ノウハウの共有

テーマ別活動

ピアレビューWG

ツール

部長会議

事業部プロセス改善委員会

事業部SEPG

専任SEPG各部SEPG

QA


２-４標準を適用するための仕掛け - 1

15

（１）カスタマイズルールを規定⇒（テーラリング指針）①標準プロセスの選定②実施項目を選定

（２）情報共有による適用の支援①Ｗｅｂ公開

②適用結果の収集

プロジェクト毎に管理者が個別にカスタマイズ① 誤ったカスタマイズを防止

できない② 重要なプロセスを個人の

判断により、省略してしまう

標準適用には、プロジェクト毎のカスタマイズが不可欠

標準プロセス→プロジェクト毎の定義プロセス

従来今回

テーラリング


２-５標準を適用するための仕掛け - 2

• テーラリング基準

– プロジェクトの属性や性質で決定する例：プロジェクト期間、開発工数、売上、形態(新規、機能拡張、改造)など

– プロジェクト分類で考慮するもの開発場所、顧客、サイズ、体制、形態

• テーラリング指針

– 標準プロセス：省略してよい手順や選択すべき手順などを決定する

– 作業成果物(計画書、仕様書、設計書など)：記述内容を決定する

16


２-６プロセスQA

17

製造

プロセスQA

ソース

現場のプロセスを実査し、プロセス定義の実施状況を確認

チェックリストを用いて、正しいプロセスでテストが実施されているか？

⇒プロセス不遵守事項の発見と原因分析・担当者が基準を知らない → 教育不足、基準の浸透不足・基準が古く使えない → ルール自体の問題・基準を勝手に変更 → 管理の問題

製品のQA → 成果物QA＋プロセスQA

設計

成果物QA

テスト

改善サイクル

・現場プロセス・標準プロセス

チェックリストの結果より、予定通りのテスト項目が消化

されているかを確認

⇒テスト実施状況の把握


２-７ピアレビュー - 1

18

上流工程での不良発見は品質向上に直結– 弊社の品質方針

– 別の言葉で言い換えると

解決策は、ドキュメント・ソースコードへの「レビュー」

テストでの不良減少! すばやい効果!

上流工程での品質確保

テストの前に勝負を決めろ！


２-８ピアレビュー - 2

19

解決策は、ピアレビュー（Peer Review）ペアレビュー（2人でやるレビュー？）ではない

ピュアレビュー（純粋レビュー？）でもない

もちろんビアレビュー（枝豆で一杯？）でもない

ピアレビューとは？

△ 同僚(Peer)が実施するレビュー

○ 欠陥除去を目的に行う成果物に対する技術的なレビュー

ピアレビューにとって大切なもの・レビューで不具合を取り除こうとする文化・レビューの技法・レビューのデータ収集と分析


２-９ピアレビュー - 3

20

不良の前倒し摘出による手戻りの防止

小室睦、男澤康、木村好秀、「開発現場の実態に基づいたピアレビュー手法改善と改善効果の定量的分析」、SEC journal創刊号より

工数/

件

ﾋﾟｱﾚﾋﾞｭｰテスト

削減可能

ピアレビューの効果

テストで不良を発見・修正するのに比べて2倍効率がよい


２-１０プロセスの安定化

21

レビューNo. 準備時間時間人数サイズ指摘件数内改善要件数1 3 13 10 120 19 82 2 3 9 40 2 03 2 35 6 60 2 24 2 15 8 30 9 45 2 2 9 20 1 16 3 7 8 80 13 87 3 2 8 30 2 28 3 5 8 200 11 109 2 2 7 30 3 310 3 3 7 50 5 511 2 3 6 40 5 512 2 3 5 50 12 613 3 5 7 80 6 5

レビューデータ

レビュー速度

指摘密度

8件目のレビュー速度が管理上限

を超えている原因を調査して、再レビューする


２-１１プロセス実績モデル - 1

22

レビュー指摘率(レビュー指摘数／合計)とバグ率(合計／対象サイズ)の相関関係– 単体テストより前に摘出したバグ率：全体バグ率

負の相関関係

解釈：上流工程で不良を除くと類似不良も除かれ品質向上する

バグ率 = 9.109853 - 6.8741829 * レビュー指摘率 - 7.0972925 (レビュー指摘率 - 0.5241)**2バグ率 = 8.8843107 - 6.7126427 * レビュー指摘率

対象サイズ(Ks) レビュー指摘数テストバグ件数合計1 12 32 26 582 25 64 24 883 34 98 79 1774 46 130 169 2995 58 140 232 3726 76 210 262 4727 85 180 364 5448 105 193 500 6939 124 320 524 844

10 145 360 394 75411 180 600 282 88212 210 650 358 100813 243 720 447 116714 354 1030 457 148715 450 1240 605 1845


２-１２プロセス実績モデル - 2

23

レビュー指摘率(レビュー指摘数／合計)とバグ率(合計／対象サイズ)の関係から予測モデルを重回帰分析で求める

レビュー指摘数からテストでのバグ件数が予測できる

予測モデル

合計 = 130.557072912652 + 5.70595836805996 * 対象サイズ

- 0.589751752960368 * レビュー指摘数

対象サイズ(Ks) レビュー指摘数テストバグ件数合計1 12 32 26 582 25 64 24 883 34 98 79 1774 46 130 169 2995 58 140 232 3726 76 210 262 4727 85 180 364 5448 105 193 500 6939 124 320 524 844

10 145 360 394 75411 180 600 282 88212 210 650 358 100813 243 720 447 116714 354 1030 457 148715 450 1240 605 1845


２-１３改善効果の定量化 - 1

24

プロセス改善グループはソースコード生成ツール(LINC)を用いた生産性

向上の効果を確かめようとしている。

(グループ1) 45人のプログラマにLINCを使わずにプログラムを書き、不

具合なく作動するまでの時間を記録する。(グループ2) 32人のプログラマにはLINCを使いながら同じプログラムを作

成し同様の記録をする。

[結果]グループ1の平均 x1=26分、母集団の標準偏差 σ1=8分グループ2の平均 x2=21分、母集団の標準偏差 σ2=6分であった。

LINCにはプログラミングの平均時間を短縮する効果があるかをプロセス改善グループの立場で調べる。(有意水準5%で検定する)

( ) ( )2

221

21

02121

nnXX

Zσσ

µµ

+

−−−=


２-１４改善効果の定量化 - 2

25

従業員番号ツール処理時間1 100014 Non-LINC 442 100016 Non-LINC 173 100018 Non-LINC 254 100024 Non-LINC 165 100031 Non-LINC 286 100040 Non-LINC 277 100052 LINKC 238 100061 LINKC 289 100069 LINKC 18

10 100076 LINKC 1511 100072 LINKC 2812 100074 LINKC 2113 100001 Non-LINC 2514 100007 Non-LINC 3015 100020 Non-LINC 3516 100036 Non-LINC 2517 100046 LINKC 918 100050 LINKC 2619 100066 LINKC 1520 100056 LINKC 24

Documents

プロセスモデルを用いた プロセス改善ソリューションの事例紹介 · 2011-11-28 · 自己紹介. 臼井孝雄（うすいたかお） 所属：日立ソリューションズ技術開発本部

プロセスモデルを用いたプロセス改善ソリューションの事例紹介 · 2011-11-28 · 自己紹介. 臼井孝雄（うすいたかお）所属：日立ソリューションズ技術開発本部