Step.3 設計・開発の計画

設計・開発を担う事業者にとって、最初のインプット資料は、調達仕様書や要件定義書です。そのため、その内容には十分な質・量が求められますが、どんなに準備したとしても、要件の不備・不足は発生しますし、作業が進めば当初の計画からのかい離は起こり得ます。これらをＰＪＭＯが早期に察知して適切な関与を行っていかなければ、後々大変なことになりかねないのですが、事業者の活動は、実際の状況が見えづらくブラックボックスになりがちで、対応が遅くなってしまうことが多くあります。

ここでは、事業者の活動を正確に捉えて、設計・開発を円滑に進めて品質の良い情報システムを作り上げていくために、計画時点で理解すべき知識やノウハウを紹介していきます。

設計・開発の管理の要点を理解する

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

設計・開発を担う事業者の活動状況は、事業者との定例会において共有されますが、専門的な内容が多くなると、説明をただ聞くだけになりがちです。そのような状況でも、管理すべき管理の要点をしっかり押さえて確認し、不明な部分を事業者から引き出していけば、正しい方向にプロジェクトを導いていくことができます。

ここでは、設計・開発における管理の要点を見ていきましょう。

定点観測こそ進捗・品質管理の要（かなめ）

もしも、あなたに情報システムの整備に係るプロジェクトの経験がなくても、まずは作業の状況を定量値で管理し、継続してその値を把握してみましょう。そうすると、現場の状況がいろいろな角度から見えてきます。これにより問題が発生する予兆を捉えることができれば、その事象を個別に分析することで、原因を捉え、必要な対策をすることにつながります。

• 注記

ＳＰＩとは、累計の出来高計画値（ＰＶ）に対する累計の出来高実績値（ＥＶ）の比率のこと。

ＳＰＩはSchedule Performance Indexの略。

• 注記

ＥＶＭとは、ＷＢＳにより詳細化した各作業項目に出来高計画値（ＰＶ：Planned Value）を設定し、プロジェクトの進捗を出来高実績値(ＥＶ：Earned Value)として定量化すること。ＥＶＭはEarned Value Managementの略。（EVMの詳細については、Step.3-2Fを参照）

• 表7-6

工程別観測定量値と確認観点

• 注記

ＣＰＩとは、累計の投入実績値（ＡＣ）に対する累計の出来高実績値（ＥＶ）の比率のこと。

ＣＰＩはCost Performance Indexの略。

定量値の観測で大切なことは、事前に進捗率の測り方を明確にしておくことです。作業ステータスのような定性的な情報も、表7-6のようにプロジェクトで定めた基準に従って、定量的に管理するべきです。さらに、ステータス管理は、可能であれば作業に応じた成果物（ドキュメントやプログラミング）を捉えて、進捗を計上することをお勧めします。

このようなルールがなく担当者の恣意性に委ねると「進捗率90%」のまま数週間経つようなことになりかねません。例えば100本のプログラムがあって、50本のコーディングが完了したから「コーディング工程」の進捗率が50%、そのうち30本の単体テストが完了したので「単体テスト工程」の進捗率は30%というのではなく、100本の機能の内、進捗率100%が30機能、進捗率50%が20機能というように計上します。ドキュメントについても同様です。

• 表7-7

進捗計上ルールのサンプル（ドキュメント）

なお、コーディングと単体テストを峻別して進捗管理や品質メトリクスをマネジメントすることは、少なくてもユーザ側にとって意味がありません。

テスト駆動開発（テストを先に実装し、それにパスするようにプログラムをコーディングする開発手法）ではコーディングと単体テストが混然として実行されますし、設計されたテストケースどおりではなく単体テスト中に怪しいと感じた箇所を探るような探索的テストによって、コーディングを変更することが推奨される場合もあります。

むやみに作業を細分化して管理するのではなく、現場の行動に即して管理単位が決められているかを確認してください。

判断に必要な情報を職員が理解できる説明として事業者に求める

設計・開発の内容は専門的なものであるため、どうしても事業者の資料や説明内容は、職員から見ると専門的でわかりにくいものになりがちです。そのような場合、職員は、事業者が出してきた資料を苦労して読み解こうとしてしまうことがよくあります（もちろん悪いことではありません）が、職員の役割は、問題の本質を正しく捉えて判断することです。そのための近道は、職員が内容を理解できるように、丁寧な説明や資料のまとめ直しをしてもらうことです。内容がよくわからないからといって、事業者からの説明内容をうのみにして判断したり、判断を遅らせたりしてはいけません。

ただし、説明や資料の出し直しの過度な要求には、注意が必要です。進捗の遅延を引き起こす要因にもなりますし、事業者との関係悪化の原因にもなります。そのような状況になる前に、ＰＭＯに相談してみてください。設計・開発事業者と「協働して、良い情報システムを作り上げていく」という心構えが大切です。

設計・開発の実施計画を立てる

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

この実践ガイドブックには、別添として設計・開発の実施計画書と実施要領のひな形を示しています。

• 様式例7-1

設計・開発実施計画書、設計・開発実施要領のひな形

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

以降では、設計・開発の実施計画を作成するときに、特に注意が必要なポイントについて説明していきます。

2種類のプロジェクト計画書の相違点を理解する

設計・開発実施計画書は、設計・開発事業者が作成する「プロジェクト計画書」と同じものでしょうか。これらは、厳密には異なるものです。

設計・開発実施計画書は、当該事業者が担当する設計・開発作業の範囲について、ＰＪＭＯが作成するプロジェクト全体のプロジェクト計画（第３編第２章で示すプロジェクト計画書）を具体化・詳細化したものです。事業者との活動においても、他の関係者とのコミュニケーションや変更に対する管理は、プロジェクト計画に従って行わなければいけません。つまり、設計・開発実施計画書は、プロジェクト全体のプロジェクト計画書と整合性が取れている必要があります。

事業者が作成する「プロジェクト計画書」と必ずしも分ける必要はありません。事業者がプロジェクト計画書を作成し、それらをＰＪＭＯがプロジェクト全体のプロジェクト計画書との整合を確認して確定するという流れでも良いです。もちろん、ＰＪＭＯが設計・開発実施計画書を作成しても良いです。

大切なことは、設計・開発実施計画書、プロジェクト全体のプロジェクト計画書、事業者が作成するプロジェクト計画の整合性が取れており、全ての関係者がそごなく作業を行えることです。

• 図7-5

設計・開発実施計画書、プロジェクト計画書、事業者のプロジェクト計画書の関係性

意思決定の手順を明確にする

設計・開発の実施中には、プロジェクトの内外問わず様々な課題や問題が発生します。その際に、どのように意思決定を行うかを計画時に明確にしておきます。

通常は、事業者との定例会を設置し、発生した課題や問題はその場で対応を決定していくことになります。しかし、優先度が高く解決が難しい問題を定例会の場だけでやりとりしていると、解決が遅れてプロジェクト全体の遅延につながってしまいます。

したがって、優先度が高い問題、影響が大きい問題が想定外に発生した場合の意思決定の方法をあらかじめ定めておくことが大切です。一般的には、課題や問題の影響範囲や優先度等の基準を定めておき、一定以上の基準の課題や問題が発生した際に、定例会議以外に、発生した課題を集中的に検討する会議の設置、影響範囲や影響度合いに応じての参加者等を定めておきます。

大切なことは、課題や問題が発生した場合に、それらを事業者やプロジェクトの一部の関係者だけでブラックボックスにせず、影響がある関係者に適切に共有し、共同して解決に向かうことです。

当初計画からの変更は、必ず関係者で合意する

策定時に関係者全体で合意した内容が、いつの間にか当事者だけで変更されてしまうというケースがあります。特に、プロジェクトの目的に直結する重要な事項の変更は、全体関係者及び責任者の承諾なしに変更することは厳禁です。

関連する事例として、実践ガイドブック「第２章事例2－10. 開発途中の機能追加による目標の形骸化」も参照してください。

他の関係者との役割分担の境界線を定める

設計・開発の計画においては、ＰＪＭＯ、設計・開発の事業者、プロジェクト内の他の事業者、連携する情報システムのプロジェクト等の関係者の役割分担（誰が何を実施するか）を決定し、関係者で合意することがとても大切です。

役割分担でよく問題になるのは、他の情報システムの連携仕様を誰が具体的に定めるのか（要は、具体的なインタフェース仕様書を誰が作成するか、テストにおいて誰が主導してデータやテスト計画を作成するか）です。特に、複数情報システムで共有する連携仕様の場合は、分担が不明確になりがちなので、計画時点で明確に取り決めておきましょう。連携に関するテストを誰がどのように取り仕切るかも同様に決めておく必要があります。

• 注記

ＷＢＳとは、プロジェクトに必要な作業の全体を細かい単位に分割した上で、全体の構成を示したもの。ＷＢＳはWork Breakdown Structureの略。

ＷＢＳで作業計画を確認し進捗を把握する

ＷＢＳは、設計・開発のスケジュールや進捗を管理する際に一般的に使われるもので、設計・開発の活動ごとの成果物を洗い出し、その成果物を得るために必要な作業を細分化し、作業にかかる時間や作業順を当てはめていったものです。（正確には、縦軸の作業項目がＷＢＳであり、スケジュールを含めたものはガントチャートと呼びます。）

ここでは、設計・開発の計画や進捗状況を正確に把握するためのＷＢＳに関するノウハウを見てきます。

ＷＢＳの構造を理解して計画や状況を効果的に把握する

スケジュールは、「マイルストーンを明確にする」「概略のスケジュールを立てる」「詳細な作業ごとに、作業にかかる時間と作業間の依存関係を検討し、作業順を決める」という３段階で組み立てられます。

• 図7-6

WBSのイメージ。

このイメージはアプリケーション開発に着目した例。運用に関しても、運用設計、運用手順書、総合テスト、運用テストという流れで同様にWBSを作成する。

• 注記

クリティカル・パスとは、アクティビティの最長経路。この経路に必要な期間が、プロジェクトの最短所要時間となる。クリティカル・パス上のアクティビティが遅延した場合、プロジェクト期間に影響を与えるため、注意が必要。

ＷＢＳを確認する際には、この構造を理解し、「マイルストーンにそごや抜け漏れはないか？」「マイルストーンに対して、概略のスケジュールが妥当か？」「各作業の依存関係の誤りや作業の抜け漏れはないか？」「どのアクティビティの経路がクリティカル・パスとなっているのか？」のように段階的にチェックすることで、網羅的な確認をすることができます。

また、「Ｓｔｅｐ3-1-A. 定点観測こそ進捗・品質管理の要（かなめ）」でも述べたように、定例会等で進捗状況を確認していると、「進捗率が90%で止まっている作業が大量にある」というような状況がよくあります。これは、多くの場合、進捗率の定義が曖昧であることに起因しています。進捗率は、定量的に判断できるように事前に基準を定めましょう。

• 注記

ＰＶとは、計画時に見積もった出来高値のこと。

ＰＶはPlanned Valueの略。

ＥＶＭを用いた進捗管理手法を理解する

• 注記

ＥＶとは、進捗把握時までに完了した作業の出来高値のこと。

ＥＶはEarned Valueの略。

ＷＢＳにより詳細化した各作業項目に出来高計画値（ＰＶ：Planned Value）を設定し、プロジェクトの進捗を出来高実績値(ＥＶ：Earned Value)として定量化するＥＶＭを用いることで、作業状況を客観的な統一尺度で可視化及び一元管理し、プロジェクトの進捗状況や進捗に係る課題・問題の把握を行い、事前に的確な対応を行うことが可能となります。

ＥＶＭを用いて進捗管理を行う場合、次に示す資料を作成します。

• 注記

ＡＣとは、進捗把握時までに完了した作業に投入したコストのこと。

ＡＣはActual Costの略。

ＥＶＭ進捗管理表

ＷＢＳの各作業に対し、出来高計画値（ＰＶ）、出来高実績値（ＥＶ）、投入実績値（ＡＣ）を記載します。

本様式は各タスクの計画と実績の対比を詳細に示すものであり、進捗管理の基礎情報として用いるものであるため、必ず正確な情報を記載します。

• 図7-7

ＥＶＭ進捗管理表

• 出来高計画値（ＰＶ） ＷＢＳにより詳細化した各作業項目に対し設定した出来高計画値（ＰＶ）を記載します。出来高計画値（ＰＶ）の合計は計画総コスト(ＢＡＣ:Budget At Completion)と必ず一致するように設定します。 出来高計画値（ＰＶ）の作成により、作業コストが多い作業項目や期間が可視化されるため、各期間の作業統制の難易度やリスクが顕在化した際の影響の大きさを判断することが可能となります。 なお、出来高計画値（ＰＶ）はその精度を高めることが必要でありますが、事前に完全一致させる計画を立案することは不可能であり、また、計画外の事態は起こり得るものです。そのため、進捗管理に当たってはＰＶどおりに進めることのみを意識するのでなく、実績と計画の差異を常時把握し、計画どおりに戻すための対策を検討することが重要です。

• 出来高実績値（ＥＶ） 進捗把握時までに完了した作業の出来高値を記載します。計上方法は表7-8に示す例を参考にあらかじめ定め、それに基づき計上します。 出来高実績値（ＥＶ）は現状を可視化するための基礎情報であるため、リアルタイムで、かつ、正確な情報とする必要があります。

• 表7-8

出来高実績値（ＥＶ）計上法

• 注記

ＥＡＣとは、完了時に予測される総コストのこと。

ＥＡＣはEstimate At Completionの略。

投入実績値（ＡＣ） 進捗把握時までに完了した作業に対し、実際に投入したコストを記載します。 投入実績値（ＡＣ）は現状を可視化するための基礎情報であるため、リアルタイムで、かつ、正確な情報とする必要があります。

1. 進捗状況表

• 注記

ＥＴＣとは、進捗把握時から完了までに予測されるコストのこと。

ＥＴＣはEstimate To Completeの略。

ＥＶＭ進捗管理表を集計し、月次の出来高計画値（ＰＶ）、出来高実績値（ＥＶ）、投入実績値（ＡＣ）、スケジュール効率指数（ＳＰＩ）、コスト効率指数(ＣＰＩ)、予測総コスト（ＥＡＣ）及び残コスト（ＥＴＣ）を記載します。

本様式は、月次の進捗状況の定量分析結果を示すものであり、次に示す例は、スケジュールが遅れている上にコストも超過し、体制強化や品質向上施策等の対応を至急行うべき状況を表すものです。

• 図7-8

進捗状況表

（様式及び記載例）

• 表7-9

進捗状況表の記載項目

2. ＥＶＭ推移グラフ

ＥＶＭ進捗管理表を集計し、出来高計画値（ＰＶ）、出来高実績値（ＥＶ）及び投入実績値（ＡＣ）の推移についてのグラフを作成し、予測総コスト（ＥＡＣ）、予測完了時点等を分析します。

本様式は、「(2)　進捗状況表」と合わせて月次の進捗状況の定量分析に用いるものです。次に示す例は、スケジュールが遅れている上にコストも超過し、体制強化や品質向上施策等の対応を至急行うべき状況を表すものです

（様式及び記載例）

• 図7-9

ＥＶＭ推移グラフ

• 表7-10

ＥＶＭ推移グラフの記載項目

3. 進捗状況分析図

進捗状況表を集計し、スケジュール効率指数（ＳＰＩ）、コスト効率指数(ＣＰＩ)の推移についてのグラフを作成し、スケジュール及びコストの効率の傾向を時系列で分析します。

本様式は、月次の進捗状況の定量分析に用いるものです。次に示す例は、品質悪化が進み、スケジュール変更等の抜本的な見直しが必要な状況を表すものです。

（様式及び記載例）

• 図7-10

進捗状況分析図

スケジュール遅延

コストは計画超過

スケジュール遅延

コストは計画内

計画以上の進捗

コストは計画超過

計画以上の進捗

• スケジュール効率指数（ＳＰＩ） 各月のスケジュール効率指数（ＳＰＩ）をグラフ化する。右に行くほどスケジュール効率が高まっていることを示す。

• コスト効率指数（ＣＰＩ） 各月のコスト効率指数（ＣＰＩ）をグラフ化する。上に行くほどコスト効率が高まっていることを示す。

上図の例では、7/1から作業が始まっています。

ところが、9/3や9/14頃にはSPIもCPIも１を下回りました。つまり、スケジュール面では計画から遅れ、コスト面でも予定を超過（予定よりもコスト効率が低い）した状態となっています。

その後、10/1の段階ではSPIが1に戻りました。つまり、スケジュール面では計画どおりに追いついたということです。一方で、CPIはさらに悪化しています。当初想定以上に要員を投入したのではないかと、読み取ることができます。

4. ＥＶＭの使い方

ここまで説明したように、ＥＶＭ手法はプロジェクトの進捗度合いを管理していくための有用な手段です。端的に言えば、「進んでいるか遅れているか」をわかりやすく表現することが可能です。ただし、計画に描いたＷＢＳそのものに抜け漏れがあったり、潜在的な課題を見過ごしたりしていれば、ＥＶＭ管理上では問題がなさそうなプロジェクトにおいてもある日突然進捗が進まなくなることがあります。また、業務関係者の調整とコンセンサスが不十分であれば、開発終盤にどんでん返しのように手戻りが発生する懸念もあります。

こうしたことから、ＰＪＭＯとしてはＥＶＭの指標値を有力な手掛かりとしつつも、継続的にＷＢＳの妥当性や関係者間の業務調整の状況にも気を配っていくことが肝要です。

テストの計画を立てる

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

情報システムの設計・開発では、品質の管理が重要であり、そのためには十分なテストが必要だ。ということは、よく耳にすると思います。しかし、そもそも「品質の良い情報システム」とは、どういうものでしょうか？また、設計・開発では様々なテストを行いますが、何が違うのでしょうか？

ここでは、効果的なテストを行いながら品質を管理してより良い情報システムを構築していくためのテストの計画に関する基本的な考え方、知識、ノウハウをご紹介していきます。

Ｖ字モデルと発注者・委託先事業者の役割分担を把握する

現在、ウォーターフォール型の開発プロセスではＶ字モデルが一般的です。開発プロセスには各種の国際標準や国内標準もありますが、「標準ガイドライン」の工程定義にのっとると、次のように表現できます。

• 図7-11

標準ガイドラインの定義に則ったソフトウェア開発プロセスのV字モデル

直線的に進んでいく工程を、あえてＶ字にしていることには意味があります。同じ高さにある工程が、それぞれ深く関係しています。例えば、総合テストとは基本設計で定めた要件が充足されているかを確認するテストであり、受入テストとは要件定義との充足性を確認するテストということです。

また、工程によって発注者側（ＰＪＭＯ）と委託先事業者の役割は変わりますし、作業の主体も変わります。このことを非常に大雑把に表すと、次のような図となります。

• 図7-12

発注者と委託先の関わり度合の変化

多くの人は、図の左側にある要件定義や基本設計は両者で協業して作り上げていく認識を持っています。一方で、図の右側にあるテスト工程については発注者が関与するという認識を持っていないこともあります。

テスト工程において、発注者側にはテスト計画を確認し、テスト実施状況を管理し、テスト結果を評価するという重要な役割があります。特に、総合テスト以降の工程終盤になればなるほど発注者側の関与が重要であり、受入テストは発注者自身が実施するものであることを覚えておいてください。

• 事例7-4

  テスト工程の品質が悪いために進捗の遅延、すり抜けバグが多発するプロジェクト

テストのレベルや種類を理解する

さて、単体テスト、結合テスト、総合テスト、受入テストの４種類の工程があることを説明しましたが、これらの工程は何が違うのでしょうか。

情報システムのテストは、段階的に進めていきます。個々のプログラムが設計書どおりにできているか？プログラムをつなげて機能としてみたときに、機能の設計を満たしているか？機能同士をつなげてみたときに、要件を満たしているか？要件どおりにできたが、業務が適切に遂行できるか？このように、徐々に確認するレベルを上げていくのです。

これは、まさにＶ字モデルが表していることです。標準ガイドラインで定義しているテスト工程では、次のように整理しています。

• 注記

ユースケースとは、特定の目的を達成するためにアクタ（ユーザ）が実施する手順等を定義したもの。

• 表7-11

テスト工程

大きな分類は、上記のとおりですが、それぞれのテスト工程の中でも異なる種類のテストを実施します。それらの詳細は、Step.4で触れていきます。

また、テスト工程とは別に、テスト手法の違いがあります。これらの内容は、事業者がテストの実施方法をＰＪＭＯに説明する際に使用されるため、知識として知っておくと理解しやすくなります。

• 表7-12

テストの種類

非機能要件のテスト工程を詳細に確認する

非機能要件については総合テストで全体的に確認することになりますが、総合テストの工程で初めて非機能要件を確認するわけではありません。単体テスト、結合テストという前工程でも、それぞれの「部品」が非機能要件を満たすことを確認した上で、総合テスト工程でシステム全体としての非機能要件を確認します。

この点を誤解して結合テストにおいて非機能要件の確認を怠ると、総合テストにおいて大きな手戻りが発生することになりかねません。

以下に、結合テストにおける非機能要件のテスト観点の例を示します。非機能要件に係るテストの実施工程の検討材料としてください。

• 表7-13

非機能要件テストの実施観点及び工程例（テスト観点は抜粋）

リスクを踏まえてテストの方針を決める

テストの計画を立てる以前に、プロジェクトや情報システムの特性を見極めて、どこに深刻なリスクが存在するかを分析します。

例えば、統計システムと請求支払システムでは端数誤差に対するリスク度合いが異なるでしょう。請求支払いシステムでは、１円の誤差でも誤請求として重大な問題になります。このように、リスクを識別することで、初めて機能、性能、セキュリティ、可用性等について当該情報システムがクリアしなければならない重要な要件をあぶり出すことができ、テストを重点的に実施すべき対象を特定できます。

このようなリスク分析は、事業者に丸投げすることはできません。情報システム特性は多様なので、様々な経験・スキル等を持った「人」によってその見え方が異なります。それはデータベースやネットワークという技術要素のことだけでなく、主に過去の障害事例やレアケースを経験しているようなことを指しています。利用者、情報システム運用者、ヘルプデスク等の関係者によって見えてくる風景が異なるので、特に改修案件の場合はこれらの人にヒアリングをして、情報システム特性やリスクを特定してください。

また、プロジェクトの企画段階において、まず必要なテスト工程の期間やリソースは十分確保すべきですが、短期間でリリースする必要があり、かつスケジュールの延伸が許されないプロジェクトにおいては、あらかじめ業務上発生するユースケースに係る機能の重要度や優先度を定めておきます。

重要度、リスクの高い機能については、綿密にテストを行う一方で、重要度やリスクが低い機能についてはエビデンスの取得を省略する、探索的テストを導入するなど、濃淡をつけた対応をすることで、スケジュールが遅延するリスクを軽減することができますので、自らのプロジェクトの状況により検討してください。

ただし、このように重要度やリスクに応じてテスト手法や確認方法に濃淡をつける場合は、どのように濃淡をつけたのかテスト計画書等に明記し、事前に関係者で合意し、事後に振り返りができるようにしてください。

テストにおける役割分担と必要な環境を明確にする

他の情報システムと連携を行う場合（特に複数の情報システムがデータを連携する場合）は、役割分担を具体的に定めることがとても重要です。これらを事前に決めておかないと、いざテストを行う時期になってもめることになり、テストの開始が遅れて十分なテストが行えず、本番稼働を行ってから不具合が多発することにもなりかねません。

他の情報システムと連携を行う場合は、次に示す事柄を計画時点で明確にして、関係者間で合意しましょう。

他情報システム連携に関する計画の注意点

• 他情報システム連携に係る機能において不具合が発生した場合、他情報システムにも影響が発生する。 そのような不具合を早期に発見するために、前もって疎通確認しておくことや、優先度や重要度の高いテスト項目からテストを実施することも重要である。なお、「他情報システム連携に関する計画の注意点」に記載された事項は他情報システム連携に限らず、例えばフロントエンドとバックエンドで開発方式や開発チームが異なる場合においても留意すべき事項である。

• 他情報システム連携を確認するテスト（主に総合テスト）の実施主体（誰が音頭を取るか）、各情報システムの窓口となる担当者、計画の作成者を決める。 なお、高度な調整を要する場合は、プロジェクトの対外調整の役目を有するプロジェクト推進管理者が実施することとなる。

• どの段階で何を確認するかを明確にする。例えば、結合試験段階では、サンプルデータを授受し、事前にインタフェースの確認を行う等、段階的に品質を高めていく方法もある。また、連携テストを行う環境の疎通テスト、本番環境の疎通テストはいつ行うか等、環境や観点ごとに漏れなく計画する。

• テストデータは、誰がどの範囲のデータを作成するかを決める。基本的には出し元が作成することになるが、どのようなデータのバリエーションのテストが行いたいかは受け側と調整する必要がある点にも注意する。

• 連携テストはどの環境で行うか。環境ごとの疎通テストの実施有無、実施時期を決める。特に総合テスト以降は、様々なテストが同時並行で行われるため、環境の取決めはしっかり行うことに注意する。

テストツールを有効活用する

近年、情報システムの品質を向上させるためのツールは多く登場しています。これらを活用することで、設計・開発の活動を効率的に進めたり、効果的に品質を担保・向上させたりすることができます。事業者とも相談しながら、導入を検討してみてください。

• 表7-14

テストツール

• 参考7-3

自動テストを導入するメリット・デメリット

テスト計画を作成する

前述のA.～E.で検討した内容をテスト計画書にまとめます。テスト計画書は、単体テスト、結合テスト等のテスト工程ごとに作成します。

以下にその目次と記載内容の例を示します。

• 表7-15

テスト計画書（テスト工程別）目次と記載内容（例）

テスト工程別のテスト計画書だけでなく、テスト全体の方針等を定める全体テスト計画書を作成する場合もあります。

全体テスト計画書は、想定されるリスクや重視すべき要件等を踏まえて、テスト全体を効率的かつ効果的に実施するために作成します。

以下にその目次と記載内容の例を示します。

• 表7-16

全体テスト計画書 目次と記載内容（例）

また、各テストを実施する前に、テスト計画書の内容を踏まえて、テストシナリオ、テスト項目、使用するテストデータ、合否判定基準等をテスト実施要領にまとめます。なお、ドキュメントの名称は案件によって異なっていても問題はなく、これらの項目を事前に定義していることが重要です。

テスト結果の確認方法を明記する

テストケースやテストシナリオの作成時に「エラーを確認する」といった曖昧な確認方法を記載すると、テスト実施者（テスター）によって確認結果がバラつき、テスト作成者が求めていた意図と異なってしまう可能性があります。

そのため、どのテスターでもテストの確認結果にバラつきが出ないようにテストシナリオ、テストケースを準備する必要があります。

以下にテスト結果の確認方法が不明確な例、明確な例を示しますので、テストシナリオやテストケースの作成時の参考にしてください。

テストの確認方法が不明確な例、明確な例

• （不明確な例）テスト結果が正しいことを確認する。

• 注記

  具体的なメッセージ等を記載すること。

（明確な例）テストを実行した際に表示されるメッセージが、設計書に記載されているメッセージ(「メッセージID：XX 成功しました」等)と一致すること。

⇒（解説）具体的な期待結果を記載することが望ましい。

• （不明確な例）エラーが発生することを確認する。

• （明確な例）エラーが発生（エラーID：XX）した場合において、利用者が対応（入力データの修正等）できるようなシステムの仕様になっていることを確認する。

  ⇒（解説）エラーが発生することだけでなく、エラーが起きたあとユーザが対応可能であるか確認が必要であるため、明確に記載すること。

取得するテストエビデンスの対象を事前に合意する

テストを実施する際に取得するテストエビデンスの対象については、テスト計画段階で受託者と確認方法や承認方法、納品物を関係者の間で合意しておく必要があります。

• 参考7-4

テストのエビデンスを取得するメリット・デメリット