サイボウズのアジャイルクオリティ2024

Transcript

1. サイボウズの アジャイル・クオリティ よりよい価値のあるソフトウェアを 提供し続けることをめざして アジャイル・クオリティ 永田 1 5/2023 copyright © Atsushi Nagata
2. 永田 敦 サイボウズ株式会社 開発本部 アジャイル・クオリティ JSTQB Advanced Level Test Manager Agile Inspection Maestro 2008年 JaSST Tokyo ベストスピーカ賞受賞（マインドマップとHAYST法） 2011年 JaSST Tokyo ベストスピーカ賞受賞（リスクベーステスト） 2011年 5WCSQ (5th World Congress of Software Quality: 上海) 2016年 6WCSQ(6th World Congress of Software Quality: London) 2021年 JaSST Niigata 2021 基調講演 アジャイル・クオリティの探求 その他発表、ワークショップ多数 SQiP研究会 研究コース４ 「アジャイルと品質」 主査 2024/4/25 サイボウズ 開運研修 copyright © Atsushi Nagata 2024 2
3. • クオリティ・品質という言葉を理解する • なぜ、アジャイル開発を行うのか、品質の面から理解する • サイボウズのアジャイル・クオリティの心を理解する 3 講義のコンセプト 5/2023 copyright © Atsushi Nagata よりよい価値のあるソフトウェアを 提供し続けることをめざして
4. ▌ 第1部 アジャイルと品質 ⚫ 品質って何だろう ⚫ ソフトウェア開発の歴史 ⚫ ソフトウェア開発はＶＵＣＡだ ⚫ アジャイル開発へのモチベーション ⚫ 経験的プロセス ⚫ 顧客価値の最大化 ▌ 第2部 サイボウズにおけるアジャイル・クオリティ ⚫ サイボウズの品質 ⚫ 品質を組みこむ ⚫ 品質を支える文化 ⚫ まとめ 4 アジェンダ 5/2023 copyright © Atsushi Nagata
5. 第1部 アジャイルと品質 アジャイルに対するモチベーション アジャイルと品質との関係 5/2023 copyright © Atsushi Nagata 5
6. 品質って何だろう 品質・クオリティは誰かにとっての価値？ 5/2023 copyright © Atsushi Nagata 6
7. 5/2023 copyright © Atsushi Nagata 7 品質は誰かにとっての価値である 誰か＝使っていただいているお客様 [価値] • サービスを使って満足している • 今後も使っていこうと思っている • もうこれなしでは仕事はできないと感じている • 効果の実績が出ている お客様は、そのサービスに価値を感じ、使い続け、対価を払う ジェラルド・M・ワインバーグ そのような価値を提供し続けること ⇒ 顧客価値の最大化
8. 5/2023 copyright © Atsushi Nagata 8 価値を提供し続ける活動と仕組み ソフトウェア開発 開発の課題 • 計画、見積もりを外す • アウトプットが出ない • 不具合が多い • 当たり前品質がない • 求められる価値を外す • アウトプットが求められるものと違う • 魅力的品質がない アウトカムが出ない
9. 狩野モデル 5/2023 copyright © Atsushi Nagata 9 顧客満足度 高い 低い 高い 低い 品質の 充足度 魅力的品質 当たり前品質 当たり前品質を やたら上げても 満足はさほど上 がらない 当たり前品質が 低いと 顧客満足度はす ごく悪くなる 魅力的品質が 悪くても 満足度は落ちない 魅力的品質が 上がれば 満足度も上がる
10. 魅力的品質の当たり前化（コモディティ 化） 5/2023 copyright © Atsushi Nagata 10 なぜ、我々は、新機能を作り続けなければならないか その時、なぜ、品質が必要なのか 当たり前品質 魅力的品質 魅力的品質しきい線 障害 障害 もはや、魅力的製品と 扱われない 時間 リリース 顧客 価値
11. 顧客満足を達成するためには 5/2023 copyright © Atsushi Nagata 11 私たちは 当たり前品質を必要十分に確保しつつ 魅力的品質をリリースし続ける イノベーティブな開発活動を継続しければならない それに対して、今までどう対処してきたのだろうか？
12. ソフトウェア開発の歴史 それは品質との戦いの歴史 5/2023 copyright © Atsushi Nagata 12
13. コンピュータの黎明期 5/2023 copyright © Atsushi Nagata 13 ソフトウエア・クライシス “The Software Crisis”. Euromed Marseille School of Management, World Med MBA Program - Information Systems and Strategy Course. • 1954 FORTRAN • 1958 ALGOL • 1959 COBOL • 1946 ENIAC 最初の電算機 • 1951 UNIVAC 工芸品から商用機へ • 1664 IBM360 大規模で複雑なシステムが可能 顧客の要望： より高い品質で、 時間どうりに、 予算内で作られた製品を求める しかし、大規模なシステムは、多くのものが失敗したとみなされていた
14. ソフトウェア開発手法 黎明期 5/2023 copyright © Atsushi Nagata 14 事前に計画することはない 設計は、その場で急ごしらいするか、 もしくは、しないまま、いきなりコーディングに走る 動かなかったら、デバッグする 計画やテスト、レビューを負担に感じている Code and Fix development: 作ってから直す開発 結果 進捗に従い、手戻りが増え、新規機能の追加が滞る バグが蔓延し、修正が難しくなる。市場障害が起こる。 バグが多いので、デバッグと再テストが重なり、スケジュールが伸びる
15. 失敗：クライシスの原因 5/2023 copyright © Atsushi Nagata 15 • さらに多額の投資をしても、ソフトウェアが完成しないことがしばしば起こった。 • 完成したソフトウェアから欠陥やバグを取り除き、使えるようにする作業には、かな りの時間を要することが多かった。 • ソフトの機能とエンドユーザーの要求が一致することはほとんどなかった • 一度作ったソフトはほとんどメンテナンスができず、開発者が書いたものを理解する 能力は時間とともにどんどん低下していくように見えた。
16. 5/2023 copyright © Atsushi Nagata 16 価値を提供し続ける活動と仕組み ソフトウェア開発 開発の課題 • 計画、見積もりを外す • アウトプットが出ない • 不具合が多い • 当たり前品質がない • 求められる価値を外す • アウトプットが求められるものと違う • 魅力的品質がない アウトカムが出ない
17. 1970 Royce 5/2023 copyright © Atsushi Nagata 17 システム 要求 要求 分析 設計 実装 テスト 運用 https://www.praxisframework.org/files/royce1970.pdf ウォーターフォールモデル
18. Royceのモデル 5/2023 copyright © Atsushi Nagata 18 連続する開発フェーズ間の反復的な関係 戻ることを認めている ⇒ ウォーターフォールではない
19. 計画駆動型開発：ウォータフォール 5/2023 copyright © Atsushi Nagata 19 他の工学分野（主にハードウエア）の方法論を取り入れる ◦ 計画に強く重点を置いた規律あるプロセスを作る ◦ プロセスを守らせる ◦ 計画を守らせる 取り入れる動機 ◦ より予測通りに開発をしたい ◦ 開発効率を上げたい ◦ 品質をあげたい 効果 （ある時期まで） ◦ 遅延プロジェクトが減少 ◦ バグが減少 ◦ 生産性が上がった ◦ メンテナンスコスト減少
20. ▌ 1981 マイクロコンピュータの普及 IBM-PC発売 ▌ 1982 ワークステーション SUN microsystems SUN-1 ▌ 1983 分散処理システム Xerox社PARC：Ethernet開発 ▌ 1984 Apple Macintosh ▌ 1988 トロン協会発足 ▌ 1989 ネットワーキング WWW CERN ▌ 1990 RISC ワークステーション ▌ 1991 オープンシステム LINUX ▌ 1992 SH-1組込み機器用32ビットRISC ▌ 1995 Windows 95 ▌ 1997 クラウドコンピューティング ▌ 2001 Windows XP ▌ 2001 Mac OS X v10.0 ▌ 2006 Amazon EC2/S3 ▌ 2007 組み込みLINUX Android ▌ 2010 Microsoft Azure ▌ 2012 マイクロサービス 20 ずっとソフトウェアクライシス 2023/4/12 「アジャイルと品質」 オンデマンド研修 copyright © A.Nagata コード量は限りなく増え システムは複雑になる ずっとソフトウェアクライシス
21. 2023/4/12 「アジャイルと品質」 オンデマンド研修 copyright © A.Nagata 21 ウォータフォール：計画駆動型開発の対処 なんとか、時間と工数をかけて、成果物をより完全なものに近づけようとした 要求・仕様： 要求仕様書 設計： 設計書、モデル • ドキュメント（プロセスの成果物）を作る • プロセスを定義し、管理、監査する 進捗を管理する ドキュメントをレビューする 品質ゲートを設ける 多大な時間と労力を、計画とプロセスの管理にかけていった 膨大なドキュメント 多くの会議 • より多くのテストをする ”実装後”に、動くコードに対してテストする プロジェクトの最後で 多くの不具合が発見される 計画・見積もり：ガントチャートなど 完全な ドキュメントは 作れない テストで バグをゼロには できない
22. 計画駆動型手法で起こったこと 5/2023 copyright © Atsushi Nagata 22 起きてしまったこと ▪ 計画を守るために、要求の追加・変更を避けるようになる。 ▪ 予測通りにするために、計画に重点を置いたが、外れることも多い ▪ 外れたときの手戻りによるスケジュールのインパクトが大きい ▪ プロセスごとにサイロになる メンタリティ ▪ 組織的に官僚主義的になる ▪ プロセスを定義する部署（QA)と実施する現場が分離する ▪ その部署が、他で成功したプロセス、手法をそのまま現場に押し付 けてしまう
23. プロジェクトの成功率 5/2023 copyright © Atsushi Nagata 23 Standish Group 2015 Chaos Report
24. 2023/4/12 「アジャイルと品質」 オンデマンド研修 copyright © A.Nagata 24 なぜ、プロジェクトは失敗するのか それは、 ソフトウェア開発がVUCAだから
25. ソフトウェア開発はＶＵＣＡだ Volatility 変動性 Uncertainty不確実性 Complexity 複雑性 Ambiguity 曖昧性 5/2023 copyright © Atsushi Nagata 25
26. ▌Volatility 変動性 ⚫ 要求は変更される ▪ 顧客は、本当の要求に気づいていない ▪ 初めから本当の要求を正確に獲得することが難し い ⚫ 獲得しても、それは間違っているかもしれない ▪ 顧客は、動くシステムを見て、その価値に気づく ▪ 時間がたつにつれて、 ▪ 顧客の価値が変わる ▪ ビジネス環境が変わる 26 ソフトウェア開発はVUCAだ 2023/4/12 「アジャイルと品質」 オンデマンド研修 copyright © A.Nagata 求められる価値を外す
27. ▌Uncertainty 不確実性 ⚫ 初めから、すべてのリスクを認識することは非常に 難しい ⚫ 設計におけるチャレンジ • やってみないとわからない ⚫ プロセスどおりにやったとしても、期待どおりの結 果が出ない 27 ソフトウェア開発はVUCAだ 2023/4/12 「アジャイルと品質」 オンデマンド研修 copyright © A.Nagata 計画も見積もりも外れる
28. ▌Complexity 複雑性 ⚫ ソフトウェアが複雑になる ▪ 要求・仕様が複雑になる ▪ コードが複雑になる 結合度,凝集度 ▪ アーキテクチャが複雑になる 依存性 28 ソフトウェア開発はVUCAだ 2023/4/12 「アジャイルと品質」 オンデマンド研修 copyright © A.Nagata 保守性、可読性が悪くなる ⚫ 本質的な複雑さ ⚫ 適合性 ⚫ 変更可能性 ⚫ 不可視性 ソフトウェアの本質的な性質が複雑性に拍車をかける
29. ▌Ambiguity 曖昧性 ⚫ 要求や仕様をドキュメントに完璧に表現することは難しい ▪ したがって、それを伝達共有することが難しい 29 ソフトウェア開発はVUCAだ 2023/4/12 「アジャイルと品質」 オンデマンド研修 copyright © A.Nagata 求められる価値を外す 不具合が生まれやすい
30. 5/2023 copyright © Atsushi Nagata 30 ソフトウェア開発のＶＵＣＡな性格 • 計画、見積もりを外す • アウトプットが目論見通り出ない • 不具合を起こしてしまう • 当たり前品質がわるい • 求められる価値を外す • アウトプットが求められるものと違う • 魅力的品質がない Ｖ Ｕ Ｃ Ａ これらは、必然的に起きてしまうもの
31. ウォータフォールのアプローチ 5/2023 copyright © Atsushi Nagata 31 計画駆動型開発：ウォータフォール ◦ プロセスは、プロセス定義通り行えば、想定通りの出力を出す ◦ プロジェクトは、プロセスを守れば計画通りに行われ、終了する ソフトウェア開発のＶＵＣＡな性格 より厳密にプロセスを定義し、計画通りに行うために より多くの時間と労力を費やした
32. アジャイル開発へのモチベーション なぜ、我々はアジャイル開発をしているのか 5/2023 copyright © Atsushi Nagata 32
33. アジャイルのアプローチ 5/2023 copyright © Atsushi Nagata 33 ソフトウェア開発のＶＵＣＡな性格 ⚫ 必然的なものと受け入れる • プロセスの出力は、予測を外すことがある • 計画も外れることがある ⚫ 適応していく • 仮説検証 • 経験的プロセス
34. 仮説検証 5/2023 copyright © Atsushi Nagata 34 要望も仮説 要求＝バックログは仮説 仕様も仮説 設計も仮説 実装も仮説 テストは、仕様（仮説）どうりに実装されたかどうかを確認 正しく作られているかを確認すること - Verification 製品を顧客にリリースし、顧客が、その製品の価値を“検証“する ◦ 作られていることが正しいことを確認する - Validation
35. 5/2023 copyright © Atsushi Nagata 35 仮説が外れることへの対応 アジャイル 仮説をできるだけ早く検証し適応するループメカニズム 〇 仮説をできるだけ小さくする できるだけ小さく、かつ、検証して価値が分かる大きさに要求を分割 [バックログアイテム] 分割した要求ごとに開発し、検証できるコードをリリースし、 顧客に検証してもらう 〇分割した仮説ごとに検証する 〇検証のフィードバックから学び 〇適応する：仮説の修正
36. 仮説検証の比較 5/2023 copyright © Atsushi Nagata 36 開始 評価 開始 開始 開始 評価 出荷 出荷 出荷 出荷 計画駆動開発：ウォータフォール アジャイル 改善？ 検証 改善 検証 改善 検証 改善 開発 仮説 仮説 仮説 検証 計画 予測 出荷 検証 改善 仮説 出荷 検証 改善 仮説
37. アジャイルは早いのか？ 5/2023 copyright © Atsushi Nagata 37 真のゴール 初期のゴール 最初の リリース アジャイル 最初の リリース
38. 経験的プロセス 複雑なプロセスに対する適応的アプローチ スクラムは、経験的プロセスである 5/2023 copyright © Atsushi Nagata 38
39. 定義プロセス制御モデル 5/2023 copyright © Atsushi Nagata 39 プロセスは、プロセス定義の通り処理を行う ⇒ プロセスを繰り返しても、毎回同じ結果が得られる ⇒ 予測可能性が高い ⇒ 管理と制御ができる ⇒ プロセスの定義を守っていれば、予想通りの結果が得られる プロセス プロセス定義 Input Output 予測可能 計画駆動型手法のプロセス制御モデル
40. 複雑なプロセス 5/2023 copyright © Atsushi Nagata 40 • 初めてのプロセス⇒定義が不十分、決められない • 完璧なプロセスの定義は至難の業 • ノイズが多い：入力のノイズ、プロセス内のノイズ • プロセスが複雑 ⇒ プロセスを繰り返し使ってみると、同じ結果にならない ⇒ 予測可能性が低い ⇒ プロセスの定義を守っても、予想通りの結果は得られない プロセス 弱いプロセス定義 複雑、ノイズ Input Output ノイズ 予測不可能 ノイズ
41. スクラムの考え方：経験的プロセス制御 5/2023 copyright © Atsushi Nagata 41 思いがけないことを監視し、順応させ、規則正しさと予測可能性を 提供するためのフィードバックのメカニズムを採用している スクラムチームのメンバーは彼らの技術、経験、状況をベースにして、 最適のプロセスを作り、実行する。 プロセス C I O 図2 経験的管理モデル：経験的プロセス制御のフィードバック I ：入力、または、要求、技術 (バックログ) プロセス : イテレーション（スプリント） C：プロセスのモニタ：ディリーミーティング スプリントレビュー O : イテレーションごとに出力される インクリメンタルなコード Ken Schwaber, Mike Beedle, アジャイルソフトウェア開発 スクラム (1)
42. 5/2023 copyright © Atsushi Nagata 42 経験的プロセスの導入 アジャイル : スクラム 開発における仮説をイテレーティブに検証するようにした 計画や見積もりや仕様、設計の仮説をイテレーティブ（スプリントごと）に検証する Plan : スプリント計画 Check : スプリントレビュー Do : ソフトウェア開発： 仕様・設計・実装 Action : レトロスペクティブ（振り返り） スプリント
43. 5/2023 copyright © Atsushi Nagata 43 スプリントでは、 • 計画どうりにスプリントを達成すること • 見積もりどおりに開発すること をゴールとしていない⇒失敗＝予期していなかったことを重要視する イテレーションの長さを、短くすることにより、速く失敗に気づき、 計画への不確実性の影響をできるだけ少なくできる期待がある。 また、バックログが小さいほうが、不確実な事柄に気づき、対応することが期待できる 失敗したままにしない⇒ 振り返り：学び、改善の活動 プロセスの改善：プロセスがより適応したものに日々変わっていく ソフトウェア開発で、イノベーティブなアイデアを実現するためのチャレンジは、避けられないからだ。 従って、チャレンジする限り、不確実性をなくすことはできない。 しかし、スプリントの学びと適用により、より効果的、効率的なプロセスの改善を促し、 計画を調整することができ、よって、より不確実性を抑える改善ができる
44. 顧客価値の最大化 アジャイル開発で最もやりたいこと サイボウズでやりたいこと 5/2023 copyright © Atsushi Nagata 44
45. 5/2023 copyright © Atsushi Nagata 45 顧客価値の最大化のためには 当たり前品質を必要十分に確保しつつ 魅力的品質をリリースし続ける イノベーティブな開発活動を継続する 顧客の想定以上の価値を持つ製品やサービスを ジャストインタイムで提供する
46. 要求と価値 5/2023 copyright © Atsushi Nagata 46 要求満足 仮説で作られたものを お客様にリリースしたということ 価値満足 リリースしたものが、お客様にその価値を認められて、 代償が払われ、見えてきたその結果が、Outcome Output Outcome
47. 5/2023 copyright © Atsushi Nagata 47 お客様が価値を評価する： Validation システムに触れ、機能を体験してみないとわからない システムを触り、機能を体験できる、 動くコードを提供する
48. 5/2023 copyright © Atsushi Nagata 48 バックロ グと計画 コードの 開発 動くコードを 提供する お客様が 価値を評価する お客様が 新たな価値に 気づく お客様が 要求を変え 追加する 要求の フィード バック 要求の トレードオフ より高い 価値に 要求が 変化する 素早く 要求を ピボットする 変化する 要求を ジャストイン タイムに開発 お客様の より高い 価値への変化に 素早く適応する Adaptive 仮説を 立てる
49. より高い価値を提供する 5/2023 copyright © Atsushi Nagata 49 この価値ループをできるだけ早く回す 価値があるのかを確認する：仮説の検証 より高い価値があることに気づいてもらい、それを フィードバックしてもらう そのフィードバックから、より価値のある要求を出す
50. 5/2023 copyright © Atsushi Nagata 50 顧客価値 高い ゴール （実際） 要求 変更 計画 ゴール (計画） 修正ゴール （計画） リリース と 顧客からの フィードバック ウォータフォール 推定される価値 実際の価値 アジャイル アジャイルは、より価値を生む変化を引き出し、作り出す 時間 最終リリース 受け入れ テスト
51. 5/2023 copyright © Atsushi Nagata 51 素早く適応する 素早くピボットしても、 品質は崩さない仕組み 変化に対する努力と工夫 • 品質にインパクトする • コードが複雑になる • 可読性 • 保守性 • コードの追加変更で、副作用が出る • 障害が起こる • コードが部分最適になる 素早くピボットする仕組み 計画が変わる スプリント計画 リリース計画 手戻りが増える プロダクトバックログ ソフトウェアエンジニアリング 調査、設計、実装 テスト、自動テスト
52. アジャイルにおける、変化に対する努力と工夫 5/2023 copyright © Atsushi Nagata 52 開発において、変化が起こるときのリスク：手戻り リファインメントで少しづつバックログを詳細化していく • 顧客価値が高いと思われるもの • 早くリリースして、顧客に評価してほしいもの より価値のある機能から、順にスプリントで開発する 大切な機能とは • 優先度の調整 • バックログをより明確化（リファインメント）する • より小さく分割することもある • 要求が変わるかもしれない • 新たな要求と入れ替えるかもしれない • 優先度が変わるかもしれない
53. プロダクトバックログの構造 5/2023 copyright © Atsushi Nagata 53 すぐに手を付ける サイズが小さい 仕様は詳細に 詰めている サイズが大きい 仕様はまだ大まかに 決めてある まだすぐには 手を付けない 優先順位 高い 低い
54. プロダクトバックログのグルーミング 5/2023 copyright © Atsushi Nagata 54 バックログ リファインメント オリジナルの 大きなバックログ バックログの 優先順位付変更 バックログの割り込み プロダクトバックログをより明確化し、見積もりをする サイズ プロダクトバックログアイテム バックログ削除
55. 第2部 サイボウズにおけるアジャイル・クオリティ サイボウズの品質 5/2023 copyright © Atsushi Nagata 55
56. サイボウズの品質 バリューチェーン 5/2023 copyright © Atsushi Nagata 56
57. 価値の創造と流れ：バリューストリーム 5/2023 copyright © Atsushi Nagata 57 計画 ⚫ どんな価値を提供すればよいのか 主役：PM PG, QA Design ライター がかかわる
58. 価値の創造と流れ：バリューストリーム 5/2023 copyright © Atsushi Nagata 58 計画 設計 実装 ⚫ どのようにして その価値を 作り上げるのか 主役：PG QA、Design ライター がかかわる
59. 価値の創造と流れ：バリューストリーム 5/2023 copyright © Atsushi Nagata 59 計画 設計 実装 テスト ⚫ どのようにして その価値を 作り上げるのか ⚫ 作り上げたものは、 その価値を満足するものなのか
60. 価値の創造と流れ：バリューストリーム 5/2023 copyright © Atsushi Nagata 60 インテグレーション リリース 品質の自信 利用 活用 計画 設計 実装 テスト お客様に 使っていただく 私たちは、作り上げたものの 価値に自信が持てるか
61. 価値の創造と流れ：バリューストリーム 5/2023 copyright © Atsushi Nagata 61 インテグレーション リリース 品質の自信 利用 活用 計画 設計 実装 テスト モニタリング 観測 ⚫ 顧客は、その価値に本当に満足しているか
62. 価値の創造と流れ：バリューストリーム 5/2023 copyright © Atsushi Nagata 62 インテグレーション リリース 品質の自信 利用 活用 計画 設計 実装 テスト モニタリング 分析 学ぶ ⚫ よりよい価値を、よりよく提供するにはどうしたらよいか 顧客からのフィードバックから 何を学ぶか
63. すべての人がかかわるバリューストリーム 5/2023 copyright © Atsushi Nagata 63 インテグレーション リリース 品質の自信 利用 活用 計画 設計 実装 テスト モニタリング PM PG,QA,Design Technical Writer PG,QA Design 調査部 サポート 営業 QA,PM 顧客の情シス パートナー サイボウズサポート 顧客 SRE 全員
64. Whole Team パターン 5/2023 copyright © Atsushi Nagata 64 “だれも”が品質＝価値を作り上げることに貢献している それぞれの役割において 多様な観点によって、補い、コラボし ”提供する価値”に責任を持っている
65. 多様性が品質を支える 5/2023 copyright © Atsushi Nagata 65 製品品質 PM QA Test Engineer Technical Writer アクセシビリティ チーム Design PG 観点 専門性 情報 知識
66. 品質保証：Quality Assurance(QA) 5/2023 copyright © Atsushi Nagata 66 ”顧客価値を、製品またはサービスに組み込む活動のこと” その活動はバリューチェーンにあるすべてのロールに分散している。＝ Whole Team チーム全員が品質の組み込みにかかわり、つまり、品質保証を行っているといえる。 この活動の結果：顧客がこちらの目論見通り満足し、 あるいは安心して使って“うれしい”と言っていただける
67. ロールとしてのQA 5/2023 copyright © Atsushi Nagata 67 QA（品質保証担当）は、 • ソフトウェア品質のスペシャリストとして、 • 品質のビックピクチャの観点を持ちながら、 • 製品の品質を顧客視点で肌で感じ、 • 製品の品質とプロセスの品質とバランスをもって • Whole Teamが支える品質保証が進化改善していくよう サポートするロールである。
68. 品質を組みこむ できるだけ早く、品質情報のフィードバックをする 5/2023 copyright © Atsushi Nagata 68
69. バリューストリーム 5/2023 copyright © Atsushi Nagata 69 インテグレーション リリース 品質の自信 利用 活用 計画 設計 実装 テスト モニタリング PM PG,QA,Design Technical Writer PG,QA Design 調査部 サポート 営業 QA,PM 顧客の情シス パートナー サイボウズサポート 顧客 SRE 全員 スコープはここ
70. 例：kintoneの開発プロセス 5/2023 copyright © Atsushi Nagata 70 スプリント Sprint Planning 2 リスク認識 タスク 計画 受入テスト 設計 仕様書変更 プロダクトバックログアイテム 設計・実装・テスト Sprint Review Sprint Panning 1 バックログ 説明 割り当て タスク実行 モブ・アクティビティ リファインメント
71. スプリントプランニング２ 5/2023 copyright © Atsushi Nagata 71 バックログ タスク設計 テスト実装 タスク実行 懸 念 点 出 し ・ モ ブ QA 設計 テ ス ト 設 計 ・ モ ブ 仕 様 作 成 ・ モ ブ PM UIデザイン リスクリスト 仕様書 受入テスト 試験設計書 テスト実行 品質の共有 品質の共有 共有の 形式化 品質の 埋込み 品質の 確認
72. これによって出来上がる状態 5/2023 copyright © Atsushi Nagata 72 QAメンバーも開発メンバーも、同じチームとなって、 同じゴールに向かって、走っていくことができる Whole Teamで 上流での 品質を組み込みを行う
73. 5/2023 copyright © Atsushi Nagata 73 品質の埋め込み方（プロセス）は、各チームで違っています 計画 設計 実装 テスト ⚫ どのようにして その価値を 作り上げるのか ⚫ 作り上げたものは、 その価値を満足するものなのか DevQA 振り返り レビュー
74. 品質を支える文化 サイボウズの文化 5/2023 copyright © Atsushi Nagata 74
75. 5/2023 copyright © Atsushi Nagata 75 〇 心理的安全性が高い 〇 発言平等性が高い 〇お互いをリスペクトする: 謙虚 〇 新しいものを受け入れる：好奇心 サイボウズのメンタリティ
76. 5/2023 copyright © Atsushi Nagata 76 質問する 傾聴する 回答する 説明する コメントする 相手をリスペクトする態度 その上で自由に行える 議論する ベテランの人だって ・間違える、知らないこともある ・新人に学ぶこともある 発言によって 傷つけられる ことがない 質問することに ためらったり、 恥ずかしく思う 必要はない 質問力をつける ・コメントするより 質問する ・自分が誤っている、 誤解しているかもしれない チャレンジする：“試してみよう！“ 失敗から、成功から学ぶ 食わず嫌いをしない勇気 自分とは違うところを学ぶ 心理的安全性が高い お互いをリスペクトする: 謙虚 発言平等性が高い 新しいものを受け入れる：好奇心
77. 5/2023 copyright © Atsushi Nagata 77 やりがい エンジン 学習 エンジン 謙虚 尊敬 信頼 心理的安全性 共創 エンジン オープン 自律 Whole Team 感謝 挑戦 エンジン さら な る 高 みへ ス ケール 多 様 性 新 たな挑戦 仲間を 増やしたい！ 進化する チーム
78. まとめ 5/2023 copyright © Atsushi Nagata 78 サイボウズが提供するサービスの品質とは お客様にとっての価値である 品質＝価値はチームの皆が支え責任をもつ 品質＝価値のバリューストリームを回そう それを支えるメンタリティを持ってます
79. おしまい 質問・コメントをお待ちしております アジャイルクオリティ 永田 5/2023 copyright © Atsushi Nagata 79 https://bozuman.s.cybozu.com/k/#/space/6465/thr ead/49189