アカベコマイリ

HEAR NOTHING SEE NOTHING SAY NOTHING

redmine.tokyo 19 感想

November 29, 2020イベントRedmine, redmine.tokyo

2020/11/14 (土) に開催された redmine.tokyo 19 の感想。前回に引き続きコロナウイルス禍を考慮して Zoom によるオンライン開催となった。

Redmine 4.1・RedMica 1.0ユーザーのためのRedMica 1.1 (2020-05)・1.2 (2020-11) 新機能ガイド

講演 1、となっているが今回は LT とパネル ディスカッション中心で講演はこれのみであった。

紹介されている新機能は redmine.tokyo 18、Redmine Japan 2020 で概ね既知。新しい情報としては RedMica 1.2 がリリース直前 (2020/11/18 に無事公開) という点。Redmine 4.2 は年内にいけるかも？という感じでまだ未定らしい。

RedMica 1.2 では待望の 2 要素認証が提供される。職場の Redmine は IP 制限しており在宅勤務だと VPN が必要で面倒だ。これを脱するにあたり 2 要素認証が安全面でよき代替になることを期待している。

続 なぜ Redmine によるタスク管理が失敗するか

パネル ディスカッションその 1。Redmine Japan からの続き。

ディスカッション内でも触れていたが最後は人や組織の話になってしまう。Redmine はツール。どう利用するかは人なのでタスク管理そのものの価値を理解していないと、Redmine のような ITS へ馴染めないだろう。以下は私の関連ツイート。

それと折に触れて言及しているがタスク管理は Excel などのスプレッドシートで運用しているものの Redmine に馴染まないのは初見の多機能さにあると考えている。誰しも学習や決定コストは下げたいものだから「多機能 = 自由度の高さ」はよほどモチベーション高くないと厳しい。

Planio と私の 604 日

Planio を初めて知った。Redmine を元にカスタマイズされた ITS とのこと。同じく Redmine 系の SaaS である My Redmine に比べて外観やわかりやすさを重視している印象。調べたらドイツ発のソフトウェアで日本進出においては My Redmine でおなじみのファーエンドテクノロジーが協力していた。

この登壇は Planio 導入から実際の運用までをめぐる 604 日のダイジェストになっている。とはいえ基本は Redmine なので共通する話が多い。以下、印象に残ったところ。

外部ベンダーとの連絡手段。

PPAP をやめるためにドキュメントの受け渡しはチケット添付、または Git/SVN のプライベート リポジトリーを利用。私も前職の Redmine で取引先と共有プロジェクトを用意して同じ運用をしていた。

Planio 的な特徴としてはリポジトリー。My Redmine と異なり Planio は自身でリポジトリー作成と関連付けがおこなえる。つまり GitHub のように利用できるのだ。これはかなり魅力的。ただし Redmine ベースでチケットがシステム全体で連番となる仕様も踏襲しているとしたら、チケット番号によるコミットとの関連付けは分かりにくいかも。

作業時間を管理する。

この機能は Redmine ならでは。かつ非常に有用だと考えているので実用例の存在は嬉しい。入力を習慣づけると見積もりスキルを鍛えるのによいため、時間契約でない業務にも強くオススメする。作業時間、Redmine がチケットの開始日と期日から初期値を自動計算してくれたらもっと活用されると思うのだが、どうだろうか。例えば 1 日を 8 時間と設定したら 2 日なら 16 時間が初期値になる、みたいな。

ヘルプデスク機能。

特定のアドレスにメール送信すると内容に応じてチケット登録される。チケットの注記でメールにも返信されるのは便利。これは取引先に Planio 操作させたくないがメールを起点としてチケット管理はしたい、という用途によさそう。ヘルプデスク以外にもそういう場面はあるかも。Redmine にもほしい機能だがメール サーバー中継などの環境面で難しそう。

総じて Redmine を導入しにくい、できない組織へ訴求するようにうまくカスタマイズされていると感じた。既に Redmine 運用している場合でも DB などを送れば移行を手助けしてもらえるそうなので、金額などが折り合えば魅力的な選択肢といえる。実際、私も Redmine 運用している立場として強く惹かれた。

こんな Redmine の使い方はイヤだ！の紹介

  • ながやす しんやさん

ひさびさにわろた。こういうチケットがたくさんつくられたのがむかしのレッドマインなんだよな。いまのしんざんはむかしのレッドマインをしらないからこまる。

全チケット全員ウォッチャ。

とりあえず関わっていそうな人はすべて会議へ呼ぶ。そうするのが無難だろう的な。大手企業の会議ってこういうのが多かった。そして人数分の資料が大量に印刷されてオフィスの片隅に遠足のしおりでも作るんですか？というパワー スポットが出現するのだよね。並べた紙を順番にとってホチキスどめしてゆく人、人、人。個人的にはウォッチャーが 5 人を超えたらチケットの粒度が大きすぎるから分割の好機だと考えてる。

半年先まで 1 日単位チケット。

作業の粒度を考慮していないのだろう。これは見積もり時点ですべてが自明、例外も起き得ないという前提がない限り無理。高度にマニュアル化された業務、例えばファーストフード チェーンでもないとそんな計画は立てられない。対策としてロードマップ (バージョン) を利用して漸進的に調整したとのこと。ロードマップ、ソフトウェアのバージョン (semver が有名) や慣習的な節目にしか使われない印象。しかしチケットの期日と時間管理において非常に有用なので期間を定義できるものなら積極的に使うことをオススメしたい。それこそ「〜調査期間」とか「〜見積もり」みたいに実作業へ入る前の管理なんかにうってつけである。

塩漬けチケットの山。

漬け込んでも旨味はでないし土へも帰らないから積極的に閉じるのが吉。私も「〜の間、放置されているので終了します」というコメントを添えて放置チケットをまとめて閉じることがある。期日を過ぎて一定期間、放置されてるチケットをこのような感じで閉じるか警告通知をだす機能が標準でほしい。チケット一覧で色が変わるだけじゃ足りない。毎日、放置されてるぞと警告メール送信するぐらいでも OK。

退職届チケット。

案の定、どうやってチケットを閉じるのか？という反応が多い。最近は GitHub で社則とか履歴書なんかを公開編集するのを見かけるので意外によい使い方だと感じた。人事選考プロジェクトを用意して公開範囲をコントロールしながらチケットで相談するのはどうか。人事選考って必要以上にタブー視されてて議論も知見も属人的すぎる。パワハラや揉め事の原因にもなりやすいから言質をテキストで記録しながら複数人でレビューする仕組みはあったほうがいい。チケットはこの点で向くのではなかろうか？

あなたは誰かのガントチャートを描けますか？

  • あいちゃん ２号機さん

Redmine を題材とした寓話絵本の朗読。こういう技術系のイベントでは初めてみるスタイルだ。「あいちゃん ２号機」さんによって朗読され代理となる方が司会として前説や録画再生などを担当、という体裁になっている。解説系の動画で VOICEROID とかゆっくりボイスが普及しているしコロナウイルス禍によるリモート化の流れもあるから、編集を凝らした動画で登壇というのは選択肢として有用かも。

チケット運用してるとその時点の空気や感情を記録してゆくことになる。ここで物議をかもした、評判のあの機能はコメントの些細な覚書からはじまった、といった感じで。過去のチケットを読み返す時はたいてい今の課題を解決するための知見を期待しているのだが、同時にこういう当時の空気も喚起されることになり、本題を忘れてひたってしまうことがある。走馬灯的というか。人間が書くものだからどうしても生々しくなるし、むしろそういう部分も積極的に記録したほうがいい。

本編を眺めながら↑みたいなことを考えてた。

テレワークにおける Redmine とチャットを含む業務の進め方について

パネル ディスカッションその 2。

うちは 4 月から在宅勤務が中心となった。利用ツールは Redmine/Git、Slack、Google Workspace (旧称 G Suite)。私がプログラマーということもあり出勤中心だった時からコミュニケーションはこれらのツールでまかなえていた。そのため業務としての変化はあまり感じていない。

一方、本題のチャット (Slack) については思うところがある。もともと Redmine と Slack がうまく棲み分けできていなくて、チケットで管理したほうがよいものも Slack になりがちだ。これは今も解決できていない。ただし口頭のやりとりはなし崩し的に「Slack = テキスト」へ移行されたのでチケットへ転載しやすくなった。これを機に非同期テキストのコミュニケーションへ慣れてもらい、そこから Redmine のような ITS へステップアップしてもらえないかと検討している。

私の考えた Redmine より Slack が好まれる理由。

  1. 入力欄が基本的にテキストのみ
  2. メンション通知
  3. 絵文字リアクション
  4. スレッド機能

1 はチャットだから当たり前なのだけどタイトルやトラッカーなど不要で、とりあえず思ったことを書けば課題管理の起点 (チケット登録) となれる。担当は 2、既読は 3、既読以上のやりとりがしたければ 4 を使えばよい。チケットに比べて圧倒的に楽。作業単位が小さく短期ならこれで十分に運用できる。そのため Slack でいいや、となるのだろう。これにタイトルと諸々のメタデータを付ければ Redmine チケットになる。あと一歩なので推してゆきたい。

会議について。「会議で発言しない人は呼ばない」正しい。圧倒的に正しい。

私は会議が好きではない。正確には複数人の同期的な対面の議論を非効率と考えている。議論は非同期テキストによるコミュニケーション、つまり Redmine や Slack などのほうが向く。それでも対面の会議を求める動機、例えば慣習や情緒などは認めるので参加はしてきた。こういうのも組織の輪を維持するうえで必要なのだろうと。

在宅勤務になってから、こうした対話や会議はほとんどなくなった。たまにビデオ会議はあるもののカメラはオフにしている。発言しない場合はマイクもオフだ。これで十分に会議は成立してる。リアルな会議だと一言しか発言しないものでも 1 時間ぐらい拘束されていたがビデオ会議でこのスタイルならオンデマンドに数分の参加で済む。要点を把握可能なぐらいは話を聞いているしメモもとるけど、リアルに比べたら大幅に省力モードだ。

そして実感。リアルな会議も本質はこんなものだと。ほんの数分を発言するために 1 時間、じっとしていたのだ。そしてその程度の立場なら参加する必要性はかなり薄い。Redmine や Slack で代替可能だし、これらのほうが言質もテキストで残るし万々歳じゃないか。

というわけで会議が必要最小になり、参加しても個人の裁量で効率 (省力) 化しやすくなった現状を歓迎している。

CODA チケット管理システム

JAXA による Redmine ベースの Web アプリケーション CODA 運用事例。

チケットの凍結と解凍。

承認 (終了) されたチケットに対して編集が発生することを防ぐための機能を実装。Redmine でもワークフロー機能でステータスに応じてチケットを読み取り専用とすることは可能だが、注記の追加や編集、ファイル添付などは防げない。この機能はこれらも禁止する。具体的には編集操作 UI を非表示化。ステータスを「進行中」などに戻せば再表示されるとのこと。実現には view customize plugin を利用。

登壇を聞いていた時は「この機能、本当に必要？」と感じたが改めて考えると要る。コメント (注記) の編集はチケット上の履歴として見えないため、通信や DB のログには残るかもしれないが Redmine 上では改ざん可能といえるだろう。編集可能であることは「チケット終了 = 合意形成の保証」を壊す。そのため Redmine として明示的に終了チケットの編集をステータス以外、無効化する機能はあったほうがいい。

親子チケットについて。

業務の構造化や可視化のために親子チケットが流行るも、いまは沈静化して慎重に使うようになったとのこと。私も前職で同様の経験をしたので納得。この機能を知るとモデリングするのが楽しくて、いつの間にか巨大なツリーができあがる。そして登壇で指摘されているような親子関係ゆえの所属・所有の問題によりがんじがらめに。

プログラミングにおける継承の問題みたいだ。できるだけ避けて、それでも必要なら階層は浅く保つ。継承よりも委譲を。具体的な数字としては、せいぜい 2 階層で子を 5 以下とするのが管理面の限度だと考えている。それと有効な時期もあって、ソフトウェア開発ならプロジェクト初期で仕様の粒度が大きい場合の分割管理には有効。開発が進むにつれバグ修正や単発の機能追加が中心となるため親子チケットの適用できる場面が減る、という感じ。

設計ドキュメント考 ～これからの Redmine が更なる進化を遂げるために～

Redmine の開発体制を題材としたソフトウェア設計論。

設計ドキュメントを整備して、開発プロセスもそれに倣うようにすれば慎重さと変化を両立できるのでは？という提案からはじまる。これは賛否のわかれる方法で組織的にしっかりと期限のある開発するなら必須で SIer なら前提。いわゆる Web やモバイル系だと変化の激しさや人員の少なさからドキュメントを維持するコストが見合わなくて「わかってるけどできないね」となりがち。

私は両方とも経験してるが、はじめに触れたのは SIer 的なドキュメント重視なプロジェクトなのもあって Web やモバイルでもドキュメント主軸で開発する派。仕様と合意形成をテキストにしないと揉める、という事例を見過ぎたというのもある。

そして具体的な方法だが、本登壇で提案されてる Design Doc に近い。基礎となる不変の仕様を定義しつつ更新を前提にしたら自然とそんな感じになるのだろう。詳細を書きすぎないというのが重要。そこはコードや Redmine チケットでよい。私はドキュメントを Redmine の Wiki で書き、仕様策定と合意過程はチケットにしている。

こうすると Wiki 上の仕様部分にチケットのリンクを列挙して詳細や関連する議論と連携できてよい。当然、チケットには現在進行系のものもある。これこそ生きたドキュメントではないか。せっかくの Web システムなのだからリンクを活かそう、という方針である。

本登壇でも結論は Wiki だった。Redmine といえばチケットみたいな印象があるけど、私は Wiki が標準で用意されてることも重要だと考えている。それはこのようにチケットと組み合わせることで生きたドキュメントを書けるから。ソフトウェア開発でドキュメントが軽視される原因は「静的 = 固定」と認識されているのでソフトウェアの「動的 = 柔軟」な特徴と相性がよくないからではなかろうか？この齟齬を埋めるものとして Wiki とチケットの組み合わせによる「静動の両立」はもっと評価されてよい。

複数 Redmine 環境におけるユーザ管理の効率化

複数の Redmine を連携させる方法の提案。

Redmine を Primary/Secondary にわけてユーザーなど共有したいものは Primary へ定義、それを DB 上で Secondary 側へ伝搬 (複製) することで連携させるとのこと。伝搬にともなう状態の矛盾についても個別に対策されている。技術的に面白い。Redmine 本体として複数連携する機能、例えば同一 DBMS 内なら Secondary となる DB 名を指定すると本登壇のような連携をするとか想像しながら聞いてた。

一方で複数 Redmine という状況そのものを避けるほうがよいと考える。ITS として有名な Trac は 1 システム 1 プロジェクトなので、これを利用していた際は自前で似たようなことをしていた。しかし Redmine を知り、アクセス制御可能な複数プロジェクトに馴染んだ身としては複数連携をがんばるよりも単体でまかなう方が好ましい。

企業文化として、特に大きなところだと組織横断でシステム統合は難しいのだろう。それでも設計思想として向き不向きはあって、Redmine は明らかに単一統合するものとして設計されている。そのため本登壇のように連携が技術的に可能であっても、それは伏せて単一統合するように提案したい。

プログラミング稼業をしているとこういう「設計思想として不向きだが技術で対策可能」な場面に何度も出くわす。単なる実装者を超えて設計者としてやりがいのある仕事ともいえる。そうした時、技術カードを切るのか？政治 (交渉) で済ませるのか？は悩ましい。けれどプログラマーとして長くやってゆくなら政治も重要で、例えば「うちでも Google Maps みたいなの作れないかな？いまいる 4 人で」みたいな提案をやりすごす寝技が必要なのだ。もしくは Google Maps へ自作のガワだけかぶせて「できました」と言えるぐらいの胆力も。

トラッカーの設定をコピーする方法

最初の膨大なカスタムフィールドが写っているスクリーンショットでめまいがする。これはトラッカーにも影響して、新規作成の際に必要なカスタムフィールドを個別にチェックしてゆく必要があって厳しい。この問題を解決するため、プロジェクトやロールのようにトラッカーもコピーできるようにしてみた、というのが本登壇。

実装は JavaScript でほんの 10 行ぐらい。どれぐらい需要があるか分からないと締めているが、ニッチであればこそ、こうして小さなスクリプトで局所的に拡張するのに向くので適材適所だと思う。

そして毎度のことなのだけど Redmine View Customize Plugin さえ標準バンドルされれば、本体でまかなえない用途の大半は本登壇のように「JavaScript で対応して」と言いやすくなるのでそうなってほしい。

ユーザー ディスカッション

「Redmine の UI 改善」部屋になった。本日登壇された Juno NISHIZAKIさん、前田さんたちと議論。

  • UI/UX 改善といっても現在の開発体制では難しそう
  • 人員的に山積しているコア機能拡充やバグ修正で手一杯なのでは
  • UI/UX は重いので即物的かつ低コストな対応はなさそう
  • RedMica の独自拡張は DB 互換や本体コードを変更しないためにプラグイン実装する方針
  • Planio は Redmine 3.4 ベース
  • Planio は著名な Redmine プラグインを fork して Planio 互換を維持している
  • Redmine 本体の対応が難しいなら RedMica みたいに UI/UX 改善をまとめたプラグインとするか Planio みたいに fork だろうか

という感じの話をした気がする。

懇親会

最初の部屋でボウコバさんと一緒だったが、いきなりラーメンをつくりはじめて乾杯ならぬ麺杯してて面白かった。いろいろな人と話したが、Redmine ネタより雑談が多めだった感じ。酔いもあって楽しかったということぐらいしか覚えてない。

2 時間ぐらいで 10 人ぐらい？まで人数が減ったので部屋わけをやめたが、この人数でも同時に話すのは厳しいので 5 人ずつぐらいにしたほうがよいと思った。というわけであがり。

まとめ

これだけ回数を重ねても話すネタが尽きず継続しているのはすごい。私も 14 回から数えて 6 回目の参加になるが、毎回こうして登壇の感想をけっこうな文章量で書こうと思うのもネタの面白さゆえ。

今回も楽しませていただきました。ありがとうございます！！

Copyright © 2009 - 2024 akabeko.me All Rights Reserved.