RedmineのAI支援機能はチケット管理システムにとって重要な要件だ

RedmineとAIの相性に着目し、その可能性を探ってみたい。
チケット入力の負荷軽減や、蓄積された膨大なデータからのナレッジ蒸留など、AI活用はRedmineの利便性を劇的に向上させることができる。
最新の連携事例を交えながら、プロジェクト管理をより進化させるためのAI活用のアイデアを考察してみる。

【参考】
Codex appでAIからプロジェクト管理ツール「Redmine」を操作する方法(1)設定・動作確認編 | Redmine.JP Blog

Codex appでAIからプロジェクト管理ツール「Redmine」を操作する方法(2)議事録からチケットを自動起票する | Redmine.JP Blog

Redmine MCPサーバーの設定と使用方法（VS Code × Codex連携） - ファーエンドテクノロジー株式会社

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

ゼロから作るDeep Learning Pythonで学ぶディープラーニングの理論と実装

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

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

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

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

ゼロから作るDeep Learning ―LLM編 : 斎藤 康毅: 本

【1】RedmineとAIの相性は良いだろうか？
僕は、AIとRedmineは相性が良いと思う。

Redmineの主たる機能はチケットへの入力や更新、そしてチケットから意味を読み取ること。
チケットへ情報を書き込む手間は割と多い。
チケット駆動に慣れないユーザは、そこでつまずく。

また、RedmineにはチケットやWikiにどんどん情報を書き込んで蓄積するほどナレッジが溜まり、有用性が高まる。
しかし、肝心のデータを単純に検索するだけでなく、本質的な意味を長文から読み取るのは面倒。
そこでつまずく人も多い。

【2】そこで、AIを活用すれば、これらの問題はかなり解決されるだろう。

たとえば、日本語変換のように、文字列を入力する時に勝手にAIが自動補完する。
AIが、この人がこの場面ならこんな文章を入力したいのだろうと、勝手に支援してくれる。

あるいは、障害チケットや問合せチケットから、このチケットを要約するとこんな意味です、とレポートする。
あるいは、PJに蓄積されたチケットを元に、週次報告を出力し、プロジェクトの健康診断みたいに報告してくれる。

つまり、AIが入力更新の手間を減らし、AIがナレッジを蒸留させて、色んな場面でレポート出力してくれる機能も提供できるだろう。

【3】なぜAIはRedmineにとってそんなに重要なのか？

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索にも書いたように、Redmineにいくらチケットに情報を書きこんで蓄積したとしても、それを有効活用できなければ、持ち腐れに過ぎない。

その問題解決の手段の一つとして、全文検索の機能強化があった。
もう一つは、AIによる機能強化があげられるだろう。

つまり、AIにより、Redmineへナレッジを書き込む労力を減らし、利用ユーザのモチベーション低下を防ぐ。
また、いつでも簡単に、蓄積されたデータを蒸留させたナレッジが取り出すことができ、そこから、利用者が欲しい情報を手に入れたり、プロジェクトリーダーの意思決定を強化できるはずだ。

よって、Redmineに蓄積されたデータの品質が良く、データ量が多いほど、AIをフル活用させるメリットが出てくる。

RedmineとAIを組み合わせた機能改善は、今色んな人が試している。
@haru_iidaさんのAIヘルパープラグインもある。
ファーエンドテクノロジーさんのCodex appでAIからチケット入力更新を支援する事例もある。
その他にも、MCPサーバーと連携して、SlackやGitHubと連携するやり方もある。

これらの事例や技法は、今後のRedmineにたくさんの活用シーンを広げてくれるだろう。
この辺りのアイデアはもっと考えてみたい。

マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet

現代ではチケット駆動開発は当たり前になった。
しかし今、その運用はマイクロマネジメント化し、タスク管理のはずが管理強化の道具となり、現場の自律性を奪うケースが増えている。
加えて大規模運用の壁も顕在化している。
現場視点で課題と打ち手を具体的に考えてみる。

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

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

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

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

入門Redmine第6版

【1】僕が2008年に「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ 」をKOFで発表してからもう15年以上経った。
現在地点では、チケット駆動開発をベースとしたソフトウェア開発は、アジャイル開発であれ、WF型開発であれ、たぶん当たり前になっているだろう。

redmine-presentation-846109from akipii Oga

では、現在地点におけるチケット駆動開発の課題は何があるのだろうか？
チケット駆動開発のどこに問題が起きているのだろうか？

【2】僕個人の考えでは、2つの問題があると思う。

1つ目は、チケット駆動開発がマイクロマネジメントのツールに化してしまっていること。もう1つは、大規模チームでチケット駆動開発を運用するノウハウがまだ蓄積できていないこと。

前者の問題点は、伊藤直也さんがツイートされている。

Xユーザーのnaoyaさん: 「タスクを細かく洗い出してチケット切って開発みたいなの、自分は基本的に信用してない マイクロマネジメントで作業者から自分で物事を考えて進める思考や責任を奪ってる」 / X

Xユーザーのnaoyaさん: 「チームでざっくり直近の目標を決めて、それぞれの担当領域を決めたらその領域内でどうつくるかは各々に任せる そのうえで作ってるものの過程は成果物をマネジメントするべきで、プロセスをマネジメントしない」 / X

Xユーザーのnaoyaさん: 「2週間とかの期間がある中で、どこで本気出すかは各々の自由だしそれはコントロールできるものでもない マイクロマネジメントはその裁量を奪うだけだ」 / X

Xユーザーのnaoyaさん: 「良いプロダクトは、洗い出したタスクを全部こなしたらできあがるわけではなく、良いプロダクトになるよう仕上げることで出来上がるもの プロセスをマネジメントしすぎると、結果タスクをこなすことにマインドが向かう 良いプロダクトに仕上げることにマインドが向くようマネジメントするべき」 / X

Xユーザーのnaoyaさん: 「良いプロダクトにしようと思ったら、作りながら発見した事実をもとに、臨機応変にやることを変えていく必要がある タスク志向になると、この自分で臨機応変に状況にあわせてやることを変える、という力を奪うことになる」 / X

本来のチケット駆動開発は、タスク管理をプロマネから開発者へ権限委譲し、開発者自身がアジャイル開発をベースにタスクを消化していくことで、ソフトウェアを開発するスタイルだった。開発者の自主性を引き出す効果があった。

しかし、チケットをWBSとみなせばWF型開発にも適用できるので、プロマネが計画時点でPJ計画書に基づいてWBSをチケット化して開発者に押し付ける運用も多く見かける。
つまり、開発者がタスクを考える必要もなく、プロマネがチケットを担当する開発者をマイクロマネジメントするための道具になってしまった。
すなわち、開発者がシステム開発するためにタスクを詳細化していく思考を奪ってしまい、単純労働者の地位に押し付けられている。
こうなってしまうと、チケット駆動開発はアジャイルさを失い、ガチガチのマイクロマネジメントの道具になってしまっている。

【3】では、そんな状態から脱出し、本来のチケット駆動開発の良さを引き出すには何が必要なのか？

そもそも、マイクロマネジメントしたい状況は、特に製造業の工程管理や、ソフトウェア開発の大規模案件でよく見かける。
たとえば、製造業の工程管理では、受注、設計、購買、製造、出荷物流のような工程があらかじめ決まっている。
各工程では、メカ・エレキ・ソフト・品質管理担当などがどんな役割でどんな作業をするのか、ISOの規定に沿ってあらかじめ決まっている。
それらのタスクは、受注した時点であらかじめ確定する。
後は、納期に合わせてスケジュールを作り、担当者の負荷計画を立てるだけだ。
つまり、WF型開発みたいにガチガチの作業管理になるのは必然だ。

しかし、実際の製造業の現場を見ると、設計者も生産管理担当者も3つ4つの製品を担当していて、複数案件をまたがって作業しているのが一般的だ。
つまり、製造業の組織が機能別組織であっても、実際の作業者は複数案件を掛け持ちして兼務しているので、自然にマトリクス型組織になる。
2ボス体制なので、レポートラインが2つ以上あるため、作業者は非常にやりづらい。
製造業の担当者はいつも複数製品の作業で手一杯で、いつも忙しそうにしている。
毎日自転車操業しているようなものだ。

よって、ガチガチのガントチャート管理をしてもすぐに進捗遅延が発生する。
納期間近になってドタバタするのが当たり前だ。

だからこそ、本来のチケット駆動開発の良さを引き出すには、突破的な作業はチケット管理で忘れないように起票して毎日の朝会で優先順位付けすることが大事だと思う。
一方で、製造業では工程管理も重要なので、突発的な作業管理以外にも、工程管理するためのチケット管理も必要になると思う。

つまり、製造業のタスク管理では、突発的な作業管理と工程管理の2種類のチケット管理が必要になるだろう。
マイクロマネジメントになる雰囲気があっても、やるべき作業は見える化し、チームとして対応していく雰囲気づくりは必要だと考える。

【4】後者の問題は、大規模なチケット駆動開発により、管理の複雑性が増していることに起因しているのだと思う。

元々、チケット駆動開発は数人レベルの小規模なチームによる開発経験から生まれた。
だから、少人数で俊敏に開発するアジャイル開発と親和性が高い。
そこから、アジャイル開発のプラクティスを取り入れると開発が上手くいくことが分かり、チケット駆動開発のプラクティスやアンチパターンも色々分かってきた。

また、チケット駆動開発は元々柔軟なワークフロー管理機能を持つので、ITILによるソフトウェア保守、情シスのタスク管理、システム監査、カスタマーサポートなどにも適用できる。
つまり、色んなプロセスをチケット駆動開発で実現できる。そこが、チケット駆動開発の面白さの一つだと思う。

しかし、チケット駆動開発の適用範囲が広がり、ユーザ数やチケット数が膨大に増えていくと、複雑性が増して、単純な運用ルールだけではじきに手が負えなくなる。
大規模なチケット駆動開発では、複雑性を制御するために、何らかの標準プロセスの実装が必要になってくるのだと思う。

では、大規模なチケット駆動開発による複雑性は、どのように解決すればいいのか？

Redmineコミュニティで今までに語られたアイデアの一つとしては、Redmine警察やRedmine職人のような役割を設けたり、定期的な棚卸し会を運用するなど、組織として運用する仕組みを作ること。

他には、大規模アジャイル開発のフレームワークであるLeSS、SAFeなどのアイデアを参考にして、チームやプロセスを階層化して管理する手法もあるだろう。

つまり、チームやプロセスを階層化することで、会議体を整理し、必要な情報がレイヤに関係なく共有できる仕組みづくりが必要だろうと考えsる。

【5】2つのテーマに関するこの辺りの問題点、解決法を整理してみたいと思う。

「資料をそのままAIに食わせたい」を解決するMicrosoft製ツールMarkItDownとは？

AI活用が進むほど増える「前処理の手間」。PDF・Excel・PowerPointの内容をMarkdownに変換できれば一気に楽になるはず。
Microsoftが公開した「MarkItDown」が、そのボトルネックを解消するかもしれない。
リンク先をメモ。

【参考】
多様な形式のファイルを Markdown に変換できるMicrosoft 提供の MarkItDown を試してみた #Python - Qiita

markitdown/README.md at main ・ microsoft/markitdown

Obsidianで育てる最強ノート術

Markdownライティング入門　プレーンテキストで気楽に書こう！ (技術の泉シリーズ（NextPublishing）) | 藤原 惟 |本 | 通販 | Amazon

TAKE NOTES!――メモで、あなただけのアウトプットが自然にできるようになる | ズンク・アーレンス, 二木 夢子 |本 | 通販 | Amazon

Xユーザーのkou@エンジニアさん: 「Microsoftが出してるmarkitdownが地味に便利すぎる！PDFもExcelもPowerPointも、なんでもMarkdownに変換してくれる。LLMに食わせる前処理がこれで全部解決した笑 https://t.co/WYlb58r68Y #AI #個人開発 #ツール」 / X

AI時代では、プロンプトをmarkdownで書く時が多い。
しかも、コンテキストとして前提条件、制約条件をたくさん書く必要がある。
文章がすごく長くなる。
そんな時に、ExcelもPowerpointを添付する時に、テキストの文章でmarkdownで貼り付けたくなる。

まだ試せてないが、今度試してみたいと思う。

なぜ『図解 線形代数: ストラング流直感的理解』は分かりやすいのか？従来の線形代数との決定的な違い

大学で習った線形代数、正直つまらなかった記憶はないだろうか。
しかしAI時代の線形代数はまったく別物だ。
正方行列中心から長方形へ、ゴールも固有値分解から特異値分解へ。
本記事では、図解 線形代数: ストラング流直感的理解を元に、その違いと本質をわかりやすく解説する。

【参考】
図解 線形代数: ストラング流直感的理解 (近代科学社Digital) | 平鍋 健児 |本 | 通販 | Amazon

世界標準MIT教科書 ストラング:教養の線形代数

世界標準MIT教科書 ストラング:線形代数とデータサイエンス

世界標準MIT教科書 ストラング 微分方程式と線形代数

世界標準MIT教科書 ストラング:計算理工学 | ギルバート ストラング |本 | 通販 | Amazon

線型代数学 (数学選書 (1)) (数学選書 1) | 佐武 一郎 |本 | 通販 | Amazon

【1】「図解 線形代数: ストラング流直感的理解」が出版された。
僕もレビューアとして手伝えたので、出版が凄く嬉しい。

僕が大学生の時に使った佐竹一郎の線形代数本（線型代数学 (数学選書 (1))）よりも実践的で分かりやすいと思う。
線形代数のゴールは、昔はジョルダン標準化だったが、現代は特異値分解。
ここから画像の特徴量抽出につながる。
また、昔の線形代数の対象は、正方形の行列だったが、現代では、長方形で縦長や横長の様々な行列に変化した。
AI時代では、線形代数の理解が鍵を握る。
そのアイデアを自分なりに解説してみる。

【2】一般に高校生や大学生は、線形代数を習得するが面白くないだろうと思う。
なぜこんな書き方で計算する必要があるのか、理由がいまいち納得できないからだ。

一般に線形代数は連立方程式を解くための手法の一つに過ぎないと思う。
しかし、単にそれだけではないのだ。

「図解 線形代数: ストラング流直感的理解」は他の巷の線形代数本と違うのか？
それは2つある。

【3】1つ目は、線形代数で対象とする行列が、昔は正方形の行列ばかりだったが、AIが主流の現代では、長方形の行列のように何でもありになったことだ。

昔の線形代数は、量子力学に出てくるエルミート行列にしても、相対性理論のテンソルにしても、基本は正方形だ。
次元数を揃えるのでそうなるわけだ。

しかし、現代では、線形代数は画像を対象に使う。
縦長だったり横長だったりする画像が普通なので、線形代数も正方形でなく長方形が一般的だ。
すると、従来の線形代数のやり方では通用しない場面も多い。
行列のRankを考えると、次元数が少なく、連立方程式でも無数の解が出る場合も出てくる。

よって、昔の線形代数に慣れた人ほど、ストラング本の線形代数を読むと正直面食らうと思う。
昔の線形代数は量子力学のために利用する。
今の線形代数は、データサイエンスや画像の特徴量抽出、機械学習のために使う。
その時に、行列の対象が正方形から長方形へ変わっているからだ。

【4】2つ目は、線形代数のゴールが昔はジョルダン標準化だったが、AIが主流の現代では、特異値分解であることだ。

昔は、正方行列を以下に対角化可能な状態へ変形することに労力をかけていた。
その理由は、行列の積が出る場面が多く、手作業で計算するにはできるだけ対角行列に近い行列に変形しておきたかったからだ。
僕には、昔の線形代数は正直面白くなかった。
ひたすら計算をいかに楽にするか、という点だけ考えるばかりで、線形代数の意義が感じられなかったからだ。

線形代数が一番効果的に使われる分野は、物理学における量子力学だろう。
波動関数を計算する時に、固有値分解を使う。
場の量子論へ向かう過程で、|φ>、<φ|みたいな基底を作って計算する。
そういうお作法みたいに感じる。

しかし、AI全盛の時代では、線形代数の利用対象が、従来の物理学から今は画像処理やAIに変わりつつある。
特に、画像処理の背後では線形代数を使うのが一般的だ。
その画像処理の計算もPythonでプログラミングできてしまう。

佐竹一郎の線形代数本（線型代数学 (数学選書 (1))）のように、線形代数のゴールは固有値分解の最終形であるジョルダン標準形だった。
しかし、AI全盛の時代では、線形代数のゴールは特異値分解になる。
特異値分解があるからこそ、画像圧縮、特徴量抽出の計算が楽になる。
Pythonなら、U, S, VT = np.linalg.svd(X)　の一文だけで特異値分解できる。

たとえば、下記ページから、画像圧縮の特異値分解では、せいぜい100の固有値ぐらいで見た目が変わらない事が分かる。
画像を2倍以上圧縮しても人間の目では判断がつかないレベルになる。

SVD-Demo: Image Compression

個人的には、高校生や大学生の頃に、線形代数の計算の中に、特異値分解を知ることができたら良かったと思う。
そうすれば、画像処理の計算から入って、最終的には機械学習や深層学習の計算に触れることができただろう。
さらに、そこからLLMを自ら計算して作り出すところまでいったかもしれない。

そんな時代を考えると、時代の環境変化に追随して、自分の古い知識や価値観を捨てて、新たな知見を探す旅を恐れてはいけないと思う。

【5】「図解 線形代数: ストラング流直感的理解」の良さは、2つある。
1つは、行列をベクトルの足し算に分解するイメージが湧くこと。
2つ目は、マトリクスワールドの絵で直感的に行列のシュルを理解できることだ。

本がカラフルなのもいい。

【6】AIに必要な線形代数を理解するために、線形代数の攻略マップを描いてみた。
線形代数の攻略マップのイメージはこんな感じ。

the-map-to-conquer-linear-algebra-for-it-engineer-b102from akipii ogaoga

高校生や大学生の頃に習った線形代数と、AI全盛の時代の線形代数は異なると理解した方がいい。
ポイントは2つだ。

AI時代の線形代数は長方形の行列を対象にする
1つ目は、行列は正方行列がメインではなく、長方形の行列が対象になることだ。
理由は、画像を行列に表す時、画像のサイズはいつも正方形とは限らないからだ。
むしろ、縦長だったり横長だったり、長方形のケースが一般的だ。

よって、従来の正方行列に関する対角化、固有値分解の考え方だけでは通用しない。
したがって、A＝LU、A＝CRのように、任意の長方形行列を積分解して、rankを落としたり、正方行列に直したり、色々工夫する。

線形代数を理解するためのゴールは特異値分解だ
2つ目は、線形代数を理解するためのゴールは、固有値分解ではなく、特異値分解だ。

AIでは画像処理で特徴量抽出により、教師なし学習で概念を把握する。
その画像処理では、画像はRGBでMｘNの行列成分で表示されて、特異値分解により画像圧縮して情報量を減らす。
また特徴量は、特異値分解によって得られた固有値、実際は特異値によって判別される。

特異値分解に行くまでの道筋はこんなイメージだ。
基本は実数の世界で考えるので、実数の行列で考える。

任意の行列Aは、AA^{T}が必ず対称行列になるために、対称行列の世界にマッピングする。
直交行列は、線形独立なベクトルから成る行列と見なせばいい。

すると、スペクトル分解により、任意の対称行列は直交行列を組み合わせて、対角化可能になる。
さらに、対称行列の中から半正定値行列を選べば、固有値は必ず０以上の実数になる。

そこから、任意の行列を「必ず半正定値行列のスペクトル分解に帰着させる仕組み」を考えれば、特異値分解になる。
そんな流れ。
たぶん上記の考え方を使えば、スムーズに行くはずと思う。

【7】世界標準MIT教科書 ストラング:教養の線形代数 | Gilbert Strang, 松崎 公紀, 平鍋 健児はとても良い本なのだが、たくさんの内容が書かれていて、最短ルートで本当に知りたい内容を理解するのに時間がかかる。
だからこそ、図解 線形代数: ストラング流直感的理解でまずイメージを理解した方が手際よく読み進められると思う。

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の組み合わせには色んな可能性を秘めていると思うので考えてみたい。