ボクココ

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

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) を提供している。これにより、通話の録画や同時50人までの通話が可能になった。

プログラマブル 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 です。

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

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

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

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

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

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

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

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

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

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

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

私はそう信じている。

終わりに

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

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

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

Heroku Pipeline にステージング環境を乗せてみた

ども、@kimihom です。

今回はステージング環境と本番環境で Heroku アプリを分けていたものを、 Heroku Pipeline でまとめたのでその手順についてご紹介する。

今まで Heroku Pipeline を勘違いしていたんだけど、ステージング環境の Heroku アプリは Heroku アプリの設定を保ったまま残る。つまり、アドオンや、アドオン内で保存されたデータなどはそのまま保たれるということを意味する。ステージング環境と本番環境の切り替えだけの場合は特に大きな変更をすることなく Pipeline へ移行できた。

RAILS_ENV での環境切り替えは非推奨

Rails アプリは、 RAILS_ENV の環境変数によって、読み込みに行く config/environments/~.rb を変えてくれる。これをうまく利用して、Heroku の RAILS_ENV を staging にすると、config/environments/staging.rb を読み込んだ状態でアプリを起動してくれる。また、Rails.env.staging? といったメソッドを利用できるため、コード内で ステージング環境と本番環境を分けたコードを書くことができる。

ただし、この方法は Heroku では非推奨とされる。このようなアプリを書いて Heroku にデプロイすると、以下のような警告が表示される。

f:id:cevid_cpp:20170626005319p:plain

Heroku アプリは全てproduction環境であるべきとされ、アプリごとの差分は環境変数で管理しなければならない。デプロイするたびにこの警告を見るのは気分がよろしくないから、思い切って同じ Production 環境の Heroku アプリとして Heroku Pipeline に移しつつ、警告が出る問題をクリアしようってわけ。

既存本番アプリに Pipeline を作成

さて、Heroku Pipeline を使ってみよう。Heroku Pipeline を使えば修正内容を ステージング環境でチェックしたら 本番へデプロイするみたいな流れを Heroku と Github のプルリクエストで管理できるようになる。それぞれの Heroku アプリは継続的デリバリーのワークローとして例えば以下のようなステップで表すことができる。

  • Review
  • Development
  • Staging
  • Production

ひとまず、本番環境で運用する Heroku アプリの画面から Heroku Pipeline を有効にしよう。

f:id:cevid_cpp:20170625225354p:plain

そんで Pipeline の画面に行ったら、Add Existing App をクリックし、既存で管理してた別のステージング環境のアプリを指定する。

f:id:cevid_cpp:20170626003549p:plain

無事追加すると、Heroku のアプリ一覧は以下のような感じに統合される。2 Apps となって一緒のアプリになった感が出たね!そして Pipeline には Staging でのアプリが表示されるようになった。

f:id:cevid_cpp:20170626003759p:plain

f:id:cevid_cpp:20170626004304p:plain

本来ならこれで Github と連携すれば、プルリクエストに応じてパイプラインのアプリが Heroku にデプロイされ、Accept すると勝手に Staging から Production へ昇格させたりできるらしいけど、Bitbucket での運用の場合は普通に git push heroku master とかでデプロイする感じになる。つまり、今までと特に何も変わらないってこと。今後 Heroku の Bitbucket 対応を待つか、諦めて Github にお金を払ってプライベート環境を用意するかになりそうである。

ソースの修正

さて、Bitbucket Pipeline はこのくらいにしておいて、Heroku デプロイの際に表示されるあの忌まわしい Waring を消す作業をしていこう。

これを実施するには、以下のような流れとなる。

  1. config/environments/staging.rbconfig/environments/production.rb の差分を確認
  2. 適宜 環境変数に置き換える
  3. その他コードで Rails.env.staging? のコードを探し、必要に応じて環境変数に置き換える
  4. デプロイ
  5. ステージングアプリで heroku config:set RAILS_ENV=production を適用   環境ごとの差分は staging, productionif 文で切り替えるのではなく、ENV環境変数 で切り替えよう。ここはソースを grep しながら、慎重に修正していかないといけない。

1 の environments の切り替えで特にオススメしたいのはログレベルの設定だ。LOG_LEVEL=infoが本番、LOG_LEVEL=debug がステージングって感じにして config/environments/production.rbconfig.log_level = ENV['LOG_LEVEL'].to_sym にしておくと何かと便利である。

これでステージング環境に Heroku をデプロイすると、見事警告を消去することができた!Heroku に怒られないようになったのはとても喜ばしいことである。

終わりに

今回は、本番環境とステージング環境を別々で管理していた Heroku アプリケーションを、 Heroku Pipeline 上で一まとまりとして管理できるようにした。さらに個々のアプリを 環境変数で対応するようにすることで、デプロイ時の警告を消去することに成功した。

Heroku Pipeline のより具体的な運用事例に関しては、前回の Heroku Meetup の tambourine の安部さんの発表資料を見るといいと思う。

www.bokukoko.info

それでは素敵な Heroku ライフを。

Heroku Strike のイベントに行ってきたレポ

ども、@kimihom です。

Heroku UG で定期的に開催している Heroku Meetup に行ってきたのでそのレポ。今回はがっつり Heroku を使っている方々の運用事例だったり、Heroku を選択する理由、Heroku の最新機能など盛りだくさんの内容だったのでブログに書くしかないと感じたので早速記事にする。

Heroku Meetup #17 Heroku Strike - Japan Heroku User Group | Doorkeeper

Node.js や PHP でもこわくない Heroku

まずはお世話になっている 10madoの山岡さんの登壇。ちょっと前までは “Heroku = Ruby” な印象が強かったけど、今では Node.js や PHP でも不自由なく使えるようになっていて、実際に 別言語プラットフォームで運用している事例を紹介していただいた。

個人的には山岡さんの Google Form x Slack 通知周りでとてもお世話になった記事があって、今回も Google Analytics から Slack 通知の運用をされているってことで、そこに興味を持った(Heroku は関係ないw)。いつか記事にしてくれるみたいなのでとても楽しみ。

あとは Terraform で環境設定をコード化したり、死活監視に Uptime Robot を使っていたりしていたのが独特な感じがした。インフラ管理周りは個人的にほとんど詳しくなく、名前しか聞いたことないレベルだったので調べてみよう。

そして最後の言葉がぐさっときた。"Heroku に委ねた結果試行錯誤が減る。" これは次の発表にもつながってくるワードだった。

スタートアップのインフラ選び(仮)

続いて crispy の高丸さんの登壇。高丸さんも個人的にとてもお世話になっている方でインフラもわかるアプリケーションエンジニアって感じの凄腕エンジニアだ。

私からすると、昔から Heroku 一択で他の選択肢はちょろっと見るだけで ほとんど比較することもなかったんだけど、具体的にそれぞれのプラットフォームを比較した上で、なぜ最終的に Heroku を選んだかという内容だった。

0->1のフェーズであなたならどうしますか?って部分は考え方が似ている部分が多くて安心した。私も Heroku x Rails な構成でいかに早く顧客に価値を提供するかを考えていたので、やはり Heroku はそういった場合に有用になるはずだ。

今は少人数の開発だから一番シンプルな形でなんとかなっているけど、今後規模が大きくなったり、人数が増えてきたりした時のことまで考えていたのがさすがだった。Heroku 一択な状態というよりかは、Docker コンテナをうまく活用してチームで分業できるような体制などを検討しておかないと、今後の成長スピードを技術的負債で一気に遅める危険性もある。(まさにp40の件) 自分のサービスは新規開発って意味では落ち着いてきたフェーズに入るので、この部分もうちょい勉強して検討していかないとな~。

受託案件での Heroku 運用

受託開発で Heroku を用いてやられている tambourine さん。いつも TAM さんの会場提供してもらってお世話になってる。安部さんからは Heroku Pipeline や Heroku CI などを用いたクールな Heroku 運用事例を紹介していただいた。

個人的にもこの運用方法はとても興味があったんだけど、Github 限定ってことで Bitbucket ユーザーの自分にはなかなか手が出せないところを、ちゃんと使えばこんなことまでできる!って具合で解説してくれた。

開発中にレビューしたり、本番でトラブった時にすぐに戻せるような状態にしたり、Hotfix ブランチで速攻直して本番反映したりといった流れはよくあると思う。これらを Heroku Pipeline でどう実現するか図でわかりやすく説明していただいた。

自分があーだこーだいうより資料見たほうがいい説明されてるので、是非読んでみてほしい。

Heroku の細かすぎて伝わらない最新情報

最後は岡本さんより最新情報。

4つの新機能ってことで、JVM Metrics, Release Phase, DNS Service Discovery, Heroku Shield を紹介していただいた。Java ユーザーに嬉しい JVM Metrics は、 Librato のようなメトリクスツールに表示させたり、Heroku 本体のメトリクスに表示させたりすることができるようになる模様。今後 Java だけでなく他の言語にも対応されるってことで、こういうメトリクス系が増えるのは原因を特定する上でありがたいのでどんどん出てきてほしいと思った。

Release Phase は CDN の更新とかを中心にデプロイの度に何かしたい時にコードを実行できる仕組み。git push heroku master をした後に必ず毎回何かコマンドを実行しているような人にとってはありがたい機能になるだろう。

LT 話してきました

Heroku Support についてと Aistein Vision についてのLT、そして私の Heroku HQ にいった話の3本立てだった。

Heroku Postgres は Heroku を使っている方ならほとんどが使うアドオンだろう。そこで気になるプランの使い分けや、Follower に関しての疑問に答えていただいたのでその知見だけサクッと共有した。 他にも Postgres の運用についてアドバイスをいただいたりしたんだけど、そこは Heroku とは直接関係ないので割愛(LTだし)。また機会があればそこのところについては記事にしようと思う。 とにかく SF 出張、刺激を受けて楽しかったっす。また来年も行けたらいきたい。

終わりに

今回の Heroku Strike はコンテンツ的にかなり注目な内容ばかりで面白かった。何より登壇いただいたお二人は私からのラブコールで実現したってのでとても嬉しかったし、期待通りの発表をしていただいた。そういうのもコミュニティをやっていると得られるものだと思うので、今後ともコミュニティ活動も積極的に関わっていきたい。