こんにちは、鈴木です。
求人票の作成を経験しました。実際に公開した求人票を実例として、どのように考え、どのようなプロセスで、どのような中間成果物を生み出しながら取り組んだのか。具体的な内容を共有します。
「先に知っておきたかった！」と思うものや、検索しても見つからなかったものなど、多くの知見を得ることができました。
それらを公開することで、これから求人票の作成に関わる人のお役に立てれば幸いです。
- QAリード採用はじめました
- はじまりは兄弟会社の組織図
- 求人票を書こう! ってどうすれば!?
- 求人票作成のフレームワーク
- 1. 現在を書き出す
- 2. 未来を書き出す
- 3. その職種が必要な理由を書き出す
- 4. 必須経験と必須スキルを決める
- 5. 業務内容に具体的行動を書き加える
- 求人票が完成しました
- おわりに
QAリード採用はじめました
実際に作成したのはQAリードの求人票です。QA組織の立ち上げに関わり、組織をリードできる人をターゲットとする求人票です。
はじまりは兄弟会社の組織図
モノタロウには米国でECを展開している兄弟会社があります。そこのエンジニアの組織図を見たのですよ・・。そこには数十人規模のQA組織が存在しました。
モノタロウにはQA組織がありません。主に開発者がテストをしています。テスト専任が1人いますが、組織上は、その時々どこかの開発チームに所属して、各開発チームからのテスト依頼を受けています。
以前からQAに取り組んだ方が良いだろうという感覚がありました。しかし、他にも重要な取り組みがある中で、QAが必要な理由を言語化しないまま時間が過ぎていきました。
兄弟会社の組織図にあった数十人規模のQA組織。これをきっかけに、あらためて将来を見据えたモノタロウのQAの形と、それに必要な採用を考えることにしました。
求人票を書こう! ってどうすれば!?
まずは求人票を書きましょうという話になりました。
求人票には会社の概要情報のような職種に依存しない情報に加えて、「どのような業務なのか」「どのようなスキルを求めるのか」といった情報を記載します。
でも、求人票ってどうやって作れば良いのでしょうか。
世の中の情報を探すと記載項目やテンプレート、記述例を見つけることはできました。作り方を解説しているものもありますが、以下のように概要レベルの情報ばかりです。
- 会社の方針を確認しましょう。
- その職種のマネージャにヒアリングしましょう。
- それらを踏まえて求人票を書きましょう。
わたくしごとですが、QA組織を立ち上げたいと思っているエンジニアリングマネージャをやっています。上記の「2. その職種のマネージャにヒアリングしましょう」のマネージャが自分自身だから困ったというわけです。
ではどうするか。
求人票作成のフレームワーク
闇雲に書き始めて上手くいくとは思えません。そこで「どのように考えるのか」を先に考えました。
といっても大層なものではありません。事前に決めたのは「今はこうです。未来はこうです。ギャップを埋める勇者募集。」というストーリーで考えることだけです。
最終的には以下のように整理しました。これが求人票作成のフレームワークです。
- 1. 現在を書き出す
- 1.1. 思っていることを書き出す
- 1.2. 現在使っているモノを書き出す
- 1.3. 現在おこなっているコトを書き出す
- 2. 未来を書き出す
- 2.1. 将来おこなっているコトを書き出す
- 2.2. 将来使っているモノを書き出す
- 3. その職種が必要な理由を書き出す
- 3.1. 環境変化を書き出す
- 3.2. 環境変化を乗り越えるために必要なこと書き出す
- 4. 必須経験と必須スキルを決める
- 4.1. 経験とスキルを分けて考える
- 4.2. 隣接する職種がカバーできるものは必須から落とす
- 4.3. 必須と歓迎に分けた結果
- 5. 業務内容に具体的行動を書き加える
1. 現在を書き出す
1.1. 思っていることを書き出す
最初に、課題でも理想像でも何でも良いので、思っていることを書き出します。
実際に書き出したものが以下です。
- 案件単位ではなくサービスの品質を第一にする活動がしたい
- 上流工程に参加してサービスの品質を作りめる活動がしたい
- テスト計画やテスト設計に基づいたテストをやりたい
- テストを効率化するためのツールやサービスの選定・導入をやりたい
- QAをキャリアアップの通過点にしたい
- 開発チームが十分なテストを行えるようになるために支援したい
- FlakyなE2Eテストをなんとかしたい
- テスト管理やE2Eテストのツールやサービスを使いたい
- E2Eテストに時間がかかりすぎる問題を解決したい
- E2Eテストの書き方や書く基準を明確にしたい
- 自動テストの結果を収集・分析して活用したい
- ユニットテストとE2Eテストの比率が妥当なのか分からない
- インテグレーションテストってあるんだっけ？
- 非機能テストのやり方や実施基準を明確にしたい
- 人間が実施するのは探索的テストだけにしたい
何でも良いので思っていることを書き出すことは重要です。
あまり出てこないとしたら現状把握が不十分なのかもしれません。もしかすると課題があると思い込んでいるだけで、現状のままで何も問題はないのかもしれません。どちらにせよ一度立ち止まるべきサインです。
今回だと兄弟会社には大規模なQA組織が存在することを知って、モノタロウも頑張らねばと盛り上がってしまっただけの可能性もあります。
書き出したものは、この先を考えるための重要な材料です。フレームワークは考え方の枠組みでしかありません。インプットとなる材料がなければ何も出てきません。
1.2. 現在使っているモノを書き出す
現在使っているモノ（技術やツールなど）を書き出します。事実ベースで淡々と書き出します。
- Python, unittest, pytest, Robot Framework, Jenkins, IntelliJ, Docker, MySQL, Apache HTTP Server, JIRA, Bitbucket, Googleスプレッドシート、BigQuery, Data Portal, jMeter, Apache Bench, Remote TestKit, Mac, Windows, Linux, Slack
1.3. 現在おこなっているコトを書き出す
次に、現在おこなっているコト（業務や工程など）を書き出します。これも事実ベースで淡々と書き出しますが・・
書き出していくと「これって、やったり、やらなかったりするなぁ」とか「業務としての形を成していないような・・」と思うものが出ることもあります。微妙なものには「？」を付けておきます。
- 自動テスト、マニュアルテスト、ユニットテスト、E2Eテスト、複数ブラウザテスト、スマホアプリテスト、負荷テスト（案件ごと？）、回帰テスト？、受け入れテスト？、リリース判定
2. 未来を書き出す
ここからは未来について考えます。
現在のことは「モノ（技術やツール）」→「コト（業務や工程）」という順番でボトムアップに書き出しました。未来のことはトップダウンで「コト（業務や工程）」→「モノ（技術やツール）」という順番で考えます。木を見て森を見ず、にならないためです。
2.1. 将来おこなっているコトを書き出す
「1.1. 思っていることを書き出す」で「こうなりたい」というものがいくつもありました。それをベースに将来おこなっているコト（業務や工程など）を書き出します。
- サービス視点でのQA活動
- 上流工程への参画
- テスト計画、テスト設計
- ツールやサービスの選定と導入
- 開発チームに対する支援
2.2. 将来使っているモノを書き出す
次は将来の業務や工程をおこなうために必要なモノ（技術やツール）を考えます。
実際に書き出したものが以下です。
- 現在使っている技術やツール
- 将来も使い続けるものがほとんどのはず。
- テスト管理やE2Eテストのツールやサービス
- Mabl, Autify, TestRail, ...
- どれも使ったことがないので今は決められない。
あまり書けなかったのは、あまり見通せていない証拠です。
3. その職種が必要な理由を書き出す
ここまで現在と未来について書き出してきました。それによって、QAリードがなぜ必要なのか、言語化できる状態になりました。
3.1. 環境変化を書き出す
現在起こっている、もしくは近い将来起こるはずの環境変化が明確になると、「だから何をやるべきか」「どのような人が必要なのか」が分かります。
環境変化は以下の通りです。
- モノタロウは組織もシステムを拡大し続けている。
- E2Eテストが壊れた、誰が修正すべきか、といった会話が増えてきた。
- このままでは開発速度と品質を両立することが困難になると予想できる。
組織もシステムを拡大し続けているので、このままでは立ち行かなくなるという危機感があります。
3.2. 環境変化を乗り越えるために必要なこと書き出す
環境変化を乗り越えるためには、次のことが必要だと考えました。
- 品質を第一の関心ごとに活動するQA体制
- そのQA体制を築き上げる一人目QAの存在
拡大し続ける組織とシステムという現実に対して、品質面の不安が膨らんできたということです。
4. 必須経験と必須スキルを決める
ここまで進むと、採用したい職種に期待する業務経験やスキルが明らかになります。
- ソフトウェアテストの知識と実務経験
- テストに関するツールやサービスの使用経験
- テスト計画、テスト設計、テスト実施の知識と実務経験
- 複数名プロジェクトのプロジェクトマネジメント経験
- Web システムの開発経験（開発者としての経験）
- QA や SET（Software Engineer in Test）の経験
- テストや品質に関する体系的知識（例: JSTQB 合格者）
- CI/CD ツールの使用経験（例: Jenkins）
- 組織のマネジメント経験（管理職相当の経験）
- 単体テストや E2E テストの自動化経験
- AWS や GCP の使用経験
多いですね。上記の全てが必須だと言われるとなかなか厳しい。該当する人は誰もいない気もします。
そこで、必須とするものを絞ります。
4.1. 経験とスキルを分けて考える
応募のハードルをコントロールする上で意識したいことが2つあります。
- 必須経験は弱めに門戸を閉じる。
- 必須スキルは強めに門戸を閉じる。
経験とは今までに積み重ねたものです。現時点では業務として担当している必要はありません。少しでも経験したことがあれば「経験あり」になります。スキルと比べると経験を必須にすることは採用の門戸を閉じにくいです。
一方のスキルは、そのスキルを今現在保有しているかどうかが重要です。人が一度に担当できることには限界があるので、必須スキルを増やすほど該当者が急激に減ります。必須スキルは採用の門戸を閉じる力が強いです。
必須スキルを増やしすぎると該当者がいなくなる。一方、必須経験を減らしすぎると「◯◯の経験はありますか？」「ありません」ばかりで面接で聞くべきことがなくなる。どちらも注意深く取捨選択する必要があります。
4.2. 隣接する職種がカバーできるものは必須から落とす
何を必須から落とすべきか。隣接する職種のことを考えると決めやすいです。
モノタロウでは一人で完結する仕事は少ないです。チームやプロジェクトの関係者と協力しながら働いています。そのため、隣接する職種の人がカバーできるものは、積極的に必須から落とすことができます。
必須から落としたものは不要という意味ではありません。それがあるなら歓迎という位置付けです。
4.3. 必須と歓迎に分けた結果
今回は「QA組織の立ち上げに関わり、組織をリードできる人」がターゲットです。そこで、「テストと開発の両方の経験」と「複数名プロジェクトのマネジメント経験」を必須としました。
- 【必須】ソフトウェアテストの知識と実務経験
- 【必須】テストに関するツールやサービスの使用経験
- 【必須】テスト計画、テスト設計、テスト実施の知識と実務経験
- 【必須】複数名プロジェクトのプロジェクトマネジメント経験
- 【必須】Web システムの開発経験（開発者としての経験）
それ以外は必須から落としました。
- 【歓迎】QA や SET（Software Engineer in Test）の経験
- 【歓迎】テストや品質に関する体系的知識（例: JSTQB 合格者）
- 【歓迎】CI/CD ツールの使用経験（例: Jenkins）
- 【歓迎】組織のマネジメント経験（管理職相当の経験）
- 【歓迎】単体テストや E2E テストの自動化経験
- 【歓迎】AWS や GCP の使用経験
よく見ると分かると思いますが、必須スキルも歓迎スキルも書いていません。これは意図的に決めたことです。
5. 業務内容に具体的行動を書き加える
2.1. では将来行っている業務や工程として以下を書き出しました。
- サービス視点でのQA活動
- 上流工程への参画
- テスト計画、テスト設計
- ツールやサービスの選定と導入
- 開発チームに対する支援
このままだと抽象的すぎるので、応募者が業務の内容をイメージしやすいように肉付けします。その業務がすでに存在するものだと思って、人に説明するつもりで書くとリアリティが増します。
以下のようになりました。
- サービス視点でのQA活動
案件視点ではなくサービス視点で品質に取り組みます。例えば、各案件で流用できるような共通テスト仕様書を作成する、重要機能の E2E テストを整備する、開発チームを支えるためのツールやサービスを導入するといった活動です。自ら課題を見つけ、解決に導く活動です。 - 上流工程への参画
プロジェクトの企画や要件定義といった上流工程に加わり、(1) 品質観点での確認や提案、(2) テストに必要な情報のキャッチアップを行います。 - テスト計画、テスト設計
プロジェクトの内容を理解した上で、どのようなテストの全体計画や設計を行います。ウォーターフォール開発よりもアジャイル系で進める場合が多いです。重厚なドキュメントを作るのではなく、開発速度と品質を両立できる取り組み方が求められます。 - ツールやサービスの選定と導入
負荷テストに使うツールやテスト仕様書を管理するサービスなどを選定し、導入します。場合によっては開発チームに対する説明や、負担を減らすための仕組みを構築します。 - 開発チームに対する支援
同値分割や境界値分析のようなテスト技法の説明、テスト自動化の支援、Flakyなテスト（実行するたびに成功/失敗が変わる不安定なテスト）の安定化など、開発チームが抱える課題の解決を支援します。
求人票が完成しました
なんとかQAリードの求人票を完成させることができました。
モノタロウでは、各エンジニアが担当案件でテストをおこない、不具合を出さないように努力しています。それに加えて、案件単位の品質ではなく、サービスとしての品質を第一の関心ごととして取り組む人を必要としています。
一緒にモノタロウの品質を考えてくれる人に来てもらえたら嬉しいです。カジュアル面談もやっているので、ぜひともご連絡ください。
おわりに
今回、ゼロベースで新しい求人票を作成しました。
どのように考え、どのようなプロセスで、どのような中間成果物を生み出しながら取り組めば良いのか。それを考えることは非常に良い経験になりました。
ただ、こういった情報は検索しても見つからないんですよね。コンサル的なアドバイスやテンプレートは見つかるのですが、実際どうすれば良いのかと。
何かを考えるときに「考え方を考える」ことから始めるのは大変です。あらかじめ考え方の形（フレームワーク）を持っていれば、重要なことに多くの時間を使うことができます。
この記事で公開した内容が、求人票の作成に取り組む人の参考になれば幸いです。
Enjoy! 採用!
