Tweet
Tweet

Slide 1

Slide 1 text

2022/05/13　阿久津岳志 機能横断型チームにおける技術改善 ~タイミーにおける1年間の取り組みを振り返る~ @sky_83325

Slide 2

Slide 2 text

阿久津岳志 / @sky_83325 株式会社タイミー プロダクト本部 ワーカーチーム iOS Engineer

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

タイミーのチーム体制 技術軸ではなく、バリューストリーム（顧客価値）単位でチームを構成し 開発しています デザイン、API設計、サーバーサイドの開発、フロントの開発、分析など全てのレイヤを1つのチームで解 決できる体制をとっています。

Slide 6

Slide 6 text

チームの実例: マッチング領域 タイミーは以下のような体制でサービス開発をしています。 PdM(PO) デザイナー (トラベラー) スクラムマスター Backend Backend iOS iOS Android Android Analyst LeSS(Large Scale Scrum) Android Android Backend 開発チームA 開発チームB

Slide 7

Slide 7 text

iOSに関することは全てiOSエンジニアが、 Androidに関することは全てAndroidエンジニアが、 サーバーサイドに関することは全てサーバーサイドエンジニ アが担当するという状況でした。 機能横断型でチームを作りつつも

Slide 8

Slide 8 text

それが、最近は

Slide 9

Slide 9 text

アナリストの方が 必要なトラッキングイベントを追加したのでPRレビューお願いします！

Slide 10

Slide 10 text

アナリストの方が 昨日、Aさん（iOSエンジニア）が休みだったので 代わりにリリース申請しときました〜！

Slide 11

Slide 11 text

Androidエンジニアの方が ここ仕様が変わったのでiOS側も変更しておきますね！ PR投げたので確認お願いします！

Slide 12

Slide 12 text

サーバーサイドの方が CSの部署の方から依頼来たので、新しくTestFlightのテスターの登録しときま すね〜！

Slide 13

Slide 13 text

いかにして そのような状況に変化したのかを お話しします。 今日の発表では

Slide 14

Slide 14 text

目次 ● 環境構築コストの削減 ● リリースプロセスの刷新 ● 各種オペレーションの自動化 ● まとめ

Slide 15

Slide 15 text

目次 ● 環境構築コストの削減 ● リリースプロセスの刷新 ● 各種オペレーションの自動化 ● まとめ

Slide 16

Slide 16 text

ツバメの会にて isowordsのSwiftPackageManagerを中心としたプロジェクト構成 面白いですよ 良さそうなのでやってみよう！

Slide 17

Slide 17 text

外部ライブラリや各種CLIツールの管 理を全てSwiftPMで行うように 環境構築コストの削減

Slide 18

Slide 18 text

外部ライブラリ/CLIツール 1年前は・・ 外部ライブラリの管理にはCarthage、CocoaPodsを利用し、 CLIツールの管理にはMintを利用していました。 そのため、それらのインストールのためにRubyやBundler、 Homebrewのインストールが必要になっていました。

Slide 19

Slide 19 text

外部ライブラリ/CLIツール それを全てSwift Package Managerで管理するように Before 外部ライブラリ（RxSwift / Firebase / etc…） →　CocoaPodsやCarthageで管理 CLIツール（SwiftGen / SwiftLint / etc…）→　Mintで管理 After 全てSwift Package Managerで管理するように

Slide 20

Slide 20 text

社内ライブラリ 社内ライブラリもSwift Packageとして管理 外部ライブラリやCLIツールの管理をSwiftPackageManagerに移行したのに乗じて、 マルチモジュール開発のために作成していた社内ライブラリ（Feature Module）に関して もEmbedded FrameworkではなくSwift Packageとして管理するようにしました。

Slide 21

Slide 21 text

脱XcodeGen 結果として、XcodeGenを剥がすことにも成功 Embedded Frameworkにおけるファイルの追加/削除は pbxproj ファイルで管理されるが、Swift Package内の変更は管理されません。 基本的な実装は全てSwift Package側で行うことで、pbxprojへの影響を限りなく少なくすることが出来ま す。 結果として、そのコンフリクト解決のために入れていたXcodeGenが不要になりました。

Slide 22

Slide 22 text

環境構築コストの削減 その結果 ローカルの開発環境がXcodeにのみ依存するようになりました。 ※ ローカル環境でも一部の処理をするためにFastlaneを利用したいケースがあれば Rubyのインストールが必要になります。

Slide 23

Slide 23 text

指定されたバージョンのXcodeだけ あれば開発可能になりました🎉🎉🎉

Slide 24

Slide 24 text

環境構築も容易になりました Xcodeのみに依存した結果

Slide 25

Slide 25 text

環境構築コストの削減 Before After 各種ライブラリやCLIツールの管理をXcodeに統合されているパッケージ管理システムであるSwiftPackageManagerを利用 することでプロジェクトの初期化処理が簡潔になりました。

Slide 26

Slide 26 text

環境構築コストがゼロになった結果 コミッターが増えました 🎉🎉🎉

Slide 27

Slide 27 text

環境構築コストの削減 環境構築が容易になったことでコミッターが増加 前職やプライベートでiOSの開発経験があるものの、タイミーでは他の職域で活躍している人が多数いま す。その方々が簡単なUX改善や、アナリティクスイベントの追加などのPRを投げてくれる事例がありまし た。 ※ もちろん、環境構築のコストが下がったことはこれらの1つの要因でしかなく、多くは彼らの努力（挑戦心/好奇心）によってもたらされたものかもしれませんが、 環境構築コストが下がったことによるコミットへの心理的ハードルの減少も少なからずあると思います。

Slide 28

Slide 28 text

アナリストの方が 必要なトラッキングイベントを追加したのでPRレビューお願いします！

Slide 29

Slide 29 text

Androidエンジニアの方が ここ仕様が変わったのでiOS側も変更しておきますね！ PR投げたので確認お願いします！

Slide 30

Slide 30 text

SwiftPMを中心としたプロジェクト構成に移行 タイミーのテックブログにも関連する内容の 記事を書きましたので、 こちらもご覧ください 大規模なマルチモジュール開発をSwiftPackageに 移行して運用してみた

Slide 31

Slide 31 text

目次 ● 環境構築コストの削減 ● リリースプロセスの刷新 ● 各種オペレーションの自動化 ● まとめ

Slide 32

Slide 32 text

たくさんの無駄が 省かれました リリースプロセスの刷新

Slide 33

Slide 33 text

リリースプロセスを刷新 リリース作業をシンプルにするために以下を行いました - developブランチの廃止 - Semantic Versioningからの卒業 - マイルストーンでのリリース履歴管理を辞める

Slide 34

Slide 34 text

リリースプロセスを刷新 Developブランチを廃止 ブランチ戦略をGit-flowからGitHub flowへ変更しました。 理由 1. Releaseブランチを設けているメリットが感じられなかった 2. ブランチが増えると、CI待ちの回数が増え、それを待つのが億劫だった

Slide 35

Slide 35 text

リリースプロセスを刷新 Semantic Versioningからの卒業 日付を元にバージョンを決定するようにしました。（2022年5月13日 → ver22.05.13） 理由 1. SemanticVersioningを利用するメリットが見つからなかった 2. 機械的にバージョンを決定したかった

Slide 36

Slide 36 text

リリースプロセスを刷新 マイルストーンでのリリース履歴管理を辞める 各リリースにどのPRが含まれているかをGitHubのマイルストーンを用いて管理していましたが、GitHub のRelease Noteを自動生成する処理に乗り換えた 理由 1. マイルストーンで担保したかったことを　　　　　　　　　　　　　　　　　　　　　　　全て代替できたから

Slide 37

Slide 37 text

たくさんの無駄を省いた結果、 GitHub Actionsの実行で 完結するようになりました リリースプロセスの刷新

Slide 38

Slide 38 text

アナリストの方が 昨日、Aさん（iOSエンジニア）が休みだったので 代わりにリリース申請しときました〜！

Slide 39

Slide 39 text

詳細は後日テックブログで リリースプロセスの刷新

Slide 40

Slide 40 text

目次 ● 環境構築コストの削減 ● リリースプロセスの刷新 ● 各種オペレーションの自動化 ● まとめ

Slide 41

Slide 41 text

定期的に必要な作業はMakefileに 処理をまとめています 各種オペレーションの自動化

Slide 42

Slide 42 text

サーバーサイドの方が CSの部署の方から依頼来たので、新しくTestFlightのテスターの登録しときま すね〜！

Slide 43

Slide 43 text

目次 ● 環境構築コストの削減 ● リリースプロセスの刷新 ● 各種オペレーションの自動化 ● まとめ

Slide 44

Slide 44 text

まとめ iOS開発への参加コストを下げていきたい 他の職能の人がiOS開発へ参加しやすい/参加してみようと思ってもらえる状況を作るために - 環境構築のコストの削減 - リリース作業の自動化 - 各種オペレーションをコマンド化 してきました。

Slide 45

Slide 45 text

まとめ Viewの開発コストを下げるために SwiftUI へ移行中 そして、今現在はよりiOS開発の参入コストを減らすために、SwiftUIへの移行中です - InterfaceBuilder時代 → コードレビューが実質不可 → 自己で研鑽することが多かった 🖥 - SwiftUI → コードレビューが可能 → チームでスキルを向上していける 🙌

Slide 46

Slide 46 text

まとめ iOSエンジニアだけど - AndroidのViewの開発（JetpackCompose）ならわかる - 簡単なAPIの開発なら出来る Railsエンジニアだけど - iOSの運用（テスターの登録 etc..）なら手伝える - 簡単なiOSのバグであれば修正してリリースできる デザイナーだけど - 簡単なレイアウトのずれはiOS/Androidともに直せる

Slide 47

Slide 47 text

もしこの発表を見てタイミーに興味を持った方がいればこちらご覧ください！

Slide 48

Slide 48 text

Thank you