障害発生時の連絡フローとSLAの基礎

ある日の午後、社内で使っている基幹システムが突然反応しなくなった。画面はぐるぐると読み込み中の表示のまま固まり、営業担当からは「見積もりが出せない」「顧客データが開けない」という声が次々に上がってくる。あなたは真っ先に何をするだろうか。開発会社に電話をかける、メールを送る、それとも社内のチャットで「誰か知らないか」と聞いて回るだろうか。そして、電話をかけたとして、開発会社からはどれくらいの時間で折り返しがあるのが「普通」なのか。1時間待っても連絡がなければ催促していいのか、それとも半日は待つのが契約上のルールなのか——多くのひとり情シス・総務兼任の担当者は、この問いに即答できない。

障害発生時の対応は、平時にはまったく意識されないのに、いざ起きた瞬間から会社の業務そのものを左右する。にもかかわらず、「誰に、どういう順番で、どれくらいの時間で連絡すべきか」という連絡フローが文書化されている中小企業は少なく、多くの現場は「そのとき考える」という運任せの状態で本番障害を迎えている。この記事では、障害発生時の連絡フローをどう設計すべきか、そして開発会社との契約に登場する「サービス品質保証」という言葉が実務上何を意味するのかを、基礎から順番に整理する。すでに保守契約を結んでいる方は、今の契約内容が実際の障害対応にどこまで効いてくるのかを確認する材料としても使ってほしい。

この記事で分かること

この記事では、システム障害が発生した瞬間に何をすべきかという初動の考え方から、社内での連絡フロー設計、開発会社への連絡ルート、対応時間の目安をどう契約に落とし込むか、そしてエスカレーション(対応が進まないときに上位者へ引き継ぐこと)の判断基準までを、実務の流れに沿って解説する。契約書にサービス品質保証の項目が書かれていない、あるいは書かれていても内容を読み解けていないという担当者にとって、何を確認し、何を開発会社に質問すればよいかが具体的にわかる内容を目指す。逆に言えば、この記事は個別のシステムの技術的な復旧手順(バックアップからの復元方法など)を扱うものではない。あくまで「誰が、どの順番で、どれくらいの時間で動くか」という体制とルールの話に絞っている。

なぜ障害対応のルールは「起きる前」に決まっていないのか

結論から言うと、多くの中小企業では障害対応のルールが「起きてから」その場しのぎで作られる。理由は単純で、障害は滅多に起きないため、平時にルールを整備する優先順位が上がりにくいからだ。システム導入プロジェクトの終盤は、要件通りに動くかどうかの検収に関心が集中し、「動いたあと、壊れたときにどうするか」という論点は後回しにされやすい。これは前回取り上げた運用フェーズの役割分担の話とも重なる構造であり、障害対応フローの欠如はその中でもとりわけ実害が大きい典型例といえる。

さらに厄介なのは、障害が「起きて初めて」ルールの不備が発覚するという点だ。平時にどれだけ「何かあったら連絡してください」と言われていても、実際に障害が起きた瞬間、担当者は次のような疑問に直面する。

• 開発会社に連絡する前に、社内でどこまで確認すべきか
• 誰が開発会社への連絡窓口になるのか(担当者が休みのときはどうするか)
• 連絡してから、どれくらいで返事が来るのが普通なのか
• 「これは異常」と判断する基準は何か(単なる操作ミスと障害の見分け方)
• 対応が進まないとき、いつ・誰に・どう催促すべきか

これらの問いに対する答えが事前に用意されていないと、障害発生時に「まず何をすべきか考える」という時間そのものが、業務停止の時間を延ばすことになる。障害対応において最も高くつくコストは、多くの場合、技術的な復旧作業そのものよりも、この「判断に迷っている時間」であることを覚えておきたい。

障害対応の初動が遅れる最大の原因は、技術力の不足ではなく、誰が何をすべきかという役割分担が事前に決まっていないことにある。連絡フローという「紙一枚のルール」があるかどうかで、初動のスピードは大きく変わる。

障害発生時、社内でまず何を確認すべきか

開発会社に連絡する前に、社内でいくつかの一次確認を行うことで、無駄な連絡往復を減らせる。ここでいう一次確認は、技術的な原因究明ではなく、「本当に開発会社への連絡が必要な状態か」を切り分けるための最低限のチェックだ。

一次確認で押さえておきたい項目は次の通りだ。

1. 影響範囲の確認: 自分のパソコンだけの問題か、他の社員も同じ症状か
2. 時間的な特定: いつから起きているか(直前に何か操作をしたか、社内でシステム更新をしていないか)
3. ネットワークの確認: そもそも社内のインターネット接続自体に問題がないか
4. 再現性の確認: ブラウザを再起動する、別の端末で試すなど、簡単な操作で直るものではないか
5. 既知の障害でないかの確認: 開発会社やサービス提供元から障害情報の告知が出ていないか

これらを数分程度で確認したうえで、それでも解消しない場合に開発会社への連絡に進む、という順番を社内で共有しておくことが望ましい。ここで重要なのは、この一次確認に時間をかけすぎないことだ。5分や10分で切り分けがつかない場合は、深追いせずにすぐ開発会社へ連絡する判断に切り替える。「自分でなんとかしよう」とする姿勢は評価されるべき面もあるが、ひとり情シスが技術的な原因究明に時間を使いすぎると、業務停止時間がそのまま伸びてしまう。一次確認はあくまで「明らかに社内側の問題」を除外するためのフィルターであって、原因究明そのものではないと割り切っておきたい。

開発会社への連絡フローをどう設計するか

一次確認を終えて開発会社への連絡が必要と判断したら、次に問題になるのが「誰が、どの窓口に、どうやって連絡するか」だ。この連絡フローが事前に文書化されていない会社は驚くほど多い。連絡フローを設計する際に決めておくべき要素を整理する。

連絡窓口の一本化

社内から開発会社への連絡は、できる限り窓口を一本化しておくことが望ましい。複数の社員がそれぞれ個別に開発会社の異なる担当者へ連絡してしまうと、開発会社側でも状況把握が混乱し、対応が重複したり抜け漏れが生じたりする。窓口となる担当者(多くの場合、ひとり情シスや総務担当者)を決め、社内には「システムの不具合はまずこの人に報告する」というルールを周知しておく。

連絡手段と優先順位

電話・メール・チャットツールなど、開発会社との連絡手段は複数存在することが多いが、緊急度に応じてどれを使うべきかを決めておく。一般的には、業務が完全に止まるような重大な障害は電話、軽微な不具合や質問はメールやチャットという使い分けが現実的だ。契約書や保守契約の中に、緊急連絡先の電話番号やメールアドレスが明記されているかを確認しておこう。明記されていない場合は、開発会社に確認して社内の連絡フロー図に反映しておくとよい。

連絡時に伝えるべき情報

開発会社への連絡が要領を得ないと、その分だけ対応開始が遅れる。連絡時に最低限伝えるべき情報をテンプレート化しておくと、慌てている状況でも抜け漏れなく伝えられる。

このテンプレートは、社内の誰が連絡しても同じ質の情報が伝わるよう、あらかじめ紙一枚やチャットの定型文として用意しておくと実用性が高い。

サービス品質保証とは何か、契約書のどこを見ればよいか

ここまで社内側の連絡フローを整理してきたが、もう一方で重要になるのが、開発会社側が「連絡を受けてからどれくらいの時間で対応してくれるのか」という約束事だ。これを定めたものが、SLAと呼ばれる合意である。障害発生時の対応開始までの目安時間や、システムの稼働率の目標値など、提供されるサービスの品質水準について発注者と開発会社の間で交わす取り決めを指す。

サービス品質保証が保守契約に明記されていない場合、障害時に「どれくらいで対応してもらえるか」の目安がなく、いざというときの交渉が難航しやすい。逆に言えば、この項目が契約書に具体的な数値とともに書かれているかどうかは、保守契約の質を見極める重要なチェックポイントになる。

サービス品質保証の項目を確認する際は、次のような観点で契約書を読み進めるとよい。

• 対応時間の目安が明記されているか: 「連絡受付から○時間以内に一次回答」のような具体的な数値があるか、それとも「速やかに対応します」といった曖昧な表現にとどまっているか
• 対応時間の起算点はいつか: 電話をかけた時点か、メールを送った時点か、開発会社が受信を確認した時点か
• 営業時間外・休日の扱い: 平日日中のみの対応なのか、休日や夜間の緊急対応にも別料金や別条件で対応してもらえるのか
• 重大度によって対応時間が変わるか: 「全社停止」と「一部機能の不具合」で、同じ対応時間の約束になっているか、段階分けされているか
• 未達成時の扱い: 約束した対応時間を超過した場合、何らかの是正措置や説明義務があるか

サービス品質保証は、開発会社が「頑張って早く対応します」という気持ちの表明ではなく、対応開始までの時間や稼働率について、数値として合意された約束事を指す。数値が書かれていない「速やかに」「可能な限り」といった表現は、実務上は目安にならないと考えておいた方がよい。

なお、サービス品質保証の内容は、保守契約の月額費用や契約形態(準委任契約か請負契約か)によっても変わってくる。手厚い対応時間を求めるほど月額費用が上がるのは自然なことであり、「安い保守費用のまま、大企業並みの即時対応を期待する」という組み合わせは現実的ではない。自社の業務がシステム障害でどれくらいの損失を被るかを見積もったうえで、必要な対応時間の水準と費用のバランスを判断することが求められる。

対応時間の目安をどう考えるか

サービス品質保証を検討する際、「何時間以内の対応が妥当か」という数値の相場観を求められることが多いが、これは業種・業務内容・システムの重要度によって大きく異なり、一律の正解は存在しない。この記事では特定の時間数を推奨することは避けるが、判断の材料となる考え方を示しておく。

対応時間を検討する際の軸は、大きく分けて次の3つだ。

• 業務停止による損失の大きさ: そのシステムが止まると、1時間あたりどれくらいの業務・売上に影響するか
• 代替手段の有無: システムが使えない間、手作業や別の方法で業務を継続できるか
• 復旧までの現実的な技術的所要時間: どれだけ迅速に連絡が取れても、原因調査や復旧作業自体に一定の時間がかかることは避けられない

これらを踏まえたうえで、開発会社と「どのレベルの障害に、どれくらいの対応時間を求めるか」をすり合わせておくことが、サービス品質保証を実効性のあるものにする第一歩になる。契約書に数値を書き込むこと自体が目的ではなく、その数値が自社の業務実態に見合っているかを確認することが本質的に重要だ。

エスカレーションはいつ、どう判断するか

連絡フローとサービス品質保証を整えても、実際の障害対応では「窓口担当者に連絡したが、なかなか進展しない」という状況が起こり得る。このとき、現場の窓口担当者では対応しきれない問題を、より上位の担当者や責任者に引き継いで対応してもらうことを指す言葉が、エスカレーションである。

エスカレーションのルート、つまり誰に、どの基準で、どれくらいの時間で引き継ぐのかが契約時に決まっていないと、緊急時に対応が遅れる原因になる。多くの担当者が悩むのは、「催促」と「エスカレーション」の境界線をどこに引くべきかという点だ。単純な催促の連絡を繰り返すだけでは、担当者個人のキャパシティの問題は解決しない。ルートを一段上げて、開発会社側の別の担当者や責任者に状況を共有する必要がある場面がある。

エスカレーションを判断する際の目安として、次のような基準を社内であらかじめ決めておくとよい。

• サービス品質保証で定めた対応時間を明らかに超過している: 約束した時間の目安を過ぎても最初の連絡すら来ない場合
• 窓口担当者から的を射た回答が得られない状態が続いている: 状況を繰り返し説明しているのに、話が前に進まない
• 業務への影響度が当初の想定より大きいと判明した: 一部の不具合だと思っていたら、実は全社的な影響だったことが分かった場合
• 窓口担当者と連絡が取れない状態が一定時間続いている: 電話にもメールにも反応がない

これらに該当したら、契約書や過去のやり取りで確認できる開発会社側の上位窓口(営業担当、プロジェクトマネージャー、場合によっては経営層)に連絡を切り替える。このとき重要なのは、感情的な不満をぶつけることではなく、「いつ、何を依頼し、どういう約束で、現在どういう状況か」という事実関係を淡々と伝えることだ。感情的なやり取りは状況の解決を遅らせるだけでなく、その後の関係にも悪影響を残しやすい。

エスカレーション先の連絡先についても、平時のうちに確認して社内の連絡フロー図に記載しておくことをおすすめする。窓口担当者しか連絡先を知らない状態は、その担当者が捕まらないときに詰んでしまうリスクがある。

障害の重大度をどう切り分けるか: 全社停止と部分不具合を同じ扱いにしない

サービス品質保証や連絡フローを設計するうえで、見落とされがちなのが「障害の重大度」という視点だ。ひとくちに「障害」と言っても、その深刻さは幅広い。全社員が業務を続けられなくなる完全停止と、特定の一部機能だけがおかしいという軽微な不具合とでは、求められる対応スピードも、開発会社に連絡する緊急度もまったく異なる。にもかかわらず、多くの中小企業では、この重大度による切り分けがなされないまま、すべての不具合が同じ扱いで連絡されてしまっている。

重大度を切り分ける際の目安として、次のような3段階程度の分類を社内で用意しておくと実務上扱いやすい。

この分類を開発会社ともあらかじめ共有しておくと、「緊急」と伝えた連絡には即座に反応してもらえる一方、「軽微」な問い合わせで開発会社の緊急対応リソースを消費してしまうという事態を防げる。逆に言えば、担当者が焦るあまりすべての不具合を「緊急」として連絡し続けると、開発会社側も本当に緊急な連絡との区別がつかなくなり、結果として全体の対応スピードが落ちるという逆効果も起こり得る。重大度の切り分けは、開発会社を急かすためだけでなく、本当に緊急な場面でスムーズに動いてもらうための土台でもある。

サービス品質保証を交渉する際に注意したいこと

すでに保守契約を結んでいて、サービス品質保証の項目が曖昧だと感じた場合、それを是正するための交渉を開発会社に持ちかけることになる。この交渉にあたって、いくつか心得ておきたい点がある。

まず、サービス品質保証の条件を厳しくすればするほど、それに見合った費用が発生するのが通常だという前提を理解しておく必要がある。24時間365日の即時対応を求める契約と、平日日中のみの対応でよい契約とでは、開発会社側の体制構築コストがまったく異なる。自社の業務にとって本当に必要な水準を見極めずに「とにかく早く対応してほしい」とだけ要求すると、過剰な費用負担につながりかねない。逆に、費用を抑えることばかりを優先して対応水準を下げすぎると、実際に障害が起きたときに業務への影響が大きくなるおそれがある。

次に、サービス品質保証の交渉は、一度きりの契約締結時だけでなく、事業の状況が変化したタイミングで見直す価値がある。たとえば、システムへの依存度が事業拡大とともに高まった場合や、逆に一部業務を縮小してシステムの重要度が下がった場合には、それに応じて対応時間の水準を見直すのが合理的だ。契約を結んだときの水準がそのまま何年も据え置かれているケースは珍しくなく、定期的な見直しの機会を持つことをおすすめする。

最後に、サービス品質保証の内容を確認する際は、口頭での説明だけで納得せず、必ず契約書や覚書といった書面に反映してもらうことが重要だ。営業担当者から口頭で「基本的にはすぐ対応します」と説明されても、それが書面化されていなければ、担当者が変わった際や実際にトラブルが起きた際に、その約束が引き継がれる保証はない。

よくある失敗パターンから学ぶ

最後に、障害対応の連絡フローやサービス品質保証をめぐって実際によく起きる失敗パターンをいくつか挙げておく。自社に当てはまるものがないか、確認の材料にしてほしい。

• 連絡先が特定の担当者の個人携帯電話しかない: その担当者が休暇中や退職した場合、連絡が取れなくなる。会社としての正式な緊急連絡窓口を確保しておくことが望ましい
• サービス品質保証の対応時間が「受付から」なのか「着手から」なのか曖昧: 連絡してから実際に調査が始まるまでの時間と、調査が終わって解決するまでの時間を混同していると、期待値のズレが生じる
• 障害の記録を残していない: 過去に同じような障害が繰り返し起きているのに、記録がないため毎回一から状況説明をする羽目になる
• 開発会社側の連絡フローだけを整備し、社内側の一次確認や周知を怠っている: 開発会社への連絡がスムーズでも、社内で「誰に報告すればいいか分からない」状態では初動が遅れる
• サービス品質保証を契約時に確認したきり、その後一度も見直していない: 事業の変化に対応の水準が追いついていない

これらの失敗パターンの多くは、技術的な問題ではなく、体制と文書化の不備に起因している。逆に言えば、技術投資をしなくても、紙一枚のルール整備だけで防げる失敗が多いということでもある。

連絡フローを文書化する: 誰が見ても迷わない一枚に

ここまで説明してきた内容を、実際に社内で機能させるためには、口頭の申し送りではなく文書として残しておく必要がある。文書化する際は、複雑な手順書を目指す必要はなく、次のような要素が一枚にまとまっていれば十分に機能する。

• 一次確認のチェックリスト(何を確認してから開発会社に連絡するか)
• 社内の連絡窓口担当者の氏名と連絡先、不在時の代理者
• 開発会社の緊急連絡先(電話番号・メールアドレス)と受付時間
• サービス品質保証で合意している対応時間の目安
• エスカレーションの判断基準と、エスカレーション先の連絡先
• 過去に発生した障害とその対応記録(あれば)

この文書は、システム管理台帳と同様に、担当者が異動・退職しても引き継げる形で残しておくことが重要だ。属人化した「あの人しか連絡先を知らない」状態は、まさに障害対応が最も必要とされる場面で機能不全を起こしやすい。文書は年に一度程度、連絡先や契約内容に変更がないかを見直すタイミングを決めておくと、形骸化を防ぎやすい。

また、この文書は開発会社とも共有し、双方が同じ認識を持っておくことが望ましい。社内だけで作った連絡フローと、開発会社が想定している対応フローがずれていると、いざというときに「そちらからそういう連絡が来るとは思っていなかった」というすれ違いが起きる。可能であれば、保守契約の見直しや定例ミーティングの機会に、この連絡フロー文書を開発会社と一緒に確認し、認識をすり合わせておくとよい。

復旧までに時間がかかる場合、中間報告のルールも決めておく

障害対応の連絡フローというと、多くの担当者は「最初の連絡」の場面ばかりを想定しがちだが、実際に運用してみると、復旧までに数時間、あるいは数日を要するケースで問題になりやすいのが「その間の状況報告」だ。最初に連絡した後、開発会社からの続報がないまま時間だけが過ぎていくと、担当者は「本当に対応が進んでいるのか」「忘れられているのではないか」という不安を抱え続けることになる。

この問題を避けるために、連絡フローの中に「中間報告の頻度」という項目を加えておくことをおすすめする。たとえば、対応開始から一定時間ごとに状況を報告してもらう、あるいは進捗に大きな変化があったタイミングで都度連絡をもらうといった取り決めだ。この頻度も、サービス品質保証の一部として契約書や覚書に盛り込んでおければ理想的だが、そこまで厳密な取り決めがなくても、障害発生時の最初の連絡の際に「どれくらいの間隔で状況を教えてもらえますか」と一言確認しておくだけで、その後のやり取りの心理的な負担はかなり軽減される。

中間報告を受け取る側の社内対応としては、次のような点を押さえておくとよい。

• 報告内容を都度、簡単でよいので記録しておく: 「何時に、誰から、どういう状況の報告があったか」をメモしておくと、後から経営層や社内に説明する際の根拠になる
• 社内の他部署への共有タイミングを決めておく: 開発会社からの報告を受けるたびに全社に共有するのか、一定の区切り(解決の見込みが立った時点など)で共有するのかを決めておくと、社内が過度に混乱しない
• 報告が途絶えた場合の扱いを決めておく: 約束した頻度で報告が来なくなった場合、それ自体をエスカレーションの判断材料の一つとして扱う

なお、障害の内容によっては、開発会社側でも原因の特定に時間がかかり、「いつ直るか分からない」という状態が続くことがある。この場合、担当者としてはやきもきする状況が続くが、開発会社を一方的に責める前に、業務への影響を最小化するための代替手段(手作業への一時切り替えなど)を並行して検討することも忘れないようにしたい。連絡フローとサービス品質保証はあくまで「開発会社とのやり取りを円滑にする仕組み」であって、業務を止めないための工夫そのものは、社内側でも並行して考える必要がある。

障害対応フローが機能した状態とは

最後に、ここまで整理してきた連絡フローとサービス品質保証が実際にうまく機能している状態とはどういうものかをまとめておく。それは、障害が起きた瞬間に「何をすべきか考える」時間がほぼゼロになっている状態だ。担当者は文書化された一次確認を数分でこなし、決められた窓口に決められた情報を伝え、契約で合意された時間内に開発会社から一次回答が来ることを見込める。その見込みが外れた場合には、いつ・誰にエスカレーションすべきかも既に決まっている。

この状態を作るために必要なのは、高度な技術知識ではなく、平時のうちに「もしもの時」を具体的に想像し、それを紙一枚のルールに落とし込んでおく作業だ。障害は起きてほしくないものだが、起きること自体を完全にゼロにすることはできない。だからこそ、起きたときにどう動くかを事前に決めておくことが、ひとり情シス・総務兼任の担当者にとって最も費用対効果の高い備えの一つだといえる。

まだ連絡フローが整理できていない場合は、まず自社が結んでいる保守契約書を取り出し、サービス品質保証に関する記載があるかどうかを確認するところから始めてみてほしい。記載がなければ、次の開発会社とのミーティングで「対応時間の目安を明文化したい」と相談することが、最初の一歩になる。

システムの復旧を左右するのは、多くの場合、技術力そのものよりも、事前に決められた体制とルールがあるかどうかだ。次は、システムが壊れたときにどこまでの業務が止まるのかを事前に洗い出しておく「単一障害点」の考え方や、開発会社との関係全般をどう長期的に良好に保つかについても、あわせて確認しておくことをおすすめする。