「現在地14%」をどう算出したか – フロントエンド転向のスキル可視化メソッド

このシリーズは全3本構成です。

  1. 現在地14%を可視化する(提示編)
  2. 本記事 — 算出ロジック編
  3. コーダー経験は他の路線に転向しても5〜10%の損失で済む話(応用編)
目次

はじめに

別記事で「フロントエンド転向の現在地14%」という数字を出しました。書き終えてから自分で読み返したとき、「なんで5%なの?10%でもいいんじゃない?」というツッコミが頭の中で起きました。

数字を出すからには根拠を曖昧にしないほうがいい。そう思って、算出方法を分解してこの記事にまとめました。同じやり方を使えば、フロントエンド以外のキャリア(バックエンド・インフラ・デザイナー転向など)にも応用できるはずです。

メソッドは大きく3ステップです。

  1. ゴール100%を採用要件から定義する
  2. 100%をスキル領域に配分する
  3. 各領域で自分が何%取れているかを評価する

順に書いていきます。

ステップ1:ゴール100%を何に置くか

最初のステップは「100%の定義」です。ここを曖昧にすると、後の数値化がすべてぶれます。

自分の場合は、

Web系受託(モダンフロントエンド)で Junior Frontend Engineer として採用される水準

を100%にしました。

なぜこれを基準にしたかというと、

  • 自分の現実的なゴールがここにあるから(フリーランスからの転向・年収目線・リモート可など)
  • 採用基準が比較的明示されている職種なので、求人票や採用記事から要件を逆算しやすいから
  • 「シニアエンジニア」や「Web系自社サービス」だと100%の定義が広がりすぎてブレるから

ここでブレると、自分がどこに向かっているか分からなくなります。「採用される水準」という具体的なゴールに固定したことで、後の配分がやりやすくなりました。

ステップ2:100%をスキル領域にどう振り分けたか

次に、100%を5つのスキル領域に配分します。

領域 配点 内訳の例
マークアップ・スタイリング 15% HTML / CSS / レスポンシブ / アクセシビリティ
JavaScript / TypeScript 25% ES6+ / 型定義 / 非同期処理 / モジュール
モダンFEフレームワーク 25% React / Next.js(App Router)/ 状態管理
開発周辺 20% Git / テスト / CI/CD / 設計
ビジネス・ヒューマンスキル 15% 要件理解 / コミュニケーション / 納期管理

配点の根拠は、自分が応募候補にしている中小〜中堅の Web 制作会社・受託開発会社の求人票を10件ほどサンプリングして、

  • 「必須」とされている項目に重みを置く
  • 「歓迎」項目は配点を下げる
  • 出現頻度の高さで重みづけする

という決め方をしました。

ここでの注意点として、この配分はあくまで主観的なサンプリング結果だということです。100社調べれば配分は変わるはずですし、応募する企業の規模や種類によっても比重は動きます。「自分のゴール周辺の現実値」として割り切っています。

ステップ3:各領域の中で自分が何%取れているか

最後に、各領域の中で自分が今どれくらいカバーできているかを自己評価します。

マークアップ・スタイリング(15点満点 → 自己評価 5点)

HTML / CSS の実装力は領域内のほぼ全範囲をカバーできています。BEM・FLOCSS・SCSS も実務で使ってきました。

ただし、アクセシビリティ(WCAG 2.1 対応)やパフォーマンス最適化(Core Web Vitals)まで詰めた経験はないので、「マークアップ枠の中でも上位層」とまでは言えない。半分くらい、というのが正直なところです。

JavaScript / TypeScript(25点満点 → 自己評価 0点)

実務での使用がほぼなく、入門書レベルで止まっています。

ここがゴールまでの最大ギャップです。ここに着手しない限り「フロントエンド候補」とは見なされない領域なので、これからの半年で重点投資する場所になります。

モダンFEフレームワーク(25点満点 → 自己評価 0点)

React も Next.js も触ったことがありません。教材は選定済み(公式チュートリアル+Udemy)ですが、実装経験ゼロ。

JS / TS と合わせて、ここの50%が現状の白地図です。

開発周辺(20点満点 → 自己評価 3点)

Git の基本操作(commit / branch / push / PR)は問題ないレベルです。

ただし、チーム開発のブランチ戦略・コードレビュー文化・テスト・CI/CD パイプライン構築などはまったく未経験。「Git は使える」と「チーム開発の Git ができる」は別物だと感じていて、控えめな数字にしています。

ビジネス・ヒューマンスキル(15点満点 → 自己評価 6点)

クライアント対応・要件ヒアリング(4点)と、案件納品の実績(2点)で6点。

残りの9点は、チーム内コミュニケーション・スクラム的な開発文化への適応・非同期コミュニケーションなど、これからの実体験で埋めていく領域です。

合計14%の意味

5 + 0 + 0 + 3 + 6 = 14%

これが「Junior FE に必要なスキル全体のうち、約14%は既に自分の中にある」という解釈になります。

ここから残り86%、特に JS/TS と React/Next.js の50%を埋めていくのが半年プランです。ゼロからではなく、14%地点からのスタートラインだと思うと、学習計画が現実的に立てられるようになりました。

このメソッドの限界(正直なところ)

メソッドと言っていますが、配点も自己評価も主観の塊です。なので、限界は3つあります。

配分が主観

求人票サンプリングと自分の解釈が入っているので、客観的な指標ではありません。応募する企業の規模・分野・地域によって配分は変わるはずです。

自己評価バイアス

自分のスキルを高く見積もりがち、または逆に低く見積もりがち、という偏りは必ず入ります。できれば現役エンジニアやメンターに見てもらうと精度が上がるはずですが、そこまでやっている人は少ないと思います。

「14%」という数字自体に意味はない

ここが大事なところで、数字の絶対値そのものに意味はありません。

12%でも18%でも、結論は同じです。「ゼロではない」「残りで何を埋めるべきかが見える」「ステップに分解できる」。この3つさえ得られれば、メソッドの目的は果たせています。

このメソッドは他のキャリアにも使える

3ステップ(ゴール定義・領域配分・自己評価)はフロントエンド以外でも組めます。

  • バックエンド転向なら → Junior Backend Engineer の採用要件から逆算
  • デザイナー転向なら → Junior UI Designer の採用要件から逆算
  • データ職種転向なら → Junior Data Engineer の採用要件から逆算

重要なのは順序で、「ゴール側を定義してから、自分側を測る」ことです。

多くの人(少なくとも以前の自分)は「自分は何ができるか」から考え始めて、ゴール側を曖昧にしたまま走り出してしまいます。すると「自分にできることをやり続ける」だけになって、ゴールから遠ざかっていることに気づけないことがある。ゴールを先に定義することで、それを防げます。

まとめ:数字は心理的な道具・ゲーム感覚で埋めていく

「現在地14%」は、5領域配分+自己評価で算出した、主観の塊です。客観指標ではありません。

それでも、この記事を書こうと思ってから気づいたことがあります。数字にすると、ゲーム感覚で埋めていくプロセスが楽しくなるということです。

RPG の経験値ゲージを進めるような感覚で、「次は React チュートリアルを完走したら +5% かな」「ポートフォリオ1本完成したら +10%」みたいに、進捗が可視化されます。漠然と「学習しなきゃ」と思って動くより、ずっと手が動きます。

数字そのものは飾りでも、ゲージを進めていく行為は本物です。これが、心理的な道具として数値化が効く理由なのかもしれません。

転向を考えている方が同じ方法を試してみるなら、

  1. ゴール100%を採用要件から定義
  2. 100%をスキル領域に配分
  3. 自分のスコアを正直に当てはめる

の順で30分くらいでできます。出てきた数字に一喜一憂するというより、ゲージを進めるための地図として使うのがおすすめです。

転向先を変えたときに既存資産がどれくらい転用できるかという話は、シリーズ3本目「コーダー経験は他の路線に転向しても5〜10%の損失で済む話」にまとめています。

written by 松尾|フリーランスWebコーダー

コメント

コメントする

CAPTCHA


目次