モバイルエンジニアの職務経歴書の書き方｜書類通過率を上げる実例テンプレート
モバイルエンジニアの職務経歴書は、「何を作ったか」の羅列になりがちな職種である。しかし採用担当者や技術責任者が実際に評価するのは、技術選定の背景・チームでの役割・数値化された成果の三点であり、これらが明示されているかどうかが書類通過率の分岐点になりやすい。本稿では、iOSおよびAndroidエンジニアが職務経歴書を構成する際の実務的な考え方と、書類審査を通過しやすくするための具体的な記述例を解説する。
モバイルエンジニアの職務経歴書が抱える構造的な課題
モバイル開発の職務経歴書には、他の職種にはあまり見られない固有の難しさがある。代表的なのは次の三点だ。
アプリ名を書けないケースが多い BtoBのSaaSや業務システムでは、アプリ名を記載すると守秘義務に抵触する可能性があるため、開発内容を具体的に説明しにくい。
技術の陳腐化が早い SwiftUI・Jetpack Composeなど比較的新しい宣言的UIフレームワークが台頭したことで、数年前の経験がどの程度現場で通用するのか、読み手が判断しにくい。
役割が見えにくい 「メンバーとして開発に参加」という記述では、設計を担ったのか、実装専業だったのか、コードレビューを主導したのかが伝わらない。特に5〜10人規模の中規模チームで働いていたエンジニアほど、役割の曖昧さが顕在化しやすい。
これらを解消するには、記述の構造そのものを変える必要がある。
職務経歴書の全体構成
標準的な構成は以下のとおり。分量の目安は2ページ（A4換算）で、スキル要約を冒頭に置くことで読み手が全体像を把握しやすくなる。
| セクション | 内容の概要 | 目安分量 |
|---|---|---|
| 職務要約 | 専門領域・経験年数・強みの3点を3〜5文で | 100〜150字 |
| スキルマップ | OS・言語・FW・ツールをカテゴリ別に整理 | 箇条書き |
| 職務経歴（逆年代順） | プロジェクト単位で記述 | メイン |
| 自己PR | 技術的な強みと再現性の提示 | 200〜300字 |
職務要約の書き方
採用担当者が最初に目を通すのが職務要約である。ここで「この候補者が何者か」を即座に伝えられるかどうかで、残りのページを丁寧に読んでもらえるかが変わりやすい。
良くない例：「iOSエンジニアとして5年の経験があります。Swift・Objective-Cを使った開発が得意です。」
改善例：「Swift（歴4年）およびReactNative（歴2年）でのモバイル開発を主軸に、直近ではチームリードとして設計・コードレビュー・後輩指導を担当。月間アクティブユーザー数50万規模のBtoC向けサービスにおいて、クラッシュ率を0.8%から0.2%まで改善した実績あり。」
後者は文字数は増えるが、技術領域・規模感・成果の三点が一段落で把握できる構成になっている。
スキルマップの記載方法
スキルは「ただ並べる」ではなく、熟練度を分類して示すことが望ましい。書き方には自由度があるが、以下のような軸で整理すると読み手が評価しやすくなる。
| カテゴリ | 主な項目例 | 熟練度の目安表記 |
|---|---|---|
| 言語（iOS） | Swift / Objective-C | 実務3年以上 / 実務1年 |
| 言語（Android） | Kotlin / Java | 実務4年以上 / 補助的に使用 |
| クロスプラットフォーム | Flutter / ReactNative | 実務2年 |
| アーキテクチャ | MVVM / Clean Architecture / MVI | 設計主担当 |
| CI/CD | Fastlane / GitHub Actions / Bitrise | 環境構築経験あり |
| テスト | XCTest / JUnit / Espresso | 単体・UIテスト作成経験あり |
| バックエンド連携 | REST / GraphQL / Firebase | 基本的な実装経験あり |
「できる」という一語では判断材料にならない。実務での経験年数、設計まで担当したか実装のみか、という区別を明示することで、面接での技術的な深掘りにも対応しやすくなる。
職務経歴の書き方：プロジェクト単位での記述構造
プロジェクト単位で以下の要素を揃えることが基本となる。
【プロジェクト名または概要】
期間：20XX年X月〜20XX年X月
チーム規模：X名（モバイルエンジニアX名・バックエンドX名・デザイナーX名）
担当OS：iOS / Android / 両OS
主な使用技術：Swift 5.x / UIKit・SwiftUI / MVVM / Fastlane / GitHub Actions
【担当役割と業務内容】
・〜〜の機能設計および実装を主担当として対応
・コードレビューを週次で実施（対象：モバイル担当全員）
・ライブラリ選定会議に参加し、〜〜を採用する技術提案を実施
【成果・インパクト】
・アプリ起動時間を平均1.8秒から0.9秒に短縮（Instruments計測）
・リリース後3ヶ月でApp Storeレーティングが3.2→4.1に改善
・クラッシュ率を月次0.6%から0.15%に改善
守秘義務がある場合の記述例
アプリ名を出せない場合は、以下のように業態・規模感・課題を軸に記述する方法が有効だ。
「国内の金融機関向けに提供するBtoBアプリ（企業内利用者数：約3,000名規模）の刷新プロジェクトにおいて、iOS版の設計および実装を主担当。既存のObjective-CコードをSwiftへ段階的に移行しつつ、テストカバレッジを0%から65%まで整備した。」
具体的な名称を伏せながら、規模・課題・役割・成果の四点を盛り込むことで情報量は確保できる。
ケーススタディ：経験5年・中堅iOSエンジニアの書類改善例
Before（改善前の記述）
「株式会社○○にてiOSエンジニアとして勤務。SwiftおよびObjective-Cを使ったアプリ開発を担当しました。チームメンバーと協力しながら機能追加・バグ修正を行い、リリース対応なども経験しました。」
この記述の問題点は三つある。チームでの役割が不明、数値化された成果がない、技術スタックが浅い列挙にとどまっている、の三点だ。
After（改善後の記述）
「〜〜向けライフスタイルアプリ（月間アクティブユーザー：20万規模）のiOS版開発において、機能実装からApp Storeリリースまでを一貫して担当。アーキテクチャをMVC→MVVMに移行する際の設計方針策定に参画し、画面ごとの責務分離を推進。また、GitHubActionsを用いたCI/CD環境を整備し、リリースにかかる手動作業を週あたり約4時間削減した。Xcodeのパフォーマンスプロファイリングツールを用いたボトルネック分析により、特定画面のスクロールパフォーマンスを60fpsで安定稼働させる改善を実施した。」
同じ経験を持つエンジニアであっても、記述の粒度と構造によって伝わる情報量が大きく変わる。
よくある質問
Q. 使用したライブラリはすべて書くべきですか？
全列挙は不要であり、むしろ読み手の負担を増やすことが多い。選定に自分が関わったもの、設計レベルで理解しているもの、採用先が重視しそうな技術スタックに絞って記載する方が、技術的な判断力を示しやすい。
Q. iOSとAndroidの両方を経験している場合、どう整理するのがよいですか？
スキルマップでOSを分けて記載しつつ、職務経歴はプロジェクト単位で記述するのが一般的な整理方法だ。「どちらがより深い経験か」を明示しておくと、採用側がポジション要件とのマッチングをしやすくなる。両OSを同等に扱おうとすると、どちらも浅く見える傾向があるため、主軸と補完という位置づけを文章で示しておくことが望ましい。
Q. 個人開発のアプリは職務経歴書に含めてよいですか？
含めてよいが、「業務経験」と混在させずに「個人開発・サイドプロジェクト」のセクションを分けて記載するのが誠実な書き方だ。ダウンロード数・レーティング・継続期間など、第三者が確認できる情報を添えると評価の基準が生まれやすい。
Q. 経験年数が浅い場合（1〜2年）、どこを強調すべきですか？
経験量で勝負するのではなく、技術的な理解の深さと学習の質を示すことが有効だ。具体的には、「なぜその技術を選んだか」「問題をどのように分析・解決したか」というプロセスの記述を充実させること、および社内勉強会での登壇・技術ブログ・OSSへのコントリビューション等の補足情報を加えることで、評価の引き上げにつながりやすい。
まとめ
モバイルエンジニアの職務経歴書において書類通過率を高める核心は、技術スタックの羅列を超えた「役割・判断・成果」の三点を構造的に示すことにある。守秘義務のある案件であっても、規模感・課題・解決アプローチという軸で記述を組み立てることで、情報量は十分に確保できる。スキルマップは熟練度の分類まで行い、プロジェクト記述は数値と役割を必ずセットにすることが基本的な作法だ。市場のニーズとの整合性を自分で判断することが難しい場合は、現在の職務経歴書をもとにキャリアアドバイザーへの相談を検討することで、自身の市場価値をより客観的に把握できる可能性がある。