顧客価値を安定的に届けるために―Rettyにおけるアジャイル開発とQA改善の取り組み / Deliver customer value regularly at Retty

Ques #14の登壇資料です。
https://ques.connpass.com/event/149668/
https://quesqa.com/interview-retty-yuichi-tsunematsu/

Transcript

1. 顧客価値を安定的に届けるために
 Retty株式会社
 常松祐一
 Rettyにおけるアジャイル開発とQA改善の取り組み
 2019/11/15
 confidential
2. 自己紹介
 • 常松祐一 (つねまつ ゆういち) 
 ◦ Engineering Manager 
 ◦ Software Engineer
 ◦ Agile Development
 • SNSアカウント
 ◦ tunepolo : 
 ◦ tune : 
 
 • 顧客にとって価値のあるプロダクトを、チーム一丸 となって協力し、短期間にリリースする開発体制の あり方を模索しています。 
 confidential
3. Confidential Copyright © 2018 Retty, Inc. All Rights Reserved. 3 confidential
4. Confidential Copyright © 2018 Retty, Inc. All Rights Reserved. 4 confidential
5. Confidential Copyright © 2018 Retty, Inc. All Rights Reserved. 5 confidential
6. グルメサービスRettyを支えるシステム
 confidential Photo by Jay Wennington on Unsplash to C向け Web & App to B(レストラン)向け Web
7. 今回のテーマ
 confidential Agile Testの今 Photo by David Travis on Unsplash
8. あらかじめ申し上げておくと・・・
 confidential • RettyはQAの分野で進んだ取り組みができている会社ではありません。
 • RettyはQAを専門とする組織・チーム・社員がおりません。
 
 • それでもRettyはアジャイルな開発に真摯に取り組んでいる会 社だと確信しており、今日の話がアジャイルなQAを探求する皆 様の参考になることを願っております。

9. アジャイルってなんでしたっけ?
 confidential • 状況変化に機敏に対応していけるという「状態」。
 • 「アジャイル開発をやります」と言ってすぐにできるもので はない。組織の文化を変える必要がある。
 Photo by Cara Fuller on Unsplash
10. Rettyが目指すソフトウェア開発の目標
 confidential • 「グルメサービスRetty」ワンプロダクトで成長する
 ◦ メンバーが増えてもプロダクトは増えない。
 • 全社で重要なことに注力する
 ◦ 重要なものから1つずつ対処する。着手からリリースまでを短く。
 • フィードバックを踏まえ、短期間で方針を見直していく。
 
 「上記が達成された状態＝顧客価値を安定的に届ける」
 を実現するため、アジャイル開発に取り組んでいます。

11. 開発が抱えていた課題
 confidential
12. 課題を改めて整理すると・・・
 confidential 1. アジャイルになっていない開発プロセス
 ◦ アジャイルを目指したはずが綺麗なウォーターフォールになっている。
 ◦ 開発着手からリリースまでが長い。
 2. レガシーシステムのお守り
 ◦ 創業からサービスを支えるPHPモノリス。
 ◦ 全体像がわからず、パッチワークがさらなる負債となる。
 3. ドメイン知識が不足し、開発・ビジネスのスピードが上がらない
 ◦ 仕様の把握に時間が取られ、開発スピードが遅くなる。
 ◦ テストで見るべきポイントが曖昧で増えていく一方。

13. 1. 開発プロセスの改善
 confidential 【課題感】
 1. アジャイルを目指したはずが綺麗なウォーターフォールになっている 
 2. 開発着手からリリースまでが長い
14. スクラムの簡単な紹介
 confidential
15. アジャイルにやっているつもりが、なぜWFに?
 confidential 1. 「何を作るか」と「どう作るか」を同じ人が担当。
 2. 手が空いてはいけないと思い、開発タスクを早期に開発 者へアサイン。
 3. 開発が遅れた時のリカバリが難しくなるので開発項目を 入念に見積もる。
 Photo by Mike Lewis HeadSmart Media on Unsplash
16. 開発プロセスをテコ入れしたポイント
 confidential QA観点で重要なものを抜粋すると
 • バックログリファインメントの改善
 • 開発プロセスの見える化
 • 小さく定期的に出していく意識の醸成
 Photo by Olga Guryanova on Unsplash
17. バックログリファインメントの改善
 confidential • バックログの項目に対し、「何をやる か」について「複数人」で議論し、「開 発規模に対しての見積もり」を「ざっく りと」出す。メンバ間で見積もりに差異 が生じた場合、「その背景をきちんと 議論する」。

18. だめなバックログリファインメント
 confidential • バックログの項目に対し、「どうやる か」について「個人」で考え、「開発期 間に対しての見積もり」を「正確に」出 す。メンバ間で見積もりに差異が生じ た場合、「どちらかが折れるまで議論 する」。
 • バックログの項目に対し、「何をやる か」について「複数人」で議論し、「開 発規模に対しての見積もり」を「ざっく りと」出す。メンバ間で見積もりに差異 が生じた場合、「根拠を互いに共有」 し「短く終わる」。

19. バックログリファインメントの目的 1. 開発スケジュールを正確に見積もるためではない。 2. 関係者でアイテムについての認識を合わせるため。 3. バックログのアイテムが開発可能であることを確認する。 a. 受け入れ条件が明確である。 b. 見積もりが可能なサイズである。 c. 実現の目処がついている。 4. バックログがメンテされ、取り組む価値のある開発項目 が上位に並ぶようにする。 ※社内向け説明資料より抜粋
20. 開発プロセスの見える化
 confidential • 現在の開発プロセスを可視化し、ボトルネックを明確にするためにカンバンを使う。
 • GitHub Project、ZenHubを使っていたが、ツールが先にあるとツールの使いこなしに 頭が向いてしまう。
 ◦ GitHubのIssueよりも小さい単位でタスクを分割しない
 ◦ ツールがサポートしていない項目は可視化しない
 • 柔軟にカスタマイズができる物理カンバン (壁・ホワイトボード+付箋)で自分たちに 合ったやり方を確立し、その上で必要ならば電子化する。

21. カンバンの変化 (1週目)
 confidential チームのタスク以外に個人で請け負っ ているタスクがたくさん合った
22. カンバンの変化 (2週目)
 confidential 振り返りで決めたことを 常に見える所に掲示
23. カンバンの変化 (3週目)
 confidential 社内のリリースフローに合わ せてフェーズを詳細化
24. カンバンの変化 (4週目)
 confidential
25. 小さく定期的に出していく意識の醸成
 confidential • 大きくリリースしようとすると計画が大変になり、開 発が複雑になり、QAが大変になり、障害対応も大 変になる。
 • 小さく定期的にリリースできれば計画は小さくなり、 開発はシンプルになり、QAはやることが明確で、障 害原因の絞り込みもやりやすい。
 • 例えば
 ◦ ありたい姿→ユーザ導線を改善したい。ペー ジ構成からヘッダからきちんと設計して刷新す る。
 ◦ 最初の一歩→あるページに「戻る」リンクをつ けて様子を見る。

26. 開発プロセスの改善 まとめ
 confidential • 【課題感】
 ◦ アジャイルを目指したはずが綺麗なウォーターフォール になっている
 ◦ 開発着手からリリースまでが長い
 
 • 【やったこと】
 ◦ バックログリファインメントの改善
 ◦ 開発プロセスの見える化
 ◦ 小さく定期的に出していく意識の醸成
 Photo by Olga Guryanova on Unsplash
27. 2. レガシーシステムからの脱却
 confidential 【課題感】
 1. 創業からサービスを支えるPHPモノリス。 
 2. 全体像がわからず、パッチワークがさらなる負債となる。 

28. 創業からサービスを支えるPHPモノリス
 confidential 1. サービスの根幹をなす機能が密結合されている。
 2. 正しいビジネスロジックが把握しきれない。
 3. リファクタリング・改善が入れにくい
 Photo by James Hammond on Unsplash
29. レガシーシステムをテコ入れしたポイント
 confidential QA観点で重要なものを抜粋すると
 • マイクロサービスへの移行
 • 不要になったコードの削除
 • ビジネスロジックの整理・簡素化
 Photo by Pranav Kumar Jain on Unsplash
30. PHPのモノリス→マイクロサービスへの移行
 confidential 責務を小さく・明確にし、 リリースしやすくする。 ⇆ 一般的にQAは難しくなる。
31. 不要になったコードの削除
 confidential • 「焼け石に水」→「雨だれ岩を穿つ」
 ◦ 不要になった機能の削除
 ◦ 実行されないコードを削除
 ◦ 不要になったブランチの削除
 ◦ 不要になったIssueのクローズ
 • マイクロサービスへの移行と同じくらいモノリスの弱体化は効果がある。

32. ビジネスロジックの整理・簡素化
 confidential • マイクロサービスの導入と合わせて型を導入
 ◦ proto / gRPC
 ◦ GraphQL, TypeScript
 • 不要コードの削除と合わせてロジックの簡素化
 ◦ 表示する写真の選別
 ◦ 口コミの表示順 などなど

33. 他にも取り組んでいる技術的な改善
 confidential • CircleCIを使った自動テスト、カバレッジ計測・自動テスト
 • Dependabotを使ったライブラリの定期的な更新
 • Datadogを用いたモニタリング機構
 • Terraformを使ったIaaC

34. レガシーシステムからの脱却 まとめ
 confidential • 【課題感】
 ◦ 創業期を支えたPHPモノリス
 ◦ 全体像がわからず、パッチワークがさらなる負債とな る。
 
 • 【やったこと】
 ◦ マイクロサービスへの分割
 ◦ 不要になったコードの削除
 ◦ ビジネスロジックの整理・簡素化
 Photo by Pranav Kumar Jain on Unsplash
35. 3. ドメイン知識の蓄積とQAプロセス改善
 confidential 【課題感】
 1. 仕様の把握に時間が取られ、開発スピードが遅くなる。 
 2. テストで見るべきポイントが曖昧で増えていく一方。 

36. ドメイン知識が蓄積されず、QA改善が進まない
 confidential 1. WF型の開発プロセスで、特定個人に知識が溜まる。
 2. PHPモノリスのあちこちにロジックが分散し、As-Isの把握 すら困難になる。
 3. 上記解決のため、QAプロセスの抜本的な刷新を図るが 頓挫する。
 Photo by Jessica Sysengrath on Unsplash
37. ドメイン知識・QAプロセスをテコ入れしたポイント
 confidential QA観点で重要なものを抜粋すると
 • 現状QAプロセスの良い点を認識する。
 • To-Beではなく、As-Isから改善を進める。
 • テスト観点・仕様の集積場を設ける。
 Photo by Sikai Gu on Unsplash
38. 現状QAプロセスの良い点を認識する
 confidential • 【課題】専門のQA組織・チームが無い
 ◦ ✖ QA組織・チームを立ち上げよう
 ◦ ◦ 組織全体でQAをやっていく機運がある。
 ◦ ☆ QA組織・チームが立ち上がっても、「ドメイン知識が不足している」という現 在の問題は改善されないだろう。
 • 【課題】プランナーがQA項目を考えている
 ◦ ✖ QA項目はQAエンジニアが考えてチェックするべき
 ◦ ◦ プランナーがQA項目を考えることで仕様の矛盾に目が向くようになってい る。ユーザ観点のチェック項目はプランナーが作成し、エンジニアは実装観点 のチェックを実施する。

39. To-Beではなく、As-Isから改善を進める
 confidential • 「QA組織・チームを立ち上げなければならない」という思い込みを元に、理想の状 態から逆算して改善を進めようとした。
 ◦ QAプロジェクト推進担当者を選出 → 本人の重荷に
 ◦ 完全を目指した仕様書 → メンテされず
 
 • 理想を話すより、今より少しでも改善される具体的な行動をとる。

40. テスト観点・仕様の集積場を設ける
 confidential 社内Confluenceに集積場を設けた。 • 問題に気がつくたびに追記する。 • まずは書き出してもらうことを優先 し、後から整理する。 テスト観点の集積→仕様の集積→テスト 項目の修正 と段階的に進める
41. ドメイン知識の蓄積とQAプロセスの改善 まとめ
 confidential • 【課題感】
 ◦ 仕様の把握に時間が取られ、開発スピードが遅くなる。
 ◦ テストで見るべきポイントが曖昧で増えていく一方。
 
 • 【やったこと】
 ◦ 現状プロセスの良い点を認識する。
 ◦ To-Beではなく、As-Isから改善を進める。
 ◦ テスト観点・仕様の集積場を設ける。
 Photo by Sikai Gu on Unsplash
42. まとめ
 confidential
43. まとめ
 confidential 1. 開発プロセスの改善
 ◦ バックログリファインメントの改善
 ◦ 開発プロセスの見える化
 ◦ 小さく定期的に出していく意識の醸成
 2. レガシーシステムからの脱却
 ◦ マイクロサービスへの分割
 ◦ 不要になったコードの削除
 ◦ ビジネスロジックの整理・簡素化
 3. ドメイン知識の蓄積とQAプロセスの改善
 ◦ 現状プロセスの良い点を認識
 ◦ To-Beではなく、As-Isから改善を進める
 ◦ テスト観点・仕様の集積場を設ける

44. アジャイルな開発をやっていくには
 confidential • アジャイルは状況変化に機敏に対応していけるという「状 態」である。
 • 仕組みを導入すればできるものではない。
 • 組織の文化を変える必要がある。
 Photo by Cara Fuller on Unsplash
45. Rettyは様々なポジションで仲間を募集しています
 confidential Rettyの新たな仲間・募集ポジション一挙公開！ https://note.mu/retty_inc/n/n5bb837354e47 または私までお気軽にご連絡ください。 twitter : @tunepolo mailto: yuichi-tsunematsu@retty.me