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

MESはむしろ品質のためにある(+経営工学会シンポジウムのご案内)

  • サイトのカテゴリー分類について

当サイトの以前からの読者はお気づきかもしれないが、最近、記事のカテゴリー分けを見直した。「A 生産マネジメントとSCM」「B プロジェクト・マネジメント」「C システムとしての工場」「D 情報システムのマネジメント」「E ビジネス・マネジメントと管理技術」「F 考えるヒント」「G 書評」の、実質7カテゴリー・23分類に詳細化したのである。これで、話題の広がりが見通せると同時に、関連記事が少しは見つけやすくなっただろう、と信じる。

そう言いながら、自分の記事の分類に自分で悩むことも結構ある。例えば今から書こうとしている本記事にも、その一つだ。なぜなら、2種類のトピックに関して、その関連性を考えようという記事だからだ。2種類のテーマとは、 次世代スマート工場の必須の道具であるMESと、製造における重要なKPIである『品質』のことである。前者には、カテゴリーC2「スマート工場」があるし、後者はカテゴリーA4「コスト・品質・安全」に属する。

今回はそれでも、後者のカテゴリーA4に分類しようと思う。 なぜなら、品質について改めて考え直してみたいからである。


  • 品質偽装の蔓延と、その原因

こんなことをネットで書くべきではないのかもしれないが、最近気になることをある製造業に詳しい知り合いの法務専門家から聞いた。この方によると、品質偽装はかなり多くの企業で起きていて、もはやそれを前提に色々と対策を考えざるを得ない、という。 かつての品質大国ニッポンは風前の灯だ、とのことだ。

たしかにちょっと振りかえってみても、数多くの偽装問題が新聞を賑わせた。たとえば:

  • D工業(自動車メーカー)による道路運送車両法の認証不正問題(1989年頃〜/2024年問題化)
  • K重工業による海上自衛隊向け潜水艦のディーゼルエンジンの燃費・性能データ偽造(1988〜2021/2025年問題化)
  • Pインダストリー(電子材料事業)で、複数種類の半導体材料・電子部品関連の材料データにおける改ざん・認証関連不備(2000年代後半〜/2024年問題化)
  • K製鋼所によるアルミ・銅・鉄鋼製品などの強度・耐久性データ偽造(1970年代後半?〜/2017年問題化)

・・などなど。どれも防衛・鉄道・自動車・半導体など社会の基幹インフラに関わる事案で、なおかつ人も知る(社会的信用もあるはずの)大企業によって行われていた。なお、新聞沙汰になったのだから実名を書いてもいいのだが、個別企業の経営批評が目的ではないので伏せ字にしておこう。


  • なぜ品質偽装が表に出てきたのか

偽装のはじまりが1980年代の終わり頃、つまり高度成長が終わったバブル時代くらいにまでさかのぼるケースも多い。偽装は近年に始まった話ではないのだ。ただ、それが近年になって発覚した事例が多い。なぜだろうか? 内部告発等があったにせよ、ではなぜ、長い間だれも声を上げずにきて、急に最近増えたのか、疑問が残る。

え? コーポレート・ガバナンスが浸透したから? 金融庁関係者ならそう思うかもしれないが、どうだろう。だったら架空取引とか売上偽装事案だって、もっと出てきてもいいはずではないか。なぜ品質偽装ばかりが多いのか。

そこには二つの要因があるのではないかと、わたしは推測している。すなわち人手不足と、製造現場へのデジタル技術の浸透である。これらはまさに、コロナ禍の時代に前後して、製造業に共通して進んだ事象だ。人手不足は、熟練工の引退と若手の採用難、そして派遣労働者への依存と歩を合わせて進んだ。若手や中堅の転職も増えている。偽装には、その秘密を守れる仲間意識が必要だ。だが、自分は職場と運命共同体という感覚を、次第に持てなくなってきている訳である。

そしてもう一つが、現場のデジタル化である。従来は、生産管理システムがあっても、現場の差配は紙の帳票ベースが主体だった。ところが、ITは生産管理から現場の製造管理までおりてきた。それがMESである。現場の検査機や製造装置の数値を、そのままI/F経由で読み取ってデジタル製造記録に残すのが、MESの主要な役目だ。そうなるとMESの検討段階で、「おい・・やばいなこれ、どうすんだ?」という内緒の会話が始まるのである。


  • MESとは品質保証のシステムである

そもそも、なぜ品質偽装なのか。それは簡単に言うと、QCDのしわ寄せが現場に来た結果である。製造業の三つの主要指標、QCDはトリレンマの関係にある。トリレンマは三すくみ、つまり他の2つに影響を与えずに1つだけいじることができない関係を表す。コストを下げたら、品質か納期に影響が出る。納期を早めたら、品質かコストにしわ寄せが来る。

ところで、製造業では誰がその三つを決めるのか。実は、別の部門が決めるのだ。図は以前、「製造業のトリレンマ・QCDを決めるのは誰か」(2024-11-19)にあげたものの再掲である。コストはそもそも、製品設計や工程設計や調達など、製造に入る前の段階で(多くは本社で)、大半が決まってしまう。納期は、生産管理業務を受け持つ工場の製造マネジメント層(中二階)が決める。そして製造品質は、現場が作り込む。でも、会社の力関係は、本社>マネジメント>現場、となりがちだ。だから、コスト>納期>品質、の順にしわ寄せがくるのである。

MESはむしろ品質のためにある(+経営工学会シンポジウムのご案内)_e0058447_20145690.png
MESとは製造管理システムともよばれるように、主に現場の業務を支える。それもふつうは、製造指図が上位系のERP/生産管理システムから下りてきた所が起点となる。MESは詳細な手順を現場の作業員に表示し、あるいは物品にバーコードラベルやRFIDを発行してロット識別し、機械と通信I/F経由で指示値や実績値をやりとりする。
作業者が間違えてロットを投入しないよう、ラベル照合したり、機械に応じた設定条件を通信で送ったりといった、いわゆる「ポカよけ」は、MESの得意分野である。正しい標準作業手順SOPにしたがって、モノづくりをするようガイドする。つまりMESとは、納期を司る生産管理よりも、品質を保証する役割の方が強いのだ。


  • スマート工場とMESの役割とは

スマート工場とはMESを活用する工場である」 と、わたしは言い続けてきた。単なる機械単位・工程単位のデジタル化・IoT化も結構だけれども、工場全体が賢さを得なければ、本当の意味で製造業の問題解決にならない。そのためには、まずMESが必要だ、と。だから部分的なスマート化と区別したくて、あえて「次世代スマート工場」という言い方を選んできた。そのポイントは、工場レベルでの賢さの実現である。そして「賢さ」には、偽装のような悪だくみに陥らない、という意味もこもっている。

誰だって、やりたくて偽装をやってるのではない、と思う。最初は誰かがやむなく命じ、時間がたつと次第に職場の「習慣」となっていく。だが、やる当人は気持ちのいいものではない。少なくとも、自分の子どもに向かって、胸をはって話したい事ではない。働く人が、働くモチベーションを失ったら、良い製品ができるはずがないではないか。それは「賢さ」とはほど遠い。

今こそ、「なぜスマート工場なのか」を議論すべき時なのだと信じる。たまたまちょうど、信頼する研究会仲間である松本卓夫氏から、経営工学会が主催する、次世代スマート工場に関するシンポジウムの案内を頂戴した。内容は下記の通りである。

テーマ:「次世代スマート工場の運営と管理を考える
日時:3月14日(土)13:00〜17:00
場所:青山学院大学(青山キャンパス17号館17810教室)。オンラインあり
費用:無料

ちなみにエンジニアリング協会の「次世代スマート工場研究会」からは、太田裕文氏が工場物理学(Factory Physics)について講演される予定だ。また神奈川大学からはリチウム電池再利用のビジネスモデルの提案、大手自動車部品メーカーからは労働集約型工場の海外・日本での運営について、講演が予定されている、という。

あいにく日程の関係から、わたし個人はオンラインで部分的に視聴するだけだが、こういった場でぜひ、製造業のあるべき姿と、現状の悩みについてディスカッションすべきだ、と思う。ちゃんと議論できないこと。それこそが、今のわたし達の社会の、一番根底の問題なのだから。

<関連エントリ>

# by Tomoichi_Sato | 2026-02-16 19:56 | A4 コスト・品質・安全 | Comments(0)

ふつうの会社のためのプロジェクト・マネジメントとは ~ モダンじゃないPMの特徴

  • なぜ、わたしはPMPの維持をやめたのか

2017年の秋、わたしはシカゴで開催された『PMI Global Conference』に参加した。自分の研究成果を講演発表するためだ。テーマは、"Decision making with Risk-based Project Value (RPV) analysis and activities’ value contributions"。それまで10年以上にわたって続けてきた、リスク確率に基づくプロジェクト・マネジメントの手法論を簡潔にまとめたものだった。

考えてみると、PM関連の国際カンファレンスには、これ以来、参加していない(まあ、GAPPS Initiative のこぢんまりしたオンライン会合は別として)。2000年代の初め頃は、米国でも欧州でも、PMの国際大会への参加は楽しかった。新しい理論や手法の提案も多く、活気に満ちていた。だがシカゴでは、なぜかもはや、そうした興奮に浸ることはできなかった。ちなみに日本からの発表者は、わたし一人だった。

わたしは独立研究者である。PM研究は、わたしの勤務先の仕事ではない。上記PMI Global Conferenceには、渡航費も参加費も自費で負担した。だから気持ちが高揚できない大会には、それ以上行く気になれない。

わたしはその後、PMPの資格維持もやめてしまった。気がついたらコロナ禍の間に、更新期限が来ていたのを忘れていたのだった。うかつな話だ。だが維持にはお金も時間もかかる。日本で名刺にPMPと書くことに、どれだけの値打ちがあるのか。PMPとは、モダンPMを理解して使える能力を証明する資格のはずだ。だがPMI自身が、PMBOK Guideの第7版で大きな方針変更をはかろうと、右往左往していた時期だった。


  • モダンPMの特徴とは

1年ほど前から、本サイトに「モダンPMへの誘い」というシリーズを、断続的に書いている。モダンPMの最大の特徴は、専門的・計量的なマネジメント技術であることだ。 プロジェクト階層的に細分化してWBSを作り、ロジック・ネットワークを構築してクリティカル・パスを同定し、EVMSで進捗とコストをコントロールする。 結果は数字で表され、精度の良い予測が可能になる。

このような技術は、大規模で、コストやスケジュール制約の厳しいプロジェクトの方法論として、優れている。だから、どのような分野であれ、大規模なプロジェクトのマネジメントに適用可能だし、 必要だ。わたしのかつての部下の1人は、プラント建設のプロジェクトに従事していたが、結婚して米国にわたり、バイオ医薬品企業や、Googleのデータセンター建設プロジェクトなどに携わっている。それでも通用する。それがモダンPMだ。

ところで、このようなモダンPMの手法が 適用できるのは、主にスコープが「ハード」で明確である場合だ。 プロジェクトの任務がふわふわしていて、何を作り、どこまで行ったら終わりなのか、見定めることが難しいようなケースでは、あまりうまく使えない。最初にかっちりした計画もWBSも作れないからだ。

そしてPMI自身、しだいにPMBOK Guide第6版までのPM論への確信に揺らぎが出てきた。その理由の一つは、PMIの参加メンバーに IT系の人材が増え、マジョリティになったからではないかと推察している。ITプロジェクトでは、スコープが最初に十分確定していないことが多い。だから、アジャイル開発のような方法論が有効性を持つのだ。


  • プロジェクト型の企業と、ふつうの企業

PMBOK Guideの最初の基礎を90年代の初めに作ったのは、航空宇宙産業とエンジニアリング産業の人たちだったと聞いている。この人達の仕事は、航空機とかロケットとかプラントなど、典型的にハードなスコープの受注型プロジェクトだった。そして、こうした業界の企業はプロジェクト型だ。つまり、ビジネスの中心が受注型プロジェクトなのである。わたしの勤務先では(同業他社もそうだが)、全ての仕事が、プロジェクト受注番号に紐付く形でコントロールされる。

しかし、そういう会社は少数派だ。通常の会社は、定常業務がビジネスの中心である。多くの製造業も、サービス業も、流通業も金融業も、そうだ。定常業務の中に、まれにプロジェクト的な仕事がある形だろう。

もちろん中間型を考えても良い。たとえば、繰返し型業務がメインだが、時折、大型の受注型プロジェクトがある重工メーカーなどがそれだ。運用保守がメインだが、時折、それなりの開発プロジェクトが入る情報子会社などもこのカテゴリーに入る。

(A)プロジェクト型企業、(B)定常業務型企業、(C)中間型、とかりに分類したとき、動くプロジェクトの性格は少しずつ異なる。(A)では規模の大小はあれど、受注型でコスト・納期制約の強いプロジェクトが中心だ。とくに大規模ハード系のプロジェクトなら、まさにモダンPMがフィットする。


  • ふつうの会社のための、プロジェクト・マネジメント論が必要

しかし、プロジェクト型企業は、産業界全体で言えば少数派だ。定常業務中心の、つまり(B)に属する製造業やサービス企業の方がずっと多い。では、こうしたふつうの企業における、プロジェクトの取り組みはどんなものか? それはたとえば、重要な製品開発(小手先の模様替えではないもの)、新工場づくり、新事業展開などで、いずれも自発型プロジェクトだ。

こうした自発型プロジェクトは、ふつうの会社にとって、競争と発展のための部門横断的な取り組みである。その目的は、「新しい能力の獲得」にある。新製品による競争能力、新工場による生産能力、新事業による市場開拓能力、などだ。ただ、その青写真は最初から明確とは限らない。スコープが「ソフト」なのだ。

(C)中間型として重工メーカーの例をさきに挙げたが、個別受注生産の製造業でも、多くの案件は部門間のバトンリレーで処理され、プロジェクトとしては扱われない。ただかなり大型の案件となると、誰かが責任を持って調整する必要が出てくる。それが本来はプロマネ役なのだが、「プロジェクト」という認識と、それに必要な体制・権限が曖昧な場合もある。

結局、プロジェクト型ではない普通の企業における問題とは、プロジェクトが「プロジェクト」として認知されていないところと、スコープが柔らかい点にある。プロジェクトと認識されていないのだから、プロジェクト・マネジメントの方法論などを期待しようがない。そういった企業に、精緻で定量的なモダンPMの技術を持ってきても、スコープの柔らかさのために役立たない。


  • プロジェクト・マネジメント能力の発展段階

「ふつうの企業」では、ほとんどが機能型組織の形態をとっている。部門が営業、設計、購買など専門的機能ごとに分かれている。プロジェクトは部門横断的な取り組みだが、プロマネの役割と権限が曖昧な「弱いマトリクス型組織」では、うまくプロジェクトを進められない。全体を見てコストや納期をタイムリーに決断する、意思決定の仕組みが欠けているからだ。

これこそが、日本の製造業が過去30年間の間、競争力を落としてきた原因の一つだと、わたしは考えている。なぜなら、製品開発や事業開発の取り組みが、スピーディーにうまく回らないからだ。そのために必要なのは、モダンPMとかEVMS以前の、基礎的な仕組みや人財側の能力であろう。

とくに、柔らかい(ソフトな)スコープの中で、どう意識決定し、どのように価値あるアウトカムを創出していくかが、問われる。ちなみにモダンPMが得意なはずの(A)型の企業だって、自社内で行う自発型プロジェクトは、必ずしも上手ではない。マネジメントの観点が違うからだ。

ふつうの会社にとって、プロジェクト・マネジメント能力の発展段階はこんな風なステップになるのではないか。

レベル1:「プロジェクト」を認知し「定常業務」との違いを理解する
レベル2:プロジェクト遂行に必要な組織・役割・権限・ツール類を整備し、、キーパーソン層のソフトスキルを高める
レベル3:プロジェクト・マネージャー職種を確立し、マネジメント技術を獲得・蓄積する(企業文化の中に組み入れる)

わたしのような外部コンサルタントは、レベル2・3のお手伝いはできる。しかし最初の1は、経営層の「気づき」が必要だ。自分の真の「ニーズ」を知ってはじめて、学びのステップを登ろう、との気持ちが起きるからだ。それがたとえ、失敗のペインを通した気づきであっても、学びのニーズこそ、組織と人を育てる原動力なのだから。

ふつうの会社のためのプロジェクト・マネジメントとは ~ モダンじゃないPMの特徴_e0058447_22332236.png

<関連エントリ>

# by Tomoichi_Sato | 2026-02-08 22:36 | B1 プロジェクト・マネジメント全般 | Comments(0)

モダンPMへの誘い 〜 プロジェクトのActivity間には4種類の依存関係がある

  • プロジェクトのクリティカル・パスとロジック・ネットワーク

プロジェクトの全体工期の長さを決めるクリティカル・パスとは、そのプロジェクトを構成するActivityからなるロジック・ネットワークにおいて、開始点から完了点までを結ぶ種々の経路の中で、最長の経路を指す。プロジェクトの工期を短くしようとしても、クリティカル・パスが「つっかい棒」のように邪魔をして、それ以上短縮できないからである。そしてロジック・ネットワークとは何かというと、プロジェクトを構成する全てのActivityを、お互いの先行→後続の依存関係にしたがってつなげて表示した、有向グラフである。

プロジェクトをActivityのネットワークとして理解する、という概念は20世紀の半ばに、アメリカ人達がはじめた。1950年代のことで、プラント建設プロジェクトにとりくむ化学企業デュポン社のエンジニアと、ポラリス・ミサイルの開発プロジェクトに携わった海軍のコンサルタント、ブーズ・アレン・ハミルトン社の人びとであった。クリティカル・パス概念自体は、デュポンで生まれた。そして、プロジェクトをこのような「要素的作業=Activityのネットワーク」としてのシステムと理解し、そのシステム工学的な性質をとらえ、数値的にマネジメントしよう、という発想が、『モダンPM』の始まりだった。

その後、クリティカル・パスの計算手法が発達するとともに、プロジェクトのより具体的な構成や制約条件も、取り込みたいとのニーズが高まった。たとえば初期には、Activityの間には、「先行」→「後続」という直列的な依存関係しか考えられていなかった。しかし現在は、依存関係には4種類がある、と考えられるようになっている。

4種類とは、先行と後続それぞれのActivityに、開始(Start)と完了(Finish)があるので、かけ算で4つのバリエーションが生まれることを指す。すなわち、以下の4種類だ。
1. Finish to start (略称FS)
2. Start to start (略称SS)
3. Finish to finish (略称FF)
4. Start to finish (略称SF)
モダンPMへの誘い 〜 プロジェクトのActivity間には4種類の依存関係がある_e0058447_19075803.png

  • FS型・SS型・FF型の依存関係

さて、Activity間の4種類の依存関係のうち、最もベーシックで、実務でも最も多く使われるのがFinish to start (FS)である。先行Activityが完了したら、後続Activityが開始できる。設計が完了したら、実装が開始できる。資機材の調達が完了したら(=入荷したら)、据付作業が開始できる。例の枚挙にはいとまがない。資機材が入荷もしていないのに、据付ができる訳がない。設計も終わっていないのに、作り始めるのは愚かである。これは分かりやすい。

Start to start (SS)とは、どんな依存関係か。それは、先行Activityが開始したら、後続も開始できるという関係だ。ただ通常は、この二つのStart日時の間に、一定の期間が挟まる。これを英語ではLagと呼ぶ。

たとえば、家やマンションの塗装工事を考えよう。塗装は普通、下塗りと上塗りの2工程からなっている(場合によっては中塗りを入れて3工程)。下塗りをしたら、それが乾燥する(落ち着く)まで一定の時間がかかる。それを待ってから、本塗りをする。だが、下塗りを建物全体に行って、それが全部乾いてから、上塗りを開始するかというと、そんなことはしない。たとえば1階部分の下塗りが乾いたら、そこの上塗りを開始する。同時に、まだ2階や3階の下塗り作業が続いているかもしれない。だが一定の日数をはさめば、下塗りと上塗りの2つのActivityは並行して進めるのだ。こういうときに、Start to start (SS)の依存関係を使う。

では逆に、Finish to finish (FF)を使うのは、どんな場合か。たとえば設計書を作成するActivityと、そのレビューを行うActivityなどがその例だ。設計書が多数ある場合、レビューはできたものから順次着手して、並行して進む。しかし設計書が全部完成しないうちに、レビューだけ勝手に完了できる訳がない。最後の部分のレビューに必要な期間が、Lag日数になる。


  • SF型の依存関係の、本当の意味

ところで、最後のSatrt to finish(SF)型とは、どんな依存関係だろうか。先行Activityが開始しないと、後続Activityが完了できない? なんだそりゃ? こんな関係、意味が分からん。

ということで、これは理屈だけのもので、現実には意味がないと考える人も、ときどきいる。事実、実務でもまあ、たまにしか使わない。だが、使うときはあるのだ。それは、どんなケースか?

実は、上のような図は、ミスリーディングなのだ。本当はSF型は下のように理解すべきである。
モダンPMへの誘い 〜 プロジェクトのActivity間には4種類の依存関係がある_e0058447_19092056.png
すなわちSF型依存関係とは、「後続Activityがスタートしたら、先行Activityを完了できる」というケースなのである。英語のtoという語は、ここでは時間的な前後関係ではなく、論理的な依存関係を示している。たとえば、システム移行に伴って、旧型システムの運用は、新型システムの運用が開始したら、終了できる。後続の開始が遅れたら、先行Activityの期間も伸びてしまう。後続が開始しない限り、先行は完了できないという関係を、SF型は意味しているのだ。

ということで、Activity間の依存関係はやはり、4種類必要なのである。クリティカル・パスをベースにしたスケジューリング・ソフトウェアも、これら4種類の関係を定義できる機能を取り込むようになった。その種のソフトの代表格が、普及価格で手に入るMicrosoft Projectと、プロ用のツールであるPrimavera Project Planner(通称P6)である。

プロジェクト・スケジューリング・ソフトを導入すると、なんとなく自分たちもすぐに、プロジェクトをうまくマネージできるような気分になる(ソリューションの売り手側も、そういう気分を盛り上げて、販売促進をするわけである)。でも、4種類の依存関係をちゃんと理解して使いこなせるようになるまでは、まだ習熟の期間が必要だ。ソフトの導入完了と、実務の運用能力アップの開始には、だからFinish to Startの関係の上に、Lag日数があるのである。


<関連エントリ>

# by Tomoichi_Sato | 2026-01-31 19:14 | B3 プロジェクト・スケジューリング | Comments(0)

本を読む事、本を最後まで読むこと(+ 書評:「ペスト」 A・カミュ著)

  • わたしにとって読書とは

昨年(2025年)、ちょうど20冊本を読んだ。わたしが「本を読んだ」というときは、本を最初から最後まで、全ページ読んだ、という意味で使っている。一部の頁を読んだだけの時は、「見た」ということにしている。見た本はもちろん、もっと多い。だが、読み通すつもりのものが、ほとんどだ。辞書や一部の規格書・法律書など例外はあるが、基本的に読み通すつもりで、本は買う。

月2冊程度だから、わたしは決して読書家ではない。学生の頃は年に100冊程度読んでいたが、働いて、家庭生活も持つと、読書時間は削らざるを得ない。わたしの主な読書タイムは電車の中である。しかし最寄り駅から勤務先まで3駅・10分足らずだし、外出や出張時には寝落ちしていることが多くて(汗)、ちっともはかどらない。

わたしにとって読書は、仕事ではなく勉強でもなく、趣味である。自分ではビジネス書を書いているくせに、ビジネス書はほとんど読まない。仕事から離れたら、仕事以外のことを考えたいからだ。小説もあまり、読まない。自分はあまり、物語を好むタイプでは、ないらしい。物語が好きな人は、小説だけでなく、経営書にも物語を読み取り、スポーツにもドラマを感じるのだろう。感情的価値を、欲しているのだ。わたしはむしろ、知る喜びの方が、面白い。

  • なぜ読み通すことが大切か

本を読み通すのには、時間がかかる。近頃は有名書ならネットでサマリーを見ることができるし、あまり大部でなければ生成AIに要約してもらうことだって可能だ。しかし、わたしはそうしない。自分の本、たとえば「BOM/部品表入門」でも「時間管理術」でもいいが、そういう風に読まれるのを好まないからだ。

書いている立場から言わせてもらえるなら、あれだけの長さと厚みになるのは、相応のロジックの流れと対話(=多面的な検討)の積み重ねが必要だからだ。それをすっ飛ばしたら、肝心のメッセージがよく理解できなくなる。よく理解できなければ、結局、自分の身について使えなくなる。読書前と読書後で、自分が何も変わらないなら、読書は知的消費ではあっても、知的投資(学び)ではないことになる。知的消費にしたって、小説がそれなりの長さなのは、そうしないと表現できないことがあるからだ。

どれほど短い時間で、知識と情報を得られるか、そのタイパを追求するのが今の流れらしい。知識は資産である。また、人より先に「知ってる」と、自己承認欲求も満足できる。しかし、「知ること」と「理解すること」の間には、大きな距離がある。

人は知識と記憶力だけでは、賢くならない。複雑な社会で物事を判断するためには、構造を洞察し予測する力が、とても大切だ。またリーダーシップを発揮して人を動かしたかったら、他人の見方考え方を知る必要がある。こうした能力を得るためには、知的時間がいるのだ。それも、それなりの長さと深さで。読書はそのための、大事な階(きざはし)だ。


  • 長い文脈を理解する能力を得よう

また知的消費(別に消費はわるいことではない)の面を考えても、深い感情的体験には没入の時間、文脈の共有が必要である。長い文脈を、感情とともに体験し保持できる力。それは今のところ、普通の人間でも生成AIに決して負けずに持つ、知的能力の一つなのだ。

せっかくそうした能力があるのに、切れ切れな知識情報ばかりを相手取って過ごしたら、どうなるか。いつの間にか、流れてくる情報に踊らされ、巻き込まれて搾取される側になる事だって、ありうるだろう。

何年か前、ある著者の方が、有名な書評ブロガーに会った際の話を読んだ。そのブロガーさんは、進呈された本をパラパラと15分ほど目を通した後、さっそくブログに書評をアップしたのだそうだ。そういう芸風なのだろう。だが、そのまねは自分にはできない。わたしは基本的に、書評は全頁を読んだ本しか、書かないことにしている。本は最後まで読むこと。それが、零細ながら著者でもあり読者でもある、自分の信条なのだ。

ということで、今回は近年読んだ小説の中でも最良の一作、カミュの「ペスト」の書評をかかげることにしよう。


書評:「ペスト」 アルベール・カミュ著

ペスト」(新潮文庫版 Amazon.com)

本を読む事、本を最後まで読むこと(+ 書評:「ペスト」 A・カミュ著)_e0058447_19471616.png
本書を最初に読んだのは20年以上も前のことだったと思う。その時は、「重厚なSFだな」という感想をメモに残しているが、それ以上のことはなぜか、記憶に残らなかった。

この小説を「SF」と分類する人はまず、いない。ノーベル文学賞作家アルベール・カミュによる純文学だ、と位置づけれらているからだろう。でも、思索上は可能だが、現実にはありそうもないと誰もが思うシチュエーションを、想像力をもとに科学的知識も加えてストーリー化し、その中で人間性の本質を描き出すのがSFだ。だとしたら、まさに直球ど真ん中の小説ではないか。

物語は、北アフリカ・アルジェリアの地方都市オランで起きる。まだフランスの植民地だった時代だ。その街で、死んだ鼠が次々と見つかるようになる。そして、それを追うように、高熱で苦しむ患者が少しずつ増えていく。主人公の医師リウーが、最初の患者の死を看取るまで、わずか20頁あまり。押さえた筆致ながらぐいぐいと読者を引き込んでいく。

街の医師達は、蔓延しつつある疫病がペストである、ということをなかなか認めようとはしない。だが政府(総督府)は電光石火、街を封鎖する。疫病と都市封鎖。これが西欧では歴史的にワンセットだという事が分かる。そして外部との交通も通信も事実上遮断され、その日を境に、家族や友人や恋人も突然分断されて、人びとのドラマはにわかに深刻化する。

この小説には重要な登場人物として、バヌルー神父という宗教者が登場する。彼は最初、この疫病は神が人間の目を覚まさせようと与えた劫罰なのだ、と教壇から信徒達に説教する。しかしその後、疫病の最前線で患者達を、彼なりに助けて回ろうとすようになる。

著者のカミュは神を信じない人間だ。それはフランス的社会の中では、キリスト教会とその権威に反対する、という意味である。だから、この登場人物のフェアな扱い方とその悲劇を通して、最も重要な問いを提出する。主人公の友人がこう言うのだ。「人は神によらずして聖者になりうるか——これが、僕の知っている唯一の具体的な問題だ」(P.307)

政府の助けも、神の助けも、そして緊急輸入した血清医学の助けも十分に得られぬまま、それでも街の人びとは保険隊を結成し、医師リウーを中心に団結して、可能な限り疫病と闘い続ける。

この小説は第二次世界大戦の終結直後、1947年に発刊され、瞬く間にベストセラーになった。「人間を絶滅させる悪との闘争を描く」と背表紙の解説にあるが、人びとは何年間も世界を覆い尽くし分断した戦争の災厄と、ペストとを重ね合わせて読んだだろう。

わたし達はあの世界的規模のパンデミック禍、恐ろしくも奇妙な「新型コロナウイルスに閉ざされた数年間」を経験した。今や人びとは、まるで何事もなかったかのような顔をしている。だが、いかに忘れたふりをしようとも、決して忘れられぬ、息の詰まる時間だった。それをわたし達は、団結して乗りこえたと言えるのだろうか。次にまた災厄が襲ってきたとき、連帯して互いに助け合えるような賢さと勇気を、わたし達は本当に発揮することができるのだろうか? ちょうどこの小説の中で、港町オランの人びとが示したように。


# by Tomoichi_Sato | 2026-01-24 19:48 | G 書評 | Comments(0)

生産管理システムの設計・導入は、なぜ販売管理や経理システムより難しいのか

  • 上司にレポート作成を命じられたら

月曜の朝一番、あなたは上司に呼ばれて、ある件に関するレポートを作成するように命じられる。それなりの内容だ。部内の過去の資料などを調べ直さないといけない。3日位はフルにかかりそうな仕事だ。それを今週中に提出してほしいと言う。あなたは他にも定常業務を抱えていて、今その1つに着手したばかりだ。さて、どうするか。

1つの考え方は、やりかけの仕事は脇において、そのレポート作成にすぐ取り組むことだ。早ければ水曜日の夕方には終わるだろう。やりかけの定常業務は、木曜の朝から再開すれば良い。その方が気が楽だし、書き上げたレポートをブラッシュアップするチャンスもあるだろう。

しかしもちろん別の考え方もある。金曜日の夕方に提出すれば良いのだから、ギリギリ水曜日の朝に着手すれば間に合うはずだ。そうすれば一旦、着手しはじめた定常業務の方を、先にある程度片付けることができる。頭脳労働というものは、途中で腰をおられると再開するまでに時間がかかり、その間、能率も落ちる。

早めに着手するか、ギリギリでの完成を狙うか。あなたには選択の余地がある。考えなければいけない因子もいくつかある。やりかけの仕事を中断して、生産性の低下を我慢するかどうか。作成するのに3日かかると見積もったが、その見積もりはどれくらい正確なのか。一旦完成した後で、品質向上のチャンスを残したいかどうか。そして週末に気楽な気分になって、気になっているカノジョに飲みに行こうと声をかけたくなるかどうか…etc, etc。


  • 指示のためには基準と目標が必要

別にそんな「白か黒」みたいに固く考える必要は無いのではないか。金曜までの間に思いついた時だけ少しずつやれば良い、そんな感想もあるだろう。それはこの仕事をあなた1人だけでやる場合だったら正しい。しかし、仕事の1部を後輩や部下に分担してもらうのだったら、どうだろう。 その時には、仕事の内容やアウトプット、そして期限などを決めて伝えなければならない。ちょうどあなたが上司からそうされたように。

できるだけ早く着手するか、それとも可能な限りギリギリの完成を狙うか。スケジューリングの分野では、前者を「フォワード・スケジューリング」、後者を「バックワード・スケジューリング」と呼ぶ。

この2種類は、どちらもプラスとマイナスがある。 前者の方針をとると、定常業務の生産性が一旦落ちる上に、成果物が完成してから上司に提出するまで、手元に二日間とどまることになる。いわば仕掛在庫になるわけだ。「在庫(=作りすぎ)のムダ」を嫌うジャスト・イン・タイム生産の基準に 従うなら、ギリギリの完成を狙うことになる。 しかしその場合、「三日間」と言う作業期間の見積もりが甘かった場合、納期遅れになるリスクが生じる。飲み会を考える気分的余裕はないかもしれない。

品質を取るか、生産性を取るか。週末の自由度を取るか、納期リスクを取るか。指示を出す人は、決めなくてはならない。誰かに指示を出すときには、決断のための基準がいる。 その基準は、QCDなどのKPIの内、どれを重視するのかとリンクしている。 もちろん毎回個別に考えてもいい。だが、指示を出す業務をITシステム化するときには、何らかの基準と目標を設定する必要がある。

生産管理システムの設計・導入は、なぜ販売管理や経理システムより難しいのか_e0058447_18364179.png

  • 生産管理システムの特徴=指示を出す仕組みであること

知人のコンサルタント本間峰一氏は以前、「生産管理システムには魂を入れる必要がある」と解説しておられた。うまい表現だと思う。では生産管理システムに入れるべき「魂」とは何か。上で述べた基準や目標値の取り方は、明らかにその重要な要素である。

生産管理システムは、販売管理や経理システムなどとは、かなり違う性格を持っている。販売管理システムは、基本的に営業マンに指示を出さない。売上目標ぐらいは与えるかもしれないが、具体的にどの顧客を訪問し、どう喋って何を売り込め、というような指示は出さない。それらは全て営業マンたちが自分の頭の中で判断して決める。

そして販売業務の結果、引合や注文を受け取ったら、結果を販売管理システムに入力し記録することになる。経理システムも同様だ。経理部門のユーザに対し、何を買えとか、いくら借りてこい、とか指示を出すわけではない。業務の指図と手配は、全てユーザが頭の中で行って、その結果を記録するだけだ。

ところが、生産管理システムは違う。上にのべたレポート業務との類推で、考えてみて欲しい。レポート作成の代わりに、生産ではどの部品を手配し、どの工程でいつ着手するのか、どのサプライヤーに発注するのか、すべて指示が必要だ。そうした指示は基本的に、システムが決めて出力することになる。

もちろん指示の作成・発行は、設定したルールや基準に従って行うわけだ。そして指図を現場に伝えて、初めて実際の業務が動き始める。指示の決め方の基準やルールに応じて、結果の品質や納期やコストといったパフォーマンスが、大きく左右されることになる。

だから、どういうルールや基準に基本的に従うのかを、ユーザたちが選び、設定できるようにしなければならない。これこそが「システムに魂を入れる」部分なのだ。販売管理や経理システムでは、魂を入れる必要は無い。魂は、実際の指示や業務を行う人たちの頭の中にあるからだ。


  • 生産管理システムの難しさは機能面よりも、業務ルールとKPIの因果関係理解にある

生産管理システムは複雑だ。BOM=部品表をはじめ、多数のマスタがあり、画面数もトランザクションも多く、外部I/Fだって、各種あり得る。だから担当SEは、全体の仕組みを理解するだけでも、かなりの勉強時間を必要とする。無論、販売だって経理だって、システムはそれなりに複雑で、その点では本質的な違いはない。しかし生産管理系の難しさの中心は、IT側にはない。本当に理解すべきなのは、工場という仕組みとその組織、そして生産業務を構成する諸要素と結果(KPI)との、因果関係にある。ここが実に、分かりにくい。

なぜ、分かりにくいのか。意外に思うかもしれないが、じつはユーザーである製造業の側に、それをちゃんと説明してくれる人が少ないからだ。日本の製造業の多くは縦割り組織になっていてサイロ化が進み、工場業務の全体像を知っている人がほとんど、いない。仮にいたとしても、自分の業界のこと以外は、普通は知らない。

製造業の業務は、生産形態にしても生産方式にしても、非常にバラエティが大きい。生産管理システム・パッケージは普通、できる限り広い業種業態をカバーしようとする。特定業種に適用するには、一種の「翻訳」が必要になる。それに、製造業が高度成長期から令和の現在までに、どのような変化に直面しているのか、それが目標設定にどう影響するのかも、ふつうのユーザは説明できない。

それだからこそ、(ここから少し手前味噌的になるが)幅広い製造業を長年相手にしてきた、エンジニアリング会社だとか生産系コンサルタントといった職種が役に立つのだ。新著『攻めの工場づくり』のような本は、製造業の人ではあまり、書けない。工場の仕組みをゼロからスクラッチで構想し、設計・実装する仕事は、ふつうの企業ならよくて10年に1度程度しかない。だがエンジ会社は、ずっと工場づくりを繰り返している。そして工場のハードウェアは、生産管理のソフトウェアと、ワンセットなのである。

生産をきちんとマネジメントしたかったら、ITシステムの機能や構造を理解するだけでは十分ではない。基準に従って出る指示が、どう実際業務を動かし、その因果関係がどう生産のQCDなどのパフォーマンスにはね返るかを、知らなければならない。冒頭のレポート作成を見れば分かる。すぐ着手するよう指示すべきか、ぎりぎり完成するよう指示すべきか。そのプラスとマイナス、トレードオフを意識できるようになって、はじめて有用なシステムが作れるのである。

<関連エントリ>

# by Tomoichi_Sato | 2026-01-18 18:38 | A1 生産マネジメント全般 | Comments(0)