システム開発の予算上限はどう決める？必須の仕事と後回しを分ける方法

社内の上限と、開発会社の見積もりを分ける

社内の予算上限は、会社が検討する支出の条件です。開発会社の見積もりは、示された作業範囲や前提に対して提供側が出す金額の案です。社内で180万円までと考えていても、同じ仕事を180万円で作れると決まったわけではありません。逆に、210万円の見積もりが届いても、その金額を会社が使うと決まったわけではありません。

架空の卸売会社では、経営者だけで画面名を並べるのではなく、受注担当がどの資料へ何を入力し、誰が注文内容を確認しているかを説明します。例えば「今回、注文の入力と確認を先に検討したい」という案なら、入力した内容を誰が、どの仕事の前に確かめられる状態を目指すのかまで話します。現在の手順や困りごとの記録が、その理由になります。

金額を社内で決める人、支払い条件を確かめる人、業務の必要性を説明する人は、会社によって異なります。発注担当が全てを一人で決める前提にせず、経営者・予算の決定者・経理担当・現場担当のうち、自社では誰が何を確認するかを決めてください。支出時期や他の支出との関係が分からなければ、上限案は未決定のまま、判断に必要な情報を集めます。

現在の入力時間がどれだけ減るか、売上がいくら増えるかが未計測なら、効果を仮の金額で埋めて上限の根拠にしないでください。困っている作業、確認した事実、期待する変化、まだ測っていないことを分ければ、経営者が判断できる情報と不足が見えます。

何の費用を、いつまでの上限にするかを明記する

「予算180万円」だけでは、初期の開発作業だけか、使い始めるまでの移行や確認も含むか、運用を続ける費用まで含むかが分かりません。社内の案と見積もりで対象が違えば、数字が上限以内に見えても、必要な支払いの全体を確認したことにはなりません。

対象にする仕事と費用

開発、初期設定、データ移行、試用・動作確認、利用者への説明など、今回どこまでを同じ上限に含めるかを記録します。必要な作業か、誰が行うか、費用に含まれるかはそれぞれ確認します。

税と金額の表示条件

社内案と見積もりが税込か税抜きかをそろえます。表記が不明な資料は、確認先へ尋ねるまで同条件の金額として確定しません。この記事の数字は「税込・初期費用のみ」と仮定した説明です。

対象期間と支払い時点

初期費用だけの案か、いつまでの支出を含む案かを明記します。分割された支払いがあるなら、その支払時点を会社が負担できるかも経理・決定者へ確認します。金額の合計と支払える時期は別の条件です。

利用・保守などの継続費用

初期費用の外にある利用料、保守や外部サービスの料金を、別の確認項目として残します。金額や対象範囲が未確認なら0円と入力せず、提供会社と社内の確認先を示します。

架空の180万円は、税込・初期費用のみという社内案です。実際の社内決定や発注条件ではありません。税の扱いと、移行・試用・保守などをどの上限に含めるかを社内で確かめ、依頼時にはその決まった条件へ書き直します。社内で「税込と置いた案」があることと、実際の見積もりの税・対象費用を確認できたことを混同しないようにします。

費用の項目そのものを整理したい場合は、システム開発費用の内訳と予算例で、開発・移行・継続費用の読み分けを確認できます。確認した内訳を使い、何を今回の社内上限へ含めるかを決めます。保守の対象や応答条件が分からない場合は、保守費用と作業範囲を比べる記事へ進んで、その条件を確認してください。

必須・後段候補・未判断を、仕事の理由で分ける

画面や機能の名前だけで「必須」を決めると、何ができれば業務を始められるかが曖昧になります。現場の作業を一つずつ挙げ、今回必要と考える理由、後に回した場合の仕事、判断に足りない条件を付けて分けます。区分は社内で検討するためのものです。記事の例が、自社にとっての必須を決定するわけではありません。

• 今回に残したい仕事の案

  架空例では「注文の入力と確認を先に検討」としています。受注担当が扱う注文内容と、確認担当が確かめる内容を具体化し、どの状態になれば今回の目的に届くかを現場と確認します。「入力画面がある」だけで、必要な確認業務までできるとは決めません。

• 後に回せる候補

  「集計画面は後段候補」と記録します。今すぐ作らない場合に、誰がどの資料で集計するか、業務に支障がないかを現場へ確かめます。候補としただけで、後段化や費用の減額が決定したわけではありません。

• まだ判断できないこと

  入力と確認だけで業務が回るか、集計画面を後から作れるか、移行や権限の確認が何に依存するかが分からなければ、未判断に残します。現場が必要とすることと、技術的に分けられることの両方を確認してから区分を直します。

例えば、集計画面を作らない案でも、集計に使うデータが取り出せず、現場の仕事が続けられないなら、単に画面を外すだけでは目的に届きません。反対に、別の確認方法で当面の業務を行える可能性があるなら、その条件と負担を確認できます。いずれも、この架空例だけで可否が分かるものではありません。

安全に使うための権限や必要な確認作業も、「画面ではないから」と一律に削らないでください。何を扱い、誰が操作し、どの仕事を再開できればよいかを示し、分けてよい作業かを開発会社と業務の責任者へ確認します。後回しにした作業に依存して今回の仕事が成立しているなら、範囲を決め直す必要があります。

IPAは、限られた工期・予算の中では必要不可欠な要求を判断し、優先度の低い要求の範囲を調整する考え方を紹介しています。また、要求の優先順位に理由を残すことも参考になります。記事の三つの区分は、その考え方をこの架空業務へ当てはめた編集上の整理です。特定の機能を必ず削る規則ではありません。

180万円の社内案と210万円の見積案で、何が分かるか

次の図は、同じ架空の受注入力を題材にした、説明用の二つの資料状態です。左は見積依頼を準備する社内案、右は上限を超える見積案を読むために置いた例です。実案件でこの順に進んだ記録ではありません。金額を比較する部分では、どちらも税込・初期費用のみという同じ架空条件を置いています。

30万円は、210万円から180万円を引いた差です。集計画面に30万円かかるという内訳ではありません。画面を外すと共通の作業がどう変わるか、後で追加する準備が必要か、確認や移行の作業が残るかは別に確かめます。引き算の差を、そのまま「削れる費用」へ置き換えないでください。

実際の見積もりで税や対象作業が違っていた場合は、まず条件をそろえて再提示を依頼します。この例の30万円を自社の差額として使うこともできません。比較できる部分、金額がまだ分からない部分、社内の判断が必要な部分を分けて残すことが、この段階の成果です。

上限を超えたら、同じ条件で再提示を頼む

上限を超えた見積もりには、「何とか180万円にしてください」と金額だけを伝えるより、今回残したい仕事と確認したい案を示します。開発会社が何を変えて金額を再提示したかが分からなければ、上限内になっても必要な業務が実現できるかを判断できないためです。

1. 比較条件を渡す。社内上限は決定済みか案か、初期費用と対象期間、税の扱い、含める作業、未確認費用を明記します。未確認の欄はそのまま示し、どの条件が分かれば再見積もりできるかを尋ねます。
2. 今回残したい業務を説明する。注文の入力と確認を先に検討する理由と、使える状態の目安を伝えます。画面の名称だけでなく、誰のどの作業が必要かを説明します。
3. 代替案・段階を分ける案を尋ねる。必須として検討する仕事を残す方法があるか、集計画面などの後段候補を分けられるかを確認します。分けた場合の業務上の負担、依存関係、別途必要になる作業と費用も回答へ含めてもらいます。
4. 同じ項目で回答を受け取る。各案の作業範囲、含まないもの、金額の前提、日程の前提、未確認事項をそろえます。希望額に合わせた回答が必ず得られると約束するものではありません。

これは説明用の依頼文です。実際には社内で決めた条件へ書き換え、共有してよい業務情報だけを相手へ渡します。全ての欄を完成させなければ相談できないわけではありません。「移行費は誰に確認すればよいか」など、不明点と確認したいことが一つでもあれば、それを明示して相談できます。

回答を受けるための業務説明や依頼書を作る段階では、開発会社へ伝える提案依頼書の作り方が役立ちます。本稿で決めた社内上限案と優先する業務を、その依頼内容へつなげてください。

回答後に案を直し、社内判断と発注を分ける

再提示が届いたら、金額だけを上書きせず、どの仕事が残り、どの条件が変わったかを社内案へ戻します。現場には今回の作業が成立するか、開発会社には分け方や必要な確認が実現可能か、経理・予算の決定者には対象支出と支払い条件が判断できるかを、それぞれ確かめます。

例えば、集計画面を後段へ分ける案が出ても、当面の集計作業を現場が引き受けられるか、後で追加するための前提や費用が何かが不明なら、後段化は未決定に残します。見積もりに明細がない作業を、無料で含まれている、不要になった、既に終わったと判断しないでください。

条件をそろえても上限を超える場合は、会社が上限を見直すか、業務の範囲や実施時期を見直すか、今は発注しないかを判断します。記事の例がその選択を決めるわけではありません。どの情報を基に、誰が何を決め、何が未確認で残ったかを記録します。上限を上げる案も、社内で検討しただけで承認済みとは扱いません。

二社の提案を選ぶ段階になった場合は、同じ条件で開発見積もりを比較する方法へ進めます。今回の「社内で上限と優先業務を決める作業」と、提供側の提案を比較する作業を順に接続してください。

最後に、再見積もりを受け取ったこと、社内で案を選んだこと、実際に発注・着手を了承したことを分けます。受注後に追加作業が出る場合の見積回答と着手の扱いは、追加費用の確認と着手の了承を分ける記事で確認できます。本稿の相談例や図は、契約や着手の記録ではありません。

まとめ：金額と仕事の条件を、一緒に決める

システム開発の予算上限は、会社が決める支出の条件です。何の仕事を変えるのか、何の費用をどの期間へ含めるか、今回に残す仕事と後段候補、未判断の条件を一緒に整理します。開発会社の見積もりが、そのまま会社の支出決定になるわけではありません。

架空の180万円と210万円では、置いた同条件で30万円の差があることだけが分かります。後段化による減額や保守費は未確認です。上限を超える案には、必要な仕事を残す代替案と段階を分ける案を、同じ条件で再提示できるか尋ねます。回答を社内案へ戻し、社内判断と発注・着手を分けて扱ってください。