≪前編後編

番外編≫

アジャイル開発の進捗管理(番外編)在庫はリードタイム

2020年8月28日公開

前編と後編では、アジャイル開発における進捗管理の考え方を、バーンダウンチャートを中心に述べました。ここでは、バーンダウンチャートの形状から観測される事象について紹介します。あわせて、その原因と対策について考察します。

何故か上に凸

バーンダウンチャートは、縦軸に機能残量を、横軸に経過時間をプロットする単純なグラフです。
下の図のように、反復期間の最初に計画した機能残量の減少を、理想線とよばれる(図中では赤)線で示します。また、機能残量の減少を実績線としてプロット(図中では黒い線で表示)します。

図 バーンダウンチャート

上の図は、計画どおりに開発が進んでいったバーンダウンチャートといえるでしょう。しかし実際のバーンダウンチャートをいくつかみてみると、下図のように実績線が上に凸の形状を示していることがしばしばあります。

図 バーンダウンチャート(上に凸)

機能残量が反復期間の終了間際に急激に減少するこの現象については、以下のような言葉で説明されることが多いようです。

  • 学生症候群
    夏休みの宿題や試験対策など「期限までまだ時間があるから…」と、なかなか着手しない学生のような状態のこと。
  • パーキンソンの法則
    使える資源(時間やお金)を使い切ってしまうまで使ってしまうこと。計画よりはやく完成していても見積りどおりの時間まで完成したと言わなくなること。
  • 新たな問題の発見
    必要な作業の不足や、見込みではうまく動作するはずだった設計など、計画では予期していなかった新たな問題が発見されること。

    学生症候群によって着手は遅延する。あるいは、パーキンソンの法則によって前倒しには進まない。しかし、予期せぬ新たな問題の発見のために完成には見積りを超える時間がかかる。つまりバーンダウンチャートの実績線は理想線を必ず上回る。しかし、期限間際で頑張ることによって、反復期間の最後に帳尻を合わせる。

と、説明されていることをよく見かけます。

本当にそうなのでしょうか?実際そういう事例があるのかもしれません。
しかし、そうではない事例も実は存在します。そうではない事例とは、学生症候群もパーキンソンの法則も関係なく、新たな問題の発見もない。にもかかわらずバーンダウンチャートが上に凸の形状を示す事例です。

From Concept To Cash

「From Concept To Cash」は、リーンソフトウェア開発で言及されることの多い考え方です。「概念が浮かんでからお金がいただけるまで」そのリードタイム(経過時間)を重視します。バーンダウンチャートの形状からは、このリードタイムを推測することが可能です。

まずは、理想線と実績線がほぼ一致するバーンダウンチャートを見てみましょう。

図 バーンダウンチャート(理想線と実績戦がほぼ一致)

実績線つまり機能残量は、時間の経過にともなってほぼ線形に下降しています。
縦軸にプロットした機能残量が、どのように減少しているのかをバーンダウンチャート内に図示してみます。

図 バーンダウンチャート(ストーリーライフサイクル)

反復期間の冒頭に開発予定であった(図中にStoryと表示した)8つの機能は、順次完了しています。ある時点の機能残量は、その時点に完成していない機能の数(チャート内の機能生存を表すバーの本数)です。

さらに、生存状態の機能(つまり未完了の機能)の様子を詳しく示してみましょう。

図 バーンダウンチャート(ストーリーライフサイクル~Busy表示)

各機能を示すバーをグレーと赤で塗り分けました。グレーは(作業中ではない)Wait状態を、赤は(作業中である)Busy状態を示します。各機能は同時に開発される訳ではなく、一個流し(同時着手することなく一個ずつつくる方法)で開発されていることがわかります。

では次に「学生症候群」も「パーキンソンの法則」も関係しない。「新たな問題の発見」も無い。にもかかわらずバーンダウンチャートが上に凸の形状を示す場合についてみてみましょう。

図 バーンダウンチャート上に凸(ストーリーライフサイクル~Busy表示)

各機能の生存状態を見てみると、Wait状態とBusy状態がまだらになっていることがわかります。つまり一個流しで開発されていないことがわかります。
さらによく見てみると、Busy状態の時間の合計は、理想線と実績線が一致する場合と同じであるということもわかります。「学生症候群もパーキンソンの法則も関係なく、新たな問題の発見もない」ということは、各機能を完了させるためにかかる時間は変わらないということですから、時間の合計値が同じになります。

時間の合計値、より正確には工数(人時:ManHour)は両者ともに同じです。しかし、リードタイムつまり各機能が完了するまでの経過時間には相当な開きがあります。これはWait状態の時間によるものです。

一個流しでない場合には、Wait状態によってリードタイムが長期化するため、バーンダウンチャートは上に凸の形状を示すのです。

在庫はリードタイム

バーンダウンチャートから観測できる「ある時点の機能残量」は、その時点に完成していない機能の数(チャート内の機能生存を表すバーの本数)です。製造業でいう「在庫(中間在庫、あるいは仕掛品)」の数といえるでしょう。ソフトウェア開発ではWIP(Work In Progress あるいは Work In Process)と呼ばれます。

WIPが大きければ大きいほどリードタイムは長くなり、「一個流し」の場合、つまり「WIP=1」の場合にリードタイムは最短になります。これは、WIP(=在庫)を制御することでリードタイムを制御できることを意味します。

しかし、一個流しにしたからといってVelocity(反復期間あたりに完成する機能の数)が向上するわけではありません。各機能のリードタイムが短縮されるだけです。また、コストダウンされる訳でもありません。完成する機能の数が同じであり、稼働工数も同じだからです。


WIP=1(一個流し)WIP=大
リードタイム最短WIPの増加につれて長期化
コストWIPで変化しない
VelocityWIPで変化しない

それでは、理想線と実績線がほぼ同一である(=各機能のリードタイムが最短である)ことのメリットとはどのようなものなのでしょうか?

リードタイム短縮のメリット

リードタイム短縮のメリットはアジャイル開発のメリットそのものです。

開発者やチームの成長を促進 ~ 学習の視点
複数人が開発作業を共にするチームで一個流しを実現するためには、全員が同時に一つの機能の開発にあたる必要があります。機能一つずつの設計、実装、テストに対する知見を共有し開発者やチームの成長を促します。また、全員が同時に作業できるシンプルな設計へと洗練されます。これは品質の向上も促します。

品質と顧客満足度の向上 ~ リスク早期検知の視点
一個流しは、機能を一つ一つ順に利用可能な状態まで完成させます。要望の誤解、技術的な実現可能性や品質の検証が早期に実施されるため、故障も少なく満足度の高いソフトウェアが提供されます。

要求の変化に柔軟な対応が可能 ~ 変動対応性の視点
着手中の機能は一つ(一個流し)だけです。要求の変更が発生しても変更によるインパクトは最小化されます。このため要求の変化に柔軟に対応できます。

より速いスピードでの提供 ~ 正味現在価値の視点
理想線と実績線がほぼ同じであるということは、反復期間を短縮できるということです。

図 バーンダウンチャート

上図のようであれば、下図のように反復期間を半分にできます。

図 バーンダウンチャート(反復期間半減)

つまり、2回の反復に分割し、反復回数を倍増できるということです。

図 バーンダウンチャート(反復回数倍増)

反復期間が半分になり反復回数が倍になれば、要望の高い機能がより短いサイクルでリリースされます。要望から提供までのスピードが速いため、利用したい機能をタイムリーに利用できます。

このように一個流しによるリードタイムの短縮(WIP=1)は、アジャイル開発のメリットを最大化するものに他なりません。

持つべき視点

規模の経済のメリットを追求するウォーターフォール開発に対して、スピードの経済のメリットを追求するのがアジャイル開発です。スピードすなわちリードタイムの最小化によって、組織、プロセスや品質、顧客満足、財務状況が向上されます。

バーンダウンチャートは、縦軸に機能残量を、横軸に経過時間をプロットするだけの単純なグラフです。しかし上に凸のバーンダウンチャートを「最後にがんばったから期限に間に合った」とだけ見るのは少しもったいない話です。その背後にあるWIPやリードタイムの構成への視点を持つことで、よりバーンダウンチャートが有益なものとなります。この視点は、アジャイル開発者であれば当然持って然るべきといえるでしょう。


≪前編後編

番外編≫

参考文献

  • Mary Poppendieck, Tom Poppendieck. “Implementing Lean Software Development: From Concept to Cash”. Pearson Education, 2006, 304p, ISBN 978-0321437389.

執筆

坂田 晶紀(さかた あきのり)富士通株式会社 ジャパン・グローバルゲートウェイ
ソフトウェア開発者、中小企業診断士(Registered Management Consultant)
メインフレームOS、主にシステム資源最適化プログラムの開発に従事。
その後、WEBアプリケーション開発業務に携わり、2002年からアジャイル開発を実践。
アジャイルソフトウェア開発の品質管理、開発管理、組織マネジメントを中心に、約1,000の職場をコンサルティング。

お問い合わせ

ページの先頭へ