「料理サプリ」「Quipper」の技術者が語る、プロダクト開発を加速させる組織づくり【３】

2016年6月28日、リクルートマーケティングパートナーズ（以下、RMP）×Quipperの技術対談を聞きながら、おいしいご飯やお酒を楽しむことができるイベント「【RMP×Quipper】Food&Drink meetup #2」が開催されました。トークセッションでは、RMPでマネジメントを担当されている金谷祐季さん(@soplana)とQuipperの開発者である長永健介さん(@kyanny)に、導入している技術の意図や課題、開発組織における職種間の関わり方やスピードに関する課題などを語っていただきました。

（vol.2 はこちら）

▼「グローバル企業」の勤務体系

ーチーム開発もいろいろな工夫が必要になりますが、Quipperには「グローバル」というキーワードがあると思います。時差のある人たちと、同じコードベースを触っていくうえでの苦労話やケアの方法について教えてください。

金谷：時差の話は聞きたいですよね！
長永：時差の話は本当に簡単で、「解決できない」んですよ。
ー（一同爆笑）
長永：これは、もうどうしようもないんですよ（笑）ロンドンの人は「ワークライフバランス」がはっきりとしてるんで、やっていくうちに日本人が合わせていくような。徐々にそういうふうにはなっていきますね。
金谷：そうなると、勤務体系ってどんな感じなんですか？別に「決まった時間に来い」って感じではないですよね？
長永：そうですね。就業規則でも「フレックスタイム制」ということになってるし、就業規則以前にみんなそういうつもりで働いてるって感じですね（笑）

▼エンジニア×非エンジニアの組織開発

ーエンジニア職と非エンジニア職の関わり方について、気をつけていることなどありますか？

金谷：具体的には、どういうふうに施策が出てきて、どういうふうに実装してるか、の流れに関する質問になるのかなと思いますが、それで言うとRMPの内製エンジニアが関わってるプロダクトはスクラムを組んでます。「料理サプリ」は、今 1 週間スプリント。スプリント開始前にエンジニアとかプロダクトオーナーが3時間ぐらいみっちりと話し合って、その週でやることを全部そこで決めちゃうんですね。差しこみ案件とかもほぼ無いようにしてそのスプリントは走れるようにします。施策のチケットをどう出しているか、という話だと、もちろんエンジニアの意見から具体的な案件になっていく、って流れもありますし、特に誰がそれを出すかは権限があって決めてるということではないですね。そんな風土ではないかなと思います。やりたいことがあって、それが妥当であれば、通るような環境ですね。あとは「料理サプリ」以外のことでいうと、これはリクルートならではの話なのかなと思うんですけど、営業部がそもそも全国各地にあって、我々がつくったプロダクトを売りに行ってくれてるわけですよ。そうすると、何百人もの人々が関わってるので、誰かが言った意見をそのままスッと通すことは難しいこともある。なので、全体として「プロダクトをこうしていきたいんだ」という話が降りてきて、それを実装していくっていう流れももちろんあったりします。ただ、それが完全にウォーターフォール的かというと、そういうことでもなくて。スクラムをやってる中で「具体的にはどう実装していこうか」という話は、エンジニアがどんどん意見しながら進めていきますしね。

長永：ほぼ同じですね。うちは、アジャイル開発の手法をすごく厳密にやっている感じではなくて、だいたいみんな「できるよね」みたいな感じでゆるくやってます。KPTはやってますが。週に1回、みんなのタスクの棚卸しとか情報共有のミーティングをして、その場でビジネス側のwebディレクター的なロールの人たちに入ってもらいつつ、優先順位決めみたいなことをやっていきます。「Quipper」は、どの機能をいつつくるかということに関して、すごくロジカルに決めてきた感じがあるんです。もともとスタートアップ企業なので、生き残るか／お金が尽きるのが先か、みたいなところがあるので本当にビジネス側・マネジメント側の人たちが「こういうサービスで、こういうユーザに、こういう方法でリーチして、このようにマネタイズするんだ」みたいな筋書きを考えていて、その仮説を検証しつつプロダクトをつくっていくみたいな感じなので、出てきた時点でほぼ議論の余地がないというか、議論しつくされた状態のものが来ている感じはありますね。プロダクトマネージャーみたいな人たちがいて、彼らはマーケティングとか数字・利益を追うビジネスの人と我々開発者の中間にいるような感じなんですね。「両方わかってる人」という立ち位置です。その人達が舵取りをしながら「プロダクトとしては、具体的にはこういう機能になるよね」みたいなことを開発者と話して、つくっていくという感じですね。
金谷：出てきた施策にすごい熱量と納得感があったら、我々開発側もそれに感化されて「じゃあ、それをどれだけスマートに実装するか」みたいなことで燃えたりもしますよね。そういうマインドって、ベンチャー的な気もしますが。
長永：そういうのはありますね。
金谷：今はスクラムなんですけど、今後変えていきたいなと思ってるところが実はあるんです。すごく小さいチームをつくろうかと。非エンジニアも含めて 4 - 5 人ぐらいの体制をつくっちゃって、達成するべきKPIだけチームごとに決める。あとは好きにやっていいよ、と。実験的ではあるんですけど。「料理サプリ」は今、エンジニア・非エンジニア含めて 15 人とかなので、それを3チームとかに分割しちゃって、あとは達成したい数字だけ強く意識してもらう。チームから出てくる施策なんかに関してはある程度、是正したりはしますけど、細かく「こういうことをやってよ」みたいな振り方はせず、そのへんも自分たちで考えて「このサービス、どうしてくいくんだっけ？」というところをちゃんと考えてやっていこうよ、という働き方に変えていくような動きがあったりします。

▼エンジニアリングリソースはグローバルに調達

長永：まだ試行錯誤の最中ではあるんですけど、この4月ぐらいから「プロジェクト制」を導入して、Quipperのプロジェクトの進め方もすこし変えてきています。「スタディサプリ」は日本だし、「Quipper Video」だったらインドネシアとかメキシコとか各サービスをやってるリージョンによって、つくりたい機能とかいろんな要望がステージによって変わってきてるんですよね。今までは、いろんなところから上がってくるものを、数名のプロジェクトマネージャー・プロダクトマネージャーたちがなんとか捌いていました。だけど、だんだん不透明でよくわかんなくなってきちゃった。なので、今オンボーディングの案件はどれなのか、っていうのをしっかりプロジェクト化して。フォーマルにCTOからOKをもらったら、エンジニアがアサインされて進むっていう仕組みをつくりました。前提となるのが、Quipperの場合は開発者がwebで 20 名、いろいろ含めると 30 名以上いて、そのエンジニアがグローバル全体で 1 つののチームになってるんです。組織図でいうと、CTOの下に開発者が全員フラットに並んでいるんですよ。
金谷：地球単位ですね（笑）
長永：それこそ「Quipper」の機能をつくるっていうときに、どの国のどのエンジニアが実装してもいいんです。もちろん得意・不得意とかいろんな事情があって、ある程度の偏りは生まれてきちゃうんですけど。エンジニアリングリソースは、どこからでも空いてる順に出せばいいようになっているので。「インドネシアのVideoの再生体験を良くする」というプロジェクトがあったとしたら、そこのプロジェクトのオーナーが誰で、マネージャーは誰かというのは全部明記されていて、そのプロジェクトにエンジニアが 2 名× 2 ヶ月アサインされますよ、と。そのプロジェクトの進捗とか実際うまくいってるのかとか、KPIはどうか、みたいな話は隔週のミーティングで報告義務があって、ちゃんと終わりも決まっているので、そこまでにやる。そういう仕組みを運用しはじめましたね。
金谷：コードレビューは全員でするんですよね？
長永：そうですね。とはいえ、やっぱり背景がわからないのできつい。そこは同じプロジェクトに、少なくと 2 - 3 名ずつアサインされているので、その中で基本的に回して良いということにはなってますね。ただ、ジュニアの人が 2 人で、シニアの人が 1 人とかのチームだったりすると、ジュニアの人のレビューだけでは不安がある、みたいなときには他のプロジェクトの人がヘルプするということもありますし。あとは、プロジェクト自体も組み換えがどんどん発生するので、日本の「スタディサプリ」の機能をマニラの開発者がつくったりするんですよ。日本で人手が足りないという事情があったり、アニメで勉強して平仮名が読めるエンジニアがマニラに居たり（笑）そういう事例が実際にありましたね。

▼RMP×Quipperのコミュニケーション

ー【質問】RMPとQuipper間の人材交流ってあるんですか？

金谷：めちゃくちゃ交流があるかと言うと、そんなに濃くはないんですけど。RMPからも何人か出向というかたちで、Quipperにジョインしてやってる人とかいますね。そういう交流はあったりします。まだ、RMP側に来たことはないんですけど。あとは、何回か飲んだり（笑）
ー社内でAndorodエンジニアのイベントをしたり、slackのアカウント交換をしたり。最近はデジタルでのコミュニケーションが活発な気がしますね。実はロケーションも、同じ建物の中にいるので、話に行こうと思えばすぐに歩いて行けるんです。

▼「読む」より「書く」が難しい

ー【質問】Quipperで求められる英語はどのぐらいですか？

長永：まず、喋れなくても大丈夫です。聞けなくても大丈夫です。なぜなら、口頭で喋る機会はほとんどないので。もちろん英語力はあったほうがいいし、多数のエンジニアとコミュニケーションをとるような人だと出張も多いですし、また違うと思うんですけど、エンジニアとしては、ほぼ喋らないし聞かないし、でもやっていけていますね。何か技術的な質問をググるじゃないですか。ググッて 1 番目がスタックオーバーフローのときに、逃げずに読めれば大丈夫だと思います。基本的にはエンジニア同士の、しかも特定のコードベースやサービスに寄った話なので「スタックオーバーフローが読めれば、読める」ぐらいのことしか書いてないんですよ。これまで仕事で英語を使われてこなかった人だと、書くほうが大変ですね。ぼくが入社したとき、まさにそういう状態だったんですけど、読むより書く方が大変でした。プルリクエストにレビューコメントを返すのとかも大変ですし、チャットで話しかけられるとすごくテンパっちゃうというか（笑）ただ、そこはもうGoogle翻訳さんに頼って。あとは、いくつかパターンとなるような言い回しがあるので。相手が言った見慣れない言い回しを検索してみて「ああ、こういう意味なんだ」と理解できれば、「逆に、こういうときはこう言うんだ」っていうのが、だんだん自分の頭の中でストックされていく。それが溜まってくると、そのストックの中でやりくりして、ひととおりチャットの中で会話をスムーズに終わらせられるぐらいになるんですよ。だいたい半年ぐらいでそのくらいになりましたかね。そうなると、あんまり不便はありません。ただ、これはあくまで「最低限」で。なおかつ、Quipperは比較的日本人が多い職場なので、シリコンバレーのスタートアップに日本人が飛び込む！とかいう話と全然ちがうので、ハードルがだいぶ低い話だとは思うんですよね。フィリピンの人とかだと、結構英語が母国語の1つではあるんですけど、割とブロークンで、適当な英語でも耐性あるというか、わかってくれたりするところがあるんです（笑）そういうところでも恵まれてる気がしますね。あとは、それこそ海外のエンジニアを束ねるマネジメントとか、プロダクト開発のディレクションがしたい、となるともう数段上の英語力が求められるかと思います。