Redmineで日本語ファイル名の画像がPDF内で正常表示されるようになった

ver3.3.2のRedmineで日本語ファイル名の画像がPDF内で正常表示されるようになったのでメモ。
@naitohさん、ありがとうございました。

【参考】
Defect #22335: Images with non-ASCII file names are not shown in PDF - Redmine

akipiiさんのツイート: "Redmine3.3.2 で、PDF出力時に、日本語ファイル名の画像ファイルが埋め込まれない 。画像ファイル名がURLエンコードされた文字列がPDF出力される 。画像ファイル名が英数字ならば、PDFに画像が埋め込まれるのでOK。"

akipiiさんのツイート: "Redmine 利用の日本人にはありがたいです。RT @g_maeda: @naitoh @akahane92 Defect #24271 の件とともに修正ありがとうございます! PDF内で画像が正常に表示されることを確認しました。 喜ばれる方が多いのではないかと思います。"

akipiiさんのツイート: "ありがとうございます！@naitoh: @akahane92 @g_maeda Redmine 3.x で、日本語ファイル名の添付画像がpdf出力されない件、対応が遅くなり申し訳ありません。先程リリースした rbpdf 1.19.1にて修正しましたので、ご確認頂ければと思います。"

Kuniharu AKAHANEさんのツイート: "@naitoh @g_maeda 内藤さん、対応してくださったのですね。本当ありがとうございます。確認しますね。/ A good news for #Redmine CJK users! Thx a lot @naitoh san! https://t.co/HK2o7DnQwT"

Kuniharu AKAHANEさんのツイート: "@naitoh @g_maeda 当方の全環境にて、問題の解消を確認できました。とても助かります。ありがとうございました！/ Images with non-ASCII file names are not shown in PDF https://t.co/zITGox6odB"

Redmine 2.6のCHANGELOGのメモ: プログラマの思索

10年前のRedmineでは、PDF出力した時、日本語が文字化けする問題があったが、今はもう無い。
しかし、ついきさっきまで、Wikiに日本語ファイル名で画像ファイルをアップした後でPDF出力すると、PDF内に日本語ファイル名がURLエンコードされて表示されてしまい、画像が埋め込まれないバグがあった。

@naitohさんが、PDF出力Gemを更新してくれて解決した。
「bundle update」を実行すればOK。

(引用開始)
bundle update results:

Using rbpdf-font 1.19.1 (was 1.19.0)
Using rbpdf 1.19.1 (was 1.19.0)
(引用終了)

RedmineのPDF出力機能が活躍する場面は、Wikiに記載したマニュアルをPDFで出力したい時だろう。
たとえば、Redmineの運用マニュアル、業務システム開発PJの技術情報や用語集などは、Wikiに書いている場合が多い。

Wikiに書いておけば、メールにリンクさえ貼れば誰でも見れる。
Excelドキュメントに運用マニュアルや技術情報を書いても、すぐに内容が古くなるし、Excelファイルはすぐに散在してしまうから。

運用マニュアルや技術情報のように、版管理しなくてよいドキュメントは、Wikiにピッタリだ。
最新版のマニュアルさえ取得できればいいから。

Wikiに編集履歴が残るので、最新版さえ保守すればいいから。

マニュアル納品の時は、PDFで納品すればいい。
しかも、RedmineからWiki全てを一括PDF出力できるし、しおり機能も付いてくるので便利。

Redmine 1.4新機能紹介: Wikiの全ページを一括してPDFに出力 | Redmine.JP Blog

しかし、PDFではなく、Wikiの内容をOffice文書で出したい時もある。
Redmine本家には既に、ODT形式で出力するパッチがアップされている。

2016年5月のRedmine開発状況 | Redmine.JP Blog（WikiページをODT形式でエクスポート）

Feature #22923: Export Wiki to ODT - Redmine

WikiからOffice文書が出せるのはすごくいい。
ユーザマニュアルを納品した時に、ユーザが自分で加工できるから。
後はご自由に、みたいな感じで。

この機能も早くリリースできるようになればいいと思う。

【追記】
Windows上で、Ruby1.9、Ruby2.0では、rbpdf 1.19.1でエンコーディングエラーが発生する、として、JPLがチケットをRejectした。
それを受けて、まるやまさんが、Ver3.4で、Ruby1.9、Ruby2.0は廃止することを提案している。
実際、Ruby2.0以前は既に保守されていないからだ。
但し、RedmineがRuby2.0以前は対応しない、という意思決定がなされると、利用ユーザに大きな影響を与えるだろうと思う。

Defect #24271: htmlentities warning - Redmine

Feature #25538: Drop support Ruby 1.9.3 and 2.0 - Redmine

なお、その後、@naitohさんがRbpdfの修正バージョンをリリースしたので、Redmine本家に取り込まれた。

リビジョン 16520 - Use rbpdf 1.19.2 (#22335, #24271). - Redmine

JPLがこのように、細部までテストしてバグ出ししていること、それを受けて、レガシーなRubyを廃止することを検討していること、それらの動きをWeb上で全世界で参照できることにすごく敬服している。
Redmineの進化の方向性は、間違っていないように思う。

【追記】
RubyのPDFライブラリRbpdfに関して、@naitohさんの移植作業は下記で公開されている。

Rbpdf gem library from Jun Naitoh

第54回関西IT勉強会の感想

第54回関西IT勉強会で、渡辺さんの生産管理データモデルを超高速開発ツールで実装してデモを見せてくれて、面白かった。
以下はラフな感想。
間違っていたら後で直す。

【参考】
データモデルを通して業務を理解しよう ＜第54回IT勉強宴会＞ | ＩＴ勉強宴会blog

データモデルを通して業務を理解しよう - connpass

【1】渡辺さんの生産管理データモデルは既に公開されている。
書籍では何度も読んでいるけれど、実際に動いた画面は見てないので、ピンときていない部分もあった。
今回、超高速開発ツールで実装してデモを見て、渡辺さんの生産管理データモデルはすごい！と改めて気づいた。
（レベルが低くてスミマセン）

【2】渡辺さんの生産管理データモデルで興味深い点はいくつかある。

【2-1】受注生産と言いながら、汎用部品の見込生産にも対応している

受注生産のシステムなので、製造するときには必ず受注番号が既にある。
受注番号から製造指図書が生成され、それに従って、原材料の発注、設備の作業時間の予約、作業員のスケジュール予約が自動設定される。
つまり、MRPの所要量計算が自動計算されて、必要なリソースが予定として計画される。
そして、次の業務へ移る。

だが、渡辺さんの生産管理データモデルでは、「特殊売上」「特殊仕入」という特殊な業務がある。
これは、汎用部品の売上処理や仕入処理を意味する。
なぜこういう機能が必要なのか、を推測すると、受注番号なしで製造指図書を発行したい、という例外的な業務があるからだろう。
そういう例外的な業務をシステム化しないケースもありうるが、その場合は、例外的な業務は従来の紙による運用になってしまい、生産データや売上データを別で入力する必要が出てしまう。
だから、このような例外的な業務に対応する機能も実装しておくと便利。

その場合、その例外的な業務に対応する機能は、ほとんど全ての例外業務を飲み込んでしまう。
たとえば、本来は、何らかの理由で追加生産する時に使う機能だったのに、汎用部品を事前に見込生産する、とか、サポート保守用の部品を事前に生産して準備する、とか、ありとあらゆる例外業務に対応できてしまう。
つまり、例外的な業務に対応する一機能にすぎないのに、実際は、受注生産以外の全ての生産業務に対応できるような仕組みを故意に作っておけば、中小企業のある程度の生産業務に対応できる、という背景があるのだろう。

そういう意図を読み取りながら、デモ画面を見ると、さほど複雑ではないシンプルな生産システムにも関わらず、このデータモデルを流用すれば、ある程度のシステムを構築できてしまうわけだ。
たぶん、渡辺さんの過去の経験から、こういうデータモデルがないと、現場の業務は回らない、という確信があるのだろう。

【2-2】製造指図書、発注明細などのFatなテーブルの項目には意味がある

公開されたER図をサラッと見ると、業務の中心にFatなテーブルがあり、その周囲に惑星のような小さなテーブルが配置されている。
まるで、太陽系のようなデータモデル。

T字形ERの人達から見れば、正規化しきれていないテーブル構造だと思えてしまうかもしれない。
だが、実際にデモを見ると、Fatなテーブルの項目は、それぞれの業務の画面項目に対応しており、データの生成→更新→終了に至るまでの経緯を保持するデータに対応する。
つまり、導出項目だったり、数量だったり、連番だったりする。

渡辺さんの生産管理データモデルで最も特徴的な在庫推移機能の画面では、業務が変わるたびに、在庫数量がその都度更新され、リフレッシュされる。
実際は、親画面からポップアップされた子画面で、ステータスや数量を更新すると、親画面の在庫数量がリフレッシュされる。

下記の質問はそんなデモを見た時に出た。

(引用開始)
・先ほどから画面を閉じるとひとつ前の画面がリフレッシュしてるように見えます
　最近追加した機能です。画面フォーカスが戻った時に自動リフレッシュ出来ます
　またルールエンジンも組込みましたので簡単な業務ならノンプログラミングになりました。
(引用終了)

在庫推移画面は実際に見たことがなかったので、そんな動きになるのか、とようやくイメージできた。
（レベルが低くてスミマセン）

つまり、Fatなテーブルは、各業務に必要な導出項目や更新する項目を保持するために必要であり、データ保守やデータ移行の手間を考えると、あえて、正規化しすぎないようにしているわけだ。
その分、カスタマイズもしやすいだろう。

【2-3】製造指示工程明細---●製造指示材料明細

製造指図書テーブルから、製造指示工程明細と製造指示材料明細の2つのテーブルが外部キーとして外部参照関係を持つ。
さらに、工程と品目明細のテーブル間で、「製造指示工程明細---●製造指示材料明細」という外部参照関係がある。

この意味は、原材料を「工程の始点から投入」だけでなく、「工程の途中から投入」できるようにするために、そのような関係を持たせている、らしい。
なるほど！

普通は、原材料は「工程の始点から投入」のパターンだが、工程の途中から投入する生産工程もあったりする。
そのような例外的な業務に対応できるように、故意に制約を緩めて汎用化しているわけだ。

工業簿記の総合原価計算では、「工程の始点から投入」のケースと「工程の途中から投入」のケースでは、加工進捗の計算方法が変わるため、加工費の算出が変わってくる。
つまり、この部分に対応することで、多様な原価計算パターンにも対応できるようにデータモデルを設計されているわけだ。

【2-4】発注明細●----入荷見出し

(引用開始)
発注の部分のＥＲがすごく良くできています。
発注見出　－＜　発注明細を作ります。
仕入が入ってくると発注明細ごとに仕入番号を更新することで入荷された単位で仕入れを発生させることが出来ます。
(引用終了)

僕の理解では、発注明細が複数個発生すると、そのたびに入荷処理するわけではなく、一括で処理したい。
そこで、一括処理する単位で、発注明細を束ねて、入荷処理する。
つまり、発注明細に、仕入番号という外部キーを挿入して、仕入番号の単位で入荷処理を行うように記録させる。
なるほど！

T字形ERでも、2個のトランザクションに先行・後続の関係を持たせる時、外部キーを持たせる。
また、T字形ERでは、先行のトランザクションを一括処理でまとめて、後続のトランザクションに渡す時は、親子キーの関係を持たせるが、渡辺式データモデルでは、実運用を考えて、外部キーで持たせている。
つまり、発注明細テーブルの仕入番号は最初はNULLであり、仕入という入荷処理を行うと、仕入番号が発行されてセットされる。

懇親会で実装した人に聞いたら、この部分のデータモデルはシンプルで汎用性が高いので、いろんな業務にカスタマイズしやすい。
よく考えられている、という話だった。

【2-5】ストアドプロシージャは、サーバーサイド・JavaScriptで実装する

今時、ストアドプロシージャをプログラミングするのは古いらしい。
サーバーサイド・JavaScriptで実装するが流行らしい。
確かに、サーバーサイド・JavaScriptで実装しておけば、どんなWebシステムでもクライアントアプリでも、公開されたAPI経由で自由に計算処理できる。

性能要件が気になるけれど、そこさえクリアできれば、保守性を考えると、サーバーサイド・JavaScriptで実装した方が良いのだろう。

【3】@sakaba37さんから、渡辺さんのデータモデルのようなモデリング手法に違和感がある、と聞いた。
あれは、論理モデルではない、物理モデルだから。
本来のモデリングではないのでは、と。
たとえば、オブジェクト指向モデリングならば、モデルは論理モデルを指すのであり、物理モデルはいろんな種類があるから、と。

たしかに、モデリングと言うよりも、実際に実装したシステムまで作ってしまった、みたいな感じだ。

この手の話は、以前、議論したことがあった。

ドメイン駆動設計に出てくる「モデル」とは何ですか？～第28回関西IT勉強宴会の感想: プログラマの思索

つまり、普通のモデリングで言われるモデルは「論理モデル」であり、論理モデルだからこそ、実装方法は色々ある。

一方、勉強会の途中で、渡辺さんの質問「業務に対するモデルの正しさはどのように判定していますか？」があがり、皆であれこれ議論して、結局、場面ごとに違うので、正しいモデルは一つとは限らないね、という話になった。
そして、渡辺さんいわく、モデリングはエンジニアリング技法の一つなので、品質やコスト、納期のトレードオフでモデルが決まるから、と言っていた。
その意図は、「モデルの判定は理想論ではなく、QCDやその時代の技術レベルの選択のすり合わせで決まるので、相対的なものである」という意味なのだろうと思う。

以前、@yusuke_arclampさんも似たようなことを言っていた。

akipiiさんのツイート: "アーキテクトは理想論を語る科学者ではなく、コストなど現実的な折り合いを付ける技術者であるわけか。RT @yusuke_arclamp: アーキテクトというのは「個別の技術論」ではなく「技術選択論（要件と技術のすり合わせ）」を語れないといかんのだけどね。"

でも、@sakaba37さんと同じく、何かすっきりしない気持ちもある。
上記の議論は、モデルのレベルを「実装モデル」に落としているために、技術選択論になっているのではないか、と。
この辺りは妄想なので、あとでまとめる。

第16回Redmine大阪の感想 #RedmineOsaka

第16回Redmine大阪が盛況で終わりました。
講演者、参加者、スタッフの皆さん、ありがとうございました。
以下は感想をラフなメモ書き。
力尽きたので書きかけ。

【参考】
Redmine大阪 第16回勉強会 - connpass

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪: プログラマの思索

【1】参加者は約70人近く。
関西以外に、東京、名古屋、福岡、岡山など遠方から参加された人も多かった。
LTの5人のうち4人は、関西以外のエリアの人達。
それだけRedmineが注目されているのだろうか。

(引用開始)
東京から参加しました。機械メーカーの調達マネージャーでITには詳しくないため、ついて行けない場面も多々ありましたが、雰囲気も良く時間が短く感じられました。
東京でも参加したいと思います。おせわになりました。
(引用終了)

発表内容も、組込みソフトウェア開発プロセスや運用面から3.4の新機能、アンチパターンまで幅広く、色々議論できたと思う。

【2】「高信頼性ソフトウェア開発へのチケット駆動開発の適用事例」　宿口雅弘さん

組込みソフトウェア開発プロセスの機能安全という特性にRedmineを導入した事例のお話。
実際は、Redmineベースのパッケージ製品eWeaverをベースに、開発プロセスを構築したみたい。
但し、コミュニティ講演なので、製品紹介よりも、機能安全をベースにしたプロセスのお話がメイン。

Redmineベースの組込みソフト開発向けプロセス支援ツールeWeaverのリンク: プログラマの思索

イーソルトリニティ株式会社 eWeaver

昨今、IOT、インダストリー4.0、自動運転、人工知能のように、メーカーを巡る動きは激しい。
その中で、ソフトウェア品質特性の中で特に、機能安全をどのように保証するか？
もちろん、そのプロセス実装は、Excel帳票や人手でやるのは、大規模開発になるほど非常に難しくなる。

機能安全をプロセスで保証するメリットは、PL法への対処にもなる、という指摘は参考になる。
製品出荷後のクレームによる損害は、今の時代は非常に大きくなっていて、リスクも大きい。
だから、プロセスで十分に保証されているけれど、その損害は予知できないものだ、と主張できれば、損害賠償責任を免れるわけだ。

お話はソフトウェア工学がメインテーマなので面白いけれど、Redmineウォッチャーの観点では、そのプロセスをRedmineの機能にどのようにマッピングして、どのように運用したのか、という点が非常に気になる。
肝心のお話はサラリと流されてしまったので、ちょっと肩透かしかも笑

質疑応答で聞いてみると、プロセスの保証は、チケット駆動のトレーサビリティという性質を使う。
つまり、機能要件やセキュリティ要件などの要件は親チケットとし、そこから派生したタスクは子チケットへブレイクダウンする。
成果物はSVNの配下に置き、必ずチケットにSVNリビジョンとして変更履歴が残る。
話を聞くと、Officeファイルも全てSVNで構成管理する、とのこと。
確かに、この運用なら、トレーサビリティは確保できるだろう。

チケット駆動の弱点は、時系列の表現が弱い点だ、という指摘は、そういう見方もあるのか、と参考になった。
だから、eWeaverでは、タスク管理のビューとして、かんばんを採用しているわけだ。

面白いと思った点は、Wordの要件定義書にある各要件の番号から、Redmineのチケットを新規登録したり、リンクを張れること。
つまり、Redmineチケットに散らばった要件やタスクは、Wordの要件定義書に基づいて作成されて更新される。
すなわち、要件定義書がしっかり保守されていれば、Redmineと相互連携もできるし、Redmineのチケット一覧をわざわざ見なくてもいい。

【3】「乱立してるRedmineを一つにまとめる話」　堂端 翔さん

東京Redmine勉強会の再演。
今後、さらに大きいRedmine移行作業を控えている、とのこと。

乱立してるRedmineを一つにまとめる話 · GitHub

【4】 @pinzoloさん、@g_maedaさんの「Redmine 3.4.0にアップグレードしよう!　お気に入り改善点一挙紹介」

@pinzoloさんの資料の「おまけ」の部分が面白い。
レスポンシブテーマに対応したことが、逆に、プラグイン作者やテーマ作者は大変になった。

Ver3から、10年以上前のチケットの実装など、古いチケットが対応されてきた。
@g_maedaさんによれば、積極的に、新しいパッチはどんどん最新のターゲットバージョンに設定しているから、とのこと。

パッチ数が順調に増えている。
つまり、Redmineを機能改善したいと貢献する開発者が増えている。

マイナーバージョンアップの期間が長くなる傾向にある。

Redmineの機能改善はとても保守的。
それが逆にすごく有効に作用している。
品質が安定している。

RedmineがRails4.2に対応してから、Redmineの機能拡張がやりやすくなったみたい。
RailsのVerUpに追随している。
Rails4.2に対応するRubyのバージョンに対応しているので、1.9にも対応している。

Rails5は、Ruby2.2.2以上しか対応しないので、VerUpしたら影響が大きくなる。

【5】LT

「Location-Based Task Management with Redmine」の発表が面白い。
Danielさんは地図関係の事業をしている。
担当者が現地に行って作業するが、その作業をRedmineで管理している。

その時に、国土地理院から取得した地図と、GPSで把握した担当者の位置状況をチケット画面や担当者画面に表示して、このチケットはどこで作業しているのか、担当者は今どこにいるのか、をRedmineから把握できるようにプラグイン化したらしい。

【6】パネルディスカッション「RedmineのFAQとアンチパターン」

親子チケットのアンチパターンについて、パネラーや参加者と意見交換。
時間がなくてあまり深掘りできなかった。

WBSの最下層はタスクにする。
だから、親子チケットの最下層のチケットは必ずタスクになる。

eWeaverでも、Redmineで運用する前に、ユーザにヒヤリングしてプロセスを確定してからRedmineの親子チケットの運用を決めている。

他の資料はこちら。

【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪 from akipii Oga

ある工場の Redmine バージョンアップ from Kohei Nakamura

Redmine 3.4.0にアップグレードしよう! お気に入り改善点一挙紹介 from Go Maeda

オープンソースプロジェクトのチケットを触ってみよう！2017 03-25 from Shinji Enoki

Redmineを活用したプロジェクトマネジメント教育について（ダイジェスト版） from Hirofumi Kadoya

日本の大企業におけるRedmineの利用事例の資料のリンク

最近、日本の大企業におけるRedmineの利用事例がPDFでネット上にかなり公開されている。
後々の自分のために、資料のリンクを貼っておく。

【例1】JAXA(宇宙航空研究開発機構)によるスパコン運用部門でのRedmine利用事例。

“CODA” チケット管理システム | JSS2@JAXA

JAXAのRedmine利用事例の講演資料がWeb公開されました: プログラマの思索

CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント

主用途はソフトウェア開発ではなく、スパコンに関わるさまざまな運用業務の管理に使われており、課内のみならず関係ベンダーともRedmineで情報共有をしている、とのこと。
Redmineの機能をレイヤ構造で十分に分析した後で、業務へ適用した点が素晴らしい。

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

JAXAのRedmine運用事例の分析～「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

JAXAのRedmine運用に隠れている運用ルール: プログラマの思索

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

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

【例2】パナソニックにおけるソフトウェア開発のPJ管理の事例：
開発現場を救うプロセス改善の進め方 - SPIJapan2014

パナソニックの子会社におけるRedmineの利用事例が3つほど公開されている。
一つは、CMMIレベル4を目指して、Redmineを導入して課題解決を図っている。

改善前の状態の問題点として、下記が挙げられている。

・壮大な改善計画の立案のみが存在
・膨大な標準帳票が存在
・職人気質な優秀なメンバーに頼ったプロジェクト運営

この問題点の原因分析を読むと、日本のほとんどの企業に当てはまる問題ではないか、と食い入るように思えてしまう。

そういう問題点がRedmineを導入したことで解決の目処が経ったことを考えると、CMMIレベル4における定量データの収集・分析・是正のレベルは、Redmineのような定量的プロジェクト管理ツールという運用基盤が必須である事実を示唆しているように思える。

また、Redmineに不足した機能として、「親子チケットの関係を持った一括インポート」機能を別で実装した点も参考になる。
階層化されたWBSを一括インポートしたい意図は、WF型開発では十分にあるから。

【例3】パナソニックにおけるオフショア開発のPJ管理の事例：
海外開発拠点におけるソフトウェア開発プロセスの確立 - SPIJapan2015

こちらは、シンガポールのオフショア開発のPJ管理に適用した事例。
「ソフトウェア開発業界でデファクトスタンダードになっているRedmineを導入」という文章を読むと、そうなのか、と改めて気づく。
Redmineの適用方法として「No Ticket, No Commit」を徹底させた点がとても参考になる。

【例4】パナソニックにおける多部門連携のソフトウェア開発の利用事例：
複数部門にまたがったシステム・ソフトウェア開発プロセス改善の取り組み - SPIJapan2016

複数の部門と連携したソフトウェア品質改善のバックグラウンドで、Redmineを利用している事例。
資料のメインは、ツールよりも、組織面や運用面のお話。

【例5】島津製作所における大規模組織の内部統制へ適用した利用事例：
｢効率･品質･統制｣の共通課題に着目した現場主導による ITS 導入事例～OSS 運営ツールで効率的・低コストな導入を実現～　(IPA　「先進的な設計・検証技術の適用事例報告書 2016 年度版 」)

｢効率･品質･統制｣の共通課題に着目した現場主導による ITS 導入の効果検証～SQIP2014

ソフトウェアの品質向上に資する開発・運用現場の情報管理～現場主導によるITS導入～JASST関西2013

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

チケット駆動でソフトウェア開発のメトリクス分析を行うアイデア: プログラマの思索

Redmineの理想と現実～RxTStudy #12 「ITS活用最前線～現場からの実践報告」の感想: プログラマの思索

@akahane92さんが中心で行われた大規模組織の内部統制の利用事例。
何度も内容は聞いているけれど、個人的にいつも気になる点がいくつかある。

一つは、ITSMSやISO9001で要求されるOffice文書は、どのように構成管理されているのか？
普通は、共有ファイルサーバーに配置しているので、履歴管理されていない。
一方、SVNでOffice文書を管理するのは可能だが、SVNリポジトリが膨大なサイズになるし、大容量ファイルをコミットする時にSVNへ負荷がかかるデメリットがある。

もう一つは、チケットだけでなく、ソースやOffice文書も含めた全文検索のインフラはどのように構築しているのか？
ITSMSやISO9001の内部監査では、1～2日の間に、内部監査員から要求された文書を証跡として、素早く提出して確認を取る必要がある。
その証跡が提出できなければ、正しいプロセスを踏んでいない、という印象を監査員から持たれてしまう。

つまり、障害や仕様変更などの事案に対し、それと関連付けられたチケット、ソース、Office文書を即座に検索して検索結果を得る必要がある。
そのインフラは、「No Ticket, No Commit」という手動の運用ルールに紐付けられたトレーサビリティだけで十分か？

そんな疑問が思い浮かぶけれど、これだけ大規模な運用で成功している事例なので、裏では相当濃いノウハウがあるに違いないと思う。

【例5】電子楽器の商品価値を高めたモデルベース開発フレームワーク

組込みソフトウェアの派生開発、プロダクトライン型開発にRedmineを導入した事例。
プロセスよりもソフトウェア設計に力点を置いている。

「Redmineを変更管理に適用」、
「チケット駆動の大規模反復型開発」、
「コードのみならず全文書をSubversion管理とRedmine連動によるトレーサビリティ実現」
の部分がすごく気になる。

【例6】「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」

Redmineをソフトウェアプロダクトラインの開発基盤として構築しようとモデル化してる、とても野心的な事例。
ソフトウェアプロダクトラインは、ソフトウェアモジュールをハードウェア製品の部品のように、共通部品と可変部品に分けて、部品を組み立てるようにモジュール生産したい、という発想。

その場合の課題は、ソフトウェアアーキテクチャを共通部分と可変部分にどのように分けるか、という点だろう。
ソフトウェアをそんなに綺麗に分けられるのか？

また、コア資産とアプリケーション資産に分別した場合、それぞれのソフトウェア資産に対する開発プロセスは明確に分けて、かつ、緊密に情報連携させるにはどのような仕組みが必要なのか？
その開発プロセス基盤にRedmineを導入した場合、コア資産とアプリケーション資産をどのようにRedmineにマッピングし、どのように運用するのか？

次回5月の第12回勉強会 - redmine.tokyoで講演していただくので、内容がとても楽しみ。

【追記１】
第12回東京Redmine勉強会の感想 #redmineT: プログラマの思索

【追記２】気象庁でもRedmineを利用している事例の資料が公開されている。
複数のRedmineインスタンスを立ち上げて、故意に複数インスタンスで利用されている点が興味深い。

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

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

「Git と Redmine を用いた気象研究所共用海洋モデル」の論文のリンク: プログラマの思索

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪

次回のRedmine大阪のパネルディスカッションの資料を事前に公開しておきます。
パネルのテーマ「RedmineのFAQとアンチパターン」に関する資料を書いていたら、ページ数が増えてしまったので、事前に公開しておく。

【参考】
Redmine大阪 第16回勉強会 - connpass

【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪 from akipii Oga

Redmineの親子チケットの功罪: プログラマの思索

最近よく聞くRedmineのFAQ～Excel添付のチケットから野良Redmineまで: プログラマの思索

親子チケットを使う上での用途や問題とかを洗い出してくれている。Redmineの現機能上の制約なども書いてあり、参考になる。 - prisira のコメント / はてなブックマーク

【1】Redmineが他のPJ管理ツールと違う点は、OSSでありながら、チケットやPJの階層が無限に作れること、があると思う。
その特徴があるがゆえに、多様な業務でもPJごとに切り替えたり、WBSの粒度に合わせて親子チケットで表現できる。
つまり、多様な業務、大規模な組織でも、Redmineの利用範囲が広がっている。

しかし、特に、親子チケットは落とし穴が多い。
そのアンチパターンや、よく聞かれるFAQを資料にまとめてみた。

【2】Blogでアイデアを書き散らした後で、もう一度見直した点は、「ＷＢＳはプロジェクト組織を規定する」という意見だ。
作業や業務内容を親子チケットで表現したものの、何故かしっくりこない原因には、「ＷＢＳはプロジェクト組織を規定する」という事実が背景にあるような気がする。

ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索

実際、Redmineでプロジェクト管理を始めると、WBSはチケットでどのように書けばいいか、という質問がよく来る。
他にも、チケットの粒度やチケットの完了条件、ワークフローの質問もある。
つまり、WBSは工程単位に作るべきなのか、機能単位に作るべきなのか、という質問が根本的と思う。

彼らは、情報処理試験で習った教科書通りに、工程単位にタスク分割して階層化して、WBSをチケット化しようとする。
しかし、実際は、そんなきれいな開発はほとんどない。

経験上、工程単位のタスク分割でチケット駆動を始めると、たいてい上手くいかない。
溢れたタスク、割り込みタスク、仕様確認のQA、突然発生した障害など、WBSでは表現しきれない作業がどんどん現れるからだ。
それらのタスクは、どの工程に入れるべきなのか？
いつも判断に迷う。

たとえば、バージョン＝工程に紐付けても、障害が出るたびにバージョンはReOpenされ、いつになってもCloseできない。
工程単位にPJを作るチームもあって、工程ごとにタスクを分割したい発想が根源にあるけれど、工程単位に作ったPJのチケットは統一的に管理しにくい。
その結果、チケットは乱発され、放置されて、Redmineはゴミ箱になる。

つまり、彼らは「WBSは工程単位に作るべき」という思い込みに囚われすぎていると思う。
もっと柔軟に考えて、実際の現場の運用に合わせて、もっと軽量なプロセスにすべきだと思う。

ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌からで指摘していることは、WBSの構造、つまりチケット化されたタスクの構造は、そのチームの組織構造を体現することだ。
機能別組織ならば、工程単位のWBSが向いているだろう。
つまり、縦割り組織だったり、開発工程をベンダーに一括請負契約で丸投げ発注している場合には、向いているかもしれない。
しかし、その後の受入テスト、部門間の調整事項などのタスクや課題が発生したら、その運用では耐えきれないだろう。

また、親チケットの開始日・期日・進捗率・予定工数は子チケットをロールアップさせるべきなのに、親チケットにせっかく入力した予定情報は消して欲しくない、という要望がすごく多い。
結局、親チケットと子チケットはバラバラに運用したい、という現場が多い。
つまり、彼らも綺麗なWF型開発を運用するのは難しい、と知っているのだ。

【3】上記の資料を書きながら思ったことは、あるべきチケット駆動開発をRedmineが完全に実現しきれていないことだ。
Redmineの機能制約があるために、チケット駆動開発のあるべき姿に制限がかけられて、未実現に終わっている。

例えば、ロードマップ画面で、スクラムのバックログのようにチケットの優先順位をドラッグ＆ドロップするパッチが提供されているのに、まだ実現されていないゆえに、Redmineはアジャイル開発のツールとしてまだ不十分だ。
そのパッチの提供者のMarius BALTEANUさんは以下のように書いている。

Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmine

(Google翻訳による引用開始)
ロードマップタブでは、トラッカータイプ（アルファベット順）と作成日付（古いもの）の後に、バージョンで自動的にソート（配置）されます。
あるバージョンの問題の位置を手動で設定したり変更したりすることは可能でしょう。
このようにして、ユーザーはバージョン内の作業の優先順位をつける方法が増えます。
ユースケース：私たちはバージョンをスプリント（時間ベース）として使用し、各バージョンについて、チームが次の期間に実装すべきいくつかの問題を計画します。
この機能を利用できるようにすることで、機能の実装順序も設定できるようになります（バージョンの上位にある問題が最も重要です）。
このメカニズムは、現代のソフトウェア開発（スクラム、かんばんなど）に非常に使用されており、チームで使用するのは簡単ではありませんが、古典的な計画（開始日、期日、後続/先行関係あり）定期的に問題を発行し、優先順位が頻繁に変更されます。
(引用開始)

彼の意見に僕は同意見で、ロードマップ画面はアジャイル開発のバックログ、かんばんのように使うべき画面へ改良すべきと思う。

他に、ロードマップ・カレンダー・文書・ファイル画面のように、Redmineで置き去りにされた機能は、もっと改善すべき余地がたくさんある。

しかし、逆に言えば、Redmineで色々試すうちに、チケット駆動開発のあるべき姿が見えてきた、という経緯もある。
こんなやり方もあるよね、とたくさんの人々が試して、初めて分かったアイデアもある。

つまり、RedmineはWebのプロジェクト管理ツールとして、先進的な人々が試す実験ツールなのだ。
だから、Redmineが機能改善されて、チケット駆動開発のあるべき機能が実現できれば、今まで思いもつかなかった運用方法や効果が出てくるだろう。
すなわち、Redmineにはたくさんの可能性が秘められている。

幸いなことに、Redmineはオープンソースなので、自由にカスタマイズできる。
Redmine本家でも活発に機能改善パッチが提供されて、どんどん改良されている。
今後のRedmineにすごく期待している。

Redmineのワークフロー設定を拡張する機能提案～Redmineは汎用的なBPMツールになりうるか

Redmine本家のチケットを見ていたら、Redmineのワークフロー設定を拡張する機能提案のパッチが起票されていて、Planioの Jan とやり取りしていた内容が興味深かった。
ラフなメモ書き。

【参考】
Patch #20384: Proposal: Workflow enhancement - Redmine

【1】Frederico Camaraさんの発言

(Google翻訳による引用開始)
私はブラジルの大規模なICT公開会社に勤務しています。
ここではRedmineを使用しています。

最初は、Redmineのワークフローツールが何らかの制限を加えることは明らかになりませんでした。
しかし、より複雑なワークフローを構築し、さまざまなプロジェクトやチームのロールとトラッカー名を再利用するようになると、特定のロールやトラッカーに固有のワークフローによって、ロールやトラッカーと同様の名前と同義語が使用されるようになりました。
当社のさまざまな分野の新しいワークフローを開発することができます。
これには、名前の大文字と小文字の使用、数字の追加、両方の性別の単語の使用（ポルトガル語の実体は性転換を持つ）などがあります。
同様のエントリがRedmineのさまざまなメニューに表示されるため、最終的には迷惑になりました。

また、クローズステータスは発行ステータスに固有であり、ワークフローでは重複してエントリを複製するため、一部のステータスでは問題が終了しますが、別のワークフローでは同じステータスにはなりません。
ワークフローは依然として役割とトラッカーに固有のものであるべきだと思いますが、プロジェクトには異なるワークフローセットが用意されているため、同じワークフローを使用して異なるプロジェクトを作成し、同時に異なるワークフローを使用する異なるプロジェクトを作成できます。

また、クローズされたステータスは、使用されているワークフローに固有のものでなければなりません。

最初の提案では、管理画面にワークスペース、ワークフローセット、ワークフロースペースなどの項目が表示されます。
そこから、ワークフローはワークスペースの一部になり、各プロジェクトでは使用するワークスペースを選択します。
移行の目的で、既存および新規のワークフローおよびプロジェクトはすべて、デフォルトのワークスペースに割り当てられます。
新しいサブプロジェクトは、作成時に親と同じワークスペースを選択する必要があります。
プロジェクト間にワークスペースの継承はありません。

主な利点は以下のとおりです。

・作成される発行ステータスの数が少なくなります。
・ワークフロー間の簡単な移行
・複雑なインフラストラクチャに対するより多くの制御。
・より単純なインフラストラクチャへの影響は非常に小さい。
(引用終了)

(Google翻訳による引用開始)
私は、コミットをチェリーピックし、Redmine3.3安定に対して必要な調整を行った。
ここにパッチがあります。

「管理」メニューに「ワークスペース」が追加され、既存のすべてのワークフローが「デフォルト」のワークスペースに移行されます。
プロジェクトごとに、使用するワークスペースを選択できます。
ワークスペースは、ワークフロー（遷移とアクセス許可）を互いに分離して、異なるプロジェクトが異なるワークフローを持つことができるようにします。
また、管理を手助けしようとします。
このパッチはLinux上で作成されました。
Windowsでは改行文字を修正する必要があります。

変更点：管理では、「ワークスペース」にワークスペースを追加できます。
管理>ワークフローには、新しいフィルタ「ワークスペース」があります。
ワークスペースを変更すると、異なるワークフローセットが切り替わります。
これは、フィールド許可タブの場合にも機能します。

[管理]> [ワークフロー]> [概要]には、異なるワークスペースからのビューを切り替えるためのドロップダウンメニューがあります。
管理>プロジェクトは、各プロジェクトが使用しているワークスペースを示します。
各プロジェクト>設定で、プロジェクトが使用しているワークスペースを変更することができます。

「すべて」をクリックすると、ロールがフィルタリングされたトラッカーを表示/非表示できます。
ロールは、ワークスペース上でワークフローを持つロールと、割り当てられていないロールによってフィルタリングされます。
（管理>ロール）フィルタリングされたロールの表示/非表示を「すべて」をクリックするデフォルトのワークスペースを削除することはできません（また、移行する場合は、これまでのワークフローをすべて削除します）。
(引用終了)

【2】Jan from Planio www.plan.io さんの発言：

(Google翻訳による引用開始)
これは面白い（広範囲で複雑なパッチだが）、それを提案してくれてありがとう。
この大きさのパッチが考慮されるためには、完全なテストカバレッジが必要であり、既存のテストを破ってはいけません。
可能であれば、一連のパッチに分解して、各パッチがすべてのテストをパスしたRedmineの実用バージョンになりますが、作業を別々のチャンクに分割することをお勧めします。

Planioの非常に大規模な組織のRedmineとの共同作業の主な要件は、プロジェクトチームが管理者を必要とせずに他のプロジェクトに干渉することなく独自のトラッカー、ステータス、ワークフローを作成することでした。
あなたのパッチは後者の課題を解決するようだが、前者の問題は解決していないようだ。
あなたのソリューションでは、異なるワークフローを必要とするプロジェクトチームは、依然としてRedmine管理者にそれらを作成するよう依頼する必要があります。

特に大規模な組織では、管理者が多くの帽子をかぶり、さまざまなシステムを管理するため、これは大きな課題となります。
彼らは、Redmineの管理領域の設定インタフェースや、特定のワークフロー変更を要求するプロジェクトマネージャのビジネスニーズにどのように対応しているのかを100％理解しているわけではありません。
これは、プロジェクトマネージャが電子メールまたは電話で異なるワークフローのセットを要求しているときに誤解を招く可能性があります。
管理者と一緒にプロジェクトを作成することはしばしば実現するのが難しく、プロジェクトで必要なワークフローを実装するには数週間かかることがあります。

私は、特定の役割がプロジェクトのトラッカー、ステータス、ワークフローを個別に管理できるソリューションが、多くの大企業で見られた課題に適したソリューションであると考えています。
(引用終了)

【3】Redmineを大規模な組織に適用して運用していくと、ユーザグループやカスタムフィールド、ワークフローなどの「設定だけ」をシステム管理者ではなく、一部のPJ管理者に権限委譲したくなってくる。
そのPJだけに必要なマスタ保守は、そのPJ管理者だけが更新する方が早いし、逐一、システム管理者に連絡する必要もないはず。

Janの意見の通り、非常に大規模な組織において、プロジェクトチームがシステム管理者を必要とせず、他のプロジェクトに干渉することなく、独自のトラッカー、ステータス、ワークフローを更新できるようにしたい。

システム管理者はRedmineの全機能にアクセスできるが、PJ管理者にはそこまでの権限を緩めたくはない。
PJ管理者は、Redmineの全機能、Redmineに付与されたマスタ設定の意味まで100％知っているわけではないからだ。

つまり、PJ間同士でマスタ不整合が起きない限り、PJに関するマスタ保守は、PJ管理者に権限委譲して、システム管理者の作業負荷を下げたい。
すなわち、システム管理者無しで、Redmineのあらゆる機能の権限制御をもっと細かく設定したい。

上記のチケットの意図は、おそらくそんな所にあるのだろうと思う。

まだ、上記のチケットに添付されたパッチを適用していないので分からないが、上記のパッチは、以下のような機能を持つらしい。

・「管理」メニューに「ワークスペース」が追加され、プロジェクトごとに、使用するワークスペースを選択できる
・ワークスペースは、ワークフロー（遷移とアクセス許可）を互いに分離して、異なるプロジェクトが異なるワークフローを持つことができる
・ワークスペースにあるワークフローには、ロールやカスタムフィールドなどがあり、PJごとに、ロール単位で制御できる

しかし、Janの意見では、上記のパッチでは、「プロジェクトチームが他のプロジェクトに干渉することなく独自のトラッカー、ステータス、ワークフローを更新できる」機能を提供するが、システム管理者なしでPJ管理者だけでコントロールするには不十分らしい。

【4】では、このパッチが提供する機能の本来の課題は何なのか？
それは、Redmineを汎用的なBPMツールへ機能拡張する方向性を示したい、ということだろうと思う。
そのアイデアについては、以前書いた。

RedmineをBPMツールとして使うアイデア: プログラマの思索

Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索

Redmineにワークフローエンジンとして必要な機能～ワークフローに組織マスタの情報を持たせる: プログラマの思索

上記のパッチが提供するイメージとしては、最終的には、Redmineのマスタ保守をPJごとに保存でき、PJ単位で保守できるようにすることだ。
つまり、PJ単位でワークフロー設定情報をXML出力してバックアップでき、そのXMLをインポートすれば即座にRedmineのPJごとにマスタを復元できるイメージ。

管理画面から、PJごとにワークフロー情報を画面から更新できるならば、その情報を出力したり、一括インポートできる機能があって然るべきだろう。
実際のRedmineではそんな機能はないが、そこまで実現できれば、RedmineはOSSのBPMツールとして、十分に通用するだろう。

そもそも、RedmineにBPMツールのような機能が必要なのか、と言われると、正直分からない。
でも、Redmineの管理画面の権限制御の課題は、東京RedmineでもRedmine大阪でも、一部のユーザからは似たような問題意識が提起されていた。
つまり、彼らも、Redmineを運用している組織が大規模になってくると、管理画面の権限制御をシステム管理者なしで、PJ管理者がPJ単位で制御できるようにしたくなってくるわけだ。

QA #263: カスタムフィールドの選択項目定義（KVS）を、admin以外にも可能としたい。 - Unofficial Redmine Cooking - redmine.tokyo

QA #265: カスタムフィールド(list)の選択肢定義をadmin以外編集可能にしたい(KeyValueList以外で) - Unofficial Redmine Cooking - redmine.tokyo

QA #266: ユーザグループの定義内容変更をadmin以外も可能にしたい - Unofficial Redmine Cooking - redmine.tokyo

上記チケットのやり取りを見ていると、今後のRedmineの発展の方向性は、そこにあるのかもしれない。

残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事

残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事が面白かったので、リンクしておく。

【参考1】
Redmineで残業申請ワークフロー - My Tracking

(引用開始)
勤務管理の厳正化が叫ばれる昨今、所属する会社でも残業申請が行わている。 概ね、以下のような残業申請の形態（一応システム会社）。

基本Excelでの申請台帳形式
申請者が事前にExcelに以下の内容を入力する。
①申請日・②時間・③残業予定時間・④概要・⑤内容。
申請者が上司にメールする。
上司が内容を確認し、承認/却下とその理由も添えてExcelに記載し、回答する。
事後申請の場合は、申請者がその旨記載し、入力する。

いろいろな問題をはらんでいるものの最大の問題が、

「Excelの台帳を誰かが開きっぱなしにすると、申請自体ができない」

という最も単純かつ根本的な問題に行きつき、そのわずらわしさから、申請自体がおざなりになるという事態が頻発。
(引用終了)

システム会社であっても、残業申請はExcel管理台帳に書いて、それを印刷して、警備員に渡す運用フローが回っている所は多い。
Excel管理台帳や印刷した紙は便利だが、大人数の運用には向いていない。
こういう現場はまだまだたくさんあるのではないだろうか？

上記の記事では、そんな問題意識からRedmineを導入したらしい。
興味深い点は二つある。

一つは、最初にBPMN 製品を検討したがRedmineに乗り換えた点。

僕も一時期、汎用ワークフロー基盤を持つパッケージ製品を調べていたので、事情は何となく分かる。
確かに、事務処理のような汎用ワークフローの機能は豊富だが、複雑すぎて使いこなせない。
汎用ワークフロー基盤のメリットは、組織情報を持っているので、組織や役職に応じた複雑な条件をワークフローに入れ込むことができること。
しかし、もっと簡易なワークフロー機能だけで、十分に使える利用シーンは多いから。

Redmineは帳票ワークフローシステムであるというアイデア: プログラマの思索

Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索

Redmineを勤怠管理システムで運用するアイデア: プログラマの思索

オープンソースのBPMツールBonitaのメモ: プログラマの思索

オープンソースのワークフローエンジンActivitiの感想: プログラマの思索

BonitaBPMを動かしてみた感想～BPMツールに必要な必須機能: プログラマの思索

もう一つは、「事前申請」「事後申請」の二つのトラッカーを使っている点。
普通は、事前申請トラッカーだけだろうが、たとえば、本番障害の緊急対応で急遽、休日夜間に出勤して対応した、という事態もあるだろう。
つまり、例外的な残業申請に対して「事後申請」というトラッカーを設けている、と思われる。

この辺りは、現場に応じていろんな状況があるはずなので、例外的な運用をどこまでシステム化するのか、あるいは、手運用でフォローするのか、という天秤をかけることになるのだろう。

個人的には、残業申請のように、特に細かな観点の集計が必要でないワークフローは、IssueTempateプラグインで、説明欄に申請テンプレートを作っておく運用がとてもマッチしていると思う。

Issue Template - Plugins - Redmine

理由は、申請テンプレートを用意しておけば、申請者は空欄に情報を埋めるだけでよく、申請内容を考える労力が減るし、申請内容の記載漏れも減るからだ。
わざわざ、たくさんのカスタムフィールドを設けて、入力が面倒になるようなUIにする必要はない。

事務処理ワークフローでは、IssueTempateプラグインのようなチケットテンプレートを事前準備する機能が重要になってくるだろうと思う。

【参考2】
Redmineを使ったITIL的な運用プロセス管理 - My Tracking

(引用開始)
所属する会社（一応システム会社の情シス）では、 日々ヘルプデスク業務や問合せ業務が頻繁に発生するが、 概ね、どこにでもあるような以下の課題が発生している。

当事者同士の口頭・メールベースでやり取りが可視化・蓄積化されずらい。 （しかも、個人に割り当てされるメール容量が少ないため、メールを最終的には削除せざるを得ない。)

問い合わせに端を発し、課題管理・ 変更管理といった形でプロセス遷移していった場合、その遷移が事後的に追いづらい。 （あの件どうだったっけ？が頻発する。）

以下の参考書籍には、顧客サポート業務をRedmineを使用して行っている好例があっため、先述の課題をRedmineで改善できないかと考えたのがそもそもの発端。
(引用終了)

システム会社であれ、製造業であれ、小売業であれ、ヘルプデスクや問合せ、カスタマーサポートのような業務は必ずある。
それら業務は普通は、メールや電話などでやり取りされているだろう。
しかし、個人ベースで情報蓄積されてしまいがちで、応援したくても刻一刻と状況が変わるような状況では情報共有しにくく、引き継ぎしにくい。
特に、顧客からの問合せには、即座に対応する緊急性の高いものから、優先度が低いものまで多様なので、それら切り分けも大変。

上記の記事で興味深い点は、「ITILのプロセスを「トラッカー」で表現し、それぞれステータス更新させる」している点。
つまり、インシデント管理、問題管理、変更管理、リリース管理などのプロセスごとにトラッカーを作り、運用方針を定めている。
このやり方の方が上手く回るだろうと思う。

僕も、9年前に、ITILをRedmineのワークフローで回そうと色々試していた時期があった。
当初は、一つのトラッカーで、インシデント管理、問題管理、変更管理、リリース管理のプロセスにステータスを割り当てて運用しようとしていた。
すると、ステータスが10個近くにもなり、チケットは更新されているのに、外部から見るとチケットが滞留しているように見えて、あまり上手く運用できなかった経験がある。

ステータスの多いトラッカーでよく見られるアンチパターン「スタンプラリー」に陥っていたのだと思う。

個人的には、こういうタスクは、親子チケットにすれば良いと思う。
親チケットが進捗報告用、子チケットがそれぞれのプロセスのチケットにすれば、親チケットで進捗率や状況が一目で分かる。
また、各プロセスの子チケットでは普通は担当者がそれぞれ異なるので、担当者も自分のチケットだけに専念しやすい。
こういうたくさんの担当者が関わるチケットは、親子チケットで分割した方が作業しやすいし、プロマネも管理しやすい。

できれば、Redmineで親子チケットのテンプレートを設定できる機能があれば、もっと良いのだが。

最後のコメントもとてもいい。

(引用開始)
以上の感じで、問合せに端を発した１つのチケットが様々なプロセス（ここではトラッカー）遷移を経ながら、 最終的には、クローズされ、その経緯もバッチリ履歴化されるため、 内容をよりシャープにさせていけば、より高精度な業務が実現できそう。

※こんな高機能のソフトウェアを無償で利用できるようにしてくれた開発者・コミュティの人たちに唯々感謝するばかり。
(引用終了)

Redmineの最大の特徴は、チケットの柔軟な機能だ。
そのおかげで、ソフトウェア開発のタスク管理以外の用途にも適用でき、色んな使い方、色んな利用シーンが生まれている。
Redmineは、先進的なプロジェクト管理の実験ツールなので、今後も改良される余地がたくさんあるだろう。
その可能性を色々調べてみたい。

最近よく聞くRedmineのFAQ～Excel添付のチケットから野良Redmineまで

3/25土開催予定のRedmine大阪のパネルディスカッション「RedmineのFAQとアンチパターン」について、資料を集めている。
たくさん集まりすぎて、話せそうにないので、たぶん話せないことをメモ書きしておく。
以下は、未整理のメモ。
たぶん、どこかで講演として話したい。

【1】Excel添付のチケット

チケット説明欄がほとんど無くて、Excel添付だけ。
Excelを開かないと内容が分からない。
添付Excelの内容が最新でないので、話がつながらない。

障害管理、事務処理ワークフローで発生しやすい。

解決策は、いくつかある。
基本は、Excel添付は極力止めて、チケット説明欄に書く。

2つ目は、障害の画面キャプチャは、clipboard_image_pasteプラグインで、コピーした画像を貼り付ける。

peclik/clipboard_image_paste: Redmine plugin for pasting cropped image from clipboard as an attachment.

3つ目は、どうしてもExcelファイルが必要ならば、wiki_uncプラグインで、共有ファイルサーバーのExcelにへリンクさせる。
その方がExcelファイルが大容量でも良いし、Excelファイルがどんどん更新されても最新版は共有フィアルサーバーにあるから。

Redmineで共有ファイルサーバーへリンクするプラグインredmine_wiki_unc: プログラマの思索

追記：
GDriveプラグインがある。
このGDriveプラグインを使えば、添付ファイルや文書はGDriveに配置して、チケットにリンクすればいい。

Gdrive Document library - Plugins - Redmine

neta＠とんこつしかたべないさんのツイート: "G Suite を検討中。Redmineの添付を Google ドライブ にできると捗る気がしたけども、そもそもリンク書けばいいんだよな。プラグイン Gdrive Document library - https://t.co/F1q9aOhRln"

他に、FTP File Server Pluginを使う方法もある。
FTP File Server Pluginをを使って、FTPファイルサーバーを別途用意して、そこに添付ファイルや文書を配置する運用もありうる。

RedmineへのファイルアップロードをFTPファイルサーバーに置き換えるプラグインFTP File Server Plugin: プログラマの思索

FTP File Server - Plugins - Redmine

【2】チケットがポエム

チケット説明欄が散文形式。
誰も分からない。
何をしたら完了になるのか、意見が割れる。

チケット管理のアンチパターンとベストプラクティス - Javaプログラマのはしくれダイアリー

Redmineのチケット管理のアンチパターン事例: プログラマの思索

基本の対策は、チケット起票の運用ルールを策定する。
チケットUIの改善策として、Issue_templateプラグインを使う。
つまり、何を書いたら作業指示書となるのか、テンプレートを事前に用意して、強制的に書かせるようにしたらいい。

Issue Template - Plugins - Redmine

【3】議事録はチケット？　Wiki？

議事録をチケットで回す事例を見かける。

議事録チケットのメリットはいくつかある。
一つは、回覧のチェックができる。
チェックリスト形式で、全員がきちんと読むように義務付けられる。

もう一つは、議事録の書記を担当者でアサインできる。
議事録の責任者を明確にできる。

しかし、議事録チケットのデメリットもあると思う。
議事録がチケットに埋もれてしまうのが嫌。
議事録は日付順に、1箇所にまとめられた方が、変更内容を追跡しやすい。
たとえば、顧客との要件定義の議事録とか。

Wikiの方が共有しやすいと思う。
個人的には、議事録はWikiの方が好き。(この辺りは色々意見があると思う)

対策としては、Wikiに議事録チケットのリンクを張り、日付順に探せるようにしておく。

【4】Redmineでナレッジはどう蓄積する？

業務や技術ノウハウを蓄積したい。
その場合、Redmineをポータルサイトのように使いたい。
PJ横断のグローバルWikiのような機能がRedmineに欲しい。

このアイデアは以前書いた。

redmineでナレッジを蓄積していく方法: プログラマの思索

ナレッジ蓄積用のプラグインはいくつかある。
WikiExtensionsプラグイン。

Wiki Extensions - Plugins - Redmine

用語集プラグインは、業務分析工程での専門用語の管理、社内辞書として使える。
但し、Ver3.xに未対応なので、有志がカスタマイズしている。

redmine_glossary（用語集）プラグインのRedmine 3.0（3.1）対応 - torutkの日記

knowledgebaseプラグインは、タグ付けやカテゴリ分類ができて、情報の役立ち度をランク付け、記事にコメント可、管理メニューから即アクセス可能。
たぶん、グローバルWikiとして使いたいなら、knowledgebaseプラグインがお勧めかな。
Ver3.3.xでも使えた。

Knowledgebase - Plugins - Redmine

alexbevi/redmine_knowledgebase: A knowledgebase plugin for Redmine

個人的に、Redmineでいつも残念な機能は、コードシンタックスの言語が少なすぎること。
C#がない。
.NET開発者から、いつも問い合わせが来る。

2016年12月のRedmine開発状況 | Redmine.JP Blog（Feature #24681: シンタックスハイライトの対応言語を100以上に増やす）

【5】チケット完了時に項目が未入力

チケットの期日、進捗率が未入力で放置されやすい。
CFが空欄だとチケット集計時に困る。

対策は、完了時に自動補完させる。
issue_completionを入れる。

Redmineチケットの完了時に進捗率と期日を自動更新するプラグインredmine_issue_completion: プログラマの思索

カスタムフィールドの自動補完は、ViewCustomizeプラグインで実装できるだろう。

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

【6】チケットのCFが多すぎる

CFが誰も使わない項目になっている。
Excel管理台帳の項目がそのままチケット化された場合に多い。
特に、障害管理台帳とか。

CFのメリットは集計しやすいこと。
一方、入力コストが大きい。
CFはコピーしにくい。
タブキーが使えないので、入力が面倒。
CFが多くなるほど、チケットがサクサク流れない。

解決策は、基本はCFは必要最小限にする方が良いと思う。

チケットのUI改善策として、説明欄にテンプレートを準備し、CFを極力使わない方法もある。
Issue_templateプラグインを使う。
チケット入力を楽にするための方法はもっとあるだろう。

Issue Template - Plugins - Redmine

【7】庶務チケットをテンプレート化したい

利用シーンとして、庶務・事務の業務は定型作業。
内容も単純。
集計不要のタスクだから。

定形作業のテンプレートがないと、一貫性がなくなり属人的になりやすい。
CFでたくさん細かく項目を作る程でもない作業が多い。

解決策はいくつかある。
一つは、チケット説明欄をテンプレート化する。
Issue_templateプラグインを使う。

Issue Template - Plugins - Redmine

Issue_templateプラグインは、トラッカー単位、PJ単位にテンプレートを用意できるので、庶務業務のためだけのトラッカーを増殖させる必要がなくなるメリットが良い。

一方、Issue_templateプラグインでは、担当者は空欄になってしまうので、デフォルトの担当者を設定できない。
ここの運用が結構困る。
ViewCustomizeプラグインでデフォルト担当者を自動補完させるように設定する？

ViewCustomizeプラグインでRedmineをマイクロコア化できるか: プログラマの思索

もう一つは、テンプレートチケットを作っておき、チケットのcopy機能を使う。
説明欄をテンプレートにしておき、担当者を初期設定しておけばいい。
開始日を空欄にしておけば、新規でコピーした時、現在日が自動設定される。

【8】毎月の定型作業のチケット登録を簡単にしたい

利用シーンは、月末の作業実績報告書の作成、とか、定期的なログ集計、とか、年1回のシステム保守作業。

akipiiさんのツイート: "手伝ってもらってる感触がいいね！RT @netazone: Redmine に仕込んだ定期チケット作成バッチが、忘れがちな月次タスクのチケット作ってくれるのでとても捗る。 システムに手伝ってもらってる感あって、なんかいい。オススメ。"

チケットを定期的に登録する解決策はどんなものがあるか？

一つは、Cron＋REST APIでチケット自動登録。
他には、定型タスクをチケットするプラグインがいくつかある。

定期的なタスクをチケット登録するRedmineプラグイン: プログラマの思索

【9】チケットがメール化している

チケットがなかなか終了しない。
コメントがスレッド化している。
チケットのコメント数が多い。
チケットのコメントで別の問題解決が進行している場合は、危険なサイン？

個人的には、スレッドが長いチケットは気にならない。
メールのやり取りがチケット化されたと理解できるから。

チケットは細かすぎても逆に使い勝手が悪く、検索しにくくて、困る場合もある。

【10】ソース管理よりも文書管理をチケットで追跡したい

たとえば、ISO9001の規定文書をポータルサイトに配置して共有したい。
文書テンプレートは、ポータルサイトからダウンロードさせて、使わせたい。
ISO9001の規定文書の履歴管理もしたいし、参照や更新権限を制御したい。

現状では、共有ファイルサーバーに文書を置くと、チケットと関連付けれない。
共有ファイルサーバーのファイル管理は煩雑になりがち。

解決策としてはいくつかある。
暫定策としては、ファイル容量が大きすぎな場合は、redmine_wiki_uncプラグインを使う。
共有ファイルサーバーへUNCパスでリンクさせるだけ。

Redmineを文書管理ツールとして使うならば、DMSFプラグインを使う。
RxTStudy勉強会のJAXA講演でも、JAXAではDMSFプラグインを導入していたらしい。
Ver3.3.xにも対応している。

DMSF - Plugins - Redmine

Redmineの文書ファイルを全文検索するプラグインのリンク: プログラマの思索

DMSFプラグインなら、文書を階層で管理できる。
文書ファイルの履歴管理、文書ファイルの簡易ワークフロー制御も可能。
但し、文書ファイルのワークフローはトラッカーと異なる管理画面で設定する。

文書更新時にメール送信、Office文書を全文検索もある。
但し、全文検索は日本語はパッチ必要みたい。

第２回品川Redmine勉強会（日本語全文検索）

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

【11】利用者全員に手軽にアナウンスしたい

利用シーンは、RedmineのVerUpアナウンス、定期メンテナンスなど利用者全員への事前通知。

いくつかプラグインがある。
bannerプラグインなら、バナー表示できる。
このプラグインが一番使い勝手が良い。

Banner - Plugins - Redmine

redmine_maintenanceプラグインでは、メンテナンスモードになると、管理者以外は操作できなくなる機能を提供する。
VerUp時は、そもそもRedmineを再起動するので、使えない？

ameya86/redmine_maintenance: メンテナンスモードを提供するプラグインです

【12】チケット集計機能が弱い

蓄積されたチケットを色んな観点で集計したい。
Redmineの基本機能では集計機能が不足している。
でも自作すればいい。
自分たちで改善していく。

対策は、やり方は色々ある。

CSV出力してExcelマクロ集計。

各種の集計プラグインを使う。
たとえば、RedminePivottableプラグインでピボット集計とか。

Redmine Pivot tableプラグインのリンク: プログラマの思索

他にも色々。
RESTAPI経由でBIツールに集計させれば、もっと多機能にできる。

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

Elastic Search＋Logstash＋Kibana＋TimelionでRedmineのBIを実現する記事のリンク: プログラマの思索

【13】野良Redmineが社内に溢れる

症状として、会社標準のRedmineは使いにくい。
別チームのRedmineは特定PJに特化されている。
運用が拡大すると、運用ルール策定が追いつかない。
オフショアや外部ベンダーのやり取りは、セキュリティ上別サーバーにすべきだから。

結局、社内に非公式のRedmineインスタンスがあふれる。
別名は「闇Redmine」。

Redmineを運用している規模について - Google グループ

Redmineの運用が大規模化していく上での課題～@Will_meaningさんとのやり取り - Togetterまとめ

第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

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

akipiiさんのツイート: "あるある笑。RT @ryouma_nagare: 久々に他人が構築したRedmineを使い始めたが、自分がシステム管理者じゃないRedmineはなんとなく居心地が悪い。"

根本問題は、大規模な組織で多様な業務を、一つのRedmineインスタンスで対応できるか？
組織ごとにRedmineを作りたい意図もある。
セキュリティ上の理由で複数のRedmineインスタンスはありうる。

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

第13回RxTStudy勉強会の感想 #RxTStudy: プログラマの思索

他の課題として、複数のRedmineインスタンスを統合できるか？
組織の統廃合、ナレッジ蓄積の引継ぎなど、いろんな事情があるだろう。

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

Redmine同士でチケットを関連付けたい。
リンク型CFを使う。

Redmineのリンク型カスタムフィールドの使い方: プログラマの思索

【14】他にも「ウォッチャー機能を強化したい」とかある。
後でまとめる。