以前に『プロジェクトマネジメントの基本が全部わかる本』の記事に書きましたが、長期的なプロジェクトマネジメントをあまりやってこなかったため、本を読みながら日々の業務で活かすようにしています。最近はデータ基盤のチームリーダー兼プロジェクトリーダーとして全社横断データ基盤を社内に活用していくために日々奮闘しています。
最近、プロジェクトの中長期的計画を立てることに悩んでおり、その助けとなることを期待して『アジャイルな見積りと計画づくり』を読んでみました。
毎日コミュニケーションズ (2009-01-29T00:00:01Z)
￥2,506 (中古品)
部構成
本書は7部構成、23章から構成されています。
第1部 問題とゴール
第2部 規模を見積もる
第3部 価値のための計画づくり
第4部 スケジュールをたてる
第5部 トラッキングと情報共有
第6部 なぜアジャイルな計画づくりがうまくいくのか
第7部 ケーススタディ
第6部（22章）が第1部から第5部までのまとめであり、各章のポイントを拾っているため、全体像をざっくり掴みたい人は第6部（22章）から読むと良い。
いくつか印象に残ったことを書いていきます。
アジャイルな計画づくりとは
本書では、アジャイルな計画づくりを以下に定義しています。
- 計画よりも計画づくりを重視する
- 変化を促進する
- 計画そのものは容易に変更できる
- プロジェクト全体にわたって繰り返される
多くのプロジェクトマネジメントは 「計画－計画－計画－実行」 の流れをとります。何をつくるのかについての不確実性をできるかぎり除去してから、どうやってつくるのかについての不確実性に対処する方式です。
一方で、アジャイルは 「計画－実行－適応」 を繰り返します。何をつくるのかが不確実であり、プロジェクト初期にすべて不確実性をすべて排除できないという前提に立っています。なのでプロダクトの一部を開発したら、それを顧客に見せて、そこからフィードバックをもらい、計画を修正していくというスタイルをとります。
不確実性を表すものとして、不確実性コーンというものがあります。
簡単に説明すると、プロジェクト初期は不確実性が最も高く、見積もりの幅（=ズレ）も最も大きくなります。その後、プロジェクトが進むにつれて不確実性が減っていき、見積もりの精度が上がっていくという考え方です。
要件がある程度固まっているプロジェクトならまだしも、ざっくりとしか決まっていない段階でのプロジェクト計画はかなり不確実性が高い状態であり、その時点で正確な見積もりを出すことはかなり困難といえます。アジャイルな計画づくりでは、不確実性があることを認識したうえで、顧客にとって重要な機能を少しずつ実装してはフィードバックをもらうことで計画を修正していくことで最短・最小リスクで顧客にとって欲しいものを提供するといった方法となります。
作業を基準にするのではなく、フィーチャ（機能）を基準とした計画にする
スケジュールをひいていくときに作業（タスク）を基準としてしまいがちです。例えば、DB設計、UI設計、ログイン機能の実装、ユーザー管理機能の実装といったものが挙げられます。
本書では、作業を基準とした計画はスケジュールから以下の理由により、遅延しやすいと述べています。
- 作業は早くおわらない
- パーキンソンの法則
- 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
- 私たちは作業完了までの期間が決まっていると、許される限りの時間をすべて使ってしまう
- パーキンソンの法則
- スケジュールの遅れは先へと伝わる
- ガントチャートだとなにかあったら後の工程も遅れる
- 作業は独立していない
- 先の例では、DB設計が終わらないと、ログイン機能やユーザー管理機能の実装に取りかかれない
また、顧客からすればその作業自体に何の価値もないわけです。フィーチャ（顧客の視点から見たシステムの機能や特徴）を顧客にとっての価値の単位として、フィーチャ単位で計画づくりをすべきと説いています。アジャイルではフィーチャの概要をユーザーストーリーという形で記述して計画づくりをします。
テンプレート：<ユーザーの種類>として、<機能や性能>がほしい。それは<ビジネス価値>のためだ
例：本の購入者として、ISBNで本を検索したい。それは探している本をすばやく見つけるためだ
規模を見積もる
アジャイルをかじったことがある人なら、ユーザーストーリーにストーリーポイントというのをプロジェクトメンバー全員で数字付けをし、1イテレーション（固定期間、タイムボックス）で消費できるポイント数をベロシティ（速度）として計測することで開発期間を見積もれると見聞きしたことがあると思います。
私は今までどうやってリリースできるまでの期間を見積もるのかが理解できずにいました。ストーリーポイントをつけるんじゃなくて見積もり時間で見積もったほうがいいんじゃない？と思っていました。
これに対する答えは第2部「規模を見積もる」に書いていたので一部引用します。
アジャイルチームは、 規模の見積りと期間の見積りとを分けて考える。
この違いを理解するために、これから私が庭の端にある一山の土を、庭の反対側の端まで運ぶことになったとしよう。 この作業に 5時間かかると見積もる。ここで 5時間という見積りを出すのに、私は規模の見積りをせずに、いきなり時間を見積もった。
今度は、まず規模の見積りから始めてみるとしよう。山の寸法から考えて、私は土の量を 300立方フィートと見積もった。
これが、このプロジェクトの規模の見積りだ。しかしこの場合、規模だけ見積もっても役には立たない。規模の見積り（300立方フィート）を、期間の見積りに変換しなくてはならないからだ。
私の手押し車のラベルには、積載容量が6立方フィートと書いてある。300立方フィートを 6立方フィートで割れば、この手押し車で 50往復ですべての土を運べることがわかる。
次に、1回の往復にかかる時間を見積もる。土を積み込むのに 3分。庭の端から端まで手押し車で運んで土を降ろすのに2分。空の手押し車を押して戻るのに1分。
合計すると、1往復にかかる時間は 6分という見積りになった。全部で 50往復する予定だから、期間の見積りは 300分、すなわち 5時間だ。
アジャイルな見積りと計画づくり P.59
アジャイルにおいて、ストーリーポイントがユーザーストーリーやフィーチャにおける作業の大きさ（規模）を表しています。そして、ストーリーポイントの合計がプロジェクト全体の規模を表すことになります。そして、1イテレーションでこなせるポイント数（ベロシティ）がわかれば、ストーリーポイントの合計値をベロシティ数値で割って、1イテレーションの期間を掛けたものが開発期間となるわけです。
ストーリーポイントの数字自体は重要ではなく、他の作業との相対値となります。例えば、機能Aを開発するストーリーを1ポイントだとして、機能Bを開発するストーリーを見積もる場合に、機能Aを開発する場合とざっくり比べて相対化した数字を入れます（3倍時間がかかりそうだとおもったら3ポイントといった具合）。
なぜ、ポイントという数字で見積もるのかというと、チーム全員で見積もる必要があるからです。ベテラン、新人関係なく、その機能を開発する人ではないテスターやQAといったメンバーも見積もりに加わります。時間単位の見積もりにしてしまうと、人によって開発実装する時間がバラバラになり、チーム全員で合意を得ることが難しくなります。その点、ポイントによる相対値だと、要する時間の差異はあれど、規模の相対化はある程度チーム内で合意を得やすいです。
では、時間見積もりをまったくしないかというとそうではなく、イテレーションプランニングという過程でユーザーストーリーをタスクに分解した際、タスク単位で時間見積もりをしていきます。
プランニング（計画づくり）
アジャイルプロジェクトでは、リリースプランニング、イテレーションプランニング、デイリープランニングというレベルに応じて計画づくりをしていきます。
リリースプランニング
- リリース全体についての計画であり、リリース計画はチームがプロジェクトを進めていく道しるべとなる
- 期間は3ヶ月から6ヶ月がよく使われる
イテレーションプランニング
- リリースプランニングを元に、イテレーションの開始時におこなう計画づくりのこと
- 直前のイテレーションで達成した内容に応じて、プロダクトオーナーは新しいイテレーションで達成すべき、優先度の高い作業を決定する
- ユーザーストーリーをタスクに分解して、タスク単位で時間見積もりをする
デイリープランニング
- いわゆる朝会。その日に取り組むこと、困っていることを長くても15分以内で終わらせる
- 3種類のプランニングの中で最も見積もりの精度が高い（その日にやることなので時間見積もりがしやすい）
価値のための計画づくり
顧客にとって価値が高いものから開発していくのがアジャイル手法であるが、「顧客にとって価値のあるもの」とはなんだろうか。それをどうやって優先順位付けすればいいのだろうか。本書では金銭価値やリスクによる優先度順位付けを紹介していますが、もう一つ、ユーザーの視点で見た望ましさで優先度をつける手法が紹介されています。
- 顧客満足度の狩野モデル
- 以下の3つのカテゴリに分類する
- 当たり前、または必須のフィーチャ
- 線形、 一元的なフィーチャ
- 魅力的な、 わくわくするフィーチャ
- 相対的重み付け
- チーム全員でフィーチャのそれぞれについて、実装することで得られる利点と、実装しないことで被る悪影響を評価する
私のデータ基盤チームでは、テスト導入として相対的重み付けを使った優先度順位付けをするようにしています。チーム全員で評価するために、各フィーチャの詳細を知る必要があり、実装することで得られる利点と、実装しないことで被る悪影響についてを議論して理解を深めることができていると感じています。
まとめ
中長期的なプロジェクトにおいて時間見積もりや計画づくりが難しく感じたため、『アジャイルな見積りと計画づくり』を読みました。読む前に疑問だったアジャイルにおける期間の見積もりについて規模の見積りと期間の見積りとを分けて考えるというのは目から鱗でした。本書に書かれていることをすべて実践するには時間的制約で難しく、まずは相対的重み付けによる優先順位付けをするところから実践しています。チームメンバーが増えたのでアジャイルを本格的にやっていこうと思っているので本書に書かれているプランニングを参考にしていきたいと思います。
