updated_at: 2026/5/7

エンジニア採用のOSS戦略｜オープンソース活動で技術ブランドを築く方法

OSS活動を採用ブランディングに活かす戦略設計から社内制度・評価の実践手法まで体系的に解説

このページでわかること

「うちは技術力に自信があるのに、なぜかエンジニアが集まらない」

スタートアップの経営者や採用担当者から、こうした声をよく聞きます。求人票に技術スタックを並べても、スカウトメールで事業の魅力を語っても、肝心の「この会社で技術的に成長できそうだ」という実感が候補者に伝わらない。

その課題を根本から解決する手段の一つが、企業としてのOSS（オープンソースソフトウェア）活動です。

社内で開発したライブラリやツールを公開する、既存OSSにコントリビュートする、OSSコミッターを社員として支援する。こうした取り組みは、技術力を外部に「証明」する最も強力な方法であり、結果として採用ブランディングに直結します。

この記事では、以下を解説します。

OSS活動がエンジニア採用に効く構造的な理由
企業規模別のOSS戦略設計フレームワーク
社内制度の作り方（業務時間の配分、評価への反映、法務対応）
OSS活動を採用プロセスに組み込む方法
候補者のOSSコントリビューションを評価する基準
先行企業の実践パターンと成果指標

「技術力は高いのに、それが採用市場に伝わらない」と感じている企業に、具体的なアクションプランをお伝えします。

TL;DR（要点まとめ）

OSS活動は技術力の「証明」を外部に公開する行為であり、求人票やスカウトメールでは伝えきれない企業の技術文化を可視化する
エンジニアの転職意思決定において「誰と働くか」「どんな技術文化か」は上位の判断基準。OSS活動はこの両方に直接アピールできる
企業のOSS戦略は3段階で構築する。「既存OSSへの貢献」→「社内ツールの公開」→「コミュニティ主導のプロジェクト運営」
業務時間の10〜20%をOSS活動に充てる制度を設計し、評価制度にも反映させることが持続性の鍵
OSS活動の採用効果は、技術ブログのPV・GitHub Starsの数ではなく、カジュアル面談・応募経路の変化で測定する

1. OSS活動がエンジニア採用に効く3つの構造的理由

技術力の「可視化」が信頼を生む

エンジニアが転職先を選ぶとき、最も気にするのは「その企業の技術力は本物か」という点です。求人票に「モダンな技術スタックを採用」と書いてあっても、候補者はそれだけでは信用しません。

OSS活動は、企業の技術力をコードという最も客観的な形で外部に公開する行為です。GitHubリポジトリを見れば、コードの品質、設計思想、ドキュメントの充実度、レビュー文化まで一目瞭然。候補者は「この会社の技術レベル」を自分の目で確かめられます。

実際、ある転職実態調査によれば、エンジニアの約24%が「業界内で知名度の高いエンジニアがいること」を企業選びの要素に挙げています。OSS活動を通じて社内エンジニアの技術的な存在感を高めることは、この期待に直接応える施策です。

「転職市場に出てこない層」へのリーチ

優秀なエンジニアほど現職での評価が高く、転職サイトに登録していないケースが多いのは周知の事実です。スカウトメールの基本を押さえることは大切ですが、そもそもスカウト媒体にいない層にはリーチできません。

OSS活動は、技術コミュニティを通じた自然な接点を生み出します。自社のOSSプロジェクトにコントリビュートしてくれた外部エンジニア、技術カンファレンスで自社OSSについて質問してくれた参加者、GitHub上で自社ツールにStarをつけてくれた開発者。こうした接点は、スカウト媒体では絶対に作れないものです。

技術文化の「体験」が応募動機になる

OSSのIssueやPull Requestでのやり取りを通じて、候補者は入社前にその企業のコミュニケーション文化を体験できます。コードレビューの丁寧さ、Issue対応の速さ、新規コントリビューターへの歓迎姿勢。これらは、面接では伝えきれない「働く環境のリアル」そのものです。

候補者体験（CX）の改善が採用成功の鍵であることは広く認識されていますが、OSS活動は選考プロセスの外側で候補者体験を作り出せる点がユニークです。

2. 企業規模別のOSS戦略設計フレームワーク

OSS活動を採用に活かすには、自社の規模とリソースに合った戦略設計が不可欠です。大手企業のように専任チーム（OSPO）を置ける会社もあれば、エンジニア5人以下のスタートアップもある。それぞれに適したアプローチがあります。

レベル1：既存OSSへのコントリビュート（エンジニア5人以下）

最もハードルが低く、今日から始められるのが「既存OSSへの貢献」です。

自社プロダクトで使っているOSSにバグ修正やドキュメント改善のPull Requestを送る。たったこれだけでも、「この会社はOSSコミュニティに貢献している」というシグナルになります。

具体的なアクション:

自社で使っているOSSのバグを見つけたら、社内で修正するだけでなくupstreamにPRを送る
日本語ドキュメントの翻訳・改善PRを送る
自社での利用事例を技術ブログに書き、OSSプロジェクトのREADMEに掲載を依頼する
コントリビュートの実績をテックブログで発信する

この段階では追加コストはほぼゼロです。通常の業務で見つけたバグの修正先を「社内フォーク」から「upstream」に変えるだけ。

レベル2：社内ツール・ライブラリの公開（エンジニア10〜30人）

自社で開発した社内ツールやライブラリのうち、汎用性の高いものをOSSとして公開する段階です。

ここで重要なのは、公開すること自体が目的ではないという点。公開後のメンテナンス、ドキュメント整備、Issue対応を継続できるかが問われます。「公開したけど放置」では逆効果です。

公開候補の選定基準:

自社固有のビジネスロジックを含まないこと
社外のエンジニアにも需要がありそうなこと（類似ツールが存在しない、または既存のものより優れている点がある）
社内にメンテナンスを継続する意思と能力があること
ライセンスや知的財産の観点で問題がないこと

公開するツールの例としては、開発環境のセットアップスクリプト、CI/CDパイプラインの共通設定、特定フレームワーク向けのユーティリティライブラリ、社内で開発したLintルールやコード品質ツールなどがあります。

レベル3：コミュニティ主導のプロジェクト運営（エンジニア30人以上）

自社が主導するOSSプロジェクトを立ち上げ、外部コントリビューターを含むコミュニティを育てる段階です。ここまでくると、採用ブランディングへの効果は絶大です。

ただし、コミュニティ運営には相応のリソースが必要です。Issue対応、PRレビュー、リリース管理、ドキュメント整備、コミュニティイベントの開催。これらを継続するには、専任または準専任のメンバーが必要になります。

IPA（独立行政法人情報処理推進機構）の調査によれば、OSPO（Open Source Program Office）を設置している日本企業は全体の約41%、明確なOSS戦略を策定している企業は約39%にとどまっています。一方で、約69%の企業がOSSのビジネス価値を実感しているというデータもあり、戦略と実行の間にギャップがある状態です。

3. OSS活動を支える社内制度の設計

OSS活動を「個人の自主的な取り組み」に留めると、継続性も採用効果も限定的です。組織として制度化することで、安定した成果を生み出せます。

業務時間の配分設計

OSS活動に充てる時間は、業務時間全体の10〜20%が現実的な目安です。

具体的な運用パターンとしては、以下の3つがあります。

パターンA：週1回の固定枠 毎週金曜の午後をOSS活動に充てる。チーム全体で取り組む時間を揃えることで、ペアプログラミングやレビューが自然に発生します。

パターンB：スプリント内での配分 2週間スプリントの中で1日分（10%）をOSS活動に充てる。スプリント計画に組み込むことで、プロダクト開発とのバランスを取りやすくなります。

パターンC：四半期ごとのOSSスプリント 四半期に1回、1〜2日間をOSS集中日として設定。ハッカソン形式にすることで、チームビルディングの効果も期待できます。

評価制度への反映

OSS活動を業務として認めるなら、評価制度にも反映させるべきです。「やりたい人が勝手にやる」だけでは、組織としての持続性がありません。

評価に組み込む際のポイント:

OSSコントリビューションの数や質を定量的に記録する（PRの数、マージされた件数、Issueの解決数）
社内ツールのOSS公開を「技術的成果」として評価する
外部カンファレンスでの登壇や、OSSに関する技術ブログ執筆も評価対象に含める
ただし、数値目標のノルマ化は避ける。義務感からの活動は質が下がり、逆効果になる

ライセンスと知的財産の整理

社内ツールをOSSとして公開する際に、最も注意が必要なのが法務面です。

確認すべきポイント:

ライセンスの選定: MIT、Apache 2.0、GPLなど、目的に応じた適切なライセンスを選ぶ。ビジネス利用を広く許容したいならMITやApache 2.0が一般的
著作権の帰属: 業務中に書いたコードの著作権は原則として会社に帰属する。就業規則や雇用契約で確認する
CLA（Contributor License Agreement）: 外部コントリビューターからの貢献を受け入れる場合、CLAの整備を検討する
機密情報の除去: 公開前にAPIキー、内部URL、顧客データへの参照がないか徹底的にレビューする
競合優位性の判断: そのコードを公開することで競合に不利益が生じないか、経営判断として確認する

採用における法務知識と同様に、OSS公開にも法的なリスク管理が必要です。特に初回の公開時には、弁護士や知財部門のレビューを入れることを推奨します。

4. OSS活動を採用プロセスに組み込む方法

OSS活動そのものを強化するだけでは、採用効果は最大化できません。採用プロセスの各段階にOSSの要素を意図的に組み込むことで、効果を倍増させられます。

求人票（JD）でのOSS活動のアピール

求人票の書き方においてOSS活動に言及する場合、単に「OSS活動を推奨しています」と書くだけでは弱い。具体的に何をしているかを示すことが重要です。

効果的な記載例:

「業務時間の15%をOSS活動に充てる制度があります（実績：直近1年で〇〇個のPRをupstreamにマージ）」
「自社開発の〇〇（GitHubリンク）をOSSとして公開・メンテナンスしています」
「社員がOSSコミッターとして活動しており、〇〇カンファレンスでの登壇実績があります」

スカウトメールでの活用

スカウトメールの書き方において、候補者のOSS活動に言及することは非常に効果的です。GitHub上でのコントリビューション履歴を確認し、具体的なPRやプロジェクトに触れることで、「ちゃんとコードを見てくれている」という印象を与えられます。

ただし、注意点もあります。

候補者のOSS活動を「評価」するような書き方は避ける。上から目線に感じられる
あくまで「共通の関心」として触れる。「弊社でも同じ領域に取り組んでおり、ぜひお話ししたい」という切り口が自然
GitHubプロフィールの閲覧だけでは見えない部分もある。GitHubやポートフォリオの正しい評価方法も参考に

カジュアル面談での活用

カジュアル面談では、自社のOSS活動について具体的に語れるエンジニアを面談担当にアサインするのが効果的です。

話すべきポイント:

自社がOSS活動にどう取り組んでいるか（制度、実績、今後の方針）
面談担当者自身のOSS経験やコミュニティ活動
OSS活動を通じて得られた技術的な学びやキャリアへの影響
候補者のOSS活動への関心や経験を聞き、共通の話題を見つける

OSSコントリビューションを選考に組み込む

コーディング試験の代替として、自社OSSへのコントリビューションを選考課題にする方法もあります。ワークサンプルテストの一種として位置づけられます。

メリット:

候補者の実践的なスキル（コードリーディング、PR作成、コミュニケーション）を評価できる
候補者にとっても「面接のための課題」ではなく「実際の開発への参加」として前向きに取り組める
合否に関わらず、OSSプロジェクトへの貢献として残る

注意点:

候補者に過度な負担をかけないよう、課題の範囲を明確に限定する
選考課題として強制しない。OSSコントリビューション経験がない候補者には代替の評価方法を用意する
コーディング試験設計と同様に、評価基準を事前に明確化する

5. 候補者のOSS活動を正しく評価する

候補者のOSS活動を評価する際、Star数やコントリビューション数だけを見るのは危険です。表面的な数値に惑わされず、本質的な技術力を見極める方法を解説します。

評価すべき3つの観点

観点1：コードの質と設計思想

PRの内容を実際に読み、以下を確認します。

コードの可読性と保守性
適切な設計パターンの選択
テストの充実度
ドキュメントやコメントの質
エッジケースの考慮

観点2：コミュニケーション力

OSSプロジェクトでのやり取りは、チーム開発におけるコミュニケーション力の指標になります。

Issue報告の明確さ（再現手順、期待結果、実際の結果を正確に記述しているか）
PRの説明の分かりやすさ（何を、なぜ、どう変えたかが明確か）
レビューコメントへの対応の丁寧さ
反対意見への建設的な対応

観点3：継続性と一貫性

一時的な大量コントリビューションよりも、長期間にわたる継続的な活動の方が、技術への真摯な姿勢を示します。

コントリビューション頻度の推移
特定のプロジェクトへの継続的な関与
自身のOSSプロジェクトのメンテナンス状況

よくある評価ミスと対策

ミス1：GitHub Starsの数だけで評価する

Star数はプロジェクトの認知度の指標であり、技術力の指標ではありません。タイミングやマーケティングの要素も大きい。コードの中身を見ずにStar数だけで判断するのは避けましょう。

ミス2：コントリビューション数の少なさをマイナス評価する

OSS活動は任意のものです。育児・介護などで時間が限られるエンジニア、前職でOSS活動が禁止されていたエンジニアもいます。OSS活動がないことをマイナス評価するのは公平性の観点からも問題があります。

ミス3：有名OSSへのコントリビューションだけを高く評価する

大規模プロジェクトへの小さなtypo修正よりも、ニッチだが実用的なツールを自作してメンテナンスし続けている方が、技術力の証明としては強い場合があります。

6. OSS活動と技術ブランディングの相乗効果

OSS活動単体でも採用効果はありますが、他の技術ブランディング施策と組み合わせることで効果は何倍にもなります。

テックブログとの連携

自社OSSの開発背景、設計判断、運用で得た知見をテックブログで発信します。これにより以下の効果が生まれます。

OSS単体では伝わりにくい「なぜこの設計にしたのか」という思考プロセスを共有できる
技術ブログ経由でOSSプロジェクトの認知度が上がる
OSSプロジェクト経由で技術ブログの読者が増える
SEOの観点でも、OSS名をキーワードとした流入が期待できる

カンファレンス登壇との連携

自社OSSの開発経験を技術イベントやカンファレンスで発表することで、対面での技術ブランディングとOSSの認知拡大を同時に実現できます。

発表テーマの例:

「〇〇を開発した背景と設計判断」
「自社OSSのコミュニティ運営で学んだこと」
「既存OSSに〇〇をコントリビュートした話」
「OSS活動を社内制度化するまでの道のり」

DevRel活動との統合

DevRel（Developer Relations）の一環としてOSS活動を位置づけることで、技術コミュニティとの関係構築と採用ブランディングを体系的に進められます。

DevRelとOSSの統合ポイント:

DevRelのKPIにOSS関連の指標（コントリビューター数、Star数の推移）を含める
DevRel担当がOSSプロジェクトのコミュニティマネジメントを兼務する
技術イベントでのスポンサー活動とOSSプロジェクトの紹介を連動させる

7. OSS活動の採用効果を測定する

OSS活動の効果を「なんとなく良さそう」で終わらせず、定量的に測定し改善サイクルを回すことが重要です。

直接指標（アウトプット）

OSS経由の応募数: 「応募のきっかけ」に自社OSSやGitHubを挙げた候補者の数
カジュアル面談でのOSS言及率: 候補者が自社のOSS活動に言及した面談の割合
OSS活動者の採用決定率: OSSコントリビューション経験のある候補者の採用決定率（他チャネルとの比較）

間接指標（アウトカム）

GitHubリポジトリのStar数・Fork数の推移: 認知度の指標
外部コントリビューター数の推移: コミュニティの成長度
技術ブログのOSS関連記事のPV・SNSシェア数: 発信の到達度
カンファレンスでのOSS関連登壇数: 技術コミュニティでの存在感

採用ROIの考え方

OSS活動の採用ROIは、他の採用チャネルと単純に比較すべきではありません。

一般的な採用ROIの計算では、チャネルごとの「採用1人あたりのコスト」で比較しますが、OSS活動の効果は「ブランド認知」「技術文化の可視化」「自然な候補者接点の創出」といった、即座に数値化しにくい領域に広がります。

測定の現実的なアプローチとしては、以下がおすすめです。

四半期ごとに「OSS活動が直接のきっかけとなった応募・採用」を集計する
OSS活動に投じた工数（業務時間の〇%×人数×期間）をコストとして算出する
同期間の他チャネル（スカウト、エージェント、リファラル）のコストパフォーマンスと比較する
ただし、OSS活動にはリテンション（定着）への効果もあるため、定着率の推移も合わせて追う

8. OSS戦略の導入ロードマップ（90日計画）

OSS活動を組織として始める際の、具体的な90日間のアクションプランです。

フェーズ1：準備期間（1〜30日目）

Week 1-2：現状把握と方針決定

社内で使っているOSSの棚卸し（依存ライブラリ、ツール、フレームワーク）
社内にOSS活動経験のあるメンバーがいるか確認
経営陣とOSS活動の方針を合意（目的、投下リソース、期待成果）

Week 3-4：制度設計と法務確認

OSS活動に充てる時間の上限を決定（推奨：週の10〜15%から開始）
ライセンスポリシーの策定
機密情報チェックのプロセス整備
就業規則の確認（副業規定、著作権条項）

フェーズ2：実行開始（31〜60日目）

Week 5-6：既存OSSへのコントリビューション開始

チーム内で「自社プロダクトで使っているOSSで改善したい点」を洗い出す
最初のPRを送る（バグ修正、ドキュメント改善など、ハードルの低いものから）
コントリビューションの記録を開始

Week 7-8：社内ツールの公開準備

公開候補の社内ツールを選定
コードの整理、ドキュメント作成、テスト整備
公開前の法務レビュー

フェーズ3：拡大と発信（61〜90日目）

Week 9-10：OSSの公開と発信

選定したツールをGitHubで公開
テックブログで「なぜこのツールを公開したのか」を発信
社内Slackなどでの活動報告チャネルを開設

Week 11-12：効果測定と改善

初期指標の計測開始（GitHub指標、応募経路の変化）
チーム内で振り返りを実施（良かった点、改善点、次の四半期の計画）
採用チームと連携し、求人票やスカウトメールにOSS活動の情報を反映

9. OSS戦略でよくある失敗と対策

失敗1：公開して放置する

OSSを公開したものの、Issueが放置され、PRがレビューされない状態は、採用ブランディングにとって逆効果です。「この会社はメンテナンスを放棄する文化なのだ」という印象を与えかねません。

対策: 公開するプロジェクト数を絞り、メンテナンスできる範囲に限定する。メンテナンスの責任者を明確に決め、Issueへの初回応答のSLAを設定する（例：3営業日以内）。

失敗2：OSS活動を強制する

「全員がOSSに貢献すべき」という空気は、プレッシャーとなり逆効果です。OSS活動に興味がないメンバーもいれば、プロダクト開発に集中したいメンバーもいます。

対策: あくまで「機会の提供」として制度を設計する。参加は任意とし、参加しないことがマイナス評価にならないことを明確にする。

失敗3：採用目的が前面に出すぎる

OSS活動の動機が「採用のため」と見透かされると、エンジニアコミュニティからの信頼を失います。OSS活動の本質は技術コミュニティへの貢献であり、採用効果はその結果として付いてくるものです。

対策: OSS活動の目的を「技術力の向上」「コミュニティへの還元」として位置づける。採用効果は意識しつつも、対外的な発信では採用目的を前面に出さない。

失敗4：法的リスクの見落とし

機密情報の漏洩、ライセンス違反、競合への技術流出など、法的リスクを十分に検討せずにOSSを公開してしまうケースがあります。

対策: 公開前のチェックリストを作成し、法務・知財部門のレビューを必須プロセスとして組み込む。特に初回の公開時は慎重に。

失敗5：効果測定をしない

「なんとなく良いことをしている」という感覚だけでOSS活動を続けると、経営陣の理解を得られず、リソースが削られる可能性があります。

対策: 前述の指標を四半期ごとに計測し、経営陣に報告する。採用効果だけでなく、エンジニアのスキル向上やチームのモチベーション向上といった副次効果も含めて報告する。

FAQ（よくある質問）

Q1. エンジニアが5人以下の小規模チームでもOSS活動に取り組む意味はありますか？

あります。むしろ小規模チームこそOSS活動の恩恵を受けやすいのが実情です。大企業は知名度だけで候補者を集められますが、スタートアップにはそれがない。OSS活動は、知名度に頼らず技術力で候補者を惹きつける手段として非常に有効です。まずは自社で使っているOSSへのバグ修正PRを送るところから始めてみてください。工数はほぼゼロで、技術コミュニティでの存在感を少しずつ高められます。

Q2. OSS活動に充てる業務時間はどのくらいが適切ですか？

週の業務時間の10〜15%が現実的な出発点です。週40時間勤務なら4〜6時間程度。まずはこの範囲で始め、チームの状況やプロダクト開発への影響を見ながら調整するのが賢明です。Googleの「20%ルール」が有名ですが、すべての企業にそのまま適用できるわけではありません。自社の状況に合った配分を見つけることが重要です。

Q3. 社内ツールをOSSとして公開する際、競合に技術を真似される心配はありませんか？

この懸念はよく聞きますが、実際にはリスクは限定的です。まず、公開するのはビジネスロジックではなく汎用的なツールやライブラリであり、競合優位性の源泉そのものではありません。次に、ツールの公開よりも、そのツールを作れるチームの存在と、それを使いこなすノウハウの方がはるかに重要な競争力です。むしろ公開することで、外部からのフィードバックやコントリビューションによってツールの品質が向上するメリットの方が大きいでしょう。

Q4. OSSプロジェクトのメンテナンスが負担になりすぎた場合はどうすべきですか？

メンテナンス負荷が大きくなりすぎた場合は、以下の段階的な対応を検討してください。まず、外部コントリビューターの中から信頼できるメンバーにコミット権限を付与し、メンテナンスの分散を図ります。次に、プロジェクトの状態を正直にREADMEに記載します（「メンテナンスが追いついていません。PRのレビューに時間がかかる可能性があります」等）。それでも難しい場合は、プロジェクトをアーカイブ状態にすることも選択肢です。放置するよりも、明確にアーカイブする方が誠実な対応です。

Q5. OSS活動の実績がない候補者を不利に扱うべきではないのはなぜですか？

OSS活動はあくまで「追加の評価材料」であり、必須条件ではありません。OSS活動に参加していない理由は多様です。前職の就業規則でOSS活動が制限されていた、育児や介護で業務外の時間が限られている、プロプライエタリな領域で高い専門性を持っている、など。OSS活動の有無を採用基準にすると、特定の属性の候補者を不利にする可能性があり、ダイバーシティ採用の観点からも問題があります。

Q6. AI時代にOSS活動はどう変化していますか？

生成AIツールの普及により、OSSの開発速度は加速しています。Copilot、Cursor、Claude Codeなどを活用してOSSの開発やコントリビューションを行うエンジニアが増えており、AIツールを使いこなしてOSSに貢献する能力も新しい評価軸になりつつあります。一方で、AIが生成したコードの品質チェックやライセンス上の問題（AIの学習データに含まれるコードのライセンス）など、新たな課題も生まれています。AI時代の技術面接の設計と合わせて、OSS活動の評価基準もアップデートが必要です。

Q7. OSSプロジェクトのライセンスはどれを選べば良いですか？

目的によって最適なライセンスは異なります。企業としての利用しやすさを重視するならMITまたはApache 2.0が広く推奨されます。MITは最もシンプルで制約が少なく、Apache 2.0は特許条項が含まれるため特許関連のリスクを軽減できます。コピーレフト型（GPL系）は、派生物も同じライセンスで公開する義務があるため、企業の利用に制約が出る場合があります。初めてOSSを公開する場合は、MITライセンスが最も無難な選択です。

まとめ：OSS活動は「採用チャネル」ではなく「技術文化の表明」

OSS活動を採用戦略の一つとして紹介してきましたが、最も重要なのは、OSS活動を単なる採用チャネルとして扱わないことです。

OSS活動の本質は、「自社の技術文化を外部にオープンにし、技術コミュニティと共に成長する」という姿勢の表明です。その姿勢に共感するエンジニアが自然と集まってくるのが、OSS活動の採用効果の本質です。

逆に言えば、採用目的だけでOSS活動を始めても、見透かされて終わります。技術コミュニティに対する誠実な貢献があってこそ、採用ブランディングとして機能する。この順番を間違えないことが、成功の最大の条件です。

今日からできるアクション：

自社で使っているOSSの棚卸しをする
エンジニアチームに「upstream にPRを送れるバグや改善点はないか」聞いてみる
最初の1つのPRを送る

大掛かりなOSPO設立や社内ツールの公開は、その先の話です。まずは既存OSSへの小さな貢献から始めてみてください。

エンジニア採用の技術ブランディングやOSS戦略についてお悩みの方は、ぜひtechcellarにお気軽にご相談ください。採用コンサルティング営業の経験と現役エンジニアの視点から、貴社に最適な採用戦略をご提案します。