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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第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でモデル化してみると、販路開拓を目指す新規事業とそれを実現するシステム要件がうまく関連していることがよく分かって面白い。
ベンチャー企業も、新規事業を起こしたい大企業も、こういう発想でシステムを開発しようとしているのだろう。
他にも試してみたいと思う。

経営戦略とIT戦略をつなぐ鍵は何なのか

経営戦略とIT戦略をつなぐ鍵は何なのか？
考えたことをラフなメモ書き。

【参考】
ITの地殻変動はどこで起きているのか？～今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

【資格】ＩＴストラテジスト試験対策　この時期にすること（ＢＳＣ） | 三好康之オフィシャルブログ　「自分らしい働き方」Powered by Ameba

【1】外部環境をPEST分析や5Fsで分析し、内部環境をVRIO分析やバリューチェーンで分析できたとしよう。
そして、経営目標が定まり、経営方針として経営戦略が立てられたとしよう。
経営者としては、こういう経営目標を実現するためにこんな経営戦略を実現するんだ、とスローガンをあげる。
では、そこからどうやって、どんなシステムが必要でどんな順番でシステムを構築していくのか？

ITアーキテクトが、経営者から提示された経営戦略を元に、これだけの数のシステムの開発や改修が必要です、と言っても、投資効果がなければ経営者は納得してくれない。
数千万円から数億円、数十億円のシステム開発に投資するなら、どれだけの投資効果があるのか、その説明の根拠が欲しいのだ。

【2】では、経営目標や経営戦略からIT戦略までの枠組みはどんな体系図になるのか？
経営目標を達成するために、こういう戦略が必要で、こういうITシステムが必要なのです、するとこれだけの投資額が必要でこれだけのROIが出てきます、という因果関係を表す流れを説明したいのだ。

経営戦略からIT戦略、個別システム開発までの全体の枠組みはこんな感じになるだろう。

経営目標 --> CSFに基づいた経営戦略 --> 業務戦略 --> 全体システム化計画 --> 個別システム化計画 --> 個別プロジェクト計画

一般に、経営戦略は中長期の観点で作られる場合が多いので、3～5年ほどの期間で組み立てられるだろう。
そういう経営戦略の元に、事業にある各業務プロセスが新規で立ち上がったり、業務の効率化を目指す活動が実行される。
そんな業務を支えるためにITシステム、ITサービスがあるから、それらは各事業を支える裏方のシステムが多くなり、一般に基幹系業務システムが多いだろう。
たとえば、販売管理、発注管理、生産管理、会計、債権管理、顧客管理など。
もちろん、顧客を獲得するためのエンゲージメントに注力したシステムやサービス、たとえばECサイトなどもあるだろうが、それと同じくらいの規模のバックエンドのシステムも必要になるし、そちらのシステムの方がより巨大になりやすいからだ。

【3】こういう体系図はバランス・スコアカードで表現できるだろう。
財務＞顧客＞内部ビジネス・内部プロセス＞組織や人の学習と成長　の観点でレイヤ化できるだろう。

すると、各レイヤは業績測定指標というKPIでモニタリングできることになるので、下位のレイヤのKPIが良いから上位のレイヤのKPIも良くなって、最終的に売上向上になり、利益向上につながります、という因果関係で説明できることになる。

つまり、経営戦略とIT戦略をつなぐ鍵は、こういう業務測定指標の因果関係にあるのではないか、と思う。
各レイヤの業務測定指標であるKPIが階層化されていて、下位のレイヤの業務のKPIを上げることで、最終的にKGIという経営目標が達成できる、という流れになるだろう。

【4】では、財務・顧客・業務・成長の観点でどんなKPIがあって、どんな因果関係で結ばれているのか？

財務の観点では、一般的に経営指標だろう。
ROE、ROA、収益性、効率性、安全性など。

顧客の観点では、一般にマーケティング指標だろう。
新規顧客数、RFM分析の指標、顧客満足度、コンタクト件数など。

業務の観点では、業務の効率性を示す指標だけでなく業務を支えるITの観点の指標も含まれるだろう。
一般にはQCDの観点が多いだろう。
品質なら、不良品率、部溜率、稼働率、ライン停止時間など。
コストなら、製品別原価、作業工数、在庫費用など。
納期なら、サイクルタイム、リードタイム、納期遵守率など。
他に、研究開発費、アフターサービスの問い合わせ対応回数など。

学習と成長の観点では、従業員の能力向上やナレッジ蓄積に関する内容が多いだろう。
従業員満足度、従業員定着数、特許数、など。

これらのKPIを組み合わせると例えば、利益向上であれば、下位レイヤーのKPIに分解できるだろう。

利益＝売上ー原価
売上＝新規顧客数ｘ販売単価
原価＝時間単価ｘ作業工数
新規顧客数∝説明会の参加回数ｘ説明会に参加した新規顧客数ｘ営業訪問率ｘ見積依頼率ｘ成約率

説明会の参加回数、説明会に参加した新規顧客数、営業訪問率、見積依頼率、成約率というKPIをリアルタイムに測定するために、CRMのシステムが必要であると判断し、CRMを導入・開発・運用するコストがこれだけかかるが、これだけの売上が見込めるので投資効果があります、という説明の流れになるだろう。

こういう話を考えると、ECサイトで商品購入に至る導線作りと全く同じ。
たとえば、AARRRという指標でECサイトの購入率を分解して、ECサイトの導線となる画面設計を考えるやり方と同じ。

AARRRとは?サービスを成長させるための基本戦略【テンプレート付】｜ferret

AARRR（アー）モデルを活用する上で知っておきたいこと | Urumo！

【5】今の自分が経営戦略とIT戦略をつなぐロジックを考えている時、相手を説得できるだけのロジックがなかなか作れずに悩んでいた。
悩んでいた原因の一つは、経営戦略と業務を支えるITシステムの計画の間で、階層化されたKPIによって最終的に経営目標が実現されるから投資効果がある、という説明ができなかったためだろうと思ってる。
自分なりに考えているけれど、思いつきで理由を作ってそれをつなげているから、色んな突っ込みがあるとボロボロと漏れが出てしまうという感じだった。

KPIというツリー構造で考えれば、各指標は各要素に因数分解されて、各要素は下位レイヤーのKPIになるからさらに因数分解されていく、という形式になる。
つまり、経営目標KGIというトップから、下位レイヤのKPIまで数式として分解されるので、一つのロジックツリーという構造で一覧できる。
そういうロジックツリーの構造があるからこそ、KPIを繋いで説明することは数式をなぞるように論理的に説明することと同一になるので、相手も説得しやすくなる、という流れかな。

KPIツリーという考え方はおそらく、フェルミ推定の発想と同じ。
ゴールを達成するために、ゴールを測定するKGIを設定し、それを公式を使って因数分解し、各要素の数値は推定して仮説を立てて、KGIを推定するという流れと同じ。

おそらく既に理解できている人、実践できている人にとってはとても当たり前の考え方なのだろうが、現場で色んな経営課題に対して解決策を提示したり、経営戦略に基づくビジネスモデルを提案したりする時、こういう手法を持っておかないと短時間にそこそこ高品質な提案や仮説が出てこないのだろうと思う。