本記事は、hey Advent Calendar 14日目の記事です！
STORESでフロントエンドエンジニアをしています、@daitasuと申します。
この記事では、STORESのプロダクト開発のフロントエンドチームで行っている Pull Requestのfirst commit ~ mergedAt までのリードタイムと 各Issueのstory point をベースとした開発PJTの振り返りについてご紹介します。
はじめに
チームについて
私が所属しているチームは、STORESというECのプロダクトを取り扱っています。 その中でも、主に今年の6月にリリースされたSTORES レジというネットショップと一体となったPOSレジサービス の機能を、ECのダッシュボードと統合して1つの管理画面でレジとECの様々な管理を行えるようにしていく、ということをおこなっているチームになります。
※ 以下、自チームをRライン(Regi関連の機能を追加するので)と称して書いていきます
今年の6月にSTORES レジがリリースされてから、チームのバックエンド、PdM、デザイナーなどメンバーが大きく変わり、 新体制 としてレジ関連の機能をECダッシュボードに追加するRラインが発足しました。
速いを言語化して振り返りたい
Rラインでは、MTG体制やスクラム開発の進め方など、この体制変更時にいろいろと練り直し、大体1ヶ月に1機能はリリースするようなサイクルで開発を進めてきました。
開発の進め方としては大きな負荷なくリリースも順調だったので、「自分たち、開発速度上がってきているのでは？」とチーム内でもうまく進んでいる手応えがありました。
しかし、あくまで手応えとしてそうなだけで、実際に「速いを言語化」することができないむずがゆさがあり、PJTの進め方が良かったのか悪かったのか、開発速度や様々なデータをきちんと計測して、その情報をもとに振り返りで議論したい！と計測の舵を切ったのでした。
開発PJTの進め方
前提として、開発PJTの進め方を簡単にご紹介します。
開発PJTは以下のような手順で進みます。
また、STORES ではZenHubをカンバンツールとして活用しており、チームでは1ヶ月程度のPJTそれぞれに対してEpicとなるIssueを切り、Epicに各開発Issueを紐付けるような運用としていました。
どう振り返る？
どんなふうに解析して振り返るかについてです。
いつもプロジェクトの振り返りはチームでのKPTのみを行なっていました。
以前のプロジェクトでは、タイムラインを書いてやってみたこともありますが、この情報もKPTの材料にはなれど、どうしても体感に依存してしまうので、議論できる実測データとして羅列していくことにしました。
今回可視化した項目
今回可視化したのは以下のデータです。
PJT全体の概観分析
- Epicの総計見積もりポイント
- PJTの初回仕様検討日
- PJTの初回PR日(モブ土台形成、実装開始日)
- QA開始日
- リリース日
- PJT合計日数
Issue単位の分析
- Issue番号
- 見積もりポイント
- 初回コミット日時
- マージ日時
- 初回コミット〜Pull Requestがリリースブランチにマージされるまでの所要時間
なぜこの指標なのか？
PJT全体の概観分析
まず、PJT全体の概観をプロットして振り返りに活かしました。
Epicの総計見積もりポイント
見積もりが膨れるほど不確実性が高まり開発がうまく進まなくなりがちです。 これを避けるため、全体で各PJTがどのくらいの粒度のものなのかを把握するために見ています。
各フェーズの開始日
仕様検討日、実装開始日、QA開始日などを振り返りの材料として残すことで、実際どこで一番詰まったのか、それはなぜか、というところに焦点を当てて話せるように記録しました。
Issue単位の分析
こちらは、LeanとDevOpsの科学 (原題: Accelerate)をもとに、各IssueにリンクしているPull Requestの 初回のcommit 〜 Pull Requestのマージまでの時間 をリードタイムとして計測しました。
LeanとDevOpsの科学では以下の4つを「開発組織のパフォーマンスを測るための指標」として挙げています。
リードタイム
機能が開発されてから本番環境にデプロイされ、ユーザーに価値提供されるまでの時間。
デプロイ頻度
本番環境へのリリースされる頻度。
変更失敗率
デプロイに起因して、本番環境で障害が発生する割合(%)
平均復元時間(MTTR)
障害の発生から回復までにかかった時間
今回の計測では、「リードタイム」に焦点を当て、実装過程やレビュー過程で何かつまずきが発生していなかったかを見るようにしました。
本書でのリードタイムは本番環境へのデプロイまでの時間になるのですが、今回の計測では、PJTのチーム振り返りで開発の速さと課題を見たいが目的だったので、 各Pull Requestがリリースブランチにマージされるまで の時間をリードタイムと定義して計測しています。
上記の内容については、 texta.fmさんで詳しく取りあげられているので、そちらを見ると解像度があがります。
また、もう一つ意識したこととして、各Issueに対して設定されたZenHubの見積もりポイント(story point)も併せて測っています。
これは、リードタイム全体の推移を見たいのではなく、開発PJTの振り返りの材料として見たかったため、同じサイズのポイントを付与したIssue同士でグルーピングして見ることで、
- 特筆して時間がかかりすぎていたものがないか
- 逆に見積もりの割に極端に早く終わり、見積もりを外しているものがないか
などを追えるようにしました。
具体的な結果例
何度かPJTの中でこの手法で計測を行ったので、あるPJTの例を記載します。
PJT全体の概観
PJT全体の概観は、このようにそれぞれにかかった期間を土日祝日除いてどのくらいかかったかと見積もりのサイズを出しています。
Issue単位の分析
Issue概観
Issueはまず全体を見積もりポイントごとに分け、それぞれに紐づくPull Requestのfirst commit~mergedAt までのリードタイムの平均値、最大値、最小値をリスト化しています。
- 「平均値が見積もりポイントに沿って階段構造になっているので、おおよそ見積もりとしては正しそうです」
- 「Issueの数がどれも同じくらいの数ですが、3Pのものがもう少し分解できたかもしれません」
などの観点を振り返りながら議論します。
サイズごとのPull Request比較
次に、上記で分解したPull Requestを、見積もりポイントごとに比較し、極端に短いもの、長いものを見ていきます。
5P
5PのIssueは例としたPJTではありませんでした。
3P
特筆して3つほど大きいPull Requestがあります。 どれも必要なコンポーネントがデザインシステムに関係するもので、この部分に改善できそうな可能性がありそうです。
2P
特筆して1つリードタイムが長いものがありますが、全体としてはばらつきは少なめです。 長くかかったものは調査系のタスクで、パターン洗い出しの部分で苦戦したため、これはIssueをもう少し分けても良かったかもしれません。 一方、極端にリードタイムが短いものは見積もりを多く取りすぎているので、次回の見積もりで考慮したほうが良さそうです。
1P
1つ長めのものがあります。このタスクは、assignee に差し込みタスクがいくつか入り、実装が少し滞ってしまったのが原因でした。 こういった場合は差し込みが入ったタイミングで他メンバーにパスできる体制にできていると良さそうです。
0.5P
どれもそこまで差異がないので、問題は起きてなさそうです。このくらい粒度が低いと不確実性も少なく、課題も生まれないようです。
このように、見積もりポイントごとのグラフを見ながらいろいろとチームの課題としてPJTの改善点を振り返りました。
良かったこと
- PJTの振り返りを単に体感でKPTを行うよりも、どんな問題が発生していたのか、それはなぜなのかなど議論点、改善点が明確になった
- PJTの概観をベースに振り返ることで、ほんとに速かったのか、実はそうでもないのかなどが見えてきた
- Issueを見積もりポイントでグルーピングしてPull Requestのリードタイムを追ったことで、はずれ値が存在し、かつそこに課題が多いことが分かった
- Issueの数もポイントごとに見たことで、実装開始時点で不確実性が高いPJTかどうか(見積もりポイントが大きいものが多い)なども見えやすくなった
改善点
- リードタイムから業務時間外を除きたい
- 休日は除くようにしたが、深夜帯など非活動時間を除いたほうがより正確な値として判断できそう
- リードタイムの最大、最小値以外にも色々出せそう
- 中央値や分散、標準偏差なども出せばよりデータのばらつきを示すことができそう
- 計測の自動化
- PJT規模が小さい場合やチームやPJTを跨いで議論したい場合に弱い
- 振り返りに特化したため、PJT単位での比較はできますが、去年に比べて現在どう変わったか、といった中長期での判断には向いていない
- PJTを横断した中長期の変化やチームを跨いだ変化にはEpicで絞らず、指定した期間のPull Requestごとのリードタイムを追ったほうが良い
まとめ・今後について
今回の計測で、より実態に即したPJTの振り返りが行えるようになりました。
一方で、各PJTのサイズが小さい場合であったり、チームやPJTを横断的に開発速度の変化を見たい場合には今回の計測手法は向いていないことも見えてきました。
上記の改善点から、現在はこの計測手法と別に、もう一つ、期間軸で見るリードタイムの推移の計測も取り組み始めています。
開発速度を上げていくために、まずは計測から！より良いチーム改善が出来ていくように取り組んでいきます。
