急成長スタートアップにおける技術的負債とトレードオ フ・スライダー 株式会社ROUTE06 取締役 CTO / 共同創業者 重岡 正 1

Index / 目次 1. 自己紹介 2. 会社紹介 3. 技術的負債とエンジニア 4. 急成長期のスタートアップにおける挑戦 5. 頭の中ほとんどトレードオフ・スライダー 6. 技術的負債の管理戦略 7. 技術的負債とトレードオフ・スライダーの事例紹介 8. まとめ 9. 質疑応答 2

1. 自己紹介 重岡 正 (SHIGEOKA Tadashi) / GitHub @shige 株式会社ROUTE06 取締役 CTO / 共同創業者 普段は熊本からフルリモートワーク 本日は出張で今年初のオフィス出社 3

2. 会社紹介 4

5

6

7

8

2. Company / 参考情報 事業内容 - 株式会社ROUTE06 (ルートシックス) 顧客事例 - 株式会社ROUTE06 (ルートシックス) 数字で見るROUTE06〜働き方・キャリア編〜 9

登壇機会の御礼 ROUTE06 Tech Blogの記事経由で今回の登壇依頼をいただきました プロダクトの立ち上げから事業の拡大期にかけて、技術的負債の返済を進めながら、 日々の改善や新機能の開発を実施しています。現在、複数のロードマップが同時に進行 中のチームも存在しています。 引用元: ROUTE06 CTOが考えていること（2023年9月） - ROUTE06 Tech Blog 10

TL;DR ・スタートアップは急成長が求められる ・スタートアップの成長に合わせて ”技術的負債” の取り方を変えていく ・理想を抱いて溺死しない、理想と現実の ”トレードオフ” を考え抜く 11

3. 技術的負債とエンジニア 12

技術的負債とは何か？ 技術的負債（英語: technical debt）、または設計負債[1]、コード負債とは、ソフトウェア開発における概念であり、時間がかかるより良い アプローチを使用する代わりに、今すぐ簡単な（限定的な）解決策を選択することで生じる追加の手直しの暗黙のコストを反映したものであ る[2]。 金銭的な負債と同様[3]に、技術的負債も返済されなければ、「利子」が蓄積され、変更の実施が困難になる。技術的負債を処理しないと、ソ フトウェアのエントロピーが増大する。金銭的負債と同様に、技術的負債も必ずしも悪いものではなく、プロジェクトを前進させるために （概念実証として）必要な場合もある。一方で、「技術的負債」というメタファーは、その影響を最小限に抑える傾向があり、その結果、修 正するために必要な作業の優先順位付けが不十分になると主張する専門家もいる[4][5]。 コードベース上で変更が開始されると、コードベースの他の部分やドキュメントにも、他の調整された変更が必要になることがよくある。完 了していない必要な変更は負債とみなされ、支払われるまでは利息が上乗せされて発生するため、プロジェクトの構築が煩雑になる。この言 葉は主にソフトウェア開発で使われるが、他の職業にも適用できる。 引用元: 技術的負債 - Wikipedia 13

14

[大前提] エンジニア、個として目指したいこと 質とスピードを両立させて、開発 質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き） / Quality and Speed AWS Dev Day 2023 Tokyo Edition - Speaker Deck 未来の技術動向の変化やビジネス要求を見極めて、技術選定 技術選定の審美眼（2023年版） / Understanding the Spiral of Technologies 2023 edition - Speaker Deck 15

目指し続けたい、最強で無敵のエンジニア 16

4. 急成長期のスタートアップにおける挑戦 本日の発表内容はスタートアップの技術経営者目線での話です。 新規事業としてプロダクトを立ち上げる場合 立ち上げ期、価値検証期では、技術的負債を積みがち 成長期 この事業がいけると検証できたら、成長に向けてアクセルを踏みたい 技術的負債が積み上がっていると、アクセルを踏めない 戦略的に技術的負債を管理したい 既存事業に対してプロダクトを立ち上げる場合 プロダクトの寿命が長くなりそうなら、最初から技術的負債を減らしたい 17

スタートアップのフェーズが進むことで発生すること 人が増える、チームが増える、色んなコードが増える 1人が書くコードの割合が相対的に減る 18

5. 頭の中ほとんどトレードオフ・スライダー 短期的成功と中長期的健全性のバランス 創業初期：事業やプロダクトを軌道に乗せるぞ！ 創業中期：継続的に成長させていくぞ！ 創業後期：（未知の領域） トレードオフの判断基準 判断基準は事業、プロダクト、チームなどの状況によって変わる 判断を間違えると何かを失う可能性がある 技術的負債を返済すること無く、事業終了、サービスシャットダウン 技術的負債により開発効率が下がり、エンジニアが辞めていく 19

20

6. 技術的負債の管理戦略 管理戦略 理想：同じプロダクトバックログとチームで扱う 基本戦略：隙あらば返す 効果的な返済戦略 短期で借りる場合 借りたら、次のイテレーションで返す 中長期で借りる or 気付いたら負債があった場合 借りる前にPros/Consを出して、チームと合意形成を得る 返済計画を立てて、チームと事業責任者や経営陣と合意形成を得る 21

7. 技術的負債とトレードオフ・スライダーの事例紹介 22

事例A: 機能開発 or 技術的負債の返済 機能開発を優先したいケース 事業成長や市場での競争力に直接影響を与える 顧客のニーズや市場の動向に応じて、新機能の開発が急務である 技術的負債の返済を優先したいケース プロダクト開発の進行や将来の拡張性を妨げる プロダクトの安定性やパフォーマンスに深刻な影響を及ぼしている 23

わたしの頭の中 前提: 事業の成功 ≒ 顧客への価値提供ができていること 新規事業: 機能開発を優先 既存事業: 事業成長の進捗状況を見ながら、技術的負債を返済することを優先 背景: プロダクトの中長期的な開発・利用が予想できているため 期限を最優先する場合に意識したいこと リリース時点での機能・非機能に加えて、技術的負債のお品書きも作成 目的: エンジニア以外とも技術的負債を負う合意形成を得る チームが変化する場合に考えていること 継続的にチームに人が増える場合 技術的負債を返済することで、チームの知識共有を促進する 認知負荷は人の数だけ線形的にコストとなるので、早めに返済したい 24

事例B: 積極的な技術選定 or 消極的な技術選定 創業初期に消極的な技術選定をしたことがありました。 すでにチームメンバー（主に自分）が習熟している言語を用いる Node.js + Vue.jsの経験が長かったので、NestJS + Nuxt.jsを採用 学習コストが少なくて済むように、フロントエンドとサーバーサイドで同じ言語を用い る TypeScriptを採用 開発メンバーのレベル感に配慮し、学習コストが小さい言語を選定する TypeScriptなら、あとから入ってきたエンジニアも書ける可能性が高そう 参考: 積極的な技術選定と消極的な技術選定 - uhyo/blog 25

事例C: ドキュメントを書く or 書かない ドキュメントを書く チーム内での共通認識を得やすい あとから入社する人がわかる ドキュメントを書かない あえて属人性を許容して、開発スピードを上げて、リリースを早める あとで書く -> 書かない -> 忘れた頃に質問が来る -> やっと書く 社内事例 創業1-2年目は属人性を許容して、ドキュメントは最低限 3年目からドキュメント文化が醸成されて、現在はドキュメント文化が根付いてい る 参考: チームにおける ADR 導入から 1 年経った振り返りと感想 - ROUTE06 Tech Blog 26

事例D: Monorepo or Polyrepo Monorepo（モノレポ） コードを共有できる 全体の状況を把握しやすい Polyrepo（ポリレポ） 各repositoryで管理すれば良い（Monorepo管理ツールが不要） 関心の分離 社内事例 エンジニア数名のフェーズでPolyrepo管理したことがあった 7 repositoriesを行き来していてオーバーヘッドが勿体なかった 現在、Monorepoを採用することが多い 参考: Plainのフロントエンドにおける技術選定(2023年8月版) - ROUTE06 Tech Blog 27

事例E: プロダクト毎に技術選定 or 技術選定の統一 プロダクト毎に技術を選定すると、エンジニアのスキルセットが多様化する 常に一番良い技術選定ができる チーム異動で技術のキャッチアップから必要になる 全社で技術選定を統一すると、エンジニアのスキルセットが統一される 最適な言語や技術選定をする機会が減る 技術選定に失敗したときに影響範囲が大きい 社内事例 プロダクト毎にチームに技術選定を任せている 28

[付録] ROUTE06の技術スタック Go, Kotlin for server-side, Python, Ruby, Swift, TypeScript NestJS, Spring Boot, Ruby on Rails Next.js, Nuxt.js, Vite MySQL, PostgreSQL 29

8. まとめ ・スタートアップは成長状況に応じて ”技術的負債” を取り、返済しよう ・理想と現実の ”トレードオフ” を考え、チームで合意形成して取り組もう ・個としては理想を追求し続けて、 ”最強で無敵のエンジニア” を目指そう 30

9. 質疑応答 31

参考情報 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wada のブログ Why Understanding and Reducing Technical Debt Matters - Orange Matter Trade-off sliders - Agile Experience Design: A Digital Designer’s Guide to Agile, Lean, and Continuous [Book] O'Reilly Japan - レガシーコードからの脱却 Clean Architecture 達人に学ぶソフトウェアの構造と設計【委託】 - 達人出版会 アジャイルサムライ―― 達人開発者への道 | コンピュータ・一般書,プログラミング・開 発,開発技法 | Ohmsha LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する - インプレスブックス Monorepo開発のメリット vs デメリット | CircleCI 32

参考情報 全社ワークスペースに GitHubを選んだ ROUTE06の開発生産性 / Development productivity of ROUTE06 - Speaker Deck ROUTE06 CTOが考えていること（2023年9月） - ROUTE06 Tech Blog チームにおける ADR 導入から 1 年経った振り返りと感想 - ROUTE06 Tech Blog Plainのフロントエンドにおける技術選定(2023年8月版) - ROUTE06 Tech Blog ドキュメント文化を支える不文律 - ROUTE06 Tech Blog 33