タイム・コンサルタントの日誌から

製造業のプロジェクトがうまく進まない、本当の理由

• プロマネはどこにいるのか？

先日、名古屋工業大学で開催されたプロジェクトマネジメント学会中部支部のシンポジウムに参加し、アビーム・コンサルティングの阿部さんと一緒に講演をする機会があった。メインテーマは「MES導入のための標準業務テンプレート」の紹介で、我々の研究会で開発リーダーである阿部さんが解説されたが、わたしはその前振りとして、製造業におけるプロジェクトの共通課題についてお話しした。

わたしが訴えたかった共通課題とは、一言でいうと『プロマネ不在問題』である。プロジェクトは必要があって発足し、進んでいくのだが、肝心のプロマネが誰だか分からない。大事な決断を誰が下し、誰が権限と責任を持つのか分からない。そんなバカな、と思う人もいるだろうが、しばしば見かける現実である。こんな状態では、ものづくり改革だとか工場スマート化などが、うまく進むわけがない。

プロマネが誰だかわからないのだから、「プロジェクト・マネジメント計画書」なども、きちんと存在するわけがない。当然ながら、ベースライン計画を前提としたマネジメント・プロセスも機能するわけがない。つまり、普通の意味でPM標準が規定するような知識や技術は、適用されない（適用しがたい）ことになる。

日本PM学会は、米国PMIが策定したPMBOK Guide(R)の紹介活動や、最近は欧州IPMAとの提携によるPM標準の普及などを進めている。そしてPM学会の構成員の大多数を占めるIT業界では、確かにプロマネなりプロジェクトリーダーなりの職種も、かなり確立してきた。しかし、プロマネすら不在の組織では、PMBOKの10のマネジメント領域どころではない。非常に大きなギャップが存在する。どうしてこうなのか？

• 製造業におけるプロジェクトとは

ずいぶん以前のことだが、プロジェクト・マネジメントの本を読んでいたら、

「『プロジェクトはタコ壺であり骨壺だ。一度入ると生きては戻れない』－－こんな感想をよく耳にする」

と書かれていて驚いたことがあった（「書評：『はじめてのプロジェクトマネジメント』近藤哲生・著」 ）。著者は製造業の重鎮・日立製作所のOBである。「そういう会社なんだなあ」と、当時思った（今は違うのかもしれないが）。

日立は製造業であり、かつIT受託開発の元請けもやる会社だ。だがIT受託の分野をもたない普通の製造業でも、実際には様々なプロジェクトに取り組む必要がある。それは新製品開発プロジェクトであり、新工場ないし製造ライン増設プロジェクトであり、新販路開拓プロジェクトであり、あるいは業務改革プロジェクト（これにはしばしば、ITシステム開発プロジェクトが付随する）であろう。ものづくり改革とか工場スマート化は、最後のカテゴリーの一つと捉えても良い。

これらのプロジェクトに共通する1つの特徴は、複数部門の協力がいる点だ。もちろんそれはプロジェクトの規模や複雑性に依存する。比較的シンプルな製品のバージョンアップに伴う新製品開発などは、設計開発部門だけで完結するかもしれないし、 小規模なラインの増設は、生産技術部門だけでほとんど終わるだろう。仮に他部門の協力が必要だとしても、業務上隣接する部門、例えば企画部門と設計部門、あるいは生産技術部門と製造部門といった、接点の多い部署との調整で良い。

ところが、新しい製品ファミリーを作るようなタイプの新製品開発では、企画・設計・研究・生産技術・調達・製造・物流・営業…といった、かなり多数の機能部門が関わることになる。 そして、それぞれの部門は、お互いに異なる目標やKPIの尺度を持っていて、意見調整が簡単にいかないことがある。大型の新工場建設や、未経験の地域や国での販路開拓などでも、似たような事情が起きやすい。

• プロジェクトは部門横断（クロス・ファンクショナル）な取り組みである

日本企業は業務を回す実務レベルの人々が優秀で、それなりに権限範囲を持ち、隣接する部門同士の調整は上手にできると、前回の記事で書いた。 しかし、隣同士でのすり合わせで問題が解決しない場合、問題の全体構造を見た上で、誰かが決断を下す必要がある。それは本来、プロジェクト・マネージャーの役割である。

問題の全体構想とは何か。それはプロジェクトの予算であり、納期であり、またスコープ＝責任範囲（役務範囲）の制約である。 製造業の3大パフォーマンス目標値がQCDで、トリレンマの関係にあることを前回記事で書いたが、 プロジェクトでは、一般に品質の代わりにスコープ（役務範囲）をとる。これはスコープが全体の仕事量を表すからだ。品質を 確保するためのレビューやテスト等のアクティビティーもスコープの中に含まれるため、このようにする習慣だ。

そしてこの3つもトリレンマの関係にある。どれか1つを変更すると、他の2つに何らかの影響が及ぶ。だからプロジェクト・マネージャーの1番大切な仕事は、この3つの制約条件の中で、プロジェクトの価値を最大化するような選択肢を探して、決断することにある。

決断のためには、プロジェクト・チームの中で議論を戦わせ、様々な事実認識を共有し、いろいろな方策・オプションを提示し検討することが大切だ。だが、最終的には何らかの決断を下さなければならない。そして決断はタイムリーに行わなければならないのが、プロジェクトの現実である。

ところで、ほとんどの製造業は、機能別の組織になっている。1番上に経営者がおり、それを支える形で人事・財務といった本社機能と、研究開発機能があり、そしてライン業務を受け持つ部門が並ぶ。具体的には営業であり、技術、製造、物流などである。では、プロマネのいるべき部門はどこなのだろうか？

• 機能型縦割り組織と、プロジェクトの論理

ところで読者諸賢は、上のようなピラミッド型の組織図で、各部門を結ぶ線のことを、何と呼ぶかご存知だろうか？　英語では、これをレポーティング・ライン(Reporting line)という。 つまりレポートする（報告する）線である。「私の上司はジョンだ」を、英語では "I report to John"と表現する。 組織図の線は、報告及び指示を伝達するコミュニケーションのルートを意味している。

すなわち、組織における公式なコミュニケーションは、この線を経由しなければならないルールなのである。もちろん、昼食時に食堂でおしゃべりしたり、休日に一緒にスポーツを楽しんだりするような非公式のコミニケーションは、個人同士で直接行って構わない。

しかし例えば新工場プロジェクトで、検査部門の担当者が、生産技術部門の工程設計技術者に対して、新しい検査装置についての要望を出すとしたら、 本当は検査課長から製造部門長に上げて、技術部門長を通って、生産技術課長経由で下ろさなければならない。 これがピラミッド型機能別組織の、本来のルールなのである。

だがご存じの通り、部長同士が定例的に顔を合わせる部長会など、週1回か隔週である。プロジェクトの連絡調整を、いちいちそのルートでやっていたら、日が暮れてしまう。そして各部門は異なる目標値KPIと、異なる利害意識を持っている。それらが対立した場合、誰が意見調整をするのか？　まさか多忙な社長が、いちいちプロジェクトの個別の決断を下してはいられまい。

そこで本来は、経営者がプロジェクトに必要な権限と予算と責任を、『プロジェクト・スポンサー』という役職に委譲する。そしてスポンサーはプロジェクト・マネージャーを任命して、プロジェクト実務に専任させる、という建て付けでPMBOK Guideなどはできているのである。プロマネは、手を上げて自分でなるものではない。スポンサーが（あるいは、プロジェクトの上位にプログラムがある場合は、プログラム・マネージャーが）任命するものなのだ。

プロマネは、プロジェクト・チーム内の意見をとりまとめて、必要な決断を下す。決断を下すからには、その結果についても責任を持つ。それでも、周囲のステークホルダーが納得しないような重大な問題がもしも生じたら、スポンサーが経営層を通じて説得・調整を行う。これが欧米などのPM標準を貫く思考原則なのである。

• 製造業のプロジェクトは、「プロジェクト以前」に真の問題がある

ところが、日本の多くの製造業では、こうした思考習慣自体が存在しない。だから、プロマネ不在のまま、プロジェクトが始まってしまう。

拙著『世界を動かすプロジェクトマネジメントの教科書』 も、じつはこの問題を取り扱っている。本書の内容は元々、東大や静大の大学院でのPM講義がベースだが、講義そのままでは面白くないので、ストーリー仕立てに設定した。主人公は製造業の若手エンジニアである。年齢は30歳そこそこ。まだプロマネに立てるような年代ではない。

ところが彼の会社では、社長の思いつきで突如、アジア新興国の海外企業との「共同製品開発プロジェクト」が走り出すのだ。とはいえ、誰がプロジェクト・マネージャーなのかも、定かでない状態なのである。

主人公は設計部門に属していて、彼の直属上司の課長は本プロジェクトに大いに乗り気だが、その上の部長は腰が引けている、といったシチュエーションになっている。どう見ても、このままではプロジェクトはうまく行かない。そしてその問題は、担当者である自分の上に被さってくるはずだ。

危機感を覚えた主人公が、偶然空港で出会った大学時代の大先輩に、「プロジェクト・マネジメントの基本を教えてください」と他の頼み込むところから、本書のストーリーは始まる。単なる担当者の立場でありながら、主人公はどうプロジェクトを動かし、リスクを乗り越えていくべきか？

無論、著者としては主人公をこのまま放り出しておく訳にはいかないから、製造業の組織論に即した現実解の一つを、本には書いている（ご興味があれば、ぜひお読みくだされ^^）。でも、こういう風に進むかどうかは無論、個別の企業の状況によっている。

長引く不況の間、日本の製造業は、差別化を求めて新製品を開発し、新興国などの市場を開拓し、あるいは海外工場の移転などで活路を求めてきた。それらは皆、プロジェクトだ。だが、プロマネ不在の機能型組織でプロジェクトを進めたって、納期もコストも守れず、目指したアウトカムは得られまい。失われた30年は、製造業におけるプロジェクトの不調がもたらした結果である。

そして、その真の理由は、PMBOKみたいなPM標準が普及しない事にあるのではない。もっとそれ以前のところ、企業がプロジェクトを『プロジェクト』だと認知していないこと、決断が必要なのにプロマネが不在なことに起因するのである。

＜関連エントリ＞

「書評：「はじめてのプロジェクトマネジメント」　近藤哲生・著」 https://brevis.exblog.jp/10266445/ (2009-05-18)

「製造業のトリレンマ・QCDを決めるのは誰か」 https://brevis.exblog.jp/33340696/

製造業のトリレンマ・QCDを決めるのは誰か

• トリレンマとしてのQCD

トリレンマという言葉をご存じだろうか。トリレンマとは、満たすべき目標が３つあるのに、そのうちの 2つしか選択できず、残りの1つは諦めるしかない状況を指す。2つの選択肢に矛盾がある場合をジレンマというが、トリレンマはその3点版だ。

ちょっとネットで調べると分かるが、有名なのは「国際金融のトリレンマ」らしい。これは(1) 独立した金融政策、(2)為替相場の安定、(3)国際資本移動の自由化、の 3つのうち、2つしか選べない、という。

製造業で、このトリレンマに相当するのは、QCDのパフォーマンス指標だろう。いうまでもなく、Quality（品質）・Cost（コスト）・Delivery（納期）の頭文字だ。この三つは、まるで三角形の三辺のように関係し合っていて、他に影響を与えずに、独立にコントロールすることが難しい。

たとえば品質を上げたければ、その手段の一つとして検査を徹底する必要がある。しかしそうすると工程が増えて、コストが上がり、納期も長くなりがちだ。コストを下げるために安価な材料を選ぶと、品質が落ちることもよくある。納期を短くしようと、製品や中間部品の在庫を増やすと、コストが上がってしまう。

知人で研究会仲間である渡辺薫氏は、以前アメリカかどこかで見かけたピザ屋のポスターのことを、先日の『スマート工場人財育成セミナー』で話しておられた。このポスター曰く、お客様はQCDの三つの内、二つまで選ぶことができる。すなわち、

• 安くて早いピザ（その場合、味=品質は落ちる）、
• 美味しくて早いピザ（むろん値段は高くなる）、
• 安くて美味しいピザ（時間はかかる）

という訳で、三つとも満たす事はできない。無論このポスターは教育目的のジョークで、本物のピザ屋の宣伝ではないが、まさに製造業のトリレンマをうまく言い表している。

• 製造はシステムであって、足し算ではない

そして、このような教育用ポスターが作成されるのは、あの米国でも、QCDは独立して操作・達成可能だと信じる人間が、結構大勢いることを示している。こういう人たちの頭の中は、単純な足し算でできあがっているんだろうなあ。まあ楽観的で単純なアメリカ文化らしいとは思う。

ちなみにアメリカに限らず西洋文化のアプローチは、「分解と分析」による問題解決である。対象をこまかな要素に分解して、分析していく。そしてそれぞれの要素を操作することで、問題を直そうとする。臓器ごとに専門分化していく西洋医学など、まさにこのアプローチだ。分析思考と楽観性が合わさると、QCDを別々に分担する、という仕組みができあがる。

実際、米国企業の中には、設計図面や仕様書に、Quality ControlとSchedule Controlのチェック欄があるケースがある。日本企業の常識では、図面の作成・検討・承認欄というのは、担当者→係長→課長、みたいなタテの職位でハンコを押していく。だが、設計レビューにおいて、本当に上司の係長が、製造品質やスケジュールなど、ヨコに並んだ機能の観点で、きちんとレビューできるのか。問い詰められると答えに窮するに違いない。

とはいえ、こういうチェック欄を見ると、「品管とスケジュール屋が、真逆のコメントをしたら、一体どうするんだろうなあ」といった観想もわいてくる。まあ、そのためにマネージャーがいるんだ、と米国人なら答えるのだろう。部分に機能分解した後、全体を統合して判断するのは、マネージャーの仕事である。それが米国経営の論理だ。

ところで、日本型経営の感覚（というのがあるとして）は、似て非なるものである。仕事は縦割りに機能分化した部署間を、バケツリレーのごとく受け渡されて進んでいく。問題が見つかったら、それぞれの部署内でローカルに解決が図られる。問題を後続工程に流さない。いわゆる「自工程完結」である。設計部門は設計品質を、製造部門は製造品質を担保し、生産管理は納期を、調達は材料コストを、生産技術は生産性と賃率を担保する、と。それでも問題が起きたら、隣接する部門同士で相談・調整する。これはこれで、立派な足し算の論理である。

米国流の経営論理に従うと、実行部隊は平凡でもいいが、マネージャーは優秀で頭が良いことが要求される（実際にアメリカ人のマネージャーが皆優秀だ、と言っているのではないよ、それが要請だということだ）。他方、日本の経営感覚では、実行部隊が優秀であることが望ましく、その場合、管理職はお飾りでも良いことになる。逆から見ると、米国企業では細かな現場問題が多発しがちで、日本企業はマクロな経営問題が放置されがち、とも言える。

• コストとスケジュールはどこの段階で決まるか

さて、海外のことはおいて、日本の製造業での問題構造を少し見てみよう。

製造コストはそもそも、材料費＋労務費＋外注費＋その他、と分解できる。これらの内で、まず材料費については、製品に必要とする部品材料の構成と数量、すなわち部品表（BOM）が定まり、その工程設計が決まり、そして各部品材料の購入単価が決まれば、ほぼ決定されてしまう。つまり材料費は、設計・生産技術・調達部門がほとんど決めるわけで、製造や生産管理や品管部門が左右できる余地は少ない（もちろん良品率向上による廃棄コスト低減などはあり得るが）。

労務費は？　これは手作業が多い場合、たしかに人の習熟度で所要時間が変わる。とはいえ日本の製造現場で、人によって倍半分も違うようなケースは少ないだろう（労働者の入れ替わりが激しい海外工場と違い、人が年単位で働き続ける日本の現場で、そんな生産性のムラを放置しているようでは生き残れない）。労賃（賃率）も年間でほぼ決まる。まして工作機械などを多用する加工工程や、装置産業的な業種の工場では、そう大きく変える余地はあるまい。つまり、ここも製造現場側で工夫する余地は多くない（ただし、ムダな段取替えや不適切ななどによる時間ロスは、生産管理部門の責任だと言えよう）。

外注費も同様だ。どの工程を外注するか、その単価はいくらかは、概ね製造着手段階で決まっていることが多い。急な納期変更や能力あふれで、現場判断で外注に出すケースはあるだろうが、外注費の大部分は現場努力で減らせないと思う。そして、その他費用としてのエネルギー費用・金型費・機械賃率（減価償却費）等も、現場がその場で工夫できる余地は小さい。

だから結局、製造コストは設計と調達段階で大方が決まってしまう訳である。設計・生産技術・調達部門が本社にあるか工場にあるかは、企業によってまちまちだが、いずれにせよ製造に着手する前の段階（ISA-95のレベル風にいうならば、Level-4のビジネス業務）でコストはかなりが決まるのである。ITシステムでいうと、PLMやERPの領域だ。

ではスケジュール（納期D）は？　これはさすがに、現場側、とくに生産管理の采配で決まる。無論、基本的なリードタイムは目安があり、それは営業を通じて顧客に納期回答しているのだろうが、スケジュールは生産管理部門と、彼らの使う生産管理システムが握っている。つまり工場の中二階にいる、製造スタッフの人たちの責任範囲だろう。

• 品質はどこで決まるか

じゃあ、トリレンマの最後の一齣・品質（Q）はどうか。ここでは、設計品質は脇に置いて、製造品質を考えよう。これはさすがに、設計でも調達でも生産管理でもなく、現場のショップフロア側の責任範囲だと言えよう。

ただし、トリレンマの中で品質がやっかいなのは、コストやスケジュールと違い、品質が数値化しにくいことだ。良品率や直行率など、マクロな指標で代表的に言える業種と、そうでない業種がある。

品質問題が起きたとき、その理由を調べるためには、素材（マテリアル Material）それ自体と、使った機械設備（マシン Machine）と、作業方法（Method）、そして担当した作業者（HuMan）、いわゆる4Mにドリルダウンしていく必要がある（余談だが、最後のMは、昔はManだったけれども、やはり昨今の事情を鑑み、HuManのMだということになってきている）。

そして、個別のマテリアル（ワーク）の識別IDや、作業者のIDプレートや、機械のタグNo.や、作業IDを示すSOP（標準作業手順書）のデータなどは、多くの場合、生産管理システムの埒外で、しいていえばMES（製造実行システム）の領域である。

まとめよう。QCDのうち、コストCは本社的な上流部門で決まる。納期Dは工場中二階の生産管理スタッフで決まる。品質Qは現場フロアの4Mで決まる。じゃあ、これらの間で矛盾や相克が生じた場合、誰がどう調整するのか？

答えは、組織の力関係で決まるのだ。まず本社やエリートの配属される上流部門は、お金も握って発言権が強い。工場では、現場と中二階は対等かもしれないが、納期は客先の意向の反映なので、後ろに営業部門が控えている。一般に日本の製造業では営業の方が製造よりも強い。だから、しわ寄せが来るのは現場で、その結果は品質に表れる。

おわかりだろうか。これが過去10年も20年にもわたって、日本の製造業を悩ませている品質偽装問題の正体なのである。コストは決まっている。納期も無理を言われる。だから品質をごまかすしかない。この事情は、以前書いた物語的な記事「パン屋問題の解決、または中小製造業の生き残る道」 にも描いた通りだ。

あのパン屋は、ギリギリのところで我に返って、パン屋の魂を捨てずにすんだ。それは、ちゃんとした製品を、お客さんに食べてもらう事だった。それが日本的経営の、そもそもの原点でなかったか。

米国式経営は「分析的思考」のために、QCDのトレードオフに気づけず、日本的経営は「現場頑張り主義」のためにトリレンマを解決できない。どちらも、製造業をダメにしている。誰か幻のピザ屋のポスターを再現して、経団連の会合で配ってくれないか。わたし達は根本のところで、大切なものを見失っているのである。

＜関連エントリ＞

「パン屋問題の解決、または中小製造業の生き残る道」 https://brevis.exblog.jp/28109443/ (2019-03-23)

生産管理は事務屋の仕事か

• 技術屋と事務屋

以前も書いたことだが、私がまだ駆け出しの頃ついた先輩は、文系出身のエンジニアだった。一流大学の経済学部を出て、システムエンジニアを志し、製油所の基本計画をLP（線形計画法）で最適化設計するような仕事のセクションの、リーダー格だった。わたしは一応、工学部の修士卒だったが、もちろん知識でも能力でも、その先輩にはかなわない。おまけに粗忽な性格だったから、痛い思いをしながら色々と学んだ。

世間ではよく、理系と文系と言うような対比をするが、わたしはこの区分をあまり信じていない。高等教育の人格への影響が大きい事はもちろん認めるが、そもそも専門科目を選ぶきっかけは、単に特定科目の好き嫌いや、先生との相性だったりする。持って生まれた資質から必然的に決まる人間類型だ、とは到底言えないだろう。外的環境、つまり運不運で決まる要素が大きいのだ。

理系・文系とよく似た区分で、技術屋・事務屋という言い方がある。 前者が教育の分類を示すなら、後者は職種の違いを表している。上に書いたように、わたしの 勤務先では、文系の教育を受けたエンジニアが結構いる。つまり教育と職種は一応独立と言うことだ。

もっとも、私の職場は（あるいは「エンジニアリング業界は」と言い換えてもいいかもしれないが）、他の日本企業に比べて若干例外的かもしれない。と言うのは、この業界では、エンジニアという言葉が差し示す範囲が、比較的広いのだ。

エンジニアと言うと普通は、何らかの設計に関わる業務をしている人、のイメージだろう。だがエンジニアリング業界では、設計、調達、建設、そしてプロジェクト・マネジメントが、業務の4本柱だ。 これら主要業務に携わる人たちは、皆エンジニアと言うことになっている（補助的事務職は除く）。だから、文系出身のプロマネも、文系出身の調達のバイヤーも、エンジニア職種に分類されている。この業界では、世界的に共通のことだ。

もう少しだけ補足する。我々の業界では、プロジェクト・マネージャーになる前に、「プロジェクト・エンジニア」と言う職種をキャリアパスとして通過するのが普通だ。 この職種はプロマネの下について、プロジェクト・マネジメントの様々な業務に専従する。

製造業を見ていると、基本設計部門のベテランが、大型案件のプロマネになったりするケースがある。だがエンジニアリング業界では、そういうのは例外で、普通はプロジェクト・エンジニアを何年も経験した上で、プロジェクト・マネージャーにようやく任命される。

それは、たとえて言うならば、オーケストラの指揮者と作曲家との関係のようなものだ。基本設計のリーダーは作曲家である。だが、指揮者に求められる能力・資質は相当に異なっている。作曲家が上手に指揮をできるとは限らない。癇癪持ちのベートーベンや、 気まぐれなモーツァルトは、 作曲家としては天才だったろうが、上手にオケを指揮できたかどうかは怪しい（もちろん、中にはマーラーやブーレーズのように 、両方にたけた人だっているが）。

• エンジニアであることの条件

でも、世間一般に話を戻そう。 エンジニアと言う職種は、通常、以下のような特性を持っていると考えられる。

(1) 対象とする領域の科学法則をよく理解し活用している

(2) 有用なプロダクトの設計が本務である

(3) プロダクトの質の高さが、自分の仕事のプライドの源泉である

3番目は結構大事な条件だと思う。金銭的報酬以外に、その仕事がどのような事によって評価され、当人が自尊感情を持ちうるかは、仕事を続けていく上でとても大切だからだ。 エンジニアのプライドは、主にプロダクトの質によっている。

これに対して、事務屋という職種では、どうだろう。経理も営業も人事も、ふつうは事務屋の領域に分類される。共通の特性はあるだろうか？

(1') 科学法則よりも、人々の人間関係やルール・前例などの知識が求められる

(2') 直接目に見えるプロダクトを作る仕事には携わらない

(3') そのため仕事の質が、自分にも他人にも比較評価しづらい

事務職のアウトプットはたいていの場合、何らかの伝票とか（例：売上伝票）、帳票とか（財務諸表）、リスト（採用者一覧）とか、発令書や報告書の類いである。文字と数字の集合、つまり情報であって、目に見えて手触りのあるプロダクトがない。だから、本人でも質を「比較評価しづらい」のがポイントである（だから、出世競争や社内政治に関心が向きやすい、という傾向もありそうだ）。

もっとも営業職は、（しばしば）売上の数字で比較評価されるから、(3')はあてはまりにくいように思えるかもしれない。でも、新規顧客か既存顧客か、どの製品ファミリか、国内か海外か、などの区分を考えていくと、やはり比較は簡単ではない。なので比較対象は、ほぼつねに「前例」ということになる。大事なのは（科学）法則ではなく、前例なのだ。

• 生産管理の仕事とは

さて、ようやくここからが本題である(笑)。生産管理の仕事は、技術屋の仕事なのだろうか、それとも事務屋の仕事なのだろうか？　こういう問いを立てるのは、案外多くの製造業で、生産管理部門が「事務屋」に分類されると聞いて、違和感を持ったからだ。

エンジニアリング業界では、プロジェクト・マネジメントはエンジニアの領分とされる。 もともとエンジニアリング会社の多くは、製造業の生産技術・工務部門が独立したものである。エンジ会社のプロジェクト・マネジメントは、製造業の生産マネジメントに相当する。それなのに、なぜ製造業では生産管理が事務職とされるのか。そこで、あらためて生産管理屋の仕事の中身を、検討し直してみよう。

通常、生産管理とは、本社・営業部門から降りてきた受注情報や需要、予測情報をもとに、工場の各関連部門・工程・作業区に対する指示を出し、指示に対する進捗及び実績を把握する仕事だ。 指示には、通常、品種・数量・ 着手予定日・期限 等の情報が必要とされる。

生産管理の仕事は、ある種、レストランのフロア係の役目に例えられる。直接の接客はしないが、次々に入る顧客からの注文をもとに、工場と言う名の厨房に対して、順序建ててタイミングよく指示を出す。

生産管理の仕事が上手だと、工場の中はスムーズに仕事が流れ、必要な時に材料部品が揃っており、顧客の望む納期通りに順序よくプロダクトが出ていく。生産管理が下手だと、あちこちの工程で欠品が生じて製造作業が滞り、使わない部品在庫が倉庫に溢れ返り、生産順序があべこべになって、顧客をひどく待たせたかと思うと、いりもしないものがあっという間に出来上がる。ロットサイズもバラバラで、無駄な段取り替えが多い上に、製造の効率も品質も落ちてしまう。そして働く人たちは皆、イライラしたりがっかりしたりする。

生産管理の仕事には、帳票以外の具体的なプロダクトがない。手触りのあるプロダクトは、製造部のものだ。そうすると前述の特性(2')があてはまる。そしてほんとうに事務的（＝機械的）にやるなら、単なる伝票・情報の交通整理屋ということになる。

しかしたいていは、それ以上の役目がある。それは、部門間・工程間の利害調整役である。計画通りに事が運ばなかった際に、問題解決のために、いろいろな調整をする。そこで、あちらの顔を立てたり、こちらに貸しを作ったりして、なんとか進める。これも、科学法則とはあまり縁がなさそうだ。だとしたら、やはり事務屋の仕事ではないか？

• 仮説検証とテクノロジー

でも、単純にそうは言えないと思っているから、この記事を書いているのである。なぜか。

生産マネジメントの仕事は本来、計画立案・実行コントロール・評価改善の三本柱から成り立っている。

まずは、適切かつ正確で、実行可能な生産スケジュールを立案し、指示手配をかける。これが1本目の柱だ。生産計画業務とも呼ぶ。

次に現実の進捗状況をモニタリングし、計画からの乖離その他の問題が生じたとき（特にその問題が複数の職場間での調整と協力を必要とするとき）、問題解決をリードする。これが2本目だ。生産統制業務という言い方もある。

そして計画立案時に立てた仮説を、現実の結果で評価検証し、次の計画立案に活用する。これが3本目の柱だ。だが、実を言うと、これが大事な柱になっている企業は、わたしの経験では、それほど多くない。

なぜか。それは、そもそも「計画の背後に仮説がある」「仮説を立てて計画を立案する」という意識が希薄だからだ。たとえば、これからは需要増の時期を迎える。だから極力、納期優先で順序計画を立てよう、熟練者を配置しようとか、逆にこれからは稼働率が下がってくる、だからコスト優先で段取り替えを最小化しよう、教育のために未経験者を配置しよう、といった采配が、仮説ベースの計画なのである。

ところが多くの組織では、この仮説検証の働きが弱い。仮説を立てて検証するトレーニングが、学校教育でも企業内研修でも、ろくに行われていない。事実と意見の区別がなされず、状況判断と感情的反応がごっちゃになったまま、物事に対処する。事実を客観的・正確に把握する前に、問題解決に飛びつこうとする。このような傾向は、理系の教育を受けたエンジニアにも、文系の教育を受けた事務職にも共通する問題点だ。わたし達の社会の、共通問題だといってもいい。

仮説検証のアプローチは、じつは科学の基礎である。科学教育は（それがちゃんとしたものであれば）仮説を立て、予測し、検証するサイクルを身につけさせる。そして仮説がある確度で検証できれば、それは方法論に昇格する。方法論になれば、組織としての継承も、他部門や他国への移転も、可能になる。つまり、テクノロジーに近づいていくのだ。

マネジメントにテクノロジーがあるとはどういう意味か。それは方法論が数字と法則性に基づき、属人的ではなく移転可能になっていることを示す。これを希求するのが、本来の技術屋の職分であろう。もちろん、利害調整など人間系のソフト・スキルを要する仕事も、必ず残る。その重要性は、なくなりはしない。

そういう意味でマネジメントとは、技術屋と事務屋の両面を兼ね備えた、独立の職務領域なのである。（ここであえて率直に書くが）、今の多くのエンジニアには、真の意味での仮説検証のマインドセットが不足していると、わたしは感じる。自分の狭い専門領域を一歩でも外れると、急に「居酒屋のおっさん談義」みたいな論調になったりする。

マネジメントは理系だから適職、文系だから適職、という仕事ではない。科学とハートと、両方を持ち得た人でなければ上手に回せない職能なのである。

＜関連エントリ＞

「わたしが新入社員の時に学んだこと​​」 https://brevis.exblog.jp/12569297/ (2010-05-01)

「仮説検証のトレーニング」 https://brevis.exblog.jp/11562183/ (2009-11-11)

BOMのデータ構造（の入り口を、ちょっと）考える

• BOMデータベースの基本構造

「ウチの会社にはBOMがないんです」「そろそろ、BOMを作らなきゃと考えていまして」といった台詞を、ときどき製造業の方から、お聞きすることがある。きっと何か、誤解があるんだろうなあ。聞くたびに、そう思う。

BOMはBill of Materialの略で、材料表ないし部品表のことである。材料表がなかったら、製造業は外から部品材料を買ってくることができない。何も仕入れずに、モノを製造することはできない。だから、どんな製造業でも、必ずBOMは持っているはずなのである。

ただ、上記のような言い方をする人たちは、おそらく「ウチの会社にはBOMデータベースがないんです」「そろそろ、BOMソフトウェアを作らなきゃと考えていまして」と考えておられるんだと想像する。今は、手書きのFAXやExcelシートで仕事を回している。しかしそろそろ、もう少し近代的なITのやり方に切り替えたい、と。

そこで意思疎通の誤解を避けるため、わたしはBOMに関する用語を、次のように区別することを、かねてから提案している。すなわち、BOMのデータ、データベース、ソフトウェアの区別である。

1.「BOMデータ」：　表になっている状態。Excelや手書きも含む

2.「BOMデータベース」：　コンピュータに形式化されている状態

3.「BOMソフトウェア」：　BOMデータベースを処理するITシステム。BOMプロセッサと呼ぶこともある

『データ』とは、元々、「定型化された記号の並び」を指す。だからここでは、Excelや手書きも、意識して定型化されている限りは、データに分類している。でもまあ、普通はコンピュータの中にデータベース化しないと、効率的な処理はしにくい。

では、それはどのようなデータ構造になるのだろうか。ちょっと考えてみよう、というのが今回のテーマだ（いつものことだが、イントロが長いな・・）

ちなみに、わたしは拙著『 BOM/部品表入門』を書いた際に、DBの論理スキーマを示すことは、あえて避けた。BOMの世界はバリエーションが複雑で、企業によって必要とする深さも異なるため、妙に一般論を示しても役に立たないからである。でもまあ、ここではその入り口、もっとも基本的なところだけを、少し考えてみたい（ITが専門でない方にも役に立つ程度に、書くつもりである）。

なお、BOMにはマスタデータとトランザクションデータの2種類があり、ふつうは両方が必要だが、ここではマスタの方を考える（なぜトランザクションBOMデータが必須かの理由は、拙著P.23「Q: BOMは何種類お持ちですか」などを参照されたい）

さらにBOMとしては最も一般的な、「A型」BOMを考える。A型BOMというのは、複数原材料（醤油・酢・ゴマ油・砂糖）を集めて中間材料（タレ）を作り、さらに中間材料や部品（麺・錦糸玉子・キュウリ・チャーシュー）を組み合わせて、最終製品（冷やし中華）ができあがる、というような食品系、あるいは組立系の機械・電機などに多いトポロジー類型である。（いいかえると化学反応のような、複数原料から複数生成物ができる「X型」BOMや、製鉄・ガラスのような、製品が原材料にリサイクルされる「Q型」は対象外とする）

• BOMデータの基本構造

そして、BOMデータベースは普通のリレーショナル型DBを用いるとしよう。いや、俺はnon-SQLの方が好きだとか、最近流行りのGraph DBの方が樹形構造は表現しやすいぞ、とか考える向きには、ご自由に設計をお任せしたい。ここでは、業務系システムでの利用を考えて、ありきたりのRDBを想定しておく。

BOMデータの一番基本的な構造は、親子関係の1対による表現である。つまり、

「親部品Aを作るには、子部品aがN個必要である」

という関係を表現するデータ構造が基本だ。すなわち、BOMデータベースの基本は、シングルレベル表現である。親の品目コードと、子の品目コードと、その間の数量関係（「員数」と呼ぶ習慣になっている）の、3データ項目が最低限、記述できなければならない。

そして、品目コードとその属性が並ぶ「マテリアル・マスタ」（品目マスタ・部品マスタと呼ぶ場合もある）の存在が、まず前提になる。その上で、一種のサブ・テーブルとして、BOMを考える訳である。そうなると、2種類の考え方が可能だ。

一つめは、親の品目コードと、行番号ないし単純な連番を、複合キーにとったサブ・テーブルを作る方法だろう。つまり、

親品目A - 1番目：子部品a、員数N個、他の属性…

親品目A - 2番目：子部品b、員数M個、他の属性…

親品目A - 3番目：子部品c、員数L個、他の属性…

　・・・といった感じのデータが並ぶことになる（下線のついている項目がキー値で、これらはテーブル内でユニークでなければならない）。もちろん員数の後ろには、さらに他のデータ項目が並ぶ。これを、かりに『行番号方式』とよぶことにする。

こういうデータ構造は、機械組立図をベースに、BOMを登録したりするときに便利である。組立図には各部品に、いわゆる「風船」（引き出し線と丸数字）が記入されていて、そのリスト（番号と部品名と員数）が、図面の横の方についている。この表の構造に類似しているからだ。

もう一つの考え方は、親子の品目コードを複合キーとする方法だ。この場合、

親品目A - 子部品a：員数N個、他の属性…

親品目A - 子部品b：員数M個、他の属性…

親品目A - 子部品c：員数L個、他の属性…

　・・・といったデータになる。この場合、別に組立図とか風船は、なくてもいい。「冷やし中華のBOM」を作る場合、わざわざ組立図は作らないだろう。そういう製品分野だって、たくさんある。こちらは『ペア方式』とよんでおこうか。

• 二つの方式を比較する（そして、BOMデータは生き物である）

さて、設計に複数の選択肢がある際は、そのプラス・マイナスを考えるというのが、よい習慣であろう。

『行番号方式』の設計の良い点は、何だろうか。たとえば、行番号（連番）がついていいるので、入力した順が分かりやすい事かもしれない。また、表示順をユーザが制御しやすい面もある。『ペア方式』の設計では、別途「表示順」のようなデータ項目を用意して、ユーザが入力編集できるようにしてやらないといけなくなり、ちょっとだけ手間ではある。

その代わり、『行番号方式』が単純な連番だと、あとから順序の途中の所に追加で行を挿入する、といったことができなくなる。それはとくに、親に対する子部品の数が多くなった場合に、やっかいだろう。

・・でも、そうしたことはマイナーだ。むしろ比較検討上で考慮すべきは、BOMデータの変更である。BOMは生き物であって、設計変更と共に、いろいろと変わっていく可能性がある。子部品aが、子部品zに入れ替わったとき、どうするか。

『行番号方式』だと、1行目の子部品の品目コードを、aからzに直接、更新することになる。それでもいいが、そうするとその時点でマスタの内容が変わってしまう。だから、「翌月から変更」といった計画的変更のためには、何かバッチ処理を別に組まなければならない。

『ペア方式』ならば、親品目A - 子部品a と、親品目A - 子部品z という2レコードの一時的な共存が可能になる。だから「有効期限」のような属性項目を作っておいて、月末になると条件判断で自動的に切り替わる処理が、可能になる。

だが、あるいは子部品aが、a1とa2の二つの部品に変わったら、どうか。そして二つの部品が一体化して、一つの部品になったら。一つ言えるのは、こうした設計変更が頻繁に起きる場合、「どこの部位の部品が、いつ、どう変わったのか？」が分かりやすいようにすべきだ、ということであろう（変更がめったに起きないなら、そんな心配は無用だが）

従って変更が多いケースでは、『行番号方式』で行く場合でも、単純な連番はさけた方が良さそうだと分かる。10番刻みにして、途中に追加可能にする、などの工夫がいるだろう。もう少し言うと、この「行番号」というのは、実は親部品の中に子部品が占める「部位」「機能要素」のIDなのである（これを設備系BOMではFunctional locationないしOperational locationなどと呼ぶ）。

• 属性データの種類

ついでに少し、その他の属性データ項目についても考えておこう。

まず員数には、セットで「UOM」（Unit of Measure＝係数単位）がいる。つまり、個数とかccとかgといった単位である。わたしの生きているエンジニアリング業界にはしばしば、ポンド・ヤード系とか、石油の「バーレル」とか、言語道断な単位系が登場する。だから場合によっては、相互変換の計算機能も必要になるかもしれない。

BOMにおいて親子関係をつなぐのは、製造プロセスを表す「工程」（または複数作業からなる「工順」）のIDである。このIDは、同一の親部品にぶら下がる子部品では、すべて共通になるよう、注意を要する。そして、MRPで使用するBOMならばさらに、工程のロットサイズと標準リードタイムの項目が必要である。

さらに、改廃に関する項目がある。上でも述べたように、BOMには変更がつきものだ。変更履歴を過去に渡って、ずっと追いかけられるようにしたいとしたら、改訂番号、改廃年月日などが必要になる。その場合、行番号方式であろうがペア方式であろうが、改訂番号は複合キーの一部になっていなければならない。

いずれにせよ、BOMデータベースのシングルレベル表現では、親部品と子部品の品目コードを、マテリアル・マスタの外部キーとして参照する構造になる。だから、BOMデータベースにはマテリアル・マスタが必須、ということになる。実はここが重要なポイントで、BOMデータとは、マテリアル・マスタという土台の上に乗っかる建物なのである。

ともあれ、こう見てくるとシンプルな例でも、BOMデータベースのスキーマは案外、単純ではない、ということだ。そして現実に応用するには、それなりのバリエーションにも対応できるようにしなければならない。

例えば、「代替部品」はどう表現するか、考えてみられたい。代替部品とは、本体の製品自体にはあまり影響しないが、複数の部品の選択肢が可能なケースである。冷し中華に乗せる細切りチャーシューは、三枚肉の場合も、肩ロース肉の場合もあるだろう。これが代替部品だ。普通の顧客は、どちらを乗せてもとくに文句は言うまい。だが作る側からすると、製作時間も原価も違うのだ。

・・でも読者の中には、「寒くなってきたから冷し中華の話は、もういいや」とお考えの方もおられるかもしれない。うむ、わたしもそろそろ、そう思っていたところだ。

＜関連エントリ＞

「BOMのレベルとは何か」 https://brevis.exblog.jp/33251771/ (2024/10/18)

お知らせ：PM学会シンポジウムで「MES標準業務テンプレート」について講演します（11月7日・名古屋）

お知らせです。来る11月7日（木）午後3時から、名古屋工業大学で開催される『プロジェクトマネジメント学会 2024年度中部支部シンポジウム』で、「MES標準業務テンプレート」について講演します。参加費は1,000円（学生およびPM学会員は無料）です。ダッソー・システムズの廣谷満氏との共同講演です。

この標準テンプレートは、（すでに何回か書いていますが）わたしが幹事を務める（財）エンジニアリング協会「次世代スマート工場のエンジニアリング」研究会が、昨年秋から共同で開発し、今年6月にパブリックコメント版として公開したものです。

工場で使う製造実行システムMESは、わたし達の研究会の調査では、すでに普及率が3割近くに達しており、さらに利用が広まると期待されています。「スマート・ファクトリーとはMESを活用する工場である」というのが我々の考え方ですから、この国でもようやく製造現場のスマート化の流れが出てきたと感じています。

（なお国際標準である ISA-95 = IEC62264の階層定義では、Level 2の制御システムとLevel 4の業務系システムの間を、製造オペレーション・マネジメントManufacturing Operation Management = MOMシステムと呼ぶことになっています。すなわち広義のMOMの中に、製造実行のための狭義のMESが含まれる事になるのです。ただ、世間では厳密に両者を使い分けている訳ではないので、我々はMES/MOMと、ひとくくりにしています）

今回の講演では、最初にわたしが、製造業における生産改革プロジェクトでありがちな課題について触れます。それは、縦割り意識の強いサイロ化した組織における、機能横断的な取組みが直面しがちな問題点です。ついで、我々の研究会が「標準業務テンプレート」開発という、一種ボランタリーなプロジェクトをどう進めたかを、お話しします。PM学会のシンポジウムですから、PM的な側面に触れる訳です。

ついで、共同講演者の廣谷満氏が、標準テンプレートの具体的な内容と使い方について、レクチャーされます。廣谷氏は半導体製造におけるMESを振り出しに、長年MES/MOMの実務に携わってこられた方です。

MES/MOMは業界や生産方式ごとに、個別性の強いシステムですから、IT機能の側から見ると、かなりバラエティーの大きな説明になってしまいます。しかし、ユーザの業務の視点から見ると、ディスクリート型工場では、製品が機械であろうと食品であろうと、比較的共通しています。どちらにも製造部門があり生産管理部門があり、品質管理業務や在庫管理業務がある、といった具合です。

我々の標準テンプレートは、このような日本の工場に共通する「As-Isの業務カタログ」というべき表形式になっています。そして、これを見ながら、ユーザは自社のニーズに合った形でカスタマイズして、MES/MOMの要件定義やRFP作成に活用することを想定しています。

本テンプレートについては、10月22日の「第4回スマート工場シンポジウム」（東京・大森）でワークショップを開催したばかりですが、日本の製造業のメッカである名古屋でも、発表できるチャンスをいただきました。短時間の講演ではありますが、ご関心のある大勢の方のご来聴をお待ちしております。

＜記＞

「プロジェクトマネジメント学会 2024年度中部支部シンポジウム」

～　技術革新とプロジェクトマネジメントの未来への挑戦　～

日時：2024年11月7日　15:00-17:55

会場：国立大学法人 名古屋工業大学 NITech Hall

　　　　〒466-8555 名古屋市昭和区御器所町

　※名古屋工業大学へのアクセス

　　　https://www.nitech.ac.jp/access/index.html

　※NITech Hall の場所：正門から入ってすぐ右側（下記地図の右下）

　　　https://www.nitech.ac.jp/access/campusmap.html

講演 1 （15:10～15:55）

工場スマート化プロジェクトのボトルネックを解決する『標準業務テンプレートの開発』

～　日本の製造業の現実に合った MES/MOM システム構築のために

講師：日揮ホールディングス（株） 佐藤 知一、ダッソーシステムズ（株） 廣谷 満

申込方法：下記サイトからお申し込み下さい。

　　　https://www.spm.or.jp/event/chubu_symp2024/

申込期限：11月4日(月)

参加費：　1,000円（学生およびPM学会員は無料）

以上、よろしくお願いいたします。

佐藤知一＠日揮ホールディングス（株）

＜関連エントリ＞

「スマート・ファクトリーとはMESを活用する工場である」 https://brevis.exblog.jp/30503581/ (2023-12-02)