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

中間管理職と化したプロマネ ～ 一体、何をどうしろと言うんです!?

• どうしてプロマネを助けないのか

会議は､あっけなく終わった。「質問は？」議長がたずねたが、誰も声を上げない。それが最後の議題だったので散会となった。参加者は皆、三々五々部屋を出て行く。報告者のプロマネも、しばらくじっと黙ってうつむいていたが、自分のノートPCをたたんで静かに出て行った。ただ、わたしは呆然とした気持ちのまま､席を立つ気がしなかった。

この種類のプロジェクトが、この段階でこの状態にあるとは、まともじゃない。基本構想の仕事ならいざ知らず､すでに投資決定も下り､力仕事の段階に入っている。報告内容から見て､明らかに人も､予算も足りていない。当然､納期にも間に合うまい。ただ、プロマネ自身は､そうは言わなかった。顧客起因の重大な変更があって、進捗も遅れ気味だが､「何とか頑張ります」と言ったのだ。

会議の出席者の中には、経営層の人もいた。他のメンバーだって、昨日今日仕事を始めた人たちではあるまい。だったらなぜ、発言しないのか。「今すぐ､このプロジェクトを助けなけりゃダメだ。このまま放っておいたら大変なことになる」と。だが、誰もそうは言わなかった。実際に会議で決まったのは､問題プロジェクトなので、さらに定期報告やレビューの義務を課すことだった。

わたし自身は違う会社の人間で､たまたまオブザーバーとして後ろの席に座っていただけだから､当然、発言権はない。だが当事者の一員だったら､こう主張したくなったろう。「プロマネ一人の責任に任せて、レビューだゲートだ報告だ、などと言っている場合じゃないですよ」と。逆に自分がプロマネの立場だったら､どうするか。「こんな状態で一体、何をどうしろと言うんです!?」とでも叫ぶだろうか。

• プログラム・マネージャーとプロジェクト・オーナーの圧倒的不在

モダンPMの参考書や標準書を読むと､プロジェクトは複数のアクティビティから構成され（業界によっては「タスク」とも呼ぶ）、さらにプロジェクトの上位概念としてプログラムがある､と書いてある。つまりプログラム、プロジェクト､アクティビティ（タスク）の三階層がある、という訳だ。

また、かりにプロジェクトが単独で行われ､上位にプログラムがない場合にも､プロマネの上位に『プロジェクト・オーナー』という立場が存在する､と書いてある（これも業界によってはプロジェクト・スポンサーと呼んだりもするが）。このオーナー/スポンサーの役割とはすなわち、プロジェクトを公式化し､予算枠を与え､プロマネを任命することだ。これが、連関する複数のプロジェクトを束ねるプログラムの場合だと､その仕事はプログラム・マネージャーが行うことになる。

とはいえ受注型プロジェクトは、単独で行われることがほとんどだ（複数の連関するプロジェクトを気前よくバサッと渡して、全体を任せてくれる顧客なんていやしない）。だとしたら、受注したプロジェクトの数だけ、オーナーもいるはずだ。そしてオーナーは、フルタイムでプロジェクトを面倒見ている訳ではないが、それでも遂行状態を時折ウォッチして、問題が起きたらプロマネを助ける存在である、はずである（それが任命責任というものだ）。

だが現実には､そんな上等なプロジェクト・オーナーなんかいない。プログラム・マネージャーなんか、もっと不在だ。そもそも『プログラム・マネジメント』なんて概念､社内で知る人もいないし勉強する人もいない。勉強する場所もない。――それが受注ビジネスで食べている、大方の組織の現状ではないか？

• PMOとプロジェクト「管理」

そういう会社にも､PMO(Proejct Management Office)と呼ばれる組織はあったりする。PMOは何をする部門か？　一つの重要な役割は､プロジェクト・マネジメントに関する標準プロセスや仕組みを作り上げることだ。もう一つは､個別のプロジェクトで、「マネジメントを支援する」ことになっている。

支援というのは､しかし、微妙な概念だ。支援した人は､結果についても責任を持つのか？　そうではあるまい。プロジェクトの最終責任は､やはりプロマネが負うことになっている（ところが多い）。PMOが横から手を出しても、何か重要なことを決断するのは､プロマネである。そうでなければ、今度はプロマネの側がやってられなくなる。自分とは違う考えの人が､横から勝手に判断を下したら、誰が結果に責任を持つのか？

つまり、マネジメントという仕事の一番大切な部分は､「決断を下す」ことにあるのだ。状況は流動的､先行きは不確実、技術にもリスクがある。だが、何かを決めなければならない。決めるために、マネージャーがいる。いったん決めたら､それが良い結果を生むよう、周囲を動かしていかなければならない。「先を読む」「決断する」「人を動かす」――それがマネージャーの仕事だ。

もちろん、「進捗や品質やコストの状況を、正確に把握する」「報告する」も、マネジメントの仕事ではある（PMOは主にこちらを助ける）。それをしなくていい､とは言わない。だが状況把握は、より良い決断のために必要なのだし､報告はそれによって会社（チームの上位の組織）が助けてくれるからこそ、意味があるのだ。報告それ自体が目的なのではない。

実をいうと、わたし自身､PMO的な仕事を何年間もやっていた。だから、その難しさを少しは知っている。PMOはプロマネの部下ではない。その指揮命令の下で、手足として動く訳ではない。しかし、プロマネの上位にいる訳でもない。上位にいるのは（一応）オーナーだ。PMOにはプロマネへの指揮命令権限もない。

じゃあ何かというと､いわばスポーツのスコアラーなのだ。フィールドで観察し､記録する。そのデータ蓄積はとても重要だ。決断の参考にもなる。ただ、日本語ではモニタリングし記録する仕事も、『管理』と呼ぶ。わたしがプロジェクト・マネジメントを「プロジェクト管理」と呼ばないのは､この点を区別したいためだ。主体的に決断し､最後まで覚悟を決めて実行すること。それが責任あるマネジメントの姿で、上から目線の「管理」とはほど遠い。

• 必要なのは責任にバランスした権限である

日本のサラリーマン組織の中核問題（の一つ）は、上位マネジメントの機能不全を､現場リーダーが無理にカバーしている点にある。そう、わたしは考えている。

プロジェクトとは、スコープ・コスト・スケジュールの3つの制約条件に取り囲まれ､トリレンマの状態にある。これは製造業における生産マネジメントが､QCDのトリレンマ状態にあることとよく似ている。

トリレンマだから、どれか一つを変えようとすると､必ず他の二辺に影響が及ぶ。したがって、プロジェクト・マネージャーは、スコープ・コスト・スケジュールの3つについて、適切な手を打てるような権限が必要である。そもそもマネジメントの仕事とは､経営資源の適切な配分によって、組織のアウトカムの価値を最大化することである。もっと具体的に言えば、人員を動かし､必要ならば外部組織を動かすための金を使い、技術や設備など有形無形の資産を動員して、トリレンマを緩和することにある。

それなのに、少なからぬ組織では（とくにIT業界のSIer等では）､プロマネに予算の執行や発注の権限を、十分に与えない。トリレンマの内､コストはすでに片手を縛っている訳だ。スケジュールも、契約で最初に決まってしまう。そうなると、スコープの多少の出し入れと、チーム内の人員（再）配置だけで､なんとか成果物を出せと言っているのに等しい。

そのくせ､「プロマネは結果が全て」「成果主義人事」などと称して､利益だけで人を評定しようとする。そもそも権限のないところで、結果責任だけを評価する企業が多いのだ。

そして仕事が利益を生まず､うまくいかないと､「もっと管理すれば良い」と考える。プロマネの権限をセーブして､必要な決断を、他人が承認しないとできないようにする。プロジェクト・マネジメントをマネジメントするための、屋上屋の組織を作る。「管理」はするが、助けることはしない。マネージャーとは一国一城の主のはずだった。それを、中間管理職化してコントロールしようとする。つまり、（はっきり言って）稼げない現場のリーダーは馬鹿だ、と思っているのではないか。

「だったら一体、何をどうすればいいんですか!?」と言いたくなるところだが、プロマネだって組織人だ。そして（上が思っているほどは）馬鹿ではない。だから心の中で静かにPCを閉じて会議室を立ち去り､そんな報われない仕事を､会社を､そして業界を、優秀な人ほど見限っていくのである。

組織の形態（フォーメーション）をデザインすることが､経営やマネジメントの仕事だと思っている上級職の人は、ずいぶん多い。だが組織の形態と、評価システムのデザインはワンセットである。プロジェクトには、プロマネが自分でなんとか采配できる範囲と､自分の意思や権限が及びにくい外部環境・内部環境の変動がある。責任も評価も､その権限範囲に対応していなければならない。

そして長年、プロジェクト・ビジネスを見てきた自分だから言うのだが､とくに大きなプロジェクトは必ず外部環境の影響を受ける。期間が長いからだ。その全てを、プロマネの能力のせいにしてはいけない。もう一度言うが､「プロマネは結果が全て」などというのは虚妄である。

〈関連エントリ〉

「プロジェクトのオーナーシップとは何か」 https://brevis.exblog.jp/27925736/ (2019-01-17)

BOP（Bill of Process）とは何を意味するのか ～ 三種類の用法を再整理する

• Bill of Processは比較的新しい言葉である

「言葉を大切にする」——これは、ロジックに関わる仕事をする人間にとって、とても大切な思考習慣だ。言語は（特に名詞や動詞などは）、その背後に『概念』を抱えている。何かを言葉で伝えるとは、その背後にある概念を指し示すポインターを、相手に渡すようなものだ。

このポインターがずれてしまうと、誤解の元となり、仕事がうまくいかなくなるばかりか、感情的な摩擦の原因になったりもする。ガンバリズムの「目標」に過ぎないものを「計画」と呼んだり、 支配欲求丸出しの号令を「リーダーシップ」などと称したりするところから、わたし達の混乱ははじまっていく。

もっとも、差し示される対象の「概念」のほうも、明確な領域や境界線があるとは限らない。しばしば、個物（インスタンス）の雲のような集合があって、そこから帰納的に概念を導いたりする。雲のような集合だから、人によって思い描く範囲が異なる。そこで時には話し合いによって、ここからここまでを、この概念の範囲に取り決めようと、「定義」が定められたりもする。ただし法律用語でもない限り、そうした定義は、部署や企業や業界団体の中で、 慣例として用いられるだけで、同じ言葉が業種を超えると、しばしば別の意味を持ったりする。

BOP（Bill of Process）という用語は、拙著「BOM/部品表入門」 には出てこない。この本を書いていたとき（2004年）には、まだほとんど使われていない言葉だったからだ。BOPは日本語では、「工程表」ないし「製造工程表」と訳される（というか、正確に言うと、これらの言葉はずっと昔からあったわけで、日本語ではこれらに対応する、と言うべきだろう）。

つまりBill of Processは、 近年になって普及してきた比較的新しい用語なのである。実際たとえば、大手PLM/MESベンダーであるダッソーシステムズ社は、つい最近までこの言葉を使わず、別の用語を当てていた。ようやく昨年頃から、Bill of Process の言葉も使われるようになった、と聞いたことがある。

• 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の3種類の用法とは

ということで、ここまででもう充分、読者の頭は混乱したと思うから(笑)、ここで再整理しよう。

BOP = Bill of Processの用語は、3種類に分けることができる。

第1の用法：工順を表す

すなわちBOMの中で、あるマテリアル（部品材料）が、その親のマテリアル（中間部品・製品）になるまでの、一連の作業の集合を表す、という使い方である。わたしの知る事例では、航空機製造業界で大手企業が部品製造に関して、このような使い方をしている。つまりMRP IIでいうRoutingのことを、BOPと呼ぶ訳だ。

第2の用法：工順の全体ツリーを表す（共通マスタ情報）

第1の用法が、BOMの1段階の親子関係をつなぐ部分に着目しているのに対して、第2の用法は、最終製品を作るために必要なRouting全体をさすケースである（BOMがツリー構造になっているため、BOPもツリーに表現できる）。ネットでBOPを検索すると、現時点ではPLM系のベンダーやコンサルタントの記事が多く引っかかるが、ほとんどはこの用法で使っている（ようだ）。

なお、自動車産業をはじめ、グローバル生産を行う企業では、同一の製品でも生産地によって異なる作り方をすることが多い。この場合、複数の代替的な製造プロセスを一つのBOPに集約する、150%BOM的な例も紹介されたりする。つまり、ここでのBOPはあくまでマスタ概念である。

第3の用法：工順の全体ツリーを表す（具体的な日時の情報をもつ）

ところで、PLM系の業務に用いるマスタでは、複数の代替手段を定義してもいいが、SCM系業務に用いる現実の製造オーダーでは、どれか一つを選ばなくてはならない。無用な重複は許されないからだ。つまり、その場合BOPのトランザクション・データ（インスタンス）は、現実に可能な製造プロセスのスリムなセット、ということになる。

そして現実の製造オーダーには、具体的な期日がついて回る。したがって、BOPには着手完了に関して、具体的な日時の情報をもつことになる。そして、このようなケースでは、しばしばガントチャート（工程表）表現も付随して使われる。これが第3の用法だ。第3の用法、つまり製造オーダーまでも、PLMシステムでカバーしている事例は少ないと思われる（少なくともわたし個人は知らない）。多くはERPや生産管理システムなど、SCM系システムで展開しているはずである。

はじめにも書いたとおり、言葉は大切だ。ただ、わたし達の社会では、言葉は雰囲気作りの道具としても使われる。「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)

書評：「オールド台湾食卓記」洪愛珠・著、「何が『いただく」ぢゃ！」姫野カオルコ・著

という訳で（笑）、料理本2冊の書評です。

• 「オールド台湾食卓記」洪愛珠・著、新井一二三・訳

「オールド台湾食卓記」洪愛珠・著 (Amazon)

なんて幸せな本だろう！　この本を読むと、台湾人がどれほど食べることと生きることに情熱を傾け、そして楽しんでいるかが分かる。そしてまた台湾に行きたくなる。

本書の原題は『老派少女購物路線』。老派少女という語がどういうニュアンスを運ぶのかはよく分からないが、著者は1983年生まれのデザイナーで、原著出版当時は38歳だった。訳者によると、古臭いという意味の「老派」の語を一種ポジティブに使うようになったのは、この10年ちょっとの事らしい。著者自身の装幀を再現した日本語版の表紙にも、古くからある桃饅頭が赤い表紙の真ん中に鎮座して、レトロだが親密な感じを醸し出している。

「祖母、母、私の行きつけの店」と副題のついたこの本は、著者の記憶の中にあるちょっとだけ前の世代の台湾の暮らしが、その雰囲気や匂いと共に行間から立ち上がってくる。著者は台北郊外の五股（ウーダー）、蘆洲（ルージョウ）地域に生まれ育つ。そして育った家の台所と、亡くなった母の大事にしていた台所道具の話から始まる。これがいい。土鍋、フライパン、玉杓子。嫁入り道具だという中国包丁とまな板。これらは著者による写真がついている。そして京都の錦市場でわざわざ買ったという毛抜き（魯肉を煮るとき、皮付き黒豚から毛を抜くのに使うのだ）。

蘆洲は切仔麺発祥の地らしいが、とくに観光名所でもなく普通の町だという。でも幼少の頃は祖母が切り盛りする大家族の台所を見て、育つ。そして近くの永楽市場での買い物について回る。第2部は、麺と、粥と、ちまきなど米食の話だ。もちろん多数のバリエーションがある。この人は福建系で潮州の家系に属するらしく、塩気の強いおかずと一緒に粥を食べる（雑鹹というらしい）。

第3部はメインのおかずの話。魯肉（ルーロー）は台湾の代表的家庭料理だが、一族の中で魯肉を煮るのは自分一人になってしまった、と著者は書く。こうしたところに、豊かになった台湾社会の少子化と、とても手間のかかる台湾料理とのギャップが透けて見える。

そして著者の家族に、日本から作家の乃南アサさんがたずねてくるので、歓迎するための宴席の準備が細かく描かれる。ああ、なんて美味しそうなんだろう！　そしてまさに、手間の極致である。ちなみに本書には数え切れないほど沢山の料理の名前が、複雑な漢字で独特の読みガナつきで紹介されるが、訳者が都度、かっこ書きで簡潔適切な説明を入れてくれるので、とても助かる。

第4部は香港や留学先のイギリスを含めた、お茶とお茶菓子の記憶。そして第5部は東南アジアの旅行先で出会う潮州料理の話。どのページを読んでも、ため息が出そうなくらい、美味しそうな食べ物に満ちていて、そして食べることに愛情を注ぎながら、溺れずに一歩引いて自分を見つめる著者の姿がある。

本書は全編の底に、病気で早世した母君への、著者の哀悼の気持ちが強く流れている。その、いわばノスタルジアに近い感覚が、『老派少女』の回想を色づけているのだろう。日本統治下で生まれた祖母も、国民党統治下を生きた母も、苦難の時代を女性という不利な立場で忍耐しながら、家族愛を持って生き続けた。その二人から、そして親族や父祖達から受け継いだ「思い」こそが、複雑な現代台湾の人生の味を生み出しているのだ。

• 「何が『いただく」ぢゃ！」　姫野カオルコ・著

「何が『いただく」ぢゃ！」姫野カオルコ・著 (Amazon)

姫野カオルコは直木賞作家で、ひいきにしている小説家である。代表作『リアル・シンデレラ』 や『昭和の犬』、話題作『彼女は頭が悪いから』など、ゆがんだ現代日本において、普通の人びとがいかにまっすぐ生きていくかを、あまり鋭角になりすぎず情緒的にもなりすぎぬ筆致で描き出す。日本には数少ないモラリストの作家だと思う。

同時にこの人は若い頃から、ウィットあふれるコラムニストとしても確かな腕前をもっていて、『みんな、どうして結婚してゆくのだろう』 とか『すべての女は痩せすぎである』とか、ときにシャープな喩えで、またときに抱腹絶倒な形容詞で、世にあふれる陳腐を笑い飛ばし、読者の頭の中の澱みをクリアしてくれる。

その著者が、男性向けの食と料理の雑誌「Danchu」に連載したコラムを、まとめたのが本書である。でも、もちろん高級料理店やら貴重食材などにウンチクを傾ける話には、ならない。冒頭の話題は「ふきのとう」である。ちょうど今頃のシーズン、出回りはじめる早春の山菜ですな。ごく普通の、どちらかと言えば地味な食材。

ただ、ふきのとうのほろ苦い美味しさを味わうのは、子どもには無理だ。だから著者は、地方自治体は『ふきのとう条例』を出すとよい、という。「成人式の会場の受付で、ふきのとうの料理を出して、 おいしく味わって食 べられた者だけを、中に入れることにする。『大人になりましたね、おめでとう』と」(P.8)。最初からヒメノ節炸裂である。

でも、それだけではない。天ぷらか味噌和えくらいしか普通は思いつかないふきのとうの、新しいレシピを著者は提案する。豚の赤身の挽肉を、ごま油で炒めて甘辛に味付け、それに、軽く蒸し上げたふきのとうをそえて、一緒に食べる。そしてよく冷えたビールを飲む。読んでいるだけで、口の中に苦みと香りのハーモニーが感じられるではないか。

ちなみに上の例でも分かるとおり、この人は料理を考える際に、お酒といっしょに食べておいしいように、まず考える。お酒に弱い人を「下戸（げこ）」というが、著者はその逆の「上戸 (じょうご)」である。下戸は、ごはんと食べて美味しいように考える、という(P.30)。たしかに料理屋にはいると、そこの主人がどちらに属するかは、よく注意すると分かるような気がする。

そのためだろう。ある意味、本書で最も有用な提案は、実はレシピではなく、日本酒のクラス分類に使う「大吟醸」「特別本醸造」といったネーミング用語に関する部分かもしれない。酒税法の税金は同じだが、作り方を区別するための「特定名称酒」。これについて、違いは二点だ、と著者は言う。

・米粒をどれくらい削っているか

・醸造アルコールも入っているか（これは味をデザインするために使う）

そして、女性モデルに喩えた用語を代わりに提案する。

◇米と米麹だけで造った酒＝ソロ。

◇醸造アルコールも入っている酒＝デュエット。

o米粒をほっそり削った＝スリム。

o米粒をガリガリに削った＝スキニー。

そうすると、純米大吟醸は「ソロ・スキニー」だし、特別本醸造は「デュエット・プラス」である（「特別」＝「プラス」）。うーん。確かに、この方がずっと分かりやすい。

それに、米を削る方が必ず美味しい、醸造アルコールを加えない方が美味しい、とは必ずしも言えない。それは作り方の、あるいは味のデザインのポリシーだからである。ぜひ、世の中の酒店もこう表記してくれないかな。

この例で分かるように、この著者は（作家だから当然かもしれないが）言葉や文法についても潔癖である。だから謙譲語であるべき「いただく」を、世のメディアが誤用している状況を許せないのだろう。書名の「何が『いただく」ぢゃ！」は、そうしたおかしな言葉が、そしておかしな判断や通念がまかり通る世の中で、モラリストの女性作家がブレない不動点を示す、見事な象徴なのである。

＜関連エントリ＞

「書評：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)

製造作業を自動化するために必要な技術とは

（→ 前回記事に続く）

• キッチンに置く端末

料理が趣味というほどではないが、料理書を読むのは好きだ。美味しそうな写真付きの料理本、あるいは文章に味があって想像力に訴える食のエッセイなどは、読んでいて楽しい。夕食後のゆったりした気分の時に読むと、胃を刺激して消化を助けるような気もする（「食後に料理本なんて読むのはあなただけよ」と連れ合いは言うのだが）。

ともあれ、料理本は実用書なので、調理の時に台所において参考にする。だからページは開きやすく、表紙は汚れにくい方が良い。もっとも最近はレシピをネットで調べることも多く、そうなるとスマホかタブレット画面を見ることになる。しかし、これが意外と不便なのだ。

まず、料理中は手指がぬれたり汚れたりする。画面スクロールも指紋認証もやりにくい。そして肝心なときに画面がタイムアウトし、オフになる。わたしは専用スタンドにiPad miniを置き、画面オフ時間をかなり長くしているが、それでも置き場所に悩む。キッチンは狭くて、物が所狭しと並ぶ。台の上にはスペースがないのだ。それに電源も。

いっそのこと伸縮式アームに取り付け、壁か天井に固定したら便利なのに、とも思う。だがそもそも、台所とは油や煙がたちこめやすい。温度も高温になり、湿度も湯気で高くなる、ハードな環境なのだ。今のスマホやタブレットは、そういった過酷な環境向けには設計されていない。もっと堅牢で、手指の入力インタフェースも明確で、拭いたりメンテしやすいハードが必要なのだ。どこかのベンチャーが開発してくれないものか。

• 端末が調理器具につながったら

実は、このような堅牢なハードウェアへの要望は、工場や物流センターなどの現場の悩みと共通している。そういった職場も、普通のオフィスとは違う温度・湿度で、ホコリや煙もあったりする中を、手袋をした人たちが使う。場所によっては防爆対応も求められる。「防爆」とは、可燃性物質のある場所で、電子機器が点火源となって火災・爆発が起きないようにする技術仕様のことだ。

まあ、仮にそんなナイスな端末が、我が家のキッチンでも使用可能になったとしよう。それで完全にハッピーだろうか？　いや、そうなればむしろ欲が出てくるかもしれない。例えば、その端末からガスレンジの温度制御もできるとうれしい。最近のガスレンジは、揚げ物の鍋の温度を180℃とか200℃とかコントロールできるものがある。それが端末から指示できないか。レシピと連動して、温度制御できるといいなあ。

それとタイマー設定して、自動的に火を消してくれるとうれしい。これもレシピと連動してほしい。まあ自動着火までは、安全性の観点から望まないとしても、だ。

そうなるとレンジだけではなく、卓上の計量器とつながって、端末からの指示で食材の秤量もしてくれると、もっと便利だろう。調味料の計量（醤油大さじ1杯半）なんかも、自動でできるといいなあ。レシピを入力すると、必要な調味料が全部、料理番組みたいに目の前にそろっている。素敵ではないか。料理では、こういうところに案外時間がとれらるのだ。

食材を秤量し、調味料を計量し、加熱時間や温度をセットしたら、当然ながらそれが現実に何グラムで何度何分だったかの、記録もとりたい。そして端末には、料理のステップバイステップで、手順が表示される。すると、ミスも防止される。いや、ミスよりむしろ大事なのは、今まで作ったことのない料理でも、きちんとできるようになることだ。スパイスカレーの作り方を「体で覚えて」いない人だって、ちゃんと本格派カレーが作れる。製造作業が「暗黙知」の属人的なスキルから、移転可能な仕事に変わるのだ。

そして、これこそがMES＝製造実行システムの主要な機能の柱なのである。それまでやったことのない人でも、正しい手順で、求められるプロダクトが作れる。そして作業記録も取ってくれる。作業日報なんて、いらない。MESの中核機能が、これだ。

そのためにはMESシステムが、調理器具だの計量器だのといった、製造現場での機械類とインタフェースでつながっている必要がある。先ほど温度制御してくれるガスコンロがあると書いたが、そうしたコンロの中には、簡単なPLCが組み込まれているのだ。そうしたPLCと、相互にデータ通信できるインタフェースが必要だ（望むらくは無線で）。現場機器とつながっていないMESでは、作業者に指示画面を表示する程度で終わってしまう。それでは、自動化としては、とても物足りない。

• ロボットでもっと機械化する

でも、もう少しだけ空想の幅を広げよう。いっそのこと、ロボットを導入して、キッチンを完全自動化するのはどうだ？　最近は、人と一緒の場所で働いてくれる「協働ロボット」が普及してきた。昔は安全のため、産業用ロボットは柵の中で動かしていた。その壁が、とりはらわれつつあるのだ。

でも、現実のロボットを少しでも知っている人なら、案外ハードルが高いことが予想できよう。料理では、野菜とか魚とか肉類とか卵とか、柔らかい不定型な材料を扱う。これらをちゃんと（そっと、しかし、しっかり）ハンドでつかまなければならない。そして、芯とかハラわたとか骨とかを認知して、その向きに沿って包丁を入れる必要がある。

そればかりではない。素材の大きさに応じて、三つに割ったり四つに切ったりする。表面を見て、傷んでいたら、その箇所を取る。切ってみて、中まで痛んでいたら、捨てなければいけない。つまり、料理には細かな判断が必要なのだ。これを、どうロボットに組み込むのか。まさか、良い料理もダメな料理もたくさん作ってみて、結果を機械学習させるという訳にもいくまい。料理は人が食べるもので、安心して食べられることが絶対条件なのだ。

そして台所は、上にも述べたとおり流体や粉体（塩・砂糖・小麦粉等）を扱う場所だ。ロボットアームの摺動部分にこうした流体・粉体が入り込んだら、故障の原因だ。どうする？　ロボットにかっぽう着を着せるのか？（じつは、わたしの勤務先で粉体を扱う医薬品の製剤工場にロボットを納入した際、ほんとにロボットに更衣を着せた）

だが、最大の問題は他にある。料理が多品種であることだ。キッチンは多品種少量の典型なのだ。製品の種類もバリエーションも、人類の文化と食欲にしたがって、無限に広がっていく。でも、ロボットにはティーチング（つまりプログラミング）が必要である。じゃあ、新しい料理を作るたびに、誰がどうティーチングするのか？

• 製造作業の自動化とは、AIやロボットの導入ではない

つまり、機械による自動化には、スケール（規模）が要求されるのである。一人で働くキッチンに機械やロボットを入れても、あまり引き合わない。しかし1日1万食作るセントラル・キッチンなら、話は別だろう。レストラン・チェーンなら、料理メニューの数だって一応、限りがある。

「え、ロボットが作った料理？　美味しそう！　すぐ食べてみたい」と思うお客さんが、どれだけいるのかは知らない。だが量がさばければ、可能な自動化の選択肢も増える。

たとえば、バッチ処理・ロット処理を連続生産化する、というのはよくある方法だ。鍋で煮込むとか、パンを窯で焼くとかいった加熱調理のほとんどは、バッチ処理である。しかし、コンベヤに乗ったパン種が、長いオーブンのトンネルを抜けると、ほかほかのパンに焼き上がって出てくる、といった光景は想像がつくと思う。まあチキンカレーを煮込むのは、コンベヤや配管ではやりにくいので、おそらく大型の鍋を並べることになるだろうが。

生産の量的拡大に伴って、生産の方法や仕組みや機械設備を考えて実装する仕事を、『スケールアップ』とよぶ。ITの世界では「スケールアウト」という言葉を使うが、製造業の世界ではもっと以前から、スケールアップと呼ばれてきた。そして、わたしの勤務先のようなエンジニアリング会社とは、じつはこのスケールアップを得意技術とする業種なのである。

ところで、大規模セントラル・キッチンで肝心のロボットは、どう働いていくのだろうか？　煮込みは圧力鍋、揚げ物はフライヤー、焼き物はグリル装置の仕事だ。・・とすると、ロボットができるのは、材料をセットしたり、取り出したり運んだりする、マテリアル・ハンドリングだけ、ということになりそうだ。製造とは、材料を加工・変形・変容させて製品に変えていく仕事で、そこに付加価値がある。だが、モノを運ぶだけの作業は、必要かもしれないが付加価値はほとんどない。

つまり、ロボット自体は付加価値を伴う『正味作業時間』に貢献しない存在なのだ。まあ溶接ロボットみたいな種類は別だが。レストランなら、盛り付け、配膳、そして会計などのテーブルサービスはいいだろう。だが本当の料理・調味・下ごしらえには貢献しない。

そしてAIは？　もちろん、サンプルデータ数が数万になれば、機械学習も役に立つ。だが繰り返すが、料理は美味しく食べられてナンボなのだ。試行錯誤には向かない。

製造作業の自動化とは、AIやロボットの導入ではない。この事をわたしは、声を大にして言いたい。なぜなら、こういう表層的な勘違いをしている人が、世間にはごまんといるからだ。本社で働くホワイトカラー達も、現場を見ない経営層も、経済評論家も、メディア記者も学者も、高学歴なコンサルタント達も、文系理系にかかわらず、大いに勘違いをしている。製造現場についての洞察が足りないのだ。

キッチンに入って、半日も料理してみれば分かることを、この人達はついぞ思い至らないらしい。現場への理解と共感の欠如。まさにそれがわたし達の社会の、生産性不足と競争力低下を生んでいる根源なのに。

＜関連エントリ＞

「製造作業を自動化するために必要なデータとは」 https://brevis.exblog.jp/33521355/ (2025-02-15)

製造作業を自動化するために必要なデータとは

• カレーの作り方

『スパイスカレー』という言葉は、2000年頃から使われるようになったらしい。昔の昭和風のカレーライスは、具材を水で煮て、そこにカレー粉と小麦をベースにしたルーを加えて作った（「ライスカレー」という言い方もあったなあ）。これに対してスパイスカレーは、自分で配合したスパイス群を使い、水を使わず、しかもサラサラ感のある仕上がりになる。より、本場のインド風に近い料理だ。

わたし自身も、スパイスカレーという言葉がはやるずっと前に、米国でインド人の奥さんに教えてもらって以来、繰返し自分で作ってきた。カルダモン、ターメリック、クミン、コリアンダー・・といったスパイス類（粉ではなくホール=粒状のもの）も、昔は都心のデパートや外人向け高級スーパーでないと手に入らなかったが、最近は最寄りの店で買えるようになった。

作り方の概略をざっと記すと、次のようになる：

(0) スパイス類をフライパンでゆっくり煎ってから、乳鉢でひいて潰す

(1) フライパンに油をひいて、細切りの玉ねぎ、クミンシード、ニンニク、唐辛子を入れて、弱火で炒める

(2) これを鍋に移して中火で加熱し、鶏肉を入れてさっと炒める。さらに潰したトマトをいれ、沸騰したら、塩と(0)のスパイス群を加える。水は使わない。もしジャガイモや人参を入れたかったら（わたしは入れないが）、ここで投入する。

(3) 弱火でじっくり煮込む。カレーは時間が大事。それで味や香りが渾然となじむ。

分量をあえて書かなかったのは、全て目分量だからだ（笑）。途中で味見して、必要なら調整する。量も温度も、炒め方や加熱の時間も、自分が体で覚えている。

• 製造作業の記述とは

さて、個人用のメモならこれでいいが、自分でもスパイスカレーを作ってみよう、と思った読者の方には、いささか不便だろう。

なんらかの作業を人にやってもらおうと思ったら、ちゃんと伝わるように、作業に再現性のある書き方が必要だ。つまり、体で覚えている「暗黙知」を、「形式知」化することが求められる。はんちくなコンサルなら、ここで『SEKIモデル』とかの話をしてカッコつけるのだろうが、そんな脇道は省略して先に進もう。

まず、当たり前だが、材料の正確な分量の記述が必要である。カレーを（仮に）4人前作るとすると、鶏肉600g、トマト3個、ターメリック大さじ2・・といった具合だ。つまり、最終製品に対する構成品目と数量の表で、これをBOM＝部品表と呼ぶのは、当サイトの読者なら、とうにご存じだろう。製造作業の記述には、まずBOMがいる。

次に必要なのは、手順の記述である。「カレー作り」という製造工程は、上述するように4つくらいのステップからなる。それぞれのステップ、つまり最小の業務単位を、『作業』Operationと呼ぶことにする。その工程は、どのような作業からなっており、どの順番でそれを行うのか、の記述が求められる。

その上で、各作業で必要とする、『製造資源』Manufacturing resourceを規定する。製造資源とは、製造作業に使うけれども、材料と違い、作業が終わっても消費されずに残り、（洗ったり多少の修復作業はいるだろうが）別の作業に使えるような、再利用可能な道具を指す（英語では労働力はHuman resourceなので、要員もふつう含む）。

上記ステップ(1)の作業ならば、作業者（1名）、中型フライパン（1つ）、ガスコンロ小（1口）、フライ返し（1本）、といったところだ。これが工場ならば、作業者、金型、機械、工具などが並ぶことになる。逆に言うと、作業Operationとは、1セットの製造資源を占有する単位で区切るべき、ということになる。

• SOP（標準作業手順）とRouting（工順）の概念

さて、これだけで十分だろうか？　そうではあるまい。それぞれの作業において、火加減とか加熱時間といった、製造条件ないし製造仕様の記述が必要だ。そして、目視・味見・手応え等、簡易なチェック項目と、次の作業に進んでいいかどうかを決める合格基準もほしい。

つまり、1つの作業に付随して、様々な設定やらチェックやら、より細かな手順がある。こうした事を記述するのが、SOP（Standard Operation Procesure）＝『標準作業手順』と呼ばれる情報である。さらに言うならば、実際のチェック結果はどうだったのか、記録できるともっと望ましい。後から確認できるからだ。

製造における一つの工程とは、こうした各作業と、それに付随する製造資源・SOPのセットを、直線的に順に並べた集合から構成されている。これを英語で、Routing（ルーティング）と呼ぶ。

Routingはふつう『工順』と訳されてきて、当サイトもこの用語にしたがってきた。ただ、工順という言い方は、複数作業の集合のことを指す場合と、その中での単純な順番を指す場合があって、いささか誤解を招きやすい。これをきらって、あえて「行程」と呼ぶ人もいる。だがこちらは、「工程」と同じ音だから、別の意味で混乱しやすい。もっと良い訳語があればと、いつも思っている。

なお、各作業の中間には、製造の途上の中間品が存在する。これは材料とも最終品目とも異なるモノだ。ただ、製造作業の途上でいったん生じるが、全量がすぐに消費されるモノは『ファントム』とよび、マテリアル・マスタやBOMにはふつう登録しないのが習慣である。

• 製造作業を自動化するために必要な基準データとは

以上をまとめると、図のようになる。親品目のスパイスカレーと、子品目の材料a群・材料b群を結ぶ、一連の作業と付随する製造資源・SOPのセットである。

製造作業を自動化するためには、つまり仕事を機械にやらせるには、これらを文章記述ではなく、デジタル・データ化しなければならない。じゃあ、これをRDBで表現するにはどんなデータ構造にして、どうE-R図に表現するのがいいか、データ・モデリングの心得のある方はぜひ、考えてみていただきたい。
ともあれ、誰か不慣れな人間でも、ちゃんとスパイスカレーを作れるようにするためには、こうしたデータ項目にもとづいて、UI経由で指示を出せるようにしなければならない。さらにできれば、実績も入力できることが望ましい。こうした機能を提供するのが、『製造実行システム』MES = Manufacturing Execution Systemなのである。
以前の記事にも書いたことだが、ERP（基幹業務）システムと、生産管理システムと、製造実行システムMESは、その主たる目的が異なる。部品調達や製品販売などを受け持つERPは、主にコストをコントロールする。生産管理システムは、主に納期と在庫を采配する。では、MESは？　
MESは、詳細な作業と手順と仕様を通して、ある意味で、「正しく作ること」＝すなわち品質を見ているのだ。再現性とは、製造品質の別名でもある。
そしてMESを支える基準情報（マスタ・データ）は、作業と手順（Method）、品目（Material）、作業者（HuMan）、製造資源（Machine）の、いわゆる4Mを記述している。製造の自動化のためには、いや、人の作業一般を自動化するためには、こうした4Mの形式知化が必要なのである。

＜関連エントリ＞
「製造業のトリレンマ・QCDを決めるのは誰か」 https://brevis.exblog.jp/33340696/ (2024-11-19)