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

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

主催 : AWS Startup Community

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

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

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

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

Transcript

1. AWS Startup Day 2023 2023/9/2 shinden tomohiro 技術的負債を抱えながら それでも生きていく https://aws-startup-community.connpass.com/event/289498/ #AWSStartup / @t_shinden
2. https://amzn.to/3OWZsdX https://www.ghibli.jp/info/013702/
3. 今日話すこと・話さないこと 今日は話さないこと • 技術的負債の与える影響 • 技術的負債の良し悪し • 技術的負債の発生の対策 • 技術的負債の解消の方法 • AWSの話・・・ 今日、話すこと • スタートアップにとっての技術的負債は何かの考察 • スタートアップという特殊環境で生まれる技術的負債の原因 • 技術的負債の向き合い方
4. タイトルで気付いていると思いますが 今日の話はロジカルではなくエモな話です スタートアップ x 技術的負債 という テーマ
5. この資料はのちほど公開します！ ページ数が多く、登壇中に触れない箇所がありますが、 後で確認してもらえればと思います #AWSStartup / @t_shinden
6. CfPのページにあった選択肢で困った 技術的負債ってどのトピックですか？ もし１つだけチェックをつけるとしたら？ 技術的負債ってどの項目なんだろう とても迷って、全部のチェックを入れた
7. index 0.話すこと、話さないこと 1.自己紹介 2.スタートアップとは 3.技術的負債とは 4.スタートアップで起こる変化 5.技術的負債と向き合うために必要なこと 6.まとめ
8. 自己紹介
9. 自己紹介 名前：新田智啓 (Shinden Tomohiro) 　　　ふりがなが無いと99%読み間違えられます 経歴：SI系とWeb系の両方で開発を経験 　　　新規システムの開発、新規事業の開発も数回経験　 　　 2001年〜 SIer数社 ・エンジニア、テックリード、エンジニアチームマネージャなど 2014年〜 サイバーエージェント ・アドテクスタジオ、エンジニア、開発責任者、技術責任者、子会社CTOなど 2018年〜 メルペイ ・バックエンドエンジニアリングマネージャ、テクニカルプログラムマネージャ 2020年〜 現在 株式会社カケハシ シリーズCのスタートアップ https://www.kakehashi.life/ ・新規プロダクト開発(AI在庫管理チーム) の 開発ディレクター(スクラムマスター)として入社 ・2022年9月 からはエンジニアリングマネージャーとして活動 ・働き始めて３年経ちますが、 オフィスへの出社回数は10回以下のフルリモート環境
10. SI系会社時代 (主にSESでの業務) 自己紹介 - 新規事業経験 新規構築システム ・保険共済 ・交通網ICカード在庫管理 ・工場部品管理 ・ソーシャルゲームアプリ ・など 役割 エンジニア・テックリード いま考えると、自分は事業を作っておらず 新規システムを作っていた 新規サービス立ち上げ ・ゲーム広告配信システム開発 ・動画広告配信システム開発 ・広告 DMP 開発 ・リアルタイム情報広告配信 ・など 役割 エンジニア・開発責任者・ 技術責任者・子会社 CTO Web系会社時代 新規事業立ち上げ ・薬局在庫管理システム → 順調にサービスは成長中 　入社時の立ち上げ 5人チームから 現 在は40人規模の開発組織へ 現在シリーズC (調達額94億円) 役割 開発ディレクターのちに エンジニアリングマネージャ スタートアップ会社時代 • プロダクトの成長経験とスタートアップのお金の動きや事業として必要な範囲の広さは 現在の会社で経験して理解した事が多い • 過去には立ち上げたサービスの クローズの経験を何度も味わいました。。
11. スタートアップとは ・自己紹介
12. スタートアップとは？ この３つの違いってご存知ですか？ 「スタートアップ」 「ベンチャー」 「スモールビジネス」
13. スタートアップとは？ ベンチャーとは 独自のアイデアや技術で新しいサービス等に挑戦している新規の企業全般 (以前はベンチャーとスタートアップを混同した使い方も多かったが、使い分けがされるようになってきている) つまり、スタートアップもスモールビジネスも ベンチャーに含まれる可能性がある では「スタートアップ」と「スモールビジネス」の違いは？
14. スタートアップとは？ (成長の推移) スタートアップとスモールビジネスの違い
15. スケールの仕組みが違うため、作るものが違う スタートアップとは？ (作るものの違い)
16. スタートアップとは？ (利益の推移) スタートアップの利益のグラフはJカーブやホッケースティックカーブと言われる
17. スタートアップの利益は最初は少なく 出資を受けた現金を使い果たす前に 利益を出す必要があります！ 創業して数年は赤字が拡大する 死の谷 (Valley of Death) を経験します そして、利益を反転できない場合は 会社がなくなります スタートアップとは？ (死の谷) 死の谷 (Valley of Death)
18. スタートアップとは？ 命の炎に限界があり、つねに燃え尽きるまでの時間と戦っている 追加の命 (資金) が無い限りは死ぬ 追加の資金は簡単に貰えない。次のステップの価値を証明する必要がある。
19. 会社という存在は土台 会社があり、 全ては資金で成り立っている 良い開発組織 良いシステム ここが崩れると 上に乗っているものも 無くなる 常に終わりが身近にある
20. スタートアップは 良いシステムか、良い組織か、そうじゃないか、ではない。 まずは 死ぬか生き残るか
21. スタートアップも色々なフェーズがある 安定した売上や生活があればスタートアップでもそこまで短期向きの意思決定をしなくて いい。ランウェイですね。命のロウソクが長い。 今回は 死の谷 (Valley of Death) 向かうスタートアップを想定します
22. スタートアップとは (まとめ) スタートアップは命の炎の限界がある 常に会社の存続と隣り合わせで考慮する必要がある あるとはいえ、技術的負債は放置して良いものでは無い 開発環境は複利で効果を得られるので、中長期目線であれば絶対やるべき スタートアップの中での技術的負債を考えていく
23. 技術的負債とは ・自己紹介 ・スタートアップとは
24. そもそも技術的負債とは ウォード・カニンガムによって造られたメタファー。 システムは粗雑なものが蓄積しやすく、内部品質に欠陥が出ます。 この欠陥がなければ開発時に必要なかった追加の労力は、借金に対して支払われる利 息というイメージに似ています。 この欠陥を解消する活動が技術的負債の解消ということです。 効率的に開発をするためには、定期的あるいは日常的に技術的負債を解消する取り組 みが必要ということです。 https://wiki.c2.com/?WardExplainsDebtMetaphor
25. そもそも技術的負債とは また、マーティンファウラーは借金が意図的に選択されたものなのか、 それが賢明なのか無謀なのかを考えることが有益であると語っています。 [無謀・意図的] • 設計に割く時間がない [慎重・意図的] • リリースを優先するが、結果にも対応する [無謀・無自覚] • レイヤー化って何？ [慎重・無自覚] • 今だから分かる手段もあった 無謀な負債 慎重な負債 意図的な 負債 無自覚な 負債 https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
26. そもそも技術的負債とは フィリップ・クルクテンは実際の価値は何なのかということに注目し、 「見えるかどうか」と「価値のプラスとマイナス」の軸で表現しています。 [プラスの価値・見える] • 新しい機能 [マイナスの価値・見える] • 欠陥・バグ [プラスの価値・見えない] • アーキテクチャ・構造の特徴 [マイナスの価値・見えない] • 技術的負債 https://philippe.kruchten.com/2013/12/11/the-missing-value-of-software-architecture/
27. 技術的負債とは プラスをアーキテクチャとして捉え、技術的負債をマイナスとすると 技術的負債の根底にはアーキテクチャや構造的な問題も含まれるはずなので、MICEで はないのでは？言葉の定義が合わない感覚もあるが・・・ アーキテクチャがフィットしない原因は、アーキテクチャそのものの失敗だけでなく、事業 の成長によってシステムに求められるものが変わることもある。 どちらにしても見えない部分の品質と呼ばれるものを理解する必要がありそう • 品質について外部品質と内部品質などの見える面と見えない面 • 表に見えている機能要件と障害になったときしか見えない非機能要件
28. 内部品質とは https://www.ipa.go.jp/publish/qv6pgp0000000wkj-att/000055008.pdf IPAの「つながる世界のソフトウェア品質ガイド」より 品質を高めるって どの品質？
29. 非機能要件とは
30. 技術的負債のメタファーを生み出したウォード・カニンガムは以下のように言っていま す。 技術的負債の比喩の中で、あとで綺麗なコードにするつもりで雑なコードを書くことも負 債の主な原因であるという考えが、他の原因と混同していると感じます。 私は決して雑 なコードを書くことには賛成しません。たとえ部分的な理解であっても、問題に対する現 在の理解を反映するコードを書くことが重要です。理解が不完全な状況でも借金を負い たい場合は、そのソフトウェアに自分の理解をできる限り反映させて、いざというときに 備えておくのが重要です。いざリファクタリングを行うときに、当時コードを書いたときに 何を考えていたかが明確になり、現在の理解に合わせたリファクタリングしやすくなりま す。 技術的負債のイメージの違い https://wiki.c2.com/?WardExplainsDebtMetaphor
31. よくイメージされている技術的負債との違い ウォード・カニンガムの言っていたことをまとめると コードを書くときにはベストを尽くせ！ コードを雑に書くのは技術的負債ではない (ただの怠慢) リファクタリングするときの未来が重要 技術的負債のイメージの違い
32. ペイオフラインの見極め マーチン・ファウラーは、デザイン(設計) に力を入れるとプログラミングの効率が下がる という意見には反対している。プログラマの自己満足のために設計を行っているという のは違う。 設計しないことで コードベースが劣化して 修正が難しくなり、生産性、 すなわちラインの傾きが低下 する。生産性の測定は難しく、 これは単なる仮説であるにも かかわらず、多くの人にとって の公理になっています。 https://martinfowler.com/bliki/DesignStaminaHypothesis.html
33. 機能開発の戦略には２つのアプローチがある • タクティカルアプローチ • ストラテジックアプローチ コードの複雑さはある日突然現れるのではなく、 塵が積もって山になるように徐々に出てきます。 ２つのアプローチがあるが、ペイオフラインは想像以上に早い。 日々の考えとして機能を作るだけでなく、 日々の考えの中でちょっと先の事も考えながら開発することが必要。 技術的負債とは A Philosophy of Software Design https://amzn.to/44mFYE2
34. 技術的負債とは 突然に現れるものではないとしても、 どうなると技術的負債と呼ばれ、負債リストに載せられるのか？ エンジニアがやりづらいと感じた瞬間、気がついたとき システムのコードや構造などでより良い新しいアイデアがあるとき 認知できない負債は負債ではない なぜなら価値への反映の障害となる課題感がない
35. 技術的負債とは ということは、現在のシステムで満足できないところが技術的負債 つまり 欲しい開発者体験 (DX)との差分というと 分かりやすいのではないだろうか
36. 開発者体験 (DX：Developer eXperience)とは 開発者体験とは、開発者が高速な仮説検証を行うための企業における環境や 習慣、文化のことを指します。 (CTO協会 DX Criteriaビジョン https://dxcriteria.cto-a.org/660d6573b45645bcb431c7c29c5431f8 ) 開発者体験という言葉だけ聞くと、開発者が働きやすいだけの環境のように聞こえます が、違います。開発者が障害に感じるものを最小化し、エンジニアが価値を最速で実現 できることです。つまり、生産性の高い理想状態のことです。 生産性って？
37. 生産性とは 生産性 = 生産物 ÷ 投入した資源 (Wikipedia) 生産性とはアウトプット量だけではなく、質も含んだ価値をどれほど高められるか。生 産性とは作るスピードではなく、価値貢献のスピードと考えています。 インパクトチェーン インプット アクティビティ アウトプット アウトカム インパクト (投入) (活動) (出力) (成果) (社会的変化) 計測Lv1 計測Lv2 計測Lv3 フェーズに合わせ生産物の計測 "価値"レベルを進める 例：開発機能数　　　　例：ユーザー利用数　　　例：利用者発信数 ムーヴメントを起こすのを 目指すのがスタートアップ？
38. 今回扱う技術的負債とは 理想との差分では、「解消すべき負債」と「解消不要な負債」がありますが、 負債解消が価値へのインパクトに繋がるものがスタートアップの課題になる そのため 「解消すべき負債」のみを技術的負債と定義して、話したいと思います。 理想の価値として定義している開発体験は理想郷の妄想ではなく、 現実に必要とされている生産性の回復した状態を定義したものです
39. • エンジニア価値発揮のための "理想"環境 (DX) - 現状システムや環境 = 技術的負債 • エンジニアの生産性を妨げ、追加の金利的な工数が掛かるもの • システム内部の課題 (内部品質、非機能要件) • 雑にコードを書いたものではなく、ベストを尽くしたもの • コードの複雑さはある日突然現れるのではない • 今回は負債解消によって価値が発揮されるものだけを負債と考える 技術的負債とは (まとめ)
40. スタートアップで起こる変化 ・自己紹介 ・スタートアップとは ・技術的負債とは
41. 優先順が変わりやすい理由 - 優先順とバランス スタートアップではない進め方では不確実性が低く、目標があり、 開発完了までゴールが変わらなかったり、変わるとしても無理なく 緩やかに変わる スタートアップでは大きく変わることが前提 不確実な事実が明らかになったときに大きく変わってしまうため、 急激に方向性も変わる
42. 方向性の変化と「技術と組織と事業」の３つの関係 方向性を変える時に必要なことは技術内だけでは決まらない 技術と事業と組織は密接に関わり、影響を与えあっている
43. 技術(システム) エンジニア目線での開発と成長サイクル 事業 組織 成長 作る 拡大
44. 技術(システム) エンジニア目線での開発と成長サイクル 事業 稼働するシステム ◆技術的広さ◆ AWSなどインフラ フロントエンド バックエンド ◆技術的深さ◆ アーキテクチャ フレームワーク活用 プログラミング言語 組織 システムを 維持するための ルール システムを 開発するための プロセス 成長 作る 拡大 システムを 維持するための 仕組み CI/CD IaC 自動回帰テスト DB Migration Lint 文化 注目しがち 見えないけど 実は大事
45. システム開発に必要なのはシステムだけではない システムを開発するための仕組み、ルール、チームの形 だけど、スタートアップの変化は多い。事業、組織も変わる必要がある 変化に合わせチームも仕組みも変えなければ状況と開発プロセスが合わなくなる 組織的プロセスの負債が生まれる (計画の立て方、目標の定義、属人性、品質目線、レビュー文化、テストの不足など ) 緩やかな変化では対応できるが、 急激な変化では意識的に対応しなければ対応が難しい システム開発に必要なのは稼働するシステムだけではない
46. 技術(システム) エンジニア目線での開発と成長サイクル 事業 稼働するシステム ◆技術的広さ◆ AWSなどインフラ フロントエンド バックエンド ◆技術的深さ◆ アーキテクチャ フレームワーク活用 プログラミング言語 組織 システムを 維持するための ルール システムを 開発するための プロセス 成長 作る 拡大 システムを 維持するための 仕組み CI/CD IaC 自動回帰テスト DB Migration Lint 変化が 大きい エンジニア 頑張る エンジニア頑 張る 文化 スピード が早い 対応に時間も パワーも掛かる 対応に時間も パワーも掛かる チームが拡大し ても 思ったより 早くならない ここにも負債が あるのでは？
47. 変化に合わせて変えなければならないこと 開発や事業の状況が突然変わることがある。 スタートアップだとその可能性が高い。むしろ当たり前。 改善レベルの変化では間に合わないので、意識を変革させる取り組みが必要 事業の状況変化の前後で対応しなければいけないことが変わるが、 組織の文化やプロセス、システムの構築には慣性があるので システムや組織が大きくなればなるほどすぐに変わることは難しい
48. システムそのものの負債も周辺の変化対応負荷も高い システムは開発チームによって作られます (当たり前) 一番大事なことは機能開発ではあるが、そのために必要なことが色々ある。 エンジニアチームは機能の継続的開発 の他に３つの大きな課題に同時に向き合う １．稼働するシステムの周辺のシステムの対応 ２．組織の変化に対応 ３．そして技術的負債への対応
49. 周辺の変化によって技術的負債の価値が変わる (今回の定義では) 負債解消されると価値が発揮されるもの である。 変更する必要がないところは負債ではない！ (今回の定義では) だが、変更が必要になった瞬間負債になる。 本来は元々あった負債だが、事業の変化によって優先順が大きく変わる！
50. 優先順が変わりやすい理由 スタートアップは基本的にいつでも変わるという前提はあるが 分かりやすく大きく変わるタイミングがある
51. プロダクトを作るときの事業フェーズ 最小限実装 フェーズ Minimum Viable Product 機能試行錯誤 フェーズ Product Market Fit スケール可能実装 フェーズ Go To Market スケール フェーズ Growth MVP PMF GTM Growth なるべくシステムを 作らずに価値を検 証する 価値をプロダクトで 実現する方法を最 小コストで探る スケールするため のシステム状態に する 価値を拡張する 様々な機能を追加 する システム 視点での 解釈 意味 通称
52. 技術的負債のフェーズの変化 フェーズによって感じることや見え方や優先順が違う 例として 次ページの２つの環境の違いから感じることを紹介
53. 事業が立ち上がるか戦っているとき ドラゴンと戦っています！ • Q. 腕に大きな怪我をしている。どうする？ ◦ 傷は抉れている ◦ 腕を動かすのも辛い ◦ 動かさなくても痛い • A. それどころじゃなく戦うしかない ◦ 小さな傷でも、大きな怪我でも、 今死なない限りは気にしている暇がない ◦ 命の危険の方が大きい
54. 事業の立ち上がりが見えて、日常に戻れそうなとき 日常に移ったとき同じ怪我をしていたら？ • Q. 腕に大きな怪我をしている。どうする？ ◦ すぐには死なない ◦ 大変だけどまだ生活は出来る？ • A. なんでこんなになるまで放っておいた？！ ◦ 普通ではこんな怪我ありえない！ ◦ 放ったまま生活している意味が分からない！ ◦ 何が起こったんだ！？大丈夫か？ ▶ 場面が違うと同じ状態 (ダメージ) でも全く違うように見える 同じ質問
55. 環境が違うと同じ意味の問いを掛けても意味が変わる 現状環境と理想状態が変わるので、技術的負債と感じるものが急激に増大する 技術的負債も見る場面によって違うように見える 環境によって理想状態が変わり差分が大きくなる = 技術的負債の増大 フェーズの切り替わりは価値観が変わる
56. 事業フェーズによって変わるシステムに向かう価値観 最小限のコストで の実現方法 価値の探索のため のアイデア検証 組織としての安定 を目指す 成長のための開発 ラインの複線化 システム安定よりも 機能開発 売上の安定化 価値的スケーラビ リティの検証 機能開発がプロジェク トマネジメント的になる リアーキテクチャなど の大規模リファクタが 必要になる MVP PMF GTM Growth ↑↑ 実現アイデア ↓ 機能品質 ↓ バグの問題 ↑↑機能開発スピード ↑ バグへの品質 ↑ 組織化 ↓↓ 阿吽の呼吸 ↑↑バグへの品質 ↑↑高負荷状況 ↑ スケール向け機能 ↓↓ 探索的アイデア ↑ バグへの品質 ↑ 組織化 ↑ 模索的アイデア ↑↑ 安定開発 優先度や 関心度の 変化 意味 通称 フェーズが変わると価値観が大きく変わる
57. 技術的負債があるって？・・・、知ってたよ。 技術・組織・事業は一体となって開発をする必要があるが、 フェーズが変わり組織が急成長すると、 組織の問題が噴出する 新しい価値観で見た技術的負債が掘り起こされる 事業への価値停滞が発生する 知ってた。 技術的負債があるって分かってたが、違う優先順の価値観があった。
58. フェーズが変わると理想状態が変わり差分が大きくなる = 技術的負債の増大 技術的負債が増大する理由とスタートアップの変化 (まとめ) 技術的 負債 現状の システム 状態 事業として 必要な システム状態 理想の システムの 状態 技術的 負債 現状の システム 状態 事業として 必要な システム状態 理想の システムの 状態 期待の状態 現状 期待の状態 現状 状況や目標の 変化 機能開発予定 会計のB/S的イメージ 増加 増加 追加
59. 技術的負債と向き合うために必要なこと ・自己紹介 ・スタートアップとは ・技術的負債とは ・スタートアップで起こる変化
60. スタートアップ x 技術的負債 事業として軌道に乗るまで ・人員を増やすことが難しい ・継続的な機能開発が求められる プロダクトがPMFを模索したり、ユーザーが増えることで品質問題が顕在化する ・優先すべきは機能リリース ・技術的負債の対応までは手が回らない ← ？
61. スタートアップ x 技術的負債 事業として軌道に乗るまで ・人員を増やすことが難しい ・継続的な機能開発が求められる プロダクトがPMFを模索したり、ユーザーが増えることで品質問題が顕在化する ・優先すべきは機能リリース ・技術的負債の対応までは手が回らない ← ここを諦めずに向き合う
62. スタートアップ x 技術的負債 今回の話すこと ◯ 技術的負債に向き合う 今回話さないこと ☓ 技術的負債の対応(対策・解消)方法の検討
63. スタートアップ x 技術的負債 防げた技術負債はあったのか？ 人も居ない、時間もない、お金もない • 制約的選択 (賢明な意思決定) ◦ トレードオフでの選択 ◦ お金がないことが起因による時間のなさ • 学びの不足 (無謀な意思決定) ◦ 開発的知識の不足 ◦ 事業的(ドメイン)知識の不足
64. スタートアップ前提で負債への意識を考えてみる [無謀・意図的] • 設計に割く時間がない → そうです。無いです。 [慎重・意図的] • リリースを優先するが、結果にも対応する → そうです。やるしか無いです。 [無謀・無自覚] • レイヤー化って何？ → そうです。良いエンジニアは揃っているわけではにし、雇うお金もありません。 [慎重・無自覚] • 今だから分かる手段もあった → そうです。知らないことだらけのところで新しい価値を作るんです。 そうです！ スタートアップは無謀で慎重に意図的に分からないことに飛び込でいます！ 不確実性が高い中で新しい価値を模索している！ なので、満たされるまでは技術的負債が生まれます！ マーティンファウラーの提言した４象限
65. 技術的負債が気になるのは次の課題に進んだから 誰かが悪い訳では無い 当時の状況の中で精一杯やった結果である むしろ事業を成長したからこそ次の課題にぶつかっているという証 過去のエンジニアの汗と血と涙に敬意を持ちながら、 今の課題として粛々と対応していくべきもの
66. 技術的負債を憎まない 人を憎まず、技術負債も憎まず 感謝していこう
67. 技術的負債 過去への向き合うことは分かった でも、今の課題とどのように向き合っていけば良いのか？ 今に向き合って、未来に進むためには多くのことを決める必要がある
68. 立ち上げの範囲 システム 立ち上げ プロダクト 立ち上げ 事業 立ち上げ
69. 立ち上げの範囲 システム 立ち上げ プロダクト 立ち上げ 事業 立ち上げ ここだけ見れば 意思決定できることもあるが、
70. 立ち上げの範囲 システム 立ち上げ プロダクト 立ち上げ 事業 立ち上げ スタートアップはここまで見ないと 意思決定できないことが多い
71. 優先順とバランスを捉える必要がある 事業-組織-技術(システム) はエンジニアにとって全て理解してく必要がある 広い権限と同時に責任もある 技術だけで考えても納得できない意思決定を感じてしまう 未来を決めるための意思決定は全領域の未来を想像する必要がある そして、過去を理解する必要がある
72. 技術的負債の過去と現在、そして未来 技術的負債の経緯と敬意 • 経緯が分からなけれ敬意は生まれにくい • システムだけの理解では感謝は難しい 必要なのは「今とシステム」という目線から「広げて知る」こと • 過去 - 現在 - 未来 • システム - プロダクト - 事業
73. 今の課題と未来を話す 技術的負債の経緯と敬意 は過去 未来を話すための "Disagree and Commit" 全てを伝えきれるわけではない。意見をすることで経緯を理解する "Disagree and Commit" とは amazonのリーダーシッププリンシパルの１つ ｢意見に同意できない場合には、敬意をもって異議を唱えなければなりません。たとえそうすることが面倒で労力を要することであっ ても、例外はありません。安易に妥協して馴れ合うことはしません。しかし、いざ決定がなされたら、全面的にコミットして取り組みま す。｣
74. 技術的負債の過去と現在、そして未来 今を優先せざるを得ない状況でも 広い視野で技術の未来を考える責任に向き合う これまでに抱えた負を伝え合い、理解する そして技術的負債に向き合い対応を検討する
75. 未来の得る複利と支払う金利の厳然たるロジックでの計算 スタートアップとはいえ、短期的効果が低いが長期的効果があるものを全て実行しない というのはもったいない。事後的に見ると結果的に最速を実行できていないケースもあ るはず。 事業・組織・技術を一体で捉え 未来からの逆算での意思決定が 必要になる。 当たり前だが超難しい。 だが、これが本当の技術力。 価値に対しての技術インパクト を計算し、実行すること。
76. 必要以上に短期に見積もると事業への弊害が起きる 中長期の事業スピードに大きな影響が出る 命の炎に迫られていても短期の結果を取ることが正義な訳では無い 開発文化はバランスを取る必要がある • フェーズに合わせた日常的な負債解消の文化を入れること • プロジェクト化するときは事業の波と合わせる必要がある • 事業の方向性を先回りしてシステムの負債の箇所を把握する
77. 木こりのジレンマ ある木こりが、がんばって木を切っている。 通りがかった旅人がその様子を眺めていたが、斧を振るう勢いのわりに、なかなか木が切れていない。 見ると木こりの使っている斧がこぼれしているようなので、旅人は言った。 「斧を研いだほうが効率がいいのでは？」 すると、木こりは言った。 「わかっちゃいるんだけどね、 木を切るのに忙しくて、それどころじゃないよ」 斧の刃が ぼろぼろだよ 斧を研ぐ　 暇はないよ！
78. 技術的負債の悪循環が回る瞬間は絶対に食い止める 技術的負債の金利の悪循環は辛い 技術的負債が原因による品質の低下で発生する悪循環 • 無謀な開発→障害が増える→開発速度の低下→無謀な開発 　　→最初に戻る 技術的負債から品質の悪循環が起きないレベルの担保かつ時間が最速を選ぶ 技術的負債が生まれてるのは分かってる！シビアなトレードオフの意思決定が必要！
79. 技術的負債はひとりひとりが向き合う事 ロジックとして技術的負債に向き合うには？ 誰かがやってくれるもの？ エンジニア全員でやるもの
80. 理想の定義って出来ています？ 技術的負債の方程式： 現状 → 理想 → ギャップ = 技術的負債 みんなの理想って合ってますか？ それぞれが自由に思っていてバラバラなことも多い 理想の定義がチームで揃えないと、技術的負債の具体的な認識も揃わない Howの精査より価値の精査をして、技術的負債の認識を揃える必要がある 技術的負債の認識の違いによって、軋轢が生まれていることもあるのでは？
81. 最速のための作業はルールを合わせて実行する 実行頻度 x 実行時間 と 開発時間 のトレードオフ マインドシェアも含めて計算考慮するべき 頻度が多いものは無条件で開発する (検討時間自体が無駄なことも多い) 開発だけに集中することが難しいスタートアップのエンジニアにとって マインドシェアの影響は想像以上に大きい マインドシェアを取られる開発は解消に向けた開発をする
82. 実働時間に加えてマインドシェアも気をつけるべき 10分の作業が10個あったら約１人分のコストを無駄にしているかも知れない 毎日するデプロイ作業時間 10分とした時に、エンジニアのマインドシェアは前後 10分掛かるとする。その 場合、 30分(前後の10分のマインドシェア + 実働時間10分)のコスト * 月に20日 = 600分 = 10時間 => 毎回か掛かっている金利 年間で 120時間 = 15日分。１ヶ月弱無駄にしている。これは１日１回しかデプロイしないパターンなので、 １日数回デプロイするとそれ以上掛かる。新しい人が作業すると手順からキャッチアップが必要なので、そ れ以上の時間が掛かる。 10分の作業だから自動化しなくていいと思っていること無いですか？ デプロイ以外にも本当だったら仕組み化できる 10分の作業ってないですか？
83. 技術だけでも向き合えないし、組織の視点も必要で 広い視点と技術の特性の深い視点を持ちバランスする必要がある 必要な広い視点 • システム - プロダクト - 事業 • 過去 - 現在 - 未来 • 技術 - 組織 - 事業 という関わる人 必要な技術の特性の深い視点 • エンジニアのマインドシェア • エンジニアの無駄な認知負荷 • エンジニアの理想状態の思い 必要な広さと深さとバランス 技術スキルの知識の 向上は前提として 今の全力を出すために
84. どう向き合う？ 事業で結果を出してから技術的負債に向き合う 事業で結果を出すために技術的負債に向き合う 組織が感じる技術的負債の辛さに向き合う 組織の本当の力を発揮するために技術的負債に向き合う 学んだ技術を今の技術的負債を解決する力にする 学んだ技術を次の技術的負債を生まない力にする 技術的負債が生まれる前でも後でも、向き合って一歩ずつ進む
85. まとめ ・自己紹介 ・スタートアップとは ・技術的負債とは ・スタートアップで起こる変化 ・技術的負債と向き合うために必要なこと
86. 技術的負債は雑にコードを書いたものではない ベストを尽くした上で発生したもの 少し未来を見ながらコードを書く 必要な広さと深さとバランス
87. スタートアップ x 技術的負債は 必要なヒト・モノ・カネも不足している上に 変化が大きく、スピードも早く、技術的負債が生まれやすい環境 短期的な事業的事情と中長期的なシステム的事情をバランスの扱いが難しい 「技術を中心とした広い視点」と 「技術の特性の深い視点」を持ち バランスする必要がある 必要な広さと深さとバランス
88. スタートアップの技術的負債のまとめ 技術的負債がある前提で、責める必要はない 今を悲観するのではなく、「何故生まれたか」と「どう向き合うか」が大事 過去 - 現在 - 未来 の全てが大事 経緯に敬意を持ち、過去も理想(未来)も伝え合うことで技術負債の輪郭が見える 技術的負債と向き合うには、システムだけではなく組織と文化も大事
89. CfPのページにあった選択肢で困った 技術的負債ってどのトピックですか？ もし１つだけチェックをつけるとしたら？ 最後にあらためて確認 全部やらないと技術的負債とは向き合えない
90. ご清聴ありがとうございました！ ちょっとだけ続きのページがあります
91. 以降、アイデアスライド メイキングビデオ的なもの 本編、メイキングスライドのどちらも SNS等で反応を頂けると喜びます！！ 　　 #AWSStartup / @t_shinden
92. アイデア スピード最優先・属人性歓迎。事業が成功しなければ意味がない。 そのために技術負債を受け入れても事業の成功見通しを立てる。システム的構造物の優先順は確実に優先順が下。 しかし、事業の成功が見えた瞬間、中長期に向けた重要機能になるため、事業成功のコアの位置を取るため、優先順が事 業と同等になる。 最速のための安定。間違ってはいけない。雑作業と受け入れ判断。 求めるのは意思決定後の最速のスピード、広い未来の可能性を受け入れられる仕組みを意思決定する。 AWSのサービスを様々選択することが出来る。 最大規模を受け入れられるシステム的理想状態ではなく、最速で受け入れられるシステム的理想状態。 急速に襲いかかる技術的負債。事業成功が見えたときには新しいメンバーも入る。負債に不満も出る。 システム崩壊が組織崩壊に繋がる可能性もある。大きく変える、小さく変えるを柔軟にする。
93. 伝えること • スタートアップにとって技術的負債を抱えることは必然 ◦ 注意：ただし、雑なことと、判断して受け入れることは別 ◦ 安定性を犠牲にした負債は最速を奪う - 内部品質は重要 ◦ 技術的負債の許容は最速のためである - スタートアップは環境が違う。 ▪ ドラゴンと戦っている or 街の工場で働いている。 ◦ 技術的負債の原因は２つ。能力の不足、周辺環境の変化。 ◦ 技術的負債は状況とのズレが大きいが、スタートアップではむしろ無いものの方が多い。 ▪ 負債であってもあるだけまし、動くだけまし。 ◦ 能力の方の話はしない ▪ 技術的な理解を鍛えるだけ。 ◦ 負債には２つの環境変化の原因がある ▪ 事業的環境変化と開発的環境変化。 ◦ 問題は負債と呼ばれる課題だけでなく、そのズレによる影響度 => スタートアップは即死する • 事業的フェーズの区切りで突然技術的負債の解釈は変わるもの ◦ 価値観の変化は必然、システムの持つ優先度が変わる • システムと組織は一体である ◦ システムの状況解釈の違い、目線の変化、経緯が理解できないと、組織停滞や崩壊にも繋がる可能性がある。今やることの理解だけでなく、未来も知りつ つ、過去の理解も大事。 PMFあとに入った人はこの惨状にびっくりする。 • 必要なのは多くの可能性を受け入れることが出来る選択 ◦ システムは作るだけでなく、なくすこともある、作ったものを変えるのは大変 ◦ 多くの変化に対応できる構え。事業の変化、組織の変化、システムの変化 • AWSはこれらを柔軟に対応させてくれる土台の仕組みを提供してくれる ◦ 最後は使う人の設計力や組織との接合力は必要
94. 違い • スタートアップと安定企業 ◦ ファイターと職人 ◦ 事業状況のボラティリティが大きい、小さい ◦ 即死 or 様々な選択肢 • 技術的負債の種類 ◦ 技術力の不足と事業理解の深度 ◦ 環境の変化、事業周辺の環境変化、開発環境の変化 • システムが欲しいのか、事業の成功が欲しいのか 技術的負債を解消してやりたいことは同じ • 最速での開発と将来に広い選択肢を残すこと • 文脈は違っていてもやりたいことは同じ ◦ ただ、スタートアップの場合は即死という比重が大きすぎる • 最速での開発 ◦ 開発者体験の向上 = 内部品質の向上 と プロセスの構築 ▪ 内部品質の向上 = システム = コードやインフラ & そしてチーム ▪ プロセスの構築 = チーム活動 • CI/CDのシステムの自動化したプロセス • ドキュメンテーションなどを通じた知識のシェア • チーム力を向上するための知識集約と行動 を生み出す取り組み アジャイルなプロセス • ドキュメントはいらない ◦ でも意思決定は残す ◦ 変化のスピードが早すぎて、ドキュメントを直すよりも早く変更が入ってしまう ◦ ドキュメント書いてるくらいならコード書け。死ぬぞ。 ▪ 敵を倒さないと死ぬ。攻撃するしか無い。補助魔法でスピード上げてもバーンダメージの方が大きいから意味ない。１ターンで切れる。変化のターンが５ターン位持つようになると 意味が出てくる。 ▪ 斧を磨く、木こりの問題。
95. 技術的負債とスタートアップ 計画はあるが人は居ないところからスタートする そして時間はない キーワードは "継続性" をどうロジカルに計算するか どこまでテストコードを書くのか？ どこまでリファクタリングするのか？ １回しか使わないコード vs ずっと動き続けるコード 開発中に何度も動作試すコード vs 開発中に動作を試さないコード
96. ズレ • テクニカルな表現のズレ ◦ テスト品質 (不足・不安定) ◦ ドメインモデル外の構造 • テクニカルな劣化のズレ ◦ バージョンアップ ◦ トレンドの変化 • 事業的な表現のズレ ◦ モデル構造 ◦ アーキテクチャー • 事業的な要件のズレ ◦ スケーラビリティ ◦ セキュリティ 技術的負債とは
97. 技術的負債とは 技術的負債が増え続ける環境が辛いのは、理想とする開発環境から遠くなるから ただ、開発体験と価値提供と天秤に乗せたときに、価値提供を優先するエンジニアこ そ、スタートアップ向き。 （スーパーなエンジニアは両方を実現するのだろうけれど）
98. スタートアップとは？ 命の炎 (資金) に限界があり、つねに燃え尽きるまでの時間と戦っている
99. スタートアップとは？ 命の炎に限界があり、つねに燃え尽きるまでの時間と戦っている 追加の命 (資金) が無い限りは死ぬ
100. スタートアップとは？ 命の炎に限界があり、つねに燃え尽きるまでの時間と戦っている 追加の命 (資金) が無い限りは死ぬ 追加の資金は簡単に貰えない。次のステップの価値を証明する必要がある。
101. スタートアップとは？ 指標 スタートアップ エクセレントカンパニー 事業フェーズ 黎明期〜成長期 成熟期 リソース 常に不足・兼任 充実・専任 リスクと不確実性 高い・全体的 低い・局所的 組織化と事業意識 粗い・集中 緻密・分散 変化のスピード 急速 緩やか
102. 技術的負債とは 技術的負債は見えないとか言ってるけど、エンジニアから見えてるし、感じているし、む しろ耐えている ずっと焼かれ続けている 技術的負債を産み続ける無謀な開発に持続性はない。 だが、事業が失敗すれば開発も存在しない未来しかない。 事業が継続してこその開発の継続。
103. 基準はシンプル → 事業のスピードに影響が出るものは手抜きしない！ • 開発のスピードではない • 短期的 (3ヶ月〜6ヶ月) 以内に事業のスピードに影響が出る事象については対応 する • 1-2日の影響よりも、中長期 (3ヶ月〜6ヶ月)を意識する • 違う言葉なのに同じ期間。立場によって期間の感覚が変わることを理解する ◦ 事業目線 - 短期的 (3ヶ月〜6ヶ月) ◦ 実装目線 - 中長期 (3ヶ月〜6ヶ月) • プロトタイプか永続的かを考える 最低限の品質とは？
104. 最低限の品質とは？ （例） 技術的負債から品質の悪循環が最低限起きないレベル担保かつ時間が最速の中で諦 めることは？ 個人的に考える「１ヶ月以内に元が取れる取り組み」 • 現状の構造変更は諦める ◦ 構造の変更は事業をできる限り理解しながら書く ◦ 振る舞いだけでなんとかする (だからこそ最初の構造設計が大事、そこにはコストを掛ける ) • テストは最低限書く ◦ ユニットテストは当然書く ▪ カバレッジは70-90%くらいが良いのでは。実装中にコストをペイ出来る。 ◦ インテグレーションテストと e2eテストは無し or 最低限の正常系から始める • CI/CDは作り込む ◦ リリースするものは全て通過するため、　頻度と時間の負担の大きさから理由は明白 ◦ ここを明白と思わない人は計算が上手くないので、別のエンジニアに判断を任せた方がいい • コードレビューは行う ◦ 障害が起きるとダメージが一番大きい。怪しいコードが生まれないようにする ◦ コード自体の改善も効果があるが、組織の目線合わせと文化づくりへの効果も大きい
105. 技術的負債を定義するために大事なこと 理想状態の定義 • 現状と理想のギャップのため、みんなの技術的負債への認識のズレが大きい • それぞれの頭の中にあるふわっとした理想を明確に定義する • みんなの理想を明確にしてみると、やりたいことが大体違うので、これらを絞り込んで、目線を合わ せていく • 目線合わせでこれから作るものを意識する • 大きな課題は 生み出す価値 が 事業価値にインパクトがある場合にはプロジェクト化する • 大上段でチームで動く方法 ↑ • 目の前の気になりを個人で動く方法 ↓ • 目の前のツラミやコードのちょっと気になる表現は自由に直せるようにする • 20%程度は技術的負債の解消に当てる時間にする • 説明するよりも直した方が早いモノはある • エンジニアで感覚的に理解しているものや怪しい匂いはある
106. 技術的負債 もし、人、物、金、時間があるようだったら 一番早い改善の方法としては技術的負債に適切に対応できる人を採用することをオス スメします それは、エンジニアかも知れないですし、プロジェクトマネージャかも知れないですし、技 術コンサルかも知れないですし、アジャイルチームを作るコーチかも知れません 次にチームのエンジニアの成長と新たな取り組みをすることがいいと思います
107. 技術的負債とは 品質と開発者体験 (DX)の関係を考える上で、 品質と顧客満足度の関係を分析する狩野モデルで当てはめて考えてみます。 • 魅力品質 → プラス方向の理想のため負債ではない • 当たり前品質 → ここが担保されていたい　(例：内部品質) • 一元的品質 → ここが困らない適度な状態　(例：CI/CDのスピード、PCのスピード) • 無関心品質 → 今回は価値に繋がらない負債は負債ではない • 逆品質 → ここが最小に抑えられている　　(例：バグ、PjMの確認多すぎ) 体験のポジティブ面が高いところではなく、 ネガティブ面が抑えられているという状態を目指したい圧 = 技術的負債 　と感じるものがイメージに近いのではないでしょうか 品質を高めるって どの品質？
108. 技術的負債とは 生産性は１つの指標では測れない SPACEフレームワーク 出典 • Satisfaction and well being 業務難易度、必要なツールやリソースがあるか、自分のチームを薦めるかどうか • Performance バグの発生数、コードクオリティ、顧客満足度、サービス稼働率、信頼性向上 • Activity PRマージ数、コミット数、コードレビュー完了数、デプロイ頻度（ Four Keys） • Communication and collaboration ドキュメント発見時間、新メンバーのオンボーディング時間や体験 • Efficiency and flow 自チームのMTG数や時間、他チームとのMTG数や時間、CI/CDフローでのトイル消化数 FourKeys 参考：書籍DevOpsの科学 • リードタイム コードが commit されてから本番環境で正常に実行されるまでの時間 • デプロイ頻度 コードを本番環境にデプロイまたはエンドユーザーにリリースした頻度 • 変更失敗率 リリースを実施した結果サービスが低下し、その後修正を行う必要が生じた割合 • 復元時間 サービスインシデントまたは不具合が発生したときにサービスの復元にどれくらいの時間がかかるか
109. 技術的負債に最小限にするために必要なこと 未来を見通す力 過去を理解し、敬意を示す
110. 技術的負債に向き合う スタートアップだから放置していいという話ではない 価値の提供のスピードに影響が出ると致命的 複利で効果があることは真っ先にやる 価値が発揮できるかどうか分からないことは作ってから考える 技術的負債になることは分かっていても、この方向転換がたくさんあるのがスタートアッ プ
111. 組織の変化も同時に起きる 順調に事業が伸びると組織にも新しい人が増え、組織も拡大する 組織ができてくると技術リーダーが「全てを決める」「中央集権型」から 「組織で決めること」と「トップが決めること」の「権限の分離」が起きる 経緯を知らない人がシステムを見ることになる チームが見ているシステムの見え方が変わる 組織が変わると組織の形も文化も調整し直す必要がある
112. あらしい異人たちは知らない (typoしたけど面白いからそのまま ) でも、以前あった優先順やシステム以外の周りはまだ見えていない エンジニアリングの技術的負債はエンジニア以外見えない 組織に新しく入ってきた人は経緯を知らない、ここまでの成長を知らない 組織の話なのか？技術の話なのか？事業の話なのか？ 全部の話です。
113. 突然フェーズが変わる 事業が順調に進み、エンジニアが増えると負債の影響も増える フェーズが変わったら、絶対に負債対応の意思決定は必要 • 組織崩壊が先か、システム障害祭りが先かのチキンレースになる • (毎晩夜１時に起こされる時期がありました。) • 新しく採用した人数を含めて、３割から５割の人員を投入するべき ◦ 根拠はないが、このくらいの人数を投入する覚悟がないと負債の生成速度に追いつかない ◦ 同時に、負債で起きる障害や開発の非効率さに巻き込まれて失う時間のロスが大きすぎる
114. 突然フェーズが変わる リリースや機能開発の完了であれば分かりやすい 手応えみたいなもので、方針が変わるため状況をキャッチする必要がある 明確に形になるのは、事業的な意思決定やVCからの追加出資によって変わる チームや組織は慣性があるため、急に変わらない、変われない 慣性はチームの目線などの暗黙的合意、プロセス、システム 強力に状況に合わせた方向転換が必要 方向転換と同時に組織が大きくなると状況が複雑化する (だけど、あるある。順調だと同時に組織も大きくなりがち )
115. 自分の中の経験で技術的負債と向きあったときの問題 • MVPデカい問題 ◦ アドテクプロダクトの場合 ◦ バーティカルSaaSの場合 • PMF超えた問題 ◦ 事業の価値観が大きく変わる • 前提：命の火問題 ◦ スタートアップだからこその背水の陣 • 副次的視点：金・人・物 が全て足りない ◦ 適切なエンジニアいない問題 → 分かっていても技術的負債を生み続ける意思決定が必要になることも多い 詳しい話は 懇談会などで 聞いてください！
116. 外見えることでなくエンジニアの頭の中で起きていること 技術的負債 → システムの中身なので、エンジニア以外には見えない エンジニアにも見えていないこと • 認知負荷 • マインドシェア • モチベーション (基本は下るが、負債に奮起して上がるケースもある) → 具体化や計測をする必要がある
117. 技術的負債に最小限にするために必要なこと 未来を見通す力 • 技術と事業の両面の価値を比較できる人を備える ◦ 両方を知っているというレベルでなく、経営判断可能な金銭的価値を説明可能な人 • 頻度が高く複利で得られる価値は優先的にシステム化する ◦ 頻度が高いということは払う金利も大きい。金利を払う前に先に対応する。 • とにかく話し合う、エンジニア同士でも、エンジニアの職種を超えて、今いる人も前から居た人も新し く入った人も ◦ 未来は結局わからない。チーム全員の叡智を集める & 全員の納得度を高める。 = 今のチームの全速力 過去を理解し、尊重する • 努力を怠ったわけではなく、制約の中で精一杯のことをやっている • 十分な時間がなかっただけでなく、十分なスキルをもった人が居なかったこともある • 様々な苦難を乗り越えて事業として成立させたからこそ、今この開発がある
118. 技術的負債の認識を合わせる必要がある 技術的負債は感覚的なものである → 詳細化と目線合わせが大事 根拠：人の感覚によって負債であるかどうかが違う。能力差 x 課題感 = 課題感は 現状(状況 + 目標) - 未来への対応力(解決力) 技術的負債はスタートアップでは当たり前に存在するものである → 事業を優先するため、短期間の事業 状態を理解した技術な意思決定が大事 根拠：今目の前のことをやらなければ、会社の存続自体が難しい 普通の会社のプロジェクトの場合、お金の追加という手段があるがスタートアップには結果を出さなけれ ばその選択肢がない 技術的負債は変化するものである → 事業フェーズに合わせた経緯を説明し、フェーズの切り替わりでは 理解を促進して、敬意を持って対応することが大事 根拠：事業の状況によって、安全生存期間や目標の長くなることで価値の変化が起きる
119. 優先順が変わりやすい理由 - 優先順とバランス 優先順が極端でバランスが悪い 優先順でやれる個数が少なくてカツカツ • なので、少し変えると大きく方向が変わる 事業レベルで不確実性の高いことをやっている • 機能レベルでも不確実性の高いことにチャレンジする必要がある 会社を生かして事業続けるには、事業を優先せざるを得ない • システムや組織面での対応は後手になりがち
120. 時間軸の広がり 空間軸の広がり 個人とチーム 広がった側には 自分や過去が含まれる 具体と抽象 過去やシステムは具体的 未来や事業は抽象的 事業が抽象的なのは エンジニアとしてシステムに 落とし込むことを考えたときに遠いため 価値の発揮 = 価値の発揮タイミング x 価値発揮の継続的効果 = 価値発揮総量
121. 技術的負債に向き合うには 技術的負債は 理想の開発者体験 と 現実の開発 のギャップ 技術に対する 知識・認識・文化が必要 基本的な技術的な知識 認識を合わせて目線を揃える 維持対処の日常的行動規範 技術 認識 文化 学習の積み上げ 気づきでの切り替え 日常の熟成
122. 技術的負債に向き合う見積もり 実行推進のための見積もり 企画してくれる人はいない全てはエンジニアが行う （普通の機能開発はプロダクトマネージャやビジネスメンバーがキックオフしてくれる） 技術的負債の場合は、機能開発ではないので 下記の見積もりがオススメ • トップダウン • ３点見積もり • エキスパート判断 https://asana.com/ja/resources/estimation-methods
123. 技術的負債はシステムだけでなく広く捉えて深く実行する 技術の視点を変えていく 技術から事業まで広げる 具体と抽象を行き来する 組織として技術を見つめる 時間軸を過去と未来で見る 技術的負債の話は結局、システム開発のそのものをどう扱うかの話 図式にして絵で直感的に分かるようにする システム→組織→事業 という軸のサイクル 過去→現在→未来という軸とを表現する
124. スタートアップで考えるべき順番 売上がある or 追加でお金を出してもらう どちらか出来ないと会社がなくなる システムを作るだけでなく、事業を立ち上げる必要がある
125. 技術的負債と支払い金利と技術投資の複利 技術的負債はどんなシステムでもゼロになることはない スタートアップのシステムが抱える技術的負債が大きいという、大きさの違い どこまでがオーバーエンジニアリングなのかの判断が難しい 技術投資とは基本的に複利で得られる手間の削減を有効活用していくもの とくにモダンな開発プロセスでは当たり前になっている
126. 技術的負債に向き合う 良い技術負債は学びのための負債 良い技術負債は価値のための負債 悪い技術的負債は自分やチームで防げたはずの負債 技術的負債は０にはならず、緩やかに堆積する システムはチームで作るものだからこそ、チームの日常的な仕組みが重要
127. 大きなプロジェクトで対応するのではなく、日常化する。したい。 できないこともある。 技術的負債のリスクを細かく返済する
128. 以降、ボツスライド
129. SI系会社時代 (主にSESでの業務) • エンジニア (いま考えると、自分は事業を作っておらず、新規システムを作っていた) • 保険共済、交通網ICカード在庫管理、工場部品管理 などを新規構築 • Web系に近いところでは、 ◦ ソーシャルゲームアプリ ◦ ソーシャルコミュニティサービス • に関わっていました。どちらも現在はサービス終了 自己紹介 - 新規事業経験 (1/3)
130. 自己紹介 - 新規事業経験 (2/3) Web系会社時代 (初期) • スマートフォンゲーム広告配信システム エンジニア→のちに開発責任者 ◦ → 開発責任者になって程なくしてサービス クローズ • 動画広告配信システム 開発チーム立ち上げ開発責任者 ◦ → 一定の立ち上げ後、別開発へ異動。数年は事業継続したが、現在はサービス クローズ • 広告 DMP (Data Management Platform) 開発 (子会社) エンジニア →のちにCTO ◦ → 10人程度の組織から30人で３プロダクト組織に。別プロダクト開発へ異動。 現在は１プロダクトを残し、自分の関わっていたプロダクトはサービス クローズ • リアルタイム情報利用広告配信システム 開発チーム立ち上げ開発責任者 ◦ → サービス提供後、事業を伸ばせず クローズ
131. 自己紹介 - 新規事業経験 (3/3) Web系会社時代 (現在) • 薬局在庫管理システム → 開発ディレクター(スクラムマスター) のちにエンジニアリングマネージャ ◦ → 順調にサービスは成長中 　入社時の立ち上げ 5人チームから 現在は40人規模の開発組織へ ◦ 現在シリーズC (調達額94億円) まとめ • プロダクトの成長経験とスタートアップのお金の動きは現在の会社で 経験して理解した事が多いです。 • 逆に、サービスクローズの経験は何度も味わいました。。
132. 話の流れ - アイデア 自己紹介 スタートアップとは 技術的負債とは スタートアップで起こる変化　MVPとPMFとは ・フェーズにより価値観が変わる 理想が変わるから技術的負債も変わる ・技術的負債じゃなかったものが一気に負債となって襲いかかる 技術的負債と向き合うために必要なこと ・システムだけでなく事業も理解して作る。全ては短期と長期の価値の見極め。 ・システムを見極められるのはエンジニアだけなので、エンジニアが事業を理解するしか ない。事業者がエンジニアリングを理解してくれないと嘆くのは、エンジニアリングを伝え る変換がまだまだできていないだけ。 足りないものはたくさんある最初から満たされることはない。全てを抱えて僕等スタート アップは生きていく
133. 重りをつけたまま走っている 技術的負債とは重り。外した方が早く走れるが、止まって外すべきかを考える 重りをつけて走る 重りを外してから走る 重りを外す時間を取られると止まってしまうが、ない方が早く走れる 短期を見るか、中長期を見るかのロジカルな話。俯瞰して捉え、印象での判断をやめる。 変化が大きく、回数も多いという前提、変わらない部分と変わりやすい部分を見極める
134. 成功のために一歩ずつ進む 最初から全てが出来ることなどない 事業も組織も技術も全て （事業の成長、人材の不足、技術的負債） 足りないことが当たり前 会社の消滅と隣り合わせの状況では、これらの負が溜まりやすい 技術的負債だけでなく、 全てを抱えながら僕等はスタートアップの成功のために生きていく
135. 技術的負債の論者 ウォード・カニンガム • Wikiの発明者、XPの父の１人、ケント・ベックと共にパターンランゲージをソフトウェア開発に導入し ようとした人、アジャイルマニフェストの署名者の一人、技術的負債の考案者。 マーチン・ファウラー • オブジェクト指向設計、統一モデリング言語 (UML) 、アナリシスパターンをはじめとしたソフトウェア パターン、エクストリーム・プログラミング (XP) を含むアジャイルソフトウェア開発方法論の各分野で 活発に活動。アジャイルマニフェストの署名者の一人、依存性の注入（ Dependency injection）の用 語の発案者。 • 日本での書籍 ◦ リファクタリング―プログラムの体質改善テクニック ◦ エンタープライズアプリケーションアーキテクチャパターン ◦ など
136. 技術的負債の論者 フィリップ・クルーシュテン • ラショナル統一プロセス の書籍の著者 ジョン・オースターハウト • A Philosophy of Software Designの著者 (日本語訳書はない)
137. 内部品質はシステムの特性によって求めるレベルを変える システムの品質は画一的なものを求めているわけではない SoE SoR 他にSoIやSoCも SoRの構造はシッカリが大事。技術的な土台になる。変えるの大変。 SoEは発見が大事。柔軟に素早くを優先して検証する。少しずつ変えやすい。 長期で戦う可能性、変更コスト、結果の価値、複利の効果 = 技術的意思決定 時間軸 x 借金返済コスト x 事業的時間価値 x 金利 = 技術的負債の計画
138. 内部品質はシステムの特性によって求めるレベルを変える 構造なのか、振る舞いなのか SoRは構造に近い SoEは振る舞いに近い SoCは構造に近い SoIは構造から振る舞いまで層がある それぞれに違いはあるが、設計(design)の重要度や力点が変わる
139. 内部品質はシステムの特性によって求めるレベルを変える 変化が起こる前提での設計 小さく作る 捨てられるように作っておく 変化の影響が限定的になるように作っておく 未来の選択肢を広く取れる方法を選択する
140. 技術的負債の許容はどうするか 借金返済コスト は自然発生する 自然発生に対応しやすいアーキテクチャはある 金利 は相対的なもので、過去の状態と未来の状態の差によって決まる 理想を定義してから開発は始まるため、足りない状態から始まる 理想を達成しても次の理想はある 事業影響に合わせてどれだけ許容するかを考える
141. アーキテクチャの工夫で変化に強くする システムの品質は画一的なものを求めているわけではない ドメインを理解し分解しておく わからないことはあるので、直す前提 １つの棚に全部ぶち込んでも、物をしまうことができる。しかし、カテゴリごとにざっくり棚を分けてしまっておくだ けでも変更をしやすくなる ドメイン x 技術的レイヤー でのマトリックス的な構造 究極に整えるとマイクロサービスで、中間的なものがモジュラモノリス、 定義的には次はモノリスだが、アーキテクチャ次第で緩い整頓がされたアーキテクチャと何も整頓されていない アーキテクチャのモノリスは意味が違う。 ドメイン x 技術レイヤー を想定してフォルダ (パッケージ)分けする
142. 現状の不足と理想の思考 今目の前のことだけ、システムだけで決めていないか？ 以下の文について、左を考え、右の疑問を持つ 技術から事業まで広げる => 技術だけみて決めていないか？ 具体と抽象を行き来する => 個別の質が全体最適に繋がっているか？個別の質にこだ わっているか？ 組織として技術を見つめる => システムだけ見てないか？作る人も見ているか？ 時間軸を過去と未来で見る => 今の目標だけ見ていないか？経緯を理解し、理想を定 義出来ているか？
143. 技術的負債とは 技術的負債が増え続ける環境が辛いのは、理想とする開発環境から遠くなるから
144. アイデア 攻めと守りの2軸の組織構成になりやすい • １つのプロダクトに２つのアプローチが必要になるので難しい • お互いに様子をみながら少しずつ進む時間があれば問題ないが、基本的にお互い全速力で走る体制じゃないと時間 的に厳しい (基本的にぶつかり合いながら全速力で走る二人三脚 ) 現システムを開発しつつ新アーキテクチャにリプレイス • レガシーと呼んだりするが、技術的負債の溜まったシステム ◦ 経緯と敬意がなければハレーションが大きい。 ◦ レガシーや負債と呼ばれるメンバーの事を考えた、呼び名や取り組みがないとつらい気持ちになる。 • よくあるパターンでマイクロサービスでの置き換えを目指したりする ◦ めちゃくちゃ地雷がある 技術面でも成熟度の差が生まれやすい • 環境の差もあるが、求められた技術の差もある。初期は、人、物、金がないので来てくれるだけで感謝。 • だた、金が集まると人も強い人を採用する基準になる。なぜなら、解決すべき課題が複雑になっている上に、会社が 惹きつける魅力があがっているため (金(年収)、実績、安定性)。 • 課題の難しさの種類が変わる。難易度は単純に比較できるものではない
145. 技術的負債の過去と現在 技術的負債の経緯と敬意 技術的負債 = 技術的な課題全般 => 課題とは理想と現実のギャップ つまり エンジニアが安定的にシステム開発を実現するために 理想とするシステムの状態と現在のシステム状態との差分 (ギャップ) 要は欲しい開発者体験 (DX)との差分というと分かりやすい
146. スタートアップ前提で考えてみる エンジニアから見るとMECEじゃない気がするが？ 技術的課題のあるアーキテクチャや構造的な特徴はどう捉えればいいの？ 技術的負債はマイナス価値を発しているところは完全同意 プラスもマイナスも価値として影響してないところはどうなる？ エンジニアとしてはシンプルに 内部品質課題として向き合えば良さそうでは？ 外部品質はPdMがコスト対効果をジャッジする？
147. 技術はミルフィーユ構造 技術は基本的にミルフィーユ構造 このミルフィーユの層を深く理解しているほど、細かく層を作ることができるため、ハンドリングの チューニングがしやすい構造を作って、影響範囲をコントロールしやすい システムの深い話とシステムをはみ出した広い話がある 深い話はベーシックな技術や概念であるアーキテクチャがある 広い話は稼働システムと稼働システム周辺システムと組織と仕組み、そして事業 クリーンアーキテクチャ的な話はコードの中だけでなくモジュール的な話もあるので近いと感じる
148. 技術は事業や組織と一体である アーキテクチャとして、事業や組織を一体化する技術的考え方が出てきている • DDD (ドメイン駆動開発) ◦ 技術と事業の一体的に対応する技術 ◦ 事業というと少し広すぎるが、ユーザー業務と技術の一体化に加えて、運用周りも含めて DDDで設 計して運用することで、業務プロセスと技術のアーキテクチャを一体化させる • マイクロサービス 、モジュラモノリス ◦ 技術と組織の一体的に対応する技術 ◦ 組織を考慮せずに技術面だけで考えると失敗するアンチパターンになりうる • アジャイル、スクラム ◦ 技術、組織、事業で必要なコミュニケーションの循環をして開発が出来るようなプロセス ◦ システム開発組織の中だけでは本来の力半分 ◦ システムを作ることが目的ではなく価値の発揮やそのための文化やプロセスを作る
149. 技術のミルフィーユ構造により技術的負債の防護壁を作る ドメイン的な区切りを先に作っておくことで、変更の影響を分かりやすく出来る 全体を理解しなくても価値が発揮しやすいように、適度に区切ったドメイン範囲を定義す ることで価値を発揮しやすくする チームを適切に分けておくことで、必要なドメインと技術的観点をセットで理解できるよう にナレッジを平準化して、学びとコラボレーションを循環させる 土台としての柔軟なインフラ(AWSなどのクラウド技術) 組織づくりも考慮したプログラミング言語やフレームワークの選定 SoRやSoE的な観点での構造慎重さと実行の柔軟性のバランス
150. 変化に合わせて変えなければならないこと 組織が拡大するということは新しいメンバーも増える。 経緯を説明し納得性を高め、過去に敬意を持つ。 事業中心の意思決定になるため技術的負債が溜まりやすく、この変化対応も難しくして いる。 組織の文化を作る
151. 負債への対応とは技術的意思決定 未来を思考と試行をして、どれだけのことを想定しながら意思決定が出来るか その意思決定回数が圧倒的に多い これがスタートアップの面白さと大変さ エンジニアリングの視座を強制的に上げる必要がある 意思決定の回数が増えるので他の会社の１年の経験と全く密度が違う経験できる (可能性がある)
152. エンジニアの能力と成長のための環境と技術的意思決定 視野を広げることと深めることが必要 スタートアップの難しさは良い成長機会と取るか、大変な苦労と取るかはエンジニアとし てのフェーズによりそう。自分の転職と経験のステップと感覚が合うところもある。 キャリア的な話はまあまあ出来ると思う EM的な立場になってから10年くらい経つ
153. 株式会社カケハシ 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
154. 株式会社カケハシ 会社説明資料 SpkeakerDeck note 私たちが、専任のスクラムマスターにこだわる理由。開発組織の理想像とは？ https://blog.kakehashi.life/n/nfa5fcf5cec9f サービス開発チーム タグ https://blog.kakehashi.life/m/m7f8181d9a76b
155. 株式会社カケハシ イベント登壇やTechBlogの情報をお届けします！フォローお願いします！ https://twitter.com/kakehashiPR カケハシ主催のイベントなどの情報が届きます。メンバー登録お願いします！ https://kakehashi.connpass.com/ カケハシの説明資料や登壇資料などが登録されています。 https://speakerdeck.com/kakehashi