事業・組織も変わらないと、システム開発は変われない
新田智啓氏：スタートアップで起こる変化というところでまず確認したいのが、スタートアップではない進め方の時には基本的に不確実性が低いというか、低くなるようになるべくアプローチする。開発物とかの目標があって、開発期間があって、「これができたら完成だ」みたいなところがわりと明確にあったりすることのほうが多いのかなと思います。
変わるとしても、無理なく緩やかに変わることが大事。なにかコンセンサスがあって、うまく変えられるみたいな。スタートアップはけっこう大きく変わることが前提なのかなと。不確実な事実が明らかになった瞬間に、大きな方向転換が起こると思っています。
なので、技術と組織と事業みたいな3つの関係があって、方向転換の中、技術の中だけで開発が進むわけではないと思っています。
ざっくりした考えですが、「技術」を使ってシステムが出来上がってくると、いろいろなユーザーに使ってもらって「事業」が成長して、「事業」が成長するともっといろいろな開発を進めたくなって「組織」やチームを拡大する。エンジニアを採用する。エンジニアを採用していくと、さらに技術でのアウトプットが増えてより多くのシステムの機能が作れるみたいな話ですね。
内部的な、少しエンジニア的な目線で考えた時に、稼働するシステムみたいなものと、そのシステムを維持するための仕組みシステムみたいなものがあると思うんですよね。これはたぶん外には見えていなくて、エンジニアにしか見えないシステムとして存在する。
それをさらに作るために、システムを維持するためのルールとか、システムを開発するためのプロセスだったり文化だったりが組織の中にあって、これらがあることによって初めてシステム作りみたいなものが順調にいくんだと思うんですよね。
なので、システム開発に必要なのは、動くシステムを作るだけじゃなくて、事業も組織も変わっていく。ここに追従していかないと、組織的なプロセスの負債だったりルールの負債、足りないものだったり、計画の立て方、目標の立て方、属人性、目線だったりにも対応しなきゃいけないのかなと思います。
普通の緩やかな変化だと自然に「足りないね」みたいな。「こうしよっか」みたいなものが思いつきますが、急激な変化だと、かなり意識的にしっかりそこにアプローチしていかないと間に合わないということをけっこう実感しています。
変化のスピード、拡大のスピードが速いとか、変化が大きいところで、パワーがかかるところもあるかなと。そこでチームが拡大しても、結果、作れるものが大きくならない、速くならないみたいなことも起きたりするかなと思っています。
あとは文化、組織、プロセス、システムというものが存在して。営業の人みたいにいきなり「明日からこう動いて」と言ったら動けるわけじゃなく、既存のものがある中で変わっていかなきゃいけないので、その既存の仕組みの慣性の力みたいなものにどうやって向き合っていくか、アプローチしていくかはすごく難しいなと感じています。
システムは開発チームによって作られるんですけど。技術的負債も1つの大事なテーマですが、変化の課題が一番見えるのが機能開発、継続的な開発。見える部分はそうだとしても、周辺のシステムみたいなところもちゃんと対応していかないといけないし、組織の変化にも対応していかないといけない。その中に技術的負債もあるのかなと思っています。これはけっこう同時に起きるので、大変かなと思います。
もともとシステムの中に負債はあったのですけど、今回は解消されることによって価値があることを「負債」と呼んでいるので、価値の変化があると負債が増えます。
スタートアップが“変わる”4つのフェーズと、その変化から感じること
スタートアップにはいつでも変わるタイミングがありますが、大きく変わるタイミングがあるなと僕は感じています。プロダクトを作る時、だいたいフェーズが6つとか7つあるんですが、その中から開発で大きく影響があるものを今日は4つ挙げています。
MVP、PMF、GTM（Go To Market）とGrowthというかたちになっています。（スライドを示して）特に変化が大きいのが、左の2つですね。MVPはなるべくシステムを作らずに価値を検証するということ、PMFは価値をプロダクトで実現する方法を最小コストで探るということですね。ここのフェーズの変化みたいなもので、開発組織としても向き合わなければならないものが大きく変わると思っています。
このフェーズの変化から感じることを例にするために、ちょっとだけ環境の絵を描きます。いきなりファンタジーなんですが、ドラゴンと戦っています。腕に大きな怪我をしていて「どうしますか？」となった時に……。腕にすごく大きな怪我であっても、命の危険があったら戦うしかないわけですよね。ドラゴンを倒すためになんとかしようと思うわけです。
では違う場面です。質問は同じです。腕に大きな怪我をしている。「どうする？」といった時に……。いきなり満員電車みたいな絵でちょっと辛い気持ちになるんですが。ここに大きな怪我をしている人がいたらどう思うかというと、「なんでこんなふうになっているんだ？」と思うんですよね。「何が起こったんだ？ 大丈夫か!?」みたいな。
まったく同じ質問で同じ状況なのに、環境が違うとまったく違う印象を受けるということがあるかなと思います。
これはちょっと極端な例ですが、環境によって理想状態が変わり、差分が大きくなって技術的負債と感じるものが大きくなることがあるんじゃないかなと思いました。
先ほどのフェーズですね。MVPとかPMFとか、そのフェーズごとに大事なこと。優先度とか関心度の変化みたいなものがあるのかなと思います。MVPだとアイデアの実現、「本当にこれが活きるのかどうなのか」の検証みたいなところですね。バグとかが多少あっても「価値の検証が大事なのでしょうがないよね」みたいなところがあります。
（フェーズが次に移ってPMFの）プロダクトでの価値検証というところでは、機能開発のスピードを最優先しなければなりません。バグも品質も前よりは少し高めていかなければいけない。人数も増えてきて、もしかしたら阿吽の呼吸みたいなところよりは、ちゃんと説明するとか、プロセスみたいなものが必要になります。
さらにフェーズが進むと次にGTMですね。Go To Marketでスケーラビリティを求めるプロダクトの導入みたいなものになった時には、バグの影響が大きくなって、品質とか、システムへの期待みたいなものがすごく高まるわけですよね。なので、探索的なアイデアを探ってきた前のフェーズとはまったく違う価値観に変わるというのが、タイミングとしてあるのかなと思います。
たぶん、スタートアップによってはPMFがすごく早く終わって、GTMを速めにがんばるみたいなフェーズの会社さんもあるのかなと思います。PMFを越えるまでに苦労すると、ここの組織の変化はすごく大きく感じるのかなと思います。
フェーズ変化による価値観の変化によって、技術的負債が掘り起こされる
フェーズが変わったりすると、新しい価値観で見た技術的負債が掘り起こされたりして、開発側の中だと事業への価値提供みたいなものがわかっているものの、事業側から見た時には価値提供の停滞みたいなものが起きている（ということになる）んじゃないかと。でも「それ（技術的負債があること）は知っていた」という気持ちなんですね。開発の責任者はそれがあると知っていた。ただ優先順が違ったという、それだけだと思います。
フェーズが変わった時の状況は、会計のバランスシート的なイメージで、事業として必要なシステムと理想状態。エンジニアが求める理想状態を現状のシステム状態、そして技術的負債みたいなところ。で、事業として必要なシステム状態をなんとかカバーしているみたいな。それが価値の転換があると、事業として必要なシステムが大きく伸びます。
機能開発の予定は入るんですが、実は技術的負債という見えないものも増えていると感じているんじゃないか。これは自分の感覚値のものですね。ということで変化によって起きたのが、この技術的負債の主な理由になります。
防げた技術的負債はあったのか？
次に最後の項目ですが、技術的負債に向き合うために必要なこと。スタートアップは事業が軌道に乗るまで人を増やすことが難しいとか、継続的な機能開発が求められるとかがあって。プロダクトがPMFを模索したり、ユーザーが増えることで品質問題みたいなものが顕在化したりしますが、優先するべきは機能リリースだということになる。
よく「技術的負債には手が回らない」みたいになるんですが、ここに向き合っていきたい。
今回話すことで向き合うんですが、対策・対応方法（を紹介するわけ）ではないというところで、ロジカルというよりはエモだと思ってください。
防げた技術的負債はあったのか。人もいない、時間もない、お金もない、制約的なところもいっぱいある。
マーティン・ファウラーの4象限みたいなところで、無謀で意図的みたいな、設計に割く時間がない。そうです。ないです。慎重で意図的にリリースを優先するけど、結果にもしっかり対応します。そうです。やるしかないです。
無謀で無自覚、レイヤー化って何？ みたいな。エンジニアリングみたいな知識、経験がある人がいないこともある。良いエンジニアが揃っているわけじゃないし、雇うお金もない。慎重で無自覚。過去に遡って今だからわかる手段もあった。未来だったらわかるけど、それを経験したからわかった。知らないことだらけのところで新しい価値を作ろうとしているんです。
というところで、スタートアップは不確実性が高い中で新しい価値を模索しているのかなと思うので、満たされるまでは技術的負債は生まれ続けてしまうのかなと。マーティン・ファウラーのどんなカテゴリであっても、一定は生まれ続けてしまうのかなと思います。
なので、技術的負債は誰かが悪いわけじゃなくて、当時の状況の中で精一杯やった結果である。むしろ事業を成長させてここまで来たからこそ、この課題にぶつかっている。過去のエンジニアの汗と血と涙に敬意を持ちながら、今の課題に粛々と対応するべきなのかなと思います。なので、人を憎まず、技術的負債も憎まず、感謝していこう。
「過去・現在・未来」「システム・プロダクト・事業」を広く確認する
「過去に向き合うことはわかった」と。「じゃあ未来に進むために多くのことを決める必要があるんだな」と思います。
システムの立ち上げはプロダクトとか事業とかでレイヤーがあるのかなと思っています。技術の話では、ここだけを見れば意思決定できることもありますが、スタートアップだと全体を見ないと意思決定できないことがあるのかなと思います。僕もSIerの時代はシステムしか見ていなかったんですが、スタートアップになってくると、レイヤーで広く考えてシステムのことを意思決定しないとマッチしないなと思います。
なので、技術だけで考えても納得できない意思決定に感じちゃうこともすごくあるのかなと思います。なので、エンジニアに理解してもらいたいのは、過去・現在・未来のすべてだと思うので、技術的負債の経緯の過去の経緯と敬意に対して、「事業をしっかり継続させてきたんだ」みたいなところをちゃんと伝えられるといいのかなと。
「必要なのは今のシステム」みたいな目の前のスコープだけじゃなくて、広く、過去・現在・未来のシステム・プロダクト・事業を広く確認することだったり、伝えていくというのが大事なのかなと思います。
未来を話すためのDisagree and Commitみたいな、そういうことが大事なのかなと思っています。すべてを伝えきれるわけじゃないので、「ここってどうなっているの？」「これっておかしくない？」という意見から過去の経緯を説明したり、未来の目標をちゃんと伝えたりが大事かなと思います。
「抱えた負」を伝え合って理解する。技術的負債に向き合って対応することが大事かなと思います。
時間がないのでちょっと飛ばします。技術的負債は中長期の話でしっかりと考えなきゃいけない。必要以上に短期に見積もると弊害が起きるので、開発文化、感性があるとか、中長期みたいなところのバランスを見て進める必要はあると思います。ちょっとこのあたりは飛ばすので、あとで資料を見てください（笑）。
（スライドを示して）このページがこのセクションの結論です。広い視点と深い視点の両方ができたらいいなと思います。技術的なところも、深いところ……。実作業とか機能だけじゃなくて、マインドシェアだったり認知負荷だったり、理想だったり、そういうちょっとふわっとしたものも認識を合わせるのも大事かと思います。
どう向き合うかというと、事業や組織、技術というところで、いろいろなものがありますが、どの技術的負債が生まれる前でも後でも向き合って、一歩ずつ進むことが大事かと思います。
必要なのは広さ・深さ・バランス
ということでまとめのページで、必要なのは広さ、深さ、バランスみたいなところです。技術的負債は雑にコードを書いたものではない、ベストを尽くした上で発生したもの。少し未来を見ながらコードを書く。そしてスタートアップというのは、ヒト・モノ・カネが不足していて、変化も大きく、スピードも速く、技術的負債が生まれやすい環境。
その中で、広い視点や深い視点のバランスをとる必要がある。
そして技術的負債というのはそもそもある前提で、責める必要はない。それを悲観するんじゃなくて、「なぜ生まれたか」「どう向き合うか」みたいな。現在の状況だけじゃなくて「過去のこういうことがあって、これを乗り越えるためにこうなっている」。
今が良いわけじゃなくて「未来はこうしたいんだ」「こうすると、より良いよね」みたいなものを伝え合うのが大事なのかなと思うので、システムだけでなく、組織とか文化とかも大事なんじゃないかと思います。
ということで、このページが最後です。CfPにあったこの選択肢に困ったんですが、あらためて、全部チェックしないと技術的負債には向き合えないかなと、この資料を作り終わって思いました。
ご清聴ありがとうございました。
続きで、アイデアスライドみたいなものがこのあとに50ページぐらいあって、伝えきれなかった技術の話とか「プロジェクトマネジメントはこれがいいんじゃないか」とか、そういうのがいろいろ載っています。アイデアレベルなので文脈から読み取れるかわからないですが、そのままアップロードするので興味があれば見てみてください。ありがとうございました。
