開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する
Posted: Updated:
この記事は前作 開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと に続き、開発生産性へのスタンスを整理したい2作目です。
効果・成果よりも効率を優先することは生産性か？
開発生産性と言いながら単なるアクティビティの量や時間を見て効率改善を志してしまういくつかの状況、一部の風潮に対して疑問を呈したい。
- 例えば、PRやイシューの起票数などアウトプット量の高低に一喜一憂する
- 例えば、変更のリードタイムやデプロイ頻度の増進を過度に重視する
- 例えば、サイクルタイムの各時間を人間の努力のみで短縮しようとする
それにも関わらず、開発がもたらしたユーザーへの効果やビジネス上の成果に無関心というのは順序おかしいよね、という話。
などと考えていたら開発生産性カンファレンス2024 - 登壇資料まとめ｜610を見る限り、近しい主旨の論説を散見するに至り、もしかしたら世間の議論は次の段階に進んでしまったかもしれない。供養。
結論
安直に (特に人間に起因する) 効率だけを求めて、効果や成果そのものから目を逸らすのはやめよう。 本来的な存在価値にそぐわない改善活動に腐心することは衰退の兆候である。
チームの開発効率の向上を目的として開発アクティビティ指標の観察によって効率改善を試みることは生産工程の歯車に限り正しいが、チームに求められていることが価値創出であるにも関わらず開発効率を目的にしてしまうと変な方向にいってしまう
— あほむ@KINTOテクノロジーズ (@ahomu) June 24, 2024
効率だけをいくら追っても効果や成果にアラインできない
効率と効果と成果は異なる
昨今の開発生産性の指標と言われる多くは人間起因の行動量、時間を示す開発アクティビティ指標であることが少なくない。組織が求めている成果が売上やプロダクトKPIの達成などであれば、プロダクトに変更を加えてリリースするだけで「生産した」とは言えない。
| 項目 | 具体指標 | 観測装置 |
|---|---|---|
| 効率 Efficiency | 開発アクティビティの定量値 | 生産性可視化サービスの類 |
| 効果 Effect | 信頼性、可用性、性能、プロダクトKPI | 運用ダッシュボードの類 |
| 成果 Outcome | 売上、利益、KGI | 経営ダッシュボード、BIの類 |
「開発工程の効率」と「開発によって生じた効果」と「組織が得られた成果」は厳密に区別される。指標やスコアを上げたら何となく良いことだ、という認識で開発アクティビティ指標だけに執着するようでは効率の局所最適が行われるだけで本質的な生産には何ら影響を与えない可能性がある。
それどころか人間に起因する効率に過度な期待を寄せたコミュニケーションは、チームやメンバーを燃えつき症候群を誘引してしまいかねない。健全に効率を上げたいなら CI/CD の処理短縮や定型業務の自動化などに向き合って時間を増やす方が真っ当だろう。
効果と成果の確認を優先するべき
請け負い仕事を除いてソフトウェア開発の多くが、常に価値があると決まったものを生産できるわけではないため、時間あたりのアウトプットの多寡がアウトカムを保証しない。メソッドとパフォーマンスの側面からアウトプットをいくらか効率化しても、アウトカムに繋がらない生産が続けばそもそもの前提が誤っていることになる。
前向きには試行回数を増やすことを念頭にイテレーションの高速化を志向するのが現代のソフトウェア開発におけるユーティライゼーションだが、例えば「無駄なものを作らない」という意思決定の有無というユーティライゼーションがアウトカムの生産性に最も響くという可能性も大きい。 開発生産性の可視化サービスから何を見いだして何ができるのか
おにぎりを作ったら無限に売れるのであれば効率と成果の関連は強いと言えるが、おにぎりを作りすぎたら普通は売れ残るので効率以前の計画が必要である。過去のブログでも述べたが、いくら開発工程の回転数だけを上げたとしてもユーティライゼーション（計画や活用のうまさ加減）が及ばなければ意味がない。
多くの事業においても効率化の追求やリソースの投入は、それが成長のレバーになっていると確信できてから行うものだろう(※)。不確実性が高い中では開発工程が効果や成果につながっているかどうかと向き合うことが必要であり、効率はそれらと比べれば優先度が下がる。
※このフェーズであればソフトウェアによる自動化や定型化を経たアウトソースのほうが社内リソースを温存して効率的である可能性も観点として必要である
それでも開発効率を求めるべき状況はあるのか
価値探索フェーズにある事業やチームにおいて仮説検証の打席数を増やすために回転効率を高めることは一見すると正しそうでもある。一方でそのようなフェーズの開発者にかかっている期待の優先事項は開発効率だろうか？
開発チームとして未成熟（個々人の成熟度というよりもチームワークとしての成熟度）で人間起因の効率を最適化したい場合でも、やはり第一義としては効果・成果に目線を向けた上で取り組むべきだと考えられる。
未成熟なチームが手元の効率から追うことはあるかもしれない
習熟が進んでいない主体（チーム、メンバー）は「アウトプット」に多くの関心を払い、成熟した主体では「アウトカム」に多くの関心が自然と払われるようになる 開発生産性の可視化サービスから何を見いだして何ができるのか
以前の記事でも言及したとおり、そもそも開発を著しくスムーズに回せていないのであれば自分たちの開発が本当にスムーズになったと言えるのかを可視化するために開発アクティビティ指標で必要最低限の効率を見ることは有効な可能性がある。
その場合は Pull Request (ないしパッチサイズ) の単位を小さくする等の汎用的なプラクティスと、それらの実践に必要なチームインフラへの投資が考えられる。誤解を恐れずに言えば、ある程度の習熟をしたチームであれば汎用的なプラクティスで向上する程度の効率は一定満たしているので開発効率に強くフォーカスする必要はない。
※チームとして効率性の習熟にどれくらいの目線を持つかという要素もある。チーム内でいくら満足していても相対的に程度が低いことは常にありうることから当事者の意識にも左右される。順序を間違えない限り究極的には効果/成果のために効率は必要であり、どちらもやればい良い。
Four Keys は効率というよりパフォーマンスのヘルスチェック指標
DORA (DevOps Research and Assessment) の研究によって見出された Four Keys と呼ばれる（いた？）指標は State of DevOps Report 2023 においてソフトウェアデリバリーパフォーマンスを示す指標として次のように整理されている。
- 変更のリードタイム - コードの変更を commit してからデプロイするまでの時間
- デプロイの頻度 - 変更を本番環境に push する頻度
- 変更時の障害率 - デプロイにより障害が発生しすぐに対処する必要が生じる頻度
- デプロイ失敗時の復旧までの時間 - デプロイの失敗時に復旧にかかる時間
同様に組織パフォーマンス（利益等の実利）やチームパフォーマンス（コンディション）などが評価対象の尺度として並んでいる。年度によっては fifth metric として信頼性が入っていることもあったが直近は運用パフォーマンスとして扱われている。
これら Four Keys 相当の指標群は攻守のバランスがとれており、これまでの調査研究において組織パフォーマンスとのポジティブな関連性が示されている(※)。デリバリーパフォーマンス指標を運用パフォーマンス指標とあわせてトラッキングすること自体は開発活動のヘルスチェックとして意義があると考えられる。その場合も各指標を目標として扱うのは慎重であるべきだ。
※一方で「本当にそうなのか？」という話もある。LeanとDevOps生産性の神話(1) - 11年目のState of DevOps Report という記事では興味深い視点で Four Keys への疑義を論じていたので紹介したい。
コトに向き合う姿勢や環境を作るほうが大事では
近年の State of DevOps Report では組織パフォーマンスを高めるために、健全な組織文化やユーザー中心の開発を成すことの有効性が言及されており、それらはソフトウェアデリバリーパフォーマンスとも関連性が示されている。
- Culture in the 2022 State of DevOps report | Google Cloud Blog
- 2023 State of DevOps Report: Culture is everything | Google Cloud Blog
7 章「組織文化への投資なしには何事もうまくいかない」のモデル（2023 State of DevOps Reportより）
広範な組織文化はチーム単位においてアクショナブルではないかもしれないが、ユーザー中心の開発推進はチーム単位でも取り組める関心事だ。ユーザーにより早く、より良い品質でプロダクトや事業の価値を提供するために結果としてデリバリパフォーマンスも高まるという機序は感覚的にも理解できる。
Four Keys 相当の指標が芳しく無いとき下手に開発効率だけにフォーカスしてしまうよりは、まずはチームがコトに向かえる姿勢や環境整備、チームワークの獲得を志向することから入るほうが望ましいのではないだろうか。
効率から上げようとするな、効果・成果を上げろ
普段から全体の効率を高めることは至極あたりまえの取り組みだが、開発生産性を可視化する中で特に人間の行動に起因した効率性を過度に突き詰めることは危険という立場である。本当に効率がボトルネックならば局所最適を考えざるをえない可能性を否定しきれないが、基本的には効果・成果を念頭に向き合うべきだろう。
個人的には、生産性可視化サービスはシンプルに Four Keys とビルドやテストの所要時間が見えているくらいで良い。人間起因の些末なアクティビティ指標のほとんどがノイズであり、スコアで抽象化して曖昧に高低を示してしまうことも余念がすぎると感じている。純粋なアウトプット量や速度だけを観測したいベンダーコントロール用途等は別文脈・別製品として考えたい。
限られた開発リソースが意図した方向に向かえているか (意図した投資が成されているか) のほうが関心事としては真っ当に感じられるため、雑多な指標を出すよりは How to balance engineering investments — and not just keep the lights on? | Swarmia にあるような可視化を今後期待したい。
