QAエンジニア組織立ち上げはじめの一歩

by techtekt

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

⾃⼰紹介名前: 吉次洋毅年齢: 31 お仕事: Salariesの開発・プロジェクトマネジメント QAエンジニア組織の⽴ち上げ経歴: 2014/4〜2016/11 某飲⾷店検索サービスの会社 2016/12〜パーソルキャリア株式会社その他: 個⼈事業主としてベンチャー企業のプロジェクトマネジメントや開発のお⼿伝い趣味: 旅⾏、写真、将棋、ピアノ、カフェ Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

新規サービス開発・グロースにおける品質課題に対する意識 • リリース後のバグ検出頻度の増⼤ – サービスの機能が拡⼤するに従い、システムの複雑度が上がっていく – 影響範囲の特定の難易度アップ、リグレッションテスト等の仕組み未整備（コードの変更に対する後ろ盾が弱い状態） • ドキュメント不全 – 仕様書がない or メンテナンスされてない – いまこうなっている経緯がわからない • リリース前QAの準備におけるエンジニアの負荷 – リリースが近づくと、テストベンダにテストスコープの説明やその使⽤の説明を都度実施 – テストベースを揃えたりコミュニケーションしたり、テスト仕様書のレビューの負荷がが⾼くなっていた Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. 9

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

品質課題のヒアリングと改善施策案の作成 Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. 12 分類課題改善施策案仕様 • 仕様書がない（断⽚的にFigma上に書かれている、誰かの頭の中にある） • 仕様の理解が⼗分でないまま実装が⾏われることがある • 仕様書を作成・メンテナスできる状態を作る実装 • 実装時の確認パターンが網羅できていない（異常系の確認漏れなど） • 品質に対する意識が薄れがち • エンジニアに対する品質に関する基礎知識のインプット • ⼀定レベルでの仕様理解が担保されるプロセス、ルールの整備テスト • リリース前のテスト実施時のインプットが不⾜している（質・量） • エンジニアのテスト実施準備負荷が⾼い • 仕様書の整備、レビュー体制の強化各プロダクトの開発リーダーに品質課題をヒアリングし、組織として解決すべき課題を明確化した。

Slide 13

Slide 13 text

Slide 14

Slide 14 text

仕様書メンテ・リリース前のQAテスト実⾏へのスムーズな移⾏ Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. 14 分類課題改善施策案仕様 • 仕様書がない（断⽚的にFigma上に書かれている、誰かの頭の中にある） • 仕様の理解が⼗分でないまま実装が⾏われることがある • 仕様書を作成・メンテナスできる状態を作る実装 • 実装時の確認パターンが網羅できていない（異常系の確認漏れなど） • 品質に対する意識が薄れがち • エンジニアに対する品質に関する基礎知識のインプット • ⼀定レベルでの仕様理解が担保されるプロセス、ルールの整備テスト • リリース前のテスト実施時のインプットが不⾜している（質・量） • エンジニアのテスト実施準備負荷が⾼い • 仕様書の整備、レビュー体制の強化 ↑まずここをカバーした体制にしたい。とはいえ現状社内にリソースはない…

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

実装⾯でのアプローチ Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. 17 分類課題改善施策案仕様 • 仕様書がない（断⽚的にFigma上に書かれている、誰かの頭の中にある） • 仕様の理解が⼗分でないまま実装が⾏われることがある • 仕様書を作成・メンテナスできる状態を作実装 • 実装時の確認パターンが網羅できていない（異常系の確認漏れなど） • 品質に対する意識が薄れがち • エンジニアに対する品質に関する基礎知識のインプット • ⼀定レベルでの仕様理解が担保されるプロセス、ルールの整備テスト • リリース前のテスト実施時のインプットが不⾜している（質・量） • エンジニアのテスト実施準備負荷が⾼い • 仕様書の整備、レビュー体制の強化 ↑アプリケーションエンジニアに対する実装⾯でのアプローチ。基礎知識のインストールと意識の醸成を狙っていく。

Slide 18

Slide 18 text

Slide 19

Slide 19 text

QA輪読会実施形式の変遷 Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. 19 予習資料作成（発表者）輪読会予習疑問点・議論したいことの共有資料作成（発表者）輪読会 • 章ごとに1サイクル • 以前は横⼀線で予習し、発表者が要約資料を作っていたが、何がポイントなのか掴みづらく、輪読会の中での議論で深みが出なかった • 予習後、疑問点や議論したいことを共有した後、それに基づいて発表者が資料を作成することで、内容が濃くなった改善前改善後

Slide 20

Slide 20 text

Slide 21

Slide 21 text

まとめ Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. 21 • まずはヒアリングして品質課題を明確にする • 明らかになった課題にたいして現実的なアプローチを模索する – 新しく⼈を採れればできること、テストベンダとの協業でできること、すでに組織内にいるメンバーでできることに分けて、⼀つ⼀つ着⼿する • 既存メンバーを巻き込んで組織としての活動に引き上げる • ちなみに、、採⽤難易度は⾼め（後述します） – 課題意識から組織的な活動への昇華、周囲の巻き込み – 「1⼈⽬のQAエンジニア」の採⽤要件の整理の難しさ – 市場にマッチする⼈材が少ない

Slide 22

Slide 22 text

Slide 23

Slide 23 text

1⼈⽬の難しさと中⻑期的な組織デザイン Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. 23 • 1⼈⽬のQAエンジニアの要件を定めるのは難しい – ⾜元の課題解決だけではなく⻑期的な組織づくりに⽬を向けられる⼈である必要がある – よって、採⽤要件が盛り盛りになりがち… – 結果的に超⼈要件になる • 組織づくりの経験、採⽤経験、テスト⾃動化経験、テストマネージャの経験、エンジニアリング知識、多職種との協業経験など… • ロードマップを描く – ⾜元の課題の整理 – 数年単位で考えてどういう状態になっているか、どういう価値提供ができるチームになっているかを描いておく（と⾔いつつ、⾊々試して模索する側⾯も⼤きい。経路までは決めれないが⽬的地・⽅⾓くらいは考える） • 採⽤要件の分解 – どちらかと⾔うとある数年単位のロードマップに要件を寄せつつ、できる限り⾜元の課題をカバーできるようにする – カバーしきれない部分は既存メンバーでカバーできるようにアプローチする結果、なんとか採⽤に漕ぎ着けた︕

Slide 24

Slide 24 text

今後の展望 Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. 24 • ⾃動テストの推進 – E2Eテストツールの導⼊・展開により品質担保しつつ⽣産性を⾼める（QCDの向上） • 既存メンバーの巻き込み – エンジニアに対して品質知識をインストールする活動は、開発組織全体としての⼟台となるので継続する • テストベンダとの連携の強化 – 各プロダクトに⼊ってもらっているテストマネージャの横連携がまだまだこれからなので、連携を強め、プロダクト横断的にベストプラクティスを流通させる • 他部署との連携の強化 – 新規サービス系以外の領域でも同様に品質課題が存在するため、染み出していきより⼤きな価値提供を⽬指す • 組織の拡⼤ – 上記の活動により拡⼤した役割をカバーしきれる体制を採⽤などによって実現する