コンパウンド戦略に向けた技術選定とリアーキテクチャ

株式会社ナレッジワークCTO 川中 真耶
アーキテクチャConferenceでの発表資料です（2024/11/26）
https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/Z5OijqyP

＜セッション概要＞
ナレッジワークは、エンタープライズ企業の営業生産性を向上させるSaaSプロダクトを提供しています。創業当初は単一プロダクトのためのアーキテクチャを採用していましたが、今後3年間で10個のプロダクトをリリースするコンパウンド戦略を推進するにあたり、複数プロダクトが重なり合いながら同時に展開が可能な新たなアーキテクチャへと大きく舵を切りました。このセッションでは、コンパウンド戦略を実現するための設計思想や、技術選定、リアーキテクトの方針について、具体的な事例を交えてご紹介します。

Transcript

1. アーキテクチャ Conference 2024 講演資料 コンパウンド戦略に向けた技術選定とリ アーキテクチャ mayah (@mayahjp) / Knowledge Work, CTO
2. © Knowledge Work Inc. プロフィール 2 株式会社ナレッジワーク CTO 
 川中 真耶
 主な経歴
 2006 東京大学大学院情報理工学系研究科コンピュータ科学専攻
 修士課程修了
 2006 日本IBM 東京基礎研究所リサーチャー
 2011 Google Japan ソフトウェアエンジニア
 2020 株式会社ナレッジワーク共同創業
 
 ACM国際大学対抗プログラミングコンテスト世界大会出場
 「王様達のヴァイキング」（週刊ビッグコミックスピリッツ）技術監修　など
 
 

3. © Knowledge Work Inc. Agenda 目次 • 会社・事業紹介 • アーキテクチャの変遷 • 各時代のアーキテクチャの目論見と pros/cons • まとめ 3
4. 会社紹介
5. © Knowledge Work Inc. Profile　会社概要 5 創業日 　2020年4月1日 代表者 　麻野 耕司 資本金 　61.3億円（資本準備金等含む） 事業内容 　ナレッジワークの開発・提供 主な株主 　グロービス・キャピタル・パートナーズ、DNX Ventures、WiL 　One Capital、ANRI、XTech、Salesforce Ventures 　ユーザベース、フォースタートアップス、Sansan
6. © Knowledge Work Inc. 6 できる喜びが巡る日々を届ける Deliver the joy of enablement 「昨日できなかった仕事が今日できるようになった」 「今日うまく進められなかった仕事も明日はうまくできるかもしれない」 そんな想いで働ければ、仕事に希望が持てるはずです。 しかし、世の中の多くの人が「上司に恵まれない」「職場に恵まれない」 「会社の仕組みに恵まれない」などの理由で、 「努力しても成長できない」「努力しても成果が出ない」つまりは 「努力しても報われない」という環境で仕事をしています。 私たちは『イネーブルメント』を実現するプロダクトを提供することで 世の中の人たちが仕事にできるようになることを支援し、 働く喜びが巡る日々を届けます。
7. © Knowledge Work Inc. 製品紹介 7 みんなが売れる営業になる セールスイネーブルメントクラウド セールスイネーブルメントクラウド「ナレッジワーク 」を提供しています
8. © Knowledge Work Inc. ナレッジワーク 導入実績（一部の企業様のみご紹介しています） ナレッジワークは、多くの大手企業様に数千名規模でご利用いただいています 8
9. アーキテクチャの変遷
10. © Knowledge Work Inc. 事業とアーキテクチャの変遷 10 創業当初 ＋オプション　時代 コンパウンド　時代 単一のコアプロダクト コア プロダクト オプション プロダクト オプション プロダクト 共通基盤 コア プロダ クト プロダ クト プロダ クト オプ ション 事業の進捗に合わせてプロダクトアーキテクチャを変革してきました 似たような変遷をたどるスタートアップも少なくないと思われます 2020 2022~ 2024~
11. © Knowledge Work Inc. 各時代のアーキテクチャについて pros/cons と変遷を振り返り 同じ道を歩む人の道しるべを示す 11 今日のメイントピック
12. 単一プロダクト時代
13. © Knowledge Work Inc. 単一プロダクト時代の前提 13 • プロダクトの機能は少ない ◦ エンジニアもセールスもすべての機能を把握出来る • エンジニアの人数は少ない ◦ エンジニアは 10 人以下 ◦ １チームで十分、マネージャーも一人 • プロダクトはこれからどう転ぶか分からない ◦ 当たるかもしれないし、当たらないかもしれない ◦ 当たった場合にはスムーズにスケールする構造に移行できる必要がある ◦ スピードを出すためにオーバーエンジニアリングは避けたい 創業当初 単一のコアプロダクト 2020
14. © Knowledge Work Inc. 14 単一プロダクト時代: 調整の要らないアーキテクチャ frontend 単一 Next.js App backend 単一 gRPC server protobuf 一番技術力の ある人に全権を 預ける 一番技術力の ある人に全権を 預ける CTO が責任 持って API 定義 スキーマ駆動 CTO (backend に強み) と frontend 責任者に全権を預け 可能な限りこの二人の合意だけで全てを済ませる API 定義は引き返しづらいのでスキーマ駆動開発する UI を把握して API を作る excuse: ここに web 向 けの protobuf 変換レ イヤーが必要
15. © Knowledge Work Inc. 15 • 古き良き MVC アーキテクチャからスタート ◦ model ▪ モデル定義 ◦ view ▪ view layer は HTML ではなく gRPC message を作成して返す ◦ controller (gRPC service) ▪ request を受けてモデルを操作して response を返却 • 最初はどのように機能単位で分割していくのかもよく見えてないので、なるべく論理的に混ぜないことに注意することとし、 フラットに書くことも許した ◦ ちゃんと力ある人であれば、規約がなくても機能を論理的に区切った状態でサービスを作れる ◦ 間違っていたらすぐにリファクタリングして直す ◦ 横着する人がいたらすぐにぐちゃぐちゃになるので機能単位で区切るコストを払うべき 尚 frontend も似たような構成になっていた backend の構成
16. © Knowledge Work Inc. 割り切り • 一番技術力ある人が間違えたら仕方ないと割り切る • 責任者が全部定義しているから、間違えたら自分で責任取って直すという覚悟を持つ pros • とりあえず作り始められる • frontend, backend の強みがある人がそろっていたので、その力を最大化できる • 合意形成にかかる時間が少ない cons • モジュールが大きく分かれてなくても論理的に違うものを混ぜない常識ある人だけでサービスを作る必要がある • 強みが立った人が揃ってないと取りづらい • プロダクトの未来やコアドメインを常に理解しながら作らないと後のリアーキテクチャが難しくなる 16 単一プロダクト時代の pros/cons
17. オプションプロダクト時代
18. © Knowledge Work Inc. オプションプロダクト時代の前提 18 • プロダクトの機能が増えてきた ◦ 力がある人は全部を把握している ◦ 自分が担当しているプロダクトしか分からない人もいる • エンジニアの人数が増えた ◦ エンジニアは 20 人程度 ◦ ３チームで各プロダクトの並列開発が可能 • コアプロダクトは初期的な PMF に到達した ◦ コアプロダクトの品質は上げていく必要がある • オプションプロダクトは当たるかもしれないし当たらないかもしれないからすぐに出 したい ◦ 品質要件が異なるプロダクトが混在している ＋オプション　時代 コア プロダクト オプション プロダクト オプション プロダクト 2022~
19. © Knowledge Work Inc. 19 モジュラーモノリスの採用 tenant module user module group module knowledge module role module コアプロダクト内も機能単位で モジュールとして切り分け …… オプション プロダクトA オプション プロダクトB product A module product B module 依存 可能 gRPC service gRPC service gRPC service view view view バイナリは１つ、全部同時にデプロイ / オプション単位でモジュール化
20. © Knowledge Work Inc. Multiple teams
 Single team
 １つの機能を１チームで作っている みなが何をやっているかわかる 20 コードの衝突確率増加 知らない間に密結合化する事象の増加 なぜモジュラーモノリスにするのか（チーム事情） 人数増加に伴う多チームが見えてきた段階で移行を決断（多チーム化の前に決断） あらかじめモジュラーモノリスへの道標を示すことで チームが分割しても生産性を維持できるようにしておきたい
21. © Knowledge Work Inc. 21 なぜモジュラーモノリスにするのか（マイクロサービスでない理由） モジュラーでないモノリス モジュラーモノリス マイクロサービス 疎結合度 開発 オーバーヘッド デプロイ容易性 バージョン 管理整合容易性 ※全て個人の偏見です 特別注記 × ◯ △ ◯ △ ◯ × △ ◯ △ × × 絶対だれかが分散トランザク ションの話を始める ◯ インフラ運用 容易性 ◯ ◯ ×
22. © Knowledge Work Inc. 22 なぜモジュラーモノリスにするのか（マイクロサービスでない理由） モジュラーでないモノリス モジュラーモノリス マイクロサービス 疎結合度 開発 オーバーヘッド デプロイ容易性 バージョン 管理整合容易性 ※全て個人の偏見です 特別注記 × ◯ △ ◯ △ ◯ × △ ◯ △ × × 絶対だれかが分散トランザク ションの話を始める ◯ インフラ運用 容易性 ◯ ◯ × △ も acceptable、あるい は工夫でマイクロサービ スと同等の ◯ にできると 判断して採用を決定
23. © Knowledge Work Inc. 23 • clean architecture に近い構成を採用 • トップレベルはレイヤー モジュラーモノリスへの構成変更 • トップレベルを意味で区切る ◦ 公開するモジュール API と model 以外は 内部 package へ移動して非公開化 • service レイヤーに置かれていたコードは意味で 区切ったモジュールの中へ 当初構成 モジュラーモノリス構成 model/ (model layer) usermodel/ knowledgemodel/ service/ (controller layer) userservice/ knowledgeservice/ infrastructure/ rdb/ usermod/ user_module.go 公開メソッド定義) usermsg/ 公開データ構造定義) internal/ model/... 内部で利用する model 実装 service/... module API 実装 adapter/... repository 実装等 service/ これは残る userservice/ 内部では usermod を利用する
24. © Knowledge Work Inc. 24 pros • チームで触るモジュールが分かれて、少ない知識でも開発が始められる • 論理的に分けたので、疎結合度が高い • 公開してよいモジュール API を定義するようにしたので、内部が多少アレでも API がきれいならリファクタリングできる cons • なんだかんだ全てのプロダクトの共通モジュールを全員が触りがち • どっちのモジュールに入れたらいいのか分からない機能がしばしば出てきて議論になる • 移行には大変腕力が必要 ◦ 知らない間に絡み合っているコードがある ▪ 頑張ってほどくのに２週間ぐらいは使った ◦ モジュールを疎結合にしづらい仕様が混じっている ▪ 仕様を変更する モジュラーモノリス構成の pros/cons
25. コンパウンド時代
26. © Knowledge Work Inc. Multiple Products
 Single Product
 １つの良いプロダクトを磨き込むことが 良しとされてきた 26 複数プロダクトを持つことで開発・営業に複利を 効かせることが良しとされ始めた SaaS 事業の環境の変化 rippling 社の成功によりコンパウンド戦略を取るスタートアップが急増 ナレッジワークでも同様の戦略をとって市場の拡大を狙う
27. © Knowledge Work Inc. 2023年11月のプレスリリース 27
28. © Knowledge Work Inc. 大きな方針変更 28 オプションプロダクトとして作ってきた部分を 単体のプロダクトとして成立するようにしま す
29. © Knowledge Work Inc. 29 私: 3 年後にプロダクト作るのをやめているわけがないから絶対 10 個で収まるわけがない…… マルチプロダクト、コンパウンド戦略に適したアーキテクチャに変更することを決断 実現したいこと • 各プロダクトを独立したチームで作れるようにする ◦ 少なくとも独立でデプロイできるようになる • リアーキテクチャ中にも歩みを止めない ◦ 0 から新しく作ったりせず、既存のものから徐々に移行できるようにする 幸いにもモジュラーモノリス化が進んでいたので下地はできているはず！ → プロジェクト化して多数のエンジニアの協力で進めていくことにした リアーキテクチャを決断
30. Project Bamboo _KNOWLEDGE WORK
31. © Knowledge Work Inc. Project Bamboo Project Bamboo の心 • 竹を割ったような美しいプロダクト分割 • 雨後の竹の子のようにプロダクトがニョキニョキ生えても問題がない設計 コンウェイの法則を念頭に • プロダクト単位でチームができるから、その単位で完結する設計へ 最終的に目指すアーキテクチャと遷移方法を設計 • 設計にかかった時間は大体丸１日ぐらい • 実際の遷移は、プロダクトを作りながらであれば１年仕事と覚悟 ◦ プロダクト作成の時間は落としたくないので受け入れる • マイクロサービスには絶対にしない（少なくとも言わない） ◦ 論理的に複数のサービスをまとめたミニサービスと呼称することにした 31
32. © Knowledge Work Inc. 32 最終形の構想 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01
33. © Knowledge Work Inc. 33 最終形の構想 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 gateway layer 外からのアクセスを必ず gateway layer で受ける • client layer からの認証を管理 ◦ ブラウザからの認証 ◦ OAuth による認証 ◦ データ外部共有先からのアクセス認証 ◦ SCIM によるユーザー管理アクセス認証 ◦ 管理画面へのアクセス DB アクセスは不可とし、認証が通ったアクセスは backend layer へ
34. © Knowledge Work Inc. 34 最終形の構想 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 backend layer 実際の処理を行うレイヤー 点線の箱は以下の制約がある • 下から上に向かって依存して良い • 箱の中では依存してはならない ◦ あるプロダクトが他のプロダクトに依存 することはできない
35. © Knowledge Work Inc. 35 最終形の構想 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 middleware backends プロダクトの共通基盤 • ユーザー管理 • ナレッジ管理 などの全てのプロダクトで共有するデータをミドルウェ アとしてまとめ、ミドルウェア開発チームによる定期更 新を行う 全てのプロダクトをミドルウェアの思想の上に載っかる 用に設計していくことが大事
36. © Knowledge Work Inc. 36 最終形の構想 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 product backends 各プロダクトの実装 • １つのプロダクトに１つのバイナリ ミドルウェアとは API で通信。API の互換性は非常に重 要なので breaking change があると CI で警告がでるよ うになっている。 各プロダクトチームが独自にデプロイする。
37. © Knowledge Work Inc. 37 最終形の構想 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 central backends どうしてもプロダクト横断で何かをしないといけなかっ た場合の退避先 • プロダクト間のデータ分析
38. © Knowledge Work Inc. 38 最終形の構想 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 admin backend 社内からプロダクトの設定を変更したりする場合は admin backend より他 backend にアクセスできる形に なっている
39. © Knowledge Work Inc. 39 最終形の構想 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 subsystems コンテンツ処理基盤、データ処理、検索処理基盤、AI 処 理基盤などのような、他 backend と強調して動作する複 雑なサブシステムは外に切り出されてある １つの subsystem に対して担当者や担当チームが存在 する
40. © Knowledge Work Inc. 40 この構成の肝 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 とにかく product backend を増やせばプロ ダクトが増やせる形に 既存のミドルウェアの資産は API 呼び出しに よってそのまま使える形に → 目論見はうまくいっている（新規プロダク トの作成がこれまでとおなじ納期、半分の 人員でできている ）
41. © Knowledge Work Inc. 41 最終的に持って行きたい形は描けたので、徐々に移行できるようにマイルストーンを設計する 移行プロセス
42. © Knowledge Work Inc. 42 当初構成 frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 api-backend 全ての機能が ここにある （内部はモジュラーモ ノリス） gateway layer は当初から結構 分かれていた batch-backend バッチ処理特化 システムは別にある
43. © Knowledge Work Inc. 43 移行プロセス frontend scim cloud scheduler scim client (Azure AD, ...) cloud tasks knowledgework web frontend admin frontend externalshare external share viewer product backend knowledge work learning ... ex-api oauth client server authenticated by token auth client job invoker admin frontend admin gateway admin gateway gateway client layer gateway layer backend layer DB not accessible Authentication layer authenticated by admin token central backend central middleware / product directory middleware directory content middleware content admin backend admin notification middleware notification * cloud tasks and cloud scheduler have service account, so it's OK to skip gateway subsystems content processing cpv4 data processing dbt email email-sender search elasticsearch subsystem can access backend layer middleware layer 最終形 updated at 2024-08-01 api-backend batch- backend このプロセスはまだ途中で 2025 年内完成予定 product backend new product backend モジュラーモノリスであった サーバーで一度受け、 backend が対応できたも のは proxy として動くよう にして後ろへ流す product backend が一時的に middleware layer の機能を持っ ていることを許す 徐々に middleware API の呼び 出しに置き換えていく 新規プロダクトは理想形で 作る（必要なミドルウェアはミ ドルウェア内に作る）
44. まとめ
45. © Knowledge Work Inc. まとめ 45 • 事業の進捗とともにアーキテクチャを徐々に変更してきた ◦ 単一 MVC サーバー → モジュラーモノリス → マルチプロダクトに対応したサービス • 移行は一筋縄ではいかない ◦ 強めの権限を持った人のコミットと周りの協力が必要 • ０から作ったりしない ◦ 事業が止まってしまう、漸近的に遷移できる方法を考えるべし