変更管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

変更管理システムの導入は、要件整理から定着まで6段階を順に進めると、変更事故と監査負担を抑えられます。

管理対象や費用相場、見積もりの確認点も、順に解説します。全体像は、変更管理システム開発の完全ガイドでも確認できます。

▼全体ガイドの記事
・変更管理システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

変更管理システムの全体像

変更管理システムは、ITサービスマネジメント（ITSM）／ITILにおける変更を、リスクに応じて確認しながら安全に実施するための仕組みです。申請の内容から実施結果までを記録するため、原因究明や監査の説明にも役立ちます。

製造業の設計変更管理や組織変革のチェンジマネジメントは、この記事の対象に含みません。

変更管理の対象範囲

管理対象になるのは、ITサービスに影響する追加・修正・削除です。サーバー、ネットワーク、クラウド設定、データベース、業務アプリなどが該当します。

• 本番環境：データベース設定や業務アプリのリリースが対象になります
• アクセス・安全対策：クラウド権限の変更や脆弱性パッチを含みます
• 管理境界：サービス、環境、変更金額、停止可能時間で区切った範囲

セキュリティ設定や監視設定のように、ITサービスに間接的に影響する変更も対象になります。

開発環境の個人設定まで同じ承認フローに載せると、申請する側の入力負荷が大きくなりすぎます。そのため、管理対象はサービスへの影響に応じて決めておきます。

基本の流れは、変更要求を登録し、種類と緊急度を分類したうえでリスクを評価することから始まります。そのあと承認を経て日時を確定し、テストとバックアウト計画を確認します。続いて本番で実施し、結果を確認してクローズします。

インシデント、問題、リリース、構成アイテム（CI）も変更の記録と関連付けると、変更の前後にどのような因果関係があったかを追えます。申請番号を振るだけでなく、関連する記録までたどれる設計が必要です。

標準・通常・緊急の3分類

変更は、リスクと緊急度に応じて3種類に分けます。分類ごとに、承認の深さや実施後の確認を変えて設計します。

• 標準変更：低リスクで、手順と実績が確立し事前承認できる変更
• 通常変更：個別評価と承認が必要で、本番リリースやネットワーク構成変更などが該当します。
• 緊急変更：重大障害や脆弱性に速やかに対応する変更

Atlassianの公式ガイドは、変更分類と標準変更の事前承認を説明しています。変更カレンダーやリスク評価の自動化、CI/CD連携にも触れています（出典: Atlassian「Jira Service Managementにおける変更管理の仕組み」、2026年確認）。

緊急変更にも審査は必要です。実施を優先する一方で、後追い承認、テスト結果、事後レビューを必須にします。

変更管理システムの進め方と設計

導入は、要件整理から定着まで6段階に分けて進めます。まずは申請・承認・実施記録・変更カレンダーを動かし、入力負荷と承認時間を測りながら対象を広げます。また、全社のCMDBやすべての連携は最初から完成させず、最小単位から始めます。

フェーズ1：現状と目標をそろえる要件整理

変更の情報は、メールやExcel、チャットのほか、チケットや口頭承認にも分かれています。そこで、直近6〜12か月の変更を集めて一覧にします。記録がなければ、担当者への聞き取りとサンプル調査から始めます。

• 実績：変更件数、緊急変更率、失敗、変更起因のインシデントを洗い出します
• 時間と体制：平均承認時間、対象サービス、承認者を確認します
• 申請情報：理由、対象CI、影響、日時、担当、テスト、連絡先を定めます
• 運用条件：承認権限、代行者、レビュー期限、ログ保存年数の取り決め

標準・通常・緊急を判定する質問は3〜5問程度にまとめ、低リスクの変更が毎回CABに回らないようにルールを設けます。

申請項目は、変更内容やバックアウト条件、実施後の確認結果まで含めつつ、判断に必要な情報に絞ります。環境やサービスの範囲と、既存のインシデント・リリース管理との連携も決めておきます。

要件が曖昧なまま製品を選ぶと、業務を無理に変えたり、高額なカスタマイズが必要になったりします。

フェーズ2：方式と製品の選定

候補は、SaaSとパッケージ／オンプレミスのほか、既存ワークフローのローコード拡張とスクラッチ開発です。利用人数や連携要件に合わせて比べます。

• 小規模：5〜20人で申請・承認・通知・履歴が中心なら、SaaSや既存ITSMの標準機能が候補です。
• 複雑な要件：複数拠点や厳格な保管、複雑な承認、深い基幹連携がある場合は、パッケージ拡張またはスクラッチを検討します。
• 評価方法：機能数ではなく、実際の業務シナリオで候補を比べます。

本番DB変更を申請してから、CIを確認し、承認と作業チケットの発行を経て、デプロイ結果を取り込むまでを、候補製品で実演してもらいます。

Jira、Microsoft 365、ServiceNowとの連携可否を確かめます。加えて、監視製品やID管理基盤、GitやJenkinsとのつながりも確かめます。

製品選定では、SSOや多要素認証に加え、権限分離と監査ログの改ざん防止も確認します。そのほか、ログの保存期間やデータセンター、バックアップと復旧目標を確認します。API制限やサポート時間、解約時のデータ返却も見ておきます。

Fit to Standardを基本にして、法令・監査・連携上必要な差分だけを足します。こうすると、開発費と将来の保守費を抑えられます。

フェーズ3：ワークフローの設計と開発

画面を作る前に、業務ルールを固めておきます。申請から承認までを経て、実施待ち、実施中、検証、クローズへと進む状態遷移を描きます。

• 標準変更：承認済みの手順や作業時間、バックアウト条件をテンプレートから引き継ぎます。
• 通常変更：リスクに応じて、技術、サービスオーナー、CABの承認を組み合わせます。
• 緊急変更：先行承認の経路を設け、実施後に記録とレビューを残します。

承認の段階は、顧客影響と停止時間で分けます。さらに、データ重要度や変更実績、復旧難度も判断の材料にします。

緊急変更では、電話やチャットで先に承認を得ます。そのうえで、申請番号や実施ログ、テスト省略の理由、事後レビューの結果を後から記録します。

変更レコードに一意のIDを付け、それを使ってGitのプルリクエストやCI/CDのデプロイ、監視アラートと関連付けます。インシデントやCMDBのCIも、同じIDで結びます。この設計があれば、どのコードがどのサービスへいつ反映されたかを追跡できます。

ServiceNowの更新文書では、変更管理と脆弱性対応の統合、エージェント型ワークフロー、外部アプリとのAPI連携が案内されています（出典: ServiceNow「変更管理」「変更管理API」、2026年3月12日更新）。

フェーズ4：業務・連携・権限のテスト

画面の表示だけでなく、業務シナリオが最後まで完了するかを確認します。緊急変更の記録が残らず、通常の承認を回避できてしまう状態も防ぎます。

• 変更ケース：標準・通常・緊急変更、差し戻し、延期、バックアウトを試します。
• 例外ケース：代理承認、レビュー未完了、承認者の異動、連携先停止
• 権限：申請者の自己承認や、実施者による履歴変更を防げるかを確認します。
• 連携：SSOの入社・異動・退職、CI/CDの成功・失敗・取消を確認します。

監査担当者が必要なログを閲覧できるかも確認します。また、変更管理システムでは、デプロイを伴わない手作業も記録できる必要があります。

受入基準には、申請からクローズまでの時間と必須項目の入力率を含めます。加えて、承認経路や競合検出、ログ、通知、バックアウト記録も含めます。

履歴を移すなら、全件を移すのか、監査上必要な期間だけを移すのかを決めます。移行後は、件数とサンプルを照らし合わせます。

フェーズ5：小さな稼働と改善点の収集

初回は、1部門または1サービスに絞ったパイロットが適しています。選ぶ対象は、変更件数がある程度あり、協力的な担当者がいて、影響範囲を把握できるところです。

• 運用するもの：申請フォーム、承認ルート、変更カレンダー、実施記録、KPI
• 記録するもの：入力時間、承認待ち、差し戻し理由、標準化できる作業
• 切替条件：旧Excel・メールで新規申請を受ける期限、移行案件、停止時間、問い合わせ先、障害連絡網

並行運用が長引くと、二重登録が起きてしまいます。そこで、パイロット期間と終了条件をあらかじめ定めておきます。

たとえば、2〜4週間運用し、主要な変更が新システムに登録されて、承認履歴と実施結果を追える状態を終了条件にします。

フェーズ6：KPIと教育による定着

定着後は、複数のKPIを月次で確認します。変更成功率だけで評価せず、件数やサービス重要度、障害の影響度と合わせて見ます。

• 結果：変更成功率と変更起因インシデント率
• 運用：緊急変更率、承認時間、標準変更比率を見ます。
• 事後対応：事後レビューの完了率を確認します。

成功率だけを上げる評価は、小さく申請したり、失敗を記録しなかったりする誘因になります。

教育では用語の説明より、「何を申請するか」「標準変更の選び方」「緊急時の連絡先」を画面で示します。運用では、入力に困る項目を月次で減らし、よく出る作業はテンプレート化します。

IPAは、サイバーセキュリティリスク管理で、関係者の役割と責任を明確にするよう示しています（出典: IPA「指示2 サイバーセキュリティリスク管理体制の構築」、2026年確認）。そのため、運用責任者からサービスオーナー、承認者、実施者、監査担当まで、責任分界を文書にします。

変更管理システムの費用相場とコストの内訳

費用は、ライセンスだけでなく業務設計や設定、移行、連携にかかる分も含めて考えます。テストや教育、保守も費用の対象です。

ここでの金額は、2025〜2026年の公開料金と一般的なITSM導入作業から整理した目安です。変更管理に限った公的統計ではなく、要件や利用者数によって見積もりは変わります。

クラウド・パッケージ導入の相場

小規模から大規模まで、導入の規模と連携の範囲によって費用は変わります。製品料金の例も含めて、規模ごとの相場を比べます。

• 小規模：担当者5〜20人で申請などの基本機能を使います。
• 中規模：CMDBやSSOなど複数の連携を含みます。
• 大規模：複数拠点、24時間運用、監査、脆弱性管理、複数インスタンスの統合は1,000万〜3,000万円超になる可能性があります。
• Freshservice：Starter月19ドル、Growth49ドル、Pro99ドル（各1エージェント）。Enterpriseは個別見積もりです。
• ServiceDesk Plus：クラウド年額は29.1万円から、オンプレミス通常ライセンスは119.9万円からです。

担当者5〜20人で、申請・承認・通知・履歴・簡易レポートを使う場合は、業務設計と設定に100万〜300万円が目安です。初年度の総額では、150万〜500万円の幅で見ておきます。

中規模導入では、CMDBや資産管理、SSOと連携します。さらに、複数部門の承認やカレンダー、インシデント、CI/CDも連携の対象です。

費用の目安は、初期設定・連携・移行・教育で300万〜1,000万円、初年度総額で500万〜1,500万円程度です。

小規模導入の期間は4〜8週間程度です。ただし、既存ルールの整理やデータ移行が多い場合は、期間も長くなります。

Freshserviceの価格は年間契約の場合です（出典: Freshworks「Freshservice Pricing & Plans 2026」、2026年確認）。1ドル150円、10人で単純に換算すると、ライセンスは年約34万円、約88万円、約178万円になります。税や為替、追加機能、導入支援は含みません。

ManageEngine ServiceDesk Plusの料金は、日本語の価格ページに基づきます（出典: ゾーホージャパン「ServiceDesk Plus 価格一覧」、2026年確認）。

スクラッチ開発・大幅カスタマイズの相場

独自開発の費用は、機能の範囲と規模によって変わります。期間と保守を含めた総額も、合わせて見ておきます。

• 小規模：申請と承認だけなら、数百万円規模から検討できます。
• 中規模：複数組織、可用性、API、レポートなどの独自開発は500万〜1,500万円が目安です。
• 大規模：同様の独自開発では、1,000万〜3,000万円超を想定します。
• 開発期間：要件定義1〜2か月、設計・開発2〜6か月、連携・移行・テスト1〜3か月で、合計6〜12か月程度です。
• TCO：5年間の保守、基盤、監視、脆弱性対応、追加要望まで含めて比較します。

監査ログや権限分離、CMDB、CI/CD、SSOを含めると、開発費は増えます。さらに、スクラッチ開発では、通知や承認代理、監査証跡、権限変更、障害復旧、バージョンアップ対応も必要になります。

これらは、変更管理に固有の公的統計ではありません。類似する業務システムの公開相場と必要工数から推定したものです。初期費用だけで判断せず、TCO（総所有コスト）で比べます。

変更管理システムの見積もりを取る際のポイント

見積もりの差は、機能数よりも、対象サービスや承認ルート、連携先から生まれます。移行データや監査要件、運用支援の範囲でも差が出ます。

依頼時に「変更管理システム一式」とだけ伝えると、各社の前提が食い違い、比較できません。そこで、RFPでは業務シナリオと非機能要件を分けて示します。

要件と見積もりの前提をまとめた資料

RFPには、月間件数や利用者と承認者の数、サービスとCIの数を記載します。さらに、変更分類の割合、変更可能な時間帯、ログ保存年数も書いておきます。

• セキュリティ・運用：SSO、IP制限、多要素認証、バックアップ、SLAを示します。
• 既存環境：利用中のツールとデータ移行の範囲
• 業務シナリオ：申請から実施、事後レビューまでの一連の流れ

代表例として、定例パッチを標準変更で申請する流れを示します。加えて、基幹システムのリリースを通常変更でCAB承認する例も添えます。

重大な脆弱性を緊急変更で実施し、翌営業日にレビューするシナリオも示します。

見積書では、ライセンスと初期設定、業務設計、画面・ワークフロー、API連携を分けてもらいます。さらに、CMDBや資産データの整備、移行、テストを別に示してもらいます。教育、マニュアル、稼働支援、保守、追加ユーザー単価は、項目ごとに分けて記してもらいます。

個別見積もりの製品では、ライセンスと導入支援を分けて見ます。契約期間や最低人数、追加モジュールも確認し、ストレージやAPI量、サポート水準まで見ておきます。

開発会社・導入パートナーの比較

製品の設定だけでなく、変更分類や承認権限、KPI、定着まで設計できる会社を選びます。実績も、社名だけでなく導入内容まで確かめます。

• 導入実績：同規模・同業界の経験と、対象範囲を確認します。
• 設計・連携：CMDBやCI/CDの担当と、標準機能との境界を確かめます。
• 運用支援：緊急変更、改善会議、保守窓口の支援内容を聞きます。

対象サービス数や変更件数、連携範囲、導入期間、運用体制まで聞くと、実績が自社に合うかを判断できます。

提案は、価格だけでなく、要件理解やFit to Standard、移行・テスト計画で評価します。さらに、セキュリティや担当者の経験、障害時の責任分界も見ます。

デモでは、差し戻しや代理承認、緊急変更、失敗デプロイ、事後レビューを再現してもらいます。

回答が曖昧なままだと、契約後の追加費用や運用負担につながります。

費用と納期が膨らむリスクへの事前対策

費用と納期の膨張は、初回の範囲と移行・運用の条件を早めに決めておくことで抑えられます。

• 初回範囲：申請、分類、承認、実施記録、クローズに絞ります。CMDB全件、脆弱性管理、チャットボット、高度なAI評価は後続に分けます。
• 拡張設計：変更ID、サービスID、CI識別子、API、権限モデルを初期設計で考慮します。
• 移行準備：重複、担当者名の揺れ、廃止サービス、添付ログを確認し、対応表、変換ルール、エラー時の扱い、監査対象期間を決めます。
• セキュリティ：権限分離、ログ保存・閲覧、バックアップ、復旧テスト、脆弱性対応の責任を契約と手順に記します。

経済産業省は、システム監査基準とシステム管理基準を、情報システムのリスク管理の基準として案内しています（出典: 経済産業省「システム監査制度について」、2026年6月1日更新）。

変更管理システムについてよくある質問（FAQ）

導入時は、管理範囲や承認の量、クラウドとオンプレミスの選択で迷うことが多いです。よくある質問を、判断の材料として取り上げます。

10人程度の情シスでも変更管理システムは必要ですか？

必要かどうかは人数ではなく、変更の影響度、監査要件、属人化、障害時に履歴を追えるかで判断します。

10人程度でも、メールやExcelで承認を管理していて、担当者が不在のときに経緯が分からないなら、導入の効果があります。SaaSや既存チケットの標準機能で対象を絞って始めるのが現実的です。

変更管理を導入すると開発スピードは落ちませんか？

承認を一律に増やせば、開発スピードは落ちます。一方で、低リスクで繰り返す作業は標準変更にできます。

条件を満たせば自動または簡略承認とします。そのため、高リスクの通常変更にレビューを集中できます。

CI/CDからデプロイ情報を変更記録へ取り込めば、開発者は同じ内容を別画面へ再入力せずに済みます。

クラウドとオンプレミスはどちらを選ぶべきですか？

初期費用や導入期間、運用負担を抑えたい場合は、クラウドが候補になります。

閉域網や保管場所、独自のバックアップ、既存認証に強い制約がある場合は、オンプレミスや専用環境を比べます。

どちらの場合も、5年間のライセンス、基盤、保守、更新、障害対応の総額で比べます。さらに、データ返却や復旧目標、責任分界も同じ条件で確認します。

CMDBは最初から完成させる必要がありますか？

最初から全資産を登録する必要はありません。影響の大きいサービスやデータベース、ネットワーク機器など、判断に必要なCIから始めます。

変更記録と照合しながら、精度を高めていきます。将来に備えて、サービスID、CI識別子、関連APIは初期設計で決めます。

まとめ

変更管理システムでは、申請フォームに加えて、対象範囲と変更分類を先に決めます。リスクに応じた承認からテスト、バックアウト、事後レビュー、監査ログ、KPIまでを、一連の業務として設計します。

要件を整理し、業務シナリオで製品を比べ、標準機能を基本にして設計します。権限や連携をテストしたうえで、1部門または1サービスから稼働させます。

小規模クラウド導入は初年度150万〜500万円、中規模連携は500万〜1,500万円、独自開発や大規模統合は1,000万〜3,000万円超が目安です。ライセンス、導入、保守を分けて見積もります。

成功率に加えて、緊急変更率や変更起因インシデント率、承認時間、標準変更比率、事後レビュー完了率を、継続して見ていきます。

低リスクの作業は自動化し、高リスクの変更には影響分析とレビューを集中させます。現場の負担を抑えながら安全性を高めることが大切です。

▼全体ガイドの記事
・変更管理システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。