スクラム初心者お悩み相談参加レポート

はじめに

1/28(火)にアジャイルチームを支える会主催の「スクラム初心者お悩み相談」に参加した。（募集サイト）
悩み相談は、参加者の持ち寄ったスクラムの悩み事について、標準５分〜最大２０分で対話するという形式だった。
参加者は８名だった。冒頭のアンケートでスクラム実践前の悩みを抱える３名、スクラム実践中の中身を抱える５名でグループに分かれた。そこへ各２名の相談員の方に参加いただき、計５名のグループと７名のグループで対話をした。
私はスクラム実践前の悩みを抱えるグループに参加した。対話の時間はおよそ１時間で、この間に５個くらいのトピックについて対話をした。
いずれの悩みも共感せざるを得ない悩みで、相談員の方のコメントもとても参考になった。
ここではその中から、私が一番聴きたかった、QAチームとの連携に関する悩み相談と相談結果を共有する。

f:id:sonomirai:20200129091914j:plain:w400 — 私が相談したQAチームとの連携についての悩み

悩み

上記のポストイットを説明する際に、口頭で説明した内容を補足すると、悩みは以下の通り。

初めてのスクラムチーム立ち上げに際し、従来のQAチームとどう連携するか？
- ステークホルダーと連携する場合は、スクラムの説明をすれば大枠ではわかってくれると思うが、普通にスクラムの話をしていても品質の話は出てこないので、QAチームの気になるであろうところを説明できない。。。
- 「スクラムチームとQAチームがうまく協力して品質評価した国内事例」として私が知っている事例だと以下の２つがある。
  - アジャイル開発における富士通ソフトウェア検証の取り組み
  - アジャイル開発における段階的品質の積み上げによる品質保証
  この２つの事例は素晴らしいと思う反面、これが実現できたのはQAチームにアジャイルの有識者がいて、QAチームがスクラムチームに寄り添ってくれたからで、QAチームがアジャイルについて理解がないと、この協力関係を実現するのは困難なのでは？という感触を持っている。。。

相談結果

参加者の方、相談員の方と対話させていただき、自分の中では悩みは解消した。（とりあえず次の一歩を踏み出せそうという感触を持てた。）

対話した内容と、それを受けて考えたことをまとめると以下の通り。

従来のQAチームが何をしているのかを理解することは次の一歩を踏み出すために大事なので、資料を展開してもらうなり、対話をする必要がある。
- QAチームがウォーターフォール案件を見るときにどんな営みをしていたかは、スクラム案件には関係ない気がしており、資料の展開をしてもらう必要はないかと思っていたけど、ウォーターフォール案件のQAで何を担保しようとしていたかを理解することは非常に重要だと、対話を通じて考え直した。
QAチームのメンバ（例えばモチベーションの高い若手など）を自分たちの案件にステークホルダの位置付けでアサインしてもらい、一緒に品質保証に向けた取り組みを進めるのは効果的。（その後スクラム案件が拡大することを見越すと、試験項目の内容を見てもらったり、完了の定義を一緒に検討するのも良さそう。）
QAチームと話す際は、ウォーターフォール案件かスクラム案件かという観点で話す必要はない。「お客様に価値を早く提供するためには、どう連携できるか？」という観点で話をした方が良い。
- 悩みのところに「スクラムの話をしていても品質の話は出てこない」と書いたけど、それは当たり前で、品質保証というもののはウォーターフォールかスクラムかという案件特性とは関係なく守らねばならないものだからだ。なのでQAチームにスクラムの話をしてもあまり意味はない。それより、QAチームがクオリティゲートを設けていることで価値の提供速度が下がってしまうという課題を取り上げて、その課題をどう解決することができるかを話し合ったほうが建設的な議論ができるということだった。めちゃめちゃ納得した。
早い段階で成果物を見せてもらうというのは、QAチームにとっても嫌な話ではない。最後の最後に品質の低い成果物を持ってこられて打つ手なし、となるよりは、早い段階で品質の低い成果物を見て早めにその旨をフィードバックをする営みをしたほうがお互いによい。こういった営みをする時、実はQAチーム側としては対応稼働は従来から増えない。それに対してスクラムチーム側は、QAチーム用の環境を構築してメンテする必要があるので、対応稼働は増えるので、そこはスクラムチームが頑張る。
- このあたりも実践しないとわからない知見だと思う。教えていただけて大変有難かった。

悩み以外の対話内容

上記の悩みに関連して、調査する中で気になったことを２点伺ってみた。

スクラム案件が増えた際にQAチームがボトルネックになる懸念ついて

QAチームがスクラムチームに寄り添う（≒各スクラム案件に担当者をアサインしてサポートする）事例は素晴らしいと思うが、スクラム案件が増えると、QAチーム側がボトルネックになるというリスクはある？
- スクラムチームが成熟して毎回安定した品質の成果物を提供することができるようになった結果、QAチームが「品質保証のために入り込む必要はない、スクラムチームの判断でリリースして問題ない」となった国内事例がある。
  - その事例を踏まえると、QAチームはスクラムチームの立ち上がりの際に寄り添ってサポートして、スクラムチームの十分な成熟を見届けて、QAチームのところから卒業させるような世界観がありうる？
    - これは結構な理想論で、従来型のQAチームがそこまで変われるかは難しいところ。QAチームの営みが従来の品質保証から発展して、QAトレーナーとしてスクラムチームの指導ができるところまで行かないと、この世界観は実現されない。

海外事例について

アジャイル関連の書籍を見ると、基本的にはスクラムチームがリリースの判断をすべきとある。「スクラムチームでリリースの判断ができる」というのは、海外だと元々QAを専門としていたメンバが開発チームの一員となっていて、品質保証に人一倍の責任を持っているから成り立っているのではないか？と仮説を立てたのだが、海外事例などご存知か？
- その側面もあるかもしれないが、大切なのはその場合でもリリース判断しているのは、QAの専門家ではなく、スクラムチームだということ。
  - 質問の背景として、日本の開発現場だと、チームにQAの専門家がいるのではなく、QAの組織が別にあり、そこがリリース判断に関与するので、日本の開発現場って、海外に比べて品質保証の意識が薄いのでは？という仮説を持っている。（この仮説が全くもって違うかもしれない。）そうした時に、品質保証について意識の薄いスクラムチームが「アジャイルだとクオリティゲートは設けず、チームでリリース判断するんですよー。それが普通ですよー。」みたいな形で上位層を言いくるめてリリースして、結果として故障が出て、上位層が「アジャイル駄目じゃん」みたいになってしまわないかという懸念があったので聞いてみた。「アジャイルになってQAチームの役割は変われど、QAチーム自体はなくならないと思う。」とおっしゃっていた相談員の方もおり、自分もそんな気がした。

おわりに

品質保証という難しい悩みについて、相談会でここまで色々な学びを得られるとは思っていなかったので、本当に有難かった。悩み相談にのってくださった相談員、参加者の皆様、ありがとうございました。