2018/06/01

「CTO役」に必須なのは徹底した目的志向！ DeNAの新規事業エンジニアが語る7つの心得

「CTOに必要なことって何ですか？」

 

CTO役を何度も経験してきたエンジニアの回答は、「徹底した目的思考」でした。

 

DeNAのサービスインキュベーション事業部（以下、SI事業部）は、ゲーム以外の新規事業立ち上げを担う部署。ここではほとんどの場合、プロダクトオーナーとエンジニアの2人でリーンに開発をはじめます。

 

今回の記事では、同部署で“CTO役”として数多くのサービスに参画してきた小田賀一と田坂祐太が、立ち上げの各フェーズにおいて必要な心得を語ります。その言葉には、幾多のチャレンジを続けてきたからこそ滲み出る“極意”が詰まっていました。

 

シードフェーズの心得：目的のために最小コストで動く

・最低限の人数で”阿吽の呼吸”を実現

小田：シードフェーズで最も大切なのは「MVP（※1）を作るという目的のために必要な最小構成は何か」をスピーディーにジャッジすることです。

 

私たちの部署は「最初の2か月でMVPを作って、次の1か月で検証する」という早いサイクルで動いていくため、リリース後は高速でPDCAを回す必要があります。

そのために必要なのはプロダクトオーナーとエンジニアとの”阿吽の呼吸”です。

 

SI事業部でプロジェクトがスタートする際には、「POが考えた企画を事業部に提出し、承認後に担当エンジニアを探す」という流れを取る場合が多いです。

 

初期バジェットの都合から、エンジニアの人数は1名からスタートすることがほとんどです。そのため、エンジニアは技術力だけではなく「企画についてPOと同等の理解度を持つこと」も重要になります。

 

サービスの初期フェーズでは、エンジニアはPOと二人三脚でプロジェクトを推進していくため、理解度が噛み合っていないと、阿吽の呼吸で業務を進めることが難しくなってしまうからです。

 

※1……Minimum Viable Productの略。お客さまに価値やサービスを提供できる最小限の製品のこと。

 

コマース＆インキュベーション事業本部サービスインキュベーション事業部システム部 小田賀一　
新卒でヤフー株式会社に入社、Yahoo! メール、広告システムの開発に携わる。カナダ留学を経て、2010年にDeNA入社。国内外、計9つのゲームの立ち上げ、運用に従事した後、2016年より現職。

 

POとの理解度を合わせるには、エンジニアが自発的に情報をキャッチアップしようとする姿勢が重要になります。私の場合は、プロダクトオーナーがどんなニーズを発見したのか徹底的に調査しますし、世の中にある類似サービスなどもかなり使い込みます。

 

・MVPは極限までミニマムに

田坂：二人三脚でプロジェクトを推進するという話が出ましたが、MVPの検討にエンジニアも大きく関わります。

 

POとの理解度を合わせて、お客さまがサービスにハマってくれるようなコアな価値（コアバリュー）を提供できるMVPを徹底的に議論します。POの経験が浅い場合MVPが大きすぎることもあり、エンジニアが初期のMVP決定において果たす役割はとても重要なんです。

 

コマース＆インキュベーション事業本部サービスインキュベーション事業部システム部 田坂祐太
研究開発系のベンチャー企業で医療システムやB向けWebサービスなど4つのサービス開発を経験。2016年DeNAに新卒入社し、いくつかのサービスでリードエンジニアを担当。現在はクンカブルのエンジニア。

 

MVPが固まるとエンジニアは実現のためにプロダクトの性質に最適な手段を使って開発をします。例えば、「テストコードは必ず書いた方がいい」と一般的には言われていますが、あえてテストコードを“書かない”箇所を作る選択をすることもあります。

 

なぜなら、サービスの新規立ち上げでは機能の追加・変更・削除が多いので、書いたテストコードが無駄になってしまうこともよくあるからです。恒久的に変化しない機能はもちろんテストコードを書きますが、変化する可能性が高い機能は書かないことも多いですね。

 

小田：サービス立ち上げのフェーズでは、手段が目的化してしまうと開発のスピードが出ません。目的は何か。それを達成するために最適な手段を選べているか。それらの点を常日頃から考えておくべきだと思います。

 

・あくまでも技術は手段

田坂：シードフェーズでは、一刻も早くプロダクトをリリースして仮説検証を回すことが大切です。その目的を達成するには、技術選定にも細心の注意が必要になります。

 

なぜなら、新しすぎる技術やエンジニアが経験のない技術を使うと、習得に時間がかかったり予期せぬトラブルが起こったりする可能性があるからです。そのため、一定の使用実績があって技術的に“こなれている”もの、エンジニア自身が経験のあるものなどを使うようにしています。

 

とはいえ、リスク回避のために全く新技術を導入しない方針にしてしまうと、メンバーの成長が鈍化してしまいます。そのため、自分たちのチームでは「新しい技術は必要に応じて1つまで使っていい」というルールを決めているんです。

 

SI事業部ではリリースから1週間くらいで各種の数字を見て、結果が芳しくなければ元に戻すことも多い。そのため、1つひとつの作業が遅延してしまうと、プロダクトの改善サイクルに影響が出てしまいます。だからこそ、リスクが高いチャレンジを複数やらないという方針なんです。

 

アーリーフェーズの心得：目的のために“必要な分だけ”改善する

・ 仮説検証では、目的と検証可能性を常に考えておく

田坂：サービスローンチ後のアーリーフェーズでは、仮説検証をどんどん実施していきます。新規事業は、サービスが提供する体験が世の中で仮説検証されていないものも多いので、検証作業が特に重要になります。

 

このフェーズにおいて重視しているのは「仮説検証の目的が明確になっているか」「施策の検証が可能か」という2点です。

 

例えば、「利用者のアクティビティを高めたい」などの漠然とした目的ではいけません。「このサービスでは投稿にコメントがある利用者は継続して利用するが、コメントがあまり付いてない利用者は離脱する傾向がある。なのでコメントを促進するためにコメントするボタンを設置する」など、具体的現象に基づいた検証可能な目的であることが重要になります。

 

また、1度のリリースで複数の仮説を立てて複数の機能を実装すると検証しづらくなるので、仮説は1つに絞ることも大切です。

 

・サーバ増強やコード改善は「達成したい目標」をベースに決める

田坂：開発初期はスピードを重視し、負債を抱える覚悟と軌道にのったあとの返済（リファクタリング）を見据えて開発していきます。そのとき求められる要求に応えられるレベルで最小限の実装をすることで、変化を恐れないようにするためです。

 

大規模開発の場合、設計をじっくり作り込んでから実装をスタートすることも多いですよね。でも、小規模開発において最初からそれをやろうとすると、無駄な時間的コストが大きくなってしまいます。

 

だから、最初はまずスピード感を持って開発できるような設計からスタートします。プロジェクト開始から半年くらい経ってサービスが軌道に乗ってきたら、リファクタリングを検討していくことが多いです。

 

小田：その際に、改善の基準とするのは「サービスが達成したい目的」です。例えば、次のフェーズに「DAUを○○まで伸ばしたい」という目標があるならば、そこから逆算して「そのDAUを目指すならば、これくらいのサーバスペックが必要だ」と算出していきます。

 

また、コードのリファクタリングも、目標を達成するうえでボトルネックになりそうな箇所を先読みして解消していくようなイメージでやっていきます。つまり、判定の基準は常に「目標を達成するためにシステムとして何が必要か」にあるんです。

 

小田：コードのリファクタリングは、サービスに求められるパフォーマンスや開発にかかる工数、必要な品質、バジェットなどを考慮したうえで検討していきます。

 

リファクタリングをしている期間に機能開発のスピードが止まらないようすることも重要な要素です。

 

バジェットが出て次フェーズの計画をするタイミングに行ったり、エンジニアが2人以上いる場合は、1人はリファクタリングをして1人は機能改修を担当する、などの役割分担をして開発のスピード感を損なわないように気をつけています。


グロースフェーズの心得：目的に適うチームを作る

・「目指しているKPIに必要なチーム構成は何か？」を考える

田坂：サービスがグロースフェーズに入ったら、チームの規模も拡大していく必要があります。メンバーをどれくらい増やすべきかを判断するうえでも「目的をベースに考えること」が重要です。

 

例えば、次のフェーズに実施する施策が「なるべく早いサイクルでPDCAを回す必要がある」という性質を持っているならば、人件費を増やしてでもエンジニアを増員し、開発期間を短くします。逆に、効果検証に時間がかかる施策ならば、人数を増やさず倍の期間をかけてトライすることもあります。

 

小田：チームに引き入れるメンバーを考える際にも、「プロダクトの成長に必要なスキルセットは何か」をベースに考えます。例えば、私が担当しているサービスでは、スケールするためにサーバサイドエンジニアが必要になってきたため、追加のバジェットが出たタイミングで増員を行いました。

 

アサインするメンバーを決めるにあたり、事前に社内エンジニアの評判などを噂レベルで仕入れておき、候補として挙げておきます。

 

DeNAには、本人と異動先部署の意志が合致すれば部署異動できる「シェイクハンズ制度」や、全体工数の数十パーセントを他部署の業務に割ける「クロスジョブ制度」などの制度があるため、それらも上手く活用しながらメンバーのアサインを進めます。

 

もちろん、場合によっては採用活動を行う場合もあります。社内外問わず目的のために必要な人材に声をかけているんです。

 

 

・サービスの成長のためにメンバー自身が成長していく

小田：新メンバーをチームに招き入れたら、プロダクトの仮説検証に影響しない、腰を据えて開発できる機能やツールから担当してもらいます。そこからプロダクトやシステムの理解を深めてもらい、徐々に仮説検証に必要な機能を任せていくイメージです。

 

手取り足取り教えるのではなく、まずはメンバーに考えてもらい、その都度、結果に対してフィードバックするように心がけています。自分で考えて、得ることのできた結果を考察する。これを繰り返すことで成長し、自然と自信につながると考えているからです。

 

メンバーが成長すれば、相乗効果でチーム全体の力もつき、プロダクトの成長に直接つながります。

 

田坂：僕はSI事業部に参画したとき、小田さんに育成してもらいました。その際にも、挑戦の機会を積極的に与えてくれて。「もし失敗しても、僕が骨を拾う！」くらいの感じでやらせてくれました。だからこそ、成長できたのかなと思います。


何より大切なのは「企画やサービスが好き」というマインド

小田：最後に話しておきたいのは、SI事業部はすごく「企画やサービスを考えることが好きなエンジニアが多い」ということです。ガチガチに技術寄りのエンジニアというよりは、新しいサービスのアイデアを考えたり、作ったりすることが好き。私自身もそうです。

 

実は、事業部にいる半数以上のエンジニアが、会社の業務以外にもプライベートな時間を活用してサービスを開発しています。

 

田坂：だから、業務外の開発で培った知見を会社での開発に持ち込んで、良い相乗効果が生まれることが多々あります。メンバーが色々なことに興味を持って、自発的に動いているからこそ、SI事業部の開発がうまくいっている部分はあるかもしれません。

 

小田：だから、私たちの部署では決まりごとも少ないです。必要なことは自分たちで考え、決めていく。

 

田坂：「何時に出社してください」とか「タスク管理は絶対にこうしよう」というのもない。個人の裁量に任せています。メンバー同士に信頼関係があって、各メンバーが自分の力で判断しているからこそ、業務がスピーディーに回っているんだと思います。

 

小田：確かに、それは大きいですね。スモールチームでプロジェクトを回すからこその良さでもありますし、1人ひとりのエンジニアの裁量が大きいからこその楽しさだと思います。

 

 

まとめ

シードフェーズの心得：目的のために最小コストで動く

・最低限の人数で”阿吽の呼吸”を実現

・MVPは極限までミニマムに

・あくまでも技術は手段

 

アーリーフェーズの心得：目的のために“必要な分だけ”改善する

・仮説検証では、目的と検証可能性を常に考えておく

・サーバ増強やコード改善は「達成したい目標」をベースに決める

 

グロースフェーズの心得：目的に適うチームを作る

・「目指しているKPIに必要なチーム構成は何か？」を考える

・サービスの成長のためにメンバー自身が成長していく

 

DeNAでは一緒に働く仲間を募集しています

DeNA　キャリア採用

 

執筆：中薗昴　編集：榮田佳織　撮影：鈴木智哉