こんにちは！ウィルゲート開発室の佐々木です。
みなさん、たくさんデプロイしてますか？
「開発生産性」という言葉がよく耳にされる現代では、デプロイ頻度に着目されているエンジニアの方も多いかと思います。
弊社でも各チームごとにデプロイ頻度を計測し、月次でモニタリングする時間を設けています。
私の所属するチームでは、直近の1年で劇的にデプロイ頻度が改善しました。 なぜ改善できたのか、その点についてチーム内で振り返りを行いましたので、ご紹介させてください。
はじめに
私のチームでは、約1年ほど前から生産性指標の改善に取り組み始めました。 それまでは、デプロイ頻度を含む生産性指標に対しては、特にルールなどを設けず実装・リリースを行っていました。
しかし、デプロイ頻度を計測し、定期的にモニタリングするようになってからは、徐々に数値が改善していきました。
デプロイ頻度の推移について
実際のデプロイ頻度の推移は以下の通りです。
徐々に右肩上がりで数値が改善しているのが分かるかと思います。
ただ改善しただけで終わるのはもったいないので、他チームにも展開できないかと思い、その要因を言語化するために振り返りを実施しました。
振り返り方法
Miroを使用して、チームメンバーでブレストを行いました。
その後、他チームでも実践できるようにアクションを具体化したのでご紹介します。
改善するためのアクション
仕様はMiroへ集約
私のチームではアジャイル開発を採用しており、企画と開発を並行して進めることが多いです。
日々発生する仕様変更や追加に対応するため、仕様に関する情報は全てMiroに集約しています。 これにより、企画・開発のどちらのフェーズにおいても、一目で現在の状況を把握できるようにしています。
細かくコミット・細かくリリース
こちらは一般的なテクニックですが、細かくコミットし、細かくリリースすることを意識しています。
これにより、レビューの負荷を軽減し、本番環境への影響を限定することが可能です。 また、リリースサイクルを短縮することで、フィードバックに対して迅速に反映することも可能になります。
積極的にモブプロ
私のチームでは、開発時にモブプログラミング（モブプロ）を積極的に活用しています。モブプロを行うことで、以下のような効果が得られます。
- レビュー待ち時間およびレビュー内容の反映時間の削減
- チーム全体での知識共有とスキルアップの促進
- 問題発生時の迅速な解決
- 複数の視点からのコード品質の向上
- コミュニケーションの強化によるチームワークの改善
動作確認は全員で
基本的に動作確認は実装者のみが行うケースが多いかと思われますが、私のチームでは必ず複数人で確認するようにしています。
複数人での確認作業は、以下のような効果があります。
- 異なる視点や経験を持つメンバーが関わることで、見落としやすい問題を発見しやすくなる
- バグの早期発見と修正が可能になり、品質向上に繋がる
- チーム全体のスキル向上と知識の共有が促進される
- テストケースや確認項目の見直しが進み、より包括的な動作確認が行えるようになる
おわりに
デプロイ頻度が改善した要因を振り返ってきましたが、最も大切なことは「何を目的として生産性を改善するのか？」という点です。 デプロイ頻度をはじめとする生産性指標を上げること自体が目的ではなく、それによって提供すべき価値こそが真に追うべき目標となります。
みなさんが目標達成に向けて生産性を改善する際に、この記事がお役に立てれば幸いです。
