はじめに
「うちのチーム、アジリティ高いんですよ」
この言葉を聞いたとき、私は多分凄い変な顔をしていました。が今はそれは脇に置いておきます。
貴方はどんなチームを想像しましたか？
変化に柔軟に対応し、価値あるプロダクトを継続的に届けているチーム？
それとも、とにかくリリース速度が速いチーム？
後者を想像した方に向けて、この記事を書くことにしました。
アジリティとは
「変化への対応力」のことで「速さ」ではありません。
速さは結果として現れることはありますが、アジリティの定義そのものではありません。
ここを混同すると、チームは「アジリティが高い」のではなく「アジリティが暴走している」状態に陥りやすくなります。
その暴走に気づくのは、まぁ、概ね障害が多発した後だったり？
アジリティが「高い」チームと「暴走している」チームの違い
具体的にどう違うのか。症状を並べてみます。
| 観点 | アジリティが高い | アジリティが暴走している |
|---|---|---|
| 要件 | ストーリーに「誰が・何を・なぜ」が明記されている | 「口頭で伝えた」「やればわかる」「少ない情報量」で着手する |
| 受入基準 | 検証可能な条件がストーリーに明文化されている | 未記載、または「適切に処理されること」レベル |
| リファインメント | 要件の曖昧さと受入基準の不足を洗い出してからスプリントに入れる | 時間がないので形だけ実施、または省略する |
| スコープ | スプリント中のスコープが安定している | スプリント中にストーリーが後から再現無く湧いてくる |
| ベロシティ | 安定していて予測可能 | 数字上は出ているが、中身が毎回違う |
| 残業 | 想定内に収まっている | 常態化しているが、それが普通になっている |
この表を見て「右側、うちのチームだ」と思った方。仲間は多い。
いや、安心はしないでください。
要件と受入基準は別物です
ここで一つ、重要な前提を整理しておきたいと思います。
要件 とは、「誰が・何を・なぜ作るか」です。
ビジネス上の要求であり、ユーザーが達成したいことを記述します。……している筈……
受入基準 とは、「どうなっていればDone、つまり作業やリリースが完了になるか」です。
そのストーリーが完了したと判断するための、検証可能な条件を記述します。……している筈……
この2つは別の技術で書かれる、別の成果物です。
「そんなの当たり前だろう」と思った方は、次の問いに答えてみてください。
要件は書かれているのに受入基準が書かれていないストーリーは何割ありますか？
今これを読んでいる対象の方なら、少なくない数のストーリーが該当するはずです。
これは「手を抜いている」のではなく、「要件を書けていればリリースできる」という思い込みがまぁまぁ発生しています。
じゃあなぜこれが問題なのか。
要件が「何を作るか」を定義しても、「作ったものが正しいかどうか」を判定する基準がなければ、完成の判定は個人の感覚と想像力が鍵になります。
開発者は「動いたからDone」と思います。
QAは「仕様通りかわからないけどバグは見つからなかったからDone」と判断します。
PO或いはPdMは「なんとなくイメージと違うけどまあいいか」でリリースを承認します。
全員が違う「Done」を頭に描いています。
嫌な属人と間違った暗黙知の発生です。
チームとしての世界観と正解がまるで噛み合わないパターンにもなりやすいです。
受入基準とは、共通のゴールラインを引くために必須なものと考えた方が健全だと思っています。あとこれも上流工程だよ。
なぜ上流がスキップされるのか
要件の深掘りや受入基準の記載がスキップされるのには、構造的な理由があります。
私でも大体3つ位はパッと思い浮かびます。
1. 時間がない
期日が先に決まっています。
営業とか受注とか、評価社内政治的力学とか。
あるいはスプリントの期間内に「とにかく着手しないと間に合わない」というプレッシャーをかけてくる障害が存在します。
不確実性が高いのに中身を詰めずにスプリント突入て。
要件を丁寧に詰める時間、受入基準を検証可能なレベルまで書く時間。
これらは、最下流のテスト同様、最初に削られるコストとなりやすいです。
「要件定義に2日使うくらいなら、その2日で実装を進めたい」
この判断は、短期的には合理的に見えます。見えるだけだよ？調査も含めて大事だよ？
2. 書き方がわからない
要件と受入基準は別の技術が必要だと書きました。
つまりそれぞれ別の「わからない」が存在します。
要件側の「わからない」は、ビジネス要求をストーリーとして言語化するスキル不足が主になります。
ドメイン知識はあっても、「誰が・何を・なぜ」の形に落とし込む訓練を受けていなければ、「〇〇機能を作る」という一行で終わってしまいます。
受入基準側の「わからない」は、検証可能な条件として記述するスキルの不足です。
POがドメインに精通していても、それを第三者がテストできる形に変換することは別の能力であり、体系的に学ぶ機会はほとんどありません。あったら教えて欲しい。
結果として「ユーザーが使いやすいこと」「適切に処理されること」のような、検証しようのない受入基準が量産されます。
適切って何ですか、と聞くと空気が凍るやーつ。
3. 書かなくても回ってきた
マジでやめて欲しい。
過去に要件が曖昧なまま、受入基準がないまま開発して、それでもリリースできた経験があると、「別に細かく書かなくても大丈夫」という認識が定着するケースがあります。あった。あったんだよ。
実際には「大丈夫だった」のではなく、誰かが行間を読んで補完していただけだったり、途中のリファイメントで発覚したりします。
開発者がPOの意図を推測し、QAが経験則でテスト範囲を判断していたり、先回りでどうにかしているケースです。
その暗黙の貢献は可視化されにくいですし、「あの時は（どうにか）できたし」というマズイ成功体験が残ります。
そのためのリファイメント、そのためのスプリント計画です。
なぜ暴走は止まらないのか
上流がスキップされていることに、チームが気づかないわけはありません。
皆薄々わかっています。それでも止まらないんですよね。
手戻りのコストが残業で吸収されるから、メトリクス上は問題が見えないケースが一番ヤバい暴走だと私は思っています。
経験上、こういうことが起きています。
- 要件が曖昧なまま、受入基準がないままストーリーに着手する
- 開発者とQAがそれぞれ自分の解釈で作業を進める
- 設計～テスト段階で「仕様と違う」「いや、こういう意味だと思った」が発覚する
- 手戻りが発生する
- 残業して帳尻を合わせる
- スプリントは完了扱いになる
- ベロシティは維持される
そして、この認識ズレには2種類あります。
要件が曖昧なことによるズレ は、「そもそも何を作るべきか」のズレで要望からうまく汲み取れていない最悪の状態です。
作ったもの自体が的外れになるので、これはもう手戻りというより作り直しと言って良いんじゃないでしょうか。
受入基準がないことによるズレ は、「作ったものがDoneかどうか」のズレです。
機能としては存在しますが、エッジケースの考慮漏れや境界条件の認識違いが起きます。
大抵テストレビューか実施段階で「これも必要だったの？」が頻発します。
どちらのズレも、手戻りとして残業に吸収されます。
ベロシティが出ていますし、スプリントは回っています。
デリバリーも間に合っているので、メトリクスだけ見れば順調なチームに見えます。
しかし実態は、認識ズレによる手戻りを、現場の残業で塗りつぶしているだけです。
これが固定残業代とかあるともう最悪です。大抵そこを食いつぶしても会社が許してくれてるという誤認も相まって残業パーリナイ。
早く目を覚まして帰ってくれ。
そしてこの残業の負担は非対称に分配されます。
要件や受入基準を書く側ではなく、それを解釈して実装・検証する開発者とQAが帳尻合わせの残業を引き受けることが多いです。
しかしこれはPOが悪いという話ではなく、曖昧な上流成果物が後工程にコストを押し出す品質とチーム構造の問題ということを認知していただきたいです。
その先に何が起きるか
暴走が止まらないまま時間が経過すると、もう一段深刻な問題が現れます。
慢性的な残業は、人の認知リソースを削ります。
残業が常態化すると、集中力・注意力・判断力が低下します。
これは精神論ではなく、認知科学の領域で繰り返し確認されている事実です。
本来なら気づくはずの要件の矛盾、見落とすはずのないエッジケース、レビューで拾えるはずのバグ。
これらを見逃す確率が上がっていきます。
上流スキップ → 認識ズレ → 手戻り → 残業で吸収 → メトリクスに出ない → 誰も止めない → 慢性残業 → 認知リソース低下 → 見落とし増加 → 障害確率の上昇
最初の「上流スキップ」が、巡り巡って「障害」として返ってきます。
しかもその因果は長く、メトリクスに現れにくいため、障害の原因分析で「上流の仕様品質」にたどり着けることは稀です。
「実装ミス」「テスト漏れ」で片付けられ、根本原因はそのまま残り、障害対応で時間が削られます。
デスマーチループの構造だね。
明日からできる一線の引き方
ここまで構造の話をしてきました。
脱落していないなら、
「わかった。じゃあどうすればいいの？」
という声が聞こえる気がします。
全部を一度に変えることはできません。
ただしリファインメントの場に2つのチェックポイントを追加するだけで、暴走は構造的に止まり始めます。
チェック①：要件——「誰が・何を・なぜ」が書かれているか
ストーリーに「誰が」「何を」「なぜ」が明記されていなければ、Ready判定しません。
※ステータスをドラフトからto doにしない、スプリント計画に入れない等。今ならAIで阻止できるので人力じゃなくても良くなりました。
例
Before（曖昧な要件）：
商品のお気に入り機能を作る
After（明確な要件）：
リピート購入するユーザーが、
気になった商品をお気に入りリストに保存できるようにする。
再訪時に商品を探し直す手間を減らし、購入率の向上を狙う。
Beforeは「誰が使うのか」「なぜ必要なのか」が書かれていません。
Afterはそれが書かれているので、開発チームが「何のためにこれを作るのか」を共有できます。
なぜを共有できれば、実装上の判断に迷ったとき、目的に立ち返って自律的に意思決定できます。
想定アウトカムを書く場所もあれば完璧ですが、そこまで求めるとキリが無いので一旦忘れて大丈夫です。
チェック②：受入基準——「第三者がテストケースを書けるか」
受入基準が記載されていない、または検証不可能な記述しかないストーリーは、Ready判定しません。
例
Before（曖昧な受入基準）：
ユーザーがお気に入り機能を正常に使えること
After（検証可能な受入基準）：
- 商品詳細画面でお気に入りボタンを押すと、その商品がお気に入りリストに追加される
- お気に入りリストに追加済みの商品のお気に入りボタンを押すと、リストから削除される
- 未ログイン状態でお気に入りボタンを押すと、ログイン画面に遷移する
- お気に入りリストには最大100件まで保存でき、上限に達した場合は「最大100件に到達しています、削除してください」というエラーメッセージが表示される
Beforeは「正常に使える」の定義が人によって違います。
Afterは条件と期待結果が明記されているので、開発者は何を実装すればいいかわかりますし、QAは何をテストすればいいかわかります。
受入基準の粒度で迷ったら、「この文章だけを読んで、第三者がテストケースを書けるか？」 を基準にしてみてください。
書けないなら、まだまだ曖昧ということです。
ここに時間をかけられるほど、後工程は物凄く早くなります。AI時代ならば猶更です。
この2つが揃って初めて「Ready」
要件だけあっても、受入基準がなければ完成の判定ができません。
受入基準だけあっても、要件がなければ何のために作っているかがわかりません。
リファインメントの場で確認することは、たった2つです。
- 「このストーリー、誰が何をなぜやるか書いてありますか？」
- 「このストーリー、第三者がテストケース書けますか？」
どちらかにNoが出たら、スプリントに入れない、入れていたら外す。
これだけで良いです。
もしスプリントプランニングの場で要件の曖昧さや受入基準の不足に気づくなら、それはリファインメントが足りていないサインです。
※プランニングは「何をどう作るか」を計画する場であって、「何を作るか」を議論する場ではありません。
どうしても受入基準が書けない！！
抱えがちなのですが、POが泣きそうになっていたら是非困っていることとして声高に叫んでください。そのためのデイリースクラムです。
一人で完璧に書こうとするから詰まるのなら、チームメンバーを頼るべきです。
QAやエンジニアに「この機能、どうなってたらOKだと思う？」と是非 聞いてみてください。
※心配になって聞きにいく事もありますが、健全ではないので。
チーム全体として「どういう状態になったら壊れてる/実装できると判断するか」を日常的に考えているはずなので、その逆を言語化するだけで受入基準の種になります。
「受入基準が書けない？」「どう書けない？」「じゃあこういうのはどうだろう」
このコミュニケーションコストを支払う価値はあります。
だって誰も終盤に残業したくないですよね。
おわりに
アジリティが高いチームと暴走しているチームの違いは、リリース速度ではありません。
上流の品質確保——要件の明確化と受入基準の明文化——に、意図的に時間を投資しているかどうかだと私は思っています。
投資しなければ、短期的にはベロシティが出ますし、メトリクスも青信号です。
しかしそのコストは残業という形で現場に蓄積し、やがて認知リソースの低下を経て、障害として返ってきます。
そうなれば障害コストも視野に入れた計画を立てる必要が出てきます。不確実性の塊で誰も書けない計画を。
つまり暴走を放置すると、障害だけでなく見積もりの信頼性まで崩壊します。
要件は「誰が・何を・なぜ」が書かれていること。
受入基準は第三者がテストケースを書けること。
この2つが揃わないストーリーは着手しないとチームが宣言すれば良いのです。
完璧な要件も完璧な受入基準も、最初から書ける人はいません。
でも「書こうとする」だけで、チームの会話の質は変わりますので、是非チャレンジしてみてください。
品質を上流で作り込む為にも、
小さく作り、小さく伝播させ、小さな結果を求めてください。
千里の道も一歩から、私の好きな言葉です。