Flutterからネイティブへの挑戦と学び -評価1.6から4.0への道のり-

■ イベント
2025年9月10日-12日開催
DroidKaigi 2025
https://2025.droidkaigi.jp/
■ セッション情報
2025年9月12日登壇
https://2025.droidkaigi.jp/timetable/930808/
■ 発表者
chocoZAP Androidエンジニア
北村 涼・藤井 賢太郎

Transcript

2. 自己紹介 Self-introduction 2
5. chocoZAPの紹介 Introducing chocoZAP 5
6. 6 Introducing chocoZAP
7. 7 Introducing chocoZAP コンビニジム Convenience Gym
8. Introducing chocoZAP 8
9. 9 Introducing chocoZAP
10. 目次 Agenda 10
11. Agenda 1. Flutter版アプリ開発 Developing chocoZAP app in Flutter 2. ネイティブアプリ化 Converting to a native app 11
12. Agenda 3. 不具合の原因と分析 Analyzing the causes of bugs 4. 品質改善 Improving quality 12
13. Agenda 5. 事例紹介 Introducing a case study on quality improvement 6. 改善の確認 Confirming the outcomes of the improvements 13
14. Agenda 7. まとめ Summarizing 14
15. 1. Flutter版アプリ開発 Developing chocoZAP app in Flutter 15
16. 16 Developing chocoZAP app in Flutter 最初はFlutterアプリとしてリリース chocoZAP app was initially released as a Flutter app
17. 17 Developing chocoZAP app in Flutter 企画開始が2021年11月 Planning began in November 2021.
18. 18 Developing chocoZAP app in Flutter リリース目標は2022年3月末 The release target was the end of March 2022.
19. 19 Developing chocoZAP app in Flutter 社内は開発1名、QA1名 The project team consisted of one software developer and one QA engineer from our company.
20. 20 Developing chocoZAP app in Flutter 外部の会社に開発を委託した We Outsourced development to an external company.
21. 21 Developing chocoZAP app in Flutter 低コストでスピード感のある開発を求 めてFlutterを採用 We adopted Flutter to achieve: - low development costs - faster development speed
22. 22 Developing chocoZAP app in Flutter 開発が完了し、リリースされた We completed the development and released the app.
23. 23 Developing chocoZAP app in Flutter 評価は4.2だった We got a rating of 4.2 (out of 5)
24. 2. ネイティブアプリ化 Converting to a native app 24
25. 25 Converting to a native app アプリ開発の内製化を行うプロジェク トが発足してネイティブアプリへ We launched a project to insource the development and convert the app into a native app.
26. Converting to a native app 3つの思いがあった We had three main aims. 26
27. 27 Converting to a native app - solving a problem with WebView - improving implementation efficiency using the SDK - improving recruitment efficiency for application engineers
28. 28 Converting to a native app WebViewが意図通りに動かない The WebView did not behave as intended.
29. Converting to a native app ネイティブのWebViewであれば解決で きるのではという期待があった We aimed to solve the WebView problem by switching to a native app. 29
30. 30 Converting to a native app SDKを利用する処理はネイティブコー ドが必要 Operations involving the SDK require native code.
31. 31 Converting to a native app ネイティブコードを書く必要があるな ら、ネイティブに寄せたい If we need to write native code, we should move to a native implementation.
32. 32 Converting to a native app
33. 33 Converting to a native app Flutterとネイティブができるエンジニ アを見つけるのが困難だった It was hard to find engineers who have skills in both Flutter and native development.
34. Converting to a native app ネイティブコードが書けるエンジニア は見つかるはず It would be easier to find engineers with expertise in native code. 34
35. Converting to a native app 開発が完了し、リリースされた We completed the development and released the app. 35
36. Converting to a native app 不具合が多発し、ストア評価が1.6まで 下がる Numerous bugs occurred and brought the rating down to 1.6. 36
37. Converting to a native app 不具合修正に追われるとサービス価値 向上に時間を割けなくなる Engineers were swamped with bug fixes and could not spare time for service improvements. 37
38. Converting to a native app なんとしても品質を向上させなければ ならない We absolutely must fix the bugs!. 38
39. 3. 不具合の原因と分析 Analyzing the causes of bugs 39
40. 3-1 発生していた問題と原因 Problems and their causes 40
41. Problems and their causes 表示不具合の問題 Bugs in Display Rendering 41
42. Problems and their causes フォントサイズを変更すると表示が崩 れる Changing the font size broke the layout. 42
43. Problems and their causes → Figmaのサイズを固定値として実装 していた → We set the Figma size as a fixed value. 43
44. Problems and their causes 画面を横向きにするとUIが崩れる The UI broke in landscape layout. 44
45. Problems and their causes →デザインや実装の時に画面横向きの 考慮が漏れていた → We did not design and implement support for landscape layout. 45
46. Problems and their causes エラー時にエラーと気付けない表示に なる We did not implement the error message display. 46
47. Problems and their causes →異常系の実装が後回しにされたまま だった → Implementation of the abnormal scenario was incomplete. 47
48. Problems and their causes クラッシュする問題 crash issue. 48
49. Problems and their causes →APIレスポンスで落ちてくる値が期待 通りではない時がある →Sometimes, the return values of the API response were inconsistent with the specification. 49
50. Problems and their causes →エラーハンドリングが不足していた →Implementation of error handling was incomplete. 50
51. Problems and their causes 画面の表示動作が遅い Display performance was slow. 51
52. Problems and their causes →Recompositionの考慮が不足してい た →The recomposition design was insufficient. 52
53. Problems and their causes →余計な処理があった →The process included redundant steps. 53
54. 3-2 根本原因を考える Considering the Root Causes 54
55. Considering the Root Causes 傾向でまとめる Summarizing the trends. 55
56. Considering the Root Causes デザインや実装の時に画面横向きの考 慮が漏れていた We did not design and implement support for landscape layout. 56
57. Considering the Root Causes 異常系表示の実装がなかった Implementation of the abnormal scenario was incomplete. 57
58. Considering the Root Causes FlutterアプリのUIを再現することに 注力していた We focused only on reproducing the UI. 58
59. Considering the Root Causes つまり in other words 59
60. Considering the Root Causes あるべきUI/UXを意識してデザインや 仕様を調整できていなかった We did not design the UI/UX specifications suited to Android. 60
61. Considering the Root Causes APIレスポンスで落ちてくる値が期待通 りではない時がある Sometimes, the return values of the API response were inconsistent with the specification. 61
62. Considering the Root Causes つまり in other words 62
63. Considering the Root Causes API作りをアプリエンジニアが一緒に行 えていなかった Backend and application engineers did not collaborate on the API design. 63
64. Considering the Root Causes Figmaのサイズを固定値として実装し ていた We set the Figma size as a fixed value. 64
65. Considering the Root Causes エラーハンドリングが不足していた Implementation of error handling was incomplete. 65
66. Considering the Root Causes Recompositionの考慮が不足していた The recomposition design was insufficient. 66
67. Considering the Root Causes 余計な処理があった The process included redundant steps. 67
68. Considering the Root Causes 情報の共有ができておらずレビュー難 易度が高くなっていた We lacked the sharing of specifications, which made it difficult to review. 68
69. Considering the Root Causes つまり in other words 69
70. Considering the Root Causes チームビルディングがうまくできてお らず、情報が共有されるチームとなっ ていなかった Failed team building led to poor information sharing . 70
71. Considering the Root Causes 原因を整理する Organizing the causes. 71
72. Considering the Root Causes 1. あるべきUI/UXを意識してデザインや仕様を 調整できていなかった 2. API作りをアプリエンジニアが一緒に行えていなかった 3. チームビルディングがうまくいっておらず、 情報が共有されるチームとなっていなかった 1. We did not design the UI/UX specifications suited to Android. 2. Backend and application engineers did not collaborate on the API design. 3. Failed team building led to poor information sharing. 72
73. Considering the Root Causes 開発の進め方に問題があった チームビルディングに問題があった There were problems in the development process. There were problems in team building. 73
74. 4. 品質改善 Improving quality 74
75. Improving quality 大きく2つの問題が見えてきた Two major issues were revealed. 75
76. Improving quality - 開発の進め方に問題があった - チームビルディングに問題があった - There were problems in the development process. - There were problems in team building. 76
77. Improving quality できていなかったことをできるように していく We began addressing the issues. 77
78. 4-1 開発の進め方の改善 Improving the development process 78
79. Improving the development process あるべきUI/UXを意識してデザインや 仕様を調整する We should design UI/UX specifications to suit Android. 79
80. Improving the development process Material 3コンポーネントを活用する We adopted Material 3 Components. 80
81. Improving the development process ユーザビリティが高い / high UI/UX usability. 作るのが早い / faster development. 保守性が高い / greater maintainability. 81
82. Improving the development process Figmaで扱い易いUIを作りやすくなっ た By using Figma, engineers were able to develop UIs more easily. 82
83. Improving the development process コストの高い独自UIは十分に議論する Adopting the original UI requires high development costs, so we thoroughly discussed it. 83
84. Improving the development process 開発生産性と品質を 両立しやすくなった Using Material3 Components improved both development productivity and quality. 84
85. 4-2 チームビルディングの改善 Improving team building 85
86. 4-2-1 API作りを一緒に行う Creating API with server-side engineers 86
87. Creating API with server-side engineers サーバサイドエンジニアへの働きかけ Mobile engineers approached server-side engineers to collaborate on API creation. 87
88. Creating API with server-side engineers 全員でドキュメントを作成して レビューできるようにする All members participated in creating and reviewing documents for the API design. 88
89. Creating API with server-side engineers ドキュメントを分割して見通しをよく する We divided the documents to improve interpretability. 89
90. Creating API with server-side engineers ドキュメントをSSOTにする We treated the documents as SSOT (Single Source of Truth). 90
91. Creating API with server-side engineers API起因の不具合発生を抑制できた We were able to suppress API- related bugs. 91
92. 4-2-2 こまめな情報共有 Sharing information actively 92
93. 93 Sharing information actively フィードバックループを作っていった We created feedback loops.
94. 94 Sharing information actively タスクが人に閉じていた We did not fully grasp each other’s tasks.
95. 95 Sharing information actively チームを活かしたタスクの進め方に なっていない We did not fully utilize the team’s synergy.
96. 96 Sharing information actively どうすれば良いチームができるのか？ How can we build a good team?
97. 97 Sharing information actively Software Engineering at Google: Lessons Learned from Programming Over Time
98. 98 Sharing information actively フィードバックループ Feedback loop
99. Sharing information actively 99
100. 100 Sharing information actively フィードバックループをたくさん作る We attempted to create many feedback loops.
101. 101 Sharing information actively Slack でタスクについて話すチャンネ ルを用意 We created a Slack channel to discuss tasks.
102. 102 Sharing information actively うまくいかない作業をアウトプットする We attempted to share information about stuck tasks.
103. 103 Sharing information actively 作業の途中経過もアウトプットする We attempted to share information about unfinished tasks.
104. 104 Sharing information actively 心理的安全性を高める取り組み We attempted to enhance psychological safety.
105. 105 Sharing information actively オフィスアワーの開催 We set up communication sessions.
106. 106 Sharing information actively 積極的なペア作業を行った We actively encouraged pair work.
107. 107 Sharing information actively 正しいコードレビューができるように なった We achieved healthy code reviews that promoted active discissions.
108. 108 Sharing information actively コードレビューに期待する機能を発揮 できるように Code reviews became more effective.
109. 109 Sharing information actively 不具合をなくす / 良いコードを生み出 す / ナレッジの共有 debugging / efficient coding /knowledge sharing
110. 110 Sharing information actively ともにコードを作る意識を持てた We developed a sense of how to code collaboratively.
111. 111 Sharing information actively メンバー間の相談が増え、 問題を未然に防げるようになった Better communication might have helped prevent problems.
112. 5. 事例紹介 Introducing a case study on quality improvement 112
113. Introducing a case study on quality improvement 113
114. Introducing a case study on quality improvement 114
115. 115 Introducing a case study on quality improvement あるべきUI/UXを意識してデザインや 仕様を調整したこと We designed UI/UX specifications to suit Android.
116. 116 Introducing a case study on quality improvement 独自カスタマイズを最小限にする We minimized customization.
117. Introducing a case study on quality improvement 117
118. 118 Introducing a case study on quality improvement 不具合の起きづらい堅牢なUIへ We successfully developed a robust UI with fewer bugs.
119. 119 Introducing a case study on quality improvement API作りを一緒に行ったこと Backend and application engineers collaborated on API design.
120. 120 Introducing a case study on quality improvement 既存APIを使う方針ではなく新設へ We changed our policy to create new APIs instead of using existing ones.
121. 121 Introducing a case study on quality improvement 地図矩形内の分だけ取得 するAPIを新設 We developed a new API to retrieve map information only within the selected area.
122. 122 Introducing a case study on quality improvement 地域毎に店舗数を返すAPIを 新設し、ズームアウト用に利用 We also developed a new API to return the number of gym locations per region for zoom out.
123. 123 Introducing a case study on quality improvement パフォーマンスの良いUXへ We were able to provide a drastically better UX.
124. 124 Introducing a case study on quality improvement こまめな情報共有を行ったこと We actively shared information.
125. 125 Introducing a case study on quality improvement 都度フィードバックを得る振る舞い We had more discussion to get more feedback.
126. 126 Introducing a case study on quality improvement デザインについて呟いたらデザイナが 拾ってくれる For example, an engineer posted about a UI design on a Slack channel, and a designer responded.
127. 127 Introducing a case study on quality improvement 相談の中での気づきから実装ミスを防 げた Active discussions have helped prevent implementation errors.
128. 6. 改善の確認 Confirming the outcomes of the improvements 128
129. Confirming the outcomes of the improvements 改善したことをお客様に評価していた だく We must evaluate the improvements based on customer opinions. 129
130. Confirming the outcomes of the improvements 開発部門がストアレビューを直接確認 し、返信していく運用体制を作った We established an operational system in which the development department directly checks reviews and responds. 130
131. Confirming the outcomes of the improvements アプリ内レビューを組み込んだ We incorporated In-App Review. 131
132. Confirming the outcomes of the improvements Android Developersのガイドラインを 参考に発火箇所を設計した I designed the trigger points with reference to the Android Developers Guidelines. 132
133. Confirming the outcomes of the improvements サービスを十分体験してから、アプリ 内レビューのフローを開始する We offer the In-App Review only to customers who actually visited a location. 133
134. Confirming the outcomes of the improvements 品質を高めた成果が現れる We were seeing the results of the improvements. 134
135. 135 Confirming the outcomes of the improvements 4.0 .
136. 7. まとめ Summarizing 136
137. Summarizing 評価が下がってしまった We received a low rating of 1.6. 137
138. Summarizing 原因を分析した We analyzed the causes. 138
139. Summarizing - あるべきUI/UXを意識してデザインや仕様を調整できてい なかった - API作りをアプリエンジニアも一緒に行えていなかった - こまめに情報を共有するチームとなっていなかった - We did not design the UI/UX specifications suited to Android. - Backend and application engineers did not collaborate on the API design. - Failed team building led to poor information sharing. 139
140. Summarizing - 開発の進め方に問題あり - チームビルディングに問題あり - There were problems in the development process. - There were problems in team building. 140
141. Summarizing 改善すべきことが見えてきた We gradually recognized the problems to be solved. 141
142. Summarizing - あるべきUI/UXを意識してデザインや仕様を調整する - API作りをアプリエンジニアも一緒に行う - こまめに情報を共有するチームを作った - We should design UI/UX specifications to suit Android. - Backend and application engineers collaborated on API design - We built a team that actively communicates with each other. 142
143. Summarizing 不具合の発生を抑制し、品質を向上す ることに成功した We successfully reduced bugs and improved the quality. 143
144. ご清聴ありがとうございました！ 144
145. References Software Engineering at Google : https://www.oreilly.com/library/view/software-engineering- at/9781492082781/ 伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書 https://www.shoeisha.co.jp/book/detail/9784798186009 Google Play In-App Review API : https://developer.android.com/guide/playcore/in-app- review?hl=ja#when-to-request 145