東京の小さなスタートアップ、エンジニアとプロジェクトマネージャーのスキル尺度をつくる

最初の設問は、一つの機能追加から始まる。新機能の実装を任されたとき、モジュールをどう分け、責務をどう切り離すか。回答は小さな階段になっている。動くコードを優先し構造化は後回しにする。責務を意識して分割し設計根拠を説明できる。さらに、システム全体の設計思想を持ち、ガイドラインと自動チェックで品質を仕組みにする。

コンパイラが回答を監視するわけではない。同僚がプルリクエストを開くわけでもない。受検者は、自分の仕事に近いと思う記述を選ぶ。画面は次へ進み、21問が終わると、普段はリポジトリ、障害対応、会議メモ、チームメートの記憶に分散している「自分の力」がレーダーチャートになる。

これがAI Nativeの「AI開発力スキル診断」だ。6月22日に公表され、9軸でエンジニアの強みと伸びしろを可視化するという。発表時は「約7分」、現在の公式ページは「21問・約10分」と書く。通常の表示更新かもしれないが、測る道具そのものも動いていることを示す小さな痕跡ではある。

登場のタイミングはよい。生成AIによって、もっともらしく動く試作品を作るハードルが急に下がった。その結果、難所が移った。重要なのはモデルに一回答えさせる人だけではない。AIを使うべき問題か判断し、挙動を定義し、失敗を評価し、展開し、変化を監視し、漏えいや被害を止められるチームである。

月齢で数えられるスタートアップ

AI Nativeの設立は2025年10月。本店所在地は渋谷区円山町である。坂と細い道が交わり、ホテル、音楽会場、小さなオフィスが道玄坂から流れる街の間に並ぶ。翌年6月の診断公開時、法人としての年齢は約8カ月だった。

同社はAIメディア、生成AIプロダクト、コンサルティング・開発を事業に挙げる。無料診断は三系統ある。全社員向けのAI活用診断、経営層向けの組織成熟度基準、そして今回の開発者向け診断だ。無料の診断は利用者を教育し、コンサルティングの入口を作り、見込み客が課題を表現する言葉を集められる。これらの目的は両立する。

若い会社が描いた割に、尺度の範囲は広い。プロンプトが書けるかだけを尋ねない。課題設定から運用まで、開発組織に考えさせる。土台は、エンジニアリング基礎、言語化・コミュニケーション、効率・ROI思考の3軸。その上に6つの専門軸を置く。

表の3列目は同社の公表内容ではない。語彙を、組織として説明可能な評価へ変えるにはどんな証拠が要るかを示した。ここが核心である。リストが正しい対象を挙げていても、点数が対象を正しく測っているとはまだ証明されない。

21問が実際に測っているもの

公式ページには結果を「客観視」できるという表現があるが、現在のフォームは構造化された自己申告である。第1問は3段階の行動記述を示し、迷う場合は直近のプルリクエストで設計理由を説明できるか考えるよう促す。「設計が得意ですか」より具体的で、記憶の中の仕事に回答を結び付ける工夫はある。しかし、その仕事自体を観察してはいない。

同社は、知識・設計力を表すCapabilityと実務経験のExperienceを分ける。この判断はよい。評価パイプラインを説明できても、深夜の障害で運用したことがない人はいる。逆に、ベンダーの基盤で複数システムを展開してきたが、設計を一般化して説明しにくい技術者もいる。知識と経験を一つの数字へ潰すべきではない。

ただし、9軸に対して21問では、同じ概念を別角度から確かめる設問の重なりは多くできない。信頼性の確認には通常、複数の独立した項目が役立つ。魅力的な選択肢を一つ選ぶ行為には、実力だけでなく、理想、寛大な自己解釈、流行語への慣れが入り込む。公開資料には、配点、設問作成法、信頼性、再検査、妥当性確認の標本、実務成績との比較がまだ示されていない。

だから無価値なのではない。正しい分類は、短時間の成長対話を始める道具である。22件のメタ分析を統合した研究では、能力の自己評価と客観的成績との平均相関は0.29だった。無関係ではないが強くもない。質問が具体的で、身近な領域ほど関係は強くなる。AI Nativeの具体的な記述は助けになるが、限界を消さない。

次の段階では、結果を三角測量すればよい。設計判断、小さな評価設計、障害対応の説明、実務サンプルを求める。同じ行動基準で上司や同僚にも、実際に見た行動を評価してもらう。情報源の差を調べ、実務後に再度見る。そうすれば点数は証拠の代用品ではなく、証拠を集める出発点になる。

小数点に隠れた分母

発表資料には目を引く結果がある。3月から6月の先行利用者では、「High」の割合が効率・ROI思考で88.6％、AIドメイン知識で85.7％、言語化・コミュニケーションと課題設定・要件定義で82.9％だった。「Low」が多かったのは運用保守の17.1％、品質保証とエンジニアリング基礎の14.3％だという。

試作品を考える人は多いが、本番で信頼性を保てる人は少ない――業界記事として魅力的な筋書きだし、現実味もある。NISTのAIリスクマネジメントフレームワークと生成AI向けプロファイルが、評価、監視、ガバナンス、ライフサイクル全体のリスクを重く扱うのも、一度動くデモが頼れるシステムではないからだ。

ただし、発表は標本数と募集方法を書いていない。小数点が手がかりになる。すべての割合は、分母35でぴたりと再現できる。31人なら88.6％、30人なら85.7％、29人なら82.9％、6人なら17.1％、5人なら14.3％になる。35の倍数でも同じ丸め値を作れるため、35人は公表事実ではなく算術的推定である。新サービスの「先行利用者」としては最も単純な読みだ。

ここから日本のエンジニア全体は推定できない。専門スタートアップの診断を早期に使う人は自己選択されており、AIへの関心が高い、会社に近い、自分をよく見せたいといった可能性がある。「High」「Low」は同社の基準による区分で、標準化された全国順位ではない。製品開発の手がかりにはなるが、労働統計ではない。

ダッシュボード以前、「技能を箱へ入れる」長い試み

仕事を測りたい願望はソフトウェアより古い。産業管理は仕事を観察可能な動作と時間へ分けた。職業資格は、実務家が持つべき知識を示そうとした。どの時代にも、上司一人の勘から独立した言葉で技能を記述できれば、比較し、教え、配置を考えられるという約束があった。

1980年、ヒューバートとスチュアートのドレイファス兄弟は技能獲得を段階として説明した。初心者は文脈から離れた規則に頼る。経験を重ねると、何に気づき、状況をどうまとめ、どう決めるかが変わる。後に「初心者から熟達者まで」の5段階として広く知られた。大切なのは呼び名より、専門性は事実の在庫が増えるだけではなく、具体的事例から作られる知覚と判断だという点である。

プロジェクトマネジメントは別の道から職業を定義した。計画と日程の共通問題を話す場を求めた実務家により、Project Management Instituteは1969年に生まれた。最初のPMP試験は1984年、受験者56人、合格43人。建設、エンジニアリング、防衛、事業に散らばっていた仕事は、共通の知識体系と資格を持った。

デジタル職には、個別製品より長生きする地図が必要だった。1980年代からの共同作業を源流に、SFIAは2000年に正式発足。専門技能と7段階の責任レベルを組み合わせた。現行の言葉は「従う」から「戦略を定め、鼓舞し、動員する」まで進む。重要なのは、SFIAが実務で示した技能をコンピテンシーとする点だ。知識だけを試す資格では、経験や責任の水準を示せない。

これらは別の問題を解く。ドレイファスは学習の理論、PMPは職業資格、SFIAは技能と責任の参照言語、スタートアップの診断は内省とサービス発見のための速い画面である。一種類を別の種類として使ったとき、混乱が始まる。

ITSSからDSS 2.0へ、日本の道筋

日本には、デジタル技能を尺度にしてきた明確な公的歴史がある。国際競争、オフショア開発、高度人材育成への懸念から、経済産業省は2002年にITスキル標準を策定した。後の体系は、すべてを「SE」「プログラマ」で包まず、11職種、35専門分野、能力と実績に基づく7段階を定め、SFIAも参考にした。

ITSSは、コンサルタントやITスペシャリストと並び、プロジェクトマネジメントを職種に含めた。キャリア、経験、研修を結ぼうとした。一方、IPA自身は、スキル標準は人材育成の「ものさし」にすぎず、個々の力を有用なサービスへ統合する戦略がなければ競争力にならないと注意した。レーダーチャート時代のために書かれたような警告である。

2014年のiコンピテンシ ディクショナリは視点を変えた。ITを使う事業が行うタスクと、それを支えるスキル・知識をそれぞれ辞書にした。組織は戦略と仕事から出発し、不足に合わせて育成を設計できる。全員へ一つの「選手能力値」を付けるより、組み替え可能な辞書だった。

DXによって対象はITベンダーの外へ広がった。2022年12月、経産省とIPAはデジタルスキル標準を公開。全ビジネスパーソン向けのリテラシー標準と、変革を担う専門人材向け標準からなり、ソフトウェアエンジニアをビジネスアーキテクト、デザイナー、データサイエンティスト、サイバーセキュリティと並べた。

標準はすぐに改訂を始めた。2023年に生成AIをリテラシーへ追加。2024年7月の1.2版はAI開発の行動例とプロダクトマネージャーの補記を加えた。AI Nativeの発表からわずか2カ月前の2026年4月には、DSS 2.0がデータマネジメント、AI、事業変革の役割を刷新した。

この速い変化が、軽い民間診断を魅力的にする。国の標準は広く合意を取り、安定性を持つ。21問のフォームは、コンテキストエンジニアリング、マルチエージェント、評価パイプライン、LLMOpsを、用語の意味がなお議論されるうちに追加できる。速度と引き換えに、制度的な厚みを失う。

プロダクトマネージャー、プロジェクトマネージャー、危険な二文字

「PM」は安定した職名ではない。プロジェクトマネージャーは期限のある仕事をまとめる。範囲、依存関係、日程、資源、リスク、契約、納品を扱う。プロダクトマネージャーは、継続する製品の方向を担う。誰の問題を解くか、どの成果を求めるか、何を作り、何を捨て、学習をどうロードマップへ返すかを考える。日本のテック企業で後者をPdMと書くのは、混同を避けるためだ。

AI Nativeの発表見出しは「エンジニア・PM」とするが、診断概要の対象はエンジニア、テックリード、CTO／VPoE、PdMである。現在の製品ページはエンジニア、技術リーダー、技術責任者を中心に説明し、独立したプロジェクトマネジメント尺度は公表していない。したがって、最も安全な読みは「プロダクトマネージャー」であり、あらゆるプロジェクトマネージャーではない。

重なる仕事はある。どちらも要件を考え、トレードオフを交渉し、不確実性を伝え、チームの実行を助ける。AIではモデル挙動が製品方針を技術試験へ変えるため、境界はさらにぼやける。それでも、モジュール分割、評価パイプライン、LLMOps、ガードレールを含む診断が測るのは、AI製品開発への参加であって、プロジェクトマネジメント実務の全体ではない。

採用では重大な違いになる。建設プロジェクトの有資格管理者が、調達、工程、関係者調整に優れていても、コンテキストエンジニアリングの点は低いかもしれない。それはプロジェクト管理能力が低い証拠ではなく、測定領域が狭い証拠である。妥当性には必ず続きがある。何の解釈に、誰について、どの判断のために妥当なのか。

レーダーチャートがゲームのように感じる理由

ゲームの画面は成長を見えるようにする。ロールプレーイングの登場人物は経験値を得て能力を解放し、偏った育ち方を示す。攻撃は高い、防御は弱い、魔法はこれから。曖昧な未来を「次の行動」に変えることが楽しさになる。スキル画面も同じ文法を借りる。低い軸は失敗だけでなく、次のクエストになる。

それは人に優しい可能性がある。従来の人事評価は、昇進の時まで規則を隠すことがある。共通尺度があれば、若手は「上達とは何か」を尋ねられ、上司は技術の広さと組織への影響を分けられる。知識と経験を別にすれば、学んでいても機会が少なかった人を、一つの年功点数の中へ消さずに済む。

可視化は同時に圧縮する。同じ形のレーダーでも履歴は違う。一人は医療情報を扱う安全な検索システムを作った。別の人はチュートリアル後に同じ自己記述を選んだ。玩具チャットボットのコンテキスト設計と、多言語・規制産業サービスの設計は同じではない。経験は、どの器にも注げる液体ではない。

点数は行動を変える。昇進、配置、給与と結び付けば、人は基準を学ぶ。見える成果物を集め、流行語を身につけ、表にない価値ある仕事を避ける。「指標が目標になると、同じ指標として機能しなくなる」というグッドハートの法則の一般的表現が当てはまる。

対策は尺度を隠すことではない。判断を複数に保つ。チャートを、成果、実務証拠、同僚の視点、仕事が行われた条件と組み合わせる。障害ゼロだけでなく、障害から学んだ行動を評価する。枠組みは版管理し、尺度が変わっただけで本人の能力が下がったように見えないよう旧結果を残す。

測定がマネジメントになるとき

AI Nativeは採用、育成、アサインへの利用を挙げる。順に判断の重みが増す。個人の内省なら粗さに耐えられる。育成対話には、妥当な練習へ導く一貫性が要る。採用や昇進の足切りには、関連性、信頼性、アクセス、公平性、プライバシー、異議申し立てに答えなければならない。

10分の自己申告を自動ゲートにしてはいけない。候補者は謙虚さ、言語、選択肢への慣れ、高度なシステムに触れた機会が違う。強いガバナンスを持つ会社の人は、自分の権限を正確に狭く答えるかもしれない。非公式な小チームの人は、他に誰もいなかったため広い所有を主張できる。自信と能力が逆転し得る。

一方、チーム育成では9軸がよい会議の目次になる。全員がAI知識を高く、運用を低く付けたとき、必ずしも「LLMOpsの英雄」を採用する必要はない。リリースチェックを作り、モデルとプロンプトの版を定義し、評価セットを整え、ロールバック責任を決め、障害訓練をする。尺度は、人を順位付けするだけでなく、人を囲む仕組みを変えたとき価値を得る。

診断データのガバナンスも要る。スキルプロファイルは雇用情報である。誰が見られるか、いつまで残すか、本人が事情を補足・訂正できるか、ベンダーが集計してよいかを決める。公式ページによると公開フォームの個人情報は任意で、メールアドレスなしでもブラウザ上で結果を見られる。企業利用にはさらに厚い規程が必要だ。

AI開発そのものについて、尺度の方向は妥当である。NISTはAIリスク実務をGovern、Map、Measure、Manageに整理し、生成AIプロファイルはライフサイクル全体の統制を重視する。AI Nativeの品質、運用、ガバナンスの軸は、その制度的言語を開発チームの日常へ翻訳している。残るのは、翻訳が正しいか検証する仕事だ。

この診断自身が受けるべき試験

信頼できる評価には、主張、証拠、境界が要る。AI Nativeの主張は、21の回答でAI開発の9要素における強みと伸びしろを可視化できること。証拠は段階的に積める。専門家による設問内容の確認、受検者が意図通りに設問を解釈するかの面接、内部一貫性と再検査、実務サンプルや観察行動との比較、提案された行動で成果が改善するかの研究である。

会社は版番号と技術ノートを公開するとよい。割合の標本数、募集方法、欠測処理、不確実性を示す。「High」が定義済み行動を満たす基準準拠なのか、他人より高い規準準拠なのかを説明する。細部ではない。絵の意味を決める条件だ。

「市場価値」の主張も急がない方がよい。市場価値は職種、産業、地域、言語、会社段階、成果を出す機会で変わる。レーダーチャートは能力を言語化できる。労働市場データと検証済みモデルなしに給与を言い当てることはできない。

最も将来性があるのは、尺度の重心だ。品質保証、LLMOps、ガバナンスを、プロンプトやAI知識と同じ画面に置いた。エンジニアとプロダクトマネージャーへ、「本番運用こそ職業だ」と伝える。一度動く試作品はデモである。評価でき、監視でき、守れ、修理でき、説明できるものがサービスになる。

各軸の背後には場面がある。誰かが最初の敵対テストを書く。モデル費用の急増に気づく。データでは約束を支えられないとプロダクト責任者へ伝える。顧客が目覚める前に更新を戻す。次の担当者が一人にならないよう障害を記録する。これらは技能だが、同時に責任であり、組織から与えられた権限でもある。

AI Nativeは、その国の小さな地図を描いた。まだ測量器ではなく、初期データを国勢調査と見なしてはいけない。それでも、多くのチームが試作品を実利用者へ渡して初めて知る山々に名前を付けた。若い会社が次に、自らの尺度をAIシステムと同じ厳しさで測るなら――テスト、版管理、監視、失敗の透明性――点数以上のものを作れる。デモの後に始まる仕事の、共通言語である。