ITパスポート 令和5年度 問43：service_managementに関する問題

答えは d です。

ソフトを本番に入れる（導入する）ときは、引っ越しと同じで「先に計画を立てて、関係者みんなでOKをもらってから動く」のが基本です。動いている本番に手を加えるなら、なおさら事前に段取りと同意が必要です。

👉 覚え方：「導入は“先に計画＆合意”→それから作業」。

ほかの選択肢：

• a「計画書を作らず急いで入れる」→ 段取りなしはダメ。
• b「作業してから計画書を作る」→ 順番が逆。
• c「合意は導入後でいい」→ これも順番が逆。

“事前に計画して合意してから実施”のdだけが正しいやり方です。

なぜこれが正解か

正解は d（dのみ）。ソフトウェア導入は「導入計画書を作成 → 関係者の合意 → 導入作業の実施 → 導入報告書」が原則の順序。dは本番稼働中ソフトへの機能追加でも、計画書作成→合意→実施と正しい順を踏んでいる。

各記述の解説

• a 誤り：新規開発でも導入計画書は必要。「作成せず速やかに導入」は手順省略でリスク管理ができない。
• b 誤り：計画書は作業“後”ではなく“前”に作成・合意するもの。実施後にまとめて作るのは順序が逆。
• c 誤り：自社開発・社内影響でも、合意は導入“前”に得る。「合意は導入後」は不可。
• d 正しい：事前に計画書を作り合意を得てから作業を実施。

覚え方・ひっかけ注意

キーワードは 「計画と合意は必ず事前」。「速やかに」「導入後に合意」という言い回しは順序を入れ替えた誤りの定番パターン。影響範囲が社内に限られても省略可にはならない点に注意。

理論的背景

ソフトウェア導入（リリース管理・変更管理）は、ITサービスマネジメント（ITSM）の重要なプロセスの一つであり、共通フレーム（SLCP：Software Life Cycle Process）においても移行プロセスとして明示的に定義されている。国際標準ISO/IEC 20000（ITSM標準規格）でも「変更管理」と「リリース及び展開管理」が独立したプロセスとして要求事項が定められており、（1）変更要求の評価・承認、（2）リリース計画の策定と合意、（3）実施・展開、（4）結果の評価という順序が規定されている。

「導入計画書の作成→関係者の合意→導入作業の実施」という順序が正しいことの論理的根拠は、リスクマネジメントにある。導入計画書には「何を変更するか・いつ実施するか・影響範囲・実施手順・ロールバック（切り戻し）手順・テスト計画・責任者・判断基準」が記述され、これらを事前に関係者全員で確認・合意することで、実施時のリスクを最小化し、問題発生時の対応を迅速化できる。

実務での使われ方

ITILの変更管理プロセスでは、本番環境への変更はすべて変更要求（RFC：Request for Change）として起票され、変更諮問委員会（CAB：Change Advisory Board）または緊急変更委員会（ECAB）の承認を経てから実施される。本番稼働中システムへの機能追加は「標準変更（事前承認済みの低リスク変更）」「通常変更（CAB審査が必要な変更）」「緊急変更（ECAB審査）」に分類され、リスクに応じた承認プロセスが適用される。

特に「本番稼働中のソフトウェアへの機能追加」（選択肢d）は、稼働中システムに手を加えるため、既存機能への影響（デグレード）リスクが高く、変更管理の手順が厳格に適用される。実施前に影響範囲アセスメント・テスト計画（回帰テスト含む）・ロールバック計画の三点セットを確立することが実務の鉄則である。データベース移行・設定変更・バージョンアップなど多くの変更失敗事例が「計画書なし・合意なし・ロールバック手順なし」から生じている。

近年のDevOps・CI/CD文脈では、変更の頻度が高まる（1日数回のデプロイ）ことでCABによる逐一審査が現実的でなくなるため、「自動化されたテスト・デプロイパイプラインによる品質ゲート」がCABの代替として機能する設計が広まっている。この場合も「自動承認ロジックの事前設計・合意」が計画書と合意に相当し、本問の原則は形を変えて維持されている。

試験での位置づけ

ITパスポートのマネジメント系・サービスマネジメント分野では、ソフトウェア導入・変更管理・リリース管理のプロセス順序に関する問題が繰り返し出題される。本問のような「各記述が正しいか誤りかを全部判定してから正しいものの組合せを選ぶ」形式は、一つでも見落とすと誤答するため、各選択肢を「いつ何をするか」の順序に着目して丁寧に判断することが重要である。

本問で問われている「計画書の作成と合意は事前に行う」という原則は、PDCA（Plan-Do-Check-Act）サイクルのPlan（計画）段階の重要性と本質的に同じ考え方である。「速やかに・事後に」という表現が誤答の選択肢に含まれる場合、計画・合意タイミングを後ろにずらす意味なので誤りと判断できる。

選択肢の発展補足

選択肢a（新規開発の場合、導入計画書を作成せず速やかに導入）が誤りの根拠：新規開発であっても、初めて本番環境に展開するシステムは既存業務・インフラ・データへの影響を持つ。影響範囲の特定・展開手順の確立・利害関係者への事前周知なしの展開は、予期しないサービス停止・データ消失のリスクを持つ。「新規だから計画不要」という論理は成立しない。

選択肢b（作業後に導入計画書を作成・合意）が誤りの根拠：導入後に計画書を作成することは「後付け正当化」であり、実施前のリスク評価・合意取得というリスクマネジメントの機能を完全に失う。さらにITIL・ISO 20000・共通フレームのいずれにも「事後に計画書を作成する」手順は存在しない。

選択肢c（自社開発・社内影響のみの場合、合意は導入後でよい）が誤りの根拠：影響範囲が社内に限られても、社内の業務部門・IT部門・経営陣は「いつ・何が変わるか」を事前に知る権利と必要性がある。合意を事後に取ることは承認権限者を無視した独断実施であり、ITガバナンスの観点から不適切である。