受発注システムの開発費は、取引先と例外の数で決まる｜見積もりを取る前に社内で数えておくもの

受発注システムを外注して作るとき、金額を大きく動かすのは、作る画面と帳票の数、ほかのシステムとつなぐ数、今の台帳から移すデータの量です。そして画面と連携を増やしている元は、多くの場合、取引先ごとに違う条件です。単価の決め方、締め日、納品先、取引先が使う品番の呼び方。こうした違いを多く抱えている会社ほど、同じ「受発注システム」でも作るものが増え、見積もりは高くなります。

相場として示される金額の多くは、取引先ごとの違いをいくつ想定した金額なのかが分からないため、自社がどのあたりに入るのか見当をつけられません。見積もりを取る前に、社内で次の五つを数えておくと、開発会社はその数から作る量を見積もれるようになり、各社の金額を同じ前提で比べられます。

1. 注文がどの入口から、月に何件来ているか
2. 取引先ごとに違う条件が、何種類あるか
3. どのシステムと、どのくらいの頻度でデータを受け渡すか
4. 今のExcelや販売管理から移すデータが、どれだけあるか
5. 使い始めた後に、取引先や項目を足すのは誰か

この記事では、それぞれの数え方と、数えた結果を画面の数・連携の数に置き換える方法、見積もり依頼に添える1枚のまとめ方を順に説明します。Aurant Technologiesは受発注・在庫の仕組みづくりを支援しており、費用は業務の内容を伺ってからお見積もりしています。そのときに伺う内容の多くも、ここで数えるものです。

相場の金額に幅があるのは、取引先ごとの違いが前提に入っていないから

同じ「受発注システム」でも、中身は会社によって大きく違います。どの取引先も同じ価格表で同じ商品を買い、全員が月末締めなら、取引先の注文画面、社内の受注管理の一覧、請求データの出力があれば、ひとまず業務は回ります。

取引先ごとに掛け率が違う、締め日が20日と月末に分かれている、納品先が店舗ごとに何十か所もある、注文書に取引先側の品番が書かれてくる、という状態なら事情が変わります。単価の表、締め日ごとの請求の処理、納品先の一覧、品番の対応表が要り、それぞれに登録や修正のための画面が付きます。正しく動くかを確かめるテストも、違いの数だけ増えます。相場の金額の幅には、こうした違いの差がそのまま入っています。

取引先ごとにやり方が違うのは、受注する側では珍しいことではありません。中小企業庁は、企業間の受発注でFAXや電話が使われている例が一定数ある一方で電子化が進みつつあるとし、受注側で電子受発注に対応していたのは48.5%（2021年、同庁の取引条件改善状況調査）と紹介しています。同じページでは、中小企業共通EDIで受発注をそろえる利点として、取引先ごとに専用の端末や用紙を用意しなくて済むことを挙げています（中小企業庁「中小企業の受発注デジタル化」）。

ですから、相場表の中で自社の位置を探すより先に、自社の違いを数えます。数える対象は、取引先の数そのものより、違いの種類です。

注文の入口ごとの件数を、1か月分数える

最初に数えるのは、注文がどこから入ってくるかです。入口の種類によって、システムでの受け方が変わります。

• 取引先が自分で入力するWebの注文画面（Web受注）
• FAXや電話で届いた注文を、社内の担当者が代わりに入力する画面
• メールに添付されてくるExcelやPDFの注文書の取り込み（書式ごと）
• 取引先の発注システム（Web-EDIなど）から落としたデータの取り込み（相手の形式ごと）

入口が一つ増えるごとに、画面か取り込みの処理が一つ増えます。取引先の全部がWebでの注文に移るとは限らないので、FAXや電話が残りそうな取引先の分も数に入れておきます。

数え方は、ふだんの1か月を選び（季節の波が大きい業種なら繁忙の月も）、受注伝票やFAXの束、メール、電話のメモから、取引先ごとに入口と件数を書き出します。すべてを数えきれない場合は、注文の多い取引先から順に拾うだけでも、見積もりの前提として役に立ちます。書き出しておくと見積もりで使われるのは、次の項目です。

件数と並べて明細の行数を見るのは、入力の手間が件数より行数に左右されるからです。月の件数が少なくても1件に数十行ある取引先は、Webの注文画面へ移ってもらえたときに手間が大きく減る取引先でもあります。

取引先ごとの条件は「型」と「一社だけの決まり」に分けて数える

次に、取引先ごとに違う条件を書き出します。数えたいのは、条件ごとに「型がいくつあるか」と、「どの型にも入らない一社だけの決まり（この記事でいう例外）がいくつあるか」の二つです。

型に入る条件は、取引先ごとの設定として持てます。取引先が増えても設定を1件足せば済み、画面は増えません。締め日のように型がはっきりしている条件は、既製の部品で済むこともあります。たとえばkintoneで受注を管理する場合、日付から次の締め日（月末・10日・15日・20日・25日など）を自動で出す当社の締め日自動計算プラグインのような部品を使えば、締めの計算を一から作らずに済みます。

一社だけの決まりは、その一社のための処理や帳票になり、作る量もテストも一社分ずつ増えます。見積もりの金額を大きく動かすのは、取引先の数よりも、この一社だけの決まりの数のほうです。

そこで、一社だけの決まりは一つずつ、次のどれにするかを社内で決めておきます。

• システムで持つ（件数が多い、間違えたときの影響が大きい）
• 手作業で残す（年に数回しか起きない）
• 取引先と相談して、型のどれかにそろえてもらう

どれを選ぶかは業務の事情で決まるため、開発会社には決められません。一つでも「手作業で残す」「そろえてもらう」に回せれば、その分だけ作る量が減ります。

単価の持ち方は、移すデータの量にも関わります。取引先別の単価表で持つと、単価の行数は最大で「取引先の数×品目の数」まで増えます。掛け率で決められる取引先が多いほど、移すデータも、使い始めてからの単価改定の手間も小さくなります。

つなぐ先は、相手・向き・頻度・方法を書き出す

受けた注文は在庫の引き当てと出荷に回り、出荷した分は請求と会計に回ります。今の販売管理や会計ソフト、倉庫の委託先、ECサイト、取引先の発注システムなど、データを受け渡す相手を書き出し、相手ごとに次の四つを決めます。

同じ「会計ソフトとつなぐ」でも、締めごとにCSVを出して経理の担当者が取り込む形と、出荷のたびにAPIで送る形とでは、作る量が違います。後者は、送れなかったときや二重に送ったときの扱いまで作り込む必要があるからです。在庫の数を倉庫の委託先と常に合わせるような両方向の連携は、なかでも手間がかかります。

方法は、つなぐ相手のシステムで決まります。APIがあるか、使うのに追加の契約が要るか、仕様書を出してもらえるかは、つなぐ相手の提供元に確かめます。相手側の費用が、開発の見積もりとは別にかかることもあります。今の販売管理や会計を残したまま、足りない部分だけをつなぐ進め方はシステム統合・基幹刷新のページで紹介しています。

数えた結果を、画面の数と連携の数に置き換える

ここまで数えたものを、システムの部品に置き換えます。開発会社は画面・帳票・連携・移すデータの一覧から作業の量を見積もるので、社内で数えた結果をこの形にしておくと、最初の打ち合わせから具体的な話ができます。

移すデータは、件数に加えて、整理が要るかどうかも書いておきます。同じ取引先が別の名前で二重に登録されている、品名の書き方が担当者ごとに違う、といった状態なら、どれに寄せるかを業務を知っている人が決める作業が、移す前に入ります。

既製のサービスで収まるか、作るかは、例外の数で分かれる

置き換えた結果、画面のほとんどを既製の受発注サービスの設定で表せるなら、作らずに使うほうが早く始められます。当社も自社の業務では、既製のサービスで足りる部分はそのまま使い、合わない部分だけを自社で作ってつないでいます（自社での実践）。反対に、一社だけの決まりが多く、既製のサービスに合わせると業務が回らない場合に、作る意味が出てきます。そのあいだに、kintoneのような業務アプリの基盤で組む方法もあり、どれが合うかも、ここで数えた例外の数と、使い始めてから社内で変えたいことの量で決まります。

補助金を見込むなら、ここで分かれる

国の「デジタル化・AI導入補助金2026」は、中小企業などがAIを含むITツールを導入する費用を支援する制度で、申請は事務局に登録されたIT導入支援事業者のサポートを受けて行います（中小企業庁「デジタル化・AI導入補助金2026」の概要）。補助の対象になるのは、事前に事務局へ登録されたITツールを導入する費用です（事務局「よくあるご質問（通常枠）」）。そしてITツールの登録の決まりでは、製品として完成しておらずスクラッチ開発を伴うソフトウェア、業務の流れに影響するほどの大きなカスタマイズが要るもの、特定の顧客向けに限られて一般に販売されていないものは、登録の対象外とされています（事務局「ITツール登録要領」）。

つまり、一社だけの決まりに合わせて一から作る部分は、この補助金の対象にならないと考えておくのが安全です。例外が少なく、登録された受発注のツールで業務が収まるなら、補助金を使える可能性があります。ほかの制度は要件が別なので、使える制度があるかは、制度ごと・年度ごとの公募要領で確かめます。

生成AIを使っても、期間の半分近くは社内の人が加わる工程

開発に生成AIを使うと、どの工程が短くなるのか。縮みやすいのは、決まった仕様を画面や処理にする「作る」部分です。画面や定型の処理のコードを書く、テスト用のデータをそろえる、移すデータの変換処理を書く、といった作業は生成AIに任せやすく、縮む余地があります。

ただ、「作る」部分が全体のどれくらいを占めるかを見ておくと、期待できる幅が分かります。日本情報システム・ユーザー協会（JUAS）の「ソフトウェア・メトリクス調査2025」は、企業のプロジェクトの実績から、工程ごとの工数（人が働いた量）と工期（かかった期間）の比率を示しています。

設計から結合テストまでの「作る」工程は、工数では61%を占めますが、工期では53%です。一方、要件定義、ユーザー総合テスト、稼働直後の初期フォローを合わせると、工期の47%になります。いずれも、業務を知っている人が加わって進める工程です。作る工程が速くなっても、期間のこの半分近くは、発注する側の人の時間に左右されます。

なお、このデータは情報システムの開発・保守に取り組んできた企業へのアンケートにもとづくもので、工数と工期の関係を分析した232件のうち150件は50人月以上の規模です。小さな受発注システムの比率にそのまま当てはまるとは限らないので、工程ごとの重みの傾向として読んでください。

生成AIだけでは縮みにくく、社内の準備で短くできる作業

受発注の開発で、この「人の時間」にあたるのは次のような作業です。どれも生成AIだけでは縮みにくく、発注する側が先に準備しておくほど短くなります。

• 例外の聞き取り：一社だけの決まりは書類に残っていないことがあり、取引先ごとの担当者に聞いて回る時間が要ります。この記事で数えた一覧があれば、聞き取りは一覧の確認から始められます。
• データの整理：重複した取引先や、書き方の揺れた品名をどれに寄せるかは、業務を知っている人が決めます。見積もりを取る前から、社内で進めておけます。
• 並行運用：新しい仕組みと今のやり方を並べ、受注・在庫・請求の数字が合うかを確かめます。請求まで確かめるには少なくとも一度は締めをまたぐので、使い始めたい時期は締めの日程から逆算しておきます。
• 取引先への案内：Webの注文画面に移ってもらう取引先には、案内と操作の説明が要り、進み方は取引先の都合にも左右されます。どの取引先から声をかけるかと案内の文面は、開発と並行して社内で用意できます。

私たちも、生成AI（Claude Code）を使って取引先の注文画面や受注一覧を先に作り、いつもの注文を入れて触っていただく進め方をとっています。画面を先に用意するのは、紙の上の打ち合わせでは出てこない例外を、実際の注文を入れてもらう中で見つけるためです。例外を知っている方の時間をいただくことは、生成AIを使っても変わりません。

取引先が増えたとき、設定で足せるか、開発の依頼になるか

受発注の仕組みは、使い始めてからも変わり続けます。新しい取引先が加わる、掛け率や単価を改定する、新商品を追加する、納品先が増える、締め日や請求書の様式が変わる、LINEで注文したいという取引先が出てくる。こうした変更のたびに開発会社への依頼が要る作りだと、そのたびに費用と待ち時間がかかります。

そこで、見積もりを取る前に、使い始めてから起きそうな変更を並べ、社内の担当者が設定の画面で変えられるようにしておくものと、開発会社に頼むものを分けておきます。よく起きる変更ほど、設定で変えられるようにしておく意味があります。その分、最初に作る設定の画面は増えますが、どの変更を社内で済ませたいかは、発注する側にしか決められません。

社内に直せる人がいる前提で考えないことも大切です。東京商工会議所が2024年10〜11月に主に東京23区の中小企業を対象に行った調査では、情報システムの専任担当者がいる企業は11.7%で、担当者がいない企業は28.9%でした（「中小企業のデジタルシフト・DX実態調査」集計結果（詳細版）。口頭・電話・帳簿での業務が多いと答えた企業を除く1,002社の集計）。兼任の担当者がほかの仕事と並行して直すことになるなら、設定で変えられる範囲を広めにとり、変え方の手順を残しておく必要があります。

見積もりの段階で、次の三つも確かめておきます。

• 保守の範囲：不具合の修正だけか、項目や画面の追加も含むか
• 変更の頼み方：取引先や項目を足したいときに、どう依頼し、費用をどう決めるか
• 引き渡してもらう資料：操作の手順と、データの定義（項目・マスタ・つなぐ先と受け渡すデータの一覧）

見積もり依頼に添える1枚のまとめ方

ここまで数えたことを1枚にまとめ、見積もりを頼むすべての会社に同じものを渡します。前提がそろうので、金額の違いを「何を作る前提か」の違いとして読めるようになります。書けない欄があっても構いません。「未定」「分からない」と書いておけば、開発会社はそこを質問として返してきます。

見積もりを受け取ったら、この1枚のどの欄が金額を大きく動かしたかを各社に聞きます。とくに、一社だけの決まりを設定で持つのか、その一社のために作るのか、運用で吸収する提案なのかは、会社によって答えが分かれることがあります。その答えの違いが、そのまま金額の違いの理由になります。届いた見積書を行ごとに並べて比べる方法は、開発会社の見積もりの比べ方で扱っています。

Aurant Technologiesでは、FAX・電話・Excelで受けている注文を、取引先がWebで入れる形にする受発注・在庫の仕組みづくりを支援しています。費用と期間を左右する要素と、最初のお見積もりまでに伺う内容は、受発注・在庫管理システムの開発のページにまとめました。この記事の1枚が途中まででも数え方からご一緒できますし、他社から届いた見積もりを、この1枚の前提で読み直すご相談も受けています。