アーリーステージにおけるスタートアップの変遷

2017-02-12 22:41
2017-02-12 22:41

今週はスタートアップのステージ変革に伴って起こったチームの変化について書こうかなと思います。自分自身の振り返りという意味合いも含むので、あまり役立つ情報になるかはわかりません。私がエンジニアなので、エンジニア目線で書かれていることはご了承いただければと思います。

現在、弊社はシリーズAを終えて少したったという時期ですので、シード投資〜シリーズAあたりの変遷を書きたいと思います。

ちなみに会社の基本スペックは

  • ドイツ・ベルリンを拠点
  • 30名前後(私を含む2名が外国人)
  • ドイツ、その他隣国(スイスなど)向けのヘルステックサービスを展開

シード投資期前半

私がジョインした頃はまだ7人くらいの規模感で、これからどんどん成長していこうという段階でした。この時期は、プロダクトに関しては「クオリティーがギリギリ許される範囲でなるだけ早くリリースする」というのが、チームの合意としてありました。

理由としては、マーケットフィットが見えてきたので、

  • 早くマーケットを抑えたい
  • 類似サービスが出てきても大丈夫なように、先行者優位を確立してしまいたい
  • キャッシュが尽きる前に走り抜けたい(次の投資を受けられるよう成長したい)

というようなところですね。
ということで、エンジニアサイドとしては、この時期は

  • なるはやで実装は行う
  • テストを書くことは最低限するし、ビジネスサイドに理解してもらう

この2つを大きな軸として開発していました。

仕事の仕方としては、全員がプロダクトの関係者という感じで、基本的にビジネスサイドはファウンダー陣を中心に、大枠で必要な要素を決め、CTOを含めて工数を話し合い、チケットに落として実装していくという流れでした。話し合いはケースバイケースで参加者が変わっていく感じですね。バグは見つけ次第ささっと直してリリース。まさにスピード勝負。

具体的な管理方法を書くと、

  • Asanaでビジネスサイドが大枠の要件を出す
  • Github issuesにそれらを落とし込んで優先順位順に実装
  • MTGは全体で週に1度。けっこう細かく各人が今何をしているかをシェア

シード期後半

ビジネスが進むに連れて、仕様も複雑になってきます。それに伴ってチケット管理が厳しくなりだし、さらにはビジネスサイドとエンジニアサイドに隔たりが生まれてきました。この時期は一番難しかったですね。ビジネス側はこれも必要、あれも必要と言い出す。とはいえ期日は守って、早く作ってという要求。エンジニアサイドは過大な要求から本質を絞っていかに実装内容を少なくしていくかのせめぎあい。

特にうちの会社で難しかったのは、開発陣は全員(CTOと私の二人)が外国人。しかしサービスのユーザーはドイツ人でステークホルダーも基本的にドイツ人なので、すべてがドイツ語で進んでいき、どんどんビジネスサイドと離れていく。こうした言語的要因とリソース的要因によって壁がどんどんできていきました。

この時期の管理方法は、

  • GithubのMileStoneでスプリントを管理
  • 一度FixしたMileStoneには新しいチケットは付け加えない
  • とはいえ、緊急で何かを直して欲しいという要求は都度来る
  • 徐々に週一でのMTGがなくなっていく

後にCTOが離職するのですが、この時のビジネスサイドとのねじれが原因でした。開発の2人以外にITをわかっている人間がいない、特にビジネスをひっぱるファウンダーの2人がその辺を全くわかっていないというのが大きな原因だったように思います。私は基本的に謎な要求をされても笑って無視して必要な部分だけを抽出して開発するように心がけてそういう部分には対処していたのですが、彼はその辺が我慢ならず、よく衝突していました。

これはもうファウンダーに技術職の人間がいない時点である種宿命なので、割り切るしか無いと思っていたのですが、実際の所どうなのでしょう。確かにもっとコミュニケーションを取って技術に対する理解を持ってもらってというようなプロセスを踏めばいくらかマシだったかもしれませんが、本当にこの時期のスタートアップはめまぐるしく状況が変わり、仕事があふれているので、あまりそういう余裕が無かったように思います。逆に自分がファウンダーの立場の時に、その辺をトップからもっと無理やり相互理解の時間を持つようにしたほうが良いなと思っています。

この時期の最後くらいに、会社はさらに大きなオフィスに移動し、IT部門はITだけの部屋を持てたことで、ビジネスサイドとのノイズを完全にシャットアウトするに至りました。これは非常に仕事効率アップには繋がったのですが、日毎にビジネスサイドの下請け会社のような立ち位置になっていき、なんとかすべてを一度リオーガナイズしないといけないなと感じていました。今思うと完全にウォーターフォール型の組織になっていっていたのですが、中にいるとそのあたりの感度が非常に鈍っていたなと言うのが反省点です。客観視する姿勢を常に持っていなければいけません。

シリーズA前半期

まさに現在進行形です。CTOが辞め、新しく入ってきたブラジル人CTOが新たに組織をオーガナイズしようと動き始めました。また、私も前述の通り、もう一度組織運営を考え直したいと思っていたので、2人でかなり大掛かりなテコ入れを行いました。彼は非常にスタートアップの経験が豊富で、かなり良い人選だったように思います。彼がジョインしたことには多分に運が良かった面はありましたが。
まず私たちが行った主な変更点は下記のとおりです。

  • プロジェクト毎に、プロジェクトチームを都度立ち上げること
  • プロジェクトチームをIT部門の部屋に全員集めてそこで仕事をすること
  • ITの納期に関してはITの人間しか発言権を持たないこと(安易にビジネスの人間が「これは小さな変更だから」というのは禁止)
  • User Story Mappingという本に書かれたことを実践し、スプリントを回す
  • 上記に関し、スプリントマネージャーを置き、すべての要求は彼に集約され、彼がどのスプリントに入れるか考える
  • よって、開発陣へのプライベートメッセージによる追加開発のお願いは禁止
  • ドイツ語禁止(ドイツ語で話し合われたことを英語で2重で話し合うのは時間の無駄という理由。いつでも議論に途中参加できるように)

基本的な思想としては、プロジェクトは最終ITなので、ITを中心として開発しましょう、可視化することを大切にしましょう、ということを大事にしています。Githubでのチケット、MileStone管理も辞め、ボードに付箋を貼っています。スプリントは毎週月曜にチームメンバーで実現すべきユーザーストーリーを話し合い、その後開発陣でタスクわけしていくという形です。2週間に一度、大枠での振り返りを行い改善点を洗い出し、誰がその改善点の克服に責任を持つかというところまで決めます。

まだ完全に全てが上手くいってるわけではもちろんありませんが、いくつかの面で非常に良い効果が出始めています。また、少なくともプロジェクトチームのメンバーがこれを成功させようと良い風が吹いているように思います。


簡単に振り返りをまとめると、プロダクトにしても、もう少し小さな単位となるプロジェクトにしても、上位概念から順に組み立てていき、「端的に言うとどうなることがゴールなのか」というところを明確に軸としながら進めていくことが重要。この辺、エンジニアは最下層概念となるタスクとなる部分まで理解できるので、実は全体を理解して動くのは一番容易いと思っています。これを全体理解とするためにどうチームを動かしていくかがポイントではないでしょうか。

そして、組織の柔軟性。フェーズが変わるに伴って仕事の仕方、組織の動き方などが変わってくるのを当たり前と捉えて、その中での最適解を常にチーム一丸となって探すという姿勢。まさにこれがスタートアップの醍醐味のひとつでもあると思います。

ちょっと振り返りで締め方が難しくなってしまったのですが、こんな感じです。

*ITと呼んでいるのは、日本で言う技術開発部とかR&Dと読み替えていただければ。

このエントリーをはてなブックマークに追加