JaSST'22 Hokurikuで学んだ『アジャイル開発で大切なこと、レビューを改善する方法、探索的テストを推進する方法』｜イベント参加レポート

きっかけ

こんにちは。株式会社SHIFTでQAエンジニアをしている坪根です。先日のJaSST'21 Tokaiに引き続き、2022年1月21日（金）に開催された、JaSST'22 Hokurikuに参加してきました。忘れないうちにセッションで学んだことと感想を残していきたいと思います。

参加したセッションは以下になります。

【基調講演】 「アジャイル開発で本当は、本当に、大切なこと ～ビジネスとプログラマとテスター協働チームづくり～」 平鍋 健児氏（永和システムマネジメント）

【招待講演1】 「プロジェクトに寄り添ったレビュー改善の実践と効果」 久連石 圭氏（東芝）

【招待講演2】 「なぜ大規模SIerで探索的テストを推進しているのか？ ～2021ver～」 熊川 一平氏（NTTデータ）

「アジャイル開発で本当は、本当に、大切なこと～ビジネスとプログラマとテスター協働チームづくり～」」【基調講演】

講演者：平鍋 健児氏（永和システムマネジメント）

アジャイルはウイルス

アジャイル開発を導入しようという話はチーム内ではなく、チーム外から入ってくるケースが多いです。全社で取り入れるのではなく、まずは一部のチームでスクラムを取り入れ、そこからエクストリームプログラミングなどを徐々に取り入れるといいです。

結果チームと合わなければ、アジャイル開発を取り入れないのもありです。

アジャイル開発を導入する

まずはプロジェクトの可視化から始めます。
野球場のスコアボード※のようにステークホルダーにとって意味のあるボードを作ります。

※「最新の正の情報」が「一箇所に」。「大きく」書かれていて、それを、「両チームのメンバー」、「審判」、「観客」が見ている。「次の行動」を誘発する。

カンバン

カンバンは誰がタスクを取ってもいいので、助け合いが生まれやすいです。
また、エンドユーザーが分かる表現で記載すると、ビジネスサイドのメンバーからも意見をもらいやすいです。

バーンダウンチャート

「バーンダウンチャートを見てね」で終わらせると、バーンダウンしていなくてもチームのメンバーからスルーされがちです。スルーされないために講演者の方の会社では、チームのメンバーがバーンダウンチャートを手書きしています。

アジャイル開発とテスト

QAがプロダクトオーナーの品質に対する相談相手になり、QAが達成したい品質をプロダクトバックログに入れ込んでアジャイル開発を進めながら達成することが重要です。

コロナ禍でのコミュニケーション

コミュニケーションには信頼関係が必要です。信頼関係を築くには共感が必要です。短いアイスブレイクや、雑談チャンネルを作ってペットの写真を投稿するなどを継続的に続けると、オンラインのコミュニケーションのみでも、チーム内で共感が生まれ、信頼関係を築けます。

本当に大切なこと

組織や考え方を変えていくには、大きなエネルギーと覚悟が要ります。時間は誰にとっても有限で他人と過去は変えられないです。人への共感からイノベーションは始まります。自分から話をしにいくことが大切です。

人にはその人の正義があるので、文句や批判にエネルギーを使わずに、迷ったらコミュニケーションが多くなる解決策を選ぶのが大切です。

《このセクションの感想》

バーンダウンしないことをスルーしないためにバーンダウンチャートを手書きするアイデアに驚きました。オンラインでコミュニケーションをとる場合、オフラインの場合より共感を得るための工夫が必要というのが参考になりました。

「プロジェクトに寄り添ったレビュー改善の実践と効果」【招待講演1】

講演者：久連石 圭氏（東芝）

レビューの目的

レビューの最大な目的は、設計や実装に対する影響度が大きい欠陥を上流で検出して除去することです。レビュー会議はできるだけ多くの欠陥を検出する場にすることが重要です。レビュー改善の目的は、レビュー会議の進め方や出席者の意識を変えることで、会議の中でできるだけ多くの欠陥を検出できるようにすることです。

レビューの改善事例

■背景
短納期かつ不具合ゼロが求められる案件で、ここ数年で不具合が何度も出てしまいました。 原因分析をした結果欠陥は設計工程で混入しており、設計工程の改善が必要でした。設計工程の改善として欠陥を早期に検出するためにレビューの改善を行いました。

■改善前のレビュー
レビュープロセスが存在し、プロセスに従って一通りのレビューは実施済みで、レビューに関する定量的データも取得できていました。
ただしレビュー会議の進め方に以下の改善の余地がありました。

・レビュー会議が指摘の場でなく説明・議論の場となってしまっている
・指摘する人が偏っている
・レビュー会議の役割分担ができていない

■改善したこと
事前レビュー・個人レビューの徹底
・事前にレビュー対象ドキュメントを確認し、指摘を挙げました。

抜け漏れを意識したレビュープロセスの構築
・「誤り」より「抜け・漏れ」の検出が難しいです。
・漏れ⇒曖昧性⇒誤りの順でレビューを実施しました。

レビューの目的や観点の明確化
・レビュー会議に目的や観点を設定しました。

役割の明確化とレビューファシリテーターの育成
・役割を一人に集中させないために、場をコントロールするレビューファシリテータを設定しました。

改善結果の計測
改善した後のアンケートでは開発者の8割がレビューの改善を実感でき、レビュー工数、質、効率が向上し、設計の漏れや誤りなど致命的な欠陥の検出割合が増えたことを計測できました。

改善推進者と開発者が寄り添いながら進めることが大切

改善するには今のやり方よりどうすればよくなるか考え、仲間と協力しながら、チームや組織への展開・定着を進めていくことが大切です。

《このセクションの感想》

・「誤り」より「抜け・漏れ」の検出をレビューの目的とするのは参考になりました。

・講演者の方は改善推進者がいる場合の事例を紹介してくださいましたが、改善推進者がいない場合でも、レビューに問題意識を持つ仲間を募り、上司を巻き込むことでレビューの改善をできそうだと思いました。

「なぜ大規模SIerで探索的テストを推進しているのか？～2021ver～」

講演者：熊川 一平氏（NTTデータ）

探索的テストとは？

テストをしながら次に行うテストを考え、バグを探索するテストです。その場で思いついたことを確認するアドホックテストや、何も考えずに打鍵するモンキーテストとは異なります。テストをしながら以下のふるまいを観察してバグを探索するのが探索的テストです。

・画面
・帳票
・ログ
・DBレコード
・体感的な応答速度
・など

スクリプトテストとは?

実行手順や期待結果を記述したテストケースに則って実施するテストです。

テストを現実的に考えてみる

テストをすることによって得られる最もわかりやすい効果はバグが見つかることと悪い仕様を見つけることです。探索的テストとスクリプトテストの結果を比較すると、1時間当たりに摘出したバグの件数は10倍でした。 同様に悪い仕様を見つけた件数は100倍でした。

スクリプトテストはバグが出ないと思われる機能に対してもテストケースを記述するので、時間がかかりすぎます。 また、期待結果通りであればテストがパスしてしまうので、悪い仕様について報告されにくいです。

なので、スクリプトテストより現実的に効果のある探索的テストを推進しようと考えました。ただしスクリプトテストと比較して探索的テストは可監査性が低いので、非公式なテストとして推進しました。

探索的テストを推進するために、探索的テストを推進する価値を理解した人を増やそうと、以下の研修を自社で実施しました。

・意図的にバグを混入させたシステムに対して探索的テストをする

結果100プロジェクトで探索的テストを推進し、10000個以上のバグを摘出できました。

今進めていること

探索的テストとは別に、スクリプトテストを実施するなら、探索的テストは無駄ではないかという意見がありました。

なので、公式テストとして実施できるSONAR Testingを考えました。 SONAR Testingとはまずテストし、テスト中に取得されたモデルをレビューして抜け漏れを見つけ、結果を記録するテストです。

《このセクションの感想》

・現実的な効果を積み上げていくために新たな手法を取り入れ、批判的な意見が出ても逆らわずに柔軟に対応されているのがすごいと感じました。

・探索的テストを推進し結果を出すだけでなく、より良い手法を考えてらっしゃるのもすごいと感じました。

JaSST'22 Hokurikuに参加した感想

・普段の業務で取り組んでいるアジャイル開発など身近なテーマの講演が多く、普段の業務で改善できそうな事柄に気づくことができました。

・また普段の業務と近いので、改善できたら同僚にも横展開しやすそうだと感じました。

・ 先日参加したJaSST'21 Tokaiのように普段の業務から離れたテーマの講演を聞き視座を高め、視野を広げることも必要ですが、身近なテーマの講演を聞き普段の業務の改善に直結する気づきを得ることも必要だと感じたので、どちらの講演にも今後も参加したいと感じました。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

執筆者プロフィール：坪根 圭佑
ERPパッケージソフトの開発会社で会計ソフトの手動テストを2年経験したのち、2019年にSHIFTに参画しました。普段はAPIテストを担当しています。

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/