受注から部品表を展開して発注する作業を表計算から外す——移す前に決める 5 つのこと

表計算でやっている「受注から発注まで」

受注生産や組立品の多い工場では、受注が入るたびに次のような作業が回っている。受注一覧から製品の品番と数量を拾い、部品表のシートから構成部品を検索関数で引き、構成数に受注数量を掛ける。複数の受注にまたがる共通部品は集計表でまとめ、在庫表と見比べて足りない分を数え、仕入先ごとに並べ替えて、注文書のひな形に転記する。

担当者が慣れていれば、この作業は 1 日で回る。問題は、作業の途中にいくつもの判断が入っているのに、その判断が表のどこにも残らないことである。どの版の部品表を使ったのか、在庫を何個として見たのか、なぜこの部品はこの仕入先にしたのか。答えは担当者の頭の中にしかない。

部品表そのものの作り方は部品表（BOM）とはで、所要量を発注数量に変える段階（展開・引当・丸め・割り付け・逆算）はBOM から発注をどう起こすかで扱っている。この記事は、その作業を表計算から外すときに何を決めればよいかに絞る。

言葉をそろえておく

表計算の列の名前は会社ごとに違う。移す前に、JIS Z 8141（生産管理用語）の言葉に対応させておくと、仕組みを選ぶときも設定するときも話が早い。

いずれも JIS Z 8141 の定義を要約したものである^[1]。表計算の作業を書き出してこの表に当てはめると、自社の作業のうちどこが計算で、どこが人の判断かが見えてくる。

表計算で詰まるところ

使った部品表が最新か分からない

部品表のシートは、設計が持っているものと購買が手元にコピーしたものが並存しがちである。毛利・田村の論文は、部品表は購買部門では購買計画や購買オーダの立案・変更、業者選定、単価設定に使われ、各部門が同じ形の部品表を使っているわけではないので、使う目的に合わせて部門ごとに部品表を組み直す手順が要る、と整理している^[3]。購買用に作り直した部品表は、設計変更が入ったときに追随しないと古いまま残る。

階層を無視して合算すると、中間品の在庫を見ない

表計算では、展開を 1 回で済ませるために、製品の下の部品を全部同じ段に並べた一覧（サマリー型）を使うことが多い。中根の解説は、米国の初期の生産管理を代表する方式として、サマリー型の部品表で部品展開を行い、各構成部品のレベルを考慮しないため中間レベルの部品に対して在庫引当や正味所要量計算を行わない方式を紹介している^[2]。この方式では生産の手配量と受注への引当量の間にずれが生じ、しかも 1〜3 か月の長い計画サイクルで需要の変化への応答が鈍く、その結果として過剰在庫や部品の品切れが頻発したという^[2]。中間のユニットを在庫で持っているのに、その下の部品まで全部手配してしまう。このうち、階層を見ないまま部品の数量を合算してしまうところは、表計算のサマリー型の一覧でも同じように起きる。

合算すると、どの受注の分かが消える

共通部品を受注をまたいで合算すると、発注数量は 1 つの数字になる。後から受注が 1 件取り消されたとき、どれだけ減らせばよいかを逆算できない。JIS がペギングという言葉を置いているのは、この「出所を探す」作業が別に必要になるからである^[1]。

転記のたびに、注文書の項目が抜ける

集計表から注文書へ手で写すと、数量や単価の写し間違いだけでなく、納期や納入場所の欄を空けたまま出してしまうことがある。注文書に書くべき項目は発注書の 4 条明示 12 項目に、表計算の注文書ひな形の限界は注文書のひな形を表計算で持つ限界にまとめている。

移す前に決める 5 つのこと

表計算の作業は、担当者が毎回その場で判断して埋めている部分が多い。システムに移すと、その判断を事前に決めた規則に置き換えることになる。決めずに移すと、システムの既定の動きがそのまま自社のやり方になる。

1 と 2 は、部品表の作り方の問題として先に片付ける

部品表の正本と展開の深さは、発注の仕組みより前に、部品表をどう持つかで決まる。中間品を外注先から買っているなら、その中間品の下は相手の部品表であって、自社が展開する必要はない。逆に自社で組み立てる中間品なら、その下まで展開しないと部品が手配されない。製品ごとに「どの段の品目を買い、どの段を作るか」を一度書き出すと、必要な展開の深さが決まる。

3 は、全部を任せるかどうかより「誰が最後に見るか」

在庫と発注残の差し引きを仕組みに任せるか、案を出させて人が確かめるかは、在庫の数字をどこまで信じられるかで決まる。在庫表が棚卸のたびに大きくずれる状態なら、自動で差し引くと誤った数字で発注が減る。先に在庫の数字を整えるか、当面は差し引きを人が見る運用にする。在庫表の作り方は在庫表を表計算で持つ限界で扱う。

4 と 5 は、例外の扱いを決めるのが本題

受注をまとめる単位と仕入先の決め方は、通常の場合よりも例外の扱いで揉める。仕入先が決まっていない新しい部品、最小発注数で切り上がった余り、急ぎの受注だけ別に出したい場合。それぞれ「仕組みが案を出さずに人に回す」のか「既定の規則で埋める」のかを決めておく。

切り替える前に、同じ受注で結果を突き合わせる

情報処理推進機構（IPA）の「システム再構築を成功に導くユーザガイド」は、同一のインプットで現行システムと新システムのアウトプットが一致するか不一致かを確かめる「現新比較テスト」を挙げている^[4]。同じガイドは、再構築で「現行踏襲」を求めるとき、その「現行」が何かについて利用する側と作る側の間でギャップが生じうるとも指摘している^[4]。表計算の作業では、担当者が毎回入れている手直しも「現行」の一部である。

受注から発注への作業でも、この突き合わせがいちばん確実である。過去の 1 か月分の受注を、表計算と新しい仕組みの両方に通し、部品ごとの数量と仕入先ごとの合計を並べる。食い違ったら、どちらが正しいかを担当者と一緒に確かめる。食い違いの多くは、表計算側の手直し（在庫を見て減らした、仕入先を変えた）が規則として書かれていないことから生じる。その手直しを規則にするか、仕組みに入れずに人の確認として残すかを、この段階で決める。

突き合わせは、全部の製品でやらなくてよい。部品点数が多い製品、共通部品の多い製品、過去に手配ミスが出た製品から順に選ぶ。ガイドも、現新比較テストは全ルートのテストではないため、範囲と内容を明確にするよう求めている^[4]。

発注に変えたあとに残すもの

部品表から作った発注案も、確定すれば普通の発注である。取適法の対象になる製造委託なら、発注した日、給付の内容、受領する期日などを 7 条記録として残し^[5]、記録すべき事項を全部記録した日から 2 年間保存する（記録規則第 3 条）^[5]。記録は事実が生じたときに速やかに行うこととされている（同第 2 条第 1 項）^[5]。

表計算の運用では、集計表と注文書が別のファイルになり、どの集計からどの注文書が出たかがつながらない。システムに移すなら、発注から元の受注と展開の結果を引けるかを確かめておくと、受注の変更や取消があったときに戻れる。発注後に数量や納期を変えたときの記録は発注後の数量・納期の変更を記録に残すを参照してほしい。

テキストは、明示した事項のうち内容が定められないことに正当な理由がある事項がある場合、その事項の内容が定められなかった理由と、定まったあとに明示した日と内容も記録するよう求めている^[5]。展開の時点で単価や納期が決まっていない部品を仮の数字で発注に載せるより、決まっていない理由を持ったまま扱えるかを、移す前に確かめておく。

表計算のままでよい場合

製品の種類が少なく、部品表が 1 段で、受注が月に数件、展開から発注まで同じ担当者が行っている会社なら、表計算で回っていることが多い。その場合でも、展開の結果を残すシートに「使った部品表の版」「展開した日」「元の受注番号」の 3 列を足しておくと、後から説明できる。数式だけで済ませず、担当者が手で直した数字は色を変えて理由を書く。それだけで、移すときの突き合わせが格段に楽になる。

よくある質問

受注の前の内示で展開して、先に部品を手配してよいですか

内示をもとに部品を展開し、仕入先に材料の手配や加工を始めさせているなら、それはもう発注であり、注文書を出す段階に来ている。考え方はBOM から発注をどう起こすかの該当箇所にまとめた。仕組みに移すなら、内示で作った発注案と受注確定後の発注案を区別でき、内示の段階で仕入先に何を伝えたかが残るようにしておく。

共通部品は受注ごとに分けて発注すべきですか

分けなくてよいが、まとめた数量のうちどれだけがどの受注の分かを引ける形は残す。受注の取消や納期変更があったときに、減らせる数量が分かるからである。

展開の途中で設計変更が入ったらどうしますか

変更前の部品表で作った発注案は、確定前なら作り直す。確定後なら、変更の対象になった部品の発注を個別に確かめる。部品表の改訂と発注済みの部品の扱いは部品表（BOM）とはで扱っている。

全部の部品を仕組みに任せると、担当者の仕事がなくなりませんか

なくならない。仕組みが受け持つのは展開と合算と並べ替えで、仕入先が決まっていない部品、余りの出る部品、急ぎの部品の判断は人に残る。その判断を、毎回の手作業の中ではなく、決まった画面で落ち着いて行えるようになる、というのが移す意味である。

まとめ

受注から部品表を展開して発注に変える作業は、表計算でも回る。ただし、どの部品表を使ったか、何階層まで見たか、在庫を何個と見たか、どの受注の分かという前提が表に残らない。階層を無視した合算は、中間品の在庫を見ずに手配することにつながる。移す前に、部品表の正本・展開の深さ・在庫と発注残の差し引き・受注をまとめる単位・仕入先の決め方を決め、過去の受注で表計算と新しい仕組みの結果を突き合わせる。食い違いの多くは担当者の手直しで、それを規則にするか人の確認に残すかを決めることが、移行の本当の作業である。

出典・参考資料

1. JIS Z 8141:2022 生産管理用語（日本産業標準調査会 JIS 検索で閲覧／2022 年 3 月 22 日改正）
2. MRPシステムについて（中根甚一郎／日本経営工学会誌 29 巻 4 号／1979 年）
3. 部品表 (BOM) の設計に関する一考察（毛利直博・田村隆善／生産管理 6 巻 2 号 25-30 ページ／1999 年）
4. システム再構築を成功に導くユーザガイド 第 2 版〜ユーザとベンダで共有する再構築のリスクと対策〜（独立行政法人情報処理推進機構（IPA）ソフトウェア高信頼化センター／2018 年 2 月）
5. 中小受託取引適正化法テキスト「下請法」から「取適法」へ（公正取引委員会・中小企業庁／令和 7 年 11 月）

WHITE PAPER

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

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

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