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

ボクココ

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

英語を学ぶ動機を改めて確認する

ども、@kimihom です。

定期的にやってくる英語学習のモチベーション。その波がやってきたのでブログに書くとする。

現在の最大の動機は、再来月の Twilio Signal の参加にある。これは毎年サンフランシスコで開催されるわけだけども、このイベント参加を実りあるものにするためには当然英語を正しく聞き取れるようになる必要がある。

ってことで何度目かわからんけど再び英語熱が出てきた。

自分の現状

前職で TOEIC を強引に勉強させてもらったおかげで、全くできないレベルからそれなりにできるレベルにはなった。 全盛期で TOEIC 780 くらいなので今は 730 くらいかな。

地味に頑張っているのが英語のブログ。ちょっとした英語のセンテンスを1年以上毎日欠かさず書き続けている。今日やったことや感じたことを日記として記している。これのおかげで、基本的な英語であればポンポン喋れるようにはなっているはずだ。ただし長く続けられるようにするために、誰かにチェックしてもらったりとかそういうのをしてもらわずに、ただ自分なりの英語を書き殴っているだけなので、文法ミスとかは多くあるだろう。とはいえそういうの気にするより自分の言いたいことを言えるようになるって方が大事だと思っているので、1年以上続いているのはとても良いことだ。

さて、海外のカンファレンスにおいてライティングやスピーキングは自分が登壇するわけではないので、現地で誰かと話す時くらいになってしまう。カンファレンスにおいて大切なのは当然リスニングだ。

TOEIC 780 レベルなので、一般的な受験英語みたいなやつはそれなりに聞き取れるけど、ネイティブになると途端についていけなくなる。あの受験英語とネイティブ英語の大きな隔たり、あれなんなのほんとw そこの高すぎるハードルに私はいつまでも打ちのめされているのである。

英語ができるようになったら

エンジニアとして英語ができるようになったら、当然いいよね。技術の最新情報は常に英語からだ。わざわざ日本語に翻訳される前に、その情報を得ることができる。思った以上にそれはめちゃめちゃ得なことで、例えば今まで超絶面倒だったことが最新技術を使えばパッとできるようになっちゃったりするわけ。そんなことが日常茶飯事なのがこの世界。

今後はグローバルなサービスとの戦いになるのは必至だ。今でも海外のWebサービスやアプリがどんどん日本にやってきて、侵食されてきている。それはそれでいいことなんだけども、私個人としてのエンジニアリングと世界でやりあっていくためには、まずは共通言語である英語をちゃんと身につけなきゃいけない。自分の作ったサービスも世界に目を向けて作っていくことで、世の中に必要とされるサービスとなり続けることができる。

基本的には web 上にあがっている情報を理解する能力である “リーディング” が求められる。これに関しては自分もそれなりに鍛えてきたつもりでいて、技術英語であれば特段困ることはなくなったし、英語の文章でも目をそらさずに読むようにはなった。最悪 Google 翻訳もあるし、問題ない。

でも"読める"ってだけでは最新および未来を知るのは難しく、"聞き取れる"ようにならなることで得られるものだと考えている。読めるってのはつまるところ文章化されたものを読むことになるので、一歩遅れるからだ。例えばカンファレンスでしゃべっていることを聞き取れるようになれれば、最新情報と未来のことまで知ることができる。

あとやっぱり懇親会でどこの国の人かわからない人と喋ってみたいよね。「君はどこからきたんだい?」「Twilio を使ってどんなことをしているのかい?」 そんなトークをしてみたい。 Twilio ってめちゃめちゃ便利なのに、日本では まだまだ盛り上がりに欠ける部分があるので、海外の先端を突っ走る人たちと情報交換をしてみたいと思う。これには相当の勇気がいることだけども、一歩ずつ英語を学んで自信をつけていくしか方法はないだろう。

勉強の模索中…

さて、アメリカに行くまでにまだ時間はある。英語の勉強を頑張っていこう。

去年の Signal のビデオを Youtube で見たり、丸暗記した DUO をシャドーイングしてリスニング力を鍛えたり、音読パッケージトレーニングで基本的な英語をリピーティングしたりしてコツコツ学んでいる。

DUO 3.0

DUO 3.0

ぐんぐん英語力がアップする音読パッケージトレーニング 中級レベル(CD BOOK)

ぐんぐん英語力がアップする音読パッケージトレーニング 中級レベル(CD BOOK)

だけども、なかなかのツラミを感じる次第である。これを2ヶ月続けられる自信は正直ない。どうにかしなければいけないと思っている。

レアジョブとかやってみたけど、あれも成長を感じられず半年と続かなかった。そう考えると今回の勉強もまた Signal が終わったら止まってしまうのだろう。そうなる前に、毎日書き続けている日記のように寝る前にリスニングをするっていう習慣をつけられるような何かを探してみようと思う。

やろうと思っている時にやる。そうしてちょっとずつでも英語ができるようになると信じている。

(続編)

ポッドキャストを勧めてくれたので、面白そうな英語のポッドキャストを登録してみた。寝る前とか電車乗ってる時とかに聞くようにしてみよう。 ググってお勧めってあったのを適当に追加しただけなので、 Rails とか Startup とか その他諸々いいのあれば追加していきたい。

RR Episodes

Giant Robots Smashing Into Other Giant Robots

5by5 | Quit

Bootstrapped Web - The podcast for founders bootstrapping their startups online

開発手法を学ぶことに意味を感じない件について

ども、@kimihom です。

開発手法について議論されたり、発表するような場があったりする。例えば “弊社ではアジャイル開発手法を用いて最先端の開発を実践しています。” 的な話ね。最近はアジャイルじゃなくて何て言うのかよく知らないけども。 それらの話に関してなぜ私が意味を感じないと思うのかを書いていこうと思う。

事前に一つ注意していただきたいのは、私は開発手法に関する話は1,2冊程度しか読んだことがない。だから開発手法を極めればこんなことができるようになる!みたいなのは是非教えて欲しい。開発手法に関する本を読んで、それが全く見えなかったから興味が沸かなかったので。

それより実際に開発しようぜ

基本的にあまり開発をしない方々が、開発手法に関して話しているような感じがする。開発しない立場でチームの開発をとりまとめる立場であるために、何か良い方法を模索している感が漂ってくる。はて開発手法通りにやったところでチームの技術力が上がったり、良いプロダクトができるのだろうか?他のプロジェクトのやり方を真似したり参考にしたところで、本当に自分たちの開発手法とマッチしているのだろうか。

私は技術力のない集団が先端的な開発手法を取り入れれば良いプロダクトができるなんて思わない。反対に技術力のある集団が、開発手法を学ばなくても良いプロダクトは確実にできると思っている。

例えば開発のできない集団がリリースサイクルを細切れにして継続的にデプロイしますってことをしていても意味がない。開発品質もテスト品質も未熟なので、中途半端な機能を継続的にリリースするだけだろう。それだったらじっくり設計をやってレビューもらって開発してってので1ヶ月時間をかけたほうがいいはずだ。テスト駆動開発やってますって話をしたところで、中途半端なエンジニアが適当なテストコードでカバレッジを満たしていればそれでいいのだろうか。優秀なエンジニアがやるからこそそういう開発手法ってのは意味が出るのであって、ただ単に開発手法だけを学んでプログラミングが不得手な集団がやっていたら何の意味もない。無駄にガチガチのコードになって逆に変更に柔軟に対応できない鎖に結ばれたようなシステムになるだろう。プログラミングをたくさんやってたくさん失敗して学んでいかない限り、開発の理想を実現するのは困難だ。

開発できる人ってのはちゃんと設計してプログラミングしてテストしてってのを繰り返して顧客に価値を届けるってことを当たり前のようにやっている。んで、そういう顧客に価値を届ける開発をたくさんやった経験をした人こそが、開発手法で本来目指していると思われる理想的なチームに次第になっていくのではないだろうか。例えば繰り返しデプロイをやってきた経験を通して、そこは自動化できるよねだとか、毎回同じテストを手動でやってたら、ここはテストコード書いてみようだとか勝手になっていくものではないか。開発手法の理論から始めた人では本当にテストコードを書いたほうがいい理由なんて見えてこない。テスト書こうぜ!って言って同意してくれるのは、実際にテスト書くことに意味を感じたことのあるくらいプログラミングと手動テストをたくさんやってきた人のはずなのだ。

つべこべ言わないでまず開発しようぜってのは、開発し続けた先にこそ、自分たちだけの答えがあるのではないかってことが言いたいからである。そして開発手法を勉強する時間があるくらいなら、プログラミング全般を学んだり、そもそも何かを作るてことをした方が圧倒的に大切だと思うのである。

開発の経験こそが、次なる素晴らしいプロダクトを作り上げる条件だ。 私は実際そう信じて続けてきたことでより良いプロダクトを作り上げることができた。だからこの方法は正解だと今では思っている。

チームとしての開発よりも自律的な開発を

チームとしてみんなで1つのを開発していこうぜ的なアプローチって非常に難しい。何かするたびに変更が入って、メンバーと確認してどうするか決めて・・。みたいな流れが発生することだろう。

こんなことになるくらいだったら優秀な1人のエンジニアが開発したほうがよっぽど早くいいものができたと言われるのがこのパターンである。実際1人で開発するってのは本当にスピーディーに良いものが作れる。では大人数で開発するってことで少人数で開発するよりもパワーが生まれるのはどんなときだろうか。

私の一意見に過ぎないけども、自律的な組織こそがそれを可能にすると考えている。つまり、このシステムは1~3人のあなたたちだけでお願いね と完全に分離させるやり方だ。特に web/api/スマホ などで少人数で分担し、最終的に一つのプロダクトを作り上げるような組織がいいんじゃないかと思う。そうすれば一人一人が主体的になってそれぞれが開発に集中できる環境が生まれる。

結局は優秀な少人数で開発すれば OK って話になってしまうんだけど、結局そういうことだと思う。だからこそ、それぞれが優秀なエンジニアになるためにまずはプログラミングをひたすら学び、開発し失敗しよう。やがてチームごとの開発手法ってのは勝手に生まれてくるものなのだから。今回は言いたかったのはそこんところ。

終わりに

今回は開発手法に関するお話が出てくるたびにモヤってたのでそのことについて書いた。

皆さんの意見を聞かせていただければ幸いである。

私が社内勉強会を好む理由

ども、@kimihom です。

うちの会社では、月一で社内勉強会をやっていて、それが個人的に毎回楽しみなイベントになっている。社内勉強会の素晴らしさをちょっと語らせていただきたい。

勉強会のきっかけ

実は私は大学生の頃から勉強会をやっていた。研究室をまたいで自分の勉強した特定の技術に関して情報をシェアし、議論する。そんな場が好きだった。それは自分が一番興味のある内容について熱く語ることが楽しかったし、誰かの発表を聞いてそれに関して話をするのもまた素晴らしいもののだった。

大学生の頃に興味のあった技術の勉強会があって、そこに参加してみたことがきっかけだった。周りは社会人ばかりだったけど、それぞれの体験や思いについて発表している人たちを目の当たりにした。初めての勉強会の参加ですっかり私はその魅力に気づき、大学でも友達を集めてやってみようとなったものだった。

ありがたいことに、私の提案に乗ってくれる人が 4,5 人いた。それだけで十分だった。週に一回、空いてる教室を使って事前に決めたテーマで勉強した内容をみんなに共有する時間を作った。ありがたいことにみんな参加し続けてくれた。主催者のやる気さえあれば勉強会はいつでも続けられる。卒論が忙しくなってしまった頃に勉強会は終わってしまったが、長々と続いた素敵な時間だった。

社会人になっても、自分は定期的に勉強会に参加していた。ただ社会人の参加する勉強会はいつも聞く側に回ってしまって、それはそれでいいんだけどもやっぱり大学の頃のように自分の思いを語る場も必要だと感じた。

今ではいろんな場所に登壇させていただいているけど、新米エンジニアの頃は自信がなくてなかなか手を挙げることができなかった。

そうして今に至る。

社内勉強会

今の会社では毎月サポート勉強会を開催している。社内勉強会ではあるが社外に公開しても問題ない情報なので、外部の方が参加できる枠も少し用意している。サポートツールを提供する立場から、その業界や自分たちのサポートの改善に活かそうってのが主な目的だ。

このような勉強会の場合、社外の参加者が0人でも全く問題ない。社内の自分たちが成長し、仕事の改善に活かすための勉強になれば OKという明確な勉強会の開催の目的があるからだ。

社内勉強会では「失敗したらどうしよう」とか「いいプレゼンにしなきゃ」とかいった余計なプレッシャーがないため、毎回の発表を通じて常に新しいチャレンジを実行できる。それがまた素敵なんだよね。前の勉強会では一発笑いを取ろうとして見事に滑った経験をしたりもした。これはこれで貴重な経験になって、やってよかったと心から思える。

社内勉強会だからこそできることがある。他の外部の勉強会だと各社の方向性や理念など当然違うし、そこで全員が完全に共感してもらうなんてことはできない。でも社内勉強会なら、同じ方向に向かって一緒にビジネスをやっている関係なので思い切って夢や理想を語り合えるのだ。余計な飾りごとをする必要はない、自分の学んだことや考えたことを率直に語れば良いのである。

私の理想の勉強会は、映画「風立ちぬ」で新しい飛行機について語り合っているあのシーン。予告編ではワンシーンだが 2:21 くらいのところだ。 もし興味あれば全編見て欲しい。今日は 3/11 ではあるけども、この映画はそこから復活していくための勇気を与えてくれる。そう思っている。

始めてみよう

勉強会を開催するのってめちゃめちゃ簡単。ただ単に場所と時間と発表者を決めるだけ。

自分が日頃からどんな思いを持っているのか、思い切って話してみよう。それが同僚に伝われば、日常の業務をより気持ちよく仕事できるだろう。チームワークをより強められるし、同じ目標に向かって頑張って行こうって気になれる。社内勉強会にはそんな魅力があるのだ。

もしそれが社外に公開してもいいような内容なら、外部の参加者も受け入れてみよう。そうしたらより発表に身が引き締まっていいものを作ろうって気になれる。経験則ではあるが、社内勉強会でも来てくれる方ってのはかなり熱い思いを持った素敵な方であるケースが多い。

“勉強会を採用の告知のために参加する。” そういう目的ってのは実は本来の勉強会の目的ではない。もちろんそれはそれで目的を達成するのにいい方法なのかもしれない。けれども時には心から勉強会を楽しむ時間を作ってみてもいいのではないだろうか。発表者が目を輝かせて夢を語る。そんな発表を目を輝かせて聞く聴衆。私にとって最高の勉強会はそんな姿だ。

一人一人の “学びたい” という純粋なモチベーションから生まれた勉強会に、私は今後も参加していきたいと思う。

コードを美しく保つためのたった一つの方法

ども、@kimihom です。

とあるイベントでエンジニアの方々と話していて話題になった “クリーンなコード” について書いていくとする。

結論から言うと、コードを書かない のが最も美しく保つための条件だと考える。

サービス設計レベルでの"美しさ" を極めよう

いくら優秀なエンジニアがサービスを作ったところで、優秀でないプロダクトマネージャーの元で開発をしてはいいコードを保つことはできない。優秀でないプロダクトマネージャーは、機能の多さで他社と差別化をしたり部下の仕事を作ろうとする。この機能が他社サービスにはあるから、うちにも取り入れよう。そんな自社サービスの思想を全く考えない機能をエンジニアに要求するのだ。

その時点で、どんな優秀なエンジニアでも作ったシステムは確実に複雑になる。例えて言うなら、小説家が1冊の本の中にうまく章立てをしてまとめていたのに、全く別の話題をその本に書けと言われているようなものだ。そんな要望があれば、どんなに美しかった本を書き続けたライターでも途端に汚い本を作り上げなければならなくなってしまう。

「このサービスはこのためにあります。」そう明言し既存機能を改善できるビジネス側の人間がいない限り、コードを美しく保つことは不可能だ。これがまずとても重要な前提条件。

某メッセンジャーアプリを見てみよう。基本的に全てのユーザーはメッセンジャーアプリをインストールしたなら、"友達と会話をするため" にそのアプリを起動するだろう。なのにそのアプリ内にゲームだとか情報誌だとかニュースだとか、それらがあってもほとんどのユーザーは使わない。ユーザーにとって"そのサービス=メッセージのやり取り" という明確な意識が根付いているためだ。友達と会話するためにアプリを開いたのに、そこにニュースがあったとして、それを見るだろうか。ほとんどのユーザーは"ニュースアプリ"として切り出されたものを使うだろう。なぜならニュースを見たいと思ったときにそのアプリを開くと言う明確なモチベーションが紐づいているからである。

これは大分類の"機能"ではあるが、小さな意味での"機能"にも同等のことが言える。そのお気に入り機能は本当に必要か?その SNS ちっくな機能は本当に必要か? 軸がブレると手当たり次第に機能追加するというやり方が正当化されてしまう。"開発"した分だけサービスが成長させられると思ってしまう。そんな幻想を抱いている方は、Google 検索や Uber が何故あれだけダントツで成功したか理由を考えて欲しい。"機能追加" ってのは仕事をした感が得られるだけの、何も考えていない証拠である。

機能が大規模になればなるほど複雑になるのは必然だ。コードを共通化したりしていくと、ある機能は動いてある機能は動かなくなる。そんな微調整の連続が始まる。それを嫌がってコードの共通化を行わないと、どんどんコードが肥大化していく。Fat なコードがあると、エンジニアは開発するモチベーションを大きく損ねる。一度でも妥協すると、ドミノ倒しのように崩れていくのだ。第三者がそのサービスの開発担当になったときに、リスクを冒したくなくなる。コードを修正するよりも、新しくコードを追加するという選択に 逃げる ことになる。新しく追加したコードであれば、他の依存関係をあまり考えなくて済むからだ。そんな逃げのコードの連続、そして軸のブレた機能開発こそ、最終的に Fat でメンテナンス困難なコードを生むのだ。

全ては機能を追加することが正義だと思い込んでいる人が最初に生み出す悲劇である。だからこそ、サービスの “Why"、そのサービスは何のために存在するのか をちゃんと理解し、志を持ち続けられる人にしか美しいコードを保ち続けることはできない。

これはサービスを作るエンジニアが優秀かどうか以前の話だ。ちゃんと機能が設計されたサービスであれば、勝手に綺麗になっていくものである。何故なら、闇雲に機能を追加するのではなく、同じ機能を改善/洗練していくことになって既存ソースの修正がしょっちゅう入り、より良いコードにするための仕組みが意図せずとも生み出せるためである。

どんなに優秀なエンジニアだって、ひたすら機能追加していくようなサービスをクリーンに保つことなど不可能だ。最初はそんな機能がない前提で設計していたのに、どんどん追加していけばぐちゃぐちゃになって当然だ。

これから何かを作ろうとする人は、まずそのサービスがなんのために存在するのかを明確にし、その理由に沿った機能を磨き続けることだけに集中すればいいのではないかと思う。

既に Fat なサービスを運営している方へ

多くの機能を提供しているサービスを運営しているなら、確実に Fat な状態になっていることだろう。そんな方へ私が言いたいのは、「コードを思い切って消していく人を賞賛する」文化をつくっていって欲しいと思う。Fat なシステムを削除していけるエンジニアは"勇者"だ。自分の責任を背負って懸命にシステムの依存関係を読み解き、いらないコードを消していく。これには半端ない集中力とシステム全体の理解が必要で、新しく機能を作るよりも何十倍,何百倍も難しい。しかもビジネスサイドの人たちからは賞賛されることのない地味な仕事だ。その仕事を進んでやる人こそ、Fat なシステムを担当することになった場合の最高のエンジニアだ。

コードを消していかないと、確実に理想は届かない。コードを消すって文化のない開発組織は、確実に Fat なシステムになって減退する。

コードを消すことを諦めて作り直すって選択もあるかもしれない。しかし、その作り直した先にはまた機能追加っていう逃げの開発をしてしまって、やがてまた Fat なシステムができあがっていく。そんな無駄な時間の繰り返しが発生する。

コードを消すってことに時間を投下することを容認しないような会社にいる場合は、とっとと辞めるべきだ。機能開発ばかりに目を向いているのはサービスの軸がブレブレである証拠だし、素晴らしいシステムを保ち続けることに理解のない会社なのだから。

終わりに

今回は私の思うコードを美しく保つための方法について記した。もちろんこれにはいろんな意見があるかとは思う。あなたのコードを美しく保ち続けるための秘策を教えて欲しい。私もその理想について一緒に考え続けていきたい。

WebRTC の Media, Stream, Track について

ども、@kimihom です。

最近の週末は Twilio Video を使ってビデオ通話アプリケーションを作成している。Twilio Video は今どんどん進化していて、単なる2,3 人でのビデオ通話をするにとどまらず、面白いことができるようになっている。特にスクリーンシェアの機能を Chorme 拡張機能を使うことで Twilio Video でもデスクトップ画面共有のアプリケーションが作れてしまう。ちなみにデスクトップ画面共有のドキュメントは1週間前に出たばかりなので、最新情報だ。

さて、この デスクトップ画面共有の概念を理解しようとすると、途端に WebRTC の Media, Stream, Track というそれぞれわかりづらい概念をそれなりに理解しなければならなくなる。今回は自分なりに勉強して理解したことをまとめようと思う。

Media, Stream, Track

最初に自分が理解した 図を貼り付けよう。少々見づらいかもしれないがこの点は勘弁してほしい。

f:id:cevid_cpp:20170305215612j:plain

今回は、ローカルのメディア、つまり自分のブラウザ環境だけに焦点を当てている。実際は LocalMedia での Track だけでなく、 Remote つまり相手の Track と合い重なってそれぞれのビデオ通話を可能にしている。

さて、まず全体を取り巻くのが Local Media だ。Media には複数の Stream を持つことができる。WebRTC といえばのメソッド getUserMedia で取ってこれるのは、デスクトップカメラとマイクの2つだ。 これらはそれぞれ VideoTrack, AudioTrack がある。てことで、大抵の WebRTC でのビデオ通話では、1つの Stream で 2つの Track を持った状態で相手と通信をすることになるだろう。

そしてその下、getUserScreen と書いたが、これが Chrome の画面共有などのメソッドとして仮に定義したものである。実際は Chrome 標準で作られているものではないので、Chrome 拡張機能 として getUserScreen を実装しなければならない。んで、getUserScreen を呼ぶと、もう一つの Stream が出来上がり、その中に VideoTrack が作られることになる。こんな感じで一つの Local Media に 2つの Stream が存在することも可能だ。

ここまで説明すれば、というより図を見た時点で Media, Stream, Track が理解できてのではないかと思う。ただ実際に Twilio Video のドキュメントを読んでみると、これらが複雑に絡み合ったようにそれぞれがそれぞれの参照を持つようになるので、何が何だかわからなくなる。こういう図を最初に見ておけば、混乱することもないかと思う。

Twilio Video でのサンプルコード

さて、ここまでくれば、Twilio Video のサンプルコードも理解できるだろう。 Twilio Video でのビデオの初期化はこんな感じで実装できる。

    _localMedia = new Twilio.Video.LocalMedia();
    Twilio.Video.getUserMedia().then(function(mediaStream){
      _localMedia.addStream(mediaStream);
      _localMedia.attach('#video-view');
    });

    getUserScreen(['window', 'screen', 'tab'], "your chrome app id").then(function(stream) {
      _localMedia.addStream(stream);
    }).catch(function(error) {
      console.error("Screen Capture is not instaled!");
    });
  }

2つの MediaStream を add して追加し、Media を div 要素に Attach することで その中に Video や Audio 要素が追加されるようになる。

それぞれ LocalMedia を addStream すると、先ほどの図のように Track ができあがるので、Media#event:trackAdded イベントが呼ばれる。これでそれぞれの Track を管理して、例えば停止したりミュートしたりの操作も可能になるだろう。

終わりに

今回は Twilio Video でデスクトップ共有ができるようになったので、 Media, Stream, Track の3つについて勉強し、学んだことをシェアした。もし誤りなどあれば、指摘してくれると私の勉強にもなるので大変嬉しい。

個人的に Twilio はこのビデオ分野が今アツいと思ってるので、今後も追っかけていく次第である。

まだ WebPay から移設をしていない方へ

ども、 @kimihom です。

WebPay がサービス終了宣言を出してからおよそ半年が経とうとしている。いよいよ2017年04月30日までというデッドラインが近づいてきている。

「WebPay からどこかへ移った系のエントリーが出てくるのを待つか」 と思って後回しにしている読者の方に一言、伝えておかなければならないことがある。

今すぐ申請を始めるべき!!

私も甘くみていた側面があるのだが、WebPay の審査が通ったからといって、他の決済サービスの審査期間が短くなるということではない。つまり、そもそも次なる決済サービスを本番サービスに反映しようにもその審査時間であるおよそ 20 営業日を待たないといけないのだ。Visa/Master の2ブランドだけでいいなら、1週間以内に本番反映できるようになるが、それ以外のカードをサポートするには1ヶ月の余裕を持った方がいいだろう。

1ヶ月・・。そう今日が 3月2日だとして、もうかなりギリギリのラインだ。当然、その決済サービスの審査に"落ちる"ということもありえなくはない。そしたら他のクレジットカード決済サービスを探すか、決済ブランドを減らすかの選択をしなければならないだろう。今から申請して審査に落ちたとなれば、その猶予はもはや残っていない。

本番で審査しようとする決済サービスを使うか使わないか関係なく今すぐ本番申請を始めよう。さもなくば、あなたのサービスが一時的に決済のできない状態が生まれてしまい、とんでもなく大変な事態に見舞われるだろう。

実際に移行してみて

実際に月額課金モデルを実装する上では以下の記事にまとめている。もしよければ以下も読んでいただきたい。

www.bokukoko.info

私のサービスの場合、単発課金の API をこちらで定期的に呼ぶという実装にしている。この設計にしたおかげで、WebPay から他の決済サービスに移設する上で必要になったコードを最小限に抑えることができた。これは不幸中の幸いだった。

実装で注意しなければならないのは、一時的に WebPay と移設先決済サービスを混在させる必要があるということ。深夜メンテナンスをしてガッと変えたいところだが、 WebPay が時間指定でのカード移設をしてくれないという悲しいサポートのため、この実装が必要になる。

もうちょっと具体的な実装方法についてご紹介しよう。

WebPay と外部サービスを混在させた実装

きっと、WebPay を使っているなら、 Customer のオブジェクト ID をデータベースに保存していることだろう。webpay_token とする。そんで今回から新しく別サービスのトークンを使うことになるので、hoge_token を新しく作ることになるだろう。

WebPay から移行する期間に入るまでに、新規カード登録は全て、新しい決済サービス側で登録させるという実装をする。つまり、新規カード登録は webpay_token に保存するのではなく、 hoge_token に保存するようにさせる。

んで移行期間中の決済に関しては、全ての決済においてhoge_token が存在すれば、そのサービスで決済をし、もし存在しなくてwebpay_token が存在すれば WebPay で決済するという実装をする必要がある。

WebPay 側で移行が終われば、データベースに保存していた webpay_tokenhoge_token にコピーするっていう作業を実施することで、それ以降の決済は全て移行先の決済サービスで行われるようになるだろう。

それが完了次第、 webpay_token 自体や、 if 文で分岐させていた WebPay 決済部分のコードを消して、決済サービスの移行が完全に完了したことになる。これで一件落着だ。

Subscription の移行は至難の技

WebPay の Subscription の仕組みから、移設先の Subscription の仕組みに移設するのはなかなかの困難を伴うようだ。私自身はやっていないので何とも言えないが、その難しさは想像するに容易い。

もし WebPay の Subscription の仕組みを使っていて、まだ何も行動していないという方がいたら、それはかなりヤバイ状態に既にいることを認識しておく必要がある。私から言えるのは、ともかく頑張れということだ。

終わりに

意外と WebPay からの移行記事が全然出回っていないので、私から警告の記事を書かせていただいた。

全てのサービスが正しく移設できることを祈っている。

新技術とどう向き合うかについて

ども、@kimihom です。

テクノロジーの進化は速く、追いついていくのは大変だ。全部を完璧に吸収するってのは理想ではあるが、当然のことながら一人では限界がある。私たちはどう新技術と向き合えば良いのだろうか?

今回は私の思う技術を見極める方法について書いていこう。 ちなみに私はどちらかと言うと新しくサービスを作る側のエンジニアであり、何かに特化するスペシャリスト側のエンジニアではない。その目線からの話である。

その技術は本質的に “新しいか”

私は何か技術が生まれた時に、"その技術は本質的に新しいか" を見極めるようにしている。よくある新技術として、以下のような例があるだろう。

  • 新しい技術分野
  • 新しい仕様
  • 新しいプログラミング言語
  • 新しいフレームワーク
  • 新しいミドルウェア
  • 新しいインフラストラクチャ
  • 新しい設計思想

さて、同じタイミングでガッと色々と出てきた時、何を選ぶだろうか。

もちろん興味の度合いなどあるだろうけど、私は常に顧客目線を大事にするようにしている。新しく出てきた技術が、本質的に顧客体験を変えることができるのかという視点である。"今までできなかったことが、その技術でできるようになるのか"、とも言い換えられる。

例えば新しい言語やフレームワークってのは、得てして今までもできたけど純粋にちょっと速くなったり、ちょっと使いやすくなったりする程度の話が多い。その言語しかできないことってのは案外少ないものだ。フレームワークも同様だ。そのフレームワークの登場で、今までできなかったことができるようになるのか。その答えに対し明確に Yes と答えられるフレームワークと出会えることはほとんどない。 これまで色々な技術が出てきたけど、個人的には Rails, jQuery, Heroku (Postgres, Redis) 以上に素早く正確に新しいもの開発できる技術はないと思っている(私が単に得意ってのもあるし、私の判断なので人それぞれのはず。好みの技術で書き換えて欲しい)。新しいフレームワークをざっと見てみても、上記テクノロジー以外で新しくできるようになることってのが見つからない。だから新しいものに対して事前に調査はするけども、磨いていくってことはしていない。もっと他に学ぶべきものがあるはずだと考えるようにしている。

じゃあ例えばどんな技術に注目すべきかって話になるけど、例えば HTML5 の主要技術 はこれから一般的に普及するものであり、今までできなかったことができるようになるという点で注目すべき技術だ。また、新しく登場した各種 API も今まで難しかったことが簡単に実現できるようになったって意味で貴重だし、もっと大枠で言えばスマホアプリ開発技術も当てはまる。何かしらのプログラミング言語で作られたミドルウェアが今までできなかったことができるようになるレベルのものだった場合、その新しい言語を学ぶ価値があるかもしれない。そのような判断基準だ。

この基準でテクノロジーを見渡すと、学ばなければならないものがはっきりする。一部で話題になっている技術に飛びつくようなことをしなくなる。人と比較しないってのは大事なことだ。自分が目指す理想のサービスやシステムを実現することだけを考える。私にとってテクノロジーは自分の理想を実現する上で必要なものだけを取り入れる。それだけの話だ。

それでも終わらない技術への探求

ここまでの話は、あくまで学ぶものを選ぶことによって自らがすべきことを明確にするってだけの話。つまり、私たちは常に学び続け成長しなければならないことには変わりない。当初は甘くみていた新技術がいつのまにか革新的な開発効率を生むようなものになっている可能性だってあるし、そもそも新らしく出てきた技術にアンテナを立てなければ今までできなかったことなのかどうかも判断できない。だから、そもそも学ばないとかアンテナを立てないとかってのは問題外の話である。

エンジニアにとって一番大切なのは探究心/好奇心だ。新しいものをまず見てみて、それが自分の方針に合いそうだったらしっかりとやる。

師匠/先生がこれをやれと言ってるからやっている?教科書に次はこれってあるからやっている?なんか流行ってるからやっている? このような周りに流されながらの学習方針は、エンジニアとしての成長を鈍くさせるだろう。もっとも大切なのは、繰り返しになるが、自らの好奇心だ。湧き出る好奇心から生まれた技術への探求が四六時中そのことを考えられるようになるための、ついては自らが成長し続けられるようになるための条件だ。

私の磨く技術は私が決める。それが結局一番自分の技術力を高められることだと信じている。

“いい師匠を持つことが大事だ"って意見をよく聞くが、本当にそうだろうか。確かに凄い人を見ればモチベーションは上がるけど、私はその人が言うからやるみたいなことはしたくない。その人から言われてやっていることをやり続けたところで、その人を超えることはいつまで経ってもできないのだ。

終わりに

新技術と向き合った時、それは一つのチャンスである。まだ誰もタッチしたことのない新しい領域だから、極めれば自らが第一人者になれることができるかもしれない。ただし、自分がそこまで没頭してでも磨きたい技術なのか。その磨いた先にある未来は見えるのか。そうした冷静な分析が、今後の学習を正しい方向へ誘ってくれるだろう。

共に次なる高みへ進んでいこうじゃあないか