JIS X 0161：2008(ISO/IEC 14764：2006)は、ソフトウェア保守に関する国際規格を、日本工業規格（JIS）として採用したものです。
内容が規格としての書き方となっており、内容を理解のに苦労することもありますが、本書で保守プロセスの内容を分かりやすく説明します。
用語の定義
保守の型と修正依頼
保守には次の５つがあります。
- 是正保守：ソフトウェアのバグを修正する。
- 緊急保守：是正保守を保留にして一時的にシステムを運用状態に保つために行う計画外の修正
- 適応保守：利用環境に合わせて修正する（例：新しいOS対応のための修正。）
- 完全化保守：性能又は保守性を向上させるための。仕様書が存在しない場合やプログラムとの不整合がある場合のリバースエンジニアリングで仕様書を見直すのも完全化保守に入る。
- 予防保守：潜在的な障害の原因を発見して修正する。（例：定期的な点検やログ監視。）
これらのソフトウェア製品への変更提案を「修正依頼」（または「変更依頼」）と言います。
修正依頼は訂正と改良で分類できます。
ソフトウェア保守
ソフトウェア保守「システムへの費用対効果の高い効率的な支援の提供を要求するあらゆる活動」です。
ソフトウェア保守は引渡し前の計画活動も対象に入ります。
保守の目的
ソフトウェア保守の目的は、製品の完全性を維持しつつ修正することです。
保守プロセス
保守プロセスは、６つのアクティビティで構成されています。
- プロセス実装
- 問題分析及び修正の分析
- 修正の実施
- 保守レビュー及び受入れ
- 移行
- 廃棄
①プロセス実装
「プロセス実装」は、この呼び方と意味がかけ離れており分かりにくいのですが、内容としては「保守プロセスで実行されるべき計画及び手続を確立する」です。
つまり、「保守作業を始める前に、やり方を決め、文書化し、運用可能な状態にするしておくこと」です。
- 入力
保守プロセスで使用する材料はこれを使いなさいという説明です。
材料は以下の３つです。
・ソフトウェアの正式版（ベースライン）
・設計書・マニュアル
・既に来ている修正依頼又は問題報告
- タスク
保守をどう進めるかの作戦を決めて、文書にするべきということが書かれています。
属人化を防ぎ、再現可能な状態にするのです。
・保守計画を作る
・バグ受付のルールを作る
・作業員が勝手に変更しない仕組みを作る（構成管理）
- 保守計画・保守手続
保守計画と手続きは次のように分けて進めます。
・保守計画：方針・考え方（どういう体制で、どこまでやるか。またリソースや予算や時間は足りているか。）
・保守手続き：実際の手順（誰が、何を、どうやるか） - 修正依頼・問題報告手続
障害や修正依頼要求を「受けっぱなし」「放置」「記憶頼り」にせず、しっかり管理するという内容です。
具体的には次のようにします。
・番号を振る
・種類分けする
・優先度を決める
・進捗を知らせる - 構成管理
ソフトウェアの修正依頼の際は、版管理、いつ誰が修正したか、修正内容を記録するということです。 - 制御
作成した計画書や手順書は、レビューをする。 - 支援
文書化・品質保証・構成管理などの共通プロセスを使って進めるということです。 - 出力
保守計画書・手順書・マニュアルなどを成果物として列挙しています。
また、出力した成果物は構成管理で管理することが望ましいです。
②問題分析及び修正の分析
問題分析及び修正の分析は、次の流れで実施します。
- 修正依頼・問題報告を分析する。
ここでは不具合なのか改善要望なのかの区分けや、重要度、修正に必要なコスト、リソースを出します。 - 問題を再現又は検証する。
報告のあった問題が本当に再現するか確認します。
検証環境があればそこで試します。 - 修正実施に関する選択肢を用意する。
例えば、①すぐ直す、②一時回避策で対応、③次期リリースで対応、④仕様として受け入れる などの選択肢を用意します。 - 修正依頼・問題報告，結果及び修正実施の選択肢を文書化する。
修正に対する背景や目的、分析結果、テスト方針、判断結果などを文書化しておきます。 - 選択した修正選択肢の承認を得る。
不具合や修正要望が来たときに、すぐ手を動かさず、本当に必要か・どう直すか・影響は何かを整理し、承認をもらってから直すための準備作業するといいことです。
③修正の実施
前の「②問題分析及び修正の分析」では「直すか？どう直すか？」を決めるのに対し、今回の「③修正の実施」は、「決まった内容を正しく直す」ということです。
修正の実施とは承認された修正について、設計 → 実装 → テスト → 文書更新 → 構成管理登録を順序立てて行い、勝手な変更を防ぎながら“正式な修正”として完成させることです。
- 設計
どう変えるか、影響を考慮して進める - 修正
実際に修正する（コード・設定など） - テスト
- 文書を更新
- 構成管理下に正式登録
④保守レビュー及び受入れ
「③修正の実施」で修正が終わったあとに、「ちゃんと直っているか」「約束どおりか」を確認して承認する工程です。
この工程の流れは次の通りです。
- 修正内容をレビューする
- 要求どおりか確認する
- 利用者・顧客が受け入れる
- 正式リリース扱いにする
要求どおり動くか、業務に支障がないか、想定外の問題がないかを確認するのですが、これに必要な判断材料（入力）は次のものを使用します。
- 承認済みの修正依頼・問題報告
- 修正後の成果物（ソフトウェア等）
- テスト結果
- 更新された文書
- 受入れ基準（あらかじめ決めた条件）
⑤移行
「移行」は、前の「④保守レビュー及び受入れ」で受け入れが完了した修正内容を、安全に・計画どおりに本番環境へ反映する工程です。
全体の流れは次の通りです。
- 移行計画を確認・確定
いつ実施するか、誰がやるか、どういう手順でやるか、失敗したらどう戻すか（切り戻し） - 移行準備（環境・手順・関係者）
リリース前に実施すべき内容です。
例えば、本番環境の確認、バックアップ取得、移行手順書の最終確認、関係者への事前連絡などです。 - 移行の実施（リリース）
- 移行結果の確認
- 移行完了の記録
⑥廃止
「廃止」は、サービスの終了をしたシステムやソフトウェアを安全に終わらせる工程です。
- 使っていないはずなのに動いている または、データが残っている
- 責任者が分からないシステムが残る
- セキュリティ更新されないまま放置
この工程では次のものが必要になります。（判断材料に使用）
- 廃止決定が分かるもの
- 現行システムの構成情報（代替システムの情報も含める）
- データ・資産の一覧
- 法令・契約上の要件
全体の流れは次の通りです。
- 廃止計画を立てる
廃止日、対象範囲（全部？一部？）、代替手段、データの扱い、リスクと対策 - 利用者・関係者へ通知
- データ移行
他システムへ移行をする場合は移行作業 - システム停止・撤去
- 文書・構成情報の更新
構成管理情報、運用文書、契約・サポート情報を整理して更新
まとめ
- ソフトウェア保守は予め定義されたプロセスとして実施する必要がある。
- 不具合や修正要望が発生したら、まず「直すべきか・どう直すか」を分析し、影響と選択肢を整理する（問題分析）。
- 問題分析では、技術面だけでなく、費用・期間・人員・リスク・利用者影響まで含めて評価することが重要である。
- 修正は、分析結果と承認に基づいて、設計・実装・テストを順序立てて実施する（修正の実施）。
- 修正作業では、勝手な変更を防ぐため、文書化と構成管理を通じて成果物を正式に管理する。
- 修正後は、技術的に正しいだけでなく、要求どおりであるかを利用者・顧客の視点で確認する（保守レビュー及び受入れ）。
- 受入れが完了した修正のみを、本番環境へ計画的かつ安全に反映する（移行）。
- 移行作業は障害リスクが高いため、事前計画・手順遵守・結果記録を徹底することが求められる。
- システムが不要になった場合でも、責任をもってデータ・資産・利用者影響を整理し、正式に廃止する（廃止）。
コメント