第5回品川Redmine勉強会の感想 #47redmine

第5回品川Redmine勉強会にスタッフとして参加してきました。
盛り上がって楽しかったです。
資料をリンクしておきます。
感想をラフなメモ書き。

【参考】
第5回勉強会 - shinagawa.redmine

第5回品川Redmine勉強会 2013/6/29 - Togetter

【1】@sakaba37さんの資料。
共通結合、データ結合などのソフトウェア結合度の観点と業務フローの類似性のお話と、社内業務にRedmineを適用した事例のお話。
構造化設計のお話は、今では情報処理試験に出るくらいしか使わないから、ピンと来る開発者はいたのかな？
社内業務で、PC資産のタスク管理にRedmineを使った事例は興味深かった。
ある業務でタスクが発生して、そのタスクを管理したい時、チケット管理は有効であるように思う。

チケットシステムの可能性 - 開発から業務まで - from Makoto SAKAI

【2】その後、「マネージャ」「開発者」「運用担当者」「Redmineシステム管理者」の観点でワークショップ形式で議論した。

第5回品川Redmine勉強会～開発者がRedmineを使いこなすには？ from akipii Oga

第５回品川Redmine勉強会の資料 from Masanori Machii

運用業務でのRedmine from Tomohisa Kusukawa

Redmine admin from Jun Naitoh

いろんな議論が出てきた。
皆同じような問題を持っているのね、と共感している人も多かった。

僕が興味を引いたのは、顧客との打合せ管理にRedmineを使っている人の話。
顧客との打合せや会議の準備で、タスク管理と工数管理をチケット管理で実施している。
トラッカー＝顧客単位でチケットを発行し、全て打合せや会議の工数を記録し、月末に工数集計して顧客報告して請求するという流れ。
実績工数の作業分類にも、打合せの作業の種類に分けて、実績工数に色付けして入力・集計しているらしい。

この事例は、RedmineをCRMソフトとして使おうという発想であり、更に工数集計ツールとしても使おうとしている。
このアイデアは、第8回勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索にも書いたけれど、顧客問合せ(つまり、コールセンターやサポートデスクの管理)の管理機能にも関連する。
この辺りのアイデアはあとでまとめる。

他には、@naitohさんのRedmineシステム管理者としてのノウハウや事例が面白かった。
RedmineのVerUp作業は結構面倒だ。
Redmineを導入すると、開発チームはRedmineなしでは作業できなくなるので、気軽に改造したりVerUpして正常動作しなくなるのが怖いので、VerUpするのが難しくなる。

@naitohさんの話では、Ver1.4からBundlerでRubyGemをインストールするようになったおかげで、インストールしたRedmineの単位でRubyGemを管理できるようになった。
だから、Ver1.4以降では、異なるバージョンのRedmineを併存するのも問題ないとのこと。
特にVerUpするための検証作業で、既存の古いバージョンのRedmineと、検証中の最新バージョンのRedmineを一つのサーバーに入れている時は、Ver1.4以降なら問題ないみたい。

但し、プラグインはRedmineのVerUpで動作しなくなるので要注意とのこと。
Redmineは2.1になるまでに、Rails2→3、Ruby1.8→1.9、Prototype→JQueryへアーキテクチャが変わったために、追いつけていないプラグインが多い。

第8回RxTStudy勉強会で@marutosijpさんが言っていたように、プラグインと言えどもテスト自動化して日々ビルドする環境がなければ、ミドルウェアやライブラリのバージョンアップ作業に追いつけずに破綻してしまう危険があるのだろう。
改めて、TDDとCIの強みを印象づけられた。

また、Redmineのバックアップはやってますか？という質問もあった。
@naitohさんは、SQLiteなのでファイルコピーでやってます、とのこと。
@akiko_pusuさんからは、MySQLならDMP出力、Redmineの添付ファイルはrsyncでお手軽にやっています、というお話もあった。
DBのDMP出力、ファイルの同期作業は、Cronで日次に夜間に実施するなどすればよいだろうと思う。

【3】@tkusukawaさんのテーマ説明やLTでは、ヘッダに電子公告のように流れるメッセージが面白かった。

Twitter / hiyoshism: 勉強会の真っ最中に上司から「Redmineの導入は見送ります」というメールが届いた俺が来たよ。 #47redmine

Yggdrasil（ゆぐどらしる） ～ サーバ運用のNo Ticket, No Work ～ from Tomohisa Kusukawa

【4】日経システムズの記者さんのLTでは、記者の眼 - 「新3種の神器」で開発現場を改革しよう：ITproの記事の裏話を少しだけ聞くことができた。
読者アンケートを取った結果では、Redmineの読者評価が高いらしい。

Twitter / akiko_pusu: Redmineの特集は何回もやってます。なぜか読者評価が高いです。アンケートでは普及率22% #47redmine

日経システムズという雑誌は、IT業界でしか読まれないだろうし、日経の雑誌を購入する層を考えると、SIの中堅～大企業の30代以降のSEやPM層が多いだろうと思う。
20代の開発者はそもそも購入する人はかなり少ないのではないだろうか？
また、日本のSIではアジャイル開発を採用している会社はほとんどないだろうし、おそらくウォーターフォール型開発が主流の会社で、Redmineを使っている現場が多いのだろう。

そういう読者セグメントを考えると、Redmineは日本のSIの開発現場で好まれやすいツールなのではないか、という仮説が思いつく。
ウォーターフォール型開発が主流の中では、XPやScrumを実践できないけれども、それでも軽量かつ規律ある開発をやりたい現場にチケット駆動開発がマッチしているのではないか、と想像する。
その議論については、以前、本来のチケット駆動開発(TiDD)とは何なのか？ - Togetterでまとめた。

Twitter / quicy: あえて残念な言い方をすれば、チケット駆動開発は、XP/Scrumを実践できない現場、それでも規律的なライトウェイト開発をやりたい、という現場開発者のための、救済なんちゃってアジャイル手法だと思う。

Twitter / quicy: 自分がBugzillaでチケット駆動開発と呼ばれる以前のものをやっていた時には、チーム外からは「ツール使ってるのね」という認識だけで、そこにある軽量さと規律の両立の妙を、なかなか理解してもらうことができなかった。名前と体系化は重要ですね。

この辺りのアイデアも色々まとめてみたい。