identify CTO兼「ワインと鍋」オーナー岩崎さんに聞く。過去の技術選定とそこから得た学び

identify株式会社は、個人が販売した動画素材を企業が購入して、マーケティングへ活用することを支援する「DeLMO」というクリエイタープラットフォームを運営しています。その「DeLMO」では、クリエイターがスキマ時間に動画を撮影・販売し、報酬を得ることができる複業支援サービス「DeLMO for creator」と、企業が縦型ショート動画素材を簡単に収集し、クリエイティブ制作に活用できるサービス「DeLMO for advertiser」の2つを提供しているのです。

同社の取締役CTOを務めるのが岩崎 裕馬さん。彼は水天宮前（茅場町、人形町、日本橋）にあるレストラン「ワインと鍋」のオーナーでもあるという変わった経歴の持ち主です。これまで岩崎さんは、CTOとしてどのような技術選定を行ってきたのでしょうか。

GoやNext.jsを採用。“攻めた”技術選定をした意図とは

――このインタビューでは、岩崎さんがidentifyで取り組んできた技術的意思決定の事例について伺います。

「DeLMO」の技術選定においては、「長期的に見た場合のプロダクト開発効率」「エンジニアの採用難易度」「自分自身にとっての面白さ」という3つの観点を大切にしました。

まず、サーバーサイドの言語としてGoを採用したことについて話します。私がソフトウェア開発において大切にしているのは、改善をスピーディーにくり返せることです。プロダクトを作る際には、自分たちの立てた仮説がそもそも本当に正しいのかわからない状態で開発を進めることが多いです。もし仮説が誤っていたり、方向性を変えるべきだったりする場合には、柔軟に軌道修正することが必要になります。その際、Goではある程度の型の支援があるため作り直しやリファクタリングが容易なんです。何か問題があっても、ビルドが失敗するためすぐに気づけます。

それから、コードベースの規模が小さくても大きくても、かけたエネルギーに対して書けるコードの量が一定であるのがGoの良いところです。Goでは、プロダクトの規模が小さいフェーズでも、大きくなってからも、エンジニアが1のエネルギーを使ったら1のコードを書けます。

言語やフレームワークによっては、プロダクトの規模が小さいうちは1のエネルギーで10のコードを書けるけれど、規模が大きくなったら10のエネルギーでようやく1のコードが書けるといったように徐々に開発生産性が落ちるものもあります。Goの場合はそれがないですね。

開発効率という観点で言えば採用技術としてRuby on Railsなども候補に挙がりましたが、現代のWebアプリケーションはSPAを取り入れていることによってフロントエンドとバックエンドが分離されることが多く、バックエンドはJSONを返却する役割に徹することがほとんどです。そこで、「Goを使ってもそこまで開発効率が変わらないのではないか」と考えました。

「エンジニアの採用難易度」についても話すと、RubyやPHPなどは採用候補者がたくさんいる言語であるものの、初学者のエンジニアの割合も高いため、スキルの高いエンジニアかどうかの判断が難しいかもしれないと感じていたんです。反面、当時Goをやっていたのは技術的好奇心の強いエンジニアが多かったため、Goを採用することでスキルの高い方と出会いやすくなるのではないかという感覚を持っていました。

また、「自分自身にとっての面白さ」については、私は個人的に新しい技術を使うのが好きなので、そういった点からもGoを面白いと感じています。それに、Goは使用できる文法が良い意味で限られているため、コードを書く際に迷いが少ないです。仮にモチベーションが低いときであっても、一定の開発生産性をキープできます。

――フロントエンドに関してはいかがですか？

フロントエンドはNext.js＋TypeScriptを採用しています。私がidentifyに参画してプロダクトを開発し始めたのが2019年7月なのですが、当時はVue.jsとNuxt.jsが全盛期でした。でも、「フロントエンドにおいてもいずれは型安全性が重視されるようになるため、Vue.jsとNuxt.jsではなく、TypeScriptフレンドリーなフレームワークが流行するだろう」と予想していました。そして、私はモダンなフロントエンド開発のスキルがそれほど高くないため、何か大きめのフレームワークのエコシステムに乗って開発を進めたいという思いもありました。

そんなタイミングで、2019年7月にNext.js 9がリリースされ、Dynamic Routingがサポートされたんです。これなら実戦投入できると思い、採用を決めました。当時、フロントエンドのスペシャリストであるmizchiさんが「Next.jsを使うといい」という話をしていたのも、導入する理由になりました。

結果的に、サーバーサイドはGoでフロントエンドはNext.jsという構成はスタートアップでは当たり前に使われる構成になりました。これによって、エンジニアの採用にもかなりプラスの影響が出ています。

それから、フロントエンドとサーバーサイドの両方に関係する話として、GraphQLを使いたかったためgqlgenのライブラリを採用しています。知人であるgfxさんから「GraphQLはいいぞ」という話を聞いていて、きっと今後流行するだろうなという予想をしていました。私はgfxさんの技術的な審美眼を信頼しており、実際に調べてみると利点が大きかったため、採用を決めました。

CIや単体テストなどを初期フェーズから整備しておくべきだった

――ここまでは技術選定のポジティブな点ですが、その逆に反省点はありますか？

事業を立ち上げた当時は、売れるプロダクトを作ることが第一だと考えて、機能開発を優先して技術的負債を蓄積してしまいました。ですが、それらを後から解消するのにかなり苦労したため、もっと早めのフェーズから課題に向き合っていくべきだったと思います。

――この記事を読まれる方のなかにも、同じようにアーリーフェーズのスタートアップで働いており、なるべく早急に売れるプロダクトを作らなければならない状況のエンジニアもいるかと思います。その方々に、ご自身の経験を踏まえてアドバイスはありますか？

アプリケーション開発の定石を理解したうえで、100点は無理でも70点くらいの開発環境の整備を目指すのがいいと思います。“70点くらいの状態”の具体例を挙げると、1つ目はCI環境を構築して、Lintや単体テストなどが自動実行される状態を作ることです。

2つ目は単体テストを書いておくこと。決してすべての分岐を通るようにする必要はなくて、特定メソッドの1つの分岐しか通らないテストだとしても構いません。テストが全くない状態のアプリケーションにテストを足していくのと、最低限のテストが書かれている状態のアプリケーションを改善していくのとでは、労力がまるで違います。

3つ目は、インフラの環境をなるべくマネージドサービスに切り替えること。私たちはかつて、Jenkinsを用いてジョブの実行などを行っていました。でも、サーバーの管理作業を自分たちで行う必要があるため運用の工数がかかるとか、ミドルウェアやインストールされている言語のバージョンを上げづらい、スケーラビリティに難があるなどの問題が生じていたんです。

現在はJenkinsを脱却して、すべてのジョブをCloud Run jobsとBatch for Google Cloudで動かしています。これによりシステムのポータビリティが向上し並列実行も容易になりました。「DeLMO」では事業の特性上、1日あたり数百件から数千件の動画の変換処理が発生します。そうした処理をBatch for Google Cloudで動かせるようにしたことで、変換がスピーディーに終わるようになりビジネス改善やコスト削減につながりました。

採用するライブラリを“取り替え容易な状態”にしておく

――他の技術選定の事例はあるでしょうか？

これは失敗談なのですが、社内向けの管理画面を作る際に、「UIライブラリを使って楽ができないだろうか」と思ってAnt DesignやHeadless UIを採用しました。Ant Designは、中国のAlibaba社が開発した、UIを作成する際に役立つ多数のコンポーネントを備えたUIフレームワークです。

また、Headless UIについては私たちが用いているTailwind CSSとの親和性から選択肢に上がりました。素早く管理画面を作っていく必要があったことや、社内向けの管理画面だから3年くらい経てば作り変えればいいという思いもあり、これらのライブラリの導入を決めたんです。

Ant Designはとても便利なライブラリなのですが、Reactのバージョン18との相性が悪く、特定のコンポーネントがかなりCPUを消費するようになってしまいました。Ant DesignのISSUEなどを追ってみたところ、その問題が解消される見込みはありませんでした。また、思っていたよりもAnt DesignやHeadless UIでの開発がしづらかったこともあり、当初の予想よりも早めに別のライブラリに切り替える必要性が生じてしまったんです。

――この事例を踏まえての学びはあるでしょうか？

これはUnix哲学にも通じる部分ですが、なるべく特定の役割だけを担うような薄いライブラリを使って、交換が容易な状態を維持しておくべきだと思いました。Ant Designはライブラリの担っている役割が広くて、UIに関する機能とFormの操作に関する機能をどちらも持っているんですよね。それもあり、React Hook Formを入れづらかったり、TypeScriptによる型の支援が受けづらかったりしました。幸い、管理画面の一部でしか使ってないライブラリなので、多くの苦労をせずに取り除けると予想しています。

今後、Headless UIはshadcn/uiなどに切り替えていく予定です。余談ですが、これからのフロントエンドのUIライブラリにおいて大事なのは、「AIフレンドリーであること」だと私は思っているんですよ。基本的に、デザインのトレンドは数年スパンで変わりますから、どれだけ優れたライブラリであっても絶対に技術的負債になります。

今後はそうした技術的負債を、人間ではなくAIが返済するような世界になっていくと予想しています。だから採用するUIライブラリも「AIが理解しやすいコードかどうか」を重要な判断軸にすべきだと思っていますね。

副業のメンバーに「わかりやすい正解がある仕事」をお願いする

――それ以外の工夫はあるでしょうか？

ライブラリのアップデートや型定義・単体テストの追加、技術的負債の解消といったタスクは「必ずやる必要があるが緊急度は低い仕事」です。そういった業務の多くを副業のエンジニアにお願いしているのは、identifyの開発組織の特徴だと思います。

――副業のメンバーにうまくワークしてもらうために重要なことはありますか？

まずは先ほどの説明にも通じますが、Lintや単体テスト、CI環境をきちんと整備することが大事だと思っています。私は副業や業務委託で参画した方に「既存コードを壊していいですよ」と言っているんですよ。要するに、機能が壊れることを恐れず、どんどんリファクタリングをやってほしいんです。仮に既存機能が壊れてしまったとしても、CIで守っているからすぐに気づけます。

それから、「わかりやすい正解がある仕事」をお願いすることですね。たとえば「○○のライブラリのバージョンを○○に上げて、その状態ですべての機能が動く状態にしてほしい」とか「テストのカバレッジが○○％だけれど、これを○○％まで上げてほしい」などの要望であれば、目指すべき成果が明確なんですよね。認識の齟齬が生まれにくいので、副業のメンバーにも任せやすいです。

「すべてがアイデンティティになる時代をつくろう」

――今後、岩崎さんがidentifyで実現したいことについても教えてください。

identifyは「すべてがアイデンティティになる時代をつくろう」というビジョンを掲げていて、この状態に1歩でも近づけるように尽力していきたいと思っています。個人的な話をすると、私はもともと家が貧しかったのと低学歴だったため、いざ働くとなったときに就職先の選択肢が少なかったことを覚えています。そういった方々の選択肢を広げることに協力できたらと考えています。

これまでどんなキャリアを歩んできた人でも、自分の個性を発揮して生きていける世界を作れたらいい。テクノロジーを活用することで生活や仕事のマイナスを取り除いて、みんなが楽しく生きられるような状態にしていきたいです。

――すてきなビジョンだと思います。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

「何の技術を採用すべきか」に、わかりやすい正解はないと思っているんですよね。でも、技術的意思決定において「何を考慮すべきか」については、方法論がパターン化されていると思うんですよ。そういった知識を持っておくと、自分自身も明確な判断基準に基づいて決断できますし、他の人たちにも納得感を持ってもらいやすいと思います。特定の事例を学ぶというよりも、事例の裏側にある“技術的な意思決定の意図や背景”を学ぶことが大切です。

そして、その意思決定に用いる変数は事業の状況や世の中のトレンドによっても変化します。たとえば、最近では生成系AIが流行しており、それが技術選定にも影響を与えています。数年前までの自分であれば、“AIフレンドリー”という言葉は絶対に使っていなかったと思うんですよね。だからこそ、適切な意思決定ができるように、技術選定の方法論やその判断材料となる情報などを、常に学んでいくことをおすすめします。

取材・執筆：中薗昴

撮影：山辺恵美子

取材協力：ワインと鍋

提供：株式会社Haul