「複業クラウド」開発における複業タレント登用事例

株式会社Another worksで取締役CTOをしている塩原です。

株式会社Another worksは、複業マッチングプラットフォーム 「複業クラウド」 を運営している会社です。

複業クラウドは、以下のような特徴を持つサービスです。

• 即戦力の複業タレントと企業や自治体をマッチング
• エンジニア・デザイナー・PdM・マーケター・営業など職種横断
• 企業は月額定額で採用し放題

私自身、取締役CTOとしてプロダクト開発に関わる一方で、複業タレントを「登用する側」でもあり、「提供する側」でもある立場にいます。

その中で強く感じているのが、複業タレント登用は、正社員と「同じ役割設計」で考えるとうまくいかないということです。

一方で、役割設計さえ間違えなければ、複業タレントは非常に強力な戦力になります。

この記事では、Another worksで「複業クラウド」のプロダクト開発を通じて、実際にうまくいった複業タレント登用パターンと、逆にうまくいかなかったケースを正直にまとめます。

前提

今回の事例では、フルタイム、もしくはそれに近い形で正社員と同様にチームに入って開発してもらうようなスタンダードな複業タレント登用は含めていません。

この形式は正社員採用とさほど変わらず、複業タレント登用としての示唆が少ないため、今回の事例からは省略しています。

うまくいった複業タレント登用パターン

プロダクトビジョン策定アドバイザー

▼ 進め方

• ワークショップ & 壁打ち（ディスカッション）でプロダクトビジョンを策定
• ワークショップ・壁打ちの回数ごとに支払い
• 実際の意思決定には入らず、思考の質を引き上げる役割に徹してもらう

▼ ポイント

以下のような業務の特性から、複業タレントとの相性が非常に良い領域です。

• 社内だけだと視野が狭くなりやすく、バイアスがかかりやすい
• かといってフルタイムで雇うほどの業務量ではない
• そもそも策定経験のある人が少ない

OSS開発風（技術的に難易度の高い課題解決）

▼ 進め方

• 重要度は高いが緊急度は低い課題をリスト化
• その中から本人に課題をピックアップしてもらう
• 自律的に解決を進めてもらう

▼ ポイント

ここでの肝は、「自分で課題を選んでもらう」ことです。
この形にすることで、以下のようなメリットが発生します。

• オンボーディングコストが最小限になる
• 前提説明がほぼ不要になる
• 自律的に高いアウトプットが出やすい

AWS構築の切り出し

▼ 進め方

• AWSの構築・設計をまとめて依頼
• 要件を固めた上で成果物ベースで進行

▼ ポイント

インフラ構築は、以下の理由から複業タレントに任せやすい領域です。

• 作業範囲が明確
• 成果物が定義しやすい
• プロダクト文脈の理解が浅くても成立する

また人材側にとっては、月10万円程度でもノウハウを活かしやすく魅力的な案件になりやすく、企業側にとってもマネジメントコストがほとんどかかりません。

ただし、ある程度の信頼関係が前提になる点は注意が必要です。

プロンプト最適化エンジニア

▼ 進め方

• プロンプトのQA
• AI精度の検証
• 改善提案

▼ ポイント

プロンプト最適化は、時間がかかり、エンジニアでも得意・不得意が分かれる業務です。
この領域を得意な複業タレントに任せることで、メインメンバーはコアな開発に集中できるようになりました。

小さなUI・UX改善

▼ 進め方

• UI・UXの課題をひたすら解消
• 一定予算でタスクを大量に消化

▼ ポイント

後回しになりがちなUI・UX改善を、期間限定・タスク消化型で一気に進めることで、プロダクト体験の継続的な改善やメインメンバーの集中力維持に繋がりました。

プロジェクト型（ウォーターフォール寄り）開発

▼ 進め方

• 要件をかっちり定義
• 目標期限を設定しプロジェクト型で進行

▼ ポイント

• メインKPIとは直接関係しない
• 要件変更が少ない
• 期限が明確

こうした機能はスクラムには乗せず、プロジェクト型で切り出して開発することで複業タレントと相性良く進められます。

技術アドバイザー

▼ 進め方

• 設計レビュー
• 技術選定の壁打ち
• アーキテクチャ相談

▼ ポイント

特定技術のエキスパートというより、プロダクト開発経験が豊富なシニアエンジニアにお願いするケースがハマりました。

現役でプロダクトを作っている人は、ビジネス上の制約・技術的トレードオフ・現実的な落とし所の理解が深く、実践的なアドバイスをもらえます。

逆に、うまくいかなかったケース

小稼働メンバーをフルタイム前提のスクラムチームに入れる

▼ 進め方

• 日中稼働が難しい
• 週2程度の稼働
• フルタイム中心のスクラムチームに参加

▼ 何が起きるか

• 担当チケットがスタックする
• 他の開発に影響が出る
• 複数人開発における前提知識の共有が難しい

特に問題になるのが、その人の実装箇所でインシデントが発生した場合です。
結果として、定量的にもスピードが落ち、定性的にもチームの空気が悪くなるという状態になりがちです。

まとめ：複業タレント登用は「役割設計」がすべて

うまくいくケース	うまくいかないケース
コンテキスト依存度を下げる	スクラム前提で考える
自律的に動ける役割を切り出す	チームにそのまま入ってもらう
成果物・責任範囲を明確にする	稼働制約を軽視する

複業タレント登用で一番大事なのは、依頼の目的を明確にすることです。
複業タレント登用を検討している方や、すでに試していて悩んでいる方の参考になれば嬉しいです。