ボクココ

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

Web サービスを自力で作る上で大事な考え方

ども、@kimihom です。

“最近Webサービスを気軽に作ることができなくなった気がする” 流れがある中で、私はどんどんサービスを作っていけ派な人間なので、一言書いておきたいと思う。

開発するネタが出尽くしたことが一つの要因

ちょっと昔は、基本的に「ユーザーがログインして、データベースに書き込んで、それを見る」みたいなだけのサービスでも、業界やユーザーを絞ることで成功させることができた。最近の勢いに乗ってる企業も、基本的に大した技術は使っていない。それでもちゃんとサービスを運営する体制が整えば、軌道に乗せて成功させることはできた。

これから「ユーザーがログインして、データベースに書き込んで、それを見る」だけの発想でサービスを作ったとしても、既視感たっぷりなサービスが出来上がってしまう。基礎的な技術ベースで作られたサービスってのは、他の誰かがもう考えて作ってしまっている。

こんな状況でもニッチ市場を狙ったり営業力でカバーしたり、機能で差別化すればうまくいくかもしれないけど、そのアイディアに対して余程のモチベーションがない限り難しいだろう。同じような発想で、ここ数年前までは Web アプリからスマホアプリへとシフトしていった。そしてスマホアプリでも類似サービスがどんどん出てきてしまってさぁどうしよう、というのが現代である。

そういう意味では、"最近Webサービスを気軽に作ることができなくなった気がする" っていう雰囲気を感じてしまうのも間違いではないと思う。じゃあ私たちは本当に気軽にサービスを作ることができないのか? いや、私はそんなことないと思うので今この記事を書いている。

Web の基本動作に1つのスパイスを入れよう

技術的な観点で、基本動作の一歩上の技術を使うようにしたいところだ。そして新技術を実現するための環境も整い始めている。

本記事で私が最もオススメしたい技術は「WebSocket」だ。WebSocket を簡単に言うと、サーバー側からブラウザ側へ好きなタイミングでデータを送信することのできる HTML5 の技術である。この技術を誰でも使えるようになってきているのは、従来の Web の概念を変えるポテンシャルのある大きな変化だと考えている。

この WebSocket をベースにしたサービスを作れば、既視感のないサービスを誰でも作れようになる。あの Uber は Google Maps に 車の位置情報を WebSocket で紐付けたサービスだ。チャットサービスも同様に WebSocket をベースにメッセージの送受信が行われている。最近ではリアルタイムのゲーム通信でも WebSocket は活躍している。そう考えるだけでWebSocket の可能性にワクワクしないだろうか? WebSocket はアイディア次第で面白いサービスができるはずだ。例えば教師が黒板に書いたデータを送ると、生徒側でその内容がリアルタイムで見られるようになるサービスとかも WebSocket ならではだろう。まぁそんな感じで WebSocket は面白い技術なので是非調べてみて欲しい。キーワードは「socket.io」「ActionCable」「Firebase」、「Twilio Sync」などである。

それ以外にも、最近は Google などが機械学習や画像解析の API を公開してくれたりするので、それらを使って面白いサービスを作ってみるってのも簡単に始められる方法だと思う。とにかく私が言いたいのは、「ユーザーがログインして、データベースに書き込んで、それを見る」の一歩先を1つでもいいから取り入れたサービスを考えてみて欲しい、ということである。そしたら、まだまだ誰も作ったことのない、既視感のないサービスを作ることだってできるのである。夢のある話だ。

技術は複雑になってきているのか?

バックエンドやフロントエンドの複雑さが、気軽に作れなっくなった要因というのは、違う気がする。複雑な技術ってのは新しく作る上では全く必要ない。今でも VPS や PaaS(私は Heroku 推し) など既存技術を使えば同じように簡単に作ることができる。

むしろサービスを公開するって意味ではさらに簡単になってきている。ちょっとでも詰まればググればすぐに答えが見つかるようになってきているし、PaaS 側も大きく改善されている。複雑な技術ってのは、サービスがうまくいって、そのサービスに最適なシステム構成を考え始めた段階で必要になってくる。人がどんどん増えたり、作る機能が増えたりサーバーが増えたりすることで出てきた課題を解決するための技術である。Web サービスを0から作るって段階でそんなことは知らなくていいのだ。

終わりに

Web サービスを自分でゼロから立ち上げる経験は、エンジニアの能力を一層向上させるために必要なことだと思う。そのことに関しては以下の記事に書いたので興味があれば読んでみて欲しい。

www.bokukoko.info

この記事を見て Web サービスを自分で作っていく方が増えていけば幸いだ。

今から始めても決して遅くはないから,どんどんサービスを作っていこう。

CRUD のその先へ。データ分析をはじめよう

ども、@kimihom です。

f:id:cevid_cpp:20170813161658p:plain

Rails を使って Web アプリケーションを作ってる分には、ActiveRecord をちゃんと理解すれば十分だ。そして複数テーブルにまたがった joinpreload の方法などを理解することで、効果的なクエリの発行を学んでいくことだろう。以下のスライドに紹介している。

www.bokukoko.info

さて、その先を目指すってなったらデータ分析をしていくことになる。今回はそんな発展的なデータベースについてのお話と学習方法などについてご紹介しようと思う。

データ分析の重要性

それなりに自社サービスでユーザーが増えてくると、「優良ユーザーはどんな行動をしているのだろう」とか「顧客はどんな種類があるのだろう」とかの疑問が湧いてくる。これは、実際にサービスの思想や理念をベースにして開発している時に、その思想に沿った使い方をしてくれているのかの検証としても非常に重要である。理念ばかりに焦点を置きすぎて、実際のユーザーを理解していないようでは独りよがりのサービスとなってしまう。サービスとして自分たちのやっていきたい方向と、実際のユーザーの使い方の両方を適切に比較することで、初めてサービス提供者とユーザーの理想的な関係が生まれる。

オーケー。実際にユーザーに話を聞きに行けばいいじゃないかという意見はその通りだ。生の声ほど直感的に理解できるものはないし、実際に聞くことで生まれるモチベーションってのも確かに存在する。それはそれで継続してやっていきたいことだけども、ユーザーが増えてくるにつれ、話を聞きに行けることに限界がやってくる。

そんな時にデータ分析の出番はやってくる。

データ取得とデータ分析の違い

データ分析とはいえ、結局は SELECT 文を投げるだけではあるけども、その種類や方法は大きく異なる。

データ解析には2通りの方法がある。ユーザーの"属性"を知るのと"行動"を知るのの2つだ。前者はいわゆるユーザープロフィールなどを集約するので、既存のデータベースから引っ張ってこれる。逆に後者は行動を一つ一つデータとして蓄積していかなければならないので、それ用の設計も必要になるし、集計の方法も変わってくる。

ユーザーの属性や行動を知るために、Google Analytics や MixpanelRepro といったのがメジャーなものとして存在する。これらを使えば、それなりの分析は可能になるけども、実際の生データとして自分で DB の SQL を叩けるようになることでより柔軟で欲しいデータを正確に分析することができるようになる。

今回の記事ではその中でも特に重要になるであろうウィンドウ関数共通テーブル式を簡単にご紹介する。

データ分析で活躍する SQL

データ分析で特に活躍するのが、ウィンドウ関数と共通テーブル式。この2つをしっかりとマスターすることで、柔軟で欲しいデータを簡潔に記述することができる。

ウィンドウ関数

ウィンドウ関数は、一度集約した結果を再度通常のクエリに組み込ませることができる関数だ。これによって例えば「全体のユーザーの中でこのユーザーはどんな属性か」といったことを分析することが可能になる。用法は以下のような感じだ。

AVG() | ROW_NUMBER() | RANK() | LAG()  etc... 
OVER (PARTITION BY ~ ORDER BY ~ ROWS BETWEEN ~ AND ~)

共通テーブル式

1つのクエリの中で使える一時的なテーブルに名前をつけて利用することができる。これで一度取ってきたデータを元に、さらに集約をかけるみたいなことが可能になる。後続の SELECT 文の FROM に、その集約したテーブル名を利用することができる。用法は以下のような感じだ。

WITH テーブル名 AS (SELECT ~ ), テーブル名 AS (SELECT ~ )…
SELECT * FROM テーブル名;

もはや裏技みたいな感じなんだけど、1つのSQLで以前のSQLの実行結果を元にデータを構築するってことができる。それを1つのSQLで書くことができるので、今までプログラムでSQLを組み立てる必要があったのが、 SQLだけで書けるようになった。

Heroku での活用方法

Heroku Postgres には Dataclips という機能があって、これを使えば色々な SQL を実行してデータを取得するみたいなことを簡単に行うことができる。しかも、その結果は URL でシェアすることができるので部署をまたいだデータの共有が可能になる。まずは SQL 分析の訓練として Dataclips を積極的に活用していきたいところである。

さて、この実行結果は当然SQLの実行結果と同じく"表"で出力される。これをなんとかグラフ化したいと思うことだろう。

Heroku Dataclips にはそんな時のために Dataclips の結果を JSON 形式で結果を出力する方法が存在する。それは、なんとURLの末尾に .json をつけるだけだ!これによって、例えばデータをサーバーから読み込んで、フロントエンドのチャートツールで描画といったことも可能になる。

終わりに

今回はデータ分析の概要だけをご紹介した。本記事でより興味を持ってデータ分析をやっていきたい!となったら下記の本はとても参考になるので読んでみてはいかがだろうか。

ビッグデータ分析・活用のためのSQLレシピ

ビッグデータ分析・活用のためのSQLレシピ

  • 作者: 加嵜長門,田宮直人,丸山弘詩
  • 出版社/メーカー: マイナビ出版
  • 発売日: 2017/03/27
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

実はこのデータ分析によってサービスを改善していく姿勢そのものが、「カスタマーサクセス」だ。こういった知見は私はまだ未熟なのでこれからも引き続き勉強していきたいと思ってる。

機能開発より機能改善が大切な理由

ども、@kimihom です。

ここ数日ちょっと風邪をひいてしまって更新が遅れてしまった。。でも今日からまた復活したので書いていこうと思う。今回はサービス開発においての"何をやるか"について。

なぜ人は機能開発を安易に選ぶのか

ここでいう"機能開発"は、「サービスにおいて今までなかった機能を新しく顧客に提供するための開発」とする。

これは一見すると顧客にとって価値を与えられるための手段に見える。そして、機能開発は簡単だ。今まで開発してきた機能とは全く別で追加するだけなので、あまり他の機能との依存関係を気にする必要はない。前に誰かが書いた酷いコードの影響を考えずに、のびのびと新しくコードを書くだけでいい。

新しく機能を開発すれば、「自分の成果」を誰に対しても見せつけることができる。それがプロデューサー、エンジニア、デザイナーそれぞれの成果として会社の評価に響くことだってあるだろう。お客さんに対しても、ちゃんと働いてるアピールをすることにもつながる。

上記のような点によって、ほとんどの人が機能開発にフォーカスしたくなるのは適切なように思える。実際、機能開発こそ全て!なサービス開発をしている企業が多い。私はそんな流暢にあえて “No” と言わせていただきたい。

新機能開発の落とし穴

こんなにもいいことづくしな新機能開発だが、どこに落とし穴があるのだろう?大きく分けて致命的なデメリットが3つある。

まず一つ目に、サービスの強みが薄らぐ というのがある。他社製品と差別化していくべき時に、自社の機能改善をせずに機能開発をしてしまうことで、尖ったサービスで無くなってしまう。多機能なサービスは、他のよくあるサービスのうちの1つにしかならなくなり、他の類似サービスと比較してもメリットを感じないサービスとなる。新機能開発を続けることは、表面的な開発しかしないのでそれぞれの機能が洗練されていくことがない。つまり、「機能の多さで勝負することは、それぞれの機能に自信がないことの現れ」である。本当に自信のあるサービスなら、たった一つの機能で顧客を魅了する。他の機能はその圧倒的な一つの機能を補足するために過ぎない。そんなレベルのサービスが、他社を寄せ付けず圧倒的 No.1 を獲得することができる。

二つ目に、無駄に人が必要になるということがある。新機能開発主義は、特に今までの依存関係を気にすることなく人手を使ってなんとかしていくことがでいるので常にエンジニア不足に陥る。そうしてなんとか雇ったエンジニアたちは、それぞれのコードを書いていくことでサービスがどんどん複雑になっていく。そうしてエンジニアの入退職を繰り返していくうちに、メンテ困難な肥大なソースコードが見事完成するのである。

三つ目に、顧客を迷わせるという点がある。新機能開発ってのは否応にして既存顧客の好みがはっきりと分かれる。A, B, C といたら確かに A だけはその新機能を欲していたかもしれない。しかし、ほとんどのユーザーにとって、現状の機能で概ね満足しているからこそ使い続けてくれているので、無駄に新機能ができたところで喜ぶことはあまりない(機能による)。逆にほとんどのユーザーにとってあまり使わない機能だったら、ただ単に複雑になるだけだ。無駄な機能開発で満足するのは、開発元の会社だけだ。

機能改善を意識しよう

機能改善を意識できているということは、自社のサービスの強みを理解しているということにつながる。その強みを磨き続けることで、業界で圧倒的に他社を寄せ付けないサービスを実現することができる。

それは地味な作業の繰り返しだ。ぱっと見の UI が変わることなんてほとんどないし、ユーザーに大々的に告知することもできない。それでも、その地味な機能改善を繰り返しによって圧倒的な機能の精度、正確性、洗練さ、速度を実現したサービスは、不思議な使いやすさを実現する。地味な機能改善を繰り返すことで得られる境地だ。そして、この地味な作業な繰り返しには、多くのエンジニアを必要としない。一人の情熱を持ったエンジニアが改善を繰り返すことで市場を独占することができるのである。

“機能の多さで簡単に真似されることはないサービスを実現できる” だとか、 “あの有名なサービスは多機能だから、うちも多機能なサービスを目指そう"と考えるのは危険だ。なぜならそれぞれの機能に最適化されたサービスが出てくれば、一つ一つが微妙で複雑なサービスを使う理由がなくなるからだ。世の中には多機能なサービスで成功したものはあるけども、そのサービスにだって他を寄せ付けない一つの圧倒的な特徴ってのがあるはずだ。それがなければ簡単に他が真似できるのだから。

終わりに

今回はプロダクト開発における"改善"について焦点を当ててみた。

尖ったサービスを目指しましょう。そうすれば、顧客がそのサービスを選ぶ理由ってのが生まれて、サービスを使い続けてくれるようになる。私はそう信じている。

インターネット公衆電話サービスを1人開発したよ

ども、@kimihom です。

f:id:cevid_cpp:20170801190002j:plain

ボクココの記事で前からエンジニアはサービスを1人で作りきるくらいの気迫を見せて欲しいと言っている立場だったので、私が今回空き時間で作ったサービスをご紹介する。

名前は InstantCall 。InstantCall を一言で言うと「インターネット公衆電話」だ。 Google Chrome を起動してこのページにアクセスするだけで、日本全国の番号へ発信することができる(0120番号や110などを除く)。ここまで簡単にブラウザで電話発信できるサービスは今のところ日本でここしかないはずだ。

インターネット公衆電話 InstantCall

現在は PC と Android の Google Chrome に対応している。iPhone は早く WebRTC サポートしてください…

開発の背景

本業では企業向けのブラウザ電話システムを作ってるけど、一部のお客さんは ただ一時的に発信したいだけ みたいな方が思った以上にたくさんいた。具体的には、以下のようなケースである。

  • 携帯が一時的に紛失/故障 していて使えない
  • 個人の発信として番号通知されて欲しくない
  • 海外にいる人で日本の電話番号で日本に発信したい

「 InstantCall は誰が使うの?」という質問に対しては、上記のような一時的に電話が使えない特殊なパターンにいる方である。きっと今この瞬間でも、1万人に1人は上記のような状態になっているはずだ。日本全体で1億人と考えれば1日1万人に使われれば良いという発想である。困ったらいつでも InstantCall へアクセスして電話発信ができるということを知っておいて欲しいと思う。

このサービスによる通話料は、1分57円 である。この値段を高いと思われる方がいるかもしれないが、日本全国どこへでもこの料金へかけられるという点と、携帯電話や家の電話のように毎日使うことを想定したサービスではないので、この値段でも全く問題ないと考えているし、発信にそれなりにコストもかかるのでこの料金設定となっている。

まだまだ、ブラウザで電話をするというのは誰もが経験のしたことのないことだと思う。そういう意味では、このサービスでブラウザで電話をする経験を一度でもしてもらって、その便利さを感じていただけたら幸いだ。

強みをサービスに

今回のサービスで私が示したいのは、個人開発でも自分の強みを活かすことで尖ったサービスができあがるということだ。 ただ単に Web アプリケーションが作れますってだけでは誰もが作れるアプリしか作れない。しかし、それにプラスして例えば実家が~~とかだったらそれに特化したサービスを作れば良い。今回のように"この技術は仕事でもよく使う"っていうのでも良い。

つまりは そのサービスは他の誰でもなく、なぜあなたが作るのですか? という質問に堂々と答えられれば OK だ。それがなくて単に「あったら良いなと思ったから」レベルだとモチベーションは続かないし、使われるレベルのサービスに仕上げることは難しいだろう。

“痛み” を抱えているユーザーを想像できるか

今回のサービスで言えば、"電話をかけたい時にかけられない" 痛みに着目している。ほとんどの人はそんな機会はほとんどないだろうけど、そんな痛みを抱えることが先の例のように3年に1度はあるかもしれない。その痛みを解消するためにこのサービスは存在する。

その痛みレベルが大きければ大きいほど良い。サービスを作るときはこの観点だけに注目しても良いと思うくらい大事なことだと思う。"あったら良いなのサービス"ではなく、"ないと困るサービス"を作る。これはサービスを作る上でのアイディアの基本ではあるんだけど、私はそれを常に意識するようにはしている。

終わりに

今回は1人エンジニアで作ったサービスをご紹介した。

読者の皆様の中でも、きっといつか電話発信したい時が来た時に、InstantCall が役立つ日が来ると信じている。

Node.js Express で非同期処理を next で対応する方法

ども、@kimihom です。

今回は Node.js の Express を使った場合の非同期処理のスマートな対応方法をご紹介する。

Node.js の非同期処理の重要性

簡単な比較をすると、Ruby では非同期処理をほとんどしない代わりに、それぞれのリクエストの一連の処理がが終わるまでサーバーはそのために仕事をする。例えば、DB の読み書きの処理は ActiveRecord を使うが、そこで DB との接続をして処理が終わるまでサーバーの一つのリソース(プロセス)は占有されることになる。これはこれでシンプルなコーディングができるので良いのだけど、処理効率という観点ではあまりスマートな方法ではないと言われている。

Node.js でプログラムを書いていると、DB処理を含めたあらゆる処理が非同期となる。これによってより多くの処理を1つのサーバーで処理することが可能になる。しかし、JavaScript 特有の大量 function ネストが続くコールバック地獄が頻繁に発生する。

さて、Express ではこのコールバック地獄を防ぐために next という便利な引数が存在する。今回はこの next についてご紹介しよう。

使い方

まず Express の基本的なルーティング処理は以下のような感じだ。

router.get('/', function(req, res, next) {
  res.render('index');
});

“/” へアクセスが来たら、index の View をレンダリングせよという処理が書かれている。同じようにして、その下に router.get('/foo'... と書けば、/foo にアクセスした時の処理を書くことができる。んで、Express で書くときに意識したいのが、「リクエストが来たら、コードの上から順番にリクエスト処理がマッチするかを探しに行く」ということだ。そしてこれが next を使う上で大切となる。

早速、先ほどの index に非同期処理を噛ませてみよう。今回は JavaScript で定番の setTimeout でレスポンスを遅らせてみる。

router.get('/', function(req, res, next) {
  setTimeout(next, 3000);
  // setTimeout(function() { next(); }, 3000);  上と同じ
});

router.get('/', function(req, res, next) {
  res.render('index');
});

Express はリクエストが来たらコードが上から評価されるということを把握しておけば、"/“ へアクセスが来たらまずは上のコードが実行され、next によってその次にマッチする下のコードが実行されるという流れを理解できるはずだ。

Express の app.js に 404500 の処理が最後にあるのはそのためである。最後の404の部分でマッチしてしまったら対応する定義が見つからなかったということで 404 をエラーを含めてnextに渡す。next の第一引数に エラーオブジェクトを入れておけば、他にマッチせず最終的に一番最後に定義されたエラーハンドリングの処理にマッチすることになる。

/// app.use ~~でルーティング定義

// 一番下に...
// catch 404 and forward to error handler
app.use(function(req, res, next) {
  var err = new Error('Not Found');
  err.status = 404;
  next(err);
});

// error handler
app.use(function(err, req, res, next) {
  // set locals, only providing error in development
  res.locals.message = err.message;
  res.locals.error = req.app.get('env') === 'development' ? err : {};
  console.error(err);

  // render the error page
  res.status(err.status || 500);
  res.render('error');
});

終わりに

今回は Express を使う上で大事なリクエストが来た際のコードが実行される順番について解説した。

next の仕組みを理解することが、Express のコード実行の流れを理解することに繋がってくるので、これから Express を触ろうと思っている方は是非マスターしておいていただきたい。

Express をうまく使いこなせれば、多くの処理をハンドリングする高性能な Web アプリケーションを作ることができるので、シンプルな Web アプリケーションは Express で作ってみても良いかもしれない。

ポッドキャストに出演した話 (収録内容付)

ども、@kimihom です。

今回は縁があって Salesforce 界隈でおなじみの migration.fm というポッドキャストにゲストとして参加させていただいた。そして恐れ多くも2回に渡って公開していただくこととなった。

まずは時間ある時にでも聴いていただけたら幸いだ(それぞれ1時間くらい)。以下、概要とともにリンクをご紹介する。

16 Customer Success! (kimihom)

16: Customer Success! (kimihom)

  • migration.fm を運営されている倉谷さんと知り合ったきっかけ
  • Heroku コミュニティの運営に対する思い
  • 本当のカスタマーサクセスとは

17 Where is Silicon Valley in Japan?

17: Where is Silicon Valley in Japan? (kimihom)

  • 新しい技術 (AI, BigData, IoT…)
  • 日本のシリコンバレー。現時点ではないが、福岡が最有力?
  • よいサービスの作り方。信念を通しつつも顧客と向き合うこと

自分で聴いてみて感じたこと

自分のコミュニケーション能力の低さを露呈してしまった感がものすごく出ている出演だったと思うw 何せ普段、リモートワークで誰とも喋らずにただひたすらプログラミングやこうして記事を書いていることが多い中で、いきなり声でのポッドキャスト出演となれば誰だって難しいだろう。きっと聴く人のことを意識して喋るってのもまたスキルの一つとしてあるのだと思う。私には圧倒的にその能力が無く、素人っぷりが出てしまった。

ただ MC の倉谷さんはさすがの進行力でうまくバランスを取っていただいたと思う。私の素人っぷりの喋りでもなんとか聴いてもらえるような内容になったと思っていただいていることを願う。

話した内容で Part 16 は Heroku コミュニティネタ以外はボクココに書いたことがベースになっているので、読者の方であれば慣れ親しんだ話題に聞こえるかと思う。 Part 17 は割と未来のことって感じであまり記事で書いていない話題に触れているけど、ちょっとだらだら話しちゃったな〜と反省。"このビジネスはいける" 的な話は、最終的にはお前がやれよなんだよなぁ。まるで VC が起業のサービスネタについて喋っているような感じになってしまった。聞く人にとってはそう思われてしまうような感じだっただろうけど、話した本人としてはとても楽しかった。

話し上手か下手かはさておき、私は今回のポッドキャストのような内容を話すことが好きで、そういうのを情熱もって話してくれる人と交流を深めていきたい。そんな意味では良いアピールにもなったと思う。

いつか自分のポッドキャスト bokukoko.fm をやってみても面白いかもな〜と検討したけど、ポッドキャストをやる側になると MC の立場になるわけで、聞く力が間違いなく大事になる。 それはそれでスキルとして磨いていければ良いんだろうけど、やっぱ私はこうしてブログでひたすら思いを書きまくるってスタイルの方が今までやってきた経験を踏まえて自分に合ってるなと感じた。

私は友人や知人にブログを書きましょう、読みにいきますから とよく言ってるんだけど(それでも書いてくれない泣)、ポッドキャストで情報を発信していく人が今後もっと増えても良いんじゃないかな〜。ポッドキャストは移動中に目を使わなくても情報を"聞ける"って意味でありがたいものになるはずだ。最近自分の目がしょっちゅう疲れるんだけど、そうなるとマジで何もやることがなくなるので結局目を使うみたいな循環の繰り返しだった。ポッドキャストはそんな私の一つの良い対処法の一つでもある。知り合いがポッドキャストをやっているのであれば尚更聞きたいし、配信者の方と今後もっと多く巡り会えたら良いな。

終わりに

今回はお誘いいただき & 聴いていただきありがとうございました。ポッドキャストに出演するって機会はほとんどないと思うので、良い経験になった。

実際はポッドキャストって言っても、収録が始まれば普段のトークをしている感じだったので(それのせいで聴きづらい感じになっちゃってるかもしれないけど)楽しく参加することができた。

何か思い出した時にでも定期的にこの収録を聴いていきたい。私にとってそんなポッドキャストの収録だった。

勝手に好きな技術の Twitter サポートを始めてみた話

ども、@kimihom です。

私は HerokuTwilio (あとちょっとだけ Stripe)の User Group のコミュニティの運営として活動に協力しているわけだけども、イベント開催以外でこれらのテクノロジーの普及に向けて何かできることはないかと思っていた。

そんな矢先、ふと Twitter で Heroku や Twilio の検索をしてみると、これら技術に関する問題や疑問をツイートしている方が何人かいた。

思い返してみると、確かにどっかの質問サイトに投稿したところで、実際に見て回答してくれる人ってのは少ないかもしれない。私自身、テクノロジーで何か困ったことがあったらまずは公式ドキュメント + ググってみて、それでもダメならソース読むか US サポートに依頼するみたいなくらい極端な解決方法しかなかった。

この間でもうちょっと助けになってくれる人がいたら、その技術をより使っていきたいと思ってくれるかもしれないし、その技術自体が好きになってくれるかもしれない。私としては Heroku や Twilio を好きな方と一緒に盛り上げていきたいと思っているので、どんどんコミュニティのメンバーが増えていって欲しいと考えている。

問題をそのままにしてしまうと、その技術自体の興味が薄れてしまったりやりたくなくなったりしてしまうことがよく起こる。きっと私も同じような経験をすればそうなるに違いない。結果としてその技術自体も日本で流行らなくなり、ノウハウもたまっていかずに衰退していく。そうなれば、今まさにその技術を使っている私にも大きなダメージを食らうことになってしまう。

てことで、定期的に Heroku と Twilio のツイートで何か困ってそうな方がいて自分が助けになれそうなものに関しては積極的にリプライしていこうと決めた次第である。念のためだが、別にこれら2つのサービスからお金とかもらってるわけではない。

ちなみに Heroku の日本語サポートは Enterprise 契約していないと対応してくれないそうで(!)、ここは私が一役買わないといけないなと強く感じた次第である。Twilio は技術サポートに問い合わせれば回答はくれる。ただ、 Twitter での Twilio に関するタイムラインは見てないようなので、そこは私が時間空いた時に(勝手に)引き受けようと思う。

実際に Twitter サポートを始めてみた

早速、何人か困ってそうな方にツイートをすると、ツイートした問題が解決には至ってない場合が多く、こうして私が何か言わなければそのまま問題が放置されていたような状態だった。

Heroku は解決が難しい(Heroku が原因ではない)場合が多いので大変だけど、話をするだけでも自分自身の勉強につながる。Heroku がどうやって使われているのか、どんな時に使いたいのかを知ることで、自分の技術や興味の幅が広がるので良いことだ。

反対に Twilio は私自身が Twilio のほぼ全てのサービスを触ってやり込んでるので、助けになることが必ずあるはずだと思っている。Twilio 自体が日本ではまだまだ盛り上がりに欠ける部分があるので、こうしたサポートの側面からでも貢献できたらと思う。

そんなこんなで始めてみたはいいものの、公式の Twitter Web サイトを使っていると毎回検索バーに行って最新順で並び替えるという手順を踏まないといけないので地味にめんどくさいw。ここは何かしらの方法で解決していきたい。

てことで困ったらツイートしてみてね

Heroku や Twilio で困ったらツイートしてみて欲しい。もちろん私はこれが本業ってわけじゃないので返信の頻度は下がるけど、困ってそうなツイートを見かけたらフォロー関係なくつぶやいていきたいと思っている次第である。

Heroku と Twilio は本当に素晴らしい技術なので、皆さんもぜひ始めて欲しい。

困っても大丈夫。私がきっと付いている。