LAPRASのカスタマーサクセスとソフトウェアエンジニアが、サンプルの求人票を添削し、改善ポイントを解説する記事の中級編・第3弾です。

今回取り上げるのは「仕事内容」について。仕事の概要・詳細はどのように記載したらいいか、「求めるスキル・経験」を記入するうえでの注意点などについて解説していきます。

「求める役割」については、期待する人物像の心を動かすにはどうしたらよいか、すぐに使えるテクニックを交えて解説していますので、ぜひ最後までご覧ください！

＜インタビュイー紹介＞
・Chiri Yuki（千里）：Customer Sucess Manager 2021年9月にLAPRASへジョイン。入社後は一貫してCustomer Success Managerを担当。顧客のLAPRAS活用と継続利用の支援を行う。2023年からはカスタマーサクセス領域のマネージャーとなり、サークルの戦略策定やメンバーマネジメントといったマネジメント業務と、顧客へのCS業務・CSOps等のプレイング業務を兼務中。

・板谷美玲（ことね）：ソフトウェアエンジニア 2022年4月にLAPRASへジョイン。プロダクト周辺の技術的な課題解決による貢献を行い、約１年後に課題解決の専門チームを立ち上げてリード。2024年4月からはCS領域での課題解決にフォーカスし、エンジニアリングやアジャイル開発のスキルを駆使してメンバーの支援や業務改善などにコミットしている。

仕事内容は直近の課題・目標が伝わるように

求人票のサンプル：Before
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
●JOB（仕事内容）
・概要
LAPRAS SCOUT と LAPRAS のフロントエンド(Vue.js / Vuex)とバックエンド(Django)の開発を担当していただきます。主にWebフロントエンド開発のスキルをお持ちの方を募集しています。
DjangoやVue.jsの業務経験がなくても、入社後に学んでいただくことが可能です。

■具体的な業務内容
・スクラム開発チームの開発者として参加
・LAPRAS SCOUT, LAPRAS の機能開発および改善
・Chrome拡張機能（LAPRAS SCOUT Extension）の開発
・Terraform や Kubernetes を使用したインフラ整備
・フロントエンドの設計や実装
・バックエンドAPIの設計や実装
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

仕事概要はわかりやすく一文で

（千里）仕事内容は「概要」と「具体的な業務内容」で記載する情報量にメリハリを付けるのがポイントです。

閲覧者はまず「概要」を見て、そこで興味を引かれたら「具体的な業務内容」を見る、という順番で読み進めていくので、以下のように分けて考えるといいでしょう。

・「概要」は、その仕事の内容をわかりやすく1-2行で記載する。
・「具体的な業務内容」には、定常的な業務だけでなく「直近でどんなプロジェクトやイシューに取り組んでいるか」、「直近半年～1年でどんな目標を目指しているか」を記載する。

「特にフォーカスしてほしい仕事」に力点を置く

（千里）ここでは、定常的な業務や基本的な役割などの「普遍的な仕事」に関する情報と「今、特にここに注力している」という「直近でフォーカスしてほしい仕事」に関する情報を意識してかき分けることが重要です。

特に後者の「直近でフォーカスして仕事」については「どんなプロジェクトやイシューに取り組んでいるか」「チームの短期的にどんな目標を目指しているか」を記載すると、自社の独自性を効果的にPRできます。

（ことね）サンプルの求人票は、仕事内容を網羅的に書こうとするあまり、そのあたりのかき分けが十分にできていません。

エンジニアの視点からも「明確なゴールがイメージしにくい定常業務」だけでなく「現在ここまではできている」「直近ではさらにここまでできれば良い」という、現在の状態と短期的な目標が示されたほうが、安心して応募しやすいです。

（千里）たとえ同じ職種でも「成熟した組織」で求められる仕事と「まだ未成熟な組織」で求められる仕事には違いがあります。現状がどちらに当てはまるのかがわかるだけでも、閲覧した人は「自身に求められる仕事」を具体的にイメージしやすくなります。

仕事内容を網羅的に記載することもたしかに大事です。しかし、それ以上に「自分が特に、どこの領域でパフォーマンスを発揮してほしいか」がわかるような情報が載っているほうが、企業側としても自社の課題感にマッチする人を集めやすくなりますし、求職者も「自分の志向性に合う仕事かどうか」を判別しやすいため、結果として良いマッチングに繋がりやすくなります。

求めるスキル・経験は「緩やか」かつ「明確」に

求人票のサンプル：Before
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
■求めるスキル・経験

【必須スキル・経験】
・Webフロントエンド開発の実務経験（1年以上）
・JavaScriptまたはTypeScriptの使用経験（1年以上）
・プロダクトマネジメントとしての経験
・開発マネージャーとしての経験
・エンジニア育成の経験
・フロントエンドのアーキテクチャに対する深い知見（Reactの設計ができるレベル）

【歓迎されるスキル・経験】
・Vue.jsを用いた開発経験
・Djangoを用いた開発経験
・クラウドサービス（AWS, GCP等）を活用した開発経験
・UI/UXデザインの知識やスキル
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

求めるスキルは必要最小限で記載する

（千里）「求めるスキル・経験」のポイントは、必須な条件（MUST条件）と必須ではないがあると嬉しい条件（WANT条件）を明確にすることです。特に、MUST条件については原則「それがないと仕事にならない」というレベルの最低限持っていてほしいもの」に限定して記載することを推奨します。

サンプルの求人票で気になるところは「プロダクトマネジメント」から「開発マネージャー」、エンジニア育成など、幅広い領域で経験がある人を求めている点です。まず「本当にそれだけの経験がある人が必要なのか？」という点から考え直してみるべきでしょう。

条件をできるだけ緩やかにしたほうが良い理由は、エンジニア採用では母集団形成の難易度が非常に高いからです。求人を出す際は「なるべく多くの方にリーチして面談につなげる」ということを第一に考える必要があります。

たとえばプロフィールだけを見て「要件に合わないかも」「情報が不足していて判断できない」と感じた人材でも、面談で話してみたら「選考に進めたい！」という印象に変わることも少なくありません。そうした「対話で生まれる可能性」を閉ざしてしまわないよう、間口を広げておくことが大事です。求人の閲覧時点では採用要件を厳しく絞るのではなく、少しでも広い分母にリーチできるような形で臨むことをおすすめします。

提示年収は市場感的に適切か？

（千里）企業が採用要件を決める際は「まず大枠で募集するポジションの職種やスキルのレベル感が決まり、次に提示年収を決める」という順番で進めるのが一般的です。この段階で「自社と同レベルの採用要件で募集を出している企業」、つまり「採用市場で競合になりうる企業」の求人をチェックし「スキルに対する提示年収が市場感に合っているか」を一度確かめておきましょう。

（ことね）エンジニアは転職する際、自分に近い採用要件の求人を複数比較して転職先候補を選定します。提示年収が市場感よりも高く設定できれば、当然多くの求職者からは魅力的に映るはずです。

ただし、市場感を上回る提示年収を提示できなくても、それ以外の点で「働く魅力」を訴求できれば転職先としてに選んでもらえる可能性はあります。候補者は提示年収だけでなく、採用要件・やりがい・働く環境など、異なる複数の要因を総合的に見て転職先を決めるからです。

どこで競合に差別化するかを決める

（ことね）ここからは提示年収以外で、どのように競合に差別化すればよいかポイントを解説します。

（千里）提示年収が妥当であっても「ネームバリューがある」「事業ドメイン的に人気がある」など、独自の魅力を持つ競合他社が多くいる場合は、それらの企業とどう差別化していくかが重要になるので、普遍的に役立つノウハウです。

まず採用したい人物像をイメージして、その人物が求人に応募するにあたって「判断材料になりうる要素」を、思いつく限りピックアップしてみましょう。

（例）求人票で比較される要因
・給与・報酬
透明性、賞与・インセンティブの仕組み、福利厚生など

・就業条件
フレックス・リモートワークの可否、勤務地、休暇制度、残業制度など

・仕事のやりがい
仕事内容、成長機会、企業文化、社会貢献性、チーム構成など

（千里）要素をピックアップできたら、次のような流れで、自社にとって「ネックになりうる要素」を特定、改善できないか検討してみましょう。

（1）求人上の競合他社：自社が負けている要素はあるか？
（2）負けている要素：変えられるか？変えられないか？を検討
（3）負けているが変えられない要素：「ネガティブに映らない書き方」を検討

たとえば、競合に負けている要素が「給与」なのであれば、もっと提示年収をあげられないか検討する、「就業条件」なのであれば「リモートワークやフレックス制を導入できないか検討する」ということです。とはいえ、変えるのが難しい条件もあると思うので、そういう場合はワードチョイスなどを工夫して「ネガティブに映らない書き方」を目指しましょう。

曖昧な表現はできるだけ避ける

（千里）エンジニアの目線から、こういう点に気をつければ「ネガティブに映りにくい」というポイントはありますか？

（ことね）そうですね。エンジニアは基本的に「イレギュラーな事態に備える仕事」です。そのため、なるべく「曖昧な表現を避ける」というのがポイントになるでしょうか。

サンプル求人を例に取ると「プロダクトマネジメントの経験」「開発マネージャーの経験」といった表現がありますが、単に「経験」といっただけでは数ヶ月なのか数年なのか、どの程度のレベル感なのかが抽象的でイメージできません。そうすると「イレギュラーに備える」というエンジニアの考え方の傾向から「自分にはマッチしていないかもしれないから、応募するのはやめよう」と考えるきっかけになってしまう可能性があります。

同じことを伝えるにしても、たとえば「スクラムマスターのような役割を要求します」など、ある程度業界で浸透している用語に置き換えて期待値を表現するほうがいいでしょう。

経験年数より「何ができるか？」が重要

（千里）サンプル求人にも記載がある「言語名：経験年数◯年以上」といった表現はいかがですか？

（ことね）それもあまり推奨できません。エンジニアのスキルレベルと経験年数は、言語によってどの程度相関するかに違いがあるからです。また、同じ言語でも事業ドメインやコードベースの設計によって書きぶりも変わってくるので、経験年数のみで技術力を図ろうとするのは、アンマッチが発生するリスクを高めてしまいます。

（千里）経験年数だけでなく「その言語で何をやっていたか」を尋ねるほうがいい、ということですね。

（ことね）たとえば「Webアプリケーションを構築・運用した経験がある」「TypeScript/JavaScriptでReact, Vue等を使った開発ができる」というふうに、どんな言語を使って、どんな開発ができるのかを明確に聞くほうがエンジニアにとっても曖昧ではない、明確な表現として伝わります。

エンジニアが魅力を感じるワードは「エンジニアに聞く」のが一番

（千里）エンジニアが曖昧だと感じる表現を避けるのは、まだエンジニア採用の経験が浅い人事の方だと難しいのではないでしょうか。そういう方におすすめの方法はありますか？

（ことね）ある程度、エンジニアが「魅力的な求人だ」と考えるであろう勘所がわかっていて、かつそれを言語化できるエンジニアと文面をブラッシュアップするのが一番ですね。

（千里）社内にそういった相談ができるエンジニアの方がいればいいですが、いない企業もあると思うのでLAPRASでそういった方々の相談に乗るイベントを企画するのも面白そうですね！

「求める人物像」に刺さる魅力を発信

求人票のサンプル：Before
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
（価値観）
・弊社のミッション・ビジョン・バリューに共感いただける方
・スタートアップのカオスを厭わずに業務遂行出来る方
・周囲と協調しながら自律的に行動できる方

（志向性）
・フロントエンドエンジニアとしてさらなる成長を目指す方
・経験豊富なエンジニアのサポートのもと、実践的なスキルを身につけたい方
・フロントエンド開発を中心に、バックエンド開発やクラウドインフラなど幅広い技術領域に興味がある方

（意欲）
・ユーザー体験、品質、開発効率を向上させるためのフロントエンド開発の改善に積極的に取り組める方
・チーム全体のフロントエンド開発能力向上のため、技術的な知識の共有や勉強会の開催などに意欲的な方

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

「求める人物像」に「選んでもらう」ために

（千里）「求める人物像」というと「◯◯に当てはまる方」というように「企業側が条件を提示し、当てはまる人を選ぶ」といったニュアンスが強いですが、エンジニア採用は圧倒的な売り手市場です。そのため、むしろ「求める人物に転職先として選んでもらえるよう、魅力的なアピールポイントを記載する」という発想で記載するのをおすすめします。

理想としては「実際にどのような環境があるか」や「どのように実現可能か」の具体エピソードが想像できる内容まで書いていただくことが大切です。そのひと手間により、他社に広く当てはまる情報から自社ならではの色が出る、よりユニークな強み情報にレベルアップ出来ると思います。
（記事末「サンプルの改善案」もご参照ください）

価値観に共感してもらえそうな自社の記事や、実際のエピソードが読める記事等を盛り込んでいただくこともおすすめしています。 

（ことね）そうしたアピールポイントに、自分のキャリアビジョンにマッチするような内容が書かれていたりすると、思わず興味を惹かれてしまいますね。

社内の活躍しているロールモデルを示そう

（ことね）逆に、よくあるパターンで注意すべきものとしては「弊社のビジョン・ミッション・バリュー（MMV）に共感してくれる方」という記載が挙げられます。これらMMVなどの概念は抽象度が高く、「文章として理解できても、自分の解釈が正しいのか」という点に確信を持つのが難しいです。避けるべき「曖昧な表現」と受け取られる可能性もあるので気をつける必要があります。

（千里）言葉で説明しようとするのではなく「現在社内で活躍している人はどんな人が多いのか」を紹介するほうがわかりやすいです。

たとえば「技術志向の強いエンジニアが、技術的な挑戦ができる環境に惹かれて集まった」という企業もあれば「プロダクトのファンになってくれた人が集まって、そのプロダクトをより良くしていこうという点で団結している」という企業もあるはずです。

このように「どんな人が、どんな点に惹かれて集まっている組織なのか」という点は、企業の「色」を出しやすいポイントなので工夫のしがいがあります。

（ことね）社内である程度パフォーマンスを発揮している人にインタビューして「どんな点を自社の魅力だと感じているか」を聞いてみるのがおすすめです。それがそのまま、自社を選んでもらえるような魅力的なアピールポイントになるはずです。

今回使用したサンプルの改善案

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ 
●JOB（仕事内容）
LAPRAS SCOUT と LAPRAS のフロントエンド(Vue.js / Vuex)とバックエンド(Django)の開発を行います。Webフロントエンドの開発に強みをお持ちの方を募集しています。

DjangoやVue.jsの業務経験は必須ではなく、入社後にキャッチアップいただく形で問題ありません。

■具体的な仕事内容
・スクラム開発チームの開発者として
LAPRAS SCOUT, LAPRAS のスクラム開発チームに開発者として参加します。このスクラムチームではプロダクトに関わる開発機能をすべて備えているため、Webアプリケーション開発の他にも、Chromeの拡張機能である LAPRAS SCOUT Extension の開発や、Terraform や Kubernetes を使用したインフラの整備も担当することがあります。

チーム全体における開発内容の割合は
フロントエンド：バックエンド : その他 = 30 : 60 : 10
程度です。

そのうち、このポジションでは主にフロントエンドのタスクや、フロントから利用するAPIの設計や実装なども担当することを想定しています。

・フロントエンドエンジニアとして

主に二つの役割を期待しています

・ 体験、品質、開発効率を向上させるためのフロントエンド開発の改善に継続的に取り組み、リードしていく（現在のフロントエンド設計担当のエンジニアと協力しつつ進めます）

・技術の伝導
チーム全体のフロントエンド開発能力を向上させるため、技術的なインプットを欠かさず、それらを勉強会の主催、ドキュメンテーションなどを通じてチームに共有して活用できるようにしていく

■求めるスキル/経験
・利用者の求めているソフトウェアを作ることに喜びを感じる方
・フロントエンド開発に興味をもちつつも、バックエンド開発をすることに抵抗がない方
現在のチーム規模ではフロントエンド/バックエンドの完全な分業は考えていません。
・ソフトウェア的な理想だけではなく、事業や開発チームの状況を考慮して最適な設計を導き出すことを重要視されている方

●必須スキル/経験
現在の業務では必ずしも必要ではないものも含んでいます（現状の課題を抽出していく上で必要となるようなベースとなる知識等）

・Web アプリケーションの構築・運用経験
・バージョン管理システムを利用したチームでの開発経験
・TypeScript/JavaScript
・React, Vue等を使った開発ができる
・ミドルウェア等の選定/データフローの設計ができる
・ビルド環境の設計/構築ができる

・CSS
基本的なレイアウト（display, flexの基本, レスポンシブの考慮)を実装できる
メンテナブルなCSSにするための方法論(bem, FLOCSS等)に関する知識を持っている
AltCSS (PostCSS, LESS, SCSS)などの知識をもっている

・マークアップ
マシンリーダブル/アクセシビリティを考慮したマークアップができる
デザイナーとコミュニケーションを取って、実装コストを意識した仕様のすり合わせができる

■歓迎するスキル/経験
・フロントエンドにおけるテスト設計に関する知識
・フロントエンドの容量削減、SEOに関する知識
・フロントエンドのパフォーマンスチューニングに関する知識
・デザイナーとしての業務経験
・Python, Django での開発経験

■入社後に期待していること
・入社1ヶ月で開発フローの理解や社内のコミュニケーションが円滑にできるようになること
・入社2ヶ月でフロントエンド開発において機能開発タスクが設計を含めて一人でできるようになること
・入社4ヶ月でサービスの主要な機能の仕様を把握しており、開発に支障がないこと。また、主体的に技術的負債の返済やより効率的な開発環境の提案などができること

■LAPRASがご用意できる環境
◯技術への挑戦と成長
・短期的な価値最大化と長期的なミッション達成の両立を目指す環境で、技術的チャレンジと事業インパクトの両方を追求できます。
・フロントエンド開発を軸に、バックエンドやインフラなど幅広い技術領域にチャレンジできます。
・実力主義の文化の中で、技術力を正当に評価され、成長の機会が豊富にあります。
・ユーザー体験や開発効率の向上など、フロントエンド開発の改善に主体的に取り組める裁量があります。

◯自由度の高い働き方
・フルリモート・フルフレックスの働き方で、ワークライフバランスを重視しながら最大限のパフォーマンスを発揮できます。
・ホラクラシー組織を採用しており、役割ベースで柔軟に組織構造が変化する中で、自身の強みを最大限に活かせるポジションで活躍できます。

◯刺激的で成長できる仲間たち
・複数のプロダクト開発経験を持つ実力派エンジニアたちと切磋琢磨しながら、日々の技術的課題に取り組めます。
・ビジネスサイドと対等に議論し、社会的意義の高いプロダクト開発に携わることで、エンジニアとしての視野を広げられます。
・技術共有や勉強会を通じて、チーム全体のスキル向上に貢献できる機会が豊富にあり、自身の知識やスキルを高められます。
・「なぜLAPRASで働くのか」という問いに、「難しいが価値ある課題に挑戦できる」「目指す方向が明確」と答えるような、志の高い仲間たちと働けます。

■募集チームから
LAPRASが目指す世界を一緒に作っていきたい！と強く思っている方に来ていただきたいと考えています。世の中のミスマッチをなくしていきたい方、ぜひ私達と一緒に未来を作っていきましょう！
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

まとめ：エンジニア目線で魅力的な求人票づくりを

「求人票の改善ポイント：中級編」も今回で3本目。今回は仕事内容、求めるスキル・経験と求める人物像を魅力的に見せるにはどうすればいいか解説してきました。

全編を通してお伝えしたかったのは、求人票は常に「エンジニアの方々の目線」に沿って作っていくのが大切である、という点です。求人票がエンジニア目線で書かれていれば「この企業はエンジニアを大切にしている」ということが伝わり、自然と良い面・アピールしたいポイントも好意的に受け止めてもらえるようになります。

今回ご紹介したポイントを忘れず、ぜひより良い求人票を作るために役立ててみてください！