ブログ

検収（受け入れテスト）で実際に揉めた実例と、検収後に見つかった不具合をFUNBREWがどう扱っているかを、開発会社の側から書きました。原因は変更履歴を残していなかったことにもありました。

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

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

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

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

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

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

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

システム開発の検収期間は一般的に1〜4週間が相場ですが、規模や複雑さによって大きく異なります。この記事では、検収期間の適切な設定方法、契約書への記載方法、期間延長が起きる原因と対処法、トラブルを防ぐ実践的なポイントを発注者向けに解説します。

システム開発の検収（受け入れテスト）で使えるカテゴリ別チェックリストと検収書テンプレートを公開。機能テスト・非機能テスト・UI/UX・ドキュメントの4カテゴリで抜け漏れなく確認でき、合否判定基準の決め方やよくあるトラブル対処法まで徹底解説します。

システム移行の標準スケジュールは当初見積もりの1.3〜1.5倍が目安。計画・データ移行・並行運用・テスト・教育の5フェーズで注意すべきポイントとチェックリストを解説します。

システム開発において、検収（けんしゅう）は「発注者が成果物を確認し、合格・不合格を判定するプロセス」です。検収が完了すると、受注者は代金を請求でき、発注者は成果物を正式に受け取ったことになります。 つまり検収は、お金と責任が動く「最重要関門」です。