Movatterモバイル変換

[0]ホーム
URL:

プログラマの思索

IT業界に身をおいて、1日の労働後、心に溜まった疑問を一つずつ点検してみる。

2025年11月
日月火水木金土
      1
2345678
9101112131415
16171819202122
23242526272829
30      

Google

  • Google

最近のコメント

最近の記事

Google4

  • Google4

Redmine勉強会

Amazon

  • Amazon検索
    :

Redmine

2025/11/09

第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で社内標準プロセスをテンプレートで実装すれば、各案件に展開すればいい。

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

2025/11/09プロジェクトマネジメント,Redmine,チケット駆動開発,Agile|固定リンク|コメント (0)
Tweet

2025/09/21

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

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


2025/09/21コミュニティ,Redmine|固定リンク|コメント (0)
Tweet

2025/07/31

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

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

2025/07/31Redmine,チケット駆動開発,Agile|固定リンク|コメント (0)
Tweet

2025/06/01

Jiraの機能はTracに似ている気がする #redmine

最近、Jiraを触り始めた。
Jiraの感想は一言で言えば、昔のTracにすごく似ている気がする。

Redmineユーザの観点では、Jiraは非常に使いにくい。
Jiraのどこが使いにくいのか？

使いにくい原因は、Jiraがアジャイル開発機能に特化していること、Tracのような古い機能が残っていることだと思う。

Tracのワークフロー: プログラマの思索

RedmineとTracの機能比較: プログラマの思索

Jira Cloud ユーザー向け 入門ガイドブック第２版 : リックソフト株式会社

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

【1】一般に、JiraはScrumのようなアジャイル開発、カスタマーサポートのようなサービスデスクなどのユースケースに特化している。
Jiraには、アジャイル開発の機能がすでに盛り込まれている。
チケットと呼ばず課題（Issue）と呼ばれている。
課題には、エピック、ストーリー、タスクが既に存在していて、ストーリーポイントのような見積もり項目もある。
課題のビューには、バックログとスプリントバックログが既に存在している。

しかし、一般の日本企業では、WF型開発が主流であり、ExcelのWBSとかガントチャートを使いたい。
結局、リックソフト社のガントチャートプラグインを入れて、Scrumの機能は全く使わず、ガントチャート上でタスク管理している事例がすごく多い。
つまり、日本企業の現場では、実際のタスク管理とJiraのアジャイル開発機能にギャップが発生している。

しかも、日本企業の現場では、Jiraのスプリント機能を使っていない。
スプリントをなぜ使わないのか？

Jiraではプロジェクトを階層化できないため、１個のプロジェクトで１つの大規模案件をアサインする。
すると、１個のプロジェクトに複数チームのタスク管理に使うため、複数チームのタスクが混在してしまう。
だから、複数チームのタスクを区別するために、WBSのトップ階層を各チームに割り当てて、タスクを階層化して使っている。
非常に使いにくいこと極まりない。
Redmineならプロジェクトを階層化できるので、子プロジェクトをチームごとに割り当てることで、タスクを分別できるし、親プロジェクトで横串で横断して管理もできるのに。

しかも、JiraのスプリントはRedmineのバージョンと同様に、１プロジェクトに依存するために、複数チームのタスクに１つのスプリントがアサインされる。
しかし、現場では、チームごとにチーム特有のスプリントを決めたいケースは多い。
大規模案件ではリリースバージョンというメインターゲットが決まっていても、各チームのタスク管理では、各チームごとにこまめにリリースしたいバージョンがあって、それをスプリントにアサインしたいが、スプリントはPJ固有であるために、チームごとにスプリントをアサインできない。

Redmineならば、親子プロジェクトができるから、子プロジェクトでチーム独自のバージョンをアサインできる。
つまり、全チームはアジャイルリリーストレインのごとく、最終ターゲットであるリリースバージョンに向けて作業していく。
ただし、チームごとにリリースバージョンに向けて細かなバージョンを作成してマイルストーンを決定したいし、各チームごとにロードマップを詳細化すればいい。
そういう作業計画がJiraでは非常にやりにくいと感じる。

【2】Jiraのチケット項目には、解決状況というバグ管理システムの遺産みたいな項目がまだ残っている。

たとえば、TracやMantisでも解決状況の項目があったし、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできなかったり、ロードマップの画面に取り消し線でCloseされた意図が表示されない機能があった。

Jiraでも同様に、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできない。
チケット駆動の初心者にとって、チケット完了させるためにはステータスを完了にするだけでは不十分なのはなぜ？　解決状況って何なの？と思うだろう。
Redmineのようにシンプルに、解決状況はステータスと同一視して、無くしてしまえばいいのにと思う。

RedmineとTracの機能比較: プログラマの思索

また、チケット管理ツールで最重要な機能であるワークフロー管理機能は、JiraではUIエディタ上で設定する仕組みになっている。
UIエディタ画面上で、ステータスに先行後続の関係を線で引っ張るのが鬱陶しい。
Redmineならば、状態遷移表のようにステータスの先行後続はチェックボックスをつけるだけなので、状態遷移図をイメージできれば記入しやすいし、事前にチェックリストのように作っておけば間違えにくい。

たぶん、TracのワークフローはINIファイルにPlantUMLみたいに記述するやり方だったが、Jiraもそのやり方を踏襲しているが初心者でも使えるようにUIエディタ上で見た目は分かりやすく表現しているのだろうと想像する。
正直使いにくくて鬱陶しい。

Tracのワークフロー: プログラマの思索

さらに、Tracのチケット集計ビューはSQLで直接書くことができたように、JiraでもJQLというSQLに似た構文を使って、ダッシュボードというビューを自由自在に作れるメリットがある。
Jiraを使う場合、Confluenceとセットで使う場合が多いので、Confluenceにダッシュボードを埋め込んで、Wordみたいにきれいに文書化できる。
この点はRedmineよりも優れている点だろうが、解決状況やワークフロー機能の使いにくさを思い出すと、改めてTracにすごく似ているように思える。

【3】とは言え、たぶん僕がまだJiraを使いこなせていないだけなのかもしれない。
自分がやりたいのは、Jiraでスプリント機能を使って、複数チームのタスク管理をイテレーション単位に管理して、アジャイル開発のペースを実現したいことだ。
その観点でさらに試してみたいと思う。

2025/06/01Redmine,ソフトウェア工学,チケット駆動開発,Agile|固定リンク|コメント (0)
Tweet

2024/12/29

Redmineは組織のナレッジ基盤として実現可能なのか～島津製作所の事例を読み解く #redmineT

redmine.tokyo #27では、@akahane92さんが島津製作所にRedmineを導入し組織のナレッジ基盤として長年運用して成功された事例を講演された。
資料を改めて読んでみて、気づきや疑問もあった。
きちんとまとめたいけど時間がないので、ラフにメモ書きして、疑問形をラフに散らかしている。

【参考】
株式会社島津製作所_研究開発（集団協業と知的生産）の現場を支える、OSS知識基盤システムの導入 - Speaker Deck

Kuniharu AKAHANEさん: 「発表資料 全スライド 85ページ版（SpeakerDeck）です。 Redmine東京＃27、2024年11月9日＠中野 #redmineT https://t.co/52DZPkJfz2 （URL, QRコード は変更なし） https://t.co/QWQYCePqGY」 / X

2024/11/10 第27回勉強会 - redmine.tokyo #redmineT - Togetter [トゥギャッター]

【1】Redmineを導入し成功した事例では、いつも下記のような2つの疑問が問われる。

【1-1】Redmineの機能と、会社として実現したい問題解決の間にあるフィットギャップ

いくらRedmineが有用だといっても、それぞれの会社で抱える問題は個別であり、他事例を安直に移植できない。
Redmineの標準機能で、会社特有の問題をどの範囲までどのレベルまで解決できるのか？

問題解決に対し、Redmineに不足した機能があるならば、どのような手段を使って解決を試みたのか？
それはどのレベルまで解決したのか？

【1-2】Redmineの運用推進を支えるための組織体制づくり
いくらRedmineが有用だといっても、ツールの機能にプロセスは埋め込まれているわけで、そう簡単にユーザに根付くものではない。
Redmineを日々運用して普及を支える組織体制はどのように工夫しているのか？
どのような運用ルールを組み込んでいるのか？

【2】Redmineの標準機能をどのように使っているのか？

ITSの内部構造：

ITSプロジェクト＝PLM(対象装置、製品)毎に作成
ITSプロジェクト毎にメンバーと権限を付与
チケット＝対象装置に関する解決すべき課題
Wiki＝対象装置に関するメンバー間で共有する情報


ITSプロジェクトはどんな観点でどんな単位で割り当てているのか？
ITSプロジェクト＝1製品
プロジェクトの期間は長い
製品が企画されて設計されて、その後製品が販売終了し保守も完全に終わるまで、プロジェクトは続くと推測
そう簡単にプロジェクトはCloseしない
1つの製品プロジェクトに、数年、数十年携わった試行錯誤のチケットが蓄積される
サブプロジェクトに「研究開発　第◯次」が含まれる

Redmineインスタンスは
「分析計測技術ITS」「分析計測事業部ITS Global」の2つ

「分析計測技術ITS」が元々運用されていた
企画部門・開発部門が中心になって、製品企画から開発まで

「分析計測事業部ITS Global」は製品開発後に、製品そのものの製造・販売・サービス保守などと連携するために作られたと推測
インスタンスをわざわざ分けた理由は何か？
製品企画や製品開発までと、設計が完了して量産化体制に入った製品の生産や販売や保守は、情報の観点や管理する観点、部門間の関連度合いも異なる
「情報流通の壁」
販売情報まで企画や設計も含む1つのRedmineに集約する必要はない

プロジェクト数が1千個まで増えている
たぶん、製品寿命は数年以上と長いのでプロジェクトの生存期間は長い
製品が増えればプロジェクトは単調増加する

とはいえ、プロジェクト数が増えても、アサインされるメンバや権限を制御できれば、実作業するメンバは担当プロジェクトしか表示されないので、困ることはない

チケットの対象は？
WBS作業単位から、要求・仕様のストーリー単位
チケットは作業よりも課題
チケットはIssueとみなす
ITSという本来の使い方

チケットの説明欄の文字数が増えている
その理由は明らか
作業レベルではなく、要求や課題の背景、課題解決の試行錯誤まで書き残す

チケットは共有できる研究開発ノート
「後任者の道しるべ」

ナレッジ基盤としてチケット駆動が活用できるメリット
チケット同士の相互リンク
Wikiに技術勉強会などの共有ナレッジを集約

チケットにSubversionの成果物が紐づく
チケットに成果物の履歴もリンクされる
１チケット＝１クリアフォルダ

研究段階からチケットに記録されて、製品開発の担当者にも知見が共有される
試作した結果も研究者にフィードバックされる
研究や開発の相互の担当者にもメリットがある

チケットに添付ファイルを付ける
添付ファイル数が以前より2倍以上に増えている
製品開発に関わる画像やPDF資料が多いのではと推測
チケットにファイルを添付することで、課題の背景や試行錯誤をより説明しやすくなる

チケットの生存期間はどれくらいなのか？
毎週に週次の棚卸しを開催して、3ヶ月以上放置されたら積極的にCloseされている
チケットの生存期間は数週間レベルではないかと推測

チケットは年間で2万～3万件発行されるため、毎月2千件以上発行されると推測
チケット完了率が約80～90％と高いので、1ヶ月以上放置されることはあまりないと推測
チケットの内容が作業レベルよりも製品開発の課題であることから、チケットの難易度はそう簡単ではないと思われるため、チケット完了率の高さが驚き
チケットの作成や更新を担当するメンバーのモチベーションや意識が相当高いと推測


【2】Redmine運用を支えるための非機能要件は満たされているのか？
数千人、数十万チケット、数十テラバイトのデータを維持管理できるRedmine基盤を構築できるのか？

ITSの弱点は全文検索機能

問題点
ITS標準の検索機能はデータ量増加により性能要件を満たせない
検索できる範囲はせいぜいチケットとWikiくらいのみ
検索精度も文字列の一致だけで意味間まで見ていないので、有用な情報を検索できない
真の意味で、情報の追跡可能性を実現できていない

そこで
チケット、Subversion、添付ファイルを全文検索の対象範囲とする
GroongaとRedmineを連携させて全文検索させる

Groongaで Redmineを 高速全文検索 - Rabbit Slide Show

Redmineシステム内の文字列、添付ファイルやリポジトリまで全文検索を対象にしてくれる
スコアベース、畳み込み検索で高精度検索が可能
検索も高性能
元データは未加工、秘匿できている

おそらく、Groongaで定期的に検索対象データをクローリングし、索引を作って全文検索できる仕組みを提供しているはず
全文検索対象の記録文字のほとんどは、Subversionと添付ファイル
PDFやExcel、Word、パワポなどの資料が多いのではないか
それらを全文検索対象にしているはず
全文検索の基盤構築はそう簡単ではないと推測

情報の追跡可能性と非機能要件の確保を実現できたと言うが、3千ユーザ、数十万チケット、数十テラバイトのデータ類を鑑みると、インフラ基盤のチューニングは相当なノウハウが埋め込まれているのではないかと推測
そう簡単に実現できるレベルではない

【3】Redmineの運用推進を支えるための組織体制づくり

Redmineを社内全体に運用推進するための工夫は何か？
組織や体制はどんな構造にしているのか？

数千人の社内ユーザに説明して普及させるには、ITS事務局だけでは推進できない

週次ミーティングでチケット棚卸し
３ヶ月に１度、放置チケットを積極的にClose
問い合わせチケットは、常任モデレータを付けて「見つけてクローズ」

おそらくITS事務局の他に、各部門、各部署に専任のRedmine担当者を付けて、普及推進しているのでは？
そうでなければ、日々の細かな問合せ対応がITS事務局に集中してしまい、運用がパンクする
また、各部署へRedmine運用プロセス訂正通知や指示が流せない
組織をまたがるような指揮命令系統があるのではないか

今後の展望も興味深い
Redmineに蓄積されたデータをAI学習用データとして利活用できるか？

運用後まもなく、構成管理される成果物はDocumentsとSourcesで分類して運用されている
つまり、知識として確定したデータと経験で得られたデータを区別して管理されている
教師データとして使えるデータを区別できている

昨今成長著しいLLMを使えば、会社の事業領域に関する独自データを元に学習させて、学習モデルを作れるはず
過去に販売した製品、今研究中の製品について、AIに聞けば高精度の内容をすぐに回答できるはず
社内の生き字引みたいな人をAIが代用してくれる

こういう取り組みができるのも、Redmineに蓄積されたデータの品質が良いからだろう
チケットや成果物の記録内容の精度が低ければ、いくら学習させても使えない

【4】感想
島津製作所の事例では、@akahane92さんの講演を何度も聞いてきたが、やはりすごいなと思うし、自分もこういう運用をやりたかったなと思う。
Redmineの面白さや醍醐味は、実運用が定着すると、データが自然に蓄積されるので、そのデータを使えば定量的に分析できるし、実験データや研究データとしても使える。
有用なデータを蓄積できていれば、定量分析した内容も有意味になるはずで、いろんな利活用を膨らませることができる。

特に、機械学習などAI活用は全文検索の機能強化にも役立つ。
相互メリットを活かせば、今後も色んな研究に発展できると思う。


[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

入門Redmine第6版 [ 石原佑季子 ]
価格：3,080円（税込、送料無料)(2024/12/29時点)


2024/12/29Redmine,ソフトウェア工学,チケット駆動開発,統計学・機械学習・深層学習|固定リンク|コメント (0)
Tweet

2024/11/24

「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT

第27回redmine.tokyo勉強会で講演された「RedmineのUbuntu+Docker構築への移行」は内容が参考になったと思う。
ラフなメモ書き。

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

発表 #1609: 第27回 講演: ＜RedmineのUbuntu+Docker構築への移行＞ - redmine.tokyo

【1】今回の講演の背景としては、問題意識として、RedmineをCentOSで利用している場合、どのOSへ移行したら安全なのか、容易に移行できるのか、がある。
おそらく、Redmineはフリーで現場で使っているので、OSやサーバも自前で構築する時にCentOSを利用しているケースは非常に多い。
そこで、CentOSはサポート切れになってしまった状況では、セキュリティリスクがあるために、どこかのOSに移行せざるを得ない。
OSSのLinuxOSは数多くあるが、どれが最適であるのか？

さらに、どのOSが最適なのか、そして移行作業としてどれだけの工数や難易度が発生するのか、という問題も発生する。
RedmineというWebアプリ程度なら簡単だろうと思っていると、RubyやOSのバージョン、プラグインとの相性など色んな点で地雷を踏んでしまうリスクがある。

そういう背景を踏まえて、本資料を読み直すと価値があると考える。
本資料では2つの観点で整理できると思う。

【2】1つ目は、本資料では、CentOSからの移行先OSとして、Ubuntsを選択している。
移行要件詳細①を読むと、Ubuntsを選択している理由は明確だ。
s
Ubuntsを選択した理由を品質特性の観点で整理すると下記になる。

リリースの歴史が長く突然停止の可能性が低いこと
　→OSとして成熟しており、信頼性が高いと想定。

LTSの定期的な提供、2年単位の最新版提供により最新の機能が使える
　→最新の機能が使えるので、機能適合性が高いと想定。

Webクライアントとしてのシェアが高くナレッジ豊富
　→障害が発生しても障害解決の知見が豊富なため、信頼性(耐障害性)が高いと想定。
　→Ubunts上では、他のソフトウェアと共存し使用できる知見が多数あるため、互換性が高いと想定。

x86やARM等アーキテクチャを問わず稼働し、汎用性に優れる
　→x86やARM等アーキテクチャなど幅広く移植できるため、移植性が高い。

CentOS互換系のOS特有の機能を使わないのでCLIでよい
　→CLIでメンテナンス用プログラムを作成できるため、保守性が高いと想定。

CLIに慣れる事でLinuxに対する耐性や知見を上げる
　→CLIに慣れれば、UbuntsOSはCLIで操作しやすいため、使用性が高いと想定。

すなわち、信頼性、機能適合性、信頼性、互換性、移植性、保守性、使用性などでUbuntsの品質は高いと分析されている。
品質特性のかなりの数の観点が網羅されており、実際にRedmine移行で成功されたことを考慮すれば、Ubuntsを選択した理由には妥当性があると考える。

もちろん、RockyLinuxなど他のOSも候補に入るだろうが、普及されているUbuntsは移行先の有力候補になるだろうと思う。

【3】2つ目は、本資料では、Redmineの移行を今後も考慮するためにDockerを採用されていることだ。

vSphereの期限切れという事情もあるだろうが、Hyper-VとDockerのような仮想基盤の上にアプリ層を乗せる方が、今後の移行作業もコピーするだけでよく、作業しやすくなる。
「Redmineの移行」ページにソフトウェア構成図が記載されていて、Redmineが乗る基盤が層別に整理されていてイメージしやすい。

また、Dockerイメージを複製することで、移行後の動作検証やプラグイン検証、性能検証なども並行作業で実施しやすくなる。
本資料で注目すべき点の一つは、Redmine本体のDockerイメージ(sameersbn / redmine)とプラグイン込みのRedmineのDockerイメージを区別して準備されている点だろう。

既に準備されているRedmine本体のDockerイメージを利用する理由は、Webサーバやバックアップなどの基本機能が既にあり、プラグイン無しの標準機能がそのまま使えることだろう。
つまり、プラグインを使わずRedmine本体の標準機能だけで使うならば、公開されているDockerイメージをそのまま流用するほうが品質も担保されているし、検証や移行などの作業工数も無駄に使わなくていい。

一方、プラグイン込みのRedmineのDockerイメージはカスタムイメージで独自作成されている。
Lychee RedmineやFull Text Search等のプラグインを使われているそうなので、それらの動作検証を入念に行われたと記載されている。
確かに、プラグインの動作はRedmineのバージョンやプラグイン同士の相性、OSの相性にも依存するため、Dockerのカスタムイメージを作成した方が、プラグインを1つずつ入れて検証OKのDockerイメージを作りやすく、事前検証の先祖返りのリスクもないだろう。

本資料を読むと、View Customizeで改良した部分が動作しなかったり、Lychee Redmineのガントチャートの日本語表示はOSの日本語フォント配置で解決したり、応答速度低下のクレームにはインスタンスのスケールアップやMariageDBのチューニングで改善されたりしている。
やはり移行後には予期しないクレームも発生するので、色々対応せざるを得ない。
そんなケースでもHyper-VとDockerを使っているなら、インスタンスの性能チューニングも簡単だし、Dockerで移植し直すこともできる。

分かってしまえば簡単な内容かもしれないが、やはり実際に移行してみないと分からない時も多い。
そういう試行錯誤された事例として非常に価値ある内容と思う。

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

入門Redmine第6版 [ 石原佑季子 ]
価格：3,080円（税込、送料無料)(2024/11/24時点)


2024/11/24ソフトウェア,コミュニティ,Redmine,ネットワーク・クラウド|固定リンク|コメント (0)
Tweet

2024/11/10

第27回redmine.tokyo勉強会の感想 #redmineT

本日、第27回redmine.tokyo勉強会にスタッフとして参加した。
非常に楽しかった。
ラフなメモ。

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

redmine.tokyoで第二回プロジェクトマネジメントあるある！　#redmineT | マドびっ！ Madosan's View

【0】今回もプリザンター様の会場を利用させて頂いた。
とてもきれいな場所で、映像や音声もきれいで、そのまま懇親会の会場に使えるので、とても素晴らしい会場でした。
いつも本当にありがとうございます。

【1】今回の勉強会はオフラインで久しぶりに約45人も集まってくださり、雰囲気も良くて盛り上がったと思う。
大阪、京都、松江、山梨など遠方から参加してくれた人もいた。
一方、懇親会などで話してみて気づいたのは、初参加の人が多かったことだと思う。

10年以上続けているとどうしても常連さんが多くなり、居酒屋でローカルに盛り上がっている場みたいになって、雰囲気も停滞してしまう。
しかし、初参加の方や若い人が入ってくれると、フレッシュな気分になるし、入りやすいコミュニティの雰囲気も出てくるし、気付きもある。

年2回程度で開催するのが、飽きることもないし、スタッフも準備に苦労するほどでもなく、ちょうどいいのかもしれない。

【2】発表内容は今回も多様だったと思う。
Redmineというプロジェクト管理ツール、チケット管理ツールの機能面、技術面の話だけでなく、情報の追跡性や保持の観点、プロジェクトマネジメントの観点、ISMS運用などの運用の観点もあった。
参加者にはなにか1つは心に残るものがあったのではないかと思う。

第27回勉強会 - redmine.tokyo

講演も盛り上がってしまって、15分ほど延長するくらい濃い内容だったと思う。

【3】最後に告知タイムがあったが、川端さんより、ウクライナにいるRomanさん会社の開発者がアジャイルウェア社と一緒に仕事することになった、とご報告があった。
前回6月の勉強会では、ウクライナ人のRedmine開発者Romanさんのショート動画を紹介した。

第26回redmine.tokyo勉強会の感想～多様性はコミュニティが成功する重要な要因の一つ　#redmineT: プログラマの思索

ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン: プログラマの思索

川端さんのお話では、Romanさんはウクライナに住んでいて、戦争の影響を受けている。
Romanさんの会社は5人の社員がいたが、戦争のために2人になっていて、今も戦争によるインフラの影響を受けながらRedmineの開発をされている。
アジャイルウェア社の技術者とコンタクトを取れたので、今後Redmineに関する開発を一緒に行っていくことになったとのこと。

Redmineというオープンソースのツールの中でもそんなに大きくなく小さなコミュニティであっても、時代の影響、そして世界の状況を垣間見るような事例だったと思う。
少しでもコミュニティから役立ててもらえればと思う。

【4】@netazoneさんが、今年もRedmineアドベントカレンダーを作ってくれました。
興味のある方はぜひ、ご参加してみてください。
一緒に楽しめればいいなと思います。

Redmine Advent Calendar 2024 - Adventar

2024/11/10コミュニティ,Redmine|固定リンク|コメント (0)
Tweet

2024/06/23

Redmineのバージョン設定でプロジェクトの設定方法が違う

Redmineのバージョン設定では、プロジェクトの設定方法が、サブプロジェクト単位、プロジェクト階層単位、プロジェクトツリー単位、全プロジェクトで4つある。
設定内容の違いにいつも迷ってしまうが、redmine.jpで詳細な解説があった。

プロジェクトの設定＞バージョン - Redmineガイド

（引用開始）
共有: バージョンをほかのプロジェクトと共有します。共有すると、ほかのプロジェクトのチケットも割り当てることができるようになります。設定可能な共有範囲は次の通りです:

サブプロジェクト単位: 子孫プロジェクト

プロジェクト階層単位: 直系の先祖・子孫プロジェクト (最上位の親プロジェクトにおいて「バージョンの管理」権限が必要)

プロジェクトツリー単位: 最上位の親プロジェクトとすべての子孫プロジェクト (最上位の親プロジェクトにおいて「バージョンの管理」権限が必要)

全プロジェクト (システム管理者のみが設定可能)
（引用終了）

あるプロジェクトで設定したバージョンを、他のプロジェクトのどこまでの範囲まで設定できるか、を細かく設定できる。
プロジェクトはツリー構造に設定できるので、子孫だけなのか、親や先祖も含むのか、先祖が同じプロジェクトまで含むのか、を考慮する必要がある。

バージョン設定範囲を細かく設定したいケースは、バージョンを複数プロジェクトで使い回したいケースになるだろう。

2024/06/23Redmine|固定リンク|コメント (0)
Tweet

2024/06/18

ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン

第26回redmine.tokyo勉強会で、ウクライナのRedmine開発者が作ったRedmineテーマやプラグインを解説した動画を紹介した。
改めてリンクしておく。

第26回勉強会 - redmine.tokyo

Redmineのテーマはタブレットやスマホを意識して作られたらしい。
プラグインも痒いところに手が届くような機能を提供している。

2024/06/18Redmine|固定リンク|コメント (0)
Tweet

2024/06/15

第26回redmine.tokyo勉強会の感想～多様性はコミュニティが成功する重要な要因の一つ　#redmineT

第26回redmine.tokyo勉強会にスタッフとして参加してきた。
久しぶりに常連や新しく知り合った人たちと話して気づいたのは、多様な属性の人達が集まり多様なテーマで議論するのがコミュニティの醍醐味ではないか、と思った。
ラフな感想をメモ書き。

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

2024/6/15 第26回勉強会 - redmine.tokyo #redmineT - Togetter [トゥギャッター]

プリザンター｜OSSのノーコード・ローコード開発ツール

【1】勉強会の場所は、OSSツールPleasanterを運営しているインプリム様の会場を借りて開催した。
映像、音響も非常に良く、そのまま懇親会の会場で、宅配のピザ、缶ビールやジュースの買い込みもできて、バーのカウンターもあって盛り上がった。
インプリム様には快く会場を提供して頂き、非常に感謝いたします。

今回の勉強会で気づいた内容をメモしておく。

【2】OSSツールPleasanterは、C#で作られたノーコード・ローコードツール。
前回の勉強会で、Redmineと連携してチケット作成などの機能をデモされた。
個人的には、こういうノーコード・ローコードツールは日本人に向いていると思う。
理由は2つある。

1つ目は、データベース設計さえきちんと設計できれば、画面や帳票はプログラムレスで初心者でも開発できること。
つまり、いわゆるノーコードツールはデータベース設計が肝。

データの格納場所は後で安易に変更しづらいし、テーブルに依存した画面設計になるので、テーブル設計がぐちゃぐちゃだと画面そのものも使いづらくなる。
テーブル設計に業務フローやビジネスルールの制約条件を反映するように設計すれば、無駄なロジックを実装する手間も減るし、画面開発も楽になる。

幸いなことに、データベースモデリングの技術は枯れているし、渡辺幸三さんなどの本で優れたノウハウはあるので活用するだけでいい。

2つ目は、日本人は現場で生産性向上のためにプロセス改善、業務改善するやり方に非常に強いから。
以前のメーカーのQCサークルもそうだろうし、Redmineがこれだけ日本各地で使われているのは現場で気軽に使って業務改善するやり方が日本人の気性に向いているから。
よって、ノーコード・ローコードツールのように、業務改善に気軽に使える道具は日本人の気性に非常にマッチすると思う。

たぶん、戦略的にトップダウンで設計や標準化するよりも、現場で改善する方が日本人に向いているように経験的に感じる。
それが日本人の良い点でもあるし、日本人の弱点であるのかもしれない。

【3】@g_maedaさんの講演では、Redmine本の出版に合わせて20年近いRedmineの歴史を振り返っていた。
気になった点は、Redmineの弱点と、その裏返しとなるメリットの観点だ。

特に直近5年ほどは、Redmine本体の機能も枯れてきており、ドラスティックな機能追加はほとんどない。
つまり、Redmineは安定してしたツールであり、一方、少しずつ時代に遅れつつある面も否めないと思う。
backlogやJira、Asanaなどのツールに比べると、機能改善の速度はやはり違う。
その理由はいくつかあるだろう。

JPLを含む少人数の開発体制が変わっていないこと、UI/UXではシングルページアプリケーションのままで画面遷移や画面更新に手間がかかりやすいこと。
チケットトラッキング機能以外に大きな機能追加が行われていないこと。

アジャイルウェアさんも同様の問題意識を持っており、RedmineのUIや機能をドラスティックに変えにくいので自分たちでRedmineクローンを公開し、Redmine本家にバックポートしていく戦略を話されていた。
ウクライナ人開発者のRomanさんも、RedmineのUIを昨今のスマホ・タブレットを意識したテーマに変更してアピールしていた。

一方、LTでも懇親会でも議論されていたが、Redmineの古いUI/UXが逆にユーザに安心感があるメリットもある、と言う。
RedmineのUIは古いと言われるが、逆に15年近くほとんど変わっておらず、使い慣れている。
JiraのようにいきなりUIが変更されるとユーザも混乱しやすい。

Redmineはシングルページアプリケーションでないけれど、画面更新や画面遷移に必要な機能は分かりやすいし、操作に慣れると、勝手に変更される方が戸惑いやすい。
たとえば、汎用機やクラサバの頃のUIのように、画面にたくさんのボタンやテキストが左から順に並んでいて、キータッチで入力する方がやりやすい、と。

すなわち、RedmineのUIが古いと言われるデメリットは、換言すればUIが変更されておらず一貫性があるので、日本人の気性ではメリットの一つでもある。
そういう観点があると知ったのは面白かった。

【4】今日の勉強会で面白かった点は、Redmineという一つのツールで数多くのテーマで議論できる内容があることだ。
今日の講演では少なくとも5つの観点の事例があった。
情シス、プロジェクト管理、ITIL、性能チューニングによるインフラ運用、プラグイン開発やテーマ開発などのようなRuby開発の観点だ。

【4-1】@netazoneさんの講演では、メーカーの情報システム部門の立場から、人事・総務・営業などのバックエンドの業務をチケット化することで、タスク管理の漏れをなくし、作業の経験や反省点を次回の作業に改善するようにナレッジ化していた。
つまり、会社のバックエンド業務を一括管理してナレッジ化するために、情報システム部門がRedmineを効率的に利用して業務改善している事例だった。

【4-2】@madowindowさんのディスカッションでは、プロマネやPMOの立場から、WBSの管理や策定方法、プロジェクト運営でリスクを感じる兆候の管理、たとえば、進捗90％症候群、頑張ります発言などを話されていた。
つまり、RedmineをSIerのプロジェクト管理に適用するやり方になる。

また、@ta_ke_chan_ さんのLTでは、工場での工数管理にRedmineを利用されていた。
つまり、プロジェクト管理のうち、労務管理やコスト管理、原価管理に適用した事例になる。

【4-3】岩崎さんの会社のRedmineプラグインの話は、ITILの観点で、障害チケットをツールが自動起票して漏れなく一括管理し、電話応答する機能まで実装されていた。
つまり、ITILのようなサービス運用やヘルプデスク管理の観点で、Redmineを効率的に利用して業務改善する事例だった。

【4-4】@akahaneさんの事例では、島津製作所の計測機器に関する事業部でRedmineを全面展開し、Redmine単体1つだけで日々の業務を全て管理されている。
その時に、約３千ユーザ、数十万チケットをRedmineでスムーズに運用するために、RubyのJITコンパイラによる高速化、アプリサーバやDBMSなどの性能チューニングを施して、Redmineがバージョンアップしても高速化を実現していた。

この講演の肝は、Redmineにプラグインを入れないだけでなく、Redmine本体には一切手を入れず、Redmineの外側のインフラ基盤だけで性能チューニングを図ることで、高速化を実現していることだ。
つまり、Redmineに関する知識だけでなく、ApacheやDBMS、VM、通信帯域などのインフラ基盤の技術も必要であることを示唆している。
こういう高度なインフラ基盤の知識が必要な理由は、システム計監査やBCP対策で非常に厳しいビジネス要求に対応する必要があったからだ。
RubyやRailsの開発経験だけでなく、インフラ基盤の経験も相当必要なので、かなり高度な運用内容になっている。

【4-5】ウクライナ人のRedmine開発者Romanさんの事例では、自社で開発されているRedmineテーマやプラグインを紹介されていた。
彼のLinkedInのプロフィールを見ると、開発者の経験が豊富であり、Redmineについてかなり知識を持っているのだろうと思う。
また、@mattaniさんの事例では、Gemの依存性に関する知見の話だった。
彼らの講演は、RubyやRails開発などのテーマに属する。

【5】以上のように、たった半日の勉強会に過ぎないのに、Redmineに関するテーマとして全く別々の５つの内容が議論されていた。
どれか１つのテーマなら詳しい人は参加者でも多数いると思うが、これら５つのテーマを全て理解している人は、今日の参加者では非常に少ないのではないだろうか。

だからこそ、他の人の事例を聞くことで、自分たちが経験していない事例を聞いて参考にできて、盛り上がる要素の一つになったのではないか、と思う。

Redmineというたった一つのOSSツールに過ぎないのに、多様なテーマが存在しているということは、Redmineはまだまだ今後も発展できる余地がたくさん残されているのだろうと思う。

【6】最後にウクライナ人開発者のRomanさんのショート動画を紹介させてもらった。

Romanさんを知ったきっかけは、LinkedInで彼から僕に問い合わせがあり、LycheeやRedmica、hosting Redmineをやっている企業とコンタクトを取って日本市場に出たい、とのことだった。
Romanさんは自分の会社でRedmineテーマやプラグインを自社開発しており、それを日本市場で販売したい、そのために手を組める日本企業を探していたようだった。
僕は、@_maedaさんと川端さんを紹介した時に、redmine.tokyoで動画で紹介してはどうかと提案したら、彼が快諾してくて、この企画が実現した。

実際は、彼の動画が届くのは勉強会の１週間前でかなり直前になった。
彼から、5月末からウクライナでは電気が不安定で、動画を作るのに時間がかかってしまって申し訳ないと話された。
その話を聞いたとき、ニュースでちょうど、戦争で発電所などのインフラ設備にミサイル攻撃などがあって大変な時期だった、という話を思い出した。
彼の環境は、非常に大変だけれど、そんな中で、オープンソースのツールRedmineに関わって開発に取り組んでいる。
僕らとは違う環境でRedmineという共通のツールに興味を持っている彼に何となく共感したい気持ちがあった。
僕自身ができること、貢献できることは分からないけれど、コミュニティで共有することで何か連帯できればいいなと思っている。

【7】今日の勉強会では、常連だけでなく、新しく知り合った人たちとたくさん話ができた。
常連だけが盛り上がるのではなく、新しく参加した人たちとオフラインの場で一緒に経験を共有することで、より一層結束も強くなる。

Pleasanterの人たちも、こういうユーザコミュニティを作りたいんですよ、と言っていた。
Pleasanterはノーコードツールなので、パートナーと呼ばれる開発者兼利用者と強い関係がある。
それをベースにビジネス展開できている。
しかし、今のPleasanterコミュニティはビジネス色が強いと思われてしまうデメリットを感じている。
だからこそ、利用者自身がコミュニティを立ち上げて盛り上げてくれるやり方を模索している、と。
そんな話を聞きながら、思ったことは２つある。

１つ目は、Redmineコミュニティが長続きしているのは、熱狂的な利用ユーザがいて、Redmineコミッタやプラグイン開発者、Redmineプラグインやサービスを提供するベンダーの間で、活発な互恵関係があることだろう。
利用ユーザが困った問題があれば、利用ユーザはコミッタに聞いたり、Ruby開発者にプラグインの要望を出したり、有償プラグインではこんな機能がほしいなどを投げかけて、問題解決のメリットを得る。
一方、コミッタやプラグイン開発者、Redmineベンダーは、利用ユーザのニーズを直接聞きだすことができ、それをRedmine本体やプラグインの改善に役立てられるし、有償プラグインや有償サービスによりビジネス化できるメリットを得る。
そういうお互いにWin-Winの関係が成り立っているからだろう。

それは意図して作られた関係ではない。
最初は、利用ユーザがコミッタに声をかけよう、プラグイン開発者に来てもらおう、ベンダーにも来てもらおう、という程度から始まった。
そこから、数多くのやり取りを経て、お互いに信頼関係を築くことができて、あの人なら失礼な行為や不利益な行為はしないだろうという安心感が作れている。
そういう長期的な信頼関係が作れたからこそ、コミュニティが長持ちしているのだろう。

もう一つは、Redmineに関するテーマが多様であることだ。
そして、Redmineの利用ユーザや開発者も日本各地にいて多様性があることだ。
今日の勉強会でも、北海道、京都、大阪、福岡から参加者がいた。
さらにウクライナの開発者も動画を送ってくれた。
多様な属性を持つユーザが集まることで、予期しない化学反応が起きて、より熱狂的になれる。
熱狂的な楽しい経験を一緒に共有し、それを何度も続けていくこで、信頼関係を築いていく。
信頼関係がコミュニティを支えてくれる。
そういう体験がコミュニティ運営の醍醐味だろうと思う。

また、僕がブログにRedmineのアイデアをたくさん書き散らした記事について、すごく参考になったと話してくれた人もいて、非常に励みになった。
その人曰く、Redmineでこんな使い方もできる、あんな使い方もできる、という記事がたくさんあって皆読んでいるから、勉強会で盛り上がるのではないか、と話してくれた。
僕自身は強いミッションや使命感もなく、ただアイデアを書き残して公開しないとなかなか寝れなかったというだけだったのだが、そういう人がいてくれて非常に勇気づけられた。

僕自身は、OSSツールのチケット管理ツールRedmineとモデリングツールastahの２つにこだわりを持っている。
この２つのツールを使ったテーマは今後も考えていきたいと思う。

2024/06/15コミュニティ,Redmine,チケット駆動開発|固定リンク|コメント (0)
Tweet

より以前の記事一覧

クリエイティブ・コモンズ

Google2

  • Google

SNSブックマーク

  • はてな
    このエントリーをはてなブックマークに追加
  • Facebook

講演・執筆した資料

IT本

Google3

  • Google3
無料ブログはココログ
 
[8]ページ先頭
©2009-2025 Movatter.jp