「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

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

『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost

デブキャリで牛尾さんの講演を聞いた。
「世界一流エンジニアの思考法」を出版されている。

Developers CAREER Boost 2023 （2023.12.09）

デブキャリでこっそりシェアする三流エンジニアが『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法

話が上手いし面白い。
牛尾さんには15年以上前にXP祭り関西2006でXP寸劇にも参加して頂いたこともあり、あの頃の雰囲気を思い出した。

Subject: [ruby:1293] XP祭り関西2 006 in ワッハ上方

XP祭り関西2006 in ワッハ上方 (プログラミング C# - 翔ソフトウェア (Sho's))

【告知】XP祭り関西2006 in ワッハ上方: プログラマの思索

牛尾さんの講演の気づきは3つ。

1つ目は、常日頃から職歴を更新して、アピールできるレベルに随時ブラッシュアップすること。
牛尾さんはアジャイルのエバンジェリストでは超一流だったが、自身曰く、プログラマのスキルは低かった。
だから、マイクロソフトでプログラマになるべく、Githubに書いてアップしたり、エンジニアが来日したらAttendeしたり、色々アピールした、と。
そのためにも、職歴に、第三のスキルを常に磨いて記載するようにした、とのこと。
職歴は、LinkedInのプロフィールみたいなもの。
私はこういう人です、こういうスキルがあります、こういう職歴を積んできました、とアピールできるもの。
自分がより良い職業や職場に行きたいなら、そういうアピールできるものが必要。

一方、会社は「こういう人が欲しい」というジョブディスクリプションを出す。
それを見て、そのジョブディスクリプションに応募する。
その時に、会社が提示したジョブディスクリプションに対し、2つ上のレベルを目指すようにする。
そうすれば他人の目を引くことができるから。

牛尾さんほどの優れたエバンジェリストのレベルであっても、地道に努力されているんだなと思った。

2つ目は、何をやらないか、が大事なこと。
Be Lazyと言っていた。

Xユーザーのakipiiさん: 「Be Lazy。何をやらないか。物量よりもインパクトが大事。日本人は勤勉重視、努力重視なので価値観が正反対だよね。染み付いた価値観を捨てるのは難しい。 #devboost」 / X

どうしても日本人は「努力」が好きなので、全部をやろうとしてしまう。
捨てるのが難しい。

物量よりもインパクト重視。
たくさんできるよりも、何か一つ目立つものが成果として出れば十分。
そういう発想が大事。

3つ目は、「チャンスの時に受けないと次に進まない。受けましょう。」

Xユーザーのakipiiさん: 「牛尾さんが最後に伝えたこと。チャンスの時に受けないと次に進まない。受けましょう。つまり、挑戦しましょう。実力がなくても英語力がなくても関係ないと。 #devboost」 / X

今、牛尾さんはマイクロソフトでAzureファンクションのプログラマをされていると聞いた。
そのきっかけは、米国チームから、新卒に教えるのが得意なエンジニアで採用されたのがきっかけ。
そこからチャンスを掴み、今プログラマとしてバリバリ働かれている。
気後れせずに、チャンスをつかめ、というメッセージとして受け取った。

牛尾さんがすごいなと思うのは、40代を過ぎてから、英語を習得し、エバンジェリストからプログラマへキャリアを転換されたこと。
今までの実績や経験をすべてアンラーニングして一からやり直されたのはすごいと思う。
普通は、今までのキャリアやスキルをベースに深めていくのが普通であって、最初からやり直すのは大変。

本当に自分がやりたいことは何なのか、を深く考えて実行されたのだろうと思う。

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

パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai

Jasst関西がオフライン開催だったので10年ぶりに参加してきた。
感想をラフなメモ。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'23 Kansai

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る: プログラマの思索

「大人の学びパターン・ランゲージ」の感想～知識と経験を行ったり来たりするタイミングを大切にする: プログラマの思索

現場の経験知をパターン言語にするコツが分かった　#agileto2014: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

SECIモデルは知識の再利用モデル、または、実践知を生み出すモデルだ: プログラマの思索

【1】今回のテーマは「思考停止」。
正直難しいテーマだったかなと個人的印象を持った。
基調講演の山口鉄平さんの話を聞くと、説明に苦労されている印象があって、本来は「ソフトウェアテストをカイゼンする50のアイデア」本から色んな改善事例を出してもらえるともっと聞きたかったのにと思った。

今の日本の社会情勢であれば、「思考停止」というテーマはたくさんの事象が出てくるだろう。
たとえば、円安やインフレ、少子高齢化による社会保障制度の不安、コロナ補助金不正、マイナンバーカードの名寄せ問題、EV車やAIに対応できていない製造業やIT企業、を見れば「思考停止」の事例はいくらでもあるだろう。
つまり、そういう問題に対し、本来の課題（イシュー）は何なのか、その課題を解決する時に一番効果のある対策は何か、予防策は何か、まで突き止めて考えなければならないのに、前提条件や制約条件を無視した議論がすごく多い。

一般に、日本の組織論で有名な「失敗の本質」本を読めば、日本人の「思考停止」の例はすぐに2つは思いつく。
1つは、個人では意見を持っていても、同調圧力に流されて集団浅慮やリスキーシフトに陥ること。
もう一つは、一般兵士のような下級レベルの労働者や兵士は真面目で優秀だが、戦略の目的に合致しない行動を取っているために、いくら真面目に働いても生産性や投資効果が低いこと。
野中先生が指摘した日本人の弱点は、1945年当時から80年たった今でも変わらない。

akipiiさんはTwitterを使っています: 「日本人が思考停止に陥りやすい例が自分のイメージと違っている気がした。日本人は集団浅慮に流されて自分の意見を言わないとか、一生懸命働くけど生産性を意識せず働く場合が多いんじゃないかな？ #jasstkansai」 / Twitter

こういう思考停止の事例を分析するには、なぜなぜ分析が結局使われると思う。
なぜなぜ分析で自分の言動を問い詰めて、最終的にはその人の油断、プレッシャー、焦りなどの心理背景まで突き止められるのではないか、と思う。

OL参加者の意見として、フレームワーク思考を習慣的な思考と考えて、思考停止になっているのではというツイートもあって面白かった。

akipiiさんはTwitterを使っています: 「#jasstkansai なるほど、フレームワーク思考は習慣的な思考と捉えるのか。SECIモデルならどれに相当するのか？形式知を組み合わせる連結化？形式知を暗黙知にする内面化？」 / Twitter

【2】今日のJasst関西で最も印象に残ったのが、「思考停止からの脱出 ～ あなたの"問い”が自律へと導く ～」ワークセッション。
テーマは「思考停止を題材にして、問題事象をモンスターで書いてみよう」。

「思考停止」というテーマを各人の体験から問題事象を洗い出し、それらの問題事象にモンスターとして名前付けする。
そのモンスターには、名前とモンスターの絵があり、モンスターのプロフィールとして得意技・どんな時・他の特徴という説明文が付与される。
そのモンスターに対し、必殺技でやっつける、という流れ。

僕は「打合せ大好きマン」というモンスターを書いてみた。
伝わるかな？

これはアンチパターンと言えるだろう。
つまり、モンスターの名前はアンチパターン名。
得意技は問題事象。
どんな時は、問題事象が発生するタイミング。
他の特徴は、問題事象の影響事例。
必殺技は、解決策に相当するだろう。
フォースに相当する項目があればなおいいね。

僕もパターンは好きだし、パターンを自分で作れないか、パターンカタログのようなものを作れないか色々考えていた時期があった。
しかし、深く考えるほど難しいなと思う。
モンスターにアンチパターンを当てはめると、ロールプレイングゲームのように気楽な気持ちでパターンカタログを作り出すことができる。

この発想は他のワークショップでも使ってみたいなと思う。
プレインステーションなどのゲーム経験が深い人ほど馴染みやすいかもしれないから。
もっと気楽にパターンを考えてもいい。

【3】久しぶりにオフラインでコミュニティに参加して気づいたことはいくつかある。

1つ目は、参加者に若い人もいるけれど、年齢層が割りと高そうなこと。
アンケートでは、SE経験が10年以上の人が参加者の半分を占めていた。
本来は20～30代の人たちが半分以上を占めていて、経験が少なくてもノリが良くて活気があるのが普通だが、ちょっと落ち着いていた感じ。
久しぶりに会った方と話していたら、最近は若い人が少ないですよ、とのこと。
昨今の日本社会の情勢である少子高齢化が出ているのだろうか？

2つ目は、オンライン開催のチャネルが勉強会コミュニティで必要になってきたこと。
コロナ禍を経て、開催側もオンライン開催の手段がすごく簡単と分かったし、参加者も簡単に集めやすいと分かった。
参加者もオンライン開催であれば、スマホさえあれば作業しながらでも聞ける。
わざわざ交通費を払って時間を拘束させる必要もない。

今後の勉強会の運営は、Jasst関西のようにハイブリッド開催が当たり前になってくるだろうと思った。

デブサミ2023の感想

デブサミ2023の感想をラフなメモ。
自分用のメモ。

【参考】
Developers Summit 2023（2023.02.09-10）

DX、アジャイル、プロセス、テストなどを色々聞いた。
その中で僕が興味を惹いたのは、Rustとテスト自動化の2つの講演。

【1】RustはFirefox、Linux、Androidなどで使われ始めていると聞いたが詳細は知らなかった。

Rustは所有権の概念を持つ。
所有権とは束縛した変数みたいなもの。

Rustは一生コンパイルが通らないと言われる。
理由は、コンパイラが強いから。
そもそもプログラミングが難しい。
代入可能な変数かどうか所有権で決まる
所有権で解決する。
コンパイラが教えてくれる。

Resultはエラーハンドリング。Scalaにもある。
インターフェイスからエラーを返すか判断できる。

OptionはJavaのOptionalと同じ。
ScalaのOptionalみたいなものか。

enumはパターンマッチ。

traitはジェネリクス関数をシュッとしてくれる。
ScalaのTraitと同じ。

「なんでもかんでもclone()をつけたくなってしまいます、どうしたらいいですか？」という質問に対して、Cloneで妥協していい。
Cloneせずにコーディングすればメモリを小さくできるが、コーディングが難しい、と回答があった。

僕はRustはC言語の代わりとなる低級プログラミング言語と誤解していた。
しかし、こういうRustの話を聞くと、C言語のように扱える関数型プログラミング言語と見なした方が良いと思った。

【2】テスト自動化では、今はE2EテストがAIによって更に加速している。
画像の物体認識、画像処理のディープラーニングを使って、画面UIをテストする方向に進化しているらしい。
しかし、OCRのような、画面の文字認識の精度が低いらしい。
むしろ、テスト後に画面変更をAIが検知して、テストプログラムを自動修正する方向に進化しているらしい。

AIをテストに利用する発想がよく分かっていなかったが、AIが物体認識や画像処理に特化している強みを生かすことで、UIテストを強化しているのは面白い。

UMTPモデリングフォーラムのパネル討論の感想

先週11/24に行われたUMTPモデリングフォーラムのパネル討論だけを聞いた。
ラフな感想をメモ。

【参考】
MF2022プログラム - UMTP 特定非営利活動法人UMLモデリング推進協議会

30、50、100人の壁の正体｜山本 正喜 / Chatwork CEO｜note

データモデリングの立場の中山さん、渡辺さんに対し、ドメイン駆動設計の増田さん、スクラムの原田さんという割りと立場や意見も異なる人達の討論だった。
話は色々あったが、その中で気になった点は2つある。

1つは、少人数のベンチャー企業から大人数の大企業へ進化する時にどんな壁があるのか？

スパン・オブ・コントロールの原則通り、1人の社長が統率できる人数はせいぜい5～7人まで。
そこから20名、50名、100名、300名と増えるごとに、ピラミッドのような階層構造を持つ組織になっていく。
すると、必ずその会社特有の業務システムが必要になってくる。

興味深かったのは、30名未満の少人数ベンチャー企業が、従業員数よりも多い個数のSaaSを運用している会社があるよ、という話。
おそらく、10名未満の少人数ベンチャー企業であれば、自社だけに作り込んだ業務システムは不要であり、SaaSを導入するだけで十分やっていけるだろう。
しかし、事業や業務がどんどん拡大していき、従業員も増えるが、それ以上に業務が複雑化して、その業務を支えるSaaSを次々に導入して運用してしまった。
しかし、SaaSにインポートするデータは、各事務員がExcelで作りこんで準備して取り込んで修正する作業を行っている、と。
これは、いわゆる「人間バッチ」と同じですね、と。

「人間バッチ」と揶揄する理由は、本来は事業や業務を回すための業務システムを独自に作って自動化する必要があるのに、それをさぼって、事務員が労力をかけて業務データをExcelで作り込んでSaaSに流し込むという手作業をこなっているからだろう。
結局、今はどんな企業であれ、税務会計だけでなく、事業や業務を回すためのシステムも必要になっているわけだ。

そんな状況ではデータモデリングがとても威力を発揮すると思う。
なぜならば、業務を回すための仕組みを分析するには、業務フローだけでなく、事務員が作り込んでいるExcelデータを抽象化したデータモデルが必要になってくるからだ。
そのデータモデルさえきちんと分析できれば、業務フローも画面もバッチも帳票もほぼ決まってしまう。
業務分析とデータモデリングは表裏一体と思う。

もう一つは、データモデリングが業務分析、ビジネスモデルの分析でとても有用なのに、なぜその技術が普及せず、軽んじられているのか？

パネラーの方も色々話されていたが、僕は本当の原因が他にあるような気がした。
単にIT技術者や事務員にデータモデリングの知識が足りないから、だけではないだろう。
データモデリングを習得するモチベーションがそもそもないことに真因があるだろう。

特に昨今のアジャイル開発に興味を持つ人であれば、古臭いデータモデリングよりもドメイン駆動設計の方に惹かれるだろう。
実際、増田さんが主催されるドメイン駆動設計の勉強会にはたくさんの開発者が集まるのに、データモデリングの勉強会はあまり開催されていないし、開催されたとしても正直あまり人は集まらない。

それはなぜなのか？
その理由は僕もわからない。
このテーマは今後も考えてみたい。

【追記】
@sakabaさんからこんなコメントを頂いた。

さかばさんはTwitterを使っています: 「@akipii 開発者がソフトの寿命を短く考えがちなことや、利益が出てから作り直した成功例のあることが根底にあると思います。このため目先の利益を得ることに走りがちで、モデルが後回しになっていると思います。」 / Twitter

ベンチャー企業では売上重視のビジネスモデルなのでSoEのようなWebサービスのシステム開発が中心になる。
一方、大企業になって安定してくると、社内の業務を安定して回す基幹系システム（SoR）が重要な役割を占めてくる。
つまり、ベンチャー企業では、社内の業務システムが必要になる状況になるまでは、基幹系システムは作らないし、作る必要がないと認識しているのだと理解した。

XPエクストリームプログラミングは偉大だ～時代がその設計思想に追いついた

XPエクストリームプログラミング入門をオンラインで聞いた。
改めて、XPエクストリームプログラミングは偉大だ、時代がその設計思想に追いついた、と思った。
ディスカッションの内容から感じたことをラフなメモ。

【参考】
XPエクストリームプログラミング入門 - connpass

ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか: プログラマの思索

僕は、「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 」の第1版の方が好きだ。
理由は、荒削りだが内容はとてもシンプルで、当初考えていた直感的な思いが直接的に表現されているからだ。

- eXtreme Programmingの魅力を探るにある「Embrace Change - 変化ヲ抱擁セヨ」のグラフが一番好きだ。

勉強会の内容は放談会みたいで面白かった。

XPはプラクティスありきではない。
プラクティスは具体的な実践方法。
プラクティスは価値を実現したものの一つ。
しかし、価値は抽象的すぎるので、プラクティスと価値の間に原則を置いて、プラクティスと価値を橋でつなぐ。
そういう絵がXPではよく出るが、その意味がようやく分かった。

XPのプラクティスは、そのテーマ単体だけで一冊の本になる。
たとえば、リファクタリングなら、リファクタリング(第2版)。
テスト駆動開発なら、テスト駆動開発、実践テスト駆動開発。
継続的インテグレーションなら、継続的インテグレーション入門、継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化。
見積もり手法や計画ゲームなら、アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~。
ふりかえりなら、アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き。
シンプルな設計なら、エリック・エヴァンスのドメイン駆動設計。
つまり、それぞれのテーマはとても奥深いのだ。

たぶん、それらのテーマは重要である、とケント・ベックは直感的に感じていたのだろう。
それを言語化して形式知としてプラクティスで取り上げたのはすごいと改めて思う。

福井さんいわく。
最初はスクラムは好きではなかった。
XPは具体的なのに、スクラムではプロセスはしっかりしているが、実際に実践しようとすると中身が分からない。
でも、今はスクラムは好きですよ、と。
スクラムはスクラムマスターの存在が凄く大きい、と。

アジャイル開発は自動車の運転のようなもの。
到着先は分かっていて、その道順が分かっていても、不確定要素があり、ハンドル操作で変化を受け入れながら進める。
つまり、運転は変化が全くない動作ではないし、変化を受け入れる動作範囲に落ち着くようにする。

時代がアジャイルにやっと追いついた。
アジャイラーは当初は周囲と戦っていた。
いかに導入するか、いかに普及させるか、に注力していた。
しかし、今はお客様からも、アジャイル開発を導入したいと言われる。

WF型開発の権化だったPMBOKがアジャイル開発の考え方を取り入れて、PMBOKの最新版でごっそり変わったのも大きいね、と。
実際、PMBOKは従来の分厚い数多くのマネジメント技法の知識体系だったのに、アジャイル開発の考え方を具現化して、価値や原則が主体のマネジメント体系に変わろうとしている。

アジャイル開発を支える技術が揃ってきたのも重要だろう。
特にクラウドが普及したおかげで、すぐにサーバーを立ち上げて、実際に動かしてみて、動かしながら作っていくのができるようになった。
それもコストをあまり掛けずに、個人ですら開発できるようになった。
つまり、継続的インテグレーション、継続的デプロイ、リファクタリング、テスト駆動、短期リリースなどを支える技術が揃ってきたおかげで、アジャイル開発を実践しやすくなった、と。

一方で、SIがアジャイル開発に追いついていないように思える、と。
発注者は自社で内製開発がしたいので、アジャイル開発を自然に受け入れやすい。
しかし、SIは受託なので、既に自分たちの標準プロセスを持っているし、人月単価のビジネスモデルもあるから、いきなりアジャイル開発に変換するのは難しい。

僕がXPやアジャイル開発に惹かれる最大の理由は、IT業界のきつい仕事から脱出できるための救いとして捉えていた面があったからだと思う。
多重請負の人月単価のビジネスモデルの中で、大量のプログラマや技術者をまるで仕掛在庫みたいに扱って、変動するバッファみたいに扱う手法がどうしても慣れなかった。
アジャイル開発は人重視であり、技術者の専門性を活かしながらチームでアウトプットを出していく、という思想に引かれていたのだと思う。
IT技術者として専門性を高めていくと自然にアジャイル開発に収れんされていくはずだ、と思っていた。
今もその思いは変わらない。

第23回東京Redmine勉強会の感想～コミュニティは仲間から生まれて続く #redmineT

第23回r東京Redmine勉強会の感想をラフなメモ。
3年ぶりのリアル会場でハイブリッド開催だった。

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

2022/11/5 第23回redmine.tokyo勉強会 #redmineT - Togetter

Redmine Advent Calendar 2022 - Adventar

【1】リアル勉強会で嬉しかったのは、@yukiaさんと@shinyaさんに対面で会えたこと。

yukiaさんとRedmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論したことがあった。

Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた - Togetter

Redmineのトラッカーは一般向けに説明が難しいよね、その原因は何か？
yukiaさんはヘーゲル弁証法の観点で、トラッカーは各人ごとの切り口でバラバラに使っているが、弁証法でより一層抽象化ないしもう一段上の抽象化レベルで議論すれば同じ概念だ、と話。
僕の観点では、フッサール現象学やプラトンのイデア論みたいに、トラッカーという概念は客観的に存在すると思われているが、各人の目線では、帳票設計だったり、チケットの種類だったり、ワークフローだったり、いろんな解釈で存在が認識される、という話。

yukiaさんは「強制エポケー」というフッサール現象学の言葉も知っているので、僕が言いたい内容ももちろん理解した上で発言されている。
懇親会ではあまり話せなかったけれど、この辺りももう一度話しみたい所。

shinyaさんの、塩漬けチケットを一気に却下したツイートを以前コメントしていたら、反応が多かった。
他にも退職者ツイートなど、面白いツイートがあったのですごく記憶にあった。

面白すぎる。RT @NAGAYASU_Shinya: Redmineにて塩漬けチケットがしぬほどある部署にいたとき、ついカッとなってここ1ヶ月更新のないチケットを一気に却下にしたったことある
……すごい怒られた、そして別に業務になんの支障もなかった。

— akipii (@akipii) March 10, 2017

他にもリアル対面の人を認識できて良かった。

【2】前田剛さんの話では、RedMicaのお話と国民年金基金連合会がRedmineで作られていた話。
これには笑った。

Redmineで構築されている国民年金基金連合会の「他年金調査 事業所回答システム」を調べてみた - ファーエンドテクノロジー株式会社

他年金調査　事業所回答システム

実際にログイン画面を見れば分かるが、どう見てもRedmineだ。
日本企業の事業所は約300万と言われているらしいので、その事業所にいる社員数をRedmineで管理していると考えると、相当な数のレコードがRedmineに蓄積されていて、個人情報の観点でも非常にセンシティブな内容があるだろう。
Redmineなら安全に運用できるという判断があったのではないか。
このあたりの話も勉強会で聞けると嬉しいね。

【3】僕の話はチケット駆動開発の昔話。
あの頃は若かった。
なお、2020年頃からRedmineの勢いに陰りが出て、JiraやBacklogの勢いを感じている。
実際Googleトレンドではそんな感じ。

齋藤さんはTwitterを使っています: 「@akipii google トレンドの話に、興味を持ちました。JIRA / backlog 勢がほぼ同じような動きですね。 実際の日本でのシェアは、どんなもんですかね？ #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT 詳細は知らないですが、ネットやコミュニティの話を見聞すると、JiraやBacklogの勢いは感じますよね。」 / Twitter

中村さんの話は、Redmineを5.0にVerUpしたお話。
プラグインの互換性確認のために手間がかかったそうだが、@g_maedaさんやプラグイン開発者、パッチ提供者のおかげで無事に乗り切れた、とのこと。
Redmineコミュニティが活発であるからこそ、安心して運用できるわけだ。

@geosanak さんの話は、Redmineプラグインのテスト自動化を頑張っている話。
ビルド管理ツールはJenkinsからCircleCIまで色々あるが、GithubActionを使ったよという話。
詳細をもう少し聞きたかったが時間切れ。

@bowkoba さんのオフショア開発にRedmineを運用した時に、コミュニケーションの問題が発生した話は同感だった。
チーム運営、プロジェクト運営で発生する問題は、結局のところ、プロマネが伝える内容が伝わっていない、指示を仰ぐメンバーが理解できていないことに尽きる。
その問題はコミュニケーション不足の症状として現れるが、その根本原因と再発防止策は、それぞれの現場で異なる。
現在、アジャイル界隈では、DXを実現するための組織論の話が多いが、その観点も、このコミュニケーション不足の問題と同じ構造を持つと思う。
結局のところ、組織文化の問題として出てくるが、本当の真因は、プロセスや組織構造に根っこがあるわけだ。

@t_tsuru さんのRedmineUIの問題点は、従来から問題提起されてきた。
この問題の改善は、今後どんどん重要視されてくるだろうと思う。
他のPJ管理ツールやSaaSでは、チケットのコメントがリアルタイムに表示されたり、UIが今風で使いやすかったりするので、どうしてもその観点から比較されて敬遠されてしまうから。

チケット茶番劇も面白かった。
実際にチケットのやり取りを見るのは楽しい。
チケットを書く人がどんな気持ちでいるのか？
リアルで見えるのはいい。

@yokoba569さんの話では、チケット駆動開発が良かったよ！という話。
チケット駆動が楽しい！
Redmineが実績管理にとても向いていて、実際にデータをメンバー自ら採取して分析し始める。
見積もりと持ち工数の観点でPJ管理をどんどん改善しようとする。

@tohosaku さんはRedmine を railway にデプロイしてみた話。
@agilekawabata さんは、Redmineハンドブックの紹介。
わかりやすくてとても良い本です。

@tkusukawa さんは、Redmineを利用する趣旨のお話。
趣旨を説明するのはいつも大事。

@hiroiwsk6さんは、お役所の問い合わせ管理と帳票出力をRedmineで改善した時に、どんな設計で構築したのか、というお話。
問い合わせチケットのステータスごとに、送信メールが作られるのが面白い。
つまり、ステータスごとに、メールの内容や宛先が微妙に異なってくるので、メールテンプレートをいかに共通化して設計するかが肝なのだろう。

@naitohさんは、勉強会の参加者や利用Redmineの属性分析のお話。
もう8年以上蓄積されているので、Redmineにも波がある。

【3】今回はハイブリッド開催。
会場の参加者は26人くらいで、そのほとんどが常連さんで初めての方もチラホラ来られていた。
その後の懇親会では、久しぶりの再会を皆で喜んだ。

オンライン開催が普通になった今では、確かにZoomでやった方が正直楽だ。
しかし、会場開催の方が、反応を生で感じられるし、いろんな人達と交流できるのが楽しい。
生身の人間と肌感を感じるのがとても久しぶりだったから、本当にそう感じた。

Redmineコミュニティももう11年目で、他コミュニティに比べても古参になった。
スタッフや参加者も入れ替わりがありながら、よく続いているなと思う。
熱量がある人が入れ替わり立ち替わり居続けることで続いているんだと思う。
コミュニティは仲間から生まれて続く。