PMPとCSM取得者数推移（日本 vs 中国）から読み取れる指針は何か？

PMPとCSM取得者数推移（日本 vs 中国）を調べて、色々考えたことをメモ。

【参考】
アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント | 平鍋 健児, 野中 郁次郎, 及部 敬雄 |本 | 通販 | Amazon

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 | 西村 直人, 永瀬 美穂, 吉羽 龍太郎 |本 | 通販 | Amazon

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection) : Kenneth S.Rubin, 岡澤 裕二: 本

スクラム実践者が知るべき97のこと | Gunther Verheyen, 吉羽龍太郎, 原田騎郎 |本 | 通販 | Amazon

PM教科書 PMP完全攻略テキスト PMBOKガイド第7版対応 改訂版 (EXAMPRESS) | 鈴木 安而, PMアソシエイツ株式会社, 株式会社NTTデータユニバーシティ |本 | 通販 | Amazon

図解即戦力　PMBOK第7版の知識と手法がこれ1冊でしっかりわかる教科書 | 前? 和哉 |本 | 通販 | Amazon

【0】Gemimiに、PMPとCSM取得者数推移（日本 vs 中国）を調査させてみた。
結果は圧倒的に、中国人の方が取得者数が多いだけでなく、認定スクラムマスターは4倍、PMPに至っては10倍以上の差があった。

【1】Gemimiより：PMP（Project Management Professional）の日本および中国における取得者数について、PMI（Project Management Institute）の公開データ（Fact File）や年次報告書に基づき、2010年から2025年（最新予測・公開値）までの推移をまとめました。

中国は2010年代半ばから爆発的に取得者が増加し、現在は米国に次ぐ世界第2位の市場となっています。一方、日本は安定した増加傾向にありますが、その成長スピードには大きな差が出ています。

【PMP取得者数推移（日本 vs 中国）】
※2025年は最新の公開統計および市場動向に基づく推定値、その他はPMI公式データに基づきます。

年度 日本 (Japan) 中国 (China) 備考
2010 約 24,000 約 45,000 中国の伸びが加速し始めた時期
2011 約 26,000 約 55,000
2012 27,841 70,256
2013 29,150 85,000
2014 31,500 110,000 中国が10万人を突破
2015 33,200 135,000
2016 34,800 150,000
2017 36,400 190,000
2018 37,200 240,000 中国の増加ペースが年5万人規模へ
2019 38,500 300,000
2020 39,200 330,000 パンデミックにより試験休止等の影響
2021 41,000 380,000
2022 42,500 450,000
2023 44,100 520,000
2024 45,649 580,360 中国が日本の10倍以上の規模に
2025 約 47,000 約 630,000 (予測値)

【2】Gemimiより：スクラムマスターの普及は、PMP以上に「アジャイル開発」の浸透速度と比例しています。
日本は2010年代後半から急速に伸びている一方、中国はPMP同様に圧倒的な母数で推移しています。

【CSM取得者数推移（日本 vs 中国）】
※数値はScrum Allianceの年次報告書および公開統計に基づきます。2025年は最新の四半期統計からの予測値です。

年度 日本 (Japan) 中国 (China) 状況の推移
2010 約 250 約 1,200 日本ではごく一部の先進層のみ
2011 約 450 約 2,000
2012 710 3,400
2013 1,020 5,800 日本で1,000人を突破
2014 1,450 8,200
2015 2,100 12,000 中国で1万人を突破
2016 2,800 18,500
2017 3,900 26,000
2018 5,500 35,000 日本でDXの機運が高まり増加加速
2019 7,800 48,000
2020 10,200 55,000 パンデミックによりオンライン研修が普及
2021 13,500 68,000 日本で1万人を突破
2022 17,000 82,000
2023 21,500 98,000
2024 26,800 115,000
2025 約 32,000 約 135,000 (予測値)

【3】PMPとCSM取得者数の比較より、Geminiにも聞きながら、何が読み取れるか？

1つ目は、中国の方が日本よりも、PMPやCSMの取得者数が多い事実より、特にプロジェクトマネジメントが個人のスキルではなく、グローバル競争における「共通言語」として定着していること。
数値の差は、そのままグローバル市場での「交渉力」や「信頼性」に直結する。
つまり、IT業界だけでなく、製造業や建設業、公共事業などの他業界でも、巨大なプロジェクトを統制するための型があり、共通言語もあり、意思決定が速いだろう。

一方、日本国内では「阿吽の呼吸」で成立していたプロジェクトも、グローバル市場では通用しない。
色々な場面で、日本人が太刀打ちできないシーンが増えているのだろう。

日本では、PMPもCSMも会社や国家が強制することもなく、個人の自己研鑽が主に発生源となって資格取得しているだろう。
つまり、中国では組織的な徹底力で取得人数も圧倒的に増やして、それを標準プロセスとして強制的に運用しているのに、日本では資格取得が「個人の自己研鑽」に留まるケースが多く、取得した知識を組織全体のプロセス改善（BPR）にまで昇華させる力が弱い。

すなわち、日本人単独の意思が強くても、その人数は非常に限られていて、「資格＝学習」で止まり、「組織の武器」にならない。

2つ目は、日本では、「マネジメントの二極化」による断絶があること。

日本ではPMPの伸びは緩やかだが、CSM（アジャイル）の伸び率が近年高まっている。
これは、ウォーターフォール型の管理から、より柔軟な開発体制（DX推進）へ急速に舵を切っている過渡期にあることを示唆している。
やはり、日本人のソフトウェア開発者もその問題意識を持っている。

特に、日本でのスクラム普及は、組織の上層部からの命令（トップダウン）ではなく、現場のエンジニアや若手リーダーが「このままでは開発が回らない」と危機感を持って取得し始めるボトムアップ型が多いのが特徴らしい。
実際、僕の周囲でも、開発現場の危機感から認定スクラムマスタを取得するパターンを多く見かけた。
そもそも、日本のSIerはこういう研修にお金を支払わないから。

しかし、日本ではPMP的な「管理層」とCSM的な「現場層」が分断されがち。
経営層は依然としてウォーターフォール型の進捗（ガントチャートやマイルストーン）を求め、現場はアジャイルで動こうとするため、その摩擦で中間管理職であるプロジェクトマネージャが疲弊すうｒ
中国や米国では、管理者がアジャイルを理解した上で「ハイブリッド型」のガバナンスを構築するスピードが速いらしい。
つまり、PMP的な管理層もアジャイルの価値を認識したうえで、PJ全体はWF型であっても、マイルストーン単位に区切ったスプリントではアジャイルに開発するなど、現実に柔軟に対応しているわけだ。

すなわち、日本では、現場の開発者は危機感や自己研鑽を持ちながらも、経営層はそのモチベーションを有効活用できず、ビジネスの環境変化のスピードに追随できていない。

特に、PMPやCSMの取得者数の伸び率（傾き）は、そのまま「ビジネスの意思決定スピード」の代用指標になる。
中国が日本の10倍以上の速さで標準化を進めている間、日本は「どの資格が自社に合うか」の検討に時間をかけすぎて、スピードが遅すぎる。

まあ、結局、組織として推進する力も必要なのだろう。

自動車の組込ソフトウェア開発が難しい理由は3つある

自動車の組込ソフトウェア開発の現場を見ると、とても難しいなと思う。
第三者視点で考えたことをメモ。

【参考】
自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か？: プログラマの思索

システムズエンジニアリングに基づく製品開発の実践的アプローチ | 後町智子, 土屋浩幸, 鈴木　研 |本 | 通販 | Amazon

図解カーエレクトロニクス 上 システム編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

図解カーエレクトロニクス 下 要素技術編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] エンジニアリングセット | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] 管理支援 | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

ISO26262 2nd実践ガイドブック［エンジニアリングセット］ | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

詳解 車載ネットワーク -CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために- | 藤澤行雄, 品川雅臣, 高島 光, 村上 倫, 石本裕介 |本 | 通販 | Amazon

【1】自動車の組込ソフトウェア開発を現場で見ていると、皆いつも忙しそうにしている。
基幹系システム開発の時よりも大変なように見える。

組込ソフトウェア開発の初心者である僕から見て、ハードとソフトを組み合わせて正常動作させることすら、根本的に難しいように思う。
業務系Webシステムの設計・開発・保守を経験した僕が見て、ハードと一体化したソフトウェア開発は、ハードレベルに近い知識も必要。
相当大変なように思える。

また、自動車にも自動運転のように、AIを使った機能追加は当たり前になった。
おそらく、どのOEMメーカーも、どの部品メーカーも、AIを使った新機能の開発、さらには研究開発に相当のリソースを投入しているはずだ。
もはやハードウェアに付加価値はないので、ソフトウェアでいかに付加価値を上げるか、にビジネスモデルの力点が移動している。
しかし、AIの開発は、組込ソフトウェアやWebシステムとは異なる異次元の専門知識も必要なので、習得のハードルも高い。

さらに、自動車の製造には、数多くのISO規格の認証が必要だ。
なぜならば、民生品と言えども、人命に関わる製品なので、人命第一の品質保証が問われるからだ。
数多くのISO規格の監査を踏んで承認が得られなければ、そもそも販売できない。

そんな状況を踏まえると、自動車の組込ソフトウェア開発が難しい理由は、3つあると思う。

【2】１・ECUというハードとソフト双方を結合した部品を作った後に、さらに複数のECUを統合して初めて1台の自動車が完成するので、結合・統合テストで非常に苦労する。

そもそも、ECUとは、車載の電子制御装置（Electronic Control Unit）の略。CPUが10個ぐらい搭載されていて、ハード部品と組込プログラムから成る。例えば、エンジンECU、ブレーキECU、エアバックECU、自動運転ECUなどがある。一般に、デンソーのようなTier1メーカーが製造し、OEMメーカーであるトヨタ、ホンダに納品し、OEMメーカーが20～50個くらいのECUを結合して1個の自動車を作る。

Geminiでは、下記の解説があった。
車ECU（Electronic Control Unit）は、自動車のエンジン、ブレーキ、エアバッグなど様々なシステムを電子的に制御する「車載小型コンピューター」です。センサーから得たデータをもとに最適な動作を計算し、1台の車に約100個搭載されることもあります。現代の車には不可欠な「頭脳」です。
ECUの主な特徴と役割
役割（自動車の「頭脳」）: エンジンの燃料噴射・点火制御、ブレーキ（ABS）、パワーステアリング、車線維持支援など、安全・快適・性能を包括的に管理します。
構成: マイクロコントローラ、メモリー（ROM/RAM）、入出力インターフェースで構成され、厳しい耐熱・耐振動設計が施されています。
連携: 車載ネットワーク（CAN）を介して、それぞれのECUが連携して動作します。
種類: エンジン系、シャシー系、ボディ系（ライト、ドア）、情報系（ナビ）など、機能ごとに分散しているほか、これらを統合する「統合ECU」の採用も進んでいます。
近年は、自動運転や電動化の進展に伴い、より高度な処理能力を持つECUの重要性が高まっています。

つまり、ECUに組み込むソフトウェアのテスト、ECUというハードとソフト自体の結合テスト、さらには複数のECUを組み合わせた1つの自動車という統合テストという多段階のテストが必要。
Webシステムのような単純なテストモデルではない。

また、彼らのテスト作業を見ると、回這う現場にはECUというハードの台数が少ないので、ECUのテスト時間を予約して、その間にテストしてバグ出ししている。
ECUというテスト機器も1チーム1台ではなく、複数チーム1台しかないので、テスト機器の確保が大変みたい。
すなわち、ハードに縛られたソフトウェア開発では、テスト対象のECUというハードウェアが作業のボトルネックになりうる。

【3】２・自動運転（AD）や走行制御（ADAS）のように、全てのECUに指示制御する統合ECUが初めて出現したために、従来のハード中心のゾーンアーキテクチャからソフトウェア主導のアーキテクチャに変わったので、ソフトウェア開発力が弱いメーカーは非常に苦しいと思う。

Geminiに聞くとECUのアーキテクチャには、ハードの名残りから進化した歴史がある。

自動車の脳にあたる「コンピューター（ECU）」の配置ルールは、進化とともに3段階あります。
・ドメイン型：役割ごとのチーム制。「走る」「止まる」など機能別に脳を分ける方式です。機能が増えるほど配線が複雑になり、車が重くなるのが弱点です。
・ゾーン型：場所ごとのエリア制。「右前」「後ろ」など車の場所で脳をまとめます。近くの部品を最短の配線でつなぐため、線を劇的に減らして軽量化できます。
・セントラル型：一極集中制。車の中央に超高性能な「1つの脳」を置き、全てを指揮します。スマホのようにソフトの更新だけで車の性能を後から進化させやすくなります。
現在は、配線を減らしつつ高度な制御を行うため、2と3を組み合わせた形が主流になりつつあります。

つまり、最近では、自動運転（AD）や走行制御（ADAS）が全てのECUを指示・制御する必要がある。
そのために、ADやADASの機能を持つ統合ECUが必須となるセントラル型アーキテクチャが主流になっていると思う。
ハード面でもソフト面でもアーキテクチャ設計が以前よりも遥かに重要な印象。

昔は、トヨタやホンダが「ハードの部品のすり合わせ」により1つの自動車を作っていた印象。
しかし、今は、SDVという「車のAPI化やOTAでソフトウェアによるハード制御などの実装に近い設計手法」になったために、
20～50個ものECUを結合して、性能、品質、セキュリティなどを担保するのは、昔ながらの「すり合わせ」では実現不可能。

「すり合わせ」という複数チームのコミュニケーション活動による解決ではなく、ハード面でもソフト面でも「アーキテクチャにより自動車の構造をすり合わせる」へ時代が変わったと考える。
だから、MBSEのような「アーキテクチャ主導の製品開発」が重要になってきたと考える。

【4】３・A-SPICE、機能安全、サイバーセキュリティのような監査プロセスを踏んで品質担保を保証する必要がある。
ソフトウェア開発チームはソフトウェア開発だけでなく、監査ドキュメント作成の作業負荷も増えている。
これらの規格をOEMメーカーがTier1の部品メーカーに要求するため、開発現場はいつも人手不足で作業が大変な印象。

その問題点は下記に書いた。

自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か？: プログラマの思索

【5】自動車のソフトウェア開発が面白いなと思う点は、元々、ハードとソフトを組み合わせるので難易度が高い上に、MBSEのようなアーキテクチャ主導のソフトウェア開発が必要になったこと、更には、A-SPICE、機能安全、サイバーセキュリティのようなISO規格遵守も必要になったことにより、他のシステム開発よりも複雑かつ難易度が高い点だ。

一方、他の製造業の業界に比べると、トヨタを頂点とした自動車業界は品質面でもプロセス面でも優れているので、彼らの考え方を理解できれば、他の製造業を富士山から眺めるような観点で見下ろして、強みや弱みを比較分析して把握できるだろうと思う。
たとえば、家電、機械製品、化学、医療、食品加工、防衛産業などの製造業を比較評価することで理解しやすくなると思う。

その辺りも色々考えてみたい。

自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か？

自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善の話を聞いてきた。
自動車業界の裏話もたくさん聞けて、すごく有意義だった。

【参考】
【ハイブリッド開催】品質・効率・安全を同時に実現する統合開発プロセスの最新アプローチ （第75回 SEA関西プロセス分科会） | Peatix

図解カーエレクトロニクス 上 システム編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

図解カーエレクトロニクス 下 要素技術編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] エンジニアリングセット | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] 管理支援 | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

ISO26262 2nd実践ガイドブック［エンジニアリングセット］ | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

詳解 車載ネットワーク -CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために- | 藤澤行雄, 品川雅臣, 高島 光, 村上 倫, 石本裕介 |本 | 通販 | Amazon

システムズエンジニアリングに基づく製品開発の実践的アプローチ | 後町智子, 土屋浩幸, 鈴木　研 |本 | 通販 | Amazon

【1】聞いた講演のストーリーはこんな感じ。
自動車業界では、従来のISO9001系列の規格だけでなく、A-SPICE・機能安全・サイバーセキュリティの規格が次々に導入された。
本来のハード設計、組み込みソフトウェア開発だけでなく、その開発プロセスがこれらの規格に準拠していることが求められる。
そのために、監査のドキュメントが多くて開発現場の負荷が高く疲労している問題が出ている。

そこで、A-SPICE・機能安全・サイバーセキュリティの規格で定義されるプロセス領域や各プロセスを整理統合したプロセスを作ることで、1つの監査資料で複数のアセスメントに対応できるようにしたり、整理統合したプロセスの順番に実施すれば、複数のアセスメントのレビューをスムーズに進められるように対応した、という流れ。

【2】僕としては、それぞれの規格に対する考え方を聞いて面白かった。

まず、A-SPICEは元々、CMMIから派生したSPICEというプロセスモデルがあり、これを自動車業界向けに特化したAutomotive-SPICEが作られた。
元々、CMMIの目的は組織の成熟度を上げるために成熟度モデルに従ってプロセス改善しましょう、という考え方だった。
しかし、A-SPICEはPJごとのアセスメントに行うために、他のPJではA-SPICEが当てはまらないケースが多くなる。
すると、A-SPICEに準拠しないPJにアサインされたメンバーはプロセス改善する目的も意欲もないので、目的が失われてしまい、組織のソフトウェア開発能力が上がらないという結果に陥りがち。
つまり、A-SPICEという規格を通すだけに頑張る、という環境に陥りがち。

そもそも、A-SPICEは欧州の自動車メーカー、特にOEMメーカーが生み出した規格であり、A-SPICEはサプライヤに対する品質要求を定めて、サプライヤのふるい落としに使う。
部品メーカー、つまりサプライヤはプロセス改善に躍起になっているのが実情らしい。

聞いた話では、たとえば、OEMメーカーは、試作車の段階で4社のサプライヤから同じ部品を採用し、各段階でサプライヤを3社、2社と1社ずつふるい落とし、最後の量産工程で初めて1社に決定する。
つまり、サプライヤは試作段階では投資フェーズであり、量産工程で初めて投資を回収するわけだ。

サプライヤはA-SPICEに準拠するように対応するわけだが、A-SPICEを満たさない部品を納入した場合、サプライヤは罰金を支払う契約になるらしい。
つまり、サプライヤは納入して代金をもらうはずなのに、逆に罰金まで支払ってでも、量産工程に採用されるために対応し続ける時もあるらしい。
それぐらい、OEMメーカーに部品を採用されるのは利益があることなのだろう。
そんなA-SPICE規格の内情を聞くと、かなりしんどいプロセスだなと思う。

【3】機能安全の規格は原子力発電所やプラント工場が対象らしく、民生品向けでは自動車が初めてらしい。
機能安全のよくある例は、踏切だ。
たとえば、踏切を安全に動作させるために、バーを付けたり、センサーを付けたり、音を鳴らしたり、点灯させたりする。
そういう機能を付加して、安全を保証するわけだ。

また、危険な状態になったら、安全な状態へ移す機能をつける場合もある。
いわゆるフェイルセーフ。

さらに、試作工程の設計だけでなく、量産工程でも機能安全を検討する。
たとえば、故障率も調べて、許容率よりも超えて故障したら、設計工程から機能安全を考えて作り直す必要も出てくる。
つまり、故障や誤操作を想定しながら、設計工程で機能安全の設計を考える必要があるわけだ。

機能安全の規格もかなり複雑かつ膨大な印象。
機能安全という品質特性は、全ての機能に横断的に関わるだろうから、特有の設計手法が必要だろうと思う。

【4】車載サイバーセキュリティの規格も機能安全と並ぶ、安全性確保のもう一つの柱。

車載サイバーセキュリティの規格が生まれたきっかけとしては、ジープクライシス（Jeep Hack/Crisis）があったらしい。
具体的には、2015年頃の米国で、2人のセキュリティ研究者が走行中のジープを遠隔でハッキングし、運転席のドライバーが操作できない状態で速度を落としたり、ブレーキを無効化したりできることをデモで証明したらしい。
つまり、コネクテッドカーに対するサイバー攻撃の脆弱性が実証・公表されたわけだ。
これにより、ジープの所有者から訴訟が起き、リコールや損害賠償に発展したらしい。
そこで、自動車メーカーは躍起になって規格を作って対応しようとしているわけだ。

【5】では、これらの規格に自動車メーカーはどのように対応しているのか？

基本は、ECUごとに、A-SPICE、機能安全、サイバーセキュリティの規格を当てはめる。
一般に、自動車のECUは100個近くあるらしいので、100個のA-SPICE、機能安全、サイバーセキュリティのドキュメントを全部作っている。
つまり、ECUごとに監査用ドキュメントが異なり、それぞれのアセスメントの観点も違うので、ECU100個　ｘ　3規格＝300個の書類を作る必要がある。
開発者の観点では、同一のECUというハードとソフトに対し、似たような、しかし違う観点の監査用ドキュメントを作らないといけない。
実際の現場を見ると、ハードにソフトを組み込んだ開発とテストだけで精一杯なので、後付けで監査ドキュメントを作っているようだった。
つまり、プロセス改善の目的や動機もなく、ただアセスメントを通すために資料作成している感じだった。

【6】最後の質問では、プロセス改善のコンサルの拠り所、肝は何か？という質問があった。
回答は2つあった。

1つ目は、現場の開発プロセスと規格のマッチング。
サプライヤの現場にはそもそも、開発プロセスという概念がなく、定義された工程がない場合がある。
すると、A-SPICEに応じたソフトウェア開発やハードウェア開発、ハードとソフトを統合した開発プロセスを最初から導入して、現場で初めて実践する必要がある。
あるいは、サプライヤに独自の開発プロセスがあったとしても、A-SPICEに合わせたハード・ソフトの開発プロセスに定義し直す必要がある。
どちらにせよ、規格に対応するだけで精一杯ではないかと想像する。

2つ目は、規格を現場に浸透させること。
アセスメントを依頼する人は管理者、企画部門になるが、監査ドキュメントを作るのは現場のソフト開発者やハード設計者になる。
現場の人には、規格に準拠する動機やインセンティブがない。
現場の人に、いかに、規格に即することが重要なのか、を浸透させる事が大事なわけだ。
しかし、A-SPICEはプロジェクト単位、ECU単位になるので、別PJになれば俺は関係ない、という立場になりやすい。

そういう葛藤を聞いて面白いなと思った。

データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか

関西IT勉強会で、データモデリングについて聞いてきた。
関西IT勉強会の議論について、@kitaohxさんと議論しながら、「データモデリングでは、システムが宿命的に負う複雑性をどのように解決しようとしているのか？」について気付きがあった。
ラフなメモ書き。

【参考】
販売管理システムで学ぶモデリング講座 (DB Magazine Selection) | 渡辺 幸三 |本 | 通販 | Amazon

システム開発・刷新のための データモデル大全 | 渡辺 幸三 |本 | 通販 | Amazon

業務別データベース設計のためのデータモデリング入門 | 渡辺 幸三 |本 | 通販 | Amazon

生産管理・原価管理システムのためのデータモデリング | 渡辺 幸三 |本 | 通販 | Amazon

業務システムのための上流工程入門 | 渡辺幸三 |本 | 通販 | Amazon

人月の神話 | フレデリック・P・ブルックス，Jr., 滝沢徹, 牧野祐子, 富澤昇 | 工学 | Kindleストア | Amazon

データモデリングの手法をあなたは持ってますか？ at 関西IT勉強宴会: プログラマの思索

「やさしいデータベース設計」出版記念講演 in 新大阪 - connpass

「やさしいデータベース設計」出版記念講演 in 新大阪 (第105回IT勉強宴会) | ＩＴ勉強宴会blog

【0】システムが持つ本質的な複雑性を、データモデリング屋はどのように解決しようとしているのか？

「人月の神話」には「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という一節がある。
この言葉は、システムが本質的な複雑性を持っている、という論点だし、SEもアーキテクトも皆、この論点をいつも考えていると思っている。
この内容について以下考える。

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

【1】お題は、大学生に対するストレスチェックみたいなアンケートシステムに対し、データモデルを書く。
渡辺さんは、ホワイトボードを前に、ライブ・コンサートみたいに、スラスラとデータモデルを書いていく。

データモデリングの手法をあなたは持ってますか？ at 関西IT勉強宴会: プログラマの思索

書いたデータモデルについて、参加者と議論があった。

外部キー制約の実装箇所はDB層なのか、アプリ層なのか、あなたがモデラーならどうする？

外部キー制約をRDDBMSに貼れば、ER図をそのまま実現できる形になる。
一方、大量データをデータ移行する時、外部キー制約があると、外部キーとして存在しないキーを登録するとエラーになる。
つまり、データをインポートする順番を事前検討する手間がかかる。
Railsや他のフレームワークでもそうだが、たぶん、RDBのテーブルは主キーぐらいの制約だけで、アプリ層で外部キー制約を実装する場合が多いだろう。

渡辺さんもえとうさんも、話を聞くと同じで、フレームワーク層に配置する、と。
つまり、DBMSに制約も張らず、アプリ層でもなく、その間のフレームワーク層に配置する意見で一致していた。

渡辺さんは自作のローコード開発基盤を持っているので、その基盤上で制約を実装する。
えとうさんはTM手法手法の人だが、Seasarを使っていると言っていたので、フレームワーク層で実装するのだろう。
僕の理解と合ってたので特に違和感なかった。

【2】この論点の問題をさらに発展させると、外部キー制約だけでなく、動的参照関係、ユニーク制約などのDBMSの制約ロジックはDB層なのか、アプリ層なのか、どこに実装すべきなのか？

渡辺さんは、外部キー制約、動的参照関係、ユニーク制約など、DBMSの関数従属性にプラスアルファされる制約条件は、ローコード開発基盤に実装すべきであり、アプリ層に配置すべきではない立場だ。
なぜならば、DBMSの制約条件とビジネスロジックは関心事が異なるから、という論点と理解している。
えとうさんはTM手法ですが、実装レベルでは、Seasarで実装していると言っていたので、フレームワーク層で実現する点は同じと理解している。

つまり、DB層とアプリ層の中間レイヤである純粋仮想化物の層であるフレームワーク層に、制約を配置すべきだ。

【3】アンケートシステムのデータモデルでは、渡辺さんがデータモデルに、「支援制約」「回答値制約」というカラムを書いていた。
ストレスチェックのアンケートシステムの目的は、学生の心身状態をアンケートで回答してもらい、心が病んでいる学生にはカウンセリングや薬物処方などの手当や支援が必要だ、という考え。
だから、アンケートの質問に応じて回答内容は何でも良いわけではなく、何らかの制約がある。
「支援区分」には学生、家族のようなカテゴリがあり、学生への支援内容、家族向けの支援内容ではそれぞれ対策が異なるので、何らかの制約がある。
そのような内容があるので、「支援制約」「回答値制約」と書いていた。

【4】では、「支援制約」「回答値制約」のような制約ロジックの内容をテーブルのカラムに埋め込むのか、フレームワーク層やアプリ層にロジックを実装するのか？

確か楽々フレームワークの人はフレームワークに実装する意見だった。
渡辺さんは、テーブルのカラムに制約ロジックまで入れてしまえばいい意見だった。
例えば、何らかの制約ロジックはJavaScript プログラムのテキストでカラムに放り込み、フレームワーク層でJSプログラムを評価して実行すれば良い。
そうすれば、プログラム実装やビルド、デプロイも不要で、データをアップデートすれば簡単と言う理由と思う。

【5】僕の意見では、単に制約ロジックと言う業務ロジックをDB層に配置するか、フレームワーク層やアプリ層のプログラミングする層に配置するのか、と言う単純な論点ではないと考える。
つまり、論点は、アーキテクトとして、システムが持つ本質的な複雑性をどのように解決しようとするか、だ。

システムが宿命的に負うべき複雑性をいかに分散して全体のコストを最小化すべきか？

一般に、普通のアーキテクトであれば、N層レイヤーの発想を元に、MVCモデルのように、ビジネスロジックを層別に分割し配置して、複雑性を人間の手で扱えるレベルまでバラす。

一方、データモデリング屋は、業務ロジックをできるだけDB層に全て表現したい欲求がある。
この利点は、本質的な複雑性をDB層に押し込むことで、機能を実装するアプリ層の複雑性を狭めて、アプリ開発のコストを減らしたい意図があると考える。
渡辺さんが提唱する三要素分析法は、システムが持つ本質的な複雑性をDB層に落とし込むために、データモデリングでもっと頭を使い、プログラミングするアプリ層は簡単にしたい発想と思う。

「販売管理システムで学ぶモデリング講座 (DB Magazine Selection) | 渡辺 幸三 |本 | 通販 | Amazon」では、「データモデルと業務モデルを複雑にして機能モデルを簡単にする」という言葉で表現されている。
この意味は、システムが持つ本質的な複雑性をDB層のデータモデルと、例外業務を含む業務手順に集約し、プログラミングで実装する機能モデル、つまり、アプリ層は複雑にすべきではない、という考え方だ。

実際、例外業務はいくらでもあるので、それを全てシステムで実装すべきではないだろう。
年1回しかやらない例外業務で手間が駆らないなら、業務マニュアルで解決すればいい。
例外業務をプログラミングしてしまうと、例外業務のロジックがあれば修正コストが発生し、トレードオフを考慮すると無駄になるかもしれない。

また、業務ロジックから発生する関数従属性の制約条件は、アプリ層で逐一実装するのではなく、DB層あるいはDB層を薄く包むようなフレームワーク層に配置すればいい。
プログラマは、関数従属性の制約ロジックを逐一実装しなくてもいい。
もっと本質的な業務ロジックを実装すべきだから。

【6】この発想を推し進めると、ローコード開発基盤は、データモデルやモデル駆動開発と相性がいいと思う。
ローコード基盤はDB層をラッパーしているから、プログラマはRDBMSのテーブルを直接触ることもないし、アプリ層で必要なオブジェクトだけ触れば、自然に制約条件が満たされる、という形になるはずだ。
つまり、DB層をラッパーしたフレームワーク層はローコード開発基盤というわけだ。

今後はAIがプログラミングしてくれるので、モデリングや要件定義の重要性が高まるから、ますますローコード開発基盤の重要性は高まるだろう。
我々は本来、事業に役立つ業務を実行したいのであって、無駄なプログラムを大量に作りたいわけではない。
ローコード開発基盤を使って、直接の利用ユーザが使いたいシステムを素早く品質よく作りたいのだ。

特にローコード開発基盤は、製造業の基幹系システム、生産管理システムでニーズが多いと思う。

データモデリングを極めていくと、ローコード開発基盤に落ち着き、さらにはAIエージェント駆動によるプログラミング自動生成までつながるのが面白い。

【補足】
データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて | 杉本 啓 |本 | 通販 | Amazon

実践的デ-タモデリング入門 (DB Magazine SELECTION) | 真野 正 |本 | 通販 | Amazon

やさしいデータベース設計　要件定義から運用までの勘どころ | 衛藤 豊 |本 | 通販 | Amazon

事業分析・データ設計のためのモデル作成技術入門 | 佐藤 正美, TMの会 |本 | 通販 | Amazon

データモデリングの手法をあなたは持ってますか？ at 関西IT勉強宴会

関西IT勉強宴会で、データモデリングについて聞いてきた。
データモデリングの手法をあなたは持ってますか？と皆に聞かれた気がした。
ラフなメモ書き。

【参考】
やさしいデータベース設計　要件定義から運用までの勘どころ | 衛藤 豊 |本 | 通販 | Amazon

「やさしいデータベース設計」出版記念講演 in 新大阪 - connpass

「やさしいデータベース設計」出版記念講演 in 新大阪 (第105回IT勉強宴会) | ＩＴ勉強宴会blog

事業分析・データ設計のためのモデル作成技術入門 | 佐藤 正美, TMの会 |本 | 通販 | Amazon

システム開発・刷新のための データモデル大全 | 渡辺 幸三 |本 | 通販 | Amazon

業務別データベース設計のためのデータモデリング入門 | 渡辺 幸三 |本 | 通販 | Amazon

生産管理・原価管理システムのためのデータモデリング | 渡辺 幸三 |本 | 通販 | Amazon

業務システムのための上流工程入門 | 渡辺幸三 |本 | 通販 | Amazon

【1】渡辺さんのライブモデリングは、いつ見ても、すごいと感じる。
佐野さんよりいきなり、お題は、大学生に対するストレスチェックみたいなアンケートシステムに対し、データモデルを書いてみましょう。

渡辺さんは、大学と学生のテーブルを書いた後、こんな感じでホワイトボードに書き始める。
アンケートと質問が必要ですね。
質問はアンケートごとに作られるので行番号があり、アンケート回答ごとの何らかの制約は回答値制約、アンケートに基づき大学生の心身状態に対応する必要があるので、対応区分と対応制約があるね。

次に、アンケート実施した結果は、学校別アンケートが必要で、その元ネタは生徒別回答だね。
ここで、生徒別回答テーブルのカラムを書き出した時、さらっと「（対応区分）」と書いて、動的参照関係が出てくるね、と書き下す。

そして、アンケート結果から、学生の心身状態に対応する集計結果が必要なので、対応区分別SUM（サマリ）も必要だね。

最後に、学校別にもアンケート集計結果が必要で、学校別対応区分SUMがいるね。
ここで、学校別対応区分SUMへ、外部キー制約や親子関係を貼っていく。

では、このデータモデルを皆で見てみましょう。
ここで、「対応区分」という言葉が、アンケートシステムの目的にフィットしていないことに気づき、本来は学生の心身状態に応じて支援する対策を立てることであるから、「支援区分」と書きましょう、と赤字で書き直した。

衛藤さんが絶賛されていた点は、一度書いたデータモデルを赤字で「支援区分」に見直して修正したこと。
まさにモデラーですね。
データモデルに対し、最後まで美学というか、こだわりをもって、少しでも用語に違和感があれば最後まで粘って、用語を修正し、モデルを修正する。
ドメイン駆動設計で言う、ユビキタス言語にこだわっている。
モデラーの美学、コンサルの美学を僕も感じた。

【2】渡辺さんのデータモデリングの最大の利点は、DBMSの制約条件が自然に出てくることだ。
具体的には、外部キー制約だけでなく、ユニーク制約などだ。
ユニーク制約は、国民年金番号みたいに別の主キーがもう一つあるね、とか、取引管理番号みたいにもう一つの主キーがいるはず、という業務ルールを意識して考えなければ、出てこないだろう。

特に、動的参照関係という、DBMSでは実装できず、論理的なER図だけでしか表現できないような制約条件も、渡辺さんのデータモデリングでは自然に出てくる。
動的参照関係は、TM手法でも他のデータモデリング手法でも、明示的に導出される場面を見た時がない。

たぶん、渡辺さんの過去の経験値から、こういう手法が編み出されているのかなと想像する。

こういうシーンは過去にも見た時がある。
１０年以上前だが、花束問題のデータモデルに、テーブルの派生関係にさらに２次識別子を設けて、受払いの過去データと予定データを１つにまとめる手法は、目からウロコだった。

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

【3】TM手法と渡辺さんの関数従属性だけのモデリング手法は、どちらが優れているのか？
見た感じでは、渡辺さんの関数従属性だけのモデリング手法が生産性が高く、分かりやすい。

実際、今日はいきなり、佐野さんから、アンケートシステムのお題を出されて、渡辺さんはあっという間にホワイトボードにデータモデルを書き上げた。
しかも、実際にアンケートシステムは既に作られていて、その画面を見ながら答え合わせすると、そのデータモデルはほぼ同じ。

一方、TM手法では、２つのリソースの対照表を作っては、業務レベルで必要なのか吟味する作業を延々と続けるので、正確ではあるが、モデルを完成させるまでに手間がかなりかかる。
また、外部キー制約、ユニーク制約とか、特に動的参照関係の制約までは、業務ルールを意識しなければ出てこない。

【4】ただし、TM手法では、２つのメリットがあると思う。
１つは、リソース数とイベント数を数えて、リソース数＞イベント数であれば、新しいイベントを生み出すことで新しい事業を生み出す可能性があると指摘できること。

リソース数がビジネスの可能性に関係する理由: プログラマの思索

もう一つは、「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料: プログラマの思索に書いたように、２つの業務の順番を入れ替えることで、コストやリードタイムを劇的に改善できる可能性を指摘できること。
たとえば、「伝統的なセーターの製法は「糸を染めてからセーターを編む」」だが、「染色から販売まで6ヶ月もかかるので、見込生産になる。在庫が蓄積されやすい。」
しかし、「ベネトンは「セーターを編んでから染める」手法へ製造順序を逆転した」ことで「製造期間を短縮できるので、受注生産や直販が可能になった。在庫も減らせる。」

「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料: プログラマの思索

つまり、TM手法では、データモデルから新しい事業や業務を提案できる仕掛けを持っている。
その点が非常に面白いと思っている。

【5】渡辺さんのデータモデリングは何度か見ているが、今日みたいに、いきなりライブモデリングしていく姿に刺激を受けた。
関数従属性というたった一つのルールだけで、データモデルをTOBEとして描くことができるわけだ。
真似できないが、色々考えてみたいと思う。

【補足】
データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて | 杉本 啓 |本 | 通販 | Amazon

実践的デ-タモデリング入門 (DB Magazine SELECTION) | 真野 正 |本 | 通販 | Amazon

E-BOMとM-BOMの違いは何か？

E-BOMとM-BOMの違いは何かを考えると、日本の製造業に特有である製番管理とBOM管理が密接に絡むのではないか、という仮説を持った。

【参考】
なぜArasは国内PLM市場で支持されるのか　カギは“製造業の強み”への深い理解：国内製造業のPLM - MONOist

PLMを構築できない部門がやろうとすると失敗する

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

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

中小企業だからこそできる ＢＯＭで会社の利益体質を改善しよう！ | 谷口　潤 |本 | 通販 | Amazon

MES入門 | 中村 実, 正田 耕一 |本 | 通販 | Amazon

図解MES活用最前線: 実践事例でわかるMES〈製造実行システム〉導入のポイント | 中村 実, 中村 一世, 実践MES研究会 |本 | 通販 | Amazon

IoT時代のMESをもう一度考え直す ? (3) MESの未来像とは : タイム・コンサルタントの日誌から

IoT時代のMESをもう一度考え直す ? (1) MES普及を妨げたもの : タイム・コンサルタントの日誌から

IoT時代のMESをもう一度考え直す ? (2) MESの機能と階層を理解する : タイム・コンサルタントの日誌から

【1】僕はERPに含まれる生産管理、つまりM-BOMとMRPの部分の機能しか知らなかった。
だから、BOMに種類があり、目的ごとにBOMの使い道が違うという発想がなかった。

日本の製造業のうち、組立製品や部品加工業が多いと思う。
東京や大阪の下町で見かける中小企業の工場がまさにそうだろう。
彼らのビジネスモデルは、多品種小ロットの受注生産だ。
たいてい、大企業や元請けから受注した一品物の部品や製品を製造し納入するビジネスモデル。

その仕組は製番管理であり、受注生産になる。
すると、受注時に製品の設計図を作って、顧客とすり合わせしながら設計図を固めて、初めて受注が確定する。
その時に、設計BOMなるE-BOMが確定する。
普通は、リピート製品が多いので、過去の製番に紐づくE-BOMを元に、ちょっと部品をカスタマイズして設計図を完成させる。

そのE-BOMを元に、部品ごとの単価表を組み合わせた部品原価と、工場人員の作業工数、設備機械や電気水道などの運用費用をあわせた製造原価が確定する。
それが見積もりBOMになる。
見積もりはQuoteなのでQ-BOMと呼ぶときもあるらしい。

見積BOMを元に、製造スケジュールや負荷計画を立てて、生産計画を作る。
それが製造BOM、つまりM-BOMになる。
ここからMRPを使って、製品に必要な部品をいつまでにどれくらい手配すべきか確定し、部品発注される、という流れ。

5つの問題解決パターンから学ぶ実践メソッド BOM(部品表)再構築の技術 | 三河 進 |本 | 通販 | Amazonを元に、受注から生産までの流れを書いてみた。

explaining-the-flow-of-purpose-specific-bomfrom akipii ogaoga

【2】BOMには、E-BOMやE-BOMだけでなく、P-BOM、S-BOMなどもある。
実際にインスタンスを書いてみると理解しやすい。
中小企業だからこそできる ＢＯＭで会社の利益体質を改善しよう！ | 谷口　潤 |本 | 通販 | Amazonを元に、具体例を書いてみた。

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

ポイントは、部品を自社で作るのか、外部に委託するのか、しかも外部に委託する時に部品や材料も渡して組み立ててもらうのか、などの種類によってBOMの構成が変わること。
また、S-BOMのように、販売後の保守では、単なる保守サービスだけでなく、オプション品を提案することで売上を確保する営業もしていきたい、という発想までつながる。

【3】目的別BOMで考えた時、どのBOMが一番重要なのだろうか？
BOMをマスタ保守すべき対象として考えた時、E-BOMが一番重要だろう。
なぜならば、E-BOMが全てのBOMの発生源となるからだ。
E-BOMの内容がおかしかったりブレていれば、そこから派生するM-BOMもP-BOMもS-BOMもおかしくなってしまう。

また、多品種小ロットの受注生産が基本的なビジネスモデルでは、製番管理とE-BOMが密接に絡む。
受注時の顧客要望より、過去のE-BOMに似たような製品を抽出してきて、そのE-BOMをカスタマイズして製番が確定する。
つまり、製番には、製造すべきE-BOMがある。
よって、製番に紐づくE-BOMは、今までに蓄積してきたE-BOMのどこかから派生しているので、何らかのツリー構造を持つ。

すなわち、E-BOMは過去の製番の履歴が蓄積された巨大な部品のツリー構造をマスタとして持つ。
これこそが、製造業の競争力の源泉になるわけだ。

しかし、製造業の中小企業はもちろん、大企業であっても、E-BOMをきちんと管理できている現場は実は少ない。
IT化されていない頃は紙の製図で設計図を書き、そこに部品情報を書き込んでいたので、E-BOMとして抽出できていない。
たいていの製造業では、たくさんの設計図が紙やExcel、PDFなどが存在するが、マスタとして利活用できる状態ではない。
だから、PLMで一括管理して、資産管理しましょう、という流れ。

【4】E-BOMとM-BOMの違いは何か？
それは、E-BOMが全てのBOMの発生源であり、M-BOMは生産計画に使われるBOM。
それらBOMを全工程で統合して一括管理するツールがPLMになるわけだ。

PLMの考え方は、図解 DX時代のPLM/BOMプロセス改善入門 デジタル化 段階別課題解決のアイデア100 | 三河 進 |本 | 通販 | Amazonが一番分かりやすかった。

【5】佐藤 知一さんが下記Blogに書かれていた「E-BOMをコンフィグレータとして使う」イメージがようやく分かった。

IoT時代のMESをもう一度考え直す ? (3) MESの未来像とは : タイム・コンサルタントの日誌から

E-BOMができていれば、部品構成が分かっているので、そこから自動で見積もりが一瞬で出てくる。
さらに、部品をオプション部品やカスタム部品に分類しておけば、顧客に最適なオプション部品を提案してさらに付加価値を上げることができる。
そういうE-BOMの仕組みをコンフィグレータ（コンフィギュレータ）でシステマティックに作っておくわけだ。

しかし、コンフィグレータを作ってきちんと管理できている製造業は少ないだろう。
ちょっとした複雑な製品になれば、部品点数は１万点、１０万点ぐらいにすぐに膨れ上がる。
それらを何十年もかけて、全ての受注生産した製品のE-BOMを管理するのは難しい。

また、日本の工場は、設計者も製造担当者も真面目に働きすぎているので、IT化しなくても工場が回るのだろうと納得した。
今まで、E-BOMやコンフィグレータがなくても、受注生産してきて、売上を確保してきたからだ。
現場の人たちの頑張りのおかげ。

とはいえ、さすがに現代ではそのやり方は通用しなくなってきたという状況なのだろう。
この辺りの考察は再度まとめる。

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

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

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

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

受注生産に徹すれば利益はついてくる！ | 本間峰一 |本 | 通販 | Amazon

製造業におけるPLM製品とMES製品の違いは何か？

製造業におけるPLM製品とMES製品の違いは何なのか。
この問題を考えると、製造業のシステムは、PLM、ERP、MESの3層構造からなるのではないか、という仮説を持った。

【参考】
MES入門 | 中村 実, 正田 耕一 |本 | 通販 | Amazon

図解MES活用最前線: 実践事例でわかるMES〈製造実行システム〉導入のポイント | 中村 実, 中村 一世, 実践MES研究会 |本 | 通販 | Amazon

IoT時代のMESをもう一度考え直す ? (3) MESの未来像とは : タイム・コンサルタントの日誌から

IoT時代のMESをもう一度考え直す ? (1) MES普及を妨げたもの : タイム・コンサルタントの日誌から

IoT時代のMESをもう一度考え直す ? (2) MESの機能と階層を理解する : タイム・コンサルタントの日誌から

【1】製造業の基幹系システムは結局何があるのか？
普通は、ERPやその一部機能であるMRPなどの生産管理機能だろう。

しかし、工場の現場では、M-BOMとMRPのような製造工程だけの管理だけがメイン作業ではない。
その部分は、いわゆるMRPの機能を含むERPに相当するが、それ以外の機能も必要なんだ、と現場を見て知った。

僕の理解では、製造業の基幹系システムは、PLM、ERP、MESの3つが必要であり、3層構造からなると考える。
特に、MESの観点が漏れていたなと思った。

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

【2】まず、製品を製造するには、製品の設計図をCADで作る必要がある。
その製品の設計図から、まずE-BOMという設計BOMが作られる。
その設計BOMが製造BOMであるM-BOMの発生源になる。

E-BOMもM-BOMもBOMの一種であるが、設計→製造→販売後の保守という流れの中でBOMは当然変化するので、何らかの履歴管理として残していきたい。
それらBOMの変遷サイクルを管理する製品がPLMになる。

つまり、PLM（Product Lifecycle Management：製品ライフサイクル管理）は、製品の企画、設計、製造から、販売、保守、廃棄に至る全プロセスの技術データやプロセスを一元管理する手法・システム。

【3】ERPは、一般に販売管理、会計管理などの業務が主体だが、生産計画と購買管理を持つ生産管理システムも含む。
すなわち、E-BOMで定義された部品構成とBOP（工程表）を元に、製造スケジュールや工場の設備・人員のリソースを考慮して生産計画を立てる。
生産計画から生産指示が工場の現場に送られて、実行される。

explaining-the-flow-of-purpose-specific-bomfrom akipii ogaoga

【4】PLM、ERPの製品が必要なことは分かるが、製造業の役員・部長クラスはそれだけでは不十分らしい。
彼らの問題意識を聞いてみると、生産計画に対し、工場の進捗状況や発生原価をリアルタイムに把握して、生産・販売・在庫をリアルタイムに管理したいらしい。
そのために、生産現場の各工程のKPIを取得したいらしい。

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

実際にその内容を見ると、製造現場で各工程の直接作業工数、設備などの運用費用、部品の費用なども考慮したコストも把握したいらしい。

たぶん、それを管理するためのシステムは、MESになるだろうと思った。

MES（製造実行システム：Manufacturing Execution System）は、製造現場の生産工程、作業者、設備をリアルタイムで管理・監視・支援するシステム。上位の生産管理システム（ERP）と現場の制御機器の中間に位置し、作業指示、進捗管理、品質管理、設備保全などのデータを収集・分析して生産効率を最大化する。

【5】IoT時代のMESをもう一度考え直す ? (3) MESの未来像とは : タイム・コンサルタントの日誌からを読んで気づいたのは、工場の生産ラインにあるNC制御装置や工作機械をプラグラム制御しているのだから、それらの設備機械に生産手順だけでなく、生産計画も流し、生産実績も吸い取れば、生産進捗を管理できるはず。
それがMESなんだな、と気付いた。
ソフトウェア開発のPJ管理ツールで、実際の開発者の作業管理に使うのと同じ。
製造業の進捗管理は、MESという製品でカバーするわけだ。

しかし、MESというシステムはほとんど聞かない。
日本ではなぜMESが導入されていないのか？
MES入門 | 中村 実, 正田 耕一 |本 | 通販 | Amazonのような優れた本が2000年代初頭から出版されているのに、誰も見向きもせず絶版になっている。

一方、PLMについては、2000年代初頭から製造業において必要性がうたわれて、導入がようやく進みつつあるように思える。
PLMの導入が遅れた理由は何があるのか？

これらの問題も考えてみたい。

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

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

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

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

受注生産に徹すれば利益はついてくる！ | 本間峰一 |本 | 通販 | Amazon

日本の半導体産業はなぜ凋落したのか

日本の半導体産業はなぜ凋落したのか？
エヌビディア 半導体の覇者が作り出す2040年の世界を読んで理解できた。

【参考】
エヌビディア 半導体の覇者が作り出す2040年の世界 | 津田 建二 |本 | 通販 | Amazon

教養としての「半導体」 | 菊地 正典 |本 | 通販 | Amazon

図解即戦力　半導体プロセスのしくみとビジネスがこれ1冊でしっかりわかる教科書 | 先端テクノロジー業界研究同好会 |本 | 通販 | Amazon

Amazon.co.jp: 電子立国は、なぜ凋落したか : 西村 吉雄: 本

「電子立国は、なぜ凋落したか」の感想～日本の技術者は減価償却のコスト意識が低い: プログラマの思索

これでよいのか?日本の半導体市場シェアが単調下落し続けついに5%台まで下落 - セミコンポータル

【0】日本の半導体・デジタル産業戦略の今後の方向性は、経済産業省の下記レポートが分かりやすい。

第14回　半導体・デジタル産業戦略検討会議 （METI/経済産業省）

半導体・デジタル産業戦略の現状と今後

【1】半導体は2026年の今、製造業の中で最重要な製品になる。
半導体があるから、スマホ、PC、自動車、家電製品、制御装置など、ありとあらゆる製造物には半導体が埋め込まれている。
半導体があれば、プログラム制御できるし、プログラムを自由に書き換えることにより、高機能化しやすい。
さらに、現代では、AIがGPUを大量に消費するので、半導体の重要性はさらに高まっている。
特に、AIデータセンター建築のために、半導体を浪費しまくっている。
そのために2026年後半から半導体不足に陥る予想が出ているほどだ。

【2】1980年代の日本は家電立国だった。
半導体のシェアは、日本が殆どを占めていた。
しかし、90年代から右肩下がりとなり、今やシェアは5％くらいに過ぎない。
米国はもちろん、台湾、韓国、中国に圧倒的に負けている。

日本の半導体業界の技術者は優秀だ。
僕も優れた知り合いを知っている。
実際、東芝、NEC、日立など。
フラッシュメモリを生み出したのも東芝だった。
しかし、2026年の日本では、ルネサスとか、TSMCやサムスンに比べるとあまりパッとしない企業しか存在しない。

【3】なぜ、日本の半導体産業は凋落したのか？

エヌビディア 半導体の覇者が作り出す2040年の世界では、こんなストーリーだ。

家電メーカーの経営者が半導体業界の環境変化を認識できず、事業戦略を間違えた。
家電メーカーは、白物家電、公共インフラ、車載機器、半導体などたくさんの事業部門を抱えているので、どの事業に注力すべきか、選択と集中がやりにくいし、カニバリゼーションになりやすい。
図体だけ大きくて、意思決定も遅い。
欧米の独裁者のようなCEO、中国韓国のアジア圏にいる家父長制のCEOに比べて、経営者の意思決定が遅すぎる。

【4】半導体製造は元々、日本の家電メーカーが垂直統合でやってきた。
しかし、90年代以降、設計や露光・エッチング・洗浄などの製造、品質評価など後工程のように、各工程ごとにバラバラに水平分業のサプライチェーンに変わった。

なぜ、半導体製造は垂直統合から水平分業に変わったのか？
理由は簡単だ。
半導体製造の設備投資額は膨大なので、1社がすべての工程を抱えることはほぼ不可能になったからだ。
ポーカーゲームのような賭金で設備投資をどんどん積み上げていくスピードについていけなかった

つまり、設計だけ行うファブレス、TSMCのような製造を行ってに引き受けるファウンドリ、後工程だけを請け負う専業メーカーに細かく分かれて、一つのサプライチェーンをなす構造に業界そのものが急激に変化した。
この環境変化に結局、日本の家電メーカーは追随できなかった。

【5】また、各工程ごとに半導体製造装置を納入する製造装置メーカー、原材料や特殊薬品を納入する化学用品メーカーが多数あり、それらメーカーの規模もかなり大きい。
つまり、半導体製造業界は、非常に専門化されて分業化された流通構造、サプライチェーンを形成している。

今の日本企業は、半導体製造や設計は弱いが、特定の工程に特化した半導体製造装置メーカーや化学用品メーカーは、その工程ではシェアが高いケースが多い。
結局、iPhone製造のサプライチェーンにおける日本企業の立ち位置と同じように、一品物の専門製造メーカーのみ生き残っている感じだ。

【6】さらに、日本の半導体メーカーは、歩溜まり向上に囚われすぎて、出荷スピード感がない。
日本の半導体メーカーは、半導体製造装置メーカーから納入された製造装置を生産ラインで稼働させて正常動作するまで検収を続けて、歩溜まりが上がるまで検収完了とせず、支払いを半年以上待たされたという。
つまり、納入して検収が終わるまでの半年間も、日本の半導体メーカーは半導体製造装置メーカーにお金を支払わなかったのだ。
こんな状況では、日本の半導体製造装置メーカーも資金繰りが悪くなり、やってられない。

一方、台湾や韓国の半導体メーカーは、半導体製造装置の納入時に7～8割は前払いし、生産ラインで実稼働させながら、歩溜まりを向上させて、どんどん売上を増やす施策を取った。
半導体製造装置は1台数億円もする装置なので、非常に高価であるが、彼らはそれらを使い捨てにしてでも、早く元を取るために、減価償却の期間を短くする施策を取ったわけだ。

この事象は、「電子立国は、なぜ凋落したか」の感想～日本の技術者は減価償却のコスト意識が低い: プログラマの思索に書いたし、Amazon.co.jp: 電子立国は、なぜ凋落したか : 西村 吉雄: 本に詳しく書かれている。

【7】さらに、日本の半導体メーカーは、半導体の設計製造に関わる優秀なエンジニアを大切にしなかった。
技術者ならば常に最先端の技術を追いかけたいのに、日本の半導体メーカーは、彼らのモチベーションを下げるような施策をやっていた。
なぜなのか？

たぶん、半導体製造の設備投資は非常に膨大であり、シリコンサイクルと言われる好況不況の波が激しいので、いつもリスクを取れるわけではない。
よって、日本の半導体メーカーは、自分たちの身の丈に会う程度で設備投資できる範囲内で、半導体事業をコントロールしたかったからではないか。
しかし、それは裏目になったと言えるだろう。

だから、「電子立国は、なぜ凋落したか」の感想～日本の技術者は減価償却のコスト意識が低い: プログラマの思索に書いたし、Amazon.co.jp: 電子立国は、なぜ凋落したか : 西村 吉雄: 本にもあるように、優秀な半導体エンジニアは、日本メーカーを退職して韓国、台湾企業へ転職したり、土日にアルバイト出張して、技術流出させていた。
そんな事象を見ると、日本の半導体メーカーはもちろん、日本の製造メーカーは、エンジニアを育てる環境を作っていないなと思ってしまう。

【6】半導体は、現代では全ての製造業の基盤だ。
AIブームにより、半導体の設計製造の重要性は非常に高まっている。
しかも、昨今の中国・米国の政治的対立を見れば、半導体の重要性はさらに高まっていると言えるだろう。

日本がどのような施策を取って挽回していくのか、探ってみたいと思う。

製造業のDXを推進する部門をITコーポレート部門に割り当てるとなぜ失敗するのか

製造業のDXを推進する部門はどこに置くべきなのか？

【参考】

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

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

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

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

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

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

【1】一般企業では、常識的には、IT情報システム部門やITコーポレート部門がDXを推進しているだろう。
しかし、製造業のDX推進部門にITコーポレート部門を割り当てると、事業部門から総スカンをくらったり、現場のサボタージュによって、たいてい上手く行かない。
製造業ではDX推進にITコーポレート部門に割り当てるとなぜ失敗するのだろうか？

製造業ではない業界、たとえば、小売業や金融業では、ITコーポレート部門がDX推進して上手くいくケースがある。
そのケースを見てみると、ECサイトに特化したり、QRコード決済やオンライン取引へ拡大したり、実際の事業活動を現場から離れてオンライン場へ展開したケースが多い気がする。
つまり、できるだけ、現場の作業から生み出される利益よりも、オンライン事業による利益を追求したケースだ。
最終的には、SaaSに近いビジネスモデルになるのではないか。

【2】一方、製造業では、製造設備や工場敷地を持つ現場に、設備投資して製品を生産し、付加価値を付けて製品を売り、利益を得る。
すなわち、実際の現場の作業こそが利益の源泉であり、現場から離れることは難しい。
いくらITで業務効率化したといっても、現場の手作業が効率化されるだけであって、現場の作業そのものがなくなるわけではない。
むしろ、現場の手作業にこそ差別化要因があるケースもあるだろう。
自動車、家電、医薬品、食品、石油精製、製鉄、造船などの製造業を見れば、どうしても現場の手作業から離れることは難しいように思える。

だから、製造業のDX推進部門は、ITコーポレート部門ではなく、事業部門そのものが推進すべきという考え方には一理あるように思う。

【3】しかし、AIの普及とロボットにAIを埋め込むことで、その考え方も変わるかもしれない。
製造業における工場の生産ラインをロボットでAI制御できる状態にしたり、生産ラインそのものをソフトウェアで簡単に入れ替えできる状態にできれば、全てをITで制御できることも可能だろう。
そうすれば、初めて、製造業のDX推進部門を事業部門からITコーポレート部門へ移すこともできるのではないか。

ビジネスモデルとIT戦略の関係、さらにはDX推進部門を含めた組織戦略については、再度考えてみたい。

SAFeはScrumと全く異なるアジャイル開発プロセスだ

SAFe経験者の話を聞いて、SAFeはScrumと全く異なるアジャイル開発プロセスだと初めて認識できた。
ラフなメモ書き。

【参考】
SAFe 5.0のエッセンス: スケールド・アジャイル・フレームワークによりビジネスアジリティーを達成する (00) | リチャード ナスター, D レフィングウェル |本 | 通販 | Amazon

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 | 榎本 明仁, 木村 卓央, 高江洲 睦, 榎本 明仁, 荒瀬 中人, 水野 正隆, 守田 憲司 |本 | 通販 | Amazon

SAFeRアジャイルな企業への変わり方　現場から経営まで貫く価値創造のためのフレームワーク入門 | 張嵐, 横田和彦 |本 | 通販 | Amazon

作る、試す、正す。　アジャイルなモノづくりのための全体戦略 | 市谷 聡啓 |本 | 通販 | Amazon

Amazon.co.jp: アジャイルソフトウェア要求 (Object Oriented SELECTION Classics) : Dean Leffingwell, オージス総研: 本

【1】SAFe勉強会に議論してすごく参考になった。SAFeはスクラムと全く異なるフレームワークと見たほうがいい感じだ。

僕がSAFeで一番知りたいことは、アジャイル開発における計画・実行・検査・適応のそれぞれのプロセスでは、誰が責任を持って意思決定しているのか、ということだ。
大規模アジャイルだからといっても、大規模プロジェクトと同じ構造を持つわけだから、メンバー全員が一同に集まることは時間的にも物理的にも難しくなる。
責任の分担と責任範囲、権限範囲の設計が必要になる。

誰がプログラムバックログ、スプリントバックログの優先順位、イテレーションの範囲を決めるのか？
誰がプログラムバックログのメンテナンス、リファインメントを担当するのか？
誰が、各チームが開発したモジュールを統合ビルド、デプロイ、デリバリーの責任を持つのか？
誰が、リリース計画の方向性を決めるのか？

僕は、誰が責任や意思決定を持つのか、が知りたかった。
実際、大規模プロジェクトになれば、どうしても階層的な組織構造が発生し、そこに意思決定や指揮命令系統の順序が決まる。
だからこそ、組織の4原則に基づき、統制範囲の原則、命令統一化の原則が組織構造に必要になり、指示命令する人と指示に従う人に分かれる。
その組織構造が大規模アジャイル組織では、どのように設定すべきなのか？

※大規模プロジェクトなので、プロダクトバックログと呼ばず、プログラムバックログとも呼ぶらしい。

【2】SAFeの肝は、2つあると思う。
1つ目は、アジャイルリリーストレインで複数のアジャイルチームのリリースを同期させること。
大規模アジャイルなので、複数のアジャイルチームで構成されるプロジェクトになる。
すると、複数のアジャイルチームが開発したコンポーネント複数個を統合ビルドする必要がある。
その統合ビルドを合わせるために、電車の発着時刻にたとえて、アジャイルリリーストレインと言うわけだ。

2つ目は、複数のアジャイルチーム同士でプロダクトオーナーだけのPOSync、スクラムマスターだけの打合せ、全メンバーが集まる打合せ、など数多くの打合せを設計すること。
確かに官僚的なアジャイルな印象を持った。

アジャイルリリーストレインを全チームに同期させるために、事前に全チームで計画を立てて、定期的にリリースする。3ヶ月後にふりかえりする、というプロセスみたいだ。
興味深いことは、統合ビルドしたモジュールのスプリントレビュー、スプリントデモ・スプリントレトロスペクティブというイベントは正式に作られていないらしい。
もちろん、アジャイルチーム内ではスプリントプラニング・レビュー・デモ・レトロスペクティブは行われる。
とはいえ、大規模プロジェクトであっても、全チームメンバー全員が集まることはできないので、各チームのリーダークラスが集まった打合せで、モジュールのデモ・レビュー・レトロスペクティブは行われているのだろう。

【3】小さなチームによる小さな開発が現代では主流であっても、LLMとかSaaSとか大規模なシステム開発は必ずある。
GAFAのように、ソフトウェア専門企業も数万人の従業員を抱える大規模な組織を形成している。

だからこそ、SAFeのように、既存の大規模かつ複雑な組織にアジャイル開発を導入する時に無意味な摩擦をできるだけ避けて、導入できるプロセス手法が欲しくなる。
その辺りを考えてみたい。