Scrumban: ScrumとKanbanを組み合わせる手法

Scrumbanは、ScrumかKanbanかという二者択一を無理にやめたときに生まれる手法です。計画された構造は必要だけれど、厳格なスプリントを組む余裕はない、というチームがまず手を伸ばすのがScrumbanです。

Scrumbanとは

Scrumbanは、Scrumの計画の規律の上に、Kanbanの継続的なフロー管理を重ねたハイブリッドなアジャイルフレームワークです。作業は仕掛かり中(WIP)の上限を設けたプル型のボード上を進みますが、計画イベントは固定のスプリント周期ではなく、必要に応じて発生します。

Corey Ladas氏が2008年のエッセイでこの用語を作り、その後著書『Scrumban: Essays on Kanban Systems for Lean Software Development』でこの考えをさらに発展させました。彼の核心的な主張はこうです。Scrumはアジャイルに不慣れなチームにとって良い足場になるが、チームが成熟するにつれて、価値を生まない儀式は取り除き、価値のある儀式だけを残すべきだ、というものです。そのすき間を埋めるのがKanbanのフローモデルです。その結果、保守作業、サポートのキュー、マーケティングオペレーションなど、2週間のスプリントにきれいに当てはまらない業務にも柔軟に対応できるフレームワークになります。

重要なポイント

• 第17回State of Agile Report(2023年)によると、回答者の9%がScrum/Kanbanのハイブリッドを主な開発手法として採用しており、2年前の6%から増加しています。
• Donald Reinertsen氏の著書『Principles of Product Development Flow』(2009年)で引用されているフロー改善のデータによれば、プル型システムとともにWIP制限を導入したチームは、通常サイクルタイムが20~40%短縮されます。
• Scrumbanは計画イベント自体は残しつつ、そのトリガーをカレンダーではなくキューのサイズにしているため、計画にかける労力を実際の作業量に見合ったものにできます。

Scrum、Kanban、Scrumbanの比較

この3つのフレームワークはボードとバックログを共有していますが、リズム、役割、作業がシステムに入ってくる方法という点では大きく異なります。

すでにScrumを回しているものの、緊急対応のためにスプリントのルールを何度も曲げているようなら、すでにScrumbanの半分は実現できているようなものです。逆にKanbanを回しているものの、振り返りや計画のために立ち止まる機会がまったくないなら、Scrumbanの「必要なときだけ構造化する」モデルが、立ち止まる理由を与えてくれます。

Scrumbanの仕組み

Scrumbanの仕組みは、4つの相互に関連するアイデアの上に成り立っています。

プルシステム。 作業はエンジニアに押し付けられるのではなく、引っ張られる形で流れます。誰かがタスクを終えると、レディキューから次の項目を自分の列に引き込みます。これにより、作業が特定の人のレーンに積み上がることを防ぎ、ボトルネックがすぐに見えるようになります。

WIP制限。 ボードの各列には上限数が設定されます。例えば「作業中」列は一度に3枚までしかカードを持てない、といった具合です。列が満杯になると、チームは新しいことに手を出す前に、今ある作業を終わらせることに集中します。WIP制限は、Kanban系のあらゆるシステムにおいて、サイクルタイムを短縮するための最も強力なレバーです。

レディキュー。 バックログと実際の作業列の間には、レディキューと呼ばれる、精査され優先順位付けされた、本当にすぐ着手できる項目の小さなバッファが置かれます。レディキューは計画と実行を切り離します。計画は集中した短い時間で行い、その後チームは計画担当者が同席していなくても自由にキューから引き出すことができます。

必要に応じた計画トリガー。 状況にかかわらず2週間ごとに計画を行うのではなく、Scrumbanではレディキューが、例えば開発者1人あたり2項目といった設定したしきい値を下回った時点で計画イベントが発生します。つまり、計画にかける労力が実際の必要性に応じて変動するということです。落ち着いた週は軽い補充だけで済み、忙しい週はそもそも計画が不要になることもあります。

累積フロー図は、キューのサイズ、WIP、スループットを一つの図で可視化できるため、Scrumbanにとって自然な追跡ツールです。帯が広がり始めたら、作業が完了するペースよりも溜まるペースの方が速いということです。

Scrumbanのメリット

混乱のないフロー。 Kanbanの継続的なフローモデルは作業を止まらせません。Scrumbanはそこに、バックログが手つかずのチケットの墓場と化すのを防ぐための、最低限の構造を加えます。

自分たちのペースでの計画。 実質2時間分の意思決定のために丸1日かかるスプリント計画の儀式に苦労してきたチームなら、その違いをすぐに実感できるはずです。計画は、カレンダーがそう言っているからではなく、キューの補充が必要なときに行われます。

安定したチームにとっての運用負荷の軽減。 チームが自分たちのやるべきことを理解してくると、立ち上げ期には意味があったScrumの儀式が、次第に無駄に感じられてきます。Scrumbanなら、役に立たないものを手放し、役に立つものだけを残すことができます。

混在する作業タイプへの対応。 ほとんどの実際のチームは、計画された作業(新機能、プロジェクト)と、計画外の作業(バグ、依頼、インシデント)の両方を抱えています。Scrumはスプリントを乱してしまうため、計画外の作業をうまく扱えません。一方Scrumbanは、通常の精査サイクルの外でも、いつでもレディキューに新しい項目を引き込む余地がボードにあるため、こうした作業を吸収できます。

可視性。 ボードは常にリアルタイムで更新されます。誰でも、何が進行中で、何がブロックされていて、レディキューが計画をトリガーするまでどれくらい近づいているかを確認できます。システムの状態を知るためにスプリントレビューを待つ必要はありません。

Scrumbanの弱点

Scrumbanは万能薬ではありません。それ自体が独自の失敗パターンを生み出すこともあります。

役割がないということは、説明責任もないということ。 Scrumに定義された役割が存在するのは、誰かがバックログを所有し、誰かがファシリテートし、誰かがチームをスコープクリープから守る必要があるからです。Scrumbanはデフォルトでこれらの役割を持ちません。この構造を省いてしまったチームは、しばしば精査されていないバックログ、誰も準備してこない計画会議、誰も更新しないボードという結末を迎えます。

WIP制限には規律が必要。 マネージャーが「あと一つだけ追加してほしい」と頼んだ瞬間、WIP制限はこっそり引き上げられがちです。一度制限が単なる目安になってしまうと、フローの仕組み全体が崩れます。ScrumbanはチームがWIP制限を絶対的な制約として扱ってこそ機能します。

大規模で複雑な探索的作業には不向き。 本当に未知のものを構築しているのであれば、Scrumのスプリントのリズムこそが、探索的な作業に必要な振り返りと計画を強制してくれます。Scrumbanの必要に応じた計画は、正しいものを作っているかを立ち止まって問い直すことなく、長く突き進んでしまう可能性があります。

ベロシティの測定が難しい。 固定のスプリントがないため、従来のアジャイルにおけるベロシティの指標はそのまま適用できません。チームは代わりにスループット(週あたりの完了項目数)とサイクルタイムに切り替えます。多くの場合これはより優れた指標ですが、発想の転換が必要です。

Scrumbanの導入方法

ステップ1: 今のボードから始める

すべてを一度に作り直そうとしないでください。ScrumからでもKanbanからでも、既存の列とカードのフォーマットはそのまま残しましょう。最初の変化は目に見えないものです。作業を人に割り振る「プッシュ」の発想から、準備ができた人がキューから引き出す「プル」の発想へと移すことです。

ステップ2: 進行中の列にWIP制限を設定する

各進行中の列に、控えめな数値を設定します。目安はチームメンバー1人あたり1_{2件です。1}2週間後に調整すればよいので、完璧な数値を最初から選ぶ必要はありません。目的は数値を的中させることではなく、フローの問題を見える化することです。

ステップ3: レディキューを作る

バックログと最初の進行中列の間に「レディ」列を追加します。項目は、内容が定義され、見積もりが済み、本当にすぐ着手できる状態、つまり精査が終わったときにのみレディに移動します。これがあなたの計画の成果物です。チームは計画担当者が同席していなくても、自由にレディから引き出せます。

ステップ4: 計画トリガーのしきい値を設定する

計画セッションを実行する前に、レディキューがどこまで少なくなってよいかを決めます。よくある出発点は、レディが2日分の供給量を下回ったら計画を行う、というものです。これを明文化しましょう。トリガーは「なんとなく少なく感じたら」ではなく、具体的な数値であるべきです。

ステップ5: 軽量な振り返りを行う

固定のスプリントがなくても、チームは立ち止まって、うまくいっていることは何かを問う必要があります。2_{4週間ごと、あるいは決まった件数の項目をリリースするごとに、短い振り返りを予定しましょう。時間は30}45分程度に抑え、フローに焦点を当てます。何が私たちを遅くしたか、何が助けになったか、次に変えるべき一つのことは何か、といった問いです。

数サイクルを経ると、実際のスループットデータが手に入ります。それを使ってWIP制限を調整し、計画トリガーを見直し、ボード上で最も速く進む作業の種類を見極めましょう。これがアジャイル手法の中核にある継続的改善のループです。

チームタイプ別のScrumban事例

ベストプラクティス

ボードを正直に保つ。 カードのステータスは、スタンドアップの時でも1日の終わりでもなく、変化した瞬間に更新しましょう。古びたボードは、誤った安心感を生むという意味で、ボードがない状態よりも悪いものです。

WIP制限をチームの契約として扱う。 全員で合意し、ボードに書き出し、互いにそれを守り合いましょう。誰かが制限を超えたいと思ったときは、一方的な決定ではなく、話し合いの場を設けるべきです。

緊急対応と計画済みの作業を分ける。 本当の緊急事態のために、ボードに小さな「ファストレーン」の行を追加しましょう。同時に1件までに制限します。これにより、メインのフローを崩すことなく、インシデントに対応する道筋を用意できます。

ブロックされた作業を可視化する。 ブロックされたカードは、単に進行中に放置するのではなく、フラグや色タグを使いましょう。WIP制限の中で静かにブロックされたままの作業は、目に見えないムダです。

ベロシティではなくサイクルタイムを測定する。 項目がReadyから完了に至るまでにかかった時間を追跡しましょう。サイクルタイムは、あなたの開発の予測可能性を示します。これを改善することこそが、プルシステムの主な目的です。

定期的に**ScrumとはとKanbanとはに立ち返りましょう。** Scrumbanは両者から要素を借りているため、うまくいかないことがあれば、元の原則に立ち返ることが役立ちます。多くの場合、答えはすでにそこにあります。

チームがスケーリングのためのより広範なフレームワークを検討しているなら、スケールドアジャイルフレームワーク(SAFe)がポートフォリオレベルで同様の緊張関係に対応しています。また、Scrumbanよりもさらに儀式を減らしたいチームには、エクストリームプログラミング(XP)という別の方向性もあります。エンジニアリングの実践を重視し、プロセスの足場を減らすアプローチです。

よくある質問

Scrumbanにスプリントはありますか?

デフォルトではありません。Scrumbanは固定のスプリントを、キューのサイズによって発生する必要に応じた計画に置き換えています。とはいえ、フロー管理を日々の作業に使いながら、強制力として緩やかな2週間の計画リズムを維持するチームもあります。このフレームワークは、チームの役に立つのであれば、スプリントを組み込むことも十分できる柔軟性を持っています。

Scrumbanに定義された役割はありますか?

ありません。Scrumbanは、Scrumが必要とするProduct Owner、Scrum Master、開発チームといった役割を持ちません。バックログを誰が所有するか、誰が計画をファシリテートするか、誰がボードを維持するかは、チーム自身が決めます。とはいえ、優先順位付けは誰かがやらなければならないため、軽いプロダクトオーナー的な役割を残すチームは多くあります。ただし、フレームワークとしてそれを義務付けてはいません。

Scrumbanは保守チームに向いていますか?

最も相性の良いケースの一つです。保守作業は予測不能で、規模もまちまちであり、スプリント計画のサイクルにうまく当てはまりません。プルシステムと必要に応じた計画により、保守チームはスプリントの区切りに対してスコープの交渉を常に強いられることなく、発生した作業に対応できます。

Scrumbanは単なる「Kanbanを実践すること」とどう違うのですか?

主な違いは構造です。純粋なKanbanには、義務的な儀式も、計画のトリガーも、組み込みの振り返りループもありません。Scrumbanはそこに、レディキュー、計画トリガーのしきい値、任意の振り返りを加えます。純粋なフローだけでは偶然に任せる部分が多すぎると感じたチームのための、ガードレール付きのKanbanと言えます。

Scrumbanチームはどのような指標を追跡すべきですか?

サイクルタイム(Readyから完了までの時間)、スループット(週あたりの完了項目数)、キューサイズの3つが中核となる指標です。累積フロー図はこの3つを一つの図にまとめて表示し、ボトルネックを一目瞭然にします。ベロシティはスプリントを前提とした指標なので、スプリントを導入していない限り追跡は避けましょう。

Scrumbanは、チームがScrumの儀式とKanbanのフローツールの新たな組み合わせを見つけるたびに、進化を続けています。このフレームワークが根強く支持される理由は、シンプルな発想にあります。プロセスを実際の作業に最適化するのであって、その逆ではない、ということです。まずは今のボードから始め、WIP制限を加え、その制約が何を明らかにするかを見てみましょう。

関連記事

• Scrumとは
• Kanbanとは
• ScrumとKanbanの違い
• WIP制限
• 累積フロー図
• スプリント計画
• アジャイルにおけるベロシティ
• アジャイル手法とは
• エクストリームプログラミング
• スケールドアジャイルフレームワーク(SAFe)