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/10/12

astahを起動せずにJavaScriptで情報を取得する方法

tokudiroさんが、astahを起動せずにJavaScriptで情報を取得する方法を公開されていたのでメモ。

astah APIをjjsを使って楽に呼び出す - Qiita

やり方は、java8 のjavascript 実行エンジンjjsを使って、下記のようなコマンドを実行すればよい。
詳細は上記参照。

jjs.exe -cp astah-api.jar;astah-community.jar openProject.js hoge.js closeProject.js -- fuga.asta

使いたい状況としては、astahファイルからクラス情報などを一括出力したい時、hoge.jsにJSスクリプトで取得プログラムを書いておき、JJSエンジンで実行すればよい。
これは便利だ。

astahにはスクリプトエディタがあり、そこにJavascript、Ruby、Groovyなどを書けば即実行できるが、バッチ出力したい状況も多い。
プログラムは使い慣れたテキストエディタや開発環境の方が書きやすいから。
また、astahのスクリプトエディタではなく、プログラムを別ファイルで保存できるので、バージョン管理もやりやすい。

たぶん、JavaScriptだけでなく、Ruby、Groovyでも、上記と同じようなやり方で実行できるだろうと推測する。

利用シーンは、たとえば、本番稼働中の既存ソース群をastahへリバースして、クラス図などで設計図を書き起こした後、astahAPIでソフトウェアメトリクスを計算するJavaScriptをプログラム化しておき、上記のJJSエンジンでメトリクスを一括出力する、とか。

astahのモデルからソフトウェアメトリクスを出力して、既存のソフトウェア工学の理論を実証実験したい時に有効活用できるような気がする。

| | コメント (0)

astahのシーケンス図をPlantUMLへ変換する方法

astahのシーケンス図をPlantUMLへ変換する方法が公開されていたのでメモ。
これは興味をくすぐる。

【参考】
astah*で描いた図をPlantUMLやmermaid用に変換 | astah in 5 min

Avens666/Astah_Jude_UML_export_to_Markdown-mermaid-Plantuml-: Use Astah JS plugin, export astah diagrams data (such as flowchart, class chart ) to mermaid text fomat and Plantuml format

PlantUML インストール方法 - unhurried

UML図を描画するための単純なテキスト記述を使用したオープンソースのツール。

テキストでUMLを書く - Qiita

【1】手順はこんな感じ。

astahのシーケンス図を開く

astahのスクリプトエディタ起動

Jude_sequence_to_plantuml.jsを貼り付ける

スクリプトエディタからRunで実行

実行結果に、PlantUMLのソース(シーケンス図)が出力される

たとえば、PlantUML Web Serverに、PlantUMLのソースを貼り付けると、シーケンス図が表示される。
これは便利だ。

Jude_sequence_to_plantuml.jsを読むと、astahのシーケンス図の要素をAPIで取得して、PlantUMLの記法にセットしているだけでシンプル。
このやり方を真似れば、PlantUMLのクラス図、ユースケース図、アクティビティ図、コンポーネント図などにも適用できるだろう。

【2】PlantUMLを使いたい場面は、UMLの各種ダイアグラムで基本設計や詳細設計の成果物を作りたい時。

以前は、RationalRose、EnterpriseArchitect、Astahなどの設計ツールか、ExcelやVisioなどのOfficeソフトでお絵描きするのが普通だったが、こういうお絵かきツールはちょっとした仕様変更にすごく弱い。

メソッドが1個増えただけで、レイアウトが大きく変わり、お絵かきの修正にかなりの時間が取られたりする。
お絵かきがしたいのではなく、クラス設計に注力したいのに、実際は、線1本のレイアウトに時間を取られる時の方が多くないだろうか?

また、お絵かきソフトは、バージョン管理が弱いので、修正履歴がない場合が多い。
すると、ちょっとした変更で間違えたので元に戻したい、という作業ができなくなる。

そんな場面では、PlantUMLのように、UMLの各種ダイアグラムもテキストで書いた方が楽。
テキストであれば、Gitでバージョン管理できるので、Undo・Redoがいつでもできるので、試行錯誤しながら、設計することもできる。
バージョン管理の環境がない作業は、UndoやRedoができないので、今何をやっているのか、常にログを残して覚えておく、というプレッシャーが残り、本来の創造的な作業がやりにくいように思う。

但し、ラフなスケッチでお絵描きしたい時もある。
だから、astahで書いてPlantUMLに出力し、その後はPlantUMLのソースを修正していく方が楽かもしれない。

【3】上記のやり方を発展させると、以下のような機能へ発展できないか、と思う。

・astahから、PlantUMLの各種ダイアグラム(クラス図、ユースケース図、シーケンス図等)のソースを出力する
・PlantUMLのソースから、astahへリバースしてダイアグラムを復元する

つまり、astahとPlantUMLで相互にエクスポート・インポートできるようになれば、色んな可能性が出てくると思う。
たとえば、astahでラフなスケッチをしてからPlantUMLに出力して、ソース管理する。
本番稼働中の既存ソースをastahへリバースしてクラス図を作り、PlantUMLへ出力してバージョン管理しておく、とか。

あるいは、PlantUMLからastahへインポートして、さらにastahからJavaやC#のスケルトンクラスを出力する、とか。

プラグイン化できたら面白そう。

【追記】
RedmineにPlantUMLを表示するプラグインは、既に公開されている。
海外の開発者のコメントを見ると、好評らしい。

plantuml - Plugins - Redmine

dkd/plantuml: PlantUML Plugin for Redmine

RedmineでPlantUMLを使う事例: プログラマの思索

Redmine で技術仕様書を書こう | Aiming 開発者ブログ

| | コメント (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)

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