Androidエンジニアのフリーランス面談でよく聞かれる質問と答え方

Androidエンジニアのフリーランス面談でよく聞かれるのは、どんなアプリをどの役割で担ったか、古い書き方から新しい書き方へどう移したか、Google Playの要件に合わせた更新をどう進めたか、端末の差や不具合にどう向き合ったかの4つです。面談官は知識の量より、「この人に自分たちのアプリを触らせたら、何をどの順番で進めるか」を確かめています。

準備では、模範回答を覚えるより、自分の経験から判断した場面を3〜4つ選び、どの質問にもそこから答えられるようにしておくのが近道です。面談全般の答え方は業務委託の面談でよく聞かれる質問と答え方で扱っているので、この記事ではAndroidの面談に固有の質問に絞ります。

Androidの面談で面談官が見ていること

Androidの面談に出てくるのは、発注元のテックリードやAndroidチームのリーダー、受託側の開発責任者であることが多く、本人もAndroidのコードを書いてきた人です。そのため、使った技術の名前を並べるより、なぜその書き方を選んだか、どこで困ってどう抜けたかを聞いています。

面談官が知りたいのは、おおむね次の3点です。

1. すぐに手を動かせるか：今のコードの書き方（Kotlin、コルーチン、Compose、推奨アーキテクチャなど）に、立ち上がりの時間をかけずに入れるか
2. 古いものとの付き合い方：Javaのコード、XMLのView、古いライブラリが残るアプリを、壊さずに直していけるか
3. チームの進め方に合うか：レビュー、リリースの周期、iOS担当やサーバー側との連絡の取り方が、自社のやり方に合うか

以下の質問は、この3点のどれかを確かめるためのものです。質問の意図が分かれば、答えの中心に何を置くかも決まります。

よく聞かれる質問と答え方の考え方

ここで示す答えの例は、組み立て方を伝えるための架空の例です。ご自身の経験に置き換えて準備してください。

1. 「直近で担当したアプリと、あなたの役割を教えてください」

確かめたいのは、経験の重さと範囲です。一般向けか業務用か、利用者の規模感（言える範囲で）、チームの人数、Androidの担当者の人数、自分が担った範囲（画面だけか、設計からか、リリースまでか）を短く伝えます。

架空の例：「一般向けの会員アプリで、Android担当3名のうちの1名でした。主に決済まわりの画面と処理を担当し、後半は設計のレビューも任されていました。リリースの作業はリーダーが担っていました」

肩書きより実際に担った範囲を正確に話すと、後の質問との食い違いが起きません。

2. 「JavaからKotlin、ViewからComposeへの移行はどう進めましたか」

運用中のアプリを持つ発注元が、最もよく聞く質問の一つです。見られているのは、新しい書き方を知っているかより、リリースを止めずに少しずつ置き換える進め方を持っているかです。

• どの単位で区切ったか（画面ごと、モジュールごと、新しい画面から）
• 古い部分と新しい部分をどうつないだか
• 置き換えの途中で起きた不具合と、その防ぎ方
• 途中でやめた、見送った判断があればその理由

移行の経験がない場合は、新しく作った画面でComposeを使った経験や、個人で試した範囲を正直に分けて話します。

3. 「targetSdkの引き上げはどう対応しましたか」

Google Playでは、2026年8月31日以降、新しいアプリとアプリの更新はAndroid 16（APIレベル36）以上を対象にする必要があると案内されています（スマートフォン向けの場合。2026年10月時点のAndroid Developersの案内）。この種の対応は毎年のように発生するため、経験の有無をよく聞かれます。

答えるときは、「上げました」で終わらせず、影響をどう調べ、何を直し、どう確かめたかを順に話します。権限、通知、バックグラウンドの処理、画面の表示など、どこに影響が出たかを具体的に挙げられると、実際に担ったことが伝わります。組み込んでいたSDKやライブラリの対応を待った、といった調整の話も評価の材料になります。

4. 「機種やOSの版による不具合にどう対応しましたか」

Androidならではの質問です。確かめたいのは、端末の差を前提にした確認の範囲の決め方と、再現できない不具合の詰め方です。

• 確認する機種とOSの版を、誰がどう決めていたか
• 特定のメーカーの端末だけで起きた不具合を、どう見つけてどう直したか
• 手元にない端末の問題を、どんな情報から絞り込んだか

5. 「クラッシュや性能の問題を、どう調べて直しましたか」

運用中のアプリでは、リリース後の不具合への向き合い方が見られます。クラッシュの報告から原因を絞り込んだ手順、画面の動きの重さやメモリの問題を測った方法、直したあとに再発していないかをどう確かめたかを話します。「ツールを使いました」より、何を見て仮説を立て、どう確かめたかの順番が伝わる話し方がよいでしょう。

6. 「設計の方針を教えてください。なぜその構成にしましたか」

アーキテクチャの名前を答えるより、画面の状態をどこで持ち、データの取得や保存をどう分けたか、テストをどこで書いたかを話します。チームの既存の構成に合わせた経験があれば、それも評価されます。新しい構成を持ち込んだ場合は、チームにどう説明して合意したかも添えると、現場での動き方が伝わります。

7. 「iOS担当やサーバー側とは、どう連携していましたか」

アプリの開発は、iOS版やAPIの担当者と仕様をそろえる仕事でもあります。挙動の違いをどうそろえたか、APIの仕様の変更をどう受け止めたか、デザイナーとの細かなすり合わせをどう進めたかを話します。連絡の頻度や手段も、発注元が自社のやり方との相性を測る材料になります。

8. 「なぜフリーランスで、なぜこの案件に興味を持ちましたか」

長く続けてもらえるか、案件の中身を理解しているかを確かめる質問です。働き方の希望だけでなく、案件のどの部分（移行、新規開発、業務用端末など）で自分の経験が生きると考えたかを添えます。

準備は「判断の場面」と「数字」をそろえる

上の質問は数が多く見えますが、答えの材料は共通しています。準備は次の手順で進めると効率的です。

1. 場面を選ぶ：移行、要件対応、端末の差による不具合、リリース後の障害など、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状況、気づいたきっかけ、調べたこと、選んだ方法と理由、結果、次に生かしたことを書き出す
3. 規模の言い方をそろえる：チームの人数、Android担当の人数、期間、対応したOSの版の幅を、どの場面でも同じ言い方で話せるようにする
4. 2分版と5分版をつくる：最初は短く話し、掘り下げられたら詳しく話せるようにする
5. スキルシートと照らし合わせる：シートに書いたKotlinとJavaの比率、Composeの経験、targetSdkの対応の書き方と話がずれていないかを確かめる

スキルシートの書き方はAndroidのスキルシートの記事、冒頭の自己紹介の組み立ては面談の自己紹介の記事で解説しています。コードを書く課題や技術的な質問が中心の面談への備えは技術面談・コーディングテストへの備え方をご覧ください。

案件の種類によって聞かれる重心が変わる

Androidの面談は、案件の種類によって聞かれる内容の重心が変わります。案件の種類ごとの働き方はAndroidの仕事内容の記事で整理しています。

同じ質問でも、案件の種類に合わせて選ぶ場面を変えると、限られた時間で伝わりやすくなります。

Androidならではの逆質問

面談の終わりの逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。Androidの案件では、次の点を聞いておくと判断がしやすくなります。

• 今のコードの状態（Kotlinの比率、Composeの導入の度合い、主なアーキテクチャ）
• 次のtargetSdkの対応の予定と、その担当の見込み
• 検証端末の用意の仕方と、確認する機種の決め方
• リリースの周期と、ストアへの提出を誰が担うか
• iOS版の有無と、担当者との連絡の取り方

一般的な逆質問の考え方は業務委託の面談で聞いておくべき逆質問にまとめています。逆質問で聞いた内容は、契約前の確認にもそのまま使えます。案件を選ぶときの確認点はAndroid案件の選び方で整理しています。

よくある質問

Composeの実務経験がないと、面談で不利になりますか？

Composeを使っている現場では、経験があるほうが立ち上がりは早いと見られます。ただ、運用中のアプリにはViewのコードも多く残っているため、Viewでの経験が評価される案件もあります。実務で使った範囲と、個人で試した範囲を分けて正直に話すことが大切です。

面談でコードを書く課題が出ることはありますか？

案件によってあります。その場で簡単な処理を書く形や、過去に書いたコードについて説明を求められる形などがあります。事前に課題の提出を求められた場合の考え方は面談で課題の提出を求められたときで解説しています。

個人で公開したアプリの話をしてもよいですか？

話して問題ありません。業務の経験が少ない分野を補う材料になります。その場合も、何を作ったかより、どんな判断をして、公開後にどんな問題をどう直したかを話すと伝わりやすくなります。業務の経験と混ぜずに、個人の取り組みとして分けて話しましょう。