kk-web

個人的なスクラム体制における開発フローのベストプラクティス案

2025-03-28

昨日のブログが怖いと言われたので、今日は普通の内容です。

以前にも書いたのですが、スクラムにおける開発フローというのは個人的にある程度ベストプラクティスを持っていまして。

今日はそれを改めて書いていこうといった内容です。

前提

  • スクラム開発
    • 期間の短いスプリントのほうが適している
  • GitHub
    • スプリントバックログ内の作業タスクを扱う
  • オープンソースでないプロジェクト

この運用の考え方

本記事で紹介する開発フローは、「属人性を排除し、誰でも迷わず開発を進められる状態」を目指しています。

経験豊富なエンジニアだけでなく、Git 操作に不慣れなメンバーも含めてチーム全体の一貫した開発体験を提供することが目的です。

一見すると rebase や squash merge など高度な操作に見えるかもしれませんが、ルールが明文化されていることで手順が明確になり、むしろ初心者にとってやりやすいという側面があります。

スクラムのおけるスコープ

スプリントプランニング〜スプリントレビューまでの「実際の開発期間」にフォーカスした運用フローの話です。

技術スタック

事前準備

  • GitHub の Issues に以下のデフォルトのテンプレートを作成する
    • Bug report
    • Feature request
  • GitHub の Pull Requests は Allow squash merging のみを許容する

開発フロー

  1. Issue（作業タスク）に自身の Assign を振る
  2. ローカルでブランチを作成する
  3. 開発作業を行う
  4. コミットする
  5. 2 本以上コミットを行った場合は rebase を行う
  6. PR を作成する
  7. レビューを依頼された開発メンバーはレビューを行う
  8. レビュー内容に応じて追加のコミットを行う
  9. レビューが完了次第 merge する
  10. 以下手順を 1 から繰り返す

開発フローの詳細

ローカルでブランチを作成する

Git ワークフローにもよるのですが、作成するブランチ名は feature/#◯◯-hogehoge のように紐づく Issue 番号を含めるようにしましょう。

コミットする

後ほど詳細を記載しますが、PR に紐づく 1 本目のコミットには必ず Issue を紐づけるようにしましょう。

つまり以下のようなフォーマットに則ってコミットメッセージを書くことが大切です。

<type>[optional scope]: <description>

[optional body]

close #◯◯

また基本的にコミットメッセージは AI に出力してもらうようにしましょう。

2 本以上コミットを行った場合は rebase を行う

PR を作成する に詳細を記載しているので、ここでは説明しません。

PR を作成する

PR の作成時は以下のルールを守りましょう。

  • コミットメッセージは 1 本のみ許容する
  • PR の description は 1 本目のコミットメッセージの body 以下のみ許容する

GitHub の場合自動的に反映されるため、修正や追記を行わないようにしましょう。

description をあえて修正しないことで、テンプレートや自動生成された内容と整合性が取れ、ヒューマンエラーや説明のばらつきを防ぐことができます。

PR の詳細を知りたい場合は、紐づく Issue や、さらに紐づくプロダクトバックログアイテムを辿る運用です。

またスクリーンショットや追加の説明を行いたい場合は、PR の description に記載せず、追加でコメントを行うようにしましょう。

ただし基本的には不要な認識です。

レビューが完了次第 merge する

GitHub の設定で Squash merge しか行えませんので、そのまま merge しちゃいましょう。

auto merge をオンにするのも良い運用だと思います。

備考

  • Jira など他のサービスで作業タスクを扱う場合、今回の開発フローは適用できません
  • リポジトリが GitLab や BitBucket の場合、未確認ですが部分的にしか適用できない可能性があります

初心者への適用について

一見すると rebase など多少 Git に慣れていないと難しく見える部分もありますが、実際にはこのようにルールが固定されていることで、むしろ初心者でも迷わず手順通りに開発が進められるという利点があります。

作業フローが明文化・固定化されていることで「自由度の高さゆえの迷い」や「属人化」を避けることができ、チーム全体としてもスムーズに開発を進めやすくなります。

チームメンバー全員が同じルールに従うことで、レビューや手戻りの発生も減り、長期的に見ると開発スピードや品質の安定にもつながります。

つまりルールとしては以下のような感じです。

  • 作業用ブランチ名には Issue 番号を含めること
  • コミットメッセージは Conventional Commit のフォーマットに沿うこと
    • PR に紐づく 1 本目のコミットメッセージの Footer には Issue のクローズワードを含めること
  • コミットメッセージは可能な限り AI に出力させること
  • PR 作成時にコミットは 1 本だけ紐づけること
  • PR 作成時に description を修正しないこと

比較的シンプルなルールだと思うのですが、いかがでしょうか。

© 2018 kk-web