0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

見積もり、難しくないですか? 失敗から学ぶ、見えない工数の見つけ方

Posted at

はじめに

皆さん、見積もりは得意ですか?

私はあまり得意ではありません。閉店間際のスーパーで売れ残りのアボカドを選ぶのと同じくらい苦手です。

「この画面と機能の実装工数はどれくらいになりそうですか?」と開発の初期段階でよく聞かれます。
その場で簡単に答えてしまい、後から全く足りないことに気づいて顔が青ざめる。
そんな経験をしたことがある方も多いのではないでしょうか。

今回は、僕の失敗体験を交えて、システム見積もりをする際に意識すべきだったなと思うことを書いていこうと思います。

失敗1: 目で見えるものだけで考えて見積もりをした

以前、あるWebアプリケーションの実装工数を見積もった時のことです。
デザインはFigmaで綺麗に出来上がっていて、「UIはシンプルだし、複雑な動きもない。まあ、この規模感ならすぐ終わるだろう」と算出しました。

しかし、蓋を開けてみるとこれが結構大変でした。

状況

  • フロントエンド:自社担当(自分たち)
  • バックエンド(API):外部のベンダーが担当

何が起きたか

「見た目を整える(マークアップやスタイル)」ことに関しては、予想通りのコストで済みました。
しかし、画面を動かすためのロジックやAPI連携において、予期せぬコストが発生しました。

これらのコストの原因は、API仕様書が未完成であったり、機能要件が十分に固まっていなかったことにあります。
その結果、「このパターンのときはどのような挙動が正しいのか?」といった確認事項が多く発生し、それらのすり合わせに非常に多くの時間を要しました。

学んだこと

目に見えるUIだけでなく、その裏側にある「不確定要素(特に他社連携)」をどれだけシビアに見積もれるかが重要だなと思いました。

  • 仕様書の有無と品質を確認する
    • 仕様書はフィックスしているか?
    • 未確定な場合、相手のレスポンス速度はどれくらいか?(ここ重要です)
  • 「質問タイム」を工数に積む
    • 仕様が未確定な場合、チャットやMTGでの質疑応答(ラリー)が必ず発生します。
    • これにかかる時間は「実装作業」ではありませんが、プロジェクトの「期間」には確実に含まれます。
  • 基本は悲観的に
    • デザインからロジックが100%明白な場合(LPとか)のみ、少し楽観的になっても良いかもしれません。
    • 基本は「何か起きる」前提でバッファを積んでおくべきでした。

失敗2: 自分が実装すると決まっていないのに、自分基準で工数を考えた

これはPMやリードエンジニア的な立ち位置でやりがちなミスなのかなと思います。
「この機能なら、あのライブラリを使えばサクッと終わるな」と、自分のスキルセット基準で見積もりました。

しかし、実際にプロジェクトが始まってみると、実装担当になったのは経験の浅いジュニアメンバーでした。

何が起きたか

実装速度は人によって異なります(当たり前体操)
しかし、それ以上に誤算だったのは「レビューコスト」でした。

昨今の「生成AI開発」ならではの落とし穴

最近は Claude Code や Cursor などを使ってコードを書くのが当たり前になりましたよね。
これにより、経験が浅いメンバーでも動くコードを爆速で大量に生産できるようになっています。

しかし、適切な設計や制御がない生成コードは、一見動作していても、保守性が低く、不要な記述が含まれがちです。

実装者🐣 :「AIのおかげですぐ書けました!」(大量のコードをPR)
レビュアー👴:「……(これを全部読み解いて修正指示を出すのか)」

生成AI時代において、個々人がプロンプトを適切に制御できなければ、膨大な量のコードを押し付けられる事態が発生します。
その結果として、レビュアーが自らが実装するよりも多くの時間をレビューと修正に費やすことになる可能性があります。

学んだこと

以下の点を意識すべきだったと感じています。

  • 「誰が書くか」で係数をかける
    • どのレベルのエンジニアが参画するのか決まっていない場合は、自分の工数にバッファを持たせて見積もるべきでした。

  • レビュー工数は実装工数に比例しない
    • 特にAIを活用する場合、コード量が増加しがちです。プロンプトのルールや設計方針を整備するか、レビュー負荷が増えることを前提に見積もる必要があります。

おわりに

今回の失敗から学んだ最大の教訓は、「コーディングの時間」と「プロジェクトが終わるまでの時間」は全く別物だということです。

実装の手が動いている時間よりも、仕様の確認で止まっている時間や、レビューで修正している時間の方が、往々にして長くなります。 だからこそ、見積もりは「これくらいで終わらせたい」という願望ではなく、「これくらいハマるかもしれない」というリスク管理の視点で行うべきでした。

  1. 外部連携・仕様未確定 → 質問・待ち時間を計上する
  2. 実装者未定・AI活用 → レビュー・修正指導コストを計上する

僕と同じような失敗をする人が、ひとりでも減れば嬉しいです。
ここまで読んでいただきありがとうございました!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?