川口将貴氏がCTOになった経緯
川口将貴氏：BASE株式会社で執行役員CTOをやっている川口です。1991年生まれの32歳です。新卒でソーシャルゲーム開発をしているサイバーエージェントの子会社に入って、サーバーサイドのエンジニアをやりつつ、インフラやネイティブを全部やっていた感じです。
その後に転職して、2017年5月からBASEにジョインしました。その時はCTOでの採用ではまったくなく、バックエンドエンジニアとして入社しました。半年ぐらい経って、テックリードになり、そこから2年ぐらいでCTOになりました。
BASEだと（CTOは）えふしんさん（藤川真一氏）のイメージが強かったと思います。自分も、えふしんさんからCTOが変わるとは、あまり思っておらず、1度打診をされた時に、ちょっとめんどくさそうだったので断りました。組織開発などのミーティングが増えそうな仕事はあまりやりたくなかったので断ったのですが、業務分掌の話の中で、現場の技術の責任を担当する役割としてのCTOだったらどうだろうかという話をされて、それだったらいいですよと言って、2019年7月にCTOになりました。
実際にやってみると、技術をなんとかするとかプロダクトを良くしていくのに、採用やチーム組成が必須になって、CTO1人では何もできないことがわかったので、結局、最近はやりたくなかったこともやるようになっています。
僕がCTOになったことでえふしんさんがBASEから離れたのではなく、SVPoDとして、もうちょっと全体的な全社視点での活動や不正決済の部分を別でやっています。
個人だと、水道橋でシーシャ屋をやっています。お願いします。
コロナ禍によって自分たちが想定していた5年先がいきなり来てしまった
（スライドを示して）会社の概要です。ミッションは「Payment to the People,Power to the People.」です。一人ひとりに決済を、個人やスモールチームの方にペイメントを解放することを、ミッションとしてやっています。
サービス紹介です。ネットショップ作成サービス「BASE」、購入者向けショッピングサービス「Pay ID」、オンライン決済サービス「PAY.JP」などがあります。CMなどでよく見るのは、ネットショップ作成サービスの「BASE」だと思いますが、iPhoneやAndroidのアプリとして「Pay ID」があります。
（Pay IDは）もともとは「BASE」という名前だったのですが、1年ほど前にリブランディングして、「Pay ID」という名称にしました。（スライドを示して）これがネットショップ作成サービスの「BASE」です。CMとかで、手軽に開設できるとか、けっこういろいろできるということを伝えています。
（スライドを示して）ショップ開設数の伸びですが、2022年12月時点で190万ショップになっています。3年前ぐらいのコロナ流行の直後に、相当伸びています。その時は攻めや守りを考える余裕はなく、当時の記憶を思い出せるエンジニアがあまりいないというのが通説です。
今やるべきことや「BASE」で開設されたショップのサイトへの負荷など、自分たちが想定していた5年先がいきなり来た感じで、「3年後には12倍になっているから、3年後に備えて作ろう」みたいことはなんとなく思っていても、1ヶ月でいきなり目の前に来るとは誰も思っておらず、すごいことになったので、みなさんきちんと準備をしておくといいと思います。
サービス提供開始10周年を迎え、直面している課題
ここからが本題です。「BASE」は2022年12月11日でサービス提供開始から10周年を迎えました。上場は2019年10月25日なので、ここから数ヶ月でコロナ禍に入るというタイミングだったかなと思います。
自分が入ったのは「BASE」の初期ではなく、ちょうど半分ぐらいでジョインしたので、最初から「BASE」のすべてを知っていたわけでもないし、今でもわからないことがわりとあるというのが現状です。
最近だと、「ここのコードにバグがあって、URLエンコードしているコードがあるんですが、知っています？」と聞かれました。今はGitHubですが、当時のバージョン管理システムはGitLabだったり、Slackのチャットがぜんぜん違ったらしく、本当に理由が皆無なコードのせいで、不具合が出たり、問い合わせを受けたりするので、そういう闇はいまだにけっこうあります。
サービスリリースから10年の間に機能がたくさん増え、機能自体はクローズするのですが、コードが消えているわけではないということがよくあると思います。コンテナやKubernetes化などをサービス全体でやっている会社さんもあると思いますが、うちはEC2が現役で、これはネガティブな感じではありません。
しかし、PHPのバージョンがちょっと古かったり、フレームワークもEOLを迎えています。最近だと、AuroraのMySQL5.65が、V1のアプデを無事終了させて、ホッとしたのも束の間、1週間後にそのバージョンがもう1度、EOLみたいになるというので、ここを担当している人の気持ちを考えると、とてもつらいのですが、技術さんとも同じ話をしました。つらいですね。
古いサービスや、古いコードは一定あるのですが、やはりサービスは動いており、多くのユーザーに使われているという現状をリスペクトしないといけないよねと日々話しています。
2017年から取り組んできたこと
自分が2017年に入ったタイミングで、たぶん、1度も検討されていなかったであろうPHPのアップデートがプロジェクト化されて、全部のコードにテストコードを書くという、けっこうすごいことをやっていました。
僕も普通に機能開発をやっていたのですが、興味があったため参画していました。あと、最初に見たメンテナンスがAWSのVPC移行でした。今は立ち上げると、だいたいVPCに入っているじゃないですか。
VPCに移行しようみたいな、今考えると「よくやったな」というのがあって、EC2-Classicが動いている素朴で単純なシステムを、けっこうがんばっていました。今でもそうですが、ビジネス的な機能開発も並行して進めていました。
DBのAurora化など、技術的投資みたいな部分は日々やっていて、5.6から5.7にするのもそうだし、そもそもDBをAurora化するというのもやっていました。あとは2020年頃、ちょうどコロナでバタバタする直前に、フレームワークのEOLもあるし、これ以上はしんどいよねと、「BASE」はネットショップ作成サービスですが、ネットショップで商品を貯める場所、カート部分のリプレイスプロジェクトを始動しました。
CTOの僕もここでがっつりコードを書くという体で（プロジェクトを）立ち上げたのですが、コロナの影響による負荷対応で全部飲まれてしまい、メンバーがすごくがんばってくれました。EC2は今でも運用していますが、カートの部分はコンテナやFargateにしたり、モノリシックですごく大きいコントローラがあったのを、モジュラモノリスでリアーキテクチャ戦略を進めています。
うちの会社では、新入社員が入社した時にだいたい僕がオリエンをするのですが、いきなり機能開発を全部止めて技術負債を解消しようとか、リアーキテクチャしようということはやらないで、機能開発を止めない漸近的なアップデートを目指しています。進みはどうしても遅くなるのですが、プロダクトを通じた価値の提供を重要としているので、そこは意識して取り組んでいます。
技術投資や負債返済をしない結果、困るのは自分か未来の同僚
技術投資や負債返済をけっこうがんばっていますねと言っていただくことが多いです。特にIPO直後だと金銭的な面からも、「そういうことができるようになって羨ましいです」という言葉をいただいたのですが、IPOしたから負債返済ができるようになったというわけでは なかったと思っています。
サービスリリースから3年、4年ぐらいは返済する場合じゃなくて、今も生きるのが精一杯だったんだろうなというコードや、システムの部分は確かに見えました。
ただ、やはりどのフェーズにおいても、今いるメンバーが、今の課題や技術負債に対してここに投資したいと思う覚悟は必要なのかなとは思っています。当然、CTOはその先導をする必要があるし、現場にいるメンバーたちが、いつか誰かがやるだろうと思っていても、やらないんですよね。後で困るのは自分か未来の同僚で、たいていの場合は未来の同僚ですよね。
もしかしたら自分が辞める可能性もあるので、なんとも言えませんが、だいたい困るのは自分が見える部分です。なので、そこに困らないように負債の返済や投資をしていこうとしています。
ただ、IPOでなにか変わったかというと、実際ネームバリューは当然増えるので、技術に強いエンジニアがうちの会社を知る機会はあったと思っています。そういうところでメンバーが増えたのは、よかったと思っています。
プロダクト開発における「攻めと守り」とは？
（スライドを示して）今回の登壇にあたって考えたのですが、そもそも「攻めと守り」と言われると、あまりピンと来ません。会社の技術負債の返済の点で、ユーザーに直接価値を届ける機能開発、「〜〜販売の機能」みたいなものは攻めで、技術負債の返済は守りなんでしたっけ。
エンジニアにとっては負債を解消して、より開発組織がユーザーに価値を提供しやすくする、スループットが上がるのも、普通に攻めではないか？ みたいなところもあるので、あまりそこは意識していませんでした。
セキュリティ対策もまた守りと言われます。もちろん悪意ある人から守るという意味では守りですが、技術的に守りなのかというと、あまりそうも思えなくて、安心安全なプロダクトを作ることも攻めていますよね。
「BASE」が考える「守り」とは？
（スライドを示して）守りとはそもそもなんなんだ？ と思って、社内のドキュメントをいろいろを漁っていたら、えふしんさんが2022年のアドベントカレンダーで、ちょうどいい記事を書いているので、後で読んでください。けっこういい感じのことを書いています。
そこを抜粋すると、うちは決済のサービスも提供しているので、24時間365日、正しく決済が動くことを担保するのは、非常に「守り」の作業になります。システムは何もしなければ壊れないのではなくて、何もしないと壊れるというのがあって、そこを守っていくことがすごく大事です。なので、きちんと人を当てましょう。機能開発がないからといって、人を当てないのはやめましょう。
不正決済もユーザーにとっては、なにもしていないのに損害を受けてしまうことにつながるので、そこは守りの開発ですよね。ほかにもユーザーからの問い合わせに対応するのは、エンジニアにとって少し大変な作業だったりする部分もあります。
今、自分の機能開発に集中したいとか、技術投資をしたいという時に、大変な部分ではありますが、使ってくれるユーザーがいるからこその自分たちのシステム開発なので、ここに対応していくことが守りなのかというと、ちょっとここにも諸説あります。
自分たちのプロダクトを守っていくこと、ブランディングを守っていくことは、なんなら自分たちを守っていることに近いですね。なので、プロダクト開発している僕のチームでは現在、リリース後の問い合わせ対応までやっていますが、特に入った直後の人に絶対にやらせるようにしています。
「攻めと守り」はどっちもやるのが当たり前
内部統制やJ-SOX対応に関していうと、けっこう守りの部分でもあります。実際に、今回登壇している中だと、うちだけIPOがあるのですが、IPOをする前後にあたって、自分たちのシステムやデータがどのように統制を取られているかを、きちんと管理することをけっこう求められました。
例えば、ソースコードのデプロイは、何人かにレビューをされていることが重要なのですが、ふだんエンジニアとしてコードを書いていると、ここって何の本質があるんだろう？ みたいなことを、思ってしまう部分がなくはないです。
これを守っていくことで、BASEという会社が株式市場にいられて、ユーザーにより広く価値を届けられることにはなるので、とても重要です。ただ、対応しているチームと揉めることもある部分なので、そこが一番大変だなと思っています。
プロダクトを作る上で、これらの守りの要素は当たり前のようにやることだと思うし、Webアプリケーションを作って運用しているのなら、「まぁそうですよね」という感じなので、俗に言う、攻めと守りのバランスというよりも、どっちもやるのが当たり前だみたいなところはあります。
ただ、この守りの開発の部分は、モチベーション管理みたいな部分がちょっと難しいところもあって、なんで今これをやらなきゃいけないんだろうとか、これってやらなくてもいいのでは？ と思ってしまいがちになるので、価値をきちんと評価してあげるのは、日々やっていかないといけないなと思っています。
なので、「BASE」はこれからも攻めと守り、どちらもバランスとかではなくて、どちらも自由になることを考えて、ユーザーによりよいプロダクトを提供していければと思っています。
なので、エンジニアを積極採用しています。Webアプリケーションエンジニア、フロントエンジニア、エンジニアリングマネージャー、SREマネージャーですね。さまざまな事情で、今僕がチームのマネージャーをやっていて、良くないと思っているので、ぜひお願いします。ありがとうございました。
（会場拍手）
