redmine.tokyo 21 感想
2021/11/27 (土) に開催された redmine.tokyo 21 の感想まとめ。今回も Zoom 開催。
- 第21回勉強会 - redmine.tokyo
- 【オンライン開催】第21回redmine.tokyo勉強会 - connpass
- 2021/11/27 第21回勉強会 - redmine.tokyo #redmineT - Togetter
講演: RedMica 2.0 新機能解説
新機能で特に興味を惹かれたのは CommonMark Markdown 対応。現在のテキスト書式における Markdown は vmg/redcarpet によるもの。これを gjtorikian/commonmarker へ移行する予定とのこと。CommonMark になると HTML 埋め込みが可能となり例えば <br> を記述することで文中の任意位置で改行することも可能。
私がメンテナーを務める vivliostyle/vfm も CommonMark/GFM を基本としているのだが、Markdown 記法で対応しきれない部分は HTML 埋め込みにより代替する方針である。Mark"up" である HTML を前提とした簡易記法としての Mark"down" という意味でも、この相互補完は好ましい。
テキスト関連では Mermaid.js による作図サポートも楽しみ。図をプレーン テキストで記述可能とすることは編集や履歴、差分管理の面でメリットが大きい。編集に関しては WYSIWYG を好むユーザーが多そうではある。しかしテキストの多い図ならばプレーン テキストにすることでテキスト エディターやプログラムと組み合わせた処理による生産性の向上に期待できる。履歴と差分は Redmine 上の Wiki で役立つ。図の更新も Wiki のテキストとして管理可能となるのだ。これは嬉しい。
現在の職場 Redmine は今年の夏頃に v3 から v4.2 へ乗り換えた。この時はサーバー単位の移行となるため万が一のトラブルを危惧して Redmine を選んだのだが、RedMica はディストリビューターが異なるだけで互換は保証されているし Mermaid.js によって UI Extension の魅力が大きく増したので真剣に採用を検討することにする。
LT: ある工場の Redmine 2021
- neta @ 11/27(土) redmine.tokyo オンライン で会いましょう💪さん (@netazone) / Twitter
- ある工場の Redmine 2021 ( Redmine of one plant 2021 )
Redmine サーバーを 7 年も維持しているのはすごい。しかもプラグイン込み。長きに渡り慎重に互換性の維持に努めてきた Redmine 本体、ならびにプラグイン開発者の方々には脱帽だし netazone さんがユーザーとしてもマメに動向をチェックしながら更新したからこその結果といえる。
登壇後半の有料 Redmine テーマ購入も、こうしたマメさのひとつだろう。私は Redmine テーマを開発者していることもあり有料テーマの実用性には興味がある。とはいえなかなか購入して試そうとまでは思わない (金銭よりやる気の問題) ため、よくぞ取り上げてくれたと拍手したい。
テーマ試用について私も少し協力した。さすがにテーマのイメージを提供してもらうわけにはゆかないため購入者である netazone さんが立てた Redmine を利用。どのテーマも有料だけあってよくできていた。登壇で指摘されているとおり細部の作り込みが甘くレイアウト崩れするここともあるのだが、テーマ開発者の視点としては仕方ないと思っている。
標準テーマの差分修正に収まらず大規模な変更を加える場合、資料の類はないため CSS と HTML を見ながら手探りとならざるを得ない。これに加え本家の更新追従も必要となる。これはかなりの苦行だ。とはいえ資料を運用するコストの高さも理解できるから、そういうものだと受け止めている。
ではどうやって改善してゆけばよいのだろう。本家の開発へ協力するのはハードルが高いので本登壇のように有料テーマ購入でビジネス面を盛り上げるとか、私のようなテーマ開発者が Redmine パッチ会的な感じで勉強会なりワークショップを開催してコミュニティーを広げる、などだろうか。
それと minimalflat2 に言及してくれてありがとうございました！
LT: Redmine に必要なのは Confluence?
最近、友人の運用する Jira を利用する機会があったのでファミリー製品の Confluence はどうなんだろう？と興味を持ちながら聞いた。
Redmine のチケットや Wiki がプレーン テキスト ベースなのに対し Jira/Confluence は WYSIWYG である。本登壇で価値を感じているのもここにあるという印象。例えばテーブル内の値を編集する場合、WYSIWYG ならセルを直に書き換えれば済む。これが Textile や Markdown だとスペースによりインデント調整をしていないと対象部分を探すだけで一苦労だし、インデント調整していると書き換えた後に全体の再調整を検討しなければならない。
これは編集動機にかなり影響していると思う。Jira/Confluence のような WYSIWYG であればテーブルが大量かつ頻繁に変更される資料の運用も苦になりにくいだろう。
では Redimine Wiki もそうしたほうがよいか？というとこれも悩ましい。Markdown については JavaScript による WYSIWYG なエディターがいくつかあるので CommonMark 対応とあわせて導入できるかもしれない。しかし Textile はどうなのだろう。調べたら Redmine プラグインとして
があって Markdown と Textile の両方へ対応しているようだ。使用感が気になる。
LT: アンガーマネジメント on RedMica
Redmine (RedMica) をアンガーマネージメントに活用する話。お題が強くてネタ枠？と思ってしまったが内容は至極まっとう、かつ Redmine の機能を使いこなしている。さすがだ。
課題管理は分析的なモデリング作業ともいえる。Redmine のチケットは標準でもかなり細かなメタデータを提供しているため、分析結果を当てはめる先も十分。ゆえに本登壇のアンガーマネージメントもしっくりくるモデリングだと感じた。
登壇でも言及しているがチケット化の過程は結果としてアンガーマネージメントにおける 6 秒ルールを踏襲させる。時間的にも起票のための分析としても。情動を飼いならすために重要なのは観察である。これはアンガー以外でも有用だと思う。
例えばソフトウェア開発だと設計の議論や資料作成といった分析を割愛して「とりあえず実装」というのはよくあること。分析に比べて実装は短期で結果を得られるため、安直に手を動かしてしまいがち。しかしよほど典型的とか小規模でもない限り、分析を経ていない実装は散々なものだ。ほんの一手間、やりたいことを箇条書きにする程度でもはるかによい結果を得られるだろう。
LT: RedMica Bridgeの紹介
- Fukuda Keiko さん
RedMica Bridge の話。
Redmine は多機能さがそのまま UI に反映されているため、初見では難しく感じられる。またチケット管理だけあれば十分というユーザーもそれなりにいるだろう。Redmine Bridge はそういう要望を意識したサービスだと感じた。
オンプレミスも含む既存 Redmine をそのまま利用するというのも面白い。Redmine は REST API を公開することでフロントエンド部分を別立て可能なのだが、その好例といえる。WordPress API と静的サイト ジェネレーターを組み合わせて Headless CMS 運用する話を思い出した。
この方法には可能性を感じる。例えば完全 SPA な Redmine を開発するとか。プラグインとテーマ以外の拡張として盛り上がってほしい。
第21回 パネルディスカッション ＜Redmineとわたしたち＞
- モデレータ: あさこさん
- パネラー:
- みけねこさん
- Tomoko さん
- Ryoko さん
- Mika さん
- 第21回勉強会 2021-11-27 redmine.tokyo - YouTube
今回のパネルディスカッションは女性限定。面白い試みだ。パネラーのうち三名が音楽系の偉人アイコンなのだけど、デフォルメされたいらすとやと写実的で解像度の高いショパンが並ぶ絵面の VISUAL SHOCK 感も楽しい。以下、ざっくりとした覚書。
- Redmine のすきなところ、いまいちなところ
- 情報を記録するのによくナレッジベースとして評価している、機能としてシンプルだがエンジニア以外にはとっつきにくい
- 最初は説明欄へ何を書いてよいかわからない、作文スキルが要求されて途方にくれる、テンプレート機能などで改善可能、書けるようになれば記録として有用
- チケット同士の紐付け (関連、親子) が簡単、ロール (権限) 管理の柔軟さがよい、ある工場の Redmine でも言及されていたが UI に改善の余地あり、Planio を利用しておりこれはかなり洗練されているが初見 (これは主に非エンジニアを指している印象) には厳しい
- チケット駆動を理解していないと取っ掛かりがわかりにくい、導線の問題がある、馴染んでしまえばカスタマイズ性が高く便利
- 総じて自由度の高さはよく、それゆえの難しさがいまいち
- Redmine 利用のハードル
- Redmine の利用ハードルは高いのでどう改善したらよいか？
- 初見の取っ掛かりをなんとかしたい、Redmine 導入者は利用者を考慮する必要あり
- UI について特に不満はない、トラッカーとステータスでワークフロー管理しているがこれを事前設計していないと組織利用は難しいと感じる、各プロセスで必須の手続きを確実に実行させるために必要
- プラグインではなく URL パラメーターによるテンプレートで利用しやすくしている、URL は Wiki のリンクとなっているためユーザーはクリックするだけで利用可能、Redmine 警察活動としてチケット運用をパトロール
- Redmine だけで解決せず業務を整理したフロー図を作成して関係者に腹落ちしてもらう、Excel が登場してもよい、Redmine が有用な部分 (記録と検索性など) を納得して利用する方針
- 伴走者
- それぞれの立場からどのようにユーザーや Redmine 管理者へ寄り添ったか、それによる苦労談や気をつけている点など
- ユーザーとして Redmine の改善点や要望などを管理者へ報告している、カスタムフィールドの追加や利用頻度の少ない機能を隠して簡素化するなど
- Redmine 管理者としてユーザー要望へ対応している、例えば図を書くために PlantUML 導入したら好評だった、Redmine 自体に寄り添っている感じ、インフラ運用としてのサーバー負荷対応などに苦労している
- ユーザーとしてもあるが非 IT 系のユーザーも多い組織なので全体最適の観点で取り組んでいる、Redmine に限定せずもっと包括的な感じ
- どうやったら Redmine を使ってもらえるかを重視している、Redmine など特定のツールや仕組みの利用を義務化したくない、やりたいこと解決したいことの相談を前提とした全体最適が大切
- 人を大事にする
- 課題管理の方法として Excel など様々なツールがある中で「人 = ユーザー」に Redmine を腹落ちして利用してもらうにはどうしたらよいか？
- こうした登壇も含めて PC やスマホで人とやりとりしているが、その先には現実世界の人がいることを常に意識するのが大事
- 人の関係は対面のように同期的なものだけでなく過去に起きたことをまとめた資料が読まれるなど非同期も重要、Redmine もそのひとつ、資料やチケットが非同期に読まれるなら初見の人なども考慮して背景やチケットの関連付けなどを充実させたい、Redmine はこうした情報を豊富に持たせられる点がよい
- チケットの注記でわかりにくい表現などがあったらこっそり編集している、注記は履歴が残らないので後で本人へその旨や改善についてアドバイスしている
- ツール利用にとらわれずなによりも利用する人がいることを大切にする、チケットを使いこなしてタスク管理がまわると結果的に「人」が幸せになるということを重視しているし伝えたい
- 柔軟性
- 柔軟性を維持するための心がけなど
- 新しいものを取り入れる、Redmine なら新機能など、技術動向をキャッチアップしてゆく
- Redmine は自身の持っているものを出力するのに向く、柔軟性に関しては外部のニュースや Twitter、対面コミュニケーションにおける偶発性のほうがよいのでは？と考えている
- 自身が Redmine に詳しい立場というのもあり、あまり馴染んでいないユーザーからの意見を聞くと発見がある、こうしたやりとりが柔軟性に寄与するのでは？と考えている
- 否定から入らない、結果として多様な人から意見を聞くことになる、試みを躊躇せずにまずは小さくやってみて段階的に改善してゆく
みなさん意見の言語化がうまい。全般的に Redmine を通じたファシリテーションという感じで COVID-19 による緊急事態宣言で対面コミュニケーションを取りづらくなった現状をどう過ごすか？というテーマにも思えた。
講演: 林業におけるRedmine活用
一般に「Redmine はソフトウェア開発や IT 系で利用されるもの」という印象は強いのではなかろうか。実際にそうではない業種の方々へ便利さを説明しても、この印象からの忌避感を見て取れることが多々あった。
ここまでの登壇でも挙げられていた UI 面の問題もあるだろう。多機能さがそのまま UI に反映されているため、高度なソフトウェアの知識を求められそうにみえてしまう。日本語のローカライズはかなり気を使って翻訳している (特に Issue を課題ではなくチケットとした点) が、それでも自身の業務で使用していない用語や概念に忌避感を覚えるのはよくわかる。
ただし業種を問わず課題管理をするなら Redmine チケットぐらいの項目は必要なはず。既になんらかの課題や工程管理をしているなら Redmine へ移行しても使いこなせるだろう、と考えている。なのでソフトウェア開発や IT 系ではない事例は楽しみ。前回の新型コロナウイルス陽性者情報（非公式）も非常に面白かった。
そして今回は...なんと林業！
どんな登壇になるか期待と不安が半々だった。しかし冒頭から語りとスライドが抜群にうまくて林業そのものへの関心が高まる。パネル ディスカッションで Redmine 導入にあたり関係者に腹落ちしてもらうのが重要という話をされていたが、本登壇はまさにその好例といえるだろう。ドメイン知識 (林業) のある人がそれに基づいて (= 腹落ちして) 工程 (課題) 管理を Redmine へ落とし込んでいる。見事だ。
林業ならではの利用法としては GTT プラグインの導入が面白い。これは redmine.tokyo 20 の登壇でも話題になったプラグインでチケットなどに地理情報として地図を埋め込めるというもの。林業における現場を示す情報として利用しているとのこと。林業以外でも工務店や運輸など地理情報と現場が紐づく業務ならこの事例のように活用できるのではなかろうか。
木こりのジレンマを乗り越えている点も素晴らしい。トップダウンで導入して実運用まで漕ぎ着けている。これもグループ ディスカッションの内容が伏線として効いてて今回の登壇順は練られているなぁと感心。もしかしたら偶然なのかもしれない。あるいは課題管理について掘り下げてゆくと帰結する場所は近づくものだとも。
登壇のおわりに紹介されたアドベント カレンダーも面白い。Redmine のとあわせて毎日、楽しみにしている。
LT: Redmineで徒労を減らす
ドラクエのトヘロスが「"徒労" を "減らす"」に由来してるのをはじめて知った。
実際、Redmine チケットや Wiki にはトヘロス的な効果がある。課題の可視化とその蓄積によるナレッジベース的な性質により、徒労たる冗長なやりとりや水掛け論を避けるのに役立つ。だいたいの試みは既知なのだ。未知であってもチケットや Wiki へ記録して既知にすれば、次回以降はそれを踏まえて差分の議論をするなり改善してゆけばよい。
こうやって未知を切り開いて既知を蓄積し、常にトヘロスのかかった状態としておく。これを前提に本質的な難しい課題 = この登壇でいう「強い敵」へ注力する。そのためのツールとして Redmine のような ITS が役立つ。
Web ベースの良さとしてチケットや Wiki に一意の URL が振られるので書けば書くほど説明コストを URL 貼るだけに省力化できるのは確かに。結果としてトヘロスになってる#redmineT
— アカベコ (@akabekobeko) November 27, 2021
LT: Redmine(SHERPA)の通知をMatterMost(チャット)に連携
Redmine + 独自プラグイン = SHERPA におけるチャット通知の話。
Redmine 標準の変更通知は v4.2 の時点でメールのみとなっている。便利な機能だ。しかし Slack や Microsoft Teams といったチャット ツールの企業利用が進む現代としては、こちらにも通知してほしいものだ。本登壇ではそれを実現しうる方法として SHERPA-SUITE を利用している。
工夫点として Redmine のユーザー情報にカスタムフィールドを追加、そこへチャット (MatterMost) のユーザー ID を定義可能とした。Redmine とチャットのユーザー ID が一致するとは限らず、そのために一方へ寄せるのも手間だろうから、この方法は現実的でよい。応用で複数の通知先を定義するのにも便利そう。通知条件とメンションの工夫も練れており素晴らしい。
そして Redmine 標準機能になってほしいなと願うわけだが、システムの外へ通信することは安全性の懸念があるため難しいだろう。メールのように標準規格があるわけでもないため、実現にあたりサービス間の差を吸収するために拡張性をもった設計が求められる。拡張性 = 自由度なので脆弱性の要因になりがち。そのため既に拡張を担っているプラグイン側で、となるのはやむ無しか。
LT: Redmine屋から見たMS Planner
Planner、初耳だ。Office365 に付属する TODO 管理ツールらしい。カンバン式という点から Trello とか GitHub Issues の Projects 機能みたいな感じなのだろうか。
登壇としては失敗談という感じ。
タスクの終了条件がチェックリストなのはよさそうに思える。しかしタスクは単一目的にするほうが運用しやすくて、そう分割したらチェックリストがひとつだけのタスクが増えて運用が面倒そうだ。タスク分解の粒度をあげてチェックシート中心にすると柔軟性を欠く。課題管理において明確な終了条件を定義することは重要。しかしチェックリストとして箇条書き可能なものばかりではない。実際の Planner だとこの辺を解決する機能があるのかもしれないけど、登壇の印象として TODO 管理なのでチェックリストの範疇で運用という割り切りを感じた。
予定のタスクが多すぎる、について私はカンバン方式に馴染みがないため問題点がよくわからなかった。閲覧性だろうか。Planner だけで管理するのが難しくて別途 Excel ファイルを作ったという点から、そう読み取った。後続の問題点についても Planner の設計思想が ITS 的ではなく、もう少し手軽な TODO 管理を想定しているがゆえに思える。
多機能な Redmine で課題管理をモデリングしてゆくのと、あらかじめ目的を限定したモデリングのなされたシステムを利用するのでは勝手が違いすぎてこういう感想になるのもやむなしか。一方、システムにあわせるという考え方もあって Planner で可能な管理しかやらないというのも面白そうだ。縛りゲー的ではあるがそれはそれで学びもあるだろう。といいつつ実際は akipii さんと同じ状況になってガデムモーター超フル回転となるだけかもしれないが。
LT: Unofficial-Redmine-直近カスタマイズ事例紹介
- y503Unavailable@Redmine Kindle本出版unofficialcookingさん (@y503Unavailable) / Twitter
- Unofficial-Redmine-直近カスタマイズ事例紹介 | ドクセル
本旨である「直近カスタマイズ事例紹介」は面白いのだが LT として時間内にそこへ到達しなかった。有意義な活動をされており、それを紹介したい気持ちはわかる。けれど登壇へ期待されるのは本旨。なので先にここを取り上げてほしかった。
本旨のカスタマイズ事例では以下が本家に採用されてほしい。
このチケットに書かれているとおり本家 #19501 で検討されたが採用に至らず。しかしチケット起票者は課題の扱いについて特別な立場 (ステークホルダーなど) であることが多いから、それを選択したいことはよくある。そのため Redmine 標準で対応してもらいたいものだ。
というわけで本家チケットを改めてみたら注記へ @y503Unavailable さんによる再提案と +1 があったので私も投票しておいた。
LT: Redmine パッチ会やってます！
Redmine パッチ会の紹介。
パッチ会、興味はあるのだけど私はプログラマーで Redmine を利用していながら Ruby に縁がないのとタイミングのあわなさもあって参加できていない。
そういえば Slack の Redmine Free Salon にプログラマーではなくても参加して大丈夫か？という質問があり、大歓迎とのことだった。これをもってプログラマーであるがゆえ実装に貢献できないと参加する意味ないのでは？と考えていた私にとってもありがたい返答。なので来年こそは参加したい。
LT: Redmine Japan Vol.2 開催します
オンラインとなるが開催するとのこと。Vol.2 では Takuto Wadaさん (@t_wada) / Twitter が登壇される予定。この理由だけでも参加決定である。楽しみだ。
懇親会
今回はわりと真面目な話をした。オンラインであったためだろうか、珍しく？akipii さんが最後まで残って 22:30 ぐらいまで議論が白熱。楽しかった。内容は思い出として、それぞれの胸の内に。
おわりに
今回も楽しく有意義な情報に触れられた良イベントでした。登壇者と運営のみなさま、ありがとうございました！