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

Size: px

Start display at page:

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

しじんちゃわんや
5 years ago
Views:

1 Software Engineering Center Information-technology Promotion Agency, Japan ソフトウェアジャパン 2013 IT フォーラムセッション IPA/ 2013 年 02 月 15 日ソフトウェア開発データの見える化に基づく定量的プロジェクト管理独立行政法人情報処理推進機構技術本部ソフトウェアエンジニアリングセンター研究員大和田裕 Copyright 2013 Information-technology Promotion Agency, Japan. All rights reserved.

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

3 IT プロジェクトの実状要求の多様化高度化リスクの増大インフラ基盤としての高信頼性の要求レポーティング市場競争の激化ビジネスモデルの革新開発の多様化高機能化開発の短期間化低コスト化法対応リスク対策などの社会的要請信頼できるマネジメント効果的な進捗障害管理品質確保トラブル未然抑止高難易度となったプロジェクトマネジメント作業を遂行するためのが必要 2

4 IT プロジェクトの見える化期限どおりに所定の費用で求められる品質のソフトウェア開発を行うには様々な問題を早期に発見し解決していくためのITプロジェクトのが必要となるマネジメントプロジェクト一歩進んだ 3

5 見える化が対象とする工程ライフサイクルプロセス保守見える化運用 V 字モデル 4

ネガティブなインパクトを最小にすることは容易ではない課題プロジェクトの不十分な状態を把握するための定性的定量的な見える化が必要

6 上流工程要件定義システム設計ソフトウェア設計プログラミングソフトウェアテストシステムテスト運用テスト問題認識納期までの切迫感の欠如要件の曖昧さ成果物の見えにくさ所詮見切り発車プロジェクト稼働後に様々な問題を惹起するリスクを予知しネガティブなインパクトを最小にすることは容易ではない課題プロジェクトの不十分な状態を把握するための定性的定量的な見える化が必要問題の潜在箇所早期に発見する不確定な要素いつまで不確定で良いかを評価し判断するこのような状況を乗り切ってきたスーパー PM の暗黙知を形式知化することが必要 5

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

7 中流工程要件定義システム設計ソフトウェア設計プログラミングソフトウェアテストシステムテスト運用テスト問題認識先立つ上流工程での要件定義が曖昧なままプログラムへの変換作業が進められる多くの要件 ( 仕様 ) 変更とトラブルの多発多くのベンダー技術者による分業となり個人への作業依存が高くなる進捗品質がばらつきやすいプロジェクトの透明性が著しく悪化し管理が難しい課題要件の曖昧さを把握し是正する見える化が必要機能要件非機能要件要件 ( 仕様 ) 変更への対応進捗品質のばらつきを把握し是正する見える化が必要 6

8 下流工程要件定義システム設計ソフトウェア設計プログラミングソフトウェアテストシステムテスト運用テスト問題認識それまでの工程に起因する品質不良が一気に露呈問題に対応するための時間や手段が限定されるという宿命課題失敗しそうなプロジェクトを救う活動が重要問題の早期発見迅速な処置のための見える化が必要問題を起こす品質不良の原因は多様なため見える化手法の工夫が一層重要 7

9 見える化の方向プロジェクトの状態を把握するために KKD( 勘と経験と度胸 ) だけではなく定性的定量的なアプローチが必要カリスマプロジェクトマネジメントの暗黙知を形式知にしていくことでプロジェクトマネジメント力の向上を図る野中郁次郎竹内弘高知識創造企業 KKD ( 暗黙知 ) 状況を的確に掴むためのチェック項目の検討網羅性のある観測すべき項目の検討嘘をつかない定量データの収集方法と活用方法の検討 8

10 3 つの見える化アプローチ俯瞰図チェックシート ( 自己評価シート / ヒアリングシート ) 定性的見える化アプローチ事例集俯瞰の視点によるドミナントアイテムの見える化測定分析データにしたがって定量化した情報によるリスクの見える化実践の場プロジェクトチェック項目によるリスクの見える化見える化アプローチをひも付けることによる総合的判断の仕組みリスク分類表統合的アプローチ測定項目リスト測定分析データ一覧表ベース尺度一覧表支援ツール定量的見える化アプローチ 9

11 見える化参照 URL 10

12 IT プロジェクトの見える化 < 定性的見える化アプローチ > 11

13 俯瞰図上 / 中 / 下流 :6/7/4 例提示木を見て森を見ず弊害の排除ドミナントアイテム 1 を継続的システム横断的に把握変更が生じたら直ちに修正 1 プロジェクトの成否を左右する支配的要因ステークホルダー俯瞰図プロジェクト推進体制俯瞰図周辺システム構成俯瞰図システム構成俯瞰図スケジュール俯瞰図要員遷移俯瞰図マスコミ協力会社 PM メンバー営業経営者発注側の株主先方キーパーソン決定権を持っている技術面業務面におけるキーパーソン経営者発注側 GM PM 担当者プロジェクトプロジェクトマネージャスタッフメンバー営業発注側の顧客受注側営業共通 GM 12

14 ステークホルダ俯瞰図の例 ( 病院システム ) 13

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

チェックシートプロジェクトマネジメントの要点を再確認客観的視点でのチェックによる見落としの排除リスクの明確化自己評価ヒアリング評価課題管理モチベーション自己評価とヒアリングレーダチャート統合 5 4 3 スコープタイム 4 3 2 自己評価とヒアリング評価のスコアの乖離 P M が悲観的

16 チェックシートプロジェクトマネジメントの要点を再確認客観的視点でのチェックによる見落としの排除リスクの明確化自己評価ヒアリング評価課題管理モチベーション自己評価とヒアリングレーダチャート統合スコープタイム自己評価とヒアリング評価のスコアの乖離 P M が悲観的基本動作組織技術顧客調達コスト品質人的資源コミュニケーションリスク統合スコープタイムコスト品質人的資源コミュニケーションリスク調達顧客技術ヒアリング評価 - 自己評価組織基本動作モチベーション課題管理 P M が楽観的 15

17 自己診断シートによる見える化自己評価シート : プロジェクトマネージャによる自己評価 ( 上流 :35 中流 :38 下流 :40 項目 ) 自己チェックによる気付き集計表示ツール付き現場リーダ向け 3 段階評価所要時間 40 分程度 16

18 ヒアリングシートによる見える化ヒアリングシート : 専門家チーム (PMO) によるヒアリング ( 上流 :74 中流 :78 下流 :85 項目 ) 専門家からの客観的チェック集計表示ツール付きベテランが現場リーダから聞き出すエビデンス資料要求 5 段階評価所要時間 2 時間 + 17

19 チェックシートによる見える化自己評価と専門家の診断の差専門家からの対策案を提示マネジメントの過不足を把握し対策を検討 18

20 失敗事例集上 / 中 / 下流 :58/58/77 事例失敗から学んで失敗を防止リスクを内在させたままでの見切り 1 方法捉えるべき兆候 1 プロジェクトマネージャが得られる限りの情報を駆使し最悪の場合も見極めて自己責任のもとで選択する問題発生の典型パターンプロジェクトマネジメントの問題要件定義開発範囲にかかわる問題システム設計構築技術にかかわる問題ステークホルダーにかかわる問題モチベーションにかかわる問題 19

21 事例 : 本当のユーザを見誤ってしまう情報システム部門からの要請によるシステム構築であり情報システム部門と契約し開発を進めていたそのため顧客内部のユーザ部門と情報システム部門に対立があったようだが発注者である情報システム部門主導でのシステム仕様を進めていたいざ実装してユーザー部門での利用が始まると操作性や仕様に関しての問題が相次ぎ仕様変更対応に追われ予定通りの本番稼働が出来なくなった事例における見切り内容 : ユーザ部門からの旧システムに対する問題提示や新システムへの要求等が上がっていたがあまり議題に取り上げることなく情報システム部門主管で仕様決めを行った本来はユーザ部門側からも仕様検討者がいるべきではあるが顧客企業の情報システム部門ということで特に仕様に関しては問題ないだろうと思っていた捉えるべき兆候 : システム機能の話ばかりで業務レベルの検討を実施しようとしない先方の体制にユーザ部門が入っていない情報システム部門がユーザ部門との打ち合わせの場を持ちたがらないユーザ部門への質問を情報システム部門で制限をかけようとする 20

22 IT プロジェクトの見える化 < 定量的見える化アプローチ > 21

23 測定項目リスト上 / 中 / 下流 :78/84/70 項目総集編に全工程導出尺度一覧プロジェクトの状況を定量的に把握するための測定項目測定分析データ一覧表測定項目ごとの測定方法分析方法を整理例 ) 要件定義書のレビュー進捗率ベース尺度一覧表測定項目を測定する際のベースとなる定量情報例 ) レビュー計画書のレビュー計画回数計画所要時間要件定義書のレビュー実施回数累積時間 22

24 見える化のための測定分析項目 (1/2) スコープ :( 上流工程重点測定項目 ) 測定の目的 : 要件の総数から計画時点の規模と比較して要件の規模と変動を把握する確定していない要件の規模と変動を把握する導出尺度 : 計画時点の要件数発生要件数の推移確定要件数の推移未確定要件数の推移未確定要件数 = 発生要件数累計 - 確定要件数累計タイム :( 上流工程 ) 測定の目的 : 要件定義作業の進捗を把握し計画との差異を確認する導出尺度 : 要件定義完成したドキュメントのページ数の推移コスト :( 全工程重点測定項目 ) 測定の目的 : コストの消化状況を見るコストが計画を超えていないかを見る当初計画にない対応をとる場合に予算内でとれるコストを見る導出尺度 : 予算使った金額残っている金額 = 予算 - 使った金額品質 :( 全工程 ) 測定の目的 :[ 保守性移植性 ] 要求定義プロセスにおける標準順守の度合いを把握する標準に準拠する項目数の度合いをもとに評価する導出尺度 : 要件定義プロセスでの標準順守率 = 順守している項目数 / 順守すべき標準項目数ここでの標準の意味 ; 要件定義レビュー計画書要件定義書レビュー基準要件定義フォーマット要件定義書記入要領人的資源 :( 上流工程 ) 測定の目的 : 要件定義工程における体制の強弱を測定する導出尺度 : 要件定義スキル (IT コーディネータ ) の保有率 =IT コーディネータ相当のスキル保有者数 / 要件定義メンバー数コミュニケーション :( 上流工程で準重点測定項目全工程で計測 ) 測定の目的 : 各委託先部門とのコミュニケーションが取れているか測定導出尺度 : 複数委託先 ( 協力会社 ) 部門の体制階層数会社数 ( 部門数 ) 開発拠点数 ( チーム毎の作業場所数 ) 報告書の提出数 23

25 見える化のための測定分析項目 (2/2) リスク :( 上流工程で準重点測定項目中流工程で重点測定項目 ) 測定の目的 : リスク全体をスポットで計測しトップマネジメントに活用導出尺度 ; 重要度発生確率緊急度対応策有無のマトリックスモチベーション :( 上流工程で準重点測定項目中流工程下流工程で重点測定項目 ) 測定の目的 : 要員毎の予定労働時間に対する労働時間など勤務状況により ( 極端な労働時間の増加 ) などモチベーションに影響を与える要因を測定する導出尺度 : 要員毎の労働時間 / 予定労働時間残業時間 / 予定残業時間組織 :( 上流工程重点測定項目 ) 測定の目的 : 要件定義書が組織としてレビューされているか測定する導出尺度 : 要件定義書のレビュー達成率 = 要件定義書のレビュー実施回数 / 要件定義書のレビュー計画回数要件定義書レビューのメンバー参加者数 / 要件定義書レビューの参加計画者数課題管理 :( 上流工程で準重点測定項目中流工程下流工程で重点測定項目 ) 測定の目的 : 課題発生数対応数を測定し課題完了状況を把握する導出尺度 : 課題発生の推移課題対応数の推移未解決課題数の推移未解決課題数 = 課題発生数累計 - 課題対応累計技術 :( 上流工程で計測中流工程で重点測定項目 ) 測定の目的 : キャパシティプランニング実施の有無を測定する導出尺度 : キャパシティプランニング実施の有無顧客 :( 上流工程重点計測項目 ) 測定の目的 : 要件定義工程における顧客の要件定義業務経験者率を測定する導出尺度 : 要件定義工程における顧客の要件定義業務経験者率 = 要件定義業務経験者数 / 顧客の要件定義メンバー数 24

26 IT プロジェクトの見える化 < 総合的見える化アプローチ > 25

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

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

28 ヒアリングから失敗事例へリスク分類表リンク事例 6 件知識エリアリスク分類チェックシート測定分析データ一覧事例業務有識者 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 ヒアリングシート No. 知識エリアチェック項目 H28 人的資源求められる業務知識のキーパーソンを獲得できているか? 事例集事例 11 業務経験業務知識の乏しい要員で要件定義工程を実施要件定義に必要な要員の人数は確保できたのでプロジェクトをスタートした担当者に業務知識がなく要件定義は日を追うごとに遅れていき成果物の品質もきわめて低いものとなってしまった 27

29 ヒアリングから測定データへリスク分類表知識エリアリスク分類チェックシート測定分析データ一覧事例業務有識者 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 ヒアリングシート No. 知識エリアチェック項目 H28 人的資源求められる業務知識のキーパーソンを獲得できているか? 測定分析データ一覧項目番号知識エリア ( 主 ) 知識エリア ( 関連 ) 測定の目的利用者導出尺度 H2 人的資源要件定義工程における体制の強弱を測定する PM PMO 要件定義工程における対象業務分野 ( 小売業とか保険業とか ) の経験者率対象業務分野経験者数 / 要件定義メンバ数 28

30 失敗事例からヒアリングへリスク分類表知識エリアリスク分類チェックシート測定分析データ一覧事例未経験技術 H74 Te2 14,26,28,31,33,48 技術標準化検討システム実現方式検討事例集移行パッケージ事例 14 初物プログラム言語での開発で十分な性能が出ないユーザ側からまだ市場に出て日が浅いプログラム言語を使っての開発を指定されたその顧客はそのベンダー側にとっては重要な顧客であったためどうしても受注したかったそのプログラム言語での実装を行ったが十分な性能要件を満たすことができなかったヒアリングシート No. 知識エリアチェック項目 H74 技術新技術 / 未経験技術がある場合その技術に対する対応策は十分か? 29

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

32 IT プロジェクトの実状要求の多様化高度化リスクの増大インフラ基盤としての高信頼性の要求レポーティング市場競争の激化ビジネスモデルの革新開発の多様化高機能化開発の短期間化低コスト化法対応リスク対策などの社会的要請信頼できるマネジメント効果的な進捗障害管理品質確保トラブル未然抑止高難易度となったプロジェクトマネジメント作業を支援するが必要 31

33 開発の多様化短期間化低コスト化開発フレームワーク開発ツールを利用既存アプリケーションの再利用変更 / 追加部分のみの開発機能アプリケーションの分割開発外部発注開発オフショア開発プロジェクトの状況把握が困難品質がバラつき全体品質管理が困難問題解決の判断遅延定量的なデータに裏付けられた網羅的統一的なプロジェクトマネジメントが必要 32

34 定量的管理の課題定量データの収集に工数がかかるため進行中プロジェクトの定量的診断が行えない定量データの自動収集日次業務での定量データの収集を可能に定量データ分析のノウハウが乏しく手間がかかりプロジェクト遅れ予測などを簡単に行えない統計グラフ描画による視覚的直観的な分析診断定量的プロジェクト管理ツールに実装プロジェクト管理機能と定量的分析診断機能を一体で提供 Excel 等のデータをインポート管理するツールの環境が整っていない各プロジェクトで個別の Excel などを使用データを蓄積による社内基準値の作成プロジェクトを定量的に診断するための基準値を持っていない 33

35 定量的プロジェクト管理の業務 KKD( 勘経験度胸 ) からツールによるに基づいたプロジェクト管理へ版管理 ( ソースコード ) 課題管理 ( 障害課題 ) 進捗管理 ( 計画と実績 ) 定量的プロジェクト管理ツールソース規模の推移定量データ工程別の障害件数不良発生原因発生箇所計画値との比較による進捗システムのの取得ソースを課題や進捗を対策計画診断実施課題の把握プロジェクトの進捗を課題の把握将来進捗をの作成プロジェクト計画値の 34

36 定量的プロジェクト管理ツールとはプロジェクトタスクの進捗, 課題障害の解決状況, 工数等の把握を定量的データにより行い中小規模プロジェクトでのするツールタスク収集進捗障害課題工数集計定量的データの収集定量的プロジェクト管理ツールプロジェクトの可視化グラフ化要員負荷管理複数プロジェクト俯瞰タスク品質管理可視化障害課題管理 35

定量的プロジェクト管理ツールの特徴グラフ表示による視覚的直観的な分析診断機能の提供ダッシュボード表示ドリルダウン

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

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

37 定量的プロジェクト管理ツールの特徴グラフ表示による視覚的直観的な分析診断機能の提供ダッシュボード表示ドリルダウンドリルスルー表示利用者によるグラフカスタマイズ定量的データの自動収集プロジェクト管理ツール構成管理ツール日常使用ツールからの日次業務データの取り込み Excel, MS Project, CSV 等からのデータ収集既存ツールを活用 Redmine Trac Subversion GIT BIRT(BI ツール ) Pentaho(ETL ツール ) ツールが簡易に利用できることを重視基本測定量 ( 規模工数工期品質 ) に絞って提供高度で複雑な利用方法は将来の拡張柔軟性拡張性の確保利用者による定量データの追加など全環境を導入できる一括インストーラを提供オープンソースとして公開 (GPL) 36

38 定量的プロジェクト管理ツールの概要図プロジェクト管理支援機能データ収集集計起動定量的分析診断呼出プロジェクト管理プラットフォーム (Redmine,Trac,Subversion,GIT) 設定管理機能プロジェクト管理プラットフォームチケットデータ収集機能 ETL ツール (Pentaho) 定量データデータ集計機能複数プロジェクト俯瞰表示機能プロジェクト俯瞰表示機能個別グラフ表示機能グラフ表示データ BI ツール (Eclipse BIRT/BIRT Report Viewer) 37

39 チケットとは担当者が割り振られその作業に登録, 担当者割り当て, 作業中, 完了などの状態がある作業作業指示書報告書チケットの利点開発者は自分に割り当てられているタスクやリスクを明確に知ることができる開発者は割り当てられたチケットの必要項目に入力するだけなので作業報告を省力化できる管理者は進捗やリスクについての収集作業を省力化できる 38

40 WBS チケット 39

41 チケット入力 40

42 障害課題チケット 41

43 チケットの一覧 42

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

45 表示グラフ一覧 WBS( タスク ) 品質管理試験計画項目密度 WBS 進捗推移 WBS 進捗変化 EVM 評価 ( 進捗工数 ) ソフトウェア規模推移試験進捗率工数の予実遅延重要タスク抽出障害課題管理障害件数変化障害解決予測障害原因分析障害発生密度障害滞留状況長期未解決課題抽出要員負荷管理負荷状況プロジェクトを俯瞰するグラフ定量管理ダッシュボード複数のグラフを縮小表示してプロジェクト状況を俯瞰複数プロジェクトを俯瞰するグラフ複数プロジェクトの進捗確認健全性確認 44

46 画面レイアウト共通機能グラフ表示領域ナビゲーション領域 HIDE/SHOW で切替 45

47 共通機能操作バーパラメータ変更 - 期間変更閾値エクスポートファイル出力 -PDF,Word, PowerPoint 印刷パンくずリスト表示領域 46

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

49 定量管理ダッシュボードの例ユーザ ID を指定自分が受け持っているプロジェクトを選択遅延重要タスク抽出の件数が多い遅れているタスクの詳細を確認する必要がある遅延重要タスク抽出のグラフで原因を追究 ( ダブルクリック ) 48

50 WBS( タスク ) 品質管理のグラフ (1/4) 試験計画項目密度試験項目のカバレッジを確認する試験進捗率試験項目がモジュールごとにどの程度消化されているかを示す 49

51 WBS( タスク ) 品質管理のグラフ (2/4) WBS 進捗推移過去の進捗の進み具合を描画し開発の進み具合を把握する WBS 進捗変化最近の開発進行度 ( 変化分の大きさ ) を確認する 50

52 WBS 進捗管理の例 (1/2) WBS タスク :IPF 開発プロジェクト表示期間 :2012/06/09-08/09 スケール : 週プロジェクトの終了予測日が大幅に予定を上回っているプロジェクトのどの工程が遅れているのかの確認が必要ドリルダウンして下位タスクのグラフで原因を追究 ( ダブルクリック ) 51

53 WBS 進捗管理の例 (2/2) XXX-1 製造は予定どおり終了している XXX-2 製造が大幅に遅れている XXX-2 製造タスクが遅れている原因の調査が必要 52

54 WBS( タスク ) 品質管理のグラフ (3/4) EVM 評価 EVM により最近の開発価値とコストを把握するソフトウェア規模推移ソース行数による規模の推移及び計画値との対比を行う 53

55 ソフトウェア規模推移の例 WBS タスク : プログラム製造表示期間 :2011/8/1-10/31 スケール : 週プログラム製造は順調に進み予定通り 8/30 の週に完了 9/13 の週に修正が行われた障害による修正と想定スケジュールと照らし合わせ計画された工程内かを確認想定外であれば調査 54

56 WBS( タスク ) 品質管理のグラフ (4/4) 工数の予実開発工数の予実把握を行い完了時の工数を予想する遅延重要タスク抽出開発が遅れている WBS( タスク ) を抽出する 55

57 障害課題管理のグラフ (1/3) 障害件数変化課題の件数未解決数の推移計画値との対比を把握する障害解決予測課題の未解決数と解決生産性から解決完了日を推定する 56

58 障害課題管理のグラフ (2/3) 障害原因分析現在の障害の数を原因別に分類する障害発生密度どのモジュールの品質が悪いのか把握する 57

59 障害原因分析の例 (1/2) WBS タスク : IPF 開発プロジェクト製造でのコーディングミスが 30 件で一番多い未解決は 1 件のみなので対応は進んでいる試験進捗率障害件数変化のグラフで状況を確認 58

60 障害原因分析の例 (2/2) 製造の設計との不一致の件数も多いかつ 4 件の未解決障害が残っているプロジェクトへの影響が大きい可能性が高い詳細の確認が必要障害タスク一覧表示で問題タスクを追究 ( ダブルクリック ) 59

61 障害課題管理のグラフ (3/3) 障害滞留状況長期間解決されていない障害を抽出する長期未解決課題抽出長期間解決されていない課題を抽出する 60

62 負荷管理のグラフ負荷状況開発グループ / 開発者の負荷を把握する 61

63 複数プロジェクトを俯瞰するグラフ複数プロジェクトの進捗確認担当プロジェクト / サブプロジェクトでリスクのあるものを検出する複数プロジェクトの健全性確認担当プロジェクト / サブプロジェクトのリスクを俯瞰する 62

64 複数プロジェクトの健全性確認では判定基準閾値 ( 健全 ):10% 判定基準閾値 ( 危険 ):20% 障害滞留日数 ( 健全 ):10 日障害滞留日数 ( 危険 ):20 日 SAMPLE プロジェクトは障害の発生件数と未解決件数が多く試験進捗率も悪いプロジェクト俯瞰障害原因分析のグラフで原因を追究 ( クリック ) 障害により試験の進捗が阻害されている工数超過は危険レベルではないが注意が必要 63

65 参照 URL

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

セミナータイトル　　～サブタイトル～

セミナータイトル　　～サブタイトル～ Software Engineering Center Information-technology Promotion Agency, Japan Redmine を利用した定量的プロジェクト管理 2011 年 9 月 8 日独立行政法人情報処理推進機構 (IPA) 技術本部ソフトウェアエンジニアリングセンター () 大和田裕 Copyright 2011 Information-technology

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

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