変更管理の活動
説明文の冒頭は何と書かれているか。箇条書きの 5 つで全部か。
「変更管理の活動では，主に次を行うことを理解する。」である。
「主に」が付いている。5 つで全部だとは書かれていない。
変更要求を承認するとき、考慮するものを 4 つ挙げよ。
リスク、事業利益、実現可能性、財務影響の 4 つである。
リスク，事業利益，実現可能性及び財務影響を考慮し，変更要求を承認する。
最後が「及び」でつながれている。
箇条書きの 4 つ目に置かれている条件は何か。
「可能であれば」である。
成功しなかった変更を戻す又は修正する活動を計画し，可能であれば試験する。
計画には条件が付かないが、試験には「可能であれば」が付く。 同じ箇条書きの 3 つ目では、承認された変更を条件なしで「試験する」と書かれている。
用語例の「変更のカテゴリー」の括弧には何が入っているか。閉じているか。
標準変更、通常の変更、プロジェクト変更、緊急変更の 4 つが入り、 末尾は「など」で開かれている。
この 4 つで全部だとは書かれていない。 4 つのそれぞれが何を指すか、どう違うかも書かれていない。
なお、同じ節の ① 変更管理方針 の説明文は「変更のカテゴリ」で長音符が無い。 表記が違う。どちらもシラバスの表記のままである。
シラバスは変更管理の活動で主に行うこととして、変更要求の優先度を決定する、リスク、事業利益、実現可能性及び財務影響を考慮し変更要求を承認する、承認された変更を計画、開発（構築）及び試験する、成功しなかった変更を戻す又は修正する活動を計画し可能であれば試験する、試験された変更はリリース及び展開管理に送られ稼働環境に展開する、の 5 つを中黒の箇条書きで挙げている。冒頭が「主に次を行う」であり、5 つで全部だとは書かれていない。用語例は 5 語で、変更のカテゴリーの括弧は 4 つを挙げたうえで「など」で開かれており、CAB と PIR には展開が付いていない。
箇条書きの 5 つ（シラバスの並び順のまま）
| 順 | 逐語 | 注意すべき語 |
|---|---|---|
| 1 | 変更要求の優先度を決定する。 | — |
| 2 | リスク，事業利益，実現可能性及び財務影響を考慮し，変更要求を承認する。 | 考慮するもの 4 つ |
| 3 | 承認された変更を，計画，開発（構築）及び試験する。 | 開発に「（構築）」が付く |
| 4 | 成功しなかった変更を戻す又は修正する活動を計画し，可能であれば試験する。 | 可能であれば |
| 5 | 試験された変更は，リリース及び展開管理に送られ，稼働環境に展開する。 | 他の細目名が現れる |
冒頭は「主に次を行う」であり、この 5 つで全部だとは書かれていない。 この表の「順」はシラバスの並び順である。実行の順序であるとは書かれていない。
用語例 5 つ（シラバスの並び順のまま）
| 順 | 用語例 | 括弧の中身 | 括弧の閉じ方 |
|---|---|---|---|
| 1 | 優先度 | — | — |
| 2 | 変更のカテゴリー | 標準変更，通常の変更，プロジェクト変更，緊急変更など | 「など」で開いている |
| 3 | ロールバック | 切り戻し | 閉じている |
| 4 | 変更諮問委員会 | CAB（展開なし） | 閉じている |
| 5 | 変更実施後のレビュー | PIR（展開なし） | 閉じている |
この表の「順」はシラバスの並び順であって、重要度でも扱う順でもない。 括弧の中身は、2 が例示、3 が和語、4・5 が展開の付かない略称である。 3 つ目の括弧の「切り戻し」を、シラバスが「ロールバックと同じものである」と 明記しているわけではない。
この細目でのシラバスの書き方
| 項目 | 記載 |
|---|---|
| 説明文 | 一文＋中黒の箇条書き 5 項目 |
| 冒頭 | 「主に次を行うことを理解する。」 |
| 列挙に付くラベル | 用語例 |
| 用語例の数 | 5 |
| 節の中の位置 | （12）変更管理 の ③（①② が先にある） |
シラバスが書いていること
Section titled “シラバスが書いていること”説明文は一文で、その後に中黒の箇条書きが 5 項目続く。
変更管理の活動では，主に次を行うことを理解する。
・変更要求の優先度を決定する。 ・リスク，事業利益，実現可能性及び財務影響を考慮し，変更要求を承認する。 ・承認された変更を，計画，開発（構築）及び試験する。 ・成功しなかった変更を戻す又は修正する活動を計画し，可能であれば試験する。 ・試験された変更は，リリース及び展開管理に送られ，稼働環境に展開する。
続けて 5 つが列挙されている。
用語例 優先度，変更のカテゴリー（標準変更，通常の変更，プロジェクト変更，緊急変更など）， ロールバック（切り戻し），変更諮問委員会（CAB），変更実施後のレビュー（PIR）
中黒の箇条書きを持つ唯一の細目
Section titled “中黒の箇条書きを持つ唯一の細目”この 29 細目のなかで、中黒（・）の箇条書きを持つのはこの細目だけである。
括弧付きの英小文字で番号を振った箇条書きを持つ細目は 3 つある （2.（15）① インシデントの対応＝a)〜e)、2.（16）サービス要求管理＝a)〜d)、2.（17）問題管理＝a)〜e)）が、 記法が違う。
冒頭の「主に」
Section titled “冒頭の「主に」”「主に次を行う」と書かれている。
5 つで全部だとは書かれていない。 ほかに何を行うかは書かれていない。
箇条書きの 5 つ
Section titled “箇条書きの 5 つ”1. 変更要求の優先度を決定する
「優先度」は用語例の 1 つ目でもある。
何を基準に優先度を決めるかは書かれていない。
2. リスク，事業利益，実現可能性及び財務影響を考慮し，変更要求を承認する
考慮するものが 4 つ挙げられている。
| 順 | 考慮するもの |
|---|---|
| 1 | リスク |
| 2 | 事業利益 |
| 3 | 実現可能性 |
| 4 | 財務影響 |
この表の「順」は説明文に現れる順であって、重要度ではない。
最後が「及び」でつながれている。 4 つのそれぞれが何を指すか、どう重み付けるかは書かれていない。
3. 承認された変更を，計画，開発（構築）及び試験する
行いが 3 つ —「計画」「開発（構築）」「試験」。
「開発」に「（構築）」という括弧が付いている。 両者が同じものかどうかは書かれていない。
対象は「承認された変更」である。 2 の承認を経たものと読める書き方だが、 シラバスがそう明記しているわけではない。
4. 成功しなかった変更を戻す又は修正する活動を計画し，可能であれば試験する
対象は「成功しなかった変更」である。
行いは「戻す又は修正する活動」に対して 2 つ —「計画し」「試験する」。
試験にだけ「可能であれば」という条件が付く。
3 つ目では条件なしで「試験する」と書かれているのに対し、 ここでは条件が付く。この書き分けはシラバスのものである。
5. 試験された変更は，リリース及び展開管理に送られ，稼働環境に展開する
この項目には、同じ小分類の別の細目の名前が現れる。
| 語 | 一致する箇所 |
|---|---|
| リリース及び展開管理 | 2.（14）の細目名 |
| 稼働環境 | 2.（13）③ の説明文／2.（14）の説明文と用語例 |
シラバスが「その細目のことである」と明記しているわけではない。 名前が一致する、というところまでである。
5 つの並びを実行順序として読まない
Section titled “5 つの並びを実行順序として読まない”優先度の決定、承認、計画・開発（構築）・試験、戻す又は修正する活動、展開、という並びは、 順に進む流れのように見える。
しかし、シラバスはこの並び順が実行順序であるとは書いていない。 冒頭も「主に次を行う」であって、「次の順に行う」ではない。
このノートでは、5 つを矢印でつないだ流れ図を作らない。
ただし、「承認された変更」（3）・「試験された変更」（5）のように、 前の項目に現れる語を受ける形の語を含む項目がある点は、逐語のとおりである。 それが前の項目の結果を指すと、シラバスが書いているわけではない。
用語例 — 括弧の付く 4 件
Section titled “用語例 — 括弧の付く 4 件”| 順 | 用語例 | 括弧の中身 | 役割 |
|---|---|---|---|
| 2 | 変更のカテゴリー | 標準変更…緊急変更など | 例示（開いている） |
| 3 | ロールバック | 切り戻し | 和語（同じものとは明記なし） |
| 4 | 変更諮問委員会 | CAB | 略称（展開なし） |
| 5 | 変更実施後のレビュー | PIR | 略称（展開なし） |
この表の「順」は用語例の並び順に振った番号であり、括弧を持つ 4 件だけを抜き出している。 3 つ目の括弧の「切り戻し」を、シラバスが「ロールバックと同じものである」と 明記しているわけではない。
1 つ目の「優先度」には括弧が付かない。
変更のカテゴリーの括弧
Section titled “変更のカテゴリーの括弧”2 つ目の括弧には 4 つが入り、末尾が「など」で開かれている。
| 順 | 括弧の中の語 |
|---|---|
| 1 | 標準変更 |
| 2 | 通常の変更 |
| 3 | プロジェクト変更 |
| 4 | 緊急変更 |
この表の「順」は括弧の中の並び順であって、重要度ではない。
この 4 つで全部だとは書かれていない。 4 つのそれぞれが何を指すか、どう違うかも書かれていない。
2 つ目だけが「通常の変更」と「の」を持つ。 ほかの 3 つは「〜変更」である。 シラバスの表記のままである。揃えない。
「カテゴリ」と「カテゴリー」
Section titled “「カテゴリ」と「カテゴリー」”この細目の用語例は「変更のカテゴリー**」で、長音符が付く。**
同じ節の ① 変更管理方針 の説明文は「変更のカテゴリ」で、長音符が無い。
| 細目 | 表記 |
|---|---|
| 2.（12）① 変更管理方針 | 変更のカテゴリ |
| 2.（12）③（この細目） | 変更のカテゴリー |
どちらもシラバスの表記のままである。揃えない。 シラバスが両者を同じものとして扱っているかどうかも書かれていない。
また、① が定義するのは「緊急の変更を含む変更のカテゴリ」であり、 この細目の括弧が挙げる 4 つがその中身だとは書かれていない。
CAB と PIR に展開が無い
Section titled “CAB と PIR に展開が無い”どちらも略称だけが括弧に入り、英語のつづりは書かれていない。
シラバスが展開していない略称を、このノートで補うことはしない。
この 29 細目には、展開の付かない略称がほかにもある — 1.（4）の SLO・SLI、2.（1）の PDCA、2.（4）の SAM、2.（5）の CI・CMDB、2.（8）の SaaS・PaaS・IaaS、2.（11）の CPU（管理指標の括弧の中）、2.（12）② の RFC、2.（18）の MTBF・MTTR・MTBSI・MTRS。
この細目で書かないこと
Section titled “この細目で書かないこと”次はいずれもこのノートの根拠に含まれていない。
- CAB・PIR が何の略か（シラバスが展開していない）
- 変更のカテゴリー 4 つのそれぞれの中身、違い、使い分け
- 優先度の決め方、承認の基準、誰が承認するか
- 「事業利益」「財務影響」がそれぞれ何を指すか
- 「開発」と「構築」の違い
- ロールバックをどう行うか
- 変更諮問委員会の構成、権限
- 変更実施後のレビューをいつ、誰が行うか
- 箇条書きの 5 つが実行順序かどうか
名前から内容を推測して書くことは spec.md §8.1a に反する。
同じ節の ①（変更管理方針）・②（変更管理の開始）の内容を、この細目に書かない。 それぞれ別の細目である。