iOSエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

iOSエンジニアのスキルシートは、アプリごとに「SwiftUIとUIKitの比率」「最低対応OS」「リリースにどこまで関わったか」を書くのが基本です。iOSの案件では、同じSwiftの経験でも、画面の作り方と、申請や審査に自分が関わったかどうかで任せられる範囲が変わるためです。公開されているアプリのストアURLは、載せてよいかを先に確かめ、載せる場合は自分の担当範囲と一緒に書きます。

この記事では、iOSならではの書き方と記入例を紹介します。案件で見られるスキルの中身はiOSの案件で求められるスキル、独立の準備はiOSエンジニアがフリーランスになるにはで扱っています。

プロジェクトは「アプリ単位」で書く

iOSのスキルシートは、基本的に1つのアプリを1つのプロジェクトとして書くと読みやすくなります。読み手は「どんなアプリを、どの段階で担当したか」でイメージをつかむからです。

アプリ単位で書くときに、冒頭に置きたい項目は次の4つです。

1つの参画で複数のアプリを担当した場合は、アプリごとに分けるか、主なアプリを1つ選んで詳しく書き、ほかは1〜2行にまとめます。

技術欄は「比率」と「対応OS」で深さを伝える

iOSの技術欄でよく見るのは、「Swift、SwiftUI、UIKit、Combine」と名前を並べる書き方です。これだけでは、SwiftUIで画面を設計したのか、UIKitの画面に少し組み込んだだけなのかが分かりません。

次のように、比率と対応OSを添えると、読み手は深さを判断できます。

• 画面の作り方：UIKit 7割・SwiftUI 3割（新しい画面からSwiftUIで作成）
• 非同期処理：コールバックとCombineが中心。新しい処理からasync/awaitへ書き換え
• Swiftの版と言語モード：Swift 5の言語モード。Swift 6への移行は一部のモジュールで着手
• 最低対応OS：参画時と離任時の最低対応OS（例：参画時はiOS 15、離任時はiOS 16）
• 設計：MVVM。画面遷移はCoordinatorで管理

これらは書き方を示すための例です。比率は厳密でなくてかまいません。「おおむね」で十分ですが、実際より新しい技術の比率を高く書かないことが大切です。

最低対応OSは、iOSならではの項目です。最低対応OSが古いほど、新しいAPIを使えない場面が増え、分岐の書き方や代替の実装の経験が積まれます。最低対応OSを上げる判断や作業に関わった場合は、担当内容にも書いておきましょう。

リリースへの関わり方を動詞で書き分ける

iOSの案件では、App Store Connectでの申請や審査の対応、証明書やプロビジョニングの管理を任せられるかが、よく確かめられます。ところが、スキルシートでは「リリース対応」とひとまとめにされがちです。

自分が実際にしたことを、次のような動詞で書き分けると伝わります。

「立ち会った」に当たる経験を「申請を担当した」と書くと、面談で手順を聞かれたときに答えられません。関わり方を正直に書き分けるほうが、任せられる範囲が正しく伝わります。

Xcodeの版上げや、Appleの提出要件に合わせた対応をした場合は、どの要件に対して何をしたかを1行で書きます。要件の内容はiOSの案件で求められるスキルで紹介しています。

公開アプリのストアURLの載せ方

iOSエンジニアのスキルシートで迷いやすいのが、App Storeで公開されているアプリのURLを載せるかどうかです。アプリは誰でも見られますが、そのアプリに自分が関わったことを書いてよいかは別の問題です。

載せる前に確かめること

• 契約や参画先の決まりで、関わったアプリ名を外部に出してよいとされているか
• 会社員時代のアプリなら、在籍していた会社の決まりに反しないか
• アプリ名から参画先の会社が分かることを、参画先が問題にしないか

確かめられない場合は、URLやアプリ名を書かずに「一般向けの予約アプリ」のように種類で書きます。判断の考え方はスキルシートに書いてよいこと・いけないことにまとめています。

載せる場合の書き方

載せてよいと確かめられたアプリは、URLだけを置かず、自分が担当した画面や機能を一緒に書きます。公開アプリは多くの人が開発に関わっているため、URLだけでは読み手が「このアプリ全体を作った人」と受け取ることがあるからです。

• ストアの評価やランキングは、自分の成果として書かない
• 配信が終わったアプリのURLは載せない（リンク切れは読み手の手間になる）
• 自分の担当画面が、今の公開版ではすでに作り直されている場合は、その旨を書く

個人開発のアプリ

個人で開発し、自分のアカウントで公開しているアプリは、URLを載せやすい実績です。この場合は、設計の方針、更新を続けている期間、OSの更新への対応を書き添えると、実務に近い経験として読まれます。業務で作ったアプリを個人のアカウントから公開しない点は、著作権の記事もあわせてご覧ください。

プロジェクト欄の記入例

ここでは、運用中のアプリで画面の移行とリリースを担当した場合を想定した記入例を示します。以下は書き方を示すための例で、実在のアプリや実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（1年3か月）
アプリ：生活関連サービス向け 一般利用者のiOSアプリ（運用中のアプリの機能追加）
配布・規模：App Storeで公開。利用者の規模は非公開
規模・立場：iOS 4名（自分はメンバー。後半はリリース担当を兼務）
使用技術：Swift、UIKit 6割・SwiftUI 4割、Combine → async/await、MVVM、XCTest、CI
最低対応OS：参画時と離任時で1つ引き上げ
担当内容：会員情報と設定まわりの画面をSwiftUIで作り直した。月1回程度の定期リリースで、申請と審査の指摘への対応を担当した
工夫・成果：通信処理をasync/awaitに書き換え、画面ごとにばらばらだったエラー表示をそろえた。TestFlightへの配布をCIで行うようにし、手作業の手順を減らした

Objective-Cや古いコードの経験の書き方

長く運用されているアプリでは、Objective-Cのコードが残っていることがあります。Objective-Cの経験は、古い部分を読める人として評価されることがあるので、隠さずに書きましょう。

• Objective-Cで新しく書いたのか、読んで直しただけか
• Swiftへの置き換えに関わったか、その範囲

「Swift◯年」とObjective-Cの年数を合算せず、別の行に書くと、読み手が判断しやすくなります。

よくある質問

SwiftUIの経験が個人開発だけの場合、どう書けばよいですか？

実務の行とは分けて、「個人開発で使用」と書きます。そのうえで、個人のアプリで何を作り、どんな設計にしたかを1〜2行添えると、学習の深さが伝わります。実務ではUIKitが中心でも、運用中のアプリの多くはUIKitの画面を含むため、その経験自体が評価の対象になります。

社内配布のアプリしか担当していません。不利になりますか？

社内配布のアプリでも、設計、テスト、証明書や配布の管理の経験は伝えられます。App Storeでの審査の経験がない点は、正直に書いたうえで、配布の仕組みをどう扱ったかを具体的に書きましょう。一般向けのアプリの案件に応募する場合は、個人開発で審査を経験しておくと補いになります。

iPadやApple Watchの対応も書いたほうがよいですか？

対応した経験があれば書いておきましょう。iPadの画面サイズへの対応や、Apple Watchなどのほかの端末との連携は、求める案件が限られるぶん、条件に合ったときに目に留まりやすい経験です。対応した範囲（画面の調整だけか、専用の機能まで作ったか）も添えます。