カンバンとスクラム
アジャイルの実践方法として取り上げられる、カンバンとスクラム。
現在私が所属しているチームでは、これまでカンバン形式でプロジェクト管理をしていたのですが、次第にチーム内外での要求が変化し、スクラムを参考にイテレーティブな開発を導入し始めました。
その中で、チームの中にはスクラム未経験のメンバーもいたため、これまでのカンバン形式と、参考にしようとしているスクラムがどのような関係性にあるのかチームにシェアしました。本記事では、その時話した内容をまとめます。
注意点として、この記事では「カンバンからスクラムへ移行しよう」「カンバンよりスクラムの方が良い」といった主張をしているわけでは決してありません。むしろスクラムを実践することの難しさについても書いております。
なおカンバンとスクラムの違いについては実は既に様々な記事があり、体系的な話はそれらを参考にしてください。
アジャイル開発を実現するためのカンバンとスクラム
まず、カンバンもスクラムも、アジャイル開発を実現するための手段の一つです。
アジャイル開発とは、簡単に言えば、 小さな動くソフトウェアを短い周期(イテレーション)でつくり、顧客やユーザーのフィードバックを得ながら改良していくことで、不確実な状況の中で価値あるサービスを届ける開発手法です。
その中でもカンバンは、アジャイル開発をする上で、タスクの優先度や各タスクの進捗をカンバンボードに可視化して透明性を出すことでプロセスを改善していくツールやスタイルのことを指します。
画像引用：かんばんとスクラムの違いとは？
一方でスクラムは、アジャイル開発をする上で、メンバーの役割やイテレーション(スプリント)中のイベント、各メンバーに求められる心構えなどを明確に定義したフレームワークです。
画像引用：アジャイル開発とは（中編）
そしてスプリントごとにバックログ（スプリントバックログ）を作り、そのスプリントバックログの進捗管理のためにカンバンを用いることができます。
改めてカンバンとスクラム
つまり、カンバンもスクラムも、アジャイル開発を実現するための手段の一つで、目指すものは一緒です。そしてカンバンとスクラムは全く異なるものではなく、組み合わせることができます。
次に、もう少し細かい単位でカンバンとスクラムを比較し、運用面でどういった違いがあるのか解像度を上げていきます。
メンバーの役割
カンバン：特に決まりは無い
スクラム：
・プロダクトオーナー：「何を、なぜ、どんな順番で」に集中
・ 開発者: 「いつ、どうやって」に集中
・スクラムマスター: プロダクトオーナーと開発者の支援に集中
イテレーション
カンバン：特に無い、できた順にリリースする
スクラム：1~数週間の固定されたイテレーション(スプリント)
タスク(プロダクトバックログアイテム)のサイズ
カンバン：特に決まりは無し
スクラム：スプリントにおさまるサイズ
差し込み対応
カンバン：都度優先度に応じて対応
スクラム：スプリントゴールに集中するためスプリント中の差し込みは原則受け入れない
イベント
カンバン：特に決まりは無し
スクラム：4つのイベントが定義
・スプリントプランニング：スプリントゴールとそれを実現するための計画
・デイリースクラム: 日々の状況に透明性を出し、スプリントゴール達成のための障害の検知と適応
・スプリントレビュー: スプリントの成果物が関係者の期待とあっているか確認
・スプリントレトロスペクティブ: スプリント中の人間関係やプロセスの改善
チームメンバーに求められる価値基準
カンバン：特に無し
スクラム：5つの価値基準 (確約、集中、公開、尊敬、勇気)
スクラムの難しさ(スクラムへの移行で起こること)
このように、スクラムはカンバンに比べて、役割やイベントが明確に定義され、それぞれの役割に集中し、またプロダクトゴールとスプリントゴールに集中して日々動きます。つまりカンバンに比べて従うべき制約が多く、かつ常にチームとして同じ方向を向くような仕組みになっているからこそ、カンバンの時には経験しなかったかもしれない困難にぶつかることがあります。
スクラムについての理解
まず、スクラムの4つのイベントや各種役割がそれぞれ何のためにあるのか、といったようなスクラムに対する知識・理解が大切になってきます。最初はとりあえず従うだけでも良いかもしれませんが、自分たちで改善していくにあたって、この辺りの理解はとても大切です。
一人一人の主体性と建設的な議論
カンバンの時には特定の期間を設けないですが、スクラムを導入すると、固定された期間の中で各期間のゴール(スプリントゴール)に向けてチームとして進んでいくため、「何でこのゴールを達成できなかったのか/あるいは達成できたのか」といった議論が自然と発生します。これがスクラムの強力なところではあるのですが、逆に言えば、未成熟なチーム（あるいはグループ）の場合、この議論がなかなか難しい。まず先ほどお伝えしたようなスクラムについての理解が浅いと、そもそも全体像が見えてないので、どう改善したら良いかも見えづらい。全体像が見えていたとしても、お互いに率直な意見を言い合う主体性がないと、なかなか建設的な議論にならず、いつまでも改善できない。お互いに率直な意見を言いっても、そこに信頼関係がなければ衝突が生まれ、「自分たちにはスクラムは合わない」と思いたくなる可能性もある。つまり、一人一人の主体性や、タックマンモデルに代表されるようなチーム形成の理論を理解しているメンバーがいないと、なかなか建設的な議論をしチームとして成熟していくことが難しく、次第にスプリントゴールをチームとして目指すのが辛くなってしまうことも。
画像引用：仕事ができる人は｢正しい衝突｣が超得意！
スクラムの実践が難しい
スクラムではいくつかルールがあるものの、そのルールを満たして価値を生み出すための実践方法は、チームに委ねられています。それは、組織やチーム、作るサービスなどによって最適な方法が異なるからなのですが、先ほどお伝えしたように、自分たちで最適な方法を経験主義的に見つけていくのは、チームの成長も絡んでおり、なかなか簡単にはいきません。例えば、プロダクトバックログアイテムはスプリントにおさまるサイズにするのが良いのですが、その理由や具体的な方法を考えたり、もしスプリントに収まらなかった場合どうするのか、などスクラムのルールに従うための具体的なノウハウを自分たちで見つけるのが結構難しい。実際はこの辺りはスクラムマスターが貢献する箇所ですが、スクラムマスターに頼りきりにするのではなく、チームメンバー一人一人が、確約、集中、公開、尊敬、勇気の価値基準を持って、誰かに従うのではなく自分たちで答えを見つけていく心構えが大切だと考えています。
自分たちに合ったやり方を模索する
ここまで、カンバンとスクラムの違いと、これまでカンバンで運用していたチームがスクラムを導入するときの困難について説明しました。ここで断っておくことは、カンバンorスクラムのような二項対立の考え方ではなく、自分たちのチームが目指す方向と、現状ある課題を自分たちで分析し、そこに対する処方をカンバンやスクラムの考え方から必要に応じて部分的に真似することが大切だと思います。もちろん、まずは形から入るということでスクラムに従うのも問題ないですが、盲目的に従うのではなく、「なんでスクラムを導入したいんだっけ？」というのを考えながら自分たちに合うようにカスタマイズしていくことが大事だと思います。
この記事が気に入ったらサポートをしてみませんか？