Slide 1

Slide 1 text

戦う 兵站部隊で 品質保証 を 勝ち取る ー 僕が追求する QA (Quality Assurance) 2020-07-21 @ 吉祥寺.pm23 まみー (@mamy1326) / Lancers

Slide 2

Slide 2 text

Twitter Work Like ✔ 2017年の趣味:MySQL ✔ 2018年の趣味:DNS ✔ 2020年の趣味:CakePHP4 :@mamy1326(まみー) :Lancers,Inc. @ PHPer :cune.jp 自己紹介 2

Slide 3

Slide 3 text

✔ リファクタリング したい   →事業優先・予算の都合で手が出せない… ✔ 品質 を上げたい   →開発速度低下、データの劣化、etc… ✔ 経営層を納得 させたい   →メリデメを数値で示したいが… こんな悩みありませんか? 3

Slide 4

Slide 4 text

僕も 似たような 悩み があります 4

Slide 5

Slide 5 text

✔ 品質保証に課題 がある   ・レガシー脱却したい   ・運用しんどい   ・チーム連携をもっと密にしたい ✔ QA (Quality Assurance) って?   ・品質保証って範囲広くない?   ・各社でやってること違くない?   ・テストを徹底すればいいの? 想定オーディエンス 5

Slide 6

Slide 6 text

こんな 疑問 と 僕なりに 向き合った 半年の話をします 6

Slide 7

Slide 7 text

一般的な QA とは ✔ 開発段階での仕様の確認・評価 ✔ テストケースの設計・実行 ✔ テスト結果と不具合分析 ✔ テスト自動化 ✔ 開発プロセスの見直し ✔ チーム横断で品質マネジメント 7

Slide 8

Slide 8 text

一般的な QA とは ✔ 開発段階での仕様の確認・評価 ✔ テストケースの設計・実行 ✔ テスト結果と不具合分析 ✔ テスト自動化 ✔ 開発プロセスの見直し ✔ チーム横断で品質マネジメント 8 ちょっと待って!

Slide 9

Slide 9 text

一般的な QA とは ✔ 開発段階での仕様の確認・評価 ✔ テストケースの設計・実行 ✔ テスト結果と不具合分析 ✔ テスト自動化 ✔ 開発プロセスの見直し ✔ チーム横断で品質マネジメント 9 全ての組織・ サービスに 同じこと言える?

Slide 10

Slide 10 text

一般的な QA とは ✔ 開発段階での仕様の確認・評価 ✔ テストケースの設計・実行 ✔ テスト結果と不具合分析 ✔ テスト自動化 ✔ 開発プロセスの見直し ✔ チーム横断で品質マネジメント 10 段階が あるよね

Slide 11

Slide 11 text

じゃあ サービスの 段階とは 11

Slide 12

Slide 12 text

1 → 100 サービスが 軌道に乗る ✔ パフォーマンスが気になり始める   →想定のトラフィックを超え始める ✔ インフラ増強を考え始める   →インスタンスを大きくしてみようか アプリもデータも まだ大丈夫 12

Slide 13

Slide 13 text

100 → 10000 サービスで 利益が出る ✔ 人員拡大を進める   →チームで役割分担を考え始める。開発・SRE・etc ✔ 重たい処理が出始める   →サーバーの台数が増えていく データ量が問題 になってくる 13

Slide 14

Slide 14 text

10000 → 1000000 サービスが 社会に影響 を与える ✔ 事業が多角化する   →サービスの種類が増える。チームがさらに分かれる ✔ システムの問題が見過ごせなくなる   →データ肥大化によるスロークエリ、処理の複雑さ、etc リファクタリング が必要になる 14

Slide 15

Slide 15 text

10000 → 1000000 サービスが 社会に影響 を与える ✔ 事業が多角化する   →サービスの種類が増える。チームがさらに分かれる ✔ システムの問題が見過ごせなくなる   →データ肥大化によるスロークエリ、処理の複雑さ、etc リファクタリング が必要になる 15 この段階の お話をします

Slide 16

Slide 16 text

起きていたこと - 1 / 2 ✔ コードに無理 が生じている   →10年以上戦い肥大化 ✔ バージョンアップが 困難 に   →FW含め、新しい技術の追従が遅れる 16

Slide 17

Slide 17 text

起きていたこと - 2 / 2 ✔ スロークエリ 多発   →想定しなかったデータの肥大化 ✔ 役割ごとのチームに 距離 が   →なんとなく齟齬を感じる 17

Slide 18

Slide 18 text

誰もが通る道 でも… 18

Slide 19

Slide 19 text

乗り越えるには 覚悟 が必要 19

Slide 20

Slide 20 text

覚悟すること - 1 / 2 事業拡大の 痛み を ポジティブ に ✔ 役割分担=᫁轢・摩擦は当たり前   →事業・サービスの成長痛 ✔ 摩擦はコミュニケーションのチャンス   →迂回すればするほど痛みだけが増していく 問題の顕在化=改善のチャンス! 20

Slide 21

Slide 21 text

覚悟すること - 2 / 2 道具 (FW) に 熟達する ✔ 武器を誰よりも良く知る   →選択した技術を突き詰める ✔ 最新に追従   →常に更新し、自分たちも変化を続ける 変化の積み重ね=開発効率の維持 21

Slide 22

Slide 22 text

22 常に 変化し続ける 覚悟

Slide 23

Slide 23 text

23 変化し続ける = 品質保証

Slide 24

Slide 24 text

品質保証に必要なこと - 1 / 2 ✔ 戦略的に考える   ・両輪:[戦闘] 事業拡大 + [兵站] 後ろ支え   ・勝利のない戦闘に補給無用   ・補給のない戦闘に勝利なし ✔ 事業拡大の先が本番   ・戦って得たモノを 盤石化・維持発展   ・本当の意味で勝利 24

Slide 25

Slide 25 text

品質保証に必要なこと - 2 / 2 ✔ 第一線での戦闘力=開発力   ・継続した 武器の熟練、最新への追従   ・アプリ・インフラ・RDB を၆ᛌ ✔ チーム同士の連携   ・役割分担=チーム   ・結果ベースで信頼、妥協のない相互理解 25

Slide 26

Slide 26 text

26 必要なことを 踏まえて…

Slide 27

Slide 27 text

27 僕が考える 最強の QA

Slide 28

Slide 28 text

僕が考える最強の QA - 1 / 2 戦う兵站部隊 ✔ 最前線でも戦える戦闘力を持つ   →技術者として最強を目指し続ける ✔ 変化への柔軟さを維持   →最新への追従を続ける 戦って品質保証を 勝ち取る 28

Slide 29

Slide 29 text

僕が考える最強の QA - 2 / 2 フェーズ に合わせる ✔ 組織・サービスは変化し続ける   →フェーズを意識し目標を合わせる ✔ 現状に満足しない   →地道で確実なチャレンジを積み重ねる 多彩な戦略 を選択可能にする 29

Slide 30

Slide 30 text

終わりに ✔ 品質とは 永遠の課題 ✔ 現状に満足したら死 ✔ コスト計算とメリデメを明確に ✔ 楽しく品質保証 ✔ 地道な改善・確実な追求 30

Slide 31

Slide 31 text

575 品質は 歴史という名の ノウハウだ 31

Slide 32

Slide 32 text

しっかり 地面を見定めて 32

Slide 33

Slide 33 text

蓄積された 業務・実装を 33

Slide 34

Slide 34 text

歴史という名の ノウハウに していきましょう! 34

Slide 35

Slide 35 text

35

Slide 36

Slide 36 text

最強のQA #424242 #F0F0F0 #E6855E #5EC84E #F0F0F0  あいうえおかきくけこさしすせそ #E6855E   あいうえおかきくけこさしすせそ #5EC84E  あいうえおかきくけこさしすせそ