アジャイル開発の進捗管理(前編)
バーンダウンチャート

2020年7月2日公開

「ウォーターフォール開発とアジャイル開発とでは工程の捉え方が大きく異なる」と、テクノロジーコラム「アジャイル開発の原価管理(中編)」で述べました。異なるプロセス、異なる工程。であれば、アジャイル開発では異なる進捗管理が必要になりそうです。

進捗管理とは

進捗管理。ソフトウェア開発では日常的によく使われることばです。その定義を調べてみようとWeb検索してみました。しかし、「進捗管理とは○○である」といった定義を見つけることができませんでした。どのように進捗管理を実施するのか?つまりHowについての記述は数多くありましたが、WhatやWhyにあたる定義がなかなか見つかりません。

いくつかみたWeb検索結果をあわせてみると、

進捗管理とは、計画をまもるために、予定と実績とのズレや進み遅れを管理すること。遅れたらリスケジューリングして遅れの原因に対処すること

と、判断できます。

であれば、

  • Why:計画をまもるため
  • What:予定と実績のズレや進み遅れを管理すること
  • How:遅れたらリスケジューリングして遅れの原因に対処すること

と、いえるでしょう。

進捗率

進捗は進捗率(単位はパーセント)でみることが多く、分母と分子は、それぞれ「全体の量」と「終わった量」で示します。

進捗率(%)=終わった量/全体の量

全体に対する完了の度合いが進捗率です。全体の量と完了した量がわかれば、進捗率は出せるということです。

全体の量と完了した量

アジャイル開発では、開発する全体の量は決まっていません。しかしイテレーションあるいはスプリントと呼ばれる反復期間でどれだけつくるか、つまり反復期間内の開発量は、反復の冒頭に計画ゲーム(あるいはスプリントプランニング)と呼ばれるミーティングで計画します。

計画

開発者全員を含む関係者によるミーティング(計画ゲームあるいはスプリントプランニング)で、反復期間内につくる機能の量や優先順位を計画します。

  • 反復期間 ~ 開発期間を通じて固定
  • 個々の機能の量 ~ それぞれの機能をつくるのにどれくらいかかりそうか?
  • 受容能力(Capacity) ~ 全部でどれくらいつくれそうか?
  • 優先順位 ~ どういう順番でつくるか?

反復期間

反復期間(イテレーションあるいはスプリント)の長さは、概ね2週間以下の期間とすることが多いです。根拠としては、

  • 計画が容易~なんとか想像できるのは、向こう2週間までの分までがやっと
  • ふりかえりが容易~なんとか思い出せるのは、2週間以内に起きたことがやっと
  • リスクを最小化~変動に対するリスク、検証・品質に対するリスクを小さくできる

これらが上げられます。しかし「ハイリスクである」、「頻繁なリリースが必要である」あるいは「開発プロセスをより頻繁に調整する必要がある」など、より短いサイクルが必要な場合には、2週間未満(例えば1週間)とすることもあります。

また、反復期間を固定にするのは以下の特質によるものです。

  • 反復増加型のアジャイル開発では機能ごとに品質検証の完了が必要である
  • 反復期間内に費やすコストは反復期間の長さに依存する

これらの特質から、反復期間(デリバリータイム)を固定にすることで、品質とコストとデリバリー(QCD)を一定にすることが可能となります。

個々の機能の量と受容能力

下記の視点で量を見積ります。

・開発する機能それぞれ、一つ一つの大きさ(=規模、量)はどれくらいか?
・反復期間内にどれくらいの量をつくれそうか?

優先順位

各機能ごとにつくる優先順位をつけます。優先度ではありません。一列に並ぶように順番をつけます。優先順位に従ってつくるためです。
同時につくるとリードタイムが長くなるため、一つの機能に集中してつくりきります。
分担して別の機能をつくったり、開発対象の機能を切り替えながらつくると、完了までの期間が延びるため、一つずつつくります。一つずつつくることを製造業ではよく「一個流し」といいます。

アジャイル開発の進捗

冒頭、進捗の管理は進捗率でみることが多いと述べました。

進捗率(%)=終わった量/全体の量

しかし、進捗率で進捗を管理するアジャイル開発チームを見かけたことはほとんどありません。そもそも、全体の量が決まっていないアジャイル開発では進捗率を計上できないでしょう。

全体の量を決定することはできませんが、反復期間の冒頭には、スコープ(どの機能をつくるか、どれだけの機能をつくるか)を計画します。そして反復期間は固定されています。反復期間内には、バーンダウンチャートを利用して機能の量を追跡することが多いでしょう。

バーンダウンチャート

下の図は、バーンダウンチャートの例です。

【図 バーンダウンチャート】

バーンダウンチャートの横軸は反復期間内の経過時間縦軸は反復期間内につくるつもりの残機能量です。
一日1回あるいは複数回、その時点での残機能量をプロットします。

進捗管理しない?

多くのアジャイル開発では、計画したスコープが固定された反復期間内に収まりそうにない場合には、機能量を削減します。

【図 バーンダウンチャート ~ スコープの削減】

また、計画したスコープが反復期間の終了時期よりも早く完了しそうな場合には、機能量を追加します。

【図 バーンダウンチャート ~ スコープの拡張】

進捗管理とは、計画をまもるために、予定と実績とのズレや進み遅れを管理すること。遅れたらリスケして遅れの原因に対策すること

と、述べましたが、計画をまもるためにバーンダウンチャートが利用されている訳ではないようです。

多くのアジャイル開発では、

・「どれだけつくるのか」の計画自体を変える ~ スコープは可変
・「いつまでにつくるのか」の計画はまもる ~ 反復期間は固定

という具合に、反復期間は固定されているものの、反復期間内に計画したスコープを達成できそうになかったらスコープを減らしてしまいます。計画が必ずしも遵守される訳ではないのです。また、進捗を測る単位である進捗率は、

進捗率(%)=終わった量/全体の量

であり、スコープが可変である場合には意味を持ちそうにありません。

ということは、
アジャイル開発では、進捗管理を実施しないのでしょうか?
進捗管理を実施しないのであれば、何を管理しているのでしょうか?

後編では「何を管理しているのか?」についてみていきましょう。

参考文献

  • Alistair Cockburn. "アジャイルソフトウェア開発" .株式会社テクノロジックアート訳, 長瀬 嘉秀(監訳), 今野 睦(監訳). ピアソン・エデュケーション. (2002/8/30). 400p. ISBN 978-4894715790

  • Alistair Cockburn. "Crystal Clear: A Human-Powered Methodology for Small Teams" . Addison-Wesley Professional; 1版 (2004/10/19). 336p. ISBN 978-0201699470

   

執筆

  • 坂田 晶紀(さかた あきのり)

    株式会社富士通ソフトウェアテクノロジーズ Agile⁺開発センター
    ソフトウェア開発者、中小企業診断士(Registered Management Consultant)

    メインフレームOS、主にシステム資源最適化プログラムの開発に従事。
    その後、WEBアプリケーション開発業務に携わり、2002年からアジャイル開発を実践。
    アジャイルソフトウェア開発の品質管理、開発管理、組織マネジメントを中心に、約1,000の職場をコンサルティング。

   

ページの先頭へ


前編 バーンダウンチャート
前編 バーンダウンチャート スコープの削減
前編 バーンダウンチャート スコープの拡張
前編 TOP
前編 NEW