スクラム: 長所と短所
どちらの方法論にもそれぞれ長所と短所があります。スクラムでは、短い開発期間 (スプリント) の中で、少人数のチームを組んで共同作業に当たり、タイムボックス化された各スプリントの終了時に作業中のソフトウェアが納品されます。スクラムの場合は、計画プロセスを意図的に短く変更し、細かいピースに分けてソフトウェアを急ピッチで開発することに焦点を当てます。スクラムの長所は次のとおりです。
- スケジュールを立てやすい - ビジネス要件が複雑で、わかりにくく、スケジュールを立てづらいという問題をスクラムで乗り越えることができます。スクラムの場合の要件評価アプローチは、作業しやすい単位に分割し、開発を迅速化することです。
- エラーの影響が少ない - 1 つのスクラムでエラーが発生したとしても、次のスクラムですぐに手直しされ修復されます。
- コミュニケーションが向上する - 毎日ミーティングを開催するため、ステータスの最新情報 (進行と停滞) をはっきりと認識できます。実際に、開発の管理をタスク ボードの使用だけに絞ることができます。そのボードにスプリントのバックログが表形式でまとめられ、ステータスを記載する列が設けられています。
- 生産性が向上する - 毎日のミーティング開催により、チームの生産性が高まります。
- 顧客とのより良い関係を築くことができる - スクラムには作業を繰り返しながら進めるという性格があり、そのときどきに顧客を巻き込み、貴重なフィードバックをもらえるため、顧客のニーズに対するチームの意識が高くなり、その結果チームはニーズにより敏感に反応できるようになります。
- ソフトウェアが改善される - 変更は作業の中断ではなく、ソフトウェアの価値を高める手段です。
反対に、スクラムの短所は次のとおりです。
- スコープ クリープ - プロジェクトの終了時期が明確に決まっていないにも関わらず、変更が積極的に採用される状態になると、スコープ クリープが現実の問題になります。利害関係者は得てして機能を増やそうとする傾向があります。
- 大きなチームに向いていない - スクラムは、チームの人数が少ないときによく機能します。
- 経験の浅いチーム メンバーには荷が重い - スクラムがうまく機能するかどうかは、チーム メンバーが開発期間を見積もることができるかどうかにかかっています。
- 几帳面すぎる管理者には向いていない - スクラムは、スクラム マスターがチームに頼って、あまり細かくコントロールしようとしない方がよく機能します。スクラムは、個人が協力し合って自分の仕事を管理するものであり、厳格な監視を受けるものではありません。
- 離職率が高くなる - チームが少人数編成であり、開発期間も短いことから、負担が重くのしかかる傾向があります。
- 品質管理が難しい - チーム メンバーがすべてのテストを実施しますが、回帰テストが省略されることがあり、その結果、単体テストだけが実施されることになります。
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
カンバン手法とは
カンバンは、トヨタの技術者であった大野耐一氏が開発した手法で、時間の経過とともに徐々にサービス提供の改善を重ねていくという管理手法です。カンバン手法には 3 つの指導原則があります。
- 今やっていることから始める
- 漸進的、進化的な変化の追及に合意する
- 現在のプロセス、役割、責任、肩書を尊重する
カンバンには 5 つのコアとなる特性があります。
- ワークフローの可視化
- 仕掛品 (WIP) の制限
- フローの管理
- 管理およびプロセスのポリシーの明確化
- カイゼンと呼ばれている継続的な改善 (モデルと科学的な手法を使用する)
カンバン: 長所と短所
スクラムと同様に、カンバンにも長所と短所があります。カンバンの長所は次のとおりです。
- リソースの配分の改善 - WIP が制限されているため、リソースが利用可能になるときに、新しい作業がチームに入ってきます。
- プロジェクト管理の簡素化 - カンバン ボードにすべての作業の状態が一目でわかるよう掲載されているため、プロジェクト管理を簡単に行うことができます。
- 作業中断の減少 - 担当しているプロセスの作業に当たり、時間をかけながらプロセスを改善していくため、劇的な変更が発生することが少なくなります。
- より多くの情報に基づいた決断 - ワークフローを可視化しているため、作業の進捗状況が把握しやすくなり、変更を決断しやすくなります。
カンバンの短所は次のとおりです。
- カンバン ボードに最新の状況を反映していなければならない - カンバン ボードの内容が最新でないと大きな問題が発生する可能性があります。カンバンはチーム メンバーが常に最新の状況を掲載していることを前提にしており、スクラムのように毎日ミーティングを実施しないため、進捗が把握しづらい面があります。
- カンバン ボードが過度に複雑になる - カンバン ボードで追跡する項目やプロセスの数が多くなりすぎると、複雑になってしまい、正確な更新が難しくなることがあります。
- 期限がない - 開発の時間枠がないため、チームの進捗が遅れる可能性があります。
スクラムとカンバン: その違い
スクラムとカンバンは大きく異なっています。両者を折衷するのは不可能に見えるかもしれません。スクラムには、スクラム マスター、プロダクト オーナー、ステークホルダー (利害関係者) というように、あらかじめ決まった役割が設けられています。しかし、カンバンにはあらかじめ決まった役割はありません。スクラムもカンバンも「プル型」のシステムであり、担当することが可能なチーム メンバーがバックログから仕事を引き抜きます。しかし、見方を変えると、スクラムは実際のところ「プッシュ型」のシステムと言えます。バックログには「仕事のまとまり」という特徴があり、まとまった単位の仕事がスプリントの開始時点でチームに割り振られるからです。カンバンは、必要に応じてバックログから仕事が引き抜かれ続けるため、紛れもないプルベースのシステムと言えます。
スクラムの場合は、毎日のミーティングの他に、ソフトウェアを顧客に公開し、フィードバックをもらうためのデモなど、必須のミーティングを何回か催します。しかしカンバンには必須のミーティングはありません。
スクラムとカンバンの決定的な違いはおそらく、スクラムがスプリントの長さに制約を受けるのに対して、カンバンは開発期間の制限がない状態で運用されるということです。始まりも終わりも明確に決まっておらず、作業が絶え間なく流れ、開発が成功すると、新しい開発が始まるという方式なのです。
スクラムは容易かつ柔軟であることを意図しているものの、中にはアジャイル開発ビジネスにスクラムは厳格すぎるように感じる開発チームもあるでしょう。同時に、カンバンは緩すぎるように映るでしょう。スクランバンはスクラムとカンバンの折衷として誕生しました。スクラムの厳格さとカンバンの緩さを組み合わせて、多くのアジャイル開発組織にとって理想的な方式となってきました。
スクランバンの方法論: 両方の手法のいいとこどり
スクランバンについては、ソフトウェア開発手法に明るい Corey Ladas 氏が、その著作『Essays on Kanban Systems for Lean Software Development』の中で紹介しています。同氏は、スクラムからリーン (継続的な改善のために構築、測定、学習の流れに依存し顧客に与える価値にのみ焦点を合わせる) またはカンバンに開発チームを移行する手段としてスクランバンができたと見ています。しかし、チームがスクラムからの変更を行うことを意図していながらも、実際にはスクラムとカンバンの両方の要素を取り入れた独自の方法論となっています。スクラムまたはカンバンをスクランバンに置き換えるかどうかは、環境や組織のニーズに応じて決定する必要があります。
スクランバンは開発プロジェクトと保守プロジェクトで最もよく使用されている手法です。実際のところ、開発チームと保守チームの両方で同じスキルの大半が必要です。開発チームは開発プロセス全体を管理する手段を必要としますが、保守チームは不具合が発生したソフトウェアを更新し、修復できる必要があります。
スクランバンとスクラムの比較
- イテレーション: イテレーションはスクラムの性格をよく表している特性ですが、スクランバンは継続的なワークフローというカンバン アプローチを取っており、イテレーションを採用するかどうかは任意です。
- チームの役割: スクラムでは開発プロジェクトに参加している開発チーム メンバー全員に決まった役割を割り当てますが、スクランバンでは必要のある役割のみを割り当てます。
- 可視性: スクラムでボードを使用することもありますが、使用されるのはバックログとバーンダウン チャートがほとんどです。一方、スクランバンの場合は、カンバンと同様にスクランバン ボードを使用して作業の可視性を維持します。
- ミーティング: スクラムもスクランバンも毎日ミーティングを実施しますが、スクランバンではスプリントやリリース計画のミーティングがなく、レビューも実施しません。スクランバンでは、必要に応じて計画を立てます。
- 見積もり: スクラム チームはスプリントに課された成果の達成にかかる作業時間を (たいていはバケットサイズ プラニング システムとストーリー ポイントを使用して) 見積もる必要がありますが、スクランバンでは時間の制約がありません。その代わり、チームが実行するタスクの数が増えるにつれて、見積もりが次第に確実になります。
- WIP: スクラムの場合、WIP のすべてがスプリントのバックログで決まり、各スプリントのスタート時点で計画されますが、スクランバンの場合、チームの WIP は利用可能なリソースに限定されます。
- 変更: スクラムの場合、次のスプリントで変更に対応して計画できるため、変更を受け入れやすいですが、スクランバンの場合は、変更に即座に対応します。スプリントとバックログがないということは、タスクを導入できるタイミングに制限がないということです。変更は、担当できるリソースがあるかどうかの問題になります。
- フィーチャー フリーズ: スクランバンでは変更に即座に対応しますが、限界があります。スクランバンではフィーチャー フリーズが採用されています。フィーチャー フリーズとは、プロジェクトの期限が迫ってきているため、変更や機能追加を受け付けられなくなる期限のことです。
- トリアージ: スクランバンでは見積もりが採用されていないため、トリアージ段階は重要です。プロジェクトの期限が迫るにつれ、プロジェクト マネージャーは、スクランバンのトリアージによって、重要性の低い機能の作業を中断し、重要な機能を期限内に完了させることができます。
スクランバンとカンバンの比較
- チームの役割: カンバンにあらかじめ決まった役割はありませんが、スクランバンには決められたチームがあり、必要な役割が決まっていることもあります。
- ミーティング: カンバンの場合、ミーティングは必須ではありませんが、スクランバンの場合は毎日ミーティングを実施します。毎日のミーティングは、チーム メンバー間の共同作業を維持し、進捗を妨げる要因を解消するうえで効果的です。また、カンバンは進化を目指すプロセスですが、進化や改善案を検討するための決まったミーティングはありません。スクランバンの場合は、事後の検証を許容しているため、チームはプロセスの改善に打ち込み、その中で得たものをチーム メンバーと共有することができます。
- メトリック: カンバンもスクランバンも、主なメトリックとしてリード タイムとサイクル タイム (同じ意味で使用されることもあり) の測定に比重を置いています。このメトリックで、特定のタスクが完了するまでの平均時間を見積もります。リード タイムは顧客の要求を受け付けてから顧客に納品するまでの時間です。サイクル タイムは、作業の開始から納品までの時間です。
スクランバンの導入に最も適した環境とは
スクランバンの導入に最適な環境がどのようなものかと疑問に思うかもしれません。すべての方法論がそうであるように、スクランバンもすべての環境や文化に向いているわけではありません。組織がスクラムに非常に向いているケースもあるでしょう。たとえば、経験豊富なメンバーが多く、顧客が開発プロセスへの参加を望んでいて、ユーザーが求めていることを明確に把握できており、決められたプロジェクト管理とタイムラインの重要性が会社で高く認められているとしたら、スクラムを採用することができます。主に保守環境の業務に携わっていて、その環境で新しい開発がチームのアクティビティのごく小さな部分でしかなく、作業が継続されていて、必要に応じてタスクを引き抜くことが重要であり、特定の顧客に応じて決められたプロジェクトがないのであれば、カンバンを採用することができます。
スクランバンを導入する最善のタイミングは次のとおりです。
- あるプロジェクトで、ユーザーの求めている内容に想定外の変更や優先順位の立て直しがたくさん発生する場合。
- スクラム式の開発プロセスにプル型の特徴を加えたいと考えている場合。
- さまざまな問題や、スクラムの時間の制約に合わせるだけの十分なリソースがないことが原因でスクラムがうまく機能していない場合。
- 優先順位が常に変化するヘルプ デスクのサポートのような、イベント駆動型の作業の場合。
- チーム全体が機能追加と既存製品のサポートに注力している場合。
- 開発チームでスクラムを採用しているが、自分自身はカンバンの原則の一部に関心がある場合。
- スクラムの厳格さがチームの変更に対する適応能力を限定していると思われる場合。
- カンバン方式に変えようとしているが、混乱を抑えるために、方法論の変更を小さくする必要がある場合。
最後にスクランバンについて必ずお伝えしたいことは、チームがその手法にどのように反応するかということです。スクラムがうまく機能するチームは、構造化のレベルを上げ、今後の作業内容を把握したいと考えているようなチームです。スクランバンの主なメリットは、モデルの流動性です。突き詰めればどの開発手法でも同じことなのですが、企業とチームが気に入るかどうかで成功するかが決まります。
Smartsheet がスクランバンにとって効果的なツールである理由
ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。