はじめに
はじめまして！
Leverages（レバレジーズ）Advent Calendar 2019 18日目担当の吉澤です。
普段は、看護師向けの転職サイトや社内システムの開発・運用などをしています。
今回は、LINEでの顧客対応に用いられるチャットシステムの構築についてと実際運用してみてどうなの？みたいなところを書いていこうと思います。
何作ってるの？
↓ざっくりこんな感じのやつを作っています。
開発に至った背景については以下の記事に書かれています。
LINEのMessaging APIとFirestoreを用いて、社内のSFA/CRMシステムから顧客とLINEのやり取りができるような機能です。
以下、内製のSFA/CRMシステムを社内システムと略します。
構成
全体的な構成としては以下の様になっています。
サーバーサイド
まず、ユーザーがメッセージを送るとLINEサーバーからWebhookを受け取ります。受信時のメッセージの取りこぼしがあると、そもそものコミュニケーションツールとしての役割を満たせなくなってしまうため、ここは特に気を使わなければならない部分でした。
そのため、Webhookを受け取ったらペイロードをそのまますぐにキューに追加し、仮に後続の処理に問題があったとしても、ログから復旧できるような構成にしています。
サーバーサイドは慣れ親しんでいたという理由もありlaravelを利用しています。
キュードライバはAmazon SQSを使おうかとも思いましたが、当時SQSがFIFOに対応していなかったこともあり1回のみのメッセージを保証したかったのでRedisを利用しています。
後は順にキューから取り出し、Firestoreへの保存など受信時の処理を行っています。
クライアントサイド
次にメッセージを表示するクライアント画面ですが、ここはVue.jsとfirebaseのsdkを用いて、該当ユーザーのメッセージのcollectionをリッスンし、変更があればステートに追加していくといった割と一般的な処理になっています。
自力でWebSocket使って...みたいなことをしなくていいのでfirebaseほんと楽で便利ですね！
ただ当時、「Firebaseの読み取り超過で○百万円飛んでった 😇」みたいな記事が上がっていたのと、実際にリリース後どのくらいの読み取りが発生するかが予想しづらい状況であったため、ドキュメントの読み取り数には警戒していました。
そのため対策としてメッセージを20件ずつローディングするようにしたり、オフラインキャッシュを利用するなどして読み取り数を削減していました。今思うとFirestoreの無料枠も大きいのでそこまで警戒する必要もなかったかもと思っています。
通知機能
メッセージ受信時の通知に関しては、FirebaseCloudMessagingとServiceWorkerを使ってプッシュ通知をしています。
普段、通知許可を求められると不快に感じてしまうタイプではあるんですが、こういう利用用途が限られていてユーザーに使ってもらうことが前提の場合はサクッと実装できて便利だなと思いました。
社内システムにおいては、サポートブラウザが限定できる点や実装効率の面でもPWA周りの技術のメリットを享受しやすいのではないかと思いました。
ーーー
全体的には、このような構成で何とか一年近く運用できています。
加えてメッセージのやり取り以外の面でも、LINEログインを用いたオウンドサイトからの登録や定期的なメッセージ配信など集客面での機能追加なども行っています。
最近、LINE側でも頻繁に機能追加されているので、いろいろできそうで面白いですね😉
運用してみて
このプロジェクトにおいては、技術面以外でも多くの学びがありました。
まず、これまで顧客とのLINEでの連絡は通常のLINEを利用していました。
これを内製のシステムに乗り換えるとなると提供されていない機能があったり、実装工数などの兼ね合いでどうしても今まで出来ていたことが出来なくなる機能が存在します。
狩野モデル *1 でいうところの当たり前品質が「本家のLINEで出来ていたこと」に該当していたように思います。
当然、利用者からすれば不便に感じる部分があったかと思います。
また、移行において仮にLINEで出来ていたことを実現できていたとしても、それだけではただ代替性が高いだけで、移行コストの方が高く感じてしまうのではないかと思います。(自分に置き換えてもそうなので、ｗ)
そのような状況の中で、社内システムの開発・運用において以下のような点が重要だと感じました。
背景・目的への理解
何か新しいものを導入する際にはその背景や目的を明確にすることはもちろん、それが現場の人たちの中でも共有され、腑に落ちているかが重要だと思います。
よく職種間のやり取りにおいて、専門的な用語でなく相手が理解しやすい言葉でのコミュニケーションを心がけようと言われますが、たとえ言っている内容を理解できたとしても、それがどのくらい重要であるかという温度感は担当する役割によって違っていたりします。
全員が納得するのは中々難しいかもしれないですが、そういった認識のギャップを埋めていく動きも必要であると感じました。
ただ納得してもらうために、不用意に決定を曲げてしまうと本来の目的から逸れていってしまうこともあるので、その塩梅は中々難しいように感じます。
実際にはチームメンバーが現場への説明、疑問や不安の払拭、改善要望に対する対応目処の伝達など、とても献身的に働きかけてくれたこともあり、理解が得られていったように思います。
エンドユーザーの視点を持つ
ここでいうエンドユーザーはサービスにおける最終的な顧客のことを指します。
社内システムの開発において、システム自体の利便性を高めるということはとても重要ですが、それが最終的にどうユーザーに還元されるのかという視点を持つことも必要だと思います。
例えば
システムのレスポンス速度を改善することによって、現場の業務効率が上がり、ユーザーへの対応速度が上がる
データを入力しやすくすることによって、今まで個人の中に埋もれていたような情報が蓄積されるようになり、ユーザーがより詳細な情報を得られるようになる
などのようなことです。
普段、開発をしていると目の前のタスクの消化だけに目が行ってしまったり、自分は何のサービスを作っているのかが分からなくなってしまう時があるので、立ち返るという意味でも重要であるように感じます。
また、担当の職域が違うとその担当内での視点に寄ってしまいがちですが、同じ視点で議論することによって共通認識が取れやすくなるように思います。
同じサービスを提供する者同士として、目的は共通であるという前提の理解と、お互いがユーザーの視点に立ち、何ができるかを一緒に考えていくという姿勢が重要だと感じました！
We Are Hiring !
レバレジーズでは一緒に働く仲間を募集しています！
創業14年目を迎え、より一層テクノロジーでの課題解決が求められるフェーズになってきたように思います。
技術での事業貢献、ユーザーファーストでのサービス作りなどなど、ご興味ある方、是非ご連絡お待ちしております！！
https://recruit.jobcan.jp/leverages/show/b01/7682recruit.jobcan.jp
*1:顧客満足度に影響を与える製品やサービスの品質要素を分類し、それぞれの特徴を記述したモデル | wikipedia:狩野モデル
