Application Service Provider の略。業務ソフトウェアをはじめとする各種システム機能を、ネットワーク経由で提供する事業者やサービスのこと。 Software as a Service の略。必要な機能のみを選択して「サービス」としてネットワーク等を通じて利用できるようにしたソフトウェアのこと。ＡＳＰとほぼ同義である。

飾区情報システムガイドライン

【構築編】

 飾 区

目 次

＜本編＞

Ⅰ 構築ガイドラインについて １

１ 背景と目的 １

２ 位置づけ １

３ 対象範囲 １

４ 開発手法 ２

５ 用語の定義 ２

Ⅱ 構築プロジェクトの立上げ及び管理 ５

１ 構築事業者との仕様調整及び契約 ６

1.1 プロポーザル方式による調達執行 ６

1.1.1 仕様の確定 ６

1.1.2 契約 ９

1.2 競争入札方式による調達執行 １０

1.2.1 契約 １１

1.3 随意契約方式による調達執行 １１

1.3.1 契約 １１

２ プロジェクト推進体制の確立 １３

３ プロジェクト実施計画の合意 １６

Ⅲ 開発工程管理 ３１

１ 要件定義（業務・機能）工程 ３３

1.1 要件定義（業務・機能） ３３

1.2 要件定義（業務・機能）の承認 ３７

２ 設計（業務・機能）工程 ４０

2.1 基本・詳細設計（業務・機能） ４０

2.2 設計書の承認（業務・機能） ４３

３ 開発工程 ４５

3.1 開発の管理 ４５

3.2 開発の承認 ４６

４ 要件定義（運用・保守・移行）工程 ４９

4.1 要件定義（運用・保守） ４９

4.2 要件定義（移行） ５１

4.3 要件定義（運用・保守・移行）の承認 ５３

５ 設計（運用・保守・移行）工程 ５５

5.1 運用・保守設計 ５５

5.2 移行計画 ５８

5.3 設計書の承認（運用・保守・移行） ６１

６ テスト工程管理 ６３

6.1 テスト全体計画 ６４

6.2 個別計画（結合テスト） ６５

6.2.1 結合テスト計画 ６５

6.2.2 結合テスト実施 ６９

6.2.3 結合テスト結果の承認 ７１

6.3 個別計画（総合テスト） ７３

6.3.1 総合テスト計画 ７３

6.3.2 総合テスト計画（ユーザーテスト） ７８

6.3.3 総合テスト実施 ８２

6.3.4 総合テスト結果の承認 ８５

７ 本番稼働 ８８

7.1 移行リハーサル準備 ８８

7.2 移行リハーサル実施 ９１

7.3 稼働判定 ９２

7.4 システム移行 （リリース実施） ９５

８ 引継ぎ ９６

8.1 運用・保守事業者への引継ぎ ９７

９ 納品検査・管理 ９９

9.1 納品検査 １００

9.2 納品管理 １０１

＜様式編＞

01 トレーサビリティマトリクス（要求追跡）

02 レビュー管理表

03 課題管理表

04 リスク管理表

05 仕様追加要求理由書

06 テスト項目チェックリスト

＜資料編＞

01 成果物品質チェックリスト

02 要件定義書チェックリスト

03 設計書チェックリスト

04 構築ガイドライン詳細フロー

05 構築プロジェクト成果物様式

Ⅰ 構築ガイドラインについて

１ 背景と目的

平成２０年度に作成された飾区情報システムガイドラインには、システム開発における管理方法が構築編として記されている。この構築編は調達編では構築時の内容が不十分であることから、システム構築プロジェクトを管理する際に職員が困窮することが多く、様々な不備が散見されてきた。今回策定する飾区情報システムガイドライン【構築編】（以下、本ガイドラインという）は、この実情を受けて新たに策定し、職員が構築事業者を管理しシステム構築プロジェクトを確実に遂行できるように整備するものである。

本ガイドラインは、システム構築に関する基本的な考え方をはじめ、調達の際に要求した機能及び仕様の確定、開発・テスト管理、各課の役割分担、事業者の管理方法等、具体的な作業内容や様式類を一括して定め、区が求めるシステム実現に向けたシステム構築のプロジェクト管理が適切に行えるようにするものである。

２ 位置づけ

本ガイドラインは、庁内規則としての性格を持つものである。

本区の全職員は、情報システムの構築に当たって、本ガイドラインの遵守に努めなければならない。

３ 対象範囲

本ガイドラインが対象とする情報システムは、原則として本区が事業者と契約して調達した全ての情報システムとし、構築プロセスを対象とする。

参考として、対象とするプロセスは、情報システムの診断と評価から調達執行の手続きを示した調達プロセス（調達編）、構築の手続きを示した構築プロセス（構築編）、運用の手続きを示した運用プロセス（運用編）に分けられる。各プロセスの繋がり及び流れを以下に示す。

４ 開発手法

構築プロセスにおける開発手法は原則ウォーターフォール型※とする。区が適用できるその他開発手法は以下のとおりとする。

・アジャイル「５ 用語の定義」参照

５ 用語の定義

ガイドラインにおいて、次の各号に掲げる用語の定義は、以下の規則等に定めるもののほか、それぞれ当該各号に定めるところによる。

○葛飾区情報セキュリティに関する規則（令和２年飾区規則第１１号）

○葛飾区デジタル技術を活用した行政の推進及び情報システムの管理運営に関する規則

（平成１７年規則第４６号）

○情報セキュリティ対策基準（令和２年４月１日施行）

○飾区情報ネットワーク管理運用要綱（平成１７年９月３０日１７政Ⅰ第１８９号）

○飾区端末装置等管理運用要領（平成１７年９月３０日１７政Ⅰ第１８９号）

○飾区共通データベースシステムの管理運用に関する要領（平成１７年９月３０日１７

政Ⅰ第１８９号）

(1) パッケージ・ソフトウェア

複数の顧客において汎用的に利用することを想定して事業者が開発した、既製のソフトウェアのこと。

(2) ＡＳＰ

Application Service Provider の略。業務ソフトウェアをはじめとする各種システム機能を、ネットワーク経由で提供する事業者やサービスのこと。

(3) ＳａａＳ

Software as a Service の略。必要な機能のみを選択して「サービス」としてネットワーク等を通じて利用できるようにしたソフトウェアのこと。ＡＳＰとほぼ同義である。

(4) インフラ統合基盤（仮想化基盤）

飾区では以下の目的を達成するために、仮想化技術を用いた統合基盤を外部のデータセンターで運用しており、それらをインフラ統合基盤と呼ぶ。

・ＩＣＴ-ＢＣＰ対策

・情報システムの最適化（システム運用に係る業務の負担軽減、コストの削減）

・グリーンＩＣＴの実現（機器台数そのものの削減／消費電力の低減／発熱量の抑制）

(6) ウォーターフォール

ウォーターフォールとは、システムの開発を「要件定義」「基本設計」「詳細設計」「開発」「テスト」等という工程に分け、順に段階を追って行う方法である。ひとつの工程が終

わるごとにその工程での成果が文書化されるため、システム開発の管理を行いやすいのが特徴である。

(7) アジャイル

アジャイルとは「すばやい」「俊敏な」という意味で、主にプロジェクト開始段階で要件を明確に定めることが難しい案件に適しているとされる。短い期間に設計からテストを反復して行うことにより、ソフトウェアの完成度を高めていく開発手法である。

(8) ホワイトボックステスト

システムがどのような論理構造で作成されているかに着目したテストのことである。プログラムの外部仕様には着目せず、論理を実現するために使われている命令や、分岐が正しく動作するか、といった部分についてチェックが行われる点が特徴の手法である。

(9) ブラックボックステスト

データが正しく処理されることを検証するテストであり、入力データと出力データの結果だけに着目し、仕様書どおりに正しく処理されるかを検証するテスト手法である。

(10) シナリオテスト

実際の業務の流れ（業務フロー）を意識し、システムを稼働させた際に想定（シナリオ）どおりに業務が運用できるかを確認するためのテスト手法である。

(11) サイクルテスト

日次などの定常業務のほか、月次、年次、及び随時の非定常業務など、いくつかのパターンでシナリオテストを実施した際に、業務が問題なく運用できるかを確認するためのテスト手法である。

(12) トレーサビリティマトリクス

ある要件と別の要件の関係、あるいは要件とテストの関係など、システム開発におけるさまざまな設計情報と要求を対応させ、管理するための表のことを指す。開発や成果物において、区の要求をどこで満たしているかを確認することができる。

(13) フィットアンドギャップ

システム開発時にパッケージ・ソフトウェアを導入する場合、そのパッケージ・ソフトウェアの機能と導入する業務プロセスやシステム化要求などが、どの程度「適合（フィット）」し「かい離（ギャップ）」があるかを調査・分析・評価する作業のことである。パッケージ・ソフトを導入するかどうかの意思決定や、追加開発及び修正すべき機能の洗い出しなどのために行う。

（14）事業者

本プロセス内において、構築全般を実施する事業者を指す。契約相手方に加え、再委託先等実際にシステム開発を行う相手方の総称

（15）クリティカルパス

システム構築プロジェクトを進めるうえで、ネックとなる重要な部分を指し、事実上プロジェクト全体のスケジュールを左右する作業の連なりを指す。クリティカルパスの作業が

遅れると、プロジェクト全体のスケジュールが遅れることになる。

（16）デグレード

デグレードとは、新しいバージョンのソフトウェアの品質が、以前より悪くなること。また、以前に修正した不具合やバグが再発・復活すること。また、新しいファイルなどを古い内容で上書きしてしまい、更新内容が失われること。

（17）ＩＰＡ（情報処理推進機構）

日本におけるＩＴ国家戦略を技術面、人材面から支えるために設立された、経済産業省所管の中期目標管理法人たる独立行政法人のこと。

（18）ソフトウェア開発データ白書

ソフトウェア開発データ白書は、ＩＰＡが２００４年から収集している４，０６７件のプロジェクトデータを収録したものであり、同データは、その質や分析の多様性、継続的に収集した情報に基づく経年変化の分析結果が示されたものである。

（19）マイルストーン

システム構築プロジェクトにおけるスケジュール管理において、進捗の目安となる重要な節目、区切りのこと。「要件定義工程」「設計工程」などの、大項目の開始や終了などを設定することが多い。

（20）運用レベル合意書

システム提供事業者と内部グループとの間で取り交わした合意文書のことであり、サービス及びサービス目標を定義した文書のことを指す。

本区における「運用レベル合意書」は、システムのサービスの正常状態を構築事業者と区が合意し、機器の配置場所やソフトウェアの設定値、ネットワーク状態など明らかにした資料のことを指す。

Ⅱ 構築プロジェクトの立上げ及び管理

プロジェクト計画及びプロジェクト管理について、案件の調達ガイドラインの運用基準の内容を踏襲したうえで、価格及び調達ガイドライン申請区分からプロジェクト管理方法を設定する。

本ガイドライン運用をプロジェクトに適用するあたり、プロジェクト管理パターンを下表に示す。

・「価格」は開発費用（システムインテグレート（SI）、カスタマイズ）（税抜き）の合計とする。

・「調達ガイドライン申請区分」は、調達ガイドライン運用において、システム計画書か概要説明書のどちらを作成したかで判断する。

パターン別の対応案（ＡＢＣ）の考え方については下図に示す。

構築プロジェクトの立ち上げ及び管理の流れと内容を、以下の１～５に示す。

１ 構築事業者との仕様調整及び契約

1.1 プロポーザル方式による調達執行

本工程は、調達ガイドラインの「Ⅲ.4.1 プロポーザル方式による調達執行_4.1.4 選定」において、プロポーザル方式による調達執行及び事業者選定が行われた後の、最優秀提案者との仕様の確定及び契約手続きを行うものである。

最優提案者との仕様調整は、本ガイドライン「２ プロジェクト推進体制の確立」「３ プロジェクト実施計画の合意」の内容を踏まえ実施すること。

1.1.1 仕様の確定

業務主管課及びシステム主管課は、最優秀提案者と事業者提案書、ヒアリング等の内容を確認し、相互にシステム構築について、認識のずれが生じないよう打合せを行い、仕様内容を確定させる。

調達仕様書（ＲＦＰ、事業者提案書、xxxxx等の内容を含む。）、特記仕様等を作成し、最優秀提案者から見積書（調達仕様書の内容に応じて合意した見積価格）を提出させる。

なお、ＬＧＷＡＮ接続系システム及び住民情報系システムは、情報システム課と共同で調達仕様書を作成し、契約手続きは、原則として主管課が飾区契約事務規則に従って行う。ただし、情報システム課が所管しているシステムの場合、契約手続きは情報システム課が行う。

(1) 実施者

業務主管課	仕様内容の調整及び確定調達仕様書等の作成
システム主管課	仕様内容の調整及び確定調達仕様書等の作成
情報システム課	調達仕様書等作成の支援（共通データベース連携システム、インフラ統合基盤の場合）
最優秀提案者	仕様内容の調整及び確定

(2) 入力情報及び成果物

成果物作成の根拠資料	成果物
ＲＦＰ（提案依頼書）書、特記仕様等）	調達仕様書等 （調達仕様書、特記仕様等）
事業者提案書	見積書

(3) 手順と役割

①システム主管課は、最優秀提案者と連絡を取り、交渉日程を調整し、提案内容の交渉及

びプロジェクト開始にあたり必要となる事項の交渉及び調整を行う。最優秀提案者とＲ ＦＰ、提案書、xxxxx等の内容について交渉し、仕様内容を確定する。交渉及び調整すべき事項は以下を参考にすること。

要件	交渉及び調整すべき事項
業務要件	業務要件、機能要件（機能、帳票、外部インターフェース）、現行業務の課題及び導入を予定している業務をもとに業務要 件を確定しているか
システム要件	システム要件、非機能要件を確定しているか その他、区独自の業務（機能変更）がある場合に実現方法を確定しているか
	外部インターフェースにおいては、新システムが既存のデータ形式に合わせることで合意しているか また、共通ＤＢが用意するＶｉｅｗ（カスタマイズして表にし たもの）の項目が不足している場合の対応方法を合意しているか
	インフラ統合基盤を利用する場合に構築ルールに則ることを合意しているか
セキュリティ要件	区のセキュリティポリシーに則ることを合意しているか
開発・導入に関する要件	開発手法として、ウォーターフォールを適用することを合意し ているか。また、他の開発手法とする際に、事業者からの提案を受けた開発手法であるか
	区の要求事項、パッケージ機能の変更履歴をトレースし常に現状や履歴が把握できる管理方法の提案を受けているか
	操作研修においては、業務主管課だけでなく一般利用者に対しても実施することを合意しているか。
運用・保守に関する要件	運用・保守に関する要件について合意しているか。 また、保守・運用設計は設計工程内で行うことを認識しているか。なお、設計書の作成にあたっては、「飾区情報システムガイドライン【運用保守編】」を確認し、調達するシステムに適切な運用・保守のパターンを特定した上で臨むこと。その他、障害時の復旧対応について、システム構成（システム提供事業者とハードウェア提供事業者が異なるなど）を鑑みて業務への影響を最小限とする具体な提案（想定障害件数、想定運用保守数、作業内容、回数、復旧時間など）を事業者から受け合意し ているか。

	以下の廃棄要件を合意しているか （1）本調達におけるシステムの次期システムへのデータ移行を考慮し、汎用的なデータ形式で、全件分のデータ抽出を可能とすること。 （2）本調達におけるシステムの次期システムへのデータ移行 を考慮し、最新のファイルレコードのレイアウト、コード表など必要となるドキュメントを提出すること。
	インフラ統合基盤を利用する際の保守・運用について、責任分 界、障害時の対応、連絡体制、連携方法等を明示し、区の基盤のルールに則ることを合意しているか
提案に対する要件	ハードウェアとソフトウェアの分離調達要件がある場合にその内容を含めているか
プロジェクト計画及びプロジェクト管理方法	プロジェクト計画及びプロジェクト管理についてプロジェクト計画書もしくは業務計画書を用いて管理することを合意し ているか
	プロジェクト推進体制について調整しているか （事業者の体制は提案内容をもとに早々に確定させること。区側は事業者決定のタイミングまでに決めること。契約時には合 意できていること。）
	構築スケジュールを合意できていること。（ユーザーテストの時期が業務の繁忙期と重ならないように考慮すること）
	キックオフミーティングの実施の有無を調整する
	プロジェクト計画書、業務計画書の作成準備を調整する
成果物	成果物を合意しているか
	引継ぎにおいては、システム改修時の成果物を含めたシステム構築から保守終了までの全量の成果物を納品させることを合 意しているか。

② 業務主管課及びシステム主管課は、確定した仕様内容に基づき、調達仕様書等を作成する。また、調達仕様書等の内容に応じて合意した予定価格を確定する。

③ 業務主管課及びシステム主管課は、最優秀提案者と調達仕様書等の内容及び見積価格を最終チェックし、両者で合意する。

(4) 完了条件・チェックポイント

① 最優秀提案者と合意に達した内容が、調達仕様書等、見積価格書等に漏れなく反映されていること。

(5) 留意点等

① 最優秀提案者とＲＦＰ、提案書、xxxxx等の内容について交渉する場合は、作業内容、作業範囲、費用についての確認を行うこと。特に、構築時に予期しない仕様変更（パッケージにおいては機能追加）が発生した時の方針（対応時期、費用等）を明確にしておくこと。

② 最優秀提案者と仕様内容に関して合意に達しない場合には、優先交渉権を解消し、次点の優秀提案者（複数者でも可とする。）と交渉を行う。優秀提案者との間でも合意に達しない場合には、調達は不調とし、再度、調達執行を実施する場合には、ＲＦＰ等の要求事項を見直した上で着手すること。なお、不調となった場合には、デジタル推進委員会又は情報システム統括責任者へその旨報告を行うこと。

③ プロポーザル方式を採用する場合、主管課は仕様の合意内容に基づき価格を決定する。原則提案価格は変更できないものとする。

④ 調達仕様書等は、調達ガイドラインの<資料編>に載せている「モデル仕様書」を参考に作成すること。なお、調達仕様書等の作成に当たっては、以下の事項に留意すること。

・ ＲＦＰに書かれている機能要件、その他要求要件の実現を含めること。要求要件が実現できなかった場合の処置（サービスレベル合意書の締結）について検討すること。

・ 著作権の帰属については、調達するシステムの案件内容に応じて、事業支援者の意見を聴き、必要と判断する場合には調達仕様書等に「権利帰属に関する特記仕様」を添付すること。

・ 個人情報等の重要な情報を扱う場合には、調達仕様書等に「機密情報の取扱いに関する特記仕様」、「飾区が保有する個人情報の取扱いに関する特記仕様」を添付すること。また、特定個人情報を扱う場合には、「飾区が保有する特定個人情報の取扱いに関する特記仕様」を添付すること。

・ その他、他団体の当該情報システムの関連資料等を入手すること。

1.1.2 契約

システム主管課は、飾区契約事務規則に基づき、受注予定者と契約交渉を行い、契約を締結する。

なお、ＬＧＷＡＮ接続系システム及び住民情報系システムの契約手続きは、原則として主管課が飾区契約事務規則に従って行う。ただし、情報システム課が所管しているシステムの場合、契約手続きは情報システム課が行う。

(1) 実施者

業務主管課	特命随意契約理由書の作成を支援
システム主管課	特命随意契約理由書を作成

	契約手続きの依頼
情報システム課	情報システム課が契約主体の契約手続き主管課の契約手続きの支援
契約主管課	主管課が契約主体のシステムの契約手続き
契約管財課	複数年度にまたがる契約手続き
最優秀提案者	契約手続き

(2) 入力情報及び成果物

成果物作成の根拠資料	成果物
調達仕様書等	特命随意契約理由書
契約書	-

(3) 手順と役割

①システム主管課は、最優秀提案者と随意契約を締結する理由を記した特命随意契約理由書を作成し、調達仕様書、提案募集要項等、選定委員会議事録を添付した上で契約管財課の審査を受ける。

②システム主管課は、最優秀提案者と合意した調達仕様書等をもとに契約書を作成し、システム計画可否決定通知書を添付して契約手続きを行う。ただし、複数年度にまたがる契約の場合には、契約管財課での契約となるため、主管課は契約管財課に契約締結を依頼する。

③区契約権者は、契約書、見積書及び特命随意契約理由書を最終チェックし、契約を締結する。

(4) 完了条件・チェックポイント

①特命随意契約理由書は、契約管財課所定の様式を使用すること。

②契約締結の前に契約内容を再確認すること。

③契約書及び特命随意契約理由書の決裁が、適切な決裁権者のもと完了していること。

(5) 留意点等

①特命随意契約の場合、区契約権者は、飾区契約事務規則で定める予定価格に応じて主管部局の長又は主管課長となる。ただし、複数年度にまたがる契約のときには、契約管財課での契約となるため、飾区契約事務規則で定める予定価格に応じて区長、副区長、総務部長又は契約管財課長となる。

②内容の検討に当たって不明な点がある場合には、契約管財課、情報システム課及び事業支援者の支援を得ること。

③最優秀提案者に対し再委託先の確認を行い、区は必要な再委託協議の手続きを実施すること。

1.2 競争入札方式による調達執行

本工程は、調達ガイドラインの「Ⅲ.4.2 競争入札方式による調達執行_4.2.3 選定」において、競争入札方式による調達執行が行われた後、受注予定者と契約手続きを行うものである。

1.2.1 契約

契約管財課は、飾区契約事務規則に従って契約手続きを行う。

1.3 随意契約方式による調達執行

本工程は、調達ガイドラインの「Ⅲ.4.3 随意契約方式による調達執行_4.3.1 調達仕様書等作成」後、受注予定者と契約手続きを行うものである。

1.3.1 契約

システム主管課は、飾区契約事務規則に基づき、受注予定者と契約を締結する。

なお、ＬＧＷＡＮ接続系システム及び住民情報系システムの契約手続きは、原則として主管課が飾区契約事務規則に従って行う。ただし、情報システム課が所管しているシステムの場合、契約手続きは情報システム課が行う。

(1) 実施者

業務主管課	特命随意契約理由書の作成を支援
情報システム課	情報システム課が契約主体の契約手続き主管課の契約手続きの支援 特命随意契約理由書の作成を支援
システム主管課	特命随意契約理由書を作成 契約手続きの依頼
契約主管課	主管課が契約主体のシステムの契約手続き
契約管財課	複数年度にまたがる契約手続き特命随意契約理由書の確認
最優秀提案者	契約手続き

(2) 入力情報及び成果物

成果物作成の根拠資料	成果物
調達仕様書等	特命随意契約理由書
契約書	-

(3) 手順と役割

①システム主管課は、受注予定者と随意契約を締結する理由を明記した特命随意契約理由書を作成し、契約管財課の審査を受ける。

②システム主管課は、受注予定者と合意した調達仕様書等をもとに契約書を作成し、システム計画可否決定通知書を添付して契約手続きを行う。

ただし、複数年度にまたがる契約の場合には、契約管財課での契約となるため、主管課は契約管財課に契約締結を依頼する。

③区契約権者は、契約書、見積書及び特命随意契約理由書を最終チェックし、契約を締結する。

(4) 完了条件・チェックポイント

① 契約締結の前に契約内容を再確認すること。

② 契約書及び特命随意契約理由書の決裁が、適切な決裁権者のもと完了していること。

(5) 留意点等

① 区契約権者は、飾区契約事務規則で定める予定価格に応じた主管部局の長又は主管課長となる。ただし、複数年度にまたがる契約のときには、契約管財課での契約となるため、飾区契約事務規則で定める予定価格に応じた区長、副区長、総務部長又は契約管財課長となる。

② 内容の検討に当たって不明な点がある場合には、契約管財課、情報システム課及び事業支援者の支援を得ること。

２ プロジェクト推進体制の確立

システム主管課は、プロジェクトの推進体制について、契約前から検討し、業務主管課、システム主管課、情報システム課、各関係課、各関係機関、各関係事業者など、プロジェクトを実行するうえで、調整の必要な全ての担当者及び役割を明確化する。

(1) 実施者

業務主管課	プロジェクト推進体制の調整及び確定
システム主管課	プロジェクト推進体制の調整及び確定
構築事業者	プロジェクト推進体制の調整及び確定

(2) 入力情報及び成果物

成果物作成の根拠資料	成果物
‐	‐
‐	‐

(3) 手順と役割

①システム主管課は、プロジェクトの推進体制については契約前から検討し、業務主管課、システム主管課、情報システム課、各関係課、各関係機関、各関係事業者など、プロジェクトを実行するうえで、調整の必要な全ての担当者及び役割を明確化する。

プロジェクト推進体制の構成例を表２－１ プロジェクト推進体制（例）に、システム種別の例を表２－２ システム種別の参考に、プロジェクト参画者の役割を表２－３ プロジェクト参画者の役割にそれぞれ示す。

表２－１ プロジェクト推進体制（例）

システム種別	住民情報系	内部システム系	個別システム
業務主管課	●	●	●
システム主管課（業務主管課）	-	-	●
システム主管課（情報システム課）	●	●	-
情報システム課	-	-	△
構築事業者	●	●	●
現行事業者	●	●	●
運用事業者（次期システム）	△	△	△

保守事業者（次期システム）	△	△	△
関係課	△	△	△
システムの利用者（区民事務所、保健センター等）	△	△	△
関係事業者	△	△	△
関係機関	-	-	-

システム種別	システム判断	システム例
住民情報系	・情報システム課が所管しているシステム ・住民情報系ネットワークに接続している ・システム停止時に区民サービスへの影響がある	・住民基本情報システム ・税システム 等
内部システム系	・情報システム課が所管しているシステム ・ＬＧＷＡＮ接続系ネットワークに接続している ・他システムと連携がある ・システム停止時に内部事務作業への影響がある	・グループウェア ・統合型行政システム 等
個別システム	・情報システム課が所管していないシステム ・システム停止時に個別業務への影響があ る	・かつしかデジタルミュージアム 等

●：体制に含める △：必要に応じて支援（体制に含める） -：体制に含めない表２－２ システム種別の参考

表２－３ プロジェクト参画者の役割

業務主管課	課長	・プロジェクト全体に関する事項の承認及び決定（プロジェクトオーナー）（プロジェクト計画書に定められた場合による） ・業務に関する事項の承認及び決定 ※承認及び決定権限をプロジェクトリーダーへ委任することができる。
	係長	・業務に関する指揮命令系統（プロジェクトリーダー） ・業務に関する体の進捗及び課題の把握 ・業務主管課担当者のコントロール ・承認及び決定権限を受任した場合に限り、プロジェクト全体に関する事項の承認及び決定
	担当者	・業務に関する依頼及び調整

		・業務要件に関する事項の把握、確認、調整対応 ・業務に関するテスト実施対応
システム主管課 ※システム主管課はシステムにより「業務主管課」と「情報システム課」に担当課が変わる	課長	・プロジェクト全体に関する事項の承認及び決定（プロジェクトオーナー） ・システムに関する事項の承認及び決定 ※情報システム課がシステム主管課の場合に、電算機管理者がプロジェクトオーナーとなる。 ※プロジェクト計画書に定められた場合には業務主管課長もプロジェクトオーナーとなる。 ※承認及び決定権限をプロジェクトリーダーへ委任することができ る。
	係長	・プロジェクトの指揮命令系統（プロジェクトリーダー） ・プロジェクト全体の進捗及び課題の把握 ・システム主管課担当者のコントロール ・承認及び決定権限を受任した場合に限り、プロジェクト全体に関する事項の承認及び決定
	担当者	・プロジェクト及びシステムに関する依頼及び調整 ・プロジェクト及びシステムに関する事項の把握、確認、調整対応 ・システムに関するテスト実施対応
情報システム課		・システムに関する事項の支援 ・インフラ統合基盤に関する事項の情報提供 ・インフラ統合基盤事業者及び運用保守事業者との調整
現行事業者		・現行システムに関する情報提供 ・現行システムデータ抽出作業
構築事業者		・次期システムに関する、構築業務全般を実施 ・各開発工程において成果物作成、レビュー及び指摘箇所の修正 ・プロジェクト推進における進捗管理、課題管理、及びリスク管理
運用事業者		・システム運用に関する調整 ・システム運用に関するテスト実施
保守事業者		・システム保守業務に関する調整
契約事業者		・次期システムに関する、契約相手
関係課		・連携先業務として支援及び調整 ・連携先業務として情報提供 ・連携先システムとしてテスト協力
システムの利用者（区民事務所、出張所等）		・連携先業務として支援及び調整 ・連携先業務として情報提供

	・連携先システムとしてテスト協力
関係事業者	・連携先システムとして支援及び調整 ・連携先システムとして情報提供 ・連携先システムとしてテスト協力
関係機関	・関係機関から方針が示される（国、都、J-LIS 等） ・連携先関係機関として支援及び調整

(4) 完了条件・チェックポイント

①構築プロジェクトの体制が確立され、参画者及び役割が明確になっていること。

(5) 留意点等

①構築プロジェクトにおけて区が実施するタスクが「決定」「管理」「調整」「承認」であることを理解し、効率的にプロジェクトを推進すること。

３ プロジェクト実施計画の合意

仕様調整及び契約書の内容をもとに、システム主管課はシステム構築の実施計画書となる「プロジェクト計画書」または「業務計画書」の作成を構築事業者に依頼する。

また、計画書において、プロジェクト管理方法及びプロジェクト品質を保つ方法及び基準を定める。

作成した計画書の内容を区と構築事業者において合意し、構築プロジェクトを開始する。

(1) 実施者

業務主管課	計画書の内容調整
システム主管課	計画書作成を依頼計画書の内容調整 関係各課及び関係機関への調整
構築事業者	計画書作成 計画書の内容調整及び修正

(2) 入力情報及び成果物

成果物作成の根拠資料	成果物
調達仕様書等	プロジェクト計画書
契約書	業務計画書
事業者提案書	プロジェクト管理資料

(3) 手順と役割

①システム主管課は、プロジェクト計画として契約後、システムの構築にあたり、システム主管課はシステム構築の実施計画となる「業務計画書」または「プロジェクト計画書」を構築事業者に作成を依頼する。（「Ⅱ 構築プロジェクトの立上げ及び管理」を参照）「業務計画書」においては、「プロジェクト計画書」の簡易資料として、目的、成果物、スケジュールを明確にする。

「プロジェクト計画書」項目においては、以下の表３－１ プロジェクト計画書標準項目を参考にすること。

表３－１ プロジェクト計画書標準項目

項番	項目
1	目的及び範囲
1.2		目的
1.3		システム範囲
1.4		プロジェクトの範囲
1.5		プロジェクトの実施方法
1.6		プロジェクトの目標
2	プロジェクトの体制
2.1		区の体制と役割
3	会議体
3.1		会議体
3.2		定例会議について
4	スケジュール
4.1		プロジェクトのマスタ計画
4.2		主要マイルストーン
4.3		実施スケジュール
5	作業の範囲と成果物
5.1		作業範囲と成果物
5.2		設計業務の作業範囲と成果物
6	前提条件及び制約条件
6.1		前提条件
6.2		制約条件
7	標準管理要領
7.1		進捗管理
7.2		変更管理
7.3		課題管理
7.4		リスク管理

7.5		品質管理
7.6		情報セキュリティ管理
7.7		コミュニケーション管理
7.8		構成管理
7.9		文書管理

②システム主管課は、構築事業者が作成した「プロジェクト計画書」の成果物の記載内容について、区がシステム構築の際に求める成果物が含まれているか、以下の表３－２ プロジェクト成果物（案）を参考に確認する。また、プロジェクト管理パターン別の要求成果物項目においては、調達ガイドライン「【資料-06】参考成果物一覧」を参考にすること。なお、成果物は案件の性質により異なるため、最終的な成果物についてはシステム主管課と構築事業者の協議の上で決定すること。

表３－２ プロジェクト成果物（案）

区分

資料名

設計・開発関連資料

・要件定義書 ・要件定義（運用・保守・移行）工程完了報告書、要件定義 （業務・機能）工程完了報告書 ・設計書（基本設計書、詳細設計書（※1）、システム概要図、ハードウェア一覧、物理ネットワーク構成図（※ 2）、論理ネットワーク構成図（※2）、IPアドレス一覧 （※2）、配線図（※2）、ER図、データベース定義書、スキーマ一覧、テーブル一覧、テーブル定義書、マスタ一 覧、マスタ定義書、ビュー定義書、ファンクション定義 書、プロシージャ定義書、トリガー定義書、処理機能記述書、データ項目定義書、画面一覧、画面項目定義書、バリデーションチェック定義書、画面項目定義書、画面レイアウト図、画面遷移図、状態遷移図、帳票一覧、帳票レイアウト図、帳票項目定義書、シーケンス・フロー、監視項 目・閾値の一覧、監視項目・監視間隔の一覧、ジョブ一 覧、ジョブネット構成図、ＤＮＳ設計書、アクション定義書、インフラ設計書、外部インターフェース一覧、画面設計方針書、機器配置図、機能一覧、処理機能記載書、ソフトウェア一覧、データベース設計書、ネットワーク設定 書、パラメータ一覧、プログラム設計書 等） ・業務フロー ・設計（業務・機能）工程完了報告書

	・開発工程完了報告書 ・テスト全体計画書 ・結合テスト計画書、結合テスト仕様書 ・結合テスト結果報告書 ・個別計画（結合テスト）工程完了報告書 ・総合テスト結果報告書 ・総合テスト計画書、総合テスト仕様書 ・個別計画（総合テスト）工程完了報告書 ・テストデータ ・移行計画書 ・移行結果報告書 ※1パッケージの場合にカスタマイズ部分だけ提示される。 ※2インフラ統合基盤利用の場合には含まれない
操作研修関連資料	・操作手順書（一般利用者向け及び情報システム管理者向け） ・研修用資料
運用設計及び保守設計関連資料	・運用設計書 ・保守設計書 ・設計（運用・保守・移行）工程完了報告書 ・運用・保守作業分担、実施手順等 ・各種管理台帳（課題管理表、リスク管理表、運用保守作業 報告書、完了報告書、障害報告書、運用保守記録、作業計画書、議事録）等（様式）
システム移行関連資料	・タイムスケジュール ・移行リハーサル結果報告書 ・作業手順書 ・体制図
現物関連	・ソースコード一式 ・実行プログラム一式 ・ソフトウェア製品パッケージ ・ライセンス証書 ・インストールメディア類等 ※現物関連の成果物は本番への適用をもって納品とする。
引継書	・引継資料一覧 ・課題、リスク引継事項 ・案件特性及びシステム特性に伴う個別引継事項

	・運用レベル合意書 ・総経費算出xxカスタマイズ履歴書（開発費、機器更改 費、運用・保守費、カスタマイズ費及びカスタマイズ箇所・内容・理由を明記）
プロジェクト管理	・プロジェクト計画書または業務計画書 ・スケジュール管理表 ・トレーサビリティマトリクス（要求追跡） ・変更管理表 ・リスク管理表 ・レビュー管理表 ・課題管理表 ・進捗報告書 ・議事録（各種会議体）

③システム主管課は、構築事業者が作成した「プロジェクト計画書」のプロジェクト管理の記載内容について、区が求めるプロジェクト管理の基準を満たしているか、また、プロジェクトを適切に推進するために特に必要となる管理業務について明確化されているかを確認する。

管理すべき内容と具体的な手法、確認観点を管理項目ごとに以下に示す。

＜進捗管理＞

ア スケジュール管理

システム主管課は、システム構築の進捗管理にあたり、「スケジュール管理表（ＷＢ Ｓ: Work Breakdown Structure）」がプロジェクト計画書に付属されていることを確認する。

「スケジュール管理表」にはクリティカルパスが明確化されていることを確認する。システム主管課は、「スケジュール管理表」をもとに構築事業者が行う進捗管理が予

定通りに実施されていること。また、業務主管課、現行事業者及び関係事業者などのプロジェクト全体の進捗管理を実施する。特にクリティカルパスなど、プロジェクトの進捗に影響が大きい作業項目については、進捗報告会義を待たずに個別で進捗を確認することが望ましい。

スケジュール管理については、以下の表３－３ スケジュール標準項目及び表３－４スケジュール確認観点を参考にすること。

表３－３ スケジュール標準項目

No	標準項目
1	管理項番

2	タスク名（大項目、中項目、小項目）（作業、レビュー、承認など）
3	担当者
4	必要工数
5	承認者（飾区）
6	日程（タスクに分解）
7	開始及び完了 予実
8	開始及び完了 進捗率
9	ステータス（先行、オンスケ、遅延、イナズマ線、進捗線）

表３－４ スケジュール確認観点

No	管理観点	内容
1	タスクの必要工数明記 （期間との分別把握）	各タスクに対し、遂行に必要な工数を人日で明記されていること
2	タスクの細分化 （レビューの修正など潜在的タスクを明記）	日単位でタスクに割り当てる工数消化率が明記されていること レビュー後の修正タスクなどを明記されていること タスクの追加及び変更においては、区と構築事業者の合意を必要とする
3	進捗率の目安設定	スケジュール管理表細項目の進捗率は、以下に定義されていること ＜タスク＞ 未着手：０％ 着手：１０％ 担当者作業完了：５０％ 内部レビュー完了：８０％ 区へのレビュー完了：１００％
4	タスク担当の明確化	確実なタスク遂行のため、各タスクには担当者名が明記され ていること
5	要員計画との整合性	要員計画との整合性がとれていること。無理なスケジュールとなっていないことを確認する。 例：１人の担当者が複数タスクに割り当てられているが、合 計すると１人日以上の稼働となっている 等
6	余裕(バッファ)	スケジュールの余裕(バッファ)が２割程度、設けられていること

イ 進捗報告

進捗報告においては、業務主管課及びシステム主管課は、構築事業者が作成する「進捗報告書」をもとに、定められた報告期間に実施したプロジェクトの進捗状況の報告を受ける。

その際、遅延が発生している作業については、遅延の原因・対応策とその見通しについて確認する。また、業務主管課及びシステム主管課は、会議体等がない場合にも定期的（週 1 回程度）にメールで進捗状況の報告を受けること。

なお、構築事業者においてクリティカルパスに関するスケジュールの遅延が想定された際には、即時で区へ報告させること。その際、原因と対策を併せて報告させること。スケジュール遅延の原因が区にある場合には、上長と協議したうえで対応の目途を事業者に伝え、リリースに影響がないか確認する。

ウ 会議体

会議体は「プロジェクト計画書」で定められている内容に沿って実施する。

会議開催においては、会議の目的、ゴールを事前に明確に定め、プロジェクトの進捗を阻害せぬよう、あらかじめ選定された参加者のみで行うことが望ましい。

また、会議における資料は、参加者が事前に確認できていることが望ましいため、要件定義等の個別検討会議を除き、原則として２営業日前までに参加者へ送付し、会議の主旨や議題等を共有することとする。

主な会議体を、以下の表３－５ 主な会議体と目的に示す。

表３－５ 主な会議体と目的

会議体	目的	頻度
進捗報告会議（定例会）	進捗、リスク、課題、変更管理状況の確認	１回/月
個別検討会議	仕様や課題に関する検討及び調整	１～２回/週
工程完了判定会	工程の開始・終了の判定（要件定義・設計、開発・ テスト）	随時
内部定例会	区の関係者間でプロジェクトの推進状況の確認や課題の共有及び検討	１～２回/週

※「プロジェクト計画書」に定められた会議体と内容がかい離している場合には「プロジェクト計画書」の内容を優先する。不足している会議がある場合には実施を検討し、必要性がある場合に実施する。

なお、各会議体（内部定例会を除く）における議事録については、構築事業者が３営業日以内に作成し区へ提出することとし、その際、業務主管課及びシステム主管課は議事録の記載内容及び決定事項や課題、実施期限等の認識に相違がないかを確認すること。また、議事録へコメントは５営業日以内に構築事業者に提示すること。

＜変更管理＞

制度や方針の変更から仕様等の変更が余儀なくされる場合には、変更管理を行う。変

更管理の手順として、構築事業者において「変更管理表」を作成した後、変更対象資料、理由、変更前後の状態、変更による影響、変更者等を記録することとする。

また、要件定義工程において作成された「【様式 1】トレーサビリティマトリクス（要求追跡）」を利用して影響箇所を特定したうえで、修正対応及び対応結果について「変更管理表」への反映を構築事業者に依頼する。

以下に作業ルートを明確化したフローを示す。

＜品質管理＞

品質管理においては、構築事業者が作成する「プロジェクト計画書」において品質の基準を定めること。また、プロジェクト計画時点では品質の基準が立てられない場合には、必ず前工程終了までに、当該工程の合格基準を定めておくこと。

高い品質の成果物を実現するため、工程終了時に構築事業者から提示された成果物に対し、システム主管課は「要件定義書」と比較し、内容が不足している場合は構築事業者に対し指摘を行う。品質管理は各工程で実施し、可視化されるべき事項が記載されているかどうか各工程で確認すること。

ア 工程成果物の確認観点

工程成果物に対する主な確認観点を以下に示す。

工程	チェック観点
全行程	・プロジェクト計画書に基づく網羅性確認
要件定義、設計工程共通	・表記の統一性 ・曖昧さの回避、分かりやすさの追求 ・システムとして明らかな機能欠如がないこと ・指摘事項の反映（レビュー管理表を使用） ・トレーサビリティマトリクスを用いた仕様書記載要件の確認
テスト前工程	・テスト計画として主に以下内容が明記されていること目的、検証ポイント、完了基準、試験範囲 環境、前提条件、制約・留意事項、体制

なお、工程成果物の確認においては、「【資料 5】構築プロジェクト成果物様式」を参考に観点に漏れがないか確認すること。

イ 成果物表記ルール

システム主管課は構築事業者から提示された成果物について「【資料 1】成果物品質チェックリスト」を用いて品質確認を実施する。

表記ルールについては、事前に構築事業者に閲覧させ、認識させておくことが望ましい。

ウ レビュー管理表

「レビュー管理表」を利用することにより、反映すべき指摘事項の網羅性、正当性を向上させる。レビュー管理表運用の基準を以下に示す。

・レビュー翌営業日・・・構築事業者が区へ「レビュー管理表」を送付

・レビュー管理表受領後３営業日・・・区が構築事業者へ「レビュー管理表」の内容に

対しコメントする

エ 設計工程（基本設計）及びテスト工程における品質基準

構築プロジェクトにおいて、構築事業者がプロジェクト計画書に示す品質基準に対し、その品質基準が適正であるかを判断するために、区においても設計工程（基本設計）及びテスト工程の品質基準を定め、システム構築の品質を担保する。

区の品質基準の設定においては、ＩＰＡ（情報処理推進機構）が民間の構築プロジェクト実績を調査・分析し統計をまとめた「ＩＰＡのソフトウェア開発データ白書」を参考にすること。

システム主管課は設計工程（基本設計）およびテスト工程において、以下の品質基準をもとに定量的及び定性的に判断を行うこと。

◆定量的に判断

・設計工程における判断

システム主管課は構築事業者に対し、基本設計書を作成するにあたり、実際にレビューに掛かったページに対する工数及び、レビューの際にあがった指摘件数の実績を提示させ、中央値以上の数値となっており、一定以上の品質が保たれていることを確認する。

人時／ページ

	ＰＪ 件数	最小	P25	中央	P75	最大	平均	標準偏差
基本設計レビュー実績工数	74	0.018	0.079	0.297	3.615	120.267	7.293	21.981

件／ページ

	ＰＪ 件数	最小	P25	中央	P75	最大	平均	標準偏差
基本設計レビュー指摘件数	270	0.000	0.110	0.281	0.620	10.000	0.580	0.991

・試験工程における判断

システム主管課は構築事業者に対し、開発したプログラムに対し実施した、結合テスト及び総合テスト結果について、プログラムのソース１０００行(ＫＳＬＯＫ:ｋ Ｓｏｕｒｃｅ Ｌｉｎｅｓ Ｏｆ Ｃｏｄｅ)あたりのテストケース数及び検出バグ数を提示させ、その数値が中央値以上であり一定以上の品質が保たれていることを確認する。

件／ＫＳＬＯＫ

	ＰＪ 件数	最小	P25	中央	P75	最大	平均	標準偏差
結合テスト （テストケース）	901	0.125	16.422	39.022	91.364	63.800.000	232.744	2.266.010
総合テスト （テストケース）	963	0.017	4.460	12.439	34.721	15.200．000	98.561	760.056

件／ＫＳＬＯＫ

	ＰＪ 件数	最小	P25	中央	P75	最大	平均	標準偏差
結合テスト検出バグ数（原因）	413	0.000	0.428	1.175	2.369	700.000	3.849	34.597
総合テスト検出バグ数（原因）	414	0.000	0.063	0.200	0.726	32.066	0.756	2.112

◆定性的に判断

システム主管課は構築事業者に対し試験において検出されたバグについては、分類及び傾向分析（機能別、処理別、障害分類（何故バグが起きているかなど））を実施させ報告を受けること。また、設計工程（基本設計）及びテスト工程において、区の品質基準に満たない場合には構築事業者に品質基準を満たしていない理由を求め、報告内容から判断すること。

＜課題管理・リスク管理＞

システム主管課は、プロジェクトを実行するうえで発生する課題について「課題管理表」を用いて明文化し、構築事業者に検討経緯や対応方針を記録、管理させる。また、対応主体となる担当者を明確化し、課題が解決するまで管理を継続させる。課題が解決したかどうかについては、システム主管課の承認をもってこれを達成とし完了とする。

課題管理においてはメールやコミュニケーションツール、個人が把握している課題などに管理が分散しやすいため、構築事業者においてプロジェクト全体の「課題管理表」を作成し、プロジェクトの進捗に影響する課題全てをxx管理するものとする。なお、構築事業者が行う課題管理においては、フォーマットは問わない。しかし、「【様式 3】課題管理表」を参考に標準的な記載項目が不足している場合は追加したうえで利用させること。

以下、表３－６ 課題管理標準項目及び表３－７ 課題管理観点を参考にすること。表３－６ 課題管理標準項目

No	標準項目
1	項番
2	課題名
3	課題内容
4	ステータス
5	発生日
6	完了予定日
7	完了日
8	対応責任者
9	対応内容

表３－７ 課題管理観点

No	管理観点	内容
1	課題・ＴｏＤｏとリスクを別冊書式で管理	「課題」及び「リスク」がそれぞれ独立した状態（別冊で管理）で、かつ適切に管理が行われていること
		＜課題管理における管理ルール＞ ・対応期限は空白にしない ・対応者は担当者名を記載する ・課題を解決するための解決プロセスがタスクまで細分化する ・個別検討会で課題の棚卸を実施する
2	課題の重みづけ設定	課題について重要度及び緊急度（対応期限）で重みづけを設定されていること ＜重要度＞ ・費用及びリリースに影響なし ：０Ｐ ・費用及びリリースへの影響は限定的：２０Ｐ ・費用及びリリースに影響あり ：５０Ｐ ・費用及びリリースに大きく影響あり：１００Ｐ ＜緊急度（対応期限）＞ ・期限はない ：０Ｐ ・１週間から１か月 ：２０Ｐ ・２日～６日 ：５０Ｐ ・１日以内 ：１００Ｐ
3	優先度	重要度及び緊急度（対応期限）を用い、以下の計算式より優先度スコアの高いものから順に対応優先

		度を決める 重要度×緊急度（対応期限）＝優先度スコア ０の場合に課題管理は不要とする
4	課題解決基準の明確化	課題の「ゴール」が明記されており共有できること

なお、将来発生が考えられる懸念事項をリスク管理対象とする。リスク管理においては、以下、表３－８ リスク管理観点を参考にすること。

なお、構築事業者が行うリスク管理においては、フォーマットは問わない。しかし、

「【様式 4】リスク管理表」を参考に、記載観点が不足している場合は追加したうえで利用させること。

システム主管課においては、構築事業者が行うリスク管理の内容を確認及び監督する。

表３－８ リスク管理観点

No	管理観点	内容
1	リスクとなる条件	影響度及び発生確率からリスク管理対象とする 「条件」を以下に示す ＜影響度＞ ・費用及びリリースに影響なし ：０Ｐ ・費用及びリリースへの影響は限定的：２０Ｐ ・費用及びリリースに影響あり ：５０Ｐ ・費用及びリリースに大きく影響あり：１００Ｐ ＜発生確率＞ ・発生する可能性はない ：０Ｐ ・発生する可能性が低い ：２０Ｐ ・条件により発生する ：５０Ｐ ・必ず発生する ：１００Ｐ 影響度×発生確率＝リスクスコア リスクスコアが高い順に優先度を決める ０の場合にリスク管理は不要とする
2	影響の定量化	リスクが顕在化した場合の「影響」が以下の観点など定量的に記載されていること ① 品質：プロジェクト計画書および前工程までに定められていた品質は保てるか ② コスト：費用がいくらかかるのか（全てのリス

クがコストに紐づくものではない。後工程で吸収できるものは影響なしと判断する）

③ 納期：スケジュールへの影響はあるのか

＜コミュニケーション管理＞

プロジェクトのコミュニケーション管理について、業務主管課、システム主管課、情報システム課、事業者、関係各課などプロジェクトの参画者同士でコミュニケーションツールが違うことにより、情報格差や認識の相違によるコミュニケーションロスが発生することがある。

これを防止するため、構築事業者がコミュニケーション方法の案を提示したものについては、システム主管課がプロジェクト関係者間で円滑にコミュニケーションが行えると判断したうえで承認を行うこととする。また、双方において連絡窓口を明確にする。

また、コミュニケーションのプラットフォームが提示されない場合においても、関係者間で以下のコミュニケーションルールを明確にし、実施すること。

・メーリングリスト登録者

・窓口担当者

・資料添付のパスワード設定

・各種依頼時の管理方法 など

会議体及び進捗報告のコミュニケーションについては、＜進捗管理＞を参照すること。

＜情報セキュリティ管理＞

プロジェクトに参加するもの全員に対する情報セキュリティ管理の遵守、「情報セキュリティに関する規則」及び「情報セキュリティ対策基準」に沿ったシステムの機能要件の実装、非機能要件への実装の確認及び安全性の確保が可能な計画となっているかを確認し確実にする。

また、情報セキュリティ要件を定める際には、内閣府サイバーセキュリティセンターが規定する「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」を参考とする。

＜構成管理・文書管理＞

プロジェクトの成果物を管理する目的や作成する成果物を明確にし、作成した成果物を格納した場所を明確にして、その成果物の変更時の維持管理を実施する。

なお、作成した成果物についてはバージョンの最新・過去を問わず、これらを探すことなく参照できるものとし、変更の影響を理解したうえで成果物に対する変更を確実に行う。

構築事業者が作成するプログラムの構成管理は、プロジェクト計画書に定められて

いる構成管理が正しく行われていることを確認する。パッケージが更新（変更及び追加）される際には、必ず事業者にて「デグレード」観点でのリグレッションテストを実施させ、結果を報告させる。なお、デグレードの試験ケースは事前に区側でも把握しており、内容について承認されている状態のものが使用されていること。

以下にリグレッションテストの概要イメージを示す。

④作成された「業務計画書」及び「プロジェクト計画」が、調達仕様書等、事業者提案書、契約書等と整合が取れていること、必要な項目が網羅されていること、計画が妥当であることの確認を経て区と構築事業者がプロジェクト計画の内容を合意する。

⑤構築プロジェクト開始に伴うキックオフミーティングの実施は区と構築事業者において、実施することを合意したプロジェクトにおいて開催する。開催する場合、システム主管課 は、プロジェクトの関係者（「２ プロジェクト推進体制の確立」で決定したもの）を招集 し、プロジェクトの背景や目的、プロジェクトの実施計画について情報を共有し認識合わせ を行う。なお、キックオフミーティングは、「プロジェクト計画書」を用いて実施し、区及 び事業者の双方がプロジェクトを実施するうえでの体制やスケジュール、コミュニケーシ ョンルール、実施手段を合意する場とする。

(4) 完了条件・チェックポイント

①業務計画書及びプロジェクト計画書が作成されていること。

②業務計画書及びプロジェクト計画書の内容を確認のうえ合意していること。

Ⅲ 開発工程管理

開発工程は原則として、使用する開発手法であるウォーターフォール方式の構築プロセスに基づいた要件定義、基本設計、詳細設計、開発／単体テスト、総合テスト（ユーザーテスト含む）とする。

本ガイドラインでは、各工程について目的、役割分担、成果物、手順、確認観点などの運用及び管理方法を明確にし、構築プロジェクト実施の際、一定以上の品質が保てるものとする。

(1) 開発工程とテスト工程の関係性

開発工程管理の実施方針としてⅤ字モデルを採用する。

要件定義（業務・機能）から基本・詳細設計（業務・機能）及び開発、テストまでの一連の流れにおける、開発工程とテスト工程の関係性を以下の図に示す。

また、要件定義（運用・保守・移行）及び設計（運用・保守・移行）は、業務要件（業務・機能）及び機能要件（業務・機能）が確定した時点から着手するものとしている。

なお、パッケージ利用の場合においては、要件定義（業務・機能）工程と設計（業務・機能）工程が並行して行われることがあるが、その際、システム主管課と構築事業者が協議を行い、並行する理由が合理的であることを条件に実施できるものとする。

(2) トレーサビリティマトリクス採用対象案件

要求が確実に機能に反映されていることを確認するためには、トレーサビリティマトリクスの運用が必要となるが、業務計画書対象案件、システム規模が小さく機能全てに目が届くものや、機能に対する要求追跡の管理が不要となる案件においては、作業効率化の観点からトレーサビリティマトリクスの運用は実施不要とする。

トレーサビリティマトリクスを作成する際には、「【様式 1】トレーサビリティマトリクス（要求追跡）」を利用すること。

トレーサビリティマトリクスの運用要否について、「Ⅱ 構築プロジェクトの立上げ及び管理」のプロジェクト管理パターンに準ずること。

１ 要件定義（業務・機能）工程

＜概要＞

業務主管課及びシステム主管課は、構築事業者が作成した「要件定義書（業務・機能

版）」に対し、「調達仕様書」の内容と事業者提案内容をふまえ、区が求める要件が満たされているかを確認し、必要に応じて構築事業者と調整を行い、業務及び機能の要件定義を確定させる。

要件定義工程（業務・機能）は、業務の見直し内容をふまえて、情報システムが備えるべき機能・性能等を具体的に定め、明確化する工程である。また、プロジェクトの目標を達成するうえで、極めて重要な工程であり、明確な要件定義を行えない場合、計画に対する遅延または情報システムの機能・性能が要求水準に満たないものとなる事態等が発生する可能性が高まるため、適切に取り組む必要がある。

＜目的＞

信頼性、安全性の確保された業務及び必要なサービスを区民に提供するために、必要な業務及び機能の要件を確定させる。

1.1 要件定義（業務・機能）

業務主管課及びシステム主管課は、構築事業者が作成した「要件定義書（業務・機能版）」に対し、区が求める業務要件、システム全体要件、機能要件、及び非機能要件が確実に反映されていることを確認し、必要に応じて修正及び課題等の調整を行う。

運用、保守及び移行要件に関しては、「４ 要件定義（運用・保守・移行）工程」において検討及び調整を実施する。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・要件定義書内容確認（業務要件、システム全体要件（業務部分）機能要件） ・要件定義調整 ・成果物内容確認及びコメント
システム主管課	・要件定義書（業務・機能版）、新業務フロー、トレーサビリティマトリクス（要求追跡）作成依頼 ・要件定義書内容確認（システム全体要件（システム部分）、非機能要件）

	・要件定義調整 ・成果物内容確認及びコメント
構築事業者	・要件定義調整 ・要件定義書（業務・機能版）、新業務フロー、トレーサビリティマトリクス（要求追跡）作成 ・成果物内容説明及び修正

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
契約書	要件定義書（業務・機能版）
調達仕様書
事業者提案書
契約前仕様調整結果
現行業務フロー（※1）	新業務フロー
【様式 1】トレーサビリティマトリクス（要求追跡）	トレーサビリティマトリクス（要求追跡）

※1 業務主管課は現行業務フローが存在しない場合は入力情報として用いず、構築事業者とともに新たにフローを作成すること。

(4) 手順と役割

① 業務主管課は、入力情報となる「契約書」「調達仕様書」「事業者提案書」「契約前仕様調整結果」各要求機能に対し区が想定する業務と、構築事業者が想定している実現方法の認識をすり合わせる、フィットアンドギャップによる仕様調整を実施する。

フィットアンドギャップは「現行業務フロー」をもとに、新システムのパッケージ機能での業務の実現方法を検討する。また、「現行機能一覧」をもとに現行機能と新システムのパッケージ機能との突合を行う。「現行業務フロー」がない場合には、後工程の「新業務フロー」作成と併せて構築事業者と業務主管課が協力し、新システムのパッケージ機能で業務の遂行が可能であるか確認し、仕様に漏れがないことを確認する。

フィットアンドギャップの際に、仕様の漏れや、法・制度改正による仕様の追加が発生した際の仕様追加を実施するか否かの判断を以下の図１－１－１ 仕様追加フローをもとに決定する。

図１－１－１仕様追加フロー

契約後の仕様追加においては、仕様追加を要求する担当課が「【様式 5】仕様追加要求                                                                                                     理由書」に理由を記載し、費用（変更費用を含めた費用全体額）に応じた決裁者の承認を得たもののみを仕様追加対応として取り扱うものとする。

また、原則、仕様追加要求に掛けられる改修費用（システムインテグレート（SI）、カ                                                                                                       スタマイズ）は原契約費用の１０％以下までとする。

② システム主管課は、構築事業者に対し「契約書」、フィットアンドギャップ結果をもとに「要件定義書」を、また、現行業務フロー及び業務要件をもとに「新業務フロー」の作成を依頼する。その他、各種要件がどの機能に実装されているかを可視化した「トレー

サビリティマトリクス（要求追跡）」の作成を依頼する。作成の際には「【様式 1】トレーサビリティマトリクス（要求追跡）」を利用すること。

③ 業務主管課は、構築事業者が作成した要件定義書の「業務要件、システム全体要件（業務部分）機能要件」に関する内容、システム主管課は、以下の表１－１－１ 要件定義項目に基づく「システム全体要件（システム部分）、非機能要件」に関する内容について、記載の漏れがないことを確認する。また、詳細な内容チェックについては、「【資料 2】要件定義書チェックリスト」に沿って確認を行い、記載内容に認識の齟齬がある場合は構築事業者と調整を行う。

表１－１－１ 要件定義項目

チェック対象項目	要件定義項目
システム全体（必須チェック項目）	業務に関する事項
	システム方式に関する事項
	取扱いデータに関する事項
	規模に関する事項
	機能に関する事項
	情報セキュリティに関する事項
画面がある場合	画面に関する事項
	アクセシビリティに関する事項
帳票がある場合	帳票に関する事項
他システムとの接続がある場合	外部インターフェースに関する事項
性能に対する明確な要求がある場合	性能に関する事項
システムの継続稼働に対する明確な要求がある場合	完全性に関する事項
	可用性に関する事項
	信頼性に関する事項
	災害対策に関する事項
将来取扱いデータ、利用者の増大が見込まれる場合	拡張性に関する事項
テスト環境に対する明確な要求がある場合	テストに関する事項

要件定義の調整が必要となる場合について、以下の表１－１－２ 要件定義調整事項に示す。

表１－１－２ 要件定義調整事項

No	調整事項
1	事業者が作成した要件定義の総量に疑義がある場合
2	事業者提案による調達仕様書記載要件からの要件変更の提案がある場合

3	調達仕様書記載要件に不備（不足、過剰、誤認識）が存在している場合
4	調達仕様書作成段階から業務見直しや制度変更が発生し、要件に影響する場合
5	システム連携している他システム側の要件に変更が生じた場合
6	インフラ統合基盤を利用する場合において、インフラ統合基盤側の要件に変更が生じた場合

④業務主管課は、構築事業者が作成した新業務フローにおいて、実際に業務運用が行えることを確認したうえで、実装する機能が正しく要件定義書に反映されているかを確認することとする。⑤ 業務主管課は構築事業者に対し、調整結果を「レビュー管理表」で管理することを依頼する。

⑥ 業務主管課及びシステム主管課は、修正方法（修正箇所・修正内容）の提案を受けたうえで承認を行う。修正結果については「トレーサビリティマトリクス（要求追跡）」及び「レビュー管理表」をもとに確認し、要求の漏れや修正内容、影響箇所に認識の相違がないかを確認することとする。「レビュー管理表」作成の際には、「【様式２】レビュー管理表」を利用する。

(5) 完了条件、チェックポイント

① 業務主管課及びシステム主管課は、設計・構築事業者が作成した「要件定義書（業務・機能版）」及び新業務フローについて、機能漏れがなく業務運用が行えることを確認したうえで受領していること。また、調整により課題が発生している場合には、要件定義工程にて全て対応完了していること前提とする。ただし、後工程に引き継がれる課題については、対応時期や対策、現段階でのリスクが明確となっていること。

② 「要件定義書（業務・機能版）」について「トレーサビリティマトリクス（要求追跡）」により要件の網羅性が担保されていること。

(6) 留意点等

① 業務主管課及びシステム主管課は、構築事業者が作成した「トレーサビリティマトリクス（要求追跡）」については、この工程において完成ではなく、以降の工程（設計、開発・テスト）で適宜、構築事業者に更新させ、完成度を高めていくものであることを認識しておくこと。

② 現行システムに存在しない業務及び機能を、新システムの仕様調整の際に漏らさないためには、事前に現行業務における課題や、法・制度改正による業務の変更点などを整理し、変更および追加が必要となる機能を入力情報に反映しておくこと。反映できなかった場合は、フィットアンドギャップの際に明らかにすること。なお入力情報が存在しない場合は仕様変更及び契約変更の可能性があることを十分に留意すること。

1.2 要件定義（業務・機能）の承認

業務主管課及びシステム主管課と構築事業者との間で実施された要件定義の調整及び合意結果をもとに、業務主管課長及びシステム主管課長は要件定義の承認を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・成果物内容確認及びコメント ・業務課長へ承認依頼（業務要件、システム全体要件（業務部分）、機能要件） ・工程完了承認
システム主管課	・要件定義（業務・機能）工程完了報告書作成依頼 ・成果物内容確認及びコメント ・システム主管課長へ承認依頼（システム全体要件（システム部分）、非機能要件） ・工程完了承認
構築事業者	・要件定義（業務・機能）工程完了報告書作成 ・成果物レビュー

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
要件定義書（業務・機能版）	要件定義（業務・機能）工程完了報告書
新業務フロー
トレーサビリティマトリクス（要求追跡）

(4) 手順と役割

① システム主管課は構築事業者に要件定義工程における「要件定義（業務・機能）工程完了報告書」の作成を依頼する。受領した「要件定義（業務・機能）工程完了報告書」に対し業務主管課及びシステム主管課は、以下の観点により、要件定義工程の作業が完了していることを確認し、結果を報告書へ記載する。

表１－２－１ 要件定義（業務・機能）工程作業完了確認観点

観点項目

要件の総量を確認していること。また、定めた要件で全ての想定している業務が実施できること

要件に対し、実装可否や範囲が定まっていること

要件定義（業務・機能）工程で実施すべきタスクが全て完了していること

要件定義（業務・機能）工程で作成された成果物のレビューが全て実施され、摘出された不具合の対策が全て完了し、合格基準を満たしている

要件定義（業務・機能）工程で作成された成果物について、必要とされる承認が全て得られている

こと

プロジェクト計画書に定めたスケジュールどおりに進められていること

特定された不具合要因に基づき、未然防止等に向けたxx的な対応が取られていること

未完のタスクや合格基準未達の成果物があった場合、次工程以降への影響が限定的で、次工程の開始に影響がないか、また、リカバリプランが明確となっていること

② 業務主管課は「業務要件、システム全体要件（業務部分）、機能要件」に関する内容を業務主管課長に、システム主管課は「システム全体要件（システム部分）、非機能要件」関する内容についてシステム主管課長に承認依頼を行う。

③ 業務主管課長及びシステム主管課長は「要件定義（業務・機能）工程完了報告書」をもとに要件定義工程の承認を行う。また、内容に不備がある場合には、不備の内容を明示する。

④ システム主管課は、構築事業者に対し不備の内容を「レビュー管理表」で管理することを依頼する。

⑤ 業務主管課及びシステム主管課は、構築事業者の対応結果に対し、「レビュー管理表」をもとに確認を行う。

(5) 完了条件、チェックポイント

①要件定義（業務・機能）工程の工程完了報告会議において、構築事業者からの報告が行われ、プロジェクトオーナー（システム主管課長 or 業務主管課長もしくは両者）の承認をもって工程完了としていること。

「業務計画書」案件の工程完了報告の場合には会議体である必要はない。要件定義（業務・機能）工程における完了時の確認観点を以下に示す。

表１－２－２ 要件定義（業務・機能）工程完了確認観点

No	項目	チェック内容
1	スケジュールの評価	当初に定めたスケジュールに対し予定通り完了しているか。当初スケジュールを越えている場合には、後続の工程への影響とその対応策について構築事業者から報告を受けていて、 リリースに影響がないことを確認できているか。
2	残課題確認	残課題がないか。残課題がある場合には、課題の対応完了時期が明確であるか。明確でない場合、また、後続に影響があるクリティカルパスに関係する課題の場合にはリスクとして管理しているか。課題管理の際には「【様式 3】課題管理表」を用 いること。
3	リスク管理	リスクがある場合には、全体スケジュールから切り離し、別線 表でスケジュール管理が行われているか。リスク管理の際には「【様式 4】リスク管理表」を用いること。
4	成果物チェック	プロジェクト計画書に定められた工程成果物が当該工程において全て提出されていること。また、「要件定義書（業務・機能版）」が「【資料 2】要件定義書チェックリスト」を用いて 確認され品質が保たれているか。
5	要件網羅性の担保	「要件定義書」について、「トレーサビリティマトリクス（要 求追跡）」による要件の網羅性の担保が行われているか。

２ 設計（業務・機能）工程

＜概要＞

業務主管課及びシステム主管課は、構築事業者において作成された基本・詳細設計について、要件定義の内容が全て設計に反映されていることを確認し、必要に応じて修正及び課題等の調整を行う。

＜目的＞

構築事業者が作成した「基本設計書」「詳細設計書」について、区が求める要件を満たしていることをトレーサビリティマトリクス（要求追跡）、課題管理表、リスク管理表など、定量的にかつ可視化された資料を用いて妥当性を確認する。

2.1 基本・詳細設計（業務・機能）

業務主管課及びシステム主管課は、構築事業者が作成した「基本設計書」に対し、区が求める業務要件、機能要件、及び非機能要件が確実に反映されていることを確認し、必要に応じて修正及び課題等の調整を行う。

詳細設計においては、「詳細設計書」が成果物として作成されていることを確認する。

なお、パッケージの場合、すべての機能に対して設計書は作成されないケースが多く、（フロ

ー、マニュアル程度となる）設計がなされるのは主にはカスタマイズ部分となる。

運用、保守及び移行設計に関しては、「５ 設計（運用・保守・移行）工程」において実施する。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア 更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・設計書内容確認（業務要件、システム全体要件（業務部分）機能要件）及びコメント
システム主管課	・基本設計書、詳細設計書、トレーサビリティマトリクス（要求追跡）作成依頼 ・設計書内容確認（システム全体要件（システム部分）、非機能要件）及び コメント
構築事業者	・基本設計書、詳細設計書、トレーサビリティマトリクス（要求追跡）作成 ・成果物内容説明及び修正

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
要件定義書（業務・機能）	基本設計書
基本設計書	詳細設計書
トレーサビリティマトリクス（要求追跡）	トレーサビリティマトリクス（要求追跡）

(4) 手順と役割

① システム主管課は、構築事業者に対し「要件定義書（業務・機能）」をもとに「基本設計書」、「基本設計書」をもとに「詳細設計書」の作成を行うことを依頼する。また、設計工程で発生した差分の更新を明確にするため「トレーサビリティマトリクス（要求追跡）」において示すことを依頼すること。また、基本設計書作成の際に「Ⅱ.3 プロジェクト実施計画の合意 ＜品質管理＞ エ 設計工程（基本設計）及びテスト工程における品質基準」の内容に沿って、レビュー実績工数、レビュー指摘件数の実績取得を依頼すること。

② 業務主管課は、構築事業者が作成した基本設計書について「業務要件、システム全体要件（業務部分）、機能要件」に関する内容を、システム主管課は「システム全体要件（シ

ステム部分）、非機能要件」関する内容についてトレーサビリティマトリクス（要件追跡）をもとに記載の漏れがないことを確認する。

「基本設計書」の詳細な内容の確認は、要件定義工程において作成した業務フローの内容と合致し、業務が行えるかの視点で「【資料 3】設計書チェックリスト」に示す観点等から、システムの特性を当てはめた設計要素を抽出し、設計要素の実現手段の設計が行われていることを確認する。

また、「Ⅱ.3 プロジェクト実施計画の合意 ＜品質管理＞ エ 設計工程（基本設計）及びテスト工程における品質基準」の内容をもとに、作成された設計書が区の品質基準を満たしていることを確認すること。基準を満たしていない場合は構築事業者に説明を求めること。

③ 業務主管課及びシステム主管課は、基本設計に対し要件定義内容の反映確認、また、詳細設計に対する基本設計内容の反映確認の結果、設計内容に不備（不足、過剰、不一致または矛盾）が発生している事項について、構築事業者との調整を行う。

④ システム主管課は、基本設計書に対し「Ⅱ.3 プロジェクト実施計画の合意 ＜品質管理＞ エ 設計工程（基本設計）及びテスト工程における品質基準」の内容をもとに、レビュー実績工数、レビュー指摘件数の実績が区の品質基準を満たしていることを確認すること。基準を満たしていない場合は構築事業者に説明を求めること。

⑤ システム主管課は構築事業者に対し、調整結果を「レビュー管理表」で管理することを依頼する。

⑥ 業務主管課及びシステム主管課は、修正方法（修正箇所・修正内容）の提案を受けたうえで承認を行う。また、修正結果については「トレーサビリティマトリクス（要求追跡）」及び「レビュー管理表」をもとに確認を行い、要求の漏れや修正内容、影響箇所に認識の相違がないかを確認すること。

⑦システム主管課は、「詳細設計書」が作成されていることを確認する。

(5) 完了条件、チェックポイント

① システム主管課は完了時には設計・構築事業者が作成した「基本設計書」について、内容確認のうえで受領していること。また、課題については、詳細設計工程にて解決すべき課題が全て解決（クローズ）していること。後工程に引き継がれる課題については、対応時期や対策、現段階でのリスクが明確になっていること。

② 「基本設計書」について「トレーサビリティマトリクス（要求追跡）」による要件の網羅性の担保が行われていること。

③ 「詳細設計書」が作成されていること。

(6) 留意点等

① 設計内容に対する要件定義内容反映確認の結果、設計内容に要件との不適合（要件の不確実、不足または過剰）が判明し、要件の見直しを行う場合は、当該要件の見直し内容を変更管理の対象として扱うこと。また、その際、課題及びリスクが全体スケジュールに影響するものと判断されるものについては、別線表でスケジュール管理を行うこと。

2.2 設計書の承認（業務・機能）

業務主管課及びシステム主管課と構築事業者との間で実施された設計内容の合意結果をもとに、業務主管課長及びシステム主管課長は作成された「基本設計書」及び「詳細設計書」について承認を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・成果物内容確認及びコメント ・業務課長へ承認依頼（業務要件、システム全体要件（業務部分）、機能要件） ・工程完了承認
システム主管課	・設計（業務・機能）工程完了報告書作成依頼 ・成果物内容確認及びコメント ・システム主管課長へ承認依頼（システム全体要件（システム部分）、非機能要件） ・工程完了承認
構築事業者	・設計（業務・機能）工程完了報告書作成及び修正 ・設計（業務・機能）工程完了報告

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
基本設計書	設計工程完了報告書
詳細設計書
トレーサビリティマトリクス（要求追跡）

(4) 手順と役割

① システム主管課は構築事業者に設計工程における「設計工程完了報告書」の作成を依頼する。受領した「設計工程完了報告書」に対し業務主管課及びシステム主管課は、以下の観点により、設計工程の作業が完了していることを確認し結果を報告書へ記載する。

表２－２－１ 設計（業務・機能）工程作業完了確認観点

観点項目

設計に対し、要求が確実に反映されていること

設計工程で実施すべきタスクが全て完了していること

設計工程で作成された成果物のレビューが全て実施され、検出された不具合の対策が全て完了し、合格基準を満たしていること

設計工程で作成された成果物について、必要とされる承認が全て得られていること

プロジェクト計画書に定めたスケジュールどおりに進められていること

特定された不具合要因に基づき、未然防止等に向けたxx的な対応が取られていること

未完のタスクや合格基準未達の成果物があった場合、次工程以降への影響が限定的で、次工程の開始に影響がないか、また、リカバリプランが明確となっていること

② 業務主管課は「業務要件、システム全体要件（業務部分）、機能要件」に関する内容を業務主管課長に、システム主管課は「システム全体要件（システム部分）、非機能要件」に関する内容をシステム主管課長に承認依頼を行う。

③ 業務主管課長及びシステム主管課長は「工程完了報告書」をもとに設計工程の承認を行う。また、内容に不備がある場合には、不備の内容を明示する。

④ システム主管課は、構築事業者に対し不備の内容を「レビュー管理表」で管理することを依頼する。

⑤ 業務主管課及びシステム主管課は、構築事業者の対応結果に対し、「レビュー管理表」をもとに確認を行う。

(5) 完了条件、チェックポイント

① 設計（業務・機能）工程の工程完了報告会議において、構築事業者からの報告が行われ、プロジェクトオーナー（システム主管課長 or 業務主管課長もしくは両者）の承認をもって工程完了としていること。

「業務計画書」案件の工程完了報告の場合には会議体である必要はない。設計（業務・機能）工程における完了時の確認観点を以下に示す。

表２－２－２ 設計（業務・機能）工程完了確認観点

No	項目	チェック内容
1	スケジュールの評価	当初に定めたスケジュールに対し予定通り完了しているか。当初のスケジュールを越えている場合には、後続の工程への影響とその対応策について構築事業者から報告を受けてい て、リリースに影響がないことを確認できているか。
2	残課題確認	残課題がないか。残課題がある場合には、課題の対応完了時期が明確であるか。明確でない場合、また、後続に影響があるクリティカルパスに関係する課題の場合にはリスクとして管理しているか。課題管理の際には「【様式 3】課題管理表」を用 いること。
3	リスク管理	リスクがある場合には、全体スケジュールから切り離し、別線 表でスケジュール管理が行われているか。リスク管理の際には「【様式 4】リスク管理表」を用いること。
4	成果物チェック	プロジェクト計画書に定められた工程成果物が当該工程において全て提出されていること。また、「基本設計書」が「【資料 3】設計書チェックリスト」を用いて確認され品質が保たれ ているか。
5	要件網羅性の担保	「基本設計書」について、「トレーサビリティマトリクス（要 求追跡）」による要件の網羅性の担保が行われているか。
6	品質の担保	区が定める品質基準を満たしているか。満たしていない場合に理由が明確かつ納得できるものであるか。

３ 開発工程

＜概要＞

システム主管課は、構築事業者が実施する開発について、構築事業者から開発工程の報告を受け、必要に応じて調整を行う。

＜目的＞

信頼性、安全性の確保された業務及び必要なサービスの区民への提供が、正しくスケジュールどおりに実現されるように構築事業者が行う開発工程を管理する。

3.1 開発の管理

システム主管課は、構築事業者が実施する開発について実施状況の管理を行う。システム開発結果報告の内容に対し、「基本設計書」の内容と機能に沿って開発されていることを確認する。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	-
システム主管課	・システム開発依頼 ・システム開発結果報告内容確認
構築事業者	・システム開発 ・システム開発結果報告

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
基本設計書	プログラム一式
詳細設計書
運用・保守設計書

(4) 手順と役割

システム主管課は、構築事業者から受ける開発工程の完了報告及びプログラム一式に対し「基本設計書」の内容に沿って開発されていることを確認する。

(5) 完了条件、チェックポイント

構築事業者からプログラム一式を受領していて、内容に不備がないことを確認していること。

(6) 留意点等

① 単体テストについては、構築事業者において開発と併せて行うこと。また、単体テストにおいては、主にプログラムの論理構造に着目して実施すること。（ホワイトボックステスト）

② パッケージにカスタマイズが入る際には、「Ⅱ.3 プロジェクト実施計画の合意 ＜構成管理・文書管理＞」をもとに構築事業者にリグレッションテストを実施させること。

② 開発工程終了後に円滑に次工程へ進められるように、この時点から結合テスト工程の準備を進めておくこと。

3.2 開発の承認

システム主管課と構築事業者が作成した「開発工程完了報告書」に対し、システム主管課長は承認を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・業務課長へ承認依頼 ・工程完了承認
システム主管課	・開発工程完了報告書作成依頼 ・開発工程完了報告書確認及びコメント ・システム主管課長へ承認依頼 ・工程完了承認
構築事業者	・開発工程完了報告書作成及び修正 ・開発工程完了報告

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
プログラム一式	開発工程完了報告書
単体テスト結果

(4) 手順と役割

① システム主管課は構築事業者に開発工程における「開発工程完了報告書」の作成を依頼する。また、受領した「開発工程完了報告書」に対し、以下の観点により、開発工程の作業が完了していることを確認し、結果を報告書へ記載する。

表３－２－１ 開発工程作業完了確認観点

観点項目

開発したプログラムが開発環境にて動作することが確認されていること

開発工程で実施すべきタスクが全て完了していること

開発工程で作成された成果物のレビューが全て実施され、検出された不具合の「傾向」が把握できていること

開発工程で作成された成果物について、必要とされる承認が全て得られていること

プロジェクト計画書に定めたスケジュールどおりに進められていること

特定されたバグ・不具合要因に基づき、未然防止等に向けたxx的な対応が取られていること

未完のタスクや合格基準未達の成果物があった場合、次工程以降への影響が限定的で、次工程の開始に影響がないか、また、リカバリプランが明確となっていること

② 構築事業者から提出された「開発工程完了報告書」について、業務主管課は業務主管課長に、システム主管課はシステム主管課長に承認依頼を行う。

③ 業務主管課長及びシステム主管課長は「開発工程完了報告書」をもとに開発工程の承認を行う。また、内容に不備がある場合には、不備の内容を明示する。

④ システム主管課は、構築事業者に対し不備の内容を「レビュー管理表」で管理することを依頼する。

⑤ 業務主管課及びシステム主管課は、構築事業者の対応結果に対し、「レビュー管理表」をもとに確認を行う。

(5) 完了条件、チェックポイント

開発工程の工程完了報告会議において、構築事業者からの報告が行われ、プロジェクトオーナー（システム主管課長 or 業務主管課長もしくは両者）の承認をもって工程完了としていること。

「業務計画書」案件の工程完了報告の場合には会議体である必要はない。開発工程における完了時の確認観点を以下に示す。

表３－２－２ 開発工程完了確認観点

No	項目	チェック内容
1	スケジュールの評価	当初に定めたスケジュールに対し予定通り完了しているか。当初のスケジュールを越えている場合には、後続の工程への影響とその対応策について構築事業者から報告を受けてい て、リリースに影響がないことを確認できているか。
2	残課題確認	残課題がないか。残課題がある場合には、課題の対応完了時期が明確であるか。明確でない場合、また、後続に影響があるクリティカルパスに関係する課題の場合にはリスクとして管理しているか。課題管理の際には「【様式 3】課題管理表」を用 いること。
3	リスク管理	リスクがある場合には、全体スケジュールから切り離し、別線表でスケジュール管理が行われているか。リスク管理の際に は「【様式 4】リスク管理表」を用いること。
4	成果物チェック	プロジェクト計画書に定められた工程成果物が当該工程にお

いて全て提出されていること。また、成果物の内容が事前に定められた品質の合格基準に達していること。

４ 要件定義（運用・保守・移行）工程

＜概要＞

業務主管課及びシステム主管課は、構築事業者が作成した「要件定義書（完成版）」に対し、「調達仕様書」の内容と事業者提案内容をふまえ、区が求める要件が満たされているかを確認し、必要に応じて構築事業者と調整を行い、運用、保守及び移行の要件定義を確定させる。

＜目的＞

信頼性、安全性の確保された業務及び必要なサービスを区民に提供するために、必要な運用、保守及び移行の要件を確定させる。

4.1 要件定義（運用・保守）

業務主管課及びシステム主管課は、「１ 要件定義（業務・機能）工程」「２ 設計（業務・機能）工程」で明確になった業務及び機能をもとに、構築事業者が作成した「要件定義書（運用・保守要件追加版）」に対し、区が求める要件が確実に反映されていることを確認し、必要に応じて修正及び課題等の調整を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・要件定義書内容確認（業務に関すること） ・要件定義調整 ・成果物内容確認及びコメント
システム主管課	・要件定義書（運用・保守要件追加版）作成依頼 ・要件定義書内容確認（システム運用、保守に関すること） ・要件定義調整 ・成果物内容確認及びコメント
構築事業者	・要件定義調整 ・要件定義書（運用・保守要件追加版）作成

・成果物内容説明及び修正

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
要件定義書（業務・機能版）	要件定義書（運用・保守要件追加版）
基本設計書
詳細設計書

(4) 手順と役割

① システム主管課は、入力情報となる「要件定義書（業務・機能版）」「基本設計書」

「詳細設計」をもとに「要件定義書（運用・保守要件追加版）」を作成することを構築事業者に依頼する。構築事業者は、「要件定義書（運用・保守要件追加版）」の作成にあたり、業務主管課に対し現行運用の実態及び課題、その他要望のヒアリングを実施する。

② 業務主管課は、構築事業者が作成した「要件定義書（運用・保守要件追加版）」について、以下の表４－１－１ 要件定義項目に基づき、記載の漏れがないことを確認する。また、詳細な内容チェックについては、「【資料 2】要件定義書チェックリスト」に沿って確認を行い、記載内容に認識の齟齬がある場合は構築事業者と調整を行う。

表４－１－１ 要件定義（運用・保守）項目

チェック対象項目	要件定義項目
システム運用に対する明確な要求がある場合	システム運用に関する事項
構築後、開発ベンダによる保守が必要な場合	保守に関する事項

要件定義の調整が必要となる場合について、以下の表４－１－２ 要件定義調整事項に示す。

表４－１－２ 要件定義（運用・保守）調整事項

No	調整事項
1	事業者提案による調達仕様書記載要件からの要件変更の提案がある場合
2	調達仕様書記載要件に不備（不足、過剰、誤認識）が存在している場合
3	調達仕様書作成段階から業務見直しや制度変更が発生し、要件に影響する場合
4	システム連携している他システム側の要件に変更が生じた場合
5	インフラ統合基盤を利用する場合において、インフラ統合基盤側の要件に変更が生じた場合

③ システム主管課は構築事業者に対し、調整結果を「レビュー管理表」で管理することを依頼する。

④ 業務主管課及びシステム主管課は、修正方法（修正箇所・修正内容）の提案を受けた

うえで承認を行う。また、修正結果については「レビュー管理表」をもとに確認し、要求の漏れや修正内容、影響箇所に認識の相違がないかを確認することとする。

(5) 完了条件、チェックポイント

①業務主管課及びシステム主管課は、設計・構築事業者が作成した「要件定義書（運用・保守要件追加版）」について、要件漏れがなくシステムの運用保守が行えることを確認したうえで受領していること。また、調整により課題が発生している場合には、要件定義（運用・保守・移行）工程にて全て対応完了していること。後工程に引き継がれる課題については、対応時期や対策、現段階でのリスクが明確となっていること。

4.2 要件定義（移行）

業務主管課及びシステム主管課は、構築事業者が作成した「要件定義書（完成版）」に対し、区が求める移行要件（システム・データ）が確実に反映されていることを確認し、必要に応じて修正及び課題等の調整を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア 更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・要件定義書内容確認（業務に関すること） ・要件定義調整 ・成果物内容確認及びコメント
システム主管課	・要件定義書（完成版）作成依頼 ・要件定義書内容確認（移行（システム・データ）に関すること） ・要件定義調整 ・成果物内容確認及びコメント
構築事業者	・要件定義調整 ・要件定義書（完成版）作成 ・成果物内容説明及び修正
現行事業者	・要件定義書（完成版）作成に必要な情報を提供

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
要件定義書（運用・保守要件追加版）	要件定義書（完成版）
基本設計書
詳細設計書

(4) 手順と役割

① システム主管課は、入力情報となる「要件定義書（運用・保守要件追加版）」「基本設計書」「詳細設計」をもとに移行要件を含めた「要件定義書（完成版）」を作成することを構築事業者に依頼する。その際、現行事業者に対し、構築事業者が求める「要件定義書（完成版）」作成に必要な移行（システム・データ）情報の提供を依頼する。

② 業務主管課は、構築事業者が作成した「要件定義書（完成版）」について、以下の表

４－２－１ 要件定義項目に基づき、記載の漏れがないことを確認する。また、詳細な内容チェックについては、「【資料 2】要件定義書チェックリスト」に沿って確認を行い、記載内容に認識の齟齬がある場合は構築事業者と調整を行う。

表４－２－１ 要件定義（移行）項目

チェック対象項目	要件定義項目
データ移行に対する明確な要求がある場合	データ移行に対する事項
システム移行に対する明確な要求がある場合	システム移行に関する事項

要件定義の調整が必要となる場合について、以下の表４－２－２ 要件定義調整事項に示す。

表４－２－２ 要件定義（移行）調整事項

No	調整事項
1	事業者提案による調達仕様書記載要件からの要件変更の提案がある場合
2	調達仕様書記載要件に不備（不足、過剰、誤認識）が存在している場合
3	調達仕様書作成段階から業務見直しや制度変更が発生し、要件に影響する場合
4	システム連携している他システム側の要件に変更が生じた場合
5	インフラ統合基盤を利用する場合において、インフラ統合基盤側の要件に変更が生じた場合

③ システム主管課は構築事業者に対し、調整結果を「レビュー管理表」で管理することを依頼する。

④ 業務主管課及びシステム主管課は、修正方法（修正箇所・修正内容）の提案を受けたうえで承認を行う。修正結果については「レビュー管理表」をもとに確認し、要求の漏れや修正内容、影響箇所に認識の相違がないかを確認することとする。

(5) 完了条件、チェックポイント

①業務主管課及びシステム主管課は、設計・構築事業者が作成した「要件定義書（完成版）」について、要件漏れがなくシステム移行が行えることを確認したうえで受領していること。また、調整により課題が発生している場合には、要件定義（運用・保守・移行）工程にて全て対応完了していること。後工程に引き継がれる課題については、対応時期や対策、現段階でのリスクが明確となっていること。

4.3 要件定義（運用・保守・移行）の承認

業務主管課及びシステム主管課と構築事業者との間で実施された要件定義（運用・保守・移行）の調整及び合意結果をもとに、業務主管課長及びシステム主管課長は要件定義の承認を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア 更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・成果物内容確認及びコメント ・業務課長へ承認依頼（業務に関すること） ・工程完了承認
システム主管課	・要件定義工程完了報告書作成依頼 ・成果物内容確認及びコメント ・システム主管課長へ承認依頼（システム運用、保守、移行（システム・データ）に関すること） ・工程完了承認
構築事業者	・要件定義工程完了報告書作成及び修正 ・要件定義工程完了報告

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
要件定義書（完成版）	要件定義（運用・保守・移行）工程完了報告書

(4) 手順と役割

① システム主管課は構築事業者に要件定義工程における「要件定義（運用・保守・移行）工程完了報告書」の作成を依頼する。受領した「要件定義（運用・保守・移行）工程完了報告書」に対し業務主管課及びシステム主管課は、以下の観点により、要件定義工程の作業が完了していることを確認し、結果を報告書へ記載する。

表１－２－１ 要件定義（運用・保守・移行）工程作業完了確認観点

観点項目

要件に対し、実装可否や範囲が定まっていること

要件定義（運用・保守・移行）工程で実施すべきタスクが全て完了していること

要件定義（運用・保守・移行）工程で作成された成果物のレビューが全て実施され、摘出された不

具合の対策が全て完了し、合格基準を満たしている

要件定義（運用・保守・移行）工程で作成された成果物について、必要とされる承認が全て得られていること

プロジェクト計画書に定めたスケジュールどおりに進められていること

特定された不具合要因に基づき、未然防止等に向けたxx的な対応が取られていること

未完のタスクや合格基準未達の成果物があった場合、次工程以降への影響が限定的で、次工程の開始に影響がないか、また、リカバリプランが明確となっていること

運用保守の内容について十分に検討されていること

② 業務主管課は業務に関する内容を業務主管課長に、システム主管課はシステム運用、保守及びシステム移行に関する内容についてシステム主管課長に承認依頼を行う。

③ 業務主管課長及びシステム主管課長は「要件定義（運用・保守・移行）工程完了報告書」をもとに要件定義工程の承認を行う。また、内容に不備がある場合には、不備の内容を明示する。

④システム主管課は、構築事業者に対し不備の内容を「レビュー管理表」で管理することを依頼する。

⑤ 業務主管課及びシステム主管課は、構築事業者の対応結果に対し、「レビュー管理表」をもとに確認を行う。

(5) 完了条件、チェックポイント

①要件定義（運用・保守・移行）工程の工程完了報告会議において、構築事業者からの報告が行われ、プロジェクトオーナー（システム主管課長 or 業務主管課長もしくは両者）の承認をもって工程完了としていること。

「業務計画書」案件の工程完了報告の場合には会議体である必要はない。

要件定義（運用・保守・移行）工程における完了時の確認観点を以下に示す。

表１－２－２ 要件定義（運用・保守・移行）工程完了確認観点

No	項目	チェック内容
1	スケジュールの評価	当初に定めたスケジュールに対し予定通り完了しているか。当初のスケジュールを越えている場合には、後続の工程への影響とその対応策について構築事業者から報告を受けてい て、リリースに影響がないことを確認できているか。
2	残課題確認	残課題がないか。残課題がある場合には、課題の対応完了時期が明確であるか。明確でない場合、また、後続に影響があるクリティカルパスに関係する課題の場合にはリスクとして管理しているか。課題管理の際には「【様式 3】課題管理表」を用 いること。
3	リスク管理	リスクがある場合には、全体スケジュールから切り離し、別線 表でスケジュール管理が行われているか。リスク管理の際には「【様式 4】リスク管理表」を用いること。
4	成果物チェック	プロジェクト計画書に定められた工程成果物が当該工程において全て提出されていること。また、「要件定義書（完成版）」が「【資料 2】要件定義書チェックリスト」を用いて確認され 品質が保たれているか。

５ 設計（運用・保守・移行）工程

＜概要＞

業務主管課及びシステム主管課は、「要件定義書（完成版）」をもとに構築事業者に運用・保守設計の作成を依頼する。構築事業者は、運用及び保守方法や障害発生時の対応について、実装方法を考慮したうえで運用・保守設計を行う。

その他、システム移行及びデータ移行に備えて、移行の方法、環境、ツール、段取り等を記載した移行計画の作成を依頼する。内容を確認し必要に応じて、事業者と調整する。

＜目的＞

構築事業者が作成した「運用・保守設計」、及び「移行計画」が、区が求める要件を満たしたうえで、課題管理表、リスク管理表などを用いて、定量的にかつ可視化された資料で判断する。

5.1 運用・保守設計

システム主管課は、運用・保守設計工程においては、非機能要件の実現と、システムの維持に必要な管理機能内容の設計を行うため、構築事業者に対し、定常時における作業項目、役割分担、作業スケジュール等をまとめた「運用設計書」及び「保守設計書」の作成を依頼する。

構築事業者が作成した「運用設計書」及び「保守設計書」について、「要件定義書（完成版）」

「基本設計書」の内容と整合性がとれ、区が求める要件を満たしていることを確認する。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・設計書内容確認
システム主管課	・運用設計書、保守設計書作成依頼 ・設計書内容確認
構築事業者	・運用設計書、保守設計書作成 ・成果物レビュー

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
要件定義書（完成版）	運用設計書保守設計書
基本設計書

(4) 手順と役割

① システム主管課は構築事業者に対し、システムの特性を考慮した「運用設計書」及び

「保守設計書」の作成を依頼する。

② 業務主管課及びシステム主管課は、構築事業者が作成した「運用設計書」及び「保守設計書」について、以下の表５－１－１ 運用・保守設計の記載事項について漏れがないことを確認する。

表５－１－１ 運用・保守設計の記載事項

	記載項目	内容
運用設計	作業項目及び作業概要	内容について、「【資料 3】設計書チェックリスト」_運用に関する事項を参照すること
	役割の定義	業務主管課、システム主管課、開発・設計事業者、運用事業者、保守事業者等の役割が明確になっていること
	整備する運用関連文書	附属文書を記載すること
	成果物	計画書、体制表、手順書、作業報告書、管理台帳等が記載されていること

	その他	運用における前提条件、時間・予算・品質等制約条件が記載されていること
保守設計	作業項目及び作業概要	内容について、「【資料 3】設計書チェックリスト」_保守に関する事項を参照すること
	役割分担	業務主管課、システム主管課、開発・設計事業者、運用事業者、保守事業者等の役割が明確になっていること
	作業体制	定常時と緊急時における区、事業者双方の連絡体制が体制図として記載されていること
	作業スケジュール	日次、月次、年次、その他定期、随時の作業が整理されていること
	整備する保守関連文書	附属文書が記載されていること
	成果物	計画書、体制表、手順書、作業報告書、管理台帳等が記載されていること
	保守形態、保守環境	オンサイト、オフサイト、作業場所等が記載されていること
	その他	保守における前提条件、時間・予算・品質等制約条件が記載されていること

③ 業務主管課及びシステム主管課は、運用・保守設計内容に対し要件定義及び基本設計内容の反映確認の結果、設計内容に不備（不足、過剰、不一致または矛盾）が発生している事項について、構築事業者との調整を行う。

④ システム主管課は構築事業者に対し、調整結果を「レビュー管理表」で管理することを依頼する。

⑤ 業務主管課及びシステム主管課は、修正方法（修正箇所・修正内容）の提案を受けたうえで承認を行う。修正結果については「レビュー管理表」をもとに確認を行い、要求の漏れや修正内容、影響箇所に認識の相違がないかを確認すること。

(5) 完了条件、チェックポイント

①システム主管課は設計・構築事業者が作成した「運用設計書」及び「保守設計書」について、内容確認のうえで受領していること。また、課題については、運用・保守設計工程にて解決すべき課題が全て解決（クローズ）していること。後工程に引き継がれる課題については、対応時期や対策、現段階でのリスクが明確になっていること。

(6) 留意点等

① システム主管課は、「運用設計書」及び「保守設計書」の作成を依頼する際に、開発、運用、及び保守と契約不適合責任の範囲内で実施する作業の分担を明確にすることを構

築事業者に認識させておくこと。

② システム主管課は、構築事業者に対しシステムのサービスの正常状態を示す「運用レベル合意書」の作成を依頼する。作成タイミングは、総合テスト実施後のシステムが正常に稼働している状態の確認が取れた以降に実施する。作成された「運用レベル合意書」は業務主管課、システム主管課、構築事業者及び運用事業者において、内容の合意を実施すること。

「運用レベル合意書」の記載事項は以下とする。

表５－１－２ 運用レベル合意書の記載事項

記載項目	内容（正常な状態）
物理環境	ランプ状態配置図
ネットワーク環境	ネットワーク接続状態、設定
ソフトウェア	ソフトウェア設定
正常稼働時サービス一覧	正常稼働時のサービス一覧
年間処理計画及びイベント	年間処理計画、イベント計画
バッチ処理スケジュール予定	バッチ処理スケジュール予定表
連携対象	システム連携先及び連携元
障害時対応合意（通常保守、イレギュラー対応）	稼働情報（稼働時間、２４時間３６５日）一次切り分け対応者 障害時の対応ルート

③ 本工程で作成した、「運用設計書」及び「保守設計書」については、総合テスト終了後に必要に応じて内容の見直しを実施すること。その際、総合テスト工程内で対応を行うこと。

5.2 移行計画

システム主管課は、システム移行及びデータ移行に備えて、構築事業者に対し、移行の方法、環境、ツール、段取り等を記載した「移行計画書」の作成を求める。「移行計画書」の提出を受けた後、その案について移行リスクを低減するため、必要に応じ、関係機関、関係事業者等と調整を行う。

移行計画の作成については開発工程と並行で進め、移行リハーサルまでに完了させること。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・設計書内容確認
システム主管課	・移行設計書作成依頼 ・設計書内容確認
構築事業者	・移行設計書作成 ・成果物レビュー
現行事業者	・移行設計書に必要な情報を提供 ・データ抽出

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
要件定義書（完成版）	移行計画書
基本設計書
運用設計書

(4) 手順と役割

① システム主管課は、構築事業者に対し、本番環境へのシステム移行及びデータ移行を計画的かつ確実に進めるため、「要件定義書（完成版）」「基本設計書」及び「運用設計書」に基づき、「移行計画書」の作成を依頼する。

② システム主管課は、現行事業者に対し、構築事業者が求める「移行設計書」作成に必要な情報の提供と必要に応じたデータ抽出を依頼する。（本作業においては、本項の(6)留意点②を参照）

③ 業務主管課及びシステム主管課は、「移行計画書」について以下の項目に漏れがないことを確認する。また、内容に不足がある場合は構築事業者と調整を行う。

表５－２－１ 移行計画書項目

	記載項目
移行対象	移行対象となる現行システムのプログラム、ファイル、データ等
	上記移行対象の属性情報（レイアウト、サイズ、格納場所等）
移行方式	移行方式（一括移行、段階移行、並行運用）

	上記移行方式の前提条件・特記事項
体制と役割	主管課の体制と役割
	構築事業者の体制と役割
	その他関係者（現行事業者等）の体制と役割
切戻し	切戻しのための判断基準、期限、手順等
環境	移行実施の各工程で利用する環境（開発環境、テスト環境、本番環境）
	上記環境の前提条件・特記事項
ツール	作成ツールとその目的・概要
	各ツールの詳細（機能概要、作成方法、利用方法、利用環境等）
データ	データの断面（静止点）の管理 ※段階移行の際にマスタデータにおいて「断面」に不備がないことが重要となる
手順	システム移行、データ移行の作業手順（移行データ調査、移行データ整備、本番環境構築、移行リハーサル、移行判定、本番切替え）及びその概要、実施時期
	移行作業手順詳細（作業内容、作業者、作業方法）
	移行判定方法（判定項目、達成基準、判定時期）
リスク管理	想定リスク
	移行による影響
	リスク対応策及び影響軽減策

④ 業務主管課及びシステム主管課は、要件定義、基本設計、及び運用設計内容の反映確認の結果、移行計画内容に不備（不足、過剰、不一致または矛盾）が発生している事項について、構築事業者との調整を行う。

⑤ システム主管課は構築事業者に対し、調整結果を「レビュー管理表」で管理することを依頼する。

⑥ 業務主管課及びシステム主管課は、修正方法（修正箇所・修正内容）の提案を受けたうえで承認を行う。修正結果については「レビュー管理表」をもとに確認を行い、要求の漏れや修正内容、影響箇所に認識の相違がないかを確認すること。

(5) 完了条件、チェックポイント

①システム主管課は設計・構築事業者が作成した「移行計画書」について、内容確認のうえで受領していること。また、課題については、移行計画工程にて解決すべき課題が全て解決（クローズ）していること。後工程に引き継がれる課題については、対応時期や対策、現段階でのリスクが明確になっていること。

(6) 留意点等

①「移行計画書」は、現行システムの資産を適切に引き継ぎ、次期システムの稼働に必要

となる環境を整備するための計画であるため、次期システムの設計内容をふまえたものにすると同時に、現在の業務運用状況や現行システムの状況を鑑みた現実的かつ実行的な計画とすることが必要である。そのため、「移行計画書」の作成に当たっては、現行事業者や情報システム利用者等と調整し、現在の業務運用状況や現行システム状況を十分把握したうえで行うこと。

② 現行事業者のデータ抽出作業および移行作業に伴う費用については、実際に現行事業者に作業負担が発生するため作業費の要求にはある程度の正当性が認められると考えられるが、データ抽出のためのアプリケーション開発費は、事業者都合によるデータ加工であるため、区への請求に正当性は認められない。

データ抽出に掛かる費用について、区と現行事業者が取り交わした合意内容が契約書に記載されているかを確認し、その内容をもとに交渉を行うこと。

5.3 設計書の承認（運用・保守・移行）

業務主管課及びシステム主管課と構築事業者との間で実施された設計（運用・保守・移行）内容の合意結果をもとに、業務主管課長及びシステム主管課長は作成された「運用設計書」「保守設計書」及び「移行計画書」について承認を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 関係者及び役割

業務主管課	・成果物内容確認 ・業務課長へ承認依頼（業務に関すること） ・工程完了承認
システム主管課	・設計（運用・保守・移行）工程完了報告書作成依頼 ・システム主管課長へ承認依頼（システム運用、保守、システム移行に関すること） ・工程完了承認
構築事業者	・設計（運用・保守・移行）工程完了報告書作成 ・設計（運用・保守・移行）工程完了報告

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
運用設計書	設計（運用・保守・移行）工程完了報告書
保守設計書
移行計画書
トレーサビリティマトリクス（要求追跡）

(4) 手順と役割

① システム主管課は構築事業者に設計工程における「設計（運用・保守・移行）工程完了報告書」の作成を依頼する。受領した「設計（運用・保守・移行）工程完了報告書」に対し業務主管課及びシステム主管課は、以下の観点により、設計工程の作業が完了していることを確認し結果を報告書へ記載する。

表５－３－１ 設計工程作業完了確認観点

観点項目

設計に対し、要求が確実に反映されていること

設計（運用・保守・移行）工程で実施すべきタスクが全て完了していること

設計（運用・保守・移行）工程で作成された成果物のレビューが全て実施され、検出された不具合の対策が全て完了し、合格基準を満たしていること

設計（運用・保守・移行）工程で作成された成果物について、必要とされる承認が全て得られていること

プロジェクト計画書に定めたスケジュールどおりに進められていること

特定された不具合要因に基づき、未然防止等に向けたxx的な対応が取られていること

未完のタスクや合格基準未達の成果物があった場合、次工程以降への影響が限定的で、次工程の開始に影響がないか、また、リカバリプランが明確となっていること

② 業務主管課は業務に関する内容を業務主管課長に、システム主管課はシステム運用保守及びシステム移行に関する内容をシステム主管課長に承認依頼を行う。

③ 業務主管課長及びシステム主管課長は「設計（運用・保守・移行）工程完了報告書」をもとに設計工程の承認を行う。また、内容に不備がある場合には、不備の内容を明示する。

④ システム主管課は、構築事業者に対し不備の内容を「レビュー管理表」で管理することを依頼する。

⑤ 業務主管課及びシステム主管課は、構築事業者の対応結果に対し、「レビュー管理表」をもとに確認を行う。

(5) 完了条件、チェックポイント

①設計（運用・保守・移行）工程の工程完了報告会議において、構築事業者からの報告が行われ、プロジェクトオーナー（システム主管課長 or 業務主管課長もしくは両者）の承認をもって工程完了としていること。

「業務計画書」案件の工程完了報告の場合には会議体である必要はない。設計（運用・保守・移行）工程における完了時の確認観点を以下に示す。

表５－３－２ 設計（運用・保守・移行）工程完了確認観点

No	項目	チェック内容
1	スケジュールの評価	当初に定めたスケジュールに対し予定通り完了しているか。当初スケジュールを越えている場合には、後続の工程への影響とその対応策について構築事業者から報告を受けていて、 リリースに影響がないことを確認できているか。
2	残課題確認	残課題がないか。残課題がある場合には、課題の対応完了時期が明確であるか。明確でない場合、また、後続に影響があるクリティカルパスに関係する課題の場合にはリスクとして管理しているか。課題管理の際には「【様式 3】課題管理表」を用 いること。
3	リスク管理	リスクがある場合には、全体スケジュールから切り離し、別線 表でスケジュール管理が行われているか。リスク管理の際には「【様式 4】リスク管理表」を用いること。
4	成果物チェック	プロジェクト計画書に定められた工程成果物が当該工程において全て提出されていること。また、「基本設計書」が「【資料 3】設計書チェックリスト」を用いて確認され品質が保たれ ているか。

６ テスト工程管理

＜概要＞

システム主管課は、構築事業者に実施するテスト工程の詳細が記載されたテスト全体計画、個別計画（結合テスト・総合テスト）の作成を求め、テスト内容の十分性、テストデータの適正性等を確認したうえでテストを実施する。必要に応じて課題等の調整を行うものとする。

また、テスト工程の最終確認として区が構築事業者の協力のもと総合テスト計画（ユーザーテスト）を作成する。検収テスト実施の際には、開発されたシステムが区の要求事項を適切に実現し、業務運用が想定どおり実施できることを確認する。

＜目的＞

システム主管課は、各種テストにおいて機能実装、動作、運用、業務において信頼性、安全性 の確保された業務及び必要なサービスが区民に提供を実現できるようにテスト工程管理を行う。

6.1 テスト全体計画

「テスト全体計画書」では、テスト工程（結合テスト・総合テスト）とそれぞれ試験観点を明らかにする。「個別計画書」内では、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を明確にする。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア 更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	-
システム主管課	・テスト全体計画書作成依頼 ・成果物内容確認及びコメント
構築事業者	・テスト全体計画書作成 ・成果物内容説明及び修正

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
要件定義書	テスト全体計画書
基本設計書
詳細設計書
運用設計書

(4) 手順と役割

①システム主管課は、構築事業者に対し、「テスト全体計画書」の作成を依頼する。「テスト全体計画書」においては以下、表６－１－１ テスト種別を参考に、実施すべきテストが網羅されているか確認すること。

表６－１－1 テスト種別

工程	テスト種別	テスト内容
結合テスト	機能テスト	「基本設計書」をもとに各機能の結合箇所の確認を行う テスト

	負荷テスト	重い負荷をかけて、負荷のレベルに応じて想定どおりに動作するか確認するテスト
	性能テスト	性能に係る要件（応答時間、スループット等）に適合していることを確認するテスト
	シナリオテスト	業務（フロー）に則ったシナリオをベース行うテスト
	運用テスト	・信頼性テスト 信頼性に係る要件（平均故障時間、エラー数の目標値等）に適合していることを確認するテスト ・障害回復テスト ソフトウェア、ハードウェア、回線等について、障害発生時の処理を確認するテスト ・説明書テスト 説明書の内容に従って、情報システムの利用者が操作を行うことができるか確認するテスト
	ユーザーテスト	使いやすさを確認するテスト

(5) 完了条件、チェックポイント

①「テスト全体計画書」についてシステム主管課長の承認を得ていること。また、その結果を構築事業者に通知していること。

6.2 個別計画（結合テスト）

結合テスト計画及び実施、結果承認の流れと内容を以下に示す。

6.2.1 結合テスト計画

「結合テスト計画書」「結合テスト仕様書」においての作業内容、テスト実施範囲、テスト体制、テスト環境、作業スケジュール、合否判定基準、ケース等を明確にする。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア 更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課 ・成果物内容確認（結合テスト仕様書）及びコメント

システム主管課	・結合テスト計画書、結合テスト仕様書作成依頼 ・成果物内容確認及びコメント
構築事業者	・結合テスト計画書作成 ・成果物内容説明及び修正

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
詳細設計書	結合テスト計画書結合テスト仕様書
運用設計書
テスト項目チェックリスト

(4) 手順と役割

① システム主管課は、構築事業者に対し「結合テスト計画書」「結合テスト仕様書」の作成を依頼する。

作成された結合テスト計画について、下記表６－２－１ 結合テスト計画書の項目の記載に漏れがないことを確認する。

表６－２－１ 結合テスト計画の項目

	確認項目
作業内容	結合テストの目的、確認・検証事項
	結合テスト開始条件・終了条件
	結合テスト対象及びテストケース（スクリプト）作成方法
	結合テストデータ作成方法
	結合テスト実施手順、実施者
	結合バグ・不具合発見時の手順、実施者
	作業内容の前提条件・特記事項
	結合テスト結果報告方法
実施範囲	結合テスト対象のシステム/範囲
	結合テストにおける「結合」の範囲
実施体制	業務主管課及びシステム主管課の体制と役割、責任範囲
	構築事業者の体制と役割、責任範囲
	その他関係者（現行事業者等）の体制と役割、責任範囲
	結合テストにおけるコミュニケーション管理方法
実施環境	結合テストを実施する場所
	結合テストで利用する環境

	結合テストで利用するツール
	実施環境・ツールの前提条件・特記事項（本番環境をテスト環境として利用する場合の情報セキュリティ上の留意点等）・制約事項
スケジュール	全体スケジュール
	各工程の作業スケジュール（テスト準備、テスト実施、バグ・不具合の修正、テ スト結果取りまとめ・報告）
合否判定基準	合格基準（品質管理指標、合格基準）
	合否判定基準
	不合格時の対応方法（再テスト、追加テスト等）

表６－２－２ 結合テスト計画の確認観点

	確認観点
作業内容	結合テストの目的が明確であり、目的と確認・検証事項が合致していること
	テスト開始条件・終了条件が明確であり、矛盾・不整合・過不足がないこと
	テスト目的、確認・検証事項に合致したテスト対象となっていること
	確認・検証事項に対して網羅性が確保できるテストケース（スクリプト）作成方法になっていること
	正確なテストデータ（正常系・異常系双方）を作成するテストデータ作成方法に なっていること
	テスト対象やテストケースをふまえたテスト実施手順、実施者になっていること
	テスト実施手順が明確であり、矛盾・不整合・過不足はないか
	テスト対象やテストケースをふまえたバグ・不具合発見時の手順、実施者になっていること
	バグ・不具合発見時の手順が明確であり、矛盾・不整合・過不足がないこと
	バグ・不具合発見時に迅速かつ正確に対応され、潜在バグなども解消が見込まれる手順、実施者になっていること
	テスト実施結果が正確に報告され、業務主管課、システム主管課、及び構築事業 者で正確な情報・実態を迅速に共有できること
	テスト実施結果を含むテスト関連資料が全て管理され、その後の情報システムの維持・改善の際に再利用可能であること
	テスト項目チェックリストに定めるテスト項目が、どのテスト（結合テスト・総合テスト）で実施あるいは省略することに合意しており、結合テストで実施され るテスト項目が検証事項に含まれていること
実施範囲	テスト可能な範囲とテスト不可の範囲を明確にしたうえで、テスト実施範囲が決められていること。また、その範囲が妥当であること

実施体制	業務主管課及びシステム主管課の役割、責任範囲がテスト目的・テスト内容に合致しており、テスト実施に必要十分な体制になっていること
	構築事業者の役割、責任範囲がテスト目的・テスト内容に合致しており、テスト実施に必要十分な体制になっていること
	その他関係者（現行事業者等）の役割、責任範囲がテスト目的・テスト内容に合致しており、テスト実施に必要十分な体制になっていること
	定常時、課題発生時に双方のタイミングで業務主管課、システム主管課、構築事業者、その他関係者が連携を図り、迅速な対応が取れる体制になっていること
実施環境	結合テストで利用する環境がテスト目的・テスト内容に合致しており、テストを実施するに十分な機能、性能を有していること
	結合テストで利用する環境が各環境の構築時期、利用可能時期と整合していること
	結合テストで利用するツールがテスト目的・テスト内容に合致しており、テストを実施するに十分な機能、性能を有していること
	環境・ツールの前提条件・特記事項・制約事項として記載されている情報セキュリティ上の留意点が適切であること
スケジュール	他の工程と整合した全体スケジュールであること
	各工程の作業項目や作業の順番に過不足、不整合がないこと
合否判定基準	設計開発実施要領で定めた品質管理と品質基準（品質管理指標、水準）が整合していること
	品質基準が明確であり、客観的なものであること
	品質基準に沿った合否判定となっていること。また、不合格時の対応方法が明確になっていること

② 「結合テスト仕様書」について、業務主管課及びシステム主管課は次の表６－２－３結合テスト仕様書項目及び表６－２－４ 結合テスト仕様書確認観点を参考に記載されていることを確認すること。

表６－２－３ 結合テスト仕様書項目

項目

テスト対象ケース名称

確認・検証事項、テスト結果の予測

テスト結果として求めるエビデンス（根拠資料）

表６－２－４ 結合テスト仕様書確認観点

項目

テストの確認・検証事項があるか

正常系に加え異常系の確認項目があるか

要件、設計内容と比較してテスト結果の予測が明確であるか

テスト結果として求めるエビデンス（根拠資料）が取得可能か

テスト結果として求めるエビデンス（根拠資料）がテスト結果を証明するのに適切か

なお、結合テストは開発した機能同士を結合した場合に設計どおりの流れによる動作が行われることを確認するものであるため、全ての機能の結合を網羅的に確認できるとする点、正常系に加え異常系のテスト結果確認も含める点に留意する。

また、検証の実施方法についてＣＩＯ補佐官やシステム支援事業者に意見を求める。

(5) 完了条件、チェックポイント

①「結合テスト計画書」及び「結合テスト仕様書」について業務主管課及びシステム主管課が確認のうえ承認していること。また、その結果を構築事業者に通知していること。

(6) 留意点等

① 結合テストにおいてはプログラムの論理構造は気にせず、入力データと出力データの結果だけに着目すること。（ブラックボックステスト）

6.2.2 結合テスト実施

業務主管課及びシステム主管課において、「結合テスト計画書」及び「結合テスト仕様書」の内容確認の後、構築事業者において結合テストを実施する。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア 更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	・結合テスト実施状況確認
システム主管課	・結合テスト実施依頼 ・結合テスト実施状況確認 ・結合テスト結果報告書作成依頼 ・結合テスト結果報告書内容確認及びコメント
構築事業者	・結合テスト実施 ・結合テスト結果報告書作成及び修正

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
結合テスト計画書	結合テスト結果報告書
結合テスト仕様書

(4) 手順と役割

① システム主管課は、構築事業者に対し「結合テスト計画書」及び「結合テスト仕様書」の内容に沿って結合テストの実施を依頼する。また、その際「Ⅱ.3 プロジェクト実施計画の合意 ＜品質管理＞ エ 設計工程（基本設計）及びテスト工程における品質基準」の内容に沿って、テストケース数、検出バグ数の実績取得を依頼すること。

② 業務主管課及びシステム主管課は、構築事業者が行う結合テスト実施状況を確認する。実施状況の確認を行う際の参考として、基本的な確認の観点等を以下の表６－２－５結合テスト実施状況の確認観点に示す。

表６－２－５ 結合テスト実施状況の確認観点

確認観点

テスト実施者、確認者がテスト体制と合致していること

適正なテストツール、テスト環境を用いていること

網羅的なテストケース（スクリプト）を用いていること

適切なテストデータを用いていること

テストにかけている時間が適切であること

バグ・不具合が全て修正されていること

バグ・不具合要因の特定に当たっては、構築事業者により調査が行われ、網羅的に要因が特定されていること

③ 業務主管課及びシステム主管課は、構築事業者がテストを実施する際に、円滑に進められるように、関係各課及び関係事業者間との調整や課題に対する方針決定、質問に対する回答を迅速に行うこと。

④ システム主管課は、構築事業者に対し、テスト結果について合否判定基準を満たすエビデンス（根拠資料）を提示させ、「結合テスト結果報告書」を作成することを依頼する。

「結合テスト結果報告書」は「結合テスト仕様書」をもとに作成すること。

⑤ システム主管課は、「Ⅱ.3 プロジェクト実施計画の合意 ＜品質管理＞ エ 設計工程

（基本設計）及びテスト工程における品質基準」の内容をもとに、テストケース数、検出バグ数の実績が区の品質基準を満たしていることを確認すること。基準を満たしていない場合は構築事業者に説明を求めること。

(5) 完了条件、チェック

①構築事業者において、「結合テスト仕様書」の全てのテスト項目を消化し、テスト項目に対するテスト結果が「結合テスト結果報告書」にまとめられていること。

(6) 留意点等

① 結合テスト工程終了後に円滑に次工程へ進められるように、この時点から総合テスト工程の準備を進めておくこと。

② 結合テストにおいてはプログラムの論理構造は気にせず、入力データと出力データの結果だけに着目すること。（ブラックボックステスト）

6.2.3 結合テスト結果の承認

業務主管課及びシステム主管課は構築事業者に対し、結合テストの実施結果の報告を求め、必要に応じ、課題等の指摘または調整を行うものとする。なお、業務主管課長及びシステム主管課長は、結合テスト結果について、設定した合否判定基準を全て満たしたと認められる場合に承認を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	・成果物内容確認及びコメント ・業務課長へ承認依頼 ・工程完了承認
システム主管課	・個別計画（結合テスト）工程完了報告書作成依頼 ・成果物内容確認及びコメント ・システム主管課長へ承認依頼 ・工程完了承認
構築事業者	・個別計画（結合テスト）工程完了報告書作成及び修正 ・個別計画（結合テスト）工程完了報告

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
結合テスト結果報告書	個別計画（結合テスト）工程完了報告書

(4) 手順と役割

① システム主管課は構築事業者に個別計画（結合テスト）工程における「工程完了報告書」の作成を依頼する。受領した「個別計画（結合テスト）工程完了報告書」に対し業務主管課及びシステム主管課は、以下表６－２－６ 個別計画（結合テスト）工程作業完了確認観点により、個別計画（結合テスト）工程の作業が完了していることを確認し、結果を報告書へ記載する。

表６－２－６ 個別計画（結合テスト）工程作業完了確認観点

観点項目

結合テスト工程で実施すべきタスクが全て完了していること

結合テスト工程で作成された成果物のレビューが全て実施され、検出された不具合の対策が全て完了し、合格基準を満たしていること

結合テスト工程で作成された成果物について、必要とされる承認が全て得られていること

プロジェクト計画書に定めたスケジュールどおりに進められていること

特定されたバグ・不具合要因に基づき、未然防止等を図るためのxx的な対応が取られていること

未完のタスクや合格基準未達の成果物があった場合、次工程以降への影響が限定的で、次工程の開始に影響がないこと、また、リカバリプランが明確となっていること

② 業務主管課及びシステム主管課は「個別計画（結合テスト）工程完了報告書」について、業務主管課長及びシステム主管課長に承認依頼を行う。

③ 業務主管課長及びシステム主管課長は「個別計画（結合テスト）工程完了報告書」をもとに個別計画（結合テスト）工程の承認を行う。また、内容に不備がある場合には、不備の内容を明示する。

④ システム主管課は、構築事業者に対し不備の内容を「レビュー管理表」で管理することを依頼する。その際、要件及び機能自体に不備があり仕様変更が必要となるものについては、構築事業者は区と協議し方針を決定したうえで対応する。

⑤ 業務主管課及びシステム主管課は、構築事業者の対応結果に対し、「レビュー管理表」をもとに確認を行う。

(5) 完了条件、チェック

①個別計画（結合テスト）工程の工程完了報告会議において、構築事業者からの報告が行われ、プロジェクトオーナー（システム主管課長 or 業務主管課長もしくは両者）の承認をもって工程完了としていること。

「業務計画書」案件の工程完了報告の場合には会議体である必要はない。個別計画（結合テスト）工程における完了時の確認観点を以下に示す。

表６－２－７ 個別計画（結合テスト）工程完了確認観点

No	項目	チェック内容
1	スケジュールの評価	当初に定めたスケジュールに対し予定通り完了しているか。当初スケジュールを越えている場合には、後続の工程への影響とその対応策について構築事業者から報告を受けていて、 リリースに影響がないことを確認できているか。
2	残課題確認	残課題がないか。残課題がある場合には、課題の対応完了時期が明確であるか。明確でない場合、また、後続に影響があるクリティカルパスに関係する課題の場合にはリスクとして管理しているか。課題管理の際には「【様式 3】課題管理表」を用 いること。
3	リスク管理	リスクがある場合には、全体スケジュールから切り離し、別線表でスケジュール管理が行われているか。リスク管理の際に は「【様式 4】リスク管理表」を用いること。
4	成果物チェック	プロジェクト計画書に定められた工程成果物が当該工程にお いて全て提出されていること。また、成果物の内容が事前に定められた品質指標に達していること。
5	品質の担保	区が定める品質基準を満たしているか。満たしていない場合に理由が明確かつ納得できるものであるか。

(6) 留意点等

①テスト結果の承認に当たっては、必要に応じて会議を開催する。また、承認状況を記録するとともに、必要に応じて承認理由や承認に当たっての前提条件等の記録を残すことで、後工程で疑義が生じたときの判断資料とする。

6.3 個別計画（総合テスト）

総合テスト計画及び実施、結果承認の流れと内容を以下に示す。

6.3.1 総合テスト計画

総合テスト計画において作業内容、テスト実施範囲、テスト体制、テスト環境、作業スケジュール、合否判定基準、テストシナリオ、テストケース等を明確にする。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	・成果物内容確認（総合テスト仕様書）及びコメント
システム主管課	・総合テスト計画書、総合テスト仕様書作成依頼 ・成果物内容確認及びコメント
構築事業者	・総合テスト計画書作成 ・成果物内容説明及び修正

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
基本設計書	総合テスト計画書総合テスト仕様書
運用設計書
テスト項目チェックリスト

(4) 手順と役割

① システム主管課は、構築事業者に対し「総合テスト計画書」「総合テスト仕様書」の作成を依頼する。

作成された総合テスト計画について、下記表６－３－１ 総合テスト計画の項目の記載に漏れがないことを確認する。また、総合テストは全体として想定したとおりに稼働するかを確認する工程であるため、一貫した業務処理を実施し、性能面、運用面、ユーザの使いやすさに係る要件の実装状況等について、業務の網羅性や、繁忙期の業務想定、例外業務等それぞれの観点から検証できるテストの設定がなされていることを確認する。

表６－３－１ 総合テスト計画の項目

	確認項目
作業内容	総合テストの目的、確認・検証事項
	総合テスト開始条件・終了条件
	総合テスト対象及びテストケース（スクリプト）作成方法
	総合テストデータ作成方法
	総合テスト実施手順、実施者

	総合バグ・不具合発見時の手順、実施者
	作業内容の前提条件・特記事項
	総合テスト結果報告方法
実施範囲	総合テスト対象のシステム/範囲
	総合テストにおける「総合」の範囲
実施体制	業務主管課及びシステム主管課の体制と役割、責任範囲
	構築事業者の体制と役割、責任範囲
	その他関係者（現行事業者等）の体制と役割、責任範囲
	総合テストにおけるコミュニケーション管理方法
実施環境	総合テストを実施する場所
	総合テストで利用する環境
	総合テストで利用するツール
	実施環境・ツールの前提条件・特記事項（本番環境をテスト環境として利用する場合の情報セキュリティ上の留意点等）
スケジュール	全体スケジュール
	各工程の作業スケジュール（テスト準備、テスト実施、バグ・不具合の修正、テスト結果取りまとめ・報告）
合否判定基準	合格基準（品質管理指標、合格水準）
	合否判定基準
	不合格時の対応方法（再テスト、追加テスト等）

表６－３－２ 総合テスト計画の確認観点

	確認観点
作業内容	総合テストの目的が明確であり、目的と確認・検証事項が合致していること
	テスト開始条件・終了条件が明確であり、矛盾・不整合・過不足がないこと
	総合テストの目的、確認・検証事項に合致したテスト対象となっていること （シナリオテスト及びサイクルテストが実施されること）
	確認・検証事項に対して網羅性が確保できるテストケース（スクリプト）作成方法になっていること
	正確なテストデータ（正常系・異常系双方）を作成するテストデータ作成方法になっていること
	テスト対象やテストケースをふまえたテスト実施手順、実施者になっていること
	テスト実施手順が明確であり、矛盾・不整合・過不足がないこと
	テスト対象やテストケースをふまえたバグ・不具合発見時の手順、実施者になっていること
	バグ・不具合発見時の手順が明確であり、矛盾・不整合・過不足がないこと

	バグ・不具合発見時に迅速かつ正確に対応され、潜在バグなども解消が見込まれる手順、実施者になっていること
	テスト実施結果が正確に報告され、業務主管課、システム主管課、及び構築事業者で正確な情報・実態を迅速に共有できること
	テスト実施結果を含むテスト関連資料が全て管理され、その後の情報システムの維持・改善の際に再利用可能であること
	テスト項目チェックリストに定めるテスト項目が、どのテスト（結合テスト・総合テスト）で実施あるいは省略することに合意しており、総合テストで実施されるテ スト項目が検証事項に含まれていること
実施範囲	テスト可能な範囲とテスト不可の範囲を明確にしたうえで、テスト実施範囲が決められていること。また、その範囲が妥当であること
実施体制	業務主管課及びシステム主管課の役割、責任範囲がテスト目的・テスト内容に合致 しており、テスト実施に必要十分な体制になっていること
	構築事業者の役割、責任範囲がテスト目的・テスト内容に合致しており、テスト実施に必要十分な体制になっていること
	その他関係者（現行事業者等）の役割、責任範囲がテスト目的・テスト内容に合 致しており、テスト実施に必要十分な体制になっていること
	定常時、課題発生時に双方のタイミングで業務主管課、システム主管課、構築事業者、その他関係者が連携を図り、迅速な対応が取れる体制になっていること
実施環境	総合テストで利用する環境がテスト目的・テスト内容に合致しており、テストを実 施するに十分な機能、性能を有していること
	総合テストで利用する環境が各環境の構築時期、利用可能時期と整合していること
	総合テストで利用するツールがテスト目的・テスト内容に合致しており、テストを実施するに十分な機能、性能を有していること
	環境・ツールの前提条件・特記事項として記載されている情報セキュリティ上の留意点が明確であること
スケジュール	他の工程と整合した全体スケジュールであること
	各工程の作業項目や作業の順番に過不足、不整合がないこと
合否判定基準	設計開発実施要領で定めた品質管理と品質基準（品質管理指標、水準）が整合し ていること
	品質基準が明確であり、客観的なものであること
	品質基準に沿った合否判定となっていること。また、不合格時の対応方法が明確になっていること

② 「総合テスト仕様書」について、業務主管課及びシステム主管課は次の表６－３－

３総合テスト仕様書項目及び表６－３－４ 総合テスト仕様書確認観点を参考に記載に

漏れがないことを確認する。

テストシナリオ及びテストケースについて、業務主管課及びシステム主管課は総合テスト、次の項目を参考としながら記載されていることを確認すること。なお、総合テストは開発したプログラムが設計どおりに動作することを確認するものであるため、全ての要件（機能）を網羅的に確認できるシナリオ及びケースとする点、正常系に加え異常系のシナリオも含める点に留意する。

特に、総合テストにおいては業務の流れに関し全体確認を行うことが必要であることから、業務要件や機能要件などの観点から網羅性が担保できるテストシナリオとすることに留意する。

また、検証の実施方法についてＣＩＯ補佐官やシステム支援事業者に意見を求める。

表６－３－３ 総合テスト仕様書項目

項目

テスト対象シナリオ及びケース名称

確認・検証事項、テスト結果の予測

テスト結果として求めるエビデンス（根拠資料）

表６－３－４ 総合テスト仕様書確認観点

項目

テストの確認・検証事項に合致したテストシナリオになっていること

全ての要件（機能）を網羅的に確認できるシナリオになっていること

正常系に加え異常系のシナリオも含まれていること

要件、設計内容と比較してテスト結果の予測が明確であること

テスト結果として求めるエビデンス（根拠資料）が取得可能であること

テスト結果として求めるエビデンス（根拠資料）がテスト結果を証明するのに適切であること

(5) 完了条件、チェックポイント

①「総合テスト計画書」及び「総合テスト仕様書」について業務主管課及びシステム主管課が確認していること。また、その結果を構築事業者に通知していること。

(6) 留意点等

① テスト手順・データの再利用対策として、システム主管課は、将来の保守や更改時におけるテスト工程の合理化に資するため、テストシナリオ・スクリプト、テストデータ等を保存し、保守後の動作確認等において、それらを一部改変して再利用できるようにするものとする。

② システム主管課は、各テストの「テスト計画書」と合わせてテストケース（スクリプ

ト）、テストデータ、テストツール、テスト実施手順を保存し、運用後の不具合発覚時の原因特定や、保守における改修箇所のテスト実施等の際に、これらを一部改変して再利用することで、効率的にテストを実施する。

③ 総合テストにおいてはプログラムの論理構造は気にせず、入力データと出力データの結果だけに着目すること。（ブラックボックステスト）

6.3.2 総合テスト計画（ユーザーテスト）

業務主管課において、開発されたシステムが実際の業務に使用できるか、また、業務プロセスに適合しているか、要求仕様の正当性などの検証を目的とした総合テスト計画（ユーザーテスト）（以下、ユーザーテスト計画という）の作成を実施する。

ユーザーテスト計画において作業内容、テスト実施範囲、テスト体制、テスト環境、作業スケジュール、合否判定基準、テストシナリオ、テストケース等を明確にする。その際、構築事業者の支援を受けて「総合テスト計画書（ユーザーテスト）」「総合テスト仕様書（ユーザーテスト）」を作成する。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	・総合テスト計画書（ユーザーテスト）、総合テスト仕様書（ユーザーテスト）作成（業務部分）
システム主管課	・総合テスト計画書（ユーザーテスト）、総合テスト仕様書（ユーザーテスト）作成（システム部分）
構築事業者	・ユーザーテスト計画作成支援

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
要件定義書（完成版）	総合テスト計画書（ユーザーテスト）総合テスト仕様書（ユーザーテスト）
運用設計書

(4) 手順と役割

① 業務主管課は、総合テスト（ユーザーテスト）（以下、ユーザーテストという）実施

に向けてユーザーテスト計画の作成をスムーズに行えるように、必要に応じて構築事業者から支援を受けること。

ユーザーテストは本番移行への可否を判断する最終段階であることから、可能な限り本番に近い状態でのテストを行うことが重要である。また、ユーザーテストは、区が主体となって行うものであり、実際のシステム利用者がテストに参加することが必須である。システム利用者がシステムの操作等について十分習熟していない場合は、構築事業者に対しシステム操作方法の説明等の支援を受けたうえで、業務主管課が責任を持ち確実にユーザーテストを実施すること。

② 業務主管課及びシステム主管課は以下の項目及び観点のもと、「総合テスト計画書（ユーザーテスト）」「総合テスト仕様書（ユーザーテスト）」を作成する。その際、業務主管課は、開発されたシステムが「要件定義書（完成版）」に記載した事項を適切に実現しているかどうかを検証するため、「総合テスト計画書（ユーザーテスト）」に基づき、実データに近いテストデータを用いて、ユーザーテストを行うものとする。特にユーザビリティ要件を検証するときは、業務主管課、システム主管課、システムの利用者がユーザーテストに参加するものとする。

「総合テスト計画書（ユーザーテスト）」の作成観点及びテストの実施状況確認観点については、以下を参考にすること。

表６－３－５ 総合テスト計画（ユーザーテスト）項目

	確認観点
作業内容	ユーザーテストの目的が明確であり、目的と確認・検証事項が合致していること
	テスト開始条件・終了条件が明確であり、矛盾・不整合・過不足がないこと
	ユーザーテストの目的、確認・検証事項に合致したテスト対象になっていること （シナリオテスト及びサイクルテストが実施されること）
	確認・検証事項に対して網羅性が確保できるテストケース（スクリプト）作成方法になっていること
	正確なテストデータ（正常系・異常系双方）を作成するテストデータ作成方法になっていること
	テスト対象やテストケースをふまえたテスト実施手順、実施者になっていること
	テスト実施手順が明確であり、矛盾・不整合・過不足がないこと
	移行前データと移行後データの現新比較の確認を実施する内容が含まれていること
	テスト対象やテストケースをふまえたバグ・不具合発見時の手順、実施者になっていること
	バグ・不具合発見時の手順が明確であり、矛盾・不整合・過不足がないこと
	バグ・不具合発見時に迅速かつ正確に対応され、潜在バグなども解消が見込まれる 手順、実施者になっていること

	テスト実施結果が正確に報告され、業務主管課、システム主管課、及び構築事業者で正確な情報・実態を迅速に共有できること
	テスト実施結果を含むテスト関連資料が全て管理され、その後の情報システムの維持・改善の際に再利用可能であること
	テスト項目チェックリストに定めるテスト項目が、どのテスト（結合テスト・総合テスト）で実施あるいは省略することに合意しており、総合テストで実施されるテスト項目が検証事項に含まれていること
実施範囲	テスト可能な範囲とテスト不可の範囲を明確にしたうえで、テスト実施範囲が決め られていること。また、その範囲が妥当であること
実施体制	業務主管課及びシステム主管課の役割、責任範囲がテスト目的・テスト内容に合致しており、テスト実施に必要十分な体制になっていること 複数課が関わるシステムの構築においては、当該システム構築課だけでなく関係課 においても検証を行う体制になっていること
	構築事業者の役割、責任範囲がテスト目的・テスト内容に合致しており、テスト実施に必要十分な体制になっていること
	その他関係者（現行事業者等）の役割、責任範囲がテスト目的・テスト内容に合致しており、テスト実施に必要十分な体制になっていること
	定常時、課題発生時ともに双方のタイミングで業務主管課、システム主管課、構築事業者、その他関係者が連携を図り、迅速な対応が取れる体制になっていること
実施環境	ユーザーテストで利用する環境がテスト目的・テスト内容に合致しており、テストを実施するに十分な機能、性能を有していること
	ユーザーテストで利用する環境が各環境の構築時期、利用可能時期と整合していること
	ユーザーテストで利用するツールがテスト目的・テスト内容に合致しており、テストを実施するに十分な機能、性能を有していること
	環境・ツールの前提条件・特記事項として記載されている、情報セキュリティ上の留意点が明確であること
スケジュール	他の工程と整合した全体スケジュールであること
	各工程の作業項目や作業の順番に過不足、不整合がないこと
合否判定基準	設計開発実施要領で定めた品質管理と品質基準（品質管理指標、水準）が整合していること
	品質基準が明確であり、客観的なものであること
	品質基準に沿った合否判定となっていること。また、不合格時の対応方法が明確になっていること

表６－３－６ 総合テスト（ユーザーテスト）計画確認観点

観点

要件定義書及び設計書に基づいて業務の流れを確認し、テストシナリオ、テストケースとして設定すべき事象、特に詳細に確認すべき機能、処理等を特定していること

要件定義段階、設計段階の課題管理表を確認し、要件の実装に注意が必要な箇所、区のニーズの実

装に齟齬が生じやすい箇所を特定し、テストシナリオ、テストケースとしての設定方法を整理してあること

現行システムの運用報告書及び保守報告書等を確認し、業務遂行に当たって犯しやすい操作ミス、

誤認識しやすい箇所等を特定し、テストシナリオ、テストケースとしての設定方法を整理してあること

③ 「総合テスト仕様書（ユーザーテスト）」について、業務主管課及びシステム主管課は次の表６－３－７総合テスト仕様書項目及び表６－３－８ 総合テスト仕様書（ユーザーテスト）確認観点を参考にテストシナリオ及びテストケースについて作成すること。なお、総合テスト（ユーザーテスト）は実際に業務が実施できるかを確認するものであるため、全ての業務を網羅的に確認できるシナリオ及びケースとする点、正常系に加え異常系のシナリオも含める点に留意する。

また、検証の実施方法についてＣＩＯ補佐官やシステム支援事業者に意見を求める。

表６－３－７ 総合テスト仕様書（ユーザーテスト）項目

項目

テスト対象シナリオ及びケース名称

確認・検証事項、テスト結果の予測

テスト結果として求めるエビデンス（根拠資料）

表６－３－８ 総合テスト仕様書（ユーザーテスト）確認観点

項目

テストの確認・検証事項に合致したテストシナリオになっていること

全ての業務を網羅的に確認できるシナリオになっていること

正常系に加え異常系のシナリオも含まれていること

要件、設計内容と比較してテスト結果の予測が明確であること

テスト結果として求めるエビデンス（根拠資料）が取得可能であること

テスト結果として求めるエビデンス（根拠資料）がテスト結果を証明するのに適切であること

(5) 完了条件、チェックポイント

①業務主管課及びシステム主管課において「総合テスト計画書（ユーザーテスト）」及び

「総合テスト仕様書（ユーザーテスト）」を作成していること。

(6) 留意点等

① テスト全体計画作成のタイミングからユーザーテスト計画の策定に着手し、発注者側の意向を結合テスト・総合テストに反映させることが望ましい。

②ユーザーテストで不具合が生じた場合は、再度、開発及びテストを行う必要がある可能性もある。

したがって、要件定義工程、及び設計工程の段階から準備を進め、ユーザーテストの正確性・必要十分性を高めるとともに、概要を早期に確定させユーザーテスト要員の確保の準備を進めておくこと。

③「総合テスト計画書（ユーザーテスト）」「総合テスト仕様書（ユーザーテスト）」を作成するうえでは、業務の運用が問題なくできるか、サービスが維持できるかの確認に重点を置くこと。「総合テスト計画書（ユーザーテスト）」にはテスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を必ず記載して作成すること。

④ テスト体制には構築事業者の品質保証担当も組み込み、不具合発生時に迅速に対応できるようにする。ユーザビリティ要件を検証するときは、業務主管課、区民事務所職員等、主たるシステムの利用者がユーザーテストに参加する。また、システム運用のみならず、業務運用の観点からの確認も必要であるため、システム利用者が積極的に参画し、構築事業者が支援・参画するよう留意する。なお、運用業務の円滑な実施を図るため、運用事業者はユーザーテスト段階から参加し、具体的な運用業務の試行を実施する。本番運用に備えて、運用事業者には運用対象である情報システムについてあらかじめ把握させておくことが望ましい。

⑤ 作業スケジュールについて、研修テストは本番移行への可否を判断する最終段階であり、バグ・不具合発生等により仮に期間延長となった場合は、本番リリースのマイルストーンに影響を与える可能性が高いことから、バグ･不具合対応も考慮し、十分なテスト期間を設けること。

⑥ ユーザーテストにおいてはプログラムの論理構造は気にせず、入力データと出力データの結果だけに着目すること。（ブラックボックステスト）

6.3.3 総合テスト実施

業務主管課及びシステム主管課において「総合テスト計画書」及び「総合テスト仕様書」の内容確認の後、構築事業者において総合テストを実施する。

また、業務主管課及びシステム主管課において「総合テスト計画書（ユーザーテスト）」及び「総合テスト仕様書（ユーザーテスト）」をもとに、業務主管課、システム主管課、システムの利用者において総合テスト（ユーザーテスト）を実施する。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	・総合テスト及びユーザーテスト実施状況確認 ・成果物確認及びコメント ・ユーザーテスト実施（業務に関すること） ・ユーザーテスト結果報告書作成（業務に関すること） ※複数課が関わるシステムの構築においては、当該システム構築課だけでなく関係課においても検証実施
システム主管課	・総合テスト実施依頼 ・総合テスト及びユーザーテスト実施状況確認 ・総合テスト結果報告書作成依頼 ・成果物確認及びコメント ・ユーザーテスト実施（システムに関すること） ・ユーザーテスト結果報告書作成（システムに関すること）
構築事業者	・総合テスト実施 ・総合テスト結果報告書作成及び修正 ・ユーザーテスト実施支援
運用事業者	・ユーザーテスト実施（運用に関すること）

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
総合テスト計画書	総合テスト結果報告書
総合テスト仕様書
総合テスト計画書（ユーザーテスト）	総合テスト結果報告書（ユーザーテスト）
総合テスト仕様書（ユーザーテスト）

(4) 手順と役割

① システム主管課は、構築事業者に対し「総合テスト計画書」及び「総合テスト仕様書」の内容に沿って総合テストの実施を依頼する。また、その際「Ⅱ.3 プロジェクト実施計

画の合意 ＜品質管理＞ エ 設計工程（基本設計）及びテスト工程における品質基準」の内容に沿って、テストケース数、検出バグ数の実績取得を依頼すること。

②業務主管課、システム主管課及び運用事業者は「総合テスト計画書（ユーザーテスト）」及び「総合テスト仕様書（ユーザーテスト）」の内容に沿ってユーザーテストを実施する。

③ 業務主管課及びシステム主管課は、総合テストおよびユーザーテストの実施状況を確認する。

実施状況の確認を行う際の参考として、基本的な確認の観点等を以下の表６－３－５総合テスト実施状況の確認観点に示す。

表６－３－５ 総合テスト実施状況の確認観点

確認観点

テスト実施者、確認者がテスト体制と合致していること

適正なテストツール、テスト環境を用いていること

網羅的なテストシナリオ及びテストケースを用いていること

適切なテストデータを用いていること

テストにかけている時間が適切であること

バグ・不具合が全て修正されていること

バグ・不具合要因の特定に当たっては、関係する事業者により調査が行われ、網羅的に要因が特

定されていること

④ 業務主管課及びシステム主管課は、構築事業者が総合テストを実施する際に、円滑に進められるように、関係各課及び関係事業者間との調整や課題に対する方針決定、質問に対する回答を迅速に行うこと。また、業務主管課、システム主管課及び運用事業者が実施するユーザーテストにて問題や課題が発生した場合は、課題箇所、指摘事項を明らかにしたうえで構築事業者と調整し、プログラム等の修正等の指示を行う。リリースに影響する課題や発生原因の分析等が必要な課題は課題管理の対象とし、進捗報告会等で共有したうえで、関係者での迅速な解決に努めること。

⑤ システム主管課は、構築事業者に対し、テスト結果について合否判定基準を満たしたエビデンス（根拠資料）を取得し、「総合テスト結果報告書」を作成することを依頼する。

⑥システム主管課は、「Ⅱ.3 プロジェクト実施計画の合意 ＜品質管理＞ エ 設計工程

（基本設計）及びテスト工程における品質基準」の内容をもとに、テストケース数、検出バグ数の実績が区の品質基準を満たしていることを確認すること。基準を満たしていない場合は構築事業者に説明を求めること。

⑦ 業務主管課及びシステム主管課は、ユーザーテスト結果について合否判定基準を満たしたエビデンス（根拠資料）を取得し、「総合テスト結果報告書（ユーザーテスト）」を作成する。「総合テスト結果報告書」及び「総合テスト結果報告書（ユーザーテスト」は

「総合テスト仕様書」及び「総合テスト仕様書（ユーザーテスト）」を更新したうえで作

成すること。

(5) 完了条件、チェック

①構築事業者において「総合テスト仕様書」の全てのテスト項目を消化し、テスト項目に対するテスト結果が「総合テスト結果報告書」にまとめられていること。

また、業務主管課、システム主管課、運用事業者において、「総合テスト仕様書（ユーザーテスト）」の全てのテスト項目を消化し、テスト項目に対するテスト結果が「総合テスト結果報告書（ユーザーテスト）」にまとめられていること。

(6) 留意点等

① 総合テストは本番移行への可否を判断する最終段階であることから、可能な限り本番に近い状態でのテストを行うことが重要である。また、ユーザーテストは、区が主体となって行うものであり、実際のシステム利用者がテストに参加することが必須である。 テスト担当者がシステムの操作等について十分習熟していない場合は、構築事業者に対しシステム操作方法の説明等の支援を受けたうえで、ユーザーテストを実施すること。

② ユーザーテストは、利用者が日々の業務を新システムで実施した場合に支障なく処理が可能なことを確認するテストであるため、実施の際は、原則以下について確認を密にし、機能上の支障がないことを確認すること。

・ 通常時のオペレーション

・ 異常時のオペレーション

・ 特殊時のオペレーション

・ システムが生成する値（計算値、判定結果等）の妥当性

また、ユーザーテストにて検出された不具合等の問題は全て、構築事業者への報告、構築事業者からの問題に対する解決策等の提示が行われ、納期までに修正されたことが確認されていなければならない。解決策等が明確に提示されていない問題が存在している間は、検査において合格とすることはできないものとする。

③ 総合テスト終了後に「運用設計書」及び「保守設計書」内容の見直しを実施する必要がある場合には、本工程内で対応を実施すること。

6.3.4 総合テスト結果の承認

業務主管課及びシステム主管課は構築事業者に対し、総合テストの実施結果の報告を求め、必要に応じ、課題等の指摘または調整を行うものとする。なお、業務主管課長及びシステム主管課長は、総合テスト結果について、設定した合否判定基準を全て満たしたと認められる場合に承認を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	・成果物内容確認及びコメント ・業務主管課長へ承認依頼 ・工程完了承認
システム主管課	・個別計画（総合テスト）工程完了報告書作成依頼 ・成果物内容確認及びコメント ・システム主管課長へ承認依頼 ・工程完了承認
構築事業者	・個別計画（総合テスト）工程完了報告書作成及び修正 ・個別計画（総合テスト）工程完了報告

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
総合テスト結果報告書	個別計画（総合テスト）工程完了報告書

(4) 手順と役割

① システム主管課は構築事業者に個別計画（総合テスト）工程における「工程完了報告書」の作成を依頼する。受領した「個別計画（総合テスト）工程完了報告書」に対し業務主管課及びシステム主管課は、以下表６－３－６ 個別計画（総合テスト）工程作業完了確認観点により、個別計画（総合テスト）工程の作業が完了していることを確認し結果を報告書へ記載する。

表６－３－６ 個別計画（総合テスト）工程作業完了確認観点

観点項目

総合テスト工程で実施すべきタスクが全て完了していること

総合テスト工程で作成された成果物のレビューが全て実施され、摘出された不具合の対策が全て完了し、合格基準を満たしていること

総合テスト工程で作成された成果物について、必要とされる承認が全て得られていること

プロジェクト計画書に定めたスケジュールどおりに進められていること

特定されたバグ・不具合要因に基づき、未然防止等に向けたxx的な対応が取られていること

未完のタスクや合格基準未達の成果物があった場合、次工程以降への影響が限定的で、次工程の開

始に影響がないか、また、リカバリプランが明確となっていること

② 業務主管課及びシステム主管課は「個別計画（総合テスト）工程完了報告書」について、システム主管課長に承認依頼を行う。

③ 業務主管課長及びシステム主管課長は「個別計画（総合テスト）工程完了報告書」をもとに個別計画（総合テスト）工程の承認を行う。また、内容に不備がある場合には、不備の内容を明示する。

④ システム主管課は、構築事業者に対し不備の内容を「レビュー管理表」で管理することを依頼する。その際、要件及び機能自体に不備があり仕様変更が必要となるものについては、構築事業者は区と協議し方針を決定したうえで対応する。

⑤ 業務主管課及びシステム主管課は、構築事業者の対応結果に対し、「レビュー管理表」をもとに確認を行う。

(5) 完了条件、チェック

①個別計画（総合テスト）工程の工程完了報告会議において、構築事業者からの報告が行われ、プロジェクトオーナー（システム主管課長 or 業務主管課長もしくは両者）の承認をもって工程完了としていること。

「業務計画書」案件の工程完了報告の場合には会議体である必要はない。個別計画（総合テスト）工程における完了時の確認観点を以下に示す。

表６－３－７ 個別計画（総合テスト）工程完了確認観点

No	項目	チェック内容
1	スケジュールの評価	当初に定めたスケジュールに対し予定通り完了しているか。当初のスケジュールを越えている場合には、後続の工程への影響とその対応策について構築事業者から報告を受けてい て、リリースに影響がないことを確認できているか。
2	残課題確認	残課題がないか。残課題がある場合には、課題の対応完了時期が明確であるか。明確でない場合、また、後続に影響があるクリティカルパスに関係する課題の場合にはリスクとして管理しているか。課題管理の際には「【様式 3】課題管理表」を用 いること。
3	リスク管理	リスクがある場合には、全体スケジュールから切り離し、別線 表でスケジュール管理が行われているか。リスク管理の際には「【様式 4】リスク管理表」を用いること。
4	成果物チェック	プロジェクト計画書に定められた工程成果物が当該工程において全て提出されていること。また、成果物の内容が事前に定

		められた品質指標に達していること。
5	品質の担保	区が定める品質基準を満たしているか。満たしていない場合に理由が明確かつ納得できるものであるか。

(6) 留意点等

①テスト結果の承認に当たっては、必要に応じて会議を開催する。また、承認状況を記録するとともに、必要に応じて承認理由や承認に当たっての前提条件等の記録を残すことで、後工程で疑義が生じたときの判断資料とする。

７ 本番稼働

＜概要＞

本番稼働に向けた移行計画を整備したうえで、移行リハーサルを実施し、その結果をもとに稼働判定を実施する。総合テスト及び総合テスト（ユーザーテスト）の結果から、リリースの妥当性を判断する。リリース当日の段取りや体制、障害時の対応、責任分界点等を事前に整理したうえでシステム移行を行う。

リリース後に評価を実施し、リリース結果が妥当であるか判断を行う。

＜目的＞

信頼性、安全性の確保された業務及び必要なサービスを区民に提供するために、移行リハーサル及び稼働判定を経て、システム移行を確実に達成する。

7.1 移行リハーサル準備

構築事業者により、システム移行に向けた移行リハーサルの事前準備を実施する。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・ 端末装置・周辺機器

白：対象 グレー：非対象

(2) 実施者

システム主管課	・移行計画書具体化依頼（スケジュール、体制図、作業手順書） ・システム移行全体スケジュールの明確化 ・関係各課、関係事業者、関係機関との調整
構築事業者	・移行計画書具体化

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
移行計画書	移行計画書
	体制図
	タイムスケジュール
	作業手順書
	正常性確認方法及び観点

(4) 手順と役割

① システム主管課は、構築事業者に対し、設計工程時に作成した「移行計画書」の内容を具体化することを依頼する。また、設計工程時から仕様の変更等が発生し、移行計画内容にも変更が必要な場合は、関係者との調整結果をふまえて内容を確定させ、これに基づく作業を構築事業者に対して求める。遅くとも、移行の各段階（データ移行段階、環境整備段階、本番移行段階）の開始前に、該当箇所の確定を行う必要がある。

「移行計画書」の内容確認を行う際の参考として、基本的な確認観点や方法、留意事項等を次に示す。

表７－１－１ 移行計画書確認観点

	確認観点
移行データ調査	現行システムのファイル、ファイルレイアウト、データレイアウト、使用しているコード体系、外字の利用等を調査していること
	現行システムの不備データを調査していること
	移行対象となるデータを確定できる手順になっていること
	移行データ調査に係るリスクが網羅的に挙げられ、対応策等が整理されていること
移行データ整備	現行システムの移行対象データが新システムのデータとして過不足なく変換される方法になっていること
	不備データを修正する方法が明確であること
	新システムで追加されるデータ項目に正しい値が設定される方法になっていること
	移行前データの確認、データ変換前後の整合性チェック、移行データのシステムとの親和性のチェック、基本的な整合性検査（件数チェック、合計値チェッ ク）等、移行データの正確性を保証する方法になっていること
	移行データ整備に用いるツールは十分な機能を有していること
	移行データに対する機密保護対策が十分であること
	移行データ整備に係るリスクが網羅的に挙げられ、対応策等が整理されている

	こと
本番環境構築	本番環境として用意する情報システム資源が明確であること
	本番環境構築手順（既存機器の撤去、新規機器の搬入・設置、移行判定、データ移行、システム移行等）が明確であること
	新規機器の搬入・設置に係る各作業（ＯＳインストール、アプリケーションプ ログラムインストール、ネットワーク・サーバ等各種設定、周辺機器等各種設定、疎通テスト等）に過不足がないこと
	本番環境構築の各手順に係る作業量、期間の見積りが妥当であること
	本番環境構築に係る主管課、機器設置事業者、構築事業者の体制と役割が明確 であること
	本番環境構築に係るリスクが網羅的に挙げられ、対応策等が整理されていること
移行リハーサル	移行リハーサルにかかる作業量・移行所要時間の見積りが明確であること
	移行リハーサルに用いるデータが明確であること
	移行リハーサルにおいて主管課の関与・役割が明確であること
	本番環境とリハーサル環境の差異を把握していること。差異がある場合の影響を把握し、必要な対策がとられていること
	移行リハーサルにより明らかになる課題・問題等が対処、管理され、移行リス クを低減する方法になっていること
	移行データリハーサルに係るリスクが網羅的に挙げられ、対応策等が整理されていること
	本番とリハーサルの作業時間の差異が把握されていること。また、差異がある 場合の影響が把握されており必要な対策がとられていること
	リハーサル実施手順と時間の妥当性が確認できていること
	作業と作業の依存関係を確認できるリハーサル実施手順になっていること
	チェックポイントが定められていること。また、チェック内容（条件）とチェックにおいて合格基準に満たない場合の対応、区への連絡先、及び連絡手段など が定められていること
	リカバリポイントの作成及びリターン出来ない場合の対応内容及びシステム状態を関係者間で合意すること
移行判定	移行判定項目は網羅性、完全性、正確性が確保されていること
	移行判定基準は客観性を有し、曖昧さが排除された妥当性の高いものであること
	移行判定基準を満たさない場合の再実施手順が明確であること
	移行判定に係るリスクが網羅的に挙げられ、対応策等が整理されていること

本番切替え	移行により業務遂行に際して障害が発生しないこと
	本番切替え実施手順（移行判定、本番切替え、本番切替え判定、切戻し等）が明確であること
	本番切替え不成功時の切戻し条件が明確であること
	本番切替え不成功時の切戻し方法が明確であること
	本番切替えに係るリスクが網羅的に挙げられ、対応策等が整理されていること

② システム主管課は、システム移行に係わる連携システムを含む、全体のタイムスケジュールを明確化し、関係各課、関係事業者、関係機関等に配布すること。タイムスケジュールに認識の齟齬がある場合は調整し確定させる。

③ システム主管課は移行リハーサル時の「体制図」及び「作業手順書」の作成を構築事業者に依頼する。その際、区の体制や必要な作業については事前に構築事業者と調整を行うこと。

(5) 完了条件、チェック

①構築事業者において移行リハーサル準備が完了し、移行リハーサルが実施できる状態となっていること。

(6) 留意点等

①移行リハーサルは本番移行を行う手順や体制等を確認する最終段階であることから、可能な限り本番に近い状態でのリハーサルを行うことが重要である。

7.2 移行リハーサル実施

構築事業者においてシステム移行に向けた移行リハーサルを実施する。

業務主管課及びシステム主管課は、構築事業者が移行リハーサル実施にあたり、他システムとの連携が求められる場合には、関係各課及び関係事業者との調整を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	・移行リハーサル実施支援
システム主管課	・移行リハーサル実施依頼 ・移行リハーサル実施支援

	・移行リハーサル結果報告書作成依頼 ・成果物内容確認及びコメント
構築事業者	・移行リハーサル実施 ・移行リハーサル結果報告書作成及び修正

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
移行計画書	移行リハーサル結果報告書
体制図
タイムスケジュール
作業手順書
正常性確認方法及び観点

(4) 手順と役割

① システム主管課は、構築事業者に対し、定めたタイムスケジュールと各作業手順書に沿った移行リハーサルの実施を依頼する。

② 業務主管課及びシステム主管課は、構築事業者が移行リハーサルを実施する際に円滑に進められるよう、関係各課、関係事業者、及び関係機関との調整や課題に対する方針決定、質問に対する回答を迅速に行う。

③ システム主管課は、構築事業者に対し、移行リハーサル結果について合否判定基準を満たしたエビデンス（根拠資料）を取得し、「移行リハーサル結果報告書」の作成を依頼する。

(5) 完了条件、チェック

①構築事業者において移行リハーサルを全て消化し、その内容が「移行リハーサル結果報告書」にまとめられていること。

(6) 留意点等

①移行リハーサルは本番移行を行う手順や体制等を確認する最終段階であることから、可能な限り本番に近い状態でのリハーサルを行うことが重要である。

7.3 稼働判定

稼働判定は本番稼働の可否を判断する最終段階であることから、稼働判定基準から妥当性を検証し、それに基づき判定することが重要である。安定稼働を確実に行うために必要な作業であるため、システム主管課長において、「移行計画書」「課題管理表」「総合テスト実施結果」

「総合テスト（ユーザーテスト）結果」「移行リハーサル結果」等の報告全てを網羅的に確認したうえで稼働判定を行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	・テスト全体の結果報告（業務主管課の立場から）
システム主管課	・テスト全体の結果報告（システム主管課の立場から） ・稼働判定（プロジェクトオーナー）
構築事業者	・テスト全体の結果報告（構築事業者の立場から）

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
総合テスト結果報告書	稼働判定結果
総合テスト結果報告書（ユーザーテスト）
移行リハーサル結果報告書

(4) 手順と役割

① システム主管課及び構築事業者は、「総合テスト結果報告書」「総合テスト結果報告書（ユーザーテスト）」「移行リハーサル結果報告書」をもとにそれぞれの立場よりプロジェクトオーナーであるシステム主管課長に承認を求める。

稼働判定においては、事業者の立場からの判定考察と、区（発注者）の立場での判定考察が必要となる。

② システム主管課長は、以下表７－３－１ 稼働判定基準をもとに妥当性を検証し、それに基づき判定する。稼働判定工程完了の確認は、以下表７－３－２ 稼働判定工程作業完了確認観点をもとに確認を行う。

表７－３－１ 稼働判定基準

観点項目

新システムの稼働に必要なシステム開発・機器の設置が完了していること

新システムの稼働に必要なシステムや機器のテストが実施され、品質基準を満たしていること

新システムに移行するための準備やリハーサルが全て完了していること

新システムを運用するために必要な業務手順書等の準備が完了し、必要な教育がされていること

新システムを運用・保守をするための体制が準備されていること

新システムへの移行・本番稼働に際し、不測の事態が発生した場合の対応計画（コンティジェンシープラン）が明確であること

表７－３－２ 稼働判定工程作業完了確認観点

観点項目

稼働判定工程で実施すべきタスクが全て完了していること

稼働判定工程で作成された成果物のレビューが全て実施され、検出された不具合の対策が全て完了し、

合格基準を満たしていること

稼働判定工程で作成された成果物について、必要とされる承認が全て得られていること

プロジェクト計画書に定めたスケジュールどおりに進められていること

未完のタスクや合格基準未達の成果物があった場合、稼働後においてサービスに影響がないこと、あるいは局所的であること、また、その際のリカバリプランが明確となっていること

(1) 完了条件、チェックポイント

①稼働判定会議において、プロジェクトオーナー（システム主管課長 or 業務主管課長もしくは両者）によるシステム移行（リリース実施）が妥当であると判断されていること。

また、結果が構築事業者に通知されていること。

「業務計画書」案件の稼働判定の場合には会議体である必要はない。稼働判定工程における完了時の確認観点を以下に示す。

表７－３－３稼働判定工程完了確認観点

No	項目	チェック内容
1	スケジュールの評価	当初に定めたスケジュールに対し予定通り完了しているか。当初のスケジュールを越えている場合には、後続の工程への影響とその対応策について構築事業者から報告を受けてい て、リリースに影響がないことを確認できているか。
2	残課題確認	残課題がないか。残課題がある場合には、課題の対応完了時期が明確であるか。明確でない場合、また、後続に影響があるクリティカルパスに関係する課題の場合にはリスクとして管理しているか。課題管理の際には「【様式 3】課題管理表」を用 いること。
3	リスク管理	リスクがある場合には、全体スケジュールから切り離し、別線表でスケジュール管理が行われているか。リスク管理の際に は「【様式 4】リスク管理表」を用いること。
4	成果物チェック	プロジェクト計画書に定められた工程成果物が当該工程において全て提出されていること。また、成果物の内容が事前に定

められた品質の合格基準に達していること。

7.4 システム移行 （リリース実施）

稼働判定の結果、システム移行（リリース実施）が可と判断されたシステムのシステム移行を実施する。システム移行はタイムスケジュール及び「作業手順書」に沿って行う。

(1) 対象案件

新規システム開発
システム改修 リプレイス・ソフトウェア 更新
機器更改
ＡＳＰ （小規模） サーバ機器・端末装置・ 周辺機器

白：対象 グレー：非対象

(2) 実施者

業務主管課	・システム移行状況確認 ・成果物内容確認及びコメント
システム主管課	・移行結果報告書作成依頼 ・システム移行状況確認 ・成果物内容確認及びコメント
構築事業者	・システム移行実施 ・移行結果報告書作成及び修正 ・移行結果報告

(3) 入力情報及び成果物

成果物作成の根拠資料	成果物
移行計画書	移行結果報告書
体制図
タイムスケジュール
作業手順書
正常性確認方法及び観点

(4) 手順と役割

① システム主管課は、構築事業者に対し「移行計画書」に沿ってシステム移行作業を実施することを依頼する。また、各確認ポイントでの確認結果のエビデンス（根拠資料）を取得のうえ「移行結果報告書」にまとめて報告することを依頼する。

②業務主管課及びシステム主管課は、構築事業者の作業が「移行計画書」に沿って行われているかを確認する。

(5) 完了条件、チェックポイント

①システム主管課がシステム移行作業について構築事業者から完了報告を受けていること。また、予定作業が全て完了していること。

No	項目	チェック内容
1	移行計画の評価	移行計画通りに完了しているか。 移行計画に変更があった場合に、その理由に妥当性があるものであるか。
2	タイムスケジュールの評価	当初に定めたタイムスケジュールに対し予定通り完了してい るか。当初作成したタイムスケジュールを越えていた場合に、サービスに影響がないことを確認できているか。
3	作業手順の評価	当初に定めたシステム移行作業を全て完了しているか。 残作業がある場合にその理由に妥当性があるものであるか。
4	正常性確認方法及び観点の評価	システム移行時のチェックポイントにおけるチェック内容と合格基準が満たされているか
5	システム移行における問題	システム移行作業において発生した問題が解消されているか。問題が残っている場合には、サービスに影響がないことが確認できているか。また、問題に対する対応完了時期が明確で あるか。

システム移行作業における完了時の確認観点を以下に示す。 表７－４－１ システム移行作業完了確認観点

(6) 留意点等

①障害発生時の対処方法及び役割分担について、事前に関係者間で取り決めておくこと。

８ 引継ぎ

＜概要＞

システム主管課は、構築事業者に対し、運用事業者及び保守事業者に対する引継書を用いた引継ぎを行うとともに、設計・開発に係る各種資料、情報の共有を行うことを求める。システム主管課は引継期間内に運用事業者及び保守事業者に対する適切な引継ぎがなされたか、各事業者の習熟度を確認し、円滑かつ効率的に当該情報システムを運用するための準備を行う。

＜目的＞

システム主管課は、構築事業者に対し、運用事業者及び保守事業者に設計・開発の設計書、作業経緯、残存課題等を確実に引継ぐよう求め、情報システムの整備後の事業者変更のリスクを最小限に抑えつつ、円滑かつ効率的に当該情報システムを運用する。