新卒エンジニアが見積もりで失敗して学んだこと——精度を上げる4つの方法
概要
新卒でエンジニアとして働き始めて、苦労したことのひとつに「見積もり」があります。
インターンのときから「まずはちゃんと見積もれるエンジニアになろう」という目標はCTOとの1on1でも言われていたのですが、なかなかその理由までは理解できていませんでした。
しかし、実際に業務がはじまって少し長めの開発を任されるようになったときにその重要性を身を持って感じました。
単発のタスクではなく長期のタスクになると、開始前にスケジュールを引いてその進め方や進捗を都度開発チームやPMとすり合わせながら日々のタスク進行を行う必要があります。
見積もりをスケジューリングを行わず遅延させた新卒1年目のプロジェクト
自分が新卒で入社したマイベストにて任された最初の大きなプロジェクトが「商品のバリエーション掲出」というものになります。
プロジェクトの詳細は下記の記事でも書いたのですが、このときは既存の商品情報を送るエンドポイントの追加に加えて、新規に2つのエンドポイントを作成し。フロントエンド側で処理をしてデータを表示する必要がありました。 メンバーとしては自分と、フロントエンドエンジニア、そしてPMの3名で進行させたのですが、ざっくりそれぞれのタスクと初期のストーリーポイント見積もりは行ったものの、タスクの進行の進捗管理やスケジューリングは行っていませんでした。
【体験談】マイベストの新卒1期エンジニアが初年度を終えての経験と学び | Engineer
こんにちは!マイベストでバックエンドエンジニアをしています、井上です!大学院を卒業後、2021年4月に新卒でマイベストに入社して、現在社会人2年目になります。ここ最近では23卒でマイベスト志望の...
その結果として、いくつもの問題が起きてしまいました。
- フロントエンド側でAPIの開発待ちが発生した
- 現在どのタスクが進行中で、どの単位でリリースできるのかという認識が持ちづらくなった
- いつ終わるのか、どのくらい遅延しているのか伝えづらくなった
- リリース間際でコンフリクトが起きて予期していなかった工数が発生した
結果として機能のリリースを1ヶ月程度遅延させてしまうことになりました。 悔しかった自分は、この失敗をふりかえり、見積もりと計画づくりについて改めて勉強し直してまとめました。

見積もりについて完全に理解した
以下の勉強会で発表したLT「見積もりについて完全に理解した」の発表資料です。 【オンライン】エンジニア達の「〇〇完全に理解した」Talk #22 https://easy2.connpass.com/event/226964/ Twitter https://twitter.com/is…
現在こちらの記事を書いているのはそれから1年ちょっと後ですが、改めて復習の意味でもこちらの内容を都度補いながら書いていきたいと思います。
見積もりとは
見積もりとは、ざっくりとの検討をつけることです。 何か製品をつくるときにはその原価や日数、経費などを前もって計算することです。
上記のプロジェクトの例では、一体作業にどれくらいの工数がかかるのか。それは何人で行えるのか、リリースはいつになりそうかなどを手を動かし始める前に検討をつけておくことを意味します。
しかし、見積もりを正しく行うはとても難しく、『Clean Coder プロフェッショナルプログラマへの道』p.141にも下記のような記述があります。
見積もりとは、ソフトウェアのプロが直面する活動のなかで、最もシンプルだが最も恐ろしいものである。ビジネス価値の多くは見積もりにかかっている。我々の評判の多くは見積もりにかかっている。不安や失敗の多くは見積もりが原因である。ビジネスと開発者を分断してきたのは見積もりだ。両者の関係が不信感に満ちている原因も見積もりだ。
見積もりがなぜ大事なのか
そんなに大変な見積もりなのに、なぜ行う必要があるのか?おおきく4つの役割があります
リスクの低減
見積もりを行い、事前にこれから行われる作業内容や工程を一度頭の中でシミュレーションすることで、起こりそうな問題を発見できます。 結果として起こりそうなリスクに対して適切に事前に対策を行ったり、場合によってはそもそものプロジェクトを取りやめるなどもできます。
意思決定を支援できる
リスクの話と関連して、事前に調査や見積もりを行うことで得られた情報が、その後のプロジェクトの進行に対しての実施や順番ぎめの判断材料とすることができます。
不確実性を減らせる
また、結果としてこれからチームが進むべき方向や取り組んだ先にある成果物がイメージしやすくなるため、それを足がかかりとして不確実性をへらすことができます。
信頼を確立する
進捗として成果物が出せない場合でも、事前に取り決めた計画の進捗として開発の成果を供給していることを伝えれれば、開発チーム外に対しての信頼を担保できます。
「見積もり」という言葉の曖昧性
コミュニケーションのなかで無意識的に「見積もり」という言葉を使うことも多いですが、実は見積もりという言葉は人によって解釈が異なることがあります。 下記の記事にも詳しくありますが、見積もりの信頼精度を意識して、それが「コミットメント」なのか単なる「見立て」でよいのかなどを「見積もりをお願いします」というお願いをされた段階で認識を合わせておくことが大事です。

技術顧問との1on1で見積もりには3種類あることを教えてもらった - Qiita
はじめに 本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 ※公開するにあたって分かりやすさを重視...
見積もりがずれる原因
未来が遠すぎる
また、見積もりとは未来のことを事前に考える行為なので、当然ならが不確実性が多くあります。 遠い未来のことほど想像しづらく、近い未来は想像しやすいです。 見積もりの話をするときに有名な「不確実性コーン」というものがありますが、だいたいプロジェクトの初期には60〜160%のズレが生じますが、ステップ数が進んでいくほど見積もりの精度は上がっていきます。
最初に見積もったタスクについても、改めてプロジェクトが進行するにあたって「再見積もり」を行うことでその後のプロジェクトのスケジュールを正しく引くことに繋がります。

要件定義
また、開発を勧めていくにつれて、要件が変わることもあります。当然見積もりは事前に決めた要件をもとに算出されているため、要件が変わるとそのみつもりは変わります。
要件そのものが変わることはなくても、決めていた要件に考慮できていないケースがあったり、表現があいまいで固まっていないケースなどがあると、その結果として思ったよりも複雑な実装になり工数が増えるということもあります。
イレギュラーが発生する
スケジュールを見積もっても、だいたいの場合には正しくいきません。
- 障害が起きて対応しないといけない
- 外部サービスが落ちてしまい、予定通りの開発が行えなかった
- 開発者が体調を崩した
などなど、予期しないイレギュラー発生によって伸びてしまう(工数は変わらないけど工期が延びる)ようなケースもあります。
認知バイアス
また、人はだれしもバイアスを持っています。 想像よりも自分やチームの実力を過大評価してしまい、実際にかかる工数よりも小さく見積もってしまうということもあります。

心理学の手法で見積もりを改善する
バイアス、プライミング、サリアンスは見積もりの能力に影響を与える3つの代表的な心理要因だ。見積もりをしているときに心理的に何が起こっているのかを知ることは、これらの要因に対処して見積もりを改善するのに繋がる、と心理学の研究者であるJoseph Pelrine氏は言う。
見積もりを正しく行うためには
自分が新卒で入社したときには振られたタスクについて全くの検討がつなかったことが多かったのですが、だんだんと精度を上げることができました。 それは、自分の中で開発経験がたまり、その根拠をもとに新しいタスクの見積もりが行えるようになったことがあると思います。
しかし、そこで正しい見積もりができるためには、自分の中の開発経験の実際にかかった工数と作業内容がただしく記憶されていることが大事です。
最初の例では、新規で2つAPIを建てる必要があったときに、1つめで2日かかってのであれば、2つめのAPIを建てるときも2日程度かかることは予想できます。
タスクが終わったときに、そのタスクに対しての見積もりと実際にかかった工数を記録していき、その差分と原因を自分の中で修正していくことがよかったと思っています。
分割する
そのうえで、作業を細かくするのは振り返りの際に役立ちます。 「APIを建てる」というタスクを、Modelの実装、スキーマの実装、GraphQLの実装、などのように分割できるところまで文化値して、それぞれのタスクに対しての見積もりを出して、それぞれの作業に対しての見積もりを行うようにします。
結果として、次に振られるタスクがModelの修正だけで済むのであれば今回のAPIの実装の経験を生かして正しく見積もることができます。
さらには、小さいタスクのほうが見積もりがしやすいので結果的に正しくなりやすいという副次的な効果もあります。 小さく分割したタスクのうち、やったことがないものやよくわからないものから着手して、なるべく不確実なものをなくしていくのも大事です。
調査の時間をつくる
「どのくらいかかりますか?」という質問に対してすぐに答えたくなりますが、上でも書いたように「コミットメント」を求められている可能性もあります。
そのようなときには、ちゃんと調査する時間をもらって正しく見積もることも大事です。
- 技術調査する
- 詳しそうな人に見積もってもらい参考にする
- 作ってみる(プロトタイピング)
これらの手法は一例ですが、それぞれ有効なので、この見積もりの時間を見積もって、要求してもらうという手があります。 実装してから見積もりの差分に気づくことの手戻りよりも、事前に不確実なことを発見するときの計画の作り直しのほうが失うものが少ないです。
単一の視点で見積もりをしない
他の人と一緒に見積もりをしたり、「楽観的」「悲観的」などの視点を加えてその見積もり結果をもとに見積もりをすることも見積もり精度を上げることに繋がります。 このあたりは参考書籍にもあるので、興味がある方はぜひ読んでみてください。
まとめ
見積もりは経験が積み重なるにつれて精度が上がります。大切なのは、タスクが終わったときに「見積もりと実績の差分」を記録して自分の中で修正し続けることです。
「守れる約束をして、それを果たす」——当たり前のことですが、それができるエンジニアは確実に信頼されます。
新卒エンジニアの成長に関連した記事もあわせてどうぞ。
参考
www.amazon.co.jp/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%…
www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%…

約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな?」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない?もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあん…
記事の更新をメールで受け取る
質問・リクエストを送る
記事についての質問や、取り上げてほしいテーマがあればお気軽にどうぞ。いただいた質問はブログ記事として回答し、Q&Aページで公開することがあります。