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 ユースケース・モデルの数

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

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

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

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

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

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

・オンライン

・ディレイドオンライン

・バッチ

6-12

f ファンクションポイント数

g テーブル数、ファイル数

h ユーザ・インターフェース（画面数）

画面の特性により分類し、区分別に集計する

・入力更新系：画面遷移図上の全ての入力更新系画面の数

・検索照会系：画面遷移図上の全ての検索照会系画面の数

・分析系：画面遷移図上の全ての分析系画面の数

i ユーザ・インターフェース（帳票数）

帳票の特性により分類し、区分別に集計する

・バッチ帳票：バッチ及びディレイドオンラインで出力する帳票の数

・オンライン帳票：オンラインで出力する帳票の数

（２） 品質評価報告書の作成

開発受託者は品質評価報告書を作成し、品質評価会議にて報告する。品質評価報告書は、開発受

託者が作成する。事務局は開発プロジェクト全体としての品質管理状況を統括した品質評価報告書

（全体）を作成する。

表 6-6 品質評価報告書の内容 項目 補足

品質に関する全体状況 ・今回の報告期間に対する品質状況の要約

品質データ一覧及び分析結果 ・機能充足率の推移と分析結果と所見。

・欠陥数、解決数、レビュー密度、欠陥摘出率の推移と分析結果と所見。

・欠陥の現象と原因に関する層別分析結果と所見。

・その他のデータの傾向分析結果と所見。

品質上の問題点と対応策 ・問題点と対応策（欠陥の未然防止策や作業方法の変更案等）の一覧

欠陥の未然防止策 ・欠陥の未然防止策の一覧（展開中、展開予定）

前回からの申し送り事項

次回への申し送り事項

保留事項一覧

その他

添付資料

（３） 品質評価会議の実施

品質評価会議では、品質評価報告書に基づき改善策等を決定し、その実施を指示する。品質評価

会議の実施時期は、要件定義の作業計画に基づき、あらかじめマスタースケジュールに組み込む。

なお運営上、品質評価会議は進捗会議の中で実施することも可とする。

図 6-7 品質評価の実施

（改善策等の例）

開発受託者 開発受託者

プロジェクト管理事務局

レビュー報告書 レビュー報告書

品質評価会議品質評価

報告書（全体）

・品質管理データの

集計と分析

・問題点の調査・改善策の検討

F

012

34

56

78

5 15 25 35 4555 65

F

012

34

56

78

5 15 25 35 4555 6505

10

1520

25

9/8

9/22

10/6 10/2011/311/17

12/1

12/15

12/29

1/12

A

BC

05

10

1520

25

9/8

9/22

10/6 10/2011/311/17

12/1

12/15

12/29

1/12

05

10

1520

25

9/8

9/22

10/6 10/2011/311/17

12/1

12/15

12/29

1/12

A

BC

品質評価報告書

品質評価報告書

対策の指示§レビュー計画の変更§追加レビューの実施

§作業方法の変更§体制強化等

6-13

・レビュー計画の変更

・追加レビューの実施

・作業方法の変更

・体制強化等

6.2.6 品質目標達成確認

工程を終了するに当たり、最終成果物が品質管理目標（6.2.2目標設定 参照）を達成し、一定の品質レベ

ルにあることを確認する。

（１） 品質評価報告書（工程完了）の作成

事務局は、開発受託者に対して「品質評価報告書（工程完了）」の作成を指示する。開発受託者は

報告書を作成し、事務局はその内容を確認の上、品質評価会議への提出を指示する。開発プロジェ

クト全体としての報告書は事務局がとりまとめ、別途同様の書式にて報告書を作成する。

表6-7 品質評価報告書（工程完了）の内容

項目 補足

品質状況に関する総括 今回の工程に対する品質目標達成状況の総括

品質データ一覧及び分析結果 機能充足率、問題数（発生、解決、残）、欠陥摘出率、レビュー

密度の推移の最終結果とその分析結果に関する所見

その他

添付資料

（２） 品質目標の達成確認

事務局は品質評価会議を開催し、以下の観点から最終成果物の品質レベルを判定し、工程の完了可

否の判断を行う。

・品質管理目標を達成していること（6.2.2目標設定 参照）

・次工程への申し送り事項が妥当であること

・保留事項については対応策と解決時期が決定し、次行程に対する影響が整理されていること。

（３） 成果物

・品質評価報告書（工程完了）

6-14

6.3 留意事項

品質評価報告書を作成する上での留意点を下記にまとめる。

定量的な問題発見方法として、品質尺度（欠陥数、解決数、レビュー密度、欠陥摘出率）の分布状況や傾

向変化を観察する。これにより品質上の問題を効率よく発見することができる。

開発受託者及び事務局は以下に示すようなデータ分析を実施し、根本原因の追及と対応策の検討を行った

上で品質評価報告書に記載する。

（１） 欠陥摘出率の分布状況に基づく問題発見の方法 （例1）

欠陥摘出率のヒストグラム

0

1

2

3

4

5

6

7

8

0 0.2 0.4 0.6 0.8 1 1.2

外れ値

図 6-8 欠陥摘出率の分布例

欠陥摘出率をヒストグラムで表現し、分布状況を確認する。分布状況から統計的手法が適用可能

であれば、分布の外れ値（図の両端に分布しているデータ）に対して、その原因分析を行うことに

より、作業プロセスや作業品質上の問題を発見する。

具体的には、レビュー報告書を参照し、外れ値を生じさせているレビューではどのような問題が

指摘されていたか、どのような対策がとられているか、作業プロセスは確認済みか、作業者に問題

はないか、レビュー実施者に特徴はないかなど、多角的にその原因を追及する。

図 6-9 欠陥摘出率の分布

外れ値の選択基準が確立されていない状況に於いては、四分位図（箱ひげ図）などを用いて、分

析対象を客観的に選択する方法も有効な手段である。

6-15

（２） 欠陥数の傾向変化に基づく問題発見の方法 （例2）

分布状況に基づく問題発見の方法と同様に、傾向変化に着目して調査対象のデータを絞り込むこ

とで問題発見につなげる。

0

5

10

15

20

25

30

9/8

9/22

10/6

10/20

11/3

11/17

12/1

12/15

12/29

1/12

A

B

C

図 6-10 欠陥数の傾向変化のポイント

例えば図6-10において、CとAのデータ系列の変動傾向が丸で囲んだポイントで大きく変化して

いる。この変化が A、C同時に発生していることから両者に関わる部分に問題が潜んでいる可能性

がある。それを見極めた上で必要に応じて対策を実施する。

また、Bは欠陥数が増加傾向を示している。レビュー品質が向上したことによる増加であれば問

題ないが、レビュー方法を変更していないのに増加しているのであれば、発生している問題の内容

を調査し、必要に応じて対策を実施する。

7-1

7. 課題・問題管理要領

課題・問題管理の目的とは、発生した課題・問題を漏れなく把握し、かつ迅速に対応すること、及びその

対応結果を共有することで、課題・問題の早期解決・再発防止に役立てることである。目的達成のために必

要な管理手順を以下に示す。

7.1 課題・問題管理とは

課題・問題管理の適用範囲と、基本的な考え方を示す。

7.1.1 適用範囲

課題・問題管理にて取扱う適用範囲及びその定義を以下に示す。

（１） 課題・問題

開発プロジェクトの実施に伴って発生して、開発プロジェクトの進捗を妨げる事象のこと。

（２） 質問

開発プロジェクトの実施における開発受託者側の不明点及び疑問点を解消するため、開発受託者

から事務局に対して行われる問合せのこと。

（３） 通知

開発プロジェクトの実施に伴って発生する、事務局から関係者へ伝達する連絡事項のこと。

7.1.2 基本的な考え方

課題・問題、質問、通知に対応するための基本的な考え方を以下に示す。

（１） 課題・問題対応

開発プロジェクトで発生するそれぞれの課題・問題に対して担当者を定める。その担当者が課

題・問題の解決まで責任をもって対応する。また、課題・問題の解決にあたり、事務局の判断や他

の開発受託者の協力が必要な場合に対応できるようにエスカレーションの仕組みも整備する。これ

により、開発受託者で対応できない課題は速やかに個別・全体進捗会議の場に提示され、解決に向

けた適切な対応（課題検討会議等）を取ることができる。

なお、関係者間の情報伝達は、課題管理台帳にて行う。開発受託者は自身の課題管理台帳を保持・

管理するが、全体進捗会議では、事務局が全ての管理台帳のエスカレーション部分を集約して報告

する。

（２） 質問対応

課題・問題には至らない軽微な内容を取扱う。質問を分離することにより重要な課題・問題への

対応がより効率的に行われることを意図している。

（３） 通知対応

事務局が関係者に対し必要事項を周知徹底させる手段である。課題・問題対応で明らかになった

解決策を開発プロジェクトに横展開する場合や週次の進捗会議を待たずに周知したい場合等を想

定している。通知を受領した開発受託者は速やかに対応し、その結果を事務局に報告する。

7-2

7.2 課題・問題管理の詳細

7.2.1 課題・問題対応

課題・問題対応の詳細を以下に示す。

（１） 管理帳票

（ア） 課題管理台帳

開発受託者の担当範囲における課題を一元的に管理する。（表7-1）

新規の課題・問題の登録時に、項番、分類、関連部署、課題内容、担当者、状況（起票）、開始

年月日、期限を入力する。

対応状況に進展があった、または進捗会議で報告する場合は進捗状況を入力し、対応が完了し

た場合は、回答年月日、回答担当者、状況（終了）を入力する。

表7-1 課題管理台帳一覧

台帳名 台帳管理者 記述内容

1.全体課題管理台帳 事務局 ・プロジェクト全体の進捗・品質に関わる

課題

（下記 2.の台帳上の課題の中からも抽

出）

2.間接業務システム開発：

個別課題管理台帳

間接業務システム

開発受託者

・間接業務システム開発に係る課題

※当初は各受託範囲にて発生した課題を全て記載するが、全体進捗会議での調整後、 ・上記範囲で発生したが他で解決すべき課題は、削除する。 ・他で発生したが上記範囲で解決すべき課題は、追加する。

（２） 管理サイクル

（ア） 台帳登録

開発受託者及び事務局が、プロジェクト活動、品質管理活動等において発生した課題・問題を、

課題候補として個別課題管理台帳に登録する。

（イ） 個別進捗会議での対応

個別課題管理台帳に登録された課題候補を、課題として扱うか否か、また全体進捗会議にエス

カレーションするか否かについて事務局が判定する。過去に発生した開発受託者内の課題につい

てもその対応状況を事務局が確認する。エスカレーション対象の課題（共通課題）は、事務局が

全体課題管理台帳に取りまとめる。また、取りまとめた課題に対し、解決方針の提示、解決担当

者の指名、別途検討会議を設ける必要性の判断等の対応を実施する。対応結果は全体課題管理台

帳に記録され、開発受託者に配付される。

（ウ） 全体進捗会議での対応

全体課題管理台帳を基に、プロジェクト責任者及びプロジェクト全体管理者に状況報告を行う。

事務局での対応が難しい課題についての対応方法を確認する。

7-3

（エ） 課題検討会議での対応

開発受託者に配付された課題のうち、課題検討会議が必要であると判断された課題については、

課題の関係者を集めた会議を招集する。議事録を必ず作成し関係者に回付することで情報共有を

図る。

（オ） 終了時の対応

解決した課題は、個別課題管理台帳上の状況を更新し、課題・問題管理としてクローズする。

（３） 役割分担

（ア） 開発受託者

・開発受託者内及び事務局が提起する新規課題を台帳に登録する。

・課題の対応状況を把握し、台帳を更新する。

・個別進捗会議に個別課題管理台帳を提出する。

・事務局にエスカレーション対象の課題（共通課題）を提出する。

・全体進捗会議での検討結果を受けて、台帳を更新する。

・個別進捗会議または全体進捗会議にて指名された後、その課題が解決するまで責任を持って対

応する。

・必要に応じて課題検討会議を招集する。議事録を作成し会議の内容を事務局及び他の開発受託

者に報告する。

（イ） 事務局

・開発受託者に対し、開発受託者内の新規課題を提起する。

・個別課題管理台帳上の課題についての対応方針や課題担当者の決定、エスカレーションの必要

性等を判断する。

・個別管理台帳のエスカレーション対象の課題（共通課題）を集約し、全体課題管理台帳として

全体進捗会議に提出する。

・全体進捗会議にて検討された結果を、開発受託者に振り分ける。

・全体課題管理台帳上の課題についての対応方針や課題担当者、課題検討会議の必要性等を判定

する。

7.2.2 質問対応

質問対応の詳細を以下に示す。

（１） 管理帳票

（ア） 質問管理台帳

・新規質問の登録時、事務局が、質問管理№、起票者名（開発受託者区分、氏名）、起票年月日、

質問内容、希望回答期限、質問先を質問票から転記し、状況（起票）を記入する。

・回答完了時、事務局が、回答者名（開発受託者区分、氏名）、回答年月日、回答内容を質問票か

ら転記し、状況（終了）を記入する。

7-4

（イ） 質問票

・起票時、開発受託者が、起票者名（開発受託者区分、氏名）、起票年月日、標題、質問内容、

希望回答期限を記入する。また、事務局による発行後、質問管理№も開発受託者が記入する。

・回答完了時に、開発受託者が、回答者名（開発受託者区分、氏名）、回答年月日、回答内容を

記入する。

（２） 管理サイクル

（ア） 起票・発信

・開発受託者が起票する。事務局が発行する質問管理№を記入のうえ、事務局に送付する。事務

局は質問管理台帳への登録も実施する。

（イ） 回答・終了

・事務局が回答を作成し、開発受託者に返送する。事務局は回答の写しを受領し、質問管理台帳

にその内容を転記する。

（３） 役割分担

（ア） 開発受託者

・質問票の起票及び回答の受領を行う。また事務局に対し、質問管理№の発行依頼も行う。

（イ） 事務局

・質問票の受付、回答作成及び回答送付を行う。また回答送付時、質問者だけでなく管理者にも

回答の写しを送付する。

・質問管理№の発行管理及び質問管理台帳の記入を行う。質問管理№の発行時、類似の質問が

過去に提出されていないかを確認する。

7-5

7.2.3 通知対応

通知対応の詳細を以下に示す。

（１） 管理帳票

（ア） 通知管理台帳

・新規通知の登録時に、通知管理№、起票者名、起票年月日、通知内容、通知先を通知票から転

記する。

（イ） 通知票

・起票時に事務局にて、起票者名、起票年月日、通知内容を記入する。また、事務局による発行

後、通知管理№も事務局が記入する。

（２） 管理サイクル

（ア） 起票・発信

・事務局が起票する。事務局が発行する通知管理№を記入し、被通知者（開発受託者等）に送付

する。

（３） 役割分担

（ア） 開発受託者

・通知票を受領する。通知内容に従って速やかに対応を実施する。

（イ） 事務局

・通知票の起票を行い、通知管理№を発行する。

・通知管理№の発行管理及び通知管理台帳の記入を行う。

7-6

7.3 課題・問題管理のワークフロー

7.3.1 課題・問題対応のワークフロー

課題・問題対応のワークフロー及びその作業内容を以下に示す。（図7-1、7-2）

図7-1 課題・問題対応のワークフロー（１／２）

開発受託者

社会保険オンラインシステム

財団健診システム

プロジェクト管理事務局

課題提起個別課題

課題提起全体課題

①

①全体課題管理台帳

個別進捗会議

課題報告。

解決策提案

課題報告・解決策提案

全体進捗会議報告課題の識別

課題担当者の振り分け

解決策の確認個別課題

課題対応

全体進捗会議

課題報告・解決策提案

補足説明・解決策の確認

解決策の確認

課題の確認・対応指示

②

③

開発受託者

開発受託者

他の受託者

他の受託者

プロジェクト管理事務局

プロジェクト管理事務局

課題提起課題提起個別課題

管理台帳登録個別課題

管理台帳登録

課題提起依頼課題提起依頼

課題提起課題提起全体課題

管理台帳登録全体課題

管理台帳登録

①

①

個別課題管理台帳個別課題管理台帳個別課題管理台帳

全体課題管理台帳全体課題管理台帳全体課題管理台帳

個別進捗会議

課題報告。

解決策提案

課題報告。

解決策提案

課題報告。

解決策提案

課題報告・解決策提案課題報告・

解決策提案課題報告・

解決策提案

全体進捗会議報告課題の識別

全体進捗会議報告課題の識別

全体進捗会議報告課題の識別

課題担当者の振り分け

課題担当者の振り分け

課題担当者の振り分け

解決策の確認解決策の確認

全体課題管理台帳取りまとめ全体課題管理台帳取りまとめ全体課題管理台帳取りまとめ

個別課題管理台帳更新

個別課題管理台帳更新

個別課題管理台帳更新

課題対応課題対応

全体課題管理台帳全体課題管理台帳全体課題管理台帳

プロジェクト責任者

プロジェクト全体管理者

プロジェクト責任者

プロジェクト全体管理者

全体進捗会議

課題報告・解決策提案課題報告・

解決策提案課題報告・

解決策提案

補足説明・解決策の確認

補足説明・解決策の確認

補足説明・解決策の確認

解決策の確認解決策の確認

課題の確認・対応指示

課題の確認・対応指示

課題の確認・対応指示

②

③

7-7

※「他の受託者」は、間接業務運用業者やハード納入業者等を想定

図 7-2 課題・問題対応のワークフロー（２／２）

（１） 課題登録

事務局及び開発受託者から提起された課題を個別課題管理台帳に登録する。

（ア） 課題提起

・開発受託者が課題を発見した場合、台帳登録に向けて課題内容を整理する。

・他システムの開発において、間接業務システムの開発に影響を及ぼす課題が発生した場合、事

務局で課題内容を整理する。

・事務局が課題を発見した場合、台帳登録に向けて課題内容を整理する。なお、特定の開発受託

者の課題である場合は、当該開発受託者に台帳登録を依頼する。

（イ） 個別課題管理台帳登録

・各受託者は自身が発見した課題及び関係者から登録を依頼された課題を、自身の個別課題管理

台帳に登録する。

開発受託者

社会保険オンラインシステム

財団健診システム

個別課題課題対応

課題検討結果受領

個別課題管理台帳

課題検討会議

解決策検討

個別課題

③全体課題

全体課題管理台帳

全体課題

②

④へ

④

開発受託者

他の受託者

プロジェクト管理事務局

個別課題管理台帳更新

個別課題管理台帳更新

個別課題管理台帳更新

課題対応課題対応

課題検討結果受領課題検討結果受領課題検討結果受領

個別課題管理台帳個別課題管理台帳個別課題管理台帳

課題検討会議

解決策検討解決策検討

個別課題管理台帳更新

個別課題管理台帳更新

個別課題管理台帳更新

③全体課題

管理台帳更新全体課題

管理台帳更新全体課題

管理台帳更新

全体課題管理台帳全体課題管理台帳全体課題管理台帳

全体課題管理台帳更新

全体課題管理台帳更新

全体課題管理台帳更新

②

④へ

④

7-8

（２） 個別進捗会議での対応

開発受託者の個別課題管理台帳を個別進捗会議に提出し、課題としての取扱いを決定する。

（ア） 個別進捗会議

・開発受託者は、個別進捗会議に個別課題管理台帳を提出する。

・事務局は、提出された課題内容を検討し、開発受託者内で対応するか、全体進捗会議にエスカ

レーションするかを判断する。開発受託者内で対応する課題については、対応方針も決定する。

（イ） 個別課題管理台帳更新

・個別進捗会議の結果を受けて、開発受託者は個別課題管理台帳を更新する。開発受託者内で

対応する課題（開発受託者内課題）と全体進捗会議にエスカレーションする課題（共通課題に

分類する。

（ウ） 開発受託者内課題対応

・開発受託者は、開発受託者内課題への対応を実施する。解決するまで対応は継続するものとす

る。ただし、週をまたがって対応が継続する場合は、個別進捗会議にて対応状況を報告する。

（３） 全体進捗会議での対応

開発受託者内の共通課題を取りまとめ、全体進捗会議に提出し、対応方針を決定する。

（ア） 共通課題提出

・開発受託者は、自身の個別課題管理台帳の共通課題を抽出し、事務局に提出する。

（イ） 全体課題管理台帳取りまとめ

・事務局は、開発受託者から提出された共通課題及び自身の個別課題管理台帳上の課題を取りま

とめ、全体課題管理台帳を作成する。

（ウ） 全体進捗会議

・事務局は、全体進捗会議に全体課題管理台帳を提出する。

・事務局は、提出された課題内容を精査し、課題担当者は誰か、課題検討会議の開催が必要かを

判断する。また各課題の対応方針も決定する。

（エ） 全体課題管理台帳更新

・全体進捗会議の結果を受けて、事務局は全体課題管理台帳を更新する。更新された結果は、事

務局が課題担当者別に分類し開発受託者に配付する。

（オ） 個別課題管理台帳更新

・事務局から配付された更新結果を受けて、開発受託者は個別課題管理台帳を更新する。開発受

託者内で対応する共通課題（共通課題（検討会不要））と課題検討会議で対応する共通課題（共通

課題（検討会要））に分類する。

7-9

（カ） 個別課題対応

・開発受託者は、共通課題（検討会不要）への対応を実施する。解決するまで対応は継続するも

のとする。ただし、週をまたがって対応が継続する場合は、個別進捗会議にて対応状況を報告す

る。

（４） 課題検討会議での対応

共通課題（検討会要）に対して課題検討会議を招集し、課題解決に向けての検討を実施する。

（ア） 課題検討会議の招集

・共通課題（検討会要）の課題担当者となった開発受託者は、課題解決のために必要なメンバー

を選定し、課題検討会議を招集する。

（イ） 課題検討会議

・課題担当者となった開発受託者は、課題解決に向けて主導的に議事を進める。

・課題検討会議の出席者は、課題解決に向け、課題担当者に協力する。

・会議内で解決しない場合は、再度、課題検討会議を招集する。

・会議の議事録は課題担当者が作成する。なお、議事録は検討結果を中心に簡潔にまとめ、会議

終了前に必ず出席者全員の同意を得る。

（ウ） 議事録配付

・会議終了後、課題担当者となった開発受託者は、関係者全員に議事録を配付する。

（５） 終了

課題解決後、その結果を個別課題管理台帳に反映し、課題をクローズする。

（ア） 個別課題管理台帳更新

・開発受託者は、開発受託者内課題対応及び課題検討会議にて課題解決した結果を受け、個別

課題管理台帳を更新し、課題をクローズする。

7-10

7.3.2 質問対応のワークフロー

質問対応のワークフロー及びその作業内容を以下に示す。（図7-3）

※「他の受託者」は、間接業務運用業者やハード納入業者等を想定

図7-3 質問対応のワークフロー

（１） 起票・発信

開発受託者が質問票を起票する。事務局は質問票を発行し、管理台帳に記載する。

（ア） 開発受託者は質問票を起票し、回答期限を明記のうえ質問事項を記載する。事務局に連絡して質

問管理№の番号を入手後、事務局に送付する。また、他の受託者に対する質問票は、事務局が起

票し、他の受託者に送付する。

① 記載事項

・ヘッダー情報（開発受託者、起票者（会社名）、起票年月日、質問先、表題）

・質問内容

② 注意事項

・質問票は、開発受託者内で調整し整合性をとって作成すること

・関係者に誤解を招かない文章表現で作成すること

・過去の質問票を確認し、同等の質問がないことを確認して起票すること

・希望回答期限は事務局の現実的な資料検討・作成時間を考慮して設定すること

開発受託者

社会保険オンラインシステム

財団健診システム

プロジェクト管理事務局

質問票起票

資料管理

質問依頼

質問票起票

①

①

回答作成 資料管理

開発受託者

開発受託者

他の受託者

他の受託者

プロジェクト管理事務局

プロジェクト管理事務局

質問票起票質問票起票

資料管理資料管理

質問依頼質問依頼

質問票起票質問票起票

回答作成支援回答作成支援

回答支援依頼回答支援依頼

①

① 回答作成支援回答作成支援

回答作成回答作成 資料管理資料管理

回答内容確認

回答内容確認回答内容確認

質問依頼質問依頼

7-11

（イ） 事務局は、質問票を受取り質問管理台帳に質問票の内容を記載する。質問管理№を発行後、質問

管理台帳及び質問票に各々記載し、状況欄を［１．起票］に設定して質問票を返却する。

① 記載事項

・ヘッダー情報（質問管理№）

・質問管理台帳に新規データを追加

（２） 回答

事務局が質問に対する回答を検討・作成し、質問票に記載する。またその結果を開発受託者、他

の受託者に返信する。回答済み質問票を開発受託者に返信して終了とする。

（ア） 事務局は、質問票の内容を確認し回答を作成する。その際、以下の注意事項を考慮することとす

る。

① 記載事項

・回答

② 注意事項

・希望回答期限までに回答作成が困難な見通しの場合、事務局に連絡して開発受託者と回答期限

の調整を行うこと。

・内容が他の開発受託者等にまたがると考えられる場合は、該当開発受託者に質問票を送付し、

意見・情報を入手したうえで回答を作成すること。

・質問票を転送する際には、備考欄等に転送経緯を明記すること。

（イ） 開発受託者、他の受託者は質問票を受取り、回答内容を確認する。

（ウ） 事務局は質問票の回答を受取り、質問管理台帳の状況欄を［２．終了］に更新し、質問票を保管・

管理する。

（エ） 事務局は質問対応の進捗情報を一ファイルに集約する。また回答済みの質問票を定期的に関係者

全員に発信して、回答内容を周知する。

質問対応の中から課題が発生することもある。その場合は、個別進捗会議の場などで課題として別

途報告するものとする。

7-12

7.3.3 通知対応のワークフロー

通知対応のワークフロー及びその作業手順を以下に示す。(図7-4)

※「他の受託者」は、間接業務運用業者やハード納入業者等を想定

図7-4 通知のワークフロー

（１） 起票・発信

事務局が通知票を起票する。事務局は通知管理№の発行と台帳記入を実施する。

（ア） 事務局が通知事項を記載し、通知管理№の番号を入手して通知票を起票する。

－記載事項－

・ヘッダー情報（起票者、起票年月日、表題）

・通知内容

（イ） 開発受託者は通知票を受け取り、通知管理台帳に通知票の内容を記載する。通知管理№の発行後、

通知管理台帳と通知票各々に記載し、事務局に通知票を返却する。

－記載事項－

・ヘッダー情報（通知管理№）

・通知管理台帳に新規データ追加

（ウ） 事務局は通知票を開発受託者、他の受託者に発信する。

（エ） 開発受託者は通知票の内容を確認・理解し、必要に応じてチームメンバー等に周知する。

（オ） 事務局は通知票を保管・管理する。

開発受託者

社会保険オンラインシステム

財団健診システム

プロジェクト管理事務局

通知票起票 資料管理

開発受託者

開発受託者

他の受託者

他の受託者

プロジェクト管理事務局

プロジェクト管理事務局

通知票起票通知票起票 資料管理資料管理

通知内容確認通知内容確認

通知内容確認通知内容確認

8-1

8. 変更管理要領

成果物等の変更管理対象に対する変更手続きを定め、変更要求の承認及び変更履歴の保持を確実に行う。

8.1 変更管理とは

8.1.1 変更管理の対象

変更管理要領では、納品が終了し検収された成果物を変更管理の対象とする。

納品が終了した成果物を初版とし、そこから変更管理を実施する。対象となる成果物文書は、仕様書（確

定版）、プロジェクト計画書、基本設計書、各種標準等となる。

※ 完成前の成果物に対する変更の管理は、変更管理の対象外とする。

8.1.2 変更作業の実施

変更作業担当者が作業を実施し、その結果を事務局に報告する。その際、変更履歴の作成等を実施し、差

分がわかるように適切に管理する。

8-2

8.2 変更管理の詳細

8.2.1 変更管理対応

（１） 変更管理のワークフロー

納品された成果物に対する変更案件をすべて変更管理台帳にて管理する。各個別サブシステム内に閉

じた変更案件は個別変更管理台帳にて管理し、プロジェクト全体に関わるか複数サブシステムに跨る

変更案件は全体変更管理台帳にて管理する。各サブシステムの開発受託者は、承認された変更案件に

ついて、修正を実施し、変更管理台帳を更新の上、個別/全体進捗会議にて一覧を配付して結果を周知・

報告する。

図 8-1 変更管理のワークフロー

仕様変更要件起票

変更管理台帳変更管理台帳変更管理台帳

仕様変更要件合否判定案作成(代替案・影響分析)

変更管理台帳変更管理台帳変更管理台帳

プロジェクト管理事務局

プロジェクト管理事務局

開発受託者

個別進捗会議

報告内容承認・改善指示

報告内容承認・改善指示

報告・指示確認報告・指示確認

プロジェクト責任者

プロジェクト全体管理者

プロジェクト責任者

プロジェクト全体管理者

仕様変更要件起票

仕様変更要件起票

仕様変更要件起票

変更管理台帳

変更管理台帳

変更管理台帳

報告内容承認・実施指示

報告内容承認・実施指示

全体進捗会議

報告内容承認・

実施指示

報告内容承認・

実施指示

報告・指示確認報告・指示確認

仕様変更要件合否判定案作成（代替案・影響分析）

仕様変更要件合否判定案作成（代替案・影響分析）

変更管理台帳変更管理台帳

仕様変更の作業実施仕様変更の作業実施仕様変更の作業実施

個別進捗会議

仕様変更完了確認

作業完了報告

個別進捗会議

仕様変更完了確認仕様変更完了確認

作業完了報告作業完了報告変更管理台帳更新

変更管理台帳更新

変更管理台帳更新

変更管理台帳変更管理台帳変更管理台帳

変更管理台帳変更管理台帳変更管理台帳

変更管理台帳

変更管理台帳

仕様書等仕様書等

プロジェクト全体/複数サブシステムに

関わる変更案件か？

YES

NO

8-3

（２） 変更管理登録

（ア） 仕様変更要件起票

・プロジェクト管理事務局、開発受託者が仕様の変更につながる可能性のある問題・要件が発覚

した際に、変更管理台帳に記帳し、ステータスを「新規」に変更する。

（イ） 仕様変更要件合否判定案作成（代替案・影響分析）

・プロジェクト管理事務局、開発受託者が仕様変更要件としての妥当性を仮判定する。

・仕様変更として妥当性(合格)と判断された場合には個別進捗会議用に対応案検討、影響分析、

スケジューリングを行う。

・仕様変更として妥当性(不合格)と判断された場合には個別進捗会議用に代替案検討を行う。

・影響分析、代替案を検討し、実施しなかった場合の影響を整理する。

・影響分析中には変更管理台帳のステータスを「影響分析中」に変更する。

（ウ） 報告内容承認・改善指示

・仕様変更要件合否判定において合格となった案件について、仕様変更の実施可否の判定を行う。

却下、もしくは延期する場合は業務運用上の代替案の方向性についても検討・採択し、延期する

場合はさらにおおよその実施時期についても検討・採択する。

・仕様変更要件合否判定の結果を受け、変更管理台帳のステータスを「実施承認」もしくは「却

下」「延期」に変更する。

・原則、仕様変更実施可否判定会議の場においてすべての案件の実施可否判定を次週に繰り越す

ことなく行うこととする。

（エ） 報告・指示確認

・仕様変更要件合否判定において合格となった案件について、案件内容の報告を行う。

・報告内容承認・改善指示で可決した結果を受けて、今後の作業について指示を受ける。

（オ） 報告内容承認・実施指示

・個別進捗会議の結果報告を受け、仕様変更の実施可否の判定を行う。

・実施可となった案件について実施指示を出す。

（カ） 報告・指示確認

・個別進捗会議で出た結果をプロジェクト責任者・プロジェクト全体管理者に報告を行う。

・プロジェクト責任者・プロジェクト全体管理者に報告を行い、結果確認を行う。作業指示が出

た場合には開発受託者に作業指示を出す。

（キ） 仕様変更の作業実施

・個別進捗会議において実施可となった仕様変更案件について、開発受託者が即座にチーム別作

業スケジュールに反映し、割り当てられた作業担当者に通告する。なお、影響範囲に記述された

すべての対象に対応がとられるよう、関係各所と調整のうえスケジューリングする。

・変更管理台帳のステータスを「対応中」に変更する。

・変更となった仕様については、該当する仕様書等の変更箇所の修正を行う。

（ク） 仕様変更完了確認

・プロジェクト管理事務局は完了となった作業について、開発受託者から提出された仕様変更対

象成果物の確認を行う。実質的な仕様変更作業はここで完了とする。

8-4

（ケ） 作業完了報告

・仕様変更作業が終わった案件について、プロジェクト管理事務局に仕様変更対象成果物を提出

する。

（コ） 変更管理台帳更新

・仕様変更完了となった案件の変更管理台帳のプロジェクト管理事務局から仕様変更完了の確認

をとれた項目のステータスを「完了」に変更する。

8.3 留意事項

・ 完成前の成果物に対する変更の管理は、開発受託者が定める手順に従う。

・ 要件定義設計書に対する変更管理は、基本設計以降から開始する。

・ その他の変更管理の開始時期は、別途通知する。

9-1

9. システム構成管理要領

情報システムを構成するシステム資産を、システムのライフサイクルに沿って適切な時期に調達し、管理

する。

9.1 システム構成管理とは

9.1.1 管理対象システム資産の明確化

情報システム構成するシステム資産（ハードウェア、ソフトウェア、ネットワーク）から、管理対象とす

るものを抽出する。

9.1.2 システム資産別管理項目及び相互関係の明確化

変更管理の影響調査等に活用するため、各システム資産の管理項目及び相互関係を示す。

（１） ハードウェア

管理番号、分類、メーカー、品番、シリアル番号、取得価額(リース料)、数量、購入日、廃棄日、

設置場所、OS、バージョン、実装メモリ、ディスク容量 等

（２） ソフトウェア(パッケージソフトウェア)

管理番号、分類、名称、バージョン、取得価額、数量、購入日、廃棄日、契約ライセンス数、使用

済ライセンス数、媒体保管場所 等

（３） ネットワーク (WANの場合)

管理番号、分類(アクセス回線、中継回線)、ネットワーク種類、帯域、設置拠点、月額料金、契約

開始日、契約終了日 等

9.1.3 システム資産別管理項目の更新・維持

システム資産の新規導入、変更、追加、削除等のタイミングで適宜情報を更新し、変更履歴を保持する。

9.2 留意事項

要件定義ではシステム資産を取り扱わないため、システム構成管理にかかる作業は実施しない。

10-1

10. リスク管理要領

リスク管理の目的は、事前にリスクを洗い出し適切に管理することで計画遂行への阻害要因を受け入れら

れる程度にとどめ、リスクが顕在化した際の手戻り等を最小化することにある。

10.1 リスク管理とは

10.1.1 リスクの定義

リスクとは、もしそれが顕在化した場合、時間、工数、品質等に深刻な影響を及ぼす可能性のある事象で

ある。

10.1.2 リスク管理の実施者

本標準におけるリスク管理の実施者は開発受託者とする。開発受託者は、立案したプロジェクト計画書に

対し、客観的な立場からリスク管理計画を立案する。

他の開発受託者は、事務局の要請に応じて、リスクの洗い出しや対策検討などのリスク管理作業に協力す

る。事務局は、全体進捗会議にて新規リスクの報告等を行う。

開発受託者内におけるリスクについても、適切なリスク管理が実施されることを前提とする。

10.2 リスク管理のワークフロー

リスク管理のワークフローを以下に示す。(図10-1)

図 10-1 リスク管理のワークフロー

管理 管理

リスクの終了リスクの監視リスク計画の立案リスクの洗い出し

開発受託者

プロジェクト

管理事務局

④③②①

管理台帳起票・リスク内容の記載

計画立案・リスク対策の記載

課題・問題

予防対策の実施

監視・再評価・事後対策の実施

リスク報告・新規リスクの評価

課題・問題

事後対策の実施

終了判断・リスク状況の判定

終了承認計画承認

・リスク対策の記載

リスク洗い出し

予防対策なし

事後対策なし

管理 管理

リスクの終了リスクの監視リスク計画の立案リスクの洗い出し

開発受託者

プロジェクト

管理事務局

④③②①

管理台帳起票・リスク内容の記載

計画立案・リスク対策の記載

課題・問題

予防対策の実施

監視・再評価・事後対策の実施

リスク報告・新規リスクの評価

課題・問題

事後対策の実施

終了判断・リスク状況の判定

終了承認計画承認

・リスク対策の記載

リスク洗い出し

予防対策なし

事後対策なし

個別進捗会議

10-2

10.2.1 リスクの洗い出し

開発受託者は以下の観点でリスクを洗い出し、リスク管理台帳に記入する。

（１） 費用に関するリスク

費用に関するリスクは、間接業務システムが当初想定したファイナンシャルプラン通りに進捗し

ないリスクである。費用には設計、開発、運用の各工程で発生する問題を解決するために必要とな

る追加費用を含む。

（２） スケジュールに関するリスク

スケジュールに関するリスクは、納期内での作業未達成に関するものである。このリスクは、ス

コープ変更や要員不足及び費用に関するリスクの解決のために発生する追加作業等を原因として

発生する。

（３） 技術的なリスク

技術的なリスクは、想定されているアプリケーション仕様及び期待されている効果が得られない

リスクを表す。このリスクは、新規・標準外プラットホーム技術の採用、現行システムとの統合、

移行、パフォーマンス非現実性、システム環境の複雑性といった問題から発生するリスクである。

（４） 運用に関するリスク

運用に関するリスクは、アプリケーションの開発により発生する組織変更、業務変更に関するリ

スクである。このリスクは、必要な組織・業務変更を円滑に実現するために必要な教育に関するリ

スクや、システム移行リスクを含むものである。

（５） 外部要因によるリスク

外部要因によるリスクは、間接業務システムの管理外である環境的要因に関するリスクである。

このリスクは、間接業務システム開発の成功に直接的・間接的に影響を及ぼし、法的要件等から発

生するものである。

10.2.2 リスクの数値化

認識したリスクは、その影響度合と発生確率をもとに、以下の計算式で数値化し、識別されたリスク軽減

活動や是正処置のより効果的な優先順位付けを実現するとともに、リスクの解決進捗状況を監視する。

Risk Exposure（危険度合）=Impact（影響度合）× Probability（発生確率）

10-3

10.2.3 リスク管理計画の立案

洗い出されたリスクに対して、それぞれ下記の観点でリスク管理計画を立案する。リスクが顕在化する前

に予防策を実行し、リスクの除去あるいはリスクの軽減を図る。

リスク管理計画の立案に当たってはそのリスクが顕在化する条件及び兆候、リスクが顕在化した際の具体

的な影響範囲等を記載する。

（１） 回避策

原因を取り除くことにより、ある特定の脅威を回避する。全てのリスクを取り除くことはできな

いが、特定のリスクを回避することは可能なものもある。

（２） 軽減策

特定の処置を講じて、リスクの発生確率及び顕在化した場合の開発プロジェクトへの影響の軽減

を図る。例えば、技術、工数、スケジュール上のリスクを減らすために実績のある技術を用いる等。

（３） 受容策

リスクを受け入れる。回避策や軽減策の立案が困難であり、且つリスクが顕在化した際の影響範

囲、影響度等が受け入れられる程度のものである場合に採用する。また、リスク評価（影響度、発

生確率の乗積）が高いもの及び予防対策において受容策しか立案できないものについては事後対策

も用意する。立案されたリスク管理計画について、事務局は内容を確認し、承認する。リスク管理

計画における予防対策の実施は、課題・問題管理にて実施する。

10.2.4 リスクの監視及び再評価

全体進捗会議において、前述の各リスクの概要を記したリスク管理台帳により、各リスクの状況に変化が

ないか、また各リスクが顕在化していないか等を確認する。

また、新たに認識されたリスクについてリスク管理台帳への反映が完了しているかも合わせて確認する。

リスク顕在化に伴う事後対策の実施は、ワークフロー（図10-1）に示された課題・問題管理にて実施する。

10.2.5 リスクの終了

事前に洗い出され、リスク管理計画が立案された各リスク項目において、そのリスクが発生する可能性が

なくなった場合や、リスクが顕在化し、リスク管理計画を実施したことにより、リスクそのものがなくなっ

た場合はリスクが終了したとみなす。

11-1

11. 文書管理要領

文書管理とは、設計・開発工程で作成され、事務局が入手した全ての文書を、その記述内容・媒体等に応

じて適切に保管・管理することである。

11.1 文書管理とは

文書を入手・作成した事務局が、当該文書の管理者となることを基本方針とする。

文書管理は、標準文書、システム文書（要件定義設計書等）、開発プロジェクト文書（議事録等）を対象と

する。それぞれの管理においては、以下の点を考慮する。

・可用性管理 ：必要なときに使える状態になっていること

・完全性管理 ：記述内容が正しい状態で保たれていること

・構成管理（変更管理） ：最新状態であることを保証し、変更履歴を保持すること

管理対象となる文書に対し、文書番号、文書タイトル、作成担当、発行日、版番号を記録し、保管を行う。

また保管された文書に対し、文書の改ざん・紛失等を防止し、その構成を最新の状態に維持し、過去に加え

られた変更の履歴を保持する。

なお、当管理要領では、媒体種別（電子媒体及び紙媒体）は問わないが、電子媒体での取り扱いを推奨す

る。

11.2 文書管理の詳細

11.2.1 文書番号

管理対象文書には文書番号を割り当てる。文書番号の体系を以下のように定義する。（図11-1）

図11-1 文書番号体系

X X - 9 9 - 9 9 9 9 部門分類

カテゴリ

システム分類 通し番号(0001－9999)

X X 9 9 9 9 9 - X 9 9 - 9 9 9 9 プロジェクト番号

担当コード

・システム文書

・開発プロジェクト文書

部門分類

カテゴリ

文書分類

通し番号(0001－9999)

X X - 9 9 - 9 9 9 9 部門分類

カテゴリ

文書分類 通し番号(0001－9999)

・標準文書

11-2

文書番号のコードは以下のように定義する。(図11-2)

なお担当コードの指定は、各開発プロジェクトで判断する。（指定無しの場合は“Z”を選択）

文書体系 ・標準文書

部門分類 カテゴリ 文書分類 通し番号

記号 内容 記号 内容 － 記号 内容 － 記号 内容

30 開発管理標準

31 開発管理標準に係る

運用規約

B

間接業

務シス

テム

R 標準文書

0001

～

9999

＊文書分類ごとに

0001からの通番とする

・システム文書

部門分類 カテゴリ 文書分類 通し番号

記号 内容 記号 内容 － 記号 内容 － 記号 内容

01 間接業務システム

02

03 B

間接業

務シス

テム

S システム

文書

04

0001

～

9999

＊文書分類ごとに

0001からの通番とする

・開発プロジェクト文書

部門分類 カテゴリ プロジェクト番号 担当コード 文書分類 通し番号

記号 内容 記号 内容 記号 内容 － 記号 内容 記号 内容 － 記号 内容

08001 間接業務システム AD 工程管理業務 01 プロジェクト計画書

08002 KS 間接業務システム 11 進捗報告書

08003 ZZ 共通 21 レビュー報告書 B

間接業

務シス

テム

P システム

文書

08004

＊以降、上２桁は年度、

下３桁は通番とする

22 品質評価報告書

0001

～

9999

＊文書分類ご

とに

0001からの

通番とする

31 課題管理台帳

32 質問管理台帳・質問票

33 通知管理台帳・通知票

41 リスク管理台帳

51 情報管理台帳

71 進捗会議議事録

72 課題検討会議議事録

73 品質評価会議議事録

81 説明資料等（事務局作成）

91 お知らせ等（事務局作成）

図11-2 文書番号コードの発行ルール

（例1）開発管理標準の場合：BR-30-0001

（例 2）間接業務システムプロジェクトの間接業務システム開発受託者の第 1回進捗会議議事録の場合：

BP08001-KS71-0001

開発プロジェクト文書のコードの中で、担当コードと文書分類については、プロジェクトごとに定めるこ

ととする。間接業務システムにおける、担当コードと文書分類の対応表を以下に示す。（表11-1）

11-3

表 11-1 担当コードと文書分類の対応表

工程管理業務

間接業務システム

共通

担当

コード

文章分類 AD KS ZZ

プロジェクト計

画書 01

全体実施

計画書 個別プロジェクト計画書 NA

進捗報告書 11 進捗報告書(全体) 進捗報告書（個別） NA

レビュー報告書 21 レビュー報告書 NA

品質評価報告書 22 品質評価

報告書（全体） 品質評価報告書 NA

課題管理台帳 31 課題管理台帳 NA

質問管理台帳・

質問票 32 質問票（開発受託者→事務局）

課題管理台帳 33 課題管理台帳 NA

通知管理台帳・

通知票 34 NA 通知票（事務局→開発受託者）

リスク管理台帳 41 リスク管理台帳 NA

情報管理台帳 51 情報管理台帳 NA

進捗会議議事録 71

全体

進捗会議

議事録

個別進捗会議議事録 NA

課題検討会議

議事録 72

課題検討

会議議事録 NA

品質評価会議

議事録 73

品質評価

会議議事録 NA

説明資料等

（事務局作成） 81

説明資料等

(事務局作成) NA

お知らせ等

（事務局作成） 91

お知らせ等

(事務局作成) NA

凡例； ；0001～0009 ；0001のみもしくは枝番なし NA；該当文書なし

11-4

表 11-2 「標準文書」における文書分類の適用

文書分類 分類の基準 適用される様式 該当する文書例

30.開発管理標準 ・間接業務システムの

開発管理に係る標準を

定義する。

なし ・開発管理標準

31.開発管理標準に係る

運用規約

・管理に係る手順の詳

細を定義する。

なし ・開発管理標準に係る運用規約

表 11-3 「開発プロジェクト文書」における文書分類の適用

文書分類 分類の基準 適用される様式 該当する文書例

01．プロジェクト計画書 当標準のプロジェクト

計画書策定手順で示さ

れる、各種プロジェク

ト計画書、及びその付

随文書。

1-1 プロジェクト計画

書

1-2 プロジェクト計画

書別紙

・事務局による全体プロジェクト計画書

及び各々WBS等の付随文書。

11.進捗報告書 当標準の進捗管理要領

で示される、各種進捗

管理報告書、及びその

付随文書。

3-1 進捗報告書(全体)

3-2 進捗報告書(個別)

3-3 EVM報告書

3-4 ガントチャート

・開発受託者による個別週次/月次進捗報

告書

・事務局による全体週次/月次進捗報告

・事務局によるPMO向け進捗/完了報告

・各々品質管理報告書と課題管理台帳を

除く付随文書

21.レビュー報告書 当標準の品質管理要領

で 示さ れる 各種レ

ビューのうち、ピアレ

ビュー･ウォークス

ルーレベルを除く、各

種レビュー報告書。

4-1 レビュー報告書

（兼追跡票）

・開発受託者による（インスペクション

A）レビュー報告書

・事務局を含む各受託者による（インス

ペクションB）レビュー報告書

22.品質評価報告書 当標準の品質管理要領

で示される品質評価会

議に提出される品質評

価報告書。

4-2 品質評価報告書

4-3 品質評価報告書

（工程完了）

・開発受託者による品質評価報告書

・事務局による品質評価報告書（総括）

・開発受託者による品質評価報告書（工

程完了）

31.課題管理台帳 当標準の課題・問題管

理要領で示される、開

発受託者別の課題管理

台帳。

5-1 課題管理台帳 ・開発受託者による個別課題管理台帳

・事務局による全体課題管理台帳

32.質問管理台帳・質問票 当標準の課題・問題管

理要領で示される質問

管理台帳、及び質問票。

5-2 質問管理台帳

5-3 質問票

・事務局による質問管理台帳

・開発受託者による質問票

11-5

文書分類 分類の基準 適用される様式 該当する文書例

33.通知管理台帳・通知票 主に成果物作成に影響

のある仕様等に関する

通知等。当標準の課

題・問題管理要領で示

される通知管理台帳、

及び通知票。

5-4 通知管理台帳

5-5 通知票

・事務局による通知管理台帳

（91：お知らせ等と 33：通知票の双方を

対象とする)を含む開発受託者による通

知票（会議開催通知等）に対する通知票

41.リスク管理台帳 当標準のリスク管理要

領で示されるリスク管

理台帳。

6-1 リスク管理台帳 ・開発受託者による個別リスク管理台帳

・事務局による全体リスク管理台帳

51情報管理台帳 当標準の情報セキュリ

ティ管理要領で示され

る情報管理台帳。（開

発受託者用）

7-1 情報管理台帳 ・開発受託者による個別情報管理台帳

71.進捗会議議事録 当標準の進捗管理要領

で規定された各種進捗

会議の議事録。

2-1 議事録 ・各個別開発受託者による個別進捗会議

議事録

・事務局による全体進捗会議議事録

72.課題検討会議議事録 当標準の課題･問題管

理要領で規定された各

種課題検討会議の議事

録。

2-1 議事録 ・各受託者による課題検討会議議事録

73.品質評価会議議事録 当標準の品質管理要領

で規定された各種品質

評価会議の議事録。

2-1 議事録 ・各受託者による品質評価会議議事録

81.説明資料等

（事務局作成）

事務局自身が作成した

資料で、開発受託者に

直接個別には包含され

ないもの。事務局の指

示により、保管する資

料。

・説明会資料及び関連の追加資料等、各

種事務局作成資料

・事務局指示により保管するプロジェク

ト外資料

91.お知らせ等

（事務局作成）

事務局作成によるプロ

ジェクト運営上の連絡

事項等事務局作成によ

る会議開催案内や当標

準の運用ルールなどに

関するお知らせ等独自

に採番できないプロ

ジェクト外資料の開示

(通知票の添付資料と

して）通知票単独、又

は通知票と付随文書

（単独または文書群）の

形をとる。

5-5 通知票 ・事務局による、会議開催・関連通知を

行う通知票

・事務局による、標準規則等の解説・補

足通知

・事務局による、規約等の配布

・事務局が開示する、プロジェクト外資

料の配付（通知票は、いずれも33：通

知票フォーマットに準じる）

11-6

注釈：

11.進捗報告書 付随文書のうち、独自の文書分類を持っているもの（品質管理報告書と課題管理

台帳）は、除外する。

22.品質評価報告書 付随文書のうち、独自の文書分類を持っているもの（レビュー報告書）は、

除外する。

33.通知管理台帳・通知票 通知管理台帳は 33：通知票以外に、91：お知らせ等 でも使用する点

に留意のこと。

11.2.2 文書管理者

開発プロジェクトでは、事務局が文書管理者の役割を担う。

文書管理者の役割を以下に示す。

・文書番号の管理

・ファイルサーバのフォルダ構成の管理

・保管庫の管理

11.2.3 保管方法

（１） 電子媒体

事務局が受領・作成した電子媒体文書は、事務局にて管理するファイルサーバに保管する。開発受託

者とのデータ共有は想定していないので、開発受託者はそれぞれの責任範囲において、適切な文書管理

を実施する。

（２） 紙媒体

事務局が受領・作成した紙媒体文書は、事務局にて管理する保管庫に保管する。機密文書を保管する

際は、施錠した保管庫に保管する。

11.2.4 ファイル名（電子媒体文書の場合のみ）

電子媒体文書のファイル名は、以下のように定める。(図11-3)

図11-3 電子媒体文書のファイル名

（例）2008年12月27日に作成した開発管理標準の電子ファイル

20081227_BR-30-0001_開発管理標準.doc

YYYYMMDD_文書番号_文書名.拡張子 作成日付 内部文書：XX-99-9999

開発プロジェクト文書：

XP99999-X99-9999

11-7

11.3 文書管理のワークフロー

文書管理のワークフローを以下に示す。(図11-4)

図 11-4 文書管理ワークフロー

全体開発管理 受託者 開発受託者開発担当

ﾌﾟﾛｼﾞｪｸﾄ管理 開発受託者 プロジェクト管理事務局

文書登録 ・各受託者は、メールにて 事務局に登録文書を 送付する。 （紙媒体の場合は、持参または郵送とする） ・ 事務局は、作成または受領した文書の種別 （プロジェクト共通 / 個別）を確認し、管理レベルを判 定する ・事務局は登録情報を確認する。 ・電子ファイルはファイルサーバに登録し、紙文書は ファイリングする ・ 事務局は、メールにて登録された文書情報を 周知する。

文書の保管 （電子／紙）

登録文書の 更新通知

更新情報の 受領

登録情報の 受領

登録情報の 受領

文書の作成 ・提出 文書の作成

管理レベル判断 （個別

/ 共通）

12-1

12. 情報セキュリティ管理要領

当管理要領では、開発プロジェクトの設計･開発業務を外部委託するにあたり、開発受託者に対する要求事

項を定める。委託先においても厚生労働省情報セキュリティポリシーと同等の情報セキュリティ管理を実施

させるための基準を示すことを目的とする。

なお、事務局側における情報セキュリティ管理は、厚生労働省情報セキュリティポリシーに準拠して社会

保険庁が定める各セキュリティ関連規定に従うため、当管理要領の対象には含めない。

12.1 情報セキュリティ管理とは

12.1.1 適用範囲

貸借、請負その他契約に基づく役務のうち、情報処理に係る業務とする。以下に例を示す。

・統計、集計、データエントリー、媒体変換を含む情報の加工・処理

・情報システムの構築（ソフトウェア開発、運用、ASPサービス、保守、改修等含む。）

・その他調査・研究

・物品等の賃貸借（機器増設、保守、レンタルサーバ、ハウジング等含む。）

12.1.2 基本方針

（１） 開発プロジェクト個別のセキュリティ要件及び契約内容の優先

開発プロジェクトにおいて、個別のセキュリティ要件が提示されている場合、別途契約により定めら

れる場合（例：秘密保持契約の締結、等）は、その内容に従う。

（２） 提供情報等の複製

受託者における提供情報等の複製は原則禁止する。ただし、受託者において複製が必要であると判断

した場合には、予め社会保険庁に協議を行い、その承認を得なければならない。

（３） 秘密の保全

・受託者は、社会保険庁が交付又は使用を許可した機密情報等に限らず、業務を履行するにあたり知

り得た情報について、目的以外に使用又は第三者に開示若しくは漏洩してはならない。

・機密情報等及びその他情報等を第三者に開示することが必要な場合には、予め社会保険庁に協議を

行い、その承認を得なければならない。

12-2

12.2 情報セキュリティ管理の詳細

12.2.1 組織と体制の構築

実施体制や評価手順、違反や例外に関する措置に係る情報セキュリティ対策について、以下に示す。

（１） 組織・体制の確立

受託者内における情報セキュリティ対策に関する事務を統括する情報セキュリティ管理責任者

を設置し、以下のとおりのセキュリティ管理を実施する。

・定期的な情報セキュリティ教育の実施

・情報セキュリティ対策の遵守状況の監査

・情報セキュリティ障害発生時の対応

・その他情報セキュリティに関する管理全般

（２） 情報セキュリティ障害発生時における対応手順の整備

受託者内において、機密情報の漏洩等の情報セキュリティに係る障害が発生した場合、以下の対

処手順にて対応する。

（ア） 発生状況の報告

情報セキュリティ障害が発生した時は、受託者は速やかに情報セキュリティ管理責任者を通じ、

書面にて事務局に報告する。その際、漏洩等が発生した日時、場所、事由、情報取扱者を記載す

る。

（イ） 対応措置の実施

事務局の指示に基づき、情報漏洩等による影響調査および原因調査を行うと共に、必要な対応

措置を速やかに実施する。

（ウ） 報告書の提出

事務局が指定する期日までに、障害の具体的内容、原因、実施した対応措置等を内容とする報

告書を提出する。また、機密情報等の取扱い規定等の違反者については就業規則等に従って厳正

な処分を行い、その処分内容を事務局に通知する。

（エ） 再発防止策の策定･提出

セキュリティ障害に対する再発防止策を作成し事務局に提出する。事務局による承認を受けた

後、速やかにその再発防止策を実施する。

（３） 情報セキュリティ対策遵守状況の評価及び見直し

情報セキュリティ対策の実施状況を評価するため、受託者内にて内部監査を実施する。各対策が

計画通りに実施されているか、及びその有効性を確認し、事務局に報告する。なお、監査担当者は、

被監査部署以外の者を指定する。

また、社会保険庁が受託者に対して、情報セキュリティ確保が図られているか監査する旨を申し

出た場合は、定期・不定期に関わらず、これを受入れる。

内部監査及び社会保険庁による監査の結果、セキュリティ違反等の問題が生じた場合には、その

状況（問題発生の背景、対応措置の内容及び実施予定等）を事務局に報告するとともに、必要な対

応措置を速やかに実施する。

12-3

12.2.2 情報についての対策

情報の作成、利用、保存、移送、消去等といった情報のライフサイクルの各段階において、遵守すべき情

報セキュリティ対策を示す。

（１） 情報の格付け

開発プロジェクトの実施において、事務局が受託者に提供又は閲覧を許可した全ての情報（電子

データ及び印刷された資料を含む。以下「提供情報等」と言う。）及び提供情報等をもとに作成す

る成果物、関連資料等は、機密情報として取扱うことを基本とする。

（２） 情報の取扱い

機密情報については、以下の通り取り扱う。

（ア） 情報の作成と入手

・受託者は委託業務遂行以外の目的で、機密情報の作成または入手をしないこと。

（イ） 情報の利用

・受託者は委託業務遂行以外の目的で、機密情報を利用しないこと。

・機密情報を放置しないこと。

・機密情報は原則複製しないこと。複製が必要であると判断した場合には、予め社会保険庁の承

認を得ること。

（ウ） 情報の保存

・機密情報を電子計算機上に保存する場合は、適切なアクセス制御を行うこと。

・機密情報を電子計算機又は外部記録媒体に保存する場合は、暗号化の必要性を検討し、必要に

応じて暗号化を実施すること。

（エ） 情報の移送

・機密情報を移送する場合には、情報の内容及び移送手段について情報セキュリティ管理責任者

を通じて事務局に報告すること。

・機密情報である電磁的記録を移送する場合、パスワードを設定すること。

・機密情報である電磁的記録を移送する場合、暗号化による保護の必要性を検討し、必要に応じ

て暗号化を実施すること。

（オ） 情報の消去及び返却

・電子計算機、通信回線装置及び外部記録媒体を廃棄する場合は、データ消去ソフトウェア若し

くはデータ消去装置の利用又は物理的な破壊若しくは磁気的な破壊などの方法を用いて、すべ

ての情報を復元が不可能な状態にすること。

・電子計算機、通信回線装置及び外部記録媒体を再利用する場合は、必要に応じてデータ消去ソ

フトウェアを用いて、当該電子計算機等の要機密情報を復元不可能な状態にし、残留する要機

密情報を最小限に保つこと。

・機密情報が記録された書面を廃棄する場合には、復元が不可能な状態にすること。

（３） 情報管理台帳の作成

機密情報等の授受に関して、発生日、担当者等を記録するための「情報管理台帳」を作成すること。

12-4

12.2.3 情報システムの構成要素についての対策

開発プロジェクトの開発対象及び開発環境に対して考慮すべき点を以下に示す。プロジェクトにおいて、

より具体的な実施要領が必要な場合は、事務局より別途通知を行う。

（１） 入退室管理

（ア） 情報セキュリティ管理責任者は、機密情報を取扱う執務室内に開発プロジェクト外の者を立ち入

らせない措置を講ずる。

（イ） 情報セキュリティ管理責任者は、機密情報を取扱う執務室は他の領域から物理的に隔離し、立入

り及び退出が可能な場所を制限する措置を講ずる。

（ウ） 情報セキュリティ管理責任者は、機密情報を取扱う執務室への全ての者の立入り及び退出を記録

し及び監視する必要性を検討し、必要に応じて措置を講ずる。

（２） 電子計算機のセキュリティ確保

（ア） 情報セキュリティ管理責任者は、機密情報を取り扱う電子計算機が、安全管理上盗難及び無許可

の持出を防止する必要があると認められる場合、当該場所から移動できない措置を講ずる。

（イ） 情報セキュリティ管理責任者は、機密情報を取り扱う電子計算機が担当者離席時の不正操作や、

表示用デバイスの盗み見から保護する必要性を検討し、必要に応じて措置を講ずる。

（ウ） セキュリティホールまたは不正プログラム（ウィルス等）から電子計算機を保護するための対策

を講ずる。

（エ） 外部から入手した電子ファイルを外部記憶媒体等から読み込む場合は、ウィルス対策を実施する。

（３） 電子メール利用時のセキュリティ確保

（ア） 開発プロジェクトにて電子メールを使用する場合は、要員の不注意または故意による不正行為を

未然に防止するため、事務局の承認を受ける。

（イ） 電子メールに電子ファイルを添付する際は、パスワードを設定した圧縮ファイルを用いる。

（４） FAXの扱い

（ア） 要員の不注意及び故意による誤送信や出力後の放置を防止するため、FAXによる機密情報の送受

信は原則禁止とする。

13-1

13. プロジェクト計画書改訂手順

プロジェクト計画書の変更手順は、原則として変更管理要領に従うものとする。プロジェクト計画書の変

更例を以下に示す。

・作業範囲に関する変更

・スケジュールの変更

・受託者の体制に関する変更

・管理手続きの変更

・その他の変更

14-1

14. 実施計画完了手順

計画に関連する成果物の納品及び検収作業が完了すると、実施計画は完了する。当該実施計画を担当する

事務局は、実施計画に関連する記録を整理し、社会保険庁の文書管理手続きに従って記録の保管手続きを行

う。

15-1

15. 標準書改訂手順

当標準の改訂が必要な場合、マネジメントグループが改定案を策定し、プロジェクト総括が承認する。

付録-1

付録 用語集

ア

アクター

システムと相互作業を行うシステムを利用するユーザや外部システムを表したもの。UMLのユー

スケース図の要素の一つ。

インスペクション

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

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

上げ、その過程で参加者が欠陥を発見していく熟視テストを指す。フォーマルなエラー・ログ

の記録，修正状況のトラッキングと再発防止のための作業工程へのフィードバックなど，ウォー

クスルーに比べやや形式的に運営される。

インターフェース

異なる機能単位同士が接続する部分を指す。コンピュータとそれを操作する人間との間の規約

や操作方法、システムからの情報の提示方法などは特にユーザ・インターフェースと呼ばれる。

ウォークスルー

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

書の作成は義務づけず、参加者はよりフランクな形で内容の検討に注力する。作業ガイドや標

準規約の理解と徹底、担当者間の個人差をなくすなどの効果がある。より自由度をあげた形が

ピアレビューである。

エスカレーション

課題・問題の解決にあたり、その内容に応じて組織内の上位レベルに報告し、判断を仰ぐこと

を指す。

エンティティ（DB）

システム化対象業務において管理すべき実態を指す。具体的には，「得意先」「商品」「商品区

分」「売上」などで、エンティティは一般的に名詞になる。

エンティティ（ユースケース）

データ管理を行うオブジェクトを指す。(ユースケース表記）

オペレーター

コンピュータ端末の操作者を指す。

カ

課題・問題

開発の阻害要因となる課題または問題を指す。他の開発受託者や社会保険庁業務に影響を与え

たり、社会保険庁の判断・対応が必要となったりするため、課題管理台帳による対応が必要と

なる。

ガントチャート

人員、工程管理などに用いられる帯状のグラフ。横軸に時間、縦軸に人員、作業項目等を配置

し、工程ごとの個別の作業開始日、作業完了日などといった情報を帯状に示す。

クリティカルパス

ネットワークダイアグラム（作業関係図）において、その部分の遅れが全体の遅れとなるよう

な作業パス（経路）を指す。これは全体作業の始点から終点にいたる経路の中で、時間的に最

も長い経路にあたるので、重点管理の指標として有力な情報となる。

厚生労働省情報セキュリティポリシー

厚生労働省が所有する情報資産の情報セキュリティ対策について、省が総合的・体系的かつ具

体的にとりまとめたもの。どのような情報資産をどのような脅威から、どのようにして守るの

かについての基本的な考え方並びに情報セキュリティを確保するための体制、組織及び運用を

含めた規定。

付録-2

コントロール（ユースケース）

制御を受け持つオブジェクトを指す。(ユースケース表記）

サ

サブシステム

システムを複数の機能に分割した、個々の機能。

サンプリング

統計調査などを行う際に、母集団全体の性質を調べるために一部を抽出する行為のこと。無作

為抽出(ランダムサンプリング)などがよく知られている。

四分位図（箱ひげ図）

ばらつきのあるデータをわかりやすく表現するための統計学的グラフ。細長い箱と、その両側

に出たひげで表現されることからこの名がある。

タ

データ・ディクショナリー

データベースに保存しているデータの属性とそのデータ項目を使っているファイルとの関係を

管理しているものを指す。

データベース

大量のデータを効率よく管理するためのソフトウェア。カード型、リレーショナル型などがあ

る。

電子署名

電子文書の正当性を保証するために付けられる署名情報。文字や記号、マークなどを電子的に

表現して署名行為を行なうこと全般を指す。

トラッキング

追尾、あるいは追跡調査を指す。

トランザクション

関連する複数の処理を一つの処理単位としてまとめたもの。一連の作業を全体として一つの処

理として管理するために用いる。

ナ

内部監査

組織が自身の組織のマネジメントシステムが有効に運営されていること、あるいはマネジメン

トの目的が達成されているかどうかの観点も含めて確認する手段。情報セキュリティ対策の有

効性を確認するために実施する一連のプロセスもこれに相当する。

ハ

バウンダリー

アクターからイベントを受け取る役割オブジェクトを指す。(ユースケース表記）

バッチ

一連の処理手続きを何らかの方法で記述し、一括してコンピュータで処理できるようにしたも

の。

ピアレビュー

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

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

をあげた形にしたもの。

付録-3

ヒストグラム

数量化できる要因や特性のデータについて、そのデータが存在する範囲をいくつかの区間に分

け、その区間の幅を底辺とし、その区間に含まれるデータの度数に比例する面積をもつ柱(長方

形）を並べた棒グラフを指す。

ファイルサーバ

事務局内における文書共有を図るため、成果物及びプロジェクト文書の電子媒体を保管する仕組

みを指す。

ファンクションポイント（法）

ソフトウェアの規模を測定する手法の 1つ。開発工数の見積もりに利用される。ソフトウェア

の“機能”を基本にして、その処理内容の複雑さなどからファンクションポイントという点数

を付けていき、ソフトウェアのすべての機能のポイントを合計して規模や工数を導き出すもの。

プラットフォーム

アプリケーションソフトを動作させる際の基盤となるハードウェア、OS、ミドルウェアなどを

指す。

ブレインストーミング

自由に意見を出し合い、あるテーマに関する多様な意見を抽出する発想支援法のひとつ。質よ

り量を重視し、お互いの意見に批判をせず、自由に意見を出し合うことで、問題解決などに資

する知識を洗い出すことができる。

プロトコル

ネットワークを介してコンピュータ同士が通信を行なう上で、相互に決められた約束事の集合。

通信手順、通信規約などと呼ばれることもある。

プロトタイプ

実機を用いてパッケージ標準機能を評価し、新システムのビジネスプロセスの実現性を判断す

る手法。

ベースライン

特定の時期に公式に確定された当初計画値を指す。各時点での実績値とは、このベースライン

に、その確定以降に実施された変更情報を加えたものである。

マ

マイルストーン

プロジェクトの中で工程遅延の許されないような大きな節目のことを指す。プロジェクトマネ

ジメントにおいては、マイルストーンに間に合うかどうかという観点で、現在の進捗状況等の

情勢判断することが重要となる。

ヤ

ユースケース

利用者の観点で記述した、システムの振る舞いの単位であって、シナリオ（ユースケース記述）

として記述できるまとまりとして、一定の価値を利用者に提供するもの。一般的には動詞で表

現する。

ラ

ライフサイクル

システムの調査・計画段階から、設計・開発を経て、運用・維持管理に至るすべての段階を指

す。

レビュー工数

レビュー実施にかかった工数を指す。レビュー時間×参加人数で求められる。