やまずん的QA概論_公開用

やまずん的QA概論 テストの街例大祭2024＠亀有地区センター 2024.12.28(土) Keynote やまずん Dirty Tester バキバキQA

自己紹介 ⚫ Dirty Tester/バキバキQA ⚫ バキバキQAチャンネル主 ⚫ パーフェクトQAパーフェクトスタイル ⚫ SaaS企業のQA ⚫ 職業歴 ⚫ 営業 ⚫ テストベンダー ⚫ 自社QA ⚫ MOS検定2008スペシャリストExcel ⚫ from大阪 2

本発表のゴール ⚫ QAに対するやまずんの理解を 知ってもらう 3

本発表における「テスター」とは 「テストの専門家」or「テストが好きな人」 くらいで捉えてください。 ソフトウェアのテストを担う人という意味で使っています 蔑称ではありません そして私はテスターです 4

本発表における「QA」とは 「Quality Assurance」 のこと Question Askerではないです 「品質」を「保証」することです 私はテスターですが、QAエンジニアでもあります 5

本発表のスタンス 人によって考えが違うのは正しい コンテキストが別だから結論が違うのは正しい だからといって 「人によって考えが違う」 と言語化から逃げるのは違う 「コンテキストが別だから」 と背景の相互理解から逃げるのは違う と考えている 6

本発表の注意 ⚫ 大学などの専門機関や権威のある先生から習ったわけでは ありません。 ⚫ 市井のQAとして泥臭くもがいた結果がこのスライドです ⚫ 興味があったら自分でも調べる強い気持ちを持って欲しい ⚫ あんまりまとまった発表でもないです ⚫ 素朴理論 7

今年のやました ⚫ 念願のQAエンジニアになりました ⚫ そして「QAなんもわからん会」に参加したせいで、自分の品 質に対する価値観を言語化してしまった ⚫ だいたいぜんぶnacoさんのせい ⚫ そんな中で、「きちんと品質について勉強したい」と思って 「TQC」に手を出してしまった ⚫ 半年で１０万以上本に投資した ⚫ ただ、個人的にはそれに見合うリターンがあったと思っている 8

品質に感じる闇 品質の話をすることが怖いと感じるのは私だけ？ 「お前は勉強していないから品質が理解できていない」という難しい話 「私は品質を勉強しました」から感じるマウント感 「品質管理には歴史があるから素人が語るべきではない」という風潮 「QAなんもわからん」と言わなきゃいけない同調圧力 権威があることは理解できるが、その権威のありがたみを理解していない自分 日本VS欧米という古の構造 そして欧米下げ 本をはじめ、学習コスト（金銭面）やハードルが高く感じる 9

品質に感じる闇 品質の話をすることが怖いと感じるのは私だけ？ 「お前は勉強していないから品質が理解できていない」という難しい話 こういった「怖さ」を感じたとしても 「私は品質を勉強しました」から感じるマウント感 「品質管理には歴史があるから素人が語るべきではない」という風潮 先人の人々を尊重しつつも乗り越え 「QAなんもわからん」と言わなきゃいけない同調圧力 権威があることは理解できるが、その権威のありがたみを理解していない自分 自分なりに整理するのが 日本VS欧米という古の構造 そして欧米下げ この発表の趣旨 本をはじめ、学習コスト（金銭面）やハードルが高く感じる 10

品質ってなんなの？ Part1 11

「品質とは」を考える ⚫ 品質とは何かと問われたとき、一般的には製品やサービスが本 来の目的や仕様に適合しているかどうか、顧客の期待や要求を 満たしているかどうか、さらにはその価値がどれほどの持続性 を持ち、使い手にどれだけの満足感を与えるかといった多岐に わたる要素を含む概念として説明されることが多いものの、そ 品質について 長々と講釈垂れ る人いるよねえ の内容は時代や文化、個々の価値観、さらには市場環境やビジ ネスモデルの変化によっても異なり、つまるところ「品質」と いう言葉自体が指し示す範囲が非常に広く、これを一言で説明 することは極めて難しいため、どうしても長々とした説明を 伴ってしまうものだと言えるのです。 ⚫ With ChatGPT-4o 12

「品質とは」を考える ⚫ 品質とは何かと問われたとき、一般的には製品やサービスが本 来の目的や仕様に適合しているかどうか、顧客の期待や要求を 満たしているかどうか、さらにはその価値がどれほどの持続性 を持ち、使い手にどれだけの満足感を与えるかといった多岐に ChatGPTに言わ せただけやろ わたる要素を含む概念として説明されることが多いものの、そ の内容は時代や文化、個々の価値観、さらには市場環境やビジ ネスモデルの変化によっても異なり、つまるところ「品質」と いう言葉自体が指し示す範囲が非常に広く、これを一言で説明 することは極めて難しいため、どうしても長々とした説明を 伴ってしまうものだと言えるのです。 ⚫ With ChatGPT-4o 13

「品質とは」を考える前に 「品質とは」を考える前に 「品質がどう扱われているか」を考える ⚫ 「品質保証」や「品質管理」を先に考える 品質って都合の いい言葉として 使われがちだよ ね〜 ⚫ 「何を保証したくて、何を管理したいんだろう？」 から考えるというアプローチ 14

品質管理と品質保証 品質管理と品質保証は文化的な印象があるっぽい ⚫ 品質管理と品質保証ってどう違うの？ ⚫ 品質管理っぽいってなにがありますか？ 結局同じような 難しい話してな い？ ⚫ 品質保証っぽいってどんなのがありますか？ 15

品質管理と品質保証にはいろんな受け取り方がある 品質管理と品質保証の意味について 日本(TQC)と欧米（ISO）では若干ニュアンスが異なる TQC 品質マネジメントシステム（ISO） 品質を中核とした全員参加での改善を重視する経 方針、目標、達成のためのプロセスを決める 営のアプローチ ための組織の一要素 • 品質保証…顧客が満足する製品・サービスを提供 • 品質保証…品質要求事項が満たされるという すること、あるいはそのための活動 確信を与える • 品質管理…品質保証をするための活動 • 品質管理…品質要求事項を満たすこと • 品質…「顧客に受け入れられる」ということ • 品質要求事項…品質に対して要求する事項 欧米ってくくり も雑だし ISO＝欧米って するのもどうな のかなあ • 品質…明示されている、通常暗黙のうちに了 解されている、義務として要求されている、 ニーズ又は期待 16

TQCとISOにおける品質管理と品質保証の違い ⚫ TQC ⚫ 品質保証のために品質管理を行う ⚫ 目的-手段の関係 理解するのは大 事だけど、間 違ってるなら訂 正しなよ ⚫ ISO ⚫ 品質管理を行い、その実証として品質保証を行う ⚫ 実行-確認の関係 TQCにおける品質管理は“品質”が具体的に何を指すかを探索することも含まれる ISOは”品質要求事項“を定義して、それ目指してを頑張る という理解をした 17

TQCとISOにおける品質管理と品質保証の違い TQCとISOで “品質”をどう扱うかの 意識に違いがありそうだ 18

品質をどう扱うか？でQCやQAっぽいがかわる 例えば 品質をコミットメントとして扱いたい ➢ ISO的な考え方で品質要求事項を決めてから管理や保証をしたい 例えば 品質を組織の目的として扱いたい これって合って るのかなあ？き ちんとQMSの勉 強したら考えか わるんじゃな い？ ➢ TQC的な考え方で顧客満足を目指して管理や保証したい どれが正しいってことはないよね だけど「わたしはどっち派か」によって QAやQCの責務や仕事内容は異なりそうだニャ 19

参考：JSTQBにおける品質管理と品質保証 QCは適切な品質の達成を支援する活動に焦点を当てた、プロダ クト志向の是正アプローチである。テストは品質コントロール の主要な形式であ(略)る。 QAはプロセスの実装と改善に焦点を当てた、プロセス志向の予 これ誰が言い出 したの話なんだ ろう 防的アプローチである。よいプロセスが正しく行われれば、よ いプロダクトをつくることができるという考えに基づいている。 JSTQB FLシラバス4.0 p18 20

日本における品質保証から学ぼう 21

日本における品質保証とは ⚫ 戦後、日本の産業界が欧米の品質保証の考えを（ほ んまに）魔改造して体系化したもの ⚫ 現在はTQMとして確立しているような気がする 日本における食 の魔改造と品質 の魔改造は似て いるよねえ ⚫ TQMの考え方は今でも通じるとやまずんは思ってい る というわけでこれからこの話をします 22

日本における品質保証の歴史（超概略） ⚫ 戦前は欧米流の検査検品主義、なんなら安かろう悪かろうの時代 ⚫ 統計的品質管理（SQC）の導入 ⚫ 新製品開発の品質保証 ⚫ TQMの確立 この紆余曲折の 部分を知りたい んだけど 〜紆余曲折〜（わからないだけ） ⚫ ソフトウェアの時代へ（Now） 「品質保証」の歴史はソフトウェア開発より長い ソフトウェア開発が主流じゃなかった頃から存在する だからソフトウェア開発には当てはまらないパラダイムも存在する 23

ソフトウェア開発の品質保証を考える ハードウェアの開発にあって、ソフトウェアにないもの ⚫ 量産工程がない ⚫ できばえのばらつきがない ⚫ 最終成果物に物的な実体がない ハードウェアと ソフトウェアは いろいろ特徴が 違うんだねえ ⚫ 一層成果の可視化・文書化が求められる ⚫ 自然法則を受けない ⚫ 論理的な組み合わせが爆発的に増える 新版品質保証ガイドブック p10から抜粋 24

ソフトウェアのテストの難しさ テストのやり方も変わってくる ⚫ 物質的な連続性がないので、「正しいこと」を確認でき ない ⚫ 例：1ミリ隣の鉄板の厚さは１ミリ隣と同じであることはあ ソフトウェアテ ストの話も変 わってくるよね え る程度保証できるが、ソフトウェアの場合はこういった連続 性がない ⚫ いわゆる「ソフトウェアは決めきれない」問題 ⚫ 設計工程の品質保証がキモになってくる（次のページ） 新版品質保証ガイドブック p10から抜粋 25

製品開発（品質保証）プロセスの違い 組み立て製品 ソフトウェア製品 市場調査・企画 市場調査・企画 研究開発 研究開発 プロセスがカラ フルでかわいい ねえ 製品設計 製品設計 生産準備・工程設計 機能設計 調 達 生産 販売 アフターサービス 内部設計 調 達 コーディング 物流 テスト ソフトウェア製品は、 物理的なインストールや 複製といった「生産」が 容易であるという 特徴がある そのため、「製品設計」の 品質保証が重視される 販売 新版品質保証ガイドブック p54から抜粋 回収・廃棄・再利用 アフターサービス 26

やまずんのソフトウェア品質保証観 ソフトウェアの品質保証において、 ⚫ 「QAだけがQAやってたらQAです」というのは無 理やと思ってる QAがQAしてる からQAだからも うQA！ ⚫ 「全員参加」「顧客志向」といったTQMの考えは ソフトウェア開発に活かせる だからここから品質保証の原則の話をしたい 27

日本の品質保証の原則 28

品質保証の原則 1.目的 マーケットイン 後工程はお客様 品質第一 2.手段 プロセス重視 標準化 源流管理 PDCAサイクル QCD結果に基づく管理 再発防止 重点思考 未然防止 事実に基づく管理 たくさんあるね え 潜在トラブルの顕在化 3.組織の運営 リーダーシップ 全員参加 人間性尊重 教育・訓練の重視 29 マネジメントシステムの審査・評価に携わる人のためのTQMの基本p.9より

品質保証の原則 1.目的 マーケットイン 後工程はお客様 品質第一 2.手段 プロセス重視 標準化 源流管理 PDCAサイクル QCD結果に基づく管理 再発防止 重点思考 未然防止 事実に基づく管理 まずは目的から 話すよ！ 潜在トラブルの顕在化 3.組織の運営 リーダーシップ 全員参加 人間性尊重 教育・訓練の重視 30 マネジメントシステムの審査・評価に携わる人のためのTQMの基本p.9より

マーケットイン（顧客重視） ⚫ 提供側の技術や都合（プロダクトアウト）より、顧 客のニーズが大事という考え（マーケットイン） ⚫ 「クレーム０だからOK」ではない ぼくもぬいぐる みユーザーのこ と考えてるん だ！ ⚫ 不具合の防止やコストダウンのみが目標なのも違う ⚫ 常に顧客の視点で立つことが大事という考え方 31

後工程はお客様 ⚫ 顧客と直接関係ない部門も自分を優先するのではな く、お客様の代わりに後工程をお客様と捉えること ⚫ 結果的に組織の隅々まで顧客志向が広がるという論 お客様と直接接 してなくてもい けるんだねえ 理 ⚫ トイレのスリッパを揃えることは「後工程はお客様」 らしい 32

品質第一 ⚫ いい品質であれば市場でも勝てるという考え ⚫ 顧客のニーズに合った製品を出すことは、売上増大、 原価低減、能率向上より「目的として」優先するとい う考え方 過剰品質って言 葉は誰がどんな 文脈で言ったの かなあ ⚫ これらを考えないというわけではなく、あくまで最優先に するという話 ⚫ 品質を重視することは結果的にスピードや効率も上がるみ たいな話もある 33

品質保証の原則 1.目的 マーケットイン 後工程はお客様 品質第一 2.手段 プロセス重視 標準化 源流管理 PDCAサイクル QCD結果に基づく管理 再発防止 重点思考 未然防止 事実に基づく管理 次は手段だね！ 潜在トラブルの顕在化 3.組織の運営 リーダーシップ 全員参加 人間性尊重 教育・訓練の重視 34 マネジメントシステムの審査・評価に携わる人のためのTQMの基本p.9より

プロセス重視 ⚫ 結果だけを追うのではなく結果を生み出すプロセスを管理し て、向上させようという考え方 ⚫ 「手順を決めてそれを絶対に遵守する」みたいなことではな い 僕も小魚を食べ るプロセスは大 事にしてるよ！ ⚫ ただ、そう言っている人はいることは事実 ⚫ 「結果さえ出せたらなんでもいい」ではなく、「良い結果を 起こしたしくみややり方にきちんと目を向けよう」という考 え インプット プロセス アウトプット 35

標準化 ⚫ 各々が勝手に行動するより、もっとも優れた方法を 標準として定めて、これに沿って行動するのがいい よねという考え方 白くって丸いの も標準的なかわ いいだよねえ ⚫ 標準による効率化や認知の負荷を下げることが狙い ⚫ 標準自体の改善の必要も忘れてはいけない ⚫ そもそも標準化されていないと叩き台もないって話もし ている 36

源流管理 ⚫ 仕事の流れの源流に遡って、品質を管理しようとい う考え方 ノルウェーサー モンくんも源流 管理で川を登る のかな ⚫ アジャイルでいうシフトレフトと一緒だと思う 市場調査・ 企画 開発・設計 生産 販売・提供 アフター サービス さかのぼれ、源流へ！ 37

品質保証の原則 1.目的 マーケットイン 後工程はお客様 品質第一 2.手段 プロセス重視 標準化 源流管理 PDCAサイクル QCD結果に基づく管理 再発防止 重点思考 未然防止 事実に基づく管理 まず左からね 潜在トラブルの顕在化 3.組織の運営 リーダーシップ 全員参加 人間性尊重 教育・訓練の重視 38 マネジメントシステムの審査・評価に携わる人のためのTQMの基本p.9より

PDCAのサイクル ⚫ 人間のプロセスに関する知識は常に不完全 ⚫ だから、プロセスを設定してその結果を見ながら逐次的に修正す ることが大切という考え方 ⚫ TQMでは「改善」と「管理」でアプローチを分けている 廻せ！PDCA! ⚫ 改善→目標を現在の水準より高いところにおき、それを達成するた めの活動 ⚫ 管理→目標を現在の水準におき、結果のずれを安定化させるための 活動 ⚫ 失敗が少なくなった場合には、全く新しいプロセスの導入が必要 であることを示唆している 39

再発防止 ⚫ 問題が発生した際は、現象に対する対処で満足する のではなく、プロセスに遡っての再発防止対策が必 要だという考え方 僕も宿題忘れし ないように気を つけないと ⚫ 再発防止には以下の三段階がある ⚫ 個別の再発防止 ⚫ 水平展開 ⚫ 根本原因の除去（製品やプロセスを生み出すしくみ） 40

未然防止 ⚫ トラブルが発生する前に防止しようという考え方 ⚫ 過去の失敗やトラブルを整理・一般化する ⚫ 失敗を一般化する概念として「モード」という概念 僕もお魚食べる 時に小骨抜いて るよ！ が使っているみたい 41

潜在トラブルの顕在化 ⚫ 報告されていないトラブルも積極的に探そうという考え方 ⚫ いわゆる「氷山の一角」 見えている氷山 は一部なんだ よ！ 42

品質保証の原則 1.目的 マーケットイン 後工程はお客様 品質第一 2.手段 プロセス重視 標準化 源流管理 PDCAサイクル QCD結果に基づく管理 再発防止 重点思考 未然防止 事実に基づく管理 つぎは右 潜在トラブルの顕在化 3.組織の運営 リーダーシップ 全員参加 人間性尊重 教育・訓練の重視 43 マネジメントシステムの審査・評価に携わる人のためのTQMの基本p.9より

QCD(結果)に基づく管理 ⚫ プロセスをプロセスだけで評価するのではなく、 結果に着目して評価しようよという考え方 ⚫ 活動の実践において、「高次の目的はなにか」を プロセスだけで 空中戦してる人 いるよねえ 考えて、その目的にそって適切な行動を考えよう ということ ⚫ このためには個々のプロセスだけを考えるのでは なく、組織全体で捉える必要がある 44

重点思考 ⚫ 結果に大きな影響を与えている問題から取り組もう という考え方 ⚫ TOCとかスクラムのスウォーミングも近いかもしれない 地球温暖化問題 を止めるため に、太陽の動き を止めるんだ！ ⚫ 例えば手順書の場合、すべての手順書を書くのでは なく、重要な部分を書いて、影響が小さい作業は書 かなくてもいいということも謳っている 45

事実の基づく管理 ⚫ 勘や経験だけに頼るのではなく、事実やデータに基 づいて考えるという原則 ⚫ いわゆる三現主義（現場・現物・現実） 亀の甲より年の 功よりデータだ よ！ ⚫ TQMでは「統計的手法」を重視しているが、これは ソフトウェアでは向き不向きがあるかもしれない 46

品質保証の原則 プロセス重視 源流管理 標準化 手段の中にもい ろんな構造があ るんだねえ あるべき姿 PDCAサイクル 再発防止 未然防止 QCD結果に基づく管理 対を なす 重点思考 事実に基づく管理 潜在トラブルの顕在化 47

品質保証の原則 1.目的 マーケットイン 後工程はお客様 品質第一 2.手段 プロセス重視 標準化 源流管理 PDCAサイクル QCD結果に基づく管理 再発防止 重点思考 未然防止 事実に基づく管理 組織の運営の話 もするよ！ 潜在トラブルの顕在化 3.組織の運営 リーダーシップ 全員参加 人間性尊重 教育・訓練の重視 48 マネジメントシステムの審査・評価に携わる人のためのTQMの基本p.9より

リーダーシップ ⚫ 経営者・管理者が率先して顧客やステークホルダのニー ズを考慮して、適切な役割を果たせという考え方 ⚫ TQMが経営の考え方だと言われる所以だと思っている リーダーしっか りしてよ！ ⚫ 各々がリーダーシップを持つという今風の考えというか、 あくまでリーダーがリーダーシップを持てという考え方 49

全員参加 ⚫ 特定の人だけでなく、会社の全部門が全員参加で TQMを行うという考え方 ⚫ 共通の目標を持ち、部門間の障壁を取り除き、それ ぞれが自分の貢献と役割を理解した上で、知識や経 シャチくんが狩 りするときも全 員参加でやって るよね 験を共有して、問題・課題について自由に議論でき るようにする ⚫ Whole Team Approachやとおもう 50

人間性尊重 ⚫ 人間らしさ、人間の特性を十分に発揮できるように する考え方 ⚫ 英知、想像力、企画力、判断力、行動力、指導力な 海獣性も尊重し てほしいな どの能力をフル活用できるようにする ⚫ TQM成功の鍵とも言われている ⚫ マズローの欲求の「自己実現」をやる ⚫ モチベーション3.0にも通じるよね 51

教育・訓練の重視 ⚫ 企業の発展を支えるためには、知識・技能・モラル の向上のために一人一人の能力を上げるために教育 と訓練が必要という考え方 お勉強なんてや だなあ ⚫ 教育・訓練してるソフトウェア企業ってあるかな。ある か。 52

品質保証とは（まとめ） 顧客満足のために 全員参加で IYO（in yamazun opinion） やるべきことを きちんとやる やと俺は思う 53

QAエンジニアを言語化する 54

QAエンジニアに関するミもフタもない話 ⚫ QAエンジニアは元々外国の言葉です ⚫ 外国で品質保証とは第三者のテストのことです ⚫ つまりQAエンジニア＝テスターです 原点志向だね！ でも 55

ももの提言 TQMを言い訳に 自分の言いたい 主張しているだ けじゃないよ ね？ TQMがそうだったように 「日本におけるQAエンジニア」も 魔改造したい ももトイレ 56

TQMにおけるテストの位置付け ⚫ 調べてみてもよくわからなかった ⚫ ソフトウェア品質保証においては結構重要そうでは ある ちゃんと調べて よお〜 ⚫ 一方で、品質保証＝テストかというとNoという 気持ちがある ⚫ 静的テストがあろうとなかろうと 57

“品質保証エンジニア“という呪い ⚫ 日本において品質保証は「全員参加」だった ⚫ じゃあ「QAエンジニア」ってどうなんだ？ ⚫ そもそもQAエンジニアという言葉自体日本語ではな 覚悟キマってか ら品質の話しろ よ！ い気がするが、、 ⚫ 少なくとも、日本語で「品質保証を担う」と 言ってしまうとそれ相応の覚悟が必要な呪いに かかった 58

やまずんはQAとテスターの使い分けてる ⚫ TQM立場に立つと、「品質保証」はテストの延長線上ではなく、 顧客満足を目指すすべての活動（またはその姿勢）を指すっぽい ⚫ そうなってくると、すべてのロールはQAに関わっていると言え る気がしてきた 何言ってんだ ⚫ 顧客満足のためにエンジニアリングしてたら全員QAという極論 ⚫ 例えば山下さんは「テストに専門性があるQA」と名乗っている ⚫ 「テストの専門性だけではないQA」が存在していいことを仄めかして いるつもり 59

テストにおけるさまざまな専門性 ⚫ テスト実行者 ⚫ テスト設計者 ⚫ テスト計画者 ⚫ モニタリングとコントロールができないタイプの人もいる ⚫ テストマネージャー 色々あるんだね え〜 でも、こういう 思想が差別を増 長させてるん じゃないかとも 僕はおもうよ ⚫ テスト実行マネージャー ⚫ テスト自動化エンジニア ⚫ SET ⚫ テスト自動化エンジニアとSETは違うのですよ ⚫ QA 60

テストにおけるさまざまな専門性 ⚫ テスト実行者 ⚫ テスト設計者 ⚫ テスト計画者 ⚫ モニタリングとコントロールができないタイプの人もいる ⚫ テストマネージャー テスターってテ スト実行だけす る人じゃないな の？ ⚫ テスト実行マネージャー ⚫ テスト自動化エンジニア ⚫ SET ⚫ テスト自動化エンジニアとSETは違うのですよ ⚫ QA 私のテスターの スコープはこのへん SETがテスターかどうかは 意見が分かれる 61

QAの専門性 それは… 62

QAの専門性 全部です 63

QAエンジニア＝フルスタック ⚫ ”QAエンジニア“は全員参加の品質保証を担う ⚫ だからフルスタックであるべきと考える ⚫ つくる技術、確認する技術、運用する技術、売る技術 やまずんはFull Stuck QAだね！ etc ⚫ 顧客満足に関わるすべての技術を結集して日本的 な意味での「品質保証エンジニアリング」をすべ きだと考える 64

“品質はみんなで担うものです“以前の話 よくある“品質はみんなで担うものです“ だけどそもそも 開発はみんなで行う QAだけが自分の 責任をみんなで 担えると思って るやつは傲慢だ よね〜 ビジネスはみんなで行う ということを忘れてはいけない その前提の中で分業したり専門性があるということ 65

私が考える「品質、QA、QC、テスト」 ⚫ 品質…顧客がハッピーになる度合い ⚫ QA…QCが十分だって説明可能にすること ⚫ QC …品質を高めるためにやるすべて シンプルに考え すぎじゃない？ ⚫ テスト…QCのうちのひとつの手段 66

チームにおいてテスターではなくQAである必要 ⚫ 今風でクロスファンクショナルなチームの場合、テス トという単一のスコープをやるのはなく、品質保証と いう責務であったほうがいいという考え方 ⚫ テスターを業務のスコープと捉えるのか、専門性と捉 「テスターじゃ なくてQA」って 人多いよねえ えるのか、それによって違ってくる ⚫ QAのためにテスターならいいと思うけど、「テストし かしないQA」を日本語として捉えると違和感を感じて しまう体になってしまった 67

チームにおいてQAではなくテスターである必要 ⚫ そもそもQAとは全員で担うものなのだから、「QA」エンジ ニアというロールが識別されるのは変な感じがする。 ⚫ 人間に生まれたからと言って「人間」という名前をつける人はあ んまりいない どっちやねん ⚫ 開発もデザイナーも全ての人は品質保証を担うQAであり、そ の中で専門性がある「テスター」の方がいいんじゃないか？ 真面目な話、自分が作った製品を 常に批判的に見るのは無理があるから、 QAであれテスターであれ何かしら必要 だとは思う 68

品質富士山こそ品質保証の真髄である 僕もそろそろ登 山始めたいねえ ログラスQAのミッション・ビジョン・バリューを策定しました, https://note.com/k_kotatsu1992/n/nd639aa4b5692 69

質のランドスケープ 社会の質 品質富士山の高みから 会社の質 事業の質 製品の質 「質のランドスケープ」 何言ってんだ を見下ろす 高ければ高いほど ソフトウェア の質 我々は遠くをみることが できる 70

質のランドスケープ を広げるために 我々は時に 巨人の肩にも乗る 71

伝統と進化を両立させる両利きのQA かわいい黒猫 ちゃんだね！ ⚫ 伝統を尊重しつつも、ソフトウェアのQAを進化させる必要がある ⚫ というのをすごく具体的に示唆してくれている人もいます 72

パーフェクトQAパーフェクトスタイル ⚫ フルスタックに成って満足するのではなく、常に進 化することを目指すQAスタイル ⚫ 私はパーフェクトQAパーフェクトスタイルになる きっと君はそう ずっとパーフェ クトなQA 73

品質ってなんなの？ Part2 74

品質とは何か ⚫ 品質の定義は色々 ⚫ 「要求との適合」 ⚫ 「顧客満足」 いろいろあるよ ねえ、これって 叡智だよ ⚫ 「誰かにとっての価値」 75

品質とは何か ⚫ 品質の定義は色々 ⚫ 「要求との適合」 ⚫ 「顧客満足」 どう考えても大 事やろ ⚫ 「誰かにとっての価値」 最近 そんなに大事なことか？ と思うようになった 76

品質ってなんなの？ Part2 品質とは何かとは何か 77

「品質とは何か」を考える前に考えること ⚫ 顧客の要求は常に変わっているし、常にこれまでにな いものを作らないといけない ⚫ いわゆるVUCA みんなわかって るんじゃない？ ⚫ 「顧客満足」とは「顧客の言うことを聞く」ではない ⚫ 自分たちで考えて、学び、失敗しながら作らないとい けない 78

よく言われる「品質とは何か」とは何か 「品質」という言葉を言い換えたり、 メタファーすることではない 「顧客満足を目指す」ことが自明ならば 「自分たちにとっての品質は具体的になんなのか」 を考え抜くことが必要 79

「品質は怖い」 「品質なんもわからん」 ではなく 品質に向き合い 品質保証を担うエンジニアになる そうした未来を我々でつくる

参考文献 いつもありがと ね〜 • コタツ、ログラスQAのミッション・ビジョン・バリューを策定しました、 https://note.com/k_kotatsu1992/n/nd639aa4b5692、2024.12.22 • やまずん、品質保証における原則をソフトウェア開発に当てはめて考えてみ る、https://zenn.dev/55_ymzn/articles/principles_of_quality_assurance、 2024.12.19 • ISTQB:JSTQB,ISTQBテスト技術者資格制度Foundation Level シラバス 日本語 版 Version 2023V4.0.J02、 https://jstqb.jp/dl/JSTQBSyllabusFoundation_VersionV40.J02.pdf、2024.12.20 • 西康晴、時代遅れでブレーキ扱いのQAから、イマドキでアクセルとなるQAへ の脱皮、 https://www.juse.or.jp/sqip/community/bucyo/14/files/shiryou_kichokouen .pdf、2024.12.20 • 新版品質保証ガイドブック、（社）日本品質管理学会、2009年、日科技連出版 社 • マネジメントシステムの審査・評価に携わる人のためのTQMの基本、（社）日 本品質管理学会標準委員会、2008年、日科技連出版社 • 日本的品質管理ーTQCとは何かー、石川馨、2024年、日科技連出版社 • 品質管理入門、石川馨、2024年、日科技連出版社 • 日本のTQC ーその再吟味と新展開ー、小暮正夫、2024年、日科技連出版社 • 現代的品質管理総論、飯塚悦功、2009年、朝倉書店 81

• https://note.com/k_kotatsu1992/n/nd639aa4b5692
• https://zenn.dev/55_ymzn/articles/principles_of_quality_assurance
• https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf、2024.12.20
• https://www.juse.or.jp/sqip/community/bucyo/14/files/shiryou_kichokouen.pdf