保守会社の品質に不安がある時の見直し手順

問い合わせへの返信が数日返ってこない、障害が起きても原因説明がなくその場しのぎの対応で終わる、こちらから頼んだことしかやらず改善提案が一切出てこない——保守を委託している会社に対して、こうした不満を抱えながらも「言語化できないモヤモヤ」のまま契約を続けている発注者は多くいます。

不満はあるが、それが「切り替えるべき水準の問題」なのか「どんな保守会社でも多かれ少なかれあること」なのか、判断がつかない。この記事では、保守品質を感情ではなく事実で評価するための観点と、継続と切り替えの判断基準を整理します。

「なんとなく不安」を放置するコスト

保守品質への不満は、多くの場合すぐには事業に致命傷を与えません。だからこそ後回しにされがちですが、放置コストは静かに積み上がります。

• 障害対応が遅れるたびに、ユーザー離脱や信頼の毀損が起きている
• 改善提案が出ないまま、競合が先に機能を出してくる
• 「今の会社に聞かないと分からない」状態が続き、ブラックボックス化がさらに進む

「まだ致命的な事故は起きていないから大丈夫」ではなく、次の障害が事業インパクトのある規模で起きたときに今の体制で耐えられるか、を基準に考えるべきです。

品質を客観評価する5つの観点

感情論を避けるために、次の5つを事実ベースでチェックします。いずれも「過去3〜6ヶ月の実績」を根拠にするのがポイントです。印象ではなく記録を見ます。

1. レスポンスタイム

• 問い合わせ（Slack・メール・チケット）への一次返信までの時間は何時間〜何日か
• 契約書やSLAに応答時間の合意はあるか、あるなら守られているか
• 緊急度が高い連絡と通常の連絡が同じ速度でしか返ってこないなら、優先順位付けの仕組みがない可能性が高い

目安として、営業時間内の一次返信が24時間を超えて常態化しているなら要注意です。返信が遅いこと自体より、「返信が遅い理由の説明がない」ことのほうが問題の本質です。

2. 障害対応の質

• 障害発生から検知までの時間、検知から復旧までの時間、復旧から原因説明までの時間、それぞれを直近数件で振り返る
• 障害報告が「直りました」で終わるか、根本原因と再発防止策まで含むか
• 同じ種類の障害が繰り返し起きていないか（再発は「その場しのぎ」の対応をしている証拠）

障害対応レポート（ポストモーテム）が一度も出てきたことがないなら、それ自体が品質シグナルです。原因を追わない保守は、同じ火種を燃やし続けます。

3. 改善提案の有無

• 直近半年で、依頼していないのに向こうから出てきた改善提案・リスク指摘は何件あるか
• 「言われたことだけやる」保守と「プロダクトの状態を見て先回りする」保守は、契約金額が同じでも提供価値が大きく違う
• 依存ライブラリの脆弱性、パフォーマンス劣化の兆候、コストの無駄（AWS課金の異常など）を能動的に報告してくるか

保守契約は本来「壊れたら直す」だけでなく「壊れる前に気づく」ことに価値があります。これがゼロなら、実質的には作業員を時給で雇っているのと変わりません。

4. ドキュメントの整備状況

• 変更を加えるたびに、その内容・理由が記録として残っているか（コミットメッセージ、変更履歴、構成図の更新）
• 「なぜこの実装にしたか」を今の担当者以外が答えられるか
• あなたが今この保守会社を切ったら、次の会社が引き継げる状態か

ドキュメントが薄い保守ほど、担当者個人への依存度が高くなります。これは担当者が退職・離脱した瞬間にリスクが顕在化する、時限爆弾のような状態です。

5. 見積もりの透明性

• 追加開発や改修の見積もりに、工数の内訳（設計・実装・テスト・レビュー）が示されるか、それとも一式いくらの丸投げ数字か
• 同程度の作業で見積もり額が案件ごとに大きく揺れていないか
• 「なぜその工数か」を聞いたときに、納得のいく説明が返ってくるか

内訳のない見積もりが続くのは、必ずしも悪意とは限りませんが、少なくとも説明責任を果たす体制がないことは分かります。

継続か切り替えかの判断基準

5つの観点を洗い出したら、次の軸で判断します。

継続を検討してよいケース

• 5観点のうち大半は及第点で、特定の担当者個人の問題（相性・スキル不足）に起因している → 担当者交代の相談で解決する可能性がある
• レスポンスの遅さなど改善余地はあるが、障害対応とドキュメントは最低限機能している
• 契約金額と提供価値のバランスが著しく崩れていない

切り替えを検討すべきケース

• 障害の再発防止策が一度も提示されず、同じ障害を繰り返している
• ドキュメントがなく、かつ担当者が固定の1〜2名に依存している（属人化リスクが高い）
• 改善提案がゼロで、かつこちらからの指摘にも防御的な反応しか返ってこない
• 見積もりの根拠を尋ねても納得のいく説明が得られない状態が続いている

1つでも切り替え条件に強く当てはまる、かつ次の重大障害が事業に与える影響が大きいなら、様子見ではなく具体的な行動に移すタイミングです。

切り替える場合に準備すべきこと

切り替えを決めたら、円満な移管より先に「移管できる状態か」の確認が最優先です。

• ソースコードのリポジトリ、サーバー、ドメイン、SaaSアカウントの所有権が発注者側にあるか（開発会社名義になっていないか）
• 本番環境の構成・環境変数・認証情報が引き継ぎ可能な形で残っているか
• 移行期間中、旧保守会社と新チームが並走できる契約条件を確保できるか

このあたりの具体的な手順とチェックリストは「開発会社を変更するときの引き継ぎチェックリスト」にまとめています。切り替えを決める前に、まずこちらで移管の実現可能性を確認しておくことをおすすめします。

第三者に現状診断してもらう価値

判断に迷う最大の理由は、比較対象がないことです。今の保守会社しか知らないと、「これが普通なのか、それとも異常なのか」の基準を持てません。

第三者による現状診断を挟むと、次のことが分かります。

• 技術的負債やセキュリティリスクが、実際どの程度深刻か（印象ではなく指標で）
• 今の保守費用が、プロダクトの状態に対して妥当な水準か
• 「今の会社を切る前に、まず自社で直せること」があるかどうか

診断結果は、今の保守会社との交渉材料にもなります。「ここを改善してほしい」を具体的な指摘として提示できれば、継続のまま関係改善する道も開けます。切り替えるにしても、次の会社への引き継ぎ資料としてそのまま使えます。

まとめ

• 保守品質の不安は感情でなく、レスポンス・障害対応・改善提案・ドキュメント・見積もりの透明性という事実ベースの5観点で評価する
• 障害の再発、属人化、改善提案ゼロ、説明のない見積もりが重なるなら、様子見ではなく切り替え検討に進むべきサイン
• 切り替える場合は所有権と引き継ぎ可能性の確認が先。判断に迷うなら第三者の現状診断を挟むと、交渉材料にも移行資料にもなる

torcheeesでは、既存プロダクトの保守・運用改善を通じて、レスポンス速度・障害対応・改善提案までを含めた保守体制を提供しています。第三者が既存プロダクトを引き継ぐときにまず確認する観点は既存プロダクトの改善、外部チームが最初に見る観点にまとめています。まずは現状の診断から、今の保守が妥当な水準かを客観的に確認することも可能です。継続すべきか切り替えるべきか迷っている段階でも、お問い合わせから状況をお聞かせください。