ブログ

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

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

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

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

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

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

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

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

1つのシステムに複数の開発会社が関わる状態で、責任の切り分けをどうしているか。境界で問題が起きたとき各社が線を引くと発注側が間に立たされるという構造と、発注側が用意できることを書きました。

システム開発の見積もりが実際どう作られているか。過去の実工数から積む方法、見積もりに無い機能開発で利益が減る典型、そして工数が余りそうなときに機能改善を提案している理由を書きました。

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

相見積もりで値下げを受け入れた結果、開発会社側で何が起きたのか。工数が苦しくなり最上の提案ができなかったという自社の経験から、発注側が価格差をどう見ればよいかを書きました。