目標の約半分が未達のままリリース、そして無事炎上…　技術的負債てんこもりサービスのフルリニューアルから学んだこと

丹羽氏の自己紹介

丹羽悠斗氏（以下、丹羽）：最初に謝らないといけません。（開発失敗談の）詰め合わせで考えていたんですけれど、10分じゃとても話しきれなかったので、今回は1つの失敗談のみで共有できればと思います。

失敗談から技術的負債との向き合い方などに関して、みなさまになにかしらの示唆を与えられればと思って、今回の発表資料を作っています。

簡単な自己紹介から始めたいと思います。私は、株式会社SIGNATEでVPoEをやっている丹羽と申します。僕は前者の3名とは違って、JAIST（北陸先端科学技術大学院大学）と呼ばれるところで「知識がどう生成されるか？」というような研究をして、（その後に）オプトホールディング（現、株式会社デジタルホールディングス）のデータサイエンスラボに入社して、今までやってきている感じになっています。

今回は、弊社が今、東大IPCさまから出資していただいているので、その関係でお声がけをいただき参加しています。

キャリアとしては、エンジニアからPMを経験して、2022年からVPoEをやって組織作りと採用をがんばっています。SNSは時間をけっこう浪費しちゃうのでやっていなかったんですけど、今回（アカウントを）作ったので、よければフォローしてください。

株式会社SIGNATEの事業

弊社の事業を簡単に紹介できればと思います。今は2つの事業をやっている感じになっています。1つはTaaS事業と呼ばれるもので、もう1つはSaaS事業と呼ばれるものです。基本的には、世の中のDX推進において、人が足りない課題を解決するために必要となりそうなサービスやプロダクト作りを進めています。

TaaS事業に関してはPHPのLaravelで作られていて、SaaSの事業はRailsをベースに作っています。（ただ）一部Goで作られているところもある感じになっています。

技術的負債がてんこもりサービスで行ったフルリニューアル

今回お話ししようと思っているのは、TaaS事業のプロダクトでやらかしてしまった失敗談です。

だいぶ古い話で恐縮ですが、実は2018年頃にサービスのフルリニューアルを行っており、これがけっこう大変だったという点を共有できればと思います。

入社してからたぶん3年目ぐらいになります。入社する前に作られていたシステムは、ホームページとCMS、あとはコンペ機能というところで、外注で作られたシステムにてんこもりな機能が存在している状態でした。

徐々にユーザー数が増えてきて、いろいろと開発の邪魔になる部分があったので、2016年にプロダクトの切り離しなどをして運用していたんですが、ここに技術的な負債がてんこもりでした。

さらに、使われていたフレームワークもZend Framework 1.2というだいぶ古いものでした。このサポートが切れるタイミングでメジャーバージョンアップをしようとすると、破壊的な変更がかなり多く、バージョンアップの対応もメチャクチャ難がある。

そういう状況だったのですが、1部署から会社として独立するのにあたって「フルリニューアルしましょう」という話になりました。

2018年では、スライドの目標の部分に書いてあることがけっこうモダンな開発の内容になっていました。今後のプロダクトの開発速度を向上させたり、セキュリティ面などを気にしたところでシステムをフルリニューアルしていいという話になったので、約半年の期間が設けられ、チームとして僕を含めた3名でやることになりました。

当時モダンな技術が使われていた夢のようなプロジェクトにワクワクして入ったら悪夢を見たという、そういう話ですね。

目標の約半分が未達のままリリース、そして炎上

目標に対して約半分が未達のような状態でリリースされることになってしまいました。やりたいことの半分はできたと言いつつ、あまり重要でないと判断した既存機能がすべて移植できなかったり、そういう意味では半分以上がぜんぜんできていないという結果だったと思っています。当時はエンジニアとして参加していましたが、常にこれが自分のキャリアの中の大失態としてあるので、けっこう記憶に残っています。

開発が終了してリリースも行えましたが、リリース後に無事に炎上して、約1週間かけて既存メンバーでゴリゴリ開発して、炎上の消火活動をしていくことを暫定的に行ったという感じです。

この時の技術的な負債が、今もなお残っているような感じです。サービスは一応順調に成長していて、人員も増えて6名体制になったタイミングで、新規開発をする人と技術的な負債を解消する人にメンバーを分けるなどして対応してきています。

フルリニューアルからの学び

このフルリニューアルからの学びとしては、いろいろなことをいっぺんに実行するのはやめたほうがいい。これが反省としてあります。

また、一度作ってしまった負債は本当に地道に解消するしかない。今回のフルリニューアルで一気に解消しようとして失敗したので、時間もかかるし、地道にやっていくしかないというのが振り返りとしてあります。

あとは、体制が3名だったこと。6名に増えたらけっこう開発に集中できたり、役割によって開発に集中できるケースが増えたりするので、チーム体制もけっこう重要なファクターだと思っています。

現状はそういった学びを経て、TaaS事業もSaaS事業もなるべく技術的負債を溜めないような感じで開発を進められるようになってきました。なるべく負債を作らないように、チーム内であらかじめ仕様のレビューやコードレビューをしていく文化もできてきているので、そういう意味ではけっこう健全なチーム運営が今はできはじめているのかなと思っています。

技術的負債に関しては、TaaS事業はコンシューマー向けのサービスになっていて、トレンドをけっこう追って新規技術・新規開発をしているので、技術的負債が溜まりがちです。

一方、SaaS事業は提供しているサービスは学習系なので、予算取りの都合で繁忙期・閑散期がけっこうあるような状態です。そのため、繁忙期ではないタイミングで負債を解消すべく、うまくバランスをとってやれている状況です。

技術的負債の解消方法に正解はない

一連のプロダクトを見てきて思うのは、基本的に負債の解消方法に正解はなく、こまめに返済していく、あるいはある程度溜まってから返済することを使い分けていく感じに今はなっています。

とはいえ、直近のプロジェクトの「ChatGPTチャレンジ」。TaaS事業側で「すぐに作ってくれ」という話が経営から下りてきたものとかもありました。（このチャレンジは通常のコンペと違い、Twitter上にユーザが投稿したChatGPTに関する内容を、弊社のシステム上にルールや規約に同意の上投稿してもらい、今流行りのChatGPTに関する知見を共有し合うという試みです。）チャレンジが成立できるよう、一応2週間で段階的にリリースしているんですが、設計にあまり時間をかけられず場当たり的な対応になっているので、現在進行形で負債を蓄積してしまっている失敗ケースです。

5名で開発して、1週間で物を作ってテストまで終えてリリースするという流れを踏んでいます。明日（2023年3月23日）にランキング機能もリリースされるので、今日この話を聞いて興味を持った方はぜひ参加してみてください。

この話が持ち上がったタイミングで技術的な負債が発生するのは目に見えていたので、開発の工数としては負債を解消することをあらかじめ含め、スケジュールを引いて確保して負債が残らないよう工夫をしている状況です。

ChatGPTチャレンジは始まっていますが、僕たち開発チームの技術的負債の返済チャレンジはこれからだということで、発表を終わります。

なお、僕の会社は採用もがんばっています。少しでも興味を持った方はDMなどで連絡をいただければと思います。以上です。