急成長スタートアップと15年以上続くサービスで事業成長を支える技術的負債への向き合い方 / 開発生産性Conference 2024

2024年6月28日、ファインディ株式会社が主催するイベント「開発生産性Conference 2024」が、開催されました。本記事では、FastLabel株式会社とGMOペパボ株式会社によるセッション「急成長スタートアップと15年以上続くサービスで事業成長を支える技術的負債への向き合い方」の内容をお届けします。

本セッションには、FastLabel株式会社からエンジニアリングマネージャーの風見亮さん、リードエンジニアの爲西貴大さん、GMOペパボ株式会社から技術責任者の高橋健一さんが登壇。ファインディ株式会社プロダクト開発部SREの下司宜治がモデレーターを務め、パネルディスカッション形式で進行されました。

■登壇者プロフィール 風見亮（かざみりょう）
FastLabel株式会社 Engineering Manager @FlKazami
慶應義塾大学卒業後、ワークスアプリケーションズで大規模な会計・生産管理システム開発に携わる。 FastLabelの創業期から参加し、混沌とした初期ステージを乗り越えた。現在は開発部門の責任者を務めると共に、エンジニアリングマネージャーとして複数の開発チームのマネジメントを行っている。

爲西貴大（ためにしたかひろ）
FastLabel株式会社 Lead Engineer @ttarkkaru922
九州大学で量子力学を専攻。FastLabelに4人目のエンジニアとして新卒入社。フルスタックエンジニアとしてインフラ含む全ての領域での開発に従事し、現在はAI開発におけるMLOpsプロダクト全般の開発を担当。高品質なプロダクトを迅速に提供できる開発生産性の高い組織を主導。

高橋健一（たかはしけんいち）
GMOペパボ株式会社技術責任者 @kenchan
2014年9月、GMOペパボ株式会社に入社。技術基盤チームにて複数のサービスの技術的課題解決に従事。2016年9月にはEC事業部のチーフテクニカルリードに就任し、データベースサーバのRDS移行など、サービスの可用性向上のための技術課題に取り組む。2022年9月にはエンジニア組織全体のマネジメントを担う技術責任者を兼務し、開発組織の生産性向上と技術プレゼンスの向上を担う。

■モデレータープロフィール 下司宜治（げしよしはる）
ファインディ株式会社プロダクト開発部 SRE
新卒でヤフーに入社。2、3度の転職を経ながらサーバーサイドやSRE領域を担当。アンドパッドでは、VPoEとして採用・組織づくり・技術的負債の改善からSRE、CRE、QA領域などプラットフォーム部分を担当。2024年4月にファインディへジョイン。ファインディでは入社後よりSREなどのプラットフォーム領域を担当。

FastLabelとGMOペパボ、各社における技術的負債の事例

下司：本日のアジェンダとしては、登壇者ご紹介の後、各社からそれぞれ抱えていた技術的負債についてお話しいただきます。そして、その後パネルディスカッションをさせていただければと思います。では、まず初めに登壇者の皆様からご挨拶をお願いします。

風見： FastLabel株式会社でエンジニアリングマネージャーをしている、風見と申します。私は去年も登壇させていただいたんですけど、ずっとテーマとしては皆さんとつらみを分かち合うというところがあると思っていますので、学びのある楽しい時間になればいいなと思います。よろしくお願いいたします。

爲西：FastLabel株式会社でリードエンジニアを務めている、爲西と言います。FastLabelに4人目のエンジニアとして新卒で入社し、これまで3年弱フルスタックのエンジニアとして開発に携わってきました。今はAI開発におけるMLOpsプロダクトを中心に開発しており、高品質なプロダクトを迅速に提供できる開発生産性の高い組織を主導しています。本日はどうぞよろしくお願いします。

高橋：GMOペパボ株式会社で技術責任者をしている、高橋と申します。インターネットでは、kenchanというIDでやっています。私は今ペパボ10年目くらいなんですが、5年目くらいのときに会社として部門のエンジニアリングマネージャーをつくっていく動きがあり、そこで初めてマネジメント領域の仕事を始めました。

2022年からは、全社の技術責任者として全体のエンジニアリングマネジメントを担っています。本日は技術的負債がテーマということで、長くやっているサービスのつらみについて、私の目から見えているものをお話しできたらと思っています。よろしくお願いします。

下司：本日はこの3名に加え、モデレーターの下司が進行させていただきます。よろしくお願いします。では、各社の技術的負債の事例をご紹介いただきたいと思います。FastLabelさんからお願いします。

風見：負債の話に入る前に、まずは簡単に会社や事業の紹介からさせていただきます。我々は、「AIインフラを創造し、日本を再び『世界レベル』へ」というパーパスを掲げて活動しているスタートアップのベンチャー企業です。現在シリーズBで、従業員が正社員62名、トータル82名という規模です。

2つの事業を展開しており、1つはデータの質を重視したAI開発ができるオールインワンのプラットフォーム。もう1つは、データ収集やアノテーション、モデル開発などの代行サービスです。これらを両軸で展開していて、我々はこれをサービス駆動開発と呼んでいます。

アプリ開発からすると、社内に最初のお客様がいるようなイメージで、このフィードバックループが上手く回っているところが事業の特徴です。続いて、具体的な技術的負債の背景について、爲西の方からお話しします。

爲西：私の方から、急成長しているスタートアップとして、どのような背景があって技術的負債を抱えたのかについて説明します。まず最初のシード期は、とにかく売り上げを上げようという時期でした。

開発組織も4人くらいで一定の統制が取れていて、ひたすらソースを書いてどんどん機能リリースをしていました。このころ、技術的負債について薄っすら感じてはいたのですが、それよりは売り上げを上げようということで、技術的負債が話題に上がることは少なかったです。

シリーズAからは、売り上げだけでなく組織やアプリケーションのスケールについて考え始めました。いろいろなモジュールが増えてきて、シニアエンジニアが感じる負荷や技術的負債が高まっている状態でした。

その後シリーズBでは、アプリケーションの安全性や健全性を重視すべきだという考えにシフトしました。開発組織全員でアプリケーションの現状の課題を整理したり、エンジニアが抱えている課題をみんなで集めて改善したりといったフェーズになっています。今まさに、少しずつですが改善している最中です。

爲西：具体的に感じていた技術的負債としては、みんなが挙げたものを大きくグルーピングすると、コード負債、テスト負債、設計負債、ドキュメント負債、この4つがありました。

コード負債は、アーキテクチャがわかっていなくてバラバラな部分があったりとか、テスト負債は、テストが少なくてカバレッジが不明だったりとか。設計負債は、DB構成の根拠となるADRが残っていなかったりしました。ドキュメント負債は、開発フローがまとまっておらず、新しく入った人がオンボーディングしやすい環境があまり整っていないなどですね。

こうした負債について、開発合宿に行ったときに、写真のようにみんなで付箋に書き出して可視化し、課題について共通認識を持ちました。解決策としては、開発ルールやディレクトリ構成を整理する、テストを全員で地道に増やす、ドメインモデル図をつくって共通認識を持つ、設計のドキュメントや議事録を丁寧に残す、といった心構えを持つようにしました。こうして今、絶賛改善している最中です。

下司：ありがとうございます。続いて、GMOペパボさんからもお願いします。

高橋：まず初めに、GMOペパボという会社についてご紹介します。私たちは、「人類のアウトプットを増やす」というミッションを掲げて、さまざまなサービスを提供しています。

創業は2003年。今回、私がメインでお話しするネットショップ作成サービス「カラーミーショップ」は、2005年に始まりました。来年で20年を迎えるサービスですね。創業時、2001年には「ロリポップ！」というサービスが始まっており、20年近いサービスが社内にたくさんある状況です。

事業領域としては、ホスティング事業、EC支援事業、ハンドメイド事業、金融支援事業を展開しており、一貫してクリエイターや表現者の方々の活動を支援するサービスを提供しています。

高橋：今回ご紹介する技術的負債に関連するところで、今年は2つのシステムを大きくリプレイスしました。これはほぼ全部、書き直しをしています。1つは、いわゆるアクセス解析の機能ですね。

ネットショップをされている方々は、自分のショップにどれだけの人が来て、どういう買い物をして、どういう行動をしているかを、多くの場合はGoogleアナリティクスなどを使って見ていると思います。ですが、私たちもこの機能を、私たちだからこそ計測できるものを含めて提供していて、これを大きくリプレイスしました。

もう1つは、ショッピングカートです。ECのサービスはお客様に物を買ってもらうのが一番の重要なポイントですが、そのショッピングカートの部分をフルリプレイスしました。こちらは結構長く取り組んでいたものなのですが、ようやく今年全部終わって、古いショッピングカートをクローズしました。

高橋：今回、スタートアップのFastLabelさんに対して、私たちは長いサービスをやっているという立ち位置でお話しさせてもらっていますが、やはり歴史が長いサービスならではの課題があります。

これまで事業の領域をどんどん拡大してきたので、当然ながら機能は増えますし、機能が増えることによってシステムの複雑性が高まっていきます。単純に減らせばいいじゃないかという話もありますが、事業領域を拡大していくと、いろいろなユーザーの方がいろいろな機能を使っているんですね。しかも、「これってそんなに強みだったのか」と思うようなものが、ユーザーさんの使い方によって発見されることが結構あります。

2つ例を挙げると、1つは熨斗（のし）です。引き出物などに被せる紙なんですが、私からすると正直、そんなに大事だと思っていなかったんです。でも、ユーザーさんにインタビューしていくと、「これがあるから使ってます」という声が結構あって。日本の商習慣における贈り物では、これが非常に重要な機能だとわかって優先順位が上がりました。

もう1つは、決済方法です。事業領域の拡大を進めるなかで、さまざまな決済方法を提供してきて、結果数えてみたら37個ありました。この37個すべての決済方法を新しいシステムでもやるのか、というところで優先順位をつけたりなど、なかなか苦労しながらやってきました。

高橋：歴史の長いサービスをやっていると、どこかで大きくリプレイスしなければならないシチュエーションがやってくると思います。そのときに、私たちが気をつけてきたのは、第一にはユーザーさんにとって価値が上がることと、それに対する説明責任を果たすことです。

ユーザーインターフェースやパフォーマンスの改善によって、ユーザーさんにとってメリットがあることはもちろん、開発者体験の向上を通じて継続的に改善していけるようになるということも、わかってもらえるように説明を続ける必要があると思っています。

もう1つは、チームを組成して維持し続けること。特にビジネス面と技術面の両方で責任を持っている人を、別々でもいいので立てることが大事です。途中でどうしても優先順位が下がってしまうパターンがありますが、とにかく止めないこと。1人になっても「あなたにお願いします」と言って進めるというのが、今回フォーカスしたところです。

最近はそういったことを推進していくために、1つの策として、事業に責任を持つ技術系幹部を各サービスに置いています。今これを私たちは事業部CTOと呼んでいて、部門の経営メンバーの一員として技術職を入れることに取り組んでいます。

技術的負債に関して、“やらない意思決定”をしたことは？

下司 :では、ここからパネルディスカッションに移りたいと思います。1つ目のテーマは、「技術的負債に関して、やらない意思決定をしたことはあるか？」です。GMOペパボさんは長年運営されてきたなかで、やった方がいいこともやらない方がいいことも、さまざまあったのではと思いますがいかがでしょうか？

高橋：先ほどお話したことにもつながりますが、やれば開発者の体験は良くなるけれど、ユーザーさんにはメリットがあるかわからなかったり、直接的には影響がなかったりするものを、やるかどうかのジャッジは非常に難しい。それで過去やらないという意思決定をしてきたことは、結構あると思っています。

そこでは、やはりユーザーさんと開発者の体験を両立できるかがポイントになります。ただ、中長期的に見れば必ずユーザーメリットはありますが、短期的なメリットも何かないと、いろいろなところに説明できなかったり、そこまで行けなかったときにどうするのかという話が出てきたりします。そういう意味で、「やった方がいいけど今じゃない」というのは、最近もよくありますね。

下司 :短期的なメリットがないと、やはり他のチームにも説明しにくいと。

高橋：そうですね。それもありますし、やっている本人たちが、ユーザーさんに向けた機能を開発してるところと、そうでないところに分かれてしまうのも良くないなと感じているので。やはりどういう形であれ、ユーザーさんのメリットを第一に考えてやっているんだと思ってもらうためにも、短期的な目標は必要かなと感じますね。

下司 :FastLabelさんは、先ほど技術的負債を抱えた背景についてお話しいただいていましたが、やらない意思決定について今振り返るといかがですか？

風見：創業期よりは、中長期的な目線での投資をできるようになってきたものの、我々は意欲的な目標を掲げてどんどん開発していくところが強みではあるので、なかなかリソースを張り切ることは難しい状況があります。

先ほどもお話がありましたが、やはりそれをやったらどうなるかというところですね。短期的にでも中長期的にでも、開発者はみんなやりたがるけど、意外と取り組み終わった後に「あれ？」となることが結構あると思うんです。なので、なぜやるのかが納得できるものであればいいですが、そこがふわっとしているものは基本落としてきました。

とはいえ、全然やっていないと開発者のテンションが下がるので、ちょっとしたテクニックとして、インパクトは小さいけど工数も小さいものを散りばめる。そうやって少しずつやってる感があるなかで、たまにドカンとインパクトの大きなものが来るという、そういうところは意識していましたね。

下司 :GMOペパボさんでも、そうした少しずつやり続けるような取り組みはありましたか？

高橋： そうですね。今回は大きなリプレイスの話しかしていませんが、それ以外もやはり重要です。エンジニアが自分たちの責任範囲のなかで、小さな改善をしていないとすれば、それは専門職としての責任が果たせていない状態だと思うんですよね。

ユーザーメリットがあることばかりをやり続けた結果、例えば技術的負債がどんどん溜まって、どこかでものすごい工数がかかるようになってしまうとか、そういうことを防ぐためにエンジニアリングの専門性があるはずです。

なので、もちろんユーザーメリットのためにどんどんやっていくのですが、「言われた通りにやっていたら、ドカンと爆発しちゃいました」という状態にならないように、エンジニアリングマネージャーやリードエンジニアが、きちんとグリップしていくことが必要だと思います。

下司 :どのようにグリップしているのかという部分が気になる方も多いと思うのですが、FastLabelさんはその辺りいかがでしょうか？

爲西：グリップについては、かなり難しいとは思っています。メンバー目線で言うと、やらない意思決定をするとき、今はやらない方が利点が高いということで、長期的に見ればどこかで絶対にやらなければいけないと思うんですね。

だから、今はやらない意思決定をされて苦しくても、どこかで必ずもう一度同じ課題にぶち当たるから、そのときに絶対に直してやるんだというマインドを持って臨むのが、メンバーとしてあるべき姿だと思っています。

やらない意思決定に一時的にはヘコんだりしますが、メンバーもどれだけ長期の目線でその課題に対して向き合えるかという、そこの気合いの入り方が重要になるのかなと思います。そして、グリップに関する話は、僕の上司である風見さんに振ります。

風見：こういうアツいメンバーをグリップしないといけないので大変なんですが（笑）、最終的に目指しているところを、ちゃんと見せることが大事だと思います。我々も開発計画があるので、例えばクォーター単位でこれくらいまではやろうとか。正直さまざまな事情で入れ替えはあるものの、まずは目がけていることを明確化し、しっかり共通認識を取ります。

あとは、先ほど高橋さんからもお話がありましたけど、小さな工数で細かくやれることは、あまり口うるさく言わず、例えば「メソッド少しだけ直しました」だけでも歓迎してあげる。もちろん限度はありますけど、そういうちょっとした改善をちゃんと受け入れることは大事にしています。

高橋：それで言うとうちの会社は、頼まれていなくてもやってくれる方が結構いて、「こんなプルリク上げてくれるんだ、ありがたい！」、「バージョンめっちゃ上げてくれる、ありがとう！」みたいなことがあって、すごく助かっています。みんなで開発生産性や技術的負債にアタックしているという感じはしますね。

下司 :細かな改善をエンジニアの方が気づいてやってくれるというのは、非常にありがたい環境ですが、どうしたらそういった環境がつくれるのでしょうか？

爲西：普段話しているなかでも、例えば「このバージョン上がったらいいよね」とか「ここのソース見にくいよね」といった話が出てきます。うちの開発組織は結構フラットで、みんなでランチや飲み会に行って話す機会も多く、そういう話がポロポロと出てくるんですね。なので、そういう共通認識を持っていることが大事なのかなと感じています。

そして、余裕がある人が直してくれたら、それに対してみんなで「ありがとうございます！本当に助かります」と、しっかり感謝しています。うちの開発組織は、そういうコミュニケーションのところに強みがあるように思いますね。

高橋：うらやましいですね。ちょっとした改善を称賛する文化は、自分ももう少し意識的にやらなければいけないなと思いました。

GMOペパボでも、技術でユーザーの課題解決をしようという文化が根付いていて、各々の専門性のなかから「こんなのつくってみました」とか「ここを改善してみました」といったことが、たまにあります。そういうときに、もっと称賛したりチームで盛り上げたりできるといいなと思いました。

事業グロースを目指すうえで、技術的負債とどう付き合うか

下司 :続いて、2つ目のテーマは「事業グロースを目指す上で、技術的負債とどう付き合っていくべきか」です。先ほどFastLabelさんは、シリーズAから技術的負債が見えてきたといったお話もありましたが、実際そのときは負債とどう付き合っていたのでしょうか？

風見：やれるところはやりつつという感じですが、今でも変わっていないのはバランスだと思います。プラットフォームの立ち上がりでお客様もほぼいないのに、完璧に綺麗なものを組んでも虚しいですよね。逆に今は、数百社のお客様に使っていただいていて、何年後も安定して機能をリリースしていかなければなりません。

とはいえ、我々もまだまだ成長途中なので、もちろんやるに越したことはないですが、どのくらいのリソースを投下するかは、事業やプロダクト、開発チームの状態のバランスを加味して判断していくことがベースにあると思います。

下司 :そのバランスを加味するところに難しさがあると思うのですが、バランスの良い向き合い方にするために意識するポイントはありますか？

風見：定量的に取るのであれば、GitのIssueなどでシンプルな工数としてどのくらい投下したかわかるので、例えばクォーター単位でどれくらい技術ロードマップへの投資を行えたかといったことが見れると思います。

あとは、メンバーの雰囲気も大事だと思います。スタートアップにいるメンバーは意欲的なメンバーが多く、機能をつくりたい人が多いんですね。なので、彼らも彼らで足元と新しい機能とのバランスを考えていて、定性的ではありますが、そこのバランスは良くなるようにしたいと思っています。

下司 :実際にメンバー目線ではいかがですか？

爲西：ポジティブに考えれば、技術的負債を積み上げてきたからこそ、成長してきたんだとも言えますよね。ただ技術的負債が溜まっているときはつらいですが、それを終えて一段落ついたときに、「こういう負債が溜まっていたから今があるんだ」と言えるのかなと思っています。

今はその負債を回収しているフェーズではありますが、負債が溜まっていることは一概に悪いことではない気がしていて。改善点はもちろんあるんですけど、そこにいつフォーカスするかということですよね。

それから、みんな技術的負債と言っているけど、「何が技術的負債なのか？」という状態もあると思っています。なので、例えば開発組織が具体的に今どうなっているのかアンケートを取ったり、その後の改善を進めていくなかで数値が上がっていることを確認したり。そうして前向きなことが言えれば、チームの雰囲気は全然変わってくると思います。

下司 :事業を成長させてきたコードにリスペクトを払っていることが、言葉の端々から伝わってきました。GMPペパボさんは、事業グロースを目指すうえで技術的負債とどう付き合ってこられましたか？

高橋：私たちの会社のフェーズは、少なくともスタートアップではないので、着実な成長を求められているサービスがとても多いです。もちろん新しいチャレンジもしていきますが、たくさんのユーザーさんに使っていただいている既存のサービスを、どう再成長させるかということを最近考えています。

そのなかで最近強く思っているのは、放っておくと勝手に負債になってしまうということです。改善し続けていないと、気づけば一昔前の技術ばかりになってしまい、技術によっては「これに触れるエンジニアはもういません」という状況になってしまいます。

実際に事業を再成長させていくぞというタイミングで、「これどうやって誰が直すんですか？」というものが結構ありました。それでリプレイスしたという背景も実はあるので、それを正直どうしたらよかったのか、今でも自分のなかに正解はないですが、それが最近2つの大きなシステムをリプレイスして感じたことですね。

下司 :たしかに、15年以上もサービスを運営していると周辺ツールなども全然違いますよね。

高橋：そうですね。もともと私たちのサービスは、物理サーバにインストールして動かしていましたが、少し前にバーチャルマシンベースのインフラにして、最近はコンテナベースに全部移行しようとしています。ただ、そのベースとなるアプリケーションは、VM時代を前提とするアーキテクチャになっていたりするんですね。

例えば、ローカルに何らかのファイルがあることを前提としたシステムになっていたり、ファイルシステムの書き込みがどうしても必要だったり、そういうものを全部直しながらやっていかなければならない。これが結構大変で、自分の意思決定として放っておいたのは良くなかったなと思っています。

少しでも次の技術の邪魔にならないように、例えばこれからコンテナにするなら、ファイルシステムとの分離をしておくとか、そういうポイントを押さえておくべきだったなと。今思い返すと自分の反省というか、やっておけばよかったなと感じるところはありますね。

下司 :15年以上のサービス運営を経験してきた高橋さんから、FastLabelさんにアドバイスをするとしたら何かありますか？

高橋：そんなことを言える立場ではないですが（笑）。サービスが成長していく過程で、サービスの成長が人数と比例しているときと、人数に対して鈍化してくるときがあると感じていて、実際に今の私たちの事業はそういう状況になっています。

そうなったときに、新機能開発と開発者の生産性向上を両立させられる組織を上手くつくれていると、すごく強いだろうなと感じています。そして、それを今自分がやらなければならないと思いながら、日々やっているところです。

下司 :とのことですが、いかがですか？

風見：今お話を聞きながら、登壇していることも忘れて「その通りだな」と（笑）。ありがたいアドバイスをありがとうございます。本当にそこはマストだと思っていて、我々のビジネス的にもやりたいところにたどり着くためにも、ストレッチが必要です。もちろん個人のストレッチもありますが、やはり仕組みとして開発者体験の向上、生産性の向上といったところを、上手くやっていかなければいけないと思っています。

下司 :まだまだ聞きたいことがありますが、そろそろお時間となりますので、最後にFastLabelさんからの告知をお願いします。

風見：FastLabelは、今まさに絶賛急成長中のスタートアップ企業です。FastLabelがいる世界といない世界で、いかに良い差分が生み出せるかが重要だと思っているくらい、意欲的に取り組んでいる会社です。

FastLabelでは、一緒に働くメンバーを募集中です。カジュアル面談から気軽に、情報収集でも結構ですので、楽しくお話できればと思っています。採用ページや求人媒体にいろいろと載っていますので、ぜひご応募いただけると嬉しいです。

下司 :本日は、短い時間でしたがありがとうございました。