サイボウズのアジャイルクオリティ2024

Slide 1

Slide 1 text

Slide 2

Slide 2 text

永田敦サイボウズ株式会社開発本部アジャイル・クオリティ 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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

▌ 第1部アジャイルと品質 ⚫ 品質って何だろう ⚫ ソフトウェア開発の歴史 ⚫ ソフトウェア開発はＶＵＣＡだ ⚫ アジャイル開発へのモチベーション ⚫ 経験的プロセス ⚫ 顧客価値の最大化 ▌ 第2部サイボウズにおけるアジャイル・クオリティ ⚫ サイボウズの品質 ⚫ 品質を組みこむ ⚫ 品質を支える文化 ⚫ まとめ 4 アジェンダ 5/2023 copyright © Atsushi Nagata

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

5/2023 copyright © Atsushi Nagata 7 品質は誰かにとっての価値である誰か＝使っていただいているお客様 [価値] • サービスを使って満足している • 今後も使っていこうと思っている • もうこれなしでは仕事はできないと感じている • 効果の実績が出ているお客様は、そのサービスに価値を感じ、使い続け、対価を払うジェラルド・M・ワインバーグそのような価値を提供し続けること ⇒ 顧客価値の最大化

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

コンピュータの黎明期 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 大規模で複雑なシステムが可能顧客の要望：より高い品質で、時間どうりに、予算内で作られた製品を求めるしかし、大規模なシステムは、多くのものが失敗したとみなされていた

Slide 14

Slide 14 text

ソフトウェア開発手法黎明期 5/2023 copyright © Atsushi Nagata 14 事前に計画することはない設計は、その場で急ごしらいするか、もしくは、しないまま、いきなりコーディングに走る動かなかったら、デバッグする計画やテスト、レビューを負担に感じている Code and Fix development: 作ってから直す開発結果進捗に従い、手戻りが増え、新規機能の追加が滞るバグが蔓延し、修正が難しくなる。市場障害が起こる。バグが多いので、デバッグと再テストが重なり、スケジュールが伸びる

Slide 15

Slide 15 text

失敗：クライシスの原因 5/2023 copyright © Atsushi Nagata 15 • さらに多額の投資をしても、ソフトウェアが完成しないことがしばしば起こった。 • 完成したソフトウェアから欠陥やバグを取り除き、使えるようにする作業には、かなりの時間を要することが多かった。 • ソフトの機能とエンドユーザーの要求が一致することはほとんどなかった • 一度作ったソフトはほとんどメンテナンスができず、開発者が書いたものを理解する能力は時間とともにどんどん低下していくように見えた。

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

計画駆動型開発：ウォータフォール 5/2023 copyright © Atsushi Nagata 19 他の工学分野（主にハードウエア）の方法論を取り入れる ◦ 計画に強く重点を置いた規律あるプロセスを作る ◦ プロセスを守らせる ◦ 計画を守らせる取り入れる動機 ◦ より予測通りに開発をしたい ◦ 開発効率を上げたい ◦ 品質をあげたい効果（ある時期まで） ◦ 遅延プロジェクトが減少 ◦ バグが減少 ◦ 生産性が上がった ◦ メンテナンスコスト減少

Slide 20

Slide 20 text

▌ 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 コード量は限りなく増えシステムは複雑になるずっとソフトウェアクライシス

Slide 21

Slide 21 text

2023/4/12 「アジャイルと品質」オンデマンド研修 copyright © A.Nagata 21 ウォータフォール：計画駆動型開発の対処なんとか、時間と工数をかけて、成果物をより完全なものに近づけようとした要求・仕様：要求仕様書設計：設計書、モデル ● ドキュメント（プロセスの成果物）を作る ● プロセスを定義し、管理、監査する進捗を管理するドキュメントをレビューする品質ゲートを設ける多大な時間と労力を、計画とプロセスの管理にかけていった膨大なドキュメント多くの会議 ● より多くのテストをする ”実装後”に、動くコードに対してテストするプロジェクトの最後で多くの不具合が発見される計画・見積もり：ガントチャートなど完全なドキュメントは作れないテストでバグをゼロにはできない

Slide 22

Slide 22 text

計画駆動型手法で起こったこと 5/2023 copyright © Atsushi Nagata 22 起きてしまったこと ▪ 計画を守るために、要求の追加・変更を避けるようになる。 ▪ 予測通りにするために、計画に重点を置いたが、外れることも多い ▪ 外れたときの手戻りによるスケジュールのインパクトが大きい ▪ プロセスごとにサイロになるメンタリティ ▪ 組織的に官僚主義的になる ▪ プロセスを定義する部署（QA)と実施する現場が分離する ▪ その部署が、他で成功したプロセス、手法をそのまま現場に押し付けてしまう

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

▌Volatility 変動性 ⚫ 要求は変更される ▪ 顧客は、本当の要求に気づいていない ▪ 初めから本当の要求を正確に獲得することが難しい ⚫ 獲得しても、それは間違っているかもしれない ▪ 顧客は、動くシステムを見て、その価値に気づく ▪ 時間がたつにつれて、 ▪ 顧客の価値が変わる ▪ ビジネス環境が変わる 26 ソフトウェア開発はVUCAだ 2023/4/12 「アジャイルと品質」オンデマンド研修 copyright © A.Nagata 求められる価値を外す

Slide 27

Slide 27 text

Slide 28

Slide 28 text

▌Complexity 複雑性 ⚫ ソフトウェアが複雑になる ▪ 要求・仕様が複雑になる ▪ コードが複雑になる結合度,凝集度 ▪ アーキテクチャが複雑になる依存性 28 ソフトウェア開発はVUCAだ 2023/4/12 「アジャイルと品質」オンデマンド研修 copyright © A.Nagata 保守性、可読性が悪くなる ⚫ 本質的な複雑さ ⚫ 適合性 ⚫ 変更可能性 ⚫ 不可視性ソフトウェアの本質的な性質が複雑性に拍車をかける

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

5/2023 copyright © Atsushi Nagata 35 仮説が外れることへの対応アジャイル仮説をできるだけ早く検証し適応するループメカニズム〇仮説をできるだけ小さくするできるだけ小さく、かつ、検証して価値が分かる大きさに要求を分割 [バックログアイテム] 分割した要求ごとに開発し、検証できるコードをリリースし、顧客に検証してもらう〇分割した仮説ごとに検証する〇検証のフィードバックから学び〇適応する：仮説の修正

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

複雑なプロセス 5/2023 copyright © Atsushi Nagata 40 • 初めてのプロセス⇒定義が不十分、決められない • 完璧なプロセスの定義は至難の業 • ノイズが多い：入力のノイズ、プロセス内のノイズ • プロセスが複雑 ⇒ プロセスを繰り返し使ってみると、同じ結果にならない ⇒ 予測可能性が低い ⇒ プロセスの定義を守っても、予想通りの結果は得られないプロセス弱いプロセス定義複雑、ノイズ Input Output ノイズ予測不可能ノイズ

Slide 41

Slide 41 text

スクラムの考え方：経験的プロセス制御 5/2023 copyright © Atsushi Nagata 41 思いがけないことを監視し、順応させ、規則正しさと予測可能性を提供するためのフィードバックのメカニズムを採用しているスクラムチームのメンバーは彼らの技術、経験、状況をベースにして、最適のプロセスを作り、実行する。プロセス C I O 図2 経験的管理モデル：経験的プロセス制御のフィードバック I ：入力、または、要求、技術 (バックログ) プロセス : イテレーション（スプリント） C：プロセスのモニタ：ディリーミーティングスプリントレビュー O : イテレーションごとに出力されるインクリメンタルなコード Ken Schwaber, Mike Beedle, アジャイルソフトウェア開発スクラム (1)

Slide 42

Slide 42 text

5/2023 copyright © Atsushi Nagata 42 経験的プロセスの導入アジャイル : スクラム開発における仮説をイテレーティブに検証するようにした計画や見積もりや仕様、設計の仮説をイテレーティブ（スプリントごと）に検証する Plan : スプリント計画 Check : スプリントレビュー Do : ソフトウェア開発：仕様・設計・実装 Action : レトロスペクティブ（振り返り）スプリント

Slide 43

Slide 43 text

5/2023 copyright © Atsushi Nagata 43 スプリントでは、 • 計画どうりにスプリントを達成すること • 見積もりどおりに開発することをゴールとしていない⇒失敗＝予期していなかったことを重要視するイテレーションの長さを、短くすることにより、速く失敗に気づき、計画への不確実性の影響をできるだけ少なくできる期待がある。また、バックログが小さいほうが、不確実な事柄に気づき、対応することが期待できる失敗したままにしない⇒ 振り返り：学び、改善の活動プロセスの改善：プロセスがより適応したものに日々変わっていくソフトウェア開発で、イノベーティブなアイデアを実現するためのチャレンジは、避けられないからだ。従って、チャレンジする限り、不確実性をなくすことはできない。しかし、スプリントの学びと適用により、より効果的、効率的なプロセスの改善を促し、計画を調整することができ、よって、より不確実性を抑える改善ができる

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

5/2023 copyright © Atsushi Nagata 51 素早く適応する素早くピボットしても、品質は崩さない仕組み変化に対する努力と工夫 • 品質にインパクトする • コードが複雑になる • 可読性 • 保守性 • コードの追加変更で、副作用が出る • 障害が起こる • コードが部分最適になる素早くピボットする仕組み計画が変わるスプリント計画リリース計画手戻りが増えるプロダクトバックログソフトウェアエンジニアリング調査、設計、実装テスト、自動テスト

Slide 52

Slide 52 text

アジャイルにおける、変化に対する努力と工夫 5/2023 copyright © Atsushi Nagata 52 開発において、変化が起こるときのリスク：手戻りリファインメントで少しづつバックログを詳細化していく • 顧客価値が高いと思われるもの • 早くリリースして、顧客に評価してほしいものより価値のある機能から、順にスプリントで開発する大切な機能とは • 優先度の調整 • バックログをより明確化（リファインメント）する • より小さく分割することもある • 要求が変わるかもしれない • 新たな要求と入れ替えるかもしれない • 優先度が変わるかもしれない

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

品質保証：Quality Assurance(QA) 5/2023 copyright © Atsushi Nagata 66 ”顧客価値を、製品またはサービスに組み込む活動のこと” その活動はバリューチェーンにあるすべてのロールに分散している。＝ Whole Team チーム全員が品質の組み込みにかかわり、つまり、品質保証を行っているといえる。この活動の結果：顧客がこちらの目論見通り満足し、あるいは安心して使って“うれしい”と言っていただける

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

5/2023 copyright © Atsushi Nagata 76 質問する傾聴する回答する説明するコメントする相手をリスペクトする態度その上で自由に行える議論するベテランの人だって・間違える、知らないこともある・新人に学ぶこともある発言によって傷つけられることがない質問することにためらったり、恥ずかしく思う必要はない質問力をつける・コメントするより質問する・自分が誤っている、誤解しているかもしれないチャレンジする：“試してみよう！“ 失敗から、成功から学ぶ食わず嫌いをしない勇気自分とは違うところを学ぶ心理的安全性が高いお互いをリスペクトする: 謙虚発言平等性が高い新しいものを受け入れる：好奇心