スクラムをうまく回すために受け入れ基準をきちんと書く

はじめに

こんにちは。12月1日より、プロダクト開発のディレクションを担当している三好と申します。スクラムの役割定義で言うと、プロダクトオーナー（以下PO）がしっくりくるかと思います。

みなさんの開発現場では、スクラムがきちんと機能していますか？　POとスクラムマスター、エンジニアがきちんとコミュニケーションをとって開発を進められていますか？
今回は、「受け入れ基準をきちんと書くこと」をテーマに本記事を書きます。

背景

弊社は、昨年9月11日に開催したSmartHR Next 2018で、「SmartHR」のプラットフォーム化構想を発表しました。

これに伴い、雇用契約機能や年末調整機能、店舗向けのiPadアプリなど、SmartHR本体と連携する機能と、SmartHR本体の開発をチームを分けて進めていく体制に移行をしていきました。
機能が増えるということは、機能に対するビジネス要件もより広範に、かつ複雑化していきます。一方で、エンジニアの数は増加し、昨年1年で約10人増えました。

私が入社し、大きな課題の1つと感じたことは、開発プロセスにおいて、暗黙知で補われているコミュニケーションが多く、それが結果として当事者間の意識のズレや手戻りを生んでいることでした。
SmartHRでは、1週間のスプリントを切り開発を進めています。そして、スプリント中に行った実装をデモし、確認するスプリントレビューを、スプリントの終わりに実施しています。
開発者が増え、要件が広範かつ複雑になるにつれ、スプリントレビューでの手戻り発生の起きる頻度が増えてきていました。

良いチケットとは？

これらの原因の多くは、チケットで実現するユーザーストーリーもしくは受け入れ基準のどちらかが曖昧であったことに起因していました。
チケットに具体的な要件が書かれていないものでも、なんとなく内容が伝わるからとスプリントにのせていたりしないでしょうか？
開発がGOできるチケットが絶対必須の条件として備えていなければならないことは、

実現したいユーザーストーリー（もしくはビジネス要求）が、誰が見ても迷いなく理解できる状態で明確になっていること。

だと考えています。
受け入れ基準は、この状態を実現するために、理解の揺れをなくし、実装された機能がビジネス要求を満たしているかをチェックするためのものです。

確認者が、思い込みでOKにする余地を残さない。確認環境さえ整っていればサルでも確認ができる。
実装する人が、受け入れ基準を見てそれを最終ゴールだと思って走れる。

このレベルの受け入れ基準が実現したいユーザーストーリーとセットで書かれていることで、実装するエンジニアは迷いなく実装に入れ、実装後の「手戻りかYO！」の不幸を防ぐことができます。
ストーリーを見ただけではわからない「曖昧な部分」を指摘し、より具体化することができます。
「曖昧な部分があるけど、これはなんとなくこういうことだろう」と実装者が自身の理解をいれないと実装に入れないチケットは良いチケットとはいえません。

例を挙げてみます

SmartHRには管理者が従業員のリストを参照することのできる「従業員リスト」という画面があります。
この画面で表示されている従業員の表示項目をカスタマイズすることのできる機能を提供する場合は、どう書くのが適当でしょうか。（実際はすでに機能は提供されています）

■チケット名：
管理者が、従業員リスト画面の表示項目をカスタマイズすることができるようにする。

■課題：
管理者は、見たい従業員の登録情報だけをリストして見たいケースが存在する。不必要な情報が存在するもしくは見たい情報がない場合、確認工数が無駄に発生してしまう。

■実現したいこと・ユーザーストーリー：
・管理者は、従業員情報に登録されている情報から、一覧に表示させたい項目を選択し、表示セットとして登録することができる。
・管理者は、一覧画面から表示セットを呼び出すことができる。
・管理者は、呼び出した表示セットの一覧の項目をソートすることができる。

■受け入れ基準
・一覧画面から、情報項目のカスタマイズメニューボタンを押し、一覧表示項目カスタマイズ画面に遷移する。
・カスタマイズ画面から、追加するボタンを押し、表示項目登録画面に遷移する。
・表示項目登録画面で、グループ名の追加および表示項目を複数選択できる。
・選択できる表示項目は登録できる従業員情報がもれなく網羅されている。
・登録した一覧表示項目は、一覧画面の表示選択プルダウンメニューから呼び出すことができる。
・呼び出した一覧と、登録した表示項目に差異がない。
・呼び出した一覧の項目それぞれでソートをかけることができる。
・項目数が多く表示しきれない場合は横スクロールで表示させる。

実現したいことやユーザーストーリーを細かく書ききれない場合でも、
その機能をどうデモするか？　テストするか？という観点で受け入れ基準を書いてみると、
どういう要素・条件が必要か。ということがわかります。
上記では性能要件などは記載していないのですが、同時アクセス数や応答時間などの要求がある場合は、それも記載する必要があります。
また、内容によってはワイヤやモックで説明する必要もあるでしょう。
受け入れ基準を書く段階で、？がたくさん浮かぶようであればそれはまだ開発GOすべきチケットではないと言えます。

曖昧なチケットを放置すると何が起きるのか

実際のところ、暇な人はいません。この記事を読まれている方は、おそらく日々の業務に忙殺されている方がほとんどでしょう。
ちゃんと書かなきゃなあ。と頭では理解していても、「よしなに」のレベルで物事が進むのに慣れてしまうと、必要最小限の説明だけですませるようにしてしまいます。
しかし、曖昧なチケットによって開発が進む状況を放置すると、いずれメンバーとプロダクトが拡大した際には、以下に記載したような事態が頻発することになります。

特にユーザ影響確認せずリリースしてバグになる。リリースするたびにバグ祭り
そもそもこれが求められているものだったんだっけという状態でリリースし、修正リリースが発生する。
デプロイ直前になって手戻り発生
影響範囲の確認漏れでデプロイのたびに別機能に地雷が仕掛けられて後から爆発炎上
エンジニアとPO（ビジネスサイド）同士がお互いにお前が悪いと反目を始める。
結果、お客様への価値の提供も満足にできなくなる ※かつて身をもって体験した実話です。。

バックログにあげられる状態のチケットであれば、受け入れ基準は数分で書けるはずなのです。
この数分をしっかりかけるか、適当に記載して、後はよしなにやってくれることを期待するか、どちらがHAPPYな現場になるかは明らかでしょう。

一方で、細かくしすぎて結果としてスピードが落ちることを望んでいるわけでは決してありません。
重要なのは暗黙知が前提として話が進まないようにすることなので、前提となる情報などを社内ナレッジツールに貯めた上で、なるべく余計な説明をしなくてもいいようにする。という環境の整備は同時に必要だと思います。
また、チケットをあげる人がエンジニアでない場合、どこまで細かく書けばよいのか、またそもそもバックエンドのことなどわからん！ということもあるでしょう。
その場合は、素直にその点については相談して決めればよいと思います。
適度なバランス感を求めるためのカイゼンはスクラムの中で続いていくことになります。そこが面白いところでもあります。