コロナ禍とコーヒー生活
コロナ禍で自宅勤務がメインになって以降、コーヒーにハマっている。
アメトーークで紹介されていたコーヒーサーバーをふるさと納税で購入し、近所のお店で焙煎してもらった豆を、自宅で挽いて淹れている。
それまではコーヒーの味の違いなどわからなかったが、やはり日常的に飲んでいると豆の種類・焙煎度・挽き方で味が変わることに気づく。（多分厳密には、もっと他のパラメータもあるんだろうけど、そこまでわかってない）同じ豆で、同じ焙煎でも、挽き方やその他を少し変えただけで味が変わったりして「あれ、昨日と違ってイマイチだな」と思うこともあり難しさと奥深さを感じている。
という前置きがあって本題だが、最近 Developer Productivityの向上というのをメインタスクとして活動している。もう少し詳しく言うと、グループ全体の各開発組織（＝チーム / project）の開発生産性に係る指標を計測し、その計測結果から改善アクションにつなげる、という試みに取り組んでいる。
ここで目的としている Developer Productivityの向上って、「美味しいコーヒーを飲んでもらう」という顧客体験に対して、「様々な種類の良いコーヒー豆をより多く提供する」ようなものだな、と感じたという話。
コーヒーの作業工程と味への影響
前述したように、コーヒーの味を分解すると、豆の種類・焙煎・挽き方(and more)に分かれる。ここで注目すべきは、豆を製造するという工程と、製造された豆を焙煎する・挽くという加工する工程に分かれることだ。
当然それぞれの工程に別々の担当者がいて、生産者は日本から見た外国（コーヒーベルトと呼ばれている国々が主）の人たちで、加工者は地元のコーヒー屋の店員さんだったり、自分自身だったりして、全然違った人が担っている。
それらの工程を経て、最終的にエンドユーザー（つまり自分）の前にコーヒーが提供され、それが美味しいものだと幸せである、というストーリーになっている。しかし、違う領域の担当者のそれぞれのアウトプットの品質が、最終的な成果物の品質にも影響してしまうのがデリケートなところだ。特に製造者から見たら、豆の質にしかresponsibilityを持てない状況で如何ともし難い問題と言えるかもしれない。
と匂わせて書いてきたので、コーヒー豆の製造者がエンジニアで、加工者がプロダクト（ビジネス）サイドっぽいよね。というのはおそらくしっくりくるだろう。
Developer Productivityの指標
開発生産性の話をするときに「生産性（が高いこと）をどうやって測るのか」が議論になることがあり、個人的にも未だに結論は出ていないのだが、最近立てている仮説として、「Deployment Frequency(デプロイ頻度）」をKPIとできるのではないかと考えている。Deployment Frequencyは御存知の通り、Google が提唱する Four Keysと呼ばれる指標のうちの一つだ。Four Keysは Deployment Frequency , Leadtime for Change, MTTR, Failure Rate の4つがあり、それらを俯瞰してみていくことでDeveloper Productivityが可視化されるとされている。
実際、今取り組んでいるタスクにおいてもこれらの指標を可視化するのがこれまでのメインフォーカスになっている。それに対して、「KPIは Deployment Frequencyだ」と言うと、4つのうちから1つに絞りこむように誤解されがちだが、そうではなくて、
- Developer Productivityの向上という取り組みを、とあるFunctionと捉える
- Four Keysの指標を Functionに渡すためのInput パラメータと捉える
- FunctionにInputがあれば、Outputもあり、それが生産性向上の取り組み結果つまりKPIとなる。これを Deployment Frequencyと置く
つまり、Four Keysの指標を以てDeveloper Productivity改善に取り組んだ結果を Deployment Frequency向上に跳ね返ってきたことで測るべきではないか、という仮説だ。これは特に今所属する組織がFocusすべき指標として攻めの Deployment Frequency や Leadtime for Changeと守りの MTTR, Failure Rateであれば攻めの指標をKPIにする方が組織風土に合っているのではないか、という個人的な事情も含んでいる。特に、究極的な数値が「０」のLeadtime for Changeに対して、Deployment Frequencyはそれが「正の数値」なので、「向上」施策で「数値を増やす」ことが直感的にわかりやすいし、会社のカルチャー(Go Bold)にマッチしている気がする。
そして、これをKPIとする穴は、Deployment Frequency向上がDeveloper Productivity向上の最終的な目的ではないということだ。
Developer Productivity向上の最終的な目的はなにか？ずばり Business Growthである。すべては事業が成功するために取り組んでいる。これはとても重要なポイントだ。
しかし、Business Growthが目的だとしても、Business KPIと同じ数値をDeveloper Productivity向上の取り組みのKPIとすることはできない。なぜならそのKPIに対してダイレクトにリーチできないからだ。その間には Product Productivityとでも呼べるものがある。より良いProductを提供するための様々なファクターだ。
toCのProductだったらPMの企画設計力・仮説設定力、Designerのデザイン力、BIの分析力、QAの品質確保レベル、CSが握る顧客満足度、などなどどれも欠かせない要素が絡み合ってProductの成否を左右する。
Developerがどれだけコーヒー豆に風味と香りをつけても、焙煎と挽きの工程次第では顧客の望む美味しさにはならないかもしれない。
一方で、加工工程に一流のバリスタを置いていても、豆そのものの質が悪ければ期待したクオリティにならないのもまた同様だ。
そして何より、製造・加工それぞれがベストを尽くしても、「顧客にとってそれが美味しいと思うものか」はわからない。
加工工程でどう処理するかもわからないし、顧客が何を望むかもわからない。しかし「だから我々Developer はただ『質の良いコーヒー豆を提供すること』にfocusする」というのはたとえ論理的であっても、それがゴールになってはいけない。何故なら我々Developerも顧客に提供したいUXは例えば「ホッとするひととき」であり、それを達成するためのProductは豆ではなく、飲み物としてのコーヒーだからだ。
なんのためにDeveloper Productivityを向上させるのか
Developer Productivity向上という取り組みに対して、
- Business KPIは本質的には追いたいが、成果が見えない数値であること
- Technicalな数値(e.g. Deployment Frequency)だけを追いたくはないが、成果が見える数値であること
これらを理解した上ならば、それぞれの数値を扱うのも良いのではないかと思う。
これはEMFMで言われている「物的労働生産性」と「付加価値の労働生産性」の違いだと思う。
ここまで考えれば、最終的に我々が目指しているDeveloper Productivityの向上というのは、ただ「コーヒー豆を大量生産する」物量の話では決してない。コードを書いてデプロイすることそれ自体に意味はない。「多くの顧客の”それぞれ”が美味しいと感じるコーヒーを飲んでもらえるようにするために、様々な種類の良いコーヒー豆を提供する」ことを目指すべきだ。できるだけたくさんの種類で、できるだけたくさんの量を、できるだけ早く。
Sortware Engineerであるならば、高い技術力で、多くのコミットを、素早くデプロイ、とかになるのではないだろうか。それによって Productの仮説検証の回数と確率を上げて、Business Growthに至るのが理想的なストーリーである。
