Redmineのコミュニティであるredmine.tokyo（旧shinagawa.redmine）主催の勉強会（通算7回）が開催されました。各セッションの資料・動画は勉強会ページ（次のURL）から辿れます。
http://redmine.tokyo/versions/13
講演は、アンチパターン、Redmineサーバの統合、LT、そしてオープンディスカッションがありました。
以下、Redmine活用にヒントになったことなどを五月雨メモします。
松谷さん（@mattani）
- Redmineは柔軟性の高いツール、使うためにコツがいる
- Redmineに慣れた人がチケットを作ってあげるのは一見Redmine推進があるようで逆効果、各自に作ってもらって慣れさせる、重複気にせず作ってもらう、不要ならあとで破棄すればいい
- Excelの課題管理とかは担当者記載したらほぼ固定、チケットなら人を担当者にして随時担当者を変えてよい
- 「レビュー待ち」ステータス設け、担当を承認者にする、承認者はクローズするときは根拠を書く
- 塩漬けチケット対策、必ず期限を書く（仮期限でもよい）、期限ないチケットはやらなくてよいことにすれば期限を書くようになる、中長期バージョンを定義してというのもあり
- プロジェクトの設け方、チームが違えば別プロジェクト
- ロードマップを使いこなす
- 小さいチームならワークフローなくて（緩くて？）いい
- 半日かかる作業、リポジトリをいじる作業は必ずチケット化
- 大きなチケットは流れが変わるときに別チケットにする
あきぴーさん（@akipii）
- 完了基準を決める、基準はチームの成長とともに変わっていく
- CCBパターン、プロジェクト階層を設け、チームごとのサブプロジェクトを子階層にする。親プロジェクトはチームリーダーとPMOをメンバーにして課題管理などを行う
- アンチパターン）乱発トラッカー、あるある。同じワークフローを持つトラッカーは抽象化したトラッカーにまとめる
- 「タスク」を「設計」「実装」「調査」「作成」などに分けたくなることもあるけど、やっぱり「タスク」にしておくのがいいということかな
- 帳票単位にトラッカーを作る（例、進捗一覧はタスク、障害一覧はバグ、課題一覧は課題）
- アンチパターン）WBSをチケット化、担当者は常に同じ
- チケットはキャッチボールが大事、担当者と承認者とチケットの担当者は変わるもの
- 横断的タスク
- 小規模なら子チケットに各プロジェクトのタスクを作る
- 中規模なら各プロジェクトごとのバージョンを作る
- 大規模ならサブプロジェクトを作る
- まずチケットにあげること、すればみんなが見るようになる
オープンディスカッション
司会者がいくつか設問（二択）を用意し、どちらかに挙手させ、それから意見（主張、補足、反論）をいってもらうという形式。サンデル教授の白熱教室みたいな形態です。
- 分オーダーの作業にチケットを作るのは手間
- 定常ルーチンでチケットは手間
- チケットは作業の証跡を残せる
- チケットは連絡ツールとして使える
- マインドマップを書くイメージでチケットを作る
- メインフレーム運用管理でバッチ投入、障害対応などは昔ロータスノーツに記載していた
- REST APIなどを使ってなるべく自動化すれば
- Redmineは機能多過ぎ、Wikiとチケットしか使わない
- 一人で完結する仕事にチケットは必要か？
- 過去の修正履歴が残っている、とくにSubversionのコミットとチケットが紐付けされているのは最強
- 作業の依頼・報告をメーリングリストでやっているがチケットの方がいい
- ドキュメントのレビューをチケットにしたが似たようなチケットが乱立し管理できなかった
- 何をチケットにするかが難しい
@y503unavailable さん
複数のRedmineサーバーを立てて運用し、それを１つに統合する作業をどのようにしたのかを詳しく紹介していました。Redmineサーバーは気軽に立てられるので、立てたサーバーをあとでまとめたいといったニーズはありますが、かなりの難業になりそうであきらめていました。それを実際にやった方からの紹介だったので実は今日一番ききたい講演でした。
内容は、業務システムリプレース時のデータ移行プロジェクトをやるような感じです。とてもメモできるものではないので、資料公開を待ちますRedmine勉強会ページのリンクから発表資料（発表後修正あり）をご覧ください。以下は超断片メモです。
@naitoh さん
Redmine 2.6および3.0の最新動向、変更点の紹介です。
実はPDF関連のたくさんの修正は、@naitohさんの貢献です。
