判断の出発点
予算の出発点は画面数ではなく、利用者が完了させる仕事と例外処理です。権限、既存データの取り込み、外部連携、失敗時の復旧まで含めて考えます。同じ五画面でも必要な作業量は大きく異なります。
具体例で考える
架空の仕入先ポータルを例にします。調査と設計に8人日、主要な業務フローに15人日、連携に6人日、検証に5人日、公開準備に3人日なら合計37人日です。見積書や市場相場ではなく、計算を説明するための仮定です。合意した単価を掛け、運用と保守は別に計上します。
見積もりを責任の一覧にする
仕事ごとに約束する結果、前提、担当者、受入の証拠を分けます。「連携」だけでは広すぎます。承認した注文が一回だけ届き、外部番号が返り、失敗時にも状態が見えると書きます。テストアカウントの提供者も記します。安い見積もりが別の人の無償作業を暗黙に頼らないよう、同じ責任で各案を比較します。
例外の費用も意識して確認する
商品が取り下げられ、承認後に住所が変わり、仕入先の返答も遅れる注文を考えます。どこまで費用に含み、どの前提が崩れたでしょうか。提案全体を白紙にせず、該当する項目を見直します。証拠が足りなければ、判断につながる小さな調査を決めます。予備費は約束の中の不確実さに備えるもので、新しい約束の追加は範囲変更です。
公開費用と持ち続ける責任を分ける
公開後もバックアップ確認、更新、転送失敗の調査、運用相談があります。事業者、開発元、別の提供者の誰が行い、どう引き継ぐかを決めます。支援依頼がいつ追加開発になるかも確認します。受入例、対象外、外部料金、アカウント所有者、使わなかった予備費の扱いを見てから合意してください。将来の全請求を当てるのでなく、後の判断を説明できる約束を作ります。
選択肢とその負担
不明点が残る項目には幅を持たせます。仕様書のあるAPIと内容不明の出力ファイルでは見積もりの確度が違います。先行調査で不明点を減らす方法も、受入条件を固めて固定価格にする方法もあります。
見落としやすい点
データ修正を開発費に隠したり、余った時間だけでテストしたりしないことが大切です。対象外と未決定事項を書き、予備費は未取得のアクセス権など具体的なリスクと結び付けます。
依頼前に確認すること
サンプルデータを出す人、権限を承認する人、取引完了の判定方法を確認してください。その情報を個別開発の相談に持ち込み、どの前提が変われば費用も変わるか説明を求めます。