コミュニティ

2017/02/05

第53回IT勉強宴会「深層学習の概要とドメインモデル」の感想

第53回IT勉強宴会で、能見さんの「深層学習の概要とドメインモデル」を聞いてきた。
すごくワクワクして、面白かった。
自分は初心者なので、理解できたことをラフなメモ書き。
間違っていたら後で直す。

【参考】
深層学習の概要とドメインモデル<第53回IT勉強宴会> : ATND

深層学習の概要とドメインモデル<第53回IT勉強宴会> | IT勉強宴会blog

【1】昔流行したニューラルネットワーク理論と深層学習の深い関係

僕の一世代上の人たちから見ると、ニューラルネットワークがすごく流行して冬の時代になったのを知っているので、理論は既に知っているが、本当に使い物になるのか、という思いがあるみたい。

単純パーセプトロンで、0または1に分類するのは、回帰直線による相関分析。
でも、そのままでは当然解けない問題もある。

多層パーセプトロンにすれば、非線形な問題は活性化関数を用いて線形分離できるように変換すればいい。
シグモイド関数が有名だし、それ以外にも色々ある。

多層パーセプトロンのボトルネックは、学習コストを最小化する関数を求める時、真の極小解ではない極小解に落ち込んでしまって、そこから脱出できなくなる点。
誤差逆伝播法で、勾配を少しずつ計算して、誤差をフィードバックして、鞍点にはまらないように学習していく。

でも、過学習の問題も出てくる。
この辺りは、人間が、スポーツや勉強をあるパターンだけで進んでいくと頭打ちになり、いくら努力してもそれ以上伸びない、という症状によく似ている。
他にも、教師あり学習とか、強化学習は子供の躾、ペットの躾に似ているとか、すごくアナロジーしやすい。

そういう時代を過ぎて、2012年に深層学習が画像認識の精度を大きく上げるブレイクスルーが起きて、深層学習が流行し始めた。

講演で最も興味深かった点の一つは、「なぜ、学習の構造はDeep(深層)なのか」。
「なぜディープラーニングが、これほど世の中の多くの問題にうまく適用(特に認識)できるのか?」
「Linの仮説」というものが説明しようとしているが、その理由は、まだ理論として結果は出せていないらしい。

深層学習は 世界をどのように変えられるのか - IBISML

能見さんの「直観的な理解:対象の階層的な構造をうまく取り込めるから」という話を聞くと、人が物事や現象を理解しようとする時、ツリー構造で概念を分解して理解しようとする方法と上手くマッチしているから、と理解している。
たぶん、深層学習の仕組みは、人間の脳の仕組み、人間が物事を考える仕組みの本質に触れているからこそ、プログラムで実装してその威力を発揮できているのだろうと推測する。

【2】深層学習はどこまで知性に近づいているのか

深層学習はニューラルネットワークをプログラムで実現しているので、まさに人の脳の神経回路のシミューレションに近い。
では、深層学習はどこまで人間の知性に近づいているのか?

話を聞く限り、2017年始め時点では、画像認識などの分野で人よりも認識の精度は高いが、全ての分野で置き換えられているわけではない。
まだ知性まで追いついていない。

渡部幸三さんが質問したように、深層学習が画像認識の処理をした後で、「美しさとは何か」という問いに対して、その特徴量、その評価基準が知りたい。
しかし、現時点の深層学習のフレームワークでは、中間パーセプトロンの中身はいちおうトレースできるが、「美しさ」の特徴が何であるか、明示しているわけではない。
深層学習の処理結果として、入力した画像を犬か、猫か、ゴッホの作品なのか、とフィルタリングしているだけ。

深層学習による画像処理において、ある風景写真をゴッホ風にアレンジする、というシミュレーションした絵があって面白かった。
ちょうど、昔のセピア風、プリクラ風の写真の加工に似ている。
では、ゴッホの絵の美しさの特徴は何なのか、と抽象的な概念で言い表して欲しいが、それは明確ではない。

なぜ、美しさの特徴を知りたいのか?
やはり、人間なので、その結果に至る道筋、ロジック、原因が知りたい。
もしそれが完全に判明したとしたら、プラトンのイデア論を立証できることになる気がする。
つまり、美しさの本質はこれこれです、と明確に言えるならば、全ての人の心にはそれが宿っているので、お互いに理解し合えるのだ、というロジックで言いたい。
最終的には哲学の性善説に行き着く気がするが、現時点の深層学習はそこまで人間の心理の本質まで迫っているわけではない。

現在、深層学習をベースとした人工知能の研究は、アメリカと中国で相当激しく進んでいるらしい。
また、東京での人工知能や機械学習の勉強会は、すぐに定員いっぱいになるぐらい人気があるらしい。
今はブームが始まったばかりで、深層学習のどのフレームワークが生き延びて集約されるのか、分からない状態なので、面白いみたい。

| | コメント (0)

2017/01/14

オープンソースのコミュニティの存在意義と知的財産権

OSSコミュニティの継続性の記事がとても素晴らしいので、自分の心の琴線に惹かれた部分だけ引用しておく。
以下、ラフなメモ書き。
特に主張はなし。

【参考】
OSSコミュニティの継続性

ほころびていくコミュニティとなかなかできない世代交代、そしてさよならアドベントカレンダー - Qiita

ゾンビOSSが危ない - [1]オープンソースソフトウエアにも寿命がある:ITpro

【1-1】(引用開始)
日経コンピュータがゾンビOSSと表現した記事を2014年に出している。
ここで根底にあるOSSに対する考え方は「無料で使えるソフトウェア資産」なのだと思う。
それを支える開発者コミュニティへの認知が欠落していて、そこには有用性を見出していないようだ。
(引用終了)

【1-2】(引用開始)
日本では開発者のコミュニティに直接参画しようという動きは少ないように思う。
また、「あるOSSプロジェクトを中心にゆるく連帯した開発者の集団が継続的に存在していること」は、市場における人材育成の点で非常の大きな効果があるという点は、あまり認識されていないように感じる。
(中略)

ソフトウェア技術者の人材流動性が非常に高い米国のような場所では、OSSプロジェクトを開発者資源として活用することで成果をあげている例が多い。
特にうまくOSSを活用しているのはAppleだ。
彼らは社内のビジネスに必要なソフトウェアを、OSSプロジェクトを支援することで得るという手法に長けている。

現在のmacOSの基盤になったRhapsodyが公開されたのは1997年のWWDCだった。Mach 3とFreeBSD 5系のコードを組み合わせてモノリシックカーネルにしたもので、ユーザランドのコンポーネントにもOSSが多く使われていた。現在もツールチェインとしてLLVM/Clangを使う、認証基盤としてHeimdal Kerberosを取り込むなど、開発に非常に大きな労力がかかる部分にOSSプロジェクトの成果を使っている。

また、彼らは単にコードを使うだけでなく、開発者コミュニティにいる開発者を雇用したり金銭的な援助を行なったりして、コミュニティを育てる努力を怠っていない。
OSSプロジェクトが持つソフトウェア資産だけでなく、開発者を資産として認識しているからだ。
差別化が必要な部分は社内で開発し、重要だが開発者コミュニティが存在するソフトウェアはそこに投資することで成果物を利用するという2つの方法のバランスをとって、開発を迅速に進めるとともにコストを低く抑えることに成功したわけだ。
(引用終了)

【1-3】(引用開始)
利用者のコミュニティの継続性は、開発者コミュニティに継続性が前提になっている。
開発者のコミュニティに継続性が欲しいなら、話は単純だ。何らかの形で支援すれば良い。少なくともOSSを理解している個人や企業は、みんなすでにそうしている。
「OSSプロジェクトのソフトウェア資産だけを使い、サポート会社にお金を払う」という関わり方は、開発者コミュニティの継続性に寄与しない。
(引用終了)

日本では、OSSを無料のソフトウェアとみなす考え方が強い。
だから、保守サポートを受けたければ、サポートのある会社に有償でお願いしたほうが安全だ、という方向へ行きやすい。
保守契約や請負契約を結べば、リスクを業者に転嫁できるから。

一方、AppleがOSSとOSSコミュニティを上手く利用している、という意見はとても参考になる。
OSSは単なる無料のツールではなく、優秀な開発者資源の集まりである、という考え方がある。
OSSコミュニティにいる優秀な開発者は、重要な資産なのだ。

コミッタを雇用することで、優秀な開発者を自社に取り込むこともできる。
コミッタを金銭的に援助することで、OSSのツールの継続性を後押しできる。

一点気になるのは、ベンダーという営利企業のステークホルダーがOSSコミュニティに関わることで、OSSの発展の方向性がベンダーの意のままになるリスクは無いのか、という点だ。
詳細は知らないが、Linuxのように、多数のベンダーが入り込んでいるOSSでは、そのようなリスクをどのように排除して、Linuxを発展させようとしているのか、調べてみたい。

【2】オープンソースに関わる内容として、もう一つ気になる点は、知的財産権との絡みだ。
オープンソースのライセンスはGNUが有名でよく使われている。
すると、営利企業のソースライセンスとオープンソースのライセンスの違いが気になってくる。

この辺りの情報もまとめたい。

【3】IT技術者にとって、オープンソースのコミュニティに関わるメリットは、とても大きいと感じている。
製造業の技術者に比べると、IT技術者は、アイデアや成果物の利用について、とても自由度が高い。
その分、活発な活動が行われている、と感じる。

技術士として、他の製造業の話を聞くと、メーカーの技術者は自分の能力をアピールする場が少ないと感じる。
彼らは、論文発表するか、特許や意匠、商標などの知的財産権を取得するか、どちらかを採用している。

特許を取れば、普通は職務発明になるから、会社が専用実施権を持つ場合が多いように見える。
会社の戦略としては、ライセンス戦略になる。
つまり、自分たちの技術を他者が使う場合、ライセンス供与によってライセンス料を得るわけだ。

メーカー技術者は、代わりに「相当の利益」として、金銭やストックオプションとか、他のもので代用する。
しかし、それは嬉しいのだろうか?
自分のアイデア、自分が作った成果物と実質上は言えるが、外向けには会社の知的財産権であり、公の場で詳細な技術の議論はしにくいはずだ。
その代わりに、学会で論文発表することで、意見交換しているみたい。

一方、特許ではなく営業秘密として技術を保持するとなると、公開不可になる。
不正競争防止法で規制される対象になる。
すると、自分のアイデア、自分の成果物を世の中に公表することすら認められない。
会社の戦略としては、いわゆるブラックボックス戦略を取るわけだ。
たとえば、コカ・コーラ、天一など。

技術者にとって、お金も重要だろうが、むしろ、自分のアイデアを世に出して、色んな人達のフィードバックを得たり、技術者と知的議論をしていく方が重要だ、と思うはずだ。
そうでなければ、一発ものの技術で終わってしまうから。

でも、メーカーの技術者は、特許や営業秘密というツールで自分のアイデアや成果物が縛られやすい。
何となく可哀想な気もする。

一方、IT技術者はオープンソースで、自分の成果物を公開することで、他ユーザのフィードバックを得たり、他の技術者からプルリクエストで改善要望をもらえたり、自分の能力をアピールできたりする。
つまり、IT技術者はかなり自由だ。
むしろ、自分の成果物をクローズドにするのはあまり価値がない。
沢山の人に知ってもらい、使ってもらう方が価値が上がる。

「GitHubでソーシャルコーディング」という言葉は、たぶんそんな意味が込められていると思う。

すると、会社の経営戦略としては、プラットフォーム戦略になる。
つまり、ネットワークの経済の概念。
たくさんの人に使ってもらうことで、自分たちの技術をデファクトスタンダード化し、マーケットシェアを上げる。

その戦略を取り続ける場合、Appleの話のように、企業はOSSコミュニティを支援する場合が多くなるのだろう。
OSSコミュニティは、OSS利用者の多いマーケットだけでなく、優秀な開発者という資源がある場所、と捉えるわけだ。
それによって、OSSが長持ちする。

その場合、コミュニティの活発度がOSSが生きている証になる。
普通、ソフトウェアの活発度合いは、バージョンアップの頻度として現れる。
バージョンアップされないソフトウェアは死んだも同じだ。

数多くの利用ユーザのフィードバック、優秀な開発者によるセキュリティパッチや機能改善パッチの迅速なマージなどで、OSSソフトウェアは進化していく。

【4】そんなことを考えてしまったのは、Redmineもそういう意見がチラホラ見受けられるからだ。
Redmineコミュニティもちょっとずつ変わろうとしているのかもしれない。

akipiiさんのツイート: "Mischa The Evilのコメントを読むと、僕も同じような意識を持っている。Redmineはもはや単なる無料のツールではなく、OSSのコミュニティとして大きな影響力を持ち始めている。だからこそ永続的な開発の基盤を求めている。https://t.co/0wmfbPNu4V"

| | コメント (0)

2016/12/06

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

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

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

第11回勉強会 - redmine.tokyo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Feature #2024: gantt chart editing - Redmine

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2016/12/05

AgileTourOsaka2016の感想

AgileTourOsaka2016に行ってきた。
知り合いも多くて居心地の良い場だった。
感想をラフなメモ書き。
メモを殴り書き。

【参考】
Agile Tour Osaka 2016 2016年12月3日 - こくちーずプロ(告知'sプロ)

現場の経験知をパターン言語にするコツが分かった #agileto2014: プログラマの思索

【公開】AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" #agileto2010 #tidd: プログラマの思索

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

【1】パターンの中で「デザインパターン」は最も有名だが、「デザインパターン」の最初に「これはパターン言語ではない」とはっきり述べている。
パターンとパターン言語は違う。

パターン言語は、もっと広い概念。
パターン言語は、全体性が特徴、と原田さんは言う。

【2】Scrumパターンは、「組織パターン」から生まれた。
7年経った今もなお作成中。
来年に完成すればいいね、という感じだね、と。

Scrumパターンを見ると、「防火壁」はスクラムマスター、「顧客の代弁者」がプロダクトオーナー、「ワークキュー」はバックログ、「スタンドアップ・ミーティング」はデイリースクラムという概念が自然に出てくる。
組織パターン」から、プロダクトオーナー、スクラムマスター、プロダクトバックログの概念が生まれた。

Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti’s diary

Scrumパターンは、パターンがつながっていて、一つの言語(ランゲージ)になっている。
つまり、パターン名を言えば、パターンの発生源となる問題や背景が自然に出てきて、人々で共有される。
パターンで問題解決されると、新たな課題が発生し、別のパターンが使われる時もある。

【3】アンチパターンはパターンなのか?
アンチパターンはパターンではない。
アンチパターンはパターンのコンテキストを表すものでしかない、と。

【4】パターンはベストプラクティスではない。
パターンは「Good practice」である、と変えた、と。

【5】パターンの中で、Forceを書くのが一番難しい。
Forceは、パターンの背後にある、利害関係者の力の衝突を表す。
たとえば、プロジェクトが遅延しているから作業方針を変更したいのに、マネージャが駄目だ、と拒否権を発動する場合、とか。
Forceはトレードオフを表す。

だから、パターン、コンテキスト、ソリューションを書くのを勧めている、と原田さんは言う。

この意見には、僕は違和感を持っていて、別の意見を持っている。
むしろ、経験者はForceから書き出した方がいいのではないか、と思っている。

実は、午前のプレセッションで、パターン・ワークショップがあり、Scrum道関西で有名な山本雄一郎さんたちと同じチームで、パターンを洗い出そうとしていた。
すると、僕も山本さんも、いきなりパターン名やソリューションを出したものの、そこから話が進まない。
コンテキストや問題がメンバーの間で違うので、議論が発展せず、深掘りされなかった。
結局、時間切れで、僕らのチームは、パターンを作り出すこともできなかった。

プロジェクト運営の経験があり、何らかの問題に対して自分なりのソリューションを持っている人は、パターン名らしき概念を既に持っている。
そんな場合、パターン名やソリューションを書き出した後、そのソリューションが使われる背景(コンテキスト)や、Forceのような力関係を洗い出し、そこから、もっと他のソリューションがあるのでは?、他の問題が出てくるのでは、という方向へ議論しても良かったのでは、と後で感じた。
なぜなら、自分が持っているソリューションのコンテキストを説明しようとすると、過去の案件ではこんな対立があった、とか、以前のチームではこんな人間関係があって対立していた、と言う内容を説明しやすくなるからだ。
経験者が持っていたリアルな現場感を伝えるために、Forceを使うわけだ。

なお、原田さんからは、もっとパターンを抽象的にしたら、というアドバイスをもらった。
その意味を考えると、ソリューションにこだわりすぎて、パターンというもう一つ上のレベルへ抽象化できなかったのではないか、と思う。

【6】チームでパターンを作った後、どうするか?
チームで、あるノウハウに名前(パターン)が付くと、良い傾向。
チーム内の良い習慣を、パターンで共有できる。

「おやつ神社」と言えば、日本人なら分かるでしょ?
ふりかえりミーティングでは、お菓子を持ち寄り、くつろいだ雰囲気を醸し出す、と。

僕も、チケット駆動開発のプラクティスをパターンとして表現できないか、狙っている。
今、日本各地でRedmineエバンジェリストの役割を担う人達が出現しているので、彼らのノウハウをパターンという名前で具体化して、皆で共有できるようにしたいのだ。

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

つまり、皆がバラバラに持っているノウハウをパターンとして抽出して、パターンカタログのような形式でまとめたい。
パターンはカタログではない、という意見があるのは重々承知だが、ボトムアップで経験知を整理して、誰もが共有できる形式知にしたい。

【7】その意味では、欧米人はネーミングが上手い。
同じような概念を時代に合わせて再パッケージングして、いかにも新しい流行のようなワードを作り出し、世の中に広めている。
アジャイル開発やXPのプラクティスは以前から知っていた、と日本の年上の技術者は誰もが言うが、僕ら若手はそんな技術はつゆ知らず、むしろ、アジャイル開発やXPを知って、すごく興奮した。

似たような例はたくさんある。
日本の製造業の品質管理(TQM)に対するシックスシグマ、トヨタ生産方式に対するリーン生産方式、ソフトウェア再利用の設計に対するマイクロサービスアーキテクチャ、とか。

日本から独自のパターンを生み出せないか?

【8】長沢さんに、エバンジェリストはどんな役割なのか、を聞いた。
彼の回答は明確で、「エバンジェリストは市場を作る人である」と。
僕のイメージは、エバンジェリストはツールや製品を宣伝する人と思っていたから、その固定観念を打ち砕かされて、しびれた。

また、キャズム理論や製品プロダクトライフサイクル理論では、市場の立上げ・成長期・成熟期・衰退期に応じて、イノベータ、アーリーアダープター、マジョリティ、ラガードなどの市場参加者の種類がある。
その中で、エバンジェリストは新しい製品を市場に導入して、パイを広げるべきと思っていたから、イノベータやアーリーアダープターに専念すべきと思っていた。

しかし、長沢さんによれば、エバンジェリストは市場の全体の人達にフォーカスする。
特定の人達にフォーカスするのではない、もっと広い層の人達に伝えるべき、と。

さらに、ツールや製品にこだわるべきではない。
一段上のレベルで話をすべきである。
ツールや製品は流行り廃りがある。

エバンジェリストは新しい技術の動向を伝えるだけでなく、それによって市場を拡大するように、方向性を示すべき、と。
だから、自分は、マイクロソフトやアトラシアンの製品だけにこだわってはいない、アジャイルやプロセスの話をしている。
RUPの頃から何も変わっていない、RUPにも既にアジャイルやDevOpsの萌芽はあった、と。

| | コメント (0)

2016/11/27

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RedmineMigrate - Redmine

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【今日の資料はコチラ】

| | コメント (2)

2016/11/20

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

11/26土に開催される第11回東京Redmine勉強会の見所についてメモ。

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

redmine.tokyo 第11回勉強会 - connpass

【1】10月下旬にこっそり告知したら、あっという間に満員御礼になりました。
いつもながら東京では、Redmineユーザが多い事実を感じます。

【2】今回の勉強会の主なテーマは「Redmineの「多用」性とその進化」です。
テーマに関しては、スタッフ内で議論が色々ありました。

【2-1】Redmineや「チケット駆動」という概念が日本ではかなり普及しています。
実際の現場では、IT業界だけでなく、多方面の業界で、色んな職種を持つ人達がRedmineを利用している。

すると、本来のタスク管理という使い方だけでなく、インシデント管理やヘルプデスクのサポートなどにも使われていて、色んな問題点や課題が発生している。
そこで、「どんな使われ方がされているのか?」という観点で、@kazuphさんのIOT企業の事例、@mattaniさんの簡易CRM利用事例の講演を用意しました。

個人的には、@kazuphさんのIOT企業の事例はとても興味があります。
以前Blogで紹介しました。

「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしい: プログラマの思索

Blogの内容を読むと、ポイントは、ハード部隊やソフト部隊、カスタマーサポートのような気質も技能も異なるチーム間連携にRedmineが有効であった、という点でしょう。
利用ユーザが増えて、利用する組織が増えると、チームごとの組織文化も異なってきます。

その場合、そういうチームと作業や情報を連携して、いかにシナジー効果を生み出すか?
そして、どのような開発基盤や運用ルールがあれば、スムーズにチーム間連携ができて、1+1=3のようなシナジー効果を発揮できるのか?

また、「導入にはRedmineエバンジェリストみたいな人が必要」という指摘も興味深い点です。
Redmine特有の癖をいかに生かすのか、あるいは、組織にマッチさせたのか?

実際の現場でRedmineを運用して駆使されているだけに、その経験談を聞いてみたい所です。

【2-2】大規模な組織へRedmineの運用を拡大した時、どのような問題点や課題が出てくるのか?という問題意識から、今年は大阪と東京で過去3回のRedmine勉強会がありました。

第14回RxTStudy勉強会「Redmineの未来を考える - 機能・運用・コミュニティ」の感想 #RxTStudy: プログラマの思索

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

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

Redmineと組織構造の関係性については、第15回RxTstudy 『大規模組織や 多様な業務における Redmineの課題』で発表しましたが、他の課題もあります。

スタッフからあがったテーマは「Redmineのバージョンアップやデータ移行で留意点はあるか」という点です。
Redmineも誕生してから既に10年経ち、Redmineを運用している現場でも3~8年くらい使っているところもあるでしょう。

たとえば、当初は3人で使っていたRedmineが100人以上に使われて、SIの現場で勤務時間中はフル稼働している状況になると、バージョンアップ作業や保守作業がやりにくくなってきます。
特に、バージョンアップやデータ移行作業は、RedmineがSIの事実上の基幹業務システムになった状態では非常に神経質にならざるをえないでしょう。

その場合、どんな点に留意して、バージョンアップやデータ移行をすべきなのか?

ファーエンドテクノロジーの@g_maedaさんにRedmineバージョンアップの注意点、アジャイルウェアの堂端さんに「乱立してるRedmineを一つにまとめる話」について講演してもらいます。

特に、「乱立してるRedmineを一つにまとめる話」の内容は、十数個のRedmineインスタンスが部署ごとに別々に存在していたが、プロセス標準化の機運が盛り上がって、1個のRedmineインスタンスに統合した時の経緯と苦労話になります。
データ移行をどこまで行なっているのかは聞いていませんが、各部署のRedmineインスタンスのワークフローを抽出し、社内の標準ワークフローを策定する方向に持っていった、と聞いています。

Redmineのデータ移行と言えば、奈良さんの講演「Redmineサーバ統合事例」が真っ先に思い出されますが、単純なデータ移行だけでなく、標準プロセスの策定作業に、Redmineのワークフローデータが使われたこと、その標準プロセスがトップダウンではなく、散在したRedmineから抽出してボトムアップに作っていった、という点が面白いのだろうと思います。

【2-3】また、「Unofficial Redmine Cooking」というプロジェクトを開始して、東京Redmine勉強会のスタッフやユーザを中心に、Redmineの改善要望やパッチの情報を交換しよう、という要望もスタッフからあがりました。

たとえば、Redmineユーザメーリングリストでも、Redmineの画面UIの改善要望が非常に多いです。
Redmine利用者が増えてきたので、現場ごとにRedmineをもっと使いやすくしたい、という声が多く上がっているのでしょう。

そういう質問を実際にやり取りできる場を設けて、Redmine本家に情報提供ができたらいいな、と思います。

Redmine Users (japanese) - Google グループ

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

【3】他にも、最近公開されたRedmineのサービス「Planio」の紹介、会場を提供して頂いたテクマトリクス様における「RedmineとElectronで新人の育成状況を可視化した事例」などがあります。

さらに、@ryouma_nagareさんのLT「開発環境の認証を改善してRedmineを社内標準にした話」は、RedmineのLDAP設定に関する話なので、とても興味があります。
Redmineのログイン認証を社内のLDAPサーバーと連携させることで、Redmineユーザ管理や保守をかなり楽に出来ます。
実際、Redmineを外部に公開している場合、退職したユーザをRedmineから削除する運用作業は、ユーザ数が増えるほど非常に面倒になってくるので、LDAP認証をかませれば、LDAPサーバーの方でユーザ管理してもらい、その情報を同期するだけでいい。

しかし、実際に運用した人の話を聞くと、色んな留意点やノウハウがあります。

たとえば、ユーザが退職した場合、Redmineユーザに登録されたメーリングリストのメールアドレスから削除しないと、通知に失敗する。
たとえば、自社の社員のLDAPサーバーと協力会社の常駐メンバーのLDAPサーバーが異なる場合、どのように設定して注意すべきか?
実際、Redmine本家にも下記チケットで要望が上がっているが未対応のまま。

Feature #9216: Support of multiple LDAP servers for authorization - Redmine

この辺りのノウハウも、もっと聞いてみたい。

【4】講演LTを含めては10本近くあって盛りだくさんですが、グループディスカッションの場ももうけています。
テーブルごとにざっくばらんに話してみながら、お互いの苦労話や知見、ノウハウを情報交換してもらえればと思います。

【追記】そういえば、「入門Redmine第5版」が公開されていました。
出版日は2016/12/1だそうです。
作者の@g_maedaさんも来られるので、もしかしたら、最新の出版の状況も披露してくれるかもしれません。
お楽しみに。


| | コメント (0)

2016/07/31

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

JAXAのRedmine利用事例に関する講演会が無事に終了。
多数の参加者の皆さんも満足できたと思います。
スタッフとしても、講演者と参加者の方に感謝です。
ラフなメモ書き。

【参考】
第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

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

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

第65回 SEA関西プロセス分科会&RxTStudy15 「チケット管理システムによるプロセス支援と今後の課題」 #RxTStudy - 日々の御伽噺

MAEDA, Goさんのツイート: "JAXAのRedmine利用事例の論文( https://t.co/xcay83LGeB )の英語訳が公開されています。 https://t.co/3pt5OnnPXe"

【1】JAXA様のRedmine利用事例の講演では、実際の画面の一部も見せてもらうことができて、JAXAの運用ルールが非常に理解できた。
JAXAの動機としては、マネージャの観点では、経営層に、投資対効果のメリットをアピールするために、Redmineでデータを収集して、定量データを報告したい、ということがあったらしい。

だから、カスタムフィールドを増やして、カスタムフィールドで集計しやすくする運用は必須だった。
しかし、ワークフローを複雑にしたくなかったので、トラッカーとロールを増やさないようにしたかった。
そこで、ロール設定のORルールやカスタムフィールドのANDルールを生み出した、と。

僕の疑問は、カスタムフィールドを増やしたがるのはマネージャの観点であり、入力項目が多いと億劫になりがち。
そのようなデメリットはないかと思ったが、JAXAの回答としては、過去のお手製BTSでは、入力項目がテキストボックスでデータの揺らぎがあり、集計しづらかった。
だから、Redmineのカスタムフィールドで入力項目の書式を定型化して、集計しやすくするルールは必須だった。

また、カスタムフィールドのANDルールによって、各プロジェクトごとにカスタムフィールドのON/OFFを制御しているので、ユーザにとっては必要なカスタムフィールドしか表示されていないので、あまり気にならないメリットもあると理解できた。

【2】パネルディスカッションでは、ISO9001やIT内部統制をRedmineで実現して、実際にコストを削減できるか、という点も質問してみた。
ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデア: プログラマの思索にも書いたけれど、日本のメーカーではISO9001の導入は必須の会社が多い。
しかし、ISO9001のプロセスが重荷になり、逆にコスト増になっているのではないか、という現状が多いのではないか。

JAXAの回答では、ISO9001をRedmineで運用するのはうまく回っている。
ISO9001は指針をしめしているだけであり、QMSの実装は現場ごとに実現して良い。
ISO9001やQMSの目的を十分に理解できていれば、その手段をRedmineで実現してもいいし、実際にそれで運用を上手く回す事ができる、と。
逆に、そんな質問は、ISO9001の目的と手段を取り違えて運用しているのではないか、という指摘を頂いた笑。

僕の感触としては、RedmineでISO9001で運用する場合の課題は、チケットの全文検索と、証憑などのエビデンスというOfficeファイルのファイル検索にあると思っている。
監査の時に、必要な情報をRedmineの全文検索からチケットを抽出できるか、その証憑となるExcelファイルを共有ファイルサーバーから取り出せるのか。

JAXAの方や@akahane92さんの話を聞くと、Redmineチケットに情報を集約し、チケットの関連付けや構成管理ツールのリポジトリ連携によって、トレーサビリティは実現できるし、検索もできる。
また、JAXAの運用では、DMSFプラグインを入れることで、ファイル検索と必要な情報の分類もできている、とのこと。
たしかに、DMSFプラグインでその課題はクリアしているわけだ。

【3】僕の発表資料「大規模組織や多様な業務におけるRedmineの課題」では、僕が理解しているJAXAの運用ルールの紹介と、組織構造がRedmineに与える影響事例としてPJ分割ルールについて話してみた。
JAXA運用ルールの噛み砕いた紹介は、参考になったという声があって、良かった。
また、機能別組織・事業部制組織・PJ型組織・マトリクス型組織という4つの組織構造に対し、Redmineが有効に使える部分の提示、そして、Redmineプロジェクトと組織構造の関連の説明も、一部の人にとっては、すごく参考になった、という声も聞いて、作った甲斐があった。

個人的には、組織構造がプロセスやツールに影響を大きく与えているのは確かだし、日本では、自社の組織構造や組織のルールに、プロセスやツールを従わせるようにしたい欲求が強い。
そういう状況において、Redmineの機能の柔軟さ、豊富さがメリットになっている部分を感じている。

【4】他の資料はコチラ。

| | コメント (0)

2016/07/16

Redmineコミュニティに関わる動きのメモ

本日、東京でRedmine生誕10周年記念パーティが開催されたらしい。
僕は参加できなかったが、謎のフランス人コミッタJPLのショートビデオメッセージもあったらしく、JPLはイケメン、という声も上がったらしい笑。
最近のRedmineコミュニティに関するリンクと考えていることをラフなメモ。

【参考】
「Redmine 10周年を祝う会」 松江・大阪・東京で企画 | Redmine.JP Blog

Redmine生誕10周年記念パーティ - redmine.tokyo

akipiiさんのツイート: "日本人が貢献できて良かった。RT @netazone: Redmine作者のJPLからのメッセージ。Toshi と Go に感謝といっている #redmineT https://t.co/meoUBSkZn0"

akipiiさんのツイート: "Redmine コミッタJPLはイケメンではないか、と女性スタッフの意見もあり笑。RT @glad2121: Redmine 10周年を祝う会@東京。 (@ ANTHEM) https://t.co/gvQug6kyoG https://t.co/55l9NkRiQv"

akipiiさんのツイート: "@netazone JPLもRedmine の次の大きな課題はRails5対応と考えているのか。確かにテストコードの整備も、考えれば大変だろうが、今までの歴史を振り返れば必ず達成できるだろう。"

redmine.tokyoさんのツイート: "#Redmine 生誕10周年記念パーティを昨日実施いたしました。Redmine作者のJPLからのビデオメッセージをいただくことができ、参加者の皆さまには楽しんでいただけたと思います。... https://t.co/bjKA4EKKsZ"

【1】Redmine作者JPLからのメッセージの本文を読むと、彼がRedmineに誇りを持っていること、Rubyを学習するためにRedmineを書き始めて10年経つが、今もWonderfulな経験をしているよ、とのこと。

また、特にRubyを生んだ日本と、日本のRedmineコミュニティからのフィードバック、前田剛さんとまるやまさんへの感謝が述べられていた。

次への課題は、まず、Rails5への対応。
そのために、2千もの更新すべきテストケースがあること。
また、RailsのTurbolinksやActionCableを当てはめることで、RedmineのUI/UXをもっと今風に改善したい、とのこと。
Ver3.2でレスポンシブデザインの機能改善が期待されなかったら、RedmineのUIはずっとそのままだっただろう、とのこと。
そこで、JPL自身もRedmineをより良くするための幾つかのアイデアを持っていて、コミュニティとシェアしていきたい、とのこと。

JPLのメッセージ、そして、RedmineがRubyやRailsのVerUPに追随しながら10年も開発が続けられてきたこと、さらに、自動テストやテストカバレッジの充実による安定した品質を考えると、本当に偉業だと思う。

【2】世界でも、最近の日本でも、Redmineを巡る状況が少しずつ変わってきているように思う。
興味を惹くのは、ベンダーの動きだ。

Redmineを作っている人々 (3.3.0編) - ファーエンドテクノロジー株式会社によれば、Ver3.3でリリースされた機能である「+ボタン」「セキュリティ通知」はドイツの会社の開発者が提供したパッチが元になっているらしい。

(引用開始)
存在感があるのがドイツのPlanioです。
Redmineをベースにしたサービスを提供している会社です。
以下の表の通り、6人が21件のパッチを書きました。
カスタマイズしたRedmineを自社サービスとして提供しながらその一部をオープンソースコミュニティにフィードバックするというすばらしい活動をされています。
3.3.0の新機能では +ボタン や セキュリティ通知 もPlanioによるものです。
(引用終了)

Planioというドイツの会社の開発者は、Redmineにレスポンシブデザインのパッチを送ったことでも知られている。
つまり、直近のRedmineのUIや機能改善に重要な貢献を果たしている。

Feature #19097: Responsive layout for mobile devices - Redmine

自社のサービスのRedmineで改造した機能をオープンソースに提供し、それによって、Redmineの全てのユーザに恩恵が受けられた。
自社のRedmineサービスで実績があるのだから、ある程度品質も枯れているだろうし、Redmine本家もパッチ取込にさほどリスクも少なかっただろうと推測する。

【2-1】また、日本でも先日、日本人コミッタをRedmineベンダーが支援するというニュースが流れていた。
Redmineの開発者はボランティアベースで実質3人でしか開発されていない状況を考えると、コミッタへの支援は重要な出来事だと思う。

ホロンテクノロジーとアジャイルウェアのプレスリリースに当社代表取締役 前田のコメント掲載 - ファーエンドテクノロジー株式会社

PRESS RELEASE - アジャイルウェア5期目、Toshi MARUYAMA氏をフェローに迎える

【3】上記の状況が意味していることは、Redmineのユーザ数が増えてきていて、Redmineというマーケットが成長しているという事実だろう。
下記の記事では、日本でMyRedmineを使っているユーザが一部のイノベータやアーリーアダプターのような先端物好きのユーザだけでなく、一般のユーザ層にも使われている事実が示されている。

My Redmine業種別導入実績を公開します - ファーエンドテクノロジー株式会社

最近思うのは、Redmineがソフトウェア開発のタスク管理、つまりチケット駆動開発としての使い方よりも、昔のNotesの代わりのようなBPRツールとして使われる事例が多いように感じることだ。
僕は元々、チケット駆動開発をRedmineで実現することによって、アジャイル開発やソフトウェア工学の可能性を見出し、色んな実験ができることに興味を持っていた。

実際、Redmineを使えば、プロセスのデータは簡単に収集できるので、プロジェクト管理やソフトウェア工学で見出された過去の経験則を検証し、その正しさや限界を調べることが容易にできる。

しかし、Redmineを一般ユーザが使う状況が増えることによって、汎用的な帳票ワークフローシステムとして使われるようになってきていると思う。

実際、見積書や稟議書のような事務処理、インシデント管理やサポートデスクなどでもRedmineが使える。
オープンソースでありながら、Redmineほど、ワークフローや権限制御を細かく設定できるツールは珍しいし、使いこなせれば、かなり強力だ。

すると、一昔前にNotesで、BPRと称して社内の業務を紙の帳票からクラサバに置き換えていった動きと、今のRedmineの普及が重なるように見える。

普通の若い人にとって、ブラウザ上でチケットをやり取りする操作はそんなに難しくないし、慣れれば、使いやすいと思う。
また、Redmineでなくても、チケット管理ツールは、JiraやTrello、PivotalTracker、Backlogなどたくさんあるし、一度チケット管理に慣れれば、どのツールでも同じように使える。

つまり、チケット管理ツールをBPRとして運用するやり方は、自然な流れではないかと思う。
そんな特徴も、Redmineが日本人好みのツールである理由の一つではないかと思う。

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

【4】個人的には、Redmineのコミッタとユーザコミュニティが、Redmineの機能や使い方について、色んな可能性や事例や要望を議論しながら、より良いものを作っていく基盤が出来ればと思う。
つまり、Redmineのエコシステムを他の成功したオープンソースと同じように実現したいのだ。

たとえば、LinuxやRubyは、当初は開発者のおもちゃに過ぎず、エンタープライズでは使えないと言われていたが、今は十分に普及し、どこでも使われている。
そして、一部の熱いユーザだけでなく、一般ユーザもユーザコミュニティを形成し、LinuxやRubyを支援するベンダーも多数参入し、コミッタも生活の糧の支援を得て、より良い方向へ進化する基盤が整っている。

Redmineもいつかはそんな形になればいいなと思っている。

それから、いつか、JPLを日本に呼びたい。
その意見は、2011年に東京Redmineコミュニティが立ち上がった時のキックオフミーティングでも机上に上がった。
日本のユーザコミュニティの熱い気持ちを彼に伝えてみたい。

| | コメント (0)

2016/06/11

7/30土の第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で議論してみたいこと #redmine

7/30土に開催される第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で議論してみたいことをメモ。
ラフなメモ書き。

【参考】
第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

(引用開始)
7/30に第65回 SEA関西プロセス分科会&第15回 RxTstudy 「チケット管理システムによるプロセス支援と今後の課題」を開催します。
今回の勉強会のメインセッションは、JAXA様の担当者の方にRedmine運用の事例報告を講演して頂きます。

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

JAXA様のRedmine運用事例報告を読むと、発注業務以外にISO9001も見据えた運用フローの標準化、ならびに、大規模な組織や多様な業務に対応できるようにRedmineの機能を十分に評価検証したことがよく分かります。
JAXA様の事例講演を次回も聞くチャンスはそうありませんので、ご興味のある方は是非ご参加下さい。
(引用終了)

【1】最近、Redmineの運用をいろんな場所で展開している時に思う問題意識は、二つある。
一つは、大規模な組織形態や多様な業務に対して、一つのRedmineインスタンスでカバーするには、Redmineにはどんな機能が必要で、どんな運用ルールが必要なのか。

もう一つは、組織構造とRedmineの相互関係を整理したいこと。
つまり、複雑な組織構造がRedmineやその運用プロセスにどんな影響を与えてしまうのか、ならびに、Redmineの導入と運用によって従来の硬直した組織の雰囲気を打破できる可能性はあるのか、を事例とその背後にある経験則を編み出したいこと。

【2】第10回東京Redmine勉強会のディスカッションで偶然聞いたグループでは、「闇Redmine」という言葉が出ていた。
つまり、一つのRedmineインスタンスでは他種類の部署の運用、多様な業務に耐え切れないので、自分たちのチームだけにこっそりとRedmineインスタンスを作り、自分たちのチームのソフトウェア開発プロセスの管理に使っている。

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

ツール主導ではなく、自分たちのプロジェクトで成果を出すためにツールを使うのだから、このやり方はおかしくはない。
しかし、自分たちのチームで上手くいったRedmineを隣のチーム、自分の部署のすべてのチーム、他の部署へ展開していくと、Redmineはどんどん複雑化していく。
特に、ワークフローやカスタムフィールドは、野放しに複雑に設定してしまいがちだ。

また、自分たちのチームのプロセスが、保守案件や問合せ管理、事務処理ワークフロー、サーバー資産管理、購入機器の管理などの多様な業務をカバーできるとは限らない。
むしろ、一つのRedmineですべての業務をカバーする方が無理があるのかもしれない。

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

【2-1】JAXA様のRedmine運用事例では、こういう運用の複雑さに対する解決策として、「ロールのOR設定ルール」「カスタムフィールドのAND設定ルール」を提唱されている。
このやり方は、ERPのパラメータ設定のノウハウに似ている気がする。
少ないパラメータ設定で、多様な業務、多様な要件に対応するために必要な運用ルールなのだ。

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

【2-2】以前のRedmineでは、ロール単位のアクセス権限の機能が弱いと言われていたが、随分改善されてきた。
Ver3.3では、トラッカーごとにチケット編集・参照の権限を付与する機能が追加される。

akipiiさんのツイート: "これは便利!RT @g_maeda: Redmine 3.3.0に入るのが確定。 ? Feature #285: Tracker role-based permissioning https://t.co/vImWQN2OZy https://t.co/CwSfqamCc2"

Feature #285: Tracker role-based permissioning - Redmine

アクセス権限管理の強化は、Redmineがエンタープライズ分野で利用されるに従って、重要なテーマになるだろうと思う。

【2-4】個人的には、@akahane92さんの思いと同じく、Redmineの機能をベースに、多様な業務に適応するための「ITSガイドライン」のようなものが作れるといいなと思う。
つまり、Redmineというプロジェクト管理用ERPのパラメータ設定の汎用的なノウハウをまとめてみたい。

「ロール設定のORルール」と「フィールド設定のANDルール」はもちろんその中に入るし、他にもたくさんあるはずだ。

akipiiさんのツイート: "面白そう。RT @akahane92: redmine 等のITSのトラッカー設計について、みんなどうしてるのかな。「ITSトラッカー設計ガイドライン」があればいいな。RxTstudyの参加者がトラッカーを持ち寄って、少人数グループで議論して持ち寄ると作れるかな。広く役立ちそう。"

Kuniharu AKAHANEさんのツイート: "@akipii 直感的で有効なステータス名、トラッカーとの組み合わせ、興味深いです。/背景と要求(例: 利用・運営者の組織文化、ITSによる問題解決の対象領域, 等)によるふれ幅がどの程度あるのか。/ケーススタディーの対象にしたとき、参考となるどのようなケースを引き出せるのか。"

neta@とんこつしかたべないさんのツイート: "@akahane92 @akipii いいですね!ウチはほとんど『依頼』、『課題』ですが、『課題』からそのまま解決のための『依頼』になってるチケットも多く、分ける必要なかったと思ってます。"

一つのRedmineインスタンスで、大規模組織でも多様な業務にも耐えれるような運用ルールを策定できれば、Redmineの利用範囲はもっと広がるだろうと思う。

【3】「組織構造とRedmineの相互関係」については、最近色々感じるものがある。

【3-1】従来から経験していることは、トラッカーやステータスは、そのチームの文化、その組織の文化が色濃く反映されることだ。

例えば、オフショア開発チームとRedmineでやり取りしていた時、「課題」トラッカーは使いにくく「QA」トラッカーの方が使いやすい、と言われた時があった。
ワークフローは同じなのに、トラッカー名が変わるだけで、メンバーのモチベーションもかなり上がった。

逆に、障害トラッカーで「リリース済」「対応済」ステータスを使っていたら、そのステータスにアサインされた担当者は何をすれば良いのか、直感的に分からないので、チケットが放置される場合もあった。
「~済」というステータスは、タスク完了なので、自分はやらなくていいんだよね、と思ってしまうらしい。

また、メーカーのように、営業部隊・設計部隊・製造部隊が組織として分かれていると、チケットが組織をまたぐ場合に別のステータスが必要になるという場合もあった。
チケットをやり取りするボールは誰が握っているのか、をステータスで明確にしたいのだ。
すると、メーカーのような機能別組織の場合、一つの製品、一つのソフトウェアを出荷するには複数の部門が関連するために、ステータスがかなり多くなってしまい、チケットが放置される危険が高くなりやすい。

一方、SIならば、普通は一つのチームが要件定義からリリースまで担当するので、一つのトラッカーに含まれるステータスの個数はそれほど多くはないし、多くする必要性もない。
チケット駆動で回したいならば、トラッカーに含まれるステータスの個数は少ない方が回しやすいからだ。

そんな経験を振り返ると、Redmineは機能が豊富な特徴、機能が柔軟である特徴があるがために、逆に、縦割り組織の文化をそのまま持ち込んで、複雑なパラメータ設定になりがちだ。

特に最近、ISO9001やITILの運用プロセスをRedmineに乗せて運用できないか、という質問を受ける時がある。
彼らとしては、Redmineの柔軟なワークフロー機能やREST APIによるチケット情報の取得の容易さ、Redmineの展開のしやすさを生かして、ISO9001のような硬いプロセスを実現したいみたいだ。

門屋 浩文さんのツイート: "@akipii @netazone @akahane92 トラッカーやステータス・進捗率のからみは、組織やプロジェクトの癖がもろにでますね。何もなければ、このルールでやろうねと教育はしているののの、、、プロジェクトごとの癖をみて、ちょこちょこメンテナンスしたりしてます"

門屋 浩文さんのツイート: "@akipii @netazone @akahane92 ちなみに、トラッカー「WBS」「障害」「課題」「要望」「質問」「レビュー記録」、ステータス「新規」「受付」「作業中」「停滞」「確認中」「差戻し」「完了」「却下」です。きっと組織によってぜんぜん違うんでしょうね"

【3-2】一方、Redmineでチケット管理し始めると、チームの雰囲気や組織文化が少しずつ変わっていくという経験もある。

たとえば、Redmineには最初のバージョンの頃から、複数プロジェクト機能があった。
この機能を使うと、ソフトウェアプロダクトラインのような複数製品の並行開発、一つのパッケージ製品を顧客ごとにカスタマイズする派生開発に適用しやすいことは、従来から知られていた。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

Conwayの法則の拡張版~運用は組織に従う、ワークフローは組織に従う: プログラマの思索

Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク: プログラマの思索

この機能を使い始めると、メンバーは縦割り組織に属している感覚よりも、複数のプロジェクトで作業している感覚になる。
つまり、組織の建前としてはピラミッド型の組織構造かもしれないが、現場のメンバーにとっては、プロジェクト型組織に属しているような雰囲気になる。
すると、自分の役割や権限が広くなるので、能力のある若手はたくさんのシステムに触れる経験を得やすく、どんどん成長していく事例をよく見かける。

また、プロジェクト型組織になると、プロジェクト内でコミュニケーションが活発化する。
一つのプロジェクト内で、一つのチケットをやり取りして完了させるまでに、色んな部署の人達と連携しなくてはいけない。
だから、自分は○○組織の一員だから、という意識よりも、○○プロジェクトの一員という意識になり、縦割り組織の雰囲気をぶち壊し、風通しの良い組織文化を形成してくれる。

【3-2】また、チケットの構造がチーム内の組織形態を規定する事例も見かける。

若手のプロジェクトリーダーからよく聞く質問は、WBSやチケットは、機能単位で作った方がいいのか、作業ベースで作った方がいいのか、という内容だ。
設計・プログラミング・テストのような単位で作業をグループ化すべきなのか、それとも、画面単位や帳票単位で作業をグループ化すべきなのか、迷うらしい。

会社の研修で教わるやり方は、設計・開発・テストのような工程単位の作業管理だ。
このやり方は、元々、製造業で規模の経済を生かすための作業管理手法であるから、ソフトウェア開発に馴染まない、と僕は常々思っている。
メーカーの組織が営業・設計・製造・品質保証の部門に縦割りになっていて、機能別組織になっているのは、設備投資を有効活用し、製品を低コストで大量生産するために、規模の経済を生かすためにそのような組織構造になっているのだ。

しかし、ソフトウェア開発の場合、人月の経験則のように、作業メンバーを増やすほどプロジェクトはどんどん遅延していくことが既に知られている。
つまり、ソフトウェア開発は規模の経済が通用しない。
むしろ、機能単位に作業を分割した方が管理しやすい。
機能単位ならば、機能の粒度を小さくすることで、小さなチーム構成にすることが可能だからだ。

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索にあるように、工程単位のWBSと機能単位のWBSでは、PERT図の構造が全く違うし、WBSを管理しやすくするための組織構造がWBSに規定されてしまうのだ。

すなわち、チケットの構造は、プロジェクト型組織の役割分担を規定する。
チケットを階層化するほど、WF型開発っぽくなるし、チケットをバージョン単位でグループ化して小規模リリースを優先するなら、アジャイル開発っぽくなる。
開発プロセスは、逆に、組織形態を規定しまうのだが、それに気づかない人も多い。

【3-3】「ソフトウェアアーキテクチャは組織構造の影響をもろに受けてしまう」という経験則は、Conwayの経験則として既に知られている。
この考え方は、組織構造がソフトウェアアーキテクチャ、開発プロセスを規定することから、アーキテクチャやプロセスの複雑さの遠因には、ソフトウェア組織にあるということだ。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

Conwayの法則の拡張版~運用は組織に従う、ワークフローは組織に従う: プログラマの思索

一方、平鍋さんの記事で「逆コンウェイ戦略」という概念を知って、気づいたことがある。

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

「逆コンウェイ戦略」の発想は、より良いアーキテクチャに合わせて、チーム構成を作るべきというもの。
その発想を受け継ぐならば、より良いプロセスに合わせて、組織構造やチーム構成を決めてもいいのではないか。

実際、Redmineの導入によって、チームの文化や組織の文化は変わる。
その変化は良い方向性の場合が多い。
だから、積極的に、Redmineというツールの背後に隠れたプロセスを使って、縦割り組織を打破することも可能ではないだろうか。

【4】第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」のパネルディスカッションでは、上記のような経験や事例を元に、組織とプロセスの関係と、相互に与える影響について、パネラーや参加者の知見をまとめてみたいと思っている。


| | コメント (0)

2016/05/15

第10回redmine.tokyoの感想~Redmineユーザはメトリクスがお好き #redmineT

第10回redmine.tokyoは参加者100名超の大盛況で終わりました。
参加者、スタッフの皆さん、そして、コミッタのまるやまさん、コントリビュータの前田剛さん、ありがとうございました。
UStreamでも参照できるので、私的感想をメモ。

【参考】
第10回redmine.tokyo勉強会 - dots. [ドッツ]

第10回勉強会 - redmine.tokyo

第10回東京Redmine勉強会~「メトリクスの見える化とその周辺」 #redmineT - Togetterまとめ

【1】Redmineの開発とリリース計画作りは、わずか3人の体制で支えられている。
役割分担は、JPLが機能追加やリリース作業、まるやまさんがバグ修正やテストコード整備やRails5対応、前田剛さんがチケット整理と次バージョンの対象チケットをアサイン、となっているらしい。
Redmine本家の活動ログを見る限り、3人体制で上手く回っているように見える。

でも、第三者から見れば、Redmineは日本でこれだけ普及したOSSのプロジェクト管理ツールであり、SIの事実上の基幹系業務システムになっている現状を考えると、Redmineの開発体制はもっと強化してもいいかもしれない。
今後もずっと、永久的にRedmineの開発が安定して続けて欲しいのだ。

前田剛さんから、Redmine本家に、バグ報告や機能改善の提案があれば、チケット登録して欲しいと、実際の操作方法も説明された。
また、前田剛さんによれば、Twitterで「#Redmine」のハッシュタグを付けてバグ報告してもらえるだけでも拾えるから、と言っていた。

Kawabata Mitsuyoshiさんのツイート: "Redmineのコミッターは実質2人だけ。日本人コミッターまるやまさんはバグ対応しか出来ないほど追われてるので、バグ対応のパッチを送ってくれることが今一番の貢献じゃないかなと思う #redmineT #eventdots"

akipiiさんのツイート: "あなたの秘蔵パッチも本家にあげて欲しい。一度マージされれば、その後は本家が保守してくれる。 #redmineT #eventdots"

akipiiさんのツイート: "スクリーンショットは英語モードで添付して欲しい。本家の人達は海外の人だから。 #redmineT #eventdots"

松谷 秀久さんのツイート: "英語がハードルの方はGoogle groupのRedmine users(japanese)へどうぞ https://t.co/sdeNF9xQ0T"

redmine.tokyoやRxTStudyというユーザコミュニティも、Redmineのバグ報告や機能改善の提案などのフィードバックが行えればと思う。

【2】ViewCustomizePluginはとても面白いプラグインだ。
フック処理を上手く使ってRedmineの表示処理を自由に制御できる。
Redmineコミッタから見れば、邪道なプラグインかもしれないが、Redmine運用管理者にとっては非常に、かゆい所に手が届きやすいプラグインだろうと思う。

なぜなら、ちょっとした表示処理を微修正するために、Redmine本体のソースにパッチを当てたり、プラグインを追加するとなると、RedmineのDBマイグレーションやRedmine再起動が発生したりするからだ。
@netazoneさんが講演されたように、ユーザが会社全体に広がり、海外の工場でも使われ始めると、Redmine再起動のタイミングがなくなってしまうからだ。

ViewCustomizePluginを使った事例のうち、聞いた話では、金額にカンマ表示させたり、二つのプルダウンのカスタムフィールドの値同士に関連の制御をかける事例を聞いた。
たとえば、OSと.NETバージョンの二つのプルダウンに関連がある場合などだ。

ViewCustomizePluginは他の利用シーンでも使えるので、利用シーンごとに表示処理をカスタマイズするJQueryのソースが整理されると面白いだろうなあと思う。

【3】「メトリクスの見える化」というテーマは、今回の勉強会の参加者に聞くと、食い付きが良かったらしい。
話を聞くと、Redmineに溜まったチケットデータを集計する作業を実際にExcelでやっていたり、メトリクス集計をしたいがどんな方法が効果があるのか知りたい、という人が多かったみたい。

そもそもRedmineに興味を持つユーザ層は、プロジェクトリーダーやPMOクラスの人なので、ソフトウェアメトリクスによる進捗・品質の見える化は一度はやってみたいテーマなのだろうと思う。

【3-1】GnuPlotによるメトリクスのビジュアル化スクリプトの話は興味深かった。
仕組みとしては、PerlスクリプトでREST API経由でRedmineチケットデータを全件取得してCSV形式に加工し、GnuPlotにデータを食わせて画像表示して、RedmineのWikiに「ダッシュボード」タブを作って、メトリクス専用のWikiに最新表示させておく。
ダッシュボードの新規タブを作るには、Wiki Extensionsプラグインを使っているらしい。

Wiki Extensions - r-labs

松谷さんのPerlスクリプトでは、平均完了日数、最大放置日数をRedmineプロジェクト単位にメトリクス出力して、GnuPlotでヒストグラムや折れ線グラフ、散布図などで表示させる。
さらに、WikiListプラグインを使って、GnuPlotの元ネタとなるCSVデータを表形式にWikiで表示し、さらにそこから詳細はチケット一覧のクエリへリンクさせるようにしているらしい。

Wiki Lists - Plugins - Redmine

そうしておけば、たとえば、最大放置日数が多いチケット2件はどのチケットか、そのチケットを最優先で対処すべき、という意思決定が容易に行えるようになる。
また、1週間毎に平均完了日数と更新チケット枚数を折れ線と棒グラフで表示させて、平均完了日数が週ごとに短くなっているならば、チームが学習して開発速度が上がっている、という評価もできる。

この使い方は面白い。

また、GnuPlotで、信頼度成長曲線の関数を使えば、チケットの情報を渡せば、信頼度成長曲線の定数値を自動計算してくれるらしい。
チケットの精度やデータ数が多ければ、信頼度成長曲線の精度も上がるわけだ。

さらに、そこまで難しく集計加工する必要がないならば、Redmine Pivot Tableプラグインを使えると、Redmine上でExcelのピボット集計のような機能を実現できる。
Redmine Pivot Tableプラグインは、表形式に集計表示してくれるだけでなく、様々なグラフ形式でもビジュアルに表示してくれる。
これは便利だ。

Redmine Pivot Table - Plugins - Redmine

deecay/redmine_pivot_table: This Redmine plugin allows you to generate pivot table for issue analysis.

【3-2】楠川さんの話を聞いて、WorkTimeプラグインの「工数付替機能」の意味がようやく分かった。
どうやら「顧客向け工数報告」プロジェクトと、「チーム内の作業管理」プロジェクトで分けた運用をしているらしい。
つまり、月中は「チーム内の作業管理」プロジェクトで、メンバーは日々の作業チケットに実績工数を登録している。
しかし、顧客向け報告書に、その内容をそのまま出力して報告はできない。
なぜなら、顧客の観点では、本番障害に工数がかかりすぎ、とか、単純な問合せに対してなぜこんなに工数がかかり過ぎているの、など、突っ込みが入ってしまって、顧客に実費請求できないリスクがあるからだ。

そこで、「チーム内の作業管理」プロジェクトから「顧客向け工数報告」プロジェクトのチケットへ実績工数をコピーし、プロジェクトリーダーが、報告書の体裁に合うように、各チケットの実績工数を微修正したり、配分し直したりする。
その作業が「工数付替機能」なわけだ。
確かに、複数のWebシステム保守をやっているプロジェクトリーダーは、実費請求の作業報告書を作る時に、作業内容と実績工数のつじつまを合わせるために、月末に加工する作業にかなりの時間を費やしている。
正直、工数管理の二重管理だ、という指摘もあろうが、SIの準委任契約案件では、このようなドロドロした管理作業はよくあるので、工数付替機能は良く考えられた機能だと思う。

WorkTime - Work Time - r-labs

【4】各テーブルのフリーディスカッションは好評だった。
グループディスカッションで、参加者からRedmine運用の現状や問題点を聞いた。
一部の参加者の話を聞くと、実は、Redmineはソフトウェア開発チームのタスク管理よりも、カスタマーサポートや障害管理などの方が向いている、という意見があった。

理由は、ソフトウェア技術者はGitを使っているので、プルリクエストが使えないRedmineは使いにくい。
だから、GitlabをGitリポジトリに見立てて、IssueのインターフェイスはRedmineを使うように、RedmineとGitlabを連携している。
一方、ユーザからの問合せ対応やインシデント管理、製品のバグ報告の管理は、Redmineのチケットに登録して、ワークフローにのせて担当者に回す運用が上手く回っている、と。

つまり、Gitを使っているユーザは、RedmineのGit連携機能に完全に満足できていない。
一方、カスタマーサポートの担当者は、インシデント管理やバグ管理はRedmineチケット管理だけで十分に回る。

【5】改めて、Redmineの今後の課題の一つは、多様で大規模な組織に、一つのRedmineインスタンスでどれだけ幅広く業務をカバーできるか。
そのためには、Redmineにどんな機能が必要なのか、という課題だと思う。
参加者から数多くのフィードバックを聞いた。

【5-1】たとえば、Apacheのセキュリティバグが判明し、そのバグ修正を行うチケットがあったとする。
すると、一つの製品だけではなく、他顧客の他システム、他のパッケージ製品にもセキュリティパッチを当てないといけない。
その場合、一つのバグ報告のインシデントチケットに対し、関連する複数のシステムや複数の製品に同じ内容のチケットが複製されて、それぞれで対応していく必要がある。
なぜなら、システムごとにセキュリティパッチのリリース日が違うし、進捗も違うからだ。

しかし、発端となったインシデントチケットと、それを複製した他製品のチケットは、一つのRedmineプロジェクトで管理すべきものではない。
むしろ、各Redmineプロジェクトにそれぞれ配置すべきであるが、どのシステムに影響があるのか、漏れ無くチケット登録するのはかなり大変だ。
手作業なのでどうしてもミスが発生するリスクがあるし、インシデントのチケットと派生製品のチケットを関連づけて、各チケットの進捗やリリース日も漏れなく管理したいのに、今のRedmineでは機能や運用ルールが不十分なのだ。

【5-2】たとえば、ISO9001に即した作業管理をRedmineで運用している場合、チケットの構造はISO9001の文書に即した構造になるため、カスタムフィールドがとても多い。
しかも、一度作成した作業依頼書は、内容が似ているので、他の作業でもコピーして流用したくなる。

すると、Redmineチケットのコピー機能を使って、チケットを複製した時、コピー先チケットの登録時にコピー元チケットも関連付けられて、コピー先の担当者やウォッチャーだけでなく、コピー元のチケットの担当者やウォッチャーにも更新メールが飛んでしまう。

Redmineの運用を始めると、大量にメールが流れてしまうため、「~のチケットが関連付けられました」だけのメールは正直不要なので、メール送信から外したい。
しかし、今のRedmineの管理画面では、更新メールの制御条件は「担当者」「優先度」ぐらいしか条件がないので、色んな利用シーンで更新メールを通知させない制御ができない。
本来は、「チケット関連付けを通知する」「説明の変更を通知する」「開始日・期日の変更を通知する」「カスタムフィールドの更新を通知する」などのメール送信制御も入れたいし、プロジェクトごとに更新メール通知の制御もやりたい。

また、現在のRedmineのチケットコピー機能ではなく、単純な「チケット内容の複製」機能が別途欲しい。
終了チケットの内容をそのままコピーして、カスタムフィールドの内容をちょっと微修正して流用したい場面は結構ある。
事務処理ワークフローシステムでよくある「申請書コピー」機能と同じだ。

@netazoneさんによれば、今のバージョンのRedmineチケットコピー機能を使うと、コピー先のRedmineチケットの期日に、コピー元チケットの期日が複製されてしまうため、コピー先チケットの作成日よりも期日が古いという矛盾したチケットが作られるのは困る、と言っていた。
たしかに、チケットコピー機能はもう少し改善したい機能の一つ。

【5-3】JAXAのRedmine運用事例の経験論文では、「ロールのORルール」「カスタムフィールドのANDルール」という優れた運用ルールの説明がある。
参加者からその意図を聞くと、たくさんの部署に展開した時に、各Redmineプロジェクトにロールやトラッカーやカスタムフィールドを割り当てる時、それぞれの部署の業務ごとにそれらを作ってしまいがち。
すると、ロールやトラッカーやカスタムフィールドが50個以上ぐらい発散してしまい、似たような項目が増えていき、システム運用が回らなくなる。

そこで、「ロールのORルール」「カスタムフィールドのANDルール」を導入して、Redmineのロールやカスタムフィールドをできるだけ増やさないような運用方法を編み出した、と言う。
だから、Redmineデフォルトのロール「管理者」「開発者」「報告者」は使わず、独自のロールをいちから作った、と話されていた。
確かに、「ロールのORルール」「カスタムフィールドのANDルール」を徹底できれば、共通のロールやカスタムフィールドを組合せることで、より多くの業務を一つのRedmineインスタンスでカバーすることができるだろう。

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

【5-4】しかし、別の参加者の話を聞くと、会社のRedmineが使いづらいために、各部署ごと、さらには各チームでRedmineインスタンスをこっそり作って、自分たちの課題管理・障害管理・作業管理に使う利用事例もあるらしい。
つまり、自分たちの案件で自由に使いたいために、自分たちのためだけのRedmineインスタンスを作って、自分たちの運用ルールで回している。
すると、その会社では、Redmineインスタンスが20個以上乱立した状態になっているらしい。
その状況を「闇作業」「闇チケット」ならぬ「闇Redmine」と言っていた。

この事例の話は、一つのRedmineインスタンスで数多くの業務、数多くの利用状況をカバーできない問題があることを示している。
その原因は、Redmineの機能不足もあるだろうが、むしろ、運用ルールとRedmine機能のギャップにあると思う。

前田剛さんの話を聞くと、Redmineはそもそもオープンソース開発のためのプロジェクト管理ツールなので、幅広い多様な業務の運用に耐えれるように機能が最初から作られているわけではない、と言われていた。

おそらく、Redmineが当初想定されていた利用シーンであるソフトウェア開発の作業管理から、カスタマーサポートや事務処理ワークフローなど、数多くの業務にも適用されたことで、このような問題点が具体化されてきたのだろうと思う。

つまり、大規模な組織の多様な業務に対し、一つのRedmineインスタンスの機能や運用ルールが追いついていないから、闇Redmineのように、業務ごとに多数のRedmineインスタンスが乱立するわけだ。

でも、複数のRedmineインスタンスを作らざるをえない状況もある。
たとえば、オフショアチームや顧客には社内のRedmineに入れないので別途やり取りするRedmineインスタンスを作るしかない、という状況はよくある。
社内のRedmineには、見積りや原価の情報が記載されているので、社外には見せれない、という事情もあったりする。

したがって、一つのRedmineインスタンスで、大規模な組織の多様な業務をどれだけカバーできるか、そのためには、どんな利用シーンで、Redmineにどんな機能が必要で、どんな運用ルールを整備すべきか、という課題が今後必要になるだろうと思う。

【追記】
発表資料はコチラ。

| | コメント (2)

より以前の記事一覧