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