ブログ

サポートが終了したLaravel 6系のシステムをFUNBREWが実際に引き継ぎ、バージョンアップまで進めた実例。多かった修正、いちばんの懸念だった動作確認、旧WordPressのプラグインの問題を開発会社の側から書きました。

AI（Claude）で作り直したシステムの保守だけを頼まれた実際の相談2件で、FUNBREWが見積もりの前に確認したこと、提案した月額5万円からの保守の形、AIのコードの印象を開発会社の側から書きました。

引き継いだシステムで実際に見つかるセキュリティ上の問題と、その伝え方・費用の扱い。サーバーやドメインの引き受けで手間取る点まで、開発会社側の実際を書いています。

障害も改修依頼もなかった月に、保守で実際に何をしているか。バックアップとライブラリ更新、余った稼働時間を小さな改修に充てる運用まで、受けている側の実態を書いています。

保守中に障害が起きたとき、開発会社側は実際にどう動いているか。連絡経路、夜間・休日の対応、応急対応と恒久対応の分け方、稼働時間外の扱いを、少人数の会社の実態としてそのまま書いています。

古いフレームワークで作られたサービスを引き継いだ案件で、調査を省いたために見積もりが甘くなり難航した実例。難航の兆候、増員できないままスケジュールが伸びた経緯、顧客との関係に残ったものを書いています。

他社から保守を引き継いだ直後、開発会社が最初にやるのは調査結果のドキュメント化と検証環境の構築です。修正より先に環境を作る理由と、アプリを触らない保守なら開発会社でなくてよい理由を書きました。

システムの保守契約が終わる理由と、その後に起きること。予算で切られる構造、開発会社側の事情、そして最低限の保守ほど緊急時の対応に時間がかかるという実態を開発会社側から書きました。

予算の限られた中小企業のシステムでセキュリティの線をどこに引くか。必ず抑えている対策、予算次第で外れるWAFや脆弱性診断、引き継ぎで見つかる危ない状態、そして最低限死守してほしいことを書きました。

他社システムの引き継ぎ相談で顧客から実際に出てくる資料はどんな状態か。役に立つ順、意外と役に立たないもの、資料が何も無いときの手がかりと社内で聞くべき相手を、開発会社側の実務からまとめました。

他社システムの引き継ぎ・刷新をやり切ったあと、顧客側で何が変わるか。協力してもらえて助かったこと、想定より時間がかかった部分、最初に決めておいてよかったことを実体験から解説します。

他社が作ったシステムの保守・引き継ぎは、必ず引き受けてもらえるとは限りません。お断りになりやすいケースと、引き受けてもらいやすくするために発注側ができることを解説します。