カオナビQAエンジニアによる『より早く品質を届けるために開発チームみんなで品質について対話した話』
本記事は、kaonavi Tech Talk #17 〜 カオナビの"カイゼン戦略" 〜内のトークセッションの文字起こしです。弊社QCの赤﨑と業務委託で参画中の岩壁さん・木原さんが、開発チームで品質について真剣に向き合った内容を話しました。
kaonavi Tech Talk #17についてはこちらの記事にもまとまっておりますので是非ご覧ください。
赤﨑: 私たちからは、「より早く品質を届けるために開発チームみんなで品質について対話しよう」というテーマでお話しさせていただきます。
はい、タイトル通りなんですが、今日のお話は開発チームみんなで品質についての対話機会を増やすという取り組みを行ってみたので、その利点について説明できればと思っています。
では、話の流れはこのような形で進めさせていただきます。
まず初めに自己紹介からさせていただきます。
私、赤﨑光と申します。株式会社カオナビでQCとしてテスト活動を行っております。マイブームははビールを飲むことと、最近は七輪でお酒のつまみを焼くことにハマっています。最近は良い感じの火をつくるのがうまくなってきました。よろしくお願いします。
岩壁さん: 私は岩壁亜利依と申します。株式会社カオナビには2021年からSESとして所属しています。職種はQCで、赤﨑さんや木原さんと一緒に業務に従事しております。マイブームはウィスキーと、Alexaとおしゃべりと書いてますが、Alexaの鼻歌がすごく好きなので、皆さんもAlexaに「鼻歌を歌ってみて」なんてちょっと聞いてみると楽しいと思います。以上です。よろしくお願いします。
木原さん: 赤﨑さん、岩壁さんと同じチームにSESとしてカオナビに所属しています、木原です。今一緒に映っているのはペキニーズのキクラゲになります。いつも仕事中はちょっと豪快にいびきをかいて邪魔しているのですが、今日は起きていてもらっています。マイブームはトマトサワーと今炭酸水を飲むことにハマっておりまして、つい先日スマホゲームでちょっと欲しいキャラに課金をしてしまいまして、1回5400円、ちょっと高いのか安いのか。。。はい、そんな感じです、よろしくお願いします。
赤﨑: 今日はこの3人でこのテーマについてお話しさせていただきます。
よろしくお願いします。
対話を増やす前のチーム状況
では、まずはじめに、対話を増やす前までのチームの状況について簡単に説明できればと思います。
例えば、こういったテキストフィールドに関するテスト中に半角文字をたくさん入力すると、テキストフィールドを突き抜けるような不具合をQCが検知しまして、起票後に修正が必要というのを開発チームに伝えたところ、「そんなにたくさん半角文字だけ入力するようなフィールドじゃなくない？」とか、「本当にそれ対応必要かな？」といった声がPOやエンジニアから上がりました。
正直、起票前にそんなやり取りが発生すると微塵も思っていなかったので、「えっ、不具合なのに対応不要なの！？」と驚いてしまうみたいな、そういった場面が何度かありました。
また、別件ですが、次に控えているアップロード機能に関する要件が固まってきて、デザインもできてきて、その内容についてレビューをしている際に「そういった懸念がありますか？」みたいな話の中で、特に懸念なく「いい感じだね」「いけそうだね」みたいな話をしていたんですが、いざ実装やテストのイメージをエンジニアやQCで考え始めてみると、やっぱりどうしても実際の機能の触り方、利用者がどう触るのかみたいなのを確かめながら既存の機能で類似した機能とかを触りながら確かめたりとかするので、そういう中で「この機能を使ってアップロードするのは使用性的にも性能的にも難しすぎてちょっと誰もアップロードできないのでは？」みたいな不安の声が上がるようになりました。
ただ、デザイナーとしても「これまでのカオナビの仕様との整合性は取れているので使えそうだけどな」といった形で意見が割れるような場面がありました。
で、懸念払拭のためのミーティングをその後2回経て、方針が確定するといったことがありました。
対話の必要性に対する気づき
こういう状況を見ているうちに、「これは放置しているとまずいかも」と漠然と思うようになっていきました。
品質に関する認識のズレがあること自体は自然なことだと思うんですが、ただそれが良くない形で発覚しているなという印象で、認識のズレをいい形で発見できないかなとモヤモヤと思うようになりました。
ただ、「いい形でって何だ？わからん」てなって答えは見つからなかったんですが、そもそもみんな品質についてどう考えているんだろう、どう認識しているんだろうというのが気になるようになりました。
そこで、それを知るために対話機会を増やせないかというのを考えるようになりました。
そして、対話機会を増やしてみたというところになります。
ここから、いろんな対話機会を増やしてみたものがこちらになるんですが、今日はこの黄色のハイライトをしている1から4までの紹介をできればと思っています。
作ったものを触る会
まずはじめに、作ったものを触る会から、岩壁さんお願いします。
岩壁さん: 1つ目、作ったものを触る会についてご紹介します。
こちらは対話機会を増やすぞという開発チームの取り組みの中でも、一番最初に始まったものです。
今現在も開発チームで定期的に開催されている重要かつ主要なイベントと認識しています。
このイベントは表示されているスライドのように、開発チームの中のQCエンジニアのちょっとした提案から始まりました。
開発したものユーザー視点を持って触ることで気づきを会得
こちら趣旨としてはリリース前ですね、現在自分たちが開発しているプロダクトをみんなで触ってみようという、タイトルままのものですね。
この会に参加をしたら全員で通話をつないで、チャットに少しでも気になったこと、気がついたことは何でも書き残していきました。
内容としては動作の遅さや、「やたらもさりしているよね」とか「一度入力した値が保持されたままなら使いやすいのにね」とか使用感、あとは「そもそも仕様ってこれで正しいんだっけ？」なんて質問とか、本当に何でもありました。
実際その回にはプロダクトオーナーとか実装したエンジニアも同席していたので、その場で改修するかの判断とか、改善するならこういう方法がいいよね、なんてアイデアがでたりとか、結構本当にコミュニケーションが多い場になっていました。
会議によっては全員で操作するとデータの不整合が起こっちゃって全然できなくなっちゃうようなケースもあったので、そういった場合には画面共有をして操作を行うドライバーを1名と、ドライバーに指示をするナビゲーターを1名選出して、操作している場を他の全員は眺めて同じようにチャットに気づいたことを記載していくっていう方式で進めていました。
こんな感じですね。
改善を行いながら品質への意識を向上
作ったものを触る会はだいたい1年ぐらい、1年以上続けているのですけども、やっぱり途中途中で内容を変える、いわゆる味変しながら続けていました。
中では過去の不具合の出た場所を、条件や要素を変えてテストしたり、触っていったり、あるいは、カオナビが提供しているユーザーマニュアルに沿って、操作していったりとかですかね。
あとは、デジタル庁が公開しているウェブアクセシビリティガイドラインに沿って操作したりも行っていました。
過去不具合の出た場所をいじめたりとかは、この『ソフトウェアの品質を学びまくる』、のツアーの中から『ガイドバックツアー』や『嫌な隣町ツアー』から選出して実施していました。
これら作ったものを触る会通してきて、最後どうなったのかというと、これから自分たちが作っていく機能やプロダクトに関するもっと品質について会話したいとか、デザインについてもっと話したいなんて交流を希望する声が上がるようになりました。
利用者のペインを体感してみる会
これから2つ目ですね。
利用者のペインを体感してみる会ですね。
こちらについてはスライドをお願いします。
ペインを体感してみる会なんですけども、仕様策定とかデザインがまだ未着手の段階で開催されました。
そこらへんが未着手なんですけども、見えてるのは利用者のペインだけが見えてる状態ですね。
利用者がペインを感じているってことはじゃあ、カオナビが提供している既存の機能を使って、実際に僕たちもやってみようということで開催されました。
利用したデータは、実データにできるだけ近いデータと環境ですね。こちらで実施しました。
こちら、実際開催したところ、まず「普通に辛い」辛いものだとカオナビだとCSV一個で回してるのかなって思ったら、実際のデータいただいたらCSV3つ用意されていて、その中の特定のセルをガッチャンコしてアップロード用に整形するとかいうので、「実際のデータって結構複雑じゃん」っていうのでみんな痛みを覚えて、過去一番人気の会になっています。
実際に利用者との交流が必要という気づき
こちらでペインを体感してみる会なんですけども、振り返ってみると普段テストケースの実装とかで利用者の目線はどうかなとは考えたりすると思うんですけども、実際のところ「利用者との交流が少ないと、利用者の視点を持つのは難しいんだね」っていうことが分かりました。以上です。
品質の理想像を描く会
木原さん: 次は自分たちが作る製品に期待する品質に対する会話機会を開いた話をしたいと思います。
ここでは作った機能や作る機能など、製品を触るというものではなくて、チームのみんなが自分たちの作る製品に期待する品質を言語化して擦り合わせる、その名も「品質の理想像を描く会」を開催しました。
「品質の理想像を描く会」では、期待する品質について付箋に書き出して貼ってもらい、その品質や価値を測定するための指標を選択していきました。これは「品質ピラミッド」という「ソフトウェアテストを改善する50のアイデア」という本にも出てきたもので、このようなマズローの5段階欲求のピラミッドのようなものを品質の概念に当てはめたものに、メンバーの考える品質や価値を付箋に書き出して貼ってもらい、チーム全体で品質に関する共通の合意のピラミッドを完成させました。
実際、実施した背景としては、これは自分たちのチームの理想像を明確にする取り組みを実施している時期があって、せっかくなので品質を規定に自分たちのチームの作るアウトプットの理想像も明確になると、より向かう先の共通認識もできて、相乗効果が期待できるんじゃないかなと思って開催しました。
開発者の品質に対する意識が向上
みんながそれぞれ大事にしたい品質や目指している品質があることが知れて、「自分の頭の中にある品質は一部でしかなかったな」っていうのがこれで知れました。
また他のメンバーの考えている作り込もうとしている品質がたくさんあることを知る機会になって、私たちが作る製品に期待する品質に対してのチーム全体の意識が高まりました。
より一層このQCとしてはフィードバックの幅が広がったのはすごい効果が大きかったなと思っています。
対話によりチームの一体感を獲得
次は開発タスクの中で対話を増やしたっていう話になります。
以前からリファイメントやプランニングで実装することや実装方針についての対話は、開発チームみんなで実施していて、QCとしてもテストを考えやすくなるメリットをすごく感じていました。
なので、テストについてもチームのみんなで対話しながら考えるのは良さそう、有効だと考えました。
「実装の話もテストの話も一緒にしたい」と思い、エンジニアと一緒に受け入れ基準の補完、テスト分析、テスト設計の方針決めを開始しました。
やり方としては、スプリント初期の段階でエンジニアとQCみんなで受け入れ基準を見ながら、何をテストするのか、どうテストするのかを洗い出して考えるようになりました。
一緒にテスト分析することで得られたのが、テストケースを見て初めて気づく正しい振る舞いの認識齟齬に早めに気づくことができたり、テストと実装が少し融合される形になるので、チームみんなで一緒に製品を作ってるという実感が持てて、より一層前向きに仕事ができてるなと実感できました。
対話を増やして良かったこと
赤﨑: では最後に対話を増やして良かったことをお話しできればと思います。
今までお話ししたように、各対話機会の中で良かったことっていうのはそれぞれにもあるんですが、ここでは共通して良かったことについてお話しできればと思います。
品質に関する認識齟齬は対話から発見
まず1つ目が、品質に関する認識齟齬が開発タスクの遂行を通じてではなく、対話を通じて明らかになっていきました。
そうすると、認識齟齬が開発タスクの遅れに直結しない分、認識を無理に一致させようとしたり、ストレスを感じたまま開発タスクを進める可能性を減らすことができて、認識齟齬をより前向きに、例えば多様性として受け止められるようなメリットがあるかなと思います。
また、品質に関する認識齟齬が開発タスクではないところで明らかになっていくので、開発タスクの中で発覚するようなリスクも低減しているのかなと思います。
チームメンバーへの尊敬チャンスが増加
2つ目にチームメンバーへの尊敬チャンスが増えたという風に書きましたが、やっぱり品質について対話していると、必然的に他メンバーが大事にしてたりとか、作り込もうとしている品質がたくさんあることを知れるので、「この人こんなところまで考えてたのすごいな」といった発見がたくさんあるんですね。なので、そうするとそこから他のメンバーを尊敬できたりするので、仕事もやりやすくなるといったメリットもあるのかなと思います。
利用者視点を考える対話
3つ目に「利用者視点でどう？」という対話が増えました。
こちらは先ほどお話しした利用者のペインを体感してみる会などの効果ももちろんあると思うんですが、品質についての対話の中でやっぱりその品質って何っていうのを問うていくと、結局利用者にとっての価値を担保ていきたいという話になっていくので、そういった点が起因しているのかなと思います。
開発チーム全体の品質共通理解と品質保証の実現
最後に開発チームみんなが理解する品質に向かって品質保証を行えるようになったというところがあります。
品質についての対話を繰り返す中で認識齟齬が解消し、共通認識が増えていき、みんなが理解する品質が可視化されていったことで、それがチームの共通指針になるので、足並みを揃えて開発を進めていけるといったメリットもあったのかなと思います。
というわけで最後になんですが、まとめとしてより早く品質を届けるために、みんなで先ほど話したような品質についての対話機会を設けていくと認識齟齬による阻害要因を解消できるのでお勧めです。
というところで本日の話は以上になります。
ご清聴ありがとうございました。
取り組みの頻度は2週間に1回
松下: 質問がYouTubeの方でも上がっていたんですけども、
取り組みにどのぐらい頻度でやっているんですかというとこなんですけども岩壁さんお願いできますでしょうか。
岩壁さん: はい、こちら開発チームでは2週間に1回開催してます。
で、次回何するかのネタはその2週間の間に考えるというスパンで実施してます。
こちらの記事の発表はこちらのアーカイブスからご覧いただけます。
この記事が気に入ったらサポートをしてみませんか？