Software Engineering Center - IPASoftware Engineering Center 5 上流工程...

Information-technology Promotion Agency, Japan

Software Engineering Center

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

IPAセミナー in 高松 2012年12月7日

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

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

プロジェクトの【見える化】

研究員大和田裕

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

1 Software Engineering Center IPAセミナー in 高松 2012年12月7日 Copyright© 2012 ＩＰＡ, All rights reserved.

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



ITプロジェクトの実状

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

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

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

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

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

信頼できるマネジメント

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

進捗・障害管理

レポーティング

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



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

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

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

一歩進んだ

プロジェクト

マネジメント



Ｖ字モデル

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

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

保守

運用

見える化



上流工程

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

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

易ではない

問題認識

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

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

課題

要件定義

システム設計

ソフトウェア設計

プログラミング

ソフトウェアテスト

システムテスト

運用テスト



中流工程

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

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

問題認識

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

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

課題

要件定義

システム設計





運用テスト



下流工程

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

問題認識

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

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

課題

要件定義

システム設計





運用テスト



見える化の方向プロジェクトの状態を把握するために、

KKD（勘と経験と度胸）だけではなく、定性的・定量的なアプローチが必要。カリスマプロジェクト・マネジメントの暗黙知を形式知にしていくことで、

プロジェクト・マネジメント力の向上を図る

KKD （暗黙知）

・状況を的確に掴むためのチェック項目の検討・網羅性のある観測すべき項目の検討

・嘘をつかない定量データの収集方法と活用方法の検討

野中郁次郎竹内弘高

「知識創造企業」



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

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

事例集

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

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

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

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

測定項目リスト

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

測定分析データ一覧表

ベース尺度一覧表

支援ツール

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

実践の場プロジェクト

統合的アプローチ

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

断の仕組み

リスク分類表



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

「見える化」参照ＵＲＬ




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



俯瞰図

経営者発注側

協力会社

マスコミ

発注側の顧客

発注側の株主

営業 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時間＋

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



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

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



知識エリアの拡張と知識エリアによる分類

ＰＭＢＯＫ９エリア

拡張知識エリア



失敗事例集

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

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

問題発生の典型パターン

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

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



事例1：異動により約束事が反故に

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

事例における見切り内容：

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

捉えるべき兆候：

顧客側の人事異動情報



事例2：本当のユーザを見誤ってしまう情報システム部門からの要請によるシステム構築であり、情報システム

部門と契約し、開発を進めていた。そのため、顧客内部のユーザ部門と情報システム部門に対立があったようだが、発注者である情報システム部門主導でのシステム仕様を進めていた。いざ実装してユーザー部門での利用が始まると、操作性や仕様に関しての問題が相次ぎ、仕様変更対応に追われ、予定通りの本番稼働が出来なくなった


ユーザ部門からの旧システムに対する問題提示や新システムへの要求等が上がっていたが、あまり議題に取り上げることなく情報システム部門主管で仕様決めを行った。本来はユーザ部門側からも仕様検討者がいるべきではあるが、顧客企業の情報システム部門ということで、特に仕様に関しては問題ないだろうと思っていた


システム機能の話ばかりで業務レベルの検討を実施しようとしない

先方の体制にユーザ部門が入っていない

情報システム部門がユーザ部門との打ち合わせの場を持ちたがらない

ユーザ部門への質問を情報システム部門で制限をかけようとする



事例3 新サービスと非合理的な納期金融機関で創立○○年の記念日に新サービスを開始することが至上課

題だった。新サービスについてはマスコミへの発表もされていたため納期順守が絶対であった。ところが、新サービスということで実現方式も二転三転し、手戻りが発生。カットオーバー前に突貫作業でとりあえず動くレベルの物を納入。しかし、稼働後は突貫作業の影響で品質の問題が多発した


目新しい新サービスということで、実現方式がなかなか決まらなかった。そのため、非機能要件やセキュリティポリシーについてもなかなか決まらず、方式設計が曖昧なままであった。納期まで時間がないこともあって、開発に進めそうなところから着手していかざるを得なかった


マスコミ発表など対外的なセレモニーを優先させるキーパーソン

顧客任せの仕様決め




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



測定項目リスト

測定分析データ一覧表

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

ベース尺度一覧表

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

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

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

上/中/下流：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



上流工程の測定分析データ一覧表（人的資源）

H2

H6



H2

H6



上流工程のベース尺度一覧表（人的資源）

BH002,003,007,008




リスク分類表

事例集

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


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

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

技術

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

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

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

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

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

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



リンク先ヒアリング項目



品質関連の分析からポイントされた中流工程の失敗事例



下流工程のヒアリングシートの例（「品質」の一部）



定量データの必要性



ユーザベンダ

ユーザ・ベンダ間の合意形成

【事業計画】・事業目的・事業領域／規模・投資／回収・事業スケジュール

【プロジェクト計画】・開発目的・スコープ／規模・予算・開発スケジュール

要件

実現性

整合

「やりたいこと」と「できること」の整合が必要だが･･･

・共有しやすい見積り手法がない

・初期の仕様は固めにくく、早期契約時の適切な見積りが困難

・要件決定の遅れ、プロジェクト途中での仕様変更の発生

定量データに裏付けられたマネジメントが必要



ユーザ

ベンダ

定量データの必要性・効用

経営層

業務・情報システム部門組織長・スタッフ

プロジェクト管理者

・IT投資、概略計画の妥当性、実現性の目安

・予算数値、根拠の制御・ベンダからの見積の比較と評価、強み／弱みの認識

・計画策定、目標値の制定、QCDの妥当性評価・予実差異の分析、完了評価、開発能力の評価

経営層

プロジェクトマネージャプロジェクトリーダ

・自社の強み・弱み、生産性などの開発力の認識

・規模、工数、工期、品質の見積り、計画策定、制御・オフショア等、外部委託先評価

PMO 品質保証部門

・定量データベースの構築・自社プロジェクトのベンチマーキング、モニタリング

定量データが十分集まれば・・・こんな活用ができる

ユーザ、ベンダ間の合意形成



組織的活動

組織的な取り組みが必要

現場利用ﾌﾟﾛｼﾞｪｸﾄ計画基本設計詳細設計製作結合ﾃｽﾄ総合ﾃｽﾄ

定量的プロジェクト管理・マネジメント見積り・予測

プロジェクト内データ収集・蓄積

データ利用

組織的データ活用サイクルデータ収集

データ精査・分析

コンテンツ作成

個人やプロジェクト内部で定量データを活用するだけでなく、活用のプロセスを確立し、活用サイクルを組織的に回すことが重要。

FP規模と工数 (新規開発、IFPUGグループ)　信頼幅50%付き

0

50,000

100,000

150,000

200,000

250,000

300,000

0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000

FP実績値(調整前)

実績

工数

(開発

5工

程)

[人時

]

値

y(50%)

y(-50%)

自社蓄積データ（計画と実績）

工期規模工数

生産性品質

【基本指標】組織へのデータ提供

インプロセス

ポストプロセス

見える化



定量化に取り組む際のポイント

やみくもに取り組んでも成果は出にくい。なぜなら…

①主にＱＣＤの観点で目的とすべきこと、つまり

「問題意識と改善の必要性」が明確でなければならない。

②目的実現によって「何が得られるのかを具体的」に示し、

関係者間で理解、共有しておく必要がある。

③定量化活動(プロジェクト)のオーナーを明確にし、その

人が「強い意志を持って推進する」ことが重要である。

④欲張ることなく「コアな問題・課題の解決に絞り込んで」

取り組むべきである。



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



ITプロジェクトの実状

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

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

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

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

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

信頼できるマネジメント

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

進捗・障害管理

レポーティング

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



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

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

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

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

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

問題解決の判断遅延



定量的管理の課題

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

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

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

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

プロジェクト管理機能と定量的分析・診断機能を一体で提供 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



課題管理システムへ(Issue Tracking System) 障害だけでなく、課題や要望に使用

バージョン管理システムとの連携チケットとリビジョンを紐付

Redmine,Tracとは

オープンソースのプロジェクト管理ツール

障害管理システム(Bug Tracking System)として使用バグの情報をチケットで一元管理チケットのステータス遷移で制御終了チケットを履歴として残す

チケット駆動開発へ(Ticket Driven Development) 作業をタスクに分割し、チケットに割り当てる



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

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

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

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

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

するツール

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

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

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

の問題を機能へ

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

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



チケットとは

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

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

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

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



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により最近の開発価値とコストを把握する

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



「EVM評価」の例

計画値(PV)より生産価値(EV) が下回っている。進捗の遅延が発生している。

コスト実績値(AC)が計画値(PV) を上回っている。コスト超過になっている。

製造2週目で遅れ始めているので、遅延要因の調査・分析が必要。

WBSタスク：プログラム製造表示期間：2011/10/18-12/6 生産価値：工数スケール：週

プログラム製造の工程完了は 1週間遅れる見込み。

ドリルダウンして、プログラム製造の下位

タスクのグラフで原因を追究（ダブルクリック）



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

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

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

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

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




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

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



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

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

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




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

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



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

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

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

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

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



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

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

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

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

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




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

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



負荷管理のグラフ

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



「負荷状況」の例

業務Bグループの中に閾値を超えている要員がいる。詳細の確認が必要。

業務Bグループの負荷が高い。

表示期間：2011/10/1-10/31 時間閾値：150時間表示種別：グループ

下位グループ／要員の負荷を確認

（ダブルクリック）



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

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

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



「複数プロジェクトの進捗確認」の例

「SAMPLE2プロジェクト」の製造進捗率は約70%。

それに対して工数は予定より20%以上超過。

工数が足りない原因の調査が必要。

「プロジェクト俯瞰」のグラフで原因を追究（ダブルクリック）

抽出条件：製造進捗率閾値：10%



「複数プロジェクトの進捗確認」の例

「SAMPLEプロジェクト」の工数は90%を使用。

それに対して製造進捗率は予定の80%でしかない。

工数が足りない以外の要因が含まれている。

「プロジェクト俯瞰」のグラフで原因を追究（ダブルクリック）

抽出条件：工数の予実閾値：10%



「複数プロジェクトの健全性確認」では

判定基準閾値（健全）：10% 判定基準閾値（危険）：20% 障害滞留日数（健全）：10日障害滞留日数（危険）：20日

「SAMPLEプロジェクト」は障害の発生件数と未解決件数が多く、試験進捗率も悪い。

障害により試験の進捗が阻害されている。工数超過は危険レベルではないが注意が必要。「プロジェクト俯瞰」、

「障害原因分析」のグラフで原因を追究

（クリック）



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

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

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

参照ＵＲＬ



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

Software Engineering Center - IPASoftware Engineering Center 5 上流工程...

Documents

Transcript of Software Engineering Center - IPASoftware Engineering Center 5 上流工程...