<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet href="/assets/xslt/rss.xsl" type="text/xsl" media="screen" ?>
<rss version="2.0"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
     xmlns:admin="http://webns.net/mvcb/"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <channel>
    <title>タイム・コンサルタントの日誌から</title>
    <link>http://brevis.exblog.jp</link>
    <description>タイム・マネジメントとSCM専門家のエッセー・批評・考察集</description>
    <dc:language>ja</dc:language>
    <dc:creator>Tomoichi_Sato</dc:creator>
    <dc:rights>2026</dc:rights>
    <pubDate>Thu, 12 Mar 2026 09:29:39 +0900</pubDate>
    <dc:date>2026-03-12T09:29:39+09:00</dc:date>
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <sy:updateBase>2013-06-01T12:00:00+00:00</sy:updateBase>
    <image>
      <title>タイム・コンサルタントの日誌から</title>
      <url>https://pds.exblog.jp/logo/1/200508/25/47/e005844720050825233346.jpg</url>
      <link>http://brevis.exblog.jp</link>
      <width>80</width>
      <height>60</height>
      <description>タイム・マネジメントとSCM専門家のエッセー・批評・考察集</description>
    </image>
    <item>
      <title>インフレとサプライチェーン途絶時代の資材調達・在庫を考える</title>
      <link>http://brevis.exblog.jp/33909850/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33909850/</guid>
      <description><![CDATA[サプライチェーンの危機とエネルギー・インフレのリスク<br />
<br />
<br />
この文章を書いている現時点で、ホルムズ海峡は事実上の閉鎖状態にある。いつまでこの事態が続くか、予測は難しい。少なくともわたしには、分らない。中東の事態は毎日急変しており、WTI原油価格は100ドルを超えたり乱高下している。わたしは石油よりむしろ、中東の現場で勤務している同僚や仲間達の安全を、何より危惧している。<br />
<br />
<br />
しかし多くの人々の関心事はやはり、エネルギー価格の高騰や、サプライチェーンの不安定化にあると思う。中東産の原油や石油製品・LNGの国際輸送の出口は、ほぼペルシャ湾にある。そのボトルネックに位置するのが、ホルムズ海峡だ。ここを迂回するための陸路パイプラインも存在はするが、キャパシティはずっと小さい。<br />
<br />
<br />
日本にとって深刻なのは、それなりの備蓄量を持つ石油よりも、むしろ電力用のLNGだろう。いったん液化したLNGは、普通のパイプラインでは送れない。LNGは燃焼カロリーあたりの二酸化炭素排出量が石油より小さく、比較的クリーンだが、極低温で超高圧のため、輸送も貯蔵も特殊設備を要し、簡単に増強できない。したがって元々、LNGサプライチェーンはフレキシビリティが小さい。供給途絶に弱いのである。<br />
<br />
<br />
その性質は、電力網ともすこし似ている。大規模発電所と高圧送電網を中心とした系統電源もまた、ルートや設備が固定されていて、かつ、備蓄が難しい。そして肝心な原料は輸入依存だ。そういうインフラの上に、我々の産業社会は成り立っている（データセンターで動く生成AI等を含めて）。<br />
<br />
<br />
<br />
<br />
インフレ時代の、ある企業の事例から<br />
<br />
<br />
ここまで書いて、思い出したことがある。日本のあるメーカーが過去、似た状況下でとった行動だ。今から半世紀近く前の1979年、第二次石油ショックが世界を襲った。このときも、震源地はイランだ。革命によって旧体制が倒れ、石油供給が停止したため、原油価格が倍以上に跳ね上がった。シャー・パーレビ（日本ではパーレビ国王と訳されているが、シャーは「皇帝」の意味）の旧体制がどういうものだったか、ここでは書かない。イランとアラブの区別すらつかない人が大多数の日本で、中東の社会や政治を手際よく説明するのは難しい。<br />
<br />
<br />
ともあれ、世界は急激なインフレの波に襲われた。インフレとは資材価格が上昇するだけでなく、入手までの納期が長く、見えにくくなる状態を指す。これに乗じて、生活必需品などの買い占め・売り惜しみに動く連中が出るから、逼迫は一層ひどくなる。<br />
<br />
<br />
このとき、日本のある機械メーカーは、自社に必要な部品材料を、短期間に大量発注した。相場的投機のためではない。専用の機械部品や鋳物などは、転売しにくい。生産確保による自衛のためだ。大量発注といったが、個別の量は少ない。ただ品種が多いのだ。多品種少量の機械製品だったからだ。<br />
<br />
<br />
当時、まだERPなどというパッケージソフトはない。そもそも、生産管理や資材購買に汎用コンピュータを使うこと自体、珍しかった。だがこの会社は、自社開発でシステムを持っていた。だから大量の発注伝票を一気に出せたのだ。これが他の会社のような手書き伝票では、数千数万もある部品群から、適切な品目を選んで、倉庫に入りきる量を計算して発注するなど、それだけで一月も二月もかかったろう。その間に、資材などどんどん値上がりしていく。<br />
<br />
<br />
<br />
<br />
インフレ時期の調達・在庫行動とは<br />
<br />
<br />
インフレの時期には、原材料・購買部品の在庫を、早め・多めに抱える必要がある。単価も上がり、納期も伸びるからだ。デフレの時代は、その逆になる。単価は落ち気味、納期も早い。だから極力、生産に引きつけて発注する。いわゆるJIT（ジャスト・イン・タイム）納品やJIT購買は、価格安定期や不況期に成り立つ方策だ。インフレになったら、別の方針をとらなければならない。だが、この政策変更を機敏に行える経営者は、決して多くあるまい。<br />
<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/202603/11/47/e0058447_18420468.png" alt="_e0058447_18420468.png" class="IMAGE_MID" height="375" width="500" /></center><br />
<br />
<br />
上記の会社の経営者は、「在庫をミニマムにする計算機システムを逆に使って、在庫最大化を図った」と、外部には説明していた。しかし在庫管理システムの内部構造を考えると、話はそれほど単純ではないはずだ。どの品目をどれだけ抱えるか、平均使用量と金額と倉庫キャパシティを考えて、特別にプログラムを書く必要があっただろう。ともあれ、それを指示して、短期間に発注をかけることで、たしかこの会社はインフレ期間を減収増益で乗り切ったと記憶する。<br />
<br />
<br />
たいていの生産・在庫管理システムには安全在庫量や発注点の設定機能がある。だが、この機能を活かしている企業は、決して多くないという印象がある。わたしが生産計画の入門セミナーをする際には、最初の方で必ず、在庫の話をする。在庫にはストック在庫とフロー在庫があること、また計画在庫と偶発在庫があること、そして在庫には3つの機能がある事、などだ。こういう基本的な理解抜きに、在庫を「管理」しようというのは無謀な話だ。だがこうした基本抜きに、「在庫削減」の掛け声だけまかり通る企業が、いかに多いことか。<br />
<br />
<br />
意図せぬ欠品を防ぐための「安全在庫量」には、もちろん在庫理論の計算式がある。経済的発注ロットサイズ、いわゆるWilsonの経済的発注ロットサイズの計算法もある。ただ、これらをよく知らない企業は案外多い（残念ながら「管理」は文系の仕事だと思っているらしい）。かりに知っていても、サプライチェーン混乱期に、これらを単純に適用すると、かなり多めの数字になってしまう。だからこそ、主要なストック在庫ポイント（カップリング・ポイント）の位置決めや、在庫や調達手配のノウハウの有無が、利益に直結するのだ。<br />
<br />
<br />
<br />
<br />
日本企業にとっての二つのハードル<br />
<br />
<br />
それでも10年前に比べると、在庫に対する考え方は、明らかに変わってきた。2010年代は「在庫は悪」と単純に信じる人がほとんどだった。しかしコロナ禍とウクライナ戦争等のサプライチェーン脆弱期を経て、ようやくその思い込みは、原材料・購買部品には必ずしも当たらない、と感じる人が増えたのだろう。とはいえ日本の製造業が、上記の企業のように機敏に動くためには、大きく二つの障害があるように思えて仕方がない。<br />
<br />
<br />
その一つは、JIT生産が良い、在庫は悪、という信条である。これは、有名なトヨタ生産方式を、前提や状況の違いを無視して、無批判に真似ようとする態度に支えられて広まった。しかし、生産マネジメントの世界では、つねに複数の相反する目標値が存在し、状況に応じて優先度を変えなければならない。<br />
<br />
<br />
そして元祖のトヨタ自動車自身が、各部品の調達条件を踏まえて、実は1～4カ月分の在庫を持っていると公表する（2020年度第3四半期の決算会見）に至って、ようやく「在庫＝悪」の信条は揺るぎ始めた。<br />
<br />
<br />
ただし、インフレ下で適切な在庫・調達に動くムーブを止める、もう一つの要因がある。それは、工場がコストセンターとして別会社化されているケースが多いことだ。在庫を増やすには、資金が要る。在庫は、マクロ経済的には投資である。だが、このような投資的判断を、工場自身が決められないのである。ミクロな会計的に見ると、原料部品在庫の積み増しは、コスト増加要因でしかない。それでも本社は、「一時的なコスト増は容認するから、早く購買手配を掛けろ」と指令を出すだろうか？　減点主義の官僚組織から、そのような指示は出てきそうもない。<br />
<br />
<br />
見かけ上、いったんは損になっても、長期的な得を目指すような策は、「戦略」である。貴方のところに、経営者からそのような戦略指示は下りてきているだろうか。調達サプライチェーンを見通して、そのような戦略的判断ができる経営層がどれだけいるのか。それが製造業にとって、この先の分かれ道になるはずだ。<br />
<br />
<br />
<br />
<br />
＜関連エントリ＞<br />
「欠品を起こさないための在庫手配入門(1)――まず、累積需給曲線を理解しよう」 (2020-07-15)<br />
]]></description>
      <dc:subject>A3 在庫・調達計画</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Wed, 11 Mar 2026 18:48:21 +0900</pubDate>
      <dc:date>2026-03-11T18:48:21+09:00</dc:date>
    </item>
    <item>
      <title>大日程・中日程・小日程計画と、生産スケジューリングのレイヤーとの関係を理解する</title>
      <link>http://brevis.exblog.jp/33902328/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33902328/</guid>
      <description><![CDATA[大日程・中日程・小日程計画とは<br />
<br />
<br />
<br />
世の中には、教科書に書いてあるのに、実務ではあまり出会わない用語が時々ある。「生産統制」なる言葉は、その一つだ。わたしは 毎年大阪で「生産統制」を テーマとしたセミナーを行っているが、生産統制部とか統制課とか統制係という所属肩書の人は、参加者に過去1人もいなかった。そういう名前の部門は、製造業にはほとんど存在しない、としか思えない。生産管理の教科書は、「 生産管理＝生産計画＋生産統制」だと書いてあるにもかかわらず、である。<br />
<br />
<br />
似たような違和感を、わたしは「大日程・中日程・小日程計画」なる言葉に対しても感じている。自分の経験した範囲では、この3種類の名前で計画を使い分けている企業は、ほとんどなかったからだ。なぜだろうか？<br />
<br />
<br />
教科書的には、大日程・中日程・小日程計画は、計画対象期間のスパンと目的によって、下記のように分類されている。<br />
<br />
<br />
大日程計画：半期〜1・2年程度。予算計画とも。目的は生産資源（人・設備等）の戦略判断<br />
中日程計画：1ヶ月〜半期程度。月次計画とも。目的は個別納期や在庫量の管理<br />
小日程計画：1週間〜1ヶ月程度。日程計画とも。目的は作業順序の判断調整<br />
<br />
<br />
<br />
本や情報源によって、多少のブレはあるが、ざっとこんなところだ。 計画のスパンだけでなく、粒度（目の細かさ）でいうと、大日程＝月単位、中日程＝日・週単位、小日程＝時間・日単位、みたいなことが書かれている。<br />
<br />
<br />
でも本当だろうか？　わたしは産業機械や航空機製造業界とも仕事をしているが、こうした分野では、1つの製品や大型の部品モジュールを作るまで、1年半とか2年かかるような場合が結構ある。 では、こうした製品を受注して、日程展開をかけた結果は、大日程なのだろうか、中日程なのだろうか？　上記のような区分は、製品を作り上げるまでのリードタイムが1〜2ヶ月程度の、自動車業界や家電業界の感覚から来ているのではないかと感じる。<br />
<br />
<br />
<br />
<br />
<br />
多くの工場には二種類の生産計画があり、しかもズレている<br />
<br />
<br />
<br />
日本の製造業のものの考え方は、昭和の高度成長期を牽引した自動車産業や家電産業の影響を、強く受けている。 生産管理の教科書の記述にも、そうした影響が現れており、典型例がここにあげた生産計画の3分類ではないか、とも思う。しかしそれはすべての業界に合致するわけではない。自動車業界で大成功した生産方式があるからといって、他の業界が無批判に取り入れて真似る傾向については、当サイトでも以前から批判してきた通りだ。<br />
<br />
<br />
<br />
ところで、中日程・小日程といった用語は必ずしも使わないとしても、わたしが 見た限りでは、工場の内部に2種類の異なった生産計画が動いているケースを、非常に多く見かける。しかもほとんどは、両者の不整合に苦心しているのだ。一つは、生産計画システムとかERPとかの内部にある、生産計画である。もう一つは、Excelで作成されたり、現場のホワイトボードに手書きされたりしている、より詳細な生産スケジュールだ。<br />
<br />
<br />
前者はいわば、公式の計画であり、工場の製造部門だけでなく 営業部門や本社の管理部門もそれを参照できる。後者は逆に非公式なスケジュールで、しかし実際の現場はそれに従って動いている。前者はふつう、日単位の計画である。後者は日単位だったり、より詳細な時間単位だったりする。 多くの現場では、1日に複数の品目を製造するので、後者は順序計画の機能も兼ねている。<br />
<br />
<br />
その二つが、すなわち中日程と小日程計画を指すのだと、教科書を学んだ人は思うだろう。 ではなぜ、この二種類の計画には、ズレとギャップがあるのだろうか？　ある品目は、前者の公式計画では月曜日に製造することになっているのに、現実には後者の非公式計画で金曜日に作られたりしている。大日程・中日程・小日程の関係は、粒度を上げて詳細化したものだ、と言う話ではなかったのか。内容が異なっても良いと、教科書には書いてあるのだろうか。<br />
<br />
<br />
<br />
<br />
<br />
なぜ両者は合わないのか？<br />
<br />
<br />
<br />
公式な計画から非公式な現実がずれていく理由は様々である。例えば、部品材料の納入が予定よりも少し遅れた、機械のトラブルで終わるべきタイミングがずれてしまった、特急割り込みがあり後ろにずらさざるを得なかった・・などなど。 そのたびごとに、現場のチーフたちは、非公式の計画を現実に合わせて書き換えているわけだ。<br />
<br />
<br />
<br />
営業担当者たちも、工場が公式な計画通りには動いていないことを知っている。だから、自分が担当する顧客の重要なオーダーについては、納期が実際にはいつになるのか、工場にいちいち連絡して確認せずにはいられない。Excelの日程表や ホワイトボードは、工場の外からは見えないからだ。 納期が遅れそうだったら、他の品目を後回しにして、自分の顧客を優先してくれとねじ込むだろう。その営業マンの発言力が強い場合、現場はそれに合わせて、また非公式な計画を書き換える。実にすりあわせ型のビジネスだ。かくて公式な計画と非公式な現実はどんどんずれていく。<br />
<br />
<br />
だったら、公式な生産計画の方をちゃんと書き直したらいいじゃないか。あなたがもし、工場から遠く離れたところで働く、しかも論理的な人だったら、そう考えても不思議ではない。でも、それはできない。そこには簡単な理由がある。公式の計画は、既にリリースして、製造指図や購買発注書などの「オーダー」を、現場や サプライヤーに対して、発行してしまったからだ。<br />
<br />
<br />
<br />
<br />
ズレが生じる根本の理由＝確定と発行<br />
<br />
<br />
<br />
「計画」と我々が呼ぶものには、実は2種類のステージがある。 1つ目は、まだ机上の検討プランである状態だ。だから変えることができるし、何ならば複数のプランを作って比較することもできる。その中から、1番良いと思われる「実行計画」を選ぶ。ここまではいわば、工場の生産計画プランナーの、机の上での仕事だ。<br />
<br />
<br />
ただし実行計画を決めたら、それを実行する現場の人たちに伝達しなければならない。 そしていったん伝えてしまったら、その計画は「リリース済みの確定計画」と言うステージに変わる。もう勝手に変更することはできないのである。<br />
<br />
<br />
生産計画を製造現場に伝えるにあたっては、通常、部品単位・工程単位に分解した『製造オーダー』の形で伝える。伝え方は紙の伝票の場合もあるだろうし、電子的に表示する場合もあるだろう。そこには、どの工程で、どの部品・材料から、どのような中間部品を、どの製造仕様に従って、いつまでに何個作るべきか、が書いてある。（なお製造オーダーは、製造指図とか生産指令とか、会社によってまちまちな呼び方がされるので、自社の用語に翻訳して理解してほしい）<br />
<br />
<br />
サプライヤーに対しても同様だ。『購買オーダー』（英語だとPurchase Orderなのでこう訳したが、ふつうは発注書ないし注文書とよぶ）を発行し、そこに、どの部品を、どの製造仕様に従って、いつまでに何個作って納めてほしいか、が指定してある。<br />
<br />
<br />
そこで、あなたがサプライヤーの立場になったと想像してみて欲しい。一旦発注書を受けた品目が、納入先の工場の都合で、必要になる日にちが前後に少しずれたからといって、毎度毎度、発注書を差し替えられたら、たまったものではない。 自分の工場にはそれなりの都合と予定があって、スケジュールを組んでいるからだ。だから普通、いったん発行した注文書は、よほど大きな変更がない限りは改訂し再発行はしない。でも実際の納入日は、顧客と別途連絡を取りながら、前後に動かしたりするのが常だ。<br />
<br />
<br />
工場内の製造現場であって同じことである。上流側の工程が遅れたから、月曜日に着手すべき品目の完成予定日が水曜日にずれたとしても、一旦発行された製造オーダーは、普通は変更しない。生産管理システムの中の日程をずらして、再発行すればいいじゃないかと思うかもしれないが、既に一度発行した製造指図書は、部品に添付されて、既に工場の中をどこかに移動中である。それを全部差し押さえて、紙を張り替えることが現実的だろうか？　出庫してしまった材料を、いちいち倉庫に戻し入れろと指示するだろうか？　2日後にはまた出庫しなければいけないのに。<br />
<br />
<br />
これが、工場内に2種類の生産計画が存在する理由である。一度、「リリース済みの確定計画」となって、指示が伝達されたものは、簡単には変更できないのだ。<br />
<br />
<br />
<br />
<br />
基準生産計画、生産スケジューリング、ディスパッチング<br />
<br />
<br />
<br />
確定版の生産計画から、製造オーダーや発注書を切り出して、現場とサプライヤーに発行する仕事を『ディスパッチング』とよぶ。日本語で「差立て」などとよぶ企業も多い。複数のオーダー間の順序などもここで決めたりする。欧米企業ではディスパッチングは工場管理者側の仕事だが、現場の裁量の大きな日本企業では、現場側のチーフが実質的に行う例も多いと思われる。<br />
<br />
<br />
そして実を言うと、本社側の計画と工場側の計画との間にも、似たような関係が存在する。本社側のいわゆる「基準生産計画」（PSI計画のPの部分）は、製品単位に、必要な数量と期日を規定するプランだ。複数の工場がある場合は、それを工場単位に切り分けて、工場に伝達する。これを『生産オーダー』とよぶ。工場側は生産オーダーを受けて、製品単位の必要量を、BOMやBOPを基準にして 工程単位・部品単位に展開し、工場の生産スケジュールを作成する。本社が「基準生産計画」を毎日ぐるぐる変えてきたら、工場側はたまったものではない。<br />
<br />
<br />
生産計画の機能はいくつかあるが、最重要な目的の一つは、需要と供給を合致させることである。需要のないものを供給すれば在庫の山ができるだけだし、需要があるのに供給しなければ欠品と失注の穴が深まる。そして需給の一致は、企業レベルでも、工場レベルでも、各工程レベルでも大事だ。ただし工場も現場も、それなりの自律性を持つ。だから指示と伝達が必要になるし、いったん指示した事は、みだりに変えられない。<br />
<br />
<br />
製造業では、「本社」「工場管理者（製造スタッフ）」「製造現場」の3つのレベルで判断・決定が行われる。これが、業務の3層モデルである。それぞれの層の間で、指示と報告の伝達がある。だから、計画も3層に分かれていて、その間で実行指示が出されていく。それは会社レベルの「基準生産計画」、工場レベルの「生産スケジューリング」、そして工程レベルの「ディスパッチング」（製造オーダー・スケジュール）を示すのだと理解すべきであろう。この観点から見ると、大日程・中日程・小日程といった期間のスパンによる区別は、あまり有用ではない。<br />
<br />
<br />
そしてこの3者の間には、本質的にズレが生じやすい。需要や生産が安定しているなら、ズレは小さいから、無視してもいいだろう。だが昨今のようなサプライチェーンの乱れがある場合や、有力顧客の需要にひどく変更が多い場合には、ディスパッチング・レベルの現実を、なるべくリアルタイムに把握し共有できる仕組みが必要である。その詳細は今回は省くが、多くはMESとAPSの連携がキーになるはずだ。だからこそ今、多くの企業がMESに目を向けるようになっているのである。<br />
<center><img src="https://pds.exblog.jp/pds/1/202602/28/47/e0058447_22015399.png" alt="_e0058447_22015399.png" class="IMAGE_MID" height="206" width="500" /></center><br />
<br />
<br />
＜関連エントリ＞<br />
「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 (2017-08-19)・・業務の3層モデルを解説している<br />
]]></description>
      <dc:subject>A2 生産計画と生産スケジューリング</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Sat, 28 Feb 2026 22:04:15 +0900</pubDate>
      <dc:date>2026-02-28T22:04:15+09:00</dc:date>
    </item>
    <item>
      <title>お知らせ：関西設計管理研究会KEACで、設計のプロジェクト・マネジメントについて講演します（3月27日）</title>
      <link>http://brevis.exblog.jp/33898145/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33898145/</guid>
      <description><![CDATA[お知らせです。来る3月27日(金)に、関西設計管理研究会（KEAC）の例会で、設計業務のプロジェクト・マネジメントについてお話しします。場所は京都の四条烏丸に近い京都経済センターで、午後1時40分からの予定です。年度末の時期ですが、関西であまりPMの講演をする機会がないので、ぜひお越し下さい（研究会員企業限定ですが、体験参加も可能とのことですので、ご興味のある方は佐藤までご連絡ください）。<br />
<br />
<br />
ご存じの通りプロジェクトとは一回限りの、ユニークな仕事（＝他に同一なものが無い仕事）を指します。PMBOK Guide(R)の、「独自のプロダクト、サービス、所産を創造するために実施される有期的な業務」という有名な（そして難解な）定義もまさに、『独自の』『有期的な』という言葉（原語はuniqueとtemporary）で、それを表現しています。<br />
<br />
<br />
考えてみると設計という仕事は、まさにそのようなプロジェクト的性質を最初から持っています。それは製造業の他の業務と比べると分かります。工場の製造現場では、技能員が全くおなじ部品を繰り返し繰り返し、作っています。しかし技術者が、全くおなじ設計図面を何枚も何枚も作ることは、あり得ません。設計のアウトプットは、必ず（少しであれ）従来のものとは違っていて、つまりユニークです。そして設計業務は基本的に、出図すれば終わりとなる、一過性の業務です。だとすると設計業務は、すべてプロジェクトだと言えるでしょう。<br />
<br />
<br />
では、設計業務をプロジェクト・マネジメントの視点から動かそうと考える企業は、どれだけいるのでしょうか？　実はこの3月の講演に先立って、KEACの研究会員に簡単なアンケートをしてもらいました。会員メンバーの多くは製造業の設計部門の技術者です（ちなみに、名称には「関西」とありますが、関西以外からの参加者も、それなりにおられるとのこと）。そこから、興味深い事実が見えてきました。<br />
<br />
<br />
たとえば会社に公式な役職として「プロジェクト・マネージャー」がいるかどうか。皆さんは、どれくらいの比率だと思われますか？　研究会にとっていただいたアンケート結果をここで勝手に公開できないので、数字は当日お話ししますが、かなり少ないのです。プロジェクト的業務なのに、プロマネがいない。その結果、何が起きるでしょうか？<br />
<br />
<br />
ちなみに、日揮のようなプラント・エンジニアリング業界では、必ず『エンジニアリング・マネージャー』という職種の人たちがいます。プラント系プロジェクトは、大まかに言うと設計（エンジニアリング）のフェーズ、調達フェーズ、建設フェーズに分かれます。その設計フェーズのプロジェクト業務をとりまとめる責任者が、エンジニアリング・マネージャー（略称EM）です。この職種はある意味、プロマネの右腕であり、EM職はプロマネへの登竜門とも言われます。<br />
<br />
<br />
このエンジニアリング・マネージャーの養成教育について、少し前に調べたことがあるのですが、米国にはちゃんとEM教育のためのコースを持つ大学が存在します。しかし、日本には調べた限り皆無でした。（まあプロマネ教育の専攻コースだって、国内の大学には皆無ですから、推して知るべしですが）<br />
<br />
<br />
音楽にたとえてみるならば、日本にはヴァイオリンやチェロや金管といった、各種専門分野の教育は存在するけれど（これらが工学部で言う電気とか機械とか土木に相当します）、指揮者を養成教育するコースだけが存在しない訳です。<br />
<br />
<br />
なぜか？　それは、不要だと思われてきたからでしょう。実際、西洋のオーケストラには指揮者がいますが、日本の雅楽とか能楽の演奏団には、指揮者なんていませんしね。横目でちらと見て、阿吽の呼吸であわせる、と。それで済んできたのです。<br />
<br />
<br />
しかしそれは小規模で、ゆったりした曲調の場合の話です。曲が複雑・大規模化してスピード感を求められたら、やはり誰かタクトを振るう役割が必要になります。設計もおなじでしょう。複雑化し大規模化し、スピードを求められたら、やはり専門のマネジメントが必要になるのです。日本の製造業の多くは、この変化にまだついて来られずにいるのではないか、と危惧します。じっさい、PLMソフトウェアのベンダーからは、単なる図面管理をこえた、設計進捗管理やBOM展開などの機能を、使いこなせているユーザはまだ少ないと聞いています。<br />
<br />
<br />
では、設計のプロジェクト・マネジメントとは具体的にどんな仕事なのか。どういう技量が必要なのか。それについて、限られた時間ではありますが、ご説明しようというのが今回の講演です。昨年夏に引き続き、講演にお呼びいただいた関西設計管理研究会（KEAC）さんに、あらためて感謝いたします。<br />
<br />
<br />
<br />
<br />
＜記＞<br />
<br />
<br />
講演タイトル(仮)：「エンジニアリング・マネジメントの役割と価値　〜　プロジェクトの視点から設計をとらえ直す」<br />
<br />
<br />
日時：2026年3月27日(金) 13:15 ～ 17:00<br />
（わたしの講演は13:40 ～ 15:10の予定です）<br />
<br />
<br />
開催方法：ハイブリッド開催（リアル70名＋オンライン70名）、研究会員限定<br />
<br />
　【リアル会場】京都経済センター 　 ６階　６－C 会議室<br />
<br />
<br />
主催団体：関西設計管理研究会（KEAC）<br />
<br />
<br />
開催案内はこちらのページです（注：3月2日に更新されました）<br />
https://keac.jp/archives/event/regular-meeting527　<br />
<br />
<br />
<br />
<br />
このテーマに関心のある方のご来聴をお待ちしております。<br />
<br />
<br />
<br />
<br />
佐藤知一＠横浜<br />
<br />
<br />
]]></description>
      <dc:subject>E2 設計のマネジメント</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Sun, 22 Feb 2026 21:57:12 +0900</pubDate>
      <dc:date>2026-02-22T21:57:12+09:00</dc:date>
    </item>
    <item>
      <title>MESはむしろ品質のためにある（＋経営工学会シンポジウムのご案内）</title>
      <link>http://brevis.exblog.jp/33893960/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33893960/</guid>
      <description><![CDATA[サイトのカテゴリー分類について<br />
<br />
<br />
<br />
当サイトの以前からの読者はお気づきかもしれないが、最近、記事のカテゴリー分けを見直した。「A 生産マネジメントとSCM」「B プロジェクト・マネジメント」「C システムとしての工場」「D 情報システムのマネジメント」「E ビジネス・マネジメントと管理技術」「F 考えるヒント」「G 書評」の、実質7カテゴリー・23分類に詳細化したのである。これで、話題の広がりが見通せると同時に、関連記事が少しは見つけやすくなっただろう、と信じる。<br />
<br />
<br />
そう言いながら、自分の記事の分類に自分で悩むことも結構ある。例えば今から書こうとしている本記事にも、その一つだ。なぜなら、2種類のトピックに関して、その関連性を考えようという記事だからだ。2種類のテーマとは、 次世代スマート工場の必須の道具であるMESと、製造における重要なKPIである『品質』のことである。前者には、カテゴリーC2「スマート工場」があるし、後者はカテゴリーA4「コスト・品質・安全」に属する。<br />
<br />
<br />
今回はそれでも、後者のカテゴリーA4に分類しようと思う。 なぜなら、品質について改めて考え直してみたいからである。<br />
<br />
<br />
<br />
<br />
品質偽装の蔓延と、その原因<br />
<br />
<br />
<br />
こんなことをネットで書くべきではないのかもしれないが、最近気になることをある製造業に詳しい知り合いの法務専門家から聞いた。この方によると、品質偽装はかなり多くの企業で起きていて、もはやそれを前提に色々と対策を考えざるを得ない、という。 かつての品質大国ニッポンは風前の灯だ、とのことだ。<br />
<br />
<br />
たしかにちょっと振りかえってみても、数多くの偽装問題が新聞を賑わせた。たとえば：<br />
<br />
<br />
D工業（自動車メーカー）による道路運送車両法の認証不正問題（1989年頃〜／2024年問題化）<br />
K重工業による海上自衛隊向け潜水艦のディーゼルエンジンの燃費・性能データ偽造（1988〜2021／2025年問題化）<br />
Pインダストリー（電子材料事業）で、複数種類の半導体材料・電子部品関連の材料データにおける改ざん・認証関連不備（2000年代後半〜／2024年問題化）<br />
K製鋼所によるアルミ・銅・鉄鋼製品などの強度・耐久性データ偽造（1970年代後半?〜／2017年問題化）<br />
<br />
<br />
<br />
・・などなど。どれも防衛・鉄道・自動車・半導体など社会の基幹インフラに関わる事案で、なおかつ人も知る（社会的信用もあるはずの）大企業によって行われていた。なお、新聞沙汰になったのだから実名を書いてもいいのだが、個別企業の経営批評が目的ではないので伏せ字にしておこう。<br />
<br />
<br />
<br />
<br />
なぜ品質偽装が表に出てきたのか<br />
<br />
<br />
<br />
偽装のはじまりが1980年代の終わり頃、つまり高度成長が終わったバブル時代くらいにまでさかのぼるケースも多い。偽装は近年に始まった話ではないのだ。ただ、それが近年になって発覚した事例が多い。なぜだろうか？　内部告発等があったにせよ、ではなぜ、長い間だれも声を上げずにきて、急に最近増えたのか、疑問が残る。<br />
<br />
<br />
え？　コーポレート・ガバナンスが浸透したから？　金融庁関係者ならそう思うかもしれないが、どうだろう。だったら架空取引とか売上偽装事案だって、もっと出てきてもいいはずではないか。なぜ品質偽装ばかりが多いのか。<br />
<br />
<br />
<br />
そこには二つの要因があるのではないかと、わたしは推測している。すなわち人手不足と、製造現場へのデジタル技術の浸透である。これらはまさに、コロナ禍の時代に前後して、製造業に共通して進んだ事象だ。人手不足は、熟練工の引退と若手の採用難、そして派遣労働者への依存と歩を合わせて進んだ。若手や中堅の転職も増えている。偽装には、その秘密を守れる仲間意識が必要だ。だが、自分は職場と運命共同体という感覚を、次第に持てなくなってきている訳である。<br />
<br />
<br />
<br />
そしてもう一つが、現場のデジタル化である。従来は、生産管理システムがあっても、現場の差配は紙の帳票ベースが主体だった。ところが、ITは生産管理から現場の製造管理までおりてきた。それがMESである。現場の検査機や製造装置の数値を、そのままI/F経由で読み取ってデジタル製造記録に残すのが、MESの主要な役目だ。そうなるとMESの検討段階で、「おい・・やばいなこれ、どうすんだ？」という内緒の会話が始まるのである。<br />
<br />
<br />
<br />
<br />
MESとは品質保証のシステムである<br />
<br />
<br />
<br />
そもそも、なぜ品質偽装なのか。それは簡単に言うと、QCDのしわ寄せが現場に来た結果である。製造業の三つの主要指標、QCDはトリレンマの関係にある。トリレンマは三すくみ、つまり他の2つに影響を与えずに1つだけいじることができない関係を表す。コストを下げたら、品質か納期に影響が出る。納期を早めたら、品質かコストにしわ寄せが来る。<br />
<br />
<br />
ところで、製造業では誰がその三つを決めるのか。実は、別の部門が決めるのだ。図は以前、「製造業のトリレンマ・QCDを決めるのは誰か」(2024-11-19)にあげたものの再掲である。コストはそもそも、製品設計や工程設計や調達など、製造に入る前の段階で（多くは本社で）、大半が決まってしまう。納期は、生産管理業務を受け持つ工場の製造マネジメント層（中二階）が決める。そして製造品質は、現場が作り込む。でも、会社の力関係は、本社＞マネジメント＞現場、となりがちだ。だから、コスト＞納期＞品質、の順にしわ寄せがくるのである。<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/202411/19/47/e0058447_20145690.png" alt="_e0058447_20145690.png" class="IMAGE_MID" height="375" width="500" /></center><br />
<br />
MESとは製造管理システムともよばれるように、主に現場の業務を支える。それもふつうは、製造指図が上位系のERP/生産管理システムから下りてきた所が起点となる。MESは詳細な手順を現場の作業員に表示し、あるいは物品にバーコードラベルやRFIDを発行してロット識別し、機械と通信I/F経由で指示値や実績値をやりとりする。<br />
作業者が間違えてロットを投入しないよう、ラベル照合したり、機械に応じた設定条件を通信で送ったりといった、いわゆる「ポカよけ」は、MESの得意分野である。正しい標準作業手順SOPにしたがって、モノづくりをするようガイドする。つまりMESとは、納期を司る生産管理よりも、品質を保証する役割の方が強いのだ。<br />
<br />
<br />
<br />
<br />
スマート工場とMESの役割とは<br />
<br />
<br />
<br />
「スマート工場とはMESを活用する工場である」 と、わたしは言い続けてきた。単なる機械単位・工程単位のデジタル化・IoT化も結構だけれども、工場全体が賢さを得なければ、本当の意味で製造業の問題解決にならない。そのためには、まずMESが必要だ、と。だから部分的なスマート化と区別したくて、あえて「次世代スマート工場」という言い方を選んできた。そのポイントは、工場レベルでの賢さの実現である。そして「賢さ」には、偽装のような悪だくみに陥らない、という意味もこもっている。<br />
<br />
<br />
誰だって、やりたくて偽装をやってるのではない、と思う。最初は誰かがやむなく命じ、時間がたつと次第に職場の「習慣」となっていく。だが、やる当人は気持ちのいいものではない。少なくとも、自分の子どもに向かって、胸をはって話したい事ではない。働く人が、働くモチベーションを失ったら、良い製品ができるはずがないではないか。それは「賢さ」とはほど遠い。<br />
<br />
<br />
今こそ、「なぜスマート工場なのか」を議論すべき時なのだと信じる。たまたまちょうど、信頼する研究会仲間である松本卓夫氏から、経営工学会が主催する、次世代スマート工場に関するシンポジウムの案内を頂戴した。内容は下記の通りである。<br />
<br />
<br />
テーマ：「次世代スマート工場の運営と管理を考える」<br />
日時：3月14日（土）13:00〜17:00<br />
場所：青山学院大学（青山キャンパス17号館17810教室）。オンラインあり<br />
費用：無料<br />
詳細：経営工学会HP　https://www.jimanet.jp/wp-content/uploads/1291d4db4d21d2e590c4b5ace6da3cb8.pdf<br />
<br />
<br />
ちなみにエンジニアリング協会の「次世代スマート工場研究会」からは、太田裕文氏が工場物理学（Factory Physics）について講演される予定だ。また神奈川大学からはリチウム電池再利用のビジネスモデルの提案、大手自動車部品メーカーからは労働集約型工場の海外・日本での運営について、講演が予定されている、という。<br />
<br />
<br />
あいにく日程の関係から、わたし個人はオンラインで部分的に視聴するだけだが、こういった場でぜひ、製造業のあるべき姿と、現状の悩みについてディスカッションすべきだ、と思う。ちゃんと議論できないこと。それこそが、今のわたし達の社会の、一番根底の問題なのだから。<br />
<br />
<br />
＜関連エントリ＞<br />
「製造業のトリレンマ・QCDを決めるのは誰か」  (2024-11-19)<br />
「スマート・ファクトリーとはMESを活用する工場である」  (2023-12-02)<br />
]]></description>
      <dc:subject>A4 コスト・品質・安全</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Mon, 16 Feb 2026 19:56:11 +0900</pubDate>
      <dc:date>2026-02-16T19:56:11+09:00</dc:date>
    </item>
    <item>
      <title>ふつうの会社のためのプロジェクト・マネジメントとは　～　モダンじゃないPMの特徴</title>
      <link>http://brevis.exblog.jp/33888818/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33888818/</guid>
      <description><![CDATA[なぜ、わたしはPMPの維持をやめたのか<br />
<br />
<br />
<br />
2017年の秋、わたしはシカゴで開催された『PMI Global Conference』に参加した。自分の研究成果を講演発表するためだ。テーマは、"Decision making with Risk-based Project Value (RPV) analysis and activities’ value contributions"。それまで10年以上にわたって続けてきた、リスク確率に基づくプロジェクト・マネジメントの手法論を簡潔にまとめたものだった。<br />
<br />
<br />
考えてみると、PM関連の国際カンファレンスには、これ以来、参加していない（まあ、GAPPS Initiative のこぢんまりしたオンライン会合は別として）。2000年代の初め頃は、米国でも欧州でも、PMの国際大会への参加は楽しかった。新しい理論や手法の提案も多く、活気に満ちていた。だがシカゴでは、なぜかもはや、そうした興奮に浸ることはできなかった。ちなみに日本からの発表者は、わたし一人だった。<br />
<br />
<br />
わたしは独立研究者である。PM研究は、わたしの勤務先の仕事ではない。上記PMI Global Conferenceには、渡航費も参加費も自費で負担した。だから気持ちが高揚できない大会には、それ以上行く気になれない。<br />
<br />
<br />
わたしはその後、PMPの資格維持もやめてしまった。気がついたらコロナ禍の間に、更新期限が来ていたのを忘れていたのだった。うかつな話だ。だが維持にはお金も時間もかかる。日本で名刺にPMPと書くことに、どれだけの値打ちがあるのか。PMPとは、モダンPMを理解して使える能力を証明する資格のはずだ。だがPMI自身が、PMBOK Guideの第7版で大きな方針変更をはかろうと、右往左往していた時期だった。<br />
<br />
<br />
<br />
<br />
モダンPMの特徴とは<br />
<br />
<br />
<br />
1年ほど前から、本サイトに「モダンPMへの誘い」というシリーズを、断続的に書いている。モダンPMの最大の特徴は、専門的・計量的なマネジメント技術であることだ。 プロジェクト階層的に細分化してWBSを作り、ロジック・ネットワークを構築してクリティカル・パスを同定し、EVMSで進捗とコストをコントロールする。 結果は数字で表され、精度の良い予測が可能になる。<br />
<br />
<br />
このような技術は、大規模で、コストやスケジュール制約の厳しいプロジェクトの方法論として、優れている。だから、どのような分野であれ、大規模なプロジェクトのマネジメントに適用可能だし、 必要だ。わたしのかつての部下の1人は、プラント建設のプロジェクトに従事していたが、結婚して米国にわたり、バイオ医薬品企業や、Googleのデータセンター建設プロジェクトなどに携わっている。それでも通用する。それがモダンPMだ。<br />
<br />
<br />
ところで、このようなモダンPMの手法が 適用できるのは、主にスコープが「ハード」で明確である場合だ。 プロジェクトの任務がふわふわしていて、何を作り、どこまで行ったら終わりなのか、見定めることが難しいようなケースでは、あまりうまく使えない。最初にかっちりした計画もWBSも作れないからだ。<br />
<br />
<br />
そしてPMI自身、しだいにPMBOK Guide第6版までのPM論への確信に揺らぎが出てきた。その理由の一つは、PMIの参加メンバーに IT系の人材が増え、マジョリティになったからではないかと推察している。ITプロジェクトでは、スコープが最初に十分確定していないことが多い。だから、アジャイル開発のような方法論が有効性を持つのだ。<br />
<br />
<br />
<br />
<br />
プロジェクト型の企業と、ふつうの企業<br />
<br />
<br />
<br />
PMBOK Guideの最初の基礎を90年代の初めに作ったのは、航空宇宙産業とエンジニアリング産業の人たちだったと聞いている。この人達の仕事は、航空機とかロケットとかプラントなど、典型的にハードなスコープの受注型プロジェクトだった。そして、こうした業界の企業はプロジェクト型だ。つまり、ビジネスの中心が受注型プロジェクトなのである。わたしの勤務先では（同業他社もそうだが）、全ての仕事が、プロジェクト受注番号に紐付く形でコントロールされる。<br />
<br />
<br />
しかし、そういう会社は少数派だ。通常の会社は、定常業務がビジネスの中心である。多くの製造業も、サービス業も、流通業も金融業も、そうだ。定常業務の中に、まれにプロジェクト的な仕事がある形だろう。<br />
<br />
<br />
もちろん中間型を考えても良い。たとえば、繰返し型業務がメインだが、時折、大型の受注型プロジェクトがある重工メーカーなどがそれだ。運用保守がメインだが、時折、それなりの開発プロジェクトが入る情報子会社などもこのカテゴリーに入る。<br />
<br />
<br />
(A)プロジェクト型企業、(B)定常業務型企業、(C)中間型、とかりに分類したとき、動くプロジェクトの性格は少しずつ異なる。(A)では規模の大小はあれど、受注型でコスト・納期制約の強いプロジェクトが中心だ。とくに大規模ハード系のプロジェクトなら、まさにモダンPMがフィットする。<br />
<br />
<br />
<br />
<br />
ふつうの会社のための、プロジェクト・マネジメント論が必要<br />
<br />
<br />
<br />
しかし、プロジェクト型企業は、産業界全体で言えば少数派だ。定常業務中心の、つまり(B)に属する製造業やサービス企業の方がずっと多い。では、こうしたふつうの企業における、プロジェクトの取り組みはどんなものか？　それはたとえば、重要な製品開発（小手先の模様替えではないもの）、新工場づくり、新事業展開などで、いずれも自発型プロジェクトだ。<br />
<br />
<br />
こうした自発型プロジェクトは、ふつうの会社にとって、競争と発展のための部門横断的な取り組みである。その目的は、「新しい能力の獲得」にある。新製品による競争能力、新工場による生産能力、新事業による市場開拓能力、などだ。ただ、その青写真は最初から明確とは限らない。スコープが「ソフト」なのだ。<br />
<br />
<br />
(C)中間型として重工メーカーの例をさきに挙げたが、個別受注生産の製造業でも、多くの案件は部門間のバトンリレーで処理され、プロジェクトとしては扱われない。ただかなり大型の案件となると、誰かが責任を持って調整する必要が出てくる。それが本来はプロマネ役なのだが、「プロジェクト」という認識と、それに必要な体制・権限が曖昧な場合もある。<br />
<br />
<br />
結局、プロジェクト型ではない普通の企業における問題とは、プロジェクトが「プロジェクト」として認知されていないところと、スコープが柔らかい点にある。プロジェクトと認識されていないのだから、プロジェクト・マネジメントの方法論などを期待しようがない。そういった企業に、精緻で定量的なモダンPMの技術を持ってきても、スコープの柔らかさのために役立たない。<br />
<br />
<br />
<br />
<br />
プロジェクト・マネジメント能力の発展段階<br />
<br />
<br />
<br />
「ふつうの企業」では、ほとんどが機能型組織の形態をとっている。部門が営業、設計、購買など専門的機能ごとに分かれている。プロジェクトは部門横断的な取り組みだが、プロマネの役割と権限が曖昧な「弱いマトリクス型組織」では、うまくプロジェクトを進められない。全体を見てコストや納期をタイムリーに決断する、意思決定の仕組みが欠けているからだ。<br />
<br />
<br />
これこそが、日本の製造業が過去30年間の間、競争力を落としてきた原因の一つだと、わたしは考えている。なぜなら、製品開発や事業開発の取り組みが、スピーディーにうまく回らないからだ。そのために必要なのは、モダンPMとかEVMS以前の、基礎的な仕組みや人財側の能力であろう。<br />
<br />
<br />
とくに、柔らかい（ソフトな）スコープの中で、どう意識決定し、どのように価値あるアウトカムを創出していくかが、問われる。ちなみにモダンPMが得意なはずの(A)型の企業だって、自社内で行う自発型プロジェクトは、必ずしも上手ではない。マネジメントの観点が違うからだ。<br />
<br />
<br />
ふつうの会社にとって、プロジェクト・マネジメント能力の発展段階はこんな風なステップになるのではないか。<br />
<br />
<br />
レベル１：「プロジェクト」を認知し「定常業務」との違いを理解する<br />
レベル２：プロジェクト遂行に必要な組織・役割・権限・ツール類を整備し、、キーパーソン層のソフトスキルを高める<br />
レベル３：プロジェクト・マネージャー職種を確立し、マネジメント技術を獲得・蓄積する（企業文化の中に組み入れる）<br />
<br />
<br />
わたしのような外部コンサルタントは、レベル２・３のお手伝いはできる。しかし最初の１は、経営層の「気づき」が必要だ。自分の真の「ニーズ」を知ってはじめて、学びのステップを登ろう、との気持ちが起きるからだ。それがたとえ、失敗のペインを通した気づきであっても、学びのニーズこそ、組織と人を育てる原動力なのだから。<br />
<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/202602/08/47/e0058447_22332236.png" alt="_e0058447_22332236.png" class="IMAGE_MID" height="354" width="500" /></center><br />
<br />
<br />
＜関連エントリ＞<br />
「製造業のプロジェクトがうまく進まない、本当の理由」  (2024-12-01)<br />
]]></description>
      <dc:subject>B1 プロジェクト・マネジメント全般</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Sun, 08 Feb 2026 22:36:15 +0900</pubDate>
      <dc:date>2026-02-08T22:36:15+09:00</dc:date>
    </item>
    <item>
      <title>モダンPMへの誘い　〜　プロジェクトのActivity間には4種類の依存関係がある</title>
      <link>http://brevis.exblog.jp/33883118/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33883118/</guid>
      <description><![CDATA[プロジェクトのクリティカル・パスとロジック・ネットワーク<br />
<br />
<br />
<br />
プロジェクトの全体工期の長さを決めるクリティカル・パスとは、そのプロジェクトを構成するActivityからなるロジック・ネットワークにおいて、開始点から完了点までを結ぶ種々の経路の中で、最長の経路を指す。プロジェクトの工期を短くしようとしても、クリティカル・パスが「つっかい棒」のように邪魔をして、それ以上短縮できないからである。そしてロジック・ネットワークとは何かというと、プロジェクトを構成する全てのActivityを、お互いの先行→後続の依存関係にしたがってつなげて表示した、有向グラフである。<br />
<br />
<br />
プロジェクトをActivityのネットワークとして理解する、という概念は20世紀の半ばに、アメリカ人達がはじめた。1950年代のことで、プラント建設プロジェクトにとりくむ化学企業デュポン社のエンジニアと、ポラリス・ミサイルの開発プロジェクトに携わった海軍のコンサルタント、ブーズ・アレン・ハミルトン社の人びとであった。クリティカル・パス概念自体は、デュポンで生まれた。そして、プロジェクトをこのような「要素的作業=Activityのネットワーク」としてのシステムと理解し、そのシステム工学的な性質をとらえ、数値的にマネジメントしよう、という発想が、『モダンPM』の始まりだった。<br />
<br />
<br />
その後、クリティカル・パスの計算手法が発達するとともに、プロジェクトのより具体的な構成や制約条件も、取り込みたいとのニーズが高まった。たとえば初期には、Activityの間には、「先行」→「後続」という直列的な依存関係しか考えられていなかった。しかし現在は、依存関係には4種類がある、と考えられるようになっている。<br />
<br />
<br />
4種類とは、先行と後続それぞれのActivityに、開始（Start）と完了（Finish）があるので、かけ算で4つのバリエーションが生まれることを指す。すなわち、以下の4種類だ。<br />
1. Finish to start (略称FS)<br />
2. Start to start (略称SS)<br />
3. Finish to finish (略称FF)<br />
4. Start to finish (略称SF)<br />
<center><img src="https://pds.exblog.jp/pds/1/202601/31/47/e0058447_19075803.png" alt="_e0058447_19075803.png" class="IMAGE_MID" height="393" width="500" /></center><br />
<br />
<br />
FS型・SS型・FF型の依存関係<br />
<br />
<br />
<br />
さて、Activity間の4種類の依存関係のうち、最もベーシックで、実務でも最も多く使われるのがFinish to start (FS)である。先行Activityが完了したら、後続Activityが開始できる。設計が完了したら、実装が開始できる。資機材の調達が完了したら（＝入荷したら）、据付作業が開始できる。例の枚挙にはいとまがない。資機材が入荷もしていないのに、据付ができる訳がない。設計も終わっていないのに、作り始めるのは愚かである。これは分かりやすい。<br />
<br />
<br />
Start to start (SS)とは、どんな依存関係か。それは、先行Activityが開始したら、後続も開始できるという関係だ。ただ通常は、この二つのStart日時の間に、一定の期間が挟まる。これを英語ではLagと呼ぶ。<br />
<br />
<br />
たとえば、家やマンションの塗装工事を考えよう。塗装は普通、下塗りと上塗りの2工程からなっている（場合によっては中塗りを入れて3工程）。下塗りをしたら、それが乾燥する（落ち着く）まで一定の時間がかかる。それを待ってから、本塗りをする。だが、下塗りを建物全体に行って、それが全部乾いてから、上塗りを開始するかというと、そんなことはしない。たとえば1階部分の下塗りが乾いたら、そこの上塗りを開始する。同時に、まだ2階や3階の下塗り作業が続いているかもしれない。だが一定の日数をはさめば、下塗りと上塗りの2つのActivityは並行して進めるのだ。こういうときに、Start to start (SS)の依存関係を使う。<br />
<br />
<br />
では逆に、Finish to finish (FF)を使うのは、どんな場合か。たとえば設計書を作成するActivityと、そのレビューを行うActivityなどがその例だ。設計書が多数ある場合、レビューはできたものから順次着手して、並行して進む。しかし設計書が全部完成しないうちに、レビューだけ勝手に完了できる訳がない。最後の部分のレビューに必要な期間が、Lag日数になる。<br />
<br />
<br />
<br />
<br />
SF型の依存関係の、本当の意味<br />
<br />
<br />
<br />
ところで、最後のSatrt to finish(SF)型とは、どんな依存関係だろうか。先行Activityが開始しないと、後続Activityが完了できない？　なんだそりゃ？　こんな関係、意味が分からん。<br />
<br />
<br />
ということで、これは理屈だけのもので、現実には意味がないと考える人も、ときどきいる。事実、実務でもまあ、たまにしか使わない。だが、使うときはあるのだ。それは、どんなケースか？<br />
<br />
<br />
実は、上のような図は、ミスリーディングなのだ。本当はSF型は下のように理解すべきである。<br />
<center><img src="https://pds.exblog.jp/pds/1/202601/31/47/e0058447_19092056.png" alt="_e0058447_19092056.png" class="IMAGE_MID" height="217" width="500" /></center><br />
すなわちSF型依存関係とは、「後続Activityがスタートしたら、先行Activityを完了できる」というケースなのである。英語のtoという語は、ここでは時間的な前後関係ではなく、論理的な依存関係を示している。たとえば、システム移行に伴って、旧型システムの運用は、新型システムの運用が開始したら、終了できる。後続の開始が遅れたら、先行Activityの期間も伸びてしまう。後続が開始しない限り、先行は完了できないという関係を、SF型は意味しているのだ。<br />
<br />
<br />
ということで、Activity間の依存関係はやはり、4種類必要なのである。クリティカル・パスをベースにしたスケジューリング・ソフトウェアも、これら4種類の関係を定義できる機能を取り込むようになった。その種のソフトの代表格が、普及価格で手に入るMicrosoft Projectと、プロ用のツールであるPrimavera Project Planner（通称P6）である。<br />
<br />
<br />
プロジェクト・スケジューリング・ソフトを導入すると、なんとなく自分たちもすぐに、プロジェクトをうまくマネージできるような気分になる（ソリューションの売り手側も、そういう気分を盛り上げて、販売促進をするわけである）。でも、4種類の依存関係をちゃんと理解して使いこなせるようになるまでは、まだ習熟の期間が必要だ。ソフトの導入完了と、実務の運用能力アップの開始には、だからFinish to Startの関係の上に、Lag日数があるのである。<br />
<br />
<br />
<br />
<br />
＜関連エントリ＞<br />
「モダンPMへの誘い　〜　クリティカル・パス法は役に立つのか？」 x (2025-04-02)<br />
「ロジック・ネットワーク・スケジュールとは何か」  (2007-11-25)<br />
]]></description>
      <dc:subject>B3 プロジェクト・スケジューリング</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Sat, 31 Jan 2026 19:14:31 +0900</pubDate>
      <dc:date>2026-01-31T19:14:31+09:00</dc:date>
    </item>
    <item>
      <title>本を読む事、本を最後まで読むこと（＋ 書評：「ペスト」　A・カミュ著）</title>
      <link>http://brevis.exblog.jp/33877780/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33877780/</guid>
      <description><![CDATA[わたしにとって読書とは<br />
<br />
<br />
<br />
昨年（2025年）、ちょうど20冊本を読んだ。わたしが「本を読んだ」というときは、本を最初から最後まで、全ページ読んだ、という意味で使っている。一部の頁を読んだだけの時は、「見た」ということにしている。見た本はもちろん、もっと多い。だが、読み通すつもりのものが、ほとんどだ。辞書や一部の規格書・法律書など例外はあるが、基本的に読み通すつもりで、本は買う。<br />
<br />
<br />
月2冊程度だから、わたしは決して読書家ではない。学生の頃は年に100冊程度読んでいたが、働いて、家庭生活も持つと、読書時間は削らざるを得ない。わたしの主な読書タイムは電車の中である。しかし最寄り駅から勤務先まで3駅・10分足らずだし、外出や出張時には寝落ちしていることが多くて（汗）、ちっともはかどらない。<br />
<br />
<br />
わたしにとって読書は、仕事ではなく勉強でもなく、趣味である。自分ではビジネス書を書いているくせに、ビジネス書はほとんど読まない。仕事から離れたら、仕事以外のことを考えたいからだ。小説もあまり、読まない。自分はあまり、物語を好むタイプでは、ないらしい。物語が好きな人は、小説だけでなく、経営書にも物語を読み取り、スポーツにもドラマを感じるのだろう。感情的価値を、欲しているのだ。わたしはむしろ、知る喜びの方が、面白い。<br />
<br />
<br />
なぜ読み通すことが大切か<br />
<br />
<br />
<br />
本を読み通すのには、時間がかかる。近頃は有名書ならネットでサマリーを見ることができるし、あまり大部でなければ生成AIに要約してもらうことだって可能だ。しかし、わたしはそうしない。自分の本、たとえば「BOM/部品表入門」でも「時間管理術」でもいいが、そういう風に読まれるのを好まないからだ。<br />
<br />
<br />
書いている立場から言わせてもらえるなら、あれだけの長さと厚みになるのは、相応のロジックの流れと対話（＝多面的な検討）の積み重ねが必要だからだ。それをすっ飛ばしたら、肝心のメッセージがよく理解できなくなる。よく理解できなければ、結局、自分の身について使えなくなる。読書前と読書後で、自分が何も変わらないなら、読書は知的消費ではあっても、知的投資（学び）ではないことになる。知的消費にしたって、小説がそれなりの長さなのは、そうしないと表現できないことがあるからだ。<br />
<br />
<br />
どれほど短い時間で、知識と情報を得られるか、そのタイパを追求するのが今の流れらしい。知識は資産である。また、人より先に「知ってる」と、自己承認欲求も満足できる。しかし、「知ること」と「理解すること」の間には、大きな距離がある。<br />
<br />
<br />
人は知識と記憶力だけでは、賢くならない。複雑な社会で物事を判断するためには、構造を洞察し予測する力が、とても大切だ。またリーダーシップを発揮して人を動かしたかったら、他人の見方考え方を知る必要がある。こうした能力を得るためには、知的時間がいるのだ。それも、それなりの長さと深さで。読書はそのための、大事な階（きざはし）だ。<br />
<br />
<br />
<br />
<br />
長い文脈を理解する能力を得よう<br />
<br />
<br />
<br />
また知的消費（別に消費はわるいことではない）の面を考えても、深い感情的体験には没入の時間、文脈の共有が必要である。長い文脈を、感情とともに体験し保持できる力。それは今のところ、普通の人間でも生成AIに決して負けずに持つ、知的能力の一つなのだ。<br />
<br />
<br />
せっかくそうした能力があるのに、切れ切れな知識情報ばかりを相手取って過ごしたら、どうなるか。いつの間にか、流れてくる情報に踊らされ、巻き込まれて搾取される側になる事だって、ありうるだろう。<br />
<br />
<br />
何年か前、ある著者の方が、有名な書評ブロガーに会った際の話を読んだ。そのブロガーさんは、進呈された本をパラパラと15分ほど目を通した後、さっそくブログに書評をアップしたのだそうだ。そういう芸風なのだろう。だが、そのまねは自分にはできない。わたしは基本的に、書評は全頁を読んだ本しか、書かないことにしている。本は最後まで読むこと。それが、零細ながら著者でもあり読者でもある、自分の信条なのだ。<br />
<br />
<br />
ということで、今回は近年読んだ小説の中でも最良の一作、カミュの「ペスト」の書評をかかげることにしよう。<br />
<br />
<br />
<br />
<br />
書評：「ペスト」　アルベール・カミュ著<br />
<br />
<br />
「ペスト」（新潮文庫版　Amazon.com）<br />
<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/202601/24/47/e0058447_19471616.png" alt="_e0058447_19471616.png" class="IMAGE_MID" height="640" width="480" /></center><br />
本書を最初に読んだのは20年以上も前のことだったと思う。その時は、「重厚なSFだな」という感想をメモに残しているが、それ以上のことはなぜか、記憶に残らなかった。<br />
<br />
<br />
<br />
この小説を「SF」と分類する人はまず、いない。ノーベル文学賞作家アルベール・カミュによる純文学だ、と位置づけれらているからだろう。でも、思索上は可能だが、現実にはありそうもないと誰もが思うシチュエーションを、想像力をもとに科学的知識も加えてストーリー化し、その中で人間性の本質を描き出すのがSFだ。だとしたら、まさに直球ど真ん中の小説ではないか。<br />
<br />
<br />
物語は、北アフリカ・アルジェリアの地方都市オランで起きる。まだフランスの植民地だった時代だ。その街で、死んだ鼠が次々と見つかるようになる。そして、それを追うように、高熱で苦しむ患者が少しずつ増えていく。主人公の医師リウーが、最初の患者の死を看取るまで、わずか20頁あまり。押さえた筆致ながらぐいぐいと読者を引き込んでいく。<br />
<br />
<br />
街の医師達は、蔓延しつつある疫病がペストである、ということをなかなか認めようとはしない。だが政府（総督府）は電光石火、街を封鎖する。疫病と都市封鎖。これが西欧では歴史的にワンセットだという事が分かる。そして外部との交通も通信も事実上遮断され、その日を境に、家族や友人や恋人も突然分断されて、人びとのドラマはにわかに深刻化する。<br />
<br />
<br />
この小説には重要な登場人物として、バヌルー神父という宗教者が登場する。彼は最初、この疫病は神が人間の目を覚まさせようと与えた劫罰なのだ、と教壇から信徒達に説教する。しかしその後、疫病の最前線で患者達を、彼なりに助けて回ろうとすようになる。<br />
<br />
<br />
著者のカミュは神を信じない人間だ。それはフランス的社会の中では、キリスト教会とその権威に反対する、という意味である。だから、この登場人物のフェアな扱い方とその悲劇を通して、最も重要な問いを提出する。主人公の友人がこう言うのだ。「人は神によらずして聖者になりうるか——これが、僕の知っている唯一の具体的な問題だ」（P.307）<br />
<br />
<br />
政府の助けも、神の助けも、そして緊急輸入した血清医学の助けも十分に得られぬまま、それでも街の人びとは保険隊を結成し、医師リウーを中心に団結して、可能な限り疫病と闘い続ける。<br />
<br />
<br />
この小説は第二次世界大戦の終結直後、1947年に発刊され、瞬く間にベストセラーになった。「人間を絶滅させる悪との闘争を描く」と背表紙の解説にあるが、人びとは何年間も世界を覆い尽くし分断した戦争の災厄と、ペストとを重ね合わせて読んだだろう。<br />
<br />
<br />
わたし達はあの世界的規模のパンデミック禍、恐ろしくも奇妙な「新型コロナウイルスに閉ざされた数年間」を経験した。今や人びとは、まるで何事もなかったかのような顔をしている。だが、いかに忘れたふりをしようとも、決して忘れられぬ、息の詰まる時間だった。それをわたし達は、団結して乗りこえたと言えるのだろうか。次にまた災厄が襲ってきたとき、連帯して互いに助け合えるような賢さと勇気を、わたし達は本当に発揮することができるのだろうか？　ちょうどこの小説の中で、港町オランの人びとが示したように。<br />
<br />
<br />
<br />
]]></description>
      <dc:subject>G 書評</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Sat, 24 Jan 2026 19:48:02 +0900</pubDate>
      <dc:date>2026-01-24T19:48:02+09:00</dc:date>
    </item>
    <item>
      <title>生産管理システムの設計・導入は、なぜ販売管理や経理システムより難しいのか</title>
      <link>http://brevis.exblog.jp/33873612/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33873612/</guid>
      <description><![CDATA[上司にレポート作成を命じられたら<br />
<br />
<br />
<br />
月曜の朝一番、あなたは上司に呼ばれて、ある件に関するレポートを作成するように命じられる。それなりの内容だ。部内の過去の資料などを調べ直さないといけない。3日位はフルにかかりそうな仕事だ。それを今週中に提出してほしいと言う。あなたは他にも定常業務を抱えていて、今その1つに着手したばかりだ。さて、どうするか。<br />
<br />
<br />
<br />
1つの考え方は、やりかけの仕事は脇において、そのレポート作成にすぐ取り組むことだ。早ければ水曜日の夕方には終わるだろう。やりかけの定常業務は、木曜の朝から再開すれば良い。その方が気が楽だし、書き上げたレポートをブラッシュアップするチャンスもあるだろう。<br />
<br />
<br />
しかしもちろん別の考え方もある。金曜日の夕方に提出すれば良いのだから、ギリギリ水曜日の朝に着手すれば間に合うはずだ。そうすれば一旦、着手しはじめた定常業務の方を、先にある程度片付けることができる。頭脳労働というものは、途中で腰をおられると再開するまでに時間がかかり、その間、能率も落ちる。<br />
<br />
<br />
早めに着手するか、ギリギリでの完成を狙うか。あなたには選択の余地がある。考えなければいけない因子もいくつかある。やりかけの仕事を中断して、生産性の低下を我慢するかどうか。作成するのに3日かかると見積もったが、その見積もりはどれくらい正確なのか。一旦完成した後で、品質向上のチャンスを残したいかどうか。そして週末に気楽な気分になって、気になっているカノジョに飲みに行こうと声をかけたくなるかどうか…etc, etc。<br />
<br />
<br />
<br />
<br />
指示のためには基準と目標が必要<br />
<br />
<br />
<br />
別にそんな「白か黒」みたいに固く考える必要は無いのではないか。金曜までの間に思いついた時だけ少しずつやれば良い、そんな感想もあるだろう。それはこの仕事をあなた1人だけでやる場合だったら正しい。しかし、仕事の1部を後輩や部下に分担してもらうのだったら、どうだろう。 その時には、仕事の内容やアウトプット、そして期限などを決めて伝えなければならない。ちょうどあなたが上司からそうされたように。<br />
<br />
<br />
できるだけ早く着手するか、それとも可能な限りギリギリの完成を狙うか。スケジューリングの分野では、前者を「フォワード・スケジューリング」、後者を「バックワード・スケジューリング」と呼ぶ。<br />
<br />
<br />
この2種類は、どちらもプラスとマイナスがある。 前者の方針をとると、定常業務の生産性が一旦落ちる上に、成果物が完成してから上司に提出するまで、手元に二日間とどまることになる。いわば仕掛在庫になるわけだ。「在庫（＝作りすぎ）のムダ」を嫌うジャスト・イン・タイム生産の基準に 従うなら、ギリギリの完成を狙うことになる。 しかしその場合、「三日間」と言う作業期間の見積もりが甘かった場合、納期遅れになるリスクが生じる。飲み会を考える気分的余裕はないかもしれない。<br />
<br />
<br />
品質を取るか、生産性を取るか。週末の自由度を取るか、納期リスクを取るか。指示を出す人は、決めなくてはならない。誰かに指示を出すときには、決断のための基準がいる。 その基準は、QCDなどのKPIの内、どれを重視するのかとリンクしている。 もちろん毎回個別に考えてもいい。だが、指示を出す業務をITシステム化するときには、何らかの基準と目標を設定する必要がある。<br />
<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/202601/18/47/e0058447_18364179.png" alt="_e0058447_18364179.png" class="IMAGE_MID" height="193" width="500" /></center><br />
<br />
<br />
生産管理システムの特徴＝指示を出す仕組みであること<br />
<br />
<br />
<br />
知人のコンサルタント本間峰一氏は以前、「生産管理システムには魂を入れる必要がある」と解説しておられた。うまい表現だと思う。では生産管理システムに入れるべき「魂」とは何か。上で述べた基準や目標値の取り方は、明らかにその重要な要素である。<br />
<br />
<br />
生産管理システムは、販売管理や経理システムなどとは、かなり違う性格を持っている。販売管理システムは、基本的に営業マンに指示を出さない。売上目標ぐらいは与えるかもしれないが、具体的にどの顧客を訪問し、どう喋って何を売り込め、というような指示は出さない。それらは全て営業マンたちが自分の頭の中で判断して決める。<br />
<br />
<br />
そして販売業務の結果、引合や注文を受け取ったら、結果を販売管理システムに入力し記録することになる。経理システムも同様だ。経理部門のユーザに対し、何を買えとか、いくら借りてこい、とか指示を出すわけではない。業務の指図と手配は、全てユーザが頭の中で行って、その結果を記録するだけだ。<br />
<br />
<br />
ところが、生産管理システムは違う。上にのべたレポート業務との類推で、考えてみて欲しい。レポート作成の代わりに、生産ではどの部品を手配し、どの工程でいつ着手するのか、どのサプライヤーに発注するのか、すべて指示が必要だ。そうした指示は基本的に、システムが決めて出力することになる。<br />
<br />
<br />
もちろん指示の作成・発行は、設定したルールや基準に従って行うわけだ。そして指図を現場に伝えて、初めて実際の業務が動き始める。指示の決め方の基準やルールに応じて、結果の品質や納期やコストといったパフォーマンスが、大きく左右されることになる。<br />
<br />
<br />
だから、どういうルールや基準に基本的に従うのかを、ユーザたちが選び、設定できるようにしなければならない。これこそが「システムに魂を入れる」部分なのだ。販売管理や経理システムでは、魂を入れる必要は無い。魂は、実際の指示や業務を行う人たちの頭の中にあるからだ。<br />
<br />
<br />
<br />
<br />
<br />
生産管理システムの難しさは機能面よりも、業務ルールとKPIの因果関係理解にある<br />
<br />
<br />
<br />
生産管理システムは複雑だ。BOM＝部品表をはじめ、多数のマスタがあり、画面数もトランザクションも多く、外部I/Fだって、各種あり得る。だから担当SEは、全体の仕組みを理解するだけでも、かなりの勉強時間を必要とする。無論、販売だって経理だって、システムはそれなりに複雑で、その点では本質的な違いはない。しかし生産管理系の難しさの中心は、IT側にはない。本当に理解すべきなのは、工場という仕組みとその組織、そして生産業務を構成する諸要素と結果（KPI)との、因果関係にある。ここが実に、分かりにくい。<br />
<br />
<br />
なぜ、分かりにくいのか。意外に思うかもしれないが、じつはユーザーである製造業の側に、それをちゃんと説明してくれる人が少ないからだ。日本の製造業の多くは縦割り組織になっていてサイロ化が進み、工場業務の全体像を知っている人がほとんど、いない。仮にいたとしても、自分の業界のこと以外は、普通は知らない。<br />
<br />
<br />
製造業の業務は、生産形態にしても生産方式にしても、非常にバラエティが大きい。生産管理システム・パッケージは普通、できる限り広い業種業態をカバーしようとする。特定業種に適用するには、一種の「翻訳」が必要になる。それに、製造業が高度成長期から令和の現在までに、どのような変化に直面しているのか、それが目標設定にどう影響するのかも、ふつうのユーザは説明できない。<br />
<br />
<br />
それだからこそ、（ここから少し手前味噌的になるが）幅広い製造業を長年相手にしてきた、エンジニアリング会社だとか生産系コンサルタントといった職種が役に立つのだ。新著『攻めの工場づくり』のような本は、製造業の人ではあまり、書けない。工場の仕組みをゼロからスクラッチで構想し、設計・実装する仕事は、ふつうの企業ならよくて10年に1度程度しかない。だがエンジ会社は、ずっと工場づくりを繰り返している。そして工場のハードウェアは、生産管理のソフトウェアと、ワンセットなのである。<br />
<br />
<br />
生産をきちんとマネジメントしたかったら、ITシステムの機能や構造を理解するだけでは十分ではない。基準に従って出る指示が、どう実際業務を動かし、その因果関係がどう生産のQCDなどのパフォーマンスにはね返るかを、知らなければならない。冒頭のレポート作成を見れば分かる。すぐ着手するよう指示すべきか、ぎりぎり完成するよう指示すべきか。そのプラスとマイナス、トレードオフを意識できるようになって、はじめて有用なシステムが作れるのである。<br />
<br />
<br />
＜関連エントリ＞<br />
「なぜ生産管理システムはちゃんと機能しないのか」  (2015-10-07)<br />
]]></description>
      <dc:subject>A1 生産マネジメント全般</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Sun, 18 Jan 2026 18:38:12 +0900</pubDate>
      <dc:date>2026-01-18T18:38:12+09:00</dc:date>
    </item>
    <item>
      <title>お知らせ：生産統制セミナー（1/28）と、MES関連インタビュー記事公開</title>
      <link>http://brevis.exblog.jp/33867475/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33867475/</guid>
      <description><![CDATA[お知らせが2点あります。<br />
<br />
<br />
1点目はリアル参加型の1日研修セミナーで、来る1月28日（木）に大阪で開催します。テーマ名は「生産統制」ですが、計画（Planning）と統制（Control）は車の両輪ですので、前半は生産計画についてきちんと学ぶ構成としています。そして全体を通しては、「納期遅れを防ぐ」がテーマです。コストダウンでも品質でもなく、スケジュールに焦点を当てる。これが特徴です。<br />
<br />
<br />
この大阪府工業協会さんの生産統制セミナーは10年ほど前にお引き受けし、年1〜2回程度のペースで開催してきました。主な受講対象の方は、協会会員企業である関西圏の製造業、どちらかといえば中堅中小メーカーの実務クラスの方が中心です。こうした企業は、大手セットメーカー（OEM）からの受注生産形態が中心で、しかも品種数も多いため、納期問題に悩むのが常です。<br />
<br />
<br />
『生産管理』（Production Management）と呼ばれる仕事の範囲は企業によって様々ですが、わたしはその主要なタスクを、下の図のように整理しています。仕事は大きく計画（Planning）と統制（Control）に分かれます。<br />
<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/202601/10/47/e0058447_12411677.png" alt="_e0058447_12411677.png" class="IMAGE_MID" height="281" width="500" /></center><br />
<br />
<br />
計画は、(1)製品単位の基準計画、(2)部品・工程展開、(3)生産スケジューリング、(4)指示発行（ディスパッチング）の順に進みます。<br />
<br />
<br />
他方、統制は4種類のタスクを並列にならべています。(5)工場パフォーマンスの測定（QCDや在庫・リードタイム等）、(6)計画と現実の乖離調整、(7)製造資源のモニタリング、(8)個別作業・モノ・情報のトラッキングと優先づけ、の4つで、これらは並行して進めねばなりません。このような整理の仕方は伝統的な生産管理の教科書とは違いますが、今日の工場で求められている業務内容や主要課題に沿っているつもりです。<br />
<br />
<br />
このように生産マネジメントは幅広い業務であるにもかかわらず、多くの企業ではここに、スキルのある人財を十分に配置しているとは言えない状況にあります。仕事は多いのに人手不足なのです。そこで本セミナーでは、上記の中から(3)生産スケジューリングと(6)計画と現実の乖離調整に焦点を当てて、納期遅れ問題に取り組む基本を学びます。<br />
<br />
<br />
具体的には、部品材料の在庫量の計算法（在庫理論）からはじめて、リードタイムの概念と求め方（生産スケジューリング）、カップリング・ポイントを用いたリードタイムの短縮（マテリアル・マネジメント）、ボトルネック中心の生産統制（ただ一つの管制塔を持つ）などをご説明します。<br />
<br />
<br />
納期問題が主題なのに、在庫理論からはじめるのは奇妙に感じられるかもしれません。一つには、在庫とリードタイムが表裏一体の関係にあるからです。が、それよりもまず、「マネジメントにはちゃんと理論も計算式もあるのだ」という事を実感していただくために、こうした構成にしています。なぜなら多くの企業では『生産管理』を、労務管理か何かの延長、いいかえるとルールと号令の仕事（＝文系の業務）、だと思い込んでいるらしいからです。これでは科学的マネジメントの方法論を展開してきた欧米企業や、それに学んでいる中国企業などに勝てる訳はありません。<br />
<br />
<br />
本セミナーは1日がかりでリアル参加型です（有償）。オンライン配信型よりはハードルが高く、関西圏の方が主になるとは思いますが、その代わり実際にクラスルームで議論し手を動かしていただくことによって、より理解度が深まると思います。直前のお知らせになってしまいましたが、大勢の方のご参加をお待ちしております。<br />
 <br />
<br />
<br />
＜記＞<br />
<br />
<br />
日時：　2026年1月28日（水）　9:45～16:45<br />
テーマ：　「納期遅れを起こさない 生産統制のポイント」<br />
主催：　公益財団法人　大阪府工業協会<br />
会場：　大阪府工業協会 研修室<br />
セミナー詳細・申込み：　下記Webサイトをご参照ください<br />
https://www.opmia.jp/seminar/4557/<br />
<br />
 <br />
<br />
<br />
<br />
<br />
もう一点、お知らせです。<br />
<br />
<br />
上図で、下側に赤い点線で囲んだ領域は、しばしば『製造管理』ないし『工程管理』と呼ばれます。そしてMES（製造実行システム）は主に、この領域をカバーする仕組みとして、近年急速に注目を集めています。<br />
<br />
<br />
今なぜ、MESが注目されるようになってきたのか、また、MESの構想づくりやベンダー選びの障害となっているものが何で、いかにそれを乗りこえるべきかについて、WebメディアであるMONOistにインタビュー記事が掲載されました。<br />
<br />
<br />
「なぜ工場のスマート化には、MESが必要なのか」<br />
<br />
<br />
本記事はアビームコンサルティングの阿部洋平氏との共同インタビューで、前半は主にわたしが話し、後半は阿部さんが説明されています。阿部さんは、わたしが主幹事を務める（財）エンジニアリング協会「次世代スマート工場」研究会で、『MES/MOM導入のための標準業務一覧』  策定プロジェクトのプロマネでもあります。こちらもぜひ、あわせてご覧下さい。<br />
<br />
<br />
<br />
ちなみに、このMES標準策定プロジェクトチームが中心になり、現在、MESに関する総合的な解説書を作る構想が進んでいます。タイトルは仮称『新・MES入門』。もちろんこれは、2000年に発刊されて今は入手困難となっている「MES入門」（中村実・正田耕一編、わたし自身は第3章を執筆）の、いわば後継書をねらったものです。もし実現できれば、夏過ぎには発刊になる見込みです。こちらもぜひ、ご期待下さい。<br />
<br />
<br />
<br />
]]></description>
      <dc:subject>A1 生産マネジメント全般</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Sat, 10 Jan 2026 12:54:09 +0900</pubDate>
      <dc:date>2026-01-10T12:54:09+09:00</dc:date>
    </item>
    <item>
      <title>時計を合わせよう</title>
      <link>http://brevis.exblog.jp/33863955/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33863955/</guid>
      <description><![CDATA[時計は正確でなければならない、なぜなら・・<br />
<br />
<br />
自宅のリビングの窓際に、クリスマス・カクタスの鉢を置いている。小さな緑のサボテンだが、いつもクリスマスの時期になると深紅の花を咲かせる。どうして植物は目も耳もないのに、正確に時を知ることができるのだろう。いつも不思議に思う。時を知るとはどういう事なのか。<br />
<br />
<br />
「時計の針を進ませておいてはいけない」と、亡き父はいった。よく、『時間に遅れないために』時計の針をわざと数分進ませておく人がいる。時間のゆとりを確保しておくためだ。だが、父はそうした意見に反対だった。家の時計は正確に合わせておくよう、母に命じた。なぜなら、「時計は計器である」。それが技術屋だった父の答えだった。<br />
<br />
<br />
計器は正確でなければ役に立たない――それが技術者の感覚だ。安心や余裕のために、計器の針をずらしてはいけない。たとえば体温計を考えれば分かる。体温計は計器だ。『健康のために』体温計を0.2～0.3℃、上げておく人がいるだろうか？　事実が分からなくなったら、計器の役には立たない。<br />
<br />
<br />
ちなみに計器は英語でInstrumentという。これは多義語で、器具や楽器を指す言葉でもある。ただしこれを動名詞化してInstrumentationというと、計器を使った制御、すなわち計装のことを指す（日本で最初にInstrumentationを「計装」と訳したのは、父の働いていた会社だったらしい）。<br />
<br />
<br />
話を戻すが、計器にはときどきキャリブレーション（較正）が必要である。居間の時計をTVの時報に合わせたりするのが、キャリブレーションだ。仕事で使う計器は、定期的に（必ずしも使うたび毎回ではないだろうが）、この作業が必要になる。その間は設備が使えないので、生産性を下げてしまう。無論、較正は必要である。だが生産性が至上命題の組織や社会で、この種の仕事がどう位置づけられるか、想像に難くはあるまい。当然、後回しになる。そして情報は次第に、正確さからズレていく。<br />
<br />
<br />
<br />
<br />
サーバの時刻同期化問題<br />
<br />
<br />
もう20年以上も昔のことになるが、わたしはあるプロジェクトで、発注先の米国のSIerからの追加請求の交渉に直面していた。彼らのクレーム（請求項目）の一つに、サーバ間の時刻同期の問題があった。複数のサーバ群からなる、MESと制御系システムを発注している。当時のことだから、サーバは全て物理サーバで、オンプレミスである。<br />
<br />
<br />
サーバ群のクロックを同期する仕組みを構築する作業は、最初の仕様書に明記されていないから追加役務だ、金を払えというのが、彼らの主張だった。発注側であるわたし達は、「そんなこと当然だろ」のスタンスだ。最初、議論は平行線だった。しかし対象の制御系DCSから時系列データを、MESの一部であるPI SYSTEMに送るとき、時刻がズレて未来のデータになると、MES側が受け取れない。これはパッケージの仕様であった（当時）。しかも彼らは直前に、同等構成のシステムを顧客に納めているのだから、知らなかったはずはない。これを理由に、追加をはねつけた。<br />
<br />
<br />
しかし交渉は複数項目の間の駆け引きでもあるので、この件で逃げ切れたのはラッキーだったと思う。ただ、わたしはその時に、キャリブレーションといっても、絶対値に合わせることと、相対的に合わせることの二種類があるのだ、という事を学んだ。相対的に合っているだけでも役に立つ場合があるのだ。<br />
<br />
<br />
サーバ間の時刻同期は、ISA95でいうLevel-2以下の制御系と、Level-3のMESでは必須である。それぞれが単独で動いている場合は別に問題はない。だが協調して働くときには必須なのだ。そしてこのようなことは、いわゆるOT技術の分野では、昔から常識だった。そのために必要なNTPプロトコルだとか、あるいは近年注目されつつあるTime-sensitive Network (TSN)といった技術の詳細についは、ここでは割愛しておく。ただここでは、近代的なスマート工場を目指すとき、ロボットやマテハン機械でもおなじ問題が起きることだけ指摘しておこう。<br />
<br />
<br />
<br />
<br />
協調して働くということ<br />
<br />
<br />
OT分野ではずっと以前から常識だった時刻同期問題を、今さら取り上げたのは、これがまだIT分野では課題になりがちだと、最近感じたからだ。IT分野では、たとえ記録計のSoRであっても、秒を争うようなアプリケーションはごく少数だ。情報系のSoEなら、言わずもがな。ましてクラウド化が進めば、クロックの水晶時計のズレを心配する必要などないではないか。<br />
<br />
<br />
それが、そういってもいられれなくなってきたのは、セキュリティのためだ。サイバーセキュリティ技術は、リアルタイム性がかなり重要になる。悪意ある侵入や攻撃を、いかに瞬時に察知してはねつけるか。それなのにSSOと実体サーバが何秒もズレていては目も当てられない。<br />
<br />
<br />
ただ、そこであらためてクローズアップされるのは、「リアルタイム性」とはそもそも何か、という問題だ。そもそもこの感覚が、OT技術者とIT技術者の間で、基本的にズレている。「リアルタイムとは何か」については、以前このサイトでも書いた（今調べてみたら、もう15年も前だ）。簡単にかいつまんでいうと、「リアルタイム性とは、対象とする系の時定数よりも、有意に短いこと」なのである。ミリ秒とか、マイクロ秒とかがリアルタイム性の定義なのではない。対象とする相手よりも有意に速いかが、リアルタイムの意味なのだ。<br />
<br />
<br />
だから、体温を計るのに十数秒かかる体温計だって、リアルタイムなのだ。なぜなら人間の体温の変化は分とか時間単位でしか動かないからだ。機械式の時計は、1秒ごとに針が動く。それでも日常生活のスピードからはリアルタイムだ。昔、SAP社のERPはR/2とかR/3とかいう名前だった。あのRはReal-timeの頭文字であった。なぜなら、企業の会計は、一日単位で集計できれば、十分リアルタイムだからだ。企業経営の指針としての財務バランスは、そういうゆっくりした時定数で動いているからだ。<br />
<br />
<br />
計器はリアルタイム性が必要である。しかしそれは測定する対象系の「時定数」に依存する。この時定数の感覚、系（物理対象となるシステム）がどれくらいのスピードで変化するのか、に対する感覚こそが重要だ。そして人やモノが協調して働くときには、このリアルタイム性の中で、時を共有する必要がある。<br />
<br />
<br />
そういう意味で、組織の中に時代認識が違う人がいると、協力しにくい（たとえば人手不足問題などが、いい例かもしれない）。シニア世代と、中堅と、Z世代では、時の感覚が違う。なのにお互い、違いをきちんと認識して、同期することを諦めている。<br />
<br />
<br />
「時計は正確でなければならない」と、技術屋出身の、経営者でもあった父はいった。事実とデータに基づいて認識し、決断すること。それが、マネジメント判断の基礎である。そういう教訓が、この短い一言に現れている。今の世でいう「データドリブン・マネジメント」とは、すなわちデータに基づくマネジメント判断である。AIを使うかどうかは本質ではない。事実を客観的にとらえようとする態度の有無が、境目なのだ。<br />
<br />
<br />
だから事実を見て、お互い頭の中の時計を合わせよう。わたし達は協調して働けなければ、何事もなしえないのだから。<br />
<center><img src="https://pds.exblog.jp/pds/1/202601/05/47/e0058447_12431712.jpg" alt="_e0058447_12431712.jpg" class="IMAGE_MID" height="640" width="480" /></center><br />
＜関連エントリ＞<br />
「リアルタイムとは何か」  (2010-12-15)<br />
]]></description>
      <dc:subject>E1 マネジメントの技術論</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Mon, 05 Jan 2026 12:45:23 +0900</pubDate>
      <dc:date>2026-01-05T12:45:23+09:00</dc:date>
    </item>
    <item>
      <title>クリスマス・メッセージ：塵のようだが、ゼロではない</title>
      <link>http://brevis.exblog.jp/33853198/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33853198/</guid>
      <description><![CDATA[Merry Christmas !!<br />
<br />
感情への関心について<br />
<br />
<br />
<br />
当サイトを以前からご覧いただいている読者の方はお気づきだろうが、わたしは『感情』というテーマに、しばしば触れるようになってきた。その最初はおそらく2011年の「知識労働、肉体労働、そして『感情労働』」かもしれないが、2017年頃から少しずつ増えている、そうなった特段のきっかけがある訳ではないが、感情というものが人間を動かす大きな原動力となっていると気づいた、それが理由である（なお、ここでは感情を「感覚的・情緒的なもの」という広い意味で使っている）。<br />
<br />
<br />
言うまでもなく、当サイトのテーマは「計画とマネジメントの技術ノート」だ。技術と感情ほど、縁遠いものはない。技術は科学を基礎とした理知的な方法論で、かつ非属人的な移転可能なものである。感情の割り込む余地はない、はずだ。なのになぜ、感情を重要なファクターとして考えるようになったかというと、マネジメントが「人を動かす仕事」だからだ。<br />
<br />
<br />
自分で手を動かして、設計したりモノを作ったりする仕事は、もちろんとても重要で、それがなければ世の中は回らない。しかしマネジメントとは、自分で手を動かすことではなく、人に働いてもらうこと、少なくとも人と一緒に動くことである。そして、人と人との間には、必ずヒューマン・ファクターが働く。その大きな要因が、感情面だ。<br />
<br />
<br />
マネジメントにはテクノロジーがある、と長年わたしは主張してきた。人やモノをコントロールする業務プロセスを、誰もが一定のレベルで遂行できるようにする技術が、世には存在するのだ、と。それはたとえば、プロジェクト・マネジメント分野におけるPERT/CPM・EVMSだとか、生産マネジメント分野のスケジューリング・在庫理論などだ。これらの技術や理屈の中には、『感情』はもちろん登場しない。<br />
<br />
<br />
<br />
<br />
「（株）マネジメント・テクノロジー社」設立<br />
<br />
<br />
<br />
ちなみに余談になるが、わたしは最近、自分自身のための会社を作った。名前を「株式会社マネジメント・テクノロジー」という。従来から研修・セミナーや、コンサルティングなどの仕事を、中小企業診断士として受けてきた。ただインボイス制度の影響や、大企業の顧客だと個人相手の契約が難しいなどの問題があり、勤務先の承認を得た上で、いわば副業用にヴィークルを作った訳である。<br />
<br />
<br />
この「マネジメント・テクノロジー」という言葉は、数年前に惜しくも亡くなった勤務先の同僚、故・秋山聡氏が使い始めた用語だった。彼はこれをマネテクと略して、「まねてくニュース」というMLを社内で発信し続けた。なので会社名を登録するときに、故人の霊前に頭を下げ手を合わせ、無言の許可を得てから、登記した次第だ。<br />
<br />
<br />
そんなことをしなくても別段、法律上の問題は無い。ただ、それでは自分の感情面が落ち着かないのだ。なんだか、申し訳ない気がする。だから、そういう挨拶ないし儀式が必要だった。つまり感情というのは、人間の間の敬意に、結びついている。<br />
<br />
<br />
人と人との関係には、ほぼ必ず、感情が絡みつく。上下関係にも、勝ち負けにも、貸し借りにも、そして好き嫌いにも、すぐ顔を出す。だとしたら、人が人を動かすマネジメントの仕事に、感情が無関係でいるはずがない。加えて、モチベーションとかウェルビーイングといった人財・組織開発系のキーワードも、やはり感情的価値に関係している。<br />
<br />
<br />
ところが、（正直に告白するが）わたしは他者の感情に対する感受性が、著しく低い。そればかりか、自分自身の感情に対するセンシングも、うまくない。それでは、他者とよい協力関係で動けるはずがない。自分の感情に感度が低いので、いつの間にかメンタルに感情的負荷が高まっていても、その弊害に気づきにくい。これは心身的にもストレスだし、思考にも良い影響を及ぼさない。だから、感情というものに、ちゃんと向き合う必要を感じ始めた、ということだ。<br />
<br />
<br />
<br />
<br />
感情の底にあるもの<br />
<br />
<br />
<br />
しかしちょっと勉強しはじめて、不思議な気持ちになった（この「不思議」も感情ですね）。心理学・精神医学・脳科学など、さまざまな学問が感情に取り組んでいる。文学・芸術や哲学も、ずっと主題にしてきた。にもかかわらず、感情という現象は、とても未整理なのだった。よく「喜怒哀楽」というが、このリストアップは文化圏によっても異なる。人間の基本的感情はいくつに分類できるのか、それさえ不明である。<br />
<br />
<br />
感情にはポジティブとネガティブがあり、強さ弱さの強度があるから、4象限で付置できる、という理論もきいた。でも感情には時間的な波や、遷移もある。そうした動力学はどう扱うのか。そして、現象論は分かったとして、自分はどう感情に向き合い、付き合い、育てたら良いのか。なんだか五里霧中である。<br />
<br />
<br />
ただ、考えているうちに、感情とは制御システムで言うSV（Set Value = 目標値）とPV（Process Value = 現在値）の差異をあらわす状態信号なのではないか、と思うようになった。われわれ動物は、環境に対して、ある種の期待＝目標値を持っている。たとえば体内環境の一つ、体温は36.5℃前後といった風に。そして体温の現在値が目標値からずれると暑いとか寒いという感覚を感じ、フィードバック的対応をとる（ホメオスタシスの制御系）。同様に、心理的な欲求に対して現状をくらべ、快適だとか不快だとか（つまりポジティブとかネガティブの）感情を抱くのではないか。<br />
<br />
<br />
たとえば承認欲求が満たされれば、自尊感情を感じる。安全欲求が脅かされれば、不安や恐怖を感じる。帰属欲求や所有欲求の対象が失われれば、悲しみを感じるといった風に、である。そして制御システムのように、SVとPVの差異は、それを修正しようとするMVを導き出す。つまり人の行動を促す。そう考えると、人間の多くの行動の下には感情があり、さらにその底には、さまざまな欲求が隠されている。<br />
<br />
<br />
<br />
<br />
怒りに希望はない<br />
<br />
<br />
<br />
この事実に気がつくと、自分や他者の思考・行動が、いかに欲求と感情にドライブされているかが次第に見えてきた。見かけ上は、知性や経済合理性に基づいて考えたり発言しているようだが、実はその下に、自分をこう位置づけたい、他者をこうしたい、といった欲求がひそんでいる。わたしの敬愛する英語教育家・中津燎子氏は著書『なんで英語やるの？』の中で、人間の行動の8割以上は感情的な動因にうごかされている、という意味のことを書いていたと記憶するが、この方の洞察力にはいつも感心する。<br />
<br />
<br />
感情の中でも一番大切なのは、『希望』かもしれない。わたし達は希望に導かれ、つまづきがちな自分の人生を何とか歩んでいく。しかし昨今の社会を見ると、合理性や正義・公正にもとづいて将来像を語る言説の裏に、じつはしばしば、怒りの感情が貼り付いた言い方が、リアルでもネットでもあふれている。怒りの底には、さらに他者への支配欲求とか、自己への承認欲求などが渦巻く。そしてネットのアルゴリズムが、人びとの同調性をさらに加速する。そんな乱流状態を、わたし達は今、体験しているのではないか。<br />
<br />
<br />
見かけ上どれほど正しい主張でも、怒りの感情に駆られている限り、そこには希望はない。なぜなら、怒りとは、他者を打ち破ろうとする欲求と一体だからだ。支配欲求は、次には負かされた側の攻撃欲求を引き起こす。だから、これは対立を生み続ける心理ゲームである。<br />
<br />
<br />
「剣をおさめよ。剣を取る者は剣で滅びる。」——夜の暗闇で捕縛されようとしたとき、その人は弟子にこう言った。エルサレム郊外でのことだ。今から2千年前、当時の帝国支配下の植民地状態の小国で、宗教改革者として現れた彼は、指導者層の欺瞞を批判し、命を狙われるようになる。追っ手が彼に手をかけたとき、弟子の一人は剣を取って相手に斬りかかるが、彼はそれを制止する。また、こんな風にも言った：「あなた方はまるで強盗に向かうかのように武装して、夜、捕らえに来たのか。毎日わたしは神殿の境内に座って、教えていたのに。」<br />
<br />
<br />
怒りと支配欲求で動く者は、結局、怒りと支配欲求で滅びる。なぜなら、欲求に自分を乗っ取られると、後先を考えられなくなるからだ。強い感情は、「我を忘れる」作用がある。だから滅びたくなければ、「我にかえる」必要がある。我にかえって、少しだけ平静さを取り戻し、自分の有限さを思い出すべきである。<br />
<br />
<br />
当時の夜は、今と違って、空に多くの星が見えただろう。星空を見ると、自分の小ささが分かる。古代人がある種、現代人より謙虚に見えるのは、そのためかもしれない。彼が亡くなって以来、2千年が経ったが、まだ人類は剣に滅びる愚かさを、抜け出ていないようにも感じる。だがこの人の活動は、意味がなかった訳ではない。<br />
<br />
<br />
宇宙150億年の歴史に比べれば、わたし達は塵のような存在だ。だが、ゼロではない。この世を少しでも良くするために、せめて少しでも平和にするために、この冬至の短い季節に、何を語り何を祈るべきか、心静かに考えよう。<br />
<br />
<br />
<br />
<br />
＜関連エントリ＞<br />
「怒りやすい人びと・怒っていると気づかない人びと」  (2017-06-17)<br />
「わたし達の社会には、感情的価値が足りない」  (2025-09-23)<br />
]]></description>
      <dc:subject>E6 メンタルと働き方のマネジメント</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Sat, 20 Dec 2025 23:48:13 +0900</pubDate>
      <dc:date>2025-12-20T23:48:13+09:00</dc:date>
    </item>
    <item>
      <title>スマート製造のボトルネックはどこにあるのか？</title>
      <link>http://brevis.exblog.jp/33845829/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33845829/</guid>
      <description><![CDATA[「生産システム」のIPOモデルとは<br />
<br />
<br />
時折頼まれて生産マネジメントの研修セミナーの講師を引き受けることがある。その時大体いつも最初に話すのが、「工場を生産のためのシステムとして捉える」と言うトピックだ。<br />
<br />
<br />
システムと言うと、すぐコンピューターと情報システムを連想する人がほとんどだろう。だが、ここで言うのは「仕組み」の意味で、人間を含むいろいろな要素が、互いに機能し合い、助け合って目的を達するメカニズムのことだ。現代のシステムズ・エンジニアリングでは、仕組みを理解するために、「IPOモデル」を用いる。インプット・プロセス・アウトプットの略である。<br />
<br />
<br />
工場という仕組みの主要なアウトプットは、当然ながら製品＝プロダクトである。プロセスは文字通り、製造工程である。では、主要なインプットは何だろうか。<br />
<br />
<br />
それは部品材料だ、と言うのが昭和時代の答えだった。部品材料をインプットして、製品というアウトプットを生み出す。これが工場だ、と。まあ部品材料以外に、副資材や用役などもサブのインプットとして必要だろうが。<br />
<br />
<br />
<br />
<br />
需要情報と、製造業の変化<br />
<br />
<br />
ところが現代では、この答えはもはや、間違いなのだ。現代の工場の主要なインプットは何か。それは、「需要情報」である。需要情報をインプットして、製品（の形に込められた付加価値）をアウトプットする。サブのインプットとして、部品材料や副資材・用役を用いる。これが現代の生産システムの姿なのだ。<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/201804/28/47/e0058447_14470245.jpg" alt="_e0058447_14470245.jpg" class="IMAGE_MID" height="264" width="500" /></center><br />
<br />
なぜ、そう言えるのか？　考えてみてほしい。あなたがどこかの工場の、工場長さんだったとする。あなたは、「部品材料があるなら、その分だけ製品を作れ」と指示するだろうか？　需要を無視して勝手に製品を作っても、ムダな製品在庫が積み上がるだけかもしれない。だから需要の明確な製品を優先して、作ろうとするだろう。すなわち、需要情報がメインのインプットに変わったのだ。<br />
<br />
<br />
このような変化の起きた理由は、単純である。物不足時代は昭和で終わり、市場が成熟した。もはや「作れば売れる」時代ではない。だから企業は差別化を求めて、製品種類を増やしてきた。種類が増えれば、単純な外挿による昨年度並みの計画では当たらなくなる。かくして需要情報が、いちばん大事な、メインのインプットの座につくことになった。製造業とは、需要情報を得て、それを製品に変換する仕事になった。<br />
<br />
<br />
すなわち製造業の中核部分は、じつは情報処理産業に変わったのだ。この変化にいち早く気づいた欧米人たちは、「スマート製造」とか「インダストリー4.0」といったスローガンによって、この変化を先取りしようとしている。<br />
<br />
<br />
<br />
<br />
設計機能の問題<br />
<br />
<br />
ところが、ひるがえってわが国では、このような意識変化についていけてない企業や、経営者・メディア・学者たちがまだまだ多いように思われる。<br />
<br />
<br />
情報処理産業である以上、組織の外部からの情報を収集し取り込む「感覚器官」が必要だ。もちろん組織内部の状態をセンシングする内的感覚器官もなくてはならない。そして何よりも、外と内、中枢と末端をつなぐ情報のチャネル＝中枢神経系が必要である。神経系である以上、バケツリレーではなくリアルタイム伝達が必須だし、一方通行ではなく双方向でないとこまる。<br />
<br />
<br />
そして当然ながら、情報変換機能も必要だ。形のない需要情報、顧客の「ニーズ」を、具体的な製品の形に変換するのは、誰か。むろん、設計部門だろう。では、あえて質問するが、あなたの会社の設計能力は、どれほどの水準だろうか？<br />
<br />
<br />
わたしが見聞きしてきた限り、日本企業では、詳細設計は今でも一流だ。世界的に遜色ないレベルだと言える。<br />
<br />
<br />
しかし、はっきり言って、基本設計は二流だ。なぜか。顧客の要求事項に個別に対応し続けることが、設計だと思い込んでいるからだ。一流の設計には、設計思想がいる。そして標準化への強い意思がなければならない。まして超一流の設計とは、新しい製品カテゴリーを創造する能力である。<br />
<br />
<br />
技術カンファレンスなどを見ても、設計のツール論はたくさんあるが、設計論自体は内容が乏しい。設計を導くガイディング・プリンシプルが足りない。<br />
<br />
<br />
<br />
<br />
製造業の本当の問題は、工場の外にある<br />
<br />
<br />
しかし設計機能よりも、もっと問題な部分がある。それはマーケティング・営業である。これは需要情報をインプットし集約するとともに、需要喚起のための製品情報をアウトプットし、顧客を誘引する機能だ。生産システムのメインのアウトプットは製品それ自体だが、同時に製品に伴う情報も、アウトプットし続ける。この情報アウトプットを上手に制御しつつ、インプットの需要情報にうまくフィードバックする仕事こそ、営業に他ならない。<br />
<br />
<br />
マーケティングとはどちらかというと中枢系の機能で、営業セールスは末端組織の力仕事という区分が、西洋社会にはある。しかし、日本企業ではこの区分が明確でない。マーケティング機能自体が、一部のB2C大企業以外では、とても乏しい。<br />
<br />
<br />
マーケティング・営業の仕事とは、煎じ詰めれば「いかに高く売るか」を考える仕事だ。しかし、日本企業の多くは奇妙なプル型（下請型？）体質がしみこんでいて、「いかに安く売るか」「顧客にどれだけ従うか」が、思考のモノサシになっている。これでは情報の一方通行である。よい基本設計は、すぐれたマーケティングとワンセットでなければならない。末端組織の一人ひとりの営業マンは足で稼ぎ、エンジニアは詳細設計で汗をかいて努力している。だが肝心の、中枢機能がつながっていないのだ。<br />
<br />
<br />
こうした状況は、全体システムを統合する経営レベルの問題である。組織図をつくり、KPI・KGIを与えて目標管理で皆をドライブするが、サイロ化した部署の間で、情報の流れがどうなっているのか無頓着でいる。<br />
<br />
<br />
これらの問題は、すべて工場の外で起きている。日本の製造業を再生したかったら、設計、マーケティング、そして経営者の思考習慣を、何とかしなければならない。<br />
<br />
<br />
もちろん工場の刷新は、必要だ。デジタル化だって、省人化だって、待ったなしだろう。でも工場のスマート化は、製造業の活性化にとって必要条件だが、十分条件ではない。製造現場にどれだけIoTセンサーを詰め込んだって、スマート製造は実現しないのである。<br />
<br />
<br />
<br />
<br />
＜関連エントリ＞<br />
「生産システム、そのパラダイム・シフト」  (2018-04-28)<br />
「設計という仕事が、本当に目指すべき役割は何か」(2025-09-15)<br />
<br />
<br />
<br />
]]></description>
      <dc:subject>E3 組織・経営・戦略論</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Wed, 10 Dec 2025 17:36:55 +0900</pubDate>
      <dc:date>2025-12-10T17:36:55+09:00</dc:date>
    </item>
    <item>
      <title>良い設計者はなぜ、他部門の知識を広く求めるのか</title>
      <link>http://brevis.exblog.jp/33841279/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33841279/</guid>
      <description><![CDATA[他部門の知識は必要か<br />
<br />
<br />
エレベーターに乗っていたら、急に声をかけられた。「今、あの本を読んでます。とっても面白いです。本にしていただいて、ありがたいですよ」。勤務先でのことで、他部署の人だった。あの本、とはもちろん、新著「攻めの工場づくり」のことに違いない。本の中身は100%わたしのオリジナルではなく、会社の多くの同僚との共著だ。それでもまとめた人間としては、単純にうれしい。たとえ職場で、先輩格のわたしへのご挨拶半分だとしても、だ。<br />
<br />
<br />
でも、なぜ彼は「まとめてくれて、ありがたい」とまで言ったのか？　それは、この本に書いた工場エンジニアリングに関するほとんどの事柄が、社内の暗黙知か、さもなければ部内知識だったからだろう。部内知識とは、その部の書庫かデータベースのどこかには書かれているが、他の部門の人間には検索もできないし、アクセスもしにくいという意味である。<br />
<br />
<br />
エンジニアリング会社というのは、技術の総合デパートみたいな存在だ。今どきのデパートなら、在庫マスタはどの売り場からでも参照できるだろう。だが社内の知識在庫を参照できる知識在庫マスタは、今のところない（知識在庫の半分以上は、たぶん個人の脳の中にあるし）。そもそも知識って、SQLで値を参照するようには取り出せない。RAGはどうかって？　設計技術は正確性が大事なので、生成AIの中途半端なハルシネーション回答では迷惑だ（そのうち推測確度74%とか、表示されるようになるのだろうか?）。<br />
<br />
<br />
ともあれ職場では、部門間のインタフェースが一応、Functional WBSを基準にして、業務標準で決まっている。インプットとアウトプットは明確だ。だから他部門の知識の中身まで知らなくても、普通の仕事は回る。それでも部門横断的な知識を総合化した本がありがたいのは、なぜだろうか。単純な知識欲？　それも少しはあるかもしれないが、もう少し別の理由があろう。一般に、三つくらいの動機が、考えられる。<br />
<br />
<br />
<br />
<br />
プロジェクト・マネジメントは、広く薄い知識の上に成り立つ<br />
<br />
<br />
第一の動機は、プロジェクト・マネジメントのためだろう。エンジ会社のプロマネ職は、設計部門のシニアや、販売部門のやり手営業マンの仕事ではなく、独立した専門的職種である。そして独立したキャリアパスがある。とはいえ工場づくりやプラントづくりは、設計→資機材の調達→建設管理、という順番がある。とくに設計には時間と工数がかかり、その品質と出来映えが資機材や工事に直結する。<br />
<br />
<br />
だから良いプロマネを目指したければ、設計を理解し、その計画立案と予算化ができるようになる必要がある。とくにプロジェクトを構成する様々なアクティビティについて、その時間軸上の前後関係や矛盾を理解し、ボトルネック工程を見極められるかどうかが、大事だ。<br />
<br />
<br />
たとえば建屋や屋外プラントなどの構築物は、ふつう上物から設計して、それから土台・基礎の設計へと進む。ところが工事は基礎から始めて下から上にしか、進めない。だから、基礎コンクリートの設計・施工がボトルネック工程になりやすい。こうした事を理解するためには、機械・配管・建築・土木など様々な設計について、広く薄く知っておく必要がある。<br />
<br />
<br />
そして、プロジェクト途上の問題解決をファシリテーションするのも、プロマネの大事な仕事だ。プロマネは全分野の専門家ではないから、すべて自分で問題解決はできない。各専門担当者をつなげて、問題解決をファシリテーションしなければならない。それには、問題事象とその文脈や影響範囲について、広い知識と見通しがいる。<br />
<br />
<br />
<br />
<br />
経営企画と投資判断も、広く薄い知識を必要とする<br />
<br />
<br />
もう一つの動機は、経営企画の仕事のためだ。わたし自身、もう10年以上も経営企画畑で働いてきたので知っているが、この種の仕事は（会社によってバラエティはあれども）自社内の仕事について、広く薄い知識を必要とする。<br />
<br />
<br />
日本企業の経営企画部門の大きな仕事は、中期経営計画の策定とモニタリングである。すなわち企業経営視点から見た、大きな課題・ニーズの把握と、リソース体制を見通す事、そしてそれを数字に落とし込むのが仕事である。だからどの部署でどんな仕事を何人がかりでやっているのか、理解しなければならない。<br />
<br />
<br />
もう一つ重要な仕事が、投資判断のサポートである（判断自体は経営層の仕事だが、経営企画部門は事務局的な準備と調整作業を担う）。投資にはいろいろな種類がある。産拠点や営業拠点の新設、設備投資、IT投資、研究開発投資、技術提携からM&amp;Aまで。それら各種案件が生み出すビジネス価値と、必要なコスト・時間が評価できることが大切だ。<br />
<br />
<br />
企業内のには常に複数の投資案件の候補が動いているから、優先順位を決める必要がある。また進行中の案件リスクを見極め、必要なら中止させることもある。こうした仕事を進めるには、ファイナンスの尺度さえ知っていれば良い訳ではない。社内業務について、広く浅い、しかし構造化された知識が必要なのだ。<br />
<br />
<br />
<br />
<br />
設計者が、より良い作り方を知っているとは限らない<br />
<br />
<br />
だがPMも経営企画も、エレベーターで声を掛けてくれた人のケースには当てはまらないかもしれない。むしろ単純に、良い設計を実現するために、他の部門の知識を知りたいという事だった可能性が高い。だが、なぜ設計に、他の部門の知識が有用なのか。オーケストラでヴァイオリン奏者が、隣のヴィオラ奏者の楽譜をのぞき込むだろうか？　空軍のパイロットが、駆逐艦の操舵を知りたいと思うだろうか？<br />
<br />
<br />
実はそこが、設計と他の仕事との違いなのだ。設計技術者は、器楽奏者というより作曲家の立場だ。作曲家は、すべての楽器は演奏できないだろうが、楽器と奏法の基本的な特性は知らなければ、オーケストラ曲はかけない。作戦の立案者は、輸送機や駆逐艦の能力や限界について、基本を知らなければ仕事ができない。つまり、実装の基本的なやり方を知らずに、良い設計はできないということだ。<br />
<br />
<br />
また逆に、実装しやすい設計を目指すことの意義も大きい。もちろん設計の良さには複数の尺度があり、作りやすさだけで良し悪しが決まる訳ではない。それでも工場で加工しやすく組立てやすい製品を設計すれば、コスト・品質・納期では有利である。普通は、設計→製造という風に情報は流れる。しかし設計←製造というフィードバック情報があり、双方向につながることで、より良いものを作る可能性が高まる。<br />
<br />
<br />
これがアメリカの企業だったら、良い仕事には他分野の知識など邪魔だ、と思われるだろう。専門化と分業化の追求が是とされる文化だからだ。英米企業との仕事の経験からいうと、彼らの情報の流れは完全にウォーターフォール型であり、設計は調達や実装はお構いなし、作りやすいかどうかは関係なく、出図さえすれば問答無用で設計完了となる。日本企業は、程度の差はあれど、もう少し「下流側に優しい」。下流に優しいとは、設計技術者一人ひとりが、実装の苦労を少しは気遣いながら、仕事をするという意味だ。<br />
<br />
<br />
もっとも、英米企業はその代わり、マネジメントの計画力が高い。個人の優しさではなく、トップダウンの仕組みで実装側の効率性を確保していく（たとえば手待ちを減らす、など）。<br />
<br />
<br />
<br />
<br />
双方向の統合のために<br />
<br />
<br />
やや話がそれたので戻すが、設計と実装では分担の区切りが異なる。設計は機械・電気・制御・・みたいに機能別・工学別なのに、製造は加工・組立・検査みたいな作業種・工程別になる。だから実装を知ってちゃんと理解しようとすると、結局、隣接する設計領域のことも、少しは知らなくてはならなくなる。かくして、良き設計者は、広く薄い知識を得たいという気持ちを持つようになるのだ。<br />
<br />
<br />
設計とは、Whatを決める仕事だ。それを実装するのは、Howに関わる仕事である。そして情報の双方向のつながりは、組織の統合（もっと言えば「スマートさ」）の尺度である。わたしが危惧するのは、仕事のサイロ化が進んでいる多くの日本企業で、WhatとHowがバラバラになっていく現象だ。<br />
<br />
<br />
幸いにも拙著「攻めの工場づくり」は、出版直後にAmazonの「コンサルティング」ジャンルでランキング上位にはいった。工場に関する広く薄い知識を提供する本書が、多少なりとも好評を得ている事は、サイロを再統合したいというニーズの表れかもしれない。多少なりとも、この本がお役に立てるなら望外の喜びである。<br />
（なお、紙のペーパーバック版は、順調にいけば12月10日頃から販売開始できる予定です）<br />
<br />
<br />
＜関連エントリ＞<br />
「新著『攻めの工場づくり』出版のお知らせ」  (2025/11/17)<br />
<center><img src="https://pds.exblog.jp/pds/1/202511/16/47/e0058447_21383373.png" alt="_e0058447_21383373.png" class="IMAGE_MID" height="480" width="299" /></center><br />
]]></description>
      <dc:subject>E2 設計のマネジメント</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Thu, 04 Dec 2025 17:54:23 +0900</pubDate>
      <dc:date>2025-12-04T17:54:23+09:00</dc:date>
    </item>
    <item>
      <title>工場ハードウェアの構造と、その現代的な『設計思想』を考える</title>
      <link>http://brevis.exblog.jp/33835150/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33835150/</guid>
      <description><![CDATA[建築とレイアウトと動線と<br />
<br />
<br />
「ちょっと想像してみてください。もしも家の台所が1階と2階に分かれていたら、どうなると思いますか。冷蔵庫と流し台は1階にあり、ガスレンジは2階にある、と。それはどんなに不便か、お分りでしょう？」――これは、わたしが工場の建築レイアウトについて、よく使うたとえだ。「ところが、製造業のお客様の工場を訪問すると、こんなレイアウトをよく見かけるんです。モノづくりの工程が、上下階に分かれていて、途中に上下の移動が必要になっています。どんな結果が生まれるか、分りますか？」<br />
<br />
<br />
「工程間で互いに相手の状況が見えないから、作業の同期がとりづらくなりますし、そもそも垂直搬送自体が、時間とエネルギーのムダです。ところが、働いている人は、誰もそれを不思議と思っていません。なぜなら、工場ができた時から、そうなっていたからです。」<br />
<br />
<br />
日本は敷地が狭い。だからどうしても、工場は平屋ではなく多層階になる。それ自体は仕方があるまい。だがフロアが分かれると、いくつか弊害が出る。一つは視認性がなくなること、もう一つは垂直搬送が増えること。それは直接、生産性を阻害する。<br />
<br />
<br />
いや、生産性という言葉は誤解を招くかもしれない。機械1台あたり・作業者1人で加工組立できる数量は、平屋でも多層階でも変わらないからだ。だが同期がとれないと、「整然とした動き」ができなくなる。組織としての俊敏性が下がるのだ。もっと分かりやすく言うと、渋滞が起きる。結果としてリードタイムが長くなる。仕掛在庫量も増える。すると、スペースも圧迫する。<br />
<br />
<br />
<br />
<br />
レイアウトが不便な建物とは<br />
<br />
<br />
わたしは東急東横線・みなとみらい線を毎日通勤に使っている。でも（個人の感想だが）東横線の横浜駅のつくりは感心しない。人の流れを導く動線が、無理に遠回りするような感じを与えるからだ。昔は地上2階にあり、ホームも狭く混雑したが、動線に迷うことはなかった。2004年にみなとみらい線とつながり、地下化してできた現在の駅は、動線の方向が直感に反している。南北両側に連絡通路があるのだから、エスカレーターや階段は両側に別れて向かうべきなのに、中央に誘導するようになっている。<br />
<br />
<br />
混雑時のバッファリングなど、何らかの理由があってこうしたのだろうが、利用者にとって不自然である。東横線渋谷駅も、ある種似たような不便さを感じるので、これは東急電鉄の「設計思想」の結果ではないかと想像している。建築レイアウトの設計では、利便性とか安全性とかコストとか、いろいろな評価尺度がある。そして、すべてを満足させる解を作るのは難しい。その際に、どれを優先するかを決めるのが、設計思想だ。この駅の設計では、何か別の要素が優先され、結果として動線の視認性と利便性が犠牲となったのではないか。<br />
<br />
<br />
もう一つ例を挙げる。横浜みなとみらい地区にある、ランドマークプラザとクイーンズスクエアという二つの建物だ（神奈川以外の読者の方すみません）。超高層のランドマークの隣に、ひな壇のように三つクイーンズの建物がならぶ絵姿は、横浜の代表的光景になっている。前者は三菱地所が設計し、後者は日建設計が手がけた。<br />
<br />
<br />
だがこの二つ、動線の分かりやすさが天と地ほど違う。ランドマークプラザは自分がどこにいて、どの階のどの店にどう行けば良いか、きわめて明快だ。ところがクイーンズの方は、どこがどうつながっているのか、実に分かりにくい。クイーンズタワーA棟が勤務先なので、もうかれこれ25年以上使っているのだが、つい先日も「え、こんなところに誰も使わなそうなエレベーターが」と、新鮮な発見（笑）をしたくらいだ。<br />
<br />
<br />
建物というハードウェアは、外観の美しさも大事だが、それと並んで動線が大切だ。クイーンズは日本建築学会賞を受賞したが、審査委員の先生方は、本当に何日間も自分の足で歩いて使ってみて、審査されたのだろうか。建物は箱ではない。大勢の人が動く場だ。その動きが、きれいな層流なのか乱流なのか、考えるべきだろう。<br />
<br />
<br />
<br />
<br />
工場を「流れの場」として考える<br />
<br />
<br />
もっとも、人の動きを流体力学にたとえるのは、お前さんが建築出身ではなく、プラント屋だからだろ、と言われるかもしれない。別に否定はするまい。いわゆる建築美学とはかけ離れた、プラント・エンジニアリング会社で働いてきて、美術館にも教会建築にも携わったことはない。わたし達が設計するのはそうした「純建築」ではなく、工場とか研究所とか病院などの、機能的に複雑な建築物だ。<br />
<br />
<br />
わたし達プラント・エンジ会社の技術者の目からは、工場とは「人と物が流れる場」に見える。これは、製造業の生産技術や工務部門の人たちとは、相当違う視点だろうと思う。ほとんどの製造業の生産技術者にとって、この部品はどんな機械でどう加工するか、この複雑な製品はどう精度を確保して組立てるか、が命だ。部品をどう供給するか、人はどこで着替えるか、クリーンな空気はどこから供給するか、とかは付随的な問題に過ぎない。<br />
<br />
<br />
そして正直に言うが、エンジ会社は、製造業の顧客の本当に中核的な技術ノウハウには、タッチしない（できない）。それならば、どうやって工場づくりのインテグレーションができるのか？　中核が分からないのに、どうして周辺を決めて組上げられるのか？<br />
<br />
<br />
それは、人々がCPUチップの内部回路を知らなくても、自作PCを組上げられるのと一緒だ。CPUはパソコンの命だが、CPUだけではパソコンは機能しない。メモリや外部記憶や電源や筐体やキーボード・ディスプレイ・周辺機器がそろってはじめて、CPUが威力を発揮できる。PCを設計し組上げるのには、CPUの外部I/F要求を理解すれば十分で、必ずしも内部知識はいらない。ただしCPU以外の様々なデバイスを、性能やサイズやコストを勘案しながら、バランス良く決めなければならない。<br />
<br />
<br />
<br />
<br />
工場を「システム」として設計するために<br />
<br />
<br />
特にCPUにとっては、各種資源にアクセスするためのバスが大切だ。CPUだけが速くても、バスの能力が低ければ、システム全体のパフォーマンスが上がらない。バスは、信号の動線だ。同じように、工場の建物というハードウェアを建てるときだって、モノと人の流量と、動線の設計が大切なのだ。<br />
<br />
<br />
バスの能力問題は、CPUが遅いときはクローズアップされない。CPUを高速化しスケールアップ（多重化）していくと、システム全体のボトルネック工程が、CPUの外部に生じるようになる。工場も同じだ。小さな町工場に動線問題はない。だが工場を大きくし、生産量を拡大し、多品種化しようとすると、この問題がクローズアップされるようになる。だからこそ、工場の動線とレイアウト設計には、設計思想が必要なのだ。<br />
<br />
<br />
電子機器には回路図がある。だが、あなたは工場にも、モノの流れを表す「回路図」が必要だし、存在することをご存じだったろうか？　それが『マテリアルフロー図』であり、『メカニカルフロー・ダイアグラム』である。それがどういうものであるかは、ぜひ新著「攻めの工場づくり」（佐藤知一・丸山幸伸）を見ていただきたい。回路図なしに、工場を作ろうとしていないだろうか？　建築図面と機械図面があれば工場ができると思っている人にこそ、ぜひ本書を読んでほしい。<br />
<br />
<br />
工場は、各工程という機能要素と、その間を結ぶ動線というリンクからなる、一つのシステムである。それは製造設備だけでなく、物流設備や用役設備や空調設備や、建築というハードウェアの組合せで実現される。その上で人々が働き、モノが動き、さらに情報が流れる。それを動かすためのソフト（ITシステムならびに、人を動かす手順・ルール群）がいる。それを作り上げるのが「工場のシステムズ・エンジニアリング」だ。<br />
<br />
<br />
機械を買ってきて、建屋にポンと置けば工場ができた昭和時代から、今はここまで変わったのである。現代流の工場づくりの考え方が、我が国にももっと広まってくれれば良いと、強く願っている。<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/202511/26/47/e0058447_14194270.png" alt="_e0058447_14194270.png" class="IMAGE_MID" height="375" width="500" /></center>「攻めの工場づくり」第9章より引用<br />
<br />
<br />
<br />
＜関連エントリ＞<br />
「工場レイアウト設計の典型的問題と、そのエレガントな解決法」  (2016-07-16)<br />
]]></description>
      <dc:subject>C1 工場計画論</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Wed, 26 Nov 2025 14:36:42 +0900</pubDate>
      <dc:date>2025-11-26T14:36:42+09:00</dc:date>
    </item>
    <item>
      <title>工場エンジニアリングに関する新著：「攻めの工場づくり」を刊行しました</title>
      <link>http://brevis.exblog.jp/33827693/</link>
      <guid isPermaLInk="1">http://brevis.exblog.jp/33827693/</guid>
      <description><![CDATA[新著刊行のお知らせです。<br />
工場とは何か、どんな風に計画し、いかに作っていくかを、誰にも分かりやすく説明した本を、本日（11/17）発刊しました：<br />
<br />
<br />
<br />
「投資価値を最大化する『攻めの工場づくり』　〜　10のスマート化戦略」<br />
　　佐藤知一・丸山幸伸著<br />
<br />
<br />
<center><img src="https://pds.exblog.jp/pds/1/202511/16/47/e0058447_21383373.png" alt="_e0058447_21383373.png" class="IMAGE_MID" height="480" width="299" /></center>（丸山幸伸氏は日揮の同僚で、医薬品工場をはじめとする非プラント系工場づくりのプロジェクトに、長年携わってきたエキスパートです）<br />
<br />
<br />
<br />
<br />
電子書籍Kindle版は、11月17日よりAmazonから以下のurlにてお買い求めいただけます。<br />
　https://amzn.to/49pnLvW<br />
<o:p></o:p>　定価1,200円（ただし今週・来週ははキャンペーン価格で入手可能ですので、ぜひ早めにお申込みください）。そしてKindle読み放題の対象です。<br />
　なお、紙の書籍は2〜3週間後に販売開始となる予定です（予価2,500円）。あわせてご利用ください。<br />
<br />
<br />
<br />
日本にも海外にも工場は無数にあります。それはモノづくりの場所で、産業の基幹である製造業を支える役目を果たしています。しかし、工場とはそもそもどんな仕組みとして成り立っていて、どう作れば良い工場ができるのか、分かりやすく解説した本は、不思議なことにほとんどありません。<br />
<br />
<br />
中で動かす機械を決めて注文して、それを入れる建物を作れば、「工場」ができあがる。そう考える人も多いでしょうが、率直に言って昭和時代の発想です。物不足だが労働力は豊富だった頃の考え方だからです。かつ、その後の長い不況の間、工場新設は（一部産業を除いて）抑えられ、社内で技術を継承発展する事も難しい状況でした。その結果日本は、現代的なスマート製造の実現で、欧米や中国に後れを取る事態になりつつあります。<br />
<br />
<br />
このような状況を逆転するために、わたし達は筆を執りました。国内外で多数の工場・プラントづくりを手がけてきた日揮のエンジニアリング・ノウハウを、惜しみなく公開し、現代的な『仕組みづくり』としての工場設計・建設手法を詳述しています。現代的な工場設計の考え方が、上に書いた昭和的な発想といかに違うか、驚かれると思います。<br />
<br />
<br />
本書を読んでいただきたいのは、製造業で工場投資の意思決定に携わる方、具体的には以下のような方々です：<br />
経営企画部門で、工場立地計画や投資採算分析に関与する方々<br />
生産技術部門で、工場の増改築・リノベーション、製造ライン増設、そして新設に関わる機械系・電気制御系の技術者<br />
生産技術あるいは施設管理部門で、工場の建築面に関わる方々<br />
工場の製造部門・生産管理部門で、現場の実務に携わるスタッフ、あるいは購買・物流・品証その他工場内の業務に関わる方々<br />
製品開発・設計部門で、自分たちの設計図がどのような形で、製造プロセスに実現されるかに関心のある技術者<br />
製造業の情報システム部門や情報子会社の技術者<br />
<br />
<br />
<br />
また、製造業以外の方にもおすすめしたく思っています：<br />
ITエンジニアで、工場や製造の実務を理解したい方<br />
建築設計事務所、ゼネコンの設計部門の方<br />
工作機械、マテハン機械メーカーの方<br />
経営コンサルタント<br />
<br />
<br />
<br />
内容は実物を見ていただくのが一番ですが、とりあえず目次の一部をご紹介しておきます。<br />
<br />
<br />
序章：あなたの工場は「コストセンター」？<br />
【戦略１】立地選定・敷地計画<br />
<br />
「敷地」で工場の未来は決まる<br />
【戦略その３】生産方式とレイアウト設計<br />
<br />
レイアウトは利益を左右する<br />
【戦略その４】採算分析・投資判断<br />
<br />
巨額投資を成功に導く！「工場マスタープラン」の作り方<br />
【戦略その５】製造工程設計<br />
<br />
工場の設計は「回路図」で考えよ<br />
「製造工程の見える化」がライン設計の出発点<br />
<br />
【戦略その７】建築・空調設計<br />
<br />
「レイアウト」と「空間構成」で進化する工場へ製品品質と歩留まりを決める「空調設備設計」【戦略その９】ITシステム導入<br />
<br />
ITなんて怖くない！ スマートな工場の制御・ITシステム<br />
【戦略その１０】PMと立上げ組織<br />
<br />
工場づくり、誰に任せる？ 失敗しないアウトソーシングと契約の鉄則<br />
<br />
<br />
これから工場づくりに関わる方にも、今まさに工場を作りつつある方にも、そして、まだ予定はないけれど「現在の工場は、本当はどうあるべきなのか」を考えたい方にも、きっとヒントになると信じています。<br />
<br />
<br />
なお本書は2022年から1年半の間、日刊工業新聞社の月刊誌「工場管理」に連載した記事がベースになっていますが、全体構成の部分からかなり見直し、図表等もかなり描き直しました。より分かりやすく、実戦的な内容になっていると思っています。<br />
<br />
<br />
大勢の方に手に取っていただければ幸いです。<br />
<br />
<br />
<br />
<br />
佐藤知一＠日揮ホールディングス（株）<br />
]]></description>
      <dc:subject>C1 工場計画論</dc:subject>
      <dc:creator>Tomoichi_Sato</dc:creator>
      <pubDate>Mon, 17 Nov 2025 10:31:38 +0900</pubDate>
      <dc:date>2025-11-17T10:31:38+09:00</dc:date>
    </item>
    <supplier>
      <url>
        <excite>https://www.excite.co.jp/</excite>
        <exblog>https://www.exblog.jp/</exblog>
        <idcenter>https://ssl2.excite.co.jp/</idcenter>
      </url>
    </supplier>
  </channel>
</rss>
