長期で勝つための柔軟なプロダクト開発を可能にする「プラガブル」という設計思想
「たった0.2.%しか出来てない」
CXプラットフォーム「KARTE」を提供するプレイドでは、よく社内でこんな話をします。プレイドでは「あらゆるサイトにKARTEが入り、横断的なデータをもとにエンドユーザに直接価値提供出来ている状態」からがスタートで、そのデータを使って何をするか？が重要だと考えています。
長期での目標に向かってプロダクトを開発していくためには、その設計思想もビジョンにフィットしたものでなければいけません。今回は、KARTEを支える「プラガブル（接続可能）」というプロダクトの設計思想について、CTOの牧野に語ってもらいました。
牧野 祐己
プレイドCTO。東京大学工学系研究科で修士課程卒業。2009年から2014年まで、IBMソフトウェア開発研究所で研究開発業務に従事。2015年にプレイドに参画し、データ分析エンジンの研究開発を担当。
長期的な視野に立った柔軟なプロダクト設計
────KARTEには「プラガブル」というプロダクト開発思想があると聞きました。「プラガブル」とは一体、どういったものなのでしょうか？
「プラガブル」は接続可能という意味で、複数のプロダクトがつながるKARTEの特徴を表現しています。KARTEがこうしたコンセプトを持つに至った背景には、開発初期から長期的なビジョンを持っていたことがあります。
Web上には、サイトを運営している人と、サイトを使うユーザーがいます。ただ、Webの仕組みがコミュニケーションを円滑にするものになってない、そのことに課題を感じていました。サービスの提供者側はユーザーを数字として見ていて、エンドユーザーも提供側を人間として見ることが少ない。リアルな店舗では、売る人と買う人がいて、そこは人間同士のコミュニケーションが存在しています。
単純にリアルなものをWebで実現しようというわけではありませんが、人間らしいコミュニケーションが実現できるようなプラットフォームをつくりたいと初期から考えていました。その構想を実現しようとプロダクトを作りつつ、活用例としてEC領域向けにウェブ接客ツールとして提供したのが初期です。
長期的な視点を持ちながら開発を行い、実際に使ってもらいやすい領域に対応するために短期的な開発を行うというスタイル。長期的な視点では抽象的な用途になり、柔軟性が高くないといけなかった。そこで、KARTEはスキーマーを規定しない、スキーマーレスであり、その中の1つに「プラガブル」というコンセプトが掲げられました。
───柔軟性を高く保つ「プラガブル」という開発思想のもと、KARTEではどのような開発が行われているのでしょうか。
KARTEには、「知る」「合わせる」という特徴があります。プラガブルは、これらを拡張し、いろいろなことを可能にしています。
「合わせる」ための、エンドユーザーとコミュニケーション手段は多様化しており、アクションのすべてをKARTE内部で開発するのは一苦労です。KARTEでは、こうしたアクションをプラグインで加えていける設計になっています。
なるべく、必要なアクションをすでに外部で実現されているようなサービスを利用して、プラグイン化し、よりユーザーのためにリッチなアクションができるようにしようというのが、プラガブルな構造の狙いです。
例えば、KARTEでSMSなどのプラグインを使って外部サービスと連携させれば、SMSをはじめとする多様なコミュニケーションチャネルに合わせてメッセージが送信できます。コミュニケーションチャネルは多様でも、KARTEの管理画面からは一人のユーザーに対してどんなメッセージを送ったのかの履歴が一覧できる状態になっています。
外部サービスの不確実性をどう織り込んで開発するか
────「プラガブル」であることの利点が多いように感じますが、「プラガブル」な構造で開発することによる苦労はありますか？
プラグインとの距離感は難しいですね。プラグインへの適切な依存度と言ってもいいかもしれません。例えば、メインのデータベースにある程度アクセスできないとプラグインも価値を発揮しにくいのですが、結びつけが強すぎるとプロダクトがプラグインに依存してしまう状態になってしまい、切り離しにくくなってしまう。
最初からプロダクトの機能として開発していれば、様々なデータにアクセスできますが、プラグインだと取得できるデータを制限しないと切り離せなくなってしまいます。切り離しやすいのがプラグインの利点でもあるので、適切な距離感で開発しなければいけないのが「プラガブル」の難しさですね。
────過去、距離感を決めるのが難しかったプラグインはありますか？
いろいろありますが、選ぶとしたらチャットのプラグインですね。チャットのプラグインは、ただメッセージを送るだけではなくて、ユーザーの状態に応じてロジックを変えたりするために、どこまでプラグインがデータを把握できるようにするかは悩みました。
どこまでもアクセスできるようにしてしまうと、大量のデータを取得してしまってパフォーマンスが下がったり、メインのデータベースに負荷がかかってしまったりするので。どうやってプラグインに制約をかけるかも難しいポイントです。
────他にプラグインならではの課題や難しさはありますか？
プラグインが接続する先のサービスの安定性も課題です。KARTEはプラグインを使っていろんなサービスと接続できますが、サービスの安定性はそれぞれ異なります。時には、プラグインで接続している先のサービスが落ちていることも起こりえます。
そういうときに、どこまでKARTEがフォローするか。データを取得するプラグインが、データが取得できなかったときにどうするのか。接続する外部サービスの安定性がバラバラの中でどう対応するかはプラグインならではの課題ですね。
すべてを自社で提供していれば対応や予測もできますが、APIの向こう側では対応や予測が難しいこともあります。
────とにかくプラグイン化していると、不確実性も増えそうですが、何か制約などはありますか？
現状はほとんど制限はありません。むしろ、いろんなプラグインを作るほうがいいと考えています。ただ、依存性はなるべく排除し、本番環境への影響をなくす。ルールとして決まっているわけではありませんが、そういう方針で開発しています。
プロダクトの進化速度を上げる「プラガブル」
────「プラガブル」な構造で開発してきて、開発体制に何か変化はありましたか？
プラグインでなんでも簡単に試せてしまうので、過去には試しっぱなしが発生することもありました。その経験も経て今は、プラグインとして作るべきなのか、機能として作るべきなのか、作るときにちゃんと議論しようという話になっています。とはいえ、基本は「試してみたかったらまずは作ってみよう」という考えですね。
一時期、全部プラグインにしようという流れもありましたが、すべてがプラグイン化することでのやりづらさや、ちゃんとメンテナンスすることの難しさなども議論されました。「そこまでしてすべてをプラグインにしなくてもいいよね」ということで、今は落ち着いています。
────現在、KARTEではプラグインと機能をどう住み分けているのでしょうか。
プラグインで提供していたものが、KARTEの機能として実装されることもあります。例えば、レコメンドはプラグインで提供してみた後、KARTE本体に機能として実装されました。
プラグインとして提供してみて、「もっとカスタマイズしたい」「データ管理もKARTE上でやりたい」というニーズが出てきたため、KARTEならではのレコメンドができそうかを議論し、機能として開発したんです。
他にも、チャットも最初は外部サービスを使ったプラグインとしてスタートしました。できることは限定的でしたが、チャットはエンドユーザーに対するアクションとして非常に重要です。チャットをプラグインで提供しながら、議論し、KARTEの機能として提供することになりました。
────実装すべき機能を見極める上でも「プラガブル」は相性がいいんですね。
そうですね。プラグインで外部サービスと連携させて、実際に使ってみてもらい、KARTEと相性が良ければ機能化する。このサイクルが回せれば、プロダクトの進化速度も上がります。過去には、プラグインで提供していて、KARTEの機能としては提供しないという判断をしたこともあります。プラガブルが開発における決断のスピードを上げていると感じますね。
KARTEは、機能も一旦プラグイン化してつくることも可能なアーキテクチャになっています。本機能としてではなく、まずはプラグインとして出すことで素早くユーザーからのフィードバックが得られます。実際に機能としてリリースしたときに使ってもらえそうなのかどうかが、検証しやすいんです。
例えば、プラグイン化されていれば、特定のKARTEユーザーに対してのみ、テスト的に機能を追加してもらうこともできます。そして、使ってみてもらって、問題なければ機能の実装を進めていく。プロダクトの開発初期からすべて同じプラグインレベルで扱うことが可能な構造にしてきたことで、こうした開発の進め方も可能になっています。
「プラガブル」でKARTEのエコシステムをつくる
────「プラガブル」はプロダクト開発にかなり影響しているんですね。
影響は大きいですね。プラグインの存在を積極的にKARTEユーザーに伝えることで、KARTEユーザー側からも「こんなサービスと連携できないの？」と聞かれることもあります。時には、自分たちが想定しているKARTEの活用領域以外の要望も寄せられます。KARTEユーザーからの要望が寄せられやすく、プラグインで素早く要望に応えることが可能な構造のおかでで、プロダクトの進化速度が上がります。
KARTEは、いろんな領域で活用される抽象的なプラットフォームを目指しています。様々なフィードバックを得ながら、多様な領域に染み込んでいく必要があります。様々な業界でのKARTEの使われ方を見て、僕たちもラーニングしていきます。
ただ、いろんな要望に全て対応していくとキリがありませんし、コストも膨大になります。多業種にKARTEが広がっていくためには、自分たちで作るものはシャープにしていく必要がある。「プラガブル」な構造になっていることで、集中して開発すべき価値が明確になります。
────「プラガブル」な構造のKARTEは今後どう進化していくのでしょうか。
開発の思想としては、将来的にKARTEをサードパーティに開放するという構想もあります。初期からサードパーティーもKARTE上でプラグインを作って提供する未来を描いていました。
サードパーティに開放してプラグインにエラーが起きたり、使い勝手の悪いプラグインが出てきたらどうするか。そこも含めてKARTE上の体験になるので、どう向き合っていくかは考えないといけないですね。
また、よりよいアプリケーションを作ってもらい、利用してもらうためには、ハブとなるようなストアをしっかり作っていく必要があります。現在は、KARTEのアクションが蓄積されている「ナレッジストア」があるので、そこと上手く連携させていきたいですね。
より大きな意味でのナレッジをKARTEに蓄積していき、いろんなプレイヤーが参加したくなるようなプラットフォームとしてのストアをつくり、理想的なエコシステムを構築していきたいと思います。
株式会社プレイドでは一緒に働く仲間を募集しています！
もっとPLAIDを知りたい方はこちら
PLAIDの採用に興味のある方はこちら
CX（顧客体験）プラットフォーム「KARTE」はこちら