生産計画とスケジューリングの用語集

生産管理の用語は用法・定義が定まっていないものが多く、また実務の世界と学問の世界で意味の異なるものも少なくありません。ここでは、筆者が拙著「革新的生産スケジューリング入門」「BOM/部品表入門」で用いた語義・用法をベースに記載しております。これが唯一無二の正当な用語と主張するつもりは全くありません。しかし、語彙の間では互いに一貫した整合性のある意味参照関係となるよう留意しているつもりです。

英文字略語はABC順、日本語は50音順でならべてあります。同義の言葉があればそれを見出しの下に併記し、また対応する英語がある場合はそれを記してあります。第何章第何節、とあるのは、拙著「革新的生産スケジューリング入門」「BOM/部品表入門」でそれを解説している箇所ですので、参考までにご利用ください。


[目次]


A−N



APS
革新的生産スケジューラ
Advanced Planning and Scheduling
「革新的生産スケジューリング入門」第5章

MRPの限界を打破した、より現実的で精度の高い生産計画・スケジューリング手法の総称。あるいは、それを実現するためのソフトウェアを指す。厳密な定義はないが、MRPの無限負荷計画よりもリアルで柔軟な制約条件を入れてスケジューリングできるものをAPSとよぶ事が多い。

筆者も理事を務めるNPO法人「ものづくりAPS推進機構」では、『ホワイトペーパー:APSの基本アーキテクチャーとシステム実装技術』(2004年12月)で、APSを次のように定義している。

「APSとは,プランニングやスケジューリングなどの組織の意思決定の要素を統合させ,さらに各部門が組織間や企業間の枠を超えて同期をとりあいながら自律的に全体最適を志向するしくみのことである.APSは,もともと米国にて1990 年代に提案されたコンセプトであり,拡張された詳細スケジューリング技術によって,企業間のサプライチェーンマネジメントを含む,製造業の全体最適化を指向したものであった.」

もっとも、この説明だけでは抽象的でいささかわかりにくい。もう少し今日的な言い方をするならば、APSとはERPのもつ計画機能の弱さを補完するものだ。ERPパッケージを生産管理分野に導入する企業は、APSとよばれる外部モジュールを追加し、両者を組み合わせて使うケースが増えている。ERPパッケージのほとんどはMRPUをベースとしたスケジューリング機能を持っているのに、なぜそれだけでは足りないのだろうか?

MRPのスケジューリングは、必要な資材を必要なときに必要な量だけ供給する、ジャスト・イン・タイムのロジックで動く。それは在庫ミニマムのリーン生産を実現する『最適スケジュール』を作成できるはずである。しかしMRPの解は、工場が無限に生産能力をもつことを前提として計算される。つまり、最適であるかもしれないが、実行不可能な絵に描いた餅のスケジュールになるケースが多々あった。

CRPクローズド・ループMRPを上手に運用すれば、この欠点はある程度解消できるが、それでもまだ深刻な弱点が三つほど残る。

(1)能力以外の制約条件の考慮ができない。
 現実の工場の生産スケジューリングには、多数の制約条件が存在する。たとえば治工具・金型の数の制約とか、中断不可能な作業の存在(複数日にまたがったスケジュールが許されない)とか、設備能力はあっても多能工作業員が足りない、などの制約である。こうしたケースでは標準リードタイムと標準能力の設定だけではうまくモデル化できない。

(2)生産効率の視点からの最適化ができない。
 たとえば、代替部品や代替工程が複数存在する場合に、どちらを選ぶべきかの判断は、MRPでは自動化できない。あるいは、段取り替え作業に順序依存性がある場合(たとえば色の薄いものから濃いものへの切替時間は短いが、その逆は長い、など)に、適当に色の濃さを合わせて、順序づけて流す、などの工夫ができない。MRPにあるのは、在庫ミニマムという最適化だけである。

(3)工程レベルでの納期回答ができない。
 MRPIIでは、MPSATPによる製品レベルでの納期回答は可能である。しかし、飛び込みや急な変更、資材の遅延などにともなう納期照会に対しては、製造工程レベルで納期を追う必要がある。しかしMRPでは個別ロットと生産オーダーの対応関係(ペギング情報)が保存できないため、精確な納期回答が困難である。

そして、さらに大きな問題として、クローズドループMRPでは計画立案のサイクルタイムが長くなりすぎる点を上げなければならない。市場環境の変化が急速になった今日、週単位で計画をまわしていくことが望まれる。しかしMRP←→CRPの手戻りのため、計画の立案から確定までへたをすると3,4日かかってしまう。

こうした問題点を解決するために、高速かつ柔軟なモデル化能力を備えたAPSが登場したのである。

APSはふつう、ERPなど生産管理の実行系システムから、需要オーダー・在庫量などのデータを各種マスタデータとともにダウンロードする。そしてデータの整合性をチェックした後、スケジューリング計算に用いる。スケジューリングでは、需要オーダーをもとに部品展開をして、優先度とロットまとめを考えながら在庫の引当計算を行ない、個別工程における製造オーダーを作成する。そして着手日の計算と、能力の負荷山積みを行なう。

ここまでの手順は、MRPとよく似ている。ただしAPSでは『タイム・バケットを単位とした標準リードタイム』の考え方をとらず、作業時間を直接、個別に計算する。

 作業時間=製造オーダーの所要量/割りつけた生産資源の処理能力+前後の段取り時間

作業の着手日計算は、納期から逆算するバックワード・スケジューリングで行なう。しかし資材などがネックになる場合は、納入を起点としたフォワード・スケジューリングをする。

この時点で得られているスケジュールは、まだ能力制約を満たしていない。そこでAPSは、高速で自動的に山崩しをして実行可能解を作成する。また代替部品や代替工順などの選定もこの中で行なわれる。このロジックの高速性が、APSの競争力のポイントである。

こうして得られたスケジュールを、APSはガント・チャートなどの形で計画者に対し出力表示する。スケジュールは、必ず人間の目で評価しなければならない。納期遅れが生じている場合、どれを優先し、どれを後回しにすべきか、あるいは加工外注でしのげるかなど、判断を機械まかせにすべきでない事柄が残っているからである。そして、GUIによって手で修正したり、あるいは条件を変えてケーススタディを行なったりといった作業を経て、はじめてスケジュールが確定する。

確定スケジュールは、製造部門に対して開示され、直近に着手すべき製造オーダーがディスパッチされる(つまり製造指図が差し立てられる)。そして、スケジュールファイルとして保存され、納期回答や次回のスケジュール立案のベースとして、利用されるのである。

ものづくりAPS推進機構のホワイトペーパーでは、APSの主要な要素技術として以下の事項をあげている。
・作業中心のBOMデータ管理(内部に工順を持つ)
・生産現場の詳細なモデリング
・有限能力&有限資材スケジューリング
・ボトルネック指向スケジューリング
・MPS詳細シミュレーション
・ダイナミック・フルペギング
・メタヒューリスティックによる最適化

これらは、どちらかというと内部機能的な観点のリストである。私は、これとは別に、「APS導入を考えるユーザがベンダーに聞くべき10の質問」として、以下の問いをあげたいと考えている。

(1)この製品は生産計画もできますか、それともスケジューラ機能だけですか
(2)この製品はBTOに対応できますか
(3)この製品は複数工場のスケジューリングができますか
(4)BOMの切替えや代替にはどのように対応しますか
(5)リソースにはどんな種類がありますか
(6)工順や設備・ライン・作業の選択は、どのような判断基準で行いますか
(7)ローリング・スケジュールのタイム・フェンスはどう設定できますか
(8)リモート・バッチで納期照会が可能ですか
(9)MESから進捗情報をとりこむ機能がありますか
(10)最適化機能のチューニング・ツールはそろっていますか?

念のためいうが、これらすべてが必須項目だという訳ではない。ただ、これらの質問に、ベンダーが的確に答えられなかったら、ちょっと心配だから誰かコンサルタントに相談されるといいと思う。そして、これらの質問の意味がユーザ側にとって半分以上わからなかったら・・もしかしたら、まだAPSの導入は早すぎるのかもしれない。



ATP
納期回答 / 販売枠管理
Available To Promise
「革新的生産スケジューリング入門」第3章講義13

基準生産計画(MPS)をもとにした計画供給量の累積線と、確定需要量の累積線の差。一種の計画上の在庫量で、まだ未確定だけれども販売が「約束可能な量」ということになる。これをATPと呼ぶ。


BOD
Bill of Distribution
「革新的生産スケジューリング入門」第4章講義1.5

流通資源計画(DRP)でつくる、MRPによく似た構造型の部品表。
BODの中には、品目の名称、員数、および製造・梱包・輸送などにかかわる標準リードタイム、といった情報が記述される。



BOM
部品表
Bill Of Materials
「革新的生産スケジューリング入門」第2章講義1
「BOM/部品表入門」第1章〜第12章

BOMとはBill Of Materialsの略、日本語では『部品表』とよばれる概念であり、製造業においては、生産管理とスケジューリングの中核に位置するデータである。BOMではなく、B/Mと略す会社もある。

BOMについては、私はまるまる1冊の本を書いた(『BOM/部品表入門』日本能率協会マネジメントセンター、2005/4刊)。それくらい、BOMについてはさまざまな視点から多面的にとらえて理解するべきポイントが多い。しかし、その内容をあえて一言でいえば、

 「BOMとはマテリアル間の数量的な関係を示した一覧表である」

と総括することができる。ちなみに、英語のbillとは、明細書ないし一覧表の意味である。英語圏を旅行した方は、レストランでウェイトレスが各テーブルに裏返して置いていく勘定書伝票もbillとよぶのをご存じだろう。あれは料理というモノの名前と数量が、勘定書として特定のテーブルに関係づけられている、一覧表だ。したがって、あれは立派なBOMであるといっていい。

製造業では一般に、BOMは製品がどの部品いくつから構成されるかの関係を示すのに使われる。だから部品表というのだが、ならばなぜ、私は上に述べたような「マテリアル間の数量的関係」云々と回りくどい表現を使うのか?

それは、「部品」という日本語の守備範囲の狭さに起因している。BOMはあるけれども部品表を持たない業界が存在する、といったたら、読者は信じられるだろうか? しかし、あるのだ。製鉄・化学・医薬品・化粧品・食品・飲料・ガラス・プラスチック成形・金属材料・繊維・アパレル・出版・・・等々、非常にたくさんの業界が、「部品表」という言葉を使わない。なぜなら、こうした分野では、製造に原料・材料・素材はあれど、『部品』という概念がないからだ。

英語でマテリアルMaterialとは、部品だけでなく、素材・原料・材料・資材・中間品・アセンブリ、そして製品までのすべてを包含する用語である。決して部品(英語ならparts)のリストではないのである。ちなみに、製品か部品かのちがいは、BOMの観点からは相対的なものでしかない。

BOMとは定型化されたデータの集合であり、コンピュータ内ではデータベースに格納されることが多い。BOMデータベースの中には、マテリアルのコード、員数、製造の各段階に必要な工順リソース(資源)と標準リードタイム、といった属性情報が記述される。表現としては構造型・サマリー型・マトリクス型などがある。

BOMのデータ形式と内容は、MRPの発展とともに拡充されてきた。とくに、MRPU以降では、工順・リソースなどのデータ項目が重要視されるようになってきた。

BOMはまた、マテリアル・マネジメントの中心に位置するデータでもある。今日の製造業におけるマテリアル・マネジメントの課題は、「モノはたくさんあるのに、必要なモノが見つからない」という悩みである。この問題の改革の視点から考えるならば、BOMを単なる部品表(マテリアル・リスト)以上の、大きな概念としてとらえるべきである。すなわち、BOMの概念には「狭義のBOM」と「広義のBOM」があるのだ。

広義のBOMとは何かというと、「マテリアル・マスタを中心とした製品構成と製造工程にかんする基準情報、ならびに、そこから派生する履歴情報」と定義できる。狭義のBOMに加えて、マテリアル自体のマスタや、工順(工程表)のマスタ、設計図面、製造指図や製造実績報告などの履歴情報などの要素からなる、マテリアルに関連する大きな情報の体系を指している。

これに対し狭義のBOMとは、マテリアルの数量的な関係を示した一覧表、という上記の定義でしめされる。それは製品と部品の関係を示す表でもありうるし、1卓の顧客の消費によって一時的に関係づけられ払出されたレストランの勘定書でもありうる。倉庫で使用するピッキング・リストも、構造的には同じである。

企業の中には、用途に応じて、さまざまなBOMのデータと、表現型がある。それらはことなる運用の局面とライフサイクルがあるから、すべてを一元化する必要は、かならずしも無い。しかし、BOMが多様化しすぎてコントロールを失い、相互に矛盾したデータの集合となってしまう事例も多い。その結果生じるのは、在庫の混乱、製品開発の遅延、購買の無駄、製造納期遅れと欠品といった現象である。マテリアル・マネジメントを実践するためには、BOMの理解とコントロールが不可欠なのである。



BOQ
Bill of Quantities

BOQとは、タスクの作業量をあらわす指標を指す。この用語には、まだ確たる訳語がない。強いて訳せば「作業量表」ということになりそうだが、エンジニアリング業界などではすでにそのまま3文字略語として、あるいは「B/Q」の2文字略語として流通しており、訳語の定着しないままつかわれる言葉の一つになる公算大である。

BOQは製品の原価企画ならびに生産計画において重要となる概念である。周知の通り、製造原価とは「材料費」「人件費(労務費)」「経費」の三つの部分からなっている。このうち、外部から購入する材料費の推算については、BOM(部品表)が基礎データとなる。製品をBOMに展開すれば、各部品(マテリアル)の所要量がわかるから、それに標準単価をかけて合計したものが、その製品の材料費になる。

それでは材料費とならんで原価の柱となる人件費は、どう推算すべきか? これは業種および生産方式によって異なる。たとえば化学産業のようにプロセス生産方式をとる業種では、基本的にオペレーターの数は、製品種別ではなく装置ライン構成に応じて決まる。個別のどの製品について何時間働いたか、というような集計はしにくい。したがって、総生産量の中の比率によって、固定した人件費を配賦することになる。

また自動車部品業界や電子部品業界のように、量産性の強い組立加工生産方式をとる分野では、生産量は製造ラインのサイクルタイムやタクトタイムによってきまる。このタクトタイムは、労働者の行う「繰返し動作」の数や種類に密接に関わっている。右腕を伸ばして部品を1個とる→横に1ステップ移動→左手でボルトをはめ込む→目視確認→・・・といった具合だ。それぞれの単位動作について、何秒かかるかがわかれば、1サイクルの作業時間がわかる。こうしたことを研究し改善するのが、IE(インダストリアル・エンジニアリング)分野におけるタイム・スタディであり、また生産スケジューリングも、工程の標準作業時間をマスタとして計算することができる。。

ところが、製品により個別性の強い業種では、こうはいかない。たとえば造船・航空機・産業機械といった産業である。また、建設業も、現場組立を行う一種の巨大組立加工生産だと考えることができる。こうした製造の現場では、サイクルの閉じた繰返し動作ばかりではない。そもそも、個別受注生産が主であるため、製品ごとの標準構成を決めることが難しい。では、原価推算や生産スケジューリングはどう行ったらよいのか?

そこで登場するのがBOQの概念である。BOQとは、労働時間を左右する作業量の指標である。たとえば、ある程度の量の金属配管を溶接する作業を考えると、溶接箇所や配管径など個別に見れば様々だが、全体の直接工の労働時間は、ほぼ溶接長さの合計に比例することがわかっている。そこで、配管溶接作業では溶接長がBOQの単位となる。配管製作図が決まれば、溶接箇所と径を拾い出して表とし、BOQ合計を算出することができる(溶接長合計は、配管材料の材料費には必ずしも比例しないことに注意してほしい)。

あるいは、電源ケーブル敷設の作業であれば、レイアウトがどうこみいっていようと、直接労働時間はケーブル長の合計にほぼ比例する。すなわち、ケーブル長がBOQの単位である。そこでレイアウト図からBOQ合計を求めれば、作業に必要な労働時間が次の式で計算できる。

「直接工の作業時間」=「BOQ」×「単位BOQあたりの作業時間」=「BOQ」÷「生産性」
「タスクの所要期間」=「直接工の作業時間」÷「投入人数」

BOQという概念は、19世紀末に英国で開発されたと言われている。そして、長らく建設業の世界で用いられてきた。しかし、あいにく日本の生産管理では、材料費としての物量と、作業量としてのBOQを区別して用いる習慣がうすい(モノと労働が一体に扱われている)。そのため、いったん生産方式が量産的な枠組みをはみ出すと、うまく製造原価がつかめなくなる現象が生じがちである。

今後、多くの製造業では、総合原価から個別原価へ、そして製品群単位の採算性に注目するPLM(Product Lifecycle Management)の思想が広まっていくと思われる。またこれと平行して、情報システム産業では、期間と進捗にもとづく進行基準原価管理が求められつつある。このような時代において、BOQの概念の重要性はこれからますます高まっていくと考えられる。



CAO
Constraint Anchored Optimization
「革新的生産スケジューリング入門」第5章講義2.3

RHYTHM Factory Plannerのもっとも特徴ある機能で、スケジューリングにおいて能力その他の制約に関する問題を山崩しによって平準化し解決する。この平準化において、TOC理論にしたがった戦略をもちいる。



CCR
Capacity Critical Resource
「革新的生産スケジューリング入門」第5章講義11

TOC理論でのボトルネック工程はプロダクトミックスの中で考えなければならない。工場全体の中で最も負荷のかかりやすい工程をCCRとよぶ。



CPM
Critical Path Method
「革新的生産スケジューリング入門」第2章講義6

最小の費用投下でプロジェクトの総期間を短くするためには、どのタスクとどのタスクに費用を投入すべきかを考える手法。



CRP
能力所要量計画
Capacity Requirement Planning
「革新的生産スケジューリング入門」第3章講義9

MRPの計算の結果、ある作業区でやらなければいけない作業時間の合計が、上限を超えてしまうことがある。その場合、すべての製造オーダーをその作業区でこなすのは無理なため、山崩しを行い、作業時間の合計がそのタイム・バケットの上限に入るように調整する。この作業を、能力所要量計画(CRP)とよぶ。



DBR
Drum, Buffer, & Rope
「革新的生産スケジューリング入門」第5章講義11

TOC理論に基づき、工場のスケジューリングを行うための基本的ロジック



DRP
流通所要量計画
Distribution Requirement Planning
「革新的生産スケジューリング入門」第4章講義1.5

輸送問題に対して、MRPと同じような考え方にたち、納入先の需要を「独立需要」とし、各DCおよび工場での供給量を「従属需要」として、必要な量とタイミングを計算する手法



EOQ
経済的発注量
Economic Order Quantity
「BOM/部品表入門」第4章Q6

発注点でも説明したとおり、在庫推移を監視して必要数量を補充・維持する業務においては、消費量がほどほどで変動があまりはげしくないものには、発注点方式などの「不定期・定量発注」がむいている。これは在庫量が消費にともなって減っていき、ある一定の線(発注点)を切ったら、決まった数量を補充手配する方式である。一般に在庫数量を正確にモニタリングするのは手間のかかる仕事だが、ある一線を決めておいて、それより多いか少ないかを見るだけでいいのならば、保管現場で目印や箱を活用すれば簡単に実現できる。




EPST
最早着手日
Earliest Possible Start Time
「革新的生産スケジューリング入門」第1章講義4

もっとも早くその作業に着手できるタイミング



ERP
統合業務パッケージ
Enterprise Resource Planning
「革新的生産スケジューリング入門」第7章講義3.3

ERPとは、(元は)Enterprise Resource Planningの略で、製造業における企業全体の資源配分計画の活動を表す概念であった。しかし、今日では、実際には企業の基幹業務範囲を広くカバーする機能を持った統合パッケージ・ビジネスソフトを指す言葉となっている。具体的には、会計・財務・原価・販売・物流・購買などのビジネス系の諸機能をもち、企業の基幹業務範囲を広くカバーすることをターゲットとしている。

「ERP」という言葉をはじめて使ったのは独SAP社であると言われている。この語は、言うまでもないが'60年代に成立したMRP(Material Requirement Planning)から生まれている。MRPは元々、資材所要量計画の略だったが、それが'70年代を通じて発展し、MRPU(Manufacturing Resource Planning)という概念になった。MRPは製品の最終需要(独立需要)から、BOM(部品表)をさかのぼって各部品・中間部品レベルでの所要量を算出するロジックであった。それがMRPUでは資材のみならず、機械・労働者などのリソース、そしてそれらを準備するための購入資金まで、製造業にとって必要な広義の資源の計画ツールに発展した。

ERPとは、さらにその対象範囲を広げた、企業活動全体にとっての資源配分計画の活動である、と位置づけられている。業務パッケージソフトとしても、生産・購買のみならず、会計・販売・物流・在庫管理・倉庫・輸送・品質管理・・とそのカバー領域を広げ、いまやオフィス活動全体をほぼ網羅するようになった。

パッケージソフトのベンダーとしては、今のところドイツのSAP社(この社名はよくサップと呼ばれるが、エス・エー・ピーと発音するのが正しく、そう呼ぶことを知っているかどうかがその道のプロであるかを示す踏み絵みたいになっている)と、米国のオラクル社が二大巨頭である。10年前にはこのほかにもJDEdwadrs, PeopleSoft, BaaNその他有力な企業がいろいろあったが、ほとんどが買収・淘汰され、ビッグ2と、あとは各国ローカルの中小ベンダー、という二極分化の構図が出来上がってしまった。

ところで、「製造業における企業全体の資源配分を計画する」というのは簡単だが、実際には誰が計画するのだろうか? ある意味で“製造業は計画ありきで動く”と言ってもいい。予算があり、販売計画があり、生産計画や配員計画があって工場も営業も動く。しかし、そういった複数部門を横断して、全体を統括し計画立案すべき部署は誰なのだろうか。それは、何を基準にして動くべきなのだろうか?

それは、財務部門であるべきだ。−−これが、実はERPのテーゼである。そして、その基準としては、『原価』があり、より具体的な手法論としては、活動基準原価管理ABC=Activity-Based Costingを用いるべき、というのがSAP社の思想であった。きわめてMBA的な思考である。その結果はリアルタイムに財務諸表に表されていなければいけない、という考えから、Real Timeの頭文字を取って、製品名をR/3と名付けた。(リアルタイムというのは四半期に一度では遅すぎるという意味だ)

これはつまり、言いかえると、会社を支配するのは財務部門であるべし、という考え方である。財務部門から見て、投下するコストに対してリターンを最大化するよう、企業活動を統御すべきであり、コストに引き合わないような活動には資金というResourceは配分すべきではない。そのために、すべての活動を原価に引き戻すような還元主義的な枠組みが必要になる。これがERPであり、事実SAP R/3では、FI/COと呼ばれる会計・財務モジュールは必須の中心機能とされたのである。そして、「ERPを入れるなら、まず財務会計から」という合い言葉とともに、多くの企業に普及していったのであった。

しかし現実には、FI(会計)は使っているが、COは十分使いこなせている企業は日本では少ないと言われている。これは、原価管理が、配賦基準という形の「企業を動かすためのルール・思想」をベースにしているためであろう。何をのばし、何をおさえるかは、どのようなモノサシ(原価基準)をあてがうかによって決まる。これはつまり、そうした管理会計的なルール・思想をもつ企業が少ない、という現実を示しているのだ。

会計は、ある意味で法律上課せられている義務である。しかし、原価管理はちがう。原価計算報告は求められるが、その結果を経営判断に活かすことまでは法律では定められていない。そもそも、「ちゃんとマネジメントをしろ」などということは、法律にはどこにも書いていないのである。そして、別段プランニングだのマネジメントだのという七面倒なことを考えなくったって、当面企業は動いていく。そこで、残念ながら多くの日本企業では、原価基準は(たとえどれだけ財務部門の担当者レベルでは積極的な意見が出されようとも)経営に活かすべき思想のないまま決められてしまい、思想のないまま運営され続けるという現実が生じているようである。

製造に関して言えば、MRPもまた日本の融通無碍な(いいかえれば計画軽視の)製造現場には四角四面で使いづらい道具である。したがって、これを活かすとしたら、APSのようなフレキシブルな計画・スケジューリングのツールを補助的に使うことが求められる。

唯一、安心なのは販売・物流系であろうか。たしかに販売系はリベートその他、複雑な商慣習をフォローする必要はあるが、しょせん計画など誰も真面目にとりあわずとも済む業務である。受注トランザクションを、正確に処理してくれればいい、と皆が思っている。データさえ残れば、いつか誰かが分析してくれるだろう。ということで、ERPを作り上げた欧米の人々の高邁な理想とは裏腹に、我が国ではERPは日々の事務処理をつかさどるためのシステムとして使われているのである。

もしもこのような「仏作って魂入れず」の状態を避けて、高価なERP(ビッグ2の製品を全社レベルで導入したら数十億は覚悟すべきだ)を活かしたいと願うなら、何よりも『製造業』の『資源』を『計画する』というのは、具体的にどのような状態を目指しているのか、まず経営者レベルで明確にする必要があるのである。



FP
Factory Planner
(i2 Technologies社の製品名称)
「革新的生産スケジューリング入門」第5章講義1

i2 Technologies社のSCMソフト「RHYTHM」の中核となる工場スケジューリングのモジュールで、現代における代表的なAPS



LP
線形計画法
Linear Programming
「革新的生産スケジューリング入門」第4章講義1.4

政策変数が正の値をとる変数で、かつ
 ・目的関数
 ・制約条件
のいずれもが、政策変数の一次式だけであらわされるような最大値問題の解法



LPST
最遅着手日
Latest Possible Start Time

「革新的生産スケジューリング入門」第1章講義4
(納期から逆算して)もっとも遅くその作業に着手してよいタイミング



MES
製造実行システム
Manufacturing Execution System
「革新的生産スケジューリング入門」第7章講義3.3
「BOM/部品表入門」第6章Q2

MESはManufacturing Execution Systemの略で、IT業界に多い3文字略語の一つである。日本語では『製造実行システム』という訳語が当てられているが、実際にはMESという呼び方をされることが多い(なお、英語の発音はエム・イー・エスと読む方が正しく、“メス”という読み方では通用しにくいので注意)。かつ、製造実行システムという訳語はかなり無理して言葉をあてた感じが強く、製造業の現実においては『製造管理システム』ないし『工程管理システム』などと呼んだ方が分かりやすいだろう。

MESという用語は、ある意味、製造業における“ミッシング・リンク”として、実態よりも後になって現れた。私は2000年に、中村実氏らとともに「MES入門」(工業調査会・刊)の共著に参加したが、執筆段階ではまだ我が国ではなじみの薄い概念だった。基幹業務システムERPは、すでに多くの人が知っていた。一方、現場の制御システムもかなり普及し発展中だった。しかし、基幹業務系と制御系を結びつける働きをする現場システム群は、ある程度存在感を示しつつも、確とした呼び名がないため、十分な認知を受けていなかったと言っていい。

MESの概念は、'90年代に米国の調査会社であるAMR Research社が提唱したものが原型となっている。AMR Researchは、その報告書の中で、製造業の管理レイヤーを、
(1)計画層(Planning Layer)
(2)実行層(Execution Layer)
(3)制御層(Control Layer)
の3つに分類する有名な『3層モデル』を提案した。これは現実を理解するための一種の概念モデルである。そして、これら3層をそれぞれ受け持つ仕組みとして、
(1)基幹情報システムERP(Enterprise Resource Planning)
(2)製造実行システムMES(Manufacturing Execution System)
(3)制御システムPLC(Program Logic Controler)またはDCS(Distributed Control System)
を挙げた。MES(製造実行システム)という名は、ここで初めて現れたのである。それまでは位置づけが不明確なため、CIM(Computer Integrated Manufacturing)とか現場系システムと呼ばれていたものが、ここで初めて、あるカテゴリーの商品として認知されたのである。

さて、MESの機能とは何か。これについては、標準化団体MESAのリストアップした「11の標準機能」が有名であるが、私はあえて別の説明をしたい。

企業の生産活動においては常に指示と報告という2つの情報の流れがいきかっている。指示情報はこれからすべき仕事についての上からの流れであり、報告情報は今なされたことについての下からの流れである。一方、企業活動にはPlan-Do-See=計画・実行・評価という管理のサイクルがある。Doの部分は好みによっては制御に置き換えてもいい。すなわち、計画を実行につなげるための情報が指示情報であり、また実行を評価に戻すための情報が報告情報(進捗情報)であると考えることができる。
(以下の図は等幅フォントで見てください)

      +-----------------------+
管理者   | 計画     評価  |
(本社)   +-----------------------+
        |        ^
        |        |
      指示情報     報告情報
        |        |
        v        |
      +-----------------------+
実行者   |    実行(制御)  |
(工場)   +-----------------------+

ところが、工場の中にも管理者とショップフロアの実行責任者がおり、両者の間で同じような計画・実行・評価というサイクルが成り立っていることがわかる。スケールダウンされた相似形、いわばネストをなしているわけだ。

      +-----------------------+
管理者   | 計画     評価  |
(本社)   +-----------------------+
        |        ^
        |        |
      指示情報     報告情報
        |        |
        v        |
      +-----------------------+
工場    |      実行    |
管理者   |  (計画   評価) |
      +-----------------------+
          |     ^
          |     |
        指示情報  報告情報
          |     |
          v     |
      +-----------------------+
実行者   |    実行(制御)  |
(ショップ) +-----------------------+
本社から見ると工場管理者(工場のホワイトカラー層)が工場を代表して実行しているように見える。だが、実際には工場管理者は計画と評価を行い、ショップフロアの実行責任者が製造実施しているわけである。本社からの指示情報は、工場管理者の計画作業を通して初めて、より詳細なショップフロアへの指示情報になる。同様にショップからの報告情報は、工場の他の報告情報と総合され、管理者の評価作業を経て初めて本社に対する報告情報になる。 本社と工場管理者のふたつの管理サイクルの違いは、時間刻みの違い、すなわち管理対象のもつ時定数の違いである。

このように考えてみると、MESとは工場管理者レベルの業務を支援するためのシステムだ、と考える方が真実に近いだろう。

そして、これがゆえにMESにまつわる困った事情も生まれてくる。困った事情とは、すなわち、システムとしてのMESの導入やお守りをする部署が定まらないという問題である。本社の情報システム部門は、そんな製造現場の、機械油にまみれたような泥臭いシステムには手を出したくない。かといって工場に情報部門を持つ企業は少ない。いきおい、生産技術部とか製造部とかが片手間で運用する、ということになりがちなのである。

そもそもMESが生まれてきた背景には、製造機械のインテリジェント化がある。機械加工の自働化といえば古くからNCなどがあったが、それ以外の加工装置類もシーケンサーの発達のおかげで、それなりに柔軟な制御ロジックならびに通信インタフェースを持ちうるようになってきた。そこで、それまでは点状に孤立した機械群から成り立っていた工場のショップフロアを、協調し制御できる技術基盤ができてきたのである。もっともこれはディスクリート産業の話で、プロセス産業ではすでに'80年代後半からDCSによる集中制御が当たり前となっていた。

また、加工装置中心のライン生産とは異なる、人間による組立生産工程においても、中間部品やワークをバーコード/RFIDでリアルタイムに追いかけていく、POP(Point of Production)と呼ばれるシステムが広まってきた。さらに、上位からきた生産指示情報(最終製品レベルでの生産オーダー)をショップへの製造指示情報(部品・材料レベル+工程レベルでの製造指図)にかみ砕くための仕組みである工場スケジューラも普及してきた。

こうした流れが一つに合わさって、MESというシステム群が生まれたのである。ただし、製造現場というものは個別性が強い。また、ディスクリート型生産とプロセス型生産の間には、非常に大きなギャップがある。こうした個別性の壁があるため、MESはどの産業にもフィットするような、強力な汎用型パッケージ商品があらわれにくいという特性がある。今後も、製造現場のさらなる付加価値生産性向上をねらうためには、工場管理者レベルでの合理化は避けて通れない。従来の枠組みをこえた、次世代のMESが期待されるゆえんである。



MPS
基準生産計画
Master Production Schedule
「革新的生産スケジューリング入門」第3章講義12

計画需要量と、手元の引き当て可能な製品在庫ならびに安全在庫量からかんがみて、(かつ複数の工場がある場合には、どの工場で生産を担当すべきかも考慮の上で)、計画上の必要生産量を定めたもの。
MPSは「生産オーダー」から構成され、MRP(資材所要量計算)のベースであり、スケジューリングの第一ステップとなる。



MRP
資材所要量計画
Material Requirement Planning
「革新的生産スケジューリング入門」第3章講義3
「BOM/部品表入門」第3章Q1

MRPとはMaterial Requirement Planningの略で、1960年代にアメリカで生まれた計画手法である。日本語では『資材所要量計画』と訳される。BOM(部品表)と標準リードタイムを元に、工場内のすべての従属需要の量と時期を、独立需要から計算するために開発された手法である。最近の欧米系有力ERPパッケージのほとんどは、MRPの考え方をもとに生産管理機能を実装している。

生産計画で重要な概念に、資材の「所要量」がある。ある時点に必要なモノの数量のことで、これには総所要量と正味所要量がある。

 正味所要量=総所要量−引当可能在庫量

いま、再来月の月末までに製品Sを150個出荷する注文をうけたとしよう。このとき総所要量は150である。製品Sは現在、工場倉庫にすでに70個積み上がっている。ただし今月中に、20個は出荷する予定がすでに決まっているとする。すると、今月末の引当可能な在庫量は、70−20=50個となるわけだ(安全在庫量の考慮は省略)。このとき正味所要量は、150−50=100個だから、製品Sを再来月末までにあと100個作る必要がある。つまり、製品の正味所要量とは、生産の指示(生産オーダー)と同じ意義を持つ。

さて、MRPではBOM(部品表)を中心にして、製品の総所要量(これを独立需要とよぶ)から部品の正味所要量(これを従属需要とよぶ)をもとめる。

製品Sの部品構成はつぎのとおりだ。Sは「部品X」1個と「部品Y」1個から組み立てられる。部品Xを作るためには、材料Zが2個と材料Wが1枚ずつ必要だ。部品Yは、側板4枚と背板1枚から作る。材料Wと部品Yはすべて同じ材料Vからつくられる。

これを「構造型部品表」(ストラクチャー型BOM)で表現すると、次のようになる(等幅フォントで見てください)。

製品S━┳━(1)部品X━┳━材料Z(2)
    ┃        ┗━材料W(1)━━━材料V(1)
    ┃
    ┗━(1)部品Y━━━材料V(5)

カッコ内に入っている数字は、親品目(自分から見て左側にある品目)1単位を作るのに必要な数量である。これを員数ともよぶ。

さて、これから何がわかるだろうか。製品S=100個の独立需要に対して、部品X・Yの従属需要が同じく100個ずつ、材料Zが200個、材料Wが100枚、そして材料Vが合計600枚(部品W用100枚・部品Y用500枚)となることが計算できる。

いま部品Xのストックが60個、部品Yのストックが80個あるとすると、
 
 部品Xの正味所要量 = 100 −60 = 40(個)
 部品Yの正味所要量 = 100 −80 = 20(個)

ということになる。そして、その下の材料のレベルで、材料Zが10個、材料Wが50枚、材料Vが60枚あったとすると、材料Zの正味所要量は以下のような計算になる。
 
 材料Zの正味所要量 =(部品Xの正味所要量)×(部品Xあたりの材料Zの員数)−(材料Zの在庫量) = 40×2 − 10 = 70(個)
 材料Wの正味所要量 = 40×1 − 50 = −10(個)

ということは、実際にはストックですべてまかなってしまうから、正味所要量はゼロになる。最後に、材料Vの正味所要量 = 20×5 − 60 = 40(個)だ。

これで、すべての工程や購買先に対する手配数量がきまる。このような計算を<部品展開>と呼ぶ。この計算自体は、かけ算と引き算だけの単純なものだが、製品や部品の数が多い場合はとうぜん計算機が必要になる。

なお、客先需要に基づく「需要オーダー」から製品在庫を引き当てた結果(=正味所要量)は、工場に対する「生産オーダー」になる。また、生産オーダーから部品展開をおこなってもとめた内製部品の正味所要量が、その部品の「製造オーダー」であり、購買品の正味所要量が「購買オーダー」だ。

さて、ここまではもっぱら数量の話だけだ。MRPが手配数量の計画手法からスケジューリング手法へと発展してゆくのは、ここに標準リードタイムの概念が持ち込まれてからのことである。標準リードタイムとは、各工程で必要とされる作業期間で、部品の加工種類ごとに決める。

製品Sの例では次のように仮定しよう。

 ・最終組み立て・検査のリードタイム=6週間、
 ・部品Xを材料Zと材料Wから作るリードタイム=2週間、
 ・部品Yを材料Vから作るリードタイム=2週間、
 ・材料Wを材料Vから作るリードタイム=2週間

MRPでは、正味所要量の部品展開を行うときに、標準リードタイムをもちいて、必要な時期を納期からさかのぼって計算する(LPST)。これによって、どの工程の作業を・いつ・どれだけの量やらなければいけないかが、正確にきまるのである。

上記の例でいくと、製品Sの最終納期がもし3ヶ月後だとすると、
 
 製品S 正味所要量=80(個) 必要時期=12(週)
 部品X 正味所要量=40(個) 必要時期=12−6=6(週)
 部品Yの正味所要量=20(個) 必要時期=12−6=6(週)
 材料Zの正味所要量=70(個) 必要時期=6−2=4(週)
 材料Wの正味所要量= 0(個) 必要時期=なし
 材料Vの正味所要量=40(個) 必要時期=6−2=4(週)

ということになる。

材料W用と部品Y用の両方を一緒にして(40+10=50枚)、2週目に必要とするのではなく、別々に、2週目に10枚、4週目に40枚を手配すべきなのだということを理解しほしい。

MRPのロジックは「必要な時期に、必要な量だけを手配する」だから、部品や材料の作りすぎ・過剰ストックはゼロになるはずだ。ある意味では非常に論理的で、欧米人には受け入れやすい手法だといえる。

MRPの計算では、時間刻みの単位を「タイム・バケット」とよぶ。これは日でも月でもいいのですが、欧米では週単位を採用している場合が多い。タイム・バケットを週単位にする場合は、納期の日が異なる複数の生産オーダーであっても、それが同じ週にはいっていれば(たとえば月曜日のオーダーも金曜日のオーダーも)、その週のオーダーとして集計する。また、製造のリードタイムが実は3日でできるものでも、標準リードタイムは1週間ということになる。その程度の目の粗さで計画をとらえているわけである。

目が粗いというのは、それだけ管理レベルが低いともいえる。が、逆にみれば、その程度の粗さをもって計画を立てれば、現実に起こる変動を吸収できるというふうに考えることもできる。3日でできるはずの工程が、機械の故障で止まってしまったとしても、故障が1日で修理できれば結局そのバケット内で完了できるわけだ。

MRPの所要量計算自体は単純で、ほとんど当たり前の理屈のように思える。しかし、この計算を正確に行なうためには、BOMがきちんと整備されており、かつ製品や部品の引当可能な在庫量が正確に把握されている必要がある。MRPの理屈は単純でも、実行は簡単でない理由は、この点にあるのである。



MRPU
製造資源計画
Manufacturing Resource Planning II
「革新的生産スケジューリング入門」第3章講義14

資材だけでなく、資金所要量計画、労働力配員計画など、生産における必要なすべての資源を計画し、ゲームプランをシミュレートするシステム



O−Z


OR
Operations Research
「革新的生産スケジューリング入門」第4章講義1

本来の意味は「作戦研究」だったが、現代では広い意味での「最適化手法の応用」としてとらえられている



PERT
Project Evaluation and Review Technique
「革新的生産スケジューリング入門」第2章講義2

数多くの作業(アクティビティ)が相互に関連しながら、ある決まった期間の中で一つの目的を達成するための仕事(「プロジェクト」)におけるスケジューリング計画手法。通常はアロー・ダイアグラムなどのグラフ的表現を用いる。



PPB法
Part-Period Balancing
「革新的生産スケジューリング入門」第6章講義3.4

MRPにおいて、資材の発注をある程度のロットにまとめておこなうための考え方。ロットまとめによるつくりだめのコストを保管費用として評価し、その保管費用が標準切替コストよりも下回るようならば、生産オーダーを一つにまとめる。



RFP
Request for Proposal

提案依頼書。調達における引合いプロセスの主要な書類で、主に受注生産品の見積依頼のために、発注者がサプライヤー候補に配信する。見積依頼書(RFQ=Request for Quotation)ともいう。調達において複数のサプライヤー候補から一社を決める際に、透明かつ公正なプロセスとなっていることを保証するために必要となる。

調達のプロセスは一般に、自分が購入したいものの種類と特性によって異なる。たとえば、
マテリアル(モノ)を買うのか、サービスを買うのか
●購入相手のサプライヤーは一社のみか、複数社あって決まっていないのか
●直接資材(製造に用いる資材)を買うのか、間接材やオフィスサプライ品を買うのか
●特定の用途に紐付いたモノを買うのか(「都度手配品」ないし「引当品」などとよばれる)、特定の用途が決まっていないストック在庫用に買うのか(「在庫品」「常備品」などとよばれる)
●自社の指定する仕様や図面で買うのか、それともサプライヤーの標準仕様品を買うのか
●購入品が見込生産なのか、受注組立生産なのか、繰返し受注生産なのか、個別受注生産(サプライヤー側の設計行為を含む)なのか

などによってかわる。むろん、上記は互いに完全に独立ではなく、依存関係がある。

とくに重要なのは、4番目(誰が仕様を決めるのか)という点である。もし買いたいモノが、売り手の商品カタログの中にあるような場合、ふつうはサプライヤー側は見込生産である(滅多にオーダーの無いような高級商品の場合は繰返し受注生産になるケースもあるが)。その場合、単に価格と在庫の有無をたずねればいいわけで、RFPのような手間をかける必要はない。たとえばUSBメモリを買いたい、という場合なら、営業マンに電話をかけるか、店に行くか、価格コムみたいなサイトで調べれば事は済む。

売り手の商品カタログに基本モデルはあるが、オプションがいろいろあって自分の希望を入れたい、という場合もある。多くは受注組立生産の品目である(PCとか自動車など)。この場合もサプライヤーは決まっているのだろうから、RFPなど必要がない。

RFPは複数のサプライヤー候補があって、自社仕様のマテリアルないしサービスを発注する際に、価格・納期・品質の観点から公正に比較して、適切なサプライヤーを選定する場合に必要となる。当然、発注先は繰返し受注生産ないし個別受注生産となる。いわゆる情報システムの調達にRFPが登場するのは、このような理由があってのことである。

もともと購買とは、自社が必要とする仕様に対して、サプライヤーが供給可能な性状のマテリアル(ないしサービス)をマッピングする、という作業が中核にある。ここで重要なのが、“Apple to appleの比較”の原則である。これはCompare apple to orangeという英語の言い回しから出た表現で、「リンゴ1個とオレンジ1個の値段を比較して、高いとか安いとか議論すること」の愚を戒めている。カローラとスカイラインの値段を比べて、安い方を買おうという人はいまい。比較するのならば、同じ土俵に乗せて比較しなければならない。同じ土俵とはすなわち、自分が何を求めているのかという点(=要求仕様)である。

ただし念のため書くが、「カローラがほしい」というのはRFPに書くべき要求仕様ではない(そんなRFPを日産やホンダのディーラーに送りつけて“これで公正だろう”と思ったら愚かだ)。要求仕様とは、いわば、「リンゴがほしい」と固有の商品イメージを書くのではなく、「甘くて、そのまま食べることも煮て食べることもでき、1個が150g前後で、冬の間も入手可能であり、消化によい国産の果物」という風に、使用目的を基準に抽象化した条件づけのことを指す。ここまで指定すれば、スイカや苺を持ってくる売り手はいないだろうし、100g以下の姫リンゴを提案するサプライヤーも失格となる。

RFPに規定すべきことは、上記のような「技術的仕様」(=What)だけではない。同時に、必要な数量はどれだけか、納期はいつか、検収条件は何で支払条件はどうか、といった調達条件(=How)についても規定しなければならない。

さらに重要なことは、買い手とサプライヤー相互の「スコープ・オブ・ワーク」を決めておくことである。機材でいうなら、輸送費や設置費はどちらが持つのか、予備品はどこまで含まれるのか、支給部品はあるのか、マニュアルや設計図書はどこまで含めるのか、といった事項であるし、情報システムなら、ユーザ側の遂行体制はどうするのか、業務帳票は提供するのか、レガシーデータの移行はどちらが責任を持つのか、トレーニングはどこまで含まれるのか、テスト環境は誰がどう提供するのか,等々といった事項がこれに相当する。これらを箇条書きにして、買い手と売り手の「星取り表」を作るのが良くやる方法だ。

これはいわば、売り手と書いての『権利義務関係』を規定しているわけである。受注生産品を製作し納品する作業は、ある意味で買い手と売り手の協力で進められる。つまり、お互いに結果に対して責任の一部を負っている。これを買い手が忘れてしまうと、いい成果は得られない。別の言い方をすれば、RFPのプロセスというのは他人行儀なのである。そこでは、甘えや貸し借りやなれ合いは排除される。

むろん買い手のニーズが、「甘くて食べられる果物なら何でもいい」という程度のアバウトなものならば、提案されるものはリンゴでもオレンジでも良いわけだ。しかし、その場合はもはや価格の比較は意味を失う。RFPを用いた購買プロセスとは、“価格は品質・性能に比例する”という精神に裏付けられているので、要求品質にアバウトな会社は買い手能力を疑われる。すなわち、RFPは、売り手を条件付けるだけではなく、買い手の能力をも試すものなのでのである。




S&OP
販売・事業計画
Sales & Operation Plan
「革新的生産スケジューリング入門」第7章講義4

販売側と供給側が合同でつくる整合性のある統一された計画。需要予測から生産物流計画までをふくむ。



SCM
サプライチェーン・マネジメント
Supply Chain Management
「革新的生産スケジューリング入門」第7章講義1

調達→加工→製造→物流→販売という、製造業における生産から販売にいたる供給の流れをうまくマネジメントし、生産と販売の同期化を実現する経営活動をさす。



SCP
Supply Chain Planner
(i2 Technologies社の製品名称)
「革新的生産スケジューリング入門」第5章ディスカッション6

i2 Technologies社の製品群RHYTHMの中核をなすモジュールの名称 (現在はRHYTHMという名称は用いず、TradeMatrixの名称の下の製品となっている)



SQP
二次計画法
Sequential Quadratic Programming
「革新的生産スケジューリング入門」第4章ディスカッション4.1

非線形的な解空間を、局所的にテイラー展開して二次形式化(超2次曲面と考える)して山登りしていく数理計画の手法。


TRM
タスク・リソース・マトリクス
Task Resource Matrix
「革新的生産スケジューリング入門」第1章ディスカッション1.3

タスクに対してどのリソースを割り当てるかを示した表。


VMI
ベンダー主導型店舗在庫管理
Vendor Managed Inventory
「革新的生産スケジューリング入門」第7章講義4

ECRの発展から生まれてきた活動で、流通の末端在庫を生産者側が管理することでリードタイム削減や在庫圧縮に結びつけようという手法。→CRP



WBS
Work Breakdown Structure
「革新的生産スケジューリング入門」第2章ディスカッション1

プロジェクトは複数の人が協力して、ある定まった目的を達成するために行なう、1回かぎりの時限的営為である。一つのプロジェクトは、さまざまな作業(任務)から成り立っている。この作業をタスクないしアクティビティと呼ぶ。プロジェクトを構成する多数のタスクを階層的に分類し、管理番号を定義したものを、WBS(Work Breakdown Structure)という。

“階層的に分類”とは、次のような意味である:ある製品開発プロジェクトが、かりに「市場調査」「設計」「試作」「生産準備」そして「市場投入」の5タスクから成るとしよう。その「設計」を、もう少し子細に見ると、それは「概念設計」「基本設計」「詳細設計」の3つに分割することができる場合、これらは設計タスクの下位タスクに位置づけられる。「詳細設計」は、さらに「機械設計」「電気設計」「制御設計」「外装設計」にさらに分解できるかもしれない。「設計」は最上位のレベルにあり(ふつう、これをレベル0とする)、「詳細設計」が中位のレベル1、「機械設計」がレベル2、と階層化されるのである。

では、どこまでも設計タスクは分解可能かというと、「鉛筆を手に持つ」「線を引く」という動作レベルまで分割しても、もはやプロジェクト管理上はほとんど意味がない。そこまでの粒度では計画も進捗管理もできないからだ。この点が、標準動作までを問題にする製造管理と異なっている(製造では動作は繰返されるが、プロジェクトでは個別動作でしかない)。

“これ以上分割すると、管理の手間の方が管理の効果よりも上回る”と感じられる常識的な線引きが、どこかにあるはずだ。そこで分割は止める。この作業の最小単位を「ワークパッケージ」とよぶことがある。エンジニアリング産業の経験では、どんなに大きなプロジェクトであっても、タスクの階層はレベル4まで、総タスク数は数万程度である。

さて、プロジェクトを構成するタスクは、プロジェクトと同じく、完了条件ならびにインプットとアウトプットが定義されていなければならない。つまり、タスクは“小さなプロジェクト”と考えることもできる。

よくあるWBS構成の間違いとは、ここに完了条件のないタスクを持ってきてしまうことだ。たとえば、「週次ミーティング」などである。週次ミーティングは、これこれを達成すれば終わって良い、という条件がない。したがって、こうしたミーティング類は、設計なり試作なりのタスクの一部と考えた方がいい。

もう一つ、よくある間違いは、「プロジェクト管理」というタスクを入れ忘れることだ。これがないと、プロマネの仕事がなくなってしまう。

WBSは、つねにその裏側にコストの積算とスケジュールのネットワークがぶら下がっている。つまり、コストとスケジュールの管理の観点から、WBSの構造は整理されなければならない。このためにこそ、各タスクに管理番号を付番するのである。

そして、このWBSのコード体系こそ、その企業におけるプロジェクト管理の思想そのものを表わしている。WBSのコード体系は、プロジェクト計画において、タスクを洗いだす際、「重複なく・落ちなく」(Mutually Exclusive and Completely Exhaustive = MECE)にリストアップするためのガイドラインを示すからである。

WBSの整理番号は、したがってすべてのプロジェクトに共通に振らなければならない。たとえば私の勤務先では、WBSコード2158といえば回転機の調達のことであって、それはどのプロジェクトでも共通に用いられる。従業員は誰でも、その番号を言われれば意味がすぐに分かる。

よく、WBSに1.3.2などのシーケンシャル番号を振っている例を見かけるが、これでは同種のタスクの番号が、プロジェクトごとに異なる可能性が高い。このようなコード体系はWBSの名前に値しないことを理解するべきである。




あ−お



アクティビティ
Activity
「革新的生産スケジューリング入門」第1章講義3.1

プロジェクト・スケジューリングの概念で、始まりと終わりの日時が明確にきまった出来事をさす。生産スケジューリングにおける「タスク」にほぼ相当する。



アロー・ダイアグラム
Arrow Diagram
「革新的生産スケジューリング入門」第2章講義2

PERTによるプロジェクト・スケジューリングにおいて、作業の全体像を表す図。普通、1つの作業(アクティビティ)をひとつの矢印で表し、矢印の両端をイベントとして小さな円で表現す。



安全在庫
Safety Stock
「革新的生産スケジューリング入門」第7章講義3.2
「BOM/部品表入門」第4章Q6、第5章Q3

企業のもつ在庫は、引当先の決まっているフロー在庫と、引当先が未定のストック在庫とに大別できる。ストック在庫は一種の「時間の缶詰め」であり、生産リードタイムを短縮するために見込みで調達ないし生産した結果として生じるものである。さらにこれは、意図してもつ在庫と、偶発在庫(『できちゃった在庫』)に区分できる。

意図的にもつストック在庫は、さらにその意図を分析すると、中期的な計画に沿った計画在庫(たとえば季節的な作りだめや定期補修対応のための作りだめ)と、変動を吸収するためのバッファー在庫に分けることができる。いわゆる安全在庫とは、この意図的な短期バッファー在庫を指す言葉である。

在庫−┬フロー在庫(引当先の決まっている在庫・滞留)
   └ストック在庫−┬偶発在庫
           └意図的在庫−┬中期計画在庫
                  └短期バッファー在庫(安全在庫)

JISでは安全在庫を、「需要変動または補充期間の不確実性を吸収するために必要とされる在庫」と定義する。手短で簡潔な定義だが、これだけだと若干舌足らずなことにお気づきだろうか? もう少しお節介に言葉をおぎなうならば、「欠品をさける目的で」と追加したいところだ。安全在庫とは、欠品を極力さけるために置くものなのである。欠品しても平気な商売だったら(そういう「売り切れ御免」のビジネスモデルだってたくさんある)、安全在庫など必要ない。

しかし、製品販売では機会損失につながることが多いので、一般に欠品をきらう。工場でも部品材料の欠品は計画混乱要因なので、きらわれる。そこで安全在庫の必要がでてくる。

手配(購入品の場合は購買オーダー)をかけてから補充されるまで、ふつうは日数がかかる。もし在庫がゼロになってから手配していたのでは、その期間内はずっと欠品状態がつづいてしまう。そこで、補充リードタイムの期間内に消費される分を見越して発注点をきめる。1日あたり需要量が平均20個で、補充リードタイムが2週間(実質10稼働日)かかるなら、発注点は200個と決めるわけだ。

ところが、需要には変動がつきものだし、補充期間も(機械のトラブルやトラックの遅れなどで)かわることがある。手配から補充までの間に、実際は187個消費されることもあるだろうし、210個の要求がある場合もあろう。後者の場合は、途中で欠品が生じることになる。

このような変動に対応するために追加でもっておく短期バッファーが安全在庫である。安全在庫の算出方法については古くから研究があり、いろいろな提案がある。たとえば、在庫理論のわかりやすい入門書である「適正在庫のマネジメント」(勝呂隆男・著)では、古典理論の計算式として

安全在庫=安全係数×単位期間あたり需要量の標準偏差×√(最大リードタイム)

を紹介している。最大リードタイムに√がついているのは、変動に正規分布仮定をおいた結果である。安全係数は、許容欠品率に応じて決まる。欠品率1%ならば安全係数=2.33、許容欠品率2%ならば安全係数=2.06%という具合である。

上記の例でいえば、平均需要量が20個/日、その標準偏差が2個/日、最大リードタイムが12日、許容欠品率を2%とすると、安全在庫=14.3個と計算できる。

いうまでもないが、「欠品ゼロ」で計算することはできない(欠品ゼロのためには無限大の安全在庫が必要になる)。このことは、生産計画には必ず失敗のリスク確率がともなうことを意味している。欠品率2%とは、補充手配を50回くりかえしたとき、1回欠品が生じる確率になる。つまり、補充手配間隔が2週間なら、2年に1度欠品になる、ということだ。

この式でむずかしいのは、『単位期間あたり需要量の標準偏差』の算定である。入出庫の実績を分析すればいい、と思われるかもしれないが、現実には間歇的な需要もあり、季節変動もあり、販売キャンペーンの影響もあり、分析はそう簡単ではない。

ところで、今日の製造業はほとんどが計画生産である。古典理論はこの点を考慮していない。季節変動や販売キャンペーン対応などは、ふつう生産計画の中であらかじめ考慮されている。したがって、安全在庫は「計画上の予測値があたらなかった場合」に対応すればいいことがわかる。この場合、次の式で在庫量を決めるればよい。
 
 安全在庫量=平均需要量×予測誤差×計画変更不可日数

くわしくは、「生産計画 ワンポイント講義」の中の『計画生産における安全在庫量の設定』(http://www2.odn.ne.jp/scheduling/SCM/Onepoint.html#anchor17433)を参照してほしい。



イベント
Event
「革新的生産スケジューリング入門」第1章講義3.1

プロジェクト・スケジューリングで、ある時間的長さをもつプロセスが何かの状態にたどりつく瞬間を意味する。イベントの中でも重要な意義をもつものは、マイルストーン(里程標)とよばれる。



オーダー
発注/指示
Order
「革新的生産スケジューリング入門」第3章講義5

企業間、あるいは企業内の部門間で発行される指示(ないしその帳票)。社内指示の場合をInternal Orderと呼んで社外への発注と区別することもある。
通常はまずRequest(依頼)を担当者/担当部門が起こし、それが正式に承認されて初めてOrder(指示)となる。たとえば、購買依頼(Purchase Request)を在庫係が起票し、それが購買部によって承認されてはじめて購買オーダーPurchase Orderとなる。あるいは、営業部の生産依頼(Production Request)が計画化の承認の元に生産オーダー(Production Order)となる、など。



か−こ



確定購買

安全在庫の項にも書いたとおり、在庫には、用途の決まっていないストック在庫と、用途の決まっている(引当済みの)フロー在庫がある。これとよく似た区別として、部品在庫管理における、常備品・引当品という呼び方もある。ただし、常備品の在庫の中にも、じつは引当済みの分(フロー)と、未引当の分(ストック)とがあるわけだから、両者は厳密には別の概念である。

ところで、購買発注を考える際にも、この二種類に対応する区別が有益である。私はこれを「見込み購買」と「確定購買」と呼んでいる。前者はストック在庫のための発注であり、後者は使用予定の決まった購買手配である(入荷してから使うまでに時間がある場合にフロー在庫となる)。なお、理屈から考えると、受注生産の企業はすべてが確定購買になるはずである。しかし、完全な受注生産という形態は実際には存在しない。どの企業も納入リードタイムを短縮するために、なんらかの見込み手配を行なっているものだ。これはちょうど、注文を聞いてから魚を釣りに行く料理屋がないのと同じである。

ところで、古典的な在庫・購買管理理論では、この両者を区別していない。というより、計画生産における購買発注論が不在だというべきかもしれない。その問題点は、発注点方式において典型的に現れてくる。

たとえば、向こう1ヶ月間の生産計画が確定しているとしよう(これを、計画のタイム・フェンスが1ヶ月であると表現する)。あなたは在庫・購買の担当者だ。さて、部品Xはこの期間内に合計120個、生産に使われる(引当)予定だ。汎用部品で消費量は比較的安定しているため、ABC分析の結果、Xは発注点方式で在庫を維持することになっている。注文すると翌日に納品される。今、現在庫量で40個あり、発注点は25個、発注ロットサイズは100個だ。さて、あなたならどうするだろうか?

在庫管理理論にしたがえば、こうだ:生産計画を見れば何日目かに在庫が25個を切る予定がわかる。その日になったら、100個発注をかける(発注書は今日、印刷しておいてもいい)。翌日以降はまた推移を見ていくわけだ。ところで、まったくの素人をここに連れてきたら、どうするだろうか? おそらく、120-40=80個の不足分を、在庫が無くなる前日に手配するだろう。月末の時点で、あなたのやり方なら40+100-120=20個の在庫をかかえ、素人は在庫ゼロである。どちらが経済的だろうか。その違いはなぜうまれたのか?

あなたのやり方は発注点方式であり、これは「見込み購買」の典型である。一方、素人のやり方は「確定購買」である。もし本当に生産計画が確定しているなら(ここがミソだが)、部品Xは確定購買でいけるはずなのだ。

ところで、部品Xの購買リードタイムが1週間だったら、どうだろうか? この場合、次の生産計画が決まるのは1ヶ月後だとしたら、素人流の確定購買では、ちょっとだけ気持ちのわるい部分ができる。それは、はたして月末在庫をゼロにしていいのか、という点だ。翌月の最初の1週間にXを使用する予定が入ったら、欠品状態になってしまう。だからあなたは素人さんに、「最低1週間分の在庫量は残しておいた方がいいよ」とアドバイスしたくなるだろう。確定購買に見込み購買の要素が入ってくるのだ。もっとも、生産計画が半月ごとに見なおされ、計画確定期間がシームレスに連続していったら(これをローリング・スケジュールという)、こうした心配は不要になる。

では、部品Xの購買リードタイムが1ヶ月以上だったら、どうなるか? 素人さん流の確定購買では、アウトである。今から手配しても、80個の不足はどうしようもない。もっとも、半月前の前回計画時点に手配してあって、その納入予定があるのなら別だが、その数量が80個以上かどうかは、(今月後半の計画は不確定だったのだから)何の保証もないことになる。一方、発注点方式のあなたの場合はどうか。現在庫量がまだ発注点を切っていないのだから、納入予定もないだろう。やはりアウトである。

まとめてみると、こうなる:
(1)購買リードタイム < 計画のタイム・フェンス の場合は、確定購買
(2)そうでない場合は、確定購買+見込み購買、または見込み購買のみ

見込み購買には不確定要素があるから、かならず余剰在庫や欠品のリスクがつきまとう。したがって、これを減らしたければ、購買リードタイムを短縮するか(それにはベンダー側の協力がいる)、あるいは計画のタイム・フェンス、つまり計画確定期間を確保するかの、いずれかの努力が必要になる。計画確定には、営業部門の協力も必須だ。だから、S&OP(販売・操業計画)が大事になるのである。




カムアップ・システム
Come-up System
「革新的生産スケジューリング入門」第1章ディスカッション3.1

To Doリストを管理する方式(コンピュータを利用するとは限らない)。仕切紙のタブに日付を記入し、これを使ってカードを時間の順に整理して、その日にやらなければいけない仕事がその日になると手元に現れてくるようなやり方がしばしば用いられてきた。



ガント・チャート
Gantt chart
「革新的生産スケジューリング入門」第1章講義3.3

横軸に時間軸をとり、縦軸にタスクまたはリソースをとって作業の計画をあらわした図。縦軸のとり方により、ガント・チャートはタスク型とリソース型に分類される。



供給力
-
「革新的生産スケジューリング入門」第7章講義1.2

自社が需要にあった製品を供給する力。製品それ自体の特性による「商品力」と対比させた概念。



切替え型連続生産
「革新的生産スケジューリング入門」第6章講義3

生産工程の上流側は連続、下流側はディスクリートで、中核(ボトルネック)の工程が切替え型であるような業種をさす。筆者の提唱する新しい用語。



クリティカル・パス
Critical Path
「革新的生産スケジューリング入門」第2章講義4

プロジェクト・スケジューリングの理論は、PERT技法と、このクリティカル・パスという概念の発見(発明)からスタートしたと言っていい。PERTは米海軍のポラリス・ミサイル開発の中で生まれ、クリティカル・パスはデュポン社が考え出した。いずれも1950年代の終わりごろ、ほぼ同時期のことである。

PERTは基本的にプロジェクトの期間と見積のための手法であるが、その分析のためにプロジェクトを有向ネットワーク・グラフで表現する。そのグラフにおいて、プロジェクトの始点から終点まで、さまざまなタスクアクティビティ)が網の目のようにつらなっている。つまり始点から終点まで、タスクの組合せにより多数の経路がある。そのすべての経路の中で、最長の経路をクリティカル・パスとよぶ。

クリティカル・パスがなぜ重要かというと、この経路を完遂するのに必要な時間が、プロジェクト全体の開始から終了までの所要時間を決定するからだ。あらゆる経路の中で最長の経路なのだから、当然である。そこで、プロジェクト計画立案においては、これをいかに短縮するかが問題となる。逆にいうならば、クリティカル・パス以外のタスクの所要時間を短縮しても、プロジェクト期間の短縮には貢献しない。

一般に、多数のタスクを持つプロジェクトの場合、クリティカル・パスに属するタスクの比率は1−2割程度しかないと言われている。プロジェクト遂行段階におけるスケジュール・コントロールでは、全体の中で重点を置いて監視すべきタスクは、ほんの一部だけなのである。

最近は進捗管理手法としてアーンドバリュー分析(EVA)が非常に注目を浴びつつあるが、EVAはコストの世界の手法であるため、すべてのタスク要素を積算していく必要がある。したがって手を抜いていい場所がない。ところがクリティカル・パスに注目した進捗管理では、一部のタスクだけ追えばよいことになる。プロジェクト・マネージャの観点から言うと、重点管理が可能だというこの特性は重要だ。

EVAのもう一つの問題点は、進捗度(進捗率ともいう)のごまかしが可能だという点である。かりにクリティカル・パス上のタスクが遅れていても、非クリティカル・パスの達成を前倒しに早めて出来高を稼げば、プロジェクト全体の進捗度は遅れていないように見せかけることができる。しかし、クリティカル・パスに着目した進捗管理では、その場合は明らかに納期遅れが懸念されることになる。

プロジェクト・スケジュール上では、しばしば重要なマイルストーンを定義しておくことが多い。基本設計完了、だとか機材の納品、などである。マイルストーンを予定通り達成できたかも、進捗の大事な指標になる。そのためには、クリティカル・パス上のイベントをマイルストーンとして選んでおく必要がある。

なお、プロジェクト・スケジュールを立案すると、各タスクの最早着手日(EPST)ならびに最遅着手日(LPST)が計算できる。このEPSTとLPSTの差をフロートと呼ぶが、クリティカル・パス上のタスクは、フロート=0になる性質がある。

プロジェクト遂行段階では、クリティカル・パス上のタスクだけを重点管理しておけばよいと書いたが、ただしそこには限界がある。もし、非クリティカル・パスのタスクの実行が遅れて、上記のフロート日数を食いつぶしてしまうと、今度はそのタスクを含む経路がクリティカル・パスになってしまうからである。つまり、クリティカル・パスは、遂行段階では動的に変わっていく可能性を持っているのだ。このように、計画段階のみならず遂行段階においても、クリティカル・パス概念は重要な意義を持っている。

ところで、優れたプロジェクト・マネージャは、マスタ・スケジュールを立案する際に、クリティカル・パスの終点をプロジェクトの最終納期とするような計画はふつう作らない。そんなことをすれば、クリティカル・タスクが少しでも遅れたらプロジェクト全体が沈没してしまうからだ。そのかわりに、クリティカル・パスを短縮する工夫をした上で、その末尾にフロート期間を追加する。これを、プロジェクト・バッファーと呼ぶ。このバッファーの存在がプロジェクト全体を沈没から救ってくれるのである。

余談だが、某・著名プロジェクト・ソフトウェアは、このバッファーを設定するためにプロジェクトの最終期日をずらすと、クリティカル・パスの赤色表示が消えてしまう。どうやら、「始点から終点までの最長の経路」という基本定義を忘れてしまったらしい。このソフトを使ってマスタ・スケジュールを引いていた著者の同僚は、あきれてこう語った。「この会社が出す次期OSのリリースがいつも遅れるのも、無理はないよなあ」



クローズド・ループMRP
Closed Loop MRP
「革新的生産スケジューリング入門」第3章講義9

MRPでは、無限能力の仮定の下で資材所要量計算を行ったのち、能力所要量計画に(CRP)よって、実際の工場の制約条件に合わせたプランを作成する。もしも、制約条件をクリアできない場合には、MRPにもう一度戻り、制約条件におさまるように再計算する必要がある。MRPとCRPの二つのステップの間に、一種の手戻りないしループが必要になるので、これをクローズド・ループ・MRPとよぶ。



欠品表
Material Shortage List
「革新的生産スケジューリング入門」第3章講義2

組立て工程において、必要な部品が足りない際に、そのような不足している部品をリストアップしたもの



広義のBOM
Bill of Material (in the broader sense)
「BOM/部品表入門」キックオフQ2

製造業のDNA情報であるところのBOMを本来の狭義にとらえるならば、マテリアルの数量的関係を表わしたリストだと定義できる。しかし、BOMデータの構築のためには、BOMに関連の深い一連のデータが、互いに整合性がとれた形で構築されていなければならない。これを広義のBOMと呼ぶ。広義のBOMとは、
 
「マテリアル・マスタを中心とした製品構成と製造工程にかんする基準データ、ならびに、そこから派生する履歴データ」
 
と定義される、まとまったデータである。その中心は、(狭義の)BOMマスタと、マテリアル・マスタ、工順マスタの3つのマスタだ。中でも工順(routing)は重要で、マテリアルとBOMをつなげる役割を果し、その中には、時間とリソースの情報があるため、マテリアルのサプライチェーンを統御するために不可欠である。これに加えて、製造指図や製造実績報告などの履歴データ(この中にBOM履歴が格納される)がある。広義のBOMとは、こうしたさまざまな要素からなる、マテリアルに関連する大きな情報の体系を指している。

BOMの問題を考える際には、狭義のBOMマスタだけの単体で考えてみても無意味である。広義のBOMの体系の中で、狭義のBOMデータが(あたかもDNAのように)どこで生まれ、どこに複製・転送され、どこで製品として具体的な肉体化されていくか、プロセスの視点から整理する必要がある。



工順
Routing
「革新的生産スケジューリング入門」第5章講義5.2

 BOM(部品表)は、製品と部品、また部品と原材料の関係を表した基準技術情報(マスタ・データ)であり、製造業の生産管理における中核としての役割を果たすものである。BOMにおいては、製品→部品→サブ部品→原材料、という親子関係を階層的に表す(BOMの世界の親子関係は、“親から子が生まれる”のではなく“子が親を産む”ので、その意味では逆さまだが、この辺にはいかにも組立加工業の感覚が強い−−一つの原料が多数の製品を生む素材産業からBOMが誕生していたら、こういう用語にはならなかっただろう)。
 
 1960年代に生まれた初期のMRPでは、この子部品と親部品の間に、員数(親1に対して子がいくつ必要かを示す数量)と、標準リードタイムの値をきめ、属性として直接登録していた。その標準リードタイムは、子を親に加工する工程において必要な期間(工程における待ちや滞留を含めたトータルの日数)として、タイム・バケット単位で与えた。

 ところで、80年代に完成したMRPUでは、BOMの親子関係を、すなわち『子部品を加工/組立することで親部品が出来上がる』、という風にプロセスとして解釈する。その加工/組立のプロセスは、実際には一つないし複数の作業から成り立っていると考える。そして、そのプロセス(これを加工順序ないし工順 Routingと呼ぶ)を、独立したマスタ・データとして扱い、標準リードタイムはこちらの属性として登録するようになった。これが工順マスタである。
 
 日本における生産管理の本は、いまだにその多くが現代のMRPUではなく昔のMRPしか紹介していないため、この工順マスタに関する説明が抜け落ちているケースがかなり多く見られるようだ。ともすると、APSの解説にさえ、工順の概念が抜けていたりする。

 ところで、なぜ、このような工順の概念が必要になったのだろうか? 単なる工程のままで不十分だったのは、なぜか。
 それには三つの理由がある。

 まず、生産能力(キャパシティ)を正確に表現する必要がでてきたためだ。MRPのつくる生産スケジュールの最大の問題点は、無限能力を前提とした計画であることだ。しかし、実際の工場の生産能力にはとうぜん限界がある。MRPが計算してつくったスケジュールにしたがって、作業工数の負荷山積みをしてみると、現実には不可能な数量を同一期間内に集中して作る計画になってしまうことが起こりうる。そこで、山積みされた負荷と、実際の生産能力上限を比較して、生産着手の順序を調整するCRP(Capacity Requirement Planning)の手法が生み出された。

 ところで、CRPを正確に行なうためには、「工程」のような大括りの概念ではなく、その工程内で用いられる、個別の製造機械や人間(手作業が入る場合)のサイクルタイム=能力をつかむ必要がでてくる。ことなる種類の製造機械や作業者には、それぞれ異なる能力値と上限があるからだ。

 次の理由は、コンベヤ等を使った流れ作業やフローショップ型工場における表現のためである。コンベヤによる流れ作業は、複数の加工作業がライン上にならぶ。もし、あらゆる種類の品目が、かならずコンベヤの端から端まで、まったく同じ作業を通るのならば、ライン全体を一つの工程としてまとめて扱っても、何の支障もないだろう。

 ところが、製品の多品種化が進むと、品目によってコンベヤの途中から流したり、最後まで流さずに途中から抜き出したりして、コンベヤの部分的機能だけを使うケースが増えてくる。このようなときには、同一の工程としての括りはできない。しかし、これらを別の工程として登録してしまうと、その能力上限を正しく把握できなくなってしまう。この矛盾を解決するために、工順の考え方が生み出された。工順は複数の作業の順序を定義する。そして、能力上限は工順自体ではなく、各作業の方にもたせるようにすることで、この問題を解決したのである。

 三番目の理由は、加工順序の代替性からくる。工場において、同一品目を製造する場合でも、複数の異なる機械と手順がありえたり、あるいは一部を外注加工に出したりするケースがしばしばある。MRP自体は、このような、生産手段が複数ある際の選択は苦手だが、工順マスタに代替工順を設定しておけば、CRPの検討の際に山崩しが楽になる。

 これらの理由から、MRPUでは次第に工順マスタの利用が広まり、この考え方はそのまま現代のAPS製品の大多数(全部ではないが)にも採用されるに至ったのである。



購買オーダー
発注書
Purchase Order
「革新的生産スケジューリング入門」第3章講義5

「購買オーダー」とはPurchase Orderの直訳で、企業間で発行される指示であるオーダーの一種であり、資材購買担当者が外部に対して行う発注情報を意味する。ただし、ふつうは帳票の紙切れ自体の方を指し、単に「発注書」とよぶことの方が多い。英語ではPOと略する。受け取る側の組織では、「注文書」「オーダー」「受注オーダー」などと呼ぶ。

紙が重視されるのは、それが直接、お金のコミットメントになっているためである。多くの場合、サインや印鑑が求められる。むろん、口頭で注文しても、両者が内容に合意している限りは法的に有効である(八百屋で大根を買うのに発注書を切る人はいない)。しかし紙のエビデンスがある方が法的効力が強い。逆に口頭ベースで交渉している間は価格のネゴがきく。電子データだけでやりとりをする電子調達システムが、しばしば強い抵抗にあうのも、ひとつにはこの心理が働いている。

購買オーダーは情報技術的に見ると、ヘッダー情報と明細情報との2部構成になっている。ヘッダー情報には、購買オーダーID(=注文書番号)、オーダー名称、発注金額合計、全体納期、納入先、引渡し条件(INCOTERMS)、支払方法、発注先ID、支払先ID、購買依頼(Purchase Request)ID、調達仕様書(Requisition)番号、その他注釈などが含まれる。

明細情報(発注ライン情報)の方は、明細行(ライン)番号、明細項目名称、数量、数量単位、単価、合計金額、明細納期(分納の場合に使用する)、その他注記などからなる。

このように構造的には比較的明確であるにもかかわらず、困ったことに、購買オーダーの仕組みは、たいていの生産系情報システムやAPSのウィークポイントになっている。それは、調達という行為自体が、いわゆる生産管理学の中の盲点になっているからである。製造と違って、購買は販売と同様に、いわゆる「理系」の枠組みからはずれると思われている。購買部員や営業部員は理屈を嫌う、一癖ある人達だとさえ信じられている(そして時にはそれが真実だったりもするのだが)。

このような敬遠意識があるためか、購買オーダーをめぐるシステムはたいてい、ひどく単純につくられている。APSは製造リードタイムに関しては、あれほど精密な計算をするくせに、購買リードタイムは固定値で与えるだけだったりする。

もともと、購買オーダーは、マテリアルの供給指示(つまりモノを買う目的)にも、サービスを提供する指示(つまり外注加工などのレイバーワークを買う目的)にも、用いられる。無論、同じ注文書の中に「サーバの納品」というモノの購入と、「インストールのサービス」という作業の注文が含まれることは多い。しかし、本来、後者はワーク・オーダーとして、明細レベルで区別すべきである。

にもかかわらず、同一部門が発注作業を行っているので、同じ仕組みが用いられることが多い。そのため、部品表の中に、資材のみならずサービス項目を登録したりする。こうなると、データ構造自体が全体として少しずつゆがんでしまう。

サプライチェーンの観点に立てば、購買は販売と対称形の行為である。SCMを実現したければ、購買オーダーについて、より深く理解する意欲を持たなければならないのである。



コスト・エンジニアリング
Cost Engineering

コスト・マネジメントの話を、少ししたいと思う。コストは品質・納期とならんで、製造業の生産における3要件と呼ばれる。品質(Quality)・コスト(Cost)・納期(Delivery)の頭文字をとってQCDともいう。この三つが顧客の主要な要請であり、また製造業の競争力の尺度でもあると考えられている。プロジェクト的分野においては、Scope・Cost・Scheduleが主要な三要素であり、品質がScopeに入れ替わっているが、いずれにせよコストが重要であることにかわりはない。(プロジェクトでもScopeでなくQualityを採用するべきだという議論もあるが、ここでは深入りしない)。

さて、コストである。これが、皆、分かっているようで良く分かっていない項目なのだ。その理由は二つある、のだが、その理屈に入る前に、コスト・マネジメントには専門職がある、という話からはじめよう。その職種を、「コスト・エンジニア」Cost Engineerとよぶ。

米国にはAACE Internationalというコスト・エンジニア専門家の協会があり、国際大会を開いたり研究・啓蒙活動を行っている。AACEは元々、American Association of Cost Engineeringだったはずだが、現在は Association for the Advancement of Cost Engineeringの略称ということになっている。Internatioalをつけて国際化したときに、国名を外したのだろう。英国にも、Association of Cost Engineersという団体がある。日本にはまだ、あいにく存在していないようである。

それにしても、コスト・エンジニアリングとは、何をする仕事なのだろうか? エンジニアリングとは、普通は何か「機能するモノ・仕組み」(それが有形であれ無形であれ)を設計し、現実化する仕事を指す。機械工学Mechanical Engineeringとか制御工学Control Engineeringなどは、そうした種類の技術だ。ところが、コスト・エンジニアリングはまさか『コストという名前のモノ』を作る仕事ではない。では、何を設計するのか?

答えは、製品やサービスの『原価を設計し、実現する』技術、なのである。技術というところがポイントだ。エンジニアリングは、科学的アプローチに基礎を持っていなければならない(機械工学が物理学や金属学などに基づいているように)。気合いと根性でコスト削減を目指したり、下請業者を呼んで「指し値」で恫喝したり、というやり方は、原価低減には役立つかもしれないが、『科学的アプローチ』ではない。

科学的でないと何が困るかというと、数値とデータ分析で精度を向上させたり、やり方を他者に教育・移転したり、ということができなくなることだ。エンジニアリング(技術)とは、どんな人間でも一通りの訓練さえ受ければ、70点の仕事ができるようにする事を目標としている。だから逆に、エンジニアリング抜きのコストダウン活動は、ひどく属人的なやり方になってしまう。

そのコスト・エンジニアの仕事だが、大きく分けて以下のような要素からなっている:
(1) コスト見積(estimating)
(2) コスト・コントロール(cost control)
(3) コスト予測(cost forecasting)
(4) 投資採算分析(investment appraisal)
(5) リスク分析(risk analysis)
細かく言えばまだあるが、上記の5本柱が仕事の中心である。

コスト見積(estimating)の科学的アプローチとは何だろうか。これから作ろうとする製品やサービスの原価は、ふつう、その設計内容と、過去のコスト実績とから計算する。見込生産や繰返し受注生産のように、すでに設計内容が決まっている製品については、その部品材料の仕入れ価格や、社内工賃などが定まれば計算でき、標準原価として定義されている(はずである)。むしろ目標原価を最初に設定して、それに合うような設計をすることもしばしば行われる(これを原価企画とよぶ)。

しかし個別受注生産は、毎回原価が異なる。本来はきちんと設計を完了して、はじめて精確なコストを見積もれる。ところが、受注ビジネスの商談においては、コスト見積の段階で、必要な詳細設計の全てを済ませることはできない。顧客の要求仕様にもとづき、概略の『見積設計』を行い、それをもとにコスト見積をしなくてはならない。

このとき、詳細不明な部分のコスト要素について、過去の実績データから何らかの推算方式を用いることになる。それは、なんらかの代表的尺度(トンだとかkWだとか)を用いたfactor methodであったり、あるいは過去の単価トレンドの数理的外挿だったりする。こうして、設計がどの程度まで確定しているとき、どのような推算手法を用いるべきかの決定が、estimatingの主要な技術となるのである。

二番目のコスト・コントロール(cost control)とは、実行段階におけるコストのトラッキング、予実対比ならびに問題解決を行う活動である。見積段階で作り上げた原価構成を元に、まず『実行予算』を策定する。すべてのコスト要素に対して、目標値となる予算を決め、各担当者に通知するわけである。それから、発生した実績コストを時系列的に把握・集計する。そして予定コストと対比する。これが予定内であればokだが、実績が予定を上回っているようであれば問題である。その原因をつきとめ、分析する必要がある。そして、対応策を考え、関連部門とともに対策にあたる。

こうした活動がcost controlだが、発生コストのリアルタイムな把握だけをとっても、そう簡単でないことはおわかりだろう。あなたの職場では、たとえば製品にかかわる人件費を集計するタイミングは、翌日・翌週・翌月のどれだろうか? そのタイミングは、製品作りのリードタイム(つまり納期)に比べて、十分短いだろうか? 

この問題はさらに、cost forecastingの活動にもつながる。cost forecastingとは、「この仕事が全部終わった時には、いくら金がかかっているだろう?」という問いに答える活動だ。当然ながらこの問いには、「いったい、この仕事はどこまで進んだのだろう? いつ終わるんだろう?」との視点もかかわってくる。すなわち、進捗率を把握し、着地点を推定する仕事である。完了時点のコスト推定値を、Cost Estimate at Completion、略してCost ETCという。

そして、以前、「進捗管理とは何か?」http://brevis.exblog.jp/17429450/でも書いたように、進捗率とは非常に誤解の多い概念なのだ。進捗とは、これまでどれだけ仕事をしたか、ではなく、「あと仕事がどれだけ残っているか」で量るべきものである。コストでいえば、今までいくら使ったか、ではなく(それはそれでcost controlとしては大事なのだが)、これからいくら使わなくてはならないか、を推測しなければならない。

知らない街でタクシーに乗り、目的地を運転手に告げて、たしか1,000円くらいでいけるはずだよな、と思いながらタクシーメーターを見る。すると900円になっている。「じゃあ、もう9割は来た訳だ」と考えるような人には、コスト・エンジニアリングは出来ない。今どこにいて、あとどれだけ道のりが残っているかを、地図や様々な手がかりから推計できて、はじめてコストをエンジニアリングしている、と言えるのである。なのに、ただタクシーメーターをじっと見つめているだけで「ぼくはコストをきちんと管理している」つもりになっている人が、世の中には多いように思われる。

さて、長くなってきたので(いつものことだが)、投資採算分析(investment appraisal)とリスク分析(risk analysis)の話は、別の機会に項を改めて書くことにしておこう。いずれにせよ、コスト・エンジニアリングとは、製品やサービスに必要な原価に対して、科学的なアプローチでせまろうとする技術であることが、少しは理解いただけただろうか。

ただ、通常の工学的技術が、力学や化学など固有分野の科学法則を用いるのに対し、コスト・エンジニアリング技術は、対象分野にしばられぬ汎用的な論理と法則によってできあがっている。前者を『固有技術』、後者を『管理技術』と呼ぶが、コストはスケジュールとならび、典型的な管理技術(Management Technology)の対象なのである。

コスト・エンジニアリングは歴史的には20世紀中盤頃に、英国の建設業界に生まれ育ち、その後は米国のエンジニアリング業界で発展した。その出自から、受注型ビジネス分野で、プロジェクト・マネジメントに内包される技術として成長したことがわかる。

実際、エンジニアリング業界における大規模プロジェクトでは、マネジメント業務をプロマネ一人では回しきれないため、Project Management Team (PMT)を組織する。コスト・エンジニアは、このPMTの専門職の一つに位置づけられる。もちろん中小規模プロジェクトでは、プロマネが一人で何でもこなさなければいけない。だからプロマネの職務の一部にコスト・エンジニアリングがある、といっても間違いではない。

一方、情報システム開発の分野では、工数見積はつねに大きなテーマであり、COCOMOやFunction Pointなどの技法が、ソフトウェア工学で以前から探求されてきた。しかし、ハードも含め、コストの全体像をエンジニアリングの対象としてとらえる、という概念は薄いように思われる。また開発の進捗とともに、工数の着地点がどうなるかを逐次モニタリング・推定し直すcost forecasting技術も、まだ未開発のように思われる。

まして、製造業の世界では、これだけプロジェクト的な生産活動が増えてきているにもかかわらず、コストに特化した「エンジニア」がいるという話はほとんど聞かない。今後、インフラ・システム輸出などに力点を置いて、総合力で勝負しようという機運が高まっている今日、コスト・エンジニアリングにもっと注目しても良いのではないだろうか?



コストセンター

コストセンターというのは奇妙な用語である。多義的だ、とか、意味が確定しにくい、とかいう訳ではない。コストセンターとは「費用だけが集計される部門単位」という定義が明確にあり、その点では、ほぼゆらぎがない。にもかかわらず、この用語は様々な価値判断や感情的評価を込めて使われている。ネットをちょっと調べてみれば分かるが、「もうコストセンターとは呼ばせない!」とか、「コストセンターからプロフィットセンターへの脱皮を」といった風に、ネガティブな意味合いで使われることが多い。あるいは「所詮コストセンター子会社だから」とか。いったい費用だけが集計される会社とは、どういう意味だろうか。収入がない会社が存在するのか?

もともと「コストセンター」とは、会計学から発した言葉だった。日本語では「原価中心点」という、いささかぎこちない訳語があてられている。意味は先ほど紹介したとおり、費用集計の部門単位である。企業の中には部門がたくさんあり、どこでも費用が発生するから、コストセンター(つまり中心点)がたくさんある、ということになる。なんだか幾何学的にはヘンな気もするが、まあ気にせず通り過ぎることにしよう。たとえばSAPの導入コンサルだったら、コストセンターは主にこうした会計的意味で、会社の組織定義のプロセスで使っているはずだ。

これに対となる用語がある。それは収入だけが集計される部門単位で、こちらは「レベニューセンター」と名付けられている。ところが、現実にはどんな仕事だって、人が動けば(最低でも人件費は)発生する。特許収入のように座っていればお金が流れ込んでくる種類の仕事でも、最低限の知財事務は必要なはずである。だから、純粋なレベニューセンターは実際の会社には存在しない。

そこで、コストも収入も発生し集計される部門単位が登場する。これを「プロフィットセンター」と呼ぶ約束になっている。

さて。ここまでは会計学(とくに原価管理)の概念である。会計学の特徴として、きわめて厳格に定義されているが、価値判断からは中立だ。会計士は、この製品は好ましいだとか、あの部門はアホだとかは言わないのである(少なくとも表では)。ではなぜ、コストセンターという語に、価値と感情がからみつくことになったのか。それは、会計学に隣接する別の学問、経営学の世界にこの語が取り込まれたからだ。経営学では(とくにサイエンス志向のあまり強くない経営学者の間では)、用語は厳密性より「説得力」が求められる。まして経営学のさらなる隣接地、経営コンサルやメディアの分野では、概念の「物語性」が最大の価値となる。

さて、経営学の分野ではマネジメントが主題である。そのため、部門をマネジメントする際に、その部門の性格、ならびに管理目標が問題になる。そこで、コストセンターは費用だけが集計される部門であり、費用で管理するべきだし、プロフィットセンターは収入と費用の両面で(つまり収入−費用=利益で)管理すべきだ、という見方が誕生する。

ちなみに、営業機能と開発・製造機能の双方を併せ持つ「事業部制」という仕組みを発明したのは、GMの社長スローンだったと言われている。それまでのGMは、開発・製造・販売・・と機能別に縦割り型の部門が、すべての車種を面倒見ていた。彼はそれを変えて、製品ファミリごとに、開発から販売まで自己完結・一気通貫で動く組織をつくった。この事業部は製品ごとの特性に応じて意思決定も資源配置も迅速に行えたため、大きな成功をおさめた。おかげでGMも成長したし、彼の名はMITのビジネス・スクールの名前に残った。このような事業部は、まさに収入と費用の両方を自己管理できるという意味で、プロフィットセンターと呼ぶにふさわしい。

ところで、用語というものは流通していくうちに、しばしば本来の意味から離れていく。いつの間にか、事業部制をとらぬ通常の企業でも、営業部門は収入を集計するから「プロフィットセンター」で、製造や物流や研究開発部門は(そして人事経理など本社部門も)、「コストセンター」と呼ばれることになった。これは、元の会計学的な意味では正しい。しかし、経営学的には正しいだろうか? 製造をコストだけで管理する−−それはどういう意味だろうか。

コストだけが部門の評価尺度と言うことになれば、向かう方向は必然的に「コストダウン」しかなくなる。コストは小さいほど良い。だから、コストセンター部門は必要かもしれないけれど、会社から見れば重荷でしかない、一種の必要悪である、という事になってしまった。このような見方は、コストセンター部門の子会社化による切り離し、という動きにつながり、'90年代後半から加速していく。その典型は物流子会社であろう。また工場の製造子会社化も広く行われるようになった。その背景には、わたしが以前から指摘している「生産サプライチェーンにおける生産から販売へのパワーシフト」があった。

ところで、よく考えてみてほしい。コストセンターを子会社化するというのは、その対象部門に「売上が立つ」事を意味する。そうでなければ会社として成り立たない(税務署だって認めまい)。工場を製造子会社化する場合、営業部門はそこから製品を価格付きで仕入れる事になる。今まで一つの会社だったときには意識されなかったモノの途中段階の値段が、急に浮上してくる。これを「移転価格」と呼ぶ。

この移転価格はどうやって決まるのか? 本社の販売側は「安ければ安いほどいい」から、製造原価で出せと要求するかもしれない。しかしそれでは利益ゼロで、子会社の経営が成り立たぬ。他方、原価よりずっと高い価格をつけたらどうなるか。本社側のマージンがその分減少する(無論、減った分は子会社に計上されるが、連結決算ではプラスマイナス・ゼロになる)。だからここは駆け引き、交渉になるのだが、まあ通常は本社の立場の方が強い。本社としては、製造原価とまでは言わぬ、子会社だって間接部門を維持し研究開発だって少しは必要だろう、だから原価+販売管理費の分までは負担しよう、と言うはずだ。

だが、もし子会社が100%親会社への内販だけでビジネスをしていたら、これはつまり会社として内部留保も成長余地もないことを意味する。あなたがこのような「コストセンター子会社」の経営者だったら、どういう将来展望を描き、どうやって従業員のモチベーションを高めるだろうか? ずいぶん難しい課題ではないか。

そうなると、残された道はただ一つ、親会社以外への外販比率を高めて、そちらで儲けていくしかない。だが、これは口で言うほどたやすいことでない。それは世の中に数多くある物流子会社を見ればよく分かるはずだ。営業人員だって不十分な機能子会社に、どうやって顧客を捜してこいと言うのか。一部の例外を除けば、多くは内販に頼っている現状がある。こうした会社は会計的にはプロフィットセンターだが、親からは相変わらずコストセンターと呼ばれている。

話を少し戻す。かりに子会社ではなく社内の機能部門だったとしても、コストというものは、本当にそれ単体で管理できるものなのだろうか? コストのみに責任を持つ組織というが、ここには何か欠けている要素がないだろうか?

コストの高低を言う場合、大事なことがある。それは、比較のベースである。製品コストならば、数量と、品質と、納期があってはじめて、比較可能になる。クラウンとカローラを比較して、カローラの方が安いといってよろこぶ愚か者はいない。また、同じものを作るにしても、1個作るのと100個作るのでは、当然値段は違ってくる。自分が外からモノを買うときを考えればすぐ分かる。

いいかえるなら、「コストだけに管理責任を持つ組織」では、マネジメントとしては全くの片手落ちである。いわば借方に対する貸方、つまり方程式の等号の反対側に、管理項目がなければならない。製造のようにマテリアルを供給する機能の場合は、品質・納期になる。物流のようにサービスを提供する機能の場合は、誤配率に代表される物流品質ということになる。言いかえるなら、サービス・レベルである。つまり、コストセンターは、サービス・レベルとコストに大して管理責任を持つ組織であるはずなのだ。品質が高ければ、コストもそれなりにかかる。納期が正確なら、それなりに費用もかかる。これが道理というものだ。もちろん数量も大事なコストの因子だ。だが、数量はむしろ需要側(販売側)が責任を持つべき項目であろう。

繰り返すが、経営学的にコストセンターをとらえるならば、サービス・レベルを規定した上で、コストを管理目標としていかなければならない。そうしてこそ、初めて他社との比較も意味を持ってくるのであり、また適正な移転価格レベルについても議論可能な状態となるのである。

(追記)英語版Wikipediaによれば、「プロフィットセンター」という用語をマネジメントの世界に最初に取り入れたのはドラッカーだったらしい。しかし彼は後にこの用語がおかしな意味で一人歩きしたのを見て後悔し、「企業内にあるのはすべてコストセンターだ。唯一プロフィットセンターと呼ぶべきは、不渡りでない小切手を切ってくれる顧客である」と述べている。


混合整数計画法
混合計画法、MP、MIP
Mixed Integer Linear Programming
「革新的生産スケジューリング入門」第4章講義1.6

線形計画法に選択肢の組合せ(離散的変数)が混ざった最適化問題を解く手法。ORの視点からスケジューリングにアプローチすると、ふつうこのカテゴリーの問題になる。



さ−そ



サービス

「サービス・サイエンス」という言葉は、2005年頃に米国IBMが声高に提唱したのがきっかけとなり、日本でも急速に浸透しつつある。こうした海外の新概念の流行にとても敏感な霞ヶ関のエリートたちも、すぐさま研究会やら政策提言やらをとりまとめて、時代のリードと予算確保に余念がないらしい。たしかに、以前「ヒノモト家の人々  −  マクロ経済学的素描」でも書いたように、流通サービス業は日本のGDPの約45%にあたる220兆円を稼ぎ出す基幹産業で、実は製造業よりもずっと経済への貢献が大きい。だからサービス・サイエンスで経済の活性化を、という願望もあながち的外れではないだろう。

米IBMのアルマデン研究所が中心となって進めている、この新学問は、正式にはSSME(Service Sience, Management & Engineering)と名付けられている。単にサービスの科学だけではなく工学でもあり管理でもあるという訳だ。とはいえ、この学問の対象とする範囲がどこからどこまでを指すべきか、という基本問題についても議論百出で、出発点からして混沌状態らしい。まだ、教科書を開いて「これが正解です」と勉強できる段階には、とうてい達していないようだ。

優秀なる研究者達が世界中でかくも百家争鳴の問題に対して、わたしごときがスパッと解決を提供できる、などとうぬぼれている訳では無論ない。ただ、いつものように、わたし自身は整合的な言葉づかいをしたいと思っていて、少なくともこのサイトの中では、その整合性を通したいと考えている。そこで、「サービス」に関する自己流の定義を、ここに着そうと思う。その定義とは、こうだ:

サービスとは、(ユーザの期待に合致した機能を持つ)リソースの提供である。それを有償とするか無償とするかは、提供者のビジネスモデルに従う。

リソースが何を意味するかについては、このサイトでも最近くりかえし書いた。世の中には、売り買いの対象にできる物事が三種類ある。マテリアル、リソース、そいてデータ/情報だ。このうち、リソースを販売・提供して利益を得るビジネスを、『サービス業』と呼ぶ。ちなみに、マテリアルの販売を主たる利益源とするビジネスは製造業(ないし流通業)であり、データ/情報の販売で成り立つのが情報産業である。

ちょっとここで、練習問題をやってみよう。たとえば、自家用車のメーカーは製造業だ。自動車のディーラーは流通業。どちらもマテリアルの販売で利益を上げる。では、自動車修理工場は?

修理工場では、たしかにパーツの販売代金も利益源だ。だが、主たる利益は定期点検/保全修理という「作業」によっている。作業の販売とは?  それは「組織的に熟練した工員の作業時間」というリソースの提供に他ならない。つまり、自動車修理工場はサービス業なのである。

もう一つ練習問題を。TV会社はどの業種か?  彼らは「情報」を売っている(正確に言うとスポンサーに売って広告収入を得て放送している)から、情報産業である。じゃあ出版社は?  彼らは、「書籍」というマテリアルを販売しているから、実は製造業なのである。書籍の価値は、たしかにそのコンテンツのもつ情報に依存している。しかし、現在の出版社は、それを(簡単には複製しにくい)紙の印刷物というモノの形で販売することでビジネス・モデルを成り立たせている。もし彼らが、電子出版に全面的に移行すれば、その時はじめて情報産業になれるだろう。

では、Microsoftなどのパッケージ・ソフトウェアの会社は?  じつは、パッケージソフトは、CD-ROMなどのメディアを売っている(所有権を移転している)のではない。ソフトの使用権に対価を得ているだけなのである(だからPCソフトは中古屋に転売できない)。つまり、ソフトウェアという機能を持つリソースの使用権が主たる利益源となっている、サービス業だということがわかる。

また、電話会社なども同様に、通信回線という種類のリソースを提供して収益を得るビジネスだ。このように、普通はまとめて「情報産業」とか「情報サービス業」と呼ばれたりする放送・出版・ソフトウェア業界などは、じつは別々の利潤形態になっているのである。

ソフトウェアや通信などを見ても分かるように、リソースは人的なものとは限らない。言いかえるならサービス業は、人的サービス業と、非人的リソース提供業に分類できる。当然、サービスのレベルや品質の規定の仕方も違うし、維持や向上のために必要な要件も異なる。『サービス・サイエンス』を標榜するなら、まずこうした区分からはじめるのが適当ではないだろうか。

その昔、まだモノが貴重で人件費は安かった時代は、通常のビジネスは「モノを売って、人的サービスは無償でつける」が普通だった。しかし21世紀の今日、すでに主従は逆転して、モノはただ同然でも有償サービスで儲けるビジネス・モデルがひろく普及した。それがサービス業の隆盛を招いたのであろう。

サービス業の収入の基本は、「リソースの数量×使用期間×単価」による課金のチャージである。無論、実際の料金体系は値引きを含めて様々なバリエーションを設定できるが、逆に言うと、この式のような販売価格の設定をしている業態は、実はリソース提供のサービス業ではないかと疑っても良い。たとえば、お金を貸して期間で利息をとる金融業は、サービス業の一種であると解釈できる。あるいは、人数と期間と人月単価で見積もりを出すSIerも、(成果物を伴う一括請負契約の枠ははめられているが)SE・プログラマという人的リソース提供サービス業の性格を持っている。

そして、サービス事業者側のマネジメントとは、リソースの維持と保守、ならびに機能の改善であることがわかる。リソースの「機能」とは、それをもちいて利用者が何かの行為をする、あるいは利用者の状態が変化する事を指す。電話回線ならば通信という行為であり、運送ならば荷物の場所の移動であり、医療ならば利用者自身の治癒回復である。だからサービス事業者は、これら機能を明確に規定して、そのレベルの向上に努めることが求められるのである。



サイクルタイム
Cycle Time
「革新的生産スケジューリング入門」第3章ディスカッション1

その工程全体の生産速度の逆数。今、一時間当たり10個の加工が可能であれば、1個あたり10分の1時間、すなわち6分がサイクルタイムになる。



在庫金利
「革新的生産スケジューリング入門」第1章ディスカッション2

在庫は一種の投資であり、そのぶん金利負担がかかる。これを在庫金利と呼ぶ。



在庫精度

「革新的生産スケジューリング入門」第3章ディスカッション4

在庫量を調べるには人手と時間、すなわちコストがかかる。この単純な事実がしばしば忘れられるようになったのは、コンピュータが製造現場に普及して、在庫管理にも利用されはじめてからのことに違いない。それ以前の生産管理技法は、在庫量を調べるにはコストがかかることを前提に組み立てられていた。だからダブルビン法などのように、在庫量が発注点を切ったかどうかだけを見るような仕組みが工夫されたのだ。

コンピュータ以前の製造現場では在庫管理をどうやっていたかというと、倉庫番の持つ入出庫台帳で追いかけるしかなかった。入庫・出庫の手書きの数字を足し引きするわけだから、在庫量はすぐには分からない。品目別にページや欄を分けて記入すれば、個別の現在庫量は把握できたが、増減の傾向や、あるいは複数品種の合計値などをつかむのは至難のワザだ。またどうしても誤差が多かった。

そのために、きちょうめんな現品棚卸作業が要求されることになった。保管棚にある物品をいったん全部取り出して、数をかぞえ直す作業である。帳簿と数字が合っていなければ、帳簿の方を修正する。帳簿と現物の差を、在庫差異とよぶ。在庫差異を現在庫量で割った比率が『在庫精度』である。

在庫差異にはプラスとマイナスがあるため、単純に足し算をすると打ち消し合ってしまう。したがって工場全体で評価する際には、絶対値の合計をとる。通常は工場全体で1−2%以内におさえられる(そうでなかったら入出庫と保管のやり方にどこかおかしな点があるはずである)。また、扱う品種数の多い工場では、全品種をすべて棚卸ししていると膨大な作業になる。そこで、循環棚卸といって、一部の品種を順繰りに毎月チェックしていき、在庫精度を一定に保つような工夫がされてきた。

こうした手作業の現場に、コンピュータによるリアルタイム在庫が導入されたことの衝撃は大きかった。それまでは在庫数量といっても霞の向こうに朦朧とした姿があるだけだったのに、いきなり全ての数字が鮮明な写真のごとく見えるようになったのである。総在庫量の計算だって一瞬だ。しかし、このために、かえって在庫精度のことが忘れられるようになったように思える。

そもそも在庫差異が発生する理由はいくつかある:
(1)入出庫の伝票記入漏れ
 伝票を書かずにいきなり物を動かせば、数が合わないのは当たり前である。記入漏れの中には、保管場所を変更したのに、それを訂正しなかった、なども含まれる。
(2)減耗・破損
 物品の中には、有効期限や賞味期限などがあって使えなくなるもの、あるいは保管中に破損する物があり、これらは在庫差異の原因になる。
(3)盗難
 日本ではあまり心配が(今のところは)無いが、きわめて高価な物品や、あるいは外国の工場などでは常に注意が必要である。
(4)品質管理上の区分移動
 不良品はふつう在庫に計上しない。しかし、良品と信じて受入れ入庫した物が、品質検査の結果はねられることはときどきある。この際に、在庫量からの差し引きを忘れるのである。
(5)移動中
 同じ社内で、資材をA工場の倉庫からB工場の倉庫に横引き移動するとき、A工場から出庫処理をして在庫が減り、一方まだB工場では入庫計上されないと、在庫が一時的に見えなくなってしまう。荷物として車上にある物に、ともすると起こりがちなことだ。
(6)支給品在庫・預かり在庫
 外注先に対して支給した材料は自社の資産だから、在庫量に計上しなければいけない。これが見えなくなることがある。また逆に、客先からの預かり在庫(製品として所有権は客先に渡して代金ももらったが、まだ自社倉庫に保管しているもの)も在庫差異をうみがちなポイントである。

米国の生産コンサルタント、オリバー・ワイトは'80年代のはじめに、「在庫精度が5%を切れないような会社では、MRPなどの生産管理システムは使えない」と書いている。在庫精度の向上維持は、一見当たり前のことに思えるが、当たり前のことを当たり前に実行することは、案外、努力のいるものなのである。



作業
Operation
「革新的生産スケジューリング入門」第5章講義5.2

これ自体は多義語であるが、スケジューリングの世界では製造・物流などのプロセスで行われる仕事の最小単位(もっとも粒度の小さなもの)を意味する。すなわち一つの装置で1セットの資材に対し1そろいのリソース・段取りおよび作業基準をあたえて行われる仕事である。工順を構成する最小単位。どこまで細かく作業を区分するかは、その目的に応じて決めるべきであり、むやみに細分化すればいいというものでもない。



作業区
Work Center
「革新的生産スケジューリング入門」第5章講義5.2

設備装置のブロック的なまとまり(空間的で静的な概念で、通常は計画期間中に変わったりはしない)。



自由度
Degree of Freedom
「革新的生産スケジューリング入門」第4章ディスカッション3

スケジューリング問題における解空間の広さ(系のとりうる位置の数)をあらわす量。



需要オーダー
Demand Order
「革新的生産スケジューリング入門」第3章講義5

需要計画にもとづいて営業部門から生産・物流部門にたいして発行される供給の指示。生産計画の主要なインプットとなる。通常は製品種別・需要先・納期の情報をもつが、需要先未定の場合もある。実際にできあがったものに対する納品指示(出荷オーダー)とはタイミングが異なることに注意。両者は一対一に対応するとは限らない。



需要計画
Demand Planning
「革新的生産スケジューリング入門」第3章講義12

販売予測をもとに計画需要量を決める作業。通常は製品別・販売チャネル別の数量にブレークダウンする。



正味所要量
Net Requirement
「革新的生産スケジューリング入門」第3章講義5

需要の総量(総所要量)から引当可能な手元のストック(在庫量)を差し引いた量



ジョンソン法
Johnson Method
「革新的生産スケジューリング入門」第3章講義1

2工程フロー・ショップで最短完了時間を与える古典的スケジューリング手法



進捗管理

「進捗(しんちょく)管理」は広く使われている用語だが、じつはかなり誤解されている仕事でもある。製造業の基本はQCD(Q=品質、C=コスト、D=納期)であり、それぞれをきちんと管理していかなければいけない。Qを対象とするのが品質管理であり、Cが原価管理(コスト管理)で、Dつまり納期を守るために進捗をきちんとコントロールすることが、進捗管理の任務である、と。まあそこまでは良いだろう。

ところが、この『進捗』なる概念がくせ者なのである。これほど誤解されやすいものはないのだが、わたしがそう言うと、不思議そうな顔をする人もいる。作業がどこまで進んだか、それが進捗ではないか。とてもシンプルだ−−そう思う人は、次の例を考えてみていただきたい。

これは国策である「北海道開発プロジェクト」にまつわる話である。ご存じないかたも多いだろうから解説しておくが、戦後まだ間もない昭和25年に『北海道開発法という法律が制定された。食糧増産ならびに人口問題の解決に寄与するため、未開の沃野である北海道の大地を農業化しようという壮大な構想を実現するための法律である。この法律に従って、北海道開発庁(当時)ができ、昭和27年に「第一次北海道開発五カ年計画」なる計画書を策定した。内容は、農業・畜産奨励・土壌開発(機械力による客土)・道路・河川・港湾整備・・・と多岐にわたり、予算は国費だけで800億円であった。半世紀以上前の金額だから、現在でいえば軽く1兆円を超えるだろう。

(余談だが、この『第一次五カ年計画』という用語を聞くたびに、わたしは“まるで社会主義国みたいだなあ”という感じをいだく。旧ソ連や中国などはこの種の五カ年計画が大好きであったが、日本の官庁も実はそうなのだ。北海道開発だけではなく、たとえば「科学技術基本計画」だとか「海洋基本計画」だとか、いろいろな種類のものが現在も多数動いている。「日本は世界でもっとも成功した社会主義国だ」とかつて中国人に揶揄された言葉も思い出す。そしてまた、官僚主義の病弊に悩む点まで共通だ)

さて、当時、北大に中谷宇吉郎という物理学者がいた。氷雪の研究者として有名だがエッセイストとしても知られている。この中谷教授は、北海道開発五カ年計画の最終年となる昭和32年4月に、雑誌・文藝春秋に「北海道開発に消えた八百億円 − われわれの税金をドブに捨てた事業の全貌」というショッキングなタイトルの論文を発表する。この論文の中で、人口増加・食糧増産・農家戸数の増加について詳しく統計数字を分析し、「いずれも達成率ゼロ」であった、と断定したのである。

この論文が出たおかげで、霞ヶ関の北海道開発庁は上を下への大騒動になった、と聞く(そう、この役所の長官は東京の霞ヶ関にいたのである)。そして、開発庁の高官によって、翌月の文藝春秋誌にすぐ反論が掲載される。いわく、
「開発計画は順調に進展している」
「なぜなら、過去の年度で、われわれは順調に予算を消化してきたからだ」−−

この論争、どこが行きちがっているかお分かりだろうか? 中谷宇吉郎先生は、目標にどれだけ近づいたかを問うたのに対し、北海道開発庁の反論の方は、“過去にどれだけ頑張ってきたのか”を答えているからである。彼らが怠惰だった、何もしなかった、といえば、それは嘘だろう。とくに現場の人々は努力していたにちがいない。しかし、努力はしても、それが実を結ばなかったのである。では、このような場合、進捗はいくらなのか?

一つはっきり分かることがある。それは、予算消化率=進捗率、ではないという事である。進捗率とは、達成の度合いでなければならない。いいかえれば進捗とは、どれだけ仕事をしたか、で量ってはいけない。「あと仕事がどれだけ残っているか」で量るべきなのである。

進捗管理の目的とは何か。それは『進捗』を「誰かに報告する」ためのものだろうか。そう考えてしまうから、そして、“進捗が上がらないとサボっていると非難される(かもしれない)”と信じるから、進捗管理がねじ曲がるのである。

進捗管理の一番大事な目的は、「この仕事はいつ終わるか」を予測することである。「終わるまでに時間はあと何日かかるのか」「費用はあとどれだけかかるのか」「リソースはあとどれだけ必要なのか」を見つめるために、進捗をはかるのだ。過去に費やした努力も費用も、汗も涙も、直接は関係ない。それは過去の領域に属することがらだ。進捗管理は未来志向の営為なのである。過去の出費や時間を記録する唯一最大の理由は、これまでのトレンドや生産性を知って、今後の予測の参考にすることにある。

たとえていうならば、あなたが知らない街でタクシーに乗っていて、目的地までの進捗を知りたかったら、料金メーターだけを見つめていてもはじまらない。それは過去に走った距離を示すに過ぎない。本来ならば、目指す地点まで、あとどれくらい距離があるかを聞くべきなのである。

あるいは、10日分の仕事があったとして、現在、5日経ったからといって、進捗率を単純に「50%」と考えてはいけない。仕事はあと何日分残っているのか、いつ終わりそうなのか、を考えるべきなのだ。あと8日分かかりそうならば、進捗率はあいにく20%ということになる。仮にもし、あと5日分のところまできていたとしても、例えば次の日、顧客の気まぐれや上流側の設計変更で、やはりあと7日かかりそうだ、という状況になったらどうするか。その場合は、「残念ながら今日は進捗率30%まで戻りました」と報告すべきである。

「進捗がマイナスになるような報告なんて許さない」と上司や顧客が言ったらどうするか(そういう残念な人はけっこう多い)。その場合は、“あなたは事実を直視する勇気のない人だな”などと、心の内で思ったりしてはいけない(きっと顔に出るから)。かわりに、「ゴールが遠のいたので、進捗は50%のままです。ただ、そのために生産性が当初予定より下がってしまいました」と答えるべきだ(=現在仕事の半分が残っている建前で、あと7日かかるのだから、この先の生産性は5/7=71%くらいになる計算だ)。もちろん、そんなヘンな計算をするよりも、事実は事実として記録する方が、次回以降の参考になる。事実を直視しなければ、きっとまた同じ失敗を重ねるだろう。どちらがいいか、落ち着いて考えれば分かることだが。

話を戻すと、このような形で進捗をとらえたら、それを工程表に記録(アップデーティング)していく。その方法については「イナズマ線と二重線 -- 工程表のアップデーティングとは何か」http://www2.odn.ne.jp/scheduling/SCM/Onepjmgt.html#anchor5122 に書いたばかりだから、ここには繰り返さないけれども、元々の予定線と、現実とを比較する訳だ。

まとめると、進捗管理とは次のような作業になる。
(1)作業の現状を把握する
(2)完了までの残りの作業量/作業期間を推定する
(3)工程表をアップデートして、予定と現実を比較する
(4)予実の乖離問題が見つかった場合は、是正策を講じる
この(1)〜(4)のサイクルを、定期的に、全部が完了するまで繰り返すのが『進捗管理』である。英語で言うと、"Progress Control" (あるいは"Schedule Control"とよぶ場合もある)。

管理といっても、ManagementではなくControlの領域に属することに注意してほしい。そしてコントロールの出発点は、事実認識である。もちろん事実の中には一般に、良いことも、そうでないこともある。だから、都合のわるい事実認識を拒む官僚主義は、進捗コントロールの最大の障害なのである。



進捗度
Progress Measurement
「革新的生産スケジューリング入門」第2章講義13

進捗管理に用いる指標。プロジェクトの進捗度はふつう、どれだけのタスクが完了したか、および重要なマイルストーンを通過したか、の両方にウェイトをつけて定義する。



スケールアップの法則
Law of Scaling-up
「革新的生産スケジューリング入門」第2章ディスカッション4

システムのスケールが大きくなると、量的な差が質的な違いを生む、という法則。質量転化の法則といっても良い。



スケジュール・コントローラー
Schedule Controller
「革新的生産スケジューリング入門」第2章講義12

大規模なプロジェクトで必要となる専門の職能。各タスクやプロジェクト全体の進捗を把握・監視・督促し、大きな問題が起こった場合には、プロジェクト・マネジャーに対し対応策を要請する。



生産オーダー
Production Order
「革新的生産スケジューリング入門」第3章講義5

工場にたいして発行する生産要求で、品目・数量・納期の情報をもつ。ふつう需要オーダーから未引当製品在庫を引き当てた結果(=正味所要量)が生産オーダーになる。



生産管理
Production Management

生産管理とは何か。この問いは簡単なように見えて、意外と奥が深い。

製造業とは、マテリアルを加工し販売することで利潤を生む企業体である。その企業において、生産活動に直接たずさわる業務の計画・組織化・統制にかかわる仕事を、通常は生産管理と呼ぶ。販売・設計・研究開発業務ならびに会計・人事等の間接業務をのぞいた、いわゆる工場での仕事に関わる『管理』活動と考えられている。

ここで「計画・組織化・統制」なる語を用いたのは、一応これが日本の伝統的な経営学で、経営管理の三要素と呼ばれているからである。したがって普通に考えれば、

生産管理=生産計画+生産組織化+生産統制

という等式が成り立ちそうだが、ことはそう簡単ではない。生産計画という語は実務の場でふつうに使われるが、「生産統制」はめったに聞かず、「生産組織化」となるとまず使わない。「生産組織」だったら多少は分かるが、会社の人的組織図を連想しがちで、語の本来の意図とはずれていく。

そこで、英語のマネジメント・サイクルの概念であるPlan-Do-Seeをもってくる、あるいは継続的改善のPDCAサイクルを持ってこようか、と考えることになる。しかし、Production Planという語はあるが、Production DoだのProduction Actionだのといった言葉は存在しない。なにか言おうとするとExecutionやControlなどの語を引っぱり出さなくてはならない。

このように、生産管理という概念をWBSのごとく仕事の部分品に分解して組み立てる説明は、あまりうまく行かない。それでは、目的から説明したら、どうだろうか?

以前紹介した良書「SEのためのMRP」の著者・鳥羽登氏は、同書の冒頭で
 「『最小の在庫で、顧客の納期を守ること』
  このことは、生産管理の最も重要な課題である」
と書いている。これは、なかなか含蓄の多い言葉だと思う。

在庫最小で納期を守ること。これはすなわち、供給線を需要線に一致させることだと言いかえてもよい。私はマテリアルの累積供給量と累積需要量をグラフに描いて考えることが多いが(このような図表を『流動図表』と呼ぶこともある)、このグラフ上で供給の線が需要より上にずれれば在庫になり、下にずれれば納期遅れになる。

でも、果してこれだけを達成すれば、生産管理の仕事は完璧か? たとえば、最小の在庫で変動にどう対応するのか? あるいは、製造原価の制約を考えずに納期だけ守ればいいのか?

むろん、そんな単純なことではない。だから鳥羽氏は、目的だとは言わず、最重要課題だと言っている。生産管理業務には、他にも課題があるのだ。生産効率だとか製造原価だとか品質だとか生産の自由度だとか。つまり、生産管理は本質的に多目的な問題なのだ。

そして、その多目的性ゆえに、生産管理には統合の視点が必要になる。ちょうどPMBOK Guideがプロジェクト・マネジメントの中心要素としてプロジェクト統合管理なる概念を導入したように。

生産とは、大きく見れば、インプットをアウトプットに変換する機能を持つシステムである。その入出力は、
(1)インプット:生産オーダーなどの需要情報、ならびに原料・部品・副資材というマテリアル、
(2)アウトプット:製品および副産物などのマテリアル、ならびに品質報告書や製造実績報告などの情報
であり、このために製造設備や用役や作業員などのリソースを占有・使用する。また外部環境として市場動向・法規制・技術動向などがあって、つねに変化している。

そして、生産管理とは、この『生産システム』の円滑な運用のために必要とされる間接業務の全てを指すのである。情報の交通整理のこともあるし、設備の改良のこともあるし、モノの流れを整えることもある。こうした活動全てを“管理”の語で呼ぶから理解しにくくなるのだ。

したがって生産管理の対象範囲は、企業の生産形態によっては、工場内のみならず、設計や調達や物流にかかわることもある。それは生産システムを運転するための総合的な活動であって、そこにはシステムを理解する総合的な視点、そして企業としての仮説(すなわち戦略)が盛り込まれなければならない。

製造業の目標達成のために、このレベルに達してこそ、初めてそれは生産管理の名に値するのである。



生産システム
Production System
「革新的生産スケジューリング入門」第5章

最近会った、あるIT系コンサルから聞いた話によると、この頃は顧客が"As-Is"の現状業務フローを描けなくなってきている、という。ご存じの通り、ERPをはじめとする業務管理のための情報システム構築は、現状業務の姿(As-Is)と、あるべき業務の姿(To-Be)を考えるところから出発する。業務が現状どうなっているかは、ふつう顧客自身がよく知っており、業務フローの描き方さえ説明すれば、顧客が自分で作成できる、というのがこれまでのやり方だった。

「ところが、業務の一部にレガシー・システム(既存の古い情報システム)が組み込まれているのに、誰もその内部のロジックをきちんと理解していないケースが多いんです。」と、彼は言う。「開発した担当者も退職していたりする。だから、何がどうなると、自動補充オーダーがかかるのか、どこをどう押すと、在庫引当にロックがかかるのか、よく知らないまま、習慣で業務を流していたりします。これを改善するのは容易じゃありませんよ。」

私たちは、職務分担によって細分化された機能組織の中で働いている。分業の壁のために、受注から出荷までの生産業務の大きな流れが見えにくくなっている。その上、担当する現業すら完全には理解できないとしたら、自社の生産システムの全体像など、分かるわけがない。『群盲、象をなでる』の状況に近いといえよう。

以前、私はこのサイトで、日本の製造業が共通に抱える問題点について、『特別な我が社』(「考えるヒント」2001/2/03)http://www2.odn.ne.jp/scheduling/SCM/Hints0.HTM#anchor6126 の中でこう書いた。

(業種ごとの特殊性にもかかわらず)日本の製造業が抱えている問題点というのは驚くほど共通性が高い。それは、非常に圧縮した形で表現するならば、『大量・見込生産の体制を残したまま、多品種少量の受注生産に移行しようとしている』ということになる。だから調達から販売までのサプライチェーンのあちこちで、プルとプッシュが混在している。

それからもう7年半もたつが、私の考え方は基本的にかわっていない。では日本の製造業を取り巻く状況の方はどうかというと、不況のトンネルはいったん抜け出したものの、問題点はまだ残ったままだ。むしろ工場の海外展開が広まった分、プッシュとプルの混乱は拡大したとも言える。トヨタ生産方式は多くの会社が導入を試み、現場改善に関しては一定の成果を得たが、受注から出荷までの全体改善としては、必ずしも成功していないように思える(『あなたの会社にトヨタ生産方式が向かない五つの理由』タイム・コンサルタントの日誌から 2008/06/30参照)。

どうしてこうなってしまったのか。それは、我々が自社の生産システムというものを、全体像としてはっきり把握できなくなっているからだ。

私はここで、「生産システム」という語を意識して使っている。JIS の定義では、「システムとは、多数の構成要素が有機的な秩序を保ち、同一目的に向かって行動するもの」(JISZ8121)である。製造業において生産という目的を達成するための統合された仕組みは、まさにこの定義に当てはまる。生産システムは、要素としては、人々と、製造機械と、作業空間(建築)と、そして情報をやりとりするための仕組み(ITシステムや帳票類)から成り立っている。

私が「生産システム」といい、あえて「工場」や「製造部門」などの語を使わない理由は、この方が“機能を持つ仕組み”として意識しやすいからである。我々会社員は、ともすると「組織」や「工場」を恒久的な実体概念として考える傾向がある。これらは会社員としての身分・地位に直結するからだ。しかし、本来、会社組織とか、工場建屋や製造装置などのもろもろは、道具でしかない。機能にフィットするよう、デザインすべきだし、もしもうまくフィットしなければ、デザインしなおすべきものである。

では、その生産システムの機能とは、何か。それは「需要情報というインプットを、製品というモノに変換してアウトプットする」ことである。そのための副次的なインプットとして、原料・部品と用役・副資材などを利用する。

ここで大事なことは、需要情報が主要なインプットである、と理解することだ。これは、高度成長期の見込生産のころの考え方、古き良き時代の「工場」像とはずいぶん違う。昔は、「工場とは原料・部品のインプットを、製品に製造して出荷する仕組みである」というセンスだった。ここには需要情報がない(影が薄い)ことに注目してほしい。作れば売れる時代には、需要情報は重要ではなかったのだ。供給が需要を作り出したからだ。

現代は、もはやそうではない。物不足からモノ余り時代に突入し、市場における競合相手がたくさんいる状況では、生産は需要に同期することが求められる。だからメインのインプットは需要情報なのである。これはすなわち、ほとんどの業種が、今や「受注生産」の形態になってきていることを意味している。家電や一般消費財のような典型的見込生産品でさえ、チェーンストアの毎週めまぐるしくかわる出荷要求に応じて製造することを求められる。

であるとすれば、これに対応する生産システムも、またリデザインされなければならないはずである。当然、その全体像を理解できる人が必要である。理解できないものは、改善できない。だが、それはいったい誰なのだろうか。ミクロを積み上げても、マクロにはならない。「各人がその持ち場で最善を尽くせば、会社全体も良い結果を得る」という局所最適と分業の論理に、ながらく私たちは慣らされすぎてきた。今こそ必要なのは、『生産システム全体のアーキテクト』の登場なのである。



製造管理

日本の生産管理系の用語はややこしい。その最たるものが、この「製造管理」だろう。生産管理と、製造管理とは、同じなのか、違うのか。同じなら、なぜ二つの用語が並立しているのか。違うとしたら、何が違うのか。生産と製造はそもそも違うものなのか。疑念は尽きない。

生産管理』が、製造業において生産システムをつかさどるために必要な、すべての間接業務をあらわす風呂敷みたいな概念だということは、すでに書いた。生産システムの中には、工場内の生産活動みならず、設計や調達や物流にかかわる活動も、しばしば含まれる(どこまでが含まれるかは、その企業の生産形態による。個別受注生産・見込生産・繰返受注生産・連続生産・ファブレス企業等々で、そのバリエーションと守備範囲がことなってくる)。

また、同じ製造業といっても、企業の規模は様々である。社長自身が額に汗して働く町工場からはじまって、工場と本社が同居している企業、本社や営業機能がわかれて工場は生産に専念している企業、複数工場を持っている企業、そして全世界に生産・物流拠点をもっている企業まで、広いスペクトルがある。

一般に企業組織は、量的に大きくなればなるほど、機能別に分化していく性質をもっている。したがって、生産に直接間接にかかわる部門の範囲は、大企業になるほど多くなる。設計や、集中購買や、物流や、生産計画などの諸機能が、工場の外に行ってしまっているケースは珍しくない。

そのため、こうした広義の「生産」にかかわる活動と、工場内で直接作業に従事するための活動とを、区別する必要が出てくる。その場合、後者をしばしば『製造』と呼ぶ。生産は広義の概念で、製造が狭義の概念に相当するのである。そして、その製造を支えるための間接活動を指して、製造管理と呼ぶのだ。

ちなみに、英語では生産はProduction、製造はManufacturingであるが、この両者を広義と狭義で厳密に使い分けているかというと、必ずしもそうではない。たとえばMRPUはManufacturing Resource Planningの略と言うことになっているが、カバーしている範囲は明らかに購買も受注(販売)も含む広義の生産活動である。

もう一つ、MESという言葉もある。これは情報システム系の用語で、Manufacturing Execution Systemの略だ。もともとはAMR Researchという機関による造語で、日本語では製造実行システムと訳しているが、なんだかあまりしっくりこない。そこでしばしばこれは、『製造管理システム』とも呼ばれる。ここにも製造管理が出てくる。

しかし、これは実はなかなか穿った訳語なのである。もともとAMR Researchでは、製造業の情報システムとして、「三層モデル」というものを考える。最上位層は、本社レベルにおける生産のマクロな計画と管理である(これを「計画層」Planning Layerとよぶ)。最下位層は、工場現場における機械設備の運転と制御である(「制御層」Control Layer)。そして、その中間に、工場の製造手配と進捗把握のための活動が来る(これを「実行層」Execution Layerとよぶ)。

これらの階層は、そのまま働く人間の職位につながっている。計画層は本社の生産企画部門、実行層は工場のホワイトカラー管理職、制御層は現場の職工である。また、情報システム的に言うと、最上位のERPシステムと、現場の制御システムをつなぐ立場として、製造実行システムMESが来る、という位置づけになる。整理すると次のような形だ。

(1)計画層−本社管理者−年月単位・工場単位・製品群単位のマクロな視点−ERP
(2)実行層−工場管理者−月週日単位・工程単位・品目単位の視点−MES
(3)制御層−現場運転員−週日時単位・機械単位・ツール単位の視点−PLC

むろん、これは類型化したモデルであって、いつもこの通りとは限らない。本社で、時間単位のスケジューリングをしている会社もあれば、現場班長が半月分の差立てを決めている会社も知っている。ただ、こう整理すると分かりやすいのだ(詳しくは、工業調査会・刊「MES入門」をご参照いただきたい)。

そして、(1)が広義の生産管理、(2)が狭義の製造管理、にそれぞれ対応していることが分かるだろう。広義とか狭義とかは、すなわちマネジメントのスコープ(責任範囲)のことを差しているのだ。

だから、ERPシステムで生産管理までやるべきだ、とか、いや無理だ、とかいった議論は、そもそもナンセンスなのである。生産管理といい製造管理といったとき、どこまでが必要な管理の粒度(視点の細かさ)なのか、そして判断の自由度をどこまで下ろすべきなのか、それは生産システムの質に依っている。そこの議論を抜かしたまま、情報システムベンダーや経営雑誌の批評に自分の判断をゆだねては、いけない。



製造オーダー
製造指図
Manufacturing Order
「革新的生産スケジューリング入門」第3章講義5

生産オーダーを部品展開して個別の工順作業ごとにおける指示としたもの。品目・材料・設備・リソース・着手日・製造仕様など、製造作業に必要な詳細の情報がすべて指定される。製造実績はこの製造オーダーにたいして登録される。



製造仕様
Manufacturing Specification (確定した訳語ではない)
「革新的生産スケジューリング入門」第6章ディスカッション3

同じ製品を作る場合、生産ラインが異なる場合に使う型リソースや製造プロセスが異なることがあるため、これを定めたもの。一つの製品に製品仕様は一つしかあり得ないが、製造仕様は複数存在しうる。



製番
Order Number(日本の用語のため正確に対応する英語はない)
「革新的生産スケジューリング入門」第2章講義1

受注生産の工場において、資材や作業を区別するために用いる番号。製品の注文を受けるたびに発番する。



ゾーンメルティング法
(筆者の命名による)
「革新的生産スケジューリング入門」第6章講義3.6

切替型連続生産におけるスケジューリング技法で、制約条件が非常にきつい場合に、ハード制約も緩和して初期解を求め、あとで制約を絞って再調整することで近未来の期間内だけは実行可能解を得ることができる。



た−と



タイム・バケット
Time Bucket
「革新的生産スケジューリング入門」第3章講義7

MRPの計算における時間刻みの単位。



タイム・フェンス
Time Fence
「革新的生産スケジューリング入門」第3章講義7

スケジューリングにおける計画確定期間。計画対象期間全体のうち、直近の計画を外乱や変動から守るための保護期間の意味をもつ。飛び込み・特急注文による割込みを許さない『需要タイム・フェンス』と、購買オーダーや製造オーダーをリリースして生産準備に入っている『クリティカル・タイム・フェンス』の二種類がある。たとえば、計画対象期間が2ヶ月あり、そのうち直近1週間が需要タイム・フェンス、直近1ヶ月がクリティカル・タイム・フェンスである、といった関係になる。




タスク
課業
Task

「革新的生産スケジューリング入門」第1章講義3.2

生産スケジューリングにおいて、「なすべき作業」を指す。作業が実際の行為そのものを意味するのに対して、タスクは計画・指示段階の概念である。課業という日本語訳がいちおう存在するが、ほとんど使われていない。これから見ても、日本でいかに計画系の概念が薄弱であるかがわかる。

ある組織が他の部門・組織から生産オーダー購買オーダーなどのオーダー(指示・指図情報)を受け取ったとき、それをタスクとして認識する。むろん、自分自身で課題を設定して、主体的にタスクを作りだすこともあろう。

タスクに対しては、必要に応じてリソースを割り当て、指定された期限をみたすようなタイムテーブルをつくった上で、実行にとりかかる。そしてこれを遂行して、オーダーに示された成果物をアウトプットし、それが検収されることで、タスクは完了となる。これがタスクの生成から完了までのサイクルである。

タスクのインプットとアウトプットとなりうる事柄は、次の3種類である:
(1)マテリアル
(2)リソース(人的資源と物的資源に分けられる)
(3)情報

このように整理することによって、何がわかるか? じつは、これらの組合せによって、さまざまなタスクの種類を表現することができるのである。たとえば、部品というマテリアルをインプットとし、労働力と・機械設備のリソースを占有して、製品というマテリアルをアウトプットとするタスクは、『製造』作業である。

また、仕様情報をインプットとし、知的労働力を占有して、設計図面という情報をアウトプットする作業は、『設計』作業である。同じようにして、『調達』作業や『保管』サービスなど、生産に関わるあらゆるタスクの種類を、統一して表現することができる。

なお、タスクのインプット・アウトプットには、お金は含まれない。一見奇妙に感じられるかもしれないが、お金のやりとり(価値の移転)はオーダーの方に付随するものなのである。タスクはテクニカルな領域に属し、オーダーはコマーシャルな領域に属していると言えよう。

タスクは、必要に応じて、さらに下位のサブタスクに分解し、階層化することができる。この際、サブタスク全体のインプットとアウトプットは、もとの「親タスク」のそれと一致していなければならない。製造作業のタスクを、一連の逐次的サブタスク(作業)に展開して表現したものが工順である。

なお、タスクは、プロジェクト・スケジューリングの世界における、PERTの「アクティビティ」に相当する。両者はほぼ同義であるが、場合によっては、アクティビティをより期間の長い上位概念にとり、タスクを日々のやるべき細かな作業(デイリー・タスク)ととらえるケースもある。たとえばProject Management Instituteが制定したPMBOK Guideなどでは、そうした用語の使い分けをしているが、生産スケジューリングの世界では同じとは限らないので、注意されたい。




な−の



ネット・チェンジ
Net Change
「革新的生産スケジューリング入門」第3章講義11、「革新的生産スケジューリング入門」第5章講義6

MRPにおいて、変更に関係する品目だけを再計算する手法。計算時間は短くてすむ。APSにおいても、同じ手法を用いる。



は−ほ



バックワード・スケジューリング
Backward scheduling
「革新的生産スケジューリング入門」第1章講義4.4

納期からさかのぼって最遅着手日(LPST)を計算し、それを着手日とする方針



バッチ
Batch
「革新的生産スケジューリング入門」第3章講義8

焼鈍や重合などのように、一度材料を仕込んだら、途中で止めることができないような工程(バッチ工程)で一回に処理する量。



バッチ・クライアント
Batch Client
「革新的生産スケジューリング入門」第5章講義6

FP(Factory Planner)のユーザインターフェースを直接起動せずに、入力ファイルとAPIを利用してFPの計算エンジンの機能を利用する方式です。遠隔地のPCからネットワークで問い合わせを自動的に行うことができる



発注点
Reorder Point
「革新的生産スケジューリング入門」第3章講義3

在庫管理とは、モノ(マテリアル)の保管と入出庫を中心とした現物のコントロール作業と、モノの保有数量のレベルを監視・維持・調整するマネジメント作業からなっている。このサイトですでに何度か説明したとおり、在庫とは一種の「時間の缶詰め」であり、あとからやるべき行為(購買や製造)を先に前倒しでやって、時間をかせいでおくという意味ももっている。したがって、在庫数量のレベル維持は、すなわち供給リードタイムのマネジメントでもある重要な仕事だ。

さて、在庫レベルの維持は、消費された量を見ながら、適切なタイミングで適切な量の再手配(注文)をかけることによって行なう。この発注タイミングの取り方に応じて、定期発注か不定期発注かに分類できる。また、発注数量にしたがって、定量発注、定数補充発注、不定量発注などに区分することも可能だ。

在庫数量を監視したり数えたりする仕事は、それ自体が簡単ではなく、コストがかかる。また発注手配のタイミングや量を決め、手配伝票を発行するのだって、やはり手間がかかる。むろん近年は、在庫管理にコンピュータを使用することが広まったため、ある程度この労力は軽減された。とはいえ、そうした仕組みを支えるためには、入出庫のたびに端末に入力記録したりバーコードを読んだり、といった手間や機器コストがかかっているわけだから、結局、コストは薄められて全体に広がったといってもいい。

そこで、荷動きの少ない品目や、単価の安い品目などは、なるべく手間のかからぬ簡易な方法で、在庫レベルの維持をはかりたい。このために広く用いられているのが、発注点法式である。

発注点方式では、資材の在庫の推移を見て、それがある一定の決められたレベル(これを「発注点」という)を切ったら、最も経済的な発注量(EOQ)を手配して、つねに在庫量が適正な状態になりようにはかる方式だ。手配量の側面から見ると、定量発注方式に属する。手配のタイミングは不定期となる。

発注点の数量はどのように決めるべきだろうか。原則として、その品目の手配をかけてから供給されるまでの期間(発注リードタイム)に、消費によって在庫ゼロ(欠品)が起きないようにするのがよい。すなわち、次の式のようにする(より正確には安全在庫量を加えるべきだが)。

発注点(個数)=発注リードタイム(日) × 平均消費速度(個数/日)

発注点方式は、単価はあまり高くないが、量や種類の多い資材の発注管理に使われる技法だ。この対象を選び出すにあたっては、よく在庫量のABC分析を行なって、BC品目を選び出す。ただし、使用量(需要)変動があまりにも間歇的でアバレのひどい品目には向かない。したがって、使用実績の時間経過をみるデータがとられていないといけないことになる。

なお、発注点方式では、在庫の棚や箱からモノを取り出して、ある数量まで減ったら、自動的に発注手配用の依頼伝票が中からでてくる、などの工夫をするとよい。こうすると、いちいち在庫数量をモニタリングする手間がいらなくなる。以前紹介した「ダブルビン法」も、この簡易版発注点のひとつだ。逆にいうと、コンピュータで在庫量を定期的に計算・監視して、発注点を切ったら手配をかけるという方法は、ある意味で定期発注方式と大差のないやり方だともいえる。使い分けと意義を、あらためて考えるべき時かもしれない。



バリエーション・リダクション
Variation reduction
「革新的生産スケジューリング入門」第3章ケーススタディ2

個別受注生産における設計・製造上の方針。個別受注生産方式をとっているメーカー(産業機械などに多い)にとって、部品点数の無制限な増加はつねに悩みの種である。部品点数の増加は、同時にBOM工順の増加、部品在庫量の増大、発注リードタイムの増大、設計手数と図面枚数の増大など、数々の問題をもたらす。

規格の決まったカタログ部品は、ある程度見込みで生産するため、サプライヤー側も在庫がある。したがって発注リードタイムは短い。しかし個別仕様の部品はどうしても納品までのリードタイムが長くなる。つまり、製品の多様性と、発注から入手までのリードタイムとの間にはトレード・オフの関係があるのだ。多様で細かい注文が可能な製品の入手リードタイムは長く、カタログ的にパターンの決められた製品は入手がはやい。

逆に考えると、もし購買のリードタイムを短くしたければ、製造に使う部品や資材をパターン化して、種類を少なくした方がいい、ということが分かる。そうすれば生産の全体リードタイムがかなり短くなる。リードタイムが短くなれば、年間の生産能力も上がる。

しかし、個別設計の機械部品の場合、ボルト・ナットや一部の計器などの汎用部品は共通化できるが、あとは中核部品も周辺部品も、種類は同じでもサイズはほとんど別物になってしまう。ほとんどの部品は毎回、仕様を決めては発注し直すわけである。製品種類は多様なのに、部品の種類だけを減らすことなんかできない、と考える人が多い。

それでは、どうするか。このために登場するのが、モジュール化によるバリエーション・リダクションだ。これは、多様な製品を生み出すために、組合せを使う手法である。

たとえば、100種類の製品を作るために100種類の部品を毎回設計しなおすかわりに、10種類の部品群と10種類の部品群の組合せで実現する。こうして、部品の種類は20種類におさえながら、かけ算で100種類の製品を可能にできる。これがモジュール化の力だ。これを実現するためには、部品群の設計において、ある程度グループ・テクノロジーを使う必要がある。これは金属加工部品を念頭においていえば、部品をなるべく共通の母型から削り出すように設計する方式だ。

しかし、ちょっと待てよ、と思う方もいるだろう。理屈の上では、組み合わせて100種類作れるとしても、客先の注文にぴったりあうとは限らない。性能の点で余裕がでたら過剰仕様になるではないか? これは、そのとおりである。余分な性能は、その分よけいにコストがかかることを意味する。それに、設計のやり方もがらりと変えなければならない。

これに対する回答は、こうだ。お金の時間的価値(The Time Value of Money)の観点から見れば、材料費のアップよりも、設計時間や生産リードタイムの短縮の方が、ペイすることが多い。その条件は企業によりまちまちだが、算定することができる。ペイすると分かったら、バリエーション・リダクションを導入するべきだ。そして、たいていの企業では、このお金と時間のバランス判断をしないまま、単にコスト削減だけを追っているのである。

このように、スケジューリングの問題点を深めていくと、設計による解決にたどり着くことがしばしばある。だからこそ、設計と製造の統合された企業が望ましいのである。




パンチ・リスト
Punch List

パンチ・リスト(punch list)とは、片付けなければならない作業のリストのことである。英米では、エンジニアリングおよび建設業界を中心に、ほとんど普通名詞として通用しており、契約書等にもごく当たり前に登場する。我が国でどこまで広く使われているかは不明であるが、利用範囲の広いツールなので、ここに紹介する。

パンチ・リストは一般に、残務としてやらなければならない作業タスクの表の形になっている。つまり、ある設計図にしたがって進めた構築作業がほとんど完了に近づいたとき、実物が顧客に検収され実際に使用可能な状態になるまでにクリアしなければならない項目を整理し共有するために、パンチ・リストは作られる。日本の建設業界では、これを「残工事」とか「ダメ工事」のリストと呼ぶことが多い。一部の重工・機械業界でも似たようなリストをつくって、残務を追いかけることが多い。

周知の通り、複雑な構築物や製品・システムなどを作る場合、横軸に時間をとり、縦軸に進捗度をとると、一般にS字型のカーブを描く。初期は立ち上げ段階のため進捗があまり上がらないが、中期には右肩上がりに進行していく。しかし、最後の段階になると、また傾きは緩やかになり、なかなか100%に到達しない。その傾向はとくに90%をすぎた頃から顕著になる。

そのため、最後の段階では、もはや進捗率によるコントロールはあまり役に立たなくなってくる。そこで、パンチ・リストが登場するのである。作るべきものは、ほぼ出来た。ただ、製作上のミスや不手際、部品材料やツールの欠陥、大詰めになって明かるみに出た設計上の不具合、そして後回しにされたペンディング事項、などがある。これを一まとめにしてリスト化し、追いかけるのである。ちなみに、残務をつぶしていくことを、英語では"punch killing"という、いささか穏やかならぬ言葉で表現する。

パンチ・リストは、1行に1項目、やるべき作業を書いていく。各行には通常、次のような項目が並ぶ。
(1) 整理番号(→これをきちんと採番しておくことは重要)
(2) 作業内容(簡単な記述)
(3) 責任者
(4) 発生日(リストへの登録日)
(5) 優先度
(6) 完了期限
(7) ステータス(未着手/作業中/検証中/完了/キャンセル、等)
(8) 実績完了日
(9) その他の注記事項

なお、(5)優先度は、一般にA/B/C等で最低3段階の区分をつけるとよい。たとえば、Aパンチは必須の作業で、これを完了させない限り、仕事全体が先に進めない事項とする(たとえば配電盤にトラブルがあり、全体が動作テストに入れないような場合)。Bパンチは、重要だが、なしでもなんとか先に進めるような回避手段がある場合とする(たとえばスタンバイ装置が誤作動するが、メイン系統でとりあえず運転が可能になる場合)。そしてCパンチは、最終引き渡しまでに終わらせておけばよい、化粧直し的(cosmetic)な作業である。

そして、たとえば試運転段階あるいは顧客との引渡し段階において、「Aパンチはすべて完了、Bパンチはすべて何日までに完了のめどがたっている」といった状態に持ち込んでいれば、残務付き引き渡しの形で交渉が可能となるのである。

なお、上の項目を見れば分かるとおり、パンチ・リストは実際にはタスク・リストないしTo Doリストと同じ形をしている。すなわち、これは、当初の計画と現実との差違を明らかにして、両者をすりあわせるための道具なのである。したがって、パンチ・リストはかならずしも製造や工事の最終段階でのみ使うべきものではなく、たとえば要件定義段階や設計段階、あるいは調達段階などでも利用できるツールなのである。そのような意味では、パンチ・リストとは、しばしば用いられている「課題管理表」と同じカテゴリーのツールであるとも考えられる。

そしてまた、パンチ・リストは、案件が終わった後の事後検証、ないし品質改善のための分析対象としても、大きな価値がある。なぜなら、事前の契約や設計と、現実の構築結果との差違こそ、リスク因子そのものを表しているからである。そのような意味でも、パンチ・リストは作るだけでなく、集積し分析するような仕組みを組織内で確立することが望ましい。



ひも付け
Pegging
「革新的生産スケジューリング入門」第2章講義1

工場内おける資材と工程のコントロールのために、ある部品や材料が最終的にどの製品に使われることになるか、関連づけを示す情報を持つこと。日本では製番(受注番号)を使ってコントロールすることが多い。



ファントムBOM
Phantom
「BOM/部品表入門」第6章Q5

生産計画とスケジューリングのためにMRPAPSに登録するBOMは、ストラクチャー型が原則である。ストラクチャー型BOMは、最終製品(End Item)から、その構成部品、さらにその構成部品、と上流にたどって、購買原材料まで順に展開して表現したものである。中間部品・中間製品をすべて登録したもの、と言いかえてもよい。

それでは、原材料から加工段階を通って最終製品までの製造過程上に現れる、中間的形態のマテリアル(品目)全てをストラクチャー型BOMに登録するかというと、そんなことはしない。BOMマスタにマテリアルを1種類登録すれば、それだけデータの保守・更新の手間と費用が増える。したがって、BOMへの登録品種数は、できれば少ない方がよい、と実務家は思っている。

BOMマスタにマテリアルを登録するかどうかの基準は、そのマテリアルが在庫管理の対象となっているかどうかで決まる。その中間製品が在庫管理の対象ならば、それはBOMに登録すべきである。逆にいえば、加工されてできあがる端から、次工程に消費されて、なくなっていく中間部品は、BOMに登録する必要はない。たとえば、ベルトコンベヤで何段階も工程が並んでいるとき、ふつうはBOMにはコンベヤに供給される末端の品目だけを登録し、途中段階で少しずつできあがっていく中間製品は登録しない。在庫として管理する対象ではないからだ。

ところが、こうした在庫対象ではないはずの中間製品を、あえて、BOMマスタに登録することがある。これを『ファントム』あるいは仮想部品、などと呼ぶ。ファントムをBOMに登録すると、いったい何の役に立つのだろうか?

典型的な例は、ふだんは次工程にすぐに使用されて無くなってしまうけれども、まれに何かの事情(機械トラブルや組み付け相手の品質不良など)で、前工程の完了後に現場保管されることがある品目を、ファントム扱いにするケースである。後に同じ製品の製造指示が出たときには、現場保管の在庫分を先に引き当て処理して使っていく。こうした中間製品は、ファントムとしてBOMに登録しておくとよい。

MRP/APSのBOMマスタ上では、ファントムは製造リードタイムをゼロに設定し、ロット・フォア・ロットで作るように設定する。

すると、MRP/APSで計画を立てる場合、ファントムの在庫がゼロの場合は、処理を飛ばしてすぐ下の部品階層に行く(そしてふつうファントムは在庫ゼロである)。しかし現場在庫が残ってしまった場合は、それを引き当ててから、下の部品の正味所要量を計算するように動くはずだ。

また、返品の発生しがちな業界(たとえば再販制度のある出版業界など)では、顧客からの返品の再利用にもファントムは役に立つ。通常、返品された製品は、いったんばらして不要な外装などを捨て、中核の健全な部分だけを再利用する。このときに、その中核部分(書籍ならカバーと帯をはぎとった本)をファントムとして登録する。このような中核部分は、裸のまま仕掛り在庫としてとっておかない。しかし、ファントムを登録すると、返品の再利用にそれなりに有用である。

また、つねにセットで使うことが分かっている部品群を「キット」として扱う場合も、ファントムで登録すると便利だろう。

このように、ファントムを上手く使うと、製造現場での運用上のニーズを、BOMマスタとMRP/APSにうまく反映させることができる。BOMの実践的なテクニックの一つだと理解すべきであろう。



付加価値
Added Value
「BOM/部品表入門」p.166

いつだったか、「タクシーはとても付加価値の高い乗り物です」という広告を見たことがある。マンガ風の絵で、自動車がお客さんをおぶって走っている。タクシーは楽だ、と言いたいのだろう。しかし、私は可笑しくて吹き出したくなった。付加価値が高いとは、売値に比べて儲けの比率が高いことを意味する。これでは、宣伝の意図とは逆に、“タクシーは実はとても原価の安い乗り物です”と主張してることになるからだ。

『付加価値』という言葉は、かくのごとく誤解されやすい。付加価値が高いというのは、売り手にとって重要なことだが、買い手は商品の価値そのものしか興味がない。買う価値のあるモノだから、買うのだ。だから上の広告は、本来なら「タクシーはとても価値の高い乗り物です」と書くべきだった。いや、もしかしたら、低賃金を抗議するために、運転手がわざとそんな広告を貼ったのかもしれないが。

こんな誤解がまかり通るようになったのは、長かった不況の時代に、“いかにして製品の付加価値を上げるか”という議論を皆がしてきたからだろう。その結果、付加価値を上げることが善であるばかりか、買い手にとっても善であることになってしまったらしい。そもそもの目的や意義を忘れて手段ばかりを議論しがちな、我らが社会ではよく見かける現象である。

さて、製造業における付加価値とは、簡単に言うと次の式で定義される:

 付加価値=販売高−材料購入費

製造業とは、マテリアルを加工し、付加価値を付けて販売するビジネスだ。付加価値こそ、利益や賃金や設備投資をはじめとする全ての資金の源泉なのだ。だから、この式の左辺をいかに大きくすべきかを、必死に工夫しなくてはならない。

その付加価値の源泉とはどこにあるのか? 反応や精製だ、と化学工業の人は答えるかもしれない。加工や組立だ、と機械工業の人は考えるだろう。いずれもモノの形や性質を変える製造工程が価値の源泉だと信じている。

一方、搬送だの保管だの検査だのといった作業は、モノに直接の影響を与えない。だから、物流や品管部門は付加価値を生み出さない、余計者のように扱われがちだ。事実、物流部門はまっさきにアウトソーシングと人員削減の対象にあげられる。

ところで、よく考えてほしい。顧客に製品を販売するとき、その製品が消費地から500km離れた地点にあったら、顧客は買ってくれるだろうか。その製品が壊れやすいかもしれなかったら、誰が喜んで買うだろうか。だから顧客が必要なときに、必要な場所で、必要な信頼性を提供する物流や品管の仕事は、あきらかに価値を付加しているのだ。

付加価値はふつう、製品仕様の差別化で生み出されると考えられている。それは確かに事実だ。しかし、提供場所と時間(納期)や、安心料(保険料)もまた、付加価値をつける有力な手段なのだ。

そして、もうひとつ、誰もが忘れがちな点がある。それは、販売業務それ自体は、製品に価値をほとんど付加しないという点である。だから、営業部門が物流部門を下に見るような組織があったら、その企業はどこかおかしいと考えた方が良い。



付加価値生産性
Productivity

付加価値とは、企業が生産を通じて新しく生み出した価値であり、端的に言えば販売額から材料購入費を差し引いたものだ。材料購入費はサプライヤーに対して支払う金額であり、そのサプライヤーにとっては販売額になる。したがって、付加価値の計算は、買い手と売り手の分を合計すると、取引額が相殺されていく関係になる。もし、ある企業が工場を分社化して子会社とし、そこから製品を仕入れて販売する形態に変わったとしても、親会社と子会社の付加価値の合計額は変わらない。

この計算を、サプライチェーンのずっと源流までたどって集計していくとどうなるか。ちょっと考えればわかるはずだが、これは国民総生産(GDP)に等しくなるのである。つまり、一国のGDPとは、その国が生み出した付加価値の総計になるのである。だから、計算上は儲かるからと言って、製造やサービスの仕事を単価の安い海外にアウトソースしてしまったらどうなるか、容易に想像がつくだろう。その国の経済全体がしぼんでいくのである。これはすでに米国で起こりつつある現象だ。

さて、生産管理の主要なテーマは、最小の在庫で納期を守ることである。納期を守るというのは、顧客との約束を守ることであり、それ自体は“できて当たり前”のことだ。納期厳守を実現するために、どれだけ費用を使ってもいいなら、誰も苦労はしない。問題は必要最小限の在庫で、の部分である。在庫とは、その期に外部から購入する材料の結果であるから、材料購入費に集約される。言いかえれば、生産管理の主要なテーマとは、納期通りの出荷を達成し、外部からの材料購入費を下げること、つまり付加価値の増大にあるのだ。

生産管理の主題が付加価値の増大にある、ということは特筆されて良い。なぜなら、この基本中の基本が、どうやらしばしば生産現場で忘れられているからだ。その典型例が生産性の定義をめぐる混乱である。

最新鋭の機械を導入した、あるいは、一人屋台方式やセル生産を導入した、だから生産性が何割上がりました、といった議論をよく見かける。生産性とは何か。生産高を人員数で割ったものなのか。つまり、人が減れば生産性向上なのか。それだったら、最終組立工程以外は全部外注員にしてしまえば、労賃は元のままでも生産性が上がることになる。いや、工場長以外、全員外注にしてしまえば世界一の生産性であろう。これが生産管理の目標とは、誰も思うまい。

あるいは逆に、一人屋台生産にして直接作業比率が上がり、仕掛り在庫が減りました、という議論はどうか。部品を配膳・供給する仕事は分業させて、誰か別の人間に振り分けた訳であろう。これも、最終組立工程の能力を最大限活用する面では有意義だが、工場全体の人数は(とくに自社内で材料部品加工まで行なっていれば)動線をぐっと短縮しない限り大きく減ることはない。

こういう、社員一人あたりの生産額(販売額)の議論を続けていく限り、かならず行き着く先はアメリカと同じ、全面アウトソーシングである。そして、国内の失業率増大と国民所得減少ばかりに貢献することになる。

それでは、生産性を何で計るべきか。答えは、労働時間あたりの付加価値額なのである。労働人員あたりの付加価値額で計算する場合もあるが、派遣社員やパート比率が大きくなると、比較できなくなるので、最近は時間あたりの方が良く用いられる。つまり、作業者一人1時間あたり、どれだけ付加価値に貢献しているかを測るのだ。

こうすると、単なる外注化では、生産性向上ができなくなる。内製工程を丸ごと外注すれば、材料購入費にはねかえって、全体の付加価値が落ちてしまう。工場労働者を派遣社員に切り替えても、労務費は付加価値の計算に影響しないので効果がない。

そこで、まじめに生産を計画し、需要と必要在庫を予測し、指示を同期化し、不良率を下げ、レイアウトと工程作業を工夫して、地道に一人1時間あたりの付加価値を上げて行くしかない。つまり、普通にいわれている生産管理を実行するしかないのだ。もし外注化で生産性を向上したければ、賃金の低いものを出すのではなく、「付加価値への貢献の低いもの」を出した方が良い。

ちなみに、一人1時間あたりの付加価値額と、1時間あたりの労働賃金の比率を、『労働分配率』という。労働分配率は、日本の全企業平均では50%程度だが、製造業では60%近い(つまり生産性が低い)。これが100%を超えたら、賃金を払えず事業が成り立たないない訳であるから、付加価値生産性は、その事業が人を養う力があるかを示すことになる。だからこそ、これをいかに大きくするかが、工場の最大のテーマなのである。



不定貫

「BOM/部品表入門」第5章Q1

組立加工を中心としたディスクリート型製造業の世界では、ほとんどのマテリアルは「個数」で数えられる。生産計画・製造・物流・購買・販売などの、生産に関わるほとんどの業務は、個数でコントロールされる。中には荷姿の関係上、「枚数」や「メートル数」で扱うものもあるが、考え方は同じである。それゆえ、生産スケジューリングや在庫管理などのシステムもまた、個数ベースでハンドリングされる。

ところで、搬送や保管などの物流作業においては、個数ではなく重量で表わす方が便利だ。ナット1個とエンジン1個ではずいぶん違うから、全部で2個を搬送しますと言っても意味がない。単位を重量にすれば、両者を足し算して総重量を計算する意味も出てくる。

そこで、情報システム上は、1個あたりの重量をマテリアル・マスタに登録しておいて、個数から重量に換算する方法をとる。世の中の大抵の生産管理システムはこうした仕組みをもっている。

ところが、商品の中には、個数と重量の関係が一定しないものがある。たとえば、材木である。同じ1本でも、材質のむらのために、重量にはばらつきがある。あるいは、食品工業で扱う材料、たとえば生ハムや冷凍マグロや毛蟹などもそうだ。1本あたりの重量は、かなり巾がある。よしんば大中小のクラスに分かれていたとしても、巾ができることにかわりはない。こうした商品を「不定貫」と呼ぶ。これに対して、個数と重量の関係が定まっているものは「定貫」商品と呼ばれる。

不定貫のマテリアルは、搬送や保管は本数単位で行なわれるが、製造への投入や、取引の精算は重量単位で行なわれる。そして、両者を結びつけるために、必ず「計量」という行為がどこかで入る点に特徴がある。

不定貫商品は、生物起源の材料、すなわち農産品・水産品に多い。だから食品工業で、よくお目にかかる。また逆に、食品工業だけの特殊な習慣だと理解する向きも多いだろう。しかし私は、案外多くの業種で「不定貫」の考え方が役にたつのではないかと考えている。

たとえば、機能性材料を扱う業界や、先端的な電子材料を扱う業界においては、歩留りの巾が大きい。バッチ生産やロット生産において、仕込む原料は一定量だが、どれだけが製品になるかは毎回ちがう。このような工場では、工程間のスケジューリングはロット個数(あるいは容器数)単位でコントロールするが、在庫数量は計量ないし品質検査後にはじめて確定する性質を持つ。つまり、それまでは不定貫扱いなのだ。

また、シートやロールで扱わなければならない業界にも、似たような特性がある。100m巻のロール1本から20mを切り出した後でも、ロール1本には変わりないのだ。こうしたマテリアルは、裁断工程を必ず伴うが、裁断長の合計と、元の長さは必ずしも合わない。

上記のような業界は、私のいう「切替え型連続生産」の形態をとっている工場が多い。また、一種の容器管理を必要としている場合も多い。「切替え型連続生産」においては、容器管理と不定貫の扱いが必須であると考える所以である。



部品表の精度

「BOM/部品表入門」第2章Q6

誰かに、あなたの会社の部品表(BOM)の精度はどれだけありますか? とたずねられたら、あなたは何と答えるだろうか。部品表の精度? 何だそれ? というのが、大方の反応ではないだろうか。

製造業において、精度という概念はたいてい品質管理にからんで使われる。加工精度とか、位置決め精度とか、施工精度とか。何らかの設計情報があって、それを製作し実現したときに、どれだけのばらつきの中に収まるかを調べるための概念だ。

それでは、設計情報そのものの表現である「部品表」について、精度を問う意味はどこにあるのか。全部正しいに決まっているだろう−−そんな反論も聞こえそうだ。

ならば、こうたずねてみよう。あなたの工場の、在庫精度はどれだけですか? 在庫管理担当者なら、これにはすぐ答えられるはずだ。彼らは、定期的に「棚卸」業務を行なっている。在庫量には、理論在庫量と現実在庫量がある。期初の在庫量に入庫数と出庫数を足し引きすると、期末の在庫量になる「はず」だ。これが理論在庫量である。

理論は現実に本来一致するはずだが、いろいろな事情でずれが生じてくる。たとえば破損とか、臨時の戻し入れとか、品質チェック待ちとか。そのずれを更正する作業が棚卸である。そして、在庫精度は、理論在庫量と実際在庫量の差異によって、0.3%だとか1.4%だとか計算できる。

同じように、データの削除や追加のあるマスタ情報だって、量が多ければズレが生じる確率は高くなる。BOMは、まさに新製品や設計変更や改廃があるマスタ情報である。ことに、設計部品表(E-BOM)と製造部品表(M-BOM)の2種類が分立している会社なら、ズレの可能性も非常に高い。だとしたら、BOMの棚卸を行なって、現実の姿との差異をチェックし、精度を計算すべきだろう。

BOMの精度は次式によって定義される:

      BOMが正しく登録されている製品・中間製品の数
BOM精度=−−−−−−−−−−−−−−−−−−−−−−−
           製品・中間製品の全数

この正誤の判定は、直接の親子関係を単位として行なう。たとえばBOMのマスタ上で、製品Aが中間製品X2個と、購入部品Y3個からできており、中間製品Xは購入部品v1個とw4個からなるとしよう。しかし、工場での実際の製造工程は、z1個、w4個から作っているとする。その場合、XのBOMは誤りである。しかし、Aが事実X・Y1個ずつから作られているのならば、AのBOMは(孫に誤りがあっても)正しいと認定する。もしこの企業が、製品Aのみを作っているのなら、BOMの精度は1/2=50%である。

在庫数量に誤差があると、生産計画が狂ってしまうことは容易に分かるだろう。したがって定期的に棚卸を行ない、在庫精度を高める努力をすることは意義のあることだ。同様に、BOMが正しくないと、MRPの部品展開計算が正しく行えないから、製造スケジュールや購買手配がズレてくる。まともな生産計画や購買計画を支えるのは、精度の高いBOMなのである。

しかし現実には、BOMの精度をきちんと測って評価している企業は極めて稀だ。在庫棚卸作業は、会計報告上の必要から、最低でも半期ごとにふつう義務づけられている。しかし、目に見えぬ情報としてのマスタデータは、棚卸の必要がないと、みなが信じ切っているようだ。ここらへんが、実物経済の落とし穴だろう。

部品展開計算は生産管理の基本である。最近のERPパッケージの生産管理はほとんどがMRPUをベースにしているし、APSもまた部品展開を内部で計算する。こうした道具を使って生産を効率化したければ、基準情報であるBOMの精度に注意を払うべきだ。米国の生産管理コンサルタントの大御所オリバー・ワイトは、在庫精度が95%以上、BOM精度が98−99%以上なければ、MRPは導入しても使い物にならない、と書いている。巨額の情報投資を無駄にしないためにも、BOMの精度を向上させよう。



プル型生産システム

生産において、原料に近い上流側の工程(作業)が製品に近い下流側工程に、マテリアルの使用を指示し、その量とタイミングを通知するしかけをプッシュ型生産システムという。典型的には、上流工程が製造した半製品・中間品を下流工程に引渡して、「じゃ次にこれを加工してください」と指示をわたす方式である。ひとつの工順の中は、原則としてプッシュ型となる。

プッシュ型において途中で発生する半製品の仕掛在庫は、原則的にすべて下流工程の使用予定がひも付いている(これを私は「フロー在庫」と呼んで、作りだめのストックと区別する)。プッシュ型の場合、こうした仕掛在庫レベルを決める権限は(そして在庫が過小・過大になったら、その責任も)上流側にある。

逆に、下流側が上流側に、マテリアルの供給を指示し、その量とタイミングを通知するしかけをプル型生産システムという。製品在庫を基準数量だけストックして積んでおき、それが発注点を切ったら補充生産する方式は、その典型である。定量補充・定期補充などの補充も、プル型の供給である。

プル型においては本来、在庫のレベルの維持管理は、下流側に責任がある。使用するのも、注文するのも、下流側だからである。少なくとも、下流側には引取責任がある。

後工程引取り・定数補充のカンバン方式も、プル型である。ただし、カンバン方式では使用者と補充者が分業しており、在庫のレベルの維持管理は補充者側に移る。なお、カンバン方式では資材の現場保管を活用するが、原理的には倉庫を経由しようが、プル型であることにかわりはない。

さて、見込み生産はプッシュ型システムで、受注生産はプル型システムだろうか? どうも、こうした誤解が広まっているようだが、じつはほとんどの場合、その逆なのである。

一品受注生産は、製品在庫量ゼロのプル型である、ように見える。しかし、造船であれ、複雑な生産機械であれ、実は設計の完了が購買を指示し、納品された原料資材を順に加工し、組み立てて、検査して製品にしていく。途中にある仕掛りは、すべて受注に紐づけられたフロー在庫である。上流工程が完了しなければ、下流工程は着手できない。会社全体でみれば、なるほど確かにプル型にふるまっているように見えるが、工場の中は実はプッシュ・システムで動いているのだ。

繰返し受注生産に多い、日本特有の製番管理も、ある意味で、すべての製造作業が、受注オーダー(製番)に紐付いている。そして、原料から製品へ、上流から下流へと、指示とマテリアル供給が連動して流されて行く。したがって工場の中はプッシュ型である。単に資材倉庫がプル型で補充の購買オーダーをかけているに過ぎないのだ。

一方、製品在庫・仕掛り在庫を要所要所に積んでおき、工場の中をすべてプル型で動かしている企業も、最近は多い。『売れた分だけ作る』ジャスト・イン・タイム方式、あるいは「トヨタ式生産システム」などの名前で呼ばれることもある。

売れた分だけ作る、というのは、一種の在庫の定数補充である。それは受注生産のように見えるかもしれないが、じつは、積み上げた在庫には、まだ引当の予定がない。つまり見込みで生産しているのだ。その証拠に、次の日からお客さんが来なくなれば、そこに積み上げた製品・仕掛りはまったくの不良在庫となってしまう。だから、一品受注生産の業界では、製品在庫を持って『売れた分だけ作る』などということは考えられない。これは、ある程度平準化可能な需要の見込める、自動車・家電・日雑業界などでないと適用できないのだ。

そもそも、下流側の使用予約(引当)がされているからと言って、それが最終顧客の実受注にまでひも付いているとは限らない。営業部門が見込みで工場に生産オーダーを出している場合もあろう。それは、各工程の立場からは知りようがない(最近の流行語をまねて言えば「在庫の壁」)。

メーカーが系列卸や販売店にプッシュ供給する(つまり押し込み販売する)ことは、確かにおこりうる。しかし、最終顧客に対しては、計画経済でもない限り、プッシュできないのが普通である。つまり、製造業の会社というのは、マクロに見れば必ずプル型にふるまわざるを得ない性質を持っている。その、マクロなプル型と、社内のプッシュ型の仕組みをどう矛盾なく折り合わせるかが、つねに課題となるのである。



フロントエンド・スケジュール
Front End Schedule

プロジェクトの立上げ期は忙しい。それが納期のある受注型プロジェクトとなれば、なおさらである。まず、プロジェクト・チームのコアとなる要員をアサインしなければならない。社内でプロジェクトの概要について説明する簡単な文書も必要である(それが「プロジェクト憲章」とか「Charter」と呼ばれていなくても、たとえA4サイズ1枚の紙切れでも、とにかくプロジェクトを正式化するための文書がいる)。それから会社のプロジェクト登録簿に登録して、正式なプロジェクト・コードを発番してもらわなければならない(そうしないとタイム・シートもつけられないし交通費も精算できない)。

さらに、受注型プロジェクトの場合は、見積提案書を出した後、客先とのネゴの過程でさまざまな追加要求やら変更やらが入るケースが多い。とくに不況で買い手の側の強い昨今はなおさらである。なんとか注文書をもらえた営業はにこにこ顔で帰ってくるが、プロマネとしては、相手と合意した詳細内容を盛り込んだSOWなり確定仕様書なりを作成して、契約書に添付して提出しないと危なくてしようがない。おまけに客先は下打ち合わせで顔を合わせるたびにまた違うことを言い出してくる。正式キックオフ・ミーティングを開催するまでは、しばらく放って置いてほしいものだが。

そしてもちろん、実行予算の設定と、プロジェクト・マスタ・スケジュールの立案である。概略予算や工程は見積時に検討したが、実ジョブとなるともっと確度の高い計画が求められる。そのためには、スコープにしたがってWBSを展開して、ワーク・パッケージを決めなければならない。おまけにこのごろは、リスク・レビューを実施しろとPMO(Project Management Office)がうるさく言ってくる。だがその前に、社内キックオフを準備する必要がある。客先との連絡窓口や調整手順を定めた業務遂行要領書も作らなくては・・

こんな調子で、最初の2週間かそこらは目が回りそうなスピードで時間がすぎていく。とはいえ、とにかくチーム員を動員したら、その人たちにまずは仕事の指示をしていかなければならない。でも、何から先に、いつまでにやらなければならないのだ? −−それはもちろん、マスタ・スケジュールに規定されているはずである。だが、その肝心のマスタ・スケジュールがまだ出来ていないのだ! いったいどうすればいいのか!?

そのための答えが、「フロントエンド・スケジュール」なのである。Front End Scheduleとは、文字通り、プロジェクトの最初の数週間のみをカバーしたスケジュールである。これをまず、最初に作る。そして、初動期間は、これにしたがって人を動かしていく。その合間に、本式のプロジェクト・マスタ・スケジュールを作成して、正式に配布するのである。

でも、なぜそんな二度手間をするのか? だったら、最初から全体スケジュールを作れば良いではないか−−そう考える人もいるだろう(たとえばあなたの上司とか)。でも、そうは簡単にはいかないのである。プロジェクトの全体工程をカバーしたスケジュールを立案するには、上に述べたように、きちんとWBSを展開して、ワークパッケージを定義し、それぞれに必要な期間とコストとリソースを見積もらなければならない。しかし、まだ設計も要件も揺れ動いている段階で、これを作るのは容易ではない。それどころか、いったん作っても、すぐ変更になるのは目に見えている。なにしろプロジェクトというのは本質的に個別性が強いからだ。全く同じことを繰り返すプロジェクトというのは滅多にない(もしそれが頻繁にあれば、それはプロジェクトではなく日常業務だと言うことになる)。

ところが。じつは、同種のプロジェクトというのは、初動期だけを取り出すと、かなり似ているものなのである。やるべきことは、客先との要件固めと基本設計のすべり出し、そしてプロジェクト組織の立ち上げと計画立案作業等である。個別性でスケジュールに違いが強く出てくるのは、要件や設計がはっきりしてから以降のことなのだ。それは、力仕事的なアクティビティの数や量が変わってくるからである。いわば人間の頭と胴体の関係のようなもので、背の高さや体重は、人により2割も3割も違うが、頭だけ見るとそれほどの違いは無い。プロジェクトの初動期の姿も同じようなもので、プロジェクト全体のプロポーションとは比較的独立して決まるのである。

したがって、フロントエンド・スケジュールは、プロジェクトの種別にしたがっていくつかをあらかじめテンプレートとして用意しておき、実際に案件が開始したら、それを多少カスタマイズして使えばよい。これだったら、作成配布までにたいして日数はかからない。そして、人を動かすことも出来る。客先だって、当面は安心してくれるだろう。このように、マネジメントにおいては、案件の個別性に惑わされずに、できるかぎり普遍性・共通性を見つけ出す姿勢が肝要なのである。




ま−も



マーケット・イン
Market In
「革新的生産スケジューリング入門」第3章講義2

プロダクト・アウトの反対概念。市場の主導権が消費者側にある状態。マーケット・インの時代には、市場が望むものをメーカーが作って出さなければならない。第二次大戦後の、もの不足の時代から五十年間かかって、世の中はしだいにプロダクト・アウトからマーケット・インへと変化してきた。



マイルストーン
里程標
Milestone
「革新的生産スケジューリング入門」第1章講義3.1

プロジェクト・スケジューリングの理論では、日程表の中に書き込む要素を、アクティビティとイベントに大別する。アクティビティは明確な始まりと終わりを持った出来事で、生産スケジューリングにおけるタスクにほぼ相当する。一方、あるプロセスが何らかの達成点に到達する瞬間をイベントとよぶ。たとえば、「卒業式」はアクティビティだが、「卒業」はイベントである。

イベントの中でも特に重要な意義をもつものを、マイルストーンと呼ぶ。マイルストーンはプロジェクト・スケジューリングで大事な役割をはたす。たとえば、基本設計完了だとか、製品の工場出荷などはしばしばマイルストーンとして扱われる。通常、マイルストーンは、そこを通過したら仕事が後戻りをすることはない。仕事のプロセスの逆止弁のような役割を果たす。プロマネにとってはほっと一安心でき、また気持ちをリフレッシュできるタイミングである。

そこで、プロジェクトの進捗度管理において、マイルストーン達成日時の予定と実績を対比して、とどこおりなく仕事が進んでいるかをチェックする方法がある。マイルストーンの予実をリストアップしたものをマイルストーン管理表と呼ぶ。プロジェクトのガント・チャートを書く場合は、マイルストーンはしばしば☆印や旗印などで図中に表記される。

ところで、通常の教科書に書かれているアーンドバリュー分析(EVA/EVMS)の手法では、このマイルストーンはうまく組み込まれていない。最近注目を集めているアーンドバリュー分析は、プロジェクトを構成するすべてのタスクの予算PVと完成出来高EV・実際費用ACを対比して、進捗率およびコストの予実を把握する手法だ。そのベースとなるのはタスク(アクティビティ)の予算である。しかしイベントやマイルストーンには、予算を割り当てようがない。したがって基本設計が承認されようが製品が工場を出荷しようが、出来高EVがちょっと上がるだけだ。気分的にメリハリのないことおびただしい。

そんなのは単に感情的な問題に過ぎないじゃないか、と考えるのは浅慮である。じつは、マイルストーンの達成とは、通常なんらかの不確定性・リスクが大きく下がる瞬間でもあるのだ。設計が固まる、製品がトラックに積み込まれる、これらの瞬間を重要だと人間が感じるのは、その時点において設計変更や納期遅延のリスクが完全に遠のいたからなのである。通常のEVAでは、この意義をハイライトすることができない。

そこで、現実のプロジェクト進捗計算でしばしば採用されるのは、タスク以外にマイルストーンにも何らかの重みを与える手法だ。基本設計承認では、タスクとは別に5%の進捗率アップを計上する、という風に行う。EVAとマイルストーン管理表の折衷的な方法で、理屈の点ではあまり美しくないが、実務上の納得感を与えることができる。

受託型のプロジェクトでは、実際問題として、支払い条件にマイルストーンをからめて設定することが多い。プロジェクトのキックオフで20%、設計完了で40%、製品出荷で80%、検収完了で100%、といった風に、マイルストーン毎に支払いを行う契約である。必然的に、マイルストーン管理表の手法に近づいていく(EVAも「出来高払い」という支払い慣習に根ざして生まれた)。

そもそもアーンドバリュー分析は、プロジェクトのスコープが明確で、WBSを最初からきちんと組み立てることができるような種類のプロジェクトに適している。研究開発初や新製品開発のように、最初の段階ではスコープも納期もあいまいな種類の「ソフトな」プロジェクトでは、むしろマイルストーンで把握していくほうが適切である。

その際にマイルストーンの設定において注意すべきことは、クリティカル・パス上にマイルストーンを置くことだ。そうすれば、マイルストーンの遅れがすなわちプロジェクト全体の遅れに直結するので、注視する意味が出てくる。フロートを持つタスク上に置いたのでは、プロジェクト全体の進捗の指標にならない訳だ。

このようにマイルストーンを適切に使うことは、上手なプロジェクト・マネジメントの証しなのである。



マス・カスタマイゼーション
Mass Customization
「革新的生産スケジューリング入門」第6章ディスカッション1

単一仕様の製品を多量生産するのではなく、個別仕様の製品を大量につくる業態をマス・カスタマイゼーションと呼ぶ。マス・プロダクション(大量生産)とカスタマイゼーション(注文生産)の混合からきた用語である。今日の『マーケット・イン』、すなわち市場のほしがる商品をつくらなければ生き残れない状況下で、必然的に生まれた考え方だ。

世界で初めて自動車の量産をしたヘンリー・フォードは、黒色のT型フォードという、ただ一種類のモデルのみを販売した。「顧客の望む色はどんな色でも売ります−−それが黒色である限り」という、彼の有名な文句はこの時に生まれた。それ以前の注文生産的な(つまり特権階級向けの)自動車製造方式ではなく、大量見込み生産・薄利多売を可能にするためには、製品モデルを一種類にしぼることが条件だと、彼は見抜いたのである。

この販売方式、今風にいえば“ビジネスモデル”は大成功し、フォード社は安価な製品で大きなマーケットを獲得した。そして、ベルト・コンベヤーを用いた流れ作業・分業体制による大量生産は「フォード・システム」と呼ばれて、世界中に広まった。チャップリンが映画『モダン・タイムス』で風刺した単調な労働のはじまりである。

しかし、自動車が完全なコモディティとなった今日では、単一モデル販売では競争に勝つことができない。多様な消費者ニーズに柔軟に対応しなければ、消費者という王様には販売できないのだ。しかし、今さら一品注文生産の悠長な時代にはもどれない。それではどうするか。

このために導入されたのが、製品にさまざまなオプション=選択肢をつけ加えることであった。たとえば自動車であれば、外装の色、インテリアの仕上げ、変速がマニュアルシフトかATか、エアバッグの装備、搭載オーディオ機器のグレードなどなど、かなりの種類のオプションを購入者が選べるのが普通だ。こうして、顧客の細かな好みに合わせていくことが可能となる。

このような製品オプションの導入は、じつはコンピュータ産業でも同じだった。初期の汎用機は注文生産だった。やがて「Apple II」や「IBM PC」といった安価な単一モデル導入によって、大衆向けの市場が作りだされた(むろん、技術革新による小型化も忘れてはならないが)。しかし今日では、PCはCPU速度やディスク容量・メモリ容量など、多数のオプションを選ぶ商品になっている。

このように、一つの産業が揺籃期から普及期へ、そして成熟期へと進化するにしたがい、一品注文生産から見込み生産へ、そしてまたオプション選択の注文生産へとうつっていくパターンが見られる。製品オプションを活用した、このような擬似的注文生産こそ、「マス・カスタマイゼーション」の中心的思想なのである。

オプションを活用した注文生産と、初期の一品注文生産とは、大きな差がある。それは「モジュラー化」の考え方だ。モジュラー化とは、標準的なモジュールの組合せによって、選択のバリエーションを作りだす方法である。これは、すべての部品を注文仕様に合わせてゼロから設計していく、一品受注生産とは根本的に異なっている。注文住宅と、プレファブ住宅の違いと言ってもいい。モジュラー化によって、必要な部品やサブ・アセンブリーをある程度大量に生産しておくことができるようになる。製造コストが下がるばかりか、注文から納品までのリードタイムが圧倒的に短縮される訳である。

ただし、マス・カスタマイゼーションの方式には、困難が一つある。それは、製品在庫を持ちにくい点だ。製品のバリエーションが無数にあるから、それらをすべて製品在庫として持っておくことはできない。個別の注文が確定しないと、製品の製造に取りかかれないのだ。緑色の車体を欲しいという顧客の注文を聞く前に、赤い車体を組立ラインに流しても、それは無駄な在庫になってしまう。

したがって、マス・カスタマイゼーションを実現するには、企業における生産計画とスケジューリング能力を強化して、短納期化を可能にする必要がある。それと同時に、モジュラー化に適した製品設計も必須となる。営業・製造・設計部門がより緊密な協力関係を築かなければ、マーケット・イン時代を生き抜くことは難しいと信ずるべきだろう。




マテリアル
Material
「BOM/部品表入門」キックオフQ4

生産管理やサプライチェーン・マネジメントの世界で、BOM(部品表)や品目コードのことを論じるとき、基本となるのは「マテリアル」という概念である。ところが、いざ正面切って「マテリアルとは何か」と問うてみると、案外きちんと答えられる人は少ない。

BOMが「部品表」ならば、マテリアルは「部品」じゃないか、と思うかもしれないが、それは早計だ。なぜなら、BOMは持っているけれども、部品などというものは使わない、という業界がじつは多数存在する。たとえば、製鉄業。そこにあるのは鉄鉱石や石炭などの「原料」「材料」である。石油精製、化学、医薬品、飲料・食品、ガラス、プラスチック成形、などの業界にもBOMはあるが「部品」という言葉は使わない。似た例はまだある。繊維、アパレル、製紙、紙器、印刷・出版・・などなど。こうした業界では素材や資材はあるが部品はない。

では、「原料・材料・部品・素材・資材・・等々をまとめて、マテリアルと呼ぶ」と定義したらどうなのか。いや、それではまだ足りないものがある。それは、「製品」だ。サプライチェーンの中を流れて行くマテリアルは、サプライヤーにとって製品であるものが、ユーザにとって部品になる。つまり、製品と部品の区別は絶対ではない。同一の会社内においてさえ、両者の区別が絶対でないことは、サービスパーツの取引を思いだしてもらえれば分かるだろう。「製品」とは売り買いの対象になるかどうかの区別でしかない。

それでは、「サプライチェーンの中で流通の対象となるものがマテリアルである」と定義したら完璧だろうか。残念ながら、これでもダメなのだ。これは、ちょっとでも調達系のシステム構築にたずさわったことのある人ならば分かる。製造業における購買の対象がモノだけだと考えてはいけない。たとえば、外注加工というのは「モノ」なのだろうか? 加工の注文書を発行するためには、購買品目マスタに「外注」なるモノを登録すべきなのだろうか? じつは、昔のSAP R/3などはそういうマスタ構成になっていた。それで矛盾がいろいろと生まれて、「サービス」がマスタとして区別されるようになった。

我々が商業的取引において売り買いする物事は、じつは3種類の基本的カテゴリーに分類できる。それは、マテリアル、サービス、情報/データ、の3種類だ。これらは、次のような特性をもっている。

(1)マテリアル:物的な実在性を持っている。在庫できる(資産となりうる)。取引は、所有権の売買の形をとる。八百屋に行ってリンゴを買うのは、マテリアルの取引である。
(2)サービス :物的な実在性はない。したがって在庫もできない。サービスとは、何らかの機能をもつリソース(資源)の占有使用権を取り引きする形である。リソースは人の場合と物的な場合とがある。床屋に行って髪を切ってもらったり、ホテルの部屋に泊まったりするのは、サービスを買っているのだ。
(3)情報/データ:物的な実在性はない。情報は非定型で人間に意味をもたらすものであり、データとは形式化された記号の並びである(そこから意味をくみ取るのは人間の側の作業)。情報・データは資産の一種ではあるが、他人に渡しても自分の手元に残る性質があるため、在庫という概念には意味がない。新聞や音楽CDを買うのは、媒体としての紙やディスクというモノを買っているように見えるが、じつは非占有的な使用許諾権(アクセス権)を買っているのである。

こうした多様さにめげて(?)、IT業界ではしばしばマテリアルの語を避けて、"item master"、「品目マスタ」なる用語が使われる。しかし、これは抽象化の結果と言うよりも、抽象化の不足がもたらした状況かもしれない。

マテリアルとは、物的な実在性を持ち、在庫可能で、所有権の対象となるようなものをいう。この点を、サービス・情報/データと比較し、きちんと区別して認識すべきである。さもないと、部品マスタに「外注」や「指示伝票」を登録するような混乱が待っているだろう。マテリアルの概念はあらゆる生産管理の基礎である。基礎が定まっていない上に、いかに美しい管理システムの体系を構築しようとも、それは危ないのだ。





見える化

5年前に日経文庫から『時間管理術』を上梓したとき、出版社が帯につけた惹句(注目をひくための宣伝のフレーズ)は、「自分のスケジュールを“見える化”せよ!」だった。帯の文句は著者が知らないところで決められる。でも、これを見たとき、正直に言って、やれやれと思った。“見える化”はトヨタの発明した用語で、あまり関係のないわたしが勝手に使いたい言葉ではなかったからだ。当時、たまたま学会の委員会関係で、トヨタ自動車の銀屋技監をはじめ何人かの方ともおつきあいがあった。自分の著書が出たので早速贈呈したのだが、挨拶の中で「この“見える化”という言葉は出版社が勝手に書いた惹句でして・・」と妙な言い訳をしたのを覚えている。

わたしはトヨタ独特の用語や概念を、自分のサイトなどであまり使わないことにしている。第三者が尻馬に乗ってはしゃいでると思われるのは、しゃくにさわるからだ。それにトヨタ系列以外の会社が、(自分との違いを深く考えぬまま)トヨタの真似をするのは、決して賢いことではないと思っている。だから「あなたの会社にトヨタ生産方式があわない5つの理由」などというエントリーも書いたが、この文章は我がささやかなサイトの中では、飛び抜けてアクセス数が多かった。上司から「トヨタを見習え」と指示されて苦労している人が、けっこうたくさんいる証拠なのだろう。

ところで最近、5年ぶりにまた本を書いている。そのテーマが、じつはジャスト・イン・タイムなのである。「生産革新フォーラム」の友人達と準備中のこの本は、早ければ12月に上梓される予定だが、仮のタイトルを「『JIT生産』を卒業する本 〜トヨタの真似だけでは儲からない」という。つまり、考えずにトヨタの真似をしてはいけない、がサブテーマだ。

誤解しないでほしいが、わたし達はトヨタ生産方式やジャスト・イン・タイムを批判しようとしているのではない。需要と供給を一致させる「ジャスト・イン・タイム」の思想はサプライチェーン・マネジメントを先取りしていて見事だし、有用だと思う。また、トヨタ生産方式はトヨタグループにおいては最善の仕組みであろう。ただし、別の業種業態の企業が、前提条件の違いも考えずに、かんばん方式やらアンドンやら、道具立てだけを導入したって、うまくいかない。だから自分の立ち位置を分析した上で、ジャスト・イン・タイムの本来の目的を実現するための、(トヨタ流とは違う)様々の定石を紹介しようとの意図で書いている。

ところで、そうは言いながら、わたし自身が最近、トヨタ用語についうっかり乗って、踊らされてしまったことがある。冒頭にも書いた“見える化”である。これをプロジェクトに適用しようと、最近あれこれ試みていたのだが、どうも根本的な勘違いをしていたらしいことに気がついたのだ。

いうまでもなく、プロジェクトというのは状況が把握しにくい(見えにくい)代物である。プラントは目に見えるからいいだろ、とよくIT業界の人に言われるが、それは実物を建設する段階に入ってからのことで、そんなのは後期の話である。初期から中期にかけて設計段階や調達段階での進捗や品質状況は、やはり分かりにくいのである。それでも、なんとか種々のテクニックで進捗や費用を数値化して、予実対比することはしている。

問題は、PERT/CPMやEVMSなどで計数管理しにくいエリアである。具体的に言えば、コミュニケーションとリスク(イシュー)だ。こうした、プロジェクトの深層に位置するマネジメント・エリアの把握は、非常に困難である。それをなんとかしよう、グラフ化して見える化してみようと、調査やらアンケートみたいなことを試みた。

たとえば、自分が消費している時間の何割がコミュニケーション仕事で使われているのか、また何割は追加変更や手戻りなどの想定外の仕事に使われているのか、を集計してみたのである。ちなみにエンジニアリング・プロジェクトでは、一般に30%近くが変更や手戻りで浪費されている、と言われている。わたしはこの通説の正確な出典を知らないが、あるいは米国Constrcution Industry Instituteあたりなのかもしれぬ。ともかく、想定外の仕事にどれだけ時間を割いているのかを“見える化”しようと思ったのである。

しかし、3割なんてとんでもない。結果は意外なほど小さかった。じゃあ、わが勤務先は別格に生産性の高い職場なのか? あいにく、そうとは思えぬ。つまり回答者達は、どんな追加変更やリワークが起きようが、「想定外」とは捉えなかったのである。どこかにボタンの掛け違いがあったらしい。わたしはあわてて、もう一度原典に当たることにした。つまり、トヨタ生産方式における“見える化”の意義を調べ直したのである。

もともと“見える化”は、トヨタ生産方式における改善手法とともに有名となり、世に知られるようになった概念である(本家に遠慮して、「可視化」と呼ぶ人も多い)。ところで、本家トヨタにおける“見える化”の概念とは、次のようなものであった:

(1) 異常管理を“見える化”の中心に据えている

トヨタでは正常な業務の中で異常を顕在化させる仕組みを「見える化」と呼ぶ。一番いい例が「アンドン」で、工場の生産ラインで機械の故障等が起き、ある工程がストップ状態になった際に、「アンドン」を灯して皆に分かるようにする。
言いかえるなら、作業結果や状況を示す値それ自体ではなく、あくまで正常値や目標との「ギャップ」を見える化するのが本家トヨタ流である。そのためには、このギャップは異常、と判断できる「標準・基準」が必要となる。

(2) 自律分散型管理とワンセットになっている

"自律"とは、「自らやっていることの正否を判断する機能と権限を有すること」である。これができない現場で「見える化」しても意味がない。そして、問題を解決できるのが自律である。だから、問題発生と同時に、解決・改善状況も「見える化」するようにすべきである。

(3) あくまで目的達成の手段である

目的を明確に説明できない「見える化」は、トヨタにおける見える化とは根本的に異なる。「見える化」は会社の方針管理とKPI目標にはっきり結びついているし、アクションにつながらなくてはならない。

(4) 情報を取りに行くのではなく「目に飛び込んでくる」状態を作る

だから、何かを調べて集計グラフや図表にして、それで「見えました」ではダメなのだ。

このように、トヨタの“見える化”は、会社全体のマネジメント意識と密接に結びついている。だから自社において実現する場合も、本来の目的意識を忘れないように取り組まなければならないことが分かる。

・・と。それはいい。

しかし、「正常を異常と区別できる」ことが重要と明言されているが、わたし達の場合、ここが問題であった。「正常」とは、つまり「標準動作」である。くりかえし、同じ動作・操作ができること。これが標準である。“標準なくして改善なし”もよく知られたトヨタの標語だ。

ところが、プロジェクトというものはその定義上、本来ユニークな、一回限りのものなのである。プロジェクトにおける標準とは、何だろうか。たしかにレンガ積みだけ延々繰り返す「万里の長城プロジェクト」なら、標準作業も設定できるだろう。しかし、たいていの現実のプロジェクトでは、そうではない。少なくとも、一番知りたい設計・調達段階の標準とは何なのか。そして、何が異常なのか。そもそも個別の環境変化に対応できることこそ、プロジェクト・マネジメント能力なのではなかったか?

という訳で、この問題は(少なくともわたしは)まだうまく解決できないでいる。むろん我が職場では、設計でイシューが発生するたびに机の上にアンドンを灯す、という風には「見える化」できないだろう。アンドンと同時に、ライン全員が手を止め、問題解決のために走ってきて必要な手を打つ、というのもありそうもない話だ。トヨタの生産ラインではこれが出来るのである。それは、作業の繰り返し性が高いからだ。だが、毎度ユニークな世界に生きているプロジェクト屋のわれわれは、まだしばらく頭をひねらなければいけないらしい。



見込み購買

ストック在庫にするために行なう発注のこと。
確定購買をみよ



や−よ



山積み
Loading
「革新的生産スケジューリング入門」第2章講義8

横軸に時間を、縦軸にリソース量をとり、各タスクの着手タイミングと所要リソース量のブロックを積み上げた「リソースの負荷グラフ」を作成して、必要なリソースの投入量を計算する作業を「山積み」とよぶ。



山崩し
Leveling
「革新的生産スケジューリング入門」第2章講義8

山積みの結果を基に、タスクの開始時間をずらすことによって、リソース所要量のピークを低くする作業のこと。山崩しにおいては、フロート=自由度のあるタスクを動かすのが原則となる。



優先順位法
優先番号法
Priority Method
「革新的生産スケジューリング入門」第2章講義9

各時点で同時に着手可能ないくつかの作業に、あるルールに従って優先順位をつけ、それに従って着手する順序を決めて行くスケジューリング手法。全体最適、すなわち最短の工期を得る保証はないが、簡単な手続きで解決策を得る点がメリット。ルールとしては、タスクの納期順、作業時間の短い順、LPSTの早い順、などがある。



ら−ろ



リアルタイム
Real Time

先日、数理計画法ツールのベンダーである数理システム(株)の主催するセミナーで、竹内郁夫・東大名誉教授の講演を聴く機会があった。テーマは「射程内に入った実時間ごみ集め」http://cl-www.msi.co.jp/solutions/knowledge/lisp-world/seminar/real-time-gc-in-sight.pdf、LISPのリアルタイム・ガーベッジ・コレクションの話である。ミーハーの私は、竹内先生の書かれた名著「初めての人のためのLISP入門」(今年再版された)を持っていき、サインをお願いした。と、驚いたことに、「じゃあ筆を出すから」と言って、鞄から小さなケースに入った毛筆を出して、さらさらと献辞をしたためてくださった。日本語へのこだわりといい、毛筆といい、なんて粋なんだ! と感心した次第である。

ところで、竹内先生の講演内容は大変面白かったが、『実時間』という概念について、なんとなく無条件に前提されているように感じられた点が、ちょっと気になった。むろん、LISPのごみ集め性能については、セル消費とスイープによる回収の速度の比較として明確に規定され、実験で測定されている。しかし、どうなればリアルタイムと呼びうるのか、それは技術者の常識的感覚に任されていて、そこまでは定義されていない。

LISPに限らず、バックグラウンドで任意のタイミングでガーベッジ・コレクションが走りうる処理系では、リアルタイム性の議論がうるさい。そこで一般的に言われていることは、プロセスが動作するたびにタイミングや時間がばらつかないようにすること、あるいは、開発者が実行タイミングや実行時間を確定的に計算できるようにすること、といわれる。産業用システムや組込系ソフトでは高いリアルタイム性が要求される。だから処理時間の「予測可能性」が重要である、との認識があるわけだ。あるいは、「確定論的(Deterministic)スケジューリング」が可能であること、と言ってもいい。

だが、これは本当なのだろうか?

ERPの覇者、SAP社の「R/3」のRとは、実はReal Timeの頭文字であった(初期にはR Systemという名前の汎用機ソフトから出発した)。でも、R/3はなぜ「リアルタイム」なのだろうか? 開発者は処理時間を確定的に設計できるだろうか? 答えはまったくNOである。あの三層アーキテクチャで非同期処理が走っているのに、確定論が成り立つわけはない。

あるいは、たとえば工場内でICタグとPOPシステムをつかって、ワークの位置情報を「瞬時」に読みとったら、リアルタイムなのだろうか。瞬時性にこだわるならば、DCSで制御弁の開度を1秒周期で制御することは、リアルタイムだろうか。では、スペアパーツを倉庫から払い出して、3分後にその情報を端末から入力したらリアルタイムではなくなるのだろうか。

もう少し続けよう。以前、「リスク」の定義として、「目指すべき目標値ないし理想状態から逸脱する可能性があり、かつ、その影響をリアルタイムに回避・抑制できないような事象(群)」をリスクと呼ぶ、と書いた。その場ですぐに回避可能な事象はリスクではない。自動車を40km/hで運転しているとき、ずっと前方を車いすで横断する老人がいても、ハンドルやブレーキを使ってほぼ実に避けられる。だが小学生が物陰から飛び出してきたら、そうはいかぬ。だからリアルタイム性は、リスクを議論する上で必須の項目である。ではそのリアルタイムとは、一体何なのか?

じつは、答えはたった3文字の漢字で書ける。それは「時定数」である。管理対象の時定数よりも十分速くコントロールが可能であれば、それがリアルタイムなのである。

プロセス・プラントのDCSが1秒周期で制御弁の開度を決められれば、それはリアルタイムだ。中を走っているのは秒速数m〜数10mの速度をもつ流体である。秒以内の単位で制御できなければ相手は系から逃げてしまう。しかし、わたしは以前、時定数が150時間もある超多段蒸留装置のフィード・フォワード制御をやったことがあるが、このときは30分間隔でオンライン分析計からあがってくる情報が十分リアルタイムだった。

倉庫の物品払出し作業は、品目数にもよるが数十分単位であり、その手配リードタイムは数日以上である。だから3分遅れの情報でも、十分速いリアルタイム性を持つ。そして本社財務部門にとっては、財務諸表が一日以内で得られれば十分リアルタイムだ。だからSAP R/3はリアルタイムだと主張できたのである。

だから、リアルタイム性を議論するときには、管理しようとしている対象が、どの程度の時間スケールで動いているのかを考えなくてはいけない。従来の議論で抜けていたのが、この時定数の感覚である。各人が分野毎に、無意識に前提して、話をしてきた。だからちょっとでも分野を超えると、さっぱり話がかみ合わなくなる。

応答が何マイクロ秒以内ならリアルタイム、といった閾値は存在しない。確定論的スケジューリングだからリアルタイム、という議論もおかしい。現実の世界で、「確定論」でスケジュール通りに動く物事が一つでもあるだろうか? 生産スケジューリングからコンピュータのジョブ・スケジューリングまで、スケジューリングとはすべからく「近似値」の上に成り立つものだ。その近似値の精度が、制御目的の時定数に比べて十分であるかどうだけが重要なのである。



リードタイム
Lead Time
「革新的生産スケジューリング入門」第3章講義6・ディスカッション2
「BOM・部品表入門」第3章Q3・付録Q2

リードタイムとは、「オーダーを出してから、それが完遂(fulfill)されるまでの時間」のことである。オーダーとは異なる組織間でやりとりする正式な指示であり、いろいろな種類がある。そして、リードタイムはそれぞれのオーダーの内容に対応して定義される。つまり、リードタイムと一口に言っても、その指し示す内容は様々であり、聞き手と話し手の文脈理解の差がある場合は、しばしば誤解が生じやすいので注意が必要だ。

企業間でやりとりするオーダーの代表例は、需要オーダー(あるいは受注オーダー)である。会社によっては単に『オーダー』とも呼ばれる。これは、製品の販売行為に対応する。製品Aを100個売る注文を顧客Zからもらった。納品の納期は来週末だ。こういうとき、需要オーダーが成立する。そして、この需要(受注)オーダーの完遂までの期間が、受注から納入までのリードタイムとなる。今日が月曜日なら、実働日単位では9日間、カレンダー日では11日間だ。

この注文が、もし“できる限り早く納品してくれ”という要求であり、かつ、営業部門の持っている未引当の製品在庫が120個あったら、どうなるか。すぐに100個の引当処理を行い、出荷手配をかけるだろう。国内ならば、3〜4日で納品できるかもしれぬ。その場合、受注リードタイムは4日以内となる。

この例からわかるとおり、受注から納入までのリードタイムは、定まったものではなく、製品在庫の状況によってかわる。ここを良く理解してほしい。つねに在庫をたんまり積み上げている製品(たぶん主力製品で見込み生産のもの)は短いだろう。しかしうっかり在庫を切らしたら、工場に製造を依頼しなければならない。そうなると、ずっと長くなる。リードタイムに定まった“標準値”など、とくにないのだ。それは目安に過ぎない。

この売り買いの関係を、逆から見てみると、それは外部企業からの買い物、すなわち購買オーダー(発注書)になる。そして、購買リードタイムとは、発注書を切ってから、受領検収するまでの日数をあらわす。どうだろうか。購買リードタイムの「標準値」を、固定したデータとしてMRPの購買情報マスタに登録する意義は、どれほど薄弱なものかおわかりだろう。サプライヤーに在庫があるかどうかによって、実際の日数はかわってきてしまうからだ。

また「来週の金曜日に持ってきて」と期日指定したら、サプライヤーにいくら在庫があっても、その期日が購買リードタイムになるのである。もしも購買リードタイムの標準値を3〜4日に設定していたら、それはサプライヤーに「いつも在庫を持っておけよ」と無言で指示しているに等しい。そうしたら、彼らの在庫保管費用がかならず乗って、購入単価は高くなっているはずだ。え? カンバンはどうか? カンバンというのは分納指示であって、購買オーダーではありません。

ちなみに、受注の際に営業マンがかけた出荷手配は、物流センターの人間にとっては『出荷オーダー』になる。物流マンにとって、出荷リードタイムはどう定義されるのか? それは、出荷オーダーを受け取ってから、製品を倉庫からピッキングして出荷梱包してトラックに乗せるまでの時間になる。これは、物流センター全体の仕事量と効率性できまる。当日注文、当日出荷できるところは、かなり優秀な企業だ(あるいはよほどヒマな企業か)。普通だったら、いいところ翌日出荷だろう。なお、トラックに乗せてから客先に届くまでは輸送リードタイムである。つまり、受注リードタイム=出荷リードタイム+輸送リードタイム、という関係式が成り立つことになる。

さて、受注はもらったが製品在庫が足りなかった場合のことを考えよう。この場合、正味所要量の分だけ、生産部門に対して生産依頼をかけなければならない。工場はこれを生産オーダーとして受け取る。工場に製品在庫がたまたま余っていれば、それを出荷して完了(fulfill)となる。しかし普通は生産管理部門が、製品の必要数量を部品表(BOM)と工順表から展開して、各作業区に対して製造オーダーを渡すことになる。そしてここでも、工程がいかに混み合っているか、また部品/原材料が在庫してあるかどうか、が所要日数のカギになる。

もし原料在庫が足りなければ、サプライヤーに対して購買オーダー(発注書)を切ることになる。つまり、生産リードタイム=各工程の製造リードタイム合計+原料の購買リードタイム、という関係式が成立する。そして、ここでもサプライヤー側の在庫の有無が関係して・・・

ポイントがお分かりだろうか。まず、リードタイムは固定的な期間ではありえない。標準値などというものは、一応の目安に過ぎないのだ。

また、リードタイムは、どれだけ混み合っているかでずいぶんかわる。「大病院は3時間待ちの3分診療」という言葉を思い出してほしい。3分は製造リードタイム、3時間は生産リードタイムだと思えばよい。つまり、その製品だけの固有の事情では決まらないのだ。

そしてもう一つ。リードタイムは、在庫のあるなしで大きくかわる。「在庫」とは、言いかえれば『時間の缶詰』であり、何かの仕事を、見込みにしたがって先行して行った結果である。つまり、リードタイムを短縮したければ、安定した、信頼に足る“見込み”を与えるにしかず、ということになる。これがリードタイムの、一番重要な原則なのである。



リジェネレーション
Regeneration
「革新的生産スケジューリング入門」第3章講義11

さまざまな変動に伴って行われるスケジュール再計算の二つのやり方の一つ。
文字通りすべてをご破算にして、最初から計算し直す手法。この場合、当然ながらかなりの時間がかかるため(とくにMRPでは)、よほど大きな条件変更がないかぎり、そう頻繁に行うものではない。



リサイクル型BOM
BOM with recycle
「革新的生産スケジューリング入門」第6章講義1.1、演習問題
「BOM・部品表入門」第2章Q3

ふつうの組立加工型製造業では、原材料や部品を順次加工して製品に仕上げていく。原材料から製品への流れは一方向であって、ストラクチャー型BOMを書くと、製品を頂点としたきれいなツリー型の構造になる。アルファベットのAの文字に似ているため、この種のBOMを「A型」と呼ぶ。

ところが、製造業の中には、せっかく加工して作った製品の一部を、原材料に戻してしまう業種がある。この、一見奇妙なタイプの業種は、案外多い。たとえば、シャンパンの醸造工場では、製品の一部をとっておいて、翌年の仕込みの原料にブレンドする。もったいないようだが、これによって、毎年の製品品質が安定するのである。自動制御理論を知っている人には、移動平均的な安定化の効果がある、と説明すれば分かりやすいだろうか。

この種の製法は、シャンパンに限らず、お酢や乳製品など、醸造プロセスを含む飲料・食品工業ではよく見られる。農産物を原材料にする業種では品質のばらつきをいかにおさえるかがカギなのだ。数年前に、北海道を代表する名門企業だった雪印乳業が品質問題のスキャンダルで倒産に追い込まれたが、これもじつは、製品を原材料にリサイクルするプロセスで、保存状態に失敗したため起こったことだった。

リサイクルのあるBOMの構造図では、原材料から製品への流れにループができる。そこで、私はこれを「Q型BOM」と呼んでいる。

さて、こうしたQ型BOMをもつ工場で生産計画や原価管理を行なおうとすると、BOMにリサイクルがあるため、たちまちある種の問題に突き当たる。

たとえば、MRP=資材所要量の計算である。MRPの計算ロジックは、製品から順次部品・原材料にさかのぼって、正味所要量と引当の計算を展開していく。ところが、ここにリサイクル型BOMが存在すると、製品を頂点とした階層が決められなくなってしまう。生産計画/スケジューリング用ソフトウェアの中には、副製物(by-product)を、マイナスの員数をつけて表現するものがあるが、原料にマイナスとプラスの員数を二本立てに記述できないと、この種類の計算はうまく扱えないことになる。

もう一つの困難は、個別実際原価計算である。実際原価は、それぞれの製造ロットにおける使用材料費・労務費・直接経費を個別に把握するところからはじまる。ところが、製品が原材料にリサイクルされてしまうと、この計算が単純には求まらなくなる。そこで、厳密に計算するためには、収束計算が必要になる。多くの原価管理ソフトウェアには、この機能が欠けている。

ところで、Q型BOMを持つのは、飲料・食品など、ごく特殊な一部業種だけだろうか? じつは、そうではない。たとえば、日本を代表する重工業である製鉄である。製鉄業では、鉄クズを原料の一部にまぜて使う。ガラス工業もそうだ。ガラスの主原料の一つは、カレットと呼ばれるガラスクズなのである。こうした業種では、品質安定という目的もさりながら、製品の破片を廃棄せずに再利用することも主眼のひとつである。

樹脂成形加工業も似ており、型への導管部分は再び溶かして原材料に使うことができるのだが、品質劣化を防ぐため、逆にリサイクルの混入率の上限を決めたりしている。

このように、製品の原料へのリサイクルは、少なからぬ業種で行なわれている。にもかかわらず、ERPやAPSなど、現在の市販パッケージでは、Q型BOMへの配慮が足りないように思われる。導入の際には、十分注意が必要である。



リスク
Risk

何年前だったか、梅雨になってもいっこうに雨が降らず、カラカラに晴れた日が続いたことがあった(このごろ毎年異常気象なのでいつのことだったか覚えきれぬ^^;)。陽光はまぶしく空が抜けるように青く、湿度も低くて、さながらカリフォルニアの気候のようだった。「空梅雨って、こんなに素晴らしい天気だったんですね。」と若い人たちは言った。たしかに、こんな6月だったら、英語で言うJune Brideという言葉の輝かしさも分かるような気がした。せっかくの結婚衣装が雨に濡れては、『晴れの日』ではなくなってしまう。

結婚式を待ち望む人にとっては、雨はありがたくないものだ。ところで同じ時、年寄り達は、毎日晴れていることを心配した。「梅雨に十分雨が降らないと、田んぼの稲が育たない」という。もう工業社会になって何十年もたつのに、いまだに生活の中心であるかのように稲作の心配をする。伝統的思考は、文化の中にかくも深く組み込まれている。

「雨」という事象が、ある人たちにとってはリスクであり、他の人たちにとっては「雨が降らない」ことがリスクになる。これは、リスクというものが、誰にも共通の客観的事象として存在するものではない事を示している。

医学・環境学系の議論では普通、リスクはマイナスの影響の可能性を意味する。工学系も、ほぼそれに準じた使い方だ。一方、金融学系では、リスクとは不確実性を意味し、結果はプラスにもマイナスにも(ほぼ均等なチャンスで)なり得ると考える。わたしは前者を「非対称型」リスク、後者を「対称型」リスク定義と名付けている。

では、ビジネスにおいてはどうか。生産管理・品質管理分野では通常、非対称型でリスクを捉える。品質欠陥とか在庫切れとか。一方プロジェクト・マネジメントの分野では、PMBOK Guideは対称型で用語を定義している。会計や法務・コンプライアンス部門は非対称型、財務部門は対称型だろうか。おかげで、「リスク」という言葉自体に理解のブレが生じて、ミス・コミュニケーションのリスクが生じるわけだ(←この文での『リスク』は、非対称型の使い方をしている点に注意)。

このブレを無くし、みなに共通なリスクの認識を定義する方法はないだろうか? それが、あるのだ。非常に単純なことだ。すなわち、リスクの反対概念を明示するのである。リスクの反対概念とは、リスクの無い、目指すべき「理想状態」のことである。

医学・環境学系においては、「安全/健康」が理想状態である。ここからの逸脱を、リスクと捉える。一方、金融工学では、(なぜかは知らないけれども)「確実」が理想であるらしい。だから、不確実な変動をリスクと認識する。問題は、こうした『理想状態』を、皆が無意識に前提して議論してきたことにある。だから、リスクを論じる際には、まず、「あるべき理想状態」を規定する。そして、そこからの逸脱の可能性を論じるべきなのである。

わたしの提案するリスクの定義とは、このようなものだ:
「目指すべき目標値ないし理想状態から逸脱する可能性があり、かつ、その影響をリアルタイムに回避・抑制できないような事象(群)を、リスクと呼ぶ」Risk refers to such event(s) that may possibly cause deviance from targeted ideal value/situation and that effect is not avoidable or controlable in real-time.

この定義の特徴は、主体が目指すべき理想を持っていることを前提とする点だ。その理想が『確実性』であるか『安全性』であるかは問わない。それは主体の価値判断に任されるべきことである。この定義は、だから、医学・環境学系の用法も、金融工学の用法も、いずれも内包している。「理想」という言葉が気恥ずかしかったら、「実現できる最善」でも良い。目標とする最善の状態・値をまず示す。それからの逸脱の可能性を検討する。

今日、ビジネスの現場で理想などという言葉を口にすると、青臭いと非難されかねない(そのくせ、ERP導入プロジェクトなどでは、To-Beモデルなどと言うへんてこな英語を平気で使う)。半世紀前には人を導いた「自由豁達にして愉快なる理想工場の建設」という起業理念も、その後継者達は忘れたがっているかのようだ。なげかわしい事ではないか。今やむしろ、理想を語るのを避けたいがため、そのかわりに皆リスク・マネジメントを論じるのではないかとさえ感じられる。あるべき姿を考えることが、ビジネスを引っ張っていく第一歩だと思うのだが。

もちろん、理想や最善と言っても、それはぎりぎり実現可能なものでなければならない。100mを5秒で走れとか、いや0秒が理想だ、などと主張して、そこからの逸脱をリスク呼ばわりするのは愚かである。仕掛在庫ゼロ!とか、製造コストゼロ!という『理想』をかかげるのは、マネジメントの目標として現実性がないばかりか、間違ってもいる。

ちなみにわたしは、「コスト超過」や「納期遅れ」などを、誰にも共通の普遍的リスクとして前提することに反対である。万人に適用可能な共通の目標などは無い。品質のためには費用はいとわないプロジェクトや、技術的ブレークスルーを実現するため納期はあえて設定しないプロジェクトだって、考えられるからだ。コストや納期がプロジェクト目標でなければ、そこからの逸脱はリスクにはならない。多くのリスク論は、自分の無意識な前提から出発するため、この点を誤解している。

リスクが「可能性」であることも重要だが、「影響」の大小もポイントである。以前別のところにも書いたので繰り返しになるが、リスクの大きさは、

           可能性×影響度
リスクの大きさ = −−−−−−−−−
            対応能力

で数式的に現すことができる。主体の側の能力も同時に問われるのである。このことによって、「××さんがプロマネだって!? それじゃ、プロマネ自身がプロジェクトの最大のリスクだな」といった表現の意味が理解できよう。分母の対応能力が小さければ、どんな些細なリスク因子も巨大な結果を引き起こすだろう。

むろん、対応能力というのは、リスク事象の影響をリアルタイムに回避・抑制できる能力を指す。「リアルタイム」の定義は長くなるから別に項をあらためて書くことにするが、瞬時に避けられるものはリスクではないのである。自動車を40km/hで運転しているとき、前方を車いすで横断しようとしている老人に気がついたとしても、これはリスクではない。車いすの移動よりも、車のハンドルやブレーキを使って避ける方が確実に早いからである。しかし、子供が飛び出してくるのは、リスクである。瞬時によけきれるかどうか微妙だからだ。また、相手が車いすの老人の場合でも、道が暗がりで街灯もない場合、やはり認知するまでに時間がかかるから、これもリスクとなるはずである。

ということで、このようにリスクを定義し直すことが、リスクに関わる誤解をふせぐ一番の方法だとわたしは考えている。もちろん、わたしがこんなホームページの片隅で何を定義しようが、それが明日から世の中にすぐに広まるものでないことは承知している。では、なぜ今さら「定義」するのか。それは、少なくとも、わたしのこのサイト内では、整合性の取れた議論をしていきたいからである。そして、読者諸賢も、上記の「目指すべき目標値・理想状態」を今一度思い起こして、ご自分の仕事のリスクを再点検されることをおすすめする次第である。




リスケジュール
Reschedule
「革新的生産スケジューリング入門」第2章講義12

一度発行された実施スケジュールが、
 ・注文の飛び込み、
 ・材料の入庫遅れ、
 ・在庫の破損、
 ・工場の機械の故障、
などの変動要因により、計画期間途中で行うスケジュールの見直しのこと。
リスケジュールを行うときには、通常、計画開始日を前回の計画よりも後に設定する。その開始日における引当て可能在庫量を計算し、それを出発点として、独立需要をもとにMRPの計算をするのが普通である。



リソース
Resource
資源
「革新的生産スケジューリング入門」第5章講義5.2

材料以外に、その工程を完成させるために必要なものをリソースという(ただし設計図や仕様書などの情報は除く)。
普通にはその工程で用いる機械設備のことをさすことが多いが、これ以外にも要員・治工具・金型・用役(電力、燃料、水等)・副資材などさまざまな種類のリソースがある。
リソースには消費されるものと再利用可能なものがある。また複数の作業での共有にも種々のパターンがある。



リソースカレンダー
Resource Calendar
「革新的生産スケジューリング入門」第5章講義2.1

カレンダーの形で、利用可能なリソースの量を規定したもの。工場の休日や要員シフト、また設備の稼働時間などを事前に規定しておく。スケジューリング・ソフトにとって必須のインプット・ファイルの一つ。



律速過程
Rate-determining Step
「革新的生産スケジューリング入門」第1章講義2

アイスランドの火山噴火の影響で、大混乱に陥っていた欧州の航空ネットワークが、ようやく復旧にむかっているようだ。職場の同僚や知人にも、このためにずいぶん予定をくるわされた人が出た。

遠方への旅行のスケジュールを立てるとき、移動手段の内でおそらく最初に決めるのは飛行機の便だろう。空港への電車の切符をそれより先に手配するという人は少ないと思う。その理由は、飛行機の方が電車やバスなど近郊の移動手段より、通常は選択肢の幅がずっと少ないからである。1日に数便しか飛ばない飛行機の方が、1時間に何本も走っている電車より「自由度」が少ないのである。したがって旅行全体のプランは、希望する日に飛行機がとれるかどうかに、かなり依存する。

以前、JALのフライト・アテンダントのサービスの質について皮肉を書いたことがあるが(「JALに乗るおじさんの日記」2010/02/27)、本当のことをいうと、航空会社のサービスを比較する際は、地上職員の質の方がはるかに重要だ。なぜなら、飛行機というのは自由度が小さい上に、しばしば気象その他の理由で遅れたり欠航したりしがちであるからだ。そうしたトラブルに見舞われて、あてにしていた便に乗れないとわかったとき、スムーズに予定変更できるかどうかが、旅行では重要なのである。地上係員の気が利かないと、トラブルもアナウンスが遅れるし、代替手段も得られないことが多い。

だから私は、地上職員の対応がしっかりしている航空会社だったら、多少機材が古くて小さくても、我慢して選ぶようにしている。それに比べれば、アテンダントが美人かどうかなど、まったく取るに足りないどうでもいい項目だ。

旅行のスケジュールにおける飛行機のような存在を、「律速過程」とよぶ。律速過程というのはもともと化学の用語で、反応が複数の過程を経て進む場合に、その中で一番速度の遅い(時間のかかる)反応を呼ぶ。その過程が全体の反応速度を律するので、「律速」と呼ぶのである。ふつう私たちが複数の手段を組みあわせて計画を作るときには、その中で一番ネックとなる律速過程の工程に焦点を合わせて、スケジュールを組む。ネックというのは、時間的に長くかかるとか、自由度が少ない上に代替手段がないとか、リスク確率が高くてなかなか期待どおりにいかないとか、そういった問題のあるものだ。

そして、律速過程の前には時間的な余裕をおくことで、プラン全体を予期せぬ出来事から守れ、というのがスケジューリングの大原則だ。飛行機の場合には、十分余裕を持って空港に着くようにするわけである。

ネックとなる律速過程は、プランを立てる上での自由度が少ない。つまり、いいかえると自由度とは、私たちが予期せぬ出来事に対応できる余裕・能力を意味している。そして私たちは経験的に、自由度を最大限確保するようにスケジューリングすることを身につけているのである。もう少し公式化するならば、「自由度が最小の律速過程を見いだせ。律速過程よりも上流ではフォワード、下流ではバックワードでスケジューリングせよ」という原則で表すことができる。これを律速過程中心のスケジューリングと呼ぶ。

律速段階には時間的余裕を持ってたどり着くようにするべきである。この余裕を、『保護バッファー』という。律速段階の「あばれ」から全体スケジュールを保護するためのものだからで、これは期間として確保する場合と、逆に在庫として確保しておく場合がある。ただし、保護バッファーのコントロールに十分な経験とスキルのある場合は、上流側もバックワードで計画してもかまわない。

では、工程が非常に多数あって、それらの間に順序関係や依存関係があったりなかったりしたら、どうしたらよいだろうか? 人の直感や経験知だけでは、律速段階を見つけてコントロールするのは難しい。そして、現代スケジューリング理論と、その嫡子であるAPS(先進的スケジューラ)こそ、まさにこうした問いに答えるための道具なのである。




臨界PP量

「革新的生産スケジューリング入門」第6章講義3.4

1PPあたりの保管コストで、標準切替コストを割った値を「<臨界PP量>」とよぶ。

              標準切替コスト
  臨界PP量 = ----------------------------
           1PPあたりの保管コスト

 各生産オーダーにともなうPP量が臨界PP量を超えた時点で、別の生産オーダーとして分割する(ロット・サイジングをする)、のがPPB法の原理である。



労働装備率

生産システムの効率性は生産性(付加価値生産性)によって測ることができ、生産管理の一つの目標は生産性を向上させることにある、と私は何度か書いてきた。では、目標達成のために、生産管理の担当者はなにをすべきか。具体的にどのようにしたら、付加価値生産性は上げることができるのだろうか。そこがわからないと、生産システムの議論など単なる抽象論、絵に描いた餅に終わりそうである。付加価値生産性=(付加価値額)/(従業員数)で定義されるが、この分子・分母とも、そう簡単には変えられそうにないように思われるからだ。

むろん、正社員の労働者の首を切って、派遣労働者に入れ替えれば、見かけ上は分母である雇用数は下がる。しかし、分子の付加価値額とは、(製品の売上額)−(外部支払額)で定義されている。この外部支払額には、社内人件費や減価償却費など、社内のリソースにかかわる固定費(社内振替費用)は入っていないことに注意して欲しい。もし正社員を派遣労働者に切り替えると、それは社外への支払額を増やすことになるから、すなわち付加価値額が減ってしまう。つまり分母と分子の間にはトレードオフの関係があって、そう簡単に一方だけをかえることはできない相談なのである。

また、今日の多くの製造業では、工場の人員よりも、営業部門の販売員や本社人員がずっと多いため、直接工の首を多少切っても、分母はたいして減少しない(さらに言えば、こういう無意味な数字操作の影響を排除するため、分母を「従業員数」ではなく「従事者の総労働時間数」で分析する方法もとられるようになってきた)。分母が大して変わらないのに、分子だけが小さくなるのだから、派遣労働者への切り替えによる原価低減策は、あきらかに生産性向上には逆行する施策だということができそうだ。

ちなみに、ご存じかどうかは知らないが、わが政府はつい1年半ほど前に、経済財政政策担当大臣が「今後5年間で労働生産性の伸び率を50%アップさせる」と経済財政諮問会議で発表した。たいしたものである。我が国の過去10年の年平均伸び率は1.6%だから、2.4%にしたいということらしい。1980年代は平均3%だったから、その水準まで戻りたい、ということだろう。だが、その大臣の国会答弁によると、付加価値生産性の中に技術進歩率が入っていると思っているらしい。なんだか定義自体が曖昧な、不思議な経済政策ではある。

IE的手法を用いて製造労働者の動作時間のムダとりを行い、総労働時間数を下げる、というのが、ふつうは生産性向上の王道である。しかし、そこで削減された分だけ、すぐさま人減らしできなければ、結局分母はかわらないことに注意して欲しい。動作時間のムダとりは、ボトルネックとなっている工程以外では生産性向上にはあまり寄与しないのだ。

では、どうするべきか。ここで登場するのが『労働装備率』である。労働装備率とは、(有形固定資産額)/(従業員数)で定義される指標だ。製造業の場合、有形固定資産とは、工場の建物や機械設備などが大きな割合を占めている。つまり、この指標は、労働者一人あたり、どれほど機械化が進んでいるかを大まかに示すと考えて良い。

じつは付加価値生産性は、労働装備率と密接な関係がある。同一の業種に属する日本の製造業数社をとり、横軸に労働装備率、縦軸に付加価値生産性をとって、グラフにプロットしてみると、両社の間には有意な正の相関があることが見て取れる。付加価値生産性の高い企業は、面白いことに労働装備率も高いのだ。

これは、ある意味では当然のことかも知れない。同じ製品を作る場合、より機械化され自動化された工場の方が、労働者は少なくてすむ。従来人間がやっていたことを、機械装置がやってくれるのだから、一人あたりの生産性は高くなるはずだ。そういう意味で、この「労働装備率」という言葉はいささかミスリーディングな用語であって、本来ならば、たとえば「機械装備率」とか「資本装備率」と呼ぶ方が分かりやすい。

そして、この労働装備率は、計画的に変えていくことが可能だ。たとえば、それまで人間が手作業で箱詰めしていた包装ラインがあったとする。ここに、自動包装機を導入する。あるいは、包装材料を倉庫から人間が運んで補充する作業を、天井走行車による自動供給にかえる、といった施策は労働装備率をアップさせ、それで手の空いた労働者を、よりマンパワーがタイトな工程に適切に配置転換すれば、付加価値生産性の向上にも寄与するはずである。

こう書くと、二つの疑問が浮かぶかもしれない。まず第一に、よくJITコンサルタントが“コンベヤラインや自動倉庫を捨てろ、人間を活かして使え”という指導はどうなのか、という点。また、機械化するとしたら、どの部分を機械化するのが良いのか、という点。

じつは、この二つの疑問は、同じ問題を両面から見ているのである。'90年代の初め頃、バブル経済に浮かれていた頃の日本の工場は、「人減らし・機械化」をスローガンに、むやみやたらとコンベヤや自動機械を導入した。しかし、頭の中は「見込・大量生産」時代の発想のままに行ったのである。大量高速生産の機械装置は、たいてい融通がきかない。その結果、単一製品をずっと作るには良いが、需要変動には弱い工場ができあがった。生産システムの機能は「需要情報を製品というモノに変換しアウトプットする」ことなのに、ひどく有効性の低いシステムができあがったのである。人間は柔軟だから、人間力を使え、というのはその意味では正しい。

ただし。いくら人間が柔軟といえども、工場の中には人間がやりたくない/やるべきではない作業がある。危険・汚い・きつい、いわゆる3Kの仕事である。判断基準としては、あなた自身が(あるいはあなたの子ども達が)、その作業を一生続けてやっても良いと思えるかどうかがポイントだ。工場の中の作業を分類すると、

A 人間しかできない、かつ人間がやりたい作業
B 人間しかできない、しかしやりたくない作業
C 機械でもできる、しかし人間がやりたい作業 (←これはあまりない)
D 機械でもできる、かつやりたくない作業

がある。機械化するならば、まずDから着手し、それからBにチャレンジする。これが本来の生産技術というもののあり方であろう。そのようにして労働装備率を改善していくことが、最終的に付加価値生産性の向上につながっていくのである。



ロット
Lot
「革新的生産スケジューリング入門」第3章講義8

工程で一つの段取り替えから次の段取り替えまでにくりかえし連続してつくるまとまり、またはその量。



ロット・サイジング
Lot Sizing
「革新的生産スケジューリング入門」第5章講義5
「BOM/部品表入門」第3章Q3

生産スケジュールを作成する際、製造ロットの大きさをどう決めるかが、しばしば重要になる。ふつうMRPでは、部品や製品の需要量(総所要量)から、引当可能在庫量を差し引いて正味所要量を求め、BOM(部品表)を元に、その子部品や原材料の所要量を展開計算するロジックを内蔵している。必要な時点で、必要な数量だけを製造する、という考え方である。これをロット・フォア・ロットという。

しかし、これを機械的に適用していくと、同じ品目を、ある時は1個、別のある時は100個つくれ、という指図ができてしまう可能性がある。製造機械の段取り替えの手間は、1個でも100個でもほぼ同じである。そこで、製造作業にたずさわる側は、できれば1個だけのためにわざわざ段取り替えをしたくない、と考えるだろう。

ロット・フォア・ロットでは少数量の製造オーダーが発生して不都合な場合、その工程に対して計画期間内で生じている正味所要量(つまり手配数量)を順にみわたし、複数のロットをまとめて適正な製造数量以上になるようにたばねる必要がでる。ロット合成(ロットまとめ)である。

また逆に、製造オーダーの数量が大きすぎて、加工機械の処理容量から見て一度に処理しきれないケースもある。この場合、一つのオーダーを複数に分割することになる。ロット分割である。こうしたロット合成やロット分割の計算を行なうことを、ロット・サイジングと呼ぶ。最近のERPやAPSは、こうしたロット・サイジングの機能を備えているのが普通になった。

ロット・サイジングの計算のためには、3つのパラメーターが必要になる。製造オーダーを生成するために必要な最低量(minimum quantity)と、一つの製造オーダーで生産可能な最大量(maximum quantity)、そして最大と最低の間でその数量の整数倍となるような基準量(multiple quantity)である。これらの値を、各工順に対して定義する必要がある。

ところで、大ロットで生産すると、段取り替えのロス時間はたしかに減少するが、よくない問題も起こりうる。個別の部品単位で見るとロット待ちの時間が増えるため、全体ではリードタイムが長くなる。“作りすぎ”のために在庫量が増える。『ジャスト・イン・タイム』『リーン生産』からだんだんとはずれてしまう。

そこで、従来から日本では、小ロット化を押し進めるために、『外段取り化』『シングル段取り』などの工夫により、段取り替え時間を短縮する努力が払われてきた。小ロット化を極端におしすすめ、『一個流し』を最善の理想とする考え方も強い。

しかし、これらは主にディスクリート型生産における最終組立工程では真実だが、他の分野では必ずしも適用できない。たとえば、焼鈍などのバッチ操作は、原則として1個でも10個でも処理時間に変わりはない。また、食品・飲料や医薬品などの工場では、品種切替のあとに、消毒洗浄や滅菌が法的に要求される。この時間は簡単には短縮できない。

そもそも連続流体・軟性体を扱うプロセス生産や<切替型連続生産>では、個数のような自明な「切れ目」が無いため、ロットサイズは自由度が高い。にもかかわらず、たとえば中間タンクの容量のような既存設備の制約に無意識に寄りかかって、ロット・サイジングを行なっているケースが実は少なくない。適正なロット・サイズの問題を、あらためて考え直すべき時がきているように思われる。



ロット・トレース
Lot Tracing
「革新的生産スケジューリング入門」第2章講義1

ロット番号を管理し記録しておくことで、故障など品質上のトラブルが起きた場合に、製造工程に何か問題がなかったかどうかをあとでチェックすることができる。これをロット・トレースという。我が国では通常この目的のために製番が用いられる。



ロット・フォア・ロット
Lot for Lot
「革新的生産スケジューリング入門」第3章講義8

MRPのロジックを機械的に適用していくと、同一バケット内にある生産オーダーの数量をもとに、各工程の手配量が部品展開で求められる。オーダーが1個なら製造ロットも1個、オーダーが100個ならば製造ロットも100個、になる(厳密には在庫量の差し引きがあるが)。これを、ロット・フォア・ロットという。
 しかし、製造側の都合で、1個では少なすぎる、せめて1ロットを10個単位にしてほしい、という要望が出てくる場合、この論理では応えることができないことに注意。



ロットまとめ
Lot Sizing
「革新的生産スケジューリング入門」第3章講義8

ロット・サイジング を見よ







ワーク・パッケージ

WBSの最下位のアクティビティを、「ワーク・パッケージ」とよぶことは、プロジェクト・マネジメントをちょっとでも勉強した人は知っていると思う。いうまでもないが、WBSとは、プロジェクトのスコープ(仕事の範囲)を、アクティビティに階層的に分解し、それに整理番号を付番したものである。

『プロジェクト』という業務は、それ自体では大きくて漠然として理解もハンドリングもしにくい。そこで、それをコントロール可能な小単位まで分解するのである。“大きすぎる問題は、小さな部分問題に分解して片付けろ”というのは、欧米人の得意とする発想であり戦略である。非常に分析的なアプローチと言えよう。

プロジェクトを、複数のアクティビティに分解する作業は、ある意味で、地図の上のぼんやりした領域を、そのカバーする市区町村によって数え上げる作業にも似ている。「この病院のサービスする地域」と問われて、○○区、××区、△△市某町・・とリストアップしてみると、だいたいのその姿が見えてくる。同様に、プロジェクトがカバーすべき活動範囲を、アクティビティ・リストに作ってみる。それが、プロジェクトの姿(スコープ)の『可視化』の第一歩である。

アクティビティ・リストは、ふつう、次のような表になる。

(1) アクティビティ1、(作業内容の説明)、担当者=誰々、期日=○月×日
(2) アクティビティ2、(作業内容の説明)、担当者=某々、期日=○月△日
  ・・・・・・・   ・・・     ・・・     ・・・

このようなアクティビティ・リストを作成して、その表をもとに各作業の分担を決め進捗を追いかける−−これは、もっとも原始的なプロジェクト・マネジメントのあり方である。まさに、イロハのイだろう。アクティビティ・リストも作らない(作れない)ようでは、「プロジェクトをマネジメントしている」とは言えまい。

さて、ところでこのようなフラットなリストのままでは、いろいろと運用上の不便が生じる。たとえば、「基本設計」というアクティビティを進めていくうちに、「移行段階の運用設計」というような、より細かな作業の必要性が急に浮かび上がってきたりする。この両者は、並列にならべるのは何だか落ち着かない。一種の包含関係にあるからだ。では、どうすべきか?

答えは、アクティビティを階層化すればいいのである。アクティビティの下位概念として、サブ・アクティビティを考える。「移行段階の運用設計」は「基本設計」の下位にあたるアクティビティである、といった風にである。言いかえるならば、アクティビティというのはプロジェクトと同様に、さらにアクティビティに分解できると考えるのである。アクティビティは自己相似的だ、とも解釈できよう。

こうして、プロジェクトの全体範囲を表すための階層的アクティビティの構造が定義できる。これがWBSである。ちょうど、「当病院のサービス・エリア」をより明確に示すために、市よりも下の町丁目レベルで数え上げをするようなものである。

ついでにいうと、このとき、アクティビティの整理番号は必須である。社員に従業員番号があるように、プロジェクトにおけるコントロールの対象は、何であれ重複のない整理番号をつける。こんな事はある意味、英米においては常識以前の問題であって、だから誰もわざわざPMBOK Guideになんか明記しないのである。

さて、そのようにプロジェクトを階層的にアクティビティに分解した結果を見た時、その最下位のレベルをワーク・パッケージと呼ぶわけである。地図が市町村・町丁目によって空白も重複もなく敷き詰められているように、プロジェクトの範囲は、ワーク・パッケージの総計になっている。

そして、各ワーク・パッケージにはそれぞれ、コストと、所要期間と、必要なリソースの情報が付随しているはずである。ワーク・パッケージのコストを集計すると、プロジェクト全体のコストになる。そしてコスト情報には、予定のコスト(予算)と実際のコスト(実績)が存在する。すなわち、ワーク・パッケージの意義とは、コスト・期間・リソースを集計し予実対比するための、アトムなのである。

このように考えると、ワーク・パッケージの『粒度』=大きさが重要であることが分かってくる。あるアクティビティは3ヶ月かかり、別のアクティビティは1日で終わる、というようなばらつきがある場合は、「粒度がそろっていない」と考えられる。粒度を適当にそろえる努力をしないと、コストや時間をコントロールしていく時の、集計の精度や意義が落ちていくのである。

じつは、ここがワーク・パッケージ作成の一番のポイントだと言っていい。というのは、アクティビティは(やろうとおもえば)いくらでも再分割していけるからだ。技術者は妙に律儀なところがあって、細かくすればするほど、“管理の精度が上がる”と信じたがる傾向がある。しかし、細かくしすぎると、むしろモニタリングやレポーティングの手間ばかりが増えて、管理のための管理に陥ってしまう。

たとえば、以前あるERPプロジェクトのWBSを見せてもらったことがあるのだが、全体納期は1年以上かかる大事業なのに、半日で終わりそうなアクティビティをたくさんWBSに書き込んでいる。そんなレベルまで、ほんとにプロマネさんはいちいち追いかけるんですか、と問いただしたくなる。私から見ると、それはワーク・パッケージというよりも、実装チェックリストの各項目のように思えたからである。

アクティビティ分解は、ある適切なレベルまでにとどめておく。そして、それ以下については、『デイリー・タスク』と見なして、各担当者にコントロールを委任しておく。これが、本来のあり方である。

そう考えてみると、ワーク・パッケージとは、「固有技術」と「プロジェクト・マネジメント」の境界面を示す、とも理解できる。ワーク・パッケージよりも下部(内部)には、プロマネはもはや立ち入らない。そこはもはや、担当者による固有技術の世界なのである。PMの仕事とは、そこよりも上位の領域、すなわちプロジェクトのワーク・パッケージへの切り分け、その論理的な順序関係づけ、予算や所要期間の設定、リワークやフォールバックへの準備、そしてコンティンジェンシー・リザーブやプロジェクト・バッファーの設定などであろう。そここそが、管理技術としての「マネジメント」の範囲だと考えられるのである。





→「革新的生産スケジューリング入門」にもどる
サイトマップ
このページの冒頭に戻る

(c) 佐藤知一
e-mail: tomsato@pa.airnet.ne.jp