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

Slide 1

Slide 1 text

テストコードすら書けなかったレガシーアプリが AIと上⼿に協働できるようになるまでの軌跡 iOSDC 2025 スポンサーセッションディップ株式会社 1

Slide 2

Slide 2 text

セッションのゴール ● dipと開発組織のことを知ってもらう ● チームでの取り組みと変化を知ってもらう

Slide 3

Slide 3 text

セッションのゴール ● dipと開発組織のことを知ってもらう ● チームでの取り組みと変化を知ってもらう ● 同じ課題を抱えている⼈のヒントになったり、取り組みに共感してもらえたら嬉しいです！

Slide 4

Slide 4 text

Slide 5

Slide 5 text

吉田誠 Yoshida Makoto ディップ株式会社ソリューション開発本部メディア開発統括部 Androidエンジニア ● 人生初のiOSDCで、人生初の登壇 ● カンファレンスネイルがアツい ● ものすごく緊張しています ● お手柔らかにお願いします

Slide 6

Slide 6 text

会社紹介

Slide 7

Slide 7 text

会社紹介：ディップ株式会社とは 7 ビジョン “Labor force solution company” ⼈材サービスとDXサービスの提供を通して、労働市場における諸課題を解決し、誰もが働く喜びと幸せを感じられる社会の実現を⽬指します。 × DX事業 Digital labor force solution バイトコミュニケーションアプリ『バイトルトーク』や、機能を絞ったシンプルなSaaS型の『コボット』を通じて、職場環境やコミュニケーション課題を解決しています。⼈材サービス事業 Human work force solution ユーザーファーストな独自機能を搭載した、求人情報・人材紹介サービスの提供を通じて、ユーザーの就業課題を解決しています。

Slide 8

Slide 8 text

会社紹介：dip Tech Vision 素早く安全に、継続して価値を届けられる開発体制へ

Slide 9

Slide 9 text

はじめに

Slide 10

Slide 10 text

はじめに：今⽇お話しすることテストを書きたくても書けなかったレガシーなアプリが、レガシーを克服しつつ、⽣成AIと協働できるようになるまで。

Slide 11

Slide 11 text

はじめに：今⽇お話しすることテストを書きたくても書けなかったレガシーなアプリが、レガシーを克服しつつ、⽣成AIと協働できるようになるまで。 ※Androidアプリ開発の知⾒をベースにしたところがミソ

Slide 12

Slide 12 text

● 正社員向けの求⼈広告サービス ● UIリニューアルプロジェクト(⼀部) ● 内部の作り替えも⾏っていた ● 機能はあまり多くなく、⽐較的シンプルはじめに：今⽇お話しすること「バイトルNEXT」のお話

Slide 13

Slide 13 text

はじめに：期待値コントロール ● リアーキテクト ● ユニットテストの導⼊ ● 宣⾔的UIの導⼊ ● ⽣成AIとの協働に関して、広く浅く触れていきます🙇

Slide 14

Slide 14 text

もっと聞きたい、知りたい⽅へ弊社ブースでエンジニアとお話しできます🙌 ぜひ遊びに来てください！

Slide 15

Slide 15 text

アプリ改善の取り組み〜リアーキテクト〜

Slide 16

Slide 16 text

アプリ改善の取り組み: リアーキテクトアプリが抱えていた課題 ● 炎上スケジュールの中リリースされた ● 依存関係とデータフローが整理されていない ● フレームワーク依存が散らばっている ● テストコードを書けない品質デフォルメにデフォルメを重ねて、かろうじて図になったもの

Slide 17

Slide 17 text

アプリ改善の取り組み: 抱えていた課題当然、様々な問題を引き起こすリスクがあった無秩序なコードテストコード実装不可認知負荷増大自動テスト整備不可変更が困難計画通りに進まない見積もり精度低下 ● リリースの遅延 ● 施策効果低下 ● 開発組織の信頼低下 ● チームの疲弊 ● メンバー離職など止まらないコスト増

Slide 18

Slide 18 text

アプリ改善の取り組み: リアーキテクトどうやったら解決できるか

Slide 19

Slide 19 text

アプリ改善の取り組み: リアーキテクトどうやったら解決できるか ● モジュールの役割と境界の整理 ● 依存の関係、データフローの整理 ● ユニットテストの導⼊

Slide 20

Slide 20 text

アプリ改善の取り組み: リアーキテクトどうやったら解決できるか ● モジュールの役割と境界の整理 ● 依存の関係、データフローの整理 ● ユニットテストの導⼊アーキテクチャの適⽤が有効そう💡

Slide 21

Slide 21 text

アプリ改善の取り組み: リアーキテクト「バイトルNEXT」のお話 ● 正社員向けの求⼈広告サービス ● UIリニューアルプロジェクト(⼀部) ● 内部の作り替えも⾏っていた ● 機能はあまり多くなく、⽐較的シンプル

Slide 22

Slide 22 text

アプリ改善の取り組み: リアーキテクト AndroidではGoogle推奨の「3層レイヤードアーキテクチャ」がデファクト。これをiOSでも採⽤することにした。 ※GUIアーキテクチャは MVVMライクなもの

Slide 23

Slide 23 text

アプリ改善の取り組み: リアーキテクト「別のシステムアーキテクチャへのスライドも現実的」と考えて、iOSでも導⼊した

Slide 24

Slide 24 text

アプリ改善の取り組み: リアーキテクトガイドに従い、既存機能を「表⽰(UI Layer)」「ビジネスロジック(Domain Layer)」「データアクセス(Data Layer)」に整理‧分解し再実装

Slide 25

Slide 25 text

アプリ改善の取り組み: リアーキテクトアーキテクチャーレイヤー以下は feature駆動パッケージングを意識した構成 data ├─ featureXX/ │ ├─ XXApi │ ├─ XXRepository │ └─ XXResponse ├─ featureYY/ │ ├─ YYApi │ ├─ YYRepository │ └─ YYResponse └─ featureZZ/ ├─ ZZDao ├─ ZZRecord └─ ZZRepository domain ├─ featureXX/ │ ├─ XXUseCase │ └─ XXDomainData ├─ featureYY/ │ ├─ YYUseCase │ └─ YYDomainData └─ featureZZ/ ├─ ZZUseCase └─ ZZDomainData

Slide 26

Slide 26 text

アプリ改善の取り組み: リアーキテクト機能という関⼼に基づいてクラスが集まりコードの読解がしやすくなった data ├─ featureXX/ │ ├─ XXApi │ ├─ XXRepository │ └─ XXResponse ├─ featureYY/ │ ├─ YYApi │ ├─ YYRepository │ └─ YYResponse └─ featureZZ/ ├─ ZZDao ├─ ZZRecord └─ ZZRepository domain ├─ featureXX/ │ ├─ XXUseCase │ └─ XXDomainData ├─ featureYY/ │ ├─ YYUseCase │ └─ YYDomainData └─ featureZZ/ ├─ ZZUseCase └─ ZZDomainData 読み書きしやすい！

Slide 27

Slide 27 text

アプリ改善の取り組み〜ユニットテストの導⼊〜

Slide 28

Slide 28 text

アプリ改善の取り組み: ユニットテスト DBやAPIに依存するモジュールをテストダブルで置き換えられるようになった

Slide 29

Slide 29 text

アプリ改善の取り組み: ユニットテストユニットテストのコードなら書けそうだけど‧‧‧ どんなものを書けばいいだろう？ 🤔なんとなく想像はできるけど、正直、あまりよくわからん...

Slide 30

Slide 30 text

アプリ改善の取り組み: ユニットテスト最低限意識するべきことに⽬星をつけた ● テストの単位は⼀つの振る舞い ○ 「仕事⼀覧を取得する」 ○ 「古いものを削除する」 ○ 「〜〜する」の命名を意識してみた ● AAAパターンで記述 ○ テストの流れの道標 ○ 書き⽅を統⼀できる著:Vladimir Khorikov 訳:須田智之単体テストの考え方 /使い方マイナビ出版(2022)

Slide 31

Slide 31 text

アプリ改善の取り組み: ユニットテストユニットテストに期待する効果を整理してみた

Slide 32

Slide 32 text

アプリ改善の取り組み: ユニットテストユニットテストに期待する効果を整理 ● テスト対象となる関数の結果を保証

Slide 33

Slide 33 text

アプリ改善の取り組み: ユニットテストユニットテストに期待する効果を整理 ● テスト対象となる関数の結果を保証 ● リグレッションの早期検知

Slide 34

Slide 34 text

アプリ改善の取り組み: ユニットテストユニットテストに期待する効果を整理 ● テスト対象となる関数の結果を保証 ● リグレッションの早期検知 ● 端末操作に依存しない迅速な確認手段

Slide 35

Slide 35 text

アプリ改善の取り組み: ユニットテストユニットテストに期待する効果を整理 ● テスト対象となる関数の結果を保証 ● リグレッションの早期検知 ● 端末操作に依存しない迅速な確認手段 ● 綺麗な構造の維持

Slide 36

Slide 36 text

アプリ改善の取り組み: ユニットテストユニットテストに期待する効果を整理 ● テスト対象となる関数の結果を保証 ● リグレッションの早期検知 ● 端末操作に依存しない迅速な確認手段 ● 綺麗な構造の維持 ● 仕様を表現する情報資産

Slide 37

Slide 37 text

アプリ改善の取り組み: ユニットテスト現場の課題を鑑みて、２点にフォーカス ● テスト対象となる関数の動きを保証 ● リグレッションの早期検知 ● フルビルドや端末操作に依存しない迅速な確認手段 ● 綺麗な構造の維持 ● 仕様を表現する情報資産

Slide 38

Slide 38 text

アプリ改善の取り組み: ユニットテストユニットテストの効果を得るために...

Slide 39

Slide 39 text

アプリ改善の取り組み: ユニットテストユニットテストの効果を得るために... ● とにかくテストが書ければ OK󰢏

Slide 40

Slide 40 text

アプリ改善の取り組み: ユニットテストユニットテストの効果を得るために... ● とにかくテストが書ければ OK󰢏 ○ 構造を維持するには、アーキテクチャに則った上で正常系だけでもテストが書ければ十分と考えた ○ テストコードが増えれば、形式知が増えて属人化も抑えられる

Slide 41

Slide 41 text

アプリ改善の取り組み: ユニットテストユニットテストの効果を得るために... ● とにかくテストが書ければ OK󰢏 ○ 構造を維持するには、アーキテクチャに則った上で正常系だけでもテストが書ければ十分と考えた ○ テストコードが増えれば、形式知が増えて属人化も抑えられるちょっと楽観的

Slide 42

Slide 42 text

アプリ改善の取り組み: ユニットテストユニットテストの効果を得るために... ● とにかくテストが書ければ OK󰢏 ● ただしDataSourceの差し替えのみで書く

Slide 43

Slide 43 text

アプリ改善の取り組み: ユニットテストユニットテストの効果を得るために... ● とにかくテストが書ければ OK󰢏 ● ただしDataSourceの差し替えのみで書く ○ 外部依存は DataSourceに閉じていて、ここの差し替えでテストは書ける ○ DataSource以外の置き換えると、アーキテクチャ構造の無視が可能になってしまう ○ そうなると構造を維持する効果がなくなってしまう

Slide 44

Slide 44 text

アプリ改善の取り組み: ユニットテストユニットテストをみんなの習慣にするために...

Slide 45

Slide 45 text

アプリ改善の取り組み: ユニットテストユニットテストをみんなの習慣にするために... ● とにかくテストが書ければ OK(再)

Slide 46

Slide 46 text

アプリ改善の取り組み: ユニットテストユニットテストをみんなの習慣にするために... ● とにかくテストが書ければ OK(再) ○ リリースまでに書けば実装の前でも後でも同時でもいい ○ PRを分けても分けなくても良い ○ チケットの作成もお任せ ○ カバレッジ 100%も目指さない

Slide 47

Slide 47 text

アプリ改善の取り組み: ユニットテストとりあえず書くか...

Slide 48

Slide 48 text

アプリ改善の取り組み: ユニットテストとりあえず書くか... 書かないとモヤモヤするな... ここのテスト欲しいな

Slide 49

Slide 49 text

アプリ改善の取り組み: ユニットテストとりあえず書くか... 書かないとモヤモヤするな... ここのテスト欲しいなてかもう書いておきました！！

Slide 50

Slide 50 text

アプリ改善の取り組み: ユニットテストとりあえず書くか... 書かないとモヤモヤするな... ここのテスト欲しいなてかもう書いておきました！！テストを書く習慣が定着した！

Slide 51

Slide 51 text

アプリ改善の取り組み: ユニットテスト期待通りの効果を得られたかというと... ✅ 綺麗な構造の維持 → テスト可能な状態が維持されるので効果は⼗分 → しかし⼤枠の構造の維持はアーキテクチャへの理解も⼤事 → アーキテクチャのドキュメント拡充も併せて⾏った

Slide 52

Slide 52 text

アプリ改善の取り組み: ユニットテスト期待通りの効果を得られたかというと... ✅ 仕様を表現する情報資産 → 新規実装も、テストコードを読むだけでかなり理解が深まる → 継続してテストを増やすことで、暗黙知の抑制は⼗分期待できる → テストが「振る舞い」を表現している効果も⼤きいと感じる

Slide 53

Slide 53 text

アプリ改善の取り組み: ユニットテスト結局、期待以上の成果も得られた ✅ テスト対象となる関数の動きを保証 ✅ リグレッションの早期検知 ✅ フルビルドや端末操作に依存しない迅速な確認手段

Slide 54

Slide 54 text

アプリ改善の取り組み: ユニットテスト結局、期待以上の成果も得られた ✅ テスト対象となる関数の動きを保証 ✅ リグレッションの早期検知 ✅ フルビルドや端末操作に依存しない迅速な確認手段「書いた結果、⾊々捗る」という実体験も、チームの習慣化の要因だったかも

Slide 55

Slide 55 text

アプリ改善の取り組み〜宣⾔的UIの導⼊〜

Slide 56

Slide 56 text

アプリ改善の取り組み: 宣⾔的UIの導⼊画面のリニューアルに伴って、 Viewも宣言的UIに移行 SwiftUI Jetpack Compose

Slide 57

Slide 57 text

アプリ改善の取り組み: 宣⾔的UIの導⼊書く前は、「ついにモダンな技術で開発ができる！」とワクワクしていた 😀

Slide 58

Slide 58 text

アプリ改善の取り組み: 宣⾔的UIの導⼊いざ書いてみると、「ファイル肥大化」「どう分けるべきかわからない」という課題に直面 ... 😵

Slide 59

Slide 59 text

アプリ改善の取り組み: 宣⾔的UIの導⼊ Androidコミュニティの知⾒が集まるOSSを参考にした ● android/compose-samples ● android/nowinandroid ● DroidKaigi/conference-app-2023

Slide 60

Slide 60 text

アプリ改善の取り組み: 宣⾔的UIの導⼊ https://github.com/android/compose-samples android/compose-samples ○ Jetpack Compose実装のサンプルアプリ群

Slide 61

Slide 61 text

アプリ改善の取り組み: 宣⾔的UIの導⼊ android/nowinandroid ○ KotlinとJetpack Composeのベストプラクティスとして Googleが公開している https://github.com/android/nowinandroid

Slide 62

Slide 62 text

アプリ改善の取り組み: 宣⾔的UIの導⼊ ● DroidKaigi/conference-app-2023 ○ 毎年トレンドの最先端を⾏きがち(近年はKMPで実装) https://github.com/DroidKaigi/conference-app-2023

Slide 63

Slide 63 text

アプリ改善の取り組み: 宣⾔的UIの導⼊ DroidKaigiのリポジトリで、View分割に関するissueが⾒つかった https://github.com/DroidKaigi/conference-app-2023/issues/84

Slide 64

Slide 64 text

アプリ改善の取り組み: 宣⾔的UIの導⼊ issueでは、Viewを3階層で分割するアイデアが議論されていた

Slide 65

Slide 65 text

アプリ改善の取り組み: 宣⾔的UIの導⼊プロダクトでも、DroidKaigiのアイデアをベースに戦略を⽴てた

Slide 66

Slide 66 text

アプリ改善の取り組み: 宣⾔的UIの導⼊詳しくはdipのテックブログで解説しています📖

Slide 67

Slide 67 text

アプリ改善の取り組み: 宣⾔的UIの導⼊ ✅ UIファイルの肥⼤化解消 ✅ 実装タスクの細分化‧分担しやすくなった ✅ PRが⼩さくなりレビューしやすくなった presentation └─ screen/ ├─ component/ │ ├─ HogeComponent │ └─ FugaComponent ├─ section/ │ ├─ HogeSection │ └─ FugaSection └─ XXView

Slide 68

Slide 68 text

アプリ改善の取り組み: 宣⾔的UIの導⼊権威のあるリファレンスに実装を寄せたことが⾃信につながって前向きに楽しくUI実装できるようになった🎉

Slide 69

Slide 69 text

アプリ改善の取り組み〜AIとの協働〜

Slide 70

Slide 70 text

アプリ改善の取り組み: AIとの協働今年から開発でAIツールが使えるようになった🎊

Slide 71

Slide 71 text

アーキテクチャが整ったことで、ソフトウェアの構造を説明可能になっていたアプリ改善の取り組み: AIとの協働

Slide 72

Slide 72 text

アプリ改善の取り組み: AIとの協働 AIのためのルールファイルが書けたおかげか的外れな出⼒は、ほとんど起きなかった 🤖 ナルホド...

Slide 73

Slide 73 text

アプリ改善の取り組み: AIとの協働 Devinを⽤いて「AIがコーディング → PRを⼈が修正」の流れが定着実装がブレにくいData Layerの開発と相性が良い感触

Slide 74

Slide 74 text

アプリ改善の取り組み: AIとの協働 Devinが書いたコード6割、⼈が書いたコード4割ぐらいの割合で安定

Slide 75

Slide 75 text

アプリ改善の取り組み: AIとの協働抽象度の⾼い領域では⼈が主導のコーディングしている CursorやClaude Codeにブーストしてもらっている

Slide 76

Slide 76 text

アプリ改善の取り組み: 振り返りテストを書けなかった頃は...

Slide 77

Slide 77 text

さいごに 😔 単純な対応にも時間がかかる... 新しい技術を全然触れない... 周りから置いてかれている... キャリアが不安...

Slide 78

Slide 78 text

アプリ改善の取り組み: 振り返りレガシーさを解消しつつ、トレンドのAI活⽤に漕ぎ着けた “2025年っぽい開発者体験”を感じられるようになった

Slide 79

Slide 79 text

さいごに ☺ コードが読みやすくて仕事を進めやすいモダンな技術で効率よく開発流⾏についていけるようになったキャリアの不安も軽減

Slide 80

Slide 80 text

Copyright © DIP Corporation, All rights reserved. まとめ 1. リアーキテクト 2. ユニットテストの導⼊ 3. 宣⾔的UIの導⼊ 4. AIとの協働 Google推奨アーキテクチャとfeature駆動パッケージングの実践読み書きに迷う時間が減り、テスタビリティも得られた「とにかく書く」ために意識の低いスタンスを重視結果、期待以上の恩恵を得られた Androidコミュニティの知⾒をベースに分割⽅針を決めたうまくワークし、保守性と開発効率が向上したアプリの構造が説明可能になり、効果的なルールを作れた出⼒の精度が上がり、コーディングの6割ぐらいをAIに任せられた

Slide 81

Slide 81 text

アプリ改善の取り組み: 反省と学び最初はOSのボーダーを意識しすぎていた実際はソフトウェアとして共通の課題も多く、知⾒やテクニックの流⽤も効いた同じように⽇和っている⼈がいたら、⼀歩踏み越えてコラボできるといいかも🐣

Slide 82

Slide 82 text

さいごに

Slide 83

Slide 83 text

「挑戦し、変化し、リードする仲間」を募集中エンジニアリングの⼒でビジネスを成⻑させ、「誰もが働く喜びと幸せを感じられる社会」を共に実現しましょう。 83 📎採用情報 📎インタビュー記事 📎テックブログ

Slide 84

Slide 84 text

QRコードからカジュアル⾯談の案内ページに⾶べます！🚀 「挑戦し、変化し、リードする仲間」を募集中カジュアル⾯談も実施しています！興味がある⽅、ぜひ⼀度お話しましょう🙌 84

Slide 85

Slide 85 text

ご清聴ありがとうございました🙇