Agile Testing Night#24 ~Jam Session vol.3~ に参加しました。
イベントの概要
スピードの早いテクノロジーやビジネスの変化に合わせ、ソフトウェア開発のスタイルも刻々と変化してきました。その変化に合わせ発展してきたのがAgileやLeanです。
ところが日本の場合、これらはソフトウェア開発者の視点で語られることが多くソフトウェアテスト・品質視点での議論はまだまだ足りていません。
そこでAgile testingやShift-left testingを中心とした事例の紹介・ディスカッションを行うMeetupを企画しました。
日本のテスト・品質コミュニティを盛り上げるべく、オープンでカジュアルなイベント・コミュニティを目指します！
引用：
イベント参加の背景
- テストのことをもっと知りたい。
- vol.1,2のイベント参加が貴重な体験になっています。
- vol.1お聞きできなかったおおひらさんのお話をついに…！！
セッション
会場に向かう電車が人身で遅れるという事件がありましたが、20分程度の遅刻でたどり着けました！！
スクラムとテストVer.RSGT2025 A面：チームでテストをする B面：チームにテスターがいる理由
A面：チームでテストをする
開発プロセスについて。
要件定義をもとに設計とテスト分析・設計が並走する。
そこから、実装とテスト実装が並走し、完了次第実行する。
また、テスト分析・設計が終わると、リリースノートマニュアル作成をする。
実装前にテスト分析設計をすることで、受け入れ条件を明確化する。
早めにテスト分析をすることで、実装時の考慮漏れを事前に防ぐ。
実装に着手する前のテスト分析設計はラフになる。
抽象度の高いコミュニケーションで振る舞いを捉えることができる。
リリース効率よりもフロー効率。
テスト分析の参考：
モブでふるまいベースの会話を通し、テスト分析をする。
テストで実施することだけでなく、テストしないことも明記する。
テストしないことを考えることを通し、考慮漏れを防ぐ。
テスト分析設計を後回しにすると、実装後に不具合が発生しがち。
先にテスト分析設計をすることで、気を付けるポイントに気付くことができる。
リリースノートマニュアルを書くことで、運用の具体的なイメージを共有する。
運用のイメージをビジネスサイド、ステークホルダーと共有することで、運用レベルでの手戻りを防ぐ。
運用レベルでも先に明文化することで具体的なイメージを共有できる。
要件定義の後ではなく、設計とテスト分析・設計の後に開始することで解像度をあげた検討ができる。
全員でテストをする。
実装と並行して、PdM、デザイナーと探索的テストを行う。
PdM、デザイナー：ユーザー視点。QA：テスト視点。
リアルタイムでフィードバックと修正を実施。
チーム全体でのテストイベントとして、モブテスト、バグバッシュを実施している。
バグバッシュは不具合を見つけるためだけではなく、製品知識を高めるための学習やフィードバックを貰うことを目的としている。
DEVの不安部分をフォーカスしたチャーターや、実際のユーザーを想定したロールプレイを採用している。
※ユニットテストは徹底。QAも見る。E2Eは画面がよく変わるので力を入れていない。
バグバッシュ参考：
B面：チームにテスターがいる理由
いなくても開発はできる。いると便利。
・全体像（抽象）と詳細（具体）を行き来する視点を持つ。
・異なる時間軸で話す。今と未来の品質を見据えた議論を促す。
・プロセスを常に作る。出荷可能状態を定義し、そのためのテスト計画を立てる。
参考：
開発チームが作ったものをテスターひとりでテストするのは無理。
チームでのテストをどのように実現していくかを考えることが重要。
テストを通して、新たな発見をし、ステークホルダーの意識に還元する。
テスターの覚悟。チームとプロダクトを愛する。
ビジネスとしてエンジニアとコミュニケーションを取る。
プロダクトのために恐れずに越境してコミットしていく。
参考：
アイデンティティとしてのテスター。
テスターはプロダクトを良くするために品質にフォーカスする。
あるものはすべてテストしていく。ただ、個人でのテストに捉われない。皆でやる。
必要に応じて越境する。
感想
最近テストプロセスの形骸化に悩んでいます。
私の所属するプロダクトチームは今はQA不在ですが、PBIの消化にあたっては最初にテスト計画書を書いて、次にテスト仕様書を書いてから実装に入るというプロセスを採用しています。
目的は作る前に対象に対する解像度を上げるための取り組みとなります。
恐らくはおおひらさんご紹介のプロセスと大きな違いはないと思いつつ、私たちは開発者がプロセスを推進することで、どうしても作ることにバイアスがかかっている気がしました。
テスターが実現すべき価値と実態の差異を測ることが役割だとすると、我々のプロセスには本当に実現すべき目的を満たせているかを客観的に見る目が薄いのではと気づけました。
帽子を被り直すではないけど、その場に客観的な目を持ち込むことで何とかできないかとヒントになりました。
QaaSのおおひらさん回ももう一度見直そう。
言語のプロであるソフトウェアエンジニアだからこそ、対話のプロになれる
──NVCをきっかけに、言葉の力と向き合いはじめた話
メモ
ソフトウェアエンジニアだからこそ対話のプロになれる。
もともとは強い力で相手をぶった切る姿にあこがれを持っていたが、
実際やってみたら居心地よくなかった。
技術力を磨けば言葉に説得力を持てると思っていた。
実際に今の企業に入って、対話が多いことに気付いた。
チームではモブプロを実践。
スクラム、モブプロを実践する中で対話にぶつかった。
そんななかNVCに出会った。NonViolentCommunication。非暴力のコミュニケーション。
bookplus.nikkei.com
状況の観察をして、自分の感情に気付き、相手に要求を伝える。
正解のない技術的な議論こそ、NVCが合う。
吐き出すことで自分の中のもやもやをコントロールでき、結果的に対話の価値を実感した。
相手のためより、自分のために言葉をつかえるようになった。
対話のスキルは才能じゃなく、後天的に身に着けることができるスキルと気付いた。
共通の目的に対して議論・対話ができる。
日常の要件整理、プログラミング、PR上でのレビューやり取り、運用整備を、
ヒアリング、ソフトウェアとの対話、チームとの対話、未来のメンバーや自分との対話と置き換えて把握ができた。
プログラミングはソフトウェアとの対話。
コードという言語を通して対話をする。
コンピューターに対しての発信。それに対しての動作としてのレスポンスがある。
NVCのフレームワーク。４つの観点で言葉を実装している。
アンチパターン。道徳を持ち出す、比較する、戦記人会費、自分の願望の共有。
観察と評価を混同すると、自分が伝えたいメッセージが相手に伝えづらくなる。
フレームワークを活用して、アンチパターンを避ける。
アンチパターンでもトレードオフを意図して利用する。
人との対話もエンジニアリングだと思えるようになった。
多職種とのコミュニケーションもプロダクトをを作り上げる上でのエンジニアリングとして捉えられるようになった。
NVCを活用するには客観的になることが大事。
議論の際には感情的に陥りやすい。
それを避けるためにマインドフルネスが重要となる。
感想
頭の中の考えを言語化するためのプロセスは、抽象度が高ければ高いほど難易度
が高いと思っています。
そうしたものごとを会話するために、NVCというフレームワークに頼ることは、自分の思考を整理するためにも効果的な手段だと感じました。
自分は気付けば自分の不安を隠すために議論で相手に勝ちたがる傾向があるので、NVCというクッションを置くのが効果的と思いました。
まず、明日から状況の観察をして、自分の感情に気付き、相手に要求を伝えること。観察と評価をきりわけることを意識してみます。
トーク&質疑応答
NVCは鋭い
ノン・バイオレーション・コミュニケーション。
非暴力というが、観察と評価を分けた方が鋭くも感じる。
非暴力・非服従が原則。Win-Winを目指すためのプラクティス。
観察をどう伝えるかは気を付けた方が良いかも知れない。
推論の梯子のように落としていくことが重要。
FACTを話す。事実ベースで会話した方が議論ができる。
事実と解釈。感情の認識。は会話の一歩となる。
自分がどう思ったかをプロセス化した方が、自分の感情を客観視できる。
観察は行き過ぎるとゲシュタルト崩壊する。
どこまで事実に近づけるか、感情と切り離すかが重要。
事実を飛ばしてものごとを捉えると評価になっていく。
NVCが仕事をどう変えたか
空中戦のような議論が軽減した。
コミュニケーションのすれ違いが減った。決断に対するプロセスがスムーズになった。
目的と手段があった場合、手段同士が対決することが多い。
NVCを活用することで、手段の折衷案をすり合わせしやすくなる。
テスターをどう育てるか
テスターにどうなって欲しいか次第。
どうした責務を持たせたいかを設計してから、何が必要かを考えていく。
まとめ
電車遅延での遅れはあったものの濃度の高い学びを得ることができました。
おふたりの話とも自分や自分達の課題と合った内容だったため、意識したい気づきが多くありました。
特にテストプロセスは小休止挟まないとそのまま課題が続いていくのでどこかで一気に考えたい。
いつも学びの多い内容に感謝です。ありがとうございました！
