Redmine

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時点)


| | コメント (0)

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

| | コメント (0)

2024/06/23

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2024/06/18

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

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

第26回勉強会 - redmine.tokyo

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

| | コメント (0)

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つだけで日々の業務を全て管理されている。
その時に、約3千ユーザ、数十万チケットを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に関するテーマとして全く別々の5つの内容が議論されていた。
どれか1つのテーマなら詳しい人は参加者でも多数いると思うが、これら5つのテーマを全て理解している人は、今日の参加者では非常に少ないのではないだろうか。

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2024/04/21

Redmineで持ち株管理する事例

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

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

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

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

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

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

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

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

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


| | コメント (0)

2023/12/24

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

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

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

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

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

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

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

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

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

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

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

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

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


| | コメント (0)

2023/12/17

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の使い方はもう少し色々考えてみたい。

| | コメント (1)

2023/11/05

第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月に間を開けて定期的に開催するリズムも心地良い。
また来年も開催したいなと思う。

| | コメント (0)

2023/06/03

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

第24回redmine.tokyo勉強会の感想をラフなメモ書き。

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

第24回redmine.tokyo勉強会(2023/6/3) #redmineT - Togetter

【毎月更新】Redmine リリース前の新機能を先行チェック!チケットのフィルタでOR検索ができる「いずれかを含む」など(2023年4月コミット分) | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック!関連するチケットの番号を複数指定した絞り込みなど(2023年3月コミット分) | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック!オートウォッチ「自分が作成したチケット」の追加(2023年2月コミット分) | Redmine.JP Blog

【1】@g_maedaさんの講演では、Redmineで未リリースだが取り込まれたパッチの機能改善が紹介された。
興味深い機能は、検索機能の強化だ。

チケットのフィルタでOR検索ができる「いずれかを含む」は、チケット項目だけでなく、フィルタ演算子にも適用できる。
たとえば、添付ファイル名の後ろが .png または .jpg で終わるチケットを抽出とか。
チケット一覧でSQLのように扱うことができるだろう。

また、「現在・過去の値、過去の値、履歴に一度もないの3つで検索する」機能も追加された。
使い方の例として、担当者が自分になったことがないチケット、 担当者が過去に自分だったチケット、Closeしたけど過去に自分が携わったチケット、などがあった。
過去レビューしたチケットを検索したい時に、細かな検索条件を追加することで対応できる。

akipiiさんはTwitterを使っています: 「チケットのJournalテーブルを参照して、現在・過去の値、過去の値、履歴に一度もないの3つで検索する。更新日の検索条件を入れた感じかな。OR検索といい、検索の細かい機能改善をやってますね。 #redmineT」 / Twitter

仕組みとしては、Journalテーブルの更新日を検索している。
よって、過去の履歴をより詳細にフィルタリングできるわけだ。
本来は直接SQLを書ければいいのだろうが、こういう機能改善によって、SQLの検索条件をチケット一覧のUIでカバーできるようになったのはありがたいことだ。

一方、Redmineの右上の検索ボックスの機能と全く同じであるため、チケット数が20万件以上になると性能要件に問題が出てくるだろう。

akipiiさんはTwitterを使っています: 「全検索対象テキストの機能は、性能要件は大丈夫なのかな? チケットが数万件、数十万件でもレスポンスは問題ない? インデックスを張ってあるのだろうな。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。Journalテーブルの件数が多くなると遅くなる。検索ボックスの機能と全く同じなので、検索ボックスのボトルネックを感じるなら同じ現象が起きる、と。」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。full_text_searchの検索結果と検索ボックスの検索結果は異なるケースが発生する。クリアコードさんに機能改善を対応してほしいなあという依頼ありw」 / Twitter

RedmineのデフォルトDBはPostgresSQLなので、パラレルクエリを使って、複数のCPUを活用するクエリプランを生成しクエリの応答をより速くする方法がある。
このチューニング方法を使ってもいいかもしれない。

akipiiさんはTwitterを使っています: 「#redminet Oracleのマテリアライズド・ビューみたいな機能を使ってクエリ検索の性能を上げたいアイデアがありました。PostgresSQLならパラレルクエリの機能があるんですね。なるほど。」 / Twitter

第15章 パラレルクエリ

【2】ChatGPTでRedmineチケットを自動作成する方法を試す事例があった。

akipiiさんはTwitterを使っています: 「Redmineの連携方法をChatGPTに聞いてみた。 #redmineT https://t.co/UzMAAe7dCj」 / Twitter

しかし、チケットの内容が微妙で思ったような内容でないらしい。
プロンプトエンジニアリングとか色々テクニックが必要な気がした。

akipiiさんはTwitterを使っています: 「#redminet Redmineチケット作成にも、プロンプトエンジニアリングが必要なのかもしれませんね。」 / Twitter

ボウコバさんはTwitterを使っています: 「@akipii ChatGPTは、知らないことは適当な情報で埋める傾向があるので、知らないことは勝手に決定せず、自分に質問しろと指示する案も出ていますね。」 / Twitter

akipiiさんはTwitterを使っています: 「@bowkoba なるほど、機械の中身は統計処理の推測ですからね。どういう立場で情報がほしいとか、前提条件や制約条件をかなり追加する必要がありそう。」 / Twitter

しかし、ポテンシャルはあるから、ChatGPTで、埋もれたナレッジを再活用するとか、バグチケットに類似バグ調査、過去の類似チケット検索とか、AIで補完してほしいと思う。

akipiiさんはTwitterを使っています: 「Bingに同じことを聞いてみた。埋もれたナレッジを再活用するとか、まだマシかな?? #redminet https://t.co/HKtFgxwrjG」 / Twitter

【3】川端さんから、逆引きでわかる! Redmineハンドブック バージョン5.0対応の紹介。
今までの、いかにも土壇場で作ってきました講演と異なり、Redmineの事例紹介の内容がかなり詳しかった。
たぶん、7千社近い顧客企業の事例を持っているので、Redmineのチケット管理でタスク管理するにはどういう使い方がその企業に向いているのか、かなりノウハウが溜まっているのだろうと感じた。

(1) りょうまさんはTwitterを使っています: 「川端さんが真面目な話してるの、超久々に聞くんだが #redmineT」 / Twitter

Redmineのチケット管理でハマりやすい問題は、いくつかある。
1つ目は、ワークフローの複雑さと親子チケットの階層の深さのトレードオフだ。
講演では、レビュー中というステータスを外し、ワークフローを単純化して親子チケットで対応する方法が紹介されていた。
この手法は、トラッカーの種類を減らし、ワークフローを短縮化する一方、親子チケットの階層を深くしてでも対応することに相当する。
プログラマやガントチャート好きなマネージャはツリー構造に慣れているので、このやり方が向いているかもしれない。

2つ目は、PJで現れる工程やフェーズはRedmineバージョンで使うか、親子チケットで対応するか、というトレードオフだ。
一般に、WF型開発では、Redmineバージョンを要件定義、設計、開発、テストのように割り当てる時が多い。
しかし、このやり方では、システムとしてリリースできるタイミングはPJの最後の1点だけになり、リスクが大きすぎる。

講演では、バージョンを使わず、親子チケットのうち子チケットでフェーズ分けする手法が紹介されていた。
つまり、親チケットは実装する機能とし、子チケットで要件定義・設計・開発・テストごとに作成して、親チケットでタスク全体を管理する。
このやり方であれば、親チケットをどのイテレーションでリリースするか、だけ決めるだけでいい。
WF型開発であっても、小規模な改善が多い案件、保守案件ではこのやり方の方がアジャイル開発に似ているので運用しやすいだろう。

【4】中村さんの講演では、Redmineを外部記憶装置として扱い、少ない脳内メモリを有効活用しようという話だった。
GTDにある「頭の中で動く猿を追い出す」ことと同じだなと思う。

(1) アカベコさんはTwitterを使っています: 「チケットや Wiki などを外部記憶装置と認識、よくわかる。外部記憶、かつ長期記憶で起票とかメモすることで短期記憶のスタックを明け渡すようにしてる #redmineT」 / Twitter

【5】@yukiaさんの講演では、チケット管理ツールを個人向け、チーム向け、組織向けの3階層で分類していた。
個人<チーム<組織の順に、統制や標準化という押しつけが大きくなるイメージだろう。

中村さんの話でも、チケットに記載しない内容として、個人タスク、案件化していない情報などがあった。
だから、GoogleKeep+Redmineを使っているとのこと。
確かに、GoogleKeppならメモやちょっとした履歴にも使える。
つまり、個人のタスク管理、メモ管理としてRedmineを利用する方法は実はあまり議論されておらず、今後、もっと試してみる価値はあるだろう。
僕の直感では、GTDのようなワークフローやUIをRedmineで実装できるかどうか、が鍵を握ると感じる。

(1) akipiiさんはTwitterを使っています: 「タスク管理ツールは3種類ある #redmineT https://t.co/IIOkSESd5Y」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チームのためのツールは課題管理がメイン #redmineT https://t.co/WeJGHxZEAD」 / Twitter

(1) akipiiさんはTwitterを使っています: 「組織のツールはワークフローで統制できること #redmineT https://t.co/bX9m8iwioG」 / Twitter

【6】@ryouma_nagareさんが紹介してくれたpython-redmineは試したみたいと思う。
REST APIはありがたい機能なのだが、チケット全件を取ろうとすると100件という制限があったりして割と面倒。
もっと手軽にデータを扱いたいから。

maxtepkeev/python-redmine: Python Redmine is a library for communicating with a Redmine project management application

【7】@MadoWindaheadさんから、チケット管理システム有識者の集いを開催したい、という要望があった。
チケット管理ツールの同盟を組んで、想いを実現したい、と。

(1) akipiiさんはTwitterを使っています: 「プロダクトマネジメントはプロジェクトマネジメントと確かに違うね。アジャイル開発やSaaSで多いかな #redmineT https://t.co/XSlKg04ykI」 / Twitter

(1) akipiiさんはTwitterを使っています: 「PJ管理ツールと同盟を組んだ #redminet https://t.co/OY0bUqbf3Q」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チケット管理ツールの同盟を組んで、想いを実現したい #redmineT https://t.co/e9sCIQZWCt」 / Twitter

今は色んなチケット管理ツールが有償・無償であり、それらの機能を比較して考えていくと、ああそういう使い方がしたかったのか、そんな利用シーンがあったのか、と気づく時がある。
プロジェクト管理の手法はまだまだ枯れておらず、色んなやり方を試せると思う。

| | コメント (0)

より以前の記事一覧