きっかけ

様々な要望を品質を落とさずに迅速に対応できる開発チームを構築する必要があると感じたことがきっかけでした。

正直なところ私は、今のチームのパフォーマンスに懸念をもっていました。今現在でも自社製品で対応したい要望タスクをすべてこなせておらず、要望はたまっていく一方です。今後を考えると、要望対応や機能開発のスパンは短くするための取り組みが必要だと考えています。

また、開発チームメンバの入れ替わりが激しくなったり、開発チームメンバが減ったりすることを想定されるため、持続可能な開発チームの構築が急務です。持続可能な開発チーム構築していくには、個人のマンパワーに頼るのではなく、チームでの開発フロー等の改善等を行い、メンバーの入れ替わリが発生してもチームでのパフォーマンスが大きく変化しないような環境づくりをおこなう必要があります。

しかし上記のような改善活動を行っていくにあたって定量化された指標が存在しないため、どのような問題があるのか、取り組んでいる改善案が効果があるのかを判断することができませんでした。

ソフトウェアデリバリーパフォーマンスという指標で、問題を改善していく

よってチームの開発フローの改善を行うため、ソフトウェアデリバリーパフォーマンスという指標を採用しました。

ソフトウェアデリバリーパフォーマンスは、単なる数値目標ではなく、組織の開発能力と市場競争力を直接的に反映するもので、DORA の研究によると、デリバリーパフォーマンスの高い組織は、市場変化への迅速な対応力、顧客満足度、そして製品品質において優位性を保持できることが実証されています。

DORA（DevOps Research and Assessment）の研究によると、高いデリバリーパフォーマンスを持つ組織は以下の点で優位性があると実証されています。

市場変化への迅速な対応が可能
顧客フィードバックの素早い製品への反映による競争力向上
顧客満足度の優位性
サービスや商品の量の優位性
製品やサービスの質の優位性
競合他社に対する優位性

詳しくは以下参考 https://dora.dev/research/2015/

Four Keys（DORA Metrics）によるデリバリーパフォーマンスの定量化

ソフトウエアデリバリーパフォーマンスを定量化することができないと、改善行動を行うことができません。定量化は、Four Keys（DORA Metrics）というメトリクスを用います。

Four Keys（DORA Metrics）は、以下の 4️ つで構成されています。

1. デプロイ頻度（Deployment Frequency）

定義：本番環境への変更をデプロイする頻度
意味：小規模な変更を継続的に提供する能力

2. リードタイム（Lead Time for Changes）

定義：コミットからデプロイまでの所要時間
意味：開発プロセスの効率性

3. 障害率（Change Failure Rate）

定義：デプロイによる障害の発生率
意味：変更の品質と安定性

4. 復旧時間（Time to Restore Service）

定義：障害発生から復旧までの時間
意味：障害対応の効率性

上記の指標を計測することで、計測値から問題点の特定をし、改善策を立てて、改善策の効果測定を行っていくことができるようになり、チームのパフォーマンスの改善を行っていくことができるようになります。

まとめ

ソフトウェアデリバリーパフォーマンスで、開発チームのパフォーマンスを計測することができる。

ソフトウェアデリバリーパフォーマンスは、開発して提供する速度だけではなくて、利益や業績、株価とも相関関係がある指標で、指標として信用できる。ソフトウェアデリバリーパフォーマンスは信用できる指標なので、改善軸として改善策の検討、効果検証ができる。

FourKeys でソフトウェアデリバリーパフォーマンスを定量化できる。

（担当：ぶくぶくちゃがま）

開発ブログ

開発フロー改善のためのソフトウェアデリバリーパフォーマンス計測