日本→シンガポール→ベルリンへと流れ着いたソフトウェアエンジニアのブログこの広告は、90日以上更新していないブログに表示しています。Tweet今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます!」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには**日を要する」なんてピタッと当てたためしがない。エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな?誰だっけ、それ言ったの?オレじゃねーよ。おめーのその口が『今週中』って言ったんだよ。すんの?どーすんだよ!」とツメてもプロジェクトは1歩も進まない。逆に「エンジニア様、いつもコード書いていただいてありがとうございます!」と持ち上げても一緒。ムチでしばいてもアメをぶら下げても、論理的根拠が無い限り工数見積なんてうまくいく訳がない。いうことを書くと「だからウォーターフォールはダメ。時代はアジャイルだよ」と言う人が居るけど、私が関わったプロジェクトは全てアジャイルだった。2週間ぐらいの小さな開発プロセスをぐるぐる回していくアレ。アジャイルであっても工数見積は必要だし、PMチームと開発チームの間の認識違いによる言い争いと、大幅な見積もり誤差は絶えなかった。そこでフィボナッチ工数見積である。大前提として見積もりミーティングは開発者とPMチーム全員参加。するとすごい時間の無駄なのでルーチン化してチャッチャと終わらせる。何度かやると「いつもやってることだし」となって20分から30分ぐらいで終わる。【2】バックエンドもしくはフロントエンドなどのタグを付ける。バックエンドとフロントエンドの両方に実装が必要な場合はチケットを2つ用意して、それぞれのタグを付ける。Twitter認証によるユーザー登録機能ーフロントエンド【3】全員でそれぞれのチケットに対しての必要工数をフィボナッチ数列でポイントを付ける2、3、5、8、13、21の数列を使って、最も工数のかかりそうなチケットに21ポイントを、最も少ない工数のチケットに2ポイントをつける。【4】チケットを優先順位順に並べる。手順3で付けたポイント数とは別に「どれが先に実装されるべき機能か」を基準とした優先順位。【5】優先順位の上位から最初の開発スプリント(2週間)で完了しそうな分量だけを取り出す。チーム人数にもよるがだいたい10から20チケットとか。【6】取り出したチケットを各担当者に割り振る。その後ひたすら開発する。【7】バグフィックスが出るたびにチケットを発行し、そこにフィボナッチ数のポイントを見積もって付ける。【8】2週間のスプリントが終わったら、終了したチケットの合計ポイントを数える。そこで終わってないチケットとその担当者を批判しない。【9】1に戻って同じ手順を繰り返す。2週間のスプリントが終わったら、また終了したチケットの合計ポイントを数える。これを何度も繰り返すとそのチームが2週間で処理できる平均速度がポイント数で出る。これがまーまー正確な値になっている。どんなに気合いれて開発してもいきなり速度が2倍になったりしない。ここで言う平均速度のポイント数とは100ポイントとかの単位であり、決して100人月という意味ではない。そのポイント数はチーム全員で上記の手順を踏んだ上での数値となる。「わがチームが見積もるわがチームの開発スピードポイントです」としか言いようがなく、これが驚くほど正確なのだ。最初はこれがどれぐらい画期的なアイデアかは気づかなかったが、何度も実践するうちに分かってきたことがいくつかある。工数を日数で表現しないからこそ出せる正確性もしチケットに対して「1日でできる仕事だ」とか「3日はかかる仕事」というように日数で表すと、余計な邪念が入って不正確な見積もりになってしまう。見積もりのミーティングは正確性が最も重要なのにどうしてもエゴが入ってしまう。エンジニアA「これは重いタスクですから4日はかかりますね」エンジニアB「なに?4日?こんなの1日で十分だろ(オレならできるぜアピール)」エンジニアA「いえいえ、このタスクの実装に**も含んでいることを考慮に入れてますか?前回Bさんが似たような箇所を実装された時に4日以上かかってましたよ」エンジニアB「は?テメー喧嘩売ってんのか?」PM「まーまーそこはAさんもBさんも優秀なので1日でいいじゃないですか」エンジニアA、B「はい。」これを5とか13という単位の無い数字にすることで余計な邪念を挟む余地が無くなる。単なるポイントであって単位が無いので他との相関で決めるしかなくなる。「あのタスクを5って言ったんなら、これはもうちょっと軽い目だから3かな?」という具合だ。この時点で誰が担当するかは割り振られてないので、前述のAとBのように「オレだったら1日でできるぜ」などと無駄なアピールをさせなくて住む。フィボナッチで重いタスクの差を明確にポイント数にする場合に1、2、3、..8、9、10と連続した数字ではなくフィボナッチ数列にしているのには理由がある。実務においてタスクの重さは指数関数的に伸びていくこと。軽量なタスクはそれほど差はないが重量なタスクにはモノによって大きな差が出ることはエンジニアなら経験則でご理解いただけるはず。重くなるにしたがって差を大きくすることでその差をより意識するように仕向けるため。軽いタスクの場合、2や3の差は小さく多少の誤差が出ても大きな影響は無い。見積もりの重要性は重いタスクほどにある。そこで「重いタスクを9かな?それとも10かな?」とじっくり考えても9と10の差は1でしかでなく、9と10の差を意識するのが難しくなる。ここをフィボナッチにすることで13と21の差はとても大きく、「あれが21だったらこれは13にすべきだろ」と、より明確に区別することが可能になる。「完成させます!(徹夜で)」が無くなる全員参加の見積もりミーティングから出された正確な開発スピードポイントは無茶苦茶な開発計画を制御してくれる。誰かがアレもコレも2週間以内にやれー!とやったとしても「いやいやこのポイント数を見てみ。それ無理だから」と論理的に諭すことができる。「どうしてもその機能を今のスプリントに盛り込みたいんなら、他のコレとコレを削って」と言って、現実的な計画に修正できる。逆にエンジニアが「こんなにたくさんのタスクが2週間以内に完了できる訳ねーよ。無理無理!」と言ってきたとしても「いやいやこのポイント数を見てみ。いつもの平均速度と同じだし。なんで今回だけできねーってなるんだよ。雰囲気だけでモノ言ってんじゃねーよ」とこれまた論理的に諭すことができる。論理が成り立つ手法は感覚的にしかモノを言わない奴をしっかり排除してくれるのだ。して「完成させます!(徹夜で)」という無理ゲーが無くなり、より健康的な開発が可能になっていく。要はチームの開発スピードを全員が(論理的に!)把握しておくことの効果が絶大なのだ。個人が処理したポイント数を人事評価に結び付けない。工数見積は全てプロジェクトの推進のためであって、人事評価のためにやっている訳ではない。ここに人事評価を結びつけると、ポイント稼ぎのためにやたら軽いタスクに重いポイント数を乗せて、またそのチケットを取り合ったりとロクなことが無い。以上がフィボナッチ工数見積の概要。なんか偉そうに紹介してしまったが、特にPM手法に詳しい訳でも専門知識がある訳でもない。全ては同僚のスペイン人プロジェクトマネージャーRの言ってることの受け売り。Planningをいつも紹介されている。私の意見としては「エンジニアがそんな本を読まなくてもいいように会社は君を雇ってるんじゃないの?」なのだが。見るアマゾン.comのレビューでもやたら高評価なのできっといい本なのだろう。EntriesブログをGatsbyの独自ドメインに移行しました「ウェブサービスで1発当てる」なんて言ってないで、誰かを笑顔にするサービス作りに専念する目標にお金を賭けて楽しく達成するウェブサイトを作った。その開発経緯とか有名レストランである映画監督と出逢い、自信がいかに大切で今の私にはそれが無いことを痛感したプッとくる名言サイトを作った「プログラミングはセックスのようなもの。レビューズがじわじわキテるので経過報告はてなブログにある映画の感想を人工知能で集めてウェブサイトを作ったProfileid:tango_ruby日本→シンガポール→ベルリンへと流れ着き、現在ベルリンのIT系スタートアップで働くソフトウェアエンジニア(妻と娘2人持ち、イボ痔持ち)海外転職のメール相談の回答がわりと時間割かれてつらかったので有料化しました。詳しくはAboutページをご確認ください。