ボクココ

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

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

終わりに

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

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

Web サービスにおける SSL の選定

ども、@kimihom です。

f:id:cevid_cpp:20180513134708p:plain

先日、自社のサービスを EV SSL へ適用したので、それに至った経緯と SSL について思っていることを記す。

SSL 化の流れ

もはや、今時のサービスで SSL(HTTPS) 化していないWebサービスはほとんどなくなった。ましてや企業毎に重要な情報を保存するケースの多い SaaS などでは HTTPS 化は必ずしなくてはならない対応の一つとなっている。個人のページや 会社HP など、 HTTP でも特に指摘されることがなかったようなサイトでも、SSL を利用することが重要になってきている。SSL を適用していないページの検索順位が下がってしまたり、ページ閲覧時に Chrome から警告表示されてしまうためである。

その流れの中で、もはや私たちが HTTPS を使わない理由が存在しない。今では、 Let's Encrypt のような無料の SSL も登場してきている。最近では Let's Encrypt は ワイルドカードドメイン (*.mysite.com) も HTTPS 化できるようになって、更に SSL を入れない理由がなくなった。

SSL の汎用で出てきた課題と解決

この SSL にはドメイン認証と企業認証そしてEV認証の3種類がある。細かい区別については省略するが、SSL としての信頼性やブラウザでの表示が少しずつ異なる。ただし、ドメイン認証と企業認証の SSL の違いをページ訪問者が見分けるのは困難である。両者を見分けるには Chrome の場合は URL 隣の保護された通信をクリックし、さらに「証明書」の項目をクリックしないと識別できない。さらに、その SSL が企業認証の SSL かどうかは 発行元を調べないといけない。

Let's Encrypt がもたらした「誰もが SSL を使える」という利点は、ウェブがよりセキュアになったという点では歓迎すべき点である。しかし、それと同時にフィッシングサイトのような悪意のあるサイトも HTTPS を簡単に発行できるようになったことを意味する。また、従来は SSL を使っているサイトという時点でセキュリティに対する意識をユーザーに表明することができたが、これからは HTTPS というだけではその意識をユーザーに持ってもらうことはできない。

今までは "ページがHTTPS" ということに対して得られていた一部の利点が、これからは通用しなくなってきているのである。

そこで、本記事のメインテーマでもある EV SSL である。EV SSL を使えば、URL の隣に企業情報を表示することができる。

f:id:cevid_cpp:20180513130632p:plain

ページに訪れた時点で、企業として正式に発行された SSL が使われているということをユーザーに伝えることができる。これにによって、先ほどのフィッシングサイト対策や、セキュリティに対する意識を SSL で表明することができる。実際、この EV SSL の発行には、SSL発行企業からの厳密な審査があり、これが通らないと SSL が発行されないくらい厳密な SSL である。

日本では、金融機関といった本当にセキュリティが大切になってくるページにしか EV SSL が使われていないイメージを持っている方も多いかもしれない。しかし、海外では EV SSL が一般のサービスに使われるようになるまで浸透してきている。例えば以下のようなサービスが EV SSL を使っている。

EV SSL の考慮すべき点

EV SSL を使う場合、マルチドメインを適用できないという重要な性質がある。最近はユーザー毎に独自にサブドメインを持たせるやり方が流行っているが、この方法を採用した時点で、 EV SSL 化は不可能になる。

サブドメインをたくさん持っている大きなサービスも、同様に1つ1つのドメインに対して EV SSL を発行しなければならないため、SSL にかかる費用が無視できなくなって採用していないケースが見受けられる。

確かに、サブドメインでそれぞれのドメインを区別する方法にもメリットがあるので、ドメインの運用に関しては慎重になるべきだ。本当にサブドメインの運用をすべきかどうかとの天秤となるだろう。

EV SSL の今後

誰でも HTTPS 化ができるようになった時代の先で、 EV SSL の重要性がさらに増していくことは間違いない。

私としては、今後は Webサービス であれば EV SSL を使うのが当たり前 くらいなレベルにまでなっていくと思う。今時の Webサービス では決済情報を外部の Stripe や Paypal 等に任せているとはいえ、決済情報を入力することは当たり前になってきている。そうした重要な情報を入力する必要がある Webサービス が、Let's Encrypt などの無料の SSL とほとんど区別のつかない状態であっては、ユーザーに不安を与えてしまう原因となる恐れがある。

海外の Webサービス がどんどん EV SSL を採用しているという風潮の中で、日本でも EV SSL の価値が高まっていくことだろう。

終わりに

今回は Webサービス における SSL の選定について記した。

ぜひこの記事に共感し、ワイルドカードドメインの Webサービス でない場合には、EV SSL を採用してほしい。日本でも、EV SSL の認識が広まっていけば、益々ページを訪れるユーザーのセキュリティ意識も高まっていくと思う。 それこそがフィッシングサイトの撲滅、さらにはWeb の安全化につながっていくと考えている。

改善フェーズにおけるサービス開発の考え方

ども、@kimihom です。GW は全くブログ書いてなかったから、かなり久々の投稿になってしまった。

最近は「サービスの作り方」的なエントリーがちょこちょこ増えてきている感じがしている。良いサービスが出てくること自体は大歓迎なんだけど、 一時的に成功させるよりも、それを成功し続けさせる方がよっぽど難しい ので、継続ができるサービスはもっと尊重されるべきだと思っている。使い始めていただいたユーザーに対して、期待を裏切らない開発を続けないと後発のサービスにどんどんと移って行ってしまうし、意思がなければそのサービスはそのうちすぐに閉じられてしまうだろう。

私自身、そんな改善フェーズに差し迫ってきている中で、現在はどういった考え方でやっているのかについて紹介しようと思う。

コアユーザーに思いを伝える

ここでいうコアユーザーとは、サービスに対しての思いを理解して愛着を持っていただいているユーザーを指す。サービス開発者がそのサービスに対してこだわっている部分と、そのこだわりを完全に理解してくれているユーザーの理想的な関係だ。

そのために、まずは自分たちのこだわりをユーザーに示す必要がある。サービスの特徴を機能として際立たせることも必要だろうし、時には記事を書いたり直接会ったりすることで思いを伝えることもあるだろう。この思想を理解してもらって初めて「サービスの Why」 を理解してくれる。

ユーザーにとってサービスの Why は、サービスの印象だ。私達が Why に背いた開発をした時点で、コアユーザーは共感が薄れていってしまい、コアユーザーでなくなっていってしまう。だからこそ、私たちは Why を伝えた後、 Why を表明/表現するための開発運営をしていなければならない。

私にとって、サービス開発で特に重要視している一つの Why が "シンプルの徹底" である。最初のサービスリリース時は機能が少ないからシンプルな状態に決まってるんだけど、次第に時間の経過や人の増加によって色々な機能が出てくることになる。それら機能を現状のシンプルさを保ったまま、いかに改善していくかってところが特に大事で腕の見せ所だ。"シンプルさを継続すること" が私とユーザーが深く繋がっていくために課した暗黙的な契約である。

  • シンプルだから説明書がなくても使い始められる
  • シンプルだからバグが起きづらい
  • シンプルだから困ることが少ない
  • シンプルだから忙しくならない
  • シンプルだから余計に人が必要ない
  • シンプルだから大胆なチャレンジができる

実際は裏側でシンプルに見せるように相当な努力を続けているわけだけども、ユーザーにとってはそんなことを知らなくてもいいように見えるくらいの関係を目指している。

この "シンプルの徹底" は、あくまで私の作っているサービスに対しての Why なので、当然他のサービスでは他の Why があることだろう。サービス運営者が信じていることは色々あるはずで、それをちゃんとユーザーに伝えて理解してもらうことを目指していきたいところだ。

地味な改善を尊重する

サービスを作ってローンチした頃は、当然 何かしらの今までになかったものってのがあるわけで、そういう新しいものを開発する楽しさがあったはずだ。

しかしサービス改善期に差し掛かると、そのようなワクワクするような開発の体験ってのはほとんどしなくなる。既存機能のパフォーマンス改善だったり、バグ修正、ちょっとした便利機能の実装 といったようにジャジャン!ってのをサービスローンチの時以上に出すのは激しく困難である。それを認めて、地味な改善を尊重しなければならない。改善フェーズに入ると 0->1 が得意な人にとって大きな苦痛が待っている。開発中のワクワク感を 0->1 のフェーズ以降で持ち続けるのはほぼ不可能だと思うべきだ。

ただ単に「新しい技術で何かサービスを作りたい」レベルの意思だと確実にそこで止まる。そして他の新しいサービス開発に浮気をして、既存サービスの成長は止まり、それ以上の成長はしなくなる。そうじゃなくて「自分の作ったサービスが多くの人に使って欲しい」って思いで始めたなら、サービス開発してちょっと使われ始めた程度のレベルで満足はしないはずだ。サービスが使われるようになったフェーズでは、開発の時の楽しさは減るけどそれ以外で素敵なことが待っている。実際にユーザーに会って話ができたり、機能開発のフィードバックをもらえるのである。運営しながら感謝の言葉などが入ってくることに喜びを感じるようになろう。

てことで地味な改善ができるエンジニアが尊重されるべきであり、0->1 開発のエンジニアだった私達が次に目指すべき理想像だと思う。改善エンジニアは一見すると目立たないかもしれないけど、5秒の速度を1秒に改善したら素晴らしいことだし、使いづらかった機能をより使いやすくした改善をしたら賞賛されるべきなのである。改善の話をブログやイベント登壇ではシェアしづらいから、どうしても目立たない存在ではあるんだけど、改善エンジニアがいなければ、 一時的に成功させるよりも、それを成功し続けさせる っていう本当に難しいチャレンジを達成することはできない。

私はインターネット業界に蔓延する一発当てて大成功っていう風潮は良くないと思っていて、創業後、何十年もずっと尊敬され続ける企業こそが本当に素晴らしい企業であるってことに目を向けたいと思っている。果たして、今の日本でそんなインターネット企業があるだろうか。私はそんなインターネット企業が思いつかない。一時的に上場したりして人気になったとしても、経営者や担当者がどんどん変わることで Why が変わり、当初とは違うようなサービスになってしまうケースがあとを絶たない。

インターネットの世界ってのがそもそも新しく始めても成功できる可能性のある業界ってことで、短期的な利益を目当てに人が多く起業しているのかもしれない。でも、サービス改善期においてその考え方をするようだとサービスがごちゃごちゃになって、後発のサービスにどんどん抜かれていくことだろう。結果は目に見えている。

終わりに

今回はサービス作ってユーザーを抱えるようになってきた後の話をちょろっと紹介した。

こうした地味な改善の中でも技術的な部分でどうやって向上を保ち続けるか。それに関してはまた次以降のブログで私の取り組みやアイディアを紹介したい。

目立った新機能ばかりを作るのではなく、コアユーザーのための改善を続けられるサービスが増えていくことに期待したい。少なくとも私のサービスはそうであり続けたい、いやあり続ける!

WebRTC で録画した動画の編集をFFmpeg で実現する

ども、@kimihom です。

最近は動画とか画像の変換について色々学んでいた。この分野も奥が深く、やりがいのある分野だ。てことで本記事では FFmpeg を使った動画編集の基本について備忘録がてら記していこうと思う。

WebRTC 録画の課題

WebRTC で録画すると、webm というブラウザに優しい? フォーマットで録画/録音される。当然、このまま <video><audio>タグを使えばそのまま再生できるのだけど、大抵は WebRTC で撮った動画を編集してから Youtube などに上げられる形式に変換したいよねってのがある。この場合例えば webmmp4 などに変換しなければならない。

さらに、WebRTC は 各メディアで別々の webm 形式で保存されるため、動画と音声が別々のファイルとして保存されてしまう。これも、当然ビデオとしてみるなら組み合わせたいところである。

そこで webm 形式で落としてきた動画/音声ファイルを組み合わせて Youtube などに上げられる動画を作っていこう。

FFmpeg

動画編集では FFmpeg が一般的に使われているようである。最初はその名前すら知らなかったけど、実際に使ってみると本当に色々なことができる素晴らしい動画編集ツールだった。

FFmpeg は、コマンドラインで動画の編集を可能にしてくれる。コマンドベースでできることによって軽く実行できるし、コード化しやすいというメリットがある。巷の動画編集の Web サービスのほとんどはこれを使っているんじゃないかな?実際、Qiita などでも FFmpeg に関して多くの記事を見かけることができる。

インストール方法などは読者の皆様ならきっとすぐできると信じているので省略する。以下に使い方のサンプルについてご紹介していく。

動画と音声を結合する

まず WebRTC で最も解決しなければならない動画と音声の結合と mp4 形式の作成だ。

ffmpeg -i video.webm -i audio.webm -map 0:0 -map 1:0 -vcodec libx264 -acodec libmp3lame output.mp4

-map 0:0 -map 1:0 てので 0つ目のファイルの、0番目のストリームと1つ目のファイルの、0番目のストリームをマージする という命令になるそうだ。コーデックにも色々と種類があるけど、上記コマンドでは動画H.264 と 音声mp3 の形式で組み合わせている。

これだけで mp4 の動画ができる。

動画の切り分け

無事できた動画を、パート毎に分割したいってことがあるだろう。そんな時は以下のコマンドを実行しよう。

ffmpeg -ss [開始位置(秒数)] -i [元動画] -t [切り出す秒数] [新しい動画]

1つの動画に2つを重ねて表示

例えばカメラで配信しつつ、デスクトップのスクリーンシェアをしていた場合、2つの動画を1画面で表示したいということが出てくる。右下に重ね合わせて出すイメージだ。

この場合、2つのステップが必要になる。今回のサンプルは 320x240の動画がメインであって、80x60の動画が右下に出てくるようにする場合の方法。

1 動画をリサイズ

ffmpeg -i video1.webm -s 320x240 video1_resized.webm
ffmpeg -i video2.webm -s 80x60 video2_resized.webm

2 組み合わせ

ffmpeg -i video1_resized.webm -vf " movie=video2_resized.webm[inner]; [in][inner] overlay=240:180 [out] " combined.mp4

参考資料

FFmpeg に関してはググると色々な人が記事を書いてくれているからサンプルは見つけやすい。それを後は自分のやりたいようにどう最適化していくかってところだ。 FFmpeg で一度エラーが出ると原因を見つけるのが非常に難しい。これはまだ私が触り始めたばかりだからかもしれないけど。

FFmpeg の公式ドキュメントが一番間違いないけど、オプション全てが載ってるので何使えばいいのかわからないのが難点だ。ネット上に乗っていたサンプルコードをまずは実行してみて、それぞれの詳しい意味を公式ドキュメントで学んでいくってのがいいと思った。

終わりに

最近 ちょっとだけ動画編集についてかじり始めて、その備忘録的な感じでまとめてみた。

現在、2つの動画を1つに連結する(concat) 方法を調べているけど、うまくいかなくてどハマり中。。2つの動画のサイズやエンコード形式など、うまく条件が合わないと難しいのかもしれない。

この動画/音声の編集スキルは今後より大事になってくると思うので、よければ FFmpeg を触ってみていただけたら幸いだ。

Heroku Meetup で Heroku 運用フェーズについて話してきた

ども、@kimihom です。

f:id:cevid_cpp:20170929233715p:plain

今日、Heroku Meetup #20 "Heroku Yacht" が開催されて、そこで登壇した資料と、おまけ的な感じで資料の裏に込められた思いについて記していく。

登壇資料

発表資料の補足

Heroku を使っていても、サービスのフェーズごとに意識して取り組まなければならないことは変わってくる。とりわけ、これからサービスを作る/作ったばかりって状態の人に、運用フェーズの話をしていても全く意味がない。運用の整備する時間があったら、とにかく作ったものを顧客に見せ、反応を見ながら改善していくほうが重要だ。開発初期フェーズでのお話は以下の記事に私の考えを書いているので読んでいただけたら幸いだ。

www.bokukoko.info

それなりにユーザーを抱えるようになってきて、私が特に大事にしてきたのが「フロントエンド」の開発だ。つまり HTML5/JavaScript の活用である。そろそろエンジニアの皆さんは気づいてきたかもしれないが、より早く快適なサービスを実現するのに関して、フロントエンドのウェイトがますます上がってきているというのがある。フロントエンド側のキャッシュや裏で動くWorker などを駆使し、最高のユーザー体験を目指すことが可能だ。

かといって、私は Angular や React などを始めとした SPA フレームワークにはほとんど興味がない。それらライブラリの最新アップデートやバージョンアップに追従したところで、新しくできることなんて何もないのだ。根本である HTML5 を理解し、使いこなせるようになって初めて 今までできなかったことやフロントエンドの高速化を実現できるのである。

私の運営するサービスは、最高のユーザー体験を実現するために HTML5 のテクノロジーを数多く採用している。そしてフロントエンドの開発に注力できるようになったのは、間違いなく Heroku という PaaS の存在のおかげだ。私はバックエンドの心配を、Heroku や各種アドオンのスペシャリストに任せ、そもそも問題が起きにくい設計や運用をしてもらっている。それでも問題が起きれば、サポートもしてくれる。そんな環境は IaaS で自前で構築したら手にできない代物だ。

今回紹介した HTML5 の中で深く言及したのが ContentEditable という技術だ。ContentEditable は、 HTML5 の中でも地味だけどユーザー体験を極めたい人にとっては極めがいのある技術だと思っている。ContentEditable の大きなハードルをくぐり抜けた者だけが、最高のユーザー体験を提供できる。くれぐれも、この技術を初期開発フェーズで採用してはならないということに注意しよう。興味がある場合は以下の記事を参考にしてみてほしい。

拡張テキストエリアを ContentEditable で実現しよう - ボクココ

そして、管理ツールの開発に時間をかけるのは無駄だということも伝えた。そんなのの開発に時間をかけるのではなく、Heroku Dataclips を充実させて、より柔軟なデータ収集の方法(SQL)を、管理ツールを使う人たちに教えたらいいのではないか。この試みに関しては私も道半ばだけど、今作の "誰も SQL が使えるようになるべき"という風潮に乗っかって、 Heroku Dataclips は今後 より重要な立ち位置を示すようになると思う。

私は常日頃からエンジニアは最小限のチームで構成されるべきと説いてきている。この主張はこれからも変わらない。少人数で構成されたドリームチームから生まれたプロダクトは、彼らの溢れ出る思想がプロダクトにそのまま反映される。そんな人が目を輝かせながら語ってくれる発表を聞ける日が来るまで、これからも活動を続けていきたいと思う。

終わりに

今回は参加いただいた方も、自分でサービスを開発しているという気概のあるエンジニアの方が多く、私自身も感化された良い Meetup だった。サービス開発に対して本気になって自分の可能性に挑戦する人のプラットフォームとして、Heroku や Heroku コミュニティが盛り上がっていったら嬉しいなと思う。

Heroku を使って生まれる次の Hero は、そう、 "あなた" である!

Stripe における月初決済の実装

ども、@kimihom です。

f:id:cevid_cpp:20180408161239j:plain

最近は Stripe でのサブスクリプション決済の実装について色々調べているので、その現状についてレポートする。

実装のユースケース

では早速、よくありがち(?) な SaaS での月初決済を例に挙げて、それに対応する方法についてご紹介する。

今回は、日本の財務管理を根底から変える、財務管理 SaaSをローンチする予定だと仮定しよう。その財務管理 SaaS は、3つのプランから成り立つ。今回はそのうちの Basic プランを月額2,000円でセットすると仮定する。利用企業は、その Basic プラン料金に加えて、特定の連携機能を使った分だけ課金される従量課金を提供するとしよう。つまり、月額2,000円 + 使った分だけの従量課金 を請求する料金体系となる。

月額2,000円だけの SaaS なら、めっちゃ簡単に実装できるのだけど、使った分だけの従量課金を追加しようとした途端に手間のかかる実装になる。月ごとに異なる金額となるし、前月の従量課金分をできる限り早く回収したいと考えるはずだ。てことで従量課金分は月初に決済すると想定する。これを実現する方法としては、2つ考えられる。

  • プランの決済タイミングは顧客ごとに異なり、従量課金の部分は別で月初に決済する。つまり2つの決済タイミングを分ける
  • 月初にプランの決済と従量課金分を合計した金額を決済する

2つ考えられると書いたけど、どう考えてもやりたいのは2つ目の方法だろう。そして、この月初に統一して決済する方法を、Stripe は最近になって提供するようになった。Congrats!

てな訳で、固定金額 + 従量課金な SaaS のユースケースに沿った実装サンプルを以下にご紹介する。

定額 + 従量課金の実装

さて、まずは月初に金額を統一させるためには、全ての Subscription の決済タイミングを月初に統一させる必要がある。これに対して、最近 Stripe API (2018-02-28)で登場した billing_cycle_anchor を利用することで実現できる。

subscription = Stripe::Subscription.create(
  customer: self.stripe_customer_id,
  items: [ {
    plan: plan_name
  } ],
  prorate: true,
  trial_period_days: ENV['TRIAL_PERIOD'],
  billing_cycle_anchor: DateTime.now.next_month.beginning_of_month.to_i
)

上記の実装で、「Trial 期間を設けつつ、アップグレード直後に billing_cycle_anchor までの日割り料金を決済し、それ以降は毎月月初に決済する」というフローを構築できるはずだ。ひとまず、これで定額の方の決済はクリアできる。ちなみに、trial_period_days を設けると、対象の Customer にクレジットカード登録がなくても、この Subscription を登録することができる。Trial 期間の間にクレカ登録してくれれば OK という流れを作れる。

続いて従量課金の部分に移ろう。これを実現するために、Stripe では "Invoice Item" ってのを提供してくれている。まさに、Subscription に対して追加で料金を請求できる仕組みである。

invoice = Stripe::InvoiceItem.create({
  amount: amount,
  currency: currency,
  customer: self.stripe_customer_id,
  description: description
})

上記の実装で、「対象 Customer の次の決済タイミングで、追加の料金を請求する」ことを実現できる。つまり、Subscription の月初の決済時に従量課金分を追加請求できるようになったってわけだ。上記の InvoiceItem の追加を、月初の定期決済の前に実行すれば良いことになる。めでたしめでたし。

この InvoiceItem がなかなか便利で、InvoiceItem にはマイナスの値をセットすることもできる。これは Subscription における Coupon の概念に近いんだけど、InvoiceItem の場合は顧客ごとにその割引金額を変えることができる。個人的には Coupon より柔軟性が高いので、InoviceItem を積極的に利用するのがいいのではないかと現時点では思っている。

その他の懸念事項

さて、それ以外で検討する項目について考えてみよう。

決済タイミングでのメール送信

まずは、決済成功/失敗時に顧客にメールを送りたいってことが考えられる。Stripe では、便利なことに決済成功/失敗/返金/カード期限間近 のタイミングで Stripe 側で用意した文言で自動でメールを送ってくれる機能を提供している。もちろん、言語を日本語に指定することも可能だ!てことで、 Stripe のレールに乗ればそもそもメール送信のために Webhook を使う必要がなくなる。

ただ、例えば顧客ごとにメール文言や言語を変えたいだとか、顧客だけでなく運営側にも通知を送りたいなどの細かい話になってくると、どうしても Webhook が必要になる。そこで問題が出てくるのが billing_cycle_anchor を指定したことによる、Webhook の負荷問題だ。月初に ほぼ同じタイミングで一気に決済が走るため、Webhook が大量に飛んでくる問題が懸念される。これに対して聞いた噂によると、それなりに分散して Webhook を送ってくれるらしい。ただし、もしやる場合は Webhook 先を AWS Lambda などの Function as a Service 側に向けておいたほうがいいだろう。

失敗時の再決済

決済失敗時の再決済も、Stripe が勝手にやってくれる。例えば"定期決済に失敗した場合は3週間の間で3回トライする"などの設定をしておけば、Stripe 側で最適なタイミング(機械学習を使っているらしい)で再決済をおこなってくれる。そしてその失敗に対しても Stripe がメールを送ってくれる。それら再決済のトライに全部失敗した場合、定期購読をキャンセルしたりそのままにしたりするのも Stripe がやってくれる。

領収書のPDFダウンロード

SaaS を運用していると、領収書を PDF でダウンロードしたいって要望をよく受ける。これも、Stripe で自動で送ったメールの中に、"ブラウザで表示" リンクがあるので、そこをクリックして 印刷で PDF としてダウンロードすればいい。てことで無駄に PDF ダウンロードの機能を実装する必要もなくなる。自前でメールを送る実装にすると、 "Webで表示" の項目がないので自前で実装する必要が出てくるかもしれない。

終わりに

今回は Stripe での SaaS 決済についてありがちな設計とそこで出てくる課題解決について書いた。billing_cycle_anchor 登場以前は、定額+従量な決済を設計しづらかったけど、このオプションの登場でより柔軟な決済の設計に対応できるようになったと思う。

Stripe はいいサービスだけど、個人的には 当分の間は全く使わないであろう Radar注文Connect, Apple Pay などのナビゲーションが常に左に表示されているのが ちょっと複雑さを醸し出してる感じがしている。たくさん機能が出てくるのはいいことだけど、シンプルと複雑のバランスについて考えさせられる。あと SQL で決済情報を収集できる最高にクールな機能である Stripe Sigma のナビゲーションなくなったけど、なんでだろ?

ひとまず今後はちょいちょい Stripe ネタも絡んでいく予定なので、期待していてほしい。

Ruby on Rails の魅力と思想

ども、@kimihom です。

私は Web フレームワークは Ruby on Rails を利用している。かれこれバージョン2.2 の頃から使い続けているので 7年以上になる。そこまでして私が Ruby on Rails を使い続ける魅力について個人的な想いを記していく。

Rails の作者 DHH と彼の環境

Rails の作者として有名な DHH(David Heinemeier Hansson) という名前は、 Ruby on Rails を触ったことがあるなら必ずや聞いたことがあるだろう。しかし、彼のいる会社 Basecamp がどんな想いでどんなことをしているかを知っている人は案外少ない。

Basecamp はプロジェクト管理の SaaS である。今や世界中に顧客を抱える超有名サービスであり、Basecamp は Ruby on Rails の最新版をプロダクトに反映され続けている。そしてこの Basecamp という会社は、資金調達をせずに自己資本でサービスを成長させた Bootstrap の事例として最も有名なサービスの一つである。資金調達をせずに、大成功とまで言える領域にたどり着けた背景には Ruby on Rails が深く関わっていることに間違いはない。そして、DHH の想いが Basecamp の成功と Ruby on Rails の思想に深く関わっているはずだ。

Rails は誰のためのフレームワークか?

私が7年以上 Ruby on Rails を触り続けている立場として、以下の考察を記していく。

Ruby on Rails は、極少人数(理想は一人) がサービス開発するのに理想的なフレームワークであり、それを目指し続けていると考えている。Ruby on Rails の敷かれたレールに乗ることで、一気に目的地に到達することができる。

特に大事なのが極少人数で構成されたチームのためのフレームワークであるという点だ。 3人よりは2人がいいし、2人よりは1人で Ruby on Rails を扱うのがいい。関連する人が多ければ多いほど、逆に DB と View が密になっていることで開発効率を悪くさせてしまう。大人数での開発だと Ruby の柔軟な書き方であったり、Ruby on Rails のレールに乗ったプログラムの書き方が、逆にマイナスの側面を与えてしまうだろう。

DHH の会社や思想を理解せずに、単に "Ruby on Rails はみんな使ってるから自社で使う" という判断をすると手痛い思いをする。そして、そんな人が Ruby on Rails 自体を批判するようになる。「Ruby そのものが自由すぎる」だとか、「他人の書いた Rails コードを読みたくない」だとかいう批判をよく聞くけど、そういった声は基本的に5人以上で Rails を触ってしまった場合に起きる問題である。これをしている時点で、私からすれば Rails の思想に乗っ取った開発をしていないのではないかと考える。

Rails は、少人数であり続けられるチームが常に理想の速度で Web アプリケーションを開発・維持するために理想なフレームワークであり続けるだろう。 例えばスタートアップのように人数が急激に増えるような環境においては、必ずや Rails を使っていること自体に問題が発生していくことだろう。この機能を実現するのに Rails のレールから外れなきゃいけないだとか、View と DB が密になり過ぎて担当を分けられないから ActionView を使わないといった選択をするってわけだ。その意味で、5人以上の開発チームで Ruby on Rails を使うのはナンセンスだと考えている。それだけの規模で開発するのであれば、Rails ではなくフロントエンドとバックエンドが最初から疎になっているものを選ぶべきではないか。

ここで一つ大切な事実をお伝えしたいのが、DHH 自体が人を急激に増やしていくスタートアップそのものを否定することが多いということである。これは日本でなぜかあまり知られていない大切な事実である。

Ruby on RailsのDavid Heinemeier Hanssonが語るお金と幸福の関係 - ログミー

にも関わらず、急激に人数を増やしているスタートアップな方が Ruby on Rails を使って、「Rails 辛い」といっているのを見ると、私からすれば滑稽な姿にしか見えないってわけだ。

Rails のホスティングの選択

そんな Rails をホスティングするには、やはり Heroku がおすすめだ。Heroku は Hero + Haiku の造語であることはよく知られている。まさに、「5・7・5 として少ない文字(機能)を磨き続ける人を Hero にする」という考えは、Ruby on Rails の少人数でサービス運営する人の考えと素晴らしくマッチするのである。

今では色々な言語やフレームワークがサポートされているけど、Heroku 初期は Rails のホスティングサービスであったことからも、Rails の思想から生まれたホスティングサービスであることがわかるかと思う。

終わりに

巷では、Rails を使った開発プロジェクトのお話がよく出てくるけど、案外 Rails の作者や Rails の思想について語られることは少ない。

Ruby on Rails の What(何ができるか) よりも、Why (なぜ Rails が存在するか) について深く知る機会があればいいなと思う。Why を知った上で Rails を使えば、本当の意味での Rails のファンになることができよう。