SMARTCAMP Engineer Blog

スマートキャンプ株式会社(SMARTCAMP Co., Ltd.)のエンジニアブログです。業務で取り入れた新しい技術や試行錯誤を知見として共有していきます。

FourKeysを横へ広げる

開発プロセス FourKeys

はじめに

こんにちは！スマートキャンプ開発エンジニアの井上です。
スマートキャンプでは少しずつFourKeysを活用し始めており、その中でも今回はプロダクト間の横の連携でFourKeysを広げた話をしていきます。
eyecatchの画像は生成AIにキャンプ✖️FourKeys✖️横へ広げる✖️テックブログで生成したらブログの内容には合わない壮大なものができてしまいました。。

前提

スマートキャンプはBOXIL SaaS、BALES CLOUDと複数のプロダクトが存在します。
この開発組織はそれぞれ独自の成長を速い速度で行えるようにそれぞれの開発組織が存在します。
このため共通の文化もあれば独自の文化が存在する開発組織です。

FourKeysとは

DORAが実施した6年間の研究からソフトウェア開発チームのパフォーマンスを示す4つの指標があることがわかりました。
これらの指標をFourKeysと呼びます。
また、このFourKeysの指標の中でも下記のように速度と安定性を示すものと理解しています。

  • ソフトウェアデリバリの速度
    • デプロイの頻度: 組織による正常な本番環境へのリリースの頻度
    • 変更のリードタイム: commitから本番環境稼働までの所要時間
  • ソフトウェアデリバリの安定性
    • 平均復旧時間: 組織が本番環境での障害から回復するのにかかる時間
    • 変更失敗率: デプロイが原因で本番環境で障害が発生する割合（%）

FourKeysを横に広げるとは

もともとFourKeysはBALES CLOUDでTry的に計測や改善を行い運用していました。
ただこの取り組みはプロダクト組織が改善していることをデータで語れるようになるための大事なことになるためプロダクト組織全体でやるべきだと考えました。
考えてからは開発組織のリーダー層で相談しBOXIL SaaSとBALES CLOUDでFourKeysを導入を提案し実行していきましたが、上手く広げていくためにはどのようなことが必要なのかは私も迷いながらも進めていった経験を共有したいと思います。

横に広げるために必要な要素

振り返るとですが横に広げる際に下記の要素が大切だなと思っています。
ただ初めから気づいて定義できていたわけではなく探索と検証を繰り返した結果この要素だなと感じている部分です。
ここは実際は色々試行錯誤をしました。

  • 橋を作ってくれる協力者をつくる
  • FourKeysの目的を明確にする
  • FourKeysが与える身近な効果を伝える
  • FourKeysへの取り組みをしやすくし習慣化する

橋を作ってくれる協力者

これは横という表現をした意図でもありますが、FourKeysはトップダウンでやることが決まったものではなく1プロダクトが初めてFourKeysを活用し横に広げました。
私はBALES CLOUDのエンジニアなのでBOXIL SaaSチームの解像度は低くどのように伝えればいいかを考えるための情報が足りない状態でした。
このためプロダクト組織として横に広げるには隣のプロダクトの知識や現場の声を拾い上げることが可能で、チーム状況の解像度が高い人に一緒に作っていってもらう必要があります。
この一緒にやってもらう協力者を作るためにはまずは1人に共感してもらい仲間になってもらうことがとても大事です。
このため下記の部分を資料を元に丁寧に伝えました。

  • FourKeys導入の意図
  • 期待する効果
  • 今後どのようにしていきたいか？

実際かなり助けてもらうことが多くBOXIL SaaSチームにはとても感謝しています！

FourKeysの目的を明確にする

FourKeysは生産性の指標としてよく使われますが、実現したい状態は生産性を上げた先にあります。
あくまで私も含めてFourKeysは目指す場所に到達するために見るべき指標の1つとして捉えています。
また一緒に目指していく人たちにも生産性を上げた先でやりがいのあるものがちゃんとある状態にしたかったというのもあります。
実際にこの定義は「生産性をあげ試行回数を上げることで価値への到達を早くすること」を目的としました。
プロダクト作りは一度作って終わりではなく、FBサイクルを回して研ぎ澄ませて価値あるものにしていくのでそのためにはFBを受ける回数を増やすことが大事という考えを元にしてこの定義にしました！
この部分認識が異なってはやる意義が薄れてしまうので伝える際には資料を作成したうえで説明しました。

FourKeysが与える身近な効果を伝える

生産性は人によってはすこし遠いように思えるかもしれません。
そうなるとFourKeysを元に改善することでの報酬がわからなくなり、良い取り組みでも取り組まれなかったり
人によって取り組みへの温度差が発生しチームとしての取り組みができない状態になってしまいます。
この問題はFourKeysというものが開発という活動の身近な部分にどんな影響を及ぼすかのが明確になっていないことが問題になり起きていました。
そのためこの対策としてFourKeysを元に改善することで起こる身近な改善や問題があることを伝えました。
さまざまな要素はある中で開発において身近であろう点を下記のスライドで伝えました。
うまいこと伝えられたかはわかりませんが、反応が良かったので伝わったのかなと思っています。

FourKeysへの取り組みをしやすくし習慣化する

どんないい取り組みも一歩目が難しく重くなります。
このためいかに簡易的に確認できるかと最初にやることのハードを下げるかが重要です。
またハードルを下げたうえでやることが当たり前になるように習慣化していくことが大事になります。

ハードルを下げる

こちらは協力してくれたBOXIL SaaS側のリーダーに相談しチーム状況やチームのFourKeysへの認知度を確認しアクションを一緒に考えました。
別チームのことは完全には理解できないため一人で考えずに協力を依頼したことで適切なハードル設定にできたかなと感じています。

課題に近く簡易的に確認可能なものを用意する

取り組む人たちも自分たちへのメリットがないものや課題感が無いものには取り組めないかと思います。
取り組むためには自分たちの視界に入っている身近な課題を解決できる手段の一つであることを説明したうえで関係性のある数値を出すことが重要でした。
直近の課題としてはレビューの時間が長くなっている傾向があるという話を聞いていたので、FourKeysのリードタイムの中でもレビューからApproveまでに時間がかかっていることをデータで示し
追加でレビュー時間とレビューが分散されているかをダッシュボードで可視化しました。

習慣化する　BALES CLOUD

BALES CLOUDではFourKeysのリードタイムに関連する指標として完了率というものを定義しスプリントごとに開発アイテムの完了率を見るようにしました。
まずはスプリントごとに完了することを意識したうえで、FourKeysのダッシュボードは誰でも見れる状態にしました。
これによりチームが達成意識をもつとともにチーム全体でリードタイムを改善する意識がついたと思います。
言葉として「今週はレビューが遅くなってしまった」や「全体の完了率が悪かったなど」が振り返りででてきたのが印象的でした。

習慣化する　BOXIL SaaS

また、BOXIL SaaSはレトロスペクティブで毎回FourKeysを確認するというアジェンダを入れたところFourKeysを意識する習慣ができたそうです。
実際にデータで見るだけでもリードタイムは順調に改善しており、コードレビューも分散されている状態になっていました。
これはとても嬉しかったです。

今後目指したいところ

データで生産性や価値を語れる組織を目指していくとともに自分たちが生産性をあげることで企業の競合優位性になっていきたいなと考えています。
どんなプロダクトでも価値につながるものを作り続けられるわけではなく、いくつかの試行を繰り返し価値へ到達すると思います。
なのでこの試行回数をいかに早く実行し価値にたどり着くのを早くするかはプロダクトや事業の競合優位性になりうると考えています。