fortunecodec

talking about daily rake

顧客にもたらす価値に着目 - 「アジャイルな見積りと計画づくり」

with 2 comments

本書「アジャイルな見積りと計画づくり」は、「Scrum and XP from the Trenches」でも触れられていた、Mike Cohnさんの「Agile Estimating and Planning」の邦訳です。

アジャイルな見積りと計画づくり

理想日及びストーリーポイントによる見積りについては、「Scrum and XP from the Trenches」の記述とほぼ同じ内容で、更にそれを詳しく説明しているものですが、計画やモニタリングの部分で、個人的になるほどーと思ったポイントが幾つかありました。

フィーチャベースでの計画

イテレーション計画(Scrumではスプリント計画)では、対象イテレーションで取り組む「ストーリー」を決定しますが、ここで取り扱う個々の「ストーリー」は、顧客に価値をもたらすシステムのフィーチャを表しているわけです。この辺り、アジャイル系のプランニングでは暗黙的に当たり前のものとして捉えてしまっていましたが、本書では「顧客に価値をもたらすフィーチャ(機能)を基本的な計画単位とするべき」と明確に記述してあります。

確かに、これはちゃんと説明しておくべき重要なポイントだったなぁと改めて認識することができました。

一般的にはフィーチャベースではなくて、作業(プロセス)を単位とした計画がよく作成されていると思われます。私自身が参画した開発プロジェクトでも殆どそうでした。

とはいえ、プロアクティブな計画重視という面からあんまりアジャイルっぽさが感じられないPMBOKの考え方でも、WBSはワークプロダクト(成果物)の観点からブレークダウンして作成するのが基本でした。作業/プロセス型(要件定義工程、基本設計工程などの大工程から段階的にプロセスをブレークダウンしていく形式)のWBSが推奨されているわけでは無いのですね。

作業には、「遅延しがち」「次の作業に遅れが波及しがち」「作業間に依存が生じがち」という性質があるため、計画の基本単位としては不安定と言えます。そういう面からも、より顧客へ直接的に価値をもたらすフィーチャに基づく計画を立てることが望ましいと考えられているわけです。
まあ、フィーチャを取り扱った方が、優先順位もより直接的に考えることができるようになりますしね。

本書ではFBS(Feature Breakdown Structure)というのを紹介していて、要はシステムが実現する機能ベースのWBSなのですが、そこから作成されるガントチャート上には、タスクの役割分担(リソースアサインメント)が記述されず、イテレーションより小さいスケジュールの線は引かれていないことが特徴的です。

フィーチャはチーム全体が責任を持つもの、イテレーションが完了するまでにフィーチャが完成している(仕掛というものは無い)というアジャイル開発の考え方が反映されたチャートだと思います。

望ましさによる優先順位付け

本書では、幾つかの方法でフィーチャの優先順位の付け方を提案していますが、面白いと思ったのはこの「望ましさによる優先順位」です。
これは、顧客から見た時に対象のフィーチャが以下のどれに当てはまるかを、アンケート等を通して考える方法です。

  • A:有って当然、無ければ不満な機能
  • B:有れば有る程嬉しさが線形に増す機能
  • C:無くても良いが、有れば魅力的に感じる機能

Aは言わば必須の機能なので、当然優先度が高くなります。Bは増やせば増やす程、プロダクトの価値が上がる機能なので、余裕があればどんどん作っていきたいところ。Cは、そのプロダクトの魅力と価値を高める、つまりプロダクトの価格を上げられる可能性を増す機能で、プロダクトの性格によっては優先度を上げて作りたいものでしょう。

例えば自社開発の製品であれば、Cの機能を積極的に作り込む方が市場競争力を高めることに繋がりますが、受託開発であれば、想定外の機能よりはBのように量を厚めに揃えられる機能が喜ばれる場合もあるでしょう。

この分類は、もともと狩野モデルと呼ばれる品質分類の考え方らしいのですが、モチベーション理論におけるハーズバーグの衛生要因と動機付け要因の考え方と似ていますね。職場の衛生は良く保たれていて当たり前、それによって現場のやる気が高まるわけでは無いものの、汚ければやる気は下がる、というアレです。影響を与えたりしたのでしょうか。

余談ですが、ハーズバーグの理論を知った際に個人的に面白かったのは、給与額が動機付け要因ではなく、衛生要因に分類されているということです。高い給料を貰っても、モチベーションを高める大きな効果には繋がらない、ということなのですね。良い生活にはすぐに慣れるということでしょうかね。とはいえ給料が安くなれば、モチベーションは下がる、と(強く納得してみたり)。
人間、高賃金でも詰まらない仕事よりは、低賃金でもやり甲斐のある仕事に就いた方が、よりシアワセだということでしょうか。高くなってほしいですけどねー私は…(誰にとも無く)。

閑話休題。
いずれにせよ、コストや価格だけでなく、顧客の要望をベースに優先順位を決めていく、という考え方は、やはり顧客への価値を重視するアジャイル開発の性格をよく表しているものだと思います。

バーンダウン棒グラフ

計画で決定された対象フィーチャをイテレーション中に作成していくわけですが、日々のストーリーポイントの消化状況をモニタリングするためにグラフにした物がバーンダウンチャートです。バーンダウンチャートは、一般的には右肩下がりの折れ線グラフとして描かれることが多いものです。
こういう奴ですね:

burndown chart

(追記)表ではX軸が「Iterations」になってますが、「日」になるのが普通ですよね…。プロダクトバックログ全体のバーンダウンなど、あくまでイメージということで;-)。

アジャイル開発では、顧客の要求が正確に分かってくるに従って、作るべきフィーチャが変更されたり追加されたりされ得ることを折り込んでいます。したがって、バーンダウン上で消化されてきたポイントも、フィーチャの追加が発生するなどによって増えてしまうことが起こり得ます。

上記のバーンダウンのイメージだと、3Itr目までは順調にフィーチャを消化しているのですが、4Itr目では新しいフィーチャが追加されたかしたせいで、その分のポイントが増えてしまったことを表しています。このように折れ線グラフでは、フィーチャが増えると単純にグラフが上向いて記述されます。
こうなると、メンバの作業ペースが増加分によってかき消されてしまい、メンバのポイント消化状況が一目では分からなくなってしまいます。

そこで、本書ではバーンダウンチャートに棒グラフを使う方法を紹介しています。
こんな感じです:

burndown bar chart

本書の棒グラフでは、フィーチャの追加等によるポイントの増加分は、バーの下に付け足されます。こう記述することによって、バーの長さが縮んでいく様を見ることで、日々のポイント消化状況が一目で分かるようになるわけです。

折れ線グラフと比較して慣れ辛い点があるようですが、誰から見ても「一目で分かる」という点が、情報共有を重視するアジャイルの考え方が反映されているな、と感じました。

この他にも、本書では様々なTipsやアジャイルに限定されない考え方(TOCと同じようなバッファの捉え方など)が分かり易く説明されているので、広く計画や見積りに関する考えを深める面でもオススメです。

Written by nen

June 22nd, 2009 at 9:00 P

2 Responses to '顧客にもたらす価値に着目 - 「アジャイルな見積りと計画づくり」'

Subscribe to comments with RSS or TrackBack to '顧客にもたらす価値に着目 - 「アジャイルな見積りと計画づくり」'.

  1. Appreciate you sharing, great blog post.Thanks Again. Really Cool. fbdgdkcekked

    Johnd121

    7 Oct 14 at %H:%M

  2. こんにちは私はそうです感謝私はあなたのブログのページを発見、私は本当にグーグルのための何か他のもの、とにかくのため顕著ポストとオールラウンド楽しいブログ(私もテーマ/&#12

Leave a Reply

You must be logged in to post a comment.