MVPリアーキテクチャを通して成長したWEAR iOSエンジニアアルバイト奮闘記

WEAR iOS Swift 開発者インターン

MVPリアーキテクチャを通して成長したWEAR iOSエンジニアアルバイト奮闘記

はじめに

こんにちは。2025年4月に新卒で株式会社ZOZO（以下、ZOZO）に入社予定の清板海斗（せいたかいと）です。2024年8月から入社までの約半年間、「WEAR by ZOZO」（以下、WEAR）のiOSチームで内定者アルバイトに参加しました。この記事では、内定者アルバイトの目的やチームでの取り組み、全体の振り返りについてご紹介します。

目次

内定者アルバイトの概要

ZOZOの内定者アルバイトについて

内定者アルバイトとは、内定承諾から入社までの期間にアルバイトとして就業できるものです。また、選考時に志望していた職種以外の求人に応募できます。職種以外にもサービスごとで募集もしているので入社後に希望している配属先のサービス以外の選択肢もあり、様々なサービスの雰囲気を知ることができる良い機会になると思います。

内定者アルバイトでの働き方

私は2024年2月に内定をいただき、同年の8月から翌年の3月の大学卒業までの8か月間、WEARのiOSアプリを開発するチームで内定者アルバイトとして働きました。

WEARとは

ZOZOはWEARという日本最大級のファッションコーディネートサイトを運営しています。2024年の5月に「WEAR by ZOZO」として「似合う」が探せるアプリを目指してリニューアルしました。

WEAR iOSチームについて

WEAR iOSチームは10名程度で構成されており、チームのコミュニケーションはSlack、Google Meet、Discord等で行われています。案件ごとでチームがさらに細分化されており、改善に向けた取り組みはその中で行われることが多いです。

iOSチーム全体では次のような活動をしています。

  • 朝会
    • 連絡事項の共有
    • 雑談（ご飯、スニーカー、格闘技などの話題が多く、個性的な雰囲気）
  • チーム定例
    • 技術的な知見、調査内容の報告など
    • 登壇の発表練習
    • Findyの数値を見ながら開発パフォーマンスの確認
    • Warning数など技術負債のモニタリング
    • タスク、PRの細分化に関する相談、共有
  • 1on1
    • 配属時にチームメンバー全員と1on1
      • お互いを知るための雑談

年齢層が高めのチームで、相談には若い頃のお話も交えて親身に乗っていただけますし、ミスがあっても優しく指摘していただけます。とにかくアットホームなチームです。

主な取り組み

最初は、UIやバグの修正などの簡単なタスクから始め、徐々にテストの実装やリアーキテクチャといった難しいタスクに取り組みました。

  • デザイン修正
    • ボタンの位置の修正などの対応
  • バグ修正
    • 年月日表記の修正対応
  • warning解消
    • Swift 6対応に伴うXcodeのwarning解消
  • リプレイス
    • 独自実装をUICollectionViewCellのautomaticallyUpdatesContentConfigurationを使用するようにリプレイス
    • 独自実装をUICollectionViewCellの標準APIを使用するようにリプレイス
  • リアーキテクチャ
    • Presenter移行

その中でも特に印象的だったタスクについてご紹介します。

MVPへのリアーキテクチャ

タスク概要

「ノウハウ動画投稿の着用コーディネートアイテム画面」にMVPアーキテクチャを適用しました。この画面は、ホームや探すタブからアクセスできる「ノウハウ動画」コンテンツの中心的な機能の1つです。

WEARのiOSアプリでは、MVPアーキテクチャを採用していますが、今回の対象のように適用されていない画面もあります。中心的な機能であるため、今後も改修の影響が考えられることもあり、今回のタイミングでリアーキテクチャに取り組みました。

画面スクショ

Presenter移行の背景

アーキテクチャが適用されていない従来の画面では、責務の分離ができていないという課題がありました。これにより、以下の問題が発生していました。

  • 画面のコードが肥大化し、可読性が低下
  • テストがしづらく、品質を担保しにくい
  • 修正時に影響範囲が広がりやすい

MVPアーキテクチャが導入されていないため、ViewControllerに全ての処理を実装することで、様々な処理を同時に複数抱えた、いわゆる「FatViewController」になっていました。

そこで、MVPアーキテクチャを導入し、責務を明確に分離することで、これらの課題を解決することを目指しました。

WEAR iOSにおけるPresenter

Presenterは、Viewの状態管理とアクション処理を行う責務を持つコンポーネントとして定義しています。各画面の一貫性を保つため、Presenterプロトコルに準拠しています。

Presenterの構成は次の通りです。

  • ViewState
    • UIを構築するための状態（値のみを持ち、副作用を排除）
  • InputAction
    • Viewからのアクション（ユーザー操作やライフサイクルイベント）
  • OutputAction
    • Viewへの命令（画面更新や遷移指示）
  • Presenter
    • InputActionやOutputActionに対応した処理
    • ViewStateを変更

実際のコードは次の通りです。

protocol Presenter<ViewState, InputAction, OutputAction>: Sendable {
    associatedtype ViewState
    associatedtype InputAction
    associatedtype OutputAction

    var state: ViewState { get }
    var output: ((OutputAction) -> Void)? { get }

    func apply(outputAction output: @escaping ((OutputAction) -> Void))
    func send(_ action: InputAction) async
}

ViewStateを追加して状態管理を分離することで、Presenter本体にはInputActionおよびOutputActionに対応した処理だけを実装でき、役割がさらに明確になります。

実施したこと

Presenter移行方針と単一責任の原則に基づき、以下の対応をしました。

  • Presenterの追加（ロジックをViewから分離）
  • ViewState、InputAction、OutputActionの追加（責務の明確化）
  • テストの追加（動作保証とリファクタリングのしやすさ向上）
  • ログ送信をPresenter側に移行

結果

Presenterの導入前後でどのようにコンポーネントが変わったのかを以下に示します。

まず、わかりやすくするためにコンポーネントをUI、仲介役、データ処理の3つの役割に分けます。Stateは状態を保持する補助的なものとします。

役割の関係図

次に、実際のコンポーネントをそれぞれの役割で分類し、Presenter導入前後の関係図を示します。

【Before】

MVCの関係図

データ処理の部分にあるFetcherなどは実際に使用している処理を担当するクラス名です。示したもの以外にも存在し、責務が最小化された複数のクラスに分割しています。

小さい規模のプロジェクトであればこのような構成でも問題ないですが、Viewのイベントの数が多いほどViewControllerの仕事が増えてしまい、「Fat」になってしまいがちです。

【After】

MVPの関係図

ViewControllerを仲介役から切り離し、Presenterにデータの加工、ログの送信などを任せることで一気に見通しが良くなりました。

学び

内定者アルバイトを通して学んだことは、大きく3点あります。

1. コミュニケーションと言語化の重要性

タスクに慣れていないうちは、問題点や解決方針を明確に言語化できず、メンターやレビュー担当者に負担をかけてしまっていました。

タスクに取り組むスピードも大切ですが、それ以上にチームの一員として、普段から言語化を意識し、相手の負荷を減らす習慣をつけることが重要だと学びました。

2. UIKitの理解

自分は学生時代の多くの時間をSwiftUIに費やしていたのでUIKitに慣れていませんでした（同じような学生の方はこれから増えていくのではないでしょうか？）。以下のような実装に触れましたが、UIKitをほとんど一から触ることとなり、手探り状態でとても苦労しました。

  • UICompositionalLayout
  • UICollectionView
  • UIContentConfiguration

宣言型のSwiftUIしか触れていないと手続き型の実装方法はとても複雑に感じ、理解にも時間がかかります。そのため何度も社員の方々にペアプログラミング、コードレビューをお願いしてしまいましたが、本当に親切に対応してくださる方ばかりで手探り状態の自分でもなんとか乗り越えることができ、本当に感謝しています。ZOZOの人々の良さを改めて実感しました。

3. 実務レベルで求められる視点

仕事としてのプログラミングでは、以下の点が特に重要だと感じました。

  • チームの生産性を意識した開発
  • 大規模サービスならではのアーキテクチャ設計
  • 責務の最小化と適切な分離

コードを書くことだけでなく、長期的なメンテナンスやチーム開発を意識した設計が求められることを実感しました。

最後に

長期インターンを継続している方や内定者期間に他社でエンジニアのアルバイトをしている方もいますが、自分はそうでなく、技術的なことや仕事としての立ち回りなどの不安がありました。そんな中でこのような就業機会をいただけたことで、不安も払拭され、入社後のイメージもはっきりして実現したいことがいっぱいです。もし内定をもらって自分のような境遇の方がいましたらぜひ内定者アルバイトに挑戦してほしいです！

ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。

hrmos.co

corp.zozo.com

カテゴリー