Step.3 プロジェクト計画書等の作成

プロジェクトの目標とする成果や体制等を決めた後は、今後のプロジェクトの実施方法を検討し、プロジェクト計画書、プロジェクト管理要領として明文化します。プロジェクト計画書はプロジェクトで「実施する内容とその目的・目標」を記すのに対して、プロジェクト管理要領はその「実施に係るルール」を定義するものです。

プロジェクト計画書は、プロジェクトのライフサイクルを通じて達成すべき成果を明確にし、各工程における意思決定や関係者との合意における指針として参照することにより、プロジェクト本来の目的に対して最大の成果を発揮することを目指す上で欠かせないものです。

情報システムのプロジェクトは長期にわたり、また多くの組織や担当者が関わるため、実施するプロジェクトの目的や内容に関して明文化されたプロジェクト計画書を拠り所にすることで、主要なステークホルダー間で共通理解を形成することが必要です。また、どのようなプロジェクトであっても、途中段階で要件変更等を余儀なくされることがありますが、そうした場合でもプロジェクト計画書に明記された本来の目的を見失わず、目標を達成できているかモニタリングと改善を繰り返すことにより、政策目的実現のために最大限の成果を発揮することが可能になります。このように、プロジェクトのライフサイクルを通してプロジェクト計画書を中心に据えた考え方に基づいてプロジェクト運営を推進することにより、手戻りを減らし、さまざまな制約がある中でも目的に対して最大の成果を発揮することを目指します。

プロジェクトには外部関係者（利用者、関連する公的機関や民間企業等）、内部関係者（システムの利用者となる職員、関連する各部門）、内部の推進体制（各省PMOやデジタル庁等）、プロジェクトに関連する各種事業者等、様々なステークホルダーが存在します（第2章プロジェクトの管理　Step.２　プロジェクトの立上げ、初動　５　機能する体制を作る　Ｃ．他組織と連携できる体制を作る　を参照）。これらの多種多様な関係者、そしてＰＪＭＯ内部の職員も含めて様々な局面で合意形成を図る際に、プロジェクトの目標や推進状況を的確に説明するための中心となるのがプロジェクト計画書です。プロジェクト計画書の記載の中から、個々の関係者が知りたい内容を抜粋して伝えることができるように、原典となる方針や進め方をプロジェクト計画書に一元的に集約することで、プロジェクトの姿を矛盾なく効率的に説明できるようになります。

プロジェクト計画書及びプロジェクト管理要領の２つのドキュメントについて、記載項目やポイントとなる点を見ていきましょう。

プロジェクト計画書を作成する

【標準ガイドライン関連箇所：第３編第２章第２節1)】

プロジェクト計画書を中心に据えたプロジェクト運営を推進するためには、プロジェクト計画書を適切に作成・更新していく必要があります。

この実践ガイドブックには、別添としてプロジェクト計画書のひな形を示しています。

• 様式例2-1

プロジェクト計画書のひな形

このひな形はあくまで例示ですので、プロジェクト内容に応じて記載内容を個別に追加、変更して構いません。

以降では、プロジェクト計画書を作成するときに、特に注意が必要なポイントについて説明していきます。

プロジェクト計画書は段階的に詳細化する

プロジェクト計画書は定義する内容が多く、作るのが大変そうだという印象があるかもしれません。たしかに、プロジェクトは、長期間にわたって多数の活動を行うため、全ての活動を隅から隅まで定義するのは大変労力がかかります。

でも、安心してください。プロジェクト計画書は、最初から全ての計画の詳細を記載するものではなく、段階を踏んで徐々に詳細化していくものだからです。初期の段階のプロジェクト計画書は、各項目についての概要を記載した上で、各項目の詳細化を行うタイミングを計画します。各項目の詳細化を行う際には、プロジェクトの開始時にテーラリングした内容の見直しも合わせて行いましょう。テーラリングの考え方は、標準ガイドライン解説書「第1章3．（3）プロジェクトへの適用に当たり、ＰＪＭＯは、本ガイドラインが示すＩＴマネジメントの内容をテーラリングすることが重要である」を参照して下さい。

• 図2-4

プロジェクト計画書の段階的な詳細化のイメージ

なお、プロジェクト計画書を詳細化していくと記載量が増加していきますので、１つのドキュメントとして維持していくと、少し読みにくくなってしまいます。

そこで、詳細化を行う中では、別紙構成としたり、サブプロジェクト計画書を切り出したりといった形で、プロジェクト計画書の本体に追加していくことを推奨します。プロジェクト計画書の本体には、追加した記載内容の要点と別紙への参照を記載していきます。こうすることで、プロジェクト計画書は詳細化が進むにしたがってプロジェクト全体の概要を示す目次のようになっていきます。

• 図2-5

詳細化されたプロジェクト計画書のイメージ

ただし、詳細化の結果として、計画全体に係る変更がある場合は、変更管理の手順に従った上で、その内容を各項目に反映していく必要があることを忘れないでください。

また、プロジェクトの実務作業が忙しくなっていくと、プロジェクト計画書の更新がなおざりになってしまうこともあります。しかし、プロジェクト計画書が更新されていないと、人事異動等で新しい担当者が着任した際に現在の状況や正確な内容がわからず、その後のプロジェクト活動に影響を与えてしまいます。

プロジェクト計画書は詳細化や変更発生の都度更新していくことが望ましいですが、四半期や半期等の周期でも、プロジェクトの最新の状況が確実に反映されているかを確認するようにルール化しておくことも効果的です。

• 参考2-4

  補正予算で開始するプロジェクト

抜け漏れのない実施計画を作成する

プロジェクトの立ち上げ当初は、実施計画（スケジュール）についても概略で構いません。プロジェクトで実現する事項も大きなカテゴリ単位となりますし、時間軸についても月単位や四半期単位等、概略での作業時期をプロットする形で構いません。実施計画も、段階的に詳細化していくものです。

実施計画の例を図2-6に示します。

• 図2-6

実施計画から漏れやすい作業に注意

実施計画を作成する際には、ＰＪＭＯが責任範囲を持つ部分のみで計画を立てがちですが、影響を受ける側（業務担当職員、連携先システム、移行元の既存システム等）も含めた全体的な計画が必要です。

実施計画から抜けやすい作業項目を次に示します。実施計画を段階的に詳細化する際に、このような作業が漏れていないか確認してみてください。

計画から抜けがちな作業項目

• 関係者との要件や仕様の調整、確定作業 システム連携等で影響を与える関係者に対して、要件定義内容や設計仕様を調整し、確定した要件、仕様として双方での合意を形成する作業 （マイルストーンとして、いつまでに「確定」するかを関係者で事前合意することが重要）

• 注記

クレンジングとは、データベースのデータやファイル等に存在している、不要なデータの削除や、不整合なデータを整合性が合うように修正する作業のこと。

データ移行関連作業 既存情報システムからのデータ移行、既存データの整備（クレンジング）作業、紙にしか存在しないデータのパンチ入力作業

• 注記

パンチ入力とは、データを情報システムに人の手で入力する作業のこと。（以前はコンピュータにデータを登録するためには、専用のカード（紙）に孔をあけて（パンチ）読み込ませていたことに由来する。）

テスト関連作業 現行システムと新システムで処理結果を比較する実データテスト、連携先情報システムとのデータ連携テスト、システムの性能を確認するためのストレステスト等（総合テスト、受入テストの中で、このようなテストが確実に含まれているかどうか）

• *移行リハーサル* 業務実施部門による業務移行リハーサル、情報システム部門によるシステム移行リハーサル（社会的な影響が多いシステムでは、数度のリハーサルを経た上で本番切替えを行うことが多い）

• 教育、研修、利用者サポート 利用者（国民等）への利用マニュアルの作成、職員向けマニュアルの作成（業務面、システム操作面）、職員向けの研修実施 （業務面、システム操作面）、ヘルプデスクの準備・運営

• 利用者への連絡やプロモーション 新サービス開始についての利用者・関係者への事前連絡、自府省Webサイトや広報媒体を活用したプロモーション

• 業務を実施する環境の変更 業務フロー変更に伴う窓口の配置変更や移転に伴う工事の調整

• 運用段階での利用状況分析、効果測定 アクセスログや処理件数等から利用状況を把握し、業務・システムの改善を図る。また、プロジェクトが目標としていた成果に対して、実績としての効果を測定する。 （効果を測定するための分析機能を、システム開発範囲に盛り込んでおくことが重要）

プロジェクト管理要領を作成する

【標準ガイドライン関連箇所：第３編第２章第２節２)】

このステップの冒頭でも説明しましたが、プロジェクト計画書はプロジェクトで「実施する内容とその目的・目標」を記すのに対して、プロジェクト管理要領はその「実施に係るルール」を定義するものです。

この実践ガイドブックには、プロジェクト管理要領についても別添としてひな形を示しています。あくまでこのひな形は例示ですので、プロジェクト内容に応じて記載内容を個別に追加、変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。

• 様式例2-2

プロジェクト管理要領のひな形

以降では、プロジェクト管理要領を作成するときに、特に注意が必要なポイントについて説明していきます。

問題に対処できる会議体を構成する

会議体の構成は、プロジェクトの工程によって変わっていきますが、基本的には次のような定例的な会議を主軸としながら進めていきます。

実際の会議体では、複数の会議機能を１つの会議で集約することも多いですが、会議の機能として次のようなものが漏れていないか確認してみてください。

会議体の構成例

• 仕様検討会議 （要件定義、設計） 現場で業務を実施している職員等の意見を反映しながら、業務の改善ポイントやシステムに求める機能などを詳細に決める会議です。業務の種類やサブシステム単位で複数の会議を設定することもよくあります。名称については、検討ＷＧ（ワーキンググループ）、作業部会、分科会等の名称になることもあります。 重要なことは、これらの会議において業務実施部門の職員自らが仕様を決定することです。業務を実際に担当している職員の現場感覚がなければ、業務に役立つ良い情報システムは作れません。

• 事例2-8

業務実施部門が参加しなかったプロジェクト

• 連携調整会議 （要件定義、設計） システム連携等で他システムとの調整が必要な場合に、システムの連携仕様やテスト実施方法等を詳細に決める会議です。 システム連携の調整は、連携仕様そのものを決めるだけではありません。連携データの量（ピーク時の最大処理件数等）、連携データの種類（最新歴だけか、過去歴も含むか等）、連携エラー時の処理（代替処理、エラーメッセージの出し方等）、連携テストの実施時期、運用時の対応体制等、様々な調整事項を決める必要があります。また、一度決定した連携仕様を変更すると関係者への影響が大きいため、連携仕様の決定は慎重に行う必要があります。これらの点を考慮して、仕様調整会議では十分な調整期間と体制を確保することが望まれます。

• テスト調整会議、テスト確認会議 （テスト） テスト工程では、テスト計画書の内容を確認した上で、各種テストを実施し、テスト結果に応じて対応を行います。また、総合テストまでの工程では、開発事業者が主体としてテストを実施しＰＪＭＯはテストの実施状況を確認しますが、受入テストでは業務実施部門を含めたＰＪＭＯの職員自身がテスト計画を作成してテストを実施します。 特に複数のプロジェクトにまたがるテストを実施する場合は、テスト内容、テスト実施時期、テスト実施環境、テスト体制等の調整を慎重に行う必要があるため、やはり十分な調整期間と体制を確保することが望まれます。

• 進捗報告会議、定例報告会議 （全工程） システム関連事業者の作業報告を含めて、プロジェクト全体の状況を確認する会議です。システムの開発工程では「進捗報告会議」、システムの運用工程では、「システム運用定例報告会議」、「アプリケーション保守定例報告会議」等の形で開催することが多いです。 システム関連事業者ごとに月１回程度の進捗報告を求めることが基本的な形ですが、多数の事業者が関係するプロジェクトでは、事業者単体での進捗報告会議に加えて事業者全体での「全体進捗定例会議」を開催することで、事業者間の情報共有を図ることもあります。

• 課題調整会議 （全工程） 課題管理表をベースとして、課題の発生状況と対応状況を確認し、対応が停滞している課題に対してはシステム開発事業者の作業進捗状況を確認する会議です。

• 変更管理会議 （全工程） 確定した仕様に対する変更要求、実装済の機能に対する変更要求、システムの運用手順に対する変更要求等に対して、変更の可否を決定する会議です。 変更が発生した際に必要となる会議であるため、定例的な会議として運営するというよりは、臨時的な会議として開催することが基本的です。また、他の会議体（仕様調整会議、連携調整会議、テスト調整会議、課題調整会議等）で、この会議の機能を包括することもあります。

• ＰＪＭＯ情報共有会議 （全工程） ＰＪＭＯの全職員を集めた全体定例会議、ＰＪＭＯの中でリーダーとなる職員を集めたリーダー会議等、ＰＪＭＯ内での情報共有を行う会議です。 プロジェクトの中では、特定の人しか状況を知らないという「情報の局所化」が発生しやすいので、月次、週次等で定例的に会議を開催することが有効です。

なお、プロジェクトで発生する問題の全てを、ＰＪＭＯの体制下で解決できるわけではありません。問題の大きさに応じて、自府省の幹部職員に状況を伝達し、幹部レベルでの問題対応を図ることが必要になります。また、問題が発生した時だけ幹部に相談する形では情報共有が不十分になりがちなので、常日頃からプロジェクトの計画内容、進捗状況、重要課題を関係する幹部職員が把握できるように進めていく必要があります。

プロジェクトの影響度や重要性に応じて、幹部職員への連絡会議を設定するなど、幹部から定期的な関与が得られるように調整を行うと良いでしょう。

• 事例2-9

幹部職員への定期的な報告

本質的なリスクを事前に予見して、対応を準備する

リスク管理については、リスク管理表等のドキュメントは一通り作成しているものの、実際のプロジェクトの中で役立てているケースはまだ少ないようです。

しかし、実際にはプロジェクトを進める中で様々な問題が顕在化しています。問題が起こってしまってから対処方針を考えても、予算面や既存の契約条件面等から制約が大きく、抜本的な対応を行うことが困難になります。

やはり、それらの問題が発生しないうちに**事前にリスクとして認識し、必要な対応を準備しておくことが重要**となります。

プロジェクトを進める中で発生しやすいリスクとその対応方法について、例を示します。わかりやすさのために、大きく「品質」、「コスト」、「納期」の観点で分類していますが、必ずしもこの分類で考える必要はありません。プロジェクトの特性、実状に応じて、本質的に対応が必要となるリスクを、事前に考えてみてください。

品質に関するリスクと対応方法の例

• 多数の事業者間をまたいだシステム障害が発生するリスク 多数の事業者が参画する体制（マルチベンダー体制）においてシステム障害が発生した際に、各事業者が自身の責任範囲ではないことを主張し、問題を主体的に解決する主体が存在しないことによって、原因究明や対応実施が長期化するというリスク。

→リスクを軽減するためには、プロジェクト全体を統括する品質管理チームをＰＪＭＯ職員と特定事業者によって構成する等の対応が考えられる。プロジェクト内でシステム障害等の問題が発生した際には、この品質管理チームが問題解決を統括し、複数事業者をまたがる問題についても問題の切り分けと問題対応者（事業者）の決定を行う。また、各事業者が品質管理チームの指示に従って必要な対応を行うことをプロジェクトのルールとしても明示する。

• 個人情報等の重要情報が漏えいするリスク 個人情報等の重要情報について、本来は参照権限がない利用者が参照してしまったり、外部へ流出してしまったりといった漏えいが発生するリスク。

→本番稼働前の段階においてリスクを軽減するためには、情報セキュリティの専門経験を持つ要員によるセキュリティ設計を行い要件定義で定めた情報セキュリティ対策要件の充足性を確認するとともに、実作業の中でも本番データを扱うテストにおいて氏名等の重要情報をマスキング（匿名化）した形で実施するなど、万一の情報流出時にも影響範囲を限定化する対応を行う。

→本番稼働後の段階においてリスクを軽減するためには、運用計画や運用実施要領等の中で重要情報を扱う際の手順を明確に示した上で、実際の実施状況について定期的に確認することや、セキュリティ監査の実施計画を立てて監査の実施とフォローアップを行う等の対応を行う。

• 現行システムのトラブルを次期システムにも引き継ぐリスク 稼働中の現行システムで起きたトラブルが関係者に共有されず、次期システムにおいても同様のトラブルが発生するリスク

→現行システムの開発・運用時に発生したトラブル（例：システム連携元からの誤データ受信、特定拠点におけるネットワーク通信帯域の不足等）の内容を再整理し、類似するトラブルが次期システムでも発生するおそれがある場合は、まず現行システムにて妥当な対策（原因分析、暫定対応、恒久対応等）がリスクの判断基準や影響度に応じて検討され、実行されているか確認する。 妥当な対策が検討されている場合は、当該事項を次期システムの開発管理プロセス等に組み込む。対策が十分でない場合は、次期システムにおいて対策を改めて検討した上で、その内容を開発の管理プロセス等に組み込む。

コストに関するリスクと対応方法の例

• システムの機能追加に関する要望が多発するリスク 開発段階や運用段階において、業務実施部門の職員等からシステム機能に対する改善要望が多発する一方で、予算範囲内では対応できる範囲が限定されるため、業務実施部門とシステム機能に対する合意が形成できなくなるというリスク。

→サービス・業務企画段階でのリスクを軽減するためには、業務の中核を担うベテラン職員等を巻き込み、当該職員の豊富な現場経験を活かしながら、全体のバランスを考慮して検討を進めることで、業務実施部門との円滑な合意形成を行えるようにする。

→開発段階に入る前（調達を行うまで）の段階でリスクを軽減するためには、要件定義内容を詳細に業務実施部門に提示し、システム導入後の業務実施方法を具体的にイメージできる状況の中で、必要となる機能のフィードバックを受ける等の対応を行う。また、特定のユーザに固有の少数要望についてはシステム本体ではなく簡易な外部ツール等で対応できるようにして、そのための予算化も事前に行うことも考えられる。

→開発段階でリスクを軽減するためには、要件定義や基本設計段階においてプロトタイプを作成して業務実施部門の職員がシステムの動きを詳細に理解できるようにする等の対応を行う。また、一方で各職員の個別要望だけでシステム機能が増え過ぎないように、システムのコストや保守性等も勘案した上で機能要件を増やすことの判断を業務実施部門が組織的に行うルールを導入することも考えられる。

→運用段階でリスクを軽減するためには、毎年の予算要求に間に合うように改修要望のとりまとめ方法をルール化するとともに、改修対象の選定基準や選定結果について関係者全体へ説明することで、バランスのとれた合意形成が行えるようにする。

• 本番稼働後に想定以上の利用があり、対応能力が不足するリスク システムへのアクセス数が想定以上に増加し、システムのレスポンス遅延やアクセス不能状態が発生するため、ハードウェア等への追加投資が必要になるというリスク。又は、本番稼働後にシステムの操作方法や不具合に対する問合せが頻発し、ヘルプデスクの対応能力を超えてしまったため、ヘルプデスク体制の増強等に追加投資が必要になるというリスク。

→アクセス増加へのリスクを軽減するためには、本番稼働を段階的にすることで実際の利用規模を見定めながら必要な投資を行う、ピークを分散するように業務スケジュールを見直す、クラウドサービスを利用することで突発的なアクセス増加に対しても対応能力を高める等の対応を行う。

→問合せ増加へのリスクを軽減するためには、よくある質問（ＦＡＱ）をWebサイト等で公開することで問合せ件数を抑制する、ヘルプデスクに寄せらせる問合せを分析し、業務面やシステム面での必要な改善を細かなサイクルで回す等の対応を行う。

• クラウドサービスの契約内容の変更等に伴い想定外のコストが発生するリスク クラウドサービスの料金体系やサービス内容の変更等により、想定外のコストが発生するリスク。例えば、IaaSを利用して情報システムを構築する際に、途中で値上げがあった場合は、それに応じざるを得ず、またサービス内容の変更があった場合は、それに伴う情報システムの構成に関する検討等の追加作業が発生し、情報システムの構築にかかるコストが増加する。また、利用していたサービスの一部が終了する場合もあり、他のサービスへの切替え等に伴う作業が発生する。

• 注記

クラウドサービスの契約方法により、リスクが顕在化するタイミングが異なる。クラウドサービス提供者との単価契約の場合は、発注者が月次で支払うクラウドサービス利用料に影響が出る。

一方、総価契約の場合、契約期間内はクラウドサービス利用料の変動に関わらず、発注者が支払うクラウドサービス利用料に影響しない。クラウドサービス利用料に影響が出るのは後続の契約となる。

発注者は総価契約においても、クラウドサービスの利用にかかっている実績コストを把握して、翌年度以降の予算等の検討に活用することが重要である。

総価契約／単価契約の違いについては、「事例：第二期政府共通プラットフォームにおけるクラウドサービスの調達」を参照すること。

→値上げによるリスクへの対策として、利用するクラウドサービスのうち変更可能なサービスや縮退可能なリソースをあらかじめ特定しておき、継続的にクラウドサービスに係る実績コストのモニタリングを行い、リスクが顕在化した際は、サービスレベル変更やリソース停止により縮退運転を行う。

→サービス内容の変更や終了によるリスクを軽減するために、情報システムを整備する際に、情報システムを構成する要素を特定のベンダーの技術や製品に依存しない、オープンな技術仕様に基づくものとし、将来的に他の製品やサービスへの乗り換えが可能な構成とする。

• クラウド利用における為替変動リスク 為替レートが円安に振れることで、クラウドサービスの利用料が想定以上に高額となるリスク。クラウドサービスの中には、ドルベースで料金設定を行っているものがあるため、予算の算出時に想定していた為替レートよりも円安に振れると、その分だけ利用料が増加する場合がある。

→為替レートが円安に振れるリスクを軽減するために、利用するクラウドサービスのうち削減できるリソースをあらかじめ特定しておき、リスクが顕在化した際は、当該リソースを停止して縮退運転を行う。

→リスクを軽減するために、為替レートが予算要求時点よりも円安に振れることを一定程度見込んだ額で予算要求を行う。

納期に関するリスクと対応方法の例

• 必要資源の配備が遅延するリスク ハードウェアの配備、ネットワークの開通、データセンターの供用開始、ＩＣカード等の必要備品の準備等、資源の配備が計画時期に間に合わないというリスク。

→リスクを軽減するためには、計画上のバッファ（余裕）確保、代替計画の準備（ネットワークが開通しない場合に、ネットワークを利用しないテスト工程等を先行開始する）、段階的配備（テストに必要な数枚のＩＣカードだけ先に供給を受ける）等の対応を行う。

• 関係する他機関からの情報提供が遅延するリスク 制度変更が予定されている場合における変更の詳細内容、システム連携を行うための連携仕様書やテスト計画書等、他機関から提供される情報が期日に間に合わず遅延するというリスク。

→リスクを軽減するためには、計画の部分変更（変更影響を受ける部分の機能開発を後送りにする）、段階的開発（仮決めの仕様を基に開発を行い、仕様確定後に差分部分を再開発する）等の対応を行う。

• 連携する他情報システムの設計・開発が遅延するリスク 他情報システム連携を行う場合において、連携する他システムの設計・開発の進捗が遅延することにより、担当している情報システムにも影響が発生するリスク。

→リスクを軽減するためには、事前に、当該リスクが発生した場合の影響範囲の確認を行う。また、他情報システムの窓口となる担当者と定期的な会議体（連携調整会議等）を設定し、互いの進捗状況、品質、課題、リスク等を共有するといった対応を行う。 なお、その他のリスク回避策や積極的なリスクの受容等についても検討する。

また、リスクの内容によっては、回避、軽減することが難しく、リスクとして受容せざるを得ないものもあります。そのような場合においても、当該リスクを回避不能なリスク（受容するリスク）としてリスク管理表に記載し関係者の合意を形成しておくことで、実際にリスクが顕在化した場合でも、比較的円滑に対応を行うことができます。例えば、クラウドサービスで障害が発生した場合、クラウドサービス提供事業者から個々の障害の原因や再発防止策は詳細に開示されない場合があります。このため、ＰＪＭＯはクラウドサービス提供事業者から発生した障害に関する情報や再発防止策が提供されないリスクを受容せざるを得ません。ただし、クラウドサービスの異なる地域（リージョン等）・拠点（アベイラビリティゾーン、ゾーン、可用性ゾーン、可用性ドメイン等） にも環境を構築する、情報システムを監視する項目を増やす等リスクを軽減する方策はあるため、事前に運用・保守事業者と相談の上、情報システムの運用方針を検討する対応を行うことができます。

品質管理を事業者任せにしない

品質管理は、サービス・業務としての品質管理とシステムの品質管理に大別されます。

まず、サービスや業務自体に求める品質についてです。利用者に発行する証明書の内容に誤りがあったり、利用料金の計算にミスがあったりしては、利用者からの信頼を大きく損なってしまいます。サービス品質、業務品質として、品質目標を定めた上で実際の品質達成状況を確認していくことが重要です。

なお、サービス品質、業務品質は、プロジェクト管理要領で忘れられがちなポイントです。後述するシステムの品質だけでなく、サービス・業務の品質にも留意してください。

次に、システムの品質についてです。本来はハードウェア等の品質管理も重要なのですが、よく「ソフトウェア品質」という言葉もほぼ同じ意味で使われます。ソフトウェア品質には、機能性、信頼性、使用性、効率性、保守性、移植性といった特性が含まれます。また、「サービスレベル」という形で品質上の重要な事項を指標化します。

実践ガイドブック「第3編第7章 Step4-2 品質管理の考え方を理解する」に記載されているため、これ以上詳細に踏み込みませんが、重要なことはシステムの品質についても事業者任せにしないということです。求める水準の品質を得るためには、調達仕様書の段階で具体的に品質管理手法や品質水準を提示し、試験の過程で発注者側が品質について関与する内容を明確にし、品質における事業者と発注者側の役割を明らかにすることが必要です。また、事業者内での品質管理体制も確認する必要があります。

事業者の工程完了時に、検収を行う担当者以外にＰＪＭＯの中から成果物や品質報告に対する承認を行う担当者を設けて、工程完了時にこの担当者による承認を必須とするようなルールを作ることも有効です。このようなルールを設けることで、システムの品質達成状況の実態を把握している職員が確実にチェックを行えるようになるので、一定の品質を保つことができます。

適切な工程開始条件、工程終了条件を設定する

工程開始条件や、工程終了条件は可能な限り明確に記載しましょう。曖昧に記載した場合、PJMOと事業者との間で認識相違が発生する可能性があります。とはいえ、明確に書くことだけに固執しすぎると条件が特定範囲に限定されてしまい、適切なマネジメントができなくなるおそれがあります。

例えば、社会的影響が大きいシステムについては、厳しい工程終了条件を設定し、不具合やすり抜けバグを次工程に持ち越さないようにするべきです。そのため、工程終了条件に「テストケースをすべて消化していること。」と記載するだけではなく、その後の対応まで詳しく記載する必要があります。

一方で、社会的影響がさほど大きくなくリリースまでの期間が短いといった制約条件があるような場合は、後続テストの工程を一部先行着手するといった対応も可能ですので、安易に「テストケースをすべて消化していること。」と記載せず、自身のプロジェクトの状況やシステムの特性を鑑みた上で効率的にプロジェクトを推進できる工程開始条件や工程終了条件を検討する必要があります。

以下に、具体例として結合テストの工程開始条件及び工程終了条件を示しますので、記載例を適宜確認の上カスタマイズして使ってください。

工程開始条件（例）

• 前工程の工程終了条件を満たしていること。

• テスト計画書、テスト仕様書、テストシナリオ、テストケース等のレビューが完了していること。

• テスト環境の準備が完了していること。

• テストデータの準備が完了していること。

• テストツールの準備が完了していること。

• テストを実施する要員のアサインや教育が完了していること。

• 接続先の情報システムが存在している場合は、接続先の情報システム担当者との調整が完了していること。

工程終了条件（例）

• 作成したテストシナリオやテストケースを消化していること。消化できないものについては、申し送り事項（当該工程ではなく後続工程で実施することを承認したものについて、その対応事項をまとめたもの）に整理していること。

• 検出されたすべての不具合に対して適切な是正処置（発生した不具合の原因分析、改修、再テスト、横展開での確認等を指す）が取られていること。

• テスト結果を踏まえた課題と対応方法（修正方針）について整理されていること。

• 脆弱性診断で検出された高危険度の指摘について是正方針が決定していること。

• その他の残課題がある場合、申し送り事項（当該工程ではなく後続工程で実施することを承認したものについて、その対応事項をまとめたもの）として整理されていること。

• テスト結果報告書を作成した上でテスト結果について振り返りを行い、課題やリスク、プロセス上に弱点があればそれを改善する活動ができていること。

• プロダクトの品質、プロダクトのリスク、サービスのリスクが懸念される場所については、品質強化テストなどの対策が取られていること。