Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Retty
October 26, 2021

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

2021/10/26にオンライン開催した自社イベントのスライドです
https://retty.connpass.com/event/226111/

Retty

October 26, 2021
Tweet

More Decks by Retty

Other Decks in Business

Transcript

  1. アプリチーム リードエンジニア兼SM 趣味:鉄道・面白自販機巡り・GoogleMaps 経歴:2017年 マッチングサービス (2.5年)    2019年 Retty Inc.(2年) 5

    ユーザーの気持ちになれる、自分も使いたくなるようなサービスを作りたかったので2019年にJOIN。 Rettyのはらみ(アプリ)チームで開発やチーム運用、採用などを幅広く担当、得意分野はiOS/Swift。 最近はSlack Workflowでのコミュニケーション効率化にハマっている。 https://user.retty.me/1010703/ 好きなジャンル 郷土料理・ご当地グルメ
  2. アプリ開発チーム通称「ハラミ」 アプリ開発チームの体制
 開発メンバー5名 内定インターン2名 マネージャー Retty(国内) Retty Global Retty Order

    EM SM アプリ・バックエンド開発 アプリ・バックエンドレビュー アプリ開発 イラスト:Loose Drawing
  3. 4. さよならReact Native
 スクラム開発におけるアプリチームの取り組み
 17 2. Appチームアジャイル開発 運営の工夫
 1. Appの施策立案からリリース

    までの流れ
 3. フルリモート下での働き方
 7. 開発効率をあげる自動化の 取り組み(CI/CD)
 5. こんにちはSwiftUI
 6. ユーザーの声/社内意見の吸 い上げと施策への反映事例

  4. Appの施策立案からリリースまでの流れ
 
 
 解決方法を模索する 
 実装する
 解決方法を具体化する 
 1 課題を特定する


    検証・リリースする
 2 3 4 5  定量分析 
  定性分析 
  チケット(issue)の起票 
 職種/部門を超えたコミュニケーション
 リファインメント
 施策の事前検証
 PBIの優先度判断
 タスク分解・実装対応
 QA
 申請
 リリース
 検証項目の準備
 デザイン

  5. やるべきことを明確化
 スプリントバックログ (miro) プロダクトのやるべきこと 粒度大 & 抽象度高 毎日のコミュニケーション • デイリースクラム

    • スプリントレビュー • プランナーとの連絡会 アプリのやるべきこと 粒度小 & 抽象度低 プロダクトバックログ (Spreadsheet) 図式化 (miro)
  6. 柔軟な優先度・手段の変更
 - 必要ならばWebチームと協調して開発 - Webとの機能差を減らす・リリースタイミングを事前に計画 - 場合によってはWebViewでの実装も検討する - ストーリーを小さく分割する -

    「UI変更して新バッジを追加」は「UI変更」「新バッジを追加」に分割 → 途中で優先度を変更🉑 - iOSとAndroidは揃える必要があるか、ないなら分ける https://engineer.retty.me/entry/2020/12/12/090000 より 小さく・高頻度でリリース 優先度変更や複数手段を検討する
  7. 毎日/毎週コミニュケーション
 - 毎日 - デイリースクラム (15分) - チーム内での相談時間 (60分) -

    リファインメント (15分) - ペアプロ/実装相談 (any time) - ドキュメンテーション (any time) - 毎週 - レトロスペクティブ (30分) - POとのよもやま会 (30分) - チーム横断の振り返り共有会 (30分) https://engineer.retty.me/entry/2020/12/12/090000 より
  8. チームでのタスク進行
 - チームメンションの推奨 - 相談や依頼には基本的に @harami を推奨 - 「誰かがいなければ開発できない」状態を極力避けるようにしている -

    属人性の回避 - スクラムイベント担当は持ち回り制 - ドキュメンテーションやペアプロを推奨 - 情報の公開と更新 - Spreadsheet/miroのバックログは最新にする(SMタスク) - Rettyのルール「率直に言い合う」
  9. [ポイント] • やるべきことを明確化 ◦ バックログとスプリントが指針 ◦ 今やるべきことを明確化 • 柔軟な優先度・手段の変更 ◦

    Webなどの他手段でも実装を検討する ◦ 小さなリリースで柔軟に優先度を変更 • 毎日/毎週コミニュケーション ◦ チーム内外との情報交換を欠かさない ◦ 悪い状態を見過ごさない • チームでのタスク進行 ◦ 属人性の低いチーム開発 ◦ チームメンションなどの仕組みを利用 まとめ

  10. Slackの使われ方①
 スクラム開発・スプリントに関するメインチャンネル • スクラムイベント・複数チームに関わる出来事の共有 ◦ 施策に関する相談事・調整など • チームチャンネル ◦ チーム内の開発に関することは基本的にここに集約

    ◦ やっていること・悩んでいることの宣言 • その他ワークフローごと専用のチャンネル ◦ PRレビュー・QA依頼・リリースbot Slackワークフローを用いた依頼などの仕組み化 • 属人化による「知らなかった・いつの間に」をなくす
  11. Slackの使われ方②
 その他よく使うチャンネル • #QualityReport ◦ Web・アプリなど、不具合・仕様への疑問を共有するチャンネル ◦ クリティカルなものでなければ、バックログに積む依頼をするワークフローへ • 個人チャンネル

    ◦ チーム関わらず、いろんな人が反応してくれて嬉しい ほとんどのチャンネルは、スクラム開発に関するものなので、コロナ前から存在していた。 → discordの活用などがコロナ禍に始まったこと。
  12. スプリントに関することはmiroで管理
 • 朝会は基本的にmiroを見て進めて行く ◦ スプリントバックログ ▪ 中期的なストーリーは、全体に対するサブタスクの分解意図がわかるように ◦ スプリントゴール と

    達成具合 が目につきやすいようにする チームの改善系 • 前振り返りからのネクストアクション • 短期的に話題に上げたいことを書いておく場所 • 中長期的に、チームメンバーが 把握して欲しいことを残して置く場所 けすところけす→
  13. スプリントイベントやチームMTG
 • 朝会:15分 • リファインメント:毎日15分ある ◦ 相談場所としても大歓迎 ◦ エンジニアが持ち帰るなどもOK •

    夕会:毎日最大1時間 ◦ トピックがあれば議論する。 ◦ 雑談しながら作業したり。 ◦ 実装優先でスキップも󰢏 ※タスクの相談などは、夕会などではなく都度話す • 週次のスクラムイベント:木曜日 • 振り返り共有会 ◦ LeSS特有のイベント ◦ 各チームの振り返り内容をエスカレーションする場所
  14. 4.さよならReact Native
 OTAとは • On The Airの略 • Appleの審査を介さずにアプリの更新を実行する仕 組み

    • 右図のように、ReactNativeで実行するjsをランタイ ムで更新することで実現 • 過去にこの仕組みについてブログにまとめています → OTAのおかげで快適に開発ができるようになった!
  15. 4.さよならReact Native
 これにより... • OTAを考慮したバージョン分岐の仕組みが可読性を悪化 • 利用されない事によりOTAの仕組みが半ばブラックボックス化 • iOS開発とは別にReactNativeの知識を要求されてしまい、参入障壁に •

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

    ReactNativeのパフォーマンスissueが発生 • OSや言語の更新に伴うReactNative側の運用タスクが重い • ReactNative自体が巨大なのでビルドに時間がかかりがち → ReactNativeの欠点が目立つようになり、開発の妨げになってしまうように
  17. 4.さよならReact Native
 やめかた • 使用箇所をまとめ、規模感を推測する • ReactNativeを続けるデメリットをまとめ、プランナーさんにお伝えする • 脱却を画面単位で部分部分で進める。タスクも画面の単位で登録していく •

    脱却の温度感を高める • 合わせて、機能の整理も行い、対応する旨味が少ない箇所は機能ごと落とす相談もする → 大きな障害もなく半年ほどで脱却完了!
  18. 4.さよならReact Native
 やめた結果 • 施策展開をより早く行えるように • ビルド時間を三割ほど削減 • 運用コスト低減 •

    基本的なiOS開発の知識だけで誰でも全機能を対応可能に • クラッシュフリーレートが向上し、安定したアプリを提供可能に → 生産性・バス係数・品質の向上を達成!
  19. 5. こんにちはSwiftUI
 やってみてよかったところ • APIが直感的で、理解しやすく、実装しやすい • 余計な描画処理を実行できなくなった • フロントエンドのアーキテクチャが統一された •

    既存UIにも組み込みやすく、応用範囲が広い • プレビューが便利で開発しやすい ◦ Xcodeのプレビューも便利ですが、もっぱら開発にAppCodeを利用し ているため、Injectioniiiというホットリロード的な挙動を実現するツール を利用しています。これ自体はUIKitでも使えるのでSwiftUI関係なくお 勧めです
  20. 5. こんにちはSwiftUI
 やってみて悪かったところ • iOS13でのSwiftUIの挙動が怪しい部分がたくさんある ◦ iOS13の対応で苦労したポイントがたくさんあるので、もし待てるのであればサポート対 象をiOS14以上としてから導入をした方が幸せになれるかも • 細かいところに手が出しにくい分、融通が効かないポイントも多々あった

    ◦ ハック的な手法で問題を解決していると、APIが直感的なのが良いところだったのに、あ まりにも難解なことをしてしまっているのではないか?というつらみを感じるところも • バージョン間の互換性の無さが激しい ◦ メジャーバージョン間だけでなく、マイナーバージョン間でも挙動が異なる場合があるの で、色々なシミュレータをたくさん立ち上げて挙動を確認する事になります
  21. 5. こんにちはSwiftUI
 総合的に感じたこと • 問題点もいくつかありますが、その点を考慮してもメリットの方が大きかったと感じま す ◦ 気持ち的にはUIKitとの比較で半分くらいの時間でUIが実装できてる感じがし ます ◦

    互換性問題についてはUIKitでもないことはないのでどっちもどっち感 • とはいえ、複雑なUIを組もうとすると、ハマりポイントが多い点は否めない • 場合によってはSwiftUIで頑張りすぎず、UIKitの力を借りる選択肢も捨てないでおき たいところ ◦ 文字列に対する装飾などは、UITextViewなどでAttributedStringを出してしまっ た方が楽 ▪ iOS15からはTextもAttributedStringが使えます
  22. 意見や不具合報告を素早く反映していく流れ
 [ポイント] • 幅広い場所で声を集める (発散) • 見える化・リスト化 (集約) • 必要性を共有

    & 実装してしまう (実行) Rettyのアプリに
 あれほしいなぁ...
 App: ユーザーさんのために この機能実装したいです!! PO: やっちゃってOK! App: なんならもう 実装されてます!! PO: マジ神かよ 🥺
  23. 最近リリースされた小さな体験機能
 - WebViewのProgress Bar化 - ユーザー詳細の投稿リストUI変更 - 住所や店名をクリップボードコピー可能に - Quick

    Action - 写真のExIFに基づく投稿店舗推薦 - シェアの内容とUI改善 - ログインセッション有効期限の正常化
  24. 必要性を共有 & 実装してしまう (実行)
 • GOOD IDEAのリスト: 毎週みんなで眺める • 技術負債・プロダクト課題

    : チームで精査&POとバックログ化を検討 • スプリント開始前のMTGでPOや他チームと調整 施策開発の優先度も高いので 価値がありそうだけど難しい →定期的に関係者で要望を共有 価値がありそうですぐできそう →エンジニア裁量でやってしまう エンジニアには「どんな価値・リスクがあるか」を分かりやすく説明する力が必要
  25. まとめ
 とはいえリソース制約はまだまだある状態 💦 → ぜひ一緒にアプリ開発しませんか! 社内外の声をアプリへ反映する流れ • 幅広い場所で声を集める (発散) ◦

    Slackを中心に気軽に質問・意見を送る ◦ OFF会等で直接ユーザーさんの声を聞く • 見える化・リスト化 (集約) ◦ Spreadsheetなどにまとめて一覧に • 必要性を共有 & 実装してしまう (実行) ◦ 定期的に関係者で見直す ◦ 良いものは待たずに実装
  26. macmini + Firebase App Distribution
 - 社内マシンとしてmacminiが常駐 - VPN経由でリモートデスクトップ🉑 -

    比較的メンテナンスが容易かつ高速 - 主な役割 - バイナリのビルド - ベータ版配信 (Firebase App Distribution) - ストアへのアップロード (Fastlane/Gradle) - 実行のためのSlack Botも稼働 - 配信にかかる時間 - iOS:10分 - Android:5分 いつでもどこでも誰でもリリース作業ができる
  27. 開発・QA・リリースで使っているSlack Workflow
 リファインメント依頼 フォーム 日報 リマインダー + フォーム + ボタン

    バックログ記載報告 フォーム マージ報告 フォーム QA依頼+ストア文言確定 フォーム + ボタン リリース有無の報告 フォーム 段階的リリース通知 リマインダー + フォーム 翻訳依頼 フォーム + ボタン 勤怠連絡 フォーム - メンション: 固定の通知先をテンプレ化 - フォーム: 必要情報・選択肢の明文化 - リマインダー: 定期イベントを忘れない - ボタン: 依頼状態の可視化 • 伝える相手について考えさせない • 必要な情報だけを入力させる • ボールを持っている人の明確化 (例) リリース前QA依頼での伝達事項 - バージョン: エンジニア→QA+PO - ストア文言(国内+外): 両PO→エンジニア - 審査/リリース状況: エンジニア→全員
  28. 作業効率化とデリバリ向上のために • 外部サービスを積極活用 • macminiを使った配信環境 • Slack Workflowによるやりとりの定型化 得られるもの •

    少人数でも効率的に開発 • 属人化の低減・ノウハウの形式知化 • コミュニケーション齟齬の回避・コストの削減 まとめ