読者です 読者をやめる 読者になる 読者になる

ハウテレビジョン開発者ブログ

『外資就活ドットコム』を日夜開発している技術陣がプログラミングネタ・業務改善ネタ・よしなしごとについて記していきます。

『アジャイルな見積もりと計画づくり』に学ぶ、良い見積もりと良い優先順位付けのやり方(前編)

エンジニアの祖山です。

ハウテレビジョンでは最近、スクラムによるアジャイル開発プロセスを導入しました。 バックログの作成、アジャイルな見積もり、デイリースクラム、ふりかえりなど、様々なツールやイベントを用いることで、

  • デイリースクラムで日々の進捗、困っていることを共有することで、エンジニア間の交流が活発になった
  • バックログを作成し共有することで、各機能の優先順位や納期が明確になった
  • 継続的なふりかえりにより、開発プロセスにおける問題点が放置されず、確実に解決されるようになった

などなど、様々なメリットを享受しています。

しかしながら銀の弾は存在しないため、全てがバラ色になったわけではありません。 最近我々の間で課題となっているのは主に、「 見積もり 」と「 優先順位付け 」についてです。

見積もりの難しさ

見積もりとは納期の見積もりのことです。 「アジャイルでは期間ではなく相対的なポイントで見積もる」という鉄の掟がありますが、とはいえ社内、あるいはお客様に対して「この機能はいついつまでにリリースする」と説明しなければなりません。

そして大抵の場合、見積もり通りには終わりません。そのため、納期をコミットメントする際には、想定している期間よりも余裕を持って伝える必要があるでしょう。 とはいえ、防御的になりすぎて必要以上に納期を遅らせるのも良くありません。

良い見積もり、良い納期のコミットメントをするにはどうすれば良いのでしょうか。

優先順位付けの難しさ

優先順位を付けなければ、開発のスケジュールは立てられません。 しかしながらこれも一筋縄では行きません。

あるフィーチャの重要性について、立場が異なれば当然意見も変わりますし、立場が同じであってもその人の特性、好みによって優先度は左右されるでしょう。 「事前によく話し合って決める」と言えば聞こえはいいですが、議論が紛糾した挙句何も決まらなかった、となっては本末転倒。

優先順位付けの良い指針、フレームワークはないのでしょうか。

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

こうした疑問を抱えながら社内をウロウロしていたところ、 社内図書館(?) でこんなものを発見しました。

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

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

  • 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
  • 出版社/メーカー: 毎日コミュニケーションズ
  • 発売日: 2009/01/29
  • メディア: 単行本(ソフトカバー)
  • 購入: 74人 クリック: 764回
  • この商品を含むブログ (223件) を見る

どんぴしゃなタイトルですね。

というわけで早速手に取り、通勤時間中に読んでみました。

この本はタイトルの通り、見積もりと計画づくりを中心とした、アジャイルプロジェクトの進め方のガイドです。 厚さの割に読みやすく、中身も濃いため是非読むことをおすすめするのですが、 我々の日々の課題にとって非常に重要なエッセンスが見つかったので、ここでご紹介したいと思います (ようやくここからが本題です)。

50%の見積もりと90%の見積もり

本書では、見積もりに対して感覚ではなく、根拠のあるバッファを設定した上で納期を決定する手段についていくつか紹介されていますが、その中で私の印象に残ったのは「50%の見積もりと90%の見積もり」です。

「これはいつまでの終わるの?」と聞かれた時に、「2週間ぐらいあれば終わると思います」という具合に、1つの数字で答えることが多いでしょう。 しかし実際はその数字通りではなく、それより早く完了したり、遅れてしまったりします。それは何故でしょうか。

それはもちろん、見積もった時には分からなかった、様々な不確定要素が存在するからです。

使おうとしていたライブラリが、想定通りの動作をしないかも知れません。 あるいはチームメンバーが病欠することもあるでしょう。 逆に、想定していたよりも技術的困難はなく、作業の割り込みも少なかったため想定より早く終わることもあります。

未来のことを正確に予言することはできません。 そのため我々は、見積もりの数字は1つであっても、その裏では考えられる限りの様々なケースを思い浮かべ、それぞれについて工数を出した上で、それらの平均を1つの数字として出力する、という作業を無意識のうちに行っています。

ですから本来は、見積もりの数字は1つではなく、確率分布でアウトプットすべきなのです。

f:id:fuyumi3:20140710210641p:plain

図はイメージです(Wikipediaからの引用)。本書で提示されているグラフはこれとは異なる確率分布ですが、まああくまでイメージということで。

我々が出す見積もりの数字は、上の図の頂点に当たります(グラフでは0になっていますが、実際はもちろん1週間や1ヶ月といった正の値です)。 この図では、予想通りの期間より短く完成する確率は50%、予定より長引いてしまう可能性も同じく50%です。

何か作業にかかる時間を見積もるときには、こうした背景があることを常に念頭に置いておきましょう。 見積もり通り、あるいは見積もり早く終わる確率は、たったの50%しかないのです。

話を戻します。「50%と90%」のお話です。

見積もる際には、「50%の確率で終わるだろう」という納期と「90%の確率で終わるだろう」という納期の両方を見積もりましょう。 良くも悪くもないフラットなケースと、最悪に近いケースです。

おそらく2週間で終わるだろうけど、余裕を持って4週間ぐらい。。。 」ではなく「 予定外のことがなければ2週間で終わりますが、想定外のことがあったとしても、9割の確率で4週間あれば終わります 」と考えるようにしましょう。 人に納期をコミットメントする時にも、可能であればこうした表現が使えると良いでしょう。 相手との関係性にもよりますが、理性的な相手であれば後者の表現の方が遥かに信頼感があります。

これは、あくまで見積もるテーマが1つの場合です。 もちろん、1つではなく複数のテーマをまとめて納期を出さなければならない場合もあります(実際はこちらも方が多いでしょう)。 この場合、それぞれのテーマについて90%の見積もりを出して、それを最大限の見積もりとして良いのでしょうか。 納期が過剰に長くなってしまう気がします。

このような場合についても良い方法が本書では解説されているのですが、ここでは省略します。 気になる方は書店へ行きましょう。

狩野モデルによる優先順位付け

さて、続いては優先順位付けに関する狩野モデルのご紹介なのですが、ここまでかなり長くなってしまったので、 続きは別記事とします。

最後に

アジャイルを取り入れることによって生産性が上がる、というのはよく聞く話ですが、実際の導入にはなかなか困難がつきまといます。

まず、覚えなければならないこと、受け入れなければならない価値観がたくさんあります。 弊社のような少人数のスタートアップなら「説得しなければならない頭の固い上司」なんてのはいませんので(笑)、導入にあたっての壁は比較的少ないのですが、 そうではない環境の人も多いでしょう。

しかしながら、エンジニアとして開発にできるだけ専念し、ストレスなく、できれば楽しく仕事するための現時点での最良の手法がアジャイルであることは間違いありません。 我々のやり方もまだまだ完全ではありません。ですが、 短いサイクルで改善のプロセスを回して成長し続ける というアジャイルの思想を守り、今後も前進すべく日々努力しています。

それでは、後編もお楽しみに。