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
980
機能横断型チームにおける技術改善
Takeshi Akutsu
May 13, 2022
Tweet
Share
More Decks by Takeshi Akutsu
See All by Takeshi Akutsu
技術的負債へ向き合う ~開発速度をいかに向上させるか~
takeshiakutsu
2
400
1ヶ月半でプッシュ通知許諾率を17%から40%にあげた話
takeshiakutsu
5
11k
Other Decks in Programming
See All in Programming
Quine, Polyglot, 良いコード
qnighy
4
640
CSC509 Lecture 11
javiergs
PRO
0
180
Jakarta EE meets AI
ivargrimstad
0
550
型付き API リクエストを実現するいくつかの手法とその選択 / Typed API Request
euxn23
8
2.2k
Contemporary Test Cases
maaretp
0
140
TypeScript Graph でコードレビューの心理的障壁を乗り越える
ysk8hori
2
1.1k
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
520
Enabling DevOps and Team Topologies Through Architecture: Architecting for Fast Flow
cer
PRO
0
330
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
190
AWS Lambdaから始まった Serverlessの「熱」とキャリアパス / It started with AWS Lambda Serverless “fever” and career path
seike460
PRO
1
260
Compose 1.7のTextFieldはPOBox Plusで日本語変換できない
tomoya0x00
0
190
見せてあげますよ、「本物のLaravel批判」ってやつを。
77web
7
7.7k
Featured
See All Featured
Designing for humans not robots
tammielis
250
25k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Documentation Writing (for coders)
carmenintech
65
4.4k
Bash Introduction
62gerente
608
210k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
880
Speed Design
sergeychernyshev
25
620
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Thoughts on Productivity
jonyablonski
67
4.3k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
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