中途半端な出来栄えの機能の大量生産と偽りのベロシティによる悪循環
リリースすることや、実装することが目的化したアジャイルソフトウェア開発プロジェクトでは、ベロシティが歪みます。追い立てられるようにして次々と実装した不完全な状態の機能を「完成」として扱うためです。これらをスプリントやイテレーションの実績として数えると、チームの実力を実際以上に高く評価したベロシティが算出されてしまいます。
その結果、この歪んだベロシティに基づいて立てられる計画もまた、実力を超えた過大なものとなるでしょう。そして、再び中途半端な出来栄えの機能を量産するという悪循環に陥ることになります。
本記事では、スクラムチームを前提として、この問題について考えます。
中途半端な出来栄えの機能に見られる症状
「中途半端な出来栄えの機能」とは、以下のいずれか、あるいは複数の症状が見られる機能を指します。
仕様を満たしていても、「なにか違う」と感じる。デザインが適用され見栄えは良く、動作もするが、どこかぎこちなく、一つひとつの動作にモタつきを感じることもある。
設計・実装時に仕様のヌケモレを補完できておらず、細部への気遣いがない。想定外の操作や処理が少しでもあると、途端にユーザー体験を損なわせるような挙動を見せる。
仕様云々以前に、ちょっと触っただけで次から次へとバグが溢れ出てくる。それらがブロッカーとなって、テストが思うように進められない。
内部品質が酷い状況にあり、コードが、目先の判断の連続で高く積み上げられたジェンガのようになっている。今後の追加開発でコードに変更を加えることが恐怖でしかない。
同じ仕様に基づいて作られた機能であっても、取り組み方次第でその出来栄えは千差万別、優れたものにもなれば、残念なものにもなり得ます。同じレシピで作った料理が、人や状況、環境によって美味くも不味くもなるようなもの。その違いは、ひと目で明らかな場合もあれば、見た目では区別がつかないこともあります。また、肥えた舌を持ち合わせていなければ、気付くことさえできないかもしれません。
こういった機能をテストに回したり、スプリントレビューに持ち込んでも、それらの検証が持つ本来の目的が果たせるとは思えません。しかし、テストを経ることで、何とかバグは潰せます。また、スプリントレビューが形骸化していたなら、それらはいとも容易くリリース可能と判断されることになるでしょう。
その結果、中途半端な出来栄えの機能を作り上げた実績の統計が、チームのベロシティとして、以降のスプリントでも活用されることになります。
偽りのベロシティに陥るチームに見られる傾向
このようにして算出されたベロシティは、チームの実力を正確に反映しておらず、実際よりも過大な数値となります。本来やるべきことを十分に行わず（行えず）、その中途半端な実績を基にしているためです。これが本記事で述べる「偽りのベロシティ」です。一つひとつを正しく完成させていれば、実績はもっと小さくなっていたはずなのです。
偽りのベロシティに基づいて計画されたスプリントは、また中途半端にならざるを得ません。正しく完成させていては、時間が足りないからです。実力に比して過大なベロシティになっているのだから当然でしょう。品質と引き換えに数をさばいたのです。だから、次のスプリントも、その次のスプリントも、質より量を選ぶしかありません。
こうして同じことが延々と繰り返されます。何らかの理由で、1度でも偽りのベロシティに囚われてしまったチームは、そこからなかなか抜け出すことができなくなるのです。そのうえチームも組織も、その状態に陥っていることに気づいてさえいないかもしれません。
このような組織とスクラムチームのスプリントには、次の3つの傾向がみられます。
実装することに追われている
手動で行われるテストフェーズだけで品質を担保している
スプリントレビューに意味を感じていない
1. 実装することに追われている
偽りのベロシティに縛られたスクラムチームは、なによりも「機能を実装すること」を最優先します。実装して形にならなければ、ユーザー価値どころではありません。だから、内部品質は諦め、外部品質は最終テストに丸投げして、とにかく実装することにほとんどの時間を費やします。
このようなチームの特徴としてよく見られるのは、コードレビュー待ちが長いことです。コード実装を終えたアイテムを対象に、その実装結果の良し悪しを別の開発者がチェックする「コードレビュー」がなかなか実施されず、放置されてしまうのです。
開発者らの誰もが、「コードレビュー」に先行する「設計と実装」に多くの時間を割かざるを得ない状況にあるのだから、当然でしょう。コードレビューなど後回しです。とにかく実装を終わらせなければ話になりません。内部品質が多少悪くなることは目を瞑り、テストコードも書かず、外部品質は最終テストに丸投げします。
そうして設計と実装に時間をかけているうちに、コードレビューにかけられる時間的余裕を失ってしまいます。後回しにされ、積み上がったコードレビュータスクは、最後に実施されるものの、その内容は粗く、十分な効果は期待できません。これでは実質的に、開発プロセスが設計・実装とそれ以降とでフェーズ分けされているようなものです。
また同様に、実装者が、形になった機能を実際に触って検証してみる余裕もありません。簡単な動作確認程度なら実施するものの、細部にまで目の行き届いたものにはなりません。結果、仕上がりが不十分なものになってしまいます。
2. 手動で行われるテストフェーズだけで品質を担保している
実装することに追われた結果、品質保証は最終テストに一極集中します。実装時には、テストコードも書かれず、簡単な動作確認しか行われません。そのため、スプリントレビュー前に行われる最終テストでは、単体レベルのテストケースも含めた手動でのテストが行われます。当然ながら、テストケース数は膨大です。
チームによっては、スプリント終了後にテストを実施していることもあります。テストの規模が大き過ぎて、スプリント内で実施すると、実装時間を圧迫してしまうからです。だから、テスト実施自体はテスト担当者らに任せ、チームは次のスプリントを進めながら、バグ修正も平行して行うのです。
毎スプリントごとにリリースしないなら、リリース前にテストフェーズを設け、そこで本格的なテストをする組織もあるでしょう。
どちらにしても、スプリントレビューが始まるまでには、それぞれの実装が十分な品質に達していないかもしれません。
3. スプリントレビューに意味を感じていない
スプリントレビューは単なる儀式であり、プロダクトオーナーを始め、誰も意味を感じていません。だから、このスクラムイベントは、計画通りに実装が完了しているかどうかを確認するだけの淡白な場になっています。スプリントの成果についてじっくり精査し、議論するようなことはありません。そんな状況が続いたために、スプリントレビューの実施をやめたチームもあるでしょう。
さらに、リリース日が数スプリント先に置かれた時には、スプリントをまたいでアイテムを完成させるような計画を立てるチームもあるでしょう。スプリント内で開発するアイテムの単位が、レビュー可能なものである必要がないからです。
「正しく完成した」と言える状態を定義する
問題は、「正しく完成した」とはどういう状態を指すのか、チームにその統一基準が無いことです。基準がないなら、正しく完成させることを考慮した見積りが作られることもないでしょう。その見積りに基づいた計画もまた、正しく完成させるためのものにはなり得ません。
そこで用いる手法が次の3つです。
全アイテム共通の「完成の定義」
アイテム単位の「受け入れ基準」
スプリント毎の「スプリントゴール」
「完成の定義」は、PBI（プロダクトバックログアイテム）やSBI（スプリントバックログアイテム）が満たすべき品質の基準です。すべてのアイテム、すべてのスプリントで共通した定義として作成します。テストコードを書くことや、静的コード解析での品質基準を満たすこと、コードレビューを通すこと、コメントやドキュメントを書くことなどが定義例です。主に、開発者の視点での品質を盛り込みます。
「受け入れ基準」もアイテムが満たすべき品質基準ですが、PBIごとに定義する点が、「完成の定義」とは異なります。実装された機能が、ユーザーストーリーを満たしたと言えるのはどういうことであるかを記述したものです。たとえば、その機能をユーザーがどのように使うのか、その例をいくつか示すというように、プロダクトオーナーやユーザーの観点で作成します。受け入れ基準があらかじめ定義されることで、開発者は、何を作るべきかを正しく把握することができるようにもなります。
「スプリントゴール」はそのスプリントの目的を言語化したものです。これをwhy（なぜ）とすると、各アイテムはwhat（何を）であり、計画はhow（どのように）にあたります。スプリント計画に従ってアイテムを作り上げることは、スプリントゴールという目的を果たすための手段だということです。すなわち、スプリントレビューでは、これら手段を実行したことで、目的であるスプリントゴールに至ることができたのかを確認することになります。言い換えれば、スプリントレビューで何を確認したいのか、それをスプリント計画時にあらかじめ決めるのです。
その先にはさらに、スプリントをまたいだプロジェクト単位でのゴールやプロダクトゴールもあると良いでしょう。スプリントゴールは、そこを目指すための中間ゴールのようなものです。
フローに集中する
「正しく完成した」と言える状態を定義しても、フローに集中しなければ、それらの定義は形骸化するかもしれません。
ここで言う「フロー」とは、ひとつのアイテムに関する、スプリント内での開発着手から完成までの流れです。完成とは、完成の定義と受け入れ基準を満たした状態を指しています。いったんフローが開始したら、その進捗を止めることなく、そのアイテムだけに集中して完成に至らせようということです。
最優先するのは、仕掛中のアイテムを完成させることです。次々と実装だけを終わらせていくことではありません。そんなことをすれば、実装だけが終わった未完成のアイテムの山ができてしまいます。計画したすべてのアイテムの実装が終わり、いざ仕上げようとした時には、既にそのための時間は十分には残されていないでしょう。
フローに集中しなければ、多くのアイテムが未完成のままでスプリントを終えることになります。それらはいずれも、完成の定義も受け入れ基準も満たせず、スプリントレビューの対象にする価値もないアイテムとなってしまうのです。
こうして品質を顧みず、目的を見失ったスクラムには意味がありません。
ベロシティは下がるかもしれないが、それで構わない
「正しく完成した」と言える状態を定義し、フローに集中することができるようになると、おそらくチームのベロシティが下がります。以前と同じ数のアイテムをスプリント内でこなそうとしても、捌ききれなくなるのです。一つひとつのアイテムを完成させている間に時間が経過し、未着手のアイテムが残されるからです。
しかし、それで良いのです。スプリントレビューの対象とするに値する機能を完成させられているからです。そしてスプリントレビューが通ったインクリメントは、ようやくその価値をユーザーに問える状態に至ります。中途半端なものをリリースしたところで、そこから得られるフィードバックに意味はありません。検証する価値がないのです。
ここで注意しておきたいのは、スプリント計画に含めたアイテムの「取り組み順序」を決めておくことです。スプリントゴールに必須のアイテムを、時間切れで未着手のまま終わらせるわけにはいきません。だから、スプリントゴールと照らし合わせて、必須のアイテムや優先度の高いアイテムほど先に着手するよう、計画を立てるのです。
真のベロシティ
こうして積み上げた実績に基づいて算出されるベロシティこそ、チームの真のベロシティです。このベロシティを用いることで、正しく完成させることが可能な計画を立てることができ、また、プロジェクトの予測可能性も高まります。