Redmine
インシデントを別の角度から定義する
ちょっと脇道に逸れますが、ITILは「サービスカタログ」を作っておくことを提案しています。「サービスカタログ」とは、現在運用しているすべての業務を記述した一覧のことです。特に書式は決まっていないのですが、「誰が」「誰に」「いつ」「何を」「どのくらい」「何を使って」「関係者は」「どれだけ重要か」といったことまで突っ込んで書いておくと、ビジネスの輪郭がはっきりします。また、サービスプロバイダと顧客の間で約束するサービスの提供レベルのことを「サービスレベル」と言い、これを文書化したものを「SLA」（サービスレベルアグリーメント）と言います。この「サービスカタログ」に載っており、かつ「SLA」で定義されたサービスは標準的な「要求実現」のプロセスとなります。簡単に言えば、「要求実現」は“確実に提供すべきサービス”のこと。当たり前のようにできなければビジネスが成り立たないものです。
では、「サービスカタログ」や「SLA」に載っていない標準外の案件はどうするか？ そういったものは、インシデントとして処理されることになるのです。
構成管理
構成管理とは、サービスを運営するために必要な構成要素（ヒト、モノ、ルールなど）を可視化して管理するプロセスです。サービスを構成する要素のことを、ITILではCI（Configuration Item）、構成アイテムと呼びます。「そんなもの、会社の業務が回っていれば必要ないんじゃないの？」と思われるかもしれませんが、例えば新規事業を立ち上げる時に、CIが抜けてしまい、必要な人員が足りなかったりしたら、どうなるでしょうか。恐らく、現場は大混乱に陥るでしょう。あるいは、何かトラブルがあった時、例えば特殊なプログラムを走らせることで急場をしのげるかもしれません（ワークアラウンド・暫定対応）。しかし、サービスの規模が大きい場合、そのプログラムを書ける人が一人しかいなかったら、やはり業務は滞ってしまうでしょう。ならばあらかじめそのプログラムをネットワークに上げておき、誰でも使えるようにしておく必要があるかもしれません。
このように、構成管理は何か新しいサービスを追加したり変更する時に、現状を把握する基盤となるのです。また、ソフトウェアライセンスの有効期限を一元管理したりするのも、構成管理の範疇になります。
構成管理については、Excelなどで管理簿を作れば事足ります。しかし、役割は非常に重要であると言えるでしょう。
・構成管理の活動
変更管理
ITILにおいて、新規サービス（業務）を追加したり、既存サービス（業務）の変更を行うプロセスを変更管理と言います。これはサービスそのものの変更だけでなく、サービスに必要なヒト・モノ・ルール・プロセスなどの構成アイテム（CI）を追加・変更・削除するためのプロセスでもあります。「インシデント」や「問題」を解決する、あるいは起こらないようにするための変更が、変更管理のトリガーになります（もちろん、サービスストラテジが要求してくる変更も扱います）。
・変更管理の活動
適切な変更管理プロセスを導入することで、こうしたリスクを事前に把握し、計画的に対処することができるのです。
複雑化するIT環境では、変更管理の重要性はますます高まっています。注目されている理由を解説します。
多くの企業がデジタルトランスフォーメーション（DX）を推進する中、システム環境は急速に変化しています。オンプレミスからクラウドへの移行、マイクロサービスアーキテクチャの採用など、IT環境が複雑化する今だからこそ、変更管理の重要性が高まっているのです。
クラウド環境では変更のスピードが格段に上がります。これまで数日かかっていたサーバー増設が数分で完了するなど、変更の敷居が低くなった反面、管理が行き届かなければ環境が無秩序に変化してしまうリスクも高まっています。まるで交通量が増えた道路で信号機がないような状況と言えるかもしれません。変更管理は、このような環境でも安全に前進するための「交通ルール」の役割を果たすのです。
サイバー攻撃の脅威が増大する中、セキュリティパッチの適用など定期的な変更が不可欠になっています。しかし、パッチ適用によって既存のアプリケーションが動作しなくなるというリスクもあります。変更管理プロセスを通じて、セキュリティと安定性のバランスを取ることが重要です。
たとえば、あるセキュリティパッチを適用する際に、事前の検証環境での確認を怠った結果、基幹システムが停止し、数時間業務が滞ったというケースも見られます。適切な変更管理があれば、こうしたリスクを事前に特定し、対策を講じることができるでしょう。
変更管理は、プロジェクト管理やリリース管理と混同されることがありますが、それぞれ異なる目的を持っています。プロジェクト管理が「新たな価値を創出するための活動の管理」であるのに対し、変更管理は「既存環境への変更を安全に実施するための管理」です。また、リリース管理は複数の変更をまとめて計画・実施するプロセスであり、変更管理の一部と捉えることができます。
これらの違いを理解することで、それぞれの役割が明確になり、組織内での責任分担も円滑になるでしょう。たとえば、新システムの開発はプロジェクト管理の領域ですが、そのシステムを本番環境にデプロイする際には変更管理のプロセスが適用されるというように、場面に応じた適切な管理手法の選択が可能になります。
構成管理のメリットを４つ紹介します。
構成管理とは、ITシステムを構成する要素を把握し、適切に管理する重要な取り組みです。複雑化するシステムにおいて、ある要素の変更が予期せぬ影響を及ぼし、大きなトラブルを引き起こす可能性があります。例えば、OSのアップデートが周辺機器との不適合を引き起こし、業務システムが停止するケースがあります。
このようなリスクを回避するため、構成管理ツールの活用が不可欠です。これらのツールを用いることで、システムのライフサイクル全体を適切に管理し、安定稼働を実現できます。最近では、IT資産の相関関係を可視化し、変更による影響範囲を予測できる統合運用管理ツールが注目を集めています。
構成管理とバージョン管理は、しばしば混同されがちですが、実は異なる概念です。バージョン管理がソフトウェアの変更履歴を追跡するのに対し、構成管理はシステム全体の構成要素を包括的に管理します。例えば、料理のレシピと食材の管理を考えてみましょう。バージョン管理はレシピの改訂履歴を追うことに似ていますが、構成管理は食材の在庫、調理器具、さらには調理プロセス全体を把握することに相当します。
構成管理は、作業領域管理やビルド/リリース管理など、より広範な要素を含んでいます。これにより、システムの一貫性が保たれ、他の管理業務も円滑になります。例えば、問題が発生した際に、どの構成要素が影響しているかを迅速に特定できるため、トラブルシューティングが効率化されます。
また、構成管理ツールを活用することで、チームメンバーに適切な構成を提供し続けることが可能になります。これは、大規模なプロジェクトでの協業をスムーズにし、品質管理や変更管理などの関連業務の効率を大幅に向上させます。
構成管理は、セキュリティ強化の要となります。システムの構成要素を正確に把握することで、潜在的なセキュリティリスクを特定し、適切な対策を講じることができるのです。例えば、家の鍵を管理するように、構成管理はシステムの「鍵」を適切に管理し、不正アクセスを防ぎます。
変更履歴管理により、不正な変更を迅速に検知し対応できます。また、継続的な監視はコンプライアンス違反の早期発見を可能にします。構成管理ツールを活用すれば、OSやセキュリティソフトのアップデートに伴う問題を防ぎ、セキュリティ対策を強化できます。
IT資産管理ツールは、不正アクセスの検知と遮断、一斉アップデートなどを実行可能にし、企業のセキュリティ体制を強化します。このように、構成管理はセキュリティリスクの低減に大きく貢献し、企業の安全な運営に欠かせない要素となっています。
システムの設定変更を効率化することは、構成管理の重要な利点の一つです。従来の手動による設定変更は、まるで複雑な迷路を一つずつ確認しながら進むようなもの。時間がかかり、ミスも起こりやすい状況でした。しかし、構成管理ツールを導入することで、この過程が大幅に改善されます。
例えば、複数のサーバーに同じ設定変更を適用する場合、構成管理ツールを使えば一括で変更を行えます。これは、料理のレシピを一度変更すれば、全ての調理場で同じ味が再現できるようなものです。
さらに、変更履歴の管理も容易になります。問題が発生した際に、どの変更が原因かを迅速に特定し、元の状態に戻すことができるのです。これにより、システムのダウンタイムを最小限に抑え、ビジネスの継続性を確保できます。
構成管理は大切だと分かってはいるものの、日々の業務に忙殺され、構成管理が進められていないと言う場合も多いかもしれません。そんな時は構成管理を自動化するサービスを活用することをおすすめします。
作業フローの徹底や作業状況の共有は、構成管理の中でも大切な要素でありながら、つい実施が抜けてしまう取り組みでもあります。
作業フローの自動的により指定された進捗状況を達成した際には、申請や承認が行われ、承認者や決裁者に通知されます。作業フローは自動化されているため、作業を進めるだけでコンプライアンスを順守したルールの徹底が可能です。
作業状況の確認も自動化できる構成管理の1つです。ガントチャートを用いて、プロジェクト管理者だけでなくメンバー同士でも作業実施状況や、誰がどのプロジェクトを担当しているか、期間はいつまでなのか、進捗状況に問題はないのかを図で確認することができます。
視覚的に状況の確認ができるため、リソース配分に偏りがある業務や、進捗が滞っているプロジェクトを早期発見できます。
さらに、実績のある作業履歴やメールのデータをまとめることで、課題点や対応策を検討する材料にもなります。
安定稼働や業務の効率化、リスクの低減を目指す際には構成管理が重要になってきます。
構成管理を実施するためにはどのようなステップを踏めば良いのか解説します。
まずは環境にどのような構成アイテムがあるかを理解することが大切です。構成アイテムの定期的な確認は、不足しているアイテムの早期発見に繋がります。
特にシステム上のリソースの枯渇はサーバの安定稼働に影響が出るリスクを伴いますので定期的に確認が必要です。
ハードウェアの保守期限や証明書の有効期限はいつまでか、最新バージョンがリリースされた際には、最新バージョンと現行バージョンの差異は何か、を確認し、必要に応じて対応できる体制を整えましょう。
有効期限の更新方法や、最新バージョンへのアップデート手順を手順書にまとめることで、次回作業する際に手順を確認する工数を削減できるため業務の効率化に繋がります。作業フローに沿って申請、承認が降りないと作業を実施できない取り決めにすることで誤った変更操作を防げるでしょう。
環境の要件を構成アイテムが満たしているか評価し、必要に応じてサーバを増設する、バージョンアップするといった構成アイテムの変更を実施します。構成アイテムの利点や欠点を評価すれば、環境の課題が見えてくるため、環境をブラッシュアップできるでしょう。
構成管理ツールを導入すると、構成アイテムの管理が容易になります。さらにアップデートの自動化やトラブル発生時の迅速な対応も可能になるツールもあります。構成管理ツールを活用することで、業務を効率化し、システムの安定稼働を図りましょう。
構成管理ツールには様々な種類があり、製品によって仕様や機能が異なるため、導入目的や運用方法を検討した上で、自社に最適な構成管理ツールを選択する必要があります。
当社が提供するSHERPA SUITEは検知・通知系ソリューションと管理系ソリューションから成るOSS（オープンソースソフトウェア）です。Redmineをベースに開発されており、アラート制御ツール、インシデント管理ツール、ジョブ管理ツールなどでシステム運用管理を自動化できます。
構成管理機能はありませんが、関連する様々な業務の自動化を実現できます。
作業状況の確認や、作業フローの徹底が可能であり、業務の安定稼働、効率化を助けます。また問い合わせのメールが来た際に、内容を解析し該当する各担当者への振り分けが可能です。担当者はマイページよりタスクを確認できるため、作業の重複や作業ミスの削減にも繋がります。
「SHERPA SUITE」の詳細はこちらからご確認ください。
変更管理を効果的に実施するための7つのステップをご紹介します。これらのプロセスを段階的に実施することで、変更に伴うリスクを最小化できます。
変更管理の第一歩は、変更要求を正式に受け付け、記録することです。「誰が」「いつ」「どのような変更を」「なぜ」要求したのかを明確に文書化します。口頭での依頼や非公式なメールのやり取りだけでは、後々トラブルの原因になりかねません。
変更要求には、緊急度や優先度も明記し、関係者間で認識を統一することが重要です。また、変更の目的やビジネス上のメリットも明確にすることで、その後の承認プロセスがスムーズになります。
効率的な変更管理のためには、チケットシステムの活用が効果的です。JiraやServiceNowなどのツールを使って、変更要求の受付から完了までを一元管理することができます。これにより、変更履歴の追跡や関係者間のコミュニケーションが容易になります。
チケットには最低限、以下の情報を含めるようにしましょう：
変更要求を受け付けたら、次はその変更がもたらす影響を多角的に分析します。技術的な側面だけでなく、ビジネスへの影響も考慮することが重要です。
影響度分析では、以下のような評価指標を用いることが一般的です：
ビジネス影響度
技術影響度
これらの指標に基づいて変更の影響レベルを「低」「中」「高」などに分類し、承認レベルやテスト範囲を決定します。影響度が高いほど、より厳格な承認プロセスと広範なテストが必要になるでしょう。
大規模な変更や高リスクの変更については、CAB（Change Advisory Board：変更諮問委員会）による審査と承認が必要です。CABは、IT部門だけでなく、ビジネス部門の代表者も含めた横断的なメンバーで構成されるのが理想的です。
CABの会議では、変更の必要性、リスク、対策などについて多角的に議論し、実施の可否を判断します。緊急の変更については、簡略化されたプロセス（緊急CABなど）を用意しておくことも重要です。定期的な会議と明確な承認基準を設けることで、変更の品質と一貫性を確保できるでしょう。
承認された変更は、具体的な実装計画を立てて実施します。この段階では、変更手順の詳細化、リソースの確保、スケジュールの調整などを行います。
変更実施には最適なタイミング（リリースウィンドウ）を選ぶことが重要です。システム利用が少ない深夜や週末などが一般的ですが、ビジネスの特性に応じて適切な時間帯を設定しましょう。
また、万が一の場合に備えたバックアウトプラン（変更を元に戻す手順）も必ず用意します。これは、変更がシステムに予期せぬ影響を及ぼした場合の「安全ネット」となります。具体的な判断基準（いつ、どのような状況でバックアウトを決断するか）も明確にしておくことが重要です。
計画に基づいて実際に変更を実施します。この段階では、変更手順書に従って作業を進め、各ステップでのチェックポイントを設けることが重要です。また、変更作業の様子をリアルタイムで記録し、問題が発生した場合に原因特定ができるようにしておきましょう。
自動化ツールやCI/CDパイプラインを活用することで、人為的ミスを減らし、変更プロセスの効率化と標準化を図ることができます。ただし、自動化を導入する際も、十分なテストと検証を行うことが前提です。
変更実施後は、システムが正常に動作しているかを継続的に監視します。特に変更直後は障害発生リスクが高いため、通常より注意深く監視することが重要です。監視ツールを活用して、パフォーマンスやエラー率などの指標を変更前と比較し、異常がないか確認しましょう。
変更後一定期間が経過したら、ポストチェンジレビューを実施します。変更が期待通りの効果をもたらしたか、予期せぬ問題は発生しなかったかなどを振り返り、次回の変更に活かします。
最後に、変更の経験から得られた知見を文書化し、組織のナレッジとして蓄積します。成功事例だけでなく、失敗から学んだ教訓も価値ある情報です。これらのナレッジを次回の変更に活かすことで、変更管理プロセス自体を継続的に改善していくことができます。
たとえば、「特定のシステムではパッチ適用後に再起動が必要」「DBスキーマ変更は業務時間外に行うべき」といった知見を蓄積し、チェックリストやベストプラクティスとして整備することで、同じ失敗を繰り返すリスクを減らすことができるでしょう。
変更管理は一度完成すれば終わりというものではなく、常に見直しと改善を続けることが大切です。皆さんの組織でも、この7ステップを参考に、より効果的な変更管理プロセスの構築を目指してみてはいかがでしょうか？
当社が提供するSHERPA SUITEは検知・通知系ソリューションと管理系ソリューションから成るOSS（オープンソースソフトウェア）です。Redmineをベースに開発されており、アラート制御ツール、インシデント管理ツール、ジョブ管理ツールなどでシステム運用管理を自動化できます。
SHERPA SUITEは、IT変更管理のプロセスを可視化し、自動化することで、チーム間のコラボレーションを促進するプラットフォームです。特に、変更要求の受付から承認、実装、検証までの一連のワークフローを統合的に管理できる点が大きな特徴となっています。
従来の変更管理では、Excel管理や複数のツールの併用によって情報が分断され、全体像の把握が困難でした。まるで地図なしで未知の山を登るようなもの。
SHERPA SUITEは、その名の通り「シェルパ」として、変更管理の複雑な旅路をナビゲートしてくれるのです。
変更管理は企業のITガバナンスの要であり、ビジネスの俊敏性と安定性のバランスを取る重要な役割を担っています。SHERPA SUITEの導入により、「変更が遅い」「プロセスが煩雑」といった悩みを解消し、より効率的でありながら堅牢な変更管理体制を構築することができるのではないでしょうか。
