深夜0時のスマホ通知から始まった承継後初めての障害対応
先代から会社を引き継いで半年が過ぎたある夜、後継社長のもとに営業部長からのメッセージが届いた。「受注サイトが真っ白な画面になっていて、お客様から電話が何件も入っています。どうしたらいいですか」。時刻は夜の十一時を過ぎていた。翌朝から取引先への一斉案内を控えた大事な時期で、受注サイトが止まれば新規の注文だけでなく既存客からの信頼にも傷がつく。後継社長はすぐに開発を依頼している会社の担当者に電話をかけたが、つながらなかった。メールを送っても返信が来る気配はない。先代が現役だった頃は「何かあったら開発会社のあの人に直接連絡すればいい」という暗黙のルートがあったらしいが、後継社長はその「あの人」の携帯番号すら知らなかった。結局、翌朝九時に開発会社の代表番号に電話をして初めて状況が動き出し、原因究明と復旧までに丸一日を要した。
この出来事の後、後継社長が痛感したのは「障害が起きたときに誰に連絡し、どれくらいの時間で対応してもらえるのかという約束が、自社と開発会社のあいだで一度も明文化されていなかった」という事実だった。先代の時代は口約束と個人的な信頼関係で回っていた。だが承継後は担当者が変わり、連絡先が変わり、優先度の感覚も変わる。障害発生時の連絡フローと対応時間の約束、つまりSLA（サービス品質保証）（サービスレベルアグリーメント）が明文化されていなければ、いざというときに社長自身が矢面に立たされ、社内からの信頼も、取引先からの信頼も同時に失いかねない。
後継社長にとってこの経験がとりわけ堪えたのは、技術的な原因そのものではなく、「誰に聞けば状況が分かるのか」が誰にも分からないという状態に丸一晩置かれたことだった。営業部長からの連絡を受けてから、実際に開発会社の担当者と話ができるまでの十時間ほどのあいだ、後継社長は自分のスマートフォンを何度も確認しながら、何もできない自分に苛立ちを募らせていた。翌朝、ようやく状況を説明してくれた開発会社の担当者は「もっと早くご連絡いただければ、休日対応の窓口もありましたので」と口にした。つまり、対応する手段自体は存在していたのに、それが後継社長にも社内の誰にも知らされていなかったというだけの理由で、丸一日の停止と信頼の低下を招いてしまったのである。
この一件は、システムの技術的な障害よりも、情報が正しい相手に正しく届く仕組みが欠けていることの方が、はるかに大きな経営リスクになり得るという事実を後継社長に突きつけた。会社を継いだばかりの経営者にとって、システムの中身を細部まで理解することは難しい。しかし、障害が起きたときに誰に連絡すればよいか、どれくらいの時間で答えが返ってくるのかという「連絡の設計」そのものは、技術知識がなくても整備できる経営マターである。本記事では、なぜこの問題が承継直後の会社で頻発するのか、実際にどのような形で表面化するのか、そして後継社長が具体的に何をすべきかを、実務のステップに沿って詳しく解説する。
なぜ承継後に障害対応の連絡フローが崩れるのか
先代時代の「暗黙の連絡網」が承継で消える構造
多くの中小企業では、システムの障害対応は明文化された手順ではなく、先代社長と開発会社の担当者個人との人間関係で成立していた。先代が開発会社の社長や特定のエンジニアと長年の付き合いがあり、「困ったら電話一本」で動いてもらえる関係を築いていたケースは非常に多い。このような関係は一見理想的に見えるが、実際には極めて脆い基盤の上に成り立っている。連絡先が特定の個人の携帯番号に紐づいており、その人が休暇中だったり、退職していたり、あるいは開発会社側で担当が異動していたりすると、瞬時に機能不全を起こす。
承継が発生すると、この暗黙の連絡網は二重の意味で崩壊する。まず、後継社長は先代が誰にどう連絡していたのかという経緯そのものを知らない。先代が「何かあったらまず携帯に電話して、出なければ会社の代表に連絡して」という手順を頭の中だけで持っていた場合、それは引き継ぎ資料に残らない。事業承継の引き継ぎというと、多くの経営者は決算書や取引先リスト、金融機関との関係、従業員の処遇といった項目を思い浮かべる。しかしシステムの障害対応フローという項目は、そもそも「引き継ぐべき情報」としてリストアップされることがほとんどない。先代自身が「そんなことはいつも自然にやっていたことで、特別な知識だと思っていなかった」ため、意識的に伝える対象から漏れてしまうのである。
次に、開発会社側から見ても、後継社長は「新しい顔」であり、これまでの信頼関係の蓄積がリセットされた状態からのスタートになる。開発会社の担当者にとっても、後継社長が本当に決裁権を持つ相手なのか、緊急対応の費用を最終的に誰が承認するのかが不明確なまま、対応の優先順位を判断しなければならない場面が生まれる。開発会社は複数の顧客を同時に抱えていることが多く、限られた人員でどの顧客の障害に優先的に対応するかを判断する際、長年の付き合いがあり信頼関係が厚い顧客が優先されやすいという現実もある。承継直後の後継社長は、まさにその「信頼関係の蓄積」を持たない顧客として扱われるリスクを抱えている。
さらに、承継のタイミングでは開発会社側の担当者も入れ替わっていることが少なくない。先代の代からの付き合いが長い会社ほど、開発会社側の創業メンバーや初期の担当エンジニアが退職・引退し、当時の経緯を知らない新しい担当者に引き継がれているケースが多い。つまり、発注側と受注側の両方で「当時の暗黙の了解を知っている人」がいなくなり、双方が過去の経緯を知らないまま関係を再構築しなければならない状況が生まれる。この二重の断絶こそが、承継直後の会社で障害対応の連絡フローが崩れる最大の構造的原因である。
中小企業のシステム受託契約にSLAが明記されていないことが多い理由
そもそも中小企業がシステム開発を発注する際の契約書には、SLAという概念そのものが盛り込まれていないことが非常に多い。理由はいくつかある。第一に、システム導入当初は「まずは作って動かす」ことが最優先事項であり、障害発生時の対応時間や連絡フローといった運用フェーズの取り決めは後回しにされがちである。第二に、発注側である中小企業の経営者自身がSLAという概念に馴染みがなく、開発会社に「決めておいてください」と一任してしまい、結果として何も決まらないまま契約が締結されてしまう。第三に、開発会社側も、明確なSLAを提示すると自社の負担が重くなるという意識から、あえて曖昧にしたまま契約を進めることがある。
この状態が何年も続いたまま先代の代で問題が表面化しなかったのは、前述の「個人的信頼関係」がSLAの機能を代替していたからにすぎない。契約書に「障害発生時は四時間以内に初回応答」といった条項がなくても、先代と開発会社の間には「大体こういうときはすぐ動いてくれる」という相互期待が存在していた。しかしこの相互期待は文書化されていないがゆえに、承継のタイミングで簡単に失われる。後継社長が新たに構築しなければならないのは、まさにこの「文書化されていない相互期待」を、誰が見ても同じ理解に至る形の文書として再定義する作業である。
加えて、システム導入時に契約を結んだ担当者が、そもそも将来の障害対応まで見据えて契約条件を検討していなかったという事情もある。多くの中小企業では、システム開発の発注時に最も注力するのは機能要件や見積金額であり、「動かなくなったときにどうするか」という運用面の取り決めは、契約交渉の最終盤で軽く触れられる程度で終わってしまう。開発会社側の提案書にも、初期構築のスケジュールや費用は詳細に記載されている一方で、障害対応の体制について具体的な数値を伴って記載されている例は決して多くない。この傾向は特に、開発会社が中小企業向けに一括受託のパッケージ料金で提案している場合に強く見られる。結果として、システムが正常に動いている間は誰も気にしないが、実際に障害が発生した瞬間に、双方が「決めていなかったこと」の大きさに初めて気づくことになる。
障害発生時に社長が矢面に立つ構造的な理由
もう一つ見落とされがちな構造的な問題がある。中小企業においては、システムの担当窓口が明確に分かれていないケースが多く、障害が発生すると最終的に社長のもとに情報が集まってくる。現場の担当者は「どこまで自分の判断で開発会社に依頼していいのか」が分からず、結局「社長に確認してから」という判断になる。特に承継直後は、古参社員が「先代の頃はこうだった」という基準を強く持っているため、新しい判断基準を後継社長自身が示さない限り、現場は動けない。
この現象は、承継直後の会社に特有の心理的な力学からも説明できる。古参社員にとって、先代は長年一緒に会社を作り上げてきた存在であり、その判断基準には絶対的な信頼が置かれている。一方で後継社長は、まだ社内での実績を積んでいない状態にあることが多い。そのため、現場の担当者は「新しい社長の判断で開発会社に緊急対応を依頼して、もし費用が高額だったらどう説明すればいいのか」という不安を抱きやすい。この不安が、現場担当者を「まず社長に確認する」という慎重な行動に向かわせ、結果として初動の時間を消費してしまう。後継社長自身がこの心理的な力学を理解し、あらかじめ「これくらいの障害であれば、現場の判断で開発会社に連絡してよい」という基準を明確に示しておかない限り、この遅延は何度でも繰り返される。
さらに、開発会社側から見ても、緊急対応には追加の費用が発生することが多く、その承認を現場担当者レベルで得ることは難しい。多くの保守契約では、通常の保守範囲を超える緊急対応や休日対応には別途の費用が発生する仕組みになっている。現場担当者がこの費用の発生を独断で承認することはできず、必然的に決裁権を持つ社長への確認が必要になる。結果として、障害の連絡は現場から社長へ、社長から開発会社へという二段階のルートを通ることになり、これが初動の遅れを生む最大の要因となる。この構造そのものを変えるためには、誰が最初の連絡窓口になるのか、どこまでの対応を現場の判断で進めてよいのか、費用発生を伴う対応をどの段階で承認するのかを、あらかじめSLAと連絡フローの文書に落とし込んでおく必要がある。例えば「一定額以下の緊急対応費用は現場担当者の判断で発注してよい」という事前承認の範囲を決めておくだけでも、初動の速度は大きく変わる。
開発会社側の体制によってもSLAの実現可能性が変わる
もう一つ理解しておくべき構造は、開発会社側の体制によって、そもそもどこまでの対応時間を約束できるのかが変わってくるという点である。ごく小規模な開発会社や個人事業主に近い形態の開発パートナーの場合、担当者が一人しかおらず、その人が休暇中や病気で動けない場合には物理的に対応不可能な時間帯が生じる。一方で、複数人の体制を持つ開発会社であれば、当番制やエスカレーション体制を組むことができ、より現実的な対応時間を約束できる可能性が高まる。
後継社長が自社の発注先の体制を正しく理解せずに、大企業並みの二十四時間対応を期待してしまうと、そもそも実現不可能な約束を求めることになり、開発会社との関係がこじれる原因になる。逆に、開発会社の実際の体制を確認した上で「平日日中は二時間以内、夜間休日は次営業日対応」といった、実現可能な範囲でのSLAを設定することが、双方にとって持続可能な取り決めになる。
この点で後継社長が陥りやすい誤解が、開発会社の規模と対応品質を単純に結びつけてしまうことである。規模の大きな開発会社であれば安心、規模の小さな開発会社であれば不安、という単純な図式で捉えてしまうと、実際に必要な確認作業を怠ってしまう。重要なのは規模そのものではなく、自社のシステムを実際に担当している体制が何人で、その体制がどのような場合に機能不全を起こすのかを具体的に把握することである。担当者が一人だけの体制であっても、その担当者が休暇中に別の担当者へ引き継ぐ仕組みが整っていれば実務上問題は生じにくい。逆に、大きな開発会社であっても、自社の案件を担当しているのが実質的に一人だけであれば、リスクは小規模な会社と変わらない。後継社長は、契約書に記載された会社の規模ではなく、実際の担当体制を確認するという視点を持つ必要がある。
ケーススタディで見る障害対応の失敗と成功
ケース1 受注サイトのダウンで連絡先が分からず半日を失った印刷会社
ある印刷会社では、先代の代からウェブサイト経由での受注を受け付ける仕組みを運用していた。先代が退任し息子が社長を継いだ直後、平日の午前中に受注フォームが正常に動作しなくなるトラブルが発生した。営業担当者は「フォームからの注文が入ってこない」と気づいたが、誰に連絡すればよいのか分からず、まず社長に相談した。後継社長は先代の残していたメールの履歴を遡り、数年前に一度やり取りした開発会社の担当者名を見つけたが、その担当者は既に退職していた。
会社の代表電話に連絡してようやく別の担当者に取り次いでもらえたのは、トラブル発覚から三時間後だった。その後の調査で原因判明までさらに二時間、修正対応の完了までさらに三時間かかり、合計で約八時間にわたって受注フォームが機能しない状態が続いた。この間に発生した推定被害は、問い合わせ電話の対応に追われた営業担当者の稼働時間だけでなく、受注できなかった注文の一部が競合他社に流れたことによる売上機会の損失も含まれる。
さらに深刻だったのは、この八時間のうち最初の三時間、つまり連絡先が判明するまでの時間帯に、社内で誰も状況を正確に把握できていなかったことである。営業担当者は「サイトがおかしい」という情報だけを社長に伝え、後継社長自身もシステムの構造を理解していなかったため、何が原因で受注フォームが動かないのか、自社側で何か対応できることがあるのかすら判断できなかった。ただ待つしかない状態が三時間続いたことが、現場の焦りと社長への不信感を同時に増幅させた。後継社長はこの一件をきっかけに、開発会社との間で緊急連絡先を明文化し、初回応答の時間を契約書に明記する交渉を始めた。同時に、社内でも「システムに異常を感じたら、まず誰に、どの手段で連絡するか」を一枚の紙にまとめ、営業所の壁に貼るという地道な対策も講じた。この事例が示しているのは、連絡フローが定まっていないことによる時間の損失が、技術的な復旧作業そのものよりもむしろ大きくなり得るという点であり、さらに言えば、その時間の大部分は「何が起きているか分からない」という不安の時間でもあったという点である。
ケース2 SLAを明文化したことで初動が三十分に短縮された物流会社
一方で、承継後にSLAの整備に早期に着手した物流会社の例もある。この会社では、後継社長が就任してから半年以内に、システムを委託している開発会社との間で「障害発生時の連絡フロー」を文書化した。具体的には、現場の担当者が異常に気づいた時点で即座に開発会社の専用窓口（メールアドレスとチャットツールのグループ）に連絡し、開発会社は受付から三十分以内に一次回答を返すという取り決めを結んだ。加えて、社長への報告は「一次回答を受けた時点」と「復旧完了時点」の二回に限定し、対応の細部については現場担当者と開発会社が直接やり取りしてよいというルールを定めた。
その後、実際に配送管理システムに障害が発生した際、現場担当者が窓口に連絡してから二十八分後に開発会社から一次回答が届き、暫定的な代替手順の案内とともに復旧作業が開始された。社長のもとには一次回応答の連絡が入った時点で状況が共有され、社長自身が個別の技術対応に追われることはなかった。復旧完了までの総時間は約四時間だったが、その間、現場は既に案内された代替手順で業務を継続できていたため、実質的な業務停止時間はごく短時間にとどまった。
この物流会社の後継社長が特に工夫していたのは、SLAの整備を単発の交渉として終わらせず、就任後の最初の三か月間で段階的に進めたことだった。就任直後にまず現状の連絡フローを聞き取り、次に開発会社の担当者と面談して実際の対応体制を確認し、その上で無理のない範囲の初回応答時間を提案するという順序を踏んだ。開発会社側も、後継社長が現実的な要求をしていることを理解し、協力的に交渉に応じた。さらに、この後継社長は整備した連絡フローを一度机上で終わらせず、実際に軽微な不具合が発生した際に試験的に運用してみることで、想定していた手順に無理がないかを事前に検証していた。この事例が示すのは、SLAと連絡フローを事前に明文化しておくことで、障害そのものの発生を防ぐことはできないが、対応の初動を大幅に早め、社長が本来の経営判断に集中できる体制を作れるという点であり、加えて、その整備は一度の交渉で終わらせるのではなく、段階的に検証しながら固めていくことが実効性を高めるという点である。
ケース3 SLAはあったが運用が形骸化していた建材メーカー
三つ目の事例は、SLAが文書として存在していたにもかかわらず、実際には機能していなかったケースである。ある建材メーカーでは、先代の時代に締結した保守契約書の中に「障害発生時は当日中に対応」という一文が記載されていた。しかし、この一文には具体的な連絡窓口の指定も、当日中の定義（何時までを当日とするか）も、対応レベルの段階分けも記載されていなかった。承継後に基幹システムでデータの不整合が発生した際、後継社長は契約書の存在を認識していたため安心していたが、実際に連絡を取ろうとすると窓口が定まっておらず、複数の担当者にメールを転送する事態になった。「当日中」という約束はかろうじて守られたものの、対応が始まったのは営業時間終了間際で、実質的な復旧は翌日にずれ込んだ。
この事例が示す教訓は、SLAという言葉や条項が契約書に存在すること自体は安心材料にならないという点である。連絡窓口が具体的に指定されているか、対応レベルが障害の深刻度別に分かれているか、対応開始の起点となる時刻がどう定義されているかまで踏み込んで確認しなければ、SLAは実務上まったく機能しない。後継社長はこの一件の後、契約書を見直し、連絡窓口を一本化し、障害の深刻度を三段階に分けてそれぞれの初回応答時間を明記する改訂を開発会社と協議した。
この建材メーカーの事例をさらに詳しく振り返ると、後継社長が契約書の存在に安心してしまった背景には、先代からの引き継ぎの際に「保守契約はちゃんと結んであるから大丈夫」という一言だけが伝えられ、その内容の細部までは説明されなかったという事情があった。多くの後継社長は、契約書という「形」があることをもって安心してしまい、その内容が実務上機能するレベルまで具体的に書かれているかどうかを検証する機会を持たない。この建材メーカーのケースでは、実際に障害が発生するまで、誰もこの契約条項の弱点に気づかなかった。承継後にシステム関連の契約書を見直す作業は、多くの後継社長にとって優先度が低く扱われがちだが、実際に障害が起きたときにその弱点が一気に表面化するという性質を持つ。だからこそ、障害が実際に発生する前の、平穏な時期にこそ契約書の内容を精査しておく価値がある。
実務対応ステップとチェックリスト
ステップ1 現状の連絡フローを可視化する
最初に行うべきは、現在実際にどのような連絡フローが機能しているのか、あるいは機能していないのかを可視化することである。多くの会社では、これが文書化されていないため、まずは関係者への聞き取りから始める必要がある。先代が使っていた連絡先、現場担当者が実際に何かトラブルがあったときに誰に連絡しているか、開発会社側の担当者構成を確認する。この段階で、複数の担当者がそれぞれ別の連絡先を持っていたり、退職済みの担当者の連絡先しか残っていなかったりする実態が判明することが多い。可視化の結果は簡単な図やリストの形で残し、社内で共有できる状態にしておく。
聞き取りを行う際は、現場担当者一人だけでなく、複数の部署・複数の担当者に同じ質問をすることが望ましい。ある担当者は「メールで連絡している」と答え、別の担当者は「電話で直接話している」と答えるなど、部署によって異なる連絡経路が並行して存在していることが少なくない。この不一致自体が、連絡フローが組織として統一されていないことの証拠であり、可視化の過程で必ず発見しておくべき事実である。実際にトラブルが起きたときに感情的にならず交渉するための技術は、トラブル時の交渉術。感情的にならずに解決するで詳しく取り上げている。また、先代自身がまだ会社に関わっている場合は、先代からも直接聞き取りを行い、これまでどのような経緯で開発会社との関係が築かれてきたのかを記録しておくとよい。先代の記憶は時間とともに薄れていくため、承継後できるだけ早い時期に聞き取りを済ませておくことが望ましい。
ステップ2 障害の深刻度を段階分けする
すべての障害を同じ重さで扱うと、対応の優先順位がつけられず、些細な不具合と事業停止レベルの重大障害が同じ扱いになってしまう。実務上は、障害を「事業が完全に停止する重大障害」「一部機能が使えないが業務は継続できる中程度の障害」「見た目や軽微な不具合で業務への影響がほぼない障害」の三段階程度に分けて定義することが望ましい。それぞれの段階に応じて、初回応答までの目標時間や、対応を進める優先順位を変えることで、開発会社側も無理のない範囲で現実的な対応を約束できるようになる。
段階分けを行う際に重要なのは、抽象的な言葉ではなく、自社の具体的な業務に即した基準で定義することである。例えば「受注サイトから注文が一件も入らない状態」や「配送管理システムに新規のデータを登録できない状態」といった、現場の担当者が見ればすぐに判断できる具体的な状況を重大障害の定義として書き込む。逆に「表示のレイアウトが一部崩れているが、注文自体は正常に処理できている」といった状況は軽微な不具合に分類する。この具体化の作業は、開発会社に一任するのではなく、自社の現場担当者と一緒に検討することで、実際の業務実態に即した段階分けが可能になる。段階分けが具体的であればあるほど、障害発生時に現場担当者が迷わず正しい深刻度を判断できるようになり、開発会社への連絡内容も的確になる。
ステップ3 緊急連絡窓口を一本化し、複数の連絡経路を確保する
先代時代の失敗パターンとしてよくあるのが、連絡先が特定の個人一人に集中していたことである。これを改善するために、緊急連絡窓口はできるだけ「個人」ではなく「組織的な窓口」に一本化する。具体的には、専用のメールアドレスや、チャットツールの共有グループ、あるいは緊急時専用の電話番号など、複数人がアクセスできる経路を用意してもらうよう開発会社と協議する。同時に、その窓口が実際に機能しているかを平常時に一度テストしておくことも有効である。
窓口の一本化を進める際には、連絡経路を一つに絞りすぎないことも重要である。メールだけを唯一の連絡手段にしてしまうと、メールサーバーの不調やメールの見落としによって連絡自体が届かないリスクが残る。理想的には、第一の連絡手段（例えばチャットツールの共有グループ）と、それが機能しない場合の第二の連絡手段（例えば電話）をあらかじめ決めておき、第一の手段で一定時間以内に反応がなければ第二の手段に切り替えるという二段構えのルールを作っておくと、連絡が完全に途絶える事態を避けられる。また、開発会社側の休業日や長期休暇の期間についても事前に確認し、その期間中の連絡手段が通常時と異なる場合は、その情報も社内で共有しておく必要がある。
ステップ4 初回応答時間と復旧目標時間を数値で明記する
SLAの核心は、抽象的な「早めに対応します」という約束ではなく、具体的な数値で時間を定めることにある。初回応答時間（連絡を受けてから最初の反応があるまでの時間）と、復旧目標時間（実際に問題が解消するまでの目標時間）は分けて考える必要がある。初回応答は比較的短い時間（例えば数十分から数時間以内）で約束できることが多いが、復旧そのものは原因の複雑さによって時間が変動するため、目標値として置くのが現実的である。この数値は開発会社側の体制と相談しながら、実現可能な範囲で合意することが重要であり、無理な数値を一方的に押し付けると関係が悪化する。
初回応答と復旧を分けて考えるべき理由は、後継社長の心理的な安心感に直結するからでもある。実際の障害対応において、社長が最も不安を感じるのは「問題が解決するまでの時間」ではなく、「誰かが今この問題に取り組んでいると分かるまでの時間」であることが多い。連絡してから三十分以内に「状況を確認しています。原因を調査中です」という一次回答が届くだけで、その後の待ち時間に対する社長や現場の心理的な負担は大きく軽減される。逆に、初回応答すら来ない状態が続くと、実際の復旧作業がどれだけ迅速に進んでいたとしても、発注側は「見捨てられているのではないか」という不安を強めてしまう。この心理的な側面を理解した上で、初回応答時間を優先的に短く設定し、復旧目標時間は現実的な幅を持たせるという設計が、実務上もっとも機能しやすい。
ステップ5 平日夜間・休日の対応可否を明確にする
多くの中小企業向け開発会社は、平日日中のみの対応体制であることが多い。後継社長が二十四時間対応を期待している場合、この前提のズレが障害発生時に致命的な遅延を生む。夜間や休日に障害が発生した場合、どこまでの対応がなされるのか、追加費用が発生するのかどうかを事前に確認し、文書に残しておく必要がある。対応不可の時間帯があること自体は問題ではなく、それを社長と現場が正しく認識していないことが問題である。
夜間・休日の対応可否を確認する際には、単に「対応できるか、できないか」の二択で聞くのではなく、「対応できない場合、次の営業日の何時から対応が始まるのか」まで具体的に確認しておくことが望ましい。例えば土曜日の夜に障害が発生した場合、月曜日の朝一番に対応が始まるのか、それとも月曜日の午後になるのかによって、実質的な業務への影響は大きく異なる。また、休日に対応してもらう場合の追加費用についても、金額の目安を事前に把握しておくことで、実際に障害が発生した際に費用面での判断に時間を取られることを避けられる。自社の事業内容が夜間や休日にどれだけシステムに依存しているかを踏まえ、必要であれば夜間休日対応のオプションを契約に追加することも検討に値する。
ステップ6 社内の報告ルートを整理する
障害発生時に、現場担当者から社長にどのタイミングで、どういう内容の報告をするのかも決めておく必要がある。すべての障害の詳細を社長に報告する必要はなく、重大障害の発生時と復旧完了時の二点に絞るなど、社長が経営判断に集中できる報告設計が望ましい。逆に、現場が判断に迷って社長の指示を待つ時間が長引くことも避けるべきであり、現場担当者がどこまで自分の判断で開発会社とやり取りしてよいかの権限範囲も明記しておく。
報告ルートを整理する際には、報告の「量」だけでなく「質」にも注意を払う必要がある。現場担当者が状況を正確に把握していないまま社長に報告してしまうと、社長は不正確な情報をもとに判断を下すことになり、結果として的外れな指示を出してしまう可能性がある。これを避けるためには、報告の際に最低限含めるべき項目をあらかじめ決めておくとよい。例えば「いつから発生しているか」「どの業務に影響が出ているか」「開発会社への連絡は済んでいるか」「開発会社からの回答内容」といった項目をテンプレートとして用意しておけば、現場担当者は慌てている状況でも漏れのない報告ができる。このテンプレートは、社内のチャットツールやメールの雛形として事前に整備しておくことが実務的である。
ステップ7 取引先・顧客への情報開示のルールを決める
システム障害が顧客対応にも影響する場合（受注サイトの停止など）、いつ、誰が、どのような内容で顧客に告知するのかも事前に決めておくべきである。障害の内容を隠そうとして対応が後手に回ると、後から「なぜ早く知らせなかったのか」という別の信頼問題に発展する。あらかじめテンプレートとなる告知文を用意しておくと、実際の障害発生時に落ち着いて対応できる。
情報開示のルールを決める際には、開示する情報の範囲についても注意が必要である。技術的な原因の詳細まで顧客に伝える必要はなく、多くの場合は「現在システムに不具合が発生しており、復旧作業を進めている」という程度の情報で十分である。むしろ重要なのは、いつまでに次の情報を伝えるかという「更新の約束」を明示することである。例えば「一時間後に状況を再度お知らせします」という一文を添えるだけで、顧客側の不安は大きく軽減される。この情報開示のタイミングと文面のテンプレートを、ウェブサイトの告知欄用、電話対応時の応答用、取引先へのメール用など、複数のチャネルに応じて事前に用意しておくと、実際の障害発生時に慌てずに対応できる。
ステップ8 契約書・保守契約の条項として明文化する
聞き取りと協議を経て固まった連絡フローとSLAの内容は、口頭の合意にとどめず、契約書や保守契約の条項として明文化することが最も重要なステップである。文書化されていない約束は、担当者の異動や退職とともに簡単に失われる。特に、連絡窓口の具体的な連絡先、障害深刻度の定義、各深刻度における初回応答時間、対応可能な時間帯、費用が発生する場合の条件は、必ず条文または別紙の形で残しておく。
契約書本体の改訂には時間がかかることが多いため、実務上は本体契約に手を加えず、覚書や運用ルールの別紙という形で追加することも現実的な選択肢である。この場合、別紙の内容が本体契約と矛盾しないように文言を調整し、双方の代表者が署名または捺印する形で正式な合意文書としての効力を持たせておく。契約更新のタイミングで開発会社から他にどんな情報を受け取っておくべきかは、保守契約を更新する前に、開発会社から受け取っておくべきものにまとめている。また、文書を作成した後は、社内の関係者全員がその内容を確認できる場所に保管し、いざというときに誰でも参照できる状態にしておくことが重要である。せっかく整備した連絡フローとSLAが、社長の引き出しの中にしまわれたまま現場の誰にも共有されていないという事態は避けなければならない。
ステップ9 定期的にSLAの実効性を見直す
一度決めたSLAも、開発会社側の体制変更や自社の事業内容の変化によって現実に合わなくなることがある。年に一度程度、実際に障害が発生した際の対応記録を振り返り、約束した時間が実際に守られていたか、連絡フローに無理がなかったかを見直す機会を設けることが望ましい。
見直しの機会としては、実際に障害が発生した直後がもっとも有効なタイミングである。障害対応が一通り終わった後に、現場担当者と開発会社の担当者を交えて簡単な振り返りの場を設け、「連絡がスムーズに通じたか」「初回応答は約束の時間内だったか」「報告のタイミングに無理はなかったか」を確認する。この振り返りを積み重ねることで、当初決めたSLAの数値が現実と合っているかどうかを実績データとして検証でき、必要に応じて数値を調整する根拠にもなる。障害が全く発生しない期間が続いた場合でも、開発会社の担当体制に変更がないかを定期的に確認しておくことで、いつの間にか約束が空文化するという事態を防げる。
チェックリスト
- 緊急連絡窓口は個人ではなく組織的な窓口（共有メール・共有チャット等）になっているか
- 障害の深刻度が段階分けされ、それぞれの初回応答時間が数値で決まっているか
- 平日夜間・休日の対応可否と、対応する場合の追加費用の有無が明記されているか
- 社内の報告ルート（誰が誰にいつ報告するか）が整理されているか
- 現場担当者がどこまでの判断・依頼を自分の権限で行えるかが決まっているか
- 顧客・取引先への情報開示のタイミングとテンプレートが用意されているか
- 連絡フローとSLAの内容が契約書または保守契約の別紙として文書化されているか
- 直近一年以内に実際の連絡フローをテストまたは見直したか
よくある失敗パターン
失敗パターン1 契約書に「速やかに対応」としか書かれていない
多くの中小企業の保守契約書には「障害発生時は速やかに対応する」という一文だけが記載されていることがある。この表現には具体的な時間の定義がなく、実際に障害が起きたときに「速やかに」が三十分を指すのか、三日を指すのかで開発会社と発注側の認識が大きくずれる。後継社長がこの一文を見て「対応してもらえる約束がある」と安心してしまうのは危険であり、実際には何の実効性もない場合が多い。契約を見直す際は、この曖昧な表現を具体的な数値に置き換える交渉を必ず行うべきである。特に承継直後は、こうした曖昧な条文をそのまま放置してしまいがちであり、実際に障害が発生してから初めてその弱さに気づくというパターンが繰り返される。平穏な時期に契約書を読み返し、数値化されていない表現を一つひとつ点検する作業を、承継後のタスクとして早い段階で組み込んでおくことが望ましい。
失敗パターン2 連絡先が担当者個人のスマートフォンの番号しかない
先代の時代からの慣習で、開発会社の特定の担当者の個人携帯番号だけが緊急連絡先として引き継がれているケースは非常に多い。この担当者が休暇中、病気、あるいは退職していた場合、連絡そのものが成立しなくなる。承継直後にこの状態に気づかず放置していると、実際の障害発生時に初めて連絡不能という事態に直面することになる。担当者個人ではなく組織としての窓口を持つよう、早期に開発会社と協議しておく必要がある。この失敗パターンの厄介な点は、平常時には何の問題も表面化しないことである。システムが正常に動いている限り、連絡先が個人の携帯番号一つしかないという状態は誰の目にも異常には見えない。だからこそ、後継社長自身が意識的にこのリスクに目を向け、障害が起きる前に確認と改善を進めておく必要がある。
失敗パターン3 社内の誰が最初の連絡役かが決まっていない
障害の第一発見者が誰に報告すべきかが決まっていないと、情報が社内で右往左往し、開発会社への連絡自体が遅れる。特に承継直後は、古参社員が「先代ならこうしていた」という記憶だけで動いてしまい、新しい社長が知らないところで独自の判断がなされることもある。逆に、誰も判断できず社長の指示を待ち続けるケースも多い。社内での第一報告者と、開発会社への連絡権限を持つ人物をあらかじめ明確にしておくことが、初動の速さを左右する。この問題は、部署をまたいだ障害が発生した場合にさらに深刻になる。例えば営業部門が気づいた不具合が実は基幹システム側の問題であった場合、営業部門の担当者が製造部門やシステム担当部署にどう連携すればよいのかが決まっていないと、情報の伝達だけで時間を浪費してしまう。承継後は、部署ごとの縦割りの意識が強く残っていることが多く、この横の連携ルートも合わせて整理しておく必要がある。
よくある質問
SLAという言葉を使わずに、開発会社にどう相談すればよいですか
SLAという専門用語を使わなくても、「障害が起きたときに、誰にどうやって連絡すればよいか」「連絡してからどのくらいで対応してもらえるか」「夜間や休日は対応してもらえるか」という三つの質問を具体的に開発会社にぶつければ、実質的にSLAの内容を確認することができる。まずは現状の対応体制を聞き出すことから始めるとよい。
小規模な開発会社にも同じレベルのSLAを求めてよいのでしょうか
開発会社の規模や体制によって、現実的に約束できる対応時間には差がある。担当者が一人しかいない小規模な開発会社に対して大企業並みの二十四時間対応を求めるのは非現実的である。まずは相手の体制を正確に理解し、実現可能な範囲でのSLAを段階的に合意していくことが、長期的な関係を維持するうえで重要である。
既存の保守契約にSLAの条項がない場合、追加で交渉できますか
多くの場合、保守契約は更新のタイミングがあり、その機会に条項の追加や修正を交渉することができる。更新のタイミングを待たずとも、運用ルールの覚書や別紙という形で連絡フローとSLAを追加することも実務上は可能である。まずは開発会社に率直に相談し、双方にとって現実的な内容を協議することが第一歩になる。
障害対応の連絡フローは誰が主導して整備すべきですか
最終的な責任は経営者である後継社長にあるが、実務上は社内のシステム担当者や現場の管理職と協力して整備することが望ましい。現場の実態を把握している担当者の意見を取り入れずに社長だけで決めてしまうと、実際の運用で無理が生じることがある。社長が方向性を示し、現場と開発会社の三者で具体的な内容を固めていく進め方が現実的である。
障害が一度も起きていない状態で、SLAの整備に着手する意味はありますか
障害が起きていない平穏な時期こそ、SLAの整備に最も適したタイミングである。実際に障害が発生している最中は、双方とも目の前の対応に追われて冷静な交渉ができない。平常時であれば、開発会社側も落ち着いて自社の体制を説明でき、発注側も無理のない要求内容を検討できる。承継直後のできるだけ早い時期に、障害が起きていない状態で整備を進めておくことが、結果的に最も効率的な進め方になる。
まとめ
先代の時代に築かれていた開発会社との個人的な信頼関係は、承継とともに簡単に失われる。障害発生時に誰に連絡し、どれくらいの時間で対応してもらえるのかという約束が明文化されていなければ、後継社長は初めての障害対応で右往左往し、社内からの信頼も取引先からの信頼も同時に揺らぐことになる。本記事で見た三つの事例が示すように、連絡フローとSLAが整備されているかどうかは、障害そのものの重大さよりも、対応にかかる実質的な時間と社長自身の負担を大きく左右する。
印刷会社の事例では連絡先の不明が半日の停止を招き、物流会社の事例では事前整備が初動を三十分に短縮し、建材メーカーの事例では文書があっても実効性がなければ機能しないことが示された。この三つはいずれも、技術力の高さや低さとは無関係に、連絡と約束の設計次第で結果が大きく変わることを物語っている。特に繁忙期に想定外のトラブルが起きたときの対処法は、小売業、繁忙シーズン中に想定外トラブルが起きたときの対処法も参考にしてほしい。後継社長がシステムの専門知識を持たなくても、この設計は十分に主導できる。まずは現状の連絡フローを可視化し、障害の深刻度を段階分けし、緊急連絡窓口を組織的な形に一本化することから始めたい。そのうえで、初回応答時間や対応可能な時間帯を数値で明記し、契約書または保守契約の別紙として文書化することで、担当者の異動や退職に左右されない、持続可能な対応体制を築くことができる。
承継後の早い段階でこの整備に着手しておくことが、いざ障害が発生した際に社長自身が落ち着いて経営判断に専念できる環境を作る、最も確実な備えになる。障害は「いつか起きるかもしれないもの」ではなく、「いつ起きるか分からないが必ず起きるもの」として捉え、平穏な今のうちに連絡フローとSLAという土台を固めておくことが、後継社長にとって古参社員や取引先からの信頼を積み重ねていく第一歩にもなる。
