種別を分ける意味

バグも、新しい作業も、お客さんの思いつきも、同じ一覧に混ざっている。そのままだと、どれから手をつけていいのか迷います。

ひなたが、課題の一覧を見て悩んでいます。

ひなたケンジさん、「新しいページを作る」と「スマホでメニューが閉じない」と「採用ページに社員インタビューを載せたい」が、全部同じ並びに……。

ケンジ全部、性格が違うよね。

ひなたどう違うんですか？

ケンジ1 つ目は「やると決めた作業」、2 つ目は「壊れてるもの」、3 つ目は「まだやるか決まってない希望」。

ひなたたしかに、扱い方が全然違いそうです。

種別とは、課題の「種類」

種別は、課題の種類を表す札です。Web 制作でよく使うのは、次の 4 つです。

種別は、課題の詳細の件名の上に出ます。たとえば、こんな画面です。

• 件名の上の左に、種別の札（ここでは「バグ」）がある
• 右にいまのステータスがある

なぜ分けるのか

1. 扱い方が違う

種別によって、必要な手順が変わります。

• タスク: 担当を決めて、期限までに進める
• バグ: まず再現できるか確認し、原因を調べ、直す。優先度は、影響の大きさで決める
• 要望: まず「やるかどうか」を検討する。すぐ作業にはしない

要望は、すぐ作業にせず、検討を挟んでタスクにします。

最初のタスクとの違いは、「検討する」の段があることです。

もし要望を最初からタスクとして扱うと、「頼まれたから全部やる」になり、スコープ（やること）がふくらみます。この危険は「スコープクリープを防ぐ」で扱います。

2. 数えられる

種別があれば、集計ができます。「バグが何件出たか」「要望が何件たまっているか」。品質の状態や、お客さんの関心が見えてきます。

デモのプロジェクトで、種別ごとに数えた件数です。

種別があるから、バグの件数だけを取り出せます。

3. 書くことが違う

バグには「再現手順」が必要ですが、タスクには要りません。種別ごとに書く項目を変えられると、必要な情報が漏れにくくなります。バグの書き方は「バグ報告の書き方」で説明します。

分けすぎないコツ

種別が増えすぎると、選ぶのに迷います。

• 4〜5 種類までにする
• 「迷ったら、これ」という種別を決めておく（たいていはタスク）
• 分類より、扱い方が変わるかどうかを基準にする

ケンジ扱い方が同じなら、分けなくていい。「デザインタスク」「実装タスク」みたいな職種の違いは、種別じゃなくて、ラベルで表すほうがいい。

ひなた種別は「扱い方の違い」、ラベルは「ほかの切り口」ですね。

ラベルについては「ラベルとタグの使い方」で説明します。

まとめ

• 種別は、課題の種類を表す札
• 扱い方・集計・書く内容が、種別で変わる
• 要望をいきなりタスクにしない
• 種別は 4〜5 種類までに。迷ったら「タスク」
• 職種などの切り口は、ラベルで表す

とらまる壊れたものと、希望と、作業は別の箱へ。

akamine でやるなら

akamine の課題には、タスク・バグ・要望・その他の種別があります。プロジェクトの設定で、種別ごとに「使う項目」と「必須の項目」を決められるので、バグには再現手順を必須にする、といった運用ができます。設定は「種別と入力項目」を見てください。

関連する記事

• バグ報告の書き方
• ラベルとタグの使い方
• スコープクリープを防ぐ