SaaS/会員サイト/ECは、公開した瞬間から「運用」が始まります。
そして制作会社が詰む原因は、インフラ知識の不足というより、運用の境界が決まっていないことにあります。
この記事でいう「詰む」は、初動が止まり、調査と顧客説明が制作側に固定される状態を指します。
- 監視が鳴ったら誰が見るのか
- どこまでが一次対応なのか
- 原因究明はどこまで追うのか
- 顧客へ誰が何を伝えるのか
この4点が曖昧なまま進むと、問い合わせの一次受け、障害時の判断依頼、顧客への一次報告が「気づいた人」「動いた人」に集まり続けます。
結果として、制作に加えて運用対応の一次窓口を担う状態になり、調整と説明の工数が増えます。
境界が未定だと、「作業」より先に「連絡経路と判断者の調整」が発生します。
連絡の窓口を一度担うと、その後も同じ人に連絡が集まりやすくなり、一次対応と顧客対応の担当が固定されます。その結果、一次対応や顧客説明まで制作側の役割として扱われやすくなります。
SaaS/会員サイト/ECは、止まったときの影響が売上や業務に直結しやすいため、連絡頻度が上がり即レスを求められやすい領域です。
だからこそ、曖昧なまま始めると、初動の遅れと説明・調整の工数が大きくなります。
この記事では、SaaS/会員サイト/ECで運用が一気に重くなる条件を「落とし穴」として整理し、受託判断の前に最初に線を引く責任分界の型と、そこから落とし込む運用境界の棚卸し項目をまとめます。
既存保守がいるケースでも、「まず既存に確認」の前に整理できることがあります。制作側で論点と未確定事項を洗い出し、確認すべき質問を揃えておくのが狙いです。
この記事の目的は、「受けるかどうか」ではなく、受けるなら背負う範囲を決めた状態を作ることです。
SaaS/会員サイト/ECは作って終わりではない──詰むのは運用だった
制作会社が巻き込まれるのは運用の境界が決まっていないから
立ち上げ後に増えるのは、開発よりも運用寄りの仕事です。たとえば次の4つが継続的に発生します。
- 問い合わせ：ログインできない、決済が通らない、画面が遅い、不具合報告
- 障害：監視アラート、5xxエラーの増加、外部連携エラー、ジョブ停止、性能劣化
- 変更：キャンペーン対応、料金改定、外部API仕様変更、証明書更新、パッチ適用
- 説明：顧客への一次報告、影響範囲の説明、原因の整理、再発防止の提示
ここで重要なのは、「運用を背負う」のは技術力の問題ではなく、境界が未定なだけという点です。
境界が決まっている案件は、障害が起きても、一次対応、切り分け、顧客への一次報告が滞りなく進みます。
境界が決まっていない案件は、「誰に聞くか」「誰が判断するか」から始まり、初動の10〜30分が溶けることも珍しくありません。
よくある失敗パターン：気づいた人が対応し続けて担当化する
制作会社が担当化する典型パターンは次の流れです。
- 監視通知が個人に飛ぶ
- 夜に鳴る
- とりあええず見に行く
- 一旦復旧させる
- 次もその人に通知が飛ぶ
- そのまま「担当」になる
最初の一回は問題ではありません。
ただ「次も同じ人に飛ぶ」状態が続くと、本人の稼働や心理的負担の問題に見えて、実態は運用設計の問題になります。個人の頑張りで回している限り、破綻のリスクが高まります。
もうひとつ厄介なのが、調査の終点が決まらないパターンです。
- 原因をどこまで追うかが未定
- 外部連携やクラウド要因も疑わしい
- 調査が終わらない
- 顧客説明も制作に寄る
- いつの間にか運用窓口になる
詰むのは事故そのものよりも、事故のときに誰が何をするかが決まっていない状態です。
「仕様が固まってから決めよう」と後回しにすると、障害発生時に、その場で連絡経路と判断者を決めることになります。
運用が一気に重くなる落とし穴7つチェックリスト
ここからは、受けた後に苦しくなりやすい条件を7つに絞ります。
判断の基準は、機能の難しさではなく、事故時の一次対応と判断者が決まっているかです。
読んでいてYesが増えるほど、運用設計と責任分界を先に固めないと詰みやすい案件だと捉えてください。
落とし穴1：アラートは来ているのに一次対応する人が決まっていない
よくある状態
- 通知先が個人メールや個人Slack
- 重要度の基準がない
- 夜間・休日の扱いがない
- 通知が多くノイズになっている
起きること
- 初動が遅れる
- 誰が判断するかで止まる
- ディレクターが調整役として固定される
- 「監視の整理」まで制作が抱える空気になる
アラートが鳴っているのに動けない状態は、運用の空白が露呈しているサインです。
鳴った後に体制を作るのではなく、鳴ったときに誰が一次対応し、どこへエスカレーションするかを先に決めます。
落とし穴2：管理画面に入れず調査が始められない（権限・MFA・名義が不明）
よくある状態
- 管理画面URLが不明
- 共有アカウント運用
- MFA（多要素認証）が個人端末に紐づいている
- 権限が足りない、権限付与の手順がない
- 契約名義が制作か顧客か曖昧
起きること
- 復旧ではなく、探索・連絡・権限付与待ちに時間を費やす
- 一次報告が遅れ、関係者の焦りが増えて判断が荒くなる
障害対応の最初の詰まりは、技術ではなくログインできないことです。
ここが未整備だと、復旧検討の前に「入れる状態にする」作業が発生します。
落とし穴3：原因はどこまで追うのかが曖昧で調査が終わらない（外部連携の境界）
よくある状態
- 外部APIエラー時の切り分け担当が未定
- 連携先の窓口が不明
- 連携先の稼働状況を確認する手段がない
- 連携失敗時の縮退（機能を制限して動かすこと）がない
起きること
- 制作が原因究明と説明責任を背負う
- 連携先待ちで停滞するが、顧客からは制作が遅いように見える
- 例外対応が積み上がり、運用の暗黙知が増える
外部連携の障害でも、ユーザーや顧客の問い合わせ窓口は自社側になるため、説明負荷が発生します。
だからこそ「どこまでが制作の責任か」「どこから先は連携先対応か」を文章にしておく必要があります。
落とし穴4：外部の遅延が連鎖して全体が重くなる（タイムアウト・カスケード）
よくある状態
- 下流遅延に対するタイムアウト設計（一定時間待って諦める設定）が曖昧
- リトライ方針（失敗時に再試行する基準）が曖昧
- 障害時の縮退運転がない
- 監視が「アプリ単体」しか見ていない
起きること
- 影響範囲の切り分けが難しくなる
- 連携先が遅いだけでもサービス全体が巻き込まれる
- 顧客への説明回数が増え、調整工数が増える
少しの遅延が大きな障害に見えると、影響範囲の説明と調整が増えます。
対策は、縮退の方針と、異常の判断指標を先に決めることです。
落とし穴5：画面は動くのに裏側の処理が止まる（バッチ・ジョブ・非同期）
よくある状態
- ジョブ監視がない
- 再実行手順がない
- ログの場所が不明
- 失敗時の補正方針がない
- ジョブの責任者がいない
起きること
- 復旧＋データ補正＋説明がセットで発生する
- 発見が遅れて影響が広がる
- 影響特定が難しく、報告が長期化する
SaaS/会員サイト/ECは、データの整合性が価値です。だから裏側が止まると、復旧だけで終わらず「整合性を戻す」作業が発生します。
落とし穴6：アクセス急増で遅い・落ちるのに限界値と対応方針がない（性能）
よくある状態
- 限界値が未測定
- スケール方針（負荷に応じてサーバーを増やす基準）が未定
- キャッシュ前提が曖昧
- 一次対応の手段が決まっていない
- 何を守るかの優先順位がない
起きること
- 顧客の要望と技術的に可能な一次対応の間で判断を迫られる
- その場しのぎの対応が増え、恒久対応が先送りになる
- 事故のたびに、誰が判断するかの調整が発生する
性能は実装だけでなく、計測・限界値の合意・一次対応まで含めた運用課題です。
落ちたときに何を制限し、誰が判断し、どの手段を使うかを先に決めておく必要があります。
落とし穴7：脆弱性対応や設定変更で誰がいつ何を変えるか決まっていない（変更責任）
よくある状態
- 緊急変更の承認ルートがない
- 実行者が不明
- 変更履歴の管理が弱い
- ロールバック判断者が不明
- パッチ適用の頻度と範囲が曖昧
起きること
- 事故時に履歴が追えず、再発防止ができない
- 変更が怖くなり、必要な改善が止まる
- 結果として「運用停止」か「再発」の二択になりやすい
変更は避けられません。
変更の責任が曖昧な案件は、例外対応が増えて手順が整備されず、次回も同じ確認が必要になります。
例外対応が積み重なると、次の障害で初動と説明の負荷が一気に増えます。
落とし穴を踏まないために最初に決める責任分界5つの型
落とし穴の多くは「責任分界が曖昧なまま始めた」ことが原因です。
ここでは、最初に決めるべき型を5つにまとめます。ポイントは、誰が・いつ・何をするかを1行で書ける粒度に落とすことです。
型1：通知──誰が最初に気づき、どこに通知が届くか
- 一次受けは誰か
- 通知先はどこか（メール・Slackなど）
- 夜間・休日はどうするか（当番制・外部委託・営業時間内のみなど）
- 重要度とエスカレーション条件
- 連絡がつかない場合の代替ルート
宛先が決まっていない通知は、障害対応よりも前に体制の不備として不安を増やします。
型2：初動──何分でどこまでやるか（暫定復旧・切り戻し・告知）
- 何分以内に一次判断するか
- 暫定復旧で許容する手段（縮退、制限、停止）
- 切り戻し判断者
- 告知の担当とテンプレ
- 復旧完了の定義（どの状態をもって復旧とするか）
初動で重要なのは、完璧な対応ではなく、迷わず動けることです。
型3：調査──原因究明の終点をどこに置くか（外部連携・アプリ・DB・インフラ）
- 外部連携・アプリ・DB・インフラの担当境界
- 制作が追う範囲の明文化
- ログとメトリクスの参照権限
- 途中経過の共有頻度と形式
- 連携先障害時の確認手順と窓口
制作会社が一番巻き込まれやすい部分です。
どこまで追うかを決めないと、追うこと自体が作業になります。
型4：変更──本番を誰が変え、どう戻すか（承認・手順・ロールバック）
- 実行者と承認者
- 変更手順の保管場所
- ロールバック手段と判断者
- 変更時の連絡ルール
- 緊急変更の例外ルール
変更の責任が曖昧だと、承認と実行の判断が遅れ、必要な改善が進まなくなります。
改善が止まると、例外対応が増えて手順が整備されず、次回も同じ確認が必要になります。
型5：報告──誰が誰に何を伝えるか（一次報告・技術情報の取りまとめ）
- 顧客一次報告の担当
- 技術情報の取りまとめ担当
- エスカレーション先
- 報告の粒度と頻度
- 事後報告の期限とフォーマット
報告は、丁寧さよりも一貫性が重要です。
誰が報告するかが固定されるだけで、伝達事故が減ります。
責任分界を運用に落とし込む──運用境界の棚卸し項目
責任分界を決めたら、次は「手元で埋められる運用情報」を棚卸しします。
ここが空欄だと、事故のたびに探し物と連絡待ちが発生し、初動が止まります。
既存保守がいるかどうかに関係なく、制作側が最低限把握しておくべき情報を作っておくのがポイントです。
棚卸し項目1：監視と通知（宛先・時間帯・重要度）
- 監視対象（稼働状況・応答速度・エラー発生率・外部監視・定期処理の成否）
- 宛先と時間帯
- 重要度とエスカレーション条件
- 最初に見るダッシュボードやURL
- 通知が鳴ったときの一次確認手順
棚卸し項目2：権限とアカウント（管理画面URL・名義・MFA・緊急時）
- 管理画面URLとログイン方式
- 名義と管理者
- MFA方式と緊急時代替
- 権限付与の手順と承認者
- パスワード管理の置き場と更新ルール
- 退職や担当交代時の引き継ぎルール
棚卸し項目3：初動と復旧（暫定対応メニュー・判断者・切り戻し）
- 暫定対応メニュー（縮退、制限、停止）
- 判断者と連絡順序
- 切り戻し手順と所要時間
- 告知テンプレ
- 復旧完了の定義
- 重大障害時の判断基準（例：何分で切り戻すか）
棚卸し項目4：調査と切り分け（外部連携一覧・窓口・ログ・終点）
- 外部連携一覧（決済・配送・認証・MAなど）
- 連携先の障害確認と窓口
- ログの場所と参照権限
- 制作側の調査終点と引き継ぎ先
- 影響範囲の出し方（期間・件数・対象）
- 連携先障害時の顧客説明テンプレ（簡易でも良い）
棚卸し項目5：変更とリリース（実行者・承認・手順・ロールバック）
- 本番反映手順と担当
- 承認者と連絡ルール
- 変更履歴の管理場所
- ロールバック手順と判断基準
- 緊急変更の例外ルール
- 設定変更で影響が出やすい箇所の一覧（CDN・WAF・証明書など）
棚卸し項目6：連絡と報告（関係者・連絡手段・一次報告テンプレ）
- 関係者リスト（顧客・制作・保守・連携先）
- 連絡手段と優先順位
- 一次報告テンプレと更新頻度
- 事後報告のフォーマットと期限
- 連絡がつかないときの代替ルート
- 社内共有用の最低限メモ（誰が何をしているか）
この棚卸しが埋まっていれば、初動で「誰が一次対応するか」「暫定対応を何にするか」をすぐ判断できます。
空欄が多いほど、必要情報の探索に時間を取られる運用になります。
まとめ：受ける・受けないより先に線を引けるかで判断する
落とし穴が多いほど運用設計なしの受託は危険度が上がる
落とし穴があること自体は珍しくありません。問題は、落とし穴が複数あるのに、責任分界を決めないまま受けてしまうことです。
- Yesが2〜3：責任分界を合意してから進める
- Yesが4以上：運用設計と体制がない受託は危険域
- Yesが多いほど「受けるなら責任分界を合意できるか」が判断軸になる
受ける／受けないの結論より先に、責任分界を合意できるかを確認すると、範囲外対応を引き受けにくくなります。
制作がやるべきは、全部を背負うことではなく、背負う範囲を決めることです。
既存保守会社に確認する前に責任範囲を棚卸しして相談につなげる
既存保守会社がいる場合、一次確認が既存に向くのは自然な流れです。
ただ、確認前に制作側で整理できることがあります。
- 背負いたくない責任はどこか
- 未確定は何か
- 棚卸しの空欄はどこか
- 既存保守に何を聞けば一気に埋まるか
ここが整理できていると、既存保守会社との会話も速くなり、相談の質も上がります。
制作側の不安が論点に変わり、判断材料として扱えるようになります。
コーポレートサイトをクラウドでセキュアに
サーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
