redmine.tokyo 20 感想
2021/5/22 (土) に開催された redmine.tokyo 20 の感想。LT でひさびさに登壇した。今回も Zoom 開催となる。
- 第20回勉強会 - redmine.tokyo
- 【オンライン開催】第20回redmine.tokyo勉強会 - connpass
- 2021/5/22 第20回勉強会 - redmine.tokyo #redmineT - Togetter
講演 : Redmine 4.2 新機能評価ガイド
2021/3 にリリースされた Redmine 4.2 の新機能まとめ。
サポート切れとなった 3.4 以前は未修正の重大な脆弱性が残っているので 4 系への更新を推奨。4.2 は 4 系で最後のリリースとのこと。5 系への移行を容易とするためにも 4.2 まではバージョン更新しておくとよい。
2FA 対応の 4.2 を待っていたのと本業の多忙が重なり、職場 Redmine が 3.4 のままなので更新したい。4 〜 5 月中で検討していたが 6 月も半ばになってしまった。2FA で利用する Google Authenticator は GitHub と npm アカウントで先に導入済み。意外にわかりやすい仕組みなので職場 Redmine の 2FA も簡単な勉強会でゆけそうな気がしている。
Redmine のリリースについて。
開発体制の変更により JPL 氏の実作業がなくても Marius BALTEANU 氏と前田さんで対応可能となったとのこと。Redmine のリリースは遅れがちで RedMica はそれを踏まえて定期リリース体制を採用した。この点について今後 Redmine と RedMica の関係が気になる。定期リリースと最新機能の先取りという価値は残るし、互換もあるから併存を続けるのだろうか。
4.2 の新機能は Redmine.JP Blog の記事もよくまとまっている。
講演 : Backlog x Redmine対談
- パネラー
- モデレーター
Backlogworld 2021 で実施された対談の続き。そちらは未見だが、面白い対談という評判は聞いていたので期待。
リアルな対談のようにパネラーとモデレーターが一つの画面へ同時に表示されている。また発言の状況によってメンバーの表示サイズがリアル タイムに変更されていた。これは Zoom の Immersive View という機能で実現しているとのこと。
私も業務などで Zoom によるイベントを担当しそうなので、この観点からも参考になる演出だった。ビデオ会議の対談では音声入力などを検知して発言者が順番に大映しとなるものが多い。しかし対談が込み入ってくると矢継ぎ早に画面が切り替わるため観ていて疲れる。この機能ならそういうこともない。リアルな対談以上に柔軟な表示も可能なため、積極的に採用したくなるよい機能だ。
対談で印象に残っているのはセルフ マネージメント。Backlog、Redmine、その他どのような仕組みを採用しようとも、ボトムアップな課題管理はこれにつきる。
プログラマーの間では自走とか呼ぶ、あれだ。分割統治の究極が個人の自走で、Backlog や Redmine のような Web ベースの ITS はそのためのツールとしてよくできている。
セルフ マネージメントや自走の話になると、それはマネージャーの担当であるとか自走は放任といった反論を聞く。それは違う。大抵の人は既に実践しているはずだ。予定を立てて遂行する。妨げるものがあれば解消する。これだけでも十分にマネージメントであり ITS はそれを管理しているだけに過ぎない。極端な話、継続できている生活習慣...例えば歯磨きなんかはセルフ マネージメントの成功例である。
せっかくマネージメントするなら、個人の体験に留めず共有したほうがよい。第三者とスムーズに協業するための情報となるし、後から振り返るための知見としても有用だ。
ということを考えながら対談を聞いていた。
LT: メールと Excel によるタスク管理に Redmine 導入の途中経過報告
メールと Excel によりタスク管理されている組織に Redmine を導入してみた話。
まず業務のコミュニケーション手段としてメールは厳しい。Slack のようなチャットと比べたらメタデータ面で簡易 ITS とも言える。しかし状態を表現する方法がテキストのみなので、作業状況や担当者を表現するのが難しい。登壇でも「自分が返信していないスレッドを探す」という話をしていた。
ITS ならステータスや担当者などのメタデータにより簡単に把握できることを、メールだとスレッドやメール本文の表現を吟味しながら探すことになるのだ。これは非常に辛い。
これに加えて私はメーラーによる閲覧環境の個人差も大きな問題と認識している。相当に練られた統一ルールで縛らない限り、タスク管理メールの見え方は各人バラバラだ。そのため緊急タスクが見つけらず返信がないとか、それを指摘するメールが振り分けで気づけない、といった事故がおきる。
ナレッジ蓄積も ITS の大きなメリット。特定の目的にそった調査や議論がチケットに集約されるだけでも有用だし、Wiki との併用は更に強力だ。Web ページを簡単に作れるというのは資料作成ツールとして実に便利。私の職場でもチケットより Wiki がよく使われている。なによりこれらを横断検索できるのがよい。
LT: テキスト化した「チケット駆動開発がまわりはじめるまでの取り組み」の紹介
Redmine Japan 2020 の登壇
で語りきれなかった内容を少しずつテキスト化している話。けっこうなボリュームなので少しずつ読んでいる。チケット駆動に関する考察からはじまる一連の記事は読み物としても面白い。
ITS というものに初めて触れた 2001 年頃を思い出す。私にとってもチケットで課題を可視化して解決するという管理手法は衝撃的だった。そのプロジェクトは内製の ITS、というより BTS を使っていたのだけど、チケットだけではナレッジベースとして弱いということで有志の手により別立てで Wiki の試験運用をはじめた。はじめは私も含む数人でプロジェクトの覚書を記録したりしていたのだけど、そのうち多くの人が利用するようになって...という感じで ITS (BTS) とあわせて Redmine 的な運用となってゆく。
にある「覚えなくてよくなった」が受けたのだろう。じんらいさんの話は主にチケットだが Wiki も含めて Web ベースの外部記憶装置という側面がよくて、次に ITS だと豊富かつ標準でも寝られたメタデータで記録したものを分類できる。これらの相乗効果を経験すると「まずはチケットで = チケット駆動」としたくなるものだ。
kawahara さん登壇におけるナレッジの話にも通じる。
LT: Redmine 使ってみた 5 年間 12 万チケットを 5 分で振り返る
Redmine を導入して 5 年。チケット文化の普及とファンの獲得に成功したとのこと。その過程についての話。
苦労はあったろうけど順調に浸透していてすごい。おそらく 2 年目の「とにかくファンを増やせ」からの流れがよかったのだと思う。妥当性があっても新しい試みは受け入れがたい。私もそうだが基本、人は保守的である。失敗が恐ろしい。なので「失敗してもめげない」ことが重要。大抵の試みは失敗するのだし、その許容量が組織の体力である。どれだけ失敗できるか？は、どれだけ学べるか？ともいえる。失敗しても放り出さず、地道に続けて成功例を出したからこそファンを獲得できたのだろう。
5 年目の「情報を活用しろ！」で Power BI を知った。この例では Redmine からダウンロードした CSV を Power BI で円グラフにしているが、ここを自動化できたら更によさそう。例えば会議の場でオンデマンドにグラフを出したい。Power BI から CSV を Redmine にリクエストできればいける？そういう中間層 (サーバー) を設けるのが現実的か。
LT: Redmine issue assign notice plugin の紹介
View customize プラグインでおなじみ、onozaty さんの新作。チケット担当者が変更された際に Slack や Teams などの外部サービスへ通知してくれるというもの。
担当者の変更に絞った理由にうなづく。チケットのあらゆる変更を通知すると過剰すぎて埋もれるというのは確かに。Redmine 標準のメール通知もこの理由で読まれなかったりする。作業分担が適切なプロジェクトならチケットも分割統治されているわけで、ならば変更で抑えておきたいのは「ボールが誰に渡されたか？ = 担当者が誰になったか？」となるだろう。
通知内容とされる側の振る舞いも Slack などを実際に利用している立場として練られていると感心した。メンションと通知先チャンネル、超重要。
これまで職場 Redmine では互換性の問題などで止まると困るからプラグイン無効派だったけど、これは導入したい。onozaty さんは View customize をまめに更新してきた実績もあるので将来性についても大丈夫だろう。懸念があるとすれば通知先となる各種サービスの互換維持か。
Incoming Webhoook については onozaty さん自身による調査記事が参考になる。
職場 Redmine を 4 系に更新したらあわせて試す予定。
LT: 時系列データをグラフ化する、redmine numericfield chart macro の紹介
Redmine のカスタム フィールドに入力された値の変化を時系列データとしてグラフ表示するプラグインの話。きっかけは COVID-19。これを予防するため課員の体温を Redmine のチケットへ記録して履歴を見たいと考えた。そして履歴の変遷を観察するという点から StatusHistoryChartMacro の類似に気づき、Redmine で実現してみようと試みたのが本プラグイン。
マクロとしては第一引数にカスタム フィールド名、残りを Issue ID を取る。
{{numericfield_chart(体温, 2, 3, 5)}}こんな感じで Wiki に記述すると、それぞれの Issue におけるカスタム フィールドの変遷を比較した折れ線グラフが生成され、埋め込まれるとのこと。
登壇でも挙げているように色々と応用の効きそうなプラグインだ。課題としては履歴なので、入力内容を間違えても対象とされてしまうことか。変遷を見るという意味では誤りも履歴として表示されてほしいといえる。入力の厳密さを保証するか、さほど求められないものに利用するのがよさそう。
講演 : 新型コロナウイルス感染者情報管理
通信トラブルにより順番が前後。やはり通信が絡むならこういうことも起きるものだし、それでも即座に対応して進行がスムーズだったのはすばらしい。
今回、特に楽しみだった登壇。
Redmine といえば ITS の印象があるため、情報サイトとしての事例は新鮮である。普段はチケット運用する側だから ITS と認識しているけど、チケットの豊富なメタデータと多様な表示形式の組み合わせは情報サイトにも有用なのだと理解した。
このサイトでは現在、山梨県と長野県が公開している COVID-19 の感染者情報をプログラムで自動処理して Redmine に反映している。山梨県は Web ページに対するスクレイピング、長野県は CSV を基本として一部 PDF を処理しているとのこと。県ごとにデータ形式が異なり、また予告なく更新もされるため追従は手動となっている。継続運用されていて実にすばらしい。
データについてなんとかしてほしいものだが、自治体横断で統一的に取り組むことは非常に難しく即時性も重視される。そのため調整に時間がかけられないゆえの現状なのだろう。それでも長野県がプログラムで処理しやすい CSV を公開していることは称賛したい。
国としてはオープンデータを推進している。本件はそれを活用している事例なので、もっと広く知られてプロジェクトに国や自治体が協力するようになればと思った。
それとサイトの外観が美しくテーマ作者としてよい刺激を受けた。テーマは既存のものだそうだが、カスタマイズしている部分とあわせてきちんと調和している。Redmine 4 〜 5 想定で新テーマを作りたいと考えてて、たぶんそれは影響を受けるだろう。
講演 : パネルディスカッション「Excel中毒者への特効解毒剤Redmine」
Excel は強力な WYSIWYG エディターとして利用されてる側面がある。これに本来の表計算とマクロが組み合わさると万能性がマシマシで「なんでも Excel」となりがち。万能は専用に敵わないものだが Excel 以上を求めないならコストをかけてまで別システムを導入する気にはならないだろう。
そういうユーザーに Redmine を利用してもらう施策として Excel をフロントエンドにする発想は実に面白い。私の専門であるプログラミングに例えるならリファクタリングにおける Wrapper みたいだ。改善したいコードを必要最小のインターフェース互換を持つもの (Wrapper) で包み、内部を直してゆく。
利用側は Excel という互換インターフェースで安心。渡されたデータは Redmine に集約される。そこまでする？とも思うが移行で消耗するなら、いっそこういう緩衝層で対応するのもありだと認識を改めた。
後半の Redmine ネタも面白かったが、前半のインパクトが強すぎてずっとそのことを考えながら聞いてた。
LT: Redmineで地理空間情報を扱う、Redmine GTT (Geo-Task-Tracker) plugin の紹介
Redmine の拡張性に注目して地理空間情報を組み合わせる話。この発想に至るところがすごい。これを実現するプラグインは GitHub で公開されている。
使い方の解説を聞きながら、前述の時系列データと新型コロナウイルス感染者情報（非公式）を組み合わせて面白いことができそうだと考えていた。感染者情報は地域と結びついている (現時点では山梨と長野)。また時系列に変化してゆくものだから、その変遷をマップとグラフの組み合わせで表現したらニュース番組で見るような視覚的にわかりやすい画像を提供できるかも。
今回はこういう Redmine の柔軟なデータ管理システムとしての側面に注目した登壇が複数あって、ソフトウェア開発者としても楽しめた。
LT: Redmine の通知メールを暗号化しなければいけなくなった話
うちは顧客と Redmine 上でやりとりすることはないのだけど、機密情報をチケットに書くことはあるから興味を持って聞いた。
SMTPs/STARTTLS は送受信サーバー両方の対応が必要な上、メール サーバー間との通信は暗号化されない。そこで E2E の暗号化を検討したが S/MIME に関するチケットは議論が止まっている。
ただし PGP/MIME は本家 である C3S のプラグインこそ開発が止まっているものの fork 版である freedomofpress/redmine_openpgp は現在も開発が継続されているので、これを採用してみたとのこと。
インストールなどの細かな情報は昨年の Redmine アドベントカレンダー記事にまとまっている。
証明書まわりは面倒だが、一度だけ設定しておけばという類なので検討してもよさそう。
LT: Power Automate Desktop (PAD) を Redmine から実行してみた
RPA とか Power Automate Desktop は概念と名前だけ知っているけど縁がない。プログラマー視点だと GUI を自動操作するより、本質的な API やデータ操作を実装するほうがよいと考えてしまうからだろう。けれど API やデータが公開していないアプリケーションは多い。普段 OSS へ触れる機会があるから意識しにくいが、そういうアプリケーションも広く使われているので RPA 的なものも受け入れるべきなのだろう。
ということを考えながら登壇を聞いてた。登壇で挙げられてた例だとやはりプログラムを書きたくなってしまう。が、プログラマーに依頼しなくても視覚的かつノーコード的な方法で近いものを組めるというのは需要があるのだろう。
ここまで出来る人ならプログラムを覚えて書けそうにも思えるが「プログラムを覚えて」というのは結構な壁で、じゃあどの言語で？周辺知識もたくさんあるでしょ、というのを忘れていた。
LT: 見積もりスキル養成ギプスとしての Redmine
私の登壇。
オンライン イベントでは基本、顔出ししないことにしている。しかし職場のビデオ会議で顔が見えないと反応がわかりにくいという意見を聞いて一理あると考えを改めた。というわけで折衷案としてマスクして登壇することに。マスク・ド・ベコというわけだ。バスコ・ダ・ガマのように読みます。この記事を書くために動画を見直したのだけど完全に不審者ですね。
登壇の元ネタは昨年のアドベントカレンダーで書いた以下の記事。
Twitter を見たらわりと好評？だったようで嬉しい。みんなでパンプアップしてゆきましょう！
懇親会
部屋によって真面目なタスク管理や UI 論を述べてみたり、古のウルトラファイト (TV 番組) とか Moon (ゲーム) なんかのサブカル話で盛り上がってみたり。最終的に 23:00 ぐらいまで残って解散となった。
今回も楽しく有意義な情報に触れられた良イベントでした。登壇者と運営の方々、ありがとうございました！