技術的負債が生まれる流れ
Technical debtこと、技術的負債は次のような流れで生まれると理解している。
- 事業に必要な検証を最速で行えるプログラムが書かれる
- 事業の検証がうまくいき、そのプログラムが価値を帯びる
- 事業の状態が変わり、プログラムの状態を事業に対して最適に追従させるべき差分が生じる。これが技術的負債となる なので負債は事業とプログラムの差分Δでもある、と捉えている。
この差分は負債と言われるだけあって、膨らみすぎると以下のリスクが有る。
- 利息として認知負荷がつく
- 認知負荷が増えるほど。開発速度および運用工数は指数関数的に低下する
- 利息が一定量に達すると破綻し、事業を進めるためのプログラムの推進が完全に停止する (bankrupt)
つまり事業に対して致命的なリスクとなる。
負債のコントロール
よって事業経営においては技術的負債とよばれるΔを適切に検知し、一定量を返済してΔをコントロールしなくてはいけない。そして事業を担うビジネスサイドの人を見ていて、一番欠落しやすいセンスがこれだと思っている。
Δを減らす方法は2つしかない。
- プログラム状態の変更を必要とする事業推進について速度を下げる
- 負債返済の速度をあげる
良いセールス、BizDevやプロダクトマネージャーとは、この2つのレバーを使いながらも、事業を成長させることができる存在である。
新規事業においては「Δを最小化しながら価値を見つけられる」 ≒ 「MVPとPMFを生み出せる人」なので結果的に同義で扱える。
逆に言うと、事業の成長に対して「プログラムの変更や開発のみを手段としてつかう存在」「負債返済のHowや難度に踏み込まずに、最終的なスケジュールだけで交渉してくる存在」などは、プログラムをコアに据えている事業においては一人前のビジネスパーソンとは言い難いだろう。
これを組織的に脱却する明快な方法は、まだ自分のなかにも答えがない。
※すべて私見です。
