クフでダローバルな日記

タフでもグローバルもない

現場メンバーの知識を人材要件定義に活かす手法「Job Analysis」の紹介

tl;dr ― Job Analysis ってなんやねん

  • Job Analysis は採用メンバーの業務知識を人材要件定義に活かすための構造的な手法。
  • 遂行すべきタスク（Task）と求められている能力（Competency）の優先順位をまとめた文書がアウトプットとなる。
  • Task の洗い出し・評価、Competency の洗い出し・評価、Task と Competency の紐付け、のざっくり3ステップでできる。
  • Job Analysis をしたら、する前に比べて実際の業務を反映していそうな人材要件ができ、見極めや集客をより効果的にできるようになった。
  • 米連邦政府人事管理局や Google などが推奨している手法なので、日本でももっと流行ってほしい。

目次

イントロ

この記事はスクラム採用 Advent Calnedar 201915日目の記事です。

誰？

僕は株式会社HERPでソフトウェアエンジニアをしている者です。
本名はググったら出ますが、最近はどのコミュニティでも「まざっち」と呼んでもらってます。
スクラム採用という概念を提唱している株式会社HERPのメンバーの中で、このカレンダーに投稿するトップバッターになってしまったのでやや緊張してますw

なんでエンジニアが採用についての記事を書いてるの？

まず「スクラム採用」について簡単におさらいしておきます。
スクラム採用は、職務の分化が進み採用担当が全ての職務を把握しきれなくなる中で、現場メンバーが積極的に採用に関わることで、採用にまつわる様々なメリットが得られるとの仮説から生まれた概念です。
この Advent Calendar の他の記事を見ていただければ、この仮説が多くの企業様で正しいと検証されつつあることがわかるかと思います。

ただ、「現場メンバーが採用に積極的に関わる」といっても、現実には採用担当の方が採用PM*1として現場メンバーを巻き込む段階で苦戦されているケースがまだ多いようです。
そこでこの記事では、現場メンバーが採用に積極的に関わるとはどういう状態なのか・HERPではどう関わっているのかについて、エンジニアの立場から発信してみようと思います。

特に人材要件定義は、業務知識を活かすために現場メンバーと採用PMの協力が重要になるので、HERPでのやり方を紹介したいと思った次第です。

HERP で Job Analysis が必要になった背景

HERP では、エンジニア採用の集客・見極め・オンボーディングの3フェーズについて、それぞれエンジニア内で責任者を立てています*2。
僕はこの見極めフェーズの責任者として、他社事例を調べつつ選考プロセスを設計していきました。

その結果、一番参考になったのは米連邦政府人事管理局（以下、OPM）のページでした。
Designing an Assessment Strategy

簡単に言うと、選考プロセスは以下のように設計すると良いとされています。

  1. 採用したい人の人材要件を定義する
  2. 人材要件のうち、見極めたい能力を特定する
  3. 見極めたい能力を見極められるように選考手法を設定する
  4. 実際に選考プロセスを運用する中で、選考プロセス自体を種々の指標で評価して改善する

ざっくり1と2が見極めにおける戦略的な部分、3が戦術的な部分、4はアジャイル的な改善の考え方になっています*3。
この戦略的な部分に現場メンバーの業務知識を活かすのがスクラム採用的なやり方ですが、実際に現場メンバーがやると「超絶優秀スーパー人材」*4を求めてしまうなどの問題が起きがちです。
そこで、現場メンバーの業務知識を活かしつつ納得感のある丁度良い人材要件に落とし込む Product Manager 的な役割が採用PMには求められます。

この、現場メンバーの業務知識を活かす人材要件定義手法として、Job Analysis が有効だと考えています。
これもまた OPM によって推奨されている他、人事・採用担当の方の多くが参考にしているであろう Google の re:Work でも（めちゃめちゃサラッとですが）推奨されています。

職務内容を見極め、その職務で成果をあげる人の要件と行動を特定するには、職務分析を行うのが有効です。
Google re:Work - ガイド: 構造化面接を実施する

採用に力を入れている巨人たちが推奨している方法であり、研究によってその有効性も実証されている（らしい）ので、自分たちで車輪の再発明をするよりマシだろうということで、HERP ではこの手法を用いることにしました。
詳しくは次の節で紹介しますが、SMEという職務の専門家（≒現場メンバー）を巻き込む考え方が、スクラム採用との親和性も高そうだった点も、この手法を選択した理由の一つです。

Job Analysis のやり方

というわけで、ようやく Job Analysis のやり方の説明に入ります。

正直なところ Job Analysis のやり方は OPM が公開してくれている資料がめちゃめちゃわかりやすいので、そちらを参考にしていただけるのが一番良いと思います。
この記事の最後に、参考になるリソースをまとめてあるので、ぜひご確認ください。

とはいえ、Job Analysis について日本語でアクセスできるリソースが殆どないのも問題なので、拙いながらも僕がまとめたものを以下に記載します。

用語の定義

  • Task: その職務についている人が職務を遂行する上で定期的にやる活動
  • Competency: 職務を遂行し、成功する上で必要となる知識・スキル・行動などのパターン
  • SME: その職について詳しい人。Subject Matter Expert。スクラム採用における「現場メンバー」に対応する概念だと僕は考えています。

ざっくり5ステップ

  1. 対象の職務に関する情報を集める
  2. その職務で遂行する Task をできる限り洗い出す
  3. その職務で必要となる Competency をできる限り洗い出す
  4. Task と Competency について頻度や重要度などでスコアリングし、スコアが高いものを抽出する
  5. 4で残った Task と Competency を紐付け、実際に残った能力がタスクを遂行する上で必要だと示す

ざっくり、1~3 がブレストでいう発散段階、4~5 が収束段階に対応しているのが見て取れるかと思います。

2~5 用の spreadsheet テンプレ を用意してあるので、よければご利用ください。

以下、各ステップについて詳細に説明していきます。

1. 対象の職務に関する情報を集める

事前に職務に関する情報がある場合は集めておきましょう。
情報の例としては、これまでに公開されている求人票の内容・現場メンバーへのインタビュー・社内評価で用いている基準、などがあります。

HERP はまだ歴史の浅い企業のためこのような情報があることは少ないので、実際にこのステップをやったことはないです🙇 2から始めることが多いです。

2. その職務で遂行する Task をできる限り洗い出す

その職務でやっている Task を洗い出します。どうせ後でスコアリングして減らすので、現段階では数を多く出すのを目指しましょう。

以下を意識すると良いとされています。

  • 「何を、誰に/何に、何のために、どうやってやる」の形式で書く
  • 不要と思われる言葉を削る
  • 複数に分割できそうなタスクは分割する
  • 過度にスペシフィックな記述は避け、適度に抽象化する
  • 主観的な形容はなくす
  • 専門用語は省く

OPM のスライドで挙げられていた例がわかりやすかったので紹介します。

  • 悪い例： 自身の監督下にある人物がNFCシステムで報告した勤務時間に間違いがないか確認するために誠実な努力を行い、必要に応じてリソースとして毎日の作業の概要シートと突き合わせ、時間報告および給与のシートに署名し、勤務時間の支払い期間の期限前に給与部門に転送する。
  • 良い例： 従業員の労働時間報告を監査する。

良い例くらいシンプルで分かりやすい Task に落とし込めるのが理想です。

参考までに、弊社の Web frontend エンジニアの Job Analysis では以下のような Task が数十個洗い出されました。

  • Cycle.js を用いてフロントエンドの実装を行う
  • 進捗を報告する
  • 他の人が書いたコードをレビューする
  • などなど……

3. その職務で必要となる Competency をできる限り洗い出す

今度は Competency を洗い出します。これもまずは数を多く出すのを目指しましょう。

以下を意識すると良いとされています。

  • 簡潔で明瞭にする
  • Task とごっちゃにならないよう気をつける
  • 行動に基づくものにする
  • 「〜に関する包括的な知識」や「〜に関する基礎知識」のような、曖昧で測れないものにしない

Job Analysis の中で、このステップがおそらく一番難しいです。 HERPでは、 Competency を1から書く方法と、OPMが公開している一般的な Competency のリストから自社にも適用できそうなものを抽出する方法を組み合わせています。

とはいえ自社でも上手く出来てる自信がないので、実際に Job Analysis をやってみた方がいらっしゃたらうまいやり方について議論したい……！！

4. Task と Competency について頻度や重要度などでスコアリングし、スコアが高いものを抽出する

Task, Competency それぞれについて、業務知識を持っている複数の現場メンバーが以下の観点からスコアリングします。

  • Task を頻度・重要度（職務を成功させる上でどれくらい重要か？）で点数をつける。
スコア 頻度 重要度
0 行われない 行われない
1 数ヶ月か数年に1回 重要でない
2 数週間に一回 そこそこ重要
3 数日に一回 重要
4 数時間に一回 結構重要
5 1時間に何度も 超重要
  • Competency を重要度・エントリーレベルでの必要性・差別化要因になるか（その Competency を持つ人が、普通のレベルの人にくらべてどれくらい価値があるか）で点数をつける。
スコア 重要度 エントリーレベルでの必要性 差別化要因になるか
0 いらない いらない ならない
1 重要でない 初日に必要になるはず 価値がない
2 そこそこ重要 3ヶ月以内の経験で習得できるはず そこそこ価値がある
3 重要 4-6ヶ月以内の経験で習得できるはず 価値がある
4 結構重要 6ヶ月以降の経験でしか習得できなさそう 結構価値がある
5 超重要 - 超価値がある

複数の現場メンバーによる評価が済んだら、適当な加重平均を取ります。
例えば、リードエンジニアは平のエンジニアに比べて業務知識が豊富な可能性があるので、スコアへの反映度を2倍にするなどの方法があります。

全 Task、全 Competency について加重平均が算出できたら、点数が高いものを抽出します。
OPM によると、Task については両方のスコアが3以上、Competency については重要度と差別化要因が3以上・エントリーレベルでの必要性が2以上のもののみ抽出するのが推奨されています。

5. 4で残った Task と Competency を紐付け、実際に残った能力がタスクを遂行する上で必要だと示す

最後に、重要な Task がどの Competency を必要としているのかまとめます。

重要な Task のはずなのにどの Competency にも紐付いていない場合、Competency がおそらく足りていません。
逆に、重要な Competency とされているのにどの Task にも紐付いていない場合、実はその Competency は重要でない可能性があります。

このステップによって Job Analysis のアウトプットが妥当なものであると保証できるので、おろそかにしないようにしましょう。

Job Analysis をやってみた結果

Job Analysis をやっている企業は日本にまだそんなにないと思うので、実際にやってみてどうだったかを共有したいと思います。

良かったところ

まず、アウトプットされた Task・Competency の納得感がすごいです。

例えば、Job Analysis をする前は弊社が使っているフレームワークを使えることの優先順位が高いとされていました。
ですが、実際に Job Analysis をしてみると、それよりも 触れたことのないフレームワークや言語に習熟する柔軟性や勉強のノウハウがあること が重要であるとわかりました。

また、この例からもわかるように、想定している人材要件が大きく変わるので、見極めの仕方をより有効なものに変えられます。
例えば上の例では、見極めの方法を弊社で使っているフレームワークを使えるかのテストではなく、知らない技術にどう対応するかの構造化面接に変更することができます（※実際にこのような選考をしているとは限りません）。

さらには、集客の方法やオンボーディングも変わりました。
人材要件定義という根本的な戦略部分を改善すると、採用や人事制度に対するインパクトがやはり大きいです。

1つの職務に対して行った Job Analysis の結果のうち、いくつかは近いポジションや会社全体に求められるスキルとして共通化できることもわかりました。
例えばコードレビューのような Task は Web frontend エンジニアのみならず全てのエンジニアで共通だったり、柔軟性のような Competency は会社全体で共通だったりします。
なので、まずどれか1つの職務に対して試しに Job Analysis をしてみて、その後他の職務に対して同じものや違うものを見つけていくのがよいかと思います。

難しかったところ

上記にも書いたとおり、Competency を書くのが難しいです。
Competency さえ良いものを出せれば良い人材要件ができるとは思うのですが、どのようなものが良い Competency なのか、どのようなフローでやれば良い Competency が書けるのかはまだ模索状態です。
ひとまず OPM の公開しているリストから選ぶのは割と良いと感じていますが、とはいえもっといい方法もありそうなので、今後良い方法があったらまたまとめたいと思います。

また、5ステップでできるとはいえ、ちゃんとやろうとすると結構手間がかかります。
特に洗い出しとスコアリングは現場メンバーが大量に出して大量にスコアリングしないといけないので、必然的にこの活動に時間を割いてもらう必要が生じます。
スクラム採用ではこのように現場メンバーの時間を割かせることになるので、それをサポートする仕組みが必須です。

それから、見極め対象になりうる Competency としてリストアップされるものはあくまでスキルであり、カルチャーマッチなどのよりソフトな部分に対しては使いづらいように感じました。
カルチャーマッチは必ずしも Task と紐付かず、組織として定義したカルチャーや Value から落とし込まれるものなので、 Job Analysis とは相性が悪いのかもしれません。

まだわからないところ

HERPでは今のところ、業務内容がはっきりしているポジションやある程度業務知識が溜まっているポジションから Job Analysis を進めています。
今後業務知識に乏しい職務について Job Analysis をする際には、おそらく社内の現場メンバーだけでは知識が足りなくなるので、その際にどう Job Analysis を進めると良いかは考える必要がありそうです。

また、OPM の文書でも指摘されている通り、Job Analysis は1度やれば完成するものではありません。
経営戦略の変化や組織構造のなどによって、職務内容は当然変化しうるためです。
HERP でも同一職務に対して複数回 Job Analysis をした経験はないので、どう更新していくのかは今後考えていきたいです。

おわりに

まとめは上に戻って tl;dr を見てください🙏

結構長くなってしまいましたが、ここまで読んでくださった方はありがとうございました。
読んでない方も、Job Analysis のリファレンス的にこの記事を使ってくだされば幸いです。
上述の通り、まず1職務に対して Job Analysis を行ってみるとその便利さがわかると思いますし、向いていなさそうだったらやめれば良いので、とにかくやってみてください！！

やや余談ですが、Job Analysis を HERP で導入するにあたって、この手法を導入することを提案したのは現場メンバーの僕でした。
業務時間の10~20%を採用に割いて良いことなどスクラム採用を支援する制度が整っているからこそできた取り組みだと思っています。
イントロで触れた「現場メンバーが採用に積極的に関わるとはどういう状態なのか」について、この記事を通してなんとなく思い描いていただければ嬉しいです。

明日は HERP COO の徳永の記事です。お楽しみに！

参考文献・おすすめリソース

*1:これまでの採用担当が、採用のドメイン知識を持っている Project/Product Manager として働くすがたのこと。

*2:現場メンバー内で責任者を立てる手法自体もとても有効と考えていますが、それはまた別の機会に紹介するかも？

*3:採用における戦略・戦術という言葉は Nyle ワタナベさんが使っていらっしゃって、気に入ったのでパクりました。とてもいい記事です。Webマーケで”ユーザー体験”にこだわってきた人事が、採用活動について考えてみた｜ワタナベ シンペイ｜note

*4:ワタナベさんのScrum Recruiting Labo 分科会#1_Nyle LT - Speaker Deckの資料より