スタートアップの競争力を高める 技術的負債との戦略的な向き合い方
こんにちは、Ubieでソフトウェアエンジニアをしている内藤(9toon)です。2023年3月に入社して以来、医療機関向けのSaaSプロダクトである「ユビーメディカルナビ」の開発に携わっています。現在はテックリードとして、システム基盤の開発や開発生産性の向上に取り組んでいます。
2017年5月に生まれたUbieの歴史は、医療機関向けSaaSプロダクトの開発から始まりました。そのコアシステムは創業当初から開発し続けられており、その歴史の中で多くの技術的負債が積み上げられてきました。
我々のサービスは長年「AI問診」を武器にしてきましたが、生成AIの技術の飛躍的な発展を背景に、最近では生成AIを組み合わせた新機能・サービスの開発にも取り組んでいます。このような事業環境の変化に柔軟かつ迅速に対応できるかが競争優位を分けるため、事業の方向性が定まりきっていないスタートアップ企業にとって、システムのアジリティを維持することは不可欠です。しかし、溜まりに溜まった技術的負債のために、正直なところ我々のシステムは必要なアジリティを欠いていました。
本記事では、私たちがこの技術的負債にどのように立ち向かったのかを紹介し、同じような課題に直面している方々に対してなにか一つでも学びを伝えられればと願っています。
DORAで始める課題の可視化
当時、Ubieでは全社的にDORAのFour KeysやCapabilitiesを用いた開発生産性の可視化に取り組んでいました。
その流れもあり、まずは我々の開発生産性の現在地点を客観的に測るために、DORAのFour Keysを用いた現状把握を試みました。
医療機関向けプロダクトのリリースプロセスは週3回の定期リリース方式になっていて、各リリースごとに社内のQAエンジニアと外部パートナーが丸一日がかりでマニュアルQAを行う、というとても重厚なフローになっていました。この背景として、医療機関の業務で利用されるサービスという特性から、安全性を重視したいという考えがありました。
これによって、デプロイ頻度は週3回に固定され、また変更のリードタイムもマニュアルQAを挟むために少なくとも1日以上かかるということで、低い数値となっていました。一方で、安定性の面では不具合のほとんどがQAフェイズで検知されるため、数値上は優秀な評価となっていました。
定量的には少なくとも開発者らの考えをきちんと反映した結果となっていましたが、定性的には開発者体験は決して良くなく、ヒアリングを行うと本当にたくさんの課題が溢れ出てきました。
限られた開発リソースでこれらの課題を解消するためには、戦略的なアプローチが必要でした。DevOpsのケイパビリティに照らすと、「テストの自動化」や「疎結合アーキテクチャ」など、いくつかの要素が不足していることは明らかでしたが、どこから手をつけるべきかは自明ではありませんでした。
DevExによる課題の構造化
そこで、さらに調査を重ね、DevExの3つの観点「フィードバックループ」「認知負荷」「フロー状態」による問題の分析を試みました。その結果、我々のシステムの主要な課題を以下のように構造化できました：
「フィードバックループ」
貧弱な自動テスト（マニュアルQAに頼った品質保証体制）
定期リリース方式
「認知負荷」
アーキテクチャ上の課題による複雑さ（例：責務の肥大化したモノリス、マイクロサービス間の責務分離の不備）
内部品質の低さによる複雑さ（例：テスタビリティが考慮されておらず変更容易性の低いクラス設計）
不統一な技術スタック
分析の結果、「認知負荷」の高さが開発者体験を悪化させ、「フィードバックループ」の弱さがこれらの課題の原因解消を阻んでいる、という構造が浮かび上がりました。
貧弱な自動テストは、テスタビリティの低いコードを生み、これが設計上の複雑さを招いていました。また、マニュアルQAに頼っていたために、開発者は自身のコード修正による影響範囲が広くなることを避けがちになるために、機能追加に合わせたリファクタリングなどの漸進的な改善が行われづらくなっていた、というわけです。
さらに、定期リリース方式によって複数のサービスが同時にリリースされることで、マイクロサービス間に生じた密結合などのアーキテクチャ上の課題が見えづらくなってしまっていました。
「フィードバックループ」「認知負荷」に立ち向かう
これらの分析を踏まえ、システムロードマップという形で技術課題への向き合い方を表明し、メンバーと課題解消に向けた対話を重ねました。その中で強調したのは、高い安全性を求めるのであれば、重厚な検証フローを挟むよりもむしろこまめに迅速にリリースすべきだというDevOpsの考え方です。また、高いアジリティを保つことが競争優位につながるという点も強調しました。これらの議論を通じて、単に開発者の体験を良くするだけでなく、それが事業価値の向上につながることを主張しました。
具体的な取り組みとして、たとえば以下のような活動を行いました。
まず、フィードバックループを改善するため、自動テストの強化を行いました。当時、社内で最も古くコアな責務を担っていたRailsアプリケーションの言語・フレームワークのアップグレードが控えていたことから、アップグレード作業の一環としてテストを追加する工数を確保しました。その際には、テスタビリティの低いコードも多く含まれていたために単体テストにはこだわらず、Request Specを中心にテストを追加していきました。また、QA時に手動で行っていたリグレッションテストをE2E化するなど、マニュアルQAに頼っていた品質保証体制からの脱却も合わせて取り組みました。
また、認知負荷を下げるために、我々のコアドメインに関する責務が2つのアプリケーションに分散して実装されてしまっているという重大なアーキテクチャ上の課題にも取り組みました。これらのアプリケーションはそれぞれRuby/Rails製, Kotlin/Spring Boot製と技術スタックも異なっており、開発者の大きな負担となっていました。Ubieでは、2022年末に「プロダクトサービスにはNode.jsを使う」という技術選定を行いましたが、当時はまだ多くのアプリケーションが古い技術スタックのままとなっていました。
そこで、特に頻繁に変更が加えられる一部の機能に絞って、社内標準の技術スタックに則った新しいアプリケーションに切り出し集約する、というリアーキテクチャを行いました。この際、フロントエンド側のアプリケーションから見える振る舞いは基本的に変更せずに維持しつつも、単体テストの追加を必須とすることで内部のクラス設計等の改善を促しました。
学びと今後の展望
これらの活動により、現在アクティブに開発が行われる主要な機能については自動テストが整備され、オンデマンドでのデプロイが可能となりました。これによってフィードバックループが大きく改善されました。また、技術スタックが統一されたこと、アーキテクチャ上の課題や内部設計が改善されたことで、認知負荷の低減にもつながりました。特に自動テストを強化したことの貢献が大きく、我々にとってのセンターピンはこれだったと感じています。
また、DevOpsやDevExの考え方は、安定性を重視する我々の医療機関向けのSaaSの開発にも十分に適用できることが分かり、全社的な開発生産性向上の取り組みを進めるうえで大きな自信となりました。
おわりに
今回お話しした開発生産性の改善はまだまだ道半ばです。完全なオンデマンドデプロイの実現や技術スタックの統一まではまだまだ多くの作業が残っています。
さらに、今後我々は「BtoCコンパウンドスタートアップ」として、患者のパーソナル・ヘルス・レコード（PHR）データを中心に据えてプロダクトを統合し、医療体験を再構築することに取り組んでいきます。そのために、生活者向けサービスとのIDやデータ連携のための基盤システムなどの開発にも取り組んでいく予定です。
Ubie では、医療×テクノロジーの最前線で技術的負債や基盤システムへの投資などの挑戦的な課題に一緒に取り組んでくれる方々のご応募を心からお待ちしています。