AIエージェントとastahが変える真のモデル駆動開発とは何か

20年前のモデル駆動開発の理想が、AIでついに現実できる気がした。
AIエージェントがastahで描いたUMLとソースコードを同期する「Superpowers-UML」プラグインについて、考えたことをラフなメモ書き。

【参考】
オブジェクト指向でなぜつくるのか 第3版

Pythonではじめるクリーンアーキテクチャ　SOLID原則／ドメイン駆動設計／テスト駆動開発を実践 (impress top gear) | Sam Keen, 株式会社クイープ |本 | 通販 | Amazon

UMLモデリングの本質 第2版 | 児玉 公信 |本 | 通販 | Amazon

Amazon.co.jp: UMLモデリング入門 : 児玉 公信: 本

図解即戦力 UMLのしくみと実装がこれ1冊でしっかりわかる教科書 | 株式会社フルネス 尾崎 惇史 |本 | 通販 | Amazon

XAstahさん：「ユーザーの一人が、Obraの「Superpowers」エージェントスキル用の拡張機能であるSuperpowers-UMLをリリースしました。これで、Astah Pro + Claude + Astah Pro MCPプラグインを使用して、AIエージェントがUMLモデルでソフトウェアを設計できるようになります。Superpowers-UMLのインストールはこちら：https://t.co/6WuXX9nP0f #AIagents #SoftwareDesign」 / X

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

Xユーザーのakipiiさん: 「Astah Pro + Claude + Astah Pro MCP Plugin を組み合わせて、AIエージェントがUMLモデリング＋Javaプログラミングまでやってくれるみたい。AIエージェントがどこまでモデリングとプログラミングの作業を代替してくれるのか？」 / X

Xユーザーのakipiiさん: 「@sana_ailovetaku 仰る通りモデルとコードが同期して連動する観点はメリットですね。２０年前のモデル駆動開発が本来やりたかったことはモデルからソースコードを吐き出して同期させて構成管理する事だった。ようやく時代が追いついてきた印象です」 / X

【1】astahとAIエージェントでモデル駆動開発させるプラグイン紹介が面白かった。

（引用開始）
Superpowers-UMLはSuperpowersを改良し、AIエージェントがUMLモデリングを通じて設計を行うソフトウェア開発ワークフローを実現します。

超能力に関する主な変更点：

AIエージェントは、ソフトウェア設計[1]を含む仕様をUMLモデルとして表現します。
ユーザーとAIエージェントはUMLモデリングを通じて仕様と設計を共同で改良します[1] 。
AIエージェントは、ユーザーが承認したUMLモデルに基づいて実装計画を作成する。
AIエージェントは、実装されたコードと一致するようにUMLモデルを修正します。
このプロジェクトはフックやサブエージェントといったClaude Code固有の機能に依存しているため、Claude Codeのみがサポートされています。
[1] : 将来的には、仕様と設計の成果物は分離される可能性があります。
（引用終了）

【2】20年前のモデル駆動開発と、Superpowers-UMLの違いは何なのか？

20年前のモデル駆動開発では、UMLモデリングツール上でモデルを手作業で描いた後に、ソースを自動生成してシステム開発するやり方だった。
この手法の弱点は2つある。

1つ目は、仕様変更の取込が非常にやりにくいこと。
ちょっとずつ仕様変更を取り込んでソース自動生成してコンパイルしてリリースして、という手順が当時の開発環境ではかなり時間がかかった。
一番嫌なのは、モデルと同期する必要があるためにソースコードを直接変更できないことだ。
よって、フィードバックループそのものに時間が凄くかかっていた。
だから、WF型開発のように、事前に要件や仕様をガチガチに決めた後にモデルを確定して、ソース自動生成させるやり方がほとんどだったように思う。
正直、モデル駆動のありがたみがあまり感じられなかった。

2つ目は、モデルの構成管理、変更管理がやりにくいこと。
モデルの差分を見たいのだが、モデルそのものはバイナリファイルだったり複雑なXMLなので、それらを履歴管理しても、実際のモデルのどの部分が変更されているのか分かりづらい。
人間が理解できるモデルの差分が見たいのに、その表現力がモデリングツール上では弱かった。
ちょっとしたレイアウトの差分を見たいわけではないのに。

【3】しかし、Superpowers-UMLのようなClaudeCodeとAIエージェントの組み合わせにより、ようやくモデル駆動開発が真の意味で実用的になってきたように思える。
つまり、「AIが設計モデルを理解し、モデルとコードを同期させながら開発を進める」という高度なモデル駆動開発が実現可能になったことだ。

AIエージェントが単にテキストを生成するだけでなく、「UMLモデルを介してソフトウェア設計を行う」というワークフローを定義している。
つまり、astah*が持つモデル情報、たとえばクラス図、シーケンス図などをAIが読み取り、修正・追加を自動でやってくれる。
そして、AIがUMLモデルをベースラインとしてソースコードを自動生成してくれる。
一方、ソースコードの変更を直接やっても、AIがモデルにその変更を取り込んで、AIがUMLモデルとソースコードの1対1対応を保証してくれる。

エンジニアは、ソースコードを直接触ってもいいし、モデルを触ってもいい。
モデルとソースコードの同期はAIが保証してくれる。

【4】AIエージェントがモデル駆動開発を保証してくれるなら、どんなメリットがあるのか？

エンジニア観点のメリットは、膨大なソースコードを逐一見る必要はなく、蒸留されたモデルをによりシステム構造を手早く理解でき設計の判断ができることだろう。
AIエージェントがUMLを介して構造を理解しているため、開発者は「どのクラスがどの機能に責任を持つか」を視覚的なモデルを通じてAIと会話できるので、認知負荷を下げられる。

AIがUMLダイアグラムをリアルタイムで更新・チェックするため、設計書が古くなる「ドキュメントの形骸化」を防げる。
また、モデルに基づいたコード生成により、設計意図を正確に実装に反映できる。

開発者同士のレビューでも、モデルを通じてコミュニケーションできるので、曖昧さを排除し、会話を促進してくれる。

【5】そんなことを考えると、モデル駆動開発の理想がようやく時代に追いついて来たと言えるだろう。
プログラミング作業はほぼ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の回答を読む限り、アーキテクチャモダナイゼーシヨンには下記の観点があるらしい。
・技術視点よりも、組織戦略や経営戦略の観点で組織とアーキテクチャ最適化を重視
・「大規模刷新プロジェクト（革命）：よりも、「進化的アーキテクチャ」を重視
・「リバースエンジニアリング」という単なる「負債の返済」よりも「資産の再構築」を重視

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

製造業のDXの鍵はPLMにあり！図解でわかる製造業バリューチェーンの正体

製造業のDXを勝ち抜く鍵は、分断されたデータの統合にある。
CRM、PLM、ERP、SCM。
これら基幹システムの真の連携構造と、今なぜPLM導入が急務なのかを、現場感覚に基づいた図解を元に、書いてみる。
ラフなメモ書き。

【参考】
誰も教えてくれない「SCM計画立案・遵守」の疑問 あなたの会社の生販在（PSI）計画は機能していますか？ | 本間峰一 |本 | 通販 | Amazon

誰も教えてくれない「生産管理システム」の正しい使い方 | 本間 峰一 |本 | 通販 | Amazon

誰も教えてくれない 「工場の損益管理」の疑問 | 本間峰一 |本 | 通販 | Amazon

誰も教えてくれない ｢部品工場の納期遅れ｣の解決策 | 本間峰一 |本 | 通販 | Amazon

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

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

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

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

【1】製造業のシステム連携はどのような構造になっているのか？

製造業のシステムは、CRM→PLM→ERP→SCMの流れに沿って、製造業の業務を支えている。
それぞれのシステムの役割は異なる。

下記の図が非常に分かりやすかった。

【2】CRMでは、営業マンが顧客の引き合いから受注までを管理する。
１つの顧客に対し、引き合いは複数件ある。
見積もりが発行されて、見積もり番号が採番される。
そこから受注が確定すると、製番番号が採番されて、PLMに引き継がれる。

業務によっては、１製番に対し複数の見積もり番号が集約されるケースもある。
このケースは、完全リピートの受注だろうが、過去の製番をベースにするが新規に製番番号を発行する場合が多いだろうと思う。

一方で、１つの見積もり番号から複数の製番に分割される場合もある。
このケースは、製品が大規模で複雑なので、製番を分けることで製品設計や製造をやりやすくする単位にすることがあるだろう。

【3】PLMでは、設計部門が製番を元に製品のコンフィグレーションを作成して、製造工程に渡すための詳細な設計書や手順書を作成する工程を管理する。
製造業では、設計部門の技術力がコアコンピタンスになるケースが多いだろう。

つまり、独自の製品を作って付加価値を付けるために、設計資産を蓄積する必要がある。
だから、PLMのように設計資産を蓄積し、活用するためのDBが必要になる。

PLMでは最終的にE-BOMを作り出す。
このE-BOMが、ERPにおいて生産計画や所要量展開で使うM-BOM、保守サービスで使うS-BOMの元ネタになる。
それらもPLMで一元管理したい欲求がある。

【4】ERPでは、生産管理部門が製番ごとに生産計画を作り、製造部門が生産計画に基づいて製造する。
SCMでは、購買部門が生産計画に基づいて必要な部品を発注して手配する。

ERPでは、M-BOMを整備するのが重要。
SCMでは、購買用のP-BOMを整備するのが重要。

ERPでは、MRPが最も重要な機能の一つになるだろう。
しかし、「」で語られているように、受注生産が主体である日本の製造業には、MRPは向いていない印象を持っている。
生産量の変動が大きすぎるために、生産管理部門の現場担当者が、工場を走り回って何とかやりくりしているのが実態ではないだろうか。

【5】製造業のバリューチェーンにおいて、CRM・PLM・SCM・ERPの重要度の比重はどのような関係になるのか？
下記の図が分かりやすかった。

PLM in Enterprise IT Domains | Rahul

plmvalue.jpg (446×270)

バリューチェーン上では、
設計＝PLM、CRM
製造＝ERP、SCM
出荷後の保守サービス＝ERP、CRM
が主体になるみたい。
これは、僕が現場を見た感覚と同じ。

【6】PLMとERPは何が違うのか？

PLMは、製品の構想から廃止に至るまでの設計資産を一元管理するシステム。
ERPは、製品の生産、製造が主体だが、在庫、購買、工程計画、生産スケジューリング、倉庫管理と配??送、人事、財務、サービスなど、製造およびアフターサービスプロセス全体を管理するシステム。

下記の記事が分かりやすかった。

PLM対ERP ? 競争か協業か？ | ラフル

30年前にERP導入ブームがあったと聞く。
実際、その後、製造業の基幹系システムにERPパッケージ製品導入、あるいは、ERPの自前システム構築がよくあった。

【7】そして、最近ではPLM導入ブームが多い気がする。
それはなぜか？
たぶん、今の時代では製造業もDX戦略を実行せざるを得ないが、肝心の製品データや設計資産が現場担当者の頭の中にあったり、CADデータのように社内に散在しているために、まずデジタル化を目指す必要があるからだ。
デジタル化を推進するためにPLMが必要になったからだろう。

製造業を支えるシステム設計、DX戦略については今後もウォッチしていく。

製造業はなぜ機能別組織に固執するのか？IT業界との対比で見えたDXの壁

なぜ製造業は機能別組織に固執するのか。
IT業界との対比から、DXを阻む専門性の壁と組織変革の鍵を解き明したい。
考えたことをラフなメモ書き。

【参考】
すり合わせの優位性は健在か？日本の製造業が直面するPLM活用とMBSEソフトウェア運用の理想と現実: プログラマの思索

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

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

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

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

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

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

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

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

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

「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい: プログラマの思索

製造業の品質管理の背後にあるSDCAという考え方をソフトウェア開発に適用できるのか: プログラマの思索

【1】自動車、半導体、機械装置などの製造業の業界を見てくると、IT業界とは違った景色が見えてくる。
僕が違和感を持つ点は、製造業はなぜ、機能別組織にあんなにこだわるのか？

【2】IT業界であれば、最近はアジャイル開発に向いた組織構造にするのが当たり前だ。
技術革新のスピードが速く、環境変化が速すぎるために、組織構造も従来のWF型開発ではやりづらい。
大規模なソフトウェア開発案件であっても、要件定義に時間をかけるとしても、裏側では、プロトタイプ検証やインフラ環境構築などの並行開発もやっている。

特に最近は、ローコード開発のプラットフォームが揃ってきたので、1億円くらいの開発案件であったとしても、機能を細分化して、今週に要件定義をやったら来週にはプロトタイプを見せる、という開発サイクルで段階リリースしていく手法も多く見られるようになった。

発注したユーザにとっても、自分たちの要件が翌週には形が見えるので、自分たちの現場に特化した画面や機能であるか検証しやすいメリットがある。
開発チームにとっても、ビッグバンリリース後に捌ききれない問合せや障害が多発するよりも、ユーザから早めにフィードバックをもらって手戻りを無くす方が心理的にも楽だし、開発のリズムも整えやすい。

つまり、IT業界ではアジャイル開発が主流になった理由として、アジャイルという開発プロセスがかなり確立してきたこと、さらには、ローコード開発プラットフォームが充実してアジャイル開発を実践できる開発基盤が揃ってきたこと、があるためだろうと考える。

よって、従来のWF型開発のように、インフラ層・DB層・ミドルウェア層・フレームワーク層・アプリ層・UI層のように機能別に特化した組織構造では、アジャイル開発が非常にやりにくい。
部門間のコミュニケーションロスが多すぎる。
よって、アジャイル開発に特化した組織構造にするには、ストリームアイランドチームのように、アプリ層を中心に一つのサービスやサブシステムを作る単位でインフラ層からUI層までをカバーする組織構造のほうがやりやすい。

DevOpsの考え方、クラウドが普及したことにより、技術的にもシステム運用やアプリ開発が一体化した開発プロセスも一般的になってきた。

すなわち、IT業界では機能別組織はアジャイルではなく、縦に一気通貫する事業部型組織に近いストリームアイランドチームが主流だろうと考える。

【3】では、製造業であっても、環境変化や技術革新がこれだけ速いのに、なぜ、製造業は機能別組織にこだわるのか？

製造業にいる人達も、自分たちがタコツボになりやすい傾向を既に知っている。
彼らに聞けば、環境変化や技術革新のリスクを、彼らもよく分かっている。
彼ら自身、機能別組織の欠点は知っている。
しかし、そこから彼らは抜け出せない環境にある。
それはなぜか？

【4】製造業では未だに機能別組織がはびこっている理由は、根深い特性があると考える。

理由は、設計・製造・営業に特化した方が専門知識を蓄積しやすく、効率化しやすい特性が強すぎるからだろうと考える。

たとえば、自動車であれば、たとえEVや自動運転が主流になったとしても、ボディ・エンジン・ブレーキ・サスペンション・タイヤなどのハードウェア部品が必要であり、それらの各部品の仕様や特性には深い専門知識が必要だ。

半導体製造でも、スマホやAIデータセンターに特化したチップを設計して、シリコンの原材料から微細加工したICチップを切り出して大量製造するには、数兆円規模に特化した設備や機械装置、原材料が必要だ。
半導体の各工程に特化した専門知識が必要になる。

つまり、製造業では、各機能に特化した専門知識のレベルが深いこと、さらには歴史も長いことにより、専門化した機能別組織の方が仕事しやすい傾向がある。
機能別組織の方が、専門性を発揮しやすい一方、設計や製造の現場で試行錯誤したノウハウを蓄積することにより、ナレッジを組織が維持管理しやすい。

製造業は、専門性に特化することで、業務を局所最適化しまくって、生産性を上げる方向に向いている。

【5】では機能別組織の弱点は、何があるだろうか？

1つ目は、機能を担当する部署間でコミュニケーションが数多く発生し、コントロールが難しくなる点だろう。
各機能ごとに専門家集団がいるので、他の専門家には言葉や意図が通用しづらい。
その分、無駄なコミュニケーションコストが積み重なりやすい。

おそらく、日本の製造業はすり合わせが上手い、と言っていた理由は、専門家集団同士のコミュニケーションを以心伝心でやれたからではないだろうか。
そんなことを考えると、日本の製造業は、すり合わせという行為をきちんとエンジニアリングできていたのだろうか、と疑ってみたくなる。

【6】2つ目は、機能別組織に特化した製造業の企業は、顧客ニーズを拾いきれず、市場ニーズの変化に弱い点があるだろう。

なぜならば、機能別組織では、営業・設計・製造の部門だけでなく、各部門内の各工程の部署は、自分たちの業務の局所最適化しか考えていないので、製品を利用する顧客までイメージが及んでいないからだ。
これだけ環境変化が速い時代では、顧客ニーズがコロコロ変わるのに、そのニーズを随時反映していくプロセスが機能別組織には取り込みにくいのだ。

特に、各工程の作業担当者は、自分たちの業務を終わらせることしか頭にない。
せいぜい、製品出荷時までしか頭にない。
すると、出荷したらおしまい、という考えになりやすい。

実際、出荷後の保守サービスを担当する部門が製造業の会社では作られていないケースが多い。
いわゆるカスタマーサクセスを担当する部門がないのだ。
だから、保守サービスのノウハウを蓄積したり、出荷後の製品を利用した顧客ニーズを拾い取る業務を担当する部門がないのだ。

一方、特にSaaSを中心とするIT企業では、ユーザのニーズを吸い取る部署があるのが普通だ。
また、サブスクリプションのビジネスモデルが多いので、利用ユーザのニーズに敏感になりやすい傾向があるから、そこからノウハウを蓄積するプロセスも確立しているだろう。

どうしても製造業は硬いビジネスモデルになりやすい傾向がある。

【7】しかし、Software is eating the worldの時代では、製造業も設計資産のデジタル化や、ITを使ったビジネスプロセス改革程度では不十分だ。
機能別組織から脱却して、顧客ニーズを吸い取ってフィードバックループを回すような組織へ変革すべきだろう。
それが、製造業のDX変革で目指すべき形になるだろうと考えている。

RedmineとAIが加速させるタスク管理の未来～蓄積されたナレッジを独自のAIとして活用する可能性

Redmineは単なる管理ツールから、AIの力で「意思決定のパートナー」へと進化を遂げている。
日々蓄積されるチケットは、実は組織独自の最強のナレッジDB。
色々考えたことをメモ。

【参考】
Redmine AI Helperプラグインを更新しました: 2026年2月版

第30回勉強会 - redmine.tokyo

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

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

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント | 株式会社アジャイルウェア |本 | 通販 | Amazon

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

入門Redmine第6版

【1】RedmineAIHelperを使っていると、Redmineに色んな可能性を感じさせてくれる。

Redmine AI Helperプラグインを更新しました: 2026年2月版では、下記の機能追加があった。

・チケットやWikiに添付された画像やPDFなどをAIが分析
・よく使うプロンプトを「カスタムコマンド」として登録
・沢山あるチケットの中から「今日やるべきチケット」をAIが提案
・重複チケットの検索
・チケットの担当者提案
・子チケット自動生成時の担当者選択
・類似チケット検索の範囲指定

OSSならではのこういう細かな機能改善をしてくれるのがいい。

【2】RedmineとAIはなぜ相性がいいのだろうか？

理由は簡単だ。
Redmineに、過去のタスク・課題・障害・問合せチケットの履歴がナレッジDBとして蓄積されているからだ。
その会社、そのチーム、個人特有の情報が蓄積されている。
だからこそ、自分たちに特化したLLMとして使えるわけだ。

こういうAIによる支援機能がRedmineに充実できれば、Redmineを利用するユーザも、Redmineにどんどんデータを入力して使いこなそうとするモチベーションも上がるだろう。
RedmineとAIの組み合わせは、正の螺旋ループ強化として、成長できる余地があると考える。

【3】懸念点としては、企業秘密として管理すべきセンシティブな内容をOpenAI、Geminiなどに食わせるのに難点があることだろう。
しかし、RedmineAIHelperプラグインにはMCPサーバ接続機能があるから、自社のLLMに接続し、自社内で閉じる形で運用すればいいだろう。

RedmineとAIの組み合わせには色んな可能性を秘めていると思うので考えてみたい。