こんにちは、asatoです。
今日は、僕たちのチームでの取り組みの一つ、デザイナーとQAエンジニアによるストーリーチケットの共同作成についてお話しします。
デザイナーとQAエンジニアでストーリーチケットを作っている
タイトルで完結してしまった。
みなさんのチームでは、誰がプロダクトバックログアイテム（PBI）を作成していますか？ プロダクトマネージャー（PdM）やリードエンジニアのような仕事をしている人が管理しているケースが多いかなと思います。
このチームでは、デザイナーとQAエンジニアが共同でPBIを作成しています。 別に変なことではないのですが、それなりに珍しいケースかもなーということで残しておきます。
毎日ふたりで集まって30分議論する（Pre-Refinement）
特別なことはしていないけど、チームのRefinementのRefinement Readyな状態を目指して毎日30分、少しずつPBIをアップデートしています。 チームではこれとは別にRefinementを毎日30分やってるので、叩き台の準備ができたPBIはRefinementで叩きます。
デザイナーはユーザーストーリー、QAエンジニアは受入基準にオーナーシップを持つ
共同作業としてRefinement Readyを目指しますが、大きくタイトルの通り、オーナーシップは分かれています。 分かれていると言っても、ユーザーストーリーが腑に落ちないと受入基準は明らかにできないですし、受入基準にはUIやUXデザイン的なこだわりが反映されるので、まぁ共同作業ですね。 最後、決め切るのはオーナーシップを持つ側に委ねようという暗黙のルール的なものです。
ユーザーストーリーはよくある「As xxx, I want xxx so that xxx」フォーマットを使っています。 受入基準はGherkin記法をベースにしています。 フォーマットを揃えることで、互いに（他のメンバーも含め）理解しやすく意見しやすい仕掛けを作っています。
PdMはPRDを書いている
チームにはPdMもいます。 PdMはPRDに集中してくれています。 より戦略のところに集中してくれている感じです。
デザイナーとQAエンジニアは適宜PdMをPre-Refinementに招待しています。 PRDの解釈をユーザーストーリーや受入基準という具体で議論するためです。 この辺の取り組みがいいなーって思ってます。
全開発者でユーザーストーリーマッピングしてる
こう話していると、エンジニアがユーザーストーリーや受入基準にタッチできるタイミングが遅いと感じる人もいるかもしれません。 このチームでは、このPre-Refinementの取り組みのさらに前に、PRDからユーザーストーリーマップを作成するアクティビティを開発者一同でやっています。 ので、もっと前から全員が全体像を共有している状況が作れています。Pre-Refinementは具体化の作業って感じです。
実はクロスファンクショナルな取り組みでもある
実はこの取り組みを始める前は、ユーザーストーリーを考えたり受入基準を考えることはPdMやリードエンジニアしかできていませんでした。
個人的には、ユーザーストーリーはデザイナーに持っていてほしい感覚だと思っていましたし、受入基準はQAエンジニアの専門性を活かしてほしいと感じていました。 ユーザーストーリーと受入基準というアジャイル開発の根幹（と勝手に思っている）のクロスファンクショナル化というか、まぁ適材適所的なことがしたかったのも、この取り組みを始めたきっかけです。
全体としてはうまく行ったなーという感覚です。
まずデザイナーは、今まで以上に「誰」や「なぜ」を考える姿勢が増えました。 それについてPdMと議論し合う場面も増えていました。 もちろん今まで通りPdMがオーナーシップを持ち続けたほうが早くはあるのかもしれません。 しかし、他のメンバーをその領域の感性を持つことはチーム全体の議論の質を向上させますし、属人性排除にもなりました。
支援は必須
じゃあやってみましょう！でできるわけもなく、最初のうちは支援が必須です。 この取り組みが何に効くのか、理想的にはどういうチームの形を描いているのかは、それなりに話した気がします。
今回の焦点であるPBIの内容については、ユーザーストーリーも受入基準も型を活用しているので、それなりに支援しやすかったと思います。 ほんと型っていいですね。 しかし、型の形だけ知っていても、自分のアウトプットが型にはめられているかやその型がどう役に立つのかまでは支援や経験、体験が必要です。 型を使ってもらってアウトプットしてもらい、もっとこうすれば型をうまく意図通りに使えるねといったフィードバックをしていました。
最初のうちに口うるさくそういう議論をしていたので、デザイナーとQAエンジニアで互いにそういう指摘ができるようになりました。 これがペアワークの強みですよね。 結果、2人でPre-Refinementが完結できるようになりました。
引き継がれるのは作業ではなくオーナーシップ
特に難しかったのは、自分たちがユーザーストーリーや受入基準のオーナーシップを担うんだというマインドセットを持ってもらうことでした。 当初、これはPdMやソフトウェアエンジニアの仕事を代わりにやっている、という意識が強かったです。 そのため、アウトプットを出しても「PdMに確認してもらわないと」「エンジニアに確認してもらわないと」になっていました。
そこは自分たちがオーナーシップを持ち、説明責任を持ち、「共有します！フィードバックあればお願いします！検討するんで！」のスタンスを持ってもらうまでは、何回も話をしました。 最終的にはPdMとデザイナーで「私はこう思う！」合戦が起きることもあり、にんまりできました。
ゆとりがあったから軌道に乗った
ここまでできたのは、チームにゆとりがあったからです。 ゆとりをつくってくれたといった方がいいのかも。
やはり慣れるまでは、PBIの準備ができていないのでチーム全体でのRefinementをスキップということも多かったです。 それでも耐えられたのは、それまでのPBIの貯金や、技術課題を自ら見つけて対応していたエンジニアたちがつくったゆとりのおかげです。 立ち行かなくなったら私がなんとかするといってなんとかしてったPdMのフォローも助かりました。
こうやって生み出されたゆとりが、あらたな挑戦を可能にして、チームはより強くなるのだと思います。
まとめ
とりとめもなくてごめんなさい。笑
個人的に、ユーザーストーリーと受入基準というデザイナーやQAエンジニアの専門性を活かせるアウトプットが別の誰かの持ち物になりその専門性を発揮できていないのでは、という課題感がありました。 メンバーのWillも合致し、この取り組みができました。
これがグッドプラクティスなのかバッドプラクティスなのかはわかりませんが、少なくとも僕らのチームでは機能しました。 そして、デザイナーとQAエンジニアは、新しい領域への挑戦を楽しんでいました。
もちろん、短期的に見ればこんな実験しないほうが速く開発できます。 でも、チームの属人性排除やクロスファンクショナル化、個人のスキルの向上の面で効いたし、前より強度の増したチームになりました。
これを支えたのはゆとりです。 ゆとりなくして挑戦はできないですねー。 そのゆとりを生み出していたのは、紛れもなくチームメンバーの支援だったと思います。
年の瀬なので、今年のことを徒然なるままに書いてみましたとさ。
