Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
機能横断型チームにおける技術改善
Search
Takeshi Akutsu
May 13, 2022
Programming
3
850
機能横断型チームにおける技術改善
Takeshi Akutsu
May 13, 2022
Tweet
Share
More Decks by Takeshi Akutsu
See All by Takeshi Akutsu
技術的負債へ向き合う ~開発速度をいかに向上させるか~
takeshiakutsu
2
380
1ヶ月半でプッシュ通知許諾率を17%から40%にあげた話
takeshiakutsu
5
9.7k
Other Decks in Programming
See All in Programming
TypeScript x GraphQLで2年開発してみて
yutank34
8
4.7k
Vue 3.4
kazupon
13
3.6k
Catch Up with Swift 5.10
ojun9
1
450
25 Years of the JCP Program
ivargrimstad
0
1k
phpunit/php-code-coverageって何をしてるんだ #phperkaigi
o0h
PRO
2
190
オープンなデータ・ソフトウェアを活用した開発
404background
0
160
マイクロサービスがほしいと思ったときに本当に必要だったもの〜なぜ人は共通基盤の夢を見るのか〜 / why microservice
77web
5
840
CSRF対策のやり方、そろそろアップデートしませんか / Update your knowledge of CSRF protection
hiro_y
22
12k
品質が高いコードって何?Rev2.1
ickx
1
390
SmartHRにおけるプロダクトエンジニア/product_engineer_in_smarthr_20240227
saitoryc
5
180
Sementic Kernelのネイティブ関数について
tomokusaba
0
790
Some Quick Ideas To Improve Your Tests ( #jassttokyo )
teyamagu
PRO
2
2k
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
240
1.2M
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
24
2.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
67
38k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3k
Documentation Writing (for coders)
carmenintech
59
3.7k
Designing the Hi-DPI Web
ddemaree
275
33k
GitHub's CSS Performance
jonrohan
1023
450k
WebSockets: Embracing the real-time Web
robhawkes
59
6.9k
A Philosophy of Restraint
colly
195
15k
Navigating Team Friction
lara
177
13k
Imperfection Machines: The Place of Print at Facebook
scottboms
257
12k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
219
21k
Transcript
2022/05/13 阿久津岳志 機能横断型チームにおける技術改善 ~タイミーにおける1年間の取り組みを振り返る~ @sky_83325
阿久津岳志 / @sky_83325 株式会社タイミー プロダクト本部 ワーカーチーム iOS Engineer
None
None
タイミーのチーム体制 技術軸ではなく、バリューストリーム(顧客価値)単位でチームを構成し 開発しています デザイン、API設計、サーバーサイドの開発、フロントの開発、分析など全てのレイヤを1つのチームで解 決できる体制をとっています。
チームの実例: マッチング領域 タイミーは以下のような体制でサービス開発をしています。 PdM(PO) デザイナー (トラベラー) スクラムマスター Backend Backend iOS
iOS Android Android Analyst LeSS(Large Scale Scrum) Android Android Backend 開発チームA 開発チームB
iOSに関することは全てiOSエンジニアが、 Androidに関することは全てAndroidエンジニアが、 サーバーサイドに関することは全てサーバーサイドエンジニ アが担当するという状況でした。 機能横断型でチームを作りつつも
それが、最近は
アナリストの方が 必要なトラッキングイベントを追加したのでPRレビューお願いします!
アナリストの方が 昨日、Aさん(iOSエンジニア)が休みだったので 代わりにリリース申請しときました〜!
Androidエンジニアの方が ここ仕様が変わったのでiOS側も変更しておきますね! PR投げたので確認お願いします!
サーバーサイドの方が CSの部署の方から依頼来たので、新しくTestFlightのテスターの登録しときま すね〜!
いかにして そのような状況に変化したのかを お話しします。 今日の発表では
目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
ツバメの会にて isowordsのSwiftPackageManagerを中心としたプロジェクト構成 面白いですよ 良さそうなのでやってみよう!
外部ライブラリや各種CLIツールの管 理を全てSwiftPMで行うように 環境構築コストの削減
外部ライブラリ/CLIツール 1年前は・・ 外部ライブラリの管理にはCarthage、CocoaPodsを利用し、 CLIツールの管理にはMintを利用していました。 そのため、それらのインストールのためにRubyやBundler、 Homebrewのインストールが必要になっていました。
外部ライブラリ/CLIツール それを全てSwift Package Managerで管理するように Before 外部ライブラリ(RxSwift / Firebase / etc…)
→ CocoaPodsやCarthageで管理 CLIツール(SwiftGen / SwiftLint / etc…)→ Mintで管理 After 全てSwift Package Managerで管理するように
社内ライブラリ 社内ライブラリもSwift Packageとして管理 外部ライブラリやCLIツールの管理をSwiftPackageManagerに移行したのに乗じて、 マルチモジュール開発のために作成していた社内ライブラリ(Feature Module)に関して もEmbedded FrameworkではなくSwift Packageとして管理するようにしました。
脱XcodeGen 結果として、XcodeGenを剥がすことにも成功 Embedded Frameworkにおけるファイルの追加/削除は pbxproj ファイルで管理されるが、Swift Package内の変更は管理されません。 基本的な実装は全てSwift Package側で行うことで、pbxprojへの影響を限りなく少なくすることが出来ま す。
結果として、そのコンフリクト解決のために入れていたXcodeGenが不要になりました。
環境構築コストの削減 その結果 ローカルの開発環境がXcodeにのみ依存するようになりました。 ※ ローカル環境でも一部の処理をするためにFastlaneを利用したいケースがあれば Rubyのインストールが必要になります。
指定されたバージョンのXcodeだけ あれば開発可能になりました🎉🎉🎉
環境構築も容易になりました Xcodeのみに依存した結果
環境構築コストの削減 Before After 各種ライブラリやCLIツールの管理をXcodeに統合されているパッケージ管理システムであるSwiftPackageManagerを利用 することでプロジェクトの初期化処理が簡潔になりました。
環境構築コストがゼロになった結果 コミッターが増えました 🎉🎉🎉
環境構築コストの削減 環境構築が容易になったことでコミッターが増加 前職やプライベートでiOSの開発経験があるものの、タイミーでは他の職域で活躍している人が多数いま す。その方々が簡単なUX改善や、アナリティクスイベントの追加などのPRを投げてくれる事例がありまし た。 ※ もちろん、環境構築のコストが下がったことはこれらの1つの要因でしかなく、多くは彼らの努力(挑戦心/好奇心)によってもたらされたものかもしれませんが、 環境構築コストが下がったことによるコミットへの心理的ハードルの減少も少なからずあると思います。
アナリストの方が 必要なトラッキングイベントを追加したのでPRレビューお願いします!
Androidエンジニアの方が ここ仕様が変わったのでiOS側も変更しておきますね! PR投げたので確認お願いします!
SwiftPMを中心としたプロジェクト構成に移行 タイミーのテックブログにも関連する内容の 記事を書きましたので、 こちらもご覧ください 大規模なマルチモジュール開発をSwiftPackageに 移行して運用してみた
目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
たくさんの無駄が 省かれました リリースプロセスの刷新
リリースプロセスを刷新 リリース作業をシンプルにするために以下を行いました - developブランチの廃止 - Semantic Versioningからの卒業 - マイルストーンでのリリース履歴管理を辞める
リリースプロセスを刷新 Developブランチを廃止 ブランチ戦略をGit-flowからGitHub flowへ変更しました。 理由 1. Releaseブランチを設けているメリットが感じられなかった 2. ブランチが増えると、CI待ちの回数が増え、それを待つのが億劫だった
リリースプロセスを刷新 Semantic Versioningからの卒業 日付を元にバージョンを決定するようにしました。(2022年5月13日 → ver22.05.13) 理由 1. SemanticVersioningを利用するメリットが見つからなかった 2.
機械的にバージョンを決定したかった
リリースプロセスを刷新 マイルストーンでのリリース履歴管理を辞める 各リリースにどのPRが含まれているかをGitHubのマイルストーンを用いて管理していましたが、GitHub のRelease Noteを自動生成する処理に乗り換えた 理由 1. マイルストーンで担保したかったことを 全て代替できたから
たくさんの無駄を省いた結果、 GitHub Actionsの実行で 完結するようになりました リリースプロセスの刷新
アナリストの方が 昨日、Aさん(iOSエンジニア)が休みだったので 代わりにリリース申請しときました〜!
詳細は後日テックブログで リリースプロセスの刷新
目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
定期的に必要な作業はMakefileに 処理をまとめています 各種オペレーションの自動化
サーバーサイドの方が CSの部署の方から依頼来たので、新しくTestFlightのテスターの登録しときま すね〜!
目次 • 環境構築コストの削減 • リリースプロセスの刷新 • 各種オペレーションの自動化 • まとめ
まとめ iOS開発への参加コストを下げていきたい 他の職能の人がiOS開発へ参加しやすい/参加してみようと思ってもらえる状況を作るために - 環境構築のコストの削減 - リリース作業の自動化 - 各種オペレーションをコマンド化 してきました。
まとめ Viewの開発コストを下げるために SwiftUI へ移行中 そして、今現在はよりiOS開発の参入コストを減らすために、SwiftUIへの移行中です - InterfaceBuilder時代 → コードレビューが実質不可 →
自己で研鑽することが多かった 🖥 - SwiftUI → コードレビューが可能 → チームでスキルを向上していける 🙌
まとめ iOSエンジニアだけど - AndroidのViewの開発(JetpackCompose)ならわかる - 簡単なAPIの開発なら出来る Railsエンジニアだけど - iOSの運用(テスターの登録 etc..)なら手伝える
- 簡単なiOSのバグであれば修正してリリースできる デザイナーだけど - 簡単なレイアウトのずれはiOS/Androidともに直せる
もしこの発表を見てタイミーに興味を持った方がいればこちらご覧ください!
Thank you