概要
こんにちは、kubellでAndroidアプリ開発部のエンジニアリングマネージャーをしている牛窪です（@sudo5in5k）。
弊部署にて「four keys」の計測を始めてから1年と少しが経過しました。この記事では、その計測結果を公開し、成果や失敗を率直に振り返りたいと思います。
four keysの定義
弊部署では「four keys」を下図の定義としています。
定義を若干Googleのものから変えている理由としては、下記の理由から単純に「本番環境へのリリース頻度」とすることができないためです。
- Webやサーバーサイドと違って高頻度でリリースを行うことができない
- Androidの場合Google Playからの審査が通ってはじめてお客様に価値を提供することになる
- 弊部署ではWeb, iOSなど他プラットフォームとリリース内容の時期を一定揃えるため、2週間に1回のリリースをしている
- アプリのアップデートは通信をともなうため、ユーザーは高頻度にアップデートが降ってくることを望んでいない
そのうえで、「デプロイ = リリース可能状態にしておくこと」と捉えると、弊部署としては（リリースの1段階前としては）mainブランチへのマージがそれに該当すると考えました。
他社事例もふまえ、モバイルではこの考え方がスタンダードだと判断しました。
計測の仕方
弊部署ではデプロイ頻度はFindy Team+の結果をそのまま使っています。別途消化できたチケットの数も集計していますが、GitHubのmainブランチに直接マージしないがドキュメントの整備やその他タスクをしていることもあるため集計しています。基本はFindy Team+からとった数字を参考にしています。
リードタイムに関してはJIRAのレポートのうち、管理チャートで出力される値を参照しています。弊部署はカンバン方式で開発を進めており、「設計・開発・レビュー・完了」というステータスで分けています。これらのステータスに滞在した合計時間をとっています。 カンバン方式にした経緯は弊社の以前のブログをご覧ください。
変更障害率及びサービス復元時間に関しては、アプリのバージョンごとに障害が起きたか・起きていないか、起きた場合どれくらいの時間がかかったかをスプレッドシート上で記録しています。一定期間の移動平均ではなく、計測開始した2023年8月から現在までの数値としています。
計測結果
いきなり惜しげもなく公開します！
本格的に「four keys」の計測を開始したのは、2023年8月からです。
それ以前にも一部で独自に計測していた項目はありましたが、全社として「four keys」を計測し、組織の健康状態を測る指標として掲げるようになったのはこのタイミングです。
弊部署ではそのタイミングから毎週のふりかえりで週ごとの数字を共有していますが、月毎にこれまでの結果を公開することでみえてくるものもあると考えています。 それではご覧ください。
デプロイ頻度
リードタイム
変更障害率
サービス復元時間
評価
それでは、結果に対しての要因を深ぼっていきます。
デプロイ頻度が落ちていないか？
線形でトレンドラインを挿入してみるとたしかに減少していそうです。 要因を探っていきます。
全体的に下降している？
いくつか要因があるなかで、組織体制の変更による影響が高いと考えています。 2023年8月からこれまでチームメンバーの大幅な変動がありました。特に、複数のメンバーが退職し、また新たにチームに加わったことにより、エンジニアリングチームの構成が大きく変わりました。
加えてAndroid専門の部署として独立し、私が2024年7月エンジニアリングマネージャーになりました。
採用が成功した結果、コードコミットするメンバー数は自分が入る前と変わらなくなったことは成果だと考えています。
しかし、退職した既存メンバーと新規メンバーでは組織特有の知識や業務フロー、過去のプロジェクトの背景など、暗黙の了解やノウハウの差があります。 また、オンボーディングはじめ新規メンバーには知識や仕事の進め方をキャッチアップするための準備期間が必要なため、すぐに成果が出せるわけではありません。
その点も考えると下降傾向なのは納得がいきます。
2024/8と2024/11に極端に落ち込んでいる？
特にこの2つの期間が落ち込んでいそうです。なぜでしょうか？
8月については次の下半期にあたる目標を設定する時期で、メンバーとの面談や部署として目標をどうするかに時間を一定割いていました。加えて私がエンジニアリングマネージャーとなった関係でコードコミットが難しくなったため、その分の減少もありそうです。
それと同時に、新しく始まるプロジェクトのキックオフや事前調査がはじまるなど走り出しの時期がかなり強い側面を持つ月となりました。
そのため、GitHubのmainブランチにマージされていない調査関連のチケットの比率が高くFindy Team+のGitHubをベースとしたロジックでは集計対象外になっている点も考えられます。
念の為、月次のチケットの消化状況を可視化してみました。一定凹んでいる月ではあるものの、傾向としては他の年月のものと特段変わらず、トレンドラインとしてはむしろ上昇傾向気味であることもわかりました。
11月については業務委託の休職の影響が考えられます。 こちらの業務委託の方はkubell内で参画年月が長いこともあり、影響力が大きかったです。
デプロイ頻度という「four keys」の指標1つとっても、これまでの組織体制の変更や休職のできごとから、メンバーの変更があっても生産性を維持していく必要性を痛感させられました。 なおさら自律性のある組織にするための仕組みづくりを整えていく必要があります。これは、マネージャーとしての私の反省です。
変更障害率が連続で上がっている期間がある？
弊部署の計測の仕方からすると、障害が起こった時点では数値として高く跳ねるものの、障害を起こした時点から期間が経過すればするほど変更障害率は下降していくはずです。 しかし、下期から上昇傾向なのが読み取れます。これはなぜでしょうか？
要因として、とあるバージョンの障害を修正した結果、「別の障害につながってしまった・別のデグレを引き起こしていると判断してすぐさま修正バージョンをもう一度リリースした」ことによるものです。これが8月と10月で2回発生してしまいました。
なぜこのような事態が起こってしまったのかを振り返るポストモーテムを部署内で開催しました。 その結果、初歩的な考慮漏れ・ミスによって発生したものでしたが、そもそもドメインが複雑なモデルにより可読性を著しく下げていると結論付け、それらを解消するためにメンバー全員で対応を進めています。
サービス復元時間はかなり改善できている？
変更障害率に課題はあるものの、サービス復元時間に関しては改善に向かっています。 そもそも障害が発生することをChatwork上で通知する仕組み作りや、障害であるとわかった時点で定例MTGなどスキップし全員で集まって障害対応をするというフローが確立しつつあります。
プロセスの改善や仕組みをつくることで、「four keys」の項目は改善に向かい・組織として成熟することができると信じていますし、全員で「こと」に向かうことの重要性を感じています。
結果をふまえ何をしているか・何をするか
上記の結果と評価から今後弊部署で取り組むことを言語化します。
1️⃣ 誰かが欠けても生産性を出し続ける仕組みづくり
全員で「こと」に向かうフローへ
組織の生産性を維持・さらに向上するために、特に重要なのは部署のメンバーの変動に柔軟に対応できる体制の構築です。個々のメンバーが欠けても、生産性を最大限に引き出すための仕組みを作ることが、今後の課題だと感じています。そのためには、全員で「こと」に向かうフロー状態・フロー効率の体制を整える必要があります。
これまでプロジェクトや仕事の進め方の性質上、リソース効率を意識して動いていくことをしていました。 しかし、これまでの体制変更をふまえ、メンバーの知識差が現れ・取り組む内容やキャッチアップする問題の属人化が発生するようになってきたと考えています。
そのためそのあり方を撤廃し、全員で「こと」に向かえるようなあり方としたいです。
具体的には、
・何に今注力するべきなのか認識を揃える ・1つのエピック(テーマ)に基づいてモブのような振る舞いで全員がそのエピックに触れる進め方を推進 ・日々の業務やチケットの処理の流れを標準化し、誰が担当してもスムーズに進められるようにする ・コードレビューやテストのプロセス、リリースフローを簡素化・明文化する ・コードレビューや技術的な意思決定が個人に依存しないよう、文書化やガイドラインを整備
などが挙げられます。 それらに対して以下のことを取り組んできました。
・「技術負債」に関する意志統一と負債の分類、そのうえでどの負債に取り組んでいくのか決定する合宿を開催 ・エピックの数や同時に取り組むチケットの数を一定引き締めることを意識した日々の開発 ・コードレビューをなにより優先することを部署内ですり合わせ ・テストのフレームワークの使い分けや書き方の意志統一 ・GitHub Actionsによるリリースフローの一元化とドキュメントの拡充 ・ADRによる技術的な意思決定の証跡を残す
今後この取り組みの成果が出てくることを期待しています。
知識の共有とリーダーシップの分散
ドメイン知識の共有は欠かせません。特に弊社チャットアプリのような複雑なシステムでは、個々のメンバーが持っている知識を効率的に伝える仕組みが求められます。
そこで、定期的なナレッジシェアの場を設けるだけでなく、Wikiやドキュメントでの共有を徹底することで、他のメンバーがスムーズにその知識を活用できるようにしていく必要があります。
弊部署では最近「モブドキュメント」を実践しています。特定の画面に対してこういった導線がある、こういった機能があるといったものをまとめたドキュメントをモブで作る取り組みをしています。 そのドキュメントをみることでテストケースが作成できるくらいにするクオリティとし、自部署だけでなく他部署にもAndroid/モバイルの仕様を理解してもらうことが狙いです。 この取り組みをするようになってから画面に対しての細かい仕様をメンバー全員が理解できるようになってきています。
別視点では、個々のメンバーがリーダーシップを発揮できる環境を作るためには、権限委譲が重要です。小さな意思決定を積極的にメンバーに任せ、責任感を持たせることで、自律的な部署運営ができるようになります。これにより、メンバー全員が部署の成長に貢献できる仕組みができ、組織の健康度を保つことができます。
弊部署では毎週技術的な意思決定を話し合う「意思決定会」を設定しています。ライブラリの導入をしたい、特定の書き方にコードベースを変更したい、というような小さなことでも相談できる空間を作り自律的な部署運営の一助になっていると思います。
2️⃣ 価値観の認識を揃える
部署にいるメンバー全員が共通の理解を持って一丸となるための仕組みづくりが必要です。特に「four keys」のような指標に基づく改善活動では、全員が同じ方向を向いて行動しなければ効果的な成果を得ることができません。
とはいえ、共通の理解を作ることは難しいです。みなさんのチームではどのように共通理解を得ているでしょうか？
私は、会社のミッション・ビジョン・バリュー(MVV)がそのヒントになると考えています。営利企業として、MVVには「求めている未来の姿・戦略・マインドセット」が色濃く現れていると考えています。
弊社のMVVはオープンにされており、私は特にバリューの項目が気に入っています。
kubell COMPASS Ver 1.0.0 - Speaker Deck
以上を自分たちの部署に置き換えた時、どういった価値観や行動が賞賛されるのか？を考える時間をとることにしました。
その結果、まとめると以下のアウトプットが出てきました。
価値観
・経験年数に関わらずAndroidエンジニアのプロフェッショナルでいる ・古いものは「カイゼン」し、新しいものは探索する責任がある ・仮説・想像だけで物事を判断しない姿勢
行動
・特定が難しいクラッシュや警告でも、見てみぬふりをせず諦めずに取り組む ・想像だけで判断せず、他のメンバー・部署が抱えている課題を一緒に解決できないかを考え・巻き込む ・ユーザーの問い合わせや障害に対していち早く取り組む ・あまり自分だけで悩まず部署メンバーを巻き込んで相談・解決する ・他の人が動きやすいようなアウトプットを行う (ドキュメント・チケット・PRの作成など)
これらの価値観や行動が浮かんできたのはマネージャーの私としてはとても嬉しいと思っています。
ただ、上記のように1回考えるだけで終わりではなく、これが日常行動に現れるよう定期的に見直すことで、メンバーと共有する機会を増やし、共通言語としての役割を果たすようにしていきます。
3️⃣ 長期視点の共有の継続
理想の状態に向かって進む過程で、目の前の指標だけにとらわれず、長期的な視点を持ち続けることが重要です。特に「four keys」を改善する過程では、スモールステップでの改善が積み重ねられ、それが大きな成果につながるという認識を持つことが大切です。
例えば、短期的にはデプロイ頻度や変更障害率の数値が落ちているかもしれませんが、その背後にあるプロセスの改善や組織文化の醸成という成果が少しずつ見え始めている段階です。短期的な成果だけでなく、組織としての成長を意識しながら、成果が上がっている過程も重要視していく必要があります。
弊部署では毎週数値に関する振り返りをして、月次の数値を別途共有し喜びを分かち合ったりしています。 しかし、もう少し長期の視点でのふりかえりを行うことで、新たなプロセス改善や文化作成に気づく仕組みを今後は充実させていきたいです。
4️⃣ 上記を支える新たな指標の作成
上記のように部署のあり方を変えようとするなかで、そのあり方を叶えるためには「four keys」の数値がどのくらいの世界であると実現できそうか意志統一をすることが必要だと考えています。
加えて、現在の指標を単に追うだけではなく、部署の進化に合わせて柔軟に指標をアップデートしていくことも必要です。弊部署では、「four keys」以外にも、一定期間のうち取り組むエピック数やWIP（Work In Progress）数などの指標を導入することで、全員が「こと」に向かう姿勢を表現できるのではないかという仮説を持っており、それらを追加する予定です。
この結果がどうなるか私自身も楽しみですし、ぜひ今後とも上記の結果を発信していきたいと考えています。
さいごに
「four keys」の1年間の振り返りをしてきました。マネージャーとしてまだまだこの課題に取り組む余地が多くあることが理解できました。
理想的な状態を目指すことは大切ですが、メトリクス自体が最終的な目的ではないことを忘れてはいけないと考えています。「パフォーマンスの向上＝メトリクスの改善」 という式が成立するわけではありません。メトリクスを改善することにばかり注力してしまうと、逆に部署メンバーの負担が増えたり、無駄なコストが発生することもあります。
そのため、メトリクスの結果を単なる数字として捉えるのではなく、それを改善するためのプロセスや取り組みが本当にメンバーにとって有益であるかを常に問い続ける必要があります。
そして、最も重要なのは、組織文化の醸成とメンバー一人ひとりの成長です。私は文化が生産性を作ると信じています。メトリクスを通じて明らかになった課題を解決しながら、理想の部署に近づいていけるよう、日々の活動を改善していきたいと思います。
さいごのさいごに宣伝です！
上記の開発生産性ならびに「four keys」のことについてオフラインで話します！
STORESさんのオフィスで4社合同でモバイルに関連することを発表させていただきます。弊社からは私牛窪と奥澤（@okuzawats）が登壇します。
私は上記の内容を含めた開発生産性ついて、この記事をまとめつつ生々しい話も添えてお話しします。参加枠も限られていますので、是非お早めに申し込みください！
懇親会もありますので、直接部署の雰囲気や開発生産性・チームビルディング・マネジメントについて一緒にお話ししましょう🙏
もし、上記のイベント参加が難しいようでしたらカジュアル面談でも歓迎しています！是非お話ししましょう！
