1. Quality Engineering って何なのそれ美味しいの？
にし やすはる（@YasuharuNishi）

2. Quality Engineering って流行ってるの？
© NISHI, Yasuharu
p.2
https://experience.mabl.com/japan
https://www.pnsqc.org/

3. Quality Engineeringは品質工学なの？
• 品質工学（ひんしつこうがく、英: quality engineering）とは、
技術開発・新製品開発を効率的に行う開発技法（Wikipedia）
– 考案者の田口玄一の名を冠してタグチメソッドとも呼ばれる
– 田口 玄一（たぐち げんいち、1924年1月1日 - 2012年6月2日）は、
品質工学（タグチメソッド）の創始者で日本の工学者
• タグチメソッドは1980年代のアメリカ合衆国の技術停滞打破に大きく貢献し、
これにより「アメリカを蘇らせた男」と呼ばれ、
日本人として3人目のアメリカの自動車殿堂入りを果たした
– ちなみに1人目はホンダの創業者で、2人目はトヨタ中興の祖
• 要するに…
– 「ロバスト設計」を中心とするハードウェアの設計技術
• 味を保証するために条件を固定して再現実験をする設計ではなく、
寒くても硬くならず暑くても溶けない材料条件を探すことで
どんな温度でも口の中で美味しく溶けるキャラメルを設計した
（森永製菓、1948年）
– http://merc.e.u-tokyo.ac.jp/mmrc/dp/pdf/MMRC212_2008.pdf
• ちなみにソフトウェアテストで直交表を使う技法は
タグチメソッドの入口の入口なので本筋ではない
• これは僕らが欲しいものじゃない…
© NISHI, Yasuharu
p.3
https://www.ism.ac.jp/noe/service-center/files/2013/02/taguchi.pdf
https://www.leansixsigmadefinition.com/glossary/genichi-taguchi/

4. 僕らが欲しい Quality Engineering の正解はこちらです！
© NISHI, Yasuharu
p.4
皆さんも聴きましたよね！
素晴らしい講演でした！
https://experience.mabl.com/japan

5. イマドキのソフトウェアのQuality Engineeringはどこから？鼻から？喉から？
• 日本だとこの記事かしら？
– 品質保証をアジャイルに組み込むQEエンジニアの役割を徹底解説
• 伊藤忠テクノソリューションズ株式会社 Buildサービス推進チーム 日野杉賢祥氏
• 記事の抜粋
– 「QEとはテスト戦略や自動化などの品質への焦点を
アジャイルに組み込む役割となる。ステークホルダーや
開発チームに品質戦略について教えて導いていく。」
• 具体的にはテスト計画の立案、プラットフォームごとの
テストケース設計、テスト実行など、プロジェクトチームが
適切な品質目標と合格基準を決定するのを支援する
– 「従来のQAと比べると、
各要素を含めたテスト自動化エンジニアと呼ぶと
分かりやすいかもしれません」
– 「QAでは「第三者視点」などエンジニアと別チーム
という扱いになりがちだが、
QEはエンジニアチームの一員として品質向上を進めていく
傾向がある。」
– 「一番の違いは、実装完了後にテストするのではなく、
実装開始と同時に品質に責任を持って行動する」
– 「もともとはSlalom社における役割が由来となる。」
© NISHI, Yasuharu
p.5
https://codezine.jp/article/detail/13718

6. Slalom社？
• どんな会社？
– アメリカ合衆国ワシントン州シアトルに登記上の本拠を置く総合コンサルティング会社（Wikipedia）
• Slalom Buildというテックブログ？がある
– Our Core Principles
• Whole team ownership
• Empowering teams
• Value of proximity
– i.e. Collaboration
• Automation is critical
– Here are some of the functions
our expert QEs perform every day
• Modernize the software validation process
• Enable Agile teams to move and respond faster
• Create confidence and predictability
• 要するに「QE = モダンなQA++全部入り」
– ただし定義している組織のビジネスに沿って
強調しているところが異なったりしている
© NISHI, Yasuharu
p.6
https://www.slalombuild.com/quality-engineering

7. QE = モダンなQA++全部入り、らしい
© NISHI, Yasuharu
p.7
https://www.accenture.com/_acnmedia/PDF-153/Accenture-Quality-Engineering-Affects-Everyone.pdf
https://abstracta.us/blog/software-testing/infographic-what-is-a-qe/
https://en.wikipedia.org/wiki/Quality_engineering

8. QE =モダンなQA++全部入り、らしい
© NISHI, Yasuharu
p.8
Quality Engineer Learning Roadmap
https://medium.com/slalom-build/quality-engineer-learning-roadmap-fddfcb77409e

9. QE =モダンなQA++全部入り、らしい
• CapgeminiのDX&QualityのVPさんのまとめ
（Quality Engineering has manifested to）
– Requirements engineering through intelligent solutions that
ensure delivery assets are kept in sync with changing requirements
– Experience focused “Design thinking” and feature driven development approaches
– “Test Driven Development” techniques that
drive focus on early alignment and automating incremental new functionality
– Continuous testing through the automated pipeline enabling immediate feedback loops
– Intelligent robotic process and workflow automation for user acceptance and customer experience
– Predictive analytics enabling real time insights, self-healing and overall delivery optimization
© NISHI, Yasuharu
p.9
https://www.linkedin.com/pulse/quality-engineering-paradigm-shift-kirthy-chennaian/

10. ちょっと待て新しい敵が…
p.10 © NISHI, Yasuharu
Quality Analyst

11. Quality Analyst vs. Quality Engineer
• Quality Analyst typically responsible for:
– Sprint, test, and release planning.
– Serving as a quality testing expert.
– Managing backlogs to avoid oversight of
acceptance criteria or edge cases
– Executing functional tests.
– Reporting on quality and testing status.
– Maintaining quality documentation.
– Identifying test cases.
– Working with client teams to support
acceptance testing, analyze issues, and
classify issues as bugs or
enhancements.
– Manually configuring test environments.
• Quality Engineer typically responsible for:
– Identifying repeated test cases.
– Identifying tests requiring multiple
environments, such as browsers or
operating systems.
– Identifying end-to-end test cases.
– Automating tests to eliminate issues
related to manual testing.
– Integrating testing into continuous
integration / continuous delivery (CI/CD)
pipelines.
– Identify and resolve bugs resulting from
test automation failures.
p.11 © NISHI, Yasuharu
https://www.sealights.io/software-quality/software-quality-engineering-a-beginners-handbook/

12. もう何がなんだか分からないよ…
© NISHI, Yasuharu
p.12

13. いやそもそも我々はQAを分かっているのか…？
© NISHI, Yasuharu
p.13
https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties

14. いやそもそも我々はQAを分かっているのか…？
• A社の募集要項：QAエンジニア
– 企画段階からの品質改善
– 不具合分析からの開発チームへの改善策の提示
– 事業計画に沿った開発の推進とKPIの運用
• B社の募集要項：QAエンジニア
– テスト設計・実行・不具合報告
– テスト計画・管理
– プロダクトの改善提案
• C社の募集要項：QAエンジニア
– テストインフラの構築・運用
– テスト自動化
– テスト管理・障害管理
• D社の募集要項：テストエンジニア
– テスト環境の構築
– テスト自動化
– 開発プロセスの改善
© NISHI, Yasuharu
p.14
なるほどこれがQAか…
あれれ？QAってテストするの？
あれれ？QAって
テスト自動化（SET）なの？
あれれ？テストって
SETだけなの？
https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties

15. SEA-SIGSQAではこう整理してます
• テストエンジニア（TE）
– テストする人
• テストの実行・設計・計画・戦略立案・管理・推進など
– イメージしやすいし、分かりやすい
• SET
– 自動化する人
• （E2Eも含めた）テスト自動化、 CI/CDやCT（継続的テスト）のパイプライン構築、SREやMlops、自動化戦略立案など
– これもイメージしやすいし、分かりやすい
• PE（パイプラインエンジニア）と呼んでみよう
• QAエンジニア
– みんなをよくする人
• チーム全体の品質向上、ふりかえり力向上＆プロセス改善、フロントローディング/シフトレフト、品質戦略立案など
– 本来はいらないルールを押しつけてくる人ではない
– イメージしにくいし、分かりにくい？
• 潤滑油的な役割は組織ごとに異なる
© NISHI, Yasuharu
p.15
TEとPEとQAのスペシャリティ（得意技）は全然異なる！
https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties

16. SEA-SIGSQAでは3つ合わせてQM（品質マネジメント）と呼んでます
• QMファンネル（3D版）のそれぞれの側面はスペシャリティ（得意技）を表す
– TE – テストやレビュー、メトリクスの測定など製品やサービスの評価技術のエキスパート
• 検証技術と価値重視文化を担う
– PE – 様々な自動化を行うエキスパート（SETやSRE）
• 自動化・デジタル化技術とエンジニアリング文化を担う
– QA – 組織能力を高めるエキスパート
• 組織能力向上の技術と文化を担う
• スペシャリティをきちんと区別しないと、適切にスキルを高められない
– スペシャリティのバランスが悪いと、まっすぐ力強く品質向上していかない
– その一方で、それぞれのスペシャリティを
サイロ化させずに融合していかなくてはならない
• それぞれのスペシャリティが別の人に割り当てられている状況でも、
他のスペシャリティのことを理解していなければ良い仕事はできない
© NISHI, Yasuharu
p.16
https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties

17. 早速取り入れて頂いている組織も…（ありがとうございます！）
© NISHI, Yasuharu
p.17
https://blog.kyash.co/entry/2021/11/15/170250

18. （総合的）品質マネジメントは日本の製造業の強みの源泉の一つ
© NISHI, Yasuharu
p.18

19. 日本的TQMの原則 – 製造業向けだがモダンなQA++全部入りのマインドセット
• 品質
• 品質第一
• カイゼンサイクルと標準化
• 方針管理
• 目的指向とプロセス主義
• 水平展開による品質の作り込み
• 全員参加と「後工程はお客様」
• 事実に基づく管理と5ゲン主義
• 自律と小集団活動
• 人間性尊重
• 悪さの知識
© NISHI, Yasuharu
p.19
ただ、
「管理技術」っぽい
雰囲気になってるのは
否めない
https://www.juse.or.jp/qc_circle/case/
https://www.agilityiq.io/product-management/the-kano-model-for-prioritization/

20. マネジメントに寄りすぎるのも確かによくない
© NISHI, Yasuharu
p.20
https://twitter.com/goyoki/status/1460245170239131653

21. マネジメントに寄りすぎるのも確かによくない
© NISHI, Yasuharu
p.21
Figure 2 in ISO/IEC/IEEE 29119-2:2021

22. まとめ、なの
• Quality Engineering は、どうやら流行っているらしいの
• 基本的には、QE = モダンなQA++（全部入り） のようなの
– とっても美味しいの！
• 日本の製造業では Quality Management と呼ぶのが普通なの
– QEは品質工学と訳してしまうとタグチメソッドになってしまうの
• Quality Engineering という呼び方に飛びつく前に、
自分たちが「QA」や「テスター」と呼んでいるロールは何なのかを整理しましょうなの
– SEA-SIGSQAによる TE / PE / QA という区分は悪くない気がするの
• 自組織でマネジメント側面よりもエンジニアリング側面を強調したいのであれば、
品質エンジニアと呼ぶのはあり寄りのありかな、と思うの
– 大事なことは、自分たちのロールを自分たちでちゃんと理解して定義し、
自組織の改善や成長、品質系の技術の進化に応じてアップデートすることなの！
© NISHI, Yasuharu
p.22