月次進捗管理サイクルのワークフロー - mhlw...・EV＜AC（CV＜0）...

5-8

月次進捗管理サイクルのワークフロー

月次進捗管理サイクルのワークフローを以下に示す。(図 5-3)

図 5-3 月次進捗管理サイクルのワークフロー

プロジェクト管理事務局

開発受託者

週次進捗報告書(全体)の整理

(2週間分)

月次進捗報告書(全体・中間)作成・提出

月次進捗報告書(全体)作成・提出

週次進捗報告書(全体)

週次進捗報告書(全体)

月次進捗報告書

(全体・中間)

月次進捗報告書(全体)

ＰＭＯ／ＰＪＭＯ

15日月末日

2週間分を取りまとめ

月次進捗報告書(全体・中間)承認

翌月5日

月次進捗報告書(全体)承認

20日

月次進捗報告書(個別)作成

月次進捗報告書(個別)

月次進捗報告書(個別)

中間報告

※中間報告は事務局が週次進捗報告書から作成し報告

月次報告

※月次報告は開発受託者からの月次進捗報告書(個別)をもとに事務局が月次進捗報告書(全体)を

作成し報告

プロジェクト責任者

プロジェクト全体管理者

月次進捗報告書(全体・中間)確認


(全体・中間)

月次進捗報告書(全体)確認



(全体・中間)


確認確認

5-9

5.4 留意事項

当標準に従い、作業を進めるにあたり留意すべき事項を以下に示す。

5.4.1 WBS 作成時の留意事項

（１） WBS の構造

・ある作業とそれを詳細化した下位の作業において、日付や出来高計画値(PV)の大きさに不整合が生

じないように設定する。

・下位作業における PV の合計は、その上位作業の PV に一致させる。

・下位作業の予定日付は、上位作業の予定日付の範囲内にする。

（２）対象とする作業内容

（ア） WBS に含める作業（例）

① 成果物作成に直接関わる作業

・アプリケーションの開発作業

・機器の導入・支援作業

② プロジェクトマネジメント上必要な計画、管理、支援などの作業

・インスペクション、レビュー

・テスト計画

・標準化

・開発・テスト環境の設定

・研修（ユーザに対する研修、開発スキル習得のための研修）

・共同レビュー（一般に事務局が主となり、開発受託者は支援の形となる）

・成果物の検収（主に事務局の作業であるが、開発受託者はこれを支援する）

（イ） WBS に含めない作業（例）

① 管理上の定常的な作業

・定例進捗報告等

※ただし、プロジェクト管理作業そのものを役割とする開発受託者や開発受託者内グループの作

業については、WBS に記述してもよい。

② WBS 上の各作業に作業量が組み込まれているもの

・チーム内のウォークスルーやインスペクション

5-10

5.4.2 EVM 管理項目設定時の留意事項

（１）出来高計画値(PV)を設定する場合

・価値の単位は工数（人日）とする。

・全ての作業項目に対して PV を割り当てる。

・割り当てた PV の合計が、計画総工数(BAC)と一致するように配分する。

（２）実績計上法を決定する場合

作業の性質（内容、工程）を考慮した上で、計上法を決定する。

・固定比率計上法

作業開始時と完了時のみ計上する。

・加重比率計上法

作業進捗に応じた比率で進捗を計上する。仕様作成からテストまでの一連の作業を一つの作業

として行う場合などに適する。

（３）計上比率を決定する場合（固定比率計上法の場合）

固定比率の場合は、作業の性質を考慮して、計上比率を決定する。以下に比率の例を示す。

・0:100

レビュー結果によっては作業のやり直しが発生する、要件定義やデザインなど

・30:70

比較的手戻りが生じにくい、開発実施段階など

＊基本設計工程においては、WBS のタスクが 1週間単位まで詳細化される場合は、固定比率計上法

0:100 を採用して管理する。

5.4.3 EVM を適用した場合の進捗状況の判断方法

（１）出来高計画値(PV)と出来高実績値(EV)及び投入実績値(AC)の差異について確認する。

（ア）確認するポイント

・EV 及び AC が PV から乖離していないか。

・スケジュール差異(SV：PV と EV の差異)及びコスト差異(CV：EV と AC の差異)が拡大傾向にな

いか。

・実績推移グラフより、PV からの乖離が拡大傾向にないか。

（イ）判断例

・PV＞EV（SV＜０）：進捗が計画より遅れている。差が拡大傾向にある場合は問題が収

束していないか大きくなりつつある可能性がある。

・EV＜AC（CV＜０）：進捗が計画工数を超過している。

・PV＝EV ：元の計画が甘い、または実績計上において十分な精度で集計され

ていない可能性がある。計画に問題が無いか、実績計上方法に問題がない

か確認する。

5-11

（２）スケジュール効率指数(SPI)及びコスト効率指数(CPI)の値と傾向を確認する。


・現時点での SPI、CPI は悪化していないか。

・実績推移グラフ上で効率が悪化する傾向にないか。

（イ）判断例

・SPI＜1.0 ：スケジュール効率が計画を下回っている。SPI が減少傾向にある場合は、作業

の進め方に問題が無いか確認する。

・CPI＜1.0 ：工数の消費効率が計画を下回っている。CPI が減少傾向にある場合は、工数

の投入の仕方に問題が無いか確認する。

（３）予測総工数(EAC)の値を確認する。


・開発プロジェクト完了時点での EAC は、計画総工数(BAC)内に収まっているか。

（イ）判断例

・EAC＞BAC ：終的に必要となる工数が計画時の予測工数を超過する場合は、スケジュー

ルが遅れる可能性がある。

（４）残作業時間(ETC)の値を確認する。


・開発受託者から報告された ETC は、完了まで投入可能な工数内に収まっているか。

（イ）判断例

・ETC＞完了まで投入可能な工数：終的に必要となる工数が完了まで投入可能な工数を

超過する場合は、スケジュールが遅れる可能性がある。

5.4.4 進捗のコントロールについて

遅延が発生した場合の対応方法について以下に示す。開発受託者は遅延が発生している場合、以下に示す

内容を進捗報告に含める。

（１）遅延箇所の特定

進捗報告にて遅延が報告された場合、その遅延に関して作業の実施者の観点及び成果物の観点か

ら層別分析を行い、遅延箇所を特定する。

実施者の観点からは、開発受託者全体－グループ－チーム－個人のように遅れの箇所を特定する

ための掘り下げを行う。成果物の観点からは、サブシステム－コンポーネント－作業成果物のよう

に掘り下げる。

5-12

（２）原因の追及

遅延箇所が特定された場合、作業に必要な入力情報が不十分なのか、作業実施の資源割り当てが

不十分なのか、変更が多いためか、過去の工程の品質のためか、人間的側面の問題か等、様々な側

面からその原因を見極める必要がある。同時に、同一要因による問題が発生していないか確認する。

（３）対策の策定と実施

遅延の原因が判明した場合、それらの問題を引き起こしている真の原因を明確にする。その上で

真の原因を取り除く。例えば、要員の増強、変更管理の徹底、レビュー方法の変更、入力成果物の

品質確認等。

6-1

6. 品質管理要領

品質管理の目的とは、開発プロジェクトに求められる品質基準を達成しつつ、成果物を完成させることで

ある。目的達成のために必要な管理手順を以下に示す。

6.1 品質管理とは

品質管理の考え方及び品質管理プロセスの概要を示す。

6.1.1 品質管理の考え方

要件定義は、要件を設計・開発段階に適切に引き継ぐための重要な工程である。そのため要件定義では、

庁の要件の内容が正しく設計書に反映され、システム利用者の視点から、システムの振る舞いが正しく明確

に定義されていることを確認する必要がある。

外部設計以降の工程では、前工程の設計書を元に設計・開発を進めるため、要件定義で除去できなかった

欠陥（例えば、機能の漏れ、要件の理解に関する不一致、外部インターフェースや開発受託者間インターフェー

スの不整合等）は、開発受託者間結合テスト以降の各テスト工程で発見され、多大な手戻り工数を発生させ

ることになる。従って、要件定義では、特に前述の観点から品質を管理することが重要である。

6.1.2 品質管理プロセスの概要

要件定義の品質管理プロセス概要を以下に示す。

図 6-1 品質管理プロセスの概要図

①目標設定：工程毎に品質管理の目標を設定し、開発受託者に提示する。

②計画策定：品質管理活動の計画を策定する。

③活動実施：品質管理活動の計画に従って、品質管理活動を実施する。

④評価：品質管理活動の結果得られるデータに基づき、成果物品質及び作業品質を評価する。

⑤対策実施：品質評価結果に基づき、対策の策定とその実施を指示する。

⑥品質目標達成確認：工程終了時に基本設計書が全体として品質目標を達成していることを確認する。

品質管理プロセス（プロジェクト管理事務局）

品質目標

成果物作成（開発受託者）要件成果物

品質管理活動（開発受託者）

目標設定

計画策定

評価

評価会議）

対策

実施

品質目標

達成確認

繰り返し

管理報告

開発受託者

活動実施

（レビュー）（品質

⑥⑤④③ ② ①

6-2

6.2 品質管理の詳細

品質管理の基本方針及び詳細な作業手順について示す。

6.2.1 品質管理の基本方針

（１）品質作り込みの実施プロセス

要件定義における品質の作り込みは、以下のプロセスで実施する。

（ア）レビューの計画と実施（図 6-1 の②③）

成果物納品前にも、受託範囲の品質管理状況を総括し、工程を完了できるかどうかを判定する

ため、品質評価を実施することとする。また、成果物作成手順とそれに従って作業した結果とし

ての成果物の両方をレビューして、問題点を洗い出す。

（イ）品質評価と対策実施（図 6-1 の④⑤）

レビュー報告書をもとに、品質データを収集･分析し、品質管理上の問題を発見し、問題の未然

防止策の展開及びレビュー計画の見直しを行う。

（２）品質作りこみの基本方針

開発受託者は以下の考え方に基づき、品質の作り込みを実現させる。

（ア）要求品質に対する理解の徹底

工程の立ち上げ時に、設計作業の成果物作成プロセスと作業品質を確認する事により、要求品

質に対する理解を徹底させる。初期においては、全ての成果物をレビューする。その結果に基づ

き、以降のレビュー計画を見直す。

（イ）適切なレビュー計画の策定

成果物の重要度に応じて、全件レビュー、サンプリング･レビュー、品質データによる確認など、

実情に応じたレビュー計画を策定する。

（ウ）レビュー計画の適宜修正

工程の立ち上げ後は、レビュー報告書のデータを基に品質の傾向を把握し、レビュー計画の内

容を必要に応じて変更する。

上記の方針をイメージ図で表現すると次のようになる。

6-3

①工程立ち上げ時に、作成プロセスと作業品質を確認。是正措置をとる。

②メリハリをつけたレビューの実施

F

0

1

2

3

4

5

6

7

8

5 15 25 35 45 55 65

F

0

1

2

3

4

5

6

7

8

5 15 25 35 45 55 65

○R

○○Q

○P

サンプリング全件成果物

○R

○○Q

○P

サンプリング全件成果物チェックリスト

作業プロセス品質

作業品質（＝成果物品質）

0

5

10

15

20

25

9/8

9/22

10/6

10/20

11/3

11/17

12/1

12/15

12/29

1/12

A

B

C

③品質傾向の把握と計画の見直し

レビュー計画の変更

外れ値に対する原因分析結果を基に早期に対策実施

レビュー報告書

基本設計工程

品質評価会議

図 6-2 レビュー実施の考え方

（３）レビューの視点

要件定義では、特に以下に示す観点からレビュー（欠陥除去活動）を実施する。

（ア）検証（verification）の視点

・機能の漏れがないこと

・要件が正確に反映されていること

・システム利用者の想定する操作性が反映されていること

・開発受託者間インターフェースが整合していること

・外部システム・インターフェースが整合していること

（イ）妥当性確認（validation）の視点

・システム方式設計が妥当であること

・共通化のレベルが妥当であること

・将来性の観点から妥当な技術が採用されていること

・保守性の観点から妥当な設計になっていること

（４）レビューの種類

要件定義に於ける品質確認と欠陥除去の方法は、以下の表に示す各種レビューによることを原

則とする。各レビューの特徴を以下に示す。

（ア）ピアレビュー

主として開発受託者のチーム内メンバー同士で実施する検査・評価のための検討会。設計者の

自己点検を目的として全体の品質や明晰さなどについて自主的に検査する。ウォークスルーをよ

り自由度をあげた形にしたもの。

6-4

（イ）ウォークスルー

欠陥の早期発見と除去を目的とした、より組織的で手順化された技術的検討会。レビュー報告

書の作成は義務づけず、参加者は内容の検討に注力する。作業ガイドや標準規約の理解と徹底、

担当者間の個人差をなくすなどの効果がある。

（ウ）インスペクション

成果物の品質点検と早期欠陥除去を目的として、設計段階の作業工程に組み込まれる少人数、

短時間のも効果的かつ経済的な方法。検査対象となる設計書を設計者自身が順を追って読み上

げ、その過程で参加者が欠陥を発見していく熟視テストである。

検査対象物の作成の前提となった仕様（例えば，要件定義書など）との綿密な比較、エラー発

見用のチェックリストの活用、レビュー報告書の作成、修正状況のトラッキングと再発防止のた

めの作業工程へのフィードバックなど、ウォークスルーよりも形式的に運営される。

インスペクションは、以下の 2つで構成される。

・インスペクション A：開発受託者内レビュー

・インスペクション B：事務局レビュー

上記のうち、ピアレビュー、ウォークスルー及びインスペクション Aについては開発受託者内で

実施するものとし、事務局が直接関わるのはインスペクション Bとする。ただし、必要と判断され

た場合は、事務局もインスペクション Aに参加する。

表 6-1 基本設計工程に於けるレビューの種類

レビュー

種類

ピアレビュー・

ウォークスルー

インスペクション A

（開発受託者内レビュー）

インスペクション B

（事務局レビュー）

目的・開発受託者チーム内メンバー同士

で成果物に対する自己点検を実施

すること

・開発受託者内で確認できる範囲の

欠陥除去と妥当性確認を行うこと

・全体整合性や共通化の観点から欠

陥除去と妥当性確認を行うこと

・要件が正確に反映されていること

を確認すること

・外部インターフェースの整合性を

確保すること

対象成果物・原則として全ての成果物・原則として全ての成果物・原則として全ての成果物

参加者・設計および開発者と同一チームメ

ンバー（2 名～）

・開発受託者の設計・開発チームメ

ンバーの数人。

・開発受託者の品質管理担当

・必要に応じて事務局の参加も可

・事務局と開発受託者

・関連する開発受託者

・事務局の品質管理担当

・関係ユーザ(必要に応じて)

実施

タイミング

・随時・レビュー計画に記載されている時

期

・対象成果物についてインスペク

ション A が完了後、速やかに実施

レビュー

実施単位

・小成果物単位・機能を実現する相互に関連する成

果物のセット

・機能を実現する相互に関連する成

果物のセット

利用ツール・指定なし・指定なし・事務局チェックリスト

データ収集・レビュー工数

・指摘事項の数と内容

・同左・同左

レビュー

報告書

・開発受託者が作成し、事務局に提

出する


出する


出する

トラッキング・不要・開発受託者内で解決できない問題

については、開発受託者が主担当

となり、課題・問題管理で取り扱

う

・開発受託者内で解決できない問題

については、事務局が主担当とな

り、課題・問題管理で取り扱う

6-5

6.2.2 目標設定

要件定義における、品質管理作業の完了基準を定める。品質評価会議では、全体としてこの基準を満たし

ている事を確認する。（6.2.6品質目標達成確認を参照）

（１）作業内容

開発受託者は、下表の品質管理目標を参考に、開発プロジェクトの特性を考慮して、成果物毎に

品質管理尺度及び基準値を検討し設定する。設定した基準値をその設定根拠とともに事務局に提示

する。

事務局は、基準値とその設定根拠の妥当性を評価し、妥当であると認められる場合にはその基準

値を承認する。

表 6-2 品質管理目標

品質管理尺度基準値備考

機能充足率 100% 管理目標

指摘事項の残存件数 0 件管理目標

エラー摘出密度 (成果物毎に設定） [件/機能数]

レビュー密度 (成果物毎に設定） [人・時/機能数]

6.2.3 計画策定

成果物毎にレビュー方法を定め、レビュー計画を定める。

（１）作業内容

事務局は、開発受託者に以下に示す品質管理活動の計画策定を指示する。

（ア）品質管理の役割分担の明確化

原則として、調達仕様書に示す成果物作成の役割分担に従う。

（イ）レビューの種類と実施時期

要件定義で実施するレビューを一覧で示し、それぞれの実施内容や実施時期の考え方等を明確に

記述する。なおそれ以外の方法を採用する場合は、事務局と開発受託者で協議の上決定する。

各成果物に対してどのようなレビューを実施するのかを整理し、レビュー計画表を作成する。レ

ビュー計画表には原則としてインスペクション A,B について記載する。

レビュー作業の流れは、以下の通りとする。

6-6

図 6-3 レビュー作業の流れ

ピアレビュー・ウォークスルーのスケジュールを WBS にタスクとして記載する必要はないが、インスペク

ション A,B については開発受託者が別途レビュー計画表を作成し、WBS 上にもマイルストーンとして記述す

る。（WBS 作成の考え方に従い、直近の作業が近づくにつれ詳細化する時点で記述されるとしてよい。）

以上のレビュー作業の流れとレビュー計画を基に、具体的なレビュー計画表作成例を図 6-4 に示す。

またレビューの品質を確保するため、関連性の高い成果物のインスペクションは単一のレビューとして実

施する事が望ましい。

実施予定日

実施実績日

実施予定日

実施実績日

レビュー形態

分類レビュー

形態1 ユースケース一覧 1月30日 2月15日全件2 ユースケース図 1月30日 2月15日サンプルグループ1 サンプル3 ユースケース記述 1月30日 2月15日サンプルグループ1 サンプル4 エンティティ一覧 1月30日 2月15日全件グループ2 全件5 エンティティ記述 1月30日 2月15日サンプルグループ2 全件6 画面一覧 1月30日 2月15日全件7 帳票一覧 1月30日 2月15日全件8 移行対象データ一覧 2月15日 2月28日全件グループ3 サンプル9 データ移行方法 2月15日 2月28日全件グループ3 サンプル

10 移行手順 2月15日 2月28日全件グループ3 サンプル11 移行システム仕様 2月15日 2月28日全件グループ3 サンプル12 アプリケーション・パターン 2月15日 2月28日全件13 システム全体構成 2月15日 2月28日全件14 ハードウェア仕様 2月15日 2月28日全件15 ソフトウェア仕様 2月15日 2月28日全件16 ネットワーク仕様 2月15日 2月28日全件

　　　　　　　　　　　　　品質確認方法

　　　　成果物

インスペクションAインスペクションB

個別レビュー関連レビュー

レビュー方法（全件レビューするのかサンプルレビューとするか）を記述。

他の成果物と関連させてレビューするものを識別。レビュー単位ごとにグループ化。

関連レビューの方法（全件か、サンプルか）を識別。

図 6-4 レビュー計画表の例

プロジェクト管理事務局

開発受託者

ピアレビューウォークスルー

の実施

レビュー報告書受領・評価

インスペクションＡ

レビュー実施


ピアレビュー／ウォークスルー

インスペクションＢインスペクションＡ

レビュー報告書の作成

レビュー実施



インスペクションＢ

レビュー実施

レビュー実施



成果物納品

成果物検収

納品

※必要に応じて事務局も参加※開発受託者内でのレビュー※全体整合性の観点から、必要に応じて関連レビューを実施



成果物

評価次第で再レビュー実施



6-7

大量の成果物に対して効率的にレビューを実施するための考え方を図 6-5 に示す。レビュー計画表を作成

する前に、まず優先度のもっとも高い業務について全件レビューを実施する。その結果を関係者に周知する

形で作業手順・成果物等の意識合わせを実施する。これにより作業内容・成果物の均一化を図る。

その後全件レビューの結果をもとにレビュー計画を策定し、次に優先度の高い成果物のレビューを実施し、

必要に応じてレビュー計画を見直す。この作業を成果物が完成するまで繰り返す。

図 6-5 レビュー・スケジュールの考え方

図 6-5 では、レビュー計画の見直しのタイミングを、初回を含めて３回設定してある。

（２）成果物

個別プロジェクト計画書の品質管理計画に以下の内容を記述する。

・品質目標

・レビュー計画

・レビュー・スケジュール

:

:

:

:

:

システム機能9

システム機能8

システム機能7

システム機能6

システム機能5

システム機能4

システム機能3

システム機能2

システム機能1

:

:

:

:

:

システム機能9

システム機能8

システム機能7

システム機能6

システム機能5

システム機能4

システム機能3

システム機能2

システム機能1

:

:

:

:

:

UC9

UC10

UC5

UC6

UC7

UC8

UC3

UC4

UC2

UC1

:

:

:

:

:

UC9

UC10

UC5

UC6

UC7

UC8

UC3

UC4

UC2

UC1

ユースケース作成単位

検討

優先度の高い業務の選択

:

:

:

:

:

UC8

UC9

UC3

UC4

UC5

UC6

UC7

UC11

UC2

UC1

:

:

:

:

:

UC8

UC9

UC3

UC4

UC5

UC6

UC7

UC11

UC2

UC1

優先度の高い業務

優先度の高い業務V1.0作成その他V0.5作成

その他V0.8作成その他V1.0作成

ここでは、全ての成果物を全

件レビューする。

:

:

:

:

:

UC8

UC9

UC3

UC4

UC5

UC6

UC7

UC11

UC2

UC1

:

:

:

:

:

UC8

UC9

UC3

UC4

UC5

UC6

UC7

UC11

UC2

UC1

:

:

:

:

:

UC8

UC9

UC3

UC4

UC5

UC6

UC7

UC11

UC2

UC1

:

:

:

:

:

UC8

UC9

UC3

UC4

UC5

UC6

UC7

UC11

UC2

UC1

UC：ユースケース作業、成果物の意識合わせ

（数ユースケース）

V1.0

V1.0V1.0V1.0

V0.5

V0.5

V0.5

V0.5

V0.5

V0.5

V0.5

V0.5

V0.5

V0.5

V0.8

V0.8

V0.8

V1.0

V1.0V1.0

レビュー計画の策定・調整レビュー計画の見直しレビュー計画の見直し

レビュー計画に従ったレビュー（例）全件：イベントフロー、シーケンス図、画面レイアウト及び項目帳票…サンプリング：ユースケース一覧、データディクショナリー、…

ユースケース及び関連する画面帳票等の作成作業レビュー実施の単位（インスペクションC）

凡例

ユースケース及び関連する画面帳票等の作成作業レビュー実施の単位（インスペクションC）

凡例

品質評価会議の実施品質評価会議の実施品質評価会議の実施

レビュー実施単位（インスペクション B）ユースケース及び関連する画面帳票等の作成作業

6-8

6.2.4 レビューの実施

計画に従いレビューを実施することで、成果物及び成果物作成手順の品質を担保し欠陥を除去する。

（１）レビューの準備

開発受託者は、品質管理の実施計画に従いレビューの準備を行う。インスペクション Bでは事務

局が開発受託者に、目的、対象物、実施日時、参加者と役割分担及びレビューに必要な資料の準備

状況等を確認し、実施の可否を判断する。その他のレビューでは、開発受託者がそれぞれ準備を行

う。

（２）レビューの実施とレビュー報告書（兼追跡票）の起票

開発受託者は計画に従いレビューを実施する。インスペクション A,B については、実施後、当標

準で定めるレビュー報告書（兼追跡票）を起票する。なお、開発受託者内で実施するピアレビュー

やウォークスルーについては、開発受託者はその実施方法について説明する必要がある。

レビュー報告書（兼追跡票）には以下の内容を含めることとする。

表 6-3 レビュー報告書の内容

項目補足

対象対象成果物名、ID 等、対象頁数

出席者責任者、参加者

レビュー工数レビュー時間×参加人数 [人・時]

問題点及び解決策など該当箇所、問題点、問題区分、原因区分、潜入工程、解決策及び備考、解決予定日、

修正工数、完了日、確認者

件数指摘数、完了数、残件数

レビュー密度レビュー工数／機能数

6-9

レビュー報告書（兼追跡票）の様式は以下の通り。

図 6-6 レビュー報告書（兼追跡票）

（３）品質の判定

開発受託者は、レビューの実施を通して、対象成果物の作成プロセスと作業品質を判定する。レ

ビューの結果、以下のような問題が発見された場合は、原則として再レビューを実施する。

なお、インスペクション Bについては、事務局が再レビューの要否を判定する。他開発受託者等

への影響の可能性がある場合は、横展開調査も考慮し課題・問題管理プロセスを検討・実施する。

（ア）再レビュー実施要因の例

・未解決の問題がある。

・保留事項が整理されていない。また、保留事項の解決策や解決時期が決まっていない。

・作業プロセス上の問題がある。

・問題の発生傾向が極端に変化している。

・問題の種類や内容に偏りが見られる。

（イ）レビュー後のアクションプランの例

・再レビューの実施

・対応策の再検討指示

・一斉点検の実施判断

・未然防止策などの一斉周知

レビュー報告書（兼追跡票）作成日修正日

□健■保□支□他()ﾚﾋﾞｭｰ責任者

○○○○（設計リーダー）□□□□□　（設計者）

対象成果物名（ID） △△△△△　（チームメンバー）[1] KS-01-10システム機述書_3-1-1_0.50[2] KS-01-10システム機述書_3-1-2_0.50[3] KS-01-12画面遷移_3-1-1_0.50 備考[4] KS-01-12画面遷移_3-1-2_0.50[5] KS-01-13画面レイアウト及び項目定義_3-1-2_0.5

No.

1 [1]p2 同じアクターが記述されている。 1 110 基 ○○を□□に修正。

2 [1]p3 2 110 基「入力する」に修正。

3 [1]p6 3 100 基 ○○更新画面に修正。

4 [2]p4 4 110 基[4]p2

画面遷移を修正。不要な画面を１つ削除（nnnn）

○山

○山

○山

○山

2.0 7/26

0.5 7/26

0.1 7/26

0.1 7/26

7/26

7/26

7/26

7/26ユースケース記述で規約外の「タイプする」が使われている

シーケンスと分析クラス称が整合していない。「○○入力画面」と「○○更新画面」

代替イベントフローと画面遷移が整合していない。

完了日確認者解決修正

工数

文書ID

潜入工程

解決策及び備考該当箇所問題点

H19.1.29

工数

問題区分

原因区分

12:3010:00種類日時

ｲﾝｽﾍﾟｸｼｮﾝA 範囲開始終了

回数 1回目場所 ○○ビル４F　△会議室出席者出席数 3

○山×夫

時間 2:30

残件数

0.3

40

4指摘数完了数

H19. 1.26

6 R密度

記入者修正者□川△子

頁数 20

問題区分0 体裁等欠陥以外の扱い1

曖昧な・単純な誤り2規約違反

3 記述漏れ4不整合（成果物内）5不整合（成果物間）

6 不整合（サブシステム間）

原因区分

100 推敲不足

110 修正漏れ・間違い

200 周知漏れ210 前提情報の不一致300 設計技術の不足310 業務知識の不足

400 調整結果に対する理解の不一致500 要件に関する理解の不一致

人・時

予定日

6-10

（４）レビュー報告書（兼追跡票）の提出および評価実施

レビュー報告書の起票者及び提出先は表の通り。起票者はレビュー報告書を起票するとともに、

指摘事項への対応状況を追跡、必要に応じて取りまとめを行い、対応が完了したレビュー報告書を

指定した宛先に提出する。ただし５営業日を超えて対応が完了しない場合、対応策を検討・実施す

る。また、提出されたレビュー報告書に対して、定期的に品質管理状況の評価実施を行う。

表 6-4 レビュー報告書の起票者、提出先および評価実施

インスペクション A インスペクション B

起票者開発受託者開発受託者

報告書提出先事務局事務局

提出頻度週次等週次等

評価実施個別進捗会議

全体進捗会議

個別進捗会議

全体進捗会議

（５）課題の抽出

指摘事項への対応が開発受託者との間で解決できない場合は、課題・問題管理にて取り上げる。

その際、レビュー報告書（兼追跡票）の該当箇所については、課題・問題管理にて対応中である旨

を記載し、同時に、課題管理番号を記録しておく。課題が解決したら、対応内容を更新してレビュー

報告書（兼追跡票）の更新版を再度提出する。

6-11

6.2.5 品質評価と対策実施

品質に関するデータに基づき品質評価報告書を作成し、開発受託者における品質管理状態を把握する。ま

た、品質に問題がある場合は、対応策を検討して実施する。

（１）品質評価のためのデータ収集

事務局は開発受託者に対して、レビュー活動に伴う基礎的なデータと、基本設計内容の技術的な

規模を表す技術データを収集するように指示する。

（ア）レビュー関連データ

・レビュー工数と対象設計書量

・指摘事項の数（指摘数、解決済み数、未解決残数）

・指摘事項の種類（現象と原因）

表 6-5 品質管理指標(基本設計工程における例)

管理指標名説明算出式

成果物レビューによる問題検出

・レビューされる成果物の品質を測定する。・成果物の量は、レビューされる成果物のタイプに依存す

る。・例えば、要件定義書がレビューされる場合、成果物の量

は要件項目数に依存する。

問題の総数 / 成果物の量

成果物レビューの実効性

・成果物レビューで発見された問題数を時間単位で測定する。

・成果物レビューに費やされた合計時間は、参加者全員がレビュー準備･実施に費やした全ての合計時間である。

問題の総数 / 成果物レビューに費やした総時間数

成果物レビュー準備工数

・レビューされた成果物の量に対し、レビューの準備に費やされた工数を測定する。

レビュー準備総時間数 / 成果物の量

成果物 1頁あたりの問題数

・レビューした成果物 1頁あたりに発見された問題数を測定する。

・成果物レビュー実施時に、レビュー頁数を数える。

問題の総数 / レビュー頁数

カテゴリー別の問題発生率

・成果物レビューの結果、問題がどのカテゴリーにおいて顕著であるかを明確にし、早めに問題解決できるようにする。

カテゴリー別問題数/ 問題の総数

（イ）主要な設計要素の規模データの例

a データ・ディクショナリー上のデータ項目数

b ER 図上のエンティティ数

c アクター数

d アクターの複雑性により分類し、レベル別に集計する。

・単純：定義済み API を備えた別システム

・平均：テキストベースのインターフェースを介した操作を行う人間、プロトコルを介して

相互作用する別システム

・複雑：GUI を介した操作を行う人間

e ユースケース・モデルの数

モデルの複雑性により分類し、レベル別に集計する

・単純：トランザクションが３個以下、または、分析クラス（バウンダリー、コントロール、

エンティティ）が４個以下

・平均：トランザクションが４～７個、または、分析クラスが５～１０個以下

・複雑：トランザクションが８個以上、または、分析クラスが１１個以上

モデルの種類別に分類し、区分別に集計する

・オンライン

・ディレイドオンライン

・バッチ

月次進捗管理サイクルのワークフロー - mhlw...・EV＜AC（CV＜0）...

Documents

Transcript of 月次進捗管理サイクルのワークフロー - mhlw...・EV＜AC（CV＜0）...