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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関西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

astahでPJ管理もプロセス設計もアイデア発想も全て表現したい

astahでPJ管理もプロセス設計もアイデア発想も全て表現したい。
つまり、astahで描けるUML、データモデリング、マインドマップを駆使して、仕事のすべての場面でアイデア発想、アイデア収束、展開するパワポ資料のアウトラインまで作成したい。

【参考】
astah システム設計、ソフトウェア開発支援ツール | astah*

ダイアグラム思考 次世代型リーダーは図解でチームを動かす | 髙野 雄一

第4回astah関西勉強会の感想 #astahkansai｜akipii

astah*の因果ループプラグインがいいね: プログラマの思索

astahで使える無償プラグイン一覧

astah*のデータをiPadで持ち運ぶ | 雲の巣

【1】なぜ、astahをそんなに使いたいのか？

1つ目は、単純に僕はastahが好きだから。
PlantUML、Mermaidも良いが、直感的に絵を描きたい時、astahの方が手に馴染む。
EnterpriseArchitectも良いツールだし、多機能なので何でも描けるが、僕の感覚に合ってなかった。

2つ目は、モヤモヤした状況をいろんな観点で図示して、構造を見える化したいからだ。
システムやソースコードの分析だけではない。

日々の業務では、定常業務の手順や業務フローをアクティビティ図やDFDで描けば、誰に何をどのタイミングで渡せばいいのか、理解できる。

PJ管理では、PJのゴールや成功条件に対し、中間目標には何があって、それを解決する手段は何なのか、紐づけて可視化したい。
ステークホルダー分析では、アクターとなるステークホルダーと要求事項、期待値を紐づけて、どんなコミュニケーションを実施すればいいのか、色んな観点で案を探るために、ユースケース図でイメージしたい。
発生した問題に対し、その事象にはどんな要因が原因と結果の流れでつながっていて、因果ループ図のようなシステマティックな構造で発生している構造を可視化し、本来の真因やボトルくネックを特定することで、効果的な対策を実施したい。
展開するパワポ資料を作る時、いきなり書き出すのではなく、アウトラインや目次の構成を考えるために、メッセージやアイデアを発散して収集する。意味ある因果関係で整理するために、マインドマップを使いたい。

つまり、仕事のあらゆる場面で、astahを使うことで手順の可視化、計画の可視化、問題の可視化に使いたいのだ。

【2】では、astahをどの場面でどんな技法を使うと有効なのか、考えてみたい。

UML、データモデリングは一通り使える。

【2-1】個人的に好きなツールは、ユースケース図に因果ループ図の構造を把握してくれるプラグインだ。
因果ループ図を使う場面は、PJ管理上でQCDに関する問題が発生した時に、複数の事象や複数の原因がどのように因果関係でつながっているかを可視化して、ボトルネック特定や対策策定に役立つときだ。

astah*の因果ループプラグインがいいね: プログラマの思索

【2-2】最近、アクティビティ図にInput、Outputをオブジェクトとして追加し、DFDぽく表現するやり方をやってる。
一連の業務フローに帳票、システムへの入出力となる情報、メール送信などを入れると、理解しやすくなる。
単純なDFDは順序が表現されないので、その弱点を解決できるのもメリットだ。

【2-3】最近、チームの状態やチームの能力成熟度を状態遷移図で表現するやり方をやってる。
たとえば、ファシリテーションなら、会議の中で、チーム内の議論の状態が、共有→発想→収束→展開のように流れるので、そのまま状態遷移図で表現してしまう。
すると、どんなトリガーで次の状態に移るのか、条件を考える気づきがある。

この考えを進めると、CMMIの能力成熟度モデル5段階、マズローの欲求5段階説も同様に、状態遷移図で表せる。
1段上の能力に上がるにはどんなトリガーや条件を満たす必要があるのか、を表現できるわけだ。

【2-4】ユースケース図のうち、ロバストネス図の機能を使って、DFDみたいに書く時がある。
デマルコ記法のDFDよりもロバストネス図の方が、クラス図やシーケンス図にも連動しやすいので便利だ。

【2-5】マトリクスで4象限を表現したい時、アクティビティ図でレーンで枠を囲って、無理やり表現している。
迷うのは、4象限に配置した概念をアクティビティにするか、ノートにするかだ。
長い文字列で表現するときはノートにせざるを得ないが、アクティビティの方がそれらしく見えやすいので悩んでる。

【2-6】ユースケース図をアクティビティ図の代わりに業務フローで表す手段も試してる。
ユースケース図で業務の流れを表現するメリットは、アクターやInOutのオブジェクトをクラスやロバストネス図のオブジェクトなど、色んなツールで多彩に表現できることだ。
そもそも、アクティビティ図も本来は、一つのアクティビティがユースケースになり、そこからクラス図やシーケンス図へ落とされていくので、ユースケース図の方が詳細化する他の図に連動させやすいメリットがある。

【2-7】今度試したいのは、タイミング図だ。
たとえば、時系列で推移や変動をグラフで表現したい時がある。
タイミング図では、時系列に状態を表現できる機能があるので、時系列グラフをうまく表現できないか、考えている。

【2-8】マインドマップはアイデア発散に使える。
僕は、資料構成のアウトライン作成で使って、そこからパワポ出力する機能を愛用してる。
他に、たくさんの図を残していて、それらを整理するために、マインドマップにドラッグ・アンド・ドロップしてリンク集みたいに使っている。
マインドマップ上で、リンクされた図をカテゴリすればさらに見やすくなる。

【2-9】ER図にようやくパッケージ構造の機能が追加されたので、フォルダ分けすることで、複数のER図を作りやすくなった。
DBリバース、DBエクスポートプラグインを使えば、ExcelのDB定義書と同期できるので便利。

【2-9】astahの図を全てHTML出力するプラグインも入れた。
astahの100個以上の図を貯めているので、HTMLで出力してiPhoneやiPadに入れて、暇な時に読んでいる。
自分が書いた図なのに、後で読み返すと気づきがあってすごくいい。

DiagramToHTMLプラグイン | Astah

astah*のデータをiPadで持ち運ぶ | 雲の巣

【3】結論は、astahで全て書ききれると思う。

書きづらい場面は、マトリクスや表形式で詳細にまとめたい時、パワポ資料に描くポンチ絵だろう。
その辺りもまた解決方法を考えてみたいと思う。

astahでPJ管理もプロセス設計もアイデア発想も全て表現することで、自分のアイデアも手順も全て可視化したい。
そうすれば誰にでも説明できるし、自分の中でストーリーも作りやすい。
もっともっと試してみたい。

astahでPJ管理もプロセス設計もアイデア発想も全て表現したい

アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか？～Software Processes are Software, Too（ソフトウェアプロセスもまたソフトウェアである）

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」をアジャイルアーキテクトさんや他の方と輪読していたときの感想をメモ。

【1】「ソフトウェアシステムアーキテクチャ構築の原理 第2版」は既に絶版なのだが、内容は良い本だ。
アーキテクチャ設計のプロセスを現代風にうまく表現してくれている。
今のマイクロサービス設計にも当てはめることもできるだろう。

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」に出てくる用語は、図4-3.コンテクストにおけるパースペクティブを見ればいい。

その時のビューは、図15-1.ビュー間の関係　の観点で整理される。

【2】「ソフトウェアシステムアーキテクチャ構築の原理 第2版」をアジャイルアーキテクトさんや他の方と輪読していたときに一つの疑問があった。

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」では、アーキテクチャを定義し、設計し、実装し、評価する一連のプロセスが、図7-3.アーキテクチャ定義の詳細で定義されている。
そのプロセスの中に、「適切なアーキテクチャスタイルを識別する」プロセスでは、過去のアーキテクチャパターンを参照するという記述があり、腑に落ちていなかった。
アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか。
アーキテクチャ設計はもっと高尚なプロセスではないのか、という認識が強すぎた。

実際のシステム開発では、ユーザの要求を元に、業務やシステムの要件を定義し、スケジュールやコスト、品質の観点からアーキテクチャの候補を複数から選定して基盤を決定する。
そこから具体的な設計、実装に入っていく。
今なら、業務要件や機能要件を定義する中で、非機能要件を満たせるようなインフラ基盤やネットワーク基盤、開発フレームワークを選定するだろう。
サーバはクラウド、クライアントはPCやスマホなどを基盤に選定するだろう。

そういう設計を具体的に行うときに、過去のアーキテクチャパターンを参照するときもあるが、新しい技術を導入する時は過去の事例がないので、苦労するし、失敗しやすい。
その疑問を解決できていない気がしていた。

【3】この疑問について、先輩と議論して気づいたことがある。

アーキテクチャ設計について、アーキテクトの経験や会社の過去事例に既に実績があるならば、いきなりアーキテクチャ設計を実装するのではなく、要件を基に、過去に成功して実現性の高いアーキテクチャパターンを採用することで実装する方針を決めるのは自然な流れと理解した。
その時に、プロセスの実行（プロセスクラスをインスタンス化して実行）においても、同様に過去のプロジェクトで成功して実績のあるプロセス事例を参照して、プロセスを設計するのは自然な考え方ではないか、と気づいた。

一方、新しい技術を取り入れてアーキテクチャ設計する時、社外の専門家である外部ベンダーに参画してもらい、その知見を活かしてもらうわけだが、そのやり方も実現性の高いアーキテクチャパターンを知っている専門家を利用しているわけだ。

この辺りをモデル化してみた。

「当初の案」では、プロセスパターンクラスをアーキテクチャごとのタイプみたいなパターンクラスとみなし、プロセスクラスとしてプロセスのテンプレートを生成し、各プロジェクトではプロセスクラスのテンプレートををカスタマイズして実行するイメージだった。

しかし、要求とパターンの整合性を取る必要がある時に、要求そのものにパターンを抽出する基準が暗黙的に既に埋め込まれている。
実際、要求に沿ってシステムとして実現できるアーキテクチャはこれだ、と選定するときに、要求を制約事項とみなすアーキテクチャを過去のベストプラクティスを元に選定しているからだ。
つまり、アーキテクチャ設計としてアーキテクチャを選定するときに何らかの選定基準は暗黙的に埋め込まれている。

その暗黙的な基準こそが、パターンでありイディオムであるわけだ。
アーキテクトは、自身の脳みその中に、多数のパターンカタログ、イディオムカタログを暗黙的に保持していて、それを基準に当てはめている。

そこで、「田中さん案を元に再構成した案」で書き直してみると、プロセスパターンクラスをインスタンス化したものがプロセス記述書になる。
これはアナリシスパターンの抽象・具象パターンに相当するだろう。
そのプロセス記述書は、アーキテクチャ設計プロセスのテンプレートであり、どのプロジェクトでも使えるテンプレートになっている。
このプロセス、手順に従えば、アーキテクチャ設計ができますよ、という手順書になっている。
そのプロセス記述書は単なる手順書ではなく、過去のベストプラクティスが盛り込まれて、ソフトウェア開発が成功するような知見が盛り込まれているわけだ。

このプロセス記述書を各プロジェクトに当てはめて、必要であればカスタマイズして実装して、プロジェクトを実行していくことになる。

【4】そんなことを考えると、まだうまく表現できていないかもしれないが、ソフトウェア設計、ソフトウェア開発そのものも一つのソフトウェアのような気がしてくる。

そんな論文「Software Processes are Software, Too」は1980年代に既に提唱されているよ、と先輩から教えてもらった。

Software Processes are Software, Too

主張は「ソフトウェア開発プロセスは、プロセス記述書というクラスをインスタンス化したものである」と理解したがもう一つ重要な観点があると思う。
それは「ソフトウェアを再利用して効率化するやり方と同様に、ソフトウェア開発プロセスも再利用できるはずだし、それがパターンやイディオムになるはず」だという考え方だと思う。
つまり、「ソフトウェアシステムアーキテクチャ構築の原理 第2版」本で「適切なアーキテクチャスタイルを識別する」ときにパターンを参照することと同義だと理解している。

この辺りはもう少し整理してみたい。

「システムアーキテクチャ構築の原理」の感想part2～非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する

「システムアーキテクチャ構築の原理」を読んでる。
平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」を読み直して、理解が深まった。
平鍋さんの記事に触発されたので、理解できたことをラフなメモ。
間違っていたら後で直す。

【参考】
『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

「システムアーキテクチャ構築の原理」の感想: プログラマの思索

【1】「システムアーキテクチャ構築の原理」を読んでいて分かりにくかったことは、ビュー、ビューポイント、パースペクティブという概念が出てきて混乱したこと。
これらの言葉は何を表しているのか、具体的に理解できていなかった。

平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」では、概念モデルでまとめてくれているので理解しやすかった。

@hiranabe さん記事を理解したうえで「ビューとビューポイントの違いは何？」の意見に対する私なりの回答は以下の通り。 ・ビュー＝ステークホルダーの横断的関心事をシステム観点で記述した内容。 ・ビューポイント＝横断的関心事。ユーザ観点。 ・パースペクティブ＝主に非機能要求。システム観点。

— akipii (@akipii) May 6, 2024

【2】図4-3.コンテクストにおけるパースペクティブが「システムアーキテクチャ構築の原理」のメッセージを全て表している。
平鍋さんの解説が分かりやすい。

（引用抜粋　開始）
「非機能要件がシステムのアーキテクチャに影響を与える」という観点を本書は、この言説を徹底的に解説したもの。

非機能要件に限らず、横断的な視点を「パースペクティブ」として捉えている

実際にアーキテクチャを記述しようとすると、１つの文書ではとっても複雑で巨大な説明になる。「ステークホルダー」の「関心事」毎に分割するために、「ビュー」と「ビューポイント」を導入する

「パースペクティブ」は、従来の言葉で近いものとして「非機能要求」「横断的関心事」がある。本書ではこの「ビューポイント」と「パースペクティブ」のカタログを作っています。
（引用抜粋　開始）

【3】図15-1.ビュー間の関係では、ビューを開発や運用の観点で分解している。
この図は、システム開発とシステム保守で分割すれば理解しやすい。
今ならDevOpsだから、開発も運用も一体化しているだろう。

【4】図7-3.アーキテクチャ定義のプロセスは、「システムアーキテクチャ構築の原理」が提唱している、アーキテクチャを定義し評価するプロセス。
アーキテクチャ設計の中で、特に非機能要件を含めた横断的関心事をいかにアーキテクチャに盛り込むのか、を考えた一連のプロセスになる。
プロセスの流れは、アーキテクチャ要素や横断的関心事を段階的詳細化して組み立てたあとにアーキテクチャを評価するので、違和感はない。

【5】「システムアーキテクチャ構築の原理」では上記3つの図が本書のメッセージになると思う。
本書のやり方を各システム、各案件にテーラリングして設計、実装する必要があるから、本書は、アーキテクチャ設計のメタ概念、メタプロセスの解説書みたいな感触を持っている。

【6】「システムアーキテクチャ構築の原理」の副題「ITアーキテクトが持つべき3つの思考」が指す「3つ」とは、「ステークホルダー」「ビューポイント」「パースペクティブ」と最初に書かれている。

その意図は、ステークホルダーの横断的関心事、特に非機能要求をユーザ観点のビューポイント、システム観点のパースペクティブで分解して組み立てて、トレードオフを考慮したアーキテクチャを設計すること、を意味していると考える。

他にも気づいた他内容があれば書いていく。

「システムアーキテクチャ構築の原理」の感想

「システムアーキテクチャ構築の原理」を読む機会があったので感想をラフなメモ書き。

【参考】
「システムアーキテクチャ構築の原理」の感想part2～非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する: プログラマの思索

『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

アーキテクチャ構築の原理 第2版を読んだ - 勘と経験と読経

【0】「システムアーキテクチャ構築の原理」は最新版の第２版もある。
僕は確か、デブサミ2010の時に会場で購入した記憶があり、第１版を持っている。
その時から興味のある部分だけかいつまんで読んでいたので、全部を通して読んでいなかったので、輪読するのは良かった。

「システムアーキテクチャ構築の原理」を読んで興味を持った部分はいくつかある。

【1】１つ目は、2008年の初版でありながら、マイクロサービスやサービス志向のアーキテクチャ設計を目指していること。
機能的ビュー、情報ビュー、並行性ビューなどのソフトウェア構造のアーキテクチャ設計の観点は、業務システム設計と微妙に違うな、と感じていたが、実際はクラウドベースのマイクロサービス設計を目指しているのだろう。
実際、並行性ビューでは、昔のバッチ処理設計よりもイベント駆動の並列性アーキテクチャに力点をおいている。
たとえば、REST APIやAdapter・Facadeパターンのようなアーキテクチャ設計を念頭に置いて実装しようとしている。

そう考えると、マイクロサービス設計における新たな設計思想はまだ含まれておらず、荒削りな内容を感じるが、文章の背後にある著者の思い、こういうことを言いたいのではないか、を推測しながら読むと理解できるのでは、と感じる。

【2】2つ目は、ATAMという非機能要件の設計技法を解説してくれている点だ。

データベースコンサルタントのノウハウちょい見せ アーキテクチャをレビューする方法(ATAM)

ATAMはシナリオベースで非機能要件を評価する設計技法。
僕の理解では、システムのアーキテクチャの特に非機能要件を品質特性ごとに分類し詳細化して、それをシナリオに落とす。
そのシナリオを優先度付けして、シナリオベースにアーキテクチャを評価して整合性を取ったり、システム設計を明確化する。

利点は、非機能要件をアーキテクチャとして評価する技法として、シナリオベースを用いているので、アジャイル開発をやっている人には取り組みやすいと思う。
デメリットは、CMMIを作ったSEIがATAMを提唱しているので、重たいプロセスになりがちで、テーラリングが必須であり、プロマネによってばらつきが出やすいこと。

ATAMに関する日本語書籍は「システムアーキテクチャ構築の原理」と「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 (Software Design plus)ぐらいしかないので、貴重だと思う。

データベースコンサルタントのノウハウちょい見せ 書評「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価」

【3】3つ目は、2009年頃の書籍なので、UMLをベースとした設計を念頭に置いていること。
機能的ビューではコンポーネント図、情報的ビューではER図やDFDや概念クラス図、並列性ビューではステートマシン図を使うと良いと説明されている。
このあたりの意見は僕も同意するが、注意点はいくつかあると思う。

コンポーネント図は「アジャイルソフトウェア開発の奥義」でも重要視されている。
機能を1つのコンポーネントとみなし、コンポーネント間のインターフェイスを重視する設計は重要だと思う。
一方、コンポーネント図だけでは表現しきれない仕様や要件があり、不十分と感じる。

その点は「システムアーキテクチャ構築の原理」でも、メッセージングのやり取りは記述できないので補足説明や別の図が必要と書かれている。

並列性ビューに出てくるステートマシン図は、より詳しく書いていくと結局、詳細設計レベルになってしまう。
アーキテクチャ設計ではRFPに出てくる要件レベルまでで留めたいので、粒度を揃えるのが難しい場合が多いだろう。

【4】「システムアーキテクチャ構築の原理」を読んでいて思い出すのは、2000年代にソフトウェア・プロダクトラインが流行した頃に読んだ「 実践ソフトウェアアーキテクチャ」に出てくる一節だ。

そのボタンを押したら何が起きるのですか？～アーキテクチャは利害関係者のコミュニケーション手段: プログラマの思索

実践ソフトウェアアーキテクチャの解説記事: プログラマの思索

「 実践ソフトウェアアーキテクチャ」では、政府のある委員会の2日間に渡る討議の中で、新人のアーキテクトが、政府が作ろうとしているシステムのアーキテクチャをコンサル独自の記法でモデルを描いて委員会の参加者に説明していたところ、委員会の参加者たちは何が問題なのかに初めて気づいた。
そして、委員会の参加者たちは、新人のアーキテクトの説明を途中で止めさせて、システムのアーキテクチャの問題点を活発に議論し始めたという一節だ。
これが意味しているのは、アーキテクトの役割とは、システムのアーキテクチャ設計に関する最終責任者ではなく、各利害関係者の間でシステム要件のトレードオフを考慮させる調停者であることだ。

つまり、アーキテクトの役割はシステム要件を決めることではなく、システム要件のトレードオフを色んなステークホルダーに説明して理解させて、最終的な意思決定を引き出す調停者として振る舞うべきだ、ということ。
この一節は僕が一番好きなところでもある。

「システムアーキテクチャ構築の原理」では、アーキテクトがすべてのパースペクティブやビューポイントを理解している全能の神のように思えてしまうが、実際はそうではなく、アカウンタビリティを持つ調停者という観点で捉えると理解しやすいと考える。

気づいた点はまた書き留めていく。

astahにタイミング図がサポートされた

astahにタイミング図がサポートされたのでメモ。

【参考】
astah* 9.2リリースノート | astah

タイミング図 | astah* 機能ガイド

plantumlでタイミング図が描けるらしい: プログラマの思索

astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索

astah* Mermaid Pluginが公開された: プログラマの思索

Timing図

わかりやすくUMLタイミング図とは

【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング

UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。
感覚的には、シーケンス図を横型にしたイメージを持っている。
ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べてみたいと思う。

1つの事象を複数のダイアグラムで書いてみることで、色んな観点で気づきが得られると思うし、特有の考え方や見方に慣れるメリットもあると思う。

概念モデリングや設計原則は進化しているのか

最近、概念モデリングや設計原則の勉強会に参加して色々気づきがあった。
ラフなメモ書き。

【1】「実践UML第3版」を勉強会で読み始めた。
僕は「実践UML第1版」を購入して読んでいた。
思い出せば20年前になるのか。
そこから第2版も買ったし、最近第3版も買ってみた。
中身は変わってきているが、版を重ねるごとにオブジェクト指向設計の内容が洗練されて、RUPという開発プロセスに準じるように設計から実装、移行まで一気通貫する。

2020年代の現在、「実践UML」を再度読んで気づきがいくつかある。

【2】1つ目は、RUPはもう不要と思う。
スパイラル開発プロセスはWF型開発からの脱却という観点で重要だったが、Scrumを中心としたアジャイル開発が全盛の時代だから、わざわざテーラリングが必要な重厚長大なRUPを利用するメリットはないと思う。

【3】2つ目は、モデリングに必要なUMLのダイアグラムの力点が変わっていること。
「実践UML第1版」では、以前は協調図(コラボレーション図)、今のコミュニケーション図がオブジェクト指向設計で重要です、と主張していた。
理由は、コラボレーション図を描くことで、機能をどのクラスに割り当てるべきか、凝集度や結合度、生成などの観点で検討する時に有用だから。
オブジェクトからたくさんの指示が出ていれば責務が多すぎるね、と気づきやすいから、と。
当時の自分はすごく納得した。

実践UML第2版、実践UML第3版では、クラス図やシーケンス図で説明する場面が多い。
コラボレーション図の話はなくなっていた。
たぶん、UMLの中でも重要度が下がったためだろう。

しかし、機能の割り当ての考え方は普遍的と思う。

【4】3つ目は、GRASPパターンは「情報エキスパート」パターンが一番大事ということ。
このパターンが「実践UML」の重要ポイント。

機能や責務はどのクラスに割り当てるべきか？
責務の遂行に必要な情報を持っているクラス、すなわち情報エキスパートに責務を割り当てるべきだ。

つまり、責務の遂行に必要な情報を自身のクラスの属性、関連先のクラスから取得した情報を自身のクラスで持ってること。
そして、処理を実行する時に、他クラスへメッセージを投げ出せること。

コミュニケーション図なら、情報エキスパートとなるクラスからメッセージという矢印が出ているだろう。
シーケンス図なら、情報エキスパートとなるクラスからメッセージが出て、他のクラスに処理が委譲されて、階段状の図になっているだろう。

その他のパターンも8つくらいあげられているが、そこまで重要ではないように思う。
生成、疎結合、高凝集度、多相性、コントローラは読めば分かる。
バリエーション防護壁はFacadeやAdapterみたいなもの。
純粋加工物、あるいは人工品は、機能の関連だけで構成するのではなく、ソフトウェアのプログラムの都合上、論理的なオブジェクトをワンクッション挟むようなもの。

【5】4つ目は、概念モデリングとデータモデリングは似ているようでやはり異なることだ。

「実践UML」では、概念モデリングでの注意点がいくつかある。

【6】属性とクラスは区別する。
一般に、ある概念をクラスの属性にするか、クラスで独立させるか、識別は間違いやすい。
「実践UML」の指針では、ある概念Xが現実世界では数値でもテキストでもなければ、Xは概念クラスであり、クラスの属性ではない、と言い切っている。

これは重要と思う。
初心者だった頃、どれをクラスにすべきか迷ってしまう時が多かった。
迷って、概念をクラスの属性にしてしまいがちな時が多い。

例えば、Destination、AirportはFlightに含めるべきか。
それぞれクラスとして独立させて、関連で結ぶべき。

実際は、1つの概念はクラスのロール名としていろんな別名として現れる。
例えば、企業クラスは顧客だったり仕入先だったり、取引先だったり、もしかしたらグループ内企業だったりする。
つまり、企業クラスはいろんなロール名として呼ばれる時がある。

【7】属性にはプリミティブ型を使わず、データ型を使う。
たとえば、属性にはDate型、Number型、String型を使う。
あるいは、Address、Color、PhoneNumber、UPC、SKU、ZIP、列挙型を使う。
区分値は列挙型を使う場合が多いかな。

例えば、会員クラスの会員名、会員IDみたいなものだろう。
でも、同じ会員名であっても、実際の人物は異なるケースもある。
だから、ValueObjectを別で用意して利用する場合もあるだろう。
ドメイン駆動設計なら、ValueObjectをかなり頻繁に使うだろうと思う。

【8】概念クラスの関連付けに外部キーや複合キーを書かない。
概念クラスの関連付けは、属性ではなくクラス間の関連で書く。

この部分がデータモデリングと異なるし、引っかかるところと思う。
一般にオブジェクトには唯一の主キーとなるサロゲートキーが割り当てられる場合が多いだろう。
すると、データモデリングで考えた時、外部キーや複合キーがなく、全てサロゲートキーなので、クラス間の制約条件が分かりにくくなる。
RailsのActiveRecordがそういう例になるだろう。
データモデリングなら、サロゲートキーを使っている場合、外部キーのペアが複合キーの役割を持つので強属性になるような制約をもたせるだろう。

では、概念モデルから実装モデルへ詳細化されていくうちに、関連はどう変わっていくのか？
概念モデルの関連から相手先のロール名が割り当てられて、最終的には関連はどこかのメソッドとして実装されて、そのメソッド内でロール名は変数名と同一視されて利用されるだろうと思う。

【9】概念クラス図でも、関連クラスのように、複合キーを使った事例はある。
しかし、関連クラスを多用すると、クラス図から読み取りにくくなる。
一方、データモデリングの観点では、関連クラスを複合キーを持つクラスと置き換えれば、明確な意味を読み取りやすくなる。

【10】概念モデリングでは、クラス間の関連と多重度でクラス間の制約条件を読み取る場合が多いように思う。
慣れるまで大変だけど。

【11】そんなことを考えてみると、概念モデリングや設計原則は以前よりも変化していないように思う。
UMLが流行していた2000年代からモデリング技法は進化しているのだろうか？

オブジェクト指向設計とデータモデリングの違いは他にも整理してみる。

パッケージ原則とクラス原則の違いは何なのか

パッケージ原則とクラス原則の違いについて考える時があった。
直感的なラフなメモ。

【参考】
パッケージ設計の原則を本で学ぶ - Qiita

イラストで理解するSOLID原則 - Qiita

パッケージ原則を見ると、パッケージの凝集度3つ、結合度3つの観点に分けられる。
その内容は、クラス原則であるSOLID原則をパッケージ版に拡張したように思える。

実際、単一責任の原則はパッケージの凝集度に関連するし、開放閉鎖原則はパッケージ版も同様だ。
インターフェイス分離の原則やLiskocの置換原則は、パッケージの結合度に関連してくる。

ただし、その違いはある。
1点目は、パッケージやコンポーネントの観点では、リリースできる単位が再利用できる観点と同一になる原則が最も重要になる。
理由は当たり前で、リリースして他ユーザが使えるようにするからには、他の人が再利用できる観点と同一にならざるを得ないから。

リリースモジュールは単独で動くものである一方、クラスは単独では動作できず、複数のクラスを結合して初めて一つの画面や帳票、バッチなどの機能を形成する。
この違いは大きく、再利用の観点も他者に利用してもらえる観点と、他者に読んで保守してもらえる観点の違いになる。

もう1点は、パッケージとクラスを保守する人の単位が異なる点だ。
クラスを修正する人は基本的には1人であり、コードのレビューアも関わるだろうが、1人が責任を負う。
その修正履歴はコミット履歴に残る。

一方、パッケージを保守する単位はチームや部署の単位になる。
普通は、リリースモジュールの単位はサブシステムであるから、システムごとに担当する部署があるだろう。
大規模な基幹系システムを持つ企業であれば、数多くの部署ごとに担当するシステムが異なるだろう。
つまり、サブシステムというリリースモジュールを保守するのは複数人であり、アプリ層だけでなくフロント層、インフラ層など数多くのメンバーが関わって初めて一つのシステムが動く。

すると、システム単位に開発チームが存在するので、コンウェイの法則に従うことになるだろう。
つまり、アーキテクチャ（システム）は組織に従うわけだ。
この特徴により、サブシステム間が部署間の壁となり、IFとなるので、IF連携は認識齟齬が起きやすいリスクが発生しやすい。
部署ごとにシステムが分かれることにより、システムは局所最適化されやすくなる。

そんなことを考えると、パッケージ原則とクラス原則は同じような観点が多い一方、クラス担当者やシステム担当チームの違いを認識することも必要だろうと思う。