Keysはどんな感じ?改善前はどんな感じ?改善のために何をした?終わりに概要NewsPicksは「最高の開発体験の追求」をしている会社です。エンジニア向けのサイトの1ページでも謳っており、そこから弊社高山の記事に辿れるので、こちらも読んで頂けると幸いです。Keysを追っています。ソフトウェア開発チームのパフォーマンスを計測する4つの指標です。指標を用いることで、ソフトウェアデリバリの「スピード」と「安定性」を測定できます。いわゆる組織の開発生産性が可視化できるということですね。チーム」に近づいてきました。ちなみにNewsPicksのモバイルチームは、モバイルのDevOps的な役割と事業的な開発の両軸を担当しているチームになります。両軸を担当しつつ、ここまで開発者体験の向上が実現できているチームは珍しいかもと自画自賛しております。今日は、優秀なモバイルチームの取り組みをエンジニアリングマネージャーのko2icが代表して紹介します。Teams+というサービスを利用しています。Keys指標を簡単に可視化できます。頻繁にアップデートされてるし、我々のチームとしては必須のサービスとなっております。いいサービスがあったら乗り換えます。Keysはどんな感じ?直近3ヶ月のDevOps分析GWを除いた過去3ヶ月(これはAndroid)の結果がこんな感じです。数字の左にあるアイコンが金・銀・銅でこれによって優秀なのかの目安になります。我々のチームはデプロイ頻度と平均修復時間が優秀ということになります。直近1ヶ月にすると平均障害率も12%(金)と改善されてます。実質、金に届いてないのは「変更のリードタイム」だけとなります。これらの指標について我々モバイルチームの場合について説明しておきます。「デプロイ頻度」についてです。サーバーの場合はリリースの頻度(つまりリリースタグの作成頻度)のことですが、モバイルチームではmasterブランチにマージした回数を表しています。Flowを採用しています。masterブランチにあるということはいつでもリリースできる状態ということです。モバイルの場合、リリース頻度を増やすとユーザがアプリを更新する頻度が上がるということです。ユーザによっては頻度が多いとギガ消費が増えるなどの理由で嫌悪する方もいるので、何度もリリースするのは良くない場合もあります。masterにマージしたことを「デプロイ頻度」にしています。「デプロイ頻度」が4回ということは、1日に4つのPRがmasterにマージされているということになります。Androidは計測対象のメンバーが4人いたので、1人が1つ毎日マージしているイメージです。次に「変更のリードタイム」です。これはmasterブランチへのマージされたプルリクに紐づくすべてのコミットのmasterブランチへのマージまでの時間の平均値になります。我々の場合、ここを減らすのは非常に困難です。関係者が多く、自分達だけで解決できないからです。いえ、ここが最も改善余地も多く、実際に大幅に改善されています。実装したものはすぐにリリースし、ユーザ反応を見たいというモチベーションがあるメンバーが多いため、ここを減らす努力を各々しています。次に「変更障害率」です。hotfixブランチまたは、revertブランチが占める割合です。デプロイが原因で本番環境で障害が発生する割合をおおよそ把握することができます。我々は、ストア公開されている不具合は全てhotfixブランチを作成しています。過去から存在している不具合もこの運用にしているので直せば直すほど、ここの値は悪くなりますが、リリース時のバグの発生を無くせているので、全体的なバグ数がどんどん減っている状態です。以前は、ここの計測をしていなかったのですが、安定性(品質)を犠牲にしてスピードを上げても意味がないので、しっかりと計測するようにしました。最後に「平均修復時間」です。hotfixブランチでcommitしてからmasterにマージされるまでの時間です。優先度の高いバグは、masterにマージするだけでなくすぐにリリースしています。改善前はどんな感じ?正確に言えば日々改善を繰り返していますが、今年になってOKRにも掲げることで意識付けした結果、大きく向上しています。これは、2022年の10月から12月上旬の指標です。「変更障害率」と「平均修復時間」は計測してませんでした。していることがわかります。改善のために何をした?詳細は別の記事で書くとして、色々なことをしてます。OKRとして掲げたことが大きいかも知れません。リアーキや技術的な負債の解消これは全ての指標に大きく影響を与えてると思います。色々な負債の解消を継続的に行なっています。過去のものですが、ブログに色々書いてます。ここに書いてないこともたくさんしているので、別途記事にしたいと思います。https://tech.uzabase.com/entry/2022/08/19/134127https://tech.uzabase.com/entry/2022/04/20/143717https://tech.uzabase.com/entry/2022/08/01/161831自動テストでの品質保証E2EテストやUIテスト、単体テストを充実させています。E2EテストやUIテストは安定しないことが多い(本来はグリーンになるテストが通信速度の変化によりレッドになったり、クラウドにある端末の問題であったりする)ので、そこが起きないように安定化をして、夜間に再実行する仕組みを入れることで朝起きてエラー原因を探ることがなくなっています。Testing)をしています。以前は、リリース前直前に多くの手動テストをしていましたが、半分以上は自動テストにし、品質の担保ができるようになってます。今後も費用対効果を考えて無理のないように増やしていきます。レビュー開始の速度を上げるための仕組み化PR作成をしたときにReviewerとassigneeを自動設定するようにしました。書くことで実現しています。朝10時にSlackにレビューしていないPRを送るようにしています。SlackでGithubアプリを入れて連携しておきます。githubとconnectしておけば、メンションが来るようになります。デイリープルリクアラート設定しています。これは毎日問題のありそうなプルリクがSlack上に送られてきます。一つ上のSlack連携の代わりに使えますし、振り返りでも利用できます。iOSチームではレビュー時間をGoogleカレンダーに入れています仕組みではないですが意識付けとして、OKRで明確に「オープンからレビューまでの時間を16時間以内を継続する」としています。16時間とは、弊社の場合はコアタイムなしのフルフレックスですが、大体が10時から19時の間に仕事をしています。18時にPRを出して、10時には誰かがレビューをしている状態にはするということです。土日もあるので平均を落とさないように平日に早くレビューをしておく必要があります。自分の実装で区切りが出たり、集中が切れた時にはレビューをしています。Teams+のサイクル分析で確認しています。レガシーコードのレビューはしっかりやる.上記でレビューを早くやるとしていますが、品質が低下すると他の指標が落ちるのでしっかりやります。新しいアーキテクチャ部分は単体テストもしっかり書けるし、見通しも良いので細かくレビューをしなくても品質の低下は滅多に起きないですが、昔からのコードは単体テストが書きづらいので、レビューで品質を担保する必要があります。上記のサイクル分析で、「レビューからアプループまでの時間」が少なすぎると問題だと思っています。現状、PRの1/5以上は3つ以上のレビューコメントがあるのでそれなりに適切にレビューがされていると思われます。早さも改善されていると思います。めんどくさいことはどんどん自動化.テスト系だけでなく作業の多くを自動化しています。リリース作業は当然、CIでやっていますが、「朝起きたら誰でも10分でリリース」できる状態を目指しています。Issueに特定のラベルをつけたら、モバイルチームへのSlackとClickUp作成.などなど。本質的でない作業を減らすことでリードタイムの削減に繋がっていると思われます。Teams+で、毎週月曜日にSlackで次のように送られてくるので毎週確認するのは容易です。終わりにLeanとDevOpsの科学という書籍では、ハイパフォーマンスな組織は従業員エンゲージメント、事業的成功にも相関関係があるとしています。マイクロソフトでは継続的デリバリの改善によって、「仕事とオフのバランスに対する満足度」が38%から75%に跳ね上がったと言われています。Keys指標の改善をしてハイパフォーマンスな組織、つまり、従業員エンゲージメント・事業的成功(=ユーザ満足度がないと成功しないと考えています)を目指しています。こんな我々の組織では、エンジニアを募集しています。reserved.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。