機能横断型チームにおける技術改善

Transcript

1. 2022/05/13　阿久津岳志 機能横断型チームにおける技術改善 ~タイミーにおける1年間の取り組みを振り返る~ @sky_83325
2. 阿久津岳志 / @sky_83325 株式会社タイミー プロダクト本部 ワーカーチーム iOS Engineer
5. タイミーのチーム体制 技術軸ではなく、バリューストリーム（顧客価値）単位でチームを構成し 開発しています デザイン、API設計、サーバーサイドの開発、フロントの開発、分析など全てのレイヤを1つのチームで解 決できる体制をとっています。
6. チームの実例: マッチング領域 タイミーは以下のような体制でサービス開発をしています。 PdM(PO) デザイナー (トラベラー) スクラムマスター Backend Backend iOS iOS Android Android Analyst LeSS(Large Scale Scrum) Android Android Backend 開発チームA 開発チームB
7. iOSに関することは全てiOSエンジニアが、 Androidに関することは全てAndroidエンジニアが、 サーバーサイドに関することは全てサーバーサイドエンジニ アが担当するという状況でした。 機能横断型でチームを作りつつも
8. それが、最近は
9. アナリストの方が 必要なトラッキングイベントを追加したのでPRレビューお願いします！
10. アナリストの方が 昨日、Aさん（iOSエンジニア）が休みだったので 代わりにリリース申請しときました〜！
11. Androidエンジニアの方が ここ仕様が変わったのでiOS側も変更しておきますね！ PR投げたので確認お願いします！
12. サーバーサイドの方が CSの部署の方から依頼来たので、新しくTestFlightのテスターの登録しときま すね〜！
13. いかにして そのような状況に変化したのかを お話しします。 今日の発表では
14. 目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
15. 目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
16. ツバメの会にて isowordsのSwiftPackageManagerを中心としたプロジェクト構成 面白いですよ 良さそうなのでやってみよう！
17. 外部ライブラリや各種CLIツールの管 理を全てSwiftPMで行うように 環境構築コストの削減
18. 外部ライブラリ/CLIツール 1年前は・・ 外部ライブラリの管理にはCarthage、CocoaPodsを利用し、 CLIツールの管理にはMintを利用していました。 そのため、それらのインストールのためにRubyやBundler、 Homebrewのインストールが必要になっていました。
19. 外部ライブラリ/CLIツール それを全てSwift Package Managerで管理するように Before 外部ライブラリ（RxSwift / Firebase / etc…） →　CocoaPodsやCarthageで管理 CLIツール（SwiftGen / SwiftLint / etc…）→　Mintで管理 After 全てSwift Package Managerで管理するように
20. 社内ライブラリ 社内ライブラリもSwift Packageとして管理 外部ライブラリやCLIツールの管理をSwiftPackageManagerに移行したのに乗じて、 マルチモジュール開発のために作成していた社内ライブラリ（Feature Module）に関して もEmbedded FrameworkではなくSwift Packageとして管理するようにしました。
21. 脱XcodeGen 結果として、XcodeGenを剥がすことにも成功 Embedded Frameworkにおけるファイルの追加/削除は pbxproj ファイルで管理されるが、Swift Package内の変更は管理されません。 基本的な実装は全てSwift Package側で行うことで、pbxprojへの影響を限りなく少なくすることが出来ま す。 結果として、そのコンフリクト解決のために入れていたXcodeGenが不要になりました。
22. 環境構築コストの削減 その結果 ローカルの開発環境がXcodeにのみ依存するようになりました。 ※ ローカル環境でも一部の処理をするためにFastlaneを利用したいケースがあれば Rubyのインストールが必要になります。
23. 指定されたバージョンのXcodeだけ あれば開発可能になりました🎉🎉🎉
24. 環境構築も容易になりました Xcodeのみに依存した結果
25. 環境構築コストの削減 Before After 各種ライブラリやCLIツールの管理をXcodeに統合されているパッケージ管理システムであるSwiftPackageManagerを利用 することでプロジェクトの初期化処理が簡潔になりました。
26. 環境構築コストがゼロになった結果 コミッターが増えました 🎉🎉🎉
27. 環境構築コストの削減 環境構築が容易になったことでコミッターが増加 前職やプライベートでiOSの開発経験があるものの、タイミーでは他の職域で活躍している人が多数いま す。その方々が簡単なUX改善や、アナリティクスイベントの追加などのPRを投げてくれる事例がありまし た。 ※ もちろん、環境構築のコストが下がったことはこれらの1つの要因でしかなく、多くは彼らの努力（挑戦心/好奇心）によってもたらされたものかもしれませんが、 環境構築コストが下がったことによるコミットへの心理的ハードルの減少も少なからずあると思います。
28. アナリストの方が 必要なトラッキングイベントを追加したのでPRレビューお願いします！
29. Androidエンジニアの方が ここ仕様が変わったのでiOS側も変更しておきますね！ PR投げたので確認お願いします！
30. SwiftPMを中心としたプロジェクト構成に移行 タイミーのテックブログにも関連する内容の 記事を書きましたので、 こちらもご覧ください 大規模なマルチモジュール開発をSwiftPackageに 移行して運用してみた
31. 目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
32. たくさんの無駄が 省かれました リリースプロセスの刷新
33. リリースプロセスを刷新 リリース作業をシンプルにするために以下を行いました - developブランチの廃止 - Semantic Versioningからの卒業 - マイルストーンでのリリース履歴管理を辞める
34. リリースプロセスを刷新 Developブランチを廃止 ブランチ戦略をGit-flowからGitHub flowへ変更しました。 理由 1. Releaseブランチを設けているメリットが感じられなかった 2. ブランチが増えると、CI待ちの回数が増え、それを待つのが億劫だった
35. リリースプロセスを刷新 Semantic Versioningからの卒業 日付を元にバージョンを決定するようにしました。（2022年5月13日 → ver22.05.13） 理由 1. SemanticVersioningを利用するメリットが見つからなかった 2. 機械的にバージョンを決定したかった
36. リリースプロセスを刷新 マイルストーンでのリリース履歴管理を辞める 各リリースにどのPRが含まれているかをGitHubのマイルストーンを用いて管理していましたが、GitHub のRelease Noteを自動生成する処理に乗り換えた 理由 1. マイルストーンで担保したかったことを　　　　　　　　　　　　　　　　　　　　　　　全て代替できたから
37. たくさんの無駄を省いた結果、 GitHub Actionsの実行で 完結するようになりました リリースプロセスの刷新
38. アナリストの方が 昨日、Aさん（iOSエンジニア）が休みだったので 代わりにリリース申請しときました〜！
39. 詳細は後日テックブログで リリースプロセスの刷新
40. 目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
41. 定期的に必要な作業はMakefileに 処理をまとめています 各種オペレーションの自動化
42. サーバーサイドの方が CSの部署の方から依頼来たので、新しくTestFlightのテスターの登録しときま すね〜！
43. 目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
44. まとめ iOS開発への参加コストを下げていきたい 他の職能の人がiOS開発へ参加しやすい/参加してみようと思ってもらえる状況を作るために - 環境構築のコストの削減 - リリース作業の自動化 - 各種オペレーションをコマンド化 してきました。
45. まとめ Viewの開発コストを下げるために SwiftUI へ移行中 そして、今現在はよりiOS開発の参入コストを減らすために、SwiftUIへの移行中です - InterfaceBuilder時代 → コードレビューが実質不可 → 自己で研鑽することが多かった 🖥 - SwiftUI → コードレビューが可能 → チームでスキルを向上していける 🙌
46. まとめ iOSエンジニアだけど - AndroidのViewの開発（JetpackCompose）ならわかる - 簡単なAPIの開発なら出来る Railsエンジニアだけど - iOSの運用（テスターの登録 etc..）なら手伝える - 簡単なiOSのバグであれば修正してリリースできる デザイナーだけど - 簡単なレイアウトのずれはiOS/Androidともに直せる
47. もしこの発表を見てタイミーに興味を持った方がいればこちらご覧ください！
48. Thank you