production.log

ピクスタ株式会社でエンジニアのマネージャーをやっている星直史のブログです。

スクラムのプランニングで見積もりと計画がうまくいかなかった時に参考になった本を紹介します

スクラム導入の目的の一つとして、進捗の可視化という点*1が挙げられたのですが、
うまく説明できなかったので、 「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
という本を読んだら、見積もり、計画、スケジューリング、他者への説明も以前よりはできるようになったので、
紹介しようと思います。

見積もりってどうやれば効果的なのだろう

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

まず、前書きの時点で震えるような言葉が書いていました。

アジャイル界隈に出かけていくと、私はいつも次のような質問を受ける。

  • 大規模チームの計画はどうやって立てれば良い?

  • イテレーションの長さはどれぐらいにすべき?

  • マネージャへの進捗報告はどうすれば?

  • ストーリーの優先順位づけの方法は?

  • プロジェクトの全体像をどう把握するのか?

ここに挙げたような疑問(と、その他多くの疑問)への見事な回答が本書だ。

読み終わってから思ったのが、「まさに、前書きに書かれていた通りだ」でした。

内容としては大きく下記のように構成されています。

  • (見積もりと計画においての)問題とゴール
  • 規模を見積もる
  • 価値のための計画づくり
  • スケジュールを立てる
  • ラッキングと情報共有
  • なぜアジャイルな計画づくりがうまくいくのか
  • ケーススタディ

計画と見積もりにフォーカスしているだけに、その内容はとても濃いです。
おそらく、スプリントを進めていると、ものすごく小さな疑問にぶつかると思います。
例えば、

  • 再見積もりはどのタイミングで行うか?
    • そもそも再見積もりして良いのか?
  • 部分的に完了した状態でスプリントが終わった場合は完了したストーリーポイントに加算するか?
  • 優先順位はどのようにつければ良いのか?
  • ユーザーストーリーは分割するのか?できるのか?
    • いつ分割するのか?
  • プランニング時に担当は決めるものなのか?
  • プランニング時に設計が始まっちゃうんだけで良いのか?
  • ベロシティにバッファは必要か?
    • どれくらい必要か?
  • バーンダウンチャートのうまい書き方はあるのか?
  • 個人のベロシティを計測したいのだが・・・

"プランニング"だけでも疑問を挙げ出せば切りがないのですが、
この本を読むと自分が感じた疑問は全て解決しました。

また、内容についても、深く書かれています。

なぜ必要なのか?いつ実行すべきか?実行すべきタイミングではないのはいつか?
誰が実行するのか?どう実行すれば良いのか?

それぞれ、明確に書かれており、疑問を残す余地がないほどです。

なぜ?の部分に関しては、学術的にも書かれていますので納得度も高いです。

優先度の決め方、知ってますか?

プロダクトオーナーは優先度を決める役割を担うわけですが、
優先度はどのように決めれば良いのでしょうか。

えいやで決めることもあれば、Aと比較してBは優先度は高いといった二分木探索的に決めるかもしれません。

この本では、優先度のつけ方についても詳細に書かれています。
ただ、その決め方がやや難解です。

具体的には下記項目を指標にします。

  • 金銭価値
  • コスト
  • 新しい知識を得られるか
  • リスク

収益を増加させることができるか、新しい収益を生むか、コストを抑えるか、業務効率化できるか、
実装にかかるコスト、理解するのにかかるコスト
ハイリスクのものから取り組むか、ローリスクのものから取り組みナレッジを積み上げるか
などが書かれています。

また、財務指標(内部収益率、回収期間、割引回収期間)を判断基準に用いるので、
より納得できる優先順位をつけることができると思いますし、
対外的にも納得感のある優先順位になると思います。*2

この本を買うべきだと思ったポイント

ポイントは2つあります。

1点目は、なんといっても見積もりと計画づくりにおいての網羅率と詳細度だと思います。
この本を読めば、切りが晴れたような感覚になると思います。
疑問点はなくなるでしょうし、納得感もあります。

また、"アジャイルな"と書いてありますが、見積もりと計画づくりを"アジャイルに"(「すばやい」「俊敏な」という意味)運ぶための本です。
本の中では、アジャイル開発中心として進められていますが、本を読んだ後振り返ると、
学んだことの肝は、ウォターフォール開発の中でも活きると思います。

2点目は、ソフトウェア開発(全体)についても学ぶことが多かった点です。
TDD, CI, ペアプロなど、技術者だけでアジャイルなプラクティスを回すことはできますが、
計画や見積もりなどといったビジネスサイドのプロセスがうまく回っていなければ、ソフトウェア開発がうまくいってると言えないと思います。

この本では、ビジネスサイド(計画や見積もり)のプラクティスを学び、技術とビジネスを調和を図るための一冊になると思います。

ビジネスサイドと技術サイドの人間は、決して相反するような関係であってはなりませんし、
互いに強調しながら価値のあるプロダクトを提供しなければならないと思います。
この本は、主にプラクティスについて書かれているのですが、それを実行するだけでは、"信頼のおける"見積もりと計画づくりにはできないと思います。
信頼のおける見積もりと計画づくりは、両サイドの人間が強調し合いながら、一つのプロダクトを磨くプロセスを共に歩んでこそ生まれるものなのだと学べます。

315ページ程度なのですが、1ページあたりの文字量と難しい言葉がやや多いので、気合を入れて読まないと挫折します。
(業務の合間にですが)気合を入れて読んだので、1週間程度で全て読む事ができました。

*1:要は、いつ終わるの?に答えられること

*2:とはいえ、だいぶパワーのいる作業なので、実際やれていない...orz