Upgrade to Pro — share decks privately, control downloads, hide ads and more …

「ビジネスに向き合え」ビジネスモデルを作る過程で生まれた モノリシックアプリケーションの技術的...

Stephen S.H.
January 26, 2024
370

「ビジネスに向き合え」ビジネスモデルを作る過程で生まれた モノリシックアプリケーションの技術的負債の解消方策としての マルチプロダクト化

2024年1月25日に開催された「TechBrew in 東京 〜技術的負債と共に歩むプロダクトの成長〜」でLTした資料になります

Stephen S.H.

January 26, 2024
Tweet

Transcript

  1. 技術的負債とは何か? • 「なぜ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 なし あり (視覚的に説明するための図)
  2. ⾃⼰紹介 • matsuri technologies株式会社開発部所属 Philosopher、Engineering Manager • Engineering, Scrum Masteringもやっている

    • 創業1年⽬でジョイン • コントリビューション(謝辞に名前が載るという意味) • ⼤堀淳(2021)「プログラミング⾔語Standard ML⼊⾨ 改訂版」共⽴出版 • ⼤堀淳(2021)「コンパイラー:原理と構造」共⽴出版 • https://atsushiohori.github.io/ja/texts/compiler/acknowledgments/
  3. マルチプロダクト化の影響 (ビジネスの変化も関係している) 語りたくなる点(よかった点) • ドメインごとのリリースができるよう になり、機能のリリースが早くなった。 • ⾒通しが⽴つようになった(開発チー ムも事業部側も) •

    ⾔語やFWを複数採⽤できる(Ruby, Rails, Golang, Rust, React, TypeScript) 改善点(わるかった点) • インパクトを出すまでの⼀連のサイク ルは、そこまで早くならなかった。 • もしかしたら遅くなったかも • 機能の属⼈性が、ドメインごとの属⼈ 性に変わっただけかも
  4. 結論:ビジネスに向き合え • Clean Codeを書くべきだから書くのではない。ビジネスに良い影響を与えるか らClean Codeを書いた⽅が良い。 • ビジネスをより良くしないなら、その「技術的負債」の解消には価値がない。 • 「技術的負債」と呼ぶべきでもないだろう。

    • ビジネスに向き合っていないと、何を、誰が、どう、やるのか、ということが決 まらない • 開発者としても、⽬的やモチベーションにつながらない。 • ビジネスに向き合うことこそが、「技術的負債」への気づきと解決をもたらす。