見積もりで悩まないための３つの知見

この記事は、夏のアドベントカレンダーの3日目の記事です。

こんにちは、ウォンテッドリーでバックエンドエンジニアをしております平岡です。2025年3月に入社し、現在4ヶ月目を迎えました。普段はWantedly Visitのグロースチーム (User Growth Squad) で、日々プロダクトの課題解決に尽力しています。

今回のテーマは、多くのエンジニアが経験するであろう「見積もり」についてです。私自身、入社後の開発経験を通して得た3つの重要な学びをご紹介し、さらに見積もりというプロセスを通じてどのような成長機会が得られるのかについても深く掘り下げてお話しさせていただきます。見積もり業務に難しさや課題を感じているエンジニアの皆さんに、少しでも役立つ情報が届けば幸いです。

見積もりの定義
知見1：見積もりの目的によってやり方を変える
意思決定のための見積もりの場合
計画・実行のための見積もりの場合
知見2: 信頼性の期待値をコントロールする
知見3: チームで見積もる
見積もりを成長の機会に変える
おわりに

見積もりの定義

まずは、このブログで扱う「見積もり」という言葉の定義を明確にしたいと思います。

開発における「見積もり」とは、プロジェクトを進める上で必要となる時間、コスト、そしてリソースを予測するプロセスです。これは、現時点で既にある情報や、潜在的なリスクを分析した結果に基づいて、将来の成果物や活動を定量的に予測することを指します。

この「見積もり」と混同されやすい言葉として、「ターゲット」と「コミットメント」があります。それぞれの言葉の定義もここで整理しておきましょう。

ターゲット: ビジネス要請や戦略的目標から設定される、理想的な目標日や目標値のことを指します。これはあくまで目指すべき方向性を示すものであり、予測ではありません。
コミットメント: チームがその達成に合意し、達成を約束する成果物や目標のことです。これは見積もりとは異なり、責任を伴う約束となります。

これらの定義を踏まえた上で、私が実際の開発現場で経験から得た3つの知見をご紹介していきます。

知見1：見積もりの目的によってやり方を変える

見積もりは、その目的によってアプローチを変えた方が効果的です。大きく分けて2つのケースが考えられます。

意思決定のための見積もりの場合

例えば、半年から一年といった中長期的なスパンで開発ロードマップを作成したい、というよくあるケースを想定してみましょう。このような場合、個々のタスクの詳細な工数を厳密に見積もることは現実的ではありませんし、その必要もありません。この目的での見積もりでは、それぞれの施策が、

1週間で完了するのか？
1ヶ月を要するのか？
それとも3ヶ月以上かかる大規模なものなのか？
そもそも技術的に実現可能なのか？

といった、ざっくりとした観点で規模感を把握することが重要です。これにより、施策の優先順位を決めたり、全体的なプロジェクトの順序を最適化したりするために見積もりを行います。大まかながらも全体像を把握することで、戦略的な意思決定をサポートします。

計画・実行のための見積もりの場合

一方、具体的な開発プロジェクトとしてリリース予定日を決めることを目的とする場合は、より詳細な見積もりが求められます。この目的では、具体的な設計方針や、開発の進め方を深く検討していく必要があります。具体的には、以下の要素を考慮しながら予測の精度を上げていきます。

機能を細かく分割し、マイルストーンを設定する: 大規模なタスクを小さな単位に分解することで、見積もりの粒度を細かくし、見落としを減らします。
WBS (Work Breakdown Structure) を活用して予測の精度を上げる: WBSとは、プロジェクトの目標達成に必要な作業を細かく分解し、構造化して整理したものです。これにより、作業の漏れなく見積もることが可能になります。
不測の事態に備え、バッファーを確保する: どんなに詳細に見積もっても、予期せぬ問題は発生しえます。そのため、一定の余裕期間（バッファー）を事前に見積もりに組み込むことで、リスクを吸収し、計画の堅牢性を高めます。

これらの工程を経て、現実的かつ信頼性の高い開発期間を割り出すことができます。

知見2: 信頼性の期待値をコントロールする

見積もりはあくまで将来の予測であり、不確実性を伴います。見積もりに費やした時間の長さや、対象となるシステムの規模、複雑さによって、その正確性には限界があります。

そこで重要になるのが、「信頼性の期待値をコントロールする」という考え方です。見積もりを行う際に、「このタスクは2週間〜4週間かかる見込みです」といった幅を持たせた表現を用いることや、あるいはあらかじめチームや関係者間で取り決めた「不確実性倍率（※1）」のような信頼性に関する情報を含めてコミュニケーションをすることが非常に有効です。これにより、見積もりを受け取る側（伝え手）が抱く期待値を適切にコントロールし、後々の認識齟齬や不満を防ぐことができます。

（※1: 例の一つとして、「2週間 × 不確実性2倍」など。これは、ベースの工数が2週間で、不確実性が高いため最大でその2倍、つまり最悪4週間かかる可能性があることを意味します。）

このように、見積もりの結果だけでなく、その信頼性に関する情報も併せて伝えることで、より建設的な議論と協力関係を築くことができます。

知見3: チームで見積もる

Wantedly Visitは2012年からサービスが開始されており、現在ではシステムが大規模かつ複雑化しています。このような環境では、入社歴が浅いメンバーの場合、必要なドメイン知識の習得が追いついておらず、そもそも一人で見積もりを行うこと自体が非常に難しい場面が多くあります。

また、仮に自分一人で緻密に見積もったとしても、実際にその開発を担当するのが自分だけとは限りません。自分だけで見積もりが進められてしまうと、他のメンバーと協力して開発を進める際に、修正する範囲（スコープ）や設計の方針などに関する認識のずれが発生し、それがプロジェクトの遅延要因となる可能性があります。

このような事態を避けるためには、チームのメンバーと一緒に目線を合わせながら見積もりを進めることが不可欠です。チームで見積もることで、多様な視点や知識が持ち寄られ、見積もりの精度が飛躍的に高まります。その際、ホワイトボードやMiroのようなオンラインホワイトボードサービスを活用して議論の過程を整理していくと、チーム内での共通認識をより持ちやすくなります。見積もり段階でチーム全体の目線が合っていることは、その後の開発の効率を大きく向上させることにも繋がると期待できます。

見積もりを成長の機会に変える

最後に見積もりというプロセスに関わることで、私自身が得られたこと、そして皆さんが得られるであろう成長機会について、自身の経験を踏まえてお伝えしたいと思います。

見積もり自体は、ここまで説明してきた通り単なる「予測」に過ぎません。しかし、その「予測」は、プロジェクトの優先度判断や開発計画策定といった、より重要な「意思決定」の基礎として用いられます。

私自身の過去の経験を振り返ると、要件がまだ完全に定まり切っていない、まさに不確実性の高い状況においても、自ら一定の判断を下し、具体的な計画を立ててプロジェクトを進めていくという経験を数多く積むことができました。これにより、以前よりも規模の大きな仕事や、時には新規事業といった重要なプロジェクトに関わる機会をいただくことができました。

このように、ただ与えられたタスクをこなすだけでなく、自ら意思決定に深く関わる機会を持つことは、エンジニアとしての責任感と全体を見通す力を養い、個人の大きな成長に繋がると私は考えています。