職務遂行に必要なタスクとスキル・経験を徹底的に定量分析する「Job Analysis」でチームが求めるエンジニア像を可視化してみた

職務遂行に必要なタスクとスキル・経験を徹底的に定量分析する「Job Analysis」でチームが求めるエンジニア像を可視化してみた

「Job Analysis」というOPM(米連邦政府人事管理局)が採用している職務分析手法を用いて、チームが求めるエンジニア像を定量的に可視化して募集要項を作って見ました
Clock Icon2024.08.06

こんにちは。リテールアプリ共創部のきんじょーです。

私は今、新規案件の立ち上げを専門としている「マッハチーム」でサーバーサイドエンジニアをしています。
チーム発足から 1 年ほど経過し、新たなチームを発足するためにフロントエンド、サーバーサイドエンジニアの採用に力を入れています。

採用関連の整理を進める中で、チームが求めるエンジニア像を可視化するために「Job Analysis」というワークを行いました。
その結果、求める人物像の可視化を非常に定量的に進められ、納得感のある採用基準、募集要項、面接課題を作成することができました。

今回はエンジニア採用目的のために「Job Analysis」を実施しましたが、現状の業務内容の可視化や、評価制度やキャリアパスの設計など、さまざまな目的で活用できるワークでした。そのあたりに課題を感じている方へ向けて、このブログでご紹介します。

記事後半にマッハチーム採用情報のお知らせも含んでいます。
クラスメソッドでエンジニアとして働くことに少しでも興味のある方も、ぜひ読んでみてください!

Job Analysis とは

OPM(米連邦政府人事管理局)が採用している職務分析手法です。OPM とは日本で言うところの国家公務員の人事管理を担当する人事院のような組織で、米連邦政府の人事制度を管理しています。

「Job Analysis」を実施することで、職務を遂行するために定期的に行う活動(Tasks)と、それを遂行するための能力・スキル・知識(Competencies)を定量的に洗い出すことが可能です。

Google の re:Workでも有効な手法として取り上げられており、求める人物像を可視化するワークとして活用してみました。

用語の定義

先に Job Analysis を進める上で出てくる用語を説明します。

  • Tasks
    • 従業員が職務を遂行するために定期的に行う活動
  • Competencies
    • 個人が職務や職業機能をうまく遂行するために必要な知識、スキル、能力、行動、その他の特性の測定可能なパターン
  • Subject Matter Expert(SMEs)
    • 分析対象の仕事についての専門知識を持つ人
  • Ratings/Cutoffs
    • 仕事を成功させるために必要なタスクと能力を決定するための評点と閾値

Job Analysis の進め方

まず、職務を遂行するために定期的に行う活動(Tasks)と、それを遂行するための能力・スキル・知識(Competencies)を洗い出します。

洗い出した Tasks と Competencies に対して、業務の専門家(SMEs)が後述する尺度でレーティングを行い、結果を集計して募集職種が行うべき Tasks と Tasks 遂行のための Competencies を定義します。

ブレストして点数をつけて集計する、という流れで、それほど難しいことはありません。

やってみた

ここからは実際に Job Analysis を進めた内容を、OPM が提供する Tips を交えてご紹介します。

① タスク の洗い出し

まず初めに、チームで働くサーバーサイドエンジニア、フロントエンドエンジニアが普段行っている業務を洗い出しました。(一部抜粋)

その結果、マッハチームの場合、以下のようなタスクを普段の業務で遂行していることがわかりました。

image-2.png

タスク の洗い出しには以下のポイントに注意しながら進めました。

  • 5W1H に沿って以下のようなフォーマットでタスクを洗い出す
    • 何を、誰 or 何に対して実行するか?
    • なぜ実行するか?
    • どのように実行するか?
  • 簡潔に記述する
    • 必要最低限の要素に削ぎ落として、できるだけ簡潔かつ明確に記述する
  • 2 つ以上のタスクを 1 つのタスクとして記述せず、適宜個別のタスクに分割する
  • 過度に具体的な書き方は避けること
  • 曖昧、または不明瞭な用語、主観的な形容は避ける
  • 略語は避けて、誰が見ても項目が理解できるように記述する

OPM の説明にあった以下具体例もわかりやすかったです。

  • 簡潔に記述する
    • ❌ Excel を使用して部下のタイムカードを加算、減算、 除算し、勤務時間と休暇を計算する
    • ⭕️ スプレッドシートを使用して給与と 休暇を追跡する
  • 過度に具体的な内容や略語は避けて、誰が見ても項目が理解できるように記述する
    • ❌ NFC システム内で請求された追加および時間に関するエラーについて、 自身の監督下にある人物について報告し、必要に応じて毎日の作業概要シートをリソースとして使用し、時間レポートおよび/または 給与計算シートに署名し、勤務時間の支払いを承認するために支払い 期間の締め切り前に給与部門にルーティングします。
    • ⭕️ 従業員の勤務時間レポートを監査します。

② コンピテンシーの洗い出し

次に、洗い出したタスクを遂行するにあたり必要なコンピテンシーを洗い出しました。(一部抜粋)

image-3.png

コンピテンシーは複数のタスクで共通するものもありますが、レーティング集計時にサマリーするため、ここでは重複は意識せずブレインストーミングしていきました。

OPM によると、コンピテンシーを洗い出す際は以下のポイントに注意が必要です。

  • タスクと混同するような方法で記述しない
    • 「(タスクを実行する)能力」のような書き方は避ける
  • 不要な修飾語を削除する
    • 十分な知識、かなりのスキル、基本的な理解などは避ける

③ タスクとコンピテンシーのレーティング

ここまでは、タスクとコンピテンシーのブレストを実施するフェーズでした。
ここからはチームが求める人材に本当に必要とされるタスクとコンピテンシーを定量的に評価するために、レーティングを実施していきます。
分析対象業務のエキスパート(Subject Matter Experts)として、私を含め 3 名のマッハチームのエンジニアでレーティングを行いました。(一部抜粋)

image-5.png

レーティングの基準と尺度については OPM が推奨する以下の指標に従いました。

タスクの評価尺度

OPM によると、頻度と重要度の 2 軸でタスクを評価することが多いそうです。

  • 頻度
    • 0 = 実行しない
    • 1 = 数か月ごとから毎年
    • 2 = 数週間から毎月
    • 3 = 数日から週に 1 回
    • 4 = 数時間ごとから毎日
    • 5 = 1 時間に何度も~1 時間に 1 回
  • 重要度
    • 0 = 実行しない
    • 1 = 重要ではない
    • 2 = やや重要
    • 3 = 重要
    • 4 = とても重要
    • 5 = 非常に重要

コンピテンシーの評価尺度

コンピテンシーは、以下 3 つの軸で評価します。

  • 重要性
    • タスクを実行するためにその能力がどの程度重要かを測る指標
    • 評価尺度
      • 1 = 重要ではない
      • 2 = やや重要
      • 3 = 重要
      • 4 = とても重要
      • 5 = 非常に重要
  • 入社時に必要かどうか
    • いつまでに身につければ良いかを測る指標
    • 評価尺度
      • 1 = 初日に必要
      • 2 = 最初の 3 か月以内に取得する必要があります
      • 3 = 最初の 4~6 か月以内に取得する必要がある
      • 4 = 最初の 6 か月後に取得する必要があります
  • 抜き出た価値の重要度
    • 優秀な人と平凡な人の差を区別することがどれだけ価値があるかを測る指標
    • 例を挙げると、顧客対応業務における「コミュニケーション能力」と「タイピング速度」を例に挙げた場合、前者は業績に大きく影響し、後者は一定以上のスキルがあれば業務上問題ない
    • 評価尺度
      • 1 = 価値がない
      • 2 = やや価値がある
      • 3 = 価値がある
      • 4 = とても価値がある
      • 5 = 非常に価値がある

④ 結果の集計

レーティング結果を元に結果を集計する前に、3 名の SMEs の回答で内容に大きくバラツキがあった項目については、レーティング内容の意図について事前に認識を合わせました。

その後は以下の手順で、チームの業務遂行に必要なタスク・コンピテンシーと、そうではないタスク・コンピテンシーの線引きを行いました。

タスクのカットオフスコア計算

  1. 重要でないと評価されたタスクを削除する
    1. SME の少なくとも半数が、重要でないと判断したタスクは削除する
  2. 残ったタスクの平均評価スコアを算出する
    1. 平均計算の際に 0=実行しないは除外する
  3. 推奨するカットオフスコアは、重要度と頻度で両方とも 3.0 以上とする

コンピテンシーのカットオフスコア計算

  1. 重要度は 3.0 以上のタスクを採用する
  2. 入社時に必要かは 2.0 以下のタスクを採用する
  3. 抜き出た価値の重要度は、3.0 以上を推奨とする

この時、採用されなかったタスクにしか紐付いていないコンピテンシーは除外します。

採用基準を策定する観点では、「2. 入社時の要否」 で採用されたコンピテンシーを「入社時に必須のスキル・経験」とし、それ以外の「1. 重要度」で採用されたコンピテンシーを「歓迎するスキル・経験」として定義しました。
採用・不採用を決めるカットオフスコアはあくまでも目安として使用し、最終的な取捨選択は SME による判断としました。

求める人物像へまとめる

レーティングとカットオフを行い、採用されたコンピテンシーを求める人物像としてまとめたものの一部抜粋です。

スクリーンショット 2024-08-06 12.01.09.png

完成した募集要項

上記をより簡潔にまとめて募集要項に落とし込みました。

https://careers.classmethod.jp/requirements/mach-frontend-enginner/

https://careers.classmethod.jp/requirements/mach-serverside-enginner/

Job Analysis をやってみて

一緒に働くエンジニアの方に求める期待値を、定量的な根拠をもとに可視化することができ、納得感のいく採用基準、募集要項、そしてそれを測る面接課題を作成することができたと感じています。
一方で、基準には適合しないがチームに大きな価値をもたらしていただけるような応募者の方を見落とさないように、今回策定した基準は目安として、柔軟に対応することの必要性も議論に上がりました。完成した定量的な分析結果はあくまでも基準とし、採用の場では応募者の方と向き合って総合的なマッチングを意識していきます。

採用目的はもちろん、現状の業務内容の可視化や、評価制度やキャリアパスの設計のため、現行業務内容と遂行するためのスキル・経験を可視化したい方は、ぜひ今回ご紹介した「Job Analysis」というワークを活用してみてはいかがでしょうか?

Job Analysis については以上です。
最後に、エンジニアの方向けに少しだけリテールアプリ共創部「マッハチーム」の採用情報のお知らせをさせてください!

エンジニアの方向けのお知らせ

リテールアプリ共創部「マッハチーム」とは

DevIO2024_Tokyo_キャリアディスカバリー_リテールアプリ共創部マッハチーム (4).png

我々リテールアプリ共創部では、クラスメソッドの持つアプリ開発、クラウド、UI/UX 設計、SaaS 活用といった専門知識 と、お客様のビジネスの深い理解を組み合わせて、新たな価値を「共創」 することをミッションとしています。

DevIO2024_Tokyo_キャリアディスカバリー_リテールアプリ共創部マッハチーム (3).png

クラスメソッドでは主に「クラウド」、「分析・データ活用」、「デジタル施策」の 3 本の柱で事業を展開しています。リテールアプリ共創部は「デジタル施策」として、toC 向けのアプリ開発をメインにクライアントワークを行う部署です。

ほぼすべての案件がお客様との直契約で、案件の割合としては LINE 関連のアプリ開発が一番多く、それ以外にも Web アプリやネイティブアプリの開発も行っています。

① マッハチーム発足のきっかけ

クラスメソッドは AWS やブログの会社のイメージをお持ちの方が多いと思います。
しかし、創業当初は Adobe Flex の技術を得意とした受託開発を事業の中心としており、実はバリバリの開発会社でもあります。

開発案件の立ち上げフェーズにはさまざまな課題があります。

DevIO2024_Tokyo_キャリアディスカバリー_リテールアプリ共創部マッハチーム (1).png

アサイン計画に頭を悩ませたり、プロジェクト開始前のチームビルディング・キャッチアップに時間を要してしまうと、お客様の課題解決・価値創造という本質的な仕事に集中できず、プロジェクト立ち上げフェーズでなかなか進捗が出ない問題がありました。

これらの問題に対するひとつの答えとして、プロジェクト立ち上げを専門とするためのチームとして「マッハチーム」を発足しました。

② チームの特徴

DevIO2024_Tokyo_キャリアディスカバリー_リテールアプリ共創部マッハチーム (2).png

1 チームあたり 4〜5 名(PM1 名/エンジニア 2〜3 名/デザイナー 1 名)の固定チームで、プリセールスから納品までを一貫して行うことが特徴です。
固定チーム制により、前述したアサインとチームビルディングの課題を解消し、プロジェクトに「人」ではなく「チーム」をアサインする方式をとっています。

この方式を取るようになり、プリセールから納品まで同じメンバーできることで、お客様との信頼関係を築きやすくなりました。
また、案件終了後の振り返りを次のプロジェクトでも忘れずに活かすことができるため、学びの消失を防ぐことができます。

③ マッハチームの目指すところ

image.png

マッハチームはプロダクト開発の立ち上げを高速に高品質で安定的に遂行することで、クラスメソッドと一緒に仕事がしたいとお客様に思っていただけるような信頼関係を高速に築き上げることをミッションとするチームです。

働き方

① 開発プロセス

DevIO2024_Tokyo_キャリアディスカバリー_リテールアプリ共創部マッハチーム (5).png

プロジェクト開始後の 1〜2 週間でがっつり要件定義を行いスコープを固めた後は、1 週間スプリントでアジャイルに開発を進めていきます。
受託開発という案件の性質上、あらかじめ開発スコープは握っておきながら、MVP を早い段階でお客様に確認していただき、フィードバックを迅速にプロダクトに反映するサイクルを回すため、ウォーターフォールとアジャイルを組み合わせたような開発プロセスが特徴です。

プリセールスから UI/UX 設計、設計・開発とすべてのフェーズでエンジニアが入るので、エンジニアの立場からプロダクトの方向性を提案することも可能です。

② 技術スタック

DevIO2024_Tokyo_キャリアディスカバリー_リテールアプリ共創部マッハチーム (6).png

LINE ミニアプリ開発においては、サーバーサイドはサーバレスアーキテクチャを採用し、フロントエンドは React で、フロントエンド、サーバーサイド、インフラ(AWS CDK)をすべて TypeScript で書くことが多いです。
LINE ミニアプリ開発といっても、実態は LINE プラットフォーム上で動く Web アプリ開発になるため、フロントエンド、サーバーサイドともに Web で使用する技術を使用します。

こんな方にオススメです

DevIO2024_Tokyo_キャリアディスカバリー_リテールアプリ共創部マッハチーム (7).png

サーバレス、コンテナ、IaC、CI/CDが当たり前の環境で、AWSをフル活用してモダンなフルスタック開発がしたい方にはぜひおすすめです!

プリセールス段階からエンジニアが入り、受注後もその案件をリリースまで担当できる点も魅力の一つです。
お客様やエンドユーザーにとっての本当の価値について、お客様も含めたチーム一丸となって検討し、プロダクトの方向性を提案することができます。

ゼロからイチを圧倒的なスピードで立ち上げる開発体験は単純にめちゃくちゃ楽しいです。さまざまな業界・お客様のご支援をマッハで回したい方、お待ちしています!

興味を持っていただけた方へ

クラメソのアプリ開発ってなんだか面白そうだなと、少しでも興味を持っていただけた方は、以下からのご応募お待ちしています!

https://careers.classmethod.jp/requirements/mach-frontend-enginner/

https://careers.classmethod.jp/requirements/mach-serverside-enginner/

いきなり応募フォームはハードルが高い・・!という方は、X や DM などでお気軽にカジュアル面談のお申し込みも可能です。@joe_king_shまでお気軽にご連絡ください!

以上、リテールアプリ共創部のきんじょーでした。

参考にさせていただきました

https://www.opm.gov/policy-data-oversight/assessment-and-selection/job-analysis/job_analysis_presentation.pdf

https://swimath2.hatenablog.com/entry/2019/12/16/014535

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.