求人票を書くとき、いちばん時間がかかるのはどこだと思いますか。
給与レンジでも、必須スキルの箇条書きでもありません。いちばん上の、職種名の1行です。
「エンジニア」だと広すぎて誰も刺さらない。「バックエンドエンジニア」だと、うちの仕事の半分が説明できない。「DX推進担当」と書くと、応募してくる人の想像と実際の仕事が確実にズレる。この1行を決めるのに、僕は毎回いちばん長く迷います。
その迷いに、今年の4月、国のほうから答えの一部が出ていました。8月になって、うちはまだそれを求人票に反映している最中です。国が職種の分け方をどう変えたのか、それを17人の会社がどう求人票に落としているのか。この2つを順番に書きます。
デジタルスキル標準ver.2.0で、4月に職種の地図が書き換わった
経済産業省が2026年4月16日に「デジタルスキル標準ver.2.0（DSS ver.2.0）」を公表しました。
まず前提から。デジタルスキル標準は、全ビジネスパーソン向けの「DXリテラシー標準」と、DX推進人材向けの「DX推進スキル標準」の2つで構成されています。2022年12月のver.1.0以来、2023年8月・2024年7月と改訂され、今回で4回目です。
もうひとつ。これは義務ではありません。法律でも規制でもなく、「個人の学習」と「企業の人材確保・育成」の指針です。「国が決めたから、うちもこう名乗ります」という話ではなく、外の人と話すときに使える共通語彙として使う。それが正しい距離感だと思っています。
その上で、今回の改訂で何が起きたか。「データマネジメント」という類型が、新しく1つ増えました。
なぜ「データマネジメント類型」が新設されたのか ── データエンジニアの引っ越しが意味すること
新設されたデータマネジメント類型には、「データスチュワード」「データエンジニア」「データアーキテクト」の3ロールが定義されました。
面白いのは、この新設に伴って、それまでデータサイエンティスト類型の中にいた「データエンジニア」が、そこから削除されてデータマネジメント側に移されたことです。
地味な移動に見えますが、意味はかなり大きいと思っています。
これまで「データ」の仕事は、分析する人（データサイエンティスト）の付属品として扱われていました。分析の手前でデータを整える人がいる、という構図です。今回それが、分析とは別の、独立した職種の集まりとして切り出された。
背景として経産省が書いているのは、AI活用が進む中で「データ整備や利活用を担う役割の重要性が一層高まっている」ということです。
僕はこれを、「AIの前工程が、独立した職種になった」という宣言として読みました。
以前触れた調査では、生成AIを業務で使う企業の担当者548名のうち、顧客情報や案件情報などの社内データが「整備されていない」と答えたのが50.7%でした。重複、欠損、表記ゆれ。AIがどれだけ賢くなっても、読ませるデータが濁っていたら、出てくる答えも濁ります。
受託の現場でも、最初に手をつけるのは新しいAIの選定ではなく、たいていこの掃除です。かっこよくないし、提案書の見栄えもしない。でもここを飛ばすと、上に何を載せても動きません。その仕事に、国が名前をつけた。そういうことだと思っています。
動いたのはデータだけじゃない ── ビジネスアーキテクトの3ロール刷新と、AIガバナンス
改訂されたのはデータマネジメントの新設だけではありません。原文を読むと、他にも3つ動いています。
ビジネスアーキテクト類型のロールが刷新されました。 これまでは「新事業開発」「既存事業の高度化」「社内業務の高度化・効率化」という担当領域による3分割でした。それが今回、「ビジネスアーキテクト」「ビジネスアナリスト」「プロダクトマネージャー」という3ロールに再定義されています。何を担当するかによる分け方から、どういう職能かによる分け方へ、軸が変わったわけです。
デザイナー類型も見直され、コミュニケーション領域のロールとして「コミュニケーションデザイナー」が置かれました。
そして僕が一番反応したのが、共通スキルリストの改訂です。データマネジメント関連スキルの追加に加えて、「AIの実装・運用」および「AIガバナンス」に関するスキルが追加されました。あわせて、既存のロールも含めて各ロールに求められるスキルの重要度そのものが見直されています。
AIガバナンスが「スキル」として名簿に載った。資格や研修を作るより前に、「誰がどこまで判断してよいかを決める仕事」が実在する職能として認められたということです。17人の会社でも、AIに何をやらせて何をやらせないかを決めているのは確実に誰かの仕事で、これまでその仕事には名前がありませんでした。
17人の会社が、求人票をどう書き直しているか
で、これを自社にどう落としているか。半年かけている、という話です。実際にやっているのは3つです。
1. 肩書きではなく「工程」で書く
「エンジニア募集」をやめて、その人が触る工程を先に書くようにしました。要件を聞くところから入るのか、設計からなのか、実装だけなのか、運用と改善まで見るのか。職種名は、その会社が仕事をどこで切っているかの表明なので、切り方を書いたほうが早い。応募してくる人の解像度も、明らかに上がりました。
2. 評価の軸を、社内用語から外部の共通語彙に寄せる
これは半分、社員のためです。社内だけで通じる等級名で評価していると、その評価はその人が会社を出た瞬間に価値がゼロになります。DSSの類型やロール名に寄せて評価軸を書き直しておけば、少なくとも「自分が何をできる人として評価されていたか」を、外に持ち出せる言葉で説明できる。
うちは17人しかいない会社です。「一生ここにいてくれ」と言うより、いつ出ていっても通用する言葉で評価するほうが、結果的に誠実だと思っています。
3. 兼務を隠さない
小さい会社では、1人が3つの類型をまたぐのが普通です。データを整えて、実装して、そのまま顧客と要件を詰める。以前はこれを恥ずかしいことのように感じて、求人票では1つの職種に丸めていました。今はやめました。またいでいることをそのまま書いたほうが、来てほしい人に伝わるからです。「広く触りたい人向け、決められた工程だけをやりたい人には向いていません」と正直に書くと、応募数は減りますが、話が早い人が来ます。
「職種名」ではなく「どの工程を触りたいか」で話せる会社を探している方へ
K.Platinumの募集も、まさにこの書き方でつくっています。
▶ エンジニア募集中 ── 募集職種・働き方・選考の流れを見る
類型は、説明のための道具であって、人を測る物差しではない
ひとつだけ、釘を刺しておきたいことがあります。
うちは17人中8人が高専出身です。15歳から手を動かしてきた人たちを見ていて思うのは、そういう人ほど、類型の枠から先にはみ出すということです。
データエンジニアの枠で採ったつもりの人が、気づいたら顧客の業務フローの設計まで一緒に考えている。プロダクトマネージャーの枠にいる人が、いちばん深くログを読んでいる。標準に沿って測ろうとすると、こういう人は必ず評価を取りこぼします。
だから僕は、DSSの類型を「外の人に自社の仕事を説明するための翻訳辞書」として使っています。人を格納する箱としては使わない。国が作ったのも、たぶんそういう道具です。指針であって、義務ではない。
まとめ ── 職種名は、申告書だ
求人票の職種名は、待遇の一部でも、飾りでもありません。その会社が仕事をどう分けているかの申告書です。「エンジニア」としか書けない会社は、たぶん本当に分けられていない。分けられていない会社に入ると、入った人は「思っていた仕事と違う」と言うことになります。
今回の話を4行にすると、こうなります。
- 経産省が2026年4月16日、DSS ver.2.0でデータマネジメント類型を新設（データスチュワード／データエンジニア／データアーキテクトの3ロール）
- データエンジニアはデータサイエンティスト類型から移された＝AIの前工程が独立した職種になった
- 共通スキルには「AIの実装・運用」と「AIガバナンス」が追加された
- ただしDSSは義務ではなく指針。人を測る物差しではなく、外に説明するための翻訳辞書として使う
うちはこれを、8月になってもまだ求人票に反映し切れていません。4ヶ月遅れです。でも、遅れてでも書き直す価値はあると思っています。
次に募集を出すとき、職種名の1行の前でまた長く迷うはずです。それは、うちの仕事の切り方がまだ動いているということなので、たぶん健全なことなんだと思います。
書いた人
沼田海斗／株式会社K.Platinum 代表取締役
沖縄高専出身。スタートアップITコンサルを経て24歳で起業し、現在3期目・27歳。ITコンサルティング、受託開発、プログラミングスクール「ジゴカツ」の3事業を、17名（うち高専出身8名）のフルリモートチームで運営しています。求人票の職種名を決めるのが、たぶん一年でいちばん時間を使っている作業です。
K.Platinumで働くことに興味がある方へ
うちの募集は、職種名ではなく担当する工程で書いています。要件を聞くところから、設計、実装、データを整えるところ、運用と改善まで。どこからどこまでを触りたいか、まずはそれを教えてください。
類型をまたぐのは歓迎です。というより、17人の会社なので、またがずに仕事を終えられる日はほとんどありません。逆に、決められた1工程だけに集中したい方には向いていない環境だと思います。
カジュアル面談から歓迎です。まずは話を聞くだけ、でまったく構いません。
▶ エンジニア募集中 ── 募集職種・働き方・選考の流れを見る