Redmine

2019/02/11

RedmineユーザはRedminersと呼ぼう~We are Redminers!

RedmineユーザはRedminersと呼ぶらしいのでメモ。

We are Redminers! というフレーズは何かカッコイイね。
「ルビーを掘る人」「赤いのを掘る人」という意味なわけか。

【参考】
たかのあきこ@devsumi15-D-6さんのツイート: "I am really happy to receive 100 stars. Even it took almost 7 years.... Thanks to all the Redminers and kindly communities! #redmine… https://t.co/31xibjfZV4"

MAEDA Goさんのツイート: "I have installed your really nice plugin to hundreds of Redmine instances. Thank you for creating and maintaining redmine_issue_templates!… https://t.co/qtSGqUFA8p"

akipiiさんのツイート: "Redmine ユーザーをRedminersと呼ぶのですね。初めて知りました笑… "

昌。さんのツイート: "初めて知りました。笑 使おう。がんばれベアーズみたいでカッコいい… "

門屋浩文@redmineエバンジェリストの会??さんのツイート: "積極的に使っていきます WE are Redminers!… "

たかのあきこ@devsumi15-D-6さんのツイート: "ルビーを掘る、という意味でRedmineと思ってます^^ フォーティナイナーズも金採掘にちなみますよね。世代的に49年生まれの方もマッチするかな。… "

齋藤さんのツイート: "なるほど。元々「赤いのを掘る」であってるのか。赤いのを掘る人=redminers ですね。ふむふむ。… "

| | コメント (0)

2019/01/31

RedmineのGit連携機能に関する議論

Redmine本家で、Git連携機能に関する議論があって、興味深いのでメモ。
結論のないラフなメモ。

【参考】
Feature #14961: Reconsider moving from svn to git &GitHub - Redmine

Feature #30069: Integrate Redmine with GitLab (or other free CI system for open source) to run tests - Redmine

Feature #8363: Git: Pull requests - Redmine

QA #910: RedmineでPullRequestを使いたい - Unofficial Redmine Cooking - redmine.tokyo

【1】RedmineのGit連携に関する問題は、実は2つの論点があると思う。
1つ目は、RedmineにGitHubやGitLabクローンの機能を入れて、Redmine上でプルリクエストを行いたい事。
2つ目は、Redmine本体の開発は、Gitのプルリクエストを使い、数多くの開発者のパッチによる貢献を取り入れやすくする事。

この2つの論点が混じっているので、議論が込み入っているのではないか、と思う。

【2】実は、Redmineのパッチ開発者の多くは、Redmine本体をGitの構成管理の配下に置き、自由に開発ブランチを派生させて実験したり、プルリクエストをコミッタに送りたい、という要望が大きいのだろう。

Feature #14961: Reconsider moving from svn to git & GitHub - Redmineで、Taiki I さんがこんなコメントをされている。

(Google翻訳の引用開始)
こんにちは恐竜、
この問題が発生してから5年が経過しました。全世界がGitに移行したかどうかはわかりませんが、OSSプロジェクトがPull RequestsとGitによる寄付を集める主流になりました。
Redmineにプルリクエストを実装するかもしれませんが、これは容易ではないでしょう。
まず最初に、RedmineのリポジトリをGitに移動し、プルリクエストを受け付けるようにします。そして、貢献のハードルを下げ、貢献の門を広く開きます。競合品を使っても。
幸いなことにGitLabには「外部課題追跡システム」があります。これで、GitLabのGit管理とプルリクエスト(マージリクエスト)を使用しながら、Redmine.orgの多くの問題をそのまま使用し続けることができます。
この問題についてもう一度話し合いますか?
(引用終了)

但し、その実現が容易ではないことは、Redmineユーザなら皆知っている。

Feature #14961: Reconsider moving from svn to git & GitHub - Redmineで、@g_maedaさんがこんなコメントをされている。

(Google翻訳の引用開始)
現在の状況が気に入らなくても、皆さん全員が紳士的であることを願っています。
何年もRedmineの開発に時間を費やしてきた人々を落胆させてRedmineを改善することはできません。
(引用終了)

【3】僕は、GitHub連携プラグインがRedmineに組み込まれれば、不満はほぼ緩和できると思う。
つまり、プルリクの機能はGitHub上で使い、Redmineのチケットにはその履歴を残す、というように、利用場面を使い分けることだ。
また、Redmineチケットにパッチを添付するのではなく、GitHubのプルリクの内容がRedmineチケットに自動複製されると、もっと良い。

これは完全な解決方法ではないが、プルリク機能の実装は非常に難しいと思う為だ。

【4】この議論のチケットを読みながら、OSSコミュニティを発展させるには、OSSコミッタのモチベーションが最重要であることを思い出した。

オープンソースソフトウェアを開発する日々をハッピーに ― あるいは、OSSコントリビュータに感謝を伝えるためにできること | POSTD

Redmineに不満が出て、数多くの不平を言ってしまうこともあるだろう。
その行為がOSSコミュニティにとって良いことなのか?

下記の文章が心に残った。

(引用開始)
オープンソースに関わる誰かに、シンプルに肯定の意を伝えることです。
メールや、あるいはIRCを通して、はたまたプロジェクトの貢献者に直接会うなど、手段を問わず文字通り誰かに「ありがとう」と伝えることは、とても大きな意味を持つのです。
これが取るに足らないことだとは承知していますが、長い時間をかけてオープンソースに貢献している人たちは、基本的にネガティブな人、あるいは誠意はあるけれども人から何かをしてもらおうとする人たちに相対してきたことを忘れてはいけません。
人にずかずかと要求せず、「ありがとう」と言ってくれる人がいることは、バグ修正などの要求に応えたからのお礼ではなく、プロジェクト全般が感謝されていることが分かるはずです。

この2つの感謝の違いは、愛する人のために何かをしてあげ、相手があなたに感謝の気持ちとしてハグをしてくれることと、同じ人がただ単にあなたが好きだからという理由で不意にハグをくれる、この2つのハグの違いと同じなのです。
前者のハグもすてきですが、後者のハグはあなたをより特別な気持ちにしてくれます。
(引用終了)

最近、Matzさんもこの論点の記事を書かれていた。
Rubyに対する不満がRubyクローンを生み出したこともあったらしい。

Rubyのまつもと氏、「気分を害することもある。だからどうか建設的であってほしい」 - Publickey

そして、Matzさんの回答の一つは、Ruby開発のITSであるRedmineに、提案して欲しい、と。

【5】OSS開発の活発さとOSSコミュニティの活発な議論には相関関係があると思う。
さらには、@t_wadaさんの指摘どおり、OSS開発の活発さと良いソフトウェア設計には密接な相関関係があると思う。
Redmineの良さの一つは、RubyとRailsという柔軟な開発基盤のおかげで、カスタマイズしやすいので、色んな議論ができることだろうと思う。
そのバランスはどこにあるのだろうか?

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

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

| | コメント (0)

2019/01/26

第19回Redmine大阪の見所 #redmineosaka

第19回Redmine大阪の見所を書いておく。

【参考】
第19回 Redmine大阪 - connpass

(引用開始)
テーマ~「次世代プロジェクト管理システム Redmine の未来を考える」
約1年ぶりに、待望のRedmine のメジャーバージョン4.0がリリースされました。
今回の勉強会では、さらに機能改善されたRedmineの解説だけでなく、下記の内容を提供します。

最新バージョンのRedmineでのチューニング結果報告
国内で代表的なプロジェクト管理ツール Redmine・JIRA・Backlog の有識者を招いて、プロジェクト管理ツールについてディスカッション

Redmineの初心者から、Redmineをバリバリ使う経験者まで、興味のある方はぜひお越しください。
(引用終了)

1年ぶりの勉強会の見所は、次の3つがある。

【1】@akahane92さんの「Redmineチューニングの実際と限界 ~ 200万チケットでもサクサクなRedmineの作り方~ 改訂4版」

Redmineチューニングに関しては、世界トップクラスの@akahane92さんが最新バージョン4.0の性能評価、チューニング技術に関して報告して頂く。
特に興味深い点は、全文検索プラグインを使った性能評価だ。

Redmineの全文検索プラグインが、Redmineにとってとても重要な理由は、Redmineをナレッジシステムとして実現する為に重要な機能であるからだ。
その理由は下記に書いた。

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

Redmineの全文検索プラグインには、Redmineに蓄積された過去のチケット、Wikiなどの情報を高速に検索できるだけでなく、GoogleのPageRankのように重要度の高い順にソートしたり、Amazonのお勧め商品のように類似チケットを表示する機能などがある。
この機能がRedmineに組み込まれれば、システム保守や顧客問合せなどのデータをRedmineに蓄積するほど、Redmineにその会社のナレッジが蓄積されていくので、Redmineは有用なナレッジシステムになる。
さらに、昨今の機械学習や人工知能のライブラリをアドオンで組み込むなどすれば、より的確な情報を提供するだけでなくアドバイスすることも可能になるだろう。

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

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

@akahane92さんの講演内容は今後、詳細が明らかになっていくと思うが、既にRedmineをIT全般統制(ITSMS)に適用して実運用されている背景を考えると、Redmineの全文検索プラグインがIT全般統制の内部監査で重要な役割を担っているのではないか、と推測される。

すると、ISO9001やITSMSのマネジメントシステムにRedmineをうまく当てはめる事が出来れば、Redmineの導入対象は、ソフトウェア企業だけでなく、製造業などの会社にも導入できることになり、Redmineの活用範囲が広がるだろう。
実際、既にITILとRedmineは相性が良いのは知られているので、ISO規格にあるマネジメントシステムとのフィットギャップ分析さえできればいい。
その辺りも色々聞いてみたい所。

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

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

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

そうなると、今後の課題は、Redmineの添付ファイルも全文検索プラグインの対象に入れて、Redmineを真のナレッジシステムにすることになるだろう。
なぜなら、RedmineのチケットやWikiだけでなく、チケットに添付されたExcelファイルまで全文検索の対象になれば、より重要な情報を的確にいつでも高速に抽出できるからだ。
そうすれば、Redmineにどんどん情報を蓄積していこう、というユーザの動機付けにも役立つだろう。

Ver4.1で、添付ファイルを全文検索する機能が提案されているので、今後の動向も要チェックだ。

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

【2】アジャイルウェア 堂端さんの「GitHub連携プラグイン」

Redmineの課題の一つには、Git連携がやりにくい、という点が10年前からあった。
現状の機能では、Bareリポジトリを手動で作ったり、Gitlabと連携できるように構築するなど、手間がかかる場合が多い。

今回の講演では、GitHub連携プラグインを提供されるということ。
このプラグインは、Redmineユーザにとってメリットが大きいと思う。

GitHub連携プラグインのメリットは2つある。
一つは、GitHubとRedmineと連携できることで、チケット管理はRedmine、プルリクやフォークなどのソース修正はGitHubという使い分けが簡単に実現できること。
以前から、RedmineとGitlabの連携は試みがされてきたが、GitHubでも使い分けが可能になる。

もう一つは、GitHubが無料のプライベートリポジトリを使用可能にしてくれたおかげで、個人のソース管理やドキュメント管理はGitHub、プライベートなタスク管理はRedmine、で置き換えられること。

GitHub、無料ユーザーもプライベートリポジトリを使い放題に - ITmedia NEWS

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索

マイクロソフトがGitHubを買収した後、GitHubが非常に使いやすくなったので、GitHub連携プラグインはとてもタイムリーな内容だと思う。

【3】「プロジェクト管理ツール Redmine・JIRA・Backlog によるうちの子の良い所、他の子の欲しい所」

現在調整中だが、Redmine、Jira、Backlogという著名なプロジェクト管理ツールのエバンジェリストをお呼びして、それぞれのツールの良い所を紹介してもらい、自由に議論してもらおう、という企画。
企画の隠れた目的には、そういう議論の内容をRedmineの機能改善に役立てたい、という気持ちも込められている。
個人的には、とても楽しみな内容。

なお、このパネルディスカッションの企画を手伝っている時に、過去の「チケット管理ツール大決戦」の企画を思い出していた。
2011年のデブサミで、チケット管理ツール大決戦という企画が非常に盛り上がって、その企画がユーザ投票で3位にランクインされたのを思い出す。

チケット管理システム大決戦第二弾 Trac vs Redmine vs JIRA vs Backlog を開催しました!勝者は? - I18n and L10n in My Life

デブサミ2011レポート~チケット管理システム大決戦: プログラマの思索

[#TiDD]チケット管理システム大決戦 JIRA vs Redmine vs Trac - デブサミ2011 その3 - #itsjp #devsumi: ソフトウェアさかば

2/17: デブサミ 2011 / チケット管理システム大決戦

チケット管理システム使用状況の調査結果(デブサミ) | Atlassian Blogs

【資料公開】チケット管理システム大決戦 第二弾 | Ryuzee.com

Excel大好きな日本企業の組織文化は、たぶんその頃から変わっていないように思う。
だから、それぞれの製品のメリットを強調するだけでなく、世の中の業務の問題解決にプロジェクト管理ツールが役立てればいいなあ、と思っている。

【4】既に満員御礼になっていますが、懇親会は人数を増やせるので、懇親会からの参加もOKです。

| | コメント (0)

2019/01/21

RedmineをフォークしたOpenProjectのリンク

下記の記事で、RedmineをフォークしたOpenProjectなるものを知ったので、リンクしておく。

【参考】
「近代化Redmine」ことOpenProjectでスクラム開発のプロジェクト管理 - Qiita

ExcelおじさんとGitHub若者が共存するためのタスク管理法 - Qiita

ExcelおじさんとGitHub若者が共存するためのタスク管理法 ? Be full stack?? | SI からフリーランス

【1】@g_maedaさんのツイートによれば、OpenProjectは、Redmineをフォークしたらしい。
よって、OpenProjectは、Redmineをコア基盤としている訳ではなく、Redmineとは別で発展しているみたい。

akipiiさんのツイート: "後で読む。Redmine のVerIpに追随できるのか、気になる。RT @diffshare: こういうのもあるのか https://t.co/60moUClq42 「近代化Redmine」ことOpenProjectでスクラム開発のプロジェクト管理"

akipiiさんのツイート: "詳細は知らないけど、コア基盤がRedmine なら、バージョンアップに追随できないと運用は難しいかも。Planioサービスは上手くバージョンアップに追随して、凄いと思います。… "

やっさん🍶さんのツイート: "#OpenProject のプラグインが #Redmine のがベースになってるぽいので、Redmineクローンなのかも。 openproject-local_avatars/local_avatars.rb https://t.co/htY5Qtnbda opf/openproject: OpenProject is the leading open source project management software. https://t.co/iISR8GZPy4… https://t.co/SOdVSfhRUV"

MAEDA Goさんのツイート: "2011年にRedmineをフォークしてChiliProjectができました。 https://t.co/35fGcR87fd さらに2012年にChiliProjectをフォークしてOpenProjectができました。 https://t.co/WOvyOEtHGm 現在はOpenProjectは独自に進化していて、Redmineのバージョンアップには影響されないと思います。… https://t.co/pB0P50Enmz"

【2】OpenProjectの特徴は、RedmineのVer2時代のBacklogsプラグインの拡張版として捉えられることだろう。
ScrumやかんばんをRedmine上で使いたい人には、朗報かもしれない。
今どき、Excelでプロジェクト管理するのはしんどいからね。

(引用開始)
こんな人におすすめ

今までRedmine + Backlogプラグインで頑張ってた人
・スクラム開発用に「かんばん」と「バックログ」が欲しい
・プロジェクト管理用に「ガントチャート」も欲しい
・でも、Redmineにプラグインを入れる苦行は回避したい…
・日本語化されててほしい
・簡単に環境構築したい
ExcelおじさんとGitHub若者が共存するためのタスク管理法 - Qiita みたいな環境の人
(引用終了)

Dockerで簡単にインストールできる点もいい。

詳細はまだよく分からないが、「微妙な点」の内容が面白い。
「推奨環境がメモリ4GB」となかなか豪快、とか、SPAが微妙、とか、Redmine臭がすごい、とか、まあそういう面はありそう。

RedmineをフォークしたChiliProjectは廃れてしまったが、OpenProjectの動向も追ってみたいと思う。

【追記】
Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしている: プログラマの思索

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

| | コメント (0)

「Git と Redmine を用いた気象研究所共用海洋モデル」の論文のリンク

@g_maedaさんのツイートで、「Git と Redmine を用いた気象研究所共用海洋モデル」の論文を知ったので、リンクしておく。
引用文献に、「ファーエンドテクノロジー: redmine.jp」が掲載されているだけでなく、「Redmine によるタスクマネジメント実践技法」も掲載されているのが嬉しい。

【参考】
GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理

Git と Redmine を用いた気象研究所共用海洋モデル - 日本海洋学会

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

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

akipiiさんのツイート: "後で読む!RT @g_maeda: Redmineの活用に関する論文を見つけた。 GitとRedmineを用いた気象研究所共用海洋モデル「https://t.co/zwcaQuOKca」の開発管理 https://t.co/5BfubPtHsJ"

【1】論文の内容は、気象庁の研究者が、海洋大循環モデルのソフトウェア開発にRedmineとGitを適用することで、開発プロセスを標準化し、効果を上げた、という事例みたい。

海洋大循環モデルのシステム維持はとても大変、という問題意識があったらしい。

(引用開始)
(海洋大循環)モデルの維持・開発はより困難になってきているのが現状である。世界的にモデル開発者数は減少する一方で,モデルのソースコードは日毎に大規模化・複雑化している。
このため,バグの混入や意図しない影響の抑制,つまりソフトウェア品質の維持は非常に難しくなっている。
(中略)
ソースコードは全体で 10 万行を超え,100 近いコンパイルオプションと数 100 に及ぶ実行時オプションがある。
加えて,仕様を変えずにバグ修正だけが必要な現業目的と,次々に機能を追加する必要がある研究目的の両方に対応するため,安定版と開発版の2 系統を維持しなければいけない。開発が始まってからおよそ 20 年が経過し,過去の絡み合ったソースコードの整理・再構成も必要である。
これらソースコード自体の複雑さに加えて,その利用が多様化しているという問題もある。長い開発期間の結果として,MRI.COM は,日本沿岸海況監視,季節予報,将来気候予測など,気象庁と気象研究所の多様な現業と研究の基盤モデルに用いられ,それぞれの幅広い要望に対応して,同時並行的に開発が進められている。
このような複雑な状況の下で,ソフトウェア品質を維持しながら様々な機能を次々にソースコードに加えていくことが,少人数の開発チームに求められている。
(引用終了)

そこで、GitとRedmineを導入することで、下記を狙ったらしい。

・複数のブランチに対するソースコードの開発履歴を管理する
・作業過程の記録と進捗状況の把握を一元的に行う
・これらのツールを基盤に用いることで,開発者各人がそれぞれのやり方で開発する状況から脱して,システマティックな開発手順を導入する

【2】興味深い点は、Gitの運用フローが詳細なこと、Redmineの運用フローに特徴があること、だと思う。

Redmineの実際の運用フローは以下の通り。
プログラミング作業とコードレビューがチケットの主要な使い方みたいだ。

(引用開始)
1)開発者はまず Redmine チケットを作成し,Fig. 4 のように簡潔に開発内容を記す(いわゆるチケット駆動開発,小川・阪井,2010)。
2)開発者は他の開発メンバー 1 名を「レビュアー」に指名し,ソースコードを編集する前に,変更内容と実装方針について相談する(ただし,簡単なバグ修正であれば必須ではない)。
3)相談結果を踏まえ,開発者がローカルでコード変更の作業を始める。
4)ローカルでコード変更を完成させ(Fig. 2 の手順 2 に相当),レビュアーにレビューを依頼する。
5)レビュアーがコード変更のレビューとテストを行う。レビュー結果は Redmine のチケットのコメントやGit の修正コミットとして開発者にフィードバックされる(Fig. 2 の手順 3,4,5)。
6)コード変更を開発メンバー全員に公開し,チェックとテストを受ける(Fig. 2 の手順 7,8)。
7)検証が終わったコードを幹とする(Fig. 2 で Ver.1.1を確定することに相当)。
これで 1 つのチケットの開発は終了し,確定した歴史となる。
(引用終了)

Redmineの運用のメリットは以下の通り。

(引用開始)
具体的なメリットを以下に挙げる。
1)他人に見られることを前提にしてタスク内容を明文化することで,開発方針が明確になる。
2)担当者や期日が明示されることで,各タスクの優先度の誤認などを防ぐ。
3)実装方針など開発に関する議論が残されることで,他の開発者と将来の開発者はコード変更についての理解が容易になる。開発過程のデータベース化は,次世代の開発者にとって大きな財産となる。
4)開発内容とソースコードが関連付けられ,どのような目的で,どのようにコードが変更されたかを誰もが見えるようになる。これにより,モデル利用者に対して,なぜそのような変更を行ったのかを説明する責任を果たすことになる。これは,現業使用や外部提供もされる MRI.COM にとって重要である。
5)Redmine でチケットを一覧表示させることで,モデル開発の全体の進捗を共有できる。
(引用終了)

気になる点は下記がある。

(引用開始)
上記 5)で挙げた開発進捗の共有は特に重要であるので,実際の MRI.COM の開発について,チケットを一覧表示した Fig. 5 を例にして,より詳しく説明する。
MRI.COM では 1 ヶ月単位のリリース・サイクルを採用しており,例えば 2014 年 5 月末に Ver.3.3.15,2014 年 6 月末にVer.3.3.16 をリリースした。Fig. 5 に示す Redmine でのチケット表示もリリース・バージョンに紐付けられ,Ver.3.3.15 では 16 件の開発事項があったことが分かる。
MRI.COM ではこれらチケット内容をまとめることで,例えばバグ修正 4 件,機能追加 3 件,それ以外が 9 件などの「リリースノート」を,新しいバージョンのソースコードと同時に公開している。
(引用終了)

上記の内容は、ロードマップ画面をリリース計画またはリリース履歴と用いることで、「開発者は自分の作業だけでなく全体の開発の進捗状況も簡単に把握できる。」メリットが得られた、ということ。
「これはチーム開発にとって必須の機能である。」と念押ししているように、ロードマップ画面の機能を十分に理解されていると思った。

さらに読み進めると、スーパーコンピューターのリプレースに向けたモデルの移行作業など、色んなプロジェクトにもRedmineを適用して運用しているらしい。

【3】まとめとしては、下記の通り。
GitとRedmineを非常に上手く運用していることがよく分かる。

(引用開始)
まず,ソースコードの開発履歴を管理するバージョン管理システム「Git(ギット)」と,開発のタスクを管理するプロジェクト管理システム「Redmine(レッドマイン)」を導入した。
そのうえで,開発のステップを,課題の設定,他メンバーへの説明,コーディング,レビュー,テスト,リリースと区分し,そこで行うことを具体的に定める「開発手順の標準化」を行った。これらの取り組みにより,バグの混入や意図しない実験結果の改変を抑制しつつ,モデルの集団開発を効率的に進める体制が確立された。
これによるメリットは多々あるが,とりわけ,複数の開発者による並行開発の円滑化,開発過程のデータベース化,ある変更を本体に取り込む前に他の開発者がチェックする「コードレビュー」の必須化,安定版と開発版の 2 系統維持,テスト自動化は,モデル開発において有益である。
また,開発手順の標準化は,他部署や他機関の人が行ったバグ修正や開発も通常の手順で幹のソースコードに取り込む体制が確立されたことを意味する。
(引用終了)

【4】今後の課題として、下記が挙げられている。

(引用開始)
1 つ目は,開発管理を担っている開発管理サーバーに,セキュリティの制約により外部からアクセスできないことである。2013 年から実施している JAMSTEC,東京大学,九州大学とのモデル開発に関する共同研究では,JAMSTEC のサーバーで Git と Redmine が稼働している。将来的には,より広い共同開発のために,海外主要モデルで行っているように github 等のインターネットでアクセスできるシステムを利用するのが望ましいように思われる。
2 つ目は,ソースコード公開の制約と著作権である。外部ユーザー向けの貸与制度を 2012 年に開始したのに加え,上記の共同研究の参加研究機関内ではソースコードを共有している。しかし,原則として,MRI.COM のソースコードは非公開である。日本の研究コミュニティの支持を得るには,抜本的な変更が必要になると考えられる。
3 つ目は,ユーザー向けサポートである。第 4 節で述べた MXE の作成や,力学フレームワークと主要なオプションを解説したマニュアルの公開などがおこなわれているが,MRI.COM 習熟のハードルは高く,よりきめ細かいサポートが必要である。
(引用終了)

オンプレでGitとRedmineを主体とした開発管理サーバーを運用されているので、外部に公開する時の懸念点が今後の課題として挙げられている、と思った。

【5】3/2に、気象庁の方がSEA関西プロセス分科会で講演されるので、色々聞いてみようと思う。

天気予報を支える数値予報システムの技術 第71回 SEA関西プロセス分科会 - connpass

| | コメント (0)

2018/12/20

Redmine 4.0.0 released !!

ずっと待ち続けていたRedmineのVer4.0がついに先日リリースされた。
ラフなメモ書き。

【参考】
Redmine 4.0.0, 3.4.7 and 3.3.9 released - Redmine

Redmine3.4.0 Released !: プログラマの思索

Redmineの新機能開発チケットの記事のリンク: プログラマの思索

【1】今回のリリースで最も重要な点は、Rails5に対応したことだろう。
最新のRubyやRailsに追随することで、セキュリティパッチや最新ライブラリへの対応などがやりやすくなるはずだ。

【2】リリースされた機能改善のうち、個人的に重要と思うチケットは下記がある。
一つは、メールを非同期的に送信する機能改善だ。

Feature #26791: Send individual notification mails per mail recipient - Redmine

Redmineを導入すると、時々、チケット更新が遅いと言われる時がある。
たいていの原因は、チケット更新のメール送信時にメールサーバーとやり取りしてタイムラグが発生する場合だ。
たとえば、大量のチケットを一括更新すると、メール送信が完了するまで次画面が表示されない症状が発生する時がある。
よって、今回の機能改善により、Redmineの性能改善に役立つ可能性が非常に大きくなる。

もう一つは、Wikiのシンタックスハイライトが100個以上の言語に対応されたこと。

Feature #24681: Syntax highlighter: replace CodeRay with Rouge - Redmine

以前から、VBやC#などのソースがコードハイライトされない問題があった。
だが、CodeRayからRougeへ変更されたことで、この問題も解決された。

よって、チケットやWikiに技術情報をたくさん残そう、というユーザの動機づけにも役立つだろう。
Redmineに情報が集約されれば、いつでも誰でも共有できるからだ。

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

Redmineの次期バージョン3.4の見所: プログラマの思索

【3】リリースニュースの中で、Bernhard Rohloffさんのコメントが最も興味を惹いた。

(引用開始)
Thanks to JP and all the people who made this release possible!
Redmine 4.0.0 will be a great base for further improvements in the future and keeps the community vital.
(引用終了)

(超意訳)
JPLとリリースを可能にしたすべての人々に感謝します!
Redmine 4.0.0は、将来のさらなる改善のための偉大な基盤となり、Redmineコミュニティの存続を維持させてくれます。

特に、日本では、Redmineがプロジェクト管理システムとして、事実上ミッションクリティカルな状況になっているので、Redmineが活発に開発されていくことには重要な意義がある。

今後もRedmineを安定運用したいならば、ソフトウェアの寿命が長持ちするように、Redmineコミュニティもずっと活発で居続けなければならない。
そのためには、熱心なユーザと活発にパッチ貢献する開発者、そして活発にコミットするコミッタの三者の活動が鍵を握る。

幸いなことに、Redmineコミュニティは、プロジェクトマネージャとRuby開発者という、人的属性が相異なるユーザ層から成り立っているので、開発プロセスの運用事例や技術的なカスタマイズ事例だけのテーマに偏ることなく、多様な観点で議論できる強みがある。

今後もRedmineをウォッチしていく。

| | コメント (0)

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

TiDD:チケット駆動開発: ソフトウェアさかば

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

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

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

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


Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

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

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

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

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

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

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

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

2018/12/06

Redmineの新機能開発チケットの記事のリンク


石川さんが書かれたRedmineの新機能開発チケットの記事がとても参考になるのでリンクしておく。

【参考】
いま注目しているRedmineの新機能開発チケット - ファーエンドテクノロジー株式会社

Redmine Advent Calendar 2018 - Adventar

直近のVer4.0に入っていない機能の紹介でいくつか気になるチケットはある。

【1】「プロジェクト一覧画面の改善」は実現して欲しいチケットだ。

Patch #29482: Query system for Projects page - Redmine

Redmineの運用が長くなると、プロジェクトが100個以上に増殖するので、必要なプロジェクトのみ選定して、その内容を見たい、というニーズが多くなる。
特に、現場マネージャの一つ上の経営者層がRedmine上で、複数の案件を一覧で見たい、というニーズが多い。
上記の改善ができれば、経営者層の不満となるニーズを多少緩和してくれる。

【2】「トラッカーの日本語訳変更」は、議論が活発で読んでいて面白い。

Patch #29045: Change Japanese translation for Tracker - Redmine

Redmine初心者は、トラッカーという言葉に慣れていないので、いつもトラブルの元になりやすい。
一方、「トラッカーをなくすと、Issue Trackingという概念が消えてしまう」という意見も確かに納得する。

Redmineのトラッカーは、ワークフローそのものであり、帳票そのものでもある。
トラッカーという言葉には数多くの意味が込められているので、そのニュアンスを消さずに修正するのは本当に難しい。

Redmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されている: プログラマの思索

【3】「トラッカーの説明を追加する」チケットも確かにその通りだ。

Feature #442: Add a description for trackers - Redmine

Redmineを触ったことがないユーザには、トラッカーの意味を説明した後で、現場で定めたトラッカーという業務のワークフローを説明する場合が多い。
その時に、Redmine上で、このトラッカーはこういう意味で運用しているよ、という説明文があると、ユーザは勝手に参照してくれるので、システム管理者は楽になる。

【4】「プロジェクト毎にデフォルトのカスタムクエリを設定できるようにする」チケットもニーズが多い。

Feature #7360: Issue Custom Query: Default Query - Redmine

朝一番にプロジェクトを開いた時、メンバーに見て欲しいチケット一覧をデフォルトにしたい。
そうすれば、マネージャが逐一指示を出さなくても、メンバーは自身の残チケットに着目して作業し始めるはず。

【5】チケットにタグづけ機能は、ぜひ欲しい機能だ。

Feature #1448: Add tags to issues - Redmine

ハッシュタグのように、#をつけてタグ付けして、そのタイムラインを読むのは今は当たり前。
チケットのフィルタリングとして、カテゴリやバージョン等、数多くの方法はあるが、タグ付け機能があれば、より柔軟にチケットの分別ができるようになる。

【6】上記の記事には記載がなかったけれど、下記の機能改善も期待している。

・「@名前」でリンクする
・WikiからODTファイル出力
・マイページの画面改善
・添付ファイルの全文検索

新たな機能改善がマネージャの潜在ニーズを呼び起こし、新しい運用方法の提案や新たな機能改善につながる、という議論のやり取りが楽しい。
そこがRedmineの一番面白い点。

| | コメント (0)

2018/12/04

2018年もRedmine Advent Calendarをやってます

@yassanの発案で、2018年もRedmine Advent Calendarを今年もやってます。
まだ空きはあるので、ぜひご参加下さい。
@yassan、ありがとうございます。

【参考】
Redmine Advent Calendar 2018 - Adventar

【参考2】
Redmine Advent Calendar 2017 - Qiita

Redmine Advent Calendar jp 2011とRedmine1.3に向けての感想: プログラマの思索

お勧めの記事は、前田剛さんの下記の記事かな。
なぜ、Redmineでは「Issue」を「問題」「課題」と訳さず、「チケット」になったのか、その経緯が書かれている。

Redmineの「Issue」の日本語訳はいかにして「チケット」になったか | Redmine.JP Blog

他のチケット管理ツールでは、「チケット」という言葉ではなく「課題」「問題」と訳されている場合が多い。
しかし、Redmineでは、日本語訳がチケットになったおかげで、「チケット駆動開発」という概念が生まれて、日本特有の普及推進になったのだろうと思う。
僕も以前、色々考えていた。

チケット駆動開発の理想と現実: プログラマの思索

Redmineの背景にある「チケット駆動開発」という概念は結局何なのか、もっと考えてみたいと思っている。

チケット駆動開発の原点の記事のリンク: プログラマの思索

| | コメント (0)

2018/11/11

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT

第15回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
また、コミッタの前田さん、数多くのプラグイン開発者・パッチ開発者の方にも感謝です。
以下は、講演を聞いて、感想をラフなメモ書き。

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

2018/11/11 第15回勉強会 - redmine.tokyo - Togetter

日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について: プログラマの思索

Redmineでやってみた - うさぎまんじゅう - BOOTH

【1】参加者の方から、以前の勉強会では講演の数が少なくて、時間を持て余す時が多かったのに、今回の勉強会では講演の数が多すぎて盛りだくさんだった、という感想を聞いた。
確かに、大LT大会になったので、詰め込みすぎたかもしれない。

他方、それだけのコンテンツが集まる事実は、日本のRedmineコミュニティで数多くの事例やカスタマイズのノウハウが蓄積されていることを示しており、コミュニティとして成熟していることかな、と思った。

【2】今回の勉強会のテーマは「Redmineの次バージョン4.0に向けて、皆のノウハウを共有しよう」だったが、隠れたテーマは「日本のプラグイン開発者やコミッタ、パッチ貢献者にコミュニティから感謝の声をあげよう」だったと思う。
@g_maedaさん、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさん、@naitohさん、前田みのるさん他多数のプラグイン開発者に声が届けられて良かったように思う。

中村さんの講演では、現場のRedmineに15個もプラグインを入れていて、プラグイン開発者に拍手喝采を、という内容はまさにそうだった。
Discord上でRedmineコミュニティを運営しているMaxさんの講演も、Redmineのテーマ改善など機能拡張をコミュニティドリブンで開発しよう、という内容だった。

そして、僕のLTでは、Redmineコミュニティがマネージャ層とRuby開発者という二つの全く異質なターゲットから成り立っている特徴を強みとみなし、異質な特徴を持つ彼らが相互交流することで、Redmineの進化を加速させるエンジンになりうるはず、という主張を試みた。

実際、今日の参加者とグループディスカッションや懇親会で話を聞くと、マネージャ層の人達もいれば、プラグインやパッチ等の開発者も多く、多様な参加者から成り立っていた。
たぶん、こういう交差しないセグメントのターゲットが2つ以上もあるようなコミュニティは、非常に稀で、貴重な場ではないか、と思う。

普通のOSSコミュニティは、利用ユーザだけとか、実際の開発コミュニティとか、セグメントがどこかに特定されているような気がする。

【3】では、なぜ、Redmineコミュニティはそのような異質なセグメントのターゲットを2つ以上持つことができたのか?

理由は、Redmineには2つの顔があるからだ。
一つは、「ソフトウェア工学の理論を実験できるプロジェクト管理ツール」という側面で、マネージャ層に対応する。
もう一つは、「汎用的なプロジェクト管理の開発基盤」という側面で、こちらがプラグイン開発者やRuby開発者に相当する。
つまり、全く異なる出身を持つ二つの層が生まれたことで、Redmineの機能改善を相互に議論しあえる場が生まれたように思っている。

たとえば、マネージャ層は、自分達の管理作業を楽にしたいためにRedmineを使うが、Rubyの開発はおそらく殆どの人ができない。
一方、プラグイン開発者は、実際の現場のニーズを元にRedmineに不足した機能を実装し、プロセス改善に役立てる。

Ruby開発者は、マネージャを顧客に見立てて、Redmineに不足した機能を実現できる力を持つ。
一方、マネージャは、プラグインを利用することで、自分達の開発プロセスや組織文化に合わせてRedmineにカスタマイズを施し、彼らのあるべき姿にRedmineをFitさせる。
たぶん、新たなプラグインがマネージャ層の潜在ニーズを刺激し、新たな改善アイデアを生み出すだろう。

実際、今日のLTでもリソース予約プラグインを開発した話があり、タスク管理に使われるRedmineを会議予約システムとみなして使う、という事例もあった。
つまり、柔軟なRedmineのおかげで、マネージャや利用ユーザの潜在ニースが刺激され、数多くのアイデアが生まれる、という良い意味でのらせん構造が生まれている。

【4】すると、今後のRedmineコミュニティの発展に必要な要素は2つあると思う。
一つは、Ruby開発者をRedmineコミュニティにもっと巻き込みたい、ということ。

なぜなら、他の競合のチケット管理ツールに対し、Redmineが競争優位性を保つには、もっとRedmineの進化の速度を上げたいからだ。
現状のRedmineには、いくつかの課題があると思う。

僕が感じている課題については、以前書いた。

Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索

また、Maxさんも同じく、Redmineの画面UIをもっと今風に改善したい、と思われている。

換言すれば、次の3つに課題が集約されるのではないか。

1・シングルページアプリケーション化などの画面UIの改善
2・プルリク実装などのGit連携の機能強化
3・プラグインのGem化、RedmineのVerUpの自動化などの、VerUp自動更新機能

おそらくそれらの課題の解決は、そう簡単なものではない。
だが、多くのRuby開発者をRedmineコミュニティに巻き込めば、実現のハードルは下がるだろう、と思う。

Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

【5】もう一つは、Redmine運用に関する数多くの知見を一つの体系にまとめ上げて、誰もが再利用できるようなプラクティスや知識を提供すること。

なぜなら、大阪や東京のRedmine勉強会で参加者から要望されるニーズは、Redmineの運用事例が知りたい、という内容が多いからだ。

実際、Redmineが生まれて10年以上経った今、障害管理だけでなく、タスク管理、会議の管理、資産管理、ヘルプデスクなど数多くの事例がRedmineで実現されている。

たとえば、今日のグループディスカッションでは、ITILのプロセスをRedmineで完全に実装した事例を持つ参加者がいた。
具体的には、Zabbixで検知したエラーメールはRedmineにチケットで自動登録され、インシデントとして認識される。それらチケットを精査して、修正対応すべきと判断されたチケットは、問題管理へエスカレーションされ、対応策の検討後、リリース管理で開発・リリースされる、という流れ。
つまり、この参加者の方は、システム保守・運用の立場の人なのだろう。

この話は僕も以前経験していて、ITILとRedmineは非常に相性が良いと思っている。
しかし、インシデント管理・問題管理・リリース管理などの各プロセスをRedmineにどのようにFitさせるか、については、運用してみると理論通りにうまく行かない部分がある、というのも経験している。

TiDDにITILの概念を持ち込む: プログラマの思索

Redmine for ITIL: プログラマの思索

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

エスカレーションをRedmineで運用する方法: プログラマの思索

そういうアンチパターンやプラクティスなどのノウハウを、利用シーンごとにまとめて、体系化してみたい。
おそらく、そういう知見を集めて体系化して、その知識を普及させる役割が、Redmineエバンジェリストであり、Redmine警察に相当する人達だろうと思う。

【6】今日の勉強会の中で、ツイートしながら生み出せた考え方は、「Redmine運用の4原則」のようなものがあるのではないか、ということ。
Redmine運用の4原則とは、Redmineがチームに馴染むには、プロセス・ツール・スキル・マインドの4つの要素がいるのではないか、ということ。

この考え方の発端は、Jiraのような多機能なチケット管理ツールの場合、プロセスを実装した経験がない管理者がJiraを使って運用させようとすると、失敗しやすいのでは、という話から生まれた。

ツールを使いこなすには、プロセスを知っておくことが大前提。
そして、ツールを使いこなしたり、プロセスをテーラリングできるスキルも重要。
また、プロセスやツールを受け入れるマインドもいるね、と話が広がった。

しかし、本当にこの4つで十分なのか、MECEに整合性が取れているのか、この4原則でアンチパターンの事象を演繹的に説明できるか、については検証が必要、と思っている。
でも、この4原則を検証してみるのは価値がある、と思う。

【7】最近の僕が個人的に持っているRedmineのテーマは「組織とRedmineは相互にどんな影響を与えているか」だ。

具体的には、組織構造がRedmineにどんな影響を与えて、Redmineをどんな方向に複雑化させるのか。
一方、Redmineを導入し運用することで、組織文化にどんな影響を与えて、組織にどんなメリットを与えてくれるのか。

例えば、縦割りのガチガチの組織構造は、単一の標準Redmineのワークフロー設定、トラッカー設定を複雑化させる。
その複雑化に現場が対応できなくなると、各事業部や各チームごとにRedmineインスタンスが乱立し、野良Redmineが生まれ、IT統制が効かない状態になりうる。
つまり、組織のやり方にRedmineをカスタマイズしてフィットさせて、プロセスをテーラリングしたいが、実際は理論通りにテーラリングはうまくいかない場合が多い。

一方、縦割りの組織にRedmineを導入すると、Redmineの機能に埋め込まれたベストプラクティスをメンバーが自然に受け入れることで、チームの作業が効率化されることもあるだろう。
また、Redmineがメンバー間のコミュニケーションを活発化させ、より良いプロセス改善がもっとできるのでは、というメンバーの貢献意欲を引き出す場面もあるだろう。
つまり、Redmineはチームの文化を変容させる力を持っている。

そんな経験を踏まえて、「Redmineは組織構造に従う」「Redmineは新たな組織文化を生み出す」という二つの双方向な事象を整理したいと思っている。
実際、Redmineを利用しているマネージャは大企業の方が多いので、組織構造や組織文化とRedmineのバランスを見出すことに苦労しているのではないか、と思うからだ。

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

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

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

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

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

グループディスカッションでも、懇親会でも、参加者が持つRedmine運用の問題意識にはこれらが関係しているような気がした。

以前「Redmineによるタスクマネジメント実践技法」で当時の自分が考えていたアイデアは全て書いたけれど、上記のテーマでまた新たに書いてきたくなるなあ、と思った。

| | コメント (0)

より以前の記事一覧