結婚したての頃、ワンルームのアパートにすんでいた。部屋は12畳が一つ。ユニットバスと洗面台、玄関スペースを入れても15畳だ。遊びに来たアメリカの友人が、部屋を見て唖然とした表情をしたのをよく覚えている。彼らのスタンダードからは、ウサギ小屋どころかネズミ小屋に見えただろう。 わたし達はそのワンルームを、タンスなどの家具でパーティション的に仕切って、二つの部屋みたいに使っていた。ダイニングキッチンと、勉強部屋兼寝室である。二人とも仕事を持っていたので、互いに別のスペースがいるときもあるし、多少のプライバシーだって必要だ。その後、2回ほど引越しし、子どもが生まれて部屋数も増えたが、子どもが巣立つと不要な部屋は物置みたいになってくる。家族の増大や成長と共に、必要な部屋数は変わるのだった。 何の話をしているかというと、実はBOMの数についてである。2005年に発刊した「BOM/部品表入門」で、わたしは次のように書いた。
BOMのマスタの数をいくつ持てばいいか、正解はない。数が増えれば運用上の利便性は高くなるが、整合性を保つコストは幾何級数的に増える。だから自社のニーズにあった数を考えるべきで、それでも迷うなら、少なめの数から出発することをおすすめする、と書いた。この考えは、基本的に今でも変わらない。
中小零細の企業は別としても、中堅以上の製造業は普通、BOMデータを持っている。BOMは製造業の生産系における要（かなめ）で、多くのITシステムがBOMデータを必要とする。だからそれがなければ、業務が回らない。ただ、やっかいなのは、BOMデータが同じ会社に、2つも3つもあることだ。 なぜ一つの企業にBOMが複数あるのか？ 答えは、「それが（ローカルに）便利だから」である。ローカルに、とは、業務の大まかなくくりや部門単位で、という意味だ。ワンルームだと赤ちゃんが寝ているときにテレビが見られない。だから子ども部屋とリビングを区切ろう、という発想になる。設計部門が製品のBOMの中身をいじっているときにも、購買部門は主要な部品の発注数量を決めておきたい。だから別々に維持しよう・・といった事情だ。 ただし、部品表が複数存在するのは、これ以外にも理由がある。その一番大きなものは、カバー範囲の違いである。多くの企業では、設計部品表（Engineering BOM = E-BOM）と、製造部品表（Manufacturing BOM = M-BOM）を別々に持っている。この両者は、カバー範囲が違うのだ。 機械や電機などの組立加工業では、設計部門は最終製品の組立図や、それを構成するサブ・アッセンブリー組立図、そして個別の機械部品などの図面・仕様書を作る。それらの表現がE-BOMだ。だが部品を素材からどう加工製造するかは、生産技術部問の仕事になる。製造工程を設計するためには、部品加工の段階も必要だ。M-BOMは、この部分もカバーする。 （なお、これは組立加工業の話で、食品・化学・医薬品などは元々、原材料から出発して作り方を考えるから、このような分離はあまり聞かない） またM-BOMでは、製造工程で消費する薬剤などの副資材や、製品の表面を保護する一次包装材なども登録する。それらが無いと、製造の仕事ができないし、原価の一部でもあるからだ。だから一般に、E-BOM < M-BOM というカバー範囲になる。
でも、それだけなら、素材や副資材や包材も、E-BOMに追加登録すれば良いはずである。だからわたしは、最初は一つのBOMから出発を、とすすめているのだ。だが、もう少し別の要因もある。それは「検討用」と「実行用」の区別である。 製品によっては、基本モデルにさまざまなオプションがつくケースがある。身近な例では乗用車とかパソコンを思えばいい。ユーザは、チャイルドシートだとかエアバッグだとかカーナビなど、選択肢の組合せの中から選ぶことができる。設計段階では、これら個別仕様に応じた部品構成を用意しておく。つまり、一つの製品を作るのに必要な部品だけでなく、可能性のある部品をすべて列挙し検討する必要がある。 近年はこのような可能性を検討したBOMを、「150% BOM」と呼ぶことが広まっている。100%以上、という訳だ。 ところが、生産管理や購買で使うBOMは、これではこまる。一つの受注オーダーで作る製品に、150%分の部品を用意するわけにはいかない。製造ではいわば「100% BOM」が個別に必要なのだ。これが、E-BOMとM-BOMが同居できない、もう一つの重要な理由である。 
検討業務における「可能性」「べき論」の列挙と、実行業務における「現実」「これでいく」への限定。この両者が、業務では必要だ。検討段階では、異なる部品構成のケースを設定して比較したり、架空のシミュレーションも行いたい。しかし実行段階では、架空の話は不要だし、動いているシステムで勝手にそんなデータ変更をされたら迷惑だ。ある程度以上の規模の企業で、E-BOMとM-BOMが分離していくのは、そうした背景があるからだ。 さらに言うと、「べき論」と「これでいく」の区別は、前者をマスタ・データで規定し、後者をトランザクション・データに記録することで実現するのが望ましい。オブジェクト指向風の言い方でいえば、前者がクラス、後者がインスタンスということだ。これについては、すでに以前、「BOMデータのマスタと履歴を区別する」 で解説したのでここでは繰り返さない。 ただ、このように複数の目的別BOMを作っていくと、その間の整合性の確保が課題になっていく。すなわち、本当のBOMマスタはどこにあるのか（どれが派生したコピーなのか）、そして事実を一元的に記録したBOMトランザクション履歴はどこにあるのか、という問いである。 このような整合性確保は、当然ながら簡単ではない。ただ、はっきりしている事が一つある。それは、「BOMは複数あっても良いが、マテリアル・マスタは一つだけを共通に参照する」ことだ。（なお、マテリアル・マスタは「部品マスタ」「品目マスタ」などと呼ばれることもある） ここがブレて、本社と工場が、あるいは営業と製造が、そして日本と海外子会社が、同じものを別のコードで呼んだりする状況は、断固として避けなければならない。個別の部署はそれで良いかもしれない。しかし、部門横断的なエンジニアリングチェーンもサプライチェーンも、もちろんアフターサービスも、実務が大変苦労するからだ。 ただ、そうしたBOMデータ不整合で生じる苦労は、実務レベルの人々が背負うものの、経営層はどこ吹く風で気づかなかったりする。そして時々、叫ぶのだろう。「なんでウチの現場は、生産性が低いんだ！ なんで何か聞いても、すぐ数字が出てこないんだ！」・・・ 問題のあるところには、原因がある。経営の横断的機能が働かず、部門最適がはびこりすぎると、いつの間にか会社はタコツボ的データの集合体になる。12畳のワンルームを10個の小部屋に区切ったら、使い物にならないに決まっている。『データドリブン経営』をしたかったら、データ価値を理解する経営が、まず必要なのだ。 ＜関連エントリ＞ 「BOMデータのマスタと履歴を区別する」 https://brevis.exblog.jp/28544961/ (2019-08-28) 「BOMのレベルとは何か」 https://brevis.exblog.jp/33251771/ (2024-10-18) #
by Tomoichi_Sato
| 2025-04-11 11:22
| サプライチェーン
|
Comments(0)
「クリティカル・パスなんて、実際は役に立ちませんから。」ある生産スケジューリングの専門家は、にこやかにそう断言した。この方は元々IT業界の出身で、その後は生産マネジメントやIoT・スマート製造の分野で活躍している人だ。ふうん、この人でさえ、そう思ってるのか。うすうす感じていたことだが、改めて世の認識を再確認した気持ちになった。 クリティカル・パスとは何か。今さら言うまでもないが、クリティカル・パスはプロジェクト・スケジュールにおける基本的概念で、プロジェクト全体の期間を決定する指標である。プロジェクトをアクティビティ・ネットワークで表現した際に、開始点から完了点までを結ぶ経路の内、最長のものをクリティカル・パスと呼ぶ。プロジェクトの全期間の長さは、クリティカル・パスに等しくなる。 もしもプロジェクトの納期を短くしたければ、クリティカル・パスを短縮する必要がある。クリティカル・パスに乗っていない他のアクティビティは、フロート＝余裕日数を持っており、そこを短縮しても全体は短くならないからだ。 逆に、クリティカル・パス上のアクティビティが、どれか一つでも1日遅れたら、他のアクティビティをどんなに急いで短縮しても、プロジェクト全体は納期に1日遅れてしまう。だからプロジェクト・マネージャーは、どのアクティビティ（の系列）がクリティカル・パスになっているかをきちんと把握して、その進捗をモニターする必要がある。 この点が、じつはコストとスケジュールの世界の、最大の違いなのだ。コストの世界は、全部足し算だ。だから、プロジェクトを構成するアクティビティのどれか1つでも、1円でも削減できれば、プロジェクト全体が1円儲かる。ところがスケジュールは、そうではない。担当者が頑張って1日短縮しても、プロジェクト全体ではちっとも得をしない場合がある。どこが大事で、どこはそうでないか、くっきり二つに分かれるのがスケジュールの世界なのだ。
ちなみに、本エントリは「モダンPMへの誘い」というタイトルのシリーズだ。『モダンPM』とは何か。それは、現代的なプロジェクト・マネジメントの体系を示す用語である。プロジェクトという営為それ自体は、ピラミッドや万里の長城を作った古代から存在し、人間の歴史と同じくらい古い。それだけ、人間はプロジェクトをとりまとめるのに苦労してきた訳だ。 ただ、現代的なプロジェクト・マネジメントの考え方は、1950年代に米国で生まれた。最初にこれを考えたのは、化学企業デュポン社の技術者達であった。化学プラント建設プロジェクトの期間が長引くことに手を焼いていた彼らは、プロジェクト全体の長さを何とか正確に予測できないかと考えた。そして、プロジェクトを、それを構成する単位的な作業（アクティビティ）の連鎖で表現することを思いついた。 プロジェクトをアクティビティのネットワークで表した際に、具体的にどうやってクリティカル・パスを同定し、その長さを計算するのか。それについては、すでに何度か記事に書いている。たとえば「納期が延びる要因を指標化する － スケジュールのDRAGとはどんな尺度か」 などを参照されたい。 ともあれ、これは本当に画期的なことだった。それ以前の人類は皆、プロジェクトという営為を、大きな丸ごと全体として捉え、それをなとかマネージしようとしてきた訳だ。「困難な問題は分割せよ」はデカルトの格言という話だが、デュポンの技術者達は、プロジェクトを要素的なアクティビティから構成されるネットワークと捉え直した。 そしてその個別のアクティビティの性質（期間とか費用とか）から、全体プロジェクトの性質を導出できる、と思いついたのだ。まことにプロジェクト・マネジメントにとって、真のイノベーションの瞬間だったと言って良い。それくらい、クリティカル・パス法の誕生は画期的なのである。
だったらなぜ、「クリティカル・パス法は実際には使えない」などという、冒頭のような発言が出てくるのか。そして、それが大勢の人の暗黙の共感を呼ぶのか。 もっとも、より正確には、最初に引用した発言はたしか、「PERTなんて、実際は役に立ちませんから」というものだったと記憶する。PERTという用語で、クリティカル・パス法のことを指す——これはやや日本独特の用法だ。英語圏では、Critical Path Method、略してCPMと呼ぶのが普通だ。 ではPERTとは何か。これはProject Evaluation and Review Techniqueの略で、上記デュポン社のCPMとほぼ同時期にあたる50年代に、海軍でポラリスミサイル開発プロジェクトを手伝っていたコンサルティング企業・Booz Allen Hamilton社の人たちが開発した手法だ。 PERTもプロジェクトをアクティビティのネットワークと考える点では、CPMと共通である。ただしPERTの目的は、どちらかというとコスト予測にある。そして各アクティビティのコスト見積に3点見積法を導入し、プロジェクト全体のコストの振れ幅を推算する。 後にこの手法はCPM法と合体し、一緒にして『PERT/CPM』と呼ばれるようになった。ただ日本では、この手法の初期の紹介においてPERTと略することが多かったらしく、この呼び名がもっぱら通用するようになったらしい。
そうした脇道はさておき、なぜPERT/CPMなんて役に立たない、と思われるのか。クリティカル・パス自体は、数学的に証明された、明確なものだ。だからCPMが成り立たないというのは、「1＋1が2にならない」と言うようなものではないか？ とくにそれが、論理的であるはずのIT業界・ソフトウェア開発の分野から、なぜ発せられがちなのか？（ちなみに海外のプラント系プロジェクトでは、そういった発言は聞いたことがない） 答えは、三つほど考えられる。 まず、(1)プロジェクト全てがクリティカル・パスである、という状態。これはどんなときに起きるかというと、プロジェクトが一本線のアクティビティ系列から成り立っていて、並列作業が存在しない場合だ。図を見てほしい。このような一本線のプロジェクトでは、全てがクリティカル・パスになってしまうから、あえてCMPなどを持ち出す意味がない。  二番目は、(2)各アクティビティの期間に幅やブレがあり、その見積に信頼性がない場合。1+1=2といっても、その「1」が0.5かもしれず2かもしれないのでは、足し算などして、どういう意味があるのか、という事になる。 三番目は、(3)そもそもプロジェクトがもやもや・混沌としていて、それを単位作業としてのアクティビティに分解・落とし込みが難しい場合。要素さえ決まっていないのに､要素間の関係とか足し算とか出来る訳がない。 これらはそれぞれ、もっともな理由ではある。ただPERT/CPMを持ち出し､クリティカル・パスを同定するのは、そもそも何のためにやるのか。それは、「プロジェクトの着地点予測」のためなのである。プロジェクトとは､ゴールを目指した活動､終わるために頑張る仕事だ。そのゴール地点まで､あとどれくらいあるのか。いつ、到着できるのか。それを知ることは、プロジェクトの中で頑張っている人には、とても大事だ。 だとしたら、上記(1)～(3)が当てはまるケースでも、どう着地点を予測すべきかという問題になる。それを、次回考えてみよう。 ただし、(1)～(3)以外に､もっと共通した深層の問題､すなわち、(0)計画なんてそもそも嫌いだ､という共通感情が、多くの人々の心の底にあるように想える。こちらの解決は簡単ではない（だって意識化されておらず､しかも理屈ではなく感情の問題だから）。でも、それも避けて通れないのなら､どういう態度で臨むのがベターかについても、追々触れていきたいと思う。 ＜関連エントリ＞ 「納期が延びる要因を指標化する － スケジュールのDRAGとはどんな尺度か」 https://brevis.exblog.jp/20000432/ (2013-03-25) #
by Tomoichi_Sato
| 2025-04-02 20:19
| プロジェクト・マネジメント
|
Comments(0)
会議は､あっけなく終わった。「質問は？」議長がたずねたが、誰も声を上げない。それが最後の議題だったので散会となった。参加者は皆、三々五々部屋を出て行く。報告者のプロマネも、しばらくじっと黙ってうつむいていたが、自分のノートPCをたたんで静かに出て行った。ただ、わたしは呆然とした気持ちのまま､席を立つ気がしなかった。 この種類のプロジェクトが、この段階でこの状態にあるとは、まともじゃない。基本構想の仕事ならいざ知らず､すでに投資決定も下り､力仕事の段階に入っている。報告内容から見て､明らかに人も､予算も足りていない。当然､納期にも間に合うまい。ただ、プロマネ自身は､そうは言わなかった。顧客起因の重大な変更があって、進捗も遅れ気味だが､「何とか頑張ります」と言ったのだ。 会議の出席者の中には、経営層の人もいた。他のメンバーだって、昨日今日仕事を始めた人たちではあるまい。だったらなぜ、発言しないのか。「今すぐ､このプロジェクトを助けなけりゃダメだ。このまま放っておいたら大変なことになる」と。だが、誰もそうは言わなかった。実際に会議で決まったのは､問題プロジェクトなので、さらに定期報告やレビューの義務を課すことだった。 わたし自身は違う会社の人間で､たまたまオブザーバーとして後ろの席に座っていただけだから､当然、発言権はない。だが当事者の一員だったら､こう主張したくなったろう。「プロマネ一人の責任に任せて、レビューだゲートだ報告だ、などと言っている場合じゃないですよ」と。逆に自分がプロマネの立場だったら､どうするか。「こんな状態で一体、何をどうしろと言うんです!?」とでも叫ぶだろうか。
モダンPMの参考書や標準書を読むと､プロジェクトは複数のアクティビティから構成され（業界によっては「タスク」とも呼ぶ）、さらにプロジェクトの上位概念としてプログラムがある､と書いてある。つまりプログラム、プロジェクト､アクティビティ（タスク）の三階層がある、という訳だ。 また、かりにプロジェクトが単独で行われ､上位にプログラムがない場合にも､プロマネの上位に『プロジェクト・オーナー』という立場が存在する､と書いてある（これも業界によってはプロジェクト・スポンサーと呼んだりもするが）。このオーナー/スポンサーの役割とはすなわち、プロジェクトを公式化し､予算枠を与え､プロマネを任命することだ。これが、連関する複数のプロジェクトを束ねるプログラムの場合だと､その仕事はプログラム・マネージャーが行うことになる。 とはいえ受注型プロジェクトは、単独で行われることがほとんどだ（複数の連関するプロジェクトを気前よくバサッと渡して、全体を任せてくれる顧客なんていやしない）。だとしたら、受注したプロジェクトの数だけ、オーナーもいるはずだ。そしてオーナーは、フルタイムでプロジェクトを面倒見ている訳ではないが、それでも遂行状態を時折ウォッチして、問題が起きたらプロマネを助ける存在である、はずである（それが任命責任というものだ）。 だが現実には､そんな上等なプロジェクト・オーナーなんかいない。プログラム・マネージャーなんか、もっと不在だ。そもそも『プログラム・マネジメント』なんて概念､社内で知る人もいないし勉強する人もいない。勉強する場所もない。――それが受注ビジネスで食べている、大方の組織の現状ではないか？
そういう会社にも､PMO(Proejct Management Office)と呼ばれる組織はあったりする。PMOは何をする部門か？ 一つの重要な役割は､プロジェクト・マネジメントに関する標準プロセスや仕組みを作り上げることだ。もう一つは､個別のプロジェクトで、「マネジメントを支援する」ことになっている。 支援というのは､しかし、微妙な概念だ。支援した人は､結果についても責任を持つのか？ そうではあるまい。プロジェクトの最終責任は､やはりプロマネが負うことになっている（ところが多い）。PMOが横から手を出しても、何か重要なことを決断するのは､プロマネである。そうでなければ、今度はプロマネの側がやってられなくなる。自分とは違う考えの人が､横から勝手に判断を下したら、誰が結果に責任を持つのか？ つまり、マネジメントという仕事の一番大切な部分は､「決断を下す」ことにあるのだ。状況は流動的､先行きは不確実、技術にもリスクがある。だが、何かを決めなければならない。決めるために、マネージャーがいる。いったん決めたら､それが良い結果を生むよう、周囲を動かしていかなければならない。「先を読む」「決断する」「人を動かす」――それがマネージャーの仕事だ。 もちろん、「進捗や品質やコストの状況を、正確に把握する」「報告する」も、マネジメントの仕事ではある（PMOは主にこちらを助ける）。それをしなくていい､とは言わない。だが状況把握は、より良い決断のために必要なのだし､報告はそれによって会社（チームの上位の組織）が助けてくれるからこそ、意味があるのだ。報告それ自体が目的なのではない。 実をいうと、わたし自身､PMO的な仕事を何年間もやっていた。だから、その難しさを少しは知っている。PMOはプロマネの部下ではない。その指揮命令の下で、手足として動く訳ではない。しかし、プロマネの上位にいる訳でもない。上位にいるのは（一応）オーナーだ。PMOにはプロマネへの指揮命令権限もない。 じゃあ何かというと､いわばスポーツのスコアラーなのだ。フィールドで観察し､記録する。そのデータ蓄積はとても重要だ。決断の参考にもなる。ただ、日本語ではモニタリングし記録する仕事も、『管理』と呼ぶ。わたしがプロジェクト・マネジメントを「プロジェクト管理」と呼ばないのは､この点を区別したいためだ。主体的に決断し､最後まで覚悟を決めて実行すること。それが責任あるマネジメントの姿で、上から目線の「管理」とはほど遠い。
日本のサラリーマン組織の中核問題（の一つ）は、上位マネジメントの機能不全を､現場リーダーが無理にカバーしている点にある。そう、わたしは考えている。 プロジェクトとは、スコープ・コスト・スケジュールの3つの制約条件に取り囲まれ､トリレンマの状態にある。これは製造業における生産マネジメントが､QCDのトリレンマ状態にあることとよく似ている。 トリレンマだから、どれか一つを変えようとすると､必ず他の二辺に影響が及ぶ。したがって、プロジェクト・マネージャーは、スコープ・コスト・スケジュールの3つについて、適切な手を打てるような権限が必要である。そもそもマネジメントの仕事とは､経営資源の適切な配分によって、組織のアウトカムの価値を最大化することである。もっと具体的に言えば、人員を動かし､必要ならば外部組織を動かすための金を使い、技術や設備など有形無形の資産を動員して、トリレンマを緩和することにある。 それなのに、少なからぬ組織では（とくにIT業界のSIer等では）､プロマネに予算の執行や発注の権限を、十分に与えない。トリレンマの内､コストはすでに片手を縛っている訳だ。スケジュールも、契約で最初に決まってしまう。そうなると、スコープの多少の出し入れと、チーム内の人員（再）配置だけで､なんとか成果物を出せと言っているのに等しい。 そのくせ､「プロマネは結果が全て」「成果主義人事」などと称して､利益だけで人を評定しようとする。そもそも権限のないところで、結果責任だけを評価する企業が多いのだ。 そして仕事が利益を生まず､うまくいかないと､「もっと管理すれば良い」と考える。プロマネの権限をセーブして､必要な決断を、他人が承認しないとできないようにする。プロジェクト・マネジメントをマネジメントするための、屋上屋の組織を作る。「管理」はするが、助けることはしない。マネージャーとは一国一城の主のはずだった。それを、中間管理職化してコントロールしようとする。つまり、（はっきり言って）稼げない現場のリーダーは馬鹿だ、と思っているのではないか。 「だったら一体、何をどうすればいいんですか!?」と言いたくなるところだが、プロマネだって組織人だ。そして（上が思っているほどは）馬鹿ではない。だから心の中で静かにPCを閉じて会議室を立ち去り､そんな報われない仕事を､会社を､そして業界を、優秀な人ほど見限っていくのである。 組織の形態（フォーメーション）をデザインすることが､経営やマネジメントの仕事だと思っている上級職の人は、ずいぶん多い。だが組織の形態と、評価システムのデザインはワンセットである。プロジェクトには、プロマネが自分でなんとか采配できる範囲と､自分の意思や権限が及びにくい外部環境・内部環境の変動がある。責任も評価も､その権限範囲に対応していなければならない。 そして長年、プロジェクト・ビジネスを見てきた自分だから言うのだが､とくに大きなプロジェクトは必ず外部環境の影響を受ける。期間が長いからだ。その全てを、プロマネの能力のせいにしてはいけない。もう一度言うが､「プロマネは結果が全て」などというのは虚妄である。 〈関連エントリ〉 「プロジェクトのオーナーシップとは何か」 https://brevis.exblog.jp/27925736/ (2019-01-17) #
by Tomoichi_Sato
| 2025-03-18 10:04
| プロジェクト・マネジメント
|
Comments(0)
「言葉を大切にする」——これは、ロジックに関わる仕事をする人間にとって、とても大切な思考習慣だ。言語は（特に名詞や動詞などは）、その背後に『概念』を抱えている。何かを言葉で伝えるとは、その背後にある概念を指し示すポインターを、相手に渡すようなものだ。 このポインターがずれてしまうと、誤解の元となり、仕事がうまくいかなくなるばかりか、感情的な摩擦の原因になったりもする。ガンバリズムの「目標」に過ぎないものを「計画」と呼んだり、 支配欲求丸出しの号令を「リーダーシップ」などと称したりするところから、わたし達の混乱ははじまっていく。 もっとも、差し示される対象の「概念」のほうも、明確な領域や境界線があるとは限らない。しばしば、個物（インスタンス）の雲のような集合があって、そこから帰納的に概念を導いたりする。雲のような集合だから、人によって思い描く範囲が異なる。そこで時には話し合いによって、ここからここまでを、この概念の範囲に取り決めようと、「定義」が定められたりもする。ただし法律用語でもない限り、そうした定義は、部署や企業や業界団体の中で、 慣例として用いられるだけで、同じ言葉が業種を超えると、しばしば別の意味を持ったりする。 BOP（Bill of Process）という用語は、拙著「BOM/部品表入門」 には出てこない。この本を書いていたとき（2004年）には、まだほとんど使われていない言葉だったからだ。BOPは日本語では、「工程表」ないし「製造工程表」と訳される（というか、正確に言うと、これらの言葉はずっと昔からあったわけで、日本語ではこれらに対応する、と言うべきだろう）。 つまりBill of Processは、 近年になって普及してきた比較的新しい用語なのである。実際たとえば、大手PLM/MESベンダーであるダッソーシステムズ社は、つい最近までこの言葉を使わず、別の用語を当てていた。ようやく昨年頃から、Bill of Process の言葉も使われるようになった、と聞いたことがある。
BOPは、BOM（部品表）に関連した、いわばセットになる概念である。もっと具体的に言うと、設計部品表「E-BOM」= Engineering Bill of Materialを、製造部品表「M-BOM」= Manufacturing Bill of Material に展開・変換する際に必要となる、製造プロセス情報の集合を示す。プロセスの列挙表だから、Bill of Processと呼ぶ（レストランの勘定書きを英国でBillと呼ぶように、英語のbillには所有物や債務などを列挙した表の意味がある）。 ところで、ここから先がいささかややこしい。それは、この表が、 具体的な個別の製造作業を指すのか、それとも概念的な製造作業のリストを指すのか、という点に混乱があるためである。別の言い方をすると、この表はマスタ・データなのか、トランザクション・テーブルなのか、と言う問題だ。あるいは、クラスを示すのか、インスタンスなのか、と表現してもいい。 実はこの混乱は、BOM=部品表にもある。BOMとは、 製品を作るのに必要な部品の構成表である。ところで製造業では、部品の一時的な変更や代替がしばしば発生する。特に変化スピードの早いハイテク産業や電子機器業界では、 部品の世代交代が激しく、古い部品の在庫を使い切ったら、新しい部品に切り替える、といった事態が平気で起こる。 このような時に、BOMをどのタイミングで更新したら良いだろうか？ 製品はこれこれの部品で作るべきであると言う「べき論」と、実際の製造指図はここにある部品で作るしかないと言う「現実論」に、ギャップが生じる。この「べき論」の方はマスタ・データに規定し、「現実論」の方は、 個別の指図に添付したBOMと言うトランザクション・データとして記録するのが良い。だからBOMには、マスタの他に、指示の履歴と実行の履歴の、合計3種類のテーブルが必要なのだ。この事は拙著「BOM/部品表入門」でも最初のほうに説明した。 同じ区別が、Bill of Processでも必要なのである。その製品はこういう製造プロセスで、こうした作業時間の下で作る「べき」という情報と、この製品ロットはこれこれの製造プロセスで、この着手と完了期限で作ってくれという「現実」は、マスタとトランザクションで区別しなければならない。
もう一つややこしいことがある。それは「工程」という言葉だ。皆さんの職場で工程表と言ったら、何を指すだろうか。わたしの職場では、工程表と言うとデフォルトで、スケジュールを示したガントチャートのことになる。もちろんそうではない会社だって多いだろう。 製造業では、工程とはある種の製造プロセスをさすのが普通だが、その粒度はかなりまちまちだ。しかも、「工程」が実は工場内のエリアや作業区で区分されたり、組織の班で分担されたりもする。「工程」は、極めて多義的な言葉なのである。だから「BOP」の語を、頭の中で「工程表」に翻訳して理解しようとする人たちは、この言葉に伴う混乱を、逆に持ち込むことになる。 製造プロセスの粒度、すなわちどこからどこまでをひとまとまりとして扱うのか、については古くから議論があった。アメリカで1960年代にMRPが成立するが、1つの課題は製造負荷と工程能力の調整にあった。MRPは納期から逆算して工程別に製造オーダーを計算する。 機械的に計算すると（機械だから機械的に計算するのだが）、 工程の能力で処理しきれないほど、製造オーダーが集中してしまうことが起きる。 だったら、工程の能力上限をマスタ・データにして、チェックをかければ良いではないか。ところが、これを適用しようとすると、厄介な問題に突き当たる。1つの工程とされている製造プロセスの中をよく見ると、複数の異なる機械や人員や金型といった「製造資源」を必要とする、別々の単位的な作業が並んでいたりするのである。 そこで80年代以降の「MRP II」では、複数作業が並んだセットとしての「Routing」概念が登場する。そして部品の親子関係をつなぐ製造プロセスとは、工程ではなくRoutingだ、 ということになった。ところで、英語のRoutingはふつう「工順」と訳されるが、この日本語は、「一連の作業工程のセット」という意味で使われる場合と、「作業の順番」（つまり番号）を意味する場合がある。MRP IIでいっているのは、セット＝集合の方である。
ということで、ここまででもう充分、読者の頭は混乱したと思うから(笑)、ここで再整理しよう。 BOP = Bill of Processの用語は、3種類に分けることができる。 第1の用法：工順を表す
 第2の用法：工順の全体ツリーを表す（共通マスタ情報）
 第3の用法：工順の全体ツリーを表す（具体的な日時の情報をもつ）
 はじめにも書いたとおり、言葉は大切だ。ただ、わたし達の社会では、言葉は雰囲気作りの道具としても使われる。「DX」しかり、「スマート製造」しかり。「グローバル戦略」なんて、もっとそうだ。ポジティブな雰囲気を作り出し、ムードに酔うことも、ときには必要だろう。だがロジックに関わる仕事をしたいのなら、概念について、きちんとクールに付き合うべきだろう。 ＜関連エントリ＞ 「製造作業を自動化するために必要なデータとは」 https://brevis.exblog.jp/33521355/ (2025-02-15) 「BOM（部品表）は世代交代とともに精緻化している」 https://brevis.exblog.jp/32588574/ (2024-07-04) 「部品表と工程表」 https://brevis.exblog.jp/25634844/ (2017-03-22) #
by Tomoichi_Sato
| 2025-03-09 21:50
| サプライチェーン
|
Comments(0)
という訳で（笑）、料理本2冊の書評です。
「オールド台湾食卓記」洪愛珠・著 (Amazon) なんて幸せな本だろう！ この本を読むと、台湾人がどれほど食べることと生きることに情熱を傾け、そして楽しんでいるかが分かる。そしてまた台湾に行きたくなる。 本書の原題は『老派少女購物路線』。老派少女という語がどういうニュアンスを運ぶのかはよく分からないが、著者は1983年生まれのデザイナーで、原著出版当時は38歳だった。訳者によると、古臭いという意味の「老派」の語を一種ポジティブに使うようになったのは、この10年ちょっとの事らしい。著者自身の装幀を再現した日本語版の表紙にも、古くからある桃饅頭が赤い表紙の真ん中に鎮座して、レトロだが親密な感じを醸し出している。 「祖母、母、私の行きつけの店」と副題のついたこの本は、著者の記憶の中にあるちょっとだけ前の世代の台湾の暮らしが、その雰囲気や匂いと共に行間から立ち上がってくる。著者は台北郊外の五股（ウーダー）、蘆洲（ルージョウ）地域に生まれ育つ。そして育った家の台所と、亡くなった母の大事にしていた台所道具の話から始まる。これがいい。土鍋、フライパン、玉杓子。嫁入り道具だという中国包丁とまな板。これらは著者による写真がついている。そして京都の錦市場でわざわざ買ったという毛抜き（魯肉を煮るとき、皮付き黒豚から毛を抜くのに使うのだ）。 蘆洲は切仔麺発祥の地らしいが、とくに観光名所でもなく普通の町だという。でも幼少の頃は祖母が切り盛りする大家族の台所を見て、育つ。そして近くの永楽市場での買い物について回る。第2部は、麺と、粥と、ちまきなど米食の話だ。もちろん多数のバリエーションがある。この人は福建系で潮州の家系に属するらしく、塩気の強いおかずと一緒に粥を食べる（雑鹹というらしい）。 第3部はメインのおかずの話。魯肉（ルーロー）は台湾の代表的家庭料理だが、一族の中で魯肉を煮るのは自分一人になってしまった、と著者は書く。こうしたところに、豊かになった台湾社会の少子化と、とても手間のかかる台湾料理とのギャップが透けて見える。 そして著者の家族に、日本から作家の乃南アサさんがたずねてくるので、歓迎するための宴席の準備が細かく描かれる。ああ、なんて美味しそうなんだろう！ そしてまさに、手間の極致である。ちなみに本書には数え切れないほど沢山の料理の名前が、複雑な漢字で独特の読みガナつきで紹介されるが、訳者が都度、かっこ書きで簡潔適切な説明を入れてくれるので、とても助かる。 第4部は香港や留学先のイギリスを含めた、お茶とお茶菓子の記憶。そして第5部は東南アジアの旅行先で出会う潮州料理の話。どのページを読んでも、ため息が出そうなくらい、美味しそうな食べ物に満ちていて、そして食べることに愛情を注ぎながら、溺れずに一歩引いて自分を見つめる著者の姿がある。 本書は全編の底に、病気で早世した母君への、著者の哀悼の気持ちが強く流れている。その、いわばノスタルジアに近い感覚が、『老派少女』の回想を色づけているのだろう。日本統治下で生まれた祖母も、国民党統治下を生きた母も、苦難の時代を女性という不利な立場で忍耐しながら、家族愛を持って生き続けた。その二人から、そして親族や父祖達から受け継いだ「思い」こそが、複雑な現代台湾の人生の味を生み出しているのだ。
「何が『いただく」ぢゃ！」姫野カオルコ・著 (Amazon) 姫野カオルコは直木賞作家で、ひいきにしている小説家である。代表作『リアル・シンデレラ』 や『昭和の犬』、話題作『彼女は頭が悪いから』など、ゆがんだ現代日本において、普通の人びとがいかにまっすぐ生きていくかを、あまり鋭角になりすぎず情緒的にもなりすぎぬ筆致で描き出す。日本には数少ないモラリストの作家だと思う。 同時にこの人は若い頃から、ウィットあふれるコラムニストとしても確かな腕前をもっていて、『みんな、どうして結婚してゆくのだろう』 とか『すべての女は痩せすぎである』とか、ときにシャープな喩えで、またときに抱腹絶倒な形容詞で、世にあふれる陳腐を笑い飛ばし、読者の頭の中の澱みをクリアしてくれる。 その著者が、男性向けの食と料理の雑誌「Danchu」に連載したコラムを、まとめたのが本書である。でも、もちろん高級料理店やら貴重食材などにウンチクを傾ける話には、ならない。冒頭の話題は「ふきのとう」である。ちょうど今頃のシーズン、出回りはじめる早春の山菜ですな。ごく普通の、どちらかと言えば地味な食材。 ただ、ふきのとうのほろ苦い美味しさを味わうのは、子どもには無理だ。だから著者は、地方自治体は『ふきのとう条例』を出すとよい、という。「成人式の会場の受付で、ふきのとうの料理を出して、 おいしく味わって食 べられた者だけを、中に入れることにする。『大人になりましたね、おめでとう』と」(P.8)。最初からヒメノ節炸裂である。 でも、それだけではない。天ぷらか味噌和えくらいしか普通は思いつかないふきのとうの、新しいレシピを著者は提案する。豚の赤身の挽肉を、ごま油で炒めて甘辛に味付け、それに、軽く蒸し上げたふきのとうをそえて、一緒に食べる。そしてよく冷えたビールを飲む。読んでいるだけで、口の中に苦みと香りのハーモニーが感じられるではないか。 ちなみに上の例でも分かるとおり、この人は料理を考える際に、お酒といっしょに食べておいしいように、まず考える。お酒に弱い人を「下戸（げこ）」というが、著者はその逆の「上戸 (じょうご)」である。下戸は、ごはんと食べて美味しいように考える、という(P.30)。たしかに料理屋にはいると、そこの主人がどちらに属するかは、よく注意すると分かるような気がする。 そのためだろう。ある意味、本書で最も有用な提案は、実はレシピではなく、日本酒のクラス分類に使う「大吟醸」「特別本醸造」といったネーミング用語に関する部分かもしれない。酒税法の税金は同じだが、作り方を区別するための「特定名称酒」。これについて、違いは二点だ、と著者は言う。
そして、女性モデルに喩えた用語を代わりに提案する。
そうすると、純米大吟醸は「ソロ・スキニー」だし、特別本醸造は「デュエット・プラス」である（「特別」＝「プラス」）。うーん。確かに、この方がずっと分かりやすい。 それに、米を削る方が必ず美味しい、醸造アルコールを加えない方が美味しい、とは必ずしも言えない。それは作り方の、あるいは味のデザインのポリシーだからである。ぜひ、世の中の酒店もこう表記してくれないかな。 この例で分かるように、この著者は（作家だから当然かもしれないが）言葉や文法についても潔癖である。だから謙譲語であるべき「いただく」を、世のメディアが誤用している状況を許せないのだろう。書名の「何が『いただく」ぢゃ！」は、そうしたおかしな言葉が、そしておかしな判断や通念がまかり通る世の中で、モラリストの女性作家がブレない不動点を示す、見事な象徴なのである。 ＜関連エントリ＞ 「書評：2011年に読んだ本 ベスト3」（「リアル・シンデレラ」を含む） https://brevis.exblog.jp/17166005/ (2012-01-04) 「書評：『昭和の犬』 姫野カオルコ・著」 https://brevis.exblog.jp/21911187/ (2014-04-22) 「書評：『彼女は頭が悪いから』 姫野カオルコ・著」 https://brevis.exblog.jp/28752713/ (2019-12-17) #
by Tomoichi_Sato
| 2025-03-03 19:46
| 書評
|
Comments(0)
|
検索
カテゴリ
全体 サプライチェーン 工場計画論 プロジェクト・マネジメント リスク・マネジメント 時間管理術 ビジネス 思考とモデリング 考えるヒント ITって、何？ 書評 映画評・音楽評 English articles 最新の記事
記事ランキング
著書・姉妹サイト
ニュースレターに登録
私のプロフィル My Profile 【著書】 「世界を動かすプロジェクトマネジメントの教科書  」「時間管理術  」(日経文庫)「BOM/部品表入門 (図解でわかる生産の実務)  」「リスク確率に基づくプロジェクト・マネジメントの研究  」【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
ブログパーツ
メール配信サービス by Benchmark 最新のコメント
ブログジャンル
画像一覧
|
