見積もりって難しい。過小見積もりをやらかしたので省みる
9月半ばに新しい会社に入社して、初めてそこそこ大きめの機能をメインで実装することになり、そこで目一杯やらかしました。
やらかしたのは過小見積もりです。見積もりは完璧にできるわけはないし、完璧を目指してはいないのですが、今回は特にひどすぎました。
リアルタイムなツイートがこちら。
ちょうど今取り組んでいるスプリント(的なやつ)で自分史上最大の過小見積もりをやらかしてしまって、無茶苦茶悔しい
— ﾅｶﾞﾓﾄ (@ngmt83) October 11, 2019
要因はいくらか見えているのでブログに書く
省みるんだよ
雑に例えると「ストーリーポイントで8ポイントと見積もったにも関わらず、実際やってみたら34ポイント相当だった。」「予想の3倍以上労力がかかった。」という具合です。
さすがにこんなことを繰り返すのはまずいので何故これほどの過小見積もりが起こったか振り返り、原因・要因など心当たりをブログに残しておきます。*1
前提
私がいるチームは1ヶ月前は3名程度だったのが、今は5名程度*2になり、これからチーム開発するための態勢を整えていくという状況。 メンバー全員が1人で大抵のことをできる中、みんながやりやすいようにプロジェクトの進め方を手探り中。
メンバー構成は業務委託で協力してくれる人が複数人、複数社。正社員エンジニアが2名。*3 委託でコミットしてくれているメンバーはそれぞれ拠点があるため、複数拠点のリモートチーム状態。
見積もりはいくつか基準となるIssueがXポイントであると軽い共通認識を作った上で、実装担当者が取り組むIssueに相対的なポイント設定をする。 今はベロシティを厳密に追っているわけではない。
上記の前提で原因をざっくり技術面・メンタル面・他にわけて心当たりをあげます。
技術面
エンジニアリングの見積もりなので、当然ですが技術的な原因には心当たりがありました。以下のような原因が思い当たりました。
- 採用されている技術を正しく織り込めていない
- 類似実装部分の読み込みが足りない
- 基準となるIssueのXポイントをAさんのY時間に置き換えてしまう
採用されている技術を正しく織り込めていない
私は前職ではAngularを用いていわゆるSPAとAPIサーバという構成でアプリのフロントを実装していました。今関わっているサービスはサーバーサイドのフレームワークにフロントも含み、複雑でないJavaScriptで実装されています。*4
しかし、入社したてということもあってかIssueを見積もる際に私は 「(Angularだったら)これをああやってえいってやればいいから…5ポイントだな」 と誤った前提で見積もってしまいました。フロントの実装中に大変すぎると感じてやっとこの過ちに気づきました。
類似実装部分の読み込みが足りない
アプリの改善や機能追加では既存の機能で使っているモジュールやライブラリを転用できることがよくあります。私はドックフーディングを通してどんな機能がどの辺りにあるか概ね理解できているつもりでいました。そのため、見積もる際に 「既存の機能Aと似た実装でいいはずで、多分〜な感じだろうし、もし予想が外れても既存のコードみたらどうにでもなるっしょ！5ポイントだな」 と甘々な見積もりをしてしまいました。
似てるように感じても実際には違っていたり、追加機能のほうがより高度なライブラリの知識が必要だったり、膨らむことが多いです。類似実装の読み込みと実際に書いてみるのは大事です。
基準となるIssueのXポイントをAさんのY時間に置き換えてしまう
ストーリーポイントは工数ではありません。Issue同士の比較による相対見積もりです。これを理解していても油断すると勘違いしてしまいます。
「5ポイントのIssue XをAさんは半日で終わる。」という情報から無意識に「Aさんは10ポイント/日」と誤認してしまうと危険です。 半日で終えられるのはサーバーサイドで完結するIssueだけかもしれないし、仮にサーバーサイドについてAさんと私が同じような生産性だったとしても、フロントはそうではないはずです。
ポイントは工数ではなく、Issue間の相対見積もりでしかない。Issueの締め切りが心配な場合はポイントを設定した上で、実装方法・使用技術・自分の習熟度を加味して締め切りに間に合いそうか考えましょう。 「自分にとって時間がかかりそうな部分がある」程度の共有でも周りにとってはありがたいはずです。
メンタル面
自分の気の持ち方が見積もりを見直す機会を潰してしまったと感じたことがありました。以下のような考え方によくないところがあったと思います。
- できるかどうかじゃない、やるんだよ。履き違えたポジティブ
- このくらいはできるはず、活躍してやるぜ。期待に応えたがり
できるかどうかじゃない、やるんだよ。根性ポジティブ
過小見積もりに気づき始めた時、メンバーから「間に合いそうですか？」「大丈夫ですか？」「(期日までに)できますか？」*5といった声をかけられました。そんなとき私は、 「できるかどうかじゃない、やるんだよ」 と冗談半分に返していました。辛い辛い言いながらやるより、暗くならないし捗るからこうやって言うのですが、この言葉・考え方のせいでもっとよいリカバリの機会を逃していたのではないかと思います。 やるしかないことは楽しく、勢いよくやったほうがいいですが、もっと良いやり方があるはずのときにポジティブを履き違えた考え方をするのはもはや思考停止でした。
このくらいはできるはず、活躍してやるぜ。期待に応えたがり
人は第一印象で決まるとよく言われますが、仕事においては入社後すぐにインパクトを与えらえるとその後がとてもスムーズになるでしょう。 また、自身のキャリアが5年になり、リードエンジニアへとステップアップしたいと考えている私は焦りすぎていました。
その焦りが実力を過信させたかもしれないし、チームに入った直後に普段通りの成果をあげられないという普通のことを見落とさせたのかもしれません。活躍するつもりで今後もやっていきますけどね！
他
当たり前のことばかりな上にまとまりがないですが、ブレスト的にあげると次の通りです。
- 入社直後は予定が読みにくく(自分が忘れただけの場合もある)、開発にあてる時間が少なかったり変動する
- 環境が変わったあとリズムをつかむのには思いの外時間がかかる
- 得意な技術スタックでもローカルコーディングルールや採用したデザインパターンの差異はじわじわ効く*6
- リモートチームによって露呈する自分のコミュ力不足
環境を変えたらオーバーヘッドがあるのは当然だという話と、リモートワークではコミュニケーションがより重要になるという話です。
どう対策するのか？
対策は思いついてないです。あったらぜひ教えて欲しいです。仕組みには至らない気をつける程度であれば次の通り意識していきたいです。
- 実際に30分くらい手を動かして見積もる
- わからないかもしれない・時間がかかる可能性を早く共有する
- 認識できていない不慣れもあると考える
見積もりに少し時間を割くことでずれを小さくできます。また、早い共有で見積もりの更新やリカバリする機会を作れるかもしれません。わからなくなってから、時間がかかってから共有するよりも心理的ハードルが低いというのも良い点です。不慣れについては認識できないものもあります。認識できない不慣れが影響を及ぼしていることを理解していれば、差異がでたときも冷静に対応ができそうです。
最後に
完璧な見積もりはありえません。完璧がないからこそ、完璧に近づける努力をしていきましょう。
