新卒エンジニアが学んだ、開発フローに取り入れるべきこと〜工数見積もり〜

こんにちは！
新卒エンジニアのozawaです！

新卒で入社し、約3か月間の研修を経て本配属となり、本配属からさらに約3か月が経ちました。
本記事では、4案件の開発を通じて身につけた、開発フローに取り入れてよかった取り組みを紹介します！

はじめに

配属前の研修期間中は、計画力や優先順位の付け方などをほめていただく機会が多くありました。本配属後も、その強みを維持し、さらに伸ばしていくには何ができるかを考えた結果、開発におけるタスク分解と工数見積もりに取り組むことにしました。

任されたことを期限内に必ずやり切るという「安定感」は、チームへの信頼残高を積み上げることにつながります。信頼残高を積み上げていくためには、与えられた仕事を最後まで責任をもって進めること。そのためには、小さなタスクはもちろん、いつか大きな開発を任せてもらったときにも続けられるよう、自分の仕事（タスク）をきちんと管理する仕組みが必要だと考えました。

取り組んだこと

もともとの開発フローは 調査 → 設計 → 実装 でした。 このフローに2つの工程を加え、次のフローに変更しました。

調査 → 設計 → 工数見積もり → 実装 → 振り返り

工数見積もりと振り返りの時間を意図的に設けることで、「ただこなす」のではなく、案件ごとに成長を記録するサイクルを回しています。

1.調査

改修対象のファイルを特定し、改修による影響範囲を調査します。地道な作業にはなりますが、調査を省略すると、後から修正が必要になったときに想定外の工数がかかってしまいます。

2.設計

どこをどうやって実装するかを設計書に落とし込みます。意識していたのは「コードを書きすぎないこと」。設計書を書く段階でコードを書き始めてしまうと、全体像の把握が後回しになってしまうため、スケルトンコードとして日本語で「ここにどんな処理を入れるか」を書いていました。

3.工数見積もり

設計書を書いているタイミングが、全体を一番把握できている瞬間だと感じています。設計と開発の間でタスク分解と見積もりを行うことで、実装時の見落としを減らせます。 実際に使っていた見積もりシートの項目は以下の通りです。

設計での理解度に合わせて見積もりとバッファを置き、設計書の内容をさらに深掘りするイメージでタスクを分解しています。

4.実装

設計書をもとに実装します。意識していたのは、データの流れやロジックを理解することです。わからないことはAIを壁打ち相手として使い、理解できるまで質問を重ねました。

5.振り返り

各案件の終わりに、次の3つを書き出します。

学び

設計段階の理解度が、見積もり精度を左右する

100%理解してから実装に進もうとすると、設計の段階でコードを書き始めてしまいます。そこで意識したのは、「設計では大枠が3割理解できたら次に進む」 という割り切りです。
細部まで詰めきるのではなく、「何を・どこで・どう変えるか」の骨格が見えたら、工数見積もりに進むようにしました。この線引きを持つようになってから、設計と実装のバランスが取りやすくなりました。 もうひとつ効果があったものが、見積もりシートで 「理解の時間」 と 「実装の時間」を別タスクとして分けて記録することです。新人のうちは理解に時間がかかるのに、その時間を見積もりに含めていませんでした。たとえば実工数を「実装：1時間 / 理解：1時間」のように書き分けることで、見えなかったコストが可視化され、次の見積もりに活かせるようになりました。

振り返りで「自分の成長」が見えるようになった

振り返りを 「反省のため」だけでなく「成長の記録のため」に使うように意識しました。学んだことを書くだけでなく、「今回は工数が少なく済んだ」「理解が早かった」といった体感も残すことで、目に見えるスキルの向上がなくても、案件ごとに前進があったと振り返れるようになりました。 見積もりシートに実績が蓄積されていくと、その体感を数字でも確認できます。
同じ技術領域を2回担当したとき、1回目より理解にかかった時間が短くなっていたことがシートに残っており、小さな成長を実感できました。 成長は「新しい技術が使えるようになった」ときだけではありません。振り返りと見積もりの記録を続けることで、小さな積み重ねも見えるようになりました。

工数見積もりは「おまけ」ではない

大切にしたのは、見積もりを出す時間そのものを確保することです。急いで見積もると、実装中に「思っていたより複雑だった」という手戻りが発生します。見積もりは実装前の”おまけ”ではなく、設計と実装をつなぐ工程の一部だと考えるようになりました。設計書をもとにタスクを洗い出し、工数とバッファを置く時間は、実装をスムーズに進めるための準備時間です。
見積もりの目的は、最初から完璧な数字を出すことではなく、振り返りを重ねて精度を上げていける状態、「再現性」を作ることだと感じています。

Cursorに工数見積もりをやってもらってみた

4案件目では、これまで3案件分のタスク分解・見積もり・実工数などのデータをCursorに渡し、「今の私のレベル感で工数見積もりを出して」 と依頼しました。

タスクごとにはプラスマイナスの誤差はありましたが、合計ではAIの見積もりと実工数の差は0.5時間でした。自分では安全に余裕をもって見積もっていた部分があり、AIの方が実態に近い数字を出してくれたと感じています。
案件ごとにナレッジを蓄積していけば、AIの見積もり精度もさらに上がっていくのではないかと楽しみです。次の開発からは、自分でタスク分解し、AIにも分解してもらい、照らし合わせながら進めてみようと思っています。

まとめ

入社当初は「スケジュールは前倒しできればいい」と思っていました。しかしそれは、自分のタスクを管理できていない状態でもあります。スケジュール通りに進めることが安定感につながり、チームへの信頼残高にもつながると実感しました。 タスク管理は社会人として当たり前のことですが、工数分解と見積もりという方法で「当たり前のレベル」を上げていけると感じています。これからも続けていきます。

最後までご覧いただきありがとうございました！