ビジネスモデルを作る過程で⽣まれた モノリシックアプリケーションの技術 的負債の解消⽅策としての マルチプロダクト化 ⼤王 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を書いた⽅が良い。 • ビジネスをより良くしないなら、その「技術的負債」の解消には価値がない。 • 「技術的負債」と呼ぶべきでもないだろう。 • ビジネスに向き合っていないと、何を、誰が、どう、やるのか、ということが決 まらない • 開発者としても、⽬的やモチベーションにつながらない。 • ビジネスに向き合うことこそが、「技術的負債」への気づきと解決をもたらす。