ITパスポート 令和4年度 問47：ソフトウェア保守に関する問題

答えは c です。

ソフトウェア保守とは、『お客さんに納品して、実際に使われ始めたあとの“お直し”全般』のこと。バグ直しはもちろん、『法律が変わったからそれに合わせてシステムを直す』のも保守に含まれます。

エアコンを買ったあとの修理・調整・部品交換ぜんぶがアフターサービス、というイメージです。

👉 覚え方：保守＝『納品して使い始めたあとのお直し全部』。

ほかの選択肢：a 障害が出る前に直すのも保守に“含まれる”ので誤り／b 仕様変更も保守に含まれるので誤り／d 納品前の修正は『開発中』の作業なので保守ではない。

なぜこれが正解か

正解は c。ソフトウェア保守は、本番稼働後のシステムに対する修正・改良全般を指す。法律改正への対応（適応保守）も、稼働中システムを環境変化に合わせる保守活動に含まれるため正しい。

各選択肢の解説

• a 潜在不良を障害発生前に修正する＝予防保守。これも保守に含まれるので『含まれない』は誤り。
• b 仕様変更に伴う修正＝完全化保守（機能改良）に含まれる。『含まれない』は誤り。
• d 納入前（開発期間中）の不具合修正は開発工程の作業であり、稼働後の保守ではない。

覚え方・ひっかけ注意

保守＝『本番稼働後（納品後）』が大前提。dの『納入前の修正も保守』は最大のひっかけ（それは開発）。保守の4分類『是正（バグ修正）・適応（環境/法改正対応）・完全化（機能改良）・予防（障害の未然防止）』をすべて“保守”と覚えればa・b・cの正誤を即判定できる。

理論的背景

ソフトウェア保守（Software Maintenance）はISO/IEC 14764（2006年）で「ソフトウェア製品の納入後に、欠陥の修正、性能その他の属性の改善、または変化した環境への適応のために行われるソフトウェアの修正」と定義される。正解cの「法律改正に伴うソフトウェア修正」はこの定義の「変化した環境への適応」に該当し、法的環境の変化に合わせてシステムを修正・維持する「適応保守（Adaptive Maintenance）」に分類される。

ソフトウェア保守の4分類は、ISO/IEC 14764に基づいて以下のように整理される。①是正保守（Corrective Maintenance）：本番運用中のソフトウェアの不具合（バグ）を発見・修正する（選択肢bの後半が部分的に対応）。②適応保守（Adaptive Maintenance）：OS・ハードウェア・法規制などの外部環境変化に適応するための修正（選択肢cがこれに該当）。③完全化保守（Perfective Maintenance）：性能向上・保守性改善・新機能追加など改善目的の修正（仕様変更への対応も含まれる場合がある）。④予防保守（Preventive Maintenance）：将来の障害を防ぐための修正（選択肢aの「潜在不良の発見と事前修正」がこれに対応し、ソフトウェア保守に含まれる）。

実務での使われ方

法改正対応保守の典型例として、消費税率の変更（8%→10%）対応、個人情報保護法・マイナンバー法の改正対応、IFRS（国際財務報告基準）への会計基準変更対応などがある。これらは一定の猶予期間内に本番反映が義務付けられ、複数のシステムに横断的な影響が生じる大規模な適応保守となる場合が多い。

年金・税務・医療保険などの基幹業務システムでは、毎年の法改正サイクルに対応するための「法定改修」が計画的に実施されており、年間のシステム保守コストの大きな割合を占める。企業のシステム担当者にとってもITベンダーにとっても、法改正スケジュールに合わせた品質・納期管理が重要な課題となっている。

選択肢aの「潜在不良の発見・事前修正（予防保守）」は、コードの静的解析ツール（SonarQube・Checkstyle等）や定期的なコードレビューで実施され、「本番障害を起こす前に潜在バグを除去する」活動として本番運用中のシステムに対して適用される正当なソフトウェア保守活動である。

選択肢dの「納入前の開発期間中の不具合修正」は通常「ソフトウェア開発（テスト工程）」の範疇であり、国際標準（ISO/IEC 12207）でもソフトウェアライフサイクルの「開発プロセス」と「保守プロセス」は分離して定義されている。本番リリース前の修正をソフトウェア保守と呼ぶことは標準的な定義から外れる。

試験での位置づけ

ITパスポートのソフトウェア保守分野では、「4種類の保守の内容と該当する事例の対応」が頻出である。特に「法律改正への対応（適応保守）」「将来の障害を予防する修正（予防保守）」がソフトウェア保守に含まれることと、「納入前の修正（開発中のバグ修正）」が保守に含まれないことが重要な判断基準となる。選択肢bの「仕様変更に伴う修正はソフトウェア保守に含まれない」という記述も誤りであり、仕様変更への対応は完全化保守または適応保守として分類され得る。

基本情報技術者（FE）ではソフトウェア保守コストの分布（全開発コストの50〜70%が保守コストという経験則）、保守性（Maintainability）を高める設計原則（モジュール強度・結合度・可読性）、リエンジニアリング（既存システムの近代化）・マイグレーション・リバースエンジニアリングの概念まで問われる。応用情報（AP）ではレガシーシステムのモダナイゼーション戦略（再構築・再利用・廃棄）も重要テーマとなっている。

選択肢の発展補足

選択肢bの「仕様変更に伴う修正はソフトウェア保守に含まれない」は正確でない。仕様変更への対応は、完全化保守（機能追加・改善）の典型的なケースであり、本番運用中のシステムに対して顧客・利用者の要求に基づいて機能を変更・追加する活動はソフトウェア保守の重要な一部である。CMMIやISO/IEC 12207の観点でも、保守フェーズにおける変更要求（Change Request）の管理は確立されたプロセスとして定義されている。

ソフトウェア保守の困難さとして「腐敗設計（Software Rot）」と呼ばれる現象がある。保守修正が繰り返されるにつれてコードの複雑性が増大し、当初の設計思想が失われてバグが増え修正がさらに困難になる悪循環が生じる。これを防ぐためにリファクタリング（振る舞いを変えずに内部構造を改善）や継続的な技術的負債の返済がアジャイル開発では重要視されている。リーンソフトウェア開発の観点では「技術的負債（Technical Debt）」の概念で定量化・可視化し、計画的に解消することが現代的な保守戦略となっている。