対象試験と出題頻度
ソフトウェア保守は、基本情報技術者（FE）・応用情報技術者（AP）で出題されるテーマです。
ISO/IEC 14764で定義された「是正保守」「適応保守」「完全化保守」「予防保守」の4分類を区別できるかが問われます。
それぞれの目的と発生タイミングを正確に押さえれば得点源になります。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「ソフトウェア保守って、バグ修正のこと？それとも機能追加？」と混乱しがちです。実は両方ともソフトウェア保守に含まれます。
ソフトウェア保守（Software Maintenance）とは、一言で言うと
「リリース後のソフトウェアを、不具合修正や環境変化への対応のために修正・改良し続ける活動」
のことです。
イメージとしては、「引き渡し後の自動車の整備」です。
新車を購入したあとも、故障の修理（是正）、新しい燃料規制への対応（適応）、燃費向上のチューニング（完全化）、車検前の予防整備（予防）が必要です。
ソフトウェアもまったく同じで、リリースして終わりではなく、運用しながら手を入れ続けます。
📊 ソフトウェア保守の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Software Maintenance |
| 関連規格 | ISO/IEC 14764（保守の国際規格）、JIS X 0161 |
| 主な工程 | 運用後フェーズ（リリース後） |
| 4つの分類 | 是正保守／適応保守／完全化保守／予防保守 |
解説
ソフトウェアは「作って終わり」ではありません。むしろリリース後のほうが長い時間を過ごします。
一般にシステムのライフサイクルコストの60〜80％は運用・保守フェーズで発生すると言われており、保守をどう設計するかがプロジェクトの成否を左右します。
そこでISO/IEC 14764は、保守活動を目的別に4つに分類し、現場での意思決定をシンプルにしました。
「これはどの保守か？」を判断できれば、対応の優先度や担当者、テスト範囲を素早く決められます。
4分類のマトリクス整理
4つの保守は「いつ手を打つか（事後／事前）」と「何のために行うか（修正／改良）」の2軸で整理できます。
| 修正（Correction） 問題への対処 |
改良（Enhancement） 価値の向上 |
|
|---|---|---|
| 事後対応 （顕在化後） |
是正保守 顕在化した不具合を直す |
適応保守 環境変化に合わせて変更 |
| 事前対応 （潜在段階） |
予防保守 潜在不具合を先回りで除去 |
完全化保守 性能や保守性を向上 |
4分類の詳細
| 分類 | 目的 | 具体例 |
|---|---|---|
| 是正保守 (Corrective) |
発見された不具合の修正 | 本番で発覚したバグ修正、計算誤りの訂正 |
| 適応保守 (Adaptive) |
環境変化への適応 | OSバージョンアップ対応、税率改正、法改正対応 |
| 完全化保守 (Perfective) |
性能・保守性の向上 | 処理速度の改善、コードのリファクタリング、UI改善 |
| 予防保守 (Preventive) |
潜在的な障害の未然防止 | 将来トラブル化しそうな箇所の事前修正、依存ライブラリの先行更新 |
図解：保守タイプの判別フロー
「どの保守か？」を判断するフローチャート
YES（既に発生）
NO（まだ／別目的）
YES
NO
YES
NO（性能/品質向上）
混同しやすい用語との比較
| 用語 | 意味 | 保守との関係 |
|---|---|---|
| 運用 | 日常的な稼働監視・バックアップ等 | 保守と並ぶ運用後フェーズの活動だが、コードに手を入れない点が異なる |
| リファクタリング | 外部仕様を変えずに内部構造を改善 | 完全化保守の代表的な手段 |
| 回帰テスト | 変更後に既存機能が壊れていないか検証 | どの保守でも変更後に必須となるテスト |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 ソフトウェア保守の核心を3行で
・リリース後のソフトを修正・改良し続ける活動の総称
・ISO/IEC 14764で「是正・適応・完全化・予防」の4つに分類される
・「事後／事前」×「修正／改良」のマトリクスで判別する
試験ではこう出る！
FE・APの午前問題では、保守の4分類の「具体例から分類名を当てる」問題が定番です。特に「適応保守」と「完全化保守」の判別が頻出のひっかけポイントです。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R元秋 午前 問49 |
JIS X 0161における完全化保守に該当する事例を選ぶ。 | ・「性能改善のためのプログラム修正」が正解 ・OS変更対応（適応）、バグ修正（是正）がひっかけ |
| AP H29春 午前 問57 |
適応保守の説明として適切なものを選ぶ。 | ・「ハードウェア更新等の環境変化への対応」が正解 ・潜在欠陥の事前修正（予防）が紛れ込む |
| FE H30秋 午前 問49 |
予防保守に該当するものを選ぶ。 | ・「将来発生し得る障害を未然に防ぐ修正」が正解 |
| AP H26秋 午前 問57 |
是正保守の説明として適切なものを選ぶ。 | ・「引渡し後に発見された問題の訂正」が正解 |
📝 IPA試験での出題パターン
パターン1：「具体例から分類を選ぶ」
「税率改正に伴うシステム改修は何保守か？」のように事例が示され、4分類から選ぶ形式。キーワードで即判別可能：「バグ・障害」→是正、「OS・法令・税制」→適応、「性能・効率・保守性」→完全化、「将来・潜在・先回り」→予防。
パターン2：「分類の説明を選ぶ」
「完全化保守の説明として適切なものはどれか」のように分類名が示され、定義文を選ぶ形式。ひっかけは「潜在不具合の修正」（予防）と「性能改善」（完全化）の取り違え。
最大のひっかけは「適応保守」と「完全化保守」です。外部要因（OS・法令）なら適応、内部の質向上なら完全化と覚えてください。深追いは不要、4分類のキーワード対応さえ押さえればOKです。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. JIS X 0161（ISO/IEC 14764）におけるソフトウェア保守の説明として、最も適切なものはどれでしょうか？
- A. 設計工程で作成した仕様書をもとに、プログラムを新規にコーディングしテストを実施する活動を指す。
- B. 引渡し後のソフトウェアに対し、不具合の修正、環境変化への対応、性能改善、潜在問題の予防を目的として行う修正・改良活動を指す。
- C. 稼働中のシステムに対する日常的な監視・バックアップ・ジョブスケジュール管理など、コードに手を加えずに正常稼働を維持する活動を指す。
正解と解説を見る
正解：B
解説：
選択肢Bは、是正・適応・完全化・予防の4分類すべてを包含した正確な定義です。JIS X 0161（ISO/IEC 14764）はまさにこの範囲を「ソフトウェア保守」と定めています。
選択肢Aは「ソフトウェア構築（プログラミング工程）」の説明です。リリース前の活動であり、保守には該当しません。選択肢Cは「システム運用」の説明です。運用は保守と並ぶ運用後フェーズの活動ですが、ソースコードを変更しない点で保守とは区別されます。
よくある質問（FAQ）
Q. 「予防保守」と「完全化保守」はどう見分ければ良いですか？
判断基準は「目的が将来の障害回避か、今の品質向上か」です。予防保守は、現時点では問題が起きていないが将来トラブル化しそうな箇所を先回りで直す活動です。一方、完全化保守は処理速度・使いやすさ・コードの保守性といった「ソフトの質そのもの」を高める活動です。たとえば「使われていない古いライブラリを最新版に置き換える」は予防保守、「同じ処理のレスポンスを2秒から0.5秒に短縮する」は完全化保守となります。
Q. 機能追加（新機能の開発）はソフトウェア保守に含まれますか？
JIS X 0161の定義では、純粋な機能拡張は厳密には「保守」ではなく「新規開発に近い改良」として扱われます。ただし、実務では運用フェーズに入った後の小〜中規模の機能追加を「保守案件」と呼ぶケースが大半です。試験では「適応保守＝環境変化への対応」「完全化保守＝既存機能の品質向上」と位置づけられているため、ゼロからの機能追加は4分類のいずれにも当たらないと割り切ってください。
Q. 保守作業で必ず実施すべきテストは何ですか？
回帰テスト（リグレッションテスト）です。保守はすでに動いているソフトに手を入れる作業なので、変更箇所のテストだけでは不十分です。「修正によって、これまで正常だった他の機能が壊れていないか」を確認するために、影響範囲の既存テストを再実行します。是正・適応・完全化・予防のどの保守でも共通して必要となります。
Q. 保守性を高める設計上の工夫にはどんなものがありますか？
代表的なのはモジュール分割、疎結合化、ドキュメントの整備、自動テストの拡充です。ISO/IEC 25010の品質特性では「保守性（Maintainability）」が独立した品質項目として定義されており、その下位特性として「モジュール性」「再利用性」「解析性」「修正性」「試験性」が挙げられます。設計段階でこれらを意識すると、運用後フェーズのコストを大幅に下げられます。
