こんにちは、DRIPの五十嵐です。
DRIPはDrecom Invention Projectの略称で、ドリコムのミッションである『発明を産み続ける』ためのチームです。
いわゆる新規事業部です。

はじめに

10年ほど前からドリコムの主力事業はゲーム事業で、それゆえにOH部門を抜くと97%はゲーム事業に関わっています。※

じゃあ残りの3%は何をしているかというと、次の収益の柱を創るための新規事業開発に勤しんでいます。

本記事ではそんな3%側の視点から、ドリコム流の『新規プロジェクト立ち上げからサービスリリースまでの流れ』について、ご紹介出来ればと思います。

※広告事業もゲームタイトルを取り扱っているため、本記事ではゲーム事業として記載していますが、組織上は別事業部として独立しています。そして%は概算です。

チーム環境

本記事の執筆時で、DRIPチームは業務委託/アルバイトの方を含めて13名です。

職種の内訳としては、以下の通りです。

エンジニア:10名
デザイナー:1名
プランナー:2名

人数はサービスの数やフェーズによって多少前後しますが、基本的に10名程度のチーム構成です。
※もっと増やしたい気持ちはあり!

現在は主に2つのサービス開発を進めており、それぞれにエンジニアリーダーがいて、そのもとで開発を進めています。

新規での開発となるため、技術選定などはエンジニアリーダーとメンバーで相談をして決めていくスタイルです。
※比較的自由に攻め気味の技術選定をできるのはありがたいところです。

直近リリースしたサービスはWebアプリケーションサービスだったので、新しい技術領域への挑戦として、フロントエンドでは React + TypeScript を選択しました。

さらに ESLint (with TypeScript) + prettier でコーディングルールをサポート、Storybook による見た目のカタログ運用、Jest + enzyme によるテスト環境を導入しています。

新規プロジェクトスタートまでの流れ

ドリコムでは、『週1で新規事業を提案する場』を用意しています。

正確には『投資するべきものを役員陣が判断する会議(投資会議)』があり、そこで新規事業の提案ができる、という仕組みです。

投資会議で承認されたら予算がついてプロジェクトスタート、という運びになります。

その会議への提案までのハードルはたったの1つ。

提案内容が本部長からの承認を得られている事

これだけなので、誰でも提案できる仕組みになっています。

とはいえ、実際にいろんな人が毎週のようにバシバシと提案しているかというと、そういうわけではなく、新規事業の企画提案は、四半期に数件あるかどうか程度なのが実態です。

やはり日々の業務をしながら本部長承認が得られるような企画を作り上げるのは難しく、ある程度仕組み化しないといけないなぁーと。

そんな中、既存事業のおかげで、DRIPは新規事業を考える専任のチームとして存在しているため、提案までの企画検討段階に100%フルコミットで時間を使えています。

では、具体的にどんなフローで企画検討をし、投資会議への提案まで持っていっているかを紹介したいと思います。

企画検討段階の流れ

当たり前といえば当たり前ですが、基本的には全くの0の状態から企画検討は始まります。

0から何かを考えるのは難しいので、そのために世の中には色んな手法やフレームワーク、ナレッジがあるかと思います。

・Lean Startup
・Service Design
・Vision Driven
・Break the Bias
・Business Produce
・意味のイノベーション
・新しい現実とのギャップ
・未来予測からの逆算
・不の解消
・HMW などなど…

※勝手に名付けたものや、意味が内包している言葉も同列に並べてしまっていますがそこはご愛嬌という事で。

じゃあDRIPはどうやっているかというと、カッコよくいうと上記のナレッジを活用しながら、担当者の熱量が高い領域 × マーケットトレンドに即した領域から企画を検討する、という手法を取っています。

それぞれ解説します。

担当者の熱量が高い領域

なぜこれを重視するかというと、DRIPの過去の失敗例として、担当者が起案したプロジェクトではなく実は業務的なものだった場合、いわゆる『悲しみの谷』で撤退判断をしがち、という事がありました。

※悲しみの谷とは、Y Combinatorが発表しているスタートアップが通る道の事です。分かりやすく解説している素晴らしい記事があるので詳細はこちらで。
https://link.medium.com/NRvNsG9fHY

会社としても、悲しみの谷にある事業に対して、目の前の数値だけを見るとスケールしなさそうだし、その分を次の新規に予算振りした方が可能性高そうだし、撤退判断は合理的で正しい!となりがちかなと。

そしてそれは担当者も業務的にやっている場合、左脳で考えてそう判断しがちなのですが、担当者の根源的欲求や使命感から本来その事業でなし得たかった世界があった場合、何とか会社に対しても交渉をし、もしくはピボットを繰り返してでも実現できるまで粘れるはずだ、と。

そしてその先にこそ約束の地があるはずだ、と。

そうしたチームとしての経験を元に、担当者の熱量が高い領域である事は重視しています。

マーケット・トレンドに即した領域

これも失敗経験から来ている側面もありますが、どちらかというと弊社代表内藤の得意領域だから、という側面の方が強いかもしれません。

どういう事かというと、そもそもDRIPは内藤直下のチームとなっています。

そのため、内藤が持っている情報量や分析観点得意領域に多大に影響を受けます。

内藤の下で働くようになって分かった内藤の凄いところは、山や谷を何度も乗り越えたゆえの無想転生的な人間力だなと個人的には思っていますが(私なんかが偉そうですが…)、ビジネス面ではトレンドへの嗅覚が非常に鋭い点だと感じています。

トレンドへの嗅覚というと、一見ミーハーに見えるわけですがそうではなく(多分)、

トレンドを表面的に受け取るわけではなく、ユーザー調査や有識者へのインタビュー、多領域の先端情報からくる未来予測、過去の経験則からの類推などを含め、トレンドを要素分解し本質だけを抜き取り再構築する能力が非常に高い、という事だと感じています。

言い換えるとビジョナリーな人物ですが、反面、ディティールは…😇

何はともあれ、マーケットトレンドに即した領域を攻めるという事は、競合が多いというデメリットもありますが、トレンドの本質を掴む事でトレンドの追い風を事業的に得られるため、利の方が大きいと考えています。

それゆえにマーケットトレンドに即した領域を狙う事を重視しています。

とまあ、それっぽい事をいっていますが、単純にチームにいるメンバー的に新しいもの好きが多いからついトレンドに乗りたくなっちゃう、という側面もありますが。

具体的な企画検討方法

熱量 × トレンドで領域を決めた後はどうするかというと、前述したフレームワークなどを活用して、リサーチを進めます。

リサーチ方法や手法については、コンセント社さんの記事が非常に分かりやすくまとまっていましたのでリンクだけ貼っておきます。
https://www.concentinc.jp/design_research/2018/02/sdtools/

DRIPでは、ユーザーインタビューや業界の人へのインタビューをする事が多いです。
※リサーチは基本的にプランナーが行っています。

リサーチの結果、得られた内容をチームで共有し仮説をチームで出していきます。

仮説を出し、コンセプトやワイヤーなどを描いて、それを元に改めてリサーチして…
このサイクルを事業化の可能性が見るまで何度か繰り返していきます。

上記の流れである程度企画が詰まってきたら、前述した投資会議で提案をして、承認されれば開発の予算がおりて、晴れてプロジェクト化です。

ちなみにDRIPチームの特徴の1つですが、エンジニアもデザイナーも積極的にサービス企画に参加するため、そういうところから関わりたい!という人にはすごくオススメです。

開発のフェーズにもよりますが、実装/作業時間以外に週1日程度は上記の活動や技術調査、ブレストなどに時間を取られるので、逆にいうと、そういうのが嫌な人には向かないかもです。

プロジェクトスタートからリリースまでの流れ

企画が決まった、予算が取れた、さあ作るぞ!

という事でプロジェクトがスタートするわけですが、DRIPはどう開発進めているかというと、チケット駆動 × なんちゃってスクラムな感じです。

深ぼった話をすると長くなるので大枠だけ紹介します。

開発着手前段階

▼UI/UX
1. プランナーが、チームと相談をしながらワイヤーを作って共有する
2. デザイナーが、ワイヤーを元にデザインを起こして共有する
3. デザイナーが、チームや仮想ユーザーからのフィードバックを元にブラッシュアップする
※使用ツール:Sketch、XD、invision、Zeplinなど

▼技術選定
1. エンジニアが、チームと相談をしながら技術要件を整理する
2. エンジニアが、技術要件を元に新規技術調査をする
3. エンジニアリーダーが、最終的なアーキテクチャを決定する
4. エンジニアが、開発環境の整備をする
※使用ツール:GitLab、GitLab CI、Docker、Swagger、Storybook など

▼プロジェクト管理
1. プランナーが、要件ベースでチケットを洗い出す(スクラムでいうストーリー的なもの)
2. エンジニアリーダーが、実装観点ベースでチケットを洗い出す
3. プランナーが、チームと相談をしながらスケジュールの確認をする
※使用ツール:Trello、JIRA、ホワイトボード(物理)、Google Driveなど

上記領域を同時進行させ、スムーズに開発ができる下準備をします。

開発中の段階

毎日の朝会と週1の定例とKPTを基本として、それ以外で何か相談事があればその場で会話して無駄なMTGは極力減らしています。

相談があればパッと集まって、パッと会話して、すぐ解決させるスタイルにしています。

定例で今週やる事を決めて、チケットごとに担当をつけて駆動して、朝会で進捗を共有して、後は作業時間としています。

その他のDRIPチームの特徴として、雑談は多めです。

普段から雑談をしている事で、仕事上のコミュニケーションも円滑に。という意味もある、はずです。きっと。

開発の終盤段階

チーム内だけではできない領域、例えばQAとか法務確認などは、社内の他部署からヘルプをしてもらっています。

プロジェクト内容によっては他社さんと一緒にやる場合もあるため、リリースに向けての最終的な調整を行う場合もあります。

リリース時期が調整でき、関係各所との連携が取れたら、ラストワンマイル。優先度をつけながらギリギリまでブラッシュアップしていきます。

そしてリリースへ…

最後に

ドリコム流の『新規プロジェクト立ち上げからサービスリリースまでの流れ』を説明してきましたが、おぼろげにでもイメージを持って頂けましたでしょうか。

スタートアップではなく、主力事業がある企業内で別ドメインで新規事業をやっている側の話は、なかなかネット上にはなく、ご興味ある方に少しでもお役に立てたのであれば幸いです。

そして今更ですが、なぜこんな事を説明していたのかというと、

DRIPでは新しい仲間を探している

からです!

新しい事をやりたい、という時にスタートアップを選ぶという選択肢もあるかと思いますが、本記事を読んで『企業内新規事業部でやる』という選択肢が気になって少し話を聞いてみたい、と思って頂けたら嬉しい限りです。

DRIPには私含め前職でスタートアップでの新規事業創出を経験したメンバーも多いので、もしお会いする機会が頂けましたら、スタートアップと比較した企業内新規事業部で新規をやるメリットやデメリットなどをフラットにお伝えできるかと思います。何事も良し悪しがありますよね。

詳しい募集要項はこちらの内容をご確認ください。

募集要項

最後までお読み頂きまして誠にありがとうございました。