WEB・IT業界で働く人々の人生を少し豊かにするメディア

CAREER HACK

CtoCサービス3社が考えるエンジニアのキャリアパス【メルカリ、チケキャン、ココナラ】

2015-12-11

CtoCサービス3社が考えるエンジニアのキャリアパス【メルカリ、チケキャン、ココナラ】

急成長中のCtoCスタートアップ3社共催によるエンジニア向けイベント「CtoCアービスの開発の裏側を公開!プロダクト責任者、CTOが全て語ります!」が行われた。メルカリ、チケットキャンプ、ココナラの3社が語る「エンジニアのキャリアパス」とは?

国内CtoCサービスを牽引するキーマンたち

「CtoCサービスの開発の裏側を公開!プロダクト責任者、CTOが全て語ります!」は11月30日、mixi本社内で開催。注目のCtoCサービスを行う各社にサービスの裏側や、その先に見える思想を語ってもらうことが目的のイベントだ。登壇したのは、株式会社メルカリ株式会社フンザ株式会社ココナラの3社。どこも急成長中であり、国内のCtoCサービスを牽引する存在なだけに、参加者たちからの視線も熱い。

イベント前半は各社代表者によるセッション、後半はサービス責任者やCTOのセッションが行われた。リリース時の開発裏話やプロダクトの世界観だけでなく、今求められているエンジニア像や、3社が考える「エンジニアのキャリアパス」にも話が及んだ。

このイベントレポートでは、各社が望むエンジニア像、今後考えられるキャリアパスを中心に触れていきたい。


<登壇者>
▼セッション1「Founderが語る、プロダクトへの想い」
・株式会社メルカリ 代表取締役 山田進太郎
・株式会社フンザ 代表取締役 笹森良
・株式会社ココナラ 共同創業者/取締役 新明智

▼セッション2「CtoCサービスの開発の裏側!Q&Aでお答えします!」
・株式会社メルカリ プリンシパルエンジニア 鶴岡達也
・株式会社フンザ 取締役/CTO 酒徳千尋
・株式会社ココナラ 取締役/CTO 恵比澤賢

<コーディネーター>
・株式会社メルカリ 取締役 小泉文明

メルカリ、チケットキャンプ、ココナラのが求めるエンジニアとは?

3社それぞれの代表が登壇し、軽く挨拶をしたところからセッション1がスタートした。立ち上げ当時の話から、ウケると思って作った機能、さらにはブーストのきっかけになった機能などの話題も飛び出した。

ブーストのきっかけになった機能について、メルカリ代表・山田進太郎さんとフンザ代表・笹森良さんは「CtoCの機能でブーストがかかるものはない。日々、地道に小さな改善を続けていた」と意見が一致。ココナラ代表・新明智さんは「アップセルできるようになってから、活性化した印象がある」と話した。


新明さん:
立ち上げフェーズの「ココナラ」は、買い手と売り手がマッチしやすいギリギリのプライシングとして500円のみの出品でしたが、だんだんそのルールでは窮屈になりはじめていました。窮屈さを解消するために、2013年の終わりごろにフェーズを変えて当初のビジネスモデルを拡張し始めました。プライシングの幅を拡げていったんですね。1,000円や5,000円での出品も可能になることで、いろんなタイプの出品主さんが出てきてくれたんです。この影響で、マーケットプレイスが活性化したというのはあります。


左から、山田さん、笹森さん、新明さん

――今後のサービスや会社のカルチャーとして大事にしていきたいもの、求めるエンジニア像とは一体どんなものなのか。

新明さん:
「ココナラ」は、「CtoC × サービスEC」という、世界でもまだ事例が溜まっていない、結構難しいプラットフォームという認識があります。今いるメンバーは、ココナラが持っている「誰でも気軽に自分の知識・スキル・経験みたいなものに値段をつけたり、買ったりできる社会」の世界観に共感すると同時に、難しいものが好きだからガンガンとPDCAを回していきたい人が多いです。これまでも、エンジニアを含めてかなり優秀な人がきてくれたおかげで数値が伸びました。サービスへの共感が高い人、難しいかもしれないけれど面白がってPDCAを回せる人であればフィットは高いんじゃないかなと思っています。

笹森さん:
フンザの運営カルチャーは、少数精鋭。「チケットキャンプ」は現在、500万人のユーザーを5人のエンジニアで対応しています。つまり1人あたり100万人の責任があるわけです。僕自身、諸先輩社長のマネジメントを活かしながら、1人あたりの生産性や責任、抱え込む範囲を深く広くしたいと思っていますし、それを楽しめるメンバーを求めています。

山田さん:
「メルカリ」の場合、前会社・ウノウの人や、mixiからきた人が多かったりします。極めて自由なカルチャーで、細かいことは言いませんし、中には全然いうことを聞かない人もいます(笑)。

またメルカリは、「Go Bold」という会社のバリューを掲げています。ようするに、大胆にやろうということです。日本から海外に進出したネットサービスで成功した例は、まだほとんどありません。世界を目指すメルカリが今やろうとしているのは、まさに前人未到なこと。今まで誰もやったことがないからやってやろう、という気概のある人にきてもらえるとうれしいですね。

人づてで必要最小限のメンバーを集めた、サービス立ち上げ期

セッション2では、各社のサービス技術責任者とCTOが登壇。参加者からの事前アンケートでもっとも関心が高い質問に答えるスタイルのトークが行われた。

左から、鶴岡さん、酒徳さん、恵比澤さん、

――エンジニア目線でのサービス立ち上げ時、採用をどのようにしていたのか

・「山田進太郎さんがFacebookやTwitterで、必要最小限のメンバーを集めていた」(メルカリ・鶴岡さん)
・「当時のエンジニアは自分1人。元同僚つながりで人を紹介してもらっていた」(フンザ・酒徳さん)
・「ココナラは3人で創業し、そのうちの1人しかエンジニアリングについてわかる人間がいなかった」(ココナラ・恵比澤さん)

鶴岡さん:
最初のメンバーは進太郎さん(=山田進太郎さん)がウノウつながりの人を集めました。Twitterでつぶやいて反応してくれたひとも採用してましたね。ただ、スタートアップの場合、たくさん人がいればいいというわけではない。なので、最初のころは本当に必要最小限の人数でした。たとえば、サーバサイドなら1人、iOSとAndroidでそれぞれ1人。特にアプリは当初1人しかいなかったので、空いた時間にAndroidをやる状態でしたね。

創業時は、採用のプロモーションをかけることも特にしていませんでした。知り合いが知り合いを職場に呼んでくる、そしてジョインする。今の規模になっても、そのスタイルは続いています。やはり最初のメンバーは、スキルがあればいいだけではなく、信頼できるかどうかも大事です。直接会って話して、文化がマッチしているかどうか。それで人を選んでいた印象があります。

酒徳さん:
起業時、エンジニアは僕1人でした。メルカリさんと同じく、当時は元同僚つながりで人を紹介してもらうなどしていましたね。

僕らもやはり、マッチしているかどうかを重視します。そのため、すごく迷った結果、お断りさせていただくこともあります。会社とマッチしていないと、どんなに才能豊かで、ある程度性格を知っている関係性であっても、単純に作業量が1+1=2にしかならないんですね。初めのころは、それがすごくストレスでした。今は、会社としての力を最大限に発揮しつつ、新しい人にも最大限の能力を発揮してもらうというところにこだわっているので、マッチする・しないは重要ですし、メンタリティや方向性によって選ぶこともあります。

恵比澤さん:
僕は創業メンバーじゃないので立ち上げ時はその場にいなかったんですけど。知っている範囲でお話すると、ココナラは3人で創業し、そのうちの1人しかエンジニアリングについてわかる人間がいなかったんです。

その後、しばらくして僕が入社し、開発チームが本格的に立ち上がりました。最初のころは会社の技術面、文化面などもそうですが、「まだまだ何もないけど、これから何か作っていかなくちゃいけない状態」です。そういった、ないところから作っていくことを一緒にできる人かどうかが重要なんじゃないかと感じました。

採用技術の判断基準「絶対の自信がある言語」「負債を残さない」「学習コストの低さ」

――現在利用している技術は、それぞれどういった基準で選定したのか

・「一番自信を持って使えるかどうか、技術に対して最終的に責任を持てるかどうか」(フンザ・酒徳さん)
・「メイン部分に関わるなら、数年間は安定して使えるもの。サブ部分なら、メンバーが使いたい新しいもの」(ココナラ・恵比澤さん)
・「学習コストが低いもの。特定のエンジニア以外でも使えるもの」(メルカリ・鶴岡さん)


酒徳さん:
「チケットキャンプ」の言語はPython、フレームワークはDjangoを使っています。インフラはAWS、データベースはMySQLです。先ほどお話したとおり、当時のエンジニアは僕1人でした。僕の生産性や迷いが、プロダクトに影響するなと思ったので、自信を持ってできる環境にしたかったんです。

言語の選定やフレームワークの選定は、最終的にだれが責任を持てるのかというのがあると思います。そういうところに関しては、僕がPythonやDjangoに関して絶対、責任を持てる自信があります。

恵比澤さん:
「ココナラ」はPHPで、データベースはMySQLという一般的な環境です。なぜそれを選んだのかというと、最初のエンジニアが一番得意だったものを投入したからだそうです。やはり、サービスを短期間で立ち上げたいところと、自分が責任を持てるところは重要です。現在も使われ続けています。

もし今選ぶとしたら、どういう部分で使うものなのかなど、場面により基準が変わります。たとえば、メインの部分に関わるのか、それともサブのツールであるのかによって、選ぶ基準が変わります。失敗したときのリスクがどれくらいあるかで、適応を考えたいんですね。メイン部分なら、ある程度リスクをおさえられるもので、数年間は安定的に使えるもの、運用コストが低いものになります。メンバーが使いたい技術かどうかも大事です。逆にサブのツールであれば、新しい技術へのチャレンジの場になります。

鶴岡さん:
「メルカリ」の場合はPHPで、フレームワークは僕が過去に開発に関わっていたものを使用しています。一番大きなポイントは、学習コストが低いこと。社内で使われている技術全般がそうです。覚えるために一週間もかかって、それでもまだ全体がわからない…みたいなものは採用しません。なるべく単純なものの組み合わせで構成するようにしています。

サービスを作るときに職人的な技術者がやりがちなのは「流行っているから自分も使いたい」「新しいから触りたい」というものです。一番大事なのは、プロダクトを決まったタイミングで出すこと。そのためには自分が自信を持っているものを選ぶのが大事だと思います。1人で作るプロダクトには限界があります。最初こそ、CTOたちは時間を使って作れますが、人が入ってくると難しくなります。自分以外の人でも高いレベルのものを書ける技術じゃないとダメかなと思います。


――追加機能の判断は、どのように行われているのか

・「モバイルの思想を大事にしつつ、ディレクターが企画し、エンジニアが信頼して作っていくスタイル」(メルカリ・鶴岡さん)
・「新しく入る人にがっかりされないために、技術的負債を作らない」(フンザ・酒徳さん)
・「数値や根拠を元にエンジニアが企画し、PDCAを回していく」(ココナラ・恵比澤さん)

鶴岡さん:
メルカリはディレクターやエンジニアがいくつかのチームになり、いろんな機能をゴリゴリ作るという体制です。プロダクトの責任者が日本とアメリカのそれぞれにいて、大きな方針は彼らが決めます。企画的なものはディレクターが決め、そこをエンジニアが信頼して作っていくスタイルになっています。エンジニア自身が判断して作っていくというよりは、コミュニケーションしながら作っていく感じですね。

酒徳さん:
僕は、技術的負債を残したくないと思っています。それは自分の経験から、新しいプロダクトに入ったとき「どうしてこうなった」みたいなものが一番きついかなと思っていて(笑)。これから新しい人をどんどん迎えたいと思っているので、そういうがっかり体験はさせたくない。常に負債を作らないように努力しているつもりです。

これは僕自身のこだわりですが、「それは絶対にできません」を言わないようにしています。エンジニアが「できません」というと、何も生まれない。それは、スタートアップとして何の価値もないと思っています。自分の会社の存在意義にかかわるので、それは絶対にしないようにしています。

よく「プロデューサーに作れと言われたけれど、自分は納得していない」という話がありますが、納得できないことがあればプロデューサーととことん話し合うべきです。相手に納得してもらうこともありますし、自分が納得して機能開発することもあります。

恵比澤さん:
「ここを伸ばしたいよね」という大まかな目標があり、その中でエンジニアが企画を出したり仮説を作ったりして、どんどんPDCAを回すやり方になっています。

ココナラが会社として大切にしているバリューは、オープンな議論ができること。誰でも改善のための提案を出していいことになっているので、いろいろな人がいろいろなことを言います。どんな機能がユーザーに喜ばれるのか、それぞれが真剣に考えるので、誰の意見を採用するべきなのか簡単に決められないことがあります。意見がたくさんありすぎて収拾がつかず、どうしようもない時期もありました(笑)。そんななかでどうやってうまくやっているかというと、ちゃんと数字をみて根拠を話したり、実施した効果を検証して良し悪しをみて検証し、リカバリをやったり、客観的な判断を大切にしています。

チームとして結束が高まるのは「サービスが伸びているとき」

――会社全体や開発チームをまとめるために、どんなことをしているのか

・「1ヶ月に1回以上、直属の上司と話す機会を作っている」(メルカリ・鶴岡さん)
・「リーダーは考えを一貫させる、会社の売上に注力する」(フンザ・酒徳さん)
・「メンバーそれぞれが目標に対して何にコミットすべきかを明確に伝える」(ココナラ・恵比澤さん)


鶴岡さん:
現在、開発チームは20~30人。チーム全体というより、開発チームがどんどん増えてきた今、1ヶ月に1回以上、直属の上司がメンバー1人ひとりと話す機会を作っています。上からチーム全体に対して指示するよりも、コミュニケーションのミスを防ぐために1人ひとりの話をちゃんと聞く。それを積極的にやっています。これは人が増えても続けていきたいと思っています。チームが10人以下だったら意思疎通が簡単でいいですが、やはりある程度増えてくるとわからなくなるので。

酒徳さん:
自分の経験談からきた教訓の1つに、チームのモチベーションを下げるのはリーダーのダブルスタンダードだと思っています。自分はこうだけど他の人にはこうするとか、朝と昼で言っていることが違うとか。そういうものが一番モチベーションを下げると思っています。

また、サービスが伸びているときが一番会社としての結束を強めます。そのため、ビジネスサイドも強く意識しています。売上を上げる施策とエンジニア的にやりたい施策のどちらかなら、僕は確実に売上を上げる方をやります。今成長している会社ということにこだわってやっていきたいからで、一番会社の結束を強める方法だと思っているからです。

恵比澤さん:
みんなが目指すべき目標みたいなものをしっかり共有していくことが大事だと思っています。全体として自分たちが何を目指していて、なぜそれを目指す必要があるのか。メンバーそれぞれが目標に対してどこにコミットしていけば良いのかをはっきり伝えておくことが大事かなと思っています。

特に僕らはまだ人数が少なくて「わかっているだろう」という気持ちでついつい「ちゃんと伝える」をサボりがちだなという反省もあります。それだとまとまりません。あとはみんなで一緒にランチを食べに行くとか、小さなことをしっかりやっていくのが重要だと思っています。

3社のサービス責任者が語る、今後の「エンジニアのキャリアパス」とは

――各社ではどういうエンジニアが活躍しているのか。今後のエンジニアのキャリアパスはどうなっていくと考えているのか。

・「急激に成長する会社に身を置き、さまざまな経験をした人が活躍し続ける」(メルカリ・鶴岡さん)
・「自分の拠り所になる技術を持っているかどうか」(フンザ・酒徳さん)
・「人並みの技術では厳しい。技術+αで勝負していくことになる」(ココナラ・恵比澤さん)

鶴岡さん:
急激に成長する可能性がある会社、今成長している会社に身をおくことはとても大事かなと思っています。売上が伸びていないときって、エンジニアのやることはちょっとした改善などで達成感がよくわからない状態です。売上も毎月いくら増えていくのか天井がわからない状態というのは、メンバーはその時期にしか体験できない貴重な時間なんですね。たとえば、ソーシャルゲームの波みたいなのは何年に一度しかないもの。ここにいる会社はすべて成長していますが、そういった会社に身をおくことは大事です。

実際にうちで活躍している人は35歳や40歳を超えるエンジニアがたくさんいて、平均年齢が高いと言われています。しかし、彼らは10年前からこの業界にいて、バリバリやってきた人たちです。そういう人は過去にすごい経験をした結果、今があるのかなと思っています。

酒徳さん:
採用面接などでお会いするエンジニアさんの話を聞いていると「いろんなことにチャレンジしたい」「いろんなスキルを身に着けたい」という人がけっこういます。特に若い人は多いですね。僕としては、1つの技術を極めるということが大事かなと思っています。僕自身、拠り所になる技術があったから、今のサービスを作れたんだと思っています。

恵比澤さん:
エンジニアのキャリアパスについて、やはり技術+αで勝負していくことになるんじゃないかなと思います。具体的に何をやればいいのか、未来のことは僕にも正直わかりませんが、例えばユーザーに求められるプロダクトを作れるとか、そういうのがあるといいと思います。

技術について言えるのは、単に人並みにできることがいくらあっても、市場の中での競争という面では難しいところもあるんじゃないかなということです。僕らの業界はどんどん新しい技術が出てきますが、なかには10年経っても変わらない技術や、今後10年使われ続けるであろう技術もあります。そういった本質や原理原則を見極めて、しっかり深めていくことを意識していくのがいいんじゃないかと思います。



CAREER HACK をフォロー

タグ一覧