本日はQA（品質保証）の専門イベントQuesに参加してまいりました。
atnd.org
2人の方のセッションと懇親会、貴重な話もあり、今関わっているQA界隈のトレンドも知ることができ、有意義な時間になりました。
このブログでよくやってるように、今回も私的な要点など箇条書きいたします。
セッション1 今、QAに求められていること
内容の私的要点
- QAに求められるのは「よりうまく、より早く、より安く」っていうのはずっと変わってきていない
- 最近QAエンジニアにはほとんどエンジニアと同じようなスキルの要求も…
- QA + 「何かのスキル」が大事になっている
- 技術スキル？ プランナーのスキル？ ディレクターのスキル？
- 解決すべき課題は何か > 課題は変化することも踏まえて > 行動につなげるのが大事
- 今求められること
- 課題を発見して解決する力
- テスト以外の専門性
- 変化を楽しもう！
感想
時代とともにできることも増え、求められていることも増えて、さらに今のトレンドはすぐ朽ちる……WEB開発なりはそんなことが多かったりします。
それはQAだから例外ってわけなく、観点や手法も随時ブラッシュアップしていかないといけない。ブラッシュアップってよりもスクラップビルドかもしれないなーと感じました。
ルーチン化は効率化の一つの手法……って気もしてますが、やっぱりそれだけでは…ってことですね。
実行に移すのが大事。
そういえば、「テスト以外の専門性 > たどり着いた先がQAじゃなくても気にしない」について……これは行き着く先が全員が品質意識を持ったチームってことになるのかなとも感じました。
ちょっと責任放棄っぽい言い方ですが、品質ってQA担当に任せられるほど軽いもんでないという認識です。
認識が浅い人ほどQAに丸投げし、深い人ほどそれぞれの持ち場で品質を意識するという傾向もあるのかなと感じてます。
そう考えると、一つのQAの方向性として、意識付けをする人・導く人という立ち位置もありなのかなと思いました。
セッション2 経験ゼロから6年間で学んだ、劇的な変化に順応する品質管理チームの構築方法とは！
内容の私的要点
- この6年くらい、時代の変化によって対応するものも変わってきた時代でした。
- そんな中での0からのQAチームビルディング
- テストに限らず「誰かやってくれないかなー」ってことを業務にしていった
- 当初は数サービスの受け入れテストをするぐらいだったが、最終的には多くの業務、サービスを担当していた
- チームビルドの秘策
- ありきたりな名前じゃないチーム名
- 正社員、委託などの垣根のないフラットな施策
- 決まったフローに浸りすぎない
- インシデントが起こったらいい意味で目立つ組織に
- 細かい繰り返しで会社から信頼される組織になっていった
- 再度QA組織の立ち上げに
- CAPDo(PDCAの起点が違うもの): Check, Act, Plan, Do
感想
「誰かやってくれないかなー」をやるということは結果として品質向上に結びつくことと思ってます。
それによって、いらない手間を省くことができる > 自分の持ち場の領域に集中出来る > 変なものができなくなる
……こんな論法が私の理解です。
あと「ありきたりな名前じゃないチーム名」というのも何気に有効な手段な気がしています。
覚えたての言葉を使えば、そのチーム名が組織内のユキビタス言語になる。
そのチーム名が出れば、「全体的で最終的なテストを行うんだな」という意識が出てくるってことになるのかなと思います。
そういった意味でも信頼が出てきたのではないかと思います。
最後に……まだまだ学ばないといけない事、できるようにならない事は多く……という心持ちではあります。
ただ、「+何か」は何を持つか……これ割と範囲が広くて、興味がありさえすればまず齧ってみていいのかなと思いました。
多分、プログラムとかのエンジニアリングでも、マネージメントでも、統計手法でも、もしかしたらデザインでも……
この場ももちろんですが、広いインプットと、一つ一つのアウトプットを大事に実行していこうと思ってます。
