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

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

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

新装完全版 大国政治の悲劇 | ジョン・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: 日本/権力構造の謎 下 : カレル・ヴァン ウォルフレン, 勝, 篠原: 本

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

自動車業界における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になれば俺は関係ない、という立場になりやすい。

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

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推進部門を含めた組織戦略については、再度考えてみたい。

ビジネス書の名著はどれ？

山口周さんがお勧めのビジネス名著をリストアップされていたのでメモ。

元電通・BCGの山口周さんが、「ビジネス書の名著くらいは読んでおこ」とまとめたのがこのビジネス書マンダラ。多分野の基本は押さえておくに越したことはないので私も大賛成。組織戦略に携わる全マーケターにおすすめしたい。定着のコツは3回読むこと。 pic.twitter.com/qo6amm1ypC

— 彩花｜マーケ屋さん?? (@saika_affi) August 14, 2023

自分が読んだ経験のある本があったので、共感できた。

経済学をベースにした戦略論、組織論は好き。
人間の意志を超えた次元で、自然法則のように戦略も組織も縛られる。
そういう原則を抑えていれば、悪循環に陥る状態を防ぐことができるはず。
「マンキュー入門経済学」
「戦略の経済学」
「イノベーションのジレンマ」
「組織の経済学」
「組織は戦略に従う」

戦略/組織/人事と組織の経済学シリーズを読んでいる: プログラマの思索

組織論一般の理論を解説しているのが分かりやすかった。
「組織行動のマネジメント」

とても薄い本なのだが、アイデアがどうやって生まれるか解説してくれている。
「アイデアの作り方」

佐藤さんの解説記事がわかりやすい。
素早く考える能力、じっくり考える能力 : タイム・コンサルタントの日誌から

IT業界の営業戦略、プロセス導入ではキャズム理論が必須と思う。
パッケージ製品の営業だけでなく、新しい開発運用プロセスを導入する時もキャズムの法則に似たような事象が見られるから。
「キャズム」

キャズムの感想～イノベータ理論とホールプロダクト理論: プログラマの思索

伝記本として読んだ。
「スティーブ・ジョブズ I」「スティーブ・ジョブズ II」

岩波文庫なので文章は硬い。
「プロテスタンティズムの倫理と資本主義の精神」
「君主論」

自分が弱いのは意思決定、ゼネラルマネジメント、財務会計の分野かな。
全部読み切るには１０年ぐらいかかりそうな感じ。

営業は顧客の”購買代理人”である

「営業は顧客の”購買代理人”である」というツイートにハッと気付かされたのでメモ。

【参考】
きたざわ/リンゴ農家の経営改善/SUNABACO受講中さんはTwitterを使っています: 「「営業」がマーケティングの下位概念のような語られ方をされることがあるのだけど、どっこい営業の中でも飛びぬけて優秀なセールスは、マーケ的な思考を身に着けている。 【営業は顧客の”購買代理人”である】 野村証券で働いていたころ、トップセールスの方が言っていたことを今でも思い出す。」 / X

きたざわ/リンゴ農家の経営改善/SUNABACO受講中さんはTwitterを使っています: 「顧客自身すら気づいていない課題を見つけ出し、言語化し、「それを解決するためにはどんな商品が必要なのか？」を探し出し、提案する。セールス主導で「商品を買わせる」のではなく、顧客の隣に座って「一緒に解決策を探る」。僕が尊敬している素晴らしいセールスはこれをやってる。 #DX7th #SUNABACO」 / X

現代の営業プロセスは分業化されている～THE MODELの感想: プログラマの思索

ビジネスや営業のセンスが優れた人は、他の分野とは異なるセンスを持っているように思っている。
そのセンスとは何なのか、僕はずっと言語化できないでいた。

以前、「ロジカルシンキングの道具箱」という書籍を読んだ時「あらゆるビジネスは代行である」というフレーズを見つけてストックしていた。
その後、「ビジネスとは、顧客の業務を代行して対価を得ること」と自分なりに解釈して理解していた。

たとえば、昔なら地方の人は自分たちの裏庭の農地から野菜を作って自家消費していたが、都市住民なら自分で作らずにスーパーから提供される野菜を購入することで代用している。
つまり、スーパーはあらゆる食料を顧客に提供する人たちである。
あるいは、小売業者や金融業者は自分たちの業務システムを開発導入するために、ベンダにソフトウェア開発を委託する。
もっと視点を高くすれば、顧客の問題点や課題を解決するサービスをビジネスとして成り立たせて提供するならば、彼は顧客の問題解決の代理人になっている。

その発想から発展させれば、マーケティングに携わる人、顧客の代わりに、顧客の要望を最も叶えられそうな商品を購入する代理人と言えよう。
つまり、マーケティングとは、顧客の顕在化した欲望だけでなく、まだ潜在化されていない欲望も見抜いて、顧客を驚かせることもできるだろう。
そういう人が優れたマーケッターがと言われるのかもしれない。

第85回IT勉強宴会の感想～概念データモデルからビジネスモデルを構築すべきという考え方

土曜に開かれた第85回IT勉強宴会で、真野さんがデータモデリングの観点でエンタープライズシステム設計を講演されたのでオンラインで聞いた。
講演内容を知った前提で、感想をラフなメモ書き。

【参考】
概念モデルの効用を知ろう - connpass

概念モデルの効用を知ろう(第88回IT勉強宴会inZOOM/大阪サテライト) | ＩＴ勉強宴会blog

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

第62回IT勉強宴会のメモ～２人の方法論者によるデータモデリング激レア対談: プログラマの思索

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

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

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

【1】講演のメッセージは、DXで新規ビジネスを創出したいなら、概念データモデルを描くことから出発しよう、ということ。

メッセージの背景にある課題は、昨今、IOTやSaaSなどのSoE、既存の業務システムのSoRなど色んなところから数多くのデータがビジネスの副産物として簡単に入手して蓄積できるようになった
そのデータをAIや機械学習に食わせて分析するようにしたい。
しかし、色んな入り口から源泉データが発生し、途中で加工されて雪だるま式に派生データが積み重なり、複雑なトランザクションデータになっている。
そのためにそのデータを利活用しようとすると、派生データを取り除き、源泉データを区別して本来のデータを抽出する仕組みが必要だ、という問題意識。

akipiiさんはTwitterを使っています: 「我々が扱おうとしているのは、大半が加工・集約された派生データである。データがどこで加工されたのか、出処はどこなのかを探ることが重要。源泉データを突き止めるためにデータの系統図、データの変遷をたどるのが必要。イベントを時系列に並べてリソースを抽出する、ということかな？ #benkyoenkai」 / Twitter

そこで、SoE領域、SoR領域などの源泉データからどのように加工されてデータ連携基盤ハブにたどり着くのか、をデータモデルの観点から整理分類し、データクレンジングしたきれいなデータをデータ活用基盤へ連携してAIや機械学習に使ってもらうという仕組みにする。

akipiiさんはTwitterを使っています: 「源泉データがレガシーなSoRだったり、SaaSのSoEだったり、データレイクからだったり色々ある。そういう風にデータが時系列で加工されていく過程が見える。 #benkyoenkai」 / Twitter

講演では、製造業のサプライチェーン全てをデータモデル化し、コスト最適化の観点でシミュレーションとして使う事例が紹介されていた。

akipiiさんはTwitterを使っています: 「取引先や原材料、中間加工品の調達関係を描いたデータモデルが必要となる。制約条件は、取引先や原材料、中間加工品の調達関係を描いたデータモデルが必要となること。事業部間のデータ統合ができていることが前提。プロセスの再現だけではデジタルツインは実現できない。 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「デジタルツインでは、データ連携基盤Hubが重要。SoRが源泉データ。SoRからデータ連携基盤Hubを経てデータ活用基盤へデータが流れることになる。 #benkyoenkai」 / Twitter

僕の感覚では、雪だるま式に加工されて複雑化したトランザクションデータを時系列に並べて、マスタ（リソース）をトランザクション（イベント）と区別して抽出し、イベントやリソースをそれぞれ管理する仕組みを作る、というように捉えた。
実際の分析手法では、データモデルの正規化も使うし、クラスとインスタンスを区別することでクラスを抽出しロールとしてポリモルフィックに振る舞わせるように整理する。

講演では、顧客というクラスは、顧客、消費者、代理店、法人客というロールがある例が紹介されていた。

akipiiさんはTwitterを使っています: 「データモデリングは分類学である、とデータ総研の方は言っておられた、と。顧客、消費者、代理店、法人客などのロールを分類して、特化・汎化のER図で描く。IDEF1Xなのでオブジェクト指向設計と同じ。パーティモデルの概念と同じ。 #benkyoenkai」 / Twitter

【2】データモデルを作る目的は3つ。

akipiiさんはTwitterを使っています: 「データモデルを作る目的。3つある。ビジネス構成要素や業務ルールを把握する。保有するデータをAI機械学習の入力源にする。新規ITシステム構築に活用する。 #benkyoenkai」 / Twitter

【3】概念データモデルを描くメリットは何か？
メリットは2つある。

1つ目は、ビジネス構成要素を資源（リソース）と活動（イベント）の2種類に整理統合することによって、今後新たなビジネスモデルを生み出す材料として扱えること。

akipiiさんはTwitterを使っています: 「ビジネスの構成要素は資源（リソース）と活動（イベント）からなる。リソースは普通のマスタ、イベントは普通のトランザクションとみなせるね。羽生さんの本ではイベントに注目するとデータモデルを作りやすいと言っていたなあ。時系列に並べれば自然にDFDみたいなER図が描けるから #benkyoenkai」 / Twitter

データモデルのエンティティをイベントとリソースの2種類に整理するアイデアは、T字型ER（旧）や羽生さんのデータモデリング手法でも出てくる。
羽生さん本では、イベントは必ず日付があること、そこからイベントとリソースを区別しましょう、と言っていた。

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

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

ここで、イベントの数とリソースの数を数えて、もしイベントの数がリソースよりも少ないならば、リソースを組み合わせて新たなイベント（トランザクション）を生み出すことで、新たなビジネスモデルを考える切っ掛けの一つになりうる。

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

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索
（引用開始）
リソースの数よりもイベントの数が少ない場合、リソースの組合せで発生する可能性のある対照表というイベントは、その会社の業務として存在していない事実がある。
すなわち、新しい業務を生成することで、新規ビジネスを作り出す根拠になりうる。
（引用修了）

2つ目は、講演では、プロセス指向設計で使われる業務フロー図では、既存の業務フローで業務を入れ替え・削除したり、担当組織を入れ替える程度であって、BPRや業務改善しかできない。
DXで本来やりたい新規ビジネスモデルを生み出すことは、業務フロー図からでは発想できない弱点がある。

akipiiさんはTwitterを使っています: 「データモデルの活用例の１つはDXへの適用。経営者、業務部門、IT部門のコミュニケーションツールとして使う。ビジネス創出のためには業務フローアプローチではBPRや業務改善に留まり、新規ビジネス抽出につながらない。順序入れ替え、組織分担変更のレベルにすぎない #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「都度受注モデルからサブリスクプション契約モデルへビジネスを変更する。エンティティの置き換えだけでなく、新規イベント、新規リソースの追加が必要になることが明確に分かる。すると、新規イベント、新規リソースを保守管理する組織も必要になるだろう。 #benkyoenkai」 / Twitter

概念データモデルでAsIsモデルを描き、そこからエンティティを出し入れすることで、新規ビジネスモデルを生み出せるはず、と講演では説明されていた。

この部分については、なるほどと納得できる部分もあるが、本当にそうなのかという疑問も生じる。
確かに、講演で例に出た、AsIsの受注契約モデルとToBeのサブスクリプション契約モデルでは、業務フロー図でAsIsからToBeは出てこないだろう。
なぜなら、サブスクリプション契約モデルは誰も知らない初めてのビジネスモデルなので、業務フローをそもそも描くことすら難しい。
どんな業務が必要で、どの組織が業務のどのプロセスを担当して回すのか、そういう具体的な細かい粒度まで落とし込むのは至難の業だ。

しかし、AsIsの受注契約モデルとToBeのサブスクリプション契約モデルでは、概念データモデルを描いてみると構造はかなり違う。
契約エンティティなどの一部のエンティティは同じだが、AsIsモデルでリレーションシップや新たなエンティティをちょっとだけECRSでいじればToBeが出てくる、というのはちょっと無理があると思う。
実際、QAタイムでは、既存のAsIsモデルの概念データモデルでエンティティをECRSで出し入れする程度でToBeモデルが作れるのか、という質問もあった。

概念データモデルで新規ビジネスモデルを描く重要性は理解できるが、具体的なデータモデルを整合性が取れるように生み出すことは、別次元の作業なのだろうと思う。

【4】概念データモデルとオブジェクト指向設計、ドメイン駆動設計の違いは何なのか？

講演で紹介された概念データモデルはIDEF1Xで描かれていた。

ER図 (Entity-relatonship Diagram) | astah* 機能ガイド

IDEF1Xのエンティティ同士の関連線はクラス図と異なるが、多重度を書いたりロールを書いたりするのでクラス図に似ている。
オブジェクト指向設計やドメイン駆動設計が好きな人は、たぶん違和感なくIDEF1Xの概念データモデルを理解できるだろうと思う。

akipiiさんはTwitterを使っています: 「受注出荷のデータモデルをIDEF1XのER図、DFDで描かれた事例。クラス図に読み替えやすい。 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「受注出荷モデルの例。受注と出荷の関係が1対1、1対多では何が違うか？受注単位の出荷、一括受注して分割出荷。IDEF1XのER図はクラス図に似てるのでドメイン駆動設計が好きな人は読みやすいと思う　 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「抽象化したエンティティはロール概念を用いて関連付けることができる。真野さんが説明されるデータモデルはクラス図にそのまま置き換えられるね。 #benkyoenkai」 / Twitter

データモデリングがなかなか普及しない原因の一つは、ドメイン駆動設計が好きな人はデータモデルを読み解きにくい現象が多いのではないか、と推測するので、この辺りは1つのきっかけになるかもしれない。

【4】渡辺さん式データモデルと真野さんの講演で出てくる概念データモデルの違いは何なのか？

真野さんの講演で出てくるデータモデルは概念モデルレベルなので、エンティティ名しか書かれていない例が多い。
一方、渡辺さん式データモデルは、すべての属性を書き出し、関係従属性の意図まで明確に表していて、実際のデータの例も書いているので、より具体的だ。
実装モデルそのものと言っていい。

だから、渡辺さん式データモデルではテーブル仕様書をそのまま出力できるレベルであり、Railsのようなフレームワークを使えばすぐにCRUD画面も作れる。
つまり、どんな画面や帳票が必要で、どんな業務や画面操作でデータが生成されて更新されていくか、というレベルまで全て把握できている。
だから、ローコード開発やノーコード開発と相性がいい。
たぶん、SalesforceやKintoneのようなローコード開発ツールと相性が良いと思う。

akipiiさんはTwitterを使っています: 「真野さんのデータモデルはIDEF1Xで描かれてるので、渡辺さんのER図とは見た目は違う。個人的には、渡辺さんは関係従属性の意図まで明確にしインスタンスも例示するので、より実装モデルに近いと思う。だからローコード開発と相性がいい。 #benkyoenkai」 / Twitter

しかし、関数従属性やキーの種類の理解が深くないと、データモデルを読み解くのは難しいと思う。

再入門：「正規化崩し」としてのサロゲートキー - connpass

（引用開始）
・候補キー(candidate key)：レコードを一意に特定するキー。１テーブルに複数存在することがある
・主キー(primary key)：代表として定めた候補キー。項目値の変更は許されない
・単独主キー(single primary key)：１項目で出来ている主キー
・複合主キー(composite primary key)：２つ以上の項目で出来ている主キー
・自然キー(natural key)：業務上意識されている候補キー。単独主キーか複合主キーかは問わない
・サロゲートキー(surrogate key)：業務上意識されていない単独主キー。代理キーともいう
（引用修了）

サロゲート単独主キー vs 複合主キーの話、予習編 - たなかこういちの開発ノート

アーキテクトは、データモデルから業務フロー図、画面帳票、組織構成までイメージできる能力を求められる。
たとえば、渡辺さんの本を読めば、ほとんどデータモデルばかりでDFDは少しだけしか紹介されていないので、実際にどんな業務フローが必要になってくるのか、は自力で考えなければならない。
渡辺さんの本に出てくるデータモデルでは、複合主キーや外部キー、特に2次識別子（Alternative Key）が巧妙に使われていて、業務ルールや制約条件を表しているので、注意深く読まなければ割と読み落としやすい。

【5】概念データモデルはどの工程で使われて、どんな役割の人が担当すべきなのか？

講演では明示的な説明がなかったように思うが、常識で考えると、企画フェーズや要件定義で概念データモデルが作られる。
担当者はアーキテクトのレベルの人になるだろう。

作られた概念データモデルの粒度は、講演で紹介された粒度ならば、エンティティ名だけでかなり曖昧。
渡辺さん式データモデルの粒度なら、論理モデルまで落とし込む必要がある。
その場合、そこからすぐに実装モデルに置き換えられるから、ローコード開発ツールを使うことを前提にしているだろう

最近はデータモデリングから離れていたので、講演を聞いてすごくワクワクしながら聞いていた。
改めて、データモデリングのテクニックを自分なりに整理してみたいと思う。

令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた

令和4年度春期試験のITストラテジスト試験第4問について、問題文の構造をastahで図式化してみた。
自分のメモ用に残しておく。

【参考】
ITストラテジスト試験 | 試験情報 | IPA 独立行政法人 情報処理推進機構

令和4年度春期試験のITストラテジスト試験

【1】ストラテジスト試験第4問は必ず組込みソフトウェア開発企業のテーマになる。
今回のテーマは「電力自由化や再生エネルギー切り替えの環境変化に対し、電力会社の子会社が局地的な気象予測システムを開発し、親会社と連携することで新規顧客開拓を狙う」事例。

SDGｓや二酸化炭素排出削減、環境意識の流れ、EV化などの最近の事情を考えると、よく考えられたテーマと思う。

【2】ストラテジスト試験第4問の特徴はいくつかある。

【2-1】１つ目は、登場人物が非常に多いこと。
今回の事例を３C分析で書いてみるとすごくよく分かる。

【2-2】特に、協力者が重要な要素になる。
なぜならば、組込みソフトウェア開発企業は特定のアプリケーションソフトウェア開発には強いが、ハードウェア製品の開発は弱かったり、GISや気象データ、特殊技術を持つソフトウェア企業と連携する必要があるからだ。
自社にない経営資源は、外部企業と提携することで解決するためだ。

この事例では、GISデータを持つ企業、気象測器を製品販売する企業が協力者になる。

【2-3】2つ目は、脅威として法規制や政治情勢、社会ニーズなどのPEST分析が必要になること。
特に、法規制が多い。
人命にかかわるソフトウェアやハードウェアであればなおさらだ。
法規制の要件により、ハードウェア機器もソフトウェアも制限を受けるし、その分、コストがかかったり、ソフトウェア開発の難易度が上がる。

一般に、法規制は国が定めるので、政府や国という登場人物が出たら、法規制に必ず関わることになる。

【2-4】3つ目は、事業戦略の方向性は、新規顧客開拓が基本である点だ。
一般に、今までの既存顧客だけでは売上が減少気味だったり、SSGｓなどの環境変化で新たなニーズが生まれている背景があるから、新たな市場へ乗り出さないといけない、という方向性になりやすい。

では、新規顧客開拓に必要な経営資源は何か？
一般には、地域に根ざした営業力、特定の分野に特化した技術力があげられる。
技術力の例には、ソフトウェア開発力もあるし、保守サービス、AIやハードに特化したソフトウェア技術などがある。

すると成長戦略として、今までに培った技術力で新製品や新サービスを開発し、営業力を活かして新たなニーズを持つ顧客へ販売する、という方向性になる。
つまり、かなり積極的な経営戦略になるだろうと思う。

【3】今回の事例をSWOT分析してみたモデルを描いてみた。
モデルを描いて気づいた点は、いくつかある。

【3-1】1つ目は、協力企業と連携する箇所は必ずシステムの機能追加が必要になること。
例えば、気象予測システムに「電力の融通量を計算する情報システム」と外部連携する機能が必要になる。
この外部連携機能により、他の電力会社に局地的な気象情報に基づく情報を連携し、電力の大きな変動に対応して、全国規模の効率化を図ることになる。

たとえば、気象予測システムにGISデータを取り込む機能が必要になる。
局所的な気象は土地の起伏や構成要素に密接に関係するので、GISと連動させる必要があるからだ。
よって、GISの地図データを扱う企業と連携する必要がある。

まあ考えてみれば、協力企業と情報連携するわけだから、外部連携機能は必須になるのは当たり前。

【3-2】2つ目は、政府の方針や法規制にかかわる要件は、システムの機能に埋め込まれていること。
たとえば、気象業務法により、定められた人数以上の気象予報士を雇用する必要がある。
よって、気象予測システムでAI分析したデータは、必ず気象予報士がチェックして、顧客へ広報するという業務がシステムに埋め込まれることになる。

たとえば、政府は電力自由化を促進する必要があり、電力不足を防ぐ必要があるので、電力会社間で電力を融通してほしい思惑がある。
よって、気象予測システムと電力会社が持つ電力量算出システムが連携して対応する必要がある。

つまり、法規制や政府方針に関わる要件は、システムのどの機能で実現するのか、を必ずチェックしておく必要がある。

【3-3】3つ目は、課題の解決や経営資源がシステムの機能と密接に関係していること。
たとえば、局地気象予測システムでは、気象測器を高密度に多数設置する必要があるので通信手段が必要になる。
そこで、親会社の電力会社が持つ通信インフラである有線・無線ネットワークを利用することで解決する。
つまり、経営資源を活用することで、システムに足りない機能や環境を補充することになる。

たとえば、局地気象予測システムでは、気象測器は修理対応や交換を伴う定期保守が必要になる。
しかし、観測成果を発表するには、気象測器は基本は検定合格品を使用しなければならないが、高価であり、製品販売する企業も少ない。
そこで、観測成果の発表を止める代わりに、検定合格しない安めの製品を利用すること、親会社D社の強みである災害時を想定した保守体制を活用して、検定合格しない製品販売のZ社と提携し、予備機の追加や製品修理だけの保守を契約することで対応する。
つまり、投資効果のバランスを取っているわけだ。

【4】ストラテジストの他の問題もastahでモデル化してみると、販路開拓を目指す新規事業とそれを実現するシステム要件がうまく関連していることがよく分かって面白い。
ベンチャー企業も、新規事業を起こしたい大企業も、こういう発想でシステムを開発しようとしているのだろう。
他にも試してみたいと思う。