AIが設計も思考も代替する時代ではエンジニアはモデルを理解するだけの存在なのか？

要件から実装までAIが完遂する「FDE」の台頭。
それはアジャイル開発の終焉と、システム設計や「思考」すらAIに委ねる未来を示唆している。
人間はAIが生成したモデルをただ「理解」するだけになるのか。
すべての作業と思考が代替される世界で、私たち人間の存在意義は一体どこにあるのか。

【参考】
Astah Pro MCP | astah* プラグイン

takaakit/astah-pro-mcp: A local MCP server that runs as a plugin for Astah Professional, a UML modeling tool.

takaakit/superpowers-uml: Superpowers-UML modifies Superpowers to ensure a software development workflow in which AI agents design through UML modeling.

astah* AI連携機能

FDEは「客先常駐SES」と何が違う？人間の複雑さに向き合う「AI SaaSの生存戦略」【ログラス×LayerX】 - レバテックLAB

FDEとは？最高峰のAI職種「Forward Deployed Engineer」について徹底解説！年収・職務内容・転職・求人情報 | AI・エンジニア転職ならムービン

【1】最近、FDEという言葉を知った。
「Forward Deployed Engineer」と呼ぶらしい。
僕の理解では、FDEは、要件だけ作って、後はAIエージェントに設計・実装・テスト・移行まで全てやらせる。
つまり、顧客にヒアリングして、課題解決のためにシステム要件を提案し、その後のシステム開発は全てAIにやらせる。
また、AIエージェントにシステム開発させる仕組み、つまり、ハーネスエンジニアリングも設計する役割と理解している。

【2】では、プログラマはもちろん、システムアーキテクトもFDEで代用されるのか？
そんな疑問を感じる。

AIによるシステム開発は、アジャイル開発そのものを否定するだろう。
アジャイル開発は、顧客と開発チームが一体化して開発する。
しかし、要件さえ固めれば、後はAIが全て自動生成してくれる。
つまり、顧客と、顧客からヒアリングして要件をまとめるコンサルがいれば、後はAIがよろしくシステム開発してくれる。

すなわち、ソフトウェア開発プロセスを見れば、要件定義だけになる。
なぜならば、その後の工程、設計、開発、テスト、移行は全てAIが代替してくれるので、気にしなくていいからだ。
すると、AI主導のソフトウェア開発プロセスはWF型開発に先祖返りするだろう。
要件定義をガチガチに固めるのが重要なのだから。

アジャイル開発プロセスに乗せたとしても、AIがリリースしたシステムから顧客のフィードバックをもらって、それを要件定義して、再度リリースするだけだ。
アジャイル開発プロセスが定義する、設計も開発もテストも同時並行して開発チームが考えるプロセスは無くなる。
つまり、要件定義とAIのシステム開発だけの工程になるならば、WF型開発で工程管理した方が楽だ。

よって、システムアーキテクトという役割もAIに吸収される。
じきに、顧客自身が要件をまとめられるならば、コンサルも必要ない。
要件をのものをまとめる作業すら、AIにいろんな要望をプロンプトで投げれば、要件定義書も作ってくれるだろう。
つまり、ビジネスアナリストという役割もAIに吸収されるかもしれない。

FDEが示唆するものは、AIがシステム設計から移行までを代替するだけでなく、じきに要件定義そのものもAIが代替することを示唆しているだろう。

【3】また、astahでは、AI機能が投入された。
Copilotと連携して、AIと対話形式でクラス図、シーケンス図などの自動生成をしてくれる。

astah* AI連携機能

振り返れば、MermaidやPlantUMLでクラス図やシーケンス図などUMLダイアグラムは全て書けるのだから、AIでMermaidやPlantUMLをAIで生成すればいい。
つまり、モデルそのものもテキストで表現できるならば、プロンプトと相性がすごくいい。

astah上で、モデルの配置をマウスでグリグリする作業すらいらない。
AIがモデル要素を吐き出し、モデルの配置すら定義してくれるからだ。

【4】では、モデリング作業や、システム設計という思考そのものはAIがどこまで代替可能であるか？

モデリング作業そのものはAIに吸収されるだろう。
UMLの全てのダイアグラムは、MermaidやPlantUMLで書けるのだから、UMLによるモデル生成はAIで実装される。

FDEと同様に、モデルを定義するアーキテクチャ設計そのものもじきにAIが代替するだろう。
要求を適当にプロンプトで投げれば、要件定義書が出力できるからだ。
そこから、Bestなアーキテクチャ設計もAIに聞いて、判断すればいい。
判断そのものも、判断基準をプロンプトで投げてAIにやらせればいい。

すると、システム設計という思考そのものもAIに委託して、AIに代替されるのか？
確かに、人間が思考する行為そのものもAIに委託できるだろう。

しかし、人間はシステムを理解したい欲求があるはずだ。
システムは複雑で、目に見えないので理解しづらい。
そこで、システムをモデル化して理解したい。
よって、システムをリバースして、モデル化する作業そのものをAIにやらせればいい。

AIにシステム開発させるだけでなく、人間が理解するためのモデルもAIに生成させる。
AIで生成されたモデルを通じて、人間はシステムとアーキテクチャ設計を理解するだろう。

【5】結論は、AIがシステム開発も、システム設計も、アーキテクチャ設計も、モデル生成も、モデル設計の作業も全て代替するだろう。

システム要件を考える行為、モデルを考えるモデリング行為そのものもAIが代替するだろう。
人間の思考そのものも、AIに委託できるだろう。

しかし、モデリング作業は必要にはならないと思う。
人間がシステムを理解するためにモデルが必要だからだ。
つまり、人間がシステムを理解し把握するために、AIがモデル生成する作業そのものは残るだろう。

すると、人間の役割は何なのか？
AIがすべての作業を代替してやれるならば、人間の存在意義は何なのか？

要件定義を行うビジネスアナリスト、システムアーキテクチャを考えるシステムアーキテクトの役割もAIが代替するならば、人間の存在は何の役に立つのか？
思考する行為が人間の存在意義だったのに、それすらもAIに委託できて、AIの方がはるかに深い考察結果を出すのならば、人間は不要なのか？

リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めて、色々考えたことをメモ。

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | Nick Tune, Jean-Georges Perrin, 元内 柊也, 岩﨑 勇生, 角谷 太雅 |本 | 通販 | Amazon

More Joel on Software | Joel Spolsky, 青木 靖 |本 | 通販 | Amazon

アーキテクチャモダナイゼーションとはそもそも何なのか？: プログラマの思索

アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か: プログラマの思索

システムのリプレース案件が最も危険な理由: プログラマの思索

【1】リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか？
まだ違いが分からない。
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するでは何を語ってくれているのか？

【2】リプレース案件はIT業界の人なら誰でも経験するデスマーチ案件だ。

ユーザや顧客から見れば、既存システムは動いているのだから、その機能をそのまま移し替えるだけでしょ。
動く既存システムが仕様そのものだから、見れが分かるでしょ、とユーザは思う。
しかし、リプレース案件を担当すると、どんな技術者も苦労すると思う。

リプレース案件の特徴は３つあると思う。

一つ目は、アーキテクチャの構成要素のバージョン依存関係の難しさ。
インフラ基盤のサーバー、OS、DB、ミドルウェア、プログラミング言語のバージョン違いから出るバージョン組み合わせの品質担保の難しさ。
構成要素のバージョンが１つ違うだけで、すぐにシステムは動かなくなる。

二つ目は、システム移行、データ移行の難しさ。
同じ機能のシステムを単に入れ替えるだけなのに、システム移行、データ移行で必ずトラブル発生。
たとえば、システム移行の障害では、構成要素のバージョン依存関係が原因になるケースが多い。
データ移行の障害では、既存データのボリュームが多すぎて処理時間が想定よりも長くなって業務トラブルが発生したり、既存システムのインフラ基盤やRDBに思わぬ落とし穴が原因のケースが多い。

三つ目は、同じ機能をそのまま入れ替えるだけなのに、現行と新規システムの機能比較テストで必ず差異が出てテストに苦しむ。
ユーザから見れば、なぜ現行システムと新規システムでテスト結果が異なるのか分からない。
しかし、ちょっとした環境の違いによって、プログラムやデータの振る舞いは予期しない結果になりやすい。
テスト計画やテストマネジメントの方がプログラミングよりも大事。

その他にも、業務移行の難しさがある。
古い現行システムは使いにくいUIや既存バグがそのまま残って使いづらい。
よって、ユーザもバグあり前提で業務を運用している。
安易にUI改善や既存バグ修正すると、既存業務も変わってしまう。
リプレースのついでにBPRも行ってしまうと、マニュアル改訂やユーザ説明会みたいな工数も増えてしまい、業務移行コストが想定以上に増えてしまう。

つまり、リプレース案件には新規開発案件や機能改修案件とは異なる特徴がある。

【3】リプレース案件では、テストや移行という後工程の作業にかなりの工数が割かれるケースが多い。
そういう特徴を理解して、アーキテクトやプロジェクトマネージャはリプレース案件のプロジェクト計画を立てる。
特に、テスト計画や移行計画の精度の高さが、リプレース案件の成功度合いに直結するだろう。

【4】では、改めて、リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか？
NotebookLLMの回答は下記の通り。

既存システムを新規システムへ移行するという点では共通していますが、リプレースとアーキテクチャモダナイゼーションの違いの本質は、その「範囲」「アプローチ」「目的」の3点に集約されます。

1. 範囲の本質：技術刷新か、ソシオテクニカルな刷新か
リプレース：主に古い技術スタックを新しいものへ置き換えるといった、純粋に技術的な側面に焦点が置かれます。
モダナイゼーション：技術だけでなく、人、組織構造、ビジネス戦略、働き方のすべてを深く連携させる**「ソシオテクニカル（社会技術的）」な刷新**です。
組織のコミュニケーション構造がシステム設計に影響を与える「コンウェイの法則」を前提とし、組織とアーキテクチャを共同で最適化します。

2. アプローチの本質：革命（大規模刷新）か、進化か
リプレース：最初に全体を設計してからゼロから新しいコードを書く「ビッグデザイン・アップフロント」が主流であり、既存システムをすべて廃棄して作り直す**「大規模刷新プロジェクト（革命）」**になりがちです。これはしばしば「悪夢」のような困難を伴います。
モダナイゼーション：完成形を最初にすべて定義するのではなく、**「進化的アーキテクチャ」**の考え方を取ります。3～6カ月といった短期間で段階的に価値を提供し、継続的な学習とフィードバックを通じてアーキテクチャとロードマップを改善し続ける「終わりのない旅」と捉えます。

3. 目的の本質：負債の返済か、資産の再構築か
リプレース：既存の機能をそのまま新しい環境へ移植する「リバースエンジニアリング」に終始しやすく、古いシステムの欠陥や不要な複雑さを引き継いでしまうリスクがあります。
モダナイゼーション：単なる「負債の返済」ではなく、「資産の再構築」競争優位性のある資産へと転換し、高速なフロー（迅速かつ安全なデリバリー）を実現することを目指します。
結論として、両者の違いは**「システムを新しくするだけでなく、変化に適応し続ける組織能力そのものをアップデートしようとしているか」**という点にあります。

【5】NotebookLLMの回答を読む限り、アーキテクチャモダナイゼーシヨンには下記の観点があるらしい。
・技術視点よりも、組織戦略や経営戦略の観点で組織とアーキテクチャ最適化を重視
・「大規模刷新プロジェクト（革命）：よりも、「進化的アーキテクチャ」を重視
・「リバースエンジニアリング」という単なる「負債の返済」よりも「資産の再構築」を重視

この観点が、リプレース案件の特徴から発生する諸問題、特に移行やテストの難しさをどのように解決してくれるのか？
まだ理解できていないので、じっくり考えてみたい。

すり合わせの優位性は健在か？日本の製造業が直面する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ベースのモデル開発は非常にハードルが高いと言えるだろう。

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

アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めた。
アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か？
考えたことをメモ。

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | Nick Tune, Jean-Georges Perrin, 元内 柊也, 岩﨑 勇生, 角谷 太雅 |本 | 通販 | Amazon

チームトポロジー 適応型組織設計

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地 |本 | 通販 | Amazon

アーキテクチャモダナイゼーションとはそもそも何なのか？: プログラマの思索

チームトポロジーにおける4チームのインタラクションをUMLで整理してみた: プログラマの思索

チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索

システムのリプレース案件が最も危険な理由: プログラマの思索

【1】アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、アーキテクチャモダナイゼーションイネーブリングチーム（AMET：Architecture Modernization Enabling Team）という特別なチームがある。
このチームの役割と責任範囲は何か・
このチームは、アーキテクチャモダナイゼーションにおいてどんな役割を果たすのか？

【2】Geminiに聞いてみた。

アーキテクチャモダナイゼーションイネーブリングチーム（AMET：Architecture Modernization Enabling Team）は、全ての決定を下す中央集権的なチームになることなく、取り組み全体を通じて推進力を維持しながらモダナイゼーションを導き、サポートする専門チームです。チームトポロジーにおける「イネーブリングチーム」の一種であり、組織の能力向上に伴い段階的に縮小・解散する「一時的な足場」としての性質を持ちます。
AMETの主な役割と責任範囲は、以下の6つの目的と具体的な活動に集約されます。

1. 6つの主な目的（役割）
モダナイゼーションの始動: 説得力のあるビジネスケースを構築し、ヒアリングツアーやキックスターターワークショップを通じて、取り組みを停滞させる「分析麻痺」を打破して軌道に乗せます。

勢いの維持: 定常業務（BAU）やバグ修正などの優先順位に押されることなく、取り組み全体を通じて高いエネルギーを維持し、進捗を阻害する障害を取り除きます。

よりよい設計の促進: ドメイン駆動設計（DDD）などのモダンなアーキテクチャ設計スキルが不足しているチームに対し、コーチングやワークショップを通じて設計スキルの向上を支援します。

長期的で持続可能な変化の促進: 一時的な活動に終わらせず、新しい働き方や技術的実践が組織のDNAとして定着し、AMETがいなくなっても自律的に改善を続けられる基盤を築きます。

ビジョンと進捗の伝達: 取り組みの外部にいる関係者が不安を感じたり価値を疑ったりしないよう、ビジョンと具体的な進捗状況を組織全体へ周知し続けます。

成功事例と学びの共有・展開: 特定の分野での成功や教訓を他の分野へ広め、組織全体の学習を加速させます。

2. 戦略的・組織的な責任範囲
ビジネス戦略への貢献: アーキテクチャの変更をビジネス目標や成長戦略と明確に結びつけ、投資の正当性を説明する責任を負います。
アーキテクチャ運用モデルの確立: AMET解散後も組織が進化し続けられるよう、アーキテクチャギルドの設立やアーキテクチャアドバイスプロセス（分散型の意思決定手法）の導入を支援します。
依存関係の管理とボトルネックの解消: 複数のチームにまたがる複雑な依存関係や、レガシーシステムに関連するボトルネックを特定し、その解決に向けてリーダーシップ層と連携します。
スキルアップと人員配置の助言: 必要な技術的実践（テスト駆動開発や継続的デリバリーなど）を導入し、人材育成や外部パートナーの活用について助言します。

3. 求められる姿勢とスキル
AMETは「指示を出す側」ではなく「支援する側」であるため、メンバーには高度な技術力に加えて、**忍耐強い対人スキル（NVC：非暴力コミュニケーションなど）**やコーチング力が極めて重要視されます。自ら作業の一部をこなしつつも、適切なタイミングで一歩引き、現場のチームに主導権を委ねる柔軟性が求められます

【3】ここから分かることは、AMETはチームトポロジーにおけるイネーブリングチームであることだ。
AMETは、イネーブリングチームなので、アーキテクトの専門家、ソフトウェア品質保証や開発プロセス改善の専門家から成る専門家集団であって、ストリームアラインドチームから独立している。
ストリームアラインドチームを支援したり指導する役割と捉えた。

つまり、AMETはモダナイゼーションを推進するアーキテクト専門家集団だ。

よって、AMETは経営層と開発チームの間で、お互いの情報を吸い上げたり落とし込んだり、調停する立場にある。
すなわち、AMETは経営層を支援し、開発チームを指導する権限を持つ強力なチームと言える。
社内では相当な権力を持つチームではないだろうか。

なぜならば、AMETがモダナイゼーションを定義するアーキテクチャを指定し、そのアーキテクチャの基板上でストリームアイランドチームはアプリ開発するだろうからだ。
ストリームアイランドチームを支援するために、プラットフォームチームやコンプリケイテッドチームも存在するのだろう。

【4】そんなことを考えると、モダナイゼーションを実施する案件の規模は相当な大規模PJになるだろう。
100人月はもちろん、もっと大規模な工数がかかるだろう。
単なるアプリ開発チーム以外に、AMETのようなアーキテクト専門家集団もいて、アーキテクチャを支える基盤を構築維持するプラットフォームチームもいるのだから、相当な人数が関わる案件になるからだ。

よって、PJ管理は相当難しくなるだろう。
アーキテクチャそのものも相当複雑になりがちだろうと想像する。
だからこそ、AMETのようなアーキテクト専門家がいなければ、たくさんのストリームアイランドチームという開発チームにガバナンスを効かせて統制を取ることができないだろう。

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するではAMETがかなり重要な役割を果たしているので、じっくり読んでみたいと思う。

アーキテクチャモダナイゼーションとはそもそも何なのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めた。
アーキテクチャモダナイゼーションとはそもそも何なのか？
考えたことをメモ。

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | Nick Tune, Jean-Georges Perrin, 元内 柊也, 岩﨑 勇生, 角谷 太雅 |本 | 通販 | Amazon

More Joel on Software | Joel Spolsky, 青木 靖 |本 | 通販 | Amazon

システムのリプレース案件が最も危険な理由: プログラマの思索

【1】アーキテクチャモダナイゼーションとはそもそも何なのか？
システムのリプレースとは何が違うのか？
システム刷新に出てくるリホスト、リビルド、マイグレーションなどの概念とは何が違うのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するには明確に書かれていないようだが、理解した限り、
「モダナイゼーション＝リプレース＋UX改善＋組織変革」
を意味するらしい。
つまり、単純なリプレースを意味しない。

【2】一般に、リプレース（再構築）とは、既存システムの機能は変えず、システム内部構造を再構築し直すことだ。
リプレース案件は、SIerのビジネスの中でかなりの案件数を占めるのではないか。
ITシステムは一度作ったら10年以上変えずに動くわけではなく、OSやミドルウェアやプログラミング言語のVerUp、CPUやメモリやHDD容量のサーバー性能増強、外部環境の変化によって、必ず定期的に手を加えなければならない。
そのタイミングでシステムの内部構造を入れ替える時が多い。

しかし、リプレース案件は大抵、デスマーチ案件に陥りやすい。
その理由は20年以上前に書いた。

システムのリプレース案件が最も危険な理由: プログラマの思索

リプレース案件は危険だ。
リプレースでなくても、リホスト、リビルド、マイグレーション程度の案件であっても、ソフトウェア開発能力やPJ管理能力が不十分ならば、失敗案件に陥りやすい。
たぶん、IT案件特有の事象だろうと思う。

【3】モダナイゼーションはリプレースだけでなく、UX改善や組織変革を含む意味は何なのか？
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、システムの内部構造を変えるだけでなく、UXも改善することで、利用ユーザの便利さや活用も重視している点だろう。
つまり、業務プロセスの改善、ビジネスモデルの変革も意図しているのだろう。

さらに、モダナイゼーションが単純なリプレースではなく、ドメイン駆動設計やアジャイル開発を志向するのであれば、逆コンウェイ戦略に基づく組織運営になるだろう。
つまり、インフラ層・DB層・アプリ層・フロントUI層のような機能別レイヤーの組織構造ではない。
チームトポロジーのように、複数のストリームアイランドチームが中核の機能を開発し、イネーブリングチームやプラットフォームチーム等が支援する組織構造になるだろう。

すなわち、ソフトウェア開発組織も従来のような機能別組織ではなく、アジャイル開発に適したスクラムチーム主体の開発組織になることを意味しているのだろう。

【4】では、アーキテクチャモダナイゼーションを考える正統性、意義はどこにあるのか？
従来のリプレース案件の延長ではなく、アーキテクチャモダナイゼーションをわざわざ考えるのは、どんな背景・意図のためにあるのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、下記の観点があるらしい。

1. 経営・投資の切り口：ROI（投資対効果）の最大化
背景: モダナイゼーションはシステムと事業運営への相当な投資であり、決して無料ではありません。
意図: 闇雲にすべてを刷新するのではなく、**「ビジネスの戦略的優先事項にどう貢献するか」**を明確にすることで、投資収益率（ROI）を最大化させる判断材料を提供しています。

2. 競争優位性の切り口：競合への対抗と「慣性」の打破
背景: 成功した企業ほど過去のビジネスモデルに固執し、変化を嫌う「慣性」が生じます。一方で新規参入者は最新技術で武装して破壊的変革を仕掛けてきます。
意図: 自社の開発能力が時代遅れになり、**「迅速な競合他社に後れを取るリスク」**を直視させることで、存亡に関わる脅威としてのモダナイゼーションの必要性を説いています。

3. 事業成長の切り口：拡大を阻む「足かせ」の除去
背景: 新規参入者の脅威がない場合でも、既存のアーキテクチャがビジネスの拡大（市場浸透、新プロダクト開発など）を物理的・構造的に妨げることがあります。
意図: 市場開拓や多角化といった**「成長戦略」を支えるために、どの程度の刷新が必要か**を見極める視点を提供しています。

4. 資本戦略・M&Aの切り口：企業価値（資産）の再構築
背景: 買収による成長を目指す場合や、自社の売却（出口戦略）を検討している場合、レガシーなシステムは「負の資産」として評価を下げたり、統合のボトルネックになったりします。
意図: 厳密な資産査定に耐えうる**「投資家にとって魅力的なアーキテクチャ」**を維持することが、出口戦略の成功に直結することを示しています。

5. ユーザー体験・運用の切り口：品質と生産性の向上
背景: 劣悪なUXはブランドへの信頼を失わせ（二重予約などの事故）、非効率な内部ツールは運用コストを増大させ、従業員のストレスを増大させます。

意図: 単なる「見た目の修正」ではなく、「根本的なアーキテクチャの負債」がUXや生産性を毀損している事実をステークホルダーに認識させるためです。

6. 組織能力の切り口：人材の採用と定着
背景: 古い技術スタック（例：COBOLや巨大なC++モノリス）を使い続けることは、優秀なエンジニアにとってキャリアの行き止まりを感じさせ、採用困難や離職を招きます。
意図: 「本気でモダナイゼーションに取り組む姿勢」そのものが、優秀な人材を引きつける強力なインセンティブになるという副次的メリットを提示しています。

つまり、単に技術者がシステムを綺麗にしたいから、という意図だけではなく、「ビジネスの存続と成長のために不可欠な投資である」意図が重要なわけだ。

【5】アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するは内容がとても濃い。
システム設計の話よりも、経営戦略や組織戦略の観点が多い。
だから、正直読みづらい点もある。

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するに出てくる重要なキーワードには、AMET（Architecture Modernization Enabling Team）、アンゾフの成長戦略、BVSSHモデル、プロダクトの分類体系（プロダクトタクソノミー）などが出てくる。
これらについても理解したことを書いていく。

自動車の組込ソフトウェア開発が難しい理由は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規格遵守も必要になったことにより、他のシステム開発よりも複雑かつ難易度が高い点だ。

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

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

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

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

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

プ譜でプロジェクトの目的を管理する

オープンソースカンファレンス大阪にてプ棋の話を聞きたくて参加してきた。
プロジェクト管理の一手法として、目的や課題の管理に使えないか、今実際に使っているが、まだ腑に落ちてない。
講演者に実際に質問をぶつけてみたら、将棋の棋譜みたいにプロジェクトの局面をストーリーや歴史みたいに鳥瞰できる感覚が掴めた。
ラフなメモ書き。

【参考】
紙1枚に書くだけでうまくいく プロジェクト進行の技術が身につく本 | 前田 考歩, 後藤 洋平 |本 | 通販 | Amazon

見通し不安なプロジェクトの切り拓き方 | 前田 考歩, 後藤 洋平 |本 | 通販 | Amazon

予定通り進まないプロジェクトの進め方 | 前田考歩, 後藤洋平 |本 | 通販 | Amazon

プ譜の書き方と書く“意味” ?あなたの成長を支える“構造と思考の地図”?｜前田考歩

1月31日(土) タイムテーブル - オープンソースカンファレンス2026 Osaka

【プ譜友の会】プロジェクトの「不確実性」を定量評価する挑戦！ - セミナープログラム - オープンソースカンファレンス2026 Osaka

【1】プロジェクトで仕事している時に一番問題に感じることは、目的を忘れて作業に没頭してしまい、見失ってしまうことだ。
もちろん、プロジェクト計画も作るし、プロジェクト憲章も作るし、WBSも課題管理表も作って管理する。
しかし、実際の仕事は、目的を考える時間よりも、たくさんの打合せや資料作成などの実作業にほぼ時間を取られてしまう。

なぜ、そんな計画を立てたのか？
そもそも今の作業は効果があるのか、正しい目的に沿っているのか？
課題に対する対策は、本当に効果が出ているのか？
その判断は正しいのか？

日本人の技術者も担当者も、実作業が与えられたら真面目にやる。
しかし、作業に没頭してしまい、その作業の目的、正統性、効果測定を忘れてしまう。

プロジェクトは、経営目標や経営戦略に沿って作られるものであり、経営目標に対してそのプロジェクトがどれだけ貢献したのか、成果や効果を評価すべきだ。

そこで、プ譜というツールを使ってみる。

プ譜は端的には、目的に対する施策とその評価結果をプロジェクトの各局面で履歴として残し、将棋の棋譜みたいに追跡できる仕組みだ。
つまり、プ譜はToBeとAsIsを端的に表した1枚の図だ。
実際のプ譜のPPTテンプレはすごく単純だ。

それはプロジェクトの各局面のスナップショットであり、プロジェクト完了時にふりかえれば面白い。
プロジェクトリーダーが課題を適切に管理できていたのか？
その判断は正しかったのか？
その意思決定を間違えていたら上手く元々の軌道に戻せたのか？

すなわち、プロジェクトリーダーの意思決定をふりかえり、自分自身の意思決定の質を上げていくための処方箋にもなりうる。

プ譜はプロジェクトリーダー向けのツールだと思う。

これから使いこなしてみたいと思ってる。