この記事はこんな方におすすめです
- 副業採用の始め方を知りたい
- 副業の受け入れ側どのように整備したらいいの？
- 副業メンバーのオンボーディングどうしたらいいの？
- 副業で失敗しているのだけど、もう一度チャレンジしたいのだけど何から始めればいいの？
- 副業でのエンジニアやデザイナーの役割・マネジメントどうしているの？
- 副業人材へのタスクの分解が大変、誰がやっているの
- エンジニア、デザイナーとのコミュニケーションが難しい
- 契約周りどうやるか、誰が対応しているのか
- 勤怠管理どうしているのか（リモートワーク、時間orショット）
- コミュニケーションはどうしているの（Slack、オフラインの使い分け）
などのお悩みがある方にお伝えしたい内容です。
・副業を始めたい方：https://offers.jp/lp
・副業メンバーの採用をしたい方：https://offers.jp/client/lp
副業採用のポイントと始め方
「Offers」は、副業メンバーだけで開発しました。リリース時に「初めまして」の挨拶を開発メンバー同士で行い、全員と面識があるのはプロダクトオーナーの田中だけでしたが、どのような副業採用・開発をしてきたのかまとめています。
リファラル採用でスピードとスキルを担保
弊社Offersのプロダクト開発に携わる約7割のメンバーがリファラル
リファラル採用が多い理由
- お互いに信頼がベースにあり、コミュニケーション、作業、契約、納品など全体のフローにスピードがある
- 短い時間でも成果をあげられる
- 他の人から簡単にリファレンスが取れるので得意なことがわかる
という点で、リファラル採用を重視。
リファラル先はどういう企業か
- 弊社経営メンバーがサイバーエージェント、DeNA、メタップス出身なので該当企業
- 上記企業から卒業した方がメルカリ、メルペイ、Google、他ベンチャー企業に勤めており、一緒に働いていたことがある方など
「リファラル採用を効率的、積極的に行えるようにしたい」という経験の元、Offersにリファラル機能があります。
- リファラル・つながりが少ない方でも利用可能
- 採用担当者に副業メンバーでエンジニアやデザイナーとの繋がりがある方などを採用し、リファラル拡張
- 誰とどういう繋がりがあるのかを可視化（友人、友人の友人）
などを特徴とした機能。採用から事業・開発へのコミットスピードが早く、事業推進のスピードが格段に上がりました。
リファラル採用のポイント：成果物は見ておく方が吉
信頼がベースですが、エンジニア・デザイナーの成果物は見ましょう。リファラルが成功確率は高いですが、私たちも失敗ケースはあります。
この経験から、Offersのサービス内に「社内でディスカッションできるような機能」を設けています。
リファラル採用でも失敗したケース
- 連絡が取れなくなった
→ 久しぶりに連絡を取った方でリファラルだが関係値ができていなかったかも。
- 成果物を見ず、経歴だけで判断した結果、期待した成果をあげられなかった
→ 期待する結果＝稼働時間と当人のアウトプットの見積もりと成果が合わなかった
副業・フリーランスメンバーの管理・オンボーディングについて
Googleアカウントで全員が閲覧できるオンボーディングドキュメント。
14ページに渡って細かい設定やその理由などについて全部書かれています。
2020年2月現在だと目次はこのようになっています。
フレキシブル経営（雇用形態にとらわれない正社員・副業・フリーランスのメンバーでの経営）をする中で、秘伝のタレ的に継ぎ足されたり、削除されたりしています。
ポジション・個人の自己紹介
- 誰が
- 何をやっていて（仕事で関わっていること、特技）
- どういう人なのか（経歴、性格、好きなこと、趣味、特技）
をオンボーディングドキュメントで可視化しています。
ミラティブさんのオンボーディングのやり方をリスペクトし、notionに所定のフォーマットで入力するようになっています。
オンボーディングを行う・まとめておくメリット
- 誰だろう
- どういう背景で入社したんだろう
- どういうコミットメントになるんだろう
- 得意なことなんだろう
- どういうポジションなんだろう
という疑問が、横への興味がなくなってしまい・見えなくなってしまい、「良いコラボレーションが起きなくなってしまう問題」を引き起こす危険性があります。この問題がクリアになり、タスク・プロジェクトに入ってスムーズに成果を出してもらいやすいです。
弊社で利用しているnotionの権限もフルなので誰でも閲覧・追加・編集できます。
Slackに編集ログを飛ばして編集状態も可視化するようにしています。
プロダクト開発に関わる副業メンバーとフルメンバーの役割・稼働時間
プロダクトオーナーの私を含めて、プロダクト周りに関わる方をまとめるとこのようになります。
タスクベース、継続的にお願いしている方々、マーケティング周りでも一部お願いしている方、インターン生を含めると30名以上が関わっています。
役割・体制・関係性
- 私とCTO大谷が各ポジションのハブに
- 田中：マーケティング、カスタマーサクセス、セールス、デザイナー、プロダクト/プロジェクトマネジメント
- 大谷：インフラ、サーバー、フロント、データアナリスト、データサイエンティスト、デザイナー
- 各々のポジションのメンバー同士がコミュニケーション
- 紫色がフルタイムのメンバー、グレーが副業・フリーランスメンバー
- それ以外は副業、フリーランス、インターン生の体制
約32%がフルタイムで、68%は副業・フリーランスの方々
Offersのプロダクト開発周りに携わっている人の例でいうと約32%がフルタイムで、68%は副業・フリーランスの方々です。稼働時間についても個々のタスクや役割に応じてかなり細分化しております。
稼働時間の比率：40時間以下の稼働の方が54.5%、フルタイムは32%
個々の役割と稼働時間・タスク粒度のバランスを見ているのが主に私かCTOの大谷ですが、皆さんプロフェッショナルで自走していただけるので、やることは方向性とアウトプットの最終確認。
現在の開発周りの体制
- 大小粒度・新規/機能改善など差はありますが、現チーム月間で117の機能がリリース
- エンジニア
- フリーランスでジョインした3名のうち2名がフルタイムに（副業から転職へ）
- CTOを含むエンジニアフルタイム4名+フリーランス1名
- デザイナー
- フルタイム1名（元フリーランスで途中からフルタイム（副業から転職へ）
開発している内容範囲
- 企業さま向けサービス画面
- ユーザーさま向けサービス画面
- Offers magazineのメディアページ開発
- カスタマーサクセス用の管理画面
- セールスイネーブルメントに必要なCRM/MAツールとの連携実装
- マーケティング用の効率的な運用のための機能実装
- コーポレートサイト
- コーポレートPR用の資料やLPの作成
など、他にも事業を行っている関係で開発するものが多いですが、コアチームで開発を行なっています。
副業メンバーに依頼する仕事内容の事例
タスクベースの仕事
- 週○時間など細かいタスク化できそうな仕事
タスクベースの具体例
- 新サービス/新規事業における市場調査
- 新規機能開発
- アーキテクチャの設計やフィードバック
- 開発定例に参加し、ファシリテート
- データ分析基盤構築・毎週のデータ分析
- KGI/KPI設計
- ユーザーテスト構築と実施、UXの調査
- バナー・アイキャッチ、LPデザイン
- サイト、アプリ、サービスの仕様書作成
- ワイヤーフレーム・構成作成
- いわゆる技術顧問・外部CxO系業務も含む
- クライアント、ユーザー対応
など仕事の依頼内容は大きく分かれてきます。
タスクベースの副業ポイント
「緊急度は低いが、重要度が高いタスク」を通常の開発ライン・リソースとは別に並列でお願いするとリターンが大きいです。
プロジェクトベースの仕事
- 全体のタスクの工数が見積もりやすい仕事
- 1ヶ月〜数年に渡り細かいタスクが積み上がった仕事
プロジェクトベースの具体例
- 新規サービス/サイト/アプリの立ち上げ
- 要件定義、仕様策定、ワイヤーフレーム作成、ユーザーヒアリング・ユーザーインタビュー、デザイン、コーディング、フロントエンド 、サーバーサイド、インフラ、決済周りなどプロジェクト全体が長くなるもの
- devops
- コーポレート系ワークフロー改善 SaaS , iPaaSの連携など
コミットメントベース
- 社内の教育のフィードバック
- プルリクエストの確認
- 技術組織・採用・教育・評価制度構築での壁打ち
など、タスクともプロジェクトとも言えない、時間も読みにくいが、レバレッジがかかりやすい会社・組織全体に関わるものはコミットメントベースとして切り出して依頼する。
契約書・請求書作成/管理をスマートに
契約内容について
- 基本は稼働時間ごとの時給契約とする
- 主業との絡みや受け入れ時の確認時間などを考えると、毎月固定での稼働契約にするといずれ破綻する
- タスクを疎結合にして、マイクロタスクでも消化できるようにする
- 明確に成果物が決まっている場合のみ(機械学習モデル作成など)請負契約で
- 検証&FB -> 修正期間を含めての金額考えると準委任契約だと膨れる
- 元同僚などスキルや人物面よく知っている場合は、その後の継続も考えて準委任契約で
契約書作成の進め方
弊社では、freee api、クラウドサイン、独自請求書作成フォーム、Google App Script+スプレッドシートを駆使してほぼ全部の契約書・請求書作成を自動化しています。
2年間副業経営をする中で、多くの業務委託契約書を作成しなければならず、スタートアップながら毎月の作成・請求書が100を超えることも。その結果、誰でも簡単に作成・管理ができるようになりました。
- 弊社バックオフィスのインタビューはこちら
やり方について弊社鈴木のnoteを抜粋
https://note.com/suzukiyuto/n/nf38ed60fa49b
・リモートワーカーのアクションログから生産性を自動計算・スプレッドシートとチャットツールAPI連携でアラート機能
・売上とコストをリアルタイムに連動させた事業予測モデル
・バックオフィス機能を極限まで自動化（契約書、請求書などはslackで発行しクラウドサインAPIで締結、など）
などなど...
Google Formをご入力いただけましたら、他社の管理状態などについてまとめたアンケート調査を公開いたしますので、よろしくお願いいたします。
副業人材のマネジメントの3つのポイント
タスク分解がすべて
弊社では私かCTOの大谷が開発のマネジメントを行なっておりますが、副業人材に仕事を依頼するときの方法や例は上記している通りです。
タスクベースの仕事のポイント
自社の組織・リソース（人数、消化できるポイント）・プロダクトの性質・フェーズ・技術課題を疎結合にして、適切な権限委譲とモニタリングできる仕組みを用意しておく必要があります。
Offersでエンジニアの副業採用/事業でうまくいっている企業の例
弊社カスタマーサクセスでは、エンジニア採用がうまくいってる企業の組織の状態を定量評価しています。
掲載型の採用媒体の活用をするように、ジョブディスクリプションを作成して、当てはまりそうな人を採用していくという方法もあります。
しかし、人事に一括で任せるよりプロダクト開発に関わるPM・エンジニア・デザイナーチームで採用要件や進め方をある程度まとめておいて、採用実務周りでは人事・採用担当が主導する方がより成果があがりやすいです。
ただ、自社のエンジニア・デザイナー主導でオファーやメッセージを送ってくれればそのほうが早いことも。
COO/CTO/VPoE/CCO/CDOだけでなくPjM/PdM/ディレクター（現在or経験者）がマネジメントをしていくと「長期的に必要になりそうな重要な課題」も効率的に解決しやすい状況を作れますし、逆にこういう方々がコミットしていないと、良い方の副業採用は非常に難しいですね。
タスク管理
- 基本的に内部仕様は把握できてない前提で依頼し、結合部分は受け入れ側で巻き取るイメージで進める
- 実装する上で周辺理解が進み、そのまま組み込みまで任せられるケースもある
- サブタスク化
- タスク分解までできるタイプであれば、依頼者に任せる
- 分解できないタイプは、ToBeを元にこちらでサブタスクを切り出し、MTGして詰めていく
- サブタスク切り出し後には、担当者、作業完了日までを決定
- リモートでのやり取りが主になるため、多少面倒でも最初は週1 or 隔週で定例MTGを組む
- タスク上のやりとりは、JIRAコメントに一本化
- 言った言わない問題の回避
信頼をベースにマイクロマネジメントしない
弊社では主にリファラル採用でお互いの信頼関係をベースにマイクロマネジメントをしないようにしていました。
ただ、リファラル採用だけでは組織がスケールしないのとOffersのリリースに際して、CTO・デザイナーを交えて自社でOffersを利用してエンジニア・デザイナーの副業採用をしました。
仕事依頼の準備の期待値・アウトプットについて
- プロジェクトベースにし、プロジェクトが始まる前に成果物を明確にする
- 稼働時間と想定されるアウトプットを事前にすり合わせる
- まずAsIs, ToBeのみを伝え、自走できるかを判断
- 依頼するタスク以外のドメイン知識(周辺仕様や現構成など)も前提として共有 -> 作業契約締結前であれば、簡易的なNDAを結ぶ
- NDA締結後、JIRA, Notion, Githubなどを共有
- 開発環境整備時に、つまづきなどあればドキュメントとして記録してもらうように依頼する
- 環境依存の問題や、ライブラリのversion失効などあればここで吸収
コミュニケーションのやり方・ツールについて
- 適宜タスクの進捗や内容次第でテレビ会議
- Slackのみで、JIRA/notionなどのドキュメントをベースにしたコミュニケーション
- 弊社事例ではフロントエンドエンジニアはslackだけのコミュニケーションで副業が終わったことも
- リモートワーク を前提とした非同期コミュニケーションの徹底
最後の部分に関しては、弊社セールスマネージャーでOpsも兼務している瀬戸口のnoteを参考に。
情報管理について
- 初期は情報閲覧権限・Slack共にフル権限
- 2020年2月現在はfull,flexible,partnerという3つの花道での割り振りで権限を付与
勤怠について
slackのtimesチャンネルの例（リファラル）
- #kintai、個人のtimesチャンネルへの投稿
- 稼働が少ないメンバーは特に報告なし
- 基本的に事前にすり合わせた成果物と進捗を基準に判断
副業メンバーでもtimes推奨
弊社の副業メンバーのPM・エンジニアはtimesを行なっています。
timesを活用するメリット
- 悩んでいることをつぶやくことで簡単に共有できる
- コミュニケーションを取るための材料ができる（特にジョインした初期は大事）
副業受け入れ・人材活用問題あるあると解決策
タスクの疎結合難しい問題
タスク分解について上述していますが、同時によくある問題がタスクを疎結合にするのが難しい問題です。
副業の方の稼働時間・スキル・モチベーションを判断しタスクを依頼
- タスクにかかる時間の見積もり
- タスクにかかる費用の見積もり
- 他タスクとの進捗の兼ね合い
- 本業とのタスクの兼ね合い
- 新規タスクを別で作成する
- 副業、フリーランスに対するモチベーションの判断
- またこれらのタスクを誰がやるか
なども同時に考える必要があるため、PM/PdM/ディレクター/CTO/VPoE/CCO/CDO/現場のエンジニア・デザイナーがこの辺り取り組むリソースがなければ難しいです。
弊社のタスク分解問題の解決策の例
- 副業でPMの方にジョインしてもらう
- 新規タスク、構成作成、などディレクションを副業の方にお願いする
- 定期的に副業メンバーを入れることでタスクを棚卸し
- タスクを疎結合にすること
- チケットの記述ルールを開発メンバーで徹底する
- 全てのルールをドキュメントに残しておくこと
などを行なっております。
契約書・請求書大変問題
契約書、請求書の量が多くなってくると大変だという問題もよく耳にします。こちらに関してはバックオフィスと連携して副業人材採用用のワークフローを作成しておくことをお勧めします。
弊社では2年間副業経営をしてきて、副業メンバーが150名を超えた時期もあります。
「freee・クラウドサイン・入力用フォーム・スプレッドシート（GAS）を連携して、5-10分程度でほぼ自動で処理できる環境」をバックオフィスの方が実装してくれました。弊社ではバックオフィスの方が毎月Slackの#generalで請求書の発行などについて投稿してくれます。ホスピーな上に元エンジニアでオペレーション構築スキルが高く、最高な方です。確定申告などその時々で追加のコメントもあるので助かっております。
↑上記の環境が必要という声がありましたらサービス化も検討しております。ぜひRTしてコメントいただければ幸いです。
稼働時間・タスク管理どうするか問題
勤怠管理で悩まれる方もよくいますが、上述している通り、
- 「事前に期待値を調整しておく」
- 「進捗を共有するための方法を事前にすり合わせておく」
が特に大事です。期待値がずれてくるとなかなか元に戻すことが難しく、期待している通りの結果が得られなくなります。
- 初月は毎週レポート、進捗共有
- その後は会議を適宜設定する
などで対応方法を分けて決めておくと良いですね。
弊社ではドキュメントに残すことを推奨しているので、以前利用していたkibelaかnotion、JIRAにコメントを残しています。
まとめ
overflowという会社を事業・プロダクトのフェーズ・組織に関わる人のスキルや強みなどに合わせて最適解を模索しながら約2年半経営してきました。
「Offers」は、経営・事業を伸ばすための強い技術組織を作るためのプロダクトと位置づけており、本記事の経験・クライアント企業事例を元にさらに機能開発を進めております。
副業という働き方自体が新しく、企業側の受け入れ体制の作り方・副業に対しての考え方・採用やオンボーディングの考え方・利用ツールなどのインフラ環境・コミュニケーションのあり方など変えていかなければいけないフェーズです。
引き続き自社で高速に実験・検証し、
Offersや今後予定している新サービスに対して価値を転化し、磨き続けていきたいと思います。
弊社のプロダクトの価値観は「自社で実験し、価値があるものしか出さない」です。よろしくお願いいたします。
また、新サービス開発を予定しておりまして、CTO/VPoE/エンジニアリングマネージャー/PjM・PdMの方、プロダクト開発・マネジメントについて研究しておりますので、ぜひDM・テレビ会議・お茶などでディスカッションをさせてください。
副業人材活用における課題と解決策の各論については別々に記事を書いていきますので参考になりましたらシェアしていただける嬉しいです。
「なぜOffersを開発したのか」についてはこちらもどうぞ。
自分たちの原体験から「副業・転職マッチング」を切り口にサービススタート。overflow創業者3人にOffersの立ち上げをインタビュー(後編)
