CTO視点で振り返るクラシルの作り方【2000万DL突破】
こんにちは。クラシルを運営する、dely CTOの大竹です。Twitterは@EntreGulssでやってます。
dely Advent Calendar 2019、最後の記事です。前回はコマース事業部エンジニアの小川くんが「~OSSから学ぶ~ MVCフレームワークの保守性がモリモリ上がるクラス設計」という記事を書きましたのでそちらも是非。」という記事を書きましたのでそちらも是非。
はじめに
今月(2019年12月)、クラシルのアプリ累計DL数が2000万を突破しました。リリースから3年半での達成は、国内のC向けアプリでは最速クラスなのではと思います。
私は、2014年のdely設立の頃からCTOになり、クラシルをリリースした2016年から現在までの過程の全てに関わってきました。
この記事では、リリースから3年半で2000万DLを達成したクラシルの作り方を、"CTO視点"で振り返って書いていこうと思います。
フェーズによってCTOとしてやるべきことは変わっていきます。それぞれの時期の課題とそれをどう解決したか、参考になれば嬉しいです。
アプリリリース前（コンテンツをひたすら改善）
クラシルが順調に立ち上がったのは、実はリリース前のやり方が正しかったからだと思っています。クラシルのアプリをリリースしたのは2016年5月ですが、その前の1月〜4月の間はとにかくレシピ動画のコンテンツ自体のPDCAを回して改善を繰り返しました。
コンテンツに需要があることを確認してから、自社媒体としてのアプリを作るという順番です。プロダクトを作る前にコンテンツをユーザーに当てて検証を先に済ませる、非常にリーンな立ち上げ方だったと思います。
初期は当時持っていたFacebookページにレシピ動画をアップロードし、いいね数やシェア数をKPIにして動画のクオリティを上げていきました。最初の動画は今見ると笑ってしまうくらい低クオリティなんですが、カメラの使い方、ライトの当てから、動画編集ソフトの使い方、シーンカットのコツを一つ一つ学んでいって見やすいレシピ動画にしていきました。
このPDCAサイクルをひたすら回した結果、少しずつファンが付いていき、5月には月間1億再生を突破しました。
この段階で、ようやくアプリをリリースしました。SNS上で配信するだけだとコンテンツがフローで流れていってしまうので、ストックされる自社媒体を持ちたいと考えたからです。結果的には、クラシルはレシピ動画アプリとして圧倒的に認知を拡大していくことになります。
アプリをとにかく最速でリリース（1人開発）
レシピ動画のコンテンツに確実に需要があることの検証を終えて、いよいよアプリの開発に取り掛かります。
レシピ動画の最大の強みはひと目見ただけで価値が伝わる分かりやすさなので、その良さをシンプルに活かしてアプリを作りました。起動していきなり動画が再生されるUIを採用したのは、レシピ動画アプリにとって、それが一番のオンボーディングになると考えたからです。起動して5秒で使い方が理解できるシンプルさを意識しました。
当時、delyにはエンジニアが私１人しかいませんでした。当然、iOSアプリ実装、UIデザイン、サーバーサイドのAPI開発、インフラ構築、動画配信の基盤構築まで全て自分でやることになります。
意識したことは、
・とにかく競合よりも1日でも早くリリースすること
・後任への引き継ぎやすさを考えて技術選定は絶対にミスらないこと
・一旦は属人性が高くなっても気にしないこと
これらの要素です。とにかく頑張りました。
結果的に、4月頭に開発しはじめて、5月18日に無事リリースできました。
基礎機能を追加開発、複数人での開発体制を整備
リリース時のバージョン1.0は、恥ずかしくらいミニマムな状態だったので、使いやすいアプリにするために必須であろう基礎機能を追加していきました。具体的には、キーワード検索、お気に入り保存、関連動画の表示などを機能追加していきました。
逆に言えば、それすらもない状態でミニマムリリースしたということです。リード・ホフマンの「製品の最初のバージョンで恥ずかしい思いをしていないなら、リリースが遅すぎだ」という言葉はまさに真理だと思います。当時のクラシルはとにかく競合よりも早くリリースするという命題があったので、その制約が良い方向に作用したと思います。
これくらいの時期に、自分以外ではじめてのエンジニア社員として奥原が入社しました。１人での開発体制はリスクでしかないと思っていたので、早急に複数人開発ができる体制を整えていきました。とは言え、この時期はまだ自分もコードを書き続けているような状態です。
テレビCMのトラフィック対策
成長するスタートアップが必ずぶち当たる壁として「テレビCM対策で徹夜でインフラ構築した」という"あるある"があります。例に漏れず、クラシルも2017年にその状態に陥ります。
2016年末に5億円、2017年3月に30億円を調達したdelyは、その年の4月からテレビCMを大規模に打つということを決めて急速に準備を進めていました。当時のインフラは非常に脆弱で、冗長化ができていなかったり、単一障害点が存在したりなど、一気にトラフィックが来たらサーバーダウンしてもおかしくない状態でした。当たり前のことですが、しっかり開発工数を割いてインフラを強くしたのがこの時期です。
ちなみに、今この壁にぶち当たっている現在進行系のスタートアップの方に伝えたい注意点が２つあります。クラシルもこの罠にハマりました。
①「意外に、テレビCMよりも番組内で特集された時にサーバーは落ちる」
=> サーバーが落ちるかどうかは最大瞬間風速に依存するので、CMよりも番組でガッツリ特集されるときが危険。
②「テレビを見た人は検索してWebにランディングするので、アプリよりもWebのインスタンスを増やしておくべき」
=> 特にアプリメインのサービスを運営してると忘れがちですが、テレビを見ていきなりAppStoreからアプリをダウンロードする人はいません。必ず検索してまずWebにランディングします。
※クラシルが一番サーバーダウンしかけたのは、テレビCMよりもテレビ番組で特集されたときのピークトラフィックでした。
独自のデータ分析基盤を構築
クラシルをリリースしてから、「圧倒的にグロースさせるために何が必要なのか？」を考え始めました。当時で言うと、メルカリやGunosyのようなC向けサービスで急成長したところは初期に何に注力しているかを学び、それをクラシルにも取り入れたいと考えました。
こういうことは、素直に先輩に教えてもらうのが一番良いと思います。私の場合は、当時GunosyでCTO、今はDMMでCTOをされている松本さんに連絡をして、クラシルがやるべきことのアドバイスを頂きました。
「データを細かく見ながらプロダクト作りしないと長期で勝てない」
「しっかりデータを分析して改善を回せる基盤とその体制を作るべき」
このアドバイスに基づいて、クラシルでもリリースした直後からデータ分析基盤の構築にリソースを割いてきました。GAやFirebaseで事足りることもありますが、かゆいところに手が届く分析をするには自前でログスキーマを設計し、収集・蓄積する基盤を作る必要があります。
具体的には、Swift/Javaで書いたログ生成ライブラリをアプリに組み込んでJSON文字列を生成し、それをログ用エンドポイントにPOSTで投げて、最終的にS3とBigQueryに蓄積される流れを作りました。
また、ログを集めるだけで活かせないと意味がないので、勉強会などで開発チームにデータの分析やグロースハックの基礎知識をインストールし、データドリブンで開発できるチーム作りにも力を入れました。
Facebookのマーク・ザッカーバーグも、インタビューの中でデータ分析やABテストの基盤を構築する重要性を語っています。社内では「Airlock」と呼ばれているようです。※以下の動画の9:36あたり
実際に、クラシルの開発チームでデータ分析基盤に投資する重要性について共通認識を作るために、この動画を見て参考にしていました。
大人数開発の開発体制作り
クラシルリリースから1年くらいが経つと、徐々に開発チームの人数も増えて組織化が必要になってくるフェーズになりました。自分自身がプロダクションレベルでコードを書くことは2017年末頃でほぼ無くして、開発体制作りに注力しました。
具体的には、スクラム開発の要素を取り入れて、スプリントサイクルの概念を導入したり、バックログでタスクを管理、定例の振り返り会を設けるなど組織開発において当たり前のことを当たり前にできる体制を整えました。これらを導入したことで、開発工数の見積もり精度が向上し、安定的な開発ができる仕組みが整いました。
また、開発チームの心理的安全性を高めるために、定期的な1on1や、時にはノーアジェンダで直近の悩みを話し時間を設けました。実際やってみると、「実はこういう技術的負債が溜まっていて開発効率が落ちててつらいんですよね...」みたいな話が早期にキャッチアップできるメリットもありました。
組織開発のフェーズになってくると、「技術的負債に光を当てる仕組み」が非常に重要になってきます。特に技術者以外では気づきにくいことではあるので、CTOとして長期的な開発スピードとの兼ね合いで負債解消にリソースを当てる意思決定も重要になってくると思います。
※この時期に、「CTO of the year 2017」を受賞させていただきました。
デザインの視点を強化
技術的負債はエンジニアであれば気づきやすいと思いますが、意外に気づきにくいのが「デザイン的負債」です。10年前にリリースされたアプリを使って「なんか使いにくいな」と感じることがあると思いますが、そのアプリにはデザイン的負債が溜まっています。
具体的には、
・継ぎ足しで更新してきたUIデザインガイドの整合性が取れていない
・単発の施策で取りあえず入れたデザイン変更が残り続ける
・デバイスサイズが大きくなっている等、環境変化に対応できていないUI
などが挙げられます。
開発チームはずっとそのアプリを見ているから慣れていますが、ユーザーは初見でそのアプリを見て使いやすさを判断します。常にユーザーの視点で使いやすくなっているか判断するためにも、デザイン的負債という概念を持つのは効果的です。※詳細は以下のスライドを参照。
また、組織開発をするフェーズでもう一点重要なのが「プロトタイピングのステップを挟む」ことです。
機能をただ実装することだけを開発チームのゴールにしてしまうと、ユーザービリティの検証ができていないままの機能がリリースされる可能性があります。実際にアプリに組み込んだときに本当に使いやすいのかどうかをチェックするフローが必要であり、プロトタイピングはそのために実施します。
プロトタイピングには、紙に鉛筆で書くペーパープロトタイピングから、実際に捨てる前提のコードを書いて実機レベルで検証する方法までパターンがあります。プロトタイピングが実機にどれくらい近いかを「Fidelity (忠実度)」と呼びます。※詳細は以下のスライドを参照。
作ったプロトタイプを持って、ユーザーインタビューに出向きます。社内でやることもありますが、バイアスを極力減らすために基本は社外の方にインタビューに答えてもらうようにしました。ユーザーリクルーティングは、Twitterでbosyuを使ったり、メルマガで呼びかける形でアポを取り、自分であらゆる場所まで出向いてインタビューを実施しました。
ちなみに、2018年はデザイナーの採用を強化するため、開発チームで取り組んだ内容を上記のようなスライドにまとめて、積極的にデザイン系イベントで登壇する回数を増やしました。CTOという職務からは離れてしまいますが、開発チームを強化するという目的に沿って、デザイン界隈での露出を増やすようにしていました。
※この時期に、THE GUILDの深津さんやGo Andoさん、後にCXOとしてdelyに入社する坪田さんと知り合いました。
CXOとして坪田さんがジョイン
社員数が100人、開発チームも数十名規模に拡大した段階で、「全社を横断的に見てユーザー視点を一貫させる人が必要」という課題感を持つようになりました。結果的にそれがCXOというポジションであると分かりました。
「これってブランド的にどう？」
「ユーザー視点で見てこの機能は使いやすい？」
このような議論が起こる頻度が増える一方で、誰が最終意思決定をするんだっけというのが曖昧でした。CXOという役割をしっかり構えることで、その問題を解決することを目指しました。
深津さんがnoteのCXOになった以降から、業界の認識がガラリと変わったと思います。例えば、noteの健全な成長を作るための枠組みを作った記事を読みましたが、まさにこういう役割がクラシルにも必要だと感じました。
以下の記事のように、サービスの「グランドデザイン」が重要です。
このような背景があった上で、では誰にCXOとして来てほしいのかを考えました。CXOには大きな権限が集約されるので、本当に日本でトップofトップの方に来てほしいと想像した時に、坪田さんが頭に浮かびました。
※詳しくは以下の記事を参照。
※この手書きオファーレターの効果もあったかもしれません。
非連続な成長のための開発ロードマップ
坪田さんがCXOとしてジョインしたことで、既に多くの変化が開発チームや全社的に起こっています。
人が増えたことで組織の中に潜在的に存在する「壁」を突破するために、
・コミュニケーションの透明化
・役割の明確化
・リソース不足解消のため採用活動強化
など多岐にわたります。※詳細は以下の記事を参照。
その中でも特に重要なのが、「非連続な成長をするための長期の開発ロードマップを作り、透明性高く運用すること」です。
クラシルはレシピ動画というジャンルで急成長はしているものの、その枠組みだけにとどまらず領域を拡大していく戦略を持っています。ECもその中の大きな一つです。
つまり、足元のグロース施策を回しつつ、長期の戦略の実現のための思い開発も並行して動かす必要があります。そのために長期の開発ロードマップが必要になるのです。
今現在、大きな仕込みがいくつか動いています。2020年には来たるべきときにお見せできると思います。
自分としては、EC事業にフォーカス
今年の1月に少しバズったんですが、私個人としては開発チームのマネジメント等の業務は坪田さんを始めとするメンバーに一任し、クラシルのEC事業の立ち上げにフォーカスしています。※詳細は以下の記事を参照。
この記事の本題と逸れるので詳しくは書きませんが、こちらも仕込んでいるので、来たるべき時にお見せしたいと思います。
まとめ
長くなってしまいましたが、リリースから3年半で2000万DLを達成したクラシルの作り方をまとめました。
サービスを伸ばすためには、自身の開発スキルを高めるだけでは片手落ちで、全体のアーキテクチャ設計、組織の体制作り、良いプロダクトを作るために欠けてる視点があれば新たに学習し、必要あれば優秀な人が外部から来てもらうことが必要だと思います。
自分用のメモとしても整理になりましたが、同じような境遇の方に参考になればと思います。
最後に
私が担当するコマース事業部、坪田さんが担当する開発チーム、どちらも非常に面白いフェーズです。
クラシルやdelyに興味持っていただいたら、ぜひご連絡をお待ちしてます。エンジニア、PdM、デザイナー、BizDevなど全方位で募集してます。
TwitterのDM開放してるので、DMでの連絡も歓迎です！
この記事が気に入ったらサポートをしてみませんか？