「Flutter実務経験1年以上必須」と書かれた求人に落ちた3週間後、同じ企業の採用ページに「iOSエンジニア(自社開発・客先常駐なし)」という求人が新しく載っているのを見つけた——8年間iOSひと筋でやってきたNさんは、その矛盾に戸惑って私に連絡してきました。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、iOSネイティブエンジニアがクロスプラットフォーム求人に応募して書類選考で落ちる相談は、Flutterの採用が増え始めたここ数年で目に見えて増えています。今回は、なぜ「Flutter実務経験◯年」という必須要件がありながら実はiOS経験者が有利になり得るのか、その構造と、Swiftでの設計経験を職務経歴書でどう翻訳し直すかを、相談事例をもとにお伝えします。

今回は、次の内容に沿ってご紹介します。

  • iOSエンジニアがFlutter未経験のまま書類選考で落ちてしまう構造的な理由
  • 求人票が「Flutter実務経験◯年」を必須にする、企業側の本当の採用動機
  • Swiftの設計経験をFlutter/React Native求人向けにどう翻訳するか、職務経歴書のBefore/After実例
  • Flutterの学習ロードマップと、転職活動を始めるタイミングの見極め方
目次
  1. iOSエンジニアがFlutter未経験で書類選考に落ちる理由
  2. 相談事例、Nさんが書類選考で落ち続けた理由
  3. 職務経歴書のBefore、実績が「iOS実務経験」の列挙で止まっていた
  4. 求人票が「Flutter実務経験◯年」を必須にする本当の理由
  5. Swiftの設計経験をFlutter向けに翻訳する対応表
  6. 職務経歴書のBefore/After、実例
  7. 書き直した後、Nさんの書類選考はどう変わったか
  8. 面接で「Flutterは未経験ですよね」と聞かれたときの答え方
  9. データで見る、クロスプラットフォーム転向で年収はどう変わるか
  10. Flutterの学習ロードマップと、転職活動を始めるタイミング
  11. よくある質問に答えます
  12. まとめ、iOS経験は「翻訳すれば」武器になる

iOSエンジニアがFlutter未経験で書類選考に落ちる理由

書類選考の一次仕分けは、求人票の必須要件に書かれたキーワードとの文字列一致で機械的に処理されることが多いというのは、職種を問わず共通する構造です。「Flutter実務経験1年以上」という要件は、応募者側の経歴にFlutterという単語が出てこない限り、担当者が中身まで読み込む前に対象外へ振り分けられてしまいます。

iOSエンジニアの場合、この足切りが特に起きやすい理由があります。職務経歴書に並ぶのがSwift・UIKit・SwiftUI・Xcodeといった、Flutterとは表記上まったく重ならない固有名詞ばかりだからです。実務ではUIの状態管理も非同期処理もリリース運用も経験しているのに、書類の上ではキーワードが一つも一致しないという状態が起きます。

type「ITエンジニアの有効求人倍率は?」によると、2026年7月時点のITエンジニア(情報処理)の新規求人倍率は3.3倍で、4月の2.6倍から回復基調にあるものの、企業の採用基準は「数より質」にシフトしているとされています(出典:type「ITエンジニアの有効求人倍率は?2026年7月の最新動向」)。求人自体は増えていても、1件ごとの必須要件は厳格に運用される傾向が強まっているというのが、この数字から私が読んでいる背景です。

ポイント: 求人が増えている局面ほど、企業は必須要件のキーワードマッチで機械的に絞り込む傾向が強まります。iOSエンジニアがFlutter求人に落ちるのは実力不足ではなく、経験がFlutterの言葉に翻訳されないまま応募しているケースがほとんどです。

もう一つの理由は、職務経歴書の書き方そのものにあります。iOS専任で長くやってきた人ほど「iOSアプリの設計・実装・保守」という職種名をベースにした書き方に慣れていて、その中身をFlutter求人が重視する言葉——状態管理、クロスプラットフォームでの一貫性維持、パフォーマンスチューニング——に置き換える発想自体が抜け落ちがちです。書類選考で見られているのは経験の量ではなく、その経験がどの言葉で書かれているかです。

相談事例、Nさんが書類選考で落ち続けた理由

Nさん(33歳・経験8年)は、スマホアプリ受託開発を専門とする会社に所属し、クライアント企業向けのiOSアプリをSwift・UIKit・SwiftUIで開発してきました。画面のライフサイクル管理、Auto Layoutでの複雑な制約設計、Combineを使った非同期処理、App Store審査対応まで、iOSの実務を一通り経験していた技術者です。

「両方のOSを見られる立場になりたい」と考え、生活雑貨のECアプリを運営する自社開発企業のFlutterエンジニア求人に応募しました。求人票には「Flutter実務経験1年以上必須」と明記されており、Flutter実務は未経験のまま応募したところ、8社中8社すべて書類選考で見送りになりました。

見送りが続く中、Nさんは1社の採用ページで「iOSエンジニア(自社開発・客先常駐なし)」という別の求人が新しく掲載されているのを見つけます。Flutter必須の求人で自分は落とされたのに、同じ会社がiOS単独のエンジニアも別枠で募集している——この矛盾に納得がいかず、Nさんは私に相談を持ちかけました。

職務経歴書を見せてもらうと、原因はすぐに分かりました。業務内容の記述がすべて「iOSアプリの設計・実装」という枠組みで完結していて、Flutter求人の担当者が読み取れる言葉が一つも含まれていなかったのです。技術力は十分にあるのに、書類の上ではFlutterとの接点がゼロに見える状態でした。

職務経歴書のBefore、実績が「iOS実務経験」の列挙で止まっていた

書き直す前のNさんの職務経歴書には、次のような記述が並んでいました。

Before(書類選考に通らなかった頃の記述)

  • iOSアプリの新規開発・保守を担当(Swift/UIKit/SwiftUI)
  • Auto Layoutを用いた画面レイアウトの実装
  • App Store審査対応、リリース運用
  • Flutter:実務経験なし

事実として正確ではあるものの、この書き方では「iOSしか書けない人」という以上の情報がFlutter求人の担当者には伝わりません。画面のライフサイクルをどう設計してきたか、状態管理をどう組み立ててきたか、非同期処理をどう扱ってきたかという、Flutter求人が本当に知りたい部分が、固有名詞の羅列の裏に埋もれたままでした。

最後の「Flutter:実務経験なし」という一行も、正直ではあるものの逆効果でした。ないことを申告するだけの一行は、採用側にとって判断材料にならず、むしろ「未経験」という結論だけを強く印象づけてしまう、というのがこの一行の問題でした。Nさんの場合も、この一行が読み手の目に最後に焼きつく形になっていました。

求人票が「Flutter実務経験◯年」を必須にする本当の理由

企業がなぜクロスプラットフォーム開発に寄せたがるのか、その背景を理解しておくと、必須要件の読み方が変わります。iOSとAndroidを別々のネイティブ言語で開発する場合、企業はSwiftエンジニアとKotlinエンジニアをそれぞれ確保しなければなりません。同じ機能を2つの言語で二重に実装し、2つのチームでレビューし、2つのリリースサイクルを回すコストは、規模が小さい組織ほど重くのしかかります。

Flutter・React Nativeのようなクロスプラットフォーム技術は、この二重コストを一つのコードベース・一つのチームに集約できる点が最大の魅力とされています。開発工数が3〜4割圧縮できるという主張はFlutter推進側の文脈でよく語られる数字で、案件の性質によって振れ幅が大きく、そのまま鵜呑みにできる実証データとは言えません。ただし、iOS/Android別々に人を採用し続けるより一つのチームで両方回したいという企業側の意図は、私が見てきた求人票の書きぶりからも一貫して読み取れます。

この構造を理解すると、「Flutter実務経験1年以上必須」という一文の解釈が変わってきます。企業が本当に避けたいのは「Flutterが書けない人」ではなく、「iOSしか、あるいはAndroidしか見られない人をもう一人増やすこと」です。両方のOSの設計思想を理解している人材であれば、Flutterの構文自体は入社後にキャッチアップできると判断する企業は、私が担当した採用現場でも珍しくありません。

Nさんが見つけた「同じ会社がiOS単独求人も出している」矛盾は、この構造で説明がつきます。Flutter求人はクロスプラットフォームチームの増員枠、iOS単独求人は既存のネイティブ資産(古いバージョンのアプリの保守など)を維持するための枠で、採用の目的そのものが違っていたのです。求人票だけを見ていると矛盾に見えますが、企業側の採用計画としては筋が通っています。

Swiftの設計経験をFlutter向けに翻訳する対応表

iOSでやってきたことを、Flutter・React Nativeの概念に一対一で置き換えると、職務経歴書に書くべき言葉が具体的に見えてきます。Nさんと実際に添削で使った対応の一覧を挙げます。

iOSでの経験Flutter/React Nativeでの対応概念職務経歴書で書く言葉のヒント
UIKit/SwiftUIの画面ライフサイクル管理(viewDidLoad等)StatefulWidgetのライフサイクル、状態管理(Provider/Riverpod/Bloc)「画面のライフサイクルに応じた状態設計の経験、状態管理ライブラリの思想理解に応用可能」
Auto Layoutでの複雑な制約設計、複数端末サイズ対応ウィジェットツリーによるレイアウト設計、レスポンシブ対応「複数端末サイズ・解像度に対応するレイアウト設計の経験」
Combine/RxSwiftによる非同期処理Stream・Futureによる非同期データフロー設計「非同期データフローの設計経験、Streamベースの状態管理に転用可能」
App Store審査対応、リリース運用両ストア(App Store/Google Play)の審査基準・リリースプロセス「審査基準を踏まえたリリース設計の実務経験、両OSでの審査対応に応用可能」
ARCを前提としたメモリ管理、循環参照の回避Dartのガベージコレクションを踏まえたパフォーマンスチューニング「メモリリークを意識した設計経験、描画パフォーマンスの最適化視点」

この表のポイントは、右列を「できます」と言い切らないことです。経験が土台になっている、という書き方に留めるのが正確で、面接で技術的に深掘りされたときにも矛盾が出ません。「Flutterも書けます」と背伸びして書くと、コーディング課題や技術面接の最初の質問で崩れてしまいます。

もう一つ大事なのは、5項目すべてを詰め込まないことです。応募先の求人票が「状態管理設計」を強調しているなら状態管理の行、「両OSでの品質担保」を強調しているならリリース運用の行というように、求人票の言葉に合わせて2〜3項目に絞って厚く書いた方が伝わります。オンプレ環境しか経験のないインフラエンジニアがクラウド未経験のまま転職する場面でも、経験をクラウドの言葉に翻訳する対応表を使った添削が通過率を左右しますが、これはiOSからFlutterへの転向でもまったく同じ構造だと私は見ています。

職務経歴書のBefore/After、実例

Nさんの職務経歴書を、この対応表を使って書き直しました。Beforeは「iOSアプリの新規開発・保守を担当。Swift/UIKit/SwiftUIを用いた画面実装、Auto Layoutによるレイアウト設計、Combineによる非同期処理、App Store審査対応まで一貫して経験。Flutter:実務経験なし」という記述でした。

After(書き直した後)は、「複数端末サイズ・iOSバージョンに対応する画面のライフサイクル管理と状態設計を8年間主導。Auto Layoutでの複雑な制約設計、Combineによる非同期データフロー設計の経験があり、Flutterの状態管理(Provider)の設計思想と共通する部分を独学の検証アプリで確認済み。業務外でFlutterアプリを1本設計・実装し、状態管理の実装パターンとiOS版との設計差分を整理した」という書き方に変えました。

志望動機も同時に書き直しています。Beforeは「クロスプラットフォーム開発に興味があり、新しい技術に挑戦したいと考え応募しました」という一般論でした。Afterでは「8年間iOSの画面設計と状態管理に向き合ってきた立場から、次は一つのコードベースで両OSのユーザー体験を作る側に回りたいと考えています。検証アプリの開発を通じて、状態管理の設計思想が土台から共通していることを確認できたのが応募の決め手です」という、経験と志望理由が接続された文章に変えました。「経験なし」で終わらせず、独学で埋めた範囲まで具体的に書くことで、採用側は「どこまで任せられるか」を判断できます。

書き直した後、Nさんの書類選考はどう変わったか

職務経歴書を書き直した後、Nさんは応募先の選び方も見直しました。とにかくFlutter求人に手当たり次第応募するのではなく、募集背景に「既存のiOSアプリをクロスプラットフォーム化」「iOS/Android別々の開発体制を統合」といった文言がある求人に絞り込み、5社に応募し直しました。結果、3社が書類選考を通過し、2社の最終選考まで進み、1社から内定が出ました。

Nさんが選んだのは、現職より年収換算で約58万円高いオファーを出した企業でした。決め手になったのは金額だけでなく、最終面接で「Flutterの構文はどのくらいで慣れましたか」ではなく「iOSで培った画面設計の考え方を、Flutterの状態管理でどう再現しようとしましたか」と聞かれたことだったとNさんは振り返っています。

書類選考の通過率が上がったこと以上に大きかったのは、面接で聞かれる質問の質そのものが変わったことです。書き直す前に一度だけ通過した書類選考の面接では「Flutterはどこまで書けますか」という前提を疑う質問から始まっていましたが、書き直した後は「その設計判断」を聞かれるようになりました。選考担当者がどこから話を始めるかは、職務経歴書の書き方一つで変わります。

面接で「Flutterは未経験ですよね」と聞かれたときの答え方

書類選考を通過しても、面接で改めてFlutterの実務経験の有無を確認されることはあります。Nさんが2社目の一次面接で聞かれたのは「職務経歴書を見るとiOSの経験は申し分ないですが、正直Flutterは未経験ですよね、大丈夫だと思いますか」という、率直な質問でした。

Nさんはここで「大丈夫だと思います」ではなく、「画面の状態が複雑になるとき、UIKitでは何をどのタイミングで再描画するかを常に意識していました。Flutterの状態管理も同じ発想で、検証アプリではProviderを使って通知の流れを1つずつ確認しながら実装しました」と、自分の思考プロセスと検証で埋めた行動をセットで答えました。面接官が知りたいのは「Flutterを触ったことがあるか」ではなく、「初めて触る技術に対してどう学ぶ人か」だと私は見ています。

最終面接では別の面接官から「iOS専任で8年やってきた人が、両OSを見る役割に本当にやりがいを感じられるのか」という、意欲そのものを疑う質問も出ました。Nさんは「iOSの中でも、画面ごとに細かい実装の違いに向き合うことにやりがいを感じてきました。両OSで一貫した体験を作る仕事は、その延長線上にある、より大きな設計の問題だと捉えています」と答え、専門性を狭めるのではなく広げる話として位置づけ直しました。

データで見る、クロスプラットフォーム転向で年収はどう変わるか

doda「平均年収ランキング(職種・職業別)」によると、スマホアプリ・ネイティブアプリ系エンジニアの平均年収は459万円(男性470万円・女性417万円)で、年代別では20代404万円、30代537万円、40代661万円と、経験年数が上がるほど伸び幅が大きくなっています。同じ調査でWebサービスエンジニアは452万円、SE/プログラマは435万円となっており、モバイル系エンジニアの水準はこれらとほぼ同じレンジです(出典:doda「平均年収ランキング(職種・職業別)」、2024年9月〜2025年8月にdoda登録した約60万人が対象)。

このデータを見て私が気になるのは、「スマホアプリ・ネイティブアプリ系」という職種区分が、iOS専任・Android専任・クロスプラットフォームを一括りにしている点です。私が担当した案件を見る限り、同じ職種区分の中でも、クロスプラットフォーム対応ができる人材の方が求人票のレンジ上限に近い提示を受けやすい傾向があります。両OSを見られる分、採用企業から見た代替の効きにくさが上がるためです。

片方のOSしか書けないエンジニアを2人雇うコストを避けたいという企業側の事情は、年収の提示にもそのまま反映されます。Nさんのケースでも、Flutter求人での提示額は、同時期に受けたiOS単独求人の提示額より一貫して高めでした。iOS経験だけで頭打ちを感じているなら、クロスプラットフォームへの領域拡張は年収の天井を押し上げる現実的な手段の一つです。

Flutterの学習ロードマップと、転職活動を始めるタイミング

「Flutterを一から学んでから応募すべきか」という質問もよく受けます。結論から言うと、iOS経験がある人であれば、Dart文法の基礎とウィジェット・状態管理の実装パターンを一通り触った段階で、応募自体は始めてよいというのが私の考えです。

一般的なFlutterの学習ロードマップは「Dart文法→ウィジェットの基礎→状態管理→実践(小規模アプリ1本)」の順で1〜4か月が目安とされることが多いのですが、これは未経験からの目安です。iOS出身者の場合、画面設計・レイアウト・非同期処理の概念はすでに身についているため、Dartの文法とFlutter特有のウィジェットツリーの考え方さえ押さえれば、実践段階に入るまでは1〜2か月程度で到達する人が多いというのが私の実感です。

順番としては、Dart文法を1〜2週間で一通り触った後、状態管理の基本(Provider程度)を押さえたら、早い段階で小規模な検証アプリを1本作ることを勧めています。Nさんも学習期間は正味2か月ほどで、その間に作ったのは在庫管理アプリを模した検証アプリ1本だけでした。完成度の高いアプリを1本仕上げるより、iOSとの設計差分を自分の言葉で説明できる状態を作る方が、書類選考・面接では効きます。

学習が完了してから応募するか、学習しながら応募するかで迷う人もいますが、書類選考は学習の完成を待ってくれるとは限りません。検証アプリが動くようになった段階で、職務経歴書に「独学で実装中」と正直に書いて応募を始めても遅くはないというのが、Nさんの事例からの感覚です。モダンな技術への転向にかかる期間の考え方は、jQueryからモダンフロントエンド転職にかかる期間でも別の技術領域で扱っているので、あわせて参考にしてください。

よくある質問に答えます

iOS経験は何年あればFlutter求人に応募できますか。 年数そのものより、画面のライフサイクル管理・状態管理・非同期処理をどれだけ自分の言葉で説明できるかが重要です。Nさんは経験8年でしたが、経験3〜4年程度でも、設計判断を具体的に語れれば書類選考の土俵に乗る場面を見てきました。

React NativeとFlutter、どちらを学ぶべきですか。 応募したい企業が使っている方を優先してください。Swiftの設計知識を翻訳する作業自体は、どちらのフレームワークでもほぼ同じです。求人票にどちらの技術が多いかは業界や企業の規模によって偏りがあるので、志望する業界の求人を先に眺めてから決めても遅くありません。

Android(Kotlin)の経験もないと不利ですか。 なくても不利にはなりません。企業が避けたいのは「片方のOSしか見られない人材をもう一人増やすこと」であって、Android経験の有無そのものが必須条件になっている求人は多くありません。iOSの設計経験を丁寧に翻訳できていれば、それだけで十分な材料になります。

職務経歴書に「Flutter:学習中」と書いてもいいですか。 書いた方がいいと私は考えています。「実務経験なし」とだけ書くより、何を使ってどこまで検証したかを具体的に添える方が、採用側にとっては判断材料が増えます。ただし検証した範囲以上のことを書かないよう、事実の粒度は正確に保ってください。

まとめ、iOS経験は「翻訳すれば」武器になる

Nさんのケースが示しているのは、Flutter未経験という事実そのものが書類選考の壁になっているわけではないということです。壁になっているのは、iOSで積んできた画面設計・状態管理・非同期処理の経験が、Flutter求人の担当者が読み取れる言葉に翻訳されないまま職務経歴書に並んでいる状態です。

求人票の「Flutter実務経験◯年」は、企業がiOS/Android別々に人を確保するコストを避けたいという事情の裏返しであることが多く、両OSの設計思想を理解している人材にとっては、必ずしも高い壁ではありません。やってきたことを、相手が読み取れる言葉に翻訳し直せているかどうかが、書類選考で足切りされ続けるか、クロスプラットフォーム求人で評価されるかの分かれ目だというのが、今回の相談事例を通じて一番伝えたかったことです。iOSひと筋で来たことを引け目に感じている人ほど、実は翻訳できていないだけの経験を多く抱えていると、私は現場で感じています。