狠狠撸

7/16/2021 COPYRIGHT ? ATSUSHI NAGATA 1
アジャイル?クオリティの探求
JaSST Niigata 2021
サイボウズ株式会社アジャイル?クオリティ永田敦
https://ja-jp.facebook.com/nasaearth/

永田敦
サイボウズ株式会社
開発本部
アジャイル?クオリティ
アジャイルの品質保証サポート
JSTQB Advanced Level Test Manager
Agile Inspection Maestro
SQiP 研究会研究コース４
派生開発推進協議会運営委員
Agile流派 Evolutionary(EVO)

本日のアジェンダ
1. アジャイル?クオリティ
2. 品質って何だろう
3. 品質保証とは
4. アジャイル?プロセスにおけるサポート
5. アジャイル?ドキュメント
6. アジャイル?クオリティ?モデル
7. さらなる広がり
8. まとめ

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

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

Tom Gilbさん
Agileの
生みの親の親
? 小さくレビュー
? 書き手にフィードバックする
? 測定し品質を判断する
? 改善をしてもらう
イテレーティブに行う
アジャイルなレビューにより早く学び、書き手とドキュメントを改善する

アジャイルの特長
早く、そして小さく、イテレーティブに評価しそこから学ぶ

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

フィードバック獲得の設計
三菱電機細谷泰夫：斥候としてのアジャイルプロセス活用の提案：SPI Japan 2012

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

DevQA
Dev QA
品質の
見える化
? レビュー
? テスト
? メトリクス
サポート
? Deploy 評価環境
暗黙的共有
リスク
課題
アクション
信頼関係
合意された形式的情報
2017

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

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

ローレックスはなぜ売れる
1000万円は超えるトゥールビヨン
人は、機能だけで価値を決めていない
https://housekihiroba.jp/shop/c/c01rxnw01/
https://www.jackroad.co.jp/blog/post/tourbillon
https://www.casio.com/jp/
watches/casio/product.LTP
-1129AA-7B/

さて、
これは、いくらの値を付けます？
私たちが売っているものは、
ソフトウェアという形がないロジックにより提供されるサービスの“価値”です。
皆さんは、その[価値]の対価として、お金をいただいてる、プロフェッショナルです

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

DevOps
インテグレーション
利用
活用
計画
設計
実装
テスト
モニタリング
開発とオペレーションのフリクションをなくし
CI/CDのプロセスを自動化

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

計画
設計
実装
? どのようにして
その価値を
作り込むのか

計画
設計
実装
テスト
その価値を
作り上げるのか
? 作り上げたものは、
その価値を満足するものなのか
振り返り
レビュー

計画
設計
実装
テスト
その価値を
作り上げるのか
? 作り上げたものは、
その価値を満足するものなのか
DevQA
振り返り
レビュー

リリース
品質の自信
利用
活用
計画
設計
実装
テスト
お客様に
使っていただく
私たちは、作り上げたものの
価値に自信が持てるか
振り返り
レビュー

リリース
品質の自信
利用
活用
計画
設計
実装
テスト
モニタリング
観測
顧客は、その価値に本当に満足しているか
振り返り
レビュー

利用
活用
計画
設計
実装
テスト
モニタリング
分析
学ぶ
? よりよい価値を、よりよく提供するにはどうしたらよいか
顧客からのフィードバックから
何を学ぶか
計画
設計
実装
テスト
振り返り
レビュー

品質＝価値をどのようにして提供し続けるのか
? どんな価値を提供すればよいのか
? どのようにしてその価値を作り上げるか
? 作り上げたものは、その価値を満足するものなのか
?私たちは、作り上げたものの価値に自信が持てるか
? 顧客は、その価値に本当に満足しているか
?顧客からのフィードバックから何を学ぶか
? よりよい価値を、よりよく提供するにはどうしたらよいか
計画
設計?実装
テスト
モニタリング
改善
学び
品質の自信

Deming Wheel
1950年デミングサイクル (Deming Wheelともいう)
1. 製品を設計する
2. 製品を製造ラインで製造し、テストをする
3. マーケットに投入する
4. マーケットリサーチを通して使用される中でテストする．そしてユーザー
は製品をどう思っているか、買わない人はなぜ買わないのかを解明する.
そして１に戻る：顧客の品質や価格に対する反応の観点から製品を設計し直
す。これをぐるぐると回す
1.設計
2. 製造
3.販売
4.調査

品質に対しての良いフィードバックを得たい
よいフィードバック
デリバリーする製品?サービスの品質が
良くなければならない
よい魅力的品質価値を生み出していきたい
お客様の判断＝フィードバックを手に入れたい

よいフィードバックとは
価値のアイデア：
こうすると、このようになってもっと嬉しい
顧客からの信頼、期待がある状態?関係
価値を提供できているからこそつかめる関係

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

品質保証とは（私の定義）
”顧客価値を製品、サービスに組み込むしくみ及び活動のこと”
なので、その活動はチームすべてのロールに分散している。＝ Whole Team
なお、顧客価値も、ここではバックログアイテム（要求）のことで、仮説であり、そ
れを主に作るPOもPBIに品質を組み込む品質保証を行っている。
チーム全員が品質の組み込みにかかわり、つまり、品質保証を行っているといえる。
カスタマーサポート, 顧客のモニター、顧客の調査分析チームも、仮説である顧客価
値が、本当に顧客にとって価値があるのかという情報を開発チームにフィードバック
してくれる。これも品質保証である。
この活動の結果：顧客がこちらの目論見通り満足し、
あるいは安心して使って“うれしい”と言っていただける

すべての人がかかわるバリューストリーム
利用
活用
計画
設計
実装
テスト
モニタリング
PM
PG,QA,UX
Technical Writer
PG,QA,UX,
Technical Writer
SRE
調査部
サポート
営業
QA,PM
顧客の情シス
パートナー
サポート
SRE
顧客
SRE
QA
PO
全員
DevQA
振り返り
レビュー

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

多様性が品質を支える
製品
品質
PO
QA
TE
Technical
Writer
アクセシビリティ
チーム
UX
Dev
観点
専門性
情報
知識

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

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

品質＝価値をどのようにして提供し続けるのか
? どのようにしてその価値を作り上げるか
? 作り上げたものは、その価値を満足するものなのか
? 私たちは、作り上げたものの価値に自信が持てるか
? 顧客は、その価値に本当に満足しているか
? 顧客からのフィードバックから何を学ぶか
よりよい価値を、よりよく提供するにはどうしたらよいか
Whole Team

QAは、バリューストリームに対してどういう貢献ができるか
QAは、短い周期で品質のフィードバックをする機会を繰り返し持つことができる
チームは、より早く気づきを得て
品質の作り込みを改善する
品質保証をサポートする
チームは、その品質の見える化により、
成果物の品質に自信を持つことができる
事実をもとにした品質情報を
できるだけ早くフィードバック
全体像からの品質のメッセージ
をフィードバック

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

アジャイルにおけるプロセス
決められたプロセスが守られているかどうかを管理することよりも
プロセスをつかさどる“人”と、人どうしのインタラクションがより重要なんだ
プロセスで何をするか、中身、質が重要だ
要求毎に、必要とするプロセスは変わる。それが適切にできるか
どのようなインプットが必要か：調査の必要性、プロトタイピング
成果物は、何が必要か：モデリング、ドキュメント、コード
どのようなタスクを、どんな順番で行うか：段取り、PFD (Process Flow Diagram）

アジャイルはプロセス
プロセスは、チームが決めるもの
チームが設計していくべきもの
プロセスを守るのではなく、要求の開発作業に適合する、最適なプロセスを設計する。
バックログ(要求）毎に、プロセスを設計する

開発プロセス：LeSSフレームワーク例
スプリント
PBI
Done
Sprint
Planning 2
リスク認識
タスク
計画
受入テスト
設計
仕様書変更
プロダクトバックログアイテム
設計?実装?テスト
Sprint
Review
Sprint
Panning 1
バックログ
説明
割り当て
タスク実行
モブ?アクティビティ

スプリントプランニング２
バックログ
タスク設計
テスト実装
タスク実行
懸
念
点
出
し
?
モ
ブ
QA
設計
テ
ス
ト
設
計
?
モ
ブ
仕
様
作
成
?
モ
ブ
PO
UIデザイン
リスクリスト仕様書受入テスト
試験設計書
テスト実行
品質の共有
品質の共有
共有の
形式化
品質の
埋込み
品質の
確認

懸念出し
リスクを洗い出す
未知：わからないこと
懸念：起こるかもしれない問題
調査
試行

懸念出し～例
? 仕様の不明点
? 設計?実装上の懸念
? 初めて、久しぶり
? 機能、コード、ライブラリ、言語
? わからないこと
? 構造、責務
? オプション
? エラー処理
? 条件、出かた、優先度、検出
? スコープ
? どこで実現するか
? 影響箇所、error prone、複雑度
? 非機能要求

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

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

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

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

受け入れ試験設計
QAが主体となってテスト設計をモブで行う
? ユーザストーリと受け入れ条件をどのよう
にテストしていくかを設計していく
? QA?Dev
? 新たなリスクへの気づき
? Dev?QA
? コードの構造をモデルなどで説明
? グレーボックステスト
? 自動テストと手動テストの仕分け
? DevとQAとのテストの仕分け
テスト設計＝開発の品質ゴールの明記とその共有

これによって出来上がる状態
QAメンバーも開発メンバーも、同じチームとなって、
同じゴールに向かって、走っていくことができる
Whole Teamで
上流での
品質を組み込みを行う

タスクの洗い出し
PBIごとに最適なプロセスを設計する
スプリントバックログの設計
どのような段取りで、品質を組み込むかの設計（計画）を
チーム（モブ）で行う
リスク分析
仕様書の確定
受入テスト設計の共有

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

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

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

アジャイル?モデリング
KeepsとTempsは、平鍋さんのアジャイル?モデリングのお話からいただいた
“アジャイル時代のモデリング”, 2014, 平鍋健児、チェンジビジョン
もちろん、モデルもアジャイル開発におい
て重要なドキュメントである。
? Keeps
? 開発の基盤となるモデル
? 変化はあまりない
? コードの動機をとり、保守をする
? 構成管理をする
? Temps
? コミュニケーション、共有理解のためのモデル
? テンポラリで保守は行わない

開発で使うドキュメントの種類
? Keeps
? 開発の軸となるドキュメント
? 保守をする＝コードと同期をとる
? 構成管理をする
? 例：機能仕様書、テスト仕様書
? Temps
? コミュニケーション、共有情報のためのドキュメント
? テンポラリで保守は行わない
? その開発バージョンのためのドキュメント
? 例：PBI、スプリントバックログ, 設計メモ
? バックログなどに紐づけて、検索できるようにしておく
とよい

ドキュメントの例: kintone開発
仕様書は、設計実装の前に、DevとQAが、モブで修正?追加変更される
Dev: 設計実装において、振る舞いのブレもぬけもれもない
QA : 仕様書という重要なテストベースを手に入れる
仕様書の品質がここで決まり、上流での品質が担保される
ドキュメント種類利用作成形態レビュー備考
PBI Temps バックログのライフサイクルで参照モブチーム全員リファインメント
リスクリスト Temps タスクを設計する際に用いるモブ Dev,QA
仕様書 Keeps 計画、開発のいろいろな場面で頻繁に参照されるモブ Dev,QA,PO POが後でレビュー
受け入れ試験設計書 Temps 受け入れ試験設計の共有のためモブ Dev,QA
テスト仕様書 Keeps 機能試験設計や回帰テスト設計で参照される QA個人 QA
タスク設計 Temps スプリントバックログアイテム策定のためモブ Dev,QA
アジャイル?モデル Temps 設計の際の理解のための共有情報モブ Dev QAも参照あり

スプリントプランニング２
バックログ
タスク設計
テスト仕様
タスク実行
懸
念
点
出
し
?
モ
ブ
QA
設計
テ
ス
ト
設
計
?
モ
ブ
仕
様
作
成
?
モ
ブ
PO
UIデザイン
リスクリスト仕様書受入テスト
試験設計書
テスト実行
品質の共有
品質の共有
共有の
形式化
品質の
埋込み
品質の
確認
ビルド?CI
品質の
確認
リリース
テスト実装
テスト
仕様書

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

Plan
Action
Study
Observe
Act
気づき
改善
アジャイル
QA
チーム
フィードバック
Orient
メッセージ
Decide
チームの
方向性
QAの
方向性

OODA：QAがチームをサポートする
Observe
Orient
Decide Act
わかりやすいメッセージ
事実に基づくデータ
品質情報

Planning : アジャイルQAの計画
品質ビックピクチャ
品質ビジョン
品質コンセプト
品質ロードマップ
品質シナリオ
メンタリティスキルリソース
技術
Fundamental
会社のビジョン
会社のコンセプト
製品のビジョン
製品のコンセプト
製品開発計画
インセプションデッキが
効果的です！

〇心理的安全性が高い
〇発言平等性が高い
〇お互いをリスペクトする: 謙虚
〇新しいものを受け入れる：好奇心
サイボウズのメンタリティ

Study
アジャイルQAは現場から学ぶ
現場の判断、アイデアをリスペクトする
現場はそんな単純なものではない
多くの課題が複合的にあり、制約条件もある
過去の成功事例や知見、外部の知見は、現在の現場にとっては仮説にすぎない。
現場から、もっと価値ある知見を学ぶことができる
それにより、さらに外部からの知見からも学ぶモチベーションが起こる

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

アジャイル?クオリティ?モデルアジャイル?クオリティ?モデル
Plan
Action
Study
Observe
Act
気づき
改善
アジャイル
QA チーム
Orient
メッセージ
Decide
チームの
方向性
QAの
方向性
QA自らを
変えていく
チームの
品質保証
をサポート

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

https://speakerdeck.com/yabbysan/qa-ga-in-production-defalse-huo-dong-niqu-rizu-mishi-metahua
2020/08/19

https://speakerdeck.com/cybozuinsideout/saibouzudata-centerwozhi-eruinhuraqafalsetiao-zhan
2020/08/19

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

まとめ

アジャイル?クオリティの品質保証
顧客価値を、製品及びサービスに組み込む活動
チーム全員が品質の組み込みにかかわり、
つまり、Whole Teamで品質保証を行っている
その中でQAは、
ソフトウェア品質のスペシャリストとして、
品質のビックピクチャの観点を持ちながら、
“製品の品質”を顧客視点で肌で感じ、
“プロセスの品質”とバランスをもって
品質保証が進化改善していくようサポートするロールである。

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

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

品質保証
品質保証
品質保証
品質保証
品質保証
品質保証

ご清聴ありがとうございました
サイボウズ株式会社
開発本部アジャイルクオリティ永田敦
nagnagworld@gmail.com

狠狠撸

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

Recommended

More Related Content

What's hot (20)

Similar to アジャイルクオリティの探求 (20)

More from atsushi nagata (11)

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