突撃となりのプロジェクト / EC Tech Talk

https://pepabo.connpass.com/event/245104/ での資料です

Transcript

1. 突撃となりのプロジェクト hrysd / GMO PEPABO inc. 2022.05.26 EC Tech Talk -カラーミーショップとSTORESを支えるチームづくりと開発の裏側- 1
2. 自己紹介 2 - @hrysd - EC 事業部 DX チーム所属 - 事業部を横断したアプリケーションの改善等に従事 - 最近は LeetCode の問題を一日一問解くのを習慣にしてます よしだ ひろし
3. 3 あらすじ、今日話すこと
4. あらすじ 、今日話すこと 4 別チームのプロジェクトの助っ人 - 優先度の関係で開発が停滞していたプロジェクトが再開 - エンジニアの助っ人として参画 - プロジェクトを進めていくために取り組んだ、いることを紹介
5. 5 プロジェクトを進める
6. プロジェクトを進めていく 6 プロジェクトが進んでいるとは? 指標をみると進んでいると判断できる ? - イテレーションで消化できるポイントが N pt 増えた - ベロシティが上がった - 等々
7. プロジェクトを進めていく 7 この指標が示す状態ってつまり - 持続的にユーザに対し価値を提供できる - チーム、プロジェクトとして予測可能な計画をたてることができる
8. 8 プロジェクトを進めていく “アジャイル宣言の背後にある原則 ” https://agilemanifesto.org/iso/ja/principles.html “アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。”
9. プロジェクトを進めていく 9 新しいメンバーという立場から考えてみる 今回のようなチームのメンバーの増減といった外的な要因に対してもペースを維持していけるよ うな状態を目指すと良いのでは 💡
10. 10 新しいメンバーを受け入れる
11. プロジェクトを進めていく 11 新しいメンバーが仕事に取り組んでいけるように - ドキュメント・仕様をまとめる - 何が決まっていて、何を決める必要があるのか - ゴールとの差分がわかる - ストーリーにやることを実現・解決したいことを明記 - 〜〜を修正、だけではなく何をここでしたいのか - ハイコンテクストな説明をやめる - ストーリーの整理 - 次に何に、どの順で取り組めばいいのか
12. 新しいメンバーを受け入れる 12 新しいメンバーが来てくれた - 新しいメンバーが来てくれた！ - 受け入れ - このプロジェクトで達成したいことはこういうことで - 資料はここにまとまっていて - タスクの上から取り組んでください - わからないことは聞いてください
13. 新しいメンバーを受け入れる 13 新しいメンバーが来てくれた - 超人ならできそう！ - だが、超人は空想の話
14. 新しいメンバーを受け入れる 14 メンバーごとの違い - 技術、ドメインへの理解具合は人それぞれ - 全員が全てを理解できているわけではない - 新規、既存のメンバー問わず - 考えてもわからない事もある - 私たち特有の事情
15. 新しいメンバーを受け入れる 15 新しいメンバーが来てくれた - 質問いつでも受けてます - する側 - こんなに、こんなこと質問して平気かな？ - うける側 - 質問来ないから問題なく取り組めている（？） - 今、XXXX をやっているので後で答えます - “フロー状態” の乱れ - https://ja.wikisource.org/wiki/プログラマが知るべき 97のこと/ペアプログラミングと「フロー」
16. 新しいメンバーを受け入れる 16 新しいメンバーが来てくれた - ペアプログラミング - エクストリームプログラミングのプラクティス http://objectclub.jp/community/XP-jp/xp_relate/whatisxp-j#pair - 狙い - 仕様、暗黙知の共有 - ペア設計、レビューにおける手戻りの軽減 - 差し込みを減らし、フローを安定させる
17. 新しいメンバーを受け入れる 17 どうやっているか - 詳細を考えリストアップ - 項目ごとに休憩、ドライバー、ナビゲーターの交換 - 対面、リモート問わず実施 - Visual Studio Code の Live Share - お互いの環境に左右されない - 一日に 3 時間程度 - 作業のログを取る - 話ながら手を動かす都合、ログを残しづらい - 雑談・意思決定のふりかえりに - 土地を耕す - 種を植える - 水やり - 収穫
18. 18 プロジェクトのリリース
19. プロジェクトのリリース 19 大きめな機能の開発 - 機能開発において避けては通れないのはリリース - チームではトランクベースで開発を行なっている - 開発したものは都度本番環境にリリースしている - 公開範囲の制限にはフィーチャートグルを利用 - トピックブランチ、まとめブランチは作らない - 他の開発との衝突を避ける - レビュー負荷の軽減 - リリースの範囲を狭め、影響範囲を狭く
20. プロジェクトのリリース 20 フィーチャートグルの今 - 設定ファイル、コード上での分岐 - 動作環境、対象のユーザ等にのみ公開できるような仕組み - 統一的な方針はなく、プロジェクトにより異なる - 設定自体が煩雑になりがち - コード上からしか読み取る事ができない
21. プロジェクトのリリース 21 煩雑なフィーチャートグル - どの環境、どのユーザで動作確認できるかコード上からしか読み取れない - 例: 本番環境以外で確認できる if env != 'production' feature end
22. プロジェクトのリリース 22 煩雑なフィーチャートグル - どの環境、どのユーザで動作確認できるかコード上からしか読み取れない - 例: 本番環境以外で確認できる - 設定ファイルを環境ごとに用意 if Config.feature_is_enabled feature end production: feature_is_enabled: false development: feature_is_enabled: true
23. プロジェクトのリリース 23 煩雑なフィーチャートグル - どの環境、どのユーザで動作確認できるかパッとわからない - 例: 本番環境以外で特定のユーザは確認できる if Feature.user_ids.include?(current_user_id) && env != 'production' feature end
24. プロジェクトのリリース 24 他の問題点 - 動作環境の変更・設定の変更に、デプロイが必要になる - リリース作業 - 問題発生時の切り戻し作業 - も同様 - チーム外のメンバー、エンジニア以外のメンバーの対応が難しい - コードベースの編集が必要であるため、誰もが対応できるとは言い難い - QA チームといった別チームが自ら動作環境を用意するということも難しい - どこの環境で、どのユーザを使ってください
25. プロジェクトのリリース 25 解決するために - Unleash - フィーチャトグルを管理するサービス - https://github.com/Unleash/unleash - https://www.getunleash.io - 特定のユーザ、段階的なリリースと柔軟な設定が可能 - 各種言語向けの SDK （Ruby, JavaScript, Go, PHP…）
26. プロジェクトのリリース 26 解決するために - プロジェクトに導入中 - Web UI があるため、アクセスできるメンバー全員がフィーチャトグルを設定できる - 設定の仕方はドキュメントを用意しエンジニア以外もできるように - フィーチャートグルの設定次第では本番環境でも動作確認できる - Web UI を操作するだけのため、デプロイを伴わない - トランクベースの開発と相性が良い - 誰でもリリース・切り戻しが可能に
27. プロジェクトのリリース 27 悩んでいること - 操作が気軽 - 人間が操作する場合に切り離せない操作ミス - 結果として全公開といったことは避けたい - 誰もが安心して操作できるような方法はないかを検討中
28. 28 まとめ
29. まとめ 29 まとめ 別チームのプロジェクトに助っ人として参画しそこで考えたこと、取り組んだ事を紹介しました。健 全な開発を続けていくために今後とも取り組んでいきます。 また、一緒に取り組んでくれる方も募集中です！ !!11