第二十二回　ISO/IEC 20000-1:2018 箇条8.5「サービスの設計、構築及び移行」の真意を読み解く

　今回は幸福度を向上させるサービスマネジメント＝ISO/IEC20000-1：2018の箇条８．運用における8.5項のサービスの設計、構築及び移行について確認していきます。サービスマネジメントシステムの箇条８ SMSの運用は図１のとおり、幸福度を向上させるサービスマネジメント活動の中でも、顧客向けサービスの提供に関する重要な箇条です。そして箇条8.5は、変更管理、サービスの設計及び移行、そしてリリース及び展開管理の三つのプロセスを軸に、新規または変更・廃止されるサービスを確実にコントロールするための要求事項です。

図１．ISO/IEC20000-1:2018の箇条構成

　この箇条の概要としては、まず変更管理において、すべての変更要求を方針に基づき記録・分類し、リスクや影響を多面的に評価して承認を行う体制を確立します。その上で重大な影響を及ぼす変更については具体的な設計及び移行の計画を立て、権限、資源、依存関係、そして測定可能な意図した成果や受入基準を明確に定めることが求められています。設計段階ではサービスレベルや教育訓練、手順書などの運用基盤となるものを文書化し、続く構築及び移行段階において、それらが受入基準を満たしているかをテスト・検証します。最終的な本番環境への展開はリリース及び展開管理を通じて行い、変更管理と連携した詳細な計画のもとで構成情報のベースラインを確保し、サービスの完全性を維持しながら実施します。リリース完了後は、インシデントの発生状況などからその成否を客観的に分析し、意図した成果の達成状況をステークホルダーに報告するとともに、得られた結論を将来の継続的改善に役立てることが一連のプロセスとして求められています。

目次

1.箇条8.5 サービスの設計、構築及び移行の目的

2.箇条8.5 サービスの設計，構築及び移行を構成する管理プロセスは何を求めているのか

3.箇条8.5 サービスの設計，構築及び移行はどのような活動が求められるのか

4.まとめ

1.箇条8.5 サービスの設計、構築及び移行の目的

　ISO/IEC 20000-1:2018（JIS Q 20000-1:2020）における箇条8.5 サービスの設計、構築及び移行の主な目的は、新規サービスの導入や既存サービスの変更、さらには廃止といった一連のライフサイクル上の変化を組織が定義した要求事項に基づいて計画的に実施し、本番環境への安全な展開と意図した成果の達成を確実にすることにあります。この要求事項はシステムを構築する技術的な手順を指しているのではなく、ビジネスや顧客が求める価値を損なうことなく、サービスマネジメントシステム全体との整合性を保ちながら品質を担保するための統制の仕組みを構築することを狙いとしています。
　まず、変更管理の段階においては、活動の権限と責任を明確にし、必要な資源や他のサービスへの依存関係を事前に特定することで、変更に伴うリスクを最小限に抑えることを目指します。特に測定可能な条件で表現された意図した成果とサービス受入れ基準をあらかじめ定義することは、サービスマネジメント活動の成功を客観的に評価するために不可欠なプロセスです。これにより国際標準規格の準拠以前の状態にありがちな場当たり的な導入を避け、組織内外のステークホルダーが合意した品質基準に基づいてサービスが提供されることを保証します。またサービスの廃止や移管についても同様の厳格さで計画することを求めており、データの保管や廃棄の日付まで管理することで、サービス終了時の情報の安全性や完全性を維持することも重要な目的の一つとなっています。
　設計と移行の段階では、教育訓練やサービスレベルの更新、サービスカタログの改訂といった運用を支えるための仕組みを文書化しておくなど、変更が及ぼす影響を包括的に考慮することが求められます。これは構築されたサービスが実環境で長期的に安定して機能し続けるための基盤を作ることを意図しています。続く構築及び移行の段階では、設計通りに作られているか、そして事前に合意した受入れ基準を満たしているかを検証することで不完全な状態での本番移行・本番サービスを未然に防ぎます。
　最終的なリリース及び展開管理においては、変更管理と密接に連携しながら、サービスの完全性を維持しつつ本番環境へ反映させることを目的としています。展開前に構成情報のベースラインを確保し、リリース後の成否をインシデントの発生状況などから分析することで、失敗の原因を特定し、将来の改善へと繋げるサイクルを確立します。このように、箇条8.5はサービスの変更から展開後の評価に至るまでのプロセスを標準化し、一貫性のある統制を行うことで、サービスの信頼性を高め、顧客に対して継続的に価値を提供し続けることを目的としています。

図２．箇条8.5 サービスの設計，構築及び移行の条項群

この目的を達成するために「サービスの設計，構築及び移行」の管理は、箇条8.5にある3つの下位箇条として、
①8.5.1 変更管理
②8.5.2 サービスの設計及び移行
③8.5.3 リリース及び展開管理　
の管理プロセス＝要求事項を定めています。それぞれの主な目的について触れていきましょう。

(1) 8.5.1 変更管理の目的
　変更管理の主な目的は、サービスやその構成要素に対するあらゆる変更を統制し、サービスへの悪影響やリスクを最小限に抑えつつ、ビジネスにとって有益な変更を円滑に実施することにあります。まず組織としての変更管理方針を決めるなどして、管理対象や優先順位の判断基準を明確にすることで、属人的な判断を排除した客観的な統制が可能になります。変更の要求が記録されると、そのリスクや事業への影響、既存サービスへの影響、さらには情報セキュリティや可用性への潜在的な影響を多面的に評価し、適切な権限者が承認を行うことを求めています。これにより、不要な変更や準備不足による障害を未然に防ぐことにつながります。また承認された変更が計画通りに機能しなかった場合に備え、切り戻しや修正の活動を事前に計画・テストしておくことで、サービスの安定性を担保します。さらに過去の変更実績を定期的に分析し、傾向を把握することで、将来的なトラブルの防止やプロセスの継続的な改善につなげることも重要な目的です。

(2) 8.5.2 サービスの設計及び移行の目的
　サービスの設計及び移行の目的は、変更管理によって承認された新規サービスや重大なサービス変更、あるいは廃止や移管について、具体的な姿を作り上げ、運用の準備を整えることにあります。このプロセスでは顧客の要求事項に基づいた測定可能な意図した成果とサービス受入れ基準なるものをあらかじめ定義することで、完成時の品質を客観的に検証可能にできると考えています。設計段階では、必要な資源や教育訓練、サービスレベルの更新、構成管理との連携などをプロセス横断になるよう網羅的に計画し、運用開始後にサービスを提供する重要な現場が混乱するといった事態を回避させます。構築・テストのステップでは、合意された受入れ基準を満たしているかを厳密に検証し、基準に達しない場合は無理にサービスを展開せず、ステークホルダーと必要な処置を協議するブレーキの役割も果たします。つまり、ビジネスが求める価値を実現するための品質を設計段階から作り込み、本番環境へ引き渡せる状態であることを実証することが、このプロセスの本質的な目的なのです。

(3) 8.5.3 リリース及び展開管理の目的
　リリース及び展開管理の目的は、検証済みのサービスや構成要素を、その完全性を維持しながら安全に本番稼働環境へ反映させることにあります。リリース管理は変更管理と密接に連携し、リリースの種類や頻度を定義した上で、ビジネスへの影響を考慮しながら具体的な展開日や方法、成果物を詳細に計画します。本番環境への展開に先立ち、影響を受ける構成管理の構成品目のベースラインを取得しておけば、万が一の事態に現状復旧できる状態を確保し、システムの整合性を図ることも可能になります。実際の展開作業においては、サービス全体の完全性が損なわれないよう細心の注意を払って実施し、完了後にはその成功や失敗を客観的に評価します。ここで大事なのは、よく失敗の評価は行うのですが、成功の評価をしないことです。成功の評価・分析はとっても大切です。なぜ成功したのか、この再現性を有した取り組みこそ、幸福度を向上させるサービスマネジメントには必要不可欠です。リリース展開作業自体の有効性を測定し、その結果を報告・共有することも怠ってはいけません。これにより変更の最終段階であるユーザー・利用部門への提供を確実なものとし、リリースの品質を継続的に向上させることがこのプロセスの狙いです。
　これらのプロセスは互いに独立しているのではなく、8.5.1で承認し、8.5.2で品質を作り込み、8.5.3で安全に届けるという一つの大きな流れを構成しているのです。

2.箇条8.5 サービスの設計，構築及び移行を構成する管理プロセスは何を求めているのか

(1) 8.5.1 変更管理
　変更管理は、サービスおよびサービスコンポーネントに対するあらゆる変更に対して、安定的な提供を阻害するリスクを抑えつつ円滑に実施するためのより良い統制を求めています。まず組織は変更管理の定めともいえる変更管理方針を文書化しなければなりません。これらはサービスの変更を掌るメンバーの方向性を一致させるものです。この方針では、管理対象となる構成品目の範囲、緊急変更を含むカテゴリ別の取り扱い、そして顧客やサービスに重大な影響を及ぼす変更を客観的に判断するための基準を明確にすることが求められます。次にプロセスの入り口として、サービスの追加・廃止を含むすべての変更要求（RFC＝Request for Change）を記録し、適切に分類する仕組みが必要です。特に影響が大きいと判断された変更については、この後の8.5.2 サービスの設計及び移行のプロセスを適用して、より慎重な計画と設計を行うよう求めています。この具体的な変更活動においては、組織とステークホルダーが変更の承認や優先順位を決定するプロセスを確立しなければなりません。この意思決定ではリスクや事業上の利益、実現可能性やコスト的な影響を総合的に評価することが求められます。また、既存サービス、利用者、キャパシティ・パフォーマンス、サービスの継続性、情報セキュリティといった多面的な潜在的影響も考慮に入れなければなりません。そして承認された変更は、本番環境への展開前に準備と検証を行い、可能な限りテストを重ねることが望ましい姿です。あわせて、変更が失敗した際に元の状態に戻す＝切り戻すための計画を策定し、これも入念にテストしておく必要があります。実施後はその有効性をレビューし、記録されたデータを定期的に分析することで、傾向の把握と将来的な改善につなげる活動が求められています。

(2) 8.5.2 サービスの設計及び移行
　この条項は変更管理によって重大な影響があると判断された新規サービスやサービス変更を具体的にどのように形作り、サービスの稼働環境へと導くべきかを規定しています。プロセスは①計画～②設計～③構築・テストの3段階に分けることができます。まず①計画の段階では、サービス要求事項に基づき、活動の権限と責任、必要な資源となる人、技術、情報、コスト財務、他サービスとの依存関係や受入れ基準などを詳細に定義することが求められます。サービスの廃止が含まれる場合には、データの廃棄やナレッジの引き継ぎといった管理も計画に組み込まなければなりません。また、影響を受ける構成品目（CI＝Configuration Item）が構成管理によって正しく把握されていることも重要ですね。続く②設計の段階では、要求事項を満たすための詳細を文書化します。ここには関係者の責任、必要な資源や教育訓練の要件、新規または改訂されるサービスレベル＝（SLAサービスレベル合意書）、契約書、サービスマネジメントシステムの方針や手順の変更、サービスカタログの更新などが含まれます。ここでは運用のルールや契約関係までを一貫して設計することが求められているのが特徴です。最後の③構築及び移行段階では、設計通りにサービスを構築し、事前に合意したサービス受入れ基準を満たしているかを確認するためのテストを実施します。もし基準を満たさない場合は、そのまま展開するか、追加の処置を行うかをステークホルダーと協議して決定しなければなりません。構築・検証が完了したものは、次のリリース及び展開管理へと引き継がれます。移行完了後には、計画していた成果が実際に達成されたかどうかをステークホルダーに報告し、ライフサイクル上で明確にすることが求められています。

(3) 8.5.3 リリース及び展開管理
　リリース及び展開管理は、承認・構築された変更内容を実際のサービスの稼働環境へ整合性を保ちながら導入する最終工程を規定しています。この条項ではリリースの種類（＝大規模、小規模、緊急など）や頻度、およびそれぞれの具体的な管理方法を定義することを求めています。リリースの計画立案は、必ず変更管理と密接に連携していなければなりません。具体的には、どの変更要求（RFC）に関連するリリースなのか、どの既知の誤りや問題を解決するものなのかを明確にして、展開日、成果物、展開方法を詳細に定めます。すべてのリリースは、事前に定められた受入れ基準に基づき、展開前に改めて承認を受ける必要があります。いよいよサービスの最終段階に位置するものなので、とても重要なステップです。もしテスト結果が基準に満たない場合は、組織とステークホルダーがリスクを評価し、展開の可否を決定するプロセスが必要です。実際の展開作業においては、サービスの整合性を守るための厳格な管理が求められています。展開の直前には、万が一の障害発生時にシステムを復旧できるよう、影響を受ける構成品目（CI）の状態を記録するベースラインを取得しておくことが望まれます。また、リリース作業そのものは、サービスやコンポーネントの完全性を損なわないよう慎重に実施することが義務付けられています。リリース完了後は、その成否を監視し、分析する活動が必要です。この分析には、リリース直後に発生したインシデントの数や内容を含める必要があり、得られた結論は記録し、将来の改善機会としてレビューしなければなりません。最後にリリースの結果や今後のスケジュールといった情報は、運用に関わる関係者に情報として利用できる状態にしておくことが、リリース後のサービス全体の安定のために求められています。

3.箇条8.5 サービスの設計，構築及び移行はどのような活動が求められるのか

(1) 8.5.1 変更管理を満たすための現場活動
　変更管理を形骸化させず現場で機能させるには、まず関係者全員と共有すべき変更管理方針に基づき、管理対象となる構成品目（CI）を構成管理データベース（CMDB）や管理台帳と紐付けることから始めることをお勧めします。現場の担当者は、システムの設定変更、パッチの適用やアプリケーションの改修など、あらかじめ定義されたカテゴリに沿って変更要求（RFC）を起票します。この際に重要なのはサービス停止時間、顧客への影響範囲、情報セキュリティ上のリスク、そして失敗時の切り戻し手順を詳細に記載したアセスメントシートなるものを作成することがより良い活動へと導きます。次にこれらのRFCを評価・承認するための変更諮問委員会（CAB＝Change Advisory Board）を定期的に開催するなど、工夫するとさらに仕組みとして充実してきます。現場リーダーや関連部門の担当者は、個々の変更が他の進行中の変更やリリースと衝突しないか、リソースが確保されているかを多面的に検証します。緊急変更の場合でも、事後承認のルールを徹底し、記録を省略しない体制を整えることも重要です。承認後は計画を周知して、影響を受ける顧客や利用者に「いつ、どのような変更が行われるか」を事前に通知します。変更実施後は、その有効性をレビューし、期待通りの成果が得られたか、あるいは想定外のインシデントが発生しなかったかを確認します。現場では定期的に変更記録を分析し、月間の変更成功率や切り戻し発生数などの傾向を把握します。もし特定の作業で失敗が繰り返されている場合は、手順書の不備やスキル不足を特定し、教育訓練や標準手順）の再定義といった具体的な改善アクションへ繋げるまでを一連の活動として継続します。これらの状況はサービスレポートの重要な要素にもなります。

(2) 8.5.2 サービスの設計及び移行を満たすための現場活動
　この条項が求めるのは、場当たり的な導入を排し、運用の持続性を確保するための徹底した型にはめる活動です。現場では新規サービスや大幅なサービス変更の際、まずサービス設計・移行計画書なるものを策定します。これには、人・技術・資源の割り当てに加え、移行中のサービス依存関係や運用開始後の意図した成果（KPI）を測定可能な形式で定義することが望まれます。廃止を伴う場合は、セキュリティ基準に則ったデータの完全消去を明文化し、関係者の合意を取り付ける活動が不可欠です。設計の段階では、エンジニアは技術仕様だけでなく、サービスレベル合意書（SLA）の案、監視の設計、バックアップ計画、障害復旧手順といった運用要件をドキュメント化します。ここでは、運用の担当者がそのサービスを支えきれるかという観点から、必要な教育や訓練の計画も同時に作成しておくと安心です。まさに力量の確保です。構築・テストの段階では、あらかじめ合意されたサービス受入れ基準をチェックリスト化し、一つひとつの項目を検証していきます。単なる機能テストに留まらず、高負荷時の挙動やセキュリティ診断など、非機能面の検証結果をエビデンスとして記録します。現場で基準を満たせないと判断された場合は、リスクをステークホルダーに報告し、修正を行うか、例外的に受け入れるかを決定する会議体を運営します。移行完了後には、初期障害期間のモニタリング結果を添えて、意図した成果の達成状況をレポートとしてまとめ、正式に定常の運用体制へ引き継ぎを行うことで、設計から運用へのスムーズなバトンタッチを実現します。

(3) 8.5.3 リリース及び展開管理を満たすための現場活動
　リリース及び展開管理の現場活動は、変更管理で承認された成果物を、整合性を保ちながら本番環境へ安全に反映させるデプロイメント（展開）の活動を確立することです。まずリリースの種類（通常、緊急）ごとに作業のテンプレートを整備し、リリースの頻度やリリースパッケージとなる実行ファイルや設定、ドキュメントのセットに関する管理方法を定義します。現場担当者は、個々のリリースがどの変更要求（RFC）や問題解決に対応しているかを紐付け、リリースノートなどを作成して、関係者に対する変更内容の透明性を確保します。展開の直前には、非常に重要なステップとして、影響を受ける構成品目（CI）のベースラインを取得します。これは万が一の障害時に正確に作業前の状態へ戻すための安全な措置です。展開作業自体は、自動化ツールやチェックリストを活用し、サービスの完全性を損なわないよう細心の注意を払って実施することが良いと思います。特に複数のサーバや拠点にまたがる展開では、順序や同期の整合性を保つことがリスク回避につながり現場の重要な役割となります。リリース完了後は、その成否を定量的に監視します。具体的にはリリース後48時間以内のインシデント発生率などを測定し、問題があればその原因を分析して、将来のリリース手順の改善に活かすことが求められます。ここで得られた知見はナレッジベースに記録し、他のメンバーも参照できるようにします。また、サービスデスクなどの関係部署に対し、リリースの完了報告と新しい仕様のレクチャーを行い、利用者からの問い合わせに即座に対応できる現場のサポート体制を完成させるまでが、リリース管理として求められる活動です。

4.まとめ

　ISO/IEC20000-1:2018の箇条８運用の8.5 サービスの設計，構築及び移行はいかがでしたでしょうか。皆さんと確認してきた箇条8.5「サービスの設計，構築及び移行」の真の価値は、単なる技術的な移行プロセスの順守にあるのではありません。その本質は、サービスに関わるすべての人々の安心と信頼を得る基盤を築くことにあります 。ISO/IEC 20000-1におけるこの箇条は、変更管理、設計・移行、リリース・展開という三つのプロセスを軸に、新規または変更・廃止されるサービスを確実に制御することを求めています。これらが一体となって機能することで、場当たり的な導入を排し、ビジネスや顧客が求める価値を損なうことなく、継続的に高い品質を届けることが可能になります。まず、変更管理においては、方針に基づき客観的な統制を行うことで、属人的な判断による不安を解消します。現場の担当者がリスクや影響を多面的にアセスメントし、失敗時の切り戻し手順を事前に計画・テストしておくことは、サービス提供側の心理的安全性を飛躍的に高めます。エンジニアが不条理なトラブル対応に追われることなく、前向きでプロアクティブな改善活動に注力できる環境こそが、サービスを提供する側、そしてサービスを利用し、社会やビジネスを動かしていく側の幸福感へと直結するのです。また設計及び移行のプロセスでは、技術的な仕様のみならず、サービスレベルの更新や教育訓練、運用手順といった運用を支える仕組みを包括的に文書化します。これにより再現性を高め、サービスを受け取る現場の混乱を未然に防ぎ、受入基準に基づいた厳格な検証を通じて、不完全な状態での本番移行というリスクを回避・排除します。さらに最終工程であるリリース及び展開管理では、構成情報のベースラインを確保し、整合性を保ちながら安全に価値を届けます。ここで特筆すべきは、リリースの成否を客観的に評価する際、失敗の分析だけでなく「なぜ成功したのか」という再現性を重視する視点です。成功の要因を特定し、それを組織のナレッジとして共有するポジティブなサイクルは、現場に自信と誇りをもたらし、幸福度を向上させるサービスマネジメントには不可欠な要素となります。この箇条8.5の要求事項を現場の活動として実直に遂行することは、顧客に対しては安定した価値を提供し続け、サービスを提供する側に対しては規律ある統制と誇りを与えることに他なりません。この一連の流れを整えることで、サービスに関わるすべてのステークホルダーの満足度を超えた先の真の幸福度の向上へと結実するのです。次回は、箇条８.運用の『箇条8.6解決及び実現』について、皆さんと考えていきたいと思います。