技術選定という名の「終わりのない迷宮」
エンジニアとして生きていると、数年に一度、自分のキャリアを左右するような「選択」を迫られる瞬間が来ます。
かつては「jQueryを使い続けるか、モダンなフレームワークに移行するか」で悩み、少し前なら「Vue.jsかReactか」で現場の議論が白熱していました。私もその渦中で、胃を痛くしながら技術選定書を書いた記憶があります。
そして今、モバイルアプリ開発の領域で、私たちを悩ませ続けている最大のトピック。
それが「React Native vs Flutter」です。
私自身、この二つの技術には本当に振り回されました。
元々Webエンジニア出身の私は、最初は「JavaScriptでアプリが作れるなんて、これぞ革命だ」とReact Nativeに飛びつきました。自分の慣れ親しんだReactの知識がそのままアプリ開発に使える。その事実に震えました。
しかし、数年後にFlutterが登場し、そのパフォーマンスと開発体験の良さを目の当たりにした時、正直に言って冷や汗をかきました。「もしかして、俺が積み上げてきた技術はオワコンになるのか？」と。
今、この記事を読んでいるあなたも、きっと同じように迷っているはずです。
「副業で稼ぐなら、どっちを学ぶのが正解なの？」
「将来性があるのはどっち？」
「今から学習コストを払って、回収できるのはどっち？」
ネットで検索すれば、機能比較のスペック表は山ほど出てきます。レンダリング方式がどうとか、コンパイル速度がどうとか。でも、そんな教科書的なスペック表だけじゃ、私たちの人生の舵取りは決められないんですよね。
知りたいのは、現場の空気感。案件のリアルな単価。そして実際にコードを書いた時の「手触り」。そういう生きた情報のはずです。
この記事では、現役のエンジニアであり、スクールでメンターとして多くの初心者の技術選定に立ち会ってきた私が、この二大クロスプラットフォーム開発フレームワークを徹底的に解剖します。
忖度は一切なし。私が現場で見てきた「成功」と「失敗」、そして「後悔」も含めて、全てを話します。
これを読み終える頃には、あなたの迷いは消え、次に開くべきエディタと、インストールすべきSDKが決まっているはずです。さあ、一緒にこの迷宮の出口を探しに行きましょう。
なぜ今、ネイティブではなく「クロスプラットフォーム」なのか
比較に入る前に、少しだけ前提の話をさせてください。
そもそも、なぜ今、Swift（iOS）やKotlin（Android）といった「ネイティブ開発」ではなく、React NativeやFlutterのような「クロスプラットフォーム開発」がこれほどまでに副業やスタートアップ界隈で支持されているのでしょうか。
「二倍のコスト」に耐えられる時代ではなくなった
答えは非常にシンプルで、「お金」と「時間」です。これに尽きます。
私がまだ駆け出しの頃、10年ほど前でしょうか。アプリを作るといえば、iOSエンジニアとAndroidエンジニアをそれぞれ雇うのが当たり前でした。
「iOS版ができたので、次はAndroid版を作ります（さらに3ヶ月かかります）」
こんなスケジュール感が許されていました。
しかし、今はどうでしょう。
予算は倍、コミュニケーションコストも倍。仕様変更があれば、二つのチームにお願いして回る。iOSでバグが直ったと思ったら、Androidで新しいバグが出る。
正直、狂気の沙汰です。
潤沢な資金がある大企業ならまだしも、スタートアップや個人の副業開発で、そんな贅沢なリソースがあるわけがありません。
「一つのコードで、両方のOSで動くアプリを作りたい」。
この人類の悲願とも言える夢を、かつては「Cordova」や「PhoneGap」といったハイブリッドアプリ技術が叶えようとしました。私も触りましたが、動作がもっさりと重く、「所詮はWebビューか」とガッカリしたものです。
しかし、React NativeとFlutterは違いました。
ネイティブに近いパフォーマンスで、本当に一つのコードベースで両OSを動かしてしまった。
今、私がクライアントから「新規でアプリを作りたい」と相談されたら、9割以上の確率でクロスプラットフォームを提案します。
予算を抑えられるから？ それもありますが、一番の理由は「市場投入までのスピード（Time to Market）」です。
アイデアを形にして、ユーザーに届ける。このサイクルを高速で回すことが何より重要な今の時代において、これらを使わない手はありません。
React Native：Web界の巨人が作った「最強の武器」
まずは、私の古巣とも言えるReact Nativeから見ていきましょう。
Meta社（旧Facebook）が開発したこのフレームワークは、「Webエンジニアがアプリ開発に殴り込みをかけるための最強のパスポート」です。
Webエンジニアにとっての「実家のような安心感」
React Nativeの最大の特徴。それは何と言っても「JavaScript（TypeScript）で書ける」こと。これに尽きます。
世界中に何千万人いるかわからないWebエンジニアたちが、その知識をほぼそのまま流用してアプリを作れる。これは革命でした。
私が初めてReact Nativeに触れた時の感動は、今でも忘れられません。<div>タグの代わりに<View>、<span>の代わりに<Text>と書くだけ。あとはいつも通りのReactの作法（HooksやState管理）で動く。CSSライクなスタイリングもできる。
「え、これだけでiPhoneの中で動くの？ マジで？」
シミュレーターで自分の書いたコードが動いた時、Webエンジニアとしてのスキルがそのままアプリ領域に拡張された感覚を持ちました。
// React Nativeのコード例
import React from 'react';
import { Text, View } from 'react-native';
const HelloWorldApp = () => {
return (
<View style={{ flex: 1, justifyContent: "center", alignItems: "center" }}>
<Text>Hello, world!</Text>
</View>
);
}
export default HelloWorldApp;見ての通り、Reactをやったことがある人なら、何の違和感もなく読めるはずです。
学習コストという点において、Web経験者にとってReact Nativeはチート級の低さを誇ります。スクールでWeb制作を学んだ人が、次のステップとしてアプリ開発を学ぶなら、React Nativeは最も自然な選択肢です。
エコシステムの巨大さと「Webとの共有」
もう一つの強みは、npmという巨大なエコシステムです。
日付操作のdate-fns、通信処理のaxios、状態管理のReduxやZustand…。Web開発で使っていたお気に入りのライブラリが、そのままアプリ開発でも使えることが多いのです。
「あ、この処理、前のWeb案件で書いたな」と思ったら、そのコードをコピペして持ってこられる。
さらに、設計次第では「Web版」と「アプリ版」でロジック部分のコードを90%以上共有することも可能です（React Native for Webなどもありますが、そこまでしなくてもロジック共有は容易です）。
実際に私が担当した案件で、Webサービスと管理画面アプリを同時リリースするプロジェクトがありました。React Nativeを採用したおかげで、API通信やデータ加工のロジック（Custom Hooks）を共通化し、工数を劇的に削減できました。クライアントからは「魔法みたいだ」と感謝されましたが、あれは技術選定の勝利でしたね。
OTAアップデートという「隠し玉」
これはあまり知られていない、でも現場では強力な武器になる機能です。
OTA（Over The Air）アップデート。
通常、アプリのバグ修正をユーザーに届けるには、App StoreやGoogle Playの審査を通す必要があります。これには数日かかることもあるし、審査でリジェクトされるリスクもあります。
しかし、React NativeはJavaScriptで動いているため、JSバンドル部分だけであれば、Appleの審査を通さずにバックグラウンドで更新できるんです（※もちろんAppleの規約の範囲内で、ですが）。
「緊急バグが見つかった！ ログインできない！ でも審査待ちで3日かかる！」
そんな地獄のような状況でも、React NativeならCodePushなどの機能を使って、即座に修正パッチをユーザーに配布できる。
この安心感は、運用フェーズに入ってからボディブローのように効いてきます。私も何度この機能に救われたかわかりません。
Flutter：Googleが描いた「理想郷」
次に、現在破竹の勢いでシェアを伸ばしているFlutterです。
Googleが開発したこのフレームワークは、React Nativeとは全く異なるアプローチで「クロスプラットフォームの正解」を導き出しました。
「全てを自分で描画する」という力技
React Nativeが「OSごとのネイティブ部品（iOSのUIButtonなど）をJavaScriptから呼び出す」という仕組みなのに対し、Flutterは「Skiaという高性能な描画エンジンを使って、画面のピクセルを全部自分で描画する」というアプローチを取っています。
これ、何がすごいか分かりますか？
「OSによる表示崩れが起きない」んです。
iOSでもAndroidでも、全く同じ見た目（Pixel Perfect）を再現できる。
Web開発で言うところの「IE対応」のような、OSごとの微妙な挙動の違いに悩まされることが激減します。デザイナーがこだわって作ったUIが、Androidの古い端末でも完璧に再現される。これは開発者にとってストレスフリーな体験です。
「すべてのパーツはWidget（ウィジェット）である」
この思想も強烈です。ボタンも、余白も、配置も、アニメーションも、全てがWidget。ブロック遊びのようにパチパチと組み合わせていくだけで、モダンで美しいUIが爆速で出来上がります。
// Flutterのコード例
import 'package:flutter/material.dart';
void main() {
runApp(
const Center(
child: Text(
'Hello, world!',
textDirection: TextDirection.ltr,
),
),
);
}Dartという「愛すべき伏兵」
Flutterの唯一の懸念点と言われるのが、プログラミング言語Dartです。
「えー、また新しい言語覚えるの？ JavaScriptじゃダメなの？」
私も最初はそう思いました。でも、触ってみて考えが変わりました。
Dartは、JavaやC#のような「カッチリした型」と、JavaScriptのような「柔軟さ」をいいとこ取りしたような言語です。
特に素晴らしいのが、静的型付けの堅牢さ。
コンパイル時にエラーを弾いてくれるので、実行してから「あ、落ちた（nullぬるぽ）」という事故が少ない。Null Safetyも標準装備です。
そしてGoogleが開発しているだけあって、VS Codeなどのエディタとの連携が神がかっています。補完機能が優秀すぎて、コードを書いているというより、エディタに導かれているような感覚になります。
Firebaseとの蜜月関係
副業エンジニアにとって、ここが最大の推しポイントかもしれません。
Firebaseとの連携が異常に簡単です。
どちらもGoogle製なので当然と言えば当然ですが、認証機能、データベース、プッシュ通知…これらを実装するのに、Flutterなら驚くほど少ないコードで済みます。ライブラリ（FlutterFire）の品質も非常に高い。
私が個人の副業案件で「予算少なめ、納期短め」の相談を受けた時、Flutterを選ぶ一番の理由はこれです。
サーバーサイドの構築工数を極限まで削れる。一人でフルスタックに開発する時、Flutter + Firebaseの組み合わせは「最強の時短セット」になります。
ガチンコ比較：副業エンジニア視点で見る「案件」と「お金」
技術的な特徴はなんとなく分かりましたね。
では、ここからはもっと生々しい話。「で、どっちが稼げるの？」という点について、私の観測範囲のデータをぶちまけます。
案件数と質のリアル
案件の「数」だけで言えば、現時点では拮抗していますが、その「質」や「出どころ」には明確な違いがあります。
React Nativeの案件傾向：
- Web系ベンチャーのアプリ化案件が多い。
- すでにWebサービス（React製）があり、それをアプリ化したい企業。
- 既存のReactエンジニアチームのリソースを活かしたい企業。
- 単価は高め安定。Webフロントエンドの知識も求められるため、フルスタックな動きができると重宝される。
Flutterの案件傾向：
- ゼロイチの新規開発案件が圧倒的に多い。
- スタートアップのMVP開発（プロトタイプ作成）や、受託開発会社での採用率が爆上がりしている。
- 「とにかく早くリリースしたい」という案件ではFlutter一択になりつつある。
- 単価はピンキリだが、需要過多のため上昇傾向。
副業エージェントの担当者と話すと、「最近は新規案件の7割くらいがFlutter指定ですね」なんて声も聞きます。これから「新しく副業を始める」のであれば、Flutterの方が案件の入り口は広いかもしれません。
学習コストと収益化までのスピード
Web経験者なら：
間違いなくReact Nativeが速いです。
JavaScriptを知っていれば、学習コストは実質「React Native特有のAPI」を覚えるだけ。1ヶ月もあれば簡単なアプリは作れるようになります。すぐに副業案件に応募できるでしょう。
完全未経験、またはサーバーサイド出身なら：
Flutterをおすすめします。
環境構築のトラブルが少なく（React Nativeはここで心が折れる人が多いです、本当に）、ドキュメントや公式のYouTubeチャンネルがめちゃくちゃ親切です。「型」のあるDart言語は、初心者にとってもバグを生みにくい。結果として、アプリ完成までの最短ルートを走れます。
技術選定の落とし穴：現場で直面する「想定外」
いい話ばかりしていても信用できないと思うので、私が現場で踏み抜いた「地雷」の話もしておきます。これを事前に知っているかどうかで、あなたの副業ライフの生存率が変わります。
React Nativeの地雷：ライブラリのバージョン地獄
React Nativeは、コミュニティ主導のライブラリに頼る部分が大きいです。これが諸刃の剣になります。
ある日、iOSの大型アップデートが入ると、使っていたカメラ機能のライブラリが突然ビルドエラーを吐くようになる。作者のリポジトリを見に行くと、最終更新が2年前…。
「嘘だろ…」
これを自力で直す（ネイティブのObjective-CやJavaコードをいじる）羽目になった時の絶望感と言ったらありません。
「JavaScriptだけで書ける」と思って油断していると、エラーログに出てくるネイティブコードを見て呆然とすることになります。これがReact Nativeの洗礼です。
Flutterの地雷：OS独自機能への弱さ
Flutterは独自描画が売りですが、それは逆に言うと「OS標準のUI」とは別物ということです。
例えば、iOSの最新バージョンで追加されたばかりの「新デザインのメニュー」や「AR機能」を使いたい時。Flutterだと対応されるまでにタイムラグがあったり、再現度が微妙だったりすることがあります。
また、Bluetoothやセンサー類をゴリゴリに使うIoT連携アプリなどでは、結局ネイティブ側のコード（MethodChannel）を大量に書くことになり、「これなら最初からSwiftで書けばよかった…」と後悔した経験があります。
「ネイティブの機能をディープに使う」案件には注意が必要です。
あなたはどっち？タイプ別・技術選定診断
ここまで読んでもまだ迷っているあなたへ。
私がメンターとして相談を受けた時に使っている「判断基準」を授けます。
タイプA：React Nativeを選ぶべき人
- React / JavaScriptの実務経験がある（これは絶対的なアドバンテージ）
- 将来的にWebフロントエンドもやっていきたい
- Web版とアプリ版を同時に開発したい、コードを共有したい
- UIのデザインが「OS標準」っぽくなくても許される（独自のブランドデザインが強い）
- Meta（Facebook）のエコシステムが好きだ
タイプB：Flutterを選ぶべき人
- Java / C# などの静的型付け言語の経験がある
- Web経験はなく、これからプログラミングを始める
- 個人開発で、デザインまで一人でこだわりたい
- AndroidとiOSで全く同じ見た目のアプリを作りたい
- Firebaseを使って爆速でリリースまで持っていきたい
- Googleの技術力を信じている
正直、今の市場価値としてはどちらを選んでも食いっぱぐれることはありません。
重要なのは「自分の持っている手札（経験）」と「作りたいもの」の相性です。
副業案件獲得へのロードマップ
技術を選んだら、次は案件獲得です。
ここでも、React NativeとFlutterでは戦略が少し変わります。
React Nativeの場合：Webの実績を武器にする
React Nativeの案件に応募する際は、「Reactでの開発経験」を前面に押し出しましょう。
「ReactのHooksやReduxの知見があるので、キャッチアップは早いです」
この一言がクライアントに刺さります。Web系の企業は、アプリもWebと同じフローで開発したいと考えていることが多いからです。
Flutterの場合：個人アプリを武器にする
Flutterの場合は、とにかく「一本作りきった実績」が物を言います。
簡単なツールアプリでもいいので、Firebaseと連携したアプリをストアにリリースしてみてください。
「デザインからバックエンド連携まで、一人で完結できます」
この証明ができれば、スタートアップのCTOなどは喜んであなたを採用します。彼らは「部分的な作業者」ではなく「丸投げできるパートナー」を探しているからです。
よくある質問（FAQ）に本音で答える
ここで、私がよく聞かれる質問に、忖度なしで答えておきます。
Q. ネイティブ（Swift/Kotlin）はもうオワコンですか？
A. 絶対にそんなことはありません。
むしろ、クロスプラットフォームが普及すればするほど、「ネイティブ側の深い知識があるエンジニア」の希少価値は上がります。クロスプラットフォームの裏側で起きているバグを直せるのは彼らだからです。
ただ、「最初の入り口」としてはハードルが高いし、副業でライトなアプリを作るならオーバースペックなことが多い、というだけです。
Q. Macは必須ですか？
A. 悪いことは言わないので、Macを買ってください。
Windowsでも開発はできますが、iOSアプリのビルド（動作確認）ができません。「iPhoneユーザーもターゲットです」という案件を受けるなら、Macがないとお話になりません。中古のMac mini（M1チップ以降推奨）でもいいので用意しましょう。これは必要経費であり、投資です。最初の案件でペイできます。
Q. 将来性があるのはどっちですか？
A. 勢いはFlutter、安定はReact Native。
Googleトレンドなどを見ても、世界的な関心度はFlutterがReact Nativeを追い抜いています。しかし、React NativeにはWebという巨大な後ろ盾があるため、消えることはまずありません。
「流行りに乗りたい」ならFlutter、「潰しが効くスキルがいい」ならReact Native、という感覚でOKです。
迷っている時間はもったいない。エディタを開こう
ここまで10,000文字近く、React NativeとFlutterについて語ってきました。
それぞれの強み、弱み、そしてお金の話。
ある程度の判断材料は提供できたかなと思います。
でも、最後にこれだけは言わせてください。
「どちらを選んでも、正解にするのはあなた自身です」
技術選定に「絶対的な正解」はありません。あるのは「その時の自分とプロジェクトに合った最適解」だけです。
React Nativeを選んで成功しているエンジニアもいれば、Flutterに移行して年収を倍にしたエンジニアもいます。逆に、どちらを選んでも中途半端で終わる人もいます。
その差は何か？
「実際に手を動かして、アプリをリリースまで持っていったかどうか」です。
どれだけ高尚な比較記事を読んでも、あなたがコードを書かなければ何も始まりません。
環境構築でエラーが出て、挫折しそうになることもあるでしょう。
思った通りのUIが作れなくて、イライラすることもあるでしょう。
それでも、泥臭く手を動かし続けた人だけが、エンジニアとしての市場価値を手に入れます。
React NativeでWebの知識をフル活用して戦うのもいい。
Flutterで新しいパラダイムに飛び込んで、爆速開発を極めるのもいい。
どちらの道を選んでも、そこには「アプリを作れる」という強力なスキルが待っています。
それは、あなたの副業収入を支える柱になり、キャリアの選択肢を広げる翼になります。
まずは今日、どちらかの公式サイトを開いて、「Get Started」のボタンを押してみてください。
最初の「Hello World」が画面に出た瞬間、あなたのエンジニア人生の新しい章が始まります。
その一歩を、私は心から応援しています。
さあ、ブラウザの比較記事を閉じて、ターミナルを開きましょう。
あなたの書くコードが、世界の誰かのスマホで動く日を夢見て。
