概要

NewsPicksは「最高の開発体験の追求」をしている会社です。エンジニア向けのサイトの1ページでも謳っており、そこから弊社高山の記事に辿れるので、こちらも読んで頂けると幸いです。

そして、これはサーバーサイドだけの話しではなく、モバイルチームでも同じように開発者体験向上を目指し、Four Keysを追っています。
Four Keys とは、ソフトウェア開発チームのパフォーマンスを計測する4つの指標です。Four Keys 指標を用いることで、ソフトウェアデリバリの「スピード」と「安定性」を測定できます。
いわゆる組織の開発生産性が可視化できるということですね。

私が所属するモバイルチームもさまざまな改善をすることで、Four Keysの指標が少しづつ改善しており、「エリートDevOps チーム」に近づいてきました。
ちなみにNewsPicksのモバイルチームは、モバイルのDevOps的な役割と事業的な開発の両軸を担当しているチームになります。両軸を担当しつつ、ここまで開発者体験の向上が実現できているチームは珍しいかもと自画自賛しております。
今日は、優秀なモバイルチームの取り組みをエンジニアリングマネージャーのko2icが代表して紹介します。

どうやって指標を確認しているの？

我々は、Findy Teams+というサービスを利用しています。GitHubと連携して、Four Keys指標を簡単に可視化できます。
頻繁にアップデートされてるし、我々のチームとしては必須のサービスとなっております。オススメです。（Findyの回し者ではありませんw もっといいサービスがあったら乗り換えます。ってことでFindyさんにプレッシャーを与えておきますw）

NewsPicksのFour Keysはどんな感じ？

GWを除いた過去3ヶ月（これはAndroid）の結果がこんな感じです。数字の左にあるアイコンが金・銀・銅でこれによって優秀なのかの目安になります。我々のチームはデプロイ頻度と平均修復時間が優秀ということになります。直近1ヶ月にすると平均障害率も12%（金）と改善されてます。実質、金に届いてないのは「変更のリードタイム」だけとなります。

これらの指標について我々モバイルチームの場合について説明しておきます。

まず、「デプロイ頻度」についてです。サーバーの場合はリリースの頻度（つまりリリースタグの作成頻度）のことですが、モバイルチームではmasterブランチにマージした回数を表しています。我々のブランチ戦略はGitHub Flowを採用しています。なので、masterブランチにあるということはいつでもリリースできる状態ということです。モバイルの場合、リリース頻度を増やすとユーザがアプリを更新する頻度が上がるということです。ユーザによっては頻度が多いとギガ消費が増えるなどの理由で嫌悪する方もいるので、何度もリリースするのは良くない場合もあります。なので、masterにマージしたことを「デプロイ頻度」にしています。
「デプロイ頻度」が4回ということは、1日に4つのPRがmasterにマージされているということになります。Androidは計測対象のメンバーが4人いたので、1人が1つ毎日マージしているイメージです。

次に「変更のリードタイム」です。これはmasterブランチへのマージされたプルリクに紐づくすべてのコミットのmasterブランチへのマージまでの時間の平均値になります。
我々の場合、ここを減らすのは非常に困難です。なぜなら、事業的な開発のリリース判断は我々チームだけではなく、サーバーサイドの開発 / デザイナーの確認 / PdMの最終判断など関係者が多く、自分達だけで解決できないからです。とはいえ、ここが最も改善余地も多く、実際に大幅に改善されています。実装したものはすぐにリリースし、ユーザ反応を見たいというモチベーションがあるメンバーが多いため、ここを減らす努力を各々しています。

次に「変更障害率」です。hotfixブランチまたは、revertブランチが占める割合です。デプロイが原因で本番環境で障害が発生する割合をおおよそ把握することができます。我々は、ストア公開されている不具合は全てhotfixブランチを作成しています。過去から存在している不具合もこの運用にしているので直せば直すほど、ここの値は悪くなりますが、リリース時のバグの発生を無くせているので、全体的なバグ数がどんどん減っている状態です。以前は、ここの計測をしていなかったのですが、安定性（品質）を犠牲にしてスピードを上げても意味がないので、しっかりと計測するようにしました。

最後に「平均修復時間」です。hotfixブランチでcommitしてからmasterにマージされるまでの時間です。優先度の高いバグは、masterにマージするだけでなくすぐにリリースしています。

改善前はどんな感じ？

正確に言えば日々改善を繰り返していますが、今年になってOKRにも掲げることで意識付けした結果、大きく向上しています。
これは、2022年の10月から12月上旬の指標です。（年末年始休暇があると正確ではなくなるのでこの期間にしました）「変更障害率」と「平均修復時間」は計測してませんでした。
「デプロイ頻度」は3.2 -> 4にUP。
「変更のリードタイム」は、192.1h -> 75.7hに大幅UP していることがわかります。

改善のために何をした？

詳細は別の記事で書くとして、色々なことをしてます。
OKRとして掲げたことが大きいかも知れません。

リアーキや技術的な負債の解消

これは全ての指標に大きく影響を与えてると思います。色々な負債の解消を継続的に行なっています。過去のものですが、ブログに色々書いてます。ここに書いてないこともたくさんしているので、別途記事にしたいと思います。

https://tech.uzabase.com/entry/2022/08/19/134127
https://tech.uzabase.com/entry/2022/04/20/143717
https://tech.uzabase.com/entry/2022/08/01/161831
自動テストでの品質保証

E2EテストやUIテスト、単体テストを充実させています。 E2EテストやUIテストは安定しないことが多い（本来はグリーンになるテストが通信速度の変化によりレッドになったり、クラウドにある端末の問題であったりする）ので、そこが起きないように安定化をして、夜間に再実行する仕組みを入れることで朝起きてエラー原因を探ることがなくなっています。
UIテストは細かな見た目のテストはコストが多くかかるのでほぼやっていなく、絶対に担保したい場合だけ、画像比較テスト（Visual Regression Testing）をしています。
以前は、リリース前直前に多くの手動テストをしていましたが、半分以上は自動テストにし、品質の担保ができるようになってます。今後も費用対効果を考えて無理のないように増やしていきます。
レビュー開始の速度を上げるための仕組み化
- PR作成をしたときにReviewerとassigneeを自動設定するようにしました。これは、.github/CODEOWNERS と .github/auto_assign.yml を書くことで実現しています。
- 朝10時にSlackにレビューしていないPRを送るようにしています。SlackでGithubアプリを入れて連携しておきます。画像のa7therさんのようにメンションになっていない場合は、slackで/github signin してgithubとconnectしておけば、メンションが来るようになります。
- Findy Teams+ のデイリープルリクアラート設定しています。これは毎日問題のありそうなプルリクがSlack上に送られてきます。一つ上のSlack連携の代わりに使えますし、振り返りでも利用できます。
- iOSチームではレビュー時間をGoogleカレンダーに入れています
- 仕組みではないですが意識付けとして、OKRで明確に「オープンからレビューまでの時間を16時間以内を継続する」としています。16時間とは、弊社の場合はコアタイムなしのフルフレックスですが、大体が10時から19時の間に仕事をしています。18時にPRを出して、10時には誰かがレビューをしている状態にはするということです。ただし、土日もあるので平均を落とさないように平日に早くレビューをしておく必要があります。自分の実装で区切りが出たり、集中が切れた時にはレビューをしています。
  Findy Teams+のサイクル分析で確認しています。
レガシーコードのレビューはしっかりやる.
上記でレビューを早くやるとしていますが、品質が低下すると他の指標が落ちるのでしっかりやります。新しいアーキテクチャ部分は単体テストもしっかり書けるし、見通しも良いので細かくレビューをしなくても品質の低下は滅多に起きないですが、昔からのコードは単体テストが書きづらいので、レビューで品質を担保する必要があります。上記のサイクル分析で、「レビューからアプループまでの時間」が少なすぎると問題だと思っています。現状、PRの1/5以上は3つ以上のレビューコメントがあるのでそれなりに適切にレビューがされていると思われます。
OKRで「直近1ヶ月の平均プルリククローズ時間（Ready〜Merge/Close）が56.4h以下になっている」と掲げた「変更のリードタイム」のところでも書きました「関係者が多くて他チームでの確認待待ちがある」ということなのですが、OKRで明確に書くことで他チームへの促す回数 / 早さも改善されていると思います。
めんどくさいことはどんどん自動化.
テスト系だけでなく作業の多くを自動化しています。
- リリース作業は当然、CIでやっていますが、「朝起きたら誰でも10分でリリース」できる状態を目指しています。
- ライブラリの更新PR作成の自動化
- ClickUpのステータス変更をGitHubのマージに紐づける
- モバイルチームへの依頼やバグをSlackに書いたらモバイルチームのClickUpにタスクを作成
- GitHub Issueに特定のラベルをつけたら、モバイルチームへのSlackとClickUp作成.
  などなど。
  本質的でない作業を減らすことでリードタイムの削減に繋がっていると思われます。
リードタイムを毎週確認する Findy Teams+で、毎週月曜日にSlackで次のように送られてくるので毎週確認するのは容易です。