オーダーとは何か、指図・計画・命令とどう違うのか

オーダーって、何?

SCM、生産管理、プロジェクト・マネジメント、そしてERP関連などの分野でよく出てくる言葉に「オーダー」がある。 わかったようで、実はよくわからない概念である。 オーダーとは一体何で、どのような時に使われるのだろうか。

オーダーはもちろん、Orderという英単語の訳語だ。この”Order”は多義語であるが、今問題にしている文脈では、順番とか秩序という意味は除いて考えよう。 オーダーと呼ばれるものには、例えばどんな種類があるだろうか。ちょっと思いつく端から並べてみても、

受注オーダー(セールスオーダー)、生産オーダー、製造オーダー(製造指図)、入庫オーダー、出庫オーダー、出荷オーダー、輸送オーダー、在庫転送オーダー、購買オーダー、サービスオーダー、メンテナンス(保全)オーダー、チェンジオーダー、内部オーダー・・

まぁ、軽く1ダースぐらいは思いつく。どれもそれぞれが別の業務に結びついている。では、これらに何か共通のことがあるのだろうか。 もちろん、あるから、ここに並んでいるのだ。

オーダーとは原則として、異なる企業や部門組織(コスト管理の単位となる部署)の間で、正式な注文依頼を伝えるものである。オーダーを受けた側は、それに応じて何らかのマテリアル(資材)やサービス(役務)の提供を行う必要がある。すなわち、コストが発生する。


オーダー情報の構造と機能

だからオーダー情報においては、金額以外に、普通は提供すべきモノやサービスの種類・数量と、期限(モノを納める場合は納期)や期間(サービス役務を提供する場合)を指定する。一つのオーダーで複数のモノやサービスを指定する場合も多いので、それらは「オーダー明細」などと呼ばれる(IT的な用語では、明細行はオーダーのサブテーブルになる)。

ちなみに企業間のオーダー、すなわち「発注」では、発生するコストに見合う対価が、オーダーの中に明示される。しかし同じ企業グループ内でのオーダーでは、必ずしも明示するとは限らない(多くは金額は書かない)。でも、原価自体は発生しているし、それは集計対象となる。だから上の説明で、わざわざ「コスト管理の単位となる部署」と書いたのだ。同じ課に属する隣の同僚に、何か依頼しても、ふつうはコスト集計の単位が同じだから、オーダーとは見なさない。

したがってオーダーは、「誰から誰へ」が明確になっている必要がある。発信主体や受信対象が漠然としたオーダーはあり得ない(そんなものは注文ではなく、願望ないし要求とでも呼ぶべきである)。「どっかの会社が、○○をしてくれると良いなあ」というのは、もちろんオーダーではない。

ちなみに、オーダーを受けた側が、マテリアル(資材)やサービス(役務)を提供して、その要求を満たすことを、「フルフィルメント」Fulfillmentと呼ぶ。 日本語では発音しにくいので、めったに使われないが、英語ではよく用いる。

なお、口頭の指示でも、正式なオーダーではある(実務的にも法律的にも)。 あなたが八百屋に行って、「その大根1本ちょうだい」と口頭で注文したら、ちゃんと取引は成立する。だが業務設計の文脈でいうときには、電子データか、少なくとも紙に書いた状態のものを意味する。 だから、業務システムの文脈で、よく「オーダー」が問題になるのだ。


オーダーのステータス(状態遷移)とは


オーダーには、そのライフサイクルにそっていくつかのステージがある。(1)最初は、計画段階(Planned/Created)である。(2)次に、発行済み(Committed/Released)段階になる。(3)そして遂行を経て完了(Closed/Completed)段階に達する。(4)ただし、重要な例外として、キャンセル(Canceled)段階もありうる。これらに応じて、Planned order, Committed order等と呼ぶ。ただし、この4種類がいわば代表的ステータスだが、 用途に応じて、もっと細かく分けることも珍しくは無い。



なお上の説明(1)では、最初にオーダーがいきなり生成されると書いたが、じつはその前に「要求」(Request)が出され、それが承認されて「発注」(Order)になる、というプロセスの場合もある。 例えば、業務部門が調達要求(Purchase request)を 調達部門ないし経理部門に出し、 それが正式に承認されると、サプライヤーに対する発注オーダーになると言う手順である。

似たようなプロセスとして、チェンジオーダー(変更指示)がある。 システム開発のSIプロジェクトのように、請負契約での遂行では、当初決めた仕様に対して金額を提示し契約するわけだが、途中でしばしば、設計変更が必要になる。 これに伴って、当然ながら必要な作業工数が変わり、数量も変わったりして、金額や納期の変更が必要になる。

この時、欧米系など、海外の顧客との契約ではしばしば、受注側がまず変更要求(Change request)を 作成し提出する。そして説明・交渉を経て、発注側がそれを承認し、 正式な変更指示(Change order)になる、 と言う手続きを踏む。日本国内では契約意識がもやっとして柔らかいためか、あまりこの方式はポピュラーでないように感じる。いや、場合によっては、どんな変更が生じようと、一切金額変更には応じないと言う姿勢の企業も、ときに見かけたりする(笑)。


生産オーダーと製造指図の関係

ところで、オーダーに関してやっかいな点は、日本の製造業での用語が定まっていないことである。オーダー、指図、指示、指令・・業界により会社により、バラバラである。こうした用語や概念は、本来はアカデミアが主導して共通化すべきだと思うのだが、なぜかそうした動きは鈍い。

生産に関連するオーダーの名称として、おそらく一番広く使われているのは「製造指図」だろう。たとえば医薬品業界では、GMP省令で「製造指図書」という文書が規定されているため、業界の企業は(そしてMESベンダーも)みな、この用語に従っている。しかし、他の業界で従う動きはない。

ちなみに、わたしのこのサイトでは、原則として、
「生産オーダー」=製品単位の指示(通常は本社計画部門→工場)
「製造オーダー」=部品・工程単位の指示(通常は生産管理部門→製造現場)
という意味で区別し、使ってきた。上記のGMP用語でいえば、製造指図がおおむね、製造オーダーに相当する。当然、[生産オーダー] ⊇ [製造オーダー] 、であり、前者が上位概念である。

しかし、この用語はSAPの中では違っていて、「製造オーダー」が上位概念、「生産オーダー」が下位概念になっている。しかも下位概念の方は、ディスクリート(組立加工系)では生産オーダーProduction order、プロセス系ではプロセスオーダーProcess orderという2種類の、データ構造が異なるオーダーとして区別される。ただ、SAPコンサルタントでさえ、しばしば両者を混同して使ったりしている。おまけに日本では、SAP社の用語概念を教科書ないし神の言葉みたいに思い込んで言いふらす、そそっかしい人びとまでいて、混乱はますます助長されていくばかりである。


計画、指示、命令

話を戻そう。オーダーと計画は、同じ概念か、違うものなのか。

計画とは、簡単に言うと、「なすべきアクションの集合体」である。その一部分は、すでに実行され、あるいは完了しているかもしれない。ともあれ、それぞれの「アクション」は、それを誰か他人・他部署・他社にやってもらうときに、「オーダー」として伝える必要がある。相手はそのオーダーを「フルフィルメント」することで、当方の計画の一部を満たしてくれる。

さて、そのようなアクションとは「命令」だろうか? 命令と言うと、業務命令のような言葉を思い出す。上司が部下に明日は休日出勤することと伝えるようなのが命令だ。命令とは、通常、強制力を伴う。命令に反したときに、脱したり、査定を下げたりする 権限を、こちらが公式に持っているときに「命令」と言える。では、あなたが隣の部署や、サプライヤーに何らかのアクションをしてもらう時、それは命令だろうか? 明らかに、オーダーは命令とは違う概念だと分かる。

ただし、「省令」は英語では、Ministerial Ordinanceと呼ぶ。Ordinanceは、Orderの派生語だが、細則という位置づけで、少しおとなしい。これが政令になると、Cabinet Orderになり、強制力が増す。「大統領令」などもExecutive Orderで、オーダーと呼ばれる。政治や司法の世界では、オーダーは強い権限を持った命令になる(ああ、面倒)。

ともあれ、いわゆる業務プロセスの設計や、業務系ITシステムの要件定義では、オーダーとは計画でもなく命令でもなく、部署・企業間で伝達されるトランザクション・データの一種である。それはステータスを持ち、業務プロセスに従ってフルフィルメントされる。そして原価や対価のやりとりが通常は付随する、と。

といったことは、もちろん今どき、生成AIに聞けば要領よく答えてくれるだろう。ただ、その意義は、適切に聞かないと答えてくれない。意義とは、周縁や文脈との関係で存在する。計画や命令との違い、業務用語と政治用語の違い、世の中の語法のブレ、などを理解して、はじめてまともな設計と議論ができるようになる。だから、このようなブログ記事を提供することにも、まだ多少の意味があるのだと思っている。


<関連エントリ>
「オーダーとはいったい何か」 https://mgt-technology.info/?p=402 (2017-04-15)
「良い設計者はなぜ、他部門の知識を広く求めるのか」 https://mgt-technology.info/?p=3864 (2025-12-04)