こんにちは。PM(プロダクトマネージャー)のhiroki_Mです。
年末調整を担当しています。趣味はお絵描きと虚無になることです。
2年前に私が公開した記事「スクラムをうまく回すために受け入れ基準をきちんと書く」が、現在も思ったより多くの方にご覧いただいていることがわかりました。
スクラムやアジャイルについては様々な記事が出ているものの、現場目線での実体験に基づく情報を得たい人は多いのかも、と思い、前回書いたものをアップデートした記事を書くことにしました。
この記事では、「早くしっかりユーザに価値を届けるための、チケットの書き方のポイント」をテーマに、スクラムをうまく回す※ために気をつけるべきチケットの書き方のポイントについて書こうと思います。
やりたいことと開発者をつなぐのがチケットです。開発プロセスをカイゼンしても、チケットがきちんとしていないと、その効果は表れづらいです。逆に、やりたいことと意図が正しく伝わるチケットがきちんとかけていれば、開発プロセスはうまく回るようになっていきます。
普段の開発で手戻りが多い、もしくは内容の確認が多く開発がスムーズに進んでいる感覚がない。そんな方に少しでもヒントになるものになれば幸いです。
なお、この記事では、書いたチケットはチームでリファインメントを行うこと、スプリントは1週間単位で回すことを前提にします。
※スクラムをうまく回すことの先には、お客様への価値提供とフィードバックのループを早くし、提供する価値を最大化するという目的があります。
ポイント1. チケットで網羅する内容の認識を揃える
チケットで網羅する内容はチームでフォーマット化しておくのが良いです。
私がいるチームでは以下の内容をチケットの基本形としています。
- 背景
- やりたいこと
- やらないこと
- 受け入れ条件
- 受け入れ担当者
- 実装方針
- 成果の計測方法
- リリース調整の有無
- コンテンツの更新有無
起票されたチケットのフォーマットがチケットごとに違う場合、リファインメントやプランニングの精度に影響を及ぼします。
そのため、なるべくフォーマットは決めておき、チケットの内容に応じて必要のない項目はチケットから削るのが良いと思います。
上記に記載した項目のうち、
- 背景
- やりたいこと
- やらないこと
- 受け入れ条件
はどんな環境であれ必須かなと思いますが、その他の項目はプロダクトの性質によって進めやすい内容に変更すると良いと思います!
ワンポイント
それぞれの項目に何を記載するか、私がいるチームの場合を参考として載せておきます。
- 背景
- 「なぜやるのか(得たい成果)」「現在の課題」を書きます。詳しくはポイント2に記載しています。
- やりたいこと
- 実施したいカイゼン、機能追加を具体的に書きます。
- ワイヤーや、仕様に関するドキュメントがある場合はこの項目に記載します。
- やらないこと
- チケットのスコープとしないことを記載しています。
- このチケットでは実現しないものの、後続となる別のチケットで実現することがある場合は、そのチケットを合わせて記載しています。
- 受け入れ条件
- 受け入れ条件を記載します。
- 受け入れ担当者
- 受け入れテストを実施する担当者を記載します。
- 属人化を防ぐために、人の名前ではなく職種名を記載するようにしています。(PM、エンジニア、QA、UXライターなど)
- 実装方針
- フロントエンドおよびバックエンドの実装方針を記載します。
- 記載は、リファインメント時に行うか、リファインメント前にエンジニアがチケットを確認する際に行います。
- 成果の計測方法
- チケットが実装された後の効果をどのように測定するのかを記載します。
- リリース調整の有無
- リリース日の調整や、お知らせの発出、一部ユーザへの限定リリースなどを実施する場合に記載をします。
- コンテンツの更新有無
- ヘルプコンテンツや、サービスサイトなどの更新が必要な場合に記載をします。
ポイント2. 背景を明確にする
「どのような課題を解決するのか」「なぜやるのか」は具体的に記載するようにしましょう!背景はおおよそ次のいずれかに大別されるかなと思います。
- お客様の課題を解決したいから
- プロダクトの課題を解決したいから
- リスクを潰したいから
課題は、「お客様が得たい結果は何か(目的)」と「現在は得たい結果に対してどのようなギャップが出ている状態なのか」を書くとわかりやすいです。
また、根拠となるデータ、ヒアリングによる生の声や、サポートやカスタマーサクセスによる声がある場合は、是非載せましょう。
背景がないと、「やりたいこと」に記載したことが、本当に課題を解決するものであるのかどうかの妥当性を評価することができず、代替案の検討や実施可否の判定を行うことができません。
また、「背景」がないチケットを扱い続けることで、中長期的にそのチームは「自律駆動で考えないチーム」になっていく危険性があります。
チケットの内容やチームの成熟度によって、背景の記載を省いても良いケースが出てくると思いますが、基本的には背景はがんばって書いていくのがベストです!
例
たとえば、「労務担当者がシステムの従業員データをCSVで一括更新できる機能」があるとします。
ところが、項目に指定した値が適切ではなく更新が失敗するケースが多いことがわかり、この機能に「更新失敗を減らすため、サンプルファイルをダウンロードできるようにする」というストーリーを新たに追加します。
その場合、記載する内容としては以下のような感じになるかなと思います。
- 目的
- 更新に使用するCSVのサンプルファイルを提供することで、CSVによる更新失敗を減らし、担当者の手間を削減したい。
- 現状
- CSVによる更新処理のうち、○○%でエラーが発生している。エラーが発生した場合は、エラーが起きた箇所を修正し、再度CSVをアップロードし直す必要がある。
- 項目のバリデーションエラーがエラー原因の大半であるため、項目のバリデーションルールをCSVの作成前に伝えることでエラー件数を減らしたい。
- CSVファイルのアップロード画面にヘルプページへのリンクを用意しているが、CTRは○○%とほとんど見られていない。
得たい結果と現状、対応した時のインパクトが分かるものになっていれば良いと思います!
ワンポイント
- 背景を詳細に記載しなくても良いチケットもあると思います。バグの改修や、上位のfeatureのチケット、もしくはPRDで説明が既に行われている場合などです。
- プロダクトの課題?と思った方。あなたのやりたいことを溜めた心のバックログを持っていませんか。心のバックログにやりたいことがあるということは、それをやりたい理由があるはずなのでそれを書きましょう。
ポイント3.「詰める必要があること」を明確にする
チケットが書かれた時点で、仕様の細部までが決まっているケースと、要件までが決まっているケースがあると思います。
着手後に明確にする必要があることと、仕様のゆらぎがない部分は「やりたいこと」でわかるようにしておくと、チケットを扱う時に混乱が起きずにすみます。
私のいるチームでは、UXライターがスクラムに参加しているため、細かい文言などはチケットのサブタスクとしてプランニング時に起票し、実装しながら決めていく。という進め方をするケースがあります。
この場合、具体的に何を開発を進めながら決めていくのか。をチケット内で明確にするようにしています。
ポイント4. 受け入れ条件にはチーム全員の目を入れる
受け入れ条件を記載することの重要性は私の記事「スクラムをうまく回すために受け入れ基準をきちんと書く」を見ていただければと思います。
受け入れ条件を書く上で重要なポイントは、チーム全員の目を入れることです。
ユーザから見た期待値が実現できているかどうか?という観点でPMが受け入れ条件を書くことはできますが、それだけでは品質担保はできません。
QAやエンジニア、UXライティングの観点から、受け入れ条件の網羅性・深さの確認を行うことが大事です。
ポイント5. チケットのサイズはできる限り小さくする
チケットのサイズはできる限り小さくするのがよいです。
3ポイントのチケットを3つ消化するのと、8ポイントのチケットを1つ消化するのとでは、後者のほうが明らかにバーンダウンに向けての不確実さが増します(バーンダウンできたとしても、バーンダウンチャートのラスト1日で崖になるシーンをよく見ることになります)。
これは、ポイントが大きいほど、考慮事項が多い、影響範囲が広いといった実装にあたっての不確実性が多いということを内包しているからです。
そのため、1チケットで扱うには大きすぎるということが明らかになった場合は、素直にチケットを分割するのがおすすめです。
ここで重要なのは、分割したチケットそれぞれでユーザーストーリーが完結するようにすることです。
たとえば、
- 従業員がマイページから配偶者の情報を申告できる
というストーリーがあるとします。
このチケットで実装する画面は、申告するフォームが長大であり、13ポイントの見積もりが出てしまいました。
この場合、「フロントの実装」と「バックエンドの実装」というような技術レイヤーでチケットを分割することはおすすめできません。
なぜならば、お互いのチケットが疎ではなく、フロントを実装する人とバックエンドを実装する人の考慮することはチケットを完結するにあたって一切減っていないからです。
この例であれば、
- 機能実装で分ける(「データ入力、受け渡し」と「バリデーション実装」)
- フォームで扱うオブジェクトの塊ごとに分ける
というような方法が考えられます。
ワンポイント
「1チケットで扱うには大きすぎる」はチームとしてポイントの基準をどこに置いているかによるので、こういうチケットは危険だぞ、というのを書いておきます。
- 確認する画面・機能が複数にまたがる
- 受け入れ条件で考慮すべきパターンが多い
- 実装方針がリファインメント時点ではっきりしない
チケット(ユーザーストーリー)の分割の手法については、『アジャイルな見積りと計画づくり 〜価値あるソフトウェアを育てる概念と技法〜』という書籍により詳しい考え方が記載されています。
最後に
「早くしっかりユーザに価値を届けるために、チケットの書き方のポイント」をテーマに、気をつけるべきポイントを書いてみました。
ここに書いた内容が正解!というわけではなく、チームやプロダクトの環境、性質によって常にアップデートが必要なものです。
普段プロダクト開発に関わる方にすこしでもお役に立つ内容があれば、幸いです。がんばってやっていきましょう!
We are hiring!
SmartHRなら、自分の作っているものが本当にお客様の役にたっているかわからないプロダクト作りではなく、お客様のためのプロダクトづくりに真剣に向き合えます。
エンジニアもPMもプロダクトデザイナーも絶賛募集中です。興味を持たれた方は、ぜひご応募よろしくお願いします!
◆エンジニア採用情報
◆PM採用情報
◆プロダクトデザイナー採用情報