WebPayの正式リリースから1年が過ぎた
何か会社のことを綴るとポエムと揶揄されるからか、単純に忙殺されているのかCEOであるところの@keikuboが特段発信をしないのでそっとこの1年どうだったかを社員1号*1として個人の日記を書いてみようと思う。
文字ばっかりでびっくりしたので写真を後から添えた。
サービスとしてのWebPay
「お金扱うのなんか怖くない？」と誰もが尋ねてくれるけど、まさにそう思ってるし、お金の計算の段では毎度ピリピリとした空気で画面に向かい合って、何度もそれが正しいか、カード会社から受け取る明細と合っているかで目を回している。
ことお金の計算になると、自動化の線を決めるのがいつも難しい。銀行の人は夕方に窓口を閉めてこれをやっているのかなあ。
ペイメントにまつわる性質上、ユーザ登録をしてもらって実際に決済が回り始めるまでのリードタイムにやきもきし、何度も「WebPayってサービスとして成長してるんだっけ」と不安になるkeikuboを大丈夫だよとなだめているうちに、導入してくれたサービス、サイトがトランザクション数を伸ばしていく様を次々と見られるようになって最近は嬉しいことが多いように見えてきた。
APIとその周りについては足場が整ってきていて、加盟店の審査や各カード会社の接続など表に出てこない大事なところが思っていたよりも綺麗に積み上げられてきている。ついにStripeとの互換からの卒業をして、僕達の思い描くペイメントサービスをまず日本で文句の無い形にするところへ向かい始められるようになった。
見事にユーザ向けのダッシュボード（僕達はAPIに対してGUIと呼んでいる）側はまともに進化を経ず、ここからツールとして使えるようにしていくつもり。あくまでも主役であるAPIをちゃんと動かすことに集中して、シンプルな形を維持しつつも実現出来る幅を増やしてきていて、GUIはあくまでもそれを利用するためのドッグフーディングで、外部に公開しているライブラリで外の人と同じようにAPIを叩くという開発当初のポリシーを守っていたが、サービスがAPIだけでなくGUIも含めて使われるようになってきたことに合わせて変化が求められ始めている。
hmskの仕事
正式リリースの前後はインフラ周辺、その後ユーザサポート、加盟店審査で顧客とカード会社とのやり取り、月締めの計算を担いながら、ビジネス側の動きと同期した開発の計画と仕様の草案の作成と言い出すとキリがない。あれとあれ以外のだいたい全部ですみたいに言ったほうが早いかもしれない。
僕自身は未だに何のエキスパートにもなれていないけど、各所間の繋ぎ糊やウェブサービスはこうあって欲しいというエゴを塗りたくるようなことをやる分にはとても面白い。
開発についてはコアのロジックをゴリゴリというよりは、個々のレビューとリリースマネージャみたいなことやって、UI/UXからは程遠いけど外にどう示すか、どういう態度を取るかという側面を持つもののコードに触れている。（でもサービスとしてのエクスペリエンスだ）
全て、外の世界では名前が付いていそうなんだけど、僕達版のこれは外でいうそれなのかわからなくて、何をやっていますというのはとても難しい。
春からはプロダクト開発の責任者というラベルを貰っているけど概ねやることには変わりがなくて、出来ることをちゃんとやり続けましょうというのを繰り返している。
専科のデザイナーが居ないのとうまくフィットするように雇える自信がないので隣の部屋で暮らしているメンバーの一人と一緒に勉強を始めた。dribbblerになるのが最近の目標になっている。
あれもこれも、かつてお世話をしてくれた、はてなで、クックパッドで、ウェブサービスをやっていくことで大事なものを見せてもらっていたのだ（特に対ユーザの態度がそうだ！）と、開発に限らずひとつひとつの考えることに向かい合う度に痛感する限り。とても素晴らしい場所、人、空気でいっぱいだったというのはもうちょっと僕達がうまく行ってからお礼をしたい。
リモート
「情報は出す側がフィルタせず、受け取る側が取捨選択しましょう」「どうでも良さそうなことでも共有しましょう」「自分を見えるようにしましょう」...今まで僕が居た職場の人たちが普通にそういう感じだったのが逆に凄いことにやっと気づくことになった。
ツールには事足りているけれど、マインドを変えるのはこのツールの仕事じゃないよなと苦笑いすることが多い。Slack, Asana, Qiita:Team、ありがとう。
ただ、まだ見知った人たちと離れているだけ、しかもkeikubo達とは昨年一緒に1年弱暮らしたので、どうにかなっていて、それでもちょこちょこ会ったり、同じ空間で仕事でなくとも何かを共有することには飢えてくるので、全く知らない人が増えたらどうふるまったもんか。いつかGoogleの知人がアメリカにちょっと行ってることに理由を尋ねたら「チームビルディング」とだけ返ってきたのは頭の隅に残っているので、人が増える度に帰国すればいいのかなとも思う。日本酒飲めるし。
個人と組織
良い所に良いメンバーが入り込んでくれて、僕個人は今までの努力が足りないおかげで大した力もなく、いつも申し訳なくなるのだけど、まず小さく回すことには成功している。
ただ、オペレーションも何もかもそれぞれ得意な人のところに居着いて時間を食べてしまっていて、どうスケールさせたもんかというのは常に葛藤で、自動にすることを前提にやってもうまく行かないし、やっていることを自動にしていく作業の間はキャパシティの急増を求められている感覚がする。ちゃんとやりなさい。
何度かメンバーの追加には失敗をしていて、うまく仲間を見つけてうまく一緒にやっていけるようにするというのはとても難しい。Instagramがずっと数人で回していたのを想像して、彼らの言う「足りないことがフォーカスを生む」という意味もわかってそうありたいと思うのと同時に、周りのスタートアップがじゃんじゃん人を雇ってうまく回しているように見えることには焦るばかりだ。
そして、凄く仲間にしたい人が凄く僕達と一緒にやりたいと思うようにするのはめちゃくちゃ難しい。
引き続き宜しくお願いします
ペイメントのサービスでなかなかココロオドルとか言えない面もあるけれど、渋く、黒子のように振る舞って当たり前に使ってもらえるような態度を保っていられればいいなというのは個人の見解で、所属する団体の考えとは直接的な関係はありません。
あんまりスタートアップのことよくわからないので、自分たちで素敵なウェブサービスをつくることに取り組んでいますというのがここまでのまとめです。
WebPayでは、今月の中旬にはミートアップをやることになりました。最初に書いたサービスのリリースから1年のことをもっとわかりやすくお伝えすることが出来るはずです。
導入してくださった方、導入しようと考えている方、WebPayを気にかけてくれている方にお会い出来ることを少ないメンバー一同心待ちにしております（人数埋まるんやろか...）
これとは別に毎週なり隔週なりでペイメントの導入からまつわること、アメリカの様子まで気軽に話しに、聞きにこれるような小さなミートアップを帰国中くらいは続けてやっていけないかなと考えています。ご興味ございます方は @hmsk まで。
*1:厳密には2号なのだが、FounderではないEmployeeの最初ということで1号
アメリカに引っ越した
個人的な希望と仕事上の理由が都合良く一致させられたところがあって、就労ビザもどうにかなったので、2013年末を以て海外転出届を出し、15分そこそこ歩けば Oracle があるようなところに引っ越した。
ずっと居るとか、いつ帰国するとか何も決めていなくて、むしろそれは暮らしてみてから決めることなのでしょうというところ。
仕事も話題の？リモートというやつになって、 PS3 のビデオチャットといくつかのウェブ上のツールで今のところはどうにかなっている。小さなチームの（自分で言うのは気が引けるが）コアの1人がリモートでやるというのは、結構無理な話だと思っていたものの、ここ1年間くらい、 @keikubo と @sowawa と一緒に暮らしたのが大分功を奏しているというのは違う話題なので別の機会に。
いわゆるシリコンバレーと呼ばれるような場所にやってきて、しかも今までにそれを望んだようなアウトプットを繰り返しているものの、それが叶った感慨はあまり無くてびっくりした。漠然としていて具体性に欠く希望だったものが、現実味を帯びる時に改めて理由を認知することで高揚感を失わせているみたい。実際、甘えて飲み会に行かないとか、天気が良いとか、ウェブサービスであまり嫌な制限を受けないとか字面を見るとちょっと不安になる。
穏やかに暮らしています。ハッピーバレンタイン（現地）
#wedding-sに向けてTwilioでお祝いのメッセージを集めた
#wedding-sは、@kei-s と @yuca の結婚パーティ。夏に二人と食事をしたときに「二次会とかやんないんすかー、人生で人呼びつけられるのそんなにないっすよ」ってくだ巻いたら結婚式翌週のパーティの幹事のようなものになっていた。僕も葬式くらいは灰になるときに人を呼びつけたい。
幹事をワンマン不安になってすぐに @june29 と @darashi に泣きついて何をやるかとか話して、そこからいっぱい助けられて先週末無事に会が終了した。
コンテンツとしては
というのを一番やりたかったけれど、成功のイメージが一切思い描けなくてちゃんと没にした。
ちょうどその頃WebPayのサポート周りの改善で、「電話での問い合わせ」を録音してスタッフ全員で共有していて、メールで投げつつ電話してきたり、電話したけど後でメールしますねみたいなユーザが結構居て、僕たちとユーザの間で無駄なやり取りが発生してユーザに余計な迷惑をかけるのを防ぐような対策をしていて、その電話の録音や通知の仕組みのところに @keikubo がTwilioを使っていたというのが着想で、Twilioを使って、結婚した二人へのお祝いのメッセージを電話で集めることにした。
wedding-s-messenger
Twilioは電話がかかってくると指定したURLにXMLを見にきてくれて、Twimlで定義されているフォーマットでレスポンスすると言う事を聞いてくれる。
シーケンス制御を組み立てる感じで分岐を作って
- (1) 電話を受け付けてウェルカムなメッセージを流す
- (2) メッセージ入力方法の説明を流す（終わったら#押してねみたいな）
- (3) 発信音を鳴らして録音を実施する（#で終了する）
- (4) 録音したメッセージを流すよと宣言して流す
- (5) このメッセージで良かったら"1"を押せ、もう一度録るなら"3"を押せと促しつつ入力を待つ
- (6) 入力された数字が、"1"なら(7)へ、"3"なら(2)へ、それ以外なら(5)へリダイレクト
- (7) お礼を流して電話を切る
Twilioがtwimlを見に来てくれるときは、GET/POSTでよしなにパラメータ付きでやってくるので、やってくる先をSinatraによるウェブアプリにしておいて、やってくるメッセージの情報をよしなにデータベースに保存するようにした。この仕組みを会の名称に合わせてwedding-s-messengerと名付けた。
上のシーケンスまわりのソースは概ねこんな感じ
そして、アプリ側では管理画面を作っておいて、メッセージの削除とかダウンロードとかを行えるようにしておいた。
ちなみに、これの電話番号は結婚式やインターネットで新郎新婦に分からないように撒いておいて、新郎新婦の電話番号から万が一かかってきたら別ルートに分岐するという対策もとっていた。
一番大事だったのは受話器に流すメッセージで、テスト用には僕が自分で喋った声を入れて流していたのだけれど、ちゃんと喋る力を持った @mamipeko の声に差し替えた途端に栄えたし、これは本当に価値があるのかと不安なプロダクトに対して自信を持てて、コードよりも価値があった。Retinaディスプレイかと思った。
特に自分の声だと、なんだろ、ホテルのユニットバス系のトイレで用を足してて自分の股間が鏡越しに見えるような虚しさに近かった。
僕のブログでその声を聞けるというのはどうしようものかと思っていたらご本人が公開してくれたので良かった。MacbookPro 13 inch Retinaも薄く軽くなったことだし。
新郎新婦の日頃の行いもあって（メッセージを入れることを快く引き受けてくださった皆さんありがとうございました）、200件近い録音が行われたけどこれで負担額は$5そこそこ（もちろんかける側も電話代を負担しているが）
当日集まったメッセージの「けいさん」「ゆかさん」「おめでとう」を切り抜きまくって重ねまくった音声を流しつつ、刻印を入れたiPod Shuffle（シルバーだと結婚感ある）に全ての音声を入れてお渡しできた。
@darashi が「これはもう祝電2.0ですよ〜」と事前準備で会った時か僕の夢かで言っていたのがとても印象的だった。
この仕組みで、少なくとも幸せになれるユーザが世に居るのが分かるので、いい感じにASPとかにしたりするのはどうだろう。今回はサプライズなやつだったけど、電報感覚でまー会場に届いてますっていうのに声が追加されるのは素敵なことだと思う。もうあるのか結婚したことがないからよくわからない。
あまり関係ないけどgit-subtreeが便利
にもあるように本会の準備の進行に主婦と一緒にGithubを使っていたのだけど、このwedding-s-messengerがリポジトリの中に/messenger というディレクトリをルートとするアプリとしてpushしていて、これではHerokuにデプロイするのが不便なのではという時にgit-subtreeが最適だった。
git subtree push --prefix messenger heroku master
で、messengerディレクトリがルートなアプリをHerokuにデプロイできる。
あと、HerokuだとRack appがお休みなさるので、ずっと監視用のリクエストを叩き続けていた。
*1:ありそうなのは子どもが何人だとか
ユーザから代価を得ることをお手伝いしています。
昨秋よりWebPayに関わっている。
クラウド系かなーとfluxflexに行った初日に「決済に本腰入れ始める」と聞いた時に呆然としたところから、予想したよりも続いているし予想したよりも面白いものを見つけたと思えるようになっている。
最近の悩みはクレジットカードの更新時に再審査してもらったものの限度額が10万円だったこと。
WebPayの検証用にもDiners Clubのカードが欲しいのだけれど、誰一人持てないのではないか。Dinersホルダーのエンジニアの入社が待たれる。
WEB+DB PRESS Vol.76 特集2 Web決済入門
春先に「決済やってるんですよ」と@inaoさんに挨拶をしたところから、@keikubo, @sowawaと3人で寄稿させて頂くこととなった。
- 作者: 五十嵐啓人,伊野亘輝,近藤宇智朗,渡邊恵太,須藤耕平,中島聡,A-Listers,はまちや2,川添貴生,片山育美,池田拓司,濱崎健吾,佐藤太一,曾川景介,久保渓,門脇恒平,登尾徳誠,伊藤直也,mala,後藤秀宣,若原祥正,奥野幹也,大林源,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2013/08/24
- メディア: 大型本
- この商品を含むブログを見る
■特集2
Amazon.co.jp： WEB+DB PRESS Vol.76: 五十嵐 啓人, 伊野 亘輝, 近藤 宇智朗, 渡邊 恵太, 須藤 耕平, 中島 聡, A-Listers, はまちや2, 川添 貴生, 片山 育美, 池田 拓司, 濱崎 健吾, 佐藤 太一, 曾川 景介, 久保 渓, 門脇 恒平, 登尾 徳誠, 伊藤 直也, mala, 後藤 秀宣, 若原 祥正, 奥野 幹也, 大林 源, WEB+DB PRESS編集部: 本
Web決済入門
PayPal、WebPay、iOS/Androidアプリ内決済の導入方法
本特集では、Webサービスやスマートフォンアプリで行う課金についての最新動向を解説します。初めて課金を導入しようと思ったとき、どのような課金手段があり、どれくらいの手数料がかかるのか、どのような事前審査があるのか、どのように実装すればよいのか、セキュリティはどうなっているのかなど、わからないことだらけです。本特集ではこれらの全体像を整理し、クレジットカード、iOS/Androidアプリ内課金、PayPalなどの主な課金方法についての実装ノウハウも解説します。
日本で決済代行サービスをやっていると、カード会社や資金決済業など外からではよくわからなかった世界が少しずつ見えてきていて、今回の構成はサービス提供者として決済に関わる人には知っておいて欲しいというトピックを集めたものだ。WEBでもDBでもないだろみたいな話も多く含まれているのは正しかったのかどうか不安な限りだ。
前号のペパボの特集の際のスケジュールを@hsbtさんが書かれていた（しかも、とても素晴らしい進行だった）のを見て脱稿までずっとヒヤヒヤしたり、あまりに見積もりが甘い上、伝えたいことを書き出したら止まらなくて、10ページ以上オーバーした文字数を削り切ったと旅先の札幌で@inaoさんに連絡したら、改ページ等諸々で「ほとんど減っていません」と返ってきて青ざめたりもしたものの何とか形となってひとまずは安心している。
執筆に係っている約2ヶ月間で、WebPayの中もなかなか変化していて、特にWebPayのサブスクリプションに関する節を書いた直後あたりで、当該機能を削る時は気が動転して鼻水が止まらなくなったこともあった。
以前クックパッドの特集(vol.66)の時（偶然にも今号の特集1もクックパッドだ）に、数ページ書かせてもらったのとは全く違い、執筆者側の取りまとめを僕がやって@inaoさんとやり取りしながら進めたけれど、@inaoさんの進行管理の巧さに感嘆するばかりだった。これを隔月で何件も同時に回している中でやってくださるのだから接待及び贈答品も送りたくなる。
他の著者さんほど執筆環境を追求出来ていないが、Githubとmarkdownだけを僕たちは気にすれば良い状況にしてもらえたのが何よりも有り難かった。
よろしくお願いします
有償のWebサービスをつくるときに、提供者は「自分たちのWebサービスの代価をユーザに求めるということがどういうことか」を考え続けることに集中できるよう、周辺のルールや技術的なこと、何となく中身が不安な仕組み（今回はクレジットカードだけだけれど）を知っておくために本特集へ目を通してもらえたらとても嬉しい。
「だである」調で書くとやたら偉そうになるのが辛い。（本特集は「ですます」調です）
プロジェクタ用のパソコンを準備したくない
RubyKaigi2013のアクシデンタルスタッフ*1をした。2010,2011と当日スタッフをやらせてもらっていたけど今年は色々逸していて、前日までは普通の参加者のつもりだった。スクリーンのコンテンツ表示や自動起動などをするAndroidアプリを今回のスクリーン群の管理システムに合わせてつくって、前日に設営に会場に行ったが為にスタッフの仲間に入れてもらえて、気づけばスクリーン達の面倒をみながら見たい発表や、RubyKaigiならではの再会を楽しむことになった。
ホワイエの3台とホールAの前、会議室1の左側のスクリーンの計5つは全てAndroidで動かしていたことに来場者たちは気づいただろうか。
RubyKaigiのスクリーン達
だんだん当たり前の風景のようになってしまっているが、RubyKaigiの会場各所でTwitter、IRC、運営からのお知らせ、良い弁当などの情報が来場者達に向けて輝いている。そのスクリーン群もRubyKaigiとKaigi Freaksと一緒に成長を遂げていて、今年も進歩をしながら実用に耐えた様子だった。
Androidをプロジェクタ用端末として使う
今回、スクリーンの一部に、スティック型の、テレビに直接HDMIで繋げて使うようなAndroid端末を使用した。
@darashiのスティックと僕のスティックそれぞれで買っていたものを持ち寄っていたので金額は様々だが平均すると1台5000円そこそこでリースの端末よりも取り回しがよく、電力を食べず、予期せぬ外乱が少ないので、ブラウザで得られる情報のみを表示するのならば、こういったイベントのサブスクリーンに使うには最適だった。誰々のスティックと呼ぶと何だか卑猥に聞こえるので慣用していたが、いまづ先輩には全部スルーされた。
「起動したらすぐに動いて欲しい」など、ただブラウザをフルスクリーンで表示するだけでは足りないニーズをAndroidアプリケーションで補うのが僕の今回のお手伝いとなった。お得意のWebViewベースハイブリットアプリだ。
結果としてリースで会場用に借りていたWindows端末の使用は7台に押え込めて、設営や撤収などの諸々のコストを下げられたのはとても良い成果だった。
加えて、リコーさんの超単焦点モデルのプロジェクタが無ければホワイエの格好良いスクリーン群が叶わなかったことを付記しておきたい。
Androidアプリの細かいことだったりは、@darashiと@june29が綴るデジタルサイネージの管理システムの話と一緒でまたどこかで書いたり喋ったり出来るのだと思っているので会期終了後の高揚感のメモとして。RubyKaigiに限らず、二人がたのしく何かを開発しているのを割と近いところで知っていて、その中に少しでも入り込めてものをつくれたのはとてもとても良かった。
@makimotoさんが今回のLTで紹介していたGlitch Rubyistokeiを表示していたのだが、スクリーンが壊れているよと来場者に知らされ、僭越ながらGlitchの説明をさせて頂きますということが何度かあったがGlitchのことをあまり僕はよくわかっていない。
サンコー Android Stick 4 SmartTV ANDHDM40
- 出版社/メーカー: サンコー
- 発売日: 2012/09/05
- メディア: エレクトロニクス
- 購入: 2人 クリック: 207回
- この商品を含むブログ (3件) を見る
これとは別にRubyistokeiを電源接続時などのDayDreamで楽しめるAndroidアプリをスピンアウト的につくったが、Rubyistokeiのアイコンが決まり次第（！）公開したい。
*1:© @kakutani
