見出し画像

プロダクトの性質から考えるシステムと組織のアーキテクチャー#UPSIDER春のTech祭り

株式会社UPSIDER

前回までのお話

UPSIDERの新規機能開発を担当するPioneer チームでエンジニアをしているRyoto（@ryoto_kubo）とTakuyaが、プロダクトを高速で作ってリリースしていくために大切にしていることや、あえて一定の犠牲はあるよねという共通認識を持ちながら進めていること、どのようなコミュニケーションを行いながら開発を進めているのかについて深掘りしました。まだご覧になってない方はぜひチェックを！


はじめに

UPSIDERでVPoEを努めております泉(@yizumi)です。
ちょうどUPSIDERに関わり初めてからようやく1年ほど経過しましたが、本記事では、法人カード「UPSIDER」事業におけるシステムアーキテクチャーや組織・技術選定の特徴や取り組みについてご紹介させてください。

UPSIDERのプロダクトの特徴

法人カード「UPSIDER」のプロダクトは、大きく分けるとカード決済を確実に行うための決済基盤と、取引にまつわる管理業務（仕訳、証憑管理、請求管理など）を支えるための機能によって構成されています。

決済基盤領域と管理業務領域の特徴

決済基盤の方は、いわゆる与信枠を含めて顧客の「金融資産」にアクセスするための基盤になるため、例えば「決済そのものができない」あるいは「カードが一時ロックしているにもかかわらず使えてしまう」といった資産の利用や、その制御機能が不全に陥ると重大なインシデントになってしまうがゆえ、セキュリティー・スケーラビリティーも含めより堅牢性が求められる領域になります。
一方、管理業務においても、もちろん正確性が重視されることは言うまでもありませんが、管理業務が少しでも簡単に行えるように、例えば最近リリースした「証憑自動紐づけ機能」や、インボイス制度により簡単に対応するための「登録番号自動読込み」等、効率化・自動化を様々な新しいテクノロジーをクリエイティブに活用して実現する「柔軟さ」も兼ね備えなければなりません。PMFを探索しながらプロダクト開発を進めることもあります。

堅牢性と柔軟性の両面を持つアーキテクチャー

UPSIDERのカード事業のシステムアーキテクチャーで一つ特徴的なのは決済機能と管理業務を分離するためにThemisとChronosという領域に区分けしています。これはネットワークレベルで分離しており（もちろん一部互いに疎通するところはありますが）基本的には独立した境界でシステムが稼働してます。

2つの領域に分離

なので、たとえChronosの領域でダウンタイムが生じるようなインシデントが起きても、決済基盤の方は影響を受けないように設計されており、顧客の「金融資産」のアクセスに影響を与える要因を最小限にとどめております。
Chronosの領域の中でも基本マイクロサービス化されており、チームが単独で機能リリースをしても他機能に影響しないように分離しており、多少プロダクトとしての機能やUXの不完全さがあれど、フィーチャーフラグを使ってまずは価値提供の検証をするために、β版クローズトリリースをすることも可能です。

各チームに求められる「堅牢性」と「柔軟性」

これらの求められる性質はチームごとにもグラデーションがあるように思えます。
UPSIDERのカード事業は現在11チームあり、技能軸で特定の技術やスキルをベースに組成された横断チームもあれば、機能軸でドメインに分かれて開発しているチームもあります。

組織構成と各チームの特徴

フロントエンドや、アプリはユーザーのタッチポイントとしてよりダイナミックに体験が変わるため、より柔軟性が求められ、プロダクトリリースにおいても、最後の最後まで調整が入ります。そのためシステムの自由度はより求められます。
それに対して、SoR（System-of-Records）を扱うドメイン領域のバックエンド開発はデータの出し入れについてビジネスロジック上、不整合を起こさないように実装する必要があり、認証やDBトランザクションなどより堅牢性が求められる領域もあります。
また、同じバックエンドでも、何十もの機能が複雑に絡み合って作られたモノリシックなシステムを扱うチームもあれば、PMFのための探索をしているチームでは、プロダクトの成熟度が違うため、柔軟性・堅牢性のスライディングスケールは変わってくると思います。

各技術スタックのライフサイクルと、変化への対応

技術スタックのライフサイクルは、要件が柔軟に変わる必要のあるところは早く、より堅牢に作られるべきところは遅くなる傾向があります。それに応じてシステムの大きな変更もそのライフサイクルに合わせて実行していかなければなりません。

技術スタックのライフサイクルイメージ図

例えば、フロントエンドは一般的にも1~2年であっという間にスタックが変わり、破壊的変更を要するアップデートも含め、とにかく変化が激しい領域です。スマホアプリ開発も新機種の対応やOSのバージョンアップグレードに伴い、どんどん変更を迫られる領域です。
バックエンド技術に関しては前述の通りプロダクトの成熟度で決まる部分もありますが、一般的な技術スタックのライフサイクルで言えば、GitHubの出すThe State of Octoverseなどのトレンドを見ると2~3年でガラッと入れ替わるレベルではなく、5~6年でトレンドが1つ2つ入れ替わるスピード感かと思います。
一方インフラ／プラットフォームやネットワーキング領域になると、10年スパンでもほぼ仕様が変わらないですし、なにか大きな変更が加わるときは最低半年とかプロジェクトによっては2年とかの時間軸（たとえばCloud Computing Platformの移行など）で入れ替わるといったことも珍しくありません。プラットフォームは上位レイヤーすべてに影響を及ぼすので、なかなか速度があげられない領域です。

UPSIDERでもこのライフサイクルの速度に合わせて領域によってはドラスティックに変化を促し、違う領域においてはより慎重に変更を重ねていくアプローチを取っています。

Frontend
特にVue 2をからVue 3への移行でBreaking Changesがあるため、大規模な改修を進めているシステムも多いと思いますが、これを期にUPSIDERでは、Reactをメインストリームに見据えて、新規機能についてはReact、既存のコードベースもVueからReactに移行しており、速度の早いFront-end技術の移り代わりに対応するためのプロジェクトを推進しています。

Backend
この領域は、フロントエンドほどアグレッシブになにかを置き換えるという動きは取らないものの、多数のビジネスロジックが集中してしまっているKotlinベースのモノリシックコンポーネントから、認証やBFFの機能を分離して、技術的にもGoやNode/Typescriptに置き換えるなどを行って、より多くのエンジニアがスピード感を持って開発できるようにするプロジェクトを推進しています。

Platform
この1年ほどは、以前から課題になっていたObservabilityを向上するための基盤がようやく整備され、Grafanaによる可視化や各メトリクスのモニタリング・アラーティングを行うためのファンデーションが整った状態です。次の1年ではSLOで定めた可用性を上げるための抜本的な変更を行っていく予定です。
このように技術選定の領域でも必要なスピード感で変化に対応していかなければ、全体の開発速度がどんどん低下していき、事業上の競争優位性が下がるだけでなく、エンジニア自身の効率が下がることによる離反も招いてしまう要因になるため、一定のリソースをここに投じる必要があると思います。

まとめ

自分はどこまで行っても技術戦略は「How」、つまり課題に対する解決や、構想を実現させるための「手段」だと思っており、どのような性質のプロダクトを作るかによって柔軟に切り替える必要があると思っております。

事業戦略（Why）とプロダクト戦略（What）、技術戦略（How）の思考イメージ

なので考え方も基本的には、Why→What→Howの順番に思考が働き、まずは事業上の戦略(Why)、それから何を作るかの議論(What)、最後にどのようにそれを実現するか（How）、を考えるのが自然だと思っております。（自分はよくこれを「構想」と「実現」の両輪と整理しています）
そのHowの領域に含有されるシステムアーキテクチャー、技術戦略、組織戦略は相互に影響を与えることが多く、いわゆるコンウェイの法則に説明されるように、それらは分離不可能なものだと認識してます。
チームのコミュニケーションパターンや、責務の設計の指針となるTeam Topologyのような理論も整理をするうえで非常に便利なツールセットになりえますが、それだけでは成り立たないギャップを、事業のニーズやスピード感、現場感もって、連動させて考えていくことも必要ですし、また、事業戦略・プロダクト戦略も時間の経過と共にどんどん変化するため、アーキテクチャーや技術選定・組織は固定的なものではなく、変化を許容するものでないといけません。
そして何よりも「組織」については、人そのものの話なので、メンバー自身が変化を許容しなければならない場面も多々あります。UPSIDERのもメンバーの一部は、チーム開発のスピードを上げるために、全く違う言語での開発に取り組んだり、同じ技術でも全く違うドメインを任せられたり、アーキテクチャー上の変更を受け入れながら開発することもあります。あるいは技術的な領域の変化だけでなく、IC (Individual Contributor)からマネジメントを任せられたりと、責務の変化もあります。
これらの「組織」「アーキテクチャー」「技術スタック」で起きる様々な「変化」は、それを中長期の投資と見据えて意思決定を行い、粘り強く推進するためのリーダーシップメンバーの存在も重要だと思っております。
我々もまだまだシステムも組織も未完成ではあるし、まだまだ足りないことが多々ありますが、その未完成の状態をより成熟にするためにも、個別領域の開発を推進する優秀なエンジニアの方の力が必要であることは言うまでもありませんが、大きな意思決定をして、健全な変化を促すアーキテクトや、また組織の変化を支えるためのエンジニアマネージャーの力もこれまで以上に必要だと感じている今日このごろです。
エンジニアマネージャーは絶賛採用中ですのでもしご興味をもっていただきましたら、是非カジュアルにお話ししさせてください。

次回予告

次回はVPoPの森（@diceK66）が「UPSIDERが新プロダクト・新機能を生み出し続けられる仕掛け」と題して、UPSIDERでのプロダクト開発における取り組みをご紹介します。


この記事が気に入ったらサポートをしてみませんか？