第10章　テスト・品質とプロジェクト管理

この章のねらい 前章までで「システムをどう作るか（開発モデル・設計）」を学びました。この章は、作ったものが 本当に正しく動くかを確かめる「テスト」と、その品質をチェックする「レビュー・品質管理」、そして開発全体を予定どおり進める「プロジェクト管理・日程管理」を扱います。 ITの知識というより「ものづくりの段取り」の話が中心なので、プログラムが苦手でも得点しやすい分野です。

過去問での出方：経営情報システムの第18問〜第22問あたりで毎年のように顔を出す、いわば"常連"の分野です。出題は3系統。①テスト技法（ブラックボックス／ホワイトボックス、検収テストなど）、 ②見積り・プロジェクト管理（ファンクションポイント法・WBS・EVM）、 ③日程管理の計算（アローダイアグラム＝クリティカルパス）。 ①②は用語の意味を正確に押さえれば正誤判定で取れ、③は手順どおり計算すれば必ず解けるので、ここは「落とさない章」にしたいところです。

10-0　この章の地図

この章は「作ったものを確かめる（テスト）」→「品質をチェックする（レビュー）」→ 「開発全体を管理する（プロジェクト管理）」→「日程を管理する（アローダイアグラム）」という順に進みます。

10-1 テスト技法          … どう動作確認するか（★頻出）
   ├ テストの4段階（単体→結合→システム→受入）
   ├ ブラックボックス（同値・境界値）／ホワイトボックス（命令・分岐網羅）
   └ 結合の進め方（トップダウン／ボトムアップ）
   │
10-2 レビューと品質管理    … 動かす前に人の目で確かめる／バグの収束を見る
   ├ レビュー技法（インスペクション・ウォークスルー）
   └ バグ収束曲線・信頼度成長曲線
   │
10-3 プロジェクト管理      … 開発全体をどう計画・統制するか
   ├ PMBOK・WBS
   └ 工数見積り（ファンクションポイント法／COCOMO）／EVM
   │
10-4 日程管理（計算）      … アローダイアグラムでクリティカルパスを探す（★計算）
   └ 最早結合点時刻・最遅結合点時刻・余裕（スラック）

10-1　テスト技法

テストは「4つの段階」を下から積み上げる

作ったプログラムは、いきなり全体を動かすのではなく、小さい部品から大きなまとまりへと、段階を追って確認していきます。V字モデル（第9章）の右側にあたる部分です。

① 単体テスト（ユニットテスト）   … 部品（モジュール）1つ1つが正しく動くか
        ↓
② 結合テスト（インテグレーション）… 部品どうしをつないで、連携が正しいか
        ↓
③ システムテスト（総合テスト）    … システム全体が要求どおり動くか（性能・負荷も）
        ↓
④ 受入テスト（承認・検収テスト）  … 発注者・利用者が「これで納品OK」と確認する

段階	誰の視点	何を確かめるか
① 単体テスト	開発者	モジュール単体の内部ロジック（→ ホワイトボックス中心）
② 結合テスト	開発者	モジュール間のインタフェース（データの受け渡し）
③ システムテスト	開発者	全体機能・性能・負荷・セキュリティなど（→ 主にブラックボックス）
④ 受入テスト	発注者・利用者	要求仕様を満たすか（→ ブラックボックス。合格＝検収）

💡 覚え方：小さい部品（単体）→つなぐ（結合）→全部（システム）→受け取る（受入）。「単・結・シ・受」と下から上へ積み上げる、と覚えましょう。

受入（承認・検収）テストの急所

受入テストは、外注などで作らせたシステムを発注者・利用者の立場で「要求どおりか」を確かめる、納品前の最終関門です。中身のプログラム構造は見ず、入力と出力（外部仕様）が正しいかを確認する ブラックボックステストが基本になります。

主要機能から徐々に全機能へとテスト範囲を広げ、全機能をチェックするのが適切な進め方。
例外処理の確認では、不正なデータだけでなく適正なデータも加えて、正常時・異常時の両方を見る。
一部を修正したときは、その箇所だけ確認すればよいわけではありません。修正が他の機能を壊していないか（＝デグレードしていないか）まで含め、全体を確認します。

📝 過去問はこう出る（H19 第19問） 外注システムの承認（検収）テストの進め方を問う問題。正解は「主要機能から徐々に全機能へとテスト範囲を広げ、ブラックボックステストとして全機能をチェックする」。「検査仕様書は開発企業に作成を委託してはならない」（言い過ぎ）、「修正個所だけ動けば検収できる」（デグレード見落とし）、「例外処理では適正データを加えてはならない」（異常系だけでは不十分）はいずれも不適切でした。 → H19 第19問

ブラックボックステスト ― 仕様（入出力）に着目

ブラックボックステストは、プログラムの中身（内部構造）を見ないで、「この入力なら、この出力になるはず」という仕様＝入出力の視点で検証する方法です。箱（プログラム）の中を黒く塗りつぶして、外から見える動きだけをチェックするイメージです。

代表的な2つのケース設計技法を押さえます。

技法	考え方	例
同値分割（同値クラス）	入力を「同じ扱いになるグループ」に分け、各グループから代表値を1つ選んでテスト	「点数0〜100が有効」なら、有効グループ（例:50）と無効グループ（例:-10、150）から代表を選ぶ
境界値分析	仕様の境目（境界）の前後を重点的にテスト（バグは境目で起きやすい）	「0以上100以下が有効」なら、-1・0・1・99・100・101をテスト

💡 なぜ境界値？：プログラムのミスは「以上／を超える」「以下／未満」の取り違え、つまり境目で起きやすいからです。「境界値はバグの巣」と覚えておきましょう。

決定表（ディシジョンテーブル）も、ブラックボックスのケース設計でよく使われます。

📝 過去問はこう出る（R02 第20問） 「ブラックボックステストで、考慮すべき条件とその結果の組み合わせを整理するマトリックス」を選ぶ問題。正解は決定表（ディシジョンテーブル）。条件の組み合わせを表にして、テストケースの抜け漏れを防ぎます。ひっかけは、状態遷移を表す「ステートダイアグラム」、実験計画で組合せを間引く「直交表」、経営判断の「ペイオフマトリックス」。 → R02 第20問

ホワイトボックステスト ― 内部構造（ロジック）に着目

ホワイトボックステストは、プログラムの中身（命令・分岐などの内部構造）を見て、「すべての命令を通ったか」「すべての分かれ道を通ったか」を確かめる方法です。主に単体テストで、開発者が使います。

どこまで通せば十分かを示すのが「網羅（カバレッジ）基準」です。ゆるい順に並べます。

網羅基準	意味（何を"1回は通す"か）
命令網羅（ステートメント）	すべての命令を最低1回は実行する
分岐網羅（判定条件網羅／デシジョン）	すべての分岐（IF の真・偽の両方）を最低1回は通る
条件網羅	分岐の中の各条件（AND/OR でつながる個々の判定）の真・偽を通す
複合条件網羅	条件の組み合わせをすべて通す（最も厳密）

      ┌── 命令網羅（ゆるい：命令を1回通せばOK）
  厳しさ│
      │   分岐網羅（IFの真も偽も両方通す）
      ↓
      └── 複合条件網羅（条件の組合せまで全部：最も厳密）

命令網羅は「命令を通った」だけなので、IF の偽の側を通らないことがあり、いちばん甘い。
分岐網羅は真・偽の両方を通すので命令網羅より強い。試験ではこの2つの違いが狙われます。

⚠️ 混同注意：ブラックボックスとホワイトボックス - ブラックボックス＝仕様（入出力）に着目／中身は見ない（同値・境界値・決定表） - ホワイトボックス＝内部構造（命令・分岐）に着目（命令網羅・分岐網羅）「システム仕様の視点からのテスト」＝ブラックボックス、と紐づけて覚えましょう。

📝 過去問はこう出る（H25 第19問） ホワイト／ブラックボックスの特徴を問う正誤判定。正解は「ブラックボックステストは、システム仕様の視点からのテストである」。「ホワイトボックステストは主にテスト段階の後期に行う」は誤り（ホワイトボックスは内部構造を見るので、単体テストなど早期に行う）。 → H25 第19問

結合テストの進め方 ― トップダウンとボトムアップ

複数のモジュールをつないでいく結合テストには、上（呼び出す側）から始めるか、下（呼ばれる側）から始めるかで2つのやり方があります。まだ完成していないモジュールの代役として、 スタブとドライバというダミーを使うのがポイントです。

進め方	順番	使うダミー
トップダウンテスト	上位モジュール（呼び出す側）から下位へ	スタブ（stub）＝まだ無い下位モジュールの代役
ボトムアップテスト	下位モジュール（呼ばれる側）から上位へ	ドライバ（driver）＝まだ無い上位モジュールの代役（下位を呼び出す）

      ┌─────┐
      │ 上位 │  ← トップダウン：上から。下位の代役＝【スタブ】
      └──┬──┘
     ┌───┴───┐
   ┌─┴─┐   ┌─┴─┐
   │下位│   │下位│ ← ボトムアップ：下から。上位の代役＝【ドライバ】
   └───┘   └───┘

⚠️ 混同注意：スタブとドライバ - スタブ＝下位の代役（トップダウンで使う） - ドライバ＝上位の代役（ボトムアップで使う）「上から攻める（トップダウン）→下がまだ無い→スタブ」とセットで覚えると混同しません。

テスト設計の手順

システムテストの設計は、やみくもにケースを作るのではなく、順序立てて進めます。過去問（H21 第18問）では、①対象を分解・構造化し観点と期待値を決めたあと、 ②優先度・重要度を付けて項目を絞り込む → ③手順とテストデータを決める → ④項目とテストケースを対応づける、という流れが問われました（絞り込み→具体化→整理、という自然な順序）。

📝 過去問はこう出る（H21 第18問） テスト設計の作業順序を問う問題。分解・観点設定の後は、 ａ（優先度・重要度で項目を絞り込む）→ ｃ（手順とテストデータを決める）→ ｂ（項目とケースを対応づける） の順が正解でした。まず「何をやるか絞り」、次に「どうやるか決め」、最後に「対応づけて整理する」とイメージすると順序を思い出せます。 → H21 第18問

10-2　レビューと品質管理

レビュー ― 動かす前に「人の目」で確かめる

テストは実際にプログラムを動かして確認しますが、その前段として、 設計書やソースコードを人の目で読んで欠陥を見つけるのがレビューです。早い段階で欠陥を見つけるほど手直しのコストが小さくて済むため、品質管理の要になります。主なレビュー技法を、公式・厳格な順に整理します。

技法	やり方	特徴
インスペクション	モデレータ（進行役）を中心に、作成者・記録役・説明役・レビュー役など役割を明確に分担し、公式・厳格に実施	最も体系化された公式レビュー
ウォークスルー	作成者が主導し、成果物を説明しながら参加者にコメントをもらう	比較的くだけた、作成者中心のレビュー
パスアラウンド（回覧）	成果物を回覧し、各自が個別にチェックして結果を戻す	集まらずにできる
ペアレビュー	作成者と担当者の2名で相互確認	少人数・簡易

📝 過去問はこう出る（H23 第20問） レビュー技法の識別問題。正解は「作成者・進行まとめ役（モデレータ）・記録役・説明役・レビュー役を明確に決め、公式・厳格に行う」＝インスペクション。「作成者が問題点を説明しコメントをもらう」＝ウォークスルー、「2名だけで調べる」＝ペアレビュー、「回覧して個別に調べる」＝パスアラウンド、が区別のポイントでした。 → H23 第20問

💡 覚え方：インスペクション＝役割分担がカッチリ（モデレータがいる公式版）、 ウォークスルー＝作成者が案内する（walk through＝案内して回る）くだけた版。「モデレータ」という言葉が出たらインスペクション、と反応できるようにしておきましょう。

バグ収束曲線 ― バグの「出方」で品質を見る

テストを進めると、時間の経過とともに累積で発見されるバグの数をグラフにできます。これが バグ収束曲線（信頼度成長曲線）です。典型的には、次のようなS字カーブを描きます。

累積バグ数
  │              ┌──────  ← 終盤：新しいバグが出なくなり
  │           ┌─┘             水平に近づく（＝収束＝品質が安定）
  │        ┌─┘
  │     ┌─┘  ← 中盤：どんどんバグが見つかる
  │  ┌─┘
  │_┘  ← 序盤：立ち上がり
  └──────────────────── テスト時間（工数）

曲線が水平に近づいて（寝てきて）、新しいバグがほとんど出なくなった状態を「収束」といいます。これはソフトウェアの信頼性が成長し、品質が安定してきたサインで、テスト終了の目安になります。
このモデルは「信頼度成長曲線」とも呼ばれ、代表的な数式モデルにゴンペルツ曲線・ロジスティック曲線があります。
注意点：曲線が寝てきたからといって必ずしも安全とは限りません。「そもそもテストが十分に行われず、バグが出尽くしていないだけ」で水平になることもあります。曲線はテストの消化状況（テスト項目の消化率）とセットで判断するのが実務の鉄則です。

10-3　プロジェクト管理

PMBOK ― プロジェクト管理の"知識の地図"

PMBOK（ピンボック：Project Management Body of Knowledge）は、プロジェクト管理の 知識体系（ノウハウをまとめた世界標準のガイド）です。米国のPMI（プロジェクトマネジメント協会）がまとめており、プロジェクト管理を複数の知識エリア（スコープ・スケジュール・コスト・品質・資源・リスク・調達・コミュニケーション・ステークホルダー・統合）に整理しています。

覚えておきたい代表的な考え方が「QCD」です。プロジェクトは 品質（Quality）・コスト（Cost）・納期（Delivery）の3つのバランスを取りながら進めます。
PMBOKは「こう考えると漏れがない」というガイドであって、「WBSはこう作れ」という唯一絶対の作成方法を規定するものではない点に注意します（後述の過去問）。

WBS ― 作業を「分解」して洗い出す

WBS（Work Breakdown Structure：作業分解構成図）は、プロジェクトの成果物や作業を、大きなかたまりから小さな作業へと階層的に分解して、やるべきことを漏れなく洗い出す図です。「大きな仕事のままだと見積もれないし管理できない → 小さく割って初めて計画できる」という発想です。

プロジェクト
 ├ 大分類A
 │  ├ 中分類A-1
 │  │   ├ ワークパッケージ（最下位の作業群＝管理の最小単位）
 │  │   └ ワークパッケージ
 │  └ 中分類A-2
 └ 大分類B …

WBSまわりの用語は、R07年第18問でそのまま正誤が問われました。

用語	意味
ワークパッケージ	WBSの最下位レベルの作業群。進捗・コストを管理する最小単位
WBS辞書	WBSの各要素（作業内容・成果物・担当など）を詳細記述した文書
100％ルール	上位の作業を、過不足なく（漏れも重複もなく）下位作業へ展開する原則
ローリングウェーブ計画法	近い作業は詳細に、先の作業は概略にとどめ、時期が来たら詳細化を繰り返す反復計画技法

⚠️ 混同注意（引っかけ頻出） - WBS辞書 ≠ プロジェクト憲章／スコープ記述書：「プロジェクト全体の範囲・成果物・前提・制約を記述した文書」はスコープ記述書等であって、WBS辞書ではありません。 - ローリングウェーブ計画法 ≠ イテレーション：「先の作業は概略にして後で詳細化する反復"計画"技法」は ローリングウェーブ計画法。イテレーションは反復型"開発"の繰り返し単位を指します。 - WBSは担当者の分担ではなく成果物・作業で分解し、計画段階で作ります（実施段階に作る管理資料ではない）。

📝 過去問はこう出る（H22 第22問／R07 第18問） H22は「WBSは成果物を得るのに必要な工程・作業を記述する」が正解。「PMBOKが標準作成方法を規定」「担当者の分担に基づき作成」「実施段階で作成」は誤り。 R07は用語の正誤で、WBS辞書（誤）・ワークパッケージ（正）・100％ルール（正）・イテレーション（誤）の組み合わせが正解でした。 → H22 第22問 ／ R07 第18問

工数見積り ― 開発規模から「人月」を出す

システム開発にどれだけの手間（工数）がかかるかを見積もる手法は、大きく3タイプに分かれます。

分類	考え方	代表的な手法
類推法	過去の類似システムと比較して見積もる	（過去実績ベース）
パラメトリック法（係数モデル法）	規模などの変数を計算式（モデル）に当てはめて算定	ファンクションポイント法、LOC法、COCOMO
ボトムアップ法（積み上げ法）	作業を細分化（WBS等）して個々の工数を積み上げる	標準タスク法

ファンクションポイント法（FP法）

ファンクションポイント法は、プログラムの行数ではなく「機能の数と複雑さ」から規模を見積もる手法です。入力・出力・照会・ファイル・外部インタフェースといった 利用者から見た機能を数え、複雑さで重み付けして点数（ファンクションポイント）を出します。

メリット：プログラム言語に依存せず、設計の早い段階（要件が見えた段階）で見積もれる。
押さえ：FPは「機能規模」を測るパラメトリック法の一手法。「どの見積もり手法でも必ず必要な共通データ」ではありません。

LOC法・COCOMO

LOC法（Lines Of Code法）：プログラムのステップ数（行数）を基に規模を見積もる。変数（行数）からモデルで算定するのでパラメトリック法に分類されます。
COCOMO（ココモ：Constructive Cost Model）：開発規模（ステップ数など）を基に、補正係数を掛けて工数・期間を算定する代表的な係数モデル（パラメトリック法）です。

📝 過去問はこう出る（H29 第18問） 見積もり手法の分類問題。正解は「LOC法は…パラメトリック法に分類される」。「FPはどの手法でも必要な重要データ」（×：FPはパラメトリック法の一手法）、「ボトムアップ法は要件定義段階で見積もる」（×：作業を細分化して積み上げるので詳細が固まった後）、「標準タスク法は類推法」（×：標準タスク法はボトムアップ法）が誤りでした。 → H29 第18問

📝 過去問はこう出る（H28 第16問：CoBRA法） CoBRA法は、少数（おおむね10件程度）の実績データと専門家の知見を組み合わせて開発工数を見積もる手法。工数のばらつきは3点見積り（最小・最頻・最大）に基づく 三角分布で近似します。「規模そのものを見積もる手法」ではない点に注意（規模はFP法など）。 → H28 第16問

EVM ― 進捗とコストをお金の"出来高"で見る

EVM（Earned Value Management：アーンドバリュー・マネジメント）は、プロジェクトの進捗とコストを、すべて「金額（出来高）」に換算して管理する手法です。「予定より進んでいる／遅れている」「予算より安い／高い」を、同じ"円"の物差しで測れるのが強みです。

まず、3つの基本量を押さえます。

用語	読み	意味
PV（Planned Value）	計画価値	その時点までに完了予定だった作業の予算額
EV（Earned Value）	出来高	その時点までに実際に完了した作業の（予算換算）価値
AC（Actual Cost）	実コスト	その作業に実際にかかったコスト

ここから、効率や見通しを計算します。

CPI（コスト効率指数）＝ EV ÷ AC　… 1より小さいとコスト超過（お金を使いすぎ）
SPI（スケジュール効率指数）＝ EV ÷ PV　… 1より小さいと進捗遅れ
EAC（完成時総コスト見積り）＝ BAC ÷ CPI　…（BAC＝完成時総予算）今のコスト効率のまま進んだら、最終的にいくらかかるか

【計算をステップで】完成時総コスト（EAC）を求める（H30 第22問）

BAC（完成時総予算）＝1,200万円、AC（実コスト）＝800万円、EV（出来高）＝600万円。このコスト効率のまま進むと、完成時のコストはいくらか？

コスト効率指数を出す：CPI ＝ EV ÷ AC ＝ 600 ÷ 800 ＝ 0.75 （＝600万円分の仕事をするのに800万円使った。効率が悪い＝1未満）
完成時総コストを出す：EAC ＝ BAC ÷ CPI ＝ 1,200 ÷ 0.75 ＝ 1,600万円
予算1,200万円に対し、この調子だと1,600万円かかる見込み（400万円の超過）。

📝 過去問はこう出る（H30 第22問） 上記の計算そのものが出題され、正解は1,600万円。「CPI＝EV／AC」「EAC＝BAC／CPI」の2式を覚えていれば確実に取れる、得点源の計算問題です。 → H30 第22問

10-4　日程管理（アローダイアグラム）

アローダイアグラムとは

アローダイアグラム（PERT図）は、作業の前後関係（順序）と所要日数を矢印でつないで、プロジェクト全体の日程を図にしたものです（第1章で触れたPERT／CPMの中身がこれです）。これを使って、全体の最短完了日と、その日を決めている一本道＝クリティカルパスを求めます。

○（結合点／ノード）：作業の区切り（イベント）を表す。番号を振る。
→（矢印／アクティビティ）：作業を表す。矢印の上に「作業名」、下に「所要日数」を書く。
ダミー作業（点線の矢印）：所要日数0。「順序の制約だけ」を表す（実際の作業はしない）。

クリティカルパス＝いちばん時間のかかる経路

複数の経路があるとき、所要日数の合計が最も大きい経路がクリティカルパスです。なぜ最大の経路が重要かというと、その経路が遅れると全体が丸ごと遅れるからです。逆に言えば、日程を短縮したいならクリティカルパス上の作業に手を打つ必要があります。

【計算をステップで】最短完了日とクリティカルパスを求める

次のような簡単な例で、解き方の手順をつかみましょう。

        A(3)        C(4)
  ①────────→②────────→④
   \                    ↗
    \ B(2)      D(5)   /
     └────→③────────┘

経路は2本：①→②→④（A→C）と、①→③→④（B→D）。

手順1：各経路の所要日数を合計する - 経路1（A→C）＝ 3 ＋ 4 ＝ 7日 - 経路2（B→D）＝ 2 ＋ 5 ＝ 7日

手順2：合計が最大の経路＝クリティカルパス、その日数＝最短完了日 - この例は両方7日なので、両方がクリティカルパス、最短完了日は7日。

（※上の例はシンプルにしていますが、経路が3本以上でも「全経路の日数を出して最大を選ぶ」だけです。）

最早結合点時刻・最遅結合点時刻・余裕（スラック）

各結合点（○）について、次の2つの時刻を計算します。ここが計算問題の核心です。

用語	意味	計算の向き
最早結合点時刻（最早開始時刻）	その結合点に最も早く到達できる時刻	先頭から後ろへ。合流点では入ってくる経路の"最大値"を採用
最遅結合点時刻（最遅完了時刻）	全体を遅らせずに、そこを最も遅くても出発してよい時刻	最後から前へ（最短完了日から逆算）。分岐点では"最小値"を採用

合流点で最大値をとる理由：早い経路が着いても、遅い経路が着くまで次に進めないから。
クリティカルパス上の結合点は、最早＝最遅になります（＝余裕がない）。
余裕（スラック／フロート）＝最遅結合点時刻 − 最早結合点時刻。この余裕が0の作業をつないだ経路がクリティカルパスです。余裕がある作業は、その日数だけ遅れても全体には影響しません。

💡 覚え方：「最早は前から・合流は大きいほう」「最遅は後ろから・分岐は小さいほう」。そして余裕ゼロの一本道＝クリティカルパス。まずは最早結合点時刻を先頭から順に埋める練習を。

⚠️ つまずきポイント - 合流点で「小さいほう」を選んでしまうミスが定番。遅いほうに合わせないと作業が始められない、と現場をイメージすれば「最大値」を選べます。 - ダミー作業（点線）は所要日数0ですが、順序の制約は効くので経路計算では無視しないこと。

この章のまとめ（試験直前チェック）

☐ テストの4段階＝単体 → 結合 → システム → 受入（検収）（小さい部品から積み上げる）
☐ 受入（検収）テスト＝発注者・利用者視点のブラックボックス。修正時はデグレードも確認
☐ ブラックボックス＝仕様（入出力）に着目（同値分割・境界値分析・決定表）
☐ ホワイトボックス＝内部構造に着目（命令網羅 < 分岐網羅。分岐網羅のほうが強い）、主に単体テスト
☐ 結合：トップダウン＝スタブ（下位の代役）／ボトムアップ＝ドライバ（上位の代役）
☐ レビュー：インスペクション＝モデレータ中心の公式版／ウォークスルー＝作成者主導
☐ バグ収束曲線（信頼度成長曲線）＝S字。水平化＝収束だが、テスト消化率とセットで判断
☐ PMBOK＝管理の知識体系（QCD）。唯一の作成方法を規定するものではない
☐ WBS＝成果物・作業を階層分解（計画段階で作成）。最小単位＝ワークパッケージ、100％ルール
☐ 見積り：FP法・LOC法・COCOMO＝パラメトリック法、標準タスク法＝ボトムアップ、類推法＝過去比較
☐ FP法＝機能の数と複雑さから規模を見積もる（言語非依存・早期に見積もれる）
☐ EVM：CPI＝EV／AC、EAC＝BAC／CPI（CPI<1でコスト超過）
☐ アローダイアグラム：クリティカルパス＝所要日数最大の経路。最早＝前から合流は最大／最遅＝後ろから分岐は最小
☐ 余裕（スラック）＝最遅−最早。余裕ゼロの一本道＝クリティカルパス

この章に対応する主な過去問

年度・問	論点	リンク
H19 第19問	承認（検収）テスト	問題
H21 第18問	システムテストの設計手順	問題
H25 第19問	ホワイトボックス／ブラックボックステスト	問題
R02 第20問	ブラックボックステスト（決定表）	問題
H23 第20問	レビュー技法（インスペクション）	問題
H22 第22問	WBS（作業分解構成）	問題
R07 第18問	WBS（辞書・ワークパッケージ・100％ルール）	問題
H29 第18問	ソフトウェア開発の見積もり手法	問題
H28 第16問	CoBRA法（工数見積り）	問題
H30 第22問	EVMによる完成時総コスト見積もり	問題

次章予告 ▶ 第11章「経営情報管理とセキュリティ」 開発したシステムを"安全に運用する"側面を扱います。情報セキュリティの3要素（機密性・完全性・可用性）、暗号化・認証、リスクマネジメント、そして個人情報保護など、実務でも試験でも重要度の高い論点に進みます。

← 第9章システム開発第11章経営情報システムとIT戦略 →

第10章 テスト・品質とプロジェクト管理

10-0 この章の地図

10-1 テスト技法