人気ブログランキング | 話題のタグを見る

リードタイム、サイクルタイム、タクトタイム 〜 何がどう違うのか

数年前、「世界を動かすプロジェクトマネジメントの教科書」を書いたとき、プロジェクト成功の条件として、「チャレンジのOS」を定義した。組織のOSとは、体系化した思考と行動の習慣を意味する。そして、チャレンジのOSは、頭文字でいうと「S+3K」の4つの項目からなっている、とした。S+3Kのうち、最初のSは、システムズ・アプローチ、すなわちシステムな見方である。

あとの3Kとは、
・言葉を大切にする
・契約と責任を重んじる
・かならず計画をたてる
の略だ。そして、このOSを組織で共有しいていることが重要だ、と(登場人物の口を借りて)主張した。

なぜ、あえて『言葉を大切にする』を最初にあげたのか。理由は簡単。「言霊のさきわう国」のはずだった、わたし達の社会で、多くの人が言葉をぞんざいにしているからだ。いや、ぞんざいという意識はないのだろう。だが、自分の使っている言葉が正確に何を指しているのか、そして、その言葉が自分の所属するムラを離れて通用するのか、意外と無頓着に思えたからだ。

たとえば、「リードタイム」という言葉がある。リードタイム短縮、などという課題もよく耳にする。だが、そこでいうリードタイムとは、具体的に何を意味しているのか? そこを置き去りにしたまま、自分たちの文脈で勝手に理解して、議論が始まってしまう。そこで時々、リードタイムという言葉で何を指そうとしているか、問いたださなければならない。

わたしがよく使う質問は、「15年もののウィスキーをネットで注文したら、3日後に届いた。リードタイムはどれだけと言うべきか?」だ。それは15年なのか。3日なのか?

15年もののウィスキーを作るには、明らかに15年(以上)かかる。「リードタイム短縮」のために、作る期間を10年以内に短縮したら、詐欺である。では3日後に届く商品を、翌日配送できるようにしたら、それはリードタイム短縮ではないのか? いったい、リードタイムとは、何の期間のことを指しているのか。

言葉の意味が問題になるとき、世間では従来、広辞苑などの権威ある辞典をひらいて、定義を見る、みたいなことがよく行われた。最近ではかわりに、無料のWikipediaを検索したりする例もある。だがはっきり言って、Wikipediaはマネジメント・テクノロジー系の語彙に弱い。では、JISはどうか? JIS Z 8114:2001「生産管理用語」という規格はある。だが、この冊子を座右に持っている人は多くないだろうし、率直に言って、問題もあると考える(「下請け型受注生産という日本的形態を考える」 参照のこと)。

ウイスキーの例については、以前も論じたから、簡単に繰り返すにとどめるが、「リードタイムとは、何らかの指示(order)が発せられてから、それが完遂(fulfillment)されるまでの期間をいう」のである。そして、生産や物流の世界では、いろいろな種類の指示・オーダーがある。製品単位の生産オーダーだったり、部品・工程単位の製造オーダーだったり、倉庫からの出荷(納品)オーダーだったり。

したがって、リードタイムの種類は、オーダーの種類と同じだけある、ということになる:

生産リードタイム:生産オーダーが発せられてから、製品ができあがるまでの期間
製造リードタイム:個別の部品(工程)の製造オーダーが発せられてから、それが完了するまでの期間
出荷リードタイム:出荷指示が倉庫に発せられてから、実際に出荷されるまでの期間
搬送リードタイム:物流搬送指示が発せられてから、搬送が完了するまでの期間
納品リードタイム:顧客から納品オーダー(=注文)を受けてから、納品されるまでの期間
・・・

15年もののウィスキーの生産リードタイムは、明らかに15年以上である。樽で熟成する工程の製造リードタイムだけをとっても、15年かかるからだ。その前に原料の醸造や蒸留があり、熟成後もボトリング・包装などの工程がある。ただし、納品リードタイムは3日である。それは、出荷リードタイム2日と、搬送リードタイム1日の合計かも知れない。受注したら即日出荷の体制を作れれば、納品リードタイムは2日に短縮するであろう・・

では、リードタイムに類似した言葉である、サイクルタイムはどうか?

仮にあなたが、パン屋の主人だったとしよう。店の旧型のパン焼き釜には、1回に30個のパンを仕込める。焼き上げるまでの時間は、2時間だ。このとき、パン焼きのサイクルタイムは?

JIS Z 8114:2001によると、サイクル時間とは「生産ラインに資材を投入する時間間隔。通常,製品が産出される時間間隔に等しい」のだそうだ。あなたは、2時間毎にパンの材料を釜に投入する。ということは、サイクルタイム=120分である、と。

ところで、あなたは設備投資をして、新しいパン焼き釜にとりかえることにした。今度は、コンベヤ式の連続炉だ。もちろん、炉の中を通り抜ける時間は2時間かかる。ただし、連続生産なので、同じ量を生産するなら、4分に1個ずつ、パンの材料を投入する。JISの定義によると、サイクルタイム=4分になる。

リードタイム、サイクルタイム、タクトタイム 〜 何がどう違うのか_e0058447_08202732.jpg
1日の生産量は同じで、釜の中で焼く時間もまったく変わっていないのに、サイクルタイムは1/30だという。何か、間違っていないだろうか? もっというと、パン材料が液体で連続供給され、コンベヤの上に1個ずつノズルから絞り落とされるような自動化工程だったら、どうするのか? JISのサイクルタイム定義は、固体のことしか考えていないと言わざるを得ない。 

元が横文字の言葉の場合は、米国の生産在庫管理協会APICSの出している、APICS Dictionaryが一応、頼りになる。そこのCycle timeの項には、こういう意味のことが書いてある(拙訳):

サイクルタイムとは、1) IEで、2個の生産物の時間間隔。2) マテリアル・マネジメントで、資材が生産設備に到着してから、そこを出るまでの時間。

語義が2つ書いてあるが、最初はIE(生産工学=Industrial Engineering)の用語で、ストップウォッチを使った作業員の動作時間の分析などに用いる用語である。なので、一つのモノを作ってから次の部品を手に取るまで、といった比較的ミクロな時間を問題にしている。

生産管理に関連する、工程ないし工場レベルのマクロな用語は2番目で、こちらは明確だ。そして、この定義に従えば、パン焼きのサイクルタイムは、どちらも120分であることが分かる。設備(工程)を通り抜ける時間は、普通の釜だろうが連続釜だろうが、変わらない。そしてサイクルタイムは、設備ごとに値が変わりうる。

いいかえると、リードタイムはオーダーを起点とした概念、サイクルタイムは資源(工程)視点からの概念といっていい。でもまあ、一連の工程単位、あるいは工場全体を問題にした場合、リードタイムと、サイクルタイムはよく似た概念である。

もっとも、APICSの定義を注意深く読むと、サイクルタイムは「資材が生産設備に到着してから、出るまで」といっている。つまり、もしもその設備の前に、たくさん処理すべき資材が溜まっていたら、そこで滞留している時間もサイクルタイムに含む、ということになる。もっとも、標準リードタイムの方だって、その設備の前に常に滞留があるのなら、それを考慮する必要があるから、平均的な滞留時間を含むはずである。

で結局の所、リードタイムは「計画上の標準的な設定時間」、サイクルタイムは「実際にかかる時間の実測値」という使い分けをされる場合も多い。

じゃあ、連続釜の4分というのは何か? じつは、これは製造ラインにおける「タクトタイム」なのである。Taktとは、オーケストラの指揮者の振る棒のことで、ようするに一定のリズムのことを指している。とくに量産型の製造ラインで用いられる尺度だ。たとえば乗用車の最終組立ラインは、1分間に1台、というタクトタイムで動くことが多い。

少しまとめよう:

リードタイム(LT):
 オーダーが出されてから完遂されるまでの時間。オーダーの種類毎にある。
 顧客注文から納品完了まで  =納品リードタイム
 生産オーダーから生産完了まで=生産リードタイム、等

サイクルタイム(CT):
 工程単位のCT=工程への到着から完了までの平均所要時間
 工場全体のCT=原料投入から製品出荷までの平均所要時間
  (上記には原料在庫・中間在庫や滞留の待ち時間も含む点に注意)
 リードタイムは計画上の値。実効値をサイクルタイムという。

タクトタイム(TT):
 複数工程やラインで、同一製品を同期して均等に生産する場合のサイクルタイム

最初におことわりしたように、世の中では言葉の使い方はまちまちである。しかも日本にはAPICSの資格試験みたいな生産管理分野での標準資格もないため、方言が使い放題だ。だから、上述の解説は、あなたの会社の用語とは違っている可能性も大きい。

しかし、あなたの会社の中でさえ、部署によって違う意味でつかっているかもしれない。そういうときは、何か基準を作ることが必要だ。その時に参考になるかもしれないと思い、あえてここに解説する次第である。

<関連エントリ>

# by Tomoichi_Sato | 2021-06-03 08:24 | 工場計画論 | Comments(1)

「プロジェクト&プログラム・アナリシス研究部会」(6月10日)開催のお知らせ

各位:

「プロジェクト&プログラム・アナリシス研究部会」の2021年第3回会合を開催いたします。今回もオンライン形式になりますので、ご了承ください。

みなさんは『ローコード開発』という言葉を聞いたことがあるでしょうか? プログラムのコーディングを不要、または最小限にして、ソフトウェアを開発する仕組みの一つです。

ご存知の通り、ソフトウェアは普通、何らかのプログラム言語を用いて開発します。ゼロからコーディングしてシステムを作り上げるやり方が、「スクラッチ開発」です。ユーザの望む通りの機能を実装できるわけですが、コストと時間がかかります。この対極にあるのが「パッケージソフト導入」で、出来上がったソフトを買ってきて、多少のパラメータ設定をした上で、ユーザの使用に供します。業務にピッタリ合えば、比較的安く、早く出来上がります。しかし望んだ機能がないと(そういう場合が多いのですが)、業務を変えるか、不足機能を追加(アドオン)開発する必要があります。ユーザの望むような、小刻みな機能変更も、事実上できません。

ローコード開発は、両者の中間的な性格を持つ方法です。機能的な仕様を設計したら、その設計情報を元に、(半)自動的に動くソフトウェアが生成されます。このために画面や処理ロジックを、部品のように用意してあり、組み合わせて動かす仕組みです。このため「超高速開発」と呼ぶこともあります。機能的な変更も、ユーザが自分でできるようになる点も特徴の一つでしょう。

プロジェクト・マネジメントの世界でも、ソフトウェア開発プロジェクトは、かなりの難物だと考えられています。その主要な理由の一つは、コストの大部分を占めるプログラム開発作業の見積が、難しい点にあります。ローコード開発は、そうしたIT開発プロジェクト・マネジメントのあり方を、大きく変える可能性を持っています。

今回は、ローコード開発ツールの一つで、とくに製造業系のアプリケーション分野に強いユニークな製品・「TALON」を出しているベンチャー企業、(株)HOIPOI代表取締役の古関雄介様をお招きしました。プログラマの人月を売って儲ける、SIerというビジネスモデルが曲がり角に来ている今日、ソフトウェア開発の未来について、持論を語っていただきます。ぜひご期待ください。


<記>

■日時:2021年6月10日(木) 18:30~20:30

■講演タイトル:
ローコード開発手法でプロジェクトマネジメントはこう変わる

■概要:
企業向けの業務システム開発は近年DX・IoTを中心キーワードに変化を続けています。一度作ったら長期間大きな変更なく運用するシステムから、環境変化にキャッチアップする為にシステムも短期間での変化が求められています。これらの変化に対応する為、プロジェクトマネジメントの手法にも変化が必要になっています。
当講演ではこの変化に対応する為のローコード開発手法を使ったマネジメント・開発の進め方についてお話しします。

■講師:株式会社HOIPOI 代表取締役 中小企業診断士 古関 雄介様

 
■講師略歴:
古関 雄介(44歳)
1999年にIT業界に入り、ネットワークインフラ、プログラミングを経験。JavaによるMVCフレームワークを自作。
2003年に自動車部品メーカーの基幹システム導入(PM兼PL)を実施し、業務システムの全工程を体験。
以降は様々な企業向けに基幹システムの導入を実施。
2008年に中小企業診断士を取得。
2014年にローコード開発ツールメーカとして起業。製品名:「TALON(タロン)」

■参加希望者は、三好副幹事までご連絡ください。後ほどオンライン会議のリンクをお送りいたします。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 
 以上、よろしくお願いいたします。


佐藤知一@日揮ホールディングス(株)


# by Tomoichi_Sato | 2021-05-26 23:02 | プロジェクト・マネジメント | Comments(0)

(くどいけれど)マネジメントにはテクノロジーが存在する

このサイトの目的は、『マネジメント・テクノロジー』について考え、それを読者と共有・議論することにある。マネジメント・テクノロジーとは聞き慣れない言葉かもしれないが、ま、要するにマネジメントのテクノロジーである。

・・えーと、これじゃ何も説明したことにならないか。日本語で『管理技術』と言ってもいいし、スペース節約と通じやすさのために、そう書くこともある。だが、ほんとは少しニュアンスが変わってしまう。とくに「管理」という日本語は、英語のManangementと守備範囲も異なるし、人びとの受け取る感情も違う。なので、決してカタカナ好きではないのだが、マネジメントという表記を選ぶ

テクノロジーの方は、単純に日本語の技術でいいじゃないか。もちろん、そう思いたい。だが、日本語の『技術』がまた、曖昧に使われすぎているのだ。たとえばあなたは、技術と技能を線引きして、使い分けているだろうか? 「あの人のPythonプログラミング技術はすげえ」みたいな言い方は、よく耳にする。でもこれ、実は属人的なスキル、すなわち技能のことを指している場合が多い。

Technologyという英語は、Science - Technology - Engineering、という系列の中で位置づけられる。Scienceは『科学』であり、その目的は真理の探究、客観的な法則性の発見にある。世の役に立つかどうかは二の次、ないし無関係である。科学とはいうなれば、法則性の知識に関する体系である。

これに対し、Technologyは、Scienceの発見の土台の上に構築される発明・方法の体系であって、世の問題解決に資することが大事だ。ただし、実効性が検証されており、役に立つならば、たとえ真の科学的基礎がまだ不明であっても、技術者はそのTechnologyを使うだろう。事実、いろんな分野で使っている。

ではEngineeringとは何か。これを『工学』と訳してしまうと、かえって分からなくなってしまう。明治時代の大学で、科目名を設定する際に、何にでもすべて「〜学」をつけてしまったせいで、この混乱が残っている。Lawはべつに法「学」ではないし、Economicsは経済「学」ではなく、Architectureも建築「学」ではない。同様にEngineeringは工学という名の学問ではない。わたしは長年、「エンジニアリング会社」に務めているが、そこは別に工学の研究をする組織ではない。

Engineeringとは、何らかの仕組みを設計し、実装する諸活動の総称である。その中では、様々なTechnologyを統合して、用いる。もっとも場合によっては、実装をProductionとかInplementationと呼んで、狭義のEngineering=設計と区別する場合もあるが、ここでは広義のEngineeringについて論じている。そしてEngineeringという活動の中心には、複数のTechnologyのインテグレーションがある。

Engineeringという活動は普通、ビジネスとして行われて、その職業に従事する人びとをEngineerと呼ぶ。Technologyは方法の体系であって、それ自体はビジネスではない(まあビジネスの種とは言えるが)。Technologistという職種を自称する人びとも、まずいない。

テクノロジーに話を戻そう。テクノロジーは世に役立つことを主たる価値とする、と書いたが、もう一つ重要な特徴がある。それは、『再現可能』『共有可能』『移転可能』なことである。テクノロジーの多くは、なんらかの「道具」の形に結実して、繰り返し結果を生むことができ、かつ、人の手に渡すことができる。人に渡せないもの、個人の五感やセンスに依存するもの(senseという英語は「感覚」という意味だが)、つまり属人的な能力は、技能(Skill)と呼ぶべきである。

古くから日本では、縄目が均等に12箇所ついた縄の輪を、測量や工事で用いていたと聞く。この輪を、3:4:5の長さの辺からなる三角形に張ると、3:4の辺の角が直角になる。ピタゴラスの定理(和算では「勾殳玄の定理」)の応用である。この道具を使うと、直角の割り出しを、個人の感覚に依存せずにすむ。そして誰でも、経験が少ない者でも、ただしく直角を割り出せるようになる。これがテクノロジーである。誰かベテランが感覚的に、直角をどんなに正確に描き出すとしても、それはその個人の技能に過ぎない。
(くどいけれど)マネジメントにはテクノロジーが存在する_e0058447_22575252.jpg

つまりテクノロジーとは、組織全体の能力を底上げするものなのである。組織の能力は、構成員の能力の単純な足し算ではない。テクノロジーを用いて、組織全体の能力の向上を可能にする、という発想がそこには必要だ。いや、むしろ組織と言うものは、テクノロジーの力を使って、全体として能力を共有・向上できるように設計されていなければならない。

テクノロジーの道具はもちろん、物的なものばかりではなく、計算チャートやプログラムなど、手順・アルゴリズム類も含んでいる。むしろ、アルゴリズムを記憶媒体に記録して共有・移転可能にしたノイマン型コンピュータは、このテクノロジーの範囲を大きく拡げたと言っていい。

ただし、テクノロジーという言葉を、ITやデジタル技術のみに限って使う人が、ときどきいる。「当社はテクノロジーを活用した成長戦略を云々」というから、どんな事かと思って資料を読んでみれば、デジタルの話ばかりだったりする。CTOという役職の人が、専らアジャイルとデータ分析の話ばかりしたりする。こういう傾向は、MBAあがりのコンサルタントなどにも、結構多いが、それは狭すぎる使い方である。

なぜ、こういう偏った語法が通用するようになったかというと、例によって米国のトレンドの真似なのだ。主にアメリカで、金融業とか、小売業とか、B2Cのサービス業などの業界において、大企業がIT (Information Technology)を導入活用するようになった際、IT技術を単にTechnologyと呼んだことに由来しているらしい。

なるほど、こうした業界では、日本風に言えば「文系」の仕事ばかりだから、ITという理系チックな方法の体系が入ってきたら、Techonlogyという語を独占できるのだろう。かつ、こうした業界は戦略コンサルタント業の良いお客様だから、その語法がコンサル業界にもうつったらしい。

しかし、自動車メーカーでも半導体メーカーでもいい、モノづくりに電子やら機械やら計測やら、さまざまな分野技術を総合して使っているような企業では、CTOがITのことしか語らない、などという現象は起こらない(そしてついでながら、戦略コンサルの人達は、こうした、本来の意味でテクノロジー・リッチな企業の成長戦略は、業界出身者でない限り、なかなか描けないのである)。

もう一つ、ついでに書いておこう。それは、「テクノロジー」と「テクニック」の違いである。テクノロジーは、繰り返すが、移転可能な(=客観的・非属人的な)方法の体系である。では、テクニックとは何か。それは、主に道具や方法の使いこなし方に関する、個人的なスキルを言う。また、体系化されていない、ちょっとした道具や方法を、テクニックと呼ぶことも多い。日本語の「コツ」にも通じる。

誰かが、自動車を複雑な街路をすごいスピードで運転できたら、その人は高度な運転テクニックを持つ、という。まちがっても、その人は運転テクノロジーを持っている、とはいうまい。上記の縄目による直角の割り出しも、それ単体だったら、まあテクニックの部類である。それが木造の日本建築の体系の中に組み入れられているから、テクノロジーの一部とよべるのだ。

それこそ端的に、「あの人はすごいテクニックを持っている」というが、「あの会社は高度なテクニックを持っている」とは言うまい。そう言われると、どんな会社なのか、妙な想像がしたくなるではないか(笑)。かくのごとく、テクノロジーとは、組織単位のものなのである。

だから、マネジメントのテクノロジー、というとき、それはマネジメントに関して、再現可能・移転可能な、組織の共有する方法の体系を意味するのである。

・マネジメントには、客観的で移転可能な方法論がある
 (その根拠には科学的な法則性がある)
・マネジメントは、属人的・主観的なスキルではなく、組織レベルで共有できる能力である
・マネジメントのテクノロジーは、組織のパフォーマンスを上げることができる

これは、通常信じられている、下記の考え方と真っ向から対立することが、お分かりいただけるだろう。

・マネジメントは、リーダー個人の属人的な能力で決まる
・リーダーの成果を決めるのは、その人の「やる気」と、「資質」や「運」である
・組織の能力とは、構成する個人の能力の足し算である
・組織のパフォーマンスが落ちたら、リーダーを取り替えればいい

もちろん、マネジメントは人が人を動かすことであるから、不可避的に属人的な要素が関わることは、否定しない。そして、人の活動は、モチベーションが大切であることも、いうまでもない。ただ、それらは必要条件かも知れないが、十分条件ではないといいたいのだ。下側の考え方は、そこを不必要に強調しすぎているというのが、わたしの意見だ。

わたし達の社会のマジョリティが、下側の考え方で動いている限り、現在のような不況と混沌からは、決して抜け出せないだろう。だが、残念ながら、今の大学教育でも、企業研修でも、マネジメントのテクノロジーについて教えている場所はきわめて少ない。だからこそ、ささやかながらセミナーやら研究会活動などを通じて、同志を集めようと心がけているのである。


<関連エントリ>
  (2019-10-05)


# by Tomoichi_Sato | 2021-05-23 23:18 | ビジネス | Comments(1)

ライン、ショップ、セル 〜 生産方式を理解する

社内の勉強会で、若手のエンジニアに対し、「スマート工場とは何か」をテーマに話をしている。といっても、スマート工場に関する共通定義が、世の中に明確にある訳ではない。だから、既存の工場にロボットやAGVを1,2台導入して、ちょっぴり作業を自動化したり、タブレット端末やセンサーを数カ所につけて情報化したりしたら、誰でも「ウチはスマート工場です」と言えてしまう。ある意味で便利な(?)社会である。

もちろん、AGV(Automated guided vehicle=自走台車・無人搬送車)を導入してちゃんと動かしたり、センサーで意味あるデータを取得したりする取り組み自体は、意味あることだ。そのこと自体を否定するつもりは、まったくない。また、そうした取り組みは、けっして、端の人間が見るほど簡単ではない。

どうしてかというと、工場はそれなりに多数の設備と業務が組み合わさって、できあがっているからだ。そこに新しい設備や仕組みが、急に割り込んできて、それが場所や電源供給や通信を必要とし、勝手な自分のタイミングで動くのだ。かつ、こうしたスマートでデジタルな新参者たちは、妙に「石頭」なので(=ふるまいを変えるためにはプログラムを変更しなければならない)、周囲とどうしても軋轢を生みやすい。

そうした苦労を経て、ようやく一部の工程をスピードアップし、一部の設備の稼働率をあげたとしよう。担当者はデータやグラフを示して、その有用性をアピールするだろう。当然のことだ。だが、ではそのスマート化は、工場全体のパフォーマンスにどうつながるのか? このところ頻発している納期遅れや、品質トラブル、はたまた人員不足問題を、どう改善したのか。

実は、よく分からない、というのが、多くのケースでの本音だろう。そんなこと大声で言えないから、誰も口にはしない。とにかくプラスにはなっていると思う。なっているはずだ。そうは信じている。だが、数字で示すのは難しい。

理由の一つは、そもそも工場全体のパフォーマンスを示すKPI、たとえば納期遵守率が、定常的に集計されていないからだ。そんなの簡単だ、注文書の納期通りに納めたかをチェックすればいいじゃないか、と思う人もいるだろう。だが受注後に急に仕様や数量の変更要求があり、工場と相談なしに営業が元の納期通りで受けてしまったら、それはどうカウントするのか? 顧客が示した月次の内示と実需の合計が、大幅に違ったら、どうするのか?

だが、もっと根本的な理由がある。それは、工場が生産のための仕組み=システムである、ということだ。システムというのは、その一部が変わったからと言って、全体のパフォーマンスが比例して良くなるとは限らない。

かりに自動車で、エンジンだけを、大きな排気量のものに取り替えたら、クルマのスピードや運転性能が歴然と上がるだろうか? 当たり前だが、ミッション系からタイヤ・足回り・ブレーキ系・電装系まで、すべて足並みを揃えて変えていかなければ、全体の運転性能は上がらないのだ。それがシステムというものの性質だ。システムの性能は、要素の性能の単純な足し算ではない

なので、工場のパフォーマンスを上げたかったら、工場というシステムの仕組みを知らなければならない。良い工場を設計したかったら、工場という『生産のためのシステム』の成り立ちを、まず理解する必要がある。

エンジニアという人種は、新しくてカッコいい技術の話が大好きだ。それに比べて、生産システムみたいな基礎的な話は、地味で、どう役に立つのか、分かりにくい。だから、こういう種類の話は、書籍にも雑誌記事にもなりにくい。ネットの情報も限られている。なので社内の勉強会が必要なのだが。

という訳で、スマート工場を作りたかったら、まず工場の仕組みと成り立ちを理解しなければならない。そのためには、対象とする工場について、

(1) 品種数と生産数量
(2) 生産形態
(3) 生産方式
(4) サプライチェーンの中での位置

を知ることが、真っ先に必要な仕事だ。これをおさえなければ、始まらない。

また、上記の4項目が同じだったら、その工場が何を作っていようが、実はオペレーション・マネジメント上の課題は、共通していると思っていい。極端に言えば、電車の部品を作っていようが、特殊な機能性素材を作っていようが、はたまたお洒落なクッキーを作っていようが、上記の4条件が同等なら(ま、思いつきであげたこの3品目が同等になることは滅多になさそうだが)、同じ知恵が使えるだろう、ということだ。

これは、個別の製品設計や製造技術に関わっているエンジニア達には、意外だろうと思う。また、企業を「業種・業界」で分類したがる、メディアや役所や経済団体の人達にも、意外だろう。複数の異なる業種の工場・プラントづくりに関わってきた、エンジニアリング会社の人間だからこそ、ピンとくる話なのかも知れない。

上記の内、(1)品種数と生産数量については、横軸に品種数(P: Product)をとり、縦軸に生産数量(Q: Quantity)をとってプロットする「P-Q分析」が、よく用いられる。品種数Pが少なく生産数量Qが大きいものは、「少品種大量生産」で、図では左上に位置する。逆に、品種数Pが多く、生産数量Qが小さい場合は、「多品種少量生産」になる。図では右下に来る。

次の(2)生産形態については、すでに当サイトでも何度か解説したことがあるので、ここではスキップしよう。
ライン、ショップ、セル 〜 生産方式を理解する_e0058447_13244374.jpg

(3)の生産方式は、大きくいうと、化学プラントなどの流体を扱うプロセス系と、組立加工系で固体を扱う「ディスクリート系」に分かれる。日本では自動車産業や電気産業などの裾野が大きく、後者に属する工場が大半だ。そして、ディスクリート系工場における生産方式は、さらに、以下の4種類に大きく区分することができる。

1. フローライン

 コンベヤで連続的にワーク(加工対象)が流れる方式。いわゆる「フォード・システム」が源流である。作業者は細分化された作業を受け持つ。大量生産向きといえる。

2. フローショップ

 上記に似ているが、コンベヤでワークが自動的に流れていくのではなく、複数の工程が別々に並び、その間をワークを順に(ただし非同期的に)流していく方式。

3. ジョブショップ

 複数の工程(作業区)間を、ワークが行きつ戻りつ動く方式。作業者は複数台の機械を受け持つことも多い。工順が個別に変わるような、多品種少量生産向きである。

4. セル生産

 一人の作業者が「セル」内で、複数の工程を受け持つ。そして工場内には複数のセルが並んでいて、同等の機能を果たす。この用語は90年代に、ソニーから始まったと聞いている。

ちなみに、セル生産方式と、従来のフローショップやジョブショップの違いを説明しておこう。後者では、作業者が特定の工程に専任しており、単能工的になる。技能蓄積にはいいが、負荷変動が大きいと、人が余ったり足りなくなったりしがちである。セル生産は基本的に多能工的な方式のため、負荷変動に応じて、セルの数自体を増減すればすむ。また、モノの搬送も比較的少なく済むメリットがある。

この4種類の生産方式は、当然ながら工場の物理的なレイアウト設計の基本になる。ただ、どこに在庫ポイントをもつかによって、同じ生産方式でもレイアウトは異なってくる。そして在庫ポイントの設定は、(2)生産形態によって定まるから、結局、その両者を適切に選んで組み合わせないと、良い工場にはならない事が分かる。そして生産形態は、さらに(4)サプライチェーン上の位置づけ、に大きくしばられる事になる。

という訳で、こうした工場のマクロな特性を最初に理解することが肝心なのだ。

・・という話をしていたら、若手から、「そういうことを、もっとちゃんと勉強したいのですが、何かおすすめの本はありますか?」と質問された。

うーん、それがねえ。良い本がないんだよねえ。「モノづくり大国ニッポン」のはずなのに、こういう原理原則を体系的に述べた、教科書的な本がないんだ。そういう技術的・専門書的な本を出しても売れません、と出版社の人は言う。売れないから出ないのか、出ないから売れないのか、本当のところは分からないけどねえ。

いいたかないけど、米国ではねえ、生産マネジメント研究と教育に特化した工科系大学が複数あるし、APICSのような民間ベースの技術者団体があって、資格制度と研修カリキュラムを整備しているので、参考書はいろいろあるんだよ。

でも、日本ではねえ、無いんだよねえ。大学の先生も作ってくれないし。そもそも、大学の先生って、学会誌に論文を何本書くかで、文科省から能力を測られるからねえ、基礎的な本を書いても業績にならないんだ・・

「じゃあ、どうしたらいいですか?」

うーん、そうだねえ。せめて、僕の個人的なサイトがあるから、それを見て自分で考えてもらうしかないだろうねえ(苦笑)。

・・という、オチでした。


<関連エントリ>


# by Tomoichi_Sato | 2021-05-15 14:32 | 工場計画論 | Comments(0)

講演のお知らせ:「生産スケジューリングの基礎とリードタイム短縮への活用ポイント」(6月2日)

久しぶりに、生産スケジューリングとリードタイム短縮をテーマとした研修講演を行います(オンライン・有償)。前回は2018年に実施し、お陰様で好評だったためアンコール講演も開催しました。今年はさらに今日的な課題も盛り込み、バージョンアップしてお届けします。

今なぜ、リードタイム短縮なのでしょうか? QCD(品質・原価・納期)は、製造業の最も重要なKPIです。そしてこの3つの指標は、互いに連動し合っています。あちらを立てればこちらが立たず、のトレードオフ関係が生じることもしばしばです。

過去25年間の不況の間、日本企業はひたすらC(原価)を主眼に置き、コストダウンに邁進してきました。在庫を削減し、人を切り、外注価格を下げ、そして工場をアジアに移転し、頑張ってきた訳です。その間、顧客からのリードタイム要求(D)も、短くなる一方でした。ですが結果として、そのツケは、日本製品の命綱であったはずの、Q(品質)の低下という形で回ってきました。

1年以上にわたるパンデミック禍の時期を経て、市場の需要は現在のところ、まだら模様ながら回復傾向にあります。しかし海外に延びきったサプライチェーンの脆弱性と、深刻な人手不足問題により、多くの企業は納期遅延問題に今、あらためて直面しています。自社の工場内を督促すれば済む、と考えられていたリードタイム短縮に、より広い視野とシステムズ・アプローチで、取り組む必要が出ているのです。

とはいえ同時に、製造業におけるDX(デジタル変革)が、一種トレンド化してきています。だったら、QCDのトレードオフ解決と、デジタル化の取り組みを、組み合わせられないかとの発想も生まれて当然です。

しかし、そのためには、生産活動の仕組み=『生産システム』の基本デザインを理解する必要があります。ここで言うシステムとは、単なるコンピュータのことではなく、働く人々と、機械設備と、物流と、それを包む建築空間からなる、生産の仕組み全体を指しています。この基本的な理解を抜きに、ただ流行であるAIやIoTなどの「スマート化」技術を追いかけても、部分的な改善効果しか生まないでしょう。

また生産システムは、自社を取り巻くサプライチェーンの特性に応じて、適切な機能構成を選ばなくてはなりません。単に、業績の良い他社の物真似をしても、生産形態が違えば、役に立たないのです。

本サイトの読者の方はご存知の通り、わたしは具体的なテクニック論のみならず、原理に関する体系的な理解を重視し、生産システムをより良く運用するにはどうしたらいいかを考える『システムズ・アプローチ』をとります。そのため業種分野については、わりと間口を広くとってお話しできる点が特徴です。

わたしの講演は、製造業の方だけでなく、ITコンサルタント系の受講者の方にも、それなりに役立つ内容である点も特徴です。従来の現場改善的なアプローチに限界を感じておられる技術者の皆さんに、ヒントとなればと願っております。


生産スケジューリングの基礎とリードタイム短縮への活用ポイント ~演習付~ <オンラインセミナー>

日時: 2021年6月2日(水) 10:30 ~ 17:30
主催: 株式会社日本テクノセンター
会場: WebExを用いたオンラインセミナー
   (グループ演習を入れるため、受講される方は、マイク機能の用意もお願いいたします)

生産計画とスケジューリング、リードタイム短縮について、事例と演習を含めてお話しします。

セミナー詳細: 下記のURLをご参照ください(受講申込もここからできます)

関心のある大勢の方のご来聴をお待ちしております。


佐藤知一@日揮ホールディングス(株)


# by Tomoichi_Sato | 2021-05-07 12:56 | サプライチェーン | Comments(2)