APB-SM

①「現状の問題点・課題の抽出型」

概要:与えられた組織・サービスの現状から、問題・ボトルネック・リスクを特定させる問題。

根拠（複数資料共通）
問合せ増加・対応遅延などの課題提示 [R6A_SM.pdf | PDF]
手続きが分かりづらい・回答が遅い [R7A_SM.pdf | PDF]
テレワーク環境で品質維持が困難 [R6S_SM.pdf | PDF]
よくある聞き方
「問題点を○つ挙げよ」
「課題を明らかにせよ」
「原因を述べよ」
本質
👉 ケース文の「困っている描写」を拾えるか

②「改善施策・解決策の立案型」

概要特定の課題に対して、どのような対策・改善を行うべきかを問う。

根拠
サービスデスク設立による効率化 [R6A_SM.pdf | PDF]
ポータル＋FAQで自己解決促進 [R7A_SM.pdf | PDF]
リモート対応の体制強化 [R6S_SM.pdf | PDF]
よくある聞き方
「どのような施策を講じるべきか」
「改善策を述べよ」
「対応方針を示せ」
本質
👉 ITILプロセスを踏まえた“実務的な打ち手”を答える

③「プロセス／運用設計の具体化型」

概要インシデント管理、変更管理などの手順・役割・フローを具体的に問う。

根拠
インシデントの分類・優先度・エスカレーション [R4S_SM.pdf | PDF]
変更管理の評価・承認・実施プロセス [R4A_SM.pdf | PDF]
サービスデスクの問い合わせ管理・優先度付け [R7A_SM.pdf | PDF]
よくある聞き方
「処理手順を述べよ」
「役割分担を示せ」
「どのように分類・優先度付けするか」
本質
👉 運用の流れを具体的に説明できるか

④「指標・SLA・評価に関する分析型」

概要サービス品質を測る指標やSLAに基づき、妥当性や改善点を問う。

根拠
可用性、MTBF、MTTRなどの指標 [R5S_SM.pdf | PDF]
SLAの稼働率・サービス時間の管理 [R5S_SM.pdf | PDF]
応答時間や処理時間の目標 [R7S_SM.pdf | PDF]
よくある聞き方
「評価せよ」
「妥当性を説明せよ」
「改善点を述べよ」
本質
👉 数値・SLAと業務影響の関係を説明できるか

⑤「組織・役割・体制設計型」

概要サービス提供のための組織構成や担当分担を問う。

根拠
開発・運用・サービスデスクの役割分担 [R6S_SM.pdf | PDF]
複数部門でのシステム運用 [R5A_SM.pdf | PDF]
変更管理の意思決定者や責任分担 [R3A_SM.pdf | PDF]
よくある聞き方
「部門の役割を述べよ」
「責任分担を明確にせよ」
「体制を設計せよ」
本質
👉 ITサービスを支える“組織の整合性”を理解しているか

まとめ（試験対策視点）

頻出パターンは以下の5つに集約できます：

課題抽出
改善策提示
運用プロセス設計
指標・SLA評価
組織・体制設計
👉 実際の過去問は

「①→②→③ or ④」**の流れで出題されることが多いです。

おまけ：得点戦略（重要）
①は「本文の言い換え」でOK
②は「ITIL用語で答える」
③は「時系列 or フローで書く」
④は「指標＋影響のセット」
⑤は「役割＋目的の対応づけ」
必要なら、「採点者に刺さる回答テンプレ（丸暗記OK）」も作れますがやりますか？

======================================================

5分類について、**実際の過去問PDFの内容に基づく「答案の書き方レベルの具体例」**を示します。
（採点で点が入る表現を意識しています）

① 課題抽出型（問題点を挙げる）

例（サービスデスク・問合せ増加ケース）
想定設問
「現状の問題点を2つ挙げよ」

回答例

問合せが増加しているにもかかわらず受付が分散しており、対応状況を一元管理できていない点
初回対応で解決できない割合が高く、回答時間が長期化している点 [R6A_SM.pdf | PDF]
👉 ポイント

「現象」＋「業務への影響」をセットで書く
本文の記述を“言い換え”る

② 改善施策型（対策を答える）

例（社内サポート改善）
想定設問
「問合せ対応を改善する施策を述べよ」

回答例

問合せ窓口をサービスデスクに集約し、受付から対応までを一元管理する
FAQを整備したポータルを提供し、利用者による自己解決を促進する
問合せ内容に応じて優先度を設定し、対応順序を標準化する [R7A_SM.pdf | PDF]
👉 ポイント

「仕組み導入（SD・ポータル）」＋「運用ルール（優先度）」で書く
ITIL用語を使うと加点されやすい

③ プロセス設計型（手順・流れ）

例（インシデント管理）
想定設問
「インシデント発生時の処理手順を述べよ」

回答例

インシデントを検知し、内容を記録する
影響度と緊急度に基づき優先度を決定する
一次対応で解決できない場合は専門部署へエスカレーションする
解決後、利用者に通知しクローズする [R4S_SM.pdf | PDF]
👉 ポイント

「時系列」で書く（これ超重要）
動詞をそろえる（検知→記録→分類→対応→終了）

④ 指標・SLA評価型

例（可用性評価）
想定設問
「サービス品質をどのように評価するか」

回答例

SLAで定めた可用性指標（稼働率）および平均修復時間（MTTR）を用いて評価する
障害発生時の復旧時間が長い場合、目標未達となり業務停止時間が増加する
そのため、MTTR短縮や冗長化構成の見直しが必要である [R5S_SM.pdf | PDF]
👉 ポイント

「指標名」＋「意味」＋「影響」まで書く
数値がなくても論理が書ければOK

⑤ 組織・体制設計型

例（部門連携）
想定設問
「サービス提供体制を説明せよ」

回答例

サービスデスクが利用者からの問合せ受付と一次対応を担当する
解決できない場合は、開発部門や運用部門へエスカレーションする
各部門の役割を明確化することで、迅速な対応と負荷分散を図る [R6S_SM.pdf | PDF]
👉 ポイント

「誰が何をするか」を明確に
“責任の所在”を書くと得点が伸びる
✅ まとめ：答案テンプレ（そのまま使える）
各設問はこの型に落とすと安定します：

■ 課題
○○であり、その結果△△となっている

■ 改善
○○を実施し、△△を図る

■ プロセス
①○○ → ②△△ → ③□□

■ 指標
○○指標により評価し、△△の場合は□□に影響する

■ 体制
○○部門が△△を担当し、□□部門が補完する

■ さらに伸ばすコツ（合格レベル）
「利用者影響」まで必ず書く（採点で差がつく）
「一元管理」「優先度」「エスカレーション」は鉄板ワード
“問題→対策”の対応関係を崩さない
必要なら、
👉「実際の設問形式（穴埋め・記述）で演習問題」も作れます。

===================================================

優先して覚えるならこの10語

“頻出ワード”は次のあたりです。

1. サービスレベル関連

2. サービスデスク・問い合わせ対応

サービスデスク
もっとも頻出の1つです。役割、対応範囲、利用者支援、一次窓口という観点で重要です。 [R7A_SM.pdf | PDF], [R3S_SM.pdf | PDF]
SPOC
R3S_SM.pdf の設問で解答群に明示されており、科目A向きの用語です。 [R3S_SM.pdf | PDF]
FAQ
利用者の自己解決や問い合わせ削減の文脈で出ています。 [R7A_SM.pdf | PDF]
チャットボット
FAQの活用課題を受けた改善策として登場しており、サービスデスクの周辺語として重要です。 [R3S_SM.pdf | PDF]
問合せ件数
サービスデスク要員体制や負荷見積りに関係する語として出ています。 [R7A_SM.pdf | PDF]

3. インシデント管理・問題対応

4. 変更管理・リリース関連

変更管理
直接テーマになっている資料があり、科目Aでも定義・目的・役割が問われやすい語です。 [R3A_SM.pdf | PDF]
RFC（変更要求）
R3A_SM.pdf で繰り返し使われています。略語問題になりやすい代表です。 [R3A_SM.pdf | PDF]
CAB
変更諮問委員会として明示されており、科目A頻出の典型語です。 [R3A_SM.pdf | PDF]
変更管理マネージャ
役割ベースの知識として重要です。 [R3A_SM.pdf | PDF]
変更スケジュール
解答群に出ており、運用実務上の用語として押さえたいです。 [R3A_SM.pdf | PDF]
展開作業
変更の実施・リリースに関する語として登場します。 [R3A_SM.pdf | PDF]
PIR（変更実施後レビュー）
そのまま定義問題になりやすい語です。 [R3A_SM.pdf | PDF]
ROI
変更承認の判断基準として明示されており、科目Aでも意味理解が重要です。 [R3A_SM.pdf | PDF]
KPI
プロセス評価の指標として登場しています。 [R3A_SM.pdf | PDF]
リリースノート
SaaSアップグレード対応で使う文書として明記されています。 [R3S_SM.pdf | PDF]
リグレッションテスト
SaaSのアップグレード対応文脈で出ています。 [R3S_SM.pdf | PDF]

5. 容量・能力管理 / 可用性関連

6. クラウド / サービス提供形態

単語帳

CMDB（Configuration Management Database）	構成管理データベースのことで、ITサービスの提供に必要な「資産」と「構成」の情報を一元管理するデータベースです
CMIS（Capacity Management Information System）	キャパシティ管理を支援する一連のツール、データおよび情報を含む情報システムのことです
KEDB（Known Error DataBase）	既知のエラー（根本原因と回避策が分かっている問題）が登録されているデータベースです
SACM（Service Asset and Configuration Management）	サービス資産管理および構成管理のことで、サービス提供のために必要な資産を適切にコントロールし、資産に関する正確な情報が必要なときに利用できるように管理すること

初期費用（イニシャルコスト）	サービス開始前または開始時に必要となる費用
運用費用（ランニングコスト）	サービス開始からサービス終了までに必要となる費用

会計・原価計算のロジックなどの話がでたら

押さえるべき核心概念（浅く広くでOK) これらは頻出パターンなので、定義を覚えるより「判定基準」を覚える方が実戦的です。

概念	判定のコツ
直接費 vs 間接費	「特定の事業部/サービス専用に使っているか」で判定。複数で共用→間接費
初期費用 vs 運用費用	サービス開始前に一度だけ発生→初期費用。開始後に継続的に発生→運用費用
TCO(総所有費用)	初期費用＋運用費用の合計。「保守」「アップグレード後の追加開発」などが初期/運用のどちらかを見極める問題が頻出
減価償却	初期費用（資産計上）を耐用年数で分割して毎月費用計上する仕組み。一括費用にならない点が狙われる
KPI設計	「目的（何を管理したいか）」に直結する指標を選ぶ。今回の問題なら「予算超過や不採算の早期発見」→「計画と実績の差異」が答え

例えば自動車部品を製造している会社の場合

直接費	間接費
鋼材	工場長の給料
ネジ	品質保証部門の給料
塗料	総務部門の給料
製品を加工する作業者の賃金	工場照明の電気代、設備保守費

用語集

用語	英語	意味・ポイント
可用性(かようせい)	Availability	システムが稼働している時間の割合。稼働率(%)やMTBF/(MTBF+MTTR)で算出。SLAの代表指標
信頼性(しんらいせい)	Reliability	故障しにくさ。MTBF(平均故障間隔)が長いほど高い
保守性(ほしゅせい)	Maintainability	故障からの復旧のしやすさ。MTTR(平均修理時間)が短いほど高い
完全性(かんぜんせい)	Integrity	データが正確・改ざんされていないこと。情報セキュリティの3要素の一つ
機密性(きみつせい)	Confidentiality	許可されていない者にアクセスさせないこと。情報セキュリティの3要素の一つ
可用性(セキュリティ文脈)	Availability	必要な時に情報にアクセスできること。情報セキュリティの3要素の一つ
拡張性(かくちょうせい)	Scalability/Extensibility	システム規模やユーザー数の増加に対応できる度合い
保全性(ほぜんせい)	Serviceability寄り	予防保守なども含めた保守のしやすさ全般を指す場合がある
効率性(こうりつせい)	Efficiency	資源(時間・コスト)をどれだけ有効に使えているか
移植性(いしょくせい)	Portability	別環境への移行のしやすさ
使用性(しようせい)	Usability	使いやすさ、ユーザビリティ
機能性(きのうせい)	Functionality	必要な機能を満たしているか
真正性(しんせいせい)	Authenticity	本人・正当な発行元であることの証明。JIS Q 27000の追加要素
責任追跡性(せきにんついせきせい)	Accountability	操作や行為が誰によるものか追跡できること
否認防止性(ひにんぼうしせい)	Non-repudiation	後から「やっていない」と否認できないようにする性質

サイト内リンク

午後対策

必須	問1	情報セキュリティ	APB-SEC
選択	問2	経営戦略
〃	問3	プログラミング
〃	問4	システムアーキテクチャ	APB-SA
〃	問5	ネットワーク
〃	問6	データベース	APB-DB
〃	問7	組込みシステム開発
〃	問8	情報システム開発	APB-IS
〃	問9	プロジェクトマネジメント
〃	問10	サービスマネジメント	APB-SM
〃	問11	システム監査	APB-AU