Tweet
Tweet

Slide 1

Slide 1 text

技術的負債を抱えながら それでも生きていく (LT版) 技術的負債とどう向き合ってる？ みんなで学ぶLunch LT shinden tomohiro https://findy.connpass.com/event/297713/ #技術的負債_findy / @t_shinden

Slide 2

Slide 2 text

スタートアップ x 技術的負債 という テーマ AWS Startup Day 2023で発表した内容を再編集したものです。 https://speakerdeck.com/shinden/living-with-technical-debt

Slide 3

Slide 3 text

タイトルで気付いていると思いますが ロジカルではなくエモな話です

Slide 4

Slide 4 text

index 1.自己紹介 2.スタートアップとは 3.技術的負債とは 4.スタートアップで起こる変化 5.技術的負債と向き合うために必要なこと 6.まとめ

Slide 5

Slide 5 text

自己紹介

Slide 6

Slide 6 text

自己紹介 名前：新田智啓 (Shinden Tomohiro) 　　　ふりがなが無いと99%読み間違えられます 経歴：SI系とWeb系の両方で開発を経験 　　　新規システムの開発、新規事業の開発も数回経験　 　　 2001年〜 SIer数社 ・エンジニア、テックリード、エンジニアチームマネージャなど 2014年〜 サイバーエージェント ・アドテクスタジオ、エンジニア、開発責任者、技術責任者、子会社CTOなど 2018年〜 メルペイ ・バックエンドエンジニアリングマネージャ、テクニカルプログラムマネージャ 2020年〜 現在 株式会社カケハシ シリーズCのスタートアップ https://www.kakehashi.life/ ・新規プロダクト開発(AI在庫管理チーム) の 開発ディレクター(スクラムマスター)として入社 ・2022年9月 からはエンジニアリングマネージャーとして活動 ・働き始めて３年経ちますが、 オフィスへの出社回数は10回以下のフルリモート環境

Slide 7

Slide 7 text

SI系会社時代 (主にSESでの業務) 自己紹介 - 新規事業経験 新規構築システム ・保険共済 ・交通網ICカード在庫管理 ・工場部品管理 ・ソーシャルゲームアプリ ・など 役割 エンジニア・テックリード 新規サービス立ち上げ ・ゲーム広告配信システム開発 ・動画広告配信システム開発 ・広告 DMP 開発 ・リアルタイム情報広告配信 ・など 役割 エンジニア・開発責任者・ 技術責任者・子会社 CTO いま考えると、自分は事業を作っておらず 新規システムを作っていた Web系会社時代 新規事業立ち上げ ・薬局在庫管理システム → 順調にサービスは成長中 　入社時の立ち上げ 5人チームから 現 在は40人規模の開発組織へ 現在シリーズC (調達額94億円) 役割 開発ディレクターのちに エンジニアリングマネージャ スタートアップ会社時代 ● プロダクトの成長経験とスタートアップのお金の動きや事業として必要な範囲の広さ は現在の会社で経験して理解した事が多い ● 過去には立ち上げたサービスの クローズの経験を何度も味わいました。。

Slide 8

Slide 8 text

スタートアップとは ・自己紹介

Slide 9

Slide 9 text

スタートアップとは？ (利益の推移) スタートアップの利益のグラフはJカーブやホッケースティックカーブと言われる

Slide 10

Slide 10 text

スタートアップの利益は最初は少なく 出資を受けた現金を使い果たす前に 利益を出す必要があります！ 創業して数年は赤字が拡大する 死の谷 (Valley of Death) を経験し、 利益を反転できない場合は 会社がなくなります スタートアップとは？ (死の谷) 死の谷 (Valley of Death)

Slide 11

Slide 11 text

スタートアップとは (まとめ) スタートアップは命の炎に限界がある 常に会社の存続と隣り合わせで考慮する必要がある とはいえ、技術的負債は放置して良いものでは無い 良い開発環境の効果は複利でメリットを得られるので、中長期目線であれば絶対やるべき スタートアップの中での技術的負債を考えていく

Slide 12

Slide 12 text

技術的負債とは ・自己紹介 ・スタートアップとは

Slide 13

Slide 13 text

ウォード・カニンガムが作り出したメタファー 「技術的負債」という言葉を誤認している世間の様子を知って、ウォード・カニンガムの 言っていたことをまとめると コードを書くときにはベストを尽くせ！ コードを雑に書くのは技術的負債ではない (ただの怠慢) リファクタリングするときの未来を考える事が重要 技術的負債とは

Slide 14

Slide 14 text

技術的負債の語る上で重要な品質 https://www.ipa.go.jp/publish/qv6pgp0000000wkj-att/000055008.pdf IPAの「つながる世界のソフトウェア品質ガイド」より 品質を高めるって どの品質？

Slide 15

Slide 15 text

内部品質とは https://www.ipa.go.jp/publish/qv6pgp0000000wkj-att/000055008.pdf 技術的負債に 深い関連のある品質 見えない部分の品質と呼ばれ るものを理解する必要がある ● 品質について外部品質と 内部品質などの見える面 と見えない面 ● 表に見えている機能要件 と障害になったときしか見 えない非機能要件

Slide 16

Slide 16 text

技術的負債と定義できる瞬間とは コードの複雑さは突然現れるのではなく、 塵が積もって山になるように徐々に現れる。 エンジニアがやりづらいと感じた瞬間、良い新しいアイデアがあるとき 現状の課題を技術的負債として認知される。 現在のシステムで満足できないところが技術的負債 つまり 欲しい開発者体験 (DX)との差分

Slide 17

Slide 17 text

開発者体験 (DX：Developer eXperience)とは 開発者体験とは、開発者が高速な仮説検証を行うための企業における環境や 習慣、文化のことを指します。 (CTO協会 DX Criteriaビジョン https://dxcriteria.cto-a.org/660d6573b45645bcb431c7c29c5431f8 ) 開発者体験という言葉だけ聞くと、 開発者が働きやすいだけの環境のように聞こえますが、違います。 開発者が障害に感じるものを最小化し、エンジニアが価値を最速で実現できることで す。つまり、生産性の高い理想状態のことです。 生産性って？

Slide 18

Slide 18 text

生産性とは 生産性 = 生産物 ÷ 投入した資源 (Wikipedia) 生産性とはアウトプット量だけではなく、質も含んだ価値をどれほど高められるか。生 産性とは作るスピードではなく、価値貢献のスピードと考えています。 インプット アクティビティ アウトプット アウトカム インパクト (投入) (活動) (出力) (成果) (社会的変化) 計測Lv1 計測Lv2 計測Lv3 フェーズに合わせ生産物の計測 "価値"レベルを進める 例：開発機能数　　　　例：ユーザー利用数　　　例：利用者発信数や収益 ムーヴメントを起こすのを 目指すのがスタートアップ かもしれない インパクトチェーン

Slide 19

Slide 19 text

● エンジニア価値発揮のための "理想"環境 (DX) - 現状システムや環境 = 技術的負債 ● エンジニアの生産性を妨げ、追加の金利的な工数が掛かるもの ● システム内部の課題 (内部品質、非機能要件) ● 雑にコードを書いたものではなく、ベストを尽くしたもの ● コードの複雑さはある日突然現れるのではない ● 今回は負債解消によって価値が発揮されるものだけを負債と考える 技術的負債とは (まとめ)

Slide 20

Slide 20 text

スタートアップで起こる変化 ・自己紹介 ・スタートアップとは ・技術的負債とは

Slide 21

Slide 21 text

技術(システム) エンジニア目線での開発と成長サイクル 事業 組織 成長 作る 拡大

Slide 22

Slide 22 text

技術(システム) エンジニア目線での開発と成長サイクル 事業 稼働するシステム ◆技術的広さ◆ AWSなどインフラ フロントエンド バックエンド ◆技術的深さ◆ アーキテクチャ フレームワーク活用 プログラミング言語 組織 システムを 開発するための プロセス 成長 作る 拡大 文化 注目しがち エンジニア以外の 要望で作ることが 多い システムを 維持するための 仕組み CI/CD IaC 自動回帰テスト DB Migration Lint システムを 維持するための ルール 見えないけど 実は大事 エンジニア自身でしか 改善できない

Slide 23

Slide 23 text

周辺の変化によって技術的負債の価値が変わる 技術的負債が解消されると価値が発揮されるもの。 つまり全く変更が必要のないレガシーコードは負債ではない。 だが、変更が必要になった瞬間負債になる。 本来は元々あった負債だが、事業の変化によって優先順が大きく変わる！

Slide 24

Slide 24 text

優先順が変わりやすい理由 スタートアップは基本的にいつでも変わるという前提はあるが 分かりやすく大きく価値観が変わるタイミングがある

Slide 25

Slide 25 text

プロダクトを作るときの事業フェーズ 最小限実装 フェーズ Minimum Viable Product 機能試行錯誤 フェーズ Product Market Fit スケール可能実装 フェーズ Go To Market スケール フェーズ Growth MVP PMF GTM Growth なるべくシステムを 作らずに価値を検 証する 価値をプロダクトで 実現する方法を最 小コストで探る スケールするため のシステム状態に する 価値を拡張する 様々な機能を追加 する システム 視点での 解釈 意味 通称

Slide 26

Slide 26 text

事業フェーズによって変わるシステムに向かう価値観 最小限のコストで の実現方法 価値の探索のため のアイデア検証 組織としての安定 を目指す 成長のための開発 ラインの複線化 システム安定よりも 機能開発 売上の安定化 価値的スケーラビ リティの検証 機能開発がプロジェク トマネジメント的になる リアーキテクチャなど の大規模リファクタが 必要になる MVP PMF GTM Growth ↑↑ 実現アイデア ↓ 機能品質 ↓ バグの問題 ↑↑機能開発スピード ↑ バグへの品質 ↑ 組織化 ↓↓ 阿吽の呼吸 ↑↑バグへの品質 ↑↑高負荷状況 ↑ スケール向け機能 ↓↓ 探索的アイデア ↑ バグへの品質 ↑ 組織化 ↑ 模索的アイデア ↑↑ 安定開発 優先度や 関心度の 変化 フェーズで 達成 したいこと 通称 フェーズが変わると価値観が大きく変わる

Slide 27

Slide 27 text

技術的負債があるって？・・・、知ってたよ。 技術・組織・事業は一体となって開発をする必要があるが、 フェーズが変わり組織が急成長すると、 組織の問題が噴出する 新しい価値観で見た技術的負債が掘り起こされる 事業への価値停滞が発生する 知ってた。 技術的負債があるって分かってたが、違う優先順の価値観があった。

Slide 28

Slide 28 text

フェーズが変わると理想状態が変わり差分が大きくなる = 技術的負債の増大 技術的負債が増大する理由とスタートアップの変化 (まとめ) 技術的 負債 現状の システム 状態 事業として 必要な システム状態 理想の システムの 状態 技術的 負債 現状の システム 状態 事業として 必要な システム状態 理想の システムの 状態 期待の状態 現状 期待の状態 現状 状況や目標の 変化 機能開発予定 会計のB/S的イメージ 増加 増加 追加

Slide 29

Slide 29 text

技術的負債と向き合うために必要なこと ・自己紹介 ・スタートアップとは ・技術的負債とは ・スタートアップで起こる変化

Slide 30

Slide 30 text

スタートアップ x 技術的負債 事業として軌道に乗るまで ・人員を増やすことが難しい ・継続的な機能開発が求められる プロダクトがPMFを模索したり、ユーザーが増えることで品質問題が顕在化する ・優先すべきは機能リリース ・技術的負債の対応までは手が回らない ← ここを諦めずに向き合う

Slide 31

Slide 31 text

スタートアップ前提で負債への意識を考えてみる [無謀・意図的] ● 設計に割く時間がない → そうです。無いです。 [慎重・意図的] ● リリースを優先するが、結果にも対応する → そうです。やるしか無いです。 [無謀・無自覚] ● レイヤー化って何？ → そうです。良いエンジニアは揃っているわけではにし、雇うお金もありません。 [慎重・無自覚] ● 今だから分かる手段もあった → そうです。知らないことだらけのところで新しい価値を作るんです。 そうです！ スタートアップは無謀で慎重に意図的に分からないことに飛び込でいます！ 不確実性が高い中で新しい価値を模索している！ なので、満たされるまでは技術的負債が生まれます！ マーティンファウラーの提言した４象限

Slide 32

Slide 32 text

技術的負債が気になるのは次の課題に進んだから 誰かが悪い訳では無い 当時の状況の中で精一杯やった結果である むしろ事業を成長したからこそ次の課題にぶつかっているという証 過去のエンジニアの汗と血と涙に敬意を持ちながら、 今の課題として粛々と対応していくべきもの

Slide 33

Slide 33 text

技術的負債を憎まない 人を憎まず、技術負債も憎まず 感謝していこう

Slide 34

Slide 34 text

技術的負債はひとりひとりが向き合う事 技術的負債に向き合うには？ 誰かがやってくれるもの？ いいえ、エンジニア全員でやるもの

Slide 35

Slide 35 text

技術(システム) エンジニア目線での開発と成長サイクル 事業 稼働するシステム ◆技術的広さ◆ AWSなどインフラ フロントエンド バックエンド ◆技術的深さ◆ アーキテクチャ フレームワーク活用 プログラミング言語 組織 システムを 開発するための プロセス 成長 作る 拡大 文化 注目しがち エンジニア以外の 要望で作ることが 多い システムを 維持するための 仕組み CI/CD IaC 自動回帰テスト DB Migration Lint システムを 維持するための ルール 見えないけど 実は大事 エンジニア自身でしか 改善できない エンジニア自身でしか 改善できない

Slide 36

Slide 36 text

立ち上げの範囲 システム 立ち上げ プロダクト 立ち上げ 事業 立ち上げ ここだけ見れば 意思決定できることもあるが、

Slide 37

Slide 37 text

立ち上げの範囲 システム 立ち上げ プロダクト 立ち上げ 事業 立ち上げ スタートアップはここまで見ないと 意思決定できないことが多い

Slide 38

Slide 38 text

理想の定義って出来ています？ 技術的負債の方程式： 現状 → 理想 → ギャップ = 技術的負債 みんなの理想って合っている？ それぞれが自由に考えてバラバラなことも多い 理想の定義がチームで揃えないと、技術的負債の具体的な認識も揃わない Howの精査より価値の精査をして、技術的負債の認識を揃える必要がある 技術的負債の認識の違いによって、軋轢が生まれていることもあるのでは？

Slide 39

Slide 39 text

技術的負債はひとりひとりが向き合う事 ひとりひとりに全員が向き合う でも、ひとりで全部やる必要はない エンジニアじゃない人も含めてみんなでやるもの

Slide 40

Slide 40 text

技術だけでも向き合えないし、組織の視点も必要です 広い視点と技術の特性の深い視点を持ちバランスする必要がある 必要な広い視点 ● システム - プロダクト - 事業 ● 過去 - 現在 - 未来 ● 技術 - 組織 - 事業 必要な技術の特性の深い視点 ● エンジニアのマインドシェア ● エンジニアの無駄な認知負荷 ● エンジニアの理想状態の思い 必要な広さと深さとバランス 継続的な技術スキルの知識の 向上は前提としてしながら 今の全力を出すために！

Slide 41

Slide 41 text

まとめ ・自己紹介 ・スタートアップとは ・技術的負債とは ・スタートアップで起こる変化 ・技術的負債と向き合うために必要なこと

Slide 42

Slide 42 text

スタートアップ x 技術的負債 まとめ 技術的負債は雑にコードを書いたものではない ベストを尽くした上で発生したもの 少し未来を見ながらコードを書く スタートアップでは技術的負債は生まれやすい環境 ここまで価値を発揮した証。責める必要はない。「どう向き合うか」の理解が大事 向き合うためには 過去 - 現在 - 未来 の全てが大事 経緯に敬意を持ち、過去も理想(未来)も伝え合うことで技術負債が見える

Slide 43

Slide 43 text

最後に カケハシでは成長をリードしながら戦える エンジニアを募集しています！ 採用サイトはこちら https://recruit.kakehashi.life/

Slide 44

Slide 44 text

株式会社カケハシ イベント登壇やTechBlogの情報をお届けします！フォローお願いします！ https://twitter.com/kakehashiPR カケハシ主催のイベントなどの情報が届きます。メンバー登録お願いします！ https://kakehashi.connpass.com/ カケハシの説明資料や登壇資料などが登録されています。 https://speakerdeck.com/kakehashi

Slide 45

Slide 45 text

ご清聴ありがとうございました！

Slide 46

Slide 46 text

次回予告 技術的負債を抑えるために取り組むこと

Slide 47

Slide 47 text

技術的負債とは 前提 ● ゼロには出来ない ● 自然に増える 出来ること ● 発生のスピードを抑える ● 定期的に解消する

Slide 48

Slide 48 text

イベント プロジェクト 日常 技術的負債を どのように抑えるのか

Slide 49

Slide 49 text

テクニカルチームベースセット (を作りたいという妄想) 技術チームがベースライン取り組むべきプラクティスのセット ● チームでプラクティスの取捨選択や数値を変更する前提 ● スクラムやXPの補完的に使う ● 具体的かつ定量的な基準を持つ ● 短期的な価値ではなく、継続的な価値を重視する ● ビジネスメンバーとの会話に使うための数値も計測する

Slide 50

Slide 50 text

次回予告 技術的負債を抑えるために取り組むこと を考えてみたいと思います！