フィボナッチ工数見積は「完成させます！（徹夜で）」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法

今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます！」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。

プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。

だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには＊＊日を要する」なんてピタッと当てたためしがない。絶対にズレる。

エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな？誰だっけ、それ言ったの？オレじゃねーよ。お前だよ。おめーのその口が『今週中』って言ったんだよ。もう金曜の夜だぜ。どーすんの？どーすんだよ！」とツメてもプロジェクトは１歩も進まない。
逆に「エンジニア様、いつもコード書いていただいてありがとうございます！」と持ち上げても一緒。
ムチでしばいてもアメをぶら下げても、論理的根拠が無い限り工数見積なんてうまくいく訳がない。

こういうことを書くと「だからウォーターフォールはダメ。時代はアジャイルだよ」と言う人が居るけど、私が関わったプロジェクトは全てアジャイルだった。２週間ぐらいの小さな開発プロセスをぐるぐる回していくアレ。アジャイルであっても工数見積は必要だし、PMチームと開発チームの間の認識違いによる言い争いと、大幅な見積もり誤差は絶えなかった。

そこでフィボナッチ工数見積である。

フィボナッチ工数見積の方法

大前提として見積もりミーティングは開発者とPMチーム全員参加。ダラダラするとすごい時間の無駄なのでルーチン化してチャッチャと終わらせる。何度かやると「いつもやってることだし」となって２０分から３０分ぐらいで終わる。

【１】 実装したい機能をできるだけ細かい単位に切り出して、タスクチケットとして発行する
例：Twitter認証によるユーザー登録機能

【２】バックエンドもしくはフロントエンドなどのタグを付ける。バックエンドとフロントエンドの両方に実装が必要な場合はチケットを２つ用意して、それぞれのタグを付ける。
例：Twitter認証によるユーザー登録機能ーバックエンド、 Twitter認証によるユーザー登録機能ーフロントエンド

【３】全員でそれぞれのチケットに対しての必要工数をフィボナッチ数列でポイントを付ける
２、３、５、８、１３、２１の数列を使って、最も工数のかかりそうなチケットに２１ポイントを、最も少ない工数のチケットに２ポイントをつける。

【４】チケットを優先順位順に並べる。手順３で付けたポイント数とは別に「どれが先に実装されるべき機能か」を基準とした優先順位。

【５】優先順位の上位から最初の開発スプリント（２週間）で完了しそうな分量だけを取り出す。
チーム人数にもよるがだいたい１０から２０チケットとか。

【６】取り出したチケットを各担当者に割り振る。その後ひたすら開発する。

【７】バグフィックスが出るたびにチケットを発行し、そこにフィボナッチ数のポイントを見積もって付ける。

【８】２週間のスプリントが終わったら、終了したチケットの合計ポイントを数える。
そこで終わってないチケットとその担当者を批判しない。ただ数える。

【９】１に戻って同じ手順を繰り返す。２週間のスプリントが終わったら、また終了したチケットの合計ポイントを数える。

これを何度も繰り返すとそのチームが２週間で処理できる平均速度がポイント数で出る。これがまーまー正確な値になっている。どんなに気合いれて開発してもいきなり速度が２倍になったりしない。
またここで言う平均速度のポイント数とは１００ポイントとかの単位であり、決して１００人月という意味ではない。そのポイント数はチーム全員で上記の手順を踏んだ上での数値となる。「わがチームが見積もるわがチームの開発スピードポイントです」としか言いようがなく、これが驚くほど正確なのだ。

最初はこれがどれぐらい画期的なアイデアかは気づかなかったが、何度も実践するうちに分かってきたことがいくつかある。

工数を日数で表現しないからこそ出せる正確性

もしチケットに対して「１日でできる仕事だ」とか「３日はかかる仕事」というように日数で表すと、余計な邪念が入って不正確な見積もりになってしまう。見積もりのミーティングは正確性が最も重要なのにどうしてもエゴが入ってしまう。

エンジニアA「これは重いタスクですから４日はかかりますね」
エンジニアB「なに？４日？こんなの１日で十分だろ（オレならできるぜアピール）」
エンジニアA「いえいえ、このタスクの実装に＊＊も含んでいることを考慮に入れてますか？前回Bさんが似たような箇所を実装された時に４日以上かかってましたよ」
エンジニアB「は？テメー喧嘩売ってんのか？」
PM「まーまーそこはAさんもBさんも優秀なので１日でいいじゃないですか」
エンジニアA、B「はい。。。」

これを５とか１３という単位の無い数字にすることで余計な邪念を挟む余地が無くなる。単なるポイントであって単位が無いので他との相関で決めるしかなくなる。「あのタスクを５って言ったんなら、これはもうちょっと軽い目だから３かな？」という具合だ。しかもこの時点で誰が担当するかは割り振られてないので、前述のAとBのように「オレだったら１日でできるぜ」などと無駄なアピールをさせなくて住む。

フィボナッチで重いタスクの差を明確に

ポイント数にする場合に１、２、３、..８、９、１０と連続した数字ではなくフィボナッチ数列にしているのには理由がある。まず実務においてタスクの重さは指数関数的に伸びていくこと。軽量なタスクはそれほど差はないが重量なタスクにはモノによって大きな差が出ることはエンジニアなら経験則でご理解いただけるはず。
また重くなるにしたがって差を大きくすることでその差をより意識するように仕向けるため。軽いタスクの場合、２や３の差は小さく多少の誤差が出ても大きな影響は無い。見積もりの重要性は重いタスクほどにある。そこで「重いタスクを９かな？それとも１０かな？」とじっくり考えても９と１０の差は１でしかでなく、９と１０の差を意識するのが難しくなる。
ここをフィボナッチにすることで１３と２１の差はとても大きく、「あれが２１だったらこれは１３にすべきだろ」と、より明確に区別することが可能になる。

「完成させます！（徹夜で）」が無くなる

全員参加の見積もりミーティングから出された正確な開発スピードポイントは無茶苦茶な開発計画を制御してくれる。誰かがアレもコレも２週間以内にやれー！とやったとしても「いやいやこのポイント数を見てみ。平均速度の３倍だぜ。それ無理だから」と論理的に諭すことができる。「どうしてもその機能を今のスプリントに盛り込みたいんなら、他のコレとコレを削って」と言って、現実的な計画に修正できる。
また逆にエンジニアが「こんなにたくさんのタスクが２週間以内に完了できる訳ねーよ。無理無理！」と言ってきたとしても「いやいやこのポイント数を見てみ。いつもの平均速度と同じだし。なんで今回だけできねーってなるんだよ。雰囲気だけでモノ言ってんじゃねーよ」とこれまた論理的に諭すことができる。
論理が成り立つ手法は感覚的にしかモノを言わない奴をしっかり排除してくれるのだ。
こうして「完成させます！（徹夜で）」という無理ゲーが無くなり、より健康的な開発が可能になっていく。要はチームの開発スピードを全員が（論理的に！）把握しておくことの効果が絶大なのだ。

個人が処理したポイント数を人事評価に結び付けない。

これは重要。工数見積は全てプロジェクトの推進のためであって、人事評価のためにやっている訳ではない。ここに人事評価を結びつけると、ポイント稼ぎのためにやたら軽いタスクに重いポイント数を乗せて、またそのチケットを取り合ったりとロクなことが無い。

以上がフィボナッチ工数見積の概要。

なんか偉そうに紹介してしまったが、特にPM手法に詳しい訳でも専門知識がある訳でもない。全ては同僚のスペイン人プロジェクトマネージャーRの言ってることの受け売り。
Rのバイブルというか超おすすめの本としてAgile Estimating and Planningをいつも紹介されている。
私の意見としては「エンジニアがそんな本を読まなくてもいいように会社は君を雇ってるんじゃないの？」なのだが。とにかくおすすめらしい。

Agile Estimating and Planning (Robert C. Martin Series)

アマゾン.comのレビューでもやたら高評価なのできっといい本なのだろう。
日本語版ならこちら。

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

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com