見出し画像

Four Keys(デリバリー能力)とアウトカムはどちらも大事!!両方高めて最高の開発組織にしよう!!

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

近年、開発組織の「開発生産性」についての関心が増加していると感じています。次のグラフはGoogleトレンドで「開発生産性」の過去5年間について調べてみましたが、近年増えていることがわかります。

「開発生産性」のGoogle トレンド

そして、開発生産性について調べていると高確率で「Four Keys」にぶつかると思います。

私自身、自分の所属しているチームのFour Keysを日々ウォッチしており、とても良い指標だと感じているのですが、Four Keysの話題になったときに「Four Keysを上げても開発生産性上がらなくね?」であったり、「Four Keysはアウトプットの量や速度しか見れていない。事業においてはアウトカムが大事!」みたいな話を聞くことが良くあります。

どちらの意見もそんなことはない!と否定するわけではなく、そういう側面もあると思っており、私はタイトルに書いた通りFour Keysもアウトカムもどちらも大切だというスタンスです。
どちらも大切なので、Four Keysを上げようぜ!という意見と、アウトカムが大事!という意見が対立することなく協力することで開発組織の能力を最大化することができると考えています。

「Four Keysを上げても開発生産性上がらなくね?」

Four Keysは開発チームのデリバリー能力を示しており、結果指標である。と認識すると良いと思っています。
Four Keysを上げると開発生産性が上がるのではなく、開発生産性が上がるとFour Keysが上がるのです。

もう少し具体的に言うと
「デプロイ頻度を上げるために、デプロイプロセスを変えずに気合いと根性で週1のデプロイを毎日するようにしました。」
ではなく
「デプロイを自動化してデプロイ作業が軽くなったので、負荷なく毎日デプロイできるようになりました!」
が良いのです。

「今の状態のままデプロイ頻度を上げたら変更障害率が高くなったのでリリース前の手動テストを増やして変更障害率を低く保てるようにしました(テスト工数が増加して開発生産性は低下)」
ではなく
「自動テストが充実させてリリース前の手動テストを増やさなくても品質担保できるようになったので、テスト工数を増やさなくても変更障害率を低く保ったままデプロイ頻度を上げることができました!」
が良いのです。

Four Keysを上げることで報酬が上がるみたいな極端な目標設定をしていたら本質的ではない数値のハックが横行する可能性はありますが、そうではない場合は自分たちの負担を増やしてまでFour Keysを上げようとする人はいません。

テストやCI/CDの自動化など開発組織のデリバリー能力を高めるノウハウは様々なところで共有されています(例: DevOpsの能力)。ただし、これらを導入した際にどれくらいデリバリー能力が変化したのか定量的に可視化することが困難でした。
これを可能にしたのがFour Keysです。
デリバリー能力を上げるノウハウを開発組織に取り入れて、その結果としてどれくらい開発組織のデリバリー能力が上がったか確認する方法としてFour Keysを活用するようにしましょう。
そうすることでFour Keysは開発組織の生産性と相関するとても良い指標になります。

「Four Keysはアウトプットの量や速度しか見れていない。事業においてはアウトカムが大事!」

Four Keysはタイトルにも括弧で書いたのですが「デリバリー能力」を示していると考えています。
デリバリーをする能力であり、「何をデリバリーしたか?」は数値には現れません。

企業におけるプロダクトの目的は顧客へ価値提供することです。そしてプロダクトを開発する目的は提供する価値を最大化することであり、それをアウトカムと呼んでいます。
そのため開発チームの「デリバリー能力」ではなく、開発チームが「何をデリバリーしたか?」が大事になるという意見はとてもよくわかります。

では、デリバリー能力とアウトカムは排他な関係なのか?というとそうではなく、どちらも高めていくことが重要です。

デリバリー能力が高くても、顧客の価値に繋がらない開発しかしていなければ、アウトカムを上げることはできません。
一方で、顧客への価値が高まるために必要な開発がわかっていたとしても、デリバリー能力が低ければいつまでたっても価値を届けられません。

前者の場合、価値につながるものが開発できていないので価値を届けられる可能性は0%。後者の場合、価値につながる開発はできているので遅くてもいつかは価値提供できるので良い。という考えから、アウトカムを重視した方が良いということかもしれません。
ただ、実際に開発してもそれが想定通りのアウトカムをもたらすかは未知数です。リリースしたが想定ほど使われなかったり、逆に想定以上に利用されることもあります。
アウトカムを事前に想定しきれない昨今では、アウトカムを最大化できるように開発前に検討することも大事ですが、デリバリー能力も高めて素早く顧客に使ってもらうことで『顧客が本当に必要だったもの』を素早く見つけることも大事です。
また、競争力の観点でもデリバリー速度が遅い場合、類似機能を他社に先にリリースされてしまったり、後発企業に開発速度で抜かれてしまう可能性が高まります。

まとめ

開発生産性にとても興味関心があるので、開発生産性について書かれているブログやスライドなどはかなりチェックしている方だと思います。
そして、タイトルではどちらか一方を重視しているように読める記事でも、中身を読むと両方大事と書かれていることが多いと感じています。

とはいえ、ブログなどの宿命だと思いますが、中身は斜め読みされて正しく理解されないままタイトルの主張だけが一人歩きしているパターンも数多く見かけます。
そこでこの記事ではタイトルの段階で両方大事と書くことにしました。

タイトルにも書いた通り、デリバリー能力を高めることとアウトカムを高めることはどちらも大事です。
デリバリー能力、アウトカム、どちらも妥協することなく最高の開発組織にしていきましょう!!

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