redmine.tokyo 18 感想
2020/5/23 (土) に開催された redmine.tokyo 18 の感想。今回はコロナウイルス感染拡大を防止するための緊急事態宣言を受け、Zoom によるオンライン開催となった。
第18回東京Redmine勉強会『Redmineによるテレワーク運用』(2020/5/23) - Togetter
【Redmine 4.2 を先取り】RedMica 1.1 (2020-05) 新機能ハイライト
redmine.tokyo 17 で発表された Redmine ディストリビューション RedMica の新機能を紹介。v1.1 は 2020/5 中にリリース予定で My Redmine へも 6 月以降に順次反映してゆく予定とのこと。
グループをウォッチャーとして追加。
チケット情報を共有したくなる場合、今まではユーザーを単体選択していた。この機能があればそれをグループ単位で操作可能となる。そういえば 10 年ぐらい Redmine 使っているのにグループ機能を知らなかった。調べてみたら現状でも非常に便利そうなので今後は活用してゆこう。
ユーザー アカウントのメール アドレスに対するドメイン制限。
例えば example.co.jp を設定すると他のドメインによるアカウント登録を無効化できる。許可と禁止の設定が別れているため、ホワイト リストだけでなくブラック リスト運用も可能。メール アドレスのドメインに基づくアクセス制御ともいえる。社外と Redmine 共有する際に役立ちそうな機能である。
チケットや Wiki の添付ファイルを一括ダウンロード。
資料性のあるものはなるべく Wiki コンテンツにしたいが、そうできないことがある。例えば顧客からの MS Office 文書。こうしたコンテンツであっても Redmine から検索できると便利なため、Wiki に添付して資料まとめページ化したりする。こういう運用をしていると添付ファイルを一括ダウンロードしたくなることが結構あるので、本機能が役立ちそう。
優先度が高いチケットの更新をメール通知。
チケット更新のメール通知は便利だ。しかし条件設定がゆる過ぎて大量の通知をフィルターするのは面倒。本機能では優先度を条件とすることで通知量を抑止したり、逆に対象外のチケットでも優先度を上げることで通知 = 監視対象にできる。メーラー依存ではなく Redmine として設定できることが重要。これを契機に通知機能の強化が進むことを願う。例えば Slack 連携は標準でほしい。
CSV インポート時のフィールド対応関係を自動設定。
タスク管理を Redmine でほぼ完結しているため、外部連携になるだろう CSV 関連の機能は利用したことがない。しかし顧客や検証会社などから要求・要件や障害レポートなどが Excel で送られてきた場合、チケット変換するための中間形式として CSV はよさそうだ。そういう処理をしたくなったら本機能は役立ちそう。
プロジェクト一覧における標準の表示形式。
標準の表示形式は好みではなくて、自作テーマ minimalflat2 では JavaScript により開閉ツリー化している。しかし Redmine v4.1 からはリスト形式が追加されていたようで、本機能によりこれを標準に指定できるとのこと。リスト形式は開閉ツリーのようなので将来は minimalflat2 でカスタマイズするのをやめるかもしれない。
チケット画面のバッジ表示。
タイトル横に「完了」と「未完了」がバッジとして表示され、チケットが閉じられているかを視認しやすくなる。minimalflat2 も対応する予定。
Wiki ツールバーのテーブル挿入ボタン。
Textile/Markdown のテーブルについて GUI で列・行数を指定して挿入するためのボタンが追加された。Markdown だとセル結合が利用できないため正規化によりテーブルが増えがちなので、こうした手軽にテーブルを作れる機能は歓迎されるだろう。minimalflat2 はツールバーのボタンを独自の外観にしているので、これも対応する予定。
Wiki ツールバーの構文ハイライト ボタンにおける対象言語の絞り込み。
標準だとサポートしている言語すべてがリスト表示されるのだが、この機能で言語を絞り込める。ボタンから表示されるリストが対象となるため、そこにないものを指定する場合は Textile/Markdown 側で指定すればよい。どんなに多彩な言語を利用している組織でも 10 種ぐらいあれば十分だろうから、絞り込めたら便利なはず。
作業時間の詳細におけるグループ条件へ「チケット」を追加。
チケットごとにどれぐらい工数がかかっているのかを確認できるとのこと。メンバーがまめに作業時間を記録していればリーダーやマネージャーがプロジェクトの危うい兆候を検出するのに役立ちそう。そういえば作業時間、ちゃんと記録されているものだろうか。私は作業時間の提示だけでなく、自分にとっての見積もり精度養成ギプスとしても有用なので記録する派。
チケットがクローズできない理由を表示。
親子チケットで子が残っていると親はクローズできない。しかし従来はこれが説明されないため原因不明で混乱の原因となっていた。この機能によりこうした混乱は減るだろう。私としてはチケットや Wiki 更新時の編集競合エラーも送信ボタンを押した時点でページ遷移せずに警告する機能がほしい。
【RedMica 独自】アイコンのベクター化。
各種ビットマップ アイコンをベクター化。登壇ではたしか SVG と言っていた気がする。minimalflat2 ではアイコン フォントを採用した。多色化を考慮するなら SVG のほうがよいだろう。
質疑応答。
- Q. Docker Hub 対応しているか？
- A. していない、対応するとしてもこれから
- Redmine 環境構築と更新はミドルウェアのバージョンにも左右されるため、それらの管理を抽象化できる Docker (Hub) 対応はかなり需要あるはず
- プラグインやテーマ開発にも役立つので、ぜひ対応してほしい
- Q. 2 ファクター認証は対応しているか？
- A. していないが Redmine 4.2 で対応予定、パッチもあるので近く採用されるだろう
- 私の質問
- 職場 Redmine は安全性の観点から IP 制限しているため在宅勤務時に VPN が必須で管理が面倒、2 ファクター認証が採用されたら IP 制限の代替にしたいという動機で Twitter につぶやいた
- パッチというのはこれ Patch #1237: Add support for two-factor authentication - Redmine
RedMica は Redmine 標準で採用予定の機能やバグ修正を先取りするディストリビューションである。余程のことがない限り、本登壇で紹介された機能は採用されるだろう。そのため今後の redmine.tokyo で RedMica に関する登壇はレギュラー化してほしい。
これであなたもRedmine活動家
「活動」と「マイ ページ」は非常に便利で面白い機能なのだけど、利用している人をあまり見かけない。教えると感心される。Redmine は多機能すぎて UI や表示項目も多く、便利な機能や使い方が埋もれやすい。なのでこうして実際に活用している事例を紹介してくれるのは非常に有用だ。
この「活動」を枕として登壇では「活動家」について解説。Redmine 上の活動をチェックして自主対応 Level 1 から他者も含む調整を経て、活動そのものを変える Level 5 に至る。
今の職場だと Level 1.5 という感じ。私については概ね Redmine でタスク管理できているが、他のメンバーに対しての助言や調整はまだ弱い。タスク管理には感心はあるものの進捗管理を Slack 伝達で完結させたり、G Suite のスプレッドシートで WBS 風なガントチャート管理していたりする。
これについては否定も肯定もしない。いくら利点を説明して実例を示したところで Redmine のタスク管理に馴染めない人や部署はある。「記録」さえ習慣化してもらえれば、いつかより便利な選択肢として Redmine のチケットに注目してもらえるかな、と考えている。
ちなみに Wiki は非常によく利用されている。用途としては作業や進捗メモ、手順書など。「活動」で流れてくる更新履歴から他部署や社員個人の作業状況を知ることが多い。これをチケットにしてくれたらなぁと思ったりする。チケットによるタスク管理まであと 1.5 歩といったところか。
「伝わるチケット」の書き方
伝わる = 前提条件や文脈の共有、と受け取った。これはシステムで強制 (矯正) すべき部分と各人の表現で管理する方法がある。
例えばチケットのテンプレートはシステム。記述してほしい情報を明示することで過不足を避けられる。これは前提条件の説明も兼ねており、テンプレートへ触れてゆく内に自然とその分野を構成する要素を把握するだろう。
バグ レポートであれば現象、再現環境、再現手順、備考などがテンプレートになるが、これはそのまま検証担当と開発者の共通言語である。Redmine として非常に重要な概念だ。なので登壇で取り上げている akiko-pusu/redmine_issue_templates は本体機能として提供すべきと考えている。
もう一つのシステム部分であるカスタム フィールドについて。これはメタデータとして運用することが可能なうえに標準提供されている。だが私はあまり好きではない。Redmine の特徴に強力なカスタマイズ性がある。これは確かに利点なのだけどカスタマイズによって属人・属組織的なルールが増えがち。
なのでルールの汎用性と可用性を保つため、むしろカスタマイズ部分は減らしたほうがよい。カスタム フィールドはもとより、トラッカーとか優先度、ワークフローなんかも標準ですら多すぎ。便利な機能ではあるが強力すぎて制御が難しい、ならば本当に必要となるギリギリまで使用は控えましょう、と考えている。
チケットの表現について。
登壇では画像や添付ファイルを紹介している。
ついついなんでも文章として表現しがちなので
というのは正に。文章力やテキストによる表現は相当に属人的で曖昧なものだ。同一人物が書き連ねてすら振れが発生しがち。専門的な訓練か長い経験を経るでもしないと、整合性のある文章を書くのは難しいのだ。
なので視覚的な要素は画像や GIF も含む動画、外部化された前提条件があればリンクや添付ファイルの資料で示すのが大事。自分の言葉で書く、というのはよいことに思えるが業務では伝わることが第一である。
とはいえ文章も避けられないだろう。以下はチケットを書く際に私が心がけていること。
- 表現を定型化する
- 作業依頼、チケット解決 (終了条件の達成) の確認などは定形にしやすい
- 〜を実装 (作成) する、この対応でよろしければチケットを終了させてください、など
- 実行してほしいことを具体的に書く
- 〜してください、〜してほしいです、というのを念頭に書く
- Redmine であれば担当者やステータスなどの入力項目に対する操作依頼もオススメ
- チケット上で次になにをやってよいかわからないと放置へ一直線なので、実行してほしい操作そのものを書くとよい
- メモと依頼・報告をわける
- メモは冒頭に「メモ」や「覚書」と記述して他者が読み飛ばしやすくする
- 依頼や報告は担当者の変更と同時に書くことで、相手に作業が移ったことを明示する
- 常体と敬体をわける
- 作業記録などは常体
- 作業依頼や報告は敬体
- 読者が自分に対して書かれたものか否かを判断する材料になる
- 自分だけで完結できる (する) チケットなら最初から最後まで常体も可
- 自他どちらへ向けた文章か？ = 対象読者の違い = 文体の使い分け
だいたいこんな感じでチケットを起票したり注記を書いている。
「Redmine管理者入門！BacklogとRedmineの違いと、基本的な考え方 ～ Backlogで物足りなくなったら ～」
Backlog は利用したことがない。以下の有名な Git 入門記事 (社内教育で役立ちました。感謝！！) により存在だけ知ってる。
簡易に整理された Redmine、みたいな評判を聞くことはあって実際どうなの？と気になってたから登壇も興味深く見ていた。
スクリーンショットや解説から受ける印象は想像よりもかなり Redmine っぽい。外観はモダーンでもチケットの入力項目は多い。大きなものだと進捗率は削られているが、概ね Redmine と共通している感じ。
チケット以外だと機能面で有償無償の差があるらしい。本登壇ではそれらにより高度なワークフロー (これは Redmine 機能としてのそれとも掛けているのだろう) を実現するのに必要としている。これは標準で簡素化されているか多機能で複雑なものを簡素化 して (縛って) ゆくのかの思想の違いともいえるだろう。
Redmine、確かに高度なことができて嬉しいのだけど、標準では Backlog ぐらいまで簡素化して機能追加は少しずつ開放化してゆくほうがよいと思っている。
歴史的な経緯もあって今から標準を簡素化します、というのは難しいのだろう。新たな標準をどうするか議論して結論が出るとも思えないし。なので Redmine を利用しつつ Backlog や GitHub (特に Issues) みたいな競合が「なにをしていないのか」を知り、簡素化の検討材料にするのが大事。
例えば Backlog や GitHub Issues は進捗率がない。これはチケットを小さく作り素早く閉じることを促しているのではなかろうか。小さな作業の進捗を数値化するのは難しいためチケットは終了のみを管理する。進捗はプロジェクトまたはそのマイルストーンとしてチケット終了数から算出できれば十分だ、という思想。
これは Redmine にも応用できるだろう。そもそも進捗率を入力せずチケット終了、というのはよくあること。
Backlog といえば Git 連携がうらやましい。というか Redmine 競合だと Git リポジトリーのホスティング機能も組み込まれているのが多い。私は自前で Gitolite サーバー立てて Redmine と連携させているのだが、リポジトリー追加とか非常に面倒なので標準でホスティングしてほしいとずっと思っている。
Redmine + Teams = TeleWork
この登壇でいう Teams 部分はうちだと Slack + G Suite。
情報が永続的か否かで Redmine と使い分ける、というのにうちは悩んでいる。手軽かつ反応を得やすいのもあってか Slack が好まれがち。
Slack にも検索やスレッド機能はあるが、作業そのものや全体的な進捗を管理できるわけではない。そのため G Suite スプレッドシートなどの外部管理と併用している。これらは直に紐付いていないため、作業内容は Slack を検索するか遡ることになりスプレッドシートからそれを知る術もない。
検索にしてもメタデータ (モディファイア) が弱すぎる。
この機能だけで進行中の作業を管理したり、過去作業の履歴を探すのは難しいだろう。メタデータの代替としてメッセージをテンプレート化する方法もある。しかしそれはフリー フォーマットなテキスト解析が必須。正規表現でいけそう？現時点だとサポートしていないようだ。もし利用できたとしてもテンプレートの強制と正規表現の運用なんて現実的ではない。
用途が異なるのだ。そのため Slack で作業依頼や終了報告するとして、結局は頭の中か別媒体で進捗管理することになる。Slack は連絡や対話 = ヒトの管理ツールであり業務 = タスク = コトには向いていない。以下を読むに本格的な作業管理は別ツールと併用するのが現実的だろう。
なんとか Slack 中心勢を Redmine へ移行できないか？と考えているうちに何年も経った。私の訴求力とやる気の問題である。日々 Slack で流れゆく貴重な作業レポートを眺めながら、ああもったいない、しかしこれをチケット管理するための教育コストとか文化的な理解と衝突を思えばやむなしか...と悩んでいる。
それでも Redmine 運用できてる人はいるし Slack 中心勢を含めてリモートワークには移行できた。大きな問題も起きていない。本登壇でいうところの非同期な連絡と業務遂行は達成した状態なので、やはりあと 1.5 歩なのだろう。
ITシロウトがREDMINEと在宅ワークについて考えてみた
在宅ワークそのものは Web ベースで業務遂行できれば Redmine 以外でもよい。ただしタスク管理システムとして非常によくできてるし、在宅ワークは専用ソフトウェアによるタスク管理について馴染む格好の契機だと思っている。
Backlog の登壇で Redmine に比べてフラットな組織に向くとあった。逆に本登壇の冒頭に挙げられているように大きなな組織なら Redmine のほうが向くのではないか。
私は小さな会社でフラット側にいるため簡素化して運用したい。しかし大きな会社ならむしろ分割統治されている子会社や部署の独自ルールをソフトウェア化 (モデリング) するために Redmine の多機能さが役立つだろう。
ルール統一と汎用化、その結果として簡素化されるのが理想。そのための第一歩としてまずは複雑なものをそのまま Redmine へ落とし込むのはどうだろう。その過程がルールの棚卸しにもなるのではなかろうか。
Redmineの優先度を自動で更新するプラグインの紹介
- hin-t さん
- 資料リンク見当たらず
Redmine の IP 制限をプラグインで実現しているらしい。うちは iptables/firewalld。高機能だが IP 制限さえあれば十分なのでプラグインほしい。できれば Redmine 本体についてると更によい。単一サーバー内で複数システム運用していて Redmine だけアクセス (IP) 制限したいというのはありそうだし。
本題の優先度を自動設定するプラグインについて。
時間経過などの条件により優先度を自動的に変更するとのこと。チケットの放置を防ぐための強制力としてよさそう。
時限爆弾みたいだ、と想像してチケット一覧で優先度により爆弾アイコンとか表示されたら面白いと思った。爆弾が並んでゆく。期日を過ぎると爆発する。複数の爆弾があると優先度「通常」のチケットにも連鎖して爆弾化したり誘爆する。不謹慎かな。
RedMica でチケット状態に基づくバッジやクローズできない原因の通知について紹介していた。これらのように視覚的な装飾・演出によって状況をわかりやすくするのはよい工夫だ。
優先度の自動変更は更に一歩、踏み込んで状態そのものを操作する点が面白い。ユーザーの明示的な操作なしに自動更新してよいのか？という意見もあるだろうけど、運用の可能性を広げる観点を追加してくれたという意味でこのプラグインを評価したい。
労力最小のGitHub/GitBucket連携プラグインの提案
自前で Gitolite サーバー立てて連携させているので、この運用コストを外部化できたらという点で大いに共感する。
ただし GitHub/GitBucket は共にチケット (Issue) 管理を提供している。この機能は Redmine が勝るのだけど、代わりに単一システムで Git リポジトリーと Issue を管理できるメリットが非常に大きく。チケット管理が貧弱でも一元化したほうがよいか、と感じる。
そのためやはり Redmine 本体に Git リポジトリーのホスティング機能がほしい。ただし Redmine は Git 以外の複数 SCM とも連携できて中立なことも評価されているだろう。なのでホスティングするなら全対応する、その実装コストは高すぎる、Git だけ対応する = 贔屓が許されるか、というジレンマに悩んでいるのではなかろうか。
もしプラグインを作るとしたら外部システム連携よりも Git ホスティング機能を追加するほうがよさそう。プロジェクト管理からリポジトリー追加と連携を自動設定してくれるような。Git 管理を Gitolite へ決め打ちして Wrapper 実装するのなら案外いけそう？
Redmine Japanで会いましょう
- Kawabata Mitsuyoshiさん (@agilekawabata) / Twitter
- 資料はアクセス制限されているためリンクなし
新しい Redmine カンファレンス イベント、Redmine Japan の紹介。2020/9/18 に初開催を予定しているとのこと。
redmine.yokyo が春秋開催なので晩夏から秋にかけて Redmine コミュニティーが賑わいそうだ。Matz 氏も登壇予定なので参加者も多そう。
できれば参加したい。期待してます！！
懇親会
今回はオンラインなので懇親会は中止だと予想していたのだが Zoom 開催となった。事前通知があれば身支度を整えておいたのだけど、そうしていないためビデオはオフにして参加。
Zoom は以前、Vivliostyle イベントで登壇した際に利用したことがある。
この時は Zoom クライアントをインストールしたのだがセキュリティー面で不安があり、イベント後すぐにアンインストールした。以降の Vivliostyle 開発者会議では Google Meet を採用している。会社のビデオ会議もこれ。個人的にオンライン飲み会へ 2 度参加した時も Google Hangouts だった。
そんなわけで Zoom に馴染みがなく redmine.tokyo 18 本編もクライアントではなく Web ブラウザー版 (on Firefox) にした。それでも視聴に問題はなし。では懇親会のように発言ありならどうか？と不安と期待まじりで参加したら非常によかった。
@netazone さんの仕切りで懇親会がはじまった。Zoom の機能を利用して 5 人ぐらいのランダムなメンバーによる小部屋へ分けるとのこと。小部屋には制限時間も付けられる。今回は 30 分へ設定。
よかったというのはこの機能と運用。リアル飲み会でも複数テーブルに分かれることがあるけど、テーブル間の移動は任意である。そして大抵は数人が移動するのみで残りはそのまま。見知った集まりならこれでもよい。しかし不特定多数の参加する懇親会であれば未知の交流こそ醍醐味なので、移動やメンバーのシャッフルを促す仕切りがほしい。Zoom の機能はそれを叶えてくれる。
懇親会の話題はやはりコロナウィルスとリモートワーク関連が中心だった。Redmine を利用または感心のある層にとって業務を Web で管理するのは身近だしリモートワークはその先端なわけで、おのずと盛り上がる。
リモートワークにおける個人宅の部屋と通信環境について悩んでいる企業はそれなりにいそうだった。うちもその一つ。生々しい悩みから、それを奇貨とした前向きな展望まで充実した議論をおこなえた。
まとめ
懇親会も含めたオンライン イベントとして大成功ではなかろうか。地理的な制限もなく質疑応答も Twitter からリアルタイムに投げかけられるので間口の広さという意味ではリアルよりも好ましいといえる。
ただ登壇者としてはリアルな聴衆の反応が見えないのは寂しさと困惑があったかもしれない。
私も前述の Vivliostyle イベントでオンライン登壇した際、自分の発表が届いているのか非常に不安だった。登壇後に Twitter の反応をみてほっと胸をなでおろしたものだ。この点について redmine.tokyo というか日本の Redmine コミュニティーは Twitter の発言が多いからよかったのかも。
今回のイベントでサブ ディスプレイがほしくなった。登壇、または視聴と Twitter の反応や調べ物をする Web ブラウザー画面は別にしたい。ビデオ会議や勉強会にも役立ちそうなので買うかも。とりあえず iPad Pro とヘッドセット用途で AirPod Pro かな。
総じて楽しく学びの多いイベントでした。運営、参加者の皆さんありがとうございました！