最近お腹のたるみが気になってきたので、社内有志でチームを組んで体脂肪率を下げるバトルが始まりました。負けたら焼き肉を奢らないといけないのでけっこう真面目にやって腹筋が割れるくらいになってきたことに喜んでます。
さて、今回はestie advent calendar 23日目ということで、estieの開発でユニークな「副業の業務委託メンバーが多い環境」をテーマにお伝えしようと思います。
実を言うと、私自身も昨年1月に業務委託として関わり始めたのがestie参画のきっかけです。最近では、副業・兼業が可能な会社も増え、お金を稼ぐためだけでなく成長の機会として副業をしている方の話をよく聞くようになりました。
estieも業務委託の仕組みを活用しているのですが、正社員メンバーだけでなく、参画していただいている業務委託の方々もタレント揃いで、相乗効果で毎日チームとして強くなっています。
今回は特にエンジニアに絞って、
-
なぜestieは業務委託の仕組みを採用しているの？
-
業務委託を含めたどういうチーム体制で開発をしてきたの？
-
業務委託から転職するの実際どうなの？
という質問に、内部で起こった「戦争」にも触れつつ、お答えできたらと思います。
なぜ業務委託の仕組みを採用しているの？
estieには様々なタイプの業務委託メンバーがいますが、大きく分類すると以下のようになります。
-
(1) フリーランスで、基本的にフルタイムで開発業務を行う
-
(2) 本業をこなしながら、副業として平日夜や土日など本業がない時間に開発業務を行う
estieは、(1) のようなフリーランスとして現在3人の方が働いています。estieに主軸をおいて仕事をしている方々で、スクラムイベントに参加するなど、部分的にみればほとんど社員と変わらない働き方をしています。
一方で、estieでは (2) の副業メンバーが15人程度と多く、様々な場面で活躍していただいています。本業ではYahooやCyber Agentなどの上場企業から、スタートアップ企業も含めると様々な企業に勤めていらっしゃいます。稼働量も月・個人によってバラバラです。リモートワークが多い現状では、本業で日中に時間に都合がつく方も多く柔軟な働き方をされています。
業務委託をestieで採用しているのは (i) シンプルに開発を手伝ってもらうため、 (ii) 新しい知見をチームに取り入れてプロダクトを改善するため、 (iii) 採用につながる人材プールを確保するため、などが大きな理由です。業務委託の人数が多いことには賛否両論あるかと思いますが、最近はスタートアップでカルチャーのマッチングを見るためなどに活用されていると頻繁に聞くようになりました。そのあたりは、実体験も含めて後ほど説明します。
業務委託を含むチーム開発
混乱の多い最初期
フルタイムメンバーのみで構成されたチームと異なり、時間に制約のあるメンバーも多いため、様々な課題が出てきます。
例えば、開発の中心が副業メンバーだった時期には、ミーティングは日中に設定しにくいために、夕方や夜、創業当初は休日を活用していました。私が副業で手伝い始めた頃には、土曜のミーティングがなくなって業務委託メンバーも含めて喜んでいました笑
また、副業メンバーの開発・QAプロセスが整備されていなかったために、それぞれが作った変更がコンフリクトしてバグを生み、しかもその実装をした人は直す時間が取れないということで、プロダクトマネージャーが見様見真似でコードを直すというようなことも起こっていました。当初「検証環境はバグがある前提です」と言われたのはかなりカルチャーショックでした…笑
業務委託をしていた目線でいうと、参画当初はオンボーディング資料も整っておらず、「全体像が見えない」と思いながら仕事をしていました。その結果、「とりあえず言われたものを作ったけど使われなかった」という失敗を実際に経験しています。
振り分け方が見え始める
このような失敗を経て、少しずつチームの形やプロセスが整備されていきます。例えば、ユーザに継続的に機能が提供されるウェブアプリは、基本的にフルタイムメンバーのみでチームを構成し、同期的に開発できる体制に寄せています。これは、業界に食い込んで価値を提供していくVertical SaaSのプロダクトをつくるためには、ドメイン知識をどんどん獲得し、顧客のフィードバックを直接受けられることが重要で、プロダクトマネージャーと同期的に開発するほうが良いものが作れるからです。
では、時間に制約があるメンバーがどこで活躍しているかというと、以下のようなケースがあります。
-
新規プロダクトの立ち上げ
-
新規プロダクトは初期であるほど必要とされる前提知識が少なく、プロフェッショナルとして入っていただいて、将来を見据えた設計をしながらも、立ち上げを高速におこなうことができています。
-
-
ウェブアプリにデータを届けるデータパイプライン
-
estieは複数のデータソースからオフィスの募集情報を集めてウェブアプリに届けるデータパイプラインを構築していますが、届けるデータのインターフェースさえ整えればタスクをお願いしやすいです。また、データパイプラインには決まったフレームワークがないため、様々な人の知識や経験を取り入れてより良いものを作っていくことが競合優位性につながっています。
-
-
インフラや情シスなどの基盤整備
-
基盤整備は業界によらず他社の知見が使えるところが多いことが参画していただきやすい理由です。
-
いずれも結局は開発・運用をしていくのは社員となるので、それぞれに社員メンバーをアサインし、タスクの割り振りも含めたマネジメントを任せています。一方で、月30時間程度は業務委託の方に稼働していただかないとお互いの期待を満足できない部分があるというのが肌感です。
自律したチームを構成（きのこ・たけのこ戦争）
業務委託メンバーが増えてくると、マネジメントコストや、コードレビュー・QAが社員に集中してボトルネックになることが課題として現れてきました。
そこで、思い切って業務委託のメンバーのマネジメントを業務委託メンバーに依頼することを行ったのが2021年前期です。このときはチームでブレインストーミングをしながら取り組むべき課題をグループ分けし、チームを2つに分けてそれらの課題に取り組むような体制を作り、各チームにコードレビュー等をおまかせする「リード」を設置しました。チームを2つに分けたのは (A) 扱うタスクが減ったほうが1回のミーティングでの議論の時間が減ってリードの人も楽なことと、(B) 一方のチームが行っている良い取り組みを他方のチームに反映できるなどが理由です。
ちなみにチームを分けるときは、興味のあるタスクを持つチームをメンバーに選んでもらった後に、チーム名を募る大喜利議論を行って「きのこ」「たけのこ」の2つにすることが決まり、どちらが「きのこ」「たけのこ」を取るのかを争いました（なぜか興味のあるタスクときのこの山・たけのこの里のどちらが好みかの相関がありそうな分かれ方になっていたのでそれはすんなり決まりました）。
これには以下の効果がありました。
-
メンバーが自分でやりたいタスクを選ぶので自発的な開発につながる
-
業務委託に限らず、個人がやりたいことと会社がやってほしいことのオーバーラップを大きく取ることがパフォーマンスを出すことにつながると考えています。
-
-
マネジメントコストが低くなり、コードレビュー等もリードが中心に行ってくれるのでボトルネックが減る
-
QAも「自分たちでやるもの」という形を形成できました。
-
-
チーム間で「あっちが頑張っているならこっちも頑張ろう」という良い競争が起きた
-
チーム合同ミーティングでは「自慢大会」という形で進捗報告を行っていました。これがいわゆる「きのこ・たけのこ戦争」です。
-
-
リードの当事者意識が上がることで転職につながりやすい
-
自社では経験できないマネジメントも体験していただけるので、キャリアパスを考える参考にしていただいています。また転職後に働くイメージがもてるのでミスマッチも少ないです。
-
一方で、ユーザの声をうまく共有しないと事業につながらないものができてしまうなどの課題もあり、プロダクトマネージャーがKPI設定をして全社と擦り合うようにするなどの対応をしながら、業務委託が多い現在の体制をうまく回す方法を模索しています。
業務委託からの転職って実際どうなの？
さて、ここまでは企業側目線で内容を書いていましたが、業務委託の立場からみると以下のように需要とマッチしています。
-
(i) シンプルに開発を手伝ってもらうため → 業務を通して新しい業界や技術に触れ、自分の知見を広げたい
-
(ii) 新しい知見をチームに取り入れてプロダクトを改善するため → 自分の持つ技術を活用して報酬を得たい
-
(iii) 採用につながる人材プールとするため → 転職も視野に入れてお互いの見極めをしたい
昨年1月に私が参画したときは (i) のつもりで副業として働きはじめました。きのこ・たけのこ戦争の前からestieは職種に縛られない働き方を良しとしてくれていて、勝手にエンジニアリングマネジャーを始めたり、プロダクトマネージャーを始めたりと「業務委託なのにいいのかな？」と思うようなことにもチャレンジさせてくれたことが、「この会社でインパクトを出せそう」という実感につながったことは (iii) にシフトする要因として大きかったです。参画当時は大企業にいて「今の会社にはまだ数年いれるな」と思っていましたが、「今の会社に3年いるより、この会社に3年いるほうが成長につながりそう」と思えました。
少人数のスタートアップであればあるほど、カルチャーフィットするかどうかや、一緒に働くのはどのような人たちかが重要になってくるので、実際に働いてみる経験ができる副業は個人と企業双方に良い仕組みです。また、関わる社員・一緒に働く業務委託の方々からも学ぶことが多いですし、「あの人もここ手伝っているんだ」というのは良い企業のサインかなと思っています。これは正社員になっても思うことです。
一方で、見極めをする場合は、お互いにそのつもりで期限を切らないと、ずるずると契約が長引いてしまって、お互いにとって不幸な結果になってしまうこともあります。「なにを期待しているか」という期待値のすり合わせは積極的に行うように心がけています。
まとめ
estieは創業期から様々な方に関わっていただいてプロダクト開発を行っていますが、今回は赤裸々に過去の失敗も踏まえた業務委託を含むチーム構築方法などについて書かせていただきました。
業務委託を通して社員になっていただける方も増えているのですが、これは途中でも述べた「個人がやりたいことと会社がやってほしいことのオーバーラップを大きく取る」ような楽しいことができる機会や、面白い人と働ける場所を提供できているからではないかと思っています。業務委託・社員に関わらず、コミットしてくれるメンバーに大きく裁量を与えてまかせてくれるestieのやり方は個人的には気に入っています。
これからも工夫を重ね、1年後にはさらに大きく成長するチームになっていきます。事業内容や開発メンバーなど興味を持たれた方はぜひお話しましょう！
