ZEALS TECH BLOG

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

EastgateHackathonにZEALSチームで参加しました!

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

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

3月16 ~ 17日に行われた『Eastgate Hackathon』にZEALSがチームで参加してきましたので、チームメンバーのご紹介とハッカソンで開発したプロダクトについてお伝えさせて頂ければと思います。

EastgateHackathonは「海外にチャンレンジするエンジニアを増やす」という思想のもとに開催されており、優勝者はFacebook本社がシリコンバレーで主催する”F8 Hackathon”への渡航費や現地ネットワーキングを得られる豪華なイベントでした。

www.eastgate.tokyo

世界一のプロダクト、そして世界一のエンジニアチームを本気で目指すZEALSとして参加しないわけにはいかず、チームを募って参加しました。

ちなみに私福本はハッカソン自体には参加せず、日本国内で最もFacbook MessengerのAPIを叩くZEALSを代表し「テックメンター」として、運営に近い形で当日ハッカソンをリードさせていただきました!

tech.zeals.co.jp

ハッカソン全体の雰囲気や福本の登壇部分については、Wantedlyで記事を書いておりますので、合わせてご覧いただけますと嬉しいです。

www.wantedly.com

  • ZEALS参加メンバー
  • 開発プロダクト
  • ピッチ&審査
  • さいごに
続きを読む

全てのmodelにvalidationを張った話

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

こんにちは、今回のブログ担当・あべです!

ZEALSにジョインして早3ヶ月…会話広告fanpのサーバーサイドエンジニアとして、日々勉強しつつ楽しく働いています!!

さて、今回のテーマですが、以前サーバサイドエンジニアの中村さんが書いてくれた年末自由開発『Hack Days』で取り組んだテーマのうちの一つ、 「データの整合性を確保するため、validationを書きまくる」 について詳しく書きたいと思います。

  • なぜこのテーマに取り組んだのか
  • 何をやったのか
  • 大変だったこと
  • テーマに取り組んだことでの学び
    • PRレビューの過程でテストの方針などが共有された
    • model周りの理解につながった
    • リファクタリングが進んだ
  • おわりに

なぜこのテーマに取り組んだのか

個々が自由に開発に取り組む中、なぜチームでこのテーマに取り組んだのか? 前提として、開発において以下のような課題がありました。

  • DBのテーブル構造に変更を加える際、本番環境で変更後のテーブル構造と不整合を起こす「 ゴミデータ 」が問題となっており、変更作業の負担になっている
  • ゴミデータが発生する主な原因として、「 Railsのmodelのvalidationが不十分だったこと 」があり、これを解消する必要がある

validationを張りまくりゴミデータを発生させないため、12月初旬から少しずつvalidationの修正をしていこう!という話がチームであがり、「1人1日1modelずつ張る」ということを目標にしました。

railsguides.jp

しかし、日々の開発や対応に追われて思うように進まず進捗はいまひとつ。。

そこで、年末自由開発の時間を使ってvalidation修正にチームの力を一点集中!!一気に終わらせよう!ということになったのです。

何をやったのか

validationを見直し、誤ったvalidation・不適切なvalidationがあれば修正する、ということを全modelに対して行いました。

具体的には…

1. DBスキーマとmodelのvalidationとの整合性を取る

  • DBスキーマの設定を確認し、その構造をmodelのvalidationとして書き起こしていく

2. DBスキーマで表現できないデータ構造があれば、validation側で追加実装する

  • URLやメールアドレスなどDBスキーマで表現しきれないデータ構造を持つカラムについては、カスタムvalidationとして実装し、データの正確性を維持する

3. Factoryから正しい構造のデータが生成されるようにする

  • 当該modelのFactoryを確認し、正しい構造のデータが生成されることを確認する

github.com

大変だったこと

まず大変だったことは、 「大量のタスクを短期間でこなす」 ということです。

今回の場合、タスク数=model数となりますが、その数

125個!!! (※後で数えました)

125、という数が多いか少ないかは人それぞれかと思いますが、前述の通り12月初旬に始めたものの進捗はいまひとつ…
未着手のもを大量に抱えたまま突入した年末開発で終わらせるには、チーム全員(6名)でひたすら潰すしかありませんでした。

数をこなすのももちろん大変ですが、そもそも書くvalidationを間違ってしまうとデータ周りで問題が発生してしまうため、素早くかつ正確にDBスキーマに沿って書くことが必要となります。

また、上記の内容に加え必要であれば新しくテストを書いたり、それに伴ったFactoryの改修テストデータの変更など付随する作業も多々あります。
最初は「結構簡単かな?」と思ったのもつかの間、気がつけば最後の成果発表会ギリギリまで作業してなんとか間に合った、という感じでした。

テーマに取り組んだことでの学び

この取り組みを通して、全てのmodelにvalidationを張ることができただけでなく、多くの学びがありました!

PRレビューの過程でテストの方針などが共有された

例えば、下記のようなことが共有されました。

  • enumテスト:enum定義におけるkeyやvalueの値までしっかりテストで検証する
  • build と build_stubbed 使い分け: build_stubbedはテストが高速 なのでbuildと分けて積極的に使う
    • build_stubbedを使うとassociation先のデータもDBにインサートされないため、少しですがテストが早くなります(塵も積もれば…ですね)
  • subject定義:shouda-matchersはsubjectを書いた方が第三者から理解しやすい

github.com

議論されたことがチームで共有されることによりテストの質が保たれたり、他の人にわかりやすくなったりと、より良いコードに繋がります。

model周りの理解につながった

このテーマに取り組むにあたりただ闇雲に進めるのではなく、作業したmodelと関係のあるmodel、さらにそれに関係のあるmodelと順に辿って作業しました。

業務で自分が開発したコード周りはよく理解していても、そうでないところはあまり理解できてないかったりします(私の場合は特に、ですね..)。
改めてmodel同士の関係性の把握や理解につながり、業務効率がアップしました!

リファクタリングが進んだ

リレーションの多いモデルにvalidationを追加した際テストが大量に落ちることがあり、テストの実装がvalidationに沿っておらず間違って実装されていたために大幅な修正が必要となりました。

結果として正確でないコードを見つけ書き直すことができ、validationの追加も含め大幅にコードを改善することができました!

おわりに

日々の開発に追われるとなかなかこういった地味な作業はできずに後回しになってしまいがちです。

続きを読む

「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がすごいのはゲームが競合だということを理解しているところですね。そういう見極めは難しいはず。

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

続きを読む