ブログ

システム移行の計画で最初に決めるのは、一度に何を変えないか。FUNBREWがフレームワーク、サーバーと一段ずつ移行し、各段階をすぐ戻れるセーブポイントにしている理由を、実務の考え方から書きました。

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

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

検収（受け入れテスト）で実際に揉めた実例と、検収後に見つかった不具合をFUNBREWがどう扱っているかを、開発会社の側から書きました。原因は変更履歴を残していなかったことにもありました。

見積もり前の要件定義や現地調査、プロトタイプまで、FUNBREWは無償でやることが多いです。調査を有償にすると「お受けできないのに調査費だけ請求する」形になりかねないから。ただし、どこまでやるかは相談の温度で決めています。

見積もりのあとの立ち消えは珍しくなく、要件定義のあとのキャンセルは1件だけ。契約前だったので動くモックまで作った工数は持ち出しになりました。費用はかかるのか、どう断ればよいかを開発会社側から書きました。

開発の途中で凍結の話が出て、そのまま連絡が来なくなった案件で実際に何が起きたかを整理しました。作業は止めましたが、着手金と中間金の取り決めがあったので未払いは起きず、ソースコードは今も保管し、連絡があれば続きから再開できる状態です。

納品後の保証期間で無償になるのはどこまでか、有償になるのは何かを、実際に「これは有償です」と伝えた依頼の中身から整理しました。保証期間の長さより、機能の範囲と開発以外の作業分担が効きます。

発注側の担当者が交代したとき何が起きるか。定例の差分説明が引き継ぎとして機能した経緯、続いた案件の共通点、終わった案件について開発会社側の視点から書いています。

2名体制の開発会社が実際どう回っているか。情報共有の置き場、途中でもプッシュする運用、打ち合わせへの同席、手順化の理由と、仕組みでは消せない限界まで書いています。

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

データ移行のリハーサルで実際にやっていること。回数、本番データの扱い、メール送信など実行してはいけない処理の代替、手順レビューとしての価値、省いた場合に何が起きるかを書いています。