What should you shift left

1. シフトレフトって何をシフトするのなの？にしやすはる（@YasuharuNishi）

2. シフトレフトとは？ • Wikipedia（英語）によると、2001年に生まれた造語らしいの – “Shift-Left Testing” by Larry Smith @ Dr.Dobb’s journal • https://www.drdobbs.com/shift-left-testing/184404768 • （テストを）早くやれ、という意味のようなの – It is the first half of the maxim "Test early and often.“ • ソフトウェア業界の用語のはずなの… – セキュリティでも盛んに使われている様子 • DevSecOpsの文脈 – “製造業では「シフトレフト」という言葉があります。” • https://www.wantedly.com/hiringeek/interview/rc_kw3/ • 普通は使いませんよ… • 教科書的には、「フロントローディング」と呼ばれます – 某社さんは「前捌き」と呼びます © NISHI, Yasuharu p.2

3. シフトレフトはメリットがあるの？ • M-1などの賞レースにおける漫才で優勝するパターン – 後半でたたみ掛けるのがセオリー • ツカミ（登場）で中笑い、序盤で小笑いからリズムをつくり伏線を張り、中盤で展開を入れて大笑いにつなげ、終盤で伏線を回収しながらたたみ掛けて大爆笑で締める • その鉄則を逆手に取ったネタがあったの – 人気若手お笑いトリオ“四千頭身”の初期名作ネタ「やりたい事」 • ワタナベエンターテインメント所属・2016年結成のトリオ – 名ツッコミ：「前半にたたみ掛けるな！」 • https://www.youtube.com/watch?v=GN7oLLvmnqU – テレビ東京「そろそろにちようチャップリン」の録画 » 2ネタ目（3:04～）の3:46で登場 • 結論：漫才においてシフトレフトはメリットが無いのなの © NISHI, Yasuharu p.3

4. シフトレフトとは？ • Wikipedia（英語）によると、2001年に生まれた造語らしいの – “Shift-Left Testing” by Larry Smith @ Dr.Dobb’s journal • https://www.drdobbs.com/shift-left-testing/184404768 – Tru64 UNIXプロジェクトで実践していたらしいの • Alpha向け64ビットUNIX • 1980年台後半から1990年台前半？ • Larry Smithのシフトレフトのプラクティス – Involve QA early – Get test resources lined up at the start – Get tests into coding soon – Coding for Testablity – など © NISHI, Yasuharu p.4

5. シフトレフトとは？ • 2015年にCMU/SEIのDonald Firesmithがブログで分類したの – https://insights.sei.cmu.edu/blog/four-types-of-shift-left-testing/ – FiresmithはATAMやセキュリティユースケースで（も）有名なの • ATAM: Architecture Tradeoff Analysis Method • Firesmithの4つの分類 – Traditional Shift Left Testing • テストはより早いテストレベルを重点的に、という原則 – テストピラミッドはより下を重点的に、と捉えてもよい – Incremental Shift Left Testing • 開発を小分け（インクリメンタル）にすれば、まとめてテストするよりも早期になるよね、という話 – Agile/DevOps Shift Left Testing • この後モダンな話をするので読み飛ばそう – Model-Based Shift Left Testing • 実行可能な要求モデルや設計モデルでテストする話 © NISHI, Yasuharu p.5

6. モダンなシフトレフト • 考え方は分かるのなの… – とにかくいつでもテストするんですよねブロッコリーさん… © NISHI, Yasuharu p.6

7. モダンなシフトレフト • 分かる…分かります…分かった気がするのなの… – 開発ライフサイクルの話ですよねブロッコリーさん… © NISHI, Yasuharu p.7

8. モダンなシフトレフト • 他人の翻訳じゃなくて、あなたの話が聴きたいのブロッコリーさん！ • ブロッコリーさんの素晴らしい話： – 色々やった • テスト設計：テスト実施の比率を1:9から5：5にした • QAチーム内のレビューを手厚くした • など – QAメンバーの声が変わった • 「最近では『仕様です』と言われても、自分で考えて『これが仕様で良いのか』と、開発チームと議論できるようになった」 – QAメンバーがレビュアーとして開発に関わるようになった • 大きなフィーチャーに取りかかる前に事前に議論し、テスト観点出しやテストパターン作成をきっかけに仕様漏れを検知した © NISHI, Yasuharu p.8

9. モダンなシフトレフト • Googleの “Testing on the Toilet” – 事実、2005年まで、テストは規律として課されたプラクティスというより、物珍しいものに近かった • （テストの）大半は手動で行われた • 2006年にテスト革命が起こったの！ – オリエンテーション講習、テスト認定プログラム、TotT • Testing on the Toilet (TotT) – 2006年4月、Google社内全体のトイレの個室に、 Pythonでのテストを改善する方法を扱う短い記事が現れた – これだってシフトレフトじゃないなの？ © NISHI, Yasuharu p.9

10. シフトレフトって？ • 要するに、 – 開発の初期からちゃんと後工程（テストなど）について – 考えたり • QAやテストエンジニアと開発者が一緒に考えたり • 開発者自身が考えるようになったり – 実際に作業したりして • QAが要求や設計のレビューに加わったり • テスト設計をより上流で行って（コード無しで）要求や設計のバグを見つけたり • 上流のモデルベース/モデル駆動化を進めて（コード無しで）要求や設計のバグを見つけたり • トレーニングしたりTotTしたり – 後回しにする嫌なことを • 工数やコストが大幅に増えたり • 技術的負債ができたり • エンジニアが後悔してモチベーションが下がったり – 防ぐことなの！ • 工程や手順だけを前倒しする計画を作って実施するというマインドでは失敗する – いわんやツールやほげほげコーチをや © NISHI, Yasuharu p.10

11. じゃあ、開発者はシフトレフトで何を新たに考えればいいのなの？ • 品質意識の低い組織 – 上流から品質を上げるといいよ、というモダンな「常識」 • TDDや技術的負債など、今は知らない方がヤバいの！ • 品質意識も品質もそこそこの組織 – テスト設計の考え方？ • 網羅しろとか • 仕様に矛盾があるとか • 画面や操作に一貫性がないとか • ユースケース考えろとか • UX考えろとか – 「オレたちは確かにできてないかもしれないけど、 QAに偉そうに言われることでもない」 • シフトレフトは、本質的に開発者サイロとQAサイロを崩し Whole Team Approach （a.k.a.全員参加）を実現し、全員で品質意識を高めて品質文化を構築することなの！ • 品質意識も品質も高い組織 – もうできてるでしょなの © NISHI, Yasuharu p.11 なんかこう、 QAの技術が高いから開発が経緯を払う、という話ではないの

12. この図には、何かが足りないなの… © NISHI, Yasuharu p.12

13. この図には、バグがいないの！ © NISHI, Yasuharu p.13

14. そうだ！バグをシフトレフトしようなの！ © NISHI, Yasuharu p.14

15. そのためにバグの分析が必要になるの • バグ分析、と言っている人が目的だと思っていることランキング（にしの心の中調べ2022） 1位：よく分からないけどやることになっているからやる • ムダの極み 2位：バグの存在する場所を明らかにしてデバッグのための情報を得る • 必要な作業だが、今日話したいのはこのことではない 3位：経営や管理職、QA部門などが犯人捜しや「仕事してますエビデンス作成」のために行う • 百害あって一利なし 4位：バグの傾向を掴み手を打つ • 役に立ちそうに見えるが… © NISHI, Yasuharu p.15

16. バグ分析（RCA）には大きく分けて2つあるの • マクロ分析（バグの傾向分析） – 目的 • 組織全体としてどのチームにどんなバグが多いか、を把握する • プロダクトのどの部分にどんなバグが多いか、を把握する • 工程のどこでどんなバグが入りやすいか、を把握する – 代表的な技術 • フォールトプローン技術 • ODC（直交欠陥分析） – 問題点 • 施策が大味になりがちで、バグと施策が結びつかず、効果がでにくい傾向がある – 基本的にシフトレフトには向いてない • バグの中身や開発の中身をきちんと見る習慣が失われる傾向がある – 「QAは時間がない」は言い訳である • 傾向という名の数値が一人歩きする傾向がある – 管理図の統計的意味も分からずに折れ線グラフを描いて「〇〇管理図」とか言い出したりする • よほど注意して実施しないと、形骸化と官僚化の温床になる – マクロ分析からの間接施策（プロセスを決めろ/変えろ、この目標メトリクスを達成しろ）は最悪である • ミクロ分析（バグのパターン化） © NISHI, Yasuharu p.16

17. バグ分析には大きく分けて2つあるの • マクロ分析（バグの傾向分析） • ミクロ分析（バグのパターン化） – 目的 • バグ、もしくはバグの原因をパターン化して水平展開し、再発防止・未然防止を行う • 根本原因分析（RCA: Root Cause Analysis）やなぜなぜ分析として行われる – 代表的な技術 • キーワード分析 • 機能分析 • 現象分析 • 開発者属性分析 • プロセス分析 • 構造分析 • （欧米型）FMEAと呼ばれる一群の何か • ソフトウェアトラップ分析（不具合モード分析） – 問題点 • そもそも水平展開や再発防止・未然防止という用語の理解が曖昧である • 技術（パターンの抽出方法）によっては出来の悪いマクロ分析になる • よほど注意して実施しないと、吊し上げになり形骸化の温床になる © NISHI, Yasuharu p.17

18. バグのパターン化の（現場で使われている）技法 • キーワード分析 – 容易だが精度は低い • 例）「日次平均値算出機能」に対し、類似のキーワードを含む仕様や機能にバグが多いと推測する技法 • 機能分析 – 容易だが精度は低い • 例）「日次平均値算出機能」に対し、機能ツリーのうち近い機能にバグが多いと推測する技法 • 現象分析 – 容易だが精度は低い • 例）「日次平均値算出機能」がダウンしたとすると、ダウンしたバグを集めてパターン化する技法 • 通常は意味あるパターンは抽出できない © NISHI, Yasuharu p.18

19. バグのパターン化の（現場で使われている）技法 • 開発者属性分析 – 容易だが精度は低いし、やってはいけない • 開発者の体調や心理状態、経歴や出身に着目する技法 • 個人攻撃になったり人事評価につながるので、中長期的に悪さの情報が隠蔽されるので品質は下がっていき官僚化していく • プロセス分析 – 容易だが精度は低い • 「～を読んでない」「～を知らない」「～に従わない」「～を確認しない」「誤った～を読んだ」「～を誤って解釈した」のように分析する技法 • 構造分析 – そこそこ難しいが精度はそこそこ高い • 例）「日次平均値算出機能」がスタックを用いているとすると、スタックや類似した構造を用いている設計部位にバグが多いと推測する技法 • 例）「日次平均値算出機能」がスタックオーバーフローを起こしたとすると、スタックなどオーバーフローを起こしうる構造を用いている設計部位にバグが多いと推測する技法 © NISHI, Yasuharu p.19

20. バグのパターン化の（現場で使われている）技法 • ソフトウェアFMEAと呼ばれる一群の何か – 故障モードを機能や現象の抽象概念だと捉えると、精度が低くなってしまう • 欧米型は、ソフトウェアの各モジュールからの機能不動作（演算間違いや遅延など）を故障モードと捉えるため、内部的な現象分析になってしまう – 公表されている事例Aは、内部処理 x 能力 x 現象の3つ組に着目するため、内部的な機能分析や現象分析になってしまう – 公表されている事例Bは、データ間の構造の考慮不足などに着目している – 公表されている事例Cは、瞬断時の異常や他動作中の移動など、発生条件に着目している – 残念ながら、多くの書籍や論文、発表資料はあまり有益でないことが多い • そもそも故障モードはハードウェアのQCや信頼性工学でも議論が分かれる概念である – 電子素材のように固有技術的に確立しているらしい分野もあるようだ • 精度よく使っているハードウェア組織では、故障モードは設計ノウハウそのもののため、外部に公表する資料には掲載されない – だからDRBFMをソフトウェア屋が読むと変化点解析になってしまう – 著者はバグのパターン化ができないのかもしれないし、できるけど有益なパターンを外部に公表できないかもしれないし… © NISHI, Yasuharu p.20

21. ソフトウェアトラップ分析（不具合モード分析） • ソフトウェアトラップ（不具合モード）を含む仕様書や母体設計書から作られる構造や機能にはバグが多いと推測する技法 – 開発者がどこをどう間違えるか、に着目する技法 – ソフトウェアの入力成果物（仕様書や母体設計書）に開発者がバグを作り込んでしまう「トラップ（罠）」が含まれているため、開発者はそのトラップに引っかかってしまい吸い込まれるように出力成果物（設計書やソースコード）にバグを作り込んでしまう、という考え方である • 例）「優先順位の表現で1（高い）～5（低い）と5（高い）～1（低い）が混在すると混同しやすい」 • 河野哲也氏（現メルカリ）らが不具合モード分析として確立し、嬉野綾氏（ワークスアプリケーションズ）らがバグシェルジェ（ASTER）という研究グループで議論を進めている – 類似品に注意：水平展開やフロントローディングを行えない類似品もある © NISHI, Yasuharu p.21

22. ソフトウェアトラップ分析（不具合モード分析） • ソフトウェアトラップ（不具合モード）を含む仕様書や母体設計書から作られる構造や機能にはバグが多いと推測する技法 – トラップにはパターンがあるので、そのパターンをシフトレフトする • テストにシフトレフト：ピンポイントテストのテスト観点にする • レビューにシフトレフト：レビューのチェックリストに加える • 開発にシフトレフト：開発者に気をつけてもらったり、開発ガイドラインに記載する – 水平展開しシフトレフトするために分析するので、水平展開できそうもない/する必要のないバグは分析しない • 本当にうっかりしたために作ってしまったバグは分析しない – 本当にうっかりであれば、トラップに依存せずランダムに発生しているはず – 本当にうっかりではないのに開発者が「うっかり」と答えるのであれば、その組織はバグ分析を始める前にすべきことがある – トラップが全くイメージできないものは無理に抽出しない方がよい • 分析にはスキルや経験が必要である • 分析にはかなりの時間がかかるので腰を据えて行う必要がある – 分析に協力してくれる開発者がいる方が分析もシフトレフトも進む © NISHI, Yasuharu p.22

23. ソフトウェアトラップ分析（不具合モード分析） • ソフトウェアトラップ（不具合モード）を含む仕様書や母体設計書から作られる構造や機能にはバグが多いと推測する技法 – ソフトウェアの入力成果物（仕様書や母体設計書）に開発者がバグを作り込んでしまう「トラップ（罠）」が含まれているため、開発者はそのトラップに引っかかってしまい吸い込まれるように出力成果物（設計書やソースコード）にバグを作り込んでしまう、という考え方である • 入力成果物は開発者の思考プロセスへの入力なので、プログラミング言語仕様や直前に作成した成果物のこともある – 例） C言語で発生するif文での代入というバグは、混同しやすい=（代入）と==（比較）を同じ場所で使えるようにした言語仕様がトラップになっている » そのためMISRA-Cなどでは規格で禁止することで「フロントローディング」を行っている • トラップによって引き起こされる「人間の思考の誤り」を意識する – 一般的なヒューマンエラーは、実のところ「人間の思考の誤り」は取り扱っていない • 人間系の要因は「ブースター」として分離して取り扱う – 「前の晩に夜更かしして注意不足だった」はトラップではなくブースターである – ブースターを根本原因として取り扱うと、対策が大味になりがちで、バグと施策が結びつかず、効果がでにくい傾向がある © NISHI, Yasuharu p.23

24. トラップの例 • 実際に各社で抽出されたトラップの例（特定できないように一部改変しているところがあります） – 二卵性双生児 • 順序が逆のものが混在すると、混同しやすい – 優先順位の表現で1（高い）～5（低い）と5（高い）～1（低い）が混在すると混同しやすい – リトルエンディアンとビッグエンディアンが混在すると混同しやすい – True/false値（1/0）がハード側とソフト側で異なる • 対称であるべきものが一部非対称であると、混同しやすい – アームの行きの動きのルーチンと帰りの動きのルーチンが一部異なっている – ifdefでコンパイルし分けるコードのCPU使用率が異なるので処理が間に合わない – 例外 • 後から追加された例外的な仕様は、設計漏れを引き起こしやすい • 複数ある対となっている条件の両方に必要な正常処理は設計できたが、特定の対の片方の条件だけ例外的に必要となる準正常処理が抜けてしまった – 浦島太郎 • 割り込み先から帰ってきたら、割り込み元の状態が変わっていた – 「備考」 • 備考欄に書かれるものは、書かれないと問題が起こるほど重要なのに、本文に入れられるほど構造化されていないものである © NISHI, Yasuharu p.24

25. バグ分析会議の運営 • ダメなバグ分析会議 – 犯人捜し/責任追及・上司による責任回避 – 吊し上げ/晒し者 – 根拠のない思い込みと決めつけ、説教と自慢話 – その後の悪い人事評価 – 防御的心理 • よいバグ分析会議 – 「納得感」の「共感」を軸にしてバグの分析を行う • 自分でも引っかかってしまうと納得できるトラップを探す • 適切なパターン化ができた瞬間は、分析会議の参加者が「あーそのトラップにはみんな引っかかるよねー」と納得し、皆が共感するようになる – 開発者への敬意を前面に出す • 悪いのはトラップであって開発者ではない、という姿勢を崩さない – 「スキルの高いあなたで “すら” このトラップに引っかかるんですから、若い連中なんてなおのこと…」 – だからトラップ分析ではトラップとブースターを明確に区別している • バグを作り込んだ人という扱いではなく、トラップの情報を提供してくれる人として尊敬を前面に出すと、前向きの会議になって共感しやすくなる – 効率を求めてはいけない • 分析に時間がかかるのはスキルが低いからだが、時間をかけてよい分析をしない限りスキルは向上しない • 途中でみんな現場に戻りたくなって分析の質が落ちるところをグッと我慢してもらう © NISHI, Yasuharu p.25

26. バグ分析によるシフトレフトの注意点 • 開発者が「腕が上がった」と思える施策を立案する – 開発者の「こんなことやっても意味ないよな」という実感を大事にして、そうならないような施策を立案する – 「腕が上がった」と思ってくれれば、どんどん協力してくれるようになる • そのバグだけを未然防止できる具体的で小さな施策を立案し、少しずつ注意しながら施策を大きくする – 全社一律や部門全体に効きそうな施策は、結局のところ大味で誰の役にも立たない – 大味な施策ほど名前を付けやすいので、「仕事をした感」を出しやすい – 一発屋ではなくグルグル回るサイクルが重要 • 「あーもっと早く気づけたのに」という後悔ドリブンにする – 誰も後悔していないバグはフロントローディングできない – 後悔しているバグはトラップも見つけやすい • フロントローディングした作業のための工数をきちんと確保する – どんなバグが出そうか、を皆で考える会議を開発の最初にやる場合、きちんとプロセス名をつけて見積もりに載せて工数を確保しないと、「いつまでお喋りしてるんだよ、とっとと作れよ」という圧力をはねのけられない • パターン集を買おうとしない – バグ分析/RCAを上手にやれるようになるのは確かにしんどいが、しんどい原因は自組織に抽象化能力やパターン化、水平展開の能力が育っていないからである © NISHI, Yasuharu p.26

27. まとめ、なの • ブロッコリーさんを応援しよう、なの • シフトレフトには色々あるが、本質的に開発者サイロとQAサイロを崩し Whole Team Approach（a.k.a.全員参加）を実現し、全員で品質意識を高めて品質文化を構築するなの • バグをパターン化してシフトレフトするといいのなの – でも注意しないと組織が硬直化して逆効果なの © NISHI, Yasuharu p.27

What should you shift left

Esté a ler uma amostra.

Confira estes a seguir

What should you shift left

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a What should you shift left (20)

Mais de Yasuharu Nishi (17)

Mais recentes (20)