計画づくりにおいて「バッファ」をどう取るか
はじめに
MIKE COHN著書の「アジャイルな見積りと計画づくり」を読んでみました。 本書はアジャイル開発における見積りや計画づくりを行う際のハウツー本であり、実践的な手法がいくつも紹介されていました。 なかでも特に興味深かった、いや私が実際に苦戦したポイントである、第4部17章「不確実性に備えるバッファの計画」について理解を深めたいと思い、これまで苦戦したポイントなどを振り返りながら本記事で深堀りしてみたいと思います。
バッファって？
本書では、計画づくりにおいてバッファは以下の2種類に分かれると紹介されていました。
フィーチャバッファ
フィーチャバッファって何か？
これはプロダクトに対する要求が優先順位付けされていて、その全てが必ず提供されるわけではないと合意できている場合に用意するバッファを指します。 このフィーチャバッファを設けることで到達点に幅を持たすことができ、スケジュールを柔軟に調整することが出来ます。
また、MoSCoWルールに従って、フィーチャを必須、重要、有用、不要の4つに分類することも有効とされています。
で、振り返ってみると
私が担当したプロジェクトでは、まず事業部の方たちと何を作るか？の認識合わせのためにユーザーストーリーマッピングを行い、プロダクトに必要となるフィーチャの洗い出したうえで、1stリリースで必須か、必須以外かで分類しました。必須以外のフィーチャーは時間的に余裕があればやると事業部の方にも一応申し伝えてはいたので、それ自体がフィーチャバッファになっていたのかもしれません。
しかし、そもそも必須と分類したフィーチャには、重要や有用に分類されるフィーチャもたくさん含まれてしまっており、必須と分類したフィーチャを見積もってみると、事業部が希望するリリース時期にギリギリとなってしまっていました。なので、実際にはフィーチャバッファを持つことは出来ていなかったと思います。
フィーチャバッファを実践する上で、フィーチャを分類するだけではなく、その分類の取扱いについて事業部の方の合意が必要であり、そこの部分を理解して貰い認識を合わせることが結局は一番難しいポイントだなぁと感じています。
スケジュールバッファ
スケジュールバッファって何か？
一方で、スケジュールバッファは名前の通り、スケジュールに適用するバッファを指します。 スケジュールバッファの見積りには、ユーザーストーリーそれぞれに50%見積りと90%見積りを行い、適切なバッファの量を見積もる手法が紹介されていました。 これは、50%以上の確率で、タスクの完了までには見積りよりも長く時間がかかるという事実を踏まえて、ユーザーストーリーごとのリスクを含んだ見積りをすることが可能とされています。
また、スケジュールバッファの持たせ方として、ユーザーストーリー毎にバッファを管理するのではなく、プロジェクトバッファとして合計量で管理することが推奨していました。 理由としては、パーキンソンの法則や学生症候群といった観点から利点が大きいからとされています。
で、振り返ってみると
私が担当したプロジェクトでは、計画づくりを行うにあたり、開発チームと一緒にユーザーストーリー毎の開発規模を見積もりました。 やり方としては、プランニングポーカーとほぼ同じ要領ですが、見積単位はS/M/L/XLを用いて、50%見積りのみを実施しました。
もちろん50%見積りは開発者によって異なりますので、場に出た一番小さい見積りをMin、一番大きい見積りをMaxとして扱い、ユーザーストーリー毎の見積りに幅を持たせて管理しました。 最終的には、MinとMaxそれぞれの見積り合計量を出したうえで、それぞれ20%程度をバッファとして追加することにしました。
おそらく、これが本書で紹介されているスケジュールバッファであったと思いますが、50%見積りでの開発者間の見積りのバラつきをバッファとしたため、見積りにリスクを完全に包含できていなかったことになります。
実際に、見積りよりも時間を要したユーザーストーリーが多くあり、また追加要件やユーザーストーリーやタスクの漏れなどもあり、Max見積り合計量に20%バッファを加味したスケジュールぎりぎりになってしまいました。
てか、そもそもバッファって水増しなのか
スケジュールバッファを設けていることは事業部の方には伝えていませんでした。理由はもちろん、水増しと思われてしまう＆説明しても理解して貰えなさそうだからでした。
しかし、本書では、バッファの存在を隠したり、使い方を秘密にするべきではなく、ステークホルダ含めて全員がスケジュールに自信を持てるようにするために、見積りとバッファをどうやって導き出したかを伝えることが重要とされていました。
確かに根拠なく20%をバッファとしていたので説明できなかっただけかもしれません。そういう意味でもこの本で紹介されているバッファの見積り手法は有効だと強く感じました。
さいごに
プロジェクトを機能面での不確実性から守るにはフィーチャバッファを用意し、スケジュール面での不確実性から守るにはスケジュールバッファを設ける。さらにこの２つのバッファを組み合わせることでさらに柔軟性をもたせることができ、それぞれのバッファを小さくすることができる。と最後に纏められていました。
この章を初めて読んだときはものすごく納得感があり、私が担当したプロジェクトを振り返りながら、もっとこうすれば良かったのか、と終始読み進めていました。過去は反省したら忘れて、次回の計画づくりで早速実践していきたいと思います。
