品質管理は「バラツキを前提に、統計理論をベースにしている」のに対して、生産管理は「バラツキを排除した中央集権的計画基準をベースにしている」、のではないか、と、、。
バラツキを避けられない一般の生産環境で中央集権的計画基準ベースの生産管理を行えば、混乱するのは自明です。
どうしたらいいか。解決策はあるのか。解決の方向性だけでも示せないか、、。
世の中の文献、資料などを探しても上記の課題に“朗報”となりそうなものは見つかりません。この問題、そう簡単なことではなさそうです。どなたか、ご存知の方がおりましたら、ぜひ、ご教示ください。
「バラツキを排除した中央集権的計画基準をベースにしている」生産管理の代表例が、ご存知、「トヨタ生産方式」。完全にバラツキを排除する、と言っても、現実的ではありません。計画基準ベースの枠組みが保てる範囲のバラツキはあってもいい。どのくらいか？ トヨタ本には“3％”って、書いてありますけど、バラツキが5％だったら「トヨタ生産方式」は成り立たないんでしょうか、成り立つんでしょうか？ 10％だったら、、20％だったら、、。いや、待て、待て。そういう話になるのなら、バラツキの定義をちゃんとしないとだめなんじゃない。“3％”っていうけど、最大3％なのか、±3％なのか、3％ぐらいという目安なのか、、。
この辺りは“経験則”で判断すればいいのかもしれません。
では、こんなのはどうでしょうか？例えば、納期遵守率80％と言った時、10回（件）の注文で納期以内に納入できた注文件数が8回（件）、ということですよね。受注した案件の生産リードタイムの平均が、例えば、20日、バラツキの標準偏差が3.6日の正規分布のとき、23日の納期ならば80％の確率で納期を守れる、ということではないですよね。
、、という話を、ある方にしたら、「それって、何が違うの？」と聞かれたことがあります。
うーん、、なにが違うんでしょうね。
じゃ、逆に、ある注文が来た時、顧客の希望納期に対して、納期に間に合う確率はわかりますか、と聞かれたらどうでしょう。我が社の納期遵守率は80％だから、80％だ、と答えますか。こう答えるのが前者の例。
注文って、いろいろありますよね。仕様もいろいろ。数量もいろいろ。その時の負荷状態（繁忙期か閑散期か）もいろいろ。顧客の重要度（得意客か初めての客か）もいろいろ。その他の様々な条件をひっくるめて平均した納期遵守率が80％ということ。今、受け取った（特定の）注文の条件を考慮した納期遵守率ではありません。
納期遵守率のキーファクターは投入から完成までの生産リードタイムと、顧客がいつまでにほしいのかの納期。
“生産リードタイム≦顧客の納期”のときは納期を守れますが、
“生産リードタイム＞顧客の納期”のときは納期を守れない、ということになります。
顧客の納期って、顧客によっても、注文品によっても、あるいは同じ顧客、注文品でも時と場合によって異なります。生産側の事情とは関係なしに納期はバラツキます。納期だけではなく注文数量もバラツキます。
これを生産側からみますと、いつ注文を受けて、その数量はいくつで、その時の稼働状態（代表的な指標は稼働率とか、受注残など）はどうか、などによって、生産リードタイムが決まってきます。受注時刻、数量、そして稼働状態、それだけじゃないですよ。それ以外にも、部品・材料の在庫、外注の納期遵守、作業者の技能、仕様変更、、などなど、生産リードタイムに影響を及ぼす要素はたくさんあります。
なんか、途端にややこしくなってきましたね。
「かんばん方式」ではカンバン1枚の数量は予め決められていますし、カンバンの到着時間間隔のバラツキも平準化生産の環境下では非常に小さい。バラツキがない（小さい）とメカニズムはすごく簡単になるんですよね。「トヨタ生産方式」が強い理由がわかります。
「トヨタ生産方式」をうらやましがってもしょうがありません。難題に真正面からぶつかってみるしかありません。
ある時、ある数量を受注して、それをいつ出荷しなければならないか。
これを実現するのが、生産ライン。生産ラインって、加工や組み立てを行う工程がいくつかあって、必要な工程を被加工物が巡回し、最終工程で完成する。工程と被加工物の流れるルートの関係は生産品により千差万別。
でも基本要素は、工程と被加工物。ひとつの工程を多数の被加工物が流れるのが、特徴でしょうか。
“ひとつの工程を多数の被加工物が流れる”ことが特徴。これが、結構重要なんですが、イマイチ、説明がうまくできなくて、苦労しています。
逆のケースはあるんでしょうか。
ひとつの被加工物が多数の工程を流れる”
工程と被加工物を入れ替えても、本質は変わりませんね。工程を基準としてみるか、被加工物を基準としてみるかの違いだけです、、。
ちょっと、表現を換えてみます。
“ひとつのものを多数の工程を経て完成させる”
“ひとつのもの”を大型船とかビルディングとか工場とか、、そうそう、“プロジェクト”にしてみましょう。そして工程を“タスク”に、、。
“ひとつのプロジェクトを多数のタスクを経て完成させる”
生産ラインからプロジェクト管理へ変わってしまいました。
生産管理もプロジェクト管理も、おんなしかぁ～。
表現を少し調整して、並べてみます。
“ひとつのプロジェクトが多数のタスクを経て完成する”
“ひとつの工程を多数の被加工物が流れて完成する”
完成するのは、ひとつのプロジェクトか、多数の製品かの違い。
この違いがリードタイムにどのような違いが出るか、なんですがね。
多くの人の反応は、「どちらも同じじゃないのぉ、、」。
分かりにくいんですよね、このはなし。ちょっと、雑談ぽくなりますが、、。プロジェクト管理にも生産管理にもスケジューリングソフトがあります。マイクロソフトはプロジェクト管理用のソフトは出していますが、生産スケジューリングソフトは出していません。生産スケジューラを出しているのは、日本ではたくさんありますが、有名なところではAsprovaやFlexsheと言った10数人の小企業。
なぜ、ITの巨人、マイクロソフトは生産スケジューラを出していないんでしょうね。
生産スケジューラの市場規模が小さいとみているからかなぁ～。それとも、技術的な理由があるのかな。
そう、そう。TOC（制約理論）でも生産ラインの管理にはDBR（ドラム・バッファー・ロープ）、プロジェクト管理にCCPM（クリティカル・チェーン・プロジェクト・マネジメント）という異なる方法を提案しています。これなんかも、プロジェクト・スケジューリングと生産スケジューリングの違いがあることを示唆しているのではないか、と。
どうやら、生産ラインのスケジューリングとプロジェクト管理のスケジューリング、同じではなさそうです。