セミナー「定量的なプロジェクト管理・プログラム管理の ... · 2019-04-01 · プロジェクトの不十分な状態を把握するための定性的・定量的な「見え

SECセミナー「定量的なプロジェクト管理・プログラム管理のススメ」

Copyright© 2015 Information-technology Promotion Agency, Japan. All rights reserved.

独立行政法人情報処理推進機構 (IPA)

技術本部ソフトウェア高信頼化センター (SEC)

Software Reliability Enhancement Center

データに基づくITプロジェクト管理

～暗黙知の形式知化により，生産性・信頼性を高める～

山下博之

SECセミナー（千石）2015年07月01日

2Copyright © 2009-2015 IPA, All Rights Reserved Software Reliability Enhancement Center

プロローグ（１）

SECセミナー (2015-07-01)

135/85mmHg 以上を高血圧と判定（家庭血圧値）

協力者

見える化：

形式知：

１４０

９０

多数・長期間の健診・臨床データ等

分析

＜高血圧対策＞1 肥満解消（運動）2 ストレス解消3 規則正しい睡眠4 禁煙5 減塩6 ．．．

知見：

比較アクション

ヒューマン・ライフサイクル


プロローグ（２）

SECセミナー (2015-07-01)

＜ポイント＞

暗黙知の形式知化

社会智

智の運用

情報の(セミ)オープン化

経験をデータに基づいて見える化，整理・体系化

社会にとって役立つ知見

知見に基づき行動する，知見を継承するための，不断の努力

多様な意見に基づく，ブレークスルー/イノベーションの創出


プロローグ（３）

SECセミナー (2015-07-01)

暗黙知形式知（知識）

形式知（智恵）

個有

共有

組織

社会

現状

現状

現状

個人が目指すところ

企業が目指すところ

人類が目指すところ

当面のマイルストーン

見える化分析・体系的整理

＜参考文献＞山下: 社会の“インテリジェンス”活用推進に向けた考察, SEC journal, No.23.

知とその共有に関する進化


プロローグ（４）

HV車における表示例

表示内容に応じて運転の仕方を改善

SECセミナー (2015-07-01)


プロローグ（５）

バッテリ（電気）使用走行

ガソリン使用走行

バッテリ充電走行（ガソリン使用無し）

SECセミナー (2015-07-01)

走行モード.WMV

走行モード.WMV

航続可能距離.WMV

航続可能距離.WMV


プロローグ（６）

ガソリン使用走行

バッテリ（電気）使用走行

バッテリ充電中（ガソリン使用）

バッテリ充電中（ガソリン使用無し）

SECセミナー (2015-07-01)

ガソリン

バッテリ

走行駆動

エネルギー使用.WMV

エネルギー使用.WMV


プロローグ（７）

燃費の推移グラフ

SECセミナー (2015-07-01)


講演内容

SECセミナー (2015-07-01)

1. データに基づく管理の分類

2. データと知見の分析・共有の取組み

(0) 見える化

(1) 情報システムの障害状況の整理

(2) 障害情報の収集・分析に基づく教訓の共有

(3) 信頼性自己診断ツール

(4) 定量的品質管理

(5) 定量的プロジェクト管理ツール(EPM-X)

(6) ソフトウェア開発データ白書


データに基づく管理の分類

データ手法見える化ツール(IPA) 主な活用方法

定性

作業日報等ビッグデータ解析 (分析) なし因果関係確認等

失敗/成功事例 (分析) チェックリスト（例:信頼性自己診断ツール）

教訓集

妥当性確認(問題点抽出)再発防止策障害事例 (分析)

定量

開発データインプロセス計測

定量的プロジェクト管理ツール

異常の予兆検知

(4) 比較による計画策定・妥当性確認ベンチマーキング (分析) データ白書

運用データビッグデータ解析 (分析) なし障害予兆検知等

データマイニング活用（確認・対策等)のための知見の抽出

(4) 定量的品質管理，等

(1) 情報システムの障害状況の整理 (2) 障害情報の収集・分析に基づく教訓の共有(3) 信頼性自己診断ツール (4) 定量的品質管理(5) 定量的プロジェクト管理ツール(EPM-X) (6) ソフトウェア開発データ白書及び関連ツール

(2)(3)

(1)(2)

(5)

(6)

ソフトウェアリポジトリ

SECセミナー (2015-07-01)


講演内容

SECセミナー (2015-07-01)



(0) 見える化








(0) 見える化

SECセミナー (2015-07-01)

http://www.ipa.go.jp/sec/softwareengineering/std/ent01-d.html

(1)プロジェクト「見える化」_100130.ppt

(1)プロジェクト「見える化」_100130.ppt


暗黙知の形式知化

プロジェクトの状態を把握するためには、KKD（勘と経験と度胸）だけではなく、定性的・定量的なアプローチが必要。カリスマプロジェクト・マネジメントの暗黙知を形式知にしていくことにより、プロジェクト・マネジメント力の向上を図る

KKD（暗黙知）

・状況を的確に掴むためのチェック項目の検討・網羅性のある観測すべき項目の検討・嘘をつかない定量データの収集方法と活用方法の検討

SECセミナー (2015-07-01)


見える化の必要性

一歩進んだ

プロジェクト

マネジメント

SECセミナー (2015-07-01)

「期限どおり」に、「所定の費用」で、「求められる品質」のソフトウェア開発を行うには、

様々な問題を早期に発見し解決していくためにＩＴプロジェクトのが必要


Ｖ字モデル

「見える化」が対象とする工程（本セミナー）

ライフ・サイクル・プロセス

保守

運用

見える化

SECセミナー (2015-07-01)


上流工程

納期までの切迫感の欠如、要件の曖昧さ、成果物の見えにくさ所詮「見切り発車」

→ プロジェクト稼働後に様々な問題を惹起するリスクを予知し、ネガティブなインパクトを最小にすることは容易で

はない

問題認識

プロジェクトの不十分な状態を把握するための定性的・定量的な「見える化」が必要問題の潜在箇所 ⇒ 早期に発見する不確定な要素 ⇒ いつまで不確定で良いかを評価し、

判断するこのような状況を乗り切ってきたスーパーＰＭの暗黙知を形式知化することが必要

課題

要件定義

システム設計

ソフトウェア設計

プログラミング

ソフトウェアテスト

システムテスト

運用テスト

SECセミナー (2015-07-01)


中流工程

SECセミナー (2015-07-01)

先立つ「上流工程」での要件定義が曖昧なまま、プログラムへの変換作業が進められる→ 多くの要件（仕様）変更と、トラブルの多発

多くのベンダー・技術者による分業となり個人への作業依存が高くなる→ 進捗・品質がばらつきやすい→ プロジェクトの透明性が著しく悪化し管理が難しい

問題認識

要件の曖昧さを把握し是正する「見える化」が必要機能要件、非機能要件要件（仕様）変更への対応

進捗・品質のばらつきを把握し是正する「見える化」が必要

課題

要件定義

システム設計





運用テスト


下流工程

SECセミナー (2015-07-01)

それまでの工程に起因する品質不良が一気に露呈問題に対応するための時間や手段が限定されるという宿命

問題認識

失敗しそうなプロジェクトを救う活動が重要問題の早期発見、迅速な処置のための「見える化」が必要

問題を起こす品質不良の原因は多様なため、「見える化」手法の工夫が一層重要

課題

要件定義

システム設計





運用テスト


定性的見える化アプローチ

俯瞰の視点によるドミナント・アイテムの見える化

事例集

チェックシート（自己評価シート／ヒアリングシート）

俯瞰図

チェック項目によるリスクの見える化

定量的見える化アプローチ

測定項目リスト

測定分析データにしたがって定量化した情報によるリスクの見える化

測定分析データ一覧表

ベース尺度一覧表

支援ツール

３つの「見える化」アプローチ

SECセミナー (2015-07-01)

実践の場プロジェクト

統合的アプローチ

見える化アプローチをひも付けることによる総合的判断の仕組み

リスク分類表


俯瞰図による見える化

経営者発注側

協力会社

マスコミ

発注側の顧客

発注側の株主

営業GM

PM

担当者

プロジェクトマネージャ

経営者

PM

スタッフ

メンバー

メンバー

営業

受注側

営業

共通

GM

プロジェクト

技術面、業務面におけるキーパー

ソン

先方キーパーソン。決定権を持っている

ステークホルダー俯瞰図プロジェクト推進体制俯瞰図周辺システム構成俯瞰図システム構成俯瞰図スケジュール俯瞰図要員遷移俯瞰図

「木を見て森を見ず」弊害の排除ドミナント・アイテム※１を継続的、システム横断的に把握変更が生じたら直ちに修正

※１プロジェクトの成否を左右する支配的要因

SECセミナー (2015-07-01)

（上流：６、中流：７、下流：４例）


ステークホルダ俯瞰図の例（病院システム）

SECセミナー (2015-07-01)


システム構成俯瞰図の例

SECセミナー (2015-07-01)


チェックシートによる見える化

集計・表示ツール付きベテランが現場リーダから

聞き出すエビデンス資料要求 5段階評価所要時間2時間＋

ヒアリングシート：専門家チーム（ＰＭＯ）によるヒアリング（上流：７４、中流：７８、下流：８５項目）⇒ 専門家からの客観的チェック

SECセミナー (2015-07-01)


講演内容

SECセミナー (2015-07-01)



(0) 見える化









SECセミナー (2015-07-01)

※ 「スタンドアロン型信頼性自己診断ツール」公開中http://www.ipa.go.jp/sec/softwareengineering/tool/dependability.html

(5)信頼性自己診断ツール_100130.ppt

(5)信頼性自己診断ツール_100130.ppt


信頼性自己診断ツール信頼性評価指標信頼性ガイドライン

Ⅱ．信頼性・安全性向上に向けての全般的配慮事項.

（１）実施項目

（２）実施項目・・・

Ⅲ．企画・要件定義・開発及び保守・運用全体における事項

信頼性評価指標Ⅱ．信頼性・安全性向上に向けての全般的配慮事項. 診断

0

20

40

60

80

100

企画

開発

保守運用技術

総得点

0

100

200

300

400

500

600

700

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

Q10

Q11

Q12

Q13

Q14

Q15

Q16

Q17

Q18

Q19

Q20

Q21

Q22

Q23

Q24

Q25

Q26

Q27

Q28

Q29

Q30

Q31

Q32

Q33

Q34

Q35

Q36

Q37

Q38

Q39

Q40

Q41

Q42

Q43

Q44

Q45

Q46

Q47

Q48

Q49

Q50

Q51

Q52

Q53

Q54

Q55

Q56 Q1

Q2

Q3

Q4

Q5

Q6

Q7

Ⅱ Ⅲ、Ⅳ Ⅴ

系列1

分野別の適合度実施項目の適合度の合計

質問項目毎の得点

情報システムの信頼性向上に関するガイドライン

経済産業省：平成21年第2版

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

経済産業省：平成21年第１版

質問項目

質問項目

質問項目

質問項目

回答

回答

回答

回答

質問項目

質問項目

質問項目

質問項目

診断結果

実施項目の適合度合い

信頼性自己診断ツール

SECセミナー (2015-07-01)

経験に基づく知見


0

20

40

60

80

100関係者の責務

経営層の責務

企画・要件定義段階における留意事項

開発段階における留意事項

保守・運用段階における留意事項

障害対応に関する留意事項

システムライフサイクルプロセス全体における横断的な留意事項

開発手法・ツールの活用及びテスト環境の整備

信頼性・安全性向上に向けた技術の活用及び留意事項

人材育成・教育の実施

組織の整備

契約における重要事項の明確化

情報システム構築の分業時の役割分担及び責任関係の明確化

着実な契約履行

基準点/満点

得点/満点

信頼性自己診断ツールによる診断結果

SECセミナー (2015-07-01)

各質問（８３項目）の得点状況（Ａ）重要インフラ等システム他に代替することが著しく困難なサービスを提供する事業が形成する国民生活・社会経済活動の基盤であり、その機能が低下又は利用不可能な状態に陥った場合に、我が国の国民生活・社会経済活動に多大の影響を及ぼすおそれが生じるもの、人命に影響を及ぼすもの及びそれに準ずるもの。（Ｂ）企業基幹システム企業活動の基盤であり、その機能が低下又は利用不可能な状態に陥った場合に、当該企業活動に多大の影響を及ぼすおそれが生じるとともに、取引先や顧客等、相当程度の外部利用者にも影響を及ぼすもの。（Ｃ）その他のシステム

重要インフラ等システム及び企業基幹システム未満の水準のもの。

項目群対応の得点状況（得点率）

0

2

4

6

8

10

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

Q10

Q11

Q12

Q13

Q14

Q15

Q16

Q17

Q18

Q19

Q20

Q21

Q22

Q23

Q24

Q25

Q26

Q27

Q28

Q29

Q30

Q31

Q32

Q33

Q34

Q35

Q36

Q37

Q38

Q39

Q40

Q41

Q42

Q43

Q44

Q45

Q46

Q47

Q48

Q49

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

得点

基準点

診断結果に基づき，基準点を下回る項目について，強化施策を講ずる．

システムタイプ


講演内容

SECセミナー (2015-07-01)



(0) 見える化









SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

Software Engineering Center 26

定量的な品質管理

品質目標値

時間

信頼性要求水準

プロジェクト特性で補正

適切な指標で状況を“見える化・測る化”

目標値達成に向けてコントロール品

質

2010-01-30 Copyright © 2009-2010 IPA, All Rights Reserved

SECセミナー (2015-07-01)

http://www.ipa.go.jp/sec/softwareengineering/std/ent01-b.html

(2)1定量データ活用_100130.ppt


(2)2定量的品質管理_100130.ppt


定量的品質管理の概念

システム化構想の立案

ソフトウェア要件定義・・・

ソフトウェア要件レビュー

業務及びシステム移行・・・

成果物作成タスクへの差し戻し

再レビュー

開発プロセス標準プロセス改善、③に対する①②の関連性分析

次回以降のプロジェクトに反映

ソフトウェア開発プロジェクト

①タスク実施前 ②タスク実施後 ③プロジェクト完了後

ソフトウェア要求レビューに着目した場合

定量データ(*)に基づく判断

レビュー作業実施率

(*) 例：

SECセミナー (2015-07-01)


品質の測定と予測の枠組み

(注）測定、対策はそれぞれの工程で実施される。

蓄積データ人の作業

データの受渡し

作業の流れ

分析・モデル化モデル

【プロジェクト】【プロジェクト】

《プロジェクト生産活動》

要件定義

基本設計

詳細設計

製作総合テスト

結合テスト

【プロジェクト】データ

計画（P) 対策（A)

ベースライン，モデルの改善・見直し

単体テスト

データ蓄積

測定（D) 分析･予測（C)

《プロジェクトマネジメント活動》

SECセミナー (2015-07-01)


対象工程測定量単位測定方法

全工程規模 FP

LOC

Function Point (FP) では測定方法、LOCは測定ルールを明確にする

作業工数人時

設計工程レビュー回数回数

レビュー時間人時 Σ 各レビューアのレビュー実施時間

レビュー対象規模ページ数レビュー対象ドキュメント量（A４換算ページ数）

レビュー指摘件数件数レビュー記録票の指摘事項数

テスト工程欠陥数件数障害連絡票の欠陥数

テスト項目数項目数テスト仕様書の項目数

基本測定量

導出測定量

対象工程測定量単位算出方法

設計工程レビュー指摘密度件数÷FP，LOC

件数÷ページ数

レビュー指摘件数÷規模

レビュー指摘件数÷レビュー対象規模

レビュー工数密度人時÷FP，LOC

人時÷ページ数

レビュー時間÷規模

レビュー時間÷レビュー対象規模

レビュー指摘効率人時÷件数レビュー指摘件数÷レビュー工数

テスト工程欠陥密度件数÷FP，LOC 欠陥数÷規模

テスト密度項目数÷FP，LOC テスト項目÷規模

品質改善の立案には、属性情報も必要です

代表的な基本測定量と導出測定量

SECセミナー (2015-07-01)


定量データ活用（品質予測）

分析名称（モデル名）

概要

管理図分析（閾値モデル）

データの分布がUCLとLCLに対してどの位置にプロットされるかを見て、データが正常値であるか外れ値であるかを判断する分析方法

ゾーン分析（ゾーンモデル）

与えられた分析のテーマを、ある特徴に着目した視点によってゾーンに分割し、各ゾーン毎に分析を行う

曲線近似分析

（関数モデル）

二つのデータ列の関係を回帰式と呼ぶ近似曲線で代替することで分析を行う

トレンド分析（トレンドモデル）

過去のプロジェクトの実績データの時間的なパターンと、現在のプロジェクトの実績データのトレンドを比較し、過去のプロジェクトの最終品質と同等な結果となるかを予測する分析である

チェックリスト分析

（チェックリスト）

チェックリストは、与えられたテーマに対してチェックする項目をリストにしたものである

分析一覧

UCL

LCL

品質不良と予測

レビュー指摘密度

ゾーン4ゾーン3ゾーン9



尺　度

尺

度

単体テスト結合テスト総合テスト

検出欠陥密度

UCL

CL

LCL

Xプロジェクト

Yプロジェクト

要求分析のレビュー指摘チェックリスト

大分類小分類レビュー指摘事項評価重みﾎﾟｲﾝﾄ備考

全体網羅性記載内容の範囲についての記述があり、明確か ○ Ａ 1.2

要求の網羅性について記載があるか ○ Ｂ 1.0

要求に漏れがないかの確認をしているか × Ａ 0.0

整合性内容に矛盾がないか ○ Ａ 1.2

要求の粒度は揃っているか × Ｂ 0.0

了解性主語が明確であるか ○ Ｃ 0.8

事実と推測が分離しているか ○ Ｂ 1.0

数値表現できるところは数値で表現しているか ○ Ａ 1.2

※ 評価（○：1､×：0）､重み（A：1.2､B：1.0､C：0.8） 6.4

近似曲線二つの要因を回帰式で分析

① ここの値から

②ここの値を予測する

管理図分析

曲線近似分析

ゾーン分析


トレンド分析

SECセミナー (2015-07-01)


管理図分析の例

管理図分析閾値モデル

概要ある尺度の閾値によって分類するモデル

ＵＣＬ（上部管理限界線ＵｐｐｅｒＣｏｎｔｒｏｌＬｉｍｉｔ）

ＬＣＬ（下部管理限界線ＬｏｗｅｒＣｏｎｔｒｏｌＬｉｍｉｔ）

管理図分析

データの分布がＵＣＬとＬＣＬに対して、どの位置にあるかで、データが正常値であるか外れ値であるかを判定する

UCL

LCL

品質不良と予測

レビュー指摘密度

SECセミナー (2015-07-01)


ゾーンモデルの例

⑧

⑦適切な範囲

① ②

⑤ ⑥

⑨ ③ ④

テスト密度

欠陥密度

欠陥密度の標準

テスト密度の標準

●

●

下限

下限

上限

上限

ゾーン評価品質

第2ゾーンテスト効率がやや悪、テスト内容点検低←点検順位→高

第3ゾーンテスト内容が適切か点検

第4ゾーンテスト効率がやや悪、テスト内容点検

第5ゾーン

第1ゾーン一応品質は良好、テスト効率も計画通り。良

前工程の品質確保不足、内容点検

第6ゾーン前工程の品質確保不足、内容点検

第7ゾーンテスト不足、前工程の品質確保不足、内容点検

第8ゾーンテスト不足、前工程の品質確保不足、内容点検

第9ゾーンテスト不足、内容点検

SECセミナー (2015-07-01)


関数モデルの例

対象フェーズ：総合テストグラフ作成日：2006/2/15

テスト開始日：2006/1/15テスト終了日：2006/3/31

総障害数：456 件総障害修正数：253 件

障害推定結果推定障害数 : 550.0 件95%到達時点 : 1.6 週目

信頼度成長モデル

2006

/1/1

2006

/1/8

2006

/1/15

2006

/1/22

2006

/1/29

2006

/2/5

2006

/2/12

2006

/2/19

2006

/2/26

2006

/3/5

2006

/3/12

2006

/3/19

2006

/3/26

2006

/4/2

0

100

200

300

400

500

600

累積障害件数

累積障害件数推定障害件数

テストの進捗

累積欠陥数

①

②

③

④

SECセミナー (2015-07-01)


0

2

4

6

8

10

12

プログラム試験ソフトウェア試験システム試験

フェーズ

件/K

L

期待値

上限値

下限値

成功

0

2

4

6

8

10

12

プログラム試験ソフトウェア試験システム試験

フェーズ

件/K

L

期待値

上限値

下限値

単体テスト結合テスト総合テスト単体テスト結合テスト総合テスト

テストにおける欠陥密度の例

時系列に減少

バラツキ小さい

結合テストで増加

バラツキ大きい

総合テストでの検出率高い

試験フェーズにおける計画達成と未達成プロジェクトを調査したところ、誤り検出率やヒット率に顕著な傾向

失敗

トレンドモデルの例

SECセミナー (2015-07-01)


チェックリスト

概要有識者のノウハウを予めリスト化するモデル


チェックリストは与えられたテーマに対しチェックする項目をリスト化し、

重み付けをして分析を行う

要求分析のレビュー指摘チェックリスト

大分類小分類レビュー指摘事項評価重みﾎﾟｲﾝﾄ備考

全体網羅性記載内容の範囲についての記述があり、明確か ○ Ａ 1.2

要求の網羅性について記載があるか ○ Ｂ 1.0

要求に漏れがないかの確認をしているか × Ａ 0.0

整合性内容に矛盾がないか ○ Ａ 1.2

要求の粒度は揃っているか × Ｂ 0.0

了解性主語が明確であるか ○ Ｃ 0.8

事実と推測が分離しているか ○ Ｂ 1.0

数値表現できるところは数値で表現しているか ○ Ａ 1.2

※ 評価（○：1､×：0）､重み（A：1.2､B：1.0､C：0.8） 6.4

チェックリストの例

SECセミナー (2015-07-01)


講演内容

SECセミナー (2015-07-01)



(0) 見える化







講演-2が関連


(5) 定量的プロジェクト診断ツール

SECセミナー (2015-07-01)

プロジェクト管理プラットフォーム(Redmine,Trac,Subversion,GIT)

プロジェクト管理支援機能

データ収集・集計起動

定量的分析・診断呼出

設定管理機能

BIツール (Eclipse BIRT/BIRT Report Viewer)

複数プロジェクト俯瞰表示機能

プロジェクト俯瞰表示機能

個別グラフ表示機能

プロジェクト管理プラットフォーム

チケット

ETLツール (Pentaho)

データ収集機能

データ集計機能

グラフ表示データ

定量データ

http://www.ipa.go.jp/sec/softwareengineering/tool/ipf/index.html


定量的プロジェクト管理ツール・ソース規模の推移・工程別の障害件数・不良発生原因、発生箇所・計画値との比較による進捗

定量的データ

システムの

の取得

版管理（ソースコード）

課題管理（障害・課題）

進捗管理（計画と実績）

ソースを

課題や進捗を

課題の把握・

プロジェクトの進捗を

課題の把握・

将来進捗を

の作成

プロジェクト

計画値の

対策

診断計画

実施

KKD（勘，経験，度胸）から，ツールによるに基づいたプロジェクト管理へ

定量的プロジェクト管理の業務

SECセミナー (2015-07-01)

発注者

ダッシュボード等


定量的プロジェクト管理ツール(EPM-X)

SECセミナー (2015-07-01)

プロジェクト・タスクの進捗，課題・障害の解決状況，工数等の把握を定量的データにより行い、中小規模プロジェクトにおいて

するツール

複数プロジェクト俯瞰

タスク障害・課題

要員負荷管理

障害・課題管理タスク・品質管理

工数

進捗収集

可視化

定量的プロジェクト管理ツールプロジェクトの可視化・グラフ化

定量的データの収集集計


表示グラフ一覧

SECセミナー (2015-07-01)

WBS（タスク）・品質管理試験計画項目密度、 WBS進捗推移、WBS進捗変化、EVM評価（進捗、工数）、ソフトウェア規模推移、試験進捗率、工数の予実、遅延重要タスク抽出

障害・課題管理障害件数変化、障害解決予測、障害原因分析、障害発生密度、障害滞留状況、長期未解決課題抽出

要員負荷管理負荷状況

プロジェクトを俯瞰するグラフ定量管理ダッシュボード

複数のグラフを縮小表示して、プロジェクト状況を俯瞰

複数プロジェクトを俯瞰するグラフ複数プロジェクトの進捗確認、健全性確認


WBS（タスク）管理のグラフの例

SECセミナー (2015-07-01)

WBS進捗推移過去の進捗の進み具合を描画し、開発の進み具合を把握する

WBS進捗変化最近の開発進行度（変化分の大きさ）を確認する


品質管理のグラフの例

SECセミナー (2015-07-01)

EVM評価 EVMにより最近の開発価値とコストを把握する

ソフトウェア規模推移ソース行数による規模の推移、及び計画値との対比を行う


障害・課題管理のグラフの例

SECセミナー (2015-07-01)

障害件数変化課題の件数、未解決数の推移、計画値との対比を把握する

障害解決予測課題の未解決数と解決生産性から、解決完了日を推定する


負荷管理のグラフの例

SECセミナー (2015-07-01)

負荷状況開発グループ／開発者の負荷を把握する


講演内容

SECセミナー (2015-07-01)



(0) 見える化









SECセミナー (2015-07-01)

http://www.ipa.go.jp/sec/softwareengineering/std/ent01-a.html




プロジェクト管理におけるベンチマーキング手法の利用

SECセミナー (2015-07-01)

定量プロジェクト管理の発展形

各プロジェクトが測定しているデータを集積し，蓄積・一元管理

実績データを誰もが容易に活用できるよう，データ抽出・分析等の活用手段を提供

過去の実績を随時参照

進捗会議などでの報告（定型化した情報中心）

プロジェクト計測者

プロジェクトの測定

特定プロジェクト内での

情報共有

プロジェクト管理者など

組織大でのデータの収集・蓄積

リポジトリ（組織大での

情報共有）

リポジトリ管理者

データ管理，分析・表示ツール群

ベンチマーキング（随時,自由な切り口で分析）


ソフトウェア開発プロジェクトのデータ収集・分析

ソフトウェア開発プロジェクトのデータを企業の協力により収集

分析を加えた上で取りまとめ「ソフトウェア開発データ白書」として公開→ 世の中の傾向を把握し，施策に反映

→ 自プロジェクトのベンチマーキングにより，開発管理にフィードバック

データ白書2005 データ白書2014-2015

上：収録プロジェクト数下：データ提供企業数

3541

29

companies

3089

27

companies

2327

22

companies

1774

20

companies

942

15

companies

1418

19

companies

2056

20

companies

2584

23

companies

SECセミナー (2015-07-01)


国際標準に準拠した「ベンチマーキング」の仕組み

ベンチマーキング経験データベース

登録/参照する

リポジトリを管理する

ベンチマーク(参照値)を作成する

道具立てを整える

データを提供する

プロジェクトを測定する

ベンチマーキングを実施する

ベンチマーキングの結果を活用する

ツール

手法

手引き

プロジェクトの測定値

組織外のリポジトリ

取り込む

提供する

登録/参照する

取り出す

抽出する

データを登録･管理する

参照する

報告する

参照する

利用/参照する

参照する

選択する

支援活動ベンチマーキングの中核活動ベンチマーキングを支援する道具

ベンチマーキングに利用される情報

組織外から参照する情報

組織外のベンチマーク

提供する

ベンチマーク(組織で共有されている参照値)

利用/参照する

提供する

ベンチマーキングリポジトリ

(蓄積データ)

① ④

②

③

<IPA/SECの取組みとの対応>

① データの収集・蓄積と機密室でのセキュアな管理

② データ白書の出版，大学との共同研究，等

③ プロジェクト診断ツール，データ活用ガイド，等

④ データ測定・提供支援ツール

国際標準（ISO/IEC 29155-1）に基づく

次の国際規格中の図に加筆：ISO/IEC 29155-1

Systems and software engineering -- Information technology project performance benchmarking framework -- Part 1: Concepts and definitions

SECセミナー (2015-07-01)


分析例：規模に関する計画値と実績値の対比

SECセミナー (2015-07-01)

0

200

400

600

800

0 200 400 600 800

規模の計画値［KSLOC］

実績

値［K

SLOC］

a：新規開発

b：改修・保守

c：再開発

d：拡張

N=240

ソフトウェア開発データ白書2010-2011より


分析結果の活用例：開発条件の検討(1/2)

SECセミナー (2015-07-01)

赤▲：当初案

緑▲：計画変更提案

規模と工数の軸反転工数と工期

利用イメージ・事例想定シーン：計画局面における開発条件の検討。

定量データの利用目的：システム開発における、規模、工数、工期からの適切な計画案の策定。

見方・使い方：


分析結果の活用例：開発条件の検討(2/2)

SECセミナー (2015-07-01)

(1)図表から認識できること・想定工数に対し工期が信頼幅線下位50％以下と相対的に短くリスクが高い。

・しかし規模は反転した信頼幅線の右50％の近傍で、相対的に工数は多め（低生産性）である。

(2)利用・想定事例ケース１：発注側の要件として工期を優先する場合、開発規模を小さくする

ため機能を削減するか、または分割開発により工期をずらし、機能毎の優先度と必要時期を協議する。

ケース２：発注側が工期に拘らない場合、コストを守ることを前提に、工期を50％信頼幅の中央部近傍の12～14ヵ月を提案する。

ケース３：開発対象機能(規模)を優先する場合、工期を12～14ヵ月で提案すると共に、工数を50％信頼幅の中央部近傍の80,000人時を提案する。（図中の緑▲位置）


■組織の生産性・信頼性マネジメント関連の活用シーン主な活用者：開発ベンダのPMO、品質マネジメント推進部門等

◇生産性・信頼性向上のための組織の重点強化領域の特定

生産性・信頼性の向上に向け、重点的に強化すると効果的な領域を特定し、適切な方策を立てる→自組織の生産性・信頼性の変動要因群を把握し、それらに着目して

方策を立てることが、一つの重要かつ効果的なアプローチ

＜例＞『上流工程での不具合摘出比率の高い方が信頼性が高い』という傾向が見られるのであれば、上流工程での不具合摘出比率を高める具体策を検討することが望ましい。

新しい分析の試行（１）

変動要因分析

SECセミナー (2015-07-01)


・・・

開発プロセス設計文書化密度

テスト密度

Q,C,D要求ユーザの協力度合い

プロファイル開発環境組織の成熟度

信頼性要求レベル

開発期間

発注仕様の確定時期

レビュー・承認の実施時期・・・

レビュー工数密度

上流工程での不具合摘出比率

・・・

CMMIレベル

品質保証体制

・・・

開発規模

新規／改良

・・・

ソフトウェア資産の整備度

・・・要員のスキルレベル

業種、ｼｽﾃﾑ種別

要件定義へのユーザ参加度合い

・・・

変動

生産性

信頼性

システムリスク

変動要因群のイメージ例 ★様々なエリアの変動要因が考えられる変動要因群には依存関係もある（必ずしも独立ではない）。

結果指標

組織改善へのフィードバック

★変動要因に対応する領域を重点的に強化することが、効果的な施策の一つ。また、組織の標準類の見直しに繋げることが望ましい。

新しい分析の試行（２）

SECセミナー (2015-07-01)

58Copyright © 2009-2015 IPA, All Rights Reserved Software Reliability Enhancement CenterSECセミナー (2015-07-01)

参考

新しい分析の試行（３）

0

100

200

300

400

500

600

700

設計文書化密度が低い設計文書化密度が高い

設計文書化密度

KSLOC当りの実績工数（開発5工程）（人時）

設計文書化密度と生産性

中央値で1.60倍の差


参考

新しい分析の試行（４）

0

100

200

300

400

500

600

設計レビュー工数密度が低い設計レビュー工数密度が高い

設計レビュー工数密度


設計レビュー工数密度と生産性



参考

新しい分析の試行（５）

0

100

200

300

400

500

600

700

800

テスト密度が低いテスト密度が高いテスト密度


テスト密度と生産性



0

100

200

300

400

500

600

700

全体 F：製造業 H：情報通信業 J：卸売・小売業 K：金融・保険業 R：公務

業種

（人時／KSLOC） KSLOC当りの実績工数（開発5工程）（新規開発）

SECセミナー (2015-07-01)

参考

新しい分析の試行（６）

生産性高

製造業は他業種よりKSLOC当り工数が少ない傾向が見られる。情報通信業は他業種よりKSLOC当り工数が多い傾向が見られる。金融・保険業は他業種よりKSLOC当り工数が多い傾向が見られる。

生産性の業種間比較


参考

新しい分析の試行（７）

0.00

0.05

0.10

0.15

0.20

0.25

全体 F：製造業 H：情報通信業 J：卸売・小売業 K：金融・保険業 R：公務

発生不具合密度

（件/KSLOC）

業種

業種別発生不具合密度（新規開発）

信頼性高

製造業は他業種より発生不具合密度が高い傾向が見られる。金融・保険業は他業種より発生不具合密度が低い傾向が見られる。

信頼性の業種間比較


(6’) 組込みソフトウェア開発データ白書

SECセミナー (2015-07-01)


組込みソフトウェア開発の推移とIPA/SECの役割

SEC設立当初（10年前）

業界が未成熟

• プロジェクトの定量的管理の土台が固まっていない

• 実のところ定量的管理が出来ていない

SECの役割は、ソフトウェアエンジニアリング手法の普及

• 先進企業のベストプラクティスを収集・整備

• 開発現場への導入推進

そして現在

定量データによる開発の基礎となる開発プロセスの導入が進んでいる

組込みデータ白書公開への期待が高まっている

SECセミナー (2015-07-01)


これまでの取組み

2013年度「製品・制御システム定量データ収集・分析WG」立ち上げ

プロジェクトデータ提供していただける企業訪問、データ受領

分析試行。組込み分野特有の傾向を確認：生産性、バグ密度

2014 年７月

ET-West2014にてプレス発表“発行宣言とデータ提供企業募集”

2015 年5月

データ提供企業向け「組込みソフトウェア開発データ白書」発行

2015 年11月

一般向け「組込みソフトウェア開発データ白書」公開予定

と今後の予定

SECセミナー (2015-07-01)


２年間の活動で分ったこと

この2年間の活動で10社174件のプロジェクトデータの提供を受けた。

分析の結果、信頼性・生産性のための定量的な指標や、定性的な傾向が見えてきた。

データ提供企業向けの分析結果が興味深かったため、継続してのデータ提供に非常に協力的。

多様なドメインが存在する組込み分野から、データ収集・分析したところで、意味ある指標（生産性や信頼性に関する指標）が導けるのか？

組込みの分野で真面目に定量管理している企業は少なく、データ提供されないのでは？そもそも、組込みの分野の開発の大半は、プロセス定義さえ無いのが実態ではないか？

2年前

1年目に6社がデータ提供。2年目には更に4社が参加し10社からデータ提供を受けた。定量管理が定着している企業は、要求以上の多くのデータを提供。定量管理の仕組みが未整備の企業も、現場を説得して、出来る限りのデータを提供。

2年経過した現在

SECセミナー (2015-07-01)


組込み分野のベンチマーキングの課題と工夫

組込み分野でベンチマーキングを可能にするための課題

多種多様なドメイン

組込み分野の製品や機器は使用される環境が様々

ソフトウェアを実行させるプラットフォームも様々

「収集・分析の仕方を工夫」製品分野共通の特性による分類と層別分析

リアルタイム性の度合い、大小

自然環境からの影響度合い、大小

ユーザの多様性の度合い、大小

ネットワーク接続の有無

稼働の形態（非停止、オンデマンド）SECセミナー (2015-07-01)


収集データ項目

開発プロジェクトの特徴・新規開発/派生開発、・新技術を利用する開発か否か

システム特性・製品の特性、・（市販）パッケージ利用の有無、・CPUアーキテクチャ、・OSアーキテクチャ、・開発対象プラットフォーム、・開発言語

開発の進め方・開発ライフサイクルモデル、・類似プロジェクトの参照の有無、

・ツールの利用有無

製品に強く要求される特性・信頼性、・使用性、・性能・効率性、・保守性、・移植性、・

セキュリティ

開発要員の経験とスキルの習熟度

規模

工期

工数・人月、・人時、・人月の時間数

開発体制・外部委託工数比率

実施工程のパターン

品質・検出バグ現象数、・検出バグ原因数、・品質保証の体制有無、・品質基準の有無、・レビューの有無、・テスト計画書の有無、・テスト計画書レビューの有無

プロジェクト評価（品質、納期、コスト）

SECセミナー (2015-07-01)


収集データの紹介（１）

2015年度版では、主に改良開発、派生開発のプロジェクトデータを分析する。

SECセミナー (2015-07-01)


収集データの紹介（２）

注）第２回答、第３回答は複数言語を使っている場合の回答

2015年度版では、主にC及びC++言語のプロジェクトデータを分析する。

SECセミナー (2015-07-01)


収集データの紹介（３）

N P25 中央値 P75SLOC規模 173 2.4 6.1 24

SLOC規模(母体含む)

173 61 249 511

収集データのSLOC規模

[単位：KSLOC]

2015年度版プロジェクトデータのSLOC規模は大半が、２.４K～２４KSLOC（中央値6.1K）

母体を含むSLOC規模は大半が、６１K～５１１KSLOC（中央値２４９K)

SECセミナー (2015-07-01)


分析項目

工数と工期の関係

規模と工数の関係（１）言語別

規模と発生不具合数、密度の関係（１）結合試験、（２）総合試験

工程別の工期・工数比率

規模あたりのテストケース数（１）結合試験、（２）総合試験

規模あたりのテスト工数（１）開発規模、（２）母体を含む開発規模

規模とSLOC生産性の関係（１）製品の特性別、（２）流用率別

分析対象・改良開発／派生開発

・C言語／C++言語

層別化項目・製品の特性別

・流用率別

SECセミナー (2015-07-01)


相関係数： C++ R=0.70

0

5,000

10,000

15,000

20,000

25,000

30,000

35,000

40,000

0 10,000 20,000 30,000 40,000 50,000 60,000 70,000

実績

工数

【人

時】

SLOC実績値【SLOC】

主開発言語別の分類と

SLOC規模と工数（改良派生開発）ｂ：言語C

ｃ：言語C++

N=44

◆ 言語C□ 言語C++

開発規模（プログラム行数）

実績

工数

（人時

）

主開発言語別の分類と開発規模と工数（派生開発）

AB

SECセミナー (2015-07-01)

・言語による生産性の違いＡの部分をみると、C++言語の方がC言語よりも生産性が高いことがうかがえるが、母数が少ないため、今後、もっと多くのデータを収集して調べる必要がある。

一方、Ｂの部分をみると、開発規模が小さいところでは、開発言語に関わらず生産性にばらつきがあることがうかがえる。

データ提供企業の募集により、さらに多くのデータを収集し、分析を進める必要がある。

73

参考

分析結果の例（１）「開発規模と工数の関係」


図２-１「開発規模とバグ密度の関係」（結合テスト）

0

1

2

3

4

5

6

7

8

0 10 20 30 40 50 60 70 80

総合

テス

ト検

出バ

グ密

度【件/KSLOC】

SLOC実績値【KSLOC】

SLOC規模と結合テスト検出バグ密度

（改良派生開発）

N=59N=57


結合

テス

ト検

出バ

グ密

度（件

／KSLOC)

開発規模と結合テスト検出バグ密度（派生開発）

結合テストにおけるバグ密度（単位規模あたりの検出バグ件数）からは、開発規模が小さい部分で、バグ密度にばらつきがあることがうかがえる。

母数が少ないため、さらに多くのデータを収集し、分析を進める必要がある。

SECセミナー (2015-07-01)74

参考

分析結果の例（２）「開発規模とバグ密度の関係」


図２-２「開発規模とバグ密度の関係」（総合テスト）

0

1

2

3

4

5

6

7

8

0 10 20 30 40 50 60 70 80

総合

テス

ト検

出バ

グ密

度【件/KSLOC】

SLOC実績値【KSLOC】

SLOC規模と総合テスト検出バグ密度

（改良派生開発）

N=54N=46


総合

テス

ト検

出バ

グ密

度（件

／KSLOC)

開発規模と総合テスト検出バグ密度（派生開発）

一方、総合テストにおけるバグ密度からは、結合テストに比べて、開発規模に関わらず、バグ密度が0に集中していることがうかがえる。これらの傾向から、総合テストは、バグが無いことを確認するために行われていることがうかがえるが、母数が少ないため、データ提供企業の募集により、さらに多くのデータを収集し、分析を進める必要がある。

SECセミナー (2015-07-01)75

参考

分析結果の例（３）「開発規模とバグ密度の関係」


組込み産業界のみなさまへ

IoT時代に向けて、

定量データに基づくマネジメントを

組込み業界全体で進めていきませんか！

（１）現在進行中プロジェクトを的確にマネジメントするため

⇒プロジェクトの状況（品質・進捗）を共通のモノサシで測ること（２）将来のプロジェクトが有効に活用できるプロジェクト資産を残すため

⇒プロファイル情報、工数情報等を含めたプロジェクトデータを収集・管理すること

定量的管理とは

◇ＩｏＴの時代に向かっています。組込み業界は当然巻き込まれていき、もっと高機能なソフトウェアが必要になり、大規模・複雑化していきます。

SECセミナー (2015-07-01)76


http://www.ipa.go.jp/sec/index.html

ご清聴，ありがとうございました

アンケートへのご協力をよろしくお願いいたします．

SECセミナー (2015-07-01)

Documents

セミナー「定量的なプロジェクト管理・プログラム管理の ... · 2019-04-01 · プロジェクトの不十分な状態を把握するための定性的・定量的な「見え