エンジニア14名体制のスタートアップ、カウシェでの開発チームの編成

はじめに

カウシェの技術領域の執行役員のikeです。
カジュアル面談をしていて以下のような質問等をいただくことがあります。

• いま何人くらいエンジニアいるんですか？
• どんな開発チームがあって、どのように開発してますか？
• 意外と人数少ないんですね〜
• …

そこでこの記事では直近の開発チームの編成について書きます！
具体的には以下を書きます！

• チーム編成とその意図
• 編成のときに最近考慮すること
• 過去の編成

エンジニア十数名体制のスタートアップでどのような編成を取っているのか、近いフェーズの方々の参考になったり、逆に参考になる意見をいただけたら良いなと思っています。

プロダクトフェーズ

具体編成の前に、プロダクトとそのフェーズも前提として重要かと思い記載します。

• 「日常に楽しさを」を掲げたtoCど真ん中のソーシャルコマースサービス
  • toCプロダクトはiOS/Androidのネイティブアプリで提供
  • toBプロダクトはWeb Frontendで提供
  • toB: 商品出品してくださる事業者向けの管理画面
• 2020/09にサービスローンチし、4年以上運用中
• 直近1年の大きめ出来事は以下
  • 2023後半：大規模なピボットを実施
  • 2024前半：ピボット後の方向性が見え始める。累計DL数200万を突破
  • 2024後半：ピボット後の方向性がさらに見え始め、検証したい施策等が以前以上に増加

特徴的なのは「ここの体験を強めていけば更に良い体験にできるかも？」というポイントがみえつつも、「大きな仮説を爆速で確認していきたい！！」という類の開発が、4年経過したにも関わらずまだまだ非常に多い、ということです。

開発チームの編成

その中で今月2024/12からは以下のような編成で開発を行っています。以下は週4以上で働いているフルタイムメンバーのみを記載しています。週3以下のメンバーも、以下以外で4〜5人ほどいます。

編成時の考慮ポイント

ありがちな話も多いですが以下です！

人数

日々の活動を共にする開発チームの人数は、なるべく少人数にしています。
「なるべく少人数＝できれば4-6名」なイメージです。

一般的に言われてる適正人数よりもやや少ないとも思いますが、そのくらいの人数が今の状況だとより理想だと感じています。

それより多くても開発自体はうまく進行できるが、施策のヒット率まで含めてうまく進行するには、なるべく少人数で高密度コミュニケーションしやすい状態の方が、今の状況だと望ましいと考えています。

それは前述したように、検証したい施策が特に多く、また方針変更も多く、探索がより重要な状況だからだと思います。

現実的には理想よりも多い人数にならざるを得ないことも多いです。なのでベストエフォートにはなります。ただ、なにか迷ったら小さくなる構成のほうを選ぶようにしています。

チーム特性と個人特性

チーム特性と個人特性を考慮して、組み合わせを様々検討しています。
多くの会社で同様のことを考えていると思いますが、我々の場合だと具体このようなイメージです。

• エンタメ領域は直近特にスピードが重要で、「何としてでも出していく！」というシーンが特に多いだろうから、それに燃えるであろう性格の人を寄せてみよう。また次クォーターのこの領域はMobile開発が少なめだから、バックエンド中心にしよう
• EC領域は他チームとの連携が多くなるし、段取り力やハブ力があったり、守備範囲が常に広めなマインドの人を寄せよう
• 事業者向け管理画面は要件がとにかく奥深い。要件定義力が強かったり、ドメインを理解したり言語化したりが特にできてしまう人を寄せよう
• 全体見渡してそれぞれのチームの中の人たちが、組み合わせ変えることでさらに良いチーム状態になりえないか、微調整しよう
• …

人数がまだ少ないこともあり、組み合わせを洗い出してできる限り最適化される編成を検討しています。

スキル完結性

1チームでスキル完結しなくても良しとしています。

スクラムなどでは「作業に必要なすべてのスキルや専門知識をチームが備える構成」というのがチームの基本単位として重視されていると思います。

一方で我々の場合、1チームで必ずしも完結しない編成、完全な独立性がない編成でも良し、としています。

例えばQA、Designerは一部のチームにしかいないです。チーム内完結しない他の例としては、エンタメ領域の施策の優先度が全体として高いものが多いから、一部タスクを他チームにお願いして進行する、などもあります。

「チームに全てのスキルが保持されており、独立性が高い」よりも「チームの人数は少なくしてチーム内コミュニケーション密度を高めやすい状態にしつつ、ほどほどの独立性がある」というのを直近は重視しています。

チーム内で完結しない部分は、他チームに依頼したり必要に応じて調整を行ったりしており、そのようなコミュニケーションのオーバーヘッドは許容する、としています。

ただこのとき、オーバーヘッドが増えてもあまり影響ない部分は今だとどこなのか、オーバーヘッドを誰に担ってもらうのが今だと良いのか、を考えるのは重要だと感じています。例えば以下のようなイメージです。

• 最近、BackendやMobileがボトルネックになりがち。一方でQAやDesigneは空きがち。QA、Designer、PdM間でやりとり増やしてもらおう
• エンジニア増えてPdMがボトルネックになってきた。エンジニアの誰かに、今までPdMがやってくれていたことを一部明示的にやってもらおう
• …

編成の変更頻度

変えたほうが良さそうであればどんどん変えています。

一般的にはチームの生存期間は長い方が良いと言われていると思います（チームとして機能するようになるまで時間がかかるため）。

が、我々の場合だと、今だと少なくともクォーターごとには何かしら変えているし、クォーター内でさらに変えてしまうことも多いです。事業としてフォーカスしたい領域がスピーディーに変わったり、人が入って状況が変わったりがあるため、都度変えています。

それよるデメリットや悪影響はどのようなものがあるか？でいうと、今だと、とはいえ変えてしまうメリットのほうがかなり大きいと考えています。

というのも、そもそもプロダクト組織全体がまだ小さく、お互いよく知っていたり、もしくは知りやすくもある状態です。ゆえに一般的に言われているよりも変更のデメリットが少なめで、気にせず変えてしまったほうが良い状況が多いのだと考えています。

過去の編成

たった3ヶ月前ですが、2024/09くらいまでは以下の状態でした。このときは人数が今よりもかなり少なかったです（今が全体で19名なので、全体で7人も少なく、エンジニアは5人も少なかった）。このときのカジュアル面談では「意外とエンジニアが少ないすね」という感想を度々いただいた記憶が…。

しかし新規加入者が来てくださり、9月から4人増え、2024/10には以下のような2チーム体制になりました。カウシェ本体チームの人数が多いですが、新規加入者が多くオンボーディングなどもあったため意図的に許容した編成でした。

そして11末にはオンボーディングも概ね進み、さらに追加の新規加入者も現れました。そして事業状況も鑑みて、今月からは記事冒頭で記載した以下の3チーム編成になりました。

まとめ

いかがだったでしょうか。次回以降で以下のような記事もかければなと考えてます！

• 正社員・業務委託比率どうなっているの？
• EM何人いるの？
• 何歳くらいの人が多いの？
• 開発系の会議どんなのあるの？
• 施策ってどうやって決まるの？
• 採用どんな体制ですすめているの？
• …