スタートアップは技術的負債をどう返済するか　カミナシCTO・原トリ氏が語る試行錯誤の第一歩

カミナシにおける技術的負債の事例を紹介

西村賢氏（以下、西村）：みなさんこんにちは。今日のテーマは技術的負債ですが、抽象的な一般的な話というよりは、1つの事例として聞ければなというところがあって。

技術的負債がどう溜まるかって、経路依存というか、どういうチームでスタートするかとか、例えばめちゃくちゃテクノロジーに強いエンジニアが始めた会社と、ビジネス系のファウンダーが始めて最初は外注していましたという会社だと、（後半の会社は）いかにも技術的負債が溜まりそうですが、そういう意味ではいろいろ違うところがあると思います。

今回のケースは、勢いがあって、マーケット的にはプルがあるようなところでプロダクトが伸びていたカミナシというところで。途中からCTOとして入って、「あっ、これはけっこう技術的負債、立ち向かわなければな」というところで。

「これを試したらちょっと、んっ？」「これを試したらうまくいった」「これはなかなか難しいところがある」「よくよく考えたらこういうところがうまくいく」というようなラーニングみたいなところを、タイムラインに沿って追体験できればなと思っています。

各フェーズごとにそれぞれたぶん学びがあるので、来ていただいている方、あるいは「YouTube」見ていただいている方の参考になればなと思っています。原トリさん、今日はよろしくお願いいたします。

原トリ氏（以下、原）：よろしくお願いします。

ピボットを経てPMFを達成

西村：まず、そもそもコンテクストとしてカミナシが何をやっていて、どういう特徴があるかを簡単にご紹介いただけますか？

原：カミナシは、たぶん創業からは、もう7年、6年ぐらい経っているんですが、けっこうピボットを繰り返していまして。

シリーズAもBも調達するまでに導いてくれたのは、現行のプロダクトですね。それを作り始める前のタイミングは、あと半年ぐらいでキャッシュが終わるという状態で、社長がピボットを意思決定して、辞めていった人もいれば残った人もいて、その残った人でガッと半年かけて作ったプロダクトが支持を得て。

「あっ、これ、PMFしたんじゃないか？」みたいになって、シリーズA、調達、B、調達につながっていったという。

西村：我々、株主・投資家なので見ていたんですが、グラフで見るともう本当にピボットで、もう、「あらっ？」というぐらいの、本当に、「あっ、PMFってこういうことだな」というぐらいわかりやすかったですね。

原：そうです、そうです。PMFをする前のプロダクトは残ってはいて。今いつでしたっけ？　（スライドを示して）今ここですよね。ピボット前のプロダクトのお客さんがまだ何社か残っていて、それのシャットダウンがちょうど先月8月末（2023年8月）で終わったという。

西村：なるほど、役割を終えた。

原：終わりました。お葬式をですね（笑）。諸岡（諸岡裕人氏）という創業者がいるんですけど、彼から温かい言葉もプロダクトに送ってもらって、最後、マシンとかを全部シャットダウンして。

西村：なんか、針供養みたいな世界ですね（笑）。今まで、プロダクトありがとうと。

原：そうですね、今までもかなり明るく……社内でシャットダウンしていく様子を全部ライブ配信していたんですけど。

西村：諸岡さんがボタンを押したりはしなかったんですか（笑）？

原：しなかったです。初期からそれを作ってきたエンジニアが、最後シャットダウンの作業までやれて。

西村：じゃあ、最後にインスタンスを消すところをみんなで。

原：そうです。その2週間後ぐらいに、お客さんから「あの時のデータのバックアップが欲しいんですけど」と言われて、「すみません」っていうのを、今コミュニケーションしている。

技術的負債がプロダクトの足かせになった

原：カミナシは、非常にSales Led Growthな会社ですね。お客さんはセルフサインアップできなくて、全部営業と会話をするところから始まって、売れたら今度はCSが入っていって、オンボーディングしてっていう。

Product-Led Growthの匂いはかけらもなくて、セールスやビジネスサイドがずっと会社を引っ張ってきました。なので、3ヶ月間だけいた業務委託の人が1人で「オラァ！」って作った機能。プルリクのディスクリプションに「作った」って書いてあって、レビューなしでマージされているみたいな。

西村：（笑）。しかもデカいみたいな。

原：はい、デカい。Changesのところに百八十なんとかとか書いてあるようなものが、もうカジュアルにずっと行われてきていたけれど、新しいものを横に生やしていくかたちで、1個のプロダクトの中に機能を作っていっていたので。

たぶんエンジニアリングバックグラウンドがある人であれば、スキルがなくても、うまく設計していなくても、横にアプリケーションの機能を生やしていくだけであれば走れるというので、2年ぐらい走ってきて、「あかん」ってなってCTOを探し始めて、僕が4月に入社したっていう感じですね（笑）。

なので、2021年どうなっていたかというと、手を入れると不具合が発生する。大きな機能開発のアイテムはぜんぜん進まずに、いつになったら終わるかも誰も言えないような状態で、わりとCS、セールスとエンジニアリングの間の空気が、こう……。

西村：よどんでいたと……言っちゃいました（笑）。

原：よどんでいた状態ですね。

西村：そこに入っていったと。

原：はい……入っていったという感じのコンテクストですかね。

西村：でも、エンジニア正社員5名ということは、外部委託もけっこうその間たくさんいた。

原：そうです。この時は業務委託の人のほうが多かったですね。稼働が不安定な人もたくさんいた状態かな。週に2時間だけ動いている人がいたりしたので、スクラムというモデルでやっていたけど、ぜんぜんスクラムしていなかったですね。

西村：バラバラに開発して。アーキテクチャ的にはどうなんですか？　例えばデータベースの正規化とか。

原：いわゆるWeb三層ですね。

西村：Web三層、はい。

原：データベースがあって、その手前にAPIサーバーがあって、クライアントは、Webアプリとモバイルアプリという。

西村：じゃあ、別にフラグメントということではないですね。

原：ぜんぜん、ぜんぜん。もう、なんて言うんでしょう、屈強なモノリス。

西村：あっ、モノリスで。なるほど、なるほど。

原：そうですね。システムアーキテクチャはぜんぜん変えていない。作った当時から変えていない感じですね。

西村：なるほど、わかりました。

フワッとしたペインをみんなが感じていた

西村：そして、入っていって最初にやろうとしたのが、とりあえず負債を返そうじゃないかと。

原：最初は状況を理解しようと思って。

西村：はいはい。

原：まず、下から見ていこうと思って。「AWSアカウントのアクセスください」と言ったら、AdministratorAccessという、一番強いIAMユーザーが送られてきて。なるほどっていう。なるほど、なるほどと。

西村：ビジネス系のファウンダーも見ているので喩えて言えば、アカウントが強力すぎるんですかね？

原：そうですね。会社の銀行口座の詳細な情報を暗証番号付きで全部、全従業員に共有していると思ってもらえればいいかもしれないですね。

西村：誰でも吹っ飛ばそうと思ったら吹っ飛ばせちゃうみたいなね（笑）。

原：そうです、そうです。退職者も攻撃しようと思えばいつでも攻撃できるみたいな。

西村：時々ありますもんね。退職して恨んだエンジニアが鍵を持っていって、脅かされるみたいな。

原：データ抜き出してインターネットにばらまく。

西村：本当に恐ろしい話を聞きますけどね。

原：なので、動きは速いんですよね。権限を絞っていないから。

西村：まぁ、そうですね。誰でもなんでもできる。

原：なんでも触れるんですけど、中身を見たら、「あれまぁ」っていう。何ですかね、ちょっと喩えるジョークが思いつかないんですけど。

西村：ちなみに、入る前にも当然想定はしていたと思うんですけど。

原：そうだろうなと思って入った。

西村：なるほど。

原：アプリケーションも先ほど言ったとおり、流しの業務委託エンジニアが、クソデカいプルリクをノールックマージしている感じなので、予想どおりというか。エンジニアリングはみんなそこにペインを抱えていて、「これが、変えていいのかわからん」とか。

その前の年から、ユニットテストを増やすとか、ちょっとずつがんばってきていたんですが、例えば、「そもそも仕様がわからん」みたいな。明文化された仕様の定義がないから、いじったら、「前までやっていたことができなくなった」とお客さんから文句言われたり。

西村：なるほど。

原：状況としてはそういう感じ。

西村：仕様もテストもないと、コードにしかなくて、コードの挙動もわからないというか。

原：コードも似た操作のところをまるっとコピーしてちょっと書き換えて作るみたいな。

西村：そうしたらこっちが壊れるとかね。リグレッションとかありますもんね。

原：そういうのがいっぱいある状態で。みんな思い思いにデータベースの設計……「データベースがとにかく良くない」と言ってみたり、「アプリケーションコードがどうこう」と言ってみたり。フワッとしたペインをみんなが（感じていた）。

西村：みんな違和感はあったんですね。

原：そうですね。

西村：なぜかうまくいっていなくて、スピードが落ちていると。

機能開発を完全に停止した

原：5月頃に機能開発を完全に止めて、「一回リファクタリングしますよ」というのを社内にアナウンスする前に、「何が課題で、それを片づけたらどうなるのかを一回言語化しましょうか？」というのをエンジニアリングとやりました。

「これがペインだ」と、ある程度アクション可能なレベルまできちん掘り下げることができたので、全社の集会で、そもそも技術的負債って何か、みたいな話とか（しました）。

ただ、その大きな技術的負債を片づける経験がない会社で、いきなりビジネスロジックに手を入れると、先ほど言ったとおり仕様もわからんし、正解がわからんので、大きなボールに手をつけられない状態ではあったので、まずは、ビジネスロジックを触らないリファクタリング。

例えばAPIサーバーのコードベースはクリーンアーキテクチャなるものを意識したんだろうなという空気を感じられるパッケージ構造に……Goなんですけど、カミナシはなっていて、そんな複雑なレイヤー要らんでしょっていうぐらい、形を重視しすぎていて変に複雑になっている。

その結果、なぜその構成になっているかという意図が後から入ってきた人はわからないので、本来そこに書くべきじゃないロジックがそこに書いてあるみたいなことが起きていて。

意図が誰もわからんとなっていたので、今必要なレベルにシンプリファイしましょうというのをここでやったんですね、1ヶ月ぐらいかけて。

西村：なるほど、なるほど。

技術負債について理解をしてもらえたことに1番の価値があった

原：ただ、今思えば一番価値があったのは、全社に向けてシステムというのは、作って終わりじゃなくて……。

西村：負債というものが溜まっていくもんですよと。

原：はい。3年前に考えていたことと今では状況が違うので、3年前は正解でも、過去に作ったものは何もしなくてもほっといたら間違いになっていく。というのがSaaSみたいな継続的な開発をしている世界だからという話を、『ハウルの動く城』とかの画像を使いながら、いろいろな比喩を交えて説明して理解してもらえたという。

なので、作ったら終わりじゃない、みたいなのを、たぶんカミナシの中で初めて全社に向けてしゃべったというのが、今思えば一番価値があったかなと（笑）。

西村：なるほど、なるほど。ビジネス系も含めてきちんとそこの価値を理解していただいたと。

原：そうですね。スタートアップってスピードが大事じゃないですか。

西村：うん、大事ですね。

原：でも、スピードを出そうとした時に、雑に作ればいいかというと、雑に作ると、無意識のうちに未来をめちゃめちゃトレードオフにしているんだという。

西村：なるほど、まさに負債ですよね。前借りしているんですよね。

原：そうですね、はい。

西村：結局クリーンにいかなきゃいけないんだけど、多少ダーティにいけば早いみたいな。

原：そうです、そうです。

西村：ハックってちょっとそういうところがありますもんね。

原：はい。本来はスキルがあれば、質とスピードを犠牲にせずに取り組めるんですけど、そんなエンジニアばかりじゃないし、自分自身、「じゃあ、やれるか？」と言われると、たぶんそんなことはなくて。

一定想定しきれなかったものが未来に出てくるので、「前借り借金しているので返さなきゃいけないんですよ」という話ができたのが機能したのかな。

西村：今回のテーマは技術的負債なのでちょっとずれるかもしれませんが、トレンドを入れすぎる。そんな複雑なものじゃなくて、普通にシンプルにスッと書けばいいのに。

それこそマイクロサービスもそうだし、クリーンアーキテクチャとか、オブジェクト指向もちょっとそういうところがあったかなと思うんですけど（笑）、それでGoに戻ったみたいなのがちょっとあるのかなというのが僕の認識なんですが、そういう構図ってありますよね。

原：そうですね。クリーンアーキテクチャの思想自体はすばらしいんですが、なぜそれを選択したかという背景が残っていない。当時それを決めた人の気持ちとか会社に残っていない。

西村：なるほど。

原：どう伸ばしていこうと思っているのかというところもDocに残っていないので、後から引き継いだ人は、やはり意図がわからない。

そうすると、やはり愚直に取り組める設計のほうがシンプルになっているのでやりやすいはやりやすいんですよね。なので、自分たちのレベルに合ったアーキテクチャを選ぶという感じですかね。

西村：なるほど。わかりました。

（次回へつづく）