ブログ

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

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

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

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

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

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

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

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

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

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

うまくいった開発案件に例外なく共通していたのは、発注側と開発側の関係性でした。なぜ関係性が仕事の中身を変えるのか、発注側から何をすればその関係が立ち上がるのかを開発会社の視点で書きました。

システム開発の相談をお断りするのはどういう場合か。10万円規模だと準備で予算が尽きるという構造と、要件の詳細が出せないと概算しか出せない理由、そして断られないために発注側ができることを書きました。