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

ボクココ

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

Web サービス開発に必要な技能について

ども、@kimihom です。

先日とある雑誌の記者さんから取材を受けて、自分のスキルについて色々と聞かれた。私自身は何かに特化したスペシャリストというよりも、あらゆることが一人でできるジェネラリストの部類である。前回の記事では web サービスのアイディアについて必要なことを書いたが、今回はそのアイディアを実現するためのジェネラリストとして必要な技能について紹介する。

www.bokukoko.info

俗にいう"有名エンジニア"の方々は何かの技術に特化したスペシャリストである場合が多いので下記の事項には当てはまらない。あくまでこれは1人のエンジニアとしての参考情報にすぎないことに注意していただきたい。

一人でサービスを作りきる能力を磨く

何かに特化したスペシャリストの人が、 CSS でデザインを整えたりすることとサーバーの負荷監視などをすることを同時に行うことは困難だ。だけども、ジェネラリストの場合はそのような技術の好き嫌いを無くし、全てできるようになる必要がある。

ただその中でやる必要のないことに時間を費やすような無駄なことをしてはならない。大抵のインフラ技術ってのは Heroku などの PaaS を使うことで共通化できるし、CSS もフレームワークに載せることで必要な実装を最小限に止めることができる。このようにオープンソースコミュニティやベンダーの力を借りながらも、自分の理想のサービスを最短で高品質なものにしていく力が求められる。

ちょっとでもオープンソース界隈の世界に足を踏み入れたなら、その技術にコントリビュート、つまりプルリクエストを通じてコードを改善していくほどの力を持つエンジニアこそ正義だと思われるかもしれない。しかしそんなこともなくてちゃんとそのオープンソースを使って、人々に価値を提供できるようなサービスを開発し、それによってそのオープンソースがより盛り上がって行けばそれでも十分すぎる貢献になるのである。

私はそう割り切って、いかに良いオープンソースを探し出して利用し、良い形で顧客に提供できるかに力を注ぐようにしている。

つまり求められるのは「正しいソフトウェアやミドルウェアを選別し利用する」ことである。言い換えれば、世に出回っている様々なAPI やプラットフォームのドキュメントを正しく読み解き、理解して使えるようになる力が求められる。組み合わせ・マッシュアップの世界に近いものがある。

その中でも特に一番大事な顧客の見える部分、つまり機能開発をより効果的に開発できるようになる技術を選ばなければならない。つまり、AWS で IaaS から構築し、yum や apt-get でソフトウェアをインストールするような時間をできる限り無くし、PaaS や その他 API サービスを効果的に活用するような道を模索しなければならない。

この記事では具体的にどんな勉強をすべきでどんなことができるようになるべきかの具体的な行動については示さない。それはご自身の興味関心に応じて変わることだし、その自分から学んでいくスタイルを身につけなければジェネラリストとしてのエンジニアを目指すべきではないからだ。自分の作りたいものを実現する上で何が必要かを正しく調べて結論を出せるように訓練していこう。

経験を積んで良いサービスとは何かについて自分なりの結論を出す

最初に作った自分のプロダクトってのは大抵は酷いモノである。大抵は誰にも使われないか 一部の友達にだけ使われてサービスは終了する運命にある。

だが、その次に作るプロダクトはその前のプロダクトより確実に良いものになっているはずだ。以前作ったプロダクト開発の反省を踏まえて、より良いデザインや機能について自分なりの哲学のようなものが次第に出来上がってくる。こうして意思のあるプロダクトを作り上げることができるようになり、やがて使ってくれるユーザーがいるアプリやサービスを開発することができるようになる。

自分で作るだけでなく、他の素晴らしいサービスを触って実感することも大切だ。色々な人に使われているサービスを実際に触ってみることで、「こういう機能やデザインは良いな」と思った部分を自分のサービスに反映していくことができる。

その学習を通して色々なサービスを何回も作ってはクローズするような段階の果てに理想のサービス開発を実現することができるようになる。その継続したサービス開発がより次なる高みへ連れて行ってくれる。

その中でも光る技術を持つ

今までの話とはちょっと矛盾するんだけど、ジェネラリストの中でもスペシャリストの要素を持つ必要が出てくる。つまり、「ある程度の技術は60点だけど、この技術は95点である」という状態が理想だ。

なぜならば、全て60点の場合は他の誰でも作れるサービスしか作れなくなってしまうからだ。それでもアイディア次第では人々に役立つものが作れるかもしれない。ただしあまり新規性を感じることができないサービスであるため、うまくマーケティングを通じて成功させるしか方法がなくなってしまう。

エンジニアであれば技術で差をつけたいと思うはずだ。だからこそある程度のことは一人でできるけど、それでもこの技術には絶対の自信があるという何かを磨き続けていこう。その技術に関しては常に Github の Issue を監視していたり、ドキュメントを購読して最新情報を得るようにしたりするような活動が必要になってくる。それこそがエンジニアとして違いを生むサービスを実現することのできるようになる秘訣だ。

終わりに

このようなエンジニアはスタートアップや新規事業部門などゼロからサービスを作っていくところでは重宝される。エンジニアでも色々な種類があるので自分のなりたい理想像について考えた上で行動していかなければならない。

私としては一人でサービス開発ができるエンジニアが増えていけば、よりシンプルで使いやすいサービスが日本でも増えていくと思っている。そんなサービスを日頃から使っていく日が、つまりはあなたが作ったサービスを使っていく日が来るのを心待ちにしている。

Web サービスのアイディアの気づき方

ども、@kimihom in 熱海 です。

久々の更新になってしまった。最近は空き時間はブログの執筆よりも Netflix で英語学習に時間を割いている。1ヶ月無料で英語の映画やドラマをたくさん見ることができるので、英語リスニングの勉強にオススメ。

さて本題に入ろう。 これから何か Web サービスを作ろうと思っている方にとって、アイディアはどのように見つけてチャレンジしていけばいいのだろうか。そこには様々な方法があるけど、私なりに良いなと思っている方法についていくつかご紹介する。

アイディアに固執しない

まず大事な前提から書いていく。最初のアイディアに固執しすぎてはいけない。よくある失敗例として、最初に思いついたアイディアで絶対成功させる!と気合を入れすぎて、そのサービスが世の中に必要とされないままサービスをクローズしてしまうパターンがある。これは、例えば Web サービスのアイディアを上司に承認を通し、それでやっていかなければならない的な大企業的スタイルでよく見られる。サービスの内容を柔軟に変えていけないため、顧客のニーズに対応できないままサービスの改善を続けてしまって失敗するのである。あくまで最初のアイディアってのは"仮説"にすぎないことを肝に銘じよう。最初のアイディアを必要最低限の機能を持つサービスとして作り上げ、見込み顧客に使ってみてもらう検証が必要となる。

見込み顧客を見誤ると、それもまたうまくいかない。最初の仮説に合った理想の顧客を見つけるのは、なかなか難しいし長い時間を取ってくれるとも限らない。ではどうすれば見込み顧客を見つけ、正しい仮説と検証を続けていけば良いのかというのが今回のメインテーマ。

“あなた” の不便を解消しよう

見込み顧客を"あなた"として設定してみよう。普段の生活や仕事の中で不便に感じていることや無駄に感じていることを気づく必要がある。しょっちゅう感じる不便は、あなたがお金を払ってでも解決したい課題であるはずだ。例えば普段の生活の中で何かを探すのに時間がかかりすぎていないか?何かを管理するのに時間がかかりすぎていないか?仕事の中で酷いエクセルで管理している何かがないか?

まずはあなたの課題を解決するために作れば、自分だけでも使えるサービスになることだろう。たとえ他の人が使わなくても、自分だけ便利になればそれでも良いではないか。でも大抵はあなたが感じた課題は、あなただけの課題ではない。結果として自分が便利になるサービスは、その他多数の方にとっても便利なサービスになるはずなのである。

“あなたの” 諦めたことを思い出そう

何かをしたいと思った時に、複雑すぎてやるのを諦めてしまったり、欲しいんだけどなくてもいいから諦めたことなどないだろうか?これもアイディアの気づき方として有効な方法だ。

その複雑さをシンプルにして誰でも使えるようなサービスを作れば、あなただけでなく他の方も確実に欲しいと思うサービスに作り上げることができる。この考え方も、例え他の顧客が使わなかったとしても、あなた自身が諦めたことをできるようになったのだから、作った甲斐があるってものだ。ただ、繰り返しになるけどあなた自身の諦めたことは、きっと他のどこかの顧客も諦めたはずである。だからそういう意識で生まれたサービスは成功する可能性が高い。

こういうのは、大抵 “他の誰かが作ってくれないかなー” という他人任せな考えが生まれてくることが多い。なぜなら作るのに時間がかかりそうだし、作るのが難しそうに思えたりするものだからである。それこそがチャンスだ。他の人も同じように考えているため、誰も作ったことがなかったりチャレンジできない領域だったりするのである。それが一つの参入障壁となり、あなたのサービスをより成功させるための秘訣となる。

あなたが思いついたアイディアで、"これはいける” レベルのサービスってのは、他の人も同じように思って競合がどんどん生まれてくる運命にある。だから、"他の誰かが作ってくれないかなー" レベルのサービスの方がうまくいく可能性が高いと思う。きっとあなたにもそんなサービスが見つかるはずだ。

空き時間でやってみる

空き時間で Webサービスを作り始めてみよう。

毎晩とか毎週末などの時間を使っていくことになるだろう。これは確かに集中が途切れて続きにくい性質がある。そこをなんとか最初の必要最低限の機能だけのシンプルなプロダクトを作ってみるところまで頑張ってみよう。

そうすることで、研ぎ澄まされた Web サービスを作ることができる。余計な機能に無駄に時間を費やさなくなる。そして思い切ったチャレンジをすることができる。実は空き時間で作ってみたサービスってのは良いサービスになりやすい。

一人でもくもくとやっていけば良いと思う。複数人でやっていくと、他の人が全然開発に加わってくれなかったり、他の興味に移ってしまうことが多発する。そんな面倒なことになるくらいなら、あなた一人でやっていった方が気楽に理想を実現することができる。

終わりに

私は今まで色々なサービスを作ってきたが、最近流行りのサービスを作りたい! というモチベーションで作ったアプリより、自分の不便を解決するサービスはうまくいく可能性が高かった。これはきっとモチベーションの継続や同じことを思う顧客を見つけやすいなどの特徴があるからだと思う。

誰でも Web サービスを作って公開できる時代になった。何かを作り始めるのなら、"今" がベストタイミングだ! 今日から始めてみよう。

海外からの競合の参入はピンチなのか

ども、@kimihom です。

Web サービスを運営していると、例えば海外で似たサービスが日本語対応して参入して来たりすることがある。とりわけインターネットの世界はこれが顕著で、ユーザーにとってより便利なサービスであれば、海外産でも国産でもそこまで変わらない気持ちで利用することができる。実際、私たちが使っているサービスのほとんどは海外で生まれて日本に持ち込まれたものである。

さて、そうなると海外から類似サービスがやってきた時には基本的にはピンチになる。ちゃんとアンテナを張っておかないとそのうち競争に負けてしまうことを恐れる。

だが本当にそれは恐るべきことなのか。真っ向勝負で戦っていかないといけないのか。今回はそんなテーマについて考えてみたい。

とりわけビジネスにおいて全員が使うサービスは存在しない

ビジネス、つまり BtoB において全員が使う Web サービスは今も存在しないし、今後も確実に出てこない。シェア No1 とかの順位づけは出てくるかもしれないけど、その会社が BtoB において全市場を独占するっていうことは事実上不可能だ。

なんでかというと、すべてのユーザーがすべて同じニーズであるとは限らないからだ。ある企業にとっては独自にカスタマイズして使いやすくしたいという柔軟性を求める場合もあるだろうし、ある企業にとっては機能は少なくても簡単に目的が達成できればいいと考える場合もある。事業規模、業種、顧客、従業員、経営理念・・あらゆる要因が重なって顧客ごとのニーズは多種多様に渡る。

マスを目指す企業は、柔軟性を突き詰めてあらゆるニーズを満たすサービスにしなければならない。それゆえの複雑さや顧客ごとの専用のカスタマイズの知識などがどうしても必要になってしまう。マスを狙う場合はそう割り切ってやっていくしかない。導入のしやすさや使いやすさはある程度犠牲にするしかない。

その複雑さを嫌がってシンプルな最小限の機能のサービスを求める顧客も当然いる。だからこそ複雑だけどたくさんの人の要望を満たせるサービスも残り続けるし、シンプルさを突き詰めたサービスはサービスで残り続ける。

これは機能の数っていう視点での比較だけども、それ以外にも一つ一つの機能が洗練されている、使いやすいデザイン、サポート(日本語)、料金、料金体系、中の人との繋がり・・・など色々な観点が存在する。そんなあらゆる視点の中で、顧客によっては例えば料金は優先度が高いけど、機能の豊富さは優先度が低いといったような観点が生まれるのである。

そんな状況で必要なのは、明確なターゲット決めである。以下の図を見て欲しい。

f:id:cevid_cpp:20170329232806p:plain

ターゲットが明確でないと、ぼんやりとしたターゲットが海外からの強豪の参入によって一気に危機的なものに感じてしまう。この図で言えば海外からの競合がやって来た時に、3分の1の見込み顧客が他で取られてしまう!と感じてしまう。自社サービスを使って欲しいターゲットが広い or 曖昧なせいで余計な心配が生まれて競合を真似て無駄な機能を実装してしまう。本質のターゲットを見失って磨くべきものを間違えてしまう。

f:id:cevid_cpp:20170329232949p:plain

ターゲットが明確であれば、完全に棲み分けられる。特に BtoB であればこのターゲット決めってのは本当に大切だ。上記の赤丸が全てを覆い尽くすことなど不可能なのだ。海外から来た人気サービスであっても、多くのマスを取ることはできても全ての顧客を満足させるサービスを作ることなどできない。

BtoC, CtoC との違い

さて、ここまで BtoB においてはといったのは理由がある。 BtoC の場合は “ネットワーク効果” ってのが大事になってくるからである。つまり、友達が使っているかどうかってのがサービスを使う決め手となってしまうのである。SNS はその典型だ。だからこそ成功するトッププレイヤーのみが BtoC で生き残り続けることができる。

BtoB ではそのネットワーク効果があるにはあるけど、薄いために棲み分けが可能だ。巨大 SaaS 企業でも、小規模向けでシンプルな類似 SaaS を使っている顧客を取ることはできない。それによって、例えば投資を受けてどんどんでかくなって機能が増えてきた SaaS は、そのあとに出てくる小さな規模向けのシンプルな SaaS を使っている顧客を獲得することは難しくなる。だからこそ新しい他の SaaS が出てくるのである。これは一つのいい循環なのかもしれない。

だから、「あの会社が既にこの分野でNo1 で存在するからサービスを作るのをやめよ」ってのは時期尚早な考え方だ。その会社の作っている顧客の中で、他でいいのが存在しないから仕方なく使っているケースってのは多くある。そんな痛みを抱えている顧客の要望を叶えるサービスを作れば、確実にその顧客を幸せにできるサービスを作ることができる。

それは特定の機能を磨いたサービスなのかもしれないし、機能を付加したサービスなのかもしれないし、より美しい何かなのかもしれない。

90% の人に好かれるサービスか、30% の人に愛されるサービスか

これは会社の理念的な話になってくるんだけど、あなたは好かれるサービスを作りたいのか、愛されるサービスを作りたいのか。果たしてどっちだろう?

ここまで書けば、BtoB においては事業規模や事業内容、人の考え方などあらゆるものが多種多様な中、90% をの人に愛されるサービスを作ることは不可能だと感じていただけたことだろう。

90% の人に好かれるサービス を作りたいなら、確かに海外からの競合の参入はピンチになる。それだけマスを取ることが難しくなってしまうのだから。だからこそ、その会社とやりあうくらいな覚悟でやらないと負けるって考え方が生まれる。この競争で最終的に勝つのは1社だ。ターゲットが同じだからである。でも、そんなピリピリモードで頑張って楽しいのだろうか。肝心の顧客は幸せになれるのだろうか。これは前回も話したようなファーストフードで日本1を目指しているようなものだ。

30% の人に愛されるサービス ってのは使われる人は少ないかもしれないが、その少ない人のことを徹底的に考えて磨き上げたサービスであれば、愛されるサービスを続けることができる。老舗の旅館のような存在である。業界を冷静に分析し、正しく住み分けをすることで、顧客もハッピー、事業者もハッピーな感じな構成を目指すことができる。

これは決して理想の話ではない。改めて言うが、BtoB では No1 の CRM サービスであってもシェアは20% に満たない程度なのである。それだけ全市場を独占っていうのは不可能なのである。アメリカを中心に足りない考え方が、愛されるまで顧客のために行動する経営だと考えている。もしその考え方が存在すれば、老舗と呼ばれる企業が多く存在するはずだからだ。彼らは 90% の顧客好かれる(使われる)サービスこそ正義!と考えてしまいがちで、日本でもそうやって流される方々が後を絶たない。

海外からの競合の参入はピンチなのか?

さて今回の結論。

マスを狙っている、もしくはターゲットが明確でないサービスの場合は、ピンチになる。

ターゲットが明確で、その顧客のためのサービスを作っているのなら、ピンチにはならない。

私はそう考えている。

API Gateway 用の Swagger JSON を生成する方法

ども、@kimihom です。

久々の AWS ネタは Amazon API Gateway のお話。

f:id:cevid_cpp:20170327191713p:plain

Amazon API Gateway を使えば、 Swagger 形式のドキュメントをアップロードするだけで、APIの “側” を作ってくれる。この “側” を API Gateway で作っておけば、キャッシュを有効化できたり、大量APIリクエスト防止のスロットリング(リクエスト数の制限)ができたり、外部呼び出し用の iOS/Android/JavaScript SDK を生成できたり、CloudWatch にログを吐き出したりすることができる。

今回は、Swagger の話は細かくは書かない。興味があれば以前の記事を参照していただきたい。

さて、上記の記事は1年前なのでちょっと古かったりするため、今回はより完璧に “API Gateway 用の Swagger JSON を生成する方法” をご紹介しよう。

swagger.json の生成

まず swagger.json を書き出す。より詳細のコマンドは以下の Github を参照していただきたい。

GitHub - Gild/ruby-swagger: A super-duper-simple library to read or create Swagger API documents.

# Generate a swagger 2.0-compatible documentation from the metadata stored into doc/swagger
bundle exec rake swagger:grape:generate_doc\[API::Root\]
# Build all the API clients
bundle exec rake swagger:compile_doc

これで書き出された swagger.json を Amazon API Gateway でインポートすれば、確かに API の定義がされた状態まで形作ってくれる。

f:id:cevid_cpp:20170327190645p:plain

しかし、この状態のままでは、統合リクエストや統合レスポンスの定義がされていないままアップロードされるため、結局一個ずつ定義していかなければならないという痛すぎる問題が起きる。せっかくなら swagger.json をアップロードしただけで、スパッとデプロイできるようにしたいよね!?

てことで今回はその方法をご紹介。

まずは面倒でも手動でセットせよ!

例えば CORS を有効にしたいといった場合、swagger 形式で上げた後に先ほどのメニューより CORS の有効化を押せば勝手に設定を変えてくれる。これはこれで手軽で便利である。その他諸々 統合リクエスト/統合レスポンスの設定をまずは完璧にセットしてデプロイし、動作を確認しよう。

んでここがキモなんだけど、これでOK!となったら、[ステージ] -> [エクスポート] -> [Swagger + API Gateway 拡張でエクスポート] を選択しよう。ここでエクスポートした json が、あなたにとって理想の JSON 形式のファイルとなる。

そこには、例えば x-amazon-apigateway-integration といったキーの JSON が追加で埋め込まれている!

つまり、書き出した swagger.json を、x-amazon-apigateway-integration などが入った JSON に再度 データを突っ込めば、API Gateway でインポートした時に全部が定義された完璧な状態を一発でアップロードできるようになるのである!

てことでここは単純な Ruby プログラムの時間である。 Rake タスクとして定義しておくのが良いだろう。

desc 'Swagger ドキュメントに AWS 関連情報を付加'
namespace :swagger do
  task :compile_aws_doc do |task, args|

    json_data = open(json_file_path) do |io|
      JSON.load(io)
    end

    json_data['paths'].each do |path, methods|
      methods.each do |method, content|
        # API Gateway settings
        content['x-amazon-apigateway-integration'] = {}
        #....
     end
  end
end

これがうまくできれば、ポチッと rake タスクを実行すれば良いことになる。

rake swagger:compile_aws_doc

一発で完璧な API を生成できた時の気持ち良さはたまらんね。

終わりに

API Gateway のメリットを知った上で、サクッとSwagger 定義に則った API Gateway の API を作ってみてはいかがだろうか。

Swagger 形式にまで出力できれば、 API Gateway に載せることはそこまで難しくはない。ぜひ挑戦してみよう。

カスタマーサポートのコスト時代の終わり

ども、@kimihom です。

カスタマーサポートの話は他で色々しているんだけども、このブログでも書いておきたいと思ったので書いてみる。まずこの話題を書く気になったのは、以下のメルカリ社のニュースを見て喜びを感じたことから始まる。

カスタマーサポートをプラチナ職種に!福岡オフィスの新スタートをお祝いしました

あのメルカリといえば、非常に多くの人が使っているサービスだ。そのサービスの電話サポートとなるとどれだけの電話がかかって来るのかを想像しただけで身震いがする。個人間取引での間でのトラブルなど解決するのが難しい問題もあったりすることだろう。それでもあえて電話サポートを開設するという決心をされたことに拍手したい。

カスタマーサポートはコストなのか?

カスタマーサポートの品質は悪いし対応も遅いから、決まりきったサポートはどんどん自動化していくべきという考え方がある。

だがほとんどの場合、人が FAQ にも書いてあるのに電話をかけて来るのは、「心配だから」なのである。それに対して、自動化してチャットボットが返信したり機械音声での電話応答だった場合に、顧客は問題を解決できたとしても"心配"を拭うことはできない。逆に信頼を損ねてそのサービスを使い続けたいとは思わなくなる可能性もある。他にちゃんと声を聞いてくれるサービスの方が安心できるので他に移ることだってあるだろう。

顧客の"心配"を"安心"に変えるためにはどうしても生の声を聞くサポートが必要だ。これはどんなに時代が進んだって変わることのない事実だ。顧客の安心を提供することを軽視し効率を求める企業は、顧客もその企業を軽視することになるだろう。顧客はその企業を色々な企業のうちの1社くらいにしか思わなくなり、別にその会社じゃなきゃいけない理由なんてものはなくなって愛され続ける企業になることはできない。

それは気軽に入れるファーストフード店と、ひっそりとした佇まいにある歴史ある名店との違いみたいなものだ。ファーストフード店は徹底して効率を求めるので値段は安く提供できるけど、品質や対応もその程度のもので終わる。歴史ある名店はファーストフード店でやっている効率化をあえて手間暇かけることで、訪れた客に感動を与えてまた来てもらえるようなことを徹底して考えている。この両者の違いは日本人が一番知っているはずの"おもてなし" の概念だ。歴史ある名店がお客をもてなすことを"コスト"だと考えるはずがない。おもてなしをコストだと考えるお店は顧客に選び続けられるための手段がない。

ファーストフード店のような効率を徹底して求めたい人もいるだろう。けれどそういうビジネスってのは一気に登り上がった後に、すぐに競合が出てきてやられる運命にある。あのマクドナルドだって効率化を求めすぎて問題を起こした。愛され続ける名店であれば、100年を超えていつまでも人々に必要とされる存在として残り続けることができる。今の世の中に求められているのはそのような企業ではないだろうか。

顧客対応をいつまでケチるのか

営業やマーケティングに人件費や広告を費やすより、カスタマーサポートに優秀な人材を揃えて 顧客に満足してもらえる仕組みを作ってもらうべき時代がやってきている。

評判の悪いサービスを営業しに行ったりマーケティング費用を費やして、一体誰がそれを使うのだろう?今や誰もが製品をググったり、 SNS などを見て簡単に評判を知ることのできる時代になった。にもかかわらず、その評判を左右する既存顧客を大切にしない (カスタマーサポートに力を入れない) 企業が未だに多い。一体いつまでカスタマーサポート担当者を外注したり、何も知らないアルバイトや新入りの素人に任せたりするような体制を取り続けるのだろうか。成長を追い求めすぎる企業は、自社の評判を気にすることなく突き進んでしまい、その過程で起きた悪評が一気にネットで広まり、崩落していくのである。

カスタマーサポートにはほとんどが単純な質問しかこない? だったらその単純な質問が来ないようにサービスやプロダクトそのものを改良し続ければいいだけの話だ。そうするとまた新しい質問や要望がやって来る。改善を繰り返した先に来る今までになかった質問に対して人工知能が対応できるはずなどない。良いプロダクトにし続けている企業のサポートにロボットが入れる隙間などないのだ。

そんな決まりきった質問しかこないような体制なのであれば、改善する気のないプロダクト自身に問題がある。カスタマーサポートは本来、もっと高度で貴重な仕事になっているはずなのだ。

良いカスタマーサポートは新しい顧客を呼び、良い評判を生み、それが営業やマーケティング以上の効果を生むことになる。顧客はいいサービスか悪いサービスかを判断し、感動すれば SNS に投稿するだろう。そんな友人が評価した情報が実は営業やマーケティング以上に魅力的な新しい顧客を呼ぶことにつながるのだ。

終わりに

今回は改めてカスタマーサポートの重要性について語らせていただいた。

カスタマーサポートを会社全体として大切に思う姿勢があるかどうかにかかっている。カスタマーサポート担当者だけが重要性を理解しているだけでは意味がない。

電話やチャット、メール、対面など、あらゆる顧客接点の一つ一つを大切にするような企業が残り続けることになるだろう。

カスタマーサポートのコスト時代は終わりに近づいている。

月額課金サービスをボクはこう設計した

ども、@kimihom です。

Stripe Meetup というのが渋谷の Tokyo Otaku Mode さんのオフィスで開催された。そこのイベントでサブスクリプション型サービスの設計について話をした。

speakerdeck.com

こちらの内容は、以下の記事の続編的な感じとしてご紹介した次第である。

www.bokukoko.info

以下は補足

プランのプライシングは慎重に

SaaS サービスをいくらで販売するか? 実際に事業を始める上で重要だけど決めることは難しい。見込み顧客に「いくらなら買いますか?」と聞いてみたところ思っていたよりも安めの金額を言われたり、今後のスケールを考えれば安くてもなんとかなると思って、金額を安めに設定しがちだ。だけども、多くの SaaS サービスは料金設定をミスって(なのかは定かではないが)、あとで値上げするという手段を取る傾向があるようだ。

値上げ自体は顧客の同意が得られるのであれば、どうしてもって場合には致し方ない対応かとは思う。でも、できる限りそうならないようにするためにはどうすればよいのだろうか?

私としては SaaS の料金は自信を持った価格設定にしていいと思っている。 ただ、これには条件がある。あなたの作ったサービスが本当に素晴らしいと自信を持って言えるプロダクトである場合にのみ有効だ。他から高すぎない?と言われた時にでも、ちゃんと理由が言える状態であるとも言えるかもしれない。

それで本当に高すぎたって話だったら、値下げはいくらでもできるのだから。

幸いにも私のプロダクトではローンチ後、一度も値上げをしていない。

追加料金を考慮する

単純に月額1,000円ぽっきりのサービスというケースは意外と少ない。例えばライセンスの追加、アドオンの追加、従量課金制の追加、プレミアムサポートの追加など、追加料金の仕様ってのは確実に生まれると考えておいたほうがいい。

その料金を都度請求するような場合には単発決済の API を投げれば済む話ではある。しかし、月末や月初などに一括で決済するような場合は、決済サービスの API に乗っかって実装するには困難が伴うことだろう。

月初や月末などの月のタイミングで一括で決済する方法は割とメジャーな PaaS や IaaS でも採られている方法だ。でもプラン料金以外に複雑に追加/値引料金が絡み合った実装を決済 API のサブスクリプションの仕組みで実現するのは難しいのではないだろか? 頑張って色々調べて サブスクリプションの決済API を呼べば可能かもしれない。でもそれよりも自前で料金を計算して都度 単発の決済 API を投げたほうが柔軟に、そして確実にサブスクリプション型の決済を成功させることができると考えている。これは私の経験上の話なので議論の余地がある。

トライアル期間は必ず用意する

会ったこともない人が作ったサービスを、顧客が一度も試しで使わずにお金を払うだろうか?

誰かと会わないでもサービスが使えるような SaaS の場合、無料トライアルの期間を用意するべきだ。お金を払った後に使ってみてダメだったという場合に、時間もお金も無駄になってしまう。

トライアル期間はサービスによって異なると考えている。 ドキュメント管理や経費精算など、トライアル期間からお金を払った後でも同様のデータをお客さんが使い続けられるのなら、長いほうが(1ヶ月以上)いいとおもう。反対にサポートツールなどはトライアル期間はあくまで内輪で試してみて、有料にしたタイミングで顧客からの問い合わせを受け付けると言った場合には2週間程度で十分かと思う。サポートツールなどは長くしすぎても結論が先送りになるだけになる恐れがあるからだ。

トライアル期間中に “~の使い方をご紹介します” 的なメールを1日1通レベルで送ってくるサービスがあるけど、あれが良いとは個人的に思わない。そもそもそういうメールは読まないし、メールをたくさん送るたびに、顧客は “あのサービスから送られてくるメールはスパムに近い” と思われるようになる。やがて課金情報などの重要なメールですら読まなくなってしまう。メールは本当に大事な時に送る手段と考えるべきで、メールで教えるよりもログインしてくれた後の機能が説明がいらないくらい明快なサービスにすることに注力すべきではないだろうか。

トライアルでどの機能を提供するのかもじっくりと検討したいところだ。トライアル期間で統計データを見せるような機能は本当に必要か?データがほとんどない状態で検索機能を置く必要はあるか?そして今後、顧客が下位プランにアップグレードした際に、上位プランの機能を知る術はあるか?

トライアル期間に上位プランの機能を使ってみてもらうというのは良いアプローチだと考えている。上位プランのメリットを知った上で下位プランに契約すれば、今後どのタイミングでアップグレードすべきかの判断が顧客が一番理解してくれるからだ。それとは反対に、例えば下位プランを使っている状態で、上位プランの機能のリンクや画像だけ表示させておいて、"上位プランにアップグレードすることで使えます" みたいなアラートを出したりするようなサービスもある。それでは、下位プランを使い続けようとしている人にとっては、単なる無駄なリンクでしかなく、ストレスを与えるだけだ。てことで何かしらの工夫が必要になることだろう。

トライアル期間をいかに満足に使ってもらえるかが、今後の顧客獲得に大きな影響を与えることになるだろう。営業やマーケティングよりも、カスタマーサポートが大事だってことが理解いただけたら幸いである。

終わりに

本記事ではよりサービスのスペシフィックな部分に焦点を当ててみた。今回の Stripe Meetup では料金体系周りの情報共有の場として貴重なものだったと思う。それぞれの月額課金サービスでの悩みや思想を聞くことで、「あ、このサービスはこういう思想があるからこういう料金体系にしているのか」だとか「そのサービスだとうちみたいな料金体系は確かに難しいな」などの新たな発見もあった。

今後もこのような場が増えていくと良いと思った。

英語を学ぶ動機を改めて確認する

ども、@kimihom です。

定期的にやってくる英語学習のモチベーション。その波がやってきたのでブログに書くとする。

現在の最大の動機は、再来月の Twilio Signal の参加にある。これは毎年サンフランシスコで開催されるわけだけども、このイベント参加を実りあるものにするためには当然英語を正しく聞き取れるようになる必要がある。

ってことで何度目かわからんけど再び英語熱が出てきた。

自分の現状

前職で TOEIC を強引に勉強させてもらったおかげで、全くできないレベルからそれなりにできるレベルにはなった。 全盛期で TOEIC 780 くらいなので今は 730 くらいかな。

地味に頑張っているのが英語のブログ。ちょっとした英語のセンテンスを1年以上毎日欠かさず書き続けている。今日やったことや感じたことを日記として記している。これのおかげで、基本的な英語であればポンポン喋れるようにはなっているはずだ。ただし長く続けられるようにするために、誰かにチェックしてもらったりとかそういうのをしてもらわずに、ただ自分なりの英語を書き殴っているだけなので、文法ミスとかは多くあるだろう。とはいえそういうの気にするより自分の言いたいことを言えるようになるって方が大事だと思っているので、1年以上続いているのはとても良いことだ。

さて、海外のカンファレンスにおいてライティングやスピーキングは自分が登壇するわけではないので、現地で誰かと話す時くらいになってしまう。カンファレンスにおいて大切なのは当然リスニングだ。

TOEIC 780 レベルなので、一般的な受験英語みたいなやつはそれなりに聞き取れるけど、ネイティブになると途端についていけなくなる。あの受験英語とネイティブ英語の大きな隔たり、あれなんなのほんとw そこの高すぎるハードルに私はいつまでも打ちのめされているのである。

英語ができるようになったら

エンジニアとして英語ができるようになったら、当然いいよね。技術の最新情報は常に英語からだ。わざわざ日本語に翻訳される前に、その情報を得ることができる。思った以上にそれはめちゃめちゃ得なことで、例えば今まで超絶面倒だったことが最新技術を使えばパッとできるようになっちゃったりするわけ。そんなことが日常茶飯事なのがこの世界。

今後はグローバルなサービスとの戦いになるのは必至だ。今でも海外のWebサービスやアプリがどんどん日本にやってきて、侵食されてきている。それはそれでいいことなんだけども、私個人としてのエンジニアリングと世界でやりあっていくためには、まずは共通言語である英語をちゃんと身につけなきゃいけない。自分の作ったサービスも世界に目を向けて作っていくことで、世の中に必要とされるサービスとなり続けることができる。

基本的には web 上にあがっている情報を理解する能力である “リーディング” が求められる。これに関しては自分もそれなりに鍛えてきたつもりでいて、技術英語であれば特段困ることはなくなったし、英語の文章でも目をそらさずに読むようにはなった。最悪 Google 翻訳もあるし、問題ない。

でも"読める"ってだけでは最新および未来を知るのは難しく、"聞き取れる"ようにならなることで得られるものだと考えている。読めるってのはつまるところ文章化されたものを読むことになるので、一歩遅れるからだ。例えばカンファレンスでしゃべっていることを聞き取れるようになれれば、最新情報と未来のことまで知ることができる。

あとやっぱり懇親会でどこの国の人かわからない人と喋ってみたいよね。「君はどこからきたんだい?」「Twilio を使ってどんなことをしているのかい?」 そんなトークをしてみたい。 Twilio ってめちゃめちゃ便利なのに、日本では まだまだ盛り上がりに欠ける部分があるので、海外の先端を突っ走る人たちと情報交換をしてみたいと思う。これには相当の勇気がいることだけども、一歩ずつ英語を学んで自信をつけていくしか方法はないだろう。

勉強の模索中…

さて、アメリカに行くまでにまだ時間はある。英語の勉強を頑張っていこう。

去年の Signal のビデオを Youtube で見たり、丸暗記した DUO をシャドーイングしてリスニング力を鍛えたり、音読パッケージトレーニングで基本的な英語をリピーティングしたりしてコツコツ学んでいる。

DUO 3.0

DUO 3.0

ぐんぐん英語力がアップする音読パッケージトレーニング 中級レベル(CD BOOK)

ぐんぐん英語力がアップする音読パッケージトレーニング 中級レベル(CD BOOK)

だけども、なかなかのツラミを感じる次第である。これを2ヶ月続けられる自信は正直ない。どうにかしなければいけないと思っている。

レアジョブとかやってみたけど、あれも成長を感じられず半年と続かなかった。そう考えると今回の勉強もまた Signal が終わったら止まってしまうのだろう。そうなる前に、毎日書き続けている日記のように寝る前にリスニングをするっていう習慣をつけられるような何かを探してみようと思う。

やろうと思っている時にやる。そうしてちょっとずつでも英語ができるようになると信じている。

(続編)

ポッドキャストを勧めてくれたので、面白そうな英語のポッドキャストを登録してみた。寝る前とか電車乗ってる時とかに聞くようにしてみよう。 ググってお勧めってあったのを適当に追加しただけなので、 Rails とか Startup とか その他諸々いいのあれば追加していきたい。

RR Episodes

Giant Robots Smashing Into Other Giant Robots

5by5 | Quit

Bootstrapped Web - The podcast for founders bootstrapping their startups online