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

Androidエンジニアのスキルシートは、KotlinとJava、Jetpack ComposeとViewの比率、対象とするAPIレベル（targetSdk）が、参画している間にどう変わったかを書くのが基本です。Androidの案件の多くは運用中のアプリで、古い書き方から新しい書き方へ移す途中に入る仕事だからです。あわせて、検証した端末の範囲と、アプリの配布の方法（Google Play、社内配布など）を書くと、読み手は経験の中身をつかみやすくなります。

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

「今の状態」より「どう変えたか」を書く

Androidのスキルシートでよく見るのは、使用技術の欄に「Kotlin、Jetpack Compose、Coroutines、Hilt」と、離任したときの状態だけを書く形です。これでは、最初からその構成だったのか、自分が移したのかが分かりません。

運用中のアプリの案件では、「古い構成から新しい構成へ、開発を止めずに移した経験」が重く見られます。そこで、主なプロジェクトでは、参画したときと離任したときの状態を並べて書くことをおすすめします。

これは書き方を示すための例です。表にすると長くなる場合は、使用技術の欄に「Java → Kotlin」のように矢印で書き、担当内容で自分の関わりを説明する形でもかまいません。

大切なのは「自分の関わり」の列です。移行がチームの取り組みだった場合も、自分がどの部分を担ったかを書き分けます。

targetSdkの対応は「上げた幅」と「直したこと」で書く

Google Playの要件に合わせてtargetSdkを上げる作業は、Androidエンジニアが毎年のように向き合う仕事です。スキルシートでは「targetSdk対応」とだけ書くのではなく、次の2点を書くと伝わります。

• 上げた幅：どのAPIレベルからどのAPIレベルへ上げたか
• 直したこと：権限の扱い、通知、バックグラウンドの動作、画面の表示など、何に対応したか

たとえば「API 34から35へ引き上げ。端末の画面いっぱいに描画される変更に合わせて、各画面の余白の扱いを直した」のように、1〜2行で書けます。上記は書き方の例です。要件の時期や内容は変わるため、最新の情報はAndroid Developersの公式ページで確かめてください。

ネイティブのライブラリを含むアプリで、メモリのページサイズの要件に対応した経験なども、対応した内容を同じ形で書いておくと、同じ作業を控えた案件で目に留まります。

端末の対応範囲を書く

Androidは、メーカー、画面サイズ、OSの版がさまざまな端末で動きます。そのため、どの範囲の端末で動作を保証していたかは、Androidならではの経験の書きどころです。

• 最低対応のOSの版（minSdk）
• 検証に使った端末の範囲（主要メーカーの端末、タブレット、折りたたみ端末など）
• 特定の端末だけで起きた不具合を調べて直した経験

端末の機種名を細かく並べる必要はありません。「スマートフォンとタブレットの両方」「業務用の専用端末」のように、種類で書けば十分です。

配布の方法と、Google PlayのURLの扱い

Androidのアプリは、Google Playで一般に公開されるものだけではありません。業務用の端末に管理ツールで配るアプリ、限られた人にだけ配る検証用の配布など、配布の方法はさまざまです。スキルシートには、どの方法で配布していたかを書いておきましょう。配布の方法によって、ストアの審査や要件への対応の経験があるかが分かるからです。

Google Playで公開されているアプリのURLを載せる場合は、次の点に気をつけます。

• 関わったことを外に出してよいか：URLやアプリ名を載せてよいかは契約によります。考え方はスキルシートに書いてよいこと・いけないことをご覧ください
• ストアの表示を実績と混ぜない：Google Playのページにはインストール数の目安や評価が表示されますが、アプリ全体の結果であり、自分の担当範囲の成果ではありません。シートに転記するのは避けましょう
• 社内配布のアプリにはURLがない：無理にURLを用意する必要はなく、アプリの種類と配布の方法を書けば十分です

公開アカウントやアプリの署名の鍵を誰が管理していたかは、契約にかかわる部分です。署名の鍵の管理を任されていた場合も、スキルシートには「署名の設定とリリースの作業を担当」程度の書き方にとどめます。

プロジェクト欄の記入例

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

期間：20XX年X月〜20XX年X月（1年8か月）
アプリ：金融関連サービス向け 一般利用者のAndroidアプリ（運用中）
配布：Google Playで公開
規模・立場：Android 5名（自分はメンバー。後半は画面設計のとりまとめ）
使用技術：Java → Kotlin、View → Jetpack Compose、RxJava → コルーチンとFlow、Hilt、Room、JUnit
対応範囲：スマートフォンとタブレット。最低対応のOSの版は参画中に1つ引き上げ
担当内容：新しい画面をComposeで作成し、既存のViewの画面と共存させた。targetSdkの引き上げを担当し、権限と通知の変更に対応した
工夫・成果：Composeの共通部品と使い方の決まりを整え、画面ごとの見た目のばらつきを減らした。特定の端末だけで起きていた表示の不具合を再現し、原因を特定して直した

Javaの期間と、SDK・ライブラリの仕事の書き方

Javaの経験は年数を分けて書く

Javaで書かれたアプリの保守も、まだ案件として残っています。Javaの期間は、Kotlinの年数と合算せずに分けて書きましょう。Androidではない業務システムでのJavaの経験も、同じ「Java」の行にまとめず、用途を分けて書くと誤解を防げます。Javaを主に使う案件も検討している方は、Javaのスキルシートの書き方も参考になります。

アプリではなくSDKを作った場合

ほかのアプリに組み込まれるSDKやライブラリを担当した場合は、「誰が、どう組み込むものか」を書きます。公開するAPIの設計、組み込む側への説明資料、版の管理と互換性の配慮などは、アプリの開発とは違う強みとして伝えられます。

よくある質問

移行が途中のまま離任しました。どう書けばよいですか？

途中までの状態をそのまま書けば問題ありません。「新しい画面からComposeで作成。既存の画面は一部を移行」のように、離任した時点の状態と、自分が担った範囲を書きます。移行を段階的に進める現場は多く、途中の状態を正しく説明できることも経験として伝わります。

業務用端末のアプリしか経験がありません。何を書けばよいですか？

端末の種類、配布の方法、バーコードの読み取りや周辺機器との連携など、業務用ならではの機能を書きましょう。一般向けのアプリの案件に応募する場合は、Kotlinでの開発や設計の経験を要約の上に置くと、読み手が共通点を見つけやすくなります。

使ったライブラリはどこまで書けばよいですか？

設計に関わるもの（依存関係の注入、データベース、通信、画面の遷移など）を中心に書き、細かいライブラリは省いてかまいません。ライブラリを選んだり置き換えたりする判断に関わった場合は、担当内容に1行添えておくと、設計の経験として伝わります。