タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。
大前提
まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。
- 市場が求めるものが変わる
- ミドルウェアやライブラリのインターフェースが変わる
- システムに適した言語や設計が変わる
- トラフィック量や傾向が変わる
- システムのリソース使用の傾向が変わる
- メンバーが変わる
- 普段とシステムの触るところが変わる
こうした具合に、日々その場に立っていることすらままらない激流が開発チームを襲います。この力をあの手この手で受け流しプロダクトを成長させることこそ、「変化への適応」というキーワードで語られるアジャイルムーブメントの重要な価値観のひとつでしょう。
ベロシティを安定させる
上の前提に立ったとき、ベロシティを安定させることは決して容易な目標ではありません。この目標を達成するには、計画やふりかえり、障害物の排除が高いレベルで機能している必要があります。それらの成熟度が低いと、見積りを大外しして計画がめちゃくちゃになったり、差し込みや障害に忙殺されたりして、少なからず重要な仕事をうまく達成できないタイミングが出てくることでしょう。
ベロシティが安定しているのは、字面から受ける保守的なイメージよりもかなり価値が高い状態です。アジャイル宣言の背後にある原則の中でも「アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。」と述べられており、非常に普遍的な価値であることがわかります。毎スプリント終わると言ったことが確実に終わり、その予想を積み重ねて大きな計画を精度高く予測できることは、POやステークホルダから見て非常に嬉しいことです。またベロシティが安定しているということは、開発チームが変化に押し潰されていないということで、ある程度の達成感や自己効力感を継続的に得られることが期待されます。
こうした議論から、多くの現場にとってベロシティを安定させることは十分に高い目標であり、最初に目指すのに適した目標だと言えるでしょう。スクラムコーチの中でベロシティを「安定させる」ほうを積極的に提示する人は、こうした堅実な考え方をしているのではないかと予想します。
ベロシティを上げる
当然、価値のデリバリーは早いに越したことはないので、ベロシティだって上がるのなら上げたいものです。ベロシティを上げることを考えるとき、ふたつ重要なポイントがあると考えます。ひとつはベロシティをハックしないこと。見積りをいじったり、完了条件を緩めたりしてベロシティを上げても意味がありません。もうひとつのポイントは持続可能であること。開発チームが無理な残業をしたり、その場しのぎの実装ばかりしていては、上がったベロシティも長続きはしません。
こうしたポイントを開発チームで守っていくことを考えたとき、ベロシティを「安定させる」という前提は非常に都合が良いと感じます。見積もりや完了条件といったバックログアイテムの取り回しに関することを一貫して行い、一定のペースで働き、システムを健全な状態に保つ……こうした望ましい行動が自然と導かれます。自分が又聞きした研修でも、「幸福度や品質を毀損しない前提で」といった前置きがあったようで、かなり近いことが言われているように思います。
こうした議論から、ベロシティを「上げる」のは、ベロシティを「安定させる」レベルをクリアしたチームが目指す次の目標であり、二者は対立するものではないと考えます。ベロシティを「上げる」ほうを積極的に提示するスクラムコーチは、レベルの高い現場に精通し、高い目標を設定することを好んでいるのではないでしょうか。多くの普通の現場においても、短期的な目標として「安定させる」ことを置き、長期的なストレッチ目標として「上げる」ことを置くと、だいぶ筋が通るように思います。
