RFCとは？Request for Change（変更要求）の意味や変更管理の流れ、RFIとの違いを初心者向けにわかりやすく解説

はじめに

ITサービスマネジメントやシステム運用について勉強していると、RFCという略語が登場することがあります。

RFCには複数の意味がありますが、ITILや変更管理の文脈では、一般的にRequest for Change（変更要求）を意味します。

例えば、本番環境に対して、

• ・サーバーの設定を変更したい
  ・OSやミドルウェアをアップデートしたい
  ・ネットワーク構成を変更したい
  ・新しい機能をリリースしたい
  ・障害対策として設定を修正したい

といった変更を行う場合、いきなり作業を始めると、その変更が原因でサービス障害を発生させる可能性があります。

そこで、

「何を、なぜ、いつ、どのように変更するのか」

を事前に記録し、影響やリスクを評価してから変更を実施します。

そのための変更要求がRFCです。RFCは、提案された変更を説明し、変更管理・変更コントロールを開始するために利用されるものと整理されています。

この記事では、

• ・RFCとは何か
  ・Request for Changeとはどのような意味か
  ・RFCには何を書くのか
  ・RFCを提出してから変更するまでの流れ
  ・CABとは何か
  ・標準変更・通常変更・緊急変更とは何か
  ・RFCとRFIは何が違うのか
  ・RFCと「Request for Comments」は何が違うのか

などについて、会話を中心に初心者向けにわかりやすく解説します。

RFCとは？

ITILでは「Request for Change（変更要求）」

RFCは、ITサービスマネジメントの話なら、Request for Changeの略として使われることがあるよ。

Changeだから、何かを変更してくださいという申請？

そのイメージでいいよ。システムやITサービスへ変更を加える前に、変更内容や理由、影響などを正式に記録するんだ。

RFC（Request for Change）は、システムやITサービスに対して変更を実施するための正式な要求・記録です。

例えば、

Webサーバーのソフトウェアを新しいバージョンへ更新したい

という変更があるとします。

実際に更新する前に、

• ・なぜ更新するのか
  ・どのサーバーが対象か
  ・いつ更新するのか
  ・サービス停止は発生するか
  ・失敗するとどのような影響があるか
  ・どのようにテストしたか
  ・失敗した場合どう元に戻すか

などを整理します。

変更管理では、このような情報を基に変更を評価し、必要な承認を行います。実務上のRFCフォームでも、変更理由、実施手順、影響・リスク、ロールバック方法などが重要な項目として扱われています。

RFCを工事の申請で例えてみよう

会社のビルで工事をすると考えてみよう。

例えば、オフィスの電気配線を変更したいとします。

工事担当者が、

「今日、ちょっと配線を変えてきます」

と言って、いきなり作業を始めたら危険です。

配線を間違えると、

• ・オフィスの電気が止まる
  ・パソコンが使えなくなる
  ・他の設備まで停止する
  ・営業中に業務が止まる

かもしれません。

そこで工事前に、

• ・どこを変更するのか
  ・なぜ変更するのか
  ・何時から作業するのか
  ・どこまで影響するのか
  ・誰が作業するのか
  ・問題が起きたらどう元に戻すのか

を書いた申請書を提出します。

責任者が確認し、

「この内容なら実施してよい」

と承認した後で工事します。

これをITシステムへ置き換えたものが、RFCのイメージです。

変更そのものではなく、変更を安全に実施するための申請なんだね。

そう。「変更したいから、影響や手順を確認して承認してください」というのが基本的なイメージだよ。

なぜRFCが必要なの？

本番環境の変更にはリスクがある

システム変更は、良くするために行うものです。

しかし、変更そのものが障害原因になることもあります。

例えば、

• ・ファイアウォールの設定変更で通信できなくなった
  ・OS更新後にアプリケーションが動かなくなった
  ・データベース変更で別機能へ影響した
  ・サーバー再起動後にサービスが立ち上がらなかった
  ・設定変更を戻す方法が分からなくなった

といった問題が考えられます。

そこで変更前に、

「この変更、本当にやって大丈夫？」

を組織的に確認します。

RFCを使って変更内容を記録することで、変更の目的、影響、リスク、実施方法、復旧方法などを関係者で確認できます。

RFCには何を書く？

組織によってRFCの様式は異なります。

代表的な項目は次のとおりです。

RFCから変更実施までの流れ

変更管理の詳細なプロセスは組織によって異なりますが、基本的なイメージは次のようになります。

変更の必要性が発生
        ↓
RFCを作成
        ↓
RFCを提出
        ↓
内容・影響・リスクを評価
        ↓
変更を承認／却下
        ↓
変更を計画・テスト
        ↓
本番環境へ変更
        ↓
結果を確認
        ↓
記録して終了

1．変更の必要性が発生する

変更が必要になる理由はさまざまです。

例えば、

• ・障害の再発を防ぎたい
  ・セキュリティパッチを適用したい
  ・新しい機能を追加したい
  ・システム性能を改善したい
  ・法令や社内基準へ対応したい
  ・サーバーを新しい機種へ交換したい

などです。

2．RFCを作成する

変更内容、理由、実施手順、影響範囲などを記録します。

3．影響やリスクを評価する

• ・重要サービスを停止するか
  ・顧客へ影響するか
  ・他システムへ影響するか
  ・セキュリティリスクはないか
  ・作業時間は適切か
  ・バックアップはあるか
  ・元に戻せるか

などを評価します。

4．承認する

リスクや影響に応じて、必要な担当者や責任者が変更を承認します。

影響が大きい変更では、複数の関係者で確認する場合があります。

5．変更を実施する

承認された日時・手順で変更を実施します。

6．変更後の結果を確認する

変更が成功したか確認します。

例えば、

• ・サービスが正常に動いているz
  ・エラーが発生していない
  ・監視アラートがない
  ・利用者が正常にアクセスできる

などを確認します。

7．記録して終了する

変更結果を記録し、必要に応じて振り返ります。

問題が発生した場合は、今後の変更へ活かします。

RFCのレビューでは、変更理由、実施内容、必要リソース、ロールバック方法などを確認してから判断する運用例があります。

CABとは？

RFCと一緒に覚えておきたい用語がCABだよ。
変更諮問委員会と訳されることが多い。

名前からすると、変更を承認する会議？

変更について助言・評価する関係者の集まりだよ。重要な変更ではCABの意見を踏まえて判断することがあるんだ。

CABには、変更内容に応じて、

• ・変更管理担当者
  ・システム担当者
  ・ネットワーク担当者
  ・セキュリティ担当者
  ・サービス担当者
  ・業務部門
  ・ベンダー

などが参加する場合があります。

重要なのは、

「変更を技術担当者一人の判断だけで行わない」

ことです。

ただし、すべての小さな変更を毎回CABで審議する必要があるわけではありません。

変更には種類がある

ITサービスマネジメントでは、変更の性質によって扱い方を分けます。

代表的には、

• ・標準変更
  ・通常変更
  ・緊急変更

という分類があります。

標準変更とは？

繰り返し実施され、あらかじめ承認されている変更

標準変更（Standard Change）は、手順やリスクがよく理解され、あらかじめ定められた方法で繰り返し実施できる変更です。

例えば、

• ・定型的なユーザー登録
  ・決められた手順での機器交換
  ・定期的な小規模設定変更

などが考えられます。

あらかじめ承認済みの変更モデルに従うため、毎回同じ重い承認手続きを行わない運用ができます。

毎週同じ安全な作業なのに、毎回大きな会議を開いたら大変だもんね。

そう。変更のリスクに合わせて管理の重さを変えることも重要なんだ。

通常変更とは？

通常変更（Normal Change）は、その変更について評価や承認が必要となる変更です。

例えば、

• ・本番サーバーのOSアップデート
  ・ネットワーク構成変更
  ・データベース設定変更
  ・新機能のリリース

などです。

影響やリスクを評価し、必要な権限を持つ人が承認してから実施します。

緊急変更とは？

緊急変更（Emergency Change）は、通常の変更手続きをすべて待っていると重大な被害が発生するため、迅速な対応が必要な変更です。

例えば、

• ・重大な脆弱性への緊急パッチ
  ・大規模障害を復旧するための設定変更
  ・サイバー攻撃を防ぐための緊急通信遮断

などです。

緊急なら承認なしで好きに変更していい？

そうではないよ。迅速化はするけれど、必要な評価や承認、記録は行うんだ。

緊急変更では、通常とは異なる迅速な承認ルートを用意することがあります。

標準変更・通常変更・緊急変更を比較

RFCとインシデント管理の違い

障害が起きたときの対応もRFCなの？

障害そのものへの対応はインシデント管理だけれど、その再発防止として恒久的な変更をするならRFCにつながることがあるよ。

例えば、

Webサービスが停止
      ↓
インシデント管理
      ↓
一時的にサービスを復旧
      ↓
原因調査
      ↓
設定変更が必要
      ↓
RFC
      ↓
恒久対策を実施

という流れがあります。

RFCとRFIの違い

名前が似ているので注意

RFIっていうのをどこかで見たんだけど、
関連用語？

文脈によって全然違うよ。略語だけ見るとかなり紛らわしいんだ。

RFIは一般的に、

Request for Information

の略です。

日本語では情報提供依頼などと呼ばれます。

企業が製品やサービスの導入を検討するとき、

・「御社にはどのような製品がありますか？」
・「この要件を満たせるサービスはありますか？」

などの情報をベンダーから集めるために使います。

一方、RFC（Request for Change）は、ITサービスやシステムへ変更を加えるための要求です。

RFCのCはChange、RFIのIはInformationなんだね。

そう。略語だけで判断せず、正式名称まで見ると間違えにくいよ。

RFI・RFP・RFQとの違い

調達分野では、RFIと一緒にRFPやRFQも使われます。

例えば、新しい勤怠管理システムを導入する場合、

RFI
どんなサービスがありますか？
        ↓
RFP
この要件で提案してください
        ↓
RFQ
価格を提示してください

という流れになることがあります。

RFCは、この調達プロセスとは別の文脈で使われます。

もう一つのRFC「Request for Comments」とは？

IT分野では、RFCという略語にはもう一つ非常に有名な意味があります。

それが、

Request for Comments

です。

同じRFCなの？

略語は同じだけど、意味は全然違うよ。

Request for Commentsは、インターネット技術に関する仕様や技術文書として使われます。

例えば、

• ・HTTP
  ・TCP/IP
  ・DNS
  ・SMTP

などのインターネット技術に関連するRFCがあります。

RFCは文脈で判断する

RFCには複数の意味があるため、問題文や周囲の単語を見ることが重要です。

次のような言葉があればRequest for Change

• ・変更管理
  ・ITIL
  ・Change
  ・CAB
  ・承認
  ・リスク
  ・本番環境
  ・ロールバック

次のような言葉があればRequest for Comments

• ・IETF
  ・TCP/IP
  ・HTTP
  ・インターネット標準
  ・プロトコル
  ・RFC番号

「RFC 〇〇番」みたいに番号が付いていたらRequest for Commentsっぽいね。

そう。逆に「変更を承認する」「CABで評価する」ならRequest for Changeだと考えやすいよ。

まとめ

RFC（Request for Change）とは、ITサービスやシステムへ変更を加えるための変更要求です。

本番環境の設定変更、OSアップデート、ネットワーク変更、新機能のリリースなどでは、変更が新たな障害を引き起こす可能性があります。

そのためRFCに、

• ・何を変更するのか
  ・なぜ変更するのか
  ・いつ実施するのか
  ・誰が実施するのか
  ・どこへ影響するのか
  ・どのようなリスクがあるのか
  ・失敗した場合どう戻すのか

などを記録します。

その内容を評価・承認してから変更を実施することで、変更によるサービス障害のリスクを管理します。

また、RFCは略語が非常に紛らわしい用語です。

Request for Changeのほかに、インターネット技術ではRequest for Commentsという意味でもRFCが使われます。

さらに、調達分野には、

• RFI：Request for Information
  RFP：Request for Proposal
  RFQ：Request for Quotation

があります。

試験では略語だけを見るのではなく、周囲の文脈から判断しましょう。

RFCって、Request for Commentsだけじゃなかったんだね。

そう。変更管理の文脈ではRequest for Changeとして使われるよ。

システムを変更する前に、『何を変えるのか、影響は何か、失敗したらどう戻すのか』を申請するんだね。

その理解でOK。特に本番環境では、変更そのものが障害の原因になることもあるからね。

クマノくらげ

X

難しいIT用語やビジネス用語を、できるだけ身近な例えで解説するブログです。 「専門用語を見ると眠くなる人」でも読めるように、画像や会話形式を多めにしています。 AWS12冠達成済み。