カンバンとスクラムの違い

スクラムの重要な要素としては、以下のような定義があります。

• チームのロール: 開発チーム、プロダクトオーナー、スクラムマスター。
• イベント: スプリント、スプリント計画、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ。
• 成果物: 製品バックログ、スプリントバックログ、（プロダクト）インクリメント。

スクラムの重要なメリットは、チーム体制や一定の作業ペースのほか、スクラムフレームワークでデリバリーする製品をすばやく定義できることです。スクラムの人気は非常に高く、「15th Annual State of Agile Report」によれば、66%のチームが使用しているそうです。スクラムの実践方法に関する情報は、ソフトウェア業界で幅広く提供されています。

カンバンとスクラム: 主な違い

カンバンとスクラムにはマクロレベルでは多くの類似点がありますが、決定的な違いもあります。ローコードプロジェクトでどちらかを選ぶ際、これらの違いが判断基準となることがあります。

特にローコードを使用して作業するアジャイルチームは、各アプローチの特性をよく見極め、チームの目標に最適なアプローチを選ぶ必要があります。現在スクラムを使用している場合、取り組み項目を検討し、新たなメトリックなどカンバンのどのような要素を取り入れればプロセスを加速できるかを評価します。

スクラムバンとは

スクラムバンとは、スクラムとカンバンの両方の要素を使用してチームのパフォーマンスを向上させ、顧客により多くの価値を提供できるようにするアプローチです。スクラムのイベント、ロール、成果物とあわせて、物理的なボードやJIRAなどの仮想ボードを使用しているアジャイルチームは、すでにスクラムバンを実践しているといえます。

また、アジャイルチームでは、スプリント全体の作業はスプリントコミットメントのようなスクラム手法で定義し、チームの作業については進行中の作業を制限するというカンバンのコンセプトで管理するということがよくあります。進行中の作業を制限することで、コンテキストの頻繁な切り替えによるコストを減らし、開発者の効率を向上させることができます。

スクラムのチーム構成や指針と、作業方法の定義に役立つカンバンの手法を組み合わせたいと考えているアジャイルチームにとって、スクラムバンは最適な選択肢です。

最適なアプローチの決め方

まず、新しいチームを立ち上げるのか、既存のチームのアプローチを再評価するのかを確認します。あらゆるチームに最適なアプローチというものはありません。また、アジャイルの定義は1つだけではありません。各チームの目標、文化、成熟度、技術レベルなどの要素に基づいて最適なアプローチを定義するようにしましょう。このプロセスに終着点はありません。改善と学習を継続していくことになります。

ただし、体系的な意思決定アプローチを使用して、スクラム、カンバン、スクラムバンのどのアプローチが最適かを評価することは必要です。アプローチを評価する際の重要な考慮事項は、次のとおりです。

• 1. 3つのアプローチすべてを習得します。スクラムを利用しているのであれば、時間を取ってカンバンを習得します。多くの高品質なコンテンツがオンラインで無料で提供されています。ブログを読んだり、無料の評価版を入手したり、オンラインコースや対面コースを受講したりするのもよいでしょう。
• 2. 組織の目標を把握します。チームの作業が組織の全体的な目標にどう寄与しているかを把握できていないせいで適切なアプローチをとれていないチームも多いものです。チームが重視するのは、市場リリースのスピード、デジタルトランスフォーメーション、アプリケーションのバックログ削減、新しいプラットフォームへの技術対応のどれでしょう。目標によってアプローチも変わってきます。
• 3. 外部のサポートを得ます。自身の知識やパフォーマンスを客観的に見ることは難しい場合があります。コンサルタントやコーチからサポートを得るのは有益ですが、「外部」が指すのは、こうしたリソースに限りません。他のチームのメンバーや、仕事でつながりのあるプロフェッショナルから支援を受けるのもよいでしょう。
• 4. 顧客からフィードバックを得ます。サービスの提供先である社内外の顧客から、現在のプロセスの価値、明確さ、有効性に関して重要なフィードバックが得られる場合があります。エキスパートではなくても、顧客は特定のプロセスの仕組みを知っているため、何らかの意見を持っています。顧客のフィードバックやニーズを聞き、それに応えるべきです。
• 5. プロセスの成熟度を評価します。現在、プロセスを明確に定義するのに苦労しているか。今のプロセスで、顧客に継続的に価値を提供することはできるか。何か目新しいことを試す前に、高いパフォーマンスで現行プロセスに取り組む必要はあるか。
• 6. 技術的な成熟度を評価します。テクノロジースタックに対するチームの習熟度が発展途上にある場合、構造や一貫性を提供するアプローチが最適な戦略かもしれません。チームが使用中のテクノロジーに習熟した段階で、流動性や柔軟性の高いフレームワークへの移行を検討するとよいでしょう。
• 7. チームが構造化を必要としているかどうかを把握します。必要の有無にかかわらず、プロセスの構造化を進めることが目的となってしまっているチームもあります。チームメンバーと対話し、メンバーの業務を観察して、意見を聞いてください。メンバーを快適にしてパフォーマンスを向上させるには、構造化を進めるべきでしょうか、構造化を避けるべきでしょうか。これもアプローチ選択の指針となります。

ローコードプロジェクトで使用すべきアプローチ

ローコード、ハイコード、ビジネス寄りのプロジェクトのいずれにおいても、どのアジャイルアプローチをとるべきかという問いに決まった答えはありません。しかし、前の章で紹介した質問に沿って組織やチームのニーズを分析することで、何らかの特徴、ニーズ、パターンが明らかになり、最適なアプローチの特定がしやすくなるはずです。

スクラムかスクラムバンか

構造化や定期的な調整によってパフォーマンスが向上しそうなチームの場合、おそらくスクラムやスクラムバンが最適です。スクラムがアジャイルフレームワークの中で最もよく利用されているのは、わかりやすく、非常に効果的であるためです。スクラムやスクラムバンが最適なアプローチとなるのは、以下のようなケースです。

• 新規チーム。Tuckmanのチーム開発ステージの早い段階にある場合は、スクラムが最適な選択肢となるでしょう。スクラムの明確に定義されたロールは、チームにおける自身の役割や貢献をメンバーにしっかり理解させるうえで良い指針となります。
• 混合チーム。混合チームには、オンショアチームとオフショアチーム、従業員とコンサルタント、最近ではシチズンデベロッパーとプロの開発者などの組み合わせがあります。こうした場合、デジタル製品の開発方法に関するチームメンバーの経験や考え方が異なることがよくあります。スクラムは製品の開発方法の構造と定義を示します。特に、複数の文化を持つチームや部門横断型のチームが製品バックログの構造化や提供方法について話し合う際には、スクラムが指針として役立ちます。
• 大規模なエコシステムに属するチーム。大規模な組織に所属するチームであり、他の開発チームやビジネスチームと成果物をやりとりする必要がある場合、スクラムが最適な選択肢となりえます。スクラムではスプリントの期間や間隔が一定であるため、予測に基づいて計画を立てやすく、相互依存の関係にあるチームとの作業がしやすくなります。
• スクラムに慣れているチーム。スクラムの予測のしやすさや定義が単純に快適だというチームもあります。スクラムがよく利用されているのは、多くの人がスクラムを好み、スクラムによって成果をあげているためです。スクラムチームが安定していて、パフォーマンスが高く、価値を提供できている場合は、アプローチを大幅に変えるのではなく、改善の余地を探すとよいでしょう。
• 拡張性。拡張性はどの開発フレームワークにおいても重要な考慮事項です。製品開発チームは、相互につながりのあるチームのネットワークとしてますます大規模になっていきます。製品開発の必要に応じてすばやくチーム数を増減するにあたり、スクラムは非常に適しています。NexusやScrum at Scaleなどのフレームワークは、ハイコードプラットフォームとローコードプラットフォームのどちらを使用している場合でも、スクラムを拡張する際のモデルとして適しています。
• スクラムまたはスクラムバンは様々な状況で最適なアプローチとなります。多くの場合、まず開始点を決めて試行してみて、そこから学習し、調整するのが最適なアプローチとなります。

カンバン

複雑に構造化されておらず、柔軟性が高いことを魅力に感じるローコードチームの場合、カンバンのほうが選択肢として適しているかもしれません。スクラムやスクラムバンから自然とカンバンへ進化していくと考える人もいますが、必ずしもそうはなりません。最善の策は、最初からカンバンを全面的に採用することです。カンバンが最適な選択肢となるのは、以下のようなケースです。

• スピードが最優先事項である場合。チームが成熟しており、（当然ながら）市場リリースのスピードが最も重要な要素である場合、一般的にはカンバンが最適な選択肢となります。カンバンを採用すると、組織の自律性を促進し、柔軟性を確保して、形式化やプロセスというオーバーヘッドを最小限に抑えながら開発を進めることができます。効率化や改善を進めるには、定量的なメトリックを使用するとよいでしょう。
• 成熟した技術チーム。ローコード開発に習熟したチームの場合、進行中の作業やシステム内のフローを制限して重点的に効率化を行うことでメリットを得られます。技術面で基本的な問題が発生することはほぼないので、プロダクトオーナーやエンドユーザーとのリアルタイムのコラボレーションの向上などに重点を置くことができます。
• 成熟したアジャイルチーム。アジャイル開発をよく理解し、継続的に価値を創出できるチームの場合、カンバンを利用することでローコード開発をさらに加速できる可能性があります。たとえば、成熟したアジャイルチームは、タイムボックスや期間の決まったスプリントではなく作業量に基づいてリリース日を定めることでメリットを得られる場合があります。こうすると、計画や見積もりといったオーバーヘッドを減らし、市場リリースを高速化することができるからです。
• パフォーマンスの高い機能チーム。カンバンを成功させるには最大限の柔軟性と対応力が必要です。要件定義を担当するチームメンバー全員がこうした能力を身に着けることを求められます。カンバンではプロダクトオーナーロールを規定していませんが、実際には、誰かがユーザーにとっての価値を規定したり、開発内容を決定したりする必要があります。また、高品質なユーザーストーリーを掘り下げたバックログが開始時になかったり、ローコード開発と同じペースで新しい要件を定義するためのプロセスがなかったりすると、ローコードのスピードを最大限発揮することができません。
• ペースと期間の柔軟な選択。一定期間のスプリントできちんと製品開発を進めることが常に効率的で実践的であるわけではありません。チームは1つとは限らず、作成するアプリケーションコンポーネントの規模も様々です。このような場合、決まりきった一定期間のスプリントに合わせてコンポーネントを分割するのではなく、相応な期間をかけて作成してリリースするほうが効率的です。スキルや成熟度が異なるチームで様々な規模の製品コンポーネントを並行して作成する場合、カンバンを使用してリリースサイクルを管理するのが合理的です。
• 拡張性。カンバンには、複数のチームに拡張する際の指針はありません。しかし、経験豊富な成熟したアジャイルチームであれば、連携方法を柔軟に定義してスピードや効率を最大化することができます。これは、カンバンチームが迅速かつ簡単に拡張し、後で必要に応じて適正な規模にすることができるということを意味します。カンバンの拡張方法を定義する際に肝心なのが、相互依存の関係にあるチームでどのように依存関係を管理するかを把握し、定義することです。

基本的には、カンバンを導入できるほどのスキルや成熟度がすでにあるか、その見込みがあるのであれば、開発スピードやチームの効率を上げることはできるはずです。プロセスの手続きやオーバーヘッドがある程度減ることで、チームが設計、開発、テスト、ユーザーフィードバックに集中する時間を増やすことができます。

継続的な学習

ローコード開発チーム向けにどのアプローチを選択した場合も、一番大切なのは継続的な学習と改善です。ローコード開発のスピードや品質を最大限に活かせるようなプロセスに仕上げられるよう、チームを後押ししてください。