OSと言語の対応
iOSはSwift、AndroidはKotlin。両OS対応の新規開発ではFlutter / React Nativeがよく出ます。
00 / First Map
まず覚える4点
最初から細かい技術名を全部覚える必要はありません。新人営業は、まずこの4点を案件概要・スキルシート・面談の共通地図として持ってください。
新しめと既存保守
SwiftUI / Jetpack Composeは新しめ。UIKit / XMLは既存アプリ保守で多いです。
技術名以外を見る
リリース経験、API連携、Push通知、Firebase、状態管理、担当工程まで確認します。
Flutter経験の扱い
Flutter経験は両OS対応に強い材料ですが、Swift / Kotlinのネイティブ経験とは別物です。
Figure 01 / OS × 言語 × UI 対応マップ
01 / Why
この技術を営業が知る意味
アプリ案件は言語名だけで判断するとミスマッチが起きます。OS、UIフレームワーク、ストアリリース、API連携、端末対応、チーム体制まで含めて読むと、提案精度が上がります。
営業が見るべき中心は「何のアプリを、どの方式で、どこまで担当したか」
SwiftはiOS、KotlinはAndroid、FlutterはiOSとAndroid両方を1つの技術で作る案件によく出ます。ただし、Swift経験があれば全iOS案件に合うわけでも、Flutter経験があればネイティブ案件にそのまま合うわけでもありません。
アプリ開発では、画面実装だけでなく、REST API連携、Push通知、Firebase、アプリ内課金、ストア申請、クラッシュ対応、UI/UX、CI/CDなどが評価対象になります。
営業向けポイント
「Swift経験3年」ではなく「Swiftで、UIKit/SwiftUIを使い、どの機能を担当し、ストアリリースまで経験したか」を聞くと、提案で強みを説明できます。
案件概要の技術名
スキルシートの担当範囲
面談での深掘り
提案コメント
02 / Basics
技術の概要
この章では、営業が案件概要で使える粒度で、スマホアプリ開発の基本を整理します。まずはネイティブ、クロスプラットフォーム、PWAの違いを押さえます。
押さえるポイント
「iOS / Android / 両OS対応 / Web寄り」のどれかを最初に分類します。分類できると、見るべき技術名と確認質問が一気に絞れます。
Swift
案件で見る点: SwiftUI / UIKit / App Store経験
Kotlin
案件で見る点: Jetpack Compose / XML / Google Play経験
Flutter / React Native
案件で見る点: 両OSビルド、状態管理、ネイティブ連携
PWA
案件で見る点: 通常のスマホアプリ案件とは要件が違う
ネイティブアプリ
iOSはSwift、AndroidはKotlinでそれぞれ専用に開発します。性能、OS固有機能、品質を重視する大規模アプリや既存サービスで多い方式です。
- iOS: Xcode、SwiftUI、UIKit、TestFlight
- Android: Android Studio、Jetpack Compose、XML、Gradle
クロスプラットフォーム
FlutterやReact Nativeで、1つのコードベースからiOSとAndroidに対応します。短期開発、新規事業、MVPでよく選ばれます。
- Flutter: Dart、Hot Reload、UI表現力
- React Native: JavaScript、TypeScript、React経験が活きる
Webアプリ風の体験
ブラウザベースでアプリのように使える方式です。ストア配布やOS固有機能が重要な案件では、ネイティブやFlutterと要件が異なります。
Kotlin Multiplatform
Kotlinでロジックやデータ層をiOSとAndroidで共有し、UIは各OSのネイティブで作る方式です。成熟度や採用状況は案件ごとに確認が必要です。
ネイティブとクロスプラットフォームの比較
スマホでは表を横にスクロールできます。重要な比較は上のカードでも確認できます。
| 観点 | ネイティブ Swift / Kotlin | Flutter / React Native |
|---|---|---|
| 性能 | 最も高く、OS機能も使いやすい | 差は縮小中だが、OS固有機能は確認が必要 |
| 開発コスト | iOSとAndroidを別々に作る | 1コードで両OS対応しやすい |
| 案件傾向 | 既存アプリ保守、大規模サービス、高品質アプリ | 新規開発、スタートアップ、短期MVP |
| 営業の確認点 | SwiftUIかUIKit、ComposeかXML、ストア経験の有無 | Dart/Flutterの実務年数、ネイティブ連携、両OSリリース経験 |
Figure 02 / ネイティブ と クロスプラットフォームの作り方
03 / iOS & Android
SwiftとKotlinの押さえどころ
案件概要では言語名だけでなく、UI方式、ライブラリ管理、ビルド、リリース、OS固有機能を一緒に見ます。
押さえるポイント
「Swift経験3年」だけで判断せず、SwiftUI / UIKit、担当機能、App Store対応まで確認します。AndroidもCompose / XML、Google Play対応まで聞きます。
iOS開発 Swift
SwiftはApple公式の言語で、iPhone、iPad、Apple Watch、Macアプリに使われます。Objective-Cの後継として設計され、型安全でモダンな文法が特徴です。
- Xcode: Mac専用のApple公式IDE
- SwiftUI: 新規開発で増えている宣言的UI
- UIKit: 既存案件で非常に多い従来型UI
- SPM / CocoaPods: ライブラリ管理
- TestFlight / App Store審査: リリース実務の重要経験
Android開発 Kotlin
KotlinはGoogleがAndroid公式言語として採用した言語です。Javaと共存でき、null安全、簡潔な文法、コルーチンによる非同期処理が強みです。
- Android Studio: Google公式IDE
- Jetpack Compose: 新規開発で増えている宣言的UI
- XMLレイアウト: 既存保守でまだ多いUI方式
- Gradle: ビルドと依存関係管理
- Firebase / Google Play: 通知、認証、クラッシュ、リリース
案件概要で出たときの読み替え
SwiftUI
新しめのiOS画面実装。新規開発寄り。経験者はまだ相対的に少ない。
UIKit
既存iOSアプリで多い。保守、追加開発、レガシー改修で強い。
Jetpack Compose
新しめのAndroid画面実装。KotlinでUIを宣言的に書く。
XML
既存Android案件で多い。保守案件では現役の確認ポイント。
04 / Job Ticket
SES案件での使われ方とキーワード
アプリ案件は「開発方式」「担当工程」「連携先」「リリース経験」の4つで読みます。技術名だけの一致で出すと、面談で深さ不足が出やすい領域です。
押さえるポイント
案件概要は「対象OS」「新規か保守か」「UI方式」「API・通知・Firebaseなどの機能」「リリース経験」の順に読みます。
iOS案件でよく見るキーワード
SwiftSwiftUIUIKitXcodeObjective-CSPMCocoaPodsTestFlightApp Store申請Auto Layout
Android案件でよく見るキーワード
KotlinJavaAndroid StudioJetpack ComposeXMLGradleFirebaseGoogle PlayMaterial DesignR8
Flutter案件でよく見るキーワード
FlutterDartHot ReloadWidgetRiverpodProviderBLoCiOS/Android両対応ネイティブ連携
共通して見るキーワード
REST APIGraphQLMVVMMVCClean ArchitectureCI/CDGitPush通知クラッシュ解析アプリ内課金
案件概要で必ず見る観点
- 対象OSはiOSのみ、Androidのみ、両OS対応のどれか
- 新規開発か、既存アプリの保守改修か
- UI実装だけか、API連携、DB、通知、課金、リリースまで含むか
- SwiftUI / UIKit、Compose / XML、Flutterの状態管理など、指定技術があるか
- 単独実装か、リード、設計、レビュー、技術選定まで求めるか
Figure 03 / アプリ案件を読む 4 つの軸
05 / Domains
代表的な案件領域
アプリ開発はBtoCだけではありません。業務アプリやIoT連携でもモバイル経験が必要になります。
金融・決済
本人確認、セキュリティ、Push通知、アプリ内の取引体験が重要。品質と審査対応の経験が評価されます。
EC・予約・会員アプリ
ログイン、商品検索、購入、決済、クーポン、Push通知など。API連携経験が見られます。
ヘルスケア・位置情報
HealthKit、Google Fit、位置情報、BluetoothなどOS固有機能の理解が強みになります。
業務・社内アプリ
タブレット、現場入力、カメラ、バーコード、オフライン同期。BtoBでもアプリ経験は需要があります。
06 / Skill Sheet
スキルシートの読み方
アプリ開発のシートは、技術名よりも「どのアプリで、どの機能を、どの工程で、どこまで責任を持ったか」を読みます。
押さえるポイント
技術名の数より、担当機能と本人の役割を見ます。リリース経験は「アプリが出た」ではなく「本人が何を担当したか」まで確認します。
Flutterを用いたECアプリ開発
- 工程
- 詳細設計、実装、単体テスト、ストア申請補助
- 技術
- Flutter、Dart、Riverpod、Firebase、REST API、GitHub Actions
- 担当
- 商品一覧、カート、Push通知、クラッシュ対応
- 見る点
- 画面だけでなく、状態管理、API、Firebase、リリース周りまで触れているか
ストアリリース経験
App StoreやGoogle Playに出した経験は強い証明です。個人アプリでも、審査や配布を通した経験は面談で補足できます。
UI方式と既存改修
SwiftUIだけかUIKitもできるか、ComposeだけかXMLも読めるかで、既存保守への適性が変わります。
APIと状態管理
一覧表示だけでなく、ログイン、API通信、エラー処理、状態管理まで説明できるかを見ます。
チームでの役割
実装者、設計者、レビュー担当、リードで提案先が変わります。単独開発かチーム開発かも確認します。
強く読める記載
- ストア申請、TestFlight、Google Play Consoleの経験
- SwiftUIとUIKit、ComposeとXMLの両方に触れている
- MVVM、Clean Architecture、状態管理の記載がある
- Firebase、Push通知、課金、位置情報など機能単位の経験がある
追加確認が必要な記載
- 「Flutter開発」とだけあり、担当機能が書かれていない
- 研修、個人開発、チュートリアルの区別が曖昧
- リリース経験ありとあるが、本人の担当範囲が不明
- iOS/Android両対応とあるが、片方だけの検証かもしれない
07 / Interview
登録面談で聞くこと
技術テストではなく、提案に必要な根拠を集める面談です。案件概要の条件に対して、候補者の経験を具体化します。
押さえるポイント
面談では「できますか」ではなく「何を、どの技術で、どこまで担当しましたか」と聞きます。曖昧な回答は提案コメントで盛らないことが大切です。
基礎確認
- Swift、Kotlin、Flutterのうち、実務で使ったものはどれですか
- ネイティブとFlutterの使い分けをどう理解していますか
- SwiftUIとUIKit、ComposeとXMLの経験範囲を教えてください
- REST API連携、ログイン、Push通知、課金の経験はありますか
- ストアリリースや審査対応に関わったことはありますか
中上級確認
- 状態管理は何を使い、どのように設計しましたか
- MVVMやClean Architectureをどこまで担当しましたか
- クラッシュやパフォーマンス問題をどう調査しましたか
- CI/CD、テスト、自動配布の経験はありますか
- 技術選定、レビュー、メンバー育成を担当しましたか
深掘り例
「Flutter経験あり」とありますが、画面実装だけか、API連携や状態管理、iOS/Android両方のビルドまで担当したか教えてください。
深掘り例
「リリース経験あり」は、申請作業を担当したのか、リリース前の不具合対応や審査リジェクト対応まで関わったのか確認してもよいですか。
08 / Level
レベル感の見極めと △ / ○ / ◎ 判定例
年数だけではなく、担当工程、リリース、設計、トラブル対応、リード経験で見極めます。
押さえるポイント
△は「経験名だけ」、○は「担当機能と工程を説明できる」、◎は「設計・改善・リリース・トラブル対応まで語れる」と見ます。
実装補助、チュートリアル相当
基本文法や簡単な画面作成が中心。既存コードの修正、テスト、軽微改修から提案しやすいです。
確認軸実務か個人開発か、チームでの作業経験があるか。
機能単位で任せられる
API連携、DB、状態管理、ストアリリースなどの経験があり、詳細設計から実装まで担当できます。
確認軸担当機能、障害対応、リリース経験の具体性。
設計、改善、リードができる
アーキテクチャ、テスト、CI/CD、パフォーマンス、セキュリティ、レビュー、技術選定まで見られます。
確認軸判断した内容、改善結果、チームへの影響。
Figure 04 / 回答の深さで見る △ ○ ◎
スマホでは判定表を横にスクロールできます。△ / ○ / ◎ の違いは、回答の具体性と本人の判断範囲で見ます。
| 質問 | 弱い回答 | 提案可能 | 強く推せる |
|---|---|---|---|
| Flutterで何を担当しましたか | 画面をいくつか作りました。 | 商品一覧、詳細、カート画面を実装し、REST APIとRiverpodで状態管理しました。 | 設計方針、状態管理、共通Widget、両OSビルド、Firebase Crashlyticsまで担当しました。 |
| iOSのリリース経験はありますか | リリースされたアプリに参加しました。 | TestFlight配布、リリース前修正、App Store申請補助を担当しました。 | 審査リジェクト対応、証明書、プロビジョニング、リリース手順整備まで担当しました。 |
| 既存Android案件に入れますか | Kotlinは少し触りました。 | KotlinでAPI連携とXML画面改修の経験があります。 | Java混在の既存コードを読み、XMLからComposeへの段階移行やGradle改善も経験しています。 |
| パフォーマンス改善経験はありますか | 重い画面を直しました。 | 一覧の描画遅延を調査し、画像読み込みとAPI呼び出しを見直しました。 | 計測、原因切り分け、メモリリーク対応、クラッシュ率改善まで数値で説明できます。 |
09 / Mismatch
営業がミスりやすい提案
アプリ案件は、同じモバイル領域でも技術スタックと担当範囲の違いが大きいです。よくあるミスを先に避けます。
スマホでは表を横にスクロールできます。ミスの種類だけでなく、提案前に確認することまで見てください。
| よくあるミス | なぜ危ないか | 提案前に確認すること |
|---|---|---|
| Flutter経験者をSwift案件にそのまま提案する | ネイティブiOSのUIKit、SwiftUI、Xcode運用が不足する場合があります。 | Swift実務、iOS固有機能、App Store対応の経験。 |
| SwiftUIのみの人をUIKit保守案件に出す | 既存iOSアプリはUIKitが多く、コード読解で詰まる可能性があります。 | UIKit、Auto Layout、Objective-C混在の有無。 |
| 個人アプリを大規模実務経験として扱う | チーム開発、レビュー、品質管理、リリース手順が別物です。 | チーム人数、担当工程、レビュー経験、障害対応。 |
| 「両OS対応可」を広く見すぎる | Flutterで両OS対応と、Swift/Kotlin両方できるは意味が違います。 | Flutterなのか、iOSとAndroidのネイティブ両方なのか。 |
| リリース経験ありを鵜呑みにする | 申請担当ではなく、開発したアプリがリリースされただけのことがあります。 | 本人が担当したリリース作業、審査対応、配布手順。 |
10 / Practice
案件概要読み解き演習
ここからは営業判断の練習です。案件概要と候補者情報を見て、提案可否、面談での追加確認、提案コメントの補足を考えます。
Flutter経験者をUIKit保守に出せるか
案件概要
- Swift / UIKit
- 既存アプリ保守
- REST API
- App Store申請補助
- 尚可: Objective-C、クラッシュ解析
候補者
- Flutter経験2年
- Swiftは個人開発のみ
- App Store公開経験あり
問い: この候補者をそのまま提案してよいか。面談で何を確認し、提案コメントでどう補足するか。
回答観点を見る
そのまま強く提案するのは危険です。Flutter経験だけではUIKit保守への適性は判断できません。Swift実務、UIKit、既存コード読解、Objective-C混在、App Store対応で本人が何を担当したか確認します。個人開発は補足材料になりますが、実務経験と誤解されないように表現します。
Swiftメインの候補者をFlutter必須案件に出せるか
案件概要
- Flutter / Dart
- Riverpod
- Firebase
- iOS・Android両OSリリース必須
- 新規開発、短期リリース
候補者
- Swift実務4年
- UIKit保守とApp Store対応あり
- Flutterは学習のみ
問い: Swift経験を強みに提案できるか。追加確認とコメントの注意点は何か。
回答観点を見る
Flutter必須・短期リリースなら、Swift経験だけでは即戦力判断は弱いです。Dart、Widget実装、Riverpod、Firebase、Android側ビルド、両OSリリース経験を確認します。提案するなら「iOSリリース経験は強いが、Flutter実務は未経験」と明確に補足し、キャッチアップ枠として相談します。
Compose中心の若手をXML/Java混在に出せるか
案件概要
- Kotlin
- XMLレイアウト
- Java混在コード
- Google Play対応
- 既存不具合調査
候補者
- Android実務1年半
- Jetpack Compose中心
- XMLは研修で少し
- Google Play申請は未経験
問い: 若手枠として提案できるか。面談で確認すべき経験は何か。
回答観点を見る
若手枠なら可能性はありますが、即戦力としては注意が必要です。XML読解、Java混在コードの修正経験、既存不具合の調査手順、Gradle、Google Play対応の関与有無を確認します。提案コメントではCompose中心であることと、XML/Javaはキャッチアップ範囲であることを正直に補足します。
11 / Proposal
提案時の注意点とコメント例
提案コメントは「技術名の羅列」ではなく、案件側の不安を先回りして補足します。
押さえるポイント
提案コメントは「経験があります」で止めず、案件に合う根拠を1つ添えます。不足がある場合は、個人開発・学習・類似経験を誤解なく補足します。
提案時の注意点
- 対象OS、UI方式、状態管理、リリース経験を明記する
- Flutterの場合は、iOS/Android両方のビルドやストア対応経験を補足する
- 既存保守案件では、レガシー技術を読めるかを補足する
- 個人開発の場合は、実務経験と誤解されないように価値を整理する
- 上級案件では、設計、レビュー、改善、技術選定の根拠を添える
12 / Check
確認テスト
知識の暗記ではなく、案件に候補者を提案してよいか、面談で何を追加確認するか、コメントでどう補足するかを確認します。
1. Swift案件でSwiftUIとUIKitの違いを確認する理由は？
回答観点: 新規開発はSwiftUIが増えている一方、既存保守はUIKitが多い。案件適性が変わるため。
2. Flutter経験2年の候補者をSwift/UIKit保守案件に提案してよいですか？
回答観点: そのまま強く提案するのは危険。Swift実務、UIKit、既存コード読解、iOS固有機能、App Store対応を追加確認する。
3. スキルシートで「リリース経験あり」と見たら何を聞く？
回答観点: 本人が申請、配布、審査対応、リリース前不具合修正のどこを担当したか。
4. Android保守案件でCompose経験だけを見ると危ない理由は？
回答観点: 既存Android案件ではXMLやJava混在が多く、既存コード読解力が必要なため。
5. Flutter新規開発案件で、提案コメントでは何を強調する？
回答観点: Dart/Flutter実務、状態管理、API連携、Firebase、iOS/Android両OSビルド、ストアリリース経験。Swift経験だけを強みにしすぎない。
6. 危ない提案パターンを1つ挙げ、面談での追加確認を言ってください。
回答観点: 例: 個人アプリを実務経験のように出す。追加確認はチーム開発、担当工程、レビュー、リリース作業、障害対応の有無。
13 / Summary
まとめ
アプリ案件の提案精度は、技術名の一致ではなく、経験の深さと案件要件の接続で決まります。
案件概要
Swift、Kotlin、Flutterだけでなく、OS、UI方式、担当工程、リリース範囲を確認する。
スキルシート
担当機能、API連携、状態管理、ストア経験、チームでの役割を読む。
面談
「やったこと」から「本人が判断、実装、改善したこと」まで深掘りする。
提案
案件側の不安に対して、適合理由と補足材料をコメントで添える。
提案コメント例