ブログ

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

システム開発の支払いを着手・中間・完了の3回に分ける理由と、開発会社が工数を先に持ち出すという構造。そして途中で止まった案件がほとんど再開されないという実際を、開発会社側から書きました。

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

予算の限られた中小企業のシステムでセキュリティの線をどこに引くか。必ず抑えている対策、予算次第で外れるWAFや脆弱性診断、引き継ぎで見つかる危ない状態、そして最低限死守してほしいことを書きました。

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

他社システムの引き継ぎ相談で顧客から実際に出てくる資料はどんな状態か。役に立つ順、意外と役に立たないもの、資料が何も無いときの手がかりと社内で聞くべき相手を、開発会社側の実務からまとめました。

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

開発が始まってから要望が増えたとき、どこから追加費用になるのかを、開発会社が実際に見ている判断軸から解説します。画面と機能リストという2つの基準と、予算が小さいほど融通が利かなくなる理由をまとめました。

システム開発の相談メールや問い合わせで何を書けば話が早いのかを、開発会社が実際に確認している予算・納期・機能の3点から解説します。予算を伝えた方がよい理由と、決まっていない段階での相談の仕方もまとめました。

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

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

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