SM 論述で合格に届かない6つのパターン|論文140本の添削から分かった減点と書き直し例
「運用の話は書けている」のに受からない答案には共通点がある
ITサービスマネージャ試験の科目B-2は、日々の運用経験があれば字数は埋まります。それでもランクAに届かない答案はたくさんあります。シカクテックでは、これまでにSMの論文を約140本AI添削してきました(2026年11月時点)。評価がBやCにとどまる答案には、同じ種類の指摘が何度も出てきます。
この記事では、そうした答案に共通する6つのパターンを取り上げます。どれも内容の良し悪しというより書き方の抜けなので、知っていれば本番の見直しの時間で直せます。
例文はすべてこの記事のために作った架空の事例で、数字も説明用の例です。
パターン1:立場がプロジェクトマネージャやSEになっている
SMの論文で問われるのは、サービスを運営する責任者としての判断です。ところが、システムの更改や移行を題材にすると、いつの間にかプロジェクトの進め方や作業の手順の話になってしまう答案があります。
❌ 私は移行プロジェクトのリーダーとして、作業計画を立て、要員を
割り当て、予定どおりに移行を完了させた。
⭕ 私は配送管理サービスのサービスマネージャとして、移行の前後で
SLAの受付時間を守ることを最優先にした。移行作業の計画は開発
チームに任せ、私は利用部門と停止できる時間帯を合意し、移行後
1週間はインシデントの受付体制を2倍にすることを決めた。
見直し方:「私は〜として」の役割名と、段落の中心にある判断を確かめます。作業の段取りではなく、サービスの品質・SLA・利用者への影響についての判断が書かれているかを見ます。
パターン2:原因分析が結論だけになっている
障害や問題管理を題材にすると、「根本原因は〜であった」と結論だけを書く答案がよくあります。採点者が読みたいのは、どうやってその原因にたどり着いたかです。
❌ 分析の結果、根本原因は手順書の不備であると判明した。
⭕ 直近半年の作業ミス12件を作業記録と聞き取りで洗い出すと、うち
9件が夜間の手動切替で起きていた。手順書を確かめると、切替の
確認項目が担当者の記憶に頼っており、手順書に載っていなかった。
そこで、根本原因は確認項目の手順書への未記載と判断した。
データ(作業記録、件数)、確かめた方法(聞き取り、手順書の確認)、そこから導いた結論の順に書くと、原因分析が「過程」として読めます。
パターン3:効果が「期待」で終わり、目標と比べていない
設問ウで対策の評価を問われたとき、「〜の効果が期待できる」「改善された」で終わる答案はランクAに届きにくいです。
❌ 対策の実施により、作業ミスの削減が期待できる。今後も改善を
続けていく。
⭕ 対策から3か月の作業ミスは2件で、目標の月1件以下を達成した。
一方、問合せの初回解決率は目標80%に対し72%にとどまった。原因は
新人の担当者が手順書を探しきれないことで、手順書の検索画面を
改めることを次の課題とした。
目標・実績・差の理由の3つを書き、未達の部分も隠さずに書きます。未達のときの対応が「追加の方策を検討する」だけになっていないかも確かめてください。
パターン4:指標の測り方が書かれていない
SMの論文では、稼働率、初回解決率、平均復旧時間などの指標がよく出てきます。ところが、どう測ったかが書かれていない答案が目立ちます。
- 稼働率99.9%の計算で、計画停止や一部の機能だけが止まった時間をどう扱うのか
- 復旧時間は、障害の発生時刻と検知時刻のどちらから数えるのか
- 「手順書の整備率100%」のような実施したかどうかの指標だけで、サービスが良くなったかを測っていないか
⭕ 稼働率は、計画停止を除いた月間のサービス時間に対する、配送の
受付ができた時間の割合とした。一部の地域だけ受付できなかった
時間も、停止として数えた。
指標を出したら、その数え方を1文添える習慣をつけます。
パターン5:顧客やサプライヤとの合意がない
改善計画やSLAの見直しを書いた論文で、顧客と何を合意したか、サプライヤ(クラウド事業者や委託先)とどう責任を分けたかが抜けている答案があります。SMは自組織だけでサービスを提供しているわけではないので、ここが抜けると現実味が薄れます。
⭕ 改善計画は、月例のサービスレビューで利用部門の課長に説明し、
受付時間の延長は見送る代わりに、障害時の第一報を30分以内に
出すことで合意した。クラウド事業者とは、基盤の障害は事業者が
復旧し、当社は利用者への連絡と業務の代替手段を担うことを確認
した。
パターン6:設問アと設問イで対象がずれる
SMの論文で特に多いのが、設問アで説明したサービスや障害と、設問イで扱うものが違っているケースです。設問アで「配送管理サービス」を説明したのに、設問イでは別の社内システムの障害を書いている、といったずれです。
内容が良くても、設問のつながりが切れていると「問題への適合性」で大きく減点されます。
見直し方:設問アで書いたサービス名・障害・数字を拾い、設問イ・ウで同じ名前・同じ値で出てくるかを確かめます。
提出前の5分で見直すチェックリスト
| 確認すること | 探す言葉 |
|---|---|
| 役割がサービスの責任者で、判断がサービスの品質についてのものになっている | 「私は〜として」 |
| 原因の結論の前に、データと確かめた方法がある | 「根本原因」「判明した」 |
| 効果に目標・実績・差の理由がある | 「期待できる」「改善された」 |
| 指標に数え方が書いてある | 「稼働率」「解決率」「復旧時間」 |
| 顧客・サプライヤと合意した内容がある | 「合意」「協議」 |
| 設問アのサービス名・数字が設問イ・ウと一致している | 設問アのサービス名 |
CBTの解答欄には文字数が表示されますが、上限を超えた分は消えてしまいます。見直しで書き足すときは、字数の残りにも気をつけてください。
論文の構成やネタの棚卸しについては、SM 科目B-2(論述式)の論文構成とネタの作り方で詳しく解説しています。
この記事を書いた人
四角くん|シカクテックの中の人
情報処理技術者試験を中心に、IT・ビジネス系資格の学習法や試験対策についてわかりやすく発信しています。実際の受験経験をもとに、効率的な勉強法をお届けします。
受験の記録を X で発信中 @shikakutech取得資格