スクラム開発におけるアプリチームの取り組み / RettyBeerBash#5

by Retty

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

2 あなたにBESTなお店が見つかる

Slide 3

Slide 3 text

エンジニアリング部門マネージャー好物：焼肉趣味：ゲーム、映画鑑賞経歴：2011年　GMOメディア（3年）　　　　　 2014年　エン・ジャパン（2年）　　　2016年　Retty株式会社 3 アプリ開発、Web開発チームのマネージャーです。アプリならではの価値提供ができるプロダクトづくりと、そのプロダクトを自らの力で向上し続けるチームづくりを考え、悩み、実行する日々を過ごしています。 https://user.retty.me/1070337/

Slide 4

Slide 4 text

営業/採用/サーバーサイド/グロースハックなど色々Rettyでやりました。現在は中長期を見据えたプロダクト全体の体験設計を担当しています！利便性だけでなく感情的に愛してもらえるようなプロダクトを作っていきたい人です。人生のミッションは「小さな幸せの認識回数を増やすこと」です。よろしくお願いしますー！プロダクト部門マネージャー兼 PM 趣味：漫画（毎月3万くらい課金してる...）経歴：2012年　家庭教師斡旋会社立ち上げ　　　2015年　インターンでRettyに入社　　　2017年　Rettyに正社員として入社 4 https://user.retty.me/1289557/

Slide 5

Slide 5 text

アプリチームリードエンジニア兼SM 趣味：鉄道・面白自販機巡り・GoogleMaps 経歴：2017年マッチングサービス (2.5年) 　　　2019年 Retty Inc.（2年） 5 ユーザーの気持ちになれる、自分も使いたくなるようなサービスを作りたかったので2019年にJOIN。 Rettyのはらみ(アプリ)チームで開発やチーム運用、採用などを幅広く担当、得意分野はiOS/Swift。最近はSlack Workflowでのコミュニケーション効率化にハマっている。 https://user.retty.me/1010703/ 好きなジャンル郷土料理・ご当地グルメ

Slide 6

Slide 6 text

アプリ開発チーム Android/iOS/サーバーサイドエンジニア趣味：ガジェット経歴：2016年一般社団法人ミライの住宅 2018年 Retty入社 6 食べる事が好きで、ユーザーさんに広く価値を届けられるプロダクト作りに関わりたい、という思いで2018年にRetty に入社。iOS/Androidネイティブアプリ開発に加え、必要に応じてサーバーサイドも色々と担うなんでも屋として活動してます。golangや、業務では使ってませんがFlutterが好きです。 https://user.retty.me/3374690/

Slide 7

Slide 7 text

7 21卒で入社後、半年間Web開発チームで修行をしていました。今月からアプリチーム所属となり、絶賛オンボーディングされ中です󰝊 アプリ開発チーム iOSメイン趣味：コーヒー / 料理 / ベース経歴：今年新卒入社 https://user.retty.me/3948610/ Miki Takahashi

Slide 8

Slide 8 text

8 アンケートのご協力をお願いします！

Slide 9

Slide 9 text

9 スクラム開発におけるアプリチームの取り組み

Slide 10

Slide 10 text

Vision 10 食を通じて世界中の人々を Happyに。世界に誇る日本の文化であり、世界中の人々の暮らしの中心でもある、「食」という分野で、お店を探す人とお店の人の双方がHappyになれる、そんな世界を実現したい。その為に、お店をオススメするというポジティブな感情で人をつなぐ事が Rettyの目標です。

Slide 11

Slide 11 text

サービス開始から現在まで急成長 11

Slide 12

Slide 12 text

ユーザーさんにとってのRetty 12 実名型点数評価のないおすすめの口コミ「ヒト」から探す信頼できるヒトから、自分にあったお店を見つけることができる実名型グルメプラットフォーム

Slide 13

Slide 13 text

13 飲食店さんにとってのRetty 新規集客ストックアクセスアップ来店顧客管理リピート集客お店の”ファン”と出会い、長期的に繋がれる将来の常連さんを作る集客のインフラ

Slide 14

Slide 14 text

14 アプリ開発チームの紹介

Slide 15

Slide 15 text

アプリ開発チーム通称「ハラミ」アプリ開発チームの体制  開発メンバー5名内定インターン2名マネージャー Retty(国内) Retty Global Retty Order EM SM アプリ・バックエンド開発アプリ・バックエンドレビューアプリ開発イラスト：Loose Drawing

Slide 16

Slide 16 text

アプリ開発チームで利用しているもの  iOS Android Kotlin Swift SwiftUI Jetpack Compose Github CircleCI Bitrise Firebase AWS Slack Discord Miro Figma Confluence

Slide 17

Slide 17 text

4. さよならReact Native  スクラム開発におけるアプリチームの取り組み  17 2. Appチームアジャイル開発運営の工夫  1. Appの施策立案からリリースまでの流れ  3. フルリモート下での働き方  7. 開発効率をあげる自動化の取り組み（CI/CD）  5. こんにちはSwiftUI  6. ユーザーの声/社内意見の吸い上げと施策への反映事例 

Slide 18

Slide 18 text

1. Appの施策立案から　リリースまでの流れ 18

Slide 19

Slide 19 text

Appの施策立案からリリースまでの流れ      解決方法を模索する   実装する  解決方法を具体化する   1 課題を特定する  検証・リリースする  2 3 4 5 　定量分析　  　定性分析　  　チケット(issue)の起票　  職種/部門を超えたコミュニケーション  リファインメント  施策の事前検証  PBIの優先度判断  タスク分解・実装対応  QA  申請  リリース  検証項目の準備  デザイン 

Slide 20

Slide 20 text

2. Appチームが行っているアジャイルな開発・運用の工夫 20

Slide 21

Slide 21 text

[ポイント] ● やるべきことを明確化 ● 柔軟な優先度・手段の変更 ● 毎日/毎週コミニュケーション ● チームでのタスク進行アジャイルな開発・運用の工夫 

Slide 22

Slide 22 text

差し込みや優先タスクもバックログへ  緊急性が高い/差し込みで対応したタスクも可視化 & バックログ化バックログ化していないものも日報に記載して毎日報告 App: 差し込みのタスクがあるのでスプリントゴール達成怪しいです ! PO: では来週やる施策のリリース期限伸ばしましょう ! 変化があってもすぐに周知して対応計画を柔軟に変更

Slide 23

Slide 23 text

やるべきことを明確化  スプリントバックログ (miro) プロダクトのやるべきこと粒度大 & 抽象度高毎日のコミュニケーション ● デイリースクラム ● スプリントレビュー ● プランナーとの連絡会アプリのやるべきこと粒度小 & 抽象度低プロダクトバックログ (Spreadsheet) 図式化 (miro)

Slide 24

Slide 24 text

柔軟な優先度・手段の変更  - 必要ならばWebチームと協調して開発 - Webとの機能差を減らす・リリースタイミングを事前に計画 - 場合によってはWebViewでの実装も検討する - ストーリーを小さく分割する - 「UI変更して新バッジを追加」は「UI変更」「新バッジを追加」に分割 → 途中で優先度を変更🉑 - iOSとAndroidは揃える必要があるか、ないなら分ける https://engineer.retty.me/entry/2020/12/12/090000 より小さく・高頻度でリリース優先度変更や複数手段を検討する

Slide 25

Slide 25 text

毎日/毎週コミニュケーション  - 毎日 - デイリースクラム (15分) - チーム内での相談時間 (60分) - リファインメント (15分) - ペアプロ/実装相談 (any time) - ドキュメンテーション (any time) - 毎週 - レトロスペクティブ (30分) - POとのよもやま会 (30分) - チーム横断の振り返り共有会 (30分) https://engineer.retty.me/entry/2020/12/12/090000 より

Slide 26

Slide 26 text

チームでのタスク進行  - チームメンションの推奨 - 相談や依頼には基本的に @harami を推奨 - 「誰かがいなければ開発できない」状態を極力避けるようにしている - 属人性の回避 - スクラムイベント担当は持ち回り制 - ドキュメンテーションやペアプロを推奨 - 情報の公開と更新 - Spreadsheet/miroのバックログは最新にする(SMタスク) - Rettyのルール「率直に言い合う」

Slide 27

Slide 27 text

[ポイント] ● やるべきことを明確化 ○ バックログとスプリントが指針 ○ 今やるべきことを明確化 ● 柔軟な優先度・手段の変更 ○ Webなどの他手段でも実装を検討する ○ 小さなリリースで柔軟に優先度を変更 ● 毎日/毎週コミニュケーション ○ チーム内外との情報交換を欠かさない ○ 悪い状態を見過ごさない ● チームでのタスク進行 ○ 属人性の低いチーム開発 ○ チームメンションなどの仕組みを利用まとめ 

Slide 28

Slide 28 text

3.フルリモート下での働き方 28

Slide 29

Slide 29 text

オンラインコミュニケーション  最近のRettyの出社状況についてオンラインコミュニケーションについて ● Slackの使われ方 ● スプリントに関することはmiroで管理 ● オンラインでのスクラムイベントなど ● ディスコードやハドルの活用

Slide 30

Slide 30 text

Slackの使われ方①  スクラム開発・スプリントに関するメインチャンネル ● スクラムイベント・複数チームに関わる出来事の共有 ○ 施策に関する相談事・調整など ● チームチャンネル ○ チーム内の開発に関することは基本的にここに集約 ○ やっていること・悩んでいることの宣言 ● その他ワークフローごと専用のチャンネル ○ PRレビュー・QA依頼・リリースbot Slackワークフローを用いた依頼などの仕組み化 ● 属人化による「知らなかった・いつの間に」をなくす

Slide 31

Slide 31 text

Slackの使われ方②  その他よく使うチャンネル ● #QualityReport ○ Web・アプリなど、不具合・仕様への疑問を共有するチャンネル ○ クリティカルなものでなければ、バックログに積む依頼をするワークフローへ ● 個人チャンネル ○ チーム関わらず、いろんな人が反応してくれて嬉しいほとんどのチャンネルは、スクラム開発に関するものなので、コロナ前から存在していた。 → discordの活用などがコロナ禍に始まったこと。

Slide 32

Slide 32 text

スプリントに関することはmiroで管理  ● 朝会は基本的にmiroを見て進めて行く ○ スプリントバックログ ■ 中期的なストーリーは、全体に対するサブタスクの分解意図がわかるように ○ スプリントゴールと達成具合が目につきやすいようにするチームの改善系 ● 前振り返りからのネクストアクション ● 短期的に話題に上げたいことを書いておく場所 ● 中長期的に、チームメンバーが把握して欲しいことを残して置く場所けすところけす→

Slide 33

Slide 33 text

スプリントイベントやチームMTG  ● 朝会：15分 ● リファインメント：毎日15分ある ○ 相談場所としても大歓迎 ○ エンジニアが持ち帰るなどもOK ● 夕会：毎日最大1時間 ○ トピックがあれば議論する。 ○ 雑談しながら作業したり。 ○ 実装優先でスキップも󰢏 ※タスクの相談などは、夕会などではなく都度話す ● 週次のスクラムイベント：木曜日 ● 振り返り共有会 ○ LeSS特有のイベント ○ 各チームの振り返り内容をエスカレーションする場所

Slide 34

Slide 34 text

Discordの活用  夕会のなんでも相談時間 ● 何かあれば、基本いつでも使う夕会のなんでも相談時間 ● 気になること・詰まったことがあればDiscordで画面共有して話したり ● ペアプロやモブプロの形式で開発して認識共有をしたり ● 夕会で一気にレビューしてしまうとかも（モブレビュー）

Slide 35

Slide 35 text

4.さよならReact Native 35

Slide 36

Slide 36 text

4.さよならReact Native  2017年末ごろ ● Appleの審査に１〜２週間かかり,PDCAを回すのが困難 ● 審査をこまめに出すとAppleからの怒られが発生する（らしい)

Slide 37

Slide 37 text

4.さよならReact Native  2017年末ごろ ● Appleの審査に１〜２週間かかり,PDCAを回すのが困難 ● 審査をこまめに出すとAppleからの怒られが発生する（らしい) Appleの審査による問題が発生！！！

Slide 38

Slide 38 text

4.さよならReact Native  2017年末ごろ ● Appleの審査に１〜２週間かかり,PDCAを回すのが困難 ● 審査をこまめに出すとAppleからの怒られが発生する（らしい) Appleの審査による問題が発生！！！そうだ！OTAを導入して解決しよう！

Slide 39

Slide 39 text

4.さよならReact Native  🤔

Slide 40

Slide 40 text

4.さよならReact Native  そうだ、OTAしよう

Slide 41

Slide 41 text

4.さよならReact Native  OTAとは ● On The Airの略 ● Appleの審査を介さずにアプリの更新を実行する仕組み ● 右図のように、ReactNativeで実行するjsをランタイムで更新することで実現 ● 過去にこの仕組みについてブログにまとめています → OTAのおかげで快適に開発ができるようになった！

Slide 42

Slide 42 text

4.さよならReact Native  時はうつろい

Slide 43

Slide 43 text

4.さよならReact Native  2020年ごろ ● Appleの審査時間は短縮され、2日ほどで完了するように ● 審査をこまめに出してもAppleからの怒られは発生しなかった

Slide 44

Slide 44 text

4.さよならReact Native  2020年ごろ ● Appleの審査時間は短縮され、2日ほどで完了するように ● 審査をこまめに出してもAppleからの怒られは発生しなかった Appleの審査による問題は解決！！！ OTAも必要なさそう！

Slide 45

Slide 45 text

4.さよならReact Native  これにより... ● OTAを考慮したバージョン分岐の仕組みが可読性を悪化 ● 利用されない事によりOTAの仕組みが半ばブラックボックス化 ● iOS開発とは別にReactNativeの知識を要求されてしまい、参入障壁に ● ReactNativeのパフォーマンスissueが発生 ● OSや言語の更新に伴うReactNative側の運用タスクが重い ● ReactNative自体が巨大なのでビルドに時間がかかりがち → ReactNativeの欠点が目立つようになり、開発の妨げになってしまうように。　 Rettyの現状にはReactNativeはマッチしていなさそう

Slide 46

Slide 46 text

Slide 47

Slide 47 text

4.さよならReact Native  そうだReactNativeをやめよう

Slide 48

Slide 48 text

4.さよならReact Native  やめかた ● 使用箇所をまとめ、規模感を推測する ● ReactNativeを続けるデメリットをまとめ、プランナーさんにお伝えする ● 脱却を画面単位で部分部分で進める。タスクも画面の単位で登録していく ● 脱却の温度感を高める ● 合わせて、機能の整理も行い、対応する旨味が少ない箇所は機能ごと落とす相談もする → 大きな障害もなく半年ほどで脱却完了！

Slide 49

Slide 49 text

4.さよならReact Native 

Slide 50

Slide 50 text

4.さよならReact Native 

Slide 51

Slide 51 text

4.さよならReact Native  やめた結果 ● 施策展開をより早く行えるように ● ビルド時間を三割ほど削減 ● 運用コスト低減 ● 基本的なiOS開発の知識だけで誰でも全機能を対応可能に ● クラッシュフリーレートが向上し、安定したアプリを提供可能に → 生産性・バス係数・品質の向上を達成！

Slide 52

Slide 52 text

4.さよならReact Native  まとめ ● RettyではReactNativeを採用していましたが、状況が変化した事による課題を感じたためこれをやめました ● 環境に適していない技術の利用をやめることで、生産性の向上を達成することができました ● その時その時の状況にあった最適な技術選定を行いましょうさよならReactNative, ありがとうReactNative

Slide 53

Slide 53 text

53 5. こんにちはSwiftUI

Slide 54

Slide 54 text

5. こんにちはSwiftUI  既存のUIKitのつらみ ● 「どう描画するか」の責務を持つ必要がある ● データに基づいた描画更新を自前で作り込まなければならない ● 自由度が高いために、品質の低いUIを作ってしまいがち ● APIが多く、複雑度が高い → 開発・運用共に難易度が高め

Slide 55

Slide 55 text

5. こんにちはSwiftUI  SwiftUIのよさ ● 「何を描画するか」の責務さえ持てばよく、「どう描画するか」は考えなくても良い ● データに基づいた描画更新をフレームワーク側で行ってくれる。差分更新もしてくれるのでパフォーマンスも比較的良い ● APIがシンプルでわかりやすい ● プレビュー機能付き → SwiftUI採用して開発効率上げたい！

Slide 56

Slide 56 text

5. こんにちはSwiftUI  状況 ● WWDC2019でSwiftUIが発表されて二年、SwiftUIに対応したiOS13以降のOSも浸透 ○ Rettyアプリとしては95%以上はiOS13.0以上で利用されている状態だった ● ReactNative脱却で大きめのUI層のリプレイスが計画されていた SwiftUIやるなら今しかない！

Slide 57

Slide 57 text

5. こんにちはSwiftUI  導入方法 1. お試しにあまり変更が入らない画面に対して隙間時間でリプレイスを実行 2. PRレビューを通して、チームメンバーに感触を聞いてみる 3. リプレイスが完了し、クオリティ面でも問題ないことを確認、プランナーさん側と懸念点を話し合う 4. しばらく運用してみて、Rettyでの利用ケースを満たせるかを確認 5. 他画面へも展開

Slide 58

Slide 58 text

5. こんにちはSwiftUI  以下の画面はSwiftUIで実装されていますその他にもあるかも ... 検索結果画面オリジナルリスト画面ログイン/会員登録画面

Slide 59

Slide 59 text

5. こんにちはSwiftUI  やってみてよかったところ ● APIが直感的で、理解しやすく、実装しやすい ● 余計な描画処理を実行できなくなった ● フロントエンドのアーキテクチャが統一された ● 既存UIにも組み込みやすく、応用範囲が広い ● プレビューが便利で開発しやすい ○ Xcodeのプレビューも便利ですが、もっぱら開発にAppCodeを利用しているため、Injectioniiiというホットリロード的な挙動を実現するツールを利用しています。これ自体はUIKitでも使えるのでSwiftUI関係なくお勧めです

Slide 60

Slide 60 text

5. こんにちはSwiftUI  やってみて悪かったところ ● iOS13でのSwiftUIの挙動が怪しい部分がたくさんある ○ iOS13の対応で苦労したポイントがたくさんあるので、もし待てるのであればサポート対象をiOS14以上としてから導入をした方が幸せになれるかも ● 細かいところに手が出しにくい分、融通が効かないポイントも多々あった ○ ハック的な手法で問題を解決していると、APIが直感的なのが良いところだったのに、あまりにも難解なことをしてしまっているのではないか？というつらみを感じるところも ● バージョン間の互換性の無さが激しい ○ メジャーバージョン間だけでなく、マイナーバージョン間でも挙動が異なる場合があるので、色々なシミュレータをたくさん立ち上げて挙動を確認する事になります

Slide 61

Slide 61 text

5. こんにちはSwiftUI  総合的に感じたこと ● 問題点もいくつかありますが、その点を考慮してもメリットの方が大きかったと感じます ○ 気持ち的にはUIKitとの比較で半分くらいの時間でUIが実装できてる感じがします ○ 互換性問題についてはUIKitでもないことはないのでどっちもどっち感 ● とはいえ、複雑なUIを組もうとすると、ハマりポイントが多い点は否めない ● 場合によってはSwiftUIで頑張りすぎず、UIKitの力を借りる選択肢も捨てないでおきたいところ ○ 文字列に対する装飾などは、UITextViewなどでAttributedStringを出してしまった方が楽 ■ iOS15からはTextもAttributedStringが使えます

Slide 62

Slide 62 text

5. こんにちはSwiftUI  Androidも宣言的UI ● SwiftUIと同じ宣言的UIの考え方で作られたAndroid向けUIフレームワーク・JetpackComposeがあります ● 同じ宣言的UIのパラダイムで作られているため、syntaxが似ています。概ね採用に伴うメリットもSwiftUIと似てます。 ● UI作りのナレッジをある程度共有できるメリットもあるため、AndroidのJetpack Compose導入も進めています！

Slide 63

Slide 63 text

6. ユーザーの声/社内意見の　吸い上げと施策への反映事例 63

Slide 64

Slide 64 text

意見や不具合報告を素早く反映していく流れ  [ポイント] ● 幅広い場所で声を集める (発散) ● 見える化・リスト化 (集約) ● 必要性を共有 & 実装してしまう (実行) Rettyのアプリに  あれほしいなぁ...  App: ユーザーさんのためにこの機能実装したいです!! PO: やっちゃってOK! App: なんならもう実装されてます!! PO: マジ神かよ 🥺

Slide 65

Slide 65 text

最近リリースされた小さな体験機能  - WebViewのProgress Bar化 - ユーザー詳細の投稿リストUI変更 - 住所や店名をクリップボードコピー可能に - Quick Action - 写真のExIFに基づく投稿店舗推薦 - シェアの内容とUI改善 - ログインセッション有効期限の正常化

Slide 66

Slide 66 text

幅広い場所で声を集める (発散)  #quality_report (不具合報告や疑問がメイン) #media_app のGOOD IDEA WF (意見やアイデア提案がメイン) 意見・不具合報告を流すSlackチャンネルで広く意見を集める

Slide 67

Slide 67 text

OFF会に参加するには: https://inforetty.zendesk.com/hc/ja/articles/360000424641 ユーザーさんから直接フィードバックをもらう機会  - 公式OFF会 - Rettyのユーザーさんどうしが美味しいご飯を片手に交流 - アプリへの感想・要望を頂くこともあり、貴重なご意見として1つでも多く・早く反映を目指しています。 - ユーザーインタビュー - 分析チームが主導しているユーザーさんへのインタビュー - 誰でも参加(閲覧)可能で生の声を聞くことができる

Slide 68

Slide 68 text

見える化・リスト化  Slack WFを使ってGOOD IDEAをリスト化 (毎週の振り返りで見直す) 技術負債・プロダクト課題のリスト (緊急性・重要性を精査してバックログへ) やったものは後からでもバックログへ & スプリントレビューで発表

Slide 69

Slide 69 text

必要性を共有 & 実装してしまう (実行)  ● GOOD IDEAのリスト: 毎週みんなで眺める ● 技術負債・プロダクト課題 : チームで精査&POとバックログ化を検討 ● スプリント開始前のMTGでPOや他チームと調整施策開発の優先度も高いので価値がありそうだけど難しい →定期的に関係者で要望を共有価値がありそうですぐできそう →エンジニア裁量でやってしまうエンジニアには「どんな価値・リスクがあるか」を分かりやすく説明する力が必要

Slide 70

Slide 70 text

クイックアクションや投稿店舗サジェストは 22新卒の内定者インターンが実装 💪 インターン生にUser Happyを届ける経験をしてもらう  - 難易度と希望がマッチしていれば　　　インターンに依頼することも - 体験改善をリリースする経験を通じて　実装スキル・プランニング力・意欲がUP Slackチャンネルで報告 & みんなで称賛コメント

Slide 71

Slide 71 text

まとめ  とはいえリソース制約はまだまだある状態 💦 → ぜひ一緒にアプリ開発しませんか! 社内外の声をアプリへ反映する流れ ● 幅広い場所で声を集める (発散) ○ Slackを中心に気軽に質問・意見を送る ○ OFF会等で直接ユーザーさんの声を聞く ● 見える化・リスト化 (集約) ○ Spreadsheetなどにまとめて一覧に ● 必要性を共有 & 実装してしまう (実行) ○ 定期的に関係者で見直す ○ 良いものは待たずに実装

Slide 72

Slide 72 text

7. 開発効率をあげる　自動化の取り組み（CI/CD等） 72

Slide 73

Slide 73 text

本質的な開発に専念するための手動作業の削減  [ポイント] ● 外部サービスを積極活用 ● 少人数でも効率的に開発 ● 漏れ・ブレ・属人性をなくす

Slide 74

Slide 74 text

- iOS/AndroidでのCIにはBitriseを使用 - 開発/リリースビルドで実行 - ビルド(フォーマット/SwiftGen/Mockolo)とテスト実行 - GitHubに結果を表示 Bitrise (CI)  グローバルチームやインターン等の開発メンバーが増加してもコードの整合性維持に貢献

Slide 75

Slide 75 text

RenovateによるiOSのライブラリ更新通知  - renovatebot/renovate - ライブラリ更新の通知サービス - CocoaPodsやGradleに対応 - 更新条件やPR数制限の変更も可能導入以前は毎月担当者が手動で更新有無を調査現在はChange Log確認とQA依頼のみ

Slide 76

Slide 76 text

macmini + Firebase App Distribution  - 社内マシンとしてmacminiが常駐 - VPN経由でリモートデスクトップ🉑 - 比較的メンテナンスが容易かつ高速 - 主な役割 - バイナリのビルド - ベータ版配信 (Firebase App Distribution) - ストアへのアップロード (Fastlane/Gradle) - 実行のためのSlack Botも稼働 - 配信にかかる時間 - iOS:10分 - Android:5分いつでもどこでも誰でもリリース作業ができる

Slide 77

Slide 77 text

開発・QA・リリースで使っているSlack Workflow  リファインメント依頼フォーム日報リマインダー + フォーム + ボタンバックログ記載報告フォームマージ報告フォーム QA依頼+ストア文言確定フォーム + ボタンリリース有無の報告フォーム段階的リリース通知リマインダー + フォーム翻訳依頼フォーム + ボタン勤怠連絡フォーム - メンション: 固定の通知先をテンプレ化 - フォーム: 必要情報・選択肢の明文化 - リマインダー: 定期イベントを忘れない - ボタン: 依頼状態の可視化 ● 伝える相手について考えさせない ● 必要な情報だけを入力させる ● ボールを持っている人の明確化 (例) リリース前QA依頼での伝達事項 - バージョン: エンジニア→QA+PO - ストア文言(国内+外): 両PO→エンジニア - 審査/リリース状況: エンジニア→全員

Slide 78

Slide 78 text

作業効率化とデリバリ向上のために ● 外部サービスを積極活用 ● macminiを使った配信環境 ● Slack Workflowによるやりとりの定型化得られるもの ● 少人数でも効率的に開発 ● 属人化の低減・ノウハウの形式知化 ● コミュニケーション齟齬の回避・コストの削減まとめ 

Slide 79

Slide 79 text

79 アンケートのご協力をお願いします！

Slide 80

Slide 80 text

次回イベント 80

Slide 81

Slide 81 text

81 Retty採用のご案内！

Slide 82

Slide 82 text

アプリエンジニア募集中！ 82 https://hrmos.co/pages/915429 488026730497/jobs/0000138

Slide 83

Slide 83 text

プロダクトマネージャー募集中！ 83 https://hrmos.co/pages/915429 488026730497/jobs/0000085

Slide 84

Slide 84 text

UI/UXデザイナー募集中！ 84 https://hrmos.co/pages/915429 488026730497/jobs/0000134

Slide 85

Slide 85 text

エンジニア募集中！ 85

Slide 86

Slide 86 text

データエンジニア・アナリスト募集中！ 86

Slide 87

Slide 87 text

No content

Slide 88

Slide 88 text

社長室　採用チーム趣味：麻雀、ボードゲーム経歴：2013年　富士通　　　2015年　リクルートキャリア　　　2017年　フーモア　　　2019年　Retty株式会社 88 新卒では大手病を患っていて富士通へ入社。リクルートキャリアでHRに興味を持ち、営業から一転ベンチャーで人事キャリア開始！ 2019年11月、友人に誘われてRettyに入社しました！！ https://user.retty.me/3066011/