「スクラム＝会議が多くて非効率」は誤解？ベロシティとアジリティの違いから考察するスクラムの本質

はじめに 

こんにちは！
メンバーズでスクラムマスターをしている小島です。

「スクラム、会議ばかりで非効率じゃない？」

皆さんはそう感じたことはありますか？スクラムマスターとして活動する中で、私も時々そのようなご意見を耳にします。

ですが、これって本当にそうなのでしょうか？

この記事では「スクラムは会議が多くて非効率？」という疑問ついて深堀りし、その発言の背景にある原因や対処の仕方について考察してみました。

特に以下のような方におすすめです：

• スクラムを導入したものの、その効果に疑問を感じている現場メンバー
• イベント（会議）の多さに対して「これって本当に必要？」と感じている開発メンバー
• 改善サイクルの意図や目的を、もう一度チームで見直したいと考えているリーダー層

速さには「ベロシティ」と「アジリティ」の２種類がある

この問いを考える上で、まずプロダクト開発における「速さ」をどう定義するかが重要です。端的に言うと、速さには「ベロシティ」と「アジリティ」の2種類があると私は考えています。

ベロシティ

「ベロシティ」は英語で「速度」や「速さ」を意味する言葉ですが、スクラムの文脈では「開発チームがスプリントで完了できる作業量の平均値を示す指標」として扱われます。通常、ストーリーポイント（作業の相対的な見積もり単位）の合計で表され、将来のスプリント計画やチームにおける生産性の予測に活用されます。

プロダクト開発において「速さ」という言葉が使われるとき、多くの場合それはベロシティを指しているように思います。「スクラムは会議が多くて非効率」と感じている人の多くは、ベロシティ（開発速度）が思うように上がらないことに不満を持っているのかもしれません。

わかりやすくするために図にしてみました。

以下のように現在地とゴールがあったとき、ベロシティは横軸の矢印に対応します。

達成すべきゴールが明確で、技術的な懸念も少ないような不確実性の低い状況においては、ベロシティをできるだけ向上させて、当初立てたゴールを迅速に達成することが求められます。

アジリティ

実は速さにはもう一つ重要な要素があります。それが「アジリティ」です。アジリティとは、単に速く走るだけでなく、素早く方向転換したり、加速・減速したり、状況に応じて体の動きを正確にコントロールする能力を指します。

先ほどの図でいうと縦軸の矢印に対応します。（厳密には現在地を基点とした円運動の速度な気がしますが、あくまでイメージとして考えてもらえると...🙏）

不確実性の高い状況では、最初に立てた計画通りに開発が進むことは稀です。そのため、アジリティを高め、頻繁に変化する状況に合わせて計画を柔軟に修正していくことが求められます。

スクラムは「アジリティ」を高めるためのフレームワーク

スクラムは先ほどの図で言うと縦軸の矢印、つまり「アジリティ」を高めることを意図したフレームワークです。スクラムガイドの「適応型のソリューション」という記述からもそのように解釈することができます。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。

[スクラムガイド2020より]

具体的には、以下のような取り組みを通じて、チームが立ち止まって考える機会を定期的に設けることで、アジリティの向上を図っています。

• 毎日15分のタイムボックスで実施されるデイリースクラム
• スプリントの最後に実施されるスプリントレビュー、スプリントレトロスペクティブ
• (イベントではないですが)チームを小規模にすることでメンバー同士の頻繁な対話を生み出す etc...

誤解のないように補足しておくと、スクラムだとベロシティ向上が見込めないという訳ではありません。むしろ、頻繁に改善を繰り返すことで結果的にベロシティは向上していくはずです。

重要なのはスクラムはベロシティ向上だけを目的としている訳ではないという点です。スクラムが想定しているような高不確実性の状況においてベロシティ向上だけを追い求めてしまうと、例えば「最初に計画したプロダクトは完成したけど、ユーザーはあまり求めてなかった...」みたいな状況に陥るリスクがあります。

ベロシティ向上は勿論重要ですが、併せてアジリティも向上させていくことで本質的な価値を生み出していこうというのがスクラムの考え方だと考えています。

「スクラムは会議が多くて非効率」と思ってしまう理由

なぜ「スクラムは会議が多くて非効率」という声があがるのでしょうか？私自身の過去の経験などから考察してみました。

チームが向き合っている問題の不確実性が低い

真っ先に考えられるのは、チームが対峙する問題がそれほど複雑ではないのにスクラムのプロセスを堅持しようとしている状況です。

例えば100m走で10mごとに立ち止まって「走る向きはこの方角で合ってるんだろうか...🤔」と考えている人がいたら「いや、いいから早く走りなさいよ！！！」って思いますよね。なぜなら100m走には「100m先にできるだけ早く到達する」という明確なゴールがあるからです。

プロダクト開発も同様です。作るもの、作る方法が誰の目にも明らかであれば敢えて頻繁に立ち止まる必要はありません。そのような状況において「スクラムは会議が多くて非効率な〜」と思ったのであれば、スプリント期間を伸ばしたり、スクラムイベントの頻度を下げるようなプロセスチューニングは個人的にはありだと思ってます。

スクラムイベント以外で作業時間を圧迫する予定が多い

他のパターンとして考えられるのは、スクラムイベント以外で作業時間を圧迫するものが多い状況です。

次の図は、1週間のスプリントを前提に、スクラムガイドに沿ってイベントを実施した場合のスケジュール例です。

こうしてみると意外と作業時間に余裕があるように感じられるのではないでしょうか。

理想

会議・タスク・他業務が重なる現実

しかし、実際は臨時MTGや差し込みタスク、別プロジェクトとの兼任などによってスクラムイベント以外の予定が発生することはよくあります。これが常態化してしまうと上の図のようなスケジュールになります。スイッチングコストなどの影響を考慮すると、これでは「スクラムって会議が多くて作業時間がないな〜...」と感じてもしょうがないかもしれません。

この状況における問題は、イベント以外の要因で作業時間が圧迫されているにも関わらず「スクラムだから遅い」のように状況を単純化して問題を覆い隠してしまうことです。そうならないための仕掛けとしてレトロスペクティブのような一旦立ち止まって問題を整理しやり方を変える機会をスクラムは提供しています。作業時間を圧迫している真因を突き止め、一つ一つ対処していくことで状況は好転していくかもしれません。

さいごに

ある著名なアジャイルコーチが「スクラムが上手くいってないなら上手くいってる」というブログを書かれていました。スクラムの狙いを端的に言語化していてとても印象に残っています。

スクラムはチームや組織の問題を検出し、明らかにする仕組みだ。みんなが問題を意識できているなら、上手くいっているわけだ。「うちは〇〇だから、スクラムが難しい」と思ったなら、その〇〇を解消できれば仕事がもっと上手くいき、よりよい成果が作れる。

「スクラムは会議が多くて非効率」と思ったら、それは今のチームに問題が潜んでいるということかもしれません。

その際にこの記事が改善の一助になれば幸いです！