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によるタスクマネジメント実践技法【電子書籍】[ 小川明彦, 阪井誠 ] 価格：3,608円 (2024/12/29時点) 楽天で購入

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

「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時点) 楽天で購入

第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

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

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

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

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

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

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

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

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

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

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

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

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

第26回勉強会 - redmine.tokyo

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

第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の２つにこだわりを持っている。
この２つのツールを使ったテーマは今後も考えていきたいと思う。

Redmineで持ち株管理する事例

Redmineで持ち株管理するツイートを見かけたのでメモ。
単純に面白いなと思った。

Redmine (+ チケットパネル) の練習がてら、お題としては良くないかもだけど、持ち株を試してみたw pic.twitter.com/asX5INWZAq

— Shion@アプリ実装者(仮) (@shion_engineer) April 20, 2024

Redmineのチケットにそれぞれの持ち株の情報を記載し、ステータスごとにチケットパネルでカンバン風に表示している。
ステータスは、候補、買付注文中、保有中、売却注文中がある。
おそらく、株の候補をリストアップし、ネット証券などで買付し、保有して、配当をもらいながら、最後に売却するという流れなのだろう。

メリットは、ステータスごとに持ち株の状況がわかること。
だが、実際はこれだけは使いづらいだろう。
現在のそれぞれの持ち株の運用損益や評価金額、すべての持ち株のサマリ情報も表示したい。
また、持ち株の運用損益や評価金額の履歴も表示させたい。

すると、ネット証券のAPIを使って持ち株の最新情報を日次で取得し、持ち株チケットに紐づけて、履歴情報を持たせるような仕組みが欲しくなる。
結局、ネット証券会社のアプリの簡易版みたいな機能が欲しくなってくるだろう。
つまり、Redmineのプラグインでそういう仕組みを作りたくなってくるだろう。

ここで、Redmineのチケットは、かんばんやワークフローのようにステータス管理させたい「フロー」の概念と、情報を資産として蓄積させたい「ストック」の概念の２つを持つ。
今回の持ち株の事例は、チケットをストックとして扱う事例に相当するだろう。

チケットはデータでとプロセスの二面性を持つ #redmine: プログラマの思索

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

こういうアイデアは面白いなと思った。
ちょっとしたデータ管理にRedmineを使ってみる事例は色々集めてみる。

チケットはデータでとプロセスの二面性を持つ #redmine

Redmineのチケットとは一体何だろうか？

Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

その他にも、Redmineでは、課題チケットという一つのインシデントという情報（データ）として意味を持たせていたのに、課題を解決する対策の作業手順（プロセス）もチケットとして登録される、というケースがよくある。

つまり、チケットは、ナレッジとして蓄積されるデータのケースと、作業手順として進捗管理されてステータス管理されるプロセスのケースの2つの性質を持つ。

たとえば、課題、障害、問い合わせのようなインシデントは、都度発生したタイミングでチケット登録される。
それらチケットには、当初のインシデントの内容だけでなく、調査結果や作業ログ、解決策や再発防止策も記録される。
最終的には、解決策や再発防止策は、ナレッジとして蓄積される。

チケット管理システムが持つ検索機能によって、それらナレッジはいつでも取り出すことができる。
つまり、チケット管理システムはナレッジデータベースの側面も持つ。

一方、作業チケットは、何らかの目的に対していくつかの作業手順に分解されてチケット登録される。
一般には、親子チケットで管理されるだろう。
作業チケットは作業手順の一部であるから、作業の順序が重要になる。
チケット管理システムでは、作業の順序はガントチャートのような進捗管理機能として実現されているだろう。

つまり、チケット管理システムは、作業手順というプロセスを管理する仕組みが必要なので、必然的にチケットの先行後続関係を表現したり、クリティカルパスを表現したり、作業チケットのステータスを管理する機能が必要になる。
一般にチケット管理システムでは、進捗管理機能はチケット集計機能の一部として実現されるので、今までに知られているプロジェクト管理システムとして普遍化されるだろう。

そんなことを考えると、チケット管理システムでは、チケットはデータであったりプロセスだったりするし、ストック型プロセスで使われるときもあればフロー型プロセスで使われるときもある。

そういう二面性をあえてチケットに持たせることで、より柔軟にプロジェクト管理しやすくする仕組みを持たせているわけだ。

PMO観点でRedmineの使い方とは何だろうか

PMO観点でRedmineの使い方とは何だろうか。
以下は経験を元に、アイデアや妄想をラフなメモ書き。

【参考】
PMO観点でRedmineの使い方とは何か: プログラマの思索

予防型PMOがRedmineでのプロジェクトモニタリング方法を伝授する | マドびっ！ Madosan's View

PMOの役割は、プロジェクトマネージャのサポート役から、プロジェクト管理支援のための事務局、そして、最終的にはシステム監査やIT統制と連動してプロジェクトを第三者的に監査する立場まである。
そういうPMOの立場では、Redmineをどのように使いたいのか？

PMOとしては、プロジェクトが火だるまになる前に事前に状況をキャッチし、プロジェクトのQCDをコントロールできる状態で維持し続けたい。
結局、Redmineからリスクを早めに検知したい。
ではそのリスクはどこから現れるのか？

PMOはプロジェクトの受注段階からリリース完了まで関わることができる前提とする。
そうであれば、受注前のプロジェクト計画を精査して、そこからRedmineにどこまで詳細化できているか、が一つのポイント。
すぐに思いつくのは、スケジュールや工数の観点で、チケット化されているかどうか。

当初計画でどこまでタスクを詳細化してカバーできているか、WBSの粒度はどうなのか。
当初の要員計画からタスクがチケット化されて作業負荷も吟味されて現実的なスケジュールになっているか。
当初計画した工数やマスタスケジュールを元に、マイルストーン単位に無駄なくタスクが落とし込まれているか。

だが実際はすぐにチケット化されているわけではない。
マスタスケジュールのマイルストーン単位に区切られて、直近のマイルストーンまでのタスクを詳細化していくのが現実的だろう。
その単位でチケットに整合性があるのか。
また、Wikiに必要な情報が掲載されているか、も必要な観点だろう。

そして、プロジェクト実行フェーズでは、プロジェクトの活発度合いより不吉な匂いが出ていないか、が一つの目安になるだろう。
チケットの更新頻度、コメントに前兆がないか。
チケットが活発すぎているのか、忙しすぎて逆にチケットに反映漏れが出ていないか。

特に、チケットの種類ごとに内容を見ておきたい。
課題チケットで案件を妨害するような支障は出ていないか。
障害チケットに品質悪化を示す兆候はないか。

プロジェクト計画時点で、システムのアーキテクチャの課題、プロジェクトの目的となる解決した課題と機能要件の実現性、非機能要件のリスクは普通洗い出しているはず。
特に、レスポンス、スループット、ネットワーク通信などの非機能要件とか。
それを念頭に置いて、どこでリスクが出そうなのか、考えていくべき。
特に昨今は、スクラッチ開発よりも、パッケージ製品の導入やカスタマイズ、他社のSaaSや外部システムと連携するアーキテクチャが多いので、開発リスクは以前よりも大きいと感じる。
そういうリスクがチケットに現れていないか、も一つの観点になりうる。

案件の実行中に、定期的にふりかえりをやっていればいいが、実際は忙しくてそれどころではないだろう。
日々の開発の中で小さな課題を一つずつ潰していく。
その活動の履歴がチケットの更新履歴に出てくるはず。

チケットの消化度合い、消化速度、残チケット数も一つのポイント。
当初計画されたチケット枚数から、さらに課題や障害によりチケット枚数が増えたとしても、案件をコントロールできて入れば、チームが消化できる範囲内に収まるはず。
残りの期間とチームの消化速度（実際はベロシティのようなもの）から、バーンダウンチャートで着地点が見えるはず。
それがコントロールできない場合、チームは混乱しているだろう。
特にテスト工程では、障害チケットの解決をどこまでコントロールできるか、が鍵を握る。

PMOは第三者観点の役割なので、プロジェクトを実行するチームを支援するがチームと一体化しない。
第三者の立場で、気づきをフィードバックし、マイルストーンでの上役への報告を支援し、最後のリリースで出荷可能な品質なのか判断を下す。
だからPMOはプロジェクトから見ると余計なお世話の役割であり、嫌われやすい。
しかし、PMOがしっかりしているからこそ、プロジェクトの暴走を早めにキャッチして防ぐこともできる。
この辺りの駆け引きの中で仕事している感じ。

PMO観点でRedmineの使い方はもう少し色々考えてみたい。

第25回東京Redmine勉強会の感想 #redminet

第25回東京Redmine勉強会についてラフなメモ書き。

【参考】
第25回東京Redmine勉強会 - redmine.tokyo

2023/11/5 第25回勉強会 - redmine.tokyo #redmineT - Togetter

【1】前田剛さんによるRedmine5.1の機能紹介。
おそらく目玉機能は、クエリ検索にOR機能が入ったこと、プロジェクト画面やユーザ画面にクエリ検索機能が追加されたことだろう。
チケット一覧のクエリ検索では、SQLライクにかなり複雑な検索が可能になった。

また、全文検索後に、さらにクエリ検索で絞り込む機能も追加された。
利用シーンとしては、たとえば、Issueで検索して全文検索結果が出た後、さらに担当者や期間、ステータスで絞り検索することで必要な情報にたどりつきやすくなる。

つまり、Redmineを長く使い込んでチケット枚数が多い環境ほど、全文検索やクエリ検索の機能強化のメリットが出てくる。
RedmineはナレッジDBであるからこそ、過去の作業履歴から意味ある内容をいつでも検索できる点は重要なポイントの一つだろう。

【2】前橋市役所のRedmine利用事例はRedmineJapanの再演講演。
講演後に4人の質問があった事実からも、この事例に興味を持つ人が少なからずいたことが分かった。

ポイントはいくつかある。
一つ目は、Redmineを運用するためにかなり準備されていたこと。
たとえば、他部署からの問い合わせを受けて、情報システム部門が1次対応し、ベンダーにエスカレーションすべきかどうか判断していること。
ITILの運用を意識しているように見られた。

他には、事業年度ごとにプロジェクトを新規作成していること。
デメリットは、事業年度のプロジェクトに連なる子プロジェクト、チケットがいったんすべてリセットされること。
一方、メリットは、公務員は3年おきに配置転換されて担当がコロコロ変わるし、年度ごとのオペレーションの意義が重要なので、年度末にすべてのチケットを棚卸しするタイミングが発生することもあるようだ。

2つ目は、アジャイル開発のプラクティス、たとえば、KPTによるふりかえりを効果的に利用してプロセス改善活動につなげていること。
3つ目は、他の自治体とも連携してRedmine運用の幅を広げていること。

プライベートクラウドに載せているのでベンダにサーバ運用はお任せしているみたいだが、実運用に注力している点が興味深かった・

【3】RedmineのチケットDBをNoSQLのグラフDBで関連度合いをグラフ化し、関連チケットや類似チケットを表示する機能追加の事例もあった。
特徴は、RDBではチケットの関連度合いをSQL検索するのは時間がかかりすぎるが、グラフDBであれば検索機能もSQLライクに書けて、性能応答もかなり高速であること。
この特徴を活かして、関連チケットや類似チケットをチケット画面に表示する機能を追加したらしい。

レコメンドエンジンをRedmineのようなチケットDBに適用することで、お勧めチケットを表示する機能改善のアイデアは以前からあった。
その場合、機械学習で学習させる事前処理が必要だったが、今回の機能追加では、グラフDBへ格納する事前処理に置き換わった点があると思う。
この辺りのメリット、デメリットを聞いてみたいと思う。

【4】チケット管理システム有識者の集いのパネルディスカッションでは、Redmine・Jira・Asana・Backlogのユーザがパネラーとして意見を述べ合う話があった。

僕が興味深く聞いた点は、3つある。
1つは、プロジェクトとタスクの違いは何か？
プロジェクトは期間や独自性がある点、プロジェクトは引き継ぎの大きな単位、などのツイートもあり、興味を引いた。
やはりプロジェクトの基本は、達成したい目的があり、期間が限定されていることだろう。
実際、市役所での事業年度ごとのプロジェクト、農作業を毎年行う年度のごとのプロジェクトのように、繰返し性や定常業務の意味合いが強くても、何らかの期限を切っている。
そして、そのプロジェクトの作業履歴は過去資産として次年度にも流用する。
そういう観点があると思う。

2つ目は、Asanaのコンサルの方が話されていたが、プロジェクト型の仕事とプロダクト型や定期タスクのようなオペレーションでは、仕事のやり方が異なること。
プロジェクトの仕事はQCD管理が基本。
やはり納期が決まっているので、納期厳守が必須で、それが一番の評価になる。
一方、プロダクト型や定期タスクでは、明示的な納期がないので、日々の改善がタスクになり、プロジェクトという概念があまりない。
評価基準も変わってくる。

3つ目は、Asanaのコンサルの方が話されていたが、プロジェクトに入っているSIメンバーの立場と、既に事業やオペレーションを回しているユーザ企業の立場は異なること。
ユーザ企業であれば、既に事業は回っているし、その事業を強化する課題を一つのプロジェクトに切り出しているだけであって、プロジェクトは一つの部品に過ぎない。
しかし、プロジェクトに入っているメンバーや契約したコンサルは、その中で成果を出そうとするが、その観点が現場寄りであり、ユーザ企業の目線と異なるので、目的や評価が変わってくる時がある。

【5】コロナが終わってオフライン勉強会は3回目だが、盛り上がって楽しかった
Backlog、Jira、Asanaユーザの方から、11月3連休のど真ん中の休日に懇親会までこんなに人が集まるのはすごい、すごい熱気ですね、と言われた。

確かに、北海道、福岡、松江、山梨からも来られている人もいて、本当にありがたい。
また、いつものコアメンバーが盛り上げてくれたし、懇親会で聞くと、土木建築業界のユーザが問題意識を持って初参加されたり、友人紹介で初参加されたり、多様な人が入ってきたのはよかったし、刺激にもなった。

僕も今までたくさんのコミュニティ活動をしてきたけれど、ここまで皆が熱気を持つコミュニティは少ないと思う。
年2回、5月と11月に間を開けて定期的に開催するリズムも心地良い。
また来年も開催したいなと思う。