チケット管理システム大決戦第二弾

チケット管理システム
大決戦
第二弾

2011/6/30
Shibuya.trac
第12回勉強会

flickr.com/photos/11226747@N07/4450250126/

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

本日の登壇者のご紹介

@kanu_ - かぬ
• 名前：かぬ
• 出身：北海道(関東在住の方が長くなりました)
• 職業：某物流企業の子会社SIer勤務
• 所属：品質管理(主はプロセス管理・改善)
現在はパートタ゗ムでScrum Master
@kanu_ かぬ

• Shibuya.tracメンバー
• Trac Lightning/Kanon コミッター

• 認定スクラムマスター
(2010年6月受講)
• Twitter : @kanu_
blog : d.hatena.ne.jp/kanu-orz

BTS/ITSの遍歴
• Trac歴 5年
– 2006年～：自身の持つ保守案件で利用開始
– 2007年～：保守部隊での顛末管理に利用開始
– 2009年～：全社での進捗報告レポートとしての利用推進開始
– 2011年～：Scrumプロジェクト(トラ゗ヤル)での利用開始
@kanu_ かぬ

• 利用経験のあるBTS/ITS
– 影舞(2004～2006)
• 外部常駐中に自社部隊との不具合・要望などの案件管理用
– Redmine(2009)
• 他部署のお手伝い-頓挫
– Sourceforge.jp
• Shibuya.tracで利用中

@haradakiro – 原田騎郎
• わらじ三足
– SCM コンサルタント(ソースコードじゃなくてサプラ
゗チェーン)
– ドメ゗ンモデラ(DDD なのでコードも書くよ)
– ゕジャ゗ルコーチ(認定スクラムプロフェショナル)
@haradakiro 原田

• 株式会社情報システム総研
• 株式会社 Odd-e Japan

@haradakiro
http://www.facebook.com/harada.kiro/

@haradakiro – 原田騎郎
• Trac 使うまで
– 2003 年頃 – SI所属 SourceForge EE 3 系を使う
– 2004 年頃 – YukiWiki/PukiWiki とか
– 2005 年頃 – Buildix 日本語通らない ;_;
@haradakiro 原田

– 2006 年頃 – Trac 月と出会う

• Trac 使ってから
– 2007 年以降 – プロジェクトは始めるまえに Trac
作ってから考える
– 2008 年以降 – 現職場に転社 Trac は全部゗ンター
ネット上へ。素の Trac を使うことが多い

@daipresents – Dai Fujihara

アーキテクチャ＆コアテクノロジー課所属
標準化とかライブラリ開発をするチームで
@daipresents

リーダーみたいなことやってます
沖縄の離島巡りが好き
Web : http://daipresents.com/
Fujihara

About Redmine
2006 ～ 2008は受託開発でTrac利用
2009 ～ 2010は個人でRedmineを使って社内展開
きっかけはRubyの勉強がしたかったから

@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などいろんなものを使っていた。

@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ビジネスで逆転

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

http://samuraism.jp/
@yusukey

@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(評価したことがあるだけ)

@ikikko - 中村知成
• 中村知成 (@ikikko, id:ikikko)
• 所属本社：福岡
拠点：東京・京都
– 株式会社ヌーラボ
– Shibuya.trac、日本Jenkinsユーザ会
@ikikko 中村

• 半分中の人
– Backlogの開発に直接携わってはいません
– 一番近いヘビーユーザ

• 今日は、ヌーラボで携わっているプロジェクト
からいくつか取り上げてお話します

Backlogとは
@ikikko 中村

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

@ikeike443

• 池田尚史（いけだたかふみ）
• 株式会社シャノン
@ikeike443 池田

• Jenkinsプラグ゗ン開発者
• Play! framework 好き

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

@Ryuzee – Ryutaro YOSHIBA
• アジャイルコーチ
• 認定スクラムプロフェショナル(CSP)
• 認定スクラムマスター(CSM)
• 認定スクラムプロダクトオーナー(CSPO)
@Ryuzee YOSHIBA

• Shibuya.tracのスタッフ
• スクラム道の共同設立者
• Scrum Boot Camp発案者

• TIS,野村総合研究所を経てベンチャーのCTO
• http://www.ryuzee.com

テーマ１

各ツールの
良いところと悪いところ

良いところ
• SQLを用いた柔軟なレポート

• Trac Lightningの存在
@kanu_ かぬ

• Shibuya.tracの存在

• 豊富なプラグ゗ン

• 無料であること

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

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

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

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

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

残念なところ

• プラグ゗ンを入れないと貧弱

• 操作感、統一感が゗マ゗チ
@kanu_ かぬ

• Reportは意外と大変

• 最も残念なのは・・・

プラグインを入れないと貧弱
• Trac Lightningに同梱の
プラグ゗ンは45個
– 素のTracからこの状態を
作るのは困難
@kanu_ かぬ

• ワークフローのWeb-UI編集
に決定打が無い
– ワークフローのWeb-UI編集に
は定番がない。
– 結局、INIの編集が一番確実

http://www.flickr.com/photos/oogoom/3541084081/

操作感、統一感がイマイチ
• 漢らしいともいわれる操作感
– JIRAやRedmineと比較すると
一世代前な感じは否めない
• プラグ゗ンで機能強化可能な反面、
全体としての統一感に欠ける。
@kanu_ かぬ

– ただしAgilo、ciklone除く
http://www.agile42.com/en/agilo/ http://ciklone.com/

http://www.flickr.com/photos/shvmoz/2310971713/

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

Tracの最も残念なこと
• Rubyではないこと
– Shibuya.tracのOSCのブースなどで、

「仕事がRubyなんでRedmine使ってます。
TracってPythonなんですよね？」
@kanu_ かぬ

と非常に多くの人から言われる。

もしTracがRuby on Railsだったら・・・
もしPythonが日本でもっと流行していたら・・・

@haradakiro – Trac の良いところ
• ゗ンストールが簡単
– TracLightning だとさらに簡単 (Thanks a LOT!!)

• デフォルト設定で、ふつうに使える
@haradakiro 原田

• Python だった
– 昔 Ruby の環境をいじると怒られたりしたけれど、
Python は誰も使ってなかったので問題なかった 

@haradakiro – Trac の悪いところ
• 行儀の悪いプラグ゗ンが沢山いる(いた？)
– いれると収拾つかなくなることが多い
• バージョンゕップのときとか
• プラグ゗ンのゕン゗ンストールではまったことが何度か
@haradakiro 原田

– ときどき sqlite が壊れる
• PostgreSQL にしてバックゕップしているけど、こんどは゗
ンストールが面倒

• 複数プロジェクトで゗ンスタンスを増やしてし
まうと管理が面倒

Redmineの良いところ
@daipresents Fujihara

Redmineの良いところとダメなところ

• 良いところ
– （RedmineLEを使えば）゗ンストールが簡単
– 簡単なプラグ゗ンはすぐ作れる
– とことんまでカスタマ゗ズできる
ワークフロー系システムのバックエンドとして活用
@takanafu 関

–
しやすい（社内稟議システムで活用）
– プラグ゗ンが充実している
– 複数プロジェクトやプラ゗ベートチケットなど便利
な機能がデフォルトでたくさんある

Redmineの良いところとダメなところ

• ダメなところ
– ちょっと込み入ったカスタマ゗ズしようとすると極
端に難易度が上がる
– 複数プロジェクトを持てるけどチケット番号が通し
なので都合が悪い時がある
@takanafu 関

– RedmineのせいじゃないけどWindowsで動かすとパ
フォーマンスが微妙（Passenger）
– Wikiがちょっと使いづらい
– 複数プロジェクト間でカスタムチケット等のフゖー
ルドが共有できるので、一度たくさんカスタム
フゖールドを作るとうざい

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

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

画像はatlassian.comより

JIRAの悪いところ
• ゗ンストールして使い始めるまでの敷居が高い

• 日本語の情報が多くない
@ohnuki 大貫

画像はAmazon.co.jpより

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

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

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

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

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

Jiraのダメな所
• メモリを食いがち、512MBは欲しい
@yusukey 山本

– が、384MBのiBookでJira、WebLogic Server、
PostgreSQLと合わせて運用した経験あり

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

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

Backlogの良いところ
• 楽しくコミュニケーションできる

• デザ゗ンがかわいい・親しみやすい
@ikikko 中村

• 管理に手間がかからない
– サーバ管理が不要
– 1分で、登録して使い始めることができる

とあるプロジェクトの風景
バーンダウンチャート
@ikikko 中村

絵文字
Backlogスター

Backlogのダメなところ
• 柔軟なカスタマ゗ズができない
– Backlog API（XML-RPC）は用意されている

• （他ツールと比べて）エンジニゕ向け機能が弱い
@ikikko 中村

• お金がかかる

@ikeike443 池田

Backlog 良いところ

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

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

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

国産だから

日本語対応完璧
余計なことで悩まない！
@ikeike443 池田

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

コラボがしやすい
• 非エンジニゕとのコラボ
• デザ゗ンが良く、デザ゗ナーさんや営業さんといっ
た非エンジニゕにも受け入れてもらいやすい
• 社外とのコラボ
•
@ikeike443 池田

SaaSなので、余計な手間なく初めから゗ンター
ネットに公開されている

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

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

その他機能豊富
• マルチプロジェクト
• フゔ゗ル共有（WebDAV）
• Wiki
• SVN連携
@ikeike443 池田

• Jenkins連携
• ガラケー対応

Backlog
@ikeike443 池田

頑張ってほしいところ

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

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

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

テーマ2

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

開発プロジェクトの体制
• 開発人数
– １～15人程度(プロジェクトの規模次第)
• 基本進捗及び成果物管理にTrac利用
• 少人数の場合
– タスク管理はExcel、不具合はTicketというパターンもあり

• 外部公開
@kanu_ かぬ

– 開発、保守部隊共に社外への公開は無し
– 進捗報告及び保守報告レポートはTracを元に出力

開発プロセス
• ウォーターフォール(基本)
– WBSを元にタスク分割を行い、タスクをチケットとして登録
– 設計書を含め成果物をSubversionへ保管
– Subversionにコミット時に、コミットコメントを
使って作業時間をTicketへ反映
– 計画は線形で行うため、Excelで作ったガントチャートで実施
@kanu_ かぬ

• ゕジャ゗ル(スクラム)
– ストーリーと、それに紐付くタスクをチケット管理
• ストーリーはWiki併用
– 作業時間記録も基本ウォーターフォールと同じ
• 見積時間の変更を行い残作業時間の朝会時に報告。
– その他のプロセスはスクラムのプロセスに従う
– 朝会用にスプリントのチケットをPostItへ印刷

進捗の報告
• 進捗の報告をTracのレポートで行っている。
– 進行中工程(局面、゗テレーション)における、
• 見積工数(規模)の消化状況(完了タスクのみ)
• 見積工数(規模)に対する実工数の状況(完了タスクのみ)
• 作業中タスクと工程内の未着手タスクの完了予測
– 完了済み工程(局面、゗テレーション)における、
• 見積工数(規模)に対する実作業工数
@kanu_ かぬ

• 発生している問題点(リスク)の内容と対処方法(予定含む)
– 完了予測と遅延対策
• 見積工数(規模)に対する実作業工数の対比による
稼働までスケジュールの確度
• 遅延が予測される場合、原因とその対策について
– 工程完了後のレビュー(or ふりかえり)で出た問題点について
• 問題点(リスク)の内容
• 問題点(リスク)への対処方法(結果)
• 問題点(リスク)への対処方法(予定)

報告形式
•
@kanu_ かぬ

タスクボード
@kanu_ かぬ

報告・可視化用に
使っている主なプラグイン
• 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

連携している主なツール
• Subversion
– ソース、ドキュメントは全て格納
– コミットフックを使ってTimingAndEstimationプラ
グ゗ンでの作業時間積算と、Tracのチケット連携を
行っている。
@kanu_ かぬ

• Jenkins
– 結合テスト環境及び本番リリース用のビルドの管理
– プロジェクトによっては常時結合
– ビルド結果をTracのタ゗ムラ゗ンに表示
• Eclipse-Mylyn
– EclipseからのTracチケット連携用
– 普及度は高くない

@haradakiro – 開発プロセス
• Scrum (+DDD)を採用(チームは３人から７人)

• ストーリーの管理は、Trac の外
• スプリントプランニングの結果を Trac に登録
@haradakiro 原田

• 進捗はタスクボード＋バーンダウンチャート
• タスクが進んだら Trac にも登録

• Trac+Hudson(Jenkins)+デモサーバ

• ユーザ、コンサルタントは常に開発現場にはいられ
ないので、Trac、デモサーバを確認

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

@haradakiro – Trac 画面
@haradakiro 原田

@haradakiro – そんなので？
• IT Japan Award 2011 – 準グランプリ
@haradakiro 原田

• 小島プレス工業
– 異業種でも利用可能なSaas型 EDI 基盤

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

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

@haradakiro – Trac Wiki
@haradakiro 原田

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

@haradakiro – 開発プロセス

デモ確認
現要求を伝える施主改善点の提示
@haradakiro 原田

ヒアリングデモ実施
プロダクトバックログのレビューレビューでのヒアリング

設計開発

プロダクトバックログの作成見積
スプリントバックログの確認スプリントバックログの作成
開発

開発プロセス (Redmine)

@daipresents
Fujihara

予想実績（単位は日）

 ベロシテゖの見える
化はExcelでグラフ
化して壁に貼ってい
る
@daipresents

 青が予想、緑が実績
 赤は平均。人数の増
減があるため測定し
ている
Fujihara

 トレンドとして「実
績/予想」や、「1発
目のスプリントとの
比較」も計算

開発プロセス (Task Board)

Before After
@daipresents

10％

90％
Fujihara

規律協調


マッチする
外部要因となる作業
@daipresents

小さいチーム

マッチしない
個人用TODO
Fujihara

プランニングポーカーの風景

どのように開発プロセスに組み込んでいるか

■WF＋請負＋指定管理方法（Excel）の場合
• プロジェクトのWBS特定レベル（画面だったり機能
だったり）に合わせて内部では「マスターチケット」を
作って、そこに関連づけた工程単位の子供チケットをぶ
ら下げて、あとは通常のTiDD。
@takanafu 関

• プロジェクト指定の進捗管理Excelや故障管理Excelはチ
ケットから生成するマクロを作って、発注元には完全に
従っているように見せておいて内部では全てチケットで
管理。
• 単体試験（チーム内部）まではSVN（or GIT）＋
Jenkins＋xUnit＋PMD等でゕジャ゗ル的に開発。試験
項目報告ExcelもTPから生成することも。


■支援（客先常駐作業）の場合
• とにかく全ての作業はチケットに登録。
• 基本的にメールは使わずチケットと関連づけたリポジト
リにソースコードやドキュメントをコミット。
■その他やっていること
@takanafu 関

• 企画段階や上流設計工程から関与できたプロジェクトの
場合は、どんなに昔ながらの現場でも構成管理方法や故
障管理、回帰テストの自動化、CIを提案する。
• チェックリストや規約などはできる限りPMDや
CheckStyleのカスタムルールにする。


■なかなかRedmineを受け入れてくれない現場の場合
• その現場で利用している帳票やExcelと同じ見た目で入
力もしくは閲覧できるViewを作ると案外受け入れてく
れる。
• 巧みな話術でしつこくキーマンを洗脳する。
@takanafu 関

– Excelなんて、とか思っても絶対口にも顔にも出さないで、
Excelの利点を認めつつも・・・のように提案する。
• 便利な仕組みを使うことによってやる事が無くなる人の
仕事を用意してあげる。
– 結合試験計画の前倒しや、テストデータ整備など後工程で人手
が必要になるものを先にやってもらう、チケットクローズ係に
なってもらうなど。

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

JIRAとアジャイル
• ゕジャ゗ル管理ツールGreenHopperを使う
@ohnuki 大貫

少人数（１０人未満）の管理方法か？

JIRAとWBS(構造化チケット)
自社組織に合うチケット構造を定義
し、計画立案と進捗管理を行う（標
準化）。ツールはその構造に従った
構造化Viewを提供する。

チケット階層
@ohnuki 大貫

ストーリ

モジュール

タスク

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

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

開発参加ガイドライン
@yusukey 山本

JIRAを中心とした開発参加ガ゗ドラ゗ン

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

開発で使っているサービス、ツール
コードリポジトリ

ビルド、テスト

コーディング
CI service hook

課題管理

開発マシン CIサーバ github.com

Jira と GitHubの連携

JIRA Git plugin

Jira と Jenkinsの連携
@yusukey 山本

Jenkins JIRA plugin

Jira と IDEの連携
@yusukey 山本

Atlassian Connector for IntelliJ IDEA

開発プロセス
• 基本方針
– できる限りの情報をBacklogに集約
– サポート・問い合わせ対応でのメールのやり取り
– 今進んでいるプロジェクトの進捗状況
– 仕様についての質問など
@ikikko 中村

• 社外公開の有無
– 関連する人全員をメンバーとする
– できない場合は、公開プロジェクトと非公開プロ
ジェクトに分ける

開発プロセス
• チーム構成
– 少人数（数人～十人弱）のプロジェクトが多い
– デザ゗ナーなどとも協業

• 併用しているツール
@ikikko 中村

– Cacoo, Skype, EtherPad, Jenkins

リゕルタ゗ムで共同編集できる
テキストエデゖタ

例：問い合わせ対応への組み込み
問い合わせメールから、Backlogにチケット自動登録
@ikikko 中村

http://www.backlog.jp/blog/2009/03/post.html

例：Cacooでの開発プロセス
@ikikko 中村

http://www.slideshare.net/nulab/seasarwebcacoo

例：Cacooの開発プロセス
@ikikko 中村

http://www.slideshare.net/nulab/seasarwebcacoo

例：Cacooの開発プロセス
@ikikko 中村

やりとりをBacklogに集約

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

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

3年半
206
@ikeike443 池田

プロジェクト

一人平均3−10プロジェクトの利用？

利用形態
社内社外

開発導入
プロジェクト型
社内 WEB制作
@ikeike443 池田

依頼協業

チケット型期限

FAQ

社外ユーザなど文化の異なる人と

タスク
SVN
@ikeike443 池田

フゔ゗ル
社外
社内
Wiki
サブバージョ
ンがさー
メールで

雑務から新しい仕事を創る

定期的に
タスク棚卸
@ikeike443 池田

分析

APIの利用による定形・自動化

Backlog

Backlog API
@ikeike443 池田

定形タスクカスタムバーンダウン

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

• CIサーバ：Jenkins

DEV コミットフック
日々のコミット

開発マシン
@ikeike443 池田

すべてのバグ管理
スプリント中の（≒プロダクト
チケット管理バックログ）

QA
CVS
QAのリポジトリは定期実行
DEVと別複数環境並行

実際のルール
• 月初に定形タスクをAPIで投入（開発の標準タスク
等）
• 月初にさらに6-8割程度までタスクを作成
• 1タスクは8時間以内（超えるものは分割）
•
@ikeike443 池田

予定と実績の時間は入力し、バーンダウン生成
• 月末にタスク分析で失敗の原因を探る

テーマ3

チケット管理システムの
運用方法

運用
• 社内サーバーで運用中
– サーバ機
• 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チェックを
毎朝お願いしている。

改善要望について
• 要望は品質管理チームで取りまとめ
– プロセス改善の目的を兼ねているため

• 既存プラグ゗ンで対応可能な場合は実施
– 目的を再確認し、開発プロセス及び要求資料の改善を提示する
ことも少なくない。
@kanu_ かぬ

• チケットへの項目追加など
– 基本的にはプロジェクト一任。
– 運用しきれない管理項目を増やす傾向があるので、
立ち上げ当初は適宜ゕドバ゗スを行っている。

• 管理用のTrac Report
– 基本的にはプロジェクト一任。
– 全体的に利用できそうな場合は、品質管理チームにて作成する
場合もあり。

現状の問題点
• 個人への依存
– 部署対応ではあるものの完全に個人へ依存
– 依存脱却への取り組みは始まったが成果は出ていない
• やらされる、使わされるに慣れていて、改善への興味が薄い?

• Tracの管理
@kanu_ かぬ

– 管理がTracのWeb-UIのみで完結しない
– Tracに関わる広い知識が必要
• Subversion, Apache, Python, Maven, Jenkins等々

• 銀の弾丸
– 道具が解決してくれると思っている傾向がある。
– 開発プロセスを含めたポリシーの徹底が必要

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

２年ぐらい

チケット管理システムの運用方法

• 社内サーバーに設置して、業務（案件）単位にプロジェ
クトを作成。
• ゕクセス制御はLDAP連携で整備。
• 基本セットはredmine+LDAP+jenkins+SVN+
xUnit&PMD系&カバレッジ系（言語別）。
@takanafu 関

• ある程度はマクロですぐに提供できるようにしている。
• 案件のリーダーに対する布教活動。
• 社内プレゼンでの布教活動。
• ある程度標準化したチケットの種別やカスタムフゖール
ドと運用方法を準備して使いまわしている。

JIRA運用のよくあるパターン
• 運用する人：社内IS部門
– JIRAユーザーは数百人規模
– ユーザーとグループは全社認証情報と連携（AD多い）
– ただしプロジェクト設定はプロジェクト管理者に権限委譲

• データ量：数年使って数十万チケットになる
@ohnuki 大貫

• ゕベ゗ラビリテゖ：２４時間３６５日止まらないで
– HW障害対策は必須、パフォーマンス検討も時々行う

• バックゕップ：まちまちで難しい
– 会社(組織)の標準バックゕップ方法に準拠
• フラッシュコピー、テープ、DB共通バックゕップ
• オンラ゗ンバックゕップできるDBやバックゕップソフト利用

自宅サーバーで運用中
• フレッツ光
• Value Domain(DDNS): twitter4j.org
• Mac Mini(Core2Duo,2.66GHz,8GB)
@yusukey 山本

フレッツ光
ダイナミックDNS Ethernet

Internet

AirMac Extreme Mac Mini

管理
• 基本放置
• カスタマ゗ズは最小限
– 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
– バージョンゕップで問題が出たことはなし
• まれに脆弱性の通知がメールで来るのでパッチ

管理上の問題点と今後の展望
• ユーザーはあまり見てくれていない
– メーリングリストとJiraの串刺し検索?

• 省電力化
– クラウドにデプロ゗？
@yusukey 山本

– Jira Studio for OSSの利用?
• http://open.jira.com/secure/Dashboard.jspa

Backlogの運用方法
• サーバ管理
– （プロジェクトチーム側では）゗ンフラ面を特に考
慮する必要無し

• チケット管理方針
@ikikko 中村

– 「楽しくコミュニケーションすること」を重視
– あまりガチガチにしない

現状の管理における問題点
• メール爆発
• 情報の分散
– Backlog, Skype, EtherPad, Cacoo
– チケットに起こす前のたたき台の場所とか・・・
@ikikko 中村

他ツールの良いところを取り入れていきたい
（と個人的に思ってます）

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

現場が自由に使っている
• 社内外でプロジェクトが立ち上がるたび、
Backlogにプロジェクトを作る
• 最低限のルールのみ決めておいて、後は現場
の判断
@ikeike443 池田

• お客様、協力会社様、社員、全ての関係者を
入れてプロジェクトを運用

チケット管理システム大決戦第二弾

More Related Content

What's hot

Viewers also liked

Similar to チケット管理システム大決戦第二弾

チケット管理システム大決戦第二弾