Unifiedメモリとは何か？

MacのARMアーキテクチャでは、Unifiedメモリが使われる特徴がある。
Unifiedメモリのおかげで、AI時代では、ローカルLLM開発やオンプレLLM運用にMacが使われると言われている。
以下、その理由をGeminiに聞いてみた。
浅はかな初心者のメモ。

【参考】
新・標準プログラマーズライブラリ　RISC-Vで学ぶコンピュータアーキテクチャ　完全入門 | 吉瀬 謙二 |本 | 通販 | Amazon

ディジタル回路設計とコンピュータアーキテクチャ[ARM版] | デイビッド・M・ハリス サラ・L・ハリス, 天野英晴 |本 | 通販 | Amazon

AI設計図の革命: ?ARMの黄昏とRISC-V。1兆個のプロセッサが世界を埋め尽くす? | Cristal AI Design, Toshiyuki Tajima, Jemie |本 | 通販 | Amazon

【1】Unifiedメモリとは何か？

以下、Geminiの解説。

Unifiedメモリ（統合メモリ）とは、コンピュータ内の複数のプロセッサ（CPUやGPU、AI処理を行うNeural Engineなど）が、ひとつの広大なメモリプールを完全に共有する設計（アーキテクチャ）のことです。

Apple Silicon（M1/M2/M3/M4シリーズなど）の登場によって一気に一般へ認知が広がりました。

従来のメモリとの違い
従来の一般的なPCと、Unifiedメモリを搭載したシステムでは、データの持ち方が根本的に異なります。

従来のメモリ構造 (Traditional Memory Architecture)
CPUとGPUがそれぞれ独立したメモリを持ち、データをやり取りする（←?の部分）ために転送コストが発生する構造です。

[ CPU ] [ GPU ]
▲ ▲
│ │
▼ ▼
[ System RAM ] ←━━━━━━→ [ VRAM ]
(データのコピー)

Unifiedメモリ構造 (Unified Memory Architecture)
CPUとGPUの「コア」が、ひとつの巨大なメモリプール（共通の部屋）を直接見に行ける構造です。データのコピーが不要になります。

[ CPU Core ] [ GPU Core ]
▲ ▲
│ │
▼ ▼
==========================================
[ Unified Memory Pool ]
==========================================

【2】なぜ、MacがローカルLLMを動かくのに使われるのか？

Mac（特にApple Silicon搭載のMac）がローカルLLM（大規模言語モデル）を動かす環境として圧倒的に支持されている理由は、まさに先ほど解説した「Unifiedメモリ（統合メモリ）の特性」と「コストパフォーマンス」が奇跡的な噛み合わせを見せているからです。

1. 巨大な「VRAM」を圧倒的な低コストで手に入れられる
LLMをローカル環境で高速に動かす（推論する）には、モデルのデータ（パラメータ）を丸ごとGPUのメモリ（VRAM）に載せる必要があります。もしメモリが足りず、通常のメインメモリやSSDにデータが溢れると、処理速度は絶望的に遅くなります。

Mac（Apple Silicon）の場合
UnifiedメモリはCPUとGPUで共有されるため、「搭載メモリのほぼすべてをVRAMとして扱える」という裏技のような状態になります。例えば、メモリを128GBや192GBにカスタマイズしたMac StudioやMacBook Proを用意すれば、それだけで「VRAM 100GB超のモンスターマシン」が完成します。これをWindows環境で実現しようとすると数倍のコストとシステム構築の専門知識が必要になりますが、Macなら吊るしの製品を買ってくるだけで済みます。

2. メモリ帯域幅（通信速度）が異常に広いLLMの処理は、GPUの計算性能そのものよりも「どれだけ速くメモリからデータを読み込めるか（メモリ帯域幅）」がボトルネック（速度の上限）になりやすい特性があります。Macの「Max」や「Ultra」と名の付く上位チップは、このメモリ帯域幅が一般的なPCとは桁違いに広く設計されています。

チップ名,メモリ帯域幅（データの転送速度）
一般的なWindows（DDR5 デュアルチャネル）,約 60 ~ 90 GB/s
Apple M3 Max,約 300 ~ 400 GB/s
Apple M2 Ultra,約 800 GB/s

3. エコシステム（ソフトウェア）の最適化
Appleが公式に提供している機械学習フレームワーク「MLX」や、オープンソースで開発されている「llama.cpp」といった高性能なライブラリが、Apple Silicon（GPUやNeural Engine）に完璧に最適化されています。

これにより、専門的な環境構築をせずとも、開発者がGitHubからコードをクローンしてくるだけで、Macのハードウェアパワーを100%引き出したローカルLLM環境が驚くほど簡単に構築できるようになっています。

Windowsで大容量VRAM環境を作ろうとすると「大掛かりなサーバーのようなPC」が必要になるのに対し、Macであれば**「静かで、電気代もかからず、ノートPCや小型デスクトップのサイズで、70B（700億パラメータ）クラスの超巨大なAIモデルが手元で動かせる」**。これが、AIエンジニアや研究者がMacを選ぶ最大の理由です。

【3】MacのUnifiedメモリは元々、消費電力最小化と処理高速化のために、ARMアーキテクチャでSoCで作られたと聞く。
つまり、CPUとGPUの処理を別々のメモリバスでつなぐのではなく、共有のメモリ領域とし、動かすような仕組みで作られた。

AI時代では、CPUよりもGPUが物を言う。
GPUがなければLLMが動かない。
しかし、Macならば、NvidiaのGPUが搭載されたAIサーバを買わなくても、Unifiedメモリ上でGPU処理を実現できる。
すなわち、Unifiedメモが128G、256Gなど巨大に搭載すれば、スケールしていくらでも処理高速化を図れる。

だから、最近Macが急激に売れている理由は、そこにあるのかもしれない。
Macは、単なるプログラミング開発環境だけでなく、ローカルLLM開発や運用ができる環境なわけだ。

夢のオンプレLLM環境？ NVIDIA DGX Sparkの真実と「Claude Code代替」の壁

【1】ローカル環境で強力なLLM（大規模言語モデル）を動かし、セキュアな開発ワークフローや独自のエージェント環境を構築する。DX推進や社内システムの刷新に携わるエンジニアなら、一度は検討するテーマではないだろうか。

最近、オンプレミスでローカルLLMを構築するためのAIサーバーとして「NVIDIA DGX Spark」が大きな注目を集めている。Amazonでも手軽に（？）購入できるこのサーバーだが、実際に導入して「Claude Codeのローカル代替」として使い物になるのだろうか。
今回は、DGX Sparkの実力と、ローカルLLM運用におけるハードウェアの壁について整理する。

Redmine勉強会で聞いた内容を自分なりに理解した内容で、Geminiに聞きながら書いてみる。

ゼロから作るDeep Learning ❺ 生成モデル編

ゼロから作るDeep Learning ❹ ―強化学習編

ゼロから作るDeep Learning ❸ フレームワーク編

ゼロから作るDeep Learning ❷ 自然言語処理編

【2】「NVIDIA製AIサーバーでしか動かない」は本当なのか？

ローカルLLMの導入を検討し始めると、「DellやHPのような一般的なサーバーでは動かず、NVIDIAが作ったAIサーバー（DGXシリーズなど）専用ではないか？」という噂を耳にすることがある。

結論から言うと、これは誤解である。

ローカルLLM自体は、適切なGPU（NVIDIA RTXシリーズなど）や十分なメモリさえ積んでいれば、DellやHPのサーバー、さらには自作PCやMacでも動作する。
モデルを動かすためのGUIツールや実行環境としては、libraryなどのライブラリ群が非常に充実してきており、環境構築のハードル自体は大きく下がっている
（参考：2026年のローカルLLM事情を整理してみた | DevelopersIO）。

では、なぜ「NVIDIA DGX Spark」がこれほど推奨されるのだろうか。
それは「GB10 Grace Blackwell Superchip」のような、CPUとGPUのメモリ帯域を広帯域で直結した統合アーキテクチャが、LLMの推論（特に大規模モデル）において圧倒的な効率を叩き出すからだ。

【3】立ちはだかる「VRAM（メモリ）」の物理的な壁

ローカルLLMを実用レベルで動かす際に直面するのが、パラメーター数と要求メモリのシビアな関係だ。一般的な目安として、モデルのパラメーター数に応じてメモリ（VRAM）が必要になる。

* **30Bモデル**: 約 30GB メモリ
* **128Bモデル**: 約 128GB メモリ
* **200Bモデル**: 約 400GB メモリ

個人や小規模なチームの環境で、数百GBのVRAMを確保するのはコスト的に非常に困難だ。
Amazon.co.jp: NVIDIA DGX Spark GB10 Grace Blackwell Superchip、128GB LPDDR5x、ARMプロセッサ、4TB NVME M.2 SSDストレージ : パソコン・周辺機器は128GB LPDDR5xメモリを搭載しているため、理論上は128Bクラスのモデルをギリギリ読み込むポテンシャルを持っている。

【4】 DGX Sparkは「Claude Codeのローカル代替」になるか？

128GBのメモリを搭載したDGX Sparkがあれば、OpenAIやAnthropic（Claude）に依存しない、完全オンプレミスの強力なコーディングAI環境が作れるのではないか。
そう期待したくなるが、現実は少し厳しいようだ。

DevelopersIOの検証記事（DGX Spark を 2 か月使って見えた「向いている仕事」 と 「向いていない仕事」 | DevelopersIO）によると、オンプレ環境のDGX Sparkには明確な「向いていない用途」が存在する。

1. **トークン生成速度が求められる用途**
2. **128GBのメモリを完全に使い切る巨大LLMモデルの稼働**

コーディングエージェント（Claude Codeなど）のように、複雑なコードベースを読み込み、高速に思考プロセスを回して大量のコードを生成・修正するタスクにおいては、「推論のスピード（トークン生成速度）」がUXに直結する。

DGX Sparkで巨大なモデルをギリギリ動かせたとしても、生成速度が遅ければインタラクティブな開発ワークフローには組み込めない。
結論として、**クラウドベースの最先端LLM（GPT-4系やClaude 3.5 Sonnet以降など）に正面から立ち向かえる性能を、1台のローカルAIサーバーで出すことは現時点では困難**と言わざるを得ない。

【5】クラウドとローカルのハイブリッド戦略

現状の技術動向を踏まえると、すべてをローカルに寄せるのではなく、用途に応じた使い分け（アーキテクチャの分離）が現実的な解となる。

機密性の極めて高い自社ナレッジ資産の解析や、レスポンス速度をそこまで問わないバッチ的な処理（ドキュメントのMarkdown一括変換の補助など）、あるいは30B～70Bクラスの軽量モデルで十分なタスクには、DGX Sparkのようなローカル環境が良いだろう。
しかし、現在では、非力すぎて使えないと聞く。

一方で、日々の「Claude Code」のようなアジリティが求められる開発体験には、引き続きクラウドAIのパワーを素直に借りるのが、プロジェクトを止めないためのベストプラクティスと言えるだろう。

Redmine、DOA、PM理論。点だった知識が“世界の見え方”に変わる瞬間

Redmine、DOA、PM理論、PLM、組織論──点だった知識が、経験と結びついた瞬間、世界の見え方が変わった。
20年以上働いて見えてきた「知識と経験が知恵に変わる瞬間」を書く。

【参考】
幸せなITパーソンになるためのいきいきする仕事とやる気のつく | 羽生 章洋 |本 | 通販 | Amazon

ワークショップ・デザイン[新版] 知をつむぐ対話の場づくり | 堀公俊, 加藤彰 |本 | 通販 | Amazon

ロジカル・ディスカッション[新版] チーム思考の整理術 | 堀公俊 |本 | 通販 | Amazon

問題解決ファシリテーター―「ファシリテーション能力」養成講座 (Best solution) | 堀 公俊 |本 | 通販 | Amazon

【1】長年の仕事の中で、自分の中で何かがインスパイアされて、経験したこと、他者と議論したことが体内に染み込んで世界の見方が変わって見える時がある。
最近、そんな肌感覚を久しぶりに感じている。

【2】どんな時にそんなことを感じたのか？

以前なら、Redmineを自分の開発チームに適用してチケット駆動開発を実践できた時、これがアジャイル開発なんだ！と熱くなった時。

RedMineでチケット駆動開発！: プログラマの思索

平鍋さんのプロジェクトファシリテーション講演を聞いて、プログラマ上がりのプロジェクトリーダーのためのリーダーシップ研修みたいだ、と気づいた時。

プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ: プログラマの思索

関西IT宴会のデータモデリング勉強会にて、渡辺さんが花束問題をライブモデリングしながら、在庫推移方式とは受払テーブルを過去の在庫と未来の在庫を派生関係で表現しているのだ、と気づいた時。

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

SEA関西でドメイン駆動設計の講演を聞いた時、オブジェクト指向モデリングを業務モデリングに適用したものなんだな、と感じた時。

ドメイン駆動設計の感想～OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プログラマの思索

SEA関西で標準プロセスから各案件のテーラリングの話を聞いた時、標準プロセスはクラス、テーラリングしたプロセスはインスタンスで区別すること。PMOはそれらプロセスを法律家のように体系として定義し、下々に利用させてモニタリングし監視することなんだな、と気づいた時。

プロセス設計はどの範囲を指すのか？～プロマネの仕事はテーラリングにある: プログラマの思索

製造業のPLMツール開発案件にて、同僚からPLMツールとは製造業の情報資産のデジタル化の一環なんだよ、と示唆を受けて、PLMこそが製造業のDX戦略の本質的ツールなのだ、と気づいた時。

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

ファシリテーション協会のマネジメントゲームにて、さりいさんがチームビルディングにてタスク志向とメンテナンス志向の話を解説した時、これはPM理論そのものだな、コーチングやカウンセリング、フィードバック技法などの行動心理学のテクニックは全てPM理論の観点で整理できるな、と気づいた時。

PM理論で読み解く日本人リーダーの弱点: プログラマの思索

【3】では、他者を通じて経験したこと、議論したことが体内に染み込んで世界の見方が変わる肌感覚はどんなタイミングに発生するのか？

いつも発生するわけではない。
インプットとなる理論を知って、自分なりに理解しておかないと、経験した内容を言語化できない。
そのまま素通りしてしまう。

自分なりの意見、価値観を持っておかないと、その経験が役立つのか、大したことがないのか、判別できない。
そのまま素通りしてしまう。

自分が抱える問題意識をずっと持っておかないと、経験が自分に引っかからない。
そのまま素通りしてしまう。

つまり、自分自身が経験を咀嚼し解釈できるだけの能力がなければ、せっかくの体験も素通りしてしまうだけ。

【4】一方、たくさんの知識をため込んでも、自分自身が経験できなければずっと空想のままであって、現実から浮世離れしてしまう期間もある。

たとえば、こんな経験をした。
一時期、中小企業診断士の試験勉強をしていた。
MBAみたいな内容だし、経営学、組織論、マーケティング、財務会計、ビジネス法務、知財、生産管理、店舗管理まで範囲が広くて面白かった。
しかし、二次試験は難しかった。
過去問の事例100件以上解きまくったけれど、模擬試験でも本番試験でも、自分の勘の当たり外れが大きかった。
マーケティング、生産管理、財務会計はA評価を取れた時があったから、それなりに手応えはあった。

しかし、組織戦略がすごく苦手だった。
自分なりの理論、自分なりの価値観を最後まで確立できず、こうかな、いや、あれかな、とずっと迷い続けた。
理由は、自分が実際に組織を動かす経験、つまり、自分が社長や役員レベル、部長レベルで戦略を元に組織を動かす経験がなかったからだと思う。

たとえば、経営戦略を元に機能を洗い出し、機能別に組織を構築するという感覚がなかった。
組織は思い通りに動かないから、自分からビジョンやミッションを発信して、メンバーを動機づけさせる必要がある感覚が分からなかった。
中小企業診断士の先生は、組織文化は社長が自らやるものだ、組織文化のために社長がもっと汗をかかなければならない、と発言された時があって、僕は実感できなかったが、たぶんそういう真理を指していたのだろうと思う。

つまり、MBAの知識をいくら勉強しても、実際のビジネスの現場で使えなければ、身の丈に合わない武器を持っているだけに過ぎない。
そして今、PMOとして製造業クライアントの案件に多数関わることになって、製造業が抱える本質的な問題として組織的課題があり、そこには組織論が隠れていることを知った。

【5】行動心理学もファシリテーションも食わず嫌いで正直好きでなかった。
でも、PMOとして、クライアントのメンバーが20代～30代で若くて僕が指導する立場に必然的になった時、コーチングやカウンセリングで彼らに目指すべき状態や目的を提示し、彼らを動機付けて、彼ら自身が行動できる環境を作る必要があると経験できた。
一方で、彼らメンバーの行動に問題があればネガティブフィードバックで改善を促し、ポジティブフィードバックすることで心の報酬を与えて彼らを動機づける必要もあることも学んだ。
そんなことも20年以上働いてようやく実感した。

【6】スキルは何で作られるのか？
机上の知識はそもそも必要なのか？
経験だけで作られるものなのか？

今なら僕は自分なりの意見で回答できる。
スキルは、知識と経験の相乗効果だ。
経験を言語化できなければ、再利用できず、本当の知恵にならない。
経験しなければ、蓄えた知識は机上の空論であり、現実を動かすこともできない。

事前に知識を習得して、後から経験して体内に深く染み込む時もある。
一方、経験した後に、他者との議論や書籍にて理論に触れることで、経験した時に感じたモヤモヤ感を言語化でき、より深く理解が進む時もある。

【7】最終的には自分なりの価値観に基づき、ビジネス上のあらゆる分野にて、自分なりの理論を構築する必要があると思う。
経験を言語化することで、自分自身の行動を再現できるようになる。
経験を言語化することで、他者に説明して説得できるようになる。

【8】そういう経験を積み重ねていくと、自分が経験を通じて得られた真理を、外界の人達に普及させなければならない、みたいな気持ちになるのだろうと思う。
エバンジェリストとはそんな人を指すのだろうと思う。

JTCの壁を壊す「Redmine参謀本部」という戦略～現場の職人気質を活かす組織論

redmine.tokyoでのJTCとの対話から見えたのは、硬直化した管理と現場の職人気質のジレンマだ。
激変する製造業に今こそアジャイルが必要である。
マイクロマネジメントを脱し組織力を高める鍵、それを提供する「Redmine参謀本部（AMET）」という新たな運用戦略を紐解く。

【参考】
アドレナリンジャンキー プロジェクトの現在と未来を映す

Amazon.co.jp: 組織パターン (Object Oriented SELECTION) : James O.Coplien, Neil B.Harrison, 和智 右桂: 本

エンジニアリングマネージャーのしごと

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

【1】前回のredmine.tokyo勉強会の休憩時間で、いわゆるJTCの人達と色々話し込んだ。
やっぱり愚痴が多くなる。
せっかくRedmineと環境を用意しても、社員がなかなか使ってくれない。
標準プロセスや標準ワークフローで縛ると、不満が多くなる。
一方、JTC内部で各PJにRedmine環境をホスティングすると、開発プロセスが乱立し、Redmineのバージョンアップも難しくなる。

【2】製造業では、マスタスケジュールに基づく工程管理が基本だ。
つまり、ガントチャート画面で予実管理したい。

しかし、現代では製造業と言えども、ホルムズ海峡の石油不足、半導体不足、サプライチェーン激変などの外部環境変化により、当初立てた計画通りに進捗管理もままならない。
しかも、顧客からの仕様変更、注文も頻繁に起きているので、製造リードタイムが長い製造業ほど、顧客満足させるために凄く苦労する。
つまり、量産品であれ、特注品の製造業であれ、いずれもアジャイル開発が必要とされている。

【3】一方、日本のSIerでは、プロジェクトマネージャやプロジェクトリーダーのような手配師が重宝される。
しかし、やっぱり日本人の気質は職人だ。
だから、プログラマとしてエンジニアとして、技術を磨く方が好きな人が凄く多い。
エンジニアであれば、やはりアジャイル開発がしたい。
でも、マネージャやリーダーは、マイクロマネジメントしたがるので、どうしても衝突しがちになる。

【4】このような状況は、製造業でも同じだ。
製造業でもマネージャのようなマネジメント能力の優れた人が重宝されるが、ほとんどの真面目な社員はエンジニア気質だ。
製造業なので、メカ・エレキ・ソフトのいずれかの技術に長けた人が多い。
彼らはマネジメントなんかよりも、技術を磨きたい気持ちが強い。

【5】そんなマネジメント環境において、Redmineをどのように利用して、組織のマネジメント能力をどこまで目指すべきなのか？
Redmineをマイクロマネジメントのツールではなく、個人の能力を活かし、チームとして一体感を醸成し、組織のマネジメント能力を上げるには、何が必要なのか？

直感的には、Redmine参謀本部が必要だ。
いわゆるRedmine運用事務局、Redmine運用推進部をもっとかっこよく言った部署が、Redimne参謀本部だ。

Redmine参謀本部の役割は、Redmine運用の戦略を策定し、高性能なサーバや開発能力を調達し、JTC内部に展開するための組織体制を整備して、推進していくことだ。
つまり、参謀本部であるから、軍事戦略の策定、兵站というロジスティックスやリソース調達、そして、将校や兵隊の教育訓練の役割を担う。

Redmine参謀本部が協力に動くからこそ、JTCという古い組織であっても、それなりにRedmineを運用し活用できる。

【6】Redmine参謀本部は、「アーキテクチャモダナイゼーション」に出てくる「AMET（Architecture Modernization Enabling Team）」に似ている。
各プロジェクトを技術的にもマネジメント的にも支援する役割だからだ。

Redmine参謀本部という考え方を使って、JTCにおけるRedmine運用の戦略をどのように立てるべきなのか？を考えていきたい。
まずJTCでは、Redmine参謀本部を作れ！

第30回東京Redmine勉強会の感想 #redminet ～古いチケット管理基盤にAIという新しい衣を被った未来

Redmine誕生20周年。AIの登場により、入力支援や意思決定、プロジェクト診断など、長年の課題解決に新たな光が差し始めた。
古いチケット管理基盤にAIという新たな衣をまとうことで、これまでにない斬新な解決策が見えてくる。
進化し続け、決して飽きることのないRedmineの未来と可能性を考察する。

【参考】
第30回勉強会 - redmine.tokyo

2026/5/16 第30回勉強会 - redmine.tokyoのツイートまとめ #redmineT - posfie

【1】今年は、東京Redmine勉強会も30回目、Redmineも20周年の節目の年。
LT含めて13本の講演があって、17時まで長かったのに飽きることもなかった。

Redmineコミュニティも16年やってきて飽きる所か、AIが出てきて今までの考え方と異なる運用が見えてきたと思う。たとえば、AIによるデータ分析、AI要約、PJ診断、意思決定支援、入力支援とか。
RedmineにAIを適用すると、どんな方向性に可能性があるのか？

【2】方向性は２つある。
一つは
もう一つは、傾向分析や意思決定するための情報濃縮。

実際、Redmine運用を推進するときの課題は従来から2つあった。
1つは、担当者がチケット入力する手間を下げること、チケットにナレッジを集約する手間を減らすこと。
管理者がチケット集計する作業の手間を省くこと、

もう1つは、チケット集計機能の強化により、データ分析強化による意思決定支援。
ワークフロー管理機能の強化により、運用プロセスの基盤を整備し標準プロセスを確立すること。

前者はRedmineナレッジ化の動機づけ。
後者は管理者の意思決定支援やプロセス基盤の確立。
いずれも今までのRedmineそのものが抱える課題は変わらない。

【3】しかしAIが、難易度が高い対策の実現可能性の敷居を下げてくれてる。
AIと言う最先端の技術が、今までの古い課題解決に新たな観点で焦点を当ててくれてる。

たとえば、入力機能や管理作業の効率化支援では、AIによる入力補完、AI要約、類似チケット検索など、色んな手段が簡単に実装できる。
たとえば、管理者の恣意決定支援やプロセス基盤の確立では、AIによるデータ分析、PJ診断レポート、組織のプロジェクト管理能力に応じた運用プロセスの提案とか、AIで簡単に実装できるだろう。

つまり、Redmineという古いチケット管理基盤に、AIという新しい衣を付けただけの話。
なのに、AIを導入することで、従来の課題に対するAIの解決方法がとても斬新で面白い。
いつになってもRedmineは飽きない。

【4】初めての人とツイートしてとても興味深い内容をやり取りした。
履歴として残しておく。
3層構造の観点がすごく参考になる。
インスパイアされそう。

Xユーザーのあおのうまさん: 「@akipii そこいら鍵になるのがOntology による意味構造の提供 とskills による行動形態の方向付けだと考えています。 ただ、Ontology は基本的にグラフ構造になるので、Redmine の現状建て付けだと、ちょっと苦しいかも。 そこいらはどこを境界線とするか悩ましいですね。」 / X

Xユーザーのakipiiさん: 「@uma_blue この三層モデル、レイヤー化アーキテクチャ興味あります。コントロール、マネジメント、プレゼンテーションの各層の定義教えてください。多分手垢のついた言葉なので認識揺れ起きてるため」 / X

Xユーザーのあおのうまさん: 「@akipii タスクの捌きに係る領域がコントロール。 リソースの調整に係る領域がマネジメント。 全体の可視化と認識共有に係る領域がプレゼンテーションです。」 / X

Xユーザーのakipiiさん: 「@uma_blue 各層の依存関係は、プレゼンテーション->マネジメント->タスク　で認識合ってますか？　各層をキックするアクターは、依存関係の順に、経営層＞管理職層＞現場担当者層で認識合ってますか？　各層は独立しておらず依存関係があり、依存関係以上の密接な関係があるように直感します」 / X

Xユーザーのあおのうまさん: 「@akipii プロジェクトに関わる人間のロール間でこれらは結構グラデーションになる事が多く。 結果として、ときどきどこに比重を置くかで、情報の扱い方や粒度を切り替えたいニーズがあります。 そこの同期あるいは連結には、静的な関数というより前後文脈と状況をパラメータとした動的な処理が要る。」 / X

Xユーザーのあおのうまさん: 「@akipii AI ならそこいら上手く埋められそうかなと夢想しています。 実際に手を動かしてみたわけではないので、とんだ的外れである可能様あるのですけれど。」 / X

Xユーザーのakipiiさん: 「@uma_blue 3つの層ではそれぞれの特有の課題があり対策も異なる。AIを使えば、対策の実現可能性が高まる。各層の課題へAIを適用する手法そのものも異なるでしょう。この辺り整理分類したい。AIの要件をまとめられれば、AI実装仕様も決まってくるでしょう。」 / X

Xユーザーのあおのうまさん: 「@akipii そこいら鍵になるのがOntology による意味構造の提供 とskills による行動形態の方向付けだと考えています。 ただ、Ontology は基本的にグラフ構造になるので、Redmine の現状建て付けだと、ちょっと苦しいかも。 そこいらはどこを境界線とするか悩ましいですね。」 / X

PM理論で読み解く日本人リーダーの弱点

多くの日本人リーダーは、管理しすぎるか放置するかの両極端に陥りがちだ。
その背景には、日本特有の組織文化と育成環境がある。
PM理論とアジャイルの視点から、これからのソフトマネジメントスキルを考える。

【1】組織論の中で、日本人が生み出した唯一の理論がある。
それが三隅二不二のPM理論だろう。
リーダーシップ論に当たる。
定量的に集めたデータを下に統計処理して生み出した社会学の理論だったからこそ欧米でも受け入れられたのだろう。

PM理論｜グロービス経営大学院 創造と変革のMBA

【2】PM理論が教えるところでは、リーダーシップの傾向には2つある。
タスク志向とメンテナンス志向。
タスク志向は業績重視、仕事重視、成果重視。
メンテナンス志向は、人間関係志向、チームワーク志向。

PM理論はもはや古典的であって、現代では使えない代物と思っていた。
しかし、実は、PM理論は、チームビルディングにおいてリーダーがリーダーシップを発揮する時に使えるのではないか？

その理由や経緯を書いてみる。

ＤＸ時代の部下マネジメント―「管理」からサーバントリーダーシップへの転換 | ロッシェル・カップ |本 | 通販 | Amazon

ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップ, Kopp,Rochelle |本 | 通販 | Amazon

【3】ファシリテーション協会のイベントで、チーム運営のワークショップがあった。
チーム運営では、リーダーは上司であるマネージャの指揮命令系統の配下にあり、メンバーに対して指揮命令できる権限を持つ。
つまり、リーダーはまさに中間管理職に当たる。
そういう指揮命令系統の前提で、あるアウトプットを出す。

では、リーダーはどのようなリーダーシップを発揮して、チーム運営すべきなのか？

ほとんどの日本人はリーダーシップ経験が非常に少ないので、たぶん、両極端になりがち。
つまり、メンバーに細かく指示して管理したがるマイクロマネジメントのタイプ。
または、和を重視して、メンバー内でいざこざを起こさないように事勿れ主義になり、何も指示しない自由放任のタイプ。

マイクロマネジメントのリーダーは、タスク志向だけでメンテナンス志向がない。
メンバーに配慮せず、成果重視、業績重視だけでメンバーに指示する。
資本主義社会で営利企業に勤めている限り、売上重視、利益重視になりがちなので、そういうタイプのリーダーは多いだろう。
日本では、終身雇用や社会保険のためにそういう風習がまだ残っているかもしれない。
しかし、メンバーは口うるさい上司に従っているだけで、心の中では反発しているだろう。
メンバーを配慮するメンテナンス志向が欠落している。

一方、自由放任のリーダーは、マイクロマネジメントに反発しているせいなのか、メンバーに何もしない。
最低限の指示だけであって、助言やフィードバックもない。
すると、メンバーは好き勝手に振る舞うことになる。
メンバーは遅刻しても、勤務中に新聞を読んでも、居眠りしても怒られない。
結果的に、チームとして意味をなさなくなる。
つまり、名ばかりのメンテナンス志向だけであって、タスク志向が欠落している。

よって、PM理論は、タスク志向とメンテナンス志向の両方のスキルが必要だ、と示唆している。

【4】なぜ、日本人のリーダーは両極端になりがちなのか？

ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップを読んでその理由が分かったような気がした。

ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップによれば、日本人は子供の頃から、集団のしつけが厳しい環境で育てられる。
アメよりもムチが多い。
すると自分がムチで育てられてきたので、自分が指導者になっても同様に部下を罰してしまう指導しかできない。

日本人マネージャのマネジメントスタイルは、部下をマイクロマネジメントするか、部下を放置するか、どちらかの両極端になりがち。
その原因は、最初の上司にそのように扱われたために、マイクロマネジメントの方法しか知らないのか、逆にそのマイクロマネジメントスタイルに反発して、何もしない放置プレーに走ってしまうのではないか。

つまり、日本人マネージャは人間関係を通じて部下の行動を変化させるソフトマネジメントスキルを教わった経験もないし、受けた経験もない。
そういうソフトマネジメントスキルがある人も稀にいるが、多分、最初の上司が優れた人だったか、自分自身にソフトマネジメントスキルの素養があったのか、どちらかに限定されるだろう。

採用基準 地頭より論理的思考力より大切なもの | 伊賀泰代でも、日本人にはリーダーシップの能力が決定的に欠けているという指摘があったのを思い出す。

「採用基準」の感想～日本の根本問題はリーダーシップの総量が不足していること: プログラマの思索

現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ: プログラマの思索

また、日本人の組織は上限関係が強すぎる。
先輩後輩、年長年下、の上限関係は、言葉遣いを見ればすぐに分かる。
日本人は、目上の人に敬意を示す行動は多いが、目下の人、目上でない人へのコミュニケーションが下手だ。

日本人は以心伝心に頼りすぎだ。
腹芸、阿吽の呼吸。

今まで同じ背景を持つ人の組織に慣れすぎている。
だから、フィードバックというソフトマネジメントスキルを通じて、部下を影響させる技術を持っていない。

【5】米国では人事制度や評価制度を整備して、能力がある人には報酬を増やす制度を充実させて、労働者にアメを与える仕組みを整えてきた。
他方、日本では、能力評価制度や実力主義の人事制度は、リストラや賃金カットの手段として否定的に捉えられている。
つまり、日本人は会社の人事制度や評価制度を根本的に信用していない。
その背景には、彼らが上司から粗雑に扱われてきた経緯があるし、会社も内発的動機に働きかける制度作りやその運用方法を知らないし実践できていないからだ。

日本企業は今まで、年功序列に従う賃金報酬、長期雇用の人事制度に頼って、社員を管理してきたと言われる。
でも、僕は、年功序列、長期雇用の保証という組織人事制度は、嘘だろうといつも思っている。
たぶん年功序列の長期雇用の保証制度は、昭和の世代までであって、今までの会社で見たことがない。
年功序列で長期雇用を保証されているから、社員を大切にし、福利厚生を充実させて、社員教育も充実させてきた、と多数の本で言われてきたが、実際の現場で見たことがない。
実際、日本人の大半は中小企業に所属していて、公務員や大企業のような恵まれた環境で働いているわけではない。
たぶん、かなり大手の大企業で羽振りの良い環境に限られていると思う。

日本企業は、年功序列や長期雇用の保証により、社員の忠誠心を保ってきて、それに依存したマネジメントをやってきた。
日本企業は従来のやり方に甘えて、マネジメントスタイルを時代に合わせて変えていく作業を怠ってきた。

しかし、社員が会社への忠誠心を持たなくなった場合、どうやって管理するのか、そのスキルを持っていないだろう。
ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップでは、堺屋太一さんが「米国企業は忠誠心を持っていない会社員を管理する技術を持っているが、日本企業は持っていない。そこで破綻するかもしれない」と言っていたらしい。

実際、日本企業の従業員エンゲージメント調査では、エンゲージメント率が世界的に低いとよく言われる。
たぶんその理由は、日本人マネージャのソフトマネジメントスキルが決定的に欠落していて管理能力が低いこと、日本企業の人事評価制度が従業員の内発的動機に働きかける仕組みや運用になっておらず形骸化していること、があるだろうと思っている。
賃金カットやリストラのための仕組みだと思っているわけだ。
つまり、時代の環境変化に日本企業が追随できていない。
これだけ多様な環境が必要になり、外部環境が激変しているのに、マネジメントスタイルも人事評価制度も日本人に根付いていないわけだ。

【6】僕もそんなチグハグな環境で働いてきた。
IT業界にいる他の人達も同様に悩みながら働いているだろう。

そんな状況の中、IT業界ではアジャイル開発がソフトマネジメントスキルを身につけるのに役立つ技術として認知されているだろうと僕は思っている。
たとえば、Scrumは開発プロセスのフレームワークである一面、スクラムマスターがチームメンバーの内発的動機に働きかけて自律的な行動を促す仕組みを作りだす。
さらに、チームやメンバーを影響させるソフトマネジメントスキルがふんだんに盛り込まれている。
Scrumのコミュニティでは、そういうプラクティス、アンチパターン、事例がたくさん公開されているから、誰もが自分に合ったソフトマネジメントスキルを習得できる環境があると思う。

他にも、日本独特のマネジメントスタイルとして、プロジェクトファシリテーションが20年以上前に提唱されていた。
WF型開発が主流でガチガチな環境の中、日本人マネージャがソフトマネジメントスキルを身につけるためのプラクティス集として公開されていた。
これもそういう流れの一環として捉えることができる。

プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ: プログラマの思索

すなわち、IT業界では、アジャイル開発はソフトウェア開発の単なる一技術ではなく、管理職層のソフトマネジメントスキル習得の一技術として捉えることができると思う。
だからこそ、日本でもアジャイル開発がこれだけ注目されている。
だからこそ、コミュニティで活発にアジャイル開発のノウハウが皆で共有されている。

たぶん、日本人の我々も薄々知っているのだ。
今までのマイクロマネジメントスタイルではやっていけないからこそ、ソフトマネジメントスキルの習得が必要だ、ということを。

【7】では、日本人が身につけるべきソフトマネジメントスキルとは何なのか？

ファシリテーションの本をたくさん漁って読んだ後に改めて、ソフト・マネジメントスキル: こころをつかむ部下指導法 | ロッシェル カップを読み直して気づいたことがある。
身につけるべきソフトマネジメントスキルは、たとえば、コーチング、カウンセリング、ネガティブ・フィードバック、ポジティブ・フィードバックなどがある。

それらソフトマネジメントスキルは、タスク志向のスキルとメンテナンス志向のスキルで分類できる。
タスク志向のスキルは、コーチング、カウンセリングのように、目標達成しようとするメンバーを助言・支援したり、悩みを持つメンバーに対して、求められる仕事の水準や基準を提示して動機づけして成果を出させる。
つまり、モチベーションが高いがスキルが低いメンバーにはアドバイスして後押しして成果を引き出したり、モチベーションの低いメンバーには動機づけして、低レベルの状態から、普通に力を発揮できるレベルへ元に戻し、普通の成果を出させるように助言する。

一方、メンテナンス志向のスキルは、ネガティブ・フィードバック、ポジティブ・フィードバックのように、メンバーの行動に対し問題点や改善点を指摘して是正処置を行ったり、メンバーが良い行動をすれば感謝の気持ちを伝えたりして望ましい行動を促進させる。

そういうソフトマネジメントスキルがリーダーに求められるわけだ。
そういうスキルを言語化して、人を動かすヒューマンスキルが身につけられるわけだ。
たぶん日本人にはそういうソフトマネジメントスキルが足りないと言われているのだろうと思う。

ディープラーニングではなぜ微分が重要なのか？

ディープラーニングではなぜ微分が重要なのか？
とても初歩的なメモ。

【参考】
最短コースでわかる ディープラーニングの数学 | 赤石 雅典

最短コースでわかるディープラーニングの数学 増補改訂版 : 赤石 雅典: 本

【1】ディープラーニングの理論で使う統計の考え方がわかっていなかった。
原因として、ディープラーニングに入る前に、ロジスティック回帰でまずつまずいているのが分かった。

最短コースでわかる ディープラーニングの数学 | 赤石 雅典を読んで、ようやく理解できた。
増補版が出たので、今なら、最短コースでわかるディープラーニングの数学 増補改訂版 : 赤石 雅典を読むといいと思う。

では、ディープラーニングではなぜ微分が重要なのか？
ディープラーニングの基本には、ロジスティック回帰の考え方がある。
ロジスティック回帰を求める時に、損失関数Lの最小値を求める必要があり、そこで合成関数の微分が使われるからだ。

こんなロジックの流れになる。

【2】たくさんのデータを収集した時に、入力値→出力値を予測したい。
まず、単回帰を考える。
回帰直線は、y=ax+b。
一般化して、y=w_0 * 1 + w_1 * x_1　とみなす。
回帰直線を求めるには、最小二乗法を使う。
損失関数Lは、微分して0になる値を求めればいい。

【3】単回帰ができれば、説明変数を増やして重回帰を考える。
一般化して、y=w_0 * 1 + ・・・　+w_n * x_n　とみなす。
同様に最小二乗法を使う。
損失関数Lも同様。

【4】次に、2値分類を行いたい。
ロジスティック回帰に当たる。
教師ラベルが振ってある前提で、入力値→出力値では、0か1を出力する。
正しいか、間違っているか。

ここで、回帰の考え方を使いたいが、そのままでは出力値は0 or 1にならない。
そこで、Sigmoid関数を使って、出力値を0～1の範囲に抑える。
出力値は確率とみなせる。
損失関数Lの最小値を求めるのに微分するが、この時に、合成関数の微分を使うわけだ。

【5】さらに、多値分類を求めたい。
ロジスティック回帰に当たる。
入力値→出力値では、0～mを出力する。
どこかのカテゴリに入っている。

ここで、同様に回帰の考え方を使いたいが、そのままでは出力値は0 or 1にならない。
そこで、Softmax関数を使って、出力値を0～1の範囲に抑える。
出力値は確率とみなせる。
損失関数Lの最小値を求めるのに微分するが、この時でも、合成関数の微分を使うわけだ。

【6】ディープラーニングでは、ロジスティック回帰を元に、さらに隠れ層が加わる。
隠れ層の関数では、ReLU関数を使う。
その他は多値分類と同様。

こういう流れがあるわけだよね。

【7】CNN、Attention、Transformerなどはもっと複雑になるが、単純であるがロジックさえ分かれば、後は同じ。
ちょうど、NANDのろじっくさえ分かれば、後は、NANDで複雑な回路を作れば、CPU、さらにはGPUになるのと同じ。

解析力学、電磁気学、量子力学、特殊相対性理論、一般相対性理論も同様だろう。
基本的なアイデアを理解できれば、後はロジックを付け足して、複雑性を増していくだけ。

製造業がRedmine導入で必ず聞く3つの質問～MS Project派がRedmine導入で悩むこと

製造業でRedmineを導入すると、必ずぶつかるのが「MS Projectの代わりになるのか？」という壁。
製造業の現場は、工程管理と階層的な進捗管理が前提。
Redmine導入で問われるのは、機能ではなく運用思想の違いだった。
製造業の現場がRedmineに求める本当の期待を整理する。

【参考】
コンサル一年目が学ぶこと ビジネススキル本

入門Redmine第6版

逆引きでわかる！ Redmineハンドブック バージョン5.0対応 | 川端 光義 |本 | 通販 | Amazon

Amazon.co.jp: Redmineによるタスクマネジメント実践技法 : 小川 明彦, 阪井 誠: 本

Amazon.co.jp: チケット駆動開発 : 小川 明彦, 阪井 誠: 本

【1】とある製造業界のメーカーにRedmineを初めて導入しようとした時、3つの質問を受けた。
これらの質問に回答しながら、質問の背景にはどんな構造があるのか？と考えた。

【2】バージョンはガントチャートでツリー構造に表示できるのか？

答えはYes。
Redmineのガントチャートでは、プロジェクト＞バージョン＞チケットの順にツリー構造に表示される。
彼らの意図には何があるか？

製造業では、基本的に、月次レベルの大日程計画というマスタスケジュールを作る。
マスタスケジュールはマスケともよく言われる。
そのマスケから、週次レベルの中日程計画、日次レベルの小日程計画へ詳細化していく。
それらスケジュールは、マスケに書かれた工程をベースに詳細化するので、工程管理する方針になる。
たとえば、設計工程、発注購買工程、製造工程、みたいになる。

つまり、彼らは、スケジュールを工程管理の道具として扱い、工程の進捗を管理したい。
その時に、工程という大枠での予実管理の視点、あるいは日々の作業レベルの日次進捗として管理したい。

注意点は、バージョンに何を当てはめるのか？になるだろう。
僕ならアジャイル開発の観点になるので、バージョンに工程を当てはめる。
工程には必ず期日があるので、ロードマップ画面で各工程ではどのタスクをやるべきか、が一目で分かる。

しかし、製造業ではツリー構造で5階層、10階層と深く階層化したい欲求があるので、バージョンだけでは足りない。
結局、バージョンを使わず、チケットのツリー構造だけで管理する方針になりやすい。

ただし、Redmineの標準機能では、ガントチャート画面で大日程に当たる工程へ折り畳みできない弱点がある。
しかし、解決策があり、LycheeRedmineを入れると、折りたたみが可能だ。

例えば、
設計（大日程）
├─ メカ設計
├─ エレキ設計
├─ ソフト設計
└─ プロセス設計
の状態で ▼ をクリックすると
親チケット（大日程）
のように、子チケットを非表示にして親チケットのみの一覧表示にできる。

つまり、LycheeRedmineを入れれば、大日程計画から小日程計画まで、一つのガントチャート画面で整理できるメリットがある。
彼らは、ガントチャート画面で全てを把握したい欲求がある。

【3】MSProjcetからRedmineへ簡単に移行できるか？

答えはYes。
ただし工夫がいる。
MSProjectからExcelへエクスポートし、Redmineチケットのフォーマットに合わせる必要がある。

また、Redmine標準のCSVインポート機能では、親子チケットのようなツリー構造でインポートできない。
親チケットNoが最初は採番されていないからだ。
そこで、Excelチケット一括のようなツールを使って、採番した親チケットNoを入れ直すなどして数回インポートする手順になるだろう。

Excelからチケットを作成・更新できる「Redmineチケット★一括★」 | Redmine.JP Blog

彼らの意図には何があるか？
たいていの大手製造業では、Redmine導入前では、MSProjectを使って、まさに大日程計画から小日程計画までスケジュールを組んでいた。
彼らにはその資産、ノウハウがたくさんある。
だから、その資産であるMSProjectファイルを流用したい。

注意点は、MSProjectでやってきた運用方法をRedmineにも適用できるか？という点があるだろう。
たとえば、MSProjectでは、ベースライン機能がある。
つまり、PJ計画時、仕様変更時、のように、当初のマスタスケジュールを変更する時に、スナップショットを残し、変更管理プロセスに乗せる。
あるいは、週次で実績を記入し、週次でスナップショットを変更履歴として残す。
そうすれば、いつでも前回差分により、予実管理しやすくなる。

Redmine標準機能にはそんな機能はない。
しかし、Lychee Redmine には MS Project のようなベースライン機能がある。
しかもこれは単なる概念ではなく、ガントチャート上で「計画時点のスケジュールを保存し、現在との差分を比較する」機能として実装されている。
つまり、Redmine上でも、日次・週次レベルで差分表示する運用にすれば、朝会や週次定例などで進捗報告にも使えるだろう。

【4】チケットではタスクとタスク内のチェックリストの違いは何か？

答えは、タスクは他人へ委譲できる作業。
チェックリストは自分だけの作業手順。他人に見せるものではない。

LycheeRedmineには、チェックリスト機能があるので便利だ。

彼らの意図には何があるか？
タスクをチケットで切っていく時、チェックリスト機能もあるので、どこまで詳細化すればいいのか迷う時が出てくる。
詳細化レベルは個人の能力に依存するので、いくらでも細かく切れる。
すると、個人レベルの作業手順まで分割してしまうだろう。
そうなると、チケット枚数が増えてチケット管理が煩雑になりやすい。

本来のチケット管理は、作業の引き継ぎ、作業の割り振りのように、自分の作業を他人に委託できるレベルにすべきだろう。
細かくするほど、余計な情報になりノイズになるからだ。

つまり、チームメンバーの能力が全員高ければ、ある程度荒い粒度のチケットで回せる。
しかし、個人の能力が低いほど、細かいチケットを切らざるを得なくなる。
細かい作業レベルでしか、結果を出せないからだ。

だから、チケットは引き継ぎや委託できるレベルの粒度とし、細かい作業手順はチェックリストに落として、必要であれば親子チケットで分割すべきだろう。

【5】そんなことを考えると、製造業特有のチケット管理の特徴が出てくるだろう。
彼らのスケジュール管理には、工程管理がベースにある。
その工程管理は階層構造でツリー構造で管理したい欲求がある。
だから、MSProjectと似たような管理がしたい。

そこから、Redmineのバージョンやかんばんを使ったアジャイルな開発スタイルと相性があまり良くない。
本来は、Redmineはアジャイル開発の基盤に実装されるべきだと思うが、Redmineは機能がとても柔軟なので、従来のようなWF型開発でも実装できる。
ハイブリッドな開発も目指せるだろう。

つまり、経営層や管理者にはWF型開発をやると見せかけて、実際の現場ではチケット管理でアジャイルに開発すればいい。
その辺りのやり方も考えてみたい。

愛憎のUML～なぜ「設計図」は消え、「スケッチ」として生き残ったか

「UML」という言葉を耳にしなくなった今、なぜ一つのツイートが10万超の閲覧を記録したのか。
そこにはエンジニアたちの深い愛憎と、理想と現実の乖離がある。
時代が求める「モデル」の形はどう変容したのか。
重厚長大な開発から俊敏なWeb開発へ、設計図からスケッチへと姿を変えた、その生存戦略に迫る。

【1】なぜか、下記のツイートがバズって10万件以上の閲覧、1千件近いいいねがついた。
僕もなぜバズったのか理由も分からない。
単に記事のリンクを貼って、自分用のメモにしただけ。

(1) Xユーザーのakipiiさん: 「これ面白い。なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？｜pdfractal https://t.co/gMUjbOYO7X #zenn」 / X

【参考】
なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？

イントロダクション：複雑化したUMLを救え | 日経クロステック（xTECH）

UML再考: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 | 増田 亨 |本 | 通販 | Amazon

改訂新版　良いコード／悪いコードで学ぶ設計入門 ―保守しやすい　成長し続けるコードの書き方 | 仙塲 大也 |本 | 通販 | Amazon

UML モデリングのエッセンス 第3版 | マーチン ファウラー |本 | 通販 | Amazon

ドメイン駆動設計をはじめよう

【2】なぜ、UMLの記事がバズったのか？
理由は、皆、UMLに愛や憎しみがすごく溜まっているので、的確に分析した記事に思わず反応してしまったのだろう。

オブジェクト指向が流行っていた時代、モデリングといえばUMLだった。

UMLを積極的に使っている人は、プログラミングできるだけでなく、モデリングも重要という認識を持ち、非常に高い能力を持つ人が多かったのではないかと思う。
しかし、理想と現実の狭間が大きすぎた。

しかし、UMLで作った設計ドキュメントと実際のソースコードに乖離があり、同期しづらく、労力が掛かる割にはメリットが少なかった。

下記のツイートに一番共感できた。

(1) XユーザーのDr.K Laboratoryさん: 「@akipii Rational Roseを使ってRUPを実践する中でブループリントとしても、双方向ツールのTogetherを使ってプログラミング言語としても経験した身として、身につまされる思い。 RUPは一定以上の規模のプロジェクトだとかなり良かった。 Togetherは使い物にならず。 ファウラーが正しかったという結論かな。」 / X

【3】なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？の記事で、非常に優れた分析だと思う点は、リリース周期の長さと厳密なモデル設計がトレードオフである点だ。

SaaSのようなWebサービスであれば、リリース頻度は1日数回、あるいは何万回もデプロイまでしているだろう。
よって、動くソースコードとモデルを同期するメリットよりも、無駄なコストがかかるというデメリットの方が上回る。
なぜならば、リリースサイクルが極端に短すぎるために、モデルを書いてソースコードを自動生成して同期させる作業がリリース速度に間に合わないからだ。

したがって、動くソースコードそのものが設計書、モデルそのものになる。

一方、UMLのようなモデルが生き残った領域は、重厚長大な産業領域だ。
たとえば、車載ECU、医療機器、防衛装置のように莫大な費用がかかり、ISOのような認証や監査が必要な領域では、モデルとソースの一貫性が求められるからだ。
たしかに、ECU開発ではAUTOSARが事実上の業界標準であり、要件からモデル、ソースコードまでのトレーサビリティを一気通貫で管理できる

しかし、とても重たいプロセスだ。
現場で見ていて、やり方は綺麗だが、設計者も開発者もトレーサビリティの維持にたくさんの労力をかけていて、膨大なドキュメントを作って監査を通す作業に時間を費やしている。
正直見ていて楽しいと思えそうな作業ではなかった。

【4】他方、平鍋さんがイントロダクション：複雑化したUMLを救え（2ページ目） | 日経クロステック（xTECH）で述べているように、、現場でのUMLの利用方法を「スケッチとして（UML as sketch）」「設計図として（UML as blueprint）」「プログラミング言語として（UML as programming language）」の3つに分類して、UMLの生き残りを図る考え方もある。
その結果、なぜ、2000年代には巷で耳にした「UML」を現在では全く耳にしないのか？の記事の通り、「スケッチとして（UML as sketch）」だけが生き残り、UMLという言葉と関係なく、モデリングという行為そのものが普及したのが現状ではないだろうか。

たとえば、MermaidやPlantUMLのように、MarkdownやテキストでUMLのモデルそのものが簡単にかける環境では、AIにプロンプトで指示すれば、簡単にモデルを描くことができる。
アーキテクチャドキュメントやアーキテクチャデシジョンの1つの資料として、生き残ったのではないだろうか。

そんなことを思うと、UMLは当初の意図から違った歴史を経て、未だに生き残っていると言えるだろうと思う。