アジャイル・クオリティの探求

https://ja-jp.facebook.com/nasaearth/

JaSST Niigata 2021
サイボウズ株式会社 アジャイル・クオリティ
7/16/2021

COPYRIGHT © ATSUSHI NAGATA永田 敦
1永田 敦サイボウズ株式会社
開発本部
アジャイル・クオリティ
アジャイルの品質保証サポート
JSTQB Advanced Level Test Manager
Agile Inspection Maestro

SQiP 研究会 研究コース４
派生開発推進協議会運営委員
Agile流派 Evolutionary(EVO)

7/16/2021

COPYRIGHT © ATSUSHI NAGATA2本日のアジェンダ
1. アジャイル・クオリティ
2. 品質って何だろう

3. 品質保証とは
4. アジャイル・プロセスにおけるサポート
5. アジャイル・ドキュメント

6. アジャイル・クオリティ・モデル
7. さらなる広がり
8. まとめ7/16/2021

COPYRIGHT © ATSUSHI NAGATA

3アジャイル・クオリティ7/16/2021

COPYRIGHT © ATSUSHI NAGATA

4アジャイルの理解が深まるにつれてこれは、品質にとって有利だと思った
いろいろなプラクティスをやってみた⚫ アジャイル・インスペクション⚫ アジャイルRCA⚫ DevQA

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

5アジャイル・インスペクション
レビューをアジャイルに行う手法
２０１０
•
••
•
•

ドキュメント全体の欠陥の閾値の目標を決めておく
ドキュメントをサンプリングし、レビューして、フィードバックを返す
また、欠陥を測定し、ドキュメント全体の欠陥を推定する。
それを欠陥の閾値目標をクリアするまで、イテレーティブに繰り返す⚫ 1ページからインクリメンタルにレビューでき、その学びでドキュメントの質と書き手の技量が改善される⚫ 書き手にフィードバックすることにより、ドキュメントの品質を改善する効果がある。
⚫ レビュー側もフィードバックの質が向上する効果が期待できる。
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

6Tom Gilbさん
Agileの生みの親の親イテレーティブに行う••••

小さくレビュー
書き手にフィードバックする
測定し品質を判断する
改善をしてもらう

アジャイルなレビューにより早く学び、書き手とドキュメントを改善する
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

7アジャイルの特長

早く、そして小さく、イテレーティブに評価しそこから学ぶ
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

8アジャイルは早い？
初期のゴール
最初のリリース

真のゴール

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

9フィードバック獲得の設計

三菱電機 細谷泰夫：斥候としてのアジャイルプロセス活用の提案 ：SPI Japan 2012

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

10アジャイルRCA
アジャイルで要因分析をする
2015
分析探索のインタビューループと、欠陥モデ
ルを作るループの二つのフィードバックルー
プをイテレーティブに繰り返して、モデルを成長させ、複雑な要因による障害の見える化を行う⚫ インクリメンタルに、モデルを成長させ学びながら分析する7/16/2021

COPYRIGHT © ATSUSHI NAGATA

11

DevQA2017

合意された形式的情報▪ Deploy
評価環境
暗黙的共有
リスク
課題

Dev

QA

アクション
品質の見える化

サポート

信頼関係
7/16/2021

COPYRIGHT © ATSUSHI NAGATA▪ レビュー▪ テスト▪ メトリクス12

品質って何だろう
品質・クオリティは誰かにとっての価値

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

13

品質は誰かにとっての価値である。
誰か＝使っていただいているお客様[価値]• サービスを使って満足している、助かっている• その製品を欲しいと思う• 今後も使っていこうと思っている• もうこれなしでは仕事はできないと感じている• 効果の実績が出ている

その[価値]の対価として、お金をいただいている

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

14ローレックスはなぜ売れる
人は、機能だけで価値を決めていないhttps://housekihiroba.jp/shop/c/c01rxnw01/
https://www.casio.com/jp/watches/casio/product.LTP-1129AA-7B/

1000万円は超えるトゥールビヨン
https://www.jackroad.co.jp/blog/post/tourbillon
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

15さて、これは、いくらの値を付けます？

私たちが売っているものは、ソフトウェアという形がないロジックにより提供されるサービスの“価値”です。

皆さんは、その[価値]の対価として、お金をいただいてる、プロフェッショナルです
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

16

お客様にとっての価値＝品質
品質が良い悪いという評価は誰ができるでしょうか？
お客様
では、どんどんデリバリして、お客様に使ってもらえば品質がいいかわかるじゃないか
悪ければ、すぐ直してすぐデリバリすればいい
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

17

DevOps
開発とオペレーションのフリクションをなくしCI/CDのプロセスを自動化

計画

インテグレーション

利用
活用
設計
実装
テスト

7/16/2021

モニタリングCOPYRIGHT © ATSUSHI NAGATA

18

価値の創造と流れ：バリューストリーム⚫ どんな価値を提供すればよいのか

計画

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

19

価値の創造と流れ：バリューストリーム計画⚫ どのようにしてその価値を作り込むのか

7/16/2021

設計
実装

COPYRIGHT © ATSUSHI NAGATA

20

価値の創造と流れ：バリューストリーム計画⚫ どのようにしてその価値を作り上げるのか

設計
実装
テスト

振り返り
レビュー

⚫ 作り上げたものは、その価値を満足するものなのか

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

21

価値の創造と流れ：バリューストリーム
計画
DevQA

⚫ どのようにしてその価値を作り上げるのか

設計
実装
テスト

振り返り
レビュー

⚫ 作り上げたものは、その価値を満足するものなのか7/16/2021

COPYRIGHT © ATSUSHI NAGATA

22

価値の創造と流れ：バリューストリーム計画

インテグレーション

利用
活用
設計
実装
テスト

振り返り
レビュー

リリース
品質の自信
7/16/2021

お客様に使っていただく

私たちは、作り上げたものの価値に自信が持てるか

COPYRIGHT © ATSUSHI NAGATA

23

価値の創造と流れ：バリューストリーム計画

インテグレーション

利用
活用
設計
実装
テスト

振り返り
レビュー

モニタリングリリース
品質の自信
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

観測
顧客は、その価値に本当に満足しているか
24

価値の創造と流れ：バリューストリーム⚫ よりよい価値を、よりよく提供するにはどうしたらよいか
計画
計画

インテグレーション

分析
学ぶ

設計
設計
実装
実装
テスト
テスト

利用
活用

振り返り
レビュー

モニタリング顧客からのフィードバックから何を学ぶか
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

25

品質＝価値をどのようにして提供し続けるのか計画⚫ どんな価値を提供すればよいのか

設計・実装 ⚫ どのようにしてその価値を作り上げるか
テスト
品質の自信

⚫ 作り上げたものは、その価値を満足するものなのか⇒私たちは、作り上げたものの価値に自信が持てるか

モニタリング ⚫ 顧客は、その価値に本当に満足しているか学び

改善
7/16/2021⇒顧客からのフィードバックから何を学ぶか⚫ よりよい価値を、よりよく提供するにはどうしたらよいか
COPYRIGHT © ATSUSHI NAGATA

26

Deming Wheel
1950年

デミングサイクル (Deming Wheelともいう)
1.設計

2. 製造

4.調査

3.販売

1.
2.
3.
4.

製品を設計する製品を製造ラインで製造し、テストをする
マーケットに投入するマーケットリサーチを通して使用される中でテストする． そしてユーザー
は製品をどう思っているか、買わない人はなぜ買わないのかを解明する.
そして１に戻る：顧客の品質や価格に対する反応の観点から製品を設計し直す。これをぐるぐると回す

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

27品質に対しての良いフィードバックを得たい
よい魅力的品質価値を生み出していきたい

お客様の判断＝フィードバックを手に入れたい
よいフィードバック
デリバリーする製品・サービスの品質が良くなければならない
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

28

よいフィードバックとは価値のアイデア：
こうすると、このようになってもっと嬉しい

顧客からの信頼、期待がある状態・関係価値を提供できているからこそつかめる関係
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

29

品質保証とは
そして、品質保証組織、メンバーの役割、目的

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

30

品質保証とは （私の定義）”顧客価値を製品、サービスに組み込むしくみ及び活動のこと”
なので、その活動はチームすべてのロールに分散している。＝

Whole Team

なお、顧客価値も、ここではバックログアイテム（要求）のことで、仮説であり、それを主に作るPOもPBIに品質を組み込む品質保証を行っている。
カスタマーサポート, 顧客のモニター、顧客の調査分析チームも、仮説である顧客価値が、本当に顧客にとって価値があるのかという情報を開発チームにフィードバックしてくれる。これも品質保証である。

チーム全員が品質の組み込みにかかわり、つまり、品質保証を行っているといえる。

この活動の結果：顧客がこちらの目論見通り満足し、あるいは安心して使って“うれしい”と言っていただける
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

31すべての人がかかわるバリューストリーム
PM
PG,QA,UXTechnical Writer

SRE
QA
PO

計画

インテグレーション

全員
PG,QA,UX,Technical Writer

設計
実装
テスト

振り返り
レビュー

利用活用
顧客モニタリング

DevQA

7/16/2021

顧客の情シス
パートナー
サポート
SRE

SRE
調査部
サポート
営業
QA,PM
COPYRIGHT © ATSUSHI NAGATA

32

Whole Team パターン“だれも”が品質＝価値を作り上げることに貢献しているそれぞれの役割において多様な観点によって、補い、コラボし”提供する価値”に責任を持っている

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

33

多様性が品質を支える
PO

観点

情報Dev

QA
製品
品質UX

知識

7/16/2021

TE

アクセシビリティ

Technical

チーム

WriterCOPYRIGHT © ATSUSHI NAGATA

専門性

34

QAに求められているもの
ソフトウェア品質に特化した多様性
謙虚なDevの話
謙虚なDevの話：私たちは、与えられた問題をどう実現していくか、そして実現を遂行することに集中したい。
集中するが上に、見落とすもの、過ちはある。
それを、違う品質の側面でフィードバックしてほしい

QAは、ソフトウェア品質に特化した多様性を持ち、それを常に磨かなければならない
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

35

品質保証メンバーのロール
QAは、• ソフトウェア品質のスペシャリストとして、• 品質のビックピクチャの観点を持ちながら、• 製品の品質を顧客視点で肌で感じ、• 製品の品質とプロセスの品質とバランスをもって• Whole Teamが支える品質保証が進化改善していくよう• サポートするロールである。

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

36

品質＝価値をどのようにして提供し続けるのか
よりよい価値を、よりよく提供するにはどうしたらよいか⚫ どのようにしてその価値を作り上げるか⚫ 作り上げたものは、その価値を満足するものなのか

Whole Team

⇒ 私たちは、作り上げたものの価値に自信が持てるか⚫ 顧客は、その価値に本当に満足しているか⇒ 顧客からのフィードバックから何を学ぶか

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

37

QAは、バリューストリームに対してどういう貢献ができるか
QAは、短い周期で品質のフィードバックをする機会を繰り返し持つことができる

全体像からの品質のメッセージをフィードバック

事実をもとにした品質情報をできるだけ早くフィードバック

品質保証をサポートするチームは、より早く気づきを得て品質の作り込みを改善する
7/16/2021

チームは、その品質の見える化により、成果物の品質に自信を持つことができる
COPYRIGHT © ATSUSHI NAGATA

38

アジャイル・プロセスにおけるサポート
アジャイルでは、質の高いプロセスが必要

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

39

アジャイルにおけるプロセス
決められたプロセスが守られているかどうかを管理することよりもプロセスをつかさどる“人”と、人どうしのインタラクションがより重要なんだプロセスで何をするか、中身、質が重要だ
要求毎に、必要とするプロセスは変わる。それが適切にできるかどのようなインプットが必要か： 調査の必要性、プロトタイピング

どのようなタスクを、どんな順番で行うか：段取り、PFD (Process Flow Diagram）
成果物は、何が必要か ：モデリング、ドキュメント、コード

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

40

アジャイルはプロセスプロセスを守るのではなく、要求の開発作業に適合する、最適なプロセスを設計する。
バックログ(要求）毎に、プロセスを設計する

プロセスは、チームが決めるもの
チームが設計していくべきもの

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

41

開発プロセス：LeSSフレームワーク例
スプリント
SprintPanning 1
バックログ説明割り当て

プロダクトバックログアイテム

SprintPlanning 2

SprintReview

タスク実行

リスク認識

仕様書変更

設計・実装・テスト

受入テスト
設計
タスク
計画

モブ・アクティビティ

PBIDone7/16/2021

COPYRIGHT © ATSUSHI NAGATA

42

スプリントプランニング２
品質の共有

品質の共有

品質の埋込み

設計

PO
バックログ

QA
UIデザイン

懸念点
出
し・
モブ

仕様
作
成・
モブ

テス
ト設計・モブ

タスク設計

タスク実行

テスト実装

テスト実行

共有の形式化

7/16/2021

リスクリスト 仕様書

受入テスト
試験設計書

COPYRIGHT © ATSUSHI NAGATA

品質の確認
43

懸念出し
リスクを洗い出す
未知：わからないこと

調査
試行

懸念：起こるかもしれない問題

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

44

懸念出し
••

仕様の不明点設計・実装上の懸念• 初めて、久しぶり•

••
•
•
•
7/16/2021～例

機能、コード、ライブラリ、言語• わからないこと• 構造、責務• オプション
エラー処理• 条件、出かた、優先度、検出
スコープ
どこで実現するか
影響箇所、error prone、複雑度
非機能要求
COPYRIGHT © ATSUSHI NAGATA

45

懸念出し・チームでモブによりリスクを出し整理をする
・QAもモブに参加して、QA観点のリスクを共有する
多様性によりリスクの漏れを防ぐ
リスクへの対策のモチベーションがうまれる
必要十分なテストが設計できる

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

46

仕様書修正仕様：システムの振る舞い開発：システムの振る舞いを作りこむ作業
仕様に誤り（欠陥）があればシステムの振る舞いが想定と違う
不具合
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

47

仕様書修正仕様書の修正は、QAとモブで行う• モブの強力なレビュー効果で仕様に誤り（欠陥）を入れない• QAからも、品質観点が仕様に盛り込まれる
必要ならば、PMも呼ぶこともある

仕様の品質が上がる
品質が組み込まれる
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

48

仕様書修正～例• タイミングを表現に加える• 条件を加える• どのように表現するか• 言葉• イメージ• 誤解・非曖昧性防ぐ• 書かなくてもわかるか• 暗黙の了解（しつこくなる）• 仕様書のどの章で書くか（構成）• POにレビューしてもらう• マージして構成管理をする
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

49

受け入れ試験設計
QAが主体となってテスト設計をモブで行うテスト設計＝開発の品質ゴールの明記とその共有•••••
7/16/2021

ユーザストーリと受け入れ条件をどのようにテストしていくかを設計していく
QA⇒Dev• 新たなリスクへの気づき
Dev⇒QA• コードの構造をモデルなどで説明• グレーボックステスト
自動テストと手動テストの仕分け
DevとQAとのテストの仕分け
COPYRIGHT © ATSUSHI NAGATA

50

これによって出来上がる状態
QAメンバーも開発メンバーも、同じチームとなって、同じゴールに向かって、走っていくことができる

Whole Teamで上流での品質を組み込みを行う

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

51

タスクの洗い出し
リスク分析
仕様書の確定受入テスト設計の共有

スプリントバックログの設計

PBIごとに最適なプロセスを設計する
どのような段取りで、品質を組み込むかの設計（計画）をチーム（モブ）で行う
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

52

プリントバックログ：カンバン

ExcelをKintoneアプリに読み込んでカンバンを作り、スプリントバックブログを管理する
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

53

アジャイル・ドキュメント
筆まめのすすめ

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

54

アジャイル・ドキュメント
アジャイル開発では、何をドキュメントとして書くべきか
目的は二つ
1. 開発で使うため• Devが参照する• QAが参照する• 保守、サービスが参照する
2. 成果物として、デリバリーするため• マニュアルなど

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

55

アジャイル・モデリング
KeepsとTempsは、平鍋さんのアジャイル・モデリングのお話からいただいた
もちろん、モデルもアジャイル開発において重要なドキュメントである。

⚫

Keeps
• 開発の基盤となるモデル• 変化はあまりない• コードの動機をとり、保守をする• 構成管理をする⚫

Temps• コミュニケーション、共有理解のためのモデル• テンポラリで保守は行わない“アジャイル時代のモデリング”, 2014, 平鍋健児、チェンジビジョン

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

56

アジャイル・ドキュメント
開発で使うドキュメントの種類

7/16/2021⚫

Keeps• 開発の軸となるドキュメント• 保守をする＝コードと同期をとる• 構成管理をする• 例：機能仕様書、テスト仕様書

⚫

Temps
• コミュニケーション、共有情報のためのドキュメント• テンポラリで保守は行わない• その開発バージョンのためのドキュメント• 例：PBI、スプリントバックログ, 設計メモ
• バックログなどに紐づけて、検索できるようにしておくとよい

COPYRIGHT © ATSUSHI NAGATA

57

ドキュメントの例: kintone開発
ドキュメント種類

利用作成形態

レビュー

備考

PBI

Temps バックログのライフサイクルで参照

モブ

チーム全員 リファインメント

リスクリストTemps タスクを設計する際に用いる

モブ

Dev,QA

仕様書

Keeps 計画、開発のいろいろな場面で頻繁に参照される

モブ

受け入れ試験設計書 Temps 受け入れ試験設計の共有のため

Dev,QA,PO POが後でレビュー

モブ

Dev,QA

テスト仕様書Keeps 機能試験設計や回帰テスト設計で参照される

QA個人

QA

タスク設計

Temps スプリントバックログアイテム策定のため

モブ

Dev,QAモブ

Dev

アジャイル・モデル Temps 設計の際の理解のための共有情報

QAも参照あり

仕様書は、設計実装の前に、DevとQAが、モブで修正・追加変更される

Dev: 設計実装において、振る舞いのブレもぬけもれもない
QA : 仕様書という重要なテストベースを手に入れる仕様書の品質がここで決まり、上流での品質が担保される
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

58

スプリントプランニング２
品質の共有

品質の共有

品質の埋込み

設計

PO
バックログ

QA
UIデザイン

懸念点
出し・
モブ

仕様
作
成・
モブ

テス
ト設計・
モブ

タスク設計

タスク実行

テスト仕様

品質の確認
ビルド・CI

テスト実装

リリース

テスト実行

品質の確認
共有の形式化

7/16/2021

リスクリスト 仕様書

受入テスト
試験設計書

COPYRIGHT © ATSUSHI NAGATA

テスト
仕様書

59

アジャイル・クオリティ・モデル
サイボウズのアジャイル品質保証のアプローチ

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

60

アジャイル・クオリティ・モデルPlan

QAの方向性Observe

チームの方向性改善

OrientAction

アジャイル
アジャイル・クオリティ・モデル
QA
Decideチーム

Act
気づきStudy
メッセージ

フィードバック

フィードバック
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

61

OODA：QAがチームをサポートする

OrientObserve

DecideAct
品質情報
わかりやすいメッセージ
事実に基づくデータ

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

62

Planning : アジャイルQAの計画
品質ビックピクチャ
製品のビジョン

会社のビジョン

製品のコンセプト

品質ビジョン

会社のコンセプト

製品開発計画
品質コンセプト

品質ロードマップ

インセプションデッキが効果的です！

品質シナリオFundamental
技術

7/16/2021

メンタリティスキル

COPYRIGHT © ATSUSHI NAGATA

リソース

63

サイボウズのメンタリティ

7/16/2021〇 心理的安全性が高い〇お互いをリスペクトする: 謙虚〇 発言平等性が高い〇 新しいものを受け入れる：好奇心
COPYRIGHT © ATSUSHI NAGATA

64

StudyアジャイルQAは現場から学ぶ

現場の判断、アイデアをリスペクトする

現場はそんな単純なものではない
多くの課題が複合的にあり、制約条件もある

過去の成功事例や知見、外部の知見は、現在の現場にとっては仮説にすぎない。
現場から、もっと価値ある知見を学ぶことができる

それにより、さらに外部からの知見からも学ぶモチベーションが起こる

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

65

Action
学んだことで、QA自らの行動を変えていかなければならない
プランニングを見直すこと：Re-Planning• どのような変化が必要か策定する• ビジョン、コンセプト、目的、目標の調整• ロードマップ• 手法の変更

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

66

アジャイル・クオリティ・モデルPlan

QAの方向性Observe

チームの方向性改善

チームのQA自らをアジャイル・クオリティ・モデル
アジャイル・クオリティ・モデル
品質保証
Decide
変えていくをサポート
OrientAction

アジャイルQAAct

チーム
気づきStudy
メッセージ

フィードバック

フィードバック
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

67

さらなる広がり
活動範囲を広げるQA

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

68

2020/08/19

https://speakerdeck.com/yabbysan/qa-ga-in-production-defalse-huo-dong-niqu-rizu-mishi-metahua
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

69

2020/08/19

https://speakerdeck.com/cybozuinsideout/saibouzudata-centerwozhi-eruinhuraqafalsetiao-zhan
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

70

2020/08/19
https://speakerdeck.com/cybozuinsideout/qagabatukuroguzuo-cheng-woyatutemitahua
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

71

2020/08/19
https://speakerdeck.com/cybozuinsideout/qagabatukuroguzuo-cheng-woyatutemitahua
7/16/2021

COPYRIGHT © ATSUSHI NAGATA

72

まとめ

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

73

アジャイル・クオリティの品質保証
顧客価値を、製品及びサービスに組み込む活動

チーム全員が品質の組み込みにかかわり、つまり、Whole Teamで品質保証を行っている

その中でQAは、ソフトウェア品質のスペシャリストとして、品質のビックピクチャの観点を持ちながら、“製品の品質”を顧客視点で肌で感じ、“プロセスの品質”とバランスをもって品質保証が進化改善していくようサポートするロールである。

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

74

Testing in DevOps World, Amir Ghahrai, 2019, https://devqa.io/testing-in-devops/

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

75

バリューストリーム：顧客の価値を組み込んでいく活動の流れ

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

76

アジャイル・クオリティ
品質保証

品質保証
品質保証

品質保証

7/16/2021

品質保証

COPYRIGHT © ATSUSHI NAGATA

品質保証

77

ご清聴ありがとうございました
サイボウズ株式会社
開発本部

アジャイルクオリティ

永田敦

nagnagworld@gmail.com

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

78