プロダクトチーム一丸となって臨むソフトウェアテストの勘所 #devsumi #devsumiE

© 2023 VeriServe Corporation 会社名・製品名・サービス名は、各社の登録商標または商標です。
プロダクトチーム一丸となって臨む
ソフトウェアテストの勘所
株式会社ベリサーブ
研究企画開発部サービス開発課
課長／プロダクトマネージャー
朱峰錦司
2023年 2月 9日
9-E-2

View Slide

➢ 約40年にわたりソフトウェア検証で品質向上に貢献
◼ 仕様などの要求事項が満たされているかを評価する Verification と、機能や性能が本来意図された用途や
目的に合っているかを評価する Validation
当社の社名にはこの 2つのV を提供する（Service）という想いが込められています
本社
東京都千代田区神田三崎町3-1-16
神保町北東急ビル 9階
西日本支社
大阪府大阪市中央区北浜1-8-16
大阪証券取引所ビル 19階
中部支社
愛知県名古屋市東区泉2-27-14
関電不動産高岳ビル 13階
沖縄テストセンター
沖縄県うるま市字州崎14-1
沖縄IT津梁パーク
情報通信機器検証拠点施設
宇都宮テクニカルセンター
栃木県宇都宮市宿郷2-7-3
IRビル宿郷 5階
広島テクニカルセンター
広島県広島市中区八丁堀14-4
JEI広島八丁堀ビル9階
刈谷テクニカルセンター
愛知県刈谷市桜町1-24
JS刈谷駅ビル 2階
西新宿テクニカルセンター
東京都新宿区西新宿6-24-1
西新宿三井ビル 14階
社名
(VeriServe Corporation)
設立 2001年7月24日
代表者代表取締役社長新堀義之
従業員数 1,452名（2022年3月末時点連結）
資本金 792百万円（2022年3月末時点）
事業内容
1. 製品検証サービス
2. セキュリティ検証サービス
3. その他サービス
子会社
株式会社ベリサーブ沖縄テストセンター
AIQVE ONE株式会社
有限責任会社ベリサーブベトナム
拠点右記参照
1

View Slide

➢ 2021年4月に株式会社ベリサーブ入社
◼ 研究企画開発部サービス開発課課長 / プロダクトマネージャー
◆ ベリサーブ内製のテスト支援プロダクト群の全体統制と普及展開に従事
➢ 前職は大手SIerにて、全社横断技術部門にて技術開発や商用案件適用支援などに従事
◼ 2009年～2013年：ソフトウェアテスト技術を中心に
◼ 2013年～2020年：アジャイル開発関連技術を中心に
自己紹介
2
朱峰錦司（あけみねきんじ）

View Slide

➢ ソフトウェアテスト技術関連の社外活動にも継続的に従事
自己紹介
3
2013年～2019年 2016年～2017年 2021年～
WACATE
実行委員
ICST 2017
運営委員
JaSST nano
お世話係
出典： https://wacate.jp/ 出典： http://aster.or.jp/conference/icst2017/ 出典： https://jasst-nano.connpass.com/
今の上長

View Slide

1. プロダクト価値についての共通認識醸成の難しさ
2. サーベイしてみた
3. 「ワイガヤテスト」と、その実践
➢ おまけ: 今改めて、ソフトウェアメトリクスの活用を考える
本日のアジェンダ
4

View Slide

© 2023 VeriServe Corporation 会社名・製品名・サービス名は、各社の登録商標または商標です。 5
1. プロダクト価値についての共通認識醸成の難しさ

View Slide

とある
プロジェクト
での悩み

View Slide

➢ 小規模チームでプロトタイピング中心にプロダクト検討
◼ ビジネスオーナー
◼ プロダクトオーナー
◼ UXリサーチャー
◼ UIデザイナー
◼ iOSエンジニア
◼ バックエンドエンジニア
➢ シンプルな会議体でスピーディーにフィードバックループを回せていた
◼ 月1の仕様検討会
◼ 月1のユーザーテスト
◼ 開発は1日1スプリントで日々優先順位を議論しながら
①立ち上げ期
7

View Slide

➢ フルスタックの開発体制に拡大
➢ テストアーキテクチャもバランスよく設計
◼ 各コンポーネントチームの裁量での自動ユニットテスト
◼ コンポーネント間IFを中心とした自動化された結合テスト
◼ 専任チームによるマニュアルシステムテスト
➢ 従来はちょっとしたアップデートにも1年かかっていた開発が、さまざまなプロセスやインフラ面での
工夫・チャレンジにより少しずつデリバリーが加速し、2カ月に1回は市場ローンチができるように！
②開発本格化
8
エンジニア2名を除き
PM系を強化したPOチーム
体制増強した
モバイルチーム
体制増強した
バックエンド
改めBFFチーム
さらに裏の
基幹チーム
が複数
さらに裏の
基幹チーム
が複数
さらに裏の
基幹チーム
が複数
専任の
QAチーム

View Slide

➢ リリーススピードや、開発分量＝アウトプット量は安定しているが、どうにもPOチーム目線でもやもやが…
③もやもや期
9
ちょっとした既存機能の改善が、
他の新機能開発に対して
優先順位を調整しきれずに
なんとなく先に進んでしまう…
リファインメント・プランニングで
開発内容を合意できていたつもりが、
出来上がってからの手戻りが
微妙に増えてきている…

View Slide

➢ おそらく、コミュニケーション・プロセス・マインドセット…複雑に問題・課題が入り組んだ状況
➢ 解決のためにさまざまな角度から事例や文献調査をしてみた
解決アプローチ
10
出典： https://speakerdeck.com/visional_engineering_and_design/number-rsgt2023
例えば、最近非常に参考になった事例整理

View Slide

➢ おそらく、コミュニケーション・プロセス・マインドセット…複雑に問題・課題が入り組んだ状況
➢ 解決のためにさまざまな角度から事例や文献調査をしてみた
➢ その中から、今日は以下の2つのサーベイにフォーカス
1. 自身の強みであるQA領域の切り口で何か貢献できないか考えてみた
◆ 不確実な市場におけるQA活動のガイドラインや事例には、
まさに「プロダクト価値」にいい感じに向き合うためのノウハウがあるのではないか？
2. 最近よく聞くキーワード「心理的安全性」という切り口でも考えてみた
◆ 何やらチームが活き活きと生産性高く仕事をするために非常に効果的な概念らしい、
というからにはチーム間のスレ違いを解消するヒントも得られるのではないか？
解決アプローチ
11

View Slide

2. サーベイしてみた

View Slide

世の「アジャイルQA」のアプローチ
13
1 アジャイル品質パターン(QA to AQ)
2 JSTQB: アジャイルテスト担当者シラバス
3 GrowingAgile: テスティングマニフェスト

View Slide

➢ Joseph Yoder氏, Rebecca Wirfs-Brock氏, Ademar Aguiar氏, 鷲崎弘宜氏らの研究
➢ アジャイル品質の考え方と推奨される活動を、4つのカテゴリと23のパターン集としてまとめたもの
①アジャイル品質パターン（QA to AQ）
14
出典：「パターンQA to AQによる Agile Quality（アジャイル品質）への変革と事例」

View Slide

①アジャイル品質パターン（QA to AQ）
15
出典：「パターンQA to AQによる Agile Quality（アジャイル品質）への変革と事例」

View Slide

➢ 日本におけるソフトウェアテスト技術者資格認定の運営組織 JSTQB が作成
◼ 国際組織 ISTQB の加盟組織
➢ アジャイル開発におけるテストの原則と、具体的な方法論について記した資格受験シラバス
②JSTQB: アジャイルテスト担当者シラバス
16
1章. アジャイルソフトウェア開発
3章. アジャイルテストの方法、技法、及びツール
2章. アジャイルテストの基本的な原則、プラクティス及びプロセス
出典：「テスト技術者資格制度 Foundation Level Extension シラバスアジャイルテスト担当者」

View Slide

②JSTQB: アジャイルテスト担当者シラバス
17
1.1.2 チーム全体アプローチ
➢ QAだけでなく、チーム全体が品質に対する責任を持つ
➢ チーム全体アプローチの本質は、
PO、開発者およびQAが開発プロセスの各ステップで協力して作業すること
◼ PO、開発者、QAがフィーチャの検討全てに参加する「3人の力(Three Amigos)」アプローチを紹介
出典：「テスト技術者資格制度 Foundation Level Extension シラバスアジャイルテスト担当者」

View Slide

➢ Samantha Laing氏、Karen Greaves氏らのコンサルティング企業「GrowingAgile」が作成
◼ ブロッコリー(風間裕也)氏が個人ブログ上で日本語に翻訳
➢ アジャイルQAにおける重要な価値観5つをマニフェストとして掲示
③GlowingAgileテスティングマニフェスト
18
機能性をチェックする
よりも
チームが理解している
価値をテストする
システムを破壊する
よりも
最高のシステムを
構築する
テスターの責任
よりも
品質に対する
チームの責任
バグの発見
よりも
バグの防止
最後にテストする
よりも
ずっとテストし続ける
出典：【翻訳記事】テストに対する考え方「Testing Manifesto」

View Slide

世の「アジャイルQA」において共通する考え方
19
チーム全員が品質に対する責任を持つ
QAロールメンバーはその橋渡しを担う
JSTQB
アジャイルテスト担当者
QA to AQ
アジャイル品質パターン
GrowingAgile
テスティングマニフェスト
パターン
『障壁の解体』
『QAを含むOneチーム』
チーム全体アプローチ
マニフェスト：
『テスターの責任
よりも
品質に対する
チームの責任』

View Slide

➢ Developers Summit 2022における風間さんの考察
（参考）Agile Testingのエッセンス
20
出典：https://speakerdeck.com/nihonbuson/agile-testing-essence-20220218

View Slide

➢ 小規模チームでプロトタイピング中心にプロダクト検討
◼ ビジネスオーナー
◼ プロダクトオーナー
◼ UXリサーチャー
◼ UIデザイナー
◼ iOSエンジニア
◼ バックエンドエンジニア
➢ シンプルな会議体でスピーディーにフィードバックループを回せていた
◼ 月1の仕様検討会
◼ 月1のユーザーテスト
◼ 開発は1日1スプリントで日々優先順位を議論しながら
【再掲】①立ち上げ期
21

View Slide

➢ 要因のひとつとして考えらえるのが体制
➢ 「POチーム」「QAチーム」という命名が、必要以上に縦割りのマインドセットを醸成していたのでは？
◼ 要件や品質は彼らに任せればいいよね
➢ 逆もしかり
◼ 開発に口は出せないよね
初期の頃にはできていたはずのことが、なぜ…？
22
エンジニア2名を除き
PM系を強化したPOチーム
体制増強した
モバイルチーム
体制増強した
バックエンド
改めBFFチーム
さらに裏の
基幹チーム
が複数
さらに裏の
基幹チーム
が複数
さらに裏の
基幹チーム
が複数
専任の
QAチーム

View Slide

➢ チームの生産性に関わる重要なファクターとして取り上げられた、心理学における概念
◼ 2010年代にGoogleの研究により流行したが、用語は1960年代より存在しており研究が進められてきた
➢ さまざまな定義や言及が存在
◼ Google社は『ネガティブかもしれない行動をしても、このチームなら大丈夫と信じられるかどうか』と記載
◼ 日本の品質保証に多大な貢献を果たしたW.E.デミング氏は組織経営論として以下のように提言
心理的安全性
23
不安を取り除け。
そうすればきっと皆が
組織のために
効率的に働くようになる

View Slide

3. 「ワイガヤテスト」と、その実践

View Slide

サーベイからの考察
25
プロセスの分担・コンポーネントの分担
もいいけど、改めて、みんなでプロダクト
と向き合わないといけないよね
その上で、感じたこと、気付いたことは
ちゃんと共有されて、対処すべきことも
ちゃんと対処しないといけないよね

View Slide

サーベイからの考察
26
みんなでワイガヤ
できたらいいかも（唐突）

View Slide

➢ 本田技研工業株式会社で昔から行われていたミーティング手法
◼ 語源は「ワイワイガヤガヤ」、井戸端会議的なもの
◼ 課題やテーマを共有しながら、ざっくばらんに話し合って、共通の答えを探していく
ワイガヤ
27
出典：「ワイガヤの本質 “ひらめき”は必然的に起こせる」
ワイガヤには上下関係を廃した議論の場であるという不文律がある。
自由闊達、皆平等、意見も批判も尊重する。
みんなが主人公となり、ワイワイガヤガヤ話し合う。
<中略>
ワイガヤは、人の発意(気付きやひらめき)を促して
今まで存在しなかったモノやコトを創出し、
イノベーションを起こすのである。

View Slide

➢ 前述のとおり、それぞれ立場が違う
◼ プロセス上の役割分担
◆ PO、開発…
◼ コンポーネント構造上の役割分担
◆ モバイル、BFF、基幹…
➢ 全員にとって確実に同じなのは、目の前にあるリリースされて動いているプロダクト・システムそのもの
何についてワイガヤする？
28
チーム横断でプロジェクト全員が集まって、
本番環境もしくは極めて近い環境下で、
動作するプロダクトを実際に気付きを共有し合う
ワイガヤ
テスト

View Slide

➢ 冒頭のプロジェクトにおいて2カ月に1回の頻度＝ほぼリリースごとに実施
➢ 「要件」や「デモ」として伝えられる改善事項について、実際に自分の身で体感することによって、
対応の優先度合いへの納得感が高まった
◼ もうちょっとで完成しそうな新機能を止めてでも、ユーザストレスとなるレスポンス改善を優先しよう…etc
➢ 個々のシステム特性を共有・議論した上で、全体最適な（≒妥当な落としどころを見極めた）
タッチポイントのUX/UIの検討が、以前より手戻りなく実施できた
◼ 基幹システムの特性上、応答時間はどうしても長くなってしまうので、レスポンス表示を非同期にしよう…etc
実際にやってみると
29

View Slide

おまけ：
今改めて、ソフトウェアメトリクスの活用を考える

View Slide

➢ これまでの話の文脈はユーザや市場にとってのプロダクトの価値、外を向いた広義の意味での品質の話
➢ 一方、ビジネスとして継続的にプロダクト開発をしていくには、内部品質やプロセス品質も非常に重要
◼ 放っておくと、どんどん機能改善や追加のスピードが落ちていく
◼ 定量的な状況もモニタリングを、プロダクトチーム全員で実施することで、改善が加速する
なぜこのテーマ？
31

View Slide

➢ 前提
◼ 従来型開発と比べ、扱うべきメトリクスや、その活用方法が大きく変わる、ということはない
◼ メトリクス＝指標先行ではなく、GQM等のフレームワークを活用し、目的志向であるべきことも変わらない
◆ 本発表における目的は、前述のとおり、「改善の加速」
➢ アジャイルな開発におけるメトリクス活用のポイント
◼ チームのアジリティ確保の上で、ほぼ必要条件といえる
◼ 目的からのトップダウン分析に加え、自動で取れるもので活用できそうなものは？というボトムアップの分析を
組み合わせて活用するメトリクスを決める
◼ これらを振り返りや要件検討の場で、改善検討のインプットとする
アジャイルな開発におけるメトリクスの活用
32
自動的に取得・分析可能なものから始める

View Slide

メトリクスの例：活用の切り口
33
市場にとっての価値の学習
デリバリーサイクルのスピードアップ
内部品質の継続的確保

View Slide

メトリクスの例：具体例
34
目的メトリクスの例
コード変更の分量
コードレビューのリードタイム
コードレビュー発行数
商用環境へのリリース頻度
新規要件や要件変更のリリースのリードタイム
コードの重複度合い
コードの循環的複雑度
自動テストコードカバレッジ
マニュアルテストの消化スピード
重要度別のバグのOPEN/CLOSE数
ユーザーの利用時間
機能ごとのユーザーによる利用頻度

View Slide

メトリクスの例：ソースコードそのものに着目
35

View Slide

メトリクスの例：レビュープロセスに着目
36

View Slide

メトリクスの例：テスト状況に着目
37

View Slide

メトリクスの例：バグ管理プロセスに着目
38

View Slide

メトリクスの例：要件管理プロセスに着目
39

View Slide

メトリクスの例：プロダクト利用状況に着目
40

View Slide

まとめ

View Slide

➢ リリーススピードや、開発分量＝アウトプット量は安定しているが、どうにもPOチーム目線でもやもやが…
開発が大規模化するにつれてプロダクト価値の認識が弱まっていく
42
ちょっとした既存機能の改善が、
他の新機能開発に対して
優先順位を調整しきれずに
なんとなく先に進んでしまう…
リファインメント・プランニングで
開発内容を合意できていたつもりが、
出来上がってからの手戻りが
微妙に増えてきている…

View Slide

チーム一丸となってプロダクトに向き合わなければならない
43
チーム全員が品質に対する責任を持つ
QAロールメンバーはその橋渡しを担う
JSTQB
アジャイルテスト担当者
QA to AQ
アジャイル品質パターン
GrowingAgile
テスティングマニフェスト
パターン
『障壁の解体』
『QAを含むOneチーム』
チーム全体アプローチ
マニフェスト：
『テスターの責任
よりも
品質に対する
チームの責任』

View Slide

➢ チームの生産性に関わる重要なファクターとして取り上げられた、心理学における概念
◼ 2010年代にGoogleの研究により流行したが、用語は1960年代より存在しており研究が進められてきた
➢ さまざまな定義や言及が存在
◼ Google社は『ネガティブかもしれない行動をしても、このチームなら大丈夫と信じられるかどうか』と記載
◼ 日本の品質保証に多大な貢献を果たしたW.E.デミング氏は組織経営論として以下のように提言
そして、思ったこと・感じたことをちゃんと共有し解決しなければならない
44
不安を取り除け。
そうすればきっと皆が
組織のために
効率的に働くようになる

View Slide

➢ それぞれ立場が違う
◼ プロセス上の役割分担
◆ PO、開発…
◼ コンポーネント構造上の役割分担
◆ モバイル、BFF、基幹…
➢ 全員にとって確実に同じなのは、目の前にあるリリースされて動いているプロダクト・システムそのもの
というわけで、みんながプロダクト価値と向き合う仕掛けとして
45
チーム横断でプロジェクト全員が集まって、
本番環境もしくは極めて近い環境下で、
動作するプロダクトを実際に気付きを共有し合う
ワイガヤ
テスト

View Slide

おまけ：内部品質・プロセス品質を見直すにはメトリクスを活用！
46
ユーザの利用時間
機能ごとのユーザによる利用頻度

View Slide

➢ 各テストプロセスをサポートするさまざまなプロダクトを開発・展開中
おわりに：ベリサーブが提供するテスト支援ツール群のご紹介
47
テ
ス
ト
計
画
テ
ス
ト
分
析
テ
ス
ト
設
計
テ
ス
ト
実
行
テストのモニタリングとコントロール
テスト管理をシンプルに。快適、スケーラブルなテスト管理ツール
“今すぐ使える”テスト技法ツールチームによる探索的テストを加速させるツール
テ
ス
ト
実
装
テ
ス
ト
完
了
[開発中] Pulse Metrics
“健康な”ソフトウェア開発を支えるメトリクス統合ダッシュボード
[開発中] テスト分析支援ツール
テスト開発のエンジニアリング化を支援するツール

View Slide

Thanks for
your attention!

View Slide

プロダクトチーム一丸となって臨むソフトウェアテストの勘所 #devsumi #devsumiE

プロダクトチーム一丸となって臨むソフトウェアテストの勘所 #devsumi #devsumiE

Kinji AKEMINE

More Decks by Kinji AKEMINE

Other Decks in Technology

Featured

Transcript