この記事は Ubie Engineering Advent Calendar 2023 及び エンジニア組織の開発生産性・開発者体験向上の取り組みをシェアしよう！ by Findy Advent Calendar 2023 シリーズ2 8日目の記事です。よろしくお願いします！
Ubie におけるスケーラビリティの重要さ
Ubie は2017年に創業し、医療機関や一般の生活者、製薬企業などのステークホルダーへ価値を提供してきました。今年はおかげさまで事業的にも YoY で X% 成長[1]と大きく拡大してきており、これからもより一層持続的な成長が必要になってきています。
これまでの過程では、多くのソフトウェア企業と同じく技術的な前借りをしてきた結果、資産だけでなく負債もそれなりのボリュームになっており、スケールするためにはこれらを改善していく力、つまり開発生産性を強化する必要が高まっています。
そんな状況も加味して Ubie では特にこの1年「スケーラブル」というワードが大きな指針でした。
いかにしてスケーラブルであり続けるか
一般的に、ソフトウェアも事業も規模が大きくなってくると共にドメインの幅・深さも大きく複雑になり、一部の数人ですべてを把握しコントロールするのは認知負荷的にも限界を迎えます。
Ubie ではそのような中央集権的なマネジメントや運用ではなく地方分権的にそれぞれのチームが自身のドメインに deep dive し、継続的にオーナーシップを持ち続けることでハイパフォーマンスを発揮するような、いわゆるチームファーストアーキテクチャを目指すことでスケーラビリティを獲得しようと試みています。
例えば、ソフトウェアのアーキテクチャはチームが効果的にそのオーナーシップを持ち続けるためのアーキテクチャやグルーピングに沿う必要があります。しかし我々のようにまだまだ事業的な不確実性の高い領域でソフトウェアの実装をするシーンがあるとき、モノリスやマイクロサービスのままでは機能が安定期に差し掛かったタイミングで適切に再配置させるコストが大きくなりすぎるという課題があり、これについては以下で少し触れているようにモジュラーモノリスを採用することでシステムとオーナーの紐づけを整備し、高いスケーラビリティを獲得しようとしています。
また、これまでは Ubie におけるチームとは流動的であり事業的な目標意識を共有するグループでしかなく、システムのオーナーであるという意識は事業成長の中で劣後している状況がありました。
そのためソフトウェアに対するオーナーシップをチームとして意識できるような変革も合わせて進める必要がありました。
一方、ソフトウェアのアーキテクチャだけでなく開発生産性の可視化も我々がスケーラブルになるうえで必要不可欠なパーツでした。
現在の我々が持つ生産性がどの程度のものかをある程度定量化できていなければ、どの程度人的な拡大することで事業をどの程度推し進められそうかを予測することすらできず、また生産性が低すぎる場合には人を増やしても事業はスケールしないはずで、このような戦略を描く上で開発生産性の可視化は急務でした。
チームにオーナーシップを装着していく
社内でもオーナーシップの不足を原因とする課題はたびたび取り沙汰されており、対処していくぞという空気感は醸成されていました。
一方で、いざオーナーシップとは何か？を定義しようとしてもなかなか難しく自分にはなかなか明瞭化できませんでした。
そこで近似値として DevOps Research and Assessment (DORA) の Capabilities を活用する方針に切り替えました。つまり、「これらの Capabilities を獲得しているということはオーナーシップを持てているということでは」というスタンスに立って整理を試みました。
DORA Capabilities の活用
Capability catalog として DORA が公開しているものがあります。
これらは長年の研究によって Outcomes と相関のある能力として挙げられており、どの Capability がどのような Outcomes に影響があるかは毎年 Report として発表されています。
例えば今年の 2023 State of DevOps Report では新たに User-centrism (ユーザー中心主義)であることは組織のパフォーマンスに大きな好影響がある、などがまとめられています。
これらの Capabilities の活用を検討する中で、このカタログにかかれているすべての項目をすべてのチームに対して見ていくことはとても運用コストが高く、また Report を見ると Outcome との相関も Capability によってかなりバラツキがあることがわかります。
そもそも、全世界との比較がしたいわけではなく Ubie という組織内において「チームへ期待することが明瞭化されている」ことが重要であったため、この観点でプロジェクトをともに進めていた @syu_cream と共に「この項目は必要やろ」「これは統合しても良いかもね」などと相談しつつ、DORA の Capabilities からいくつか我々にとって重要なものを厳選したり項目を加えたりしながら言語化して整理していきました。
最初のバージョンとしてできあがったリストはこんな感じでした。
今では「AIの活用」は不要かなということで削除したりしています
それぞれの指標は DORA を知っている人であればまだしも、全員がそうとは限らないため、DORA が実際に使用している質問 などを参考に「このくらいできてたら何点ね」というようなざっくりとした基準も合わせて整備しています。
信頼性プラクティスの例
運用としては実際に各ストリームアラインドチームのメンバーと共にページを眺めながら「この項目は8点くらいいけてるな〜」や「ん〜、0点！」のように採点していきます。
サンプルチームの例
一番得たかったものは、これを通して「うちのチームは改めてみるとココ弱いな〜」や「次はこの能力を獲得することがチームとしては一番成長しそう！」など、チームの気づきそのものでした。ゆくゆくは定期的にチーム内で実施してもらうことで自己改善に繋げていけると良いと思っています。
一方で、チームに改善の意思があったとしても今すぐ実施するためのノウハウがチーム内に存在しないケースも多くあります。
実際に「信頼性のプラクティスをどんどん導入していきたい！」と考えてはいるが、チームでこのあたりに詳しい人がいないためなかなか進まないというケースがあり、そのような話が取り組みの中で明らかになっていくことで「じゃあ SRE と一緒に進めていこう」などと具体的な打ち手が見えることも多く、想定以上に得られるものがありました。
そもそもこのような声は「最近課題とかってある？」のようなオープンな問いかけではなかなか出てこないものです。
あらゆるイネイブリングチームからするとユーザーに値するストリームアラインドチームからのフィードバックは常に大事なタネです。これを継続的に数値の傾向をみつつデータを回収できる仕組みとして使っていけるとチーム間の橋渡しとして非常に有効そうであり、社内のあらゆるイネイブリングチームを強化できる仕組みだなと考えています。
開発生産性の詳細化と可視化
Ubie における開発生産性の取り組みは去年から始まっており、GitHub と incident.io のデータをソースとして four keys の可視化を整備していましたが、これ以降は大きな改善には取り組めていない状況でした。
そのため、今まで例えば疎結合なアーキテクチャへのリプレイスや GitHub Copilot の導入など様々な取り組みで開発生産性の向上を実践できていたものの、どれだけの効果があったのかや全体として長期的に改善してるんだっけ？などはあまり深く見れてきませんでした。
一方、会社として成長の予測可能性を高めていったり予算配分の精度を高めていくためにもっと情報がほしいという要望や、高いパフォーマンスを出しているチームのプラクティスを他チームにも転用していきたい、などのニーズが高まるにつれてより詳細に分析ができるようにデータの拡充が必要になってきました。
その中でも特に週次デプロイ頻度を重視しており、よりブレークダウンして分析できるようなデータ拡充が必要で、特に repo ごと、メンバーごと、チームごとに見れることが必要でした。
そもそも Ubie では GKE をメインで利用しており、サービスのデプロイは k8s manifest の変更を契機に行われ、週次デプロイ頻度ではこれをカウントしています。
各サービスの変更は Pull Request を merge した後 tag を打つことで container image の build & push が行われます。
そのため1回のリリース、つまり k8s manifest の変更1つにつき1つ以上の Pull Request が存在します。
そのため repo, member は GitHub のデータのみで拡充ができる状態でしたが、一方 Ubie では複数のチームを兼務することが多く、GitHub のデータのみではチームの施策が何個あったのかという判断は難しい状況でした。
ところで Ubie では多くのチームでチケット管理に JIRA が使われています。
JIRA には JIRA Issue を branch, PR body, PR title, commit comment のいずれかに記載することで Issue と Pull Request を紐付けて管理できる機能があり、これを利用しているチームが多い点に着目し、チームごとの分類にはこれを使うことにしました。
幸いこの部分はコードが公開されているためこれを参考に実装すればよく、比較的手軽に実現できました。
現在のダッシュボードはこんな感じです。Four Keys をベースに高頻度で見たくなる数値を合わせて配置しています。
データは BigQuery に保存されていて、dbt を使ってダッシュボード用にデータマートを用意して使っています。
分析はまだオンデマンドに query を叩いていたりするのでこの辺も改善していきたい
まとめ
Ubie の事業に合わせて組織やシステムにどしどしアップデートをかけています。
始まったばかりの取り組みも多くまだまだ改善点はありますが事業の成長を推進していけるようやっていくぞという気持ちでいるところです。
実際、オーナーシップや開発生産性については可視化のレベルがようやく高まってきたくらいで、これを通してそれぞれのチームが主体的にパフォーマンスの改善に取り組めるようになってようやく価値が出てくると思うので、チームへの浸透も含めてやっていかねばと思っています。
またこのような取り組みに興味を持っていただけた方はぜひカジュアルにお話しましょう！僕も他社ではどんな取り組みを進めてどれだけ有用だったよ、みたいな話に興味があります。
さて明日は Ubie Engineering Advent Calendar 2023 では @syu_cream がお話してくれます[2]。のでお楽しみに！
Discussion