会社でJIRAを導入して1か月。色々あるしカタカナだし何がどーだかよーわからん！
という声が社であがったので、突然ですが、居酒屋でJIRAの全体像をたとえてみたいと思います。
設定
JIRAの全体像を理解するために、今回はJIRAの中でも**「課題、コンポーネント、バージョン、プロジェクト」**という4つの要素を取り出して、居酒屋にたとえて説明したいと思います。
ということでさっそく、
あなたは居酒屋の店長になっていただきます。
バイトのみなさんと協力し、オーダーを取り、料理を出し、お会計をして、ガンガンお客さんを回していっていただきます。
4つの要素を、居酒屋でたとえてみた
★課題は、オーダー
居酒屋なので、なにはともあれオーダーに応じて料理を作ったり、飲み物を作ったりします。
この、お客さんに出すものの1オーダー、がJIRAでいう「課題」にあたります。
どんなものを、誰が、どういうふうに調理して出してそして食べていただいたのか…というものが、課題と紐づいています。
いわゆるタスクというやつですね。
- 課題には今どうなってるか（ステータス）と、やり方（ワークフロー）があります。
- オーダーがキッチンに通ったのか、ちゃんと提供したのかってことがステータスでわかる
- やり方は、ホールがオーダーをうけてキッチンに通して…といった、そのオーダーがお客さんに提供されるまでの流れのことをさす
- 課題にはタイプがあって、タイプにより違うやり方を設定できます。
- 料理はキッチン通すけどドリンクはそのまま作って出すみたいな、タイプごとにやり方の違いを設定できる
- 課題ごとに今だれが担当しているのか、担当者を設定できます。
- 課題には、サブタスクを設定できます。
- たとえば鍋料理であれば「鍋セットの用意」「コンロの提供」「シメのラーメンの提供」みたいに更に細かくタスクを分けることが出来ます。
★コンポーネント＝メニューの分類
居酒屋のメニューには、色々なタイプがあります。つまみ、メイン、焼き物、サラダ、デザート、飲み物…居酒屋メニューの成分、カテゴリーがコンポーネントにあたるものです。
- 課題はコンポーネントとして分類することができます。
- 一つの課題は複数のコンポーネントを持つことができます。
- さわらの西京焼きみたいなものは、「魚料理」にも「季節のおすすめ」にも入る、といったような感じでどっちにも入ることもあります
- コンポーネントにはリーダーを設定できます。
- ほら、よくいるあの、焼き鳥専門のお兄さんみたいな人とか…
コンポーネントは、あくまでラベルのようなものなので、つけてもつけなくてもいいですが、
つけておくと、キッチンで調理してる担当の人が、自分の料理にさっと取り掛かりやすくなって便利です。
コンポーネントに親子関係が欲しいなとは感じていますが、今のところコンポーネントには親子関係は作れません。
★バージョン…卓（テーブル）
バージョンは、時間と関係が深く、ほんのりステータスが分かります。
コース料理の飲み会プランのお客さんをイメージしてもらうと良いと思います。
居酒屋で言うとお客さんの1グループぶんのテーブルのようなもので、いっぱいくるオーダー（課題）はこのお客さんのいるテーブルに紐づけていくことができます。
そのお客さんのお会計が終わったらリリースということですな。
- 開始日とリリース日を設定できます。
- 飲み放題の予約は19時開始21時終了っていうアレです。
- バージョンに課題を紐づけ、いまどこまで完了したかが見やすい形になっています。
- コース料理で出るものが決まっていて、今どこまで出し終わったかというのがグラフで見られるようなイメージです
- 課題は基本的にはバージョンに紐づいていきます。
- オーダーはどこのテーブルに出すか、というのが決まっているように、課題にバージョンをつけていくといいと思います。
- たとえばものすっっごく大きい皿の料理で、オーダーによっては他の席を圧迫するようなものもあるかもしれません。「影響バージョン」ということで、他のバージョンに影響があることを設定できます。
- 課題には複数のバージョンを設定できます。
- この料理は分けたいので、などという感じで、1オーダーが複数のテーブルにまたがるイメージ
コンポーネントやプロジェクトと混ざりやすいですが、コンポーネントはオーダーを担当別に種別で分けるもの、バージョンは日付で分けるもの、といった違いがあります。
★プロジェクトは、お客さんのグループ
最後に、そのお客さんのグループが、プロジェクトです。
- そのお客さんグループの接客係や調理係（プロジェクトメンバー）を設定できます。
- 大きなプロジェクトの場合は複数のバージョンに分けて管理した方がベター。
- 貸切レベルの宴会では、いくつものテーブルを占拠ているあの感じ
- 基本的には、オーダーを取った時点でどのお客さんのものなのかが決まっています。つまり、課題は必ずプロジェクトに紐づくことになります。
- まれに、ラーメン屋的にまだ決まってないけど混んできたから麺茹でておくみたいな、プロジェクトが決まってなくても課題が起こることもある
- 一つのオーダーに対し、お客さんのグループを二つ登録することは出来ません。見知らぬ人同士で料理はシェアしないよ！
- つまり、課題にプロジェクトを複数設定することはできません。プロジェクトをまたいでの課題は作れませんし、プロジェクト同士で親子関係は作れません。
さっそく居酒屋を運営しよう
それぞれのことについて分かりましたね。ではさっそく開店です！
まず、なにはともあれ、オーダーを受けましょう。取ったらお客さんのテーブルで注文票、つまり課題を作ります。
もし同じオーダーが重なったとしても、当然お客さんごと、つまりプロジェクトそれぞれに課題を作ってください。
焼き鳥なら焼き鳥の板前さんに注文票を出します（コンポーネントの設定）。ドリンクであれば（課題タイプ）さっと作って出して、出し終わったら課題のステータスは「解決済み」にします。
そして、テーブルも設定しておきます。修正バージョンを入れて「７番テーブル」とラベルを貼っておきます。ファーストオーダーの時間を書いておきつつ、もし分かれば終了時刻を書き込みます。
テーブルの料理がちゃんと食べてもらえてるかバージョンで確認しましょう。
こうしてじゃんじゃん料理を出して、テーブルごとに料理を出し終わり、お会計が終わったらバージョンは「リリース」しましょう。
マジメな方の解説
プロジェクト、コンポーネント、バージョン、課題
それぞれの違いを簡単にまとめてみました。
プロジェクト
課題をまとめる一番大きな単位。
- プロジェクトをまたぐ何かを作ることはできない。
- プロジェクトの子も作れない。（サブプロジェクトはない）
- そのプロジェクトへの参加者が設定できる
コンポーネント
課題のラベルその１。成分。
- コンポーネントごとにリーダーが設定できるため、ワークフローと関係が深い。
- つまり、権限と紐づきやすい。
- ひとつの課題にコンポーネントというタグをつける形。
- コンポーネントはただのタグなので いくつつけても構わない
- コンポーネント同士に親子の関係は作れない。
バージョン
課題のラベルその２。リリースバージョン。
- 開始日、リリース日、進行状況といった、時間の概念がある
- 残り課題数がわかるなど、ほんのりステータスがわかる
- コンポーネントと一緒で、ひとつの課題にバージョンというタグをつける。
- バージョンはタグなのでいくつつけても構わない
- 修正バージョン（その課題が入ってるバージョン）と、影響バージョン（その課題により、影響があるバージョン）の２つがあるが、基本は修正バージョン。
- バージョン同士に親子の関係は作れない。
課題
タスク。やること。
- 誰がボールをもってるか、基本は人と課題が1対1になるようにする。
- プロジェクトが必須。コンポーネント、バージョン、ラベルなどといったタグがつけられる。
- 課題の進行状況がステータスといった形で、ある。
- 課題の子としてサブタスクを持てる。
- 課題タイプといって、バグ・新機能、のようなカテゴリーがある。
- カテゴリーごとに、ステータスの遷移の仕方（ワークフロー）が異なる。
まとまらないまとめ
大きめの改修だとコンポーネント単位でバージョン切ってたりすることがあってうまくいかない…
プロジェクトとバージョンの違いもいまいちしっくりこないよね…
という声がたくさんあがっていたので、実はBBQで例えてみましたが、社内で反応がイマイチでした（反省）。
ということで居酒屋に例えてみましたが、バージョンとプロジェクトの違いがくっきりしないので、そこは反省点。
ただ、実際には、バージョンのようにプロジェクトを立てることもあると思います。
そのあたりはそもそもチームが“どのようにプロジェクトの粒度を決めているのか”、
もっと簡単に言うならば、**チームが考える「プロジェクト」って何だ？**というところに繋がっていくのかなと思いました。
これを書きながら、金曜日ですし、ものすごく焼き鳥が食べたくなりました…