Tweet
Tweet

Slide 1

Slide 1 text

顧客価値を安定的に届けるために
 Retty株式会社
 常松祐一
 Rettyにおけるアジャイル開発とQA改善の取り組み
 2019/11/15
 confidential

Slide 2

Slide 2 text

自己紹介
 ● 常松祐一 (つねまつ ゆういち) 
 ○ Engineering Manager 
 ○ Software Engineer
 ○ Agile Development
 ● SNSアカウント
 ○ tunepolo : 
 ○ tune : 
 
 ● 顧客にとって価値のあるプロダクトを、チーム一丸 となって協力し、短期間にリリースする開発体制の あり方を模索しています。 
 confidential

Slide 3

Slide 3 text

Confidential Copyright © 2018 Retty, Inc. All Rights Reserved. 3 confidential

Slide 4

Slide 4 text

Confidential Copyright © 2018 Retty, Inc. All Rights Reserved. 4 confidential

Slide 5

Slide 5 text

Confidential Copyright © 2018 Retty, Inc. All Rights Reserved. 5 confidential

Slide 6

Slide 6 text

グルメサービスRettyを支えるシステム
 confidential Photo by Jay Wennington on Unsplash to C向け Web & App to B(レストラン)向け Web

Slide 7

Slide 7 text

今回のテーマ
 confidential Agile Testの今 Photo by David Travis on Unsplash

Slide 8

Slide 8 text

あらかじめ申し上げておくと・・・
 confidential ● RettyはQAの分野で進んだ取り組みができている会社ではありません。
 ● RettyはQAを専門とする組織・チーム・社員がおりません。
 
 ● それでもRettyはアジャイルな開発に真摯に取り組んでいる会 社だと確信しており、今日の話がアジャイルなQAを探求する皆 様の参考になることを願っております。


Slide 9

Slide 9 text

アジャイルってなんでしたっけ?
 confidential ● 状況変化に機敏に対応していけるという「状態」。
 ● 「アジャイル開発をやります」と言ってすぐにできるもので はない。組織の文化を変える必要がある。
 Photo by Cara Fuller on Unsplash

Slide 10

Slide 10 text

Rettyが目指すソフトウェア開発の目標
 confidential ● 「グルメサービスRetty」ワンプロダクトで成長する
 ○ メンバーが増えてもプロダクトは増えない。
 ● 全社で重要なことに注力する
 ○ 重要なものから1つずつ対処する。着手からリリースまでを短く。
 ● フィードバックを踏まえ、短期間で方針を見直していく。
 
 「上記が達成された状態＝顧客価値を安定的に届ける」
 を実現するため、アジャイル開発に取り組んでいます。


Slide 11

Slide 11 text

開発が抱えていた課題
 confidential

Slide 12

Slide 12 text

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


Slide 13

Slide 13 text

1. 開発プロセスの改善
 confidential 【課題感】
 1. アジャイルを目指したはずが綺麗なウォーターフォールになっている 
 2. 開発着手からリリースまでが長い

Slide 14

Slide 14 text

スクラムの簡単な紹介
 confidential

Slide 15

Slide 15 text

アジャイルにやっているつもりが、なぜWFに?
 confidential 1. 「何を作るか」と「どう作るか」を同じ人が担当。
 2. 手が空いてはいけないと思い、開発タスクを早期に開発 者へアサイン。
 3. 開発が遅れた時のリカバリが難しくなるので開発項目を 入念に見積もる。
 Photo by Mike Lewis HeadSmart Media on Unsplash

Slide 16

Slide 16 text

開発プロセスをテコ入れしたポイント
 confidential QA観点で重要なものを抜粋すると
 ● バックログリファインメントの改善
 ● 開発プロセスの見える化
 ● 小さく定期的に出していく意識の醸成
 Photo by Olga Guryanova on Unsplash

Slide 17

Slide 17 text

バックログリファインメントの改善
 confidential ● バックログの項目に対し、「何をやる か」について「複数人」で議論し、「開 発規模に対しての見積もり」を「ざっく りと」出す。メンバ間で見積もりに差異 が生じた場合、「その背景をきちんと 議論する」。


Slide 18

Slide 18 text

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


Slide 19

Slide 19 text

バックログリファインメントの目的 1. 開発スケジュールを正確に見積もるためではない。 2. 関係者でアイテムについての認識を合わせるため。 3. バックログのアイテムが開発可能であることを確認する。 a. 受け入れ条件が明確である。 b. 見積もりが可能なサイズである。 c. 実現の目処がついている。 4. バックログがメンテされ、取り組む価値のある開発項目 が上位に並ぶようにする。 ※社内向け説明資料より抜粋

Slide 20

Slide 20 text

開発プロセスの見える化
 confidential ● 現在の開発プロセスを可視化し、ボトルネックを明確にするためにカンバンを使う。
 ● GitHub Project、ZenHubを使っていたが、ツールが先にあるとツールの使いこなしに 頭が向いてしまう。
 ○ GitHubのIssueよりも小さい単位でタスクを分割しない
 ○ ツールがサポートしていない項目は可視化しない
 ● 柔軟にカスタマイズができる物理カンバン (壁・ホワイトボード+付箋)で自分たちに 合ったやり方を確立し、その上で必要ならば電子化する。


Slide 21

Slide 21 text

カンバンの変化 (1週目)
 confidential チームのタスク以外に個人で請け負っ ているタスクがたくさん合った

Slide 22

Slide 22 text

カンバンの変化 (2週目)
 confidential 振り返りで決めたことを 常に見える所に掲示

Slide 23

Slide 23 text

カンバンの変化 (3週目)
 confidential 社内のリリースフローに合わ せてフェーズを詳細化

Slide 24

Slide 24 text

カンバンの変化 (4週目)
 confidential

Slide 25

Slide 25 text

小さく定期的に出していく意識の醸成
 confidential ● 大きくリリースしようとすると計画が大変になり、開 発が複雑になり、QAが大変になり、障害対応も大 変になる。
 ● 小さく定期的にリリースできれば計画は小さくなり、 開発はシンプルになり、QAはやることが明確で、障 害原因の絞り込みもやりやすい。
 ● 例えば
 ○ ありたい姿→ユーザ導線を改善したい。ペー ジ構成からヘッダからきちんと設計して刷新す る。
 ○ 最初の一歩→あるページに「戻る」リンクをつ けて様子を見る。


Slide 26

Slide 26 text

開発プロセスの改善 まとめ
 confidential ● 【課題感】
 ○ アジャイルを目指したはずが綺麗なウォーターフォール になっている
 ○ 開発着手からリリースまでが長い
 
 ● 【やったこと】
 ○ バックログリファインメントの改善
 ○ 開発プロセスの見える化
 ○ 小さく定期的に出していく意識の醸成
 Photo by Olga Guryanova on Unsplash

Slide 27

Slide 27 text

2. レガシーシステムからの脱却
 confidential 【課題感】
 1. 創業からサービスを支えるPHPモノリス。 
 2. 全体像がわからず、パッチワークがさらなる負債となる。 


Slide 28

Slide 28 text

創業からサービスを支えるPHPモノリス
 confidential 1. サービスの根幹をなす機能が密結合されている。
 2. 正しいビジネスロジックが把握しきれない。
 3. リファクタリング・改善が入れにくい
 Photo by James Hammond on Unsplash

Slide 29

Slide 29 text

レガシーシステムをテコ入れしたポイント
 confidential QA観点で重要なものを抜粋すると
 ● マイクロサービスへの移行
 ● 不要になったコードの削除
 ● ビジネスロジックの整理・簡素化
 Photo by Pranav Kumar Jain on Unsplash

Slide 30

Slide 30 text

PHPのモノリス→マイクロサービスへの移行
 confidential 責務を小さく・明確にし、 リリースしやすくする。 ⇆ 一般的にQAは難しくなる。

Slide 31

Slide 31 text

不要になったコードの削除
 confidential ● 「焼け石に水」→「雨だれ岩を穿つ」
 ○ 不要になった機能の削除
 ○ 実行されないコードを削除
 ○ 不要になったブランチの削除
 ○ 不要になったIssueのクローズ
 ● マイクロサービスへの移行と同じくらいモノリスの弱体化は効果がある。


Slide 32

Slide 32 text

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


Slide 33

Slide 33 text

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


Slide 34

Slide 34 text

レガシーシステムからの脱却 まとめ
 confidential ● 【課題感】
 ○ 創業期を支えたPHPモノリス
 ○ 全体像がわからず、パッチワークがさらなる負債とな る。
 
 ● 【やったこと】
 ○ マイクロサービスへの分割
 ○ 不要になったコードの削除
 ○ ビジネスロジックの整理・簡素化
 Photo by Pranav Kumar Jain on Unsplash

Slide 35

Slide 35 text

3. ドメイン知識の蓄積とQAプロセス改善
 confidential 【課題感】
 1. 仕様の把握に時間が取られ、開発スピードが遅くなる。 
 2. テストで見るべきポイントが曖昧で増えていく一方。 


Slide 36

Slide 36 text

ドメイン知識が蓄積されず、QA改善が進まない
 confidential 1. WF型の開発プロセスで、特定個人に知識が溜まる。
 2. PHPモノリスのあちこちにロジックが分散し、As-Isの把握 すら困難になる。
 3. 上記解決のため、QAプロセスの抜本的な刷新を図るが 頓挫する。
 Photo by Jessica Sysengrath on Unsplash

Slide 37

Slide 37 text

ドメイン知識・QAプロセスをテコ入れしたポイント
 confidential QA観点で重要なものを抜粋すると
 ● 現状QAプロセスの良い点を認識する。
 ● To-Beではなく、As-Isから改善を進める。
 ● テスト観点・仕様の集積場を設ける。
 Photo by Sikai Gu on Unsplash

Slide 38

Slide 38 text

現状QAプロセスの良い点を認識する
 confidential ● 【課題】専門のQA組織・チームが無い
 ○ ✖ QA組織・チームを立ち上げよう
 ○ ○ 組織全体でQAをやっていく機運がある。
 ○ ☆ QA組織・チームが立ち上がっても、「ドメイン知識が不足している」という現 在の問題は改善されないだろう。
 ● 【課題】プランナーがQA項目を考えている
 ○ ✖ QA項目はQAエンジニアが考えてチェックするべき
 ○ ○ プランナーがQA項目を考えることで仕様の矛盾に目が向くようになってい る。ユーザ観点のチェック項目はプランナーが作成し、エンジニアは実装観点 のチェックを実施する。


Slide 39

Slide 39 text

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


Slide 40

Slide 40 text

テスト観点・仕様の集積場を設ける
 confidential 社内Confluenceに集積場を設けた。 ● 問題に気がつくたびに追記する。 ● まずは書き出してもらうことを優先 し、後から整理する。 テスト観点の集積→仕様の集積→テスト 項目の修正 と段階的に進める

Slide 41

Slide 41 text

ドメイン知識の蓄積とQAプロセスの改善 まとめ
 confidential ● 【課題感】
 ○ 仕様の把握に時間が取られ、開発スピードが遅くなる。
 ○ テストで見るべきポイントが曖昧で増えていく一方。
 
 ● 【やったこと】
 ○ 現状プロセスの良い点を認識する。
 ○ To-Beではなく、As-Isから改善を進める。
 ○ テスト観点・仕様の集積場を設ける。
 Photo by Sikai Gu on Unsplash

Slide 42

Slide 42 text

まとめ
 confidential

Slide 43

Slide 43 text

まとめ
 confidential 1. 開発プロセスの改善
 ○ バックログリファインメントの改善
 ○ 開発プロセスの見える化
 ○ 小さく定期的に出していく意識の醸成
 2. レガシーシステムからの脱却
 ○ マイクロサービスへの分割
 ○ 不要になったコードの削除
 ○ ビジネスロジックの整理・簡素化
 3. ドメイン知識の蓄積とQAプロセスの改善
 ○ 現状プロセスの良い点を認識
 ○ To-Beではなく、As-Isから改善を進める
 ○ テスト観点・仕様の集積場を設ける


Slide 44

Slide 44 text

アジャイルな開発をやっていくには
 confidential ● アジャイルは状況変化に機敏に対応していけるという「状 態」である。
 ● 仕組みを導入すればできるものではない。
 ● 組織の文化を変える必要がある。
 Photo by Cara Fuller on Unsplash

Slide 45

Slide 45 text

Rettyは様々なポジションで仲間を募集しています
 confidential Rettyの新たな仲間・募集ポジション一挙公開！ https://note.mu/retty_inc/n/n5bb837354e47 または私までお気軽にご連絡ください。 twitter : @tunepolo mailto: yuichi-tsunematsu@retty.me