🎁

開発のサイクルタイム分析機能のリリース&活用方法

2023/05/24に公開

開発生産性

Four Keys

サイクルタイム

idea

開発組織の生産性を最大化する「Offers MGR」でサイクルタイム分析機能をリリースしました。
今回は、リリースの背景とサイクルタイム分析機能の活用方法についてご紹介します。

サイクルタイム分析をなぜリリースするか

Offers MGRでは、先月Four Keys分析機能をリリースしましたが、継続的にいくつかの分析機能をリリースする予定です。継続的に以下のような機能をリリースする予定です。

機能名	概要・ベネフィット	開発プロセスでの該当箇所	粒度
Four Keys	会社全体、チーム・プロジェクトの概要・健全性	リリース前後の開発組織の状況	抽象／全社・チームのマクロ数値
開発ファネルのサイクルタイム	チーム・プロジェクト内での開発プロセスでの各工程の効率性把握	リリースする前の開発プロセスの状況	抽象／チームのマクロ数値
ワークストリーム	チーム・プロジェクト内での開発プロセスの詳細の把握	開発タスク・チケット単位の運用状況	チーム開発の詳細

現状、大きくはこの3つの機能で現状は構成されています。

「開発組織の生産性を最大化する」と一言で言っても、どのレイヤーの視点で見るかによって得られるインサイトが異なります。このレイヤー・プロセスの現状を把握し、解決すべき課題・ボトルネックを発見、その後のアクションに繋げられるように機能を整えていっています。

サイクルタイム分析とは何か

サイクルタイムの定義

サイクルタイムとは、開発プロセスにおいて、特定の段階から次の段階までの所要時間のことを指します。
この時間は、作業が実際に開始されてから完了するまでの期間を示し、効率性と生産性の指標として使用されます。

Offers MGRにおける開発プロセスのサイクルタイムの計算方法・表示

Offers MGRにおいて、サイクルタイムはいくつかの開発プロセスの主要なフェーズに分けて測定することができます。（要求定義、デザインなどを含めた開発のフルファネルの分析機能に関しては今後リリース予定です。）

最初のコミットからPRオープンまでの時間
PRオープンから最初のレビューまでの時間
最初のレビューから承認までの時間
承認からPRマージまでの時間
PRオープンからマージまでの時間（レビューがない場合）

プルリクエストごとのサイクルタイム分析

Offers MGRでは以下の画像の通り、プルリクエストごとのサイクルタイムと以下の情報を可視化します。

アサインされている人
レビュアー
作成者（Author）

また、上記のような情報のプルリクエストの一覧を可視化する機能もあり、各プロセスでの時間が長い・短い順などにフィルターをかけることによって、プルリクエストごとの各プロセスのリードタイム・サイクルタイム・個人ごとのプルリクエストごとの傾向を把握することもできます。

サイクルタイム分析の利点

サイクルタイム分析により、各フェーズの所要時間を明確に把握することができます。

これにより、時間のかかるフェーズやボトルネックを特定し、改善策を立案することが可能となります。また、改善策の効果を測定するためのベンチマークとしても役立ちます。結果として、プロセスの効率性を高め、生産性を向上させることができます。

サイクルタイムの可視化と改善

Offers MGRではサイクルタイムに関わる各プロセスのデータを月次、週次などの単位で推移で可視化でき、チームや全社の開発プロセスにおける状況把握と現状に対しての施策の検討に役立ちます。

サイクルタイム改善の必要性

長いサイクルタイムは、開発プロセスの効率性と生産性に影響を及ぼします。これは、開発リソースの過剰な消費や、顧客・市場への製品・機能の提供が遅れる原因となる可能性があります。

そのため、サイクルタイムの短縮は、開発チームのパフォーマンスを向上させ、製品の品質と市場競争力を高めるために重要です。

以下に、各フェーズにおけるサイクルタイム改善の方法の一例を挙げていきます。

最初のコミットからPRオープンまでの時間の改善

適切な大きさに分割されたPull Request
- 概要: 一度に大きな機能を開発するよりも、小さな変更を頻繁に行う方が効果的です。これは、開発者が取り組むタスクを小さく分割し、それぞれを独立したPRとして処理することを意味します。これにより、コードのレビューが容易になり、バグが発見しやすくなります。
- 理由: 適切な大きさに分割されたPullRequestは理解しやすく、エラーの発見や修正が容易になります。それにより、開発プロセスを速め、プロジェクトの進行がスムーズになります。
- いつやるべきか: 開発の初期段階から始め、プロジェクト全体にわたって続けます。
開発環境の最適化
- 概要: 開発環境が適切に設定されていないと、開発者はコードの作成やテストに余計な時間を費やすことになります。これには、IDEの設定、ビルドツール、CI/CDパイプラインの設定などが含まれます。
- 理由: 効率的な開発環境は、コードの作成、テスト、デバッグの時間を大幅に削減し、開発のスピードを上げます。
- いつやるべきか: プロジェクトの開始前と、プロジェクトの進行中に必要に応じて。
開発プロセスの明確化
- 概要: タスクの割り当て、役割と責任、コードレビューの手順など、開発プロセス全体を明確に理解していることが重要です。これにより、開発者は自分のタスクに集中し、余計な時間を無駄にすることなく、効率的に作業を進めることができます。
- 理由: プロセスの明確化は、混乱を避け、タスクの実行に必要な時間を短縮します。また、全員が共通の理解を持つことで、チーム内のコミュニケーションも改善されます。
- いつやるべきか: プロジェクトの開始時点で、そしてプロジェクトの進行中に新しくメンバーが加わった場合や大きな変更が生じた場合にも再確認します。

PRオープンから最初のレビューまでの時間の改善

レビューの優先順位付け
- 概要: 全てのPRが同じくらいの重要性を持つわけではありません。優先度が高いPRからレビューすることで、プロジェクト全体の進行がスムーズになります。
- 理由: 優先度が高いPRを先にレビューすることで、プロジェクトの重要な部分が早く完成し、その他の部分の開発も円滑に進めることができます。
- いつやるべきか: レビューが必要なPRが出た時点から始めます。
定期的なレビュータイムの設定
- 概要: チームメンバーが一定の時間をレビューに確保することで、PRが長時間放置されるのを防ぎます。
- 理由: レビュータイムを確保することで、PRのレビューが適時に行われ、開発プロセスがスムーズに進むようになります。
- いつやるべきか: チームのスケジュールに組み込む形で、プロジェクトの開始時点から始めます。
自動レビューツールの使用
- 概要: コード品質を保つためには、スタイルガイドの遵守、バグの検出、パフォーマンス問題の特定など、自動化できるレビュータスクが多くあります。これらのタスクを自動化することで、人間が行うレビューの時間を削減し、より重要な問題に集中することができます。
- 理由: 自動レビューツールは、人間が見落としやすいコーディングエラーやパフォーマンス問題を検出するのに役立ちます。また、これによりレビュー時間を短縮し、より重要な問題に集中することができます。
- いつやるべきか: プロジェクトの初期段階で、そして新しい問題が発見された際にツールの改善や追加を行います。

最初のレビューから承認までの時間の改善

レビューのフィードバックを明確にする
- 概要: レビューのフィードバックが曖昧だと、開発者は修正の方向性を理解するのに時間を費やします。具体的で明確なフィードバックを提供することで、開発者は早く修正を加え、PRの承認までの時間を短縮できます。
- 理由: 明確なフィードバックは開発者が必要な修正を正確に理解し、それに対応するのに必要な時間を削減します。これにより、PRの承認までの時間を短縮することができます。
- いつやるべきか: レビューのフィードバックをする際に常に必要
必要なレビュアー数の最適化
- 概要: 必要以上のレビュアーが割り当てられていると、PRの承認までの時間が長くなる可能性があります。PRの重要性や影響範囲に応じてレビュアーの数を適切に設定することが重要です。
- 理由: レビュアーの数を適切に設定することで、レビュープロセスが速くなり、必要なレビュアーだけが関与することで、他のメンバーの作業を妨げないようにすることができます。
  - レビュアーがいない場合、採用・現メンバーがレビューできるように育成の判断をします。
- いつやるべきか: PRを作成する際にレビュアーを割り当てる段階
効果的なコミュニケーション
- 概要: レビュープロセスはコミュニケーションの一部であり、レビュアーと開発者が互いの意図を理解するためには、明確で効果的なコミュニケーションが必要です。
- 理由: 効果的なコミュニケーションは、誤解を防ぎ、レビューのフィードバックとその対応をスムーズに行うことができます。
- いつやるべきか: PRのレビューを行う全ての段階

https://offers.jp/lp

Offersでは技術顧問を業務委託で採用し、レビュアーを増やす・レビューを強化している企業もあります。

弊社エンジニアの執筆したコードレビューに関しての記事

PRレビューの承認からPRマージまでの時間の改善

自動マージツールの使用
- 概要: 承認されたPRを手動でマージする代わりに、自動マージツールを使用することで、このプロセスを高速化することができます。
- 理由: 手動でのマージは時間がかかるだけでなく、エラーの原因ともなります。自動マージツールを使用すると、これらの問題を防ぎ、PRマージまでの時間を大幅に削減することが可能です。
- いつやるべきか: プロジェクトの初期段階で自動マージツールを設定し、その後は継続的に使用します。
マージの戦略の見直し
- 概要: マージ戦略（例：スクワッシュマージ、リベースマージなど）が適切に選ばれていないと、マージに関する混乱や遅延が発生します。マージ戦略を見直し、チームに最適な方法を選択することが重要です。
- 理由: 適切なマージ戦略を選択することで、マージの過程をスムーズにし、マージの時間を短縮します。
- いつやるべきか: プロジェクトの初期段階でマージ戦略を選択し、プロジェクトの進行中に必要に応じて見直します。
CI/CDパイプラインの最適化
- 概要: テストの自動化、ビルドの自動化、デプロイの自動化など、CI/CDパイプラインを最適化することで、PRの承認からマージまでの時間を短縮できます。
- 理由: CI/CDパイプラインの最適化により、テスト、ビルド、デプロイの各プロセスが高速化し、それによりマージまでの時間を短縮することができます。
- いつやるべきか: プロジェクトの初期段階でCI/CDパイプラインを設定し、その後、パイプラインの改善や新たなテストの追加が必要な場合に調整します。

CI/CDの最適化などを中心・フルメンバーなどで手が回らない場合もあります。その場合には業務委託の方の活用もおすすめです。

https://offers.jp/jobs/23348

一例として、このような方に依頼できます。

PRオープンからマージまでの時間（レビューがない場合）の改善

自動テストの強化
- 概要: 自動テストを強化し、全てのPRに対して適用することで、PRの品質を確保し、マージまでの時間を短縮します。
- 理由: 自動テストにより、コードに問題がないことを確認する時間を短縮し、早期に問題を発見・修正することができます。
- いつやるべきか: プロジェクトの初期段階から始め、新たな機能の追加や既存の機能の変更ごとにテストを更新または追加します。
PRの説明の明確化
- 概要: PRの説明を明確にすることで、レビューが不要なPRでも他のチームメンバーが変更内容を理解しやすくなり、マージまでの時間を短縮します。
- 理由: PRの説明が明確であればあるほど、チームメンバーがPRの目的と変更内容を理解し、問題がないかどうかを素早く判断できます。
- いつやるべきか: PRを作成する際に常に心掛けます。
マージのルールの設定
- 概要: レビューが不要なPRでも、マージする前に一定のルールを設けることが有効です。例えば、一定の自動テストがパスする、特定の人が確認するなどのルールを設けることで、品質を確保しつつマージまでの時間を短縮します。
- 理由: マージのルールを設定することで、安定した品質を維持しつつ、効率的にマージを行うことができます。
- いつやるべきか: プロジェクトの初期段階でルールを設定し、その後は継続的に適用します。

まとめ

サイクルタイム分析は、開発プロセスの効率性と生産性を向上させるための強力なツール
各フェーズの所要時間を明確に理解し、改善の余地を見つけ出すことで、より迅速に高品質なプロダクトを開発し、リリースできるようになる
サイクルタイムの短縮は、開発チームのパフォーマンスを向上させ、製品の品質と市場競争力を高めるために重要
サイクルタイムの総計は、全体的な開発プロセスの効率を評価し、改善の余地を特定するための基準となる

サイクルタイム分析と改善は継続的に必要なプロセスであり、開発チームは常に新しい方法を探し、試行錯誤を重ねながらプロセスを最適化する必要があります。この繰り返しによってより良い開発チームができ、強いプロダクトを顧客に届けられるようになっていきます。

サイクルタイム分析機能を使って開発チームを可視化、改善したい方はこちらから。

https://offers-mgr.com/lp/