ZEALS TECH BLOG

チャットボットによる会話広告『fanp』を開発する株式会社ZEALSのテックブログです。技術やエンジニア文化について情報を発信します。

「AWS Cloud9 + heroku + Messenger API」で簡単に開発するチャットボット入門

f:id:zeals-engineer:20190225215707p:plain

皆さんこんにちは、サーバサイドエンジニアの福本です。

先日、Facebookオフィシャルコミュニティである『Facebook Developer Circle』の第2回目のイベントにて、”Messengers APIを用いたライブ・コーディング”を実施しました。

www.wantedly.com

ライブ・コーディングを実施するにあたり色々と準備をし、簡易的なチャットボットを作る手順をまとめてみましたので、みなさんに共有します。

Messenger APIにはFacebookが公開しているスタートガイドがありますが、そちらを進めるだけでは、思わぬポイントでハマってしまうことがあります。

developers.facebook.com

今回はそういったところも含めて、開発の手順を皆さんにお伝えします。
チャットボット開発の魅力を少しでもお伝えできれば幸いです。

  • 使う技術・ツール
  • ゴール
  • チャットボットの開発
    • cloud9の環境構築
    • webhookの設定
    • herokuへデプロイ
      • コマンドラインでherokuを使えるようにする 
      • herokuへのデプロイ準備
      • package.jsonの修正
      • herokuデプロイ
    • Facebookアプリの設定
    • テキストや画像の処理およびカルーセルの送信
  • 完成
    • テキストが送られた場合
    • 画像が送られた場合
    • (生成された)ボタンをタップした場合
続きを読む

Omotesando.rbに登壇&参加してきました!

f:id:zeals-engineer:20190218004109j:plain

皆さんこんにちは! ZEALSでバックエンドエンジニアをやっているRyutoooooです!

最近はもっぱらDBのリファクタリングでビジネスサイドより、開発側が喜ぶことをメインでやらせてもらっています!

さて今回ですが、有名なRubyコミュニティの『.rb』系の表参道での会に参加してきました!!
同じくZEALSのサーバサイドエンジニア福本と参加ました。

僕は参加しただけですが、福本は当日LTを実施したのでその内容も含めてイベントの模様をお届けできればと思います!

『技術を使わない問題解決 ~チームが10人越えたら考えたいgem周り~』

なんともエモいテーマのLTですね!
実際に登壇をした時の反響もよく、Twitterでも好評でした。
(詳しくはこちらです)

こちらが登壇で使用したスライド資料です↓

speakerdeck.com

紹介したGemとOSS(4~14枚目)

今回問題解決の方法として、Gem等をいくつか紹介しました!

Danger:プルリク秩序の乱れ

github.com

PRに一定のルールを設定し、それを破るとコメントしてくれるというgemです!

実際にZEALSで導入した時の記事はこちらです。

Okuribito:技術的負債の増加

コードを静的解析し、未使用の可能性が高いメソッド等を列挙する github.com

コードを動的に解析し、外部呼び出しも含め分析する github.com

上記の2つをうまく用いて、使われていないコードを判断して葬ることができます!

CircleCI Bundle Update PR:gem updateの責任なすりつけ

Gemfile.lockとbundle updateの差分を検知して、自動でPRまで作成してくれます!
日常のレビューフローの中にgem updateを入れてあげることで、より安全にRailに乗っていくことができますね! github.com

エンジニアにとっての問題解決(15~22枚目)

個人的にはこの部分が一番好きな話でした。

僕が良いと思ったところは「問題解決にはレベルがある」ということです!

最も良いのが「技術を使わないで問題を解決すること」で、
最も良くないのが「難しい技術を使っているだけ…」なこと。

僕は「エンジニアなら技術使ってなんぼでしょ?」と思っていたので、最初はよく理解できませんでした...

では「なぜ技術を使うべきではないのか?」という理由について、以下の3つを挙げていました。

・技術は必ず陳腐化する
・技術は必ず属人化する
・技術は必ず負債になる

この3つを聞いて、凄く納得しました。
エンジニアだからこそ、技術をどう使うかをしっかりと考えたいと改めて感じました。

会場の皆さんからの反響もよく、ZEALSとしてすごく良いLTができたと思います!

個人的に印象に残ったLT

「kibela2esaと正規表現」

Ruby界隈ではご存知の方も多いうなすけさんが今回登壇していました。

登壇内容は、社内で使っていた情報共有ツールを違うサービスに乗せ替えるために、正規表現で全ての情報を取得するというものでした。
正規表現での苦労やRubyで書いたからこそ良かった点等々熱く語ってくださり、思わず聞き入ってしまいました!

github.com

「Railsでモデルのステータスを扱うベタープラクティス」

ngmtさんはモデルのステータスをどのように制御したらよいかをお話していて、共感するところが多くありました!

ポイントとしては、下記の3点です。

PlantUMLとレビューで設計共有・更新を漏らさない

シーケンス図を手早く書けるドメイン言語のPlantUMLを書き、常に設計を共有しておくということ。
スクラッチだったりスタートアップでは共有するのもコストでどうしても共有が疎か…なんてこともあったりしますね…

AASM gemでステータス管理・実装をカンタンに

僕は知らなかったgemなのですが、モデルのステータスをmodule化して定義できるみたいです。 github.com

最初はほんとに小さく始める、DB設計が正規化されていれば後からでもなんとかなる

これは間違いないですね...
正規化した後も大事で、DBのメンテナンスを疎かにしていると、後で痛い目を見ます(経験談)

speakerdeck.com

全体的な感想

Rubyのコミュニティは他の言語のコミュニティに比べて規模が大きいと感じました。
他の.rbもそうですが、これからもRubyコミュニティにどんどん参加し、1人のRubyエンジニアとして界隈を盛り上げていきたいと思いました!(登壇もしたい…)

Omotesando.rbは毎月第一木曜日に開催していますので、ぜひ参加してみてください!!! コミュニティの公式ページはこちらです。

続きを読む

Tried Programming Rust lang[Rustをやってみた!!]

f:id:zeals-engineer:20190209181754p:plain

フルスタックエンジニアのAaronさんがRust言語についての記事を書いてくれました!
(Aaronさんの社員インタビュー記事もよろしければご覧ください!)

www.wantedly.com

Aaronさんは新しい技術への感度がとても高くて、ZEALS内でいち早くRustにも取り組んでくれました。
Rustを触って感じた言語の特長をまとめてくれましたので、Rustに興味のある方はぜひ読んでみてください!

後半では、Aaronさんの書いてくれた文章を日本語訳していますので、英語が苦手な方はそちらをお読み頂けると嬉しいです!

Tried Programming Rust lang

Introduction

This blog post is about typing. Specifically, typing in programming languages and about the concept having (hopefully) a positive impact on my coding style.

Although I am primarily a JS/Ruby developer by trade, I do experiment with other languages and have been looking at the benefits/drawbacks of adopting another lower level language, or even doing something like Typescript on the frontend.

I make games as a hobby. Which led me to programming in Rust, a systems-programming language by Mozilla.

www.rust-lang.org

Yeah, I know you can make games in JS (and it's actually quite fun, check out Pixie JS), but I wanted to make something really fast without all the minor hinderances of programming for a browser.

What I've come back with so far is an appreciation for types.

So what I've noticed is:

1. Compilers are nice

I went through an entire code tutorial with about 300 lines of code and never ran the program once.

I followed along typing and understanding what was happening in the tutorial and before I knew it, the tutorial was over.
It's not necessarily that dangerous in JS, but I had some apprehension about the debugging process that awaited me.

doc.rust-lang.org

But to my surprise, after only a few spelling misses and missing or wrong function parameters the program booted up dutifully and it ran perfectly!
Although one can never be sure about what kind of bugs may lie in the dependencies I downloaded, my code seemed bug free.

It made me think about JS/Ruby, and how I might not see a lot of bugs until I actually test the program.

Yes, I know you can write tests for your code, but the types were like little annotations for all my functions without writing one test.

There were no questions about function arity, no doubts about me putting the wrong kinds of arguments somewhere, I just had a confidence that the program worked.
And that it would work even if another person had edited it.

2. Structs are nice

To me, JS is the ultimate free language, with a huge price that comes with that freedom.

Especially when working in big teams, where people come and go, you can always enforce every single good-practice.
And, to be honest, sometimes it all comes down to style. But having a ton of object literals in your codebase can make things messy, especially when the object literal really ought to be an enforceable structure with some kind of scheme.

By being able to make your own types, you can ensure that an object/hash is made the same way every time.
And new languages like Rust/Golang have these convenient structs that don't force you into making entire class to accomplish that job.

And because, by nature, these structs are like schema, I can be guaranteed that they're used the same way everywhere.
I don't have to consult documentation, or the programmer that wrote it.

Effect on my style

Although I couldn't just make everybody adopt Typescript at work tomorrow, nor do I think I'd want to, I can use some of what I've learned to get the benefits of what I have experienced in my time with Rust.

1. We don't have a JS/Ruby compiler, but we can still program defensively

I can't stop JS/Ruby from getting into the master with a bunch of runtime errors, but I can have my program let others/myself know when they're/I'm using my code incorrectly by making classes which will liberally throw errors when the wrong parameters are passed into the constructor.

They say that "prevention is the best cure" and we can prevent people from using our code outside of the way we expected them to use it, we also prevent them from using it in ways we didn't expect.

2. We don't have structs, but we can try our best when it really counts

I'm not advocating for every JS/Ruby function to manually check the parameters of every function, but when it really counts don't just expect the functions we're using to behave the way we want them to. Important functions that rely on important parameters must check their inputs.

Typed languages will let you know precisely when you're "doing it wrong", but JS will just smile at you nod. An extra if-statement will probably take you 10 seconds to write and save you a lot of headaches in the end.

Closing thought

As web developers, increasingly were sending receiving tons of JSON all the time.
And I can't count the amount of hours I've wasted just debugging payloads to or from servers that don't have the correct stuff in it.

Of course, I love the flexibility that JSON provides, but I think this is one of those parts of web-development that really counts and probably should have a typing/schema.

I would like to experiment more with something like protocol buffers in the future and see if that doesn't relieve some of the headaches, although who knows, by then the next big thing may come along :D

【和訳】Rust言語をやってみた!!

はじめに

今回はコーディングについての記事です!
コードライティングやコーディングスタイルの概念について詳しく書いています。

僕はjavascriptやRubyのエンジニアとしてプログラム開発を行っていますが、他にも色々なプログラミング言語を試していて、低レベル言語やフロントエンドにおけるTypescriptなどのメリットやデメリットを調べたりしています。

Mozillaが提供するプログラミング言語”Rust"を触るきっかけは、僕の趣味が「ゲームを作ること」だったからです!

www.rust-lang.org

普通のjavascriptでゲームを作ること(Pixi.JSとか!)ももちろんできますが、ブラウザ開発にありがちな障害(ファイルシステムにアクセスできなかったり...)がなく、高速でメモリをあまり食わないアプリを作りたかったので、今回Rustに挑戦することにしました。

僕は今回、 ”型”のありがたみ を改めて感じました!
それでは、さっそくご紹介していきます!

気づいたこと

1. コンパイラがすごくイケてます!

今回、僕はチュートリアルで300行くらいのRustのコードを書きました。 チュートリアルの間、途中では一度もプログラムを実行しませんでした。

doc.rust-lang.org

チュートリアルではRustのコードの特徴を理解することに集中しました。
僕はjavascriptではあまり感じないのですが、最後のデバッグに不安を抱いていました...。

しかしデバッグしてみると、驚いたことにタイポや引数を少し間違えていただけで、プログラム全体は正常に起動し問題なく実行されました!
パッケージやライブラリにバグがあるか​​もしれないですが、自分のコード自体にはバグがほとんどなかったのです。

javascriptやRubyを書いていると、プログラムを実際にテストするまで、どれだけ多くのバグがあるかわかりませんでした。

もちろん、テスト駆動開発的に、コードのためにテストを書くことだってできます。
しかしRustの”型”は、テストを書かなくても、すべての関数に小さな注釈があるかのように機能しました。

引数についても、引数の種類が間違っているかを心配することもなくプログラムを書けました。
他の人がRustを書いても、同じようにうまくいくのではないかと思います。

2. 構造体もすごく良い概念です!

javascriptはすごく自由な言語だと僕は考えています。
特に、大規模なチーム開発をするときは、チーム内で良い書き方を習慣づけることもできます。

それらがコーディングスタイルとして定着することもあります。
しかし、コードに大量のオブジェクトリテラルがあると、処理が面倒になることも多いです。

RustやGoには便利な構造体を持っていて、無理にクラスを作らなくても良くなります!
型を作ることで、オブジェクトやハッシュを毎回同じ方法で確実に作ることができます。

doc.rust-jp.rs

これらの構造体は本質的にはスキーマに近く、どこでも確実に同じように使われます。
ドキュメントやそれを書いたプログラマーにいちいち相談する必要はないのです。

コーディングスタイルへの影響

仕事でTypescriptを採用することはしなかったのですが、Rustのメリットの多くを仕事で活かすことができると思います!

1. javascriptやRubyコンパイラはないですが、エラーを防ぎながらコードを書くことができます

javascriptやRubyの実行時にmasterブランチでエラーが出るのを止められないですが、自分のコードが間違った使われ方をされていると、それを教えてくれます。具体的には、間違ったパラメータがコンストラクタに渡されるとエラーをスローしてくれます。

コード自身が「予防が最善の治療法である」ということを教えてくれます。
僕たちは、予想しない方法でコードが使われるのを防ぐことができるのです。

2. 構造体がなくても最善を尽くす

javascriptやRubyの関数でパラメータを手動でチェックすることはあまりオススメできませんが、使用している関数が思ったとおりに動作するとは限りません。
パラメータに依存する重要な機能は、入力された値を確認する必要があると感じました。

型付けされた言語は、間違った値が入力されればそれを教えてくれますが、javascriptならほくそ笑んで終わりです。笑 if文を多用してしまうと、頭を抱えながらコードをなんとか書くことしかできません。

続きを読む

【イベントレポート】『UX Bridge vol.8』に参加してきました!!

f:id:zeals-engineer:20190205220735j:plain
皆さんこんにちは!
ZEALSでサーバサイドエンジニアをやっている福本です!

1月31日に行われました日本有数のUXデザインのコミュニティ『UX Bridge』が主催するイベントに参加してきましたので、そちらの模様をお伝えできればと思います。

uxbridge.connpass.com

参加した経緯として、元々プロダクトマネージャーを兼務していた文脈からUXデザインにはとても興味があり、今後ZEALSではプロダクトの質を高めるために、デザインの領域を今後重視していくためです!

UXデザインの現場のリアルな話をたくさん聞くことができ、とても良い場に参加することができました!UX Bridgeでは定期的にイベントが開催されるそうなので、皆さんもぜひ参加してみてください。

  • 立ち上げ期のSaaSで大事にしているUX
  •  ワイガヤUX
  •  We DESING story. 「伴走」と「共創」のUXデザイン 
    • 最後に 
続きを読む

【エンジニア対談】元トレタCTOの増井さんと語る、ZEALSのチャットボットプロダクト『fanp』のすべて(後編)

f:id:zeals-engineer:20190212115852j:plain

みなさんこんにちは、ZEALSエンジニアの福本です!

こちらの記事は前編に引き続き、ZEALSのプロダクト『fanp』についてのエンジニア対談【後編】です。

後編では「fanpに対する思い」や「今後の展望」などを中心にお話させていただきましたので、その対談の模様をお届け致します。

ちなみに、対談の前編記事はこちらになりますので、合わせてお読みください!

tech.zeals.co.jp

  • どういう思いでfanpを作っているか
    • コミュニケーションへの挑戦とは?
    • チャットボットはビジネスにならない?
  • これからfanpをどうしていきたいか
    • 目指す先は”稼げる”こと?
    • チャットボットのOSSを開発?
    • 必要なのは、信念とマーケティングの合わせ技?
続きを読む

【エンジニア対談】元トレタCTOの増井さんと語る、ZEALSのチャットボットプロダクト『fanp』のすべて(前編)

f:id:zeals-engineer:20190130160336j:plain

みなさんこんにちは、ZEALSエンジニアの福本です!

ZEALSでは、チャットボットによる全く新しい広告体験を提供するプロダクト『fanp』を日々開発しています。

fanp.me

これまでfanpは、マーケティングや広告といったビジネスの視点から語られることが多く、エンジニアリングの視点からはあまり詳細が語られることはありませんでした。

このままでは、fanp開発の面白さをエンジニアの方にお伝えできません...

そこで今回は、テクノロジーお師匠さんとしてZEALSにジョインして頂いている元トレタCTOの増井さんをお招きし、エンジニア目線から見たfanpを対談形式で語らせて頂きました!

一般的なチャットボットプロダクトとの違いや、どんな思いで開発しているか、これから先どういうプロダクトにしていきたいか...

こういった内容について赤裸々にお話させていただきましたので、対談の様子を皆さまにお伝えしていきます!

  • 関係者
  • ZEALSやfanpとの関わり
    • どんなことをやっているのか?
  •  チャットボットと『fanp』の違い
    • チャットボットとWeb開発の違いは?
    • ユーザーを乗せる「ストーリー」とは?
    • ”プッシュ”が嫌われないためには?
  • チャットボット『fanp』を作る難しさ
    • fanpを作る技術的な難しさとは?
    • コミュニケーションを要件化するとは?
    • ”アテンション”を奪い合う?
    • 前編はここまでです

関係者

元トレタ CTO 増井雄一郎

1976年、北海道生まれ。札幌大学経営学部卒業。大学時代に起業。2003年にフリーランスとなり、Ajax、Ruby on Railsなどを使ったWebアプリ開発や執筆を行う。08年に渡米し、中島聡氏とともにアプリ開発会社を立ち上げる。10年に帰国し、Appceleratorの「Titanium Mobile」のテクニカルエバンジェリストとして活躍。2013年に株式会社トレタを創業しCTOを努め、2018年10月に退社し独立。


 株式会社ZEALS CTO 島田想

1994年東京都出身。株式会社ZEALS CTO。同社創業時よりプロダクト開発に携わり、世界初の会話広告サービスfanpを開発。LINEやFacebook社の提供するMessaging API Platformを公開当初より叩き続けており、Facebook MessengerについてはMessaging APIを国内で最も多く叩いているであろう人間の一人。チャットボット以外にも、会話インターフェースであるVUIのアプリ開発にも知見がある。


株式会社ZEALS Product Manager 福本晃之

1992年兵庫県出身。富士通グループでITシステム導入の法人セールスに従事。テクノロジーへの思いを捨てられず、2018年4月に株式会社ZEALSへエンジニアとしてジョイン。PythonとRubyのエンジニアとしてチャットボット開発に携わる。2018年8月より、同社のチャットボットサービス「会話広告 fanp」のプロダクトマネージャーに就任。現在は技術広報やエンジニアの採用にも携わる。

ZEALSやfanpとの関わり

どんなことをやっているのか?

 

福本:fanpの話に入る前に、3人が最近何をやっているのか軽く触れていきます。島田さんは創業時からのZEALSのCTOですが、業務的には何をしていますか?

島田インフラやDBの手直しみたいなことをやっています。これまで速度を重視してクイック&ダーティーに実装してきたので、テーブルのスキーマを修正などをやっています。

増井さん:テーブルやDBの設計周りのイメージ?

島田:はい。ZEALSはモノリシックにRailsをやってきたので、マイクロサービス化できないかを模索していています。
インフラに関しては、トラフィックが今年あたりから急激に増加しました。今後に備えトラフィックが多い部分のサーバレスへの切り出し、マネージドの部分をKubernetes化し等を行い、スケーラビリティを担保していくイメージです。

福本:これまではどんな開発を?

島田これまでは、Facebook MessengerのAPIやLINE のMessaging API が公開された早期のタイミングでプロダクトとして使えるように実装しました。

f:id:zeals-engineer:20190130190359j:plain

福本:ありがとうございます。続いて僕ですが、4月からPythonとRubyのエンジニアをやっています。9月からプロダクトマネージャーも兼務です。
業務としては中長期のプロダクトの計画を作って、その計画を粛々と実行に移す、という役割を担っています。役割の遂行にあたって増井さんに色々と助けて頂いていると。

増井さん:僕は最近、プロダクトの方にすごく興味がある。プロダクトを作る時に、意思決定すべきことがたくさんあって、広い視野でものごとを見て判断するアドバイスをしている。
僕は自分で、「目玉」を提供していると考えている。起業する段階で「それは起業してやるべきなのか?」といった、低レイヤーの話も含めてプロダクトをどうしたいかという話に集中することが多い。

福本:ありがとうございます。

 チャットボットと『fanp』の違い

チャットボットとWeb開発の違いは?

福本:一般的なチャットボットとZEALSのプロダクト『fanp』の違いについて触れていきます。fanpについておさらいすると、世間一般のイメージである「自動お問い合わせ」と少し違っていて、チャット上でユーザーにヒアリングをして会員登録や資料請求などのコンバージョン(以下CV)を生むサービスです。
増井さんは、fanp以外のさまざまなチャットボットにもよく触れているイメージがありますが...

増井さん:僕自身『宮本さん』という勤怠管理のチャットボットを作っていて、 チャットボット自体とても好きでよく作っている。

github.com

僕は昔も今も一日中チャットをやっているので、チャットボットにはずっと興味がある。LINEのAPIが公開されて一番最初にQiitaを書いたのは僕です。

福本:そうなんですか、知りませんでした。

増井さん:他にチャットボットが好きな理由に、 WEB アプリはUI が複雑すぎる。サーバーの知識もWebのHTMLやCSSの知識もJavaScriptやサーバーサイドも必要、さらにDBやサーバー管理といった話も入ってくる。
それに対して、チャットボットは要件が合えばすごくシンプルに物ができる。ユーザーにとってもシンプルだし、作る方にとってもシンプルに作れるイメージ。

福本:チャットのデザインは既にデファクトが決まっています。

増井さん:ただし、自由度はない。僕は自由度がないところが好きで、そういう意味でもチャットボットが好き。

ユーザーを乗せる「ストーリー」とは?

福本島田さんはチャットボットとfanpの違いをどう考えてますか?

島田僕は「fanpにはCVというゴールがある」と考えています。CVとはあくまで僕達の呼び方で、ユーザーからすれば意思決定。例えば、何かを購入するという意思決定のサポートをするという点が、チャットボットとfanpとの大きな違いだと思っています。

福本:確かに、モノを買うとか契約するというのは意思決定です。

増井さん:fanpはストーリー性が強いのではと感じる。シナリオがある中で、ユーザーに”ストーリー”をどう体験してもらうか。ストーリーを作れるか作れないかは、チャットボットのUIUX が上手くいくかの大きな境目だと考えている。
少し説明すると、『宮本さん』を人の名前にしたのはストーリーを考えたから。
勤怠管理で重要なのは「チェックイン」。会社に行くというストーリーをどう考えたときに、「挨拶」をチェックインにした。会社で「おはようございます」と言うのは「出社」のサインで、それを勤怠管理にすればいい。
さらに考えると、チャットボットに対してではなく、人に「おはようございます」と話しかける。そういうストーリーとして使えば違和感がなく勤怠管理ができる。日常生活のストーリーの中に素直に入れられるかに気を遣っていて、「宮本さん」というキャラクターにした。

福本・島田:(うなずきながら同意)

f:id:zeals-engineer:20190130190519j:plain

”プッシュ”が嫌われないためには?

福本「ストーリー」という考え方は面白いですね。僕は配信をどれだけ良いものにするかがfanpにとって大切だと考えています。僕たちは配信を”プッシュ”と呼んでいて、これがあることで、継続的にユーザーと繋がりボットからアクションを起こすことができます。それはLPではできないことで、それをどれだけ突き詰められるかが重要かと。

増井さん:広告が嫌われやすいというのもある。

島田プッシュに関しては、ユーザーにどこまで好まれるかだと思ってます。
モノを買うとき、基本的にはGoogleで検索した方が速いです。ただ、「自分からは検索しないが興味はある」という潜在層の人達に対し、「こういうの見たかった!」という情報をどれだけパーソナライズして届けることができるか。ここが嫌われるかどうかの境目だと思っています。

増井欲しい情報が来る分には別に嫌われない。

島田:シンプルに便利ですからね。

増井さん:そういう意味でプッシュはチューニングしがいがある。

福本優位性ですよね。プログラムを作ってすぐに追いつくものではないので。

チャットボット『fanp』を作る難しさ

f:id:zeals-engineer:20190130190743j:plain

fanpを作る技術的な難しさとは?

福本:島田さんに聞きたいのですが、fanpを作る感じる難しさはどういった部分で感じますか?

島田:これは細かい技術的な話なんですが、APIのデータ形式は基本JSONなので、RDB で持つのが難しい。正規化するのが大変なので。

増井さん:それぞれのJSONに微妙な違いがある。同じようなJSONなのにカラム名が違う、あるいは両面や対面の違いがあるとか。

島田:fanpは管理画面でシナリオを作るので、MessengerとLINEの両方に対応しないといけない。

増井さん:メディアごとに対応が必要なのは難しい。この機能はLINEにはあって、Messengerにはないことが起こり得る。

島田:それ、実際によくあります

増井さん:例えばブラウザ。昔はブラウザ間の差異が大きかったんですが、現状ほとんどない。一方チャットボットは、プラットフォームの表現力の違いがある。ただ、全部使える最低限の機能だけ実装すると表現力が足りなくなってしまう。共通化は本当に難しい。

島田本当に大変で、僕たちも試行錯誤しながら進めています。

増井さん:プラットフォームに依存しますからね。最終決定権がないものを作るのは難しいですよね。

コミュニケーションを要件化するとは?

福本:僕は「 要望がコミュニケーションに紐づいている」という難しさがあると思います。例えば、チャットアプリにはカルーセルという機能があって、情報を並列化して表現するもので、箇条書きに近い役割を持つ機能です。文字って並列の情報を扱うのはすごく難しいので、そういう機能が求められる。

f:id:zeals-engineer:20190201115729p:plain

LINEカルーセル機能のイメージ(https://developers.line.biz/ja/docs/messaging-api/message-types/#carousel-template

増井さん:特にスマホの画面は縦に長いから。

福本:そうです。そういったことを考えながら、使う機能や実装を判断することが難しい。「そもそもコミュニケーションとは」という領域に踏み込まないといけないので。

増井さん:これまでのシステムの難しさは一方向だった。「こういうものを届けたい」という双方向ではなく、プロバイダーからユーザーへの一方通行。
例えば、今までホームページはHTMLで書けばよかった。そこに「コミュニケーションの中でどう気づいてもらうのか」という考えが必要になって、それがこれまでと圧倒的に違う部分。

福本・島田:(同意)

福本デザインと実装が変に切り離されないかというのは大事だと思っていて、両方ともエンジニアで持てるのが理想ですけど、それもなかなか難しい。

”アテンション”を奪い合う?

増井さん:デザインがリッチになればいいかと言うとそうではなくて、今度は人間のアテンション(注目)に限界が出てくる。
コミュニケーションが双方向になるということは、集中して見ないといけないので、ユーザーにアテンションが必要になる。
これはすごく難しくて、双方向のコミュニケーションが増えるとアテンションの奪い合いの話になる。人間は多くのものに集中できないので。
 Netflixについて面白い記事があって、NetFlixの一番の競合は『Fortnite』というアメリカですごく流行っているゲームだそう。
Netflixに使う時間がアメリカで減ってきていて、その代わりにゲームをしている。つまり、Netflixの敵はAmazon Primeではないと。「何を奪い合っているのか」を正確に理解することがすごく大事。

www.polygon.com

福本なるほど。まずは時間の奪い合いがあって、その中でさらにアテンションを奪い合ってるイメージですね。そう考えた場合、今後チャットボットが何と競合するのかを考えることが重要ですね。ひょっとすると、僕たちは全く違う競合を見ているかもしれない。

増井さん:その通り。fanpで会話を面白くすることがアテンションを得ることに繋がるのであれば、ミニドラマとかアニメのようなものがあり得るかもしれない。

福本Netflixがすごいのはゲームが競合だということを理解しているところですね。そういう見極めは難しいはず。

増井さん:そう、それは本当にちゃんと考えないと分からないことなので。

続きを読む

Redash v3.0で使える便利機能まとめ

f:id:zeals-engineer:20190124182957p:plain

みなさんこんにちは、インターン生の久保田と申します!
エンジニアではないのですが、MySQLを使った会話データの分析業務を主に担当しています。

今回は、ZEALSで使っているBIツールの『Redash』の便利な機能についてお伝えしたいと思います!

Redashとは?

redash.io

Redashは、SQLの分析結果をわかりやすく可視化し共有するオープンソースBIツールです。

SQLでクエリを作成することで、データソースからデータ取得をします。
ZEALSでは、KPIなど自分が知りたい情報をすぐに可視化できるために使用していて、日々の事業改善に役立てています。

現在ZEALSではv3.0を使用しているので、v3.0で使用可能な機能をご紹介していきます。

Dashboard

書いたクエリをまとめることができます。
「あのクエリどこあったっけ?」とクエリを探す手間が省けたり、クエリの実行結果を比較することができます。

使い方

事業のKPIをまとめたり、施策ごとの数値をまとめたりする使い方ができます。
自動更新の設定をしておけば、好みのタイミングでの出力数値を毎日管理することもできます。

f:id:zeals-engineer:20190129135457p:plain

VISUALIZATION

クエリの実行結果を可視化・見える化してくれる機能です。
RedashのVISUALIZATIONはそこまで種類が多くないのですが、棒グラフや折れ線グラフなどの基本的なものは作成可能です。

できること

f:id:zeals-engineer:20190129135436p:plain

  • chartで棒グラフ、折れ線グラフを作ることができます。(複数の形を使うことも可能です[図を参照])
  • 円グラフで割合や比率を出すことが可能です
  • 箱ひげ図(Boxplot)や、ピボットテーブル(Pivot Table)などもあるが使い勝手はあまり良くないと感じました
    (Pivot Tableに関してはデータ量が多いと重くなってしまうので注意)

パラメータ機能

クエリ内に {{}} を含めると, クエリにパラメータ(変数)を指定することができます。

これを使うことによって、汎用的なクエリ文を作ることが可能です。
idが変わるたびにクエリを作らずに済み、Redashが整理されます。

使い方

f:id:zeals-engineer:20190129135409p:plain

上記の画像のように {{}} をつけると下にプレースフォルダの入力フォームが出現します。
プレースホルダーに値を入力して実行すると、入力した値がパラメータに反映されます。

{{}} の中身の文字を同じにすればすべて同じ変数と見なされます。
逆に、 {{}} の中身の文字を変えると違う変数として扱われます。

f:id:zeals-engineer:20190124212751p:plain

プレースフォルダ内の入力に関してはいくつかtypeがあります。
プレースフォルダの横の設定を押すと上記の画面が出ますので、参考にしてみてください。

・ Text:自由入力
・ Number:数字を選択できる
・ Dropdown List:これを選択すると自分で選択できる内容を決めることができる
・ Date, Date and Time, Date and Time(with seconds):日付を選択できる

Query Snippets

クエリエディター上でSQL文を書く際に、特定のキーワードに反応して入力をサポートするスニペットを保管してくれます。
これにより、よく使うSQL文を保管しいつでも呼び出すことができるので、作業の効率化が図れます。

f:id:zeals-engineer:20190129141706p:plain

使い方

Triggerを設定して、Snippetに使いたいものを入力します。
クエリ上でTriggerを入力するとスニペットに変換することができます。
画像のように設定すると default という入力が、下のsnippetに入力されてる文章に変換されます。

Queryフィルタ

WHERE句で絞り込んだ結果を、さらに絞りたい場合に使います。

使い方

f:id:zeals-engineer:20190129160511p:plain

SELECT句にas '< columnName >::filter'のように別名をつけると、検索結果のフィルタリングができます。
さらに、filter の部分を multi-filter とすると、複数のフィルタリング条件の選択が可能になります。

その他

  • クエリ結果への HTML 埋め込み機能 → 実行結果に色をつけたり、リンク集をつけることができます
  • Slack通知機能 → SlackにRedashの実行結果を通知させることができます
  • query_< query ID > でRedashの他のクエリのIDを指定することで、他のクエリの実行結果をテーブルのように参照できます

などなど、様々な使い方ができます。

まとめ

ZEALSではビジネスサイドのメンバーが会話のパフォーマンスを確認するため等に使っているツールなので、VISUALIZATIONを使って結果を見やすく出力すると喜んでもらえます。

続きを読む

Facebook Developer Circle ローンチイベントに登壇してきました!

f:id:zeals-engineer:20190128223934j:plain

皆さんこんにちは! ZEALSでサーバサイドエンジニアをやっている福本です!

最近はプロダクトマネージャーや技術広報・エンジニア採用など、色々なことを兼務させてもらっています!

さて、Facebookに関係するエンジニアのコミュニティとして『Facebook Developer Circle』なるものが世界各国に存在するのですが、1月27日に記念すべき東京ローンチイベントが行われました!

splashthat.com

普段MessengerのAPIにお世話になっている関係からイベントで登壇する機会を頂いたので、僕が登壇で話した内容についてお伝えできければと思います!
イベント全体の雰囲気や様子はWantedlyの方で記事を書いておりますので、そちらをご覧ください!

www.wantedly.com

登壇内容『Messenger APIで感じるコミュニケーションの未来』

当日はJR大崎駅の近くにある『TUNNEL TOKYO』さんでイベントを開催しました!
独特な雰囲気のある会場で、イベントは凄く盛り上がりました!

f:id:zeals-engineer:20190128161139j:plain

普段Messenger APIを叩いているからこそ感じる、コミュニケーションの未来について登壇し話をさせて頂きました!
実際に登壇で使用したスライド資料はこちらです!

speakerdeck.com

自己紹介(スライド1~5枚目)

最初に自己紹介を終えた後、僕たちZEALSのプロダクト「会話広告fanp」について少し説明させて頂きました!
チャットボットと聞くと、お問い合わせ窓口の自動化システムとよく勘違いされてしまうので、この辺りは誤解のないように説明させてもらいました!

Facebook Messengerとの関わり(スライド6~8枚目)

ZEALSは2016年にMessenger APIが公開された瞬間から使い出し、おかげさまでプロダクトが大きく成長することができました!

前日にデータ確認のために社内でSQLを叩いて驚いたのですが、fanp上では既に約2200万件の会話がユーザーと行われていました!!
ここまでチャットボット一本でやり切ることができるスタートアップもそう多くないと思いますし、プロダクトの成長を肌で感じる良い機会になりました。

改めてですが、いつもZEALSやfanpを応援してくれている皆さま、本当にありがとうございます!

もっとやりたいこと(スライド9~12枚目)

f:id:zeals-engineer:20190128161511p:plain
ただ、コミュニケーションはテキストや画像、動画のやり取りだけで完結するものではありません。

皆さんも、普段誰かとコミュニケーションを取るとき、もっと細かい情報のやり取りや色々な活動をしているはずです!
僕はボットの上でも同じようにコミュニケーションが取れるべきだと考えています。

例えば、他のプラットフォームでは決済がチャット上でシームレスに完結するようになっていたり、「ミニアプリ」と呼ばれるボットが稼働していて、もはやWebページも必要なくなっていたりします。
各社様々な体験をユーザーに届け、色んなコミュニケーションをボットと取ることを可能にしています!

MessengerもPayment APIが存在しますが、米国の一部のみでの公開で、日本ではまだ使用することができません。
僕たちもプラットフォームに頼らずに自分達で工夫して、最高の体験を日本のユーザーの皆さんに届けたいと思っています!

実現したい世界観(スライド13~15枚目)

f:id:zeals-engineer:20190128161906j:plain
では、チャットボットで多くのコミュニケーションを行うことができるようになると、どのような良いことがあるのでしょうか?
僕は、”インターネット社会の情報格差”をチャットボットによって解消することができるのではないかと考えています!

順を追って説明していきます!

まずは、企業がHPやSNSアカウントを持つのと同じような感覚で、みんなが当たり前にボットを持つようになる世界を作りたいと思っています!

チャットボットは、今はまだおもちゃであると捉えられることがあります。
それは、会社がWebページを作るのと同じレベルまで、「チャットボットを作ること」がまだ選択肢に上がっていないことからそう感じています。

しかし、これまでのテクノロジーの歴史を見れば明らかですが、当初おもちゃだった技術が世界を変えています。
僕たちは、会話広告「fanp」によって機械によるコミュニケーションを当たり前にすることで、チャットボットが世界を変えることができると確信しています。

"検索しなければ、欲しい情報にたどり着けない..."
チャットボットが当たり前の世の中になれば、一方的だったインターネットの世界が一変します。

f:id:zeals-engineer:20190128212023p:plain

インターネットはあらゆる側面で社会に平等をもたらしてくれましたが、検索する力がなければたどり着けない情報が世の中にはたくさん存在します。
もし、インターネットで情報を検索できなくてもチャットボットの方からユーザーの必要とする情報が届けられたら、その格差は解消されるはずです。

この格差を何とか解消し、最適な情報を手にした人々が、自分の意志のもとに行動することができる世界を僕たちは作っていきたいと考えています!

Facebook Developer Circleの今後

登壇資料の解説は以上となります!
最後までお付き合い頂きありがとうございました!

さて、Facebook Developer Circleの今後についてですが、毎月イベントを開催するなど、東京でも本格的な動きを開始します。

ハッカソンなども開催の予定で、ZEALSも国内で最もMessenger APIを叩く身として参加する予定です!
その際は、また様子を記事にしてお伝えできればと思います!

ちなみに、今回の登壇をきっかけにFacebook Developer Circleの運営委員会に福本が加入することになりました!!
今後も日本を代表して、Facebook Developerのコミュニティを盛り上げていければと思いますので、皆さま応援よろしくお願いいたします!

コミュニティの公式ページはこちらです!
今後ほぼ毎月イベントが開催されるようなので、ご興味ある方はぜひチェックしてみてください!

続きを読む