A presentation for DeNA QA night #2 for the following panel discussion on evolution of software quality assurance for modern software development.

1. QAの過去から現在・現在から未来
DeNA QA Night #2
2019/3/6（水）
電気通信大学 大学院情報理工学研究科
情報学専攻 経営・社会情報学プログラム
西 康晴
@YasuharuNishi / Yasuharu.Nishi@uec.ac.jp

2. 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)
• Organizer
– QA4AI Consortium
• Advisor:
– Software Testing Automation Research group (STAR)
© NISHI, Yasuharup.2

3. 洞窟の奥には
隆盛を誇った古代都市の
遺跡がある．．．

4. ソフトウェアTQM
• SPC・SQiP（ソフトウェア品質委員会）として
1980年前後から取り組まれてきた
日本のソフトウェア産業における品質管理（含むQA）の活動群
– 「ソフトウェア工学とTQMの結婚」
• TQC/TQM（Total Quality Control/Management）というハードウェアの品質管理の日本的な方法論と
欧米的なソフトウェア工学とを融合させる実践的な取り組み
– 産を中心とした産学連携
• 菅野文友（逓信省・電電公社→日立→理科大など）→飯塚悦功（東京大学）→野中誠（東洋大学）がトップ
– 幅広い取り組み
• 研究会、セミナー、資格制度（JCSQE）、SQiPシンポジウム、知識体系（SQuBOK）など
• TQMとは？
– 日本で確立され一世を風靡した、ハードウェアにおける品質管理の方法論・技術の体系
• Total Quality Management（昔はTQC – Total Quality Controlと呼ばれていた）
• 品質 / 品質第一 / 目的指向とプロセス主義 / 人間性尊重 / 改善サイクルと標準化 / 方針管理と日常管理 /
品質の作り込みと水平展開 / 後工程はお客様 / 事実に基づく管理と5ゲン主義 / 自律と小集団活動 / QMS
• エッセンスを取り出すと、アジャイル開発の目指している像ととてもよく似ている
– 組立加工機械ではとても上手く作用するが、ソフトウェアでは？
• 汎用機（大型コンピュータ）の頃のソフトウェア開発では上手く作用した
• ネオダマ（ネットワーク・オープン・ダウンサイジング・マルチメディア）になってどうも雲行きが怪しくなってきた
© NISHI, Yasuharup.4

5. 時代の変化：かなり昔（汎用機時代：’70～’80）
• 特徴
– 内製や関係の強い企業に発注していた（汎用機）
– 日本的ワイガヤで開発していた
– あまり複雑でなく、規模はそこそこだった
– ほとんどが紙だった
– 全て自社製で揃えられて全部分かっていた
– 何をやればよいか手探りだった
– エンジニア意識の強い人が多かった
• どんな開発・QAだったか
– 中身をちゃんと理解して納得して作っていた
– 改善のサイクルを短くすることができた
– 品質を上げると嬉しいし儲かるビジネスモデルだった
– 開発に関わる人全員が品質意識を持つことができた
– 製品ごと部門ごとに施策を練っていた（試行錯誤していた）
– 全体としてどんな品質で何が問題なのかが分かっていた
– 組織能力が高まっていた
– 人間らしい仕事をしていた
– 品質スーパーマンに頼ってしまっていた
© NISHI, Yasuharup.5
諸説あり

6. 時代の変化：ちょっと昔（プロジェクト時代：’90～’00）
• 特徴
– 多重下請構造に基づいたプロジェクト制だった（エンプラ・組込み）
– コマンドアンドコントロールの徹底を目指していた
– かなり複雑でかなり大規模だった
– Excel方眼紙なので電子化のメリットがなかった
– オープンで分からないのに何とかできると妄想していた
– 業界標準的な品質マニュアルやメトリクスのようなものが出回っていた
– サラリーマンエンジニアが多かった
• どんな開発・QAだったか
– よく分からないけど指示に従って業務をこなす意識で作っていた
– 改善のサイクルを短くすることができなかった / そもそも改善しなかった
– 品質を上げても嬉しくないし儲からないビジネスモデルだった
– 品質を保証する専門の人たちと開発で対立が起きた
– マニュアルやメトリクスに従えば品質が保証できると盲信していた
– 全体としてどんな品質で何が問題なのかが分かっていなかった
– 組織能力は気にされていなかった
– 人間を取り替えのきく機械のように扱っていた
– コマンドアンドコントロールではあったが仕組み化はできていた
© NISHI, Yasuharup.6
諸説あり

7. 時代の変化：現在（クラウド時代：’10～）
• 特徴
– 内製化が進んできている（クラウド）
– アジリティの高いマネジメントが常識になってきている
– かなり複雑で徐々に大規模になっていく（が経験はない）
– 開発情報をデジタル化しツールを使うのが常識になっている
– オープンでどんどん変わるから制御できない
– GAFAMのやり方を学ぼうとする企業が多い
– ソフトウェアが好きな人を集めやすい
• どんな開発・QAなのか？
– 中身をちゃんと理解して納得して作れている？
– 改善のサイクルを短くすることができている？
– 品質を上げると嬉しいし儲かるビジネスモデルになっている？
– 開発に関わる人全員が品質意識を持つことができている？
– 製品ごと部門ごとに施策を練ることができている？
– 全体としてどんな品質で何が問題なのかが分かっている？
– 組織能力を高めることができている？
– 人間らしい仕事をしている？
– 仕組み化ができている？
© NISHI, Yasuharup.7
諸説あり

8. さて、
どっちに行こう？

9. 我々はどこに向かえばよいのか？
• ちょっと昔（プロジェクト時代）と同じQAをすると概ね失敗する
– クソCHAPDコントロールによる形骸化 / 開発とQAの対立 / 組織能力の衰退
/ 人間らしさの無視・モラルとモチベーションの低下 / 仕事の矮小化・視野狭窄 など
• Criteria / Human resource / Authorization / Process / Document -based control
（基準値に従え、人力でなんとかしろ、誰の責任だ、マニュアル化しろ、文書！文書！文書！）
• chapped: あかぎれになった、ひび割れた
• かなり昔（汎用機時代）と同じQAをしても的外れ・時代遅れになるだけ
– 高価なマシンパワーと原始的なツール、非オープン化の可能な開発、紙ベースの管理、
出荷で一区切り、余裕のあるスケジュールなどに最適化された方法であったと推測される
– 豊富なマシンパワーと安価でリッチな開発・運用環境、 OSSなど制御不能なオープン化、
DXされた開発情報、開発と運用の融合、分オーダーのデプロイ、AI/MLの発展など技術は変化・進化した
• 昔からのよい考え方をさらに変化・進化させながら、
現在の状況や環境、方法論、技術、道具に適応させ、さらに進化させることが必要
– 中身をちゃんと理解して納得して作る / 改善のサイクルを短くする / 品質を上げると
嬉しいし儲かるビジネスモデルにする / 開発に関わる人全員が品質意識を持つ
/ 製品ごと部門ごとに施策を練る / 全体としてどんな品質で何が問題なのかを把握する
/ 組織能力を高める / 人間らしい仕事をする / 仕組み化をする
• 参考: https://www.slideshare.net/YasuharuNishi/line-developer-meetup-in-tokyo-39-presentation-modified
© NISHI, Yasuharup.9

10. 自組織のQAを自分たちで進化させよう
• 優れた組織イニシアティブの創出や醸成
– 「納得感の共感」ファーストの品質マネジメントを行う
– 「質の高い仕事」中心の文化を育みビジネスモデルを構築する
– 品質は全員で高めるものだという考え方を常識化する
– 品質向上は成果物の質・組織能力・人間らしさを同時に高めていくことだ
というパラダイムを徹底する
• 品質保証戦略のデザインと着実な積み重ね
– サービスやチームのコンテキストや成長の過程に合わせて品質向上施策をデザインする
– 品質向上・品質保証の全体像やアーキテクチャをデザインする
– 技術ロジスティックスの動脈と（特に）静脈、そしてその循環をデザインする
– スコープが狭く具体的で、品質がよくなっていくことが
ありありと目の前に浮かぶような品質向上策をデザインする
– 人間がやらなくてよいことは全て機械に任せ、人間が人間らしい仕事をできるようにデザインする
• みんなが嬉しくなる品質マネジメントシステムの構築
– みんなが嬉しくなるように仕組みや組織構造、（人事的）評価制度、組織的振り返り、
ツールや環境の構築・整備などを行い、組織的に品質を高めていけるQMSを構築する
– 開発のあり方を考え抜き継続的に進化させていくミッションをQMSに持たせる
© NISHI, Yasuharup.10

11. よくやりがちなワナに気をつける
• おかしな組織イニシアティブの創出や醸成
× ちょっと昔のQAの人を採用してその考え方をそのまま採用する
× 表面的経営指標（利益、生産性、コストなど）を重視する
× 文化や考え方、パラダイムを無視して
プラクティスファーストのアジャイル品質保証を遂行しようとする
• 役に立たない品質保証戦略のコピペとやりっぱなし
× コンテキストや成長の過程を無視して
（他社の動向に引きずられた / バズワードに飛びついた）全社的施策を考えようとする
× 抽象的で主語の大きい施策を導入し、施策を改善せずに盲従させようとする
× クオリティゲートやアドホックCIなど、ぶつ切りで局所的で循環しない施策をデザインする
× バグやトラブルを忌み嫌ってムダにする（技術ロジスティックスの静脈をおろそかにする）
× 深く考えずに協力会社に丸投げする
• 誰も嬉しくならない品質マネジメントシステムの構築
× 品質保証組織のアイデンティティや証拠づくり、局所化、矮小化をする
× リソースが少ないからと監査でコマンドアンドコントロールや丸投げをしようとする – クソCHAPD
× 機械を信じない、機械を信じすぎる
© NISHI, Yasuharup.11

12. まとめ：
品質保証とは
組織を賢くするために
あらゆることをする
最高にやりがいのある
クリエイティブな仕事である

13. クリエイティブな技術開発を
一緒に進めませんか？
・ 共同研究 / コンサルティングでのコラボレーション
・ 社会人課程博士学生としてのジョイン
・ CI / AIを研究した学生のリクルーティング
@YasuharuNishi
Yasuharu.Nishi@uec.ac.jp