はじめに

タスクに取り掛かる前に、タスクの細分化はできていますか？

タスクの工数見積もりをし、スケジューリングしていますか？

また、細分化したタスクを、どのように取り組んでいますか？

私は、タスクの細分化やタスクの工数見積もりができておらず、タスクの期限をすぎてしまい、チームに迷惑をかけた経験があります。
（期限ギリギリになって「間に合いそうにないです」と報告することがありました。😞）

そこで、振り返りをし、タスクの工数見積もり方法や細分化について考え直したので、記事にしようと思いました。🙆

この記事では、タスクの細分化と工数見積もりについて教えます!

以下では、Pull RequestをPRと省略します。

対象読者

細分化や工数見積もりを知らないエンジニア
タスク細分化が苦手な駆け出しエンジニア
タスクを期限内にこなせず上司を困らせた経験がある駆け出しエンジニア

まずは自分の体験から

インターン先のとある開発にて

〜タスクはじめ〜

私　「このタスクやりたいです！」🔥
上司「ありがとうございます！期限がありますが頑張ってください！」

〜〆切10日前〜

私「〆切までまだ余裕あるし、すでに少し遅れてるけど、あと数日あるから巻き返せる！」🔥

〜〆切5日前〜

上司「進捗どうですか？締め切りが今週末なのでそろそろPullRequestをオープンしないと厳しそうですね。」
私　「実装に詰まっています。途中でもPRはOpenにしてもいいんでしょうか？」💦
上司「1PRで完結させずに1トピックごとにPRを細分化し分割するのは難しいですか？」
私　「1PRで全部やろうとしてました。」💦
上司「このタスクをまとめて対応すると、PRが大きくなって仰るとおり作業量が多くなるのかなと思います。」
私　「。。。」💦
上司「また、PRを分割する際には、『このPRのゴールがどこで、ここまでやる』を明確化して分割するのがいいと思います。」

私　「え、そうなの、、、」😨😨😨😨😨

～その後～
期限残り５日でタスク細分化というものに出会ったので、当たり前に、このタスクは間に合いませんでした。🙇
アドバイス通りタスクを行ってみて、タスク細分化と工数見積もりはかなり大切だなと感じました🤔

💪 振り返り（成長の記録としてw）

[Keep]
- 自分にとって難易度の高いタスクにチャレンジしたこと
- タスク後に自分自身で振り返りをしたこと
[Problem]
- タスクの期限への見積もりが甘かった（できていなかった）
- タスクを取り掛かる前に、親タスクの細分化をしなかった
- １タスク１PRで済ませようと思っていたこと（お恥ずかしいですが）
- PRの粒度の適切さを知らなかった
[Try]
- タスクの細分化や見積もりを必ず始めに行う
- 多く経験を積んで、適切な細分化や見積もりができるようになりたい

これを機に、難易度が高いタスクに取り掛かる前には、期限を意識したタスクの細分化や工数見積もりをするようになりました！！！

仕事をする上で期限を守ることは大事（エンジニア限らずですね）なので、以下では自分の経験からの反省点を踏まえ、エンジニアとしてタスクの細分化とタスクの工数見積もりについて、説明しようと思います！🙆

毎回的確にアドバイスをいただき、期日を過ぎても柔軟に対応してくれる上司には感謝しかないです🙇

😁 タスクの細分化と工数見積もり

🧠 タスクの細分化

タスクを細分化するとなにがいいか？

明確な目標：
細分化されたタスクは、より具体的なので、何をすべきかが明確になる。何をすべきかが明確になるので、動き始めるための心理的ハードルが低くなる。
不確実なタスクの期限内の完了が確実になる：
細分化されたタスクごとの工数が明確になることで、タスクの全体の見積もりの確度が上がる。
大きいPRを避けることができる：
実装者やレビュアーにとっても、大きなPRは、嫌だ！
リスク軽減：
問題が発生したとき、細分化されたタスク単位での対応ができる。細分化されたタスクごとにPDCAがまわせる！

🧠 タスクの工数見積もり

タスクの工数見積もりをすると何がいいか？

スケジュール管理：
工数見積もりにより、細分化したタスクがどれくらいの時間を要するのかが明確になるため、全体のスケジュールを立てやすくなる
優先度の確認や容易な調整：
タスクの工数とその重要性を比較することで、どのタスクから手を付けるべきか、またどのタスクを後回しにすべきかが明確になる
評価や反省：
実際の作業時間と見積もり時間を比較することで、見積もりの精度やその理由を検証し、次回のタスクへのフィードバックとして活用できる

じゃあ、どうやって工数を見積もりをしたらいいの？

当然ですが、「タスクをより細分化して工数を見積もる」です！

たくさん方法はあると思いますが、、、
タスク細分化や工数見積もりの経験がない（苦手な）駆け出しエンジニアにとっては、
おそらくいきなり「タスク細分化して取り組め！」と言われても、何を基準にどういった目安で細分化したらいいかわからないと思います。
そこで、調査するなかで、私が単純でわかりやすいなと思ったものをご紹介します！🙆

『1つのタスクが3時間以下になるまで細分化する』です！

この考えは、若手エンジニアが学んだ工数見積もり方法を参考にさせていただきました！

とはいえ細分化と言われても何を持って分割すればいいのかわからないと思います。
自分が教わった定義は「1つのタスクが3時間以下になるまで細分化」することです。

先輩エンジニアからのアドバイス

1つのタスクが3時間以下になるまで細分化する方法を紹介しましたが、その先のステップとして先輩エンジニアからのアドバイスをいただいたので、ご紹介します！

細分化の目安については色々ありますが、以下を考えたりします。

レビューしやすいPR粒度

PR出した時のコード量

時間

影響範囲

あるタスクは、一度経験したことありそうだから2時間かな。
あるタスクは、おそらく難しそうだから多分3時間くらいかかりそう。だけど、道筋見えてないからバッファ持って5時間かな。
とか思考をしていると、全体として工数に対しての不確実性が下がります！

はじめ　→　1つのタスクが3時間以下になるまで細分化する
慣れた　→　経験を元に工数見積もりの不確実性を下げていく

チームで開発をしているので、レビューが効率よく進むようなタスク細分化やレビューしやすいPR作成も大切🙆
レビューしやすいと感じるPRの大きさで細分化すると、レビューの質が上がって工数が減らせる🤔
レビューが効率化されれば、自分は期限に間に合う！👏そして、レビュアーにとってもプラス👏

😁 トピックブランチでPRを適切な大きさに

効率よくレビューを進めるためには、PRの大きさが大切！

PR（ここでは、PRの粒度）が大きくなると、、、

タスクの進捗に影響
1. 指摘内容が増え、結果的に手戻りが大きくなってしまう
2. 変更箇所が多くなり、レビュー完了してマージするまでの時間が長くなる
その他
1. レビュワーが見るべき範囲が必要以上に大きくなってしまい、レビューの質の低下
2. レビューに時間が掛かり、レビュワーも見たくなくなる

そこで、1PRを適切な大きさにするために工夫しよう！🤔

その工夫として、ここでは、Topic Branch（トピックブランチ）を使用した開発を紹介します！

🧠 Topic Branch（トピックブランチ）

トピックブランチとは？

機能追加やバグ修正といったある課題に関する作業を行うために作成するブランチ

トピックブランチはどのように使うか？

例
default-branch（main, master）
topic-branch（issue-1）→ 親タスク
topic-branch-1（issue-#番号-1）→ 子タスク

細分化したタスクをtopic-branch-1, topic-branch-2, topic-branch-3
を親タスクのtopic branchにマージし、
リリースのタイミングでtopic branchをdefault branchにマージする

default-branch　（main, master)
   ∟ topic-branch　（issue-　#番号)
       ∟ topic-branch-1　(issue-　#番号　-1)
       ∟ topic-branch-2　(issue-　#番号　-2)
       ∟ topic-branch-3　(issue-　#番号　-3)

トピックブランチで意識していること

定期的な同期：
定期的に main や master から最新の変更を取り込む。
一つの課題に一つのブランチ：
一つのブランチで複数の課題（機能追加、バグ修正など）を扱わないようにする。
ブランチ命名規則を統一する：
どのような内容のブランチか一目でわかり統一感のある命名を意識。

トピックブランチでちょこっと実践

どのようにTopic Branch（トピックブランチ）で開発するか

step1 ブランチを切る

default-branch（main, master）からtopic-branch（issue-1）を切る
topic-branch（issue-1）からtopic-branch-1（issue-1-1）を切る

ブランチを切る, 親ブランチから子ブランチを切る

# masterからissue-1のブランチを切る
(master)$ git checkout -b issue-1

# 現在のブランチを確認
(issue-1)$ git branch
* issue-1
master

# issue-1からissue-1-1のブランチを切る
(issue-1)$ git checkout -b issue-1-1

(issue-1-1)$ git branch
* issue-1-1
issue-1
master

step2 topic-branch（issue-1）で空コミットでPRを作成

--allow-emptyで空コミットして PR作成

空コミット

# 空コミット
(issue-1)$ git commit --allow-empty -m "コミットメッセージ"

# プッシュ
(issue-1)$ git push origin issue-1

step3　コードを書いてPRを作成

topic-branch-1（issue-1-1）でコードを書いてPRを作成する

step4　マージ先を変更

次に、マージ先をdefault-branch（main, master）からtopic-branch（issue-1）変更する

Editで編集
base:master ▼でtopic-branch（issue-1）に変更する
変更完了！👏

step5　topic-branch-1（issue-1-1）をtopic-branch（issue-1）へマージ

topic-branch-1（issue-1-1）をtopic-branch（issue-1）へマージする

マージ完了！
そうすると、topic-branch（issue-1）にログが残る

これで、もうマスターですね！
初めてトピックブランチを使う方でも、不安なく開発できますね！

😁 ChatGPTで細分化と見積もりを効率化（助けて、GPT先生！）

経験がなくいきなりタスクの細分化や見積もりが難しいというあなたへ、ChatGPTからヒントをもらおう！
まあまあ、ちゃんとした見積もりや細分化をしてくれるので、これをベースに見積もれば作業効率を上がりそう🙆

自分が使用しているプロンプトを紹介

以下のタスクを条件に従って細分化し、工数見積もりをしてください。

#　タスク
[タスクを書く]

#　条件
- バッファを合計で[数字]時間持たせてください。
- 思考過程がわかるように段階的に記述してください。
- 1タスクが最大でも[数字]時間で完了できるようなタスクになるように細分化、見積もりをしてください。
- 細分化の目安は、時間、およそのコード量、タスクの影響範囲について考えてください。
- 工数見積もりから、親全体タスクの工数、PRの数を教えてください。

やってみた

※タスクは一例です

以下のタスクを条件に従って細分化し、工数見積もりをしてください。

#　タスク
バックエンドでapiのPOSTに400番のエラーの型を追加し、特定の条件でバリデーション処理を追加したい。
フロントエンドでバリデーションエラーを画面に表示したい。
上の実装のテストコードを書きたい。

#　条件
- バッファを合計で3時間持たせてください。
- 思考過程がわかるように段階的に記述してください。
- 1タスクが最大でも3時間で完了できるようなタスクになるように細分化、見積もりをしてください。
- 細分化の目安は、時間、およそのコード量、タスクの影響範囲について考えてください。
- 工数見積もりから、親全体タスクの工数、PRの数を教えてください。

GPT先生からの回答

思考過程
このタスクは主にバックエンドとフロントエンドの2つの部分で構成されています。
バックエンドでは新しい400番のエラー型と特定の条件でのバリデーション処理を追加する必要があります。
フロントエンドでは、そのバリデーションエラーを画面に表示する必要があります。
さらに、これら全てに対するテストコードも書く必要があります。

各部分を更に細分化して考える必要があります。

バックエンド
エラー型の設計
コードの追加（400番エラー）
バリデーションロジックの設計
バリデーションロジックの実装
バックエンドのテストコード設計
バックエンドのテストコード実装
フロントエンド
エラー表示のUI設計
エラー表示のUI実装
フロントエンドのテストコード設計
フロントエンドのテストコード実装
各タスクには最大で3時間という制限があるため、この制限を考慮しながら工数を見積もります。

工数見積もり
バックエンド
エラー型の設計 - 1時間
コード量：少（設計文書に記述）
影響範囲：中（新しいエラー型が他の部分に影響を与える可能性あり）
コードの追加（400番エラー）- 2時間
コード量：中（エラー処理のロジックを含む）
影響範囲：中（API全体）
バリデーションロジックの設計 - 1時間
コード量：少（設計文書に記述）
影響範囲：中（特定の条件下で発生するため）
バリデーションロジックの実装 - 2時間
コード量：中（具体的なロジックを含む）
影響範囲：中（特定の条件下で発生するため）
バックエンドのテストコード設計 - 1時間
コード量：少（設計文書に記述）
影響範囲：少（テストに限定）
バックエンドのテストコード実装 - 2時間
コード量：中（各ケースを網羅）
影響範囲：少（テストに限定）
フロントエンド
エラー表示のUI設計 - 1時間
コード量：少（設計文書に記述）
影響範囲：少（特定のUI部分に限定）
エラー表示のUI実装 - 2時間
コード量：中（UIコンポーネントの作成や状態管理など）
影響範囲：少（特定のUI部分に限定）
フロントエンドのテストコード設計 - 1時間
コード量：少（設計文書に記述）
影響範囲：少（テストに限定）
フロントエンドのテストコード実装 - 2時間
コード量：中（各ケースを網羅）
影響範囲：少（テストに限定）
バッファ
合計バッファ - 3時間
合計工数
バックエンド: 1 + 2 + 1 + 2 + 1 + 2 = 9時間
フロントエンド: 1 + 2 + 1 + 2 = 6時間
バッファ: 3時間
総合計: 9時間 (バックエンド) + 6時間 (フロントエンド) + 3時間 (バッファ) = 18時間

PR（Pull Request）の数
バックエンドのエラーとバリデーション処理追加
バックエンドのテストコード
フロントエンドのエラー表示
フロントエンドのテストコード
合計PR数: 4 PR

この見積もりはあくまで一例であり、実際の状況に応じて調整が必要かもしれません。
特に、影響範囲や既存のコードベースによっては、時間が前後する可能性があります。

ChatGPTの回答どうりにタスクを細分化するのではなく、プロダクトコードと自分の技術力と経験を考慮して、細分化してみると効率化きそうですね！🙆

おわりに

駆け出しエンジニアにとって技術力はもちろん大切ですが、仕事をしている以上は、決められた期限を守るということが大切ですね！

期限を守るためにタスクの細分化や工数見積もりができることも非常に重要です。タスクがおわったら振り返りをすることも大切ですね！

この記事が、細分化したタスクの開発をしらない初心者エンジニアさんの参考になれば幸いです〜
また、タスクを期限内にこなせず上司を困らせた経験があるエンジニアさんが「こんな時期あったなー」と懐かしい気持ちになれば、嬉しいです！

自分は、技術力含め全てがまだまだですが、日々精進します！💪

タスクの期限をすぎてしまった話 〜駆け出しエンジニアがタスクの細分化と見積もりを知る〜