Four Keysを初心者向けにやさしく解説します
はじめに
こんにちは。 SHIFTアジャイルコーチの谷川です。
アジャイル界隈で暮らしている人であれば、一度は、 「Four Keys」 という言葉を聞いたことがあると思います。
私も、横文字アレルギーがあるので、最初にこの文字を見た時には、少し拒否反応がありましたが、 和田さんの講演で直接話を聞けたことで理解が深まり、感動へと変わっていきました。
是非、皆さんにもこの良さを感じてもらいたいと思ったので、今回はこのFour Keysを初心者の方にもわかるように、やさしく解説したいと思います。
私とFour Keysとの出会い
「Four Keys」はチームの生産性を可視化することを主な目的とした４つの指標です。
私と「Four Keys」の出会いは、和田卓斗さんの「質とスピード」という講演でした。(*1)
[質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition（和田卓斗さん]
この講演により、開発生産性に対する考え方が180度変わった気がします。 また、この講演の中で、「LeanとDevOpsの科学」という書籍も紹介されており、それを詳しく読んで更に理解を深めました。（*2）
開発生産性指標について
一般的に、開発生産性は、下記のように考えられます。
生産性 ＝ アウトプット／インプット
この極めて単純な式は、何かインプットとなるリソースの量に対して、アウトプットされた量がどの程度なのかという比率が生産性であることを示しています。
この、アウトプットとインプットに当てはまるものは実は数多くあり、いろんな生産性を計算することができます。
また、従来からあるソフトウェア開発における生産性指標には下記のようなものがあります。
●時間当たりの生産コード量
一般的に、一番開発生産性として使われやすい指標だと思います。
単純に考えれば、１時間あたりにたくさんのコードが書ければ時間当たりの生産コード量が増え、生産性が高くなります。
この指標だけだと、品質の悪いコードを数多く書いても、その人は開発生産性が高いということになってしまいます。
また、ソフトウェア開発の世界では、美しいコード、わかりやすいコード、効率的なコードというものがあるため、一概にたくさんコードが書ければ生産性が高いとは言えません。 つまり、この指標は、コード品質と共に見ないと意味のない指標となってしまう危険性があります。
また、ソフトウェアの保守性を考えた場合には、コード実行には関係のないコメント行をたくさん追加することが奨励されると思いますが、このコメント行の有無によって、かなり開発生産性も変わってきます。
つまり、この指標は何を目的に、どんな価値を優先度高く検討するかでかなり計測の仕方、見方が変わってきてしまうので、事前に確認しておくことが重要です。
若い頃、アセンブラコードのコーディングで、いかに短いコードで機能実装できるか？を競い合った記憶があります。
●コード量あたりのバグ数
自分が開発したコードの中にどれだけたくさんのバグが埋め込まれているのか？という指標になるので、少ない方が生産性が高くなります。この数値が低いと品質が高いと判断できる訳であり、結果的にコード修正の工数を考えると生産性も高くなるということですね。
Four Keysの各指標をやさしく解説します
●デプロイの頻度
変更（価値）を本番環境にデプロイ（適用する）、あるいはエンドユーザーにリリースした頻度です。頻度なので、一定期間内に提供回数が多いほど生産性が高いことになります。
お客様要望やトラブル対応が迅速に対応できることが大きな価値となるという考え方の指標です。
この指標は、本番環境へのデプロイが簡単に頻度高く実行できるタイプのサービスの場合は、測定の意味がありますが、ハードウェアが伴うような計画駆動リリース（数か月に一度リリースする）のサービスの場合にはあまり適しません。
また、DevOps環境のように、デプロイ頻度をあげるための仕組み作りそのものに価値があると考えることもできます。
●変更のリードタイム
変更（価値）のコミット（開発完了）から、本番環境で正常に実行されるまでの時間です。変更（価値）は、本番環境に提供されて初めて価値を発揮できます。変更はお客様要求やトラブルなど様々な要因があると思いますが、それらに対して迅速に正確に対応できるところを価値と捉えた指標です。
ここで良く起こる事象は、Dev（開発）とOps（運用）に部門間の壁があり、スムーズな本番環境リリースが実現できないケースです。
大きな会社では、開発部門と運用部門が別部門になっており、予算管理、業績評価も部門単位で行われるため、DevOps環境がうまく構築できない運用できないケースがあり、開発は完了しているのに、本番環境へのリリースに非常に時間が掛かってしまうことがあると思います。
しかし、後述する「開発生産性と業績評価指標について」で書いていますが、お客様重視のライフサイクルマネジメントを実現するためには、DevOps対応は必須であり、DevとOpsの部門間の壁は解消されている？ と思いたいです。
●変更失敗率
デプロイによって本番環境で障害が発生する割合です。当然、障害が発生する割合が低い方が、お客様に迷惑を掛けないことになるので価値が高くなります。変更の成功率が高いということなので、それだけ品質の高い作業が確実にできていることの証明になり、品質の高い作業は、結果的には生産性が高いということにつながります。
また、この指標に関しては、開発の品質だけでなく、デリバリ品質の高さ（いかに正確なデリバリ作業が実現できるか？）も要求されます。ここに注意してください。
●デプロイ失敗時の復元までの時間（MTTR）
本番環境で障害が発生した場合に、発生から復元までに掛かった時間（MTTR＝Mean Time To Repair）です。障害が起きた場合に、より早く復旧できれば、お客様満足度が高くなります。
障害が全く起きないシステムより、障害がたまに起こるが迅速な復旧ができる（MTTRが短い）システムの方がお客様満足度が高いということを聞いたことがあります。それだけ、お客様の印象が強いということなのでしょうね。
DevOpsの出現により、開発生産性の考え方が変化
従来の開発生産性指標は、成果よりも出力に焦点が当てられている点と、チームなどのグローバルなレベルではなく、個人などのローカルなレベルでの測定に焦点を当てているという点が特徴です。
そして、DevOpsの出現により、開発生産性の考え方が大きく変わることになります。ソフトウェアは開発されて完了するのではなく、デリバリーされて初めてその価値を発揮することから、ソフトウェアデリバリーのパフォーマンスやお客様に提供する価値の考え方も開発生産性に取り入れるようになりました。
Four KeysはDevOpsの重要性を認識して、数多くのデータ分析から生まれてきた指標です。
Four Keysはお客様への価値の提供を焦点にあてた指標であるため、自然と開発者の目線がお客様目線になり、これがものすごく良い効果を生むことになります。
ベロシティについて（蛇足）
ベロシティは本来は「キャパシティ計画の立案ツール」として使うべきものであるが、これをチームの生産性として測定したり、チーム間の生産性を比較するために使っているケースがあります。このやり方には以下の問題があるので、かなり注意が必要です。
ベロシティは絶対的ではなく、チーム依存の相対的な指標である
ベロシティを生産性指標にすると、悪用するようになることがある
つまり、ベロシティをチームの生産性指標として扱うことはお勧めしません。
開発生産性と業績評価指標について
開発生産性は、組織や個人の業績評価に使われることがあると思います。
従来型の企業では、売上や損益、個人ベースの指標などが業績評価に使われることが多いです。
特に、売上、損益などの指標は、内向きな指標と言われており、この指標を重視しすぎると、お客様へのサービス提供の優先度が下がってしまうことがあります。
具体的な例で話すと、あるサービスをとても高い料金でお客様に提供できれば、自社の売上、損益は大きく上がり、部門の目標は達成できるかもしれませんが、お客様へのサービスを考えた場合には、お客様満足度がかなり下がってしまうケースがあります。
このとき、業績評価指標として、Four Keysのようなお客様目線の指標を使った場合には、お客様へのサービスが重視されるため、お客様満足度は向上すると思います。
更に、お客様満足度が上がれば、その後の継続受注も期待できる訳であり、お客様と良好な関係を築くことができ、結果的に自社の売上や損益も向上する可能性が高いという訳です。
Four Keysのようなお客様への価値提供の指標を、チーム、個人の業績評価指標に使った場合には、社員の目線がお客様目線になるため、お客様に対してとても良い行動がとれるようになるのです！
しかし、業績評価指標というのは、人事部門も絡む話であるため、そう簡単に変更できるものではありません。
でも、業績指標を変えることで、社員の行動を変える、組織文化を改革できる大きな可能性を秘めていることは、今回のこの記事にて認識してもらえるとうれしいです。
当社では、このような支援も実施しておりますので、ご興味のある場合には、ご連絡ください。
おわりに
私は、「アジャイル」の理解を深めていく中で、かなり自分の行動、意識が変わっていったことを実感しています。
今回テーマにあげた 「Four Keys」 も、こんな視点で社員が行動できるようになったら、とても良い企業文化にできると思いますので、そのような会社をどんどん増やしていけたらと思っています。
組織文化改革というテーマはとても難しい、一筋縄では行かないテーマですが、微力ながらお客様に貢献できるようにアジャイルコーチとして活動を続けていきたいです。
◆参考文献
(*1) 質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition 和田卓斗さん 2022年3月
(*2) Nicole FrosgrenPh.D.さん 「LeanとDevOpsの科学」 2021年10月
執筆者プロフィール：谷川 智彦（たにかわ ともひこ）
2023年5月にSHIFTに入社。
組織アジャイル教信者。真剣に「組織アジャイル」でいきいき、ワクワク、幸せに働くことができ、日本を元気にすることができると思っている。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/
PHOTO：UnsplashのAaron Burden