Akerun - Qiita Advent Calendar 2024 - Qiita の19日目の記事です。
はじめに
こんにちは、MIWA Akerun Technologiesが運営する賃貸住宅管理システムの開発チームでエンジニアをしている井上です。
今回の記事は、自分自身の成長過程で気づいたタスクの分割とPR（Pull Request）の切り分け方について共有し、特に若手エンジニアの皆さんが仕事を進めやすくなるきっかけになればと思い書きました。
エンジニアとして業務を進める中で、タスクの整理が不十分な状態で開発を進めてしまい、手戻りやレビューの負担を増やしてしまうことがありました。その経験を踏まえて、どのように改善していったのかを具体的にお話しします。
タスクの分割とPRの切り分け方について
自分の仕事のやり方の課題
私が直面していた課題は、タスクを適切に分割せず、1つの大きなPRを作ってしまうことでした。結果として、以下の問題が発生していました。
- コードレビューがしにくい
- 変更範囲が大きくなり、レビュアーが全体像を把握するのに時間がかかってしまう。
- 手戻りが発生しやすい
- 複数の機能を一度に実装すると、バグや仕様変更が発生した際に修正範囲も広がる。
- 進捗が見えづらい
- 小さな単位で進めないため、タスクの完了までに時間がかかっているように見える。
このような状況が続くと、チームの開発速度や品質にも悪影響が出ると感じるようになりました。
課題への向き合い方と改善方法
この課題を解決するために、私は以下の改善方法を実践しました。
1. アーキテクチャの各層に分割する
タスクをアーキテクチャの各層（レイヤー）ごとに分割することで、役割ごとの明確な境界線を意識しました。 これにより、変更範囲が局所化され、PRもそれぞれのレイヤー単位で分けやすくなりました。
ちなみに、私が所属する開発チームのプロダクトの一部は以下の様なアーキテクチャで開発を進めています。
| 階層名 | 説明 |
|---|---|
| handler | 外部からの入力をusecaseが求めるインタフェースに変換する責務を負う。 HTTP Request内のパラメータを取り出してusecaseに渡す。 |
| usecase | usecaseにはアプリケーション固有のビジネスルールが含まれている。handlerから入力を受け取り、ビジネスロジックに従ってrepositoryを呼び出す。 |
| repository | データの集約・永続化の責務を負う。 usecaseが実際のテーブル構造などを把握しなくてもentityの永続化を行える責務を負う。 |
| entity | usecaseによって扱われるドメインモデルとドメインロジック |
例として、「新しいAPIのエンドポイントを追加する」というタスクがあった場合
上記の様にタスクを分割することで、進捗が追いやすくなり開発効率も改善されました。
2. テストファーストで実装を進める
アーキテクチャの層ではPRの規模が大きく、レビュー対応に時間がかかる時は各テストケースでPRを分割することで、さらに粒度を細かくすることができます。
- テストケースを作成する
- 例: APIエンドポイントの正常系や異常系の挙動を定義
- テストケースを満たす実装を行う
- 実装が完了したらPRを作成し、レビュアーに共有
- 次のテストケースに進む
- 小さなサイクルで繰り返し、機能を段階的に完成させました。
3. 実装内容をTODO化して共有する
タスクの切り分けが難しい場合、実装内容をまずTODOリストとして整理しました。 その上で、テックリードや同僚と実装方針を事前に確認し、フィードバックを受けることで不明確な内容を減らしました。 このアプローチにより、タスクのスコープが明確になり、後から大きな手戻りが発生するリスクを抑えられました。
4. 小さなPRを意識する
各タスクを小さく区切ることで、PRの変更内容を最小限に抑えました。 「小さいPR = レビューしやすい」というメリットがあり、フィードバックが早く返ってくるようになりました。
5. 優先度を整理して進める
タスクを分割したら、その中で優先度をつけて着手する順番を決めるようにしました。 例えば、先にデータベースのスキーマを作成し、その後モデルやAPI実装を進めることで、機能ごとの依存関係も整理されました。
結果の振り返り
この改善を進めた結果、以下の変化がありました。
うまくいったこと
- コードレビューがスムーズに進むようになった
- PRが小さくなったことで、レビュアーからのフィードバックが早くなり、修正の手戻りが減りました。
- 開発の進捗が見えやすくなった
- 小さなタスクを順番にクリアしていくことで、自分自身やチームも進捗を確認しやすくなりました。
- チームのコミュニケーションが改善された
- 細かい単位でのレビューや進捗報告が増え、認識のズレが減りました。
- 見積もりの精度が向上した
- タスク分割時に時間や作業量を意識したことで、作業の見通しが立てやすくなりました。
- タスクの粒度を細かくすることで、見積もり精度が向上しました
うまくいかなかったこと
- 最初はタスク分割の粒度に悩んだ
- 分割しすぎてしまうと逆に手間になる場合もあり、適切なサイズ感を掴むまでに時間がかかりました。
- 小さなPRを意識しすぎるあまり、一度に複数のブランチを作成してしまい、管理が煩雑になったこともありました。
これらの課題は、チームメンバーと相談しながら「PRの適切な粒度」を見つけることで少しずつ改善していこうと思います。
最後に
この記事では、タスクの分割とPRの切り分け方について、私の経験とその改善方法を紹介しました。私自身、最初はうまくできなかったことも多かったですが、少しずつ改善を重ねることで確実に業務の質が向上してきました。
特に若手エンジニアの皆さんにとって、日々の業務でタスクの分割やPRの切り分けは意識しにくいかもしれません。しかし、少しずつ工夫することでチームの生産性やコード品質にも繋がっていくと思います。
この記事が、皆さんの仕事の参考になれば幸いです。最後までお読みいただき、ありがとうございました！
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 photosynth.co.jp Akerunにご興味のある方はこちらから akerun.com
