Software Engineering Center - IPA ·...

Information-technology Promotion Agency, Japan

Software Engineering Center

Software Engineering Center Copyright© 2012 Information-technology Promotion Agency, Japan. All rights reserved.

第２回ＩＴＣ近畿会セミナー「ＩＰＡ共催セミナー」 2012年08月25日

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

技術本部ソフトウェア・エンジニアリング・センター

見える化と定量的プロジェクト管理ツール

研究員大和田裕

SEC Software Engineering for Mo･No･Zu･Ku･Ri

1 Software Engineering Center 第２回ＩＴＣ近畿会セミナー「ＩＰＡ共催セミナー」 2012年08月25日 Copyright© 2012 ＩＰＡ, All rights reserved.

ITプロジェクトの「見える化」



ＳＥＣが提供する定量関連のコンテンツ・ツール群

データ提供企業

データ登録

データ出力

開発5工程の工数と工期　(新規開発)　N=185

0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200,000 250,000 300,000

実績工数（開発5工程） [人時]

実績

月数

(開発

5工程

) [月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200,000 250,000 300,000


実績

月数

(開発

5工程

) [月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200,000 250,000 300,000


実績

月数

(開発

5工程

) [月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC

簡易分析自社蓄積

データ

■スタンドアロン型診断支援ツール

■プロジェクト診断支援ツール（IPA/SECWebサイト）


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200,000 250,000 300,000


実績

月数

(開発

5工

程)

[月]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC

・データ白書のグラフと自社のデータをWEB上で重ねて表示可能

プロジェクト診断（外部データとの対比）

■SECBOOKS

一般利用者（企業）

・白書の収集項目枠と代表的な分析グラフを用意したEXCELツール

プロジェクト診断（自社デ―タ）

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

ソース規模、WBS,工数等

収集

ソース管理、障害管理、工数管理

自社蓄積

データ

0

500

1000

1500

2000

2500

3000

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

ソー

ス規

模（行

数）

ソースコード規模推移

モジュールA モジュールB モジュールC

モジュールD 全体規模想定到達規模

規模計画値 4W平均生産性(右目盛)

計画値

開発終了

遅れ予測

■利用目的別メトリクス一覧表

IPA/SEC

定量データ

SEC蓄積データ

機密室

分析・文書化

ツール化

品質管理ノウハウ

マネジメントノウハウ

ベンチマーク

ノウハウ等参照

メトリクス情報提供

プロジェクト管理（自社デ―タ）

基本的な定量データ（規模、工数、工期）を自動収集・集計し、分析・管理する機能と、分析データをグラフ表示により視覚的に示す機能を備えたツール。Redmine、Trac等で構成



ITプロジェクトの実状

インフラ基盤としての高信頼性の要求

要求の多様化・高度化リスクの増大

開発の多様化・高機能化開発の短期間化・低コスト化

市場競争の激化ビジネスモデルの革新

法対応・リスク対策などの社会的要請

信頼できるマネジメント

品質確保トラブル未然抑止効果的な

進捗・障害管理

レポーティング

高難易度となったプロジェクト・マネジメント作業を支援するが必要



ＩＴプロジェクトの見える化

「期限どおり」に、「所定の費用」で、「求められる品質」のソフトウェア開発を行うには、様々な問題を早期に発見し解決

していくためにＩＴプロジェクトのが必要

一歩進んだ

プロジェクト

マネジメント



Ｖ字モデル

「見える化」が対象とする工程

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

保守

運用

見える化



上流工程

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

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

易ではない

問題認識

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

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

課題

要件定義

システム設計

ソフトウェア設計

プログラミング

ソフトウェアテスト

システムテスト

運用テスト



中流工程

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

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

問題認識

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

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

課題

要件定義

システム設計





運用テスト



下流工程

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

問題認識

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

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

課題

要件定義

システム設計





運用テスト



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

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

事例集

チェックシート（自己評価シート／

ヒアリングシート）俯瞰図

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

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

測定項目リスト

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

測定分析データ一覧表

ベース尺度一覧表

支援ツール

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

実践の場プロジェクト

統合的アプローチ

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

断の仕組み

リスク分類表




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



俯瞰図

経営者発注側

協力会社

マスコミ

発注側の顧客

発注側の株主

営業 GM

PM

担当者

プロジェクトマネージャ

経営者

PM

スタッフ

メンバー

メンバー

営業

受注側

営業

共通

GM

プロジェクト

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

先方キーパーソン。決定権を

持っている

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

「木を見て森を見ず」弊害の排除ドミナント・アイテム※１を継続的、システム横断的に把握

変更が生じたら直ちに修正

上/中/下流：6/7/4例提示

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



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



周辺システム構成俯瞰図の例



システム構成俯瞰図の例



スケジュール俯瞰図の例



要員遷移俯瞰図の例



プロジェクト・マネジメントの要点を再確認客観的視点でのチェックによる見落としの排除リスクの明確化

チェックシート

自己評価とヒアリングレーダチャート

0

1

2

3

4

5統合

スコープ

タイム

コスト

品質

人的資源コミュニケーショ

ンリスク調達顧客

技術

組織

基本動作

モチベーション

課題管理

自己評価

ヒアリング評価

自己評価とヒアリング評価のスコアの乖離

-4

-3

-2

-1

0

1

2

3

4

統合

ス

コー

プ

タイ

ム

コスト

品質

人的資源

コミ

ュニケー

シ

ョン

リ

スク

調達

顧客

技術

組織

基本動作

モチ

ベー

シ

ョン

課題管理

ヒアリング評価-自己評価

P

M

が

悲

観

的

P

M

が

楽

観

的



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

集計・表示ツール付き現場リーダ向け 3段階評価所要時間40分程度

自己評価シート：プロジェクトマネージャによる自己評価（上流：３５、中流：３８、下流：４０項目） ⇒ 自己チェックによる気付き




集計・表示ツール付きベテランが現場リーダから聞き出すエビデンス資料要求 5段階評価所要時間2時間＋

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




自己評価と専門家の診断の差、専門家からの対策案を提示 ⇒ マネジメントの過不足を把握し、対策を検討



上流工程の自己評価シートから（統合）プロジェクト計画書が作成され、レビューされているか？

（顧客）顧客のプロジェクト目的は明確か？

（コミュニケーション）プロジェクト計画書は、全員が見ることができるようになっており、全プロジェクト・メンバーへ展開しているか？

（組織）プロジェクト体制について、顧客も含めたステークホルダの責任分担が明確になっており、体制上の不備不足や不安は無いか？

（タイム）進捗状況を定期的に確認できるようになっているか？

（スコープ）顧客の要件とシステムの機能、性能が一致しているか？

（リスク）リスク分析により、リスク項目を明確にし、対応策まで検討しているか？

（課題管理）課題管理表などで課題が管理されているか？

（コスト）複数視点での見積りを実施するなど、見積りの精度を向上する工夫をしているか？

（品質）品質計画があるか？

（調達）協力会社の作業と成果を定期的に監視する計画がされているか？

（技術）方式要件（負荷・性能・信頼性・安全性・保守／運用・移行）と方式設計結果は妥当か？

（基本動作）基本となる動作（しつけ・作法）が徹底されているか？

（モチベーション）プロジェクト計画に対してメンバーの気持ちがしらけていないか？



上流工程のヒアリングシートから(1/2)

（顧客）RFPなど顧客からの要件として、何を実現したいか分かりやすく記述されているか？また、プロジェクト・メンバーがそれを把握できているか？

（統合）プロジェクトの全体を俯瞰できているか？

（コミュニケーション）開発チーム間（協力会社間）とのコミュニケーションに問題はないか？

（組織）プロジェクトのステークホルダとして位置づけられている各組織の責任・権限は明確になっているか？

（モチベーション）各メンバーは自分の範囲について責任を果たすという意識が希薄でないか？自分が担当する範囲以外について、無関心な対応をしていなしか？

（タイム）実施すべき作業が明確に定義されているか？

（人的資源）各作業に担当が明確に割り当てられているか？ WBSやスケジュール表に担当者の名前が記述されているか？



（品質）本番環境でテストを実施する計画が策定されており、本番環境での確認項目が作成されているか？

（人的資源）求められる業務知識のキーパーソンを獲得できているか？

（スコープ）システムの方向性を定義するような機能範囲と作業範囲の変更について、変更管理手順が明確になっているか？

（リスク）リスク内容についてその内容が明確に記述されているか？

（課題管理）課題管理を実施しており、それらの課題について、顧客との合意が取れているか？

（コスト）システム化の規模見積りを行っているか？その際の見積り根拠を記録してあるか？

（技術）システム実現の基本事項として、方式設計が行われているか？

（基本動作）議事録のほか、各種ドキュメントが正しい日本語で書けているか？

（調達）協力会社を使う場合、協力会社の進捗・品質に関する中間フォロー実施計画が明確になっているか？

上流工程のヒアリングシートから(2/2)



チェック項目の説明事項例

調達に関する項目：協力会社を使う場合、協力会社の進捗・品質に関する中間フォロー実施計画が明確になっているか？

個別のヒアリング要領：請負契約は成果物さえ納入すればよいと考えていないか。請負業者の品質方針・品質管理体制などの具体的な品質管理手順について確認を行ったか。中間時点のチェックを約束・実施しているか。

評価基準：進捗会議の定例化や品質基準の組織化について計画がされており、ステークホルダ間で合意されていること。

エビデンス・確認方法：①進捗管理表、②委託契約書（提出すべき中間成果物などが記述されていることがある）

対策案：協力会社のフォローに関し問題がなければよいが、フォローを行っていない状態である場合は、フォローの計画を立てて、実施する。協力会社との信頼関係が築けている場合は、必要ない。



失敗事例集

※１プロジェクト・マネージャが得られる限りの情報を駆使し、最悪の場合も見極めて、自己責任のもとで選択する

・プロジェクト・マネジメントの問題・要件定義、開発範囲にかかわる問題・システム設計・構築技術にかかわる問題・ステークホルダーにかかわる問題・モチベーションにかかわる問題

問題発生の典型パターン

失敗から学んで失敗を防止リスクを内在させたままでの見切り※１方法捉えるべき兆候

上/中/下流：58/58/77事例



・本来のプロセスに従った行動になっているか

捉えるべき兆候

・契約する前であれば、機能を削減し、予算判明以降に発生する赤字を減額する・契約内容を確認し、プロジェクト単体が最小限の損害で契約を満たす方法を検討する・システム化対象範囲を分割して複数年度の契約にする等戦略的に採算が取れるような交渉を進める

・費用と作業内容については最低限文書で取り交わしておく。作業を実施するに至った経緯についても記録しておき、たとえ後付けでも作業の妥当性を顧客側の新担当者に説得できるようにしておく必要がある・その非公式な約束事が反故になるケースを想定し、そのリカバリ方法が確保できていて、かつリカバリコストへの対策を決めておく事

決められた社内ルールを無視して顧客との契約をせずに開発に着手

対処例本来の見切りの考え方事例における見切り内容

顧客側の担当課長レベルと費用および作業内容について内々に話をつけ仕事をしたが、顧客側の職制が変更になった（前任者は退職）。後任者は前任者から費用や作業内容のことについて全く引継ぎがなかったため今までの作業内容が全く分からず工程が振り出しに戻った。

顧客側担当者が異動になり約束事が反故に！事例番号１

上流工程における見切りの事例

P174




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



測定項目リスト


測定項目ごとの測定方法、分析方法を整理例）要件定義書のレビュー進捗率


測定項目を測定する際のベースとなる定量情報

例）レビュー計画書のレビュー計画回数、計画所要時間、要件定義書のレビュー実施回数、累積時間

プロジェクトの状況を定量的に把握するための測定項目

上/中/下流：78/84/70項目総集編に全工程導出尺度一覧



「見える化」のための測定分析項目(1/2) スコープ：（上流工程、重点測定項目）

測定の目的：要件の総数から、計画時点の規模と比較して要件の規模と変動を把握する。確定していない要件の規模と変動を把握する。

導出尺度：計画時点の要件数。発生要件数の推移。確定要件数の推移。未確定要件数の推移。

未確定要件数＝発生要件数累計－確定要件数累計

タイム：（上流工程）

測定の目的：要件定義作業の進捗を把握し、計画との差異を確認する。

導出尺度：要件定義完成したドキュメントのページ数の推移

コスト：（全工程、重点測定項目）

測定の目的：コストの消化状況を見る。コストが計画を超えていないかを見る。当初計画にない対応をとる場合に、予算内でとれるコストを見る。

導出尺度：予算。使った金額。残っている金額＝予算－使った金額。

品質：（全工程）

測定の目的：［保守性・移植性］要求定義プロセスにおける標準順守の度合いを把握する。標準に準拠する項目数の度合いをもとに評価する。

導出尺度：要件定義プロセスでの標準順守率＝順守している項目数／順守すべき標準項目数

ここでの標準の意味；要件定義レビュー計画書、要件定義書レビュー基準、要件定義フォーマット、要件定義書記入要領。

人的資源：（上流工程）

測定の目的：要件定義工程における体制の強弱を測定する。

導出尺度：要件定義スキル（ITコーディネータ）の保有率＝ITコーディネータ相当のスキル保有者数／要件定義メンバー数

コミュニケーション：（上流工程で準重点測定項目、全工程で計測）

測定の目的：各委託先、部門とのコミュニケーションが取れているか測定。

導出尺度：複数委託先（協力会社）部門の体制。階層数、会社数（部門数）、開発拠点数（チーム毎の作業場所数）、報告書の提出数



「見える化」のための測定分析項目(2/2) リスク：（上流工程で準重点測定項目、中流工程で重点測定項目）

測定の目的：リスク全体をスポットで計測し、トップマネジメントに活用。

導出尺度；重要度、発生確率、緊急度、対応策有無のマトリックス

モチベーション：（上流工程で準重点測定項目、中流工程、下流工程で重点測定項目）

測定の目的：要員毎の予定労働時間に対する労働時間など勤務状況により（極端な労働時間の増加）などモチベーションに影響を与える要因を測定する

導出尺度：要員毎の、労働時間／予定労働時間、残業時間／予定残業時間

組織：（上流工程、重点測定項目）

測定の目的：要件定義書が組織としてレビューされているか測定する。

導出尺度：要件定義書のレビュー達成率＝要件定義書のレビュー実施回数／要件定義書のレビュー計画回数、要件定義書レビューのメンバー参加者数／要件定義書レビューの参加計画者数

課題管理：（上流工程で準重点測定項目、中流工程、下流工程で重点測定項目）

測定の目的：課題発生数、対応数を測定し、課題完了状況を把握する。

導出尺度：課題発生の推移、課題対応数の推移、未解決課題数の推移。

未解決課題数＝課題発生数累計－課題対応累計

技術：（上流工程で計測、中流工程で重点測定項目）

測定の目的：キャパシティ・プランニング実施の有無を測定する。

導出尺度：キャパシティ・プランニング実施の有無

顧客：（上流工程、重点計測項目）

測定の目的：要件定義工程における顧客の要件定義業務経験者率を測定する。

導出尺度：要件定義工程における、顧客の要件定義業務経験者率＝要件定義業務経験者数／顧客の要件定義メンバー数




＜総合的見える化アプローチ＞



リスク分類表

ヒアリングシート、測定分析データ一覧表、事例集を連携

統合的な視点でリスクを洗い出す例）・プロジェクト・マネージャへのヒアリング結果を基に、類似の過去事例を参照してリスクを検討する・ヒアリング結果で悪かった項目に対し、関連する測定分析データを調べ、リスクを定量的に評価する・事例集から現在の状況に類似したプロジェクトを見つけ、ヒアリングシートでプロジェクトの状況を確認する



ヒアリングシート

リスク分類表

事例集No. 知識エリアチェック項目

H28 人的資源求められる業務知識のキーパーソンを

獲得できているか？

知識エリアリスク分類チェックシート測定分析データ一覧事例

事例11 業務経験・業務知識の乏しい要員で要件定義工程を実施

要件定義に必要な要員の人数は確保できたので、プロジェクトをスタートした。担当者に業務知識がなく、要件定義は日を追うごとに遅れていき、成果物の品質もきわめて低いものとなってしまった

人的資源

業務有識者 H28 H2,H6 11,21,43,45,48,54

技術系専門家 H29 H1,H5,H7 11,26,28,34,35,58

PJ内部体制 H13,H14,H15,H17,H30,H66,H69,H70,H71

H3,H4,H8,H9,H10,Ko1,Ko2,Ko3

10,25,26,28,29,31,48

リンク事例6件

ヒアリングから失敗事例へ



ヒアリングから測定データへ


リスク分類表

測定分析データ一覧

No. 知識エリアチェック項目

H28 人的資源求められる業務知識のキーパーソンを

獲得できているか？


H2 人的資源要件定義工程における体制の強弱を測定する。

ＰＭ、ＰＭＯ

要件定義工程における、対象業務分野(小売業とか保険業とか)の経験者率

対象業務分野経験者数/要件定義メンバ数

項目番号

知識エリア（主)

知識エリア（関連）

測定の目的利用者導出尺度

人的資源

業務有識者 H28 H2,H6 11,21,43,45,48,54

技術系専門家 H29 H1,H5,H7 11,26,28,34,35,58

PJ内部体制 H13,H14,H15,H17,H30,H66,H69,H70,H71

H3,H4,H8,H9,H10,Ko1,Ko2,Ko3

10,25,26,28,29,31,48




リスク分類表

事例集

No. 知識エリアチェック項目


事例14 初物プログラム言語での開発で十分な性能が出ない

ユーザ側から、まだ市場に出て日が浅いプログラム言語を使っての開発を指定された。その顧客はそのベンダー側にとっては重要な顧客であったため、どうしても受注したかった。そのプログラム言語での実装を行ったが、十分な性能要件を満たすことができなかった

技術

未経験技術 H74 Te2 14,26,28,31,33,48

標準化検討・・・・・・・・・・・・・・・

システム実現方式検討・・・・・・・・・・・・・・・

移行・パッケージ・・・・・・・・・・・・・・・

H74 技術〔新技術/未経験技術がある場合〕その技術に対する対応策は十分か？

失敗事例からヒアリングへ



http://sec.ipa.go.jp/std/ent01-d_1.html

「見える化」参照ＵＲＬ



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



ＳＥＣが提供する定量関連のコンテンツ・ツール群

データ提供企業

データ登録

データ出力


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200,000 250,000 300,000


実績

月数

(開発

5工程

) [月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200,000 250,000 300,000


実績

月数

(開発

5工程

) [月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200,000 250,000 300,000


実績

月数

(開発

5工程

) [月

]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC

簡易分析自社蓄積

データ

■スタンドアロン型診断支援ツール

■プロジェクト診断支援ツール（IPA/SECWebサイト）


0

5

10

15

20

25

30

35

40

45

50

0 50,000 100,000 150,000 200,000 250,000 300,000


実績

月数

(開発

5工

程)

[月]

y(95%)

y(50%)

y(-50%)

y(-95%)

実績値

Copyright IPA SEC

・データ白書のグラフと自社のデータをWEB上で重ねて表示可能

プロジェクト診断（外部データとの対比）

■SECBOOKS

一般利用者（企業）

・白書の収集項目枠と代表的な分析グラフを用意したEXCELツール

プロジェクト診断（自社デ―タ）

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

ソース規模、WBS,工数等

収集

ソース管理、障害管理、工数管理

自社蓄積

データ

0

500

1000

1500

2000

2500

3000

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

ソー

ス規

模（行

数）

ソースコード規模推移

モジュールA モジュールB モジュールC

モジュールD 全体規模想定到達規模

規模計画値 4W平均生産性(右目盛)

計画値

開発終了

遅れ予測

■利用目的別メトリクス一覧表

IPA/SEC

定量データ

SEC蓄積データ

機密室

分析・文書化

ツール化

品質管理ノウハウ

マネジメントノウハウ

ベンチマーク

ノウハウ等参照

メトリクス情報提供

プロジェクト管理（自社デ―タ）

基本的な定量データ（規模、工数、工期）を自動収集・集計し、分析・管理する機能と、分析データをグラフ表示により視覚的に示す機能を備えたツール。Redmine、Trac等で構成



ITプロジェクトの実状

インフラ基盤としての高信頼性の要求

要求の多様化・高度化リスクの増大

開発の多様化・高機能化開発の短期間化・低コスト化

市場競争の激化ビジネスモデルの革新

法対応・リスク対策などの社会的要請

信頼できるマネジメント

品質確保トラブル未然抑止効果的な

進捗・障害管理

レポーティング

高難易度となったプロジェクト・マネジメント作業を支援するが必要



見える化と定量的プロジェクト管理

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

アプローチ

統合的な「見える化」

開発プロジェクトの「見える化」

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

俯瞰図プロジェクト成否要因の明確化

チェックシート見落としの排除リスクの明確化

失敗事例集失敗から学んで失敗を防止

分類表

測定項目リストプロジェクトの状況を定量的に把握

客観的・網羅的に問題箇所を把握

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

データの自動収集分析・診断



「見える化」すると

実践の場プロジェクト

ベンチマーキングベンチマークデータ

業界の傾向を示す参照値

データ蓄積

基準値参照値

蓄積データからの基準値

品質の予測

定量的プロジェクト管理

定量的プロジェクト管理ツール分析・診断・品質予測予実管理・進捗予測プロジェクト管理

要求分析・設計の品質予測プロダクトの品質予測プロジェクトの品質予測

定量的プロジェクト管理ツールとして公開（4/27）



開発の多様化・短期間化・低コスト化

開発フレームワーク・開発ツールを利用既存アプリケーションの再利用変更／追加部分のみの開発

機能・アプリケーションの分割開発外部発注開発、オフショア開発

定量的なデータに裏付けられた、網羅的・統一的なプロジェクトマネジメントが必要

プロジェクトの状況把握が困難品質がバラつき全体品質管理が困難

問題解決の判断遅延



定量的管理の課題

定量データの自動収集日次業務での定量データの収集を可能に

定量データの収集に工数がかかるため進行中プロジェクトの定量的診断が行えない

統計グラフ描画による、視覚的・直観的な分析・診断

定量データ分析のノウハウが乏しく手間がかかりプロジェクト遅れ予測などを簡単に行えない

プロジェクト管理機能と定量的分析・診断機能を一体で提供 Excel等のデータをインポート

管理するツールの環境が整っていない各プロジェクトで個別のExcelなどを使用

データを蓄積による社内基準値の作成

プロジェクトを定量的に診断するための基準値を持っていない

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



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

定量データ

システムの

の取得

版管理（ソースコード）

課題管理（障害・課題）

進捗管理（計画と実績）

ソースを

課題や進捗を

課題の把握・

プロジェクトの進捗を

課題の把握・

将来進捗を

の作成

プロジェクト

計画値の

対策

診断計画

実施

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

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



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

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

するツール

複数プロジェクト俯瞰

タスク障害・課題

要員負荷管理

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

工数

進捗収集

可視化

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

定量的データの収集集計



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

定量的データの自動収集プロジェクト管理ツール、構成管理ツール

日常使用ツールからの日次業務データの取り込み Excel, MS Project, CSV等からのデータ収集

グラフ表示による視覚的・直観的な分析・診断機能の提供ダッシュボード表示ドリルダウン・ドリルスルー表示利用者によるグラフ・カスタマイズ

ツールが簡易に利用できることを重視基本測定量（規模、工数、工期、品質）に絞って提供

高度で複雑な利用方法は将来の拡張柔軟性・拡張性の確保

利用者による定量データの追加など全環境を導入できる一括インストーラを提供オープンソースとして公開（GPL）

既存ツールを活用 Redmine、Trac、Subversion、GIT、BIRT（BIツール）、Pentaho（ETLツール）



定量的プロジェクト管理ツールの概要図

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

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

データ収集・集計起動

定量的分析・診断呼出

設定管理機能

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

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

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

個別グラフ表示機能

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

チケット

ETLツール (Pentaho)

データ収集機能

データ集計機能

グラフ表示データ

定量データ



稼働環境

サーバ

クライアント

Webアクセス

Web／アプリケーションサーバ(Apache)

サーブレットコンテナ (Tomcat)

Internet Explorer

FireFox

CentOS Ubuntu Linux

Windows Server

Windows7 Professional

Redmine/Trac Subversion/GIT

Pentaho BIRT

Report Viewer PostgreSQL



開発ツール構成管理ツール

チケット駆動型の管理ツール

チケットによるプロジェクト管理

「簡単に参加・利用・操作できる」

「開発者は担当作業・課題のチケットを登録・更新するだけ」

するツール

ＰＭの意思決定をサポート

進捗や品質のメトリクスへ集計

プロジェクト情報の一元管理プロジェクト管理

の問題を機能へ

マネージメント機能の実装

開発・報告作業をサポート



チケットとは

担当者が割り振られ、その作業に「登録」，「担当者割り当て」，「作業中」，「完了」などの状態がある作業 ≒作業指示書・報告書

チケットの利点開発者は、自分に割り当てられているタスクやリスクを明確

に知ることができる開発者は、割り当てられたチケットの必要項目に入力するだ

けなので、作業報告を省力化できる管理者は、進捗やリスクについての収集作業を省力化できる



WBSチケット



チケット入力



障害・課題チケット



チケットの一覧



WBSチケットのガントチャート表示



表示グラフ一覧

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

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

要員負荷管理負荷状況

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

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

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



画面レイアウト

グラフ表示領域

共通機能

ナビゲーション領域 HIDE/SHOWで切替



共通機能

パンくずリスト表示領域

操作バー・パラメータ変更－期間変更、閾値・エクスポート・ファイル出力－PDF,Word, PowerPoint ・印刷



プロジェクトを俯瞰するグラフ

定量管理ダッシュボード担当プロジェクトの全体を俯瞰する



「定量管理ダッシュボード」の例

「遅延重要タスク抽出」の件数が多い。

遅れているタスクの詳細を確認する必要がある。

「遅延重要タスク抽出」のグラフで原因を追究（ダブルクリック）

ユーザＩＤを指定

自分が受け持っているプロジェクトを選択。



WBS（タスク）・品質管理のグラフ(1/4)

試験計画項目密度試験項目のカバレッジを確認する

試験進捗率試験項目がモジュールごとにどの程度消化されているかを示す




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

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



「WBS進捗管理」の例（1/3）

プロジェクトのどの工程が遅れているのかの確認が必要。

WBSタスク：IPF開発プロジェクト表示期間：2012/06/09-08/09 スケール：週

ドリルダウンして、下位タスクのグラフで

原因を追究（ダブルクリック）

プロジェクトの終了予測日が大幅に予定を上回っている。




ダブルクリック

ダブルクリック




ＸＸＸ－２製造タスクが遅れている原因の調査が必要。

ＸＸＸ－２製造が大幅に遅れている。

ＸＸＸ－１製造は予定どおり終了している。




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

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



「ソフトウェア規模推移」の例

プログラム製造は順調に進み予定通り8/30の週に完了。

スケジュールと照らし合わせ計画された工程内かを確認。想定外であれば調査。

WBSタスク：プログラム製造表示期間：2011/8/1-10/31 スケール：週

9/13の週に修正が行われた。障害による修正と想定。




工数の予実開発工数の予実把握を行い、完了時の工数を予想する

遅延重要タスク抽出開発が遅れているWBS（タスク）を抽出する



障害・課題管理のグラフ(1/3)

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

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




障害原因分析現在の障害の数を原因別に分類する

障害発生密度どのモジュールの品質が悪いのか把握する



「障害原因分析」の例（1/2）

未解決は1件のみなので対応は進んでいる。

製造での「コーディングミス」が30件で一番多い。

「試験進捗率」、「障害件数変化」のグラフで状況を確認。

WBSタスク： IPF開発プロジェクト



「障害原因分析」の例（2/2）

プロジェクトへの影響が大きい可能性が高い。詳細の確認が必要。

製造の「設計との不一致」の件数も多い。

「障害タスク一覧表示」で問題タスクを追究（ダブルクリック）

かつ、４件の未解決障害が残っている。




障害滞留状況長期間解決されていない障害を抽出する

長期未解決課題抽出長期間解決されていない課題を抽出する



負荷管理のグラフ

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



複数プロジェクトを俯瞰するグラフ

複数プロジェクトの進捗確認担当プロジェクト／サブプロジェクトで、リスクのあるものを検出する

複数プロジェクトの健全性確認担当プロジェクト／サブプロジェクトのリスクを俯瞰する



http://sec.ipa.go.jp/

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

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

参照ＵＲＬ



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

Software Engineering Center - IPA ·...

Documents

Transcript of Software Engineering Center - IPA ·...