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

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