【企業向け】案件票の書き方｜応募が集まる情報の粒度

エンジニアは案件票の「書かれていない部分」を読んでいる

案件票は募集の入口です。そして多くの候補者は、案件票を最後まで読みません。読むのをやめるのは、文章が長いからではなく、判断に必要な情報が見つからないからです。

経験のあるエンジニアほど、単価レンジ、稼働日数、リモートの可否、契約期間の4点を先に探します。ここが書かれていない案件票は、条件が悪いか、社内で決まっていないかのどちらかだと受け取られます。実際にはただの記載漏れであっても、応募数には同じように効いてしまいます。

悪い案件票の例

次のような案件票は、実際によく見かけます。

• 職種: エンジニア
• 必須スキル: Webアプリケーションの開発経験、コミュニケーション能力
• 単価: スキル見合い、応相談
• 稼働: フルタイム
• リモート: リモート可
• 契約形態: 業務委託
• 開始時期: 即日
• 選考フロー: 面談

一見すると必要な項目は埋まっています。しかし、候補者側に伝わる情報はほとんどありません。問題点を挙げます。

1. 「エンジニア」では、フロントエンドかバックエンドかインフラかがわからない
2. 「Webアプリケーションの開発経験」では、自分が該当するか判断できない
3. 「スキル見合い」は、単価の目安がゼロ。応募の判断ができない
4. 「フルタイム」は、週5日なのか、週40時間の精算幅つきなのかが不明
5. 「リモート可」は、完全リモートか週1出社かで働き方がまったく違う
6. 「即日」は、実際には1か月後でよい場合が多く、対応可能な人を自ら狭めている
7. 「面談」だけでは、回数も期間も読めない

直した案件票の例

同じ案件を、判断できる粒度に書き直すとこうなります。

• 職種: バックエンドエンジニア（Go / API設計・実装）
• 必須スキル: GoまたはJavaでのWeb API開発経験3年以上／RDBのテーブル設計とクエリチューニングの経験／Gitを使ったチーム開発経験
• 歓迎スキル: AWS（ECS、RDS）の運用経験／決済または在庫管理ドメインの経験／OpenAPIによる仕様定義の経験
• 単価レンジ: 月70万円〜90万円（週5日・160時間基準／精算幅140〜180時間、超過分は時間単価で精算）
• 稼働日数: 週4日または週5日（週4日の場合は単価を按分）
• リモート可否: 原則フルリモート。月1回のチーム定例のみ東京都内へ出社（交通費支給）
• 契約形態: 業務委託（準委任）。初回3か月契約、以降1か月ごとに更新
• 開始時期: 2026年10月1日開始を想定（前後2週間は調整可能）
• 選考フロー: 書類確認（3営業日以内）→ オンライン面談1回（60分、CTOと開発リーダーが同席）→ 条件提示。応募から結果連絡まで最短1週間

情報量は増えましたが、読む時間はほとんど変わりません。候補者は自分が該当するかを30秒で判断でき、該当しない人は応募しません。結果として、応募数と選考工数の両方が改善します。

項目ごとの書き方の目安

職種

「エンジニア」で止めず、担当領域と主要技術まで入れます。検索で見つけてもらう入口にもなります。

必須スキルと歓迎スキル

必須は3つから5つに絞ります。ここを増やすほど応募は減ります。「本当にこれがないと着手できないか」を基準に選別し、それ以外は歓迎スキルに移します。「コミュニケーション能力」のような、判断できない項目は書かないほうが情報量が上がります。

単価レンジ

上限と下限を出します。出せない事情があるとしても、非公開の案件票は候補者から見ると比較対象から外れます。あわせて、何時間の稼働を前提とした金額なのか、精算幅はどうかまで書きます。単価だけあって時間の基準がないと、実質の時給が計算できません。

稼働日数

週何日か、週何時間かを明示します。週3日や週4日を許容できるなら書きます。優秀な人ほど複数案件を持っているため、この一行で候補者層が広がります。

リモート可否

「可」の一語で終えず、頻度と目的を書きます。出社が必要な場面（キックオフ、定例、リリース対応など）を具体的に挙げると、参画後の齟齬が減ります。

契約形態と期間

準委任か請負か、初回契約の長さ、更新の判断時期を書きます。更新前提であることを明示するだけでも、応募のハードルは下がります。

開始時期

「即日」は避けます。現在稼働中の人は応募できません。実際の希望日と、調整可能な幅を書きます。

選考フロー

回数、所要時間、面談に出る人の役職、結果連絡までの目安日数を書きます。フリーランスにとって選考期間は無収入のリスクなので、期間の見通しは応募判断に直接効きます。

業務内容の書き方

技術名を並べるだけでは、日々の仕事が想像できません。次の3点を短く書きます。

1. プロダクトが何で、誰が使っているか
2. 今どのフェーズか（新規立ち上げ、機能追加、リプレース、運用改善）
3. 参画後3か月で担当してほしいこと

3点目はとくに効果があります。「既存のモノリスから決済機能を切り出し、独立したサービスとして再構築する部分を担当していただきます」と書けば、興味を持つ層がはっきりします。

公開前の6項目チェック

• 単価レンジと、その前提となる稼働時間が書かれているか
• 必須スキルが5つ以内で、すべて着手に不可欠か
• リモートの頻度と、出社が必要な場面が具体的か
• 開始時期に調整幅が示されているか
• 選考の回数と結果連絡までの日数が書かれているか
• 社内用語や略称を、社外の人が読んでわかる言葉に直したか

すべて埋めても5分程度の作業です。応募が集まらないときは、募集経路を増やす前に、まずこの6項目を見直すほうが効果は出やすくなります。