情報システム開発プロジェクト管理要領 · 3 プロジェクト管理について「図1 本管理要領の位置付け」で示したとおり、プロジェクト管理は、プロジェクト

Copyright (C)Matsumoto City 2012 All rights reserved.

情報システム

開発プロジェクト管理要領

Ver.1.03 Date 平成 23 年 9 月 30 日


Table of contents

1 情報システム開発プロジェクト管理要領の目的 .................................... 4

2 情報システム開発プロジェクト管理要領の構成と位置付け ................. 4

3 プロジェクト管理について .................................................................... 5

3.1 プロジェクト内における管理対象及び管理方法 ........................... 5 3.2 管理指標に関して ........................................................................... 6 3.3 進捗管理 ......................................................................................... 6 3.4 調整事項管理 .................................................................................. 9 3.5 リスク･課題管理 .......................................................................... 11 3.6 品質管理 ....................................................................................... 15 3.7 文書管理 ....................................................................................... 19 3.8 変更管理 ....................................................................................... 23 3.9 情報セキュリティ管理 ................................................................. 25 3.10 緊急対策計画の策定 ..................................................................... 29


変更履歴

Ver. 更新日更新者更新内容備考

1.00 平成 22年 4月 9日宮尾初版作成。

1.03 平成 23年 9月 30日宮尾平成 22年度抽出の課題に対する改善内容を反映。


4

1 情報システム開発プロジェクト管理要領の目的

情報システム開発プロジェクト管理要領は、情報システム開発プロジェクトを想定通りの品質・コスト・期間で確実に推進させるために行うプロジェクト管理の方法論を取りまとめた、松本市標準管理要領である。本書においては、設計・開発・テストなどのシステム開発の各段階で共通的に実施すべきプロジェクト管理の手順、作成すべきドキュメント等を体系的に整理し、松本市としてのプロジェクト管理方法を標準化するために作成されたものである。本要領に従い情報システムを構築することで、想定通りの品質・コスト・期間で情報シ

ステムが構築できることを目的とするものである。

2 情報システム開発プロジェクト管理要領の構成と位置付け

本管理要領は、基本設計や詳細設計、製造･単体テスト等、開発プロジェクトの各プロセスにおいて共通的に実施するプロジェクト管理（進捗管理、調整事項管理、リスク・課題管理、品質管理、文書管理、変更管理、情報セキュリティ管理）、またプロジェクトの進捗等が当初の計画から著しく逸脱した時に策定される緊急対策計画等から構成される。

図 1 本管理要領の位置付け

事業評価

評価ガイドライン


設計設計・・開発開発・・運用運用

開発ガイドライン開発ガイドライン

プロジェクトの立上げ

機能／非機能要件の確定

基本設計

詳細設計

プログラム設計

製造／単体テスト

結合テスト

総合テスト

運用テスト

運用

緊急対策計画緊急対策計画Emergency PlanEmergency Planによる是正による是正

移行

教育・研修

システム切り替え

マニュアル作成

進捗管理

リスク･課題管理

品質管理

文書管理

変更管理

情報セキュリティ管理

：情報システム開発プロジェクト管理要領

調達

調達ガイドライン


調整事項管理

事業評価



設計設計・・開発開発・・運用運用

開発ガイドライン開発ガイドライン

プロジェクトの立上げ

機能／非機能要件の確定

基本設計

詳細設計

プログラム設計

製造／単体テスト

結合テスト

総合テスト

運用テスト

運用

緊急対策計画緊急対策計画Emergency PlanEmergency Planによる是正による是正

移行

教育・研修



移行

教育・研修



進捗管理

リスク･課題管理

品質管理

文書管理

変更管理

情報セキュリティ管理

：情報システム開発プロジェクト管理要領：情報システム開発プロジェクト管理要領

調達



調整事項管理


5

3 プロジェクト管理について

「図 1 本管理要領の位置付け」で示したとおり、プロジェクト管理は、プロジェクトの開始から終了まで一貫して実施すべき事項である。以下、プロジェクト管理における進捗、調整事項、リスク・課題、品質、文書、変更、情報セキュリティに関する管理方法を定義する。

3.1 プロジェクト内における管理対象及び管理方法

前述の通り、プロジェクトを遂行するにあたっては、進捗管理、調整事項管理、リスク･課題管理、品質管理、文書管理、変更管理、情報セキュリティ管理の側面から管理を行う必要がある。

管理項目概要進捗管理各工程における計画・スケジュールに対する状況を可

視化し、プロジェクト関係者全員で定期的に確認することによってプロジェクトが円滑に遂行されているかを認識するとともに、遅延が発生した場合の影響範囲を可視化し調整を行う。

調整事項管理プロジェクトを推進していく中で随時取り決められる調整（TO-DO）事項を、発注者と事業者との間で共有し、円滑な業務実施を図る。

リスク･課題管理発注者と事業者の間でプロジェクトに潜在しているリスク･課題を認識･共有し、迅速にリスク･課題への対応策を立案･実施するために行う。

品質管理各種管理要領に従って適切なプロセスでプロジェクトを運営し、結果として高い品質の成果物を作成するために行う。

文書管理プロジェクトの遂行において作成及び入手した文書を容易に識別し、業務遂行における最新情報の共有等を効率化するために実施する。

変更管理 WBS、仕様書、設計書等に対して変更の必要性が生じた場合、変更範囲、担当者や責任者を明確化し、的確かつ迅速に把握･対応する。また、変更の履歴を管理する。

情報セキュリティ管理遵守すべき情報セキュリティポリシーに対してプロジェクト関係者の遵守状況を把握し、発生した情報セキュリティに関する課題に対して、プロジェクト内での協力･連携等の体制を確立･強化し、プロジェクト全体としてのセキュリティ水準の向上を図る。

表 1 管理項目一覧

各管理についての概要は上記の通りであるが、それらの目的、管理規程、定例報告基準等の詳細について、以下に説明を行う。


6

3.2 管理指標に関して

進捗やリスク・課題等、各管理においては管理指標を設定するものとする。各管理指標は、原則としてプロジェクトの進捗や品質等、当初の計画やプロジェクトの理想的な推進状態と比較してどの程度乖離しているか異常値を示すためのものであり、当該指標により異常値を定量的に顕在化させることによって、プロジェクトの失敗を未然に防ぐことを可能とするものである。

3.3 進捗管理

3.3.1 進捗管理の目的

進捗管理は、PMO 及び松本市所管課（以下、所管課）と事業者の間で合意された計画・スケジュールに対する状況を可視化し、プロジェクト関係者全員で定期的に確認することによって、プロジェクトが円滑に遂行されていることを認識するとともに、遅延が発生した場合の影響範囲を可視化し、調整をするために行う。

3.3.2 対象範囲

進捗管理を行う対象範囲は、当該システム構築事業における事業者の作業、及びこれに係る発注者の作業とする。

3.3.3 管理規程

進捗管理おいて実施する作業概要及び成果物を以下の図に纏める。

メンバーグループリーダー

プロジェクトリーダー

所管課 PMO

WBSの作成

�WBSガントチャート

IBRの実施 IBR報告

ワーキンググループレベルの管理WBS詳細版ガントチャート更新版

プロジェクト計画の変更WBS詳細版ガントチャート更新版

終結完了報告書の作成完了報告書

松本市

計画

実行・監視

プロセス作業主な成果物事業者

協議

実施

協議・承認

協議

協議

作成

WBS説明

まとめ

確認

作成

作成

作成

協議・承認

実施・承認

協議・承認

協議・承認

図 2 概要フロー図

3.3.3.1 計画プロセスでの管理

3.3.3.1.1 WBS の作成

(1) 事業者プロジェクトリーダーは、WBS、ガントチャートを起案し、

所管課及び PMO と協議して設定する。

(2) 事業者グループリーダーが各ワーキンググループレベルでの WBS

を定義する場合、その作業は事業者グループリーダーの作業に準

ずる。WBS 作成以降の作業に関しても同様である。


7

(3) 事業者グループリーダーが作成する WBS の最も細分化されたアク

ションアイテム（ワークパッケージ）の粒度については、極力 5

人日程度まで作業を詳細化する。また、作業期間が極力 2 週間

（実働 10 日）以内になるまで、作業を詳細化する。また、先行タ

スクとの関連性を可視化する。

(4) 作成した WBS は PMO 及び事業者プロジェクトリーダーとの間で

合意を得ることとする。

3.3.3.1.2 IBR（統合ベースラインレビュー）の実施

(1) 事業者プロジェクトリーダーは作成した WBS、ガントチャートに

ついて、所管課及び PMO との間で妥当性及び実現性を検討する。

(2) IBR は WBS、ガントチャートの新規作成及び変更を行った場合に

実施する。また、WBS をプロジェクトの進捗にしたがって段階的

に詳細化する場合にも IBR を実施するため、定例報告の冒頭で必

ず実施すること。

3.3.3.2 実行・監視プロセスでの管理

3.3.3.2.1 ワーキンググループレベルの管理

(1) 事業者グループリーダーは、WBS のタスクを実施する前に、必要

に応じて各ワーキンググループレベルの WBS を作成し、事業者プ

ロジェクトリーダー、所管課と協議して設定する。

(2) 事業者プロジェクトリーダーは、ワーキンググループ報告に必ず

出席し、事業者グループリーダーから、前回のワーキンググルー

プ報告からの進捗状況を確認する。

(3) 所管課は、ワーキンググループ報告に必ず出席し進捗状況を確認

する。進捗管理上のリスク及び課題については、事業者プロジェ

クトリーダー及び事業者グループリーダーへリスク及び課題管理

表の記載を依頼し、特に重大なものに関しては事業者プロジェク

トリーダーが PMO へ報告する。

3.3.3.2.2 プロジェクト計画の変更

(1) 事業者に起因する遅延等による WBS の対象範囲及び記載項目の追

加･変更･削除が発生した場合、事業者プロジェクトリーダーの指

示の元、事業者グループリーダーが修正（案）を作成し、事業者

プロジェクトリーダーが確認の後、所管課及び PMO と協議する。


8

最終決定は IBR にて行うこととする。

(2) 要件追加や外部環境の変化により、WBS の対象範囲及び記載項目

の追加･変更･削除が発生した場合、所管課が修正(案)を作成し、

PMO が承認の後、事業者プロジェクトリーダーと協議する。最終

決定は、IBR にて行うこととする。

3.3.3.3 終結プロセスでの管理

3.3.3.3.1 完了報告書の作成

(1) 事業者プロジェクトリーダーは、プロジェクト完了時に完了報告

書を作成し、所管課及び PMO に報告する。

(2) 完了報告書には、次フェーズに対する提言を整理して記載するこ

ととする。

3.3.4 定例報告基準

3.3.4.1 報告基準

以下の報告基準を使用して、進捗管理を実施する。

3.3.4.1.1 進捗管理

事業者プロジェクトリーダーは、プロジェクト開始時に、WBS、ガントチャートを起案し、所管課及び PMO の合意を得る。WBS、ガントチャートの新規作成及び変更に対する最終決定は IBR にて行う。事業者プロジェクトリーダーは、ワーキンググループ報告において

各グループからの進捗状況を取り纏め、定例事前報告にて管理指標を用いた報告を行う。進捗管理上のリスク及び課題については、リスク及び課題管理表へ記載し、事業者プロジェクトリーダー及び所管課の間で、経過報告･情報共有を行い、リスク及び課題解決策を検討する。なお、重大なリスク及び課題に関しては、PMO に対する報告も実施

すること。

3.3.4.2 管理指標

以下の管理指標を使用して、進捗管理を実施する。

事業者プロジェクトリーダーは、定例事前報告等において PMO に対し、当月の管理指標について、定例報告書に記載し報告する。

No 管理指標説明

1 プロジェクト進捗率実際に完了したタスクの計画日数

／全タスクの計画日数

2 計画乖離率（１－実際に完了したタスクの計画日数

／当初予定していたタスクの計画日数）＊１００


9

3 進捗遅延総日数報告時点で未完了の当初予定していたタスクの計画日数

※ ワーキンググループ毎に集計

表 2 管理指標一覧

3.3.5 添付資料標準フォーマット

定例報告書

3.4 調整事項管理

3.4.1 調整事項管理の目的

調整事項管理は、業務仕様書、プロジェクト計画書、ＷＢＳ等に変更のない事項や、定めがなく市と業者の間で依頼、確認、ルール化した詳細な事項を、調整（TO-DO）事項として取りまとめてプロジェクト関係者全員の共通認識とすることで、円滑なプロジェクトの業務実施を図るために行う。

3.4.2 対象範囲

調整事項管理を行う対象範囲は、当該システム構築事業における事業者の作業、及びこれに係る発注者の作業とする。

3.4.3 管理規程

調整事項管理において実施する作業概要及び成果物を以下の図に纏める。

メンバーグループ

リーダー

プロジェクト

リーダー所管課 PMO

計画調整事項の把握ち合意調整事項管理表

実行・監視調整事項の対応状況把握調整事項管理表

終結調整事項のクローズ調整事項管理表

プロセス作業主な成果物事業者松本市

確認・報告

協議承認

記入・確認記入記入・確認

記入評価

記入

確認



3.4.3.1.1 調整事項の把握と合意

(1) 事業者プロジェクトリーダー、事業者グループリーダー、所管課

ならびに PMO は、会議や打ち合わせ、メールや電話などを通じ

て取り決めた、作業指示や作業依頼といった調整（TO-DO）事項

を、ワーキンググループごとの調整事項管理表に記入し、メール

等により情報を共有する。

(2) 事業者プロジェクトリーダーならびに PMO は、随時、記入され

る調整事項の内容や対応者、作業期限に問題がないかを確認する。


10


3.4.3.2.1 調整事項の対応状況確認

(1) 調整事項管理表に記入を行った者は、会議や打ち合わせ、メール

や電話を通じて、調整事項の対応状況を随時確認する。

(2) 事業者プロジェクトリーダーは、定例事前報告において調整事項

管理表を所管課へ提出し、調整事項の対応状況を報告し、情報共

有を行う。なお、影響範囲が大きい、重要性が高い、または緊急

度が高い調整事項がある場合は、PMO へ報告するとともに、リス

ク管理表または課題管理表に転記し対応策を検討する。

(3) 所管課は、事業者プロジェクトリーダーによる報告を受けて、調

整事項の対応状況の妥当性を評価する。


3.4.3.3.1 調整事項対応完了の確認

(1) 調整事項の対応が完了された場合は、事業者プロジェクトリーダ

ーと PMO の間での合意の上、調整事項管理表のステータスを「対

応済み」に変更し、該当する事項をクローズする。


3.4.4.1 報告基準

以下の報告基準を使用して、調整事項管理を実施する。

3.4.4.1.1 調整事項管理

事業者プロジェクトリーダーは、各ワーキンググループの対応状況を取り纏め、定例事前報告にて管理指標を用いた報告を行う。調整事項管理上のリスク及び課題については、リスク及び課題管理表へ記載し、事業者プロジェクトリーダー及び所管課の間で、経過報告･情報共有を行い、リスク及び課題解決策を検討する。なお、重大なリスク及び課題に関しては、PMO に対する報告も実施

すること。

3.4.4.2 管理指標

以下の管理指標を使用して、調整事項管理を実施する。

事業者プロジェクトリーダーは、定例事前報告等において PMO に対し、当月の管理指標について、定例報告書に記載し報告する。


11


1 未対応調整事項総数確認時点で未対応になっている調整事項の総数

2 対応遅延調整事項件数確認時点で対応期限を過ぎても対応できていない調整事項の件数



調整事項管理表、定例報告書

3.5 リスク･課題管理

3.5.1 リスク･課題管理の目的

リスク･課題管理は、発注者と事業者の間でプロジェクトに潜在しているリスク･課題を認識･共有し、迅速にリスク･課題への対応策を立案･実施するために行う。本要領では、プロジェクト開始時に WBS を作成する中で認識された初期想定リ

スク、及び進捗管理を実施する中で認識されたリスク、顕在化した課題に対する対応プロセス等を定める。

3.5.2 対象範囲

リスク･課題管理を行う対象範囲は、当該システム構築事業における事業者の作業、及びこれに係る発注者の作業とする。

3.5.3 リスク及び課題の定義

プロジェクトを推進していくあたり、リスク及び課題の定義を以下とし、リスク・課題管理を実施することとする。

リスク：今後プロジェクト推進の阻害要因になりうると想定される事象課題：既にプロジェクト推進の阻害要因と認識された事象

3.5.4 管理規程

リスク･課題管理おいて実施する作業概要を以下の図に纏める。




所管課 PMO

リスク･課題の把握リスク管理表課題管理表

リスク･課題解決策の立案リスク管理表課題管理表

解決策の状況把握リスク管理表課題管理表

解決策の見直しリスク管理表課題管理表

終結リスク･課題解消の確認リスク管理表課題管理表

実行・監視

計画

松本市プロセス作業主な成果物

事業者

まとめ

立案

まとめ

見直し

記入

協議

協議

承認

承認

承認

記入

記入

協議

協議・承認

協議・承認


12


3.5.4.1.1 リスク･課題の把握

(1) 事業者グループリーダーは、リスク及び課題管理表を作成し、事

業者プロジェクトリーダーに対し報告を行う。事業者プロジェク

トリーダーは外部要因の状況把握も併せて行い、その際、新たな

リスク及び課題が認識されればリスク及び課題管理表に記入する。

(2) 事業者プロジェクトリーダーは、ワーキンググループ報告におい

てリスク及び課題管理表を所管課へ提出し、プロジェクトのリス

ク・課題を報告し、情報共有を行う。

(3) 所管課は、事業者プロジェクトリーダーのリスク及び課題報告を

受けて、リスク内容と対応策、課題内容と対応策の妥当性を評価

する。

(4) 事業者プロジェクトリーダーは、リスク及び課題の影響範囲が大

きいもの、重要性が高いもの、緊急度が高いものは PMO へ報告し、

リスク及び課題の対応策を検討する。

3.5.4.1.2 リスク･課題解決策の立案

(4) 事業者プロジェクトリーダーは、定例事前報告等において報告、

情報共有されたリスク及び課題について、対応策の立案、担当者

の決定を行い、その結果をリスク及び課題管理表に記載する。

(5) リスク及び課題の評価は、「影響範囲」「重要性」「緊急性」の

観点で行う。

(6) それぞれに関する、評価指標は以下の通りである。

分類内容影響範囲高：プロジェクト全体に影響を及ぼすリスク及び課題

小：ワーキンググループに影響を及ぼすリスク及び課題

重要性高：影響範囲の進捗（※1）が、10 日以上の遅延となるような、著しい進捗阻害リスク及び課題。また、それに準ずること。

中：影響範囲の進捗が、5 日以上の遅延となるような、進捗阻害リスク及び課題。また、それに準ずること。

低：影響範囲の進捗が、1 日程度の遅延となるような、進捗阻害リスク及び課題。また、それに準ずること。

緊急性（※2）

高：即時に対応を要するようなリスク及び課題

中：5 日以内に対応を要するようなリスク及び課題

低：必要に応じた期日を設定し、対応を要するようなリスク及び課題

表 4 リスク及び課題の評価指標

※ 1 「影響範囲の進捗」とは、リスク及び課題により影響を受ける全タ


13

スクの進捗を指す。リスクの場合には、想定される進捗の遅延、課題に

ついては既に発生している進捗の遅延と考える。影響範囲が「高」の場

合、プロジェクト全体に影響を及ぼすリスク及び課題であり、影響を受

けるタスクが広範囲に亘ると考えるため、その際に影響を受ける全ての

タスクの遅延日数の合計で、高低に分類する。但し、先行タスクが影響

を受けることにより連鎖的に遅延が発生する後続タスクの遅延日数は、

先行タスクの遅延日数に依存するため、加算対象とはする必要は無い。

※ 2 リスク及び課題の「緊急性」の観点は、現在の実施タスク及び次タ

スクの停滞度合いで考える。現在実施中の作業や現作業完了後に実施す

る作業がリスクや課題により停滞する場合、そのまま進捗の遅延に繋が

るため、緊急度は高となる。また、影響範囲や重要度が大きい場合でも、

作業に着手するまで期間がある場合には、緊急度は低となる。


想定状況が潜在的である場合、その項目はリスクとして取り扱う。計画プロセスにおいて想定状況が潜在的であるためリスクとしていた項目が、実行･監視プロセスにおいて顕在化した場合は課題として捉えて対応する。

3.5.4.2.1 解決策の状況把握と見直し

(1) 定例事前報告等において、事業者グループリーダーは各自が担当

となっているリスク及び課題の対応策の実施状況とその結果を、

事業者プロジェクトリーダーに報告、情報共有を行う。

(2) 事業者プロジェクトリーダーは、事業者グループリーダーから報

告されたリスク及び課題解決策の実施状況とその結果を取り纏め、

定例事前報告において報告、情報共有を行う。

(3) 所管課は、事業者プロジェクトリーダーの報告を受けて、対応策

の実施状況と結果の妥当性を評価する。

(4) 所管課は、定例事前報告における検討の結果、必要に応じて対応

策の修正･追加を行うこととする。

(5) リスク及び課題の影響度、重要性あるいは緊急度が大きい場合、

PMO へ報告し緊急ミーティングを行い、リスク及び課題の対応策

を検討する。


3.5.4.3.1 リスク･課題解消の確認

(1) リスク及び課題解決策の担当者による是正処置の実施により、リ

スクの発生確率が無くなった場合、あるいは課題が解決された場


14

合は、所管課及び事業者プロジェクトリーダーで合意の上、リス

ク･課題管理表のステータスを「対応済み」に変更し、リスク及び

課題管理対象から外すこととする。

(2) 発生したリスクが顕在化し課題となった場合、リスク管理表のス

テータスを「課題転記」とし、認識された課題として課題管理表

へ転記する。

(3) 外部要因により解消が困難なリスク及び課題は、事業者プロジェ

クトリーダー、所管課、PMO にて検討し、リスク･課題管理表の

ステータスを「受容」とする。


3.5.5.1 報告基準

以下の報告基準を使用して、リスク･課題管理を実施する。

3.5.5.1.1 リスク管理

事業者グループリーダーは、プロジェクトに影響を及ぼすと考えられるリスクが発生した場合、直ちにリスク管理表に記入し、事業者プロジェクトリーダーへ報告する。事業者プロジェクトリーダーは、各グループからのリスク管理表を

取り纏め、リスクの影響度や緊急度、重要度を整理する。影響度が大きい、あるいは緊急度が高い、重要度が高い場合は即時に PMO へ報告し、リスク解決策を検討する。影響度が小さい、あるいは緊急度が低い、重要度が低いリスクに関しては、事業者プロジェクトリーダー及び所管課にて協議の上、定例事前報告において報告を行い、リスク解決策を検討する。また、前回の定例報告から残存したリスクに関しては、事業者プロ

ジェクトリーダー及び所管課の間で、経過報告・情報共有を行う。

3.5.5.1.2 課題管理

事業者グループリーダーは、リスクが顕在化し課題が発生した場合、直ちに課題管理表に記入し、事業者プロジェクトリーダーへ報告する。事業者プロジェクトリーダーは、各グループからの課題管理表を取

り纏め、課題内容と対応策を整理する。影響度が大きい、あるいは緊急度が高い、重要度が高い場合は即時に PMO へ報告して、課題解決を図る。影響度が小さい、あるいは緊急度が低い、重要度が低いリスクに関しては、事業者プロジェクトリーダー及び所管課にて協議の上、定例事前報告において報告を行い、課題解決策を検討する。また、前回の定例報告から残存した課題に関しては、事業者プロジ

ェクトリーダー及び松本市情報政策課担当者の間で、経過報告・情報共有を行う。

3.5.5.2 管理指標

以下の管理指標を使用して、リスク･課題管理を実施する。


15

事業者プロジェクトリーダーは、定例事前報告において PMO に対し、当月の管理指標について、定例報告書に記入し報告する。


1 未対応リスク総数確認時点で未対応になっているリスクの総数

2 重大リスク件数確認時点で未対応になっている影響度・重要度・緊急度のいずれかが大きいリスク件数

3 対応遅延リスク件数対応期限を過ぎても対応できていないリスクの件数

4 未対応課題総数確認時点で未対応になっている課題の総数

5 重大課題件数確認時点で未対応になっている影響度・重要度・緊急度のいずれかが大きい課題件数

6 対応遅延課題件数対応期限を過ぎても対応できていない課題の件数



リスク管理表、課題管理表、定例報告書

3.6 品質管理

3.6.1 品質管理の目的

品質管理は、各種管理要領に従って適切なプロセスでプロジェクトを運営し、結果として高い品質の成果物を作成するために行う。本要領では、発注者が実施するプロセスに関する品質保証と、事業者自身が実施

する成果物に関する品質管理に対するプロセス･基準等を定める。

3.6.2 対象範囲

品質管理を行う対象範囲は、当該システム構築事業における事業者の作業、及びこれに係る発注者の作業とする。

3.6.3 管理規程

品質管理おいて実施する作業概要を以下の図に纏める。



所管課 PMO

レビュー観点書の作成レビュー観点書

品質計画・品質目標の策定品質計画書

成果物の品質管理調整事項管理表

リスク管理表・課題管理表

法的要求事項の品質確認 ―

終結プロジェクト完了の確認 ―

実行・監視


事業者

計画

レビュー

承認

レビューレビュー

作成協議

承認

承認

作成

承認

確認

確認


16



3.6.3.1.1 レビュー観点書の作成

(1) 所管課は、「松本市情報システム管理ガイドライン」にて定義さ

れた各工程の成果物の承認（合意・確認）の記載を参考にして、

事業者が作製した文書（成果物）に対するレビュー観点書を作成

し、PMO と内容について確認及び承認を得る。

3.6.3.1.2 品質計画･品質目標の策定

(1) 事業者プロジェクトリーダーは、プロジェクト開始時に品質計画

書を作成し、内容について所管課と協議する。品質計画書には納

品物に関する品質目標及び品質目標を達成するための品質管理目

標を定義する。

品質目標：

情報システムが、松本市の要求仕様を満たし、かつ、十分な品質

を保つために定める目標を指す。

例）要求仕様一覧、ソフトウェア品質特性の達成度、ソフトウ

ェアメトリクスなど

品質管理目標：

住民情報システムの品質目標を達成するために行う品質管理上の

目標を指す。

例）バグ摘出率、テスト消化率など

(2) 事業者プロジェクトリーダーは、協議した品質計画書に対して

PMO の承認を得る。


3.6.3.2.1 成果物の品質管理

(1) 成果物の品質を担保するために、成果物に対するレビューを実施

する。レビューは、「計画プロセスでの管理」にて作成したレビ

ュー観点書に基づき行う。また、発注者へのレビュー依頼ならび

に事業者に対する修正依頼は調整事項管理表を活用して実施する

こととする。

(2) バージョン番号は、レビュー後の修正などで文書の編集が行われ


17

る都度、番号を上げていくこととする。また、文書に対する発注

者による承認が行われた際には、メジャーバージョン番号を上げ

ることとする。

(3) 文書改定の履歴は、バージョン名、日付、修正内容、作成者、承

認者を記録する。文書中に以下表の様式を設け、レビュー観点書

のそれぞれの観点が確認された時点でのバージョン番号を記載す

ることとする。ただし、履歴の記載は松本市側の承認を経たバー

ジョン番号である 1.00 以上を超えた文書に対する修正内容につい

てのみ行うこと。

Ver. 日付修正内容作成者承認者

1.00 2010/04/19 初版作成

1.10 2010/07/21 ハードウェア構成について修正

1.20 2010/09/17 誤字修正

表 6 改定履歴一覧

(4) 事業者グループリーダー、事業者プロジェクトリーダー、所管課

は、成果物に品質的な問題が発生する（した）と認識した場合、

Ver1.00Ver1.00以降の流れ以降の流れ

レビュー

Ver1.01Ver1.01

Ver1．00の編集

Ver1.01Ver1.01

レビュー後修正

Ver1.02Ver1.02

発注者レビュー

Ver1.23Ver1.23


（最終版提出）

Ver2.00Ver2.00

承認

Ver2.00Ver2.00・・・・

Ver1.00Ver1.00以降の流れ以降の流れ

レビュー

Ver1.01Ver1.01

Ver1．00の編集

Ver1.01Ver1.01


Ver1.02Ver1.02


Ver1.23Ver1.23



Ver2.00Ver2.00

承認

Ver2.00Ver2.00・・・・

レビュー

Ver1.01Ver1.01

レビュー

Ver1.01Ver1.01

Ver1．00の編集

Ver1.01Ver1.01

Ver1．00の編集

Ver1.01Ver1.01


Ver1.02Ver1.02


Ver1.02Ver1.02


Ver1.23Ver1.23


Ver1.23Ver1.23



Ver2.00Ver2.00



Ver2.00Ver2.00

承認

Ver2.00Ver2.00

承認

Ver2.00Ver2.00・・・・

Ver1.00Ver1.00までの流れまでの流れ

レビュー

Ver0.03Ver0.03

作成・編集

Ver0.03Ver0.03


Ver0.04Ver0.04


Ver0.51Ver0.51



Ver1.00Ver1.00

承認

Ver1.00Ver1.00・・・・

Ver1.00Ver1.00までの流れまでの流れ

レビュー

Ver0.03Ver0.03

作成・編集

Ver0.03Ver0.03


Ver0.04Ver0.04


Ver0.51Ver0.51



Ver1.00Ver1.00

承認

Ver1.00Ver1.00・・・・

レビュー

Ver0.03Ver0.03

レビュー

Ver0.03Ver0.03

作成・編集

Ver0.03Ver0.03

作成・編集

Ver0.03Ver0.03


Ver0.04Ver0.04


Ver0.04Ver0.04


Ver0.51Ver0.51


Ver0.51Ver0.51



Ver1.00Ver1.00



Ver1.00Ver1.00

承認

Ver1.00Ver1.00

承認

Ver1.00Ver1.00・・・・


18

逐次、課題管理表やリスク管理表,にその旨を記載し、定例事前報

告において報告及び情報共有を行う。また、成果物によってはそ

の重要性を鑑み、PMO が確認を行う。

(5) 事業者プロジェクトリーダーは、プロジェクト計画書に記載され

た成果物を発注者に納品する際、成果物に対して調整事項管理表

やリスク管理表、課題管理表に記載されたすべての全てが対応完

了であることを確認する。

3.6.3.2.2 法的要求事項の品質確認

(1) 所管課及び PMO は、プロジェクトのプロセス･成果物が、法的要

求事項に従っているかについて適宜確認する。

(2) プロジェクトのプロセス･成果物に関して、事業者が法的要求事項

（契約書の記載内容）に従っていないと判断した場合は。事業者

は速やかに改善を行い、その結果を定例事前報告にて報告する。

(3) 所管課及び PMO が改善を指示したにもかかわらず、事業者が改善

できない場合は、是正処置要求の対象となる。


3.6.3.3.1 プロジェクト完了の確認

(1) 事業者プロジェクトリーダーはプロジェクト完了にあたり、各種

管理要領に記載されたプロセスに従って、プロジェクト計画書に

記載された全ての成果物が作成され、成果物に関する品質目標を

達成したことを確認し、定例事前報告にて報告することとする。


3.6.4.1 報告基準

以下の報告基準を使用して、品質管理を実施する。

3.6.4.1.1 品質管理

事業者プロジェクトリーダーは、プロジェクト開始時に品質計画書を作成し、松本市へ提出する。事業者グループリーダーは品質計画書に基づき、調整事項管理表や

リスク管理表、課題管理表を更新し、定例事前報告の時点で、事業者プロジェクトリーダーに提出する。事業者プロジェクトリーダーは各グループからの各種管理表を取り

纏め、品質状況の確認を行う。この際、品質管理上の問題が発生している場合には、定例事前報告において状況の報告と対応策も併せて報


19

告する。また、前回の定例報告からの残存事項に関しては進捗報告、是正案を提示する。所管課は事業者からの報告を受け、品質の低下が見られる場合には、

事業者プロジェクトリーダー及び PMO を含めて緊急ミーティングを実施し、解決を図る。


調整事項管理表、課題管理表、リスク管理表

3.7 文書管理

3.7.1 文書管理の目的

文書管理は、当該システム構築事業の遂行において作成及び入手した文書を容易に識別し、業務遂行における最新情報の共有等を効率化するために実施する。本要領では、当該システム構築事業における文書管理に必要な事項を定めるとと

もに、事業者及び発注者の文書管理方法についても必要事項を定めることとする。

3.7.2 対象範囲

文書管理を行う対象範囲は、当該システム構築事業における事業者の作業、及びこれに係る発注者の作業とする。

3.7.3 文書の分類

文書管理にて管理する文書には原則として以下のような分類があり、それぞれ適切に管理するレベルや取り扱いルールが異なる。

No 分類説明例

1

成果物

・変更を重ね常に最新版を保持すべき、保守対象文書・作成後は基本的に保守が不要で、単純に蓄積されていく文書（各種管理表を含む）

・要件定義書、基本設計書・議事録、報告書、各種管理表

2

貸借文書

成果物を作成する際に必要とされる情報などが記載された、プロジェクト外で作成された参考文書。発注者から事業者へ貸与される文書

業務マニュアル、事務分掌

表 7 文書の分類

3.7.4 文書の分類と管理方法

文書の分類は上記のとおりであるが、文書管理においては原本・記録を成果物一覧で、貸借文書を文書管理台帳で管理する。文書の種類と管理帳票の対応は以下の通りである。


20

管理帳票成果物貸借文書成果物一覧 ○ －

文書管理台帳－ ○

表 8 文書の種類と管理方法

3.7.5 文書ファイルの命名規則と標準ソフトウェア

3.7.5.1 文書ファイルの命名規則

3.7.5.1.1 成果物のファイル名称については、以下の形式で命名するこ

ととする。

プロジェクト略称_文書名称_ver.N.NN_yyyymmdd.xxx 例.住基_文書作成要領_ver.1.00_20090931.doc

品質管理要領及び変更管理要領に準拠し変更を行い、文書の verX.XX

を更新する。原則、作成・変更者には事業者名、承認者には組織名（例松本市情報政策課）を記載とし、日付（yyyymmdd）は記録文書の作成日とする。また、プロジェクト略称は、PMO と事業者との間で協議して決定すること。

3.7.5.2 文書作成ソフトウェア

文書の作成は、MS-Word、MS-Excel、MS-PowerPoint、MS-Visio、MS-Project の使用を基本とする。尚、MS-Visio、MS-Project を使用する場合、PDF 化したファイルも併せて作成すること。

3.7.6 管理規程

また、実施する作業概要を以下の図に纏める。




所管課 PMO

計画成果物一覧の作成成果物一覧

受領資料の把握文書管理台帳成果物一覧

文書のレビューと承認成果物一覧

議事録の作成議事録

文書の保管 ―

文書の廃棄 ―

終結


事業者

実行・監視

廃棄依頼

レビュー

承認

確認

確認

承認

作成承認承認

作成

作成

レビュー

作成

レビュー

合意記入記入確認


21


3.7.6.1.1 成果物一覧の作成

(1) プロジェクト開始段階において、事業者プロジェクトリーダーは

仕様書に基づいた成果物一覧を作成する。この中で、関連する

WBS 番号、成果物名、文書分類、成果物の説明等を定義し、所管

課及び PMO の承認を得る。

(2) 事業者は、作成された成果物等をどのような体系で保管するかを

定義し、松本市の合意を得るものとする。


3.7.6.2.1 受領資料の把握

(1) 事業者メンバー及び事業者グループリーダーは、発注者から受領

した各資料（貸借文書）について文書管理台帳に記入を行う。ま

た、成果物が作成された際には成果物一覧に必要事項の記入・編

集を実施する。

(2) 事業者プロジェクトリーダーは、文書管理台帳及び成果物一覧の

内容を確認後、PMO と合意する。

(3) 発注者から受領した資料は情報セキュリティ管理要領に従い、厳

重に管理すること。

3.7.6.2.2 文書のレビューと承認

(1) 承認前の文書（成果物）に対するレビューは二段階実施する。第

一段階は事業者グループリーダーがレビューを行う。第二段階は

プロジェクトリーダーによるレビューを行うこととする。レビュ

ーによるバージョンの変更に関しては品質管理の要領に従い、都

度成果物一覧を更新するものとする。

(2) 所管課によるレビューの結果、各文書（成果物）の構成･内容･体

裁に問題がなければ、PMO が承認を行う。また、当該文書の重要

性などを鑑み、PMO がレビューを行うものとする。

(3) 承認を得た文書（成果物）は必要に応じて関係者に配布を行い、

情報共有を行う。

3.7.6.2.3 議事録の作成

(1) 事業者グループリーダー及び事業者プロジェクトリーダーは、進

捗管理要領の報告基準に記載されているワーキンググループ報告、


22

定例報告においての議事録を作成すること。

(2) 事業者プロジェクトリーダーは、議事録の内容を確認後、所管課

の承認を得る。


3.7.6.3.1 文書の保管

(1) 事業者は、作成した文書・発注者から受領した各文書をプロジェ

クトサーバ上の共有フォルダ等、定義された場所・体系に格納し、

管理する。なお、プロジェクトサーバ等の保管形式に関してはプ

ロジェクトの性質を鑑み、事業者・発注者間で適宜調整すること

とする。

(2) 日次や週次等、プロジェクトの性質を鑑み、格納された文書を定

義されたタイミングで外部媒体等にバックアップをとるものとす

る。

(3) 紙媒体で管理する文書は、施錠が可能なキャビネット等の適切な

場所に保管を行う。

3.7.6.3.2 文書の廃棄

(1) 文書の廃棄に関しては、松本市の文書管理規程に準拠する。


3.7.7.1 報告基準

以下の報告基準を使用して、文書管理を実施する。事業者グループリーダーは逐次、成果物一覧を更新し、定例事前報告の時

点で、事業者プロジェクトリーダーに提出する。事業者プロジェクトリーダーは各グループからの成果物一覧を取り纏め、定例事前報告において報告する。

3.7.7.2 管理指標

以下の管理指標を使用して、文書管理を実施する。

事業者プロジェクトリーダーは、定例事前報告において PMO に対し、当月の管理指標について、定例報告書に入力し報告する。


3 完了予定文書総数確認した時点で、文書作成が完了している予定であった文書の総数

4 未完了文書数文書作成予定期日を過ぎた文書のうち、バージョン


23

が1.00未満の文書の数



文書管理台帳、成果物一覧、定例報告書

3.8 変更管理

3.8.1 変更管理の目的

本要領は、当該システム構築事業を遂行する上で、WBS、仕様書、設計書、標準記述様式、ソフトウェア等の変更に必要な以下を実現するためにルールを規定する。

変更の必要性が生じた場合、変更が必要な範囲を的確かつ迅速に把握し、業

務全体への影響を考慮して最適な修正を行う。

変更の担当者や責任者を明確化し、関係者への変更通知を確実に行う。

変更の履歴を確実に残す。

3.8.2 対象範囲

変更管理を行う対象範囲は、当該システム構築事業における事業者の作業、及びこれに係る発注者の作業や、WBSや設計書等の成果物とする。

3.8.3 管理規程

変更管理において実施する作業概要を以下の図に纏める。



所管課 PMO

計画変更管理対象の把握と合意 ―

変更案件の登録変更管理票変更管理台帳

影響の確認変更管理票

変更対応の開始変更管理票

変更結果の確認変更管理票変更管理台帳

終結変更管理の完了確認変更管理票変更管理台帳

松本市

実行・監視


確認

影響確認

確認

影響確認

合意

合意

承認

把握

記入

合意把握把握

確認

助言

記入

承認確認

貸出依頼記入記入

承認レビュー記入記入

承認

承認

承認



3.8.3.1.1 変更管理対象の把握と合意

(1) 情報システムの設計･開発段階においては、原則、前工程以前の成


24

果物と情報システムそのものを、変更管理の対象とする。

(2) 情報システムの運用段階においては、納品検収後の成果物と情報

システムを変更管理の対象とする。

(3) 変更管理対象について、事業者プロジェクトリーダーは各工程の

開始時に所管課と合意する。必要に応じて、PMO の助言を受ける。


3.8.3.2.1 変更案件の登録

(1) 変更が発生した場合、作業を担当している事業者メンバー及び事

業者グループリーダーが変更管理票及び変更管理台帳の記入を行

う。その際、変更要求の起因文書を添付する。

(2) 事業者プロジェクトリーダーは、変更管理票及び変更管理台帳の

内容を確認後、所管課と合意する。

(3) 所管課と合意された変更案件は、PMO へ逐次報告し、承認を得る

こととする。

3.8.3.2.2 影響の確認

(1) 事業者グループリーダー及び事業者プロジェクトリーダーは、登

録された変更案件に関して、他の関連成果物への影響確認を行う。

(2) 他の関連成果物に影響を与える変更案件については、変更の可否

及び変更対応の担当者に関して所管課と協議し合意を得る。

3.8.3.2.3 変更対応の開始

(1) 変更管理票を所管課に提出し、変更の承認を得る。必要に応じて、

PMO の最終承認を得る。

(2) 納品検収後の成果物に対して変更が発生する場合、所管課に成果

物の貸出依頼を行う。

3.8.3.2.4 変更結果の確認

(1) 変更した成果物に関しては必ずバージョン（版数）を上げ、変更

管理票に対応内容等を記載する。

(2) 変更した成果物は、変更管理票と併せて関係者によるレビューを

受け、変更内容について所管課の承認を得る。必要に応じて、

PMO の承認を得る。

(3) 変更結果について承認を得た後に、変更管理台帳に完了の記載を


25

行う。


3.8.3.3.1 変更管理の完了確認

(1) 終結プロセスまでに実施した変更管理における記録文書（変更管

理票、変更管理台帳）についても、他の成果物と合わせて納品を

行う。

(2) 変更内容を鑑み、随時、プロジェクト関係者に変更を周知する。


変更管理票、変更管理台帳

3.9 情報セキュリティ管理

3.9.1 情報セキュリティ管理の目的

以下に示す基本的な考え方に基づいて情報セキュリティ施策を策定し、遵守する。

プロジェクトに参画する者は、遵守すべきセキュリティポリシーを踏

まえた情報セキュリティ施策を策定し、これに基づく総合的・体系的

な対策の推進を図る。

不正アクセスやコンピュータウィルス等が認められた場合における緊

急対処及び情報セキュリティ関連の意識徹底等の課題について、プロ

ジェクト内での協力・連携等の体制を確立・強化し、プロジェクト全

体としてセキュリティ水準の向上を図る。

情報セキュリティポリシーを定期的に評価し、必要があれば速やかに

更新するとともに、更新された情報やチェックポリシーに基づき速や

かに情報システムの評価・見直しを行い、必要な措置をとる。

3.9.2 対象範囲

情報セキュリティ管理を行う対象範囲は、当該システム構築事業における事業者の作業、及びこれに係る発注者の作業とする。

3.9.3 管理規程

情報セキュリティ管理において実施する作業概要を以下の図に纏める。


26



所管課 PMO

計画セキュリティ管理体制の確立プロジェクト計画書等

セキュリティ施策の遵守情報セキュリティ管理表

セキュリティ検査の実施情報セキュリティ管理表

終結セキュリティ対策状況のまとめ情報セキュリティ管理表

実行・監視


事業者

管理

確認

確認

確認

承認

承認

作成確認承認

管理承認実施・遵守

作成

確認

作成

確認



3.9.3.1.1 セキュリティ管理体制の確立

(1) 事業者プロジェクトリーダーは事業者内の管理体制を確認し、プ

ロジェクト内における情報セキュリティ施策に関する管理組織･

体制を立案し、各責任者を任命する。

(2) セキュリティ施策の遵守状況確認のための情報セキュリティ管理

表を立案･作成し、所管課及び PMO の承認を得る。


3.9.3.2.1 セキュリティ施策の遵守

(1) 事業者は、事業者及び発注者のセキュリティポリシーを勘案し、

以下の観点で情報セキュリティ管理体制及び情報セキュリティ管

理表を作成し、また、それを遵守するものとする。

原則として、以下の項目は少なくとも遵守されるものとするが、

プロジェクトの性質・規模等により、プロジェクト開始時に発注

者・事業者間で項目の調整を行うこと。

No セキュリティの観点

実施されるセキュリティ施策例（チェック項目）

1 組織・体制責任者の任命・セキュリティ施策の遵守についての最高責任者が、

事業者内で決定されていること。

確認体制の確立・最高責任者を委員長とするセキュリティ委員会が設

置され、セキュリティ遵守状況確認や問題発生時の

対応が行われる旨、定義されていること。

・委員会の構成メンバーが定義されていること。


27



2 情報の分類と管理

文書の管理・プロジェクト内で発生した文書、松本市より受領し

た文書に関してはアクセス権限を、利用目的などを

鑑み適切に設定し、管理すること。

・松本市より受領した紙媒体文書については、原則と

してプロジェクトルーム内でファイリング・管理さ

れ、持ち出し時には記録が残されていること。

・共有ファイルは原則としてプロジェクトサーバに保

管されていること。

3 物理的セキュリティ

設備の管理・重要な情報資産を取り扱う部屋に関しては、入退室

が監視され記録が取得・保管されていること。

・プロジェクトルーム退室時には必ず施錠されている

こと。

機器の管理・作業用PCを置いて長時間にわたり席を離れる場合は

、盗難防止用チェーンにより固定されていること。

4 人的セキュリティ

教育・啓蒙・委員会の構成メンバーにより、プロジェクトメンバ

ーに対してセキュリティ施策に関する教育や説明、

訓練が行われていること。

5 技術的セキュリティ

内部情報漏洩・離席後5分以内に入力がない場合には作業用PCが自

動的にロックするよう設定されていること。

・ USBメモリ、CD-ROM等の電子媒体により情報をプ

ロジェクトルーム外に持ち出す場合は記録が残され

ていること。

不正アクセス・事業者が松本市の環境へPCを持ち込む際には、松本

市の庁内ネットワークとは常に切り離されているこ

と。

・松本市の庁内ネットワークへは作業用PCのみアクセ

スできるよう設定されていること。

・サーバおよび作業用PCにはパスワードが設定され、

定期的に変更されていること。

記録保護・サーバおよび作業用PCのデータは、定期的にバック

アップが取られていること。

ウィルス対策・ウィルス対策ソフトを使用し、サーバおよび作業用

PCに保存されたデータに対するウィルス対策が行わ

れていること。ウィルス定義情報は常に最新に更新

されていること。

ソフトウェアの不正コピー

・ソフトウェアの不正コピーが禁止され、ライセンス

管理が徹底されていること。

6 運用導入支援・セキュリティ施策が適切に実施されることを保証す

るため、毎月、施策遵守状況の報告が行われている

こと。

遵守確認・プロジェクトメンバーが、情報セキュリティに関す

る事故やシステム上の欠陥を発見した場合、独自に

その事故、または欠陥の解決を図らずに速やかにセ

キュリティ委員会に報告がされていること。


28



実データ・帳票等の管理

・必要に応じて個票・名簿などの個人情報を含むデー

タを参照する場合、文書管理要領に規定のある文書

管理台帳に、借用期限などを明記の上適切に管理し

、利用目的が達せられたら速やかに返却・廃棄され

ていること。

ライブラリ等のアクセス権限

・開発用の環境は松本市の庁内ネットワークには接続

が行われず、プロジェクト専用のネットワークが設

置され、独自にアクセス権が付与されていること。

・プロジェクトメンバーおよび関係者には、適切なア

クセス権が設定されていること。

7 法令遵守守秘義務・契約段階に守秘義務に関する同意書が提出され、遵

守されてこと。

8 情報セキュリティ違反に対する対応

処分・最高責任者は、セキュリティ施策を遵守しないプロ

ジェクトメンバーに対して、その重大性に応じて処

罰を行うこと。

9 評価・見直し

施策の見直し・セキュリティ施策は各マイルストンにおいてアセス

メントを行い、フェーズ毎に見直しが計られること

表 10 情報セキュリティ施策例

3.9.3.2.2 セキュリティ検査の実施

(1) 計画段階で合意した情報セキュリティ管理表に基づき、セキュリ

ティ施策の遵守状況を確認するための検査を毎月実施する。

(2) 検査結果は、情報セキュリティ管理表に記載をし、定例事前報告

において報告を行う。


3.9.3.3.1 セキュリティ対策状況の纏め

(1) WBS に基づき、適宜マイルストンを設定する。その後、情報セ

キュリティ管理体制及び情報セキュリティ管理表を確認し、未対

応の報告がないか確認及び情報セキュリティ管理体制及び情報セ

キュリティ管理表の見直しの必要性について検討を行う。


3.9.4.1 報告基準

以下の報告基準を使用して、情報セキュリティ管理を実施する。


29



所管課 PMO

計画緊急対策計画の策定と合意緊急対策計画

緊急対策の実施 ―

緊急対策実施状況のモニタリング ―

終結緊急対策の完了確認緊急対策完了報告書

松本市

実行・監視


実施

作成

確認

確認・承認

作成確認・承認

実施実施

実施

確認

実施

サポート

確認

サポート

確認

確認

事業者グループリーダーは、情報セキュリティ管理表を定例事前報告までに作成し、事業者プロジェクトリーダーに提出する。事業者プロジェクトリーダーは、各グループからの情報セキュリティ管理表を取り纏め、定例事前報告において PMO に対して提出し、前回の定例報告から当該定例事前報告までの情報セキュリティ管理に関する報告、情報共有を行う。

3.9.4.2 管理指標

以下の管理指標を使用して、情報セキュリティ管理を実施する。事業者プロジェクトリーダーは、定例事前報告において PMO に対し、当

月の管理指標について、定例報告書に記入し報告する。


1 セキュリティ違反指摘総数セキュリティ検査を実施した結果の、違反等の指摘総数

2 セキュリティ違反指摘未対応数セキュリティ検査を実施した結果の、違反等の指摘に対する未対応数



情報セキュリティ管理表、定例報告書

3.10 緊急対策計画の策定

前述の通り、進捗、リスク・課題等の管理において、プロジェクト推進の異常値を検出するため管理指標を設定するが、プロジェクトを推進していくにあたって各管理が発注者・事業者間で合意された閾値を超えた場合には緊急対策計画（Emergency Plan）を策定し、その計画に基づきプロジェクトのリカバリーを図ることとする。

3.10.1 緊急対策計画の目的

プロジェクト管理における各管理指標が閾値を超えた場合には、当該異常値を是正し、プロジェクトが計画通りに推進される状態へリカバリーする必要がある。緊急対策計画は、管理指標を正常値へリカバリーさせることを目的とする文書である。異常値をどのように・どの期間で、どの担当者が是正し、その経過をどのようにモニタリングするかを定義することが緊急対策計画に求められる。



30

3.10.2 対象範囲

検出された異常値を是正するための発注者および事業者の作業を取りまとめることを、緊急対策計画策定の対象範囲とする。

3.10.3 管理規定

緊急対策計画策定において実施する作業概要を以下の図に纏める。


3.10.3.1.1 緊急対策計画の策定と合意

(1) 事業者プロジェクトリーダーは、プロジェクト管理上検出された

異常値をリカバリーするための緊急対策計画を策定する。

(2) 所管課および PMO は、策定された緊急対策計画の内容を確認し、

計画に不備がある場合にはその旨事業者プロジェクトリーダーに

修正を依頼する。

(3) 策定された緊急対策計画の内容が妥当であれば、PMO は、緊急対

策計画を承認する。


3.10.3.2.1 緊急対策の実施

(1) 事業者のプロジェクトリーダー・グループリーダー・メンバーは、

策定された緊急対策計画に従い、作業を実施する。

(2) 所管課及び PMO は、事業者が緊急対策計画を実施する上で必要と

される情報の提供、作業の支援などを実施する。

3.10.3.2.2 緊急対策実施状況のモニタリング

(1) 事業者のプロジェクトリーダー・グループリーダーは、緊急対策

計画で定義された報告指標・報告タイミングで所管課および PMO

へ報告を実施する。

(2) 所管課および PMO は、事業者プロジェクトリーダーの報告を確認

し、緊急対策計画で定義された通りに作業が実施されているか、

モニタリングを行う。


3.10.3.3.1 緊急対策の完了確認

(1) 事業者プロジェクトリーダーは、作業が完了したことを緊急対策

完了報告書として取りまとめる。


31

(2) 所管課および PMO は、策定された計画通りに対策が実施されたか、

緊急対策完了報告書の内容を確認する。

(3) PMO は、緊急対策完了報告書の内容を確認し、承認する。

3.10.4 緊急対策計画に求められる要素

緊急対策計画は、以下の内容を含めた記述にすること。 ■目的

当該緊急対策計画を実行する位置づけと目的を明記すること。（例：本緊急対策計画は、ｘｘｘ事業を遂行するにあたり発生した進捗管理上の問題を解決することを目的とする。認識された進捗管理上の課題が解決するまでは、ｘｘｘ事業を遂行するにあたり定義されたプロジェクト管理要領に加え、本緊急対策計画によって当該課題の解決を管理することする。）

■対象範囲当該緊急対策計画において対象となる業務の範囲を明記すること。（例：本緊急対策計画は、ｘｘｘ事業を遂行するにあたり発生した進捗管理上の問題、具体的には概要設計書を作成する作業が完了せず、結果としてプロジェクト当初定義した計画値よりもプロジェクト全体の進捗が 30％遅延した問題を解決するための作業とその担当者、モニタリング方法を定義するものである。）

■認識された課題と原因当該緊急対策計画において解決する課題の定義と、当該課題が発生した原因を明記すること。（例：－認識された課題概要設計書の作成が完了せず、結果としてプロジェクト全体の進捗が 30％遅延した。－課題発生原因概要設計書作成の作業が膨大で、当初想定していた工数では完了しなかったため。）

■解決策（作業項目と担当者）

認識された課題を解決するための作業項目、その作業項目の担当者・体制図、スケジュール、中間成果物等が発生する場合にはその旨を明記すること。（例：以下の作業項目にて、2009 年 10 月 20 日までに概要設計書を作成する。

実施作業業務実施内容開始日終了日成果物

役割分担

松本市

事業者

人員の増員概要設計書を作成する人員を追加でアサインする。

2009 年 10 月 10 日 2009 年 10 月 10 日－ ○

ヒアリング実施

概要設計書を作成するにあたり必要となる事項をヒアリングする

2009 年 10 月 11 日 2009 年 10 月 15 日 ○ ○


32

概要設計書文書化

ヒアリングした内容を元に概要設計書を文書化する

2009 年 10 月 13 日 2009 年 10 月 16 日－ ○

概要設計書レビュー

文書化された概要設計書をレビューする

2009 年 10 月 14 日 2009 年 10 月 18 日 ○ △

概要設計書最終化

レビューにて発生した指摘事項を修正し、概要設計書を最終化する

2009 年 10 月 17 日 2009 年 10 月 20 日概要設計書案

－ ○

概要設計書承認

最終化された概要設計書を確認し、承認する

2009 年 10 月 20 日 2009 年 10 月 20 日概要設計書

○ －

完了報告書作成

緊急対策計画完了報告書を作成し、発注者から承認を得る。

2009 年 10 月 21 日 2009 年 10 月 21 日緊急対策計画完了報告書

△ ○

■パフォーマンス目標

緊急対策計画を遂行するうえでの、各作業のパフォーマンス目標を明記すること。（例：概要設計書は約 200 ページを想定しているため、以下のパフォーマンス目標を設定する。－概要設計書文書化 50 ページ／1 日－概要設計書レビュー 40 ページ／1 日－概要設計書最終化 50 ページ／1 日

■モニタリング方法緊急対策計画が開始されてから終了されるまで、計画通りに対策が遂行されているかをモニタリングする方法論を定義すること。（例：2009 年 10 月 10 日の開始から、2009 年 10 月 20 日までの 11日間、対応の緊急性を鑑み毎日 17 時にプロジェクトメンバー全員に対してメールにて以下の情報を報告する。－当該日に実施した文書化ページ数／累計ページ数－当該日に実施したレビューページ数／累計ページ数－当該日に実施した最終化ページ数／累計ページ数

■完了基準当該緊急対策計画が完了する基準を明記すること。（例：緊急対策計画完了報告書を作成し、PMO から承認を得ること

Documents

情報システム 開発プロジェクト管理要領 · 3 プロジェクト管理について 「図1 本管理要領の位置付け」で示したとおり、プロジェクト管理は、プロジェクト

情報システム開発プロジェクト管理要領 · 3 プロジェクト管理について「図1 本管理要領の位置付け」で示したとおり、プロジェクト管理は、プロジェクト