こんにちは、TOWNの岩崎です。

グループウェア「Aipo.com」のメンバーとして開発・運用全般を担当しています。

そんな僕が今年の2月から5月までの間、エンジニアとして新規サービスとなるCONELY（https://conely.co）の開発に携わりました。

新規サービスの開発に携わることで見えた、既存サービスの開発と新規サービスの開発は全く異なるということ、そして今の時代、新規サービスの開発にはとにかくスピードが求められるということ、そのためになにを”やらないか”という決断が大切になること、を書かせていただこうと思います。よろしくお願いします。

CONELYとは？

https://conely.co（現在はティザーサイトとなっています。ぜひFacebookで事前登録してみてください。）

インフォグラフィックを用いたリファラルリクルーティングサービスになります。

売上やユーザー数など、サービスの成長をインフォグラフィックで表示できるところ、またそのインフォグラフィックをチームのメンバーがFacebookにシェアすることで、それを見て興味を持った友達がシェアした本人と直接メッセージのやりとりをして詳しい話を聞けるのが特長になっています。

言葉で説明するよりも見てもらったほうが早いですね。こんな感じのページができあがります。
https://conely.co/companies/3/pages/6/25

リファラルリクルーティングの難しいところは、いかに社員を巻き込むか、というところだと思います。「全員が採用担当者」と声高にとなえても、社員にそういった意識を持ってもらうのが難しく、採用担当者だけが動いているのが実情という所も多いのではないでしょうか。また、応募する側にとっては、気になる会社があってちょっと話を聞いてみたいと思っても、その連絡の窓口が採用担当者となるとどうしても身構えてしまいますよね。

CONELYでは最初に連絡する相手が採用担当者ではなくチームのメンバーとなり、Facebook上でつながりのある関係のため、まずは気軽に話を聞くことができるようになっています。

TOWNは現在、3つのチームに分かれてサービスの開発をしています。いずれのチームも、やりたいことはたくさんあるけれどメンバーが足りない状況が続いています。なんとか新しいメンバーを迎え入れたいという思いから、TOWNに興味を持ってもらえる友達に対してアプローチをするためにCONELYがうまれました。

試行錯誤を繰り返した104日間

赤裸々な話をしますと、サービスの核となるアイディアの見直しや開発体制の変更など、今の形になるまで紆余曲折がありました。生みの苦しみを皆さんと共有できれば幸いです。

エイプリルフールのネタサイトとしてスタート!?

そもそものはじまりは2月9日。当初はいくつかの質問に答えることでチームのメンバーや個人の特性を分析し、その診断結果のグラフをシェアするように考えていました。シェアする診断結果のページに採用ページへのリンクを張っておくことで、チームの診断結果に興味を持った人がそこから応募できる流れになっていました。

今から5年ほど前、TOWNが制作した「大人の仕事脳診断」がFacebook上ではやりましたが、これを採用コンテンツとして使うようなイメージです。（「大人の仕事脳診断」の開発秘話はぜひ「1ヶ月半で30万いいねを得たアプリの開発ストーリー」をご覧ください。）

デザインをWantedlyのようにすることでネタっぽくしてバズるよう、エイプリルフールの4月1日にリリースするのを目標としてスタートしました。

この際採用したのは、React と Firebase Realtime Database の組み合わせでした。最新の技術を使うことで、そういった技術にアンテナを張っている人がTOWNに興味を持ってもらうという点を踏まえてこの技術を採用しました。TOWNとして初のSPAとなる予定でした。

ただ、ネタサイトとしてやるにはサービスのアイディアとしてもったいない（事業としてより継続的なものにしたい）という思いがあり、エイプリルフールのリリースは一旦ペンディングされます。

スタートアップサイエンスのステップを一歩ずつ

サービスの事業計画を練り直し、チームも再編成して3月31日に改めてスタートとなりました。全体の進め方についても見直し、「スタートアップサイエンス」のステップを愚直に実行しました。

リーンキャンバスの作成はもちろんカスタマーインタビューも行い、細かくフェーズ分けをして進めていきました。それらの情報はGoogle Spreadsheetを使ってチームのメンバーに共有されていきました。

僕も最初にこのスライドを読んだときには「やることが多いなあ」と正直思いましたが、グロースするサービスというのはこういうところが考えられているために受け入れられるのだと思います。

新しいサービスを立ち上げる際には、チームのメンバーにも目を通してもらうのがいいと思います。スライドの量は正直多いです。ただ1日あれば読み切れます。そしてこれを読むことでリーダーはこういう思想で進めているのだ、と理解することができるようになると思います。

エンジニアとしては「早くコードを書かせてくれ」という気持ちがどうしても出てきてしまうものです。ただ、どういったターゲットに向けてそのサービスを作っていくのか、そのサービスのコアとなる部分はどこなのか、ということを意識した上で開発を行っていかないとサービスのゴールは達成できません。

TOWNではチームごとにデザイン・開発・サポート・経理といった運用業務を完結させる体制になっており、さらに各チームの売上を全員が確認できる状態となっているため、すべてのメンバーがサービスの成長について考えるというマインドがあります。そういった下地があったこともよかったのではないかと思います。

Reactを捨てる決断をした

4月12日、私達は大きな決断をしました。React で作られたコードをすべて捨て、CakePHP 3 で最初から作り直すことにしました。SPA未経験の私たちにとって React と Firebase で０から作ることは学習コストが高すぎました。

React ベースで開発を行っていた際には React の学習に多くの時間を割いており、開発スピードを最重要視する、という面で見ると問題がありました。

新規サービスの立ち上げ時にはサービスのピポットが頻繁に発生します。学習コストが高い言語やフレームワークだと、ピポットのスピードについていけなくなり、一度作ったものを捨てるという決断がしづらくなります。

元々 WordPress のプラグイン開発など PHP 開発に強いメンバーが多かっため、今までの知識・経験を活用でき比較的習得までの時間が短い CakePHP での開発にピポットすることを決断しました。

最近の PHP 界隈では Laravel の勢いがあり、現時点において CakePHP を選択することは古くない？と思われる方もいるかもしれませんが、日本語ドキュメントが充実しており、機能が成熟しているという点からCakePHP を選択しました。新規サービス立ち上げ時には新しいフレームワークの勉強で時間を潰している暇はありません。

なお React のコードは捨てましたが、その際に得た知見は Aipo.com のスマホアプリ開発に存分に生かされています。

そして主要機能の開発が一段落した5月24日、CONELYの開発メンバーから離脱し、Aipo.comの開発チームに戻りました。

私達が大切にしたこと

いちばん大切なのはスピード。これに尽きます。

なぜスピードが大事かについては、メルカリさんの2014年のスライドが羅針盤となりました。

開発に求められるスピード

新規サービスの立ち上げにはサービスの判断スピードについていける開発が重要になってきます。

2時間で作った CRUD を翌日に全部捨てるという事がたびたびありました。次の日言うことが違っているという事もよくあります。エンジニアにとって仕様の変更は受け入れがたいというのが一般的かと思いますが、すでにスタートアップサイエンスを読んでいたので、サービスをより良い方向に進めるための判断として受け入れることができました。

何を作るのかが重要であり、もっとも重要なものに絞って開発する必要があります。そのため、それ以外のものは切り捨てる覚悟が必要です。

言語やフレームワークは手段であって学習することが目的ではないので、チームのメンバーがサービスの判断スピードについていけるものを選択することが大事です。3日かけて作ったものを捨てるのは勇気がいりますが、2時間で作ったものを捨てるのは未練なくできます。また、今回の経験を通して多くの時間をかけて作ったものは資産にも負債にもなりうると感じました。

必要なものしか開発しないという以外に開発において”やらなかったこと”といえば、必要以上のフレームワークの勉強です。例えば CakePHP にはファイル操作を簡単にするクラスが用意されています。しかし、このクラスを使わなくても素の PHP の関数を使って同じことが実現できれば実装が早い方を選んでいます。

サーバー構築に求められるスピード

サーバーを構成する際においても時間をかけないということが重要視されました。

開発環境では Docker を採用しました。Docker を利用することでホストOSの環境に依存しない環境を整えることが可能になります。また、php-Apache, MySQL の公式コンテナを利用することで構築を簡略化しました。

テスト環境では EC2 のインスタンス1台に nginx, php-fpm, MySQL の環境を構築しました。それぞれのミドルウェアのバージョンは Amazon Linux 上で yum install できるバージョンを採用しました。デプロイの流れも簡略化するため、テスト環境では EC2 インスタンスにログインし git pull でデプロイを行なっています。

およそ半日で上記環境を構築することができました。

サーバー構築においても”やらなかったこと”が重要になります。

AWS でのサービス運用の経験が増えていくと、ELB や RDS を使った冗長化構成、CodeDeploy や BeansTalk, CloudFormation などによるデプロイといった今までの経験を全て詰め込んだサーバー構成にしたいという思いがどうしても強くなります。しかしながら新規サービスでは果たしてどの程度ヒットするかという予測がつきません。最初のうちはスケールアウトではなくスケールアップで対応する、という割り切りを行いました。

まとめ

既存サービスのグロースと新規サービスの立ち上げは全くの別物であると感じました。一度サービスをリリースすると、そのメンテナンスや機能改修などを行い継続的にサービスを成長させていくことがほとんどで、新規サービスを続々とリリースするというのはそこまで多くないのではないかと思います。

既存サービスの開発に長く携わっていると新しいサービスを作るときも最初からパーフェクトを求めてしまいがちで、そのトレードオフとしてスピードが殺されてしまうため注意が必要だと感じました。

CONELYを通して新たにサービスを立ち上げる土壌が整ったことで、今後もさらなるサービスを世の中に出していきたいと考えています。

TOWNでは、CONELYだけでなく新たなサービスの開発、Aipo.comのサービスの成長に携わるエンジニアを随時募集しています。フロントエンドからサーバーサイド、インフラまわりまで幅広く経験できる環境です。興味がある方はぜひ一度オフィスに話を聞きに来てください。