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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

かなり正確に開発スピードの予想ができるので、投資家に「それっていつごろリリース予定？」と聞かれても今の会社ではまーまー論理的に返答できているようだ。

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

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

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

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

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

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

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

個人が処理したタスク数を人事評価に結び付けない。

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

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

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