Quipper組織変更と41歳CTOの今後

10th Jun, 2017 | quipper

最近、自分自身に関わる人事で大きな変更があった。久しぶりにブログを書いてみる。

結論から言うと、先月まで、プロダクト、開発組織、技術の3つを担当していたのだが、プロダクトと開発組織を完全に移譲することになった。

その結果、自分のレポートラインとしては移譲した人だけが部下という形になった。Quipperを始めた6年半前、最初のエンジニアに入ってもらって以来の少なさだ。これは自分としてはなかなか大きな変化である。

振り返ってみると、Quipperが始まってから6年半、Web/アプリ事業会社のCo-founder/CTO としてありがちなコースを歩んできた(最初はタイトル的にはCTOではなかったけど)。初期はとにかくコードを自分でがりがり書き、サーバーの面倒も見るし、とにかく何でもやるエンジニア。そして組織の拡大とともに段々とコードを書く時間が減っていくというやつだ。

特にリクルートグループ入りした2年前からはスポットでコードを書くことはあっても、日常業務としてコードを書く時間はほぼゼロになってしまった。これは別にリクルート流のマネージメントをしなくてならなくなってそっちが忙しくなった、とかではなくて、そのタイミングで大きなプロジェクトが始まったり、採用を強化して、自分が書かなくてもパワー的に問題ない状態になったことと、組織/システムの規模がどんどん大きくなり片手間ではシステム全体を見きれない中、中途半端な形で手を出すのは良くないだろうというところからだ。

そんな感じで、技術をあまりやらず、組織、プロダクトに集中しているつもりだったのだが、それはそれで問題が出てきた。

現在、Quipperが展開しているメインな国というのは日本、インドネシア、フィリピン等のアジアの国々だ。また、最近はネットで完結するようなビジネスだけではなく、現地に根付いたこともどんどん増えてきた。

そんな中、日々現地で様々なことが起こる。そして、ロンドンとの時差は辛い。色々なことが自分が寝ている間に起き、みんなが困っている頃に自分が起きてくる、というどうにも悩ましい感じが続いていた。朝起きると、Slackのたくさんの部屋やプライベートチャットでメンションされている、みたいな状況だ。どうしても後手後手になってしまう。

一方で、技術方面も、短期的には問題なくても、中長期で問題になりそうなことがいくつか出てきていた。

元々の3つの担当のうち「技術」が一番できていなかった。技術から遠ざかっているCTOという感じだ。日々の開発では優秀なエンジニアがたくさんいるし、自分が時間をかけなくとも「回る」のが技術だったというのがあった。そもそも普段コード書いてないやつが「技術」だと振り回しても誰もついて来てくれる気がしなかったし。

技術側の課題感としては、一つは、みんな大嫌い「技術的負債」である。Quipperのベースシステムはそれなりに古い。ビジネス的なピボットを何度か繰り返す中、今となっては意味をなさないコードもたくさん残っている。今すぐ作り直さないと死ぬというレベルではないが、そろそろ大きく手を入れないと2年後3年後やばそうだという感じはある。自分が中心になって作ってきた「負債」であるという認識もあるので、しっかり責任を持って返していきたいというのもある。また、開発者が増えたこともあり、また、プロダクト/サービスの方向性が固まってきた今、中長期で技術的にどういう方向に行くのか、というのをしっかり技術トップとして打ち出していく必要があるというのも強く感じ始めたというのもある。

もう一つは、自分がそういう文化を作ってきたのだが、技術的に新しいことや面白そうなことをするよりも、とにかくサービスに集中するというのを第一にしてきた。「会社」なので、まずビジネスとして成立しないと話にならないと思ってきたからだ。だが、そろそろ会社のフェーズ的にもちょっとだけ遊び心、またエンジニアの成長、そしてまたそれが会社にとって大きなジャンプにつながるようなこともやってもいいという文化にしていくべきなのかなと思うようになってきた。そっちに向かうときに一番の敵になりそうなのは自分が作ってきた文化なのはちょっと面白い。

そんな感じで、プロダクト、組織が後手後手になってしまいパフォーマンスが出せてなく、他方で技術方面も中長期でまずそうだというこの状況をなんとかするために、少し前から部分的に移譲していきたいとCEOや経営陣と話していた。ただ、それなりに大きな体制変更なのですぐには変えられないようなあと思ってはいたのだが、そこはなかなかのスピード感のQuipper(&みんななんとなくそう思っていたのだろう)、色々なところが動き出し、あっと言う間に体制変更が終わった。

色々議論した結果「プロダクト」「開発組織」「技術」のうちの「プロダクト」「開発組織」を移譲することになった。つまり、残るは「技術」だけになった。なかなかいいストーリーだ。結果的に、よくあるCTO / VP of Engineering 体制に近い体制だ。ただ、移譲先の人には、開発組織だけでなくプロダクト開発組織全体も任せてしまったのでVP of Productということになった。VP of Engineeringも内包しているイメージだ。

そんなわけで自分自身は技術に集中することになった。とは言え、繰り返しになるが、ここ2年くらいまともにコードを書いてないし、トレンドを必死に追いかけていたわけでもないし、自分自身に大きなプレッシャーを与えた感じになっている。組織だ、採用だーとかの自分の中での言い訳もできなくなってしまったし！

とりあえずR&D(仮称)という組織を作った。と言ってもとりあえずメンバーは自分だけ。わりと急に色々なことが決まったので具体的に何をするかはまだ決めていない。まずは現状の再確認をしているところだ。どういう形がQuipperに一番フィットするのかまだよくわかっていないので、色々試行錯誤しながら進めていきたいと思っている。

また、組織(people)マネージメントから離れたことで、自由にできることもあると思っていて、直接マネージメントしているとできないような、ちょっと離れたことで逆に開発組織が活性化するようなことができていけたらなあと思っている。

最後になるが、最初に付けたタイトルは「Quipper組織変更と41歳CTOの生存戦略」だったんだけど恥ずかしくなって変えた。最近流行りのエンジニアの生存戦略だが、今まであんまりそんなことを考えたことがない。あえて言うと、あまり先のことを考えずに目の前の流れに乗ることと、また組織(会社)のために自分がすると効率がいいことを見つけてするということが結果として自分の生存戦略なのかなあとは思うことはある。これを社畜というのかな？ 今回もそんな感じであまり自分の生存戦略という観点では考えてなかったのだけど、後付けで自分のキャリア(生存戦略)とつなげて考えてみると、このぐらいの規模の組織を作ってから同じ会社で技術に戻る、というのはなかなかいいキャリアなのでは？ という感じがしている。組織/マネージメントに行ったきり開発に戻ってこない人が多い中、俺は違う！！と思うところはある。そもそもやっぱりコード書いている方が好きだし。もちろんどういう結果を出せるか、というのが大事なんだけども。

そんなわけで社外に出すことでさらに自分にプレッシャーをかけるためにも久しぶりにブログで現状報告してみました。



短期連載Quipper CTOより 第4回: スタディサプリ開発の裏側

4th Mar, 2016 | quipper

リリース完了

スタディサプリ高校講座/大学受験講座を無事リリースすることができた。 大きなトラブルもなくリリース後数日での「数字」的なものもとりあえず一安心という状況だ。

人生何度ものリリースを経験してきたが、今回のリリースは今までとは違う大変さがあった。

このプロジェクトが始まったのはリクルートの昨年のQuipper買収後少し経ってからになる。既存の受験サプリをQuipperプラットフォームに載せ替えるというのが大きなお題だ。リリース予定は2016年2月末。教育業界、季節性がとても大きいのでこのデッドラインは遅らせることのできない厳しいものだ。

また、今回はシステム面の置き換えだけでなく、受験サプリからスタディサプリへのブランド統合も同時に行った。Quipper開発陣も当然のことながらこれにも関わることになった。

そして、受験サプリからの継続ユーザーもたくさんいるので、課金機能などは既に受験サプリにあるものから大きく変えることができない。またサービスの質という面でも既存の受験サプリから落とすわけにはいかない。

ただ、今回のシステムを載せ替えるにあたり、現行の受験サプリであまり使われていない機能を落としたり、複雑なものをQuipperが考えるよりよい方法で再実装したりもできた。二つのシステムを統合したら機能が増えすぎて複雑になってしまいそうなものだが、逆に本当に必要な機能を見極めるいい機会と捉え、コアとなる部分だけを備えたすっきりとしたサービスにできたと自負している。

サーバー構築という面では、今まではHerokuやMongoLabなどを使っていたのだが、今回は、今後の更なるQuipperの世界展開も見据えてということと、ユーザーが日本からということでわざわざアメリカにサーバーを置くこともないだろうということで(HerokuのPrivate Spacesも検討したが今回は見送り)、AWS上に自分たちですべて構築したというのも大きい。この辺の話は スタディサプリ on Quipper プラットフォームを支える技術 に詳しくある。今後、Quipperの日本以外の地域でも順次この方向に切り替えていく予定だ。

そして、今までQuipperの展開国でのシェアが少ないことから開発を行っていなかったiOSアプリだが、日本というiPhone大国でiOSアプリなしというわけには行かないので、この開発もチーム作り含め0から行った。

つまり、既にたくさんのユーザーに使われしっかり軌道に乗っているサービスのリプレースであり、更にデッドラインがしっかり決まっていて、かつそのデッドラインが半年以上先の巨大リリースであり、クラウドとは言え自前でのサーバー運用に切り替え、しばらくの間QuipperがしてこなかったiOSアプリ開発も行い、同時にブランド変更もあり、課金含む重た目の機能の仕様もほぼ決まっていて機能を落とすことができないものも多い、というなかなか辛いプロジェクトだった。Quipperは、短いサイクルでのリリースを主にしているので、こういう開発は正直得意とは言えない。

ただ、そこは柔軟で経験も豊富な開発者が揃っているQuipper開発陣、なんとか対応してリリースにこぎつけることができた。手前味噌にはなるが本当に強いチームだなあ、と思っている。

リクルートのチームとの関係

そして、プロジェクト開始当初もう一つの大きな課題だと感じていたのが、リクルートマーケティングパートナーズの皆さんとの融合だった。元々、彼らがサービスやブランドをじっくり育ててきた受験サプリというものをQuipperのプラットフォームにするということで、心理的な抵抗もなくはなかったと思うし、プロジェクトの進め方も、それまで彼らがしていた外部組織での開発からチーム一丸となった開発へと大きく変えてもらった。また上で書いたように、より良い(とQuipperが考える)サービスにするために機能を落とすことにも同意してもらったりもした。Quipperが歩み寄った部分もあるが、全体的には7:3くらいで多めに向こう側に歩み寄ってもらったという感じを受けている。また、Quipperのいいところを消さないようにとだいぶ気を使って貰っていた感じもする。今後はさらに、どちらの会社側という言うことなく、スタディサプリチームとして更に一体となって進んでいくことになっている。

今回リリースしたサービスとQuipperにとっての意味

今回のサービス構成だが、基本的には、既にQuipperが海外で展開しているQuipper School / Quipper Videoに受験サプリのコンテンツを載せ、同時に日本独自の課金システムを載せ、それにあわせ登録フローの変更だったり、会員体系の持ち方を日本仕様にしたり、デザインをスタディサプリ仕様のものにしたり、一部スタディサプリ専用機能を実装したりが主なところだ。

また、スタディサプリは、Quipperコンテンツと比較し動画でのレッスンが占める割合が大きいので、動画回りの使い勝手を向上させるために、Quipperとの共通部分もかなり作り直した。これを先行リリースしたのが、去年の夏頃にリリースした インドネシアでのQuipper Videoになる。先日同じものをメキシコでもリリースした。

このようにベースとなる一つのサービスを世界で展開していくのがQuipperの基本戦略の一つだ。開発サイドとしては、今回、日本の開発メンバーを中心にスタディサプリという日本市場向けにサービスの改善も行ったが、同時に、良くしたものがインドネシアやメキシコでもリリースされるというお得感もある(サーバーは日本とその他で分けている)。

今後

今回のリリースで、開発側は一息つけるので、ここで体制等を見直し、これからのスタディサプリを含むQuipperサービス全体のクオリティ向上や、新サービス/新機能開発をどう行っていくかということを現在検討している。各国のマーケットのニーズをどう統一したサービスに取り入れていくのかが大きな課題だ。この辺の話を次回以降このブログで書けたらと思っている。

いつもの

そんなQuipperですが、開発チーム全ポジション積極採用中です。



短期連載Quipper CTOより 第3回: Quipperの開発体制の今

3rd Mar, 2016 | quipper

注記: なんとなく個人ブログとは切り離したくてgistで始めたのですがあまり意味がなさそうなので統合します。これは ここ に載せたものの転載です。

今回はQuipperの開発体制と進め方について書いてみようと思う。

開発チームの規模

第一回で紹介したように、Quipperは、ロンドン、東京、マニラ、ジャカルタ、メキシコシティにオフィスがあり、そのうちロンドン、東京、マニラが開発拠点になっている。

内訳としては、以下の様な状況だ。

Web iOS/Android Engineering Design Total
London 3 0 0 1 4
Tokyo 5 4 3 1 13
Manila 7 1 0 2 10
Total 15 5 3 4 27

30人弱。この規模から、今年中に3拠点合計で10人くらいの増強を考えている。拠点毎、職種毎の大まかな計画はあるが、いい人がいたら拠点/職種毎の採用の増減はある感じで、3拠点全職種トータルで考えて一番強いチームにしたい。

Engineeringは、Quipperでの呼び方で、インフラとか運用とかそういう感じのチームだ。最近だとDevOpsと呼ばれているものも近いだろう。

これらの直接開発を行うメンバーに加え、プロダクトマネージャー的なロールとして4人いる。

フラットな組織

開発組織は基本的にはフラットな形にしている。フラットと言っても、経験/技術力に差がないわけではないので、自然と各自が時と場合に応じてリーダシップを取るという感じだ。

フラットな組織はいつも魅力的に見えるし、なんか自由な感じがかっこいいし、自分自身も好きだし、とてもいいとは思っているのだけど、現実を見ると難しいこともあったりする。たとえば、明示的な開発リーダーみたいな人がいれば、その人が義務感や責任感を持って色々なことを主導していきやすいが、フラットだとそういうものに期待しづらい。そんなとき中間管理職的なポジションを置きたくなってしまう。

しかし、前回書いたように、自分の中の理想として、全員がしっかりユーザーや社内の非開発者と向き合い自分で課題を見つけ前面に立っていく、というのとフラットな組織は相性がいいと思っているので、しばらくはこの形で行きたい。また、上にも書いたように、特に会社として指名しなくても、時と場合に応じてリーダ的な存在は出てくるもので、それはそれでいい。

ただ、これができるのは、そこまで大きくなく強いメンバー/強いチームであるというのが大前提なので、そういうチームを維持できるようにCTOとして頑張りたい。

DevSupportという仕組み

Quipperの開発チームは、新規開発と保守運用と言った感じで役割を分けていない。全員で新規開発し、全員で保守運用をするというのが基本方針だ。

ただ、開発者にとって、新規開発の方が楽しいことが多いし、新規開発にはある程度のデッドラインみたいなものがあったりするので、保守運用に力が入らなかったりする。また一部の頼まれやすい人にそういうタスクが偏ってしまうのも程度を超えると問題だ。そこで、Quipperでは、DevSupportと呼ばれるちょっとしたゲーミフィケーション/見える化の仕組みを導入して、その辺を解決しようとしている。

これは、各メンバーに月ごとに達成すべきポイントが課せられ(通常10ポイント。新人やポジションにより例外あり。)、バグや、何かビジネス側のサポートが必要な案件(ちょっとデータを出して欲しいとか)が発生したら、まずGitHubにissue登録し、重要度/緊急度/難易度に応じて、ポイントが割り振られる(1/3/5ポイントとか)。 各自が自分ができそうなのを選び対応しポイントを消化するという感じにしている。

ただ、いくつかこの方法に問題があって、ポイントが高くても、あまり人気の出ないタスクというのが一定数あるので、そういうのはこの仕組を回す責任者が、ある程度の強制力を持って開発者を指名して振ることができるようにしている。また、緊急事態が起きた場合には、これとは全く別に開発者全員で当たるなど柔軟な感じでやっている。

この制度を始めて6ヶ月が経つが、最初の頃はいまいち盛り上がらなかったが、最近はうまい感じで回ってきている。

これは、先月の様子だ。ポイントの管理はこんな感じでGoogle Sheetsで管理している。

1月のDevSupport

一番左端がオフィスを表しているのだが、T(東京)の人達が軒並み0ポイントなのは、今東京メインで行っているプロジェクトが佳境だからで、彼らが非協力的と言うわけではない！ この辺のプロジェクトの波みたいのも全体的に柔軟にやっている。

開発者間のコミュニケーション

開発者のいるオフィスが3拠点に散らばっていて、かつロンドンは他の2ヶ所と比べ時差も大きいので開発者間のコミュニケーションは結構大変だ。密なコミュニケーションが必要な新規開発はオフィス毎にチームを作って行うことが多い。

余談になるが、以前、完全にオフィスを跨いでチームを作るということを試したのだが、さすがにちょっと厳しかったので今の形に落ち着いている。ただ、新しい仕組みや体制を失敗を恐れず導入し、失敗だと思ったらあっさりやめる、ということができているのはQuipperのいいところだと自負している。

ただ、オフィス毎にプロジェクトは別とは言え、どの拠点でも同じコードベースを触るし、上のDevSupportでは協力して行うこともよくある。また、GitHubでのpull-requestのreview/mergeみたいなものは国をまたぐのは全く問題なく、むしろ推奨している感じなので、そういうときには国をまたぐコミュニケーションもよく発生する。

また、SlackやGitHub issues上でも随時コミュニケーションをしているが、二週間に一度、開発者全員がSlackのあるチャンネルに集まり、文字チャットでのミーティングをしている。ここでの議題は誰もが提案することができ、日常のGitHubやSlackでは収拾のつかなかったものなどを中心に集中的に議論している。文字ベースのチャットにしているのは、20-30人での音声でのリモート会議かつ英語が得意ではない人もいる、というのは辛いというのがある。

日々のリリースとテスト

release early / release often ということで、月曜から木曜の間で毎日リリースを行っている。休み前リリースは怖いので金曜日はしていない。

半年くらい前までは、pull-requestのmasterへのmergeと同時に自動でリリースしていたのだが、いくつか連続してリリースでの問題が起きてしまい、対策として手動でのテストとセットでの一日一回のリリースに変更した。

もちろんテストコードでのテスト自動化も行っているが、それに加えて、テストケースに沿って人間がするテストを日々のリリース前に行っている。このテストは非開発者と開発者両方が参加することになっている。つまり、BizDevだったり営業だったりする人にもテストに参加してもらっている。

非開発者にも参加してもらっているのは、毎日のことなので、開発側の負担軽減のためという面もあるのだが、会社全体でプロダクトのことをしっかり意識するとか、開発者と非開発者の積極的な交流、細かい仕様の理解を非開発者にもしてもらうとか、どの辺が開発で大変なのかみたいなところもなんとなく感じてみて欲しいという意味がある。非開発者側も日々忙しいので、なかなか心苦しいことでもあるのだが、結果としてはなかなかいい取り組みになっている。

これは、前回書いた開発側も非開発側にどっぷり入って欲しい、ということの逆側で、非開発者も開発側に寄ってきて欲しいという考えから始めたことの一つでもある。

また、開発者/非開発者問わず、新しく入った人のプロダクト理解という意味でも、テストをして貰うというのはなかなかいいアイデアなのでお勧め。

2016年の開発

2015年の後半から後もう少しの間、受験サプリの移行というのが開発全体に占める割合が大きいのだが、これが一段落したら、Quipper開発が次のフェーズに入ることができると考えている。というのは、これが終わると日本でも大きくQuipperシステムが展開されることになり、今後の開発は日本を含む展開国(インドネシア、フィリピン、メキシコ)に向けた機能拡張と、さらなる新規国展開という2つの軸に整理されるからだ。ある意味でスタート地点に立ったとも言える。ちょうど今、機能拡張部分のプロダクトロードマップを作っているのだが、とてもおもしろい感じになりそうでワクワクしている。

採用活動中

そんなQuipper、2016年に入ってから久しぶりの積極採用を行なっている。少しでも興味ある方いたら、こちらからお願いします。



短期連載Quipper CTOより 第2回: Quipper開発チームに入って欲しい人

3rd Mar, 2016 | quipper

注記: なんとなく個人ブログとは切り離したくてgistで始めたのですがあまり意味がなさそうなので統合します。これは ここ に載せたものの転載です。

前回、現在のQuipperの状況みたいのを書いたが、今回は、普段CTOとして、どういうことを意識して開発チームを作っているか、どういう開発チームになって欲しいと思っているか、というのを書いてみたいと思う。

この辺り、自分自身の経験からくる「好み」とか「美学」みたいなものが強めな部分でもあるので、表に出すのはなかなか勇気がいるが、co-founder/CTOである自分のそういうところが、開発チームのカルチャーに当然影響しているし、一緒に働くことになる人ととはカルチャーのマッチがとても大事だと思っているので出してみる。

まず、以前、社内でなんとなく書いた文章があるのでそのまま出してみる。これは開発者の採用活動に当たり、どんな人が欲しいと思っているか率直に書いたものである。

以下、「開発者」と書いてある部分は、Web開発者/iOS開発者/Android開発者/デザイナー/インフラ等の人達を指している。

欲しいタイプ

最近色々な採用記事とか本とか読んでいても、自分の前職やQuipperでの実感からも、QuipperのようなWeb/アプリでサービスを作るような会社は、人間性/チームワーク/ビジネス理解みたいのが本当に大事で、(狭い意味での)技術力はその次かなと思うようになってきている。

というか、Web/アプリ/インフラ周りの技術がコモディティ化する中、 人間性/チームワーク/ビジネス理解みたいのがしっかりした人であれば、必要な技術力は入ってからでもなんとかなる、と思うところもある。(どうにもならない人がいるのも知っているので、そこはもちろん頑張って弾く)

ただ、「技術力が低くてもいい会社」みたいに思っているわけでも全くないし、外からそう見られたくもないんだけど、伝わるかなあ。

そもそも、Web/アプリ制作の場合、「技術力」というのが、コーディングだったり技術的な設計だったりの範囲を超え、技術者以外とのコミュニケーションや、ある程度のビジネス的な感覚まで含めたものだと思っている。

で、別にそういうハードル(人間性/チームワーク/ビジネス理解)を設けたとしても、来る人の(狭い意味での)技術力が下がるような気は実はあんまりしていない。むしろ高くなることを期待すらしている。ただ、 多少、分かる人には分かるでしょ、みたいな募集になってしまうかもしれないんだけど。

まあ、今までも人間性/チームワーク/ビジネス理解みたいなハードルは自分の中ではあったつもりなので、それを表に出しちゃおうかなという感じなだけなんだけども。

なんていうか、どのスタートアップぽい企業も同じような募集をしていているんだけど(XXXな言語使える/GitHubある/slackです/環境自分で選べます/椅子がいいです/企画に参加できます、みたいな)、Quipperはもう一歩先の採用ができるんじゃないかなーと思っているんですよね。

ちょっと抽象的過ぎますかね。また、それをどうjob descriptionとかに落とすのかよくわかってないですが、なんとなくそういう面を出せたらなあと思っています。 どう思います？

社内の日報的なところに書いた文章でちょっと端折っている部分もあるがそんな感じに思っている。一点、「人間性」ってのはあまり的確ではない気がしてきたが。

また、「QuipperのようなWeb/アプリでサービスを作るような会社」というのは、自社でサービスを作りそのサービスの対価を得るような会社であり、かつまだまだビジネスとして成長過程にあり、技術に特化したR&D部門のようなものを置くような規模ではないフェーズ、のようなニュアンスで書いた。

さて、どうしてこう考えるかになったかだが、Quipperでは、開発者だけがQuipperサービスの価値を作っているわけではなく、そこに乗るコンテンツを作ったり、それを広めてくれるマーケティングや営業を行い、カスタマーサポートや学校への導入サポート等の人がいて始めて成立するものとなっている。教育(EdTech)、いいサービス/アプリだけで自動的に広まってくれるようなものではないというのが最近痛感していることだ。

そういった人や、お客さんであるエンドユーザーももちろん、直接、開発者自らが課題や要望を汲み取るべきだと思っている。もちろん、そういうことが得意なプロデューサーやディレクター/プロダクトオーナー/プロダクトマネージャー等と呼ばれる人達もいるのだが、開発者もそういう人達と同じ土俵でしっかりコミュニケーションするべきだと思っている。

そんな中で、ビジネスやユーザー、開発チーム以外のことに全く興味もなくコードだけ書いていたい、みたいな人は厳しい。そして、今のところそういうことができる人が結果的にQuipperに集まっている気がするし、これから人が増えていく中で、そういうところは変わらないようにしたいと思っている。

もちろん、技術力がいらないわけではなくて、高いレベルでサービスやアプリの開発、運用をする技術を持っていることは大前提ではある。

ちょっと別の角度からになるが、もう一つ、自分の好みとして、基本的に「伝言ゲーム」や「ハブになる人」みたいなのが好きではないというのがある。よく開発組織で起きがちなのは、エンドユーザーや社内の他チームからの問い合わせや要望を、開発者が目にするまでにフィルターし編集し開発者から直接見えないようにしたり、忙しい開発チームを邪魔しないように、非開発者は開発者に相談があるときでもプロダクトオーナーであるAさんを経由するべき、とかである。これ、開発者を守って生産性を上げるため、という一見前向きな理由で採用されがちなアイデアだし、実際、そういうのは開発者としては嬉しかったりもするのだけど、自社サービスを作るような会社では良くないし非効率だと考えている。

間に置く人が多ければ多いほど、いろいろ情報(エンドユーザーの声だったり)は間違って伝わるし、自分の問題としてとらえづらい。そもそも、間に人を置くと、情報をどこかで間引かないかぎり、社内全体での必要なコミュニケーション総量が倍々になってくる。これが「ミーティングだらけ」の原因にもなったりするしとても非効率だ。コミュニケーションは基本的に面と面で、多対多のメッシュ状の組織であるべきだと考えている。同時になるべくオープンに行うべきだとも思っている。

(これと指揮系統という意味での組織の形、たとえばフラットな組織がいいのかどうかみたいなのはちょっと別の話だと思っていて、どういう組織がいいと思っているのかは改めて別の回に書きたいと思っている)

ただ、こういう組織であるためには、当然、開発者には非開発者としっかり話せることが要求されるし、ちゃんと非開発者とコミュニケーションできることが重要になってくる。ということもあって、社内で効率的なコミュニケーションをするためにも、開発者のコミュニケーション力を期待している。もちろん、非開発者にも、開発者とちゃんと話せるような、Web/アプリなどの基本的なところや、システム開発の難しいところ等を理解してもらうようにしている(例えば、「開発前に正確な見積もりは基本的に不可能！」とか)。

そんな感じで、開発もしっかりでき、社内コミュニケーションもしっかりできる、そんな開発者をQuipperは求めている。こんなQuipper開発チームに興味がある人がいたら https://jp.wantedly.com/companies/quipper/projects あたりから、今すぐの転職を考えていなくても、まずオフィスに遊びに来るとかでも是非！

次回

Quipper、現在何人くらいの開発体制で、今後どのくらいの規模のチームを計画しているのか、どういう体制を目指しているみたいなところを書いてみたいと思う。

次回はこちら。



短期連載Quipper CTOより 第1回: Quipperの今

3rd Mar, 2016 | quipper

注記: なんとなく個人ブログとは切り離したくてgistで始めたのですがあまり意味がなさそうなので統合します。これは ここ に載せたものの転載です。

これはなに

なんとなく始めてみた短期集中のQuipperのCTOブログ。リクルートグループに入り、ますます日本での活動が増えているQuipperなので、CTOとして、開発、プロダクト、サービス、チームに関わることを書いていこうと思っている。今回は、第1回ということで、Quipperの現状について書いてみようと思う。

最近のQuipper関連記事

まず、最近、世の中に出たQuipperについての記事を。

リクルートグループ入りしてから9ヶ月経って

以前、自分のブログに、3ヶ月時点( http://blog.madoro.org/mn/97 )でのことを書いた。その後、更に6ヶ月が経った。あの3ヶ月時点ではQuipper/リクルートのメンバー双方がお互いの様子を見つつ、手探りな感じだったが、その後、共同のプロジェクトを進めたりするうちに、だんだんとお互いのことがわかり、一部での融合も進んでいる。どんなことが起こっているかを書いてみようと思う。

まず、良いところばかりだと嘘くさいので、最初に辛いことも書いてみると、何人かの人がこの間に辞めた。これはちょっと残念なことだったけども、リクルートどうこうよりも、買収というのがいいきっかけになったということが大きいようだ。人が辞めるというのは会社をやっていく中で、常に最上級で辛いことだけど、人が入れ替わらない、新陳代謝しない怖さというのもあるので仕方ないと思うようにしている。

そんな辛いこともあったが、前回の採用強化期間( http://blog.madoro.org/mn/96 )で、応募してくれた人たちが9月10月にたくさん入社しチームはだいぶリフレッシュした感じになっている。今回の採用ではWeb開発者はもちろんだが、iOS/Androidチームも強化することができた。また、インフラ側(Quipperではengineering teamと呼んでいる)もかなり強化された。

そんな入れ替わりもあったが、今、Quipperの創立以来、開発チームの状態はかなりいい方だと感じている。なんでかな、と考えてみると、exitしたことで当面の資金や増資みたいなのをそこまで気にすることなく、太くシンプルな戦略を元にサービスに集中できるということが大きそうだ。

次にリクルートの人との交流だが、Quipperはリクルートマーケティングパートナーズ(以下RMP)という会社の傘下にいるのだが、RMPの人との交流は徐々に進んでいるという感じだ。

RMPの開発者の方々とは当面の間は、業務/プロジェクト面での大きい交流はなさそうなのだが、共同の採用サイトの構築や、勉強会や飲み会、Slackでの技術的な質問やミートアップの共同開催みたいなところで交流が始まっている。社外と社内の間の距離感で色々情報交換できるというのはなかなかいいなあ、と思っているので今後もっと積極的に交流していきたいと考えている。

また、RMPの事業側の一部の方とは、受験サプリ( https://jyukensapuri.jp/ )にQuipperシステムを使うという案件があり、そのメンバーの方々とは日々密にやりとりをしている。現在の東京オフィスは、RMPオフィスのすぐ側(徒歩1分)にあるので、物理的な行き来やミーティングも日々行っている。

正直なところ、やはり日本の大企業という面で、それなりに大変なところもあるが、思っていたよりはだいぶやりやすいというのは感じている。というか、Quipperのやり方をなるべく尊重しようとしてくれているんだなあというのは随所に感じられ、その辺はとてもありがたい。例えば、オンラインのコミュニケーションは基本的にすべてGitHubのissuesと、Slackで完了しているし、ミーティングも形式張ったものばかりということもなく、必要に応じて最小限にという感じになっている。

最近のQuipper - 海外

https://www.wantedly.com/companies/quipper/info に最新の状況を載せてあるが、海外では、学校先生向け機能であるQuipper Schoolと、ビデオ学習サービスであるQuipper Videoという2つの事業を行っている。機能的には、Quipper SchoolとQuipper Videoは独立したものというわけではなくQuipper Videoを学校利用(Quipper School経由で)することができたりもする。

Quipper Videoは、数ヶ月前にスタートしたものなのだが、既存のQuipperサービスの動画機能を大幅に強化したもので、リクルートの受験サプリのノウハウもふんだんに入ったものになっている。既にインドネシアでリリース済で、今後メキシコ、フィリピンと続いてリリースしていく予定になっている。

最近のQuipper - 国内

日本でもいくつかの取り込みを行っているが、その中で今一番開発のパワーを投入しているのが、上述した受験サプリのQuipperプラットフォームへの移管になっている。既に知名度もありユーザーもたくさんいる受験サプリをQuipper上で動かすという、とても大きなプロジェクトだ。

基本的なサービスとしては上記Quipper Videoとほぼ同じものなのだが、課金周りや一部特殊なビジネス要件(はい、大変！)の開発をしている。日本でクローズドベータテストやユーザーインタビューを行ない、日本のニーズに合わせた改善なども行っている。もちろん、海外でも使えるような機能はそのまま海外向けQuipperにも反映されるようになっている。

5事業拠点、3開発拠点 体制

現在Quipperのオフィスは、ロンドン、東京、マニラ、ジャカルタ、メキシコシティにある。その内、ロンドン、東京、マニラの3拠点で開発をしている。

この3拠点は、それぞれ固定的な役割があるわけではなく、Quipperにとって一番いい形になるように常に変化させつつ進んでいる。現在は、東京オフィスは上述した受験サプリの移行に集中モードになっていて、ロンドンもそれをサポート、マニラの開発チームはQuipper Videoの海外展開を担当しているという感じになっている。

基本的には、同じコードベースに手を入れることになるので、日々GitHubやSlackでやりとりをしつつということになっている。また、先月には、マニラの3人の開発者にRubyKaigiに合わせ来日してもらい、直接の交流なども積極的に行っている。一度実際に会うとその後のリモート開発が楽になるので定期的にしていきたいと思っている。

今は、CTOの自分含め受験サプリ移行に集中モードになっているのだが、数ヶ月後新しいQuipperプラットフォームでの受験サプリを日本でリリースした後には、日本を含む各国で発生した課題や、ユーザーからの要望、また各国でのビジネスプランを、プロダクトやサービスにどう反映させていくかという段階になる。

また、上では、日本と海外とを分けて書いたが、実際には、Quipper的には、日本は展開国の中の一国という位置づけで、今はその立ち上げのためにリソースを割いているという状況と考えている。

採用中

そんなQuipperだが、今年も積極的に採用を計画している。もし興味がある人がいたら https://www.wantedly.com/companies/quipper/projects あたりから、今すぐの転職を考えていなくても、とりあえずオフィスに遊びに来るとかでも是非！ また、来週にはRMPと合同のミートアップも計画しているので、そちらもお気軽に参加どうぞ。 http://rmp-quipper.connpass.com/event/24535/

次回

今回は初回ということで、今までのあらすじ、みたいな感じになってしまったが、次回は、「Quipper開発チームに入って欲しい人」というもうちょっと深いところを書く予定。

続く。