アジャイルとスクラムの基本
アジャイル
アジャイルは、ソフトウェア開発における柔軟かつ効率的なアプローチとして、1990 年代後半に登場しました。このアプローチは変化に迅速に対応し、顧客のフィードバックを積極的に取り入れることに重点を置いています。また、イテレーティブに計画・実装・テストなどを行なっていくことが特徴として挙げられます。
さらに、アジャイルマニフェストというソフトウェア開発におけるアジャイルなアプローチの根本的な原則と価値観を表現した文書が策定されています。
宣言にある通り、アジャイルはプロセスよりも個人と対話、動作するソフトウェア、顧客との協力、計画への対応を重視します。
スクラムフレームワーク
スクラムフレームワークは、スクラムガイドによって定義されている、アジャイルにおける具体的な手法の一つです。スクラムは最新のスクラムガイドのみがその時の「スクラム」であり、スクラム 1.0 というようなものは存在しません。
多くの本にはスクラムガイドには書かれていない具体的なプラクティスやアンチパターンの紹介などが記載されていますが、それらはあくまで１つの「方法論」となります。
定義を追いたい場合はスクラムガイドを参照してください。
スクラムガイドを見てもらうとわかると思いますが、スクラムは非常にシンプルで、かつ「意図的に不完全」です。
ですから適用するチームはスクラムフレームワークの中で、さまざまなプロセス、技法、⼿法をトライすることができます。
スクラムフレームワークの要素
スプリント
スプリントとは、一定期間（通常は 1-4 週間）の開発サイクルです。1、2 週間がより一般的で、4 週間以上はあまりありません。なぜならスクラムは、予測可能性を最適化してリスクを制御するためにイテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを取っているからです。
また、基本的には 1 スプリントで 1 回リリースするイメージです。
登場人物
登場人物はプロダクトオーナー(PO)、スクラムマスター、開発チーム(メンバー)です。PO とスクラムマスターの兼務に関しては、一般的には行われません。その人物が単一障害点となり得るからです。
開発者とスクラムマスターは兼務されることもありますが、その場合スクラムマスターは技術的に特に優れたメンバーが兼務することは避けたほうが良いでしょう。理由は同じくその人物が単一障害点となり得るからです。とにかく心がけるべことは権限の集中をできるだけ避けるということです。
イベント
主要なイベントはスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブの 4 つです。 それぞれのイベントには推奨されるタイムボックスや参加すべき登場人物が異なります。
また、それぞれのイベントではチームがプロジェクトの進行を効果的に管理し、連続的な改善を促進するために開催されます。これは固定された時間(スケジュール)で開催してください。スプリント期間をずらさないための工夫です。スプリント期間が変化してしまうと様々なタスク進行における計測結果の信頼が落ちます。
成果物
プロダクトバックログ、スプリントバックログ、インクリメントが主要な成果物となります。
スクラムの利点と課題
利点
柔軟性と適応性
スクラムは変化に対して非常に柔軟であり、プロジェクトの要件が進行中に変化した場合でも、チームは迅速に対応し、方向転換することができます。
透明性の向上
定期的なミーティングと明確な役割分担により、プロジェクトの進捗状況がチームメンバー全員にとって透明になります。これにより、問題点を早期に特定することができます。
顧客満足度の向上
短いスプリントサイクルと頻繁なデリバリーにより、顧客は定期的に進捗を確認し、フィードバックを提供できます。これにより、最終製品が顧客の期待により密接に合致するようになります。
チームの自己管理と責任感
スクラムはチームメンバーに自己管理を促し、各個人がプロジェクトの成功に対してより大きな責任を感じるようになります。
生産性の低下防止
明確な目標と短期間のスプリントにより、チームは本来やるべき作業に集中します。また、プラクティスに沿ったミーティングなどのスケジューリングにより無駄な作業を排除することが容易です。
課題
文化的変化の必要性
トップダウン型の管理スタイルを採用していた組織がアジャイル的自己管理型のチームへ移行する場合、大きな文化的変化を必要とします。この変化には時間と努力が必要です。スクラムコーチと呼ばれるスクラムに詳しい人の助けを借りることが一般的な解決策です。
適切な理解とコミットメントの欠如
スクラムの原則とプラクティスを正しく理解し、それにコミットすることが重要です。組織内での十分な理解とサポートがなければ、スクラムの導入は困難になります。勉強会等で解消可能であるはずです。
チームのスケールに対応しづらい
小規模なチームやプロジェクトでは効果的なスクラムも、大規模なプロジェクトや複数のチームが関与する場合、スケーリングに課題を抱えることがあります。これに対処するための方法として Large-Scale Scrum (LeSS) や Scaled Agile Framework(SAFe)などがあります。
過度なミーティングと文書化
Scrum のイベントや成果物が過度になると、チームの生産性に悪影響を及ぼすことがあります。バランスを取ることが重要です。特にドキュメントが多重とならないように、既存のドキュメントはたどりやすくかつ読みやすい文であることが必要です。共有 Wiki ツールをいくつか試してみると良いです。