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

ボクココ

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

スタートアップへ転職しようか悩んでいるあなたへ

スタートアップ

ども、@kimihom です。

f:id:cevid_cpp:20150704223133j:plain

今日あるエンジニアと話していたら、今後の仕事について悩んでいる的なことを言っていた。そんなわけで私の言うことが参考になるかどうかわからないけども、一応 自分でビジネスを立ち上げている私から伝えられることをブログを通して伝えようと思う。

悩んでいるんだったら、来いよ!

あえて私はスタートアップの世界に来ることを歓迎したい。これは相当な無責任な発言であることはわかっている。たいていのスタートアップは失敗するのだからね。でも興味があるのならとっとと移って早く経験し、そのあとに得られた教訓から次どうすればいいかを考えればいいだけなんじゃないかと思う。決してその時間が無駄になるなんてことはない。辛くもがき苦しんだ中に、重要なスキルや教訓を身につけられることだろう。

好奇心の赴くままに移り、そこで経験し、成長する。その選択をしなかった場合は、自らの好奇心を諦める癖がつく。好奇心を失った先には「どうせ~だし」というようなあらゆるものを決めつけて生きていくような人生を歩むことになる。これはみんながそうなってほしくないなぁと思う。

スタートアップのような世界に飛び込むのは、あらゆるリスクがある。でも考えてみてほしい。あなたが今いる会社に勤め続けたとしても、そこが倒産したり、チームが解散したりして自分の行く先をなくすなんてことだって普通にあるわけだ。リスクには、自ら選択するリスクなのか外的要因から発生するリスクなのかっていう2種類がある。どうせなら自分で選んだリスクを背負う方がいいと思わないか?

"やりたいことが見つかってない状態で〜" みたいな言い訳は必要ない。とりあえず興味があったから来た、最初はそれで全く問題ないと思う。何かをやっていくうちにどんどんと新しい世界を見つけ、そこで自分のやりたいことを見つけていけば良いだけの話だ。ここで大事なのは、新しいことをやらない限り、それを見つけることは不可能だってこと。

自分を磨き続けることで本当の安定を手に入れられる

安定 = 同じ企業に勤め続けるってのは完全に間違ったものであるという認識はご存知の通り。じゃあ安定ってのはどうやったら手に入るんだろうか。その一つの答えが、「自分が他者より優れた確固たるスキルを持っている」って状態があるかないかってのがある。企業から必要とされるスキルを持っていれば、どこにだって就職できる。そのスキルが高ければ高いほど、自らの市場価値を高められることだろう。

んで、そのスキルを高めるのって別にどこだってできるよねってのがある。とりわけ インターネットの世界ではどこにいたって平等にスキルを高めることができる。そう考えると、別にどこの企業にいたって変わらないのだ。唯一大事なのは「自らがスキルを磨き続ける」ってことだけである。

時代によってその必要とされるスキルは変わっていくから、常に学び続ける姿勢が必要だ。それさえできれば大企業だろうがスタートアップだろうが、途中はどうであれ必ず自分の望む道を進むことができるだろう。大企業に居続けなきゃいけない理由なんて何一つない。スキルがあるなら戻ることだってできるわけだしね。

スキルを磨き続けなかった先にあるのは、誰でもできる単純作業な仕事だけだ。誰でも替わりができるから、楽しくもなんもない。それこそが最高に不安定な状態だと言える。

ここで言いたいのは、「スタートアップに移って失敗したらどうしよう」なんて心配はいらないってこと。スキルを磨き続ければ何の心配もない。現に、スタートアップを経験した後に大企業に移ったり、別のスタートアップにいたりなんてことは日常茶飯事なのだ。

起業の失敗は人生の失敗ではない

何かいいアイディアだとか実現したい未来があるんだったら迷わず自分で始めてみよう。最近は副業としてやっている人も多いし、会社を辞めてフルタイムでやっている人もいる。

何か新しいビジネスをやろうとしていて、「どうせ失敗するからやめておけ」っていうアドバイスほど意味のないものはない。やろうと思ったなら思い切ってやってみよう。大事なのは意見を聞いて仮説を立て、それを検証するステップだ。最初の作品から検証を通してどんどん形を変えていくことで、市場に受け入れられるプロダクトを作ることができる。仮説検証からの実行は成功のためにとても大事なアクションとなる。

企業に勤めているならば、予め決まったビジネスプランを仮説検証を通して後で柔軟に変えていったりするのが難しかったり、失敗したら次のチャレンジができなかったりするようなケースが多いにある。上が決定としたことを後から変えることなんてできないっていうパターンだ。これこそが大企業の新規事業が失敗する最大の要因だと個人的には思っている。だからこそ大企業ではなく自由なスタートアップとして活動し、あなたの夢を追い続けるってのはアリなんじゃないかと思う。

起業の失敗は人生の失敗ではない。一度起業に失敗したからといって、それだけで人生が失敗だったとなるわけではない。失敗から得られた新しい仮説を立てて、検証を繰り返していけばいいだけだ。やがて成功したならば、あなたの人生は成功だった、と言えるだろう。

終わりに

私の今までのブログにおけるスタートアップに対する見解は、以下を眺めていただけたらと思う。

スタートアップ カテゴリーの記事一覧 - ボクココ

何においても正解ってのはないので、自分の軸を持ちながら "こういう考え方もあるのか" という視点で読んでいただけたら幸いだ。

それでは、あなたの人生の成功を祈っている。

Startup Rails で知っておいた方がいいかもしれない6つのこと

スタートアップ Rails

ども、@kimihom です。掲題のタイトルで以下のミートアップで発表した。

第一回スタートアップRails勉強会 - connpass

発表資料はこれ。

Startup Rails ってテーマなので、てっきり 0を1にする人たち向けかな、と思ったらそういう視点での発表は2つしかなく、他は1を10 や 100 にするフェーズの方々の発表が多かった。

補足的な

私たちは実際大きなピボットと小さなピボットのそれぞれを実施し、市場のニーズによって事業を柔軟に変えてきた。ようやく最近は Product/Market Fit を見つけられた段階まで持ってこれたので、製品の品質の改善に力を注いでいる状況になれている。うちのサービスは品質を意識してやってるよってのが今回のブログで一番伝えないといけない補足である。

0を1にするフェーズのエンジニアに求められるものってのは、普通のエンジニアとは訳が違う。よく言われているエンジニアの常識的なものは通用せず、ただひたすらにサービスをぶっ壊しては作り直して検証することが求められるのだ。だからこそ必要な知識やスキルがあるのだ。その点を発表を通じて伝えたかった。

Startup エンジニアの本当に難しいところ

toB のビジネスなら Product/Market Fit まで持っていければ、マネタイズもうまくいくことだろう。そこまで行くには当然ながら辛い道が待っているけどもね。

toC の場合はもっと辛い。toC サービスの成功レベルで言えば10万、100万ユーザーが基本で、それでようやく"土台ができた"と言える段階だ。そしてその後にさらにマネタイズどうするのってところを考えないといけない。そのサーバーの負荷を支えるのにまたエンジニアが必要になるだろうし出費も増える。そんな中でユーザーから出費と給料をまかなえるようなマネタイズをしていかないといけない。普通に考えてそれがうまくいくはずがない。いきなり広告が沢山出てきてうんざりした toC サービスを読者の方なら複数個思い浮かぶことだろう。だからこそ toC は夢がある分、過酷な道が待っているのだ。

次回以降の Startup Rails はそういう辛い時期や判断が必要な時の Rails アプリ開発はどうしてきた的な話をぜひ聞きたいなと思う。Startup として辛い時に、いかにして Rails を使って高速に機能を実装し、あらゆる外部サービスを駆使して効率化を図ってきたか。そのストーリーを私は聞きたいと思っている。現在進行形でそのフェーズにいるエンジニアってのは忙しすぎてそんなミートアップに参加してる暇すらないのかもしれないので、 経験者がどんどん語る場にしていけたらいいんじゃないかなぁ。

確かに私の理想とする Startup Rails の話をできる母数は圧倒的に下がるだろう。スタートアップで成功した CTO レベルの人たちじゃないとこの時期の話はできない。でもだからこそそういう経験をどんどんと次の若い世代に伝えていってほしいし、それが新しくサービスを立ち上げようとする若者の勇気を与えるのではないかな、と思う。

私は本気で起業して 0から1を作ろうとする若手スタートアップエンジニアにエールを送ることのできるエンジニアになりたい。

終わりに

懇親会では同じような創業メンバーとしてエンジニアに入った数人の方と交流することができた。まさに私が聞いて欲しいと思ったフェーズを経験した方に共感してくれて、それはそれは嬉しかった。

また Startup Rails は開催されるらしいので、参加できれば参加したいと思う。懇親会も長めにとってくれて早めに終わるし、健全でいい場だと思うので運営さん今後とも宜しくお願いします。

本気で作業に集中するためにしたいブラウザ設定

ども、@kimihom です。

f:id:cevid_cpp:20160109180220j:plain

勉強でも何でも集中したい時に色々と阻害されてしまうことが多くある。きっと皆さんにも一つや二つ無意識にやってしまって時間を無駄にしてしまうことで思い当たる節があることだろう。

今回はそんな時にやってみたいブラウザ設定 Tips をご紹介する。

ブックマークを整理しよう

まずはブラウザのブックマークを見直してみよう。たくさん散らかったブックマークはそれだけで作業効率を落とす原因となる。よくアクセスするようなサイトは、そもそもブックマークを経由せずに url 直打ちで行く場合も多いだろう。そういうブックマークは消してもいいのではないだろうか。「たまに行くんだけど、 URL 思い出しにくくて困ってるもの。後でしっかりと読み直したいもの」をブックマークとして残す基準にしよう。

これだけでだいぶ気持ちがすっきりする。まさに掃除をした後の気分だ。

無限に流せる集中できる作業用 BGM を見つけよう

皆さんは作業用 BGM には何を使っているだろうか。ここで Youtube や ニコ動 って選択だと、毎度そのサイトにアクセスして見ないといけない。そこにはあらゆる誘導のリンクがあり、それに惑わされて時間を潰してしまうことが何度あったことか。そういうリスクを防ぐためにも、永遠に流せる作業用 BGM を探してみよう。

私がお勧めするのは以下の2つだ。

音声を合成して好きな様に BGM を作れる Noisli

Noisli - Improve Focus and Boost Productivity with Background Noise

カフェにいるかの様な BGM Coffitivity

https://coffitivity.com/

作業用 BGM で熱くなったり、感動したりする必要はないのである。自分が最も集中できる音源を選んでみよう。もちろん無音っていう選択肢もあるけど、個人的にはあった方がいいと思う。

サイト訪問をブロックするアドオンを入れてみよう

ついつい行ってしまう様なサイトで単なる時間つぶしレベルのものはないか。もしそういうサイトがある場合はブロックしてアクセスできない様にしてしまおう。

Block site - Chrome Web Store

結構細かい時間設定ができるので、例えば休日のこの時間だけは見れられる様にしたいとかの設定が可能だ。まぁこういうの導入するのであれば、ずっとアクセスできない様にするっていう思い切った設定にすべきだとは思うけども。

簡単にどんどん追加できるので、「あ、これはついついよく見ちゃってるな。しかも無駄に」って思うサイトならどんどんぶち込んで行こう。それがあなたの本来集中しなければならない作業にフォーカスを当てることのできる重要な行動となる。

ちなみに私は ブラウザで Twitter, Facebook は見られない様にした。スマホの移動中とかでそういうのは見ればいいしな、という判断からだ。メンションやメッセージの通知も結局はスマホに届くので見逃す心配もない。そう考えればわざわざ PC で見ていたのは時間の無駄だったんじゃないか、と今になって思う。あとは動画系のサイト。これらも本当に時間を潰してしまうのでブロックした。他にも時間を費やしているゲームやサービスはどんどんブロックしていこう。

Block Site は禁止リンクにアクセスした時のリダイレクト先を選べるので、そこに今作業に集中しなければならないサイトに飛ぶようにしよう。それで我に返って作業を再開することができるだろう。

終わりに

誰でもすぐに始められる Tips をご紹介した。

誘惑の多いインターネット。ぜひ思い切って自らを追い込む作戦に出てみてはいかがだろうか。

Heroku SSL Endpoint から Heroku SSL への移行方法

Heroku

ども、@kimihom です。

Heroku SSL のベータ期間がついに終わったので、本番の SSL Endpoint を Heroku SSL に移した。$20 が無料になるなんて、 Heroku さんの気前の良さは素晴らしい。以下に Route53 を使った場合の移行手順を詳細に記す。

Heroku SSL への移行方法

移行で痛い目を見ないように、まずは以下の記事をしっかりと読んでおこう。

devcenter.heroku.com

その上で Route53 で DNS 設定している場合の Heroku SSL 設定について詳しく紹介していく。

移行手順

まずは --type sni をつけて Heroku SSL に証明書をアップロードする。これらのファイル(.crt, .key) はすでに SSL Endpoint の設定時に使っただろうから詳しいことは説明しない。

$ heroku certs:add example.crt example.key --type sni

Resolving trust chain... done
Adding SSL certificate to ⬢ myapp... done
Certificate details:
Common Name(s): www.myapp.jp
                myapp.jp
Expires At:     2016-10-31 16:36 UTC
Issuer:         /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
Starts At:      2015-10-30 05:52 UTC
Subject:        /CN=www.myapp.jp
SSL certificate is verified by a root authority.

=== The following common names already have domain entries
www.myapp.jp
? Select domains you would like to add myapp.jp

Adding domain myapp.jp to ⬢ myapp... done

=== Your certificate has been added successfully.  Update your application's DNS settings as follows
Domain              Record Type  DNS Target
──────────────────  ───────────  ────────────────────────────────
www.myapp.jp  CNAME        www.myapp.jp.herokudns.com
myapp.jp      ALIAS/ANAME  myapp.jp.herokudns.com



$ heroku certs

Name                Endpoint                     Common Name(s)                      Expires               Trusted  Type
──────────────────  ───────────────────────────  ──────────────────────────────────  ────────────────────  ───────  ────────
velociraptor-5555  (Not applicable for SNI)     www.myapp.jp, myapp.jp  2016-10-31 16:36 UTC  True     SNI
hokkaido-1111       hokkaido-1111.herokussl.com  www.myapp.jp, myapp.jp  2016-10-31 16:36 UTC  True     Endpoint

この状態では 2つの証明書情報がアップされたことになっている(velociraptor-5555 が Heroku SSL, hokkaido-1111 が SSL Endpoint)。 Not applicable for SNI とあるのは、現状で 2つ設定されているかららしい。以下の記事参照 When viewing SSL certificates, what does "Not applicable for SNI" mean? - Knowledge Base

次に Heroku SSL でのカスタムドメインを調べておこう。

$ heroku domains

=== myapp Heroku Domain
myapp.herokuapp.com

=== myapp Custom Domains
Domain Name         DNS Target
──────────────────  ────────────────────────────────
www.myapp.jp  www.myapp.jp.herokudns.com
myapp.jp      myapp.jp.herokudns.com

www.myapp.jp.herokudns.com ってのが新しい向き先らしい。今までは hokkaido-1111.herokussl.com みたいなドメインだった。

これを Route53 の CNAME レコードに設定すれば OK。具体的にはwww.myapp.jpwww.myapp.jp.herokudns.com.に向くようにする。これは Route53 の TTL 設定によってしばらく待つことになるだろう。

しばらくして dig www.myapp.jp cname +short の戻りが www.myapp.jp.herokudns.com. になったら移行が完了したことになる。それが確認できたら、SSL Endpoint を削除しよう。 $20 の節約だ!

heroku addons:destroy ssl

以上で無事に更新が完了する。

終わりに

私の場合、 SSL Endpoint を早めに削除しすぎて数分ほどアクセスできない状態ができてしまった。。 移行の場合のドキュメントがイマイチ具体的な手順がわかりにくかったってのがあったので、本記事でより安全な SSL の移行をしていただけたらと思う。

クラウドを活用した WebRTC コールセンターの最前線

JavaScript

ども、@kimihom です。

掲題のタイトルで Open Cloud Innovation Festa 2016 で発表してきた。資料は以下。補足的な資料も含めたらめちゃ多くなってしまったw

speakerdeck.com

発表の裏話的な

今回は参加者がエンジニアだけじゃなくて一般の方も来るってことだったので、ごく一般的な内容を中心に解説していった。本記事で裏話的なことをちょいちょい書いていこうと思う。

まず、私と WebRTC は実はちょっと遠い存在だ。 WebRTC メインでプロダクトを1年以上運営しているが、WebRTC コアについて深く学び始めたのは最近のことだ。なぜなら、Twilio の ClientVideo を使えば、 WebRTC の知識はほとんどなくても利用可能だからである。Twilio を使えば、 WebRTC に関して知らなければならないことはほんの少しで、WebRTC の知識がちょっと必要になるのはデバッグの時くらいになる。

そんな折、私はもっと WebRTC について詳しくなりたいと思った。以下の書籍だけが日本語であったので購入して読んだ。

WebRTC ブラウザベースのP2P技術

WebRTC ブラウザベースのP2P技術

  • 作者: Alan B. Johnston,Daniel C. Burnett,内田直樹(監訳)
  • 出版社/メーカー: リックテレコム
  • 発売日: 2014/12/12
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

NAT越えや STUN/TURN、ICE など Twilio を使って開発していた時にあまりよく把握していなかったワードが解説されていて、WebRTC への理解が深まった。でも実際にゼロから WebRTC を使って何かを実装するにはやっぱりハードルが高そうな感じはする。WebRTC のコアは Web と言うよりネットワークの領域だ。もっとコアの部分を知っていかなければ、 WebRTC を完全に理解することなんてできない。奥の深い技術テーマだ。

私は WebRTC は本当にすごいと思っている(そうじゃなきゃ WebRTC サービス運営はしていない)。WebRTC のすごいところって、Webやスマホ、電話網、SIPフォン、その他デバイス が WebRTC を通じて直接繋がることだ。今まで接続が難しかったことが 全て共通化されてリアルタイムコミュニケーションの幅が広がる。私たちのサービスでは Web と 一般電話公衆網を WebRTC を通じて繋いでいる。今回の発表を通して、ビデオ通話だけが WebRTC じゃないよってところが伝わればよかったかな。

WebRTC とそのほかの HTML5

私たちが開発しているサービスは、音声通話を利用した WebRTC サービスだ。音声通話をしている時に、普通にページ遷移してしまうと通話が終了してしまう。だからこそ Ajax を通じてページ切り替えをしないといけないし、戻るボタンを動作させるために History API を用いて履歴管理をしなければならない。

電話の着信フローの設定をよりわかりやすく表現するために Canvas が必要だった。着信時にスマホ通知を実現するために ServiceWorker が必要だった。電話を保留しているときに他のオペレーターがそれに気づけるように WebSocket が必要だった。最近の HTML5 のあらゆる技術は、私たちのサービスをより使いやすくするために必要なものだった。だからこそ WebRTC 中心にサービスを作れば、必然と他の HTML5 技術が必要になり、自然と SPA っぽくなっていく。

実はスマホ(Android Chrome) でも WebRTC で電話の受発信ができる。これをどんどん突き詰めれば、ソフトウェアをインストールすることなく Web アプリとしてスマホを携帯電話として利用できるようになるだろう。私はそんな未来を予想している。

組み合わせの大切さ

最後のまとめで話したことである「組み合わせの大切さ」。何か固有の技術が出てきた時に、それだけで爆発的なヒットを生むサービスを作ることは難しい。 WebRTC の例で言えば、ビデオ通話だけできるようなサービスを作っても今の時代ユーザーに価値を与えることはできないだろう。

サービスはあらゆるものの組み合わせだ。WebRTC と他の何かを組み合わせ、今までのコミュニケーションを劇的に改善することができてユーザーに価値を認めてもらって初めてサービスは成功する。そこで必要なのは WebRTC 以外の引き出しだ。今流行りの技術を組み合わせる例で言えば、人工知能を組み合わせたり、ビッグデータを活用して戦略的に改善できる通話サービスを作ったり、IoT と組み合わせたり。。日頃からいろんな技術を触ってみて、自分の引き出しを増やすことが大事になる。

Web 1.0でインターネットが使えるようになってポータルサイトが出来上がり、より多くの負荷に耐えられるようになって Web 2.0でSNSが広がってきた。そして次の時代の基盤とも言える HTML5 の登場ってのは何らかのチャンスと言えるのではないだろうか。

終わりに

思っていることをダラダラと書いてまとまりのない感じになってしまったが、今回の登壇で伝えたかったことはそんな感じ。発表を聞いてくれた方、この記事を読んでくれた方に何か響くものがあれば幸いだ。

学生起業を私は応援する。

雑談 スタートアップ

ども、@kimihom です。

最近、大学やめて起業するみたいなので是非が問われているようだ。私は学生の起業思考を応援したいと思っている派である。

辛い道のり、そして失敗すること

ある人は、大学を中退して起業するなんてのは辛い道のりが待っていて、ほとんど失敗するパターンだからやめろ、というかもしれない。私もそんなことは百も承知である。でも、だからと言って挑戦しようとする本人の挑戦を止めさせるってのは違うんじゃないかと思う。辛く険しい道のりがその先に待っているなんて誰もがわかってることだ。ただそれでもやりたい。そんな意思があればそれで十分ではないか。そもそも学生起業を批判している人ってのは、敷かれたレールに浸かりきってうまくいってる人たちだと思う(彼の言う通り)。だから「そんなのはやめろ」と思うのだろう。彼がもしうまくいってしまったら、自分の信じてきたものが違っていたということになってしまうからね。だから "学生起業をやめろ" なんていう先人のアドバイスなんて聞く必要なんかない。

企業に就職して、決まりきった仕事をすることで学ぶってのは、思考を停止させる一つの要因だ。「そういう決まりだからそうしている」みたいな感じで、何も考えなくてもうまく動くように企業のルールってのはできているからだ。それはそれで生き方としてうまくいく。

反対に、起業をすれば自分で考えて行動することが求められる。誰も正しい答えなんて教えてはくれない。その中で自分の信じた道だけを進み続けるという経験は、成功しても失敗しても得られるものが多い。もちろん辛いけどね。でも、そういう道を自分から選んだんだから後悔することなんてないだろう。起業したけどあまりに辛くて事業を閉じることもあるかもしれない。その時点で反対派は「だから言っただろう」っていうだろう。でも、若いうちに大勝負に出て、そこでもがき苦しんで得られた経験は、既定路線に乗った人では決して味わえない経験を積むことができる。それで死ぬことなんてないしな。

あなたにとって何が重要か。それが "金や安定" という意見があの文章に混ざっていたら、もうちょっと経験を積んでからのほうがいいとか大企業に入ったほうがいいというアドバイスもわかる。ただそうじゃなくて「自分の道を自分で決める」っていうモチベーションなら、起業ってのは正しい選択だ。

目的ありきが重要か

「起業が目的になってしまっていて、肝心の中身がない」のは不安要素としてあるかもしれない。でも起業するって決めたなら、何かしら自分の得意とするものでやることを決めて勝負しなければならない。この「決める」って行為自体も、「起業する」っていうモチベーションがあるからこそ真剣に考えるようになるし、起業するっていう目的ありきでやっても別に悪くないと思う。

ぶっちゃけ最初のアイディアに固執しまくるようなビジネスアイディアほど失敗しやすいってのはある。柔軟にニーズの"仮説"を立て、それを検証して どんどんとビジネスアイディアを変えていくような柔軟性も重要だったりする。だから絶対にこれしかやらない!っていうビジネスアイディアありきの起業も危険な側面があるのである。とりあえず起業する!ってだけでも私はいいと思う。

私からの願い

起業するってのは厳しく辛い。私が願うのは、その辛さをすぐに逃れてしまって、楽に稼げるような方法(人を騙すようなこと)を探し続けるようなことはしないでほしい。辛くもがき続けた先に信頼を獲得し、本当にお金を払ってでもほしいサービスやプロダクトを目指してほしい。

そしたら、またドヤって読者を驚かせてほしい。

時代はそんな若手のヒーローが求められている。既定路線から自らの意思で外れ、正しい事業をして正しく成功した、本当の意味でのヒーローを。そのヒーローになれるチャンスを彼は手にした。私は起業する彼を心から応援する。

2016年9月の登壇予定イベント

スタートアップ 告知

ども、@kimihom です。

先月、今月と色々なところで登壇させてもらう機会をいただいている。本記事ではこれから登壇予定のイベントをご紹介する。もし都合が合えば参加していただければ幸いだ。

9/16 ~ 9/17 Open Cloud Innovation Festa 2016

IBMクラウド「SoftLayer」と「Bluemix」のユーザーコミュニティ が主宰するイベント。大学の構内を使って400人規模のカンファレンスということでかなり大きめのカンファレンスだ。

ここでは 15:00 ~ B棟1F 102 にて、「クラウドを活用した WebRTC コールセンターの最前線」 というテーマで発表する。 WebRTC を中心とした HTML5 テクノロジーで、具体的にどのようなことが実現できるのか。そして WebRTC コールセンターサービスである CallConnect において HTML5 はどのように利用されているのか、具体的なデモを通して解説していく。それによって、なぜ今までの Web 技術だけでは同じものを実現できなかったのか、そして HTML5 で作られたコールセンターを実現したことにより、どんな新しい効果が得られるのか。そうしたところをたっぷりお届けする予定だ。

CallConnect は主要な HTML5 技術のほぼ全てを使って実現されている。ということで本公演によって HTML5 でできることは大体把握できるようになるかと思う。HTML5 を使えばどんな新しいことができるのかという観点で聞いていただければ有意義なものとなると感じている。広い観点から解説していくため、込み入った WebRTC の話は今回はしない予定だ。

9/27 19:00 ~ 第一回スタートアップRails勉強会

スタートアップにおける Rails に関してシェアする勉強会。ひたすら 5分の LT を回していくスタイル。私はこういう勉強会が好きで、なぜならどんなにつまらない発表でも 5分で終わってくれるからだ。あと Rails や Ruby だけがテーマの勉強会って長く続けるとギークだけが集まっちゃうような会になってしまって内輪な感じになってしまうから、こういう気楽に LT だけやってあとは交流するくらいのノリが好きである。

それはさておき LT ということで私の発表も5分という限られた時間しかない。その中でいかに記憶に残るプレゼンをするか。スタートアップで Rails を扱うエンジニアに向けて、経験者から少しでも有意義な教訓を伝えられたら、と思っている。テーマは 「Startup Rails で知っておくといいかもしれない 6つのこと」。既にその 6つは決まっている。全て私が経験した上での話なので、座学だけで Rails を学んでこれから新しいサービスを本気でスタートアップとして初めていくような方に伝えたい内容だ。

私の知人も多く参加するみたいなのでとても楽しみにしている。

9/28 第7回 サポート勉強会

連続で次の日にサポート勉強会。今回は Zendesk! Zendesk! Zendesk! ということで Zendesk の込み入ったテーマをそれぞれ発表していく。

Zendesk ってチケット作られてそれに返答する程度だったら誰でもできるんだけど、そこから先の分析したりより効率化したりってのはそれなりに事前知識がないと難しかったりする。それらを徹底解剖し、自分たちが Zendesk をマスターすることで、日頃のサポートの改善に役立てたいという思いがある。

私のテーマは「Zendesk マクロ/自動化 徹底解剖」。マクロのテンプレート作るくらいなら誰でもできるけど、そっから先の分析可能なマクロの構成や自動化の作り方までを説明していきたいと思う。サポートを改善していくにあたっては、数値化によって客観的に判断できる指標が必要だ。それらを Zendesk でどう扱っていくか。より良いサポートの実現に向けて具体案を提案しながら発表する予定だ。まだまだ調査しきれていない部分があるので、当日までにしっかりとまとめておく。

終わりに

色々な機会に積極的に手を挙げ発信していくスタイルはブログでも勉強会でも同じことだ。例えばこの記事によってイベントで出会える方がいたり、反対に勉強会を通してこのブログにアクセスしてきてくれたりしたら嬉しい限りだ。

地道な活動ではあるけども、しっかりと発信していくことをこれからも続けていきたいと思う。