ブログ

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

システム開発で納品後に「思っていたのと違う」と言われないために何をしているか。定期的に進捗を見せる意味と、それでも起きるズレの処理（追加見積もりか、他機能を削るか）を実務から書きました。

システム開発会社が自分たちの現場でAIをどこまで使っているか。引き継ぎ調査での実際の使い方、安くなる工程とならない工程の線引き、品質と責任の担保の仕方を、発注側の判断材料として書きました。

数万円〜30万円規模の開発依頼で実際に何を取り交わしているのか。契約書が無くても揉めなかった条件と、食い違いが起きる本当の原因である「開発の範囲」について、開発会社側の実務から書きました。

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

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

他社が作ったシステムの引き継ぎで「作り直した方が早い」と言われる理由を、開発会社がサーバーとコードの何を見て判断しているかに沿って解説します。直して使えるシステムの条件と、発注側が確保しておくべきものも整理します。

条件を変えた見積もりを何本も依頼すると、開発会社は無償で要件定義を進めることになります。見積もりの精度がどう決まるのか、詰めすぎた見積もりが発注側にどう跳ね返るのかを解説します。

ベンダーから保守終了を通告されたとき、手元にソースコードがなければ引き継ぎ先を見つけても改修はできません。引き継ぎを断念して刷新に至った実例をもとに、判断の分かれ目を解説します。

保守費の値上げを提示されたとき、値切る前に確認したいのは「作業の中身が変わっていないか」です。値上げを提示する側の内情と、実際に値上げを断った案件で保守がどう縮小したかを解説します。

テスト環境が無いシステムの引き継ぎでは、最初にやることが修正ではなく「どこを触ると壊れるか」の特定になります。2025年に対応した医療系システムの実例をもとに、環境整備に半年かかった理由を解説します。

2026年1月に施行された「取適法」（下請法改正）は、システム保守・開発の委託契約も対象です。価格交渉拒否の禁止など新ルールと、発注担当者が契約書で確認すべきポイントを解説します。