シェア
はてブ
2024年6月28日、29日の二日間にわたって、ファインディ株式会社が主催するイベント「開発生産性Conference」が、開催されました。本カンファレンスは、虎ノ門ヒルズフォーラム（東京）にて実施され、一部のセッションはオンライン配信も行われました。
本記事では、オンラインでも配信されたセッションのうち、フリー株式会社で開発者体験および資産性向上の取り組みを進めるmiyahikaさんによるセッション「freeeにおけるスモールスタートを意識した開発生産性向上の実践事例」の内容をお届けします。
会計や人事労務を核とした統合型経営プラットフォーム「freee」を開発・提供しているフリー株式会社。同社ではSREの分業が進んでおり「社会基盤として重要性を増すfreeeの全サービスの信頼性・安定稼働を実現する」といったミッションに向けて、各チームが取り組みを推進しています。本セッションでは、Four Keys の計測・可視化や開発生産性アンケートなど、Platform Delivery Teamの取り組みついてお話しいただきました。
■プロフィール
miyahika（みやひか）/ @miyahika214
フリー株式会社 SRE / Platform Delivery Team
2021年まで美容系SNSスタートアップの株式会社Meily創業メンバー/SRE。
freeeに2022年1月入社。SREの Platform Delivery Teamで開発者の経験が向上する取り組みを行ってきました。SRENEXT2023 コアスタッフ。好きな技術：Kubernetes/ArgoCD/Helm/ARC/
分業が進んでいるfreeeのSREチーム
miyahika：miyahikaと申します。本日は「freeeにおけるスモールスタートを意識した開発生産性向上の実践事例」ということでお話いたします。始めに自己紹介として、私は美容系のSNSのスタートアップで創業メンバー兼1人SREを4年間経験した後に転職しました。現在は、SRE Platform Delivery Teamの一員として、開発者の体験を向上する取り組みを進めています。
freeeは「スモールビジネスを、世界の主役に。」というビジョンを掲げており、誰もが自由に自然体で経営できる環境を作るべく、統合型経営プラットフォームを開発・提供しています。
会計ソフトのイメージが強いと思うのですが、それ以外にも人事労務や請求管理、電子契約、経費精算などに対応しており、それらのデータを連携して統合的な体験を提供しています。
SREチームの構成についてもご紹介します。freeeを支えているSREチームはPlatform、Enabling、Cloud Governancs、DBREの四つに分かれていて、Platformはそこからさらに三つのチームに分かれています。その中の一つが、私の所属するPlatform Delivery Teamです。
miyahika：SRE全体のミッションは「社会基盤として重要性を増すfreeeの全サービスの信頼性・安定稼働を実現する」「高い開発者体験を実現する基盤を開発運用しプロダクトと開発組織の成長を支える」の二つです。
対して、Platform Delivery Teamでは「エンジニアがマジ価値を届ける仕事に集中できるようにする」「開発者が機能を思いついてからユーザーに届くまでを最短にする」といったミッションを設定しています。
SREとPlatform Delivery Team、両方のミッションを達成するためには、開発生産性を向上することが必要不可欠だと考えて、本日ご紹介する取り組みをスタートさせました。
本日は、Platform Delivery Teamで実践してきた「内製統合デリバリー基盤での計測・可視化」「開発生産性アンケートの実施」「スモールスタートでDORAフレームワークの効果検証」「開発生産性OKRガイドライン」をご紹介します。
ケイパビリティの改善が必要な理由
DORAが定義したケイパビリティとは
miyahika：実践内容についてご紹介する前に「なぜケイパビリティの改善をするのか」と題してお話しします。
はじめにDORAとState of DevOps Reportについて説明させてください。DORAはGoogleCloud内のDevOps Research and Assessmentという組織の略称で、DevOpsと組織のパフォーマンスの関連について9年間研究しているチームです。
DORAが毎年発表しているState of DevOps Reportは、世界中の専門家や組織、チームから収集したデータをもとに開発生産性に関する情報をまとめたレポートです。
State of DevOps Reportでは、重要な指標としてFour Keysがあります。これはソフトウェアデリバリーのパフォーマンスを測る指標で、大きく速度を測るものと安定性を図るものにわかれています。DORAの調査によると、両方を高めていくことで組織のパフォーマンスやチームのパフォーマンス、従業員の健康状態にまで影響することがわかっています。ちなみに、最近は五つ目の指標として信頼性も加わり、Five Keysと呼ばれることもあるようです。
Four Keysを高めるために重要となるのがケイパビリティです。ケイパビリティとはDORAが定義した組織が持つ能力や要素を表したもので、技術、プロセス、文化といった三つのジャンルで27個設定されています。
ケイパビリティを改善することで「組織的なパフォーマンスの向上」「チームのパフォーマンスを向上」「従業員の健康状態の改善」といった効果があると言われています。各ケイパビリティの詳細はDORAのWebサイトに載っていますので、ぜひチェックしてみてください。
DORAフレームワークで複数の指標を取り入れる
miyahika：上図はDORAのコアモデルで、真ん中の緑色部分がFour Keysです。Four Keysを改善すると、右側にある組織のパフォーマンスが向上するということを表しています。
ただ、ここで重要となるのは、左側にあるケイパビリティの改善です。ケイパビリティを改善することで、ソフトウェアデリバリーのパフォーマンスが向上する。その結果、組織のパフォーマンスを向上することができます。
miyahika：またDORAが提唱しているフレームワークには、SPACEフレームワークといったものもあります。これは「Satisfaction and well-being」「Perfomance」「Activity」「Communication and collaboration」「Efficiency and flow」の頭文字をとったものです。
よくあるのは、評価につながりやすいActivityだけを見ることでエンジニアが燃え尽きてしまうといったアンチパターンですね。どれか一つだけの指標で評価することはできませんし、DORAフレームワークを活用して、定量的なものだけでなく定性的な指標もしっかりと見ていくことが重要だと考えています。
なお、freeeでは下図のような流れで取り組みを進めてきました。
実践①内製統合デリバリー基盤での計測・可視化
freeeの内製基盤とは
miyahika：ここからは、freeeで実践してきた内容をお話しします。はじめにご紹介するのは「内製統合デリバリー基盤での計測・可視化」です。
freeeの内製統合デリバリー基盤（以下、内製基盤）は、4年前に構築・運用を開始しています。その背景には、会計ソフトの特性上、QAと監査のプロセスを必ず実施する必要があったことも関係しています。1デプロイで平均50PR以上になる大きなプロダクトもあるのですが、そういったものでもPRごとにステージング環境で確認しなくてはいけませんでした。
また、プロダクトが50以上あるため、各プロダクトでデプロイフローを作るとなると管理が大変ですしナレッジも共有されません。そこで、全てのプロダクトで利用できるように、デプロイフローの標準化・自動化を目的として、内製基盤を構築したのです。
freeeのデプロイフローは下記の通りです。
miyahika：まずGitHub Actionsからrelease tagを作成すると、自動でイメージビルドが走り、ECRにプッシュされます。そうすると、Kubernetes manifestの管理用レポジトリにimage tagを変更するPRが作成され、それがmergeされるとArgoCDが検知してステージング環境のAWSのEKSにデプロイされます。
miyahika：デプロイされたことを検知すると、内製基盤がSlackに通知を飛ばします。PR作成者もしくはレビュアーのどちらかが承認しない限りは次のステップに進めないようになっていて、ここで1次テストやQAプロセスを経て、ステージング確認は終わりです。
miyahika：その後、プロダクション環境でデプロイが終了したら、内製基盤が監視通知をSlackに飛ばします。そこでメトリクスに問題がなければ、デプロイは終了です。
内製基盤を活用した取り組み
miyahika：freeeでは、約1年前から内製基盤を使って、定量的な指標の計測・可視化に取り組んできました。なぜ内製基盤を活用したのかというと、デプロイの情報が蓄積されていたことに加えて、Jiraで管理していた障害データをデプロイと紐づけることができればFour Keysも計測できるはずだと考えたからです。障害データの入力で足りていない部分はGUIを活用しました。
なお、Jiraとの障害データの連携については、下図のようになっています。
miyahika：障害が発生したらJiraにチケットを起票し、webhookによって内製基盤に障害の情報がリンクされます。
miyahika：そうすると、内製基盤でデプロイの情報を入力できるようになります。基本的にチケットの情報は自動で入力され、その上でFour Keysに必要な情報として「デプロイによって起きた障害か？」「デプロイによって復旧したか？」といった質問にYES/NOで回答すると、デプロイを紐付けられるようになっています。紐付けができると時刻が自動で入力されて、Four Keys に必要なデータが取れるといった仕組みになっています。
miyahika：上図はFour Keysのダッシュボードです。真ん中部分にLow～Eliteまでのランクが表示されていて、左右で直近の推移が確認できます。
内製基盤で計測・可視化するメリット・デメリットについてもお話しします。大きなメリットは、データの連携や計測が自由にできること。復旧時間が正確に出せるのは特に嬉しいポイントですね。Jiraの障害データを連携しているため、発生時刻が正確にとれています。ArgoCDがSyncしてKubernetesのpodが入れ替わったタイミングのデータも取れるように設計しているため、復旧時間も正確です。可視化したい内容に応じて、計測項目を自由に追加変更できるのもメリットだと思います。
デメリットは、開発コストと運用負荷が高いところですね。Platform Delivery teamがしっかり運用して改善を回していかないと、負債化してしまう可能性もあります。
また計測・可視化をする上で、ツールを内製するかどうかについては、組織の状況に合わせて検討するのが良いと思います。freeeはもともと持っていた内製基盤にデータを連携するだけで良かったため内製化を選びましたが、DORAでは簡単に導入できる商用製品の利用が推奨されています。
実践②開発生産性アンケートの実施
miyahika：次に、定性面のアンケートの設計についてもお話しします。先ほど紹介したSPACEフレームワークには、アンケートの定性的な回答でしか測れないものがたくさんあります。また、アンケートを通して改善すべきケイパビリティを可視化するとともに、改善活動の成果を振り返ることも目的に含まれています。
アンケートでは、DORAが推奨しているリッカート尺度を採用しています。1が全くそうは思わない、4がどちらとも言えない、7が非常にそう思う、といった形で7段階の選択肢を用意する方法ですね。これにより、回答のハードルを下げることができていますし、両極な回答ではなく程度まで測ることができています。集計はGoogleフォームで活用しており、アンケート結果はスプレッドシートで可視化しています。
実施頻度については、回数が多いと調査疲れを起こす可能性もあるため、振り返りのサイクルや現状把握したい頻度に合わせて設定する必要があります。DORAでは3ヶ月に1回、もしくは1ヶ月に1回の頻度が推奨されていますが、設問の数が41個と多いため、freeeでは前者を採用しています。
可視化したシートも一部ご紹介します。
miyahika：個人が特定されないように、回答と可視化のシートは分けるようにしています。可視化のシートを分けることで、四半期ごとに推移を見られるようにするという目的もあります。
また使いやすいシートでなければ、振り返りでも活用されません。そこで、チームや設問をプルダウンで選択してすぐに結果を確認できるようにするなど、使い勝手の良いシートにすることも意識しています。
miyahika：その次に意識しているのは、小規模なチームごとに確認できるようにすること。最初は30人単位ほどのチームの枠で可視化していたのですが、エンジニアから「他のチームの回答も結果に影響しているため、自分事として取り組めない」といったフィードバックがあり、小さな規模で確認できるように調整しました。回答結果が低い順に並び替えて、課題を特定しやすいようにもしています。
上図のチームは「技術的負債・設計的負債はない」という設問のスコアがとても低い状態でした。同時に「自分のチームはOKR外のタスクとして改善活動に充分な時間を割くことができている」「フロー（集中）状態を作れている」「Meetingの量は適切だ」「Meetingの質は健全だ」という設問のスコアも低い。
この結果を見ると、例えば「このチームではMeetingの量を減らすことで、1回ごとの質を上げるとともに、集中できる状態を作り出すことが良いのではないか」「集中できる状態を作って改善活動に割く時間を生み出すことができれば、負債を返済できるのではないか」といったアイデアが出てくると思います。このように、アンケートを通して複数の指標を見ながら考えることで、課題を特定するとともに改善アイデアを出せるようになるのです。
設問の一部もご紹介します。
miyahika：SPACEフレームワークに沿ったものに加えて、ユーザーフォーカス、freee独自の設問も用意しています。前者は2023年のState of DevOps Reportで大きなトピックとして扱われていて、ユーザーからのフィードバックを繰り返し反映しながら開発している企業はパフォーマンスが高いということがわかっているため採用しています。 freee独自のものとしては、ChatGPTやGitHub Copilotなどを業務で有効に活用できているかをヒアリングする設問も用意しています。
開発生産性アンケートを通してDORAメトリクスを可視化し、数値をもとに改善することで、勘を頼りにするような属人的な改善を防止する効果があると実感できています。マネージャーとチームが根拠に基づいて改善を実践できるようになりましたし、成果の振り返りができるのもうれしいポイントですね。
また、開発チームの皆さんが日頃から考えている改善のアイデアは、実体験から考えているため正しい策であることが多いと思います。しかし、いい改善のアイデアが浮かんでいるのに、実践されないこともあるでしょう。アンケートを通して可視化することで、そういったケースもなくなるのではないかと考えています。
実践③スモールスタートでDORAフレームワークの効果検証
DORAフレームワークの効果検証を進める前に
miyahika：ここからは、DORAフレームワークの効果検証についてお話しします。freeeでは、導入当初にフレームワークを浸透させることができませんでした。
失敗した原因は四つあり、一つ目はfreeeの中でも比較的大きなプロダクトでスタートしてしまったこと。
二つ目は、DORAフレームワークの理解度が低かったことです。プロダクトチームに伝えるためのドキュメントが充実しておらず、伝えるのに毎回苦労しているような状況でした。
三つ目は、四半期の途中から提案を始めたため、目標設定がすでに決まっていたプロジェクトチームの合意が得られず、工数を取れなかったこと。それにより改善施策を実行するリソースの半分以上がDelivery teamになっていて、コードの保守性のケイパビリティ改善で課題を特定できず、具体的なアクションに落とし込めませんでした。
最後は、指標から取り組むべきケイパビリティを特定するのではなく、ヒアリングして出てきた課題を無理やりケイパビリティに結びつけて取り組んだことです。
これらの失敗を踏まえて、スモールスタートを意識するようになり、小規模なチームでDORAフレームワークの成果が出るかを検証することにしました。アンケートによってチームを選び、Delivery teamが具体的なアクションを決められるケイパビリティに取り組むことにしたのです。
なお、取り組み当初から「いずれはプロダクトチームだけで対応できるようにしたい」と考えていたためドキュメントや手順も整備していて、現在はプロダクトチームの人も参加できるようになっています。また、指標で成果を振り返れるようにもしています。
チーム選定については、デプロイ周りの満足度や改善に対する興味の度合いとかけられる時間などをヒアリングして「課題感が深くて改善への関心が高く、時間が割けるチーム」を選定しました。
効果検証：トランクベース開発の導入
miyahika：チームが決まったあと、ケイパビリティの改善として最初に行ったのは、トランクベース開発の導入です。トランクベース開発とは、開発者は自分のPRを小さなバッチに分割し、少なくとも1日1回は共有 branchにmergeするソフトウェア開発のスタイルの一つです。
miyahika：freeeでは短命なfeature branchとPRを作成し、メインに細かくmergeしていくといったスタイルにしています。上図を見ると、main branchがたくさんあり、feature branchが細かくmergeされているのがわかると思います。release tagを作成すると、デプロイが自動で実行される仕組みです。
miyahika：ちなみに以前のブランチ戦略は上図の通りで、かなり複雑なものでした。branchが多いことによって認知負荷が高く、デプロイや障害対応の手順も増えてしまっていたのですが、トランクベース開発の導入によって解消されました。
小さなパッチ単位の作業のケイパビリティにもいい影響がありましたし、デプロイや障害対応のペインが減ったことで、メンバーのウェルビーイングのケイパビリティにも効果がありました。
ただ、トランクベース開発を進めるにあたって、注意点もあります。一つ目は、main branchに入ったPRは本番環境に入る前提で考えなくてはいけないこと。もう一つは、PRレビューをしっかりすることと、CIで自動テストやセキュリティチェックを行うことです。
なお、トランクベース開発導入後のアンケートでは、デプロイや開発環境、仕事の満足度、全てで1ポイント以上も上昇しました。ドキュメントを整備したおかげで、多くのチームで導入が進んでおり、導入した全てのチームでデプロイフローの設問の回答がプラスになっています。
導入後に実施した簡易アンケートは5段階で回答してもらっていて、そこでも多くが満点の5に近い回答を得られています。
効果検証：ロールバックの推進
miyahika：次に行った効果検証は、ロールバックの効率化、フロー整備です。こちらは復旧時間の短縮とインシデント発生時の損失を軽減するメリットがあります。また、インシデント対応の時間が減ると、幸福度が上がり、改善活動と価値を届ける仕事に集中できるといった効果があることもわかっています。
ロールバックの推進を決意した背景には、ロールバック可能な障害の割合が約38%だったことが関係しています。というのも、デプロイ後すぐに不具合を検知できていなかったのです。例えば、2バージョン3バージョンと進んだ後に、お客様からの問い合わせで不具合に気がつく。そうすると、一つバージョンを戻しても、ロールバックができない状態になってしまいますよね。そこで、デプロイ後に不具合を検知できるようにするべきだと考えました。
また、ロールバック可能な障害の中でも、実際に実施した割合は約18%しかなかったのも大きく関係しています。ロールバックの判断ができない要因はいくつかあったのですが、可能な障害に関してはしっかり実施できるようにしたいと考えていました。理由としては、ロールバックできた障害の平均復旧時間は15分で、しなかった障害については平均復旧時間が1時間半もかかっていたからです。
ロールバックすると、QAや動作確認、テストを通り抜けていると判断できるため、戻すことに特に制約はありません。ただ、改めてhotfix PRをmergeしてステージング環境、プロダクション環境のように進んでいく場合は、イメージビルドやQA、テストが挟まるため、時間がかかってしまっていました。
ロールバックを効率化するメリットは、1障害あたり対応メンバー×1時間15分の止血対応時間を削減できること。障害が影響する事業所数も80%削減できますし、その分影響範囲の調査も短くなり、サポート担当のメンバーがお客様に連絡する対応も減らすことができます。
実際に重要度の高い機能の障害だった場合は、1000万から1億円の損失を回避できる可能性もあるため、freeeではロールバックの効率化を積極的に進めています。
miyahika：ロールバックの効率化とフロー整備において、具体的に取り組んだのはRollback NG buttonの実装です。PRごとにロールバックすべきでないものがあれば押せるボタンで、これにより、50以上PRのあるデプロイでもロールバックすべきかどうかをデプロイ担当者が判断できるようになりました。また、ロールバックすべきでないPRがあった場合の二次被害も防止できています。何より重要なのは、このRollback NG buttonを開発者が常に見られるようにすることで、互換性のあるリリース意識の向上につながったこと。
ドキュメントを整備して、誰でもロールバックできるような手順を紹介したり、Rollback NG buttonについてのチェック機能の紹介をしたり、ロールバックを可能にするためのリリース作成ガイドも作成しています。これらを通して、freeeの組織には「互換性のあるリリースが当たり前」という考え方が広まりつつあります。
また、ロールバックの推進についてアンケートを実施したところ、今年の5月に始まったばかりで実施期間が短いものの、アンケートの結果は全てプラス方向に伸びていました。Four Keysの復旧時間にも大きな変化はないのですが、変更障害率や復旧時間など安定性の指標は結果が遅れて出てくるものですし、根気強く改善を続けていきたいと考えています。
実践④開発生産性OKRガイドライン
miyahika：効果検証によってDORAフレームワークの効果があるとわかりました。そこでfreeeでは、50以上あるプロダクトチームに振り返りと目標設定のサイクルに取り入れてもらうために、開発生産性OKRガイドラインを作成しました。ガイドラインには、DORAフレームワークやFour Keysが間違った利用をされるのを防ぐ目的もあります。
ガイドラインの概要は下記の通りです。
miyahika：まずはDORAフレームワークについて解説し、State of DevOps Reportの内容やFour Keys 、SPACEフレームワークについて認識齟齬がないように説明する。その上で、DORAメトリクスの確認方法や数値の扱いに関するアンチパターンについても触れています。その次に、どのようにして目標設定と振り返りに組み込むかについて解説し、最後は設問と指標に対応しているケイパビリティの改善の具体例を紹介しています。
このガイドラインで特に伝えたいと思っているのは、Four Keysやアンケートの結果の数値を目標にしないということです。数値を目標にするとハックする可能性が増えてしまうため、その裏にあるケイパビリティを目標にしようと強く訴えています。
それに加えて、DORAメトリクスを人事評価に利用しないこと、複数のメトリクスを複合的に見ていくこと、継続的な取り組みの重要性についても触れています。
また「何より重要なのは、Four Keysやアンケートの結果をもとに改善するケイパビリティを決めるのはチームであり、改善を行うのもチームである」という点についてもガイドラインで伝えるようにしています。
「開発生産性2倍」を目指して進むfreee
miyahika：今後の展望についてもお話しさせてください。
freeeでは、これから1年のテーマの一つとして「開発生産性2倍」を掲げています。組織のパフォーマンスを上げて成長を続けるための明確な答えがあるわけではありませんが、各チームで一人ひとりがメトリクスを見て、チームの課題を特定して、改善し続けることが重要なのかなと。その積み重ねが「2倍」に繋がっていくのだと信じて、freeeはこれから1年間頑張っていこうとしています。
最後に、開発生産性におけるリーダーシップの重要性についてもお話させてください。
本日参加されているリーダー層の方にお聞きしたいのは「トップダウンで決めた改善内容を押し進めたりしていないですか？」という点です。DORAの調査によると、トップダウンで改善活動を実施した場合、結果的に改善は進まず組織の中に疑念と無関心が広がってしまうことがわかっています。
それを踏まえて、リーダーの皆さんには、トップダウンではなく強力なリーダーシップを発揮してほしいと思っています。メンバーのモチベーションが上がるような目標を設定し、改善内容についてはチームに任せていく。その上で、リーダーが承認するスタイルが良いのではないでしょうか。
また、正しい取り組み方を熱意を持ってチームに伝え続けることも大切だと思います。チームを見守りながら、時にはサポートする必要もあるかもしれません。通常業務で改善作業を圧迫しないように調整するのも、リーダーの役割だと思います。
freeeではリーダーと話す機会を増やしていて、各チームが品質改善に10%の工数を取れるように調整しています。エンジニアとプロダクトマネージャーが一緒に開発生産性用のOKRを立てることで、品質の面でも生産性の面でも共通の目標を持てるようにもしています。
発表は以上となります。駆け足での発表となりましたが、最後までご清聴いただきありがとうございました。
アーカイブ動画も公開しております。こちらも併せてご覧ください。
