結論から書くと、「保守だけお願いしたい」が断られやすいのは、依頼そのものが悪いからではありません。受ける側が、中身を見ないと責任の範囲もリスクも費用も分からない からです。そのため、いきなり保守契約を打診するより、情報を揃えて「まず調査だけ」と依頼するほうが、話が進みやすくなります。
以下、受託する側がどこを見ているのかを説明し、引き受けてもらいやすい依頼の出し方をまとめます。
断られる主な理由
中身が分からないまま責任を負えない
他社が作ったシステムは、開けてみるまで状態が分かりません。設計や書き方、テストの有無、本番で手が加えられていないかなど、確認すべき点が多くあります。この状態で「今後の不具合はすべて対応してください」と言われても、受ける側は判断できません。
保守を引き受けた後に障害が起きると、それが以前からの問題でも、対応の責任を問われることがあります。だから「何を引き受け、何を引き受けないか」を決められない依頼は、断るのが合理的になります。
調査の費用が見えない
他社のシステムを把握するには、相応の時間がかかります。金額の小さい月額保守を前提にすると、この時間をまかなえません。「月に数時間だけ見てほしい」という希望と、最初に必要な調査の量が釣り合わないのです。
技術が古く、対応できる人が限られる
サポートが切れた PHP や、更新が止まったフレームワークは、経験者が多くありません。新しい技術を中心に事業をしている会社は、経験者を割り当てられないことがあります。開発会社にとっても、古い環境を維持するための検証環境や知識の負担は小さくありません。
新規開発のほうが事業として組み立てやすい
開発会社の多くは、新規開発を中心に要員を計画しています。保守は発生のタイミングが読めず、緊急の対応も入るため、要員の計画を立てにくい仕事です。これは依頼する側の問題ではありませんが、断られる理由を理解しておくと、依頼先を探すときの判断材料になります。規模の大きな会社で断られても、保守を得意とする会社や個人の開発者なら受けられることがあります。
緊急対応への期待が読めない
「止まったらすぐ直してほしい」という期待は当然ですが、夜間や休日も含めて即時に対応するには、複数の人員を常に確保しておく必要があります。少人数の開発会社や個人の開発者には約束しにくい条件です。実際にどのくらいの速さが必要なのかを伝えると、対応できる相手が見つかりやすくなります。翌営業日で問題ない業務も少なくありません。
権利や契約に不安がある
ソースコードの権利が誰にあるのか、前の開発会社との契約が終わっているのかがはっきりしないと、受ける側は手を出しにくくなります。特に、前の会社と揉めている状況で引き受けるのは慎重になります。
依頼の前に揃えると話が早い情報
受ける側が判断できる材料を先に出すと、返事が早くなり、断られにくくなります。全部揃っていなくても構いません。「分からない」と書いてあるだけでも役立ちます。
| 項目 | 伝える内容 |
|---|---|
| システムの用途 | 何に使っているか、誰が使っているか、利用者数のおおよそ |
| 止まったときの影響 | どの業務がどのくらい困るか |
| 技術 | PHP やフレームワークのバージョン。分からなければ「不明」 |
| 環境 | サーバーの種類、契約者、管理画面に入れるか |
| ソースコード | 手元にあるか、リポジトリがあるか、最新かどうか |
| 資料 | 仕様書、手順書、構成図の有無 |
| 経緯 | 開発した会社、やめた理由、前任者と連絡が取れるか |
| 困っていること | 今起きている問題、やりたい変更 |
| 希望する関わり方 | 不具合対応、バージョンアップ、機能追加、問い合わせ窓口など |
| 時期と予算感 | 期限の有無とその理由、予算の目安 |
特に大事なのは、止まったときの影響 と 希望する関わり方 です。「保守」という言葉は人によって意味が違います。障害時に即時対応してほしいのか、月に数回の修正を頼みたいのか、サーバーの管理まで任せたいのかで、対応できる会社も費用も大きく変わります。
依頼文の例
最初の問い合わせは、次のような内容で十分です。
社内の受注管理に使っている PHP のシステムについて、
保守先を探しています。
・開発会社が保守を終了し、社内に分かる者がいません
・PHP のバージョンは不明、ソースコードはサーバー上にあります
・仕様書はなく、利用者は社内の十数名です
・止まると受注処理が手作業になり、業務に大きく影響します
・現在の不具合はありませんが、サーバー移転を求められています
まず現状の調査をお願いできるか、ご相談させてください。
可能であれば、調査の範囲と費用の目安を伺いたいです。
ポイントは最後の2行です。いきなり保守契約を求めず、調査から入る と書いてあれば、受ける側は検討しやすくなります。
調査から段階的に頼む
保守を受けてもらいやすい進め方は、次の3段階です。依頼する側にとっても、相手の実力と相性を確かめてから続きを決められる利点があります。
- 調査を依頼する。 範囲と成果物を決めた単発の仕事にします。結果として、構成とリスク、対応の優先順位が分かります。
- 小さな改修を依頼する。 優先度の高いものから1件頼みます。やり取りの速さや説明の分かりやすさなどを確認できます。
- 継続の保守を契約する。 状態が分かったうえで、範囲と条件を決めます。
調査の結果が手元に残ることも重要です。仮にその会社と進めないことになっても、次の相手に渡せます。
依頼先の探し方と、断られたときの聞き方
依頼先は、「保守」「引継ぎ」「他社開発のシステムに対応」と明記しているところから探すと効率的です。新規開発を中心とする会社に当たるより、話が早く進みます。作った会社から別の会社を紹介してもらえることもあるので、関係が悪くなければ聞いてみる価値があります。
断られた場合は、理由を一言だけ聞いてみてください。「技術が対応外」「今は人手が足りない」「情報が足りず判断できない」のどれかによって、次の動きが変わるからです。情報が足りないという理由なら、調査のご依頼に切り替えると、受けてもらえる可能性があります。
複数の相手に相談するときは、同じ情報を渡します。条件が揃っていないと、返事を比べられないからです。価格だけでなく、調査の進め方や、分からないことを分からないと言ってくれるかどうかも見てください。保守は長い付き合いになるので、説明の分かりやすさは重要な判断材料です。
契約前に決めておくこと
保守の範囲があいまいだと、後でトラブルになります。契約の前に次の点を確認します。
- 対応する範囲: 不具合の修正、問い合わせ、サーバー管理、バージョンアップ、機能追加のどれを含むか
- 含まないもの: 以前からの不具合の扱い、脆弱性診断、データの修正作業など
- 対応の時間と速さ: 受付時間、緊急時の連絡方法、どこまでの対応を約束するか。即時の対応を約束できない相手もいます
- 費用の考え方: 月額に含む作業量、超えた分の扱い
- 権利と機密: ソースコードの権利の確認、秘密保持契約
- やめるときの扱い: ソースコードやアカウント、資料の引渡し
ソースコードの権利は、前の開発会社との契約書を確認します。IPA の情報システム・モデル取引・契約書は、保守運用を含む取引の考え方が公開されており、契約の確認項目を考えるときの参考になります。個別の判断が必要な場合は、法律の専門家に相談してください。
自社でも、保守だけの相談を、まず調査から始めて、その後に継続の保守につながった例があります。
h-system でできること
h-system では、他社や前任者が作った PHP・Laravel システムの保守と引継ぎを、窓口から調査、実装まで開発者本人がお引き受けしています。資料がない状態からでも、調査だけのご依頼からでも構いません。一人で対応しているため即日の対応はお約束していませんが、対応できる範囲と進め方は事前にはっきりお伝えします。秘密保持契約はご相談の前にも締結できます。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。範囲と費用は着手前にご案内します。