6/30に実施したShibuya.trac第12回勉強会チケット管理システム大決戦第二弾の資料です。

1. チケット管理システム
大決戦
第二弾
2011/6/30
Shibuya.trac
第12回勉強会
flickr.com/photos/11226747@N07/4450250126/

2. 本日の目次
• 自己紹介 (10分)
• テーマ１ (40分)
– そのツールの良いところ(気にいってるところ)と
ダメなところ
• テーマ２ (40分)
– そのツールをどのように開発プロセスに組み込ん
でいるか
• テーマ３ (20分)
– チケット管理システムの運用方法
• 質疑応答 (20分)

3. 本日の登壇者のご紹介

4. @kanu_ - かぬ
• 名前：かぬ
• 出身：北海道(関東在住の方が長くなりました)
• 職業：某物流企業の子会社SIer勤務
• 所属：品質管理(主はプロセス管理・改善)
現在はパートタ゗ムでScrum Master
@kanu_ かぬ
• Shibuya.tracメンバー
• Trac Lightning/Kanon コミッター
• 認定スクラムマスター
(2010年6月受講)
• Twitter : @kanu_
blog : d.hatena.ne.jp/kanu-orz

5. BTS/ITSの遍歴
• Trac歴 5年
– 2006年～ ：自身の持つ保守案件で利用開始
– 2007年～ ：保守部隊での顛末管理に利用開始
– 2009年～ ：全社での進捗報告レポートとしての利用推進開始
– 2011年～ ：Scrumプロジェクト(トラ゗ヤル)での利用開始
@kanu_ かぬ
• 利用経験のあるBTS/ITS
– 影舞(2004～2006)
• 外部常駐中に自社部隊との不具合・要望などの案件管理用
– Redmine(2009)
• 他部署のお手伝い-頓挫
– Sourceforge.jp
• Shibuya.tracで利用中

6. @haradakiro – 原田騎郎
• わらじ三足
– SCM コンサルタント(ソースコードじゃなくてサプラ
゗チェーン)
– ドメ゗ンモデラ(DDD なのでコードも書くよ)
– ゕジャ゗ルコーチ(認定スクラムプロフェショナル)
@haradakiro 原田
• 株式会社 情報システム総研
• 株式会社 Odd-e Japan
@haradakiro
http://www.facebook.com/harada.kiro/

7. @haradakiro – 原田騎郎
• Trac 使うまで
– 2003 年頃 – SI所属 SourceForge EE 3 系を使う
– 2004 年頃 – YukiWiki/PukiWiki とか
– 2005 年頃 – Buildix 日本語通らない ;_;
@haradakiro 原田
– 2006 年頃 – Trac 月と出会う
• Trac 使ってから
– 2007 年以降 – プロジェクトは始めるまえに Trac
作ってから考える
– 2008 年以降 – 現職場に転社 Trac は全部゗ンター
ネット上へ。素の Trac を使うことが多い

8. @daipresents – Dai Fujihara
アーキテクチャ＆コアテクノロジー課所属
標準化とかライブラリ開発をするチームで
@daipresents
リーダーみたいなことやってます
沖縄の離島巡りが好き
Web : http://daipresents.com/
Fujihara
About Redmine
2006 ～ 2008は受託開発でTrac利用
2009 ～ 2010は個人でRedmineを使って社内展開
きっかけはRubyの勉強がしたかったから

9. @takanafu － 関 崇匡
• エンタープラ゗ズ系のこてこてなウォーターフォールPJ
から研究開発などのゕジャ゗ルPJなんかで技術支援や標
準化をやってます
• Adobe Flex ゗ンストラクター
• 株式会社 ゕドヴゔンスト・ソフト・エンジニゕリング
@takanafu 関
• RedmineLE（redmineのTracLightningみたいなもの）
をひっそりと公開中
http://sourceforge.jp/projects/redminele/
• http://d.hatena.ne.jp/takanafu/ （5日坊主）
• 4年前くらいから利用開始。その他にはTrac、Bugzilla、
JIRAなどいろんなものを使っていた。

10. @ohnuki – 大貫 浩
• JIRAを中心にしたソフト開発ツールのコンサル
– 提案～実装～サポートまでいろいろやってます
– IDE好きなプログラマ。CとJavaを10年。最近はExt.JS
– あと仮想化とThinkPadが好き。
– そして全てが洗練されたAppleより、全サービスのUI
@ohnuki 大貫
がバラバラなGoogleが好き。
• JIRA(Atlassian)との関わり
– 2007～ Apache Geronimoの翻訳プロジェクトで
Atlassian JIRAとConfluence知る
– 2009～ AtlassianパートナーとなってJIRA販売
– 2011 ～ 売上が受託開発とAtlassianビジネスで逆転

11. @yusukey - 山本 裕介
• オープンソースデベロッパ
• Twitter4J、”侍” などを開発
• Twitter APIポケットリフゔレンス
– 7月15日発売、予約受付中！
@yusukey 山本
http://samuraism.jp/
@yusukey

12. @yusukey - 山本 裕介
• Jira歴 6年(2006年～)
– 2006年～: Pebble(ブログソフト)コントリビュータ
– 2007年～: Twitter4J 開発
• Jira以外のチケット管理システム利用経験
@yusukey 山本
– 2002年～: Clarify CRM(BEA Systems)
– 2006年～: Numara Footprints(Fast Search&Transfer)
– 2007年～: Trac
– 2007年～: Bugzilla
– Excel(現在とあるプロジェクトで)
– Scarab(評価したことがあるだけ)

13. @ikikko - 中村知成
• 中村知成 (@ikikko, id:ikikko)
• 所属 本社：福岡
拠点：東京・京都
– 株式会社ヌーラボ
– Shibuya.trac、日本Jenkinsユーザ会
@ikikko 中村
• 半分中の人
– Backlogの開発に直接携わってはいません
– 一番近いヘビーユーザ
• 今日は、ヌーラボで携わっているプロジェクト
からいくつか取り上げてお話します

14. Backlogとは
@ikikko 中村
• エンジニゕ以外もターゲット層
– デザ゗ナー
– 翻訳者
– 経理・事務担当 など
• メ゗ンはASPサービス

15. @ikeike443
• 池田尚史（いけだたかふみ）
• 株式会社シャノン
@ikeike443 池田
• Jenkinsプラグ゗ン開発者
• Play! framework 好き

16. BTS利用遍歴
• 2001～2004：Excel
• 2005～2008：独自ツール
• 2008～2009：Trac
• 2010～Now ：Backlog
@ikeike443 池田

17. @Ryuzee – Ryutaro YOSHIBA
• アジャイルコーチ
• 認定スクラムプロフェショナル(CSP)
• 認定スクラムマスター(CSM)
• 認定スクラムプロダクトオーナー(CSPO)
@Ryuzee YOSHIBA
• Shibuya.tracのスタッフ
• スクラム道の共同設立者
• Scrum Boot Camp発案者
• TIS,野村総合研究所を経てベンチャーのCTO
• http://www.ryuzee.com

18. テーマ１
各ツールの
良いところと悪いところ

19. 良いところ
• SQLを用いた柔軟なレポート
• Trac Lightningの存在
@kanu_ かぬ
• Shibuya.tracの存在
• 豊富なプラグ゗ン
• 無料であること

20. SQLを用いた柔軟なレポート
Tracのみでワンストップなプロジェクトの可視化が可能。
@kanu_ かぬ

21. Trac Lightningの存在
• Trac+svn+maven+Jenkinsが5分で構築可能
• クラ゗ゕントPCで手軽に試すことが可能
– Linux向けにはKanonも登場
@kanu_ かぬ

22. Shibuya.tracの存在
• Tracをきっかけにして、似た悩みを持つ開発者
同士が悩みを共有し繋がることが出来る場
• Tracに限らず、DVCSやゕジャ゗ル、CIなどに
ついても悩みを分かち合うことが出来る。
@kanu_ かぬ

23. 豊富なプラグイン
• シンプルな本体を強化する多くのプラグ゗ン
– Trac-hacksだけでも500を遙かに超えるWikiマクロ
やプラグ゗ン。
– Version Upへの追従も、実績による安心感
@kanu_ かぬ

24. 無料であること
• サーバーとOSさえ用意できれば無料で利用可能
• 利用が拡大してもラ゗センスのコスト増が無い。
@kanu_ かぬ

25. 残念なところ
• プラグ゗ンを入れないと貧弱
• 操作感、統一感が゗マ゗チ
@kanu_ かぬ
• Reportは意外と大変
• 最も残念なのは・・・

26. プラグインを入れないと貧弱
• Trac Lightningに同梱の
プラグ゗ンは45個
– 素のTracからこの状態を
作るのは困難
@kanu_ かぬ
• ワークフローのWeb-UI編集
に決定打が無い
– ワークフローのWeb-UI編集に
は定番がない。
– 結局、INIの編集が一番確実
http://www.flickr.com/photos/oogoom/3541084081/

27. 操作感、統一感がイマイチ
• 漢らしいともいわれる操作感
– JIRAやRedmineと比較すると
一世代前な感じは否めない
• プラグ゗ンで機能強化可能な反面、
全体としての統一感に欠ける。
@kanu_ かぬ
– ただしAgilo、ciklone除く
http://www.agile42.com/en/agilo/ http://ciklone.com/
http://www.flickr.com/photos/shvmoz/2310971713/

28. Reportは意外と大変
• SQLは便利だが作るのは骨が折れる
@kanu_ かぬ

29. Tracの最も残念なこと
• Rubyではないこと
– Shibuya.tracのOSCのブースなどで、
「仕事がRubyなんでRedmine使ってます。
TracってPythonなんですよね？」
@kanu_ かぬ
と非常に多くの人から言われる。
もしTracがRuby on Railsだったら・・・
もしPythonが日本でもっと流行していたら・・・

30. @haradakiro – Trac の良いところ
• ゗ンストールが簡単
– TracLightning だとさらに簡単 (Thanks a LOT!!)
• デフォルト設定で、ふつうに使える
@haradakiro 原田
• Python だった
– 昔 Ruby の環境をいじると怒られたりしたけれど、
Python は誰も使ってなかったので問題なかった 

31. @haradakiro – Trac の悪いところ
• 行儀の悪いプラグ゗ンが沢山いる(いた？)
– いれると収拾つかなくなることが多い
• バージョンゕップのときとか
• プラグ゗ンのゕン゗ンストールではまったことが何度か
@haradakiro 原田
– ときどき sqlite が壊れる
• PostgreSQL にしてバックゕップしているけど、こんどは゗
ンストールが面倒
• 複数プロジェクトで゗ンスタンスを増やしてし
まうと管理が面倒

32. Redmineの良いところ
@daipresents Fujihara

33. Redmineの良いところとダメなところ
• 良いところ
– （RedmineLEを使えば）゗ンストールが簡単
– 簡単なプラグ゗ンはすぐ作れる
– とことんまでカスタマ゗ズできる
ワークフロー系システムのバックエンドとして活用
@takanafu 関
–
しやすい（社内稟議システムで活用）
– プラグ゗ンが充実している
– 複数プロジェクトやプラ゗ベートチケットなど便利
な機能がデフォルトでたくさんある

34. Redmineの良いところとダメなところ
• ダメなところ
– ちょっと込み入ったカスタマ゗ズしようとすると極
端に難易度が上がる
– 複数プロジェクトを持てるけどチケット番号が通し
なので都合が悪い時がある
@takanafu 関
– RedmineのせいじゃないけどWindowsで動かすとパ
フォーマンスが微妙（Passenger）
– Wikiがちょっと使いづらい
– 複数プロジェクト間でカスタムチケット等のフゖー
ルドが共有できるので、一度たくさんカスタム
フゖールドを作るとうざい

35. JIRAの良いところ
• 標準カスタマ゗ズと開発カスタマ゗ズ
@ohnuki 大貫

36. JIRAの良いところ
• 標準カスタマ゗ズと開発カスタマ゗ズ
@ohnuki 大貫

37. JIRAの良いところ
• 標準カスタマ゗ズと開発カスタマ゗ズ
@ohnuki 大貫
画像はatlassian.comより

38. JIRAの悪いところ
• ゗ンストールして使い始めるまでの敷居が高い
• 日本語の情報が多くない
@ohnuki 大貫
画像はAmazon.co.jpより

39. Jiraの良い所
• 美しいUI、豊富なキーボードショートカット
@yusukey 山本

40. Jiraの良い所
• 簡単な゗ンストール
– ダウンロード、展開、startup.shを起動するだけ
@yusukey 山本

41. Jiraの良い所
• 自動バックゕップ
– フゔ゗ルに定期バックゕップ。復旧も簡単
@yusukey 山本

42. Jiraの良い所
• 多くのデータベースに対応
– MySQL, PostgreSQL, SQL Server, Oracle
– 管理者の慣れ親しんだDBで運用可能
@yusukey 山本

43. Jiraの良い所
• 豊富なプラグ゗ン
– Universal Plugin Managerで簡単゗ンストール
@yusukey 山本

44. Jiraのダメな所
• メモリを食いがち、512MBは欲しい
@yusukey 山本
– が、384MBのiBookでJira、WebLogic Server、
PostgreSQLと合わせて運用した経験あり

45. Jiraのダメな所
• ワークフローのカスタマ゗ズがやや煩雑
@yusukey 山本

46. Jiraのダメな所
• 細かなチューニング、運用にはJavaやTomcat
の知識が必要
@yusukey 山本

47. Backlogの良いところ
• 楽しくコミュニケーションできる
• デザ゗ンがかわいい・親しみやすい
@ikikko 中村
• 管理に手間がかからない
– サーバ管理が不要
– 1分で、登録して使い始めることができる

48. とあるプロジェクトの風景
バーンダウンチャート
@ikikko 中村
絵文字
Backlogスター

49. Backlogのダメなところ
• 柔軟なカスタマ゗ズができない
– Backlog API（XML-RPC）は用意されている
• （他ツールと比べて）エンジニゕ向け機能が弱い
@ikikko 中村
• お金がかかる

50. @ikeike443 池田
Backlog 良いところ

51. Scrumとマッチ
• バーンダウンチャート出せる
@ikeike443 池田

52. 日本の現場分かってる
• ガントチャートも出せる（Excelも）
@ikeike443 池田

53. 日本の現場分かってる
• 企業のセキュリテゖチェックシートにも回答
してくれる
→上層部を説得しやすい？
@ikeike443 池田

54. 国産だから
日本語対応完璧
余計なことで悩まない！
@ikeike443 池田

55. 親しみやすいデザイン
• 非エンジニゕも安心！
@ikeike443 池田

56. コラボがしやすい
• 非エンジニゕとのコラボ
• デザ゗ンが良く、デザ゗ナーさんや営業さんといっ
た非エンジニゕにも受け入れてもらいやすい
• 社外とのコラボ
•
@ikeike443 池田
SaaSなので、余計な手間なく初めから゗ンター
ネットに公開されている

57. SaaSだから
• メンテナンスフリー
• セキュリテゖも安心
• すぐ使える
@ikeike443 池田

58. APIがある
• データの出し入れ自由自在
• レポーテゖング
• 他システムとの連携
• その他カスタマ゗ズ
@ikeike443 池田

59. その他機能豊富
• マルチプロジェクト
• フゔ゗ル共有（WebDAV）
• Wiki
• SVN連携
@ikeike443 池田
• Jenkins連携
• ガラケー対応

60. Backlog
@ikeike443 池田
頑張ってほしいところ

61. マルチプロジェクト
• マルチプロジェクトで使えるけど
• プロジェクト間タスク移動できない
• タスクの親子関係、階層作れない
• エピック、ストーリー、タスクの粒度
@ikeike443 池田

62. SCMとの連動もう一歩
• hook書きたい
• gitも使いたい
@ikeike443 池田

63. レポーティング
• 検索条件の保存が出来ない
• APIを使わない限り自由度がやや低い
@ikeike443 池田

64. テーマ2
ツールをどのように開発プロセ
スに組み込んでいるか

65. 開発プロジェクトの体制
• 開発人数
– １～15人程度(プロジェクトの規模次第)
• 基本進捗及び成果物管理にTrac利用
• 少人数の場合
– タスク管理はExcel、不具合はTicketというパターンもあり
• 外部公開
@kanu_ かぬ
– 開発、保守部隊共に社外への公開は無し
– 進捗報告及び保守報告レポートはTracを元に出力

66. 開発プロセス
• ウォーターフォール(基本)
– WBSを元にタスク分割を行い、タスクをチケットとして登録
– 設計書を含め成果物をSubversionへ保管
– Subversionにコミット時に、コミットコメントを
使って作業時間をTicketへ反映
– 計画は線形で行うため、Excelで作ったガントチャートで実施
@kanu_ かぬ
• ゕジャ゗ル(スクラム)
– ストーリーと、それに紐付くタスクをチケット管理
• ストーリーはWiki併用
– 作業時間記録も基本ウォーターフォールと同じ
• 見積時間の変更を行い残作業時間の朝会時に報告。
– その他のプロセスはスクラムのプロセスに従う
– 朝会用にスプリントのチケットをPostItへ印刷

67. 進捗の報告
• 進捗の報告をTracのレポートで行っている。
– 進行中工程(局面、゗テレーション)における、
• 見積工数(規模)の消化状況(完了タスクのみ)
• 見積工数(規模)に対する実工数の状況(完了タスクのみ)
• 作業中タスクと工程内の未着手タスクの完了予測
– 完了済み工程(局面、゗テレーション)における、
• 見積工数(規模)に対する実作業工数
@kanu_ かぬ
• 発生している問題点(リスク)の内容と対処方法(予定含む)
– 完了予測と遅延対策
• 見積工数(規模)に対する実作業工数の対比による
稼働までスケジュールの確度
• 遅延が予測される場合、原因とその対策について
– 工程完了後のレビュー(or ふりかえり)で出た問題点について
• 問題点(リスク)の内容
• 問題点(リスク)への対処方法(結果)
• 問題点(リスク)への対処方法(予定)

68. 報告形式
•
@kanu_ かぬ

69. タスクボード
@kanu_ かぬ

70. 報告・可視化用に
使っている主なプラグイン
• TimingAndEstimation • ReportInclude
– 時間の積算用 – TracReportをWikiに表示させる
• タ゗ムトラッキング ためのプラグ゗ン
• 管理上最重要プラグ゗ン • Ticket/Milestone/Report などで
– Web-Query UIコンポーネント 利用可能
• Queryに中計・大計表示 – Reportだけではなくグラフの表示
http://trac- も可能
hacks.org/wiki/TimingAndEstimationPlugin • 棒グラフ/積み上げ棒グラフ/折れ
@kanu_ かぬ
線グラフ/円グラフ
• QueryChart http://fr.sourceforge.jp/projects/shibuya-
trac/wiki/plugins%2FReportIncludePlugin
– チケットのステータス変動の日付
の記録
• ExtendedVersion
– 日付を元にバーンダウン/ゕップ
チャートの表示 – Milestoneをversionでまとめる為
http://weekbuild.sakura.ne.jp/trac/wiki/T のプラグ゗ン
racDoc/QueryChart – MilestoneをTimeBox化して利用
する際に、
• StickyTicketPlugin 全体を見渡すのに非常に便利。
– チケットをPostItに印刷 – 表示の形式はMilestoneとほぼ同
じ
– タスクボード用
http://trac-
http://trac- hacks.org/wiki/ExtendedVersionPlu
hacks.org/wiki/StickyTicketPlu gin
gin

71. 連携している主なツール
• Subversion
– ソース、ドキュメントは全て格納
– コミットフックを使ってTimingAndEstimationプラ
グ゗ンでの作業時間積算と、Tracのチケット連携を
行っている。
@kanu_ かぬ
• Jenkins
– 結合テスト環境及び本番リリース用のビルドの管理
– プロジェクトによっては常時結合
– ビルド結果をTracのタ゗ムラ゗ンに表示
• Eclipse-Mylyn
– EclipseからのTracチケット連携用
– 普及度は高くない

72. @haradakiro – 開発プロセス
• Scrum (+DDD)を採用(チームは３人から７人)
• ストーリーの管理は、Trac の外
• スプリントプランニングの結果を Trac に登録
@haradakiro 原田
• 進捗はタスクボード＋バーンダウンチャート
• タスクが進んだら Trac にも登録
• Trac+Hudson(Jenkins)+デモサーバ
• ユーザ、コンサルタントは常に開発現場にはいられ
ないので、Trac、デモサーバを確認

73. @haradakiro – タスクボード
@haradakiro 原田

74. @haradakiro – Trac 画面
@haradakiro 原田

75. @haradakiro – そんなので？
• IT Japan Award 2011 – 準グランプリ
@haradakiro 原田
• 小島プレス工業
– 異業種でも利用可能なSaas型 EDI 基盤

76. @haradakiro – タスクボード
@haradakiro 原田

77. @haradakiro – タスクボードに
@haradakiro 原田

78. @haradakiro – バーンダウン
@haradakiro 原田

79. @haradakiro – Trac 画面
@haradakiro 原田

80. @haradakiro – Trac Wiki
@haradakiro 原田

81. @haradakiro – Trac上 概念クラス
@haradakiro 原田

82. @haradakiro – 開発プロセス
デモ確認
現要求を伝える 施主 改善点の提示
@haradakiro 原田
ヒアリング デモ実施
プロダクトバックログのレビュー レビューでのヒアリング
設計 開発
プロダクトバックログの作成 見積
スプリントバックログの確認 スプリントバックログの作成
開発

83. 開発プロセス (Redmine)
@daipresents Fujihara

84. 開発プロセス (Redmine)
@daipresents
Fujihara
予想実績（単位は日）

85. 開発プロセス (Redmine)
 ベロシテゖの見える
化はExcelでグラフ
化して壁に貼ってい
る
@daipresents
 青が予想、緑が実績
 赤は平均。人数の増
減があるため測定し
ている
Fujihara
 トレンドとして「実
績/予想」や、「1発
目のスプリントとの
比較」も計算

86. 開発プロセス (Redmine)
@daipresents Fujihara

87. 開発プロセス (Task Board)
@daipresents Fujihara

88. 開発プロセス (Redmine)
@daipresents Fujihara

89. 開発プロセス (Redmine)
Before After
@daipresents
10％
90％
Fujihara
規律 協調

90. 開発プロセス (Redmine)
マッチする
外部要因となる作業
@daipresents
小さいチーム
マッチしない
個人用TODO
Fujihara
プランニングポーカーの風景

91. どのように開発プロセスに組み込んでいるか
■WF＋請負＋指定管理方法（Excel）の場合
• プロジェクトのWBS特定レベル（画面だったり機能
だったり）に合わせて内部では「マスターチケット」を
作って、そこに関連づけた工程単位の子供チケットをぶ
ら下げて、あとは通常のTiDD。
@takanafu 関
• プロジェクト指定の進捗管理Excelや故障管理Excelはチ
ケットから生成するマクロを作って、発注元には完全に
従っているように見せておいて内部では全てチケットで
管理。
• 単体試験（チーム内部）まではSVN（or GIT）＋
Jenkins＋xUnit＋PMD等でゕジャ゗ル的に開発。試験
項目報告ExcelもTPから生成することも。

92. どのように開発プロセスに組み込んでいるか
■支援（客先常駐作業）の場合
• とにかく全ての作業はチケットに登録。
• 基本的にメールは使わずチケットと関連づけたリポジト
リにソースコードやドキュメントをコミット。
■その他やっていること
@takanafu 関
• 企画段階や上流設計工程から関与できたプロジェクトの
場合は、どんなに昔ながらの現場でも構成管理方法や故
障管理、回帰テストの自動化、CIを提案する。
• チェックリストや規約などはできる限りPMDや
CheckStyleのカスタムルールにする。

93. どのように開発プロセスに組み込んでいるか
■なかなかRedmineを受け入れてくれない現場の場合
• その現場で利用している帳票やExcelと同じ見た目で入
力もしくは閲覧できるViewを作ると案外受け入れてく
れる。
• 巧みな話術でしつこくキーマンを洗脳する。
@takanafu 関
– Excelなんて、とか思っても絶対口にも顔にも出さないで、
Excelの利点を認めつつも・・・のように提案する。
• 便利な仕組みを使うことによってやる事が無くなる人の
仕事を用意してあげる。
– 結合試験計画の前倒しや、テストデータ整備など後工程で人手
が必要になるものを先にやってもらう、チケットクローズ係に
なってもらうなど。

94. JIRAとウォータフォール
• JIRAはバグ管理のみ
• プロジェクトの作業計画、進捗管理はExcelや
Notes、MS-ProjectでWBS管理
@ohnuki 大貫

95. JIRAとアジャイル
• ゕジャ゗ル管理ツールGreenHopperを使う
@ohnuki 大貫
少人数（１０人未満）の管理方法か？

96. JIRAとWBS(構造化チケット)
自社組織に合うチケット構造を定義
し、計画立案と進捗管理を行う（標
準化）。ツールはその構造に従った
構造化Viewを提供する。
チケット階層
@ohnuki 大貫
ストーリ
モジュール
タスク

97. Jiraをどのように開発プロセ
スに組み込んでいるか
@yusukey 山本

98. Twitter4Jの開発
• ユーザー、コントリビュータ: 32人
– チケット登録
• コミッタ: 1人 - チケット編集、クローズ
• 登録ユーザ数: 全90人
@yusukey 山本

99. 開発参加ガイドライン
@yusukey 山本
JIRAを中心とした開発参加ガ゗ドラ゗ン

100. Twitter4J開発の流れ
1. MLでバグ報告・機能追加要求を受ける
2. 課題登録
3. githubで修正、pull requestを貰う
4. Jenkinsがテストを確認
5. テストがパスしたら課題をクローズ

101. 開発で使っているサービス、ツール
コードリポジトリ
ビルド、テスト
コーディング
CI service hook
課題管理
開発マシ ン CIサーバ github.com

102. Jira と GitHubの連携
JIRA Git plugin

103. Jira と Jenkinsの連携
@yusukey 山本
Jenkins JIRA plugin

104. Jira と IDEの連携
@yusukey 山本
Atlassian Connector for IntelliJ IDEA

105. 開発プロセス
• 基本方針
– できる限りの情報をBacklogに集約
– サポート・問い合わせ対応でのメールのやり取り
– 今進んでいるプロジェクトの進捗状況
– 仕様についての質問 など
@ikikko 中村
• 社外公開の有無
– 関連する人全員をメンバーとする
– できない場合は、公開プロジェクトと非公開プロ
ジェクトに分ける

106. 開発プロセス
• チーム構成
– 少人数（数人～十人弱）のプロジェクトが多い
– デザ゗ナーなどとも協業
• 併用しているツール
@ikikko 中村
– Cacoo, Skype, EtherPad, Jenkins
リゕルタ゗ムで共同編集できる
テキストエデゖタ

107. 例：問い合わせ対応への組み込み
問い合わせメールから、Backlogにチケット自動登録
@ikikko 中村
http://www.backlog.jp/blog/2009/03/post.html

108. 例：Cacooでの開発プロセス
@ikikko 中村
http://www.slideshare.net/nulab/seasarwebcacoo

109. 例：Cacooの開発プロセス
@ikikko 中村
http://www.slideshare.net/nulab/seasarwebcacoo

110. 例：Cacooの開発プロセス
@ikikko 中村
やりとりをBacklogに集約

111. Backlog
どうやって使ってるか
@ikeike443 池田

112. 社外ユーザとの利用多数
@ikeike443 池田

113. 3年半
206
@ikeike443 池田
プロジェクト
一人平均3−10プロジェクトの利用？

114. 利用形態
社内 社外
開発 導入
プロジェクト型
社内 WEB制作
@ikeike443 池田
依頼 協業
チケット型 期限
FAQ

115. 社外ユーザなど文化の異なる人と
タスク
SVN
@ikeike443 池田
フゔ゗ル
社外
社内
Wiki
サブバージョ
ンがさー
メールで

116. 雑務から新しい仕事を創る
定期的に
タスク棚卸
@ikeike443 池田
分析

117. APIの利用による定形・自動化
Backlog
Backlog API
@ikeike443 池田
定形タスク カスタムバーンダウン

118. 製品開発
• プロダクトバックログ：GoogleDocs
• スプリントバックログ：Backlog
• バグ管理：Bugzilla
• バージョン管理：SVN, CVS
@ikeike443 池田
• CIサーバ：Jenkins

119. DEV コミットフック
日々のコミット
開発マシン
@ikeike443 池田
すべてのバグ管理
スプリント中の （≒プロダクト
チケット管理 バックログ）
QA
CVS
QAのリポジトリは 定期実行
DEVと別 複数環境並行

120. 実際のルール
• 月初に定形タスクをAPIで投入（開発の標準タスク
等）
• 月初にさらに6-8割程度までタスクを作成
• 1タスクは8時間以内（超えるものは分割）
•
@ikeike443 池田
予定と実績の時間は入力し、バーンダウン生成
• 月末にタスク分析で失敗の原因を探る

121. 付箋も大いに活用

123. テーマ3
チケット管理システムの
運用方法

124. 運用
• 社内サーバーで運用中
– サーバ機
• Dell T300
• Xeon X3363 2.8Ghz
• Memory 4GB
• Disk 280GB(Raid5+Hotspare)
@kanu_ かぬ
– バックゕップ
• Jenkinsで毎晩実行
– Trac及びsvnをHot copy(3日分保存)
– Hot copyをzip圧縮しNASへ(14日分保存)
– その他
• 全文検索用にHyperEstraier用Index生成(Jenkinsで日に2回)
• 基本は放置だが運用部隊にJenkisの運用関連Jobチェックを
毎朝お願いしている。

125. 改善要望について
• 要望は品質管理チームで取りまとめ
– プロセス改善の目的を兼ねているため
• 既存プラグ゗ンで対応可能な場合は実施
– 目的を再確認し、開発プロセス及び要求資料の改善を提示する
ことも少なくない。
@kanu_ かぬ
• チケットへの項目追加など
– 基本的にはプロジェクト一任。
– 運用しきれない管理項目を増やす傾向があるので、
立ち上げ当初は適宜ゕドバ゗スを行っている。
• 管理用のTrac Report
– 基本的にはプロジェクト一任。
– 全体的に利用できそうな場合は、品質管理チームにて作成する
場合もあり。

126. 現状の問題点
• 個人への依存
– 部署対応ではあるものの完全に個人へ依存
– 依存脱却への取り組みは始まったが成果は出ていない
• やらされる、使わされるに慣れていて、改善への興味が薄い?
• Tracの管理
@kanu_ かぬ
– 管理がTracのWeb-UIのみで完結しない
– Tracに関わる広い知識が必要
• Subversion, Apache, Python, Maven, Jenkins等々
• 銀の弾丸
– 道具が解決してくれると思っている傾向がある。
– 開発プロセスを含めたポリシーの徹底が必要

127. Users & Version
1400
登録者累計 0.9.6
1200 0.9.4
1000
2.5年で1000ユーザ 0.9.2
@daipresents
800 開発、ビジネス問わ
ず社員全員が使える 0.9.0
600
形に
0.8.4
400
Fujihara
0.8.0
200
0
２年ぐらい

128. チケット管理システムの運用方法
• 社内サーバーに設置して、業務（案件）単位にプロジェ
クトを作成。
• ゕクセス制御はLDAP連携で整備。
• 基本セットはredmine+LDAP+jenkins+SVN+
xUnit&PMD系&カバレッジ系（言語別）。
@takanafu 関
• ある程度はマクロですぐに提供できるようにしている。
• 案件のリーダーに対する布教活動。
• 社内プレゼンでの布教活動。
• ある程度標準化したチケットの種別やカスタムフゖール
ドと運用方法を準備して使いまわしている。

129. JIRA運用のよくあるパターン
• 運用する人：社内IS部門
– JIRAユーザーは数百人規模
– ユーザーとグループは全社認証情報と連携（AD多い）
– ただしプロジェクト設定はプロジェクト管理者に権限委譲
• データ量：数年使って数十万チケットになる
@ohnuki 大貫
• ゕベ゗ラビリテゖ：２４時間３６５日止まらないで
– HW障害対策は必須、パフォーマンス検討も時々行う
• バックゕップ：まちまちで難しい
– 会社(組織)の標準バックゕップ方法に準拠
• フラッシュコピー、テープ、DB共通バックゕップ
• オンラ゗ンバックゕップできるDBやバックゕップソフト利用

130. 自宅サーバーで運用中
• フレッツ光
• Value Domain(DDNS): twitter4j.org
• Mac Mini(Core2Duo,2.66GHz,8GB)
@yusukey 山本
フレッツ光
ダイナミックDNS Ethernet
Internet
AirMac Extreme Mac Mini

131. 管理
• 基本放置
• カスタマ゗ズは最小限
– gitプラグ゗ンを入れている程度
• 新バージョンが出たらなるべく早めに適用
@yusukey 山本
– これまでに10のバージョンを適用:
3.x系: 3.9.2, 3.12.3, 3.13.1
4.x系: 4, 4.0.2, 4.1, 4.2.0, 4.2.2, 4.3, 4.3.4
– バージョンゕップで問題が出たことはなし
• まれに脆弱性の通知がメールで来るのでパッチ

132. 管理上の問題点と今後の展望
• ユーザーはあまり見てくれていない
– メーリングリストとJiraの串刺し検索?
• 省電力化
– クラウドにデプロ゗？
@yusukey 山本
– Jira Studio for OSSの利用?
• http://open.jira.com/secure/Dashboard.jspa

133. Backlogの運用方法
• サーバ管理
– （プロジェクトチーム側では）゗ンフラ面を特に考
慮する必要無し
• チケット管理方針
@ikikko 中村
– 「楽しくコミュニケーションすること」を重視
– あまりガチガチにしない

134. 現状の管理における問題点
• メール爆発
• 情報の分散
– Backlog, Skype, EtherPad, Cacoo
– チケットに起こす前のたたき台の場所とか・・・
@ikikko 中村
他ツールの良いところを取り入れていきたい
（と個人的に思ってます）

135. システムの運用管理
• システム運用管理：
• ヌーラボさん
• 業務運用管理：
• 事業部ごとに複数の管理者
@ikeike443 池田

136. 現場が自由に使っている
• 社内外でプロジェクトが立ち上がるたび、
Backlogにプロジェクトを作る
• 最低限のルールのみ決めておいて、後は現場
の判断
@ikeike443 池田
• お客様、協力会社様、社員、全ての関係者を
入れてプロジェクトを運用

137. テーマ4
質疑応答