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

炎上の中リリースされ、
長い間メンテナンスされず、
当時の担当者もチームに不在。

アーキテクチャも成立しておらず、
ソースコードはスパゲッティ、
テストコードはもちろん書けない。

私は、そんなレガシーなアプリのリニューアルプロジェクトにアサインされたAndroidエンジニアです。
iOS未経験の立場でチームのリードとしてiOS版の技術的な意思決定にも関与することとなりました。

Androidエンジニアとしての知見をベースに
・リアーキテクト
・ユニットテストの整備
・SwiftUIの導入
・生成AIとの協働
をiOSアプリで実現するまでの取り組みをお話しする予定です。

少しイロモノなトピックかもしれませんが、レガシーから脱却するために効いた取り組みの事例が、皆さんのエンジニアリングの参考になればと思います。

iOSDC2025 スポンサーセッションの登壇資料です
https://fortee.jp/iosdc-japan-2025/proposal/dfea09ab-3ebf-4327-8c9f-c52f90db08ae

Transcript

1. テストコードすら書けなかったレガシーアプリが AIと上⼿に協働できるようになるまでの軌跡 iOSDC 2025 スポンサーセッション ディップ株式会社 1
2. セッションのゴール • dipと開発組織のことを知ってもらう • チームでの取り組みと変化を知ってもらう
3. セッションのゴール • dipと開発組織のことを知ってもらう • チームでの取り組みと変化を知ってもらう • 同じ課題を抱えている⼈のヒントになったり、取り組み に共感してもらえたら嬉しいです！
4. Copyright © DIP Corporation, All rights reserved. Agenda 1. ⾃⼰紹介 2. 会社紹介 3. はじめに 4. アプリ改善の取り組み 5. さいごに
5. 吉田 誠 Yoshida Makoto ディップ株式会社 ソリューション開発本部メディア開発統括部 Androidエンジニア • 人生初のiOSDCで、人生初の登壇 • カンファレンスネイルがアツい • ものすごく緊張しています • お手柔らかにお願いします
6. 会社紹介
7. 会社紹介：ディップ株式会社とは 7 ビジョン “Labor force solution company” ⼈材サービスとDXサービスの提供を通して、労働市場における諸課題を解決し、 誰もが働く喜びと幸せを感じられる社会の実現を⽬指します。 × DX事業 Digital labor force solution バイトコミュニケーションアプリ『バイトルトーク』や、 機能を絞ったシンプルなSaaS型の『コボット』を通じて、 職場環境やコミュニケーション課題を解決 しています。 ⼈材サービス事業 Human work force solution ユーザーファーストな独自機能を搭載した、 求人情報・人材紹介サービスの提供を通じて、 ユーザーの就業課題 を解決しています。
8. 会社紹介：dip Tech Vision 素早く安全に、継続して価値を届けられる開発体制へ
9. はじめに
10. はじめに：今⽇お話しすること テストを書きたくても書けなかったレガシーなアプリが、 レガシーを克服しつつ、 ⽣成AIと協働できるようになるまで。
11. はじめに：今⽇お話しすること テストを書きたくても書けなかったレガシーなアプリが、 レガシーを克服しつつ、 ⽣成AIと協働できるようになるまで。 ※Androidアプリ開発の知⾒をベースにしたところがミソ
12. • 正社員向けの求⼈広告サービス • UIリニューアルプロジェクト(⼀部) • 内部の作り替えも⾏っていた • 機能はあまり多くなく、⽐較的シンプル はじめに：今⽇お話しすること 「バイトルNEXT」のお話
13. はじめに：期待値コントロール • リアーキテクト • ユニットテストの導⼊ • 宣⾔的UIの導⼊ • ⽣成AIとの協働 に関して、広く浅く触れていきます🙇
14. もっと聞きたい、知りたい⽅へ 弊社ブースでエンジニアとお話しできます🙌 ぜひ遊びに来てください！
15. アプリ改善の取り組み 〜リアーキテクト〜
16. アプリ改善の取り組み: リアーキテクト アプリが抱えていた課題 • 炎上スケジュールの中リリースされた • 依存関係とデータフローが整理されてい ない • フレームワーク依存が散らばっている • テストコードを書けない品質 デフォルメにデフォルメを重ねて、 かろうじて図になったもの
17. アプリ改善の取り組み: 抱えていた課題 当然、様々な問題を引き起こすリスクがあった 無秩序な コード テストコード 実装不可 認知負荷 増大 自動テスト 整備不可 変更が困 難 計画通りに 進まない 見積もり 精度低下 • リリースの遅延 • 施策効果低下 • 開発組織の信頼低下 • チームの疲弊 • メンバー離職 など 止まらない コスト増
18. アプリ改善の取り組み: リアーキテクト どうやったら解決できるか
19. アプリ改善の取り組み: リアーキテクト どうやったら解決できるか • モジュールの役割と境界の整理 • 依存の関係、データフローの整理 • ユニットテストの導⼊
20. アプリ改善の取り組み: リアーキテクト どうやったら解決できるか • モジュールの役割と境界の整理 • 依存の関係、データフローの整理 • ユニットテストの導⼊ アーキテクチャの適⽤が有効そう💡
21. アプリ改善の取り組み: リアーキテクト 「バイトルNEXT」のお話 • 正社員向けの求⼈広告サービス • UIリニューアルプロジェクト(⼀部) • 内部の作り替えも⾏っていた • 機能はあまり多くなく、⽐較的シンプル
22. アプリ改善の取り組み: リアーキテクト AndroidではGoogle推奨の 「3層レイヤードアーキテクチャ」 がデファクト。 これをiOSでも採⽤することにした。 ※GUIアーキテクチャは MVVMライクなもの
23. アプリ改善の取り組み: リアーキテクト 「別のシステムアーキテクチャへのスライドも現実的」 と考えて、iOSでも導⼊した
24. アプリ改善の取り組み: リアーキテクト ガイドに従い、既存機能を 「表⽰(UI Layer)」 「ビジネスロジック(Domain Layer)」 「データアクセス(Data Layer)」 に整理‧分解し再実装
25. アプリ改善の取り組み: リアーキテクト アーキテクチャーレイヤー以下は feature駆動パッケージングを意識した構成 data ├─ featureXX/ │ ├─ XXApi │ ├─ XXRepository │ └─ XXResponse ├─ featureYY/ │ ├─ YYApi │ ├─ YYRepository │ └─ YYResponse └─ featureZZ/ ├─ ZZDao ├─ ZZRecord └─ ZZRepository domain ├─ featureXX/ │ ├─ XXUseCase │ └─ XXDomainData ├─ featureYY/ │ ├─ YYUseCase │ └─ YYDomainData └─ featureZZ/ ├─ ZZUseCase └─ ZZDomainData
26. アプリ改善の取り組み: リアーキテクト 機能という関⼼に基づいてクラスが集まり コードの読解がしやすくなった data ├─ featureXX/ │ ├─ XXApi │ ├─ XXRepository │ └─ XXResponse ├─ featureYY/ │ ├─ YYApi │ ├─ YYRepository │ └─ YYResponse └─ featureZZ/ ├─ ZZDao ├─ ZZRecord └─ ZZRepository domain ├─ featureXX/ │ ├─ XXUseCase │ └─ XXDomainData ├─ featureYY/ │ ├─ YYUseCase │ └─ YYDomainData └─ featureZZ/ ├─ ZZUseCase └─ ZZDomainData 読み書きしやすい！
27. アプリ改善の取り組み 〜ユニットテストの導⼊〜
28. アプリ改善の取り組み: ユニットテスト DBやAPIに依存するモジュールを テストダブルで置き換えられるようになった
29. アプリ改善の取り組み: ユニットテスト ユニットテストのコードなら書けそうだけど‧‧‧ どんなものを書けばいいだろう？ 🤔なんとなく想像はできるけど、 正直、あまりよくわからん...
30. アプリ改善の取り組み: ユニットテスト 最低限意識するべきことに⽬星をつけた • テストの単位は⼀つの振る舞い ◦ 「仕事⼀覧を取得する」 ◦ 「古いものを削除する」 ◦ 「〜〜する」の命名を意識してみた • AAAパターンで記述 ◦ テストの流れの道標 ◦ 書き⽅を統⼀できる 著:Vladimir Khorikov 訳:須田智之 単体テストの考え方 /使い方 マイナビ出版(2022)
31. アプリ改善の取り組み: ユニットテスト ユニットテストに期待する効果を整理してみた
32. アプリ改善の取り組み: ユニットテスト ユニットテストに期待する効果を整理 • テスト対象となる関数の結果を保証
33. アプリ改善の取り組み: ユニットテスト ユニットテストに期待する効果を整理 • テスト対象となる関数の結果を保証 • リグレッションの早期検知
34. アプリ改善の取り組み: ユニットテスト ユニットテストに期待する効果を整理 • テスト対象となる関数の結果を保証 • リグレッションの早期検知 • 端末操作に依存しない迅速な確認手段
35. アプリ改善の取り組み: ユニットテスト ユニットテストに期待する効果を整理 • テスト対象となる関数の結果を保証 • リグレッションの早期検知 • 端末操作に依存しない迅速な確認手段 • 綺麗な構造の維持
36. アプリ改善の取り組み: ユニットテスト ユニットテストに期待する効果を整理 • テスト対象となる関数の結果を保証 • リグレッションの早期検知 • 端末操作に依存しない迅速な確認手段 • 綺麗な構造の維持 • 仕様を表現する情報資産
37. アプリ改善の取り組み: ユニットテスト 現場の課題を鑑みて、２点にフォーカス • テスト対象となる関数の動きを保証 • リグレッションの早期検知 • フルビルドや端末操作に依存しない迅速な確認手段 • 綺麗な構造の維持 • 仕様を表現する情報資産
38. アプリ改善の取り組み: ユニットテスト ユニットテストの効果を得るために...
39. アプリ改善の取り組み: ユニットテスト ユニットテストの効果を得るために... • とにかくテストが書ければ OK󰢏
40. アプリ改善の取り組み: ユニットテスト ユニットテストの効果を得るために... • とにかくテストが書ければ OK󰢏 ◦ 構造を維持するには、アーキテクチャに則った上で 正常系だけでもテストが書ければ十分と考えた ◦ テストコードが増えれば、形式知が増えて属人化も抑えられる
41. アプリ改善の取り組み: ユニットテスト ユニットテストの効果を得るために... • とにかくテストが書ければ OK󰢏 ◦ 構造を維持するには、アーキテクチャに則った上で正常系だけでも テストが書ければ十分と考えた ◦ テストコードが増えれば、形式知が増えて属人化も抑えられる ちょっと楽観的
42. アプリ改善の取り組み: ユニットテスト ユニットテストの効果を得るために... • とにかくテストが書ければ OK󰢏 • ただしDataSourceの差し替えのみで書く
43. アプリ改善の取り組み: ユニットテスト ユニットテストの効果を得るために... • とにかくテストが書ければ OK󰢏 • ただしDataSourceの差し替えのみで書く ◦ 外部依存は DataSourceに閉じていて、ここの差し替えでテストは 書ける ◦ DataSource以外の置き換えると、アーキテクチャ構造の無視が 可能になってしまう ◦ そうなると構造を維持する効果がなくなってしまう
44. アプリ改善の取り組み: ユニットテスト ユニットテストをみんなの習慣にするために...
45. アプリ改善の取り組み: ユニットテスト ユニットテストをみんなの習慣にするために... • とにかくテストが書ければ OK(再)
46. アプリ改善の取り組み: ユニットテスト ユニットテストをみんなの習慣にするために... • とにかくテストが書ければ OK(再) ◦ リリースまでに書けば実装の前でも後でも同時でもいい ◦ PRを分けても分けなくても良い ◦ チケットの作成もお任せ ◦ カバレッジ 100%も目指さない
47. アプリ改善の取り組み: ユニットテスト とりあえず書くか...
48. アプリ改善の取り組み: ユニットテスト とりあえず書くか... 書かないとモヤモヤするな... ここのテスト欲しいな
49. アプリ改善の取り組み: ユニットテスト とりあえず書くか... 書かないとモヤモヤするな... ここのテスト欲しいな てかもう書いておきました！！
50. アプリ改善の取り組み: ユニットテスト とりあえず書くか... 書かないとモヤモヤするな... ここのテスト欲しいな てかもう書いておきました！！ テストを書く習慣が定着した！
51. アプリ改善の取り組み: ユニットテスト 期待通りの効果を得られたかというと... ✅ 綺麗な構造の維持 → テスト可能な状態が維持されるので効果は⼗分 → しかし⼤枠の構造の維持はアーキテクチャへの理解も⼤事 → アーキテクチャのドキュメント拡充も併せて⾏った
52. アプリ改善の取り組み: ユニットテスト 期待通りの効果を得られたかというと... ✅ 仕様を表現する情報資産 → 新規実装も、テストコードを読むだけでかなり理解が深まる → 継続してテストを増やすことで、暗黙知の抑制は⼗分期待できる → テストが「振る舞い」を表現している効果も⼤きいと感じる
53. アプリ改善の取り組み: ユニットテスト 結局、期待以上の成果も得られた ✅ テスト対象となる関数の動きを保証 ✅ リグレッションの早期検知 ✅ フルビルドや端末操作に依存しない迅速な確認手段
54. アプリ改善の取り組み: ユニットテスト 結局、期待以上の成果も得られた ✅ テスト対象となる関数の動きを保証 ✅ リグレッションの早期検知 ✅ フルビルドや端末操作に依存しない迅速な確認手段 「書いた結果、⾊々捗る」という実体験も、 チームの習慣化の要因だったかも
55. アプリ改善の取り組み 〜宣⾔的UIの導⼊〜
56. アプリ改善の取り組み: 宣⾔的UIの導⼊ 画面のリニューアルに伴って、 Viewも宣言的UIに移行 SwiftUI Jetpack Compose
57. アプリ改善の取り組み: 宣⾔的UIの導⼊ 書く前は、 「ついにモダンな技術で開発ができる！」 とワクワクしていた 😀
58. アプリ改善の取り組み: 宣⾔的UIの導⼊ いざ書いてみると、 「ファイル肥大化」「どう分けるべきかわからない」 という課題に直面 ... 😵
59. アプリ改善の取り組み: 宣⾔的UIの導⼊ Androidコミュニティの知⾒が集まるOSSを参考にした • android/compose-samples • android/nowinandroid • DroidKaigi/conference-app-2023
60. アプリ改善の取り組み: 宣⾔的UIの導⼊ https://github.com/android/compose-samples android/compose-samples ◦ Jetpack Compose実装のサンプルアプリ群
61. アプリ改善の取り組み: 宣⾔的UIの導⼊ android/nowinandroid ◦ KotlinとJetpack Composeのベストプラクティスとして Googleが公開している https://github.com/android/nowinandroid
62. アプリ改善の取り組み: 宣⾔的UIの導⼊ • DroidKaigi/conference-app-2023 ◦ 毎年トレンドの最先端を⾏きがち(近年はKMPで実装) https://github.com/DroidKaigi/conference-app-2023
63. アプリ改善の取り組み: 宣⾔的UIの導⼊ DroidKaigiのリポジトリで、View分割に関するissueが⾒つかった https://github.com/DroidKaigi/conference-app-2023/issues/84
64. アプリ改善の取り組み: 宣⾔的UIの導⼊ issueでは、Viewを3階層で分割す るアイデアが議論されていた
65. アプリ改善の取り組み: 宣⾔的UIの導⼊ プロダクトでも、DroidKaigiのアイデアをベースに戦略を⽴てた
66. アプリ改善の取り組み: 宣⾔的UIの導⼊ 詳しくはdipのテックブログで解説しています📖
67. アプリ改善の取り組み: 宣⾔的UIの導⼊ ✅ UIファイルの肥⼤化解消 ✅ 実装タスクの細分化‧分担しやすくなっ た ✅ PRが⼩さくなりレビューしやすくなった presentation └─ screen/ ├─ component/ │ ├─ HogeComponent │ └─ FugaComponent ├─ section/ │ ├─ HogeSection │ └─ FugaSection └─ XXView
68. アプリ改善の取り組み: 宣⾔的UIの導⼊ 権威のあるリファレンスに実装を寄せたことが⾃信につながって 前向きに楽しくUI実装できるようになった🎉
69. アプリ改善の取り組み 〜AIとの協働〜
70. アプリ改善の取り組み: AIとの協働 今年から開発でAIツールが使えるようになった🎊
71. アーキテクチャが整ったことで、 ソフトウェアの構造を説明可能になっていた アプリ改善の取り組み: AIとの協働
72. アプリ改善の取り組み: AIとの協働 AIのためのルールファイルが書けたおかげか 的外れな出⼒は、ほとんど起きなかった 🤖 ナルホド...
73. アプリ改善の取り組み: AIとの協働 Devinを⽤いて「AIがコーディング → PRを⼈が修正」の流れが定着 実装がブレにくいData Layerの開発と相性が良い感触
74. アプリ改善の取り組み: AIとの協働 Devinが書いたコード6割、⼈が書いたコード4割 ぐらいの割合で安定
75. アプリ改善の取り組み: AIとの協働 抽象度の⾼い領域では⼈が主導のコーディングしている CursorやClaude Codeにブーストしてもらっている
76. アプリ改善の取り組み: 振り返り テストを書けなかった頃は...
77. さいごに 😔 単純な対応にも時間がかかる... 新しい技術を全然触れない... 周りから置いてかれている... キャリアが不安...
78. アプリ改善の取り組み: 振り返り レガシーさを解消しつつ、トレンドのAI活⽤に漕ぎ着けた “2025年っぽい開発者体験”を感じられるようになった
79. さいごに ☺ コードが読みやすくて仕事を進めやすい モダンな技術で効率よく開発 流⾏についていけるようになった キャリアの不安も軽減
80. Copyright © DIP Corporation, All rights reserved. まとめ 1. リアーキテクト 2. ユニットテストの導⼊ 3. 宣⾔的UIの導⼊ 4. AIとの協働 Google推奨アーキテクチャとfeature駆動パッケージングの実践 読み書きに迷う時間が減り、テスタビリティも得られた 「とにかく書く」ために意識の低いスタンスを重視 結果、期待以上の恩恵を得られた Androidコミュニティの知⾒をベースに分割⽅針を決めた うまくワークし、保守性と開発効率が向上した アプリの構造が説明可能になり、効果的なルールを作れた 出⼒の精度が上がり、コーディングの6割ぐらいをAIに任せられた
81. アプリ改善の取り組み: 反省と学び 最初はOSのボーダーを意識しすぎていた 実際はソフトウェアとして共通の課題も多く、 知⾒やテクニックの流⽤も効いた 同じように⽇和っている⼈がいたら、 ⼀歩踏み越えてコラボできるといいかも🐣
82. さいごに
83. 「挑戦し、変化し、リードする仲間」を募集中 エンジニアリングの⼒でビジネスを成⻑させ、 「誰もが働く喜びと幸せを感じられる社会」を共に実現しましょう。 83 📎採用情報 📎インタビュー記事 📎テックブログ
84. QRコードからカジュアル⾯談の 案内ページに⾶べます！🚀 「挑戦し、変化し、リードする仲間」を募集中 カジュアル⾯談も実施しています！ 興味がある⽅、ぜひ⼀度お話しましょう🙌 84
85. ご清聴ありがとうございました🙇