Redmine

2017/12/09

日本のRedmineコミュニティの活動報告と今後の抱負

Redmine Advent Calendar 2017 - Qiitaに初参加です。
日本のRedmineコミュニティの活動報告と今後の抱負を書きます。

私が書くのは恐れ多いと思いますが、改めて、Redmine大阪スタッフとredmine.tokyoスタッフの皆さんに大変感謝です。

【参考】 Redmine Advent Calendar 2017 - Qiita

【1】日本のRedmineコミュニティ

現在活動中の日本のRedmineコミュニティは、Redmine大阪とredmine.tokyoの二つがあります。
Redmineは誕生して11年も経ちますが、どちらのRedmineコミュニティも2011年に創立されたので割と浅いです。

Redmineの9年間の歩みを振り返ってみる

Redmine 10周年記念 10年ふりかえり

私はその二つのコミュニティでスタッフとして関わっているので、その立場から生い立ちとその歴史を簡単に振り返ります。

【2】Redmine大阪

Redmine大阪 - connpass

RxTstudy

過去のイベント - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

【2-1】勉強会の発端は、2011年6月に、@pinkmacさんが「【緩募】関西でRedmineをタスク管理に使いたい勉強会を開催したら参加/発表してみたいという方!」というTwitterが流れたことです。
あっという間にスタッフや講演者、参加者が集まり、「RxTStudy~Redmineとタスクマネジメントに関する勉強会」というコミュニティとして発足しました。
「RxTStudy」は「Redmineとタスクマネジメント(Task)に関する勉強会(Study)」という意味です。

その後、Redmineが日本で知名度が上がる中、「RxTStudy」という名前では分かりにくいという声があったため、2016年に地域名を付けた「Redmine大阪」にコミュニティ名を変更して、今に至っています。

【2-2】第1回目の経緯は下記に書いています。

【告知】Redmineでのタスク管理を考える勉強会@大阪で発表します #RxTstudy: プログラマの思索

記念の1回目の勉強会は、その頃にRedmine本を出版した前田剛さん、倉貫さん、阪井さんと僕が講演したこともあって、定員50人があっという間に埋まり、当日の模様がUStreamで中継されてたいへん盛り上がったことを覚えています。
また、僕が講演した内容「RedmineのFAQとアンチパターン集」は、当時はすごく反響が大きかったことを覚えてます。

それから、最近は年2回ペースで開催され、現在は17回まで続いています。

【2-3】勉強会の内容は、Redmineの利用事例からRedmineのカスタマイズ方法、最新バージョンの機能紹介など多岐にわたります。
今までの中で、僕の記憶に残る主な講演は下記かな。

(1)@daipresentsさんの「チームにRedmineを適用せよ! #RxTstudy」では、楽天における1000人という当時は大規模なRedmine利用事例でした。

(2)@akahane92さんの「情報システム部門のタスク管理とIT全般統制 ~ Excel管理からの脱却 ~ (ITS Redmine #RxTstudy #5)」では、島津製作所の基幹系業務システムのタスク管理とIT全般統制にRedmineを導入して運用して効果を上げている事例でした。
その後、JaSSTやSQIPなどでも講演されて一躍有名になりましたね。

(3)陸野さんの「Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用」では、パナソニックにおける組込みソフトウェア開発にRedmineを導入運用した事例でした。
従来まで数多くのプロジェクト管理のパッケージ製品を導入してきたけれど、パッケージ製品には販売元の会社のプロセスが埋め込まれていて、自分たちの組織に合わない、という指摘に改めて刺激を受けたことを思い出します。

(4)JAXAの藤田さんの「JAXAスパコン"JSS2"の運用を支えるチケット管理システム"CODA"」では、JAXAスーパーコンピュータ活用課にて、業務の管理にRedmineを利用している事例でした。
実際のRemdine画面を見ることができて大変貴重でした。

(5)@ktouさんの「全文検索でRedmineをさらに活用!」では、Redmineの全文検索の機能強化と今後の可能性に関する事例でした。
Redmineに機械学習や人工知能などの技術を組み込むと、新たな可能性が広がる、というワクワク感が満載でした。

【3】redmine.tokyo

概要 - redmine.tokyo

【3-1】勉強会の発端は、僕がちょうど東京にいた頃、東京にいる熱心なRedmineユーザが集まって、勉強会を開こう、という話があがったことでした。
2011年当時は、@nobiinu_andさん曰く「東のTrac、西のRedmine」と言われるぐらい、東京ではTracコミュニティが活発だったので、Redmineもコミュニティが欲しいなあ、という雰囲気があったためです。

Shibuya.trac Wiki - Shibuya.trac - OSDN

nobiinu_andさんのツイート: "ですね! USTあるとイイなぁ… 実は東のtrac、西のredmineという状況だったりして RT @akipii: @nobiinu_and Redmineでのタスク管理を考える勉強会@大阪で議論できると思います。http://t.co/X2o1jPF #RxTstudy"

たしか、キックオフ飲み会が暑い8月に行われた時、当時はRedmineで唯一の日本人コミッタである@marutosijpさんも来られて、Redmineを話題に盛り上がったのを思い出します。

記念の第1回目の勉強会は、IPAで場所をお借りして開催されました。
第1回目の内容は、下記に書いています。

【告知】第1回品川Redmine勉強会を開催します #47redmine: プログラマの思索

当初は「品川Redmine」という名称でしたが、参加者から限定的なコミュニティのイメージを持たれることもあり、2014年から地域名を付けた「redmine.tokyo」にコミュニティ名を変更して、今に至っています。

それから、ほぼ年2回ペースで開催され、現在は13回まで続いています。

【3-2】勉強会の内容は主に、講演が数本、ライトニングトークスやグループディスカッションです。

redmine.tokyoの最大の特徴は、参加者がすごく多い点でしょう。
@naitohさんがまとめてくれているアンケート資料「Redmine.tokyo 13 questionnaire」を見ると、過去は参加者が100名超えの時もありました。
よって、いつも大変盛り上がっているのが印象的です。

また、@tkusukawaさんたちがボランティアで、UstreamやYoutubeで講演をリアル放映してくれています。
そのおかげで、いつも満員御礼になっているにも関わらず、参加できなかった人や東京以外の地方のRedmineユーザも視聴できます。
いつもありがとうございます。

【3-3】勉強会の内容はRedmine大阪と同じく、Redmineの利用事例からRedmineのカスタマイズ方法、最新バージョンの機能紹介など多岐にわたります。
今までの中で、僕の記憶に残る主な講演は下記かな。

(1)Takashi Okamotoさんの講演「RedmineとGitとスクラム」では、当時最新の使い方であったRedmineとGit連携の事例でした。

(2)@akahane92さんの講演「Redmineチューニングの実際と限界 - Redmine performance tuning」では、100万チケットでも耐えれるRedmineのチューニングノウハウの紹介でした。

(3)@netazoneさんの講演「ある工場のRedmine +(Plus)」では、製造業におけるRedmineの運用事例でした。
当時の環境では、プラグインが23個もあるのが驚異的でした。

(4)@onozatyさんの講演「View customize pluginを使いこなす」では、View customize pluginによるRedmineのカスタマイズ事例でした。
この発表後、View customize pluginの利用が広まったように思います。

(5)@kazuphさんの講演「IoT企業とRedmine // Speaker Deck」では、IOT企業のハード製造部門とソフト開発部門、サポートデスクの3部門におけるRedmine利用事例でした。
かんばんとガントチャートを使い分けている点が興味深ったです。

(6)JAXA木元さんの講演「CODAの定義・運用の現在 - 2017年版 -」では、JAXAにおけるRedmineのノウハウを惜しみなく公開した事例でした。

【4】参加している人たち

【4-1】参加者は、実際にRedmineを使ってプロジェクト運営しているSIのプロジェクトリーダー、Remdineのパッチを作ったりプラグインを開発する人達、SIでRedmineのサーバーのインフラを管理する人、などが多いです。
さらに、参加者層を分析すると、開発プロセスに興味がある人たちだけでなく、Redmineのパッチを作ったり、プラグイン開発者が割と多いことが特徴的だろうと思います。

つまり、素のRedmineを運用してみて不足している機能はプラグインで開発して、それをGithubで公開されている人が多いように感じます。
たとえば、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさんたちです。
また、@naitohさんのように、PDFの日本語化Gemを開発して貢献されている方もいます。

【4-2】Redmineコミュニティに携わるスタッフの立場では、プロジェクト管理や開発プロセスに興味を持つ人たちだけでなく、Redmineの機能強化につながるプラグイン開発者は非常に重要と思います。
なぜなら、Redmineの不足機能をプラグインで代替できるようにオープンソースで提供してくれているからです。

そのおかげで、ユーザはRedmineを自社の組織文化に合わせてカスタマイズすることが容易になります。
つまり、ユーザ自身が設計したプロセスへツールを合わせるように運用しやすくすることで、自然にプロセス改善の雰囲気がチーム内に発生し、チーム自身で問題解決していくという自律化の雰囲気を醸し出すメリットもあるのだろう、と感じるからです。

【4-3】最近は、勉強会の参加者層は幅広くなったように感じています。

グループディスカッションで聞いてみると、IT業界に限らず、製造業やゲーム業界、Webデザイン業界、など幅広い業界の人たちが参加しているようです。
また、Redmineを長年使っている人たちだけでなく、PMOや品質保証部に在籍する上層部の人や、興味があるから来てみたという初心者も増えているようです。

背景には、Redmineが日本でかなり知名度が上がり、実際に使われている場面が多くなっているからでしょう。
実際、日本国内におけるGoogleトレンドを見ると、現時点ではTracやJiraよりもRedmineが上位に上がるケースが多いようです。

Redmine 10周年記念 10年ふりかえり

【5】今後の抱負

Redmineコミュニティに携わるスタッフとして、今後の個人的な抱負は2つあります。

【5-1】一つ目は、Redmineコミュニティの参加者の多様化を図る事です。

Redmineが持つ特徴として、二つの側面があります。
まず、プロジェクト管理を柔軟に運用できるプロセス基盤または、ソフトウェア工学の理論を実験できるメトリクス収集・集計基盤であること。

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

次に、汎用的なプロジェクト管理ツールの開発基盤であること。

第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」

すなわち、Redmineの利用者層は、前者の観点では、プロジェクトリーダーやPMO、品質保証部のような立場でプロセスを構築し運用する人達である一方、後者の観点では、プラグインを開発したりRemdineをカスタマイズするRuby開発者という二つの側面があるのです。
そして、その両方に詳しい技能を持つ人は非常に少ないでしょう。

よって、全く異なる技能を持つ人達が集まることで、プロジェクト管理やソフトウェア工学で困っている問題がプラグインやカスタマイズで解決できたり、新たなプラグイン提供によってプロジェクト管理の新たな使い方が生み出されることもあるでしょう。
つまり、プラグイン開発者とプロセス管理者がお互いに有意義な議論を重ねながら、ソフトウェア開発の現場を改善する道具として、Redmineは発展できるはずと考えます。

そういう化学反応、シナジー効果を提供する場を構築したいと考えてます。

【5-2】2つ目は、Redmineのエコシステムを作る事です。

日本の企業でRedmineがかなり普及している現在、Redmineは日本のSIにおける事実上の基幹業務システムではないか、と思います。
すると、Redmineは今後も安定的に機能改善されて保守されて欲しい。

幸いなことに、Redmineの歴史をたどると、自動テストが整備されたおかげで、RubyやRailsのバージョンアップにも追随しており、セキュリティパッチも早急に対処されています。
そのおかげで、Redmineの品質は割と高いのではないか、と思います。

Redmine build status

Redmine code coverage

また、性能面でも、Redmine大阪第17回勉強会に参加した - Basicに記載あるように「機能が増え続けるRedmineの処理の重さを、RubyやRailsの足回りが地道に改善してカバーしている」ように進化しています。

しかし、現在のRedmineのコミッタはJPLを含めて3人しかいない。

今後の夢としては、オープンソースの成功事例であるLinuxやRubyのような永続的なオープンソースとして確立して欲しい、と思っています。

たとえば、LinuxやRubyも当初は、開発者のおもちゃと見なされて、エンタープライズでは使えない、と思われた時期もありました。
しかし、コミュニティが発展してマーケットが広がっていくうちに、エンタープライズ界隈にも広がり、今ではむしろ、オープンソースで無いと保守され続けなくなるリスクがあるように見受けられます。
そして、LinuxやRubyも、コミッタと熱心なユーザだけでなく、ベンダーもユーザの一部として加わり、マーケットが拡大する方向へ成長している状況があります。

よって、RedmineもLinuxやRubyのように、コミッタ・ユーザ・ベンダーの三者が良好な関係を保ち、成長のらせん構造を昇っていけるような環境をいつか作りたい、と思っています。

| | コメント (0)

2017/11/30

Redmineをもっと強化できるポイントpart2~コミュニケーションツール連携・かんばん機能

Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化」の続き。

【1】障害チケットの活動ログをSlackのようなコミュニケーションツールと連動させる

結合テストや総合テスト工程では、従来は、朝会や夕会でメンバー全員を集めて、障害の優先順位付け、障害の担当者割り振り、修正状況の進捗確認などが行われていた。
メンバー全員の手が一時的に止まるので、結構ロスも多かった。

そこで、Jiraでは、Hipchatでチャットルームを作り、Hipchatに障害チケットの更新通知を流し、議論のやり取りをチャットにしてしまう運用があった。
つまり、Hipchatのチャットルームは、いわゆるWarRoom。
この運用で、総合テストの朝会や夕会で全メンバーが集まり、進捗状況を確認する運用がなくなった、とのこと。
なぜなら、オンライン上でリアルタイムに作業状況や進捗状況がやり取りできるので、全員が集まる必要がないからだ。

この運用は、RedmineからSlackへ障害チケットの更新通知をリアルタイムに配信し、Slack上でコミュニケーションを取ることで解決できるのではないか。

たとえば、テスターが障害チケットを起票したら、Slackに流れて、誰かがその障害を担当するか、Slack上でやり取りして決める。
決まったら、障害チケットに担当者が正式にアサインされ、その後の修正と動作確認はチケットのコメントで残す。

また、大規模プロジェクトでは、各チームの障害チケットがSlack上に流れるので、どのチームの障害が多いのか、どの人がどんな仕事をしているのか、というやり取りが全て見える化される。
見える化するような仕組みづくりは不要になる。

最近のソフトウェア開発では、Slackのようなコミュニケーションツール上で、仕様を議論したり、進捗状況を確認したりする時が多い。
なのに、逐一メール通知で気づくというやり取りは、情報連携のスピードが遅い。

SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ

歴史あるSI企業でSlack導入に成功した方法――そして社内の風通しが良くなりムダや停滞感も消えていった (1/3):EnterpriseZine(エンタープライズジン)

今後は、Slackのようなコミュニケーションツールとチケット管理システムの連携が重要になってくるだろう。
RedmineにもSlack連携プラグインがあるが、最新バージョンでも動くのかな?

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

sciyoshi/redmine-slack: Slack notification plugin for Redmine

【2】ガントチャートだけでなく「かんばん」も標準機能にして、場面ごとに使い分ける

Redmineが使えない、という人たちは、チケット一覧画面を多用しすぎる。
無造作に蓄積された多量のチケットに途方に暮れている。
乱発されたチケットを定期的に棚卸しする工夫を行わないと、すぐにチケットは放置されて、ゴミ箱になる。

だから、チケット駆動開発では、大量のチケットが発行されるので、何らかの方法でチケットをグループ化したり、他のチケット集計ビューを使ったりすることで、チケット管理を行うのが普通。

また、日本の普通のSIやメーカーのプロジェクトリーダーは、ガントチャートによるチケット管理が大好きだが、メンバー個人の立場ではガントチャートは使いにくい。
むしろ、小規模チームやメンバー個人では、タスクかんばんの方が作業しやすい。

たとえば、以前の東京Redmine勉強会の講演でも、IOT企業では、ガントチャートとかんばんを使い分けてチケット管理している、という事例があった。

RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない

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

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

Redmineでは、複数プロジェクト機能があるので、かんばんもプロジェクト単位に分割できる一方、上位プロジェクトで横断的にかんばんのチケットを見ることもできるのがメリットになる。

よって、Redmineのようなチケット管理ツールでは、従来のマネージャ層向けのガントチャートと、メンバーが自身の担当状況を把握するためのかんばんの2つのチケット集計ビューが必須だろうと思う。

残念ながら、Redmine標準でかんばん機能はないので、実現されて欲しいと思う。

【3】「上流工程のトレーサビリティの強化」「コミュニケーションツール連携」「かんばん機能」は、最近の有償のチケット管理ツールにはどれも付属しているだろう。
これら機能は、プロジェクト状況の見える化、情報共有を現代風に強化したものと思える。

これら機能の効果は、以前よりも大規模な人数による大規模開発や、地理的に離れた開発チームによるオフショア開発がやりやすくなることだ。
つまり、大人数の開発者同士、地理的に離れた開発者同士のコミュニケーションをリアルタイムに行えるようにして、情報共有、さらには信頼関係を促進する方向へ、チケット管理ツールがどんどん進化している。

従来のソフトウェア工学では、コミュニケーションパスが増えるほどソフトエアの複雑性も非線形で増大するが、その問題を根本的に解決する方法はない、みたいな話があったように記憶する。
しかし、チケット管理ツールはその問題の症状を和らげて、より大規模かつ地理的に広範囲なチームでもソフトウェア開発できる環境を整備しようとする方向へ進化している。

この流れをRedmineの機能にも盛り込んでいきたい。

| | コメント (0)

Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化

最近のJiraを見る場面があって、この機能はRedmineに取り入れた方がいいな、と感じたことをラフなメモ書き。
Redmineがもっと強化できそうなポイントは3つあると感じた。
そのうちの1個を書いておく。

【1】議事録Wikiと課題チケットを相互リンクさせる

【1-1】たとえば、要件定義や設計工程では、要件定義ヒヤリングや設計レビューが定期的に開催される。
そのタイミングで、Wikiにその場の議事録を全て書く。
そして、議事録でまとめられた決定事項以外に、課題となった内容は、チケット化する。

その時、Wikiから課題チケットを1クリックで新規作成したい。
そうすれば、ヒヤリングやレビューの打合せ時に、議事録をWikiに書きながら、その場ですぐに課題チケットを発行できる。
後で、課題チケットの詳細を書いて、チーム内で割り振りすればいい。

また、議事録Wikiには、発行した課題チケットのリンク一覧が自動生成されて欲しい。
そうすれば、議事録Wikiを見れば、どこまでが決定して、どこまでが残課題として残っていて、課題がどんな進捗状況なのか、一目で分かる。

【1-2】つまり、議事録Wikiと課題チケットを相互リンクさせるように機能強化することで、トレーサビリティを強化したいのだ。
すなわち、課題チケットの発端となった要件定義ヒヤリング、設計レビューの議事録Wikiと相互リンクさせることで、開発時やテスト工程で要件を探したり、保守フェーズで要件が変更されていった経緯を探すことに使いたいのだ。

現時点でのRedmineでは、構成管理ツール連携によって、ソースコードの変更履歴と障害チケットのトレーサビリティは実現できる。
つまり、開発やテスト工程以後の下流工程のトレーサビリティは標準機能で実現済みだ。

しかし、要件定義や設計工程などの上流工程のトレーサビリティは、機能と運用が上手く調和が取れていないと思う。
「チケットを起票してくれない」「チケットが放置されてしまう」理由の一つは、ここにあるのではないか。

以前の僕は、チケットをストーリーカードにすることで、チケットに要件を当てはめて、タスクに落とす方法を考えていた。
WF型開発におけるWBS駆動によるチケット化も同じ。

ITの地殻変動はどこで起きているのか?: プログラマの思索

しかし、要件や仕様、議事録をチケット化するのは経験上、あまり上手く運用できていないように感じる。
理由は、チケットの機能がすごく柔軟であるので何でもチケット化してしまうと、チケットをフローとして流したいのにストックの性質も持っているために、チケットを安易にCloseできなくなってしまうから。

【1-3】「議事録Wikiと課題チケットを相互リンクさせる」メリットは、課題チケットの発端となるヒヤリングやレビューという打合せがWikiに残ること、そして、課題や作業のようなフローはチケット、議事録はWikiでストックのように使い分けできることだ。
つまり、チケットはフローの処理だけに特化すればいい。
よって、チケットは基本はサクサク流れる。

また、毎回の打合せ議事録Wikiに、新規作成したチケット一覧が課題一覧として自動生成されると良い。
現時点のRedmineでは、WikiListプラグインを使って、毎回の議事録から発生した課題チケットのみを一覧抽出して表形式で記載する方法でカバーできる。

Wiki Lists - Plugins - Redmine

Redmine Wiki ListプラグインでTracのクエリのように使うアイデア: プログラマの思索

このような機能が洗練されれば、課題チケットから発端となった要件ヒヤリングやレビュー議事録にさかのぼれるし、過去の議事録からどんな課題が発生して解決されたのか、という観点でドリルダウンすることもできる。
つまり、課題チケットと議事録Wikiの間でトレーサビリティを実現できる。

特に、上流工程では、要件や仕様がぶれやすいので、要件から仕様書やソースコードに至るまでの成果物へのトレーサビリティが非常に重要になる。
せっかく顧客の打合せで合意した要件が作業漏れで仕様書に反映されなかったり、設計レビューの指摘事項が上がっているのに仕様書に反映されなければ、下流工程で発見することは不可能だから。

【1-4】もっと突き詰めると、議事録Wikiは、Redmineのバージョンと連動できる方が良い。
なぜなら、要件ヒヤリングや設計レビューは定期的に打合せが開催されるので、そのタイミングで作られる議事録は、イテレーションに対応付けやすいから。
そうすれば、上流工程でも、アジャイル開発のような反復的なリズムで、作業できるようになる。

また、チケットに議事録Wikiと連動したRedmineバージョン情報が自動設定されれば、チケットを見るだけで、どの打合せから課題が発生したのか、分かるし、バージョンのリンクから発生源の打合せにさかのぼれる。

さらに、Redmineバージョン単位に打合せから発生した課題チケットが自然にグループ化されるので、チケット集計もやりやすい。
ロードマップ画面に各バージョン単位で、議事録Wikiの内容と、紐付けられた課題チケット一覧が表示されるし、チケット全体の進捗率も表示される。
よって、ロードマップ画面上で、打合せ単位の決定事項、議論の内容、残課題の内容を全て把握できる。

つまり、要件ヒヤリングや設計レビューでは、Redmineバージョンを打合せのタイミングと同期させ、さらに、RedmineバージョンのWikiに議事録を残すように運用すれば、自然に反復型開発をRedmine上で実現できるはずだ。

【1-5】では、議事録Wikiを発生源として、上流工程のトレーサビリティを実現する仕組みを作る上で、Redmine標準に足りない機能は何か?

一つ目は、Wikiから課題チケットを1クリックで作成する機能。
さらに、バージョン設定画面のWikiページから課題チケットを1クリックで作成できた場合、チケットのバージョン欄に、バージョン設定画面のWikiページのバージョン情報を自動設定するようにしたい。

そうすれば、議事録Wiki→1クリックでチケット作成、チケットのバージョンリンクから議事録Wikiへ追跡、という前方追跡のトレーサビリティが実現される。

二つ目は、議事録Wikiに、作成した課題チケットを一覧表示させる機能。
そうすれば、議事録Wikiの課題一覧表→リンク押下で各チケットへ遷移、という後方追跡のトレーサビリティが実現される。
現時点では、WikiListプラグインを使って、手作業で課題チケット番号を収集して、表形式にまとめなければならない。

但し、議事録Wikiをバージョン設定画面のWikiページで置き換えるならば、ロードマップ画面に、バージョン単位に紐付けられた課題チケット一覧が自動で表示されるので、課題は解決できる。

三つ目は、議事録Wikiの履歴を残す機能。
議事録Wikiをバージョン設定画面のWikiページで置き換えるならば、ロードマップ画面が議事録の履歴になるので、課題は解決される。

【1-6】今後は、Redmineのあらゆる画面で、チケットを1クリックで起票できる機能が強化されると良いと思う。
さらに、起票元の画面にチケットのリンクが残せるように設定できるなど、チケットと起票元の画面で相互リンクできるとなお良い。

理由は、チケット経由のトレーサビリティの範囲を拡張したいからだ。
チケット管理ツールがMSProjectやExcelよりも優れているメリットが、トレーサビリティ機能なので、その範囲をもっと広げて、Redmine単体でトレーサビリティの設定を制御したい。

現状は、構成管理ツール連携による成果物の修正履歴とチケットの相互リンクだけだが、Wikiやフォーラム、ニュースなどとも相互リンクできるようにしたい。
そうすれば、過去の要件や仕様の変更の経緯をRedmine上で追跡できるし、ソース修正がどの仕様に影響して他の機能にどれだけ影響を及ぼすのか、を考えるきっかけにもなるだろう。

実は、以前、似たような機能として、Redmineのフォーラムのメッセージからチケットを起こすプラグインもあった。
しかし、現在のRedmineでは使えないと思う。

Haruyuki Iidaさんのツイート: "フォーラムのメッセージからチケットを起こすプラグイン。フォーラムでの議論から課題が発生することはよくあるので良いかも。Redmine: Activity - Plugins: Issue from message plugin http://t.co/OkR3LWd"

Issue from message - Plugins - Redmine

Redmineプラグインあれこれメモ: プログラマの思索

【1-7】上記のように、チケットを簡単に発行できる機能と相互リンクさせる機能を強化することで、チケット管理ツールの強みであるトレーサビリティの範囲をもっと広げられるはずだろう、と思う。

上記の考えを発展させれば、下記のように整理できるだろう。

1)プログラミングなどの開発工程では、構成管理の配下にある成果物駆動でチケットを起票して、作業状況を管理していく。
もちろん、構成管理の配下にある成果物とチケットは相互リンクされる。
また、ロードマップ画面で、リリースバージョン単位に作業チケットがグルーピングされ、コミットされた成果物までドリルダウンできる。

2)テスト工程では、障害駆動でチケットを起票して、障害状況を管理していく。
もちろん、ソースの修正履歴と障害チケットは相互リンクされる。
また、ロードマップ画面で、リリースバージョン単位に障害チケットがグルーピングされ、修正ソースまでドリルダウンできる。

3)要件定義、設計工程では、顧客との要件ヒヤリング、設計レビューの打合せ議事録駆動で、チケットを起票して、課題状況を管理していく。
打合せ議事録はWikiでバージョン付けされて、課題チケットと相互リンクされる。
また、ロードマップ画面で、打合せの単位で、議事録・確定した仕様・残課題チケットが一覧表示される。
さらに、課題チケットであがった指摘内容は、構成管理の配下にある設計書へ随時コミットされ、チケットと相互リンクされる。

すなわち、上流工程から下流工程まで、チケットの発生源と作業状況を管理するチケット、成果物を相互リンクさせる運用によって、要件から成果物までのトレーサビリティを実現できるはず。
そして、上流工程のトレーサビリティの課題は、「打合せ議事録をWikiで一元管理して、Wikiに課題チケット一覧を生成する」運用で解決できるはず。

つまり、上流工程の顧客打合せで要件や仕様が決まった経緯はWikiに残し、Wikiからチケット経由のトレーサビリティが全てRedmineで一元管理できれば、ナレッジシステムへ進展できるはず。

このアイデアを試してみる。

| | コメント (0)

2017/11/25

Redmineが今後発展する方向のアイデアpart2

2017年末の時点で、Redmineが今後発展する方向について、考えたことをメモ。
2014年時点に書いた時から、幾分状況も変わっている。
以下はラフなメモ書き。

【参考】
Redmineが今後発展する方向のアイデア: プログラマの思索

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

以前、僕が考えていた時は、アジャイル開発への適用、プラクティスやアンチパターンなどのパターン言語への適用が主だった。

僕が今、Redmineによるチケット駆動開発で考えているテーマは下記になる。
幾分重複している。

【1】SW工学への適用
【2】PJ管理ツールとしての開発基盤
【3】Redmineと組織の関係
【4】チケット駆動がもたらす効果
【5】フローとストック、変更管理と構成管理の関係

【1】SW工学への適用

もう一度、Redmineに各種のプロセスや手法を適用した時に、フィットギャップ分析や導入・運用時の注意点などをまとめたい。

【1-1】PMBOKの実装
 →EVMはその一つ。

【1-2】CMMIレベル4を実現するためのRedmine運用方法

たとえば、パナソニック子会社の事例では、CMMIレベル4を目指すために、Redmineを導入・運用することで解決しようとしている。
開発現場を救うプロセス改善の進め方 - SPIJapan2014

CMMIレベル4を実現するには、Redmineのどの機能を使って、CMMIの各プロセス領域を実装すべきか?
フィットギャップ分析して、Redmineの標準機能が不足していると判明したら、その問題をどのように解決するか?
プラグインを作ってRedmineに組み込むか?
ExcelマクロやBIツールなど、外部システムで解決するか?

【1-3】GTD
 →かんばんを使えば実装可能と思っている。
  課題は、より使いやすくするには、かんばんのUIをどのように実現すればよいか?

【1-4】ITIL
 →問合せ管理、サポートデスクの運用もこの範疇に入る。
  ITIL特有の課題は、複数の相異なるワークフローをどのように組合せて、一つのプロセスを実装すべきか?

【1-5】メトリクス収集/集計のためのプロセス基盤
 →各種ソフトウェアメトリクス、進捗・品質・コストのメトリクスを出力する。
  KPIもその一つ。
  たとえば、最大放置日数、平均完了日数(=平均リードタイム)、平均サイクルタイムなど。
  基本はチケット集計のビューを増やせばいい。
  それらメトリクスを使うと、どんな結果や効果を示せるのか?

【1-6】BPMや汎用帳票ワークフロー基盤の適用

【1-7】派生開発、ソフトウェアプロダクトラインへの適用

【1-8】ISO9001、ISMSへの適用

【2】PJ管理ツールとしての開発基盤

Redmineの柔軟な外部I/Fを洗い出してみると、汎用的な開発基盤とみなすことができることは以前書いた。

第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」

【2-1】では、「RedmineはPJ管理の実験ツールである」と考えた時、標準のRedmineでは何が足りないのか?
今までのRedmine勉強会、redmine.tokyoの Unofficial Redmine Cooking を見た限り、いくつかある。

概要 - Unofficial Redmine Cooking - redmine.tokyo

カスタムフィールド内部の項目値設定は、システム管理者以外の権限でも有効化したい。

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

ロードマップ画面で、チケットをD&Dで並び順に変更する。
この機能は、アジャイル開発でプロダクトバックログを整理する時に使う。

カレンダー画面はもっと改良して欲しい。
ユーザ別に週別カレンダー表示など、チーム内でどのメンバーがどのチケットを担当を予定しているのか、一目で分かるようなビューが欲しい。

文書、マイページなども、もっと画面改良できるはず。

他に、開発基盤であるからには、チケット画面のUIは今風にしたい。
スマホなどに慣れていると、RedmineのUIは古くなっている部分がある。

ViewCustomizeプラグインで、どの程度、RedmineのUIを改善できるか?

【2-2】他に、外部ツールとのツール連携はどのように構成すべきか?という課題がある。
たとえば、構成管理ツールGitlab、ビルド管理ツールJenkinsをRedmineと連動するのは普通だろう。

それ以外に、連携した方が良い外部ツールはあるか?

SW構成管理を実現するプロジェクト管理サーバー

【3】Redmineと組織の関係

経験上、「日本では、Redmineは組織に従う」。
日本企業は、自分達の標準プロセスに合うように、Redmineをカスタマイズしたがる。

実際、日本の大手SIが持つ自社の標準プロセスは、工程の名前が微妙に違うけれど、WF型開発の構造と何ら変わらないのに、自社の標準プロセスに非常にこだわりがある。
日本のメーカーも同じ。

【3-1】大規模組織にRedmineを導入した場合、小規模チームで編み出されたチケット駆動の運用ルールがそのまま適用できない場合がある。
複数の部署があり、部署ごとに異なる組織文化があれば、単純な一つのルールで実現するのは難しい場合もあるだろう。

大規模組織で多種多様なプロセスをRedmineで実現して運用する場合、どんな点に考慮すべきなのか?

第15回RxTstudy『大規模組織や多様な業務におけるRedmineの課題』

【3-2】また、Redmineインスタンスと組織、プロセスの関係という問題が出てくる。
大規模組織では、唯一のRedmineインスタンスで標準プロセスを強制して、運用すべきなのか?
あるいは、あえて複数個のRedmineインスタンスを許し、各チームのプロセスに合ったRedmineへカスタマイズすることを許容すべきか?

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

たとえば、気象庁ではあえて複数個のRedmineインスタンスで運用されている。
なぜ、このような運用を採用したのか、その理由や背景、意図が知りたい。

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

数値予報モデル開発のための 基盤整備および開発管理 - 気象庁

(引用開始)
開発管理サーバの特徴として、一つのサーバ上に複数の Redmine を運用している点が挙げられる。
指針が定める開発管理サーバの利用範囲は、気象庁本庁と気象研究所を含めた複数の課室を想定していることもあり、管理する開発対象が非常に多岐にわたっている。
こうした背景からサーバ上で複数の Redmine を運用し、各 Redmine の管理方法の細目は利用するコミュニティに委ねる方式を採用している。
(引用終了)

【4】チケット駆動がもたらす効果

一方、「Redmineが組織文化に変化をもたらす」場合もある。
そもそも、Redmineを新規導入したいという意図を持つ組織では、Redmineがもたらす効果を得たいために目指しているはずだから。

それは、単なる作業の見える化だけではない。
予定していなかったチケット駆動の副次的効果ももたらす。

たとえば、機能別組織で縦割りの雰囲気があっても、Redmine上ではあたかもPJ型組織の構造となり、メンバー間のコミュニケーションが活性化する。
あるいは、障害修正のように、テスターと開発者があたかもペア作業のようにキャッチボールしながら、障害を直していく。
たとえ、オフショアという地理的に離れたメンバーであっても、コミュニケーションの活性化がメンバー間の信頼関係を促進する、という場面を僕は何度も見てきた。

たとえば、Redmineの標準機能で不足している、と感じたならば、システム管理者が言わなくても、メンバーが自発的にExcelマクロやプラグインなどを作り出す。
つまり、ツールがプロセス改善の雰囲気を醸し出し、プロセス改善の方向へメンバーを動機づける、と言う場面を僕も何度も見てきた。

つまり、「Redmineが組織文化に好影響をもたらす」事例を抽出し、それら効果を整理したい。
そして、その効果を得るためには、Redmineの運用で何に気を付けるべきなのか、を明確にしたい。

【5】フローとストック、変更管理と構成管理の関係

【5-1】チケット管理ツール特有の観点として、フローとストックを別々に管理できて、フローとストックの間でトレーサビリティを実現できる点がある。

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

その時、Redmineのどの機能をフローとみなすか、ストックとみなすか、で違いが出てくる。
チケットはフローでもあるし、ストックともみなせる。
たとえば、チケットをXPのタスクカードとみなせば、フローであるし、障害管理票や課題管理票や議事録とみなせばストックになる。

【5-2】では、Redmineでは、フローやストックはどの機能に相当するのか?

フローとストックのアイデアを突き詰めると、変更管理と構成管理の概念に行き着く。
フローは変更管理、ストックは構成管理の対象になるからだ。

昨今ではGit+チケット管理によるモダンな開発が主流だが、その開発プロセスでは変更管理と構成管理が自然に実装されているので、あまり気にする必要がない。

【5-3】しかし、ISO9001などの運用で、構成管理されるべき成果物がExcel設計書である場合、問題がたくさん出て紛糾していると経験上思う。

理由は、変更管理されるべきExcel変更依頼書やExcel作業指示書と、構成管理されるべきExcel設計書が同じようなステータス管理の対象となって混乱しているからだ。
特にメーカーの運用はそうだろう。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

混乱している理由は、Excelドキュメント自体がGitなどの構成管理ツールで管理できていないので、昔ながらのフォルダ管理で運用されているから。
また、作業指示書であるExcel変更依頼書がチケット化されていないために、それもステータス名の付いたフォルダに手作業で移し替える事で、ステータス管理されているから。

【5-4】では、Excel設計書などの成果物は、どのように構成管理すべきか?

本来は、ライフサイクルの長いExcel成果物はGitなどで構成管理すべき。
しかし、Excel文書は構成管理ツールの差分が見れない、などの問題がいくつかある。

JAXAでは、構成管理ツールではなく、Redmineの文書機能拡張のDMSFプラグインで運用していた。

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT: プログラマの思索

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

一方、@akahane92さんの現場では、Excel設計書は全てSubversonで構成管理されている。

「効率・品質・統制」の共通課題に着目した現場主導による ITS 導入事例~OSS 運営ツールで効率的・低コストな導入を実現~ (IPA 「先進的な設計・検証技術の適用事例報告書 2016 年度版 」)

「効率・品質・統制」の共通課題に着目した現場主導による ITS 導入の効果検証~SQIP2014

どちらのやり方が良いのか、というのではなく、Excel文書の構成管理の実装方法をもっと整理したい。

【5-5】僕は、変更管理と構成管理を区別する、という考え方は重要と思う。
なぜなら、チケット駆動で運用しようとしてもチケットが起票されない、という問題の原因の一つに、チケットを仕様書のように細かく書こうとして入力コストが大きくなるから、という事象もあるのではないか、と思っている。

チケットをフローとして流すのを優先するか、ストックとして残すのを優先するのか。
その背後には、変更管理と構成管理の混乱があるのでは、と思ったりする。

【6】上記のように、Redmineで今後試すべき課題とその方向性を思いつくままリストアップしてみた。
「Redmineは先進的なプロセス基盤の実験場」とみなすならば、もっと色んなアイデアが出てくるし、色んな課題が出てくるだろう。

また、上記のアイデアはRedmineに限定されず、他のチケット管理ツールでも同様に実験することができるだろう。
そして、他のチケット管理ツールで実装できている機能は、Redmineに移植することができるはずだし、逆も然りだ。

さらに、「RedmineはPJ管理の汎用的な開発基盤」とみなすこともできるので、ソフトウェア工学やプロセスに興味を持つ人達だけでなく、Ruby開発者も上記の課題解決に加わることができるだろう。
背景の違う人達が数多く議論することで、より有用な結果が得られるだろう。

| | コメント (0)

2017/11/22

Redmineのもう一つのEVMプラグインEVM Calculation Plugin

先日の東京Redmine勉強会で、アンケート資料にあるプラグインを見ていたら、EVMプラグインがあったのでメモ。

【参考】
Redmine.tokyo 13回 参加者アンケート結果

EVM Calculation Plugin - Plugins - Redmine

redmine_issue_evm/README_ja.md at master ・ momibun926/redmine_issue_evm

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

RedmineにおけるEVMの考え方: プログラマの思索

RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索

RedmineからPMBOKのEVMを計測する方法: プログラマの思索

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索

RedmineにおけるEVMの実装方法は、過去にたくさん書いてきた。
また「チケット駆動開発」「Redmineによるタスクマネジメント実践技法」にもアイデアは書いた。

上記のEVMプラグインは、OSSなのにほぼ実用的に使える機能が整っている。
Redmineに予定工数、実績工数が入力される運用があるなら、EVMを使いたくなってくるだろう。

従来はExcelでEVMを管理するしか方法がなかったので、きちんとプロジェクト管理を徹底しているリーダーは、自分でExcelマクロで実装している人が多い。
EVMをきちんと運用できれば、プロジェクトの状況を正確に把握しやすくなる。
特に、製造業の製品開発のように、リードタイムがソフトウェア開発よりも多少長い場合は有効だろう、と思う。

しかし、EVMは運用が難しい。
理由は、いくつかある。
一つは、予定工数と実績工数を入力させる運用は手間がかかること。
しかも、仕様変更や進捗遅れでリスケするたびに、ガントチャートの保守が面倒になる。
そういう場面のために、仕様変更やリスケのタイミングでベースラインを設定して、進捗やコストを比較したいわけだが、その運用も結構面倒。

もう一つは、EVを計算しても、リーダーの感覚ではシステム上計算されたEVとプロジェクトの現状が合致していない場合が多いこと。
普通のEVMでは、WBSの進捗率を元にEVを計算するわけだが、進捗率が50%や90%で停滞したまま放置されてくると、プロジェクトの現状と合わなくなるのは当然。
たぶん、進捗率ベースのEVMの運用は悪手だと思う。
完了チケットでEVを計測する方がいいと思う。

なお、プラグイン上の注意点は、
・EVは進捗率を使わずに完了チケットで計算していること
・バージョンとは別にベースラインを設定してEVMを比較できること、
・チャートの表示にはHigthChartを使っていて商用目的では利用のできないライセンスであること
だろう。

つまり、EVはプロジェクトの現状よりも低めに計算されやすいので、こまめにチケットを分割したり棚卸ししたりすることが必要だろう。
また、ベースライン機能があるので、プロジェクトのスコープが変化した時にEVMの履歴が残せるのは便利。
但し、チャート表示のライブラリのライセンスには注意。

| | コメント (0)

2017/11/19

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT

昨日の勉強会は参加者、スタッフの皆さん、お疲れ様でした。
あいにくの雨にもかかわらず、参加率が約90%で大変盛り上がりました。
楽しかった余韻が冷めないうちに、感想をラフなメモ書き。

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

第13回勉強会 - redmine.tokyo ~『Redmineの今と未来』(2017/11/18) #redmineT - Togetterまとめ

redmine.tokyo 第13回勉強会 - connpass

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

【1】数多くの参加者に感想を聞いた所、JAXA様の講演が聞きたかった、という話もあったが、LTも含めて運用事例からプラグイン開発などの技術、最新バージョンの紹介、ちょっとしたプラグインの利用事例、家庭内のRedmine利用事例など、幅広いテーマで面白かった、という話があった。
また、参加者層も初心者から10年近い利用者まで、年代層も20歳から40代まで幅広かった。

akipiiさんのツイート: "#redminet 今日も参加率90%で驚異的でした。利用事例から技術まで幅広いテーマで面白かったと言う声をたくさん聞けてスタッフ一同嬉しいです。参加者層も初心者より数年経験者の人が半数以上いた。Redmineコミュニティが今後も長続きできるといいなと思う。"

さらに、女子の参加が10名を超えたのも初めてではないかと思う。(正確に数えてない)

akipiiさんのツイート: "#redminet 今日の東京Redmine 勉強会は過去最高で女子率が高くて華やかだったと思う。以前、@agilekawabata さんが、Redmine はおっさんのツールだから若い人や女子は少ないんですよ、と言ってたが、時代が変わった?"

第7回Redmine.tokyoの感想 #redmineT: プログラマの思索

そんなことを振り返ると、多種多様な年齢層や女性という人口的変数、プロジェクトリーダーだけでなくSEPG等の品質保証部の人からプラグイン開発者までの心理的変数というセグメントが幅広くて、たくさんの化学反応があって面白かったと思う。
幅広い利用者が集まるコミュニティになれば、ある人はRedmineを使っているなら常識と思っていても、他の人にとっては新鮮な内容であることも多いだろうから、そういう数多くの議論が発生して、さらに理解が深まるだろうと思う。

たとえば、Redmineのそんな所でつまずくのか、という質問が、実はRedmineというツールではなく、プロセス保証やプロジェクトマネジメントの根本的な問題に触れていたり、とか。
僕も色々気づきがあった。

【2】JAXA様の利用事例で、興味深い点は二つある。

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

【2-1】一つは、フローの管理とストックの管理を明確に別々に分けていること。

akipiiさんのツイート: "#redmineT JAXAでは、議事録はチケット、構成管理すべき文書は、文書管理機能、実際はDMSFプラグインで管理を区別してる。フローの管理はチケット管理、ストックの管理は構成管理ツールでなく文書管理プラグインで制御してる。全文検索プラグインで文書も全文検索できると、かなり良… https://t.co/AVf8WAHtsc"

Redmine本来の設計思想では、日々流れるフローのような管理対象はチケットにする。
タスク、かんばん、ISOの変更依頼書のように、作業指示書のようなレベルのものは、ステータス管理の方が重要だ。
つまり、日々のフローで管理する時、担当者とステータスに着目する。

一方、ストックのような管理対象は基本は、GitやSubversionのような構成管理ツール、あるいはWikiに蓄積する。
たとえば、ソースコードやExcel設計書は構成管理ツールの配下で履歴管理したり、技術や共有情報などのナレッジはWikiに蓄積する。
あるいは、チケットそのものを議事録にしたり、障害管理票のようにチケットに障害の発生原因や修正履歴を追記して、チケットそのものをナレッジにしてもいい。

Redmineのメリットは、フローとストックの管理を一つのツールで一元管理できるので、フローとストックの間で相互リンクを貼ることにより、トレーサビリティを実現できることだ。
よって、成果物から要件の発端まで前方追跡して変更理由を探したり、発端となった要件から成果物まで後方追跡して仕様変更の影響範囲を探る、といった使い方ができる。
この運用ルールが「No Ticket, No Commit」であり、他のプロジェクト管理ツールにないチケット管理ツール特有の最大の特徴でもある。

しかし、JAXA様の運用では、ストックの管理はRedmineの文書管理にDMSFプラグインを入れて活用されている。
この点がRedmine本来の設計思想と大きく異なる。

その理由を推測すると、成果物の対象がExcelであるため、構成管理ツールだけでは文書の変更の権限制御がやりにくい点があるのだろう。
そこで、DMSFプラグインを入れることで、Excel文書の変更履歴を残したり、Excel文書の参照・更新の細かな権限制御を付けることで、より使いやすくしているわけだ。

たとえば、外部委託したベンダーには特定のExcel文書は参照権限はあるが、更新権限は与えない、といった使い方をしたい場面があるのだろう。

【2-2】もう一つは、Redmineではボトムアップで運用ルールを柔軟に変更して、より良くしていく手法がある点。
Redmineは管理画面にあるワークフロー、ロール、トラッカー、カスタムフィールドを細かく制御できるので、運用しながら標準プロセスを固めていくことも可能だし、そういうやり方の方が普通なのではないか。

akipiiさんのツイート: "#redmineT Redmine の良さは、管理機能をフレキシブルに変更できる点。実際の運用は、かなり試行錯誤した、とのこと。プロセス標準化は一夜にしてならず、ですね"

akipiiさんのツイート: "#RedmineT 更新ロールと参照ロールに分ける。基本ワークフローは、全般トラッカーと名付けて、プロジェクトごとでカスタムフィールドを切り替えて利用する。つまり多様なプロジェクトの構造を管理画面の機能で制御するわけだ"

たとえば、Redmineの基本ロールは「PJ管理者」「開発者」「報告者」だけだが、実際に運用してくると、PJ管理者とシステム管理者の間のロールが欲しくなってくる。
その場合、「ロールのORルール」を用いて、「システム管理者でない管理者」のロールを新規作成し、各プロジェクトで各ユーザにそのロールを追加付与すればいい。
すると、既存のロールをいじることなく、既存ロールにパッチを当てる感じで、権限を細かく制御できるようになる。
たとえば、基本ロールと追加ロール、参照ロールと更新ロールのようにロールを細かく作っておけば、ロールのORルールを適用して、数多くのバリエーションで権限制御できるようになる。

すなわち、運用で試行錯誤しながら、ロールやワークフローを再定義したい時に、Redmineではパッチを当てる感じで既存の運用フローを修正していくことが可能なのだ。
こういう運用が可能な理由は、Redmineの管理画面の機能が豊富で柔軟であるからだろう。
換言すれば、Redmineの豊富で柔軟な機能をもっと理解しておけば、最初からトップダウンで完璧な運用を目指すのではなく、運用しながら標準プロセスを固めていく、といった、アジャイル的な発想を取り込めるはずだ。

僕はアジャイル開発が好きなので、ソース修正だけでなくプロセス構築にもアジャイル的なやり方を組み込むことは、実現不可能と思っていないし、むしろ、トップダウンでガチガチに固めてしまってメンバーのやる気を失わせるよりも、メンバーのより良い意見を取り入れながらチーム一丸でRedmineをより良く使いやすくしていくことは可能だと思っている。

【3】前田剛さん、堂端さんからRedmineの次期バージョン4.0に関する講演があり、興味深かった。

Redmineウォッチャーとしては、Railsの最新バージョンに追随する形でRedmineもどんどん最新化して欲しい。
性能面、セキュリティ面、今後の機能追加のしやすさ、を考慮すれば、開発基盤の最新バージョンに追随して欲しいから。
講演によれば、Ver4.0は早めにリリースしたい、とJPLが言っていた、とのこと。

Ver4.0で問題になってくるのは、既存プラグインがそのままでは、ほぼ使えなくなることだろう、とのこと。
Rails5に追随できるようにプラグインの修正が必ず発生する。
過去のRedmneのバージョンアップでも、追随できなかったプラグインは数多くあったので、利用ユーザは注意すべきだろう。

前田剛さんのアドバイスでは、古いRedmineはあらかじめVer3.4へVerUpしておくべきこと。
理由は、Rails5ではRuby2.2.1未満は切り捨てられるので、Ruby2.2.1に対応済みのVer3.4のRedmineで動作できるようにしておくと事前に検証できるから。

【4】他の講演も面白かった。
Redmineの利用が深まる中で、色んな問題意識があげられていて、興味深かった。

RedmineとSlackなどのコミュニケーションツールは、どのように使い分けた方がいいのか?

お子さんの宿題管理にRedmineを適用し、EVMや分析を行ったが結局使いこなせなかった、とのこと。
このLTも、普段のRedmineとは違う観点で面白い、という別の参加者の感想もあった。
個人的には、Redmineが使いこなせなかった理由には、Redmineが見れるPCをお父さん部屋しか置かず、子供の導線上で見える化しなかった点もあるのでは、と思った笑。

akipiiさんのツイート: "お母さんの反省点はRedmineが見れる端末を廊下と子供部屋に置くことかな笑。RT @agilekawabata: お母さんの反省会で導線が大事だったということで、JAXAの事例にもあったように、ホーム画面に担当者が必要となる導線を置くことはとてもいいと思う #redmineT"

【5】Redmineの面白さは、プロジェクトリーダーや品質保証部の観点でプロセスを自分で構築できて運用を試せる一方、プログラマの観点で不足機能をカスタマイズしたりプラグイン開発してより使いやすくできる、という両面があることだろうと思う。

すなわち、前者の観点では、Redmineは標準プロセスの運用基盤またはメトリクス収集・集計のプロセス基盤である一方、後者の観点では、Redmineはプロジェクト管理ツールの汎用的な開発基盤とみなせることだ。
つまり、ソフトウェア工学の観点とRuby開発の観点の両面からRedmineをいじくり倒せる点が、面白い点なのだろうと思う。
そして、その両方に詳しい人はほとんどいないので、Redmineコミュニティで多種多様な人達が集まることで色んなメリットが出てくる。

僕もRubyやRailsをちょっとずつ勉強しなくては、ね。。

他の資料はコチラ。

| | コメント (0)

2017/11/11

第13回東京Redmine勉強会の見所 #redmineT

@madowindaheadさんが第13回東京Redmine勉強会の見所を公開されていたので、自分も書いておく。
以下、ラフなメモ書き。

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

門屋 浩文さんのツイート: "来週の第13回https://t.co/EeqCzge6c7の見どころ! #redmineT https://t.co/7T2RrBBjUb @madowindaheadさんから"

第13回redmine.tokyoの見どころ! | MadosanPlace 新しい風をプラス!

【1】今回のテーマは『Redmineの今と未来』。
スタッフと企画した時に、Redmineの運用や管理面の講演は現時点の話、次期バージョン4.0に伴う技術面の講演は未来の話だね、という意見が出て、このテーマに決まった。

【1-1】運用面の話は、見える化の話とJAXAの利用事例のお話。
Redmineのチケット集計結果を見える化する内容は、特に、プロジェクトリーダー層が興味を持つだろう。
彼らから改善要望として出てくる意見のほとんどが、このテーマに関わる内容だからだ。

また、JAXAのRedmine利用事例をようやく東京でも講演頂けるようになった。
昨年夏にRedmine大阪で講演して頂きましたが、その時の内容からブラッシュアップされている、とのこと。

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

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

JAXAのRedmine利用事例で興味深いのは、Redmineの機能を論理モデルの観点で階層構造でモデル化していること、その分析内容を元に「ロールのORルール」「カスタムフィールドのANDルール」などのプラクティスを生み出して、利用プロジェクトの多様性をRedmineの機能で制御しようとしている点だ。

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

これは、アナリシスパターンにおける「知識レベル・操作レベル」に相当する、という指摘もあった。
その後、他にどのようなプラクティスを研究されているのか、楽しみ。

【1-2】Redmineの次期バージョン4.0では、Rails5に対応が予定されているので、アーキテクチャが大幅に変わることになる。
特に、既存のRedmineのプラグインは、現状のままでは全く動かなくなる、という指摘があった。

そこで、Rails5におけるプラグイン開発の内容、さらに初心者向けにRedmineプラグイン開発のお話も合わせて、アジャイルウェアの堂端さんに講演を依頼することになった。
日本では、OSSのプラグイン開発者が多いし、スタッフにもプラグイン開発者がいるので、直接的に役立つだろうと思う。

【1-3】LTでは、数多くの方に講演していただくことになった。

特に、ファーエンドテクノロジーの石川さんのお話が個人的に興味がある。
理由は、Redmine本家にガントチャートの改善パッチを送られているからだ。

Redmineのガントチャート改善パッチに注目している: プログラマの思索でも書いたけれど、Redmine標準のガントチャートは正直使いにくい。
チケットタイトル欄の枠を広げたい、担当者を表示したい、ガントチャート画面上で編集したい、などの改善要望は2010年頃からずっと、Redmine本家にも要望があがっていたのに、ずっと改善されて来なかった。
しかし、ようやく、石川さんがパッチを送ってくれて実現可能性が上がった。
今は、Ver4.1のターゲットバージョンで設定されている。

Redmineを改善するパッチを書いて、OSSへの貢献もする仕事 - ファーエンドテクノロジー株式会社

また、日本ではRedmineの利用度合いが高いのに、Redmine本家へのフィードバックが少ない状況に対し、石川さん他幾人から、Redmine本家へのパッチが最近あげられている。
まだ少ないけれど、利用ユーザだけでなく開発者として日本人も貢献できればいいな、と思う。
(自分もやらねば、ね。。)

| | コメント (0)

2017/10/31

Redmineを受け入れて貰うためのプラグイン紹介の記事が素晴らしい

Redmineを受け入れて貰うためのプラグイン紹介の記事が素晴らしいのでメモ。
WF型開発に固執した古い体質の現場で、Redmineをいかに使いやすくするか、という観点で読むと、とても参考になる。

【参考】
Redmineを受け入れて貰うためのプラグイン紹介 - Qiita

親チケットの詳細ページに表示される子チケットの一覧項目 - Google グループ

【1】(引用開始)
Redmineは小規模なチームでも比較的簡単に導入できる、素晴らしいソフトウェアだと思います。
ただ、このようなツールを知らない人や絶対Excelマン達にとっては、得体の知れない面倒なモノと思われてしまうこともあります。
そういった人たちにも積極的に利用して貰うためには、日々の業務で感じるイライラを極力減らす努力が必要ではないでしょうか。
この記事では、Redmineを少しでも快適に使って貰うため、開発者にとって有用なプラグインを紹介していきます。
以下は中の人の背景です。

Redmine 3.1.2~3.3.2
運用を始めて1年ちょっと
WBSっぽく運用すべく親子チケットをがんがん使う

対象プロジェクトの性質
保守
ウォーターフォール
古い体質
(引用終了)

最近は、Redmineが良さそう、という話を聞いて導入し始める人達が多い。
しかし、WF型開発に固執した古い体質の現場では、RedmineをBTSとして扱うだけでも、アレルギーを起こす人たちもいて、導入に苦労する時が多い。
では、そういう古い体質の現場で、導入のボトルネックになる部分はどこなのか?

【2】個人的には、ボトルネックになる部分はUIの部分ではないか、と思う。

WF型開発に固執した古い体質の人達であっても、障害管理や課題管理の重要性は分かっている。
そして、自分なりのやり方も持っている。

だが、ExcelやMSProjectに慣れすぎているために、そういう使い方ができないとイライラしてしまうのだろう、と思う。
だから、BTSを使おうとしても、結局はExcelに出力してExcelで管理を周囲に強制していまいがち。

こういう問題点は、おそらく他の業務システムでもよく出てくる。
ERP、SFA、原価管理システムなどでも、データを入力すれば、後は自動的に集計してくれるのは便利。
しかし、そのデータを出力してカスタマイズしたい、とか、もう少し見やすくして欲しい、とか、細かな要望は数多く出てくる。
結局、ExeclのようなUIが欲しいのだ。

だから、ERPのような業務システムでは、Excelライク、Windowsライクなデスクトップ上のクライアントアプリが重宝される。

では、どうやれば解決できるのか?

【3】一つの対策としては、上記のように、Redmineのプラグインを導入して、ExcelライクなUIや入力を促すような通知機能を機能追加してみることだろう。

【3-1】上記の記事の紹介プラグインで思うことはいくつかある。
一つは、親子チケットに関する機能改善が多いこと。

MSProjectでガントチャートをバリバリ使う人ほど、Redmnieの親子チケットを多用する。
従来の管理イメージをそのままチケットに表現できるからだ。
しかも、Redmineでは、チケットの階層は無制限なので、いくらでも深く作れるので、すぐに慣れる。

しかし、いくらRedmineの親子チケットが良いと言っても、従来のExcelやMSProjectに似た感覚にはならない。
そこで、下記プラグインが紹介されている。

たとえば、チケット一覧画面では、親子チケットの構造の表示がイマイチ。
そこで、subtask_list_accordionプラグインを導入すれば、子チケット一覧のツリーを折り畳みできるようになる。

Redmine Subtask List Accordion - Plugins - Redmine

また、子チケット画面の表示項目をカスタマイズできるプラグインもある。

Subtask list columns - Plugins - Redmine

つまり、subtask_list_accordionやsubtask_list_columnsのプラグインを使うことで、親チケットから子チケットへドリルダウンするUIが強化される。
親子チケットが使いやすくなることで、従来のWBS管理のやり方を変えることなく、Redmineへスムーズに移行しやすくなるはず。
さらに、こういう機能が強化されることで、チケットにより多くの情報を入力する動機づけにもなるだろう。

なお、Redmineの親子チケットに関するアンチパターンは以前書いた。
Redmineの機能制約によってアンチパターンが生まれるけれど、Redmineはプラグインを簡単に開発できるので、解決のハードルは低いと思う。

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

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

【3-2】もう一つは、チケットの状態を通知する機能改善があること。

Redmineのようなチケット管理ツールの最大のメリットは、情報共有だ。
各メンバーの作業や障害の情報は、チケットに記載されて公開されることで、誰もがアクセスして情報共有できる。
しかし、最新情報を常に取得するのは面倒、という声も多い。
また、初めてRedmineを使う人がよく発する声は、チケット更新通知メールが大量に来るので困る、という内容。

そこで、それらの苦情を和らげるプラグインがいくつか紹介されている。
これは便利だと思う。

In App Notifications - Plugins - Redmine

(引用開始)
チケットの変更通知をRedmine上で受け取れます
メールを見に行く面倒さがなくなります
リアルタイム性が増します

「通知の在り方はこうあるべきだ」と思わせてくれる快適さです。
現行バージョンで動作させるには若干変更が必要かもしれませんが、その手間を掛けるだけの価値はあります。
自分でカスタマイズすればより便利です。
(引用終了)

Issue Badge - Plugins - Redmine

(引用開始)
このUIは、担当チケットを早く消化したいという気持ちにさせてくれます。
(引用終了)

ameya86/redmine_news_balloon: 新しいニュースがあれば、吹き出しでページ右下に表示するプラグインです。

(引用開始)
新着ニュースを右下にバルーン表示してくれます
能動的に情報を取りにいかない人にも、新たな情報の存在を知らしめることができます
要現行バージョン対応

積極的に情報を取りに行く習慣がない人が多いチームでは、こういった機能は有効です。
(引用終了)

個人的には、@akiko_pusuさんのBannerプラグインも追加したいかな。
システム管理者が一斉通知したいニュースもあるから。

Banner - Plugins - Redmine

これらプラグインによって、担当チケットを消化していくべきだ、とか、メールボックスを逐一見る必要がなくなる、とか、PJ管理者が書いたニュースを自然に見るようになる、とか、色々なメリットが出てくる。

いくらツールを入れても受動的な人は、性格や行動はそう簡単に変わらない。
人という生き物は保守的だから、そう簡単に昔の習慣は変えられない。
そこで、特にUI部分に着目して、使いやすいUIや気づきやすいUIにすることで、受動的な人たち、保守的な人たちも最新情報を共有するようになるだろう。

【4】そういう問題や解決策を考えると、システムのUIは機能面と同じくらい重要なのだろうと思う。
いくら機能が豊富でも、UIが使いにくければ誰も使わない。
使わないシステムは、ウン千万円もするおもちゃに過ぎなくなる。

つまり、信頼性と同じくらい、使用性もすごく重要な品質特性なのだ。
特に、最近はそういう傾向が強いせいだろうか、ユーザエクスペリエンス(UX)のような概念が提唱されているのではないか、と想像する。

また、RedmineはRailsという柔軟な開発基盤のおかげで、プラグイン開発が容易であるだけでなく、昔からJavaScriptとの相性も良い。
だから、ViewCustomizableプラグインを使って画面の細かなレイアウトを即座に修正できるし、WebアプリであってもデスクトップアプリのようなUIも実現しやすい。

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

プログラミングできるプロジェクト管理者なら、Redmineみたいに、自分が考えた開発プロセスを実現できるだけでなく、自分が欲しいけど不足している機能を簡単に追加できるツールはとても重宝するのではないか。

【5】Redmineを段階的に運用していく場合、@MadowindaheadさんのPMxTMマトリクスによるポジショニングマップが参考になると思う。
Redmineを使うユーザのレベルに対し、Redmineをどのように導入すれば運用が定着するか、という観点で読めば参考になると思う。

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

第12回redmine.tokyo参加報告 あるPMOの独り言/ウェブリブログ

| | コメント (0)

2017/10/27

メールアドレスの正規表現でユーザグループを自動設定するプラグインredmine_auto_assign_group

@two_packさんが、メールアドレスの正規表現でユーザグループを自動設定するプラグインredmine_auto_assign_groupを公開されていたのでメモ。
これは面白い。

【参考】
Tatsuya Saitoさんのツイート: "Redmineにユーザー追加時、メールアドレスに対して正規表現で設定したルールに従って、グループを自動的に設定するプラグインです。 会社ごとなどで対象プロジェクトなど、利用範囲を自動的に限定するような用途を想定しています。 https://t.co/YXEEfBkrK5"

two-pack/redmine_auto_assign_group: Redmine Auto Assign Group Plugin

akipiiさんのツイート: "協力会社のユーザ管理に便利そう。RT @two_pack: Redmineにユーザー追加時、メールアドレスに対して正規表現で設定したルールに従って、グループを自動的に設定するプラグインです。会社ごとなどで対象プロジェクトなど、利用範囲を自動的に限定するような用途を想定しています。"

使い方は下記に画面キャプチャ込で記載されている。

Usage ・ two-pack/redmine_auto_assign_group Wiki

管理画面でルールタブを開き、メールアドレスに対して正規表現にマッチするルールとユーザグループを対応付けて設定する。

使い道としては、社内にいる協力会社ユーザをユーザグループで自動設定でまとめたい時に有効だろう。
例えば、協力会社ユーザが@XXX.com、@YYY_ZZZ.co.jpのようなメールアドレスのルールがあれば、ルールごとにユーザグループを指定すればよい。
案件ごとに一括請負しているベンダーのユーザのメールアドレスが違うならば、たぶんそのまま使えるだろう。

Redmineのチケット管理では、担当者にユーザグループをアサインできるので、こまめにユーザグループを作っておくと使いやすくなる。
しかし、実際はその保守の方が面倒。
そこで、redmine_auto_assign_groupプラグインを使えば、メールアドレスのルールによってユーザグループを自動設定できるので、便利。

RedmineのLDAPユーザ管理と組み合わせれば、ユーザマスタ保守やユーザグループ保守がかなり楽になるのではないか。

こういうプラグインを@two_packさんが開発された背景を想像すると、Redmineのユーザマスタ保守をもう少し便利にしたい、という動機があったのだろうと推測する。
その動機やアイデアを元にOSSでプラグインを公開されているのは、本当に素晴らしいと思う。
なぜなら、特に日本の企業では、同様の利用シーンを持つユーザが多いだろうと思うからだ。

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索にも書いたけれど、RedmineコミュニティにいるOSSプラグイン開発者は、とても重要な存在と思う。
彼らが活発に開発して公開してくれることで、Redmine標準で物足りない部分をカバーしてくれるし、Redmineの新たな使い道や機能を実現してくれるからだ。

今後も、Redmineプラグインの動向については色々探ってみたい。

| | コメント (0)

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さん、@two_packさん、@onozatyさんたちがすぐに思い浮かぶ。
また、日本企業でも、アジャイルウェアなど、Redmineプラグインを専門に開発するSI企業も結構いる。

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

より以前の記事一覧