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

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

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

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

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

 

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

 

1. 学生症候群

2. プロジェクトの掛け持ち

3. 作業の遅れは蓄積されるが、バッファは蓄積されない

 

が主な理由である 

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

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

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

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

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