読者です 読者をやめる 読者になる 読者になる

ボクココ

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

キッチハイク は「つながり」だ

ども、@kimihom です。

個人的に仲良くしている キッチハイク さんが本を出したとのことで読んだ感想を書く。

キッチハイク! 突撃! 世界の晩ごはん

kitchhike

この本を通じて私が特に知りたかったのは、「なぜ料理を提供してくれる人は、見ず知らずの人に料理を提供するのか」という観点だった。本書を通じて、その答えがなんとなくわかった気がした。

人はつながりを求める

本書は様々な国に訪問して現地の食事を食べ回ったバイタリティあふれる著者による、人の出会いや生活をまとめた記録だ。波乱万丈の旅の記録を時に面白く綴られていた。

その中で、料理を提供した方のいくつかの言葉が私には印象に残った。

  • 「またいつでも食べに来ていいからね」
  • 「数日でも共に暮らすと家族のように思えるんだ。今では世界中に家族がいるようなものだ」

これらの言葉こそ、無償で料理を提供する方の根底の思いなのではないかと感じた。料理を提供する方々は旅する者に喜んでご飯を提供し、会話を通じて世界のことを知ったり自国のことを知ってもらったりする。それぞれの国の文化を知るためには、その国の料理を食べることが一番わかりやすい。だからこそ、世界中の家庭料理を食べ歩くこの旅は有意義になったのだと思った。そうして料理を提供する方は “つながり"を得ている。本書に書かれた各国の物語は読んでいて心温まるものだった。今の日本ではちょっと忘れかけているような温かい気持ちだ。

本書の最後に、著者も「食卓を囲む行為は、人がつながり、絆を深める行為」であると述べている。まさにこの考えこそがキッチハイクの根幹ではないかと感じた。実際、私もキッチハイクを何度か利用し、知らない人と食卓を囲む機会を体験した。食を通じた会話は男女関係なく楽しめるし、何より美味しい料理を通じた会話は温かい気持ちになる。人の交流と食の関係は、どんな時でも相性がいいものなのかもしれない。

さて、海外ではホストファミリー的な感じで色々な人を家に迎えて食事を振舞うことで “つながり” を得ている。では今の私たちはどうなのか。そのことについてちょっと考えてみた。

現代のつながり

“人と繋がっている” って感覚は幸福を得るための一つの手段だ。

んで、この点をうまく実現した Facebook というサービスがある。人とのつながりを明確に可視化して、何か投稿をすると いいね! をもらえる。いいね!をもらえた瞬間に、人と繋がっている擬似的な感覚を得ることができる。これ自体は日本だけでなく世界中で同様に Facebook によって繋がりを得ることができているというのがまず現代の一つ大きな特徴としてあるように思う。否 そもそも、インターネットそのものが “繋がる” を満たした総合体のようなものだ。Facebook だけでなく 2ch やオンラインゲームが流行りだして、別に外に出なくても人は繋がりを得ることができた。だからこそたくさんの人が家に篭り始めてしまったのだと私は思う。今後も発達したビデオ通話や音声通話によって会わなくても会ったという感覚、繋がりを得やすくなることだろう。そうしてインターネットが人とのつながりを"広めて"いる。しかし、インターネットは人とのつながりを"深める"ことができているのだろうか?

ここでつながりを深めるには"実際に一緒に何かを体験する"ことが重要になるのではないかという仮説が浮かび上がってくる。そしてその一つの手段として一緒に料理を食べるのは良い方法だ。それなりにお値段のする飲み屋がそこら中にはあるのはその証拠だ。より深い体験のために週末に BBQ をみんなでしたがるのも同様の理由だろう。

私は新たなつながりを深める方法の一つとして キッチハイク というサービスに注目しているし応援している。

キッチハイク社について思うこと

正直、私は最初はキッチハイク社については「流行りのシェアリングエコノミーの乗っかった企業の一つ」くらいにしか思っていなかった。実際、登場したタイミングもネット業界で Airbnb が流行りだした時期と重なるから、案外この分野の人々は同じようなことを思っている方が多いかもしれない。

しかし、実際に創業者の人と会ってサービスに対する思いを聞いた時、その思いは一変した。キッチハイクは、近年の企業で稀に見る “理念ベース” の企業だ。会社として実現したい未来があってその思いを社員全員が共有している。特に創業者の2人の思いの強さは尊敬に値するほどだ。本書を読めば、著者の思いの強さのベースとなった体験について理解することができるだろう。

終わりに

キッチハイクはつながりだ。これはあくまで私の感想に過ぎないけど、緩くなりがちだった現代の"つながり"をより強めるための一つの方法だと思う。今後、キッチハイクが Facebook 以上の人との深いつながりを実現するサービスになることを期待したい。

San Francisco 行ったレポ

ども、@kimihom です。

5/22 から1週間ほど、サンフランシスコに出張に行ってきた中で感じたことについてまとめてみる。オフィシャルな内容は会社のブログに書いてるので、そちらも参照いただけると嬉しい。

selfree ブログ

San Fransisco の SaaS 企業ブーム

数年前までは Google や Apple, Facebook といった企業がこぞって集まる “Silicon Valley” という地域に注目が集まっていた。これは San Fransisco よりも南の地域で Sunny Bale や San Jose, Mountain View, Palo Alto といった地域の呼称である。ちなみに San Fransisco の現地の店員に Silicon Valley っていっても通じなかった。テック企業で使われる単なる通称なので注意していただきたい。

今は San Francisco の中心街がアツいことになっていた。特に Market Street より南の地域があらゆる SaaS 企業が集まる密集地帯になっていたのだ。 Salesforce, Slack, Atlasian, Zendesk, Airbnb, Uber, Intercom, Mixpannel, Twilio といった、日頃私がお世話になっている企業が一同に同じエリアに構えていた。

f:id:cevid_cpp:20170523110231j:plainf:id:cevid_cpp:20170523134129j:plainf:id:cevid_cpp:20170523134416j:plain

莫大な出資を受けて、イケイケな企業はこのようなビルにオフィスを構えるようになってきている。SaaS 企業が “東京化” している。そして東京よりもっと密集した地帯で、一大 SaaS エコシステムがそこにはあった。

Heroku 訪問

このブログでもちょくちょく書いている Heroku オフィスに訪問した。Heroku も同じ San Francisco にある。

f:id:cevid_cpp:20170523115124j:plainf:id:cevid_cpp:20170523125219j:plainf:id:cevid_cpp:20170523130047j:plain

最後の写真にある一番でかい建設中のビルが、 Salesforce の新ビルだそうだ。さすが王者といったところ。Salesforce が Heroku を買い取った時には、今後 Heroku がどんどん複雑化していってしまうのではないかと心配したものだが、Salesforce は Heroku の文化を尊重してくれていて、自由な文化のままであった。むしろもっと自由になったのかもしれない。社員のほとんどはリモートワークでオフィスにいれば定期的に社食が出る。地下は完全にリフレッシュスペースとなっていて、中はとても開放的なオフィスだった。

今回は Heroku で長らくエンジニアをされている日本人の方とお話をして、色々と話を伺ってきた。Heroku のデータベースの込み入った内容になるのでこの記事では書かないが、データベースの運用に関して色々とアドバイスをいただいた。

今回学んだこと (テクノロジー以外)

今後 San Fransisco へ行く方の参考になるような情報を雑に列挙してみる。ちなみに今回、行き帰りの飛行機と宿泊が一人っていうチャレンジングな旅行だったので、色々と勉強になったし成長できた。

  • Expedia はマジ便利。飛行機 + 宿泊場所を一瞬で比較して予約できる。チェックインの手間などもほとんどなくなる。無理して Airbnb 使う必要はないと思う。
  • 空港で 海外 Wi-Fi レンタルサービスを利用しよう。海外の出先でも Wi-Fi 使えるようにすると安心レベルが違う。6,000円ほど払う価値はある。
  • 飛行機は必ず直行便を選ぼう。ちょっと安くなるからといって Los Angels 経由などにしてはいけない。無駄に4,5 時間長くなるし乗り換えも大変面倒。
  • 行きの飛行機の中でいかにたくさん寝れるかが時差ボケ防止の勝負。足が冷えて寝るのが難しいので、足を温められる何かがあるといいと思った
  • 飛行機にいれられる程度の大きさのトラックケースを持ったほうがいい。トラックケースを預けると空港で出てくるまで待つ手間があるし、トラックケースが出てこない(今回経験した)とかの超絶面倒なトラブルも防げる。
  • Lyft や Uber は SMS 受け取れる電話番号(090,080など)がないと利用ができない。スマホで 050 番号を使っている人は注意しよう。
  • もし鉄道を使う場合には BART の切符購入手順は確実に手こずるので事前に予習しておこう。クレカ支払いにした方が吉。
  • 現金はほとんど使わないので 1万円程度の両替でOK。他は全部クレカでいける
  • Fisherman’s Wharf のクラムチャウダーが美味しかったのでオススメ
  • めちゃ寒いのに地元の人は半袖とか普通にいる。風邪引くので暖かい服装を用意しよう

全体的には特に大きなトラブルがなかったのがよかった。今まで英語勉強の記事を書いてきたように英語勉強をマジで頑張ったので英語のコミュニケーションで困ることも一度もなかった。やはりツアーを利用しない海外旅行では確実にそれなりの英語レベルが必要なので、英語に自信がない人はツアーにした方がいい。慣れない人が一人でツアーなしで行くと何かしらトラブルは起きるw これは前回のニュージーランドで経験した。

今後の San Fransisco へ行く方の参考になれば幸いだ。

日本とシェアリングエコノミー

ども、@kimihom です。

度々どこかのスタートアップ関連の方々が「日本は規制のせいで Airbnb や Uber のような破壊的イノベーションを阻害されている」と不平不満を言うケースをみる。シェアリングエコノミーのサービスを作った経験のある私からの目線で考察する。

日本は改善を繰り返して課題を解決してきた

日本は良い国だ。何か問題が起これば、みんなで解決策を話し合ってより良いものに改善していく。この力は世界的にみても素晴らしいものがあると思う。その一つが「工事」だ。日本ではどこかしらで毎日工事が行われ、道路の整備やビルの建て替えなどひっきりなしに行われている。この工事がうるさく迷惑なものだと考えることもあるかもしれないが、その工事のおかげで日本は常に綺麗で整備された状態を保ち続けることができている。

改善の典型である「工事」のおかげで、日本のインフラはびっくりするほど整備されている。電気、水道、ガス。私は東京に住んでいてこれらで困ったことがほとんどない。それって本当にすごいことだ。

さて、交通に目を向けてみよう。いま、実際に私たちは交通に不便を感じているだろうか?東京にいればいつだって電車やバス、タクシーで好きなところへどこへでもいける。しかも安い。 日本の交通は素晴らしいのである。特にアメリカをみてみると、これらインフラが弱い部分がとても多いことがわかる。ちょっとどこか行きたくても電車は汚いし、タクシードライバーのマナーは悪いし、バスは治安が悪いしで一般的な交通インフラを使いたいと思わなくなるほど荒れてきている。だからこそ、一般人ドライバーが安心や清潔をウリにしてシェアリングエコノミーの Uber のようなサービスが人々に望まれて、生まれるべくして生まれた。つまり日本は破壊的イノベーションが起こそうとする前に、そもそもインフラが素晴らしく整っているので、人々が特別に何かを変えて欲しいと思っていない、現状に満足しているケースがほとんどなのだ。

ここまで書いておいてきっと一つ気づいた方がいると思うが、日本の満員電車問題だけは、マジで解決すべき課題だ。この課題に対するソリューションを提供したスタートアップはめちゃめちゃ大成功するポテンシャルがあると思う。電車以上に安くて正確な移動系アプリ。しかし東京は車の移動もコストが高いし渋滞するわで、最高のソリューションはまだ見つかっていない。考え方を変えてそもそも移動しないってのもあると思うけどね。同じような考え方で高齢化社会、地方過疎化、保育園問題などをうまく解決するシェアリングエコノミーは今後価値あるものとなるだろう。あとは日本の文化に根付いた何かをシェアするサービスも興味深い。

宿泊場所をシェアする文化が日本にそもそもない

海外では、 B&B(Bed and Breakfast) って言葉が昔からあるように、一泊朝食付きの比較的安価なペンションに泊まるって文化が定着していた。Airbnb はそれをインターネットサービスとして手軽に誰もが利用できるようにしたものだと考えている。今までは知り合いづてなどで気軽に提供していた人に対し、知らない人に対してもインターネット上のレビューを通じて信頼できそうな人にまで泊められる人の層を広げた、という意味合いが強い。

さて、そもそも B&B のような文化がなかった日本人が、いきなり Airbnb のようなサービスを使いたいと思うだろうか。他人を家に泊める文化がなかった日本人が、このような宿泊のシェアリングに抵抗を示す人が出てくるのは当然の話だと思う。今盛り上がっている一部の人は、外人向けに提供して小銭稼ぎの副業にするって意味合いが強すぎるように思う。

日本では必要なくても世界では求められる。その時私たちはどうすべきか?

シェアリング系のサービスって特に日本人の間だけではそこまで求められていない。それほどまでにそれぞれのインフラが発展しているのだ。

しかし、海外から日本にやってきた人に対しては、これらの理論は全く通じないのがキモだ。どこの国にでもある Uber や Airbnb の仕組みがなぜ日本にはない?と言われるようになる。そう肌で感じた一部の日本人は、日本の良き文化を無視して、先ほどの「日本の発展の遅さ」にフォーカスして文句を言うようになる。

インバウンドビジネス。私はぶっちゃけインバウンドビジネスはそこまで必要ないと考えている。「郷に入っては郷に従え」だ。日本で Uber がやってなかったら素直に発展した交通網を利用すればいいし、現金主義だったら現金で支払いをすればいい(クレカ流行らないのは多分 Edy や Suica がクレカの役割を果たしてるからってのが一理あると思う)。これを無理に「アメリカではこう言うサービスが常識なのに」みたいな理論ってちょっと違うんじゃないかと思う時がよくある。

日本でも同様の課題があったのなら、そのサービスは流行っているだろう。しかし流行らないってことは日本には素晴らしい代替手段があるのだ。

それでも世界共通にした何かがあれば、世界は便利な世の中にはなるだろう。でも、島国日本だからこそ、日本だけの特別ルール的な、そんなものがあっても面白いんじゃないかな。無理にグローバル化するのではなく、良いものは残し続ける。残すって選択が今後の日本の立ち位置をより高めるために逆に必要なことなんじゃないかなんてことを最近思う。

それは「文化を守る」という言葉に集約される。たくさんの文化を持つ日本は、Zen を初めとして世界から注目されている。この “文化” について、改めて考えてみるのも面白いのではないだろうか。

Hubspot CRM のファースト・インプレッション

ども、@kimihom です。

US ではメジャーな CRM となりつつある Hubspot CRM というプロダクトがある。今回はその CRM について色々調べたので、スタートアップ/ブートストラップ企業から見た CRM という感じでまとめてみる。

実は公式ブログでも良い記事が公開されているので、こちらも参考にしていただきたい。

blog.hubspot.jp

業界騒然の 完全無料 の CRM

他の Hubspot CRM の素敵な特徴が吹き飛ぶくらいの衝撃的な価格設定。なんと Hubspot CRM は無料で使える。しかもレコード数は 1,000,000 件まで保存可能ということで、小規模の事業なら全く問題ない数値だ。

“無料っていうと、どうせほとんど使えないんでしょ?” と私も最初はそう思っていたが、そうではない。しかも私が理想としている CRM の条件をほとんど満たす有料でも使いたいくらいの機能を持つ素晴らしいプロダクトだった。

程よい制約と柔軟性

CRM っていう分野はとても面白くて、企業によって保存したい顧客情報ってちょっとずつ違っていて、その違いをどうやって企業毎に最適化していくのかみたいな問題が存在する。

私たちは従来から、Excel や SpreadSheet といった表計算ソフトでこれらの顧客情報を管理してきていた。これらは最高の柔軟性を持っているため、自分たちにとって理想の顧客シートを誰でも作れるという意味で画期的だった。しかし、ほとんどすべてを手動入力する必要があったり、マクロと呼ばれる自動化を使うとどんどんメンテナンス困難なグチャグチャで高機能なシートになるかという運命を辿っていた。つまり、これら表計算ソフトは、データの量が多くなると、その時点で破綻するものなのだ。

ってことで CRM ツールってのが世の中に出回っているわけだけども、表計算ソフトの持つ柔軟性を保ちつつ、どうやって企業毎に最適なソフトウェアを提供するのかというのは長らく問題とされてきていた。

Hubspot CRM の良さは、程よい制約と柔軟性にある。Hubspot CRM はデフォルトで顧客や取引先、活動などの最低限の項目だけが用意されている。その顧客には名前や電話番号、住所などがあるが、デフォルトで表示する項目も極小数に限られている。私たちは表示させたい必要な項目だけを選択し、顧客情報として表示するようにすれば良い。必要なデータだけを必要な時に見る。これこそがまず大事なポイントである。ちゃんと “取引先には複数の顧客がいて、顧客には複数の活動がある” といった関連がデフォルトで定義されているので、完全にゼロから作る自由なクラウドサービスや表計算ソフトでは実現困難なことも Hubspot CRM では実現できているのである。

そんな事前に用意された項目の他に、HubspotCRM は顧客や取引先などに好きな項目を追加することができる柔軟性がある。これによって自社に最適な CRM を構築することが可能になる。このカスタマイズ項目は、他の CRM でもあるにはあるんだけど、確実に有料になる機能のはずな機能だ。これを Hubspot CRM は無料にしている。

当然ながら API も用意

CRM で API はあって当然の時代なので言及するつもりもあまりないが、すべて API で操作可能になっている。

API をうまく使うことで、顧客の登録や更新、行動の登録など可能な限り自動化することが可能になる。また、API を使って他に使っているクラウドサービスとの連携も実現できるようになる。

このようなカスタマイズ性の高い CRM の場合、 API は結構複雑になるのでその扱いは注意する必要がある。たまに設計が不親切すぎる古臭い API があったりするけど、 Hubspot CRM はモダンな設計となっている。詳細は API ドキュメントをご覧いただきたい。

CRM の使いどころ

CRM って初めて見たときはこんなの何に使うの? って思われる方も多いかもしれないが、改めて CRM の重要性を記そう。

CRM は顧客情報の蓄積と共有に最大のメリットがある。顧客が増えていくと当然私たちは顧客の情報を忘れていったり、新人が入ってきたりして情報がバラバラになっていくことが多いにある。そんな時にしっかりと顧客情報を蓄積していけば、どんな顧客に対して今メールや電話で接しているのかをすぐに把握することができる。こうして初めて話すお客さんと常連のお客さんとで区別した、適切な対応を実現することが可能になる。この違いがわかってこそ、適切なコミュニケーションを実現することができるのだ。また、部署をまたいで情報共有できる点も重要だ。セールスで獲得して入力した顧客は、その後契約することで取引先となる。正しく顧客管理をしていれば、セールスとその後のサポートの流れをスムーズにすることができ、正しい顧客対応を実現することができるのである。

顧客のあらゆる情報が蓄積されるという意味で、しっかりとした CRM を使うことは大事だと思う。サポートツールや営業管理などで提供されている “簡易 CRM” 機能があるけど、その後の拡張性や連携のしやすさが無いので、重要な情報をそこで保存することができないという致命的な問題を抱えることになりかねない。

終わりに

CRM として私の理想に叶うものだった Hubspot CRM。ぜひ皆さんも 無料で 顧客管理を初めてみてはいかがだろうか。

ログベースのメトリクスサービスの魅力 (Heroku ユーザー向け)

ども、@kimihom です。

今回はログベースでの解析に関して調べたことをまとめてみる。Heroku に関連する範囲で調べたので、 Heroku ユーザーには最適かと思う。

ログベースのサービス

例えば、メトリクスサービスで有名な以下のようなサービスは、既にメトリクス内容が決まっている場合にのみ有効に活用できる。

  • Google Analytics などの JavaScript 埋め込み型ツール
  • NewRelic などのサーバー埋め込み型のモニタリングツール

上記の提供するコードをアプリケーションに埋め込むことで、何もしなくても必要な情報をそれなりに収集してくれるようになる。しかし、メトリクスサービスの提供する範囲までしか収集することができないので、例えば独自の項目(サインアップ回数や金額など)を集計したいって時にはまた他のサービスを探すか、手動でデータベースにアクセスしてエクセルを更新するかなどの対策をするしかなくなる。

メトリクス集計の柔軟性を実現ために、アプリケーション内で情報を送信する方法を取ることもできなくはない。Keen.io は色々なメトリクス数値をアプリケーション内から送信し、 Keen.io内で集計してメトリクス分析が可能になる。ただこの方法ではアプリケーションのレスポンス速度に影響が出てしまうのが難点だ。それを解決するためにはメトリクスを送信する部分はバックグランドジョブに任せるという方法になるが、それ専用のプロセスを立ち上げなければならなかったりする。Heroku ユーザーならご存知の通り、他の Dyno を立ち上げなければならなくなる。

そんな時こそログメトリクスサービスの出番だ。ログベースであれば、そのようなアプリケーション側の負荷や追加実装をほとんど気にする必要がなくなる。やることは、集計したいメトリクス情報をログに書き出すだけだ。

ログはどんなサーバーにもどんどん蓄積されていく。ログ情報は宝の山だ。ユーザーがいつどんな行動をしたのかが事細かに記されているし、どんなエラーが起きたのか。サーバーはどんな状態なのかが記されている。それ以外にも好きなタイミングで好きな内容をログに書き出すことができる。

Heroku のログベースのメトリクスアドオン

ログのアドオンといえば Papertrail と前回の記事 で紹介したけど、 Papertrail は大事なログが出た時に"通知"する仕組みは提供しているけども"集計"する仕組みは提供していない。てことで今回のログベースのメトリクスサービスとしては適切ではない。

ログベースのメトリクス視点で Heroku アドオンを調べてみると、いくつか候補があったのでご紹介する。

  1. Librato

Librato - Add-ons - Heroku Elements

おそらくこれがファーストチョイスになるかと思う。Librato はデフォルトでも Heroku のログから得られるメトリクス情報を集計し、表示してくれる。 個人的に考える Librato の最大の魅力は、カスタムメトリクスだ。Librato の提供する Gem 経由でログを吐き出すと、最終的に Librato の集計データとしてログを書き出してくれる。私たちがしなければならないのは、メトリクスに必要な数値をログに書き出すだけだ。それだけなら何もサーバーに負荷がかからない。

カスタムメトリクスは有料プランでないと使えないけども、有料で払ってでも使う価値はあるだろう。その集計したデータは自由にグラフ化することができるので、サーバー監視だけでなくビジネスに有用なデータとしてもグラフ化することが可能だ。

メトリクス集計に開発時間を取れて、グラフ描画など時間をかけてこだわりたいって人には最適な Heroku アドオンだと思う。

  1. Hosted Graphite

Hosted Graphite - Add-ons - Heroku Elements

もっとシンプルなのがいいよ!という方はよりシンプルな Hosted Graphite を検討するのもいいだろう。 Hosted Graphite はAPI キー:属性 値 のフォーマットを Heroku Log に出力するだけで、グラフ化してくれるアドオンだ。

しかも割と柔軟にグラフ描画できるっぽいので、試してみる価値はあると思う。

終わりに

今回は Heroku のログ集計についての考察を記事にまとめた。

もし Heroku を使っていなければ、サーバーのログ転送の仕組みから構築してさらにそのデータをどこかに投げる処理を実現しなければならないが、Heroku ならアドオンで一発だ。Dyno がいくつ増えても関係なしだ。

サーバー構築の手間だけではなく、ログの集計も使いこなすことで Heroku をより効果的に使いこなせることになるだろう。もし上記のようなアドオンを使ってみた方がいれば、ぜひブログ等で書いていただけたらと思う。そうして Heroku で本番運用して活用する事例がもっと増えていって欲しい。

プロフェッショナルのための 実践Heroku入門 プラットフォーム・クラウドを活用したアプリケーション開発と運用 (書籍)

プロフェッショナルのための 実践Heroku入門 プラットフォーム・クラウドを活用したアプリケーション開発と運用 (書籍)

サイトサーチアナリティクス  アクセス解析とUXによるウェブサイトの分析・改善手法

サイトサーチアナリティクス アクセス解析とUXによるウェブサイトの分析・改善手法

今からでも欲しい SaaS 領域3選

ども、@kimihom です。

今回は割と思い切ったテーマで記事を書いてみる。日本のスタートアップ/ブートストラップ界隈でどんどん SaaS が出てきて欲しいと思う。今回はそのタネとなりそうなアイディアをご紹介する。

大前提

まず、従来の BtoB 向けのサービスってのはだいたい以下のような特徴がある。

  • ごちゃごちゃして使いづらい
  • 機能多すぎ
  • API がない or 圧倒的に不親切
  • 連携できるサービスが少ない

そこで、プログラミング能力がある方は、以下の3つの領域にチャレンジしてみてはいかがだろうか。

当然ながら、これでそのまま読者の方が始めてみて、「この通りにやったけどうまくいかなかったじゃねーか」という時の責任は負えないのでご注意いただきたい。それは作った人の能力や運によっても大きく左右されるものである。

1. シンプルで柔軟な顧客管理 SaaS

俗にいう CRM と呼ばれるこの分野は、SaaS の中でも圧倒的にニーズのある分野だと思う。ビジネスをやれば、誰だって"顧客" を抱えるはずで、その顧客をしっかりと管理して部署間の情報共有や次なる顧客毎のアプローチ、マーケティングに力を注ぐことができる。

事実、CRM の部類は既にレッドオーシャンだと考える方も多いかもしれない。それだけ競合が多くいることをあらかじめ認識しておいて欲しい。それでも私が1番最初にこの分野を挙げるのには理由がある。

  • シンプルな CRM SaaS はあるけど、柔軟性がなかったり、専門性を要する場合が多い
  • 国内で CRM を今後必要とする顧客がまだまだいるはず
  • API が複雑、連携が困難

個人的にこの業界はちょいちょいチェックしているのだけども、イメージに一番近いのは、Hubspot だ。このサービスはとても良いサービスだと思っているけど、US 発なだけあって当然のことながら日本向けに最適化されたサービスではない。より良い CRM SaaS を目指す上で、以下のような機能を検討すると良いと思う。

  • 項目のカスタマイズ (リードや取引先等のデフォルト項目はあるが、属性は自由に消せるし追加できる)
  • シンプルな検索
  • データに基づく統計分析
  • API による拡張
  • 多くの SaaS サービスとの連携

顧客にメールを送りたいんだったらメールサービスと連携すれば良いし、購買履歴を知りたければ課金サービスと連携すれば良い。このように連携のしやすさを重視した CRM サービスってのは他の SaaS サービス提供者的にはぜひ出てきて欲しいと思っている分野だったりする。

顧客管理の市場を調べてみて、需要の大きい分野 (例えば EC) に特化した CRM も興味深い。

Hubspot に日本の法律や業界を絡めて日本に最適化された、API フレンドリーな CRM SaaS が1つ目の提案。

2. よりシンプルなサポートツール

2つ目にあげたいのがカスタマーサポートツール。顧客とのメール対応をいちいち何かのグループメールで管理するのではなく、チケットや担当者を適切に分けて効果的にサポートを提供するツールは今後も需要がある。

そして今後はメールサポートに留まらなくなるのが確実視されているのがこの分野の面白いところ。今の人たちはメールアドレスを持ってすらいないケースがある。では何でコミュニケーションをとっているのかといえば、 SNS や メッセージングアプリだ。これらの分野に向けたサポートツールを提供すれば、その時代にあったサポートツールとして世間に受け入れられることだろう。

究極を言えば、メール/電話/チャット/SNS/ヘルプセンター といった全てを統合したカスタマーサポートを目指す的な流れもあるにはあるけど、そこはもう Zendesk などがかなり持ってるので、何かに特化した方が逆に面白いと思う。

私のオススメは LINE や Facebook, Twitter, Snow といった流行りのメッセージングアプリのサポートチャネルに特化したサービス。特に大量の若年層の顧客を持つ BtoC ビジネスに受け入れられることだろう。これまた LINE とかを入れようとすると、途端に US のスタートアップは手をつけられない分野だから、LINE との連携は必須になるだろう。

  • 各種 SNS との密な連携
  • 同一顧客で別SNSアカウントを一緒に管理できる簡易CRM
  • 今までのメッセージ履歴を一元管理できる UI
  • 指定した顧客のグループに一括送信できるマーケティングメッセージ
  • API による外部サービスとの連携

3. より柔軟な顧客トラッキングサービス

Web サイトやアプリ上で顧客がどんな行動をしたのかを管理するサービスは CRM 市場についで熱い分野だ。 Google Analytics を筆頭に、ビジネス向けだったりアプリ向けだったりが色々と登場してきている。

それでもまだ今から作っても上手くいくと思う理由としては、以下のような背景がある。

  • ビッグデータ/ ディープラーニング といった分野はまだまだ新しい領域で、専門知識を有する人が圧倒的に少ない
  • 個別の顧客の属性や、個別でどのように行動したのかを管理できるものが少ない
  • 顧客の行動に応じた何かしらのアクションを定義したりしたい
  • A/B テストの実施

今後、顧客の分析でビッグデータから得られる洞察を元に、プロダクト改善が行われることになる。一部の顧客が “ここが使いづらい” という意見だけを鵜呑みにするのではなく、ビッグデータから “顧客の 80% はここの操作でつまずいている” というデータを元にプロダクトを改善するのが当たり前になる時代がやってくるだろう(実際やってきている)。

その時代を先駆けて、最先端技術を駆使したトラッキングサービスが出てくれば、日本どころか世界を相手にしたサービスってのが日本からも生まれるのではないか。

この分野で日本向けにフォーカスするってのは難しいけど、何かアイディアがあればそれを埋め込むのもいいかもしれない。

終わりに

以上、今からでも欲しい SaaS 領域をご紹介した。個人的に、上記のような条件を満たしたサービスが出れば興味が湧くし、試しに使ってみたい。

いうまでもないと思うけど、長期的にビジネスに挑戦するなら、"なぜあなたがそのビジネスをやるのか"という思想が必要だ。ただ単に成功しそうだからという理由だけでビジネスを始めてしまうと、1年ちょっとやってみてダメだったらやめるみたいな中途半端な終わりを迎えることしかない。

今回紹介した3領域はあくまで仮説に過ぎないけど、このような視点で何か自分の実現したいサービスがないか、考えてみるのも面白いと思う。

追記: US のサービスとの差別化に関して

上記3つのアイディアで、日本向けに最適化した機能を埋め込むことを割と強調している。 これはアメリカがこの分野において何年も先にいるというのが理由だ。私たちが今話題になり始めたようなサービスは、すでにアメリカでは当然のように使われているくらい普及しているものであるパターンがほとんどだ。日本は3年は遅れているという印象を持っている。

SaaS で “世界中” で大ヒットさせたいようなものを作るんだったら、アメリカに行く以外方法はないと思う。なぜなら、アメリカではその先端サービスを使って顧客から生まれた次のニーズをさらにサービスとして作り出すエコシステムが既にできあがっているからだ。次にやってくるようなニーズがそもそも存在しない状態の日本で、その先のソリューションなんて当然作れないだろう? 例えば Amazon Echo がそもそも日本国内で普及していない状態で、どうやってあの素晴らしい音声デバイスをベースにしたサービスを作ることができようか。 SaaS で日本発世界がほとんど生まれないのは、このような一般顧客の先端技術の未浸透が大きな原因の一つだと思う。開発する私たち以外にも、使う顧客自身が最先端を行っていないと、世界に先駆けたサービスを作って成功させることは困難だ。これは日本の IE や iPhone の普及率の高さ、シェアリング文化の未定着、現金主義などが重なって進歩をより遅くさせている。

今回出したアイディアは、今から日本国内で作り始めても海外サービスとの差別化で顧客を得ることのできるであろう領域に限定している。これが例えば投資家にとっては夢がないと言われればその通りだと思う。 しかしそれが現実だ。現在日本で成功している サービスのほとんどは、アメリカにも似たようなものが既にあってそれを参考にしたりしている。テクノロジーもそれに伴ってアメリカで生まれたのを使うってパターンがほとんどになっている。

SaaS そのものが日本で盛り上がっていかない限り、その先もないだろう。色々なサービスが起業家から出てきてくることが最初の一歩だと考えている。

Heroku x Rails のサービスを本番運用する際に確認したいこと

ども、@kimihom です。

私は Heroku に Rails サーバーを立ててサービスを運用している。これまでの経験を元に、定期的にチェックしておきたい指標とか項目をまとめてみる。今後のサービス開発などで参考になれば幸いだ。

サービス構成

現在の構成はというと、以下のような感じである。

  • Ruby 2.4.1 (執筆時点で最新)
  • Ruby on Rails 4.2.8
  • Heroku Standard 1X Dyno * 4
  • Heroku Postgres Standard 0
  • Heroku Redis Premium 0

もちろん他にも使っているのはいろいろあるけど、ベースは上記のように至って標準な作りになっている。これによってインフラ周りでトラブルが起きることを最小限にとどめている。今現在でもインフラ周りで特別に問題になっていることはないので、これからも 上記の構成を使い続けていく予定だ。

では上記のような環境の中で確認したいことについてまとめてみる。

Heroku のメモリの項目をチェック

まずはサービスがメモリを使い過ぎていないかを定期的にチェックしよう。Professional Dyno にすれば、Heroku 内で “Meterics” の項目が見られるようになる。

f:id:cevid_cpp:20170505214402p:plain

ここでたまに線がガクッと下がっているのは Heroku が1日1回、自動で再起動されるためだ。この時にメモリは一旦リフレッシュされ、ちょくちょく溜まってたメモリを落としてくれる。この1日一回の再起動があるから、 Dyno を 2つ以上に保っておかないと、その一瞬はユーザーがアクセスできない時間ができてしまう。常にアクセスできるようにするために、そして 1つ Dyno が落ちても問題ないように、基本的に本番環境では Standard Dyno を2つ 常時起動にしておいた方がいいだろう。

さて、この図の上限の 100% を超えてしまうと、スワップ領域(上図中の下部紫エリア)にメモリを退避するようになり、めちゃめちゃレスポンス速度が遅くなるのでサービスのパフォーマンスに深刻な影響を及ぼすことになる。てことで メモリが 100% を超えないか、定期的にチェックしておく必要がある。ちなみに 100% を超えると、 Heroku のログに大量の R14 ログが吐き出される。

じゃあどうやってそのメモリを低く保てばいいのかってのが、Heroku のブログで丁寧にまとめられているので、これは必ず一読しておこう。ちなみに色々やって一番効果的なのは、定期的な Ruby のアップデート だった。

devcenter.heroku.com

上記の記事を元に記事を書いたこともあるので、上記ページの英語が嫌いな人は見てみるといいかもしれない。

www.bokukoko.info

Heroku のスループットとレスポンスタイムをチェック

同じく Heroku の Metrics でスループットとレスポンスタイムをチェックしよう。

これは例えば、あなたの運営するサービスが “夕方の15時にピークタイムを迎える” などの傾向を把握する上で必要になる。ピークタイムで例えば秒間50アクセスとか来ると、同時に全てのアクセスを処理できないのでリクエストの一部は待たされることになる。当然そうなると Metrics のレスポンスタイムがその時間に上昇するので、これは何か対策せんといかんな、という具合に管理することが可能だ。

ほとんどの場合、これは Dyno を増やすことで対応が可能だ。ただ、ずっと Dyno を増やしっぱなしにするのはお金が勿体無い。深夜帯なんてほとんどアクセスがこない場合がほとんどだと思う。そんな時は Process Scheduler などのアドオンを利用しよう。ピーク帯のアクセスはほとんど決まっていて、その時間に Dyno を増やせばいいと大体把握している場合は Process Scheduler は便利だ。これが例えばピーク帯が予想できないようなサービスの場合は、Adapt Scale などのアドオンを検討することになるだろう。

Rails のメトリクスは Scout がオススメ

Rails アプリ側のメトリクスツールは、 先ほどの Heroku ブログにも紹介されている Scout がオススメだ。NewRelic よりも軽く、より Rails に特化して表示してくれる。

どのリクエストに平均どのくらいのレスポンス時間がかかっているのかを簡単にチェックすることができる。どこから改善していけばいいのかがすぐにわかるので、Rails アプリを本番運用する際にはメトリクスツールは必須になる。

Heroku の メモリのチャートを眺めていると、たまにヒョンっとメモリが急上昇することがある。これは Rails アプリでたまに生じる Memory Broat と呼ばれるもので、特定のコードが無駄な処理(例えば N+1 のクエリ) を実行することで処理に多くの時間を費やしてメモリが急上昇するものだ。この場合は Rails のソースコードを修正する必要がある。その具体的な方法は、Scout のブログを参照していただきたい。もしくは先ほど紹介した “Heroku on Rails アプリのメモリ増加対策の方法” にもちょろっと紹介してある。

Scout のフリープランは割とすぐにリミット行っちゃってすぐアップグレードしろってメールくるのでそこは注意。

Heroku Postgres や Redis もたまにはチェック

基本的に Scout のメトリクスで DB 周りの大体のことも把握できるのだけども、それ以外でチェックしないといけないこともある。

特に Heroku Postgres はプランによって色々と制限があるので、その制限を超えていないかを定期的にチェックしないといけない。

Heroku Postgres の Standard-0 の場合、コネクション数の上限は 120 だ(これを超えるってことはほとんどないとは思うが)。また、ストレージの上限は 64GB である。まぁ Standard-0 にアップグレードすればほとんどのサービスでは当分困ることはないとは思うが、予期せぬ事態に陥らないように、定期的に Heroku Postgres のページにもアクセスするようにしたいところだ。

Heroku Postgres のページでも遅いクエリを発行しているものが何なのかを教えてくれたりするので、 Scout の結果と合わせてどれを直さないといけないのかを確認するようにしよう。

Heroku Redis も有料プランにあげればほとんどの場合問題になることはないとは思うが、定期的にメモリや接続数を使い過ぎていないか等を見に行くようにしよう。 Redis の初期設定はちょっと注意が必要なので以前書いた記事を紹介しておく。

www.bokukoko.info

最後は安定の Papertrail

もはや Heroku を使っている方にとってはスタンダードとなりつつある Papertrail

Papertrail のアラート機能を使って、エラーが起きたら迅速に Slack 等に通知する仕組みを用意しておこう。例えば Papertrail の検索条件を "Error" AND -"RoutingError" で保存し、アラートで “Error” の検索がヒットした時に Slack に飛ばすようにしよう。

これでアプリケーションレベルのエラーをすぐに検知することが可能だ。

それ以外にもアプリケーションログで重要なイベントは何でも通知できるようにしておくと、ユーザーの動向に基づいた素早い行動ができるようになるのでじゃんじゃんセットしておくといい。これはお金を払ってでも使っていきたいサービスだ。

終わりに

以上が私が Heroku を本番運用している中で定期的にチェックしている項目だ。一部は以前紹介したことのある Tips ではあるが、改めて全体をまとめとして紹介した。

Rails のレールと Heroku のレールに乗れば、Web サービスを極少人数で運用できる体制が実現できる。

最後に Heroku に興味を持った方は、ぜひ Japan Heroku User Group にジョイン!