PHP 部の紹介も終わったところで

Redmine で始めるチケット駆動開発

佐藤琢哉LOCAL PHP 部

あれ、ここってPHP 部の時間じゃ…

技術的な話はほとんど出てきません

開発手法の話なのでPHP プログラマにも

安心して使えます

自己紹介• 佐藤琢哉 aka nazo• 旭川出身　東京在住• 株式会社 RYUS 所属 (http://ryus.co.jp)• rhaco-ja ？• LOCAL PHP 部• Hatena : nazone• twitter/wassr : nazo

LOCAL の人になりました

アジェンダ• チケット駆動開発について• Redmine について• 具体的な使い方• まとめとおまけ

そもそも何の話？

Redmine ？チケット駆動開発？

日本語でおｋ

タスク管理を効率的に行うための

話です

わかりづらい説明

チケット駆動開発

チケット駆動開発？

チケット• タスクの最小単位• 例えば「検索フォームで未入力の状態で

検索するとエラーになるので修正する」• 例えば「新規登録画面を実装する」• バグ登録フォームで登録したバグ１つ• バグ以外の新規開発もチケット

一つのタスク＝

チケット

チケット駆動開発• タスクをチケットの単位まで細かく区

切って、それを消化していく開発手法• すべてのタスクがチケットとして存在する

ので、タスクの量がわかる• チケットにステータスが付いているので、

タスクの消化量がわかる

チケットの消化量＝

進捗具合

どのくらい進んでいるかがチケットの量でわ

かる

プログラミングに限らず使える

普通の進捗管理の問題点• 誰が何してるのかわからない！– あの機能誰に振ったっけ？– あれ作るのに他の人の作業の完了を待たない

といけない？– その機能大きいから他の人と分担させたいん

だけど…え、全部に手をつけてるから分担できない？

普通の進捗管理の問題点• どこまでの機能が完成予定なのかわから

ない– 次回のリリースはどこまで含めるんだっけ？– あの機能は当然完成してるものだと思ってた

んだけど…

それEXCEL で

できるよ！

　

EXCEL ガントチャートの問題点• ガントチャートだからそもそも１日単位

でしかタスクをアサインできない– １日に何時間振るの？– １日のタスクの順序は？– そのタスクは現在どういう状況？

EXCEL ガントチャートの問題点• そもそも修正が面倒– 一人で全部設定するの？– 複数人でやったら誰がどこを編集したかわか

る？

そこでチケット駆動開発

そして

チケット駆動開発のための

Redmine

注意

チケット駆動開発で調べると

いろいろ出てきますが

どれが正しい方法というわけではありません

今回の紹介は私の個人的な体験に

基づいて作成したものです

どれが正しいというわけではないので、

皆さんの状況に合わせてご利用下さい

Redmine とチケット駆動開発

Redmine ？

Redmine とは• Ruby On Rails をベースに作られた

Issue Tracking System– （懸案管理システム： ITS ）

• いわゆる trac とか Mantis みたいなの• チケットを登録して、チケットの管理を行

うためのシステム

trac

Mantis

Redmine のいいところ• 複数プロジェクトの管理ができる– 多数の案件を抱えている人には必須

• 豊富な標準機能– チケット、 Wiki 、タイムライン、ガント

チャート、カレンダー、リポジトリ、ファイル管理、 etc…

• 標準で日本語対応

インストール方法とか

• http://redmine.jp/• に大体載ってます• ryus.co.jp のスタッフブログでも少し書

きました

インストールの説明とかしても仕方ないので

実際の作業の流れを追ってみましょう

タスクの進め方

ワークフロータスク発生

チケット登録 担当者アサイン

実作業 解決

作業確認 終了

管理者タスク

開発者タスク

ここから実際の流れ

タスク発生！

タスクをチケットとして登録

タスクをチケットとして登録

チケット登録時の説明を

簡単にすると

１つのチケットはあまり時間が

かからないように

チケットを見て疑問点が

ないように

以上！

以下詳細

タスクをチケットとして登録• ほどほどに細かく分ける– 当然細かすぎてもよくない– 最初は細かすぎると思うくらいでいいかも

• １つのチケットは１人の担当者で解決できるようにする

• ケースバイケース

タスクをチケットとして登録• 時間がかかりすぎている、いつ終わるか

わからない、と感じたらもっと細かくする

• 明らかにまとめたほうがいいと感じたらまとめる

• １つのタスクを解決するのに、別の大きな問題が発生したら、途中ででもチケットを分割する

１つのチケットは最大でも

１日で終わるレベル

チケット入力フォーム

入力フォーム説明

トラッカー• チケットの大枠の分類。全プロジェクト共通

題名• そのチケットの内容を的確に表すもの• 短いよりは長いほうがいいが、長すぎない

ように– 「検索が動かない」よりは「検索結果が 0 件

になる」のほうがいい– 「検索が動かない」だと、「ボタンを押して

も反応しない」とか「次の画面が真っ白になる」とか「ボタンを押すと関係ない画面が表示された」という例も考えられる

説明• そのチケットの内容を詳細に記述• 以下の要素が必須– 具体的な発生条件（わかる範囲まで調べる）

• URL• 入力内容

– その結果どうなるか– 本来期待される動作

• チケットを起こした後に担当者がチケットを起こした人に再度質問しないようにする

ステータス• そのチケットの現状• とりあえず最初は当然「新規」

優先度、担当者、開始日、期限日、予定工数、進捗、ファイル

• 説明不要

Watchers

• このチケットを監視する人• 監視対象になると、マイページの

「ウォッチ中のチケット」で確認できる• 自分は起票者でも担当者でもないけど、

そのチケットの進捗を確認したい時などに使う

関連するチケット• チケットを起こした後に設定可能• 「このチケットを終わらせるにはあのチ

ケットを先に終わらせないといけないよねー」みたいな時に設定する

• 片方で設定すると相互リンクされる

チケットを起こしたら

ワークフロータスク発生

チケット登録 担当者アサイン

実作業 解決

作業確認 終了

管理者タスク

開発者タスク

担当者を決める

担当者はチケットが割り振られたら

ワークフロータスク発生

チケット登録 担当者アサイン

実作業 解決

作業確認 終了

管理者タスク

開発者タスク

優先度や期限などから作業順序を判断し

作業を開始する

担当者が作業中にするチケット操作

進捗• 通常は 0%→100% で終了することが多い• 少し長めのチケットの場合、数時間おき

に進捗を更新するとスケジュールが把握しやすくなる

• 作業開始時はステータスを「担当」にする

コメント（注記）• 作業中に気になったことや、メモしておき

たいことは随時記入する• 起票者と担当者が遠隔地にいる場合

（ OSS 開発とかでありそう）、ここを「このチケットに対するフォーラム」的な扱いとして議論することもある

こうして作業を進めていき

終わった！と思ったら

ワークフロータスク発生

チケット登録 担当者アサイン

実作業 解決

作業確認 終了

管理者タスク

開発者タスク

解決に必要なもの• 確認方法• ソースコード• ステータスを「解決」にする

まずコミットが

されていること

コミット• プロジェクトのリポジトリを事前に設定• コミットログに「 refs #1111 」のよう

にチケット番号を書くと、そのチケットへの相互リンクが作られる

• コミットログに「 fixes #1111 」のようにチケット番号を書くと、そのチケットが自動的に解決状態になる（要設定）

• refs とか fixes の文字は任意に設定可能

起票者が確認可能であること

確認• Web アプリの場合はそれを確認する URL• その他の場合はどのテストを実行すると判別できるか、など

• 「私の環境では動いたんだけど…」とかの基本的なミスをなくすために、自分以外の環境で動作を確認できるようにする

ワークフロータスク発生

チケット登録 担当者アサイン

実作業 解決

作業確認 終了

管理者タスク

開発者タスク

確認• 問題があればフィードバック（差し戻

し）にする• フィードバックになったチケットは、そ

れだけで時間の無駄が発生しているということになるので、どうすればフィードバックになるチケットが無くなるかを考える必要がある。

ワークフロータスク発生

チケット登録 担当者アサイン

実作業 解決

作業確認 終了

管理者タスク

開発者タスク

終了• お疲れ様でした！

「チケット駆動」の名の通り

チケットの扱いが重要なので

プロジェクトの体制や環境に合わせて

カスタマイズすると使いやすくなります

ガントチャートとか

あくまでおまけ程度の機能です

「全ての開発作業がチケットとして

登録されている」状態を

目標としてみてください

実際に弊社（ RYUS ）でも

使っています

RYUS では…• しばらく Mantis で管理• Mantisちょっと機能たりなくね？• そこで Redmine• 移行スクリプトも標準であるよ！でもか

なり手を入れた

RYUS では…• ステータスの追加–保留とか–却下とか– 一部 Mantis 時代の名残も

CSS 調整大事

チケット一覧カスタマイズ

class とか ID とか最初から振られている

のでCSS側を変更するだけ

その他便利機能

ロードマップ• マイルストーン• 次回のリリースではどのチケットが close

されている必要があるか？を一覧できる• 予定工数を入れておけば、「トータルで

何時間かかるか」も見ることができる

Wiki

• Textile記法• h1. 見出し• # リスト• チケット番号の自動リンク付き

（ #1234 ）• リビジョンへの自動リンク付き

（ r1234 ）

フォーラム、ニュース• プロジェクト自体の報連相に• ニュースは Redmine のトップページに出

る

リポジトリ連携• Git や Mercurial にも対応• 単純なリポジトリブラウザとしても便利• refs や fixes でチケットと連動• 設定するときは cron でリポジトリ情報を取得するようにする（説明省略）

まとめ

Redmine を使うと

タスク管理が楽になる

メリット• タスク管理がとにかく楽• Wiki とかもあるので情報の集約ができる• コミットとタスク（チケット）を関連付

けできる

よくわかんないという方は

とりあえずインストールして触ってみてください

使ってみないとわかりません

難点• インストールがやや面倒– Rails アプリの経験がないと…–Windows環境は更に難関

• API とか拡張方面に弱い– このへんは trac のほうが上

インストールは楽なほうがいい

PHP だともっと楽だよね！

PHP でRedmine みたいなの

あればなぁ…

PHP ならカスタマイズも楽なのになぁ…

そこで

Candycane

• 安藤祐介（ yandod ）さんが中心になって作られているオープンソースプロダクト

• CakePHP で Redmine を作る！• Redmine のコードをベースに CakePHP

に移植するのが第一目標• 将来的には独自路線の使いやすさを目指

す

Candycane

本当はこれの紹介を

重点的にしたかったのですが

私が既にあまり関わっていない

ためそれほど紹介できませ

ん

orz

今夏公開予定！（らしい）

おわり