創業から1年で29人がコミット！多くのエンジニアの力を借りて成長したスタートアップ戦略
株式会社キネカを創業してから1年が経った時にエンタメマッチングアプリpatoのgithubリポジトリを見直したところ、29人がコミットしていたことに気がつきました。
本当に多くの人たちに支えられて1年を乗り越えたんだなーと思いつつ、29人もの新しい仲間ができていたことに本当に感動したのを覚えています。
創業時からトッププライオリティは常に仲間集め
弊社では「全員人事」「事業づくりは仲間づくり」という言葉がよく聞こえてくるのですが、これは創業時から全く変わってません。常に仲間集めが第一優先で動く。
なので、多くの人に会うということを常に意識して、会った人全員が採用候補であり「キネカだったらどういうバリューを発揮してもらえるだろうか」ということを常に考えながら会話しています。
そうやって100人以上のエンジニアと会っていく中で、多くのエンジニアが「ベンチャーのスピード感を感じてみたい」「自分のプロダクトを持ちたい」「0→1の立ち上がりを経験してみたい」という思いを持っていることがわかりました。
放課後ベンチャー制度
そのような需要が把握できたために、キネカでは、週末や平日の就業後を使って一緒にプロダクト開発をやってくれるエンジニアの人を募集することにしました。ビズリーチの「草ベンチャー」に近いスタイルです。
創業期は当たり前ですが全く資金がないため、手弁当という条件ではあったものの、創業から3ヵ月で10人のjoinが決まり、ありがたいことに月を追うごとに増えていきました。結果として1年間で29人の放課後ベンチャーがアプリの開発に携わっていました。そのうち一人は正社員としてjoinしています。
創業から3ヶ月目に行った開発合宿。フルタイムメンバー３人と放課後ベンチャー6人。
創業当時から「エンタメマッチングアプリpato」の立ち上げをフルスロットルでやっていました。全く仕様の決まっていないプロダクトがMVPになる過程を一緒に作り上げ、ピボットやフルスクラッチでの作り直しを半年で3回書き直したりしてました。
実装はもちろんのこと、放課後ベンチャーのみなさんと一緒にモックアプリを触りまくってイシューを出す「お触り会」を開いたり、全員でプロダクトと向き合い意見を出し合ったりと、一丸となって放課後ベンチャーのみなさんとプロダクトを作り上げていったように感じています。
放課後ベンチャーを含めた開発運用スタイル
放課後ベンチャーは実装作業を強制しているのではなく、本業を最優先として、手が空いている時に自由にくる、というスタイルを取っています。
自由度を可能な限り高い状態で、並列で数十人の放課後ベンチャーのみなさんに対して、どのようにタスクを切り、振り分けていったのか。
一言でいうと「70%のデキでリリースすること」がその秘訣になります。そして、残りの30%を放課後ベンチャーのみなさんに割り振ること。
プロダクトレベルと開発スピードはトレードオフ
リーンな0→1の開発現場では当たり前ですが、100%達するまで実装する必要性は必ずしもありません。ユーザーにコアバリューが届く最低限のプロダクトレベルであれば良いのです。
最低限のプロダクトレベルの定義はプロダクトによりますが、このレベルを下げられるほど、開発スピードが高まりPDCAサイクルが高速に回せます。
バグを認識した上であえて修正しない
「70%のデキでリリースする」と書きましたが、70%でリリースするとは、バグを認知しながらも修正せずにリリースすることです。もしくは必ずしもデザイン通りに実装しないまま、スピード重視でリリースすることです。
スピードを出すために注意していたことをあげてみます。
- 実装中にすぐには答えが出ないような実装は、簡易的な別の実装に置き換える。
- 1pxにこだわらない。よく見ないとわからない違いは無視。
- 3step以上のフローがあるバグは無視。
- デザイナーとのコミュニケーションを減らし、認識のずれはクリティカルでない限り無視。
- テストにこだわらない。メインフローのみ動作チェックする。
上記のスタイルに沿って実装するとかなり実装スピードが変わってきます。当然ですがプロダクトの質も下がります。70%に達しないかな？と思う時もあるくらい。ですが、そのままリリースします。その実装の真偽を素早く確認するためです。
間違った施策であれば、上記を修正せずに引っ込めれば良いです。30%の開発が削減できたことになります。
正しい施策であることがわかった段階で、残りの30%を実装します。この実装を放課後ベンチャーのみなさんで対応してもらっていました。
リリース後の修正タスクは細分化しやすい
新しい機能の実装はサーバーとクライアントにまたがるため、多くの場合、週末や就業後だけでは着手が困難です。ですが、一旦リリースした機能の修正、30%の改善は一つ一つのタスクが細かくなりやすいです。
例えば、1pxのデザイン修正やバグの修正です。ほとんどのタスクがある程度のスキルがあれば30分以内で終わるほどの粒度になります。
短い時間でも着手が可能なため心理的なハードルも低く、タスク数を多く消費できるためにコミット感も生まれやすいです。さらに、作業可能な日のみで完結させやすいなど、多くの利点があります。
どんなに小さいリリースでも全員でハイタッチ
下記は4半期に一回ある合宿の様子です。合宿ではバグ潰しをみんなでやっていたのですが、どんなに小さいリリースでも全員で祝福します。
合宿では開発機能がリリースされるたびにみんなでハイタッチ＆謎のダンスをしていました笑キネカではエンジニア・開発力を特に大切にする文化があります。IT事業をPDCA回しながら急成長させていくためにはエンジニアが不可欠であり、開発力こそ肝だと考えています。その技術を持ったエンジニアを尊敬することを大事にしています。他にもエンジニアだけでなく、ビジネスサイドの人間も開発ができたり、プログラミングの経験があったりと、エンジニア・開発について強く理解しようとしています。そのおかげでチーム内で円滑なコミュニケーションができるようになっています。
普段も同じ雰囲気で、みんなでリリースを最大限喜ぶ文化が根付いているため、エンジニアはいち早くリリースがしたい！と、いつも思いながら開発しています。「世界変わった！最高！」ってチームのみんなが言ってくれるのがもう最高。リリースした瞬間は相乗効果で本当に楽しい。
特に最初の1年間を乗り越えられたのは多くの放課後ベンチャーのみなさんの協力があってこそです。本当にありがとうございます。
エモい。
引き続き、いつでもオフィスに遊びに来てください。飲み会とか！
放課後ベンチャーに興味あるよって方、とりあえず話だけ聞いてみたい、という方などなど、ちょっとでも気になったらTwitterやFacebookからDMください！
※弊社ではバグのことを「伸び代」と表現していますが、本記事では便宜上バグという言葉を使っています。「伸び代」って最高ですよね。バグはネガティブですが、伸び代と言い換えたらとてもポジティブに聞こえませんか？？
