見出し画像

開発者体験を意識して持続可能な開発生産性向上を目指す！

ham

こんにちは、すべての開発組織の生産性を上げたいhamです。

開発生産性の指標として、最近ではFour Keysなどが注目されていますが、デプロイ頻度やリードタイムなどの各指標を上げることだけにフォーカスしてしまうと現場がツラくなってしまうことがあります。

Four Keysは、実際に開発生産性が高い企業のデータを集め、それらの開発チームの特徴を定量的に表したものになっています。
そのため遅行指標としての側面が強く、開発生産性がよくなってきたら自然と上がってくる指標であると考えると良いです。

では、どのように開発生産性を上げていけば良いか？
1つの方法としては開発生産性が高いといわれている企業のケイパビリティを参考にして、自社に取り入れることが考えられます。
DevOps Research and Assessment（DORA）チームが公開している下記サイトがとても参考になります。

また、別の観点として、Four Keysが世間に広まるきっかけとなった書籍「LeanとDevOpsの科学」によると、開発生産性が高い企業は従業員満足度も高いというデータがあります。

上記より、開発生産性の指標を上げるということは開発者体験を上げることにもつながると言えそうですよね！
開発メンバーが、開発生産性を上げることで開発者体験も上がるということを実感できれば、開発生産性を向上させることへのモチベーションに繋がり、現場主導でどんどん開発生産性の向上を行えるようになり持続可能な活動にすることができます。

この記事ではFour Keysを題材として、開発者体験を上げるという観点で開発生産性の向上について考えたいと思います。

デプロイ頻度

デプロイ頻度は多ければ多いほど良い指標です。
生産性の高い開発チームでは1日数回行っているというデータがあります。

デプロイ頻度を上げるには、単純に頻度を増やすだけで上げることは可能です。
例えば週1回デプロイしているチームの場合、1日1回デプロイすると意思決定するだけでデプロイ頻度は5倍になります。

ただ、デプロイのやり方を変えずに頻度だけを上げた場合、高い確率で現場が疲弊します。なぜなら、週1回デプロイしているチームには週1回にしている理由があるからです。

そこで、なぜデプロイ頻度を上げることが困難なのか？を考えます。

デプロイ頻度が上げられないよくある事例をいくつか挙げます。

  1. デプロイ作業が煩雑でデプロイ担当者が長時間拘束される

  2. デプロイ前には手動で大量のテストを実行しないと品質が保てない

1の場合、まずは頻度は変えずにデプロイ作業を自動化するなどしてデプロイ担当者の負担を減らせるようにデプロイプロセスの改善を行います。
デプロイ担当者の負担を減らすことができれば、デプロイ頻度はそのままでも開発者体験は上がりますよね。そして負担が減ることでデプロイ頻度も無理なく上げることができます！

2の場合、まずは手動で行なっているテストのうち、自動テストで代替できないか？を考えます。
自動テストのカバレッジを上げるなどして手動テストの量を減らすことで開発者の負担を減らすことで開発者体験を上げることができます。そして結果としてデプロイ頻度も無理なく上げることができます！

変更のリードタイム

変更のリードタイムは短ければ短いほど良い指標です。
生産性の高い開発チームでは1日未満というデータがあります。
リードタイムには様々な定義がありますが、この記事では最初のコミットからmainブランチにマージするまでの時間をリードタイムと定義します。

リードタイムが長くなるよくある事例をいくつか挙げます。

  1. 1つのプルリクで大量に変更するためレビュー依頼まで時間がかかる

  2. レビュアーが特定のメンバーに集中して多忙なためレビューに着手するまでに時間がかかってしまう

  3. レビュー指摘が多く手戻りが多い

  4. プルリクの生存期間が長くなりmainブランチとの乖離が大きくなりコンフリクトの解消に時間がかかる

1の場合、プルリクサイズを小さくすると良いです。
私の所属している開発チームでは先月の1プルリクあたりの平均変更行数は203.5行でした。
行数で定量的に制限をかけるとつらくなることもあるので「1プルリクでは1つの観点の修正を行う」などのルールがおすすめです。
このルールの場合、1つの観点であれば大量の変更があってもヨシとしています。変更行数が大量にあっても全て1つの観点の修正であれば認知負荷低くレビューできます。
プルリクのサイズが小さいと、作成者とレビュアーの双方の認知負荷がかなり軽減されるので開発者体験が上がり、リードタイムも短くなります！

2の場合、レビュアーを増やすと良いです。
レビュアー偏りはリードタイムを長くする最大の要因だと思うので「レビューを分担できるようにする」は最優先でやるべきだと考えています。
最初から単独で任せるのは不安かもしれないので、ジュニアレビュアーとシニアレビュアーでダブルでレビューするなどしてジュニアレビュアーのレビュースキルをチェックしつつ、レビュー力を上げていき一人立ちできるようにしましょう。
レビューが大量に来るとコンテキストスイッチが発生しレビュアーの開発者体験が低下します。また、レビューがなかなか返ってこないと作成者の開発者体験も低下します。
レビュー負荷を軽減することで作成者とレビュアー双方の開発者体験が上がり、リードタイムも短くなります！

3の場合、なぜ手戻りが多いのかを深掘りましょう。
設計が甘いのであれば、設計レビューを行ったり、事前に開発方針を壁打ちするなどで解消できますし、変更量が多いのであれば1のようにプルリクサイズを小さくすることで解消できます。
手戻りが減ることで作成者とレビュアー双方の開発者体験が上がり、リードタイムも短くなります！

4の場合、1〜3を高速にすることでリードタイムが短くなり、mainと乖離する確率が減少するので解消します。
コンフリクトはいかなる場合もストレスにしかなりません。コンフリクトが減ることで開発者体験が上がり、リードタイムも短くなります！

変更障害率

変更障害率は低ければ低いほど良い指標です。
生産性の高い開発チームでは0〜15%というデータがあります。

変更障害率が高い場合、デプロイに対するハードルが上がりますし、障害対応は緊急度が高く復旧までのスピードが求められるのでストレスが溜まりやすく、開発者体験が低下しやすいです。
そのため、この数値を下げることがそのまま開発者体験の向上に繋がります。

変更障害率が高くなるよくある事例をいくつか挙げます。

  1. 予期せず既存処理を壊してしまうことが多い

  2. 新規機能開発で障害が起こりやすい

1の場合、自動テストを強化して既存処理が壊れていないことを自動で担保できるようにしたり、過度な共通化を避けたり、処理間を疎結合にするようなアーキテクチャにリファクタリングすることで既存処理に影響を減らすこともできます。

2の場合、リリース前の検証が不足している可能性があります。リリース前に検証している観点を見直すなどして障害を検知できる仕組みを構築しましょう。
この時に気をつけることも「開発者体験が向上しているか？」です。
例えば、検証工程で隅々まで手動テストしましょう！などの方法で解決すると変更障害率は下がるかもしれませんが、開発者体験が大きく低下する可能性があります。
開発者体験が低下すると持続可能な活動にならず、現場が疲弊して生産性も次第に下がっていきます。
開発者体験を維持しつつ、変更障害率を下げる良い塩梅を探すことが大事です。(変更障害率を下げる手段が開発者体験を下げる方法しか出てこないのであれば、まだその時ではないのかもしれません)

平均修復時間

平均復旧時間は短ければ短いほど良い指標です。
生産性の高い開発チームでは1日未満というデータがあります。

平均修復時間が長い場合、本番障害を修正するまでの時間がかかっているということなので、変更障害率同様にストレスが溜まりやすく、開発者体験が低下しやすいです。
そのため、この数値を下げることがそのまま開発者体験の向上に繋がります。

平均修復時間が高くなるよくある事例をいくつか挙げます。

  1. デプロイに時間がかかる

    1. 開発チーム外の承認が必要

    2. デプロイ作業が煩雑で時間がかかる

    3. ビルドなどデプロイで行うタスクが遅い

  2. 一度に様々な変更がデプロイされ、本番障害のエラー箇所特定に時間がかかる

1の場合、いくつかの理由が考えられます。
1.1の場合、デプロイプロセスを見直しましょう。承認プロセスなど開発以外のことに時間が取られるとデプロイ開始までに時間がかかるだけでなく、開発者体験の低下にも繋がります。開発生産性を上げるためには開発開始からデプロイまでのプロセスは開発チームで完結すると良いとされています。可能な限り途中に開発チーム外のプロセスが入り込まないようにしましょう。

1.2の場合、デプロイ頻度のところと同様でデプロイの自動化などで対応しましょう。

1.3の場合、通常のデプロイかつ自動化されていてデプロイ担当者の手間がほとんどかからないのであれば、デプロイ担当者は待っているだけで良く、その間に他の作業ができるのでそれほどストレスは感じません。
一方、障害時のデプロイだと話が変わります。デプロイに時間がかかると復旧までの時間がどんどん長くなります。
復旧時間が長い場合、その対策として障害を起こさない方向に話が進みやすく、過度な品質保証を求められたり、デプロイすることのハードルがあがることがあります。
こうなると開発者体験が低下し、開発生産性も低下していきます。
デプロイプロセスを高速化できないか検討しましょう。

2は「ビッグバンリリース」と呼ばれることもあるアンチパターンです。
ビッグバンリリースの何が良くないのかは様々な記事で語られているので任せるとして、ビッグバンリリースを避けるには、デプロイ頻度を上げてデプロイ1回あたりの変更量を減らすとよいです。
ビッグバンリリースは高確率で開発者体験を低下させます。そのため、ビッグバンリリースが減るだけで開発者体験が向上します。

まとめ

前述した通り、ただ開発生産性指標の数値を上げるという観点だけで考えてしまうと、一時的に数値が上がったとしても、現場が疲弊してしまう可能性があります。
開発生産性向上について考える場合、そのやり方で開発者体験を向上するのか？や開発者体験を低下させていることは何か？など開発者体験の観点で考えると良いです。
開発者体験が上がることで、現場のモチベーションが上がり、現場主導で開発生産性の向上が推進されるようになり、持続可能な活動にすることができます！


この記事が気に入ったらサポートをしてみませんか？