エンジニアにチケットを作成する際に気をつけるべきチケットの粒度について

はじめに

開発手法にはアジャイルを始めとした様々な方法が存在しています。

プロジェクト全体の進捗を確認するにあたって、ひとつのチケットの大きさに統一性が無いと、以下のような問題が発生します。

• ひとつのユーザーユーザーストーリーでも解決にかかる時間に差がある
• 多くのユーザーストーリーを消化したが、プロジェクト全体として進行していない
• ユーザーストーリーの消化率を開発者の評価基準としているが、評価軸として活用できない

今回は、アジャイル開発においてプロダクトオーナーと開発者が共通の認識を持てるよう、チケットの粒度についてどう考えるべきかを紹介していきます。

アジャイル開発とは

チケットの粒度について記載する前に、アジャイル開発について簡単に説明をしておきます。アジャイル（agile）には「素早い」「機敏な」といった意味があり、実装やテストを機能単位の小さいサイクルで繰り返して開発を進めるのが最大の特徴です。

このサイクルは「イテレーション」と呼ばれ、一般的に１〜２週間程度でひとつの機能をリリースします。そのため、不具合が発生した場合でも手戻りの工数を最小限に抑えることができたり、仕様変更に柔軟に対応できたりするメリットがあります。

一方で、短いサイクルを繰り返していくうちに全体像が見えにくくなるというデメリットがあります。そこで、アジャイル開発では顧客に提供したい価値を開発者が認識しながらイテレーション回すことができるように「ユーザーストーリー」という概念が存在しています。

ユーザーストーリーは通常プロダクトマネージャーやプロダクトオーナーによって作成され、仕様が決定すると開発者へと渡ります。

プロジェクト管理ツールを用いると、多くの場合このユーザーストーリーはひとつのチケットとして扱われ、プロダクトオーナーはひとつのユーザーストーリーにつき、ひとつのチケットを作成していくことになります。

チケットの用語について

ユーザーストーリー

「ユーザーストーリー」は先述のように、顧客に提供したい最終的な価値を開発者が認識しながら開発を進めるために存在している単位となります。

一般的に仕様書の代わりとして用いられ、プロダクトオーナーが実現したいことを Who・What・Why を用いて端的に表現します。

ひとつのイテレーションの中でリリース可能な大きさの機能をひとつのチケットに定義し、プロジェクトの進行状況や変更に応じて、新しいユーザーストーリーを作成していきます。

エピック

開発が大規模になるにつれて、ひとつのイテレーションの中では完結できない大きさの提供したい価値が出てくる事があります。

数ヶ月かけて実現したい価値がある場合、ひとつのユーザーストーリーで表現することはできません。そこで利用されるのが「エピック」という概念となります。

複数のユーザーストーリーをエピックでまとめることにより、それぞれのユーザーストーリーがどの最終的な目標に紐付いているのかを開発者は認識することができます。

タスク・サブタスク

プロダクトオーナーによってエピックやユーザーストーリーで定義された価値を開発者は受け取り、 How を「タスク」や「サブタスク」に定義して作業を具体化します。

プロダクトオーナーは開発者に渡ったチケットの進捗を確認しながら、プロジェクト全体の進行状況や開発者の稼働状況を把握していきます。

チケットの粒度について

では、実際にチケットを作る際にどのような粒度でチケットを作成するかですが、一般的なチケットの種類と規模感の例としては以下のようなものとなります

例えば、１チーム５名、イテレーション期間を２週間と定義しているチームでは、２週間の中でおおよそ２〜３個のユーザーストーリーをこなしていくのが理想です。

件数が多すぎると優先順位付けが難しくなり、見積もりの工数にも時間がかかるようになります。逆に、件数が少なすぎるとひとつのユーザーストーリーに工数をかけすぎて、機能を盛りだくさん詰め込んでしまう問題が発生します。

チケットの具体例

ここではもう少し具体的にチケットの例を見ていきます。

例えば、四半期の事業計画の中で「顧客獲得単価の削減」というKPIがあるとします。この目標を達成するためには、バイラルな集客の仕組みを作る必要があるため「招待プログラムの改善」を行う案が採用されることになりました。

これを各チケットに落とし込むと、以下のようなものになります。

ここでは以下の点を念頭に置きながらチケットを作成しています。

• エピック: 四半期の事業計画で決定されたKPIを開発項目に落とし込んだもの
• ストーリー: エピックをユーザーストーリーの形で数週間で完了できる大きさに落とし込んだもの
• タスク・サブタスク: 作成されたエピックに紐づく開発者が必要な作業

上記の例ではユーザーストーリーはひとつしかありませんが、実際にはひとつのエピックに対して複数のユーザーストーリーが紐づくことになります。

プロダクトオーナーはエピックとストーリーを作成し、細かいタスクやサブタスクについては開発者に委任していきます。

まとめ

ひとつのチケットの粒度が定まると、開発者は作業しているはずなのにプロジェクトとして進捗が思わしくなかったり、チケットの粒度によって開発者の進捗に偏りが出たりすることを防ぐことができるようになります。

開発の進捗が思わしくない場合、ひとつのイテレーションの中でどれくらいのユーザーストーリーを消化する想定でチケットを作成しているか、開発者と一度確認してみると良いかもしれません。

ただ、開発者のチケット消化数を評価と紐付けている場合、チケットの消化数だけを見て進捗の悪いメンバーが稼働していないと判断することはできません。実は他のメンバーのレビューに時間を取られていたり、担当となっているチケット以外に負荷となる要因がある場合があります。

OfferdManager では Jira でのコミュニケーション量や GitHub での作業、チーム間の Slackコミュニケーション量を可視化することができ、チケット上では見えない開発者の負荷を早期に発見する助けとなります。