スタートアップでの働き方とは！？新卒エンジニアとしてスタートアップの最前線で働く選択肢

こんにちは、Wantedly でソフトウェアエンジニアをしている南です。自分は昨年の4月から Wantedly に新卒エンジニアとして入社し、スカウト機能の開発・グロース、ユーザー向け機能開発・グロース、新規サービス開発などに取り組んできました。

最近だと、今年の4月半ばにリリースしたポートフォリオサイト Case の開発を行ったり、2日前にリニューアルした Wantedly Tools の開発に携わったりしています。

さて、突然ですが、皆さんは「スタートアップで働く」という言葉に対して、どういったイメージを持つでしょうか？

なんとなく「大変そう」みたいなイメージはあるものの、具体的にどういった働き方をしているかはあまりイメージがつかないのではないでしょうか？

「スタートアップ働く」で検索してみると以下のように幾つか記事はヒットするものの、多くは創業者や経営者、または第三者の冷静な視点で語られており、新卒の一人のエンジニアとして「スタートアップでの働き方」に言及することはなかなか無いように思います。

スタートアップが失敗する確率は93%「僕らはゆっくり40年間働く代わりに、4年間限りなくハードに働く」

そのスタートアップで働くべきかを判断するためのチェックリスト

「あの頃はイケてないほうのベンチャーだった」グリー・青柳氏が入社1年目の思い出を語る

そこで今回は、自分の Wantedly での1年ちょっとの経験を振り返りながら、どういった働き方をしてきたか、また Wantedly が会社としてどういった取り組みをしているか、さらにWantedly のエンジニアに求められる役割とは何なのかという話をまとめてみたいと思います！

その上で、最後に「新卒エンジニアとしてスタートアップの最前線で働く選択肢」を評価してみたいと思います。

2015年4月新卒エンジニアとして Wantedly で働き始める

自分は昨年3月に大学院を卒業し、昨年4月から Wantedly でエンジニアとして働き始めました。「エンジニアとして成果を出すんだ」という思いがあった一方、長期インターンの経験なども無い自分が本当にエンジニアとして成果を出していけるかどうか、不安に感じていたのを覚えています（Wantedly は新卒・中途問わずインターンという形である程度一緒に働いてみて、お互いにやっていけそうかどうかを判断した上でジョインするというフローを取っています。特に今年の新卒エンジニアは皆長期インターンを経験していて、ギャップを感じる事なく入社しています。自分は研究漬けの毎日でインターンとして来れる日も少なかったので、入社時はドキドキしました）。

そんな自分が Wantedly に入社して最初に取り組んだのが、「スカウト」という「会社からユーザーへお誘いの声をかける」機能の開発及びグロースでした。「スカウト」の開発経緯は「会社へ話を聞きに行くという Wantedly が提供するコアな体験を、より多くのユーザーにも提供したい」というものでしたが、実際にリリース後はスカウト数やスカウト経由での「話を聞きに行く」数は伸び続けていて、Wantedly が提供する価値を拡大する事に成功しているのではないかと思ってます。

そのスカウトの開発や、さらにその後の様々な開発で自分が体験した「Wantedly 流の開発フロー」というのがどういうものだったか、どういう特徴があったのか、またそこで実感した「Wantedly におけるエンジニアのユニークな役割」がどんなものであるのか、ここで簡単にまとめてみたいと思います。

Wantedly 流開発フロー

Wantedly の開発チームは、チームにもよりますが大体エンジニア、デザイナー含めて 3~4 人くらいという規模感です。開発自体は、ざっくり言うと1週間ごとに「進捗の確認」と「次にやるタスクを決める」というサイクルを繰り返して進めていきます（iOS や Android のエンジニアが入ってくるともう少し増えますが、Web だけであればエンジニアは 1人 ~ 2人くらいです）。

ただ、Wantedly での開発の中でも、「初期リリースフェーズ」と「グロースフェーズ」で進め方に少し違いがあるので、次からはその2つを分けて説明してみます（尚、開発の進め方はチームごとに違っていて、以下はあくまで自分の Wantedly でのやり方です）。

初期リリースフェーズ

ここでは、ある程度まとまった時間（1か月 ~ 2か月）をかけて1つのプロダクトやサービスを作るという状況を、「初期リリースフェーズ」と呼ぶ事にします。「グロースフェーズ」との大きな違いは、まだリリースしていないため KPI を追いかけないこと、代わりに開発の進捗とプロダクトの完成度にエンジニアは責任を持つという事です。自分の経験では、以下の様なフローで進める事が多かったです。

1. エンジニア、デザイナーといった開発に携わる 3 ~ 4人のチームメンバーで集まって、どういった体験を作るか、その為にどういった機能が必要かを決めます。この時、コンセプトはすでに決まった状態です（スカウトの時は、話を聞きに行く人を増やすというのが達成したいゴールで、その為に直接メッセージをやり取りできるようにするというのがコンセプトでした。その体験を実現する為に必要な機能として、メッセージングの仕組みやユーザーを見つける仕組みが必要だと判断しました。）

2. デザイナーが、1で決めた実現したい体験の為にどういった機能をどういった見せ方で出すかを考え、Sketch の様なツールを使ってデザインとして絵にします。再びチームメンバーで集まって、デザインを見ながら足りない要素がないか（例えば通知など、その機能が無いことにって出来ない体験が生まれてないか）を洗い出します。そして、「この時点でのタスクリスト」を作ります。

3. デザイナーの人には足りない機能や、主要では無いが必要な画面などのデザインを引き続きやってもらいながら、この段階からエンジニアは開発を始めます。コアな価値を生み出すのに必要な要素かどうか、またタスクの依存性なども考えながら優先度を決め、順番に片っ端から消化していきます。フェーズ 1 〜フェーズ 3 に達するまでの間にかかる時間は、早くて数日、遅くて2週間くらいという感覚です（その為、エンジニアは別の project のタスクをフェーズ 3 に入るまではやり続けます。新規 project への移行の時期が、エンジニアはデザイナーよりも少し遅れるイメージです。また、Wantedly にいるデザイナーは 3 人でエンジニアよりも圧倒的に少ないので、基本掛け持ちしながらコミットする時期をずらして作業を進めてもらいます）

4. 後はひたすらリリースまで開発を行うのですが、その間も週に一度チームで集まって、進捗確認と出来上がった画面を見てのフィードバック、追加タスクの優先度付けします。また、開発中はデザイナーと密にコミュニケーションをとる様にして、お互いに作業がブロックしない様にします。

5. リリースが近いタイミングでは、実データを入れた状態での調整（例えば、表示するコンテンツを選ぶロジックの調整など）をしながら、どう印象が変わるか、より良い体験が作れるかを考えます。タスクの優先度と期限は決まってるので、最後は「どこまでタスクを消化して、どこまでプロダクトのクオリティが上げられるか」という観点での開発になります。

グロースフェーズ

一方、グロースフェーズでは、あらかじめ決めた KPI の達成状況を見ながら、適宜「次のアプローチを考えていく」事で開発を進めます。アプローチの候補はマーケティング要素の強い施策であったり、ユーザーの体験を大きく変える新機能開発であったりします。後述するように Wantedly は数字を重視し、数字でアプローチの成否を判断するので、「新機能開発」もアプローチの1つとしてフラットに判断する事になるのが個人的には面白い点だと思っています。グロースフェーズでは、大体以下のようなフローで開発を進めていきます。

1. 週に一度チームで集まって、今の KPI の達成率、現行タスクの進捗を見ながら、次のアプローチ（開発タスクやマーケ施策）を決めます。その際、「期待できるインパクトの大きさ」を考慮してアプローチの優先度を決めます。しばしば判断が難しいのは「長期的インパクトは大きいが短期的インパクトは小さいアプローチの優先度」ですが、これは適宜チームで議論して決めていきます。

2. 施策（新機能開発やマーケ施策）を行ったら、その効果を数字で評価します。KPI に影響しづらい施策であれば、他の細かい数字も見ながら、どういった影響があったかを確認します。数字で判断することで、「着実な改善」を積み重ねていきます。

このフローの中で興味深いのは「次のアプローチを決めるのはエンジニア自身」という部分です。これは Wantedly のエンジニアの特徴の1つだと思いますので、もう少し詳細に書きたいと思います。

Wantedly のエンジニアの責任範囲は広い

Wantedly のエンジニアの特徴を一言で表すと、「広く責任を持つ」という事が挙げられます。どういう事かといいますと、「決められたタスクを期限までに終わらせる事」だけではなくて、「何をやるのか、どの結果がどうなるか」まで含めてタスクに責任を持つという事です。

Wantedly の多くのチームでは、いわゆる「ディレクター」や「プロダクトマネージャー」はいません。代わりに、その役割を「エンジニア」が負っています。「何をやるかを自分で決める」自由を得るとともに、「やった結果」に対する責任も負うのです。

Wantedly ではまた、グロースフェーズの章でも記載したように数字を重視する習慣が根付いてます。チームごとにチームの KPI を設定しており、それとは別に個人の KPI も定めています。一人一人が数字に対して責任を持っている為、常にそれを達成する為のアプローチを考え続ける事になり、「予想されるインパクトの大きさ」をタスクの優先度として自然と捉えられるようになります。実際に施策や開発を行った際のインパクトの計測も数字で行い、本当に改善できているかを確認してフィードバックループを回し続けています。

多くのエンジニアと同様に、期限内にクオリティの高い機能やサービスをリリースすることも求められます。特に、KPI 達成の為に必要となる機能であれば、リリースの遅れはKPIの未達に繋がる為、期限を守ることへの強いインセンティブが働きます（大抵は KPI に対してその達成に必要な要素を分解して、「いつまでにどういった機能を作る」といった形で計画を立てるので、自分で立てたスケジュールを達成する為に自分が頑張ることになります）。「急いで作れと言われたから作る」のではなく、「自分がこの日までに必要だと考えたからこの日までに作る」といった形で主体的にタスクに取り組めるのも Wantedly で働くエンジニアの大きな特徴だと思います。

新卒エンジニアとしてスタートアップの最前線で働く選択肢を考えてみる

ここまでの Wantedly での働き方を踏まえて、「新卒エンジニアとしてこの働き方を選ぶべきかどうか」について考えてみたいと思います。

自分が常々感じているのは、Wantedly の開発フローや会社としての取り組みは、「最短距離で最大限の価値を生み出す」事に最適化されてるという事です。

チームのサイズを出来るだけ小さく保つ事でマネージングコストを減らし、また一人一人に数字目標を持たせる事で、皆が「最大のインパクトを生み出すにはどうしたら良いか」を考え実践する強いインセンティブを持っています。構造として、「価値を生む」事に集中できる環境が整えられているように思います。

また、チームの人数が少ない事で、必然的に一人が開発としてカバーする領域も広くなります。例えば、Wantedly の Web エンジニアでサーバーサイドやフロントエンドだけやるという人は一人もいません。全員が、どちらも出来て当たり前というスタンスを取っています。iOS や Android のエンジニアですら、必要であればサーバーサイドのコードを書いています。

こういった事実から、「価値を生み出す事に魅力を感じる」、「自分の責任で自分の行動を決めたい」、「限定された役割ではなく、広い役割で開発に関わりたい」といった考え方を持つ人にとっては、Wantedly の様なスタートアップで働くことはとても魅力的な選択肢になるのではないかと思います。

また、上記は「エンジニアとして働く選択肢」について述べたものですが、「新卒として働く」という観点に着目してみると、「少数チームで一人に広い役割と大きな責任を持たせる」というのも「スタートアップでない会社で新卒として働く場合」と比較して大きな違いになるのではないかと思います。新卒だからといって低クオリティのものを作って良い訳では無くて、他のエンジニアと同様に高いアウトプットが求められます。「考えること」と「手を動かすこと」の両方を高いレベルでこなしていく事が求められるため、考える力と実装力の両方が身につくように思います。

例えば、自分は学生時代は技術書を読み漁ったりしていたものの、Web サービスを作るという事はほとんどしていなかった為、DOM の API や CSS transitions など実用的な知識に欠けていました。Wantedly に入社して、否が応でも実践的な知識を求められ、身についたものは大きかったように思います。また、「細かく分割したシンプルで疎結合なコンポーネントからソフトウェアを構築すると、変化に強いシステムができる」といった書籍などで得ていた知識も、実際にエンジニア2人で自分が開発をリードしてある程度の規模感のプロダクトを作る経験をする事で、「実感を伴った知識」へと変わっていきました。

プロジェクトと開発の両方をリードするというのは、大変ではありますがすごく価値のある経験だったと思います。こういった経験ができるのも、「新卒でスタートアップで働く選択肢」を選んだからだと思っています。