プロジェクト開始時に作った計画に従って、一つ一つのタスクを完成させては次へ進む、ウォーターフォールと呼ばれる従来の開発モデルでは、急激に変わっていく開発事情に耐えられない！　何かが計画通りにいかないと修正が非常に難しい！　と悩む企業が近年使いだした、アジャイル開発。ソフトウェア開発の世界ではアジャイルを使う人が急激に増えていることと思います。

その中でも代表的なスクラム開発はチームで話し合って進めていく、コミュニケーション重視の形式です。うまく使えば自立性のあるチームが、日々ミーティングで問題や目標を確認し合うので、問題検知・軌道修正が早く、短期間でのソフトウェア開発が可能になります。しかし、世間ではスクラムに対する勘違い、間違ったやり方が広まっていて、逆に失敗してしまうプロジェクトも多いようです。数ある勘違いの中でも特に多いのは、「スクラム開発は計画を立てない」という一点です。今回はこの点について一緒に考えていきましょう。

単刀直入に言ってしまうと、「アジャイル＝計画なし」ではありません。スクラムだから、アジャイルだから、を言い訳に次のスプリントまでしか計画を立てないチームはほとんどの場合失敗します。最初に考えていたよりも工数がかかってしまった、変更しすぎて費用が増えた、考えていたものとは違うものができてしまった、など様々な可能性が考えられます。

では、本来のスクラムはどうなっているのでしょう。プロジェクトが始まると、作業に取り掛かる前にまずインセプションデッキをつくり、プロダクトゴールやプランを立てます。そしてプロダクトバックログ(要求事項を一覧化したもの)を作成し、それに優先順位付けをして優先度の高いものから順に開発を行います。そしてバックログリファイメントという優先順位の見直しを行って常時調整します。

これが計画もなしに、毎スプリントごとに何をしなければいけないか抜き出して作業に取り掛かると、自分たちが今一体どこにいるのかわからなくなるため、行き当たりばったりな開発になってしまうのです。また、何でもかんでも変更してしまうと、変更にはコストがかかりますので費用がかさみます。これもよくある失敗の一つです。そうならないようにするにはやはり初期段階でトレードオフスライダーでQCDなど重要事項の優先度をプロダクトオーナーやステイクホルダーと合意し、適宜状況を確認しながらコントロールしていく必要があります。

つまりスクラムというのは未計画のまま進めてはいけません。動くソフトウェアをつくり、そのフィードバックを受けて、適宜状況に応じて変更を加えていくというのが真の姿なのです。使いこなせばメリットばかりなスクラム開発。スクラムで開発することを目的にするのではなく、ビジネスの成功を目的にスクラムをうまく活用し、ゴールを見誤ることなく、クオリティの高い製品を迅速に世に送り出していきましょう。