[#Redmine] 我、なぜRedmine贔屓となりしや

どのBTSを選ぶかという議論になると、ついつい機能比較になりがちです。しかし、Redmineには機能では比較できない特徴があります。それは「後発」であることです。後発ということは「後出しジャンケン」ならではの有利点があり、後発が追いつく際の「ベロシティ」(速さ)が維持されていることです。

Redmineはその設計にTracの影響を受けていると言われています。このため、類似点も多く、プラグインを含めて議論すると、あまり違いはなくなってしまいます。

しかし、Redmineには後発のメリットを生かした(Tracにない)以下のような特徴があります。

・後出しジャンケン
　- 標準機能の充実
　- トラッカー

・ベロシティ
　- さらなる機能追加
　- Ruby on Rails

１．後出しジャンケン

後発の有利点は何と言っても後だしジャンケンです。先発のソフトウェアでは、すでに広く使われるようになり変更が難しくなった点があるのに対して、それらを含めて新たな設計ができるからです。

1.1 標準機能の充実

たとえばTracは豊富なプラグインが特徴である反面、プラグインがなければ利用できるのは基本的な機能に限られます。一方のRedmineは、プラグインも多くあるものの、TracではPluginが必要な機能が、標準機能となっています。ガントチャートもそのような標準機能の一例です。

標準機能が充実していることは、オールインワンパッケージのリリースを早くする効果ももたらしています。プラグインを含めたオールインワンパッケージでは利便性が向上する反面、プラグイン同志が競合することもあって動作確認に一定の時間が必要になり、バージョンアップに機敏に対応することが難しくなるはずです。

Redmineにも最近日本語化されたBITNAMI(http://bitnami.org/stack/redmine)をはじめとするオールインワンパッケージが存在すますが、それらはRedmineの基本パッケージが中心です。同梱されるのは、疎な結合を持つバージョン管理システムSubversionなどとの組み合わせですので、Redmineのバージョンアップ後の比較的早い時期にオールインワンパッケージがリリースされています。

1.2 トラッカー

Redmineはトラッカーごとにワークフローを簡単に変更することができます。一般にチケットの種類(トラッカー)はチケットの一属性にすぎませんが、Redmineではトラッカーを特別な扱いにすることで、各トラッカーのワークフローとして、ユーザのロールごとに現在のチケットの状態から遷移可能な状態を設定することができます。このワークフローの特徴によって、障害管理とタスクの管理のワークフローを別々に設定するなど、業務に合わせた柔軟な管理が可能になります。このワークフローはとても柔軟ですので、ソフトウェア開発以外の業務においてもRedmineが使われています。

２．ベロシティ

Tracはとても手になじむツールです。Versionというたった一つの属性であっても、コミュニティの意見をうまくまとめながら仕様変更が行われています。一方のRedmineは最近のChiliProjectの騒動に見られるように、全員の合意よりもさらなる機能向上を求めているような雰囲気があります。これは、後発プロジェクトの勢いそのままに、追いつけ追い越せと言った感じで、現在も素早い機能アップが続いています。それは、基盤にRuby on Railsを用いていることも影響しているのでしょう。

2.1 さらなる機能追加

Redmineは独自機能も充実しています。特徴的な標準機能だけでもサブタスキング、PDF出力、プラベートチケット、などがあります。サブタスキングとはチケットの階層化のことで、大規模プロジェクトのタスクをWBSのように階層化してチケットで管理できるようにします。階層化されたチケットはガントチャートで表示できるだけでなく、さらにPDFで出力することも可能です。プライベートチケットは最新バージョンの1.2.0からサポートされた非公開のチケットです。セキュリティの更新などRedmineプロジェクトのタスク管理に必要なことから生まれたようですが、チケット数が膨大になる大規模なプロジェクトでも効果的に使うことができるでしょう。

2.2 Ruby on Rails

Redmineの実行環境は、基盤であるRuby on Railsの思想を受け継いで柔軟に選択できます。特にバージョン管理システムの対応に関しては充実していて、CVS、Subversion(リモートも可能)、Git、Mercurialなど6種類以上の環境に対応しています。もちろん、データベースもMySQL、PostgreSQL、SQLiteといったものに対応しています。

このような感じで、仕事上ではあまり使っていないRedmineですが、贔屓(ひいき)の障害管理ツールになっています。

[#TiDD] アジャイル開発への壁 #RxTstudy

ついに「Redmineでのタスク管理を考える勉強会＠大阪(RxTstudy)」が立ち上がりました。Twitterに話題が出てから約2日で企画され、募集から1日程度で30人の定員に達しました。しかも満員になってからも補欠(キャンセル待ち)が20人以上で鵜など、企画者側もびっくりの盛況ぶりでした。東京でもRedmineのコミュニティが発足するようですので、チケット駆動開発がいよいよ盛り上がると期待しています。

恥ずかしながら私も、今年のデブサミでベストスピーカ賞をいただいた発表を再演しました(資料、Ustream)。

勉強会の概要

今回お勉強会では、あきぴーさんのアンチパターンのお話(資料)、中村さんのRedmineの事例発表(資料)やLTのほか、Redmine本の著者4人によるパネル(Ustream)や、そのうちのお一人である倉貫さんの基調講演(資料、Ustream)もあり、活発な意見交換が行われました(Ustream @bufferingsさんによるtogetter　@akipiiさんによるtogetter)。

取り上げたい内容は多々あるのですが、ここでは以前から気になっているアジャイル開発への壁という観点で、最近考えていることをまとめたいと思います。

・契約

多くのソフトウェア開発は請負契約で行われていることから、契約時に仕様(スコープ)を決めた上で、開発が始まるといういかにも従来型開発向きな契約になっています。準委託契約、いわゆる期間契約であれば、スコープを後から変更することもできるのですが、一度に発生する費用を減価償却できないという問題が生じてしまいます。

この点、倉貫さんの基調講演の請負をクラウドで実現して、納品をなくすという方法は、一定額を常に払う契約ですので、顧客・開発双方にWin-Winの関係が築けるかもしれません。類似の契約には永和システムさんの「価値創造契約」がありますが、クラウドに限定することで納品をなくし、リリース後のサービス向上も容易になりそうです。

・レイヤ構造

これは先日のSEA関西でのスクラムワークショップで教わったことです。開発者が一つのタスクに集中できるように作業を割り振るには、作業分担がレイヤごとになってはいけないというお話から気づきました。

ワークショップでのお話の趣旨は、画面担当、ビジネスロジック担当、DB担当のように担当を分けると、常に作業を割り当てることが難しくなり、複数のプロジェクトを掛け持つ必要が出てくるというものでした。

このことを拡張して考えると、フレームワークなどしっかりしたアーキテクチャが別にあり、その上の薄くて広いところの開発だと開発する機能に単純な優先順位をつけることができますが、別のレイヤに分けてしまいがちな別サーバとの通信やハードウェアとの並行開発だと単純な優先順位をつけることが困難です。アジャイルリリーストレインやスクラムオブスクラムという方法があるものの、依存関係によって、スコープの変更に制約を受けてアジャイルのメリットを生かしにくいように思います。

・顧客との関係

最後に、一番難しいのは顧客との関係ではないでしょうか？ソフトウェアが企業の命運を握っていることは間違いないはずなのですが、やはり「おまかせ」のお客さんも多いように思います。また、協力的な顧客であっても、ステークホルダー(利害関係者)が多くて、意思決定が困難な場合などは、アジャイル開発が難しくなると思います。

これは、顧客の予算どりや契約とも関係しています。詳細な仕様を決めずに商品化(リリース)までの予算を決定できるかどうかが、難し意場合もあると思います。また、意思決定が遅れると、作業が止まってしまいますので、請負開発では開発側の大きな負担になります(その点、一定の金額をいただける契約は、開発側のリスクを減らしてくれる宇土思います)。

おわりに

チケット駆動開発は、残念なアジャイル開発と呼ばれることがあります。これはアジャイル開発がある程度有効だと思われるのにアジャイル開発できない、上記のような場合に有効であることを示している言葉だと思います。

関西の勉強会(RxTstudy)はRedmineだけでなくタスク管理がその名前に入っていることから、大いに期待しています。

Shibuya.trac 第10回勉強会 #shibutra

実はtracもけっこう使っているので、デブサミ後のShibuya.trac 第10回勉強会はとても楽しみにしていました。なんと60人も集まった勉強会は期待を裏切らないものでした。

特にOかもとさんの発表は、デスノートがその語源のtrac lightning後継のKANONの発表という、ホットなものでした。このKANONは、ベースをLinuxにし、アジャイル開発を意識し、MS Project互換のOpenProjectと連携するというなかなか期待できる内容でした。

懇親会では、OかもとさんからWindows上では改行コードの問題で開発しにくかったこと、ユーザの方からは社外の協力会社に使ってもらうにはセキュリティ上Linuxの方がうれしいというお話が聞け、それぞれなるほどと、思いました。

名古屋から来られたこくぼさんは、Redmineでブイブイ言わせているとの触れ込みでしたが、「本物」でした。小規模アジャイル開発ならBacklogsプラグインは、とても便利だと思いました。

すでに、発表資料とお試しRedmineまで用意されています(背景のかわいい赤ちゃんがないのが残念！)。

この他にも、充実したLTあり、ネットでしか知らなかった多くの方々や、初めての方々との出会いと語らいがあり、非常に充実した勉強会でした。

スタッフの皆様、会場をお貸しいただいたニフティの皆様、発表者ならびに参加者の皆様、本当にありがとうございました。

詳しい内容はWikiからたどれると思いますので、ぜひご覧ください。

[#TiDD]チケット管理システム大決戦 JIRA vs Redmine vs Trac - デブサミ2011 その３ - #itsjp #devsumi

サブタイトルを含めると

「チケット管理システム大決戦 JIRA vs Redmine vs Trac ～ユーザーが語る、なぜ私はこのツールを使うのか」

というこのパネル、初めて聞いた時には時間が短いこともあり、「そんなパネルで大丈夫か？」といまどきの言葉で心配していました。しかし、皆さん紳士的でそれぞれの特徴を述べながら「チケット管理システム(BTS)を使いましょう！」との共通の思いを語られていたのが印象的でした。

逆に言うと、もう少しバンバンやってもらっても面白いかとも思いましたが、あきぴーさんが書かれているように最終日に別の場所であったShibuya.Tracで、Web上で続けられることになりました。楽しみです。

私個人は、条件を付けずにいうならデフォルトでガントチャートと親子チケット(サブタスキング)が可能なRedmine(あるいはChiliProject)かと思いますが、多くの意見を取り入れて手になじむTracも良いと思います。

BTSの議論を聞いていると、パソコンの前のマイコン時代の議論を思い出します。あのころもそれぞれに特徴があって、多くの議論が行われたのですが、個人的な結論は詳しい知り合いがいるなど「情報が得られるものを選べ」でした。

Redmineでも、Tracでも、それぞれの機能の差よりも、入れてからの使いこなしが重要なので、自分に合った情報源のあるものを選べばよいかと思っています。そういう意味では、(使ったことはありませんが)有償のJIRAなども有効な選択肢ではないかと思っています。

そういう考えですから、この新しいWeb上の大決戦のような活動で、どの程度アピールできるかが、仲間(ユーザ)を増やすポイントになるんだろうと思います(とあおっておきます)。。

[#TiDD] 出版裏話７：trac, mantis,すべてのBTSをお使いの方に

「Redmineによるタスクマネジメント実践技法」をすでにお読みの方はお気づきだと思いますが、本書のターゲットはRedmineのユーザだけではありません(もちろん、タイトルにRedmineと入っているように、インストールの説明がないことを除けば、Redmineの基本的な使い方や、プラグインについてもしっかり載っていますので、Redmineの本としても満足していただけると思います)。

このブログで出版の案内をしたとき、

　史上初の「チケット駆動開発」の本が出版に

とタイトルにつけました。これには裏話があるのです。

この本の企画を検討していたとき、タイトルにRedmineを入れるかどうかの議論がありました。チケット駆動開発の環境として、ワークフローの設定やサブタスキングなど、Redmineはとても良い環境です。しかし、チケット駆動開発そのものはツールに依存するものではありませんし、そもそも提唱者のまちゅさんはtracを使われていました。

しかし、タイトルにチケット駆動開発が入らないという大人の事情がありましたので、もう一つの売りであるRedmineがタイトルに入りました。

タイトルにあわせて、内容もRedmineの本として満足していただけるように構成しました。しかし、純粋なRedmineに依存しないチケット駆動開発の説明も入れたいということで、第1部に関しては、Redmineとは独立して一般的なチケット駆動開発関連の説明を書いています。

このほか、詳細目次を見ていただければ分かりますが、本の後半もすべてのBTSを使われている方にも参考にしていただける内容になっています。

Redmineじゃないからと思っておられたなら、ぜひ一度手にとってみてください。

＃『行きなさい。わたしが、あなたを遠く
＃　異邦の民へつかわすのだ』
＃(日本聖書協会 口語訳 使徒22・21)

[#TiDD] 好評「Redmineによるタスクマネジメント実践技法」お早めに！(追記+)

おかげさまで、あきぴーさんとの共著の「Redmineによるタスクマネジメント実践技法」が好評です。アマゾンでは書籍全体のランキングで342位まで上がりました。みなさま、ありがとうございます。

地元京都の書店を何軒か見てきました。

• ブックファースト(四条河原町)　１冊
• ジュンク堂(BALビル)　　　　　　３冊
• ジュンク堂(四条烏丸)　　　　 　０冊

不思議に思って、四条烏丸のジュンク堂で検索したところ、15日には2冊あったようですので、売り切れていたようです。

「Redmineによるタスクマネジメント実践技法」の初刷部数はそれほど多くないので、書店で確認される方は、早めにしていただいた方が良いかもしれません。

10/17追記：

京都駅周辺では以下の様子でした。

• 大垣書店京都駅前店(イオンモール)：3冊
• アバンティ京都：3冊(面陳列：表紙が見えるようにおいてありました)

10/20追記：

大阪梅田周辺では比較的潤沢にあるようでした。

• ジュンク堂(堂島店)：11冊(面陳列)
• 紀伊国屋(阪急梅田下)：6冊(平棚)
• ヨドバシ梅田：不明(見つけられませんでした)

[#TiDD] 出版裏話６：「Redmineによるタスクマネジメント実践技法」 販促チラシ

「Redmineによるタスクマネジメント実践技法」の販促チラシ(PDF)ができました。ぜひ、お知り合いにもご紹介ください。

近頃は、書籍のチラシを見ることも少なくなりましたが、出版社のご好意で作っていただけました。ありがとうございました。

# Go into all the world and
# preach the Good News to everyone.
# Mark 16:15 (New Living Translation)

[#TiDD] 出版裏話５：「Redmineによるタスクマネジメント実践技法」 詳細目次

どこまで公開してよいものかと思っていたのですが、翔泳社オンラインショップで詳細な目次が公開されていたので、ここでも公開します。本当はもっと内容があったのですが、あまりにもページが増えたので何節かを削除しています。今回は、そのときのことを書こうと思います。

この本の特徴は、共著者のあきぴーさんの人脈でたくさんのレビュアをお願いしたことです。チケット駆動開発の提唱者であるまちゅさんをはじめ、「JUDEで学ぶシステムデザイン」の著者で出版のきっかけを作ってくださった細谷さん、オープンソース開発にRedmineを使われている黒田さん、TEF関西でおなじみの仲さん、そして、説明不要の平鍋さんと倉貫さんにはレビュアのほか「まえがき」まで書いていただきました。

書いている本人は、熱くなっているのですばらしい本になったと勝手に思っているのですが、やはり色々な方にレビューしていただくと多くの指摘をいただきました。おかげさまで、かなり改善することができました。（どうもありがとうございました。＞レビュアの皆様）

泣く泣く削除する際も、削除の候補のうちどうしても残した方が良いもの、逆に消したほうが良いもがあれば教えてください、と質問をさせていただきました。結局、削除候補以外の削除した方が良い節はなく、逆に削除候補からは「残してほしい」とレビュアの方からのお言葉をいただいて復活した節があります。この件で、少しは自信を持つことができました。

出版が近づいて、まえがきを書いていただいたお二人にはTwitterやブログで紹介していただけたました(重ねて感謝します)。なんとか人に紹介していただけるレベルになったのかとほっとしています。特に平鍋さんの「チケット管理システムをつかってみよう！」は感動的な紹介ですので、ぜひお読みください。

----- 目次 -----
はじめに
まえがき　-平鍋健児-
まえがき　-倉貫義人-

プロローグ　-開発現場で試行錯誤した経験談-
  　Redmine導入前の問題点
　　Tracは使いこなせなかった
　　Tracによるチケット駆動開発
　　Redmineによるチケット駆動開発で運用を工夫した点
　　Redmine導入後
　　Redmineによるチケット駆動開発でさらに気付いたこと
　　Redmineによるチケット駆動開発の可能性
　　まとめ

第1部 チケット駆動開発技法　-BTSによる作業管理-
　第1章 障害管理ツール(BTS)
　　1.1節 ソフトウェア開発の難しさ
　　1.2節 BTSの歴史
　　1.3節 オープンソースBTSが選ばれる理由
　　1.4節 障害管理の目的
　　1.5節 障害管理からチケット管理
　第2章 BTSとツールの連携
　　2.1節 構成管理ツール
　　2.2節 構成管理ツールの歴史
　　2.3節 ブランチとメインラインモデル
　　2.4節 他の支援ツール
　第3章 チケット駆動開発　-チケットによるタスク管理-
　　3.1節 チケット駆動開発が生まれた背景
　　3.2節 チケット駆動開発の誕生と発展
　　3.3節 チケット駆動開発とは
　　3.4節 TiDDのチケット
　　3.5節 BTSのチケットの特性
　　3.6節 チケット駆動開発とソフトウェア工学
　　3.7節 Redmineの構造とWBS
　　3.8節 チケットの候補
　　3.9節 コミュニケーションと見える化
　　3.10節 日々のプロセス
　　3.11節 マネジメントとトレーサビリティ
　　3.12節 見えるものは制御できる
　第4章 チケット駆動開発(TiDD)のはじめかた
　　4.1節 チケット駆動開発の運用方式
　　4.2節 チケット駆動開発の権限ポリシー
　　4.3節 [事例]下流工程でのチケット駆動開発
　　4.4節 [事例]XPのプロセス改善
　　4.5節 TiDDはプロジェクトのアジリティを高める

第2部 Redmineによるタスク管理
　第5章 Redmineの運用方法
　　5.1節 Redmineの特徴
　　5.2節 Redmineのインストール
　　5.3節 チケット駆動開発の運用サイクル
　　5.4節 Redmineチケットの概念モデル
　　5.5節 Redmineチケットの状態遷移
　　5.6節 Redmine運用フロー
　　5.7節 有用なRedmineのプラグイン
　　5.8節 バージョン0.9の新機能
　　5.9節【速報】最新バージョン1.0.1
　第6章 Redmineの高度な使い方
　　6.1節 チケット
　　6.2節 バージョン
　　6.3節 プロジェクト
　　6.4節 ワークフロー
　　6.5節 レポート出力
　第7章 チケット駆動開発の実践的な運用方法
　　7.1節 アジャイル開発と組み合わせて運用する方法
　　7.2節 並行開発と組み合わせて運用する方法
　　7.3節 チケット駆動開発のプラクティス
　第8章 チケット駆動開発を発展させるアイデア
　　8.1節 PMBOKのEVM
　　8.2節 測定できれば制御できる
　　8.3節 Redmineと外部ツールを連携
    8.4節 ITILと組み合わせて運用する方法
    8.5節 大規模プロジェクトで運用する時の注意点

第3部 RedmineとTestLinkの連携
　第9章 TestLinkの運用方法
　　9.1節 TestLinkの概要
　　9.2節 TestLink運用前のテスト工程における問題点
　　9.3節 TestLinkの概要モデルと運用サイクル
　　9.4節 TestLinkの運用例
　　9.5節 TestLinkの運用後
　　9.6節 TestLink運用のまとめ
　　9.7節 TestLinkのプラクティス

エピローグ　-チケット駆動開発の魅力-
参考文献
参考資料
索引

＃とか書いていると、あきぴーさんに先を越されました
＃(Redmine.jpの紹介記事まで書いてるし、、)。orz

# Because God's kingdom is already among you.
# Luke 17:20-21 (The Message)

[Redmine] チケット更新のチェック (Mylinの設定あり)

「竜馬が行く」に載っていた北辰一刀流の極意に　

　気は速く、心は静か、身は軽く、技は激しく

という言葉がありました。常に備えながらも落ち着いて、いざという時には素早く効果的に行動するということなのでしょう。これは、ソフトウェア開発にも言えると思います。

Redmineには、Webでチケットの更新を確認するだけでなく、以下のような方法でチケットの更新を即座に知ることができます。

1. メール

もっともオーソドックスな方法です。チケットの更新内容を読めますので、メールを常に読める環境では有効でしょう。

2. RSS

メールの環境を整えることが困難な場合、RSSはリーズナブルな選択でしょう。RSSリーダーのほか、メールツールやWebブラウザでもチェックできます。更新内容全文が通知されるわけではないので、ブラウザの併用が必要です。

3. Mylin

eclipse環境の方はこれが便利でしょう。Redmineにソフトをいれる方法もありますが、入れなくてもWebテンプレートによって接続できます。

確認できたのはAll in One Eclipse3.6です。3.5はエラーが出ました。

1. WebテンプレートをEclipseにプラグインする (アップデートサイト)http://download.eclipse.org/tools/mylyn/update/incubator
2. その後の設定についてはhttp://www.memorycraft.jp/2009/06/mylyn-redmine.htmlの「タスクリポジトリ追加」以降を参照する。ただし、「拡張構成」の部分だけはこのサイトの通りではうまく動きません。
3. 「拡張構成」の設定内容はhttp://www.google.co.jp/url?sa=t&source=web&cd=1&ved=0CBUQFjAA&url=http%3A%2F%2Fwww.redmine.org%2Fwiki%2F1%2FHowTo_Mylyn&ei=TIqRTKGXK8fIcdWRkOkG&usg=AFQjCNFkampcHB4OmeisifnC78ug73NmoA&sig2=gxHxxi_UL_PfLv607TafiA を参考に

日本語入力とダーツに造詣の深いgoldbachさん(勝手に名づけました。すみません)に教えていただきました。感謝！

このほかにもREST APIを使うことも可能でしょう。パワーのある方は試してみてください。

＃気をつけて、目を覚ましていなさい。
＃その時がいつなのか、あなたがたには分からないからである。
＃(日本聖書協会新共同訳 マルコ13・33)   

[Redmine] 基本操作：三角と十字をクリックしてみよう！

TIPSと言うほどでもない基本の操作です。

右向きの三角や十字のマークを見つけたらクリックしてみましょう。
隠れている機能が出てきます(バージョンによって表示される内容は異なります)。

右向きの三角

右向きの三角を押すと、

十字

十字マークを押すと、

＃ 探しなさい。そうすれば、見つかる。
＃ 門をたたきなさい。そうすれば、開かれる。
＃ (日本聖書協会　新共同訳 ルカ11・9)