システム会社に頼む前に、工場の業務を1つに絞る——見積が膨らむ3つの型と、契約の分け方

製造業の頼み方で、見積が膨らむ 3 つの型

受注生産の工場で「受注の入力が大変なのでシステムを入れたい」と相談したはずが、返ってきた提案書は受注・生産計画・購買・在庫・出荷・請求までを一つにつなぐ基幹システムの計画で、期間も費用も想定を大きく超えていた、ということは起こりうる。提案する側に悪意があるとは限らない。頼む側の渡し方が、大きな見積を出すしかない形になっていることが多い。

見積が膨らむ型は、おおむね次の 3 つに分けられる。

型 1：全社・全工程を一度に頼む

工場の業務はつながっている。受注が決まれば材料を手配し、生産計画に載せ、検査して出荷し、請求する。だから「どうせなら全部つなげたい」と考えるのは自然である。しかし範囲を全工程にすると、関わる部署・帳票・例外がすべて見積の対象に入る。営業・購買・製造・品質・経理の全員の要望を集める作業だけで、相当な工数になる。

IPA の製造分野 DX の解説資料は、中小の製造業が DX にかけるお金は工夫次第で少なくでき、安価な汎用品でデジタル化している例があると書いている。さらに、データの分析も AI を使うまでもなく表計算で十分にできる場合があるとしている^[3]。最初の一歩は、全工程をつなぐ大きな仕組みである必要はない。

型 2：要件が決まらないまま、総額を求める

「何ができるか見てから決めたいので、まず見積を」と頼むと、相手は分からない部分に余裕を積んで出すしかない。IPA の「情報システム・モデル取引・契約書」は、システム化の方向性や計画の段階で出す見積を「仮試算見積」「試算見積」、要件定義の後に出す見積を「概算見積」と呼び、いずれも確定見積ではないと整理している。確定見積が出せるのは、画面や帳票などを決める外部設計の段階だとしている^[1]。

つまり、要件が決まる前に受け取る総額は、どれだけ丁寧に作られていても参考値である。参考値の段階で「この金額で全部」と決めようとすると、作る側は後で増える分を先に乗せるか、契約後の変更で取り戻すかのどちらかになる。

型 3：例外と「今と同じに」を、数えずに渡す

工場の業務には例外が多い。特急の割り込み、分納、顧客からの支給材、図面の改訂で途中から仕様が変わる注文、FAX の注文書に手書きで追記された納期、取引先ごとに違う締め日。現場の担当者は頭の中で処理しているので、聞かれない限り出てこない。仕組みを作る側は、聞いていない例外にぶつかるたびに作り直すことになる。

もう一つは「今と同じに動けばよい」という頼み方である。IPA のシステム再構築のユーザガイドは、「現行踏襲」の「現行」が何かについて、頼む側と作る側でずれが生じることがあると書いている。頼む側は動いている今の仕組みがそのまま再現されることを期待し、作る側は書類や実際のプログラムに書かれている内容を拠り所にする。書類とプログラムが食い違っていれば、どちらに合わせるかを決めないと誤った「現行通り」になる^[2]。何年も使ってきた Excel のマクロや、担当者が手で直している集計表を「今と同じに」と渡すのは、これと同じことを頼んでいる。

同じガイドは、作り直しと同時に業務の要件を変えたり足したりすると、今と同じ部分と変えた部分の整合を取るのが難しくなり、品質を確かめる難しさが非常に高くなるとも書いている^[2]。「せっかくなので、ついでにあれも」は、見積を膨らませる典型である。

頼む前に、範囲を 1 つの業務に絞る

業務の境目は「帳票」で切る

工場の業務を 1 つに絞るとき、部署で切ると範囲がぼやける。おすすめは、始まりと終わりを帳票で決めるやり方である。

• FAX・メールで届いた注文書から、受注の入力が終わるまで
• 検査記録の用紙から、検査成績書を出すまで
• 入出庫の伝票から、在庫の数が更新されるまで
• 設備の点検表から、点検の記録が残るまで
• 見積依頼の受付から、見積書を返すまで

こう切ると、何が入力で何が出力か、誰が触るかがはっきりする。範囲に入らない業務（その前後の業務）とのつなぎ目も見える。どの業務を最初に選ぶかの比べ方は工場で最初にデジタル化する業務の選び方に書いたので、ここでは選んだ後の頼み方に絞る。

「やらないこと」を先に書く

範囲を絞るときに効くのは、やることより先にやらないことを書いておくことである。たとえば「受注入力を楽にする」なら、次のように書く。

• 生産計画への自動の反映は、今回はしない（受注の一覧を出すまで）
• 請求書の発行は、今の会計ソフトのまま変えない
• 取引先側に新しい入力をお願いすることはしない

やらないことが書いてあれば、作る側は見積の前提を狭くできる。書いていないと、相手は「たぶん要るだろう」と思う部分まで含めて見積もる。

例外は、数えて一覧にする

例外は「ある」「ない」ではなく、月に何件あるかで書く。件数が分かれば、仕組みで扱う例外と、人が別に処理する例外を分けられる。月に 1 件しかない例外のために仕組みを複雑にするより、その 1 件は人が扱うと決めたほうが安く確実なことが多い。下の表は、受注入力を絞ったときの記入の例である（件数は記入の形を示すための例）。

この一覧を作ると、例外の多くが一握りの型に集まっていることが分かる場合がある。逆に、例外の種類が多すぎて一覧にならないなら、その業務はまだ仕組みにする段階ではなく、先にやり方をそろえる段階にある。

システム会社に渡すもの

範囲を絞ったら、頼む相手に渡す資料をそろえる。要件定義書のような立派な書類である必要はない。相手が見積の前提を狭くできる材料がそろっていればよい。

• 今の流れ：誰が、どの帳票を受け取り、どこに書き写し、誰に渡すか。手書きの図で構わない
• 帳票の実物：注文書・検査記録・伝票などを、取引先名や価格を消したうえで数枚。きれいな見本ではなく、手書きの追記や訂正がある現物のほうが役に立つ
• 件数：月の件数と、月末や期末の多い時期の件数
• 例外の一覧と件数：上の表の形
• 今の道具：使っている Excel やマクロ、生産管理のソフト、FAX 複合機、会計ソフト。つなぐ必要があるもの、つながなくてよいもの
• やらないこと：範囲外の一覧
• うまくいったかの見方：入力の時間、打ち間違いの件数など、何で確かめるか

購買の業務について、部門の要望を判定できる要件に書き直す手順は購買部門の要望を要件に書き直す記事で扱った。工場の他の業務でも、「使いやすく」のような要望を、誰が見ても同じ判定になる文に直すという考え方は同じである。

IPA のモデル契約は、頼む側（ユーザ）には、システムに求める要件を明確に定義する責任があるとしている^[1]。同じく IPA の製造分野 DX の解説資料は、DX は本来ユーザが主導して行うもので、中小の製造業の DX でシステム会社が担うのは、包括的な推進ではなく、部分ごとに必要なものの提供にとどまるとしている^[3]。範囲と例外を決めるのは頼む側の仕事で、ここを相手に任せると、範囲も見積も相手の想定で決まる。

見積の比べ方

複数の会社から見積を取ったら、総額だけで比べない。総額は前提が違えば比べられないからである。次の順に見る。

何を含み、何を含まないか

見積書の前提条件の欄を並べて読む。データの移行、社員への説明会、取引先への案内、導入後の問い合わせ対応、月々の保守、つなぐ相手のソフト側の改修費が、含まれているか、別途か、書かれていないか。総額が安い見積は、これらが別途になっているだけのことがある。社内で予算を通すときに漏れやすい費用の洗い出し方は稟議書の記事にまとめてあり、工場の仕組みでも同じ項目がそのまま使える。

出来合いのものを使うか、作るか

同じ業務でも、既にある業務ソフトやクラウドサービスを設定して使う提案と、一から作る提案では、費用も後の手直しのしやすさも違う。IPA のモデル契約は、作る側が仕組みの中核になる他社のパッケージ製品を選ぶ場合は、契約前の提案・見積条件を示す段階でその利用の有無を明らかにする必要があるとしている。主な再委託先などの推進体制も、提案・見積の段階で説明する事項として挙げている^[1]。見積を受け取ったら、どこまでが出来合いの製品で、どこからが作り込みかを聞く。

今のツールの見直しで済む案があるか

比べる候補には、新しい仕組みを入れない案も入れておく。たとえば受注入力なら、注文書の様式を取引先と合わせる、入力用の Excel の欄を整える、FAX をメールで受けて取り込みやすくする、といった見直しで、件数の多い例外が消えることがある。新しい仕組みを入れる案は、この案と比べて何が良くなるかで評価する。

変更をどう扱うか

作り始めてから仕様が変わったとき、どう協議し、費用と納期をどう決めるかが見積や契約に書いてあるかを見る。IPA のモデル契約は、口頭での合意によるあいまいさを排除し、必要性とスケジュール・費用への影響を双方で協議するための変更管理の手続を設けている^[1]。変更の手続が決まっていない契約では、「ちょっとした直し」の積み重ねが後で大きな請求になるか、相手が追加の対応を断るかのどちらかになりやすい。

契約は、範囲を決める段階と作る段階に分ける

範囲を 1 つの業務に絞っても、最初から作るところまでを一括で頼むと、まだ決まっていない部分の余裕が見積に入る。IPA のモデル契約は、工程ごとに個別の契約を結ぶ「多段階契約」と、あいまいさのある段階の見積を要件が明確になった段階で見積り直す「再見積り」の考え方を採っている^[1]。

契約の形は、民法の 2 つの型を知っておくと読みやすい。請負は、相手が仕事を完成させることを約束し、こちらがその結果に報酬を払う契約である^[5]。これに対して準委任は、法律行為でない事務を任せる契約で、委任の規定が当てはめられる^[5]。完成したものが決まっていない段階を請負で頼むのは難しい。IPA のモデル契約は、企画段階はユーザの業務要件が具体的に確定しておらず成果物の内容を特定できないので準委任が適切とし、要件定義も準委任として独立した段階に置いている。ここで言う要件定義は、全社の計画ではなく、選んだ 1 つの業務について帳票・件数・例外を決める小さな段階である。外部設計とシステムテストは準委任と請負の両方があり得るとし、内部設計からプログラミング、結合までは請負としている^[1]。

表の段階の名前は大きな開発を前提にしているが、工場の 1 つの業務を扱う小さな案件でも考え方は同じである。最初に「範囲を一緒に決める」部分だけを小さく頼み、その結果の資料を基に作る部分の見積を取り直す。IPA のモデル契約も、多段階で契約すれば工程ごとに異なる会社に分けて頼むこともできるとしている^[1]。最初の段階の資料が手元に残れば、作る部分の見積を他社に出してもらうこともできる。この形にしておくと、最初の段階が終わった時点で、作るか、やめるか、別の方法にするかを選べる。

民法は、成果に対して報酬を払う形の準委任も定めている^[5]。どの型を選ぶにしても、契約書に「この段階で何を受け取るか（業務の流れの図、例外の一覧、画面の案など）」を書いておくと、段階の終わりが分かりやすい。

作った後に、現場で試してから本番に移る段階もある。現場で試す段階は、何を確かめるかは決められても完成する物を特定しにくいので、表の受入・導入支援と同じく準委任で頼むのが自然なことが多い。完成を約束する請負で頼むなら、確かめる項目を「結果の報告書の納品」のような成果物の形に落としておく必要がある。試した結果を本番につなげる条件の決め方は工場での試験導入を本番につなげる記事で、購買システムに限った試行の進め方は購買システムを試しに入れるときの記事で扱っている。

小さく頼むことが、遅れることにならないようにする

1 つの業務に絞ると「全体の最適化が遅れる」という反論が出ることがある。IPA の調査では、日本で何らかの形で DX に取り組んでいる企業の割合は、従業員 1,001 人以上で 96.1％、100 人以下で 46.8％と、規模で 2 倍以上の差がある^[4]。この調査は製造業に限らない国内企業の経営層または ICT 関連事業部門を対象にしたもので、割合は従業員規模ごとの回答企業が分母である。

同じ調査は、取り組んでいない 100 人以下の企業が挙げる理由として、取り組むメリットが分からないこと、知識や情報が足りないことが上位だとしている^[4]。調査が聞いているのは取り組まない理由までだが、この記事の見立てでは、全社の計画を先に描こうとすると、このメリットが見えない段階で止まりやすい。1 つの業務で入力の手間や打ち間違いがどう変わったかを数字で見られれば、次にどこへ広げるかを決める材料になる。小さく頼むことは、全体を諦めることではなく、全体を決めるための数字を先に取ることである。

ただし、1 つずつ別々に入れていくと、業務ごとに違うソフトが並び、データがつながらなくなる心配はある。最初の 1 つを頼むときに、取引先・品目などの台帳を何で持つか、データを書き出せるかだけは確かめておく。表計算の購買業務を順番に移していく考え方はExcel の購買業務をシステムに移す順番の記事に、移すデータの扱いはデータ移行の記事にある。

よくある質問

何を頼めばよいか分からない段階で、システム会社に相談してよいですか

相談してよい。ただし、その段階で受け取る提案や金額は参考値だと理解しておく。可能なら、最初の打ち合わせの前に「困っている業務」と「月の件数」だけでもまとめておくと、相手も範囲を狭く考えやすい。範囲を一緒に決める作業を有償で頼むなら、それを独立した段階として契約し、作る部分とは分けておく。

提案書に、こちらが頼んでいない業務まで入っていました

入っている理由を聞く。つながる業務まで含めないと成り立たないのか、将来を見越した提案なのか。後者なら、今回の範囲から外した見積を出してもらう。「やらないこと」を最初に渡していなかったなら、ここで渡す。

補助金を使えば、大きく頼んでも負担は少ないのではありませんか

補助金は費用の一部を補うもので、範囲の大きさから来る失敗の危険までは減らさない。使われない仕組みが補助金で安く手に入っても、現場の手間は減らない。範囲を絞る理由は費用だけではなく、確かめながら進めるためでもある。現場で使われない仕組みになる理由と潰し方は工場にツールを入れても使われない理由の記事で扱っている。

社内に詳しい人がいないので、範囲も相手に決めてもらいたいのですが

決める作業を手伝ってもらうのはよいが、決めるのは自社である。業務の流れや例外を知っているのは現場の担当者で、相手はそれを聞かないと分からない。現場の担当者が打ち合わせに出られる時間を、最初の段階の費用の一部と考えて確保しておく。

まとめ

工場の仕組みづくりの見積が膨らむのは、全工程を一度に頼む、要件が決まらないまま総額を求める、例外と「今と同じに」を数えずに渡す、の 3 つが重なるときである。頼む前に、帳票で始まりと終わりが見える 1 つの業務に絞り、やらないことと例外の件数を書いて渡す。見積は総額でなく、含むもの・出来合いか作るか・今のツールの見直し案・変更の扱いで比べる。契約は範囲を決める段階と作る段階に分け、段階ごとに次へ進むかを決める。

出典・参考資料

1. 情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第二版〉（独立行政法人情報処理推進機構（IPA）・経済産業省／2020 年 12 月・2025 年 4 月更新）
2. システム再構築を成功に導くユーザガイド 第 2 版〜ユーザとベンダで共有する再構築のリスクと対策〜（独立行政法人情報処理推進機構（IPA）ソフトウェア高信頼化センター／2018 年 2 月）
3. マンガでわかる製造分野 DX FAQ 編（独立行政法人情報処理推進機構（IPA）／2022 年 6 月 6 日改訂）
4. DX 動向 2025 日米独比較で探る成果創出の方向性（独立行政法人情報処理推進機構（IPA）／2025 年 7 月 9 日 第 2 版）
5. 民法（e-Gov 法令検索（デジタル庁））

WHITE PAPER

この記事の理解を深める
無料ホワイトペーパーをプレゼント

製造業の現場で使える実務資料（PDF）を無料でお届けします。"こんな資料が届きます" ↓ 下のボタンからどうぞ。

🔒 全文は無料ダウンロードで