業務システムの見積が高くなる理由と、安く抑える要件の書き方

結論から書くと、業務システムの見積が高くなる最大の理由は、開発会社が読めない部分を金額に上乗せしている ことです。要件があいまいなほど、失敗に備えた分が増えます。ですから、機能を削る前に、不確かな部分を減らす ことが、最も効果のあるコスト削減です。

要件を詳しく書くというのは、何十ページもの仕様書を作ることではありません。今の業務の実物と、優先順位と、例外を伝えることです。これは発注する側にしか書けないものです。

見積が高くなる理由

1. 不確かさの上乗せ

「顧客管理ができるシステム」という依頼には、少ない画面で済む解釈も、その何倍にもなる解釈もあります。固定の金額で約束する側は、広めに見積もるしかありません。複数社の見積の金額が大きくばらつくのは、各社が想定している内容が違うからであることが多いです。

2. 例外処理

システムの費用の多くは、基本の流れよりも例外の処理で発生します。「通常はこの流れだが、この取引先だけ締め日が違う」「キャンセル後に復活することがある」「途中で担当者が変わることがある」といったことです。Excel や紙なら人の判断で処理できたものを、システムではすべて決める必要があります。

3. 権限と承認の流れ

「部署ごとに見える範囲を変えたい」「金額によって承認者を変えたい」といった要件は、画面の見た目以上に費用がかかります。ほぼ全部の画面とデータに関わり、確認のパターンも増えるからです。

4. 帳票

帳票は細かな調整に時間がかかります。特に、今の Excel や紙の書式に完全に合わせると、改ページや文字数の調整で費用が膨らみます。

5. 既存データの移行

見落とされやすい項目です。長年使った Excel には、表記ゆれ、空欄、同じ取引先の重複などがあります。見本のデータと実際のデータの差が大きいほど、移行の作業が増えます。

6. 他システムとの連携

会計ソフトや既存の基幹システムとの連携は、相手側の仕様と制約に左右されます。API があるのか、CSV の受け渡しなのか、相手の仕様書が手に入るのかで、作業量は大きく変わります。

7. 既存システムの状態

既存システムの改修なら、中身を調べるところから始まります。資料がなければ調査の費用が必要です。これは新規開発にはない費用です。

8. 見えにくい要件

同時に使う人数、データの量、バックアップ、障害時の対応、セキュリティなど、発注側からは見えにくい部分も費用に含まれます。ここを削りすぎると、後で大きな費用になって返ってきます。

見積を抑える要件の書き方

長い仕様書より、次のものを揃えるほうが役立ちます。

目的を1〜2行で書く

「受注の転記作業をなくし、請求漏れを防ぐ」のように書きます。目的が分かると、開発会社がより安い方法を提案できるようになります。機能の一覧だけを渡すと、一覧のとおりに作る見積しか出せません。

今の業務の実物を渡す

これが最も効果があります。実際に使っている Excel、紙の伝票、帳票のサンプルを渡します（個人情報や機密は隠す）。言葉で説明するより、例外の存在がずっとよく伝わります。

使う人と数を書く

誰が（部署や役割）、何人くらいで、どの場面で（社内、外出先、スマートフォン）使うかです。

優先順位を3段階に分ける

全部を「必須」にしないでください。「将来」の項目を書いておくと、後で追加しやすい設計にできるので、作らなくても書く価値があります。

例外を書き出す

今の担当者に「普通と違う処理」を聞いて、箇条書きにします。すべて網羅する必要はありません。「こういう例外がある」と分かるだけで、見積の精度はかなり上がります。

データの量を実数で書く

取引先の数、月の受注件数、移行するデータの期間などです。おおよその数字で構いません。

使わなくなるものを書く

新しいシステムに置き換えたら、やめる作業や使わなくなる Excel も書いておきます。逆に、新しいシステムの導入後も残す作業があるなら、それも書きます。ここがはっきりしていると、作らなくてよい機能が分かり、本当に必要な連携だけに絞れます。

予算と期限を伝える

予算を伝えると足元を見られると考えるかもしれません。ですが、伝えないと、開発会社はどの水準で提案すべきか分かりません。予算に合わせて範囲を調整してもらうほうが、話が早く進みます。期限は「なぜその日か」も書きます。理由によっては段階的な公開で解決できるからです。

機能を削らずに費用を抑える方法

要件を整理したうえで、次の方法を検討します。

• 段階的に作る: 必須の範囲で最初の版を作り、使ってみてから次を決めます。作ったものの使わない機能を減らせます。
• 業務を少し変える: 例外を残すかどうかを見直します。その例外のために費用をかける価値があるのか、運用で吸収できないかを考えます。
• 帳票の書式を標準に寄せる: 取引先に提出する帳票以外は、今の書式に合わせる必要がないこともあります。
• 既存の製品を検討する: 業務が一般的なら、クラウドサービスで足りることがあります。開発すべきは、自社の強みに関わる部分や、製品では合わない部分です。
• データ移行の範囲を絞る: 全期間でなく直近のデータだけ移し、過去分は参照用に残す方法もあります。
• 要件の整理を先に発注する: 要件が固まらないなら、要件定義を別の仕事として依頼します。全体の金額を固定する前に不確かさを減らせます。

IPA の情報システム・モデル取引・契約書は、発注側と開発側の取引を透明化するために公開されているもので、請負契約と準委任契約の考え方の参考になります。

見積書の比べ方

金額だけを比べると、あとで困ることがあります。安い見積は、範囲が狭いだけかもしれません。次の点を確認します。

• 何が含まれているか: 要件定義、データ移行、テスト、操作説明、公開作業、サーバーの費用
• 何が含まれていないか: 記載がないものの扱い
• 前提条件: 「データは発注側で整形」「帳票は標準書式」など、金額の前提
• 作業の内訳: 画面や機能の単位で分かれているか
• 公開後の費用: 保守やサーバーの月額、修正の頼み方
• 変更の扱い: 途中で要件が変わったときの進め方

同じ資料を渡して複数社に依頼すれば、見積の差の理由を聞けるようになります。「なぜこの金額になるのか」を説明できる相手を選ぶと、開発が始まってからのやり取りも安心です。

相場の金額を知りたいという声も多いですが、この種のシステムは内容によって大きく変わるので、一律の金額はあまり参考になりません。条件を揃えて、実際に見積を取るのが確実です。

h-system でできること

h-system では、Excel や紙で回している業務のシステム化、既存システムの改修、管理画面の開発などをお引き受けしています。根拠のない一律の価格はお出しせず、画面や機能の数、権限や帳票の要件、既存のシステムやデータとの関係を伺ったうえでお見積りします。要件が固まっていない段階からご相談いただけます。初回のご相談と概算のお見積りは無料です。ソースコードの詳細調査や技術的な解析が必要な場合は、事前に内容と費用をご案内します。