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

【後編】メルカリ×一休CTO対談|これからの組織、どうしていくつもりですか? #sotarok_naoya_sushi

インタビュー いろいろ

昨年エンジニア界隈で好評を博した伊藤直也氏(現一休CTO @naoya_ito)がホスト役を務める #naoya_sushi にメルカリCTOの柄沢聡太郎(@sotarok)が登場してから約一年。

tenshoku.mynavi.jp

tenshoku.mynavi.jp

今回はホスト役をsotarokが務める形で #naoya_sushi のオマージュ企画がメルカンで実現しました。 前編はこちら↓

mercan.mercari.com

後編では遂におsushiが。二人の話は盛り上がり、両社のプロダクトチームの話に話題が移っていきます。

f:id:mercarihr:20160913131410j:plain

両社のプロダクトチームの違いとは?

sotarok
一休はどういうプロダクトチームなんですか? エンジニアが結構役割を兼ねてるって話がありましたけど。

naoya
基本はあまりロールは分かれないです。チームごとに見てる領域が分かれている程度。企画とかプロダクトマネージャーといったロールがないっていう方がわかりやすいかな。

sotarok
それはメルカリとすごく違うところですね。

メルカリはまず一つのプロジェクトの中にプロジェクトオーナーがいて、それがエンジニアやプロデューサーかはチームによるんですけど、QAがいてって。チームの中で職能が揃ってるんですよね。

naoya
モダンだね。デザイナーは?

sotarok
デザイナーは割と横串ですかね。QAももともと横串だったんだけど、ここ1年はチーム付きになってる。

f:id:mercarihr:20160913131448j:plain

▲ここでいよいよsushiが登場。しんこからのスタートです。

f:id:mercarihr:20160913131508g:plain

naoya
(あーこの寿司最高だ…)
なるほど。

ほぼさっきの話と同じなんですけど。 現時点ではそんなにわかれてないけど、そのわかれていないことによって、ほぼ全員が目の前のことにオーナーシップを持ててるんだよね。

でもみんな目の前のことに集中しているから、一区切りした次の日になったら「なにしよう」ってなっちゃうことがあります。 ディレクターとか舵取り役がいる組織って、エンジニアが目の前のことに100%コミットしてる時に次のことを考えますよね。そのパイプラインが不在。

例えばスマートフォンアプリなんかだと、舵取り役不在なことのデメリットが大きくなりがちですね。何を作るにも工数が相対的に大きいので、やることをちゃんと見極めることをしないと、本質的でない小さなことばかりやって時間がすぎていく。あと、リリースして致命的なトラブルが起こったときに差し戻しが難しいから、そのリリースマネジメントも重要。

それで、アプリはやっぱりさすがにディレクター必要だなって思って、アプリチームのエンジニアにディレクターの役割をお願いして進めている。ディレクターを立てるにしても、エンジニアリングを分かる人がやるのが一番いいですからね。2週間前くらいから始めたんだけどやっぱりぜんぜん違いますね。

sotarok
メルカリの場合、振り返りや施策の計測とか、そこまでをプロデューサーが担うんですよ。最近だとデータサイエンティストたちも強力にバックアップしてますね。

だからある意味、エンジニアがエンジニアの仕事をやる環境はすごく整ってると思う。一方でエンジニアが仕様を考えるというか、仕様待ちになっちゃう瞬間、側面はあるのかも。 仕様や企画にコミットしてるエンジニアもメルカリには多いですが。

naoya
一休では仕様待ちどころか、やることを自分で探さないといけない。 それが僕にとってはいい意味で驚きで、これまで自分がマネジメントした会社でなかなかそうはならなかった状態ができてる部分もある。

sotarok
それはすばらしい。

naoya
そうそう。

これは僕の入る前の話なんですけど、ボトムの判断で人が部署異動したって件があって(笑) 本人は「勝手にはやってませんよ!」って笑ってるんだけど、周りの人は「実質的に自分の判断で異動したでしょう (笑)」って。もともとエンジニアだったんですけど、気づいたら自分で席替えしてデータ分析のチームで仕事をしていて。

よくよく考えると、小さな会社では普通のことですよね。足りないものだらけだから、気づいたことは誰でもいいからやっちゃう。それが大きくなると、許可がいるとかそういう形になってく。

ボトムアップ型の組織だとトップダウンで境界を明確にしたりしないから、オーバーラップする部分が多くなっていきますね。

sotarok
トップダウン型だと、プロジェクトオーナーの実力に依存しがちですしね。

naoya
そうそう。やり過ぎると大企業病みたいになっちゃうしね。

f:id:mercarihr:20160913131529j:plain

▲キス、アジ、中トロ、スミイカ

共通するエンジニア採用で絶対に譲れないポイント

naoya
メルカリのエンジニアと一休のエンジニアのカラー、印象はもしかしたら違うかもしれないですね。 メルカリは僕の印象だと、Web系のガンガン実装していきますみたいな、ハッカーマインドを持ってる人たちのイメージ。ある意味これまでの僕のホームグラウンドだった人たち。

一休のエンジニアは実装することを主目的としてない人が多いかもですね。それより事業やサービスの運営がしたいってマインドの人が多いかな。

sotarok
それでいうと、メルカリもプロダクト志向ですよ。コードばかり書きたいです!とかじゃないです。

採用のときも、基本的にちゃんとメルカリを使ってきてもらっているんですよ。 面接ではメルカリのプロダクトや事業、ミッションにどのくらい興味があるのかも気にしています。

もちろん、これまで使ってなかったとしても、受けるからメルカリを使おうというのは、志望度の現れでもありますよね。 でも、インストールして眺めましたって人と、出品して売って発送までしましたって人にはすごく大きな差があります。「使う」と言っても人によって様々なんです。

最後にエンジニアを突き動かすのは、事業への共感や興味の強さじゃないか、と思っていて。だから結果としてメルカリのエンジニアには事業に関心があって、プロダクト好きなエンジニアが多いんですよね。もちろん技術力というスキル面での後ろ盾があった上で、ですけど。

naoya
なるほど。となると、そこは一緒ですね。 うちはまあ、対象ユーザーの年齢層が高めなこともあって、サービスを使っているかをそこまで重要視することはないですけど。

そうそう、一休はIT企業じゃないんですよ。極端に言うと。

あくまでホテル予約とレストランをの予約事業をやる、その手段としてIT選んだ会社なので。営業さんに聞くと、自分をIT系だと思っていないという人もまあまあ多いんです。いい意味で。

あ、技術指向の人を否定しているわけじゃないですよ。そういう人も必要です。 そもそも僕らのプロダクトだって、そういう人たちが作ったオープンソースなんかがある上で成立しているから。 ただ僕たちの会社の主目的がITを売ることじゃないってだけで。

sotarok
規模が大きくなって、エンジニアも増えたら、エンジニアのための仕事をするエンジニアいてもいいかもしれない。ただいまはまだそういうフェーズじゃないかな。

f:id:mercarihr:20160913131541j:plain

▲車海老、ミル貝、石垣貝、勝駒

naoya
え、今エンジニア何人いるの?

sotarok
メルカリ アッテを開発・運営しているソウゾウをいれると、70人くらいかな。メルカリ本体は50人くらい。

naoya
え、ちょっとまって。メルカリ アッテとメルカリの違いがわからない…

sotarok
わかってないからnaoyaさんは入社できないな(笑)

f:id:mercarihr:20160913131604j:plain

採用と組織づくり、どうしていく?

naoya
50人だとまだそこまでテクノロジーに投資するフェーズじゃないかもしれないですね。 もうすこし増えてくるとR&Dとか、自社でコア技術持つとかって話になってくるのかもしれないですけど。

sotarok
そうそう。言語自体をHACKするとかね。FacebookのHHVMみたいなやつはまさにそうで。

メルカリには「Be Professional」というバリューがあるんですが、その価値観から外れない採用を続けたいです。

naoya
採用基準に関していうと、僕自身がぜんぜんスーパーサイヤ人じゃないですからね。 ごく平凡な頭脳で。最高学府に行ってましたとか、計算機科学の博士号持ってますとか、数学コンテストやアルゴリズム大会で優勝とかそういうのは別に何もない。

だから採用のときにものすごい優秀な人しか入れない会社だと、僕自身が入れないだろうし居心地悪いかもなって思うんですよね。Google的な、コンピュータサイエンスでドクターまで行った人が前提です、っていうエリート志向の組織に僕は入れない。

スーパーサイヤ人でしか構成しない会社を作るっていうのは、自分を否定していることになる気がしてちょっと嫌なんですよ。

そうじゃない普通の人でも、会社の組織や環境が彼ら彼女らをサポートして、世間一般では評価されるアウトプットを出していける会社にしていきたい。だから、間口は広く取りたいなと。

sotarok
それには同意。僕もGoogle実際落ちましたが(笑)
だけど、カルチャーフィットだけはどうしてもあとからわかる部分も結構あるなって。

f:id:mercarihr:20160913131618j:plain

▲バフンウニ、ムラサキウニ、穴子

naoya
それも考えようで、どこまで受け入れられるかってところもあるじゃない。
「今のカルチャーには合いません」と、果たしてそれだけで排除していいのかって。組織は多様である方が強いんだから、時にはカルチャーを壊してくれる人を採ることも大切。

それから現時点で期待値に届かなかった人でも、もう少しマネジメントで支援すれば伸びる、とか。

sotarok
それは同意なんだけど、結果的にフェーズが違ったというのもありますよね。2-3年で必要になる人材なのは間違いないけど、今じゃなかったってケースとか。今時点で活躍できないのは本人もつらい。

naoya
まあ、そうですね。その辺は若いスタートアップの会社ほどシビアではありますね。

スタートアップは特にひとりあたりの人件費が会計・経営に与える影響は大きいし、油断すると会社ごとすぐなくなっちゃいますからね。 会計・経営的に短期的なインパクトを与えられるメンバーを優先したい力学が働くのは当然かなと。

sotarok
FacebookとかはPHP自体をHACKできる人材を何故採るかといったら、それだけで会社・プロダクトに与える影響が強烈な規模になってるからで。

naoya
これから開発組織をどうしていくか、CTOとしての考えは持ってるの?

sotarok
自分も考え続けてる問いなんですが、いまの時点の考えではプロダクトを愛するひとたちがいっぱいいる組織を維持したいですね。基本的には。自分もそうだし。

自分たちのプロダクトをよくすることに強い興味を持っている、そういう組織であり続けたいです。一方で、人が増えてできることに幅を拡げられるようになったら、ちょっと難しいところにフォーカスするチームを組んでいきたいなと。

いまだとどうしてもプロダクトに関係ないことにリソースを割きづらい点はあるので。 組織課題の一つではありますけど、すこし長いスパンでそういった取り組みができる体制は会社としても今後必要になると思うので、エンジニアが100人になる頃にはそういうメンバーがいる状態にしていきたいですね。 今流行りでもありますが、機械学習のような、ちょっと長いスパンで結果が出てくることに取り組めるような。

naoya
100人か…どんどん大きくなりますね。 一休は楽天さん、JTBさん、リクルートさんとか大きな競合がいる中で、顧客のセグメントを絞って高級に特化するというポジションを確立してここまでやってきた会社なので、そこまで拡大志向じゃないんですよね。

少数のフットワークの軽さを保ちながら一番利益率の高いところにフォーカスしたことで今のブランドを築いているので。会社全体のカルチャーとして拡大という感じではないんです。

CEOにはリーンな組織を目指せと言われていますね。とはいえ、足りない部分もあるので、まだ人は増やしたいと思っています。

sotarok
40人くらいの組織でマネージャーは?

naoya
5人くらいいます。僕と、ホテル事業、レストラン事業、技術基盤系、採用組織系かな。 ひとりあたり10人ちょっとの組織をみてますね。

sotarok
僕は組織拡大の準備をどんどん進めてるんですよ。今年の2月からスタートした merci box という人事制度を使って育休に入ったことがひとつのきっかけで。

マネージャーとまではいかなくても、技術的にリードできるエンジニアを各領域でたてて、7−8人で技術コミッティーもつくっているんです。

naoya
似たようなことは一休でもはじめてる。 サービス中心の会社だと、技術的な横串は放っておくと何もできないよね。だからそこはきちんと人をアサインしてやりはじめましたね。これもトップダウン的なアプローチの一つでしょうね。

sotarok
自分が入った時からその必要性は認識していて、例えば、自分はサーバーサイドが得意だけど、他の領域もきちんと決めていけないとな、と。大枠わかっても全てを詳細まで、というのは無理だから。

naoya
一休は .NET なので、僕はぜんぜんそこは素人でね・・・

そうそう。.NET 初めてなんだけど「わかんねーなー」と思いながら触ってみるとすごい便利だったりするんだよ。いままで慣れてないプラットフォームだからというだけで敬遠してたんだけど、めっちゃ便利。GUI最高みたいな(笑)

おっと、脱線した。それはいいとして…

いかに技術的に正しい意思決定をできる人をアサインして任せられるかってのが重要ですよね。そうしていかないと、細部まで把握できない今の僕みたいな CTO が、すべてを意思決定しようとすると絶対間違う。

sotarok
そうそう。一方でちゃんと握っておかないと好き勝手違う方向に行っちゃうから。握りつつ、任せる。みたいな。そういうところは準備していきたいですね。

CTOの肩書は道具でしかない

naoya
ちなみに、技術的なことを自分ではなくわかる人に・・・となっているこの状況で「CTO」の肩書を持ってることに満足・・・というか納得している?

僕は、今の自分の仕事はぶっちゃけ「CTO」じゃないとおもうんです。教科書通りのCTOじゃないから。CTOって本来的には技術的なアーキテクトじゃないといけない、とかあるじゃないですか。

僕らは技術のコアをやってない。何やってるかって、Slackを拡めるとかばかりやっている(笑)

sotarok
自分が満足しているかどうかというより、あいつCTOの仕事していないじゃんって思われることはあるかも。

naoya
現時点ではCTOの肩書を持っていると便利だからという側面が強いんですよね。それはわかっていて、かつCTOぽくないことやっている。

ここまでで自分で一番いい仕事したなあと思っているのは、オフィスのレイアウトを変えたことなんですよ。なんじゃそりゃと思うかも知れないけど。

増床のときにオフィスレイアウトを作りなおす機会があって、机のレイアウトを結構工夫した。あまり前例のないレイアウトだったので、絶対こうしてくれって強く頼んで。

まず、エンジニアの島の真ん中にはメルカリにもあるような大きな机を置くんですね。フリーのスペースとして。

その机を中心に、4人くらい分のデスクで島を作ります。そして向きを不規則にジグザグに配置する。

僕の経験上、規則的に縦一列でずらっと並べると、一人あたり1度に会話できる人数が多くて5人位に制限されるんです。前後ろ両隣、くらい。でもジグザグにするとこれが8〜10に増えるんですよね。

ひとりあたりコミュニケーションしやすい相手が3−4人増えるだけで、コミュニケーション不全を起こす機会がぐっと減る。

オフィスのレイアウトが良いってあまり誰も誉めてくれないけど…明らかにみんなの仕事のしやすさが変わったと思います。

いやあ、我ながらいい仕事したなって (笑)

コミュニケーションのためのオフィス内導線には個人的にこだわってて、僕の中で信念があるんですよね。会社づくりの中で最も大事だと思うことのひとつ。大袈裟じゃなくて。

オフィスの見てくれがおしゃれかどうかよりも、レイアウトのほうが圧倒的に重要なんですよ。会社の入り口や来客室をどんなにおしゃれに着飾ったってそこで働く人たちには意味がなくて、特に物作りをする人たちがその大半を過ごすことになる執務室、ここの機能性がチームワーク、延いてはその成果物であるプロダクトやサービスに大きく作用すると思っています。

で、「CTOとして頑張ったことはオフィスのレイアウトの配置です」とドヤ顔 (笑)

【参考記事】 blog.kushii.net

sotarok
いい仕事してますね。

naoya
ただ、それがCTOかといわれると謎っていうのはあるけども。

sotarok
VP of EngineeringなのかCTOなのか、みたいな議論はあるけど、単純にこういう職業はこうあるべき論にハマる必要はないと思いますよね。 CTOはひとつの象徴的なもの、権限ではあるとおもうけど、別に仕事の内容が定義されてるものじゃないから。

naoya
ただ、やっぱりコアテクノロジーをやるっていうリーダーも大事だし、トップマネジメントにそういう存在がいるべきっていう議論もわかる

一休だと予約システムの未来を技術で創造する・・・みたいなね。

sotarok
あとは、会社に求められてるものをやるのはわかりやすいけど、誰も気付いていないけどやったほうがいいことをやるっていうの大事だと思う。

オフィスレイアウトとかもそうだと思うけど。

naoya
そうですね。誰も気づいてないポイントっていったらオフィスレイアウトはその最たるものだったんですよ。僕がこんなレイアウトにしようって言った時にいいですね!って真っ先に反応してくれたの、今日付き添いでそこにいるエンジニアの田中さんぐらいだったもの。基本孤独ですよ。

sotarok
技術的にこういうことが必要だってことを気付けるのが自分だけだったとして、そう思ったときにそういう人をつれてきたり、そういうことをやれる体制をつくれる状態をつくれればいいですよね。必ずしも自分が主体となってやる必要はないってことね。

もしかしたらCTOって立場じゃなくなるかもしれないし。オフィスマネージャーおじさんとか、Slackおじさんになって…。

なかなか聞けないお金の話

sotarok
naoyaさんは僕の2倍位だったよね?

naoya
違うって。そういう面倒な嘘をつくのはやめなさい (笑)

ただ年収に関しては、むかしから言われますね。

「naoyaさんみたいな人がたくさんもらってなかったら業界死ぬからたくさんもらってください」って。最近 Twitter とかでも同じこと言われるよ。

sotarok
そうそう

CTOは夢みさせてくださいって言われる。節約してるって言わないでくださいとか。

naoya
それが上限なんですか?とか言われたりね…

sotarok
メルカリの場合、そういう意味だと、エンジニアとして極めれば、CTOより稼いでいるひとはいますよ。 声高に言うような話ではないかもしれないですが、上限も下限も言わないし、ないです。自分がキャップじゃないっていうのはあります。

これはどうせ記事にはならないからなぁ…あと、エンジニアの年収ばかり話してもしょうがないと思ってて、他の職種だってあるわけじゃないですか?

naoya
それはすごくわかる。 昔はエンジニアの待遇低いから上げようというのが無条件に正しい時期はあったんですね。実際そうだったと思いますし。でもその結果上がって、いま実はWebエンジニアのお給料は既に結構高いんですよ。

そろそろ他の職種も含めて総合的に見ていかないとねと思います。

sotarok
そうね。それでいうと、数年前のソーシャルゲームを主軸にした企業の功績も大きくて。サーバーサイドエンジニアの相場感は感覚とそんなに齟齬がない気がします。 が、それ以後の世界、つまりスマホのクライアントエンジニアの相場は低いと感じますね。

naoya
サーバーサイドは低い人も高い人もいますね。揺らぎが大きいというか。 クライントは年齢層が若いのもあると思うし、揺らぎが少なさそう。

sotarok
メルカリはそういうエンジニアの評価を正当にするというか、ちゃんとその人の能力を評価していけるように業界引っ張っていきたいです。

naoya
なるほど。いまメルカリがお金払わないと、どこが払うんだって話ですしね。

話ちょっと戻るけど、エンジニアがエンジニアの事ばかりしか考えない風潮は嫌だなと思うこと増えてきたかな。「営業はエンジニアのこともっと知るべき」みたいな論調とか。なんでその逆もまた然りだということに気づかないのか、という。

過度なエンジニア中心主義みたいなもの。思わないですか? あと「海外ではこうなのに日本じゃまだ〜」みたいな話とか。対立構造に持ち込んで比較するというのかな。

f:id:mercarihr:20160913131647j:plain

sotarok
海外との比較でいうと、そういうところはありますよね。 メルカリはUSやUKの出張・出向者がかなりいるけど、ボトムの部分のケアはかなりしっかりしてると思います。USと日本一番何が違うって生活費だからね。

naoya
単純に年収換算したらおかしな話になるんだよね。 サンフランシスコの家賃とか40万50万もするらしいじゃないですか。そこを加味せず給料が日米格差がある、という話をしてもなと。

sotarok
だからメルカリはそこはフェアにしていて。うーん、可処分所得が減らないようにって感じかな。一方で、USに行ったからといって余分に給料がもらえるような設計にはしてないですね。

社員への気遣いファーストは愚の骨頂?

sotarok
他職種の話が出たけど、メルカリにはエンジニアの隣にCS(カスタマーサポート)がいるんです。CSメンバーともよくコミュニケーションをとっているんだけど、一休のエンジニアは営業さんとよくコミュニケーションとるんですか?

naoya
一休にはお客様が二種類いるんですよね。出稿側(施設、つまりホテルやレストラン)の声を直接聞くのは営業、ユーザー側の声を聞くのはCS。エンジニアはその両方から話をきくってかんじですね。

どっちが優先とかはないけど・・・迷ったときはユーザーファーストで考えようっていうのがあります。それは施設の人にとってもそうであるはず、という判断ですね。ただまあ、ユーザーファーストっていうのは別にユーザーの声を鵜呑みにしろということではないので、CSからのフィードバックの方がより重要とか、そいうのはないです。

sotarok
ともすればお金くれる側にリソースや判断寄せちゃうケースはあるからね。

naoya
そうそう。だからそうはならないようにっていうのはよく社内で話題になりますね。

ちなみに、お金をいただいている側とユーザーファーストのコンフリクトはまだ健全だと思います。ネットビジネスだとどんな会社でも大なり小なりあることだと思うし。

それより不健全なものに「従業員に対する気遣いファースト」というのがあってですね。それは最もダメだって話をよくCEOがしてます。僕もそれにはすごく同意している。

たとえば「エンジニアが一生懸命つくったから(効果は不明だけど、作った人のプライドを傷つけたくないから)リリースしたい」とかね。施設のことよりも、ユーザーのことよりも自分たちのことを優先している。そういうのは間違っている、という話。

sotarok
それはメルカリでは起こり得ないかな…結果を数字で見て、ダメだったら次!次!って感じで作った人も含め結構ドライに判断してますね。 あと社内のコンフリクトも起こりにくくて。ユーザーが出品者と購入者どちらにもなるプロダクトだから、みんな同じ方向を見れるんですよ。

さっきの、営業はエンジニアのこと知るべき、という話で言うと、メルカリはエンジニア含め全員がCS研修やってるんです。返信とかの実務も。 そういう意味ではCSメンバーに多少負担かけてるけど、ものすごく価値がある。 メルカリはアプリのUIや機能だけでなく、何かあったときのサポートも含めて、すべてがプロダクトの体験なんですよね。

これからの1年どうしてく?

f:id:mercarihr:20160913131700p:plain

▲ネギトロ巻き、たまご、しじみの赤だしのお味噌汁

sotarok
そろそろ締めですかね。この一年でやりたいことお互い発表しましょうか。sushi企画またやりたいし。

naoya
更にいいオフィスレイアウトを…(笑)

えーと、そうですね。 開発の組織がまだ少し無構造だから、モノづくりのプロセスを正しく投影したものにしていきたいですね。

いちいちマイクロマネジメントしなくても組織やプロセスの中を経て、正しいものが作られてく構造といいますか。

いいものつくってるときって、ちゃんとした手順を踏んでいるな・・・という瞬間ありますよね?それが偶然じゃなくて、毎回、当たり前にできるようになれたらいいなと思います。

なんか、いいプロダクトつくってる会社の雰囲気みたいなものがありましてね。 メルカリもあると思うんだけど、ちゃんとプロダクトがよくなることに時間をかけていて、リリース直前にこれはいけるって実感できるときがある。それをできる人だけがやっているんじゃなくて、みんながそういうことを自然とやれるようなレール、構造を作っていきたいですね。役割分担とか標準化とかをしながら。

一年後ぐらいまでにはそういう状態にしたい。

一番の理想はマネジメント的にやることがなくなって暇になってることだけどね (笑) ゲームしたい!

sotarok
それいいな。

naoya
マネージャーが忙しすぎる組織って健全じゃないから。

sotarok
僕は、これからの一年で、エンジニアもそれ以外のメンバーもすごく増えていくと思うので、昔はよかったって言われない組織にしたいですね。守りの表現かもしれないけど、「今がいい」という状態をいかに維持するか。 これは僕のチャレンジです。一年後も、今が一番良い状態ですって言えたらいいですね。

来年もお寿司たべれるように!ということで!

sotarok×naoya
ごちそうさまでした!

f:id:mercarihr:20160913131717j:plain

【取材協力】 restaurant.ikyu.com