Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「ビジネスに向き合え」ビジネスモデルを作る過程で生まれたモノリシックアプリケーションの技術的...
Search
Stephen S.H.
January 26, 2024
0
380
「ビジネスに向き合え」ビジネスモデルを作る過程で生まれた モノリシックアプリケーションの技術的負債の解消方策としての マルチプロダクト化
2024年1月25日に開催された「TechBrew in 東京 〜技術的負債と共に歩むプロダクトの成長〜」でLTした資料になります
Stephen S.H.
January 26, 2024
Tweet
Share
More Decks by Stephen S.H.
See All by Stephen S.H.
Google Slidesの日本語太字フォントで掠れないものはあるのか
shanada
8
2.2k
Featured
See All Featured
Code Review Best Practice
trishagee
64
17k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Building an army of robots
kneath
302
43k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Adopting Sorbet at Scale
ufuk
73
9.1k
Typedesign – Prime Four
hannesfritz
40
2.4k
Happy Clients
brianwarren
98
6.7k
Gamification - CAS2011
davidbonilla
80
5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Transcript
ビジネスモデルを作る過程で⽣まれた モノリシックアプリケーションの技術 的負債の解消⽅策としての マルチプロダクト化 ⼤王 A.K.A. STEPHEN SATORU HANADA(@FDDAIOH) MATSURI
TECHNOLOGIES株式会社 ~ビジネスに向き合え~
技術的負債とは何か? • 「なぜClean Codeを書くのか?」
技術的負債とは何か? • 「なぜClean Codeを書くのか?」 • ビジネス上の正当な理由による。 • つまり、変更にかかるコストのカーブを平坦にする。 • 技術的負債というのは、
• 変更コストの増⼤を増やすものであり、かつ、 • チームの中からしか⾒えないものである。 • 完成の定義からすれば、やっていたはずのこと。 • 補⾜:パフォーマンスの問題は技術的負債ではない。 1.4 1.8 2.5 4.5 1.4 1.5 1.4 1.6 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 1 2 3 4 なし あり (視覚的に説明するための図)
⾃⼰紹介 • matsuri technologies株式会社開発部所属 Philosopher、Engineering Manager • Engineering, Scrum Masteringもやっている
• 創業1年⽬でジョイン • コントリビューション(謝辞に名前が載るという意味) • ⼤堀淳(2021)「プログラミング⾔語Standard ML⼊⾨ 改訂版」共⽴出版 • ⼤堀淳(2021)「コンパイラー:原理と構造」共⽴出版 • https://atsushiohori.github.io/ja/texts/compiler/acknowledgments/
2016年からどう変わって来たか。 メッセージ 返信代⾏ ⾃動返信 物件情報管 理 マルチOTA 清掃管理 マンスリー 管理
2016年にリリースしてから、どんどん機能が増えていった…
実際どうだった? メッセー ジ返信代 ⾏ ⾃動返信 物件情報管 理 清掃管理 マンスリー 情報管理
変更コストはどんどん増⼤していった…
変更コストの増⼤の理由 • 「仮説を⽴て、リリースし、検証し、ビジネスモデルを探る」というスタイル • 設計を事前に考えるよりも、ユーザーへの価値提供を優先 • テーブル設計のミス • 密結合な実装 •
モジュラーモノリスではもちろんない • ドキュメンテーションの不備(属⼈性) • アドホックな対応の多さ • … etc.
変更コスト増⼤の影響 • 密に結合しているゆえに、1つの機能のリリースまでが遅くなる。 • 何がボトルネックかわからず、フラストレーションが溜まりやすい。 • 開発チームにとっても、事業部にとっても。 • 新しいことをやりづらく、保守的になる傾向にあった。
マルチプロダクト化という選択 実物件情報 管理 メッセージ、 清掃情報、 マンスリー 情報 チェックイ ン
マルチプロダクト化という選択 実物件情報 認証基盤 メッセージ チェックイン 清掃 マンスリー
マルチプロダクト化という選択 実物件情報 認証基盤 メッセージ チェックイン 倉庫 清掃 マンスリー
マルチプロダクトにできた理由 • ビジネスに向き合って来たから。 • ドメインを分けられるほどに、ビジネスを理解ができたから • ビジネスモデルを作れたから。 • 変更コストの増⼤を事業としても理解できたから。 •
物件数の増加が会社の中期⽬標ともマッチした。 • エンジニアにやっていきがあったから
マルチプロダクト化の影響 (ビジネスの変化も関係している) 語りたくなる点(よかった点) • ドメインごとのリリースができるよう になり、機能のリリースが早くなった。 • ⾒通しが⽴つようになった(開発チー ムも事業部側も) •
⾔語やFWを複数採⽤できる(Ruby, Rails, Golang, Rust, React, TypeScript) 改善点(わるかった点) • インパクトを出すまでの⼀連のサイク ルは、そこまで早くならなかった。 • もしかしたら遅くなったかも • 機能の属⼈性が、ドメインごとの属⼈ 性に変わっただけかも
結論:ビジネスに向き合え • Clean Codeを書くべきだから書くのではない。ビジネスに良い影響を与えるか らClean Codeを書いた⽅が良い。 • ビジネスをより良くしないなら、その「技術的負債」の解消には価値がない。 • 「技術的負債」と呼ぶべきでもないだろう。
• ビジネスに向き合っていないと、何を、誰が、どう、やるのか、ということが決 まらない • 開発者としても、⽬的やモチベーションにつながらない。 • ビジネスに向き合うことこそが、「技術的負債」への気づきと解決をもたらす。