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

(1)

Information-technology Promotion Agency, Japan

Software Engineering Center

ソフトウェアジャパン２０１３ ITフォーラムセッション IPA/SEC 2013年02月15日

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

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

ソフトウェア開発データの見える化に基づく定量的プロジェクト管理

研究員大和田裕

(2)

SEC

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

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

(3)

SEC

ITプロジェクトの実状

インフラ基盤としての高信頼性の要求要求の多様化・高度化

リスクの増大

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

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

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

信頼できるマネジメント

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

進捗・障害管理レポーティング

高難易度となったプロジェクト・マネジメント作業

を遂行するためのが必要

(4)

SEC

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

「期限どおり」に、「所定の費用」で、「求められる品質」の

ソフトウェア開発を行うには、様々な問題を早期に発見し解決していくためのＩＴプロジェクトのが必要となる

一

歩

進ん

だ

プロ

ジェ

クト

マネ

ジメ

ント

(5)

SEC

Ｖ字モデル

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

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

保守

運用

見える化

(6)

SEC

上流工程

 納期までの切迫感の欠如、要件の曖昧さ、成果物の見えにくさ

 所詮「見切り発車」

→ プロジェクト稼働後に様々な問題を惹起する

 リスクを予知し、ネガティブなインパクトを最小にすることは容易ではない

問題認識

 プロジェクトの不十分な状態を把握するための定性的・定量的な

「見える化」が必要

 問題の潜在箇所 ⇒ 早期に発見する

 不確定な要素 ⇒ いつまで不確定で良いかを評価し、

判断する

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

課題

要件定義

システム設計

ソフトウェア設計

プログラミング

ソフトウェアテスト

システムテスト

運用テスト

(7)

SEC

中流工程

 先立つ「上流工程」での要件定義が曖昧なまま、プログラムへの変換作業が進められる

→ 多くの要件（仕様）変更と、トラブルの多発

 多くのベンダー・技術者による分業となり個人への作業依存が高くなる

→ 進捗・品質がばらつきやすい

→ プロジェクトの透明性が著しく悪化し管理が難しい問題認識

 要件の曖昧さを把握し是正する「見える化」が必要

 機能要件、非機能要件

 要件（仕様）変更への対応

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

課題

要件定義

システム設計

運用テスト

(8)

SEC

下流工程

 それまでの工程に起因する品質不良が一気に露呈

 問題に対応するための時間や手段が限定されるという宿命問題認識

 失敗しそうなプロジェクトを救う活動が重要

 問題の早期発見、迅速な処置のための「見える化」が必要

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

課題

要件定義

システム設計

運用テスト

(9)

SEC

見える化の方向

プロジェクトの状態を把握するために、

KKD（勘と経験と度胸）だけではなく、定性的・定量的なアプローチが必要。

カリスマプロジェクト・マネジメントの暗黙知を形式知にしていくことで、

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

KKD

（暗黙知）

・状況を的確に掴むためのチェック項目の検討

・網羅性のある観測すべき項目の検討

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

野中郁次郎竹内弘高

「知識創造企業」

(10)

SEC

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

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

事例集チェックシート

（自己評価シート／

ヒアリングシート）

俯瞰図

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

定量的見える化アプローチ測定項目リスト

測定分析データにしたがって定量化した情報に

よるリスクの見える化

測定分析データ一覧表ベース尺度一覧表

支援ツール

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

実践の場プロジェクト

統合的アプローチ

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

断の仕組み

リスク分類表

(11)

SEC

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

「見える化」参照ＵＲＬ

(12)

SEC

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

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

(13)

SEC

俯瞰図

経営者発注側

協力会社マスコミ

発注側の顧客発注側

の株主

GM 営業 PM 担当者

プロジェクトマネージャ

経営者 PM

スタッフメンバーメンバ

ー営業

受注側

営業共通 GM プロジェクト

技術面、

業務面におけるキーパー

ソン先方キーパーソン。

決定権を持っている

ステークホルダー俯瞰図プロジェクト推進体制俯瞰図

周辺システム構成俯瞰図システム構成俯瞰図スケジュール俯瞰図

要員遷移俯瞰図

 「木を見て森を見ず」弊害の排除

 ドミナント・アイテム ^※１を継続的、システム横断的に把握

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

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

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

(14)

SEC

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

(15)

SEC

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

(16)

SEC

 プロジェクト・マネジメントの要点を再確認

 客観的視点でのチェックによる見落としの排除

 リスクの明確化

チェックシート

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

0 1 2 3 4 5

統合

スコープタイム

コスト品質人的資源コミュニケーショリスクン

調達顧客技術組織基本動作モチベーション

課題管理

自己評価ヒアリング評価

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

-4 -3 -2 -1 0 1 2 3 4

統合ス

ーコプ

タイム

コスト

品質

人的資源

コミュニケーション

リスク

調達

顧客

技術

組織

基本動作

モチーベション

課題管理

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

P M が悲観的

P M が楽観的

(17)

SEC

自己診断シートによる「見える化」

 集計・表示ツール付き

 現場リーダ向け

 3段階評価

 所要時間40分程度

自己評価シート：プロジェクトマネージャによる自己評価

（上流：３５、中流：３８、下流：４０項目）

⇒ 自己チェックによる気付き

(18)

SEC

ヒアリングシートによる「見える化」

 集計・表示ツール付き

 ベテランが現場リーダから聞き出す

 エビデンス資料要求

 5段階評価

 所要時間2時間＋

ヒアリングシート：専門家チーム（ＰＭＯ）によるヒアリング（上流：７４、中流：７８、下流：８５項目）

⇒ 専門家からの客観的チェック

(19)

SEC

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

自己評価と専門家の診断の差、専門家からの対策案を提示

⇒ マネジメントの過不足を把握し、対策を検討

(20)

SEC

失敗事例集

※１プロジェクト・マネージャが得られる限りの情報を駆使し、

最悪の場合も見極めて、自己責任のもとで選択する

・プロジェクト・マネジメントの問題

・要件定義、開発範囲にかかわる問題

・システム設計・構築技術にかかわる問題

・ステークホルダーにかかわる問題

・モチベーションにかかわる問題

問題発生の典型パターン

 失敗から学んで失敗を防止

 リスクを内在させたままでの見切り ^※１方法

 捉えるべき兆候

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

(21)

SEC

事例：本当のユーザを見誤ってしまう

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

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

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

 捉えるべき兆候：

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

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

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

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

(22)

SEC

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

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

(23)

SEC

測定項目リスト

測定分析データ一覧表

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

ベース尺度一覧表

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

例）レビュー計画書のレビュー計画回数、計画所要時間、

要件定義書のレビュー実施回数、累積時間

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

上/中/下流：78/84/70項目

総集編に全工程導出尺度一覧

(24)

SEC

「見える化」のための測定分析項目(1/2)

 スコープ：（上流工程、重点測定項目）



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



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



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

 タイム：（上流工程）



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



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

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



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

、予算内でとれるコストを見る。



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

 品質：（全工程）



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



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



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

 人的資源：（上流工程）



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



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

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



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



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

(25)

SEC

「見える化」のための測定分析項目(2/2)

 リスク：（上流工程で準重点測定項目、中流工程で重点測定項目）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

客の要件定義メンバー数

(26)

SEC

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

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

(27)

SEC

リスク分類表

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

 統合的な視点でリスクを洗い出す

例）・プロジェクト・マネージャへのヒアリング結果を基に、類似の過去事例を参照してリスクを検討する

・ヒアリング結果で悪かった項目に対し、関連する測定分析データを調べ、

リスクを定量的に評価する

・事例集から現在の状況に類似したプロジェクトを見つけ、ヒアリングシート

でプロジェクトの状況を確認する

(28)

SEC

ヒアリングシート

リスク分類表

事例集

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,Ko

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

リンク事例6件

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

(29)

SEC

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

ヒアリングシート

リスク分類表

測定分析データ一覧

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,Ko

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

(30)

SEC

ヒアリングシートリスク分類表

事例集

事例14

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

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

技術

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

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

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

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

H74 技術

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

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

(31)

SEC

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

(32)

SEC

ITプロジェクトの実状

インフラ基盤としての高信頼性の要求要求の多様化・高度化

リスクの増大

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

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

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

信頼できるマネジメント

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

進捗・障害管理レポーティング

高難易度となったプロジェクト・マネジメント作業

を支援するが必要

(33)

SEC

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

 開発フレームワーク・開発ツールを利用

 既存アプリケーションの再利用

 変更／追加部分のみの開発

 機能・アプリケーションの分割開発

 外部発注開発、オフショア開発

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

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

問題解決の判断遅延

(34)

SEC

定量的管理の課題

定量データの自動収集

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

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

統計グラフ描画による、視覚的・

直観的な分析・診断

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

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

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

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

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

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

に実装

(35)

SEC

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

・ソース規模の推移

・工程別の障害件数

・不良発生原因、発生箇所

・計画値との比較による進捗

定量データ

システムの

の取得

版管理

（ソースコード）

課題管理

（障害・課題）

進捗管理

（計画と実績）

ソースを課題や進捗を

課題の把握・

プロジェクトの進捗を課題の把握・

将来進捗を

の作成プロジェクト

計画値の

対策診断計画

実施

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

KKD（勘、経験、度胸）から、ツールによる

に基づいたプロジェクト管理へ

(36)

SEC

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

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

するツール

複数プロジェクト俯瞰

タスク

障害・課題

要員負荷管理

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

工数

収集進捗

可視化

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

プロジェクトの可視化・グラフ化定量的データの収集

集計

(37)

SEC

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

 定量的データの自動収集

 プロジェクト管理ツール、構成管理ツール

 日常使用ツールからの日次業務データの取り込み

 Excel, MS Project, CSV等からのデータ収集

 グラフ表示による視覚的・直観的な分析・診断機能の提供

 ダッシュボード表示

 ドリルダウン・ドリルスルー表示

 利用者によるグラフ・カスタマイズ

 ツールが簡易に利用できることを重視

 基本測定量（規模、工数、工期、品質）に絞って提供

 高度で複雑な利用方法は将来の拡張

 柔軟性・拡張性の確保

 利用者による定量データの追加など

 全環境を導入できる一括インストーラを提供

 オープンソースとして公開（GPL）

 既存ツールを活用

 Redmine、Trac、Subversion、GIT、BIRT（BIツール）、Pentaho（ETLツール）

(38)

SEC

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

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

管理支援機能

データ収集

・集計起動

定量的分析・

診断呼出

設定管理機能

BIツール (Eclipse BIRT/BIRT Report Viewer) 複数プロジェクト

俯瞰表示機能

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

個別グラフ表示機能

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

チケット

ETLツール (Pentaho) データ収集機能

データ集計機能

グラフ表示

データ

定量データ

(39)

SEC

チケットとは

担当者が割り振られ、その作業に「登録」，「担当者割り当て」，

「作業中」，「完了」などの状態がある作業 ≒作業指示書・報告書

チケットの利点

 開発者は、自分に割り当てられているタスクやリスクを明確に知ることができる

 開発者は、割り当てられたチケットの必要項目に入力するだけなので、作業報告を省力化できる

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

(40)

SEC

WBSチケット

(41)

SEC

チケット入力

(42)

SEC

障害・課題チケット

(43)

SEC

チケットの一覧

(44)

SEC

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

(45)

SEC

表示グラフ一覧

 WBS（タスク）・品質管理

 試験計画項目密度、 WBS進捗推移、WBS進捗変化、

EVM評価（進捗、工数）、ソフトウェア規模推移、試験進捗率、

工数の予実、遅延重要タスク抽出

 障害・課題管理

 障害件数変化、障害解決予測、障害原因分析、障害発生密度、

障害滞留状況、長期未解決課題抽出

 要員負荷管理

 負荷状況

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

定量管理ダッシュボード

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

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

 複数プロジェクトの進捗確認、健全性確認

(46)

SEC

画面レイアウト

グラフ表示領域共通機能

ナビゲーション領域

HIDE/SHOWで切替

(47)

SEC

共通機能

パンくずリスト表示領域

操作バー

・パラメータ変更－期間変更、閾値・エクスポート

・ファイル出力

－PDF,Word,

PowerPoint

・印刷

(48)

SEC

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

 定量管理ダッシュボード

 担当プロジェクトの全体を俯瞰する

(49)

SEC

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

「遅延重要タスク抽出」

の件数が多い。

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

「遅延重要タスク抽出」のグラフで原因を追究

（ダブルクリック）

ユーザＩＤを指定

自分が受け持っている

プロジェクトを選択。

(50)

SEC

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

 試験計画項目密度

 試験項目のカバレッジを確認する

 試験進捗率

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

(51)

SEC

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

 WBS進捗推移

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

 WBS進捗変化

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

(52)

SEC

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

プロジェクトのどの工程が

遅れているのかの確認が必要。

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

ドリルダウンして、

下位タスクのグラフで原因を追究

（ダブルクリック）

プロジェクトの終了予測日が

大幅に予定を上回っている。

(53)

SEC

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

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

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

ＸＸＸ－１製造は予定どおり

終了している。

(54)

SEC

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

 EVM評価

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

 ソフトウェア規模推移

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

(55)

SEC

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

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

スケジュールと照らし合わせ計画された工程内かを確認。

想定外であれば調査。

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

9/13の週に修正が行われた。

障害による修正と想定。

(56)

SEC

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

 工数の予実

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

 遅延重要タスク抽出

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

(57)

SEC

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

 障害件数変化

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

 障害解決予測

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

(58)

SEC

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

 障害原因分析

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

 障害発生密度

 どのモジュールの品質が悪いのか把握する

(59)

SEC

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

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

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

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

WBSタスク：

IPF開発プロジェクト

(60)

SEC

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

プロジェクトへの影響が大きい可能性が高い。

詳細の確認が必要。

製造の「設計との不一致」

の件数も多い。

「障害タスク一覧表示」で問題タスクを追究

（ダブルクリック）

かつ、４件の未解決障害

が残っている。

(61)

SEC

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

 障害滞留状況

 長期間解決されていない障害を抽出する

 長期未解決課題抽出

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

(62)

SEC

負荷管理のグラフ

 負荷状況

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

(63)

SEC

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

 複数プロジェクトの進捗確認

 担当プロジェクト／サブプロジェクトで、リスクのあるものを検出する

 複数プロジェクトの健全性確認

 担当プロジェクト／サブプロジェクトのリスクを俯瞰する

(64)

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

Software Engineering Center

ソフトウェアジャパン２０１３ ITフォーラムセッション IPA/SEC 2013年02月15日

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

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

ソフトウェア開発データの見える化 に基づく定量的プロジェクト管理

研究員 大和田 裕

SEC

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

SEC

ITプロジェクトの実状

インフラ基盤としての 高信頼性の要求 要求の多様化・高度化

リスクの増大

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

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

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

信頼できる マネジメント

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

進捗・障害管理 レポーティング

高難易度となったプロジェクト・マネジメント作業

を遂行するための が必要

SEC

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

「期限どおり」に、「所定の費用」で、「求められる品質」の

ソフトウェア開発を行うには、様々な問題を早期に発見し解決 していくためのＩＴプロジェクトの が必要となる

一

歩

進 ん

だ

プ ロ

ジ ェ

ク ト

マ ネ

ジ メ

ン ト

SEC

Ｖ字モデル

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

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

保守

運用

見える化

SEC

上流工程

 納期までの切迫感の欠如、要件の曖昧さ、成果物の見えにくさ

 所詮「見切り発車」

→ プロジェクト稼働後に様々な問題を惹起する

 リスクを予知し、ネガティブなインパクトを最小にすることは容 易ではない

問題認識

 プロジェクトの不十分な状態を把握するための定性的・定量的な

「見える化」が必要

 問題の潜在箇所 ⇒ 早期に発見する

 不確定な要素 ⇒ いつまで不確定で良いかを評価し、

判断する

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

課題

SEC

中流工程

 先立つ「上流工程」での要件定義が曖昧なまま、プログラムへ の変換作業が進められる

→ 多くの要件（仕様）変更と、トラブルの多発

 多くのベンダー・技術者による分業となり個人への作業依存が 高くなる

→ 進捗・品質がばらつきやすい

→ プロジェクトの透明性が著しく悪化し管理が難しい 問題認識

 要件の曖昧さを把握し是正する「見える化」が必要

 機能要件、非機能要件

 要件（仕様）変更への対応

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

課題

SEC

下流工程

 それまでの工程に起因する品質不良が一気に露呈

 問題に対応するための時間や手段が限定されるという宿命 問題認識

 失敗しそうなプロジェクトを救う活動が重要

 問題の早期発見、迅速な処置のための「見える化」が必要

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

課題

SEC

見える化の方向

プロジェクトの状態を把握するために、

KKD（勘と経験と度胸）だけではなく、定性的・定量的なアプローチが必要。

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

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

ソフトウェア開発データの見える化に基づく定量的プロジェクト管理

研究員大和田裕

インフラ基盤としての高信頼性の要求要求の多様化・高度化

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

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

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

信頼できるマネジメント

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

進捗・障害管理レポーティング

を遂行するためのが必要

ソフトウェア開発を行うには、様々な問題を早期に発見し解決していくためのＩＴプロジェクトのが必要となる

進ん

プロ

ジェ

クト

マネ

ジメ

ント

 リスクを予知し、ネガティブなインパクトを最小にすることは容易ではない

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

 先立つ「上流工程」での要件定義が曖昧なまま、プログラムへの変換作業が進められる

 多くのベンダー・技術者による分業となり個人への作業依存が高くなる

→ プロジェクトの透明性が著しく悪化し管理が難しい問題認識

 問題に対応するための時間や手段が限定されるという宿命問題認識

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

野中郁次郎竹内弘高

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

事例集チェックシート

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

定量的見える化アプローチ測定項目リスト

測定分析データにしたがって定量化した情報に

測定分析データ一覧表ベース尺度一覧表

実践の場プロジェクト

統合的アプローチ

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

ステークホルダー俯瞰図プロジェクト推進体制俯瞰図

周辺システム構成俯瞰図システム構成俯瞰図スケジュール俯瞰図

 ドミナント・アイテム ^※１を継続的、システム横断的に把握

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

スコープタイム

コスト品質人的資源コミュニケーショリスクン

調達顧客技術組織基本動作モチベーション