天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

Markin' Quality 第6回:POアシストは品質エンジニアの役割なのか・1に参加してきた

markin-quality.connpass.com

イベント概要

以下、connpassのイベントページから引用です。

2022年の初回を飾る第6回目は「POアシスト」がテーマです。品質エンジニアが品質向上のために取れる手立てはテストの他にもいろいろあるわけですが、スクラムでいうPO(プロダクトオーナー)を支援することもその一つです。たとえば、POが作るユーザーストーリーの受入条件を、QA視点から補強して、より不具合の混入しにくい要件にするといったことも考えられるでしょう。また、POの中にはエンジニアリングを背景としてこなかった人も一定数いますから、そうしたPOに、テック系の人々がどういう考え方をするのかを伝えて、チーム内のコミュニケーションを円滑にする、なんてこともできるでしょう。 品質エンジニアができるPOアシストの余地は、実はものすごく広いのではないでしょうか。

そんなわけで今回は、腕利きのプロダクトマネージャー・久津さんと、おなじみmugaさんをお招きして、POやPdMは品質エンジニアに対してどんな期待をしているのか、また品質エンジニアもどういう取り組みができるのか、議論します。正月らしい、賑やかな対談になりますよ!

イベントで話されていて印象的だったこと

受け入れ基準をどこまで書くか

DONEしたかどうかを判断する際、PO(あるいはPdM)が判断する部分とQAが判断する部分の境界が難しいというお話が出ていました。

コミュニケーションを正確に取るためにPOが受け入れ条件を正確に書こうとすると、ほぼテストケースに近い内容を書く必要が出てきてしまい、これだとPOがパンクしてしまって上手くいかなくなるので、どこまでPOで受け入れ条件を書いてどこまでQAや開発者にお任せするかが難しいということです。

久津さんは、最初の方(ドメイン知識がまだあまりない時)は丁寧にフォローをし、次第にフォローの度合を下げていくようなイメージを持っているという話をされていました。

QA視点で何をPOに求めるか

まず、QAがPOに対してなかなか話をしにくいという側面があるということで、ここをまず打破しないといけないのではないかと話がありました。

その上で、以下のような話が挙がっていました。

  • プロダクトを取り巻く環境が分かるようなストーリー(例えば性能要件を考える材料となるユーザが何人くらいいて...のようなPOが描く世界観が記載されているストーリー)が欲しい
  • ユーザーストーリーがあまりにもがちがちに書かれ過ぎているときついので、ユーザーストーリーをほどよく書いて欲しい(そこが難しい所ではあるが...)

なんだかんだコミュニケーションを密に取ることが大事だよね、という話も出ていて、そのために世界観を合わせること、相手が分かる共通用語で話すこと*1を意識するのが重要だと意見も出ていました。

POが生み出すヒエラルキー

プロダクトの方向性を決めるという役割をPOが担っている関係上、POが一番偉い、POの指示に従って仕事をするんだといったヒエラルキー構造ができてしまいがちだということです。

お互いをプロフェッショナルとして対等に扱い、フラットな関係でありたいよねという話が出ていました。

エスチョンアスカー

POアシストとして、クエスチョンアスカー(POに問いかけを投げかけることによって意思決定の質を高める)としての役割をQAが果たせるとよいのではないかという話がありました。

POやチームの中で会話が足りていないような質問をQAがすることができれば非常に価値が高い一方で、「そもそもこれはどうやったら作れるんですか?」「どんな仕様が正しいんですか?」といった質問があまりにも頻繁に出てしまうのでは、クエスチョンアスカーとしてQAが機能している以前の問題だよね(コミュニケーションが足りていないだけの可能性がある)、という話が挙がっていました。

QAがPOにコミュニケーションの取りにくさを感じる時はいつか?それはなぜか?

Outlookの予定がぱんぱんに埋まっている時は、忙しい所に仕事を放り込んでもなあ...と思っている時はなかなかコミュニケーションを取りにくいという話が挙がっていました。

イベント全体を通した感想

PO×QAというコラボをしているイベントはこれまで少ない印象だったので、出てくる話の観点で新規性を自分にとって感じられるものが結構多く、楽しかったです。

想像以上にリアルな話が聴けて満足でした。

*1:例えば技術的な課題をそのままQAからPOに伝えても伝わらないことが多い