アカベコマイリ

HEAR NOTHING SEE NOTHING SAY NOTHING

Redmine Japan 2020 感想

September 26, 2020イベントRedmine, Redmine Japan

2020/9/18 に開催された Redmine Japan 2020 とその前夜祭へ参加したので感想をまとめる。

Redmine Japan Eve 前夜祭

Redmine Japan 2020 は当初、アーツ千代田 を会場としていたがコロナウイルス禍によりオンライン開催へ変更された。システムは Remo とのこと。これはビデオ会議 + 仮想会場という感じのシステムである。

Redmine 関連のイベントでは redmine.tokyo 18 で Zoom を採用していたので今回もそうなると予想していたため意外であった。Remo 公式の解説動画や評判を見るに、参加者のテーブルを可視化して移動する機能により交流を促進するとかブースに応用できるといった利点があるらしい。

とはいえ Zoom ほどには馴染みのないシステムのため不安がある。これを解消するためだろうか？今回のイベントには前夜祭があり、その開催日よりも前倒して Remo 会場が参加者へ公開されていた。

私は前夜祭の当日に参加。LT を聞く。メモを取り忘れたので本記事 (9/26) の時点で資料公開してあるものだけ感想を書く。

プラグインに Vue.js をつかってみた

Redmine Issue Template 開発の話。Redmine 同梱 jQuery ではなく Vue.js で画面構築してみたとのこと。クライアント側で動的に画面を切り替える、すなわち UI の大幅な更新があるなら jQuery よりも Vue のほうが扱いやすそう。React もよいが Vue なら状態管理なども Vue ファミリーで揃うから環境構築にも悩みにくい。

そういば最近の WordPress は React/ReactDOM を同梱しており、プラグインやテーマから利用可能なのだとか。Redmine としては互換維持のため jQuery 同梱は継続する方針だろうけど、どこかのタイミングで React や Vue なども検討してほしい。

ただし Redmine 本体のクライアント UI 処理として jQuery 依存している部分がかなりありそう (エディターのボタンとか) だから、移行は難しそうだ。

unofficial redmine 紹介

Unofficial Redmine Cooking の紹介。Kindle で本を出したり YouTube チャンネル を運営するなど活発さに感心する。

そういえばこの活動、Redmine Japan 本編で紹介されていたパッチ会とも連携していたりするのだろうか？スライド中には言及されていないようだが。

JSだけでガントチャートを担当者ごとに表示する方法

ANKO ガントチャート を開発されている企業の方による登壇。Ajax を利用して JavaScript だけでガントチャートを担当者の単位に表示する方法を紹介している。

Redmine view customize plugin 的な感じ。私としては view customize plugin を本体提供にしてプラグインやテーマによる UI 構築は REST API + JavaScript のみで実装するほうが好ましいと考えている。直に DB 参照したり Ruby on Rails へ依存することは互換問題の原因になりがち。なので本登壇的というか view customize 方式が主流となるほうが好ましいのではないか。

REDMINE JAPAN 2020

Remo 開催にあたり会場が A 〜 C に分かれている。A と B は登壇、C がスポンサー用。タイムテーブルに記載されたスケジュールにそって視聴した順で感想を書く。

A02 基調講演 1 「Ruby にみる分散開発 OSS コミュニティ」

コロナウイルス禍により今回がオンライン開催ということも踏まえながら Ruby の分散開発と OSS コミュニティー運営について紹介。「良い」をどう定義するかがコミュニティーの価値観になる、というのに共感。これが支持されて賛同者が集まることで文化になる。有名な「設定より規約」もこうして醸成されたのだろうか？

Git について。開発にこれを採用したことでパッチをメールで送る時代から効率的で高度な分館開発が可能となった。コードは Git (GitHub)、Issue は Redmine のように管理を使い分けている。そういえば Redmine は SVN を採用していて GitHub リポジトリーはミラーなのだけど、これはなにか強い理由があるのだろうか？ちなみに RedMica はGitHub で redmica/redmica を運用している。

Issue 内で別の話題が発展しかけたら別の Issue へ切り出しているとのこと。これは私もそうしている。Issue はなるべく単一目的で小さくするのが放置を避けるコツ。複数の目的が終了条件を曖昧にして終わらず、いずれは放置される Issue の原因になる。なのでサクッと別 Issue を立てて「その件はこちらで」とするのがよい。

Issue と Wiki の使い分けが課題とのこと。これについては性質の違いで棲み分けられる。Isseu は合意形成や作業について過程も含めて記録するもの。Wiki は基本的に最終形だけを表示するため、資料や合意形成の結果を公開する場として利用するのがよいと思う。

私の場合、仕様書などの資料を Wiki で書く。その際にある機能だとか画面の Wiki ページに関連 Issue のリンクを貼ることにしている。こうすると仕様がどのような過程を経て決まったのか？または議論中であるのか？といった背景を共有しやすい。理不尽に見える仕様でも開発リソースを理由とした決断であったり、複数の選択から一つを採用しただけで別の可能性も検討されていたことがわかるなど、非常に有用なのでオススメ。

ソースコードと領分について。これは以前

で話題になっていた課題だ。まつもとさんはこれについて「エゴレス プログラミング」を提唱。自己と成果物は区別しましょう、という感じの指針である。これはプログラミング以外でも重要な考え方。「自分の心血を注いだ成果物」と認識したらそれに対する批判を過剰に受け取り、傷つきやすくなる。その過剰さは過大な防衛反応になりコミュニティー不和の原因にもなるだろう。なのでうまく距離を置きたい...のだけど、これはなかなか難しい。

ただしツールで改善可能な部分もありそう。例えばプログラミングにおける Linter や Formatter はコーディング スタイルという自己の出やすいものへ明確な客観指標を与えてくれる。しかも指摘や訂正は自動的だ。スタイルの議論をするとしても対人より前に指標たる規約が対象となるため揉めにくい。「自己 = エゴ」の投影をどれだけ回避するか？という点でこうしたツールは参考になるだろう。

A03 招待講演 「次期バージョン Redmine 4.2 の注目新機能」

Redmine 4.2 の開発状況と注目の新機能について。リリース時期は未定とのこと。4.1 が 2019/12 だったので 4.2 も年末になりそうな気がする。スライドでもだいたい 1 年周期になっていた。

新機能で最も期待しているのは 2 要素認証。方式は TOTP を採用している。これがきたら Redmine サーバーの IP 制限をやめる予定。在宅勤務における VPN 要因がひとつ減らせるので楽しみだ。

この機能も含めて機能紹介は redmine.tokyo 18 登壇を踏襲している。新しい情報として 2020/11 にリリース予定の RedMica は 2 要素認証を先行実装しているとのこと。うーむ、Redmine 本家と互換あるし公式 Docker イメージも提供されいるので移行したくなってきた。

移行するとしたら素の CentOS + ミドルウェア群で構築しているのを Docker (compose) へも切り替えて環境依存を抽象化するのが理想形。職場の Redmine は CentOS 6 上に構築しており、ミドルウェア互換が原因で Redmine v4.x へ移行できずにいる。ホスト OS が依存するミドルウェアは Docker のみとして「Redmine 環境を直に晒さない = ホスト OS を無視できる」ようにしたい。

B04 「RedmineをDockerに載せてみた」

Redmine の Docker 運用に興味があるので視聴。

Redmine 公式 Docker イメージは軽量化のため様々なパッケージを削除している。そのためそこへ依存しているプラグインが動作しない。その他、添付ファイル ディレクトリーを Volume マウントし忘れるとコンテナ切り替えで消滅するなどの問題もある。これらの対策として自作 Redmine Docker イメージ作成を提案します、とのこと。

私の期待値は「Redmine 公式 Docker イメージによる現実的な運用方法」だったので内容は高度すぎた。しかし抜群に面白い。身近な Redmine という題材による Docker 入門なのだから、楽しいに決まっている。Docker の性質を踏まえたデータ管理の作法など、実にありがたい情報だ。

では自作するか？といえばしない気がする。前夜祭の項で書いたとおりプラグインは REST API と JavaScript だけで構成されるのが互換性の観点から理想なので、公式イメージで動作しないものはリスクと認識しているのがその理由。

それでもこのスライドは Docker 理解のよい資料なので何度も読み返すだろう。もしかしたらそうしているうちにイメージ自作したくなってきたりして。

B05 「なんでRedmineなの？ 〜コミュニティの歴史と、これからのご提案〜」

ここから会場ごとに登壇がわかれる。A、B どちらもコミュニティー系の話で興味あったが今回は B を選択。A 側は後で見ることにする。

最近 Redmine コミュニティーでよく見かける yukia さん。redkine.tokyo 18 でも登壇されていた。

Redmine には 10 年もの歴史があり、コミュニティーもいくつか存在する。それらを尊重しつつ「これから」を応援するものとして Redmine Free Salon という Slack を用意。私も参加してみた。

ざっと既存チャンネルを読んだ印象としては Redmine 色が非常に濃い。規約もしっかり作られている。

これを読んだら #welcom を抜けることで同意とみなす、というのも面白い。

B06 みんなでRedmineを改善しましょう！「Redmineパッチ会」参戦！！

yukia さんの後に A 会場の高野さん登壇を見る予定だった。しかし Remo のトラブルで yukia さん登壇が中断され、急遽 B06 と入れ替えになった。どうやら A 会場も順番が前後したらしく、このタイミングで A 会場へ移動したら既に高野さんの登壇が始まっていた。

というわけで B 会場へ戻って、B05 (再開) と B06 (順番移動) の両方を見届けることにする。

Redmine を利用して見つけたバグを redmine.org へ報告しようとしたら膨大な残 Issue に圧倒された。ならばバグ修正や機能追加へ協力するためにパッチを送ろう！という感じで始まった会とのこと。Redmine 開発のエキスパート (前田さんなど) も参加しているため実践的な Ruby on Rails 開発の知見も得られてよさそう。

モブ プログラミング体制を採用している。ドキュメント整備とか新機能の議論などもあるのでプログラマー以外も歓迎とのこと。都合がつけば参加してみたいので Redmineパッチ会 - connpass のメンバーになってみた。Ruby プログラミングは未経験なのでその勉強にもよさそう。楽しみだ。

A07 「redmineと出会う前と出会ってからの７年　そしてこれから」

門屋さんの登壇。この方のプロジェクト マネージメント系の登壇は Redmine イベントでいつも楽しみにしている。今回は Redmine に対する回顧録からはじまり、Redmine エバンジェリストの会の活動紹介や PMBOK などについて語られた。

内容では終盤に挙げられた「これから取り組みたいもの」にあるセルフ マネージメントが特に気になる。この部分についてもっと掘り下げた話を聞いて (または議論して) みたい。

セルフ マネージメントは「セルフ = 自己」を含む。そのため放任のような印象を持たれるが、私は分割統治を機能させるための仕組みと認識している。つまり組織として対応するものだ。そのためのツールとして Redmine のような課題管理システムは非常に有効なはず。

指定された課題を解決してゆくうちに作業を依頼される側も管理を学ぶ。どのように課題を分解して実現可能な粒度とするのか。失敗をどう扱うのか。この体験を通し、やがては自主的にチケット運用できるようになればセルフ マネージメントである。Redmine 以外でもよい。しかしなにか期限や進捗のある作業を管理したいなら、自己流よりも Redmine のように専門設計されたツールをオススメする。

と堅い話を書いておいてなんだが PMBOK (Project Management Body Of Knowledge) って NWOBHM (New Wave Of British Heavy Metal) 感ある略称だ。声に出して読みたい略称。ちなみに (俗に？) これはピンボックと発音するらしい。

A08 「Redmine で実現する高品質なシステムの開発と運用」

  • 堀部壮彦さん
  • 公開資料、見つけられず

NTT コムウェアというのもあるのだろう、大規模かつ厳格なルールで運用される Redmine の話として面白かった。

トラッカーが 4 種類なのに対してカスタム フィールドは 200 超えというのは興味深い。大手 SIer ならトラッカーをたくさん用意してワークフロー運用という印象があったので。トラッカーに比べてカスタム フィールドのほうが影響範囲を抑えられるので複数の組織をまたいで運用するなら都合がよいのかもしれない。

機能面のカスタマイズとしては内製プラグインがあるとのこと。本体に手をいれず機能強化する利点をうまく活かしている。内製なら品質やバージョン互換なども自分で管理してゆけるし、NTT コムウェアのように開発力のある企業ならよい選択肢だ。

A09 「ある工場 と Redmine」

内容のよさは当然として、今回の登壇で配信の技術面が特にすばらしかった。Remo は登壇者とスライドを個別に配信する仕組みを用意している。しかし負荷の高さなのだろうか、これを利用した登壇は接続トラブルで切断されがちであった。これを踏まえて netazone さんは登壇配信のみでスライド中に本人のワイプをリアルタイム合成している。これで負荷が低減されたのか最後まで安定配信されていた。登壇者の顔や手振りも見えるので演出としてもグッド。利用したツールなどを公開してくれたら私もオンライン登壇で使ってみたい。

内容について。Redmine のよさに共感。Web ベースで OSS なのは強い。私が ITS/BTS というものを知ったのは 2001 年。ある企業で内製されたものだった。かなり大規模なプロジェクトで検証チームも大勢いたのだが、Web ベースであったため物理的な移動なくバグ報告や機能の議論ができたし、なにより過程が記録されていたので論拠になる。この体験から別の現場に移っても ITS/BTS を利用していなければ導入を提案するようになった。登壇を聞いていて、この 2001 年の衝撃を思い出していた。

コミュニティーのよさも同感。Twitter やブログで Redmine について言及すると、どこからともなく Redmine 界隈の人がやってきていつの間にか迎え入れられる。みなさん大人で付き合いやすいし、濃い趣味人も多いため話題も豊富で楽しい。

前述の Slack も含め、この交流に感謝しています。

A10 「Redmine 導入時のあるある」

Lychee でおなじみ、アジャイルウェアによる Redmine 導入支援で遭遇した「あるある」話。社内の Redmine 管理者 & 推進をしている立場として共感できたので項目ごとの感想を。

あるある 1 特盛！管理項目 編。

これは前職で遭遇。ソフトハウスでありプログラマーが多数だったので Redmine 導入はスムーズだったが、代わりに管理過剰へ陥りかけた。トラッカーに「〜確認」、「〜承認待ち」みたいなものがどんどん増えてゆく。「〜」には「営業」や「顧客」なんかが入る。こうするとワークフロー機能で強制力のあるチケット運用をできてよいのだが、前職は組織として小規模なため過剰だった。

これが向くのは広大で階層化の進んだ組織とか、長い歴史で培われた厳密かつ共有された現実のワークフローを再現したい場合であろう。実際、使われないトラッカーやワークフローが堆積していたので事情を説明して簡素化した。いまの職場も組織としては小さく複雑なワークフローは過剰なので、トラッカーを標準よりも減らして運用している。

あるある 2 まるっとぜーんぶ移行しちゃお。

さきほど書いた「現実のワークフローを再現したい」問題である。それを改めるより踏襲するほうが効率よい、というのでもない限り見直すべきものだ。業務のソフトウェア化は棚卸しのチャンスでもある。

あるある 3 組織は階層だ！ならば！

これは前に書いた Redmine 運用について 2/3 - 運用ルールと諸設定で言及している。スライドと同様に案件単位のプロジェクトを用意する方法でうまく運用できていると思う。階層が浅く末広がりとなることを意識している。可変長をどうやって制御するのか？が階層管理のポイント。業務なら大抵は「案件」が相当するので、その単位にプロジェクトを適用して階層の端にすると管理しやすい。

あるある 4 いきなり全く新しい運用。

これは私も失敗している。なにか素晴らしいツール (方法論なども含む) を見つけると、それが万人へ受け入れられると思いがち。そして導入に抵抗されると相手の理解不足に原因を求めたりする。物事はそんなに単純ではない。相手にも事情がある。なので十分な根回しとか、それが自分で難しければちょうどスライドで提案 (これは宣伝してもいい) しているとおりアジャイルウェアのような企業に支援を頼むのがよいだろう。Redmine ではないがウチは外部の研修で業務知識を補うというのを何度か実施していて、コスパの高さを実感している。

A11 「チケット駆動開発がまわりはじめるまでの取り組み」

チケット駆動開発のメリットを伝えるのってなかなか難しい。作業依頼や議論なら口頭や Slack でいいし、コードも SCM (Git など) でバージョン管理しているのだからチケット必要ないでしょ、という意見も聞いたことがある。

この問題に対する私の見解は以前、なぜ課題管理システムを使うのか？という記事にまとめた。そこで書いた「過程の記録」と共有が課題管理システム最大のメリットであり、本登壇の「導入しての成果」はよい実例だと思う。

後半の OKR (Objectives and Key Results) と絡めたマイルストーン運用が面白い。OKR、聞いたことがあるけどまったく未知だ。紹介されている本をどれか読んでみよう。

チケットの時間記録は私も習慣づけている。これは見積もりスキル養成ギプスとして有用。予定工数と実際にかかった時間の距離は見積もりのベンチマークだ。これを繰り返してゆくと「予定工数が設定不能 = 未知 = リスク無限大」を察知できるようになるため、どうやって「予定工数を設定可能 = 既知」とするのかを意識できるようになる。未知は見積もれない。対策として未知を既知とするための調査期間を設けるとか、担当の変更などを検討できる。

見積もりといえばプロジェクト開始前に検討して終わり、となりがち。けれど完全に見積もってから着手というのは難しい。プロジェクト開始後に新たな課題が発生することも十分にありえる。なので見積もりは「課題単位で常におこなわれるもの」と認識して、リーダーやマネージャーは総和と達成状況を定点観測しなければならない。

時間管理は非常によい機能なので GitHub Issues にも追加してほしいものだ。

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

  • モデレータ 松谷秀久さん
  • パネリスト 蘇田亮さん
  • パネリスト 小林稔央さん

パネル ディスカッション。これは視聴者による Twitter の TL でも意見が割れていて面白かった。

私としては「5. チケットによるタスク管理のリーダーシップを取る人がいない」がすべてだと考えている。多機能で自由度も高いツールなのでリーダーシップを取る人がいなければ簡単に破綻する。例えば以下の記事。

現在の職場 Redmine も私が入社する前は似たような状態だった。「プロジェクト = フォルダー」と認識されていたらしく、無秩序にプロジェクトが階層化してゆく。Wiki ページを分割するためにプロジェクトが作られることもあった。この問題は Redmine の理解不足が原因だろうか？違う。用意された機能を自分たちに好ましく利用しただけだ。問題はそこではなくルールの定義と施行を管理するリーダーの不在にある。

redmine.tokyo 14 の登壇、なじむ Redmine における「マメなサポート」ではこれを伝えたかった。定点観測して問題の芽を摘む人が必要なのだ。これを前提として初めて他の問題を議論できる。そしてこういう人を用意できてない、もしくはいるけど裁量がない、というのがタスク管理失敗 90% のさらに 90% ぐらいではなかろうか。

A13 基調講演 2 「with コロナ時代のアジャイルとコミュニケーション 〜効果的な場作りとツール〜」

アジャイル開発とスクラムで有名な平鍋さんによる登壇。冒頭に astah* の話題。平鍋さんが初期の開発者だったとは。astah*、GUI の操作感 (吸着とか) が素晴らしくて愛用していた。いまはプレーン テキストによる可搬性から PlantUML へ移行したけど、astah* も保存形式にこれを選べたら再び使いたいものだ。

副題に「効果的な場作り」と銘打つように「場」の話が面白い。コロナウイルス禍により強制的に従来の「場」は失われた。私の職場も 4 月から在宅勤務が基本となり、場をめぐる問題の渦中にある。個人としてはプログラマーという職であるため在宅でも回せているし、むしろ歓迎だ。しかし幾人かの社員がこの状況に苦しんでいることは知っている。それをソフトウェアで緩和できないか？というのをずっと考えており、この観点で登壇を聞いていた。

懇親会でも言われていたが平鍋さんとしては対面の文化や情報量を評価しているようで、本登壇でもそれをどのようにソフトウェアで再現・代替してゆくかについて考察している。例えばビデオ会議のカメラに向けて、あえて表現過剰にするとか。

オンラインだけで信頼関係を築けるか？というのも気になっている。登壇だと Management 3.0 Japan conf のくだり。短い時間でもチーム作りを通常のミーティングなどへ取り入れるのが重要なのだという。短いアイス ブレーキングを設けたり、チャットへ日常写真のチャンネルを用意して猫や家族の写真を投稿したり。この観点だと Colla はよい。会社の Slack へ導入したところ、割とみなさん質問に答えてくれて「人間の気配」を感じられる。回答のリアクションとして当意即妙の絵文字をつける遊びも定着しそう。

いまここ性、いい言葉だ。すばらしい登壇だった。

A14 「Redmine コミュニティの活動報告と今後の抱負」

redmine.tokyo の司会でおなじみ akipii さんの登壇。

関係してきた Redmine コミュニティーや勉強会の歴史を紹介。私は 2018 年の redmine.tokyo 14 から参加したのだよね。懐かしい。過去の主要な登壇まとめ。錚々たるメンバーだ。

参加者層の変化が面白い。私は 2010 年に親戚のソフトウェア開発会社を経営されている方から Redmine を教わった。そこがベンチャー系なのと v1.0 がリリースされる前だったので、先進的な開発チームが導入するものという印象だった。登壇資料によると初期はそんな感じで 2014 年あたりから多様な、例えば大企業なども利用するようになったらしい。

Redmine コミュニケーションの展望について。

参加者の多様化とエコシステムの確立を目指すとのこと。多様化については交流の場を構築する。今回の登壇にもあった Redmine Free Salon はそれを目指しているのだろう、規約もきっちり定義されおり企業参加にも応えられそう。

エコシステムはどうだろう。OSS で開発人員を増やすのは簡単なようで難しい。Linux や Ruby を参考にするなら Redmine 開発で生活可能なぐらいが目安か。メイン開発者の一人である前田さんのように Redmine でビジネスしている企業を増やしてゆくことになりそう。有志ならパッチ会を Redmine ビジネス企業が支援して大きくしてゆくのはどうだろうか。

その他

Remo について。面白く可能性を感じるサービスだ。通信トラブルがなく安定運用できれば今回のようなオンライン イベントにも向いていると感じた。テーブル モードで参加者の動向が可視化されるのは見ていて楽しい。安定以外の改善要望としては以下。

  • 会場移動
    • Web ブラウザーのアドレスバーから URL 末尾を打ち替えることで移動していた
    • 参加者によっては複数タブで開きザッピングもしていたらしい
    • Remo 内の機能として会場移動をサポートしてほしい
  • スポンサー会場
    • 休憩時間が昼食 1 時間、登壇間の 5 分なので訪れにくい
    • 昼食時を逃したら登壇を見送るしかない
    • 現実のカンファレンスもそうなっているが、物理的な体力消耗にともなう休憩として機能している
    • オンラインでは視聴中の休憩も取りやすいため、明示的にスポンサー会場を回る時間を設けないと移動しなくなるのでは
    • これは前述の会場移動が面倒なのも関係してくる
    • 私は試しに登壇合間の 5 分だけ訪ねてみたが、5 分だとアンケート回答すら間に合わなかった

最後に

登壇者ならびに運営のみなさま、おつかされまでした。

通信トラブルなどもありましたが、イベント全体としては非常に有意義で楽しめました。今後の開催にも期待しています！

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