FourKeysとDX Criteriaを用いた開発力・開発者体験向上の取り組み

READYFORのシステム基盤部でエンジニアリングマネージャーをしている熊谷です。
この記事は READYFOR Advent Calendar 2022 の21日目の記事です。

これなに？

昨年１２月に以下の記事で、開発力及び開発者体験を向上させるための取り組みとして、READYFORの組織体制を交え、FourKeys、DX CriteriaやSRE などを用いた方針について紹介しました。今回はこの１年間の結果を振り返りつつ、紹介できればと思います。開発力や開発者体験の取り組みを日々試行錯誤しながら、改善に取り組んでいる方も多いと思いますので、何か参考になれば幸いです。

目次

これまで開発力/開発者体験を向上させるために様々な施策を実施していく中で、FourKeysやDX Criteriaの値がどのように変化したのか、これまでの取り組みを振り返りつつ、以下の流れで紹介していきたいと思います。

1. FourKeysの振り返り (開発力)
   1. デプロイ頻度
   2. リードタイム
   3. 施策の振り返り
      1. 施策1. コンテナ化(EC2➡︎ECS移行
      2. 施策2. 自動デプロイ(&オートスケール
      3. 施策3. GitHub Flow導入
      4. 施策4. フィーチャートグル導入
      5. 施策5. マイクロフロントエンド導入
      6. 施策6. Dependabot運用
      7. 施策7. 技術的負債の測定と解消
2. DX Criteriaの振り返り (開発者体験)
   1. 「カテゴリ」ランキング
   2. 「カテゴリ」昨年比較
   3. 「項目」別の改善ランキング
   4. バックエンドとフロントエンドの差分
   5. エンジニアへのアンケート結果

1. FourKeysの振り返り

昨年からFourKeysの速度指標である「デプロイ頻度」と「リードタイム」を計測し始めており、開発力向上の取り組みの主要指標として掲げています。( 計測方法については昨年の記事に書いているので本記事では触れません )

2-1. デプロイ頻度

先に結果から述べると、デプロイ頻度は昨対比で２倍以上伸びる結果となりました。 この２年間の平均デプロイ頻度の推移は以下の通りになります。 最近では、デプロイの日程が詰まりすぎて、デプロイができないという嬉しい悲鳴もちらほら聞こえてきます。(それは来年の課題となっていますが。。 )

もちろん、なぜデプロイ頻度が上がったのか、その要因はしっかり深堀りする必要はあると思いますので、その辺りは「2-3.振り返り」で言及していきたいと思います。

2-2. リードタイム

次にリードタイムは以下の通りになります。

リードタイムの解釈が国内外/企業毎に異なるため(※2)明確にしておきますが、ここでのリードタイムの定義は「コードの初回コミット」から「本番ブランチへのマージ」までの時間になります。課題感として、一つのPullRequestが大きすぎてレビュー自体に時間が掛かってしまうケースや、コミュニケーション齟齬によりレビューが円滑に進まなかったり、放置されたりするケースも発生していたため、そこの測定・改善する上でも一定有効であると考えています。

ちなみに 「本番ブランチへのマージ」から「本番環境へ反映」の時間は、リポジトリ毎に多少異なりますが、数分〜２０分程度とほぼほぼオンデマンド水準ではあります。( 欲を言えば10分以内に抑えたいところではありますが。 )

2-3. 振り返り

デプロイ頻度やリードタイムは、各領域の様々な改善施策や個々の能力向上などの積み上がりも反映されるため、よほどインパクトがない限りは、一概に要因を特定することが難しい事が多いなと思っていますが、いくつか取り組みを紹介できればと思います。

施策1. コンテナ化(EC2➡︎ECS移行)

元々EC2で運用を行なっていたのですが、2021年8月にコンテナ化を進め。ECS移行を行いました。３ヶ月移動平均をみるとその月を起点に継続的な上昇傾向にあることが確認できます。コンテナ化することで各種ライブラリの追加や更新がDockerfileで完結し、EC2の煩わしさが解決できたのは非常に良かったように思います。その後、セキュリティシフトレフト文脈でRubyやRailsバージョンアップを進めるのですが、EC2の時と比較して、格段に対応がスムーズに進められるようになったと思います。

施策2. 自動デプロイ(＆オートスケール)

ECS移行に伴った対応ではありますが、元々デプロイ周りがあまり整備されておらず、本番ブランチにマージした後に手動でコマンドを叩き、デプロイするという割と危ない運用でした...。リードタイムの観点でも明らかにボトルネックでしたが、PullRequestマージ後に自動でデプロイされるように整備することで、開発者体験も大きく改善されたように思います。 ( このあたり、今時ではごくごく当たり前なフローではあると思うのですが、それなりに歴史の積み上がった当時のシステムからすると地味に大変な作業ではありました。)

また、EC2の時はAuto Scalingは導入していたものの、インスタンスを増やした際に一手間必要で、完全に自動スケールするような構成ではなかったのですが、コンテナ化に伴い適切にオートスケールできるようになりました。これは直接的にデプロイ頻度にインパクトした分けではないですが、トイルの削減という点では最低限必要な対応であると思います。

施策3. GitHub Flowの導入

元々若干トリッキーなブランチモデルだったのですが、GitHub Flowに寄せました。ブランチモデルとしてgit-flow、 GitHub Flow、 GitLab Flowなどいくつか選択肢があると思いますが、何度か議論を重ねて、結果的にGitHub Flowを変更しました。これにより無駄にブランチを切ったり、テストを流したりする回数が減り、わかりやすくリードタイムの短縮に繋がったように思います。

議論の段階では、直接mainにマージするGitHub Flowに対して懸念の声もありましたが、実際に運用してみると特に支障なく運用できています。

施策4. フィーチャートグルの導入

これまで大型の機能開発はビックバンリリースをする傾向にあったのですが、今現在ではバックエンド・フロンエンド共にフィーチャートグルを用いて、影響範囲を抑えた小まめな本番反映をするような開発を行なっています。本番リリースをより安全に行うことができるようになるだけでなく、バッチサイズの削減や、デプロイ頻度の向上に寄与してくれた取り組みであったと思います。

施策5. マイクロフロントエンドの導入

2022年の夏頃からマイクロフロントエンドの検証・導入がなされ、フロントエンドの疎結合化が進んできているのですが、開発者体験やデプロイ頻度の向上にも大きく繋がりました。書籍「LeanとDevOpsの科学」で下記の記述があるように、カプセル化された疎結合アーキテクチャは継続的デリバリへの大きな貢献要因になるのだと改めて感じさせられました。

カプセル化された疎結合アーキテクチャはパフォーマンスを向上させる。２０１７年のデータでは、カプセル化された疎結合アーキテクチャが継続的デリバリの最大の貢献要因となっていた。
LeanとDevOpsの科学. P248

もちろん、疎結合化することで各リポジトリに同じようなコミットが重複するようなケースもあるので、そこは差し引きした上で数値は見る必要はあると思いますが、それでも貢献度は高かったように思います。

施策6. Dependabot運用 (セキュリティシフトレフト )

これまでRailsや各種ライブラリのアップデートは完全に後手に回っており、全く対応ができていなかったのですが、今期から「セキュリティシフトレフト」も注力ポイントの一つとして掲げ、取り組みを進めていました。具体的には、主要なレポジトリには全てDependabot (version update(※5) / security update(※6) ) を設定し、チーム毎に運用するような形で進めています。

今では、各セキュリティアップデートが出た場合でも、迅速に対応できるのはセキュリティ観点でもとても安心です。Dependabotの対応PRはRedashで可視化しているのですが、定期的に対応できている状況が確認できます。この辺りはしっかりと持続的に取り組んでいくこと大切であり、継続的デリバリの向上にも繋がる部分であると思います。

「チームが情報セキュリティを時間軸上の左へ移動(シフトレフト)すると、継続的デリバリを実現する能力が向上し、ひいてはデリバリのパフォーマンスも向上する」との結果がでている。情報セキュリティ関連の作業を独立したフェーズとして開発プロセスのダウンストリームで実施するのではなく、最初からソフトウェアのデリバリプロセスに組み込むのである。
LeanとDevOpsの科学. P84

施策7. 技術的負債の測定及び解消 with ドメインモデリング

主にバックエンド領域では、ファットモデルやファットコントローラーなどクラスが肥大化し、変更容易性が低く、見通しの悪いコードが多くあるのですが、それらもデプロイ頻度やリードタイムを改善する上での阻害要因となります。そのような コード上の技術的負債を可視化して改善に活かすために、CodeClimateを導入しています。

これまで新規コードは増え続けているにも関わらず、technical debt ratio (技術的負債比率)や負債の量は減少し続けています。 このような技術的負債解消は、デプロイ頻度やリードタイムに劇的な変化をもたらす類のものではないですが、日々の活動の中で着実にしっかり取り組むことが大切であると思いますし、日々の積み上げが数値として反映されている手応えは強く感じています。

2. DX Criteriaの振り返り

次にDX Criteiraについて振り返りたいと思います。

前提として、詳細は前途の「エンジニアリングマネージャーとしての開発力向上の取り組みついて」にも記載してありますが、DX Criteriaは「System」テーマのみを実施しています。そのためDX Criteriaは「Digital Transformation」と「Developer eXperience」の「2つのDX」 を測定するツールではあると思いますが、ここでは主に後者のDXを軸に紹介させていただきます。( 今年末から全カテゴリで実施運用する予定で考えていますが、この記事では触れません )

また今回紹介する数値は、エンジニア全員がそれぞれ個別に評価した結果を集計したものになっています。DX CriteriaはCTOやマネージャーだけが実施している企業さんもいると思いますが、DX Criteriaは体系的にプラクティスがまとめられているため、各メンバーが全体を俯瞰して課題を認識し、振り返るツールとしても有用であると考えました。

あと大切な点として、DX Criteria公式に記載されている通りではありますが、あくまで 「エンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーション」 が目的 でありますので、「絶対的な基準」としてではなく、今後の方針・改善に向け、活用しています。

ちなみにDX Criteriaの結果は今年春のものとなります。( ちょうど今現在、再実施しようとしている最中で、大分改善されているものもありますが、それはまた別の機会にご紹介できればと思います。そこでしっかり定量的に振り返れるのは、このDX Criteriaの大きな利点ですね。)

1-1. 「カテゴリ」ランキング

「System」テーマのカテゴリ別の評価結果としては以下の通りとなりました。「バージョン管理」だけが５以上と評価が高い一方、 「疎結合アーキテクチャ」「セキュリティシフトレフト」は３以下と低い結果となっています。

最下位の「疎結合アーキテクチャ」は色々と検討し、改善に向けて取り組んでいる最中なのと、一朝一夕で解決するには難しい部分ですので、納得感のある結果ではあるかなといったところです。「セキュリティシフトレフト」は今年はいくつかしっかり改善できた項目があるため、再評価で数値がいくらか上がるのではと予想しています。

1-2. 「カテゴリ」昨対比

2021年春と2022年春との比較結果は以下の通りになりました。

最も改善したカテゴリは「継続的デプロイ」 でした。次いで「システムモニタリング」「API駆動開発」が続く形となっています。全体的に大きく底上げされたような結果となっています。では、実際にどのカテゴリのどの項目が改善されたのか、順番に見ていきたいと思います。

1-3. 「項目」別の改善ランキング

項目別で上昇率が大きい上位１０つは以下の結果となりました。

１位は「システムモニタリング」のオートスケールに関する項目 です。前途のFourKeysの取り組み紹介でも触れましたが、READYFORは２年前はEC2+AutoScaling構成ではあったものの、とある事情で自動でスケーリングする構成ではなく手動で対応しなくてはならない状態でした。ECS移行に伴い、オートスケールもできるようになり、この辺りの開発者体験も大きく改善されました。他、FeatureToggleやロールバックの導入、デプロイ頻度の計測なども推進したこともあり「継続的デプロイ」の項目の上昇が目立つ結果 となりました。

その他のカテゴリをみると、スキーマー駆動開発を推し進めたことで「API駆動開発」 の項目も大きく改善している他、ドメインモデリング文脈でCodeClimateによるコードのメトリクス計測 を始めたこともあり、「ソースコードの明確さ」の項目も上昇 しています。

補足：「0.92」とか「0.3」など半端な値になる理由は、向き合うシステムが異なる複数メンバーの平均値をとっているのと、個々の「but」判定の基準を厳密に合わせるのが難しいことが理由として挙げられますが、現状をそれなりに適切に表した、割と妥当な結果にはなっているので、許容しています。また実際には、チーム毎や職能毎、プロジェクト毎など細かく分けて集計・可視化していますが、ここでは全体の部分を紹介しています。

1-4. バックエンドとフロントエンドの比較

次に、バックエンドエンジニアとフロントエンジニアのカテゴリランキングの比較です。

バックエンドとフロントエンドとで共通の項目もあるので一概に比較することが適切ではない部分はあるのですが、「バージョン管理」、「継続的デプロイ」、「ソースコードの明確さ」など運用方法が異なる部分も多いため、比較してみました。

全体的には総じてフロントエンド側のスコアが高い傾向にありました。 その要因は各項目をしっかり見ていく必要はあると思いますが、フロントエンドはバックエンドよりも比較的レガシーコードからの脱却が容易で、同時に新しい技術スタックの導入もしやすいため、相対的に開発体験も向上させやすいのではと推察しています。

また点数の開きが最も大きかったのは「API駆動開発」でした。 スキーマー駆動を採用していて、スキーマー定義はFE/BEで一緒に策定しますが、スキーマー策定後のコード自動生成やテスト周りに関しては、バックエンド側の方が煩わしい部分があり、それは一つ差異要因として挙げられるのかなと思いました。あとそもそもとして、API駆動開発はしておらずバックエンド領域で完結している機能・サービスも残っている事もスコアに影響しているようでした。( このあたりはDX Criteria評価の対象範囲をどこに定めるかという話にもなってくるのですが、明確に境界が引きずらかったり、チーム移動で携わるシステムも変わったりするので、ある程度決めで考えるしかないと思っています。 )

1-5. エンジニアへのアンケート結果

最後に、DX Criteria実施後のアンケートで「特に力と入れていきたいカテゴリ」を聞いたところ、以下のような結果になりました。
「セキュリティシフトレフト」「疎結合アーキテクチャ」への関心が高いことがわかります。また元々課題感が多かった「継続的デプロイ」はCI/CDの改善が大きく進んだことで０件になっています。

終わりに。

今回振り返りで率直に感じた事としては、各チーム・エンジニアのこれまでの数々の取り組みの成果をしっかり数値として示すことができ、振り返りができる事はとても有用で、大切であると思いました。 サービス・システムの成長に伴い、技術的な問題に向き合い、日々多くの課題を解決していく中で、何かしら成果を示す共通指標がない場合、割とやった感で終わったり、半年・１年後に振り返えろうにも振り返れないみたいなケースも多いのではないでしょうか。

開発力の測る指標としてFourKeys、開発者体験を測る指標としてDX Criteriaを採用しているわけですが、今回改めて双方を比較して振り返ってみると、定量化のアプローチは違えど、改善した内容がしっかり数値化して結果として現れてくるのは面白いなと思いました。

最後に冒頭でも述べましたが、同様の取り組みを試行錯誤している企業さんは結構いるように思いますが、何か一つでも参考になれば幸いです。

余談

完全に余談ですが、最近この記事で取り上げたような開発力や開発体験向上の取り組みをしている方とTwitter/Qiita経由などで情報交換がてらざっくばらんに話すみたいな事を定期的にしているのですが、もしそういった話は大歓迎ですので、お気軽にお声がけください！

参考

1. "Qiita. エンジニアリングマネージャーとしての開発力向上の取り組みついて",
   https://qiita.com/KUMAN/items/8cee8e33628850fd4e29
2. "DevOps の Four keys の Lead time for changes (=変更のリードタイム)についてのまとめ", https://zenn.dev/junichiro/articles/481b6a0658ba03
3. "DX Criteria (v202104)", https://dxcriteria.cto-a.org/
4. "CodeClimate. Our 10-Point Technical Debt Assessment", https://zenn.dev/junichiro/articles/481b6a0658ba03
5. "GitHub Docs. Dependabot のセキュリティ アップデートについて", https://docs.github.com/ja/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates
6. "GitHub Docs. GitHub Dependabot のバージョンアップデートについて", https://docs.github.com/ja/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates
7. "CodeClimate. technical debt ratio (技術的負債比率)", https://codeclimate.com/blog/10-point-technical-debt-assessment/
8. "LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ", https://www.amazon.co.jp/dp/B07L2R3LTN