「ITプロジェクトの見える化」 - IPA · 2020-01-17 · ITプロジェクトを取り巻く問題について ... 20人弱の委員会：pm ... ⇒見える化手法の期待が高い

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

Software Engineering CenterCopyright© 2011 Information-technology Promotion Agency, Japan. All rights reserved.

2011年2月

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

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

専門委員神谷芳樹みたによしき

SECセミナ2011-2

「ＩＴプロジェクトの見える化」その手法と実証のこころみ

～定性・定量アプローチ、モニタツールEPMの活用から実証プロジェクトの経験まで～

「SECの推奨する『見える化』手法のすべて」

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

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

内容 ITプロジェクトにおける問題認識

ＩＴプロジェクトを取り巻く問題について

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

SEC BOOKS:「見える化」本から

その手法とツール(上流・中流・下流工程編、総集編（

- 定性的アプローチ

- 定量的アプローチ

- 統合的アプローチ

実証事例で考える「見える化」

全工程一貫計測モデル

コンパクトなアプローチ：ESxRコンテンツ

SECの組込みソフトウェア向けガイド：ESQR、ESMR

見えてどうするの！

SEC BOOKS:「定量的品質予測のススメ」

その先の話題：研究課題 2つ

IPA/SECのアウトプット活用法について



ITプロジェクトの実状

システムの社会インフラ基盤としての高信頼性の要求

要求の多様化・高度化

ＩＴシステム構築の短納期化・高機能化

増加するステークホルダ

法対応・リスク対策など複雑化する社会的要請

システム稼働環境や開発環境のオープン化

ITプロジェクトを取り巻く環境がより複雑化・多様化してきており、ソフトウェア製品に対する要求も高くなってきている。このため、プロジェクト・マネジメントの難度が高まってきている。

進捗は？

課題管理は？

品質は確保できてる？

パートナー会社のフォローが…

ITプロジェクトにおける問題認識



解決すべき課題

プロジェクトで起こるさまざまな問題を早期発見し解決していくために、見えにくいシステム開発を見えるようにする必要がある

顧客

ベンダ＇経営層（

スケジュール…

品質…

コスト…

開発作業…

プロジェクト

管理帳票など

？

？

顧客

ベンダ＇経営層（

プロジェクト

管理帳票など

！

！

スケジ

ュール

コスト

品質

開発作業

データ収集ツール見える化手法

見える！

etc...

一歩進んだ

プロジェクト

マネジメント

…

ＰＭＯ

「見える化」本



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

評価

ソフトウェア設計

システム設計

ソフトウェアテスト

システムテスト

要件定義運用テスト

プログラミング

システムの方向性・システム化計画

超上流工程

上流工程

中流工程

下流工程

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

プロセス共通

プロジェクトの見える化

プロセス改善

信頼性指標

定量データ分析

保守

運用

「アジャイル」の「ア」の字もなし



ITプロジェクトと見える化

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

KKD

＇暗黙知（

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

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

野中郁次郎竹内弘高

「知識創造企業」




ＩＰＡ／ＳＥＣ：「見える化」施策の歩み２０人弱の委員会：PM／PMO系、品質保証部系、ユーザ企業＇システム部門（、エンピリカルＳＥ系産学委員

２００６年度

下流工程における見える化

上流工程における見える化

全工程のまとめ

自己評価シート＇下流用（ヒアリングシート＇下流用（測定項目リスト症例分類表問題事象と対策事例集EPMツールの分析指標

自己評価シート＇上流用（ヒアリングシート＇上流用（測定項目リストリスク分類表見切り事例集

見える化言える化直せる化

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

中流工程における見える化

２００８年度２００７年度

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

２００５年度

書籍の４０％が、データ類。ダウンロード可能

自己評価シート＇中流用（ヒアリングシート＇中流用（測定分析データ一覧表中流工程分析ツール＇表（問題・対策事例集

全工程導出尺度一覧表

２００９年度

2010年度



ITプロジェクトの現場では見切り発車が日常的に行われているが、プロジェクト稼働後にさまざまな問題が発生している

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

問題認識

見切り発車などのようにプロジェクトが不十分な状態で進んでいる状態を想定して、その状況を定性的・定量的に見える化する手法が必要か？

上記の状況を乗り切るスーパーＰＭの知見を形式知化する必要あるのでは？

課題：上流工程

要件定義

システム仕様

ソフトウェア仕様




運用テスト

上流工程下流工程

立ち位置

上流工程の課題「見える化」本



上流工程における見える化の目標

要件の曖昧さ

顕在化していない問題をとらえ、プロジェクトの状況を見えるようにする

納期までの切迫感の欠如

成果物の見えにくさ

不確定な要素 ⇒ いつまで不確定で良いか評価し、判断する

どこかに問題が潜んでいる ⇒ 早期に発見する




上流工程での要件定義があいまいなまま、中流工程でのプログラムへの変換作業が行われ、トラブルが発生することが多い

専門家による分業体制に移行し、個人への作業依存が高くなるので、品質がばらつきやすい

問題認識

ソフトウェア要件のレビューを十分に行い、機能要件と非機能要件に対してあいまいさを極力減らす

個々に生じるプロジェクトの進捗、ソフトウェア品質のばらつきを是正する

課題

要件定義

システム仕様





運用テスト

上流工程下流工程立ち位置

中流工程の課題「見える化」本



中流工程における見える化の目標

ソフトウェア要件

中流工程は、上流工程のアウトプットである“要件”と“プロジェクト計画”を受けて、下流工程の要件に合ったシステムであるかどうかの検証へとつなぐ工程

進捗や品質のばらつきの見える化

詳細設計コード

多くのベンダ、多くの作業者

非機能要件や仕様変更への対応の見える化

仕様＇要件（の変更




下流工程の課題下流工程で問題が顕在化しやすいという特徴。

それまでの工程に起因する品質不良が入り込み、下流工程で問題が露呈しやすい

下流工程で問題発生しても、対応のための時間や手段が限定されている

「失敗しそうなプロジェクトを救う活動」の検討が主眼

要件定義

システム仕様





運用テスト

予防策も大切。しかし下流工程で「早期に発見」し「迅速に処置する」治療法を早急に検討していく必要がある品質不良の原因が多様

対応の時間・手段が限定⇒見える化手法の期待が高い

上流工程下流工程立ち位置




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

統合的アプローチ

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

測定項目リスト

実践の場

プロジェクト

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

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

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

よるリスクの見える化

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

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

仕組み

事例集

リスク分類表

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

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

測定分析データ一覧表

ベース尺度一覧表

自動計測ツールEPM





俯瞰図

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

経営者発注側

協力会社

マスコミ

発注側の顧客

発注側の株主

営業GM

PM

担当者

プロジェクトマネージャ

経営者

PM

スタッフ

メンバー

メンバー

営業

受注側

営業

共通

GM

プロジェクト

技術面、業務面における

キーパーソン

先方キーパーソン。

決定権を持っている

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

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

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




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

0

1

2

3

4

5統合

スコープ

タイム

コスト

品質

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

ンリスク調達顧客

技術

組織

基本動作

モチベーション

課題管理

自己評価

ヒアリング評価


チェックシート

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

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

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

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

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

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

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

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

-4

-3

-2

-1

0

1

2

3

4

統合

ス

コー

プ

タイム

コスト

品質

人的資源

コミ

ュニケーシ

ョン

リスク

調達

顧客

技術

組織

基本動作

モチ

ベー

シ

ョン

課題管理

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

PMが悲観的

PMが楽観的




ヒヤリング時に持参すべきマネジメント資料一式(下流工程（

P41



チェックシート＇下流工程の例（個別のヒアリング要領No. 知識エリアチェック項目評価基準

H12

スコープ想定外のスコープ増＇機能範囲と作業範囲の増加（が発生しているか？発生している場合、それは許容範囲内か？

スコープ増を定量的に押さえていること。許容範囲かどうかをコスト、スケジュールの観点から評価していること

スコープ増加時の対応策(機能削減/費用増/スコープ変更)を顧客と予め合意しておく。スコープ増の場合に、テストの増大やクリティカルな機能に対する影響度合やどの時点でスコープ増が発生したかを確認すること

H13

スコープ前工程担当者から引継ぐ時の理解度は十分か？

何が引き継ぎ資料なのか定義されていること。検討が十分でないところが明確にされていること

①引継ぎ資料が不足なくあることや、その内容についてもきちんと理解する②前工程のアウトプットを十分に咀嚼する③もし理解度が不足している場合は、引継ぎ資料のレビューや上流工程担当者からの再説明を行うなどの対策が必要である④コンサル会社の成果物がSierに渡った段階で引継ぎされてない事例があり、プロジェクトの失敗がそこに起因する場合がある⑤テスト結果を見て良いと判断できる人が何人いるかをV字モデルに対応させて確認すること

H14

スコープ他社(含む顧客)開発と接続がある時の責任分担は明確か？

他社接続に関する責任分担表とテスト･移行スケジュールを関係会社と合意しておくこと。例えば、以下のような観点で確認を行なう。　①接続テストの日程について他社と合意が取れているか？　②テストの作業順序について合意が取れているか？　③テストデータはどちらが準備するか合意が取れているか？　④テスト結果のとりまとめはどちらが行うか合意が取れているか？

①自社のWBSか他社のWBSか担当分担は明確になっているか？②問題点票のフローのルールなどが明確か？③誰がテストの責任者かを明確にする④５W１Hを明確にする⑤テストの目的、テストを行なうまでの段取りをはっきりさせること


P125



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

ＰＭＢＯＫ９エリア

拡張知識エリア





見切り事例集

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

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

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

問題発生の典型パターン

上流：58事例

中流：58事例

下流：77事例

(上流（




事例一覧＇上流工程（

P47




事例タイトル一覧＇中流工程（

P43,44




事象タイトル一覧(下流工程（P60,61




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

捉えるべき兆候

・契約する前であれば、機能を削減し、予算判明以降に発生する赤字を減額する

・契約内容を確認し、プロジェクト単体が最小限の損害で契約を満たす方法を検討する

・システム化対象範囲を分割して複数年度の契約にする等戦略的に採算が取れるような交渉を進める

・費用と作業内容については最低限文書で取り交わしておく。作業を実施するに至った経緯についても記録しておき、たとえ後付けでも作業の妥当性を顧客側の新担当者に説得できるようにしておく必要がある

・その非公式な約束事が反故になるケースを想定し、そのリカバリ方法が確保できていて、かつリカバリコストへの対策を決めておく事

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

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

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

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

上流工程における見切りの事例「見える化」本

P174



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

P175




中流工程失敗事例「見える化」本

P110



中流工程失敗事例「見える化」本

P127



下流工程失敗事例

ダウンロードはＰＤＦ形式


P142



下流工程失敗事例「見える化」本

P154






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

測定項目ごとの測定方法、分析方法を整理

ベース尺度一覧表

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

例（要件定義書のレビュー進捗率

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

上/中/下流：７８/８４/７０項目総集編に全工程導出尺度一覧

上/中/下流：１７５項目





現物確認システマティック確認

1

スコープ機能的規模と変動＇機能面でスコープが増加していないか（

機能変更要求数(未、済) 機能毎、要件毎変更管理表

2 スコープ機能変更対応数(仕様変更対応数) 機能毎、要件毎変更管理表

3

スコープドキュメントの規模(ページ数) ドキュメントの数の推移、ドキュメントごとのページ数の推移

プロジェクト実行計画書、テスト計画書、基本設計書、詳細設計書

構成管理ツール＇ＥＰＭツール（

4スコープソースコード行数ソースコード行数の推移構成管理ツール＇ＥＰ

Ｍツール（

5スコープソースコード変更行数累積ソースコード変更行数構成管理ツール＇ＥＰ

Ｍツール（

6

タイムマイルストーンの達成状況の管理

結合テスト工程での作業単位の進捗責任者マイルストーンの成果物検証数＇未、済（

ガントチャート、稲妻線

7

タイム基本設計～製作・単体テストまでの進捗

責任者マイルストーンの成果物検証数＇未、済（

ガントチャート、稲妻線

No測定方法

知識エリア測定可能な概念／測定目的測定データ項目測定データの属性(参考)

測定項目 MTTR(平均修正日数)

測定方法バグ票(発見日、修正日（、EPMツール

測定から分かること

MTTRが長い場合、プログラム構造が悪い可能性あり。または開発チームの対応力不足の可能性あり




中流：付録５＇Ｐ１４２（参照



ＮＯ．知識

エリア

＇主（

測定の目的利用者導出尺度収集者導出尺度の見方、

分かること

S3 ｽｺｰﾌﾟ設計変更の面から

●詳細設計変更の規模と変動を把握する

●詳細設計変更の対応状況を把握する

ＰＭ、

ＰＭＯ

●詳細設計変更発生数の推移

●詳細設計変更対応数の推移

●未対応数の推移

未対応数＝詳細設計変更発生数累計

－詳細設計変更対応数累計

詳細設計者 ●詳細設計変更発生数が多い、あるいは増加傾向にある場合、基本設計で機能が確定していない可能性がある

●詳細設計変更発生数が急激に増加した場合、機能が変わった可能性がある。機能の確認が必要

●詳細設計変更対応数が多い、あるいは増加傾向にある場合、対応負荷・費用について顧客と合意が取れていない可能性がある

⇒ 測定した導出尺度の値、傾向を見て次工程以降に

起こりうる問題、発生している問題の原因を発見

・・・




Empirical Project Monitor : EPM

LinuxPopper,

Subversion, 影舞

VM

Windows

Web Browser

Win Eclipse

VSS

WindowsLinux

自動計測：



定量的アプローチ：自動計測：EPMツールの例

構成管理の仕方＇ルール付け（・実践がきちんと行われているかがわかる

変更される範囲が大きい場合は、品質が悪い可能性がある

共通モジュールの変更が多いと品質の务化につながる可能性がある

バグ票と見比べて、修正作業がちゃんと行われているかどうかをチェックする

（例）チェックイン契機（CVS）

大分類技術カテゴリ名称概要目的カテゴリ見える化活用方法一次データソース

分析ツールデータ収集ツール

自動化レベル

基本測定量表示例備考

指標ソースコードその他のプロダクトを対象にして測定される属性

汎用＇品質管理，他の複雑な指標のための基礎データ（

ソースコード NA* CVS ◎* - NA EASEでの実装検討中

指標例単純プロダクト指標ソースコード行数ソースコード行数汎用ソースコード EPM CVS ◎ - NA指標例単純プロダクト指標コメント抜き行数コメント抜き行数汎用ソースコード NA* CVS ◎* - NA EASEでの実装検討中

指標例単純プロダクト指標サイクロマチック数コードの複雑さを示す指標

汎用ソースコード NA* CVS ◎* - NA EASEでの実装検討中

指標例単純プロダクト指標

指標

EPMコアと基本プラグインによって提示可能な指標．時系列に沿った表示形式．

汎用 EPMリポジトリ EPMCVS,Mailman,GNATS

◎ -

指標例 EPM基本推移指標ソースコード行数推移時間経過に対するソースコードサイズの推移

進捗管理など

・遠隔地であっても開発状況がわかるという利点がある・テスト工程に入ってからの増減から、シビアさがわかる＇ＰＭＯの立場で見ると、プロジェクトマネージャが増減の理由をきちんと説明できるかで、プロジェクト管理の状況がわかる（・減っているとおかしい＇不要コードの削除等を行って整理したなどの理由があればよい（

ソースコード EPM CVS ◎単位時間毎のソースコードサイズ

指標例 EPM基本推移指標累積ソースコード変更行数推移

時間経過に対するソースコード変更累積量の推移＇単調増加（

進捗管理など

・遠隔地であっても開発状況がわかるという利点がある・テスト工程に入ってからの増減から、シビアさがわかる＇ＰＭＯの立場で見ると、プロジェクトマネージャが増減の理由をきちんと説明できるかで、プロジェクト管理の状況がわかる（

ソースコード EPM CVS ◎単位時間毎のソースコード変更量

指標例 EPM基本推移指標メール件数の推移メール件数を時系列にプロットしたもの

プロジェクト管理など・個人ごと、Subjectごとの送受信件数推移の傾向に異常値があり、その理由の説明つかない場合何らかの問題がある可能性がある

メール EPM MAILMAN ◎単位時間毎のメール件数

指標例 EPM基本推移指標障害発生・解決時期障害発生時期，解決時期を時系列にプロットしたもの

プロジェクト管理など・品質の落ち着き具合の判定ができる・そのプロジェクトの問題解決能力がわかる

障害票 EPM GNATS ◎各障害の発生時期，解決時期

指標例 EPM基本推移指標チェックアウト頻度一定期間毎のチェックアウト回数合計の推移

プロジェクト管理など

・構成管理の仕方＇ルール付け（・実践がきちんと行われているかがわかる・変更される範囲が大きい場合は、品質が悪い可能性がある・共通モジュールの変更が多いと品質の务化につながる可能性がある・バグ票と見比べて、修正作業がちゃんと行われているかどうかをチェックする

ソースコード EPM CVS ◎単位時間毎チェックアウト数

指標例 EPM基本推移指標チェックイン契機一定期間毎のチェックイン回数合計の推移

プロジェクト管理など

・構成管理の仕方＇ルール付け（・実践がきちんと行われているかがわかる・変更される範囲が大きい場合は、品質が悪い可能性がある・共通モジュールの変更が多いと品質の务化につながる可能性がある・バグ票と見比べて、修正作業がちゃんと行われているかどうかをチェックする

ソースコード EPM CVS ◎単位時間毎チェックイン数

指標例 EPM基本推移指標累積障害件数の推移累積障害件数の推移進捗管理，品質管理など・品質の落ち着き具合の判定ができる・そのプロジェクトの問題解決能力がわかる　　－試験項目の消化と累積障害件数との関係が重要

障害票 EPM GNATS ◎単位時間毎障害票件数

指標例 EPM基本推移指標累積未決障害件数の推移累積未決障害件数の推移

進捗管理，品質管理など・品質の落ち着き具合の判定ができる・そのプロジェクトの問題解決能力がわかる

障害票 EPM GNATS ◎単位時間毎障害票件数，解決障害件数

指標例 EPM基本推移指標平均障害滞留時間の推移平均障害滞留時間の推移

進捗管理，品質管理など

・平均障害滞留時間を見れば問題解決能力がわかる　- テスト工数の妥当性がわかる　- 総合テストの段階で簡単に修正できるような不良がたくさん出ているということは　　単体テストで抽出できたはず

障害票 EPM GNATS ◎単位時間毎障害票件数，解決障害件数

基本分析指標

単純プロダクト指標

・・・

EPM基本推移指標ほぼ任意の組合わせで重畳提示可能

・より高次の指標のための基礎データとして活用される

書籍に詳細解説下流工程編

時間

ソースコード行数

ソースコード更新

(チェックイン（契機

ソースコード行数の推移



協力データ提供



累積障害件数＇プロジェクト別グラフ（

Aプロジェクト Bプロジェクト

Cプロジェクト Dプロジェクト




累積障害・パレート・クロス分析パレート図優先度

累積障害

パレート図重要度

クロス分析発見工程・混入工程

中

高低

混入工程

発見工程オーナ




累積障害・ステップ数・メール投稿数の比較

累積障害・ステップ数・メール投稿数ステップ数・メール投稿数

累積障害・ステップ数累積障害・メール投稿数

ステップ数

メール投稿数

累積障害件数

ステップ数

メール投稿数

メール投稿数

累積障害件数

ステップ数

累積障害件数協力データ提供




リスク分類表

ヒアリングシート、測定分析データ一覧表、事例集を連携統合的な視点でリスクを洗い出す

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

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

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





より客観的・網羅的な視点で見える化する

・自己評価シート・ヒアリングシート

測定項目リストによる定量的測定

失敗事例との対比

さまざまな角度からの統合評価

問題箇所の把握




ヒアリングシート

リスク分類表

事例集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章：曖昧性と不確実性のマネジメント

7章：見切りながらのプロジェクト推進

8章：プロジェクトを取り巻く環境変化と課題の俯瞰

中流 6章：中流工程の見える化によるプロジェクト・マネジメント ☆

下流 6章：「見える化」に関する研究の解説

総集編 6章：問題プロジェクトの事例分析

7章：見える化によるプロジェクト・マネジメント

8章：ＰＭＯを活用した統合的マネジメント

9章：ＰＭＯのあるべき姿

リアルオプションの話

覆面座談会あり

プロジェクト計測エンピリカルソフトウェア工学の紹介

作業区分と「見える化」「直せる化」の関連



中流工程における作業区分と「見える化」「直せる化」の関連図中流工程編 6章

P69



見える化での課題工程問題認識課題

上流工程

見切り発車が日常的

＇稼動後に問題発生（

ネガティブインパクトの最小化は

容易ではない

プロジェクトの不十分な状況を

定性的・定量的に見える化する

スーパーPMの知見を形式知化

中流工程

要件定義が曖昧なままでプログ

ラムへの変換作業

分業体制で個人への作業依存

度が高い

目標品質等のベースラインを

明確にする

品質はばらつく前提で

チェックポイントの設定

下流工程

前工程までの品質不良による

問題の顕在化

問題に対する対応時間・手段が

限定

「早期に発見」し、「迅速に処理

する」治療法

「失敗しそうなプロジェクト」を救う

活動




見える化の目標

工程目標

上流工程

潜んでいる問題を早期に発見

不確定な要素が、いつまで不確定で良いかを

評価、判断

中流工程

ルール遵守による作業品質の均一化

不測の事態につながるリスクの早期発見

仕様変更要望へのリスクの明確化

下流工程

プロジェクトの成否に関わる問題を早期に発見し、

危機的状況になる前に要因を分析、対策の実施




英訳公開済み

部分訳：和文200ページ相当(英文A4版：280ページ（

EPM：ユーザインタフェースは英語可能であるが、マニュアルは和文のみ

他にデータ白書



Software Engineering Center 46Copyright© 2010 Information-technology Promotion Agency, Japan. All rights reserved. 46/57

運用

分析

分析結果をフィードバック

分析要件の検討

予実管理情報（TimeTracker）による計画・進捗データ取得

ESQRのプロセス・プロダクト品質指標による分析

ツールサーバ

データ収集部のみをカスタマイズして搭載

実証プロジェクト事例から：2007-2009

CATS社資料から

実証１



実証プロジェクト事例から＇2007-2009（

ＯＥＭ

Tier1 サプライヤー

ソフトウェアベンダー

7社：各社3～20人程度

３年間、進行中のプロジェクト計測･可視化・フィードバック実施ＥＴＳＳ，ＥＳxＲ＇ＥＳＰＲ，ＥＳＭＲ，ＥＳＱＲ（，ＥＰＭ，ＴｉｍｅＴｒａｃｋｅｒ

組み込みマイクロプロセッサＥＣＵのミドルソフトウェアの共同・分担開発

計測、見える化、フィードバック

☆☆

☆☆☆

☆☆

実証１



SEC先進プロジェクト(COSE:2004-2006)

プローブ情報システムの共同開発

実証２

データ分析・フィードバック組織

G-PM

計測データ可視化レポート

1.プロジェクト・オーナ

開発コンソーシアム

プログラミング開発者のいる企業

プログラミング開発者のいない企業

開発末端組織

2.全体PM

3.サブPM

4.サブリーダ

5.プログラミング開発者

EPM

大手ソフトベンダ

協力会社群

タイプA

タイプB

タイプC



計測とフィードバックの形

障害追跡システム

電子メール

バグ票

XML 標準形式

リポジトリ：RDBEPM

分析機能ソフトウェア開発環境

プログラム開発

障害報告

メール

構成管理システム

ソースコード

プロジェクト・マネジメントへのリアルタイム・フィードバック

(CVS、Subversion)

(影舞、GNATS、Bugzilla)

プロジェクト・マネージャ等へのチェックリストによるヒアリング

Q&Aリスト

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

メール管理システム(Mailman、

Majordomo、fml、Popper)

プロセス改善へのフィードバック

CCFinderX

＇コードクローン分析機能（

プロジェクトデータMagi

＇協調フィルタリング分析機能（

スキルデータスキル分析

トレーサビリティの確保ソフトウェアタグへの格納

ソースコードの規模推移

障害状況の分析

ソースコードの変更状況

チェックシート分析結果

012345

品質

人的資源

コミュニケーションリスク調達

012345

統合スコープ

タイム

コスト

品質

人的資源


顧客

技術

組織

基本動作


課題管理

実証２



012345統合

スコープ

タイム

コスト

品質

人的資源


顧客

技術

組織

基本動作


課題管理Company A

Company B

Company C

Company D

Company E

Company F

012345統合

スコープ

タイム

コスト

品質

人的資源


顧客

技術

組織

基本動作


課題管理

012345統合

スコープ

タイム

コスト

品質

人的資源


顧客

技術

組織

基本動作


課題管理

012345統合

スコープ

タイム

コスト

品質

人的資源


顧客

技術

組織

基本動作


課題管理

012345統合

スコープ

タイム

コスト

品質

人的資源


顧客

技術

組織

基本動作


課題管理

012345統合

スコープ

タイム

コスト

品質

人的資源


顧客

技術

組織

基本動作


課題管理

自己診断

ヒヤリング

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



ベンチマークデータベースの協調フィルタリングによるプロジェクト予測

類似度の分布

0102030405060708090

100

0.9

～1.0

0.8

～0.9

0.7

～0.8

0.6

～0.7

0.5

～0.6

0.4

～0.5

0.3

～0.4

0.2

～0.3

0.1

～0.2

0.0

～0.1

類似度の値域

度数

多量の欠損を含む過去データベース

400項目超のデータ項目1009

プロジェクト

新しいプロジェクトのプロジェクト途中までのベンチマークデータ計画値：プロジェクトの一般的な特性、開発稼動予定、など…

実績値：プロジェクト途中までの実績稼動など

ベンチマークデータベースの協調フィルタリング

欠損を含むベンチマークデータベースから類似データセットを抽出

プロジェクト途中までのベンチマークデータを入力し、過去データベースから類似プロジェクトグループを抽出、その属性からプロジェクトの将来を予測する.

類似プロジェクト抽出＇イメージ（

類似度分布頻度

類似度

当該プロジェクトの将来予測

SEC 定量データ＇ベンチマークデータ（ベースベンチマークデータベースの協調フィルタリング実証２



情報サービス産業協会ＥＰＭ検証ワーキング:JISA2007-2009

PMO支援への大きな可能性と共にツールへの課題が明らかに

SEC journal: SEC サイトから丸ごとDL可。最近号はJ-Stageから記事ごとDL可。

実証３



PMOによる全社フォローアップ計画例開発プロジェクトプロジェクト管理部生産技術部全社インフラ

情報サービス産業協会ワーキンググループによるEPMツール検証プロジェクトの推進：SEC journal 15,pp.48-53

プロジェクト生産活動

ソースコード

プロジェクト定性評価

ドキュメント懸案B票

作業時間

経費

経費定量評価レポート

ソースコード

インスペクション結果

プロジェクト管理ツール

WBSによる管理

経営管理システム

経費面からのプロジェクト定量評価

ソースコード構成管理ツール

B票発行／消化数ドキュメント

チェックイン／チェックアウト状況

懸案発生／消化数

コードインスペクション

ツール

EPM 成果物変更管理モニタ

ソース変更状況進捗状況

ソースコードステップ数

チェックイン／チェックアウト数

ドキュメント変更状況

成果物からのプロジェクト定量評価

成果物からのプロジェクト定量評価結果

プロジェクトフォローアップ＇月次（

プロジェクトフォローアップ結果

実証３



「見える化」本まとめ

プロジェクトの見える化を体系化

上流・中流・下流工程をカバー

すぐに使えるツールを提供

ITプロジェクトの問題を

タイムリーに見える化することで、プロジェクト

成功率を高めよう

プロジェクト問題の早期発見と早期解決



機能構成図：Diamond Mandara Matrix (DMM) 記述例

情報機能関連図：Data Flow Diagram (DFD) 記述例

業務流れ図：Work Flow Architecture (WFA) 記述例

実体関連ダイアグラム：Entity Relationship Diagram (ERD) 記述例

村上敬亮：Enterprise Architectureについて，～これからのＩＴガバナンスと情報サービス産業～，経済産業省，2004.1.19.

要求定義工程：EAダイアグラム例



要素数推移

0

5000

10000

15000

20000

25000

30000

35000

9/29 10/13 10/27 11/10 11/24 12/8 12/22 1/5 1/19 2/2 2/16 3/2 3/16

要素数

要素

月日

ＡｓＩｓ図面の記述

見直し・最適化計画作成

ＴｏＢｅ図面の作成

ＥＡダイアグラムの記述要素数計測例



ＥＡダイアグラム記述量計測例＇シート数（AsIs(Sheet) ToBe(Sheet)＇枚数（＇枚数（

省庁の業務システム最適化計画パブリックコメントのためのＷｅｂサイト公開例(除：IPA)



UMLの記述要素＇クラス図の例（

属性操作依存汎化計3 2 1 0 62 0 1 0 30 0 0 0 02 1 0 0 33 2 1 1 71 0 0 1 20 0 0 0 011 5 3 2 21

CustomerCorrporate CustomerPersonal CustomerEmployee計

クラス名OrderOrderLineProduct

記述対象ＵＭＬダイヤグラム計測対象

システムの振る舞いユースケース図ユースケース、包含、拡張、アクター

アクティビティ図アクション、フロー、フォーク、ジョイン、シグナル、判断・マージ

シーケンス図オブジェクト、メッセージ

システムの構造クラス図依存、汎化、属性、操作



ＵＭＬ要素数計測例

0

100

200

300

400

500

600

700

800

900

1000要

素数

時間

クラス図の要素数の推移＇3/11～4/14（

クラス

属性

操作

依存

汎化



ソフトウェア開発全工程一貫計測モデル

企画要件定義基本設計

詳細設計

プログラム設計製造試験維持管理

上流工程調達下流工程調達調達方式例

開発工程

基本アーキテクチャ決定下流工程調達用内部見積もり

実証研究例 IPA業務・システム最適化計画

IPA/SEC実証研究UMLツールレポート機能

MSR研究

EA方式ダイアグラム記述量推移の計測

UMLダイヤグラム記述量推移計測

EPMツール群によるインプロセスのプロジェクトとプロセスの計測

研究多数

Mining

SoftwareRepository

サービス開始

計測モデル



コンパクトなコンテンツESxR

P4



P20

V字モデルと開発プロセス



P22,23

プロセス定義書システム・エンジニアリング・プロセス：システム要求定義



P203,

P207

共同レビュー記録例、不具合管理票例



品質評価指標と基礎指標

P54



品質評価指標P56,57



P135



P137

P142

コミュニケーション、ドキュメントに関するチェックとヒント



チェックとヒント



レビュー、テスト、指標に関するチェックとヒント

P148

P153

P159



コンパクトなアプローチ




実践の場

プロジェクト


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

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

よるリスクの見える化

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

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

仕組み

事例集

リスク分類表

チェックシート

俯瞰図

自動計測ツールEPM

モデリング得意

チェック項目

品質指標一覧



見えてどうするの！

品質の測定と予測

P11



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

P14



品質予測モデル

閾値モデル

ゾーンモデル

関数モデル

トレンドモデル

チェックリスト

P17-19



品質予測の実際

要求分析・設計における品質予測

プロダクトの品質の予測

プロジェクトの品質予測

P28-



レビュー指摘密度の管理

要求分析・設計における品質予測

P44



品質評価グラフ

プロダクトの品質の予測

P60



プロジェクト品質予測

プロセスパフォーマンスベースラインの活用P82



必須となる記録項目＇例（P96,97



さらに、続編、パブコメ吸収中、今年度出版予定

Ｉ．上流工程で定量的品質管理を行うためのアプローチＩＩ．定量的品質管理に一歩を踏み出すためのアドバイス

A4、全130ページ

SECサイトからDL可



2種のプロジェクトデータベースを用いた協調フィルタリングによるプロジェクト予測

協調フィルタリング

類似度の分布

0102030405060708090

100

0.9

～1.0

0.8

～0.9

0.7

～0.8

0.6

～0.7

0.5

～0.6

0.4

～0.5

0.3

～0.4

0.2

～0.3

0.1

～0.2

0.0

～0.1

類似度の値域

度数類似度分布頻度

類似度

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

過去のベンチマークデータベース

EPM,CCF…

進行中のプロジェクト計測

プロセスとプロダクトのデータベース

新規プロジェクト

途中までのベンチマークデータ

ベンチマークデータベースからのプロジェクト予測

プロセスとプロダクトデータからのプロジェクト予測

ベンチマークデータの収集

2

1

3

4

56

7

8

9

7

進行中のプロジェクト運営への反映

5

7

プロセスとプロダクトの計測データベースを活用する手法の提案

神谷ほか、進行中のプロジェクト計測とフィードバック実験に基づく計測データベース活用方式の提案ソフトウェアエンジニアリングシンポジウム２００６(SES 2006)、2006-10、 pp35-42



ソフトウェアタグ＇追跡性の研究（

StagE プロジェクトWebサイト



見える化施策の統合

プロジェクト履歴

可視化情報

情報フィルタリング

ベンチマークデータ

ソフトウェアタグ

説明性・追跡性の確保

ベンチマーキング

プロセス改善

定量的アプローチ俯瞰図チェックシート失敗事例集

リンク表

統合的アプローチソフトウェア開発プロジェクト

定量的アプローチ

測定分析データ一覧表開発管理レポジトリ

中間データ (XML)

構成管理履歴

障害票履歴メール情報ソフトウェア開発環境

構成管理システム. 障害追跡システム. メールシステム.

アナライザ

自動計測

プロジェクト管理

インプロセス計測

Empirical Project Monitor:EPM

ソフトウェア開発プロジェクトの「見える化」



IPA/SEC活動の意義：稀有の知的生産物のオープンな大量集積

見える化本：

機能要件の合意形成ガイド：全679ページTIPS集

毎月1,000件を超すダウンロード

非機能グレード表：A3-35枚、樹形図9ページ

活用シート 230行毎月 2,000件超のダウンロード

データ型書籍：

共通フレーム：325ページ

データ白書＇毎年（：353ページ

事例集積型書籍

実務に活かすIT化の原理原則：24事例解説

プロセス改善ナビゲーションガイド：10事例解説

超上流から攻めるＩＴ化の事例集：6社事例詳説、成果文書9件、サンプルドキュメント：500ページ超

ソフトウェア開発見積りガイド：10事例

続：定量的品質予測のすすめ：Ｑ＆Ａ型解説

ソフトウェアエンジニアリングの実践：先進プロジェクト詳説

組込みソフトウェア：書籍体系：ESxRシリーズ

特殊解の羅列ではない。再利用可能なようにある程度の一般化と懸命の分類整理。「網目」を構成し全体で解を提示。活用には自己の文脈へのマッピング、ブレークダウン、テーラリングが必要。自己の計測、データ蓄積が必要。



SECアウトプットの「網目」例

共通フレーム2007

＇計測（

見える化本

ＥＰＭ：インプロセス計測

ポストプロセス計測・・・ベンチマーキング

データ白書

定量的品質予測のすすめ

続：定量的品質予測のすすめ

実務に活かす原理原則17ヶ条

原理原則17ヶ条

機能要件の合意形成ガイド

非機能グレード表

英訳版

組込みソフトウェアESQR,ESPR

ETSS

ソフトウェアエンジニアリングの実践



実践型科学的プロジェクトマネジメントのすすめ

統合マネジメント

スコープマネジメント

タイムマネジメント

コストマネジメント

品質マネジメント

組織マネジメント

コミュニケーションマネジメント

リスクマネジメント

調達マネジメント

ソフトウェア要求

ソフトウェア設計

ソフトウェア構築

ソフトウェアテスティング

ソフトウェア保守

ソフトウェア構成管理

ソフトウェアエンジニアリングマネジメント

ソフトウェアエンジニアリングプロセス

ソフトウェアエンジニアリングのためのツールおよび方法

ソフトウェア品質

(※SWEBOKの知識領域参照)

(※PMBOKの知識領域参照)

ソフトウェアエンジニアリングプロジェクトマネジメント

EVM(Earned Value Management)

WBS(Work Breakdown Structure)

SECの実践的活動

定量データ収集・分析・応用

実践的な見積もり手法

ビジネス・プロセス改善

人材スキル標準

プロジェクトの見える化

科学的プロジェクトマネジメント

モダンプロジェクトマネジメント

実践型科学的プロジェクトマネジメント

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

Software Engineering CenterCopyright© 2010 Information-technology Promotion Agency, Japan. All rights reserved.

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

本セミナに関するお問い合わせはＳＥＣＷｅｂサイト※の左下

「ＳＥＣへのお問い合わせ」からお願いいたします

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

『SECセミナ』と明記してお問い合わせください

Documents

「ITプロジェクトの見える化」 - IPA · 2020-01-17 · ITプロジェクトを取り巻く問題について ... 20人弱の委員会：pm ... ⇒見える化手法の期待が高い