Redmine

2017/10/14

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係

@t_wadaさんのBlogを読んでいたら、「プラグイン機構はソフトウェアの構造がコミュニティの構造に及ぼす事例に相当する」という重要な指摘があった。
考えたことをラフなメモ書き。

【参考】
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

akipiiさんのツイート: "「ソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方である」 https://t.co/07wYG0M7yf"

akipiiさんのツイート: "Redmineもプラグイン機構を持ちカスマイズしやすい特徴もここに理由があるのかな?「組織構造がソフトウェアの構造に影響を及ぼす(Conwayの法則)と同じように、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうる」 https://t.co/07wYG0M7yf"

【1】上記の記事では、「良い OSS 開発と良いソフトウェア設計の間には緊張関係があると思いますか?」という質問が発端になっている。
意図としては、OSSが良い設計であるには、ユーザからの多数の要望を五月雨式に取り入れると、アーキテクチャとしてもUIとしても一貫性がなくなり、複雑化するだけなので、取り入れないべき。
一方、OSSが活発に活動を維持するには、熱心なユーザがフィードバックやパッチをどんどん送り、ソフトウェアをバージョンアップしながらどんどん機能改善していくミッションがあるべき。

(引用開始)
しかし、それは結果的にソフトウェアの構造をゆがめることにつながらないだろうか。活発さを志向するあまり、機能やコードベースの肥大化を招いてしまい、統一感のある小さく単機能なソフトウェアの姿を保てなくならないだろうか。
もし活発さを志向する OSS 開発にそのようなバイアスがかかるのであれば、そこには構造的な問題、不幸な構図があるように見えてしまう。
(引用終了)

つまり、OSSコミュニティの活発さとより良いソフトウェア設計の間には、トレードオフがある。
では、どうやってその折り合いを採るべきなのか?

一つの解決策としては、OSSにプラグイン機構を設けて、「ソフトウェアを汚さずに、ソフトウェアを拡張する機構」というI/Fを用意しておくことだ。

(引用開始)
プラグイン機構による開発者コミュニティへの質的な転換

その意味で、モリスさんの講演にあったようにソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方であると再認識した。
組織構造がソフトウェアの構造に影響を及ぼすというのは最近よく聞く話だが(コンウェイの法則)、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうるというのは重要な気づきであったと思う。

OSS プロダクトがメジャーになればなるほど、コントリビューションを取り入れつつ、全体の整合性は壊さないような舵取りが大事になってくるのだろう。
大きめの OSS プロダクトや言語設計者のバランス感覚や調整能力が際立つのもわかる。
(引用終了)

つまり、プラグイン機構とは、ユーザコミュニティが単に、ソフトウェアを使用するだけの受動的立場から脱却して、自ら必要な機能はプラグインで実装するように、誘導するためのソフトウェア設計機構なのだ。

よって、プラグイン機構は、「ソフトウェアは組織構造に従う」というConwayの法則の逆パターンのコミュニティ版と言えるのではないか。
つまり、「より良いソフトウェア設計はOSSコミュニティという組織を活発化させる」。

【2】上記の記事を読んで、改めてRedmineについて思いを巡らせた。

【2-1】RedmineはRailsを開発基盤としているので、ソースも読みやすいし、プラグイン機構でユーザが機能拡張することも容易だ。
実際、Railsのプラグインの作成手順は、ネット上にいくらでも転がっている。

日本では、自分たちの組織に合った開発プロセスや業務プロセスに、Redmineを従わせて、Redmineを自由に使いたい、という要望が多い。
日本人はパッケージ製品をそのまま導入するのは嫌で、自分達なりにカスタマイズしたがる、という特徴が、Redmineにも出てくるわけだ。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

Redmineが日本人好みのツールであるという仮説 part2~日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

その時、Redmine本体を修正するのではなく、プラグイン機構を使えば、Redmine本体の影響を最低限に抑えて、カスタマイズすることが可能だ。
そうすれば、Redmine本体のVerUPに追随しながら、カスタマイズした機能の保守コストを下げることができる。

【2-2】では、なぜ、「プラグイン機構=ソフトウェア本体を汚さずにソフトウェアを拡張する機構」がRedmineにあえて必要なのか?

以前、Redmine勉強会では、JPLのRedmineの開発スタイルは非常に保守的である、という話があった。
実際、大幅な機能追加はやらないし、FunctionalTestが通らないパッチは受け取らない。
テストカバレッジは基本は100%になるまでリリースしない。

第8回東京Redmine勉強会の感想 #redmineT: プログラマの思索

JPLの美的感覚、設計思想が、熱心なユーザの機能改善要望を全て実現するのではなく、Redmineの発展に必要な機能、さらに、Redmineの品質低下を起こさないような機能だけに絞り込んでいるのだろう。

すると、確かにRedmine本体はVerUpしても安定しているだろうが、ユーザにとっては、標準機能だけでは機能不足と感じる場面も多くなる。

そんな時に、Redmineのプラグイン機構を用いて、Redmine本体に手を加えずに、自分たちの組織やプロセスに見合った機能を追加するわけだ。

換言すれば、プラグイン機構という柔軟なソフトウェア設計が、OSSアプリの標準機能では物足りないと感じるユーザに、自分達でカスタマイズできる余地を残しておき、それを利用させるような雰囲気を奨励している、とも言えるだろう。
それによって、Redmineは標準単体で安定した品質を保ちながら、ユーザはプラグインを入れて、自分達の環境に合ったプロセスを実現できる。
つまり、Redmineの柔軟なプラグイン機構が、ユーザにプラグイン開発を促進させ、多様なプロセスを実現することを促進させているわけだ。

【2-3】だから、Redmineのように、自由に機能拡張できるI/Fを持つOSSソフトウェアは、日本人向きなのだろう。

実際、Redmineはプラグイン機構以外にもREST APIやメールによるチケット登録、rakeコマンドなどの数多くのI/Fがあり、それらを適材適所に当てはめれば、機能をカスタマイズしやすい特徴がある。
以前、この辺りの事情は分析していた。

Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索

但し、この特徴はRedmineに限らず、SAPなどの著名なERPにおいても、パッチ当てをプラグインのような機構で実現しているので、そんなに特別なわけではない。

【2-4】一方、Redmineは「プラグイン機構=ソフトウェア本体を汚さずにソフトウェアを拡張する機構」の特徴を持つことで、Redmineコミュニティ自身が活発になりやすいこともあるだろう。

日本のRedmineコミュニティではプラグイン開発者が多い、という特徴を以前、@agilekawabataさんが指摘していた。

Redmineが日本人好みのツールであるという仮説part3~日本のRedmineコミュニティにはプラグイン開発者が多い: プログラマの思索

この意味は、日本企業はRedmineを自分たちの組織にあわせてカスマイズしたがるので、プラグイン開発者を必要としていることだ。
そして、そういうプラグイン開発者が日本のRedmineコミュニティには結構多い。

OSSの日本人Redmineプラグイン開発者として、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@onozatyさんたちがすぐに思い浮かぶ。
また、日本企業でも、アジャイルウェアなど、Redmineプラグインを専門に開発するSI企業も結構いる。

そういうプラグイン開発者や開発ベンダーは、RedmineというOSSコミュニティの活動にとても貴重な人達だ。
なぜなら、彼らはRedmine本体に取り込まれなかった機能を無償・有償でプラグインを公開してくれており、ユーザも恩恵を受けられるからだ。

また、彼らはRedmineの機能改善や利用事例に関するニーズも多数保持しているだろう。
そこで得られた知見も多いに違いない。
そして、実際、そういう知見をRedmineコミュニティで発表して、ユーザと共有してくれている。

そんな事を考えると、プラグイン機構というソフトウェア設計は、OSSソフトウェア本体を汚さずにOSSコミュニティを活発化させていくために必要な特性と言えるのだろうと思う。

つまり、柔軟なソフトウェア設計は逆に、OSSコミュニティという組織構造に良い影響を与えているわけだ。

【3】「Redmineは組織構造に従う」「柔軟なソフトウェア設計はOSSコミュニティを活発化させる」という二つの経験則は、正直面白い。

似たような経験則として、逆コンウェイ戦略「望ましいアーキテクチャに合わせて、アジャイルな開発チームを作る」という話もあった。

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

これ以外にも、Redmineインスタンスとプロセスの密接な関係もある。
「唯一のRedmineインスタンスで、組織内の多種多様な状況に合わせた標準プロセスを実現する」という観点と、「それぞれの開発チームの組織文化や開発プロセスに合わせて、あえて、Redmineインスタンスを複数個立てて運用する」という観点の二つのやり方がある。

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

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

どちらが正しい、というのではなく、それぞれの前提条件、組織の状況に応じて、コンテキストは変わる。

今の僕の興味は、Redmineのような柔軟なOSSソフトウェア、それを運用する組織構造やプロセスとの間に、どんな関係があり、どのようなコンテキストが発生しているのか、を経験則として抽出して、その本質を探ってみたい、と思っている。

| | コメント (0)

2017/09/28

Redmineチケットのウォッチャーにユーザグループを指定したい件の回避方法

Redmineチケットのウオッチャーにグループを指定したい話がメーリングリストに流れていたのでメモ。

【参考】
チケットのウオッチャーにグループを指定したい - Google グループ

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

【1】発端はこんな感じ。

(引用開始)
チケットの登録時にウオッチャーにプロジェクトに参加しているグループを追加したいのです。
ユーザを一つずつ選択~指定すると、ふとメンバ漏れが発生しウオッチできていないときがあります。
グループを指定できれば、チケットを登録するメンバも手間が省けるのです。
(引用終了)

Excelやメールを多用していたチームやユーザが、Redmineを使い出すと、ウォッチャーを頻繁に使うようになる。
ウォッチャーをメールのCcみたいに使いたいらしい。
すると、ウォッチャー追加時に、ユーザをフィルタリングしたり、検索しやすくしたりしたい要望が出てくる。

さらに、ユーザグループをウォッチャーに追加したい要望がすごく多い。
なぜなら、メンバーを設計チーム、開発チーム、業務グループ単位にユーザグループで作成しているので、ユーザグループでウォッチャーに追加したいからだ。

この件に関しては、過去にいろいろ調べていた。

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

Redmineのチケットのウォッチャー操作に関する課題: プログラマの思索

【2】しかし、@g_maedaさんの回答では、ウォッチャーにユーザーグループを追加する機能は標準でないし、Ver3.4ではプラグインも対応していないらしい。
@netazoneさんは、下記で対応しているらしい。

(引用開始)
現在は以下、ウォッチャー入力の負担を減らす代替策で運用しています。

【代替手段】

■自作ウォッチャーフィルター(無改造、プラグインなし)

姓カラム:フルネーム(山田 太郎)、
名カラム:役職、部門など属性情報(※営業部)を入れる

さらに、そのままだと表示が長すぎるので、弊社は"名"を非表示にしています
(Redmineの姓名表示設定で変更可能)。

これでウォッチャーのボックスに「営業部」といれると、
姓名に「営業部」を含むユーザだけ抽出されるので、
ウォッチャーを複数人入れたい場合に、検索する回数が減ります。

ユーザのカスタムフィールドに「所属」あたりをつくって
検索対象になればよかったのですが、
できなかったのでこのようなやり方をしています。

こちらに画像が少々
neta@世界は私のオイスターさんのツイート: "Redmine 3.3 純正機能だけで ウォッチャーフィルター再現、うまくいったっぽい。プラグインもソース改造も無し。 複雑な条件はできないが、部門の役職者までならいける。 https://t.co/SQU1DfLMli"

■ウォッチャー専用ユーザ

グループではなく、ウォッチャー専用の"ユーザ"を作って
そのユーザに複数人のアドレスを紐付ける
(閲覧専用でチケットの担当者にできないようにする)

方式A:メーリングリスト・エイリアス方式
グループにしたい人のメーリングリストを作り、
それをウォッチャー専用ユーザに割り当てる

方式B:複数アドレス登録方式
Redmine 3.0 以降だと、個人にアドレスを複数つけることができる。
ウォッチャー専用ユーザにグループにしたいユーザのアドレスを割り当てる。

・短所
「ウォッチャー専用ユーザ」がウォッチャーになっており、
なおかつ個人でそのチケットを担当した人は
通知メールが本人あてと、ウォッチャー専用アドレス宛に2通来てしまう。
(メールサーバで工夫すれば回避できるかもしれない)

Redmine 3.0新機能紹介: 一つのアカウントにつきメールアドレスを複数設定 | Redmine.JP Blog
(引用終了)

上記の回避策のアイデアは、Redmineでは1ユーザに複数メールアドレスが持てるので、ウォッチャー専用のユーザを作り、そのユーザにユーザグループのメンバー全員のメルアドを紐付けることだ。
メーリングリストでも同様に対応できる。

但し、短所で書いているように、チケット更新のたびに通知メールが本人に2通届く可能性がある。

【3】Redmine本家でも同様の要望があがっている。

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

Feature #4511: Allowing to add user groups as watchers for issues - Redmine

他の回避策として、ウォッチャー検索画面で、ユーザグループやロールの検索条件でフィルタリングするプラグインがある。
Ver3.3でも動くので、僕はこちらのプラグインで回避している。

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

ayweak/redmine_watcher_filter: This is a Redmine plugin. This plugin filters issue watchers and checks/unchecks them, by groups, roles and custom field values.

個人的には、ウォッチャーを駆使するよりも、Slackなどの外部チャットツールに連携して、そちらに任せた方が良いのでは、と思う。

| | コメント (0)

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

Redmineの全文検索プラグインが、先日のRedmine大阪の講演時からバージョンアップされた記事を見つけたのでメモ。

【参考】
Redmineでもっと高速に全文検索する方法 - ククログ(2017-09-25)

Redmineのベンチマーク環境構築を自動化する方法 - ククログ(2017-09-26)

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

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

第17回Redmine大阪勉強会の見所~Redmineをナレッジシステム、そしてプロセス保証のツールへ進化させたい #RedmineOsaka: プログラマの思索

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

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

(引用開始)
v0.6.0での変更点

検索結果のハイライトにPGroonga/Mroongaの機能を使用するようにしました
複数キーワードごとに色分けしないようになりました
クエリー構文が使えるようになりました
類似チケットの表示をするようにしました
(引用終了)

(引用開始)
Groongaの類似文書検索の機能を使って類似チケットを表示するようになりました。

例えば、あるソフトウェアのサポートをしているときに似た問い合わせが過去にあれば、その似た問い合わせが類似チケットとして表示されることを期待しています。
現在の実装では、チケットのトラッカー、起票者、担当者、カテゴリなどのメタデータを一切考慮していないので精度はそこそこです。
クリアコード社内で運用しているRedmineに入れてみたところ類似チケットの検索には15msくらいしかかかっていないのでRedmineの性能に影響はないと考えてデフォルトでONにしてあります。
(引用終了)

Redmine全文検索プラグインで、ついに類似チケットを表示する機能が追加されたらしい。
この機能は、勉強会の参加者からも欲しいという話がよくあがっていた。

利用シーンとしては、障害管理やサポートデスクがあるだろう。
たとえば、障害チケットを起票した後、類似バグが表示されるので、新規加入メンバーや修正担当プログラマが過去のノウハウを参考にしやすくなる。
あるいは、サポートデスクで、問合せチケットを起票後、過去の類似チケットが表示されるので、経験の浅いオペレータは参考にしやすい。

つまり、Redmineに蓄積されたチケットの内容が濃密なほど、類似チケット表示の機能は威力を発揮することになる。
また、類似チケット機能が有用と分かれば、入力するテスターやオペレータも、自分が入力するチケット内容に情報を詰め込もうというモチベーション向上にもつながるだろう。
その方が、将来の自分のためにも役立つからだ。

Amazonのおすすめ商品やGoogleのPageRank検索、Facebook広告のように、ユーザ自らが検索するのではなく、システムが自動検知して、ユーザが考えていることをサポートしてくれるわけだ。

Redmineに機械学習や人工知能のライブラリやその知見を流用できたら、もっといろんな可能性が広がると思う。
また、こういう機能をオープンソースで公開されているクリアコードさんは凄いな、と思うし、そういうアイデアを即座に実装できるRailsフレームワーク、そしてRedmineは優れているな、と思う。

そして、最終的には、Redmineは、その会社特有のプロセス資産というナレッジシステムになりうるはずだ。
Redmineはデータマイニングの宝庫であり、ソフトウェア工学を適用できる場所にもなる。

Redmineをナレッジシステムとして実現するには、全文検索プラグインが必須機能と個人的に思う。

今後も、全文検索プラグインの動向に注目していく。

| | コメント (0)

2017/09/15

Redmineをポータル基盤にするアイデア

Redmineをポータル基盤にするアイデアについてラフなメモ書き。
不足部分は後で書き足す。

【1】そもそも、Redmineにポータルの機能を持たせたくなる理由や背景は何か?
今までの経験上、下記の要望があった。

ユーザ側としては、グローバルWikiが欲しい。 自分が所属しているPJメニューの一覧だけが欲しい。
自分の担当チケットの詳細を見るために、マイページをもっとカスタマイズしたい。

つまり、ユーザ側としては、自分がプログラマの場合、社内ではほとんどRedmineばかり使っている。
出社したら、まずRedmineの画面を開くから。

ゆえに、Redmineにログインした後、自分が担当中のチケット一覧がぱっと分かったり、担当中のチケットのステータス数を表示してどれが最優先なのか、表示して欲しい。

すなわち、ポータル画面のようにRedmineで、担当チケットの一覧や、担当チケットのステータス状況を把握したいのだ。

一方、マネージャやPMO側としては、PJメニューが欲しい。進行中のPJ一覧が見たいから。
全員に告知するバナーが欲しい。

つまり、マネージャやPMOとしては、事業部で進行中のPJ全てがどれくらいあって、各PJの進捗がどういう状況なのか、をぱっと見たい。
現在のRedmineでは、プロジェクト画面には多数のPJの概要とリンクが表示されるだけで、PJ数が数百もあると分かりにくい。
また、各PJの進捗を1個の画面で把握したいのに、今のプロジェクト画面は使いにくい。
さらに、事業部の中で、各PJの本番リリース日や重要なマイルストーンを全員に告知したい。

すなわち、ポータル画面のように、事業部で進行中のPJの一覧、それらPJの進捗状況を把握したい。
また、Redmineに、全員に告知する機能も欲しい。

そんな要望を聞いてみると、たぶん、Redmineにポータルのようなシステム機能が欲しくなるのだろうと思う。
普通のポータルの基本機能は、ログインユーザが使える利用システムのリンク、全社・事業部向けの記事の公開・告知、チャットや掲示板などの機能等がある。

その中でも、ログインユーザが所属しているPJ情報、ログインユーザが担当しているチケット情報、事業部内向けの記事の公開・告知、などの機能がRedmineにも欲しいのだろう。

【2】一般に、ポータル製品はCMSの一部としてたくさんあり、エンタープライズ向けのOSSツールとしては、Liferayが有名。
Liferayなら、BitnamiでインストーラやVMが提供されているので、簡単に検証できるのも良い。

オープンソースのポータル/CMS/Liferayとは

オープンソースで構築する企業ポータル「Liferay」を知る--日本法人を新設、本格普及狙う - CNET Japan

Liferay Cloud Hosting, Liferay Installer, Docker Container and VM

【3】Redmineにポータル機能を持たせた場合、現状の機能とあるべき機能のFitGap分析を考えてみる。

Redmineに足りないポータル機能は、下記3つをもっと機能拡張すればいいだろうと思う。

・PJ一覧画面
・マイページ
・Wiki

確かに、現在の最新バージョン3.4でも、PJ一覧画面やマイページ画面は使いにくい。
これら機能は、UIも含めてもっと改善できるはず。

【3-1】PJ一覧画面に進捗バーを出すプラグインはある。
しかし、PJ一覧画面で、所属PJだけ絞り込むとかできないし、数百のPJが表示されると見づらい。

stgeneral/redmine-progressive-projects-list: Redmine plugin provides projects list with progress bars for every project and version

【3-2】マイページ画面は、@g_maedaさんが以前から気にされていて、色々改善されようとしている。

Redmineのマイページをより便利にする My Page Blocksプラグイン | Redmine.JP Blog

Feature #1565: カスタムクエリを表示する新たなマイページパーツ「チケット」 Redmine 3.4 新機能紹介 (3/5) | Redmine.JP Blog

また、古いプラグインだが、マイページにカレンダーなどのパーツを表示できるようにするなどの機能がある。

Redmine 自体に手を入れずにマイページのブロックを追加する方法 - すえひろがりっっっっ!

しかし、個人的には、マイページ画面はまだ使いにくい。
担当チケットの状況以外にも、Redmineの各機能に対し、ログインユーザの情報を表示したり、自由に配置できるようにして欲しいのだ。

他にも、プロフィール画面と個人設定画面は機能が似ていて混乱しやすい、という指摘もある。
この辺りの設計ポリシーも見直しが必要かもしれない。

MAEDA, Goさんのツイート: "Redmineのプロフィール画面(users/:user_id)と個人設定画面(my/account)は統合されるべき。Redmineを10年近く使っているが、いまだに時々間違える。"

東京Redmine勉強会でも、マイページ機能をもっと拡充して欲しい、という要望があがっていた。

QA #330: マイページ機能の拡充 - Unofficial Redmine Cooking - redmine.tokyo

【3-3】ポータルの記事に対応するRedmineの機能は、Wikiになるだろう。
しかし、WikiのUIはIT初心者が使いやすいとは言えない。

Wisywigエディタ機能をRedmineのWikiに持たせたら、Wikiをもっと使ってくれる人も増えるだろう。
たとえば、WordpressのCKEditorみたいなUIがあるといいだろう。

UIがIT初心者にも優しくなるのは良いことだから。
Redmine本家にも要望チケットがあるし、プラグインもあるみたい。

Feature #617: wiki: thoughts of WYSIWYG - Redmine

redmine_wysiwyg - Plugins - Redmine

CKEditor - Plugins - Redmine

【3-4】RedmineにはCMS pluginなるものがあるらしい。
コメントを読むと、WordPressみたいな操作感らしいが、実際はどうだろうか?

New CMS Plugin: WordPress-like websites in Redmine

【3-5】自分の担当チケットの状況を簡易表示するプラグインとして、@akiko_pusuさんが作成したIssue Badgeプラグインがある。

Issue Badge - Plugins - Redmine

右上のメニューに担当チケット数がリアル表示されるのは便利。

一般のポータルシステムでも、稟議書ワークフローシステムから現在のステータスや枚数を表示する機能があるが、それと同じ。

【3-6】全員に告知する機能としては、@akiko_pusuさんが作成したbannerプラグインがある。

Banner - Plugins - Redmine

Redmine本体のバージョンアップ案内、各PJの重要なマイルストーン案内を全員に告知したい時に役立つ。
一般のポータルシステムにある、全員が参照できる記事の機能と同じ。

【3-7】RedmineにグローバルWikiの機能が欲しい、という要望は以前からあがっていた。
つまり、Redmineにポータルな画面=グローバルWikiをログイン時のトップ画面にしたい、という要望だ。
今はまだ未実装。

Feature #1040: Global wiki - Redmine

Feature #381: general wiki for the whole site - Redmine

他に、startpageプラグインを使えば、トップページを任意のWikiページなどに設定できる。
つまり、トップページ=ポータルな画面にするわけだ。

Redmine Start Page - Plugins - Redmine

Redmine startpageプラグインでトップページを任意のWikiページなどに設定する - torutkの日記

但し、グローバルWikiという機能を別途作るのが良いかどうかは正直分からない。
Redmineでは、Wikiは各PJごとに配置されている設計思想なので、むしろ、startpageプラグインのように、特定PJのWikiをトップページへ遷移するように変更する方が良い気もする。

【3-8】@haru_iidaさんのWiki Extensionsプラグインを使う方法もある。
Wikiをもっと機能拡張してくれる素晴らしいプラグインだ。

Wiki Extensions - Plugins - Redmine

Redmine wikiを使いやすくして情報共有をはかどらせる - Qiita

RedmineのWikiに「ページトップへ戻る」ボタンを追加する - kengo700のナレッジベース

上記のように、「Sidebarにリンク集、アクセス数ランキング、タグクラウドなどを追加してアクセスしやすくする」「Footerでアクセス数を表示する」などができる。
WikiをCMSみたいに、もっとリッチで使い易いUIにしたい場合、Wiki Extensionsプラグインはとても有用。

たとえば、新規加入したPJメンバーがこういうリッチなWikiを見る運用にすれば、説明会も不要だし、アクセス数やアクセスランキングが表示されることで、ちょっとモチベーションも上がる。

【3-9】アバターは、Redmine標準ではGravatorなど外部サービスを使っているので、社内Redmineでは使いにくい。
そこで、下記のアバタープラグインを使えば、ユーザのアバターを画像表示できる。
Redmineで息抜きしたり、楽しくするために必要なプラグインだろう。

ncoders/redmine_local_avatars: Local Avatars for redmine - initially imported from https://bugs.launchpad.net/redminelocalavatars

DBマイグレーションもなく、画像ファイルをアップするだけなので、インストールに問題もない。

【3-10】CMSやポータルシステムならば、ユーザごとにテーマをカスタマイズできるのが普通。
Redmine標準では、テーマはサイト固定だが、@haru_iidaさんの下記プラグインで、個人ごとにテーマを変更できる。
Redmineを楽しくしたり、息抜きできるようにするためにも、必要なプラグインだろう。

Theme Changer - Plugins - Redmine

【3-11】Redmineのサイドバーを隠すプラグインがある。
Redmineの画面を広く使いたい時に有用。
もちろん、View customize pluginでもカスタマイズ可能。

Hide Sidebar - Plugins - Redmine

Redmineでサイドバーを非表示にする(View customize plugin) - Enjoy*Study

RedmineのUIが古臭い、と言われる理由の一つは、画面レイアウトがTopメニュー・サイドメニュー・メインレイアウトのように固定されていて、一昔前のiframeのWebページに似ているからだろう。
だから、Redmine本家でも、サイドバーをユーザが無くせる機能改善のパッチが提供されいてる。

Patch #21808: Make the Sidebar collapsible, stateful - Redmine

世界中の開発者も、Redmineの古臭いレイアウトを変更したい、と思っているのだろう。

【3-12】ポータルシステムでは、SNSやチャットの機能は普通ある。
Redmineにも、slackと連携するプラグインはある。
Redmineの活動ログよりも、Slackの方が使いやすい、という場面は多いだろうから。

redmine-slack プラグインを使ってみたメモ - Qiita

また、掲示板の機能は標準のフォーラム機能で代用できる。

【3-13】今時のWebシステムなら、レスポンシブデザインに対応しているのは普通だろう。
RedmineもVer3.2で対応された。
このおかげで、スマホでも画面サイズに合ったレイアウトになる。

Redmine 3.2新機能紹介: レスポンシブレイアウトによるスマートフォン対応 | Redmine.JP Blog

なお、RedminePMというRedmineクライアントアプリもある。

iPad / iPhone / Android対応のRedmineクライアントアプリ「RedminePM」 | Redmine.JP Blog

【3-14】ポータルサイトでは、記事の全文検索は必須機能だ。
記事が蓄積されるほど、過去の記事を検索したくなってくる。

また、社内のポータルサイトでは、ファイル共有の機能も普通は付いてくる。
GoogleDriveみたいに、Officeファイルを共有して、事務処理手続きや設計書を共有する。

その時、ファイル共有した全てのファイルに対し、全文検索したい。
なぜなら、過去に作成した資料を参照したり、他人が作った資料を流用したい時が多いから。

だから、ポータルサイトでは、記事の全文検索だけでなく、ファイル共有内のファイルの全文検索も重要な機能の一つになる。

Redmineの場合、記事の全文検索の解決策は、全文検索プラグインを導入することで解決できるだろう。
ポータルの記事がRedmineのWikiに対応するように運用できるならば、Wikiにデータが蓄積されるほど、全文検索プラグインで有用な結果が上位に表示されて便利になる。

さらに、添付ファイルを全文検索できるパッチもRedmine本家に提供されているので、このパッチがRedmine標準の機能になれば、全文検索プラグインの威力が更に増すことになる。
なぜなら、チケットやWikiだけでなく、添付ファイルの中身も全文検索の対象になることで、Redmineにすべてのデータを一元管理するメリットがより大きくなるからだ。
是非、実現して欲しいと思う。

Feature #306: Full Text Search of files - Redmine

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

【4】以上のような機能評価を考えると、ポータルシステムとは多機能なCMSであるがゆえに、Redmineにはそういう機能は正直ない。
Redmineの本質はチケット管理システムであり、CMSではないからだ。

しかし、RedmineにはWikiがあるがゆえに、Wikiを機能拡張することでCMSに近い機能を持たせることはできる。
また、全員に告知できるbannerプラグイン、担当チケット数をリアル表示するIssue Badgeプラグインのような機能は、ポータルシステムでは普通にあるので、Redmineにも標準であると使い勝手は上がるだろう。

そんな事を考えてみると、RedmineのUI改善の方向性は、CMSやポータル基盤が進化した歴史を参考にすると良いような気がする。
実際、それらの機能をRedmineに追加したい要望が多いからだ。

色々考えてみる。

| | コメント (0)

2017/09/11

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか

東京Redmine勉強会のLTで、複数のRedmineインスタンスからデータ収集してAgile開発する利用事例があった。
もう一度見ながら、ラフなメモ書き。

複数Redmineでagile開発する 20170513

【1】RedmineはOSSで無料であり、インストール手順はネット上に公開されているので、誰もがすぐに運用できる。

すると、最初は自分たちのチームだけで使っていたら、各案件、各チームごとに社内でRedmineインスタンスが乱立してしまう。
このような状況は、野良Redmineと呼ばれていた。

あるいは、社内標準で設置されたRedmineは、各案件の特徴にあった運用ルールやプロセスに準じておらず、使いづらいために、こっそり自分たちのRedmineを使い始めた、という話もよく聞く。
このような状況は、闇Redmineと呼ばれていた。

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

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

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

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

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

そのように、多数の複数Redmineインスタンスが乱立している状況では、各チーム・各案件の進捗状況を横串で把握しにくい問題が出てくる。
そこで、複数Redmineインスタンスの進捗状況を横串で把握できる仕組みが必要になってくる。

あるいは、組織の統廃合などで、複数Redmineインスタンスを一つに集約したい要望が出てくる。

【2】このような要望や問題を考えると、その課題はいくつかあげられる。

【2-1】一つは、複数Redmineインスタンスの情報を一括集計する方法は何か。

複数Redmineインスタンスを現状運用しながら、全体進捗を一括集計したい場合、RedmineのREST APIを使う方法があげられるだろう。

上記のLT資料は以下の通り。

(引用開始・多少編集)
【問題意識】
受託開発案件のRedmine利用率、なんと100%
1 プロジェクト、1 Redmineのパターン
それぞれの顧客から自分のRedmineを使いたいね

【やりたいこと】
やりたいことは 複数のRedmineでAgile開発を楽にしたい
● 一目で、それぞれのプロジェクトの進捗状況が知りたい
● Agileスプリントの作成・編集を行いたい
● スプリントごとの進捗を Burndown chart式で見たい
● スプリントごとのタスク進捗をカンバン式で見たい
● Velocityを測りたい
● 見積のないタスクをすぐに特定したい

一目で、それぞれの プロジェクトの進捗状況が 知りたい!!!

【解決方法】
救世主:Redmine API できることは結構ありそう
● プロジェクト、バージョン、タスクなどの操作
● タスクの更新履歴が取れる!
● 複数のRedmineサーバから集計できそう!
(引用終了)

この仕組みを自分たちで作って「Redmine Tracker」と名付けたらしい。
まだ未公開のようだが、OSSで公開してくれるとすごく嬉しい。

Agile開発に特化しているので、WF型開発案件やその他の種類の案件では使いにくいかもしれないが、ニーズはとても多いのではないかと思う。

【3-2】もう一つは、複数Redmineインスタンスを1個のRedmineにサーバー統合する方法はあるか。

複数のRedmineインスタンスをサーバー統合する方法は、一筋縄ではいかない。
利用事例としては、下記の発表資料がある。

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

乱立してるRedmineを一つにまとめる話 agileware-jp/douhashi-slides

他システム(Notes)からRedmineへの移行(第3回品川Redmine勉強会)

NGK2012BでRedmineとRedmineを統合した話について発表してきた | Dabits

いずれも相当苦労している。
理由は、RedmineのIDはDBシーケンスなのでID変換用の中間テーブルが必要であることや、データ移行用のツールを別途開発する必要があることだろう。

たとえば、アジャイルウェアの堂端さんの事例では、17個のRedmineインスタンスを1個のRedmineに統合して、チケット数9万以上、プロジェクトは1千個以上に膨れ上がったらしいので、恐れ入る。

【4】1個のRedmineに集約するメリットは、チケット入力の運用ルールさえ徹底できれば、1個のRedmineのデータから、社内の全PJの進捗や品質の情報を集計できることだ。

実際、Redmineには複数プロジェクト機能や親子チケット、柔軟なワークフロー設定などがあるので、案件がWF型開発でもアジャイル開発でも実費請求の保守案件であっても、1個のRedmineインスタンス内で、別々のプロジェクト設定やワークフロー設定で区別して管理できる。

つまり、PMOや品質保証部から見れば、多種多様な案件があったとしても、Redmineという一つの箱を見れば、進捗や品質も一元管理できるのは最大の効果だ。
すわなち、Redmineの柔軟性が、多種多様なプロセスを全て飲み込んでくれるわけだ。

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

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

【5】一方、複数のRedmineインスタンスでの大規模な利用事例としては、気象庁のRedmine利用事例があげられるだろう。
資料を読むと、インフラ構成も公開されているので、インフラ関係者は必見だろう。

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

また、各Redmineインスタンスで運用ルールが異なっている点も興味深い。
そのような運用の背景には、各部署の権限が強く、組織文化も大きく異なるので、あえて1個のRedmineではなく、複数のRedmineの方が運用しやすい、という判断があったのではないか、と想像する。

【6】複数のRedmineインスタンスで運用している場合、Redmineインスタンスごとに運用ルールが異なるので、第三者の観点で見ると、社内で数多くのチームがバラバラに動いているように見える。
ゆえに、それぞれのチームの文化がRedmineと一体化しているので、1個のRedmineに統合するのはとてもハードルが高いだろうと想像する。

なぜなら、「アーキテクチャは組織に従う」「プロセスは組織に従う」という発想と同様に、「Redmineは組織に従う」「Redmineはプロセスに従う」経験則が見られるからだ。
よって、「標準の唯一のRedmineに全案件のプロセスを従わせる」というやり方は、大企業になるほど難しいかもしれない。

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

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

【7】一方、各チームがアジャイルに開発したいならば、チームごとにRedmineインスタンスを提供して、自分たちの開発に合わせたプロセスへどんどんカスタマイズした方が良い、という考え方もできる。
つまり、運用されているRedmineはチームの組織文化や慣習を表しているので、あえて全社統一のプロセスに標準化するよりも、変化の激しい状況に対応できるように、チームごとに動けるようにするわけだ。

すなわち、逆コンウェイの法則「アーキテクチャに合うような組織を作る」という発想のように、あえてスクラムチームまたはアジャイルチームのような機動的なチームに細分化し、そのチームの文化やプロセスに合ったRedmineへカスタマイズする戦法もありうるはずだ。

「Redmineに組み込んだプロセスに合うチームを作る」という観点で、あえて野良Redmineを作り出す手法もあるだろう。

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

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

【8】日本におけるRedmineの高い普及率の背景を見ると、Redmineと日本企業の組織文化の相性の良さが見えてくる。
おそらく、海外とは違った事情が日本の組織文化にあると、個人的には感じている。

日本で組織にRedmineを従わせる事例が多いのは「Redmineはとても柔軟なので、Agile開発にもWF型開発にも使える」「プラグインなどで機能拡張が簡単なので、組織構造や標準プロセスにRedmineを従わせやすい」理由があるのだろうと思う。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

Redmineが日本人好みのツールであるという仮説 part2~日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

Redmineが日本人好みのツールであるという仮説part3~日本のRedmineコミュニティにはプラグイン開発者が多い: プログラマの思索

今後も色々考えてみる。

| | コメント (0)

2017/09/08

Redmineの最新機能でサポートデスク管理をより効率よく使う運用方法のアイデア

前回のRedmine大阪で、前田剛さん、須藤さんの話を聞きながら、Redmineの最新機能でサポートデスクをより効率よく使う運用方法について、考えたことをメモ。
ラフなメモ書き。

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

Redmine大阪 第17回勉強会 - 全文検索でRedmineをさらに活用! #RedmineOsaka - ククログ(2017-08-27)

【1】サポートデスクやITILによるソフトウェア保守の運用作業で、従来のExcelでやっていた頃はいろんな問題が噴出していた。
その内容は、4年前の下記のスライドで既に述べた。

「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」

その問題点は下記に集約されるだろう。

【1-1】突発的な問合せ、障害が発生すると、作業が混乱する
【1-2】問合せから、暫定対応や根本的な是正対応への作業連携が悪い
【1-3】問合せ対応や障害対応のナレッジが蓄積されない

そして、Redmineを導入すると、それら問題のほとんどは解決されることは資料で既に述べた。

そこで、Redmine大阪で前田剛さんや須藤さんの講演を聞きながら、Redmineの最新バージョンに盛り込まれた新機能や全文検索プラグインを使うと、上記の問題から出てきた課題は、かなりいい感じで解決されるように思う。

【2】突発的な問合せ、障害に対する暫定対応・根本的な是正対応への作業連携は、基本はすべてチケット化することでほぼ解決できる。
さらに、Redmineの最新バージョンの機能、いくつかのプラグインがより使いやすくしてくれる。
いくつかあげてみる。

【2-1】テキストエリアのカスタムフィールドのワイド表示を設定すれば、チケット入力画面で、障害原因や対策内容のエリアを広くできるので入力しやすくなる。
オペレータやプログラマも入力してくれるようになるだろう。

Redmine 3.4 新機能紹介 Patch #21705: 「長いテキスト」形式カスタムフィールドの「ワイド表示」オプション| Redmine.JP Blog

【2-2】ヘルプデスクPJでは、デフォルト担当者=オペレータのユーザグループに設定しておけば、問合せチケットを顧客が入力した時に担当者にデフォルト担当者が設定され、オペレータ全員に通知される。
その結果、顧客の問合せを見失った、という状況を減らせるだろう。

Redmine 3.4 新機能紹介 (2/5) Feature #482: プロジェクトごとにデフォルトの担当者を設定 | Redmine.JP Blog

【2-3】個人的には、ヘルプデスク管理や障害管理では、IssueTemplateプラグインは必須と思う。
なぜなら、たくさんのカスタムフィールドに入力させる運用よりも、説明欄一つに数多くの情報を入力する方が、入力者にとっては楽だし、説明欄に大量の情報があれば、全文検索プラグインの対象範囲が広がるので、有用な情報を検索しやすくなるから。

akiko-pusu/redmine_issue_templates: Repository for Redmine Issue Template (Ready to move Repository from Bitbucket to GitHub)

Redmineで高速に全文検索する方法 - ククログ(2016-04-11)

【2-4】チケット一覧に「更新者」「最終更新者」「最新コメント」を検索・表示できるようになった。
この機能を使えば、たとえば、最終更新者が顧客になっているチケットはオペレータが未対応なので即対応すべき、と分かる。
他に、チケット一覧で最新コメントを見れば、どこまで対応したのか、が一目で分かる。
オペレータ向けにクエリを作っておくと良いだろう。

Redmine 3.4 新機能紹介 (2/5) Feature #17720: チケットのフィルタに「更新者」「最終更新者」を追加| Redmine.JP Blog

Redmine 3.4 新機能紹介 (2/5) Feature #6375: チケット一覧に「最終更新者」を表示 | Redmine.JP Blog

Redmine 3.4 新機能紹介 (2/5) Patch #1474: チケット一覧で最新の注記を表示 | Redmine.JP Blog

【2-5】チケットの添付ファイル名称を検索できるので、顧客がこんな感じのファイルを添付したんですけど、みたいな時に役立つ。
やはり、エビデンスがないと対応しにくいから。

Redmine 3.4 新機能紹介 (2/5) Feature #2783: 新たなチケットのフィルタ「ファイル」 | Redmine.JP Blog

【2-6】オペレータやプログラマには、実績工数はチケットに付けて欲しいと管理者サイドでは思う。
チケットに実績工数があれば、集計された数値を元に、いろいろ分析できるから。

最新バージョンでは、チケット一覧の実績工数のリンクを押すと、工数明細が表示されるようになったので、ドリルダウンできるのは嬉しい。
なぜこのチケットはこんなに工数が多いのか、調べる時に役立ちそう。

Redmine 3.4 新機能紹介 (2/5) Patch #24649: チケット一覧の「作業時間」「合計作業時間」をクリックすると作業時間の一覧を表示 | Redmine.JP Blog

【2-7】サポートデスク用PJでは、チケット管理を顧客とオペレータが共有するが、社内タスクや作業連携用チケットは顧客に見せたくない場合がある。
そんな場合、管理画面で、トラッカーに対するロールベースの権限制御を行えば良い。

Redmine 3.3新機能紹介: トラッカーに対するロールベースの権限制御(チケットの閲覧/追加/編集/削除/注記の追加) | Redmine.JP Blog

たとえば、「問合せ」チケットは顧客もオペレータも参照・更新できるが、「社内用タスク」「社内向け課題」のように社内の開発部隊とやり取りするようなチケットは、顧客に見せないように設定できる。

以前は、社内向けタスク等のチケットはサブプロジェクトに登録する運用にするなど、一手間かかるのが面倒だった。
しかし、この機能を使えば、1個のプロジェクトで、顧客が見えるチケットと見えないチケットを細かく設定できるので、オペレータは何も気にせず起票すればいいから、チケット入力が楽になる。
顧客に見えるトラッカーは限定されているからだ。

【2-8】PJ設定画面で「新しいチケット作成時のデフォルトの対象バージョン」を設定できるようになった。
この機能を使って、デフォルト対象バージョンを「バックログ」に設定しておけば、顧客が問合せチケットを起票した時に、バックログに自動設定されるので、オペレータは対象バージョン=バックログのチケットを優先的に対応すればいい。

Redmine 3.2.0 リリース | Redmine.JP Blog

Feature #1828: Default target version for new issues - Redmine

サポートデスク管理でも、対象バージョン=対応すべき納期で運用すれば、どの期日までにどの問い合わせチケットを優先すべきか、ロードマップ画面で判別しやすくなる。
また、対象バージョン=バックログの問い合わせチケットは、問合せの未対応の貯蔵庫と見なせるので、選択しやすくなるだろう。
問い合わせチケットはただでさえ、たくさん発生して、チケット一覧に埋もれてしまいがちだからだ。

【3】さらに、全文検索プラグインを追加すれば、過去の問合せや障害の履歴をランク付けして検索できる。
有用な情報がスコア表示されるので、Redmineに問合せや障害の情報が蓄積されるほど、価値あるシステムになるだろう。
つまり、全文検索プラグインはRedmineをナレッジシステムに進化させてくれる可能性を秘めていると思う。

また、須藤さんの発表資料のように、全文検索プラグインは数多くの可能性を秘めている。
たとえば、類似Issue機能、入力補完などの機能だ。

これらは、GoogleAdsenceやAmazonの関連商品表示のように、あなたが入力したチケットは過去のこのチケットに似てませんか?とRedmineが教えてくれるわけだ。
特に、チームに新規加入したメンバーは、問い合わせ対応や障害対応を知らないはずだから、システムが自動支援してくれる機能は非常に有効だろうと思う。

また、Google日本語入力みたいに、チケット入力時に、Redmineが単語を入力補完してくれるとありがたいはずだ。
特に日本語は同音異義語がすごく多いので、表記揺れや類義語があるだけでも、検索にヒットしない場合があるからだ。
たとえば、「打合せ」「打ち合わせ」で検索した時に、いずれも検索結果に表示されると嬉しくないだろうか。

neta@世界は私のオイスターさんのツイート: "#RedmineOsaka 表記ぶれ吸収は日本人 Redmine ユーザはみんなほしいでしょ"

サポートデスクのオペレータの観点では、入力時にあまり神経を尖らせることなく、簡単に入力できて検索できる方がありがたいはずだから。

つまり、Redmineに機械学習や人工知能の機能を追加することで、Redmineに蓄積されたデータを有効活用できるはずだし、本来のナレッジシステムに進化させることができるはずだ。
すなわち、このプラグイン実装の背景を考えると、昨今流行している機械学習や人工知能の技術をRedmineに簡単に適用できる事実を示唆している。
Redmineの未来にとって、とても興味深いだろうと思う。

たとえば、Microsoftが提唱する「働き方AI」みたいに、Redmineを使って、オペレータの業務を効率化することで、昨今の働き方改革の時流に乗り、AIを使って賢く働きましょう、みたいなことも、Redmineで実現できないだろうか?

働き方を自ら改革、機械学習とAIを活用するマイクロソフトの「Office Delve」と「MyAnalytics」 - クラウド Watch

マイクロソフトOffice365にAI機能「MyAnalytics」、これからは働き方をAIに聞く時代になるの? | ロボスタ

【4】以上のようなことを考えてみると、Redmineというツールは非常に面白いな、と思う。
世界中のユーザが使い込んでいくうちに、こういう使い方ができればいいな、という改善要望が1つずつ実現されることで、新たな使い道が発見され、そのアイデアに触発されて、さらに別の新たな使い方が見いだせる。

サポートデスク管理のように、Redmineが生まれる前からずっと存在している業務でも、Redmineのように、かゆいところに手が届くUIを提供してくれるツールが、サポートデスクをより効率化してくれる。
こういう細かな機能改善が、数多くの人たちが業務に触る時間を短縮し、本来の作業に注力できる環境を提供してくれるから。

そういうRedmineのバージョンアップの歴史を振り返ると、今後も期待できるし、それら最新機能をどの業務にどのように使えば効果的なのか、を考えることがとても楽しくなる、と思っている。

| | コメント (0)

2017/08/27

第17回Redmine大阪の感想 #redmineosaka

昨日開催された第17回Redmine大阪の感想をラフなメモ。
疲れているので書きかけ。

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

Redmine大阪 第17回勉強会「Redmineの全文検索エンジンとRedmine3.4.0の徹底解説!」#redmineosaka - Togetterまとめ

【勉強会メモ】Redmine大阪 第17回勉強会 - radioc@?

Redmine大阪 第17回勉強会 LT発表内容(足羽川永都(エイト)) - カクヨム

Redmine大阪 第17回勉強会 - 全文検索でRedmineをさらに活用! #RedmineOsaka - ククログ(2017-08-27)

「Redmine大阪 第17回勉強会」で弊社代表の前田が新機能を活用した便利な使い方について発表 - ファーエンドテクノロジー株式会社

【1】今回の勉強会のテーマは「Redmineの全文検索エンジンとRedmine3.4.0の徹底解説!」

@g_maedaさんの講演を聞いて、Ver3.x以降、Redmineはサポートデスク向け機能がすごく充実しているように思えた。
たとえば、管理画面で「ロールごとのトラッカーの参照更新制御」を使えば、1個のプロジェクトで顧客と社内担当者がチケットを共有している時、お客に見せないトラッカーを指定することで、チケット管理できる。

他に、最終更新者のフィルタを使えば、顧客が最終更新してレスしていないチケットを抽出できる。

つまり、Redmineの最新機能をより深く理解することで、Redmineの新たな機能をサポートデスクの業務にフィットギャップ分析すれば、かなりの範囲をカバーできるだろう。
そうすれば、サポートデスク業務は、Redmineでほとんどカバーできるだろうし、Redmineの痒くて使いやすい機能によって、業務を効率化することができるだろう。

Redmineの最新機能を、どの業務のどのユースケースに使用すべきか、を考えるのは、とても楽しい。
Redmineによる新しい利用方法が、業務をITによりフィットさせてくれるからだ。
その感覚はパズルに似ている。

【2】須藤さん、赤羽根さんの講演を聞いて、Redmineをナレッジシステムにするには全文検索の機能強化が重要であると改めて認識した。

5月の東京Redmine勉強会当時よりも、全文検索プラグインはさらに機能強化されて、性能もより強化されたらしい。
また、現在実装中だが、類似Issueの画面キャプチャの紹介があり、興味がそそられた。
つまり、入力したチケットを開くと、説明欄の下部に、類似した過去のチケットが数件表示されるらしい。

この機能は面白い。
Amazonの関連商品表示、GoogleAdsenceと同じように、あなたのチケットはこのチケットに似てませんか?とRedmineが示唆してくれるわけだ。
たとえば、似たような障害修正、似たような問合せのチケットが表示されるので、チームに加入したばかりの人にとっては、とても参考になるはずだ。

さらに、@sakaba37さんが言われるように、担当者ごとの傾向も表示できれば、プロセス改善に役立てることができるだろう。
たとえば、障害チケットを起票したら、最近、あなたは異常系のバグが多くないですか?気を付けましょう、みたいにRedmineがサジェストする、とか。

akipiiさんのツイート: "#RedmineOsaka RT @sakaba37: 類似チケットが気になった。担当者でもヒットするなら、パグの傾向が分かるかも。 https://t.co/pOGlpByw21"

すなわち、全文検索エンジンによって、Redmineに蓄積された障害・問合せ・仕様変更の履歴をデータマイニングして価値ある情報を抽出して、ユーザにフィードバックできる可能性がある。
さらに、機械学習や人工知能などの最近のライブラリを適用すれば、類似Issue機能をより強化できるだろう。

akipiiさんのツイート: "Redmineに機械学習や人工知能を適用する事で更なる効果を目指す野心的な事例。 RT @ktou: Redmine大阪 第17回勉強会での資料です! - 全文検索でRedmineをさらに活用! - https://t.co/kdERFEYVvY #RedmineOsaka"

但し、1点気になったのは、Redmineのチケット枚数が少なすぎる場合、サジェストできるデータが少ないために、精度が低くなり、類似Issueやスマートナビのような機能のメリットが出てこないのでは?と思った。

しかし、パネルディスカッションで須藤さんの回答を聞くと、他の社内のRedmineインスタンスのデータを活用したり、ネットに溢れているデータを活用できれば、カバーできるのではないか、と。
つまり、デフォルトのメタデータをあらかじめ持たせておけば、それほどずれないサジェストができ、じきにチケットが蓄積されれば、精度が上がる、というようにできないか、と。

この辺りは考えると色々面白そうだ。

また、赤羽根さんの講演によれば、Redmine3.4+全文検索プラグインによって、Redmineの性能上の弱点はほぼなくなる、とのこと。
全文検索プラグインを入れるメリットは、単純に検索が高速化されるだけでなく、検索結果がスコア表示されて有用な情報が上位に出てくるので、より使いやすくなる、とのこと。

個人的には、Redmineプラグインは日本人が開発したものに限定する方針がいいと思っているので、クリアコードさんの全文検索プラグインもRedmineのVerUpに追随してくれるはずだから、入れてみてもいいと思った。

【追記1】
@akiko_pusuさんの言う通り、「検索が賢ければ、記録した後は安心して忘れることが出来る」のは心理的なメリット。

あきこさんのツイート: "プラグインの組み合わせ確認で初めて試してみました。groonga入れる&エンジン確認するのにちょっと手間取ってしまいましたが、検索が賢くなるのはとても良い!私は忘れっぽいし休んだりが多かったので、検索が賢ければ記録した後は安心して忘れることが出来る。本当に良い気がします。 https://t.co/n2xYyWjMRy"

【追記2】
Redmineが度重なる機能追加で重くなる中で、最新版のRubyやRailsが地味にRedmineの性能改善に貢献している、という重要な指摘があった。

Redmine大阪第17回勉強会に参加した - Basic

(引用開始)
「Redmineチューニングの実際と限界 ~ 200万チケットでもサクサクなRedmineの作り方~ 改訂3版」 (赤羽根州晴さん)

Redmineの管理を専門に担当されていた方の講演。
RubyやRedmineのバージョンの違いによるパフォーマンス測定の結果も紹介されており、「機能が増え続けるRedmineの処理の重さを、RubyやRailsの足回りが地道に改善してカバーしている」状況がよく理解できた。
(引用終了)

【3】他の資料は下記。

| | コメント (0)

2017/08/23

RedmineでExcelの概要スケジュールを表示する方法

RedmineでExcelの概要スケジュールを表示する方法が公開されていたのでメモ。
これは面白い。

【元ネタ】
RedmineにExcelBookを表示する(ViewCustomizePlugin) - Qiita

(引用開始)
やろうと思った経緯
良くあるのですが、Redmineでチケット駆動開発をしている中で、上司は、中日程をエクセルで管理して共有しています。

エクセル資料をサーバーに置いて、メールでも添付して資料を見てください。

・・・という事をやっているのですが、
部下はサーバーの資料をあまり見に行ってくれません。

メールに添付した資料も、他のメールに埋もれてしまって、見ようと思いません。

上司も、部下がほとんど見ない資料をメンテする事になるので、そのうちサーバー資料のメンテを放置してしまいます。

結果
Redmineに、サーバーのエクセル資料を表示する様にしました。
チケット画面やガントチャート画面の下にエクセルブックを表示しています。
ViewCustomizePluginの機能で実装しています。

いつも見ているチケット画面に表示されるので、ちょいちょい目に入り、中日程が気になったら、すぐに見られる様になりました。
上司も今までと同様に、サーバー上のエクセルファイルを修正するだけで良いので、情報共有が楽になった様です。
(引用終了)

普通、マネージャは、パワポやExcelで大まかな概要スケジュールを作っている。
その概要スケジュールを共有ファイルサーバーに置いて、皆見てくれ、と言うが、普通は見ない。
そのうち、ファイルパスすら忘れて、概要スケジュールの存在すら忘れてしまう。

なぜなら、マネージャはRedmineを使わず、Excelで仕事をしているが、プログラマはRedmineやGitで仕事しているので、利用場面が違うからだ。
むしろ、Redmineにすべての情報を共有するようにした方がいい。

実際は、概要スケジュールに書かれているマイルストーンの方が重要だ。
たとえば、結合テスト開始日、総合テスト開始日、本番リリース日などをプログラマと共有することで、チケット管理でも配慮してくれるようになるだろう。
しかし、その情報は、Excelやパワポに埋もれている場合が多い。

上記の例では、概要スケジュールのExcelをマクロでExcelbook(HTML)へ変換して、Redmineサーバーにアップして、ViewCustomizeプラグインでチケット一覧やガントチャート画面の下部に表示するようにしている。
この手順を自動化できるならば、マネージャがイメージしている概要スケジュールをプログラマも見てくれる。
マイルストーンを共有できれば、チケットのリズムも生まれやすい。

しかし、残念なことに、運用は上手く回っていないらしい。

(引用開始)
設置したExcelマクロを自動実行させて、
サーバーにあるExcel資料(日程.xlsx)を、html形式で保存する作業を自動処理させます。
これをするには、Excelマクロを起動するPCにExcelがインストールされている必要があります。
結局、これは自分の個人PCから実行する様にしました。

(中略)
・上司は資料をsubversionで管理してくれない。(コミットトリガ設定できない)
などなど。。。

残念。何か良い方法ございましたら、どなたか教えて下さい。。。
(引用終了)

結局、ボトルネックは、マネージャがExcelをきちんと管理してくれないのが原因みたい。
個人的には、マネージャに、FTPアップロード用フォルダに定期的にExcelを配置してもらう運用にするのがいいかな、と思う。
マネージャも技術者でしょ、と。

こういう地味で、泥臭い運用ルールは役立つので集めてみたい。

| | コメント (0)

2017/08/12

Redmineにプロジェクト報告を機能追加するLycheeProjectReportプラグインが面白い

アジャイルウェアさんがLycheeProjectReportプラグインを公開されていた。
デモ画面を見て、色々アイデアが浮かんだのでラフなメモ書き。

【参考】
プロジェクトレポート | Lychee Redmine(ライチレッドマイン)でプロジェクトの見える化を。そして管理ももっと楽にしよう。

Kawabata Mitsuyoshiさんのツイート: "\Lychee Redmine更新のお知らせ/ Lycheeプロジェクトレポートがリリースされました! https://t.co/cbzZSIF03f... https://t.co/y3sdKxncWj"

akipiiさんのツイート: "興味深いプラグイン。経営層向けにRedmine をアピールできるだろう。RT @agilekawabata: Lycheeプロジェクトレポートがリリースされました! https://t.co/iK2E6kOTui... https://t.co/yBsSWACS9h"

門屋 浩文さんのツイート: "@akipii @agilekawabata 精度の高いプロジェクトKPIの決め方についてコンサルが必要になりそう"

akipiiさんのツイート: "@MadoWindahead @agilekawabata どこの会社でも、事業部ごとの目標利益率はあるので、それとの整合性が必要でしょうね。また、経営層のマクロの観点とプロジェクトリーダーのミクロの観点は違うので、どう運用すべきか?面白いネタと思います"

【1】下記の宣伝文言がある。

(引用開始)
Redmineを利用している多くのPMOが、「親子プロジェクトの俯瞰的な確認」「マイルストーンの確認」「進捗・品質・コストの管理」に、頭を悩ませています。
Lycheeプロジェクトレポートは、「複数のプロジェクトの営みを統合管理したい」というPMOの悩みを解決します。
(引用終了)

長年経験してみた結果、Redmineというプロジェクト管理ツールは、現場のチーム向けのツールであり、経営者向けのツールではないと思う。
受託開発プロジェクトでタスク管理を行うと、計画していた当初のタスク以外に、予期しなかったバグや突発的な仕様変更がたくさん湧いてくる。
むしろ、そういう「予定していない」障害管理、「外部環境の変化や顧客要望の変化による」課題管理や仕様変更の管理の方がはるかに重要だ。

よって、Redmineのチケット管理では、細かな粒度でチケットを作っては消していくことが多くなる。
なぜなら、そういうバグ、課題とか、仕様の変更管理は、細かな粒度で発生する時が多いからだ。
あるいは、そういう細かな点まで気配りして、変更管理しなければ、すぐにソース管理でデグレが発生したり、マージ漏れが発生したりするからだ。

つまり、プロジェクトリーダーの観点では、Redmineのチケット管理を通じて、ミクロな観点でプロジェクト管理を運用していく。

【2】一方、部長や事業部長など経営層に近い人の観点では、マクロの観点であり、個別案件のマイクロマネジメントには興味はない。
彼らは、事業部全体で、複数のプロジェクトの進捗や採算の動向を把握したいのであり、個別案件の進捗管理や利益責任はプロジェクトリーダーに任せているからだ。
経営層は、事業部の配下にある複数のプロジェクトの採算全ての責任を負っているので、観点が違う。

すると、経営層としては、各プロジェクトの進捗や品質、採算の観点で毎週、毎月の報告が見たくなる。
つまり、経営層はRedmineの各プロジェクトの現状をまとめたサマリが欲しいのだ。

Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例: プログラマの思索

従来は、このサマリがプロジェクト報告書であり、毎月末にプロジェクトリーダーがExcelの報告書を書くのが習わしだった。
この作業に、プロジェクトリーダーのかなりの管理工数が割かれているはずだ。

プロジェクトの現状は、Redmineチケットに全て蓄積されているが、そのままではプロジェクト報告にはならない。
トラッカー別、日別・月別、ステータス別など数多くの観点でチケット集計し、それらチケットを精査しなくてはならない。
経営層向けに報告するために、数値の正確さはもちろん、報告の文章と数値の整合性が取れていなくてはならないから、結構神経を使う。

しかも、PMOからは、各プロジェクトの進捗状況をお天気マークで表示しろ、とか、進捗や品質の閾値を元に進み具合を報告しろ、などと言われる。
いわゆる、プロジェクト報告の標準化を強いられるわけだが、プロジェクトリーダーの工数をさらに増やすだけ。

そして、実際の案件会議では、各プロジェクトの報告時間は限られるので、労力を使った報告書もさほど読まれないという悪循環があるだろう。

そういう実情を考えると、LycheeProjectReportプラグインのように、Redmineにプロジェクト報告の機能があればいいな、と以前から思っていた。

【3】では、プロジェクト報告に必要な機能は何なのか?

個人的にはいくつかあると思う。
1つは、プロジェクトの現状を指標(KPI)で数値化し、事前に決められた閾値で評価すること。
2つ目は、報告内容が記載できて、報告内容のテンプレート機能があること。
3つ目は、報告の履歴が残せて、それらを一覧で見れること。
最後に、プロジェクトの種類でKPIや閾値を分けて管理できること。

【3-1】プロジェクトの定期報告は、従来はExcelの報告書が多かったと思う。
しかし、経営層が欲しいサマリ情報は、Excelの報告書ではなく、Redmineに蓄積されたチケット情報を元に抽出された指標(KPI)が欲しいはずだからだ。

それらの情報はRedmineから即座にチケット集計でメトリクスを抽出できる。

たとえば、進捗は、全チケットのステータスや進捗率から計算できるだろう。
品質は、障害チケットからステータス別に集計すればいいだろう。
コストは、予定・実績工数が入力されている前提として、工数ベースでEVMを計算すればいいだろう。
その前提であれば、進捗もEVMからSPIで進捗度合いを評価できるだろう。

つまり、プロジェクト報告を保存する時点で、チケット集計するバッチを動かせば、その時点のメトリクスを保存できる。
KPIの採取はシステムによって自動化すれば、プロジェクトリーダーはその数値を参照して、報告内容を書くだけで良い。

毎月報告する運用であれば、毎月末にQCDの観点でKPIが保存されるので、報告の履歴から各KPIの時系列の推移も見れるはずだ。
そうすれば、第三者も、プロジェクトがどこで遅延が発生したか、どこで採算が悪化したのか、を把握しやすくなる。

また、進捗や採算の評価は、プロジェクトリーダー個人の判断ではなく、事業部で決めた閾値でもって判断するようにしたい。
なぜなら、事業部には社長から言い渡された目標売上高、目標利益率があるので、それらをブレイクダウンしたら、各案件の最低の利益ラインは分かるはずだから。

【3-2】また、そのKPIに、プロジェクトリーダーがコメントした報告の文章があると良い。
できれば、報告のテキストエリアには、IssueTemplateプラグインのように、報告テンプレートがあるとなお良いと思う。
なぜなら、各プロジェクトリーダーの報告内容は、記載ルールがなければ、バラバラになってしまい、本来書いて欲しい内容が漏れてしまいがちだからだ。

経営層やPMOの立場としては、QCD(進捗・品質・採算)の観点だけでなく、現状のプロジェクトのリスクや課題は何であるか、懸念事項は何であるか、も報告して欲しい。
普通は、どのプロジェクトも進捗遅延になりがちなので、遅延した原因と対策、今後の動向が知りたいのだ。

そして、彼らとしては、報告内容にある懸念事項の内容から、プロジェクトリーダーのリスク管理能力を見たいのだ。
進捗遅延の状況で、今のプロジェクトリーダーにそのまま任せても大丈夫か?
火を吹いた状況で、今のプロジェクトリーダーには、現状を改善できる能力はあるのか?

報告内容から、プロジェクトリーダーの分析能力、リスク対応能力を推量したいのだ。

LycheeProjectReportプラグインには、そういう報告テンプレート機能はあるのかな?

【3-3】実際の運用では、さらに、プロジェクトの種類ごとに、KPIや評価の閾値も分別して管理したい。
なぜなら、受託の新規開発案件ばかりではなく、定額請求の保守案件もあるだろうし、実費請求の要件定義プロジェクトなど多種多様な案件があるからだ。
特に、保守案件に、新規開発案件のKPIをそのまま適用しても上手く評価できないだろう。

保守案件は普通、毎月の定額請求なので、毎月の検収金額は決まっている。
すると、その案件に張り付くメンバーも固定されていて、彼らの人件費や工数は既に大枠は決まっている。
その予算内で回るように、進捗管理すべきだから。

普通のSIerでは、新規の受託開発案件で1次開発は赤字であっても、2次開発以後や保守案件では黒字化するのが普通なので、そういう保守案件のコスト管理の方が重要だったりする。

したがって、受託開発、保守、請負契約、定額請求、実費請求などの種類に応じた指標や閾値を設定できるようにしたい。
特に、大企業や大きな事業部では、PJの数も多いし種類も様々なので、PJの種類別の指標値の設定管理の機能はすごく重要だろうと思う。

LycheeProjectReportプラグインを見ると、進捗・品質・コストごとに、指標を新規登録できて、閾値も区別できる機能がある。
つまり、そういう観点では、よく考えられていると思う。

【4】第三者の観点で好き勝手に言わせてもらえれば、プロジェクト報告プラグインは、EVMやリソース管理、ガントチャート、信頼度成長曲線などと連動しているとなお良い。
なぜなら、経営層が各プロジェクトのサマリを報告機能で見ていた時、もっと詳細な情報を知りたいと思ったら、EVMやガントチャートを見たくなるからだ。
彼らも、サマリ情報からドリルダウンして、詳細な情報を見たくなるだろうから。

但し、彼らはチケット一覧の画面は見たくないだろう。
なぜなら、チケット一覧を見ても、たくさんのチケットが無造作に蓄積されているだけであり、そこから意味ある情報を読み取るのは面倒だから。
むしろ、EVMやガントチャート、信頼度成長曲線を見た方が、進捗状況や採算状況が分かりやすいから。

つまり、プロジェクト報告の機能は、QCDの観点によるチケット集計の画面と連動している方が使いやすいはず。
たとえば、プロジェクト報告の画面で、報告内容の横にあるKPIの数値にリンクがあり、そのリンクから、EVMやリソース管理、ガントチャート、信頼度成長曲線の画面へ遷移できるといいだろう。

実際、そこまで作り込んでいるかどうか知らないが、色んな可能性を秘めていると思う。

| | コメント (0)

2017/07/26

第17回Redmine大阪勉強会の見所~Redmineをナレッジシステム、そしてプロセス保証のツールへ進化させたい #RedmineOsaka

第17回Redmine大阪勉強会が8/26土で告知された。
見所を公開しておく。

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

Redmine大阪 第17回勉強会の懇親会 - connpass

【1】今回のテーマは「Redmine3.4.0と全文検索エンジンの徹底解説!」。

(引用開始)
2017/7/2にRedmineのメジャーバージョン3.4が無事にリリースされました。
Ver3.4には、Redmineのかゆい所に手が届く機能改善が多数リリースされているので、Redmineを利用できる場面がもっと増える効果があるでしょう。

今回の勉強会では、Redmine3.4.0の徹底解説と、Redmineの全文検索機能を強化することでRedmineをナレッジシステムへ飛躍させる可能性を秘めるお話の二つをメインテーマとして提供します。
Redmineの初心者から、Redmineをバリバリ使う経験者まで、興味のある方はぜひお越しください。
(引用終了)

【2】@g_maedaさんには、Redmine3.4.0の徹底解説やRedmineのVerUp手順、今後のRedmineの展望などを講演して頂く予定。
Ver3.4のメジャーバージョンのリリースに至るまで1年かかったが、リリースされた機能改善の内容は、Redmineの使い勝手を心地よくしてくれるものばかり。
現時点では、Ver3.4.2までリリースされていて、細かなバグはかなり潰されている。

個人的に興味があるのは、次のメジャーバージョン4.0の内容だ。
Ver4.0では、Rails5についに対応する。

今から知っておきたいRails 5の新機能・変更点 - Qiita

ざっくりRailsの各バージョンの流れ - kasei_sanのブログ

Rails5に対応する最大のメリットは、RubyやRailsの最新版に追随することで、Redmineの寿命を長持ちできること。
RedmineはSIにおける事実上の基幹業務システムなので、機能面だけでなく、セキュリティや性能面でも安定運用したい。
幸いなことに、RubyやRailsはVerUpするごとに安定しており、しかも性能アップになっているので、その恩恵をRedmineも受けられる。

個人的に注目する点は、最近流行のシングルページアプリケーションに対応できる点だろう。
最新のWebアプリケーションに慣れた人からは、RedmineのUIは古臭い、とよく言われるが、Rails5に対応することでUIは改善されていくだろうと思う。

但し、RedmineがRails5に対応することで、既存のRedmineプラグインはそのままでは事実上動作しなくなるリスクがある。
日本人のプラグイン開発者は多いので、Ver4にも早めに対応して欲しいなと思う。

akipiiさんのツイート: "ついに来たか!RT @g_maeda: RedmineのtrunkがRails 4.2.8 から 5.1.2 へ移行。 https://t.co/ly5mTOwwde https://t.co/BwoRWZbw4k"

neta@世界は私のオイスターさんのツイート: "@g_maeda @akipii プラグイン大量死の歴史がまた 1ページ ですか?"

【3】@ktohさんは全文検索プラグインのお話、@akahane92さんは全文検索プラグインの性能評価やRedmineのチューニングのお話。
前回の東京Redmine勉強会でも須藤さんに講演して頂いているが、今回は、そのお話に加えて、全文検索プラグインの可能性やそのアーキテクチャの説明もお願いしている。

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

個人的には、全文検索プラグインはRedmineをナレッジシステムにできる可能性を示唆している、優れたプラグインだと思う。

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

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

【3-1】Redmineの運用が数年も経てば、チケット枚数は軽く10万枚を超えるだろう。
50万枚~100万枚ぐらいまでチケットが蓄積されているRedmineもあるのではないか。
すると、デフォルトの全PJ横串の全文検索では応答速度が遅くなるのは知られていた。
(ただし、Ver3.0以後、全文検索は、表示されたPJだけに限定されるようにデフォルト設定されているので、性能悪化は感じない)

Redmineでは、チケットと構成管理ツール配下の成果物に対しトレーサビリティは保証するように運用できるし、Wikiやチケットに各PJの作業履歴、知見は全て蓄積されている。
しかし、Redmineにいくら、障害や課題、仕様変更のチケット、技術情報のWikiを蓄積したとしても、即座に検索できなければ、欲しい情報が取り出せない。
Redmineという一つの箱にデータが集約されているのだから、Redmineのデータを好きな時に好きなだけ検索して、過去の有用な知見を引き出したいのだ。

全文検索プラグインによって、200万チケットでもレスポンスに問題なし、という結果は、今回、@akahane92さんが回答してくれるはず。
つまり、Redmineに全文検索プラグインによる機能追加で、検索の性能要件は問題なくなる。

また、全文検索プラグインでは、Google検索のように、有用なランク別にソートしてくれるので、検索結果にノイズがない。
おそらく、他の検索プラグインよりもかなり使い勝手が良いだろう。

【3-2】さらに、全文検索プラグインで興味を引くのは、入力補完や類似Issue表示、類義語管理などの、Redmineの操作性を向上させる機能を秘めている点だ。

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

Redmineのチケット入力は面倒、という声はよく聞くが、チケット入力時に、Google検索やGoogle日本語入力みたいに、ある程度の文字列を入力したら、コードアシストみたいに文字列を補完してくれてもいいはずだ。
しかも、個別のRedmineに蓄積されたチケットデータを元に、個別のRedmineに応じて入力補完してくれたら、プログラマだけでなく、普通の事務担当者やサポートデスクのオペレータにも優しいシステムになるだろう。

つまり、入力補完によって、チケット内容の単語や表記の揺れが少なくなりデータの精度が上がるし、入力する人にとっても、最初にいくつかの文字を入力するだけで、Redmineが勝手にサポートしてくれると便利なはず。
すなわち、Redmineをナレッジシステムにしていく、という動機づけにもなるはず。

【3-3】そして、最終的には、Redmineがナレッジシステムとして運用できるようになれば、製造業におけるISO9001やISMSなどのシステム監査やサービス監査にも適用できるだろうと思う。
おそらく、日本の企業が最終的に目指したい点はそこにあるだろうと推測するから。

すなわち、Redmineのチケット入力さえ徹底できれば、各PJでは、標準プロセスに基いた成果物は構成管理ツールの配下にあり、プロセスの作業履歴はRedmineに一元化されて蓄積されていて、そのトレーサビリティもRedmineの運用ルールで保証できる。
そうすれば、Redmineに蓄積されたデータ(作業履歴、成果物)に対し、検索するだけで、ランク別に検索結果が表示されているので、監査に必要かつ、有用な情報をいつでも即座に取り出せるようになるはず。

【3-4】さらに、Redmineをナレッジシステムにした場合、プロセスに基づいた作業構造や、プロセスに必要な成果物の一覧を出力したくなる。
プロセスに基いて作られたチケットに対し作業漏れがないか、プロセスに必要な成果物(設計書だけでなくソースも含めて)は漏れていないか、をチェックするために、ツリー構造の一覧を出力して、プロセスの網羅性や完全性を保証したいのだ。

そうすれば、PL法(製造物責任法)に対して、事故が起きたとしても、メーカーはプロセスに基づいて必要十分な作業を行ったので、そこまでのリスクは取る必要はないから、メーカーは無過失責任から免れる、と主張することができるはず。

製造物責任法(PL法)入門

実装方法としては、チケットがWBSと一致しているならば、チケットからPERT図を出力できるし、PERT図にある最下層のWBSは必ず、どれかの成果物に紐づくはず。
Lychee Association Chartがそのイメージに近いが、品質保証部によるシステム監査などの作業に耐えれるレベルまでの機能かどうかは不明。

プロセスフロー図をRedmineチケットで表現するアイデア~Lychee Association Chartで実現できるか: プログラマの思索

チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part3~Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

つまり、Redmineをプロセス保証のツールにまで進化させたい。
現時点では、これらはまだ構想段階に過ぎないが、Redmineの可能性を更に広げてくれるはずと思う。

【4】LTでは、大阪以外の人達の講演があるので楽しみ。

akipiiさんのツイート: "まだ空きがあります。@ktou さん、@g_maeda さん、@akahane92 さんとRedmineの濃い話ができます。@8amjp さんとRedmineファンタジー小説の話もできます。Redmine大阪 第17回勉強会の懇親会 https://t.co/LO1oeglZx4"

| | コメント (0)

より以前の記事一覧