キャリアプロダクト開発部の森 ＠jiskanulo です。 私ごとですが今年で45歳、WEBサービスの開発歴は20年以上になります。世間的にはベテランエンジニアとかシニアエンジニアとかと称される類だと自認しています。 そんな私ですが2026年1月に基本情報技術者試験を受験して合格しました。 この記事は、ベテランエンジニアが基本情報技術者試験をスキル棚卸しツールとして活用した体験と、受験しなくても使えるセルフチェックの方法を紹介します。 www.ipa.go.jp 受験の動機 結果 得意と苦手が可視化された 得意だった領域 苦手だった領域 得意と苦手のコントラストが意味するもの 試験範囲でスキルを棚卸しする方法 受験のTips CBT受験の雰囲気 集中力の維持に課題 まとめ 受験の動機 受験したきっかけは昨今のAIエージェントを前提とした開発手法の変化です。 ファインディではAIエージェントの導入・検証を積極的に行っています。 私もDevin, GitHub Copilot Chat, Cline, Claude Codeなどさまざまなツールやサービスを日々の開発業務に導入すべく検証していました。 2025年6月頃からClaude Codeを本格的に使用しはじめ、2026年3月現在では私自身が手でコードを書くことは全くなくなりました。 昨今のAIエージェントが主となり開発を進める体制では、AIエージェントへ適切な指示を出す力、AIエージェントからの提案を判断し承認・修正するための力が求められます。 この力をつけるための基礎知識として、基本情報技術者試験の内容はちょうどよいと感じています。 また、2025年末に開発部で「基本情報技術者試験の合格を目指しましょう」という方針も出たこともあり、社内のメンバーが続々と受験・合格している流れに乗りました。 受験理由をもう一つ挙げると、実は基本情報技術者試験を20年ほど前に受験して不合格になっており再挑戦をしないままでした。 さらに後年に応用情報技術者試験を受験し合格しているのですが、応用情報は持っているのに基本情報は持っていないというチグハグ感を解消したかったのです。 近いうちにデータベーススペシャリスト試験を受けようと考えていたところ、2026年度からCBT（コンピュータベースの試験）方式に移行するという情報があり、CBTの雰囲気を先に体験しておきたいという思いもありました。 ただデータベーススペシャリスト試験の実施そのものが2026年中は不明瞭な状況です。動向を注視しつつ、申し込みが再開されたらすぐエントリーしたいですね。 www.ipa.go.jp 結果 科目Aは705点、科目Bは680点となんとか合格できました。もう少し余裕を持って合格したかったのですが、そこは今後の伸びしろとします。 得意と苦手が可視化された 受験して最も収穫だったのは、自分のスキルの輪郭がはっきり見えたことです。 得意だった領域 計算問題やコードリーディング、データベース正規化や稼働率計算などの問題はスムーズに解けました。 日常業務でコードを書き、レビューし、設計・運用を考えることを毎日やっているので、実務経験がそのまま得点に結びつきました。 過去問の模擬試験でもこれらの分野は正答率が高く、特別な対策をしなくても安定して解ける状態でした。 苦手だった領域 一方、会計管理や財務指標に関する問題には苦戦しました。損益分岐点、ROI、減価償却といったテーマは過去問を解いていても正答率が目に見えて低い分野でした。 振り返ってみると、日々の開発業務で財務指標を意識する場面はほとんどありませんでした。 業務で触れない領域は経験年数に関係なく穴のまま残っている。この気づきが、受験して得た最大の収穫でした。 得意と苦手のコントラストが意味するもの この経験から見えたことは、エンジニアのスキルは実務でカバーしている範囲には自然と強くなれるが、逆に触れていない範囲は何年経っても盲点のままだということです。 基本情報技術者試験の出題範囲はITエンジニアの基礎知識を広くカバーしています。 だからこそ、受験すると自分のスキルマップの中で「どこが埋まっていて、どこが空白か」が浮き彫りになります。 試験のための勉強がすぐにサービス開発に活かせるかというとそうでもないのですが、自分の基礎知識の全体像を把握するにはちょうどいい粒度だと感じました。 試験範囲でスキルを棚卸しする方法 受験するにあたり、基本情報技術者試験ドットコムに大変お世話になりました。 www.fe-siken.com 私の場合は1日30分、20日間ほどで合計600問を回答しました。無料サービスの範囲でも十分に過去問を試すことができますし、有料のメンバー登録をすると学習の記録管理がしやすくなります。 スキル棚卸しをするために、まず科目Aの過去問を解いてみてください。 分野ごとの正答率が記録されるので、自分がどの分野に強く、どの分野に穴があるかが数値で可視化されます。 参考として、基本情報技術者試験の科目A出題範囲をもとにしたセルフチェック表を載せておきます。自分が「得意」「苦手」「触れたことがない」のどれに当たるか振り返ってみてください。 分野 自己評価（筆者の例） 基礎理論（離散数学、情報理論等） 得意 アルゴリズムとプログラミング 得意 コンピュータ構成要素 得意 システム構成要素 得意 ソフトウェア 得意 ハードウェア 苦手 データベース 得意 ネットワーク 苦手 セキュリティ 得意 マネジメント（プロジェクト・サービス） 苦手 ストラテジ（経営戦略・法務） 苦手 表のとおり、実務で日常的に使う分野は得意、そうでない分野は苦手という傾向がはっきり出ました。 正答率が安定して高い分野は実務でカバーできている基礎知識。低い分野やまったく分からない分野は、業務で触れていない盲点です。「知っているつもりだったが正確には理解できていなかった」という曖昧な領域も見つかるかもしれません。 受験のTips CBT受験の雰囲気 当日午後に受験会場に着くと、試験開始時刻前でも受験を始めてよいと案内されました。 パソコンに向かう前に持ち物検査を終えて着席。 キーボードはログイン時にしか使わず、試験中はマウス操作のみ。紙とペンは貸してもらい、筆算やコードのトレースをしながら回答しました。 回答完了ボタンを押すとすぐに得点が表示され、合否をその場で確認できました。結果待ちのモヤモヤがなかったのは嬉しいポイントでした。 集中力の維持に課題 科目Bの時点で集中力が切れてしまったのが今回の反省点です。 20年前は午前問題のあとに2時間ほどの昼休みがあり、リフレッシュしてから午後問題に臨めました。現在の形式では科目Aのあと10分の休憩で科目Bが始まるため、体力的にも精神的にも消耗した状態で後半戦に入ることになります。 受験する前には十分に体調を整えて臨むことをおすすめします。 まとめ 基本情報技術者試験は、資格取得という目的だけでなく、自分のスキルの得意と苦手を可視化するツールとして活用できました。 スキルを可視化できたこともあり、今年中にデータベーススペシャリスト試験の合格を目指して準備を進めていこうと思います。 みなさんも試験を受けてみてください。受験しなくても、過去問を試すだけでスキルの棚卸しになりますよ。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに 皆さんこんにちは！九州大学修士1年の羽田野武蔵です！ 2025年12月に、マッチングアプリ ...

はじめに こんにちは、2025年にiOSエンジニアとして新卒入社したZOZOTOWN開発1部iOSブロックの だーはま です。普段はZOZOTOWNのiOSアプリを開発しています。本記事では、新卒1年目の私がZOZOTOWNの画面へMVVM+UseCaseアーキテクチャを導入した過程と、工夫を紹介していきます。 目次 はじめに 目次 背景と目的 チーム配属から1か月でMVVM+UseCaseアーキテクチャ導入を担当した経緯 デバッグ画面について 課題 コードやドメインに対する知識不足 700行以上に及ぶFatViewController 課題を解決するための取り組み Claude CodeのSubagentsを使いキャッチアップを高速化 MVVM+UseCaseアーキテクチャ導入 結果 デバッグ画面のテストカバレッジ0→93.5％ UI実装をStoryboardからSwiftUIへ完全移行 開発工数40％減少 MVVM+UseCaseアーキテクチャ導入を振り返って 最後に 背景と目的 チーム配属から1か月でMVVM+UseCaseアーキテクチャ導入を担当した経緯 ZOZOTOWN iOSでは、MVVMとUseCaseで構成されるチーム標準のアーキテクチャがあります（以後アーキテクチャという表記はチーム標準のアーキテクチャを指します）。現在、アプリ全体の保守性と開発効率を向上させるため、 チーム全体でこのアーキテクチャへの統一を進めるプロジェクトが進行しています 。 私自身、学生時代から設計への関心は高く、個人開発で同様の構成を取り入れた経験はありました。しかし、ZOZOTOWNのような歴史ある大規模なアプリの画面で、UIからビジネスロジックまでを含めて構成を見直した経験はありません。また、当時は入社して間もなく、経験したことのあるタスクはUIの修正やログ送信といった特定箇所の改修のみで、 ZOZOTOWNの大規模なコードの全体像も把握できていない状態 でした。 このような状況ではありましたが、iOSチームには以下のように アーキテクチャ導入を支える手厚いフォロー体制 1 が整っていました。 アーキテクチャの指針書が整備されている 各レイヤーの責務が言語化されている レイヤーごとにコードを使った実装例がまとめられている 設計段階でのレビューが義務化されており、実装後の手戻りを抑えられる これらの環境に背中を押され、アーキテクチャ導入がチームへの貢献と自己成長へ繋がると考えました。そのため、チームへ配属されて1か月目というタイミングではありましたが、 自ら手を挙げタスクオーナーとしてアーキテクチャ導入を進める ことになりました。 取り組む目的は以下の通りです。 技術的負債を抱えた画面のメンテナンスコストを下げること 疎結合でテスタブルなコードにする ZOZOTOWN iOSが採用しているアーキテクチャに慣れること ZOZOTOWNのiOSチームが採用しているアーキテクチャへの理解を深め、他画面のコードリーディングを高速化する テストコードの実装にも慣れるため、可能な限りテストを実装する 大規模なコードを高速にキャッチアップするための練習をする AIと協働して大規模なコードを高速にキャッチアップする方法を模索する 上記の目的を満たす画面をチーム内で議論し、社内向けでありユーザー影響のないデバッグ画面を選びました。 デバッグ画面について デバッグ画面は、ZOZOTOWNのデバッグ用にデータを編集する画面です。開発している案件に応じてサーバーの向き先を切り替えるなど、開発する上で便利な機能が複数用意されています。デバッグ画面を使うことでQAや案件ごとに実施される動作確認をスムーズに行えます。このデバッグ画面はiOSエンジニアだけでなく、QAチームやバックエンドを始めとした社内の様々なチームおよびメンバーが触れるため、 開発する上でとても重要な画面 です。 しかし、新規案件の実装を優先しておこなっていく中で、社内向けでありプロダクトコードではないことから保守に手をつけることができずにいました。その結果、UIからビジネスロジックまでの実装が1つのViewControllerに記述され、機能を追加するたびにメンテナンスコストが増大していました。 課題 アーキテクチャ導入にあたり解決すべき課題は以下の2つです。 コードやドメインに対する知識不足 700行以上に及ぶFatViewController コードやドメインに対する知識不足 先述したようにデバッグ画面は依存関係が複雑です。 また、導入にあたり以下のような課題がありました。どの課題にも共通して「キャッチアップするべき項目が多く、十分にできていなかった（本人は十分にできているつもりだった）」ということが挙げられます。 触れたことのないアーキテクチャの理解 学生時代に個人開発で触れていたアーキテクチャ（MVVM,TCAなど）とは思想やルール、実装する上での責任が異なるため、チームが採用しているアーキテクチャを理解して慣れるまで時間がかかる 既存実装の仕様を確認する難しさ プロパティの初期値やデータソースへのアクセス、データを読み書きするタイミングなど、既存実装には多くの仕様が存在しており、それらすべてを確認して実装を進めるのが困難 テストコード実装時に発覚した「隠れた密結合」 設計のレビューを通過し各レイヤーの責務を定義したはずが、いざ実装を進めるとデータソースの抽象化ができておらずユニットテストを書けない状態で手戻りが発生する 700行以上に及ぶFatViewController 既存の実装では1つのViewController内に画面の状態からデータソースへのアクセスまで全てのコードが記述されていました。責務分離がなされていないためクラスをDIできず、ユニットテストの記述が困難な状況です。また、StoryboardでUIを開発していたためメンテナンスコストが高くなっていました。実際にメンバーからは「デバッグ用のフラグを1つ追加したいだけなのに、Storyboardの修正や依存関係のあるコードの把握に時間がかかってしまう」という声が上がっていました。本来は開発を効率化するためのツールであるはずのデバッグ画面が、機能追加のたびに負債が溜まっていく画面になっていたのです。 課題を解決するための取り組み 前述した課題を解消するため2点取り組みました。 Claude CodeのSubagentsを使いキャッチアップを高速化 MVVM+UseCaseアーキテクチャ導入 Claude CodeのSubagentsを使いキャッチアップを高速化 1つ目の課題で挙げたコードやドメインに対する知識不足を解決するため、コードの分析からプランニングまでをサポートするClaude CodeのSubagentsを3つ作成しました。Subagentsで分析することで、自力で読み解くよりも高速なドメイン知識の獲得が可能です。また、分析結果をもとにドキュメントを作成してもらうことで、レビューの説明文にも活かせます。 作成したSubagentsと役割は以下の通りです。 spec-refactorer 既存コードを解析し、現状のロジックや仕様を整理 ios-architecture-engineer アーキテクチャ導入に向けた技術的な調査と、依存関係の整理 refact-planner 調査結果を元に、実装の優先順位や具体的な手順のプランニングを提案 3つのプロンプトを載せることは記事の都合上できないため、 spec-refactorer のみを紹介します。 spec-refactorer のプロンプトは以下の通りです。 ## 出力フォーマット に記載されているような画面の構成やデータフローなどをまとめます。 // 重要な部分のみ抜粋 ## 目的 * 画面を開いてからの **データフロー**（依存解決→API→変換→State更新→描画）と、ユーザー操作（例: **Aというコンポーネントをタップ**）時の **処理・I/O・状態/遷移** を一目で把握できるようにする。 ## 出力フォーマット 1. TL;DR（初回ロードと主要アクションのI/Oを箇条書き） 2. 画面の構成（UI/State/Lifecycleの表） 3. データフロー（画面表示→初回ロードのシーケンス図） 4. UIコンポーネント×アクション×副作用の対応表（Cell/ボタン/トグル/Pull-to-Refresh/ページネーション/セル内ボタン含む） 5. 主アクション毎のシーケンス図（最低A=主ボタン, Refresh, セル選択） 6. ネットワークI/O一覧（Method/Path/Auth/キャッシュ/失敗時/呼出根拠） 7. 状態管理（公開State, アクション（必ず網羅すること。アクションを過不足なく網羅できるかがUXに直結する）, 非同期/キャンセル） 8. DI（依存解決の流れ）／ナビゲーション 9. エラー/ローディング/空状態 10. イベントログ送信箇所（ない場合は無しと記載） 11. 分析イベント/フラグ 12. リスク・改善 13. Reference ## 探索範囲 * **関連するファイルは可能な限り探索・調査** する（ViewModel/Reducer/Repository/API/Router/DI/テスト/拡張/ユーティリティを横断参照）。 ## 網羅してほしい操作例（該当するもののみ） * 画面表示（初回ロード） * 主要ボタン（例: AddToCart/Favorite/Buy）タップ * セル選択（詳細遷移） * Pull-to-Refresh / ページネーション * 失敗時のエラーハンドリング ## 出力スタイル * 判断根拠となるコードは丁寧に過不足なく提示してください。 * 技術構成を図に描く場合は、左側にUI層で右に行くほどDomain,Data層になるようにしてください。 * 出力は日本語でお願いします。 以下の点が整理されるようにSubagentsを設計しました。これによってハルシネーションや考慮漏れを抑えた出力を得られるようになります。 判断根拠となるコードをドキュメントの最後に記載させる ユーザーアクションを軸にしてデータフローを整理させる 見落としがちなポイントも確認させる エラーやローディング時の挙動 ログ送信の有無 外部へ公開しているプロパティ（画面の状態）は何か MVVM+UseCaseアーキテクチャ導入 2つ目の課題で挙げられていた「Fat」な実装を解消するため、MVVM+UseCaseアーキテクチャを導入しました。MVVM+UseCaseアーキテクチャは Android Architecture Components を参考にしたアーキテクチャであり、以下のように役割を分担させます。 View / ViewController UIレイアウトや画面遷移 ViewModel イベントハンドリングやViewに最適化したデータ整形などのプレゼンテーションロジック UseCase キャッシュ管理などの特定のViewに依存しないビジネスロジックをカプセルし、原則として状態を持たない Translator DataSourceで取得したデータをUseCaseで扱える型へ変換することで、UseCaseにAPI等の知識が入り込むことを防ぐ DataSource データソース（APIやUserDefaultsなど）へアクセス ViewModel、UseCase、DataSourceはprotocolで抽象化しDIを可能にしました。これにより、UseCase、DataSourceのモックを作ることで、依存関係のあるクラスのテストを書けるようになります。 アーキテクチャ導入によりプレゼンテーションとドメインが疎結合となり、UI層のコードの変更が容易になったため、SwiftUIへの移行がスムーズに行えました。 結果 取り組みによって得られた結果は以下の通りです。 デバッグ画面のテストカバレッジ0→93.5％ UI実装をStoryboardからSwiftUIへ完全移行 開発工数40％減少 デバッグ画面のテストカバレッジ0→93.5％ 2つ目の課題で挙げたように既存実装は密結合が原因でテストを書けませんでしたが、ViewModel、UseCase、Translatorに対してユニットテストを書けるようになりました。 カバレッジを計測するとデバッグ画面に関連するテストの平均が93.5％でした。残りの6.5％はテスト不要なコードが対象となっているため、実質100％となります。 UI実装をStoryboardからSwiftUIへ完全移行 画面の実装をStoryboardからSwiftUIへ完全に移行させました。既存実装ではカスタムコンポーネントを使っていました。しかし、これらはOSのアップデートに伴うデザインシステムの変更や仕様変更の影響を受けやすく、その都度レイアウトの調整や挙動の修正が必要になるため、メンテナンスコストが増大していました。このメンテナンスコストを抑えるため、カスタムコンポーネントをSwiftUI化に合わせて廃止し、 Apple標準のコンポーネントのみ で画面を構成しました。 開発工数40％減少 既存実装に合わせたViewModelのリファクタリングや網羅的なユニットテスト実装など、Claude Codeに実装をサポートしてもらいました。 結果、Claude Code導入前に（先輩社員と相談し）見積もっていた 工数35日が、Claude Codeを使うと20日で完了 しました。約40％の工数削減となります。また、コードを書く時間が減り設計や実装方針を考える時間が増えたためClaude Codeなしに比べきれいなコードを書けました。 MVVM+UseCaseアーキテクチャ導入を振り返って 振り返ると、序盤は以下のような不安を抱えていました。 デバッグ画面のキャッチアップに時間がかかりすぎて、他画面のキャッチアップに時間を使えないのではないか 既存仕様を確認できておらずリグレッションを発生させてしまうのではないか （今後アサインされるであろう）他案件と折り合いがつかず中途半端に終わらせてしまうのではないか 冒頭でもお話ししたように、これらの不安の根本は「広い範囲のキャッチアップをうまく行えない」ことです。原因に序盤で気づき、Claude CodeのSubagentsを使ったキャッチアップ方法を模索するようになりました。初めは欲しい情報を得られずプロンプトを何度もチューニングしていましたが、今では開発に活きる情報（画面の状態やデータフローなど）が得られるようになっています。このように試行錯誤しながら作り上げたSubagentsのおかげでスピード感を持ってキャッチアップを進められました。また、Subagentsに調査結果をドキュメント化してもらうことで、ドキュメント生成のスピードも格段に上がりました。 これらの実績をまとめ、2025年10月には社内の全エンジニアを対象とした技術共有会で紹介しました。紹介をきっかけにiOSチーム以外の方にも活動を認知してもらい、「デバッグ画面を使いやすくなって作業が楽になりました！」のようなポジティブなフィードバックを多くいただきました。嬉しかったです。 アーキテクチャ導入を担当させてくれてサポートまでしてくれた上長やチームメンバーに感謝でいっぱいです。 最後に 本記事では、新卒1年目の私がAIを使ってデバッグ画面にアーキテクチャを導入した際の取り組みを紹介しました。現在は、その経験を活かして、より難易度の高い別画面への導入を進めています。試行錯誤の日々ですが、今回作成したSubagentsのおかげでコードリーディングの負担は格段に減り、開発スピードも上がったように感じています。本記事が、私と同じくキャッチアップの速度に課題を感じている方に届き、開発の生産性向上に少しでも貢献できれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com アーキテクチャの設計およびレビュー体制は「 ZOZOTOWN iOSアプリでのFatViewController解消への取り組み 」をご覧ください ↩