ボクココ

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

企業向けライブ配信システムをローンチした話

ども、@kimihom です。サッカー日本代表、勝利おめでとう!!

そして本日、企業向けライブ配信システム wellcast をローンチしたので、本サービスについて個人的な想いを記す。

企業向けライブ配信システム | wellcast

f:id:cevid_cpp:20180619144707p:plain

サービス概要

wellcast は、リードや顧客育成のための企業向けライブ配信サービスだ。wellcast は appear.in のように、専用の URL を発行し、その URL ですぐにでもライブ配信ができる仕組みになっている。wellcast が発行した URL を、配信を見て欲しい特定の人にメールで伝えるでもいいし、SNS を通じて広くシェアするでもいい。何かしらの方法でその URL を知ってアクセスした人は、簡単な情報(名前とメアド) を入力するだけで、ライブ配信を視聴できる。

配信者は専用のプラグインやソフトウェアをインストールする必要はない。Google Chrome で PC に付属したカメラや USB につないだカメラを使って配信を始めることができる。また、スクリーンシェアを通じてデスクトップの特定の画面を共有することも可能だ。スライドの共有や DEMO をするケースで便利に使えるはずだ。

さらに配信の内容は mp4 形式で録画されるので、ダウンロードした動画をそのまま Youtube にアップして後で見られるようにすることもできる。

よくある質問として、Youtube Live などの他配信サービスと何が違うのかという点がある。そもそも Youtube は BtoC 向けのプロダクトなので、ターゲットが違う。wellcast は企業向けの機能を強化している/する予定だ。視聴者に対して事前に情報を入力してもらうようにすることができるので、ライブ配信を見てもらった人に後でフォローメールを送ったり、面談を依頼するといったような次のビジネスの行動に移すことができる。今後は視聴者の分析機能を拡充したり、CRM との連携を通じて、ビジネス用途に最適化したライブ配信システムにしていきたいと考えている。

金額は毎月の基本料金が800円で、あとは配信量に応じた従量課金になっている。60分の配信を10人が視聴した時におよそ800円くらいになる。その規模のイベントをリアルでやった場合の交通費や会場費、懇親会費などと比べてみていただけたら幸いだ。

開発の背景

wellcast は、まさに私が望んでいたシステムだった。SaaS を運営していると、「進化し続けるサービスを顧客に対してどうやって教えていくか」という課題にぶち当たる。現状では以下のような方法が選ばれていることだろう。

  • FAQ の拡充
  • サポート(メール/電話/チャット)
  • メールやサービス内の通知によるお知らせ
  • リアルイベントの開催

基本的には顧客の不満を解決するために、FAQ やサポート体制を構築するという姿勢になる。それはそれでとても重要なことなんだけど、これらは顧客を育てる という観点ではない。顧客が今まで知らなかったような便利機能や使い方を FAQ やサポートで新しく知ることはできない。なぜなら、新しい発見は顧客の潜在的な課題なので、自分から調べたり問い合わせたりしないからである。

かといってリアルイベントを開催するってのも限界がある。全国各地にいる顧客にどうやって会うかっていったら各地で開催して各地に赴くしかない。それ自体を否定するつもりはないけど、数ヶ月に1回レベルの頻度の開催で "顧客を育てる" という意味で効果的かどうかは疑問である。

顧客育成における付き合い方を模索している中で、ライブ配信は効果的で価値のある方法の一つだと考えている。それを実証するためにも、まずは開発者である私自身が wellcast を使って、さらなる改善を続けていく。主催や共催のイベントで積極的にライブ配信をしたり、自社サービスのウェビナーを通じて、企業におけるライブ配信を普及させていきたい。

技術的な話

現状、Web のテクノロジー(WebRTC)がまだ整備されていないこともあって視聴できるブラウザは基本的に Chrome のみとしている。スマホは Android 端末は古いバージョンでない限り Chrome で見ることができる状態で、iOS はサポートしていない。今後、対応する端末やブラウザを増やしていくのは当然のことだが、現状は wellcast がビジネス向けのサービスであるため、企業のウェビナーやライブ配信を iPhone などのスマホで見ることも少ないだろうという推測がある。

今後、数年以内にあらゆる Web ブラウザで WebRTC が使えるようになるだろうという前提でサービス開発をしている。専用のアプリインストールが不要で、純粋に URL をクリックするだけで配信を視聴できる仕組みを先立って開発している形だ。

終わりに

ライブ配信をビジネスで。

今後、企業がライブ配信を通じて顧客を育成していくことが当たり前になる世の中が必ずやって来る。先頭に立って私がそれを実証していきたい。

もしよければ無料で200円分の配信ができるので、会員登録してみて頂けたら幸いだ。

自己資本 x 自社サービスにかける想い

ども、@kimihom です。

今度 Bootstrap Night! vol3 が開催されるので、それに先駆けて個人的なこのイベントについて想いを書いてみる。

selfree.connpass.com

イベント概要

Bootstrap Night! は去年から半年に1回の頻度で開催されている。外部からの資本を取り入れず、自分たちの力だけで自社サービスを成長させている企業がある。そうした企業が、どのような想いでサービス運営をやってきたのか。どのようにして今に至るのか。そして今後は会社をどのようにしていきたいのか。サービス開発だけでなく、会社経営やビジョンについても考えられる場になってきていると感じている。

そして何より、 自己資本主体の会社経営(Bootstrap)でも、自社サービスを運営して成長させられるという事実を改めて知ることのできる貴重な場になっている。自己資本では会社の意思決定全てが自分たちのコントロールできる範囲に置かれるので、完全に自由で、そして想いを曲げることなく会社とサービスを運営し続けることができる。だからこそ、サービスが成長し続けてもブレない(顧客を裏切らない)開発が可能になり、顧客とより密な関係を築き続けることができる。その熱い想いを聞ける場こそ Bootstrap Night! の醍醐味ではないだろうか。

自己資本 x 自社サービスへのスポット

自己資本の会社経営では一般的には自由を得られると言われている。では自己資本で運営する企業が自由を得て何をしていくのか? これに関してはそれぞれの企業によって考え方は異なるので、会社経営に関しての思いについても聞けることだろう。

www.bokukoko.info

こうした自己資本の企業へスポットが当たりにくいのは、関係者が少ないからだと考えられる。どうやって多くの人に知ってもらえるようにするかは、本人たちの努力でしか実現できない。私がこうやって日々ブログを書いたり、どこかのイベントに協賛して知ってもらえるようにしたり、拡散の仕組みを自分たちのサービスに取り入れたりすることが求められる。当然こうした活動は関係者(ステークホルダー)が少ないので、とても難しいことである。

そんな自己資本で自社サービスを成長させている企業に焦点を当て、情報を共有する場である Bootstrap Night! はとても貴重な場になるはずだ。自己資本で成長させられている企業は、サービス開発を成功させるための "本質" を理解している。それは お金や人の多さでどうにかなるものではない。「サービスを作って、使って欲しい人に使ってもらい、彼らに必要とされ続けたい」という純粋な想いがそこにあると思う。

参考リンク

以前の開催レポートや、参考になる書籍についてご紹介。

”理想を永く追い続ける” Cloud Business Night! イベントレポート | selfree

「Bootstrap Night! vol.2」イベントレポート | selfree

アメリカで開催される Bootstrap 関連最大のイベント。アメリカではカンファレンスが開かれるくらい一般的(?) になりつつある。

MicroConf

自己資本x自社サービスに関してはまずはこの本

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (37件) を見る

終わりに

今回は Bootstrap Night! 開催に先駆けて、個人的な想いを記した。日本で Bootstrap の企業を増やしていきたい。その先駆けとしてこれからも会社/サービス運営を続けていく。

次回開催の Boostrap Night! vol3 でお会いしましょう。

独自ドメインではてなブログを HTTPS 化した話

ども、@kimihom です。

ついに、はてなブログ Pro で独自ドメインをやっていても HTTPS 化ができるようになったので、早速このブログも HTTPS 化した。今や HTTPS でないサイトは信用性や機密性の部分で懸念点を抱えることになってしまうため、真っ先に HTTPS に対応した次第だ。

今回はそれをやっていく上で注意したいことを簡単にまとめてみる。

HTTPSで配信する - はてなブログ ヘルプ

HTTPS 化にする方法

まずどうやれば HTTPS になるのかを簡単に紹介する。

はてなブログの 設定 -> 詳細設定 -> HTTPS配信 にいけば、HTTPS化にするページに行くことができる。そのページで注意点なども書いてあるので、ざっと確認しよう。本記事の後半でも、実際にやって見て起きた点などを報告している。

f:id:cevid_cpp:20180613183421p:plain

サイト内の JavaScript を HTTPS へ

はてなブログをクールにカスタマイズして、例えば <script> タグで HTTP のサイトをロードしている場合、一部で HTTPS が使われていないことで、ブラウザの表示が "保護された通信" にならない問題が出てくる。せっかく HTTPS にしたのなら、この緑色の表示にしたいよね。

f:id:cevid_cpp:20180613182447p:plain

<script>タグのロード先が HTTPS に対応していれば、 src="https://" にするだけで OK だ。

同じように、画像の読み込み等も、基本的に全部 HTTPS にする必要がある。例えば、はてなブログの設定のタイトルに画像を入れている場合、これも HTTP の状態になってしまっている。正しく HTTPS にするためには、再度画像をアップロードすれば、勝手に HTTPS になってくれた。

f:id:cevid_cpp:20180613182625p:plain

この MixedContent の対応については、はてなブログの公式で案内されているので、参照してほしい。具体的に MixedContent の問題がどこで起きているのかを確認するには、ブログページを右クリック->検証->Consoleタブでわかる。

その他注意したいこと

HTTPS 化する前に、以下の点に注意した方がいい。

1. 関連記事一覧が出てくるか これは一時的な問題かもしれないが、HTTPS 化したら関連記事が出てこなくなった。おそらく URL 自体が変わったからなんだろうが、どうやればいいか検討中の段階だ。

もし記事下に関連記事一覧が出てこないのがめちゃ困る!って場合は HTTP のまま様子見した方がいいかもしれない。なぜなら、HTTPS から HTTP に戻すことができないからである。

追記: しばらくしたら出てくるようになった模様? 一時的な挙動のようだ。

2.はてなブックマーク数が表示されるか 記事のブックマーク数も同様に、HTTPS にしてから調子が悪くなった。これははてなブログの公式の記事にあるように、

※はてなスター・はてなブックマーク以外のSNSでのアクション数(例: Facebookのいいね!やシェア数など)は移行できませんのでご注意ください。

とのことである。まぁ、個人的にはそれを差し置いてでも HTTPS 化に真っ先に更新したかったので、この点は承知の上で行った。もしこれが困る!って場合にも、同様に HTTP のまま様子を見た方がいいのかもしれない。今後、この情報が引き継がれるってのは考えられにくいけど。

終わりに

今回は速報的な感じで独自ドメインのはてなブログを HTTPS 化した話をざっとまとめた。

ついに来た、はてなブログ 独自ドメイン HTTPS 化の感動の瞬間を見逃してはならない!!

Web担当者のためのセキュリティの教科書

Web担当者のためのセキュリティの教科書

  • 作者: 株式会社アズジェント/中山貴禎
  • 出版社/メーカー: エムディエヌコーポレーション
  • 発売日: 2017/03/02
  • メディア: 単行本
  • この商品を含むブログを見る

SaaS 運営で CRM へ保存しておきたい情報一覧

ども、@kimihom です。

f:id:cevid_cpp:20180531211339j:plain

SaaS をやっている方であれば、顧客管理の重要性は誰でも理解していることだろう。メールやチャット、電話の問い合わせが来た時にすぐにその顧客の状態を把握して、迅速に最適な回答を導き出すことが求められている。この回答のスピードが早ければ早いほど、顧客満足度につながってくるので、いかにしてその対応を早くするかを日々考えていることかと思う。

さて、今回は SaaS を運営する方なら CRM で保存しておきたい情報についてまとめてみる。

1, ワンクリックで飛べるリンク

CRM にはあらゆる顧客情報が掲載されていることが前提なので、問い合わせが来た時にいかにその顧客詳細のページへ飛べるかが勝負となってくる。電話 > チャット > メール の順番でより素早いアクセスが求められる。

理想はワンクリックだ。例えば電話が来た時点でそこに表示されたリンクをクリックするだけで CRM の顧客詳細へ飛べる。チャットが来た時点でワンクリックでその顧客の属性や過去のやりとりが閲覧できる。その顧客を検索するために、わざわざ管理ツールで文字で検索しなきゃいけないような状態では遅すぎるということである。

私のサービスの場合は電話メールそれぞれでサポートチャネルを用意している。このどちらも、ページ内でワンクリックで CRM へ飛べるリンクが用意されている。そしてどちらのサポート対応の履歴も CRM で電話番号とメールアドレスを関連づけて保存しているので、統一して閲覧することができる。

こうすれば、電話しながらでも詳細を把握して速攻で問題を解決できるサポートを実現できる。さらに、電話を受けた後にメールでフォローするみたいなことも簡単にできる。これで電話を保留やあとでかけ直したり、メールアドレスを聞き出しているようでは電話サポートでの顧客満足度を実現するには難しい。

2, 外部サービスへのリンク

今の時代、サポートの SaaS 以外にも、あらゆる SaaS を利用してサービス運営をしていることだろう。Mixpanel で行動を分析したり、Stripe で課金処理を実行したりといった具合である。どうしても自社システム内の管理画面でしか表示できない項目もあるかもしれない。例えば現在の決済情報などは CRM 側にもマストで持つべきだけど、細かい情報全てを CRM に集約することは難しい。その場合は、CRM 側で外部リンクを保存し、いつでもすぐにアクセスできるようにしたいところだ。

こうすれば電話やチャットで問い合わせが来た時に、2クリックで該当ページへ遷移できる。これも、外部サービス側で id や名前を検索しているようでは遅すぎるし非効率的だ。

CRM で概要を閲覧できるようにしておき、問い合わせ内容に応じてより詳細のページを見にいくといった具合が理想的だ。

3, プランや MRR, ヘルススコア

CRM 側でプランや MRR, ヘルススコアが管理できる必要がある。大抵の場合、こうした情報は自社の管理ツール内で完結させることが多いかもしれないが、それは最初の暫定対応ではいいかもしれないが、しばらくして管理ツールの開発だけに時間を取られることになる恐れがある。特に、例えば、最終的に欲しいデータをグラフ化して表示できるようにしたいとかいった場合に、ユーザーが見もしない管理ページでグラフ描画の実装をしなきゃいけなくなる。自前で SQL を組み立ててチャート化するツールとかもあるけど、その集計のための学習や用意に時間を取られる。

大抵の CRM では、取引を管理できるようになっていたり、カスタム属性で MRR やヘルススコアを保存できるようになっている。そして、それらを最終的にグラフで描画したり、顧客をフィルタリングしたりできるようになる。

例えば MRR が 10,000円以上の顧客を VIP とした時に、自社の管理ツールですぐに取り出すことができるか。ヘルススコア30以下の顧客一覧を抽出し、フォローメールを送ることができるか。そういった分類と対応をわざわざ自前の管理ツールで実装しているのは、時間がかかりすぎだ。それに時間を割くなら、肝心のサービスの機能の改善をしていこう。

最終的に、それらがカスタマーサクセスとしての指標分析の土台となろう。こうしたデータをしっかりと管理せずに、カスタマーサクセスは不可能だ。そして、この分析をエンジニアがわざわざ自前で作らなくても、誰でも取ってこれるような状態にしなきゃいけない。だからこそ、こうした情報こそ 自社サービスの管理ツールで実現するのではなく、CRM へ保存するようにしよう。

ありがちな顧客管理の方法として、「単一チャネルのサポートだけだからサポートツール(Zendesk/Intercom等)に顧客情報を保存しておく」って対応をするケースがある。これはこれで手軽な部分がある反面、チャート描画や指標管理といったところで不十分になることが起き始める。検索やフィルタリングくらいまでならサポートツールの顧客管理で見られたりするが、そっから先(分析やチャート描画, 通知 etc)のことまで提供をしているものはない。今後、そのサポートツールが機能を提供するようになったとしても、サポート担当者以外の人もそのサービスにライセンス費用を払う必要が出てきたりするので、効果的なのかは怪しいところだ。

4, その他 SaaS 独自の顧客情報

サポートチャネルが複数あったり、マーケティングやセールスにも顧客情報を活用しようとなったら、そのサポートツールだけでは足りなくなってくる。厄介なことにマーケティングツールの SaaS, セールスの SaaS、他には従業員管理の SaaS までなんでも SaaS を利用するケースが出てくる。

それらを最終的に CRM でフィルタリング/分析していくので、本当に必要な情報はやはり連携を駆使して CRM 側へ保存していきたいところだ。あらゆるデータを CRM へ保存し、顧客を分析してより良い成功へ導いていく。これこそが「カスタマーサクセス」なのである。

終わりに

「成功する SaaS は CRM を駆使する。」そんな仮説を私は立てている。

顧客の動向を知り、顧客に最適なサポートを提供し、機能を改善していく。自社SaaS で最適な顧客の動向を定義できれば、その理想の顧客の獲得に集中することができる。顧客を知ることができないと、手当たり次第にサービスや機能を作りまくって一か八かのリリースを繰り返すことになってしまうのだ。

本当の顧客を見つけられるようにするためにも、今一度 CRM の本格運用を検討していこう。

CRM―顧客はそこにいる (Best solution)

CRM―顧客はそこにいる (Best solution)

  • 作者: 村山徹,三谷宏治,アクセンチュア,CRMグループ,戦略グループ
  • 出版社/メーカー: 東洋経済新報社
  • 発売日: 2001/07/01
  • メディア: 単行本
  • 購入: 5人 クリック: 39回
  • この商品を含むブログ (16件) を見る

"不可避な流れ" と "伝統を守る" ことのバランス

ども、@kimihom です。

f:id:cevid_cpp:20180528232509j:plain

今日はコミュニティの飲み会的な場に参加させてもらって、色々とあーでもないこーでもないと語り合って楽しい時間を過ごしたのだけど、その中で私が感じた不可避な流れの中で、特に日本における反例について考える機会があったので記事に記す。

海外では当たり前のように使われているサービスが日本で流行らないのは時代遅れなのか

海外では既に Uber や Airbnb などのシェアリングエコノミーが当たり前のように使われていて、中国ではホームレスですらキャッシュレスの支払いを受け付けているようである。

海外の当たり前を味わって帰国した時に、日本の時代遅れ感に危機感を覚えるのは正しい感覚だ。そしてその新しい当たり前を日本でどうやって普及させていくかを考えていくこと自体も何も悪くない。それによって、最終的により便利な社会になるのであれば、やることにとても価値があることのはずだ。そういう意味で、海外で成功した 例えば シェアリングエコノミーを日本に持ってきたり、海外で成功したサービスを日本で展開するってのは社会に対していい影響を与える可能性を秘めている。

そんな流れの中で、日本で Uber がまともに使えないのは政治のせいだだとか、いつまで経っても現金主義が抜けないのは時代遅れすぎてヤバイだとか、そういうレポートを中国やアメリカに行って来た人から耳にタコができるくらい聞かされている。

そんな話の中で思ったのが、「日本ってのは昔の文化や伝統を守り続けることに長けている国」であるという歴史や事実があるってことだ。どう考えても疲れるだけの舞妓さんの身のこなしであったり、外からみたらなぜ存在するかわからないお城や人形が今も残り続けているのである。日本はそうした文化を守り続けたことによって、よその人が一見すると"何の意味があるの?" って思われそうなものでも大切に残り続け、それが逆に日本の特徴として海外から注目されるようになっているケースが少なくない。

日本の暮らしの不便を本当に解決しているのか

例えば Uber を見てみると、日本では当たり前のようにタクシーがどこにでも走っているし、ぼったくられるような心配もないし、(US とかに比べると)割と綺麗である。都内であれば電車があれば何処へでもいくことができる中で、Uber のような運転のシェアリングエコノミーが必要だと思うようなケースがほとんど起こらない。これは、日本の公共交通手段の改善の賜物だと思うし、それ自身が日本で誇らしい文化であるように思う。これが反対に海外ではタクシーの質は悪いしぼったくられるし、電車も汚いわ時間通り来ないわで最悪だったってわけだ。それを解決するためのスーパーヒーローが Uber のようなシェアリングエコノミーだった、と考えると日本で普及しない理由がよくわかる。そうした背景を考えずに、ただ単にアメリカ帰りの誰かさんが「日本で Uber のようなシェアリングエコノミーが流行らないのは時代遅れだ」という主張を聞いたところでなかなかその主張に納得できるものではない。

こんなことを話すと、必ず「海外から日本にやってきた人は確実に不便に思うだろ?」という反論が出てくる。まさにその通り!でも、その不便さを逆に日本の文化として割り切るってのも逆に面白いと思った。まさに"郷に入っては郷に従え"で、日本に来て全てをクレカ決済を求めるのは違う、と。日本に来たなら日本の綺麗なお札と、1万円出しても誰も怒らずにちょうどお釣りを用意してくれて、お金が盗まれるような心配もほとんどないような文化を知ったなら、逆に日本の素晴らしさを改めて知るきっかけになるのではないか。

悪い言い方をすればガラパゴス化だ。そしてその古いやり方が、いつの間にか日本の文化や伝統になって、舞妓さんやお城といったものと同じように文化として残り続ける可能性があるのではないか。そんなことを考えてみると、逆に「最後までシェアリングエコノミー等々の海外の常識が発展しなかった国」として意地を張り続けるのも面白んじゃないかなんて風に感じた。

全員がというわけではなく、あくまでバランスを

この件に関して、「日本国民全員が海外の当たり前を否定すべき」といっているわけでは当然ない。伝統を重んじる日本でも、当然廃れていったものもあるし、新しく取り入れた部分もある。

でもあからさまに「海外では~が当たり前なのに、日本は~じゃなくて終わっている」っていう考え方や論理立てをすることは違うんじゃないかなってところ。残り続けている部分で本当に素晴らしい日本の技術があるわけで、それを大切にし続けるからこそ今の日本の立ち位置があるのである。

そんなことを思いながら最新テクノロジーを駆使して次なる文化をどう作り出そうか考えていた月曜の飲み会だった。

2nd サービスの開発についての考察

ども、@kimihom です。

f:id:cevid_cpp:20180527172823j:plain

現在、土日や空き時間を利用して、2ndサービスを開発している。それに至った背景や実際にやってみて感じたことを記事に記す。

本記事は、以下の記事の続編の立ち位置である。本記事がサービス改善フェーズにおける技術向上のヒントとなれば幸いである。

www.bokukoko.info

1st サービス と 2nd サービス

基本的には、1st サービスに集中すべきという意見は正しい。1st サービスでそこまで成長していないのに、2nd サービスの開発を始めてしまってはいつまでたっても望む結果(ビジネスの成長や成功)は得られないだろう。まずは私がこのブログで散々言っているコア機能の改善を続けていくべきである。

サービス開発の順番を誤ってはならない。そもそも、コア機能の開発をせずに 1st サービスに無駄な機能ばかり追加している例が後を絶たない。例えば電話のサービスだったのに、ユーザーをもっと獲得するために、いつの間にかメールやチャットを詰め込んだ総合的サービスになっていったという具合である。全ての機能が中途半端で洗練されておらず、そのサービスのメリットって一言で何?と言えなくなって来ている状態。こうなってしまうと、類似サービスが出て来たときに太刀打ちできなくなるし、初めてのユーザーは迷ってしまって有料で使いたいとは思わなくなる。

私はこうして1つのサービスに機能を詰め込むことは反対しているわけだけども、それらを全く別のサービスで出すことに対しては否定的ではない。複雑さの問題をサービスのレイヤーにおいてはクリアしているからである。

どんな 2nd サービスが理想的か

私の意見ではあるが、以下の条件を満たしたら 2nd サービスの開発を検討してみて良いだろう。

  1. 1st サービスのコア機能を磨き上げ、そのコア機能に顧客は満足していただいている状態である
  2. 1st サービスのコア技術と類似したものでありながら用途が全く異なる 2nd サービスのアイディアがある
  3. 1st サービスでは取り入れなかった新しいチャレンジがある
  4. 2nd サービスを自分が使うイメージが明確に沸いている

類似のコア技術を活用するのはエンジニア目線から大事なことだと思う。既に 1st サービスで磨き上げた技術を活用して作るものであるので、その時点で優位性を持つことができる。1st サービスよりも、もっと洗練されたものができる可能性がある。ただし、用途が似通ってしまうとカニバリゼーション(新商品の導入による既存商品の売上減少)が発生してしまう恐れがあるので、全く異なるサービスである必要がある。

そんな中でも、2nd サービスでは新しいチャレンジを取り入れたいところだ。これは、新しい発見や技術力の向上を実現する上では不可欠な要素となる。実際、私の場合は 2nd サービスで得られた知見を 1st サービスに取り入れてより良くすることできた。1st サービスを磨き続けただけでは見つけることができなかった発見だった。

2nd サービスで自分が使うイメージが明確にあるってのは、1st サービスでも同様だけど本当に大事なことだから書いた。利用してくれる企業がいなくても、自分たちが欲しいサービスであるため理想に向かって磨き続けることができる。適当に仮説として立てたユーザーのためのサービスだと、今後どう改善していけば良いのかわからず、見当違いの2nd サービスを生み出してしまうことだろう。

私の場合

ここで私の場合どんな経緯を辿ってきたのかを紹介したいと思う。

まず、私は 1st サービスの SaaS を運用していて、「指標の管理」の部分に大きな課題を抱えていた。SaaS には多くの指標(MRRなど)が存在するが、現状はそれらを毎回手で入力して確認するという、エンジニアから見たらなんとも無駄なプロセスを踏んでいる。決済情報は決済サービス側で格納されているので、月ごとの売り上げなどは全て自動化できるはずだ。そして、現在その課題を解決してくれる SaaS は日本にない。てことで、「これはやれば絶対自分たちが使うし、同じように課題を抱えているお客さんにも提供できる」と考えた。普段、色々なサービスのアイディアを模索している中でたまに出てくる「これはいける!」ってアイディアだった。

しかし、実際に開発をスタートさせるべく設計をしていると色々な課題が出てきた。まず、そもそも私に SaaS メトリクスの詳しい知識がなかったという点。こういう分野は、やはり会計などの SaaS を提供している企業の方が絶対的に有利な状況である。そして技術的にも、私の得意とするコミュニケーションの分野とは全く違うもので、技術的優位に立てるアイディアでもなかった。そのため、この開発は設計の段階で頓挫することになる。

次なるサービスを模索している中で、ライブ配信やウェビナーを 1st サービスでやっていきたいという思いが沸いてきた。今後 SaaS を提供している企業は日本中に顧客を抱えるのが当たり前になる。顧客一人一人に会いに行くってのは理想ではあるけども、それはやがて不可能な状態になる。そんな中で一番顧客と身近にやりとりできるのは、ビデオ通話であるし、顧客が増えれば一回のライブ配信を行うことで最適な情報を提供することができるようになる。そして、このウェビナーやライブ配信を企業向けで提供しているサービスの中で私たちの理想に適うものが存在しなかった。

さらに、このライブ配信の技術は私の得意とするコミュニケーションの分野であった。ライブ配信で使われる技術は、私の 1st サービスで使っている技術と一致する。

そうして今も続いている2ndサービスの開発だが、その詳細は正式リリース後にお伝えできればと思う。1st サービスを使っていただいてる方へ向けて伝えたいのは、2nd サービスの開発が1st サービスの開発に活かされているという事実である。直近の 1st サービスのリリースは、 2nd サービスの開発で得られた知見を取り入れたものであった。

終わりに

今回は2nd サービス開発についての考察を記した。

どんどん新しいチャレンジをして、そこで得られた知見を他のサービスへ活かす。そんなエンジニアとしての成長ができれば、さらに大きな価値をユーザーに提供できる。

こうして私は 1st サービスの改善フェーズをより良いものにしているのである。

これだけは知っておきたい「副業」の基本と常識

これだけは知っておきたい「副業」の基本と常識

Twilio の辛いことランキングを話してきた

ども、@kimihom です。

先日の Twilio Lounge のテーマが "Twilio で辛い/辛かったこと" ってことだったので、それについて素直に語ってきた。本記事ではそれの補足とかを含めてまとめていく。

資料

speakerdeck.com

補足

この共有が終わった後に、対策について中の方から説明をいただいた。TwiML(電話かけて命令出す XML) 以降の Twilio 学習が、初心者にとってハードルが高い問題は、定期的にスクール(ハンズオン)形式で積極的に活動されており、確かにこの件はクリアできていると感じた。私が Twilio を触り始めた頃にはこうした取り組みがなかったので、今はより東京や大阪の人にとっては Twilio に触れられやすい環境になっているのかもしれない。

Twilio のバグに関しては、オープンソースと比べて完全にトレードオフとなる。この点に関しては以下の記事にまとめている。

www.bokukoko.info

オープンソースと違って、企業APIの場合は私たちエンジニアが技術そのものに貢献することはできないので、バグがあってもプルリク等で改善しようもないリスクがある。だから外部APIサービスってのは他の代替サービスが出てきたときに、エンジニアリング能力で完全に優越が決まるものである。Twilio は、Web と PSTN(電話公衆網) との接続が今までの技術者にとってとてもハードルが高かったものを実現したという点で素晴らしい。少しずつ類似の外部APIが出てきているけど、Twilio にはそのメリットを今後も強化していって欲しいと思う。

この発表で言いたかったこと

この発表で言いたかったのは、「だから Twilio は使えない」 ってことではないことを改めて強調したい。もしそうだとしたら、私はとっくの前から Twilio を使うことを止めていたことだろう。辛いことまでをしっかりと共有し、それらをコミュニティの力で解決していったり、Twilio 側で改善していってもらうことで、"より良いコミュニケーションのかたち" を生み出したいという思いがある。本件についてこのブログで共有したってことも、それが理由だ。

私自身、うだうだ文句を言っているだけではなく、問題を真摯に受け止めてどうやって改善していくべきかを考え続けてきた。その Tips は今後もブログやコミュニティで積極的に開示していきたい。それが結果的に自分に返ってくるはずだからね。

この発表を終えた後に、音質周りの改善どうやってるのか知りたいという声をいただいたので、以下の記事も併せて紹介しておく。

www.bokukoko.info

終わりに

今回はイベントで発表した内容とそれの補足についてちょろっと書いた。

会社は違えど同じテクノロジーに興味のあるエンジニアが集まって情報交換する場はとてもいいと思っている。今後もコミュニティ活動の協力をしていきたい。