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

ボクココ

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

SaaS のプラン料金設定の勘所

ども、@kimihom です。

最近は SaaSの料金設定について考えることが多いのでこの辺でまとめてみようと思う。

あらゆる規模に適した料金となっているか

各 SaaSにはそれぞれターゲットがいる訳だけども、それに見合った顧客だったとしても規模が 3人だったり50人だったりすることはよくある。その中で3人でも50人でも公平に課金がされる仕組みがあるといいと考えている。

これに対する一番簡単な解としては、1人~円と料金設定する方法だ。そうすれば明確に規模の増減に応じて公平に課金が行われる。特にこの方法で問題がない場合は、人数分の課金にするのが素直な方法だ。

ただし、そうはいかないケースがあったりする。例えばその SaaS が多くの人が使われてこそ価値を生むようなサービスの場合だ。その場合に都度料金が上がってしまうようなら、多くの人に使ってもらうようにする仕組みを作ることができない。となると人数以外の部分で課金の仕組みを作るか、10人までは~円、100人までは~円というように段階的な限度を設ける方法などが考えられる。

人数以外の部分で課金の仕組みを作るのはなかなかチャレンジングだ。3人しか使っていない場合と50人も使っている場合とで料金が同じなら、3人の人はそのサービスを使うのが適切ではないのかもしれない。例えばゲストアカウントは無料でいくらでも作れるけど、管理アカウント単位で課金する方法もある。何かしらの条件で人数や規模ごとで公平に課金される仕組みがあると、ユーザーも運営側も納得のいく料金になる確率が高まると思っている。

規模に応じたプランの機能設計ができているか

SaaSの多くがプランを用意しているのは、顧客の規模や用途によってニーズが変わるからだ。

例えば、3人などの小規模ではほとんど必要のないような機能を埋め込んでしまっては、その顧客にとって適切なサービスではなくなってしまっている。その分料金が高くなってしまっているようなら、もっと手軽に使える他のサービスを選ぶことだろう。適切なプラン設計をすれば、サービスのコア機能をベースに幅広い顧客に対応した SaaSを実現することが可能だ。

大規模になると、例えば同時ログインする人が増えたり扱うデータ量が多くなるといった特徴が出てくる。そうなると、例えば以下のような機能が必要になってくるだろう。

  • ユーザーごとの権限
  • データ分析
  • 誰がどんな作業をしたのかの追跡
  • 大量データを効果的に整理/アクセスする仕組み
  • 自動化

もちろん、これらは小規模でも必要なケースはあるかもしれないが、ほとんどの小規模事業者の場合はマストではない機能だろう。しかし、規模が大きくなれば、上記の機能はマストとなってくる。こうした違いを元に、プランごとの機能を設計していきたいところだ。

そしてそれに適した料金をセットすれば、顧客も満足して上位プランを契約してくれることだろう。

カスタマイズ項目を入れていないか

最上位プランは何でもします!的な料金体系は危険だ。どんなにお金を払ってくれる企業だとしても、その一時的な利益の向上のために未来のサービスの成長を遅めることになるだろう。

今後のサービス改善の中で、その企業のために作ったカスタマイズ機能を考慮しないといけなくなる。もしくはその企業は今後ずっとアップデートをしないということをすることになる。前者は1社だけのために余計な考慮を考えることが増え、多くの時間を消耗することだろう。後者は、SaaS のメリットを全く活かせていない。どちらの対応にしても辛い運命が待っている。

料金設定において、「カスタマイズはご相談ください」を入れることは慎重になろう。どんなに最上位プランを用意しても、である。

では SaaS はカスタマイズできない運命なのかといえばそういうわけでもない。一つの方法としてはアプリマーケットプレイスを作る方法がある。その"アプリ"自体は自社で作っても良いし、外部の企業が作って公開できるような場所を用意しても良いようにする。これによって、ある企業にとっては必要な拡張機能を必要に応じてインストールしてもらい、その後のメンテナンスはそのアプリを作った外部の企業に任せることができる。自社では引き続きコアの機能を改善していくことに時間をかけることができる。この方法は大規模な SaaS ではよく見られる方法である。

途中の金額の変更に関して

プラン料金を最初に設定してみたけど、実際にサービスが成長するにつれて今の金額が適したものではない、と考えるようになることがあるかもしれない。

そこで大抵は値上げする判断を下すことになる。値上げ自体は既存顧客が納得する範囲であれば特に問題はないと思うが、値上げ以外に良い方法がないかは事前に考えてみる価値はあると思う。例えば以下の方法が考えられる。

  • 料金体系を変えてみる。人数分の従量課金制にしたりするなど
  • 上位プランを作ってみる。既存プランは~人までが対象として新しく適したプランを作る
  • 追加オプションを作ってみる。プレミアムサポート付きにするなど

これらは既存ユーザーにマイナスの印象を与えずに、より良いサービスに進化している印象を与えることができるので、まずはこれらを検討するのが良いかもしれない。

終わりに

今回は SaaS の料金設定に関して思うことをざっと書いてみた。料金設定をミスると、適した顧客が使ってくれなかったり、後々変更することで機能開発の時間を止めないといけなくなる可能性もある。サービスごとに最適なプラン設計があるので、じっくり考えていきたいところだ。

まだまだ日本で SaaS ってもの自体が少ないので、これからどんどん増えてこのような議論が生まれる場が出てくれば良いなと思っている。

Netflix で英語リスニング訓練

ども, @kimihom です。

f:id:cevid_cpp:20170416211421j:plain

映画やドラマが定額で見放題でおなじみ Netfix 。海外発のサービスてことで当然アメリカの映画やドラマが数多く提供されている。Netflix を使いながら英語学習のために映画視聴をした報告を軽くしようと思う。

正直なところ、リスニング力の向上はまだ見られず

週末にひたすら見ることを始めて3週間ほど経ったが、まだまだネイティブの英語を聞き取るには困難な状況であることには変わりない。英語を"読む"ことから訓練を始めてしまったので、英語を聞くとまずは頭の中で"英文"に書き起こし、それを"文法"的に意味を解釈して、さらに場合によっては日本語に"置き換えて"イメージする手順を踏んでいるため、速い英語の口調で話されると一気に理解できなくなる。英語のテストレベルだったらこれでも何とかなっていたが、ネイティブ英語でこの作戦は不可能だ。

本来は、"英語の音"だけで言っていることをイメージできるようにならなければならない。そうでなければネイティブの言うことを完璧に理解することは不可能だ。だけど私たちは中学生の頃から、文章を"読む"ことから英語を教わって来た。となるとどうしても英語を読むことから始めてしまい理解できなくなる(少なくとも私は)。英語リスニングに対する考え方というか聞き方から学び直す必要があるように思う。

英語の映画をずっと見ていると、言っていることはよくわからないけど、「だいたいこんなことを言っているんだろうな」というのをシーンからイメージすることはできる。まるで赤ちゃんが母親の言っていることをじーっと聞いているかのように。その中でたまに理解できる英単語や英文が出て来たら、それを日本語に脳内で訳するのではなく、イメージするように意識づけを行なっている。たぶんこのプロセスの繰り返しで、自ずと聞き取れる英語の幅が広がり、知らない単語を言われない限りは理解できるようになるのではないかと考えている。

だから私はこれからも映画で英語を学ぶのを続けていくつもりだ。

イメージ力を磨く

実質、短期間で 100% 英語を聞き取れるようになることなど不可能だ。だから割り切りが必要だ。その人の言っていることの概要さえ知れれば、あとは実際の会話では聞いて確認しながらでも会話を成り立たせることができる。5W1H を理解することだけにフォーカスすること。これが一つのいい訓練になるだろう。

そういう意味でもラジオではなく Netflix であれば映像付きなので、英語リスニングを学ぶにはとてもいい機会だ。今は1ヶ月無料のトライアル期間ではあるが、英語を学ぶモチベーションが続く限り有料でも使い続けようと思う。

終わりに

私自身そんな英語ができるわけではないので、今はそう思いながら英語を学んでいる。近道などないだろうから、自分の良いと思った方法でこれからも続けていく次第だ。

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 に投稿するだろう。そんな友人が評価した情報が実は営業やマーケティング以上に魅力的な新しい顧客を呼ぶことにつながるのだ。

終わりに

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

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

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

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