React Nativeエンジニアのスキルシートの書き方|面談で評価される実績の見せ方
公開 2026-10-29 監修:株式会社エージェントベスト
React Nativeのスキルシートは、「React Native◯年」とまとめず、そのアプリで使っていた版とアーキテクチャ、Expoの使い方、ネイティブ側とストアへの公開で自分が担った範囲を分けて書くのが基本です。React Nativeの経験は、同じ年数でも「画面だけを作っていた人」と「ビルドから公開まで持っていた人」で中身がまったく違うため、読む側はその違いを知りたがっています。
この記事では、React Nativeならではの書き方の要点と、架空の記入例を紹介します。スキルシート全体の構成はスキルシートの基本をご覧ください。
版とアーキテクチャは、アプリごとに書く
React Nativeの公式ドキュメントでは、New Architectureは0.76から標準で有効になり、0.82からはNew Architectureだけで動くようになったと説明されています(2026年10月時点)。つまり、同じ「React Native」でも、どの時期のどの版を扱ったかで経験の中身が違います。
スキルシートでは、アプリごとに次の点を書き分けます。
| 書くこと | 書き方の例 |
|---|---|
| 扱った版 | 参画時は0.7X系、離任時は0.8X系 |
| アーキテクチャ | 従来のアーキテクチャから New Architectureへの移行を担当 |
| 版上げへの関わり | 版上げを主担当として計画・実施した/他の人の版上げのレビューをした |
| 対応しなかったこと | 版上げは別のメンバーが担当 |
版上げは、React Nativeの案件で特に見られる経験です。何系から何系へ上げたか、New Architectureに対応していないライブラリをどう扱ったかを一行で書けると、引き継ぎの案件で目に留まりやすくなります。
Expoは「使っていた」ではなく「どう使っていたか」で書く
Expoの現場でも、使い方は大きく分かれます。Expoの公式ドキュメントでは、ネイティブのフォルダを設定から生成する「Continuous Native Generation」の考え方と、設定用のプラグインでネイティブの設定を変えるやり方が説明されています。一方で、ネイティブのフォルダを手で管理している現場もあります。
次のように書き分けると、経験の中身が伝わります。
- ネイティブのフォルダの扱い:設定から生成していた/手で管理していた/Expoを使っていなかった
- ビルドと配布:クラウドのビルドを使っていた/CIで自前のビルドを組んでいた
- ストア外の配信:使っていた場合は、配信の基準づくりや手順に関わったか
- 自分で書いた設定:設定用のプラグインを自作した、既存のプラグインを直した
「Expo使用」とだけ書くと、Expo Goで動かしていただけなのか、本番のビルドまで持っていたのかが伝わりません。
ネイティブ側とストア公開は、OSごとに担当を分ける
React Nativeのアプリでも、iOSとAndroidではビルド、署名、申請の流れが別々です。まとめて「両OS対応」と書かず、OSごとに自分が担った範囲を書きます。
| 項目 | iOS | Android |
|---|---|---|
| ビルドの設定 | 担当 | 担当 |
| 署名の鍵・証明書の管理 | 発注側と分担 | 担当 |
| ストアへの申請 | 担当(審査の指摘への対応を含む) | 担当 |
| ネイティブのコード | Swiftで小さなモジュールを作成 | 既存ライブラリのKotlinの不具合を修正 |
分担していた作業は、分担していたとそのまま書きます。全部を自分がやったように見える書き方は、面談で詳しく聞かれたときに食い違いの原因になります。
出身によって並べ方を変える
React Nativeエンジニアは、WebのReact、ネイティブ、Flutterなど、入り口がさまざまです。スキル一覧の並べ方を出身に合わせて変えると、読む側が経験の全体をつかみやすくなります。
- Webから来た方:React Nativeの経験を先頭に置き、Webの経験は「React・TypeScriptの経験」として別にまとめる。Webの経験をReact Nativeの年数に含めない
- ネイティブから来た方:React Nativeの経験に加え、SwiftやKotlinの経験を「ネイティブ連携に生かせる経験」として書く
- Flutterから来た方:両OSのストア対応の経験を、React Nativeの経験と並べて書く
WebのReactの経験は、React Nativeの年数と分けて書くのが基本です。合わせて書くと、モバイル特有の経験が少ないことが面談で分かったときに、印象が下がることがあります。
スキル一覧の欄は「深さ」を添える
スキル一覧に技術の名前だけを並べると、どこまで使えるかが伝わりません。名前の横に、深さが分かる一言を添えます。
| 技術 | 添える一言の例 |
|---|---|
| React Native | 画面の実装/版上げの主担当/New Architectureへの移行 |
| Expo | 開発ビルドの運用/設定用のプラグインの自作/クラウドのビルドと配布 |
| Swift・Kotlin | 読んで原因を特定できる/小さなモジュールを書ける |
| ストア対応 | 申請と審査の指摘への対応を、iOS・Androidそれぞれで担当 |
「読める」と「書ける」を分けるだけでも、面談での質問が具体的になり、食い違いを防げます。
公開しているアプリのURLを載せるとき
公開されているアプリのストアのURLは、実績を示す材料になります。ただし、前の契約の秘密保持の範囲で、関わったことを伝えてよいかを確かめてから載せましょう。載せる場合は、担当したOSと時期、担当した機能を添えると、今のアプリのどこが自分の仕事かが伝わります。秘密保持との関係はスキルシートと守秘義務の記事で解説しています。
プロジェクト欄の記入例
ここでは、運用中のアプリを引き継ぎ、版上げとNew Architectureへの移行を担った場合を想定した記入例を示します。以下は書き方を示すための架空の例で、実在のアプリや実績ではありません。業界や規模はぼかしています。
期間:20XX年X月〜20XX年X月(1年)
アプリ:生活関連サービス向け 一般利用者のアプリ(運用中のアプリの引き継ぎ)
配布:App StoreとGoogle Playで公開
規模・立場:アプリ3名・サーバー3名(自分はアプリ側の版上げとリリースの主担当)
使用技術:React Native、TypeScript、Expo(ネイティブのフォルダは設定から生成)、状態管理ライブラリ、CI
版とアーキテクチャ:参画時は従来のアーキテクチャで動く古い版。New Architectureが標準の版まで段階的に上げた
OSごとの担当:ビルド設定と申請は両OSとも担当。iOSの証明書は発注側の担当者と分担。Androidの既存ライブラリの不具合をKotlinで修正
担当内容:New Architectureに対応していないライブラリを洗い出し、置き換え・修正・削除に分けて進めた。手で直していたネイティブの設定を、設定用のプラグインに移した
工夫・成果:版上げの手順と、ストア外の配信で直してよい変更の基準を文書にし、他のメンバーが作業できるようにした
「版とアーキテクチャ」の行は、React Nativeならではの項目です。数字の成果は、守秘義務の範囲で出せるものだけを書きます。
よくある質問
版の番号まで正確に覚えていません。どう書けばよいですか?
正確な番号が分からない場合は、「0.7X系」のように系列で書くか、「New Architectureが標準になる前の版」のように時期が分かる書き方でかまいません。大切なのは、古い版を扱ったのか、版上げに関わったのかが伝わることです。
個人で作ったアプリは書いてもよいですか?
書いてかまいません。業務の経験と分けて「個人での開発」として書き、ストアに公開したか、ネイティブのライブラリを入れたかなど、業務で生かせる点を添えると評価の材料になります。
面談ではスキルシートのどこが詳しく聞かれますか?
版上げ、ネイティブ側の対応、ストアの審査の指摘への対応が詳しく聞かれやすい傾向があります。記入した内容のうち、一つは原因と直し方まで話せるように準備しておきましょう。面談の準備は面談でよく聞かれる質問をご覧ください。
参考にした公的情報・資料
- About the New Architecture(React Native)
- React Native 0.82 - A New Era(React Native Blog)
- Continuous Native Generation (CNG)(Expo Documentation)
- EAS Update(Expo Documentation)
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。