「チケットを切るときどんなことに注意すれば良いのかわからない。。」
「エンジニアに依頼するときにチケットに何を書けばいいのか？」
今回は開発時に作成するチケットの作り方について、ポイントを紹介します。
チケット作成は会社によってはプロダクトマネージャー（PdM）ではなく、プロジェクトマネージャー（PjM）が行うケースもありますが、実際兼務しているケースも多いと思います。
今回の内容が少しでも参考になったら幸いです。
こんな方におすすめ
どのようにデザイナーに依頼すれば良いか知りたいエンジニア
プロダクトマネージャーを目指していて、デザイナーとの仕事の進め方に不安がある人
デザイナーを含めたチームビルディングに悩んでいるマネージャー
目次
なぜチケットを切るのか
プロダクトマネージャー（PdM）はどんなものを作れば良いか分からない状態から機能を定義し、仕様に落とし込んで、エンジニアに依頼しなければなりません。
エンジニアに実装を依頼するときには、その依頼内容を適切な単位で切り出して依頼します。
その開発スタイルをチケット駆動型開発と呼びます。
アジャイルやスクラムなど、さまざまなフレームワークが存在しますが、実装すべき内容を定義して、チケットとして切っていく（チケットを切る＝作成すること）行為はどの手法でも共通です。
では、そもそもなぜチケットいう単位で依頼する必要があるのか？
チケット単位で依頼する理由は以下の通りです。
- 実装範囲を限定することで手戻りを少なくする
- 進捗をリアルタイムで把握する
- チーム内で誰がどの機能を実装しているか把握する
ただし、実際にどのような手順でチケットを切れば良いのかは、チームやプロジェクトの状況によっても変わっていくので、一概に正解はありません。
では、実際プロダクトマネージャー(PdM)としてどんなことを考えてチケットを作成しているのか、そのポイントを紹介します。
完了条件を明確にする
チケットを作成する理由は、小さなゴールを作って、それに向かって小さく実装を積み重ねていくことです。
そのためには、そのチケットのゴールを明確にしなければなりません。
タスクのゴールを明確にしろというのは当たり前のようにも聞こえますが、チケット作成においては少し違う言い方もできます。
そのチケットのゴールを明確にしろというのは、言い換えれば達成可能な単位にチケットを分解するということです。
どういうことか？例を挙げます。
例えば、「画面の表示速度を上げる」というような課題があった場合、表示速度をどれだけ上げればそのチケットがクローズ（チケットが完了となること）されるのかわかりづらくなります。
2倍にすれば良いのか。それとも3倍を目指すのか。
どれだけ目指すのかによっても工数が大きく変わってきます。
こう言った場合、例えば「表示速度を1.5倍にする」など、段階的な目標値を定量的に設定するなどの工夫が必要です。
また、UIに不具合があった場合なども、正しい挙動を定義して、その挙動にあった**状態**をゴールとすべきです。
よくあるのが、不具合の内容だけ書かれていて、どんな状態であればOKであるのかが定義されていないケースです。
その際主観ではなく、プロダクト仕様と照らし合わせて、あるべき状態とのギャップを記載するようにしましょう。
また、誰がみても達成できたことを確認できる内容になっていることがポイントです。
そのチケットの完了状態が明確であること、これが良いチケットであることの最低条件です。
スケジュールを適切に設定する
大抵のチケット管理ツールは期限が設定できるようになっています。
期限のないチケットは100%対応されないので必ず期限は設定しましょう。
チケットの終了日をあらかじめ合意しておくことで、開発にメリハリをつけることができます。
ただ注意点として、必ず守らなければならない期限と、柔軟に対応可能な期限はあらかじめチームで合意していくといいでしょう。
開発していると必ず不測の事態が起こります。場合によっては期限を延ばしたり、他のチケットを優先したりと、状況によって柔軟に対応しなければならない時があります。
全てのチケットの期限を厳密にしてしまうと、余計なプレッシャーになったり、期限を優先するあまり適切な実装で進められなくなったりします。
逆に延び延びになってしまうと、チケットがだらだら放置されてしまうので注意が必要です。時間がかかりすぎている場合は、適切に細かいチケット切って段階的に対応するべきでしょう。
常に開発状況や、品質、メンバーの習熟度を確認しながら、柔軟にスケジューリングを行うこともプロダクトマネージャー（PdM）/プロジェクトマネージャー（PjM）の役割です。
工数はなるべく均一に保つ
チケットには、期限と同時にそのチケットにかかる時間=工数を定義する必要があります。
大抵の場合、開始日と終了日が設定されたチケットをエンジニアにアサイン（割り振り）し、順番に対応していくというアプローチがとられます。
この時、複数チケットを同時にアサインすることはなるべく避けた方がいいです。優先順位がつけられていない証拠ですし、エンジニアもどちらを優先して対応すべきか迷ってしまいます。
また、チケットの工数はあまり長すぎず、1~2日、長くても3日程度の工数になるのがベストです。
あまり長すぎると進捗も測りづらく、開発ペースのコントロールも難しくなります。
逆に時間単位など短すぎてもマイクロマネジメントになってしまい、お互いストレスになってしまうため、チームで適切な粒度を議論しておくのがおすすめです。
ある程度粒度を揃えたチケットが作成できるようになれば、工数の見積もりも予測しやすくなります。
例えば工数2日のチケットを5つエンジニア1人にアサインした場合、
2日 x 5 = 10日
というように、ある程度完了の時期を予測することができます。
優先順位の付け方のルールを決める
プロダクト開発できられるチケット数は膨大なものになります。
規模にもよりますが、数百個を超える現場も多々あると思います。
全てを消化できるほど潤沢なリソースや余裕のあるスケジュールだったら問題ありませんが、大抵の場合限られたリソースの中でやりくりしなければなりません。
そんな時に重要になるのが、チケットの優先順位の付け方です。
大抵のプロジェクト管理ツールには優先度を設定することができます。
ですが、どのチケットを高く、または低く見積もれば良いのか悩ましい状況がしばしばあります。
また各々が自分の主観で優先順位をつけてしまうと、人によって基準が違ったり、コンフリクト（衝突）が発生してしまいます。
そのためチーム内で**優先順位の付け方のルールを定義する**ことをお勧めします。
例えば、ビジネス的に絶対にリリースしなければならない機能は優先度が高く。機能は使えるがデザインが崩れている場合などは優先度を低くするなど。
コンスタントにリリースしたい場合、リリース日までに全てのチケットを消化できるケースはあまりなく、ある程度捨てて次回に回さざるを得ないケースがあります。
そんな時優先順位の付け方を明確にしておくと、社内のステークホルダーへ説明しやすくなります。
ぜひプロダクトやチームにあった優先順位付けルールを作ってみてください。
まとめ
いかがでしたでしょうか。
今回はプロダクトマネージャーが良いチケットを切るためのポイントについて紹介しました。
開発チケットの作り方に正解はなく、会社やチームが変わればやり方も変わります。
重要なのは、チームのメンバーと議論しながらルールを作っていくことです。
ぜひ試行錯誤しながらチームに合ったやり方を考えてみてください。
今回の内容が少しでもお役に立てたら幸いです。
