ボクココ

サービス開発を成功させるまでの歩み

Twilio の AuthToken と API Key の違い

ども、@kimihom です。

今回は Twilio ネタ。地味だけどこういうのって調べようと思わないと知らない内容だと思うので記事にしてみた。

AuthToken と API Key の違い

まず Twilio には API アクセスするために、AccountSID と AuthToken の2つが出てくる。これは Twilio をコードで使ったことがある方なら誰でも見たことのある項目のはずだ。基本的に、AccountSID と AuthToken の2つを使えば、どんな API リクエストでも実行が可能だ。

それゆえに、AccountSID と AuthToken のペアはマスターキー的な感じになっているので、できる限りあまり使いたくはないと思うだろう。AuthToken は特に大切に扱うべきだ。なぜなら AccountSID は割と公開された情報なので AuthToken がバレた瞬間に誰もが全ての API を実行できるような感じになってしまうからである。 Twilio の API 呼び出しは無料じゃないので、これは痛いところである。

きっと読者の皆さんも、AWS のアカウント管理で IAM をうまく使って管理をされているはずだ。Twilio ではどうすれば良いのか。

そこで Twilio には API Key という概念を提供して API 利用に応じてうまく分けようとしている。API Key には 2つの役割(Standard と Master) が用意されている。基本的には Standard の API Key を使うことで深刻な API(アカウントの作成/削除など) の利用を禁止することができる。てことで API Key を利用するなら Standard で作ることになるだろう。

Twilio は何でも API Key でできるのか?

うまく API Key を活用すれば、 AccountSID, API Key SID, API Key Secret の3つを保存するだけで Twilio REST API のアクセスが可能になる。つまり、データベースにサブアカウントごとの AuthToken を保存する必要がなくなる!

ここで Twilio の落とし穴にご注意を。Twilio の AccountSID と AuthToken でしかできない行動ってのがいくつかある。

  • Twilio Client の ケイパビリティトークンの生成 (なんでやねん)
  • API Key の作成

私がハマったのはこの2つ。もしかしたら他にもあるかもしれないので、 API Key で API アクセスを運用する際にはご注意を。 Twilio Client のケイパビリティトークンがなぜ AuthToken でしか生成できないのか、全くもって意味不明。これ Twilio の設計がイケてないんじゃないかと思ったほどだが、何か理由があるのだろう。ちなみに他の Chat, Video, Sync などのトークン生成は API Key と AccountSID で作れる。

終わりに

今回は Twilio の小ネタをご紹介した。Twiliio Client のケイパビリティトークン以外の API アクセスは、基本的に API Key ベースの API アクセスにした方が安全に Twilio を利用できると思う。

Admin の AccountSID と AuthToken だけ環境変数で持つようにして、サブアカウントの個々のリソースアクセスは API Key ベースでアクセスするって感じがいいんじゃないだろうか。

さて、いよいよ再来週になったが Twilio Developer Meetup、まだ空きがあるみたいなので参加検討いただけると幸いだ。ちなみに私も LT する予定なのでお楽しみに。

twiliomeetup.doorkeeper.jp

1人エンジニアでサービスを成長させるために実施したい4つのこと

ども、@kimihom です。

1人エンジニアでサービスを成長させるために実施したいことについてまとめてみる。

ローンチ前と後の違い

サービスローンチ前の開発ほど楽しいものはない。誰かに何かを言われるわけでもなく、ただこれを作る!と決めたものを夢中になって作っていける。間に割ってくる人もいない。いかに早く、そして良い物を作り上げることがローンチ前の使命だ。

ローンチした後からは別物となる。少数の見込み顧客がつきながら、その様子を見ながら開発していかなければならない。当然開発だけって状態ではなくなってきて、サーバーの運用やバグの修正、顧客サポートなどあらゆるタスクが入ってくる。

この時点でうまく人を雇ったりするのも1つの手かもしれないが、私はローンチ後も2年以上、ずっとエンジニア1人でやってきた。同じような人が今後出てきた時のために、私からの言葉として以下の文章をまとめる。

インフラを無駄にこだわらない

これはローンチ前に設計しなきゃいけない話ではあるんだけど、ローンチ後にインフラ整備をするようなケースがあったりする。それははっきり言って時間の無駄だ。一体なぜ現状アクセスがほとんどない(そして将来アクセスがくるかどうかもわからない)サービスのインフラで、将来のデータ量やアクセス数を気にしなければならないのか?

1人でやってるって場合は、ローンチ後も基本的にアプリケーションのコードをひたすら改善していくことが求められる。Infrastructure as Code だとか、マイクロサービスなんて話題は出てこない。

インフラは既にある信頼された PaaS を利用しよう。これによってデプロイ周りやインフラの構成など、自前で構築せずともベストプラクティスな環境を利用できる。

値段が高くなるなんてことは気にする必要はない。自前でインフラを持つことによってかかるインフラエンジニア1人のコスト or 自分でインフラに試行錯誤に使う時間に比べたら、PaaS にそれなりのお金を払うなんてことは本当に微々たる料金だ。しかも長年の経験と知恵で研ぎ澄まされてきた PaaS は雇ったインフラエンジニアよりも優秀な成果を生むだろう。

同じように、自前でやらなきゃいけない部分はサービスのコアの部分に集中させ、それ以外の一般的な部分(検索やDB, KVS)も外部の Addon という形で導入しよう。これによってサービスとは関係ないインフラレベルで問題が起きた時は自分で調べるのではなく、サポートに問い合わせてその分野の一流のプロフェッショナルにお願いすることができる。これだけでインフラ管理の手間がなくなる。同様に、ログ管理やメトリクス管理など、これらもPaaS の提供するアドオンで構成すれば、インフラは一流インフラエンジニアが構築した並みの環境を用意することができる。

改めて、1人でサービスを開発するのなら一番大事なのは、サービスのコア部分の開発だ。そのサービスで顧客に一番価値を届けられる部分を磨き続けること。それにいかに時間を費やすことができるかが勝負だ。そこさえ極めていけば、他の企業が10人かかって同様のサービスを出してきても対等に立ち向かえるサービスを作り上げることができる。

ぶっ壊すことを恐れない

実際にサービスを公開してみたら、顧客は違う機能を求めている傾向が強かった。そんなことがよく起こる。そん時にシステムを0から作り直さないといけないくらいのレベルでもぶっ壊していった方が、最終的にはいい結果を生む。なーに、0から作り直すっていったって、たかだか数ヶ月の時間をかけて作ったシステムではないか! 恐れずぶっ壊していこう。変に以前のサービス内容にこだわって変更しないままビジネスが成長しないことの方がよっぽど恐るべきことである。

だから、私は0->1のフェーズでテストコードをガリガリと書くのをオススメしない。1人でサービスを作ってローンチしたなら、テストコードを書く価値ってのはそこまで高くない。自分の中で設計図が全て頭に入っているので、他のメンバーが意図しない修正をされる心配もないのである。逆にテストコードを書けば書くほど、先ほどのぶっ壊すって選択をしづらくさせる。

こういう判断も、人が多ければ多いほど遅くなるだけだ。スピード感ってのは0->1のフェーズでは最も大切だけど、人が多いだけで遅くなってしまう。エンジニアは本当に限られた少数精鋭でやるべきだと考えている。私みたいにエンジニアは1人でも全然問題ない。

顧客管理の自動化を検討する

顧客が50, 100 と増えてきたら、顧客を自動で管理できるような体制を整えることを検討しよう。俗にいう管理ツールの整備だ。

具体的には CRM に顧客を登録して、チャットやメールなどの履歴、ユーザー行動、現状の設定状況などを全て一元管理できるような仕組みを用意することが望ましい。CRM の用意が難しいのなら、自前で社員の誰もが気軽に(そしてセキュアに)顧客情報にアクセスできる環境を用意しよう。これによってエンジニアだけでなく、ビジネスやマーケティング / サポートの人が顧客情報に手軽にアクセスできるようになり、新規顧客獲得の分析や、サポートの品質向上など、あらゆる面においてサービスの改善に役立ってくる。

サービス成功において大事なのはサービスの機能だけではない。こうした顧客情報をいかにして管理して社内で共有していくかってのもサービスの成功に重要な要素だ。

これによって社内の無駄な連絡コストも減る。みんなが CRM に情報を入力していくようなベースを整えていければ完璧だ。

情報を発信する

0->1 を作り上げたサービス開発のノウハウってのは情報の宝庫だ。ゼロから技術を使って構築した経験ってのは他の人も確実に欲しい情報で、拡散されやすい性質を持っている。

その技術を使ってどうやって実現したか。どこで詰まって、どうやって解決したか。何の情報が参考になったか。ブログを書くだけでなく、イベントに登壇したっていいかもしれない。私自身、ローンチ後はかなりのイベントに参加して知見を共有していった。そして今でも可能な限りイベントに参加してこれまでの経験をシェアするようにしている。

登壇履歴と資料 - ボクココ

ブログや登壇によってエンジニアとしての価値を高めることもできるし、サービスの宣伝もできる。0->1をやったのに何も情報発信をしないってのはあまりにも勿体無すぎる選択だ。1人エンジニアの場合はコードを書くだけでなく、こうしたアウトプットも必ず求められる。

終わりに

今回の4つのことは、私がやってきて正解だと思ったことに絞って紹介した。

1人エンジニアってのは時に孤独を伴うが、自分の理想のシステムを求め続けられるって意味でなかなかエキサイティングなことだと思っている。自分の極めたい技術のコミュニティに入れば、情報交換だってできる。だから自分のシステムは思い切って1人で作り上げるくらいの気迫を見せて欲しい。

サービスに対して情熱的なエンジニアが増えていって、いいサービスが増えて行くといいなと思う。

Twilio TaskRouter が目指すもの

ども、@kimihom です。

f:id:cevid_cpp:20170711192614p:plain

Twilio をちょっとかじってると、 TaskRouter という言葉を目にすることがある。たいていの場合、「何やらよくわからんもの」くらいな感じでスルーしてしまいがちなんだけど、この TaskRouter は Twilio の目指す世界観を深く表しているサービスなのでご紹介しようと思う。

TaskRouter とは

TaskRouter とは、コンタクトセンターにやってくる全ての電話/メール/チャット/その他作業を “Task” として定義し、待機しているオペレーター(以降 Worker) に Task を最適に分配するシステムのことである。Worker にはそれぞれスキルを定義することができて、やってきた Task に対して優先度付けを行い、最適な Worker に Task を割り当てることができる。このスキルには Worker の話せる言語をセットしたり、サポート/営業 といった部署で振り分けたり、最初に電話を受ける担当みたいなことをセットしたりできる。また、Worker が一定時間 Task に対応してくれなかったら別の Worker に再アサインするような仕組みまで用意されている。

あらゆる問い合わせが大量にやってくるコンタクトセンターを想像してみて欲しい。そこにはあらゆる種類の問い合わせと、あらゆる種類のチャネル(電話/メール/SNS) での問い合わせがやってくる。それらを上から一つずつ対応していくってのも無理なくらい問い合わせが来た場合には、優先度付けして対応していかないといけないんだけども、それらを都度マネージャーみたいな人が手動で割り当てるのって時間の無駄だよねって発想が根底としてある。

このマネージャーの振り分け判断基準みたいなのを、全て自動化しようってのが TaskRouter の考え方だ。

Twilio としてはオムニチャネル化を目指している傾向が強く、TaskRouter はそのオムニチャネル対応を可能にする手段と言えよう。オムニチャネルとは、全てのチャネル(電話/メール/SNS etc) を同一の端末で対応ができるような統合的なチャネルサポートと本記事では定義する。

TaskRouter を使うメリット

やって来る問い合わせが逐次で対応できないくらい大量に来る場合に、 TaskRouter を検討するのが良いと思う。

基本的に、TaskRouter を使う場合は全ての着信はキューに溜め込む必要がある。そのキューに入れた通話やメールに対してどれが一番先に対応しないといけないのかを TaskRouter が判断して、各 Worker に通知を送るのだ。大規模コールセンターを想定しているくらいだから、デフォルトで着信をキューに入れるってのは当然の話かもしれないが、それじゃ困る(普通にブルルって着信を鳴らしたい)って場合は TaskRouter の利用は向かない。

TaskRouter には JavaScript SDK が用意されている。この JavaScript SDK を利用することで、Worker がログインした時点で今対応しなきゃいけない Task が出て来た時にポップアップ表示できるような仕組みを構築できる。裏では WebSocket によるプッシュ通知が行われているような仕組みだ。私たちはその Task がやって来たら コールキューで待っている電話を繋ぎに行ったり、メール返信したりするような UI と機能を構築すればいいことになる。

また、TaskRouter を使えば リアルタイム/統計 の分析ができるのも大きな魅力だ。誰が今どんな対応をしているのかってのはスーパーバイザー的な立ち位置の人には必要な機能だ。また今月どのくらいの通話があったのかなどの分析も TaskRouter を使えば標準 API を呼ぶだけで取ってこれるってのも、TaskRouter を使って得られる魅力だろう。TaskRouter を使わなければ、これらの仕組みを自前で DB に保存して取得しなければならない。

そしてさらに ワークフォースマネジメント(Worker の勤怠管理的な)のを実現するのにも TaskRouter は役に立つ。今後、これら付加的な機能は Twilio Addon として他の企業の提供するワークフォースマネジメントツールと連携される予定なので、もし興味があれば調べてみていただきたい。これらは最近の大規模コールセンターシステムの機能でよく言われている話なので、コールセンター業界にいる方なら知っていることも多いかと思う。

参考資料

US のランディングページ www.twilio.com

日本語のドキュメント

Twilio TaskRouter - Twilio

終わりに

今回は Twilio の最難関と言っても過言ではない TaskRouter の概要について紹介した。今月(7月)末に Twilio Developer の集まるイベントがあるので、もしよければこちらの参加も検討いただけたら幸いである。ぜひ有意義な情報交換をしましょう!

twiliomeetup.doorkeeper.jp

顧客管理の重要性について改めて思うこと

ども、@kimihom です。

f:id:cevid_cpp:20170710184018p:plain

(初めて Canva で作成してみた)

唐突ではあるけども、皆さん、顧客管理してますか? 今回は顧客管理の重要性について改めて記していこうと思う。

顧客との接点の全てを記録しよう

企業活動ってのは当然一人でするものではない。ある時セールスの佐藤さんが A 株式会社とメールをやり取りし、面談に行ったとしよう。その A 株式会社は後に顧客となり、サポートの 鈴木さんが担当することになった。果たして、鈴木さんは A 株式会社の情報をどれだけ把握することができるだろうか?

ここが企業の強さを左右すると思う。サポートの鈴木さんに何も情報がなければ、きっと鈴木さんは佐藤さんに確認するような手順を踏むことになるだろう。これが2人だけならまだしも、10人100人と関係者が増えていくにつれ、そんな記憶ベースの管理は破綻する。結果として情報が分断されてしまって最終的には A 株式会社に同じことを聞く、もしくは知らない前提で対応するという行動を取ってしまう。それでは当然、顧客満足度を上げることはできないし、むしろ低下する一方である。そんな顧客対応の繰り返しが、やがて企業の存続を危ぶむほどになるのである。

顧客との接点全てを管理できれば、先ほどのようなトラブルは無くなる。担当者が変わっても、顧客情報を閲覧すれば、今まで誰がどんな対応をして今どういう状態なのかを一瞬で把握することができる。誰かに教えてもらわずとも、最高の引き継ぎができた状態で顧客と接することができるようになるのだ!

これは企業が大きくなればなるほど、時間が経てば経つほど、顧客が増えれば増えるほど、大事になってくる。

顧客管理ソフト(CRM) に全ての情報を集約する

CRM はそのために存在する。顧客との接点全てを Web 上で保存し、顧客とのやりとりを誰もが管理できるようになるシステムである。

完璧な CRM 運用をすれば、メールが来た瞬間、誰がいつどんな対面や電話対応をしたのかが一瞬で把握できるようになる。これは顧客満足度の上昇だけでなく、仕事の効率化にも繋がり、ビジネスをより飛躍させることができる。だからこそ、成功している企業こそ顧客管理をしっかりとしているのだ。

CRM 活用の先には、"優良顧客"にはどんな特徴があって、どういうことをしたらそうなったのかといった分析も可能になる。正しい顧客を呼び込むことができるようになり、正しい顧客に正しいサービスを提供することができるようになるのである。

顧客管理がビジネスの成功を左右すると言っても過言ではない、と最近は思う。

いかにして自動化するか、テクノロジー企業の腕の見せ所

分断された情報をどうやって一つにまとめるのかってのが課題となってくる。メールでやり取りしたら、わざわざその CRM に手入力しなければならないのか?電話するたびにメモをそこに保存しなければならないのか?対面するたびに?キャンペーンメール送るたびに?

実際、全ての情報を入れる必要があるのだから、どんな方法であれ顧客とのやりとりを保存しなければならない。顧客とのやりとりをいかにして CRM に蓄積し、手軽に参照できるようにするか。エンジニアの腕の見せ所である。

顧客との接点は以下のようなものが存在する。

  • サービス利用(Web/アプリ上での会員情報や行動履歴)
  • 対面
  • 電話
  • メール
  • SNS
  • その他新しいコミュニケーションチャネル (チャットやビデオ通話など)

まずは顧客情報を登録することが先手だ。住所、電話番号、メールアドレス、SNSアカウントなど。これらの情報を元に、 CRM 上の顧客を一意にすることが必要である。そうしたら検索によってマッチする顧客の活動として書き出したり、予定として登録したりできるようになる。

少なくとも顧客を"マージ"するような機能のある CRM の利用を検討したほうがいいだろう。そうじゃないと顧客がメールや電話番号ごとに分断されてしまい、本来の CRM のメリットを活用することができないからだ。完璧な顧客情報のベースがあって初めて、その先の顧客の検索や活動情報の入力ができるようになるのである。

んで、CRM 登録の一部は自動化できるけど、一部はどうしても手作業が入ってしまう。その手間を惜しまず、完璧な顧客管理を目指していく姿勢が絶対に必要だ。ただ単にシステム連携して書き出しっぱなしにしているようだと、ゴミデータがどんどん溜まっていくだけで何のメリットも享受することができないのである。

顧客管理を徹底した先に見える理想像

セールスの佐藤さんは A 株式会社と以前コンタクトを取り、 CRM に住所とメールアドレス、面談内容を入力した。ある日、A株式会社は顧客となり、会員情報として電話番号を入力していただいた。入力ある日、A株式会社からメール問い合わせがあり、鈴木さんが担当することになった。鈴木さんは以前どんな対応をして来たのかを CRM で確認し、既存顧客への返答として最適なサポートをした。半年経って、再び A 株式会社から電話がかかって来て、今度は高橋さんが担当した。当然、高橋さんは半年前の記録を見ることができるので、A株式会社が忘れてたようなことまでサポートでき、最終的に A株式会社はロイヤルカスタマーになった。

CRM を本気で運用している会社はここまで既に実現している。このような顧客管理は、会社全体で取り組んでいかないと実現は不可能だ。

一人一人が CRM を入力/整備しながら完璧を目指していく。そんな姿勢によって初めて、ビジネスを成功に導く CRM となることができるのではないだろうか。

誰でも情報を入力できる環境ってのが大事で、そこが徹底されている企業は、強い企業になると思う。

終わりに

顧客管理の徹底は、特にスタートアップ時期だと忘れがちなことだと思うんだけど、ぜひしっかりと顧客管理のできる企業が増えていってほしいと思う。

しっかりと顧客情報のベースが CRM にあって、自社の社員が情報を入力/整備できるような仕組みを整えてこそ、初めて顧客管理が始められる。顧客との接点全てを記録しなければならないから、手入力が時に必要になることだって当然存在する。そこを勘違いして全部自動化でやろうとすると必ず失敗するので気をつけてほしい。

まずは一人一人が顧客管理の重要性を理解し、できる限り CRM に情報を入力していくことから初めてみてはいかがだろうか。

実はこんなにあった Twilio のサービスを紹介

ども、@kimihom です。

f:id:cevid_cpp:20170707220201p:plain

みなさんは Twilio 使っているだろうか?「あ〜あの電話かけられる API でしょ」という方は、それはもう3年以上前に出会ったっきりで終わっていることだろう。あれから Twilio はアメリカで上場を果たし、さらなるサービス提供を進めている。てことで今回は日本で Twilio を使って何かやっていく場合に有益になるそうなサービスを全て紹介していく。もしかすると、今すぐにでも欲しい API が見つかるかもしれない。

twilio.kddi-web.com

プログラマブル Voice

まずは一番メジャーな音声通話の API 。050/0800/0120 番号を取得し、その番号に対してあらゆる命令を投げかけることができる。例えば API で電話を発信できちゃったり、通話中に API を呼んで何かに切り替えたりと、複雑な音声技術を API を呼ぶだけで実現できてしまう。 今でも Twilio 最大の強みは Voice だと思うので、まずは Voice で感動を味わってみていただきたい。API で「すごっ」と思う数少ない経験をすることができるだろう。

プログラマブル Fax

Fax を API で呼ぶことのできる仕組み。 PDF や PNG 画像で Fax を送ることができ、またさらに受信もできる。Twilio の提供する 050 番号なので、その番号は Fax もできるし電話もできるような番号にすることが可能だ。特に日本は Fax 文化が強いので、電話/Fax を組み合わせた何かが出て来てくるのが望まれていると思う。

プログラマブル Video

Twilio のビデオ通話のプラットフォームだ。日本では Skyway がメジャーだとは思うが、 Twilio もビデオ通話のプラットフォームを提供している。今までの Twilio Video は P2P 接続のみのサポートだったが、つい最近、サーバーを経由したビデオ通話(SFU) を提供している。これにより、通話の録画や同時100人までの通話が可能になった。

プログラマブル Chat

Twilio のチャットのプラットフォームである。一般的なチャットを作るには、 ユーザー/会話部屋/メッセージ/招待/権限・・・などなど、共通の実装が必要になる。これらを全て API で提供し、基本的なチャットをサーバーのコードを限りなく少なくし、データ自体も Twilio に保存してくれるような仕組みを提供している。これによって誰でも本格的なチャットシステムを構築することが可能になる。

Sync (beta)

Sync はまさに Firebase のリアルタイムデータベースのようなものだと考えていただいて良いかと思う。Firebase は基本的に JSON のみのモバイルにフォーカスされたプロダクトかと思うが、 Sync には JSON(ドキュメント) によるデータ同期の他に、 List や Map といった同期のためのデータ構造を用意してくれる。先ほどの Chat の部分のデータプッシュ周りのみにしたシンプルなサービスである。

Proxy (beta)

Proxy は匿名コミュニケーションのプラットフォームだ。Airbnb や Uber を使ったことがある方なら経験がある通り、知らない相手とやりとりするために間に仮の番号を発行し、その番号を通して電話やメッセージをやりとりすることでプライバシーを守るための仕組みを提供してくれる。 Proxy を使えば、利用する番号を良い感じに調整してくれたり、相手と結びつけを行ったりすることを簡単にしてくれる。今後は プログラマブル Chat / Facebook Messenger といったチャネルでの匿名通話が可能になるとのこと。

Channels (beta)

存在するあらゆるチャンネル LINE/メール/Slack/Twitter/Facebook/Alexa を使って相手とメッセージの送受信が可能になるプラットフォーム。相手が LINE でこっちが Facebook といったコミュニケーションを可能にしてくれる。通常、こういうのを作るには全てのプラットフォームに対応した SDK を用意し、そのための実装が必要だったが、Channels によって決まったコードを書くだけであらゆるチャンネルに対応したコミュニケーション・ハブを構築できる。

Notify (beta)

Notify は通知をするためのプラットフォームだ。サービスで色々なチャネルを提供していると、ユーザーに通知を送りたいデバイスがどんどん増えてくる。iOS, Android, Facebook Messenger, SMS など。これらにおいて優先度(今開いているデバイスが優先度高)をつけ、反応しなかったら次の優先度のデバイスに通知するようなスマートな通知を提供することができる。

プログラマブル Wireless (beta)

電話機能付きの プログラム可能な SIM カードの提供。API を通じて SIM の操作が可能で、日本でもローミングを使って通信が可能。まだ SIM 自体が前回の Signal カンファレンスで配れた段階なので、まだ一般の手に普及するには時間がかかるが、音声通話付き SIM ということで Twilio Voice との連携などが可能になる。

Authy

2段階認証のためのプラットフォーム。Google Authenticator が有名かとは思うが、 Authy は電話/SMS/アプリといったチャネルでの2段階認証が可能で、今後はアプリのプッシュ通知で認証を通すといった手軽さを実現できる。アメリカでは Authy はかなりの人気アプリなんだけど、日本語化されていないせいか日本での普及は今ひとつといったところ。日本語化に期待したい

タスクルーター

電話/SMS/チャット/ビデオ通話 といったあらゆるチャネルのサポートを一元管理し、大量の問い合わせが来た時に最適な1つの問い合わせにオペレーターを紐づけるための仕組み。Twilio としては電話だけでなくあらゆるチャネルを提供しているため、タスクルーターを使ってどんなチャネルから問い合わせが来ても、スマートに顧客とのやりとりができるようにしたいと考えている(Contexual Communication: 文脈を把握した会話)。

Runtime (beta)

Twilio を利用するには、従来は何かしらプログラムを動かせるサーバーが必要だった。しかし Runtime の Functions を使えば実行可能なコードを Web 上で記述し、実行することができる。AWS でいう Lambda + API Gateway のような仕組みが Twilio で使えるという感じ。電話操作する何か作りたいんだけど、サーバー用意するまでもないといった場合には便利。また S3 のようなファイルストレージである Assets も提供しているため、頑張れば Runtime だけでそれなりのシステムを作ることができる。

終わりに

きっと多くの読者の方は今の Twilio はこんなにあったのか!と思ったことだろう。実際アメリカでは相当多くの開発者が Twilio を使って手間をかけずに高品質なサービスを作り上げている。車輪の再発明は終わりにしよう。もっとユーザーに価値を与えられる部分に力を入れていくために、Twilio は大きな力になってくれることだろう。

ベータ多すぎ?確かに多いけどそういうのをいち早く飛びついた方が、最初の素晴らしいサービスを提供できるのではないかな。

ところでそんな Twilio なんだけど、今月末に東京で割と大きめなイベントをやるからチェックしてみてね!

twiliomeetup.doorkeeper.jp

PostgreSQL の JSONB 型の紹介とメリット

ども、@kimhom です。

今回は必要に駆られて PostgreSQL で新しく登場した JSONB 型について調べるきっかけがあったので、まとめてみる。

予め断っておくと JSONB 型はいわば PostgreSQL のリレーショナルデータベースからの脱却だ。これは一見魅力的に見えるけど、誰もが待ち望んだ機能というわけではない。導入するときは慎重に検討するようにしたいところだ。

なぜ JSONB 型が必要になったか

特に SaaS のアプリケーションを作っている方なら共感してくれると思うのだけど、保存したいデータが顧客によって異なるというケースが否応にしてある。例えば 顧客管理のサービスを扱っているなら、業界ごとに保存しなければならない項目(本記事ではカスタム項目と呼ぶ)は異なってくるし、逆に不要な項目なども出てくることだろう。そんな中、最もやってはいけない妥協が、とりあえず全ての項目を表示させるってやり方だ。これだと、機能がどんどん複雑になっていってしまって、誰のためのサービスなのかわからなくなってきてしまう。しかし、従来のリレーショナルデータベースでの設計であれば、それが正攻法だったし、リレーショナルデータベースとしての正しい使い方でもあったわけだ。

カスタム項目を最初にうまく実現したのは Salesforce だろう。そのあと、kintone のようなクラウドデータベースや、Hubspot などのカスタマイズ可能な CRM などが出てきている。最近では Zendesk や Intercom も同様のカスタム項目を提供するようになってきた。お分かりの通り、もはやカスタム項目は SaaS をより拡張して誰もが最適なアプリケーションになるために必須となりつつある技術である。

PostgreSQL には、従来より hstore と呼ばれる Key/Value で保存されるデータ形式が提供されていた。しかし、これではネストができなかったり、インデックスが効かなかったりとで不自由なことが多かった。そして最近 PostgreSQL には JSON 型が出てきたわけだけども、これはこれで圧縮されていないためデータ効率が悪かったり、インデックスが効かないというデメリットがあった。それらを解決し、カスタム項目といった柔軟なデータベース設計ができるようにするために、JSONB 型ってのが登場してきた。

カスタム項目を作りたい人は、従来はそのほかのデータベース(MongoDBなど)を選択することになっていたと思うが、これからは NoSQL のような柔軟性を兼ね揃えた PostgreSQL でも実現可能ということになる。もっとこれはビッグニュースになっていいと思うんだけど、あまり注目はされていない? ようなのでもうちょっと詳しく書いていく。

JSONB 型の利用

Great News。 Rails 4.2.5 からは JSONB 形式が標準でサポートされている。その他主要な Web アプリケーションフレームワークでも、今後サポートされていくことだろう。

def change
    create_table :model do |t|
      t.jsonb :payload
      # .....
    end
    add_index(:model, :payload, using: 'gin')
  end

この GIN インデックスってのが JSONB 用のインデックスだ。今までこのようなカスタム属性用のインデックスはなかったので、新しいデータ活用が見込めるだろう。このインデックスの詳細は他で調べてみていただきたい。

んで肝心の JSONB データのアクセスなんだけど、以下のような新しい記法を目にすることになるだろう。

  • -> JSON のオブジェクトフィールド名や配列インデックスを指定し、その値をJSONB型で取得
  • ->> JSON のオブジェクトフィールド名や配列インデックスを指定し、その値をTEXT型で取得
  • #> は階層パスを指定して その値をJSONB型 で取得
  • #>> は階層パスを指定して その値をTEXT型 で取得

最近の PostgreSQL では JSON の特定の Key/Value を更新することができるようになったし、保存された JSON を each してくれるような SQL 構文も用意されている。なんだかんだ PostgreSQL の JSON サポートしてから 2年くらい経つようである。調べてみると、次の PostgreSQL は Version 10 らしく、メジャーアップデートが控えているようなので、そこまで様子を見守りたいところでもある。

参考リンク

以下の記事はお世話になったので、より詳細を知りたい方はぜひ読んでみて、可能性を感じてほしい。

特に最後のリンクのユースケースは、どのような応用ができるのかを挙げていただいていて参考になった。

終わりに

ちなみに Heroku Postgres はすでに 9.6 をサポートしているので、この JSONB 型を自由に扱うことができる。

こういうインフラストラクチャレベルの新機能ってのは、新しい機能を持ったサービスが出てくる予兆だと思う。ぜひこの JSONB 型を使って何か素晴らしいサービスが作れないか、考えてみてはいかがだろうか。その機能ってのは、きっと今まで実現困難だった何かであるはずで、新規性という意味で差別化できることだろう。私はどっちかっていうとフロントエンドエンジニアだけど、久々にデータベースを勉強してワクワクしたものを見つけた気分である。

さぁって、私も設計を始めるとしよう。

内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Software Design plus)

内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Software Design plus)

体験レベルを上げることのメリット

ども、@kimihom です。

一般的な人の認識として、「たくさん旅行して美味しい料理食べて、たくさん遊びたい」といったことを求めている人が多い。今回はそれらと比較して高いレベルの体験について語ろうと思う。

誰でも体験できるか、あなただけの体験か

お金と時間を使えば誰だって体験できるのはレベルが高くないと思う。つまりお金を払ってハワイに行ったり、お金を払って美味しい料理を食べたり、お金を払ってカラオケに行ったり。これらってのはあなただけの体験というよりかはお金を払って得られる体験に過ぎない。

んで、そういうの(目先の利益)を求めるとお金至上主義者が見事に生まれる。なぜならばこういう体験をするためにはお金が必要だからだ。目先の誰でもできる体験に目が囚われて、自分にしかできない体験を追うことができない、むしろそういう体験を面倒と言って毛嫌いしているようにすら見える。そこには孤独や努力などが必要だからである。

さて、ここでいう「自分にしかできない体験」とは何か。

何かを磨いた先に得られる新体験を求めよう

例えば芸術家や研究者を見てみよう。彼らは自分の理想を常に求めて、一つのことを磨き続けている。常にそのことだけを考えて、試行錯誤し一つの何かを究明しようとしている。

先ほどの誰でも体験できることを楽しいとしている人は、「楽しいことが何もできなくてつまらない」と考えることだろう。

しかし、そうした"磨き続ける"ことが仕事の人は、普通の人が体験できないレベルの体験ができる。自分の理想の絵が描けた、長年謎だったことが究明された。こういう体験レベルは非常に高い。あることを磨き続けた結果得られたものであるので、単にお金を払って得られた体験とは比べ物にならないほど、貴重なものとなる。他の人がいくらお金を持っていても達することのできない体験だ。

概して成功した人ってのはこの体験レベルを重要視しているはずだ。なぜなら美味しいものやおしゃれや旅といった"目の前の"体験てのはそれだけで時間とお金がかかる。その時間やお金を自分の磨いたいものに向けられれば、それだけで他の人との大きな違いを産むことができる。あなたにしかできない何かが生まれる。

そういう意味では自分の極めたいものにいくらだけ時間やお金を投資できるかってのが今後の生活に大きく左右されると思う。誰だってできる仕事なんてのは当然価値が低いからだ。自分にしかできない仕事を持つことで未来の自分の価値を高めることができるし、一般の人には体験できない自分だけの体験を生み出し続けることができる。

私はそう信じている。

終わりに

自分だけの体験を磨き続ける人が増えていってほしいし、そういう人たちの話を聞いてみたい。概してそのような方々は情熱を持っているものだから。

もちろん先ほど挙げた目の前の体験例も、極めればその人にしか見えないものが生まれることだろう。今回の話ってのは自分の突き詰めたいものを持って生きるか、そうでないかの比較として考えていただけたら幸いだ。

子供だなぁと言われそうな文章だけども、そこんところ妥協せずやっていきたいと思っている。