--- type: guideline title: Step.3 設計・開発の計画 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # 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 進捗計上ルールのサンプル（ドキュメント） | 進捗率 | ドキュメント | |--------|--------------------------------------------| | 0～50% | 事業者の担当者が実作業の進捗に合わせて計上 | | 60% | 事業者内レビューの完了 | | 70% | レビュー指摘事項の反映完了 | | 80% | ＰＪＭＯレビューの完了 | | 90% | レビュー指摘事項の反映完了 | | 100% | ＰＪＭＯによる最終確認 | なお、コーディングと単体テストを峻別して進捗管理や品質メトリクスをマネジメントすることは、少なくてもユーザ側にとって意味がありません。 テスト駆動開発（テストを先に実装し、それにパスするようにプログラムをコーディングする開発手法）ではコーディングと単体テストが混然として実行されますし、設計されたテストケースどおりではなく単体テスト中に怪しいと感じた箇所を探るような探索的テストによって、コーディングを変更することが推奨される場合もあります。 むやみに作業を細分化して管理するのではなく、現場の行動に即して管理単位が決められているかを確認してください。 ### 判断に必要な情報を職員が理解できる説明として事業者に求める 設計・開発の内容は専門的なものであるため、どうしても事業者の資料や説明内容は、職員から見ると専門的でわかりにくいものになりがちです。そのような場合、職員は、事業者が出してきた資料を苦労して読み解こうとしてしまうことがよくあります（もちろん悪いことではありません）が、職員の役割は、問題の本質を正しく捉えて判断することです。そのための近道は、職員が内容を理解できるように、丁寧な説明や資料のまとめ直しをしてもらうことです。内容がよくわからないからといって、事業者からの説明内容をうのみにして判断したり、判断を遅らせたりしてはいけません。 ただし、説明や資料の出し直しの過度な要求には、注意が必要です。進捗の遅延を引き起こす要因にもなりますし、事業者との関係悪化の原因にもなります。そのような状況になる前に、ＰＭＯに相談してみてください。設計・開発事業者と「協働して、良い情報システムを作り上げていく」という心構えが大切です。 ## 設計・開発の実施計画を立てる 【標準ガイドライン関連箇所：第３編第７章第１節】 この実践ガイドブックには、別添として設計・開発の実施計画書と実施要領のひな形を示しています。 - 様式例7-1 設計・開発実施計画書、設計・開発実施要領のひな形

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

設計・開発実施計画書、設計・開発実施要領のひな形を本章別紙としてまとめています。

![](../assets/ds-120-ch07-image7.jpeg) ![](../assets/ds-120-ch07-image8.png)
あくまでこのひな形は例示です。プロジェクトの内容に応じて記載内容を個別に追加、変更しても構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。 以降では、設計・開発の実施計画を作成するときに、特に注意が必要なポイントについて説明していきます。 ### 2種類のプロジェクト計画書の相違点を理解する 設計・開発実施計画書は、設計・開発事業者が作成する「プロジェクト計画書」と同じものでしょうか。これらは、厳密には異なるものです。 設計・開発実施計画書は、当該事業者が担当する設計・開発作業の範囲について、ＰＪＭＯが作成するプロジェクト全体のプロジェクト計画（第３編第２章で示すプロジェクト計画書）を具体化・詳細化したものです。事業者との活動においても、他の関係者とのコミュニケーションや変更に対する管理は、プロジェクト計画に従って行わなければいけません。つまり、設計・開発実施計画書は、プロジェクト全体のプロジェクト計画書と整合性が取れている必要があります。 事業者が作成する「プロジェクト計画書」と必ずしも分ける必要はありません。事業者がプロジェクト計画書を作成し、それらをＰＪＭＯがプロジェクト全体のプロジェクト計画書との整合を確認して確定するという流れでも良いです。もちろん、ＰＪＭＯが設計・開発実施計画書を作成しても良いです。 大切なことは、設計・開発実施計画書、プロジェクト全体のプロジェクト計画書、事業者が作成するプロジェクト計画の整合性が取れており、全ての関係者がそごなく作業を行えることです。 - 図7-5 設計・開発実施計画書、プロジェクト計画書、事業者のプロジェクト計画書の関係性 ![](../assets/ds-120-ch07-image9.png) ### 意思決定の手順を明確にする 設計・開発の実施中には、プロジェクトの内外問わず様々な課題や問題が発生します。その際に、どのように意思決定を行うかを計画時に明確にしておきます。 通常は、事業者との定例会を設置し、発生した課題や問題はその場で対応を決定していくことになります。しかし、優先度が高く解決が難しい問題を定例会の場だけでやりとりしていると、解決が遅れてプロジェクト全体の遅延につながってしまいます。 したがって、優先度が高い問題、影響が大きい問題が想定外に発生した場合の意思決定の方法をあらかじめ定めておくことが大切です。一般的には、課題や問題の影響範囲や優先度等の基準を定めておき、一定以上の基準の課題や問題が発生した際に、定例会議以外に、発生した課題を集中的に検討する会議の設置、影響範囲や影響度合いに応じての参加者等を定めておきます。 大切なことは、課題や問題が発生した場合に、それらを事業者やプロジェクトの一部の関係者だけでブラックボックスにせず、影響がある関係者に適切に共有し、共同して解決に向かうことです。 ### 当初計画からの変更は、必ず関係者で合意する 策定時に関係者全体で合意した内容が、いつの間にか当事者だけで変更されてしまうというケースがあります。特に、プロジェクトの目的に直結する重要な事項の変更は、全体関係者及び責任者の承諾なしに変更することは厳禁です。 関連する事例として、実践ガイドブック「第２章事例2－10. 開発途中の機能追加による目標の形骸化」も参照してください。 ### 他の関係者との役割分担の境界線を定める 設計・開発の計画においては、ＰＪＭＯ、設計・開発の事業者、プロジェクト内の他の事業者、連携する情報システムのプロジェクト等の関係者の役割分担（誰が何を実施するか）を決定し、関係者で合意することがとても大切です。 役割分担でよく問題になるのは、他の情報システムの連携仕様を誰が具体的に定めるのか（要は、具体的なインタフェース仕様書を誰が作成するか、テストにおいて誰が主導してデータやテスト計画を作成するか）です。特に、複数情報システムで共有する連携仕様の場合は、分担が不明確になりがちなので、計画時点で明確に取り決めておきましょう。連携に関するテストを誰がどのように取り仕切るかも同様に決めておく必要があります。 - 注記 ＷＢＳとは、プロジェクトに必要な作業の全体を細かい単位に分割した上で、全体の構成を示したもの。ＷＢＳはWork Breakdown Structureの略。 ＷＢＳで作業計画を確認し進捗を把握する ＷＢＳは、設計・開発のスケジュールや進捗を管理する際に一般的に使われるもので、設計・開発の活動ごとの成果物を洗い出し、その成果物を得るために必要な作業を細分化し、作業にかかる時間や作業順を当てはめていったものです。（正確には、縦軸の作業項目がＷＢＳであり、スケジュールを含めたものはガントチャートと呼びます。） ここでは、設計・開発の計画や進捗状況を正確に把握するためのＷＢＳに関するノウハウを見てきます。 #### ＷＢＳの構造を理解して計画や状況を効果的に把握する スケジュールは、「マイルストーンを明確にする」「概略のスケジュールを立てる」「詳細な作業ごとに、作業にかかる時間と作業間の依存関係を検討し、作業順を決める」という３段階で組み立てられます。 - 図7-6 WBSのイメージ。 このイメージはアプリケーション開発に着目した例。運用に関しても、運用設計、運用手順書、総合テスト、運用テストという流れで同様にWBSを作成する。 ![](../assets/ds-120-ch07-image10.png) - 注記 クリティカル・パスとは、アクティビティの最長経路。この経路に必要な期間が、プロジェクトの最短所要時間となる。クリティカル・パス上のアクティビティが遅延した場合、プロジェクト期間に影響を与えるため、注意が必要。 ＷＢＳを確認する際には、この構造を理解し、「マイルストーンにそごや抜け漏れはないか？」「マイルストーンに対して、概略のスケジュールが妥当か？」「各作業の依存関係の誤りや作業の抜け漏れはないか？」「どのアクティビティの経路がクリティカル・パスとなっているのか？」のように段階的にチェックすることで、網羅的な確認をすることができます。 また、「Ｓｔｅｐ3-1-A. 定点観測こそ進捗・品質管理の要（かなめ）」でも述べたように、定例会等で進捗状況を確認していると、「進捗率が90%で止まっている作業が大量にある」というような状況がよくあります。これは、多くの場合、進捗率の定義が曖昧であることに起因しています。進捗率は、定量的に判断できるように事前に基準を定めましょう。 - 注記 ＰＶとは、計画時に見積もった出来高値のこと。 ＰＶはPlanned Valueの略。 ＥＶＭを用いた進捗管理手法を理解する - 注記 ＥＶとは、進捗把握時までに完了した作業の出来高値のこと。 ＥＶはEarned Valueの略。 ＷＢＳにより詳細化した各作業項目に出来高計画値（ＰＶ：Planned Value）を設定し、プロジェクトの進捗を出来高実績値(ＥＶ：Earned Value)として定量化するＥＶＭを用いることで、作業状況を客観的な統一尺度で可視化及び一元管理し、プロジェクトの進捗状況や進捗に係る課題・問題の把握を行い、事前に的確な対応を行うことが可能となります。 ＥＶＭを用いて進捗管理を行う場合、次に示す資料を作成します。 - 注記 ＡＣとは、進捗把握時までに完了した作業に投入したコストのこと。 ＡＣはActual Costの略。 ＥＶＭ進捗管理表 ＷＢＳの各作業に対し、出来高計画値（ＰＶ）、出来高実績値（ＥＶ）、投入実績値（ＡＣ）を記載します。 本様式は各タスクの計画と実績の対比を詳細に示すものであり、進捗管理の基礎情報として用いるものであるため、必ず正確な情報を記載します。 - 図7-7 ＥＶＭ進捗管理表 ![](../assets/ds-120-ch07-image11.png) - 出来高計画値（ＰＶ） ＷＢＳにより詳細化した各作業項目に対し設定した出来高計画値（ＰＶ）を記載します。出来高計画値（ＰＶ）の合計は計画総コスト(ＢＡＣ:Budget At Completion)と必ず一致するように設定します。 出来高計画値（ＰＶ）の作成により、作業コストが多い作業項目や期間が可視化されるため、各期間の作業統制の難易度やリスクが顕在化した際の影響の大きさを判断することが可能となります。 なお、出来高計画値（ＰＶ）はその精度を高めることが必要でありますが、事前に完全一致させる計画を立案することは不可能であり、また、計画外の事態は起こり得るものです。そのため、進捗管理に当たってはＰＶどおりに進めることのみを意識するのでなく、実績と計画の差異を常時把握し、計画どおりに戻すための対策を検討することが重要です。 - 出来高実績値（ＥＶ） 進捗把握時までに完了した作業の出来高値を記載します。計上方法は表7-8に示す例を参考にあらかじめ定め、それに基づき計上します。 出来高実績値（ＥＶ）は現状を可視化するための基礎情報であるため、リアルタイムで、かつ、正確な情報とする必要があります。 - 表7-8 出来高実績値（ＥＶ）計上法
方式 説明 特徴
固定比率計上法 作業の開始時と完了時のみに進捗を計上する方法

前提として詳細な作業分界を行う必要がある。

作業開始時と作業完了時に計上する比率には、0:100、30:70、50:50等があり、事前に定める必要がある。
加重比率計上法 作業の達成率により進捗を計上する方法

作業期間が長い場合等、固定比率計上法では進捗を把握するのが難しい場合に有効。

細かくマイルストーンを事前に定め、主観による曖昧さを排除する必要がある。
- 注記 ＥＡＣとは、完了時に予測される総コストのこと。 ＥＡＣはEstimate At Completionの略。 投入実績値（ＡＣ） 進捗把握時までに完了した作業に対し、実際に投入したコストを記載します。 投入実績値（ＡＣ）は現状を可視化するための基礎情報であるため、リアルタイムで、かつ、正確な情報とする必要があります。 1) 進捗状況表 - 注記 ＥＴＣとは、進捗把握時から完了までに予測されるコストのこと。 ＥＴＣはEstimate To Completeの略。 ＥＶＭ進捗管理表を集計し、月次の出来高計画値（ＰＶ）、出来高実績値（ＥＶ）、投入実績値（ＡＣ）、スケジュール効率指数（ＳＰＩ）、コスト効率指数(ＣＰＩ)、予測総コスト（ＥＡＣ）及び残コスト（ＥＴＣ）を記載します。 本様式は、月次の進捗状況の定量分析結果を示すものであり、次に示す例は、スケジュールが遅れている上にコストも超過し、体制強化や品質向上施策等の対応を至急行うべき状況を表すものです。 - 図7-8 進捗状況表 （様式及び記載例） ![](../assets/ds-120-ch07-image12.png) - 表7-9 進捗状況表の記載項目
記載項目 記載内容

①出来高計画値

（ＰＶ）

 当月及び当月までの累計の出来高計画値（ＰＶ）を記載する。

②出来高実績値

（ＥＶ）

 当月及び当月までの累計の出来高実績値（ＥＶ）を記載する。

③投入実績値

（ＡＣ）

 当月及び当月までの累計の投入実績値（ＡＣ）を記載する。

④スケジュール効率指数

（ＳＰＩ）

当月までの累計の出来高計画値（ＰＶ）に対する累計の出来高実績値（ＥＶ）の比率を記載する。

ＳＰＩが１を超えている場合は、スケジュール以上に進んでいることを示し、ＳＰＩが１を下回っている場合は、スケジュール遅延が起きていることを示す。

ＳＰＩが１を下回っている場合は、手順の見直しによるコスト効率の向上や人員の増加による投入コストの増加によりスケジュール遅延を回復することができる可能性がある。ただし、人員の増加による投入コストの増加を行った場合は、コスト効率の低下が起きることが多い。

⑤コスト効率指数

（ＣＰＩ）

当月までの累計の投入実績値（ＡＣ）に対する累計の出来高実績値（ＥＶ）の比率を記載する。

ＣＰＩが１を超えている場合は、作業効率が高まっていることを示し、ＣＰＩが１を下回っている場合は、作業効率が下がっていることを示す。

ある時点でＣＰＩが１を下回っている場合は、その後の工程で開発手順や開発効率を改善させない限り、完成時において予定コスト内でプロジェクトを終了することは難しいことが多い。

⑥予測総コスト

（ＥＡＣ）

当該時点で予測される完了までの総コストを記載する。差異が今までと同様に推移する場合は、計画総コスト（ＢＡＣ）をコスト効率指数（ＣＰＩ）で除算することにより、完了時に予測される総コストについて算定することができる。

ＥＡＣがＢＡＣを超える場合は、計画より多いコストで完了することが見込まれることを示し、ＥＡＣがＢＡＣを下回る場合は、計画より少ないコストで完了することが見込まれることを示す。

⑦残コスト

（ＥＴＣ）

予測総コスト（ＥＡＣ）と投入実績値（ＡＣ）の差を記載する。

ＥＴＣが完了までに投入可能なコストを超える場合は、完了遅延が見込まれることを示す。またコスト差異が今後も発生する場合には、コスト効率を考慮することも必要である。
2) ＥＶＭ推移グラフ ＥＶＭ進捗管理表を集計し、出来高計画値（ＰＶ）、出来高実績値（ＥＶ）及び投入実績値（ＡＣ）の推移についてのグラフを作成し、予測総コスト（ＥＡＣ）、予測完了時点等を分析します。 本様式は、「(2)　進捗状況表」と合わせて月次の進捗状況の定量分析に用いるものです。次に示す例は、スケジュールが遅れている上にコストも超過し、体制強化や品質向上施策等の対応を至急行うべき状況を表すものです （様式及び記載例） - 図7-9 ＥＶＭ推移グラフ ![](../assets/ds-120-ch07-image13.png) - 表7-10 ＥＶＭ推移グラフの記載項目
記載項目 記載内容
①出来高計画値（ＰＶ） 各月の累計出来高計画値（ＰＶ）をグラフ化する。
②出来高実績値（ＥＶ）

各月の累計出来高実績値（ＥＶ）をグラフ化する。

出来高実績値（ＥＶ）と累計出来高計画値（ＰＶ）の差がスケジュール差異（ＳＶ）となり、グラフ作成時点の作業量前倒し（ＳＶ＞０）／遅延（ＳＶ＜０）を表す。
③投入実績値（ＡＣ）

各月の累計投入実績値（ＡＣ）をグラフ化する。

出来高実績値（ＥＶ）と投入実績値（ＡＣ）の差がコスト差異（ＣＶ）となり、グラフ作成時点の計画時点からの作業コストの増加（ＣＶ＜０）／減少（ＣＶ＞０）を表す。
④予測総コスト（ＥＡＣ）

グラフ作成時点の予測総コストをグラフ化する。

予測総コスト（ＥＡＣ）と計画総コスト（ＢＡＣ）との差が予測総コスト差異（ＶＡＣ）となり、グラフ作成時点の計画時点からの作業総コストの増加／減少を表す。

予測総コスト（ＥＡＣ）と投入実績値（ＡＣ）との差が残コスト（ＥＴＣ）となり、グラフ作成時点の作業完了までにかかるコスト見込みを表す。
⑤予測完了時点

グラフ作成時点の予測完了時点をグラフ化する。

予測完了時点と納期の差が納期からの前倒し／遅延の見込みを示す。
3) 進捗状況分析図 進捗状況表を集計し、スケジュール効率指数（ＳＰＩ）、コスト効率指数(ＣＰＩ)の推移についてのグラフを作成し、スケジュール及びコストの効率の傾向を時系列で分析します。 本様式は、月次の進捗状況の定量分析に用いるものです。次に示す例は、品質悪化が進み、スケジュール変更等の抜本的な見直しが必要な状況を表すものです。 （様式及び記載例） - 図7-10 進捗状況分析図 スケジュール遅延 コストは計画超過 スケジュール遅延 コストは計画内 計画以上の進捗 コストは計画超過 計画以上の進捗
![](../assets/ds-120-ch07-image14.png)

コストは計画内

- スケジュール効率指数（ＳＰＩ） 各月のスケジュール効率指数（ＳＰＩ）をグラフ化する。右に行くほどスケジュール効率が高まっていることを示す。 - コスト効率指数（ＣＰＩ） 各月のコスト効率指数（ＣＰＩ）をグラフ化する。上に行くほどコスト効率が高まっていることを示す。 上図の例では、7/1から作業が始まっています。 ところが、9/3や9/14頃にはSPIもCPIも１を下回りました。つまり、スケジュール面では計画から遅れ、コスト面でも予定を超過（予定よりもコスト効率が低い）した状態となっています。 その後、10/1の段階ではSPIが1に戻りました。つまり、スケジュール面では計画どおりに追いついたということです。一方で、CPIはさらに悪化しています。当初想定以上に要員を投入したのではないかと、読み取ることができます。 4) ＥＶＭの使い方 ここまで説明したように、ＥＶＭ手法はプロジェクトの進捗度合いを管理していくための有用な手段です。端的に言えば、「進んでいるか遅れているか」をわかりやすく表現することが可能です。ただし、計画に描いたＷＢＳそのものに抜け漏れがあったり、潜在的な課題を見過ごしたりしていれば、ＥＶＭ管理上では問題がなさそうなプロジェクトにおいてもある日突然進捗が進まなくなることがあります。また、業務関係者の調整とコンセンサスが不十分であれば、開発終盤にどんでん返しのように手戻りが発生する懸念もあります。 こうしたことから、ＰＪＭＯとしてはＥＶＭの指標値を有力な手掛かりとしつつも、継続的にＷＢＳの妥当性や関係者間の業務調整の状況にも気を配っていくことが肝要です。 ## テストの計画を立てる 【標準ガイドライン関連箇所：第３編第７章第４節6)】 情報システムの設計・開発では、品質の管理が重要であり、そのためには十分なテストが必要だ。ということは、よく耳にすると思います。しかし、そもそも「品質の良い情報システム」とは、どういうものでしょうか？また、設計・開発では様々なテストを行いますが、何が違うのでしょうか？ ここでは、効果的なテストを行いながら品質を管理してより良い情報システムを構築していくためのテストの計画に関する基本的な考え方、知識、ノウハウをご紹介していきます。 ### Ｖ字モデルと発注者・委託先事業者の役割分担を把握する 現在、ウォーターフォール型の開発プロセスではＶ字モデルが一般的です。開発プロセスには各種の国際標準や国内標準もありますが、「標準ガイドライン」の工程定義にのっとると、次のように表現できます。 - 図7-11 標準ガイドラインの定義に則ったソフトウェア開発プロセスのV字モデル ![](../assets/ds-120-ch07-image15.png) 直線的に進んでいく工程を、あえてＶ字にしていることには意味があります。同じ高さにある工程が、それぞれ深く関係しています。例えば、総合テストとは基本設計で定めた要件が充足されているかを確認するテストであり、受入テストとは要件定義との充足性を確認するテストということです。 また、工程によって発注者側（ＰＪＭＯ）と委託先事業者の役割は変わりますし、作業の主体も変わります。このことを非常に大雑把に表すと、次のような図となります。 - 図7-12 発注者と委託先の関わり度合の変化 ![](../assets/ds-120-ch07-image16.png) 多くの人は、図の左側にある要件定義や基本設計は両者で協業して作り上げていく認識を持っています。一方で、図の右側にあるテスト工程については発注者が関与するという認識を持っていないこともあります。 テスト工程において、発注者側にはテスト計画を確認し、テスト実施状況を管理し、テスト結果を評価するという重要な役割があります。特に、総合テスト以降の工程終盤になればなるほど発注者側の関与が重要であり、受入テストは発注者自身が実施するものであることを覚えておいてください。 - 事例7-4 テスト工程の品質が悪いために進捗の遅延、すり抜けバグが多発するプロジェクト

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

ある省において総合テスト工程の進捗遅れが発生しているプロジェクトがありました。そのプロジェクトでは総合テスト工程において、既に完了していた結合テストのすり抜けバグが多発しており、その対応のため進捗遅延を発生させていました。

その原因を事後的に調査したところ、以下の問題が判明しました。

・結合テスト（ITA）の中にも細かな工程（ITA1、ITA2、・・・）が計画されていたものの、それぞれのテスト内容が「基本/詳細設計書の仕様を満たしていることを確認する」という抽象的な観点に留まっており、各テスト工程で確認すべきことが具体化されていない。

・設計書の中にも機能、処理フロー、ユーザーインタフェース、データレイアウトなど様々なドキュメントが含まれているのに、「基本/詳細設計書の仕様を満たしている」という言葉だけなので確認する対象も明確になっていない。

つまり、設計工程の同じ成果物ばかり利用して結合テストのテストシナリオ、テストケースを作成していたことが疑われました。その結果、テスト内容の重複や漏れを多数生み出したことにより、後続工程ですりぬけバグを多発させていたのです。

このような事態を防ぐにはどのようにテストを計画すれば良かったでしょうか。

やみくもにテスト設計を始めるのではなく、まずはテストケースとそのインプットとなる設計書などの成果物及びテスト観点のトレーサビリティを取ることが重要です。具体的には、テスト計画書等において下記のような一覧表形式で整理するのが有効です。

どのテスト工程でどういった成果物をもとに、どんな観点のテストを実施するか、一覧形式に整理することで、適切なテストを適切な工程で実施しているか確認できるため、テスト観点の重複や漏れの発生を防ぎ、品質の低下や進捗遅延のリスクを減少させることができます。

なお、具体的な成果物・テストの観点は各プロジェクトの状況に応じて適宜修正してください。

テスト
工程		 インプット情報 テストの観点
工程 成果物（例）
単体
テスト		 実装 ソースコード プログラム（ソースコード）が開発者の意図どおりに実装できているかを確認する。
・・・ ・・・ ・・・ ・・・
結合
テスト		 詳細設計 処理フロー 正常系だけでなく、エラー・異常系、例外的、縮退などの特殊パターンも含めて、処理の網羅性を確認する。
画面遷移図 様々な画面遷移のパターンを検証する。
・・・ ・・・ ・・・ ・・・
総合
テスト		 基本設計 機能・画面・帳票一覧 様々なシナリオ・データのバリエーションを作成し、それらを組み合わせに沿って情報システムを用いて業務や機能が正常に動作することを確認する。
システム方式設計書 情報システムがユーザ数、データ量、リクエスト数、レスポンス等の性能要件やソフトウェア、ハードウェア、ネットワーク等の障害時の振る舞い、復旧時間、データ復旧ポイント等の可用性要件といった非機能要件を満たしていることを確認する。
・・・ ・・・ ・・・ ・・・
受入
テスト		 要件定義 要件定義書（業務要件） 業務プロセスどおりに業務を行うことが可能かを確認する。
要件定義書（非機能要件） 業務プロセスどおりに情報システムを利用する中で、性能・拡張性や可用性等の非機能要件を満たしていることを確認する。
・・・ ・・・ ・・・ ・・・
### テストのレベルや種類を理解する さて、単体テスト、結合テスト、総合テスト、受入テストの４種類の工程があることを説明しましたが、これらの工程は何が違うのでしょうか。 情報システムのテストは、段階的に進めていきます。個々のプログラムが設計書どおりにできているか？プログラムをつなげて機能としてみたときに、機能の設計を満たしているか？機能同士をつなげてみたときに、要件を満たしているか？要件どおりにできたが、業務が適切に遂行できるか？このように、徐々に確認するレベルを上げていくのです。 これは、まさにＶ字モデルが表していることです。標準ガイドラインで定義しているテスト工程では、次のように整理しています。 - 注記 ユースケースとは、特定の目的を達成するためにアクタ（ユーザ）が実施する手順等を定義したもの。 - 表7-11 テスト工程
テスト
工程		 概要 発注者の関与の仕方
単体テスト アプリケーションを構成する最小の単位で実施するテストであり、主に機能単位で設計通りに動作するかを事業者（プログラマ）が確認する。 事業者がテストの実施主体ではあるが、発注者もテスト計画を確認した上で、実施状況の報告を求め、報告書に記載されている実施結果に不足、誤り等が発生している場合は、課題等を整理し、指摘又は指導を行う。
結合テスト 複数の機能を連携させて動作を確認するテストであり、主にユースケース単位で設計通りに動作するかをテスト担当者が確認する。 （同上）
総合テスト システム全体が設計の通りに動作することを確認するテストであり、ユースケースを組み合わせた一連の業務が行えることを機能面や非機能面の観点からテスト担当者が確認する。 上記に加えて、テストシナリオやテスト評価方法の妥当性を確認し、過不足を指摘することで抜け漏れの無いテストの内容になるように関与する。
受入テスト 納品されるシステムが要件通りに動作することを確認するテストであり、発注者が主体となり、事業者と協力して確認する。

発注者が主体となりテストを実施する。

実際の利用者がテストに参加することで、サービス・業務が円滑に実施できることを確認する。

事前に要件を十分確認できるテストシナリオかを確認し、実際にテストシナリオに基づき情報システムを操作し、テスト結果が要件どおりであることを確認する。
大きな分類は、上記のとおりですが、それぞれのテスト工程の中でも異なる種類のテストを実施します。それらの詳細は、Step.4で触れていきます。 また、テスト工程とは別に、テスト手法の違いがあります。これらの内容は、事業者がテストの実施方法をＰＪＭＯに説明する際に使用されるため、知識として知っておくと理解しやすくなります。 - 表7-12 テストの種類

テスト

手法

 概要
ホワイト
ボックス
テスト

ホワイトボックステストとは、プログラム（ソースコード）の内部構造、論理構造を理解した上でその構造どおりに実装できているかを確認するテストです。中身が見えている状態で行うテストなので、ホワイトボックスと呼んでいます。プログラムを「作る」人の目線でのテストともいえます。

基本的に、上述のテスト工程のうちホワイトボックステストを実施するのは単体テスト工程です。

ホワイトボックステストでは、ソースコードがテストされた割合を示す「カバレッジ（網羅率）」が重要な指標となります。しかし、カバレッジには主として３つのレベルがあるので、どのカバレッジレベルを前提としているかについて注意が必要です。

（参考） カバレッジの種類

　Ｃ０　命令網羅率 ： プログラム内の命令文をどの程度網羅したか

　　　　　　　　　　　　　（単純に、通過したステップ数のカバー率を示す）

　Ｃ１　分岐網羅率 ： プログラム内の分岐をどの程度網羅したか

　　　　　　　　　　　　　（if文であればthenとelseの両方をカバーしたか）

　Ｃ２　条件網羅率 ： プログラム内の条件をどの程度網羅したか

　　　　　　　　　　　　　（if文の条件にandやorがあれば全ての組み合わせ分）

なお、仕様自体の間違いや機能が備わっていないバグなどはホワイトボックステストでは検出できません。また、カバレッジは必ずしも100%を目指す必要はありません。むしろ、100%に近づくほど等比級数的にコストが増大するので、適切にカバレッジを定める必要があります。
ブラック
ボックス
テスト

ブラックボックステストとは、プログラムの内部構造、論理構造に着目するのではなく、プログラムの入出力に着目します。つまり、プログラムの外側から見たときに仕様どおりに動作するかを確認するテストです。中身が見えない状態で行うテストなので、ブラックボックスと呼んでいます。プログラムを「使う」人の目線でのテストともいえます。

基本的に、ホワイトボックステストの完了後に、様々な粒度や観点からブラックボックステストを実施します。
### 非機能要件のテスト工程を詳細に確認する 非機能要件については総合テストで全体的に確認することになりますが、総合テストの工程で初めて非機能要件を確認するわけではありません。単体テスト、結合テストという前工程でも、それぞれの「部品」が非機能要件を満たすことを確認した上で、総合テスト工程でシステム全体としての非機能要件を確認します。 この点を誤解して結合テストにおいて非機能要件の確認を怠ると、総合テストにおいて大きな手戻りが発生することになりかねません。 以下に、結合テストにおける非機能要件のテスト観点の例を示します。非機能要件に係るテストの実施工程の検討材料としてください。 - 表7-13 非機能要件テストの実施観点及び工程例（テスト観点は抜粋）
非機能要件 結合テストにおいて先行的に確認する観点（例）
ユーザビリティ及びアクセシビリティに関する事項

  • 一画面における画面を構成する要素の使い勝手や表示が適切であることを検証する。
性能に関する事項

  • リクエストに対するレスポンスが適切であるか検証する。

  • SQL単体での性能を検証する。
拡張性に関する事項

  • 短時間で情報システムに重い負荷をかけ、情報システムが処理量や長時間稼働等のシステム限界に関する性能や拡張の要件を満たしていることを検証する。
継続性に関する事項

  • システム障害及びエラー発生時の回復機能等が適切に動作することを確認する。
情報セキュリティに関する事項

  • 検索画面一覧等において、SQLインジェクションに対する脆弱性を検討するために、意図的な文言を入力しシステムの挙動を確認する。
### リスクを踏まえてテストの方針を決める テストの計画を立てる以前に、プロジェクトや情報システムの特性を見極めて、どこに深刻なリスクが存在するかを分析します。 例えば、統計システムと請求支払システムでは端数誤差に対するリスク度合いが異なるでしょう。請求支払いシステムでは、１円の誤差でも誤請求として重大な問題になります。このように、リスクを識別することで、初めて機能、性能、セキュリティ、可用性等について当該情報システムがクリアしなければならない重要な要件をあぶり出すことができ、テストを重点的に実施すべき対象を特定できます。 このようなリスク分析は、事業者に丸投げすることはできません。情報システム特性は多様なので、様々な経験・スキル等を持った「人」によってその見え方が異なります。それはデータベースやネットワークという技術要素のことだけでなく、主に過去の障害事例やレアケースを経験しているようなことを指しています。利用者、情報システム運用者、ヘルプデスク等の関係者によって見えてくる風景が異なるので、特に改修案件の場合はこれらの人にヒアリングをして、情報システム特性やリスクを特定してください。 また、プロジェクトの企画段階において、まず必要なテスト工程の期間やリソースは十分確保すべきですが、短期間でリリースする必要があり、かつスケジュールの延伸が許されないプロジェクトにおいては、あらかじめ業務上発生するユースケースに係る機能の重要度や優先度を定めておきます。 重要度、リスクの高い機能については、綿密にテストを行う一方で、重要度やリスクが低い機能についてはエビデンスの取得を省略する、探索的テストを導入するなど、濃淡をつけた対応をすることで、スケジュールが遅延するリスクを軽減することができますので、自らのプロジェクトの状況により検討してください。 ただし、このように重要度やリスクに応じてテスト手法や確認方法に濃淡をつける場合は、どのように濃淡をつけたのかテスト計画書等に明記し、事前に関係者で合意し、事後に振り返りができるようにしてください。 ### テストにおける役割分担と必要な環境を明確にする 他の情報システムと連携を行う場合（特に複数の情報システムがデータを連携する場合）は、役割分担を具体的に定めることがとても重要です。これらを事前に決めておかないと、いざテストを行う時期になってもめることになり、テストの開始が遅れて十分なテストが行えず、本番稼働を行ってから不具合が多発することにもなりかねません。 他の情報システムと連携を行う場合は、次に示す事柄を計画時点で明確にして、関係者間で合意しましょう。 他情報システム連携に関する計画の注意点 - 他情報システム連携に係る機能において不具合が発生した場合、他情報システムにも影響が発生する。 そのような不具合を早期に発見するために、前もって疎通確認しておくことや、優先度や重要度の高いテスト項目からテストを実施することも重要である。なお、「他情報システム連携に関する計画の注意点」に記載された事項は他情報システム連携に限らず、例えばフロントエンドとバックエンドで開発方式や開発チームが異なる場合においても留意すべき事項である。 - 他情報システム連携を確認するテスト（主に総合テスト）の実施主体（誰が音頭を取るか）、各情報システムの窓口となる担当者、計画の作成者を決める。 なお、高度な調整を要する場合は、プロジェクトの対外調整の役目を有するプロジェクト推進管理者が実施することとなる。 - どの段階で何を確認するかを明確にする。例えば、結合試験段階では、サンプルデータを授受し、事前にインタフェースの確認を行う等、段階的に品質を高めていく方法もある。また、連携テストを行う環境の疎通テスト、本番環境の疎通テストはいつ行うか等、環境や観点ごとに漏れなく計画する。 - テストデータは、誰がどの範囲のデータを作成するかを決める。基本的には出し元が作成することになるが、どのようなデータのバリエーションのテストが行いたいかは受け側と調整する必要がある点にも注意する。 - 連携テストはどの環境で行うか。環境ごとの疎通テストの実施有無、実施時期を決める。特に総合テスト以降は、様々なテストが同時並行で行われるため、環境の取決めはしっかり行うことに注意する。 ### テストツールを有効活用する 近年、情報システムの品質を向上させるためのツールは多く登場しています。これらを活用することで、設計・開発の活動を効率的に進めたり、効果的に品質を担保・向上させたりすることができます。事業者とも相談しながら、導入を検討してみてください。 - 表7-14 テストツール
ツールの種類 概要 メリット
ソースコードの静的解析ツール ソースコードから、機械的にコード規模（コード行、スペース行、コメント行等）、複雑度、複製度/重複度、正当性、セキュリティ観点からの好ましくない行、パターン等を機械的に抽出するツール。

静的解析ツールは、ソースコードレビュー（インスペクションとも言います）を助け、コード品質の向上、レビューワの負荷軽減、期間短縮に効果を発揮します。

コード特性を可視化することができることから、全体を俯瞰しながら個々の問題や指摘箇所について検討することができます。このため、プログラマはツール結果を見ながら自分で問題点を検討し、修正することもできます。一人では解決できない場合も、レビュー時にレビューワにツール結果を見せることにより、レビューワも問題の特定が容易となり作業負荷の軽減、時間の短縮にもつながります。
自動テストツール ソフトウェアテストを行うための作業（テストケースの設計、テストの実行と結果の確認、テストの進捗管理、レポートの作成）又はその一部を自動化するツール。 効率良く自動テストを実行するよう、スケジューリングすることで、手動でのテスト工数を削減することが可能です。
継続的インテグレーション コンパイル・テスト・デプロイといったソフトウェア開発のサイクルを頻繁に繰り返し実行する手法。 短期間で品質管理を行うため、問題の早期発見や開発の効率化が可能です。
タスク管理ツール プロジェクト全体のタスクを管理することができ、進捗の見える化や共有化などにより、タスクを管理しやすくするツール。

タスクのツリー構造を定義し、整理することができます。また、タスクの順序や優先度合いを設定し、スケジュール管理をすることができます。

スケジュールや進捗具合を、自動でガントチャートなどのグラフ化で表現でき、直感的に状況を把握することができます。
- 参考7-3 自動テストを導入するメリット・デメリット

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

自動テストを導入するプロジェクトが増えていますが、テストを自動化するに当たってはメリットとデメリットがあるため、それを加味した上で導入する必要があります。

テストを自動化するメリットとしては、テストを自動化することにより人為的なミスを防ぐことができる、テストを高速化し、低コストでシステムの品質を検証できる場合があります。

デメリットとしては、イニシャルコストとして、テストコードやスクリプト等を作るためのコストがかかる点です。さらに、テストコードやスクリプト、環境等を持続的に運用・保守する必要があるため、ランニングコストがかかります。適切な運用・保守ができないとランニングコストが大きくなってしまい、投資に対して充分な効果を得られません。加えて、テスト結果を分析するといった従来の手動テストにはない作業も発生します。自動テストを導入する際には、これらのメリットやデメリットを理解した上で導入を検討することを推奨します。

なお、アジャイル開発を選択する場合は開発の変更容易性を持続させるために、基本的には自動テストを導入することになりますので、これを念頭においてテスト計画を行うことを推奨します。
### テスト計画を作成する 前述のA.～E.で検討した内容をテスト計画書にまとめます。テスト計画書は、単体テスト、結合テスト等のテスト工程ごとに作成します。 以下にその目次と記載内容の例を示します。 - 表7-15 テスト計画書（テスト工程別）目次と記載内容（例）
目次 記載内容
１．はじめに

  • 本書の目的と位置付け
２．テストの概要

  • テストの目的、概要

  • 対象範囲

  • テストスケジュール
３．テストの実施方針

  • テストの観点

  • テスト実施体制、役割分担

  • テスト実施手順

  • テスト環境

  • 工程開始条件、工程終了条件

  • 使用するテスト自動化ツール

  • 成果物一覧
４．管理方針

  • 進捗管理

  • 品質管理

  • 不具合管理
テスト工程別のテスト計画書だけでなく、テスト全体の方針等を定める全体テスト計画書を作成する場合もあります。 全体テスト計画書は、想定されるリスクや重視すべき要件等を踏まえて、テスト全体を効率的かつ効果的に実施するために作成します。 以下にその目次と記載内容の例を示します。 - 表7-16 全体テスト計画書 目次と記載内容（例）
目次 記載内容
１．はじめに

  • 本書の目的と位置付け
２．対象範囲

  • 対象とするテスト工程

  • 全体スケジュール

  • 対象とするシステム
３．テストの実施方針

  • テストの目的、概要

  • テストの観点

  • テストの相互関係

  • テスト環境

  • 工程開始条件、工程終了条件

  • 使用するテスト自動化ツール

  • 成果物一覧
４．管理方針

  • 進捗管理

  • 品質管理

  • 不具合管理
また、各テストを実施する前に、テスト計画書の内容を踏まえて、テストシナリオ、テスト項目、使用するテストデータ、合否判定基準等をテスト実施要領にまとめます。なお、ドキュメントの名称は案件によって異なっていても問題はなく、これらの項目を事前に定義していることが重要です。 ### テスト結果の確認方法を明記する テストケースやテストシナリオの作成時に「エラーを確認する」といった曖昧な確認方法を記載すると、テスト実施者（テスター）によって確認結果がバラつき、テスト作成者が求めていた意図と異なってしまう可能性があります。 そのため、どのテスターでもテストの確認結果にバラつきが出ないようにテストシナリオ、テストケースを準備する必要があります。 以下にテスト結果の確認方法が不明確な例、明確な例を示しますので、テストシナリオやテストケースの作成時の参考にしてください。 テストの確認方法が不明確な例、明確な例 - （不明確な例）テスト結果が正しいことを確認する。 - 注記 具体的なメッセージ等を記載すること。 （明確な例）テストを実行した際に表示されるメッセージが、設計書に記載されているメッセージ(「メッセージID：XX 成功しました」等)と一致すること。 ⇒（解説）具体的な期待結果を記載することが望ましい。 - （不明確な例）エラーが発生することを確認する。 - （明確な例）エラーが発生（エラーID：XX）した場合において、利用者が対応（入力データの修正等）できるようなシステムの仕様になっていることを確認する。 ⇒（解説）エラーが発生することだけでなく、エラーが起きたあとユーザが対応可能であるか確認が必要であるため、明確に記載すること。 ### 取得するテストエビデンスの対象を事前に合意する テストを実施する際に取得するテストエビデンスの対象については、テスト計画段階で受託者と確認方法や承認方法、納品物を関係者の間で合意しておく必要があります。

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

事業者に対し、全てのテストのエビデンス（画面キャプチャ、ログ、テスト実行前及びテスト実行後のデータ等）を取得することを安易に求めていませんか。不要なものまで求めすぎてしまうとコストがかさんでしまいます。

PJMOは自らが担当する案件において、どのようなテストのエビデンスを取得すべきか検討してください。例えば、テストケースどおりにデータを入力して処理結果を確認する場合に、処理途中の画面のコピーを全て取得しなくても、最初と最後の画面（入力と処理結果）を取得するだけで十分なケースもあり得ます。

エビデンスを取得するメリットは、画面や機能に対しどのように不具合が発生しているのか関係者で共有することができる点と、どういった事象が発生していてどう対処したのかが把握できナレッジとしての利用ができる点です。

一方でエビデンスを取得するデメリットは、エビデンス取得のために多くの工数が発生する点、取得したエビデンスを保管するストレージの容量が増える点、エビデンスを管理・整理するためのコストがかかってしまう点です。

これらの点を総合的に考慮してエビデンスを取得する対象を検討し、効率的にテストを進めるようにしましょう。
- 参考7-4 テストのエビデンスを取得するメリット・デメリット