4プロセスは「1つの障害対応の流れ」として理解する
CIS-ITSMの学習で、Incident・Problem・Change・Requestを別々の暗記項目として覚えると、本番のケース問題で手が止まります。設問は「Incidentの定義はどれか」のような単発の知識ではなく、「この状況で起票すべきはどれか」「次にどのプロセスへ渡すか」を、業務の流れの中で選ばせてくるからです。4つを別物として並べても、その判断力は身につきません。
最初に、4つを一続きの流れとして言い切ってしまいます。Incident は止血です。 止まったサービスを、原因が分からなくても回避策込みで早く戻すことが目的です。Problem は再発防止です。 止血が終わった後、なぜ起きたのかを突き止めて、同じ障害を二度起こさないことが目的です。Change は変更を安全に通す関所です。 再発防止でも復旧でも、本番環境に手を入れる必要が出たら、リスクと承認を管理しながら変更を実行します。Request は定型の依頼処理です。 壊れたものの復旧ではなく、利用者が「標準サービスを使わせてほしい」と申請する流れを、承認と履行タスクで回します。
この4つが混同されるのは、入口の症状が似て見えるからです。たとえば「業務システムが使えない」という一報は、停止からの復旧なら Incident ですが、「新しい権限を申請したい」「アカウントを発行してほしい」なら Request です。同じ「システムが使えない」でも、壊れているのか、まだ権限を持っていないだけなのかで、入るプロセスが変わります。CIS-ITSMはこの最初の振り分けを、ケース文の細部から読み取らせます。だからこの記事は、4プロセスを横に並べて違いを一望できる比較表と、縦につなげて受け渡しを追う連携フローを軸に構成しています。プロセス単体の定義ではなく、「並べて初めて見える境界」を持ち帰ってください。
なお、ServiceNowの試験範囲やプロセスの推奨実装はリリース（YokohamaやZurichなど）やプラグイン構成で細部が変わりえます。本記事は公式ドキュメントと公開されている試験範囲、PDI（Personal Developer Instance）で確認できる挙動をもとに整理していますが、最終的な仕様は公式情報とお手元のインスタンスで確認することをおすすめします。
4プロセスを横に並べる比較表
まず全体像です。目的・発火トリガ・主なテーブル・状態モデル・期日の考え方・主担当ロールという6つの観点で、4プロセスを一望します。この表は本記事の中心なので、各プロセスの細部を読み進める前に、ここで「どこが違うのか」の骨格を掴んでください。
横にスクロールできます
| 観点 | Incident | Problem | Change | Request |
|---|---|---|---|---|
| 目的 | 止血（早期復旧で利用者影響を減らす） | 再発防止（根本原因を分析し再発を減らす） | 変更を安全に通す（本番影響をリスク・承認込みで管理） | 定型依頼の履行（標準サービス・物品・権限を提供） |
| 発火トリガ | 監視アラート、利用者からの障害報告、メール、電話 | 繰り返すIncident、傾向分析、プロアクティブな予兆検知 | 復旧や恒久対応に伴う本番変更の必要、定期保守 | 利用者がService CatalogでCatalog Itemを申請 |
| 主なテーブル | incident | problem | change_request | sc_request（REQ）/ sc_req_item（RITM）/ sc_task（SCTASK） |
| 状態モデル | New → In Progress → On Hold → Resolved → Closed | 原因分析 → Known Error化 → 恒久対応の起票 → クローズ | 計画・評価 → 承認 → スケジュール → 実装 → レビュー → クローズ | 申請 → 承認（必要時）→ 履行タスク割当 → 完了 |
| 期日・SLAの考え方 | Response/Resolution SLAで復旧時間を測る | 即時復旧ではなく中長期の調査期限で考える | Maintenance WindowとConflict Detectionで実施可能な時間を判断 | Fulfillmentの提供条件・所要時間で考える |
| 主担当ロール | サービスデスク、担当Assignment Group | Problem Coordinator、原因分析の担当者 | Change Manager、承認に関わるCAB | Fulfillment Group、承認者 |
表の読み方として、特に試験で効くのは「目的」と「主なテーブル」の列です。目的が違えば、同じ報告でも入るべきプロセスが変わります。そしてRequestだけがREQ・RITM・SCTASKという3階層のテーブルに分かれている点は、他の3プロセスが基本的に1レコード中心で動くのと対照的で、誤答を誘いやすい論点です。状態モデルの列は、IncidentのResolvedとClosedの区別（利用者確認後に確定するのか、自動クローズか）や、Changeがタイプによって通る承認ステップの重さが変わる点を、後の各セクションで掘り下げます。
プロセス間の受け渡しフロー
横の比較で違いを掴んだら、次は縦のつながりです。実務では、1件の障害対応が複数プロセスをまたいで進みます。ここでは「どこで受け渡しに失敗しがちか」という観点で、典型的な事故シナリオに沿って流れを追います。
想定するのは、ある業務システムが断続的に落ちる事象です。最初は単発の障害に見えますが、止血と再発防止と変更が連鎖していきます。
- 発生と止血（Incident）：監視または利用者から「システムが落ちた」と報告が入る。ImpactとUrgencyからPriorityを決め、担当グループへ割り当てる。再起動で復旧したので、いったんResolvedにする。ここまでがIncidentの役割。
- 再発の認識（Incident → Problem）：同じ障害が週内に何度も再発する。ここで受け渡しの最初の失敗が起きやすい。担当者が「再起動で戻るから」と毎回Incidentを閉じるだけにすると、根本原因が誰にも追われないまま放置される。正しくは、繰り返すIncident群を1つのProblemに紐づけ、再発傾向と影響範囲を可視化する。
- 原因分析と暫定対応（Problem）：Problem側で影響CI・症状・発生条件を整理し、調査を分担する。原因が特定できたらKnown Error化し、回避策（Workaround）を明文化して、次回同じIncidentが起きたときにサービスデスクが即座に参照できるようにする。ここで暫定の回避策（Workaround）と恒久対応（根本解決）を混同すると、「回避策を入れたから解決済み」と誤って扱い、Problemを早期に閉じてしまう。これが二番目の失敗。
- 恒久対応の起票（Problem → Change）：根本対応として本番設定の変更が必要だと分かったら、ProblemからChangeを起票する。ここを飛ばして現場判断で本番に手を入れると、変更の記録もリスク評価も残らない。Problemで原因が分かっても、変更はChangeの統制に必ず乗せる、という受け渡しが要点。
- 変更の実行（Change）：変更タイプ（Standard / Normal / Emergency）を判断し、必要な承認・実装計画・テスト計画・バックアウト計画を整える。Conflict DetectionやMaintenance Windowで実施可能な時間帯を確認してから実装する。実装後はレビューし、失敗や影響があれば、その結果を再びProblemやKnowledgeへ戻す。
- Requestの位置づけ（独立した流れ）：上の連鎖とは別に、Requestは「壊れていないものの定型依頼」を扱う独立した流れとして並走する。たとえば原因対応の過程で「調査用に追加のアクセス権がほしい」となれば、それはIncidentでもChangeでもなくRequestで申請する。逆に、利用者の「システムが使えない」という一報をすべてRequestのCatalog申請で受けてしまうと、復旧すべき障害が履行タスクの列に埋もれる。これが三番目の、そして最も入口で起きやすい失敗。
この連鎖を1枚で言うと、Incidentで止め、Problemで原因を追い、Changeで直し、その全体とは別レーンでRequestが定型依頼を回す、という構図です。受け渡しの失敗は決まって境目で起きます。Incidentを閉じて満足する、Workaroundで解決した気になる、現場判断でChangeを飛ばす、何でもRequestで受ける——この4つを覚えておくと、ケース問題で「次にどのプロセスへ渡すか」を問われたときに迷いにくくなります。
Incidentで問われる判断とハマりどころ
ここから各プロセスの固有の中身に入ります。Incidentで核になるのはPriorityの決め方です。Priorityは担当者の主観で決めるものではなく、Impact（影響範囲の大きさ）とUrgency（どれだけ急ぐか）の組み合わせから導きます。設問では「複数部署で業務が止まり、復旧期限も短い」のように、ImpactとUrgencyの両方が読み取れる文章が示され、最初に確認すべき組み合わせを問われます。Catalog ItemやBusiness Ruleといった無関係な選択肢に引っ張られず、影響範囲と緊急度に目を向けられるかが分かれ目です。
実務でのハマりどころは、ResolvedとClosedの扱いです。Resolvedは「復旧したと担当者が判断した」状態で、Closedは「利用者の確認や一定期間の経過を経て確定した」状態です。この二段階を「同じもの」と捉えると、利用者確認の前に案件を締めてしまう運用になりがちです。PDIでImpactとUrgencyを動かしてPriorityの変化を見たら、続けてResolvedとClosedの遷移条件も確認しておくと、状態モデルの設問に強くなります。
PriorityとImpact・Urgencyの関係で取り違えやすいのは、「優先度が高い＝影響が大きい」と短絡することです。Impactは影響の広さ、Urgencyは時間的な切迫度で、両者は独立しています。役員1人だけが使う機能が止まっていて即時復旧が必要な状況（Impactは狭いがUrgencyは高い）と、多数の利用者に影響するが業務上は数日待てる状況（Impactは広いがUrgencyは低い）では、Priorityの導かれ方が変わります。設問がどちらの軸を強調しているかを読み分けられると、影響の広さだけに引っ張られて誤答する事故を避けられます。なお、ImpactとUrgencyからPriorityをどう算出するかはPriority Lookup Rules（Data Lookup）で定義され、組織ごとにカスタマイズされる点も、実務では前提として知っておくとよいでしょう。
もう一つの論点がMajor Incidentです。これは影響の大きい障害を、通常のIncident処理に加えて組織的な情報共有・役割分担・復旧統制のもとで扱う特別な進め方です。「重大そうな名前だから」で選ぶのではなく、関係者への周知と統制が必要な大規模障害という実態で判断します。実務でのつまずきは、Major IncidentとProblemを「どちらも重大な障害だから」と混同することです。Major Incidentはあくまで今起きている大規模障害を統制下で「早く復旧させる」止血側の扱いであり、原因を追って再発を防ぐProblemとは目的が異なります。同じ大障害でも、いま止めるのがMajor Incident、二度と起こさないのがProblem、と時間軸で切り分けます。
Incidentでもう一つ問われやすいのが、Knowledgeへの接続です。解決した障害の対処手順や回避策をKnowledge記事化しておくと、次に同種の問い合わせが来たときにサービスデスクが即座に参照でき、復旧時間そのものが短くなります。設問では「解決内容を次回対応で再利用したい」という記述から、Discovery ScheduleやMID ServerではなくKnowledgeを選ばせる形が出ます。止血して終わりではなく、復旧の知見を次の止血を速くするために残す、という発想がIncidentの仕上げです。
Problemで問われる判断とハマりどころ
Problemの中心は、Workaround・Known Error・根本原因（RCA）という3つの言葉の使い分けです。Workaroundは原因が未特定でも一時的にサービスを使えるようにする回避策、Known Errorは原因と回避策の両方が分かっている状態、RCAはそこに至るための原因分析そのものを指します。設問では「原因は不明だが一時的に使える手順がある」をWorkaroundと、「原因と回避策が明確で次回Incident対応でも参照したい」をKnown Errorと判別させる形がよく出ます。
3つの言葉に加えて、Reactive ProblemとProactive Problemの区別も論点になります。Reactiveは既に起きたIncidentを起点に原因を追う流れ、Proactiveはまだ障害になっていない予兆や傾向（たとえば特定CIで軽微なエラーが増えている兆候）から先回りして原因を潰す流れです。設問が「再発したから調査する」のか「まだ障害は出ていないが傾向が気になる」のかで、どちらの文脈かを読み分けられると、Problemの目的を正しく捉えられます。
実務でのハマりどころは、複数Incidentの紐づけを軽視することです。Problemに関連Incidentを束ねる目的は、フォームの見栄えでも権限付与でもなく、影響範囲と再発傾向を把握して原因分析の優先度を判断するためです。1件のIncidentだけを見ていると、それが全社的な再発障害の一部なのか、孤立した事象なのかが分かりません。たとえば「同じエラーメッセージのIncidentが3部署から週に5件ずつ上がっている」と分かって初めて、そのProblemに人を割く価値があると判断できます。逆に、紐づけをしないまま個々のIncidentを閉じ続けると、全体としては大きな再発障害なのに、現場には「たまに起きる小さな不具合」としか見えません。
もう一つの判断場面が、Problem Taskの使いどころです。原因分析は1人で完結しないことが多く、「ネットワーク側のログを調べる担当」「アプリのスタックトレースを追う担当」のように調査を分担します。このとき各調査をProblem Taskとして切り出すと、誰が何を調べているかと進捗が可視化されます。Problem本体に全部を書き込んで属人化させるのではなく、調査の単位でTaskに分ける、という設計判断がProblemを回す鍵です。PDIでは、IncidentからProblemを作成して関連Incidentを追加し、Problem Taskで調査を分担し、Known ErrorとWorkaroundに対応するフィールドや関連リストがどこに表示されるかを確認しておきます。さらに、原因と回避策が固まったWorkaroundをKnowledge化しておくと、Incident側の止血が速くなる、というProblem→Knowledgeの流れも併せて押さえます。
Changeで問われる判断とハマりどころ
Changeの最重要論点は、Standard・Normal・Emergencyの3タイプの使い分けです。表で対比します。
横にスクロールできます
| 観点 | Standard Change | Normal Change | Emergency Change |
|---|---|---|---|
| 代表例 | 定型で低リスクの反復作業 | 通常の本番変更 | 重大障害回避など急ぐ変更 |
| 承認 | 事前承認済みのChange Modelを使う | リスク評価後にCABなどで承認を通す | 緊急承認や事後レビューが必要 |
| 試験での見方 | 低リスク・定型・頻繁・手順が確立済み | 計画・CAB・影響分析が中心 | 緊急性は高いが記録とレビューは省かない |
Standard Changeは「事前にリスク評価とモデル化が済んでいる、繰り返し実施する低リスク変更」です。設問では「毎月同じ手順で実施され低リスク」という記述からStandardを選ばせます。誤答を誘うのは「簡単そうだから何でもStandard」という発想で、手順が確立していない変更をStandardにしてはいけません。Emergency Changeの罠はさらに分かりやすく、「緊急だから承認も記録も不要」と覚えてしまうことです。Emergencyは対応を急ぐだけで、統制と記録、事後レビューはむしろ省略してはいけない、というのが正しい理解です。
3タイプの判断で実務的に効くのは、「定型かどうか」ではなく「事前にリスク評価が完了しているか」を基準にすることです。たとえば毎週実施するバッチの再起動でも、手順が文書化されレビュー済みで、失敗時の影響と戻し方が事前に合意されていれば、それはStandard Changeとしてモデル化できます。一方、頻度が低くても、影響範囲やリスクをその都度評価する必要があるならNormalです。「よくやる作業だからStandard」ではなく「リスクを事前に潰し切ってあるからStandard」という順序で考えると、設問の引っかけに強くなります。
判断材料として押さえるべきフィールドも問われます。本番変更の影響範囲を見るならAffected CI、変更が失敗したときに元へ戻す手順ならBackout Plan、実施タイミングが他の変更や停止予定と衝突しないかを見るならConflict Detection、というように、設問のキーワードと確認すべき項目を結びつけられるかが要点です。ここで実務上の落とし穴になりやすいのがBackout Planの軽視です。「うまくいく前提」で変更を計画し、失敗時にどう戻すかを書かないまま実装に進むと、本番で問題が起きたときに復旧手順が手元になく、Incidentを誘発します。変更の成否は、進める手順と同じ重みで「戻す手順」を用意できているかで決まる、という観点を持っておきます。
CABとConflict Detectionの関係も整理しておきます。CABは変更の承認とリスク評価を行う体制で、Conflict Detectionは個々の変更が時間帯やCIの面で他の変更・停止予定と衝突しないかを機械的に検出する仕組みです。CABを「会議の名前」としてだけ覚えると、承認とリスク評価という役割を見落とします。逆にConflict Detectionを承認プロセスと混同すると、「衝突がなければ承認も不要」と誤解しかねません。承認の判断（CAB）と技術的な衝突検出（Conflict Detection）は別の関門だ、と分けて捉えてください。PDIではChange RequestのTypeを切り替えて必要項目の違いを観察し、Risk・Impact・Priorityの見え方、Affected CIやChange Taskの追加、実装計画・テスト計画・バックアウト計画の入力欄を実際に触っておきます。
Requestで問われる判断とハマりどころ
Requestの核は、REQ・RITM・SCTASKという3階層の粒度です。これは他の3プロセスにない構造で、混同が最も起きやすい論点です。
横にスクロールできます
| 要素 | テーブル | 役割 | 試験での見方 |
|---|---|---|---|
| REQ | sc_request | 1回の申請全体 | 複数RITMをまとめる親の単位 |
| RITM | sc_req_item | 申請されたCatalog Itemごとの単位 | 承認・状態・変数・履行の中心 |
| SCTASK | sc_task | 履行担当者が実施する作業 | 部署ごとの作業分担、完了管理 |
たとえば1回の申請でPCとアカウント発行を同時に頼むと、申請全体をまとめる親がREQ、それぞれのCatalog Itemに対応する処理単位がRITM、ネットワーク担当やアカウント担当が実際に動く作業がSCTASKです。設問では「申請全体の親はどれか」「Catalog Itemごとに承認・状態を追う単位はどれか」「作業を部署ごとに分けるのはどれか」と、粒度を取り違えていないかを問われます。
入口の論点として、Catalog ItemとRecord Producerの違いも頻出です。どちらもService Catalog上の申請フォームですが、Catalog ItemはRequest（REQ/RITM）として承認・履行の流れに乗せるのに対し、Record Producerは通常テーブルへ直接レコードを作ります。承認やフルフィルメントに乗せたいならCatalog Item、単にレコードを作りたいだけならRecord Producer、という線引きを一文で言えるようにしておきます（詳しくはCatalog ItemとRecord Producerの違いを参照）。
3階層を取り違えると、実務では具体的に何が壊れるのかも押さえておきます。たとえばSCTASKの粒度で考えるべき「部署ごとの作業分担」をRITMの粒度でやろうとすると、1つのアイテムに複数部署の作業が混ざり、誰がどこまで終わったかを追えなくなります。逆に、本来1つの申請（REQ）にまとめるべき複数アイテムを別々のREQで起票すると、申請者から見て「1回の手続き」のはずが複数案件にばらけ、進捗の見え方が悪化します。粒度の取り違えは、レポートや承認の単位がずれるという形で効いてきます。
承認と履行の関係も論点です。RITMは承認・状態・変数・履行の中心となる単位で、承認はRITMの段階で回ることが多く、承認後にFlow DesignerやWorkflowがSCTASKを担当グループへ割り当てます。ここで「承認さえ通れば完了」と捉えると、その後の履行タスク（SCTASK）の完了管理を見落とします。承認は履行の入口であって終わりではない、という流れを押さえておくと、状態遷移の設問で「承認後に何が起きるか」を正しく追えます。
最大のハマりどころは、冒頭でも触れた入口の振り分けです。「業務システムが利用できない」という復旧依頼までRequestで受けてはいけません。壊れたものの復旧はIncident、標準的な依頼はRequest、という境界を最初に引けるかが、Requestを正しく扱う前提になります。判断に迷ったときは「利用者は今あるサービスの復旧を求めているのか、それとも新しい何かの提供を求めているのか」を問い直すと振り分けやすくなります。利用者を条件で絞ってCatalog Itemの表示を制御したい場合はUser Criteriaを確認する、という点も併せて押さえておきます。PDIではCatalog Itemを開いてVariables・User Criteria・Flowの設定場所を確認し、申請を1件送ってREQ・RITM・SCTASKの関連を追い、承認あり・なしで状態遷移を比較してみてください。
4プロセスをまたいで混同しやすいペア
各プロセス単体の誤解は前の各セクションで触れました。ここでは、4つを並べたときに「どっちだったか」と迷いやすい境界のペアを、判断の決め手とともに整理します。ケース問題はこの境界そのものを狙ってくるので、ペアで覚えておくと選択肢を絞りやすくなります。
- Incident と Request：壊れたものの復旧か、まだ持っていない標準サービスの申請か。決め手は「現状の復旧を求めているか／新規の提供を求めているか」。
- Incident と Problem：いま止血するのか、再発を防ぐのか。決め手は時間軸で、「今すぐ戻す」がIncident、「二度と起こさない」がProblem。
- Problem と Change：原因を突き止めるところまでか、本番に手を入れるところか。決め手は「分析の領域か／変更の実行の領域か」。原因が分かっても変更はChangeに乗せる。
- Workaround と 恒久対応：一時的に使えるようにするだけか、根本を直すか。決め手は「原因を解消したか否か」。回避策は解決ではない。
- Major Incident と Problem：大規模障害を統制下で早く戻すのか、その原因を追うのか。決め手は、同じ大障害でも「復旧（Major Incident）」と「再発防止（Problem）」で目的が違う点。
- Catalog Item と Record Producer：承認・履行に乗せるRequestかRecord作成専用か。決め手は「REQ/RITMの流れに乗せたいか／通常テーブルへ直接作りたいか」。
この一覧を、各プロセスの目的（止血・再発防止・変更の関所・定型依頼）と重ねて読むと、境界の理由が腑に落ちます。混同が起きるのはたいてい入口の症状が似ているからで、目的に立ち返ると振り分けの軸が定まります。
PDIで4プロセスを1本のシナリオで通す
各プロセスを個別に触ったら、最後は横断シナリオで連携を体験します。バラバラに確認するより、1件の障害対応として4プロセスをつなげたほうが、受け渡しの感覚が身につきます。題材は前掲の「断続的に落ちる業務システム」をそのまま使います。
- Incidentを起票して止血する：Incidentを1件作成し、ImpactとUrgencyを変えてPriorityの変化を確認する。Assignment Group・Assigned to・CI・SLAの表示位置も見ておく。回避策で復旧したらResolvedにし、ResolvedとClosedの遷移条件を確認する。
- Problemへ受け渡す：同じ障害が再発した想定で、IncidentからProblemを作成し、関連Incidentを複数紐づける。Problem Taskで調査を分担し、Known ErrorとWorkaroundのフィールドを埋める。
- Changeで恒久対応する：ProblemからChangeを起票し、Typeを切り替えて必要項目の差を見る。Affected CIを追加し、実装計画・テスト計画・バックアウト計画を入力し、Conflict Detectionの挙動を確認する。
- Requestを並走させる：同じ対応の中で「調査用の追加権限がほしい」という想定で、Catalog Itemから申請を1件出し、REQ・RITM・SCTASKがどう生成されるかを追う。これがIncident/Change側の流れとは独立して回ることを体感する。
この一連を通すと、比較表で見た「目的」「テーブル」「状態」の違いが、実際のレコードの動きとして腑に落ちます。完璧に作り込む必要はありません。各ステップで「なぜこのプロセスを選び、次にどこへ渡したか」を一文でメモに残すことのほうが、ケース問題対策としては価値があります。
まとめ
CIS-ITSMの4プロセスは、別々の暗記項目ではなく、1つの障害対応の中で連携する役割分担として理解すると、本番のケース問題で迷いにくくなります。Incidentは止血、Problemは再発防止、Changeは変更を安全に通す関所、Requestは定型依頼の独立した流れ——この4つの目的の違いが土台です。
横の比較表では、目的・テーブル・状態・SLA・ロールの観点で4プロセスの境界を一望しました。特にRequestだけがREQ・RITM・SCTASKの3階層を持つ点、ChangeがStandard/Normal/Emergencyでタイプ分けされる点は、誤答を誘いやすい論点です。縦の連携フローでは、受け渡しの失敗が決まって境目で起きること——Incidentを閉じて満足する、Workaroundで解決した気になる、現場判断でChangeを飛ばす、何でもRequestで受ける——を確認しました。
学習の仕上げは、PDIで4プロセスを1本のシナリオとして通すことです。レコードが相互にどう関連づくかを自分の手で動かすと、表で見た違いが実感に変わります。全体像の確認はCIS資格対策ハブ、ITSM領域の深掘りはCIS-ITSMハブ、理解度の確認はCIS-ITSM模擬試験で、知識とケース判断を往復させてください。
よくある質問
IncidentとRequestは、利用者から見ると同じ「困りごと」に見えます。どう振り分けますか。 判断軸は「壊れているか、まだ持っていないだけか」です。標準サービスが期待どおり動かない・止まっているなら復旧が目的なのでIncident、標準サービスや権限・物品を新たに申請したいだけならRequestです。同じ「システムが使えない」でも、停止からの復旧依頼はIncident、未付与の権限の申請はRequestになります。
Incidentが解決したら、Problemは作らなくてよいですか。 単発で再発の兆候がなければ必須ではありません。ただし同じ障害が繰り返している、または回避策で戻しているだけで根本原因が不明、という場合はProblemを作り、再発防止につなげます。Incidentを閉じることと、原因を追わないことは別だと考えてください。
WorkaroundとKnown Errorは何が違いますか。 Workaroundは原因が未特定でも一時的にサービスを使えるようにする回避策です。Known Errorは原因と回避策の両方が判明している状態を指します。回避策があるだけでは「解決」ではなく、恒久対応が必要ならChangeへ進みます。
Emergency Changeは緊急なので、承認や記録を省略してよいですか。 いいえ。Emergencyは対応を急ぐためのタイプであって、統制を省くものではありません。緊急承認の経路や事後レビュー、記録はむしろ確実に残します。「緊急だから統制不要」は典型的な誤解です。
REQ・RITM・SCTASKの違いを一言で言うと何ですか。 REQは申請全体の親、RITMは申請されたCatalog Itemごとの処理単位、SCTASKは履行担当者が実施する作業単位です。1回の申請（REQ）に複数のアイテム（RITM）が含まれ、各アイテムの履行が複数の作業（SCTASK）に分かれる、という階層で捉えます。
ProblemとChangeの境目はどこですか。 Problemは原因を分析して再発防止策を見つけるところまで、Changeはその恒久対応として本番環境に変更を加えるところを担います。Problemで原因が分かっても、本番に手を入れる変更はChangeの承認・リスク管理に必ず乗せる、という受け渡しが境目です。
