【ウェーイ系版】サービスマネジメントシステム（SMS）とは？社長が『任せた』と言ったら逃げろ！

サービスマネジメントシステム（SMS）って結局何なの？

国際規格ISO/IEC 20000-1:2018がその要求事項を定めている、ITサービスマネジメント（ITSM）の世界標準だと思ってくれ。

「ITILやってるだけで十分でしょ？」と思う人もいるけど、ITILは「どうやるか」のベストプラクティス集で、ISO/IEC 20000は「これを満たさないと認証取れないよ」という要求事項。 つまり、ITILは参考書、ISO 20000は試験の採点基準みたいな関係。 両方知ってると強いけど、今回はISO 20000基準で話を進めるよ。

SMSを構築する前に絶対やるべき「計画」のフェーズ

1. トップマネジメントのリーダーシップとコミットメント

「俺は忙しいから任せた！」って社長が言う組織は99%失敗する（笑）。 ISO 20000では、トップマネジメントが以下のことを自分で責任持つよう要求されている：

• サービスマネジメントポリシーの策定と伝達
• SMSの有効性を確保するための資源提供
• 組織全体へのコミュニケーション

要は「俺が本気でやるから、お前らもやれよ」という姿勢を見せないと誰もついてこない。

2. サービスマネジメントポリシー

短くてわかりやすい文言で、以下の内容を含むこと：

• 顧客要求事項と適用法令の順守
• 継続的改善のコミットメント
• サービス要求事項を満たすコミットメント

例：「当社は顧客の要求を満たす高品質なITサービスを提供し、法令を順守し、継続的にサービスを改善します。」 これをポスターにして貼るだけじゃ意味ない。実際に行動で示さないとね。

3. 役割、責任、権限の明確化

「誰が何やるか」が曖昧だと、トラブル時に全員「知らん顔」になる。 サービスマネジメント全体の責任者（サービスマネージャー）を置き、各プロセスオーナーも明確に。 RACI表（Responsible, Accountable, Consulted, Informed）を作ると楽だよ。

4. リスクと機会の特定

「うちはリスク管理なんてやってないよ」という組織はマジで危ない。 ISO 20000では、サービス提供に影響を与えるリスクと機会を特定し、対応を計画することを要求している。 例：

• リスク：主要ベンダーの倒産 → 代替ベンダーの選定
• 機会：クラウド移行によるコスト削減 → 移行プロジェクト立ち上げ

5. サービスマネジメントの目標設定

SMART（Specific, Measurable, Achievable, Relevant, Time-bound）で目標を立てる。 例：

• 「2026年末までにインシデントの初回解決率を85%以上にする」
• 「顧客満足度スコアを平均4.5以上に維持する」

目標だけ立てて放置する組織が多いけど、定期的にレビューしないと意味ないからね。

SMSの「運用（Clause 8）」──ここが本番だ

1. サービスポートフォリオ管理

提供するサービスを全部リストアップして、以下のステージで管理：

• サービスパイプライン（検討中）
• サービスカタログ（現在提供中）
• 退役サービス（終了したもの）

「うちのサービスカタログ、Excelで10年前のまま…」って組織はマジでヤバい。

2. サービス設計と移行（Design & Transition）

新サービスや大幅変更を本番環境に投入するプロセス。 ここで失敗すると大惨事になるから慎重に。

• サービスデザイン パッケージ（SDP）の作成
• 変更評価と承認
• リリース管理

「テスト環境で動いたから本番も大丈夫でしょ」精神は禁止（笑）。

3. サービス提供（Service Delivery）

日常運用の中核。

• サービスレベル管理（SLM） SLA（サービスレベル合意書）を顧客と結び、定期的にレビュー。 OLA（運用レベル合意書）やUC（契約下請け契約）も必要。
• サービス可用性管理 可用性目標を決め、障害対策、バックアップ、DR（災害復旧）計画を立てる。
• キャパシティ管理 「サーバー足りなくなるかも？」を事前に予測。
• 情報セキュリティ管理 ISO 27001と連携させると楽。
• サービス継続性管理 災害時でもサービスを維持するための計画。

4. 問題管理（Problem Management）

インシデントの根本原因を潰すプロセス。 「毎月同じ障害起きてるのに、対応が対症療法だけ」って組織はここが弱い。

5. インシデント管理とサービスリクエスト管理

お客様から「動かない！」って連絡が来たら即対応。 優先度付けとエスカレーションルールを明確に。

6. 構成管理（CMDB）

サービスを構成する資産（サーバー、ソフト、ドキュメント、契約書など）を一元管理。 CMDBが最新じゃないと、変更影響度評価ができない。

7. 変更管理とリリース管理

「勝手にサーバー再起動しました」みたいな野蛮行為を防ぐためのプロセス。 変更諮問委員会（CAB）を設置して、重大変更は必ずレビュー。

8. 知識管理

「〇〇さんしか知らない」状態をなくす。 ナレッジ記事を蓄積して、誰でも参照できるように。

9. サプライヤー管理

外部ベンダーとの契約管理。 ベンダーのパフォーマンスも定期的に評価。

継続的改善（Clause 10）──これを怠ると全部水の泡

特に継続的改善レジスター（Continual Improvement Register）を作って、改善アイデアを全部トラッキングすると良い。 「まあそのうち直せばいいか」精神だと、認証維持審査で確実に突っ込まれる。

まとめ：SMSは「仕組み」じゃなくて「文化」

結局、サービスマネジメントシステムって、ツールやドキュメントを揃えるだけじゃ動かない。 組織全体が「顧客に価値を提供し続ける」ことを当たり前に思う文化が一番大事。 トップが本気でコミットして、現場がプロセスをちゃんと回して、データを元に改善を繰り返す。 これができれば、顧客満足度も上がるし、社員の仕事も楽になるし、認証も取れるしでいいこと尽くめ。