すり合わせの優位性は健在か？日本の製造業が直面するPLM活用とMBSEソフトウェア運用の理想と現実

石油危機は再び日本の自動車産業を塗り替えるのか。
現場で感じた「すり合わせ」の限界、PLMによる設計資産のデジタル化、そしてMBSE導入に立ちはだかる高価な壁。製造業DXの理想と過酷な現実を深く考察してみる。

【参考】
Xユーザーのブルームバーグニュースさん: 「石油危機が自動車市場を変える、かつての勝ち組日本車劣勢 https://t.co/NoIbkcR5k0」 / X

PLMツールとは部品表の構成管理ツールでありGitHubである: プログラマの思索

いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化する

図解 DX時代のPLM/BOMプロセス改善入門 デジタル化 段階別課題解決のアイデア100 | 三河 進 |本 | 通販 | Amazon

システムズエンジニアリングに基づく製品開発の実践的アプローチ

システムズエンジニアリングの探求 | ジョン・ホルト, Jon Holt, 伊藤 侑太郎, 河野 文昭 |本 | 通販 | Amazon

システムズエンジニアリングハンドブック 第５版 | デイビッド・D・ウォルデン, 西村秀和 |本 | 通販 | Amazon

実践に活かす モデルベースシステムズエンジニアリングの基礎 | 西村 秀和, 西村 秀和, 河野 文昭 |本 | 通販 | Amazon

5つの問題解決パターンから学ぶ実践メソッド BOM(部品表)再構築の技術 | 三河 進 |本 | 通販 | Amazon

BOM/部品表入門: マテリアル・マネジメント改革の基本技術 (図解でわかる生産の実務) | 佐藤 知一, 山崎 誠 |本 | 通販 | Amazon

【1】５０年前の石油危機が日本の低燃費自動車普及のきっかけと同様に、今回の石油危機がEV化、SDVを加速させるだろう。
日本メーカーはITに弱いのでこの波に乗れないように見えるのが辛い。

Xユーザーのブルームバーグニュースさん: 「石油危機が自動車市場を変える、かつての勝ち組日本車劣勢 https://t.co/NoIbkcR5k0」 / X

【2】日本の製造業の現場を1年ほど見てきて、疑問に思う点は2つある。

【3】1つ目は、日本の製造業が得意とする「すり合わせ」とは一体何だろうか？
現代では「すり合わせ」の技術に優位性はあるのか？

50年前なら、ソフトウェアはハードのおまけであり、ハードウェアのすり合わせ技術が品質保証に繋がっていたのだろう。
しかし、現代では、自動車であれ、機械製品であれ、部品点数は数万点、10万点以上に及ぶ。
そんな大量の部品を組み合わせて量産するのは、人間の脳みそによる管理限界を超えている。

また、市場環境の変化、国際政治の変化によるサプライチェーンへの影響により、次から次へと多品種少量生産を強いられる。
そんな状況で、すり合わせをいちいち実施していて、環境変化の速度についていけるのだろうか？

「すり合わせ」の優位性は今でもあるのか、正直疑問に思う。

【4】もう一つは、日本の製造業のDX戦略のあるべき姿はどこにあるのか？

いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化するでは、DX成熟度というべき段階レベルがある。
具体的には、DX成熟度には、デジタル化→デジタル改革→デジタル変革　の3つがある。

現在、日本の製造業のDX成熟度は、まだデジタル化の段階にある。
彼らの現場では、職人技術者の頭にノウハウが染み付いていて、OJTという名で技能継承してきた。
いまだに2D-CADが主流であり、つい最近まで紙ベースの製図が割とあった。
製品設計図がデジタル化されていると言っても、Excelやパワポで散在していて、一元管理もできていない。

だからこそ、PLMツールを使って、製品設計図をデジタル化して一元管理しようと試みている企業が多い。
この流れは正しい道筋と思う。

しかし、彼ら日本の製造業は、今後、デジタル化された資産をどのように戦略策定に使おうとしているのか？

本来は、PLMツールに格納された設計資産を、FMEAのような品質保証と結びつけたり、見積もりや原価計算などのコスト管理に結びつけたり、MESやERPを連携させて工程管理で使うことで、設計工程や製造工程の業務プロセスを改善したい。
だが、日本の製造業の設計・製造プロセスは過去の長い歴史の経緯もあって、非常に複雑で例外フローが多く、属人的なフローが多すぎる。
まずは整理整頓する段階で留まっている。

PLMツールとは部品表の構成管理ツールでありGitHubであるならば、設計資産を有効活用して、QCD向上につながる業務プロセス改革に使いたい。
そういう戦略策定が必要になるだろう。
今は試行錯誤しているように見える。

【5】PLMツールで設計資産を一元管理できたとして、MBSEとどのように関係づけて、より高度な製品開発にもっていくか、という課題もある。

実際の物理構造である設計図面ではなく、論理的なあるべき機能からモデルを構成して、モデルベースで製品開発していくべき。
それがMBSEになろうだろう。

【6】しかし、僕は、MBSEは巷で言われているように本当に有効なのか、疑問に思っている。
理由はいくつかある。

1つ目は、新製品開発の期間が短く、多品種少量生産を強いられる環境の中で、いちいちモデルを新規作成するのは、時間もコストも掛かりすぎる。
せっかく作ったモデルもすぐに陳腐化しやすい。

また、一度作成したモデルも、設計後に量産化する前の検証段階で、何度も手が加えられて変更される。
つまり、モデルの構成管理が必要になる。
しかし、モデル作成専用のソフトウェアがなければ、構成管理は難しいだろう。
たいてい、MBSE専用のソフトウェアは非常に高価であり、大量の設計者が同時使用できる代物ではない。
モデル作成のコスト、モデルの構成管理のコストは、想像以上に高く、ハードルが高い。

MBSEソフトウェアとして、カメオシリーズが有名。
Cameo Systems Modeler | カメオ システムズ モデラー | SysMLモデリングツール | アイコクアルファ株式会社

【7】2つ目は、モデルを作成できたとして、何が嬉しいのか、効果が見えづらいことだ。

確かに、論理的なモデルにより、ハードウェアの制約や過去開発の思い込みをゼロベースから検討できるのはメリットの一つだが、それだけでは弱すぎる。

僕の直感では、ハードで実現した試作品を作る前に、MBSEで作成したモデルをソフトウェア上で何度もシミュレーションで何度でも検証できることが最大のメリットではないか、と考える。
なぜならば、ハードの試作品を作っては検証して、何度も作り直すのは、仕損費が膨れ上がり、設計コストが耐えられないからだ。

むしろ、ソフトウェア上で何度も作っては検証して、機能だけでなく性能や非機能要件まで細部の仕様を詰められれば、試作品の仕損費を劇的に減らせる。
量産に持ってくまでの試作期間を短縮することも可能だ。

つまり、Simulinkでシミュレーション検証する、CAEで検証する、と言った検証作業をソフトウェア上で何度も試せる点が重要だろうと考える。

そして、ここでも、MBSEベースのモデル検証にはMBSE専用ソフトウェアが必要であり、MBSE専用ソフトウェアが非常に高価である点がボトルネックになってくる。

すなわち、MBSEベースのモデル駆動開発とは、MBSE専用ソフトウェアによるモデル開発とモデル検証であって、我々IT技術者が思い描くGitHubベースのソフトウェア開発ではない。
よって、MBSEベースのモデル開発は非常にハードルが高いと言えるだろう。

この考え方が正しいのかどうか、今後も思索していく。

【読書メモ】ミアシャイマーに学ぶイラン情勢と、社会科学における仮説検証の醍醐味

イラン戦争の解説記事で的確だなと思った記事をメモ。

【参考】
『ジョン・ミアシャイマーが語る：トランプ政権、イラン戦争という破滅への道』

新装完全版 大国政治の悲劇 | ジョン・J・ミアシャイマー, 奥山 真司, 杉原 修 |本 | 通販 | Amazon

大国政治の悲劇 改訂版

大国政治の悲劇: 米中は必ず衝突する! | ジョン・J. ミアシャイマー, Mearsheimer,John J., 真司, 奥山 |本 | 通販 | Amazon

地政学 新版: アメリカの世界戦略地図 | 奥山 真司 |本 | 通販 | Amazon

世界最強の地政学 (文春新書 1427) | 奥山 真司 |本 | 通販 | Amazon

「大国政治の悲劇」の感想～現代はパワーポリティクスの歴史に戻ったみたいだ: プログラマの思索

【1】ミアシャイマーと言えば、Offensive realism（攻撃的現実主義）の専門家で有名。
彼がイラン戦争に関するとても現実的な解説をしている。
結論は、専門家集団を無視して、破滅的な軍事戦略を採用している。
戦略的敗北が決定的。

【2】ミアシャイマーの新装完全版 大国政治の悲劇は、地政学と軍事・政治の歴史を俯瞰し、未来を描いている。
結論は、米中衝突は避けられない、と。

彼の本みたいに、論文みたいで、壮大なスケールの本が好きだ。
あとがきにはたくさんの脚注や引用文献があるので論文みたいだ。

過去200年の歴史を元に、彼が主張するOffensive realism（攻撃的現実主義）を検証して正統性を主張している様は、まるで数学や物理の論文を読んでいる感じだ。
それを踏まえて、将来は、米中衝突が起きるだろうと予言している。

政治学や地政学のような社会科学であっても、仮説を立てて検証し、自身の理論の正当性を主張する本は僕は好きだ。
僕が高校生や大学生の頃に読んだ、ポール・ケネディやウォルフレンの著作の本も似たような構造を持っていた。
彼らも、歴史から大量の事実をベースに、自身の理論へ一つずつ割り当てて、その正統性を検証していた。

大国の興亡 上巻: 1500年から2000年までの経済の変遷と軍事闘争 | ポール ケネディ, 主税, 鈴木 |本 | 通販 | Amazon

大国の興亡 下巻: 1500年から2000年までの経済の変遷と軍事闘争 | ポール ケネディ, 主税, 鈴木 |本 | 通販 | Amazon

Amazon.co.jp: 日本/権力構造の謎 上 : カレル・ヴァン ウォルフレン, 勝, 篠原: 本

Amazon.co.jp: 日本/権力構造の謎 下 : カレル・ヴァン ウォルフレン, 勝, 篠原: 本

社会科学の研究スタイルは、本来はこんなものなんだろうね。

アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めた。
アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か？
考えたことをメモ。

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | Nick Tune, Jean-Georges Perrin, 元内 柊也, 岩﨑 勇生, 角谷 太雅 |本 | 通販 | Amazon

チームトポロジー 適応型組織設計

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地 |本 | 通販 | Amazon

アーキテクチャモダナイゼーションとはそもそも何なのか？: プログラマの思索

チームトポロジーにおける4チームのインタラクションをUMLで整理してみた: プログラマの思索

チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索

システムのリプレース案件が最も危険な理由: プログラマの思索

【1】アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、アーキテクチャモダナイゼーションイネーブリングチーム（AMET：Architecture Modernization Enabling Team）という特別なチームがある。
このチームの役割と責任範囲は何か・
このチームは、アーキテクチャモダナイゼーションにおいてどんな役割を果たすのか？

【2】Geminiに聞いてみた。

アーキテクチャモダナイゼーションイネーブリングチーム（AMET：Architecture Modernization Enabling Team）は、全ての決定を下す中央集権的なチームになることなく、取り組み全体を通じて推進力を維持しながらモダナイゼーションを導き、サポートする専門チームです。チームトポロジーにおける「イネーブリングチーム」の一種であり、組織の能力向上に伴い段階的に縮小・解散する「一時的な足場」としての性質を持ちます。
AMETの主な役割と責任範囲は、以下の6つの目的と具体的な活動に集約されます。

1. 6つの主な目的（役割）
モダナイゼーションの始動: 説得力のあるビジネスケースを構築し、ヒアリングツアーやキックスターターワークショップを通じて、取り組みを停滞させる「分析麻痺」を打破して軌道に乗せます。

勢いの維持: 定常業務（BAU）やバグ修正などの優先順位に押されることなく、取り組み全体を通じて高いエネルギーを維持し、進捗を阻害する障害を取り除きます。

よりよい設計の促進: ドメイン駆動設計（DDD）などのモダンなアーキテクチャ設計スキルが不足しているチームに対し、コーチングやワークショップを通じて設計スキルの向上を支援します。

長期的で持続可能な変化の促進: 一時的な活動に終わらせず、新しい働き方や技術的実践が組織のDNAとして定着し、AMETがいなくなっても自律的に改善を続けられる基盤を築きます。

ビジョンと進捗の伝達: 取り組みの外部にいる関係者が不安を感じたり価値を疑ったりしないよう、ビジョンと具体的な進捗状況を組織全体へ周知し続けます。

成功事例と学びの共有・展開: 特定の分野での成功や教訓を他の分野へ広め、組織全体の学習を加速させます。

2. 戦略的・組織的な責任範囲
ビジネス戦略への貢献: アーキテクチャの変更をビジネス目標や成長戦略と明確に結びつけ、投資の正当性を説明する責任を負います。
アーキテクチャ運用モデルの確立: AMET解散後も組織が進化し続けられるよう、アーキテクチャギルドの設立やアーキテクチャアドバイスプロセス（分散型の意思決定手法）の導入を支援します。
依存関係の管理とボトルネックの解消: 複数のチームにまたがる複雑な依存関係や、レガシーシステムに関連するボトルネックを特定し、その解決に向けてリーダーシップ層と連携します。
スキルアップと人員配置の助言: 必要な技術的実践（テスト駆動開発や継続的デリバリーなど）を導入し、人材育成や外部パートナーの活用について助言します。

3. 求められる姿勢とスキル
AMETは「指示を出す側」ではなく「支援する側」であるため、メンバーには高度な技術力に加えて、**忍耐強い対人スキル（NVC：非暴力コミュニケーションなど）**やコーチング力が極めて重要視されます。自ら作業の一部をこなしつつも、適切なタイミングで一歩引き、現場のチームに主導権を委ねる柔軟性が求められます

【3】ここから分かることは、AMETはチームトポロジーにおけるイネーブリングチームであることだ。
AMETは、イネーブリングチームなので、アーキテクトの専門家、ソフトウェア品質保証や開発プロセス改善の専門家から成る専門家集団であって、ストリームアラインドチームから独立している。
ストリームアラインドチームを支援したり指導する役割と捉えた。

つまり、AMETはモダナイゼーションを推進するアーキテクト専門家集団だ。

よって、AMETは経営層と開発チームの間で、お互いの情報を吸い上げたり落とし込んだり、調停する立場にある。
すなわち、AMETは経営層を支援し、開発チームを指導する権限を持つ強力なチームと言える。
社内では相当な権力を持つチームではないだろうか。

なぜならば、AMETがモダナイゼーションを定義するアーキテクチャを指定し、そのアーキテクチャの基板上でストリームアイランドチームはアプリ開発するだろうからだ。
ストリームアイランドチームを支援するために、プラットフォームチームやコンプリケイテッドチームも存在するのだろう。

【4】そんなことを考えると、モダナイゼーションを実施する案件の規模は相当な大規模PJになるだろう。
100人月はもちろん、もっと大規模な工数がかかるだろう。
単なるアプリ開発チーム以外に、AMETのようなアーキテクト専門家集団もいて、アーキテクチャを支える基盤を構築維持するプラットフォームチームもいるのだから、相当な人数が関わる案件になるからだ。

よって、PJ管理は相当難しくなるだろう。
アーキテクチャそのものも相当複雑になりがちだろうと想像する。
だからこそ、AMETのようなアーキテクト専門家がいなければ、たくさんのストリームアイランドチームという開発チームにガバナンスを効かせて統制を取ることができないだろう。

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するではAMETがかなり重要な役割を果たしているので、じっくり読んでみたいと思う。

アーキテクチャモダナイゼーションとはそもそも何なのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めた。
アーキテクチャモダナイゼーションとはそもそも何なのか？
考えたことをメモ。

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | Nick Tune, Jean-Georges Perrin, 元内 柊也, 岩﨑 勇生, 角谷 太雅 |本 | 通販 | Amazon

More Joel on Software | Joel Spolsky, 青木 靖 |本 | 通販 | Amazon

システムのリプレース案件が最も危険な理由: プログラマの思索

【1】アーキテクチャモダナイゼーションとはそもそも何なのか？
システムのリプレースとは何が違うのか？
システム刷新に出てくるリホスト、リビルド、マイグレーションなどの概念とは何が違うのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するには明確に書かれていないようだが、理解した限り、
「モダナイゼーション＝リプレース＋UX改善＋組織変革」
を意味するらしい。
つまり、単純なリプレースを意味しない。

【2】一般に、リプレース（再構築）とは、既存システムの機能は変えず、システム内部構造を再構築し直すことだ。
リプレース案件は、SIerのビジネスの中でかなりの案件数を占めるのではないか。
ITシステムは一度作ったら10年以上変えずに動くわけではなく、OSやミドルウェアやプログラミング言語のVerUp、CPUやメモリやHDD容量のサーバー性能増強、外部環境の変化によって、必ず定期的に手を加えなければならない。
そのタイミングでシステムの内部構造を入れ替える時が多い。

しかし、リプレース案件は大抵、デスマーチ案件に陥りやすい。
その理由は20年以上前に書いた。

システムのリプレース案件が最も危険な理由: プログラマの思索

リプレース案件は危険だ。
リプレースでなくても、リホスト、リビルド、マイグレーション程度の案件であっても、ソフトウェア開発能力やPJ管理能力が不十分ならば、失敗案件に陥りやすい。
たぶん、IT案件特有の事象だろうと思う。

【3】モダナイゼーションはリプレースだけでなく、UX改善や組織変革を含む意味は何なのか？
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、システムの内部構造を変えるだけでなく、UXも改善することで、利用ユーザの便利さや活用も重視している点だろう。
つまり、業務プロセスの改善、ビジネスモデルの変革も意図しているのだろう。

さらに、モダナイゼーションが単純なリプレースではなく、ドメイン駆動設計やアジャイル開発を志向するのであれば、逆コンウェイ戦略に基づく組織運営になるだろう。
つまり、インフラ層・DB層・アプリ層・フロントUI層のような機能別レイヤーの組織構造ではない。
チームトポロジーのように、複数のストリームアイランドチームが中核の機能を開発し、イネーブリングチームやプラットフォームチーム等が支援する組織構造になるだろう。

すなわち、ソフトウェア開発組織も従来のような機能別組織ではなく、アジャイル開発に適したスクラムチーム主体の開発組織になることを意味しているのだろう。

【4】では、アーキテクチャモダナイゼーションを考える正統性、意義はどこにあるのか？
従来のリプレース案件の延長ではなく、アーキテクチャモダナイゼーションをわざわざ考えるのは、どんな背景・意図のためにあるのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、下記の観点があるらしい。

1. 経営・投資の切り口：ROI（投資対効果）の最大化
背景: モダナイゼーションはシステムと事業運営への相当な投資であり、決して無料ではありません。
意図: 闇雲にすべてを刷新するのではなく、**「ビジネスの戦略的優先事項にどう貢献するか」**を明確にすることで、投資収益率（ROI）を最大化させる判断材料を提供しています。

2. 競争優位性の切り口：競合への対抗と「慣性」の打破
背景: 成功した企業ほど過去のビジネスモデルに固執し、変化を嫌う「慣性」が生じます。一方で新規参入者は最新技術で武装して破壊的変革を仕掛けてきます。
意図: 自社の開発能力が時代遅れになり、**「迅速な競合他社に後れを取るリスク」**を直視させることで、存亡に関わる脅威としてのモダナイゼーションの必要性を説いています。

3. 事業成長の切り口：拡大を阻む「足かせ」の除去
背景: 新規参入者の脅威がない場合でも、既存のアーキテクチャがビジネスの拡大（市場浸透、新プロダクト開発など）を物理的・構造的に妨げることがあります。
意図: 市場開拓や多角化といった**「成長戦略」を支えるために、どの程度の刷新が必要か**を見極める視点を提供しています。

4. 資本戦略・M&Aの切り口：企業価値（資産）の再構築
背景: 買収による成長を目指す場合や、自社の売却（出口戦略）を検討している場合、レガシーなシステムは「負の資産」として評価を下げたり、統合のボトルネックになったりします。
意図: 厳密な資産査定に耐えうる**「投資家にとって魅力的なアーキテクチャ」**を維持することが、出口戦略の成功に直結することを示しています。

5. ユーザー体験・運用の切り口：品質と生産性の向上
背景: 劣悪なUXはブランドへの信頼を失わせ（二重予約などの事故）、非効率な内部ツールは運用コストを増大させ、従業員のストレスを増大させます。

意図: 単なる「見た目の修正」ではなく、「根本的なアーキテクチャの負債」がUXや生産性を毀損している事実をステークホルダーに認識させるためです。

6. 組織能力の切り口：人材の採用と定着
背景: 古い技術スタック（例：COBOLや巨大なC++モノリス）を使い続けることは、優秀なエンジニアにとってキャリアの行き止まりを感じさせ、採用困難や離職を招きます。
意図: 「本気でモダナイゼーションに取り組む姿勢」そのものが、優秀な人材を引きつける強力なインセンティブになるという副次的メリットを提示しています。

つまり、単に技術者がシステムを綺麗にしたいから、という意図だけではなく、「ビジネスの存続と成長のために不可欠な投資である」意図が重要なわけだ。

【5】アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するは内容がとても濃い。
システム設計の話よりも、経営戦略や組織戦略の観点が多い。
だから、正直読みづらい点もある。

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するに出てくる重要なキーワードには、AMET（Architecture Modernization Enabling Team）、アンゾフの成長戦略、BVSSHモデル、プロダクトの分類体系（プロダクトタクソノミー）などが出てくる。
これらについても理解したことを書いていく。

DX戦略はDX成熟度を考慮して戦略策定すべき

DXとはそもそも何なのか？
DX戦略の考え方は何なのか？
いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化するを読んで考えたことをメモ。

【参考】
いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化する | 石角 友愛 |本 | 通販 | Amazon

【1】DX、デジタルフォーメーションという言葉はよく聞くが、その定義を聞くと、人によってバラバラだ。
たとえば、デジタル化の回答もあれば、ITによる業務プロセス改善という意見もあれば、ITを使った新しいビジネスモデル構築という意見もある。
どれが正しいのだろうか？

デジタルフォーメーションという言葉を聞くと、僕は、デジタルに変身！と叫ぶウルトラマンに変身するイメージを思い浮かべてしまう。
実際の日本企業は、そう簡単に変身できないだろうが。

【2】いまこそ知りたいDX戦略 自社のコアを再定義し、デジタル化するでは、DXには3つの段階があると解説している。
DX成熟度というべき段階レベルがある。

【2-1】Digitization

アナログ→デジタルへ移行
例：
ペーパーレス化
図面の電子化
CADによる設計
承認フローの電子化

【2-2】Digitalization

・デジタル化したデータを利用して、
ビジネスプロセスを変革する
・作業の進め方を変えて、
顧客や企業の関与と相互作用の方法を変革し
新しいデジタル収益源を生み出す
例：
ERPによる経営資源共有
見積・設計・製造プロセスの改善
3D設計＋CAEによる設計品質向上
PDMツールによる技術情報の部門内共有

【2-3】Digital Transformation

新しいビジネスモデル、コアビジネスのデジタル変革
人や組織に関する変革
例：
自社以外に、顧客やサプライヤ、ステークホルダーを
巻き込んだ変革
グローバルPLM
ライフサイクルを通じたBOM再構築

dx-maturity-in-digital-transformation-strategiesfrom akipii ogaoga

【3】僕が現場で見る限り、日本の製造業は、Digitizationの段階で留まっているケースが多い。
特に、職人芸の気質が強い中小企業がそうだ。

たとえば、ノウハウは職人、経理や現場担当者にくっついていて、なかなか周囲にナレッジ共有できない。
OJTで学ばせるだけ。
日本人は現場で優秀なので、トラブル対応や火消しをいつも頑張ることで乗り切っている。
よって、組織として習熟しているとは言えないといつも思っている。
なぜならば、業務プロセスを誰も明文化していないし、明文化したとしても例外フローが多すぎて標準化もできていないからだ。
つまり、いくらERPなどのITシステムを導入しても、帳票出力システムに過ぎず、現場担当者の優秀さに頼り切っている。

【4】さすがにそんな状況はまずいと考える経営者も多い。
そこでDX戦略を作るわけだが、一朝一夕には行かない。
まずは、職人芸のノウハウを形式知化し、現場担当者の優秀さに依存しない業務プロセスの確立が必要になってくる。

その段階が、Digitization。
まずはノウハウをデジタル化して、見える化すべき。
実際にやってみると、相当な量になる。
特に製造業は会社の歴史も長いケースが多いし、職人芸のノウハウもたくさんあるので、書き起こすだけでも大変だ。
しかし、その価値は十分にあると僕は考える。

なぜならば、昨今は人手不足や若者不足が当たり前なので、現場の優秀なベテランに頼り切るやり方はもう通用しないからだ。
技術継承するためにも、Digitizationは必須だ。

【5】Digitizationが進んでくると、業務プロセスも見えてくるので、Digitalizationによって、業務プロセス改善、さらにはプロセス改革まで進める。
だが、業務プロセスの改善程度ならまだしも、プロセス改革は相当難しいと感じる。
なぜならば、人の再配置、部署の改廃、ひいては子会社化やM&Aなどの組織構造の変化にも関わってくるからだ。

ITコーディネータ勉強会で聞いた事例では、ERP導入を通じて業務プロセス改革をやった時、ITコーディネータである部長の部下である総務部の女性3人が結局退職した、と話されていた。
業務プロセス改革により仕事がなくなり、彼女らの存在意義が無くなったからだ。
リスキリングや別の能力開発を行ったのだろうが、人間はそう簡単に変わらない。
ましてや40代、50代にもなれば、新しい知識や技術の習得は難しくなる。
しかし、そんな人間関係の軋轢も覚悟の上でやらなければならないだろう。

【6】そういう業務プロセス改革を突き進めると、最終的には、組織構造の変革を通じて、組織文化の変革、社員のマインド改革まで行き着く。
そうすると、組織変革を通じて、会社のコアコンピタンスも再定義されて、新しいビジネスモデルや新規事業創造に向かうだろう。

そういう流れがDX化であるが、実際は10年以上かけて体質変化させる流れになるだろうと思う。
人間はそう簡単に変わらないからだ。
人間はそもそも保守的な存在である。
人間は、環境変化に即座に順応できるわけではない。
人間は自らの価値観を持ち、プライドを持つからだ。

会社には、若者もいれば、ベテランもいるし、最近では女性がたくさんいる職場も当たり前だ。
女性にも若い独身女性もいれば、既婚女性もいるし、子育てしている女性もいる。
また、中国人やインド人、ベトナム人などの外国人のSEや作業員も多いはずだ。
つまり、以前に比べると、日本の製造業も多様な人材が職場に溢れている。
よって、彼らの価値観を会社の価値観に合わせるのは至難の業だ。

そんな状況を踏まえて、DX戦略を考えるべきだろう。

PLMツールとは部品表の構成管理ツールでありGitHubである

製造業のパッケージ製品に出てくるPLMとは結局何なのだろうか？
考えたことをラフなメモ書き。

【参考】
BOM/部品表入門: マテリアル・マネジメント改革の基本技術 (図解でわかる生産の実務) | 佐藤 知一, 山崎 誠 |本 | 通販 | Amazon

図解 DX時代のPLM/BOMプロセス改善入門 デジタル化 段階別課題解決のアイデア100 | 三河 進 |本 | 通販 | Amazon

5つの問題解決パターンから学ぶ実践メソッド BOM(部品表)再構築の技術 | 三河 進 |本 | 通販 | Amazon

誰も教えてくれない「生産管理システム」の正しい使い方 | 本間 峰一 |本 | 通販 | Amazon

誰も教えてくれない 「工場の損益管理」の疑問 | 本間峰一 |本 | 通販 | Amazon

誰も教えてくれない ｢部品工場の納期遅れ｣の解決策 | 本間峰一 |本 | 通販 | Amazon

誰も教えてくれない「SCM計画立案・遵守」の疑問 あなたの会社の生販在（PSI）計画は機能していますか？ | 本間峰一 |本 | 通販 | Amazon

製造業におけるPLM製品とMES製品の違いは何か？: プログラマの思索

E-BOMとM-BOMの違いは何か？: プログラマの思索

製造業のDXを推進する部門をITコーポレート部門に割り当てるとなぜ失敗するのか: プログラマの思索

製造業の本質は「すり合わせ」と「PSIのトレードオフ」にある｜akipii

【1】製造業でよく使われるパッケージ製品は、ERPだと思っていた。
いわゆる生産計画と生産実績の管理、そこから会計管理までつながる基幹系システムのことだ。

しかし、製造業ではもう一つの重要なパッケージ製品があると分かった。
それがPLMツールだ。
製品そのもののライフサイクル管理を指す。
たいていは部品表を管理するためのツールだ。

では、なぜPLMツールは製造業でそこまで重要なのだろうか？

【2】PLMツールの本質は、部品表の構成管理にある。
その理由と経緯について書いてみる。

【3】製造業のビジネスモデルとは、製品を製造して、付加価値を付けて販売することだ。
その製品は数多くの部品から構成される。

自動車なら10万個の部品、飛行機なら100万個の部品が必要と言われる。
その他の精密機械装置であれば、1万～10万点ぐらいの部品から組み立られるケースが多いだろう。
部品数が10個程度ならまだしも、数千個、数万個になると、人間の記憶や紙媒体だけで管理するのは難しい。

しかし、今までの中小製造業では、こういう組立加工の製品を現場の長年の勘と経験だけでやってきた。
ちょっとした大手製造業ですら、せいぜいExcel媒体で管理しているに過ぎないケースが多い。
日本の製造業の現場では、ベテラン社員が長年の技能経験を元に、部品のノウハウを蓄積してきたおかげで、口頭伝承でも何とか製造できてきた。
でも、新人社員の確保が難しくなったり、技能継承が難しくなったりして、もはや勘と経験だけでは維持できない。
だから、PLMツールを用いて、部品表を整備し、部品の特徴や組立加工時のノウハウを全て蓄積することで解決しようとする。

【3】一方、こういう勘と経験が長年続いてきた理由の一つに、日本の製造業は見込生産よりも受注生産が主体のビジネスモデルだったからではないか、と考えている。
実際、日本の製造業では製番管理で部品や原材料の発注購買から生産計画、生産指示、生産実績まで管理しているケースが非常に多い。
たとえば、中小製造業なら元請けから製造委託を受けたり、過去の受注生産を元にリピート受注したり、リピート製番から部品を少しカスタマイズして派生開発したりするケースが多いだろう。
つまり、過去の受注生産の実績データを元に、製番をどんどん派生させて部品を少し入れ替えたり、カスタマイズして生産するケースが多いのだ。
すると、今までの受注生産の経験を活かして、ちょっと派生開発する程度で、現場の頑張りで何とかやってこれた、という実態が多いのではないだろうか。

しかし、多品種少量生産が普通になった現代では、過去のリピート製番から多数の派生製品が作られるので、過去の変更履歴やその経緯、変更理由が分からなくなっている。
そのために、生産後のクレームや本番障害、生産途中の仕損品の増加などに苦しめられているのではないか。

だから、過去のリピート製番にある部品表や工程表（レシピ）を記録し、リピート製番から派生開発する時はその変更履歴や経緯を記録したい。
そのためにPLMツールを導入して、部品表の変更履歴を残したいのだ。

そんな経緯があるから、PLMツールが必要だと理解している。

【4】「BOM/部品表入門: マテリアル・マネジメント改革の基本技術 (図解でわかる生産の実務) | 佐藤 知一, 山崎 誠 |本 | 通販 | Amazon」では、部品表の履歴管理が重要だ、という主張がある。
今までその理由は分かっていなかったが、たぶん、日本の製造業ではリピートの受注生産が多い背景があるので、部品表の履歴管理をPLMツールで一括管理すべきだから、と考えている。

【5】PLMツールが部品表の構成管理であるということは、ソフトウェア開発にたとえれば、部品表の履歴管理をGitHubで管理しているようなものだ。
実際、過去の1つの製番に対し、複数の製番が派生開発されるケースが多いからだ。
つまり、ルートにある製番からツリー状にどんどん部品表が広がっていく。
ちょうど、カンブリア紀から現代までの生物の歴史みたいに。

【6】すると、PLMツールによる部品表の構成管理では、どのようにリビジョン管理されるのか？
そのやり方は「図解 DX時代のPLM/BOMプロセス改善入門 デジタル化 段階別課題解決のアイデア100 | 三河 進 |本 | 通販 | Amazon」に詳しく書かれている。

具体的には、リピート受注時に、大元の製番から派生させて新規製番を作る。
しかし、受注生産の場合は、製品の仕様が固まるまで、顧客と何度かやり取りが発生する。
その都度、製番に紐づく部品構成は何度も更新されて記録される。
普通はリビジョンを付けて管理する。

そして、最後に見積もり確定する時に仕様が固まる。
この時に、製番が確定するので、バージョンを付けてFixする。
バージョンを付けて確定した製番が重要であり、その途中経過のリビジョンの製番データは不要だ。
普通は、社内で設計部門が承認した版をバージョンとして残し、過去のリビジョンは消す機能がPLMツールに必要だろう。
これらの部品表の構成管理は、PLMツールのワークフロー管理機能として実現されているだろう。

ソフトウェア開発から見れば、丁度この考え方は、Githubのブランチ新規作成とタグ付けと同じだろう。

また、GitHubのDiff比較と同様に、PLMツールでもリビジョンごとの部品表比較が重要だ。
設計部門の運用を見ると、部品の差分結果のコメントに、変更理由や見積もりに至った経緯を書き込んでいる。
この差分結果を出力してエビデンスを残して、見積もりの根拠に使っている。

PLMツールには他にも重要な機能がたくさんあるので別途まとめてみたい。

【7】まとめとして、PLMツールの存在意義は何なのか？

PLMツールは元々、設計部門が作るE-BOM、生産計画部門が作るM-BOM、購買部門が作るP-BOM、保守サービス部門が作るS-BOM、それらを統合して一括管理するツールだ。
一方、日本の製造業のビジネスモデルでは、受注生産が非常に多く製番管理が主体なので、製番の派生開発のために部品表の構成管理として使いたい意図がある。

PLMツールで部品表の構成管理を一括管理できれば、部品表の精度が上がることで設計品質の向上、生産計画におけるM-BOMの精度向上により生産リードタイム短縮、受注前の引き合いで見積もりを即座に行うことによる見積もりリードタイム短縮につながるメリットがある。
そこまで行き着くには、製造業の内部で、単に部品表を口頭伝承や紙媒体からデジタル化するだけでなく、PLMツールに蓄積された資産を有効活用できる施策を実行しなければならない。
製造業にはまだまだ改善できる余地がたくさんあるのだ。

explaining-specific-examples-of-purpose-specific-bomfrom akipii ogaoga

how-does-mes-manufacturing-execution-system-workfrom akipii ogaoga