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

【Startup Day 2023】技術的負債を抱えながら それでも生きていく / Livin...

shinden
September 02, 2023

【Startup Day 2023】技術的負債を抱えながら それでも生きていく / Living with technical debt

こちらで登壇したときの資料です。

主催 : AWS Startup Community

Startup Day 2023
https://aws-startup-community.connpass.com/event/289498/

技術的負債 x スタートアップ について経験から感じたことを踏まえて話します。 システムを開発する上で技術的負債の取り扱いは難しいですが、事業立ち上げの中での取り扱いは更に難しく感じます。スタートアップの文脈の中での技術的負債は、通常の開発よりも違った傾向を理解する必要があるのではないでしょうか。システムを立ち上げることと事業を立ち上げることの違い。金銭的や人的な余裕の違い。ほかにも様々な違いがありそう。
これらの違いを考察しながら、スタートアップという特殊環境で生まれる技術的負債の原因を考えてみます。

▶ 話さないこと
技術的負債の与える影響
技術的負債の良し悪し
技術的負債の発生の対策
技術的負債の解消の方法

▶ 話すこと
スタートアップという特殊環境で生まれる技術的負債の原因
スタートアップにとっての技術的負債は何かの考察

shinden

September 02, 2023
Tweet

More Decks by shinden

Other Decks in Technology

Transcript

  1. 今日話すこと・話さないこと 今日は話さないこと • 技術的負債の与える影響 • 技術的負債の良し悪し • 技術的負債の発生の対策 • 技術的負債の解消の方法

    • AWSの話・・・ 今日、話すこと • スタートアップにとっての技術的負債は何かの考察 • スタートアップという特殊環境で生まれる技術的負債の原因 • 技術的負債の向き合い方
  2. 自己紹介 名前:新田智啓 (Shinden Tomohiro)    ふりがなが無いと99%読み間違えられます 経歴:SI系とWeb系の両方で開発を経験    新規システムの開発、新規事業の開発も数回経験     2001年〜 SIer数社

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

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

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

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

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

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

    フレームワーク活用 プログラミング言語 組織 システムを 維持するための ルール システムを 開発するための プロセス 成長 作る 拡大 システムを 維持するための 仕組み CI/CD IaC 自動回帰テスト DB Migration Lint 変化が 大きい エンジニア 頑張る エンジニア頑 張る 文化 スピード が早い 対応に時間も パワーも掛かる 対応に時間も パワーも掛かる チームが拡大し ても 思ったより 早くならない ここにも負債が あるのでは?
  9. プロダクトを作るときの事業フェーズ 最小限実装 フェーズ Minimum Viable Product 機能試行錯誤 フェーズ Product Market

    Fit スケール可能実装 フェーズ Go To Market スケール フェーズ Growth MVP PMF GTM Growth なるべくシステムを 作らずに価値を検 証する 価値をプロダクトで 実現する方法を最 小コストで探る スケールするため のシステム状態に する 価値を拡張する 様々な機能を追加 する システム 視点での 解釈 意味 通称
  10. 事業が立ち上がるか戦っているとき ドラゴンと戦っています! • Q. 腕に大きな怪我をしている。どうする? ◦ 傷は抉れている ◦ 腕を動かすのも辛い ◦

    動かさなくても痛い • A. それどころじゃなく戦うしかない ◦ 小さな傷でも、大きな怪我でも、 今死なない限りは気にしている暇がない ◦ 命の危険の方が大きい
  11. 事業の立ち上がりが見えて、日常に戻れそうなとき 日常に移ったとき同じ怪我をしていたら? • Q. 腕に大きな怪我をしている。どうする? ◦ すぐには死なない ◦ 大変だけどまだ生活は出来る? •

    A. なんでこんなになるまで放っておいた?! ◦ 普通ではこんな怪我ありえない! ◦ 放ったまま生活している意味が分からない! ◦ 何が起こったんだ!?大丈夫か? ▶ 場面が違うと同じ状態 (ダメージ) でも全く違うように見える 同じ質問
  12. 事業フェーズによって変わるシステムに向かう価値観 最小限のコストで の実現方法 価値の探索のため のアイデア検証 組織としての安定 を目指す 成長のための開発 ラインの複線化 システム安定よりも

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

    事業として 必要な システム状態 理想の システムの 状態 技術的 負債 現状の システム 状態 事業として 必要な システム状態 理想の システムの 状態 期待の状態 現状 期待の状態 現状 状況や目標の 変化 機能開発予定 会計のB/S的イメージ 増加 増加 追加
  14. スタートアップ x 技術的負債 防げた技術負債はあったのか? 人も居ない、時間もない、お金もない • 制約的選択 (賢明な意思決定) ◦ トレードオフでの選択

    ◦ お金がないことが起因による時間のなさ • 学びの不足 (無謀な意思決定) ◦ 開発的知識の不足 ◦ 事業的(ドメイン)知識の不足
  15. スタートアップ前提で負債への意識を考えてみる [無謀・意図的] • 設計に割く時間がない → そうです。無いです。 [慎重・意図的] • リリースを優先するが、結果にも対応する →

    そうです。やるしか無いです。 [無謀・無自覚] • レイヤー化って何? → そうです。良いエンジニアは揃っているわけではにし、雇うお金もありません。 [慎重・無自覚] • 今だから分かる手段もあった → そうです。知らないことだらけのところで新しい価値を作るんです。 そうです! スタートアップは無謀で慎重に意図的に分からないことに飛び込でいます! 不確実性が高い中で新しい価値を模索している! なので、満たされるまでは技術的負債が生まれます! マーティンファウラーの提言した4象限
  16. 今の課題と未来を話す 技術的負債の経緯と敬意 は過去 未来を話すための "Disagree and Commit" 全てを伝えきれるわけではない。意見をすることで経緯を理解する "Disagree and

    Commit" とは amazonのリーダーシッププリンシパルの1つ 「意見に同意できない場合には、敬意をもって異議を唱えなければなりません。たとえそうすることが面倒で労力を要することであっ ても、例外はありません。安易に妥協して馴れ合うことはしません。しかし、いざ決定がなされたら、全面的にコミットして取り組みま す。」
  17. 理想の定義って出来ています? 技術的負債の方程式: 現状 → 理想 → ギャップ = 技術的負債 みんなの理想って合ってますか?

    それぞれが自由に思っていてバラバラなことも多い 理想の定義がチームで揃えないと、技術的負債の具体的な認識も揃わない Howの精査より価値の精査をして、技術的負債の認識を揃える必要がある 技術的負債の認識の違いによって、軋轢が生まれていることもあるのでは?
  18. 最速のための作業はルールを合わせて実行する 実行頻度 x 実行時間 と 開発時間 のトレードオフ マインドシェアも含めて計算考慮するべき 頻度が多いものは無条件で開発する (検討時間自体が無駄なことも多い)

    開発だけに集中することが難しいスタートアップのエンジニアにとって マインドシェアの影響は想像以上に大きい マインドシェアを取られる開発は解消に向けた開発をする
  19. 実働時間に加えてマインドシェアも気をつけるべき 10分の作業が10個あったら約1人分のコストを無駄にしているかも知れない 毎日するデプロイ作業時間 10分とした時に、エンジニアのマインドシェアは前後 10分掛かるとする。その 場合、 30分(前後の10分のマインドシェア + 実働時間10分)のコスト *

    月に20日 = 600分 = 10時間 => 毎回か掛かっている金利 年間で 120時間 = 15日分。1ヶ月弱無駄にしている。これは1日1回しかデプロイしないパターンなので、 1日数回デプロイするとそれ以上掛かる。新しい人が作業すると手順からキャッチアップが必要なので、そ れ以上の時間が掛かる。 10分の作業だから自動化しなくていいと思っていること無いですか? デプロイ以外にも本当だったら仕組み化できる 10分の作業ってないですか?
  20. 技術だけでも向き合えないし、組織の視点も必要で 広い視点と技術の特性の深い視点を持ちバランスする必要がある 必要な広い視点 • システム - プロダクト - 事業 •

    過去 - 現在 - 未来 • 技術 - 組織 - 事業 という関わる人 必要な技術の特性の深い視点 • エンジニアのマインドシェア • エンジニアの無駄な認知負荷 • エンジニアの理想状態の思い 必要な広さと深さとバランス 技術スキルの知識の 向上は前提として 今の全力を出すために
  21. 伝えること • スタートアップにとって技術的負債を抱えることは必然 ◦ 注意:ただし、雑なことと、判断して受け入れることは別 ◦ 安定性を犠牲にした負債は最速を奪う - 内部品質は重要 ◦

    技術的負債の許容は最速のためである - スタートアップは環境が違う。 ▪ ドラゴンと戦っている or 街の工場で働いている。 ◦ 技術的負債の原因は2つ。能力の不足、周辺環境の変化。 ◦ 技術的負債は状況とのズレが大きいが、スタートアップではむしろ無いものの方が多い。 ▪ 負債であってもあるだけまし、動くだけまし。 ◦ 能力の方の話はしない ▪ 技術的な理解を鍛えるだけ。 ◦ 負債には2つの環境変化の原因がある ▪ 事業的環境変化と開発的環境変化。 ◦ 問題は負債と呼ばれる課題だけでなく、そのズレによる影響度 => スタートアップは即死する • 事業的フェーズの区切りで突然技術的負債の解釈は変わるもの ◦ 価値観の変化は必然、システムの持つ優先度が変わる • システムと組織は一体である ◦ システムの状況解釈の違い、目線の変化、経緯が理解できないと、組織停滞や崩壊にも繋がる可能性がある。今やることの理解だけでなく、未来も知りつ つ、過去の理解も大事。 PMFあとに入った人はこの惨状にびっくりする。 • 必要なのは多くの可能性を受け入れることが出来る選択 ◦ システムは作るだけでなく、なくすこともある、作ったものを変えるのは大変 ◦ 多くの変化に対応できる構え。事業の変化、組織の変化、システムの変化 • AWSはこれらを柔軟に対応させてくれる土台の仕組みを提供してくれる ◦ 最後は使う人の設計力や組織との接合力は必要
  22. 違い • スタートアップと安定企業 ◦ ファイターと職人 ◦ 事業状況のボラティリティが大きい、小さい ◦ 即死 or

    様々な選択肢 • 技術的負債の種類 ◦ 技術力の不足と事業理解の深度 ◦ 環境の変化、事業周辺の環境変化、開発環境の変化 • システムが欲しいのか、事業の成功が欲しいのか 技術的負債を解消してやりたいことは同じ • 最速での開発と将来に広い選択肢を残すこと • 文脈は違っていてもやりたいことは同じ ◦ ただ、スタートアップの場合は即死という比重が大きすぎる • 最速での開発 ◦ 開発者体験の向上 = 内部品質の向上 と プロセスの構築 ▪ 内部品質の向上 = システム = コードやインフラ & そしてチーム ▪ プロセスの構築 = チーム活動 • CI/CDのシステムの自動化したプロセス • ドキュメンテーションなどを通じた知識のシェア • チーム力を向上するための知識集約と行動 を生み出す取り組み アジャイルなプロセス • ドキュメントはいらない ◦ でも意思決定は残す ◦ 変化のスピードが早すぎて、ドキュメントを直すよりも早く変更が入ってしまう ◦ ドキュメント書いてるくらいならコード書け。死ぬぞ。 ▪ 敵を倒さないと死ぬ。攻撃するしか無い。補助魔法でスピード上げてもバーンダメージの方が大きいから意味ない。1ターンで切れる。変化のターンが5ターン位持つようになると 意味が出てくる。 ▪ 斧を磨く、木こりの問題。
  23. ズレ • テクニカルな表現のズレ ◦ テスト品質 (不足・不安定) ◦ ドメインモデル外の構造 • テクニカルな劣化のズレ

    ◦ バージョンアップ ◦ トレンドの変化 • 事業的な表現のズレ ◦ モデル構造 ◦ アーキテクチャー • 事業的な要件のズレ ◦ スケーラビリティ ◦ セキュリティ 技術的負債とは
  24. スタートアップとは? 指標 スタートアップ エクセレントカンパニー 事業フェーズ 黎明期〜成長期 成熟期 リソース 常に不足・兼任 充実・専任

    リスクと不確実性 高い・全体的 低い・局所的 組織化と事業意識 粗い・集中 緻密・分散 変化のスピード 急速 緩やか
  25. 基準はシンプル → 事業のスピードに影響が出るものは手抜きしない! • 開発のスピードではない • 短期的 (3ヶ月〜6ヶ月) 以内に事業のスピードに影響が出る事象については対応 する

    • 1-2日の影響よりも、中長期 (3ヶ月〜6ヶ月)を意識する • 違う言葉なのに同じ期間。立場によって期間の感覚が変わることを理解する ◦ 事業目線 - 短期的 (3ヶ月〜6ヶ月) ◦ 実装目線 - 中長期 (3ヶ月〜6ヶ月) • プロトタイプか永続的かを考える 最低限の品質とは?
  26. 最低限の品質とは? (例) 技術的負債から品質の悪循環が最低限起きないレベル担保かつ時間が最速の中で諦 めることは? 個人的に考える「1ヶ月以内に元が取れる取り組み」 • 現状の構造変更は諦める ◦ 構造の変更は事業をできる限り理解しながら書く ◦

    振る舞いだけでなんとかする (だからこそ最初の構造設計が大事、そこにはコストを掛ける ) • テストは最低限書く ◦ ユニットテストは当然書く ▪ カバレッジは70-90%くらいが良いのでは。実装中にコストをペイ出来る。 ◦ インテグレーションテストと e2eテストは無し or 最低限の正常系から始める • CI/CDは作り込む ◦ リリースするものは全て通過するため、 頻度と時間の負担の大きさから理由は明白 ◦ ここを明白と思わない人は計算が上手くないので、別のエンジニアに判断を任せた方がいい • コードレビューは行う ◦ 障害が起きるとダメージが一番大きい。怪しいコードが生まれないようにする ◦ コード自体の改善も効果があるが、組織の目線合わせと文化づくりへの効果も大きい
  27. 技術的負債を定義するために大事なこと 理想状態の定義 • 現状と理想のギャップのため、みんなの技術的負債への認識のズレが大きい • それぞれの頭の中にあるふわっとした理想を明確に定義する • みんなの理想を明確にしてみると、やりたいことが大体違うので、これらを絞り込んで、目線を合わ せていく •

    目線合わせでこれから作るものを意識する • 大きな課題は 生み出す価値 が 事業価値にインパクトがある場合にはプロジェクト化する • 大上段でチームで動く方法 ↑ • 目の前の気になりを個人で動く方法 ↓ • 目の前のツラミやコードのちょっと気になる表現は自由に直せるようにする • 20%程度は技術的負債の解消に当てる時間にする • 説明するよりも直した方が早いモノはある • エンジニアで感覚的に理解しているものや怪しい匂いはある
  28. 技術的負債とは 品質と開発者体験 (DX)の関係を考える上で、 品質と顧客満足度の関係を分析する狩野モデルで当てはめて考えてみます。 • 魅力品質 → プラス方向の理想のため負債ではない • 当たり前品質

    → ここが担保されていたい (例:内部品質) • 一元的品質 → ここが困らない適度な状態 (例:CI/CDのスピード、PCのスピード) • 無関心品質 → 今回は価値に繋がらない負債は負債ではない • 逆品質 → ここが最小に抑えられている  (例:バグ、PjMの確認多すぎ) 体験のポジティブ面が高いところではなく、 ネガティブ面が抑えられているという状態を目指したい圧 = 技術的負債  と感じるものがイメージに近いのではないでしょうか 品質を高めるって どの品質?
  29. 技術的負債とは 生産性は1つの指標では測れない SPACEフレームワーク 出典 • Satisfaction and well being 業務難易度、必要なツールやリソースがあるか、自分のチームを薦めるかどうか

    • Performance バグの発生数、コードクオリティ、顧客満足度、サービス稼働率、信頼性向上 • Activity PRマージ数、コミット数、コードレビュー完了数、デプロイ頻度( Four Keys) • Communication and collaboration ドキュメント発見時間、新メンバーのオンボーディング時間や体験 • Efficiency and flow 自チームのMTG数や時間、他チームとのMTG数や時間、CI/CDフローでのトイル消化数 FourKeys 参考:書籍DevOpsの科学 • リードタイム コードが commit されてから本番環境で正常に実行されるまでの時間 • デプロイ頻度 コードを本番環境にデプロイまたはエンドユーザーにリリースした頻度 • 変更失敗率 リリースを実施した結果サービスが低下し、その後修正を行う必要が生じた割合 • 復元時間 サービスインシデントまたは不具合が発生したときにサービスの復元にどれくらいの時間がかかるか
  30. 自分の中の経験で技術的負債と向きあったときの問題 • MVPデカい問題 ◦ アドテクプロダクトの場合 ◦ バーティカルSaaSの場合 • PMF超えた問題 ◦

    事業の価値観が大きく変わる • 前提:命の火問題 ◦ スタートアップだからこその背水の陣 • 副次的視点:金・人・物 が全て足りない ◦ 適切なエンジニアいない問題 → 分かっていても技術的負債を生み続ける意思決定が必要になることも多い 詳しい話は 懇談会などで 聞いてください!
  31. 技術的負債に最小限にするために必要なこと 未来を見通す力 • 技術と事業の両面の価値を比較できる人を備える ◦ 両方を知っているというレベルでなく、経営判断可能な金銭的価値を説明可能な人 • 頻度が高く複利で得られる価値は優先的にシステム化する ◦ 頻度が高いということは払う金利も大きい。金利を払う前に先に対応する。

    • とにかく話し合う、エンジニア同士でも、エンジニアの職種を超えて、今いる人も前から居た人も新し く入った人も ◦ 未来は結局わからない。チーム全員の叡智を集める & 全員の納得度を高める。 = 今のチームの全速力 過去を理解し、尊重する • 努力を怠ったわけではなく、制約の中で精一杯のことをやっている • 十分な時間がなかっただけでなく、十分なスキルをもった人が居なかったこともある • 様々な苦難を乗り越えて事業として成立させたからこそ、今この開発がある
  32. 技術的負債の認識を合わせる必要がある 技術的負債は感覚的なものである → 詳細化と目線合わせが大事 根拠:人の感覚によって負債であるかどうかが違う。能力差 x 課題感 = 課題感は 現状(状況

    + 目標) - 未来への対応力(解決力) 技術的負債はスタートアップでは当たり前に存在するものである → 事業を優先するため、短期間の事業 状態を理解した技術な意思決定が大事 根拠:今目の前のことをやらなければ、会社の存続自体が難しい 普通の会社のプロジェクトの場合、お金の追加という手段があるがスタートアップには結果を出さなけれ ばその選択肢がない 技術的負債は変化するものである → 事業フェーズに合わせた経緯を説明し、フェーズの切り替わりでは 理解を促進して、敬意を持って対応することが大事 根拠:事業の状況によって、安全生存期間や目標の長くなることで価値の変化が起きる
  33. SI系会社時代 (主にSESでの業務) • エンジニア (いま考えると、自分は事業を作っておらず、新規システムを作っていた) • 保険共済、交通網ICカード在庫管理、工場部品管理 などを新規構築 • Web系に近いところでは、

    ◦ ソーシャルゲームアプリ ◦ ソーシャルコミュニティサービス • に関わっていました。どちらも現在はサービス終了 自己紹介 - 新規事業経験 (1/3)
  34. 自己紹介 - 新規事業経験 (2/3) Web系会社時代 (初期) • スマートフォンゲーム広告配信システム エンジニア→のちに開発責任者 ◦

    → 開発責任者になって程なくしてサービス クローズ • 動画広告配信システム 開発チーム立ち上げ開発責任者 ◦ → 一定の立ち上げ後、別開発へ異動。数年は事業継続したが、現在はサービス クローズ • 広告 DMP (Data Management Platform) 開発 (子会社) エンジニア →のちにCTO ◦ → 10人程度の組織から30人で3プロダクト組織に。別プロダクト開発へ異動。 現在は1プロダクトを残し、自分の関わっていたプロダクトはサービス クローズ • リアルタイム情報利用広告配信システム 開発チーム立ち上げ開発責任者 ◦ → サービス提供後、事業を伸ばせず クローズ
  35. 自己紹介 - 新規事業経験 (3/3) Web系会社時代 (現在) • 薬局在庫管理システム → 開発ディレクター(スクラムマスター)

    のちにエンジニアリングマネージャ ◦ → 順調にサービスは成長中  入社時の立ち上げ 5人チームから 現在は40人規模の開発組織へ ◦ 現在シリーズC (調達額94億円) まとめ • プロダクトの成長経験とスタートアップのお金の動きは現在の会社で 経験して理解した事が多いです。 • 逆に、サービスクローズの経験は何度も味わいました。。
  36. 話の流れ - アイデア 自己紹介 スタートアップとは 技術的負債とは スタートアップで起こる変化 MVPとPMFとは ・フェーズにより価値観が変わる 理想が変わるから技術的負債も変わる ・技術的負債じゃなかったものが一気に負債となって襲いかかる

    技術的負債と向き合うために必要なこと ・システムだけでなく事業も理解して作る。全ては短期と長期の価値の見極め。 ・システムを見極められるのはエンジニアだけなので、エンジニアが事業を理解するしか ない。事業者がエンジニアリングを理解してくれないと嘆くのは、エンジニアリングを伝え る変換がまだまだできていないだけ。 足りないものはたくさんある最初から満たされることはない。全てを抱えて僕等スタート アップは生きていく
  37. 技術的負債の論者 ウォード・カニンガム • Wikiの発明者、XPの父の1人、ケント・ベックと共にパターンランゲージをソフトウェア開発に導入し ようとした人、アジャイルマニフェストの署名者の一人、技術的負債の考案者。 マーチン・ファウラー • オブジェクト指向設計、統一モデリング言語 (UML) 、アナリシスパターンをはじめとしたソフトウェア

    パターン、エクストリーム・プログラミング (XP) を含むアジャイルソフトウェア開発方法論の各分野で 活発に活動。アジャイルマニフェストの署名者の一人、依存性の注入( Dependency injection)の用 語の発案者。 • 日本での書籍 ◦ リファクタリング―プログラムの体質改善テクニック ◦ エンタープライズアプリケーションアーキテクチャパターン ◦ など
  38. アーキテクチャの工夫で変化に強くする システムの品質は画一的なものを求めているわけではない ドメインを理解し分解しておく わからないことはあるので、直す前提 1つの棚に全部ぶち込んでも、物をしまうことができる。しかし、カテゴリごとにざっくり棚を分けてしまっておくだ けでも変更をしやすくなる ドメイン x 技術的レイヤー でのマトリックス的な構造

    究極に整えるとマイクロサービスで、中間的なものがモジュラモノリス、 定義的には次はモノリスだが、アーキテクチャ次第で緩い整頓がされたアーキテクチャと何も整頓されていない アーキテクチャのモノリスは意味が違う。 ドメイン x 技術レイヤー を想定してフォルダ (パッケージ)分けする
  39. アイデア 攻めと守りの2軸の組織構成になりやすい • 1つのプロダクトに2つのアプローチが必要になるので難しい • お互いに様子をみながら少しずつ進む時間があれば問題ないが、基本的にお互い全速力で走る体制じゃないと時間 的に厳しい (基本的にぶつかり合いながら全速力で走る二人三脚 ) 現システムを開発しつつ新アーキテクチャにリプレイス

    • レガシーと呼んだりするが、技術的負債の溜まったシステム ◦ 経緯と敬意がなければハレーションが大きい。 ◦ レガシーや負債と呼ばれるメンバーの事を考えた、呼び名や取り組みがないとつらい気持ちになる。 • よくあるパターンでマイクロサービスでの置き換えを目指したりする ◦ めちゃくちゃ地雷がある 技術面でも成熟度の差が生まれやすい • 環境の差もあるが、求められた技術の差もある。初期は、人、物、金がないので来てくれるだけで感謝。 • だた、金が集まると人も強い人を採用する基準になる。なぜなら、解決すべき課題が複雑になっている上に、会社が 惹きつける魅力があがっているため (金(年収)、実績、安定性)。 • 課題の難しさの種類が変わる。難易度は単純に比較できるものではない
  40. 技術は事業や組織と一体である アーキテクチャとして、事業や組織を一体化する技術的考え方が出てきている • DDD (ドメイン駆動開発) ◦ 技術と事業の一体的に対応する技術 ◦ 事業というと少し広すぎるが、ユーザー業務と技術の一体化に加えて、運用周りも含めて DDDで設

    計して運用することで、業務プロセスと技術のアーキテクチャを一体化させる • マイクロサービス 、モジュラモノリス ◦ 技術と組織の一体的に対応する技術 ◦ 組織を考慮せずに技術面だけで考えると失敗するアンチパターンになりうる • アジャイル、スクラム ◦ 技術、組織、事業で必要なコミュニケーションの循環をして開発が出来るようなプロセス ◦ システム開発組織の中だけでは本来の力半分 ◦ システムを作ることが目的ではなく価値の発揮やそのための文化やプロセスを作る
  41. 株式会社カケハシ tech blog https://kakehashi-dev.hatenablog.com/ OKRに書ける!知っておくだけで AWSコストをすぐ削減できる 26個のヒント https://kakehashi-dev.hatenablog.com/entry/2023/04/11/100000 CTO/テックリードのための AWSコストを大幅カットする取り組み方

    https://kakehashi-dev.hatenablog.com/entry/2023/06/07/103000 Amplify Studioでチームポータルページを作ってみた https://kakehashi-dev.hatenablog.com/entry/2022/10/18/100000 AWSの負荷テストソリューションを使った GraphQLの負荷テスト https://kakehashi-dev.hatenablog.com/entry/2022/08/31/100000 OWASP ZAPを利用したGraphQLアプリケーションへの脆弱性診断 https://kakehashi-dev.hatenablog.com/entry/2022/08/17/100000 AWS GlueのCI/CD環境を作ってみた https://kakehashi-dev.hatenablog.com/entry/2023/07/13/110000