「LINEスキマニ」の施策リリースを最速化。サービスの根幹を支えるKARTEを使った機能開発の裏側

LINEが提供する企業とユーザーの「スキマ」時間をマッチングする単発雇用サービス「LINEスキマニ」では、チーム全体でKARTEを活用しているだけでなく、エンジニアがKARTEを活用して課題解決に取り組んでいます。

既にある機能やサービスにKARTEを加えて活用するだけではなく、新しい機能をリリースするにあたり、KARTEを活用する前提の構成を実現。企画者のアイデアをスピード感をもってサービスに反映できるとともに、エンジニアのリソースをサービス固有の機能開発に充てることが可能になっています。

今回は、LINEスキマニの佐藤裕介さん、花谷拓磨さん、鴻巣和司さんに、エンジニアがリードしてKARTEを活用した取り組みの過程を伺いました。

「LINEスキマニ」の成長を目指し、施策リリースを最速化するためにKARTEを活用

まず、サービスの概要についてお伺いさせてください。

佐藤：「LINEスキマニ」は、企業とユーザーの「スキマ」時間をマッチングする単発雇用サービスです。単発および短期アルバイトの領域を幅広くカバーしたサービスになっています。

みなさんの役割について教えてください。

佐藤：私は2018年8月にLINEに入社しました。入社当時は、LINEキャリアのプロダクトマネージャーを担当していて、現在はLINEスキマニのプロダクト全般の責任者を務めています。

花谷：私も入社は佐藤と同じ2018年です。LINEスキマニにはリリース直後から関わっており、マネージャー兼フロントエンドを担当しています。

鴻巣：2021年4月に新卒入社して、2年目でLINEスキマニに異動し、LINEスキマニが提供するエンドユーザー向けのWebアプリおよび企業向けの求人出稿画面のフロントエンド開発業務を担当しています。

サービスローンチ直後からKARTEを利用していますが、どういうきっかけだったのでしょうか。

佐藤：サービスをローンチしたばかりの頃は、なにをすればサービスの成長につながるかが不明瞭でした。一方で、過去のプロダクトマネジメントの事例から、ポップアップやバナーをユーザーごとに出し分けたりしながら素早く仮説検証を行うことが、サービス価値の向上につながるだろうと認識していました。

しかし、仮説検証のための機能は必要ではありますが、サービス開発の本質からズレます。運用系の機能開発を自社で行わない方向性で考えた結果、KARTEの導入を決めました。KARTEに決めたのは、実現できることの自由度の高さ。ほとんど迷わずKARTEを導入しました。

花谷：LINEスキマニのチームは、何を解決するかにフォーカスできていれば、手段はより良いものを選択するという共通認識があります。内製化することに固執せず、KARTEを受け入れたのは、そういう前提もあったかと思いますね。

KARTEの導入当初はどのように活用していましたか？

花谷：導入当初は、プランナーが簡単なキャンペーンを差し込むなどの使い方がメインでした。次第に高機能なことを実現したいという要望が上がるようになってきたんです。例えば、特定の行動をしたユーザーに、特定のメッセージを出す、といったものです。この時は、施策を主導するのはプランナーで、作れるところまで作り、困ったときにはエンジニアが助けてプログラムを書くという感じでした。

エンジニアが主導してKARTEを利用するようになったのはどういった背景からだったのですか。

花谷：リリースのペースをもっと早めたかったというのが大きいですね。当時のリリースペースは、二週間に一度。そのペースになっているのは、個人情報の扱いなど、さまざまなリスクを勘案したからではあるのですが、もっと早くリリースしていくことはできないかと考えていました。

正規のリリースが二週間ごとで承認もあると、どうしてもフットワークは重くなり、すぐに仮説検証はできません。検討の結果、KARTEを使えばすぐにリリースできるのでは、という考えに至りました。KARTEの設定をより高度にすべく、エンジニアがリードするようになりました。

佐藤：早くリリースしたいというモチベーションが、事業側にあるのは珍しいことではありません。素早くリリースしようというモチベーションがエンジニアにあり、リードして意思決定していったというのは珍しいことだと思いますね。

KARTEのデータにアクセスするための管理基盤を独自開発

エンジニアがリードすることで、どのような開発を行ったのでしょうか。

鴻巣：LINEスキマニは、エンドユーザー向けWebアプリケーションはJavaScriptのライブラリ「React」を使ったSPA（Single Page Application）になっています。

KARTEを使った接客の埋め込みは、ReactによるWebアプリの描画と競合してしまう面があったり、KARTEの接客内のコードだけではサービス特有のUIを実装することが困難であったりしました。そのため、KARTEの接客に合わせて、ReactのライフサイクルからUIを描画する仕組みをフロントエンドのコードベース内に含めました。

これによってKARTEを使ってユーザーごとにカスタマイズされた接客を配信できるという特性は活かしたまま、SPAの描画サイクルと競合しない、かつ複雑な体験を実現しています。LINEスキマニの既存のアーキテクチャに対して悪影響を及ぼさない形で、KARTEと連携できるようにしました。

鴻巣和司さん

花谷：LINEスキマニにおいてKARTEを通じてやりたかったことは、「データをKARTEから引っ張る」「設定をプランナーが触ることができるようにする」といったもの。この実現方法を検討した結果、KARTEに入稿するため管理画面をつくって機能化し、KARTEをデータを送る存在にしてAPI化しようとなったんです。

KARTEをAPI化するとは…？

鴻巣：KARTEを使った機能開発に関連するデータはKARTE Action Table上に保持して、KARTEの接客からアクセスする形になっています。

このデータにアクセスする方法として、KARTE仮想APIサーバーというフロントエンドコードベース上の仕組みを実装しました。これは、REST APIサーバーのように振る舞う接客を実装することで、アプリケーションコードもKARTEで保持および収集した情報にアクセスして利用できるようにするものです。

KARTE Action Tableに保持しているデータは通常であれば接客を通してのみ活用できますが、この仕組みを使うことで簡単にアプリケーションコードからも参照できるようになりました。KARTEをプランナーだけで運用すると、自分たちの要件に合致する複雑なUIは実現できませんが、エンジニアがKARTEの運用に参加することで実現できました。

KARTEを活用した機能開発の画面を見せてもらった際の様子

エンジニアがKARTEにより深く関与することで事業の成長速度が変化

エンジニアがKARTEの活用にコミットしてどのような変化が生まれたのでしょうか？

鴻巣：エンジニアがKARTEの運用に関わる以前は、フロントエンドから参照したい情報を保持するためだけにサーバーサイドの開発が行われることが多々ありました。先程の開発を行ったことで、KARTEにサーバーサイドが果たしていた役割を持たせることで、このようなケースにおけるサーバーサイドの開発をほとんどなくすことができました。これにより、エンジニアはより本質的な業務に集中できるようになったと感じます。

花谷：元々の目的でもあった、リリース速度にも大きな変化が見られました。二週間ペースのリリースは残りつつ、ライトなフローでリリースを進められるようになりました。

鴻巣：従来のリリースフローに合わせるのではなく、実行したいことに合わせて判断できるようになりました。次第に、開発の優先度の考え方の解像度も上がり、改善のトライアンドエラーがやりやすくなりました。現在では、週に複数回のリリースを実現しています。企画者のアイデアをスピード感をもってサービスに反映し、仮説検証のサイクルを回すことが可能な環境が社内で整っています。

佐藤：プロダクトマネジメント側も、リリースの影響範囲は一定ではなく、常に重厚な開発プロセスが必要なわけではないことにも気づき始めていました。早く検証したいという場合は、必要な機能を削減し、素早く検証できるライト版のフローで試せないかを相談するように変化しました。

佐藤裕介さん

鴻巣：以前は要件がしっかりまとまった状態で相談が来ていたのが、KARTEを導入した後はまだ要件が固まっていないアイデア段階から相談が来るようになったのも変化でしたね。本質的にどういった仮説検証がしたいのかを確認した上で、実行方法について話せるようになりました。

佐藤：2022年10月〜2023年1月頃の期間は、リリースサイクルが上がり、仮説検証の速度が向上したこともあって、KPIとしていた指標が約10倍の成長となりました。そのうち、約87%はKARTEのなんらかの接客経由だったのです。そのときは、バックログに積まれるアイテムを全部試してみるつもりで取り組んでましたね。振り返ってみると、変な施策もあったんですが（笑）

花谷：求人のレイアウトを1行から2カラムに増やしたら数値が良くなったので、2から3に増やしてみたんですよね。そしたら、全然結果が出なくて（笑）すぐに元に戻した施策でしたが、すぐに試してみることができたのは大きかったですね。

素早くPDCAを回していると、実行してみて「ああ、これは思いついてみたけど、要らないものだったな」と、プランナーも気づきやすくなっていきました。そうすると、本当にほしい要望だけが上がるようになって。これもKARTEの活用後に生じた変化ですね。

花谷拓磨さん

KARTEの運用に、エンジニアが関わることで、機能のリリースまでの速度がさらに向上したのですね。

鴻巣：
そうですね。プランナーとエンジニアが協業してKARTEを運用するというのは、特に新機能の初期フェーズやPoCのステップにおいて、リリースまでのスピードを早める上で有効なアプローチだと実感しています。

今回の取り組みを通して、さらに高速にリリースと仮説検証のサイクルを回すことができ、エンジニアのリソースをサービス固有の機能開発に充てることができるようになるなど、KARTEは大きなポテンシャルがあるサービスだと実感しました。

まだまだユニークな活用事例だとは思いますが、KARTEがアップデートしていけば、さらに実現できることも増えるので、KARTEのアップデートには非常に期待しています。

最後に今後挑戦していきたいことがあればおしえてください。

佐藤：「失敗のコスト」をとにかく下げたいですね。サービスを成長できている要因の一つに、どれだけの数の施策を実行してきたか、PDCAを回してきたか、というものがあると考えています。

PDCAを回すことのコストが高いと、失敗の損失が大きくなってしまい、損失を回避しようとすることで、PDCAを回すコストがさらに高くなってしまう。そうすると、ビジネス側とエンジニア側は互いに厳格さばかりを求めてしまい、結果的に信頼関係が崩れてしまうと思っています。

圧倒的に失敗のコストを下げるために、KARTEを活用していくだけでなく、組織としても改善を重ねていけたらと思いますね。

鴻巣：エンジニアとしてはできるだけ「安く失敗」できるための機能開発にKARTEを使って取り組んでいこうと思います。