2025年9月19日(金)〜9月20日(日)にiOSDC Japan 2025が開催され、弊社ではスポンサーブース、スポンサーセッションを出させていただきました！

iOSDCではWifiに接続する＝ブログを書くと宣言しているので、弊社の参加レポートを書かさせていただきます！

1. チームラボブース活動報告！〜アンケート結果から見るiOSエンジニアのリアル〜

弊社のブースではモバイル開発に関するアンケートを実施しておりました。

アンケートではたくさんの方々に回答していただきました！ご協力ありがとうございました！

それでは、アンケート内容の結果を紹介させていただきます！

Day0 「モバイル開発、これから何が流行る？」

iOS開発の方々はとてもネイティブに対する熱量を感じました！まさに、iOSDCの盛り上がり度合いに相応しい結果となりました！

FlutterやKMP/CMPは同じくらいの割合となりました。

Day1 午前 「アプリの最小対応OSバージョン、今ならどこ？」

iOSの対応状況に関するアンケートでは、最新OS -1, -2あたりの対応が多く、たくさんの会社さんの事情が聞けました。技術的にはiOS16を切りたいという意見も多かったですが、ビジネス要件でOSが切れない苦労話などもたくさん聞けました。

Day2 午後 「「持続可能な開発」のために最も重要だと思うことは？」

開発体験が変わる世の中でも心理的安全性の高いチームが一番多いことに驚きました！それに反して、人間がいなくても開発ができる世界線もくるため、ドキュメントが重要という意見も聞こえ、時代を感じました！また、自動化による効率化でEditor MCPが流行るという方もいていろんな視点をいただけました！

Day3 午前 「LiquidGlassにどう対処する？」

やはり大半は、部分的に目立つ変更箇所の変更や周りの動き方をみて対応方針を決めている方々などが多かったです。ただ、人によっては、完全に対応した方々もかなりいたので、驚きました！

Day2 午後 「あなたのチームが現在抱える最大の課題は？」

最大の課題で一番票を集めたのが、人材不足やメンバーの育成でした！Day1午後では心理的安全性が票を集めたように、人が開発するうちはまだ、人に関する悩みが尽きないような雰囲気を感じました。技術的負債やバグの多さでは、引き継いだ時点での実装や、速度感を持ってリリースした時の負債などを多く抱える方々なども多く、リアルな意見が聞けました。また、不明確な要求仕様や頻繁な仕様変更にも悩まされている方々も多く、ビジネスと開発のトレードオフな開発の中で品質を保つことには大変考えさせられました。

2. 弊社スポンサーセッションレポート!!

セッションタイトル： 

CI/CD「健康診断」のススメ。現場でのボトルネック特定から、 健康診断を通じた組織的な改善手法

登壇者本人からのコメント： 

　今年は”CI/CD「健康診断」のススメ。現場でのボトルネック特定から、 健康診断を通じた組織的な改善手法”という題で発表させていただきました。iOSDCへの参加は今年で2回目となります。昨年初めて参加した際に「いつか登壇してみたい」と思っていたところ、今回機会をいただくことができました。

　今回のセッションでは、CI/CDの改善を「個人的な改善」と「組織での取り組み」の２つの軸で取り上げました。

前半では、何を改善したらいいかわからず困った経験を基に改善のポイントを解説し、後半では継続的な改善を行うための弊社ならではの取り組みをご紹介しました。

　このセッションが皆さんのCI/CD改善の参考になれば嬉しいです。また、普段はCI/CDにあまり関わらないという方にも、ご自身の役割に関わらず興味を持っていただき、改善に取り組むきっかけとなれたら幸いです。

発表資料の公開： https://speakerdeck.com/teamlab/iosdc-2025-teamlab

3. 弊社エンジニアが選ぶ！注目のセッションはこれだ！（ペアワークレポート）

ペアA

＜注目セッション＞

　iOSエンジニアの可能性を広げる：ソニーがKotlin/Compose Multiplatformに挑戦した理由（あなたもぜひ）

＜なぜ注目したか？＞ 

　現在、KMPを導入しているプロジェクトに参画しており、他の会社での活用事例や知見に興味があった。また、CMPについては知見が浅いため、どのように活用されているのかを知りたかった。

＜セッションから得た学びと今後の展望＞

　最大の学びは、チームやエンジニアのキャリアの可能性を広げる「橋渡し」の役割を担うという視点を得られたことです。80%のコードが共通化されており、iOS/Androidという垣根を超えて開発していけるというところに魅力を感じました。

　また、全てを共通化するのではなく、AppleらしいUIのために部分的にSwiftUIを使い分ける柔軟な姿勢も、現実的な導入の上で参考になります。

　今後の展望として、登壇者が強調していた「Start Small（小さく始める）」というアプローチをぜひ実践したいです。いきなり大規模な導入を目指すのではなく、まずは影響範囲の少ない共通ロジックや、小さな機能で試すことで、リスクを抑えながら私たちのプロジェクトに合うかどうかを見極められると考えています。この技術は、iOS/Androidの垣根を越え、私たちが「モバイルエンジニア」として成長していくための新たな選択肢になる可能性を秘めていると感じました。

　先日の弊社ブースのアンケートでは、多くのチームが「人手不足」を最大の課題として挙げていただきました。この課題に対し、iOS/Androidという垣根を超えて開発できる「モバイルエンジニア」というアプローチが有効な解決策になると考えています。

ペアB

＜注目セッション＞ 

　テストコードすら書けなかったレガシーアプリがAIと上手に協働できるようになるまでの軌跡

＜なぜ注目したか？＞

　テストコードがないレガシーアプリというテーマが、今参加してるプロジェクトの現状と全く同じだったからと、将来AIを使った開発ができるとなった時に参考にしたかった。

＜セッションから得た学びと今後の展望＞

　このセッションに注目したのは、テストコードがないレガシーアプリというテーマが、私たちのプロジェクトの現状と全く同じだったからです。 発表者が提唱した「とりあえず何でも書く」というマインドセットのシフトが最大の学びであり、完璧主義で作業が止まりがちな私たちにとって、すぐに実践できる現実的な解決策だと感じました。また、AIを開発の主役（60%担当）として積極的に活用する事例は、今後の効率化の大きなヒントになりました。この学びを活かして、今後は大掛かりな改修を待たずに「小さなテストを必ず書く」ルールを導入したいです。スピーカーがDroidKaigiや過去の登壇からヒントを得てこの改善に成功したと聞き、私自身もカンファレンスへの参加意欲がさらに高まりました。外部から継続的に新しいインスピレーションを得ていきたいと考えています。

ペアC

＜注目セッション＞

　航空券、マイナカード、クレカ 以外の可能性を できること ベースで考えよう！ 進化する Walletアプリ をあなたの選択肢に！

＜なぜ注目したか？＞

　ネイティブ機能をより積極的に活用する提案をしてみたいと思いました。Walletアプリは航空券やマイナンバーカードなど特定の用途に限られているという固定観念がありましたが、それを超えた多様な活用可能性を探りたいと考えました。

＜セッションから得た学びと今後の展望＞

・学び

　今回のセッションを通し、Walletは様々なソリューションに活用できるヒントを得ることができました。

特にPKPassLibraryの進化によりバックグラウンドでパスの追加できる機能は、ユーザーの手間を省いて活用を進めていけるとても良い機能だと思いました。

　また、ユーザーの状況ごとに多種なセマンティックタグの追加ができるため、アプリに機能を持たなくてもユーザーにあったサービスを提供できる点でも可能性を感じました。

本セッションによりWallteの機能は、アプリ利用への「繋ぎ」としての機能が多いことが得られたので、Walletのパスをアプリの入り口にすることで、ユーザーにまずサービスに触れてもらい、そこからアプリの機能利用につながると思いました。

・展望

　チームとしてもよりWalletの技術を調査していきながら、ユーザー体験をよりよくして行く方法について検討・提案を進めていきたい。

ペアD

＜注目セッション＞

　「iPhoneのマイナンバーカード」のすべて

＜なぜ注目したか？＞

　今後、マイナンバーカードを活用した本人確認（eKYC）や行政サービス関連のiOSアプリ開発案件が増加することを見込んでいます。本セッションを聴講することで、iOSへのマイナンバーカード機能の導入プロセスと技術仕様を正確に把握し、将来的な案件に活かすための知見を得ることを目的としました。

＜セッションから得た学びと今後の展望＞

・マイナンバーカードの技術仕様

　マイナンバーカードが一枚のICカードに複数のアプリケーション（AP）を搭載しているという、基本的ながら重要な仕様を再確認できました。

・JPKI-AP（公的個人認証）

・券面AP / 券面事項入力補助AP

・住基AP

・免許証AP

・最近、運転免許証APが追加されたことから、今後も利用可能なAPが拡張されていく可能性が高いと感じました。これは、我々が提案できるソリューションの幅が広がると考えています。

・Appleとの協業と開発プロセス

　通常、Appleとの関わりはアプリ審査でのやり取りに限定されがちですが、今回はOSレベルでの機能統合という、協業が行われていた点が印象的でした。

　Walletに表示するカードデザインにおいて、「富士山」の案もあった中で、特定の地域に偏らず全国民に親しまれる「桜」を採用したというエピソードはとても日本らしさを感じました！また、Wallet上のカード表示が画像ではなく、Appleによるコード実装である点は、驚きました。これにより、スクリーンショット等による安易な偽造を対策している話はとても面白かったです。

　行政のシステム開発は、時に硬直的で使いにくいものになりがちですが、今回はユースケースを基点とした開発が進められており、使いやすさが意識されていると感じました。開発期間の具体的な話は聞けませんでしたが、従来の政府システム開発と比較して、スムーズに進行した印象を受けました。

　本機能へのアクセスには、特別なエンタイトルメントが付与された専用APIを利用する必要があり、Appleや政府の厳格な管理下で、機能管理が行われているのは新鮮でした。

該当API: [JPKIPassContents | PassKit](https://developer.apple.com/documentation/passkit/jpkipasscontents)

・発表のうまさ

　セッションの内容だけでなく、発表の進め方そのものにも注目すべき点がありました。

　わかりやすい概要から詳細な技術的内容まで、段階的に理解を深めることができる構成になっていました。本来、複雑で難解なはずのマイナンバーカードの仕組みが、スムーズに理解でき、発表自体についても学びがありました。

　今後、社内で発表する際や、お客様に対して技術的な説明を行う際に、このような段階的なアプローチを参考にさせていただきたいと思います。

ペアE

＜注目セッション＞ 

　『ホットペッパービューティー』の iOSアプリをUIKitからSwiftUIへ段階的に 移行するためにやったこと

＜セッションから得た学びと今後の展望＞

学び：デザインガイドラインの重要性

　私がこのセッションで特に注目したのは、「デザインガイドラインとコードの構造上の乖離」です。このテーマは、多くの開発現場で「あるある」ではないでしょうか。

　たとえ優れたデザインガイドラインが存在していても、エンジニアが画面デザインからUIを実装するプロセスの中で、意図せずガイドラインの定義とズレが生じてしまうことがあります 。この「小さなズレ」が積み重なることで、コードの再利用性が下がり、知らないうちに大きな技術的負債となってしまいます 。

　デザインガイドラインは、単なる「見た目のルールブック」ではなく、デザイナーとエンジニアの垣根を越える「共通言語」なのだと私は理解しました。

展望：この学びを元に、今後のUI開発プロセスをより良くしていくために、以下の取り組みを検討できるかもしれません。

　デザインガイドラインで定義されたコンポーネントの命名規則や責務を、エンジニアが実装するコンポーネントと完全に一致させるアプローチです。

　これにより、実装時に「このUIはどのコンポーネントだろう」と迷う時間が減り、コードの再利用性が劇的に向上するのではないでしょうか。また、デザイナーと「あのボタンコンポーネントの仕様ですが…」といったように、具体的な名前を元にした円滑なコミュニケーションが期待できます。

ペアF

＜注目セッション＞

　半自動E2Eで手っ取り早くリグレッションテストを効率化しよう

＜なぜ注目したか？＞ 

　タイトルで「自動」と謳わずに「半自動」という表現を用いていることが印象的でした。技術発表では少し誇張した表現も散見される中で、あえて不完全さを意味する「半自動」という言葉を選んだ理由が気になりました。さらに、アブストラクトでは「完璧な自動化を目指さない」と明言しており、意図的に完璧を捨てていることも伺えました。この「完璧を目指さない」という考え方は、当時の私にとってクリティカルな視点でした。業務で完璧を目指すが故に思うような進捗が生まれず、焦りや不安を感じていたタイミングで「まずは60点、70点を目指したらどうか」というアドバイスを受けた直後だったからです。しかし、100点でない目標に向かって進むことへの不安も拭えずにいました。このセッションは、「完璧を目指さない課題解決」の一つの指針になるのではないかと感じました。

＜セッションから得た学びと今後の展望＞

　本セッションは、E2Eリグレッションテストの自動化というテーマを題材に、「完璧を目指さない課題解決」がいかに現実的で、有効なアプローチであるかを具体的に示してくれました。そして、そのアプローチの最も本質的な部分だと私が感じたのが、「実行環境を外部のSaaSからローカル環境へと変更する」という方針転換です。この決断の背景には「完璧を目指さないこと = 将来の成長性が見えること」という、このセッションの重要な思想があると感じました。仮にSaaSを用いて70点の運用ができたとしても、そのプロセスの多くはブラックボックス化されてしまい、改善したくても自分たちでコントロールできる範囲は限られてしまいます。しかし、シナリオをRubyで独自記述し実機でローカル実行する手法では、改善のために干渉できるポイントが多数存在します。実際セッションの中でも、複数の改善点の紹介がありました。さらに、それらは具体的な改善手法もイメージしやすく、実現性が高いと感じるものばかりでした。つまり、最初は70点でもリソースを割けば確実に点数が上がることが保証されてる状態になっています。本セッションから得た最も大きな学びは、「完璧を目指さないこと」による不安は、「改善できる」という見通しによって解消される、という考え方でした。この考え方は、E2Eテスト自動化という特定の課題に留まらず、日々の業務で挑戦する心理的なハードルを下げてくれると感じています。

4. おわりに

今年のiOSDCは10周年ということもあり、これまで以上の盛り上がりを見せていました。

このカンファレンスで感じたiOS開発への尋常ではない熱量は、私たち開発者にとっては感無量でした。

最高の学びと熱狂を共有してくださった登壇者、参加者、そして運営の皆様に心より感謝申し上げます。

最後まで読んでいただき、ありがとうございました。チームラボでは現在、多岐にわたる業界のアプリ開発を担当して頂くエンジニアをiOS/Android/Flutterともに募集しています。モダンな技術を使用した開発や、サービスの企画提案、技術選定など上流工程からプロジェクトに入りたい、というエンジニアの皆様、ご応募お待ちしています！