メンバー全員にプロダクトの品質責任があるWhole-Team　現場で起きた品質問題のトラブルを改善

自己紹介と本日のテーマの背景

伊藤潤平氏（以下、伊藤）：私のテーマは『品質問題から始まったWhole-TeamアプローチとAgile Testingマインドセットの改善物語』。相当長いテーマですが、この1年間いろいろな学びがあったので、その事例みたいな感じで発表できればと思います。

まずは会社の紹介ですが、弊社は今国内に8拠点あり、海外にも4拠点あります。私はふだん新潟のオフィスに在籍しています。在籍と言っても今は完全にリモートワークなので、新潟から来ています。

弊社には、帳票とか文書の管理ソリューション事業があります。ここにSVFやSPAという製品があって、私はQAとしてこの分野の製品を担当しています。

データエンパワーメントソリューション事業もあり、ビジネスインテリジェント分野の製品があります。Dr.SumやMotionBoardといった製品です。

ということで、あらためまして、私はウイングアーク１ｓｔ株式会社の伊藤潤平と言います。今十数年帳票関連のソフトウェア品質保証を担当しています。あと、社外活動もいろいろやっています。

ここ1年の社外活動をちょっと紹介したいと思います。スクラムフェス大阪2020。確か2020年の6月くらいだったと思いますが、完全オンラインで12トラックくらいあって、いろいろな地域のコミュニティがそのトラックに参加していました。

私は新潟のトラックオーナーとして、このスクラムフェス大阪に参加しました。古いのですが、そこで2011年のAgile Testing Daysというカンファレンスのキーノートが動画であって。そこでジャネットとリサが自分たちの書籍について何があったかという話をしていたので、それに対して字幕翻訳を付けて、スクラムフェス大阪で映像を流しました。

「とやのガッター」というコミュニティがあって、私はここのファウンダーなんですけれど。新潟のエンジニアを元気にさせようということで、COVID-19の影響がない時代は、新潟のエンジニアが居酒屋を貸し切って集まり、みんなでLTしまくるようなコミュニティでした。今はもう完全オンラインなので、新潟にかかわらず、いろいろ募集しました。

何をやったかと言うと、ゴイコ・アジッチさんという著名人がいて。実例型仕様、『Specification by Example』や『IMPACT MAPPING』などで有名な方です。この方も2011年のAgile Testing Daysでキーノートをやっていたので、これを翻訳してとやのガッターで映像を流して、参加者みんなにレビューしてもらった感じです。

そんな活動をして、ジャネットとリサの動画やゴイコの動画を日本語字幕をつけて、本家のAgile Testing Daysに送ったら、Keynotes in Japaneseという日本語のプレイリストを作ってくれました。そこに動画が入っているので、興味ある方はぜひ見てみてください。けっこうおもしろいと思っています。

最近、RSGT2021でジャネットがキーノートをしていました。これも私が日本語字幕をして、見られる状態になっているので、ぜひ見てほしいと思います。

ここ1年、研修でいろいろ行っていますが、すごく学びになった研修が、アギレルゴコンサルティングさんでやっていた、ジェームス・コプリエンさんのプロダクトオーナー研修です。

2021年3月くらいに、これまたアギレルゴコンサルティングさんで、我々はもうジャネット先生と言っていいますが、そのジャネット先生のAgile Testing for the Whole Teamという初のAgile Testingの研修を受けました。その時知り合った方々とは、今でも連絡を取り合っていて、すごく難しかったけど楽しかった研修です。

ということで、この1年を通していろいろな学びがありました。なのでその内容、品質問題から始まったWhole-TeamアプローチとAgile Testingマインドセットの改善物語をテーマに、発表します。

今日伝えたいことなんですが、私の話はほんの事例です。すごい話ではなく、本当に現場で起こっていることを伝えられる範囲で伝えたいと思っています。

Whole-Teamとはなにか？

Whole-Teamは何か？　みなさんわかりますかね？　『Agile Testing Condensed』という本があり、ここで提唱しているのが、whoever you need to deliver the productです。Whole-Team Approachも提唱していて。all team members are responsible for the quality of their product。

つまり何が言いたいかと言うと、Whole-Teamというのは、プロダクトをデリバリーする際に関連する人、メンバー全員がWhole-Teamという言い方をしています。このWhole-Teamのメンバーは、全員がプロダクトに対する品質に責任があるというアプローチです。これがWhole-Teamアプローチ。

私は研修などでいろいろな学びを受けて、この考えはすばらしいと思っています。QAの業界に入って十数年が経ちますが、なにかバグがあると全部QAのせい、みたいなところで育ってきて。なんかやるせない、モヤモヤ感たっぷりな環境でした。

ただ、やはりデリバリーに関連する人間全員が品質に対する責任があって、品質にフォーカスした開発をするのがAgile Testingだという話を聞いて、すごく「これなんだ」と思っています。

Whole-TeamとAgile Testing

ちょっと先走っちゃいました。私はよく「Agile Testingって何？」と聞かれることがあります。私はいつも「Agile Testingは、テスト活動やテストフェーズではなく、マインドセットだ」という説明をしています。

ジャネット先生の資料に（スライドを示し）左の図のような資料がよく載っていますが、Functional Teamsというものがあります。ドメインエキスパート（ビジネスサイド、POなど）や、プログラマーや、テスターがサイロ化されていたりします。Whole-Teamはチーム全体なので、そこに壁はない。障壁を取っ払ってみんなが一緒です、という考え方です。

そうすると、誰もがビジネスを理解しなきゃいけないし、誰もが品質に対してフォーカスした開発をするような現象になります。それがAgile Testingマインドセット、Agile Testingの本質だと思っています。

モヤモヤのなかで起きた品質問題

自分のことを振り返ると、私は6つのプロダクトやサービスのQAを担当しています。その中でテスト自動化やCI/CDパイプラインなど、プラクティスはいろいろやっていますが、やはりサイロ化されているのがわかるんですよね。なんか離れている。

開発から言うと、QAの人がテスト自動化とかを勝手にやっている、と言うと変ですが、「あっちに任せりゃいいよね」状態になっているんです。

プラクティスばかりやってはいるけど、今みたいにWhole-TeamアプローチやAgile Testingマインドセットが現場にはないなぁ、そういう本質がぜんぜん足りていない。プラクティスばっかりになっていました。

ゴイコさんもやはり「原理原則を理解しないとプラクティスはやっても意味がない」ということをはっきりと言っていて。すごくモヤモヤ感たっぷりな状態だったんですね。

ただやはり神様はしっかり見ている。そんなモヤモヤしている私に対してミッションを与えてくれました。ここから物語が始まります。

ある時、お客さまが怒っていました。品質の話を語れる人に来てくれと言っていると。だから一緒に謝りに行こうと言われたことがありました。

いろいろ話を聞くと、ウイングアークではなく、関連する会社のお客さまが怒っている状況でした。私はウイングアークのQA担当として、その関連会社に入っていき、なんとかこの問題を解決するような話になりました。

この関連会社のプロジェクトの現場は、ざっくりとシンプルに図に表すとスライドのような感じで、BIの開発チームやアプリの開発チーム、それから運用チーム、サポートチームという4つのチームに分かれていて。大きくBIの開発チームとアプリの開発チームの現場がありました。

BIの開発は開発者が2名でしたが、テスト要員として運用チームやサポートチームから人を借りることをやっていて。アプリチームは、製品が違うので独自のチームでやっていて。ここには開発者2名とテスター2名がいました。

ということで、私はQA担当としてプロダクトマネージャーをはじめ、全部のチームの中に入っていきました。

次のBuild the Trustは、信頼関係の構築という意味なんですけれども、実はウイングアークのコアバリューにも、Build the Trustという言葉があります。信頼関係の構築というより、もっと相手の期待を超える結果を出して信頼されるという意味で、我々社員はみんなこの言葉を使っています。

そういうわけで、さっそくお客さまのところへ行きました。お客さまが何を言っていたかというと、至極真っ当な話でした。「システムなので不具合があることは理解している。不具合がないわけはないことはわかっているが、ただ、あまりにも軽微なバグが多くないですか」と。「本当にテストしていますか？」という話をされました。

いろいろ話を聞くと、要は社内からの問い合わせが多くて。担当者がほぼデバッカーになっていて、本業ができていないという話でした。よりよいサービス運用をするためにどうすればいいか一緒に考えようという。最後は、品質の相談みたいな感じになっていました。

私は「これから品質改善プロジェクトを立ち上げて、月に1回定例報告にお伺いして説明しますので、しばらくはお付き合いください」みたいな話をしました。

次はプロダクトマネージャーです。このプロダクトマネージャーは営業やプロダクトオーナーも兼ねているし、いろいろな役割を兼ねたプロダクトマネージャーです。お客さまの温度感は理解していると。現場のチームの品質問題も理解していて、みんな品質問題を抱えている感じです。

QAとしてプロジェクトに入って、この品質問題を一つひとつ解決してほしい。最終的には組織全体にQAを推進してほしいというオーダーをもらいました。私は最初、「QA監査としてプロジェクトに入ります」と言っていました。まずはメンバー全員と1on1をして、心理的に安全な場づくりをしたいという話をしていました。

続いてBIの開発チームです。このBI製品がいろいろ問題を起こしていたんですが。開発のメンバーは、「ユーザーの要望をスピーディに構築して、早く使ってもらいたかった」と。「なので自分たちは、プロトタイプ開発のつもりで制作して、テストはやっていない」と話していました。

なぜテストをやっていないかというと、時間がないから。ただ、やはりテストはやって品質を上げたいという思いはある。要は、テストのやり方がそこまでわかっていない状態でした。

そのため、私はまず朝会を始めてデイリーミーティングをやり、全員が共通認識を持つまで話し合いましょうとなりました。その中でカスタマーエクスペリエンスについて一緒に考えていきましょう、という話をしました。

アプリの開発チームです。アプリの開発チームはちょっと文化が違うところで、チームのリーダーと話すと、お客さまの温度感は理解しているけど、メンバーには開発に集中してほしいので、あまり伝えていないと言うのです。

品質は良くしたいけれども、これまでどおりの開発もしたい。ちょっとサイロを感じるような会話をしました。つまり、あまり私に入ってほしくないみたいな。そんなイメージだったんです。

私は「わかりました」と。「メンバーと共通認識を取りたいので、毎日のミーティングが難しかったら、ウィークリーミーティングをさせてください」ということで、オーケーをもらいました。

これは私の頭の中のイメージです。怒っているお客さまがいて、BIの開発チームとアプリの開発チームがあって、それぞれ壁を感じるな、というイメージでした。

プロジェクト始動に伴う2つの失敗談

まずテストの自動化で失敗談があります。いろいろな人と会話していて「自動化はやっていますか？」と言ったら、ほぼやっていない。やっていてもバックエンドの単体テストを回しているくらいのテストでした。

そこで、「じゃあテスト自動化をやりましょうよ」と言い、「DBがあって、テストツールがあって、このくらいのインスタンスを立ち上げて…」などといろいろ言っていたら、「どれだけお金をかけるんだ」と。「コストがかかりすぎるので、それは勘弁してくれ」とけっこう怒られたんですね。なので、テスト自動化の話は一回やめて、話を先に進めるようなことをしました。

あと、先ほどプロダクトマネージャーにQA監査として入ると言っていましたが、「“監査”という言葉には監視されているイメージがある」みたいな話があって。「QAからすごい人が来て、監視してとやかく言われるんじゃないか」といった、そんなイメージがあるという話がありました（笑）。

そこで、このQA監査という言葉をやめ、QAコーチということにして、現場に一緒に入って品質を作り上げていこう、という話にしました。

いよいよ始動です。幸いなことに、私にはけっこう優秀なメンバーがたくさんいて、その中でも生え抜きのYさんとWさんをそれぞれBIチームとアプリチームにアサインしました。BIチームはデイリーミーティングを始め、アプリチームに関しては週次のミーティングを始めました。

（次回につづく）