modern software qa - draft 1

イマドキのソフトウェアのQAの考え方
電気通信大学ウェブシステムデザインプログラム（WebSys）
2020/7/8（水）
電気通信大学大学院情報理工学研究科
情報学専攻経営・社会情報学プログラム
西康晴
@YasuharuNishi / Yasuharu.Nishi@uec.ac.jp

Profile
西康晴
（にしやすはる）
Yasuharu.Nishi@uec.ac.jp
@YasuharuNishi
Assistant professor:
– The University of Electro-Communications, Tokyo, Japan
Vice chair:
– Software Quality Committee of JUSE (SQiP)
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:
– Society of Embedded Software Skill Acquisition for Managers and Engineers (SESSAME)
Steering Committee Chair
– QA4AI Consortium
Advisor:
– Software Testing Automation Research group (STAR)
p.2

講義の流れ
• QAは「弱さ」を赦して開発を成功に導くロールである
– QAのミッションは「納得感の共感」を高めることである
• QAはどのように行動するロールか？
– サーバントシップ、カイゼンサイクル、ミッションシェア、アップストリーミング、見える化
• QAの戦略立案
– スコープデザイン、レジリエンスデザイン、スキームデザイン、ストーリーデザイン
© NISHI, Yasuharup.3

開発には3つのコントリビューションが必要である
• アジャイル開発でもウォーターフォール開発でも、
全てがカンペキなら開発は必ず成功するという仮説を置ける
– ただし目標が組織の技術力の範囲にある場合のみ
• 目標が組織の技術力を超えているならば、何をどうやっても失敗する
• しかし人間も組織もカンペキにはなりえない
– だからカンペキを目指したい
• 例）カンペキな仕様書は存在しないし、イマイチな設計から派生開発しなきゃいけないことも多い
• 例）ビジネス価値には興味なく、ただ発注という業務をこなせばよいという顧客側担当者は少なくない
• 例）とにかくリリースすればいいんだという姿勢のおざなりなマネジャーやエンジニアは意外にいる
• 例）品質には寄与しないのにプロセスやメトリクスを守らせる官僚的なQAは珍しくない
– カンペキではないところを支えることで開発を成功させたい
– カンペキではないながらも開発が成功しているかどうかを把握したい
• すなわち開発には3つのコントリビューションが必要になる
– カンペキを目指すよう導くコントリビューション
– カンペキでないところを探し、見つけて、支えるコントリビューション
– カンペキではないながらも開発が成功しているかどうかを把握するコントリビューション

3つのコントリビューションはどのロールが遂行するのか
• ロール（職種）とコントリビューションがカンペキに対応すれば麗しいが…
– カンペキを目指すよう導くコントリビューション
• 例）ビジネス上のカンペキはプロダクトマネジャーやプロダクトオーナー、顧客側担当者が責任を持つはず
• 例）開発上のカンペキはスクラムマスターやプロジェクトマネジャーが実行するはず
• 例）常にカンペキでいられるように開発プロセスやメトリクスが決められているはず
– カンペキでないところを探し、見つけて、支えるコントリビューション
• 例）サーバントリーダーシップを備えたスクラムマスターやプロジェクトマネジャーが実行するはず
– カンペキではないながらも開発が成功しているかどうかを把握するコントリビューション
• 例）プロダクトオーナーはスクラムチームの日々の仕事ぶりから把握できているはず
• 例）顧客側担当者はプロジェクトマネジャーとの適切なコミュニケーションにより把握できているはず
• 例）スクラムマスターやプロジェクトマネジャーは当然きちんと把握できてるはず
• 現実は、開発はカンペキにはなりえないし、
職種とロールの対応もカンペキには対応していない
– 誰がそれを支える？
– プロダクトマネージャー／オーナー、顧客側担当者、スクラムマスター、プロジェクトマネージャー
「ではない」職種がそのコントリビューションを引き受けられるようにしておく方がよい

QAはどんなロール？
• ひたすらテストするロール？
• プロセスを定義しメトリクスを測定することがロール？
• 開発はカンペキなのでそんなロールは必要ない？

QAは「弱さ」を赦して開発を成功に導くロールである
• カンペキでないところを見つけて支えることと、
カンペキではないながらも成功しているかどうか把握することが
QAのロールである
– カンペキでないところを「弱さ」と呼ぶ
• 例）不完全な仕様書、イマイチな設計、こなし仕事の顧客側担当者、官僚的なQA
• 生来の弱さももちろんあるが、「弱くなりやすい点（spoilable point）」の方が問題となる
– ロールやチーム、組織、ドメイン、プロダクトは、固有のspoilable pointを持っていることが多い
» 個人の能力不足ではない
• 人間も組織もそもそもカンペキではない存在なのだから、弱さを否定してはならない
– QAは「弱さ」を感知してサポートするロールである
• ビジネス上のカンペキについて、
プロダクトマネジャーやプロダクトオーナー、顧客側担当者の弱さを感知し、サポートする
• 開発上の弱さを感知し、乗り越えたり改善できるようにサポートする
– だからQAはサーバントでないといけない
• 開発プロセスやメトリクスの弱さを感知し、弱みが出ないよう運用したり弱みがなくなるよう改善する
– QAは「弱さ」がありながらも開発が成功しているかどうかを把握するロールである
• プロダクトは「欲しいもの」に向かっているか、なっているか、これからもそうあり続けられるか
• 組織やチームは「つくっていて楽しい」「つくってよかった」になっているか
• QA自身が皆から「いてもらってよかった」「そういう仕事っぷりでよかった」と思ってもらえる

「納得感の共感」が低いところに弱さは潜む
• ソフトウェアは複数の人間が思考してつくるものである
– だから複数の人間による思考がカンペキなら開発は必ず成功するという仮説になる
• そもそもビジネスだってハードウェアだって、キーになるのは複数の人間の思考である
• しかし思考にも協力にも弱さがある
– 人間は思考が不完全だと「納得感」を持たないという性質がある
• ここでの「納得感」は表面的な理解でなく、深い理解、いわゆる「腹落ち」を意味している
• 思考が不完全なのに納得感を持たないメンバには、
そこからのとてもとても基本的なエンジニアとしてのトレーニングが必要となる
– 軽作業派遣的な“単純労働者（ ≠ エンジニア）”を寄せ集めて開発するのは時代遅れも甚だしい
– 他の人の思考が不完全だと自分の思考も不完全になる
• 他の人が「納得感」を持っていると自分が感じる必要があるし、
自分が「納得感」を持っていることを他人にも感じてもらう必要がある
– これを「納得感」の「共感」と呼ぶ
– すなわち開発の弱みは「納得感の共感」が低いところに潜んでいる
• 同様に、QAは開発が成功しているかどうかを把握する際にも、「納得感の共感」が必要になる

QAのミッションは「納得感の共感」を高めることである
• QAは、組織やチーム、エンジニア、ビジネスや顧客など
あらゆるところで起こりうる「納得感の共感」が低いことを感知し、
乗り越えたり改善するようサポートするロールである
– 「納得感の共感が低いところ」は色々なところにあるだけでなく、
乗り越えたり改善すると変化・移動することが多いので、
常に追い回して乗り越えてカイゼンし続ける必要がある
• 「納得感の共感が低いところ」は消えないので自分たちの成長に不安を持つこともあるが、
全体としてはスパイラルアップしているので自信を持ってよいだろう
– 追い回し続けていると、「納得感の共感が低いところ」の変化・移動のありさまに気付き、
それは全体の構造に起因するものだと分かるので、乗り越えたり改善し続けるとともに、
ある時期にイノベーションが必要だと気づき実行できるようになる
• 組織構造の変革のようなマネジメント的なイノベーションもあれば、
アーキテクチャの刷新のような技術的なイノベーションもある
• QAは、自分たちが開発が成功しているかどうかを把握する際に、
自分たち自身の「納得感の共感」を高めるロールである
– だからQAには戦略やデザイン、技法、説明可能性や透明性、正直さや率直さ、
「欲しいもの」「（つくって）よかった」「（つくっていて）楽しい」などが何かを明らかにすること、
などが必要になる

講義の流れ

QAはどのように行動するロールか？
• 「納得感の共感」が低いことを感知し、
乗り越えたり改善するようサポートするために：
– 「納得感の共感」が低いところを教えてもらう
• サーバントシップ
– 明日は今日よりも納得感の共感を高めてもらう
• カイゼンサイクル
– みんなで納得感の共感を高め合ってもらう
• ミッションシェア
– 納得感が上げられるよう思考の質を上げてもらう
• アップストリーミング
– 共感できるよう納得感を伝達する質を上げてもらう
• 見える化
• 自分たちが開発が成功しているかどうかを把握するために：
– QAの戦略を立てる必要がある

サーバントシップ
• 「納得感の共感」が低いところを教えてもらう
– リーダーはサーバント・リーダーシップを体現せねばならない、という考え方が普通になってきた
• 「リーダーである人は、まず相手に奉仕し、その後相手を導くものである」というリーダーシップ哲学
– 日本サーバント・リーダーシップ協会：https://www.servantleader.jp/
– 10の属性：傾聴、共感、癒やし、気づき、説得、概念化、先見力、執事役、人々の成長、コミュニティづくり
• 反対のリーダーシップは「コマンド＆コントロール」型や「マイクロマネジメント」型
– リーダーは必ずしも常に完全なサーバントなわけではない
• そもそも組織の指揮命令系統の上位リーダーがサーバントでないとそのリーダーにしわ寄せが来る
• 「エラい人」や「指示を出す人」がリーダーだという誤解の文化にいる・そう育ってきた
• 達成すべき仕事が無理筋なのでサーバントになると苦情が殺到してしまう
• 面倒くさいサーバントになるよりも、丸投げして叱責して責任回避する方がある意味ラクチン
• サーバントなリーダーは忙しいので手が回らないところが必ずある
– QAという職名はコマンド＆コントロールのイメージがある
• 品質基準に達しないと非難したり叱責したり、リリースを許さないというイメージ
• 開発プロセスという名のマニュアルやルールを強制してくるイメージ
• でもQAのどんな専門書を読んでも「コマンド＆コントロールにしろ」なんて書いてない…
– ダメな組織ではリーダーもQAもサーバントではないので、納得感の共感の低さが隠れてしまう
• 品質が低いのに開発現場がQAを全く信頼せず忌み嫌うという乖離の構造は多くの組織に内在する

QAはサーバントシップを持たなくてはならない
• QAが行うべき仕事にはサーバントシップが必要である
– QAは直接品質を上げられるわけではない
• しかも品質は、関わる全員が参画しないと上げられない
– QAは微に入り細に入り技術的な問題点を言えるわけではない
• 開発技術はやっぱり開発者の方が高いし、人数比率もQAの方がずっと少ないことが多い
– 納得感が低いとか、納得感が共感できていない、というのは言い出しにくい
• 自分たちの弱さを呈示するのはなかなかしんどい
– 自分の目先の仕事ではなく、お客様や仲間、将来の自分たちのことを考えてもらわねばならない
• もしかしたら人事評価基準と食い違うかもしれない
– しかもずっと「納得感の共感が低いところ」を教え続けてもらわなくてはならない
• たった1回だけなら強制すれば済むかもしれないけど、継続しないし、その1回だっておざなりになる
© NISHI, Yasuharu
QAがサーバントに行動することで、
納得感の共感が低いところを的確に把握するとともに、
リーダーのサーバントシップが足りないところを補完していく
p.13

カイゼンサイクル
• 人間や組織は、いきなり腕は上がらないし賢くもならない
– 明日は今日よりも納得感の共感を高める、というカイゼンのサイクルをずっと回し続ける必要がある
• カイゼンサイクルはあらゆるQAやマネジメントにおいて普遍的な考え方である
• VUCAと言われる変化の激しい時代では、カイゼンサイクルは変化の習慣づけとしても機能する
• カイゼンのサイクルは色々提案されているが、大事なのは回し続けること
– 宗教論争だったりするので違いを詳しく考えるのは勧めない
• 行動に着目したサイクルタイプ： PDCA/CAPD、OODA、LAMDA、経験学習モデル
• 情報に着目したサイクルタイプ： KPT、YWT、4行日記
• サイクルと言わない場合もある：ムダトリ、TOC
– どのタイプのサイクルでも停滞することがあるので、大事なのは現場が回しやすいことと、
停滞したらまた加速できるよう「カイゼンサイクルのカイゼンサイクル」を回すこと
• 「標準化」は属人化を排除するためのマニュアルづくりではなく、
カイゼンサイクルを後戻りさせないためのベストプラクティスの共有である
• 自律と人間性尊重が重要となる
– カイゼンサイクルは楽しく回さないと継続しない
– 回し慣れてくると、回しやすいようにサイクルのタイプやサイズを自分たちでカイゼンするようになる
– ムダを取るというのは、人間に人間らしい仕事をしてもらうことだと捉えなくてはならない
• 生産性向上やコストパフォーマンスという「なんだかよく分からないもの」を上げると捉えると、
必要なことを取り除いてしまって仕事の質が低下したり、精神的に追い込んだりしてしまうので厳禁である

ミッションシェア
• みんなで納得感の共感を高め合ってもらう
– 全員参加
• 品質は、QAやテストエンジニアが保証するものではなく、全員で保証し全員で高めるものである
– QAがサーバントに全員に納得感を共感してもらうことで、「高い品質のものをお客様のもとにお届けする」と
いうミッションを組織におけるそれぞれの役割や規模などに応じて全員でシェアする必要がある
• 組織には様々な対立が起こってしまうので、
QAがサーバントに解きほぐし問題解決や品質向上に組織全体を集中させる
– QAは「あなた方vsわたし達」から「問題vs我々」に構図を変える役割である
– 組織内外のあらゆるネットワークの納得感の共感を隅から隅まで高めあう
• 顧客と開発組織とQAのネットワーク：スリーアミーゴスモデル
– 品質を判断するのは顧客なので、顧客のビジネスへの納得感を顧客自身が共感できるようQAがサポートしたり
開発組織がその納得感を共感できるようQAがサポートすれば、開発は成功に近づいていく
– 開発を進めるのは開発組織なので（上と同様）
– QAの考え方や戦略、内容、技術などについて、顧客と開発組織に納得感を共感してもらう必要がある
• バリューチェーンと組織階層：後工程はお客様（インターナルカスタマー）コンセプト
– 後工程や下位階層が納得感を共感でき仕事しやすいように、QAは当該工程・階層をサポートしカイゼンしてもらう
– 仲間をつくってもらい、励まし合ったり癒やしあったり助け合ったりしてもらう
• 小集団活動・モブカイゼン：一人でカイゼンするだけでなくチームでカイゼンするようにサポートする
• 心理的安全を確保する：「言い方に気をつける」ではないし「ヌルい職場」でもない
– 相手に敬意を払い受け入れ、相手の意図や考え方をポジティブに理解しようとし、気軽に一緒に試してみる

アップストリーミング
• 納得感が上げられるよう思考の質を上げてもらう
– ソフトウェア開発は人間の思考によって作られるし、組織も人間の思考によって動くので、
思考の質が低いと納得感を得られる開発がしにくく共感もしづらい
• 思考の質が低いのに定量化して数値で示しても納得感は得られないし共感もされない
– 「生産性の向上」ってなんですか？
– 思考の質を上げる方法の一つは、アップストリーミングである
• いまやっていることは目的にかなっているか、いま目的としていることはより大きな目的にかなっているか、
いまやっていることは原理的に適切か、他でうまくいったことを抽象化していまやっていることに応用しよう、など
• 後から行き当たりばったりに行動するよりも、事前に適切なタイミングで行動した方がよい
• 品質管理では様々なアップストリーミングが有効だと言われている
– 目的指向、「なぜ？」・なぜなぜ分析、5ゲン主義の2つのゲン（原理原則）、方針展開（の現場側からの戻し）、
品質の作り込み、源流管理、アンドン、横展開・水平展開（ベストプラクティスのパターン化）
– アップストリーミングをするためには、いまやっていることをきちんと納得しないといけない
• 「いまやっていること」は事実や観察に基づくものか、それとも先入観の混ざった思い込みか、を区別する
– 5ゲン主義の3つのゲン（現場現物現実）、データに基づく管理
» ソフトウェア開発は定量化しにくいので安易に数値化することは厳に慎まないといけない
– アップストリーミングは犯人捜しでも責任回避でもない
• 不具合を分析するのはアップストリーミングによる横展開で未然防止することであり、
犯人を捜して責任を追及することでもなければ、自分に責任が無いように言い飾ることでもない

見える化
• 共感できるよう納得感を伝達する質を上げてもらう
– 見える化は、納得感を共感しやすくし、カイゼンにつなげていくために行う
• まず正直に率直に事実や観察を描写し、丁寧にアップストリーミングしていく
• その過程で弱さが見つかっても決して責めたりなじったりしてはいけない
– 一つ一つのロジックに納得感を共感できるような「ストーリー」を見えるようにすることが重要である
• メトリクスは必ずGQM（ゴール・クエスチョン・メトリクス）とその間を明らかにすることが必要である
– 例）こういう組織がこういう開発をしているので、
こういうメカニズムでこのようなトラブルが発生する可能性があり、
その兆候はこういうところに現れるので、こういうメトリクスを測ることでトラブルの兆候を掴もうとしてます
– とにかく数値やグラフにすることが見える化の目的になってはいけない
• 測りやすい数値を測ったり、測りやすい数値に効果や原因を落とし込むのは悪手である
– テスト自動化を導入する最も容易な説得材料はコストダウンだと思う人・組織は多いが、
実際はコストは下がらないので導入はできても中長期的には定着しない
• 定量化すると説得しやすいという理屈は、納得感を共感できるストーリーをつくろうとしないことが原因なので、
数値目標を見せて同意してもらったように思えても、早晩悪影響で苦しむこととなる
– ソフトウェア開発の「生産性」を測れというエラい人は、手に入った生産性データをロクなことに使わないものだ
– 「見えないもの」をどう「見える」ようにするかを喧々諤々議論することが大事である
• 見えないものを無理に数値化・文書化するよりも、モブで直接伝えていった方が早く正確で本質的だったりする
– アジャイル開発の「ムダな文書をつくらない」は「あらゆる文書をつくらない」「必要な文書をつくらない」ではなく
「伝わらない文書をつくらない」「意味のない文書を作らない」である

講義の流れ

QAの戦略立案
• 自分たちが開発が成功しているかどうかを把握するために、
QAの戦略立案を行う必要がある
– スコープデザイン
• 目配りのデザイン
– レジリエンスデザイン
• 赦しのデザイン
– スキームデザイン
• 寄り添いのデザイン
– ストーリーデザイン
• 取り組みのデザイン

スコープデザイン～目配りのデザイン
• どこまでQAが目配りをしておけばよいのか、をデザインする
– 組織におけるレイヤと（バリュー）チェーンを明らかにし、QAの組織スコープを定める
• 経営レイヤ、事業レイヤ、組織レイヤ、サービスレイヤ、プロダクトレイヤ、ビルド／コードレイヤ、…
• エンドユーザ、顧客内バリューチェーン、顧客側担当者、自社営業、…、開発、…
– バリューチェーンだけでなく、サプライチェーンや派生チェーンもある
– その組織における「品質」とは何か、の裏返しになる
• 「品質とは何か」は深遠な問いであり、決まった答えはない
– 経営の質、事業の質、製品やサービス系列（プロダクトライン）の質、（担当の）サービスの質、
サービスを支えるプロダクト（ソフトウェア）の質、コードの質など
» 欧米（PMBOKなど）では「顧客の要求に対する合致度」のような開発の結果
» 日本（TQM）では「仕事の質，サービスの質，情報の質，工程の質，部門の質，人の質，システム（仕組み）の質，
会社の質など，これら全てを含めた『質』」だと言うエラい人もいる
• 品質をパッケージングする～ QAが品質文化や組織の価値観を創り育てる
– 「品質」を構成する多様な側面を組み合わせて自組織の価値観を形作ることで品質文化を創り育てていく
– TQMでは、価値的側面、思考・行動様式的側面、人間的側面の3つがある
» JIS Q 9005の質マネジメントの12原則：顧客価値創造、社会的価値創造、ビジョナリーリーダーシップ、
コアコンピタンスの認識、人々の参画、パートナーとの協働、全体最適、プロセスアプローチ、
事実に基づくアプローチ、組織及び個人の学習、俊敏性（アジリティ）、自律性
– 経営・管理・開発の全ての側面からの組織の成長に合わせた
長い目でのQAのスコープの変化のビジョンをデザインしなくてはならない
• 組織や事業の成長や拡大に伴って変化する「弱さ」に寄り添えるようスコープを変化させていく
– 「弊社のQAはここからここまでです」とサイロ化させ固定化させるQAがいる組織は大概品質がイマイチで、
QAが組織の成長を阻害してしまっていることが多い

レジリエンスデザイン～赦しのデザイン
• 弱さをどこまで赦せるのか、をデザインする
– Preventive（予防的）なQAとResilient（レジリエント）なQAを上手に組み合わせる
• 予防的なQA ～赦さないQA
– 不具合や障害を起こさないように予防することを主眼に置く
– 何が起こるかが予見可能な場合にとてもよく機能する
– 不具合や障害によるダメージが取り返しのつかない場合には絶対に必要となる
– よほど上手く行わないとリリーススピードが落ちる
– 形骸化したり官僚化したりしやすいが、上手にフロントローディングすると設計の質が上がる
• レジリエントなQA ～赦してすぐ直すQA
– 不具合や障害が起きることを前提として悪影響が出ないように迅速
– 何が起こるかが予見不能な場合にとてもよく機能する
– 不具合や障害によるダメージが許容可能であり、レジリエンスサイクルが早く回るのなら、実現できる
– リリーススピードを速くできる
– 「直せばいいんでしょ」と考えやすくなるため、
無秩序や混乱がどんどん大きくなって制御不能になり破綻する可能性がある
• 伝統的なQAは予防的なアプローチが主だったが、
モダンなQAはレジリエントなアプローチが強調され（すぎ）ている
– 伝統的なQAはフェーズゲートやゲートキーパーと自称することがある
– モダンなQAはフィーチャートグルやカナリアリリース、ブルーグリーンデプロイメントを使いこなす

• レジリエンスデザインでは、
予防的QAとレジリエンスQAをどう組み合わせるかをデザインする
– レジリエンスリミット（RL）を明確にし予防的QAを行う
• 開発やビジネスにはほとんどの場合、
この時点でダメージが発生すると取り返しがつかない、という点（レジリエンスリミット・RL）が存在する
– 何でもかんでもRLと考えるのではなく、開発やビジネスをもう一度見直して
本当にそれがRLなのかについて納得感を共感することが重要である
» 組織は想像以上に、面倒臭さやメンツによってRLが決まっていたりする
» キャッシュアウトのような目に見えるダメージだけでなく、
お客様からの信頼やブランド力など目に見えないダメージも考えなくてはいけない
• RLの時点は必ず予防的QAが必要となる
– RLにおけるQAをいかに迅速かつスムーズに、そして的確な品質基準を満たして通過させるかが重要となる
» RLに到達した時点で高い品質を達成していることが望ましい
» RLにおけるQAが自動化されていることが望ましい
» だからといってRLにおけるQAを儀式化させるアプローチは意味がない
• 共通のRLがあるサービスや機能、サブシステムをきちんと分割することで、
厳しいRLと相対的に厳しくないRLを組み合わせることも必要になる
– ビジネスをきちんと見直すとそのRLなのは一部だけだったりする
» 例）車載系では安全関連系と非安全関連系でRLが異なる
– 異なるRLは品質基準も異なる可能性が高い

– RL以前では、予防的QAをシフトレフトし、レジリエントQAと組み合わせる
• RLをスムーズに通過する（RLの時点で十分品質が確保されている）ように、
開発の最初期から様々な予防的QAの取り組みを行い平準化する（シフトレフトする）ことで、
開発スピードを落とさずにQAする
– ビジネスレビュー、要求レビュー、設計レビュー、コードレビュー、単体テスト、結合テスト、システムテスト…と
頻繁かつ継続的に様々なQAを有機的に行うことで、負担がかかりすぎるQAを無くす
» たまに散発的に通りいっぺんのQAをバラバラに行うと、どこかで大規模なQAが必要になったり、
不具合が大量に発生して開発がストップしたり、進捗優先の手抜きQAが発生してバグが大量に流出する
– 頻度の高い自律的なカイゼンサイクルを回すことで、ビジネスや開発の質そのものを高めていき
（フロントローディングしていき）、QAの負担そのものを根本的に減らしていく
» QAの負担の多くは、品質が向上して不具合が減ると自然に少なくなっていく
» QAの持つ「悪さの知識（どういう風につくると／仕事をすると不具合につながるか）」を開発に移転する
» 開発の初期から「後工程はお客様」を考えて「レビューアビリティ」「テスタビリティ」を高めておく
» したがってQAは開発の最初期から十二分に参画させ活動する必要がある
– RLにおけるQAを迅速に行うために自動化を開発の最初期から準備しておく
– 「RLを超えなきゃダメ」ではなく「このままだとここがこうだからRLを超えられないので一緒にカイゼンしよう」にする
• RL以前でレジリエントQAの技術や仕組み、体制を整えて運用し、
不具合を検出したら迅速に修正し再確認し開発を進められるようにする
– テスト実行の自動化やデバッグの支援、文書の最適化や自動化、不具合管理のシンプル化などを実現する
– 修正のスピードを上げるとともに開発者のストレスを無くすように取り組むと上手くいきやすい

– RLを後ろにずらせないか（シフトライト）を検討し、実現に向けて取り組みを行う
• 自分たちのスコープや技術という暗黙の制約を外すと、RLは意外に後ろにずらせたりするかもしれない
– レジリエンスなやり方について「それもアリなのか」とレイヤやチェーンの前後で納得感を共感する
» 伝統的なQAや管理職、経営陣はレジリエンスなやり方に拒否反応を示したりするので粘り強く議論する
» 規格認証がRLの場合は、審査員と（良い意味で）“闘う”覚悟が必要になる
– 予見不能性についてレイヤやチェーンの前後で納得感を共感する
» 予見できてないのにできたつもりになっている人は組織に驚くほど多い
– ダメージの低さについてレイヤやチェーンの前後で納得感を共感する
» 「契約」「プロセス」「規定」などがあるとダメージの低さを考慮できない場合が多いので粘り強く議論する
– レジリエンスサイクルを速くできるよう業務フローを見直す
» 業務全体としてレジリエンスになる方が事業全体の変化追従性が向上する、という大局観が大事になる
– レジリエンスサイクルを速くできる技術を導入する
» QAがDX、すなわちQAのパイプライン化・モデルベース化・クラウド化・インテリジェント化・AI化といった
最先端の技術に精通している必要がある
» 単にQAをレジリエントにするのではなく、業務全体のDX化を進めるという大局観が大事になる
» 何をシフトライトするのかを迅速かつ的確に判断するために、QAアーキテクチャを構築し、
いつどこでどんなQAをしているのかをきちんと整理しておく必要がある
• シフトライトは組織的な納得感の共感にも、技術の導入にも時間がかかり投資が必要で、
異なる文化の組織を巻き込まなくてはならない場合が多いので、QAがビジョンをデザインしなくてはならない
– 「世の中はDXだから」「アジャイルがブームだから」「シフトライトってのをやってみましょうよ」
といったノリのアプローチは確かに周囲を動かしやすいが、
結局のところ納得感の共感が低いので腰が据わらず、すぐに方針が戻ったりしやすいので注意が必要である

スキームデザイン
• どのくらい寄り添うのか、をデザインする
– 品質保証や品質向上には全員参加が必要であり、現実的にQAの比率を高くできる組織は多くないため、
どのようにミッションシェアを行っていくかをデザインする必要がある
• QAと開発組織のリレーションピラミッドの階層と比率を決める
– リレーションの例
» プロモーション：組織全体にQAを推進していく役割なので、自分で手を出してはいけない
» コンサルティング：開発組織に常駐せずにQAの技術移転をしたりQAの技術向上を担う
» コーチング：開発組織に時々常駐してQAの技術移転や品質文化の浸透をする
» インボルビング：開発組織の中でQAを行いながら開発組織にQAの技術移転や品質文化の浸透をする
» サービスプロバイディング：独立したQAとして開発組織からQAを受託する
» フェーズゲート：独立したQAとしてフェーズリリースやローンチの判断をする
– リレーションピラミッドの下位の階層から増やす組織が多いが、上位階層がいないと機能しない
» サービスプロバイディングは外部発注もありうるが、丸投げは社内のQAが育たないので厳に慎むべし
• QAのロールを決めてアサインする
– QA、TE、CI-SET、E2E-SETといった技術領域だけでなく、研究開発のロールもQAには必要である
» TE（Test Engineer）はテストの設計や実装、実行を担う
» SET（Software Engineer in Test）はCIや自動化の環境を構築し開発やQAにサービスとして提供する
– 組織体が異なっていても同じであっても、QAというロールによってサイロ化や対立が起きないようくれぐれも注意する
» 自分たちは同じビジネス／事業／組織／サービス・製品／チームだという強い意識を常に打ち出す
» 組織によってはQAというロール名を使わない方がよいケースもある
• QAのスキームは未来永劫同じではないので、組織の成長や品質文化の浸透、要求される品質の向上に合わせて、
リレーションをどのように変化させてQAの比率をどのように増やして／減らしていくのか、
というビジョンをデザインしなくてはならない

ストーリーデザイン
• どういうコンテキストでどこにフォーカスして何に取り組むか、をデザインする
– QAの取り組みをストーリーとしてデザインすることで、納得感を向上し共感しやすくする
• QAのそれぞれの取り組みについて、コンテキスト・フォーカス・プラクティスを明らかにしてストーリー化する
– コンテキストに合わないQA活動を行うと、一生懸命頑張ってQAをしているのに、
品質低下が起きたり、ピンボケだったり、「過剰品質」となじられたりする
– コンテキストに合わせてフォーカスを決めプラクティスに落としこむからこう品質が上がる、というストーリーになる
• コンテキストは、市場でのサービスやプロダクトの存在感やポジション、設計・ソースコードのサイズ・複雑さ、
組織能力の程度などから構成される
– 例えばプロダクトを速くリリースして市場を攻略したい時期であれば、
QAは市場の攻略や速いリリースを促進すべきであり、
じっくり検証して高い基準の信頼性を達成するフェーズゲートの役割をすべきではない
• フォーカスは、QAや開発がそのコンテキストで達成すべきことに絞る
– コンテキストとフォーカスが組織および現場の両方の問題や課題を反映し、
経営も管理も現場も納得感を共感できるようにするのは
かなりのQAの腕が必要になる
» つい一般的なコンテキストで総花的なフォーカスにしてしまうので注意すべし
• プラクティスは、フォーカスが達成できるように取り組む
– 開発やQAのプラクティスはたくさん提案されているし流行があるが、
取り組み方によって全く逆の効果を生んでしまうものもあるし、よい取り組み方は一朝一夕には実現できないので、
現場にコンテキストとフォーカスについての納得感を共感してもらい
自律的にプラクティスの取り組み方をカイゼンしてもらう必要がある
» プラクティスを導入するまでは一生懸命で後はお任せ、ではなく、プラクティスの間に何度も
「なんでこれをしてるんでしたっけ？」「これで現場はシアワセになりますかね？」と、QAがアップストリーミングをするとよい
• 個々のストーリーが集まって組織全体のストーリーになるようなビジョンのデザインをしなくてはならない

• ストーリーのテンプレートの例：AQUAフレームワーク
– Accelerating project
• コンテキスト：
– とにかく速く何度もリリースを行って市場で存在感を示したり、市場で学ぶべき時期
– プロダクトサイズは小さく、信頼性や安全性はそれほど要求されない時期
• フォーカス：
– 主要な価値やUXが損なわれないことと、開発スピードが上がること、成長できるチームになっていること、など
• プラクティスの例：
– プロダクト／プロジェクトマネジャーとの対話の開始や、チームの／との価値観の共有を目的とした朝会への参加
– 筋のよい設計でよいコードを書いているとメンバが納得感を持てるようにするペア／モブプロの促進やDR
– 頻繁なリリースをためらわず最速の開発に近づいてもらうことを促すためのKPT/PDCAやTDD、UTレベルのCI
– 市場の求める価値の理解と、市場からのフィードバックに対する反応速度の加速のためのUSMへの参加
– Qualifying value
– プロダクトのポジションやミッションが分かってきた段階で、製品の価値を最大化する
– プロダクトサイズが徐々に大きくなり、機能は増えUXを重視するが、何を目指してるのかがブレ始める時期
– 価値が向上していることや、提供価値の多様化に追いついていること、複雑さの増加に対応できていること、など
– 市場の求める価値とその変化を機能やふるまいで実現していることを実証するE2Eテスト
– 暗黙知を暗黙知のまま共有し、新しいメンバにも伝えていくためのペア／モブプロの促進やDR
– 頻発する手戻りに対してデバッグで終わらせず設計まで戻し設計の筋をよくするバグ分析とナビゲーション
– 設計の複雑さを増加させないためのデザインレベルリファクタリングの推進とテスタビリティの作り込み

– Unveiling weakness
– 多くのユーザを獲得し、市場で存在感を確立した時期に行う品質保証活動
» プロダクトサイズがかなり大きく、開発体制も大規模化し、一つのバグの影響が甚大になる時期
– 大規模化に対応できていること、不具合が出やすい仕様・設計上の弱点に気づき対処できていること、
納得感を共感させる仕組みが浸透していること、などに品質保証をフォーカスさせる
– 大規模化やSoE/SoRの融合のためのマイクロサービス化などのアーキテクチャレベルリファクタリングの推進
– 大規模化でも開発速度を保つためのE2Eテストの自動化（キーワード駆動テスト化）とフルCI
– 暗黙知の形式知化と形式知の実質化（＝反形骸化）のためのドキュメント化とレビュー
– 仕様や設計上の弱点をいぶり出し皆が弱点に気をつけられるための市場バグの根本原因分析と探索的テスト
– Accumulating knowledge
– 次世代、発展型、ファミリ的なプロダクトの開発を検討すべき／始めている時期に行う品質保証活動
– 機能の追加と、コア部分や環境の入れ替えが同時多発的に頻発し、中心メンバが入れ替わる時期
– 俯瞰し見通しよくできていること、シンプルさを保つ仕組みが保たれていること、
開発から知を獲得できていること、メンバの知が向上し循環していること、などに品質保証をフォーカスさせる
– プロダクトライン開発や環境多様化のためのコア資産の抽出やエンジン化、フレームワーク化、仮想化の推進
– 複数チームでの共有や俯瞰のためのモデル化、DSL化とレビュー
– 不具合の未然防止のための工程内バグや過去バグからの仕様・設計上の弱点の抽出とフロントローディング
– 開発全体を見通した俯瞰的なQA活動の把握のためのQAアーキテクチャの記述
– DRなどの作業埋め込み型教育、OJT、集合教育の融合

QAにはQAの腕というものがある
• QAは「開発技術が低い」からなるロールではないし、
開発技術が高ければ上手にできるロールでもない
– QAにはQAの技術領域がきちんと存在する
• 品質をパッケージングしQAのビジョンを創り組織全体を成長させる技術
• 包括的かつ俯瞰的なQAを行うためのQAアーキテクチャ構築の技術
• Spoilable pointの把握とパターン化の技術
• サーバントシップの技術
• 変化する技術・カイゼンサイクルを適切に回し続ける技術
• アップストリーミングの技術
• 適切な見える化の技術
• ミッションシェアを行い組織の隅々まで浸透させていく技術
• フォーカスに合うようにプラクティスを取り組んでもらう技術
• などなど
– QAは軽作業派遣ではなくエンジニアなので、常に技術向上が必要だし、常に技術開発に勤しまなくてはならない
• 開発技術の動向
• レビューやテストの技術
• 開発プロセスやプロセス改善の技術
• 自動化やクラウドの技術
• BI（ビジネスインテリジェンス）やデータサイエンス、統計の技術
• AIや機械学習の技術
• 規格や標準の知識、認証取得の技術
• などなど

育て合う組織になろう
腕のよい開発や顧客が腕のよいQAを育て、
腕のよいQAが腕のよい開発や顧客を育てるのが
強くあり続ける組織の姿である

modern software qa - draft 1

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to modern software qa - draft 1

Similar to modern software qa - draft 1 (20)

More from Yasuharu Nishi

More from Yasuharu Nishi (11)

modern software qa - draft 1