スクラム：優れたプロジェクトマネジメント手法

スクラムは失敗を推奨し、 「早く失敗せよ」を合い言葉にしています。 奇妙に聞こえますが、 これにはきちんとした理由があります。 従来、プロジェクトは結果を出すまでに 数か月、場合によっては数年かかっており、 期間の長さにかかわらず、 実に約 80％が失敗に終わっていました。 ではなぜ、スクラムはさらに 失敗を促すのでしょう。 実は、本当に重視されているのは 失敗することではなく、 「早く」の部分です。 失敗しても学ぶことができれば 問題はありませんが、 失敗から時間が経ちすぎると、 同じようには学べないからです。 スクラムは、アジャイル宣言とその原則を、 「小規模な開発と短期の学習サイクル」を 推奨するシンプルな枠組みに まとめています。 早く失敗することは、 早く学ぶことを意味し、 だからこそ、短いフィードバックループが 歓迎されます。 スクラムは規範的な枠組みではなく、 高速道路のガードレールのように ガイドとして使用します。 ガードレールは目的地を 示してはくれませんが、 車を安全に走行できる範囲に 留めてくれます。 スクラムもほぼ同じです。 アジャイル原則という緩やかな ガードレールの中で 短期的な活動を繰り返し、 プロジェクトを成功に導きます。 スクラムの枠組みを簡単に説明します。 まず、プロダクトオーナーが作業の バックログに優先順位を付けます。 チームは２週間ごとにバックログを確認し、 次の２週間で達成すべきことを決定します。 そしてバックログ項目に対する 機能の開発とテストを完了し、 使える状態にします。 ２週間後、プロダクトオーナーと ステークホルダーに成果物のデモを 行います。 最後に、この２週間を振り返り、 どうすれば作業効率を改善できるかを 話し合います。 短い期間で開発を行い、 最後に成果物に目を向けることで、 チームは早く失敗すること、より正しくは、 早く学ぶことが可能になります。