変更管理システム開発の発注/外注/依頼/委託方法について

変更管理システムの発注は、現行業務の整理、要件と受入条件の明確化、段階導入の順に進めます。この順で進めると、変更記録の統制につながります。

発注形態から運用定着まで、段階ごとに決めることを順に見ていきます。全体像は変更管理システム開発の完全ガイドもご覧ください。

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

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

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

変更管理システムは、サーバーやネットワーク、業務アプリなどの変更を、申請からクローズまで記録して統制する仕組みです。クラウド設定やデータベース、セキュリティ設定も対象に含まれます。発注時には、対象の範囲とリスク評価者を決め、許可条件や完了確認まで発注側と開発会社で合意しておきます。

申請から事後レビューまでの発注範囲

発注範囲には、変更を記録して完了後まで追跡する工程と、既存の管理との連携を含めます。ここを外すと、完了後の追跡が途切れ、既存の管理との連携を後から追加する手間が生じます。

変更は、種別、緊急度、影響範囲で分類し、承認を受けたあとに実施日時を確定します。次に、テストとバックアウト計画を確かめてから本番で実施し、結果確認と事後レビューを経て、クローズまで追跡します。

• ライフサイクル：登録から分類、リスク評価、承認を経て、実施、検証、レビュー、クローズまでの流れです。
• 受託範囲：申請画面だけでなく、実施結果と監査証跡まで見られる状態が条件になります。
• 既存管理との連携：インシデント、問題、リリース、資産、構成管理との関係を決めておきます。
• 情報の出所：障害復旧の変更をインシデントに紐付けるか、リリース計画から変更要求を作るかを決めます。対象サービスや構成アイテムの取得元も定めておきます。

変更を進めながらサービス中断を抑える考え方は、ServiceNowの2026年3月12日更新ドキュメントでも示されています（出典：ServiceNow「変更管理」、2026年）。

標準・通常・緊急変更の分け方

変更の種別ごとに手続きを分けると、低リスクの作業が承認で滞るのを防げます。さらに、現場がシステムの外で作業してしまう誘因も減らせます。

• 標準変更：手順とリスクを事前に確認しておき、定型の証明書更新などを扱います。
• 通常変更：個別に影響とリスクを評価し、データベースのメジャーバージョン更新などが対象です。
• 緊急変更：障害や脅威への即応を目的とし、重大障害を止める設定変更などを扱います。

RFPには、標準変更のテンプレート化と事前承認、通常変更のリスク別承認、緊急変更の事後レビューを記します。Atlassianも3分類のほか、リスク評価と承認経路の自動化、CI/CDからの要求作成を説明しています（出典：Atlassian「Jira Service Managementによる変更管理」、2026年確認）。

発注形態の選び方

発注形態は、必要な標準機能と既存環境への連携の範囲で選びます。どちらを優先するかで候補が変わるため、先に両方を整理しておくと比べやすくなります。

• クラウド型ITSM：標準的な変更管理を短期間で始めたい場合の候補です。
• パッケージと連携開発：既存の認証や資産管理、開発ツールとつなぐ場合に向いた選択肢です。
• 個別開発：独自の承認やレガシー連携が競争力に直結する場合が対象です。

形態を比べるときは、導入期間のほか、更新、移行、保守、将来の委託先変更まで含めて見ます。

SaaS・パッケージの標準機能の活用

SaaSとパッケージは、標準機能を使って必要な範囲から運用を始めやすい形態です。発注前には、エージェント数と利用者数を押さえます。加えて、SSOやMFA、API、CMDBとの接続、ログ保存、データ保管場所も確かめます。

• SaaS：サーバーの調達やバックアップ基盤の負担を抑えられ、1部門または1サービスから始められます。
• パッケージ：申請や承認、変更カレンダー、監査ログ、インシデント連携の知見を活用できます。
• 設定方針：Fit to Standardを受け入れ、独自ルールは必要な範囲に絞る方針です。
• 利用条件：認証、連携、保管などに関する契約条件が対象です。
• 見積内訳：ライセンスと初期設定、移行、連携、教育を分けてもらい、初年度総額を把握します。

また、バックアップやSLA、サポート時間、追加モジュールの条件、解約時のデータ返却も確かめておきます。

ローコードとスクラッチ開発の使い分け

小さく検証したいならローコード、標準機能では満たせない個別要件があるならスクラッチが選択肢になります。

• ローコード：申請フォーム、承認、通知、期限管理のPoCに使えます。
• 拡張設計：CMDB、監査ログ、権限分離、CI/CD連携を後から足すと複雑になるため、変更番号、対象サービス、実施結果のデータ設計とAPI方針を先に決めます。
• スクラッチ：独自のリスク評価、複雑な組織、レガシー連携、特別な監査要件があり、標準機能で対応できない場合が対象です。
• 自社で担う範囲：柔軟性と引き換えに、変更モデル、権限、通知、ログ、更新対応を自社で再現する必要があります。

ソースコードや設計書、テスト仕様書、運用手順書、脆弱性対応について、どこまでを誰が受け持つかも発注条件に含めます。

RFPと要件整理の進め方

RFPは、現行業務と目指す状態、データ、連携を、各社が同じ条件で比べられるように記す資料です。非機能、納品物、評価方法も、同じ土台で書きます。

まず直近6〜12か月の記録から、申請経路、承認待ち、緊急変更や失敗変更、変更起因インシデントを確かめます。現行の例外が見えないままRFPを作ると、見積が安く見えても、要件定義のあとに追加費用が膨らみます。

現行の変更プロセスと対象データの洗い出し

要件に落とし込む前に、現行の変更業務と対象データ、情報の正本を把握しておきます。

• 要求の起点：定期保守、機能追加、脆弱性対応、障害復旧、クラウド変更など、変更が生まれる出どころです。
• 実態と対象：理由ごとに優先度や承認者が違う場合があるため、サービス、サーバー、ネットワーク機器、クラウド、アプリ、DB、セキュリティ設定を洗い出します。
• 記録の照合：インシデントやリリースを含め、申請票、メール、チャット、チケット、監視記録、聞き取りを突き合わせます。
• 必要な記録項目：変更差分、影響サービス、予定日時、テスト、バックアウト条件、実施者、承認者、事後確認者を定めます。
• 正本の決定：CMDB、資産台帳、CI/CDのどれを正とするかを決め、二重登録を防ぎます。

機能要件と非機能要件の分け方

機能要件と非機能要件は分けて書きます。連携や利用環境まで具体的に書いておくと、提案を同じ条件で比べやすくなります。

• 業務機能：変更番号、申請、種別、リスク評価、承認、CAB条件、差戻し、通知、カレンダー、競合検知を定めます。
• 実施要件：テスト、バックアウト、ログ、レビュー、監査証跡、ツール連携の決め方です。
• 処理・稼働条件：利用者数、変更件数、拠点数、同時アクセス、稼働時間、検索性能、バックアップ、復旧目標、可用性を定めます。
• 統制・利用環境：認証、権限、暗号化、ログ保存期間、データ所在、サポート時間を指定します。
• モバイル利用：通信が切れたときの動き、添付、通知の再送、スマートフォンでの承認可否まで含めます。

GitHubやGitLab、Jenkins、Bitbucketと連携する場合は、変更レコードの自動作成と、承認後の本番移行を定めておきます。

受入条件の決め方と提案の比較

受入条件は、導入後の業務を一つずつ再現できるよう、シナリオ単位で決めます。

• 承認フロー：標準変更はテンプレートで申請し、通常変更はリスク別に承認します。
• 実施統制：承認前の実施を防ぎ、変更番号から担当者、ログ、関連インシデントまでたどれることが条件です。
• 例外と権限：緊急変更の事後レビュー、差戻し、代理承認、権限不足、連携エラーの場面を、実際に試して確かめます。
• 復旧・記録：バックアウトとログ検索を試し、匿名化した変更記録をテストデータとして使います。

情報システム、開発、運用の各部門と、セキュリティや業務部門が、それぞれの立場で結果を確かめます。

準委任・請負・ライセンスの使い分け

契約は、要件が固まった工程と、発注者と受託会社が一緒に整理する工程とで使い分けます。そのうえで、作業範囲、成果物、検収、追加費用、知的財産、保守と、どこまでを誰が受け持つかを確かめます。

法的な適用関係は案件の実態によって異なるため、最終契約は法務や購買の部門にも確かめてもらいます。

要件定義と伴走支援の準委任

作業をしながら要件を固める工程では、支援の内容と、発注者・受託会社それぞれの役割を明確にしておきます。

• 支援対象：業務の洗い出し、製品比較、RFP、試作、部門合意までを準委任で進める範囲です。
• 進め方：ヒアリングやワークショップで現状と目標を整理し、月ごとの成果物、会議、判断事項、次月の計画を決めます。
• 成果物：要件一覧、業務フロー、課題表、RFP、PoC評価結果などを明記する対象です。
• 役割分担：発注者が決めることと、受託会社が助言することを分けて、意思決定を進めます。

開発・設定と検収条件の具体化

成果物と対象範囲が固まった工程では、請負型の契約で仕様と変更手順を具体化します。

• 対象工程：画面、ワークフロー、API、移行、テスト、教育などを定めます。
• 仕様と検収：機能、環境、性能、セキュリティ、納品物、検収、修正期限、納期の前提を記します。
• 範囲の明確化：「一式」とせず、CMDB連携や緊急変更レビューを、機能やシナリオごとに分けて書きます。
• 変更手順：追加見積、納期への影響、承認者、優先順位の決め方を定めておきます。
• 契約後の扱い：瑕疵対応、再委託、ソースコードと設定情報の引き渡しを、あらかじめ取り決めます。

ライセンス・保守・データ返却の確認範囲

製品の利用、導入支援、運用委託は、契約条件と責任の境界をそれぞれ分けて確かめます。

• 製品契約：ライセンス、初期設定、追加ユーザーやインスタンス、API、サポート、更新、移行を、それぞれ別々に扱います。
• 責任分界：製品障害、業務設定、緊急変更記録の確認担当を、どこまで誰が受け持つかで定めます。
• 運用委託：監視時間、一次受け、承認代行、障害連絡、脆弱性対応、月次報告、ログ提出、引継ぎの取り決めです。
• 解約・移管：データ返却に加えて、履歴、添付、設定、ワークフロー、権限、監査ログの形式を決めます。

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

変更管理システム単体の公的な費用統計は少ないため、ここに挙げる金額は計画用の目安として読んでください。公開料金、ITSM導入作業、類似する業務システムの相場をもとに整理したもので、固定価格ではありません。

金額は、製品や利用者数、対象サービス、データ、連携本数、監査要件によって変わります。見積では、ライセンスと設定、業務設計を分けてもらうと、前提をそろえて比べられます。移行、連携、テスト、教育、保守も項目ごとに分けてもらい、どこまでが金額に含まれるかを確かめます。

クラウド・パッケージ導入の初年度総額

初年度費用と公開料金を導入規模ごとに分けて見ると、見積の前提がそろい、比べやすくなります。

中規模導入では、CMDBや資産管理、SSOが含まれます。さらに、複数部門の承認、変更カレンダー、インシデントとCI/CDの連携も含まれます。初期設定、連携、移行、教育の費用は、300万〜1,000万円程度が目安です。

• 小規模：担当者5〜20人程度で機能を絞る場合、設定と業務設計が100万〜300万円、初年度総額が150万〜500万円程度です。
• 中規模：初年度総額は500万〜1,500万円程度です。
• 導入期間：小規模は4〜8週間、中規模は3〜6か月程度が目安です。
• Freshservice料金：公開プランの料金を、導入条件に当てはめて照らし合わせます。
• ServiceDesk Plus料金：クラウド版の価格表で、金額を確認する項目です。

Freshserviceの年契約では、1エージェントあたりの月額が、Starterは19ドル、Growthは49ドル、Proは99ドルです。Enterpriseは個別見積もりです（出典：Freshworks「Freshservice Pricing」、2026年確認）。

ManageEngine ServiceDesk Plusのクラウド年額は29.1万円からです（出典：ゾーホージャパン「ServiceDesk Plus 価格一覧」、2026年確認）。10オペレーターの場合、Standardは48.5万円、Professionalは63.9万円です（出典：同価格一覧、2026年確認）。税や為替、追加機能、導入支援の費用は、別途確かめる必要があります。

スクラッチ開発と大規模導入の費用・期間

統合の範囲や個別開発の規模が大きいほど、費用と期間の幅も広がります。申請と承認だけの個別開発であれば、数百万円から検討できる場合があります。

中規模開発で自社専用に作る場合は、500万〜1,500万円程度です。対象の中心は、監査ログ、権限分離、CMDBです。CI/CDとSSOに加え、可用性、API、レポートも同じ開発範囲に含まれます。データの欠損や重複、既存システムの仕様不明、承認ルールの未合意があると、期間は延びやすくなります。

• 大規模統合：複数拠点、グループ会社、24時間運用、複数インスタンス、監査、ITOM、脆弱性管理を含むと、1,000万〜3,000万円超の可能性があります。
• 個別開発：申請と承認だけの開発から自社専用の中規模開発まで、要件によって規模が変わります。
• 大規模開発：計画の目安は1,000万〜3,000万円超です。類似する業務システムの作業範囲から推定した金額です。
• 期間と進め方：要件定義が1〜2か月、設計と開発が2〜6か月、連携・移行・テストが1〜3か月、全体で6〜12か月程度です。
• 段階導入：1部門か1サービスで標準・通常変更を始め、実績を見て連携を広げると、費用と期間を抑えやすくなります。

5年TCOと追加費用の確認

初期価格だけで判断すると、後から増える費用を見落としがちです。そのため、追加費用と5年間の総所有コストを、同じ条件で比べます。

• 追加費用：ユーザー追加、API、追加インスタンス、容量、監視、バックアップ、保守、教育、更新、障害対応の費用を含めます。
• 5年TCO：ライセンス、保守、運用、改修、移行の費用を試算し、クラウド、オンプレミス、パッケージ、スクラッチを同じ期間で比べます。
• 内訳：製品料金と導入支援が一括の場合は、費目と単価を分けてもらいます。
• 見積前提：「一式」となっている対象ユーザー、連携・移行・テストの数、教育回数、サポート時間、除外事項を確かめる項目です。
• 対応範囲：標準機能、設定、追加開発、発注者の準備範囲を明示している提案が、評価の対象です。

委託先の選び方と見積比較のポイント

委託先は、知名度や価格だけで選ばず、設計、連携、移行、セキュリティ、教育、保守への対応力で見ます。各部門の業務を理解し、入力の負担と統制を両立させる提案ができる会社が候補になります。

同規模の導入実績と支援体制

導入件数の多さだけでなく、自社の規模と業務に近い経験や、稼働後の支援体制を確かめます。

• 類似実績：変更件数、拠点、利用者、既存ツール、監査要件が近い案件の有無を聞きます。
• 製品・業務知識：主要製品の資格と、変更設計や連携、改善の実績を見ます。
• 支援体制：PM、業務コンサル、設定、連携、移行、テスト、保守の役割と、稼働時期です。
• 委託管理：再委託の範囲、アクセス権、秘密保持、事故報告の責任の分け方です。
• 稼働後：窓口の継続性と、担当が交代するときの引継ぎ方法です。

ServiceNowやJira Service Management、Freshservice、ManageEngineなどは、販売資格の有無だけでは判断しません。そのうえで、変更種別の運用設計や、CMDB・資産管理との連携、CI/CDの記録、稼働後の改善実績も聞いておきます。

自社の変更シナリオによるデモと提案の評価

デモでは、実際の変更フローと連携時の例外処理を再現して、運用の負荷を見ます。

• 通常変更：クラウド設定の申請から、対象の選択、リスク評価、承認者への通知、承認、実施、結果とログの登録、クローズまで、一通り試します。
• 例外フロー：標準変更のテンプレート、緊急変更の事後レビュー、承認前の実施防止の動きを確かめます。
• CI/CD連携：対象サービス、リスク、承認者、デプロイ結果を、どこまで自動で取得できるかを見ます。
• APIの活用：ServiceNowの変更管理APIを使った連携方法。
• 障害時の動き：連携エラー、重複登録、通信断のときに、手動でどう復旧するかまで見ておきます。

ServiceNowの変更管理APIは、外部のアプリから変更要求を作成し、プロセスを統合する用途を示しています（出典：ServiceNow「変更管理API」、2026年3月更新）。

見積項目と前提条件の比較方法

各社の見積項目と作業条件をそろえ、金額差の理由が見える状態にします。

• 共通項目：要件定義、ライセンス、設定、開発、連携、移行、テスト、教育、保守の項目を、各社で合わせます。
• 前提条件：ユーザー数、変更やサービスの数、連携本数、移行データ、テスト範囲、納品物を突き合わせます。
• 期間と支援：サポート時間と納期の起算日も、各社で合わせる項目です。
• 対応範囲：標準機能、設定、追加開発、発注者の準備、将来対応を、比較表に書き込みます。
• 選定：対象外の作業や将来費用を確かめ、前提と責任の分け方が透明な提案を選びます。

セキュリティ・監査・運用定着の発注範囲

記録には構成やセキュリティ設定も含まれるため、統制と運用を発注の要件に入れておきます。最小権限、SSO、MFA、暗号化のほか、ログやバックアップ、復旧訓練、委託先のアクセスも定めます。

IPAは2026年4月公開の実践情報で、サイバーリスクの役割と責任を明確にする管理体制を求めています（出典：IPA「サイバーセキュリティリスク管理体制の構築」、2026年）。

認証・権限・監査ログの条件

認証、権限、ログの条件は、異動や監査対応の場面を想定して具体的に決めておきます。

• 認証：社内IDとの連携、MFA、外部利用者の本人確認、共有アカウントの禁止までを条件にします。
• 権限分離：申請、編集、承認、結果登録、添付の閲覧、ログ出力を分け、自分の変更を単独で承認できないようにします。
• 運用テスト：異動、退職、代理承認、期限切れの権限、委託先の一時アクセスの場面で、動きを試します。
• 監査ログ：誰がいつ、起票からクローズまで追跡し、改ざん防止、保存期間、検索・出力、監査時の提出、異常アクセス通知、復旧を定めます。

経済産業省のシステム監査・管理基準も参考にしながら、自社や顧客が求める証跡を確かめます。

標準変更とKPIによる現場の定着支援

現場で記録が続く申請方法と、運用状況を見直す指標を、あわせて設計します。

• 申請定着：必要な入力に絞り、既存ツールから申請できるようにします。
• 変更種別：標準変更はテンプレートと自動承認で簡素にし、緊急変更は復旧後に理由、実施、結果、再発防止策を確かめます。
• 月次KPI：変更成功率、変更起因インシデント率、緊急変更率、承認時間、標準変更比率、事後レビュー完了率、バックアウト件数を追います。
• 改善点：数値が改善しない場合は、承認者数、リスク分類、入力負荷、責任部門を見直し、運用を改善し続けます。

よくある質問（FAQ）

発注では、費用や製品だけでなく、管理する変更の範囲と、運用改善の担当者も判断材料になります。

変更管理システムの開発費用はどのくらいですか？

小規模導入は、初期設定が100万〜300万円程度、ライセンス込みの初年度総額が150万〜500万円程度が、計画用の目安です。

中規模は初年度総額で500万〜1,500万円程度、大規模統合や個別開発は1,000万〜3,000万円超もあります。ユーザー数、連携、移行、教育、保守条件によって変わる推定の幅です。

変更管理システムはSaaSとスクラッチのどちらがよいですか？

変更種別や承認、ログを早く整えたいならSaaSやパッケージが候補になります。独自ルールやレガシー連携に標準機能が合わない場合は、個別開発を検討します。

まず標準機能のPoCで入力と承認の定着を確かめ、そのあとに追加開発を判断します。

委託先を選ぶときに何を確認すればよいですか？

委託先では、同規模・同業種のITSM実績と業務設計を見ます。また、CMDB・資産・CI/CD連携への対応を確かめます。移行とセキュリティへの対応も、あわせて確かめます。教育と保守の体制も見ておきます。デモでは、標準・通常・緊急変更、差戻し、承認前の実施防止、ログ追跡を試します。

製品ベンダーと実装SIerが別の場合は、要件定義、設定、移行、障害対応の責任者を明確にしておきます。

小さく始める場合は何から発注すればよいですか？

対象を決める段階で、試行後に確かめる運用課題と評価指標も、あわせて考えておきます。

1. まず1部門か1サービスに絞り、申請からリスク分類、承認、実施記録、事後レビューまでを稼働させます。
2. 標準変更のテンプレートを数種類作り、入力と承認の滞留、緊急変更の追跡を確かめます。
3. 変更成功率や承認時間、変更起因インシデント率を測り、効果と課題を見極めます。
4. 結果を踏まえて、CMDBや資産管理、CI/CD、複数部門へと段階的に広げます。

まとめ

発注前にそろえるべき判断材料

申請画面の開発費だけで判断せず、変更要求から事後レビューまでの流れと監査ログを、一連で整理します。

標準的な運用はSaaSやパッケージ、既存の連携は設定や連携開発で進めます。独自ルールやレガシー連携が欠かせない場合は、個別開発を選びます。

段階導入と同条件の見積比較

発注範囲と価格の前提を明確にし、提案を同じ判断軸で比べられる状態にします。

• RFPと見積：変更種別、カレンダー、サービス、CMDB、CI/CD、SSO、権限、監査ログ、バックアウト、データ移行、教育、保守、データ返却を含めます。
• 契約範囲：移行、教育、保守、データ返却を示し、見積の根拠と除外事項を比べます。
• 費用幅：初年度150万〜500万円程度の小規模から、1,000万〜3,000万円超の大規模開発まで、推定の幅があります。
• 導入方法：1部門・1サービスで実データを使い、定着を確かめてから拡張します。

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

▼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を創業。