創業間もないスタートアップのCTO
小林南実氏（以下、小林）：みなさんこんにちは。株式会社ウィズカンパニーの小林です。私は約5年前にDeNAに新卒入社して、そして現在ウィズカンパニーという、創業間もないスタートアップでCTOを務めています。今日はDeNAの卒業生という視点で、DeNAのエンジニア、キャリアについてお話ししていければと思います。
みなさんは、新規事業を立ち上げたり、スタートアップで働くことに興味はあるでしょうか。小さいチームで裁量を持って働きたいと思っている人もいるかもしれません。そこで今日は、新規事業立ち上げの現場で大活躍するためのスキルを、みなさんに紹介したいと思います。
今日の話を通して、エンジニアとしてサービス開発に携わっていくのはどういうことなのか、特にスモールチーム、小さい規模のチームで活躍していくためにはどうあるべきなのか、そういったイメージを少しでも明確にしてもらえればと思っています。
どういう経緯を経て今のような働き方に興味を持ったのか
本題に入る前に、まずは実際に私が歩んできたキャリアについて、紹介します。どういう経緯を経て今のスタートアップCTOというような働き方に興味を持っていったのか。そして、そのための力をどうやって身につけていったのか。そういった点についてお話ししていこうと思います。
時をさかのぼること今から約5年前、DeNAに新卒入社しました。そして最初に配属されたのは比較的小規模なチームで、全体で10人ぐらい。エンジニアだけだと2〜3人ぐらいのチームでした。
そういった小規模なチームということもあって、開発にまつわる役割を幅広く経験できたことが、今の自分にすごく活きているなあと感じています。
例えば、自分のメイン担当であるネイティブアプリだけじゃなくて、サーバーやWebフロントの開発にも携わらせてもらったり。あとはビジネスメンバーとの距離も非常に近くて、新機能の仕様の部分から一緒に議論に入っていったり、そういったかたちで開発に携わる経験をこの頃から積めました。さらには開発をリードする、いわゆるリードエンジニアみたいな役割も早いうちから経験できました。
そういった中で、「エンジニアとしてこういうふうに事業に関わっていきたいな」というイメージがだんだんと明確になってきました。この頃から、スタートアップのCTOだったり、いわゆる新規事業を立ち上げるような、そういった働き方や関わり方に強く興味を持つようになりました。
私が大事にしている軸が2つあって、1つ目は、ビジネスメンバーと近い距離でサービス開発に携わりたい、ということ。ビジネスメンバーから直接、想いやアイデアを受け取って、共に議論していく。そういったところから開発に関わっていきたいと、強く思うようになりました。
そしてもう1つは、幅広い役割で事業に貢献していきたいということ。1つの領域に特化して専門性を磨くよりも、今事業に必要な役割がなんだろうというのを都度都度自ら考えて、臨機応変に幅広い役割をやっていくのが、自分の強みが一番事業に活かせるやり方だと気づきました。
このように、この頃からスモールチームでの開発に興味を強く持ちつつも、技術的なスキルに不安を感じていた私は、このタイミングで非常に大規模なチーム、ネイティブアプリのエンジニアだけでも30人以上いるようなチームに異動しました。
このチームでは、同じ技術領域を専門とする方々がたくさんいたので、その方々からのインプットだったり、あとは開発を最適化する仕組み作りみたいなものもいろいろあって、そういうのを肌で感じたり、大規模チームだからこそ得られる経験がたくさんありました。
今振り返っても、スモールチームでの事業立ち上げに挑戦する前に、こういった環境での開発に挑戦して、本当に良かったなと思っています。なので、DeNAのように1つの会社の中で、いろいろ違う環境で経験できるのは非常にありがたいな、と思います。
そして、ついに4年目になるタイミングで、Delight Venturesで事業の立ち上げに携わることになりました。
Delight Venturesは、起業のハードルをとことん下げて起業家を全力で応援するというビジョンを掲げている、DeNA母体のベンチャーキャピタルになります。
スタートアップ企業への投資を行っていたり、それだけじゃなくて、Delight Venturesの中からも事業を立ち上げる取り組みも行っています。この事業立ち上げの取り組みには、DeNA社内外から手を挙げることができて、事業立ち上げが順調に進めば、独立というかたちで起業できます。
これは、起業を志す人はもちろん、エンジニアとしても起業を前提とした事業立ち上げに挑戦できるので、非常におもしろい環境です。
そういった環境に惹かれて、私がDelight Venturesでゼロから開発に携わることになったのが、「WITH Fitness」という、オンライン上でパーソナルトレーニングを提供するサービスです。
この事業は、メンバー3人という、非常に小さいチームで立ち上げを行ったんですが、スタートアップでの事業立ち上げというと、このような構成で始めるところも多い印象です。詳しくは、2021年の3月に開催されたDeNA TechConにて話しているので、興味ある方はそちらもあわせてご覧ください。
そして現在、その事業が独立するかたちで、ウィズカンパニーのCTOになり、現在も引き続き「WITH Fitness」の開発に携わっています。
サービス開発における議論の場でしっかりと発言できる
キャリアの紹介はここまでなのですが、4年目から事業立ち上げに関わっていく中で、最初の3年間でこんなスキルを身に着けておいて良かったなと思う点がたくさんありました。その経験を踏まえて、いよいよ本題です。新規事業立ち上げの現場で大活躍するための5つのスキルについて、お話ししていこうと思います。
1つ目はズバリ、「サービス開発における議論の場でしっかりと発言できる」というスキルです。こちらは、いわゆるエンジニアリング的なスキルではないように思うかもしれませんが、一番といっていいほど重要だと思っているので、1つ目に持ってきました。
例えば企画メンバーから、「アプリにこういった新機能を入れたいです」と提案があったとしましょう。エンジニアであるあなたは、どうしますか。「すばらしい機能だ！」と純粋に受け止めて「実装進めておきます」と、話をそこで終わりにするでしょうか。
それではいけません。どんなにすばらしく見える提案でも、もっと深く理解できる点や、さらなる改善点、実装上の懸念点など、そういったものの1つや2つは必ずあるはずです。
なので、1度の議論の場で、そういった気づきをチームとしてどれだけ見出せるかが、サービスの最終品質や開発のスピード感に、非常に影響してきます。
エンジニアならではの視点での提案はもちろん、サービスをより良くするための発言内容に、役割なんて関係ありません。なので、何か少しでも気づきはないかと考えて、前のめりの姿勢で1個1個のミーティングに臨んだり、そのうえでどんなにささいなことでも発言してくれる人は、サービス開発において非常に貴重な人材だと思います。
そんな発言ができるようになるには、日頃からどんな人の話でも違和感を覚える点が必ずある、というスタンスを持つことがメチャクチャ大事です。
これは私の入社初日のエピソードなんですが。初日は社長を始めとする方々のお話を聞いて、そして最後に日報を書く感じでした。話を聞いた時に私は、もう本当に純粋に「やはり偉い人の考えることすごいな」と感銘を受けて、いかに多くのことを学んだかを、もう日報にひたすら書いていったんですね。
なんですが、メンターさんからは「こんな感想じゃぜんぜん駄目。どんな人の話でも、違和感や不明点に気づける部分あったはずだよ」っていう、厳しいフィードバックをもらって、もう雷に打たれたような衝撃を受けました。
それ以降、人の話はある意味疑って受け止めるスタンスが身に着いて、それは本当にサービス開発の現場でも、驚くほどの効果を発揮しています。
また、議論の場で発言する経験をひたすら積むことも大事です。そのために必要なのは、自分のやる気じゃなくて、身を置く環境です。
私が入社して最初に配属されたチームでは、ベテランの先輩は鋭い気づきをたくさんチームに与えていましたし、1つ上の新卒2年目の先輩も、年次にかかわらず、意見を交わしていました。
そんな環境にいたら「新卒1年目の自分が発言なんてできるかな」という不安はすぐに飛んでいって、自然と議論に積極的に参加できるようになっていました。
こういった環境を見極めるためには、例えば就活でいろいろな会社の人と話す中で「自分の考えを自然と話せちゃうなあ」だったり、逆に「自分におもしろい質問をしてくれるなあ」だったり、そういった視点を意識して話してみるといいかもしれません。
サービス開発におけるWHY／WHATを深く考える
続いては「サービス開発におけるWHY／WHATを深く考える」スキルです。
例えば「ここのボタンのサイズを大きくしてほしい」と提案された時、あなたはどうしますか。「そんなの簡単に実装できるぞ」って思って、すぐに実装に取り掛かるでしょうか。
それではいけません。一度立ち止まって、なぜボタンを大きくすべきなのか、というWHYにしっかり向き合う必要があります。
例えば、ここで企画メンバーにその意図を聞いてみると、「このボタンを押す人が少ないので、もっと目立たせるべき」と答えが返ってきました。
まだここで納得してはいけません。サイズが本当に問題なのだろうか。サイズではなく、ボタンのタイトルがわかりにくいのではないか。そのように、チーム一丸となってWHY／WHATをドンドン突き詰めることで、本当に必要な機能改善に近づくことができます。
もちろん、機能改善に正解はありませんが、少なくとも自分自身が納得していない状態でそれをお客さまに届けてはいけません。たとえ議論の末、最初の提案どおりで進めることになったとしても、それを実装するエンジニア自身が深く理解できた、ということが非常に重要です。
このように深く考えられるようになるためには、施策単位で仕事を任せてもらうことが非常に重要です。
どういうことかというと、私のDeNA入社前のイメージでは、新卒入社して最初の頃は、会員登録ボタンを大きくしてくださいのような、タスクレベルでの仕事を任されるイメージでいました。
ですが実際は、配属直後から、会員登録率を向上させる、というような施策レベルで、エンジニアとしてのオーナー・ミッションを任されました。
なので、こういった機能改善をすればいいかもしれないというWHATだったり、そういうところから企画メンバーと議論したり。あとはそもそも、なんで会員登録まで至らないユーザーがいるんだろうというWHYの視点を自然と持てるようになりました。
これは、何も私に限った話じゃなくて、DeNAでは仕事の起承転結を丸っと任せる文化が根強くあって、WHY／WHATを深く考える経験が積みやすい環境だと感じます。
また、自分より高い視点で事業を見ている人と話すことも非常に大事です。自分の場合、事業リーダーとは日常的に話す距離感にあったので、事業全体を見ている人の視点が自然と知れる環境にありました。
また、事業本部長だったり、会長である南場さんともフラットに話せるような社風もあって、自分の視座が上がったり、WHY／WHATを深く考えていくきっかけがたくさんある環境だったな、と今振り返って思います。
そういう環境を見極めるためには、例えばいろいろな会社の人と話す中で、エンジニアは他ポジションのメンバーとどのように関わりながら仕事をしているんだろうか。あるいはエンジニア自身がサービスについて、どういった視点で考えているのか。そのあたりを意識して話を聞いてみるといいかもしれません。
可読性／柔軟性高くシステムを実装できる
ここまでは、実装に入る前段階で必要なスキルについてお話ししてきました。3つ目は「可読性／柔軟性高くシステムを実装できる」というスキルについて紹介します。
新規事業を立ち上げる、と聞くと「スピードが重要だからコードは汚くてもしょうがない」と思う方もいるかもしれませんが、決してそんなことはないと、私は思います。
見切り発車で開発を始めると、1ヶ月ぐらいでなんだかよくわからないコードになっていって、サービス開始する前にガクンと開発スピードが落ちてしまったり、なんとか開始までいけても、サービス開始後のプロダクト改善がなかなか進まなかったりします。
サービス開発は短距離走ではなく、長距離走です。スタートダッシュだけでなく、早く長く走り続ける必要があるので、最初から可読性／柔軟性を重要視すべきです。
そもそも、コードの品質とスピード感はトレードオフではなくて、むしろ品質を高く保ち続けることで、トータルのスピードは上がっていきます。
さらにいえば、コードの品質と実装スピードを両立するスキルを身に着けてしまえば、それがもう最高なので、そういったスキルが新規立ち上げの現場では、より重要になってくるんじゃないかなと思います。
そのためには、まずは小さいところからこだわり抜いて、開発に向き合うことがとても大事です。
例えば、変数名やメソッド名から自分の実装意図が伝わりやすいように、妥協なく命名にこだわっていくことが第一歩です。
実際私も新卒1年目の当時、メンターさんから、本当に妥協なく細かい点からコードレビューを受けた経験が、今の事業立ち上げの実装力につながっていると感じます。
また、割れ窓理論っていうものがあって、割れた窓が1つでもあると、他の窓を割る心理的なハードルが下がるという話なんですが。システム実装にもこの理論が本当によく当てはまっていて。いわゆる負債があるコードには、ドンドン負債が溜まっていくので、「ひび1つ入れないぞ」ぐらいこだわりが大事です。
そしてもう1つお勧めしたいのが、「リファクタリング・リアーキテクチャの経験を積む」ということです。
私はヘルスケア事業部では、Androidアプリの実装全体をリファクタリング、いわゆるコードをきれいにしていって、新しい言語に置き換えるプロジェクトを担当したり、あとはオートモーティブ事業部でも、既存の機能を丸ごと再設計し直して、適切な実装に置き換えるプロジェクトを担当しました。
これらは、いわゆる負債を解消するためのプロジェクトなので、新規事業に興味がある人からすると地味に思うかもしれません。しかしこういった開発は、技術的に非常におもしろいですし、もう何より設計力や実装力がメチャクチャ身に着きます。
なぜかというと、こういうプロジェクトは、システムの可読性や拡張性に集中して開発できるからです。あとは、書き直す前のシステムのビフォーがあるからこそ、自分が書いたアフターがどれぐらい優れているか、比較評価しやすいです。
なので、将来的に自分でゼロから開発をしたいと思っている人こそ、こういった機会にはぜひ挑戦してみてください。
1サービスを丸っと開発できるフルスタックな技術力
そして、技術に関するスキルとしてもう1つ紹介するのは、「1サービスを丸っと開発できるフルスタックな技術力」です。フルスタックというと、もちろんクライアントからサーバーまで、自分で完璧に実装できる状態に越したことはないんですが、そうでなくても、全体的にある程度実装イメージを持てる状態が非常に重要です。
そうすることで、初期の技術調査だったり、エンジニアの採用戦略だったり、そういったプロダクト開発を進めるに当たって必要なことをリードしていけます。
自分の中の技術的な引き出しが多ければ多いほど、適切な選択肢を比較・検討できるようになって、より適切な開発戦略を立てられます。
さらにいうと、ある程度のレベルであれば、ひととおり自分で実装できる状態になり、事業立ち上げのスタートダッシュがものすごいスピードで切れるので、なお良いかなと思います。
そういった技術力を身に着けるには、自分の専門領域以外にも挑戦させてくれる環境に身を置くことが近道です。前半でもお話ししたように、私が初めて配属されたチームでは、自分のメイン担当以外のタスクにも挑戦していました。
また、自分が直接他ポジションの開発をやらないにしろ、他ポジションのエンジニアがすごく近い距離にいるのは、自然と開発の様子を知れたり、あとは勉強がてらにちょっとコードを見させてもらったり、そういうのも非常にいい経験で、ある程度の動くものであれば、実装イメージはつく状態になりました。
さらにこうやっていろいろな技術に触れることで、他の技術に挑戦するハードルが自分の中でドンドン下がって、いざ新しい技術に挑戦する時に、ぜんぜん怖くない状態にもなれたら、強いんじゃないかなと思います。
なので、その技術が極められるかどうかはあまり気にし過ぎずに、つまみ食いしていくことそのものが、いい経験になると私は思います。
各分野のスペシャリストのレベル感をイメージできる
そして最後に紹介するのは「各分野のスペシャリストのレベル感をイメージできる」というスキルです。これまでお話ししてきたように、事業立ち上げにおける1人目エンジニアには、サービスへの関わり方としても、技術的に見ても、幅広い役割が求められます。
しかし幅広くスキルを身に着けても、そのすべてを深く極めていけるかというと、なかなか難しいと思いますし、逆に自分のスキルはどれも浅いんじゃないかとコンプレックスを感じがちだったりします。
そんな中で私が大事にしているのが、「スペシャリストのレベル感をイメージできる」ということです。ちょうど前のセッションでも、スペシャリストのみなさんの話があったと思うので、そちらもあわせてチェックしてみてください。
例えば、DeNAにはQAの専門部隊があります。リリース前のアプリケーションの検証を始めとした、システムの品質管理に関するスペシャリストです。アプリの検証っていうと、学生の頃は、開発を終えた後にアプリをなんとなくいろいろ触ってみて、不具合を出すようなイメージだったんですね。
しかしDeNAでは、新機能をリリースする際、開発チームが実装を進めるのと並行して、QAチームは検証すべき項目を網羅的に洗い出したり、誤りなく検証が行えるように正確な手順書を作成します。
そして実装が完了すると、完成したアプリをQAチームにお渡しして、検証を実施していく流れです。そうやって一体となって進めることが、品質の高いアプリを作り続けることにつながります。
現在ウィズカンパニーでは、限られたメンバーであらゆる役割を担っているため、アプリの検証もエンジニアやビジネスメンバーが進めています。
しかしそこは、なるべく妥協せず、お世話になったQAチームの方たちを思い出しながら、検証項目はあの当時のアレを参考にして作成していこうだったり、ちょっとした仕様不備も見逃さない、あのプロの姿勢を思い出したり、当時の経験が現在のスタートアップでのプロダクト開発の品質に与えている影響は、非常に大きいです。
そういったイメージを持つためには、やはりスペシャリストの近くで一緒に開発に関わることが近道です。実際に一緒に働くことで、仕事の進め方やノウハウを自然と知ることができて、いざスモールチームでがんばろうという時に、「そういえばあんなふうにスペシャリストの方たちは取り組んでいた」と思い出せる引き出しが増えます。
また何より大事なことが、当たり前の基準が引き上がる、ということです。高いレベル感の人と働くことで、それが当たり前になって、自分一人でがんばらなきゃいけない場面でも、自然と妥協が生まれないスタンスが身に着きます。
スペシャリストと働ける環境を選ぶためには、何かの領域に特化した部門がどれくらいあるかが1つの参考材料になるかもしれません。一般的に会社や事業の規模が大きくなると、チームが専門性に特化して細分化されていく傾向にあるので、1つの参考になります。あとはその会社の人が外部登壇していたら、それをチェックしてみたりするといいかもしれません。
小さなことにこだわり過ぎると良くないのでは？
ということで、本日はメガベンチャーからスタートアップCTOに至るまでに、私自身が歩んだキャリアの紹介と、新規事業で活躍するためのスキルについてお話しいたしました。
私を含めて、今日はいろいろな方のキャリアが垣間見える1日になっていると思います。それらの話を参考に、自分自身はエンジニアとしてどういったかたちで事業に関わっていきたいかを考えてみると、おもしろいかもしれません。
ということで、今日話した内容が、みなさんがこれから歩んでいくキャリアや、身に着けていくスキルの参考になれば幸いです。以上です。ありがとうございました。
司会者：小林さん、ありがとうございました。すごくこう、今までのキャリアがギュッと詰まったような。
小林：詰めました。
司会者：すごく密度の高いセッション、ありがとうございました。
小林：ありがとうございます。
司会者：それでは、Q＆Aセッションに移りたいと思います。最初の質問はこちらです。「小さなことにこだわり過ぎると、スピードが落ちたり、結局作ってみないとわからないこととかありそうだけど、そういうことはないのか」という質問です。
小林：私がこの質問見て思ったことは、私は「急がば回れ」という言葉が好きで。例えば「これぐらいでいいや」って妥協してリリースしちゃったほうが、リリースは1日早いのかもしれませんが、妥協したことが積み重なって、どっかでなんか「ちょっとプロダクトを抜本的に考えなきゃいけないね」ってなっちゃったり。
あと、さきほど話したみたいに、コードもちょっと妥協して実装すれば、その瞬間は早く機能が出来上がるかもしれないけど、やっぱ積み重なって技術的負債になって、後々リファクタに時間をガッツリ取らないといけなくなったりとか考えると、私は、トータルのスピードとしては、やっぱり小さなことにこだわるのが、逆に大事になってくるかなって思います。
あとそれとは並行してもう1つ大事なのは、やはり小さなこだわり、例えば変数名へのこだわりなどが、時間掛けずとも自然とそれができるようになるスキルを身に着けちゃえばいいと思うので。そういったところに妥協しないためにも、技術力アップは、大事なのかなと思っています。
司会者：どうしてもサービスを「明日リリースしなきゃ」みたいな時は、視点が狭まっちゃうのかなと思うんですけど。そういう時に、広げるためのコツとかってあったりしますか。
小林：そうですね。コツと言われると難しいのですが、私がこういうスモールチームで働いていると思うのは、企画メンバーなどからエンジニアに気を使われちゃう時があって。どういうことかというと、例えば企画メンバーが最後にちょっとデモを見て、本当はここを直してほしいんだけど、エンジニアの実装工数が掛かっちゃうな、というように躊躇してしまう場面があったりします。
だからこそ、最後、実装するエンジニアの私が、「ぜんぜん言ってください」「もう私だったらすぐ作れるんで」ぐらいの感じで。そういうエンジニアがいて、チームのそういう細かいところも妥協なくやれることを、エンジニアのスタンスでアピールしてくのも、大事かなと思っています。
やはりそこを妥協したら、どんなに早くやってもいいものができず、あまり意味がないと思うので。
エンジニアだからこそ、みんながそういうスタンス、自分はぜんぜんやるぞっと思うのは、けっこう大事なのかなって思います。
司会者：はい。ありがとうございました。
