@hokaccha です。こんにちは。最近は主にプロダクト基盤チームで組織的な開発生産性の改善に取り組んでいます。この記事では開発生産性を改善の一環として、現在取り組んでいるシステムアーキテクチャの改善や技術的負債の返却の取り組みについて紹介します。
なぜアーキテクチャを改善するのか
最初に、なぜ我々がアーキテクチャ改善に取り組んでいるかの背景について説明します。
最終的にやりたいことは開発生産性を改善することにより、事業の成長速度を最大化することです。アーキテクチャの改善はそのための手段の一つであり、他にも開発プロセスの改善や開発組織の最適化など、開発生産性の改善のために並行しておこなっている施策は多岐にわたります。
ではアーキテクチャの改善がどう開発生産性に影響を与えるかという話ですが、これについては Martin Fowler の Design Payoff Line の図を引用します。
初期の速度を重視し、設計を軽視したプロダクトは徐々に生産性が頭打ちになっていき、それと比べてよく設計されたプロダクトは長期的に見ると生産性が高いことを表しています。青いラインはまさに技術的負債を抱えた状態であり、これをオレンジのラインに戻していくことがアーキテクチャ改善による開発生産性最大化という活動であると捉えています。
なぜ今やるのか
なぜ「今」やるのか、というのも大事なトピックの一つです。これについては以下の資料がわかりやすかったので引用しておきます。
上記の資料にもあるように、スタートアップは技術的負債の解消にいつ向き合うのかという問題と常に戦っています。弊社でも同様の問題は当然あり、これまでプロダクト側、ビジネス側の事情を優先して開発をおこなってきました。長期的な生産性を犠牲にして短期的なスピードを優先してきたわけです。
質とスピードはトレードオフではないという話もありますが、中長期の生産性を毀損しない設計をしながらスピードを落とさずにプロダクトを作り続けるというのは理想ではありつつ、お金や人的リソースの制約があるスタートアップにとっては至難の業であると思います。
ただ、ユビーではこれまで技術的負債に目をつぶって何もしてこなかったわけではなく、定期的に負債解消のプロジェクトが立ち上がって優先度が高い負債については対応していましたが、プロダクト側の事情で長続きせず継続的に改善するという体制ができていない状態でした。
そういった状況の中、ここ最近でプロダクトが成長してきて、これからはプロダクトをスケールしていくというフェーズに差し掛かっており、今こそ技術的負債を解消するとともに、開発生産性を最大化するために開発基盤に投資していくという意思決定をし、継続的に改善する体制を作って推進しているのがここ最近の話です。
ユビーのアーキテクチャの現状
次に、現状どういったアーキテクチャになっているのか、どういった課題があるのかについて説明します。簡易化のため色々省略していますが、ざっくりなアーキテクチャとしてはこんな感じです。
ユビーには toC 向けの症状検索エンジン「ユビー」（以下 toC）、toB 向けの ユビーAI問診 （以下 toB）の2つのプロダクトがあります。
どちらもフロントエンドとバックエンドは別れており、フロントエンドは React、Next.js で書かれており、バックエンドは Kotlin で書かれています。このバックエンドサービスはいわゆる BFF というものではなく、ロジックも DB も持っているサービスです。その後ろには toB/toC 共通で利用するサービスや、データの性質の違いからマイクロサービスとして切り出されているもの、分ける必要がないのに別サービスとして切り出されているサービス（間違ったマイクロサービス化）などがあります。
現状の課題
現状の課題としては例えば以下のようなものがあります。
- toB/toCの境界が曖昧で依存関係があり、どちらかの変更がもう一方に予期せぬところで影響する
- 古くから存在しているコードやデータのコンテキストが失われており認知負荷が高い
- 複数の言語、フレームワークが混在していてコンテキストスイッチの負荷が高い
- データ変更の影響が多岐にわたりすぎて影響範囲が予測できない
- サービスの数が多く、オーナーが不在なサービスが存在している
- マイクロサービスの責務が曖昧で不必要に複数のドメインを扱っていたり、同じ責務が複数のサービスにまたがったりしている
これらの問題はアーキテクチャだけの問題ではなく、組織設計やカルチャーなどの問題も含まれますが、まずはアーキテクチャを見直し、その中で組織設計や文化の浸透をおこなっていくことにしました。
アーキテクチャ改善の方針
アーキテクチャの改善ポイントはいくつもありますが、現在見えているロードマップで重要なポイントとしては、主要コンポーネントの書き直しとモジュラモノリス化です(他にも toB/toC の分離やマスターデータの再設計などやるべきことは本当に色々あります）。
現在は Rails や Kotlin、Go や Node.js といった言語、フレームワークが使われていますが、以下の記事でも紹介されているように、技術スタックとしては Go と Node.js に寄せていくことになります。
現状のシステムをすべて書き直すということはおそらくしませんが、最も開発が活発な主要コンポーネントについては再設計を兼ねて書き直すという判断をしました。主に書き直す予定のものは以下です。
- toBのバックエンドサービス（Kotlin）
- toCのバックエンドサービス（Kotlin）
- 問診ロジックを扱うサービス（Rails）
これらはユビーのシステムの中でも比較的大きいサイズのサービスではありますが、10年ものの巨大なモノリスというような規模感でもないので、スクラッチで書き直しても十分にリターンは得られる考えています。おそらくこのまま3年、5年と何もしないと書き直しのコストがリターンを大きく上回るようになって手がつけられない状態になると思います。
マイクロサービスとモジュラモノリス
この中で、toB、toCのバックエンドサービスは現在のモノリスからモジュラモノリス的なアプローチで再設計しようと考えています。
現在は技術（Domain, Infrastructure, UseCase, Presentation など) で分割したモノリスなレイヤードアーキテクチャになっています。これは今のところ破綻まではいっていませんが、ここから組織やプロダクトがスケールして機能が増えていくにつれて複雑さが増していき、複数のチームで開発する際のアジリティが低下していきます。
そういった問題に対するアプローチとしてドメインで分割するアーキテクチャがあります。現状ではマイクロサービスとモジュラモノリスが現実的な選択肢でしょう。我々もマイクロサービスに寄せていくというアプローチも考えてはいますが、システム全体の複雑性の増加、データの再設計の必要性、データの整合性の担保、結合テストや開発の難しさなどのトレードオフがあります。そういったトレードオフや、比較的現在のアーキテクチャからコストをかけずに移行できるということも考慮し、今回はモジュラモノリスを検討しています。
また、共通基盤やいくつかのサービスはすでにマイクロサービス的にサービスが切られています。このあたりは、ドメインの境界がはっきりしていないものを整理したり、マイクロサービスである必要がないものをモジュラモノリスに取り込んだりする可能性はありますが、すべてをモジュラモノリスに吸収するということはしません。このあたりはバランスですが、サービスのアーキテクチャ特性やトレードオフを都度判断しながら進めていくことになります。
今回はモジュラモノリスにするという意思決定をしましたが、組織やプロダクトの変化によって、今後システム全体をマイクロサービスにしていくという判断もあり得ると考えています。そうなったときにもモジュラモノリスでドメインを分割しておくことによってマイクロサービスへの移行もやりやすくなるはずです。
持続可能なアーキテクチャ改善のための仕組みづくり
最後に、こういったアーキテクチャを継続的に改善していくための仕組みづくりについて紹介します。
アーキテクチャに責任を持つチームの立ち上げ
まず最初にやったことはアーキテクチャ改善を推進するチームを作ったことです。これまでアーキテクチャ改善に取り組んできたことは何度もありましたが、タスクフォース的なチームが組まれてひとつの問題が解決されたら解散という感じで継続的なアーキテクチャ改善ができていませんでした。
そういった学びを生かして中長期的なアーキテクチャ改善に取り組むチームを作り、現状の課題の精査、Epicの洗い出し、優先順位付けをおこない、ロードマップを敷いて今後の計画を見えるようにしました。
Design Doc の運用
負債が積まれてきた背景の一つにアーキテクチャのレビューがあまりされておらず、知らない間に負債が積み上がっていたという事情もありました。それを防ぐために、システムアーキテクチャの変更を伴うような決定に関しては必ず Design Doc を書いてアーキテクチャ戦略チームがレビューするというフローを整備しました。
Design Doc は以下のフォーマットを参考にしつつ、書く敷居を下げるためにもう少し簡易化したフォーマットにしています。
指標の可視化
また、開発生産性を図るための指標として Four Keys を導入し、継続して監視する仕組みを作っているところです。Four Keys に関してはアーキテクチャだけに関する問題ではなく、開発プロセスや組織体制、カルチャーなど様々な問題と密接に絡んできますが、アーキテクチャもその中の大きな要因の一つではあるので、アーキテクチャ改善がどう Four Keys に効いたのかを振り返りながらイテレーティブに改善ができるようにしていきたいと考えています。
まとめ
ユビーがアーキテクチャの改善や技術的負債の解消とどう向き合っているのかについて説明しました。まだ改善は始まったばかりですが、ここから10年戦うためのシステムの設計ができるタイミングと考えると、とてもワクワクしてきます。
そのようなアーキテクチャ改善や設計を行う上で、やりたいことはたくさんあって人が全然足りていないので、もしこういった話に興味がある人がいたら @hokaccha まで DM ください。まずはカジュアルに話しましょう！
Discussion