iOSエンジニアの参画初月にやること｜現場で信頼される進め方

iOSエンジニアの参画初月は、手元でビルドと配布ができる状態を整え、既存コードの作りとリリースの手順をつかみ、小さな変更を一つ審査まで通して、月末に「気づいた危うさと改善の見立て」を出すところまでを目標にします。最初の1か月で求められるのは、大きな機能を作ることより、このエンジニアに任せて大丈夫だと現場が判断できる材料を示すことです。

この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、避けたい動き、月末の振り返りを整理します。参画前の準備の全般は参画前の準備の記事、参画初期の一般的な心構えは参画初期の記事で扱っているので、ここではiOSならではの点に絞ります。

初月のゴールを3つに分ける

初月のゴールは、次の3つに分けて考えると、何から手を付けるかを決めやすくなります。

3つ目は案件によって、審査への提出を別の人が担う場合もあります。その場合は、自分の変更が入った版が公開されるまでを見届け、手順を把握することを目標にします。

1週目：環境を整え、コードとアプリを触る

環境の準備を最優先にする

iOSの開発は、Macと検証端末、発注側の開発者アカウントへの招待がそろわないと始まりません。初日から2〜3日のうちに、次の点を確かめます。

• 貸与のMacか持ち込みか。持ち込みなら、業務のコードを置く条件
• Xcodeの版と、チームで決めている版のそろえ方
• App Store ConnectとTestFlightで自分に与えられる権限
• 証明書やプロビジョニングの管理を誰が担っているか
• 検証端末の種類と、古いOSの端末の有無

Appleの提出要件は毎年変わります。2026年10月時点のApple Developerの案内では、2026年4月28日以降、App Store Connectにアップロードするアプリは、Xcode 26以降とiOS 26などのSDKでビルドすることが求められています。チームが使っているXcodeの版と、次の更新の予定も、このときに聞いておくと後の判断に役立ちます。

利用者としてアプリを触る

コードを読む前に、公開中のアプリを利用者として一通り触ります。主要な画面の流れ、設定、通知、オフラインのときの動きを確かめておくと、コードを読んだときに「どの画面のどの処理か」を結び付けやすくなります。

コードの地図をつくる

最初に読むのは、画面の一覧と、画面からデータの層までのつながりです。UIKitとSwiftUIのどちらで書かれた画面が多いか、非同期処理はasync/awaitかCombineか、Objective-Cが残っているかを、自分用のメモにまとめます。古い作りと新しい作りの境目は、後の修正で影響を読み違えやすい場所です。

2週目：小さな変更でチームの流れに乗る

最初の変更は小さく選ぶ

窓口やテックリードに相談し、影響の小さい不具合の修正や文言の変更などから取りかかります。目的は、ブランチの切り方、プルリクエストの書き方、レビューの基準、テストの範囲といった、チームの流れを一通り経験することです。

レビューで現場の決まりを学ぶ

最初のレビューで受けた指摘は、現場の決まりそのものです。命名、ファイルの分け方、SwiftUIとUIKitの使い分けなど、指摘された点をメモに残し、次の変更から合わせます。指摘を受けたら、理由が分からない点だけを短く尋ねるにとどめ、議論を広げすぎないようにします。

TestFlightで配布を確かめる

自分の変更が入ったビルドを、TestFlightで配布し、実機で確かめるところまでを経験します。AppleのTestFlightの案内にあるとおり、ベータ版のビルドを社内外のテスターに配って確かめる仕組みです。リモートの案件では、配布と不具合の報告の流れがチームの要になるため、早めに慣れておきます。進め方はiOSエンジニアのリモート案件の記事をご覧ください。

3〜4週目：リリースの流れを見届け、見立てを出す

審査への提出とリリースの手順を追う

自分の変更が入った版が、審査に提出され、公開されるまでの流れを見届けます。提出を自分が担う案件では、手順書を見ながら実際に行い、手順書に足りない点があれば書き足します。段階的な公開をしているか、不具合が出たときに公開を止める判断を誰がするかも確かめます。

気づいた危うさを一覧にする

1か月コードとアプリに触れると、気づくことが出てきます。たとえば、次のような点です。

• 非推奨のAPIや、更新の止まった外部ライブラリが残っている
• テストが少なく、手で確かめている範囲が広い
• リリースの手順が特定の人に依存している
• 古いOSの対応のために、残している分岐が多い

この段階では直すことより、事実と影響を一覧にし、優先度の見立てを添えて出すことを目標にします。

次の1〜2か月の動きを相談する

一覧をもとに、窓口やテックリードと、次の1〜2か月に自分が担う範囲を相談します。気づいた点のうち、契約の範囲の外にあるものは、引き受けるかどうかを窓口と決めてから進めます。扱いは業務範囲が変わったときの記事をご覧ください。

案件の型によって初月の重心は変わる

iOSの案件の型ごとの中身はiOSエンジニアの仕事内容で整理しています。初月に力を入れる場所は、型によって次のように変わります。

運用中アプリの機能追加

既存の書き方に合わせることと、リリースの流れを早く覚えることが重心です。2週目までに一つ変更を通し、3週目からは機能の追加に入れる状態を目指します。

新規アプリの立ち上げ

まだコードが少ないため、設計の方針や、画面とデータの層の分け方を決める議論に早くから加わることになります。初月は、決めた方針を文書に残し、最初の画面を方針どおりに作って見本にすることが重心です。

書き換え・移行の案件

Objective-CからSwift、UIKitからSwiftUIへの移行では、古いコードの読み込みに時間をかけます。どの画面から移すか、移している間の新旧の共存をどう保つかの見立てを、月末に出せると信頼につながります。

共通基盤・SDKの案件

他のチームが使う部品を扱うため、公開しているAPIの使われ方と、版の管理の決まりをつかむことが重心です。変更が利用側に与える影響を、初月のうちに説明できるようにしておきます。

初月に避けたい動き

• 設計や書き方を早く変えすぎる：前の現場の型や好みのライブラリを、参画してすぐに持ち込む
• 環境が整わないまま黙って待つ：権限がないことを伝えず、数日をビルドできないまま過ごす
• 問題を抱え込む：ビルドが通らない、実機で動かない、といった問題を一人で調べ続け、報告が遅れる
• シミュレーターだけで確かめる：実機での確認を後回しにし、通知やカメラなどの不具合を見落とす
• 範囲の外の依頼をその場で引き受ける：Androidやサーバーの対応を、扱いを決めないまま始める

つまずきやすい場面と対策はiOSエンジニアのつまずきやすい点の記事で詳しく整理しています。

1か月の終わりに振り返ること

月末には、次の点を自分で振り返り、窓口やテックリードと短く共有します。

1. 環境：ビルド、配布、提出に必要な権限と機材はそろっているか
2. 理解：画面の作り方、データの層、リリースの流れを、人に説明できるか
3. 成果：どの変更を、どこまで届けたか
4. 見立て：気づいた危うさと、優先度の考え
5. 次の範囲：次の1〜2か月で自分が担うことと、担わないこと

引き継ぎを受けた案件では、前任者の資料に足りなかった点を書き足しておくと、自分の後の人にも役立ちます。考え方は引き継ぎの記事をご覧ください。

よくある質問

参画初日にMacや権限が届いていません。何をすればよいですか？

窓口に、いつ届くかと、届くまでに読める資料やリポジトリがあるかを確かめます。設計資料やアプリの画面の流れ、過去のリリースの記録などを読む時間にあてると、環境が整ってから早く動けます。待っている状態は、その日のうちに伝えておくことをおすすめします。

初月から大きな機能の開発を任されたら、どうすればよいですか？

引き受ける場合も、最初の1〜2週は既存の書き方とリリースの流れをつかむ時間として見込み、その旨を窓口と共有します。機能を小さく区切り、早い段階で一部を見せながら進めると、方向の食い違いを防げます。

1か月たってもコードの全体像がつかめません。どうすればよいですか？

全体を一度に理解しようとせず、自分が担当する画面の周りから地図を広げます。分からない部分は一覧にし、テックリードや前任者に短く尋ねる時間をもらうと、つかむ速さが上がります。求められる技術の幅はiOSの案件で求められるスキルをご覧ください。