スタートアップの開発における技術的負債との向き合い方
スタートアップの開発では技術的負債がたまりやすい、というのはよく聞く話だと思います。
この記事では、実際にスタートアップで開発をしている身として、どのように技術的負債を捉えて向き合っているかを書いていこうと思います。
技術的負債の意味
少し前にtwadaさんの翻訳記事で話題になったのでご存知の方も多いかと思いますが開発における「技術的負債」という言葉が指す意味には二つあります。
- システムの設計がサービスを提供するドメインの実態と乖離していること
- システムの実装が不適切で保守性などの品質が損なわれていること
よく知られているのは後者の方だと思いますが、もともとの意味としては前者の方だそうです。僕もtwadaさんの記事を読むまでは後者の意味しか知りませんでした。前者は、Ward Cunninghamが発明した「負債のメタファー」という考え方に由来しています。
これらはそれぞれ向き合わなければならない問題です。前者がビジネスの生死に関わる重要な問題であることはいうまでもありません。一方、前者の問題だけを気にして雑な実装を繰り返せば後者の問題が積み上がっていき、やがて前者の問題の原因にもなってしまいます。
プロダクトの進化のための負債
スタートアップにとって、先述の二つの負債はとても身近なものです。「負債のメタファー」はプロダクトの方向性を定めるための手段として必要なものであり、「品質低下」は変化の激しい開発の結果として生まれてしまうものです。
多くの場合、スタートアップの開発ではプロダクトの方向性自体が不完全な状態です。これは、ユーザの潜在ニーズとプロダクトの提供価値がマッチしていないということです。よく、PMF(Product/market fit) していないと言います。
PMF前のプロダクトにとって最も重要な開発とは、この方向性を探ることです。方向性を探るには、形にしたものをユーザにあててみるのが一番です。つまり、Wardがいうところの負債を使って、プロダクトのあるべき方向性を探りにいきます。
このとき大事なのは、不完全な状態でも臆せず出してみることです。全く考えなしでは話になりませんが、ユーザがついたのなら、プロダクトの掲げる価値には意味があるということです（実際ユーザに届くかはさておき）。それを確実にユーザに届けるためのプロダクトを作り上げるには、ひたすら試すしかありません。
ところが、この結果として、システムのあちこちに歪みが生じがちであることも確かです。ユーザの声から得られた学びをプロダクトに反映するためには、リリースサイクルを速く回す必要があります。
当然、毎回そのときのベストを尽くしはします。しかし、変更が多いというのはそれだけで歪みを生むものです。あるとき素晴らしい作りだったものが、他の変更などを経て全くベストではなくなっているということは珍しくありません。
負債とうまく付き合う
大事なのは、負債が全くないということではありません。どう付き合うかです。
プロダクト開発はあくまでユーザに価値を届けるための行いです。負債もまた、その手段の一つとして捉えれば、うまく活用していくことができます。
スタートアップに限ったことではないですが、余程体力のある大企業でもなければ使える開発リソースには限界があります。ユーザの価値を最大化するために、どこにどれくらいリソースが投下できるかわかれば、付き合っていく上でのアクションもより明確になります。
「負債のメタファー」ではそもそも負債自体を学びを得るための手段として用いています。最終的に得られた学びをシステムに反映していくことができれば、自ずと負債は返済できます。
注意しなくてはいけないのは、中途半端にゴミを残さないようにするということです。プロダクトの方向性を探る場合、大きな変更が必要とされることが多々あります。下手に汎用的に作ることを考えず、「違う」となったら全て捨てられるようにしておくのも安全策の一つです。
「品質低下」についてはどうでしょう。先に書いた通り、ある時に素晴らしい作りだったものが、気付いたら全くそうではなくなっていたということは往々にしてあります。これは成長過程におきる現象なので受け入れる他ありませんが、定期的なコードやアーキテクチャの見直しは絶対に必要です。
生まれた歪みを片端から潰したとして、ユーザに提供できる価値自体が増えることはありません。しかし、完全に放置してしまえば、やがて開発効率を脅かしユーザ価値を大きく損ねることになってしまうからです。
また、適切な周期でコードやアーキテクチャを見直すことは、開発効率の改善にも寄与します。
プロダクトの開発が進むうちに、変化が激しい中でも徐々にあまり変更されない部分や、共通する部分が出てきます。これらはプロダクトが進化する過程でシステムの中に「定着してきた」部分であり、今後も残り続けたり、汎用的に使われたりする部分です。これらを良い状態に保つことで、後続の開発でのコストを抑えつつ、品質を担保することができるようになります。
結びに
個人的にはWardの「負債のメタファー」はとてもしっくりきて好ましく思っています。
システムとは何かしらの目的を実現するための手段です。プロダクト開発においては、ユーザにより大きな価値を提供することが目的です。しかし、何がユーザにとって良いことなのかは「やってみないとわからない」ことが大半です。むしろやってみてわかるなら御の字です。
特にPMF前のプロダクト開発では、ドメインの複雑性に真正面から立ち向かうことになります。僕たちのチームも、まさにいまその真っ只中にいるところです。不完全な理解であってもなるべく早く形にし、ユーザからフィードバックをもらうことが、プロダクトを進化させていく上での生命線です。
一方で、品質低下も見逃すことはできませんが、これはエンジニアの腕の見せどころです。どんなに変化の激しい開発であっても、未来のユーザ価値を損ねないよう、プロダクトの進化を支えるのもまた僕たちの仕事です。
負債のメタファーを知っていることで、僕たちは不完全さに躊躇することなくプロダクトをリリースできます。そして、その不完全さからどのように学びを得て、プロダクトを進化させればいいのかを考えることができます。不完全さが前提であるスタートアップの開発にとって、負債は非常に心強い味方なのです。
Discussion