本記事の目次 （→シリーズの特集ページ）
本記事の目次 サービスイン3か月後にクラウドもアーキテクチャも変更ですと!?
――「OK SKY」とはどのようなサービスなのですか？
小林：コンシェルジュサービスと弊社では表していますが、Webサイトや店舗へ訪問されるお客様にチャットを通じて接客を行うサービスです。iOSやAndroidのアプリケーションで提供しています。
OK SKYのシステムはチャットの相手となってお客様に接客を行い、お客様がお探しの商品や知りたいことが何かを聞き出します。それから、企業や店舗のお客様対応係の方がその内容を踏まえ、クロージングに至るまでの対応を行います。また、人員が少なく対応係を置く余裕がないという企業様、店舗様には、弊社のスタッフが最後の対応まで請け負うサービスも提供しています。
問い合わせ対応では、こんにちはから始まって、ご要望なんですか？ 商品ですか？ お好みは赤ですか白ですか？ デザインどんな感じがいいですか？ とお客様からニーズを聞き出していくわけですが、このやり取りはある程度パターン化できるものなんです。さらに、このやり取りが問い合わせ対応にかかる時間の実に70％を占めます。OK SKYは、このパターン化できる最初の70％をシステム化することで、問い合わせ対応を効率化しています。
また、やり取りにチャットを使うため、クロージングまでの人間が回答する部分でも、複数のお問い合わせに並行して対応できます。そのため、コールセンターでは1人が1時間に2～3件の対応が限界とされますが、OK SKYを利用するとその3倍、1人が同時に10件まで対応できるんです。
――OK SKYは何名のスタッフで運営しているのですか？
小林：開発チームが3名、お客様対応を行うチャットセンターが10名です。最近、OLIVE des OLIVEさんという、20万人以上の顧客を抱えるアパレルブランドにOK SKYを導入したんですが、もちろん問題なく運営できています。
――ずいぶんと少人数なのにすごいですね。その他のクライアントも含め10名でお客様対応サービスが提供できているのは驚きですが、開発チームだって人数が少ない。
小林：以前はシステム運用を担当するエンジニアが3名いましたが、現在はOK SKYのシステムを「Heroku」というPaaS上で稼働させるようにしたため、運用担当者は1人もいません。
実は、現在のOK SKYのアーキテクチャはバージョン2なんです。OK SKYをリリースしたのは昨年の12月で、このときはバージョン1。まだ、AWS上で動かしていましたし、アーキテクチャもまったく違っていました。今年の5月にバージョン2をリリースし、ユーザー企業様にもバージョン2へ移行していただいています。
――それはまた急ピッチで変化したんですね。またどうして？
小林：OK SKYの前に今年の1月まで、弊社ではアパレル小売り向けに「PRIMODE」というサービスを展開していました。チャットの中にファッションに関するコンシェルジュがいて、お客様に商品を提案し、買っていただくというものです。PRIMODEのシステムは開発を外部に発注し、AWS上で稼働させていました。OK SKYのバージョン1もこのやり方を踏襲していたんです。
また、バージョン1までのアーキテクチャは、各機能を独立したサービスとして開発し、稼働させるものでした。サービス開発の発注先はさまざま。実装も発注先が得意なプログラミング言語、PythonだったりGo言語だったりが使われていて、それをgemというRubyのコンポーネント化機能でラップし、Ruby on Railsに取り込んで1本のアプリケーションとして立ち上げていました。そして、それらを連携してOK SKYという大きな1つのサービスとしていたわけです。
ところが、このアーキテクチャにはサービスを運用する上で大きな問題がありました。OK SKYのようなBtoBサービスでは、利用を止めるユーザーを想定しておかなければなりません。解約のタイミングでサービス利用中に蓄積されたデータを消去しなきゃいけない。顧客データなので、完全に消去しないといけないんです。ログデータとかも含めて。
顧客データやログデータを格納しているデータベースは、独立したサービスごとに置かれていました。そのため、解約が発生すると、解約したユーザーのデータを、それぞれのサービスで削除する必要があります。これには結構な費用がかかることが想定されました。もう絶対に改善が必要でしたね。
――それで開発されたのが現在のOK SKY、バージョン2だと。
小林：はい。加えて、バージョン2は外部に発注せず、自社で開発することにしました。解約される企業さんのデータを簡単に消せるようにすることはもちろん、OK SKYを独立した1つのパッケージにして提供したいという考えもあったので。実は、OK SKYのバージョン2が社内だけで作った初めてのプロダクトなんですよ。
Force.comは「無料」で試せます！
Force.comは「無料」で試せます！簡単なご登録ですぐにさわってみることができます。ご興味のある方はForce.comの下記ページから。
本記事の目次 （→シリーズの特集ページ）
機械学習でチャットによる問い合わせに回答
――バージョン2はどのようなアーキテクチャにしたんですか？
小林：まず、ばらばらに立ち上げられていた個別サービスからロジックを取り出して、1つのRailsアプリケーションに統合しました。顧客データを格納するデータベースも同様です。そうして、OK SKYサービス全体を1つのRailsアプリケーションとして構築し直しました。
また、このタイミングでOK SKYを稼働させるクラウドを、AWSからHerokuに切り替えました。OK SKYを提供する場合には、RailsアプリケーションのインスタンスをHeroku上で立ち上げます。ユーザーが解約したときには、そのインスタンスを破棄するだけで、顧客データやログデータも含め、削除すべきデータが消去されます。これで課題を解決できました。
存外に嬉しかったのは、インスタンスの立ち上げとセットアップが簡単になったことですね。環境変数やアドオンの組み合わせなど設定しておけば、あとは「Deploy to Heroku」ボタンをクリックするだけでセットアップまで完了し、すぐにユーザーへ提供できるんです。
――アーキテクチャ図のcommunication moduleの中に「テキスト解析」とあります。システムがお客様とチャットでやり取りするのですから、この部分はサービスの品質を左右するところだと思います。どのような実装になっているのですか？
小林：詳しくはまだ言えないのですが、やり取りする言葉はIBM Watsonを使って生成しています。お客様の入力を理解し、それに対して適切な次の質問を返します。お客様への聞き方にも重要なポイントがあります。例えば、自由形式ではなく、「……していいですか？」と尋ねて「イエス」か「ノー」かで回答してもらえるようにしています。イエスかノーかを正しく聞いていけば、問い合わせたいことはおおよそ分かるんです。
また、質問は誘導型になっています。例えば「夏に着るワンピースを探しています」という問い合わせに対しては、「ワンピースですね？」「お仕事用のワンピースでしょうか？」という具合です。
――なるほど。今話題の機械学習の実用例というわけですね！ ただ、お客さんの回答をうまく誘導するための台本？っていうんでしょうか、それを作るのがまず難しそうですけど。
小林：弊社はチャットセンターを持っているので、チャットの構成、やり取りの構成自体は簡単に作れるんですよ。
OK SKYでは、チャットセンターで人間が生み出したデータをGoogle BigQueryの中に全部入れて、類似性のルームを生成し、それでいったん分類をしたあとに、人間の手でそれぞれで上手くまとめるという方法で作りました。チャットセンターには400万メッセージぐらいあり、約30万のルームができました。
なぜAWSからHerokuへ切り替えたのか
――うーん、もうSFの世界のようです……。ところでなぜ、AWSからHerokuにクラウドを変更したのですか？ AWSでも同様の実装はできたと思うのですが。
小林：コストですね、一番の理由は。バージョン1まではミニマム構成でもインフラコストとして120万円くらいかかっていた。しかし、ネットワークのトランザクションも含めて、利用できるリソース範囲の0.1％も使ってない。何かあったときのために、たとえ1台で運用していてもDBを挟んでおくとか、本来1台ならそれはいらないはずなのに、こうした余剰リソースがどうしても発生する。さらに、ミニマム構成では1つでも使用するAWSのサービスを外すと、OK SKYが提供するサービスに影響が出てしまう。にっちもさっちもいかない状態でしたね。
そんなときにHerokuさんとご縁ができて、じゃあ乗り換えませんかっていうので、それで決断しました。あと、Herokuではアドオンも含めて、立ち上げたインスタンスに対して一括で課金される点もコストに無駄がなく魅力でした。
――バージョン2への移行はクラウドやアーキテクチャの変更など、とても大きなものです。移行の際に困った点などはありませんでしたか？
小林：結構悩んだポイントはあって、1つはバージョン1とシステム連携していたユーザーさんへの対応です。在庫連携とか、商品マスターや顧客マスター連携などを行っているユーザーさんがいらっしゃったんです。それも、インフラの調査などを事前に行うようなビッグクライアントでした。
いただいた要望には、「ファイル連携だったら、HULFT（ファイル転送ミドルウェア）を使ってやってほしい」「サーバ自体は残してやってほしい」といったものがありました。また、クラウドを切り替えるとIPアドレスが変わるわけで、APIで連携しているユーザーさんではご対応いただけないケースもありました。
――結局、どうされたんです？
小林：システム連携はあきらめました。代わりに、商品や在庫のデータを表示するWebサイトをクローリングして収集する方式としました。それで、お客様から問い合わせがあったときに参照する商品や在庫のデータベースを構築する。将来的にはそのやり方がいいかなって思いました。HTMLになったものから情報吸い出すのであれば、同じしくみで全部できますから、効率的というか汎用的というか。
――荒っぽいですが、高額なインテグレーション費用をかけて連携する仕組みを構築するより、たしかにコスパに優れている気がします（笑）
Force.comは「無料」で試せます！
簡単なご登録ですぐにさわってみることができます。ご興味のある方はForce.comの下記ページから。
本記事の目次 （→シリーズの特集ページ）
GitHubやCircle CIで継続的インテグレーション
――開発はどのような環境で行っているんですか？ Heroku上にアプリケーションを構築しているということで、Gitをお使いとは思いますが。
小林：ソースコードの管理にはGitHubを使っています。ブランチは、新機能追加などのissueごとに作っています。それをdevelopブランチに向けてプルリクエストを出すと、Circle CIという継続的インテグレーションツールが外部のサービスを使ってテストを実行します。そのテストに合格するとコードがマージされ、Herokuのほうにプッシュされて、stagingアプリケーションが作られます。そこまでは自動化しました。
開発体制的にはいくつかのフェーズを切り、各フェーズの中にステップ1、2、3を置いて、あるステップの実装が終わるたびにreleaseブランチにプルリクエストを出します。そして、そこでもテストが実行され、それにパスするとreleaseブランチに統合される……という流れです。そういう流れで開発していると、自動的にHeroku上にアプリケーションが載ってくるようにしました。
まあ、これもテストをゴリゴリ書いてくれる人が外部にいるので実現できているんですが。こちらが書いたコードに対してテストを書いてもらい、それにパスすするとアプリケーションも上がってくると。
――ユーザーさんのインスタンスは立ち上がったままなんですよね。再起動は不要ということで。
小林：はい。再起動も何も必要ないですね。新しいアドオンを入れた場合には、そういうスクリプトを書かないといけないですけど。ユーザーさんには最新版の1つのコードベースでアプリケーションを提供するようにしています。
開発計画をオープンにしてしまいたい！
――今後チャレンジしたいことってありますか？
小林：費用をもっと抑えたいっていうのがありますね。いろんなアドオンを使うので、費用がちょっとずつかさむんですよね。あと、今一番気にしているのは、より売れるプロダクトをっていうことでしょうか（笑）
もう1つ、先ほど開発をフェースやステップに切って進めているといいましたが、これを世の中に公開してしまっていいんじゃないかなっていうのは結構思うところです。弊社は5年ぐらい先まで、何をやっていくかっていう開発計画が決まってるのですが、1年半までを世の中に公開しようかっていう案があるんですよ。そんな大したことでもないし、皆さんやられていくことではあるので。「ウチはこういうことやっていきますよ」っていうのは、開発者も含めて、入ってくる前に知ってもらいたいというのはありますし。OSSみたいなイメージです。
ただ、本当にOSSにして（ソースコードを公開して）はダメって言われましたね。セキュリティの問題でダメって。
――いやいや、開発計画を公開してしまえ、というだけでもかなりセンセーショナルです。
小林：競合他社が弊社の開発計画を見てコピーしようと思っても、それってビジネス的にはそんなに重要なポイントではないんですから。競合が出てきたら、それよりいいプロダクトを作りたいっていう想いのほうが強いです。プレッシャーも含めて、オープンにしようっていう計画なんです。
――本日は先端技術の実用例から開発計画の公開まで、先行サービスを提供するベンダーさんの勢いを垣間見た気がします。ありがとうございました。
Force.comは「無料」で試せます！
簡単なご登録ですぐにさわってみることができます。ご興味のある方はForce.comの下記ページから。
