Redmine

2020/09/18

RedmineJapan2020が無事に終わりました #RedmineJapan

本日、RedmineJapan2020が無事に終わりました。
講演者と参加者の皆さん、スタッフの皆さん、ありがとうございました。
今日は本当に疲れたので、まずはメモしておく。

【参考】
タイムテーブル | Redmine Japan

REDMINE JAPAN 2020 オンライン開催 - connpass

今日は朝9時から19時半まで、自宅の机とPCに張り付いて、気づいたら外は真っ暗。
基調講演から最後まで、どの講演も素晴らしくて、興味を引いて、気が抜けなかった。

Matzさんの話は、Rubyのリモート開発と、開発をリードする立場の事情話。
自分の意見と自分が書いたソースコードは違う。
エゴレス。

みうら(あに)さんはTwitterを使っています 「(自分思い出し用)1) OSS→コミュニティベース開発→PdM:「よい」とは?⇒同じ方向見れるか?⇒求心力/哲学 2) ツールの支援:円滑な意思決定⇒分散SCMのよさ⇒Issueベース⇒フロー/ストック⇒Wikiの使い方 3) コンフリクト解決:コードより知見大事、エゴレス、ゆるやかにつながる #RedmineJapan」 / Twitter

東芝やNTTコムウェアの開発プロセス標準とRedmineをベースとした開発基盤の紹介。
大企業の内部事情が分かった感じ。

@akiko_pusuさんのLTは、朗読のようなナレーションで聞き入ってしまって、聴衆の皆さんも思わず泣きたくなったのではないか。

平鍋さんの話は、リモート時代でのアジャイル開発のコミュニケーションの取り方。

akipiiさんはTwitterを使っています 「#RedmineJapan 平鍋さんが最初に作ったastahも、平鍋さんが書いたソースコードはもうない。インターフェイスだけ残っている。そういう意味では、設計思想が優れていた、ということなんでしょうね。」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan 平鍋さんは工学部出身だから、場と言えば、電磁気学や量子力学を連想されたのかな?」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan 古典力学はコマンドコントロール。場の理論は、チームの空間から力が生まれる。なるほど。」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan ティール組織は場がない。スクラムは場がある」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan リモートワークの場作り。リモートワークの基本の最初は、速いインターネット回線」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan デジタルでは表現者が優位。過剰な表現で十分」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan ネットワークの7層モデルと、コミュニケーションモデルの比較。物理層は、信頼関係に対応するのでは、という仮説」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan タックマンモデルも、最初の混乱期までは合宿して、それからリモートに移行する。でも、コロナ時代はどうする?」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan これからのチームビルディングは、合宿無しの継続的なチームビルディングへ。」 / Twitter

(1) kabukawaさんはTwitterを使っています 「#RedmineJapanA いまここ性 here-now-ness」 / Twitter

リモートワークの時代では、チームビルディングの手法はオフラインとは変わってくる。
五感のうち、見る・聞くしかチャネルがない。
だから、自己表現を派手にするぐらいでないと伝わらない。

すると、チームビルディングでは、タックマンモデルの形成期・混乱期がリモートワークでは難しくなる。
いかにそういう場をオンライン上で実現するか?

パターン言語を用いて、アジャイル開発の秘密基地のパターンを作っていた。
同様に、リモートワークのアジャイル開発のパターンが作れないか?
そのパターン言語を作ることで、リモート時代の特徴や本質が見えてこないか?

同時並行で見れなかったB会場では、RedmineのDBアーキテクチャの説明、RedmineのDockerのお話、ファーエンドさんのAWSでRedmineサービスを作った裏話、なども聞きたかった。
動画を準備しているので、ゆっくり見てみたい。

Redmineというテーマで、オンライン参加者が300人もいるイベントを実現できて本当に良かった。
Redmineは、開発プロセスの構築とそれを支えるPJ管理ツールの話と、実際にPJ管理ツールの開発基盤を構築するためのインフラ環境やRedmine本体の改善の話を同時に議論できて面白い。
そういう話をコミュニティで10年も継続できたことがすごいな、と思う。

| | コメント (0)

2020/09/13

RedmineJapan2020の見所 #RedmineJapan

9/18金に予定するRedmineJapan2020の見所について、スタッフの一人としてメモ。

【参考】
タイムテーブル | Redmine Japan

REDMINE JAPAN 2020 オンライン開催 - connpass

RedmineJapan2020の見所は3つある。

一つ目は、Redmineに関する日本最大のイベントになったこと。
発端は、@agilekawabataさんの発起により、Redmineに関するイベントを開催しよう、という話。
そこから、いつの間にか、参加者500名を超える大規模なイベントになった。
大阪や東京のRedmineコミュニティでも、50~100人前後がせいぜいなので、参加者だけでも、オンラインとはいえ、経験したことのない規模になった。
それだけ、Redmineに興味のある日本人が実は一定の層だけいることを示しているのだろう。

2つ目は、多種多様なスピーカーによる講演が目玉であること。
Redmineをテーマにするので、講演の数が集まるか、スタッフとしては不安だった。
しかし、蓋を開けてみれば、あっという間に応募枠は埋まったので、とても嬉しい。
理由を推測すると、大阪と東京のRedmineコミュニティが10年以上も継続的に存続してきたので、熱心なユーザが常に存在していたのだろうと思う。
また、ソフトウェア開発のプロジェクト管理だけでなく、製造業の業務部門や情報システム部門で、当初想定されていなかった使い方をする事例も増えてきたこともあるだろう。

RubyのパパであるMatzさんや、日本のアジャイル開発の第1人者である平鍋さんの基調講演が聞けるのも楽しみ。
そして、そういう日本のIT業界を代表する人たちと、僕も講演者としてタイムテーブルにプロフィール公開されているのも、ちょっぴり嬉しい。

講演内容は、A会場はPJ管理系・事例系、B会場は技術系・ツール系に分けた2トラックになる。
タイムテーブルを見ての通り、正直どちらの講演も聞きたいぐらいだ。
そんな声も踏まえて、後日、参加者には聞けなかった講演を動画で視聴できるようにしたい準備も進めている。

3つ目は、今後のRedmineの発展に貢献したいこと。
コロナ感染騒動でオフラインの開催自体も怪しくなったが、オンライン開催できる運びとなった。

実は、コロナ感染騒動がなければ、フランスのJPLさんもお呼びする予定だった。
しかし、コロナ感染騒動のため沙汰止みとなった。
周知の通り、Redmine本家の開発体制はJPLさん、@g_maedaさん、@matsuorijpさんの3人だけだ。
競合となるJiraやBacklogに比べれば、非常にリソースが薄い開発体制である弱みはある。
だからこそ、ユーザによるこういうイベントやコミュニティの盛り上がりで、オープンソースであるRedmineが今後も永続的になっていけるように支援できれば、とスタッフの1人として思っている。

まだ、当日まで参加可能なので、是非応募してみてください。

最後に、注意点を1つだけ。
RedmineJapan2020のオンライン配信は、Remoというツールを使う。
ほとんどの人が使ったことがないはずなので、下記のガイドは必ず読み込んでおいて下さい。
RemoはZoomとは全く違って、仮想的なイベント会場を用意している。

日本コミュニティでの活用 - Remo.co Virtual Events and Office space

Remo参加者用ガイド

当日までに、Remoにアカウントを作って事前にログインして動作確認することをお勧めします。
ちなみにRemoの環境は、PCのChrome、Firefoxが推奨です。
iPhoneなどのスマホでは、ブラウザ表示がベータ版になっています。


当日はスタッフは公演準備に忙しいのでフォローできない可能性が高い為です。

では、皆さんのお越しをお待ちしてます。

| | コメント (0)

2020/08/30

Redmine4.2に2要素認証機能が導入された

Redmine4.2に2要素認証機能がコミットされたのでメモ。

【参考】
akipiiさんはTwitterを使っています 「これは重要な意思決定だな。Webシステムのセキュリティ管理では今は当たり前の機能だから。RT @y503Unavailable: 祝! Redmine4.2 二要素認証導入確定 https://t.co/On80J3v8BG」 / Twitter

Feature #1237: Add support for two-factor authentication - Redmine

(引用開始)
I have emailed Jean-Philippe Lang and got his approval to commit this patch for Redmine 4.2.0.
Here are the final patches to be committed. I will commit the patches in a few days to a week.
(引用終了)

Redmineに2要素認証のパッチが提供されている: プログラマの思索

今の時代、よりセキュアなSaaSであれば、2要素認証は一般的なセキュリティ機能だ。
たとえば、ネットバンキングでは2要素認証が普通のセキュリティ機能になってきている。

Redmineを外部公開している場合、2要素認証機能があればよりセキュアな運用も可能になるだろう。
OSSでここまで配慮されているWebアプリはそう多くないのではないだろうか。

過去の開発履歴を見ると、「Redmine Security Advisories」のWikiに全て記載されている。
Web脆弱性が見つかったら、早めに対応されていることが分かる。
OSSのボランティアの開発者がここまで貢献してくれているのはすごいと思う。

Security Advisories - Redmine

今後もRedmineをウォッチしていく。


| | コメント (0)

Redmineの社内教育の記事のリンク

@saitoさんのRedmineの社内教育の記事が参考になったのでメモ。

【参考】
akipiiさんはTwitterを使っています 「後で読む。RT @Redmine_JP: [Headline] Redmineの教育をどのような観点で行うかの考察。 ①PJ 内の情報共有ステーション、②ストック情報とフロー情報、③タスク毎の小さな計画と、予実管理、④変更管理、⑤excel/ファイル共有 との比較 https://t.co/xRbfU61kEm」 / Twitter

Redmine を教えるということ|makoto0119|note

Redmineを社内に普及したい時、@g_maedaさんの資料「はじめる! Redmine (2017)」がお勧め。
図が多く読みやすい。

一方、チケット駆動の考え方ももっと説明したいときもある。
その場合、別途資料を作りたくなる。
@saitoさんの下記の目次も非常に分かりやすい。

1.PJ 内の情報共有ステーション
チケット駆動であれば、No ticket, No workから始めるべきだろう。
チケットが作業の起点になることで、情報共有できるし、進捗報告も不要になる。
何よりも、自分はこのチケットに専念して作業している、と宣言することで、責任を自覚できるし、指示の横槍の防火壁にもなりうる。
チケットは備忘録やToDoリストとも言われる。

2.ストック情報とフロー情報
チケットは、ストックとフローの二重性の性質を持つ。
チケットに記録していながら、ステータスや担当者で、誰がボールを握っているのか、も公開している。
この辺りの運用が馴染むと、チケットのやり合いがオンラインのペア作業みたいな雰囲気になる。

3.タスク毎の小さな計画と、予実管理
チケットの粒度にも関係するだろう。
チケットは1日単位、長くても2~3日単位の方が、メンバーもリーダーも管理しやすい。
Closeされないチケットが長期間残り続けると、何も仕事していないように見えてしまって、お互いにフラストレーションが溜まってしまう。
つまり、チケットの粒度は小さめにし、どんどんCloseしていく運用の方がPJが活発に動いている証拠でもあるし、進捗報告も不要になる。

4.変更管理
Redmineの標準機能では、チケット一覧がWBSになる場合が多い。
仕様変更や、作業の中止などは、チケットを変更するだけでいい。
ガントチャートにはチケットの変更が即座に反映されるので、無駄なガントチャート保守の作業が少なくなるはず。

あえて希望があるならば、Redmineにもプロダクトバックログの機能が欲しい。
おそらくその機能は、Redmineのロードマップ画面で、バージョン単位のチケットの並び順をドラッグ・アンド・ドロップで操作できる機能を追加することになるだろう。
開発者は、チケットの並び順の先頭からチケットを取るだけで、チケットの優先順位が反映されているからだ。

5.excel/ファイル共有 との比較
これは、脱Excelの話。

この資料が公開されるといいなと思う。


| | コメント (0)

2020/07/20

Redmineのチケットパネルプラグインが待ち遠しい

チケットパネルプラグインの記事があったのでラフなメモ。
リリースされたら使ってみたい。

【参考1】
新機能「チケットパネル」 プロジェクトの状況を視覚的に捉え、ドラッグ&ドロップで直感的に操作 | My Redmine

チケットパネル(Issues Panel) | My Redmine

新機能「チケットパネル」 プロジェクトの状況を視覚的に捉え、ドラッグ&ドロップで直感的に操作 | My Redmine

プロジェクト管理クラウド『My Redmine』に新機能「チケットパネル」 プロジェクトの状況を視覚的に捉え、ドラッグ&ドロップで直感的に操作|ファーエンドテクノロジー株式会社のプレスリリース

チケット管理をやるからには、かんばんのような機能は是非とも欲しい。
タスクを一覧表示するよりも、ドラッグ・アンド・ドロップでチケットを操作できる機能が欲しい。
かんばんならば、一目見るだけで、タスク量や作業負荷を直感的にイメージしやすい。

アジャイル開発では、かんばんによるタスク管理の手法は随分前から研究されて、かなりやり尽くした感がある。
「リーン開発の現場 カンバンによる大規模プロジェクトの運営」では、かんばんをソフトウェア開発の工程管理にカスタマイズして運用する事例だった。

Redmineでかんばんプラグインを使うメリットは、その他のチケット集計機能も併用することで、進捗・品質・コストなどの観点で多面的にモニタリングできる点だ。
1日に数枚以上のチケットが作成されて流れていく場合、かんばんビューの方が、リアルタイムな動きが見える化されて、分かりやすい。

一方、ガントチャートのビューでは、イナズマ線を表示すれば、どのタスクが遅れてるのか、一目で分かる。
他方、ロードマップのビューを見れば、マイルストーンでもあるバージョン単位の進捗率が表示されるので、ゴールまで後どれだけ残っているのか分かる。
サマリのビューを使えば、担当者・カテゴリ・トラッカー・バージョン・ステータス単位ごとに、全チケットの枚数が表示されるので、健康診断の血液検査みたいな感じに見える。

かんばんによるタスク管理は、見ていて楽しい。
かんばんはチケット集計機能の一つに過ぎないけれど、Redmine初心者がチケット管理ツールに触る敷居を下げてくれるメリットがあると思う。
こどもRedmineテーマとかんばんを組み合わせたら、小中高生のタスク管理にも使えると思う。

【参考2】
My Redmine インストール済みプラグイン | My Redmine

(引用開始)
My Redmineでは、厳選した以下のRedmineプラグインがご利用になれます。プラグインにより標準のRedmineの機能が拡張され、活用範囲が一層広がります。

Issue Templates - チケット新規作成時のテンプレートを登録
View Customize - CSSとJavaScriptによる画面カスタマイズ
メッセージカスタマイズ - 画面の文言をカスタマイズ
My Page Blocks - マイページを拡張
チケットパネル - チケットをかんばん風に表示
(引用終了)

@g_maedaさんが厳選したプラグインという風に見てしまうので、上記プラグインはRedmine利用者にとって推奨なのかもしれない。

| | コメント (0)

2020/07/13

Redmineのチケット管理はフロー型とストック型で運用方法が異なる

Redmineのチケット管理は、フロー型とストック型で運用方法がどのように違うのか、考えてみた。
ロジカルでない、ラフなメモ書き。

【参考】
Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

【1】フロー型のチケットは、チケット集計機能で見える化したい気持ちがその背景にある。
プロジェクトリーダーの場合、メンバーに個別に進捗状況を問い合わせるのではなく、Redmineを通じてリアルタイムに状況を把握したい。
だから、メンバーが自身の最新状況をチケット入力してくれれば、彼らの作業にプロジェクトリーダーが介入する必要はない。

チケット属性があれば、色んな見せ方がある。
たとえば、ガントチャート、ロードマップ、カレンダー、サマリーなど。
つまり、フロー型のチケットでは、チケット全てを集計して、進捗や品質、コスト状況、障害、課題などの状況をリアルタイムに把握したい。
そうすることで、プロジェクトリーダーは、今どの部分でプロジェクトの進捗が遅滞しているのか、どこにボトルネックがあるのか、をいち早く察知して、対処したいのだ。

つまり、フロー型チケットでは、ステータス、トラッカー、開始日・終了日、予定・実績工数、カテゴリ、バージョンなどの属性項目が重要だ。
それらの属性を用いて、進捗・品質・コストなどの色んな観点で見える化したいから。

最終的には、プロジェクトリーダーは、顧客や上司に対する進捗報告は、Redmineのチケット集計機能で代用したい欲望があるはずだ。

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

【2】一方、ストック型のチケットは、入力のしやすさが大事。
チケットの属性項目よりも、チケットの説明欄が重要だ。
Issueテンプレートプラグインはまさにそう。
チケットの説明欄をテンプレート化することで、たくさんの情報を書き込んでいく。

すると、蓄積したチケットを後から検索して、必要な時に取り出したくなる。
過去の障害や問い合わせはどうだったっけ?
なぜ、こんな複雑なパッチを書いたのか、その意図は何か?

つまり、全文検索機能も大事。
蓄積したデータをいつでも取り出せるようにする。
これは、全文検索プラグインで解決できる。

すなわち、ストック型チケットでは、チケットの説明欄への入力と、その情報を強力に検索できる機能が必須だ。
おそらく、サポートデスクやシステム運用保守チームでは、日々の進捗管理も重要だが、作業記録を残してナレッジを蓄積していくことが大事だろう。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

第17回Redmine大阪の感想 #redmineosaka: プログラマの思索

Redmineの全文検索プラグインでついに類似チケット機能が実装された: プログラマの思索

第19回Redmine大阪の見所 #redmineosaka: プログラマの思索

【3】では、フロー型とストック型の運用スタイルは、Redmineではどの機能に対応付けられて、どのように運用されているのだろうか?

実はRedmine は、ストック型の機能が多い。
チケット以外にも、文書、ファイル、Wiki、フォーラムなど。
しかし、Wiki以外は、これら機能はあまり使われてないように思える。

チケット管理がフロー型の場合、Redmineのストック型の機能を別に使ってる場合が多い。
たとえば、ソース管理、Wikiとか。

たとえば、作業の構成管理はチケット、成果物の構成管理はソース管理で行うとうまくいく。
ISO9001のシステム監査をはたから見ていると、余計にそう感じる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

たとえば、チケットの代わりに、Wikiがストックのイメージ。
Wikiに書かれるものは、たとえば、新規メンバーが加入した時に必要な環境構築、設計情報、技術情報のポータル情報とか、案件で定期的に実施されるふりかえり(KPT)の内容、顧客打合せや内部打合せの議事録、など。

あるいは、過去の障害や課題などのチケットから蒸留した情報をWikiに書く時が多い。
すなわち、システム開発やシステム保守で得られたナレッジをWikiにまとめて、メンバーは誰でも共有できるようにしたい。
そういう運用が自然に回れば、自分たちでシステム開発を改善していく雰囲気が醸し出されるはず。

一方、議事録をチケットにするのはストック型の運用だ。
だから、議事録をWikiにする人は、チケットをフロー型で運用している。

議事録の運用に優劣があるのではなく、チケットをフロー型で意識しているのか、ストック型で意識しているのか、で使う機能が違うだけだ。

【5】まとめると、フロー型はチケット集計機能によるプロジェクトの見える化を重視し、ストック型はチケットの入力や全文検索の機能を重視する。

現状のRedmineの機能を見ると、チケット集計機能は機能改善がすごく多い。
たとえば、ガントチャート、ロードマップ、サマリ、チケット一覧などの画面は、UIや機能も含めて、頻繁にパッチが当てられている。

【5-1】最近のRedmine本家のチケットで気になる機能改善は、カレンダーのUIをHorizontalだけでなく、Vertical list layoutでも表示できるようにしたい、という内容だ。

Feature #33682: Calendar UI proposal (Vertical list layout) - Redmine

#33682の添付画像を表示。

カレンダー画面は正直あまり使われていなくて残念に思っていた。
上記のVertical list layoutが実現できると、縦列は日付、横列はユーザごと・トラッカーごとで表示できる可能性がある。
そうすれば、かんばんに近い感じのUIになって、別の使い道が生まれるだろうと期待している。

あるいは、縦列に日付、横列に時間帯を付ければ、GoogleCalendarの代わりにもなる。
特に、システム保守チームでは、1日でこなすべきチケットを、ガントチャート画面ではなくカレンダー画面で見たいはず。
そういう使い方がしたい要望があれば、カレンダー画面をもっと改善できるはず。

一方、ストック型の機能はあまり機能改善が見られないように思える。
たとえば、Wiki、文書、ファイル、フォーラムなどの機能は、あまり進歩がない。

【5-2】個人的には、RedmineのWikiは仕様書になるように、もっと機能が欲しい。
たとえば、Wiki のサイトマップを自動生成して欲しい。
あるいは、WordなどのOfficeで書くUIの機能をもっとWikiに実装して欲しい。
つまり、WikiはWordやExcelの代わりに書けるもの、という運用を根付かせたい。

以前、Jiraの人に聞いたら、JiraではExcel設計書などの構成管理は考えていない、それら仕様書はConfluenceというWikiで代用できるはずだと考えているから、と聞いたことがあった。
つまり、Jiraでは、設計書はExcelで書いて、Gitで構成管理するのではなく、Wikiに直接書いてしまい、Wikiの履歴管理機能で蓄積できるはず、という設計思想らしい。
同様に、Redmineでもその設計思想は実現できるはずだ。

そうすれば、Redmineをプロジェクト管理ツールとして採用したシステム開発案件では、ExcelやWordなどのOfficeを全て排除できるはず。
ソースコードはGitで管理して、Remdineと構成管理ツール連携をすればいい。
設計書だけでなく、議事録や進捗報告の類も、全てWikiにしてしまうことで、全文検索プラグインでいつでも欲しい情報を取り出せるようになる。
納品物として必要ならば、一括PDFで出力してしまえばいいだけだ。

【5-3】文書機能もまだまだ可能性があるはず。
DMSFプラグインがRedmine本体の文書管理機能を乗っ取ってしまった感じだが、本家の機能ももっと改善したい。

【5-4】そんなことを思うと、Redmineにあるフロー型の機能やストック型の機能はどんなものがあるのか、それら機能に欠点があるならばどんな改善をすればいいのか、を考えたい。
つまり、Redmineの本来のあるべきフロー型やストック型の機能は何なのか、をもっともっと妄想しながら考えてみたい。


| | コメント (0)

2020/07/11

第21回 Redmine大阪の感想 #RedmineOsaka

第21回 Redmine大阪で初めて実施したオンライン勉強会が無事に終了しました。
参加者、講演者、スタッフの皆さん、お疲れ様でした。

【参考】
第21回 Redmine大阪 Online - connpass

Redmine-osaka-021 - Redmine.Osaka

第21回 Redmine大阪 Online(2020/7/11) - Togetter

RedmineOsaka 2020 夏の陣|makoto0119|note

第21回Redmine大阪でみんなの苦労と工夫を知る #redmineosaka | マドびっ! Madosan's View

【1】Redmine大阪は4月から2回延期してようやく実現できたので、スタッフの立場ではとにかくホッとした。
この3ヶ月間、世間では色々あったし、コミュニティは全てオンライン配信に変わってしまった。
そんな中、アジャイルウェアさんがZoomウェビナーを提供してくれて、redmine.tokyoのスタッフ2人が配信を手伝ってくれて、そして、3ヶ月以上も待ち続けてくれた参加者がいて、初めて無事に終わった。
特に今回は、関西在住の人達よりも、東京など遠方の参加者が多かった。

そういうことを思うと、Redmineコミュニティはすごく熱気があっていいなと思う。

勉強会の講演で興味を惹いた点をラフなメモ書き。

【2】前田さんの発表では、RedMicaに3つのプラグインを推奨プラグインとして取り込んで、開発者にフィードバックする発表があった。
それは、Issue template plugin, View Customize plugin, message customize pluginの3つ。
いずれも日本人が開発しているので、プラグイン開発者にとって、RedmineのVerUpに追随する上で品質向上に役立つだろうと思う。

akipiiさんはTwitterを使っています 「まさにそうなんですよね。RT @RyohHAMADA2: オーナー以外唯一のコミッタから推奨されるとか、称号として最強といえよう・・・ > 推奨プラグイン #RedmineOsaka」 / Twitter

また、Redmineコミッタが、優れたプラグイン開発者と連携することで、Redmineの付加価値が上がることも期待できる。
そういう政治的影響として重要と思った。

【3】みうみうさんの発表では、Redmineのアンチパターンの新規概念を提唱しているように思えて参考になった。

akipiiさんはTwitterを使っています 「#RedmineOsaka ロール、権限にやたらヒエラルキーを持ち込むアンチパターン。ネーミングがいいな、使おう」 / Twitter

akipiiさんはTwitterを使っています 「なるほど、ロールや権限の機能がチームを分断するのか。RT @tw_yukia: #RedmineOsaka Redmineって利用者をファーストステップとしてそこから開発者と運用管理者に派生していく気がするんですがはじめのステップは共通なのでSlackのチャットサロンのようなものがあるといいんだろうなとボンヤリ。」 / Twitter

Redmineのロール、権限にやたらヒエラルキーを持ち込むアンチパターンは、まさに組織文化をRedmineに押し付けるイメージ。
現場の業務、標準プロセスにこだわりがあるとはまりやすい。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka 内向きRedmine と外向けエクセルはよく聞くが、Redmine で裏プロジェクトがあるのか!」 / Twitter

Redmineで顧客向けPJと内向けPJを使い分けたくなる、というアンチパターン。
日本人しか分からない、本音と建前みたいな感じ。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka 人力ポーリングのネーミングがいいな」 / Twitter

チケットに書いているんだから、人力で常時見ておけ、というアンチパターン。

いずれも押し付けがましい感じ。

akipiiさんはTwitterを使っています 「#RedmineOsaka Redmine は、ぽーたるなどの静的情報、タイムラインなどの動的情報、ソースコードなどのリソースに3つに分類される、という主張」 / Twitter

Redmineなどのチケット管理ツールでは、情報の蓄積場所はチケットだけではない。
Wikiやフォーラム、構成管理ツール連携など色々ある。
その場合、その情報は3種類に分けられる、という主張は参考になった。

いわゆるチケット集計機能は、動的情報に相当する。
ガントチャート、サマリ、チケット一覧、カレンダーなど。
これらは、チケットの集計結果を表示するタイミングで確定する。

僕は、こういう「データの見える化」がプロジェクト管理で最重要と考えている。
なぜなら、プロジェクトは日々変化しているのに、その最新状況を把握できない、という問題をプロジェクトリーダーはいつも持っているから。
だからこそ、Redmineのようなツールが欲しくなる。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka データは鉱山。見せ方が大事。僕も、見える化が大事と思う一方、蓄積の仕方が大事という門屋さんの意見もある。」 / Twitter

一方、静的情報は、プロジェクト関係者で共有すべき情報を指す。
普通は、運用ルールや技術情報、設計思想などをWikiに書き溜めるだろう。

その場合、複数のチケットに記載された情報から、蒸留した情報をWikiで共有したくなる時がある。
プロジェクト特有、システム特有、チーム特有の情報は、実際に活動したノウハウとしてまとめて、今後に役立てたいから。

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka そう、蓄積した情報を蒸留した情報も欲しいんだよね。自動化できればいいけど」 / Twitter

他方、リソース情報は、ソースコードや設計書など、構成管理で管理すべき成果物。
チケット管理ツールは、チケットとSCMのトレーサビリティの機能によって、その付加価値を高めている。
Excelではできない芸当。
個人的には、このトレーサビリティ機能を何らかのサマリ機能として表現する機能が欲しい、と思っている。

【3】junoさんのLTでは、DockerでRedmineと10個くらいのプラグインを入れた環境を作る話。
講演のストーリーは簡単かもしれないが、個人的にはとても重要と思っている。
理由は、Redmineとプラグインはバージョン依存があって、構築するのにかなり手間がかかるからだ。
本来は、Redmineを使いたいだけなのに、RubyやRailsにハマってしまうのはナンセンスだから。

akipiiさんはTwitterを使っています 「#RedmineOsaka DockerでRedmine+プラグイン込みの環境を作る事例。初心者にとっては、プログラミングしたり、アプリを動かす前に、環境を構築する時に挫折してしまう。やはりRailsの環境は癖があるので、Dockerで環境を丸ごと作ってしまうのが吉と思う。」 / Twitter

(1) akipiiさんはTwitterを使っています 「#RedmineOsaka Redmine のラストワンマイル問題。優れたプラグインがあっても、環境構築が難しい。ホントこれ。」 / Twitter

この話は、Redmine運用に限らず、Railsアプリの開発でも同様の問題はある。
RubyもRailsもバージョンアップが激しい為に、機能は便利なのだが、開発環境やプログラミング環境を構築するのが初心者には難しい。
PythonのAnacondaみたいに、1個のパッケージを入れたら、RailsもRedmineもプラグインも簡単に動く、みたいな環境があればいいなと思う。

【3】パネルディスカッションでは、@ryouma_nagare さん 、@Madowindahead さん, @seizukio さんと「チケット駆動で成長し組織文化を変える」を発表した。
前回の東京で話せなかったネタをもう一度話すことができた。

内容は第21回Redmine大阪でみんなの苦労と工夫を知る #redmineosaka | マドびっ! Madosan's Viewの通り。

【4】懇親会でみうみうさんから、Redmineコミュニティでは管理者の観点の話が多すぎる、利用者の観点の話をもっと入れてみるべきでは、と言われた点が気になった。
この話は、Redmineコミュニティではもっと初心者向けの入門的な話を入れた方がいいのでは、という声が以前からあがっていたのに、なかなか実現していないからだ。

個人的な意見としては、テーマが偏らないレベルであれば、今のままでもいいかな、と思っている。
理由は、現在のRedmineの利用層はプロジェクト管理者や情報システム部門の人達なので、彼らに提供できる価値ある話をコンテンツに集めた方がいいから。
一方、Redmineの利用者の人は、受け身の立場なので、どうしても利用する以上のメリットがあまり感じられないように思えるから。

他に、みうみうさんと話していて気づいた点は、僕の興味は、Redmineの導入の手段ではなくて、Redmineをどんな場面で使うとより効果的なのか、自分がまだ知らない未知の使い方はないのか、Redmineを使ってプロジェクトをスムーズに進行させるだけでなく、チームやメンバーをRedmineでいかに変化させるか、にあることだ。
だから、Redmineの導入でなかなか浸透しない、という問題の解決はたしかに重要だけれど、その話だけにならないようにしたいと思っている。

実は似たような議論が、つい数年前までアジャイル開発の導入に関する話であった。
日本でアジャイル開発を導入・運用する事例やその講演では、いつも、アジャイル開発の導入のために現場の反対をいかに抑えて浸透させるか、という問題ばかりを10年以上もずっと話しているだけ、という指摘があった。

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

つまり、日本のソフトウェア開発のコンテキストでは、いつもアジャイルの導入部分の話ばかりで終わっていて、アジャイル開発を実践した後に、アジャイル開発にどんな可能性があるのか、その先にどんな世界が待っているのか、という議論が日本では欠落している、という指摘だ。

日本のアジャイルは導入部分ばかりで終わっている: プログラマの思索

よって、Redmineの導入に関する話の議論もこの方向の罠にハマってしまいそうで怖いと思っている。
本来は、導入が目的ではなくて、その先のメリットや、一段レベルが上った所での新たな課題解決を目指すべきはず。
たとえば、僕が議論したり考えたりしたいのは、Redmineの背後にあるチケット駆動開発はどんなメリットがあるのか、チケット駆動開発にはこういう可能性があるのにまだ実装できていない機能は何なのか、ということだ。

同様に、Redmineの利用者向けの話も、どうしてもRedmine導入のハードルを下げるための議論だけにハマってしまいそうな気がしている。
この辺りは色々議論してみたい。

| | コメント (0)

2020/06/17

Redmine活動タブの機能改善が提案されている

@g_maedaさんが、Redmine活動タブにTracみたいなポップアップフィルターによる検索機能を提案されていたのでメモ。
門屋さんが一番喜びそうな機能だと思う。

【参考】
Feature #33602: Add an interface to filter activities by user - Redmine

Feature #1422: Date selection for Activity Page - Redmine

#redmine活動家 - Twitter検索 / Twitter

Redmine警察・マイスター・活動家は導入の立役者 | マドびっ! Madosan's View

機能改善の提案は2つ。
一つは、活動タブに「auther」による検索機能を追加して、ユーザ単位の活動ログをフィルタリングすること。
メンバー単位にPJにどれだけ関わって活動したのか、確認する時に役立つ。

もう一つは、活動タブに期間による検索機能を追加して、一定期間の活動ログをフィルタリングすること。
PJの一定期間で、PJがどれだけ活発に動いていたのか、を確認する時に役立つ。

活動ログの更新頻度が多いことは、良い兆候だと考える。
なぜならば、作業の進捗や、作業を妨げる課題や障害をやり取りしている行動が、全て活動ログを経由して探ることができるからだ。
活動ログに表示されない作業は、PJの他メンバーと情報共有しにくいし、誰にも公開されない情報は、結局誰にも役立たない。

どんどんコミットできた、という良いこともあれば、仕様の不備や作業負荷が多すぎる不満もチケットに書かれているだろう。
そういう兆候が活動タブで見える化されなければ、PJにどんより曇った雰囲気が円満し、最後の受入テストで品質悪化や納期遅延が発覚して、炎上案件になってしまう。
PJの喜びも阿鼻叫喚も、Redmine活動ログを見れば、分かるはず。

プロジェクトリーダーであれば、担当PJだけしか見ないけれど、PMOという立場であれば、複数PJを横串で、どんなメンバーがどれだけ活発にチケット更新していたのか、を見たくなる。
活動ログを見れば、上手く進んでいるPJもあれば、火を噴く直前までヒートアップしたPJもあるだろう。

PJ内にある全ての残作業、残課題、障害が見える化されなければ、どんな対処方法が有効なのか、どんな打ち手があるのか、見極めることはできない。
僕もそういう経験は何度もしてきた。

Scrumには、3本柱として、透明性と検査と適応があるが、活動タブはPJの透明性の度合いを評価するのに役立つ。

透明性 - Large Scale Scrum (LeSS)

(引用開始)
スクラムは、チームがプロダクト開発においてどれだけ良い成果を出せているかの鏡として作用し、チームや組織の問題を明らかにします。
この可視性は、 チーム、PO、組織に継続的な改善を促す「検査-適応サイクル」と共に、経験的プロセス管理を支えます。
(引用終了)

メンバー自身の行動がPJにどれだけ貢献できたのか、その貢献度合いは活動タブで表現される。
活動タブを通じて、チケットのログ、Wikiのログ、Gitのログなどへドリルダウンされて、より詳細な活動履歴が分かる。

僕もプロジェクトリーダーとしてRedmineでPJ運営した時、活動タブやロードマップを見るのが好きだった。
面白かったのは、活動タブに活発に表示される若手メンバーは、どんどんモチベーションが上がり、朝会や打合せで堂々と発言する機会が多くなったことだった。
貢献度が見える化されることは、プレッシャーがかかることではなく、メンバーの貢献意欲を高揚させて、より一層成長させるきっかけになりうる。

Redmineのほんのちょっとした機能改善が、プロジェクトメンバーの貢献意欲を引き出し、チームを活性化させる。
そういう機能改善の提案をどんどんしていきたい。

MAEDA GoさんはTwitterを使っています 「@akipii 日付指定のパッチは昼前にコミットしました。Redmine 4.2 / RedMica 1.2 で使えるようになります。 https://t.co/wBWwZ99idl https://t.co/k8FWWOH53v」 / Twitter

門屋浩文@redmineエバンジェリストの会1号さんはTwitterを使っています 「@akipii そういや、活動タブで人の名前でブラウザ機能の検索したりしてましたから、いろいろできると嬉しい」 / Twitter

Redmine.JPさんはTwitterを使っています 「プロジェクトが活発に動いているか役立つRedmineの活動画面。その活動画面に対する機能改善がRedmine公式サイトで2件提案されている。ユーザーを指定しての絞り込みと、表示対象の日付の指定。 https://t.co/1zH7DZM4xM」 / Twitter

| | コメント (0)

2020/06/06

気象庁の事例「GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理」の論文を読み解く

気象庁の事例「GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理」の論文が公開されていたのでメモ。

【参考】
海の研究~GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理

(PDF) GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

第18回Redmine大阪の見所~「チケット管理システムによるソフトウェア開発支援と今後の課題~気象庁のRedmine利用事例報告」: プログラマの思索

第18回Redmine大阪の感想 #RedmineOsaka: プログラマの思索

2017年にRedmineコミュニティで、気象庁の方に利用事例を聞いた時があった。
その後の論文なので、どんな内容が追加されたのか、気になった。

(引用開始)
著者らの海洋大循環モデル「気象研究所共用海洋モデル(MRI.COM)」は,開発が始まってから20 年近くが経過し,気象研究所と気象庁の様々な部門で利用されるようになるとともに,ソースコードの大規模化・複雑化が進んだ。
このような状況の下でも,バグの混入や意図しない影響を抑えながらモデルを効率的に開発するため,現代的なソフトウェア開発で用いられるツールと手法を取り入れ,開発管理体制を一新した。
まず,ソースコードの開発履歴(バージョン)を管理する「Git(ギット)」を導入した。このツールにより,複数の開発者が複数の課題に同時に取り組む並行開発が可能になった。
また,プロジェクト管理システム「Redmine(レッドマイン)」を導入し,開発状況を開発者全員で共有した。このシステムによってデータベースに逐一記録された開発過程が,他の開発者や次世代の開発者にとって財産となることが期待される。
これらのツールを用い,さらに開発手順を明確にすることで,開発チーム内の情報共有と相互チェックを日常的に行う開発体制に移行することが可能となったことは,コード品質の向上に大きく寄与している。
現在,気象庁では,MRI.COMだけでなく,気象研究所と気象庁で開発しているほぼ全てのモデルをGit(またはSVN)とRedmineで一元的に管理するシステムを構築しており,モデルの開発管理及び共有化が大きく前進している。
(引用終了)

論文の中では、Redmineのチケットの画面キャプチャ、GitのコードラインとRedmineのバージョンの関係の図が多数あり、イメージしやすい。
基本的には、開発のタスク管理、ソースコードのレビューにチケットが使われている。
そのワークフローと、チケットの進捗率はP.184で対応付けられている。

(引用開始)
具体的なメリットを以下に挙げる。
1)他人に見られることを前提にしてタスク内容を明文化することで,開発方針が明確になる。
2)担当者や期日が明示されることで,各タスクの優先度の誤認などを防ぐ。
3)実装方針など開発に関する議論が残されることで,他の開発者と将来の開発者はコード変更についての理解が容易になる。開発過程のデータベース化は,次世代の開発者にとって大きな財産となる。
4)開発内容とソースコードが関連付けられ,どのような目的で,どのようにコードが変更されたかを誰もが見えるようになる。これにより,モデル利用者に対して,なぜそのような変更を行ったのかを説明する責任を果たすことになる。これは,現業使用や外部提供もされる MRI.COM にとって重要である。
5)Redmine でチケットを一覧表示させることで,モデル開発の全体の進捗を共有できる
(引用終了)

2014年からRedmine、Git、Subversionが導入されて、数年以上の運用を経ているので、開発プロセスは標準化され、開発者にも浸透しているのだろうと思う。
コードレビューがチケットのやり取りになるので、誰が担当しているのか、説明責任が明確になり、タスクの消化が駆動される。
また、レビューや作業の結果はチケットに全て残るので、保守フェーズでも参考になる。
そういうメリットは感じられているようだ。

(引用開始)
これによるメリットは多々あるが,とりわけ,複数の開発者による並行開発の円滑化,開発過程のデータベース化,ある変更を本体に取り込む前に他の開発者がチェックする「コードレビュー」の必須化,安定版と開発版の 2 系統維持,テスト自動化は,モデル開発において有益である。
また,開発手順の標準化は,他部署や他機関の人が行ったバグ修正や開発も通常の手順で幹のソースコードに取り込む体制が確立されたことを意味する。
(引用終了)

但し、課題も感じられている。
どうやら、RedmineもGitのソースも気象庁内だけに限られているので、外部の人達と情報共有しにくい点があるらしい。
本来は、Githubで公開して、日本や世界中の学者や開発者と連携したり、共同開発できるのが望ましい。
しかし、気象庁内のサーバーで管理されていること、ソースコードの著作権の制約があること、などの理由により、なかなか進んでいないみたい。

こういう話を聞くと、Redmineは社内で閉じた空間では非常に便利なツールではあるが、社外のベンダーや開発者と共同作業する場合、セキュリティ面や著作権などの壁という課題が出てくるのだろう。
今までの日本では、大企業や官公庁は自前のオンプレのサーバーで管理できていたが、今後はクラウド上で外部の関係者と共有できる開発基盤が必要になってくる。
その時に、自前で立てたRedmineサーバーよりも、SaaSのタスク管理ツールやGithubの方が、手間のかかる運用保守から離れられる、というメリットもある。
この辺りは、Redmineの機能が足りない、というのではなく、Redmineのようなチケット管理ツールをSaaSとしてどのように展開すべきか、という問題へ変換できるのだろう。

時代の進化と共に、現場が抱える問題点は日々変化していくものだから。


| | コメント (0)

RedmineでGitHubをらSVNプロトコルで使う

りょうまさんから、RedmineでGitHubをらSVNプロトコルで使えるよ、と聞いたのでメモ。
下記の記事にもあった。

GitHub EnterpriseのリポジトリをSVNプロトコルでRedmineから直に参照....。

(引用開始)
GitHubならSVNプロトコルが使えるよ
(引用終了)

今は時間がないので後で試してみる。
これが可能ならば、GithubリポジトリとRedmineの連携は非常にスムーズになる。
Redmineの最大の弱点はGit連携が不十分という点なので、この方法でどこまで解決できるか試してみる。


| | コメント (0)

より以前の記事一覧