Quipper買収されてました

4th Jul, 2015 (Updated on 4th Mar, 2016) | quipper

元DeNA創業メンバーの渡辺氏が創業した「Quipper」をリクルートが約48億円で買収、現状と今後の狙いを聞いた

このこと自体を決断したのはそれなりに前なので、自分の中では今更な感じがありつつも、大きく取り上げられると、やっぱりなかなか感慨深いものがある。

みんなもなんか書いてるし、せっかくのタイミングなので、自分も何か買収される側の変化みたいなものを書こうと思って書き始めてみたのだけど、そこまで大きな変化みたいなものがなかったことに気づいた。というのも買収後、元々Quipperがやっていたこと/やりたかったことの方向性が変わったわけでもなく、ただその方向を強く加速してもらっているという感じなので、とても自然に進んでいる。

上の記事の中でCEOである渡辺さんがモビルスーツという喩えを使っているがまさにそんな感じ(モビルスーツ本当はよく知らないので雰囲気で!)。うまく、PMI(post-merger integration: 今回知った用語)が行われているのだとは思うのだけど、気持ちよく働けている。

もうちょっと何か喪失感みたいなものがあるのかなあと買収前は想像していたのだけど、そんなこともない。改めて、自分にとってQuipperとは何なのかということを考えてみると、設立当初からQuipperというプロジェクトを成功させたい、という気持ちは強かったけど、Quipperが自分のもの(株式的な意味やいろいろな意味で)という感覚はそもそもあまりなかったのかもしれない。Quipperプロジェクトの中の1メンバーという気持ちが強い。そして、今もQuipperというプロジェクトを成功させたいという気持ちは変わらず、それは今回のことで特に動くものでなかったという感じ。

こんな呑気なことを言っていられるのは今だけで、もしこれからQuipperの成長がうまくいかなかった場合、何か怖いことが親会社から起こるのかもしれないけど、それは今までの投資家のみなさまとの関係でもあまり変わらないし、これも大きな変化ではない。(今までQuipperに投資して頂いた方々は本当に自由にやらせてくれ感謝でいっぱい。)

いろいろな買収の形があるんだろうけど、Quipperの場合は今のところこんな感じということを書いてみた。なんか、他の人みたいに意識の高いことを書こうと思ったんだけど難しい!性格が。

まあ、そんな再加速中のQuipper、経営もより安定し、チーム拡大中につき、ここ最近いろいろな職種を募集中。順調に進みつつも、Quipperのコア中のコアであり世界へ広げるQuipperプラットフォームの開発をするweb開発者(RubyやJavaScript)の採用がちょっとうまく行っていない。フロントエンド/バックエンド問わず我こそはという方、よろしくお願いします。

参考リンク:



Quipper現在の状況と積極採用中について

26th May, 2015 (Updated on 4th Mar, 2016) | quipper

ここ1、2年、東京オフィスでは積極採用をしていなかったのだが、事業拡大につき積極的な採用を再開している。表に出している公式の求人情報とは別の角度でQuipperとはどういう会社で、どういう人を求めているのか、みたいなことを書いてみることにした。

Quipperの今までと現在の状況

Quipper、創業5年目に入ったところ。最初の3年間はピボットの連続で、教育周りでいろいろなことをやってきたが、3年目の終わりくらいからサービスを絞り、成長フェーズに入っている。スタートアップ初期の荒波、生きるか死ぬかみたいなフェーズは終わっている感じだと思う。そこを楽しんでみたいと言う人にはちょっと遅いかもしれない。今はその次の成長フェーズで、そこを楽しみたい人にはぴったりのタイミング。初期の荒波は、それはそれで正直楽しいのだけど、落ち着いてプロダクト/サービスに集中し良いものを作る!というのは今のフェーズだと思う。

現在ほぼ唯一でメインのサービスはQuipper Schoolというもので、フィリピン、インドネシア、メキシコ、そして日本で展開している。大きく盛り上がっているのがフィリピンとインドネシアで、それを追うメキシコ、日本という感じ。今後展開国は増やしていく予定。

日本では、今のところオープンには展開していないので、どういうサービスか伝えづらいのだけど(これがQuipperの日本での求人の難しさ)、例えば、日本以外の国の様子はTwitterのtimelineを見てみるとこんな感じでユーザーに受け入れられているのがわかる。

今、フィリピンが夏休みでユーザー数が減っているので、インドネシア語ばっかりでわかりづらいけど。

他にも、

  • Facebookページ だと、35万likeくらいされている。
  • 最近の記事だと、 The Top Ten S'Cool Tools for Q1, 2015 でも紹介されたりしている。
  • Quipperの主催のイベントで、この前マニラで校長先生を集めたカンファレンスでは数百人が集まりすごい熱気だった。先生、生徒、両方に愛されるサービスになってきている。
  • Quipper School Blog というものあり、そこでスクリーンショットと共に新機能の紹介をしているのでどういうサービスかある程度イメージできると思う。

開発と開発体制

個人的に、Quipperは人生2度目のスタートアップの参加なのだが、1度目の反省をよく生かせていると思っている。もちろん、新しい反省も色々出てきているが、それはそのうちまとめる。

いわゆる技術的負債のバランスには気を使ってきたつもりで、それなりにはあるものの、3年の間ピボットを繰り返したわりには(ピボットの際に捨ててきた部分があるからとも言えるが)、少ないと思っている。が、ここはCTOである自分の贔屓目があるかもしれないので、同僚の突っ込みを待つ。

メインとなるサービスがすでにあるので既存のコードとは向き合ってもらう必要はある。「0からでないと書けん。俺の好きな言語/フレームワークで今すぐやりたい!」みたいなのは、すぐには難しいかもしれない。ただ、最近流行りのマイクロサービスにも多少乗っているので、その辺では好きなようなことができるかもしれない。eactや

体制的な面を紹介すると、現時点で、開発者やデザイナー、プロデューサーといった、プロダクト開発側の人間が20人ちょっとくらい。これが9月くらいに35人くらいになる予定。このうち、東京オフィスの人が1/3くらいで、残りの人はロンドン、マニラにいる。

プロダクト/サービス側は、全員で一つのサービスを作っている。ただ、国によるローカライズ(翻訳だけではなくて、機能的なものも含む)みたいなところもあって、その場合はその国にいる人が中心で作る。

開発側と非開発側(マーケティングや営業)との関係はとても良好。多少開発側が遠慮されているかも、というぐらいのやりやすさがある。この文化はそれなりに頑張って作ってきた。フラットに言い合える方向を目指している。

開発項目は、社内のビジネス側の提案を受けたりの他は、データを見たり現地のユーザーの声を聞いたりを元に全スタッフが機能提案をし、プライオリティを付け実装している。

オフィスは、設立順に、ロンドン、東京、マニラ、ジャカルタ、メキシコシティにある。 社内公用語は英語だが、CEO/CTOが日本人だし、日本人社員も多いのでそこまで怖くないはず。

求める/またQuipperに合うと思われる人物像としては、

  • この成長フェーズを楽しめる人。
  • 制度や、仕組み、コード、サーバーいろいろなところにそれなりに問題あるが、そこも楽しみつつ改善できる人。
  • Edtechという一見華やかっぽいが実は裏側にある教育業界の地味さを楽しめる人。
  • 海外に出てみたい人(オンラインorオフラインどちらでも)。
  • 世界を変えたいと思いつつ、それなりに色々な意味で現実的な人。

また、今、開発側の課題としてはこんなものがあるので、この辺を解決してやろうではないかという人に是非参加して欲しい。

  • 効果的で継続できる学習サービスをどう構築するか
  • (先進国以外のマーケットが多いため)貧弱なネットワーク、PC/スマートフォンでも快適なUXをどう提供するか
  • どうしても複雑になりがちな教育サービスというものをどうシンプルに提供するか
  • 世界中に展開できるようなスケーラビリティ(開発的な面でもシステム的な面でも)を持ったサービスどう構築するか
  • 膨大に溜まっている学習データをどう活かすか

募集職種

DevOps的な人

つい先日まで、サーバーサイド専任の人いなかったのだが、そろそろチームを作って進めていくフェーズだと考えていて、今までは募集していなかったポジション。

正直なんて呼ぶのがよいのかよくわからないポジション。Cloud Engineerみたいな呼び方もあるみたいだけど、そんな感じのイメージ。AWSやなんやかんやを組み合わせあれこれする感じ。

世界で通用するサーバー側の構築や、データ分析/レポート基盤みたいなものも作ってもらうことになる。体制的に開発側との境がないので、下のWebサービス開発者との兼任も問題ない。というかむしろ兼任できるぐらいの人がいい。

Android or/and iOSアプリ開発者

Quipper、設立当初はモバイルアプリの会社としてスタートしたのだが、紆余曲折あり、途中でほぼAndroid/iOSのネイティブアプリ開発を止めていたが本格的に再開した。

UIデザイナー

特に、モバイルアプリ(Android/iOS)の設計/デザインをしてくれる人を探している。現在ロンドン、東京、マニラで計4人のデザインチームに入ってもらうことになる。アプリ愛のある人是非。

Webサービス開発者

Quipper開発陣で一番多い主力なところ。SPA(single page application)な構成が多いのでフロントエンドに強い人歓迎。このポジションも、ロンドン、東京、マニラに散らばっている。GitHubやSlackでのリモートでの同期/非同期がそれなりにうまく行っているので、そういう開発スタイルに興味ある人にも面白いはず。フロントエンド側はMarionette、一部Reactな感じ。サーバーサイドの言語はほぼruby。

応募先

応募は質問等はwantedlyの各ページからでもいいし、とりあえず話を聞いてみたいということであれば、直接 tomo at quipper.com にメールしてもらってもいいし、6月一週目に東京に行くのでそのときに直接会って話すのでもok(昼でも夜でも)。お待ちしています!

追記:



CircleCIでfeature branchをHerokuに継続deploy

15th Mar, 2014 (Updated on 4th Mar, 2016) | development heroku circleci

最近CIサーバーを自前Jenkinsから CircleCI に移した。CircleCIとても便利で簡単なのでオススメ。

CircleCIには普通のheroku deployは内蔵されているのだけど、 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 、をやるにはちょっと工夫が必要。

色々書こうと思ったけど、めんどくさくなったのでscriptを晒しておくだけにしよう!

この中で使われているスクリプト関連、特に秘密にする部分もないのでpublicでgithubに置いている。 https://github.com/quipper/deploy-support-tools

/circleci.yml

deployment:
  feature:
    branch: /^(?!^master$).+$/
    commands:
      - ./script/staging_deploy.sh
  production:
    branch: master
    commands:
      - ./script/production_deploy.sh

/script/staging_deploy.sh

#!/bin/bash -e

STAGING_APP_PREFIX="hoge-cms"
NUM_OF_STAGING_SERVERS=4

DEPLOY_SCRIPT=/tmp/deploy.$$.sh
curl https://quipper-deploy-support-tools.herokuapp.com/scripts/staging_deploy.sh.txt > ${DEPLOY_SCRIPT}
. ${DEPLOY_SCRIPT}

function prepare_for_staging_server() {
  heroku addons:add redistogo:nano || : # nothing if it's already installed
  heroku labs:enable user-env-compile
  heroku config:add \
      FOO=bar \
      BAZ=hoge
}

deploy

/script/production_deploy.sh (これは普通にdeployするだけのscript)

#!/bin/bash -e

HEROKU_APPS="<heroku app name1> <heroku app name2>"

DEPLOY_SCRIPT=/tmp/deploy.$$.sh
curl https://quipper-deploy-support-tools.herokuapp.com/scripts/production_deploy.sh.txt > ${DEPLOY_SCRIPT}
. ${DEPLOY_SCRIPT}

deploy

上のスクリプト、CircleCIのheroku deployの仕組みは使っていないので、HerokuのSSH keysの登録と、 上記スクリプトから参照される HEROKU_API_TOKENHEROKU_USER を、CirclCIのEnvironment variablesに設定する必要ある。



リリース力

15th Mar, 2014 (Updated on 4th Mar, 2016) | development

って、大事だなーと思っていてエンジニアの力の差が大きく出るところだと思っている。

  • 新規サービス
  • 新規アプリ
  • ちょっとした社内ツール
  • プロジェクトの進め方の改善
  • 大き目のリファクタリング

とかなんでも、とりあえず始めることは簡単だ。ただ、それを形にしてリリースしたり継続するのは難しい。

データベースのマイグレーションが必要だったり、最後の細かいUI調整もなかなか時間がかかる。色々な環境でのテストも必要だ。

技術的以外な部分でも、関係者との調整や、ユーザーへのお知らせ、面倒なことが多い。

開発者なら誰でも実感値あると思うけど「だいたいできた」から「リリース」までの距離はだいぶ遠い。自分の感覚としては「だいたいできた」で良くて半分くらい。楽しいのも最初の半分、後半は楽しくないことが多い。飽きも来る。

(これらの面倒なことを減らすのが、Quipper CTOである自分の役目だとも思っている、がそれはまた別の話)

経験値、みたいなものもリリースするとしないで10倍くらい違うと思っている。

それだけリリースは難しい。

なんか、だらだらと思ったことを書いてみた。

リリース力を鍛えよう。

(ちょっと前に pplog に書いたのを移動してみた)



非開発者もGitHub Flowに巻き込んでみんなハッピーになった話

17th Oct, 2013 (Updated on 4th Mar, 2016) | development heroku github

前提: GitHub flow を使っていてCIサーバーはJenkins

最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。

この改善をやる前の悩み:

  1. pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。
  2. コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。
  3. コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-requestで非開発者の人を巻き込めたらそこで気付けるのに。

これらの問題を解決するのに、feature branchもHerokuにJenkinsから自動的にデプロイするようにしたら色々幸せになれた。

具体的には、N個(N=アクティブな開発者の数くらいが良さそう)のfeature branchのテスト用のHeroku appを予め作っておいて、feature branchにpushされるたびに、Jenkinsからその中の一つへデプロイされる感じにした。

補足:

  1. 同じfeature branchの新しいpushがなるべく同じHeroku appにデプロイされ続けるようにとか、heroku configもするとか、多少工夫してる。
  2. 初期の頃、feature branch毎にJenkinsから毎回heroku createしてたが、それはさすがに怒られそうなので、複数をローテーションで使うようにした。
  3. いまどき?だとJenkinsで動的に仮想環境とか作っちゃうのもありだと思う。でも、Herokuが楽過ぎて頑張って仮想環境作る必要もないかな、というのが現在の弊社の状況。

非開発者にもレビューして欲しいときは、pull-request上でmentionして、heroku上のデプロイされたものを見てもらう感じ。基本的にUIに変更のあるようなものは非開発者もチームほぼ全員見るようにしている。

数ヶ月運用してるけど、もうこれなしでは生きるのが辛い感じにまでなってきてる。

非開発者の人もとても楽になった感じで、それまでは、色々な変更が入った(または肝心なものがコミュニケーションの問題で入っていない)masterブランチが動作しているのを見るしかなく「何が」実際変更されたのかわかりづらかったが、このフローにしてから、変更点がわかりやすく開発者とのコミュニケーションもだいぶ楽になった。また、チームメンバーの誰かが「思ってもみなかった」変更がいきなり入ってしまうということもなく、だいぶストレスが減った感じ。

また、開発者も、それまでは、merge後、非開発者に指摘されると「めんどくせーなー」という意識が生まれがちで、かつ、その場合mergeから時間が経っていることも多く、その変更に対するフレッシュさが減り、再度作業を始めるまでの心理的な負担(実際、実装を思い出すための脳のコストも高そう)も高かった。それが、pull-request中に非開発者からフィードバックが貰えることで、そのpull-requestにcommitを追加することだけでさくっと修正できて、全体のスピード感がとてもあがったし、開発者の負担も減った。

つまり、pull-requestのmergedがチームメンバー全員にとってのDONEというステータスになり「実装終わったけどまだ本番には入っていない」とか「チームメンバーが納得してないものが本番に入っちゃった」みたいな事故/ストレスを減らせた。Done means DONE!

これらの結果、masterにmerge後、Jenkinsからの自動デプロイもかなり安心してできるようになった。

おまけ:

@hsbtさんが いい感じのGitHub flowベースのワークフローをあげていたので、弊社(Quipper)との差分を書いてみる。

  1. masterブランチは常にデプロイ可能な状態でかつ自動デプロイされている。
  2. なので、手でデプロイという作業は発生しない。
  3. WIPのpull-requestはそれほど推奨してない。この辺はpull-requestの粒度の話もあるので別エントリで書きたい感じ。
  4. 関連して、チェックリストみたいのも基本作らない(必要ない)。
  5. mergeはレビューした人が行う。
  6. コードレビュー以外のテストも上に書いたように、feature branchでしてしまう。
  7. インフラメンバーいない。(が、そろそろ欲しい! 興味ある人ご一報を)。
  8. Release’s notes 作成してない。

フローの中でGithub(とJenkins)の外へ出たくない、という方針。

この辺りって、絶対的に正しい方法というのはなく、組織のサイズとかサービスの規模に応じて、ダイナミックに変えていくのが正しい道だと思っている。

追記: CircleCIで上記のことをする方法書いた