SlideShare a Scribd company logo
シフトレフトって何をシフトするのなの?
にし やすはる(@YasuharuNishi)
シフトレフトとは?
• 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
シフトレフトはメリットがあるの?
• M-1などの賞レースにおける漫才で優勝するパターン
– 後半でたたみ掛けるのがセオリー
• ツカミ(登場)で中笑い、序盤で小笑いからリズムをつくり伏線を張り、
中盤で展開を入れて大笑いにつなげ、終盤で伏線を回収しながらたたみ掛けて大爆笑で締める
• その鉄則を逆手に取ったネタがあったの
– 人気若手お笑いトリオ“四千頭身”の初期名作ネタ「やりたい事」
• ワタナベエンターテインメント所属・2016年結成のトリオ
– 名ツッコミ:「前半にたたみ掛けるな!」
• https://www.youtube.com/watch?v=GN7oLLvmnqU
– テレビ東京「そろそろにちようチャップリン」の録画
» 2ネタ目(3:04~)の3:46で登場
• 結論: 漫才においてシフトレフトはメリットが無いのなの
© NISHI, Yasuharu
p.3
シフトレフトとは?
• 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
シフトレフトとは?
• 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
モダンなシフトレフト
• 考え方は分かるのなの…
– とにかくいつでもテストするんですよねブロッコリーさん…
© NISHI, Yasuharu
p.6
モダンなシフトレフト
• 分かる…分かります…分かった気がするのなの…
– 開発ライフサイクルの話ですよねブロッコリーさん…
© NISHI, Yasuharu
p.7
モダンなシフトレフト
• 他人の翻訳じゃなくて、
あなたの話が聴きたいのブロッコリーさん!
• ブロッコリーさんの素晴らしい話:
– 色々やった
• テスト設計:テスト実施の比率を1:9から5:5にした
• QAチーム内のレビューを手厚くした
• など
– QAメンバーの声が変わった
• 「最近では『仕様です』と言われても、
自分で考えて『これが仕様で良いのか』と、
開発チームと議論できるようになった」
– QAメンバーがレビュアーとして開発に関わるようになった
• 大きなフィーチャーに取りかかる前に事前に議論し、
テスト観点出しやテストパターン作成をきっかけに
仕様漏れを検知した
© NISHI, Yasuharu
p.8
モダンなシフトレフト
• Googleの “Testing on the Toilet”
– 事実、2005年まで、テストは規律として課されたプラクティスというより、
物珍しいものに近かった
• (テストの)大半は手動で行われた
• 2006年にテスト革命が起こったの!
– オリエンテーション講習、テスト認定プログラム、TotT
• Testing on the Toilet (TotT)
– 2006年4月、Google社内全体のトイレの個室に、
Pythonでのテストを改善する方法を扱う短い記事が現れた
– これだってシフトレフトじゃないなの?
© NISHI, Yasuharu
p.9
シフトレフトって?
• 要するに、
– 開発の初期からちゃんと後工程(テストなど)について
– 考えたり
• QAやテストエンジニアと開発者が一緒に考えたり
• 開発者自身が考えるようになったり
– 実際に作業したりして
• QAが要求や設計のレビューに加わったり
• テスト設計をより上流で行って(コード無しで)要求や設計のバグを見つけたり
• 上流のモデルベース/モデル駆動化を進めて(コード無しで)要求や設計のバグを見つけたり
• トレーニングしたりTotTしたり
– 後回しにする嫌なことを
• 工数やコストが大幅に増えたり
• 技術的負債ができたり
• エンジニアが後悔してモチベーションが下がったり
– 防ぐことなの!
• 工程や手順だけを前倒しする計画を作って実施するというマインドでは失敗する
– いわんやツールやほげほげコーチをや
© NISHI, Yasuharu
p.10
じゃあ、開発者はシフトレフトで何を新たに考えればいいのなの?
• 品質意識の低い組織
– 上流から品質を上げるといいよ、というモダンな「常識」
• TDDや技術的負債など、今は知らない方がヤバいの!
• 品質意識も品質もそこそこの組織
– テスト設計の考え方?
• 網羅しろとか
• 仕様に矛盾があるとか
• 画面や操作に一貫性がないとか
• ユースケース考えろとか
• UX考えろとか
– 「オレたちは確かにできてないかもしれないけど、
QAに偉そうに言われることでもない」
• シフトレフトは、本質的に
開発者サイロとQAサイロを崩し
Whole Team Approach
(a.k.a.全員参加)を実現し、
全員で品質意識を高めて
品質文化を構築することなの!
• 品質意識も品質も高い組織
– もうできてるでしょなの
© NISHI, Yasuharu
p.11
なんかこう、
QAの技術が高いから
開発が経緯を払う、という話ではないの
この図には、何かが足りないなの…
© NISHI, Yasuharu
p.12
この図には、バグがいないの!
© NISHI, Yasuharu
p.13
そうだ!バグをシフトレフトしようなの!
© NISHI, Yasuharu
p.14
そのためにバグの分析が必要になるの
• バグ分析、と言っている人が目的だと思っていることランキング(にしの心の中調べ2022)
1位: よく分からないけどやることになっているからやる
• ムダの極み
2位: バグの存在する場所を明らかにしてデバッグのための情報を得る
• 必要な作業だが、今日話したいのはこのことではない
3位: 経営や管理職、QA部門などが犯人捜しや「仕事してますエビデンス作成」のために行う
• 百害あって一利なし
4位: バグの傾向を掴み手を打つ
• 役に立ちそうに見えるが…
© NISHI, Yasuharu
p.15
バグ分析(RCA)には大きく分けて2つあるの
• マクロ分析(バグの傾向分析)
– 目的
• 組織全体としてどのチームにどんなバグが多いか、を把握する
• プロダクトのどの部分にどんなバグが多いか、を把握する
• 工程のどこでどんなバグが入りやすいか、を把握する
– 代表的な技術
• フォールトプローン技術
• ODC(直交欠陥分析)
– 問題点
• 施策が大味になりがちで、バグと施策が結びつかず、効果がでにくい傾向がある
– 基本的にシフトレフトには向いてない
• バグの中身や開発の中身をきちんと見る習慣が失われる傾向がある
– 「QAは時間がない」は言い訳である
• 傾向という名の数値が一人歩きする傾向がある
– 管理図の統計的意味も分からずに折れ線グラフを描いて「〇〇管理図」とか言い出したりする
• よほど注意して実施しないと、形骸化と官僚化の温床になる
– マクロ分析からの間接施策(プロセスを決めろ/変えろ、この目標メトリクスを達成しろ)は最悪である
• ミクロ分析(バグのパターン化)
© NISHI, Yasuharu
p.16
バグ分析には大きく分けて2つあるの
• マクロ分析(バグの傾向分析)
• ミクロ分析(バグのパターン化)
– 目的
• バグ、もしくはバグの原因をパターン化して水平展開し、再発防止・未然防止を行う
• 根本原因分析(RCA: Root Cause Analysis)やなぜなぜ分析として行われる
– 代表的な技術
• キーワード分析
• 機能分析
• 現象分析
• 開発者属性分析
• プロセス分析
• 構造分析
• (欧米型)FMEAと呼ばれる一群の何か
• ソフトウェアトラップ分析(不具合モード分析)
– 問題点
• そもそも水平展開や再発防止・未然防止という用語の理解が曖昧である
• 技術(パターンの抽出方法)によっては出来の悪いマクロ分析になる
• よほど注意して実施しないと、吊し上げになり形骸化の温床になる
© NISHI, Yasuharu
p.17
バグのパターン化の(現場で使われている)技法
• キーワード分析
– 容易だが精度は低い
• 例) 「日次平均値算出機能」に対し、
類似のキーワードを含む仕様や機能にバグが多いと推測する技法
• 機能分析
– 容易だが精度は低い
• 例) 「日次平均値算出機能」に対し、機能ツリーのうち近い機能にバグが多いと推測する技法
• 現象分析
– 容易だが精度は低い
• 例) 「日次平均値算出機能」がダウンしたとすると、ダウンしたバグを集めてパターン化する技法
• 通常は意味あるパターンは抽出できない
© NISHI, Yasuharu
p.18
バグのパターン化の(現場で使われている)技法
• 開発者属性分析
– 容易だが精度は低いし、やってはいけない
• 開発者の体調や心理状態、経歴や出身に着目する技法
• 個人攻撃になったり人事評価につながるので、
中長期的に悪さの情報が隠蔽されるので
品質は下がっていき官僚化していく
• プロセス分析
– 容易だが精度は低い
• 「~を読んでない」「~を知らない」「~に従わない」「~を確認しない」
「誤った~を読んだ」「~を誤って解釈した」のように分析する技法
• 構造分析
– そこそこ難しいが精度はそこそこ高い
• 例) 「日次平均値算出機能」がスタックを用いているとすると、
スタックや類似した構造を用いている設計部位にバグが多いと推測する技法
• 例) 「日次平均値算出機能」がスタックオーバーフローを起こしたとすると、
スタックなどオーバーフローを起こしうる構造を用いている設計部位にバグが多いと推測する技法
© NISHI, Yasuharu
p.19
バグのパターン化の(現場で使われている)技法
• ソフトウェアFMEAと呼ばれる一群の何か
– 故障モードを機能や現象の抽象概念だと捉えると、精度が低くなってしまう
• 欧米型は、ソフトウェアの各モジュールからの機能不動作(演算間違いや遅延など)を
故障モードと捉えるため、内部的な現象分析になってしまう
– 公表されている事例Aは、内部処理 x 能力 x 現象の3つ組に着目するため、
内部的な機能分析や現象分析になってしまう
– 公表されている事例Bは、データ間の構造の考慮不足などに着目している
– 公表されている事例Cは、瞬断時の異常や他動作中の移動など、発生条件に着目している
– 残念ながら、多くの書籍や論文、発表資料はあまり有益でないことが多い
• そもそも故障モードはハードウェアのQCや信頼性工学でも議論が分かれる概念である
– 電子素材のように固有技術的に確立しているらしい分野もあるようだ
• 精度よく使っているハードウェア組織では、
故障モードは設計ノウハウそのもののため、外部に公表する資料には掲載されない
– だからDRBFMをソフトウェア屋が読むと変化点解析になってしまう
– 著者はバグのパターン化ができないのかもしれないし、
できるけど有益なパターンを外部に公表できないかもしれないし…
© NISHI, Yasuharu
p.20
ソフトウェアトラップ分析(不具合モード分析)
• ソフトウェアトラップ(不具合モード)を含む仕様書や母体設計書から
作られる構造や機能にはバグが多いと推測する技法
– 開発者がどこをどう間違えるか、に着目する技法
– ソフトウェアの入力成果物(仕様書や母体設計書)に
開発者がバグを作り込んでしまう「トラップ(罠)」が含まれているため、
開発者はそのトラップに引っかかってしまい吸い込まれるように
出力成果物(設計書やソースコード)にバグを作り込んでしまう、という考え方である
• 例)「優先順位の表現で1(高い)~5(低い)と5(高い)~1(低い)が混在すると混同しやすい」
• 河野哲也氏(現メルカリ)らが不具合モード分析として確立し、嬉野綾氏(ワークスアプリケーションズ)らが
バグシェルジェ(ASTER)という研究グループで議論を進めている
– 類似品に注意: 水平展開やフロントローディングを行えない類似品もある
© NISHI, Yasuharu
p.21
ソフトウェアトラップ分析(不具合モード分析)
• ソフトウェアトラップ(不具合モード)を含む仕様書や母体設計書から
作られる構造や機能にはバグが多いと推測する技法
– トラップにはパターンがあるので、そのパターンをシフトレフトする
• テストにシフトレフト: ピンポイントテストのテスト観点にする
• レビューにシフトレフト: レビューのチェックリストに加える
• 開発にシフトレフト: 開発者に気をつけてもらったり、開発ガイドラインに記載する
– 水平展開しシフトレフトするために分析するので、
水平展開できそうもない/する必要のないバグは分析しない
• 本当にうっかりしたために作ってしまったバグは分析しない
– 本当にうっかりであれば、トラップに依存せずランダムに発生しているはず
– 本当にうっかりではないのに開発者が「うっかり」と答えるのであれば、
その組織はバグ分析を始める前にすべきことがある
– トラップが全くイメージできないものは無理に抽出しない方がよい
• 分析にはスキルや経験が必要である
• 分析にはかなりの時間がかかるので腰を据えて行う必要がある
– 分析に協力してくれる開発者がいる方が分析もシフトレフトも進む
© NISHI, Yasuharu
p.22
ソフトウェアトラップ分析(不具合モード分析)
• ソフトウェアトラップ(不具合モード)を含む仕様書や母体設計書から
作られる構造や機能にはバグが多いと推測する技法
– ソフトウェアの入力成果物(仕様書や母体設計書)に
開発者がバグを作り込んでしまう「トラップ(罠)」が含まれているため、
開発者はそのトラップに引っかかってしまい吸い込まれるように
出力成果物(設計書やソースコード)にバグを作り込んでしまう、という考え方である
• 入力成果物は開発者の思考プロセスへの入力なので、
プログラミング言語仕様や直前に作成した成果物のこともある
– 例) C言語で発生するif文での代入というバグは、
混同しやすい=(代入)と==(比較)を同じ場所で使えるようにした言語仕様がトラップになっている
» そのためMISRA-Cなどでは規格で禁止することで「フロントローディング」を行っている
• トラップによって引き起こされる「人間の思考の誤り」を意識する
– 一般的なヒューマンエラーは、実のところ「人間の思考の誤り」は取り扱っていない
• 人間系の要因は「ブースター」として分離して取り扱う
– 「前の晩に夜更かしして注意不足だった」はトラップではなくブースターである
– ブースターを根本原因として取り扱うと、
対策が大味になりがちで、バグと施策が結びつかず、効果がでにくい傾向がある
© NISHI, Yasuharu
p.23
トラップの例
• 実際に各社で抽出されたトラップの例(特定できないように一部改変しているところがあります)
– 二卵性双生児
• 順序が逆のものが混在すると、混同しやすい
– 優先順位の表現で1(高い)~5(低い)と5(高い)~1(低い)が混在すると混同しやすい
– リトルエンディアンとビッグエンディアンが混在すると混同しやすい
– True/false値(1/0)がハード側とソフト側で異なる
• 対称であるべきものが一部非対称であると、混同しやすい
– アームの行きの動きのルーチンと帰りの動きのルーチンが一部異なっている
– ifdefでコンパイルし分けるコードのCPU使用率が異なるので処理が間に合わない
– 例外
• 後から追加された例外的な仕様は、設計漏れを引き起こしやすい
• 複数ある対となっている条件の両方に必要な正常処理は設計できたが、
特定の対の片方の条件だけ例外的に必要となる準正常処理が抜けてしまった
– 浦島太郎
• 割り込み先から帰ってきたら、割り込み元の状態が変わっていた
– 「備考」
• 備考欄に書かれるものは、書かれないと問題が起こるほど重要なのに、
本文に入れられるほど構造化されていないものである
© NISHI, Yasuharu
p.24
バグ分析会議の運営
• ダメなバグ分析会議
– 犯人捜し/責任追及・上司による責任回避
– 吊し上げ/晒し者
– 根拠のない思い込みと決めつけ、説教と自慢話
– その後の悪い人事評価
– 防御的心理
• よいバグ分析会議
– 「納得感」の「共感」を軸にしてバグの分析を行う
• 自分でも引っかかってしまうと納得できるトラップを探す
• 適切なパターン化ができた瞬間は、分析会議の参加者が
「あーそのトラップにはみんな引っかかるよねー」と納得し、皆が共感するようになる
– 開発者への敬意を前面に出す
• 悪いのはトラップであって開発者ではない、という姿勢を崩さない
– 「スキルの高いあなたで “すら” このトラップに引っかかるんですから、若い連中なんてなおのこと…」
– だからトラップ分析ではトラップとブースターを明確に区別している
• バグを作り込んだ人という扱いではなく、
トラップの情報を提供してくれる人として尊敬を前面に出すと、
前向きの会議になって共感しやすくなる
– 効率を求めてはいけない
• 分析に時間がかかるのはスキルが低いからだが、
時間をかけてよい分析をしない限りスキルは向上しない
• 途中でみんな現場に戻りたくなって分析の質が落ちるところをグッと我慢してもらう
© NISHI, Yasuharu
p.25
バグ分析によるシフトレフトの注意点
• 開発者が「腕が上がった」と思える施策を立案する
– 開発者の「こんなことやっても意味ないよな」という実感を大事にして、
そうならないような施策を立案する
– 「腕が上がった」と思ってくれれば、どんどん協力してくれるようになる
• そのバグだけを未然防止できる具体的で小さな施策を立案し、
少しずつ注意しながら施策を大きくする
– 全社一律や部門全体に効きそうな施策は、結局のところ大味で誰の役にも立たない
– 大味な施策ほど名前を付けやすいので、「仕事をした感」を出しやすい
– 一発屋ではなくグルグル回るサイクルが重要
• 「あーもっと早く気づけたのに」という後悔ドリブンにする
– 誰も後悔していないバグはフロントローディングできない
– 後悔しているバグはトラップも見つけやすい
• フロントローディングした作業のための工数をきちんと確保する
– どんなバグが出そうか、を皆で考える会議を開発の最初にやる場合、
きちんとプロセス名をつけて見積もりに載せて工数を確保しないと、
「いつまでお喋りしてるんだよ、とっとと作れよ」という圧力をはねのけられない
• パターン集を買おうとしない
– バグ分析/RCAを上手にやれるようになるのは確かにしんどいが、しんどい原因は
自組織に抽象化能力やパターン化、水平展開の能力が育っていないからである
© NISHI, Yasuharu
p.26
まとめ、なの
• ブロッコリーさんを応援しよう、なの
• シフトレフトには色々あるが、本質的に
開発者サイロとQAサイロを崩し
Whole Team Approach(a.k.a.全員参加)を実現し、
全員で品質意識を高めて品質文化を構築するなの
• バグをパターン化してシフトレフトするといいのなの
– でも注意しないと組織が硬直化して逆効果なの
© NISHI, Yasuharu
p.27

More Related Content

What's hot

車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから
Yasuharu Nishi
 
Software-company Transformation
Software-company TransformationSoftware-company Transformation
Software-company Transformation
Yasuharu Nishi
 
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 PresentationLINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
Yasuharu Nishi
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern context
Yasuharu Nishi
 
テスト観点に基づくテスト開発方法論 VSTePの概要
テスト観点に基づくテスト開発方法論VSTePの概要テスト観点に基づくテスト開発方法論VSTePの概要
テスト観点に基づくテスト開発方法論 VSTePの概要
Yasuharu Nishi
 
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へパターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
Hironori Washizaki
 
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
Hironori Washizaki
 
あじゃいる時代の品質保証 ~DevSQAの提案~
あじゃいる時代の品質保証 ~DevSQAの提案~あじゃいる時代の品質保証 ~DevSQAの提案~
あじゃいる時代の品質保証 ~DevSQAの提案~
Hiroaki Matsunaga
 
Paradigm shifts in QA for AI products
Paradigm shifts in QA for AI productsParadigm shifts in QA for AI products
Paradigm shifts in QA for AI products
Yasuharu Nishi
 
私にとってのテスト
私にとってのテスト私にとってのテスト
私にとってのテスト
Takuto Wada
 
アジャイル品質パターン (Agile Quality, QA2AQ)
アジャイル品質パターン (Agile Quality, QA2AQ)アジャイル品質パターン (Agile Quality, QA2AQ)
アジャイル品質パターン (Agile Quality, QA2AQ)
Hironori Washizaki
 
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
KazukiNishizono1
 
DeNA QA night #2 presentation
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentation
Yasuharu Nishi
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
Kinji Akemine
 
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
Hironori Washizaki
 
modern software qa - draft 1
modern software qa - draft 1modern software qa - draft 1
modern software qa - draft 1
Yasuharu Nishi
 
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門
H Iseri
 
QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜
QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜
QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜
masamimorita
 
ちょっと明日のテストの話をしよう
ちょっと明日のテストの話をしようちょっと明日のテストの話をしよう
ちょっと明日のテストの話をしよう
Yasuharu Nishi
 
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
 

What's hot (20)

車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから
 
Software-company Transformation
Software-company TransformationSoftware-company Transformation
Software-company Transformation
 
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 PresentationLINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern context
 
テスト観点に基づくテスト開発方法論 VSTePの概要
テスト観点に基づくテスト開発方法論VSTePの概要テスト観点に基づくテスト開発方法論VSTePの概要
テスト観点に基づくテスト開発方法論 VSTePの概要
 
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へパターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
 
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
SQuBOKガイドV3概説 ~IoT・AI・DX時代のソフトウェア品質とシステム監査~
 
あじゃいる時代の品質保証 ~DevSQAの提案~
あじゃいる時代の品質保証 ~DevSQAの提案~あじゃいる時代の品質保証 ~DevSQAの提案~
あじゃいる時代の品質保証 ~DevSQAの提案~
 
Paradigm shifts in QA for AI products
Paradigm shifts in QA for AI productsParadigm shifts in QA for AI products
Paradigm shifts in QA for AI products
 
私にとってのテスト
私にとってのテスト私にとってのテスト
私にとってのテスト
 
アジャイル品質パターン (Agile Quality, QA2AQ)
アジャイル品質パターン (Agile Quality, QA2AQ)アジャイル品質パターン (Agile Quality, QA2AQ)
アジャイル品質パターン (Agile Quality, QA2AQ)
 
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
 
DeNA QA night #2 presentation
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentation
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
 
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
アジャイル品質パターンによる伝統的な品質保証(Quality Assurance)からアジャイル品質(Agile Quality)への変革
 
modern software qa - draft 1
modern software qa - draft 1modern software qa - draft 1
modern software qa - draft 1
 
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門
 
QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜
QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜
QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜
 
ちょっと明日のテストの話をしよう
ちょっと明日のテストの話をしようちょっと明日のテストの話をしよう
ちょっと明日のテストの話をしよう
 
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
 

Similar to What should you shift left

リーン原則とソフトウェア開発
リーン原則とソフトウェア開発リーン原則とソフトウェア開発
リーン原則とソフトウェア開発
You&I
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
 
ありえるえりあ勉強会@五反田~テスト編~ Part2
ありえるえりあ勉強会@五反田~テスト編~ Part2ありえるえりあ勉強会@五反田~テスト編~ Part2
ありえるえりあ勉強会@五反田~テスト編~ Part2
Tomoyuki Sato
 
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese TranslationEric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Kenji Hiranabe
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
 
AgileShimane始動!! in OSC2011Shimane
AgileShimane始動!! in OSC2011ShimaneAgileShimane始動!! in OSC2011Shimane
AgileShimane始動!! in OSC2011Shimane
Ryuichi Tsuruhara
 
Eric riesstartuplessonslearned2011 ja20110605
Eric riesstartuplessonslearned2011 ja20110605Eric riesstartuplessonslearned2011 ja20110605
Eric riesstartuplessonslearned2011 ja20110605
Yuki Sekiguchi
 
GCSアジャイル開発を使ったゲームの作り方
 GCSアジャイル開発を使ったゲームの作り方 GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
Hiroyuki Tanaka
 
業務システム開発モダナイゼーションガイド
業務システム開発モダナイゼーションガイド業務システム開発モダナイゼーションガイド
業務システム開発モダナイゼーションガイド
You&I
 
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
Koichi ITO
 
tokyo_webmining_no51
tokyo_webmining_no51tokyo_webmining_no51
tokyo_webmining_no51
Shu (shoe116)
 
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてAgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
Shuji Morisaki
 
アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱
Koichi ITO
 
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapanモダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
満徳 関
 
Xp Terakoya No02
Xp Terakoya No02Xp Terakoya No02
Xp Terakoya No02
takepu
 
デブサミ2013【15-C-8】セキュリティ要求仕様モデルプランで日本は変わるか?(百瀬昌幸氏)
デブサミ2013【15-C-8】セキュリティ要求仕様モデルプランで日本は変わるか?(百瀬昌幸氏)デブサミ2013【15-C-8】セキュリティ要求仕様モデルプランで日本は変わるか?(百瀬昌幸氏)
デブサミ2013【15-C-8】セキュリティ要求仕様モデルプランで日本は変わるか?(百瀬昌幸氏)
Developers Summit
 
CISOが、適切にセキュリティ機能とレベルを決めるには
CISOが、適切にセキュリティ機能とレベルを決めるにはCISOが、適切にセキュリティ機能とレベルを決めるには
CISOが、適切にセキュリティ機能とレベルを決めるには
Riotaro OKADA
 

Similar to What should you shift left (20)

リーン原則とソフトウェア開発
リーン原則とソフトウェア開発リーン原則とソフトウェア開発
リーン原則とソフトウェア開発
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
 
ありえるえりあ勉強会@五反田~テスト編~ Part2
ありえるえりあ勉強会@五反田~テスト編~ Part2ありえるえりあ勉強会@五反田~テスト編~ Part2
ありえるえりあ勉強会@五反田~テスト編~ Part2
 
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese TranslationEric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
 
地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め地図を捨ててコンパスを頼りに進め
地図を捨ててコンパスを頼りに進め
 
AgileShimane始動!! in OSC2011Shimane
AgileShimane始動!! in OSC2011ShimaneAgileShimane始動!! in OSC2011Shimane
AgileShimane始動!! in OSC2011Shimane
 
Eric riesstartuplessonslearned2011 ja20110605
Eric riesstartuplessonslearned2011 ja20110605Eric riesstartuplessonslearned2011 ja20110605
Eric riesstartuplessonslearned2011 ja20110605
 
GCSアジャイル開発を使ったゲームの作り方
 GCSアジャイル開発を使ったゲームの作り方 GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
 
20130320 agile pm
20130320 agile pm20130320 agile pm
20130320 agile pm
 
業務システム開発モダナイゼーションガイド
業務システム開発モダナイゼーションガイド業務システム開発モダナイゼーションガイド
業務システム開発モダナイゼーションガイド
 
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
 
tokyo_webmining_no51
tokyo_webmining_no51tokyo_webmining_no51
tokyo_webmining_no51
 
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけてAgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
 
アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱
 
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapanモダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
モダンアジャイル - Agile Japan 2017 地方サテライト版 #agilejapan
 
Xp Terakoya No02
Xp Terakoya No02Xp Terakoya No02
Xp Terakoya No02
 
デブサミ2013【15-C-8】セキュリティ要求仕様モデルプランで日本は変わるか?(百瀬昌幸氏)
デブサミ2013【15-C-8】セキュリティ要求仕様モデルプランで日本は変わるか?(百瀬昌幸氏)デブサミ2013【15-C-8】セキュリティ要求仕様モデルプランで日本は変わるか?(百瀬昌幸氏)
デブサミ2013【15-C-8】セキュリティ要求仕様モデルプランで日本は変わるか?(百瀬昌幸氏)
 
CISOが、適切にセキュリティ機能とレベルを決めるには
CISOが、適切にセキュリティ機能とレベルを決めるにはCISOが、適切にセキュリティ機能とレベルを決めるには
CISOが、適切にセキュリティ機能とレベルを決めるには
 

More from Yasuharu Nishi

What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?
Yasuharu Nishi
 
CommentScreeen is good
CommentScreeen is goodCommentScreeen is good
CommentScreeen is good
Yasuharu Nishi
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern context
Yasuharu Nishi
 
Teaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decadeTeaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decade
Yasuharu Nishi
 
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Yasuharu Nishi
 
Tomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systemsTomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systems
Yasuharu Nishi
 
QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019
Yasuharu Nishi
 
LINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 TrailerLINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 Trailer
Yasuharu Nishi
 
ソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホント
Yasuharu Nishi
 
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D...
Viewpoint-based Test Requirement Analysis Modelingand Test Architectural D...Viewpoint-based Test Requirement Analysis Modelingand Test Architectural D...
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D...
Yasuharu Nishi
 
IoT時代と第3者検証
IoT時代と第3者検証IoT時代と第3者検証
IoT時代と第3者検証
Yasuharu Nishi
 
日本のテスト産業の国際競争力 ~日本をソフトウェアテスト立国にしよう~
日本のテスト産業の国際競争力~日本をソフトウェアテスト立国にしよう~日本のテスト産業の国際競争力~日本をソフトウェアテスト立国にしよう~
日本のテスト産業の国際競争力 ~日本をソフトウェアテスト立国にしよう~
Yasuharu Nishi
 
同値分割ってなんだろう?
同値分割ってなんだろう?同値分割ってなんだろう?
同値分割ってなんだろう?
Yasuharu Nishi
 

More from Yasuharu Nishi (13)

What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?
 
CommentScreeen is good
CommentScreeen is goodCommentScreeen is good
CommentScreeen is good
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern context
 
Teaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decadeTeaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decade
 
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
 
Tomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systemsTomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systems
 
QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019
 
LINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 TrailerLINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 Trailer
 
ソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホント
 
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D...
Viewpoint-based Test Requirement Analysis Modelingand Test Architectural D...Viewpoint-based Test Requirement Analysis Modelingand Test Architectural D...
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D...
 
IoT時代と第3者検証
IoT時代と第3者検証IoT時代と第3者検証
IoT時代と第3者検証
 
日本のテスト産業の国際競争力 ~日本をソフトウェアテスト立国にしよう~
日本のテスト産業の国際競争力~日本をソフトウェアテスト立国にしよう~日本のテスト産業の国際競争力~日本をソフトウェアテスト立国にしよう~
日本のテスト産業の国際競争力 ~日本をソフトウェアテスト立国にしよう~
 
同値分割ってなんだろう?
同値分割ってなんだろう?同値分割ってなんだろう?
同値分割ってなんだろう?
 

What should you shift left