はじめに
「LayerXって正社員しか採用していないのでは？」「バクラクの開発はハードルが高そう」
そんな印象を持つ方もいるかもしれません。
ただ実際には、LayerX バクラク事業部ではこれまでも 副業・業務委託のソフトウェアエンジニアを受け入れ、プロダクト開発を一緒に進めてきた実績があります。
最近SNSでこの話題に触れた際にも反響があり、「興味はあるけれど、実態が分からない」という方が一定数いることを実感しました。
バクラク事業部で副業・業務委託のソフトウェアエンジニアも受け入れていること、もしや世の中に全然知られていないのでは？？という話を同僚としていたのですが、
— serima | LayerX (@serima) 2026年1月8日
これって本当ですか…？
興味ある方、お気軽にDMください！お話しましょう！！！
本記事では、候補者にとっての不安が大きい
- どのくらい稼働できるのか
- どんなタスクが任されるのか
- どんな権限や環境が提供されるのか
- どうやってコミュニケーションを取るのか
といった働き方の実態をお伝えできればと思います。
加えて、受け入れ側のマネージャーやエンジニアにとっても役立つように副業・業務委託がうまくいくタスク設計や詰まりやすいポイントの回避についても実例ベースでお伝えしたいと思います。
副業・業務委託でもチームで開発する
複数の受け入れ事例を通じて共通しているのは、参画形態に関係なくチームで開発することを前提にしている点です。
- 丸投げではなく、「一緒に前に進める」状態を作る
- コミュニケーションの設計（同期／非同期）を最初に整える
- タスクは“手作業”より“課題解決”に寄せる（任せ方も含めて）
副業・業務委託という働き方は時間が限られる一方で、自律的に前に進められる人の力が最大化しやすい形でもあります。
その前提をチーム側が理解しているかどうかで、体験と成果が大きく変わります。
ケース別の働き方
ケース1: 業務委託フルタイムに近い関わり方
ある事例では、平日中心にフルタイム相当の稼働で参画いただきました。
働く場所はフルリモートで、日々の進め方やコミュニケーションは正社員にかなり近い形で進みます。
どんなタスクをお任せしたか
細かい修正だけではなく、たとえば次のような技術的な意思決定や改善提案が効く領域を中心にお願いしました。
- 既存システムの運用・パフォーマンスを良くするための改善
- ある程度要件は伝えつつ、設計や進め方は提案も含めて主体的に進めてもらう開発
- 中長期的に効く改善（段階的に進めるタイプのもの）
単に指示された実装をこなす、というよりは、要件を満たすための方法を一緒に考え、より良い形にしていく進め方です。
権限はどこまで？
参画形態に関わらず、開発に必要な情報や環境へのアクセスは整備します。Notion、Slack 等社内情報へのアクセスは原則的に正社員と同じ扱いとしています。
また、Claude Code、Cursor等の開発ツールは本人が希望して社内利用OKなものについては導入可能です。
一方で、顧客データや本番環境など、取り扱いに慎重さが必要な領域は、リスクを踏まえて制限することがあります。
重要なのは「制限がある＝開発ができない」ではなく、開発を前に進めるうえで支障が出ない形で権限設計することです。
コミュニケーション方法
Slackを中心に、必要に応じて定例やエンジニア共有会にも参加いただく形で進めました。
フルリモートであっても、チームの一員として動ける状態をつくることを重視しています。 バクラク事業部では、Gatherというバーチャルオフィスツールを利用することで、ほかメンバーに相談をしたいと思ったときに 同期で話しかけるハードルを極力下げるようにしています。
ケース2: 副業（40時間〜60時間程度/月）での関わり方
フルタイムに近い関わり方だけでなく、副業として月に40時間〜60時間程度で参画いただくケースもあります。
副業の場合、稼働は平日夜間や週末になりやすい一方で、チーム側の稼働は平日日中が中心です。
そのため、次のような設計を取りやすいです。
- 週に1回、短時間でも同期で会話する枠を確保（進捗、次にやること、認識合わせ）
- それ以外は、プルリクエストやSlackで非同期に進める
- 稼働に波が出ることを織り込んで、スケジュールをタイトにしすぎない
どんなタスクが相性が良いか
副業・業務委託の受け入れで最初に難しいのは、「この方が何をやると双方ハッピーか」を見極めることです。
相性が良いタスク・悪いタスクの特徴を整理すると以下のようになります。
| 特徴 | 相性が良いタスク | 相性が悪いタスク |
|---|---|---|
| スコープ | スコープを切り出せる “この部分だけ完了すれば価値が出る”単位に分割できる |
締切が固定で動かせない “今週このスプリントで絶対出す”系はリスクが高い |
| 依存関係 | 並行開発に強い チームが進んでも、参画者が「今日いないと止まる」前提になりにくい |
本番データや顧客影響の調査が前提 権限設計上の制約が絡みやすい（止まりやすい） |
| コミュニケーション | 非同期コミュニケーションでも進む 仕様が曖昧でも、PR・設計メモ・コメントで意思決定を積み上げられる |
同期会話が多発する 仕様が未確定で、日中に詰める前提だと非同期で詰まる |
| 完了条件 | 完了条件が言語化できる 「何ができたらDoneか」が受け入れ側で明確に言える |
属人化している領域の“火消し” キャッチアップ負担が重く、双方が摩耗しやすい |
| 継続性 | ドメイン理解が“積み上がる” 一回やって終わりではなく、理解が次の開発に効いてくる |
- |
受け入れ側の工夫でカバーできる部分もありますが、特に初期段階では「相性が悪いタスク」を避けるのが無難です。
以下は、実際に相性が良かったタスクの具体例です。
1. “改善系”のタスク：性能・信頼性・運用の改善
- 例： 特定画面やバッチの遅さを、計測して原因を絞り、改善案を提案・実装する。
- 理由： 完了条件（応答時間など）を設定しやすく、設計とPR中心で回しやすいため。
2. “設計→PoC→レビュー”型：不確実性のあるテーマの先行調査
- 例： 新しい概念の導入に向けて、論点整理と小さなプロトタイプを作り、チーム議論を前に進める。
- 理由： 稼働制約があっても議論と試作で価値が出しやすく、開発全体が加速するため。
3. “境界がはっきりした機能”の追加：ユーザー価値が明確な小〜中サイズ
- 例： 既存フローに自然に乗る機能追加（画面・API・バリデーションなど）。
- 理由： 仕様の合意が取りやすく、Doneが明確なため。
4. “開発者体験”の改善：テスト、CI、開発環境整備、ツール導入
- 例： テスト戦略の整備、E2Eの安定化、CI時間短縮。
- 理由： 利害調整が少なく非同期で進めやすいうえ、受け入れ側の負担が長期的に下がるため。
受け入れ側の「タスク設計」のコツ
上記のようなタスクをうまく回すために、受け入れ側が意識すると良いポイントをまとめます。
1. “最初の2週間”はタスクの質より型を作ることに集中する
最初は成果よりも、
- PRの出し方
- 設計メモの書き方
- レビューの回し方
- Slackでの合意の取り方
を揃えるほうが、後々のコミュニケーションが楽になります。
2.「完了条件」を先に書く
- 例） - “xxがyy以内” - “障害時にzzができる” - “運用手順がこのページにまとまっている”
これがあるだけで、非同期でも迷子になりにくいです。この条件については、受け入れ側が書くようにしましょう。
3. “ブロッキングポイント”を先に潰す
参画者の能力に関係なく止まりがちなポイントは概ねパターンが決まっていることが多いので
- 触れる環境（開発環境やステージング環境など）
- 見られない情報の代替手段
- レビュー担当の決め方
を先に準備しておくと、双方の体験が良くなります。
どんな方に来てほしいか
受け入れ側として特に重視しているのは、特定の技術スタックの経験年数そのものも大事ですが、
- 「こういう課題があって、こう考えて、こう解いた」という形で語れること
- 不確実性のある状況でも、課題を分解し、解決策を考え、デリバリーまで意識を向けられること
です。
これらは正社員のメンバーにも求めていることですが、バクラクではエンジニアが自律的にプロダクト開発を推し進めていくことを大事にしています。副業・業務委託は稼働時間が限られることもあるからこそ、自律的に前に進められる力は大事な点となります。
副業でも、チームでプロダクト開発を
LayerX バクラク事業部では、副業・業務委託のエンジニアが周辺の作業だけを担当するのではなく、チームの一員としてプロダクトの価値を前に進める形で参画できる環境づくりを進めています。
- 副業でも、設計や提案を含めて前に進められるテーマがある
- 権限や環境は、リスクを踏まえつつ開発が止まらない設計をする
- 受け入れ側がタスクを設計できると、成果も体験も良くなる
募集について
現在、LayerX バクラク事業部では、副業・業務委託のソフトウェアエンジニアとして、プロダクト開発に関わっていただける方を募集しています。
また、エントリー前にカジュアルに話を聞いてみたい場合は、以下のOpenDoorからお気軽にお問い合わせください！（どちらでも構いません！）
バクラク事業部の開発チームの全体像を知りたい方は、こちらのBakuraku Engineering Team Deckをご覧ください！
