Zenn
🤧

PRのFiles changedが多すぎる問題

2024/05/28に公開
チーム開発
アジャイル
スクラムマスター
アジャイル開発
スクラム開発
tech

はじめに

私は、ここ数年(現職で3社目)アジャイル開発を行っている会社にてSWE,SRE(ひよこ),スクラムマスターなどのロールで仕事をしてきました。

これらの経験で会社が変わっても結構これってあるあるだよねってことがいくつかあります。そのうちの一つについてポエムっぽく語りたいと思います。
これらの考察や解決策が誰かの何かになったら幸いです。

余談

久々に記事を書いているので至らぬ点があるかもしれません。よろしくお願いします。

PRのFiles changedが多くなりがち

アジャイルやスクラムに慣れていないチームや導入したてのチーム、組織ですと結構起こりがちなのかなと思います。

量もまちまちだと思いますが20, 60fileとかザラにあると思います。
またフロントとバックエンドでリポジトリが分かれている場合は、合算するともっと行く可能性もあります。

問題点(潜在的な問題含む)

  • file数が多いことによりレビューコストが相関的に上がっていくことです。
    • レビューコストが引き起こす問題
      • 対応したことへのコンテキストの理解を知る必要が相関的に上がります。
      • 単純にコストが上がり、レビューするモチベが下がります。
      • 仕様等の見落としが発生しがちになります。
  • レビューコストが上がり、レビューするための時間が相関的に上がります。
    • マージ・テスト・リリースまでのリードタイムが伸びます。
  • 一人の人による実装でそれほどのFiles changedが起きるのは、属人化の疑いが生まれます
  • fileが多いということは、実装に時間がかかり、属人化している可能性もあります。
    • またその工数がかかってしまう点は、個人に依存しているため問題が潜在化していく可能性もあります。
    • 今後の見積もりに対しても改善がされることは低くなると思われます。

仮説

なぜFiles changedが多くなってしまうのでしょうか？
私個人の見解を述べていきたいと思います。

タスクの粒度が最も関連していると思っています。
タスクの粒度が粗いことによって一つのタスクでやるべきことが大量に発生していると想定できます。
大量に発生するということは一つのタスクでやるべき実装も増えていくということです。
実装が増えることでFiles changedが増えます。

解決策

まずはタスクの粒度を見直しましょう。どれくらいの粒度がいいのか？それはチームや組織によって定義を設けて共通認識を取るのが大事だと思っています。ですがそれを作る上での指針的なものがあるといいかなと思いますので個人的にこれくらいの粒度でもいいのでは？というのを経験してきたことをもとに例を上げたいと思います。
例として何かしらの新機能開発を行うことを前提とします。

前提

  • DBに対して何かしらの変更がある
  • フロントとバックエンドでリポジトリが分かれてます
  • フロントとバックエンドはどちらも新規Fileをいくつか作る必要がある機能だとします
  • Gitのブランチ運用としてリリースするあれこれをマージする先としてリリースブランチが存在していることとします
  • 筆者がLaravelが一番得意としているのでLaravelを採用しているプロダクト開発をしている前提で話をします
    • なおフロントは、なんでもいい派なので言及しません
  • 新機能なので複数のエンドポイントや複数の画面があるとします
  • 1タスク1PRである前提です

タスク(例)

  • 1.DBに対して変更等を加えるタスク
    • migrationなどDBに対しての変更を加えるタスクのみです
    • 単体でリリースが可能ならしてもいいのではと思っています
  • 2.APIのスキーマの作成
    • OpenAPIなどを採用している会社はこれだけのタスクがあってもいいかもしれません
    • 個人的には、ベースはリファイメントでたたきを作ってしまって共通認識を持ってもいいと思っています
  • 3.APIエンドポイントの作成 * 必要な数分タスクを作ります
    • やり方や規模にもよるとは思いますがペアプロを採用してたら以下のやり方をすることで実装も加速するかもしれません
      • テストを先行して作成してもらう
      • 同時ないし並行して実装もやってもらう
    • 一人で実装する場合
      • すごく細かくするのであれば
      • Form Requestのみの作成
      • PHPUnitのみ先に作成などがあってもいいかもしれません
    • 個人的におすすめ
      • 1エンドポイント1タスクです
      • これにはもちろんテストも含めてます
  • 4.フロントエンドの実装 * 画面単位(画面は最小粒度で)分タスクを作ります
    • OpenAPIなどを使用している会社でしたらMock等を使用することができると思いますのでAPIスキーマさえ決まっていればバックエンドの実装を待たずに進めれます
    • Mockが使えなかっとしても仮でResponseをするJsonを用意したりすることで実装が可能になるはず
    • どうしてもバックエンドがーとなりますとバックエンドがブロッキングになってしまいます。なので独立して実装ができる環境や手法を検討することをおすすめします
  • 5.必要に応じてフロントとバックエンドの繋ぎこみ実装
    • こちらは、どちらのタスクも終わって対応が必要ならタスクを作ることをおすすめします

恩恵

タスクの粒度を細かくすることで以下の恩恵があると仮定しています。(体験的に実際感じたものでもあります)

  • PRのFiles changed数が減りレビューが行いやすくなる
  • マージまでのリードタイムが減るので実装等忘れがちなことを思い出す必要がなくなり「タスクをやった感」が増えて仕事している感を味わえる(特に初学者などにはポジティブになりそうですね)
  • 見積もりの精度が上がる
    • 注意として正確になるというわけではないです。開発自体不確実なことに対して行っているので開発途中にあれこれと考慮漏れ等は発生します。なのでチーム・組織にある程度の共通認識等が蓄積されていくというニュアンスがあるかもしれません
  • 属人化が解消方向へ向かう可能性が高い
  • コンテキストの理解のハードルが下がる

感想

  • あくまで個人の観測範囲内のお話にはなりますがタスクの粒度について今一度組織・チームで話し合ってみるといいかもしれませんね。

Discussion