Agileと計画 - Agile/Scrumの考え方
私、IT業界にいるので、普段Agile/Scrumで開発を進めているわけですが、世の中ますます不確実性の高い世界＝VUCAの世界になっています。
VUCAは以下の頭文字を取ったものです。
- Volatility : 変動制
- Uncertinty : 不確実性
- Complexity : 複雑性
- Ambiguity : あいまいさ
こういう世界観なので、全ては予定通りに進みません。 そうすると、状況の変化に素早く対応していかないとまるで上手くいかなくなります。 そういう状況を解決するために生まれてきたのが、Agileの考え方なわけですね。
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を（主にここ）
この文章はよく誤解されるのですが、決して「計画をしない」ということではありません。 物作り、特にソフトウェア開発において、全てをアドホックにやっても上手くいきません。
そういうやり方をすると、上の方の人から
- 何を作っているのかよくわからない、
- いつできあがるのかよくわからない、締め切りに間に合うのか？
という声がよく出てきます（実際に聞いたこともあります）。 Agileの考え方を理解していない人ならなおさらです。
- 計画は立てます、ただし、状況に応じて変更します
ということです。
物作りにおいて、計画を立てると次のようなことがわかってくるはずです。
- 何が作られ、何が作られないのかがわかる
- いつ頃までにできあがるのかがわかる
- 今何がわかっているか、今何がわかっていないのか
- わかっていないものはいつ頃までに解決できれば良いのか
今自分たちがわからないものがあることを理解しておくというのはすごく重要です。 そして、わからないものがわかるようになるときには状況が変わっていたりすることもあります。
計画の立て方はいくつもあると思うのですが、スクラムを回している前提があると、
- PRDが作られる
- どのようなものを作るのかはっきりさせる
- PBIが作られる
- どのような順番で価値を提供していくのかがわかる
- PBIのリストからいつ頃終わるかが予測される
- PBIに見積がついている、かつ、チームのベロシティがわかっていると導き出される
PBIの見積は通常、相対見積もりで行うことが多いのですが、予実計測が出来ているのであれば時間換算でも良いとは思います。 見積の話はそれだけでかなりの量になるので、今回は省略しますが、一番重要なのは
チームのベロシティ＝1スプリントでどれだけの量を終わらせることが出来るのか
を知る必要があるという点です。
ベロシティが安定していると、
1スプリントで作業できる量がわかる⇒PBI全部が終わるのにかかるスプリントの数がわかる⇒いつ頃終わるのかの予測が立てられる
というわけです。
ここの考え方は「スプリント期間で出来る作業量には限界がある」というものです。 箱の大きさが決まっているのに、それ以上のものをつめようとしてもあふれてしまい、蓋が閉まらないということを意識しておく必要があります。
そして、大抵のソフトウェア開発には締め切りがつきものです。大抵、PBIのリストを全部やるときの予測期間では間に合わないので、やること・やらないことの優先順位を決める作業も必要になります。
組成したてのチームや人の入れ替わりの激しいチームではベロシティが安定しないことが普通なので大抵遅延します。したがってスクラムチーム回す際には、終わるまでチームメンバーの入れ替えが発生しないのが理想です。 とはいえ、人の増減は発生するので、ベロシティの予実は必ず計測するようにしましょう。
