ボクココ

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

Heroku Strike のイベントに行ってきたレポ

ども、@kimihom です。

Heroku UG で定期的に開催している Heroku Meetup に行ってきたのでそのレポ。今回はがっつり Heroku を使っている方々の運用事例だったり、Heroku を選択する理由、Heroku の最新機能など盛りだくさんの内容だったのでブログに書くしかないと感じたので早速記事にする。

Heroku Meetup #17 Heroku Strike - Japan Heroku User Group | Doorkeeper

Node.js や PHP でもこわくない Heroku

まずはお世話になっている 10madoの山岡さんの登壇。ちょっと前までは “Heroku = Ruby” な印象が強かったけど、今では Node.js や PHP でも不自由なく使えるようになっていて、実際に 別言語プラットフォームで運用している事例を紹介していただいた。

個人的には山岡さんの Google Form x Slack 通知周りでとてもお世話になった記事があって、今回も Google Analytics から Slack 通知の運用をされているってことで、そこに興味を持った(Heroku は関係ないw)。いつか記事にしてくれるみたいなのでとても楽しみ。

あとは Terraform で環境設定をコード化したり、死活監視に Uptime Robot を使っていたりしていたのが独特な感じがした。インフラ管理周りは個人的にほとんど詳しくなく、名前しか聞いたことないレベルだったので調べてみよう。

そして最後の言葉がぐさっときた。"Heroku に委ねた結果試行錯誤が減る。" これは次の発表にもつながってくるワードだった。

スタートアップのインフラ選び(仮)

続いて crispy の高丸さんの登壇。高丸さんも個人的にとてもお世話になっている方でインフラもわかるアプリケーションエンジニアって感じの凄腕エンジニアだ。

私からすると、昔から Heroku 一択で他の選択肢はちょろっと見るだけで ほとんど比較することもなかったんだけど、具体的にそれぞれのプラットフォームを比較した上で、なぜ最終的に Heroku を選んだかという内容だった。

0->1のフェーズであなたならどうしますか?って部分は考え方が似ている部分が多くて安心した。私も Heroku x Rails な構成でいかに早く顧客に価値を提供するかを考えていたので、やはり Heroku はそういった場合に有用になるはずだ。

今は少人数の開発だから一番シンプルな形でなんとかなっているけど、今後規模が大きくなったり、人数が増えてきたりした時のことまで考えていたのがさすがだった。Heroku 一択な状態というよりかは、Docker コンテナをうまく活用してチームで分業できるような体制などを検討しておかないと、今後の成長スピードを技術的負債で一気に遅める危険性もある。(まさにp40の件) 自分のサービスは新規開発って意味では落ち着いてきたフェーズに入るので、この部分もうちょい勉強して検討していかないとな~。

受託案件での Heroku 運用

受託開発で Heroku を用いてやられている tambourine さん。いつも TAM さんの会場提供してもらってお世話になってる。安部さんからは Heroku Pipeline や Heroku CI などを用いたクールな Heroku 運用事例を紹介していただいた。

個人的にもこの運用方法はとても興味があったんだけど、Github 限定ってことで Bitbucket ユーザーの自分にはなかなか手が出せないところを、ちゃんと使えばこんなことまでできる!って具合で解説してくれた。

開発中にレビューしたり、本番でトラブった時にすぐに戻せるような状態にしたり、Hotfix ブランチで速攻直して本番反映したりといった流れはよくあると思う。これらを Heroku Pipeline でどう実現するか図でわかりやすく説明していただいた。

自分があーだこーだいうより資料見たほうがいい説明されてるので、是非読んでみてほしい。

Heroku の細かすぎて伝わらない最新情報

最後は岡本さんより最新情報。

4つの新機能ってことで、JVM Metrics, Release Phase, DNS Service Discovery, Heroku Shield を紹介していただいた。Java ユーザーに嬉しい JVM Metrics は、 Librato のようなメトリクスツールに表示させたり、Heroku 本体のメトリクスに表示させたりすることができるようになる模様。今後 Java だけでなく他の言語にも対応されるってことで、こういうメトリクス系が増えるのは原因を特定する上でありがたいのでどんどん出てきてほしいと思った。

Release Phase は CDN の更新とかを中心にデプロイの度に何かしたい時にコードを実行できる仕組み。git push heroku master をした後に必ず毎回何かコマンドを実行しているような人にとってはありがたい機能になるだろう。

LT 話してきました

Heroku Support についてと Aistein Vision についてのLT、そして私の Heroku HQ にいった話の3本立てだった。

Heroku Postgres は Heroku を使っている方ならほとんどが使うアドオンだろう。そこで気になるプランの使い分けや、Follower に関しての疑問に答えていただいたのでその知見だけサクッと共有した。 他にも Postgres の運用についてアドバイスをいただいたりしたんだけど、そこは Heroku とは直接関係ないので割愛(LTだし)。また機会があればそこのところについては記事にしようと思う。 とにかく SF 出張、刺激を受けて楽しかったっす。また来年も行けたらいきたい。

終わりに

今回の Heroku Strike はコンテンツ的にかなり注目な内容ばかりで面白かった。何より登壇いただいたお二人は私からのラブコールで実現したってのでとても嬉しかったし、期待通りの発表をしていただいた。そういうのもコミュニティをやっていると得られるものだと思うので、今後ともコミュニティ活動も積極的に関わっていきたい。

近頃の電話不要論に思うこと

ども、@kimihom です。

近頃、「電話はいらない」という風潮が強まっている気がしているので、一旦ここで私の意見を書かせていただく。最終的にはそれぞれの企業の理念や思想にもよるけど、一つの参考として読んでいただけたら幸いだ。

f:id:cevid_cpp:20170620205015j:plain

電話は悪なのか?

電話不要論に関しての意見の一つとして、自分たちの作業が中断されることの負担という課題がよく挙げられる。確かに、電話はリアルタイム通信のため、チャットやメールのように自分たちの都合のいい時に返事することのできない性質を持っている。どんなタイミングでも、作業を一旦中断して顧客からの電話に出なければならないというのは、デメリットとして思われる節がある。

この意見に対して私が思うのは、自分たちにとってではなく、"顧客" にとって電話じゃなくてチャットやメールじゃないといけない理由は本当にあるかという点だ。お客様からすれば、自分の疑問点をすぐ電話で聞いてその場で解決したいと思うことだって当然あるはずである。対面/電話/チャット/メールのどれを選ぶかは、企業側の都合ではなく、顧客の内容や都合に合わせるべきだ。

その時にチャットやメールのように短くても5分、長ければ半日以上待たないといけないコミュニケーションツールしかない企業に対してどう思うだろうか。文字によるコミュニケーションは確かに画像やファイルの添付などの利点もあるけども、それは電話によってまず安心と解決策を掲示してから、補足的な内容としてメールやチャットで文字起こしで丁寧なサポートをする方が理想的ではないだろうか。 顧客によって好ましい連絡手段は変わってくる。電話番号を載せていてもメールやチャットで十分という方はメールやチャットを選べばいいだけの話である。でも電話番号を載せていないとその自由は選べない。それは、お客様のためではなく、企業側の都合によって判断された電話の排除によってである。本当に顧客のことを思うのなら、電話番号を用意して、すぐに解決したいお客様のサポートをすべきだ。

“電話” に関しての固定概念

電話における固定概念の一番悪い点として、「電話番号を1つ用意してその1つの番号で全ての要件を裁く」という一般論がまかり通っていることだと思う。実際のところ、ほとんどの企業は代表番号として03番号だけを用意するということをしてしまっているケースがほとんどである。これでは、誰か新人にまずは電話を取らせて取次をしてもらうような文化を作らざるを得ない。自社サービスのところに電話窓口の番号を載せないで、企業情報に載せた電話番号から電話がかかってきてしまうという課題が後を絶たない。

そんな非効率な電話をする時代はもう終わりだ。今では 050 や 0800 などの番号を好きなだけ取得できる時代になった。これにより、会社番号とサービス用の番号、専門サポートの番号など、かけてくる相手を限定した電話対応が可能になっている。こうすれば、あらかじめ要件が固まった状態での問い合わせがくることになるので、"とりあえず電話に出る" という悪しき習慣から解放される。

例えば、自社サービスのある特定の部分だけの専用窓口を用意すれば、その電話番号からの電話サービスに関する問い合わせしかこない。そんな番号からかかって来た電話は丁寧にサポートしたいと思わないだろうか?自社サービスを持っている企業の場合、そのサービスを最も知っている人たちによって電話サポートをすれば、新人が電話に出て誤った指示をしてしまうこともないし、顧客にとっても即決のサポートを提供できる。全員が幸せになれるコミュニケーションを実現できるのだ。

電話の課題として挙げられている「文字として残らない」「言った言わないのトラブル」も、もはや過去の固定概念だ。今や通話ごとに録音とメモを残し、クラウド上で情報を共有することのできる時代になっている。勝手に Slack 通知をしてくれるものもあるので、メール以上に情報共有のできるツールになりつつある。

そんな時代がきているのを知らずして、「電話は悪だ」というのは早すぎる結論だと思う。

営業電話との戦い

営業電話をどう対応するかという点はクリティカルな問題だ。せっかく作業を中断して電話対応したのに、営業電話だった時の落胆ぷりは私も多く経験しているからとてもよくわかる。

手当たり次第電話するような営業会社がいなくなってくれれば良いのだが、それは難しそうだ。 この課題に対しては、営業電話かどうかを着信時に判別するような仕組みをうまく活用することで対応できる。何度も電話をかけてくるような営業会社である場合は、一度目の通話で"営業"として顧客情報を保存すれば、次からは電話が来た時に営業からだとすぐに判別することができる。または電話に出られなかったり、営業時間外に着信が来た時に、あらかじめその番号を検索すれば、今は営業からの電話なのかネット上で判別しやすくなっている。このような仕組み作りで、できる限り営業電話に時間を割かないような仕組みを作り上げることが可能だ。

それに加えて、営業電話をかけてくるのは一般的に企業の番号に対してである。企業番号とサービス番号をちゃんと分けておけば、対応する担当者もうまく分けることができる。

顧客をどのくらい思うか

電話を導入するかしないかは、企業が顧客のためにどのくらい時間を割くかという決断による。顧客あっての企業という考えを持っている企業なら、当然自分たちの都合ではなく、顧客を大切にしようと思うはずだ。その考えがない場合には電話を導入しないという決断になるかもしれない。

私の願いとしては、顧客を大切にし顧客から愛される企業が日本で増えてほしい。そのためにも、熱心な電話対応ができる企業が増えてほしいと思う。最近の電話不要論は、"顧客を大切にする"という観点が薄れているような、そんな危機感を感じている。

終わりに

私にとっての電話は、顧客を大切にする企業のためのコミュニケーションツールだ!

WebRTC における通信不具合の検証

ども、@kimhom です。

以下のイベントで LT してきたので、今回はスライドとともに補足していく。

atnd.org

WebRTC チェックサイト

まず利用環境で WebRTC が使えるかどうかというそもそもを確認するには、実際に WebRTC に繋いでみる。弊社で実際に Twilio WebRTC に繋いでみるチェックツールを提供している。

Twilio Client 動作チェック

上記は Twilio Client の WebRTC に最適化されているので、一般的な WebRTC チェックツールは WebRTC 本家が提供しているのを使うのがセオリーになるだろう。

WebRTC Troubleshooter

このサイトの注意点として、上記サイトでわかるのは「全く通話できないか、そうでないか」の分類になるということ。音質の不具合などを上記のようなサイトで発見することは難しい。んで、実際に WebRTC で起こるのは、「通話できるけど品質が悪い」という問題なのだ。

そもそも問題を起きないような環境にする

ほとんどはネットワークかヘッドセットのどちらかなので、ヘッドセットに関しては良いものを必ず使っていただけるような環境を用意するのは重要だと思う。最近では接続しているデバイス名を JavaScript で取ってこれたりもするので、そこで検証したりもできる。 推奨ヘッドセットを用意するだけでは実際に使ってくれるわけではないので、そこをどう徹底するのかを考えていきたいところ。 ちなみに自分はゼンハイザーのヘッドセットを使っている。コンパクトでクールな感じで気に入っている。

www.senncom.jp

ネットワークはほんとどうしようもないので、実際に日々の運用でネットワークに負荷をかけないようにするとか、同時接続を減らすとか細かい努力が必要。そもそも貧弱すぎるネットワークの場合は、どうしても他のネットワークにしてくださいとしか言えないのが辛いところではある。

Speedtest の Download で 10Mbps 以上出ていることが望ましい。それ以下だと自分のサービスでは音質が劣化するケースが多発している。

beta.speedtest.net

感想

他の発表者の方のレベルは前評判通りとても高かった。実験として使ってみたレベルではあるんだけども、それでも WebRTC の未来を感じることができた。

自分の発表では運用するときの辛いことを言ったけど、それでも WebRTC の魅力は多い。今後ネットワーク環境はもっと良くなるし、音質もどんどん改善されていく。さらにその先の応用事例もたくさんある。今の WebRTC の課題も、時間とともに改善されていく。

自分は Twilio で提供している WebRTC を今後も使っていくので、今後も知見がたまればここや会社ブログで発信していきたい。

今の時代を生きるには「思い込み」が大事

ども、@kimihom です。

今の時代には「思い込み」が大事なんじゃないかっていう仮説をベースにつらつら話をしていきたい。

選択が多すぎる現代、選択がなかった過去

現代は、一人が決められる選択肢が逆に多くなりすぎているように思う。中学・高校卒業間近の高校生が進路について深く悩むように、社会人になってからも、人は選択を強いられる。選択肢があまりにも多いと、決めきれない人にとっては不幸になる場合がある。結局どれがいいかわからずに、無難なみんなが選んでいるものを選ぶ(女子高生が全員 iPhone を持つ etc)ようになっていく。選択を間違えないように、事前にネットで調べてみんながいいというのを選ぶ。そんな振り回されっぱなしの価値観ができあがる。そんな人は常に不安だ。誰かと一緒にいたり誰かの流れに一緒に乗れないと途端に不安になる。自分の思い込みがないぶん、誰かに依存してしまう。

生き方に正解なんてない。だからこそ、一人一人の思い込みが必要なんじゃないか。自分にはきっと絵の才能がある。そう信じれば絵を描き続けられるだろうし、自分はコンピュータが好きだと思い込めば、その道を進むことができる。自分にはこの人しかいないと思い込めば、それは幸せになれる素質があるのではないか?

昔は選択肢が少なかったぶん、「俺はこうして生きていく」ってのが決めやすかったと思う。基本的に仕事は親の仕事を受け継ぎ、身内から紹介された方と結婚する。自由がないといえばそうだけど、逆に自分の役割が明確になってるので誰でも思い込みを生みやすかった。選択の自由がないってことは決して悪いことでもないのかもしれない。

海外では宗教がいい役割を果たしていると思うんだけど、日本にはそれがないから何かしらで信じるものを持つってのは大事なんじゃないかな。ただし、それが悪いものでないことが大前提ではある。今ある思い込みが良いか悪いかは道徳の教育によって磨かれて欲しいと願う。

その思い込みを発信する

時代をリードする人ってのがいる。彼らは自分が正しいと信じる道を発信することで、ファンを増やしている。彼らは自分の生き方が正しいと"思い込んで"いる。そうした人の発言ってのは、尊敬されるような素質を生む。「私もこういう人になりたい」と他の人を一緒に思い込ませることができる。だからもし自分が人気者になりたければ、選択に悩んでる暇なんかなくて、自分のやろうとしていることが正しいと思い込んで発信することが重要だと思う。

この記事すら私の思い込みだ。そして普段発信しているテクノロジーも、自分の選択が最も正しいと思い込みながら使い、そしてそれを発信している。当然裏で色々と調査はしているけど、最終的にこれだ!と決めるときには、思い込みってのが必要になる。

終わりに

ボクココってブログタイトル自体、なんかすごい思い込みまくりな感が漂うんだけども、そんな感じで私の思い込んでいる(信じている)内容をこれからも発信していきたいと思う。

Heroku の Papertrail でログからコードを実行する方法

ども、@kimihom です。

今回は Heroku アドオンの Papertrail の活用方法についてご紹介。

このアドオンが単なるブラウザ上で綺麗にログを見れるだけのアドオンかと思っていたら、それは Papertrail の 3分の1の魅力しか知っていないことになる。Papertrail の本当の威力を発揮するのは、Alert 機能だ。今回は、この Alert 機能を使って、ログから得られたデータを下に任意のコードを実行する方法についてご紹介する。

概要図

今回は特定のログが吐き出された時に、任意のコードを実行するような想定を考える。以下のような構成図だ。

f:id:cevid_cpp:20170608221458p:plain

“Heroku は AWS で動いているだろ” という 細かいツッコミは置いておいていただいて、AWS Lambda と API Gateway の部分は自前の AWS で用意する必要がある。なので今回はその流れについてもご案内する。

STEP 1. JSON のログを書き出す

まずは Papertrail のイベントをキャッチできるようにするために、アプリケーションから特定のログを出力する必要がある。JSON 形式で書き出すようにすると、あとで処理が楽なのでオススメだ。一応 Ruby (Rails) でのサンプルコードを書いておく。

user = User.find_by(params[:id])
log_info = {
  tag: "PTLog",
  name: user.name,
  id: user.id,
  email: user.email
}
logger.info(log_info.to_json.to_s)

ここで任意の “タグ” を用意することが肝心だ。この値を下に Papertrail の Alert として設定するようにする。

STEP 2. Papertrail で Webhook の設定を実施

さて、特定のログをHeroku から出力したら、いよいよ Papertrail の出番だ。Papertrail アドオンをインストールした後の手順をご紹介する。

f:id:cevid_cpp:20170608222342p:plain

  1. 出力した “タグ” にマッチするログだけを出力するために、 “PTLog” と入力し、Search をクリック
  2. Save Search をクリックし、検索を保存
  3. 名前をつけて Save & Setup an Alert

そしたら今度は Alert をセットする方法について選択する項目が出てくる。 Slack や HipChat を使っている場合は、このまま重要なログであれば通知すれば済むだけの話だけど、今回はコードを実行したいので、"Webhook" を選択。

f:id:cevid_cpp:20170608222838p:plain

Frequency に関してはしょっちゅう起きるイベントなら 1min、そうでなければ 10min とかお好みで問題ない。同じログが短期間で一気に来たとしても、 Papertrail は 配列として データを送ってくれるため、心配ご無用だ。

さて、肝心の Webhook の URL が今回のキモだ。

STEP 3. AWS Lambda と API Gateway のセットアップ

最近は便利になったもので、 AWS Lambda に色々とデフォルトで用意されたテンプレートがあるのでそれを利用しよう。

  1. ランタイムの選択で Node.js 6.10 を選択
  2. microservice-http-endpoint を選択
  3. API 名を適当に作り、セキュリティをオープンで Next
  4. 関数名と名前を適当に編集
  5. コードを下のように修正
  6. ロールは無ければ作って次へ
  7. 最終確認して作成ボタンをクリック

Node.js コードのサンプルは以下のようなイメージだ。

exports.handler = (event, context, callback) => {
  console.log('Received event:', JSON.stringify(event, null, 2));

  const done = (err, res) => callback(null, {
    statusCode: err ? '400' : '200',
    body: err ? err.message : JSON.stringify(res),
    headers: {
      'Content-Type': 'application/json'
    }
  });

  let body = event.body;
  let log = JSON.parse(decodeURIComponent(body.slice(8, body.length)));
  console.log(log);

  log.events.forEach((evt) => {
    let json = JSON.parse(evt.message.slice(0, evt.message.length - 1));
    // ログで出力した JSON が処理できる!
  });

  done();
}

ここで decodeURIComponent したり slice したりしているのは Papertrail が Webhook で書き出すデータを微調整するために行っているもので、きっと誰もが共通の処理をすることになるだろう。これで晴れて Heroku のログに出力した関数を AWS Lambda 内で好きに扱うことができるようになった!

おっと、最後に Papertrail の Webhook URL を API Gateway が生成した URL にセットするのをお忘れなく。 https://xxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/yyyyyyyy のような URL になってることかと思う。

あとは煮ても焼いても・・・。お好みに。きっと運用フェーズで例えば外部サービスの API を呼んだりすることで、データ連携や重要な通知をしたりといったことができるはずだ。

終わりに

運用フェーズではいかに効果的にデータを集積し、サービスの改善に生かせるかが課題になってくるかと思う。しかし、通常のアプリケーション内でそのような情報を外部に送るようなコードを書いてしまうと、そのぶんユーザーへのレスポンス速度が遅くなり、ユーザー体験を悪化させてしまう。そんな時はログからイベントをトリガとして発生させ、それに応じてコードを実行させるようにすることでユーザー体験を損ねることなくデータを蓄積していくことが可能だ。

最後に宣伝になるがこのような Heroku の開発/運用 Tips をシェアする Heroku Meetup があるので、よければ参加してほしい!今回は Heroku をガチで使っている方々からの運営事例と、Heroku 最新 Tips をお届けする予定だ。

herokujp.doorkeeper.jp f:id:cevid_cpp:20170608230018p:plain

エンジニアがゼロからサービス立ち上げするメリット

ども、@kimihom です。

Web エンジニアの中で、案外ゼロからサービス立ち上げを経験したことのある人って少ないのかもしれない。大抵は企業に就職して、既にある成功したサービスの運営や新機能、他プラットフォームへの対応などをやることが多いかと思う。

そのような既にあるサービスを拡張する 10->100 のフェーズでは体験できない 0->1 フェーズについてのメリットについて語らせてもらう。

胸を張って自分の作ったサービスだと言える

単なる気持ちの問題だけど割とこれって個人的には大事で、誰かが作ったサービスをメンテしてます程度だとそのサービスに対して100%の情熱を注ぐことは難しい(あくまで私の場合)。100%の情熱が注げないとどうなるかというと、コードの品質に妥協が入ったり、第三者の意見をハイハイ言って実装するだけのイエスマンになりがちだ。

自分の作ったサービスで、思い入れがかなりある場合は、否応無くソースコードを今自分の持てる最高の限りを尽くした状態に保とうとするだろう。そして第三者が言った新機能に対し、エンジニアであっても 「~だからそれは良くない」と堂々と言えるような立場になることができる。私はエンジニアであってもそう意見の言える立場がもっと増えるべきだと思う。なぜなら俗にいうプロダクトマネージャーはほとんどソースコードを見たり触ったりしないわけで、その立場の意見はシステム側の考慮が全く入っていないためだ。

きっとここで反論が出てくるであろう、「どんな無茶な要求でも実現できるエンジニアこそ、腕のいいエンジニアだ」というパワータイプの意見が。これに対しては私は断固として No と言いたい。例えばシステム側の設計が考慮されていない実装をしたら、その一瞬はそれでなんとか凌げるかもしれないけど、そのあとはどうなる?そのコードのせいで今後ず〜〜〜っと負債を抱えたままサービスを運営し続けていかねばならなくなる。そんなことがきっかけでサービスの品質に対して愛着がわかなくなり、次の機能開発・改善で今までよりも適当なコードを書くようになってしまう。一度でも機能や品質に妥協してしまうと、綺麗にメンテされていたコードは雪崩のように崩れ去って行ってしまうのだ。

機能に関して、エンジニアでも妥協しない。そんな立場でいられるようになるには、サービスの 0->1 をやった人間こそ一番なれる可能性が高いのではないだろうか。むしろ他にあれば教えて欲しい。

システムの全てを把握できる

途中から入れば、今まで動いている状態のを手直ししていくことになる。その場合、裏側のコードがどのように動いているのかを把握せずして表側をそのまま実装してしまうことも少なくない。そんな状態のプログラミングは、毎回冷や汗ものだ。

全ての開発に自信を持ってできるってのは、ゼロから立ち上げて頭の中に全て入っている人間しかできない技だ。設計の"なぜ"を理解しているのは、どうしてもその作った本人にしかわからない。設計の"なに"に関してはドキュメントを書いてまとめて読めるようにすることはあると思うが、その裏の背景まで知りながら開発するってのは安心してプログラミングできる一つの材料になる。

途中から入った人でも同じような品質を担保するためにレビューって文化が大事なんだろう。しかしレビューはわざわざ開発する前に設計レビューをもらい、開発が終わったあとはコードレビューが入り、リリース前に手順書レビューが入り、、みたいな流れになりやすい。てかむしろ途中から入ったメンバーがいる状態で、このような手順を踏んでいない開発組織があればむしろ危険だろう。

そしてこれこそが、1つのシステムに対して1人と10人で開発するのとでそこまで効率が変わらないとまで言われる所以でもある。1人であれば全て頭の中に入れて一気に開発するぶん、メンバー間の合意形成をとる時間を割くことができる。スタートアップと大企業のスピードの違いってのは開発の現場でも同様なのだ。

成功/失敗に関わらず大きな成長を得られる

サービスが成功/失敗するかもわからない状態で、その発言は無責任だという方がいるかもしれない。それは確かにごもっとも。私自身、実に多くのサービスをゼロから作っては壊してクローズを続けてきた。でも、私は数多くの失敗がダメだったとは決して思わない。よく言われる話ではあるけど、なんでダメだったのかを分析し、それを強化するという次のモチベーションにつなげることができるのだ。例えば 1個目のサービスはユーザーに求められていないサービスを作ってしまったと反省するとしよう。そしたら次は自分や身の回りの人に事前にこんなサービスが欲しいかを確認するプロセスを踏むことになるだろう。2個目のサービスはデザインがイケてないという反省が出てきたとしよう。そうすれば自分でいいデザインとは何かについて学んだりデザインツールを勉強したりするだろう。

このような成長によって、1人のエンジニアの力量がどんどん増えていく。それは既に成功したサービスのメンテ開発をしているエンジニアとは比べ物にならないほど多くの量になっていることだろう。

10個開発して1個成功すればそれでいいのだ。その1個さえ成功すれば、今まで書いたメリットを最大限享受できる環境を、あなた自身で作り出すことができるのである。

終わりに

企業のどこもかしこもがエンジニア募集の札を掲げているけど、そこにホイホイついて行っていいのかってのは一度考えてみてもいいかもしれない。もしあなたに金銭的、時間的余裕があるのなら、空き時間からでもゼロからサービスを作り始めたり、思い切って会社を辞めて始めてみるのもいいだろう。その時間は決して無駄にはならなくて、人生で最も成長できたと言える数ヶ月を味わうことができるだろう。

「このサービスは私が作りました。何でも聞いてください。」そんなことを胸を張って言えるようになろうではないか。

良い Web API の5つの条件

ども、@kimihom です。

私は仕事柄、色々な API の仕様を見て実装するようなことをしている。そこで感じる「個人的にあったら嬉しい Web API の機能」について語っていきたい。

1. API とドキュメントが無償で公開されている

Web API の資料が誰でもアクセスできるようになっていること。そして開発者は無償でその開発環境を手に入れられること。これが一つ目の条件だ。

至極当たり前のように思えるんだけど、そうじゃないところが結構あるので、一番先に書いた。API を公にせずにドキュメントは担当者とのやり取りでメールの 添付 PDF ファイルにまとめられているとか普通に存在する。または、API を使うのに有料契約しなければ開発する環境すら用意できないところもあったりする。

Web API は色々な企業が自由に開発し、連携できるようになって欲しいと強く願う。一部の企業にだけ契約書を交わして特別公開みたいなクローズドな世界では、開発者だけでなくユーザーの選択肢を限定してしまう。特に SaaS 系だったら顧客やタイムラインなどで連携できたら良いのにと思うことがたくさん出てくるが、その企業が自由に利用できる API を公開していないために自社のユーザーを困らせる原因を自ら作っているのである。

こういう企業ってのは大抵は「ユーザーを囲みたい」っていう理由でクローズドにしているか公開していなかったりするんだけども、自社であらゆるニーズを満たすサービスをすべて実現するのは、それぞれの規模、業種、スキルがある中で不可能だと早めに気づいていただきたい。オープンな Web API を公開し、誰もがあらゆるサービスと気軽に連携できるものが求められているのだ。

2. 認証の仕組みがしっかりと用意されている

基本的に Web API の認証方法は トークン方式か OAuth2 認証かの2つになる。個人的にはこのどちらも用意していただけるとありがたい。もちろんトークン認証はセキュリティ的に危うい点があることは承知だが、トークンをセキュアに管理することで手に入れられる手軽さをは大きい。テストも簡単にできるし、変に有効期限とかを気にしなくて良いので安心して実装できる。

トークンをさらに独自に暗号化してリクエストを POST で送ってくださいみたいな API に遭遇したことがあるが、何のための予測不能なトークンを生成しているのかよくわからないので、トークンを付与するだけでレスポンスを返せるようにして欲しい。

OAuth 認証は正しく OAuth になっているものにして欲しい。たまにアクセストークンとリフレッシュトークンの使い方を勘違いした API を見ることがある。リフレッシュトークンはあくまでアクセストークンの有効期限が切れた時に再発行するためのトークンであり、普段のリクエストでリフレッシュトークンの送信も必須にするなどはして欲しくない。

トークン、 OAuth2 に限らず、利用できるスコープが用意されていると安心できるので尚良い。ここは API の機能が多い場合とかは必須になる項目かと思う。

3. リソースを検索するための手段がある

割とありがちなのは、一覧 API と ID で限定するだけの API しかないケース。これだとリソースをどうやって検索すれば良いのか困るケースが多々ある。

例えばメールアドレスや電話番号による検索、作成/更新された順番で取ってこれる検索といった利用頻度の高そうな限定的なものを提供する API があると良い。何でも OK なフルテキスト検索 API もあると便利だ。そのような検索によって対象のリソースを見つけ出し、外部から適切な処理を行うことができる。

個人的には指定更新日時より新しいリソースを一括でとってくる API はあるととても嬉しい機能である。(リソースの同期を実現する上で必要)

4. リソースを Insert or Update できる API がある

あると結構嬉しい InsertOrUpdate API。毎回 API で対象のリソースが存在したら更新、しなければ作成みたいな処理を書くのが面倒だ。そんな時には例えばメールアドレスをキーとして、存在すれば更新、しなければ作成を勝手にやってくれる API があると嬉しい。そして ID をレスポンスで返すといった形だ。

当然 Create だけの API で既にあったら例外を吐くような API もあるべきなので、両方あると良いと思う。もっと言えば Web 上ではできるのに API ではできない機能が無いように網羅したいところだ。

4, マスタデータ作成 API の手間を考慮している

例えば複雑な関連のある API である場合、ベースのリソースを作成して、その次に種類のリソースを作成して、最後にようやく目的のリソースを作成できるような API があったとする。

この時に毎回ゼロから組み立てるのは大変なので、ベースとなる部分は開発者の Web コンソール上でサクッとデフォルト値的な感じで組み立てられるようにできているとありがたい。 API で呼ぶ必要があるのは、最後の目的のリソース作成だけで、他は事前に作った固定値 ID を指定すれば良いだけみたいになっていると嬉しい。ゼロから全部作らないといけない API は、そのぶんたくさんのリクエストを送る必要があり、エラーハンドリングのことを余計に多く考えなければいけないので辛くなる傾向にある。あらかじめ最初のマスターデータ的なのは作っておけるようにすれば、このような心配もいらくなる。

5, エラーメッセージが適切

API を組み立てて実験をしていると、うまく API リクエストを送れていないことが頻繁に起こる。そん時にちゃんとしたエラーメッセージが出ていることは良い Web API の条件だ。たまに 200 を返すのにメッセージなしで失敗しているみたいなケースがあったりして、このような場合には無駄に多くの時間を割かなければならなくなってしまう。

これはどこまでエラー処理を考慮しているかってのにもよると思うけど、API 機能として最低限のエラー対策はやっておいて欲しいと思う。

終わりに

Web API を自分で設計される方は、一度有名な Web API を 2,3 個触ってみると良いと思う。その上で理想の API 像を固めた上で制作すれば、きっと上記のような条件は満たしているはずだ。

ちゃんと API の重要性を理解し、オープンな Web API がじゃんじゃん登場してくれば、HTML のリンク並みに繋がったビジネス連携が可能になることだろう。そんな素敵な Web サービスの未来を想像している。

Web API: The Good Parts

Web API: The Good Parts