品質についてイロイロと考える会、その名は"イロカイ"!

社内QAチーム内でイロカイを開催した話

吉田千鶴
WingArc1st Inc.
Dec 22, 2021

--

これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2021、第10弾(2021年12月23日)の投稿です!

お久しぶりの方もはじめましての方も、みなさまこんにちは!
ウイングアーク1stのソフトウェアプロセス&品質改善部 BDQIグループ配下のチームに所属する吉田千鶴(よし)です。今回は社内で品質についてイロイロと考える会、略してイロカイを開催したお話しをしたいと思います。

そうだ、イロカイを開催してみよう!

品質についてイロイロと考える会を開催しよう!と考えたのはちょうど1年前の12月。新しいチームに移動して1年が経ち、そこに所属するメンバーとのやり取りにも慣れてきた辺りで、ふと思いました。
「そういえばプロジェクトの垣根を越えたQAメンバー同士で、品質に関する取り組みの共有や話し合い、あまりできていない気がする……」って。

私の所属するチームでは、QAメンバーそれぞれが異なる製品を担当しています。部門で定めている『カスタマーにプロダクトとサービスを継続的に高品質で提供する』というミッションを理解したうえで、各々が関わるプロジェクトのなかで、開発者たちと連携して品質を評価したり、プロセス改善を推進しています。
製品によって求める特性が異なることから、担当製品ごとに品質のことを考えたり、関連機能の勉強会も行っています。このようにプロジェクト活動の中で、開発サイクルの上流からどうやって品質に寄与するのかを考慮し、協力して活動を行っています(みんなすごい!)。

さて。ではQAメンバー同士の横連携については、どうなっているでしょう。昨年12月の時点で、振り返ってみました。

QAチーム内では、週1で各プロジェクトの進捗報告、顕在化した問題の連絡、製品に依存しない課題の共有を行っています。
またチーム定例とは別に、5分1枠で好きな議題を上げて相談したり、Lightning Talks形式で知識を共有する場も設けています。

しかしこれらの会議では、プロダクト品質の情報共有や課題の議論はされても、各プロジェクトごとに品質を良くするために行っている工夫や改善については、あまり共有されていません。なぜなら製品リリースに直接影響しないプロセスに対する取り組みであったり、既にそのプロジェクト内では” 当たり前“として取り込まれている行動であるために、あえて意識しないと「プロジェクト外メンバーに発信しよう!」という発想がでてこないためです。

せっかく同じQAチームに所属しているメンバー同士、改善活動に対する取り組みを共有したり、品質について話し合える機会があまりないことが勿体ないと考えました。さらに検討段階のアイディアであっても、プロジェクトの垣根を超えた皆で話すことで、新たな発想が生まれる可能性もあると思いました。

プロジェクトに依存せず、品質について興味があるメンバー同士が話し合える場を作りたいと考えて、昨年12月頃からQAチームメンバーに対して「2021年になったらイロカイ(品質についてイロイロと考える会)をしたいなー。品質に関連するテーマについて掘り下げたり、取り組みを共有したり、話し合ったりするの面白くない?」と、アプローチしていました。
その発言がBDQIグループを束ねているJumpei Itoさん の耳にも入り「俺も、ちょうどしたいと思ってた!」と、意気投合。
最初はチーム内だけで実施しようと思っていましたが、グループを巻き込んで開催することに。また「イロカイ」という造語が、そのまま使われることになりました……。

イロカイの主旨

1回目の開催で、イロカイをどのように運営していくかを決めました。

その際、参加者から出た意見で ≪だれもが自由に意見を言えて、相談しやすく、話し合いやすく、チャレンジ可能な場を望む≫という発言が、とても強く記憶に残っています。なるほど!と思いました。
イロカイは、みんなで特定のトピックについて意見を出し合ったり、共有することを重視した会であり、そのトピックに興味があるメンバーが集まる任意参加の場です。主体的に発信したい人もいれば、受け手として理解を深めたい人、課題解決のためのアイディアがほしい人もいるでしょう。
ストレスなく、リラックスした気持ちで、しかし同じ目的を持った有志が前向きにチャレンジできる関係性がベストです。
上記を踏まえて、集まったメンバーでガイドラインを定めたため、参考として掲載します。

1. 目的
品質についてみんなで意見出しをしたい。なぜなら新しいことに常にチャレンジして、変化に対応していくため、皆で考えたいから。

2.スケジュール
各週で1時間 ※トピックがなければスキップ

3.概要
皆で一緒に”考えたい・考えてほしい”ことや、”伝えたい・共有したい”こと、または、自身の中でとどまっているアイディアなどを共有します。
例えば
・経験談を語る
・新しいアイディア持ってる方が、そのアイディアを共有する
・無駄な作業していると思う内容を伝えて、なくす方法を考える
・自身の中で気になっている(もんもんとしてる/止まっている)ことについて、一緒に考える
・一緒に勉強したいものを伝える(その詳細は別日程で実施しても良い)
一緒に皆で考えたいテーマについてお題を出し、皆でディスカッションする(認識をすり合わせる)

4.グランドルール
目的志向で話す
誹謗中傷はしない
個人名は出さない
ヒト・モノ・カネの話はしない
アイディアを出すことを萎縮しない
他人を尊重する・多様性を認める
何でしていないの?といわない(イロカイで出た宿題に対して)

5.トピックだし
品質に関するトピックであれば、何でも大丈夫。
お題は前週までに事前に出しておき、優先度に基づき、どの内容を題材にするか決めます。共有や発信したいだけでなく、受け手として誰かに聞いてみたい/知りたいというトピックも歓迎します。

イロカイで開催したトピックについて

この1年、さまざまなトピックの提案が、メンバーから自主的に出てきたので、ほっとしています。製品をリリースするための活動とは別に、特定のテーマについて考えてみたり、プロジェクトを跨いで情報をすり合わせる機会を望んでいた方も多かったのかな、との印象を持ちました。
ここからは、実際に話し合ったトピックについていくつか抜粋し、振り返りたいと思います。

(参考例)トピックの共有 ※ 前週までに書いておく

1.アジャイルテスティングの4象限

◆Tさんからの議題.
担当製品のテストタイプを、アジャイルテストの4象限にマッピングしてみたい。現状を可視化して、認識のすり合わせを行いたい。
※ 4象限については、こちらのブログが参考になります。

◆イロカイで実践してみた
ということで複数製品で実践してみました。

製品Aの実施例

◆実践してみて分かったこと
いくつかコメントを頂いているので、ここに掲載します。
・偏りや課題が見えてきた。たとえばQ1については開発チームと協力して出来る限り自動化が進んでいる。しかしQ2については「E2Eリグレッションテストは手動と自動に分けられるが、手動の部分は、時間がなくて自動化できないところがあるので課題」があることがわかった。
・ 複数の製品でアウトプットしてみることで、担当製品との違いであったり、どれくらい網羅できているか?を改めて考えることができた。
・ 4象限については実施するタイミングが難しかったので、ちょうどよい機会だった。今回実施したことをベースに、今後の話をしていきたい。

2.品質質分析の仕方について

◆Oさんからの議題.
担当製品で、より効果的に、次に活かす不具合分析をしたいから、相談にのってほしい。基準以外で、各プロジェクトで工夫している分析方法を共有してほしい。

◆イロカイで相談にのってみた
・第三者にプロダクトの妥当性を提示するための品質分析と、プロジェクト期間中に品質向上させる分析は、対象者も内容も異なるから、そこは明確に分けてみてはどうか?
・たとえば製品Cでは「観点の傾向×深刻度、担当者別」などの情報をチャートで可視化している。このグラフは、妥当性の根拠とはならないが発生傾向をつかめるため、開発プロジェクトの中で活用してこそ役に立つ。
・品質向上を目的とした分析を、素早く、的確に行うことを目的としているなら、どのような分析を、どのタイミングで行いたいのかを検討し、基準とは別の軸で検討してみましょう。プロジェクトの重みにもよるけれど、傾向分析による弱点強化なら、週次やリアルタイムもありだと思う。

◆ 実際にアクションしてみた
イロカイ開催後、 開発者へのフィードバックとして週次での品質分析を実行。Oさんによれば、インシデントの内容や対策事項から傾向を洗い出し、品質フィードバックと合わせた提案を短いサイクルで行うようにしたことで、話し合いや共有がよりスムーズに行いやすくなり、プロジェクト内でのカイゼンに繋がっているとのこと。

(参考)分析ボード

3.デリゲーションポーカーの実践について

◆Aさんからの議題.
マニュアルをベースとしたユーザビリティテストの担当として複数製品に携わっている。プロジェクトによって検証担当者が異なるため、それぞれ自分に求めているものが異なっている可能性があり、どこまで動いていいのか不安。製品担当者と意識のすり合わせを行いたい。

◆イロカイで実践してみた
参加者の一人が「デリゲーションポーカーというワークを利用すると、双方の意識のすり合わせが可視化して行えるから便利だよ」と、Aさんに共有してくれました。そして、担当製品ごとにワークを実践しました。
竹原健一郎さんがこの時に実施したデリゲーションポーカーの事例を書いてくれています!よければ一緒にご参照くださいませ。

◆実践してみて分かったこと
少し違った視点からまとめてみます。
今回はデリゲーションポーカーという手法の気づきと、また権限委譲のすり合わせが同時に行えました。議題を上げたAさんだけでなく、この手法を知らなかった他の参加者も学びが得られ、自身のプロジェクトでも活用できる気づきを得られた時間となったと思います。

来年度に向けて

ここまでイロカイの開催目的、主旨、実際に行ったトピックの抜粋を紹介してきましたが、いかがでしたでしょうか。

トピックによっては事前に参加者を確認しておく必要もありますが、とりあえず品質に関わる話であれば何でもOK!のスタンスであるため、ふわっとしたテーマでも議題にあげやすいことがメリットです。

開催当初はチーム内でミニマムに行うことを想定していたのですが、グループに広がったことで、出てくるトピックも多様なもの※となりました。
現在はブレインストーミングや共有・相談としてだけでなく、詳しい人に教えてもらう機会としても活用しています。今後はさらに活動範囲を広げていきたいものです。
※ 最近はメンバーがトピックの事前確認を実施してくれてます(感謝)。

読んでくださった皆様、ありがとうございます。
もしイロカイ(〇〇をテーマにイロイロと考える会)に興味がでましたらご検討頂ければ幸いです。

--

--