ブログ

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

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

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

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

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

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

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

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

システム移行の並行運用で実際に何が大変なのか。旧システムでデータが増え続け開発も続くというコスト、並行運用を避ける判断、そして終了をどう判断するか（バッチ処理の落とし穴）を書きました。

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

システム開発の打ち合わせの実際。リモート中心・2週間に1度という頻度の理由、話が進まない打ち合わせに共通する準備不足、そして社内の決裁者との温度差に開発会社をどう使えるかを書きました。

システム開発の納期は機能数に比例します。短納期のときにまずやるフェーズ分けの考え方と、それでも急いだ場合に削られるのはテスト期間だという実際を、開発会社の視点から正直に書きました。