Redmine

2018/09/25

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る

Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。
以下、ラフなメモ書き。

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

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

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

【1】以前、下記のツイートがあった。
最初はRedmineでチケット管理して上手く回っていたのに、ガントチャートで厳しく管理し始めたら、内容が空っぽのチケットが大量発生して、チケット駆動でなくなった、というアンチパターン。

【1-1】
akipiiさんのツイート: "ガントチャートはもう時代遅れなのかな?RT @kabukawa: Redmineはチケットからガントチャートが自動で作られて便利なんだけど、ガントチャートを目的に導入すると、Excelより入力が面倒で使わなくなるか、設計とか実装ってタイトルの中身が空のチケットか沢山できて、時々脱力する。"

門屋浩文@redmineeva☀️さんのツイート: "個人的には品質状態(中身)が見えないガントチャートは時代遅れだと思いますよ ごまかせるもの… "

あさこ@センチちうさんのツイート: "ガントはあくまでも、参照かなー。 誰がなんのために見るか、使うかを区別しないと手段が目的になってしまう。 時代遅れとかではなく、手段の違いだと思います。 ガントで見ることができるものをちゃんと区別していないと、ごまかしとかが生まれてくる。見るべきものを適切なもので。… https://t.co/aw4zR2QAQw"

門屋浩文@redmineeva☀️さんのツイート: "目的を理解して使ってる人 ほとんど見たことないよ(疲れていてネガティブです) うーん、見たことあるかなあ? 俺はWBS辞書 つまりチケット一覧をソートして見る派なので 期間にかかる工数も成果物の精度も見ないで何がわかるのかわからないから パッとみで安心したって意味ないもの… https://t.co/AAWOZvyaXo"

昌。さんのツイート: "まどさんがネガティブ!いかんですな。確かにぱっと見安心する使い方してる人たちいますけども。 私は最アジャイルさんのLycheeのおかげでRedmaineにおけるスケジュール見える化はプロセスわからない派にも使えるかもと思うことができましたさ。… https://t.co/4uE4LNBrDL"

門屋浩文@redmineeva☀️さんのツイート: "ネガティブ続きですが、、、ガントチャートが問題の早期発見や解決につながってないんじゃないかなと感じてるから時代遅れと言った 把握してる人に責任押し付けたって誰も幸せにならんから ガントチャートのみ見て改善につなげられる凄腕なら別だが 時系列で5つ並べてみたら気が付けるかなあ俺… https://t.co/fPxjDRBRLu"

あさこ@センチちうさんのツイート: "ガントだけだと、早期発見なんてほぼできないよね。その目的で使うならば間違いなく、「それじゃないっすよ」と答えるかなー。 ガントの強みってなんだろうねー。 タスク同士の流れとか、いつまでに何が終わるのか、どのくらい終わってるのかを見るだけのツールとして今は使っているかも。… https://t.co/xSecapQWwY"

昌。さんのツイート: "ガントに限ったことではありませんが、ツールに対してこれダメ!ってなる人は弊社の場合は大体が目的見失ってるかツールに夢見てるひとですかね。あなたが使ったようにしか使えませんよー、ってなる。… "

やっさん🍶さんのツイート: "管理者より担当者視点だと (関連あれば)チケットを前後で関連付けちゃうので、前後の関係とか、並列度とかを見るくらいですね。ガントチャートの利用って。… "

akipiiさんのツイート: "ガントチャートはメーカーの製造工程や発注作業の管理に向いていて、ソフトウェア開発のように、作業が不明確で、担当者がコロコロ変わり、管理単位が1日未満で粒度が小さい場合は向いてない。所詮、ガントチャートはマネージャがプロジェクト管理で使うビューの一つに過ぎないと思う。… https://t.co/wc6TLz0MKc"

【1-2】akipiiさんのツイート: "知りたい。RT @g_maeda: Redmineのガントチャート、実は社内では全く使ってない。ガントチャート機能を使ってる組織ってどのくらいの割合なんだろう。"

あさこ@センチちうさんのツイート: "うちは、お偉いさんたちが、プロジェクトのMilestoneとガントチャート、リスク管理表と合わせて見るということをしてくれています。 Milestoneに対してどうか、間に合うか、作業的にリスクがあるかという観点で使ってますね。 ガントチャート一本で何かを見るということは難しい…… https://t.co/uuNqP8gYWb"

あさこ@センチちうさんのツイート: "多分、そのリソースやスケジュール確認するのも、目的が合って、そこにたどり着くまでの一つのプロセスになってますよね、ガントチャート。 なので、みたい観点もある、って感じですかね?… "

昌。さんのツイート: "です。>みたい観点 個人的にしっかりプロセスてか目的に沿ってチケット運用してる限りタブ切り替えるだけで自分やメンバーのタスクが見える化されてるから便利〜なので、とりあえず朝イチとか進捗確認時に眺めたり確認したりな感じです。… https://t.co/pcMefEEx29"

【1-3】akipiiさんのツイート: "第3回 Lychee Redmineユーザ会 - connpass https://t.co/5O2rOzCMxx 「Redmine + Lychee導入のアンチパターン」の講演は、チケット管理が回っていたのに、Lycheeガントチャートを使いだしたら、空っぽのチケットが増えてチケット駆動でなくなった、というアンチパターンだろうか?笑"

【1-4】akipiiさんのツイート: "読み返したら、当初の目的が忘れられて、手段が目的化してしまった、という症状に思えてきました。チケット管理がうまく回っていたのに、ガントチャートの監視を厳しくしたら、チケットの中身よりチケットの進捗率が重要になって、チケットが忘れ去られた、みたいなイメージ。… https://t.co/u1P1tcsDZB"

りょうまさんのツイート: "そうですね。私はガントチャートは進捗の俯瞰とインデックスだと捉えてるので、その奥に詳細があるのが当たり前だと思い込んでいました。… "

昌。さんのツイート: "ひとは簡単に目的と手段が逆転しがちなので気をつけねばいけませんね。いつも、目的はなんだ?と自分にも問いかけるようにしてます。… "

【1-5】その真因は、本来のチケットは、プロジェクトで発生する変更要求、課題、作業、障害など、プロジェクトで管理すべき対象全てが起票されるはずなのに、進捗管理だけの側面だけ重視されてしまい、チケットの2重性がなくなって、スカスカの空っぽのチケットになってしまった、ということだと思う。

つまり、本来のチケットは、課題の検討履歴、変更要求の作業履歴というストックの側面を持ち、かつ、チケットの納期や作業進捗も合わせて管理できると言うフローの側面も持ち、2重性があったのに、担当者の作業進捗だけ気にするようになってしまい、フローの側面だけ残り、ストックの側面がなくなってしまった、というアンチパターンが発生したわけだ。

【2】以前、ISO9001のQMSの運用の現場を見た時、変更要求や変更管理に関するExcelの作業依頼書と、設計書やリリース手順書などのExcelドキュメントの2種類のExcel帳票が管理されていた。
その運用は非常に煩雑で、最新版のドキュメントが連携されなかったり、リリース漏れが発生したり、非常に手間がかかっていた。
今どき、Excel帳票で管理する現場はありえないと思うが、古い製造業ほど、Excel帳票がはびこっている。

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

その原因も上記と同じ。
つまり、ISO9001で実現する時、Redmineでチケット管理せず、Excel帳票で管理する場合、作業依頼書という変更管理に関するフローの側面と、設計書やリリース手順書などの構成管理対象になるストックの側面は、2つのExcel帳票に必ず分かれる。
そして、その2種類のExcel帳票を常に最新化しながら、申請承認フローに沿って厳密に管理せねばならない。

【3】では、なぜ、Excel帳票の運用は必ず失敗するのか?

【3-1】なぜなら、昨今のように経営環境がすぐに大きく変化する場合、Excel帳票で逐一管理する運用は、その変化についていけないからだ。
変更管理の運用と構成管理の運用はシステム開発ではとても重要だが、2種類のExcel帳票で管理するのは煩雑すぎて、現実として運用できないだろう。

結局、Redmineのようなチケット管理ツールで、フローの側面であるワークフロー管理と、構成管理の側面であるソース管理連携機能の双方を実現しなければ、経営環境の変化のスピードにシステム開発そのものが付いていけいないだろう。

例えば、最初は課題チケットで起票したが、課題に対して複数の代替案を出して検討し、一つの解決案を決定した履歴を残す。
さらに、その対策の作業状況も履歴として残し、課題が解決されるまで、チケットに全ての情報が残す。
すると、そのチケットのステータスが変わるたびに、裏では、その時々の意思決定の状況が管理され、マネージャによる承認プロセスを経て、システムに反映されてリリースされていく。

例えば、最初は顧客からの変更要求の仕様変更チケットで起票したが、その変更要求の発端を記録しておく。
また、チームでそのアーキテクチャや実現方法を検討した経緯を記録しておく。
すると、そのチケットのステータスが変わるたびに、裏では、担当者の作業状態が管理され、マネージャや利害関係者の承認プロセスを経て、システムに反映されてリリースされていく。

つまり、当初は課題チケットや変更要求チケットだったのに、チケットが更新されるたびに、作業チケットの意味合いに変わり、チケットが進捗管理対象になる。
さらに、チケットが更新されるたびに、変更管理の承認プロセスの意味も込められて、チケットが変更管理対象にもなる。

すなわち、チケットはストックとフローという2重性の性質が一つの実体として実現されている。
チケット管理では、ストックとフローという2重性の性質を、マネージャやメンバーが深く意識しなくても運用できるような仕組みを提供しているわけだ。

【3-2】本来あるべき姿のチケット管理では、チケットに変更管理や進捗管理というフローの側面と、成果物の構成管理や課題や作業の履歴管理というストックの側面を故意に持たせることで、スムーズに運用させる。

一方、Excel帳票でそれらを管理しようとすると、フローの側面のExcel帳票と、ストックの側面のExcel帳票の2種類に必ず分かれてしまう。
なぜなら、ステータスだけ管理したいExcel帳票と、リリース対象の成果物として厳格に構成管理したいExcel帳票は、管理方法が大きく異なるので、具体的な実体として分けざるを得ないからだ。

すなわち、Redmineのチケット駆動開発は、2種類のExcel帳票の具体的な実体が1つのチケットに合体されている。
そういう背景を、チケット駆動で運用している人は、意識しているだろうか?

【3-3】Redmineでのチケット駆動開発では、メンバーはストックの側面のチケット管理を意識しているが、その背後では、変更に関する申請承認という変更管理、そして、進捗の作業状況の把握という進捗管理、というフローの側面も裏で持たせている。

2種類のExcel帳票で分けて二重管理している運用が、チケット管理では、チケットという1つの実体で管理できるので、非常に運用しやすくなる。

よって、Redmineのチケット駆動開発ではチケットに複数の意味を持たせて運用した方が上手く回る、と僕は思う。

【4】僕の経験上、メンバーはストックの面だけ意識してもらえばよく、フローの側面はそんなに気にしない方が、チケット管理は上手く回ると思う。
もちろん、変更管理や進捗管理は重要だが、その意識が強すぎると、チケットのライフサイクルが長くなり、チケット駆動のメリットが薄れるから。

チケットに対するフローの側面を意識し始めると、ストックの側面を忘れてしまう。
チケットのストックの側面こそが重要なのに、その部分が軽視された運用になってしまうのだ。
ガントチャート重視のチケット駆動開発が、空っぽのチケットを大量発生させるアンチパターンはまさにそれだ。

一方、ストックの側面ばかり強調すると、チケット入力の運用のコストが上がってしまう。
チケットは手軽に起票して、記録して欲しいのに。
誰も更新しなくなるRedmineは、ゴミ箱と同じ。

だから、チケット管理の運用では、フローの側面を強調しすぎると空っぽのチケットが増えて破綻するし、ストックの側面を強調しすぎると、誰もチケットに起票しなくなって破綻する。

チケットの2重性という奇妙な性質を活かすには、そのバランスが重要だ。
フローの側面だけ、ストックの側面だけ、という運用では、チケット駆動のあるべき姿を実現できないし、チケット駆動の効果が得られない。

そのバランスを維持するための運用ノウハウは、実は数多くの現場で暗黙知となっていると思うので、収集してみたいと思っている。

| | コメント (0)

2018/08/28

Redmineにタグ機能を追加するパッチが投稿された

昨日、Marius BALTEANUさんがRedmine本家にタグ機能のパッチを投稿された。
次期Ver4.0で実現できたら、Redmineをより使いやすくしてくれるだろう、と期待している。
ラフなメモ書き。

【参考】
Feature #1448: Add tags to issues - Redmine

【1】なぜ、タグ機能が重要なのか?
それは、GitHub、Gitlab、Jiraなどの他のツールを見ればよく分かる。
Twitterのハッシュタグのように、「#○○○」を書けば、勝手にリンクできて、カテゴライズ化できる。
しかも、情報を探したい時に、タグで探しやすくなる。

(自動翻訳の引用開始)
私たちの問題の多くは複数のカテゴリにまたがっています。具体的には、単にカテゴリ以外のものよりも柔軟性のあるものを検索して管理したいと考えています。

問題にタグを追加する方法があれば素晴らしいだろう。
(自動翻訳の引用終了)

Redmineにタグ機能が欲しい、という要望は10年以上前からずっと言われていた。
そのため、熱心なユーザがタグ機能を実現するプラグインを開発してくれていた。
しかし、RedmineやRailsの度重なるバージョンアップに追随できなかった経緯もあった。

【2】ついに、Marius BALTEANUさんがパッチを投稿された。
そのコメントを読むと、Redmineユーザのニーズをすごく考えていることがよく分かる。

(自動翻訳の引用開始)
私は、プラグインhttps://github.com/ixti/redmine_tagsに基づいてRedmineにタグ機能を追加する作業を始めました(これまでの2年間で寄稿しました)。
私の計画は、第1段階で問題に簡単なタグ付け機能を追加し、機能がコアに承認/追加された後、他のエンティティ(ウィキ、プロジェクトなど)に拡張し、他のすべての機能を提案することです(バルク編集タグ、着色されたタグ)などがあります。

1.第1フェーズは、以下の2つのパッチで構成されています。

タグの追加/削除
タグの追加/削除タグの表示
タグの後にチケットをフィルター
チケット一覧の項目としてのタグ
タグ書き出し(pdf、csv)

添付されたパッチを使用してテストすることができます。
私はタグを管理する権限を持っているべきかどうか(私の見地からは、編集の権限は十分です)、何か他のものがなくなっていて、それがこの第1段階にあるはずなのかどうか疑問に思っています。

2. JSライブラリを追加してUIのタグを処理する(オートコンプリートを含む)添付のパッチでは、Jean-Philippe LangがSelect2をコアに追加したくないことを知っているのでSelectize.jsを提案します。
プラグインによって使用されることはもはや維持されません。
パッチは準備ができていませんが、私はこのライブラリを使用できることを最初に確認したいと思います(他の提案は歓迎です)。
また、プロジェクトからオートコンプリートでタグを提案する必要があるかどうか確認する必要があります。
プロジェクト階層、サブプロジェクトから)。

この機能は、Redmine.orgのチケット投票数のリストで1位にランクされ、120人以上のウォッチャー(この問題で80件、#2897で45件)、複数のコメントと関連する問題があります。
また、プラグインは、タグ付け機能がコアの一部である場合に役立ちます。
Redmine 4.0.0の後の次のバージョン(これはほとんど準備が整っています)でこれを行い、それを提供したいと思います。
(自動翻訳の引用終了)

【3】要約すれば、タグ機能が重要な理由は、2つある。
一つは、Redmine.orgのチケット投票数のリストで1位にランクされ、10年以上前からユーザの要望がチケットに記録され続けてきたこと。
もう一つは、タグ機能がRedmineチケットのカテゴリの代わりの機能になり、検索する時にも役立つこと。

Twitterのハッシュタグに慣れている人は多いだろうから、この機能が追加されることで、より多くのユーザがRedmineにチケットやWikiに情報を書き込むメリットを感じやすくなるだろう。
それら情報は、タグでカテゴライズでき、検索しやすくなるからだ。

このタグ機能も、Ver4.0またはVer4.1で取り込まれるといいなと思う。

また、Redmineの添付ファイルを全文検索できるパッチもVer4.1にセットされており、trunkにマージされることをユーザは待ち望んでいる。

Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?: プログラマの思索

タグ機能と合わせてリリースされたら、Redmineユーザにとっても待ち遠しいと思う。
今後も、Redmine本家の動向はチェックしておく。

| | コメント (0)

2018/07/04

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグイン

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグインを見つけたのでメモ。

【参考】
【担当者さん必見】メンバーみんなで日程調整ができる「Scheduling Poll」プラグイン登場!

cat-in-136/redmine_scheduling_poll: a plugin to provide the simple way to schedule appointments on Redmine

QA #824: チケットやニュース、フォーラム、Wikiなどで選択式のアンケートを実施したい - Unofficial Redmine Cooking - redmine.tokyo

画面を見てみると、調整さんのように複数のチェックリストに○△Xを記入した後、入力結果を自動集計してくれるみたい。

選択できるチェックリストには、日付以外にテキストが入力できるので、他のアンケート項目にも流用できるだろう。

時々、アンケート機能がRedmineにも欲しい、という声があがる時があるので、このプラグインを使えばいいかもしれない。

下記のLineの機能にインスパイアされて、Redmineプラグインを作成された、とのこと。

【幹事さん必見】友だちみんなで日程調整ができる「LINE スケジュール」機能登場! : LINE公式ブログ

こういう投票機能は、Redmineを単なるタスク管理、課題管理、障害管理だけでなく、チーム内のコミュニケーションを活性化させるためのツールへ進化させる為の機能と言い換えられる。

Rails開発の技術力があれば、自分のアイデアやプロジェクトリーダーの提案を元に、Redmineをカスタマイズすることにより、チームの一体感を生み出す機能をいくらでも作り出せる。

そういうアイデアを実現する機能とチーム内のコミュニケーションとの相関関係や影響度合いを実際に分析してみたいものだ。

| | コメント (0)

2018/06/27

Redmineにも「いいね」機能が欲しい

先日の東京Redmine勉強会のLTで「気遣いが大事」という内容に関する記事があったのでメモ。

【参考】
はじめてのredmine.tokyo勉強会参加と『エモい』Redmine - ファーエンドテクノロジー株式会社

(引用開始)
『エモい』Redmine #とは
後日、マーケティンググループのメンバーと会って話した際に、私がライトニングトークのスライドで記載していた「気遣いが大事」という点が話題になりました。

遠藤「事前にライトニングトークのスライドを見て、気遣いが足りなかったと反省したんです」

財部「逆ですよ!遠藤さんの気遣いがあるコメントを頂いて、私のほうが学んだんです」

石原「前はチケットのコメントに『ありがとうございます』とか書かなかったけど遠藤さんが書くようになって書かなきゃ!と思うようになりました」

財部「これだけでも勉強会のネタになりそうですよ、『エモい』Redmine」

例えばチケットのコメントに「◯◯してくれてありがとうございます。」と書くか否か。メールじゃないんだから、と簡潔に済ませるのか。
(引用終了)

チケットに作業ログを残すだけでなく、対応してくれた人に感謝の気持ちを伝えたくなる時もある。

Facebookなら「いいね」ボタンでその機能を実現している。
Twitterならリツイートボタンでその機能を実現している。
この機能は、マズローの欲求5段解説の承認欲求、ハーズバーグの動機づけ・衛生理論を連想させる。

すると、Redmineにも同様に、「いいね」機能が欲しくなる。
コメントに「ありがとうございます」と文字で書くのが面倒でも、ワンクリックで、感謝の気持ちを表現できるなら、そちらの機能を使いたい。

Redmineにもそういうプラグインはあるみたい。
以前、GoodJobプラグインもあったな。

Redmineに「応援する」リンクをつける: プログラマの思索

Redmineに入れたプラグイン一覧part3: プログラマの思索

akipiiさんのツイート: いいねボタンが欲しい時がある RT @hito_asa: 社内Redmine、Backlogと違って味気ないというか、スターつける仕組みもないしなんだかコミットしてて寂しくなってくるのです。スター重要。

システム構築の立場から見れば、たかが「いいね」ボタンという一つの機能に過ぎないのに、たった一つの機能「いいね」ボタンが感謝の気持ちを気軽に表現してくれることで、メンバーの貢献意欲を引き出し、チーム内のコミュニケーションを促進し、チームの一体感や使命感を醸し出す。

これまた人間の心理の不思議の一つかな。

| | コメント (1)

2018/06/21

Redmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されている

@g_maedaさんが、Redmineの「トラッカー」を「チケット種別」へ変更するチケットを提案されている。
些細な内容だが、Redmineの初心者向けユーザにさらに使いやすくする重要な提案と思うので、メモしておく。

【参考】
Patch #29045: Change Japanese translation for Tracker - Redmine

【1】Redmineのチケットで最も重要な概念は「トラッカー」だ。
なぜなら、トラッカーはワークフローと表裏一体であるので、業務フローと対応付けられるからだ。
よって、トラッカーによってRedmineチケットの状態遷移が制御される。

また、トラッカーはカスタムフィールドなど、チケットのテンプレートそのものでもあるからだ。
よって、トラッカーごとに、チケットのテンプレートを設定する思想にもなる。

たとえば、トラッカーは、ソフトウェア開発のプロセス、申請承認ワークフローの業務などに対応付けられる。
それらは、特有のワークフローがあり、特有のデータ項目(カスタムフィールド)が保持されている。

【2】しかし、従来から、「Redmineのトラッカーとは何ですか?」という問合せが非常に多い問題があった。
日本人には「トラッカー」を和訳せずにそのままの名前にしたので、イメージしにくいのが根本原因にあるのだろう。

よって、「チケット種別」にする提案が@g_maedaさんから起票された。
おそらくRedmineを知らない日本人にとって、「チケット種別」という概念の方が理解しやすいだろう、と個人的に思う。
このパッチが反映されれば、日本におけるRedmineの普及促進に重要な良い影響を及ぼすだろう。
よって、パッチは些細なものだが、非常に重要な内容だ。

【3】なお、コメントでは、「ワークフロー種別」の方が良いのでは、等の意見もある。

@g_maedaさんの言う通り、トラッカーはワークフローかつチケットテンプレートの2種類の設計思想を持つので、「チケット種別」の方がその2つの概念を包含しやすいだろう、と思う。

Patch #29045: Change Japanese translation for Tracker - Redmine

(Google翻訳にて引用開始)
松本Gohさんはこう書いた:

私の意見では、トラッカーはワークフローの名前またはタイプを表しています。
だから、私は "ワークフロー"または "ワークフロータイプ別"を提案します。

ご意見ありがとうございます。でも、私はまだ「ワークフロー種別」よりも「チケット種別」が好きです。その理由は次のとおりです。

トラッカーは、ワークフローだけでなく一連のフィールドも定義します。「ワークフロー種別」(ワークフロータイプ)という言葉は、そのうちの一つしか表現しておらず、ワークフローを強調しすぎています。私は "チケット種別"(問題の種類)は両方の意味を含んでいると思います。
「ワークフロー種別」(ワークフロータイプ)はかなり長いです。問題リストを表示すると、トラッカーフィールドが広くなります。
しかし、ユーザーのために「チケット種別」(問題の種類)と「カテゴリ」(カテゴリ)を区別するのは少し難しいとのご意見に同意できます。
(引用終了)

【4】また、 Masakazu IZUIさんのメモの絵が素晴らしい。
メモでは、チケット種別(トラッカー)のチケット群を「カテゴリ」に仕分けするイメージが描かれている。

Patch #29045: Change Japanese translation for Tracker - Redmine 「「仕分け」はどう?」

このメモが素晴らしいと思う理由は、トラッカーとカテゴリの設計思想が明確に区別されているからだ。
トラッカーは全てのPJで使われる汎用テンプレートかつワークフロー設定なので、各トラッカーの各種チケットは、各PJで、PJ特有のカテゴリで「仕分け」される。

RedmineのカテゴリはPJで自由に設定できる点がミソだ。
つまり、汎用設定であるトラッカーによる分類だけでなく、PJ特有の分類方法はカテゴリを使って分類すればいい。
そうすれば、チケット集計時に、色んな観点で集計しやすくなる。

つまり、「チケット群を仕分ける」作業は、プロジェクトマネージャが従来行っていた進捗報告作りの作業である。
その手作業は、Redmineのチケット集計機能で全てシステム化、自動化できることを示唆しているのだ。

【5】なお、カテゴリ機能については、親子PJでカテゴリを継承して使えるような機能改善が下記チケットで提案されている。
最近、Yuuki NARAさんがGitHubで試されている。

Patch #11898: Inheritable issue categories - Redmine

Feature #5358: Share Issues Categories for sub-projects - Redmine

実は、Redmineのカテゴリは重要な機能でありながら、その使い道の有用性を説明することが難しかった。
カテゴリを親子PJで継承できるようになれば、親PJのカテゴリを流用できるので使いやすくなる。

個人的には、カテゴリ機能はもっと改善して欲しい、と思っている。
そうすれば、チケット種別(トラッカー)でチケットを分類する方法ではなく、カテゴリで固有のPJで分類する運用がもっと馴染むようになるだろう、と思っている。

僕はRedmineをもう10年以上使っているけれど、まだまだ機能改善したい気持ちがあるし、色んな可能性を考えるのがすごく楽しい、と感じてる。

【追記】
Toru Takahashiさんから、「トラッカー」を「チケット種別」に変更する提案に反対意見が表明されている。
その反対意見の理由を読むと、確かにもっともだ。
なぜなら、「トラッカー」には「問題や課題、障害等を追跡する」意味が含まれているので、その意味が失われるリスクもあるからだ。

Patch #29045: Change Japanese translation for Tracker - Redmine

(Google翻訳による引用開始)
私はこの翻訳提案に同意しません。

「トラッカー」には、問題のステータス変更を追跡する意味が含まれます。
「種別」には含まれていません。
さらに、「タイプ」という単語は「カテゴリ」という単語に非常によく似ています。

「トラッカー」に適した日本語を見つけるのは難しいかもしれません。
翻訳に適した単語が見つかるまで、
現在の翻訳された単語「トラッカー」は、トラッカーの代名詞を表しています。
(引用終了)

高橋 徹さんのツイート: "Redmineトラッカーをチケット種別と表記する変更案がありますが、trackerの語に含まれる追跡管理の意味が失われるのはどうかなぁ?トラッカーが解りにくいのは同意、しかし元の意味が失われる訳語には賛同しかねるなぁと。 https://t.co/bsa9AJVobj"

Kuniharu AKAHANEさんのツイート: "同じ思いです。Issue Tracking Systemの根幹要素を欠くと思っています。その一方で、Redmineの利用領域は本当に幅広いのでOSSを使う皆さんがわかりやすいというならそのまま受け入れて、自分の環境では ja.ymlの15ヵ所をを書き換えようと思っています。… https://t.co/8qxMMCao8a"

やっさん🍶さんのツイート: "#redmine 私も同様に慎重派です。 そもそもなぜTrackerとしたのか?に関してJPLには考えがあるはずなので、そこを確認してからじゃないと「トラッカー」→「チケット種別」とするのはどうかなぁと考えています。 私は@akabekobekoさんの案が良いかなぁと(話大きくなるけど)。 https://t.co/oQpoUxpCji… https://t.co/s1XppYjKZr"

| | コメント (0)

2018/05/27

第14回東京Redmine勉強会の感想 #redmineT

第14回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
感想をラフなメモ書き。

【参考】
2018/5/26 第14回勉強会 - redmine.tokyo #redmineT - Togetter

第14回勉強会 - redmine.tokyo

redmine.tokyo 14 で登壇してみた – アカベコマイリ

【1】グループディスカッションで話を聞くと、最近Redmineを運用し始めた、という人から、10年近く触っている人まで幅広いユーザ層でした。

また、1年前から参加者の女子率が上がっているように感じてます。
女性陣もデザイナー、品質保証部、PMO、インフラ管理者など幅広い分野で活躍しており、Redmineに関する問題意識も当然高い。
以前は、40代のおっさんばかりがRedmineコミュニティにたむろしていたのを振り返れば、感慨深い。

ゆえに、参加者層が幅広くなったおかげで、ユーザコミュニティの雰囲気は、毎回開催するにつれて良くなっていると思う。

【2】個人的には、Twitterでやり取りしている人と対面できたのも嬉しい。
講演してくれた@akabekobeko さん、@nekosanz1 さん、グループディスカッションでお話できた@endo_5501 さん、@kabukawaさんを認識することができた。
もちろん、@kaorabeさん、@MadoWindaheadさん、@acha_821さん、@aj15_aj15さん達ともお話できたのも楽しかった。
また、Redmineコミュニティが縁で結婚されたカップルも居る。

コミュニティを通じて、輪が広がるのも楽しい。

【3】山崎さんの講演では、Redmineとツール連携する例として、MSProjectからRedmineへインポートするプラグイン、RedmineとSlackを同期するプラグインが紹介されていた。
(たぶん、山崎さんの会社でプラグインを作成されているだろう)

プロジェクトマネージャの要望としては、立上げ時にMSProjectで作ったプロジェクト計画をRedmineへインポートしたい要望が多い。
ざっくりしたスケジュールを引いてクリティカルパスを表示させるのは、やはりMSProjectの方が楽だから。

しかし、予定はMSProjectで作ったとしても、その後の実績管理はRedmineの方がはるかに運用しやすい。
日々の進捗はどんどん変わるし、複数人が編集して最新化する手間を考えると、MSProjectに拘る必要はないと思う。

このプラグインで面白いのは、親子チケットの構造をRedmineでも再現できる点。
現状のRedmineのREST APIでは、ツリー上のWBSを作る時、どうしても2回発行しなければならない。
なぜなら、親チケットが決まった後で、子チケットをぶら下げる更新処理が必要だから。
ゆえに、1回の更新で、しかもチケット番号を昇順に採番して更新するような仕組みがあると便利だろう。

【3-1】また、Slack連携では、Redmineの活動ログをSlackに流すだけでなく、SlackからRedmineへチケット登録する運用が紹介されていた。
仕組みとしては、Slack上で、「タイトル:~、内容:~」のようにコメントすれば、RedmineのREST API経由で登録される仕掛け。

Slackからチケット登録できるメリットは、Slack上で障害を見つけたやり取りをしている時に、Slackから即座にチケット登録したい時もあるだろう。
すなわち、Slackの運用が既に定着していて、Redmineに情報を集約して記録して残したい場合に、有効に使えるだろう。

【3-2】似たような例として、@netazoneさんがGoogle Homeで、ボイス入力した内容をRedmineにチケット登録する利用事例のLTがあった。
仕組みとしては、Google HomeからIFTTT(IF This Then That)・GMail経由で、Redmineへチケット登録メールを送って、メールによるチケット登録機能を使っていた。
Google HomeからRedmineのチケット登録ができるメリットは、PC操作無しで会話するだけでチケット登録できること。
たとえば、カスタマーサポートや事務担当者などの非エンジニアが使う利用シーンが考えられる。

このように、Redmineの優れた外部I/Fを上手く使えば、チケット管理のコストを下げることが出来るだろう。
また、現場の利用シーンを考えながら、Redmineと連携する設計を考えるのも楽しい。

【4】@akabekobekoさんの「なじむ Redmine」も面白かった。

個人的には「Redmineを浸透させるために、故意に「活況を演出する」」という考え方が面白かった。
つまり、流行っているレストランは、流行っているから更に新規顧客も増える、という現象と同じ。
特に日本人は、皆がやっている雰囲気に弱いので、故意にRedmineの活況を演出し、Redmineに触らざるをえない雰囲気に持っていく。

事例としては、Wikiで議事録や設計メモをまとめることから入り、その後チケットの運用に入っていく。
どうやら、初心者にとって、チケットを登録するのはハードルが高いらしい。
チケットのUIはボタンが多いし、ちょっとの更新でも履歴が残ってしまうので、変な更新ができない、完璧に書かないといけない、という心理が働くらしい。
几帳面で完璧主義の古き良き日本人にありがちな行動だろう。
だから、そんな時は、周囲がサポートする。
たぶん、Redmine警察とか、Redmine職人、とか、Redmineエバンジェリストの出番なのだろう。

【5】実は、今回の勉強会では、RedmineのGit連携が最大のテーマだったと思う。
パネルディスカッションで取り上げられた。
@akabekobekoさんの講演でも、最後の課題にあげられていた。

(引用開始)
最近、日本のRedmine 界隈で話題?になった記事
Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索
↑で挙げられている内容はRedmine 運用していて強く 実感させられる課題です。
私的には環境面の運用が厳しい。インストール、更新、プラグインやテーマの配布と互換性など。
(引用終了)

【5-1】パネルディスカッションで、パネラーや参加者の声を聞く限り、RedmineユーザはSVNとRedmineの連携はよく使っているが、Git連携を使っている人は少ない印象を持った。
つまり、SVNの知見は皆良く知っているが、Gitの知見を持つ人は少ない。

話を聞いた印象としては、プロジェクトマネージャやPMOとしてRedmineでチケット管理している人たちは、そもそもGitを運用する利用シーンがそもそも無い。
彼らのモチベーションはチケット管理による作業の進捗管理やリソース管理がメインだから。

【5-2】一方、RedmineとGitを連携して運用する場合、2つのパターンの事例があった。

1つ目は、RedmineとGitlab、Gitoliteと連携して、Redmineではチケット管理、Gitlab側ではブランチ管理で分けている。

Redmineサーバー側にGitのBareリポジトリをクローンし、Redmineのリポジトリ画面と連動させる運用をしている。
もちろん、Redmineのチケット番号をGitのコミットログに埋め込むので、トレーサビリティは維持できている。

しかし、Gitlabのプルリクは使えていない。
あくまでも、Gitのブランチ管理とマージ作業だけに限定されている。
よって、昨今のGitHubで最も優れている運用方法「プルリク時点のコードレビュー」が仕組みとして提供されていないデメリットがある。

2つ目は、Redmineのチケット管理とGitHubのソース管理は明示的に連携せず、Redmineではプロダクトバックログや障害チケットの管理を行い、GitHubではマージやプルリクを使う、と運用を分けている。

すると、GitHubでは活発なプルリクが行われるので、プルリクのタイミングで必ずコードレビューが行われて、masterの品質は維持される仕組みになる。
このプルリクとコードレビューが密接に関係することで、エンジニア同士のコミュニケーションが促進され、お互いの理解も進み、ソースの品質も維持される仕組みが作られた点にあると思う。

しかし、Redmineのチケット管理と連動していないので、チケット管理ツールの最大のメリットの一つであるトレーサビリティ機能が使えていない。
結局、Redmineのチケット単位にトピックブランチを手動で作り、トピックブランチをプルリクする時点で、Redmineチケットを更新するという手動の運用ルールでカバーしている。

すなわち、現状のRedmineのGit連携には、昨今のGitHubのプルリクという優れた機能を埋込できていない。
よって、Gitの恩恵を最大限活用できているとは言えない。

MAEDA Goさんのツイート: "https://t.co/9GswyYgo4P にコミットするときいつもすごく緊張する。コミットログをスペルチェッカーにかけ直したり、diff見直したり。 #redmineT"

【5-3】RedmineのGit連携の機能が不十分である、という課題は、おそらく有識者は皆知っていて、何とか解決を図ろうと色々試されている、と思う。

@agilekawabataさんは、RedmineのBareリポジトリを作成するプラグインを作ったら欲しい人はいるか、という質問を投げかけていた。
初心者にとって、GitのBareリポジトリを作成する作業はハードルが高いので、プラグインがあれば、その部分のハードルは下がるだろう。

onozatyさんのツイート: "Bareリポジトリを画面側からクローンできると確かに楽だなぁ。 (回数がそこまで多くないので耐えられているけど、、)… "

onozatyさんのツイート: "そですね、きつすぎますね。 GitLab+Redmineで使っているのですが、新規プロジェクト立ち上げる時の手間がそれなりにかかるので、そのあたりもう少し便利になるといいですね。 画面からBareリポジトリ作れるようになると、画面操作だけで完結するので敷居も下がるかなと。… https://t.co/tJVZYxcff5"

また、maeda-m さんのredmine_git_work_in_progress プラグインでは、作業ブランチとマージ先のブランチのDiffやブランチの状況を可視化する機能を紹介されていた。

matsukei/redmine_git_work_in_progress: This is a plugin that provides Reduine's Issue like "Work In Progress Pull Request" and makes it easy to share knowledge.

あるいは、RedmineとGitlabを連携したり、RedmineとGitHubを連携する方法で運用をカバーするやり方もある。

akipiiさんのツイート: "#redmineT Gitlab からベアリポジトリを作ってRedmineと連携してるのね。では同期はどうしてる?"

taikiixさんのツイート: "(会場で結論が出ているかもしれませんが)私はこのプラグイン使っています。 https://t.co/C0DQ7APwxL… "

koppen/redmine_github_hook: Allow your Redmine installation to be notified when changes have been pushed to a Github repository.

たむさんのツイート: "うちは、gitlabとredmineは独立したインスタンスなので、nfsマウントしていますよ… "

MAEDA Goさんのツイート: "mod_perlがRHEL 7から標準ではなくなったので、https://t.co/YqxU0tFwwx のインストールめんどくさそう。 #redmineT"

【5-4】RedmineとGitlabの連携で最大の問題となるのは、GitのプルリクとRedmineチケットが密接に連携できない点がある、と思う。

例えば、プルリクを作る前に、その作業のチケットがない場合、Redmineにチケットを書いて、Gitにチケット番号を書いてコミットしてプルリクを送る、という面倒な作業が発生しないか。

あるいは、トピックブランチの作業とチケットが連動できていても、プルリクを送りたい場合、プルリクに相当するリビジョンをチケットに明示的に書いて、チケットを「プルリク」ステータスに変更して、作業するのは面倒ではないか?

akipiiさんのツイート: "#redmineT @tkusukawa さんの質問はとても重要。そもそもソース修正の発端、変更管理はどこでやるの?GitHub のプルリクでやるとしても、発端のチケットが登録されてから、ソース修正が発生する。プルリクは発生チケットの後になる。ではどうやって紐づけるの?"

門屋浩文@redmineエバンジェリストの会さんのツイート: "修正変更の出発点と完了条件を決めるツールによるということか? #redmineT… "

おそらく一般の運用ルールでは、GitのトピックブランチとRedimneチケットは1対1に対応させるはず。
たとえば、Redmineチケットを発行後、チケット番号をGitブランチ名に明示的にSuffixとして入れて、対応付けて運用するだろう。
たとえば、#12ブランチみたいな感じ。
すると、masterにマージしたい時に、プルリクしたい、というステータスをRedmineチケット上に設けざるをえない。
つまり、Redmineチケット上のステータス変更でプルリクを検知し、コードレビューが行われ、OKならば、マージされてチケットもCloseされる運用になるだろう。

本来はこの運用がRedmineの機能として、手軽に操作できるように実現できたらいい。
現状は、Git上でマージ作業を行い、Redmineのチケットを別途更新する、といった作業が2つのシステムで発生するので、正直面倒に感じやすい。
実際、GitHubでは一つの画面で操作できているから、尚更そう感じてしまう。

一方、Redmine本家のPatchチケットのように、パッチファイルとRedmineチケットが1対1の場合もある。
つまり、Redmineチケットが発行されないまま、トピックブランチが作られ、マージして欲しいなと思う時点でパッチファイルを出力して、Redmineチケットにパッチファイルを添付する運用スタイル。

この運用では、trunkが成長するにつれて、パッチファイルが古くなってしまい、マージされるタイミングを逸失されがちになる。
昨今のように、ビジネスレベルでもアジャイルが求められる時代では、このパッチ主導の運用は正直、時代に合っていないと思う。

よって、今後のRedmineのGit連携の機能改善としては、下記3点が必須になるのではないか。

(1)GitのBareリポジトリ作成を画面上の操作で行える。
さらに、GitのBareリポジトリはリアルタイムに同期される。
(2)GitのトピックブランチとRedmineのチケットを1対1に明示的に対応付ける操作を画面上で行える
(3)GitHubのようなプルリク機能をRedmineにも取り入れて、GitのマージをRedmine画面上で操作できるだけでなく、チケットCloseも自動更新できるようにする

【6】参加者に聞いてみたら、東京Redmine勉強会ではいつも講演が盛り沢山なので、たとえば午前10時から午後17時までRedmineカンファレンスを開催する、とか、限定されたテーマでRedmine勉強会を開催してはどうか、という意見があった。

Rubyカンファレンスには及ばないけれども、Redmineカンファレンスみたいなイベントがいつか開催できるといいな。

| | コメント (0)

2018/05/25

第14回東京Redmine勉強会の見所


第14回東京Redmine勉強会の見所についてラフなメモ。
そして、今後のRedmineコミュニティの方向性について、最近個人的に考えていることをラフなメモ書き。

【参考】
第14回勉強会 - redmine.tokyo

第14回redmine.tokyo勉強会 - connpass

【1】今回の勉強会では、講演者もLTを含めて11人と豪勢な内容になった。
また、Git連携に関するパネルディスカッションを入れたり、グループディスカッションも入れているので、相当盛りだくさんの内容になっている。

【1-1】今回のテーマは『Redmineとその周辺ツール活用事例』。
REST APIやGit連携、他システムの連動に関する事例がある。

僕は、Redmineの醍醐味は外部ツールと色んな手段で連携できるI/Fを持つことではないか、と思っている。
なぜなら、Redmine単体で不足している機能は、Redmine標準で用意しているI/Fを使って外部ツールに任せることができるから。
そういうシステム設計や運用を考えるのも楽しい。

また、Redmineは構成管理ツール連携が当初から標準だったので、この機能を使ってトレーサビリティがどんな性質を持つものなのか、実体験できたのも良かった。

但し、今後はGit連携の強化がRedmineの鍵になると思っている。
その内容に関する議論は、パネルディスカッションで盛り上がるだろうと期待している。

Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索

【1-2】個人的には、@akabekobekoさんに講演して頂けることがとても嬉しい。
以前から、下記の記事は参考にしていた。

Redmine 運用について 1/3 ? はじめに ? アカベコマイリ

Redmine 運用について 2/3 ? 運用ルールと諸設定 ? アカベコマイリ

Redmine 運用について 3/3 ? 普及の施策と課題 ? アカベコマイリ

(引用開始)
つきあいの長い Redmine について以前からまとまった文章を書いてみたかったのだが、なかなかその気にはならなかった。書きはじめたら長くなるのは必然で、そのため腰が引けていた。そんな折、Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例: プログラマの思索はてブの反応はよい刺激になった。
Excel 中心で管理したい上司をどう説得するか。説得を諦めて現実解として Excel ジェネレーターを実装するのか。
幸い私は理解ある環境に恵まれて Redmine 導入に成功したが、そうではない人や環境に対して知見の一部でも役立てば、という気持ちで記事にしてみた。
(引用終了)

既存のExcel中心の組織文化の中で、いかにRedmineを浸透させて効果を上げていくか。
そんな組織の中で、現実的で実現可能な方法やレベルはどこにあるのか。
その辺りも聞いてみたいと思う。

【2】今後のRedmineコミュニティの方向性について、最近色々考える点はある。

一つは、Redmineユーザのレベル感や興味に関するセグメント別に、Redmine勉強会を定期的に開けたらいいな、と思うこと。
理由は、東京Redmine勉強会はいつもすぐに満席になってしまうので、せっかくRedmineに興味を持っている人達を取りこぼしてしまっているのが残念だから。

最近の勉強会に参加する人達とグループディスカッションで話を聞いてみると、長年の経験者もいれば、今から触ってみたいと思いますという初心者まで幅広かった。

そんな状況をふりかえると、経験者や初心者というレベル別に向けた勉強会を別の日程で開催してみる、とか、ViewCustomizeプラグインの使い方や効果的な事例のような特別テーマに関する勉強会を開催してみる、とか、もっとバリエーションを増やしてもいいかなあ、と思う。
既に、Redmineエバンジェリスト会のように、組織とRedmineをテーマにした勉強会も運営されているので、もっと増えたらいいな、と思っている。

もう一つは、Redmineコミュニティを東京や大阪だけでなく、各地でも開催できたらいいな、と思うこと。
なぜなら、東京でも大阪でも、福岡や福井、名古屋などの遠方からの参加者が意外に多いからだ。
今の自分のパワーでは東京と大阪ぐらいしかタッチできないけれど、Redmineユーザが各地にいるならば、各地で開催できるといいなあ、と思う。

こういうオープンソースのコミュニティ活動に好きで関わっているけれど、じきに、こういうコミュニティを半永久的に維持していければいいなあ、とぼんやりと思っている。
どんな実現方法があるのか、正直分からないけれど、いつか実現できるといいな。

| | コメント (0)

2018/04/25

Redmineの直近の課題~競合ツールGitlabに対抗できるか

2018年4月現在、Redmineの今後の課題について考えてみる。
以下はラフなメモ書き。

【1】Redmine大阪や東京Redmine勉強会にスタッフとして活動してきた中、参加者も大幅に増えて、参加者層も初心者から経験者まで広がり、業種もIT業界だけでなく特に製造業にも広がっている印象を持っている。

たぶん、RedmineはRailsアプリ、そしてチケット管理ツールの中で、日本で最も普及したアプリの一つだろう、と思う。

しかし、技術革新の流れが早い中、Redmineにも課題がチラホラ見えてきたように思う。
僕は、Redmineの直近の課題は、Redmineのシングルページアプリケーション化、Redmineのコンテナ化、Git連携の強化だろうと思う。

【2】1つ目は、RedmineのUIが古臭いと言われる問題意識だ。
たとえば、スマホに慣れていると、Redmineのように画面更新のたびにリフレッシュされる仕組みは正直手間がかかるイメージだ。
一つの画面内で、必要な箇所だけ更新するだけで、画面全体がリフレッシュされる必要はないはず。
その分、処理速度も早くなるし、ユーザの利便性も上がる。
つまり、昨今のUIで主流のシングルページアプリケーションのような仕組みをRedmineにも導入していくべきだろう。

以前、RailsはJavascriptと相性が良いので画面UIもリッチで使いやすかった。
しかし、Railsフロントエンド技術も、昨今の時代の流れの影響を受けて、どんどん進化している。

Railsフロントエンド技術の今とこれから - Hack Your Design!

rails × AngularJSでシングルページアプリケーションを作るTips - Qiita

Rails5.1に向けてフロントエンド周りで起こっている革命まとめ - Qiita

一方、競合の状況を見ると、有償のチケット管理ツールであるJiraやBacklogに比較されやすい。
それらツールは、昨今の時流に合わせてUIフレンドリーな画面になっている。
もちろん、OSSのRedmineに対し、営利目的の会社が多数の開発者というリソースを持つ競合の方が恵まれている点は否めない。

【2】2つ目は、Redmineのインストールやバージョンアップが難しいと言われる点だ。
初心者にとって、RubyやGemをインストールする時、バージョン違いによって、ハマってしまう場合が多い。
Redmineを使いたいだけなのに、セットアップに手間取ってしまって断念するケースも多いのではないか。

Redmine 3.4をCentOS 7.3にインストールする手順 | Redmine.JP Blog

この点に関しては、最近、Gitlabにも注目している。
特に、Gitlabでは、バックアップやコンテナ化など技術的にも優れている点が見えてくる。

たとえば、バックアップやリストアはrakeタスクで用意されているので、Cron化しておけば、保守で気にする必要はない。

Rake tasks | GitLab

また、GitlabCIまでセットアップすれば、Redmine+Jenkinsよりも使いやすい点はあるだろう。
インストール対象が2つのツール(RedmineとJenkins)よりも1個のツール(GitlabCI)の方が楽だから。

Gitlab + Gitlab CI をためす - LGTM

個人的には、RedmineのバージョンアップをiOSの自動更新みたいに、もっと手軽にすべきだろう、と思う。
現状でも、プラグインをGem化するアイデア、RedmineをDockerでコンテナ化する、等が色々試されている。

Feature #27705: Gemify redmine plugins - Redmine

これらアイデアをさらに発展させて、Redmineのバージョンアップの自動更新がワンクリックで可能になるように、改善されるべきだろう。
たぶん、Dockerのようなコンテナ化に解決の鍵があると感じている。

なぜなら、ちょうど今はコンテナ化や仮想化のように、インフラ基盤をプログラム化する技術が一番ホットな話題であること、それら技術がクラウドと相性がすごく良い事もあるからだ。

【追記】
RedmineのDockerは下記でインストールできる。
Windowsでも問題なくインストールできるのはすごく良い。

Redmineインストール from Docker Hub - Qiita

【3】3つ目は、RedmineはGit連携の機能が弱い点は、従来からずっと知られていた。

一方、Gitlabのチケット管理もRedmineより弱いとは言え、着実に改善されている。
一般に、SVNよりもGitを使うのが普通なので、この点に関してRedmineは多少不利な面がある。
いつか、Redmineの競合候補になってくるのではないか。

RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

【4】個人的には、Redmineの競合ツールは有償ツールであるJiraやBacklogではなく、OSSのGitlabになるのではないか、と思っている。

理由は、ポジショニングマップで書くと、RedmineとGitlabはちょうど正反対の位置に配置されるからだ。
実際、「Git連携が強い・弱い」軸と「チケット管理機能が強い・弱い」軸の2次元でプロットしてみれば、「Git連携が強く、チケット機能が弱い」GitLabと、「Git連携が弱く、チケット機能が強い」Redmineで斜め方向にプロットできる。

よって、RedmineとGitlabは全く正反対の性質を持つツールなので、現在は双方を連携することで相互補完する方向に進化している。
すなわち、Redmineでチケット管理して、Git管理やプルリクエストはGitlabで行い、WebhookによりチケットとGitを連携できるようにする運用スタイルだ。

GitLabとRedmineを連携してみるの巻 - アルパカDiary Pro

GitlabとRedmineを連携させる方法の覚書。 - Qiita

でも、RedmineもGitlabもGit管理やチケット管理の機能を強化していく方向へ進化するならば、競合することになるだろう。

なお、Gitlabには、GithubクローンとしてOSS版とエンタープライズ版が提供されている。
ビジネスモデルとしても、うまいやり方だと思う。
なぜなら、OSSで提供することにより、ユーザ数を増やせること、また、ユーザのフィードバックを受けて有償ツールに反映してどんどん機能拡張できること、があるからだ。

GitlabもRedmineと同じくRails基盤なので、改修しやすいし、機能改善の進化も速いので、近い将来、現在のRedmineの優位性は変化していくかもしれない。

たとえば、Gitlabが強力なチケット管理機能を実装したら、プログラマ層は皆、RedmineよりもGitlabに流れてしまい、Redmineのユーザ数は減ってしまうだろう。

現在は、たまたま、日本のRedmineユーザに熱いパッションを持つ人達が多いので、最新機能をいち早く試して人柱になったり、数多くの運用事例を紹介してくれたりして、コミュニティ中心に盛り上がっているけれど、いつまでもそういう幸運は続かないかもしれない。

GitLabでタスク管理してみた感想(主にRedmineとの比較) - YoshinoriN's Memento

【5】とはいえ、そういう課題がRedmineに見えてきたが、たぶん、解決できるだろうと楽観視している。
また、技術者として、ツールの課題を技術面から解決していったり、それについて色々試行錯誤して技術を試すことは楽しい。

今後もいろいろ考えてみる。

【追記1】
Gitlabの場合、RPMが提供されている。
よって、yum updateだけで簡単にバージョンアップできる。

Manually Downloading and Installing a GitLab Package | GitLab

GitLabを7.9.2から7.12.0にアップデートした時の話 - Qiita

Git lab rpm でインストール - Qiita

Redmineでも、RPMを提供できないだろうか??
また、Redmineのバックアップ用のrakeタスクも実装できないだろうか?

そうすれば、プラグイン無しの標準Redmineであれば、DBバックアップと添付ファイルバックアップだけすれば、VerUp作業そのものを自動化できるからだ。
RedmineやRubyの初心者であっても、インストールやバージョンアップ、バックアップに苦労する問題はなくなるだろう。

【追記2】
皆同じ事は考えている。

taikiixさんのツイート: "現代の開発フローがGitとPRを中心としていることを考えるとPRの実装は喫緊の課題だと思います。でもそれ以上に、半年でメジャーバージョンアップするGitLabに対抗するには今の開発スピードでは歯が立たない。だからRedmineはGitHubに開発の場を移し、広くcontributorを集める必要があると思います。… https://t.co/jt4Kmk9pCx"

MAEDA Goさんのツイート: "gitへの移行はJPLがその気になる必要があるため、簡単には進まないと思います。本家のやり方を変えずに開発への参加のハードルを下げる方法として、非公式のミラーリポジトリでプルリクエストを受け付けて私がGitHubとチケットの中継をするのはありだと思います。私が中継するので日本語でOKです。… https://t.co/LIFzu4B1lk"

【追記3】
akipiiさんのツイート: "日本の熱心なRedmine ユーザーは自らモルモットとなり、自ら海に飛び込んでいくのです!その結果は如何に?… "

あさこさんのツイート: "大きな海に溺れるも、無人島にたどり着く。そこの名は、redmineアップデートセンター…‼… "

akipiiさんのツイート: "@agilekawabata さんに解決してもらって、 @g_maeda さんに本家に取り入れてもらいましょう。。。… https://t.co/svy5cW1puI"

やっさんさんのツイート: "GitHubがメインリポジトリならもっと参加者増えて開発も回りそうな気もするんですけどねぇ🤔… https://t.co/YekJeR0RRl"

【追記4】
門屋 浩文さんのツイート: "こちらこそー。これは感覚論だけど、同じシステムを使う人は似たような振る舞いをするようになる。社会や文化と同じように。redmine関係者の振る舞いや感性は、正直好きだね。いろいろおいてきた、できなかったことが少しずつできるようになるヨ・カ・ン… "

akipiiさんのツイート: "似た振る舞いになる、と言う話は同感。たぶんチケット管理してれば、Redmine でもJiraでもTrelloでも手法や考え方は同じ。以前できなかった事がチケット管理ツールで実現できる予感も同感。ソフトウェア工学は本来はこういう開発基盤が欲しかったはず、といつも思う。… https://t.co/3OzYY4e39R"

akipiiさんのツイート: "Redmine にある機能は、細かな一機能に過ぎないかもしれないが、人の行動を変えさせるきっかけになる、と言う事例は心当たりがないですか? 是非エバンジェリスト会でネタを集めてください笑… "

akipiiさんのツイート: "Redmine でバージョンアップごとに改善された機能には、世界中の開発者が試したベストプラクティスが反映されてる。ツールの機能とプラクティス、そして開発プロセスは表裏一体と思います。特に最近のRedmine,Gitlab,Jenkinsはそう強く感じる。… https://t.co/N1LJQ69erp"

あさこさんのツイート: "redmineにも、アップデートセンター入れてほしい。… "

あさこさんのツイート: "あわわわわわ… 川口さんが、jenkinsはアップデートセンター入れてから爆発的に広がったと言っていたので、同じような経路をたどるかもしれませんね。。 そうすると、redmineバージョンアップの毒沼地はいい感じで消えていってくれる…かもしれませんね(・_・;)… https://t.co/tSddJPec3O"

akipiiさんのツイート: "似た話として、Gitlabにはrakeコマンドで自動バックアップするコマンドがあった気がする。Redmine と同じRailsアプリならば、他ツールの機能をパクるやり方もありですね。… "

【追記5】
RedmineのREST APIにも、SwaggerのようなI/F仕様書のWebサーバーがあれば、もっと使い勝手は良くなるだろう。

SwaggerでRESTful APIの管理を楽にする - Qiita

SwaggerでWebAPIドキュメントをExcel仕様書から脱却するアイデア: プログラマの思索

あきこさんのツイート: "RedmineのAPIはドキュメントが分かりにくいかな? 公式サイトにも載ってるけれど、GETしか対応してなかったり。 apipieやswagger docのようにソースコード中のコメントや説明がそのままドキュメントとして表示できるようになってたらなあ...なんて思います。"

あきこさんのツイート: "他はわからないんだけれど、JenkinsはRest APIのドキュメントのページがアプリケーションの一部としてくっついてた。JIRAやConfluenceも、ローカルで動かしたとき、Rest API Browserっていうのがあって、APIの仕様の確認がしやすかったなー。"

| | コメント (0)

2018/03/16

複数Redmineの内容を一つのRedmineに集約して見る方法

複数Redmineの内容を一つのRedmineに集約して見る方法について、ツイートされていた内容を@y503unavailableさんがまとめてくれたのでメモ。

【元ネタ】
気づき #764: 複数Redmineの内容を集約して見たい。 - Unofficial Redmine Cooking - redmine.tokyo

【発端】
@j15_aj15さんから、社内に複数のRedmineインスタンスが起動されていて、それらRedmineのチケット内容を一つのRedmineの画面上に集約して見たい、という要望があった。

昌。さんのツイート: Wiki Extensionsプラグインのiframe使ってよそのRedmine見よ!って思ったけど動かない。バラけてるタスクをメインの子で見れたら幸せだったのに。

【関連ツイート】

りょうまさんのツイート: "自ホストのapacheなりnginxでリバプロしてやって、自ホストのURLとしてiframeに埋めれば見られるのではないでしょうか。 パスの階層違うと別な対処が必要ですが。… "

あきこさんのツイート: "iframeで他のサイトに埋め込みできると、クリックジャッキングという攻撃(悪用)ができてしまうので、レスポンスヘッダに「ブラウザさん、このサイトはほかのサイトのiframeに読み込んじゃだめねー」という情報を渡すのです。多分これかなと。… https://t.co/dozV8W5zBx"

あきこさんのツイート: "更新系の操作ができるサイトはiframeで意図せず埋め込まれるのに気をつけないといけないです。 https://t.co/NsfRjWF9PW… "

あきこさんのツイート: "Redmine (というかRails4以上かな) デフォルトでsameoriginです。 ソースを変えない前提なら、各Redmineが同じドメインでSub URIで複数稼働してるケースなら行けると思います。https://t.co/Fixggi7YmP, https://t.co/eOhIZmak4f みたいな感じだったら。安全性を鑑みてAPIで統合が良いとは思います。… https://t.co/q1y6F9QVHm"

昌。さんのツイート: "解除できたらいいなー。情報一元化したい。 現実問題、他方のRedmineにタスクが散らばってること、結構あるんですよね。… "

neta@筋肉 筋肉〜💪さんのツイート: "https://t.co/gcFS9svZF5第12回勉強会/ のLT4 が(jvasseurさん)「複数 Redmine での開発のためのツールを作ってる」話でした(Private になってるようなのでスライド直リンクできず)。 これもAPI経由ですね、チケットを見るのではないかもですが… https://t.co/SVNfI5GRkH"

昌。さんのツイート: "もんのすごく乱暴ですが、とりあえず自分の環境でタスク一元確認するために、Ignore X-Frame Headerで一時的に回避してみました。少しだけ幸せ。皆様、有効なご意見色々ありがとうございました。さらに精進します。… https://t.co/zlcb3ZDv0J"

【一つの解決方法】
(引用開始)
(1)リバースプロキシの利用

RedmineのWebサーバ側でリバースプロキシし、
参照先Redmineの表示内容を自ホストのURLとして表示可能にすることで、iframeを利用して表示できる。

(1-1)iframe , X-Frame-Options ヘッダ設定

Wiki Extensionsプラグインのiframe使って別Redmine上の内容も表示させたいが、
X-Frame-Options ヘッダで制限されている。
→X-Frame-Options ヘッダのALLOW-FROMで、参照先サーバを許可サイトに追加するなどの対応が必要。

iframeの利用には、セキュリテイ面の注意が必要(クリックジャッキング攻撃などの対策)
『クリックジャッキング』に関するレポートに関するレポート(IPA 技術本部 セキュリティセンター)
(引用終了)

(2)あるいは、PCクライアントにて、X-Frame-Options ヘッダを無効化するChromeエクステンションなどを入れておく。

ローカル環境でX-Frame-Optionsを無効化する - 仕事中の問題と解決メモ。

【X-Frame-Options レスポンスヘッダ】
X-Frame-Options レスポンスヘッダ - HTTP | MDN

X-Frame-Optionsの設定 | 勉強したことのメモ

【クリックジャッキング攻撃】
IPAテクニカルウォッチ 知らぬ間にプライバシー情報の非公開設定を公開設定に変更されてしまうなどの『クリックジャッキング』に関するレポート:IPA 独立行政法人 情報処理推進機構

(引用開始)
サイトへの攻撃はX-FRAME-OPTIONSヘッダが付与されていないからというだけで、攻撃を受けてしまうとは必ずしもいえませんが、IPAではこの対策が最も有力な手段であると考えています。
(引用終了)

クリックジャッキングとは?その攻撃事例と対策方法を解説 | サイバーセキュリティ.com

Webエンジニアだったら当然知っておきたい「 クリックジャッキング対策 」とは? | ヌーラボ

≫ クリックジャッキングって? TECHSCORE BLOG


【感想】
社内にRedmineが複数個インスタンスが立ち上がっている利用シーンはとても多い。

自分たちのチーム専用のRedmineが欲しいニーズもあるし、RedmineインスタンスはBitnamiやDockerなどですぐに立ち上げられるからだ。
すると、社内にRedmineが乱立してしまい、PMOや品質保証部の立場では、各プロジェクトの進捗状況を知るために、各Redmineインスタンスにログインしてデータを取得する手間が発生してしまう。
だから、PMOが主体で管理しているRedmineに、各プロジェクトのRedmineの進捗データを集約するようにしたい。

では、どうやって、複数個のRedmineインスタンスの情報を、一つのRedmineサーバー上に集約させて表示させるか?

この解決方法のアイデアは、@netazoneさんがRedmine大阪のLTにて披露してくれた、RedmineにGoogleカレンダーや動画、Googleスプレッドを埋め込むためにiframeタグを使う方法を公開したノウハウが発端になる。

Redmine にいろいろ埋め込んて゛みた

(引用開始)
今回のテーマは”Embed”(埋め込み)。
Redmine にカレンダーやら動画やら埋め込んでみたところ、意外にうまくやれて捗ったのでご紹介。
(引用終了)

留意点としては、クリックジャッキング攻撃のようなセキュリティリスクの可能性があるので、社内LANの閉じた中だけで行う方が安全だろうと思う。
しかし、社内LANの中でさえも、セキュリティ対策上、許可されない場合もあるかもしれないので、細心の注意を払う必要がある。

とはいえ、Redmineユーザとしては、ちょっと危険な香りのする(笑)ノウハウが蓄積されることも楽しい。


| | コメント (0)

2018/03/12

RedmineもOSLC規格を導入してトレーサビリティを強化すべきか

@agilekawabataさんが、RedmineにOSLC規格を実装すべきでは、と提案されていたのでメモ。
詳細は知らないので、ラフなメモ書き。
間違っていたら後で直す。

【参考】
Feature #8678: Provide OSLC support - Redmine

(引用開始)
Open Services for Lifecycle Collaboration(OSLCまたはオープンサービスとも呼ばれます)は、ライフサイクルツールを組み合わせて使用しやすくすることで、製品ライフサイクルとアプリケーションライフサイクルの間の障壁を解消するためのオープンコミュニティです。
(引用終了)

Kawabata Mitsuyoshiさんのツイート: "チケットによく気付きましたねー。 ツール連携の標準規格です。JIRAは対応してて、こういうのが世界標準としては必要だなあと。 https://t.co/RV0KgGh56u… "

Kawabata Mitsuyoshiさんのツイート: "自動車業界など、欧米の大手企業には必須な感じです。ただ、RedmineもWebAPIがそれなりに揃ってるので、もしかしたら対応できてるのか、どこまで対応すれば良いのかがよく分からない。。… "

Kawabata Mitsuyoshiさんのツイート: "規格に対応することで、他のツールが標準で連携をサポートするようになり、複数のツールによってシステム構築するような大手には導入が進みます。JenkinsやGitHubと連携するようなことと同じです。世界的に広めるには結構重要な要素だと思います。… "

Open Services for Lifecycle Collaboration

OSLC CM Plugin - Jenkins - Jenkins Wiki

OSLC Japan Wiki : 1.OSLC とは

【1】OSLCとは、アプリケーションライフサイクル管理(ALM)でツール連携する時の公式規格のように思える。

OSLCの利用 - Enterprise Architect 13.5 日本語版 ヘルプ

(引用開始)
Open Services for Lifecycle Collaboration (OSLC) とは、ツールを統合するための仕様を定義するオープンなコミュニティです。
この仕様により、利用者の設計開発プロセスにおいて、さまざまなツールを連携させ設計データとワークフローを統合した環境を作ることができます。

OSLCはW3C Linked Dataに基づいています。OSLCでツール間を繋ぐ主要な技術の一つは、HTTPでデータを繋ぐことです。HTTPやRDFのような標準的な技術で、データの作成・参照・編集・削除を実現します。
HTTPのGETやPOSTのような標準的な方法で内容を編集できます。
(引用終了)

OSLCに対応したアプリ一覧では、Jira、Bugzilla、Mantis、Jenkinsなども含まれる。
よって、ツール連携する時に、この規格を使うことも可能。

Software - Open Services for Lifecycle Collaboration

【2】では、このOSLC規格を使うと、何が嬉しいのか?
僕は正直分からない。
今の所、OSLC規格がなくても、Redmineの運用で困った経験はない。

しかし、2012年の古い記事だが、自動車業界の安全規格ISO26262に準拠するために、このOSLC規格を持つALM管理ツールは必須だ、という主張があった。

ISO26262 日本IBM インタビュー:規格準拠は“入場券”にすぎない、ISO26262をきっかけに製品開発力の強化を (2/2) - MONOist(モノイスト)

(引用開始)
MONOist オープンという意味では、「Redmine」のようなOSS(Open Source Software)ベースのプロジェクト管理ツールも候補になりませんか。

根城氏 OSSベースのツールを組み合わせてトレーサビリティを確保することもできますが、プロセスが複雑になります。その上、ISO 26262のPart.8で求められる「Qualification of Software Tools」を満足させるための情報入手が困難です。
 また、ISO 26262に準拠するということは、その製品の企画から廃棄まで最低でも20~30年はデータを管理し続ける必要があります。そのISO 26262と関連するツールも、長期間のサポート継続が確保されていなければなりません。
 小規模の企業のツールやOSSベースのツールは、このサポート継続に不安があります。これに対して当社は、DOORSやRTCについて継続的なサポートを約束していますし、世界的な大企業であることから買収の恐れもありません。
(引用終了)

上記の意見に僕は納得できていないが、そういう発想もあるのだろう。

【3】ここで、上記のOSLC規格の背後にある意図を推測すると、チケット管理・ビルド管理・構成管理の全ツールで、OSLC規格に準拠していて、このOSLC規格が使いやすいものになれば、ツール間連携でトレーサビリティを明示しやすくなる、というメリットを導き出したいのだろう、と思う。

なぜなら、自動車業界の安全規格ISO26262では、機能や要件から成果物に至るまでのトレーサビリティを明示することがプロセス管理の観点で重要である事により、OSLC規格を満たすツール同士を連携して、要件から成果物までを明示的にトレースできますよ、と言った事がやりたいのだろう、と推測されるから。

但し、その方向性をOSLC規格で解決できるのか否かは分からない。
過去にも、SOAPやらソフトウェアタグやら、WSDL・UDDIなど、数多くの規格が提唱されては、消えていった歴史があった。
OSLCは残っていく規格なのか?

【4】Redmineにおけるトレーサビリティについては、Redmineを使い始めてから、トレーサビリティの可能性、そして、トレーサビリティを実現できる範囲をどこまで拡張できるか、をずっと考えてきた。
未だに僕の中では解はない。

Redmineにおけるトレーサビリティの課題は何か?: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

チケット駆動開発がもたらした新しい観点part2~トレーサビリティの拡張: プログラマの思索

実際、僕自身、Redmine大阪でも、Redmineでのトレーサビリティの実験結果を発表したが、まだまだたくさんのハードルがあって、思い通りの結果は得られていない。

Redmineにおけるトレーサビリティ管理の現状と可能性(第66回 SEA関西プロセス分科会&第18回 Redmine大阪) #RedmineOsaka

いろいろ考えてみる。

【追記】
akipiiさんのツイート: "内容を聞きたい。そもそも今必要な規格か?RT @ir9: ぶっちゃけ当時そこそこ関係する(糞な)ソフトを創っていた(ぉ // RedmineもOSLC規格を導入してトレーサビリティを強化すべきか https://t.co/mJwHYSu4j6"

いろきゅうさんのツイート: "直接OSLCには関わらないお話で恐縮ですが… リンク記事のようにその昔の車業界の一部では、仕様書からソースまでを紐付けて仕様変更時の影響範囲を知りたい…という飯ネタがあり、そのようなソフト開発に関わってました。「そのうちOSLC対応する」と意識していましたが対応はしていません(申し訳ない… https://t.co/PygxMeoimR"

いろきゅうさんのツイート: "作成してたツールとしては… たとえば、EAのアプリ上にあるUML要素を選択して「関連要素検索」→「wordのxx章 / Excelのyy表 が関連」等出てるのは便利感ありましたが…… アプリ超えた要素の紐付け作業が面倒というのが正直な所でした…… "

akipiiさんのツイート: "ありがとうございます。やはり規格倒れな感じですかね。JenkinsのOSLC対応プラグインも2012年から更新停止だし。Redmine への実装優先度はかなり低そうですね。… "

| | コメント (0)

より以前の記事一覧