前の記事に書かれている通り、先週の木曜日に1日の休暇を取って、Findyさん主催の『LeanとDevOpsの科学』著者登壇の開発生産性Conferenceに参加しました。目的はもちろん開発生産性を高める方法を探りたいからです。ここでは、参加した印象と開発生産性向上のために考えていることについて書いていきます。

きっかけ

健康な時は、通常は検診以外でわざわざ病院に行くことはありません。しかし、何らかの症状が現れた場合、自分が病気ではないと思って、不安や疑問を医師に相談することが多いでしょう。

開発生産性が高ければ高いほど、お客様のニーズに応えることができ、競争力が高まります。特にスタートアップ企業は、ますます生産性を重視する必要があります。製品開発企業にとって、開発生産性は健康のようなものです。開発生産性が低いとやばいと感じ、改善策を模索するのは重要なきっかけと言えます。

参加した感想

参加してわかったことの1つは、開発生産性に関心を示している参加者のうち60%以上がマネージャークラスであるということでした。また、SREの参加者も多く、フロントエンドエンジニアの自分は少数派と感じました。もしGatsbyJSのTシャツを着ていったら同じような人々を見つけやすかったかもしれないと思いました。詳細な流れについては、この記事をご覧ください。Findyの開発生産性コンファレンスを参加してきた。

参加したセッションのざっくりな感想は以下の通りです。

基調講演

正直講演者のNicoleさんの本『LeanとDevOpsの科学テクノロジーの戦略的活用が組織変革を加速する』を事前に読んできたら良かったと思います。SPACEフレームワークのことを知っていたら、もっと理解できたと思います。

Amazonで売ってあります。LeanとDevOpsの科学。

ところで、GithubにもSPACEを用いて、開発生産性を測っているようです。How do we think about developer productivity at GitHub?

組織をスケールさせるためのFour Keysとチームトポロジー by Timee

早すぎでよくわからなかったです。とりあえず理解できたことは以下の通りです。

• 本当に充実した学習環境を提供するための福利厚生措置
• 専門のスクラムマスターを採用している
• テストカバレッジは約95％あり、また毎日約5回のデプロイをしている

なぜ Four Keys を改善するのか？ 〜How ではなく Why を重視したメトリクス改善活動〜 by LM

株式会社リンクアンドモチベーションのSREである川津さんの講演は、個人的には非常に素晴らしかったと思います。

ツールを用いて開発生産性を可視化する前に、何のために測るの？とエンジニアたちとコミュニケーションを取ることがとても大切という講演でした。

なぜデプロイ頻度が低いとダメなの？

• feature単位でリリース。きり戻りが安全なのでMTTRが向上できる。
• PRが小さければテストしやすいため、テストが書かれる。品質が上がる。
• 高いデプロイ頻度であれば、心理的安全性を確保するために、エンジニア自身がテストを書く。品質が上がる。
• PRが小さければ、レビューしやすい。品質が上がる。

導入時のベストプラクティス。

• ボランティア制ではなく、仕事として生産性改善に取り組むことで、会社の意思決定に関与し、より強く関与感を感じることができる。そのため、新しい生産性改善チームを立ち上げることが良い。
• 全社会議だけでは浸透できない。チームや個別の場でも情報を伝えることが重要。
• ツール導入した後なかなか改善できない場合、そのチームに入って、一緒に開発しながら原因を特定する
  • 目標を組み込んで、メトリックスを見て計測する
  • Whyを教える

Four Keys改善だけはない。ZOZOTOWN/WEARの開発生産性向上の取り組み by ZOZO

講演ではなく、パネルディスカッションでした。

株式会社リンクアンドモチベーションと同じ取り組みをしていたようです。

• 活用されていなかったチームに入って、一緒に開発して取り込む

改善した後感じられる効果は。

• PRクローズ時間が24時間になった
• レビュアーに優しいPRが多くなったため、レビューがネックにならなくなった
  • サブタスクで分散してPRを作る
  • PRを細分化しすぎると、レビューが困難になるため、GitHubのテンプレートを使用して関連するPRを記入してもらっている

全社ワークスペースにGitHubを選んだROUTE06の開発生産性 by ROUTE06

結構ユニークなスタートアップ会社です。

業務プロセスとドキュメントの連続性を求めるために、すべてのものをGithubで一本化管理しているようです。もちろん、コーポレーションとHR部門も同じGithubでドキュメントを管理しています。

• code: 基本情報、ガイドラインなど
• discussion: 議事録など
• オンボーディングは1つのissueを読む
• 自己紹介もGithubでページのPRを出す

他の会社に活用できるか微妙な気がしますが、面白い取り組みだと思いました。

Four Keysを超えて〜信頼性はいかに開発生産性を高めるのか〜 by Google

グーグルの山口さんの講演でした。残念ながら本人は諸事情で会場に来ることができませんでしたが、オンライン上でも素晴らしい講演でした。

山口さんが強調したのは、開発生産性を測るためにFour Keysだけに頼るのは時代遅れだということです。Nicoleさんの本は2015年の作品なので、載せているのはFour Keys（デプロイ頻度、リードタイム、変更失敗率、復元時間）だけでしたが、DORAレポートによると、2018年からは「信頼性」を加えて、「Four Keys+1」として開発生産性を測るようになりました。要はいくら開発生産性が高くても、システムの信頼性が低ければ、お客さんのニーズに応えられないため、意味がないということです。

SRE分野の話となりますが、SLO（サービスレベル目標）及びSLI（サービスレベル指標）のことが話されました。

SLOが高ければ高いほど運用コストが高くなります。合理的な目標設定が必要となります。サービスの信頼性を高めるために、開発を遅らせる必要があり、逆に開発スピードを上げると信頼性が落ちるからです。

SLIはシステムによって違いますが、例えばウェブシステムだと。

• リクエストとレスポンスの可用性を測る
• レスポンスのレイテンシーを測る

などがあるでしょう。

ドキュメント化してSLIが誰でもわかるようにするのは重要です。そして、可視化して全員共有して、信頼性と速度、チャレンジのバランスをとります。エラーバジェットに余裕があれば、新しいチャレンジができます。逆にエラーバジェットの消費速度が早すぎると、チャレンジをやめて、信頼性を高めることに注力した方が良いのです。

グーグルのこのブログは参考になります。https://cloud.google.com/blog/ja/products/devops-sre/sre-fundamentals-sli-vs-slo-vs-sla

あるいは山口さんが翻訳したO’Reillyの本でも。SLO サービスレベル目標 ―SLI、SLO、エラーバジェット導入の実践ガイド

スタートアップと上場企業、二つの視点から見る技術的負債との向き合い方 by Fast Label, safie

わかったのはスタートアップでも上場企業でも技術的負債があります。

• 技術負債に向き合うチームを立ち上げて、定期的にやるのが多い。
• 有志者を募集して、技術負債に向き合う。精神的に負担が大きくなったら、普通の開発チームに移動するのがありえる。
• 3年後のイメージを提示して経営陣に決めてもらう。DXの向上にて、採用にもつながるなど提示する。

エンジニア1人から始めた開発生産性改善が、組織100名、経営をも巻き込んだ話 by GLOBIS, rector

経営陣とのコミュニケーションについて。

• 経営陣との合意形成については、お互いの信頼関係が大切。
• 経営チームのアジャイルマインドを強化するために、PO勉強派遣もした。
• 共通言語を作るのも重要である。例えば、デプロイ頻度が上がる　→　E2Eなどテストを充実する必要がある　→　品質が上がる。開発生産性が上がると、品質も上がるという共通言語でした。
• 20%のストーリーポイントは技術負債解消用に確保するのが破綻しやすい（機能開発が優先されるため）。専門チームを立ち上げた方が良い。
• 生産性を可視化するのは監視ではなく、あくまで自己管理のためにする。

感想のまとめ

• Four Keysで開発生産性を測ると、PRが小さくなり、クローズする時間が短くなる。レビューがネックにならなくなる。デプロイ頻度が高いと、心理的安全のため、エンジニアがテストを書くため、品質が上がる。
• 生産性の可視化を浸透させるために、工夫が必要。例えば、導入する理由、メリットを個別で説明する；導入問題ありのチームに入って原因を特定するなど。
• 生産性があることだけではなく、信頼性にも注意を払う必要がある。

さらに、個人的に会社の組織変更した後、開発生産性にどんな影響を与えているのが、感覚ではなく、経営陣と各マネージャー、エンジニアの共通言語として、可視化しても良いとも感じます。

注意点

開発が順調に進む時、PRの数で生産性を測れるなんてちょっと理不尽な感覚がありました。要はPRは。

• 難易度が違う
• ICと言っても開発のみ専念できる方と、開発以外の業務もある方がいるので、単純に比較できない

と測る反対派でした。

しかし、中長期的な観点で見ると、やっはりPRの数が開発の生産性と関係あると感じます。他の人と比較せず、過去の自分、同じチームの過去PR数などと比較すれば、成長しているかどうかをわかるので、良いのではないでしょうか。PRもレビューしやすくなるため、ある意味バス係数の高めることにも貢献できます。

開発生産性はソフトウェア開発企業にとっての生命線だと考えています。特にスタートアップ企業にとっては、開発生産性が会社の競争力となりますので、その重要性をしっかりと把握し、向上させることが必要だと痛感しています。