Pages

2016年5月24日火曜日

スクラム開発でバッファを最小限に

Be.Cloud通信戌亥です。

 前回のブログは、「スクラム開発によりペースを作れ!」でした。スクラム開発には、従来のウォーターフォールにはない大きなメリットがあります。今回は「バッファ」の話をしたいと思います。

 因みに当社では、スクラム開発を基本としているため、スクラム開発と記載していますが、アジャイル開発と読み替えてもらってもあまり大差はないと思います。

 私が普段から大変悩んでいるのは、スクラム開発のメリットを話し出すと、やはり、従来型のウォーターフォールを得意としている人たちからはネガティヴな反応が出てくることです。その多くは「スケジュールが作れない」です。確かに、ウォーターフォール開発は、1番最初に工程表を作り、それに沿って開発をします。いわゆるWBS(Work Breakdown Structure)を作ります。しかし、これも結構厄介です。何故なら、全ての項目をBreakdownできればいいのですが、大きなプロジェクトになると、完璧なBreakdownが出来ません。また、プロジェクトを進めていく上で、障害となることもありますが、それを考慮したWBSを作るのは至難の技です。例えば、個別のエンジニアのスキルや予期しない問題の発生などは最初から予測することは難しく、遅延する可能性もある為、プロジェクトの全行程を完全にスケジュールすることは難しいのです。

バッファ

 そこで、多くのマネージャ達は知恵を絞ってバッファを設けます。「制約理論」を提唱したゴールドラットさんは、その著者「クリティカル・チェーン」の中でこのバッファを上手に説明してくれています。

 我々もよくやりますが、エンジニアに「このプログラムはどれくらいで作れる?」と聞くと、エンジニアは「(うーん、多分、5人日ぐらいと思うんだけど、少し見えない部分もあるので2人日余分に乗せて) 7人日です!」と応えます。このプログラムをAとしましょう。次に違うエンジニアに、別のプログラムBを同じように聞いてみると、「(10人日だと思うが、このPMは怖いんだよな、計画通りにつくらないと怒られるし、よし!) 13人日です!」そして、3番目のプログラマに、別のプログラムCを同じように聞くと、「はい、6人日です。(2人日ほど余裕を見てるけどね)」と多めに宣言をします。つまり、それぞれバッファを設けます。ここではこれを、「プログラミングバッファ」と呼ぶことにします。

 そしてプロジェクトマネージャは、総合テストの10人日(2人日のテストバッファを設けてある)を加えて、最終的に合計してみると7人日+13人日+6人日+10人日=36人日な訳ですが、もちろんプロジェクト全体のバッファ(ここでは「プロジェクトバッファ」と呼びましょう)を設けるので、「(5人日ほど上乗せして) 41人日でお客さんには出そう」となるわけです。もちろん値切り交渉の上手なお客さんにはここからさらに営業がのせる「営業バッファ」を設けたり、技術者のスキルによっては、さらにバッファを設けたりする(「スキルバッファ」)為、バッファはどんどん増えてきますが、今回はややこしいので、それは省きます。

 とすると、実際にこれだけのコストで済むかもと思われる、プログラムA 5人日+プログラム B10人日+プログラムC 4人日 + 総合テスト 8人日の合計 27人日に対して、41人日が提示されてしまいます。プログラミングバッファとプロジェクトバッファを合わせると14人日となり、大凡1.6倍の見積もりが提示されることになります。

 因みに、バッファはすべて悪ではありません。バッファと言うのは、製造業で言う在庫に当たるので(「クリティカル・チェーン」を参考)、不測の事態が発生した時に使えます。例えば、エンジニアがインフルエンザにかかってしまった場合は、そのバッファを使って、スケジュールを取り戻すことが可能です。


バッファを食い尽く理由(クリティカル・チェーンより)

プロジェクトを推進するにあたりバッファを作る事がよくある。それぞれの工程にバッファを作り、さらに全体でもバッファを作るために、全体の工程は2倍に膨れ上がる。しかし、それでもプロジェクトは遅れる。バッファを食い尽くしているからである。バッファを食い尽くす理由は、

1. 学生症候群
2. プロジェクトの掛け持ち
3. 作業の遅れは蓄積されるが、バッファは蓄積されない

が主な理由である 

バッファが多くなるのは計画曖昧である

 しかし、バッファが多すぎるとこれは無駄となります。どこかで聞いたことありますのね。そうそうジャストインタイムでは、在庫は「悪」とされていますが、バッファが多いと様々な問題を起こします。ここではその説明はしませんが、問題はバッファが多くなりすぎることと、そのバッファの使い方です。

 バッファを多く設けると言うのはどういうことでしょうか?つまり、計画が明確になっていないということです。計画が明確になっている場合にはバッファをそんなに多く設ける必要がありません。つまり、計画が曖昧である為にバッファを設けるのだと思います。よくリスクという言葉を使いますが、リスクと一言で片付けるのは、曖昧性を増やすことだと思います。リスクは何が起こるかわからないことを言いますが、バッファの中には起きることを想定しているバッファもあると思います。

スクラムでのバッファ

 我々がスクラムを始めた時に、私はなんとも言えない違和感を覚えました。その違和感は悪い意味での違和感ではなく、いい意味での違和感です。おそらく、実際に開発する人には悪い意味での違和感であり、開発を依頼する人にとってはいい意味での違和感になるのだと思います。

 その違和感は決まった日数でアウトプットを作り続けるということでした。我々の場合は2週間でした。2週間経つと、アウトプットが見れますが、次の2週間の新たな開発の計画もできあがります。今から考えるとその違和感というのは、「この2週間が一度守れなくなったらどうなるのだろう」ということだったんだと思います。つまり、たった2週間のことですが、その2週間が守れなくなると、後続の開発全てが遅れてしまうことを意味します。つまり、今この2週間に集中しないと、プロジェクト全体がどうしようもなくなるという違和感です。逆にみれば、後のことは考えずに、とにかく今の2週間をうまくやることを続けていけば、プロジェクトは遅延することなく、終わることができるといういい意味での違和感です。アジャイル開発を始めて経験する私には、このことが違和感としてこころに中に残っていました。これはまさに、バッファが小さくなっているということだと思います。バッファが小さくなっているからこそ、何か不足の事態が起きた時に、「どうするんだろう」と心配になっていたということです。もちろん、スクラムでも、ユーザストーリーに対してどれだけの開発が必要になるかをポイントで示しますので、実装が予測できないユーザストーリーにはバッファを設けます。しかし、ユーザストーリーは数日の開発に分割する為、バッファ自体が小さくなり、またバッファはあくまでスプリント単位であり、1回のスプリントで精算されますので、このバッファを次のスプリントに持ち越すことはできません。つまり、バッファは最小限にし、かつそのスプリント内で使い切ることになります。

 今回はプロジェクトの中で見込むバッファを中心に話をしてきました。もちろん製造業の中でも在庫は「悪」であるという考え方と、「必要不可欠なもの」という考え方があるように、ソフトウェア開発のバッファも必要という考え方があるかと思いますが、バッファが多すぎるということは、それだけ計画が曖昧であるということだと思います。最終的にソフトウェアを仕上げることが目的であれば、バッファを極力すくなくして開発をすることが、スケジュールを守る一番良い方法でると思います。

0 コメント:

コメントを投稿