【LT版】技術的負債を抱えながら それでも生きていく / LT.ver Living with technical debt

Transcript

1. 技術的負債を抱えながら それでも生きていく (LT版) 技術的負債とどう向き合ってる？ みんなで学ぶLunch LT shinden tomohiro https://findy.connpass.com/event/297713/ #技術的負債_findy / @t_shinden
2. スタートアップ x 技術的負債 という テーマ AWS Startup Day 2023で発表した内容を再編集したものです。 https://speakerdeck.com/shinden/living-with-technical-debt
3. タイトルで気付いていると思いますが ロジカルではなくエモな話です
4. index 1.自己紹介 2.スタートアップとは 3.技術的負債とは 4.スタートアップで起こる変化 5.技術的負債と向き合うために必要なこと 6.まとめ
5. 自己紹介
6. 自己紹介 名前：新田智啓 (Shinden Tomohiro) 　　　ふりがなが無いと99%読み間違えられます 経歴：SI系とWeb系の両方で開発を経験 　　　新規システムの開発、新規事業の開発も数回経験　 　　 2001年〜 SIer数社 ・エンジニア、テックリード、エンジニアチームマネージャなど 2014年〜 サイバーエージェント ・アドテクスタジオ、エンジニア、開発責任者、技術責任者、子会社CTOなど 2018年〜 メルペイ ・バックエンドエンジニアリングマネージャ、テクニカルプログラムマネージャ 2020年〜 現在 株式会社カケハシ シリーズCのスタートアップ https://www.kakehashi.life/ ・新規プロダクト開発(AI在庫管理チーム) の 開発ディレクター(スクラムマスター)として入社 ・2022年9月 からはエンジニアリングマネージャーとして活動 ・働き始めて３年経ちますが、 オフィスへの出社回数は10回以下のフルリモート環境
7. SI系会社時代 (主にSESでの業務) 自己紹介 - 新規事業経験 新規構築システム ・保険共済 ・交通網ICカード在庫管理 ・工場部品管理 ・ソーシャルゲームアプリ ・など 役割 エンジニア・テックリード 新規サービス立ち上げ ・ゲーム広告配信システム開発 ・動画広告配信システム開発 ・広告 DMP 開発 ・リアルタイム情報広告配信 ・など 役割 エンジニア・開発責任者・ 技術責任者・子会社 CTO いま考えると、自分は事業を作っておらず 新規システムを作っていた Web系会社時代 新規事業立ち上げ ・薬局在庫管理システム → 順調にサービスは成長中 　入社時の立ち上げ 5人チームから 現 在は40人規模の開発組織へ 現在シリーズC (調達額94億円) 役割 開発ディレクターのちに エンジニアリングマネージャ スタートアップ会社時代 • プロダクトの成長経験とスタートアップのお金の動きや事業として必要な範囲の広さ は現在の会社で経験して理解した事が多い • 過去には立ち上げたサービスの クローズの経験を何度も味わいました。。
8. スタートアップとは ・自己紹介
9. スタートアップとは？ (利益の推移) スタートアップの利益のグラフはJカーブやホッケースティックカーブと言われる
10. スタートアップの利益は最初は少なく 出資を受けた現金を使い果たす前に 利益を出す必要があります！ 創業して数年は赤字が拡大する 死の谷 (Valley of Death) を経験し、 利益を反転できない場合は 会社がなくなります スタートアップとは？ (死の谷) 死の谷 (Valley of Death)
11. スタートアップとは (まとめ) スタートアップは命の炎に限界がある 常に会社の存続と隣り合わせで考慮する必要がある とはいえ、技術的負債は放置して良いものでは無い 良い開発環境の効果は複利でメリットを得られるので、中長期目線であれば絶対やるべき スタートアップの中での技術的負債を考えていく
12. 技術的負債とは ・自己紹介 ・スタートアップとは
13. ウォード・カニンガムが作り出したメタファー 「技術的負債」という言葉を誤認している世間の様子を知って、ウォード・カニンガムの 言っていたことをまとめると コードを書くときにはベストを尽くせ！ コードを雑に書くのは技術的負債ではない (ただの怠慢) リファクタリングするときの未来を考える事が重要 技術的負債とは
14. 技術的負債の語る上で重要な品質 https://www.ipa.go.jp/publish/qv6pgp0000000wkj-att/000055008.pdf IPAの「つながる世界のソフトウェア品質ガイド」より 品質を高めるって どの品質？
15. 内部品質とは https://www.ipa.go.jp/publish/qv6pgp0000000wkj-att/000055008.pdf 技術的負債に 深い関連のある品質 見えない部分の品質と呼ばれ るものを理解する必要がある • 品質について外部品質と 内部品質などの見える面 と見えない面 • 表に見えている機能要件 と障害になったときしか見 えない非機能要件
16. 技術的負債と定義できる瞬間とは コードの複雑さは突然現れるのではなく、 塵が積もって山になるように徐々に現れる。 エンジニアがやりづらいと感じた瞬間、良い新しいアイデアがあるとき 現状の課題を技術的負債として認知される。 現在のシステムで満足できないところが技術的負債 つまり 欲しい開発者体験 (DX)との差分
17. 開発者体験 (DX：Developer eXperience)とは 開発者体験とは、開発者が高速な仮説検証を行うための企業における環境や 習慣、文化のことを指します。 (CTO協会 DX Criteriaビジョン https://dxcriteria.cto-a.org/660d6573b45645bcb431c7c29c5431f8 ) 開発者体験という言葉だけ聞くと、 開発者が働きやすいだけの環境のように聞こえますが、違います。 開発者が障害に感じるものを最小化し、エンジニアが価値を最速で実現できることで す。つまり、生産性の高い理想状態のことです。 生産性って？
18. 生産性とは 生産性 = 生産物 ÷ 投入した資源 (Wikipedia) 生産性とはアウトプット量だけではなく、質も含んだ価値をどれほど高められるか。生 産性とは作るスピードではなく、価値貢献のスピードと考えています。 インプット アクティビティ アウトプット アウトカム インパクト (投入) (活動) (出力) (成果) (社会的変化) 計測Lv1 計測Lv2 計測Lv3 フェーズに合わせ生産物の計測 "価値"レベルを進める 例：開発機能数　　　　例：ユーザー利用数　　　例：利用者発信数や収益 ムーヴメントを起こすのを 目指すのがスタートアップ かもしれない インパクトチェーン
19. • エンジニア価値発揮のための "理想"環境 (DX) - 現状システムや環境 = 技術的負債 • エンジニアの生産性を妨げ、追加の金利的な工数が掛かるもの • システム内部の課題 (内部品質、非機能要件) • 雑にコードを書いたものではなく、ベストを尽くしたもの • コードの複雑さはある日突然現れるのではない • 今回は負債解消によって価値が発揮されるものだけを負債と考える 技術的負債とは (まとめ)
20. スタートアップで起こる変化 ・自己紹介 ・スタートアップとは ・技術的負債とは
21. 技術(システム) エンジニア目線での開発と成長サイクル 事業 組織 成長 作る 拡大
22. 技術(システム) エンジニア目線での開発と成長サイクル 事業 稼働するシステム ◆技術的広さ◆ AWSなどインフラ フロントエンド バックエンド ◆技術的深さ◆ アーキテクチャ フレームワーク活用 プログラミング言語 組織 システムを 開発するための プロセス 成長 作る 拡大 文化 注目しがち エンジニア以外の 要望で作ることが 多い システムを 維持するための 仕組み CI/CD IaC 自動回帰テスト DB Migration Lint システムを 維持するための ルール 見えないけど 実は大事 エンジニア自身でしか 改善できない
23. 周辺の変化によって技術的負債の価値が変わる 技術的負債が解消されると価値が発揮されるもの。 つまり全く変更が必要のないレガシーコードは負債ではない。 だが、変更が必要になった瞬間負債になる。 本来は元々あった負債だが、事業の変化によって優先順が大きく変わる！
24. 優先順が変わりやすい理由 スタートアップは基本的にいつでも変わるという前提はあるが 分かりやすく大きく価値観が変わるタイミングがある
25. プロダクトを作るときの事業フェーズ 最小限実装 フェーズ Minimum Viable Product 機能試行錯誤 フェーズ Product Market Fit スケール可能実装 フェーズ Go To Market スケール フェーズ Growth MVP PMF GTM Growth なるべくシステムを 作らずに価値を検 証する 価値をプロダクトで 実現する方法を最 小コストで探る スケールするため のシステム状態に する 価値を拡張する 様々な機能を追加 する システム 視点での 解釈 意味 通称
26. 事業フェーズによって変わるシステムに向かう価値観 最小限のコストで の実現方法 価値の探索のため のアイデア検証 組織としての安定 を目指す 成長のための開発 ラインの複線化 システム安定よりも 機能開発 売上の安定化 価値的スケーラビ リティの検証 機能開発がプロジェク トマネジメント的になる リアーキテクチャなど の大規模リファクタが 必要になる MVP PMF GTM Growth ↑↑ 実現アイデア ↓ 機能品質 ↓ バグの問題 ↑↑機能開発スピード ↑ バグへの品質 ↑ 組織化 ↓↓ 阿吽の呼吸 ↑↑バグへの品質 ↑↑高負荷状況 ↑ スケール向け機能 ↓↓ 探索的アイデア ↑ バグへの品質 ↑ 組織化 ↑ 模索的アイデア ↑↑ 安定開発 優先度や 関心度の 変化 フェーズで 達成 したいこと 通称 フェーズが変わると価値観が大きく変わる
27. 技術的負債があるって？・・・、知ってたよ。 技術・組織・事業は一体となって開発をする必要があるが、 フェーズが変わり組織が急成長すると、 組織の問題が噴出する 新しい価値観で見た技術的負債が掘り起こされる 事業への価値停滞が発生する 知ってた。 技術的負債があるって分かってたが、違う優先順の価値観があった。
28. フェーズが変わると理想状態が変わり差分が大きくなる = 技術的負債の増大 技術的負債が増大する理由とスタートアップの変化 (まとめ) 技術的 負債 現状の システム 状態 事業として 必要な システム状態 理想の システムの 状態 技術的 負債 現状の システム 状態 事業として 必要な システム状態 理想の システムの 状態 期待の状態 現状 期待の状態 現状 状況や目標の 変化 機能開発予定 会計のB/S的イメージ 増加 増加 追加
29. 技術的負債と向き合うために必要なこと ・自己紹介 ・スタートアップとは ・技術的負債とは ・スタートアップで起こる変化
30. スタートアップ x 技術的負債 事業として軌道に乗るまで ・人員を増やすことが難しい ・継続的な機能開発が求められる プロダクトがPMFを模索したり、ユーザーが増えることで品質問題が顕在化する ・優先すべきは機能リリース ・技術的負債の対応までは手が回らない ← ここを諦めずに向き合う
31. スタートアップ前提で負債への意識を考えてみる [無謀・意図的] • 設計に割く時間がない → そうです。無いです。 [慎重・意図的] • リリースを優先するが、結果にも対応する → そうです。やるしか無いです。 [無謀・無自覚] • レイヤー化って何？ → そうです。良いエンジニアは揃っているわけではにし、雇うお金もありません。 [慎重・無自覚] • 今だから分かる手段もあった → そうです。知らないことだらけのところで新しい価値を作るんです。 そうです！ スタートアップは無謀で慎重に意図的に分からないことに飛び込でいます！ 不確実性が高い中で新しい価値を模索している！ なので、満たされるまでは技術的負債が生まれます！ マーティンファウラーの提言した４象限
32. 技術的負債が気になるのは次の課題に進んだから 誰かが悪い訳では無い 当時の状況の中で精一杯やった結果である むしろ事業を成長したからこそ次の課題にぶつかっているという証 過去のエンジニアの汗と血と涙に敬意を持ちながら、 今の課題として粛々と対応していくべきもの
33. 技術的負債を憎まない 人を憎まず、技術負債も憎まず 感謝していこう
34. 技術的負債はひとりひとりが向き合う事 技術的負債に向き合うには？ 誰かがやってくれるもの？ いいえ、エンジニア全員でやるもの
35. 技術(システム) エンジニア目線での開発と成長サイクル 事業 稼働するシステム ◆技術的広さ◆ AWSなどインフラ フロントエンド バックエンド ◆技術的深さ◆ アーキテクチャ フレームワーク活用 プログラミング言語 組織 システムを 開発するための プロセス 成長 作る 拡大 文化 注目しがち エンジニア以外の 要望で作ることが 多い システムを 維持するための 仕組み CI/CD IaC 自動回帰テスト DB Migration Lint システムを 維持するための ルール 見えないけど 実は大事 エンジニア自身でしか 改善できない エンジニア自身でしか 改善できない
36. 立ち上げの範囲 システム 立ち上げ プロダクト 立ち上げ 事業 立ち上げ ここだけ見れば 意思決定できることもあるが、
37. 立ち上げの範囲 システム 立ち上げ プロダクト 立ち上げ 事業 立ち上げ スタートアップはここまで見ないと 意思決定できないことが多い
38. 理想の定義って出来ています？ 技術的負債の方程式： 現状 → 理想 → ギャップ = 技術的負債 みんなの理想って合っている？ それぞれが自由に考えてバラバラなことも多い 理想の定義がチームで揃えないと、技術的負債の具体的な認識も揃わない Howの精査より価値の精査をして、技術的負債の認識を揃える必要がある 技術的負債の認識の違いによって、軋轢が生まれていることもあるのでは？
39. 技術的負債はひとりひとりが向き合う事 ひとりひとりに全員が向き合う でも、ひとりで全部やる必要はない エンジニアじゃない人も含めてみんなでやるもの
40. 技術だけでも向き合えないし、組織の視点も必要です 広い視点と技術の特性の深い視点を持ちバランスする必要がある 必要な広い視点 • システム - プロダクト - 事業 • 過去 - 現在 - 未来 • 技術 - 組織 - 事業 必要な技術の特性の深い視点 • エンジニアのマインドシェア • エンジニアの無駄な認知負荷 • エンジニアの理想状態の思い 必要な広さと深さとバランス 継続的な技術スキルの知識の 向上は前提としてしながら 今の全力を出すために！
41. まとめ ・自己紹介 ・スタートアップとは ・技術的負債とは ・スタートアップで起こる変化 ・技術的負債と向き合うために必要なこと
42. スタートアップ x 技術的負債 まとめ 技術的負債は雑にコードを書いたものではない ベストを尽くした上で発生したもの 少し未来を見ながらコードを書く スタートアップでは技術的負債は生まれやすい環境 ここまで価値を発揮した証。責める必要はない。「どう向き合うか」の理解が大事 向き合うためには 過去 - 現在 - 未来 の全てが大事 経緯に敬意を持ち、過去も理想(未来)も伝え合うことで技術負債が見える
43. 最後に カケハシでは成長をリードしながら戦える エンジニアを募集しています！ 採用サイトはこちら https://recruit.kakehashi.life/
44. 株式会社カケハシ イベント登壇やTechBlogの情報をお届けします！フォローお願いします！ https://twitter.com/kakehashiPR カケハシ主催のイベントなどの情報が届きます。メンバー登録お願いします！ https://kakehashi.connpass.com/ カケハシの説明資料や登壇資料などが登録されています。 https://speakerdeck.com/kakehashi
45. ご清聴ありがとうございました！
46. 次回予告 技術的負債を抑えるために取り組むこと
47. 技術的負債とは 前提 • ゼロには出来ない • 自然に増える 出来ること • 発生のスピードを抑える • 定期的に解消する
48. イベント プロジェクト 日常 技術的負債を どのように抑えるのか
49. テクニカルチームベースセット (を作りたいという妄想) 技術チームがベースライン取り組むべきプラクティスのセット • チームでプラクティスの取捨選択や数値を変更する前提 • スクラムやXPの補完的に使う • 具体的かつ定量的な基準を持つ • 短期的な価値ではなく、継続的な価値を重視する • ビジネスメンバーとの会話に使うための数値も計測する
50. 次回予告 技術的負債を抑えるために取り組むこと を考えてみたいと思います！