youRoomとPivotalTrackerではじめる無駄のないコミュニケーション
チケットの登録の仕方
 |
図14：チケットの登録（クリックで拡大） |
プロジェクト画面の「ADD STORY +」ボタンから、図14のようにチケットを登録します（画面上には「ストーリー」と表記されていますが、前回の記事から一貫して「チケット」と呼称しているため、引き続き「チケット」と呼ばせて頂きます）。
最低限設定しなくてはいけない項目は「Story Title」で、図14では「デッキの一覧を見ることが出来るようにしたい」という部分にあたります。項目名は「Story Title」ですが、ここにはそのままユーザーストーリーを書いてしまうのが良いと思います。
ユーザーストーリーですが、一般的には以下のようなフォーマットで表されます。
（ 誰？ ）として、（ 要求 ）が欲しい、なぜなら（ 理由 ）するためである。
必ずしもフォーマット通りにユーザーストーリーを書く必要があるとは思いません。重要なのは、ユーザーストーリーを通じてプロダクトオーナーとプログラマーが共通の認識を持てることにあると思います。状況に応じて、適切なユーザーストーリーを作成していただければと思います。
チケットの種類をストーリータイプで設定する
一言にチケットと言っても、それが内々のちょっとしたタスクなのか、はたまたバグなのか、そういった種類を管理したい場合があります。これは「STORY TYPE（ストーリータイプ）」という項目で設定することが出来ます。
 |
図15：ストーリータイプ（クリックで拡大） |
図15の左から順に説明します。
| Feature | 一番左の★印のアイコンを「Feature（フィーチャー）」と呼びます。一番よく使うストーリータイプで、機能を実装するチケットであることを意味します。 |
|---|---|
| Bug | 次に表示されている虫の形をしたアイコンを「Bug（バグ）」と呼びます。その名の通り、不具合を意味しています。 |
| Chore | 次に表示されている歯車の形をしたアイコンを「Chore（チョアー）」と呼びます。プロダクトオーナーがアクセプト／リジェクトできないような内々のタスクにはChoreを設定します。例えばEC2のインスタンスを準備する、等のチケットにはChoreを設定したりします。 |
| Flag | 最後の旗の形をしたアイコンを「Flag（フラグ）」と呼びます。このストーリータイプは少し特殊で、マイルストーンを意味します。例えば「クローズドβリリースまでにここまでやる」といった使い方をします。図15のような形です。 |
 |
図16：フラグの使い方（クリックで拡大） |
設定できるその他の項目
チケットにはストーリータイプ以外にも設定できる項目があります。それぞれ簡単に説明します。
| POINTS（見積もりポイント） | チケットを相対的に見てどのぐらいかかりそうか、ポイントで設定します。通常はチケット登録時ではなく、プログラマーがチケットを見積もって設定します。 |
|---|---|
| REQUESTER（チケットを登録した人） | チケットを登録した人が自動的に設定されます。誰がこのチケットを必要としているのかが分かります。 |
| OWNER（チケットを実装する人） | 登録したチケットをスタートさせた人が自動的に設定されます。誰がチケットを実装しているのかが分かります。 |
| DESCRIPTION（チケットの説明） | チケットの補足説明を入力します。ユーザーストーリーだけでは分かりにくい、細かい仕様を書きます。youRoomで議論されている仕様の場合は、youRoomのトピックへのURLを貼り付けたりもします。 |
| TASKS（タスク） | チケットの粒度が荒く、チケットに取り掛かる上でさらに細かいタスクがあるような場合に入力します。本来であればチケット自体を分けるのが望ましいですが、チケットはあくまでもプロダクトオーナーがアクセプトできる単位である必要があるので、切り分けるのにも限界があります。例えば「◯◯決済システムで決済を出来るようにする」といったチケットの場合は、ユーザーの動作として「決済するかしないか」しかないので、これ以上チケットを切り分けることが出来ませんが、プログラマーが内々でやるタスクは数多くあるかも知れません。 |
| ACTIVITY（アクティビティ） | チケットの着手中に何か問題が起こった場合等はここに詳細を記載していきますが、大抵はプロダクトオーナーがチケットをリジェクトした時に、リジェクト理由を書く時に使います。 |
チケットに着手する
プロダクトオーナーがチケットを登録したら、次はプログラマーがチケットに着手する番です。
 |
図17：0～3ポイントの間でチケットを見積もる（クリックで拡大） |
 |
図18：見積もったチケットに取り掛かる時は「Start」ボタンをクリック（クリックで拡大） |
まずはチケットの見積もりです。図17の緑枠内のポイントを表すアイコンをクリックすると、図18のようにチケットがスタートできる状態になります。この状態になったところで「Start」ボタンをクリックし、チケットの実装を開始します。「Start」ボタンをクリックすると、チケットは図19の状態になります。
 |
図19：チケットが完了したら「Finish」ボタンをクリック |
 |
図20：プロダクトオーナーに見せられる環境にリリースしたら「Deliver」ボタンをクリック（クリックで拡大） |
チケットの実装が終わったら「Finish」ボタンをクリックし、チケットを次の状態（図20の状態）に進めます。実装が終わっただけでは未だプロダクトオーナーが確認できるような状態になっていないので、ステージング環境等にリリースした段階で「Deliver」ボタンをクリックし、図21のようなアクセプト／リジェクト待ちの状態にします。
 |
図21：アクセプト／リジェクト待ちの状態（クリックで拡大） |
プロダクトオーナーがチケットを確認する
プログラマーがチケットを終わらせたら、次はプロダクトオーナーが確認をする番です。ステージング環境等にリリースされた機能を確認し、チケットの出来をジャッジします（余談ですが、プロダクトオーナーがチケットをジャッジするために、チケットのゴールは何なのかをあらかじめ共有しておくことが非常に重要です）。
 |
図22：アクセプトされたチケット（クリックで拡大） |
 |
図23：残念ながらリジェクトされてしまったチケット（クリックで拡大） |
「Accept」ボタンをクリックするとチケットは図22のような状態になり、完了していることが一目で分かるようになります。このチケットでやるべきことは全て終了しました。
ここで「Reject」ボタンをクリックすると、チケットを再スタートするボタンが表示されます（図23）。プログラマーはプロダクトオーナーにリジェクトの理由を聞き、チケットを再スタートさせます。「Restart」ボタンをクリックすると、チケットは図19の状態に戻ります。
今回の解説はこれで終わりです。youRoomとPivotal Trackerそれぞれのご紹介から、具体的な使い方についてご説明しました。
このように、youRoomとPivotal Trackerを中心として開発サイクルが回っていくのですが、プロダクトオーナーがチケットをアクセプトしていくためには常にプロダクトが「動くソフトウェア」である必要があります。次回は「動くソフトウェア」を維持するために活躍したHerokuとTestFlightについて説明してまいります。
＜執筆協力 DaVinciWare（http://www.davinciware.com/）＞
