変化の激しい現代におけるシステム開発では、できるだけ早くプロダクトを世の中に出してフィードバックをもらい、またプロダクトを磨く…というリーンな開発サイクルを高速で回すことが重要だ。

しかし、このトレードオフとして生まれるのが、システム開発における「技術的負債」だ。

ラクスル株式会社では、2017年に「Raksul Platform Project」を立ち上げ。「触れば誰でも怪我をする」PHP40万行、JavaScript10万行という規模の巨大なアプリケーションが抱えた技術的負債の返済に着手した。

その目的は、既存ラクスルの解体。一枚岩のシステムを機能ごとに小分けすることで、それぞれ独立したチームがアジャイル（俊敏）に顧客へと価値を届けられる状態を目指した。

結果として、技術的負債を大きく返済することに成功。創業当初から描いてきた「印刷産業を変えるプラットフォームになる」ための事業の多角化や、海外の人材を活用した開発体制の構築も実現されたという。

今回は、Raksul Platform Projectのメンバーであり、ラクスル事業本部でHead of Engineeringを務める二串 信弘さんに、同社の技術的負債への取り組みについて、詳しくお話を伺った。

「印刷のラクスル」多角化を支えた、技術的負債の解消への取り組み

私は2017年に、エンジニアとしてラクスルに入社しました。当時は全社で100名ほど、うちエンジニアが20名ほどの組織でしたね。

組織が大きくなっていく中でマネジメント側にも踏み出すようになり、現在は印刷事業部のHead of Engineeringというポジションで、施策の優先順位決めから技術の統括、マネジメントや採用までを担っています。

いま、ラクスルの印刷事業は非常に多角化しています。従来から展開していた紙の印刷だけではなく、お客様の集客・マーケティングの支援であったり、紙以外の印刷の領域であったり、周辺領域へと事業のポートフォリオを増やしていっています。

創業当初から描いてきた「印刷産業を変えるプラットフォームになる」ということに、一歩ずつ近づいていると感じていて。

この状況を作ることができた理由のひとつに、2017年から行っている技術的負債の解消への取り組みがあったと考えています。むしろこれなくしては、今の事業成長を実現することはできなかったと。

もともとのラクスルのシステムは、いわゆる一枚岩のモノリス（単一）アプリケーションとして構築されていて、その中に価値ある機能が色々と詰まっている…という状態でした。

例えばチラシを注文する機能や、ポスティングができる集客支援の機能、入稿データを自動チェックする機能、といったものです。

これらはラクスルの競合優位性を作ってきた、非常に重要な機能です。しかしその一方では、これら全てがひとつのアプリケーションとして絡まり合っていて、今後のビジネス展望に対して簡単に活用できる状態ではありませんでした。

この大きな一枚岩をきれいに整理して、事業の成長を作っていける状態を目指そう、ということが技術的負債への取り組みの始まりでした。

結果としていまでは、各機能ごとに独立した小さなチームの中で、開発効率を追求しながら、アジャイル（俊敏）に開発ができるようになり、多角化な事業展開に大きく貢献できたと考えています。

時間を「前借り」した、スピーディな開発に伴うリスクとは

そもそも「技術的負債とは何か」をひとことで言うと、「ソフトウェアを作る過程で、その時点で最適なソリューションを選択したことにより引き起こされる、暗黙の追加コスト」です。

これだけでは抽象的でわかりづらいと思いますので、もう少し噛み砕いて説明します。

現代の変化が非常に速い世の中においては、早くプロダクトを世の中に出してフィードバックをいただき、素早くプロダクト磨く、いわゆるリーンな開発が重要になっていますよね。これ自体は、ラクスルも非常に得意とすることです。

早くリリースすれば、それだけ早くお客様も増えて売上も上がるので、一見良い状態に見えます。しかし、「早くリリースする」ということは、いわば時間の「前借り」をしているということです。

もう少し時間をかけて考えれば、より理想的なシステムが作れるかもしれないけれど、時間は有限なのでどこかでリリースしなければならないですよね。この選択によって、実は目に見えない技術的な負債が発生していて、それが溜まってくると、開発の効率が落ちてくるんですね。

「負債がある」というのは、何かしら無理がある状態です。なのでそのまま開発を進めると、いざ新しいことをやりたいときにめちゃくちゃ頑張る必要がでてくる。要するに、人的なコストが多くかかってしまいます。

結果、ビジネスサイドからはとても簡単に見える新機能のリリースに対して、エンジニアがめちゃくちゃ渋い顔で「3ヶ月かかりますよ」と答える…といったことが起こるんですね。

負債を抱えることで、早くリリースして、早くフィードバックをもらえるというメリットは当然あります。その一方で、その負債を溜めすぎるとどんどん開発効率が落ちてきて、事業にとって重要な新たな開発が進まなくなる…というリスクがあるということです。

リファクタリングのROIはゼロ？ 技術的負債はいつ解消すべきか

負債を返済する作業を、ソフトウェアの世界では「リファクタリング」と呼びます。いわば、プログラムを綺麗に整理整頓していく作業です。

例えば「新しい家に引っ越してきたけれど、明日もう会社に行かないといけない」という状態であれば、とりあえず段ボールを開けて、若干住みづらくても生活できるように一応家具を置きますよね。

もし時間があれば、もっと生活しやすいように家具の配置を変えていくと思いますが、現実的に明日からの生活があるので、どこかで見切りをつけて初期リリースをします。

この状態を「負債を抱えている状態」だとすると、リファクタリングとは家具を再配置して、室内での生活を快適に、効率的にすることです。

とは言え、明日にも潰れるかもしれないスタートアップにおいては、リファクタリングに取り組んでいる時間はないですよね。そこは「負債を満載に溜めましょう」という覚悟でやっていくんだと思います。

そもそも未来を100％予測することはできないので、どんな会社でも、どんなに頑張っても一定の技術的負債は発生します。その上で、どのタイミングで溜まった負債の解消に取り組むのかは、色々な考え方があると思います。

ラクスルの場合は2017年に「Raksul Platform Project」を立ち上げ、技術的負債の解消をスタートしましたが、その背景のひとつは人が増えてきたことです。

資金の目処もたち、優秀な人がたくさん入ってきている、いわゆる「体力がある会社」になったと。このタイミングで技術的負債に取り組むことで、より事業の成長性を高めていこうという狙いがありました。

そしてもうひとつ、「このままだと立ち行かなくなる」というリスクに対処した、という理由も大きかったと思います。もっと端的に言うと、「このままにしておくとエンジニアが辞めていくだろう」ということですね。

ラクスルのエンジニア組織はいまはとても健全な状態で、非常に生産的に働けていると思います。ですが、もちろん最初からそうだったわけではありません。

実際、技術的負債が溜まって開発効率が下がったままの状態にしておくと、優秀なエンジニアほど、より挑戦しやすい環境を求めて辞めてしまうんですね。企業として、彼らをリテンションしていくことはとても重要ですが、ここで経営陣の理解や意思決定が大事になってきます。

そもそもリファクタリングって、それ自体は価値を生まない上に、新しい機能開発に割ける人件費の割合を減らしてしまいます。なので経営陣から見ると「じゃあROI、ゼロですね。いつ価値を生むんですか？」という話になるわけです。

ラクスルの場合は当時、技術的負債がどんどん増えていったことで、「将来、やりたい事業を実現するためには、エンジニアの数を増やすしかない」という状況に陥る恐れがありました。

つまり、新しい事業によって売上が上がっても、人件費はもっと上がる…という労働集約的な構図になってしまう。それは健全ではないじゃないですか。

そこで、「将来に発生する人件費を抑えるために先行で投資する」という考え方で、経営陣とも合意した上で取り組みをスタートできた…という背景があります。

ビジネスサイドとの相互理解のため、やるべきこととは

Raksul Platform Projectの具体的な取り組みとしては、まず創業期からあった一枚岩のモノリスアプリケーションの中から、決済と会員IDの部分を別に切り出して基盤化しました。

同様に、モノリスの中にある機能ひとつひとつを、徐々に別のウェブサービスとして切り出していく形で、リファクタリングを進めていきました。

技術的負債を返す方法は色々あるので、これがベストですと言うつもりは全くなくて。ラクスルの場合、創業期に作った機能を、デザインやUXも含めて見直したいという話もあり、このような大規模なシステムアーキテクチャレベルのリファクタリング＝リビルド、という形をとりました。

※より技術的な内容については、5/18（火）開催 【Raksul Tech Talk】急成長上場ベンチャー企業が語る「技術的負債からの脱出」でも詳しいご紹介があるそうです。こちらから、ぜひお申し込みください。

一方で、こうした取り組みを進める中では、ビジネスサイドから「早く新しいもの作ってくれよ」「リファクタリングなんて、エンジニアのエゴではないか」と言われる可能性もあると思います。

ですから、エンジニアではないメンバーの理解を促進するための取り組みがとても大切です。そのためには、まず定期的に発信するということ。繰り返し飽きるまで、わかりやすく伝えることが必要です。

ラクスルの場合は全社の朝会や、締め会のようなイベントのコンテンツとして技術的負債への取り組みを発信し、存在感を出すようにしていました。その中でしっかり成果をアピールしていくことで、事業としてのメリットも理解されやすくなります。

その際には、「困っている」みたいなニュアンスより、「明るい未来が待ってるぞ」という感じで、ポジティブなニュアンスを出していくことがキーポイントかなと思いますね。

加えて、朝会の発表時に代表の松本からコメントをもらったり、社内報に取り上げていただいたり、プロジェクトが表彰の対象になったり。こうしたことを通じて、「会社としても技術的負債への向き合いをきちんと評価する」ことを全社的に発信できていたのが良かったですね。

▼Raksul Platform Projectを社内報で取り上げ

個人的にラクスルは、職種を越えて相互理解ができているところがすごく良いと思っていて。

「エンジニアが大変だから、しゃあないな」という一方通行ではなくて、事業の成長のために、エンジニアもビジネスサイドも互いを理解して互いの視点で考えていける。これがもはや、カルチャーになっているんですよね。

技術的負債というと、どうしても技術的なことだけなのかなと捉えがちですが、もっとニュートラルに考えるのが良いと思っています。そうすると、なぜ技術的負債を減らすのか？　ということも、ビジネスサイドと一緒に深堀りしていくことができるようになります。

技術的負債の解消により、海外エンジニアとの協業も可能に

また技術的負債の解消への取り組みによって、事業面はもちろん、人材面でも成果がありました。

昨年から海外の開発拠点として、ベトナムに20名、インドに10名のエンジニアを採用したんです。彼らとは英語でコミュニケーションをしているのですが、以前の状態ではこれは到底、実現できなかったです。

と言うのも、以前のモノリスアプリケーションは、ただでさえ複雑なビジネスドメイン上に負債を溜め込んでいたので、それらを乗り越えた上でさらに言語の壁も乗り越える、というのは絶対に無理でした。

ですが、リファクタリングが進んでそれぞれのプロダクトが独立したチームになったことで、こうして海外の人材を獲得して、新しいプロジェクトにアサインすることができるようになったと。

いま日本ではエンジニアの採用が非常に難しいので、こうしてグローバルにタレントを探していけることが、事業上の強みになってきています。

今後は、こうした海外拠点のメンバーと一緒に、いかにビジネスにフォーカスしたプロダクトを作っていくか、ということがチャレンジになると思います。

印刷領域って、なかなか難しいんですよ。例えばお客様がダイレクトメールを送るサービスを作るとしますよね。すると、まず注文を受けて、デザインのデータをいただいて、印刷会社に注文して、配送会社に印刷物を送って、配送して、完了報告いただく…といった形で、すごくバリューチェンが長い。

こうした非常に難しく複雑なリアル産業を、どうシステムに起こしていくのか。とても難易度が高いので、今後、いかに技術的負債を少なく取り組んでいけるかは引き続き重要になっていきます。

そして、技術的負債には色々と向き合ってきたとは言え、まだ残っている課題もあります。そこに引き続き取り組むことで、今後も事業の強みをより生み出していきたいですね。（了）