継続的改善とは？ PDCAとISO認証・審査・取得の仕組みを解説

1. なぜITサービスには継続的改善が必要なのか

たとえば社内の業務システムが、毎週月曜日の朝に遅くなるとします。担当者がその都度サーバーを再起動するだけなら、一時的には復旧しても問題は繰り返されます。継続的改善では、利用者への影響、遅延の発生頻度、原因、解消までの時間を計測し、より根本的な対策を選び、導入後の数値を比較します。

一度で完全な正解を見つける必要はありません。小さな改善が確かに役立ったのか、別の問題を生んでいないかを確認してから標準化します。運用に入った後もサービス要求、ビジネス環境、技術、脅威が変化するため、改善を一度で打ち切ることはできません。

2. サービスマネジメントシステム（SMS）の位置付け

SMS（Service Management System）は、サービスマネジメントの方針と目標を定め、計画・設計・移行・提供・改善を管理する枠組みです。ISO/IEC 20000-1は、SMSに関する要求事項を示す国際規格で、日本ではJIS Q 20000-1として対応する規格が整備されています。継続的改善はこの仕組み全体に関係する活動であり、単独の作業手順や特定のツール名ではありません。

現場では、改善する対象をサービスそのもの、運用プロセス、組織体制、インフラ構成、利用者とのコミュニケーションなどから選びます。改善を行った記録があるだけで十分とはいえず、どの指標がどう変わったか、目標に近づいたかを評価する必要があります。

3. PDCAサイクルで改善を回す

Planでは課題を「障害件数が多い」だけで終わらせず、対象サービス、計測期間、発生条件、利用者への影響を明らかにします。Doでは原因に対応した施策を選び、小規模検証やロールバック計画を用意して実行します。Checkでは数字と現場の意見の両方を確認し、Actでは有効な変更を標準化するか、追加の改善を計画します。

PDCAは順番を暗記すること以上に、効果を測らないまま「実施済み」で終わらせないために重要です。「改善のための会議を毎月開く」こと自体は活動の一部ですが、会議の回数が増えただけではサービスの改善を意味しません。

4. ベースラインとKPIを決める

改善の前後で何が良くなったかを説明するには、基準値（ベースライン）が必要です。例えば「直近3か月の月間インシデント平均20件、平均復旧時間90分」を記録し、「次の四半期末に平均復旧時間を60分以下にする」と目標を置きます。計測方法や対象範囲が変わった場合は、その違いも残さないと数値を誤読します。

5. 根本原因を分析して施策を選ぶ

障害対応が遅い理由は、監視不足、担当者への連絡遅延、手順書不足、権限承認待ちなど様々です。原因が違えば有効な改善も異なります。原因分析にはログや時系列、5 Whys、特性要因図、変更履歴などが利用できます。ただし、1つの問いだけですべての因果関係が確定するわけではありません。

対策を選ぶ際は、実現可能性、期待する利用者価値、費用、変更リスク、依存関係を比較します。短期間でできる改善を積み重ねつつ、構造的な問題については中長期の計画を立てます。優先度を決めずにすべての改善案を実行すると、運用チームの負荷や変更リスクが増大します。

6. 改善バックログを管理する

改善案を思いついた順に実施するのではなく、改善バックログとして課題、仮説、目標、責任者、期限、リスクを管理します。特定のツールは必要ありません。小さなチームなら共有のチケットや表でも始められます。大切なのは「だれが何をいつまでに改善し、何をもって効果ありとするか」を追えることです。

7. 変更管理と改善はどうつながるのか

運用設定の改善であっても、本番環境の変更が障害を引き起こす可能性があります。監視ルール変更、ロードバランサーの設定調整、サーバー増強、アプリケーションのリリースなどは、適切な変更評価、テスト、実施計画、承認、ロールバック手順を用意して進めます。低リスクの定型変更と大規模な変更で同じ手続を要求するとは限りません。

改善活動と変更管理は対立しません。変更管理は改善施策を安全に適用するための仕組みであり、継続的改善はどのような変更が価値を生むかを検討し、実施後も効果を追跡します。

8. インシデント管理・問題管理との関係

インシデント管理は現在発生しているサービス中断・品質低下からの早期復旧を重視します。問題管理はインシデントの根本原因や将来の発生可能性を分析し、既知の問題を扱います。継続的改善はそれらの情報を使い、将来のサービス品質を高めるための改善を継続的に進めます。

9. サービス継続と可用性を混同しない

可用性は利用できる状態に注目する指標・性質であり、サービス継続は災害や重大障害が起きた場合にも合意したサービス水準を維持・回復する能力に関係します。継続的改善は、それらを含む広いサービスのパフォーマンスを高めていく活動です。同じ「継続」という文字が含まれていても、意味の中心は異なります。

10. 情報セキュリティ運用に活用する

SOCのアラート処理、脆弱性対応、アクセス権限レビューなども改善対象です。例えば誤検知が多ければ検知ルールを調整し、重大イベントの見逃しが増えないかを確認します。脆弱性対応が滞るなら、優先度決定から担当部門への割当て、期限までの修正・再検証という流れを見直します。

改善の結果としてダッシュボードの数字が良くなっても、リスクが適切に低減したとは限りません。検知・予防・復旧という複数の観点を持ち、サービス責任者、セキュリティ担当者、利用部門の期待をそろえて評価します。

11. ISO認証とは？ 「規格」と「第三者認証」の違い

ISOは国際的な標準を制定する組織です。ISO規格を読むこと、規格に沿って社内制度を整備すること、独立した認証機関の審査を受けて認証を取得することは別々です。たとえば、ISO/IEC 20000-1の要求事項に従ってITサービスの運用体制を構築しても、認証機関の審査を受けなければ「第三者認証取得済み」とは表示できません。

企業サイトの「ISO/IEC 27001認証」「ISO/IEC 20000-1認証」は、一般に組織のマネジメントシステムに対する第三者認証を指します。会社そのものの全業務が無条件で保証されるわけではなく、証書に記載された適用範囲・拠点・対象業務・有効期限・認証機関を確認する必要があります。

12. 試験で区別したい主要ISO・JIS規格

規格番号は全部を丸暗記するよりも、何を守り、何を管理し、何を認証できるかで整理すると迷いにくくなります。下表の認証の可否は「その規格そのものの第三者認証が一般に想定されるか」を示します。

たとえば「企業の情報セキュリティ管理体制」なら27001、「ITサービス提供の品質」なら20000-1、「災害後も事業を続ける仕組み」なら22301です。ISO/IEC 15408は企業の運営体制ではなく、IT製品のセキュリティ機能の評価に使われるため混同しないようにします。

13. 会社が認証を取得するまでの準備と審査

認証はお金を払うだけで取得できる登録ではありません。組織が管理の仕組みを構築・運用したうえで、外部の認証機関が要求事項への適合を評価します。一般的なマネジメントシステム認証の進め方は次のとおりです。

14. 費用・準備期間・維持更新の考え方

審査費用は規格番号だけで一律に決まらず、従業員数、サイト数、対象サービス、業務の複雑性、認証範囲、審査工数などで変わります。費用の見積もりでは、認証機関への支払いと、社内人件費・必要なツール・研修・任意のコンサルティングを分けて考えましょう。認証機関の選定時には複数社の見積もりと審査範囲を比較するのが実務的です。

なおプライバシーマークは有効期間2年、2年ごとに更新申請という別制度です。国内のJIS Q 15001第三者認証とPマークも同じ制度ではありません。個人情報保護の制度を比較する場合は、この更新周期も見分けるポイントです。

15. 認証マークを見たときの確認項目と理解度チェック

会社概要やサービス紹介でISOの認証マークを見たら、単に「持っているから安全」と考えるのではなく、以下を確認します。規格番号と適用版、認証対象の組織・サービス・拠点、認証機関、登録番号、有効期限です。認証は一定の仕組みの適合を示すもので、無事故や脆弱性ゼロを保証するものではありません。

16. よくある失敗

17. FAQ

18. 実践ラボ：改善の計画と効果を評価する

架空のWebサービスを題材に、監視ルール、復旧手順、容量対策、教育を組み合わせます。最初に基準値を確認し、目標のMTTRを設定し、施策を実行して予測上の観測値を確認します。最後に振り返りを記録して、次のサイクルへつなげましょう。

19. まとめ

継続的改善は、ISO認証の名称ではなく、サービスの品質や成果を高めるため、計画・実行・評価・見直しを反復する考え方です。ポイントは、現状を測る → 目標を定める → 施策を実行する → 効果と副作用を確認する → 次の改善へつなぐという循環にあります。単なる「作業の繰り返し」でも「サービスを止めない能力」でもありません。またISO/IEC 20000-1のような要求事項規格は、継続的改善を含むマネジメントシステム全体の第三者認証を取得でき、取得には運用記録・内部監査・外部審査が必要です。