第29回東京Redmine勉強会の感想～今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet

第29回東京Redmine勉強会に参加してきた。
今話題になっているテーマは、いわゆるJTCの中でRedmineをどのように運用しているのか、とAIによるプロマネ作業支援だった。
とてもホットな内容で興奮が翌朝も残っている。
感想をラフなメモ。

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

2025/11/9 第29回勉強会 - redmine.tokyo #redminet - posfie

Jira ユーザー向け 入門ガイドブック | リックソフト株式会社

Jira と Confluence の活用: シームレスなコラボレーションの実現: Jira と Confluence をプロジェクト管理フレームワークに統合するための効果的な戦略 (プロジェクト管理, IT・テクノロジー) | R. Parvin

【1】いわゆるJTCがRedmineを運用している事例では、東芝や三菱電機の事例が発表された。
典型的な日本の大手SIがRedmineをどのように使っているのか、どんな目的で使おうとしているのか、そして、どんな効果や苦労があったのか、具体的な話が多くて面白かった。

発表 #1683: 第29回 講演: 2万人が利用するソフトウェア開発管理支援サービスのご紹介 - redmine.tokyo

発表 #1674: 第29回 LT: JTCでRedmine利用者2700人を実現した手法 - redmine.tokyo

Redmineは、日本ではよく使われているプロジェクト管理ツールと言っていいだろう。
なぜ、日本企業や日本人開発者はRedmineを好むのか？
その理由は以前たくさん考えてた。

僕が持つ仮説は、現場に直結した困りごとを自分たちが手作りでツールを作り込み、自分たち自身で改善していくというスタイルは日本人がとても好きだから、と思っている。
いわゆる現状に即したプロセス改善は、日本人の得意芸と思っている。
日本の製造業で出てくるQCサークル、QC７つ道具、デミングサイクルは、日本のソフトウェア開発にも根付いていると思う。

そこで、中小SI企業だけでなく、JTCのような大手SIの現場でもRedmineを使いたくなってくる。
では、JTCでRedmineを運用し始めると、どのような問題が出てくるのだろうか？

JTCになれば、案件の数は格段に多くなるので、単一のRedmineで全ての案件を管理し統制させるのは難しくなってくる。
なぜならば、案件の種類はスクラッチ、エンハンスメント、パッケージ製品導入、リプレース、PoCなど多岐にわたるために、１種類の標準プロセスでコントロールするのは正直無理があるからだ。

そこで、東芝のように、研究開発部門や品質保証部門がRedmineやGitlab、Jenkinsなどの開発支援ツールを仮想環境で作り、各案件に社内ホスティングサービスとして仮想環境を提供し、自由に使ってもらうような運用が多くなるだろう。
この運用のメリットは、社内案件で使われるプロジェクト管理ツールや開発支援ツールを社内標準として提供できるため、ある程度統制を効かせられること。
また、ツール類が共通なのでノウハウも蓄積しやすい。
実際、東芝の事例では、社内ユーザ会を年数回定期的に開いて、社内で事例を発表して共有したら、社内関係者にすごく評判が良かった、という説明があった。
つまり、ノウハウ蓄積により、社内の組織活性化、生産性向上にも繋げられる効果があるだろう。

一方、各案件ごとにRedmineインスタンスが乱立するために、Redmineのバージョンが古くなりがちで、最新版への移行が難しくなることだ。
東芝の事例では、200個以上のインスタンスがあり、Redmineの主なバージョンは4.2が多い説明があった。

本来は、AIヘルパープラグインやいいねリアクション機能が使えるバージョン6.1へ移行したいだろうが、大量のRedmineインスタンスをVerUpする一括移行は非常に大変だろう。
東芝の事例では、移行作業のためにスクリプトなどで自動化するなど運用上の工夫をされていたが、それでも各メンバーがそれぞれ各案件のRedmine移行作業を担当し、手作業でカバーしていると説明されていた。
おそらく実際は、Redmineのような年2,3回程度のVerUpに追随するように移行作業を実施することは、大量のインスタンスがあるために実現困難なのだろう。

つまり、社内ホスティングサービスでは、運用当初は良くても、その後のVerUp追随が難しく、次第に統制が効きづらくなるデメリットが増えてくる。
たぶんどこかで、損益分岐点が逆転するタイミングが発生するかもしれない。

他方、島津製作所のRedmine運用事例のように、単一Redmineで統制を効かせて、ナレッジ蓄積に効果を上げている事例もあった。
JTCでRedmineを社内展開するときの運用方法の選択基準、スコープ設定で違いがあると、どのような効果や問題点が発生するのか、考えてみたい。

Xユーザーのakipiiさん: 「JTC事例では、 @akahane92のような単一インスタンスによるナレッジDBで全般統制と、なおまえさんの所のような社内ホスティングによる乱立インスタンスによる標準プロセス適用の諸問題の対比が興味深い。この辺りは一度議論を聞いてみたい　 #redminet」 / X

【2】Redmine AI Helper の講演では、AIを使ってRedmine上のプロマネ作業支援できる具体例や、AIヘルパーの内部構造の説明が非常に興味深かった。
興味深い点は2つある。

Redmine AI Helper とそのしくみ 第29回redmine.tokyo勉強会

1つは、チケットの要約機能は、もっと発展させれば、課題一覧から更新分の内容を要約させて、進捗報告書の一つの元ネタに割り当てる事ができること。
この機能を発展させて、健全性レポートという機能がAIヘルパーで提供されていた。
つまり、測定時点のプロジェクトのQCD、いわゆる進捗率の変化、テスト密度やバグ密度、課題件数の推移や優先度の割合、などを進捗報告書として自動生成してくれる。
したがって、経営層向けのプロジェクト進捗報告書作成という管理作業をプロマネはAIに委託できるメリットがある。

他にも、親チケットから子チケットへタスクを自動的にバラしたり、類似チケットを自動検索したり、チケットコメントの自動生成、チケットやWikiで文章を予測して自動補完、誤字脱字チェック機能などがある。
こういうAIヘルパー機能を使えば、顧客相手にチケットでやり取りするときの誤字脱字防止、チケットで即返答、類似バグ調査などにも役立てられるだろう。

Xユーザーのakipiiさん: 「AIヘルパーで健全性レポートを保存できる。さらに差分チェックもできてAIが比較報告してくれる。cronを使えば報告書作成も自動生成できる。プロマネの作業工数削減に繋がる。　 #redmineT」 / X

2つ目は、AIヘルパーを実現する内部構造の解説だ。

Redmine に蓄積されたタスク、システム開発のナレッジを元に、AIがチケットの要約だけでなく、ストーリーチケットからタスクチケット分割を自動生成できたり、診断時点のプロジェクトの品質、進捗、テスト、レビュー状況を報告書としてまとめたりできる。プロマネの管理作業をAIが支援できる。

実際の仕組みはAIエージェントをロール毎に作ってプロンプトを渡して実行してるだけ。
具体的には、Redmine の背後に、AIエージェントが複数立ち上がり、リーダー役エージェントが仮想チャットルームを作り、そこにチケット作成エージェントやRedmineの機能に特化したエージェントを呼び込んで自然言語でやり取りして実行する仕組みだった。

Xユーザーのakipiiさん: 「AIヘルパー内部では、リーダーエージェントが仮想チャットルームを作り、チケットエージェントやリポジトリエージェント、ユーザエージェントなど必要なエージェントを仮想チャットルームに召喚して自然言語で会話しながら、要約したり子チケットばらしとかしてる。普通の開発チームみたい　 #redmineT」 / X

この話を聞いて、別ニュースで、AIエージェントを集めて仮想スクラムチームを作ってシミュレーションした話と似てるなと思った。
つまり、スクラムマスター、プロダクトオーナー、チームメンバーという仮想AIエージェントを作り、仮想スクラムチームを形成して、プロダクトを出していくシミュレーションができるわけだ。

仮想スクラムチームとAIヘルパーのマルチエージェントモデルの違いは、対等なエージェントでチームを作ると人数が増える毎にコミュニケーションパスが増えて無駄があるので、リーダー役エージェントが一括管理する方が仕組み的に良い点になる。
AIエージェントでチーム形成する時、アジャイル観点と違ってマイクロマネジメントの方が優れているのだろうか？

現代ではソフトウェア開発だけでなく、あらゆるプロジェクトでもマイクロマネジメントではなくサーバントリーダーシップによるチームビルディングが推奨されている。
つまり、コマンダーのようなリーダーではなく、チームメンバー自身がリーダーの役割を持ち、自己組織化していく傾向が良いはずだという流れになっている。
しかし、マルチAIエージェントモデルでは、コマンダーが指示するマイクロマネジメントの方が処理性能が良く優れているという設計になっている。

現代のアジャイル開発の流れと従来のマイクロマネジメントスタイルを持つマルチAIエージェントモデルが違う点は何なのか、今一度整理したい。

僕の仮説では、ソフトウェア開発のように、深い専門性を持つメンバーから成り立つ案件では、人間であるリーダーが全ての専門知識をカバーできないため、サーバントリーダーシップを発揮して、意思決定権限をチームに移譲するやり方にならざるを得ない。
一方、単純な作業指示のような案件では、マイクロマネジメント方式の方が簡単で効率もいい。
さらに、AIの場合、リーダー役のAIエージェントは全ての専門知識を知っている前提にすれば、実際の作業実行ロールのエージェントに作業分担させた方が、遥かに効率がいい。

よって、AIがプロジェクト管理に浸透するほど、サーバントリーダーシップよりもマイクロマネジメント方式が優勢になるかもしれない。
サーバントリーダーシップは、情報整理力が劣る人間の集団で必要なリーダーシップに過ぎないのかもしれない。

また、AIヘルパーの内部構造では、
Rails MVC　＞　エージェント抽象化レイヤ　＞　各エージェント　＞　MCP抽象化レイヤ、LLM抽象化レイヤ　＞LLM、MCPサーバ
で設計されていた。
これを見て、エージェントの追加変更やモデルの追加が非常にやりやすいアーキテクチャだな、と感心した。
むしろ、LLMモデルを使った設計はこのような仕組みにならざるを得ないのではないか。

【3】僕は、JIRAによるチケット駆動開発の運用事例を紹介してきた。
久しぶりの講演で実は緊張していたが、話しているとテンションが上って、いい感じで話せた。

How We Operated Ticket-Driven Development in JIRA

たぶん、世界的にはRedmineよりもJIRAの方がよく使われているだろう。
僕は、JIRAは複雑すぎて使いづらく、Redmineの方が好きだ。

僕は、組み込みシステム開発では、タスク管理が複雑な階層化のために運用が難しく、それをJIRAにフィッティングさせて運用するのも難しい、という話をした。

一方、懇親会では、JIRAにアドバンスドロードマップやスキーマ機能を使うとさらに便利になる話を聞いて興味を持った。

Xユーザーのakipiiさん: 「懇親会でJira機能を話し込んだ。アドバンストロードマップがプログラム管理に使えること、スキーマ機能が標準プロセス適用に使える事が分かって収穫があった。JiraはRedmineと異なる機能がまた面白い。　　 #redminet」 / X

Jira Advanced Roadmapsは、製品企画のような計画作成で使う機能と思っていた。
どうやら、複数プロジェクトを横断したプログラム管理で使えるらしい。
JIRAのプロジェクトは階層化する機能がないため、Redmineに比べると不便だった。
おそらくその機能を補完するような機能かなと推測する。

Jira Advanced Roadmaps を使った計画策定を習得する | Atlassian

ChatGPTで聞いたら
「複数プロジェクトの計画・スケジュールを俯瞰的に可視化・調整できる上位プランニングツール です。
Scrum や Kanban チームのバックログをまとめて管理するのに最適です。」
とのことだった。

また、JIRAにおけるスキーマ（Schema）とは、ワークフローや権限、画面構成などをテンプレート化し、複数プロジェクト間で共通化する機能だ。
この機能はRedmineにはない。
アジャイルウェアのプロジェクトテンプレート、チケットテンプレートプラグインに似ているだろう。

JIRAのSchema機能を使いたい場面は、社内の標準プロセスを全案件に展開して統制できることだ。
JTCならば、社内標準の開発プロセスがあり、工程・手順・成果物が明確に定義されたV字モデルを持っているだろう。
すると、社内の全案件は、社内標準プロセスに従わせて、ドキュメントの標準化や作業効率化を目指したい。
そんな時にJIRAのSchemaで社内標準プロセスをテンプレートで実装すれば、各案件に展開すればいい。

運用プロセスに対して、こういうチケット管理ツールの機能フィッティングは面白いので、今後も色々探ってみたい。

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管理もプロセス設計もアイデア発想も全て表現したい

第22回 Redmine大阪の感想 #RedmineOsaka

第22回 Redmine大阪の感想をメモ。

【参考】
2025/9/21 第22回 Redmine大阪 #RedmineOsaka - posfie

Redmine-osaka-022 - Redmine.Osaka

入門Redmine第6版 : 石原佑季子, 前田剛: 本

5年ぶりの開催で盛り上がりを心配したが杞憂だった。
スタッフも参加者もテンションが高くて楽しかった。
東京、岐阜、福岡から参加者が来てくれた。
初めての参加者も若手で数人おられたが、すぐに馴染んで、本音ベースで話せた。

講演内容も多様だった。

【1】前田さんの話では、Ver4以前のRedmineは最新機能が全く取り込まれていないので、早くアップデートしましょうという主張だった。
メンション機能、チケット一覧での検索、フォントサイズやフォントの変更、テーブルタグを見やすくするUI改善が目に留まった。
次バージョンでは、いいね機能もリリースされる。
昨今のスマホのようなUIを取り入れていく改善は、地味だけれども、ユーザ体験をより良くするために重要だと思う。

【2】赤羽根さんの話では、チケット20万件以上、ユーザ数3900人以上の大規模な運用事例。
製造業という非常に縦割り組織の中で、10年以上Redmineを運用して、設計情報をRedmineに蓄積しナレッジ基盤とした運用はすごいと思う。
後で聞いた話では、Redmineをフローの管理、つまりタスク管理や進捗管理に使うのではなく、チケットに設計情報や製品に関する情報だけをどんどん蓄積していく運用に振り切った、とのこと。
だからこそ、10億字以上の文字が蓄積されるわけだし、全文検索エンジンGroongaの必要性が出てくる流れを理解できる。

【3】三浦さんの話では、自分はなぜかドキュメント管理の整備にアサインされるという話から始まって、ドキュメント管理の経験を語られた。
Wikiでナレッジが集約されるメリットがある反面、ドキュメントは負債にもなり得ること、ドキュメントの保守には工数がかなりかかる。
インセンティブや強制力を使って、ドキュメントを残し集約し、検索できるようにする基盤として、Redmineも候補になりうる。

【4】アジャイルウェア様の会場をお借りして本当に楽しかった。
広くて綺麗で、液晶モニタもすごく大きくて、プロジェクタ無しで投影できて素晴らしい会場だった。
ありがとうございました。

【5】Redmineコミュニティの良い所は、講演内容がRedmineの機能紹介やカスタマイズに偏ることなく、運用事例やプロジェクト管理、情シス部門の考え方、ナレッジ蓄積やタスク管理の考え方まで幅広く紹介されること。
このあたりが面白いなと思う。
だからこそ、かなり特殊なコミュニティもかかわらず、テーマが多様なお陰で、コミュニティが長続きしているのだろうと思う。

また次回も開催したいなと思います。

データモデリングとドメイン駆動設計の違いは何か

データモデリングとドメイン駆動設計の違いは何かを考えている。
アイデア段階で書き殴りのメモ。

【参考】
業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

「データモデル大全」は良い本だ: プログラマの思索

システム開発・刷新のための データモデル大 | 渡辺 幸三 |本

達人に学ぶDB設計徹底指南書 第2版 | ミック

【1】問題設定
僕は、データモデリングもドメイン駆動設計もどちらも好きだ。
データモデリングは生産管理や販売管理などの具体的な業務ドメイン知識をベースに、どんなER図を描くべきか、具体的な実現方法まで示唆してくれる。
ドメイン駆動設計は、オブジェクト指向設計をベースに、どんなプログラムに実装すべきかまで具体的な実装方法まで示唆してくれる。

しかし、双方の考え方や価値観には大きな相違があるように思える。
たとえば、クラウド上でシステム構築するのが当たり前の現代では、ドメイン駆動設計はマイクロサービス設計につながる設計手法として再定義されているように思える。
一方、データモデリングの手法は２０年以上前のやり方と全く変わらず、今のシステム設計の文脈で置き換えられる内容が伴っていないために、古臭い手法のように感じてしまう。

【2】データモデリングの観点ではマイクロサービス設計とは何なのか？
では、マイクロサービス設計やドメイン駆動設計の考え方をデータモデリングの観点で言い換えるとどんな説明になるか？
データモデリングはどんな新しい観点をもたらしてくれるのか？

【3】データモデリングのパターンやイディオムは何か？
ドメイン駆動設計ではパターンやイディオムがあって共通言語になっている。
開発者同士で会話する時に認識を共有できる。
たとえば、リポジトリ、集約、境界づけられたコンテキスト、など。

一方、データモデリングでは、関数従属性ぐらいしか概念がなく、モデリングに関する共通言語がないように思う。
だから、関数従属性というメタ的な内容でしか話せず、生産管理や販売管理、会計などの特定の業務領域で具体的な議論にはまり込んでしまい、何かすごいことが分かった気がするのに、それを上手く伝えられていないと思う。
データモデリングでも重要な概念はあるので、パターンやイディオムを提示すべきではないか。
そうすれば、開発者同士で共通言語を用いて議論できると思う。

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

パターンやイディオムとしてあげて欲しいキーワードを挙げておく。
パターン言語にある状況・問題・フォース・解決方法・効果として整理できるはず。

・2次識別子とボイスコッド正規化
　2次識別子はもう一つの主キーなので、ボイスコッド正規化せざるを得ない。

・2次識別子とテーブルの抽象化・統合化
　具体例は動的参照関係、テーブルの派生関係になる

・2次識別子とサロゲートキー
　複合主キーを2次識別子にする

・サロゲートキーと強属性
　2次識別子（代替キー、Alternative key）は強属性（追加されたら削除されるまで更新不可）になる

・派生関係
　たとえば品番、取引先
　オブジェクト指向の継承関係とは異なる観点を明確化したい

・導出属性（作出属性）
　たとえば、在庫数とか
　渡辺式ER図では、導出属性をマスタ（リソース）に配置する例が多い
　リソースやイベントでない場合、サマリテーブルとしてバッチ処理で作る

・イベントとリソースの見分け方
　テーブルをイベントとリソースで区別できれば、ER図での配置基準が明確になる
　イベントには日付がある

・イベントの先行・後続関係の見分け方
　イベントのテーブルに順序関係が発生し、業務フローを書き起こせる
　データモデルから業務フローをイメージできるか
　ER図を見れば、業務フローを具体的にイメージできる
　ER図をベースに、業務フローやDFDを作成できるはず

・サマリテーブル、集計テーブルの作り方
　どのイベントからサマリテーブルや集計テーブルを作るのか？
　DWHの設計手法を整理できるか？

・動的参照関係と暗黙的リレーションシップ
　複数のテーブルを結合したときに、参照関係が発生する
　暗黙的リレーションシップになる
　ER図だけでは読解しづらく、開発基盤の上で動的参照関係を実現するしかない

・時限NULL
　レコード生成時はNULLだが、業務イベントを通じて値がセットされる
　一時的なNULLの項目なので、NULLの項目であっても存在を許す

・再帰構造とLLC
　LLC（Low Level Code）は、再帰となるツリー構造の深さを表す
　LLCを使って再帰構造のロジックをプログラム上で実装しやすくする

・もう1つの再帰構造
　階層構造は入れ子集合を使うと、ツリー構造をRDBに綺麗にマッピングできる

・フィーチャオプション
　テーブルに項目を横持ちで持たせるのではなく、縦持ちで持たせる構造にする
　リソース（マスタ）のテーブル設計で使われる
　◯区分、◯種別が項目で横持ちに増えるのを防ぐ

・制約条件や業務ロジックの表現
　業務のルール、業務ロジックを関数従属性を使って表現する
　業務ルールは、特定の組み合わせや特定の性質で表現される場合が多い
　そういう事象は、レコードという命題で表現されるので、関数従属性として表現されるべき
　渡辺式ER図では推移的関数従属を参照関係を使って上手く排除している

・◯◯区分や◯◯ステータスは状態遷移を表す
　テーブルにある◯◯区分や◯◯ステータスは、状態遷移を表すので状態遷移図を発生させる
　◯◯区分や◯◯ステータスは、開発基盤の上では、条件分岐を発生させる

・ActiveRecordとORマッピング、ORインピーダンスマッチング
　オブジェクト指向プログラミングとリレーショナルデータベースは異なるデータモデルを持つ。
　ActiveRecordはORインピーダンスマッチングを解決する一つの手法

RedmineJapan vol.4の感想part1～Redmine AI HeplerプラグインはRedmineのナレッジ活用を強化してくれる #RedmineJapan

RedmineJapan vol.4で紹介されたRedmine AI Heplerプラグインが素晴らしかったのでメモ。

【参考】
Redmineによるタスクマネジメント実践技法

逆引きでわかる！ Redmineハンドブック バージョン5.0対応

2025/7/25 Redmine Japan Vol.4 #RedmineJapan - posfie

Redmine Japan Vol.4

Redmine AI Helperプラグイン更新

Redmine AI Helperプラグインを公開しました

【1】Redmine AI Heplerプラグインは、RedmineからAI機能をコールして、チケットやWikiの要約などをしてくれるプラグインだ。
今年5月のredmine.tokyoでも講演されていて、参加者の多数がすごく興味を持っていた。

実際はOpenAIやGeminiなど外部のAIへトークンを発行してコールしている仕組みだけだが、AIがさらにRedmineを使いやすくしてくれる可能性を秘めている。

Redmineを長年使い込んでいくと、チケットに過去の作業、障害修正、課題対応などのノウハウがナレッジとして蓄積されていく。
しかし、そのノウハウはそのまま使えるわけではない。
内容が何なのか、ポイントを抽出したり、過去のコンテキストを元に現状の環境ではこういうナレッジになる、という仕掛けがほしい。

要約はAIが得意とする機能なので、要約機能を使えば、現場で使う詳細な進捗報告書を経営層などトップ層へサマリ化、要約して報告書を生成することもできるはず。
たとえば、詳細な障害一覧や課題一覧を見せられても彼らは分からない。
むしろ、どこにリスクがあるのか、現状はどんな評価なのか、を知りたい。
そんな時に、AIの要約機能は使えるはず。

つまり、Redmineにプロジェクト報告書を追加する機能がより具体化できるだろう。

【2】RedmineJapan vol.4ではさらに、edmine AI Heplerプラグインが進化していた。
Redmine AI Helperプラグイン更新の記事の通り、チケットの回答案生成、子チケット作成、プロジェクト報告も機能追加されていた。

チケットの回答案作成は、カスタマーサポートのような定型的な文章を書く場面で有効だろう。
主張したいことを箇条書きで提示すればAIが上手く文章を作ってくれる。

子チケット作成は、プロジェクトリーダーの管理作業を代行してくれるような機能だ。
デモでは、不具合チケットを元に、調査、原因分析、障害対応、検証、リグレッションテスト、デプロイ、リリースなどの子チケットをワンクリックで自動生成してくれていた。
つまり、障害修正のような定型作業では、手順は標準化されているので、その手順に沿ってタスクを詳細化して作成し、それぞれのタスクに担当者を割り振ればいい。
よって、プロジェクトリーダーの管理作業をかなり楽にしてくれるはずだ。

プロジェクト報告では、該当プロジェクトのチケット群をベースに、その時点のプロジェクトの進捗・品質・コストを自動で報告文を生成してくれる。
プロジェクト報告のQCDを数値で評価する機能もあり、たぶん、占いエージェントを作った経験から作られたのだろうか。
また、おれおれ報告というカテゴリもあり、AIが勝手にプロジェクトを診断して、良いか悪いかバッサリ評価した文章を生成してくれる。
遊び心があっていいと思った。

今後、プロジェクト報告機能では、定期的なタイミングでプロジェクト報告の履歴を残す機能も作りたい、と話されていた。
確かに、報告は履歴が重要で、推移を元に比較評価したい。
だから、プロジェクト報告機能の強化は、Redmineがさらにプロジェクト管理ツールとして進化する可能性を大いに秘めていると思う。

【3】RedmineにAIの機能が追加されることによって、何が大きく変わるのか？

やはり、Redmineに蓄積された作業、障害、課題、問い合わせのナレッジを元に、より精度の高いノウハウを蒸留し、抽出してくれることで、プロジェクトリーダーの管理作業や意思決定を支援する仕組みを提供することだろう。

従来のチケット管理システムでは、チケットの更新情報や活動履歴を元に、進捗・品質・コストをリアルタイムに集計できることによって、プロジェクトリーダーの意思決定を支援できる点がメリットだった。
つまり、強力なチケット集計機能がチケット管理システムの主なウリだった。

一方、チケット管理システムには案件や組織特有の情報がチケットとして蓄積されるので、ナレッジシステムにもなりうる。
ナレッジシステムであるからには、いつでも簡単にデータが検索できて、欲しい情報がすぐに得られるようにしたい。
だから、チケット管理システムでは、強力な全文検索機能も重要な要件になりうる。

しかし、全文検索機能はあくまでも文言にヒットするだけであり、本当に欲しい情報を得るには、検索結果から取捨選択する手間もかかる。
そこが弱点だった。

そこで、チケット管理システムにAI機能が追加されることにより、本当に欲しい情報が蓄積されたチケットから蒸留されてサマリ化された情報を取得できるようになる。

つまり、AI機能は、チケット管理システムがナレッジシステムでもある特徴を効果的に利用可能にするはずだ。

しかし、AI機能を単純に機能追加すればすべてが解決できるわけではない。

講演者の@haru_iidaさんが話されていたが、ある案件で担当者をアサインする時、その人の予定表をOutlookで見れば確保できる工数は限られていれば、そう簡単に意思決定できるわけではない。
つまり、Redmineだけでは、本来のリソース管理を意思決定できない。
そこで、Outlookの予定表データをAI機能でアクセスして予定情報を取り込んだり、社内システムや人事システムも取り込んで、より多角的に判断できる仕組みも必要になるだろう。

すなわち、Redmineを情報系基幹系システムとみなすことで、案件管理を強化し、プロジェクトリーダーのチーム運営や意思決定を強化する方向へ進化できるはずだ。

その辺りも今後の発展が楽しみだと思う。