アジャイル開発に必要なテストの準備、進め方 Developers Summit 2023 2023.2.10

1 自己紹介 ◼ 名前：船橋 篤史 ◼ 所属：株式会社SHIFT​ ◼ 経歴： ◼ アジャイル開発体制構築、自動テスト導入 ◼ Windowsネイティブアプリケーションのクラウドリフト ◼ Webアプリケーションのクラウドシフト ◼ 基幹システム構築 ◼ etc…

社名 株式会社 SHIFT 代表者 代表取締役社長 丹下 大 設立 2005年9月7日 従業員 連結：8,119人 単体：4,646人（パートナー、派遣含む）2022年2月末時点 所在地 【本社&東京オフィス】東京都港区麻布台2−4−5 メソニック39MTビル 【札幌オフィス】北海道札幌市 【大阪オフィス】大阪府大阪市 【仙台オフィス】宮城県仙台市 【福岡オフィス】福岡県福岡市 【名古屋オフィス】愛知県名古屋市 【広島オフィス】広島県広島市（予定） 関係会社 株式会社SHIFT SECURITY (東京都) 株式会社メソドロジック (東京都) ALH株式会社 (東京都) Airitech株式会社 (東京都) 株式会社さうなし（東京都） 株式会社SHIFT PLUS（高知県） 株式会社システムアイ（神奈川県） 株式会社分析屋 (神奈川県) 株式会社ナディア (東京都) 株式会社xbs (東京都) 株式会社エスエヌシー (大阪府) 株式会社CLUTCH（東京都） 株式会社ホープス（東京都） VISH株式会社（愛知県） 株式会社A-STAR（東京都） DICO株式会社 (東京都) 株式会社SHIFTグロース・キャピタル（東京都） 株式会社クラフ（宮崎県） 株式会社サーベイジシステム (東京都) 株式会社マスラボ (東京都) SHIFT Global Pte Ltd（シンガポール） SHIFT ASIA CO.,LTD （ベトナム） ほか 計32社 SHIFTを語る 3つのポイント ・売上高1兆円を狙えるポテンシャル ・サービス開始以来、高い売上高を維持している ・ITはますます人材不足→2030年には、79万人の不足が予想される（経済産業省平成28年度調べ） ・エンジニアがやりたがらない仕事を圧倒的に優秀な人材が実施 ・118万件に及ぶ膨大な不具合DBを活用した品質保証 ・人材を選定するCAT検定、人材を育てるヒン大、管理をするCATを開発 会社概要 SHIFTグループは、ブルーオーシャン成長市場において、ソフトウェアの 「品質保証」を手がけている会社です 2 グループ会社 ソフトウェア品質保証の デファクトスタンダードを開発 非エンジニアが活躍できる市場をつくっ た 5.5兆円のブルーオーシャン市場で圧 勝

SHIFTのサービス一覧 DX推進支援 新規事業の牽引をご支援 コ ン サ ル 最 新 技 術 支 援 推 進 構想策定支援 新規サービス開発 DXクライテリア診断 アジャイル開発 ローコード開発 オフショア開発 DevOps AI／ビッグデータ支援 アナリティクス マーケティング PMO 教 育 ベーシック（品質テスト／RPA等） エンジニアリング（設計／DevOps／UX／RPAなど） マネジメント（戦略／計画／管理／CX／アジャイルなど） 品 質 担 保 テスト計画 テスト設計 テスト実行 テスト自動化 QA推進／品質評価 インスペクション PMO（PJ管理／テスト推進） イ ン フ ラ 改 善 インフラ構築 ネットワーク クラウド ERP 開発 オフショア開発 IT自動化（CI／CD、RPA） 性能改善サービス トラブルシュート コ ン サ ル 診 断 セキュリティコンサル 各種 脆弱性診断 ペネトレーションテスト 負荷テスト コ ン サ ル ・ 実 装 ECコンサルティング Web企画／制作 Webマーケティング グラフィックデザイン UI／UX／CX支援サービス コ ン サ ル 推進 構想策定支援 新規サービス開発 DXクライテリア診断 アジャイル開発 ローコード開発 オフショア開発 DevOps AI／ビッグデータ支援 マネジメント PMO 運 用 展 開 ヘルプデスク 24x365監視 マニュアル作成 FAQ／chatbot運用 PC販売 キッティング 開 発 品質保証／テスト支援 QCDの遵守に不可欠なご支援 運用効率化支援 運用コスト削減をご支援 ITコンサルティング ITでビジネス課題の解決をご支援 デジタル接点強化支援 ECサイト／CXデザイン構築をご支援 開発／インフラ支援 目的に対する確かな手段をご支援 セキュリティ支援 事業インシデントコスト削減をご支援 人材育成支援 自走化実現への育成をご支援

「品質保証の会社」から「売れるサービスを一緒につくる会社」へ 4 SHIFTは お客様のビジネス成功に コミットする会社に 「ソフトウェアテスト」 といえばSHIFT 「DX」 「売れるサービスづくり」 といえばSHIFT 第一想起 第一想起 ソフトウェアのテストを 受託する会社 SHIFTグループは、ソフトウェア品質を起点にDXや新たな価値創造を実現し、 日本の社会問題に挑戦する会社です。

今日話すこと ◼ 昨今のプロジェクト事情 ◼ アジャイル開発でみられるよくある課題 ◼ SHIFTが生み出した品質保証フレームワーク ◼ フレームワークを活用した効果 ◼ まとめ 5

6 昨今のプロジェクト事情

7 マーケットの変化が激しいため 予測が困難な時代です。 また、それらが複雑に関係しあっており 複雑かつ不確実な世の中といえます。 デジタル革新と多様な人々の想像・創造力の融合によって、 社会の課題を解決し、価値を創造する社会が必要とされて います。 昨今のプロジェクト事情 経団連 Society 5.0(http://www.keidanren.or.jp/policy/2018/095_honbun.pdf) をベースに作図

8 価値とは？ ◼ サービスをお客様に提供する 昨今のプロジェクト事情 機能の提供 ユーザー体験の提供 価値共創の コミュニティづくり

9 昨今のプロジェクト事情 価値とは？ ◼ イソップ寓話（3人のレンガ職人）

10 WFのように長期間開発して リリースすると期待と実態が 乖離しているかもしれません。 マーケットの流れに迅速に追随する形でリリースすること が求められています。 継続的に価値を創造するアジャイル開発の取り組みが進む 一因です。 昨今のプロジェクト事情 IPA いま、なぜアジャイルが必要か？(https://www.ipa.go.jp/files/000073019.pdf) をベースに作図

11 State of Agileの調査によると、アジャイル開発に 取り組んでいる66%のプロジェクトがスクラムを採用 昨今のプロジェクト事情 採用しているアジャイル手法は？ 割合 Scrum 66% ScrumBan 9% Scrum/XP hybrid 6% Kanban 6% Iterative 4% XP 1% Lean Startup 1% Don’t know 5% Other 2% ※State of Agile Report (https://digital.ai/resource-center/analyst-reports/state-of-agile-report)

12 アジャイル開発でみられる よくある課題

13 そもそも今回取り上げるScrumは、従来の開発プロセスの 主流であるWFとは大きく違います。 従来の開発とアジャイル開発の違い 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト 総合テスト 受入テスト 数ヶ月以上

14 V字モデルからみた違い 従来のプロセスでは担当がわかれていることが多い 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト 総合テスト 受入テスト 開発が担当 品証が担当

15 Scrumを取り入れるとこうなりがち V字モデルからみた違い 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト 総合テスト 受入テスト ここだけ Scurmチーム化 なぜか取り残 される 従来の 開発チームだけで 挑戦する

◼ アジャイル開発に取り組んでいるはずがリリースが行わ れないため、フィードバックがこない ◼ 結局最後にテストが行われるため、プロセスの変化がな い 16 アジャイル開発に切り替えた場合に起こる課題 Sprint 1 Sprint 2 Sprint X ・・・ テスト Sprint Release 総合、受入テスト相当 Releaseがない

◼ リリースが開発に閉じている場合も変化はない 17 アジャイル開発に切り替えた場合に起こる課題 Sprint 1 Sprint 2 Sprint X ・・・ テスト Sprint Release Sprint 1 Sprint 2 Sprint X ・・・ テスト Sprint Release やっぱり 総合、受入テスト相当 R R R ステークホルダーが やっと腰を上げる Releaseが開発に 閉じている

18 ◼ 金融プロジェクト チームA 手動テストの実績 開発とQAが一体となれなかったチームの一例 スプリント 実施ケース 不具合件数 検出率 (不具合件数÷実施ケース数) Sprint 1 630 21 3.33% Sprint 2 605 59 9.75% Sprint 3 614 114 18.75% Sprint 4 153 - テスト中止 1.5ヶ月間開発をWFに戻す 総合テスト 2,945 400 13.5% 不具合が徐々に増加しており、Sprint 4では不具合が多発したため中止

◼ 最初からプロセスを変えることはできないからと妥協 ◼ 後追いでテストした場合、不具合を改修するころには 次の開発を行っているためうまく反映できない 19 アジャイル開発に切り替えた場合に起こる課題 Sprint 1 開発 Sprint 2 開発 Sprint 3 開発 ・・・ Release Sprint 1 テスト Sprint 2 テスト Sprint X 開発 Sprint X-1 テスト Sprint X テスト ・・・ 後追いでテスト スプリント内で不具合解 消ができず最後にリリー ス

20 ◼ One Teamとなれば解決？ 課題の解決策 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト 総合テスト 受入テスト Scurmチーム化

ロール Day1 Day2 Day3 Day4 Day5 プロダクト オーナー ス プ リ ン ト プ ラ ン ニ ン グ デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム バ ッ ク ロ グ リ フ ァ イ ン メ ン ト デ イ リ ー ス ク ラ ム ス プ リ ン ト レ ビ ュ ー レ ト ロ ス ペ ク テ ィ ブ プログラマ QA スクラム マスター 21 自称One Teamでも課題はある アジャイル開発に切り替えた場合に起こる課題 非機能系テスト はいつやれば バックログA バックログA バックログA テストどこまで やれば 開発とテストの タイミングがわ からない

22 ◼ 金融プロジェクト チームB 手動テストの実績 自称One Teamの一例 スプリント 実施ケース 不具合件数 検出率 (不具合件数÷実施ケース数) Sprint 1 93 12 12.9% Sprint 2 158 26 16.5% Sprint 3 52 0 0% Sprint 4 222 17 7.66% Sprint 5 897 98 10.9% Blocker不具合が多くテストケースが十分に消化できていない

23 ◼ 従来との違いが多すぎて、評価方法も変える必要がある アジャイル開発に切り替えた場合に起こる課題 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト 総合テスト 受入テスト 数か月以上 従来と違うから 品質の評価が できない

24 SHIFTが生み出した 品質保証フレームワーク

25 ◼ 担当の違いは思った以上に影響がある V字モデルからみた違い 再掲 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト 総合テスト 受入テスト ここだけ Scurmチーム化 なぜか取り残 される 従来の 開発チームだけで 挑戦する

26 開発とQAには障壁がある ◼ 開発担当 vs 品質保証担当 ➢ 物理的な壁 ➢ 担当部署や担当企業の違い ➢ 関係性の壁 ➢ 成果物を作成する側と指摘する側の違い ➢ つくる側と利用する側（実際は利用しているつもり） ➢ よく知らない相手から指摘がくる ➢ そもそも品質保証担当がゲートキーパだったりする ➢ 後だしじゃんけん感がある ➢ etc...

27 ◼ 従来の活動は、不具合を検出する活動となっている ◼ 従来の活動は、初期の工程から「完成」をつくっている 開発とQAに障壁があってもなぜうまくいっていたのか

28 ◼ アジャイルの場合、不具合を検出する活動では遅い ◼ アジャイル、とくにScrumの場合「完成の定義」が重要 ➢ 品質が考慮されていない ➢ 認識がチーム内外であっていない ➢ 満たす状態となっていない アジャイルの場合どうすべきか

29 ◼ アジャイルの場合、不具合を検出する活動では遅い リリースに近くなるほど 不具合の改修コストは 高くなる アジャイルの場合どうすべきか What Is Shift-Left Testing?(https://www.parasoft.com/blog/what-is-shift-left-testing/) をベースに作図

30 ◼ アジャイルの場合、不具合を検出する活動では遅い ◼ Scrumの場合、スプリントは最大4週間 ➢ 多くのプロジェクトは１～２週間スプリントを採用 短いサイクルのなかで 検出していては 手遅れ アジャイルの場合どうすべきか 不具合は予防するもの What Is Shift-Left Testing?(https://www.parasoft.com/blog/what-is-shift-left-testing/) をベースに作図

31 ◼ シフトレフトで不具合を予防する ➢ 自動テストを導入して早期発見 ➢ CI/CDを回して継続的な発見 ➢ 設計をしっかりやれば大丈夫 アジャイルの場合どうすべきか と、そう単純な話ではない

32 ◼ 「完成の定義」 ➢ プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述 ➢ リリースできる状態を示すものともいえる 「機能」や「要件」「価値」の状態だけではなく 「品質」の状態も定義が必要 アジャイルの場合どうすべきか

33 開発、QA問わず「完成の定義」に向き合う QAが上流工程から入ることで～ってよくいいますが 異物混入でしかないため壁はそう簡単に破壊できない チームビルディングのときからいっしょになる必要がある チームビルディング時にどう検討すべきかが解決の鍵 One Teamとなるためにはどうすべきか

34 ◼ チームビルディングでしっかりとテスト戦略を考える ◼ テスト戦略を意識した活動をする ◼ テスト戦略は適宜改善する 戦略、スプリント活動両方を考えるフレームワーク テスト戦略 スプリント Start テストタイプ レベル整理 テスト アプローチ 検討 完成の定義 検討 PBIの テスト方針 検討 テスト計画 テスト 分析・設計 テスト 実装・実行 テストレ ビュー

35 チームビルディング時 or 適宜 スキルマップをつくりましょう システム構成の検討、整理をしましょう これらの情報から必要なテストタイプを洗い出す テストレベルの整理は… アジャイルの場合、テストレベルはテストタイプに 溶け込みそう テストタイプ、レベルの整理

36 テストタイプの共通認識をもちましょう ◼ 単体テスト ➢ ファンクションテスト？Unit TEST？単機能テスト？ ➢ TDDやってるから大丈夫！（なにが？） ◼ パフォーマンステスト ➢ ロードテスト？ストレステスト？ロングランテスト？ プロジェクト、組織内でも認識齟齬は容易に起きる 各テストタイプの意味、検証内容・範囲の認識を合わせる 必要がある テストタイプ、レベルの整理

37 ◼ テストアプローチとは 特定のプロジェクト、リリース用にテスト戦略をテーラリングしたもの (JSTQBより) ➢ 分析的アプローチ ➢ モデルベースドアプローチ ➢ プロセス準拠アプローチ ➢ etc... このタイミングのテストアプローチは↑↑↑ではなく↓↓↓ ◼ テストアプローチとは テストの方法です (A new model for test strategies より) 各テストタイプどういった方法で実施するか検討する ➢ Scripted Approach（手動テスト） ➢ Automation Approach（自動テスト） ➢ Exploratory Approach（探索的テスト） テストアプローチの検討

38 ◼ 各テストタイプを実施するアプローチを検討 そのテスト手動？自動？ APIテストは？状態遷移テストは？ストレステストは？ 画面遷移テストは探索的テストでいいかもしれない… このタイミングで一度検討してみましょう さらに、チームの成熟度などによっても変化していくと思 います テストアプローチの検討

39 チームビルディングの過程で ◼ 構成管理（ブランチ戦略など） ◼ 不具合管理 ◼ etc... いろいろ決めていくと思います。 検討したテストタイプをどのタイミングで実施するのかも 完成の定義に含めてしまう 完成の定義に含めなかったテストタイプは品質バックログ としてリストアップし、どこかのスプリントで解決させる 完成の定義の検討

40 各ブランチでどのテストまで終わらせるかまで決める 完成の定義の検討 SAST/Unit Test API/E2E Automation Test 共用環境Deploy 脆弱性診断etc

41 ◼ ステージング環境へデプロイされていること ➢ Releaseブランチにコードがコミットされていること ➢ 自動テストがすべて正常終了されているコードがコミットされていること ◼ シナリオテストが完了していること ➢ 不具合のトリアージが完了していること ➢ 修正を後回しにした不具合はバックログリストに載っていること ➢ 自動テストのUnit TestとAPI Testが正常終了したコードがデプロイされている環境で実施する こと ◼ 静的解析で重大な問題が検出されていないこと ◼ リグレッションテストのソースもコミットされていること ➢ プロダクトコードだけではNG ➢ リグレッションテストが正常終了していること etc… 完成の定義の一例

42 バックログリファインメントにおいて ◼ 実現した際の価値 ◼ 対応内容 ◼ 受入基準 ◼ etc... いろいろ決めていくなかでINVESTという特性を考慮するが、 Testableを意識する つまり、それぞれのバックログで実施が必要なテストタイ プまでチームで認識を合わせる PBIのテスト方針検討

43 いざリファインメントしてみたら考慮不足などあると思います 見ないふりせずしっかり向き合いましょう PBIのテスト方針検討後振り出しに戻ることもある テスト戦略 スプリント Start テストタイプ レベル整理 テスト アプローチ 検討 完成の定義 検討 PBIの テスト方針 検討 テスト計画 テスト 分析・設計 テスト 実装・実行 テストレ ビュー

44 スプリントでは ◼ QAもスプリントイベントに参加する ◼ レトロスペクティブなどでテスト戦略を見直すときは全員で考える ◼ 完成の定義を満たしているかをつねに確認していく ◼ テストのレビューはスプリントレビューではない といったことに注意して活動しましょう バックログリファンメントにも参加しているので、開発と 並行してテスト分析、設計が行えます。 テスト観点をチームで共有することで不具合の予防にもつ ながります。 スプリント

45 フレームワークを活用した効果

46 ◼ 金融プロジェクト チームA 手動テストの実績 フレームワークを適用した効果 スプリント 実施ケース 不具合件数 検出率 (不具合件数÷実施ケース数) Sprint 1 630 21 3.33% Sprint 2 605 59 9.75% Sprint 3 614 114 18.75% Sprint 4 153 - テスト中止 1.5ヶ月間開発をWFに戻す 総合テスト 2,945 400 13.5% スプリント 実施ケース 不具合件数 検出率 (不具合件数÷実施ケース数) Sprint 1 758 5 0.6% Sprint 2 1,282 14 1.09% Sprint 3 1,277 23 1.8% Sprint 4 592 8 1.35% Sprint 5 966 18 1.86% ※メンバーはほぼ同じですが、一部QAメンバーがSHIFTに変更されています ※担当するプロダクトの規模、難易度は上がっています 不具合の検出率が下がっており予防傾向にある ※本番障害6ヶ月間ゼロ

47 ◼ 金融プロジェクト チームB 手動テストの実績 フレームワークを適用した効果 スプリント 実施ケース 不具合件数 検出率 (不具合件数÷実施ケース数) Sprint 1 93 12 12.9% Sprint 2 158 26 16.5% Sprint 3 52 0 0% Sprint 4 222 17 7.66% Sprint 5 897 98 10.9% スプリント 実施ケース 不具合件数 検出率 (不具合件数÷実施ケース数) Sprint 1 715 8 1.11% Sprint 2 448 5 1.11% Sprint 3 534 24 4.49% Sprint 4 973 17 1.74% Sprint 5 741 18 2.42% テストケースの消化が安定に向かいながら、不具合も予防傾向にある ※本番障害6ヶ月間5件 ※メンバーはほぼ同じですが、一部QAメンバーがSHIFTに変更されています ※担当するプロダクトの規模、難易度は上がっています

48 ◼ 開発とQAが協力しあいながら作業を行う フレームワークを適用した効果 ロール Day1 Day2 Day3 Day4 Day5 プロダクト オーナー ス プ リ ン ト プ ラ ン ニ ン グ デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム デ イ リ ー ス ク ラ ム バ ッ ク ロ グ リ フ ァ イ ン メ ン ト デ イ リ ー ス ク ラ ム ス プ リ ン ト レ ビ ュ ー レ ト ロ ス ペ ク テ ィ ブ プログラマ QA スクラム マスター バックログA 設計・開発 バックログA テスト 分析・設計 改修内容の共通認識が あるため開発とテストが 同時に設計できる バックログA 開発 I/Oを先に固めることで QAに影響を出さずに改修 バックログA テスト実行 担当するテスト に集中 必要に応じて テスト観点の フィードバック

49 ◼ 今回はチーム全体で品質を意識するフレームワーク ◼ ただ流れに沿うだけでは目的が達成できない フレームワークを妄信してはいけない テスト戦略 スプリント Start テストタイプ レベル整理 テスト アプローチ 検討 完成の定義 検討 PBIの テスト方針 検討 テスト計画 テスト 分析・設計 テスト 実装・実行 テストレ ビュー

50 まとめ

51 ◼ 紹介したフレームワークはあくまでスターターキット ◼ チームの成熟度が上がるにつれて変化していく まとめ テスト戦略 スプリント Start テストタイプ レベル整理 テスト アプローチ 検討 完成の定義 検討 PBIの テスト方針 検討 テスト計画 テスト 分析・設計 テスト 実装・実行 テストレ ビュー

52 VUCA時代、アジャイル開発への取り組みが進んでいるが プロジェクトは ◼ 不具合予防する活動に変化する ◼ MVPには「完成の定義」の共通認識が大切 まとめ

No content