「エンジニア」と「事業責任者」の間で
馬場光氏（以下、馬場）：それでは「プロダクトマネージャー／事業責任者が考えるエンジニアとしてやっていたこと3選」をお伝えいたします。
本日、学生のみなさんが聞いているということなので、お話ししたいこととしては、まずは簡単に私の自己紹介とDeNAでのキャリアを紹介します。
キャリア紹介については、n＝1の紹介ではあるんですけれども、もしみなさんがDeNAにJOINしたらどんなキャリアを描くんだろう、というところをイメージしながら聞いてもらえるとうれしいです。
そしてその後に、「プロダクトマネージャー／事業責任者が考えるエンジニアとしてやっていて良かったこと3選」についてお話しします。後ほど詳細をお話しいたしますが、私は新卒10年目で、最初の半分がエンジニアです。その後の半分がプロダクトマネージャー／事業責任者/経営などをやっているので、今だからこそわかることを、しっかりお伝えできればと思っています。よろしくお願いいたします。
8つに分けた10年間のキャリア
まずは簡単に、私の自己紹介からします。馬場光と申します。2012年、ちょうど10年ほど前に新卒エンジニアとして株式会社ディー・エヌ・エーに入社いたしました。当時はソーシャルゲーム事業本部という、主にモバゲーを開発する部隊に配属されました。
そして3年後に新規事業のシステムを作り、6年目にビジネス転向をして事業責任者に、現在はDeNAとSOMPOホールディングスが作った合弁会社のDeNA SOMPO Mobilityの代表取締役社長、DeNA SOMPO Carlifeの代表取締役副社長をしています。どうぞ、よろしくお願いいたします。
そんな私の10年間のキャリアを、ざっくり8つに分けてみました。ですので、みなさんがもしDeNAに入った時に「このようなキャリアがあるのかなー」や「こういった考え方のアサインがなされるんだ」というのを疑似体験してもらえるように話していきたいと思っていますので、ぜひよろしくお願いします。
ずっと「ワースト5」だったエンジニア研修
まずは1年目の入社直後、エンジニア研修を受けました。もちろん今の研修とは変わっているのですが、当初2012年のころについていうと、40人ぐらいのエンジニアが同期にいまして、一斉にエンジニアの研修というところで、プロのエンジニアになるために、ネットワークやセキュリティ、データベースなどの幅広い知識をまずはインプットするような研修がありました。
その研修については、毎週その理解度チェックみたいなテストがあって、だいたい40人中、私はずーっとワースト5ぐらいで。なんとか新しい知識を身に着けて、同期のみんなに食らいついていくような数ヶ月を過ごしていました。
その知識をインプットした後には、実際にコードを書いて、プロダクトみたいなものを作って、コードレビューやプロダクトとしての触り心地、セキュリティ観点で攻撃される、などのテストを含む最終試験があるのですが、それをようやく卒業できたのが2012年の8月。約4〜5ヶ月ぐらいはずーっと勉強して研修を受けていたかたちになります。
『夕暮れのバルキリーズ』と『戦国ロワイヤル』の運用
その後、1年目の途中、エンジニア研修を抜けてソーシャルゲームの運用エンジニアになります。これが初めての現場配属ですね。
当初はモバゲーというゲームプラットフォームの中の、DeNAが開発・内製を行っているチームに配属をされて。もしかしたらみなさんご存じないかもしれないですが、『夕暮れのバルキリーズ』というゲームや『戦国ロワイヤル』というゲームの運用を行っていました。
ここから1年半は、初めて本物のコードに触るというか、プロダクトのコードを触るところで、もう毎日毎日驚きながら、とにかくコードを書いて、先輩のコードを読んで、レビューを受けて、勝手にレビューをしてみたいなかたちを繰り返していったのが、このマル2のフェーズになります。
他人宛のプルリクも全部確認
そうしているうちに2年目の最後ぐらいに、そのゲームタイトルのリードエンジニア、システム責任者にアサインされます。
まだ当時は、そもそもネットワークやインフラ自体の知識はそんなについていなかったんですが、1年半、とにかくガムシャラに自分が担当していたゲームのコードを読みまくりました。
いろいろな人のプルリクを、自分にメンションがついていないものもどんどん入っていってコードを読んだり、お願いされていないものもレビューをしたりして、自分が触っているこれらのゲームについては、すごく詳しくなっていきました。
おそらく、そういった動きを上司も見てくれていて、だったらまだスキル的には足りないけれども、チャレンジとしてリードエンジニアをやってみたらどうか、と任せていただいたのが、この2年目の終わりくらいです。
当時担当していた『戦国ロワイヤル』というゲームが月商6億円ぐらいで。ちょっとなかなか規模感が伝えづらいところなんですが、例えばシステム障害で1時間止めてしまった場合に、数千万円損害が出るような規模感のゲームを触っていました。
ですので、もちろん自分が書いたコードだけではなくて、システム全体、誰が書いても同等の品質になるようにするにはどうしたらいいか、そもそもアーキテクトどうしたらいいかというところに、必死に頭を悩ませていたのがこの3年目です。
「こんな事業おもしろいよね」から始まった新規事業
この3年目で、いろいろとスキルがついてきて、エンジニアとして自由になってきたと共に、別軸でDeNAの同期とよく新規事業などについて話をしていました。
飲み屋でよく「こういう新規事業はおもしろいよね」だとか「DeNAはこういう事業をするべきだ！」などアイデアを出し合っていたのが、この2〜3年目ぐらいのところです。
さらに、そういった話し合いを経て、ゲーム事業を卒業をして、新しい事業に取り組むというところで、この「Anyca」というサービスを立ち上げることになります。
まずは、一緒に飲みながら「こんな事業おもしろいよね」とか「こんな事業ってやはりDeNAがやるべきだよね」って話していた同期が、新規事業として会社に提案しました。ちょうど当時、DeNAとしてもゲームの次の柱になるような新しい事業を作ろうという考えがあったので、タイミングのマッチングもあり、我々が提案した「Anyca」というサービスを実際に作ってみることになって、その開発を担当することになりました。
当時、エンジニアはDeNAのCTOと私の2人だけでやっていました。先ほど南場さんのお話にもあった川崎さんがCTOです。
まず、CTOと私の2人で初めて、どのようにシステムを作っていくか、分担していくかっていう話になった時の川崎さんの一言目がコレでした。「ユーザーさんが触るとこ、全部やろうかな！」と。
さきほどの南場さんの話にもあったとおり、やはり一番大事なところは何かというところが自然に「ユーザーさんが触るところ」っていうようにイメージが湧いて、それが「そこの部分はしっかりやるから」というようなCTOの意思表示だったんじゃないかな、と思っています。
「Anyca」のシステム構成
とはいえ、もう少しわかりやすく説明をすると、これはちょっと古いんですが、当時の「Anyca」のシステム構成になります。
下のほうにユーザーさんが触るデバイス、スマホやPC、あとはハードのデバイスがあって、そこからつながるアプリケーションサーバーやデータベースがあると。そして右側のほうに、他社さんとの連携として、保険や決済など、いろいろな外部サービスとの連携があります。
これをざっくり分けるとこんな感じになります。なので、私は最初「Anyca」を作る時に、ネットワーク側や外部サーバー連携系、あとはPCサイトなど、そこらへんを4年目で担当して、ゴリゴリ作っていたのが「Anyca」サービス立ち上げ当初の話です。
その後、そのCTOが抜けたので、「Anyca」のリードエンジニアとしてアサインされて、システム全体に責任を持って開発を行っていました。
Androidも触るんだ！
その中で、Androidアプリのパフォーマンスがあまり良くないというデータも出てきました。当時Androidアプリだけは外注していたんですね。なのでそこについても、iOSと同じように、チームと近い距離で開発をスピーディにやっていって、より良いものにしていくという意味合いで、Androidも内製化しました。
せっかくなので、自分はサーバーしか触ったことがないから、Androidも触るんだ！ということろで、勉強期間を2ヶ月ほどもらい、ここでAndroidエンジニアにも転向しています。
2017年当時は、Androidのスキルもほとんどなかったんですが、Androidエンジニアが私一人という体制だったので、作りながら学ぶとか、学びながら作るみたいなところをグルグルとやりながら、なんとかサービスを出していたのがこの期間になります。2017年を振り返ると11日に1度というペースでリリースをしていました。
市場がない中で、市場を切り開く
そういうふうにエンジニアとしてのキャリアを着実に積み上げていたんですが、ここでビジネス転向が起こります。
「Anyca」を一緒に立ち上げたビジネス側の責任者が、DeNAの子会社の社長に抜擢されることになりました。というところで、一緒に事業の夢を見て立ち上げたエンジニアとして作っていた私が、事業責任者兼プロダクトマネージャーになることが決まって、この6年目の終わりぐらいから、ビジネス側の責任者にもなりました。
ここから、「Anyca」というC to Cカーシェアをやっていく中で、いろいろなビジネス的な意思決定や、施策を打っていくんですが、なかなかキャズムを超えるほどは伸びないと。
もちろん確実にどんどん大きくなっていって、いろいろなユーザーさんに触ってもらえるようになったんですが、より多くの人に使ってもらうためにはどうすればいいんだろうというところを考えた時に、やはり安心・安全を根本からアップデートしなきゃいけないと。
当時、日本ではC to Cカーシェアのサービスや市場がなかったので、「Anyca」というサービスが本当にその市場を切り開いている段階だったんです。市場を切り開くフェーズ、市場がまだない時というのは、どういった状態かというと、そういった市場専用の保険なども一切ないんですね。
市場がないから保険がない。だけど、保険がないから、なかなか安心できない。よって、サービスが伸び悩んで市場ができないんじゃないかという懸念があったので、そこからなんとか動き回って、7年目の終わりぐらいに、日本有数の保険会社であるSOMPOさんと会社を作ることになりました。これが、DeNA SOMPO Mobility、DeNA SOMPO Carlife 設立のきっかけの一つとなっています。
そして現在、その会社の社長と、子会社の副社長をやっています。
ターゲットユーザー群と“自分自身”の距離を測る
ちょっと簡単に、私の10年間のキャリアをググーっと10分ほどでまとめてみたんですが、DeNAに入ったころは、経営をやるなんて想定もしていなかったんですが、いろいろチャンスをもらって、今は楽しく、このキャリアをやっています。
順番が前後してしまうのですが、現在担当している事業が2つあります。1つ目がこの「Anyca」という左側のブルーのほうですね。個人間カーシェアになります。Airbnbの車版というような伝え方が、わかりやすいかもしれません。一般ユーザーの車をシェアするサービスになります。右側の赤いのが、マイカーリース事業で、「SOMPOで乗ーる」というサービスです。
ではここまできたので、そのようなキャリアを歩んだ私が今だから思う、エンジニアとしてやっていて良かったこと、今だからこそ思う、エンジニアという環境だったからこそ身に着けられたと思ってることを、3つ紹介します。
1つ目が、ターゲットユーザー群と“自分自身”の距離が測れる、というところです。これだけだと、ちょっと何をいっているのかわからないと思いますが。
例えば先ほどお伝えした「Anyca」という事業は、C to Cカーシェアで、大きくいうと、自分の車以外の車に乗るという市場があって。レンタカーやB to Cカーシェアとちょっと近い事業です。
その市場に後発で入っていく時に、特徴をもって入っていかないとサービスが立ち上がらないと。カーシェアは、密度ビジネスであるので、基本的には近くに車がないとわざわざ乗りに行かないんですね。
ただ後発で入っていく時に、密度高く車を集めることができない我々がユーザーさんに使ってもらうには、遠くても乗りたい車がある、駅で2〜3駅移動してもこの車に乗りたい！ というようなユーザーさんを多く集めて、その車好きの方々にまずはサービスを使ってもらおうと、いろいろな施策をやっていました。
そのようなフェーズの時に、例えば車好き向けの施策をやりたいとなった時に、車好きとはなんぞや？ というような疑問や意見のブレが出てくるんです。
感覚として、乗ってみたい車があったり、車雑誌を購入するみたいな方もいると思いますが、それを「Anyca」内のデータで定義した時に、どのような方が、この感覚と近い車好きにちゃんとターゲティングできるのかを、よく悩みます。
その時に私がやっていたのが、例えば一例ではありますが、「Anyca」のユーザーのデータをバンっと散布図に投げます。例えば、横軸がログイン頻度で、縦軸が車のお気に入り台数だという時に、この右上のトップ10パーセントが、より車好きだろうと。
ではこのトップ10パーセントに対して強いクーポンを配ってテンションを上げていこうということをやるのですが、それが本当に正しいのかどうかがなかなかわかりにくいです。そういった時に私がやっていたのが、これを自分を含むデータを丸投げをして、まずこのプロット群の中から自分自身のプロットが当てられるか、という確認をしています。
例えば自分がここにいて、トップ10パーセントに入っていなかったけれども、これが本当に自分自身が思ってる成果と一緒だったらどうか。自分をここにいると思ってやったらどうかというところで。
自分がターゲットユーザーになることはできないんですが、自分との距離感で、例えば隣にいるメンバーだったり、そういったユーザーたちがこの右上のほうにいるから、この縦軸横軸が正しくて、そのこの縦軸横軸で切ったトップ10パーセントに対して施策をやったら、うまく当たるんじゃないか。というようなログを仕込んで、データを見て、分析をして、自分との距離感を測ることをやっていました。
これによって自分自身の感覚の数値化だとか見える化ができた成功体験を、エンジニアだから得られたんじゃないかなと思っています。
頭の中＜パワポ＜プロトツール＜開発中アプリ
2点目が、もう名前のとおりです。この「頭の中・パワポ・プロトツール・開発中アプリ」を、不等号で表したものになります。
これもみなさんの中にも感覚的にあると思いますが、頭の中で考えた施策をそのまま作るよりも、アプリを開発しながら何度も触りながら、そこで意思決定をしたほうがいいものができる可能性が高いことに気づきます。
よく百聞は一見にしかず、百見は一験にしかずといわれますが、エンジニアのみなさんはすごくラッキーなことに、いったん手元で作ってみて、すぐ体験できるっていうような、圧倒的な強みがあります。
これは社長やプロダクトマネージャーになっても、だいたい私はwhyを決めることが多くて、その後のhowはエンジニアに任せ切る体制にしています。
任せ切るとなった時に、どれぐらい任せるかというと、例えば「こういうことをしたいよね」っていうwhyの擦り合わせさえ済めば、あとはもうプロダクトのマネージャー承認なしに、エンジニアが例えば開発中やテスト中に「こっちのほうが絶対いいんだ！」と思ったら、誰の承認を得ることなく自分で意思決定ができる、変えられるような体制を作っています。
またビジネス的な事業戦略策定においても、常にこの4つ、頭の中＜パワポ＜プロトツール＜開発中アプリが、頭の中に入っていて。自分が今考えていることは、どのフェーズのものなのか。もしかしたらまだ頭の中のフェーズだから、ちょっと他社さんのものを触ってみてより試してみたいなだとか、今は開発中アプリぐらいのレイヤーで、事業戦略のところを立てているから、これは自信をもって進んでもいいんじゃないかと、常に置き換えながら考えています。
「他責」からの卒業
そして最後は、他責からの卒業です。みなさん、コードを書き終わってEnterを押す時って、毎度「間違っているはずがない」と思いながらバンってEnterを押して、そしてだいたいエラーが出て「アチャー」となることが多いと思います。
プログラムの世界は、本当に純粋なロジックの世界なので、少しでも間違いがあったらちゃんとエラーを出してくれますし、そしてそのエラーの原因は99.9%自分が書いたコードのせいなんですね。
なので、まずエラーが出たら、自然に自分の書いたコードを見直しにいきます。この動きが、案外、ビジネスの世界に入ると難しい貴重な動きになります。
例えば営業でも、毎回準備をやり切って自信満々に営業に行くんですが、こちらも一発でオールオッケーだったり、即契約とは、ほとんどなりません。
その時に、相手に対して「なんでわかってくれないのか」と、他責にしてしまったら、そこで終わってしまうことが多くて、エンジニアの時にやっていたように、「どこを間違っちゃったかな」と、自分側のエラーをまず考えます。そうすると、経験上、次の提案や話し方、そもそもの企画などがブラッシュアップされていき、間違いなく本来成し遂げたかった目標に近づくことが多いです。
世の中は、プログラムみたいに純粋なロジックだけの世界ではないので、なかなかうまくいかないこともあるんですが、みなさんがプログラミングをする時のように、営業やビジネスの時でも、何かしらいろいろ問題があった時に、他責、他の人の責任にするのではなくて、自分側がどうしたら良かったのかを考えて改善していけば、必ずいい方向に積み上がる、そして、それを自然に身に付けやすい環境にいる皆さんはすごくラッキーです。というお話でした。
エンジニアをやっていて良かったこと、気づけたこと
ちょっと駆け足になってしまいましたが、エンジニアをやっていて良かったこと、気づいたことをまとめると、ターゲットユーザー群と自分自身の距離感を測れる。あとは、「開発中アプリ＞プロトツール＞パワポ＞頭の中」というように、比較ができる。そして他責から卒業したところが、明確なメリットとしてあると、私としては振り返っています。
以上が、エンジニア時代に経験できて良かった、あとはエンジニア環境にいて良かったと心から思っているスキルとマインドでした。みなさんの日々の開発が、今日からより有意義になるとうれしいと思っています。発表としては以上になります。ありがとうございました。
司会者：馬場さん、ありがとうございました。自分もエンジニアから人事だったりとか、組織開発に携わるようになったので、すごく共感できるポイントがいっぱいあって、なんかすごく楽しかったです。
自分の感覚とターゲットユーザー群とのズレが大きくなってきた場合
司会者：それではQ＆Aセッションに移りたいと思います。最初の質問はこちらです。「自分の感覚とターゲットユーザー群とのズレが大きくなってきた場合、それを小さくする方法はありますか」という質問なんですが。どうでしょうか、これは。
馬場：おもしろいですね。たぶん自分の感覚とターゲットユーザー群、となった時に、ターゲットユーザー群を変えてしまうと本来の目的から外れてしまうと思うので、自分を変える手法のほうを取らざるを得ないと思うんですね。
司会者：はい。
馬場：とはいえ、経験的に自分を何回も変えるのは、なかなか現実的ではないんですよ。
なので、今日お話ししたように、ズレというもの自体はもう仕方がないと割り切る。その中でどれぐらいズレているのかの距離感をやはりとにかく測るべきなんですよね。
その距離感の測り方が、自分の場合でいうとたぶんデータの見方なんです。 それ以外にも、例えばユーザーヒアリングや、この人だったら近いのかもしれないというような、感覚的なものを周りに積み上げていくことも大事かもしれないですね。
ズレは小さくならないですが、距離感をしっかり測りましょうというのが、ちょっと回答になっているかわからないですけれども。
司会者：そうですね。距離感をどう測るのか難しいみたいな話も、さきほどのセッションの中でも、データのところでありましたね。
馬場：データもありましたし、例えば「Anyca」がやっていた試みとしては、月に1回ユーザーさんを4〜50名呼んで、飲み会みたいなものをやっていたんですね。
そこで、毎月必ずいろいろなユーザーさんに話を聞いて、この人って自分とはこれぐらいズレているなっていうのをストックしながら進んでいくようなことはやっていましたね。
司会者：なるほど。おもしろいですね。ということで、1問目の質問はこんな感じでした。ありがとうございます。
損害が出るかもみたいな緊張感の中で働く感覚は？
司会者：では、続いての質問にまいります。「損害が出るかもみたいな緊張感の中で働くのは、どんな経験なんでしょうか」。もうヒリヒリしているときのやつですよね。
馬場：そうですね。当時ソーシャルゲームをやっている時だったと思うのですが、ちょうどDeNAの全エンジニアやっていたと思うのですが、自分が開発している画面とエラーログを監視する画面をディスプレイに並べて、エラーのほうは「tail-f」でずーっとログを流し続けるんですね。
馬場：何かしらこう、エラーが起こった時に、これがブワーと、もう滝のように流れるんですね。そういうのにドキドキしながら、バグフィックスをしていくってところなんですが。
緊張感はやはりメチャクチャあります。ただその時に、チームの誰からも責められることはなかったんですよね。
みんながその瞬間「自分が書いたコードにミスがある」とか「お前何やってんだよ！」という雰囲気ではなくって「よっしゃ、これを直してくぞ！」というように、みんなが一斉に向かってやっていくカルチャーだったので、そこは一種、自分自身で、エラーを出した張本人ではない第2人格みたいなものを出して、修正に向かうというか向かわせてもらったと。
最終的には、その障害やユーザーさんへの対応まで終わった後に、ちゃんとなんで障害が起こったのか、再発防止策みたいなのはやるんですが、こういった環境だったので、なんとか心折れずにやれたんじゃないかな、という感じですかね。
司会者：ヒリヒリしてけっこう、こう生きた心地しない時もあるけど、けっこう仲間のフォローとかで行けた経験とかですね。
馬場：仲間のフォローが大きいですね。
司会者：ありがとうございます。それではお時間になりましたので、こちらで質疑応答並びに本セッションを終了いたします。みなさま、馬場さん、ありがとうございました。
馬場：ありがとうございました。
