銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

【技術書まとめ19】アジャイルな見積もりと計画づくり

毎週1冊技術書を読んでブログでアウトプットすることが目標で今回が第19弾です。

 

今回は アジャイルな見積もりと計画づくり を読みました。

アジャイル開発について詳しく解説をしている名著です。

 

アジャイルについて全く知識・経験がなかったですが考え方がとても合理的で面白かったです。

この記事を読めばアジャイルについての概要がつかめると思うので、興味ある方は是非読んでみてください。

今回は学ぶことが多かったので少し長めです。

f:id:ysk_pro:20190126103827p:plain

まえがき

  • アジャイル開発者の主張は次の通り。「私たちは今ここで分かっていることを元に計画を立てる。顧客にとって一番大切な目標を達成するために私たちは計画を変更する。プロジェクトが進んで新たな知識を得たら、それにプロジェクトと計画を適応させる。私たちから顧客への願いは、ビジネスの変化へ柔軟に適応することと当初の計画を死守するとことは矛盾した要求だと、きちんと理解してほしいということである」
  • 多くのプロジェクトマネジメント手法は「計画ー計画ー計画ー実行」であるのに対し、アジャイル手法は「計画ー実行ー適応」の繰り返しである。プロジェクトの不確実性が多ければ多いほど、成功するためにはアジャイル手法が必要となる
  • プロダクトマネージャやプロジェクトマネージャに、専門的スキルを持つ人の仕事の進め方と仕事内容を決定する権限を与えてしまうのは、ビジネス的自殺といってもよい
  • アジャイルな見積もりと計画づくりの手法が従来型の手法よりも効果的な理由は、価値を提供することとビジネスとプロジェクトチームの間に信頼関係を築くことに注力しているためである。どんなことにも透明性を保ち、いかなる変更でもビジネス側に伝えることで、ビジネス側も素早く適応し、最善の判断を下すことができる
 

第1部 問題とゴール

1章 計画の目的

  • プロジェクトが進むにつれて見積もりは正確になる。「不確実性コーン」によれば、初期のプロジェクト定義の段階では見積もりには60%から160%に及ぶ誤差が生じる
  • よい計画とは、ステークホルダーが信頼できる計画である。信頼できるとは、その計画を基にして意思決定できるということである
  • アジャイルな計画づくりを定義すると以下のようになる
    • 計画よりも計画づくりを重視する
    • 変化を促進する
    • 計画そのものは容易に変更できる
    • プロジェクト全体にわたって繰り返される
 

2章 なぜ計画づくりに失敗するのか

  • 仕事の量は、完成のために与えられている時間をすべて満たすまで膨張する。これはパーキンソンの法則と呼ばれており、私たちは作業完了までの期間が決まっていると、許される限りの時間をすべて使ってしまう
  • マルチタスク化は生産性に甚大な悪影響を与え、遅れを助長する。個人が3つ以上の作業を並行して進めると、価値を生み出す作業に使える時間が大幅に減少することが分かっている
  • 不確実性に対処する最善の方法は、繰り返すことである。プロダクトがどうあるべきかという不確実性を低減させるには、短いイテレーションで作業するとよい
 

3章 アジャイル手法

  • アジャイルチームの基本的な仕事の進め方
    • 1つのチームとして働く:すべてのプロジェクト参加者が、共通のゴールを持った1つのチームに参加している意識を持つ
    • ビジネス上の優先度を重視する
    • 検査と適応
  • プロジェクトというものは新たな機能と知識を生み出し続ける活動であり、単に決められた手順を実行するだけではない
  • アジャイルチームは3つのレベルで計画づくりをする
    • リリースプランニング:リリース全体についての計画であり、3ヶ月から6ヶ月という期間がよく使われる
    • 今日のプランニング:日々のスタンドアップミーティングでメンバーがその日に何をするか決めた1日単位の計画
  • プロダクトオーナーの満足条件を理解せずに、リリースプランニングとイテレーションプランニングはできない
 

第2部 規模を見積もる

4章 ストーリーポイントによる規模の見積もり

  • ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさを表す単位である。ストーリーポイントを使った見積もりでは、ひとまとまりの仕事に対してポイントをつける。ポイントの数値そのものは重要ではなく、他の作業との相対値が重要である
  • ストーリーポイントによる見積もりの始め方には2種類ある。これから取り組むストーリーの中で最も小さいと思えるものを基準としてそれを1ポイントとする方法と、中くらいと思えるストーリーを決めて、それに見積もりで使う数値範囲の中央に近い値をつける方法である
  • ベロシティとは、チームの進む速度を表す単位である。ベロシティの値は、チームが1回のイテレーションで完了させたユーザーストーリーのストーリーポイントの合計値である。チームが前回のイテレーションで10ストーリーポイント分の作業を完了させたのであれば、次のイテレーションでも10ストーリーポイント分の作業をこなせると予測できる
  • 必要なすべてのフィーチャのストーリーポイントの見積もりを合計すれば、プロジェクト全体の規模を見積もれる。また、チームのベロシティがわかれば、規模をベロシティで割ると必要なイテレーションの回数が見積もることができる。イテレーション数とは期間なので、カレンダーに当てはめればそれがスケジュールとなる
  • アジャイルな見積もりでは「規模を見積もり、期間は導出する」
  • プロジェクトが進捗するということはユーザーストーリーをこなしていくことなので、数イテレーションも実施すればチームのベロシティがわかってくる。ポイントによる見積もりの素晴らしい点は、ベロシティを適用することで計画時の見積もりミスが自動的に補正されることである
 

5章 理想日による見積もり

  • ユーザーストーリーの開発にかかる時間は、現実日で見積もるよりも理想日で見積もる方が簡単である。現実日による見積もりでは、ストーリーの完了までに起こりうる、あらゆる割り込みを考慮しなくてはならない。理想日による見積もりなら、ストーリーに必要な時間だけを検討すればよい
 

6章 見積もりの技法

  • わずかな時間で考えた見積もりと、長時間悩んだ末に出した見積もりがほとんど同じになるのはよくあることである。ある程度以上の労力を費やしても、見積もりの正確さには寄与しない
  • 見積もりはチーム全体で出した方がよいアジャイルプロジェクトでは誰がどの作業をするのか事前に分からないことが多く、作業を担当するメンバー以外の意見も参考にした方が良いため
  • 人は10倍以内のものならうまく見積もれるという研究結果がある。見積もりのスケールには「1, 2, 3, 5, 8」というフィボナッチ数列をよく用いる
  • プランニングポーカーは、専門家の意見、対比、分割の全てを組み合わせ、楽しみながら迅速かつ信頼できる見積もりを出すことができる。プランニングポーカーの参加者はチームの開発者全員である
    • まず最初に、全員に一組のカードを配り、そこにはチームで使用できる見積もりポイントが1枚につき1つずつ書かれている
    • 進行役となる人が、見積もり対象のユーザーストーリーやテーマを1つずつ読み上げ、見積もり担当者からの質問にはプロダクトオーナーが回答する
    • 見積もり担当者は、自分がこうだと思う見積もりポイントのカードを選ぶ。選んだカードは全員が選択し終えるまで人には見せないようにし、全員の見積もりが決定したら一斉にカードをオープンする
    • 人によって見積もりが大きく異なることは、見識の相違から学ぶチャンスである。高い見積もりを出した参加者と低い見積もりを出した参加者に、見積もりの根拠を説明してもらう。この時、見積もった人を非難しているように見えないよう留意する
    • 議論を終えたら、見積もり担当者はそれぞれ再び見積もりポイントカードを選んで、一斉にオープンする
    • 多くの場合、見積もりは第2ラウンドで収束するが、収束しなければここまでの手順を繰り返す。ゴールは、全員が合意することにある
  • プランニングポーカーがうまくいく理由
    • 複数の専門家の見解をまとめた見積もりを実現するため
    • 活発な対話を引き出すため。見積もりについて説明を求めると、情報の不足を補ったよりよい見積もりとなる
    • 個人の見積もりを平均した方がよりよい結果を残す傾向があるという研究結果があるため
    • 楽しいため
 

7章 再見積もり

  • 再見積もりが必要となるのは、ストーリーの相対的な規模に変化があったとチームが判断した時(例えば、あるシナリオだけがより時間を要すことがわかった場合など)である。あるストーリーが想定よりも長く時間を要したというだけでは再見積もりはしない
 

8章 ストーリーポイントと理想日

  • ストーリーポイントは純粋な大きさのみを測定する値だが、理想日はそうではない。開発者のスキルが変化すれば理想日の見積もりも変化してしまうが、ストーリーポイントではこうしたことは起きない
  • 理想日は人によって異なってしまうが、ストーリーポイントは人によって異なることはない
 

第3部 価値のための計画づくり

9章 テーマの優先順位づけ

  • 新しいフィーチャの優先順位づけに必要な4つの要素
    • フィーチャの金銭価値
    • フィーチャの開発(サポートも含む)にかかるコスト
    • フィーチャの開発を通じて学べる知識の量とその意義
    • フィーチャの開発によって低減できるリスク
  • 4つの要素を総合して優先順位をつけるとき、第一に考えるのはフィーチャの価値とそのフィーチャを開発するのにかかるコストである。コストに対して最も高い価値を持つテーマが、最初に着手すべきテーマとなる。さらに、他の優先順位づけの要素を検討してテーマの優先順位を上下する
 

10章 金銭価値による優先順位づけ

  • 財務的に分析することは優先順位づけに役立つ。利益と業務改善の効果を予想するのは2年先までが一般的である
  • キャッシュフローの評価には、正味現在価値、内部収益率、回収期間、割引回収期間の4つの指標を利用する
 

11章 「望ましさ」による優先順位づけ

  • 顧客満足度の狩野モデル
    • 当たり前、または必須のフィーチャ:フィーチャをどれだけ幅広く用意して、品質に磨きをかけても、当たり前のフィーチャであれば顧客満足度にほとんど影響を与えない
    • 線形、一元的なフィーチャ:あればあるほどよいもの。線形、一元的というのは、フィーチャの量に比例して顧客満足度が線形に高まることに由来する
    • 魅力的な、わくわくするフィーチャ:大きな満足をもたらしたり、わくわくする気持ちになったりするもの。このフィーチャは無いからといって顧客満足度が悪くなることはない。ユーザーは体験してみるまで、そうしたフィーチャが必要だということに気づかない
  • 当たり前のフィーチャを備えたら、線形のフィーチャをできるだけ多く完成させることを重視する。魅力的なフィーチャはこれらの機能を実装した後に、時間の許す範囲で対応する
  • ユーザーからアンケートを取ることで、フィーチャを簡単にカテゴリに分類することができる
 

12章 ユーザーストーリーの分割

  • 1つの大きなストーリーを見積もるよりも、分割して見積もった方が正確な見積もりになる
  • ユーザーストーリーを分割するタイミング
  • 大きなストーリーは、ストーリーで行う操作に沿って分割する。よくあるのは、CRUD操作を境界として分割することである
  • チームのイテレーション期間が2週間であれば、2日から5日で完了できる大きさにストーリーを分割するのが適切な大きさである
 

第4部 スケジュールを立てる

13章 リリース計画づくりの基本

  • 一般的には、3ヶ月から6ヶ月の周期でリリースを繰り返すことが多い
  • リリース計画は定期的な見直しと更新が必須である。多くのプロジェクトがイテレーション終了時点でリリース計画を見直すようにルールを定めている
 

14章 イテレーション計画づくり

  • イテレーションプランニングではタスクの担当者は決めない。タスクの担当者を決めるのは、イテレーションが始まってからである。また、一度に担当するタスクは1つであり、新しいタスクに着手するのは、前に担当したタスクを完了させてからである。イテレーションが始まる前に、全てのタスクの担当者を決めてしまうと、イテレーションのゴールに向かってチーム全員が一丸となって取り組むという参加意欲に水を差してしまう
  • アジャイルな計画づくりは二段階に分かれている。第一段階はリリース計画であり、この段階の計画は荒削りで全体的に不確定な部分が残っている。第二段階がイテレーション計画である。イテレーション計画は新しいイテレーションを始めるタイミングで実施するので、プロジェクトの中でチームが得た新しい知識を使ってリリース計画よりも詳細な計画を立てられる
  • リリース計画が3ヶ月から6ヶ月の期間を対象とするのに対し、イテレーション計画は1回のイテレーションだけを対象とする。リリース計画で扱う比較的大きなユーザーストーリーを、イテレーション計画ではタスクに分解する。ストーリーを分解したタスクは完了までの理想時間を単位として見積もる
  • イテレーション計画には、ユーザーストーリーをプロダクトに統合して動作させるために必要な全てのタスクを含めるべきである
  • タスクのサイズは、開発者が平均して1営業日に1つ完了できるくらいの大きさが適切である
 

15章 イテレーションの長さを決める

  • ほとんどのアジャイルチームは2週間から4週間のイテレーションを採用しているイテレーションの長さは、以下の要素を考慮して決めるのが良い
    • リリースまでの期間
    • 不確定要素の高さ
    • フィードバックの得やすさ
    • 優先順位が安定している期間
    • 外部からのフィードバックの必要性
    • イテレーションのオーバーヘッド
    • 切迫感を感じ始めるまでの時間
 

16章 ベロシティの見積もり

  • ベロシティの見積もり方法としての選択肢で望ましい順に以下がある
    • ベロシティの見積もりを出す前にイテレーションを1回でも実施できるなら迷わずそうする。実績値にまさる見積もりはない
    • 同じメンバーが携わった、今回のプロジェクトに関係のあるプロジェクトでの実績値を使う
  • どのやり方で見積もったにせよ、ベロシティの実績値を使えるようになったら、すぐそちらに切り替える
 

17章 不確実性に備えるバッファの計画

  • バッファの持たせ方でよく使われる方法は、フィーチャバッファとスケジュールバッファの2つである。
    • フィーチャバッファは、プロダクトに対する要求が優先順位づけされていて、その全てが必ず提供されるわけではないと合意できている場合に用意するバッファである。時間が足りなくなったときは、フィーチャバッファにあるフィーチャを削ることでスケジュールを守る
    • スケジュールバッファは、スケジュールに適用するバッファである
 

18章 複数チーム編成プロジェクトの計画づくり

  • アジャイルプロジェクトは、大規模なプロジェクトに対しては、1つのチームを大きくするのではなく、複数の少人数チームを編成することが多い。チーム間で共有できる見積もり基準の確立、ユーザーストーリーの早い段階での詳細化などが必要となる
 

第5部 トラッキングと情報共有

19章 リリース計画のモニタリング

  • リリースバーンダウンチャートは、各イテレーションの開始時点でプロジェクト全体としてストーリーポイントがどれだけ残っているか把握するためのもので、プロジェクトの完了見込みがいつになるかを教えてくれる非常に強力なツールである
 

20章 イテレーション計画のモニタリング

  • タスクボードは、どのタスクが作業中で、どのタスクがサインアップ待ちなのかが一目でわかるツールである。タスクボードの列にはそれぞれラベルをつけておき、作業の進行に応じて対応するタスクカードをチームメンバーが順番に右側の列に動かしていく
 

21章 計画とコミュニケーション

  • 見積もりと計画のコミュニケーションは、正直で頻繁な、双方向のものであるべきである。これはアジャイルな計画とは頻繁に更新されるものであり、フィードバックと新しい知識を繰り返し反映させることで洗練させていくためである
 

第6部 なぜアジャイルな計画づくりがうまくいくのか

  • アジャイルな見積もりと計画づくりのための12のガイドライン
    • 1. チーム全体を巻き込む:見積もりはチーム全体で出すなどチーム全体の参加とコミットメントを引き出す
    • 2. 複数レベルの計画を立てる:リリース計画、イテレーション計画、今日の計画それぞれに狙いがある
    • 3. 大きさの見積もりと期間の見積もりを区別するために別々の見積もり単位を使う:作業の大きさにはストーリーポイント、期間にはベロシティを使うとよい
    • 4. 不確実性はフィーチャか日付のいずれかで表現する
    • 5. 頻繁に計画を見直す:新しいイテレーションを始めるタイミングは、現在のリリース計画を見直すいい機会である
    • 6. 進捗をトラッキングして情報を共有する:プロジェクトの進捗をあらわす手段には、バーンダウンチャートなどの一目でわかるグラフを使うのがベスト
    • 7. 学習することの大切さを受け入れる:新しく得た知識があれば、必ずそれを計画にも反映する
    • 8. フィーチャは適切な大きさで計画する:数イテレーション以内の近い将来に開発予定の機能は、比較的小さなユーザーストーリーに分割する。ユーザーストーリーのサイズは1、2日から10日位までの大きさが一般的である
    • 9. フィーチャを優先順位づけする:フィーチャの価値とコストだけでなく、フィーチャから得られる知識と、フィーチャを開発することで軽減できるリスクも考慮に入れる
    • 10. 現実に即した見積もりと計画を立てる
    • 11. ゆとりを残す:メンバー全員の時間を100%使い切るような計画を立てない
    • 12. 複数チームの連携には「移動する先読み範囲」を使う:チーム間で依存関係が生じるフィーチャについては、ある程度先を見越して、あらかじめ実装するイテレーションを決めておく
 

おわりに

ここまで読んでいただきありがとうございます。
アジャイルの合理的な考え方に共感し、是非一度やってみたいなーという気持ちになりました。
本書では具体例を多く取り入れながら一つ一つ詳しく解説してくれているので、アジャイルに興味を持った方は是非読んでみてください。

次はデータベース設計についての本を読むつもりです。

来週も頑張ります!