足掛け10年のコードベース・定着しないメンテナ・どんどん生まれる機能たち… “九龍城化したシステム”を解きほぐしたCake.jpの技術選定

入社して感じた「遠くのほうにヤバいものがあるな」

新多真琴氏：（スライドを示して）今、上2つが終わりました。これから本編に入っていこうと思います。技術選定の話をしていきますが、今日、技術選定の話を持ってこようかどうか若干迷っていました。「EMといったらピープルマネジメントだろ」みたいなところもあると思うんですけど（笑）。

先ほどの（大野晋氏のセッションの）質疑にもあったように、（EMは）技術をわかっていたほうがいいのかどうか、そのあたりにもかかってくると思いますが、実際に意思決定する立場は自分でなくとも、どこに理由があってその技術を選定するに至ったのかは、わりときちんとわかっていたほうがマネージャーなのでよかろうよ、と思っています。

この技術的な意思決定は私がやりました。これはCTOのロールのうちの1つだと思ってやっていたのですが、もしテックリードが横にいたら、テックリードと一緒に決めていたかもしれないなと思います。

（スライドを示して）はいちょっと、変な絵の状態で止めて前提の話をしちゃいましたけど（笑）。

入社した当時、6月のあらたまさんは、「遠くのほうにヤバいものがあるな」と薄々感づいていたのですが、近づいてみたら本当にヤバかったということがありました（笑）。めちゃくちゃ誇張しています。誇張していますが、事実としてあるのでお話ししていきます。

Cake.jp自体は、2017年の頭ぐらいにスタートしたサービスです。Cake.jpというかたちになるまでに2回ぐらいピボットしていて、そのピボットの過程の中でコードベースを捨てるという選択を取らずに来ました。

足掛け10年ぐらいの歴史を持つ、システムとしてはなかなか古き良きサービスなんですけど（笑）、この業界で10年というとだいぶ長いじゃないですか。いろいろな技術革新がありましたし、いろいろなデファクトスタンダードが出ては消え、出ては消えてきました。

技術も業務フローも時代の変遷に合わせてたくさん最適化させてきました。新しい種を見つけて、それに沿うように今のシステムを無理くりトランスフォームさせるということをやっていっていたので、コードの歴史的経緯を把握することがけっこう難しくなっていました。

そうなるとやはり楽しくないじゃないですか。なので、「これはちょっとなんとかしないと」と思っていたのが入り口としてありました。

じゃあ、これをこんなになるまで放置してきたのが悪かったかというと、そんなことはないと思うんですよね。きれいなコードを書きましょう、きれいなアプリケーションを作りましょうとやって、やっているうちに会社が倒産したら意味ないじゃないですか（笑）。

暴論といえば暴論なんですが、プロダクトマーケットフィットしていない状態でそういうことを言うのは、「優先順位がなっとらん」みたいな話だと思っています。なので、そういった状況の事業、プロダクトにおいては、コードの寿命よりももっと優先されるべき事項があるよね、と。

結果として、技術的投資が今のタイミングではないという判断が、暗に明にされてきたというだけではないかと捉えています。もちろん、二兎を追えるに越したことはないんですよ。ですが、それをすごく高い水準で発揮できている事例を私たちは聞いたことがありますか？　という話なんですよね（笑）。

それだけ、各社悶え苦しんでいる部分だろうと思いますし、今後、Web産業自体がさらに成熟していくにあたってこういう事例はものすごくたくさん出てくると思うのです。なので、ここでなにか1つ、自分たちの中で正解を見つけられたら、それはみんなにとってもすごくいい示唆になるんじゃないかと考えています。

新しいアプリケーションに載せ替えるという判断をした

じゃあ今のCake.jpがどういう状態で、事業としてどういう状況かという話です。コロナ禍で巣ごもり需要になり、2019年には確か2パーセントぐらいだった菓子産業のEC化率が、今は10パーセントぐらいにまで上がっているんです。そのぐらい急成長を遂げている、なかなかすごい市場になっています。

わりとほかにケーキ・スイーツの専門という競合がいない状態なので、だいぶありがたい状況、追い風をもらっている状況です。より使いやすく、よりいい商品にきちんと出会えて、きちんと商品が届いて、お祝いに花を添えられる。そういうサービスを作っていくためには、やはり技術的な投資にも力も入れていくフェーズだよねという話をしました。

（スライドを示して）新しいアプリケーションと書いています。どういうことかというと、今のアプリケーションをコツコツがんばってきれいにして、バージョンアップしてメンテしていくよりは、新しいアプリケーションに載せ替えていこうという判断を2021年にしました。

（スライドを示して）理由を3つ書きました。大きく分けると2つなんですが、1つは、現状のままメンテナンスを続けるというのが、けっこうスループットが出にくそうだと、各状況を見ていて私が判断したからです。

あと、コードがなんか気持ち悪いから直したいとか（笑）、そういう場当たり的な対応をするよりは、より本質的な対応、切り込むための武器みたいなものが欲しかったというのが1個。

もう1つが、これは個人的な意見なのでチームメンバーみんながどう思っていたかはわからないんですが（笑）、マイナスをゼロにする仕事はけっこうつまらないじゃないですか。

「何をやっているんだろうな、自分」みたいな感じ（笑）。しかも、すごく大変なものだとけっこうモチベーションが続かないと思っています。なので、せっかくなら生産性だけじゃなくて、楽しさを持って新しいことを学ぶ。それが苦手という人もいますが、たいていの人はわくわくする類の話だと思います。そういう付加価値的な楽しさも大事にしていきたいと考えて、新しいアプリケーションへの載せ替えを考えていました。

PHP→サーバーサイドKotlinへの移行を決断した理由

じゃあどうやったかというと、（スライドを示して）このあたりの本に助けてもらいました。左と右の本はチームで輪読もやって、けっこう共通の語彙が増えてきていい感じです。先人たちの知恵を積極的に借りて選定した結果、PHPからサーバーサイドKotlinに載せ替えるという決断をしました。

どういうところがというと、ECサイトは手続き的な処理、型が決まっている処理がけっこう多いんですよね。そこにCake.jpらしさが加わります。例えば住所を知らない相手にギフトを送ることができるソーシャルギフトという機能があって、これはすごく便利なんですけど、そういう独自の機能が乗ってくるかたちになると思っています。

ECサイトに必要とされる業務フローをしっかり正しく落とし込むには、ある程度の型付けとパッケージングができる言語を選定したかったんです。

GoとJavaとKotlinの3択で考えていて、既存メンバーの技術のキャッチアップを考えた時に、「GoよりもJava、Kotlinのほうがキャッチアップの難易度が低くて済むんじゃないかな？」というところも検討材料の1つにして、サーバーサイドKotlinへの移行を決断したという感じです。

あと、これは採用の文脈なんですが、「PHPでECやっています」って、なんだろうな、特色がないというか、同じアセットを持ってやっていらっしゃる他社がすごくたくさんいると思います。

今の売り手市場においては、応募者が（企業を）よりどりみどりなわけじゃないですか、という時に、「おっ」と引っかかってもらう要素を作りたかったんですよね。ただ、そのためだけに飛び道具が欲しいわけではありません。きちんと現状を踏まえた上で方針を立てて、なおかつ社外へのメッセージも両立させる選択ができるようにしよう、と考えながら決めたことでした。

カオスモノリスからモジュラモノリスへ

今「Cake」はPHPで書かれているのですが、もうそのような流れなので、カオスモノリスからきちんとパッケージングしてモジュラモノリスに載せ替えていきましょうというところですね。

Kotlinでパッケージングが利くので、LLにありがちな「こういうルールでやろうね」と言っても、結局どこからでもなんでも呼び出せちゃう状態を、仕組みとして防ぐというのをやりたかったんですね。ちょっと極端な例ですが、viewにSQLを書けるじゃないですか。それを「書かないようにしようね」じゃなくて、そもそも書けない作りにしたかったということです。

もう1個、こっちがすごく大事だと思っているのですが、コンテキストの境界を正しく作る。いきなりDDDの宗派の人みたいになってきますが、これがすごく大事なことだと思っています。

コードを書くということは、現実をできるだけ写像として切り取り、それぞれのコンテキストに合わせることが一番大事だと思っています。そういうモデリングがやりやすい言語、やりやすいアプリケーション構成にしていきたいとずっと思っていました。

エンジニアリングはモデリングなので、現実世界で何が起きているかをつぶさに観察する。業界を知って、事業を知って、業務フローを知って、初めてモデリングができる状態だと思っています。言われたものを作るだけじゃ駄目だと思っているので、しっかり周りと対話して、よく知って、課題が何なのかを明らかにして、それをいい感じに解いていく。そういう手段として、エンジニアリングがあるよ、と。そういう話をチームではよくしています。

まだちょっとできていないのですが、加盟してくれている店舗にバイトとしてお邪魔して、どういった業務をふだんされているのかを知りにいくということを今後やっていきたいと勝手に思っています（笑）。

「自律型組織の話をしていたはずなのに、めちゃくちゃ技術の話をしてるじゃん」みたいな感じですね。でも、ここまで足回りが整えられて、初めてエンジニアリングの観点で自分たちに自律性が備わるようになるんじゃないかと私は思っています。わりとハードモードな考えだと理解していますが、1回振り切ってみればもういいかと思っているところです。

堅ろうなアプリケーションが作れてハッピーみたいな感じ

「じゃあ、やってみてどうなの？」みたいなところですが、現在はいくつかの新規・既存の機能が少しずつサーバーサイドAPIとして切り出されている状態です。2021年8月に「やるぞ！」と言って、ファーストデプロイが11月だったかな。最初のAPIを私がガーッと書いて、あとはよろしくとお任せして、たくさんバグを潰してもらいました（笑）。

そういう立ち上げのタイミングも私しか触っていなかった状態から、徐々に触りたい人が増えてくれて、今ではメンバーの過半数がコントリビュートしてくれるようなアプリケーションになっています。

もともと目論んでいたとおり、それぞれの領域の責務が明確になって、これはどういう業務フローに接着したコードなのかがわかりやすくなりました。そうすると、テストが書きやすくなるんですね。それで「テストをたくさん書こう」となって、すごく堅ろうなアプリケーションが作れてハッピーみたいな感じでした。

そういういいループが回るので、みんなそれなりに楽しそうに書いてくれていると見ていて思っているところです。

移行により出てきた課題とは？

一方で課題もあります。単純にパスが増えました。1つの画面を返すまでのパスが1往復分増えたので、不具合が起きた時の切り分けがちょっと大変になっちゃいました。

こればかりはトレードオフとして割り切るほかないと思うのですが、例えばトレーサビリティを上げるとか、いろいろできることはあると思っていて、そういういいやり方を模索していきたいなと思っています。

ほかの課題は、既存実装に書かれている責務を境界のない状態からスタートしているので、どこまで切り出してどう寄せていくかが議論の的にけっこうなるところです。ここが一番難しいと思っています。

PHPがあって、Kotlinがあってという状態なので、最悪99パーセントPHPに寄せていても、一応「Kotlin化が叶いました」みたいなことになるじゃないですか（笑）。意味がないんですけど。その塩梅に対してメンバーがけっこう苦労してくれていて、「すまんなぁ、ありがとうなぁ」みたいなことを言う人になっています（笑）。

こればかりはどうしても易きに流れてしまうので、「言うても納期があるので、ここの部分はPHPで書きます」ということがけっこうあります。それはきちんと次のスプリントで「これをKotlinに移行するぞ」というイシューを立てて潰すことを順次やっています。

このタイミングでは、アプリケーションのリプレイスだけをやろうと。データレイヤのリファクタリングはやらないことにいったん決めました。なので、もともとあるデータ構造に引きずられてついついアプリケーション側が割を食ってしまうというパターンもないわけではないです。

プラス、APIとして立てていて、土管みたいな機能、CRUDだけがあるみたいなものをKotlin化してもあまりうまみがないので、何を移行対象にするかはけっこう気をつけて見ているところです。実際に失敗もして「これは今じゃなかったな」みたいな話をすることもあります。

技術の話はそんな感じです。ちょっとしゃべりすぎちゃって5分押しぐらいなので、巻いていこうと思います（笑）。

（次回へつづく）