
Agile and Scrum: Understanding the Differences
Explore the differences between agile and scrum.
アジャイル実践者の多くは、知らず知らずのうちにカンバンとスクラムの両方の要素をすでに利用しています。デイリースタンドアップ(デイリースクラム)を実施し、さらに仮想または物理的なボードで作業を追跡している場合、カンバンとスクラムの両方の概念を利用していることになります。この方式は「スクラムバン」とも呼ばれます。
カンバンの要素とスクラムの要素のどちらを重視すべきかという議論が頻繁に生じるのには、作業の性質やチームが望むプロセス構造の数が関係しています。しっかりとした構造や定義を求めるアジャイル チームでは、スクラムの指針が役立ちます。一方、柔軟性、実験、分析を必要とするアジャイルチームでは、カンバンを重視するほうが多くのメリットを得られます。
では、これら2つの概念の詳細を確認し、どちらをどう使用すべきかを見ていきましょう。
自動車製造に端を発したカンバンですが、現在はソフトウェア開発でもその原理が幅広く利用されています。ただ、カンバンはフレームワークや手法ではありません。プロセスにおける価値のフローを最適化するための戦略です。カンバンではロールやイベント、成果物を定義しないため、アジャイルチームの業務や目標に応じてより柔軟な意思決定をすることができます。
David J. Anderson氏は、2010年に執筆した『Kanban: Successful Evolutionary Change for Your Technology Business』という著書の中で、カンバンを成功させる6つの重要なプラクティスを定義しています。
「カンバン方式」といえば、次々やってくるチケットの優先順位の変更に追われるサポートチームを管理するためのものだというイメージが強いかもしれません。しかし、成熟したデジタル製品チームの開発スピード向上にも非常に有効なのです。柔軟性、コラボレーション、メトリックを重視する点はローコード 開発と共通しており、親和性があります。
スクラムは、複雑な製品の開発・維持において利用されるフレームワークであり、ソフトウェア開発チームの作業管理において最もよく利用されるフレームワークのひとつです。
スクラムの重要な要素としては、以下のような定義があります。
スクラムの重要なメリットは、チーム体制や一定の作業ペースのほか、スクラムフレームワークでデリバリーする製品をすばやく定義できることです。スクラムの人気は非常に高く、「15th Annual State of Agile Report」によれば、66%のチームが使用しているそうです。スクラムの実践方法に関する情報は、ソフトウェア業界で幅広く提供されています。
カンバンとスクラムにはマクロレベルでは多くの類似点がありますが、決定的な違いもあります。ローコードプロジェクトでどちらかを選ぶ際、これらの違いが判断基準となることがあります。
特にローコードを使用して作業するアジャイルチームは、各アプローチの特性をよく見極め、チームの目標に最適なアプローチを選ぶ必要があります。現在スクラムを使用している場合、取り組み項目を検討し、新たなメトリックなどカンバンのどのような要素を取り入れればプロセスを加速できるかを評価します。
スクラムバンとは、スクラムとカンバンの両方の要素を使用してチームのパフォーマンスを向上させ、顧客により多くの価値を提供できるようにするアプローチです。スクラムのイベント、ロール、成果物とあわせて、物理的なボードやJIRAなどの仮想ボードを使用しているアジャイルチームは、すでにスクラムバンを実践しているといえます。
また、アジャイルチームでは、スプリント全体の作業はスプリントコミットメントのようなスクラム手法で定義し、チームの作業については進行中の作業を制限するというカンバンのコンセプトで管理するということがよくあります。進行中の作業を制限することで、コンテキストの頻繁な切り替えによるコストを減らし、開発者の効率を向上させることができます。
スクラムのチーム構成や指針と、作業方法の定義に役立つカンバンの手法を組み合わせたいと考えているアジャイルチームにとって、スクラムバンは最適な選択肢です。
まず、新しいチームを立ち上げるのか、既存のチームのアプローチを再評価するのかを確認します。あらゆるチームに最適なアプローチというものはありません。また、アジャイルの定義は1つだけではありません。各チームの目標、文化、成熟度、技術レベルなどの要素に基づいて最適なアプローチを定義するようにしましょう。このプロセスに終着点はありません。改善と学習を継続していくことになります。
ただし、体系的な意思決定アプローチを使用して、スクラム、カンバン、スクラムバンのどのアプローチが最適かを評価することは必要です。アプローチを評価する際の重要な考慮事項は、次のとおりです。
ローコード、ハイコード、ビジネス寄りのプロジェクトのいずれにおいても、どのアジャイルアプローチをとるべきかという問いに決まった答えはありません。しかし、前の章で紹介した質問に沿って組織やチームのニーズを分析することで、何らかの特徴、ニーズ、パターンが明らかになり、最適なアプローチの特定がしやすくなるはずです。
構造化や定期的な調整によってパフォーマンスが向上しそうなチームの場合、おそらくスクラムやスクラムバンが最適です。スクラムがアジャイルフレームワークの中で最もよく利用されているのは、わかりやすく、非常に効果的であるためです。スクラムやスクラムバンが最適なアプローチとなるのは、以下のようなケースです。
複雑に構造化されておらず、柔軟性が高いことを魅力に感じるローコードチームの場合、カンバンのほうが選択肢として適しているかもしれません。スクラムやスクラムバンから自然とカンバンへ進化していくと考える人もいますが、必ずしもそうはなりません。最善の策は、最初からカンバンを全面的に採用することです。カンバンが最適な選択肢となるのは、以下のようなケースです。
基本的には、カンバンを導入できるほどのスキルや成熟度がすでにあるか、その見込みがあるのであれば、開発スピードやチームの効率を上げることはできるはずです。プロセスの手続きやオーバーヘッドがある程度減ることで、チームが設計、開発、テスト、ユーザーフィードバックに集中する時間を増やすことができます。
ローコード開発チーム向けにどのアプローチを選択した場合も、一番大切なのは継続的な学習と改善です。ローコード開発のスピードや品質を最大限に活かせるようなプロセスに仕上げられるよう、チームを後押ししてください。