Redmine

2017/02/16

Redmineの次期バージョン3.4の見所

@g_maedaさんのRedmine開発状況の記事を読んで、Ver3.4のリリースが楽しみになってきた。
以下、ラフなメモ書き。

【参考】
2017年1月のRedmine開発状況 | Redmine.JP Blog

2016年12月のRedmine開発状況 | Redmine.JP Blog

2016年11月のRedmine開発状況 | Redmine.JP Blog

【1】Patch #21705: 「長いテキスト」形式カスタムフィールドの「ワイド表示」オプション

Patch #21705: Option for long text custom fields to be displayed using full width - Redmine

テキストエリアのカスタムフィールドの領域を広くしてくれるオプションが付く。
たとえば、障害報告用のカスタムフィールドをたくさん作っている場合、障害原因・是正対策の内容を記載してもらう時に、現在のバージョンでは、テキストエリアの領域が狭いので、書きにくいし読みにくい。
結局、入力が億劫になる。

この改善のおかげで、障害報告チケットの見栄えも良くなり、その分、チケット更新者の動機づけも上がるだろうと思う。

【2】Feature #23265: バージョン形式カスタムフィールドのフィルタをステータスごとにグループ化

Feature #23265: Group versions by status in version custom field filter - Redmine

使い道としては、Redmineのバージョンをシステムのリリースバージョンとして扱っている場合、障害が起きたリリースバージョンとか、影響のあるリリースバージョンのような項目がステータスごとにグルーピングされる。
Redmineの運用期間が長くなるほど、バージョンも多くなってくるので、こういう細かなUI改善は、利用ユーザにとって嬉しい。

【3】Feature #23310: 「プロジェクトへ移動…」ドロップダウンの改善

Feature #23310: Improved "jump to project" drop-down - Redmine

画面右上のプロジェクトプルダウンに、インクリメンタルサーチ機能が付く。
Redmineの運用期間が長くなるほど、プロジェクト数は数百~数千に増えてしまうので、こういう細かな機能改善はありがたい。

【4】Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止

Feature #10989: Prevent parent issue from being closed if a child issue is open - Redmine

WBSの階層構造を親子チケットで表現した時、現状のRedmineでは、子チケットが全て終了ステータスでなくても、親チケットは終了ステータスに変更できる。
しかし、本来のWBSの100%ルールでは、そうではない。

この機能改善では、設定画面で、WBSの100%ルールの可否を選べるようになるので、より厳密にWBSをチケットで表現できるようになる。

個人的には、WBSを親子チケットで表現した場合、親チケットが子チケットから独立させない、とか、未完了の子チケットを持つ親チケットのクローズを禁止すべき、というルールを完全に当てはめると、実運用ではやりにくくなる経験が多かった。
結局、適度に緩い運用の方がやりやすい。
この辺りの運用ノウハウは、各地のRedmineエバンジェリストの意見を聞きたいところ。

Redmineの親チケットの値に子チケットをロールアップさせない設定方法: プログラマの思索

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

【5】個人的に欲しい機能は、「Feature #24681: シンタックスハイライトの対応言語を100以上に増やす」だ。

Feature #24681: Syntax highlighter: replace CodeRay with Rouge - Redmine

.NET開発者は普通にたくさんいるので、彼らから、C#もシンタックスハイライトに対応して欲しい、という要望は非常に多い。
しかし、現状のRedmineでは、シンタックスハイライトの対応言語にC#が対応していないという悲しい事実がある。
Redmineはチケット管理だけでなく、Wikiやリポジトリのソース差分表示などもよく使うので、早く実現して欲しいと思う。

【その他】
奈良さんがRedmine本家に、Redmine.orgの全チケットに対し、「+1」のコメントを集計した結果を載せてくれている。
「Redmineの改善要望チケットが埋もれているためにフィードバックされていない」事実に危機感を持っていて、集計結果を掲載することで、実際に行動に移してくれた。

Redmine.org tickets vote count list - Redmine

コントリビュータのMischa The Evilがこんなコメントを残してくれている。

「私は、この拡張リストは、コミュニティの興味を見つけるための素晴らしい情報源だと思う。
そういうわけで、これらは非常に貴重な貢献だと思います。
作成して共有していただきありがとうございます。」

このフィードバックが今後のRedmineのリリース計画に活用されたら、Redmineはもっと使いやすくなるだろうと思う。

Unofficial Redmine CookingプロジェクトでRedmineカスタマイズのノウハウを皆で集めてみよう: プログラマの思索

Redmine本家未取込チケットで人気のあるチケット情報: プログラマの思索

| | コメント (0)

2017/02/13

Redmine 2.x→3.xへVerUpした時に画面レイアウトが崩れる症状に対する対応方法

Redmine 2.x→3.xへVerUpした時に画面レイアウトが崩れる症状が発生して、困っていた。
この対応方法について、@netazone さん、@g_maedaさんに教えてもらったのでメモ。
二人に感謝。

【参考1】
Defect #24617: Browser js/css cache remains after upgrade - Redmine

neta@とんこつしかたべないさんのツイート: "バージョンアップ後のRedmine 3.3 の表示が崩れる、と思ったら再読み込みでなおる。 →つまりブラウザ側のキャッシュか。 Redmineのセッションクリアはやったと思うんだが、これはどうしようもないんかな"

MAEDA, Goさんのツイート: "@netazone パッチが出てます https://t.co/12AcycptT2"

neta@とんこつしかたべないさんのツイート: "@g_maeda @akipii 件のパッチを本番反映してみました。ブラウザ履歴からバージョンアップ前に開いたチケットをいくつか開いてみましたが、発生していません。別PCで1回だけ崩れましたが、ブラウザ開きっぱの端末だったので怪しいです。明日騒ぎにならなければ効いたといえそうです"

MAEDA, Goさんのツイート: "@netazone @akipii 崩れるときはバージョンアップ前に開いたページでなくても崩れます。HTMLのソースの中で読み込んでいるCSSやJSのファイル名の後ろに ?1486805824 みたいに数字がついてればOKです。"

neta@とんこつしかたべないさんのツイート: "@g_maeda @akipii ソース表示で確認できました。ありがとうございます。 Redmine 3.3.2で適用は以下やりました。 ・パッチ適用 ・tmp:cache:clear tmp:sessions:clear(念のため) ・Redmine再起動 https://t.co/4nbGURiyOf"

【参考2】
Redmine3.3で表示崩れする件で色々教えていただいた | UCWD-Studio - @matsuoka_UCWDjp 's Private Projects.

【状況】
Redmineを2.x→3.xにVerUpした時、ローカルPC上では全く問題なのに、サーバー上でVerUP後、画面レイアウトが崩れてしまう。
その原因がどうしても分からず、結局、リストアせざるを得なかった。
サーバー上でキャッシュクリア、クライアントでクッキーをクリアしても、再現してしまうみたい。

【原因】
@g_maedaさんに教えてもらった下記チケットによれば、VerUp時にjs/cssのキャッシュが残ってしまうのが原因みたい。

Defect #24617: Browser js/css cache remains after upgrade - Redmine

本来は、画面ソース上では、
<script src="/redmine/javascripts/application.js?1481777729"></script>
のように、JSやCSSにセッションIDらしき数字がURLに付加されるのに、なぜか、Ver3.3にVerUpすると、
<script src="/redmine/javascripts/application.js"></script>
のように表示されてしまう。

【対応方法】
Defect #24617: Browser js/css cache remains after upgrade - Redmineにあるパッチを当てればいい。

cd redmine/config/initilizers
wget http://www.redmine.org/attachments/download/17275/0001-Adds-asset_id-parameters-to-assets.patch

patch -p1 < 0001-Adds-asset_id-parameters-to-assets.patch
10-patches.rb を入力

念の為にキャッシュクリア
bundle exec rake tmp:cache:clear tmp:sessions:clear

Apache再起動

チケット画面のソースを開くと、JSやCSSにセッションIDらしき数字がURLに付加されている

Redmineaddsasset_idparameterstoasse

色々試してみると、下記のパターンになるみたいだ。

・Ver2.xの時は、JSやCSSにセッションIDらしき数字がURLに付加されている
 ⇒問題なし

・Ver2.x→3.xへパッチを当てずにVerUpすると、JSやCSSにセッションIDらしき数字は付加されない
 ⇒画面レイアウトが崩れる

・Ver2.x→3.xへパッチを当ててVerUpすると、JSやCSSにセッションIDらしき数字は付加される
 ⇒問題なし

【疑問】
なぜ、こういう症状が発生したのか?
上記チケットの下記リンクを見ると、Ver4.2.7で廃止されたrails_asset_idメソッドから作ったパッチを当てると、解決できるらしい。

rails_asset_id (ActionView::Helpers::AssetTagHelper) - APIdock

さらに@marutosijpさんのコメントを読むと、Redmineのconfig/application.rbのasset pipeline がdisabledになっているのが原因みたいらしい。

Patch #13927: Reduce coupling between plugins and the "plugins/" directory - Redmine

config/application.rbの下記の箇所になる。

# Enable the asset pipeline
config.assets.enabled = false

/trunk/config/application.rb - Redmine

Railsの仕様を完全に理解していないので、調べてみる。

【追記1】
下記の意見もあるので、この症状に再現性があるかどうか分からない。

松岡 孝さんのツイート: "@akipii @g_maeda 今のところ問題を感じる挙動には遭遇してません。なお、3.x系は 2.6.xから3.1.1→3.1.3→3.2.1→3.2.3→3.3.2を経由してまして、その間も特に不具合に遭遇してないつもりです(除: 今回のUI部分)"

下記のBlogで原因と対処を詳細に記載してくれてます。

Redmine3.3で表示崩れする件で色々教えていただいた | UCWD-Studio - @matsuoka_UCWDjp 's Private Projects.

(引用開始)
これは Redmine 3.0.0 から Rails のバージョンが 4.2 へ移行した際に、CSS や JavaScript などの静的ファイルに付与されていた GET パラメータが付与されなくなったため、前バージョンの静的ファイルをブラウザ側がキャッシュとして持っていること(=そちらが表示に利用されている)が原因のようです。
(引用終了)

つまり、Ver2.x→3.xではcssなどで大きなUI変更があったために、前バージョンのキャッシュが残ったために画面レイアウトが崩れた。
一方、Ver3.3.1→3.3.2では、大きなUI変更がなかったために、前バージョンのキャッシュが残っていたとしても、画面レイアウトが崩れることはなかった、と推測される。

【追記2】
クライアント側では、ブラウザのスーパーリロードで対応できるらしい。

ブラウザの super reload でゆけそうな気がする。職場の Redmine も 2.x から 3.x 系に移行して更に 3.x で数回更新しているが毎回 super reload するよう案内してる。 - akabekobeko のコメント / はてなブックマーク

君は3つのリロードを知っているか? - os0x.blog
(引用開始)
ブラウザによっては、スーパーリロードという機能を備えています。IEの場合Ctrl+F5(Ctrl+更新ボタン)、Firefoxの場合Ctrl+F5(Shift+更新ボタン)、Chromeの場合Shift+更新ボタン(Ctrl+Shift+R)などでスーパーリロードを呼び出すことができます。
(中略)
リロードは大元のHTMLを受け取ったら、そのページ内のリソースについてレスポンスヘッダを確認しに行っています。その結果304 Not Modifiedが帰ってきて、実際にはキャッシュを使っています。
対してスーパーリロードはキャッシュに関係なく、すべてのリソースを取得しなおしています。
(引用終了)

【追記3】
まとめ記事がある。

QA #301: Redmine 2.x→3.xへVerUpした時に画面レイアウトが崩れる場合がある - Unofficial Redmine Cooking - redmine.tokyo

| | コメント (0)

2017/01/22

Elastic Search+Logstash+Kibana+TimelionでRedmineのBIを実現する記事のリンク

フューチャアーキテクトさんの記事で、Elastic Search+Logstash+Kibana+TimelionでRedmineのデータマイニングニングを行う記事があったのでメモ。
全てOSSのツールで、RedmineのBIを実現できるのは素晴らしい。

【参考】
マネージャーがうれしいRedmineデータのグラフ表示方法を公開します!! | Tech Blog - Future Architect

マネージャーがうれしいRedmineデータのEVM表示方法を公開します!! | Tech Blog - Future Architect

QLIKVIEWでの分析方法 - Google グループ

RedmineのチケットデータをRedmine外部のBIツールで表現するアイデア: プログラマの思索

仕組みとしては、下記の流れになる。
JDBCドライバを通じて、RedmineのDBにSQLを直接発行して、データを取得し、グラフィカルに表示するらしい。

(引用開始)
大まかな流れ

下記の手順でグラフを表示します。

1.ELKのインストール
2.RedmineデータをELKに取り込む
3.グラフ表示

1.ELKのインストール

はじめに、ELKの説明です。
ELKはelastic社が提供する、データ可視化OSSの総称。
Elastic Search+Logstash+Kibanaそれぞれの頭文字をとって、ELKと呼びます。
今回、ELKを利用して、Redmineデータの可視化環境を構築します。
(引用終了)

LinuxだけでなくWindows上でも簡単に実現できるのはありがたい。
また、集計した結果を保存でき、集計グラフをブラウザ上で閲覧できるのも良い。

毎日、集計バッチを動かすようにしておけば、上司や開発者も好きな時に見れるし、チームの開発状況を自然に見える化できるようになる。
また、チケット集計の内容だけでなく、ソースの品質情報なども公開すれば、開発者の品質意識の向上にも役立つ。

RedmineのチケットデータをRedmine外部のBIツールで表現するアイデア: プログラマの思索にも書いたが、Redmineのデフォルトのチケット集計機能が弱くても、今は、OSSで簡単にRedmineのBI機能を実現できる。
つまり、自分達が欲しい観点の集計ビューを、OSSのBIツールを駆使して作っていけばいい。

むしろ、自分達で、Redmineに不足した機能を実現していく、というプロセスの方が重要だ。
なぜなら、Redmineを通じて、自分達のソフトウェア開発プロセスをより良くしていくモチベーションの向上に役立つからだ。
上からのお仕着せのプロセス改善ではなく、メンバーが自主的に行うボトムアップ型のプロセス改善の方がはるかに意義があると思う。

Redmineの運用や集計ビューを通じて、自分達の開発プロセスのボトルネックは何なのか、どうすればより良いソフトウェア開発ができるのか、という行動を促していくわけだ。
Redmineが面白い部分はそんな所にあると思う。

| | コメント (0)

2017/01/15

Redmine本家未取込チケットで人気のあるチケット情報

@y503Unavailableさんの力作「Redmine本家未取込チケットで人気のあるチケット情報」が公開されていたのでメモ。
読んでみると、結構面白い。
@y503Unavailableさんが、幾つかのカテゴリで「+1」を集計してくれているので、感想をラフなメモ書き。

【参考】
QA #270: 本家未取込チケットを巡る(仮) - Unofficial Redmine Cooking - redmine.tokyo

気づき #280: 未完了全部(2017/01/09現在) - Unofficial Redmine Cooking - redmine.tokyo

(引用開始)
Redmine本家には、多数の未取込チケットが点在する。

+1が多いチケットには、それなりの内容がある筈だが、埋もれているのが現状。

標準に取り込まれなくとも、参考になる点は多々あるだろうし、必要な人もいる筈。
作者の思いもある。

そんなチケットに陽を当てたい。
(引用終了)

【1】気づき #271: issue編 - Unofficial Redmine Cooking - redmine.tokyo

Feature #1448: Add tags to issues - Redmine

Feature #1176: Recurring Tasks - Redmine

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

【1-1】1番多いのは、Redmineのニュース、ドキュメント、フォーラム、Wikiなどにタグ機能を追加したい要望。
チケット機能でも同様の要望が多い。
ハッシュタグみたいに、Redmineのあらゆる情報をタグ付けできると、検索しやすくなる。

【1-2】2番目はRedmineで定期的なタスクをチケット自動生成したい要望。
たとえば、毎月の報告書作成、ログの定期採取と集計作業、サーバーメンテナンスなど、定期的な作業は手動登録でなく、自動登録できれば、忘れることもない。
日本人だけでなく、世界中の開発者も同様に考えているんだね。

@netazoneさんが、Cron+Shellの実行方法を公開してくれているので参考になる。

QA #273: 定期的作業をチケットで作業管理したい - Unofficial Redmine Cooking - redmine.tokyo

他にも、Redmineのプラグインもあるらしい。
見た目はこちらの方が、一般受けしそう。

やっさんさんのツイート: "@netazone これやでー>Redmine Periodictask plugin https://t.co/pwFiPPayl9 入れるとメニューに「Periodic Task」が追加されて、こんな感じでタスクを追加できるよ。 #redmine https://t.co/zXQm8AyOSG"

jperelli/Redmine-Periodic-Task: A redmine plugin that lets you schedule an issue to fire every x days/weeks/months

【1-3】3番目は、カテゴリのサブプロジェクトへ継承したい要望。
似たようなチケットはたくさんある。
世界中の開発者も、同様に思っているみたい。

Patch #11898: Inheritable issue categories - Redmine

Redmineは親子プロジェクトを気軽に作れるために、カテゴリを逐一登録し直すのが面倒。
親プロジェクトのカテゴリを自動継承できれば、その後、自由に修正するなどできれば、もっと便利になるのに。

【2】気づき #274: customfield編 - Unofficial Redmine Cooking - redmine.tokyo

Feature #685: New Custom Field "Found in Version" - Redmine

Feature #3543: Improve 'long text' custom fields - Redmine

Feature #11361: Custom Field Groups, and User Specific Fields - Redmine

【2-1】1番多い機能は、バージョンとマイルストーンを区別したい要望。
下記チケットと重複しているらしい。

Feature #18560: Show issues with custom field of type Version as related issues in the Roadmap - Redmine

もし実現するとなると、マイルストーンとバージョンを多対1にするなどの関係が必要になるだろう。
僕としては、バージョンとマイルストーンを同一視するというRedmineの運用はアジャイル開発とマッチしているので、実装不要と思う。

【2-2】他には、「長いテキスト」カスタムフィールドを2列化したい、とか、カスタムフィールドをグルーピングしたい、という改善要望。
たとえば、障害チケットはカスタムフィールドが多くなりがちなので、テキストエリアを広くしたり、配置を自由に変えたり、グルーピングして操作しやすいUIにしたい。

カスタムフィールドのレイアウト変更は、ViewCustomizeプラグインで個別で対応可能だが、Redmineの基本機能に盛り込んだ方が確かに使い勝手は上がるだろう。

【3】気づき #275: ui編 - Unofficial Redmine Cooking - redmine.tokyo

Feature #1040: Global wiki - Redmine

Feature #2117: Alternative view for "Projects" page - Redmine

Feature #8417: per tracker configurable issue form layout with preview - Redmine

【3-1】「メインのホームページはグローバルなwikiでなければならないのでは」という改善要望が1番多い。
色んな権限を持つユーザで管理されていたとしても、Redmineを操作する時には、FAQサイトやユーザガイド、手順などをWikiにまとめておき、誰でも参照できるようにしておきたい。
そうすれば、Redmineの運用が楽になる。

小規模チームのRedmineなら、グローバルWikiは不要だが、数百人~数千人が使う場合、Redmineの権限が複雑になり、誰もがアクセスできるプロジェクトは作りにくくなる。
たとえば、社員だけ見れるWiki、パートナー社員も含めたユーザが見れるWikiなどのように、複雑に管理したくなってくる。

【3-2】2番目は、「プロジェクト」ページが使いにくい、という要望。
一般に、Redmineで複数のプロジェクトを作っていくことになり、数百~数千個作る場合もあるだろう。
すると、プロジェクト一覧ページにプロジェクトが大量に並んで表示されるが、非常に見づらい。

プロジェクト一覧ページのUIはもっと改善できる余地がある。
特に、PMOや経営層など、部署ごとに複数プロジェクトを横断して見たい場合、現状のプロジェクト一覧ページでは状況を把握しづらい。

3番目は、カスタムフィールドや基本フィールドの配置を自由に変更したい要望。

【4】気づき #277: カテゴリ未設定分 - Unofficial Redmine Cooking - redmine.tokyo

Feature #2897: Tagging in Redmine - Redmine

Feature #3995: Upgrade to "Files" module - Redmine

Feature #10121: Watchers - Add Group / Role - Redmine

【4-1】1番目に多いのは、タグ付け機能。

【4-2】2番目は、ファイル管理機能の強化。
チケットでは、チケットやWikiに添付されるファイルは、「ファイル」モジュールに表示され、"Related To:"というタイトルの列が追加されて、リンクされるようにする、という要望が届いている。
これは面白い。

Redmineのモジュールの中で、「文書」「ファイル」は最も使われていない機能の一つだろう。
「ファイル」にRedmineへアップロードされた添付ファイルの全リストが表示されるようになれば、添付ファイルを探したり、添付ファイルを管理するなどの操作もやりやすくなるだろう。

「文書」モジュールを拡張したプラグインとしては、DMSFプラグインが昔から知られていた。
RedmineへOffice文書をアップロードして、Redmine上でドキュメント管理ができるようになるプラグインだ。
このプラグインが必要になる状況は、ISO9000の監査やシステム監査などの場面で、Redmineに蓄積されたチケットだけでなく、障害や問合せ、是正対策などの文書もトレーサビリティを確保して、即座に必要な情報を取り出せるようにしたいからだ。

DMSF - Plugins - Redmine

danmunn/redmine_dmsf: Fork of svn repository for redmine_dmsf

Redmine3.2でバージョン管理もできるドキュメント管理プラグイン「DMSF」 | 俺的備忘録 ?なんかいろいろ?

【4-3】3番目は、チケットのウォッチャーをユーザグループや役割などでも選択・検索できるようにしたい要望。
現場でRedmineを使っている人からは、ウォッチャーをもっと強化したい要望は多い。
彼らは、ウォッチャーをメールのCc代わりに使っているみたいだ。
Ver3.xに対応しているプラグインとして、下記があるみたい。

foton/redmine_watcher_groups

※追記:情報が錯綜しているので、まとめた。

QA #290: チケットのウォッチャーをユーザグループや役割などでも選択・検索できるようにしたい - Unofficial Redmine Cooking - redmine.tokyo

【5】以上のように見てみると、タグ付、カテゴリ継承、ファイル管理機能の強化、定期チケット自動作成など、日本人のRedmineユーザが欲しいと思っている機能は、世界中の開発者も同様に思っているように見える。

こういう埋もれたチケットを集計して発見してくれた、@y503Unavailableさんに感謝。

| | コメント (0)

2016/12/28

チケット駆動の罠~複雑さはチケットの粒度に関連している

チケット駆動の罠の記事をメモ。

【参考】
JIRAに死を | TechCrunch Japan

(引用開始)
ここで強調したいのは、悪いのは必ずしもJIRA自身ではない、ということだ。
ここまで書いてきたことはすべて、ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元する、という考え方に由来している。
JIRAの最大の罪は、それが、もっとも成功し広く普及しているチケットシステムであること、それだけだ。
ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。
(引用終了)

tadashi-aikawaさんのツイート: "本文にも書いてあるけど JIRAをディスっているのではなく JIRAの使い方をディスっているだけ。 Confluence使えばおけ JIRAに死を | TechCrunch Japan https://t.co/pNEqwe12Ex via @jptechcrunch"

akipiiさんのツイート: "チケット駆動の罠か。なるほど。RT @arichika: 派手なタイトルの割にちゃんと読めば、チケット駆動が陥りやすいミスが書かれていると思う。プロダクト・サービスの全体像が見えにくくなる、という事。... https://t.co/TB8O1uTEA6"

宮乃ぺこ@木曜東ア34bさんのツイート: "JIRAに関してというより、システム全体をみようねって話 JIRAに死を | TechCrunch Japan https://t.co/Nk3mms8Ryg @jptechcrunchから"

Takeo Hashimotoさんのツイート: "煽りタイトル良くない。そのようにデザインされていない道具をそのようにデザインされていない目的に無理やり当てはめようとしてもうまくいかないのは、ある意味当たり前。原文見たら本当に death って書いてあって呆れた。/ JIRAに死を https://t.co/iEXy4qUFUm"

Mass Kanekoさんのツイート: "「ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。」 少なくともAtlassianはそれを推奨していないのでは。 JIRAに死を | TechCrunch Japan https://t.co/YfCfN4F9GW"

akipiiさんのツイート: "Redmineのチケットも同じ。「デベロッパーが考えるソフトウェアのアーキテクチャが、知らず知らずのうちに、JIRAのチケットにマップしやすい構造になることだ」JIRAに死を | TechCrunch Japan https://t.co/M54P4FBt3f"

akipiiさんのツイート: "「ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元するという考え方」「ソフトウェアプロジェクトをチケットの集合で表すという考え方」JIRAに死を | TechCrunch Japan https://t.co/M54P4FBt3f"

Takafumi Ikedaさんのツイート: "分かるよ。優れた要求仕様はエッセイのようになってるべきだと思う。ジョエルスポルスキーが言うみたいに。でもそうするといつ出来上がるのか予想できないプロジェクトになりやすいけど。経験上。 / “JIRAに死を | TechCrunc…” https://t.co/vzLYSENUZB"

Yamamoto hiroyukiさんのツイート: "ストーリーやタスクは完成しているかしていないかのいずれかと考えるのはアジャイルマネジメントのベストプラクティスだ。著者はそれに異論があるようだ。 | TechCrunch Japan https://t.co/9LjDHX09fI"

【感想】
Redmineのチケット機能はとても優秀だと思う。
理由は、チケット構造をツリー上に展開できるおかげで、WBSやタスクカードなどのような構造をチケットの関連として実現できるからだ。
WBSをチケットに一度登録できれば、ガントチャートであれ、ロードマップであれ、サマリであれ、好きなようにチケット集計のビューで色んな角度で分析できる。

しかし、チケット管理をやりすぎると、思ったほどの効果が出ない場合がある。
@arclampさんが以前、下記の記事を記載されていたのを思い出す。

チケット駆動開発で作業管理はしないほうがいい - arclamp

また、第11回東京Redmine勉強会のアンケート結果でも、「全てチケット化するのは非経済となるシーンもある点です」という声もあった。
たぶん、数多くの人たちが試行錯誤しながら、Redmineのチケット管理の可能性を試している。

個人的には、上記の記事のような指摘から発生する問題の根本には、チケットの粒度があると直感する。
WBSであれ、ソフトウェアやマスタの構造であれ、さほど複雑でなければ、少ないチケットの枚数で表現できる。
チケットの枚数が少ないならば、外部環境からの影響でチケットの構造に変化が発生したとしても、その修正コストはさほど大きくないし、受け入れられる。

しかし、WBSやソフトウェアの構造が複雑になり、チケットの枚数が非常に多くなれば、その構造を実現して、最新の現状と連動させるように同期し続けるのは非常にコストが大きくなる。
チケット保守のコストが大きくなってくるからだ。

ソフトウェア設計では、ソフトウェアの複雑さを複数のレイヤーで分割し、粒度や抽象度を上げることで、その複雑さを軽減しようとする。
チケット管理でも、チケットの親子関係や親子プロジェクト、バージョンなどの機能によって、大量のチケットをレイヤーで分割して、枚数を制限することで、チケット管理の保守コストを受け入れ可能なレベルまで落とす。

つまり、チケット管理が駄目なのではなく、複雑さをどのように手なづけるか、ということが本来の問題なのだと思う。
それは、ソフトウェア工学の古くからの問題であり、あちこちの場面で出てくる。

但し、Redmineのチケット管理では、複雑さを軽減するためのレイヤーとなる機能が限られている。
たとえば、親子チケット、関連チケット、親子プロジェクト、バージョン、カテゴリなどしかない。
それらの機能を増やした方が良いのか、それとも、それらの機能の使い方をもっと工夫すべきなのか。

今の僕の考えは、Redmineの既存の機能を使って、チケット管理の可能性をもっと研究してみたい。
まだまだ色んな可能性を秘めているはずだ、と思う。

| | コメント (0)

2016/12/23

Windows上でJRuby9+Redmine3.3.1を構築した時のメモ

Windows上でJRuby9+Redmine3.3をインストールした時のメモを残す。
自分用の参照。

【環境】
jruby 9.1.6.0 (2.3.1) 2016-11-09 0150a76 Java HotSpot(TM) 64-Bit Server VM 25.10
2-b14 on 1.8.0_102-b14 +jit [mswin32-x86_64]

Windows7+XAMPP

Redmine 3.3.1

【参考】
RedmineInstall - Redmine

Redmine本家の説明では「Redmine does not support JRuby because some gems do not support Rails 4.2」と記載されているので、Own your Riskということで。

【インストール】
C:\xampp\mysql\bin\mysql.exe -uroot -p
create database redmine331 character set utf8;

show databases;

cd redmineのルートディレクトリ

jgem install bundler --no-rdoc --no-ri

jruby -S gem install activerecord-jdbcmysql-adapter
jruby -S gem install activerecord-jdbcpostgresql-adapter

jruby -S bundle install --without test development sqlite3

jruby -S bundle exec rake generate_secret_token

jruby -S rake db:migrate RAILS_ENV=production

jruby -S bundle exec rake redmine:load_default_data REDMINE_LANG=ja RAILS_ENV=production

jruby bin/rails server webrick -e production

adminでログイン

環境は以下の通り。

Environment:
Redmine version 3.3.1.stable
Ruby version 2.3.1-p0 (2016-11-09) [java]
Rails version 4.2.7.1
Environment production
Database adapter MySQL
SCM:
Filesystem
Redmine plugins:
no plugin installed

個人のPCで使う場合は特に問題無さそう。
画面は通常に遷移できる。
但し、ログを見ると、Warningが数多く出ている。

Redmine3.3.1を構築したかったのは、DMSFプラグインを入れて、RedmineでISO9001のような運用が可能かどうか考えてみたかったから。

DMSF - Plugins - Redmine

danmunn/redmine_dmsf: Fork of svn repository for redmine_dmsf

また後で色々書く。

| | コメント (0)

2016/12/06

Unofficial Redmine CookingプロジェクトでRedmineカスタマイズのノウハウを皆で集めてみよう

第11回東京Redmine勉強会で告知した通り、Unofficial Redmine Cookingプロジェクトが始まった。
これは、熱いRedmineユーザによる、Redmineをカスタマイズする非公式プロジェクト。
下記のサイトで見れる。

【参考】
概要 - Unofficial Redmine Cooking - redmine.tokyo

第11回勉強会 - redmine.tokyo

【Unofficial Redmine Cookingの目的】
@akiko_pusuさんの解説が分かりやすい。

Redmineを読み取り専用にしたいけど、どうしよう? - Qiita

(引用開始)
Redmineを運用されている方は、少なからず公式サイトでは載っていないような一部改造・カスタマイズするといった経験はお持ちではないかと思います。そういったノウハウを蓄積して、各自がRedmineをより効率的に活用できることを目指したサイトになります。

この記事は、上記サイトのアドベントカレンダー企画への参加として書かせていただきました。

過去の経験を元にしていますので、今ではもっと便利な方法があったり、クラウド環境だから気にしないという方も多いと思います。
「わたしの環境ではこういう方法を取っていますよ!」というのもあれば、ぜひコメントなどいただけると幸いです!
(札束で解決、というのももちろんOK!)
(引用終了)

【興味深い内容】
いくつかのチケットは興味深い。

【1】QA #252: メンテナンス / 移行 / バージョンアップのためRedmineを読み取り専用にしたい - Unofficial Redmine Cooking - redmine.tokyo

「サーバの移転・移行により新サーバにデータを同期させる間、データの整合性を担保するため、Redmineの参照は許可するけれど、更新は全て止めたい」ような運用をしたい。
Redmineを普通のミッションクリティカルなWebシステムと同様に運用したいわけですね。

Redmineを読み取り専用にしたいけど、どうしよう? - Qiita

【2】QA #246: Redmine 管理-「トラッカー」-「サマリー」の表示枠を固定にしたい。 - Unofficial Redmine Cooking - redmine.tokyo

サマリ画面のトラッカー・標準フィールド・カスタムフィールドの表示(ヘッダ行)を固定するように、Excelのウィンドウ固定機能を実現させたい。
確かに、この機能があれば、Excelライクに扱えるので便利。

Redmine本家には既にパッチがあるらしい。

Patch #20287: Administration: Using grids instead of tables - Redmine

【3】QA #254: ガントチャートの画面上で直接編集したい - Unofficial Redmine Cooking - redmine.tokyo

この要望はすごく多い。
MSProjectに慣れているほど、似たような機能が欲しくなる。

この改善要望は、Ver0.8の頃から、一部ユーザがパッチを提供していたが、今の最新バージョンにパッチはない。
たぶん、RubyよりもJavaScriptのプログラミングがすごく必要。

Feature #2024: gantt chart editing - Redmine

最終的には、有償プラグインを入れるしかないと思う。

【4】QA #247: 複数のRedmineサーバを統合したい - Unofficial Redmine Cooking - redmine.tokyo

社内に野良Redmineがたくさんあって、統合したい機運が高まった時、このノウハウは参考にしたい。
但し、野良Redmineの数が多くなると移行リスクが高くなるので、アジャイルウェアさんに依頼することになるのかな?

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

【5】QA #237: Redmineカスタムフィールド表示改善(CF1列表示、項目見出し、表示調整) - Unofficial Redmine Cooking - redmine.tokyo

QA #231: チェックボックスのカスタムフィールドを2列で表示したい - Unofficial Redmine Cooking - redmine.tokyo

チケットにカスタムフィールドをたくさん追加すると、レイアウトを色々変えたくなってくる。
テキストエリア欄を広くしたり、チェックボックスの配列を変えたり、とか。
ソース修正パッチ以外にも、ViewCustomizeプラグインで対応する方法もあるだろう。

Redmineの画面レイアウトの微修正にこだわる改善要望はViewCustomizeプラグインを使え!: プログラマの思索

【6】QA #241: カテゴリをサブプロジェクトで継承利用したい(バージョン同様) - Unofficial Redmine Cooking - redmine.tokyo

この要望は随分前からあがっていた。
この要望が実現されていないために、カテゴリ機能はほとんど使われない組織も多いのではないか。
そろそろRedmine本体でも実現して欲しい。

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

【7】QA #251: チケットにユーザ情報の値を表示させたい - Unofficial Redmine Cooking - redmine.tokyo

REST API経由でTableauに読み込ませる運用をしているので、Redmine本体のチケットの属性(カスタムフィールド)に作出属性を保持させた方が運用が楽、という意図らしい。
確かに、Redmine本体のカスタムフィールドで作出属性を保持できれば、外部システムで集計する処理が楽になるだろう。

そんな機能を実現するcomputed_custom_fieldプラグインが使えるといいが、上記のコメントを見ると上手く使えないみたい。

Redmineのカスタムフィールドを導出属性にしてしまうプラグインredmine_plugin_computed_custom_field: プログラマの思索

【8】いくつかのチケットには、Redmine本家のコントリビュータである@g_maedaさんのコメントも見られる。
こういう場で蓄積されたアイデアやパッチが、Redmine本家に届けられたらいいなと思う。
もし気に入った機能改善があれば、Redmine本家のチケットに「+1」を追記して、その思いをJPLに届けてほしいと思う。

| | コメント (0)

2016/12/05

Redmine3.1のプラグイン一覧が参考になる

Redmine3.1のプラグイン一覧の記事がとても参考になるのでメモ。

【参考】
Redmineを3年間使い続けてお世話になったプラグインたち - Qiita

【1】Ver3.1.1で、下記のプラグインをインストールしたらしい。
少なくとも、これらプラグインは正常に動作したみたい。

clipboard_image_paste
easy_gantt
progressive_projects_list
redmine_absolute_dates
redmine_agile
redmine_backlogs
redmine_banner
redmine_checklists
redmine_code_review
redmine_default_custom_query
redmine_gantt_with_date
redmine_issue_templates
redmine_issues_summary_graph
redmine_issues_tree
redmine_japanese_help
redmine_maintenance
redmine_pivot_table
redmine_slack
redmine_wiki_extensions
redmine_wiki_lists
redmine_work_time
sidebar_hide

【2】いくつかのプラグインは、Ver3.3ではデフォルト機能に含まれているので、不要になる。
たとえば、redmine_gantt_with_date, redmine_default_custom_query とか。
また、farend_fancyテーマを入れれば、redmine_absolute_dates は不要になる。

【3】幾つか参考になる点がある。

【3-1】まず、redmine_backlogsプラグインは、「feature/redmine3」ブランチであれば、3.xでも動作したらしい。
この情報はありがたい。

(引用開始)
(redmine_backlogsは)
↓↓↓Redmine 3.xの場合は、「feature/redmine3」ブランチのものでないと動かないです。
https://github.com/backlogs/redmine_backlogs/tree/feature/redmine3
(引用終了)

【3-2】有償プラグインを提供しているベンダーの無償プラグインeasy_gantt、redmine_agileの感想も参考になる。
ガントチャート画面上で編集できるだけでもありがたいし、かんばんがRedmine上で使えるのも便利だ。

とはいえ、ガントチャートにMSProject並の操作感や、もっと高機能なかんばんが欲しくなれば、Lycheeなどの有償プラグインが必要になるだろう。

【4】「あとがき&ふりかえり」の文章が、とても心遣いが溢れている。

(引用開始)
プラグインを入れると実現したいことが叶います。
一方で、Redmine管理者の保守工数は増え、利用者には覚えてもらう操作が増えます。
プラグインを入れるだけでなく、プラグインを削除することも時には大事だと思います。
 
誰のためのプラグインなのかを考えることは重要です。
経営層やマネジメント層の声の力は強いかもしれませんが、週1や月1でしか使われないような目的のためよりも、毎日Redmineを使っている現場の人の声を大事にしたほうがいろいろと幸せになれます。
 
何のためのプラグインなのか、何のためのRedmineなのかを忘れてはいけません。
Redmineを使い始める以前のやり方を堅持するために、さまざまなプラグインを駆使するのはオススメしません。
可能ならば、人や業務にシステムを合わせるよりも、システムに人や業務を合わせることをオススメします。
(引用終了)

Redmineのようなツールに触れると、それにのめり込んでしまう。

たとえば、様々な人達の要望を取り入れて、プラグインを入れて、どんどん高機能化したくなる。
あるいは、組織やチームのワークフローを己の考えに従わせたくなる。
自分の理想のプロセスを実現すべく、Redmineをどんどんカスタマイズしたくなる。
Redmineのシステム管理者の保守工数もバカにならなくなる。

そんな時に、ふと足元を振り返って、Redmineの目的を思い出すのも大切なのだろう。

| | コメント (0)

2016/11/30

「入門Redmine第5版」が出版されました

「入門Redmine第5版」を@g_maedaさんから頂いたので、感想をメモ。

【参考】
「入門Redmine第4版」が出版されました: プログラマの思索

入門Redmine 第2版: プログラマの思索

入門Redmine 第5版|書籍情報|秀和システム

【1】数あるRedmine本の中で、Redmineのバージョンに追随して最新化されている本は「入門Redmine」くらいだろう。
最新版を購入しておけば、逆引きリファレンスとして使えるのが便利。
チームや会社に1冊あれば、引き継ぎや説明会で使えるだろう。

【2】「入門Redmine第5版」で興味深い点は、いくつかある。

【2-1】Redmine利用事例のトップに、JAXAの事例「スーパーコンピュータ「JSS2」の運用チームを支えるRedmine(JAXA)」がある点だろう。

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

JAXAスーパーコンピュータ活用課における業務で、実際に新規登録中のチケットの画面キャプチャがあるのが非常に面白い。
ISO9001監査にも使えるように、カスタムフィールドを準備したり、説明欄に記入すべき事項を記載したりしている。

また、藤田課長が「もっと楽に管理できるツールはないか」という質問を投げた時に、木元研究員がRedmineエバンジェリストとして振る舞った場面も興味深い。
社内にRedmineエバンジェリストがいたおかげで、即座に利用環境が整い、初期設定や利用者への説明なども上手く進んだらしい。

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

そんな内容を読むと、まさに先日の東京Redmine勉強会の講演と同様に、社内のRedmineエバンジェリストという存在がすごく大きかったのだろうと思う。
そして、そういう役割の人達がごく稀ではなく、多少だろうが生まれてきつつあるように思える。

チケット管理はRedmineでなくても、JiraでもTracでも同様に扱える運用ノウハウだから、そういう人達が増える背景なのかもしれない。

【2-2】もう一つは、Redmineの機能をレイヤ構造で表現していることだろう。
分かってみれば当たり前の構造だろうが、利用者観点で機能が上手く分割されている。

JAXAのRedmineモデル~Redmineはレイヤ構造になっている: プログラマの思索

また、Redmineエバンジェリストの木元さんいわく、Redmineの機能のうち「文書」「ファイル」はあまり力を入れていないように思えるため、使いにくい。
そこで、DMSFプラグインを導入して、文書管理の機能拡張を行った。
そのおかげで、運用がかなり楽になった、と。

DMSFプラグインはごく一部のユーザは熱烈に使っているが、Redmineのバージョンアップに追随できるか、検討が必要かな。

そういう話を読むと、Redmineの機能と運用を非常に研究しているように思える。
今後も、どんどんこういうノウハウが情報共有されていければいいなと思う。

| | コメント (0)

2016/11/27

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT

第11回東京Redmine勉強会が無事終了しました。
60名以上の参加者、10人の講演者、10人のスタッフの皆さん、お疲れ様でした。
感想をラフなメモ書き。

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

第11回勉強会 - redmine.tokyo ~「Redmineの多用性とその進化」(2016/11/26) - Togetterまとめ

第11回東京Redmine勉強会の見所: プログラマの思索

【1】今回の勉強会では、LTを含めて10人の講演があって盛り沢山でした。
Redmineの運用事例や技術事例がこれだけたくさんあること、参加者も多いことを考えると、Redmineのマーケットはかなり広がっているのだろう。

グループディスカッションで参加者の属性を聞いてみると、Rubyエンジニアは少なく、情報システム部門でRedmineのシステム管理者、Redmineのインフラ運用担当者、自社内の部署にRedmineの運用を啓蒙活動している人達が多いように感じた。
他に、Redmineプラグイン作者、Redmine本を出版した経験のある人、Redmineのサービスやカスタマイズを行なっているベンダーの方もいるので、多用な属性を持つ人達がいるおかげで、場がとても盛りがったと思う。

もちろん、これから社内にRedmineの利用普及を考えている参加者もいたので、今回のテーマ「Redmineの多用性とその進化」は参考になったのではないだろうか?

kazuphさんのツイート: "Redmine Plugin開発者と本体のチケットをいじれる人、本を出版した人がいる会場。ものすごくRedmine偏差値高い。 #redmineT"

kuniさんのツイート: "redmine勉強会行って来ました。自分はこれから社内で広めていく立場なので、色んなシステムを構築している人達がいて励みになりました。次も参加したいです(*^^*)"

【2】@kazuphさんのIOT企業におけるRedmine運用事例で面白いと思った点は二つ。

【2-1】一つは、ソフト屋とハード屋では、チケット管理の観点や粒度が異なること。

ソフト屋のチケットの粒度はせいぜい数時間単位のものが多く、小さい。
だから、チケットもすぐにCloseされて、毎日の進捗もすぐに見えやすく、はかどっている感じが分かりやすい。

したがって、カンバンLikeなチケット管理の運用の方が回りやすい。
だから、Agileプラグインのように、カンバンボードのようなRedmineプラグインが重宝される。

一方、ハード屋はガントチャートが大好き。
ガントチャートでスケジュール管理を見たい。
その動機にも理由はある。

なぜなら、仕入→設計→製造→品質チェック→出荷の生産プロセスでは、どうしても各工程で作業待ちのリードタイムが発生しがちなので、チケットの粒度は大きくなりやすい。
たとえば、部品や原材料を発注して入荷するまでに、数日間のリードタイムが発生するので、設計や生産プロセスのチケットはすぐに着手できず、チケットの粒度は数日~数週間のレベルになりやすい。

したがって、ガントチャートで見る方が、作業予定やクリティカルパスを把握しやすい。
むしろ、かんばんで作業を管理すると、毎日のチケットの動きが少なく見えるために、経営者から見ると、作業が遅れているように見えて問題になるらしい。
つまり、リードタイムの長いチケットが滞留してしまって、目立ってしまうらしい。

すなわち、ソフト屋はアジャイル開発、ハード屋はWF型開発にどうしてもなりやすい。
特に、ハードウェアの作業は、特殊部品の納入がなければ生産できないとか、高価な機械が1台しかないので生産の稼働率が限定されてしまう、などの問題がどうしても出てくる。
すなわち、各工程の作業でリードタイムという作業待ち時間がどうしても発生する。
したがって、ハード屋のチケット管理では、事前にチケットで先行・後続関係を設計して、各工程のリードタイムが長くならないように、ボトルネックが発生しないように、生産計画の精度を高める必要が出てくる。

その観点が、チケットの粒度やガントチャート重視につながってくるわけだ。
そう考えると、チケット管理にTOCの発想を取り入れて、ボトルネックの稼働率を高めるようにチケット管理できないか、とか、CCPMのプラグインがあれば、とか思ったりする。

【2-2】もう一つは、社内にRedmineに相当詳しい人がいたおかげで、Redmineの運用がスムーズに進められたこと。
社内のRedmineエバンジェリストである彼がすぐにAWSにサーバーを立ち上げて、すぐにRedmineのワークフローなどを初期設定してくれて、すぐに運用可能な状態になった。
そして、Redmineエバンジェリストが勝手に動いて、Redmineのベストプラクティスはこうなんです!と強く主張して、社内のサポート部隊や事務員に説明会を開催して、Redmineの啓蒙活動をしてくれたらしい。

お話を聞くと、中途入社されたSEがRedmineに相当詳しかったそうで、Redmineの立ち上げ、設定、運用、プロセス標準化、ベストプラクティスのノウハウを既に持っていたらしい。
だから、Redmineの使い勝手に関する改善要望もそのエバンジェリストが受け付けて対応してくれたらしく、Redmineの利用度も上がっていったらしい。
以前はSlackに課題が上がっていて、Slackの内容をチケットに転記していたが、現在は、Redmineのチケットに直接記入する運用に自然に定着したらしい。

その話を聞くと、Redmineの啓蒙活動を行うRedmineエバンジェリストが社内に必要なのだ、と思う。
そういう人がいるので、サポートデスクの作業管理や課題管理などで困っている、という話があっても、すぐにRedmineを立ち上げてくれて、その日のうちから運用を開始できる手軽さがある。
しかも、チケット駆動のベストプラクティスはこれだ!というノウハウもネット上に溢れているので、自分なりに運用手順をWikiにまとめておけば、すぐに社内メンバに説明会を開いて普及を促進することもできる。

IT技術者なら問題無いだろうが、工場の作業員やサポートデスク、事務員の人はチケット管理にそんなに慣れていないだろうから、そういう説明会などのフォローは重要だ。
この辺りはいわゆるERP導入時に、ユーザ説明会によるフォロー作業と同じ。

【3】@mattaniさんの講演は、Redmineを簡易CRMとして使う話も面白い。
Redmineをカード型データベースとみなし、チケットをサーバー情報や問合せ情報のマスタとみなす。
つまり、チケットでマスタ管理している。

また、「チケット in チケット」というアイデアで、チケットの説明欄にWikiListプラグインを用いて、特定のチケット集計をサマリ表示させることで、カード型DBとして使っている。
さらに、ViewCustomizeプラグインを使って、カスタムフィールドを説明欄の下部に配置したり、プロジェクトメニューでプロジェクトを選択したタイミングでチケット一覧に遷移するように工夫している。

あくまでもCRMの簡易版の利用事例だが、ViewCustomizeプラグインを駆使したり、運用ルールを工夫すれば、CRMの代替機能としてRedmineを使うこともできるだろう。

【4】アジャイルウェアの堂端さんの講演では、20数個の野良Redmineを1個のRedmineに統合した事例。
プロジェクトは1400件以上、履歴は100万件以上、ワークフローの遷移が6万以上という野良Redmineをデータ移行して、一つのRedmineに統合できたとは恐れ入る。
しかも、統合作業をプラグイン化したらしい。

あきこさんのツイート: "お客様の現場を舞台にした複数Redmineの統合のお話。20台以上乱立してて管理者も別。プロジェクト単位でRedmineインスタンスが立ち上がっている。でも実際は1台の物理サーバに乗っかっている!Oh! #redmineT"

松谷 秀久さんのツイート: "20台のRedmineサーバを統合するのはけっこう骨が折れそう/心も折れそう #redmineT"

あきこさんのツイート: "2ヶ月くらいかけ休日を中心に調整。最大のものは48時間くらいで統合できた。統合後のRedmineの規模がものすごいことに!プロジェクトは1400件以上、履歴は100万件以上。ワークフローの遷移が6万以上。。。でも、一元管理することで見えてきたものがある。#redmineT"

野良Redmineをデータ移行して統合するポイントはいくつかあるらしい。
話を聞くと、SQLiteの中間DB上で、それぞれの野良RedmineのチケットIDを変換して、統合Redmineへデータ移行するように設計したらしい。
確かに、ERPのマスタ移行でも、中間テーブルでユーザCDや商品CDを変換するバッチプログラムをよく作ったりする。

あきこさんのツイート: "統合の苦労話スタート!課題1: IssueIDがDBの自動採番に基づくため番号が重複する。課題2: トラッカーが色々。賢いエンジニアさんが統合用のツールを作った!!(すばらしいー)IssueIDが記載されているあらゆるテーブル、フィールドを検索して書き換え。#redminet"

但し、Redmineでは特有の課題がいくつかある。
たとえば、チケットIDがWikiやコミットログなどに散在しているので、それらも一括置換する必要がある。
たとえば、添付ファイルは別ディレクトリに保存されているので、それらも考慮する必要がある。
たとえば、Wikiの記法がTextileやMarkdownなどで混じっていた場合はどうするのか?
たとえば、Redmineプラグインが多数使われていた場合は、大丈夫なのか?

やっさんさんのツイート: "tail -f pinzo.log: RedmineでMarkdownに切り替えやすくするプラグインを作った これで任意にMarkdownとTextile切り替える出来ますよ #redmineT https://t.co/t4fJGRTbR0"

話を聞くと、野良Redmineは、最初に作られたRedmineをベースに各部署で作られたのでどれもバージョンが同じだったので、マシだった、とのこと。
また、野良Redmineを統合するRedmineプラグインとして作成したが、Redmineのバージョンに依存するので、他のバージョンで使うにはカスタマイズが必要であるらしい。

おそらく、統合プラグインは、データ移行処理をrakeによるバッチ処理で実装しておき、プラグイン設定画面で初期設定して、移行作業をキックする仕組みではないかと想像する。
実際、MantisやTracからRedmineへ移行するrakeタスクがRedmineにあるので、それを参考にして流用できるはずだ。

RedmineMigrate - Redmine

また、RedmineRake - Redmineには、添付ファイルを移行するrakeタスクもある。

野良Redmineをデータ移行できる統合プラグインは、有償プラグインであってもニーズはすごくあるだろう。
アジャイルウェアで販売しないのかな?

【5】Redmineのバージョンアップに関して、@g_maedaさんと@netazoneさんの事例があった。
やはりRedmineプラグインを入れていると、Redmine本体のバージョンアップに追随できなくなるらしい。

あきこさんのツイート: "プラグイン大量死の歴史!!!1.3系でルーティング変更、1.4系でbundler, 2系でRails...., jQueryへの変更.... #redmineT"

マサユキ@C91 2日目(金)東ア25bさんのツイート: "2011年、2012年を乗り越えたて現存するプラグインは歴戦の勇士ということか。redmine公式にあるプラグイン紹介で登録日が4年前とか #redmineT"

過去の歴史を振り返ると、Railsのバージョンアップ、Prototipe.jsからJQueryへの変更など、プラグインが大量死するタイミングが4回以上もあった。
最近は、RedmineでScrumを運用できるBacklogsプラグインがついに放置された。

個人的には、プラグインを使う時は、Redmine勉強会に参加しているプラグイン作者のプラグインに限定するようにできるだけしている笑。

1点気になったのは、@netazoneさんの事例で、@akahane92さんのチューニング手順を元に、@clearcodeさんの全文検索プラグインを入れた所、全文検索がかなり高速化されたらしい。
Redmineに残された弱点の一つが、検索ボックスからの全文検索が遅い点なので、ますます@clearcodeさんの全文検索プラグインは使いたくなってくる。

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

【6】@akiko_pusuさんのRedmineプラグインのテスト方法の事例も興味深かった。
testunitでRedmineプラグインのテストを自動化した動機は、OSSと言えども問合せが多いので、それを削減したい。
たとえば、プラグインのインストールで詰まった、とか、バージョン依存で動かない、とか。
プラグインと言えども、テストの自動化は、ソフトウェアの品質を高めるのに役立った、と。

@akiko_pusuさんの事例で参考になった点は、OSSのアプリであれば、フリーで使える開発基盤のWebサービスがたくさんあることだ。
CIツールwerkerや静的コード解析SideCIなど、色々あるらしい。
そういうのを聞くと、趣味で開発するOSSツールは、これらフリーの開発基盤を使いまくる方が、作業も効率化できるし、品質も向上できるメリットがある。

【7】グループディスカッションや懇親会で参加者と話をすると、自社でRedmineを普及させる役職の人たちが多く、既にその活動を行なっていて、数多くのノウハウを蓄積しているように見受けられた。
つまり、彼らはRedmineエバンジェリストとして、社内でRedmineを利用しやすくしたり、プロセスの標準化や作業の効率化、プロジェクトの見える化を実現するように活動しているみたい。
たとえば、自社の各地方にある事業所へRedmine説明会を毎回開催するとか、各部署にRedmine説明会を開いている、みたいな話が出ていた。

その活動を通しているうちに、Redmine特有の癖、いろんな業務におけるチケット管理のノウハウなどの知見がたまり、その内容を経験事例として発表されている人達もいる。
そういう話を聞くと、Redmineが日本のSIの現場で普及するにつれて、日本各地でRedmineエバンジェリストが出現しているように見受けられる。

そういうRedmineエバンジェリストが社内にいると、Redmineの立ち上げや社内説明会のコストが低いので、非常に運用しやすくなるだろう。
また、チケット管理はRedmineでなくても、JiraやTrelloにもノウハウを流用できるだろうから、チケット駆動開発という概念をより普及しやすくできるだろう。

個人的には、各地でRedmineエバンジェリストがバラバラに活動してノウハウが閉じこもっている状況を打破して、勉強会のようなオープンなコミュニティで、それらノウハウを情報共有できるようにしたい。
そうすれば、今からRedmineを使う初心者も参考になるし、既に運用中の経験者にも参考にできる情報を提供できるだろう。
つまり、現場の業務改善のツールの一つとしてRedmineがあるので、Redmineの運用で蓄積された皆のノウハウをベストプラクティスとしてまとめてみたいのだ。

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。皆様ありがとうございました。改めてRedmine は多分日本人好みのツールなのだろうと感じた。自分達の現場で業務改善したい時に手元にフリーでそれなりに使えるツールがあって、現場に部分最適するのは日本人の得意技。"

【今日の資料はコチラ】

| | コメント (2)

より以前の記事一覧