この章で学ぶこと

この章が扱う中分類「システムライフサイクルプロセス」は約197語と、PD-Sのシラバスで最大のボリュームです。用語数の多さに圧倒されそうになりますが、ウォーターフォール開発・Vモデルとテスト工程・ホワイトボックス・ブラックボックステストで扱った基礎知識をベースに、「開発の一連の工程のうち、今どこの話をしているか」という1本の時系列で捉えると、暗記負担が大きく下がります。

システムライフサイクルの基本概念と標準規格

システム及びソフトウェアの一連の工程を体系化した枠組みがシステムライフサイクルプロセスとその中核をなすソフトウェアライフサイクルプロセス（SLCP）で、国際規格JIS X 0170（システムライフサイクルプロセス）とJIS X 0160（ソフトウェアライフサイクルプロセス）で定められています。発注者と受注者が合意形成を行う合意プロセス、組織としてプロジェクトを支援する組織のプロジェクトイネーブリングプロセス、技術面をマネジメントするテクニカルマネジメントプロセス、実際の技術活動を行うテクニカルプロセスという大分類があり、対象システムと接続するインターフェーシングシステム、開発を支援するイネーブリングシステム、他システムと連携する相互運用システムを区別します。

規格をそのまま適用するのではなく、プロジェクトの規模や特性に応じて調整するプロセス修整（Tailoring）を行い、規格にそのまま従う完全適合か、一部を調整する修整適合かを選択します。これらを体系的に扱う専門分野がシステムズエンジニアリングで、組織はプロジェクトごとにばらつきが出ないよう組織の標準プロセスを整備し、継続的なプロセス改善を行います。プロセスの成熟度を評価する規格としてJIS X 33001・JIS X 33020があります。

扱う用語（精選・19語）

• システムライフサイクルプロセス／ソフトウェアライフサイクルプロセス（SLCP）／JIS X 0170／JIS X 0160
• 合意プロセス／組織のプロジェクトイネーブリングプロセス／テクニカルマネジメントプロセス／テクニカルプロセス
• インターフェーシングシステム／イネーブリングシステム／相互運用システム
• プロセス修整（Tailoring）／完全適合／修整適合
• システムズエンジニアリング／組織の標準プロセス／プロセス改善／JIS X 33001／JIS X 33020

要件定義

要件定義の出発点は、システムがどこまでを担うかという機能的な境界の定義です。利用の状況と運用シナリオを洗い出し、外部システムとの接点となるAPI・GUI・インタフェースファイルを明確にしてシステムとサービスとの境界を定めます。システム化の目標と対象範囲（対象業務・対象部署）を確定したら、応答時間などのシステムの性能要件と入出力情報要件を含む性能要件、データベース要件・テスト要件・セキュリティ要件・移行要件・運用要件・保守要件という多面的な要件を定義します。

データの生成・参照・更新・削除の対応関係を整理するCRUDマトリクスや、要件から成果物までの対応関係を保つ双方向のトレーサビリティを使い、要件が実現可能かというシステム設計の実現可能性と運用及び保守の実現可能性を検証します。安全性・信頼性の根拠を示すアシュアランスケースや、要件と成果物の対応を一覧化するトレーサビリティマトリクスも要件定義工程の重要な成果物です。

扱う用語（精選・24語）

• 機能的な境界の定義／利用の状況／運用シナリオ／API／GUI／インタフェースファイル／システムとサービスとの境界
• システム化の目標／対象範囲（対象業務・対象部署）
• システムの性能要件／入出力情報要件／性能要件／データベース要件／テスト要件／セキュリティ要件／移行要件／運用要件／保守要件
• CRUDマトリクス／双方向のトレーサビリティ
• システム設計の実現可能性／運用及び保守の実現可能性／アシュアランスケース／トレーサビリティマトリクス

アーキテクチャ設計とシステム方式設計

要件が固まったら、システムを機能単位に分割するサブシステム分割を行い、それぞれのサブシステム機能仕様定義と、サブシステム間の関係を図示するサブシステム関連図を作成します。提供する機能を明確にするサービスの定義、セキュリティ要件の識別、将来の変更のしやすさを考える保守性の考慮、実現可能かを検証するソフトウェアシステムの実現可能性を進めます。

システムを実現する手段には、ハードウェア・ソフトウェア・サービス・人手による作業（手作業）の組み合わせがあり、どこに何を割り当てるかを決めるハードウェア・ソフトウェア・サービス・手作業の機能分割を行います。ここまでで整理した機能要件と非機能要件をもとに、クラウドサービスの利用などを含めたハードウェア構成の決定、ソフトウェアパッケージの利用などを含めたソフトウェア構成の決定、マイクロサービスアーキテクチャ・サービスメッシュ・サーバレスアーキテクチャといったシステム処理方式の決定を行います。この段階でシステム統合テストの設計にも着手し、設計全体の一貫性と設計標準や方法の適切性を確認します。

扱う用語（精選・16語）

• サブシステム分割／サブシステム機能仕様定義／サブシステム関連図
• サービスの定義／セキュリティ要件の識別／保守性の考慮／ソフトウェアシステムの実現可能性
• ハードウェア・ソフトウェア・サービス・手作業の機能分割／機能要件／非機能要件
• ハードウェア構成の決定（クラウドサービスの利用 など）／ソフトウェア構成の決定（ソフトウェアパッケージの利用 など）／システム処理方式の決定（マイクロサービスアーキテクチャ・サービスメッシュ・サーバレスアーキテクチャ）
• システム統合テストの設計／一貫性／設計標準や方法の適切性

ソフトウェア設計とモジュール分割

システム方式が決まったら、個々のソフトウェア要素の実現可能性を検証しながらソフトウェアユニット分割を進め、ソフトウェア設計書とインタフェース設計を作成します。この段階でソフトウェアユニットのテストの設計とソフトウェア統合テスト仕様も先に定めておき、ソフトウェア要素分割の基準となるプログラム分割基準、設計方法や作業標準の適切性、テストの実現可能性を確認します。

ソフトウェア品質の国際規格として、品質特性を定めるJIS X 25010と利用時の品質を定めるJIS X 25019があり、それぞれ品質特性モデル・利用時品質モデルとして体系化されています。モジュールへの分割手法には論理設計・領域設計・再帰プログラムによるモジュール分割技法があり、モジュールの制御領域・影響領域・再分割というモジュール分割基準、決定表やプログラミングテーブルで仕様化するモジュール仕様の作成を行います。再利用可能な部品としてはコンポーネントウェア・クラスライブラリ・市販ソフトウェアを活用するCOTSがあります。

扱う用語（精選・20語）

• ソフトウェア要素の実現可能性／ソフトウェアユニット分割／ソフトウェア設計書／インタフェース設計
• ソフトウェアユニットのテストの設計／ソフトウェア統合テスト仕様／ソフトウェア要素分割／プログラム分割基準
• 設計方法や作業標準の適切性／テストの実現可能性
• JIS X 25010／JIS X 25019／品質特性モデル／利用時品質モデル
• モジュール分割技法（論理設計・領域設計・再帰プログラム）／モジュール分割基準／モジュール仕様の作成
• コンポーネントウェア／クラスライブラリ／COTS（Commercial Off-The-Shelf）

仕組みを理解する: レビュー技法はなぜこんなに種類があるのか

次節で扱うコードレビュー・テスト仕様レビュー・利用者マニュアルレビューなど多数のレビューは、すべて「誰が」「何を」「どう確認するか」の掛け算で種類が分かれています。同僚同士がお互いの成果物を確認するピアレビュー、設計の妥当性を確認するデザインレビュー、進行役（モデレーター）を立てて形式的に行うインスペクション、作成者が処理の流れを説明しながら参加者が指摘するウォークスルー、複数の関係者が合同で行う共同レビューという具合です。個別に暗記するより「対象（コード／テスト仕様／マニュアル）」×「形式（ピア／デザイン／インスペクション／ウォークスルー）」の2軸で位置づけると整理しやすくなります。

コーディングとレビュー技法

設計が固まったら、あらかじめ定めたコーディング標準に沿って実装します。制御構造を単純化する構造化プログラミング、論理式でルールを記述する論理型プログラミング、複数処理を同時に進める並列処理プログラミング、横断的関心事を分離するアスペクト指向プログラミングというプログラミングパラダイムを使い分けます。

品質確保の手段としては、前節で紹介したコードレビュー・テスト仕様レビュー・利用者マニュアルレビュー・ピアレビュー・デザインレビュー・インスペクション（モデレーターが進行）・ウォークスルー・共同レビューを行い、信頼性・操作性・運用の容易性・技術的整合性・開発の合理性という妥当性評価の項目で評価します。コードレビューはさらに、メトリクス計測・コードインスペクション・ウォークスルー・サイクロマティック複雑度・静的解析・動的テストといった具体的な観点を組み合わせて実施します。成果物が要件までさかのぼって確認できる追跡可能性とテスト網羅性、コーディング方法及び作業標準の適切性、ソフトウェア統合及びテストの実現可能性を継続的に確認します。

扱う用語（精選・20語）

• コーディング標準／構造化プログラミング／論理型プログラミング／並列処理プログラミング／アスペクト指向プログラミング
• コードレビュー／テスト仕様レビュー／利用者マニュアルレビュー／ピアレビュー／デザインレビュー／インスペクション／モデレーター／ウォークスルー／共同レビュー
• 妥当性評価の項目（信頼性・操作性・運用の容易性・技術的整合性・開発の合理性）
• コードレビュー（メトリクス計測・コードインスペクション・ウォークスルー・サイクロマティック複雑度・静的解析・動的テスト）
• 追跡可能性／テスト網羅性／コーディング方法及び作業標準の適切性／ソフトウェア統合及びテストの実現可能性

テストの評価指標

テストを効率化・自動化するテスト自動化を土台に、テストがどれだけ網羅できているかを表すテストの網羅度、単位時間あたりのテスト実施量を表すテスト密度、コード量あたりの欠陥数を表す欠陥密度（バグ密度）で品質を定量的に把握します。網羅の基準には、条件式の真偽をそれぞれ確認する判定条件網羅、複数条件の組み合わせを確認する複数条件網羅、実行経路の組み合わせを確認する経路組合せ網羅があり、これらをまとめて網羅率（カバレージ）と呼びます。コードにわざと欠陥を仕込んでテストの有効性を検証するミューテーションテスト、入力値の境界や領域に着目するドメイン分析テストという高度な技法もあります。

扱う用語（精選・11語）

• テスト自動化／テストの網羅度／テスト密度／欠陥密度（バグ密度）
• 判定条件網羅／複数条件網羅／経路組合せ網羅／網羅率／カバレージ
• ミューテーションテスト／ドメイン分析テスト

統合テストと検証テスト

ソフトウェア単位の統合では、ソフトウェア統合計画で統合する順序（トップダウンテスト・ボトムアップテストなど）を決め、変更が既存機能に影響していないか確認する再帰戦略（回帰戦略）のもとでソフトウェア統合テストを実施します。ソフトウェア検証テストの準備では、トップダウンテスト・ボトムアップテストという統合方式や、テスト専用の実行環境であるテストベッドを整え、ソフトウェア検証テストの評価を経て納入ソフトウェア製品の準備を進めます。

機能テスト・非機能要件テスト・性能テスト・負荷テスト・セキュリティテスト・回帰テスト（リグレッションテスト）などのテスト準備では、想定外の入力を大量に送るファジングも活用し、結果をソフトウェア検証テスト報告書にまとめ、テスト標準及び方法の適切性とソフトウェア検証テストの実現可能性を確認します。

システム全体の統合では、システム統合計画に基づきシステム統合・システム統合テストを実施し、システム統合の評価とシステム統合の共同レビューを行います。システム検証テストの準備では、探索的テストを含む多様なテストの種類を組み合わせ、結果をシステム検証テスト報告書にまとめて期待した結果への適合性を確認し、システム検証テストの実現可能性とレビューを経てシステム検証テストの評価を完了させます。

扱う用語（精選・27語）

• ソフトウェア統合計画／統合する順序／再帰戦略（回帰戦略）／ソフトウェア統合テスト
• ソフトウェア検証テストの準備／トップダウンテスト／ボトムアップテスト／テストベッド／ソフトウェア検証テストの評価
• 納入ソフトウェア製品の準備／テスト準備（機能・非機能要件・性能・負荷・セキュリティ・回帰テスト など）／ファジング
• ソフトウェア検証テスト報告書／テスト標準及び方法の適切性／ソフトウェア検証テストの実現可能性
• システム統合計画／システム統合／システム統合テスト／システム統合の評価／システム統合の共同レビュー
• システム検証テストの準備／テストの種類（機能・非機能要件・性能・負荷・セキュリティ・回帰・探索的テスト など）
• システム検証テスト報告書／期待した結果への適合性／システム検証テストの実現可能性／レビュー／システム検証テストの評価

移行と受け入れ

開発が完了したシステムを本番環境へ移す段階では、導入要件と、プロセス及びデータの移行方法・移行保守の取組方法及びスケジュールを定める移行要件を土台に、全体を一度に切り替える一斉移行と、段階的に切り替える段階移行を使い分けます。実務では、新環境に少量のトラフィックだけ流して安全性を確認するカナリアリリース、新旧環境を並行稼働させて切り替えるブルーグリーンデプロイメントという手法も広く使われます。教育訓練資料・教育訓練システム・e-Learning・Web Based Training・ロジスティクス支援パッケージを含む利用者支援も移行の重要な要素です。

利用者側の確認では、受入れ基準に沿って受入れテストを行い、検収（検収基準・受入れ体制）を経て利害関係者の合意を得ます。教育訓練計画の効果測定には、反応・学習・行動・成果の4段階で評価するカークパトリックの教育効果の4段階モデルが使われます。整備すべき文書としては、運用規程、利用者用文書類、システムに組み込む組込文書類、独立して配布する分離形文書類があります。

最終確認では、要求事項として妥当性確認される要件を満たすか、施設・設備・機器を含む必要とするイネーブリングシステムが揃っているか、各妥当性確認テストを実施するための環境条件が整っているかを確認します。問題が見つかれば不具合の根本原因を特定して是正処置・欠陥修正・改善作業を行い、学んだ教訓の記録として蓄積します。実際の使いやすさを確認する使用性テストや、限定的に使ってもらうソフトウェアの試行利用も移行判断の材料になります。

扱う用語（精選・29語）

• 導入要件／移行要件（プロセス及びデータの移行・移行保守の取組方法及びスケジュール）／一斉移行／段階移行／カナリアリリース／ブルーグリーンデプロイメント
• 利用者支援（教育訓練資料・教育訓練システム・e-Learning・Web Based Training・ロジスティクス支援パッケージ）
• 受入れ基準／受入れテスト／検収／検収基準／受入れ体制／利害関係者の合意
• 教育訓練計画／カークパトリックの教育効果の4段階モデル
• 運用規程／利用者用文書類／組込文書類／分離形文書類
• 妥当性確認される要件（要求事項）／必要とするイネーブリングシステム（施設・設備・機器）／各妥当性確認テストを実施するための環境条件
• 不具合の根本原因／是正処置／欠陥修正／改善作業／学んだ教訓の記録
• 使用性テスト／ソフトウェアの試行利用

運用と保守

本番稼働後は、運用負荷低減のための改善計画のもと、要員などの人的資源とハードウェア・ソフトウェア・データ・ネットワークなどインフラの技術的資源を扱う運用の資源管理、仮想環境の運用管理、ジョブの管理、データ管理、利用者の管理を継続的に行います。AIを活用して運用業務を自動化・効率化するAIOpsや、システムと業務双方の安全を扱う運用安全及び業務安全に関する安全戦略も現代的な運用の重要テーマです。

保守面では、保守手順・保守体制・保守の実現可能性・保守テストを整備し、既存システムの仕様を解析するリバースエンジニアリング、外部委託時の保守契約、保守要件の定義、ハードウェア保守と日常点検を行います。保守の種類には、障害を修正する是正保守、機能を改良する改良保守、障害を未然に防ぐ予防保守、環境変化に対応する適応保守、潜在的な問題を根本的に解消する完全化保守があり、実施場所によって現地で行うオンサイト保守と遠隔で行う遠隔保守に分かれ、これら全体を保守プロセスとして管理します。信頼性を分析する技法としては、故障の木構造で原因を追うFTA、故障モードと影響を分析するFMEA、社会技術システム全体の安全性を分析するSTAMP/STPAなどのシステム信頼性のための解析技法があります。

扱う用語（精選・26語）

• 運用負荷低減のための改善計画／運用の資源管理（人的資源・技術的資源）／仮想環境の運用管理／ジョブの管理／データ管理／利用者の管理
• AIOps／運用安全及び業務安全に関する安全戦略
• 保守手順／保守体制／保守の実現可能性／保守テスト／リバースエンジニアリング／保守契約／保守要件の定義／ハードウェア保守／日常点検
• 是正保守／改良保守／予防保守／適応保守／完全化保守／オンサイト保守／遠隔保守／保守プロセス
• システム信頼性のための解析技法（FTA・FMEA・STAMP/STPA など）

廃棄

システムの役目が終わったら、廃棄計画の立案を行い、廃棄計画などの利用者への通知を経て、新旧環境を並行運用しながら利用者を教育訓練する新旧環境の並行運用と利用者の教育訓練を実施します。関係者全員への廃棄の通知を徹底し、法令や社内規程に従って廃棄関連データの保持とアクセス可能性の確保を行います。開発から廃棄までの全工程を通じて、最初の工程だけでなく最後の工程まで計画的に管理することが、システムライフサイクルプロセスの本質です。

扱う用語（精選・5語）

• 廃棄計画の立案／廃棄計画などの利用者への通知／新旧環境の並行運用と利用者の教育訓練／関係者全員への廃棄の通知／廃棄関連データの保持とアクセス可能性の確保

AIで学ぶ

ここまでの用語は、ChatGPTやClaudeなどの生成AIに以下のプロンプトを投げかけると、比較表つきでさらに深く掘り下げて学習できます。コピーして使ってみましょう。

あなたはプロフェッショナルデジタルスキル（システム）試験の講師です。「システムライフサイクルプロセス」の範囲について、以下の用語を初学者向けに**関連づけながら**説明してください（単体の丸暗記より、用語同士のつながりを理解したほうが記憶に定着しやすく、試験本番で紛らわしい選択肢を見分ける力もつくためです）。用語同士の違いが分かる**比較表**を最後に付けてください。

【基本概念と標準規格】システムライフサイクルプロセス、ソフトウェアライフサイクルプロセス（SLCP）、JIS X 0170、プロセス修整（Tailoring）、システムズエンジニアリング
【要件定義】機能的な境界の定義、システムの性能要件、セキュリティ要件、移行要件、CRUDマトリクス、双方向のトレーサビリティ
【アーキテクチャ設計】サブシステム分割、機能要件、非機能要件、システム処理方式の決定（マイクロサービス・サーバレス）
【ソフトウェア設計とコーディング】モジュール分割技法、コーディング標準、構造化プログラミング、コードレビュー、ピアレビュー、デザインレビュー、インスペクション、ウォークスルー
【テストの評価指標】テストの網羅度、判定条件網羅、複数条件網羅、経路組合せ網羅、カバレージ、ミューテーションテスト
【統合テストと検証テスト】ソフトウェア統合テスト、トップダウンテスト、ボトムアップテスト、システム統合テスト、テストの種類（機能・非機能・性能・負荷・セキュリティ・回帰）
【移行と受け入れ】一斉移行、段階移行、カナリアリリース、ブルーグリーンデプロイメント、受入れテスト、検収
【運用と保守】AIOps、是正保守、改良保守、予防保守、適応保守、完全化保守、FTA、FMEA

AIに用語リストだけを渡すと、辞書をそのまま読み上げるような無機質な説明が返ってくることがあります。このプロンプトが役割（試験の講師）・関連づけの指示・出力形式（比較表）の3つを指定しているのはそれを避けるためです。特にこの章は用語数が多いため、まずは自分が弱いフェーズ（例: テスト工程）だけを抜き出してAIに投げると、消化しやすくなります。

章末チェック

最後に、この章で学んだ知識をアウトプットして定着させましょう。全問に答えたら「答え合わせ」を押してください。

この章のまとめ

この章では、システムライフサイクルの基本概念から要件定義・アーキテクチャ設計・ソフトウェア設計・コーディング・テスト・移行・運用・保守・廃棄までの全工程を、シラバス最大級の197語にわたって学びました。「今どの工程の話か」という時系列で捉えるこの視点は、次章で扱う開発方法論（アジャイル・DevOps）を理解する土台にもなります。

次章では、ウォーターフォールとアジャイルの違いから、DevOps・SREの実践、設計パターン、UI/UX設計までを学びます。→ 第6章 開発方法論とDevOps実践