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

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

shinden
October 13, 2023

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

shinden

October 13, 2023
Tweet

More Decks by shinden

Other Decks in Technology

Transcript

  1. 自己紹介 名前:新田智啓 (Shinden Tomohiro)    ふりがなが無いと99%読み間違えられます 経歴:SI系とWeb系の両方で開発を経験    新規システムの開発、新規事業の開発も数回経験     2001年〜 SIer数社

    ・エンジニア、テックリード、エンジニアチームマネージャなど 2014年〜 サイバーエージェント ・アドテクスタジオ、エンジニア、開発責任者、技術責任者、子会社CTOなど 2018年〜 メルペイ ・バックエンドエンジニアリングマネージャ、テクニカルプログラムマネージャ 2020年〜 現在 株式会社カケハシ シリーズCのスタートアップ https://www.kakehashi.life/ ・新規プロダクト開発(AI在庫管理チーム) の 開発ディレクター(スクラムマスター)として入社 ・2022年9月 からはエンジニアリングマネージャーとして活動 ・働き始めて3年経ちますが、 オフィスへの出社回数は10回以下のフルリモート環境
  2. SI系会社時代 (主にSESでの業務) 自己紹介 - 新規事業経験 新規構築システム ・保険共済 ・交通網ICカード在庫管理 ・工場部品管理 ・ソーシャルゲームアプリ

    ・など 役割 エンジニア・テックリード 新規サービス立ち上げ ・ゲーム広告配信システム開発 ・動画広告配信システム開発 ・広告 DMP 開発 ・リアルタイム情報広告配信 ・など 役割 エンジニア・開発責任者・ 技術責任者・子会社 CTO いま考えると、自分は事業を作っておらず 新規システムを作っていた Web系会社時代 新規事業立ち上げ ・薬局在庫管理システム → 順調にサービスは成長中  入社時の立ち上げ 5人チームから 現 在は40人規模の開発組織へ 現在シリーズC (調達額94億円) 役割 開発ディレクターのちに エンジニアリングマネージャ スタートアップ会社時代 • プロダクトの成長経験とスタートアップのお金の動きや事業として必要な範囲の広さ は現在の会社で経験して理解した事が多い • 過去には立ち上げたサービスの クローズの経験を何度も味わいました。。
  3. 開発者体験 (DX:Developer eXperience)とは 開発者体験とは、開発者が高速な仮説検証を行うための企業における環境や 習慣、文化のことを指します。 (CTO協会 DX Criteriaビジョン https://dxcriteria.cto-a.org/660d6573b45645bcb431c7c29c5431f8 )

    開発者体験という言葉だけ聞くと、 開発者が働きやすいだけの環境のように聞こえますが、違います。 開発者が障害に感じるものを最小化し、エンジニアが価値を最速で実現できることで す。つまり、生産性の高い理想状態のことです。 生産性って?
  4. 生産性とは 生産性 = 生産物 ÷ 投入した資源 (Wikipedia) 生産性とはアウトプット量だけではなく、質も含んだ価値をどれほど高められるか。生 産性とは作るスピードではなく、価値貢献のスピードと考えています。 インプット

    アクティビティ アウトプット アウトカム インパクト (投入) (活動) (出力) (成果) (社会的変化) 計測Lv1 計測Lv2 計測Lv3 フェーズに合わせ生産物の計測 "価値"レベルを進める 例:開発機能数    例:ユーザー利用数   例:利用者発信数や収益 ムーヴメントを起こすのを 目指すのがスタートアップ かもしれない インパクトチェーン
  5. • エンジニア価値発揮のための "理想"環境 (DX) - 現状システムや環境 = 技術的負債 • エンジニアの生産性を妨げ、追加の金利的な工数が掛かるもの

    • システム内部の課題 (内部品質、非機能要件) • 雑にコードを書いたものではなく、ベストを尽くしたもの • コードの複雑さはある日突然現れるのではない • 今回は負債解消によって価値が発揮されるものだけを負債と考える 技術的負債とは (まとめ)
  6. 技術(システム) エンジニア目線での開発と成長サイクル 事業 稼働するシステム ◆技術的広さ◆ AWSなどインフラ フロントエンド バックエンド ◆技術的深さ◆ アーキテクチャ

    フレームワーク活用 プログラミング言語 組織 システムを 開発するための プロセス 成長 作る 拡大 文化 注目しがち エンジニア以外の 要望で作ることが 多い システムを 維持するための 仕組み CI/CD IaC 自動回帰テスト DB Migration Lint システムを 維持するための ルール 見えないけど 実は大事 エンジニア自身でしか 改善できない
  7. プロダクトを作るときの事業フェーズ 最小限実装 フェーズ Minimum Viable Product 機能試行錯誤 フェーズ Product Market

    Fit スケール可能実装 フェーズ Go To Market スケール フェーズ Growth MVP PMF GTM Growth なるべくシステムを 作らずに価値を検 証する 価値をプロダクトで 実現する方法を最 小コストで探る スケールするため のシステム状態に する 価値を拡張する 様々な機能を追加 する システム 視点での 解釈 意味 通称
  8. 事業フェーズによって変わるシステムに向かう価値観 最小限のコストで の実現方法 価値の探索のため のアイデア検証 組織としての安定 を目指す 成長のための開発 ラインの複線化 システム安定よりも

    機能開発 売上の安定化 価値的スケーラビ リティの検証 機能開発がプロジェク トマネジメント的になる リアーキテクチャなど の大規模リファクタが 必要になる MVP PMF GTM Growth ↑↑ 実現アイデア ↓ 機能品質 ↓ バグの問題 ↑↑機能開発スピード ↑ バグへの品質 ↑ 組織化 ↓↓ 阿吽の呼吸 ↑↑バグへの品質 ↑↑高負荷状況 ↑ スケール向け機能 ↓↓ 探索的アイデア ↑ バグへの品質 ↑ 組織化 ↑ 模索的アイデア ↑↑ 安定開発 優先度や 関心度の 変化 フェーズで 達成 したいこと 通称 フェーズが変わると価値観が大きく変わる
  9. フェーズが変わると理想状態が変わり差分が大きくなる = 技術的負債の増大 技術的負債が増大する理由とスタートアップの変化 (まとめ) 技術的 負債 現状の システム 状態

    事業として 必要な システム状態 理想の システムの 状態 技術的 負債 現状の システム 状態 事業として 必要な システム状態 理想の システムの 状態 期待の状態 現状 期待の状態 現状 状況や目標の 変化 機能開発予定 会計のB/S的イメージ 増加 増加 追加
  10. スタートアップ前提で負債への意識を考えてみる [無謀・意図的] • 設計に割く時間がない → そうです。無いです。 [慎重・意図的] • リリースを優先するが、結果にも対応する →

    そうです。やるしか無いです。 [無謀・無自覚] • レイヤー化って何? → そうです。良いエンジニアは揃っているわけではにし、雇うお金もありません。 [慎重・無自覚] • 今だから分かる手段もあった → そうです。知らないことだらけのところで新しい価値を作るんです。 そうです! スタートアップは無謀で慎重に意図的に分からないことに飛び込でいます! 不確実性が高い中で新しい価値を模索している! なので、満たされるまでは技術的負債が生まれます! マーティンファウラーの提言した4象限
  11. 技術(システム) エンジニア目線での開発と成長サイクル 事業 稼働するシステム ◆技術的広さ◆ AWSなどインフラ フロントエンド バックエンド ◆技術的深さ◆ アーキテクチャ

    フレームワーク活用 プログラミング言語 組織 システムを 開発するための プロセス 成長 作る 拡大 文化 注目しがち エンジニア以外の 要望で作ることが 多い システムを 維持するための 仕組み CI/CD IaC 自動回帰テスト DB Migration Lint システムを 維持するための ルール 見えないけど 実は大事 エンジニア自身でしか 改善できない エンジニア自身でしか 改善できない
  12. 理想の定義って出来ています? 技術的負債の方程式: 現状 → 理想 → ギャップ = 技術的負債 みんなの理想って合っている?

    それぞれが自由に考えてバラバラなことも多い 理想の定義がチームで揃えないと、技術的負債の具体的な認識も揃わない Howの精査より価値の精査をして、技術的負債の認識を揃える必要がある 技術的負債の認識の違いによって、軋轢が生まれていることもあるのでは?
  13. 技術だけでも向き合えないし、組織の視点も必要です 広い視点と技術の特性の深い視点を持ちバランスする必要がある 必要な広い視点 • システム - プロダクト - 事業 •

    過去 - 現在 - 未来 • 技術 - 組織 - 事業 必要な技術の特性の深い視点 • エンジニアのマインドシェア • エンジニアの無駄な認知負荷 • エンジニアの理想状態の思い 必要な広さと深さとバランス 継続的な技術スキルの知識の 向上は前提としてしながら 今の全力を出すために!