月額マイカーリース「おトクにマイカー 定額カルモくん」を提供するモビリティサービス事業部では、事業の成長フェーズや、解決したい課題に合わせて技術選定をして開発環境を変えてきました。これまでの変更背景や具体的な取り組みについて事業CTO 梅本にお話してもらいました。

SPAとサーバレス体制に切り替えて開発速度が5倍に

――2018年5月に梅本さんが入社して、まず取り組んだことは開発環境の変更だったと聞きました。

入社時のナイルではブランディングの目的もあり、会社としてScalaに注力していました。定額カルモくんの立ち上げもそのタイミングだったので、Scalaによるサービス開発が行われていました。事業やサービスをありきというよりは、技術発信を強化しようという文脈での言語選定だったんですよね。

また、DDD（Domain Driven Design）で設計していたんです。それは、堅牢なサービスを作る上では有効な手段ではあったのですが、立ち上げフェーズのカルモには見合っていないと考えて、入社直後に開発言語や環境を変えたいと提案をしました。

ただ、リリースしたばかりということもあって、すぐに変えることに難色を示されたんです。そこで、2～3ヵ月かけて事業責任者を説得して、切り替えました。

――実際に切り替えるまでは時間がかかったんですね…。そこまでして切り替えようとした理由はなんだったんですか？

理由は2つあって、1つは開発スピードを上げること、もう1つは運用コストの削減です。

DDDでの設計は、機能追加や改善に時間がかかる上に、インフラコストや監視体制なども含めた運用コストが結構かかっていたので、そこを見直したかったんです。

ScalaとDDDをしっかり使いこなせば、サービスの堅牢さや保守性の面で強みにつながります。しかし、開発スピードを考えると、全方向的に堅牢にする必要はないと判断しました。もちろんセキュリティ面など守るべきところは守る前提ですが。

――では、ScalaとDDDに替わって取り入れたのはどういうものですか。

具体的に行ったのは、SPA（Single Page Application）とサーバレスでの開発体制に切り替えたことと、kintoneを導入したことです。

SPA、サーバレス体制への切り替え

開発スピード改善と運用コスト削減を実現するために、メンバーに得意な言語のヒアリングもしながら技術選定を進め、最終的にVue.jsに切り替えることになりました。

別の候補としては、PHPとLaravelの組み合わせが挙がっていました。それを取り入れれば、メンバーにPHPでの開発経験があったので教育コストはかからないのですが、運用コストは悪化する可能性があったんです。

そこで、今後の事業全体の成長を考えた際に学習コストをかけてでも新しい技術に切り替えるべきだと判断しました。

kintoneでのデータ管理

もう一つ並行して取り組んだのはkintoneの導入です。当時、一部のデータをGoogleスプレッドシートやExcelで管理しており、セキュリティやデータ管理の観点で一部課題がありました。

そこで、「情報セキュリティ」と「データ信頼性」を確立するために、データのクラウド管理体制を構築していったんです。

切り替えの交渉には時間がかかりましたが、切り替えが決まってからは2ヵ月半でやりきりました。

――そんなに早く対応できたのはどうしてでしょうか。

私ともう一人のメンバーが、前職でSPA実装経験があったのは大きいですね。前職はAngularとRiot.jsだったので、厳密にいうと開発言語は違うのですが、Vue.jsだけキャッチアップすればいい状況だったんです。

ほかのメンバーも学習しながら作るということで、進めることできました。

――この切り替えによって、どういう点が改善しましたか。

まずは生産性と柔軟性が大きく向上しました。結果的に開発スピードが5倍になって、週1回ペースでリリースしていたのが、1日数回できるくらいになりましたね。

元々Scalaの中にフロント、ビジネスロジック、データ管理と3つ全部ある状態だったのを、フロントはVue.js、ビジネスロジックはサーバレスのLambda、データ管理はkintoneと疎結合にして、影響範囲が小さくなるようにしたんです。

その結果、インターフェースのお約束を守り、フロントならフロントだけを考えれば絶対に問題ない状態になりました。

それまでは、週1回のリリースタイミングを逃すと、簡単な修正でもオーダーをもらってから最長2週間かかってしまっていたのが、内容によっては当日リリースできるようになって。これは現場メンバーからも高評価でした。

また、サーバレスに切り替えたことで、従量課金になったこと、サーバ予備費が不要になったことで、5分の1くらいまでコスト削減できましたね。

Jamstack化による運用コスト削減とSEO改善

――SPAにしてから2年足らずでJamstack化に取り組み始めたと聞きましたが、その経緯を教えてください。

2018年にSPAに切り替えたときは、まだJamstackがそこまでメジャーじゃなかったのですが、2020年に入ってよく見るようになり、実用できそうだなと感じていました。

SPAの課題感としては、最初にページを開くときの遅さで、レンダリングに時間がかかってしまうことがSEOと広告評価の観点からデメリットになっていました。SPAでリリースした後にSEOや広告の成果が一部悪化したこともあって、サイトのトップページだけ静的に作り直した経緯があったんです。

その結果、静的ページと動的ページの二重管理が発生したり、管理運用工数が増えてしまったりすることが課題としてありました。

そこで、トップページだけでなくサイト全体のSEO評価を上げることと、静的ページと動的ページの二重管理問題を解決するために、実用できそうなタイミングでJamstack化を進めることに。具体的に取り組んだのはGatsby.js、microCMSの導入です。

Jamstack化の推進とGatsby.jsの導入

Jamstackは現行のサービスサイトとの相性が良く、課題であるSEOやページ表示速度に対して大幅な改善が期待できるので採用しました。

そして、Jamstack系フレームワークの中では、開発や運用のしやすさで優位に立つGatsby.jsを選定したという流れです。

microCMSの導入

静的ページと動的ページの二重管理問題で、「お知らせ」などサイトに掲載するコンテンツを都度コーディングしてリリースし、更新しなければなりませんでした。そこで、microCMSで管理し、自動的にGatsbyでページ生成して表示できるように変更しています。

――それによって、課題解決につながりましたか。

そうですね。二重管理問題がなくなって作業工数が削減できましたし、切り替えた範囲でのSEOは改善されています。

それまでは、SPAで作った部分と、マスターデータ管理が自動同期されていない状況でした。Jamstackになるとマスターデータの変更をトリガーにして、自動的にソースのビルド・デプロイが走り、サーバにアップされて、ユーザーがみるサイトコンテンツにも自動反映されます。都度、エンジニアとコーダーに実装依頼する工数がなくなったのは大きいですね。

長期インターンが実装を進める、スマホアプリのクロスプラットフォーム化

――会員向けのスマホアプリも、立ち上げから半年ほどでクロスプラットフォーム化を進めることになったんですよね。

スマホアプリ開発の経緯からお話すると、それまで定額カルモくんの既存会員様の、お支払いやカーメンテナンスなどに関する対応は、電話やメールで行っていました。

今では会員数も多くなり、顧客対応にかかる工数もその分増えているので、会員様自身でスマホアプリから申請できるようにしたり、機能面でもWebサービスからスマホアプリ必要になってきたりしたことから、開発が始まりました。

最初は内製を検討していたのですが、当時は事業が成長しているとはいえ、どこまで伸びるのかジャッジしづらい状況だったんです。アプリエンジニアを採用する工数やリスク、社内リソース投資の優先順位などを鑑みて、アウトソースすることになりました。

データ設計、画面設計、要件定義までを社内で行い、その後の実装を開発会社に委託しています。このときは、スマホアプリ開発で一般的に使われているSwiftとkotlinを使いました。

――その後、内製に移行したそうですね。

2020年に立ち上げたつくばオフィスに勤務している、優秀な長期インターン生たちによる開発体制ができてきたことで内製化に踏み切りました。そこからクロスプラットフォームに移行していきます。

クロスプラットフォームについては、メリット・デメリットを把握した上で、カルモでやりたいことは実現できるし、導入するメリットがあると判断しました。

言語としてはFlutterを選択しています。ReactNativeとも比較検討したのですが、ReactNativeのメリットを活かそうとすると、EXPOというフレームワークが魅力だったのですが、中長期的に見てリスクがありました。

ただ、FlutterにするとGCP（Google Cloud Platform）とFirebase、Googleが提供しているサービスで揃えることになるので、プラグインの充実ぶり、バージョンアップや更新管理の楽さ、セキュリティなどを踏まえて選んでいます。

――Jamstack化も、クロスプラットフォーム化も、つくば拠点の長期インターン生たちが実装を担当しているそうですね。

今は優先度の高いところから段階的に切り替えているところですね。社員は上流の企画や要件定義、技術選定、メンバーへのディレクション、コードレビューをメインで行い、実装部分は長期インターン生がメインで進めるという役割分担を進めています。

共通部品作成、プログラミングのコーディングルールづくりなど、一般的なテックリードが対応するようなことは社員が担当していますし、重要度や緊急度の高い業務の場合は社員が手を動かすことももちろんあります。

技術力を伸ばすことが、事業やサービスのグロースにつながる

――これまでの変遷を聞いていると、新しい技術は積極的に取り入れるようにしているんですね。

そうですね、私自身も新しい技術に挑戦するのが大好きですし、エンジニア個人の技術力がビジネスの成長を支えるのは間違いないため、企業として新しい技術を学ぶこと自体は奨励しています。テクノロジーが先か、事業が先か、これは優劣の問題ではなく、テクノロジー・技術により競合との差別化を図るTechDrivenなビジネスモデルかそうでないかによる違いだと考えています。

参考： 経営者の隣でビジネス力を鍛える―「事業家集団」ナイルのエンジニアが目指すこと

――エンジニアメンバーの育成や採用方針についても、サービスグロースに貢献できることが要件になるのでしょうか。

もちろん、事業家マインドをもってサービスグロースさせられる、事業を作ることができるエンジニアを増やしていきたいとは思っていますが、入社直後から全員にそれを求める必要はないと思っています。

むしろ、3年くらいはひたすらプログラミングに取り組み、エンジニアとしての技術力を身につけた上で事業にコミットしていってもらうほうがいいと考えています。

事業へのコミットやサービスを作りたいという思いを持っていても、技術力がなければ実現できませんから。

Why（なぜやるのか）、What（何をやるのか）、How（どうやるのか）でいうと、Howができてない状態でWhy、Whatばかり考えても机上の空論になってしまいます。なので、エンジニアとしてのアーキテクト思考や技術力をベースにして、事業やサービスを作る力をつけていってもらいたいです。

画像参照元：
Scala：https://www.scala-lang.org/
Vue.js：https://jp.vuejs.org/index.html
TypeScript：https://www.typescriptlang.org/
Node.js：https://nodejs.org/ja/
Gatsby：https://www.gatsbyjs.com/
Jamstack：https://jamstack.org/
Swift：https://www.apple.com/jp/swift/
Kotlin：https://kotlinlang.org/
Flutter：https://flutter.dev/