天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

Four Keysで進める改善サイクル - Techmee vol.4に参加してきた

イベント参加レポート DevOps

timeedev.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

株式会社タイミーは「一人ひとりの時間を豊かに」をビジョンに掲げ、日々の開発を行っています。 そんな私たちが開発を通じて得ている学びを発信することで新しい取り組みを後押ししたり、アンチパターンに陥らない様に出来るのであればそれもまたエンジニア一人ひとりの時間を豊かに出来ているのではないかと考え、定期的に勉強会を通じて我々の学びを発信していく予定です。

第4回目はソフトウェア開発チームのパフォーマンスを示す 4 つの指標とされる「Four Keys」についての勉強会です。

Four Keysに関して腹落ち出来る理解をすべく「Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について」のブログを執筆し、200はてブを超える反響を呼んだyigarashi氏をお招きしてFour Keysの基礎やその重要性について講演いただきます。 また、タイミーではFour Keysを計測するだけではなく、その計測に基づいてイケてる開発組織になるべく改善活動に繋げています。CTOの亀田よりFour Keysの計測と実際の改善活動についてお話させていただきます。

会の様子

講演1〜30分でわかるFour Keysの基礎と重要性〜

speakerdeck.com

上記スライドのお話を聞いていきました。(話の具体的な内容はスライドで非常に綺麗にまとまっているため、ブログで記載するのは割愛します。内容が気になる方はぜひスライドをご覧ください！)

yigarashiさんのブログを見ていても思うことなのですが、説明の構成(説明の順序や詳しく説明する部分と軽く説明する部分のコントラスト...)がめちゃくちゃしっかりしているので、とっても聞きやすいですし、頭にもスッと入ってくるような内容でした。

LeanとDevOpsの科学やDORAに書かれていたレポートの主要な内容が本当に30分でわかるような発表になっていて感銘を受けましたし、ここ最近の更新点や直感的な例が複数提示されており、めちゃくちゃ綺麗にまとまった発表でした。

講演2〜『「ある程度」まで4keysが良くなるまでの道のりとこれから』〜

以下、発表の内容を記載していきます。(4Keys改善のためにやってきた中で効果があった具体的な取り組みを3つ紹介してくれました。

git-flowからGithub Flowへの移行

まず、オンデマンドにデプロイするためにgit-flowをGithub Flowへの移行をした話をしてくれました。

git-flowではリリースプロセスが煩雑*1なため、Github Flowへの移行をおこなったということでした。

最初にデプロイ方法をCLI(capistrano)->chatopsへ変更したことで、小さな修正が徐々にリリースの細分化が発生したそうで、これが一定のところまでいった際にGithub Flowへの移行が可能な状態になり、オンデマンドにデプロイすることができるようになったそうです。(開発者が、「何をデプロイするか」を自由に選べることで移行がスムーズに完了した)

監視を通したMTTRを素早くする

Timeeはサービスの特性上、意図しない変更の修復が遅れるほど業務に与えるダメージが非常に大きくなってくるということもあって、障害とまでは言えないような小さな変更の失敗もMTTR計測の範疇としているということでした。

Timeeは監視で検知できる範囲をとにかく厚くすることを意識しているということで、Datadog/Sentryを用いた監視*2やビジネス上の重要指標の定点観測やSLO監視、結果整合性の検査*3を実施しているということでした。

変化を導くポストモーテム

前提として、不具合は運用をしている限り必ず発生するものだという前提を置いているそうで、心理的安全性を重視しているということでした。
その上で、不具合が起きた時にそれを「やらかし」として扱うのではなく、一つの学びとして捉え、ポストモーテムを実施しているということでした。

ポストモーテムは、

  • 影響範囲と原因
  • 事実確認(発生の時間軸/対応の時間軸)
  • ふりかえり(「障害対応」の再現性を増やすには/「障害」の再現性をなくすには)

のテンプレートで実施しているということで、ここに観点としてFour Keysを組み込み、対応の理由づけを強めつつ、細かいデプロイや監視などの価値を開発者がより実感しやすくすることができているそうです。

Q&A+パネルトーク

以下、Q&Aとパネルトークの内容を常体で記載していきます。

Four Keysの指標が良いからハイパフォーマーなのか、パフォーマンスが良いからFour Keysの指標が良くなるのか、について何かしらの説明は存在するのか？
  • 因果性はあるけど相関している傾向があるよね、というのがFour Keysだと考えている。
  • ハイパフォーマーの言葉の定義は、クラスター上スコアが良かった人を呼んでいるという点は意識しておいた方が良い。ただ、Four Keysがパフォーマンスに寄与する全ての指標ではないので、他の定義されていない指標と一緒に指標が良化した結果Four Keysが良化したという可能性もある。
デプロイ頻度を上げると良いという空気感をどう作るか？周りからは冷たい反応をされることはないか？
  • スタートアップだと、割と受け入れやすいので環境的には恵まれていたと思う。受け入れられないなら、LeanとDevOpsの科学をみんなで読むとかが良いのでは。
  • LeanとかDevOpsの価値観が組織にないと理解はできないだろうなと感じた。エンジニアに限った話で言えば、ビッグバンリリースを喜ぶ人はいないと思うので、そういう切り口から話せそう。
Four Keysをはじめとした開発組織の改善の主体は誰か？
  • チームという話で言えば、yigarashiさんがリードしている。世間的にはテックリードと呼ばれるような人がやっている印象がある。あとははてなだと技術の横串グループが導入している。
  • メンバーが少ない時はkameikeさんがリードしていた。組織が大きくなって中長期的な施策を実行する必要が出てきたときは、開発プラットフォームチーム&チームにいるリードエンジニアがリードしていた。
オンデマンドリリースを目指すために、品質保証の観点で考えている部分を聞きたい(自動テストなど)
  • 自動テストはもちろんあるが、リリースする影響範囲にまつわる部分の手動テストを厚くやっている。影響範囲が限定的にできているので、この手法がとれているとは思う。あとは、心と体を慣らすために影響範囲が自明なものをそんなにQAプロセスをゆるく通して出す、みたいなことをやってもいいのかな、とは思う。
  • どんどんリリースしていく中で、変更のリスクが大きい場合のみQAをしている。変更のリスクが小さい場合は一定のリスクはとった上でリリースする。
Four Keysはどのような企業にとっても重要なのか？
  • DORAの研究によれば組織の業績と結びついているので、基本的には重要だと思う。ただ、LeanとDevOpsの価値観を体現することに痛みを伴うような会社だったり、価値観と全く合わない業界だと重要ではないのかな、と思う。
  • 継続的に運用していくようなソフトウェアを作る企業なら、重要だと思う。
リリースタイミングがビジネス側の都合で決まるものは意図的に計測から除外するのか？
  • 傾向を探るために見ているという側面もあり、MTTRなどは一部除外している。
  • 一般論になってしまうが、異常値なことがチームとして合意しているのであれば除外してもいいと思う。ただし、ユーザに機能が見えることと本番にデプロイされることは同一視しないほうがいいと思う。
Four Keysを先行指標としては扱っていないのだが、そういう事例はあるか？

体感でしか計測できていないところもあるので難しいが、デリバリーを良くすることと機能開発は評価軸が少し変わってくるので、バックログを整理する際にFour Keysを活用して優先決めしたりしている。

デプロイ頻度は既に高い状態(半日に一回)だと思うがどこまで持ってきたいとかの理想は持っているのか？

現場のデプロイ頻度で満足はしている。
そのため、頻度というよりも、デプロイで出している価値を計測しようかな、みたいな話はしている。
また、人を増やすとデプロイ頻度は落ちるので、人が増えてもなるべく落とさないようにしようとかは考えている。

4つのメトリクスにもし優先順位をつけるとしたら何から始めたらいいのか？
  • (スタートアップというコンテキストもあるので)デプロイ頻度が最初の一歩としてはおすすめ。
  • やはりデプロイ頻度がおすすめ。最悪、手でPRを計測できるというのがすごく大きい。また、どんどん上がっていきやすい指標でもあるので、改善効果も得やすい。
  • 測りたい！といって何も測らないのは時間の無駄だと思うので、masterマージの指標を測るなど、手でとりあえず測ってみるのはあり。
経営層への説明責任のために導入を考えているので、経営層からどのような反応があったのか知りたい

前提として、LeanやDevOpsの文化が染み付いているのか？は非常に重要だと思う。また、指標を達成するのが必達かどうかみたいなところは見ておいたほうがいい。(必達な指標になってしまうと厳しい)

会全体を通した感想

理論的な部分を最初にyigarashiさんから聞いた上で、具体的な組織での実例をkameikeさんの方からお話してもらい、最後にさまざまなコンテキストの中でFour Keysの考え方をどのように活用しているのか？を聞くという流れがすごく良かったです。

yigarashiさんのスライドや発表は色々なところで紹介させていただこうと思います笑

*1:どうしても手作業的な手順が必要になる、リリースのタイミングを示し合わせるコミュニケーションが発生する、「リリース作業」にオーナーシップを持つ人が必要、場合によっては変更者からの引き継ぎが発生する

*2:CPU/メモリ/NW/リクエストに占める500の割合/アプリケーション上で発生する500の種別/エンドポイントごとに処理にかかっている時間/内部で実行されている処理の負荷割合...

*3:永続化されたデータの妥当性をチェック