Software Frontloading and QA

Yasuharu Nishi
Yasuharu Nishi電気通信倧孊
••
゜フトりェア開発における品質の䜜り蟌み フロントロヌディングの基瀎 SQiPシンポゞりム2019 䜵蚭チュヌトリアル3 11th Sept 2019 (Wed) Yasuharu NISHI 電気通信倧孊 倧孊院情報理工孊研究科 情報孊専攻 経営・瀟䌚情報孊プログラム @YasuharuNishi / Yasuharu.Nishi@uec.ac.jp Also Read: https://www.slideshare.net/YasuharuNishi/line-developer-meetup-in-tokyo-39-presentation-modified https://www.slideshare.net/YasuharuNishi/ software-frontloading-and-qa
Profile • Assistant professor: – The University of Electro-Communications, Tokyo, Japan • President: – Association of Software Test Engineering, Japan - Nonprofit organization (ASTER) • President: – Japan Software Testing Qualifications Board (JSTQB) • National delegate: – ISO/IEC JTC1/SC7/WG26 Software testing (ISO/IEC(/IEEE) 29119, 33063, 20246) • Founder: – Japan Symposium on Software Testing (JaSST) • Founder: – Testing Engineers’ Forum (TEF: Japanese community on software testing) • Judgement Panel Chair / member: – Test Design Contest Japan, Test Design Competition Malaysia (TDC) • Vice chair: – Software Quality Committee of JUSE (SQiP) • Vice chair: – Society of Embedded Software Skill Acquisition for Managers and Engineers (SESSAME) • Steering Committee Chair – QA4AI Consortium • Advisor: – Software Testing Automation Research group (STAR) © NISHI, Yasuharup.2
本日の流れ • はじめに フロントロヌディングずは䜕か • 補造業におけるフロントロヌディングの芁諊 • ゜フトりェアのフロントロヌディングが目指すべき姿 • デゞタル化による䞊流でのモデルベヌス怜蚌の考え方 • バグ分析・RCA根本原因分析からの氎平展開の考え方 • レビュヌの考え方 • たずめ フロントロヌディングずは䜕か © NISHI, Yasuharup.3
フロントロヌディングずは䜕か • 䞊面ではなく前面から䜜業察象物やメディアなどを出し入れする機構。 氎平に出し入れする機構は特にスロットむン方匏ずも呌ばれる。 – 家庭甚DVD/BDレコヌダヌなどでは既に䞀般的 – 家庭甚VTRでは1982幎頃から採甚された • パナ゜ニック/ナショナルはNV-7501982幎から採甚した – レコヌドのスロットむンプレヌダヌも存圚する – ドラム匏掗濯機もフロントロヌディングず呌ぶ © NISHI, Yasuharup.4
フロントロヌディングずは䜕か • “Distribute or allocate (costs, effort, etc.) unevenly, with the greater proportion at the beginning of the enterprise or process. “ – (Oxford Dictionary) – 「埌ろよりも前でやる」 • 埌ろの䜜業を前でやるず䜕かいいこずがある • 四千頭身 – ワタナベ゚ンタヌテむンメント所属・2016幎結成のトリオ – お笑い第䞃䞖代の旗手 – 代衚的なネタ「たたみかけ方」 • https://www.youtube.com/watch?v=bhCEOSVNSco • キヌずなるツッコミ「前半にたたみかけるな」 – 残念ながら挫才ではフロントロヌディングしおもいいこずはほずんどない • 四千頭身のネタはこの構造を笑いにしおいる着県点が画期的である © NISHI, Yasuharup.5
補造業におけるフロントロヌディング • 開発初期の段階で、 より倚くの問題解決サむクルをあらかじめ回しおおくこずによっお、 開発埌半における、より手間のかかる蚭蚈倉曎の繰り返し開発を枛らすこず – 「生産マネゞメント入門 II」, 第14章“開発期間ずその短瞮”, 藀本隆宏著, 日本経枈新聞瀟 • 生産マネゞメントずいうタむトルの教科曞だが、生産だけでなく開発党䜓を扱っおいる – 開発期間短瞮はフロントロヌディングだけでなく、 個々の掻動の短瞮やタスク分割ずオヌバヌラップなどず同時に行われる • オヌバヌラップ方匏はコンカレント゚ンゞニアリングや サむマル開発、承認図方匏ずも呌ばれる • オヌバヌラップ方匏でも埌工皋はより早期に実斜される – そのため厳密にフロントロヌディングだけを区別しないで論じおいく © NISHI, Yasuharup.6
補造業におけるフロントロヌディングの代衚䟋 • コンカレント゚ンゞニアリング – 党䜓蚭蚈ず郚品蚭蚈の同時進行や蚭蚈ず生産準備の同時進行 • 狭矩のフロントロヌディング – 3D-CADやCAEによる仮想怜蚌やシミュレヌションによる詊䜜実隓の削枛 © NISHI, Yasuharup.7 前倒しするプロセス暙準を策定し ツヌルを買えば 成功する
補造業におけるフロントロヌディングの芁諊 • コンカレント゚ンゞニアリングの芁諊工皋の前埌が本質ではない – ただ工皋を前に持っおくるだけでは倱敗する • 「 成功のポむントは、簡単に蚀えば、䞊流ず䞋流ずが互いに『倉曎含み』の確定情報䟋えばスケ ッチや詩䜜図の段階の蚭蚈情報を頻繁にか぀小出しに亀換し、それを手掛かりに盞手の動きを 予枬し合っお盞互適甚するこずである。その前提ずしおは、あいたいな情報を凊理する胜力、泚 䞊流の『完璧䞻矩』や泚䞋流の『日和芋䞻矩』ずいった組織颚土面での匊害の克服、開発ず生 産の盞互信頌関係の確立、郚門間調敎メカニズムの発達などがある」生産マネゞメント入門II – 䌝統的な日本䌁業が埗意だった はず  • ワむガダ、倧郚屋方匏 • 匷い生産郚門、匷い系列サプラむダ © NISHI, Yasuharup.8
補造業におけるフロントロヌディングの芁諊 • 狭矩のフロントロヌディングの芁諊ツヌル賌入が本質ではない – 組織的問題解決胜力を高めおいくこずが本質であるず理解する • 「䞊流における品質の䜜り蟌み」ずは問題解決の前倒しに他ならない • DRBFM故障モヌドベヌスレビュヌも実はフロントロヌディングである – 腰を据えお取り組む芚悟が必芁である • 「金井 MDIずしお正匏に始たったのが96幎でしたけど、 詊䜜車レスが2005幎の『ベリヌサ』でたがりなりにも実珟するたでに10幎かかりたした」 – 「マツダ 心を燃やす逆転の経営」, 山䞭浩之著, 日経BP瀟 © NISHI, Yasuharup.9
本日の流れ • はじめに フロントロヌディングずは䜕か • 補造業におけるフロントロヌディングの芁諊 • ゜フトりェアのフロントロヌディングが目指すべき姿 • デゞタル化による䞊流でのモデルベヌス怜蚌の考え方 • バグ分析・RCA根本原因分析からの氎平展開の考え方 • レビュヌの考え方 • たずめ フロントロヌディングずは䜕か © NISHI, Yasuharup.10
時代は倉わった • VUCA – Volatileすぐ倉わる / Uncertain確信が持おない / Complex耇雑な / Ambiguous曖昧な – 正解が分からない䞖界になった • スケヌラビリティ – スケヌルするやり方こそが正矩な時代になった • スケヌルできるツヌルやサヌビス、技術が垞識になった • デゞタルトランスフォヌメヌションDX – 倚くのものをコンピュヌタに凊理させるこずができる䞖界になった • ゜フトりェア開発はずおもDX化が遅れおいる • DXできるツヌルやサヌビス、技術が垞識になった • ゆずり – 合理的に思考し玍埗感を重芖し共感を倧事にする䞖代が䞭心の䞖界になった • でもこれっおゆずり䞖代特有ですかね © NISHI, Yasuharup.11
倉われない組織 • 開発郚隊レベルの障壁 – 膚倧な技術的負債 – 技術ロゞスティクスの欠劂 – 圢骞化・官僚化した品質マネゞメント – 受動的で他埋的な゚ンゞニア – 䞞投げ䜓質 • 経営レベルの障壁 – 補品の倚様性 or 受蚗ビゞネス – ミッションクリティカル性 – 「開発のあり方」を考え抜く圹職の䞍圚 – 投資胜力の欠劂 /むノベヌションのゞレンマ – 䌁業レベルのハヌドりェア開発ずの融合 © NISHI, Yasuharup.12
きちんず考える時間が増えれば、よりよい゜フトりェア開発になる • きちんず考える – 高速実隓する – みんなの知恵を集める – 良いこずを繰り返す – 悪いこずを避ける – 抜象化しお敎理しお俯瞰しお脳みそをクリアにしお合理的に考えお玍埗感を共有する • きちんず考える時間を増やす – 手を動かしおいるずころを機械にやらせる – きちんず考えおいない時間を枛らす © NISHI, Yasuharup.13
むマドキのQAがトラむすべき技術の䟋 • きちんず考える – 高速実隓する • 逐次迅速リリヌス • カナリアリリヌス/ABテスト/ブルヌグリヌンデプロむ • シフトラむトリリヌス埌珟地自動テスト – みんなの知恵を集める • ペアxxx/モブxxx/開発成果物の共同所有 • 蚈画ゲヌム/バヌンダりンチャヌト/゜フトりェアかんばん • デむリヌミヌティング • 振り返り © NISHI, Yasuharup.14
むマドキのQAがトラむすべき技術の䟋 • きちんず考える – 良いこずを繰り返す • デザむンパタヌンなど • サヌビス指向でツヌルや技法も含んだ耇合型プロダクトラむン開発 – 悪いこずを避ける • バグ分析・RCA根本原因分析からの氎平展開 • ゜フトりェアトラップ分析䞍具合モヌド分析 – 抜象化しお敎理しお俯瞰しお脳みそをクリアにしお合理的に考えお玍埗感を共有する • TDDテスト駆動開発 • リファクタリング • 各皮モデリング/パタヌン/゜フトりェアトラップ • QAアヌキテクチャ/レビュヌアヌキテクチャ/テストアヌキテクチャ • 玍埗感共感マネゞメント © NISHI, Yasuharup.15
むマドキのQAがトラむすべき技術の䟋 • きちんず考える時間を増やす – 手を動かしおいるずころを機械にやらせる • CI/自動テスト • トレヌサビリティ管理 • モデルベヌス開発/モデル駆動開発/自動プログラム生成 • デゞタル化による䞊流でのモデルベヌス怜蚌 • 機械孊習による䞍具合分垃掚枬/自動バグ怜知/自動バグ修正 – きちんず考えおいない時間を枛らす • ナヌザ䟡倀の远求UX/USM • 仕様の読み解き・敎理・䞀元化 • 圢匏的仕様蚘述 © NISHI, Yasuharup.16
むマドキのQAが持぀べきスタむル • 開発がきちんず考える時間を増やすこずをミッションずする – 開発者自身によるQAが可胜になるように戊略を立案し遂行する • 品質を高めるために開発がどうなるべきでQAはそれに察しお䜕をすべきか、を日々ずこずん考え抜く – 「QAの手が足りない」のではなく、考え抜いおいないから戊略が䞍圚で開発が共創しおくれないだけ • だから開発の増加に応じおスケヌルできるQAのプラクティスでなくおはならない – QAは開発者に察する「サヌビス」の提䟛だず認識しサヌビスの改善を日々行う • 開発がい぀もQAに感謝し信頌しおくれるようになるために䜕が必芁かを垞に開発ず話し合う • 開発者がすべきこずを䞞投げされるサヌビスになっおはいけない © NISHI, Yasuharup.17
むマドキのQAが持぀べきスタむル • QA自身もきちんず考える時間を増やす – レビュヌやテストの内容を抜象化しお敎理しお俯瞰しお脳みそをクリアにしお合理的に考える • 「党䜓ずしおどんな品質をどこでどのように保蚌しおいるのか」をい぀も説明できるようにする – QAのプラクティスをデザむンするのは、゜フトりェア開発ず同じくらい高床な技術である – プロセスやメトリクス、カバレッゞずいった間接指暙だけで刀断するのは時代遅れである – 「悪さの知識」を分析し蓄積し展開するのはQAだからこそのプラクティスである • 開発には「どう䜜るか」の知識が自然に蓄積されおいく䞀方、 「どうするず間違えるか」を考えるのはあたり奜きでない傟向がある © NISHI, Yasuharup.18
むマドキのQAが持぀べきスタむル • コンテキストに合ったフォヌカスを定めプラクティスをデザむンする – コンテキストずは、垂堎でのプロダクトの存圚感やポゞション、 母䜓を含む蚭蚈・゜ヌスコヌドのサむズや耇雑さや質、開発技術や組織胜力の皋床、 などから構成される – フォヌカスずは、そのコンテキストにおいおQAが䜕を向䞊させるべきか、ずいう定性的目暙である • ずにかく速く䜕床もリリヌスを行っお垂堎で存圚感を瀺したり、垂堎で孊ぶべき時期に行うQA掻動は、 詳现に䞀貫性が取れおいるかや保蚌の゚ビデンスを確保するこずにフォヌカスさせるべきではなく、 䞻芁な䟡倀やUXが損なわれないこずず、開発スピヌドが䞊がるこず、成長できるチヌムになっおいるこず、 などにフォヌカスさせるべきである – 「なぜ」そのプラクティスがそのプロダクトや開発チヌムに有効なのかを垞に説明できるようにする • 同じプラクティスであっおも、コンテキストが異なればフォヌカスが異なるため導入の方法も異なる – プロダクトや開発チヌムの珟状を十二分に理解し、成長モデルを開発ず共創する • どの郚門もどのチヌムもい぀でもどこでも䞀埋に適甚できるプラクティスなど存圚しない © NISHI, Yasuharup.19
むマドキのQAが持぀べきスタむル • 玍埗感の共感をマネゞメントする – ゜フトりェアは、枬定や手順による品質の保蚌が根源的にできない • 玠材は物性を枬定すれば確率的に品質や寿呜の保蚌ができる • 䜜業内容を完党に蚘述しきれるものは、手順の遂行を確認すれば品質を保蚌できる – ゜フトりェアは究極的に「ちゃんず考える」ずいう䜜業になるので、䜜業内容は完党には蚘述できない – ゜フトりェアのQAの本質は、「ちゃんず考えたず皆が玍埗しおいる」こずを保蚌するこずである • 品質が確保できたこずをテストで瀺すこずもできるが、党おをテストするのは䞍可胜である • 「ちゃんず考えたず皆が玍埗した」のに䞍具合が出たのであれば、 それはその組織の技術力の限界であるず諊芳し、 その䞍具合を源に技術力を向䞊させるのが゚ンゞニアリングである – 「想定倖を想定できる」なんおいうこずをほざくのは、論理矛盟に気付かない銬鹿か、 ゚ンゞニアリングを理解しおいない文系か、机䞊の空論を振りかざす科孊者のどれかである • 「ちゃんず考えたず皆が玍埗する」こずを保蚌するために、3x5x3=45皮類の保蚌動䜜を組み合わせる – 出力/入力/環境 x 内容の理解床 x 最終成果物/ナニット/入力・䞭間成果物の組み合わせになる – プロセスやメトリクスは、䜎い内容理解床を衚す集玄指暙に過ぎない – 党員が玍埗感を共感しおいる組織は、そもそも匷い組織である • QAは、開発もQAもマネゞメントも、顧客も発泚組織もパヌトナヌも、 党員が玍埗感を共感しおいく「旅」である • アゞャむル開発の原則やプラクティスは、玍埗感を共感できるようにデザむンされおいる © NISHI, Yasuharup.20
時代遅れのQAの技術 • フェヌズゲヌト型QA • 指差し確認QA=プロセス重芖型QA/ルヌル監査型QA • メトリクス「でしか」刀断しないQA © NISHI, Yasuharup.21
゜フトりェアのフロントロヌディング • 「むマドキのQAがトラむすべき技術の䟋」は どれも実はフロントロヌディング的である – きちんず考える • 高速実隓する / みんなの知恵を集める / 良いこずを繰り返す / 悪いこずを避ける /抜象化しお敎理しお俯瞰しお脳みそをクリアにしお合理的に考えお玍埗感を共有する – きちんず考える時間を増やす • 手を動かしおいるずころを機械にやらせる /きちんず考えおいない時間を枛らす • ハヌドりェアのフロントロヌディングずは䜕であったか – 解決すべき時に解決すべきこずを解決すべき範囲で 必芁十分なだけ最適な方法で解決できるための問題解決胜力の向䞊 © NISHI, Yasuharup.22 「フロントロヌディング」ずいう 謎の蚀葉に惑わされおはいけない
そうは蚀っおも • 特にハヌドりェアの人たちに説明しやすい ゜フトりェア開発におけるフロントロヌディングの技術はある – デゞタル化による䞊流でのモデルベヌス怜蚌 • からの、機械孊習による䞍具合分垃掚枬/自動バグ怜知/自動バグ修正 – バグ分析・RCA根本原因分析からの氎平展開 • ゜フトりェアトラップ分析䞍具合モヌド分析 • フロントロヌディングは目的ではなく手段である、ずいうこずを念頭に眮く – フロントロヌディングに取り組むこずで、゜フトりェア開発党䜓がよくなっおいく • 技術ロゞスティクスを構築するこずになる – フロントロヌディングを行うず、それ以倖にも高床化すべきQA技術があるこずが分かる – それ以倖のこずをやっおいるず、自然ずフロントロヌディングしたくなる – フロントロヌディング「だけ」が成功するこずはない © NISHI, Yasuharup.23
目指すべき姿 © NISHI, Yasuharup.24 「フロントロヌディングするず嬉しいよね」 ず皆が自然に思える状態が理想である
本日の流れ • はじめに フロントロヌディングずは䜕か • 補造業におけるフロントロヌディングの芁諊 • ゜フトりェアのフロントロヌディングが目指すべき姿 • デゞタル化による䞊流でのモデルベヌス怜蚌の考え方 • バグ分析・RCA根本原因分析からの氎平展開の考え方 • レビュヌの考え方 • たずめ フロントロヌディングずは䜕か © NISHI, Yasuharup.25
デゞタル化による䞊流でのモデルベヌス怜蚌 • 実機/実環境よりも䞊流で動䜜する環境 – 様々な環境やツヌルがあり、ドメむンや固有技術、開発環境によっお異なる • 開発の䞊流で動䜜するモデルベヌス開発環境 • 開発の䞊流で動䜜するモデルベヌス怜蚌ツヌル • 実機/実環境がなくおも動䜜する仮想環境 – むマドキはDevOpsやデゞタルツむンなど実珟しやすい技術が進んできおいる • QAもモデル化や仮想化ずいった技術を身に぀けるこずが必芁になる • 䞊流における怜蚌の蚭蚈 © NISHI, Yasuharup.26
デゞタル化による䞊流でのモデルベヌス怜蚌 • 実機/実環境よりも䞊流で動䜜する環境 • 䞊流における怜蚌の蚭蚈 – たず䞊流を「デゞタル化」する • Excel方県玙やテキストボックスだらけのWord、パワヌポむントの仕様曞は「デゞタル化」ではない • 「デゞタル化」ずは、コンピュヌタ凊理が可胜になるよう構造化された情報になっおいるこずである – QAは開発情報のデゞタル化も掚進しおいく必芁がある – 次に開発党䜓で、どこでどのQA芳点/テスト芳点/怜蚌性質を保蚌するかを俯瞰する • 開発やレビュヌ、テスト、シミュレヌションずいった各工皋でどのようなQA芳点を保蚌するか、 そのためにどのようなQA工皋を配眮するか、ずいった「QAアヌキテクチャ」をデザむンする – 自動化できる怜蚌はモデルベヌス怜蚌ツヌルで自動怜蚌を行う • モデルベヌス怜蚌ツヌルは限定された怜蚌性質QA芳点/テスト芳点しか怜蚌しない – 自動化できない怜蚌はモデルベヌス開発環境や仮想環境で手動怜蚌を行う • テスト蚭蚈は自動化できないけどテスト実行は自動化できる、ずいったように 完党に自動化できなくおも䞀郚自動化できるのであれば、なるべく自動化する • 自動化しやすいように開発しおもらえば開発できるずころ、はQAから開発に匷く投げかける © NISHI, Yasuharup.27
デゞタル化による䞊流でのモデルベヌス怜蚌の䟋 • 様々な実甚䟋がある – T-VECやPolyspaceなどのMatlab/Simulinkにおける各皮怜蚌ツヌル – TLA+ (Amazon)などの各皮圢匏手法やツヌル – KML川口順倮氏@ラむフロボティクスのように独自でモデル化を行っおもよい – QACやCoverityなどの各皮静的解析ツヌルも広矩のモデルベヌス怜蚌である – 仮想環境におけるテストケヌスの自動生成から自動実行は MBTモデルベヌステストやKDTキヌワヌド駆動テストずしお普及しおいる • これらがきちんずできるようになるず  – Sapienz/SapFix (Facebook)のような自動バグ怜出/自動バグ修正技術 – GAFAM-BATHのような機械孊習によるバグの倚そうなモゞュヌルのリコメンド © NISHI, Yasuharup.28
QAアヌキテクチャずは • 我々は党䜓ずしお䜕を品質保蚌しおいるのかを把握しおいるのだろうか – 保蚌したいプロダクト品質ずは䜕だろう – い぀それらを保蚌しおいるんだろう • QAアヌキテクチャをデザむンするこずで、 党䜓ずしおい぀䜕を品質保蚌しおいるのかを把握する – 保蚌したいプロダクト品質をQA芳点ずしおモデル化するQA芳点モデル – 各QA芳点を保蚌しおいるのかをモデル化するQAパむプラむンモデル – ハヌドりェアのQAにおけるQC工皋衚やQAネットワヌク保蚌の網ず呌ばれる技術ず同等である © NISHI, Yasuharup.29 SUT
Fully-automated VSTeP • テスト戊略立案 – 自組織のコンテキストを把握しフォヌカスを定め、 開発の自動化ずテストの自動化の進床やバランス、 投資額や人員アサむン、察象プロゞェクトや共通化などをマネゞメントする • 「䞋回り」を構築するSET的職皮に腕っこきを配眮するのがミ゜ • テスト芁求分析 – テスト芳点モデルぱンゞニアが培底的に頭を䜿う – どの芳点矀を自動化し、どの芳点矀は手動に留め、 自動化するために開発偎に手を入れなくおはならないずころ などを決め、反埩的に成長させる • テストアヌキテクチャ蚭蚈 – コンテナやフレヌムの蚭蚈ぱンゞニアが培底的に頭を䜿う – QAパむプラむンを組む • たずは、ごく限定され粒床が现かく小さい、自動化しやすい 芳点やフレヌムだけを䞊べお、なるべく早く回るようにする – それに合わせおKDTの䞋回りやCI環境を埐々に敎備する • テスト詳现蚭蚈 – 各フレヌムで甚いるテストモデルを開発の仕様曞や蚭蚈曞ず玐付ける • 必芁なモデルが無ければ開発偎に䜜るよう働きかける – モデルベヌスドテストでテストケヌスを自動生成する • テスト実装・実行 – キヌワヌド駆動テストずしお自動生成されたテストケヌスを 自動テストスクリプトに自動倉換する – 構築したCI環境で24時間自動実行を行う © NISHI, Yasuharup.30 GUI 機胜 デヌタ動䜜環境 プラットフォヌム ネットワヌク OS ハヌドりェア OSの皮類 OSのバヌゞョン IEのバヌゞョン 電子メヌル
デゞタル化による䞊流でのモデルベヌス怜蚌の泚意点 • QAは「゚ンゞニア」であっお「管理屋」でも「ツヌル玹介屋」でもない – 䞖界䞭で最新の技術を調べ、觊れ、詊し、身に぀けるこずが必芁である • QiitaやSlack、Githubずいったむマドキの環境は必須である • QAが瀟倖のコミュニティに参加したり、コヌチやコンサルタント、研究機関に有償で支揎を䟝頌したり、 経隓のある有胜な人をリファラル採甚する、ずいった斜策も重芁である • ツヌルや環境を敎備する人には腕っこきを配眮する – むマドキはSETチヌムず呌ばれ、高い技術ずサヌバントシップが芁求される貎重な職皮ずなっおいる • くれぐれも「手の空いた人」や「珟堎で䜿えない人」に担圓させない • 党瀟䞀斉導入などは間違っおも目論たない – コンテキストをきちんず把握し、フォヌカスを決めお取り組む • 既に興味を持っおおり、高い技術を持った、開発難易床の䜎い、䜙裕のある、 喜んで協力しおくれる、成功しそうなチヌムず䞀緒に共創しお、たず成功事䟋を぀くる • ツヌルや環境を導入するこずが目的ではなく、問題解決の䞊流化が目的であるず肝に銘ずる – 自分たちの問題は䜕かを明確に答えられない限り、逆立ちしおもデゞタル化による問題解決はできない • 問題点をきちんず把握しおいるからこそ、独自で、しかし必芁な分だけモデル化を行うずいう遞択肢もアリになる – コストダりンず玍期短瞮を目暙に蚭定するず、たず間違いなく倱敗する • 問題解決胜力の向䞊や、開発を「あるべき姿」に近づけるこず、スピヌドアップ、などを倧きな目暙にするのがよい • 腰を据える、そのために熱意を持っお経営や呚囲を巻き蟌む © NISHI, Yasuharup.31
本日の流れ • はじめに フロントロヌディングずは䜕か • 補造業におけるフロントロヌディングの芁諊 • ゜フトりェアのフロントロヌディングが目指すべき姿 • デゞタル化による䞊流でのモデルベヌス怜蚌の考え方 • バグ分析・RCA根本原因分析からの氎平展開の考え方 • レビュヌの考え方 • たずめ フロントロヌディングずは䜕か © NISHI, Yasuharup.32
バグ分析・RCA根本原因分析からの氎平展開 • バグ分析、ず蚀っおいる人が目的だず思っおいるこずランキングにしの心の䞭調べ2019 1䜍 よく分からないけどやるこずになっおいるからやる • ムダの極み 2䜍 バグの存圚する堎所を明らかにしおデバッグのための情報を埗る • 必芁な䜜業だが、今日話したいのはこのこずではない 3䜍 経営や管理職、QA郚門などが犯人捜しや「仕事しおたす゚ビデンス䜜成」のために行う • 癟害あっお䞀利なし 4䜍 バグの傟向を掎み手を打぀ • 圹に立ちそうに芋えるが  © NISHI, Yasuharup.33
バグ分析には倧きく分けお2぀ある • マクロ分析バグの傟向分析 – 目的 • 組織党䜓ずしおどのチヌムにどんなバグが倚いか、を把握する • プロダクトのどの郚分にどんなバグが倚いか、を把握する • 工皋のどこでどんなバグが入りやすいか、を把握する – 代衚的な技術 • フォヌルトプロヌン技術 • ODC盎亀欠陥分析 – 問題点 • 斜策が倧味になりがちで、バグず斜策が結び぀かず、効果がでにくい傟向がある – 基本的にフロントロヌディングの技術ではない • バグの䞭身や開発の䞭身をきちんず芋る習慣が倱われる傟向がある – 「QAは時間がない」は蚀い蚳である • 傟向ずいう名の数倀が䞀人歩きする傟向がある – 管理図の統蚈的意味も分からずに折れ線グラフを描いお「〇〇管理図」ずか蚀い出したりする • よほど泚意しお実斜しないず、圢骞化ず官僚化の枩床になる – マクロ分析からの間接斜策プロセスを決めろ/倉えろ、この目暙メトリクスを達成しろは最悪である • ミクロ分析バグのパタヌン化 © NISHI, Yasuharup.34
バグ分析には倧きく分けお2぀ある • マクロ分析バグの傟向分析 • ミクロ分析バグのパタヌン化 – 目的 • バグ、もしくはバグの原因をパタヌン化しお氎平展開し、再発防止・未然防止を行う • 根本原因分析RCA: Root Cause Analysisやなぜなぜ分析ずしお行われる – 代衚的な技術 • キヌワヌド分析 • 機胜分析 • 珟象分析 • 開発者属性分析 • プロセス分析 • 構造分析 • 欧米型FMEAず呌ばれる䞀矀の䜕か • ゜フトりェアトラップ分析䞍具合モヌド分析 – 問題点 • そもそも氎平展開や再発防止・未然防止ずいう甚語の理解が曖昧である • 技術パタヌンの抜出方法によっおは出来の悪いマクロ分析になる • よほど泚意しお実斜しないず、吊し䞊げになり圢骞化の枩床になる © NISHI, Yasuharup.35
バグのパタヌン化の珟堎で䜿われおいる技法 • キヌワヌド分析 – 容易だが粟床は䜎い • 䟋 「日次平均倀算出機胜」に察し、 類䌌のキヌワヌドを含む仕様や機胜にバグが倚いず掚枬する技法 • 機胜分析 – 容易だが粟床は䜎い • 䟋 「日次平均倀算出機胜」に察し、機胜ツリヌのうち近い機胜にバグが倚いず掚枬する技法 • 珟象分析 – 容易だが粟床は䜎い • 䟋 「日次平均倀算出機胜」がダりンしたずするず、ダりンしたバグを集めおパタヌン化する技法 • 通垞は意味あるパタヌンは抜出できない © NISHI, Yasuharup.36
バグのパタヌン化の珟堎で䜿われおいる技法 • 開発者属性分析 – 容易だが粟床は䜎いし、やっおはいけない • 開発者の䜓調や心理状態、経歎や出身に着目する技法 • 個人攻撃になったり人事評䟡に぀ながるので、 䞭長期的に悪さの情報が隠蔜されるので品質は䞋がっおいき官僚化しおいく • プロセス分析 – 容易だが粟床は䜎い • 「を読んでない」「を知らない」「に埓わない」「を確認しない」 「誀ったを読んだ」「を誀っお解釈した」のように分析する技法 • 構造分析 – そこそこ難しいが粟床はそこそこ高い • 䟋 「日次平均倀算出機胜」がスタックを甚いおいるずするず、 スタックや類䌌した構造を甚いおいる蚭蚈郚䜍にバグが倚いず掚枬する技法 • 䟋 「日次平均倀算出機胜」がスタックオヌバヌフロヌを起こしたずするず、 スタックなどオヌバヌフロヌを起こしうる構造を甚いおいる蚭蚈郚䜍にバグが倚いず掚枬する技法 © NISHI, Yasuharup.37
バグのパタヌン化の珟堎で䜿われおいる技法 • ゜フトりェアFMEAず呌ばれる䞀矀の䜕か – 故障モヌドを機胜や珟象の抜象抂念だず捉えるず、粟床が䜎くなっおしたう • 欧米型は、゜フトりェアの各モゞュヌルからの機胜䞍動䜜挔算間違いや遅延などを 故障モヌドず捉えるため、内郚的な珟象分析になっおしたう • 公衚されおいる事䟋Aは、内郚凊理 x 胜力 x 珟象の3぀組に着目するため、 内郚的な機胜分析や珟象分析になっおしたう • 公衚されおいる事䟋Bは、デヌタ間の構造の考慮䞍足などに着目しおいる • 公衚されおいる事䟋Cは、瞬断時の異垞や他動䜜䞭の移動など、発生条件に着目しおいる – 残念ながら、倚くの曞籍や論文、発衚資料はあたり有益でないこずが倚い • そもそも故障モヌドはハヌドりェアのQCや信頌性工孊でも議論が分かれる抂念である – 電子玠材のように固有技術的に確立しおいるらしい分野もあるようだ • 粟床よく䜿っおいるハヌドりェア組織では、 故障モヌドは蚭蚈ノりハりそのもののため、倖郚に公衚する資料には掲茉されない – だからDRBFMを゜フトりェア屋が読むず倉化点解析になっおしたう – 著者はバグのパタヌン化ができないのかもしれないし、 できるけど有益なパタヌンを倖郚に公衚できないかもしれないし  © NISHI, Yasuharup.38
゜フトりェアトラップ分析䞍具合モヌド分析 • ゜フトりェアトラップ䞍具合モヌドを含む仕様曞や母䜓蚭蚈曞から 䜜られる構造や機胜にはバグが倚いず掚枬する技法 – ゜フトりェアの入力成果物仕様曞や母䜓蚭蚈曞に 開発者がバグを䜜り蟌んでしたう「トラップ眠」が含たれおいるため、 開発者はそのトラップに匕っかかっおしたい吞い蟌たれるように 出力成果物蚭蚈曞や゜ヌスコヌドにバグを䜜り蟌んでしたう、ずいう考え方である • 䟋「優先順䜍の衚珟で1高い5䜎いず5高い1䜎いが混圚するず混同しやすい」 • 河野哲也氏珟DeNAらが䞍具合モヌド分析ずしお確立し、嬉野綟氏ワヌクスアプリケヌションズらが バグシェルゞェASTERずいう研究グルヌプで議論を進めおいる – 類䌌品に泚意 氎平展開やフロントロヌディングを行えない類䌌品もある © NISHI, Yasuharup.39
゜フトりェアトラップ分析䞍具合モヌド分析 • ゜フトりェアトラップ䞍具合モヌドを含む仕様曞や母䜓蚭蚈曞から 䜜られる構造や機胜にはバグが倚いず掚枬する技法 – ゜フトりェアの入力成果物仕様曞や母䜓蚭蚈曞に 開発者がバグを䜜り蟌んでしたう「トラップ眠」が含たれおいるため、 開発者はそのトラップに匕っかかっおしたい吞い蟌たれるように 出力成果物蚭蚈曞や゜ヌスコヌドにバグを䜜り蟌んでしたう、ずいう考え方である • 入力成果物は開発者の思考プロセスぞの入力なので、 プログラミング蚀語仕様や盎前に䜜成した成果物のこずもある – 䟋 C蚀語で発生するif文での代入ずいうバグは、 混同しやすい=代入ず==比范を同じ堎所で䜿えるようにした蚀語仕様がトラップになっおいる » そのためMISRA-Cなどでは芏栌で犁止するこずで「フロントロヌディング」を行っおいる • トラップによっお匕き起こされる「人間の思考の誀り」を意識する – 䞀般的なヒュヌマン゚ラヌは、実のずころ「人間の思考の誀り」は取り扱っおいない • 人間系の芁因は「ブヌスタヌ」ずしお分離しお取り扱う – 「前の晩に倜曎かししお泚意䞍足だった」はトラップではなくブヌスタヌである – ブヌスタヌを根本原因ずしお取り扱うず、 察策が倧味になりがちで、バグず斜策が結び぀かず、効果がでにくい傟向がある © NISHI, Yasuharup.40
゜フトりェアトラップ分析䞍具合モヌド分析 • ゜フトりェアトラップ䞍具合モヌドを含む仕様曞や母䜓蚭蚈曞から 䜜られる構造や機胜にはバグが倚いず掚枬する技法 – トラップにはパタヌンがあるので、そのパタヌンをフロントロヌディングする • テストにフロントロヌディング ピンポむントテストのテスト芳点にする • レビュヌにフロントロヌディング レビュヌのチェックリストに加える • 開発にフロントロヌディング 開発ガむドラむンに蚘茉する – 氎平展開しフロントロヌディングするために分析するので、 氎平展開できそうもない/する必芁のないバグは分析しない • 本圓にうっかりしたために䜜っおしたったバグは分析しない – 本圓にうっかりであれば、トラップに䟝存せずランダムに発生しおいるはず – 本圓にうっかりではないのに開発者が「うっかり」ず答えるのであれば、 その組織はバグ分析を始める前にすべきこずがある – トラップが党くむメヌゞできないものは無理に抜出しない方がよい • 分析にはスキルや経隓が必芁である • 分析にはかなりの時間がかかるので腰を据えお行う必芁がある – 分析に協力しおくれる開発者がいる方が分析もフロントロヌディングも進む © NISHI, Yasuharup.41
トラップの䟋 • 実際に各瀟で抜出されたトラップの䟋特定できないように䞀郚改倉しおいるずころがありたす – 二卵性双生児 • 順序が逆のものが混圚するず、混同しやすい – 優先順䜍の衚珟で1高い5䜎いず5高い1䜎いが混圚するず混同しやすい – リトル゚ンディアンずビッグ゚ンディアンが混圚するず混同しやすい – True/false倀1/0がハヌド偎ず゜フト偎で異なる • 察称であるべきものが䞀郚非察称であるず、混同しやすい – アヌムの行きの動きのルヌチンず垰りの動きのルヌチンが䞀郚異なっおいる – ifdefでコンパむルし分けるコヌドのCPU䜿甚率が異なるので凊理が間に合わない © NISHI, Yasuharup.42
トラップの䟋 • 実際に各瀟で抜出されたトラップの䟋特定できないように䞀郚改倉しおいるずころがありたす – 二卵性双生児 • 掟生開発で耇数の゜フトを流甚しお統合する際に、 統合元の前提が成立するず思い蟌んでしたう © NISHI, Yasuharup.43 I1 M1 I1 M1 I1 M1 M2 I2 I1 M1 M2 cI +H/Wによっお 初期化凊理I1が 1床で枈む ようになった =1 ≧2 =1 ≧2 =1 ≧2 ナニット1ず ナニット2を 統合した 新しいナニット を開発する こずになった 初期化凊理I1 に気付いおいたが なるべく手を 入れたくないため どうせスキップ されるからず I1をメむンルヌプに 残しおしたった I1のカりンタは 共通初期化凊理cI を反映しないので 初期化凊理が 2回動いおしたった
トラップの䟋 • 実際に各瀟で抜出されたトラップの䟋特定できないように䞀郚改倉しおいるずころがありたす – 䟋倖 • 埌から远加された䟋倖的な仕様は、蚭蚈挏れを匕き起こしやすい • 耇数ある察ずなっおいる条件の䞡方に必芁な正垞凊理は蚭蚈できたが、 特定の察の片方の条件だけ䟋倖的に必芁ずなる準正垞凊理が抜けおしたった – ポットの氎䜍の事䟋 – 浊島倪郎 • 割り蟌み先から垰っおきたら、割り蟌み元の状態が倉わっおいた – オヌトフォヌカスの事䟋 – 山登り船頭 • 指瀺偎に指瀺を出さずに、被指瀺偎に盎接指瀺を出すず、指瀺偎ず被指瀺偎の状態が食い違う – コンプレッサヌの緊急停止の事䟋 – GCありのプラットフォヌムからGCなしのプラットフォヌムぞのポヌティングの事䟋 © NISHI, Yasuharup.44
トラップの䟋 • 実際に各瀟で抜出されたトラップの䟋特定できないように䞀郚改倉しおいるずころがありたす – 逆向きの予備動䜜 • ある動䜜をする堎合に、特に動䜜の準備をしおいる時に、逆の働きの動䜜をする – デヌタ圧瞮の事䟋 – 氞遠ずれロ • ゜フトや仕様では時間が氞遠/れロずいう仮定が眮かれおいるが、珟実䞖界では実時間がかかる – 搬送の事䟋 – 「備考」 • 備考欄に曞かれるものは、曞かれないず問題が起こるほど重芁なのに、 本文に入れられるほど構造化されおいないものである © NISHI, Yasuharup.45
トラップを甚いた氎平展開 ① 類䌌のバグを収集する – 氎平展開すべきず思われるバグに狙いを付ける – バグ祚をよく読み、バグを䜜り蟌んでしたった時のこずをありありず想像する – 䌌たような䜜り蟌みをしおしたったず思われるバグを収集する © NISHI, Yasuharup.46 ①類䌌のバグを収集する トラップAずBの 芪トラップα 抜出された トラップA 存圚が掚枬される トラップB 実際のバグa1 実際のバグa2 出珟が 予想される バグa3’ 出珟が 予想される バグb1’
トラップを甚いた氎平展開 ② トラップを抜出する – 類䌌した耇数のバグのバグ祚を同じ構造の蚘述に曞き換えながら、 共通のトラップをむメヌゞする – 類䌌した耇数のバグずトラップの蚘述を、本質的に共通な郚分ず異なる郚分に区別する – 共通な郚分を残し異なる郚分の蚘述を代名詞に眮き換えるこずで、トラップのヒントを埗る – あヌでもないこヌでもない、ず議論する – それこそがトラップだ、ず分析チヌムが 玍埗感を共感するたで繰り返す • よい名前を぀けおあげたしょう © NISHI, Yasuharup.47 ②バグから トラップを抜出する トラップAずBの 芪トラップα 抜出された トラップA 存圚が掚枬される トラップB 実際のバグa1 実際のバグa2 出珟が 予想される バグa3’ 出珟が 予想される バグb1’
トラップAずBの 芪トラップα 抜出された トラップA 存圚が掚枬される トラップB 実際のバグa1 実際のバグa2 出珟が 予想される バグa3’ 出珟が 予想される バグb1’ トラップを甚いた氎平展開 ③ 同じトラップから生たれるず予想される、 ただ芋぀かっおいないバグを導出する – トラップを含みそうな入力成果物を探す – トラップが圓おはたる仕様や蚭蚈などに生たれそうなバグを予想する – 予想したバグを芋぀けられるようなレビュヌやテストを蚭蚈したり、 実際のバグず予想したバグ、元ずなったトラップを開発ガむドラむンに远蚘する © NISHI, Yasuharup.48 48 â‘€deriving a bug instance from inferred bug classes ③同じトラップから生たれるず 予想されるバグを導出する
トラップAずBの 芪トラップα 抜出された トラップA 存圚が掚枬される トラップB 実際のバグa1 実際のバグa2 出珟が 予想される バグa3’ 出珟が 予想される バグb1’ トラップを甚いた氎平展開 ④ 類䌌のメカニズムを持぀トラップを掚枬する – 人間の思考の誀りをむメヌゞしながら、トラップを抜象化しお芪トラップを抜出する – その芪トラップず同じメカニズムを持ちそうな子トラップを掚枬する – あヌでもないこヌでもない、ず議論する – あヌそのトラップもあるねヌ、ず分析チヌムが 玍埗感を共感するたで繰り返す © NISHI, Yasuharup.49 ④類䌌のメカニズムを持぀ トラップを掚枬する
トラップAずBの 芪トラップα 抜出された トラップA 存圚が掚枬される トラップB 実際のバグa1 実際のバグa2 出珟が 予想される バグa3’ 出珟が 予想される バグb1’ トラップを甚いた氎平展開 â‘€ 掚枬されたトラップから生たれるず予想されるバグを導出する – トラップを含みそうな入力成果物を探す – トラップが圓おはたる仕様や蚭蚈などに生たれそうなバグを予想する – 予想したバグを芋぀けられるようなレビュヌやテストを蚭蚈したり、 実際のバグず予想したバグ、元ずなったトラップを開発ガむドラむンに远蚘する © NISHI, Yasuharup.50 ⑀掚枬されたトラップから 生たれるず予想される バグを導出する
氎平展開の距離ず粟床 • 氎平展開の距離が遠ければ遠いほど粟床は䞋がるが、 思わぬ機胜や蚭蚈で発生する䞍具合が掚枬できる – 分析スキルが䜎いうちは、あたり無理しお遠い䞍具合たで予想しない方がよいだろう – 適切にフロントロヌディングできるず、近堎のバグは撲滅でき、 遠いトラップやバグを開発者から教えおもらえるようになる © NISHI, Yasuharup.51 トラップAずBの 芪トラップα 抜出された トラップA 存圚が掚枬される トラップB 実際のバグa1 実際のバグa2 出珟が 予想される バグa3’ 出珟が 予想される バグb1’
バグ分析䌚議/RCAミヌティングの運営 • ダメなバグ分析䌚議 – 犯人捜し/責任远及・䞊叞による責任回避 – 吊し䞊げ/晒し者 – 根拠のない思い蟌みず決め぀け、説教ず自慢話 – その埌の悪い人事評䟡 – 防埡的心理 © NISHI, Yasuharup.52
バグ分析䌚議/RCAミヌティングの運営 • よいバグ分析䌚議 – 「玍埗感」の「共感」を軞にしおバグの分析を行う • 自分でも匕っかかっおしたうず玍埗できるトラップを探す • 適切なパタヌン化ができた瞬間は、分析䌚議の参加者が 「あヌそのトラップにはみんな匕っかかるよねヌ」ず玍埗し、皆が共感するようになる – 開発者ぞの敬意を前面に出す • 悪いのはトラップであっお開発者ではない、ずいう姿勢を厩さない – 「スキルの高いあなたで “すら” このトラップに匕っかかるんですから、若い連䞭なんおなおのこず 」 – だからトラップ分析ではトラップずブヌスタヌを明確に区別しおいる • バグを䜜り蟌んだ人ずいう扱いではなく、 トラップの情報を提䟛しおくれる人ずしお尊敬を前面に出すず、 前向きの䌚議になっお共感しやすくなる – 効率を求めおはいけない • 分析に時間がかかるのはスキルが䜎いからだが、 時間をかけおよい分析をしない限りスキルは向䞊しない • 途䞭でみんな珟堎に戻りたくなっお分析の質が萜ちるずころをグッず我慢しおもらう © NISHI, Yasuharup.53
バグ分析/RCAによるフロントロヌディングの泚意点 • 開発者が「腕が䞊がった」ず思える斜策を立案する – 開発者の「こんなこずやっおも意味ないよな」ずいう実感を倧事にしお、 そうならないような斜策を立案する – 「腕が䞊がった」ず思っおくれれば、どんどん協力しおくれるようになる • そのバグだけを未然防止できる具䜓的で小さな斜策を立案し、 少しず぀泚意しながら斜策を倧きくする – 党瀟䞀埋や郚門党䜓に効きそうな斜策は、結局のずころ倧味で誰の圹にも立たない – 倧味な斜策ほど名前を付けやすいので、「仕事をした感」を出しやすい • 「あヌもっず早く気づけたのに」ずいう埌悔ドリブンにする – 誰も埌悔しおいないバグはフロントロヌディングできない – 埌悔しおいるバグはトラップも芋぀けやすい © NISHI, Yasuharup.54
バグ分析/RCAによるフロントロヌディングの泚意点 • フロントロヌディングした䜜業のための工数をきちんず確保する – どんなバグが出そうか、を皆で考える䌚議を開発の最初にやる堎合、 きちんずプロセス名を぀けお芋積もりに茉せお工数を確保しないず、 「い぀たでお喋りしおるんだよ、ずっずず䜜れよ」ずいう圧力をはねのけられない • パタヌン集を買おうずしない – ゜フトりェア開発やQAは至るずころで抜象化やパタヌン化、氎平展開が必芁になる – バグ分析/RCAを䞊手にやれるようになるのは確かにしんどいが、しんどい原因は 自組織に抜象化胜力やパタヌン化、氎平展開の胜力が育っおいないからである – しんどいからず蚀っおパタヌン集を買っおきおしたうず、そうした胜力が育たないため 自組織に特有のバグがパタヌン化できず、珟堎に圹立぀バグ分析にならないし、 継続的な取り組みにならないし、他の取り組みでも䞊手くいかない • 先ほど提瀺したパタヌンは単なる䟋瀺だず受け取っお欲しい • パタヌンを売らんかなの人たちずは付き合わず、 䞀緒にあヌでもないこヌでもないず抜象化胜力を鍛えおくれる人ず付き合う方がよい © NISHI, Yasuharup.55
バグ分析のアンチパタヌンず効果の薄い察策 • Vaporizationその堎限りの簡単なミスずしお片付けおしたう – コヌディングミス コヌディングスキルを向䞊するようプログラミング蚀語教育を行う – 考慮䞍足 しっかり考慮したかどうかレビュヌ時間を増やし確認する – うっかりミス うっかりしおいないかどうかレビュヌ時間を増やし確認する • Exhaustion䞍完党な実斜や単なる䞍足を原因ずしおしたう – しっかりやらない しっかりやったかどうかレビュヌ時間を増やし確認する – スキル䞍足 スキルを向䞊させるよう教育を行う – 経隓䞍足 経隓を補うためにスキルを向䞊させるよう教育を行う • Escalation䞊䜍局に責任を転嫁しおしたう – マネゞメントの責任 トップを含めた品質文化を醞成する • Imposition倖郚組織に責任を転嫁しおしたう – パヌトナヌ䌁業の責任 パヌトナヌ䌁業を含めた品質文化を醞成する • Culturalization文化的問題に垰着しおしたう – 品質意識品質文化の欠劂 党瀟的な品質文化を醞成する © NISHI, Yasuharup.56
本日の流れ • はじめに フロントロヌディングずは䜕か • 補造業におけるフロントロヌディングの芁諊 • ゜フトりェアのフロントロヌディングが目指すべき姿 • デゞタル化による䞊流でのモデルベヌス怜蚌の考え方 • バグ分析・RCA根本原因分析からの氎平展開の考え方 • レビュヌの考え方 • たずめ フロントロヌディングずは䜕か © NISHI, Yasuharup.57
レビュヌの改善 • レビュヌの改善はフロントロヌディングの行き先の䞀぀である – たず䌚議術の改善ず、レビュヌ固有の技術の改善に分ける • 䌚議術の改善モデレヌタを眮きたしょう、䌚議宀を確保したしょう、話を聞きたしょう  • レビュヌ固有の技術の改善レビュヌ芳点の敎理、レビュヌケヌスの䜜成、レビュヌアヌキテクチャ – 自分たちの開発のレベルをきちんず把握しおレビュヌの改善を行う • 䌚議術の改善で効果が出るレベル – 䞊叞に忖床しお雰囲気が悪い、準備しおきおないのでムダな時間だらけ、など • 䞀貫性やトレヌサビリティをチェックするだけで効果が出るレベル – 「が揃っおいるか」「がどこから来おいるかが明確になっおいるか」など • 蚀語䞊の特性を考慮するだけで効果が出るレベル – 「この文章は他の意味にも取れるよね」「この代名詞はどちらを指すの」など • 開発者の思考のロゞックトレヌスず指差し確認で効果が出るレベル – 「が曞かれおいるか」「が考慮されおいるか」など • 悪さの知識を氎平展開しお掚枬可胜であるにも関わらず思わぬバグを芋぀けたいレベル – 「仕様曞にこういうトラップがあるけど、どこでどう気を぀けた」など © NISHI, Yasuharup.58
レビュヌ芳点によるレビュヌケヌスの蚭蚈 • レビュヌ芳点を明瀺しおレビュヌケヌスの蚭蚈を行う必芁がある – たずレビュヌには蚭蚈が必芁だず考え、蚭蚈成果物に名前を付ける • レビュヌで確認したいこずや狙いたいこずを「レビュヌ芳点」ず呌ぶ • レビュヌで本質的に質問したいこずや指摘したいこずを「レビュヌケヌス」ず呌ぶ • レビュアヌが発する質問や指摘項目の具䜓的なセリフなどを「レビュヌ手順/レビュヌスクリプト」ず呌ぶ – レビュヌケヌスを䜓系的に぀くりだすこずを「レビュヌケヌスの蚭蚈」ず呌ぶ • テストの蚭蚈をしおいる組織は倚くなっおきたが、レビュヌの蚭蚈を意識しおいる組織はただ少ない • チェックリストはレビュヌ蚭蚈のガむド、もしくは参照モデルである • レビュヌはテストよりもピンポむントで探玢的である © NISHI, Yasuharup.59
レビュヌ芳点によるレビュヌケヌスの蚭蚈 • レビュヌ芳点を明瀺しおレビュヌケヌスの蚭蚈を行う必芁がある – レビュヌ芳点は、個々のレビュヌケヌスの意図を瀺しおいる • レビュヌ芳点は、レビュアヌの持぀技術力を瀺しおいる – レビュヌ芳点を蓄積しおいない人や組織がレビュヌするず、 誀字脱字チェックなどの重箱の隅レビュヌや、指差し確認レビュヌになる – レビュヌ芳点の䞍明なレビュヌは、意図の分からないレビュヌになるため、 埀々にしお時間がかかる割に意味の無いレビュヌになる • シンプルなレビュヌであれば、レビュヌ芳点だけでレビュヌケヌスになるかもしれない – レビュヌ芳点をきちんず列挙したりモデリングするこずが、モダンなレビュヌでは必須である • ダメなレビュヌチェックリストはレビュヌ芳点が䞍明だったり偏っおいるこずが倚い • レビュヌ芳点の粒床や関係を適切に把握しレビュヌ芳点を構造化/モデリングすべきである © NISHI, Yasuharup.60
レビュヌ芳点によるレビュヌアヌキテクチャの蚭蚈 • どのようなタむプやレベルのレビュヌを行うこずによっお、 どんな品質をどう保蚌するのかどんなバグを怜出するのか、 の党䜓像を描く掻動をレビュヌアヌキテクチャず呌ぶ – マスタヌレビュヌプランやレビュヌ戊略ず呌んでもよい – 個々のレビュヌのアクティビティ≒レビュヌ䌚議をレビュヌコンテナず呌ぶ • 䟋 ○○サブシステムに察する性胜レビュヌ、○○サブシステムレビュヌ、性胜レビュヌ • それぞれのレビュヌアクティビティでどのレビュヌ芳点を分担するのか、を明瀺する – レビュヌコンテナ間の順序関係や䟝存関係を明瀺しお、レビュヌの党䜓像を描き把握する © NISHI, Yasuharup.61
レビュヌ芳点によるレビュヌアヌキテクチャの蚭蚈 • どのようなタむプやレベルのレビュヌを行うこずによっお、 どんな品質をどう保蚌するのかどんなバグを怜出するのか、 の党䜓像を描く掻動をレビュヌアヌキテクチャず呌ぶ – レビュヌコンテナ内のレビュヌ芳点、レビュヌコンテナで甚いる技術や必芁な技術レベル、 レビュヌコンテナの副次的圹割などをはっきりさせる • レビュヌレベルレビュヌ察象物の皮類や粒床、順序関係などによる分類 – 芁求レビュヌ、仕様レビュヌ、アヌキテクチャレビュヌ、詳现蚭蚈レビュヌ、コヌドレビュヌ、 サブシステムレビュヌ、モゞュヌルレビュヌ、掟生郚䜍レビュヌ、母䜓レビュヌなど • レビュヌタむプレビュヌの意図や芳点、技術などによる分類 – 割蟌凊理レビュヌ、りォヌクスルヌ、むンスペクション、性胜芋積もり、セキュリティ蚭定確認、圢匏怜蚌など • レビュヌサむクル類䌌のレビュヌコンテナを繰り返す際の分類 – ○○レビュヌ第2回、やり盎しレビュヌなど • レビュヌの副次的圹割は組織ごずに色々倚岐に枡る – レビュヌアヌキテクチャずテストアヌキテクチャを合わせたV&Vアヌキテクチャを甚いるず、 開発工皋の進捗に合わせおどのように品質が保蚌されおいくのかが可芖化できる • V&Vアヌキテクチャが無いず、メトリクスやプロセスで「間接保蚌」せざるを埗ず、倧味になる © NISHI, Yasuharup.62
レビュヌの副次的圹割 • 確認の圹割 – 仕様ずの䞀臎 – 暙準ずの䞀臎 – 意図した圹割顧客満足 • 指摘の圹割 – 䞍具合の指摘 – 匱点の指摘 – 蚭蚈考慮事項の指摘 – リスク評䟡・䞍具合圱響評䟡 • 蚭蚈改善の圹割 – よりよい蚭蚈の提案 – 問題解決策の提案 – 代替案・回避策の提案 • マむルストヌンの圹割 – 進捗の報告 – 工皋完了の刀定 • コミュニケヌション・合意の圹割 – 開発者同士 – 開発者ずリヌダ・マネゞャヌ – 開発チヌムずステヌクホルダヌ – 開発者ず顧客 • 教育の圹割 – 技術の䌝達 – 良い蚭蚈を芋せる – 䞍具合指摘の着県点を䌝える – トレヌドオフのバランスを䌝える • 監査の圹割 • 䜜業改善・プロセス改善の圹割 – 原因の怜蚎ず改善 – 申し送り事項簡易蚭蚈ガむドラむンの䜜 成ず呚知培底 – 次回プロゞェクトぞの改善
レビュヌ芳点によるレビュヌケヌスの蚭蚈 • レビュヌ芳点を明瀺しおレビュヌケヌスの蚭蚈を行う必芁がある – レビュヌ芳点は、個々のレビュヌケヌスの意図を瀺しおいる • レビュヌ芳点は、レビュアヌの持぀技術力を瀺しおいる – レビュヌ芳点を蓄積しおいない人や組織がレビュヌするず、 誀字脱字チェックなどの重箱の隅レビュヌや、指差し確認レビュヌになる – レビュヌ芳点の䞍明なレビュヌは、意図の分からないレビュヌになるため、 埀々にしお時間がかかる割に意味の無いレビュヌになる • シンプルなレビュヌであれば、レビュヌ芳点だけでレビュヌケヌスになるかもしれない – レビュヌ芳点をきちんず列挙したりモデリングするこずが、モダンなレビュヌでは必須である • ダメなレビュヌチェックリストはレビュヌ芳点が䞍明だったり偏っおいるこずが倚い • レビュヌ芳点の粒床や関係を適切に把握しレビュヌ芳点を構造化/モデリングすべきである © NISHI, Yasuharup.64
本日の流れ • はじめに フロントロヌディングずは䜕か • 補造業におけるフロントロヌディングの芁諊 • ゜フトりェアのフロントロヌディングが目指すべき姿 • デゞタル化による䞊流でのモデルベヌス怜蚌の考え方 • バグ分析・RCA根本原因分析からの氎平展開の考え方 • レビュヌの考え方 • たずめ フロントロヌディングずは䜕か © NISHI, Yasuharup.65
ひず昔前にWモデルずいうのが流行りたしおね  • Wモデル – 本来は、テスト芁求分析やテスト蚭蚈を前倒しするこずで、 最初から筋のよい蚭蚈でバグが少なくテストしやすい゜フトりェアを開発するこず • たずは筋のよいテスト芁求分析やテスト蚭蚈、テスト芳点を目指すこずが倧事 • 囜内できちんずWモデルを普及しようずしおいた人たちはこう蚀っおたした – しかしいく぀かの組織では、テストをCPM法にしたたた テストケヌスを曞くずいう膚倧な単玔䜜業をそのたた䞊流に前倒ししお、倱敗しおしたった • CPM法Copy&Paste&Modify法 仕様曞をコピペしおテストケヌスを増殖させる最悪のテスト蚭蚈 • いく぀かの組織では、単䟡の高い䞊流゚ンゞニアが膚倧な単玔䜜業を行うだけでなく、 仕様倉曎に䌎う远埓工数が倧量に発生し、コストや玍期がオヌバヌしおしたった • なんで倱敗したか分かりたすか © NISHI, Yasuharup.66
珟圚シフトレフトずいう単語が流行っおたしおね  • 「シフトレフト」が䜕を指すかを深く考えずに、 技術蚘事やツヌルの宣䌝文句に螊らされおいる人も少なくない – Wモデルなんお知らない – 圓然ながら補造業におけるフロントロヌディングなんお知らない • 成功するず思いたすか倱敗するず思いたすか © NISHI, Yasuharup.67
フロントロヌディングずいう単語も流行るんですかね  • 成功するず思いたすか倱敗するず思いたすか © NISHI, Yasuharup.68
たずめフロントロヌディングずは䜕か • 単なる䜜業の前倒しではない • 単にデゞタル化による䞊流でのモデルベヌス怜蚌ず バグ分析からの氎平展開だけを指しおいるわけではない • 組織的問題解決胜力を高めおいくこずである – 解決すべき時に解決すべきこずを解決すべき範囲で 必芁十分なだけ最適な方法で解決できるようになるこずである – 「技術ロゞスティクス」でもある • 考えるべき時に考えるべきこずを考えるべき範囲で 必芁十分なだけ最適な方法で考えられるようになるために、 知恵やノりハり、技術が埪環する仕組みを「技術ロゞスティクス」ず呌ぶ • ある偎面から芋たQAそのものである © NISHI, Yasuharup.69
たずめ 品質保蚌は 組織を賢くするために あらゆるこずをする 最高にやりがいのある クリ゚むティブな仕事である
1 of 70

Software Frontloading and QA

••
Download to read offline
Software

This presentation shows how to do frontloading in software development in fundamental level, also called shift-left technique or W model. The main topic is software trap analysis / software failure mode analysis, a method of root cause analysis of (part of) software FMEA, which extracts patterns of bugs.

Yasuharu Nishi
Yasuharu Nishi電気通信倧孊

Recommended

Re-collection of embedded software qa in the last decade by
Re-collection of embedded software qa in the last decadeRe-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decadeYasuharu Nishi
5.3K views•89 slides
modern software qa - draft 1 by
modern software qa - draft 1modern software qa - draft 1
modern software qa - draft 1Yasuharu Nishi
3.7K views•30 slides
LINE Developer Meetup in Tokyo #39 Presentation (modified) by
LINE Developer Meetup in Tokyo #39 Presentation (modified)LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)Yasuharu Nishi
5.3K views•90 slides
車茉゜フトりェアの品質保蚌のこれから by
車茉゜フトりェアの品質保蚌のこれから車茉゜フトりェアの品質保蚌のこれから
車茉゜フトりェアの品質保蚌のこれからYasuharu Nishi
2.7K views•26 slides
What should you shift left by
What should you shift leftWhat should you shift left
What should you shift leftYasuharu Nishi
1.8K views•27 slides
テスト芳点に基づくテスト開発方法論 VSTePの抂芁 by
テスト芳点に基づくテスト開発方法論 VSTePの抂芁テスト芳点に基づくテスト開発方法論 VSTePの抂芁
テスト芳点に基づくテスト開発方法論 VSTePの抂芁Yasuharu Nishi
9.6K views•69 slides

More Related Content

What's hot

Is No More QA Idealist Practical and Something Tasty? by
Is No More QA Idealist Practical and Something Tasty?Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?Yasuharu Nishi
1.2K views•15 slides
LINE Developer Meetup in Tokyo #39 Presentation by
LINE Developer Meetup in Tokyo #39 PresentationLINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 PresentationYasuharu Nishi
36.7K views•90 slides
What is quality engineer? Is it something tasty? by
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
4.1K views•22 slides
What is quality culture? Is it something tasty? by
What is quality culture? Is it something tasty?What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?Yasuharu Nishi
1.8K views•17 slides
DeNA QA night #2 presentation by
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentationYasuharu Nishi
17.9K views•13 slides
品質を加速させるために、テスタヌを増やす前から考えるべきQMファンネルの話3D版 by
品質を加速させるために、テスタヌを増やす前から考えるべきQMファンネルの話3D版品質を加速させるために、テスタヌを増やす前から考えるべきQMファンネルの話3D版
品質を加速させるために、テスタヌを増やす前から考えるべきQMファンネルの話3D版Yasuharu Nishi
20.2K views•17 slides

What's hot(20)

Is No More QA Idealist Practical and Something Tasty? by Yasuharu Nishi
Is No More QA Idealist Practical and Something Tasty?Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?
Yasuharu Nishi•1.2K views
LINE Developer Meetup in Tokyo #39 Presentation by Yasuharu Nishi
LINE Developer Meetup in Tokyo #39 PresentationLINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
Yasuharu Nishi•36.7K views
What is quality engineer? Is it something tasty? by 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?
Yasuharu Nishi•4.1K views
What is quality culture? Is it something tasty? by Yasuharu Nishi
What is quality culture? Is it something tasty?What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?
Yasuharu Nishi•1.8K views
DeNA QA night #2 presentation by Yasuharu Nishi
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentation
Yasuharu Nishi•17.9K views
品質を加速させるために、テスタヌを増やす前から考えるべきQMファンネルの話3D版 by Yasuharu Nishi
品質を加速させるために、テスタヌを増やす前から考えるべきQMファンネルの話3D版品質を加速させるために、テスタヌを増やす前から考えるべきQMファンネルの話3D版
品質を加速させるために、テスタヌを増やす前から考えるべきQMファンネルの話3D版
Yasuharu Nishi•20.2K views
Demystifying quality management for large scale manufacturing in modern context by Yasuharu Nishi
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•4.1K views
゜フトりェアの品質保蚌の基瀎ずこれから by Yasuharu Nishi
゜フトりェアの品質保蚌の基瀎ずこれから゜フトりェアの品質保蚌の基瀎ずこれから
゜フトりェアの品質保蚌の基瀎ずこれから
Yasuharu Nishi•21.9K views
Tomorrow's software testing for embedded systems 明日にでも蚪れおしたう組蟌みシステムのテストの姿 by Yasuharu Nishi
Tomorrow's software testing for embedded systems 明日にでも蚪れおしたう組蟌みシステムのテストの姿Tomorrow's software testing for embedded systems 明日にでも蚪れおしたう組蟌みシステムのテストの姿
Tomorrow's software testing for embedded systems 明日にでも蚪れおしたう組蟌みシステムのテストの姿
Yasuharu Nishi•3.5K views
日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう by Yasuharu Nishi
日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう
日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう
Yasuharu Nishi•5.7K views
゜フトハりスの品質保蚌のり゜ホント by Yasuharu Nishi
゜フトハりスの品質保蚌のり゜ホント゜フトハりスの品質保蚌のり゜ホント
゜フトハりスの品質保蚌のり゜ホント
Yasuharu Nishi•5.8K views
ちょっず明日のテストの話をしよう by Yasuharu Nishi
ちょっず明日のテストの話をしようちょっず明日のテストの話をしよう
ちょっず明日のテストの話をしよう
Yasuharu Nishi•7.6K views
Agile Quality アゞャむル品質パタヌン (QA2AQ) by Hironori Washizaki
Agile Quality アゞャむル品質パタヌン (QA2AQ)Agile Quality アゞャむル品質パタヌン (QA2AQ)
Agile Quality アゞャむル品質パタヌン (QA2AQ)
Hironori Washizaki•6.5K views
同倀分割っおなんだろう by Yasuharu Nishi
同倀分割っおなんだろう同倀分割っおなんだろう
同倀分割っおなんだろう
Yasuharu Nishi•3.3K views
Paradigm shifts in QA for AI products by Yasuharu Nishi
Paradigm shifts in QA for AI productsParadigm shifts in QA for AI products
Paradigm shifts in QA for AI products
Yasuharu Nishi•599 views
「PdMず考えるQAずプロダクトマネジメント」 by 倧貎 蜂須賀
「PdMず考えるQAずプロダクトマネジメント」「PdMず考えるQAずプロダクトマネジメント」
「PdMず考えるQAずプロダクトマネジメント」
倧貎 蜂須賀•2.2K views
組織にテストを曞く文化を根付かせる戊略ず戊術 by Takuto Wada
組織にテストを曞く文化を根付かせる戊略ず戊術組織にテストを曞く文化を根付かせる戊略ず戊術
組織にテストを曞く文化を根付かせる戊略ず戊術
Takuto Wada•76.4K views
60分お゙わかった気になるISO29119 #wacate by Kinji Akemine
60分お゙わかった気になるISO29119 #wacate60分お゙わかった気になるISO29119 #wacate
60分お゙わかった気になるISO29119 #wacate
Kinji Akemine•19.5K views
あじゃいる時代の品質保蚌　DevSQAの提案 by Hiroaki Matsunaga
あじゃいる時代の品質保蚌　DevSQAの提案あじゃいる時代の品質保蚌　DevSQAの提案
あじゃいる時代の品質保蚌　DevSQAの提案
Hiroaki Matsunaga•10.5K views
レビュヌ目的・芳点蚭定の効果ず課題 by Adachi Kenji
レビュヌ目的・芳点蚭定の効果ず課題レビュヌ目的・芳点蚭定の効果ず課題
レビュヌ目的・芳点蚭定の効果ず課題
Adachi Kenji•9.4K views

Similar to Software Frontloading and QA

PBL as a Service by
PBL as a ServicePBL as a Service
PBL as a ServiceHiroshi Igaki
1.8K views•46 slides
DXの掚進においお䌁業内に求められる人材やデゞタル人材の育お方 by
DXの掚進においお䌁業内に求められる人材やデゞタル人材の育お方DXの掚進においお䌁業内に求められる人材やデゞタル人材の育お方
DXの掚進においお䌁業内に求められる人材やデゞタル人材の育お方Hironori Washizaki
1.6K views•22 slides
【16-E-4】残業れロで開発スピヌドが10倍にもう元の開発䜓制には戻れないデン゜ヌ流のアゞャむル開発 by
【16-E-4】残業れロで開発スピヌドが10倍にもう元の開発䜓制には戻れないデン゜ヌ流のアゞャむル開発【16-E-4】残業れロで開発スピヌドが10倍にもう元の開発䜓制には戻れないデン゜ヌ流のアゞャむル開発
【16-E-4】残業れロで開発スピヌドが10倍にもう元の開発䜓制には戻れないデン゜ヌ流のアゞャむル開発Developers Summit
41.5K views•39 slides
Low-Codeプログラミングシステム Node-REDずその応甚 by
Low-Codeプログラミングシステム Node-REDずその応甚Low-Codeプログラミングシステム Node-REDずその応甚
Low-Codeプログラミングシステム Node-REDずその応甚HiroyasuNishiyama1
121 views•29 slides
LexuesAcademy-党䜓たずめ by
LexuesAcademy-党䜓たずめLexuesAcademy-党䜓たずめ
LexuesAcademy-党䜓たずめShin Sekaryo
743 views•96 slides
倉化の時代における開発者のスキル資産圢成に぀いお by
倉化の時代における開発者のスキル資産圢成に぀いお倉化の時代における開発者のスキル資産圢成に぀いお
倉化の時代における開発者のスキル資産圢成に぀いおKen Azuma
1.2K views•103 slides

Similar to Software Frontloading and QA(20)

PBL as a Service by Hiroshi Igaki
PBL as a ServicePBL as a Service
PBL as a Service
Hiroshi Igaki•1.8K views
DXの掚進においお䌁業内に求められる人材やデゞタル人材の育お方 by Hironori Washizaki
DXの掚進においお䌁業内に求められる人材やデゞタル人材の育お方DXの掚進においお䌁業内に求められる人材やデゞタル人材の育お方
DXの掚進においお䌁業内に求められる人材やデゞタル人材の育お方
Hironori Washizaki•1.6K views
【16-E-4】残業れロで開発スピヌドが10倍にもう元の開発䜓制には戻れないデン゜ヌ流のアゞャむル開発 by Developers Summit
【16-E-4】残業れロで開発スピヌドが10倍にもう元の開発䜓制には戻れないデン゜ヌ流のアゞャむル開発【16-E-4】残業れロで開発スピヌドが10倍にもう元の開発䜓制には戻れないデン゜ヌ流のアゞャむル開発
【16-E-4】残業れロで開発スピヌドが10倍にもう元の開発䜓制には戻れないデン゜ヌ流のアゞャむル開発
Developers Summit•41.5K views
Low-Codeプログラミングシステム Node-REDずその応甚 by HiroyasuNishiyama1
Low-Codeプログラミングシステム Node-REDずその応甚Low-Codeプログラミングシステム Node-REDずその応甚
Low-Codeプログラミングシステム Node-REDずその応甚
HiroyasuNishiyama1•121 views
LexuesAcademy-党䜓たずめ by Shin Sekaryo
LexuesAcademy-党䜓たずめLexuesAcademy-党䜓たずめ
LexuesAcademy-党䜓たずめ
Shin Sekaryo•743 views
倉化の時代における開発者のスキル資産圢成に぀いお by Ken Azuma
倉化の時代における開発者のスキル資産圢成に぀いお倉化の時代における開発者のスキル資産圢成に぀いお
倉化の時代における開発者のスキル資産圢成に぀いお
Ken Azuma•1.2K views
20130528 pasonatech by むンフラゞスティックス・ゞャパン株匏䌚瀟
20130528 pasonatech20130528 pasonatech
20130528 pasonatech
むンフラゞスティックス・ゞャパン株匏䌚瀟•771 views
脆匱性スキャナVulsの玹介ずMackerelメタデヌタず連携した脆匱性管理 by Takayuki Ushida
脆匱性スキャナVulsの玹介ずMackerelメタデヌタず連携した脆匱性管理脆匱性スキャナVulsの玹介ずMackerelメタデヌタず連携した脆匱性管理
脆匱性スキャナVulsの玹介ずMackerelメタデヌタず連携した脆匱性管理
Takayuki Ushida•5.2K views
新しい゜フトりェア゚ンゞニアリングのためのパタヌンランゲヌゞに向けお by Hironori Washizaki
新しい゜フトりェア゚ンゞニアリングのためのパタヌンランゲヌゞに向けお新しい゜フトりェア゚ンゞニアリングのためのパタヌンランゲヌゞに向けお
新しい゜フトりェア゚ンゞニアリングのためのパタヌンランゲヌゞに向けお
Hironori Washizaki•811 views
チケットの利甚による経隓を掻かした開発の可胜性 by Makoto SAKAI
チケットの利甚による経隓を掻かした開発の可胜性 チケットの利甚による経隓を掻かした開発の可胜性
チケットの利甚による経隓を掻かした開発の可胜性
Makoto SAKAI•6.7K views
AI/ML開発・運甚ワヌクフロヌ怜蚎案日本゜フトりェア科孊䌚 機械孊習工孊研究䌚 本番適甚のためのむンフラず運甚WG䞻催 蚎論䌚 by NTT DATA Technology & Innovation
AI/ML開発・運甚ワヌクフロヌ怜蚎案日本゜フトりェア科孊䌚 機械孊習工孊研究䌚 本番適甚のためのむンフラず運甚WG䞻催 蚎論䌚AI/ML開発・運甚ワヌクフロヌ怜蚎案日本゜フトりェア科孊䌚 機械孊習工孊研究䌚 本番適甚のためのむンフラず運甚WG䞻催 蚎論䌚
AI/ML開発・運甚ワヌクフロヌ怜蚎案日本゜フトりェア科孊䌚 機械孊習工孊研究䌚 本番適甚のためのむンフラず運甚WG䞻催 蚎論䌚
NTT DATA Technology & Innovation•620 views
【16-D-1】UI のこれたでの10幎ずこれから by Ken Azuma
【16-D-1】UI のこれたでの10幎ずこれから【16-D-1】UI のこれたでの10幎ずこれから
【16-D-1】UI のこれたでの10幎ずこれから
Ken Azuma•6.5K views
楜倩の䞭のわたしず勉匷䌚 by Rakuten Group, Inc.
楜倩の䞭のわたしず勉匷䌚楜倩の䞭のわたしず勉匷䌚
楜倩の䞭のわたしず勉匷䌚
Rakuten Group, Inc.•3K views
地域コニュニティずオヌプンデヌタ by Hiroshi Omata
地域コニュニティずオヌプンデヌタ地域コニュニティずオヌプンデヌタ
地域コニュニティずオヌプンデヌタ
Hiroshi Omata•896 views
DevSumi 関西 2013 #kansumiC4 なぜデバむス向けアプリ開発が 倱敗するのか by むンフラゞスティックス・ゞャパン株匏䌚瀟
DevSumi 関西 2013 #kansumiC4 なぜデバむス向けアプリ開発が 倱敗するのかDevSumi 関西 2013 #kansumiC4 なぜデバむス向けアプリ開発が 倱敗するのか
DevSumi 関西 2013 #kansumiC4 なぜデバむス向けアプリ開発が 倱敗するのか
むンフラゞスティックス・ゞャパン株匏䌚瀟•1.6K views
䌊久矎様 アゞャむルゞャパン2010プレれン資料(4 9) by Akiko Kosaka
䌊久矎様 アゞャむルゞャパン2010プレれン資料(4 9)䌊久矎様 アゞャむルゞャパン2010プレれン資料(4 9)
䌊久矎様 アゞャむルゞャパン2010プレれン資料(4 9)
Akiko Kosaka•1.2K views
[db tech showcase Tokyo 2018]　#dbts2018 #A11 『システム開発によろこびず驚きの連鎖を』 by Insight Technology, Inc.
[db tech showcase Tokyo 2018]　#dbts2018 #A11 『システム開発によろこびず驚きの連鎖を』[db tech showcase Tokyo 2018]　#dbts2018 #A11 『システム開発によろこびず驚きの連鎖を』
[db tech showcase Tokyo 2018]　#dbts2018 #A11 『システム開発によろこびず驚きの連鎖を』
Insight Technology, Inc.•437 views
Kspin20121201 kobayashi by Osamu Kobayashi
Kspin20121201 kobayashiKspin20121201 kobayashi
Kspin20121201 kobayashi
Osamu Kobayashi•1.1K views
Webシステムプログラミング抂芁20150630 by 矩広 河野
Webシステムプログラミング抂芁20150630Webシステムプログラミング抂芁20150630
Webシステムプログラミング抂芁20150630
矩広 河野•366 views
758 dev meijo_unv-prof_suzuki_20200217 by ryohrd
758 dev meijo_unv-prof_suzuki_20200217758 dev meijo_unv-prof_suzuki_20200217
758 dev meijo_unv-prof_suzuki_20200217
ryohrd•59 views

More from Yasuharu Nishi

CommentScreeen is good by
CommentScreeen is goodCommentScreeen is good
CommentScreeen is goodYasuharu Nishi
298 views•7 slides
Demystifying quality management for large scale manufacturing in modern context by
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 contextYasuharu Nishi
1.1K views•28 slides
Teaser - Re-collection of embedded software QA in the last decade by
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 decadeYasuharu Nishi
733 views•13 slides
Tomorrow's software testing for embedded systems by
Tomorrow's software testing for embedded systemsTomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systemsYasuharu Nishi
2.7K views•22 slides
QA4AI JaSST Tokyo 2019 by
QA4AI JaSST Tokyo 2019QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019Yasuharu Nishi
7K views•33 slides
LINE Developer Meetup in Tokyo #39 Trailer by
LINE Developer Meetup in Tokyo #39 TrailerLINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 TrailerYasuharu Nishi
1.3K views•10 slides

More from Yasuharu Nishi(8)

CommentScreeen is good by Yasuharu Nishi
CommentScreeen is goodCommentScreeen is good
CommentScreeen is good
Yasuharu Nishi•298 views
Demystifying quality management for large scale manufacturing in modern context by Yasuharu Nishi
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•1.1K views
Teaser - Re-collection of embedded software QA in the last decade by Yasuharu Nishi
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•733 views
Tomorrow's software testing for embedded systems by Yasuharu Nishi
Tomorrow's software testing for embedded systemsTomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systems
Yasuharu Nishi•2.7K views
QA4AI JaSST Tokyo 2019 by Yasuharu Nishi
QA4AI JaSST Tokyo 2019QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019
Yasuharu Nishi•7K views
LINE Developer Meetup in Tokyo #39 Trailer by Yasuharu Nishi
LINE Developer Meetup in Tokyo #39 TrailerLINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 Trailer
Yasuharu Nishi•1.3K views
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D... by Yasuharu Nishi
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D... Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D...
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D...
Yasuharu Nishi•4K views
IoT時代ず第3者怜蚌 by Yasuharu Nishi
IoT時代ず第3者怜蚌IoT時代ず第3者怜蚌
IoT時代ず第3者怜蚌
Yasuharu Nishi•1.9K views

Software Frontloading and QA