工程ごとに、費用と受け取るものを対にする
「開発一式」だけでは、要件整理や移行が含まれるか判断できません。自社の担当作業も併記し、同じ分担・対象範囲の提案として比べます。
| 工程 | 受け取る証拠 | 費用を変える条件 |
|---|---|---|
| 現状調査・要件定義 | 業務図、機能一覧、対象外一覧 | 既存仕様の調査、関係部署の数 |
| 設計・実装 | 画面・権限設計、動く機能、ソースの引渡し条件 | 役割数、例外処理、対応端末 |
| 外部連携・移行 | 連携結果、移行対象と件数の照合 | API制約、データ整形、重複の処理 |
| 試験・受入れ | 試験結果、不具合一覧、受入れ条件 | 試験データ、確認担当、再試験範囲 |
| 運用・保守 | 手順書、監視・復旧の分担、引継ぎ資料 | 受付時間、復旧支援、クラウド利用量 |
未確定の見積もりは「幅」と「前提」を残す
まだ画面や連携仕様が決まっていない場合、最初の金額は同じ確度とは限りません。確定額・概算・別見積もりを区別し、変更時の合意方法を先に確認します。
- 概算の前提：利用者、機能、データ量、外部連携を一覧にする。
- 最初の到達点：要件一覧と見積もり根拠を受け取り、開発へ進むか判断する。
- 追加の扱い：新機能と不具合修正を分け、費用・納期への影響を作業前に確認する。
- 比較期間：初期費用だけでなく、同じ期間の保守・クラウド・外部サービス費用を足す。
段階を分ければ必ず安くなるわけではありません。調査自体にも費用がかかります。現行システムの調査や変更管理の考え方は、末尾のIPA資料も参考になります。
「完成した」の判断を、契約前に具体化する
画面が表示されたことと、業務で使えることは別です。自社で再現できる確認項目を提案に含め、誰がいつ確認するかまで決めます。
| 確認したいこと | 用意する証拠 | 提案先への質問 |
|---|---|---|
| 権限が分かれる | 閲覧担当・編集担当の操作結果 | 他部署の情報や管理操作にアクセスできないか？ |
| 移行が正しい | 対象件数・金額・欠損の照合表 | 合わないデータは誰が直し、再移行するか？ |
| 障害から戻せる | バックアップと復元確認の記録 | 復旧中の業務と連絡窓口はどうするか？ |
| 担当変更に耐える | 設定・アカウント・操作手順の引継ぎ | 保守会社を変更しても運用を続けられるか？ |
状況別の選び方
| 今の状況 | 比較する提案 | 先に確認すること |
|---|---|---|
| 業務・機能が未確定 | 調査・要件定義を先に依頼 | 次段階へ進まない場合も受け取れる成果物 |
| 必要機能を説明できる | 同じ要件一覧で開発を見積もる | 仕様追加と不具合修正の境界 |
短い納期でも、データ移行や試験運用が抜けていれば同条件ではありません。連携先の制約と社内確認日を工程へ入れます。
追加の質問
要件定義・実装・移行・試験・保守の費用と成果物を分け、未確定部分の金額が変わる条件を示してください。