1. © NISHI, Yasuharu
ソフトハウスの品質保証のウソホント
SQiP関西 品質保証責任者の会
2016/5/24（金）
電気通信大学 大学院情報理工学研究科
情報学専攻 経営・社会情報学プログラム
西 康晴

2. © NISHI, Yasuharu2
自己紹介
• 身分
– ソフトウェア工学の研究者
» 電気通信大学 大学院情報理工学研究科 総合情報学専攻 経営情報学コース
» ちょっと「生臭い」研究／ソフトウェアテストやプロセス改善など
– 先日までソフトウェアのよろず品質コンサルタント
• 専門分野
– ソフトウェアテスト／プロジェクトマネジメント
／ＱＡ／ソフトウェア品質／ＴＱＭ全般／教育
• 共訳書
– 実践ソフトウェア・エンジニアリング／日科技連出版
– 基本から学ぶソフトウェアテスト／日経ＢＰ
– ソフトウェアテスト293の鉄則／日経ＢＰ
• もろもろ
– TEF: テスト技術者交流会 / ASTER: テスト技術振興協会
– WACATE: 若手テストエンジニア向けワークショップ
– SESSAME: 組込みソフトウェア管理者技術者育成研究会
– SQiP: 日科技連ソフトウェア品質委員会
– 情報処理学会 ソフトウェア工学研究会 / SE教育委員会
– ISO/IEC JTC1/SC7/WG26（ISO/IEC 29119 ソフトウェアテスト）

3. © NISHI, Yasuharu3
TEF: Software Testing Engineer’s Forum
• ソフトウェアテスト技術者交流会
– 1998年9月に活動開始
» 現在1800名強の登録
» MLベースの議論と、たまの会合
– http://www.swtest.jp/forum.html
– お金は無いけど熱意はあるテスト技術者を
無償で応援する集まり
– 「基本から学ぶソフトウェアテスト」や
「ソフトウェアテスト293の鉄則」の翻訳も手がける
» ほぼMLとWebをインフラとした珍しいオンライン翻訳チーム
– 技術別部会や地域別勉強会が実施されている
» プリンタ、Web、AVなど
» 東京、関西、九州、東海、札幌など
» TestLinkというオープンソースツールの日本語化部会もある

4. © NISHI, Yasuharu4
ASTER: Association of Software Test EngineeRing
• ソフトウェアテスト技術振興協会
– テストを軸にして、ソフトウェア品質向上に関する教育や
調査研究、普及振興を行うNPO法人
» 2006年4月に設立／理事・会員は無給
– ソフトウェアテストシンポジウム（JaSST）を開催している
» 実行委員は手弁当／参加費は実費＋α
» 毎年4Qに東京で開催／例年のべ1500名前後の参加者
» 東北・四国・関西・北海道・九州・東海・新潟でも開催／会場はほぼ満席
– ソフトウェアテストの資格試験（JSTQB）を運営している
» Foundation Levelは21,548名の受験者・11,958名の合格者
» Advanced Level（テストマネージャ）を2010年8月に開始・361/1,486名の合格
» Advanced Level（テストアナリスト）を2016年2月に開始・43/351名の合格
– ソフトウェアテスト設計コンテストを開催している
» テスト設計の質の高さを競うコンテスト／今年は全国から15チームの参加
» 主要な成果物は無償で公開／毎年レベルが向上／マレーシアでも開催
– 各地でソフトウェアテストの教育を行っている
» テストのスキル標準（test.SSF）をIVIAと共同で開発している
» セミナーや勉強会などを支援することで、地場の産業振興の定着を図る
– アジア各国とテスト技術の交流（ASTA）を行っている
» アジャイル・バグ分析・ゲームテスト・テストプロセス改善など

5. © NISHI, Yasuharu5
SESSAME: 組込みソフトの育成研究会
• 組込みソフトウェア技術者管理者育成研究会
– Society for Embedded Software Skill Acquisition for Managers and Engineers
– 2000年12月に活動開始
» 200名強の会員／MLベースの議論と、月イチの会合
– http://www.sessame.jp/
• 中級の技術者を10万人育てる
– ＰＣソフトウェアのような「そこそこ品質」ではダメ
» 創造性型産業において米国に劣り、コスト競争型産業でアジアに負ける
» ハードウェアとの協調という点で日本に勝機があるはず
– 育成に必要なすべてを開発する
– オープンプロダクト／ベストエフォート
» 文献ポインタ集、知識体系（用語集）、初級者向けテキスト、スキル標準など
» 7つのワークグループ：組込みMOT・演習・MISRA-C・ETSS・子供・高信頼性
– セミナーだけでなく、講師用セミナーも実施

6. © NISHI, Yasuharu6
SQiP：Software Quality Profession
• 名称：
– 日本科学技術連盟・ソフトウェア品質委員会
• 目的
– SQiPは、ソフトウェア品質技術・施策の調査・研究・教育を通じて、
実践的・実証的なソフトウェア品質方法論を確立・普及することにより、
ソフトウェア品質の継続的な向上を目指す
• ３つの視点
– ソフトウェア品質・実践・普及啓蒙
• 主軸とする活動
１．実践的・実証的なソフトウェア品質方法論の確立
２．ソフトウェア品質方法論の普及促進・資格認定
３．ソフトウェア品質向上のための国際協力の推進
• 活動方針
１．ソフトウェア品質追究の重要性訴求
２．日本での実践的・実証的ソフトウェア品質方法論の形式知化
３．グローバルな視野での活動
４．新しい課題へのチャレンジ

7. © NISHI, Yasuharu7
Safeware翻訳プロジェクト
• 2009年11月に翻訳版を刊行した
– Nancy Leveson（MIT）著
– 翻訳チーム：松原友夫・片平真史（JAXA）・吉岡律夫（日本機能安全）
・青木美津江（電気通信大学） ・西康晴（電気通信大学）
– 翔泳社 発行
第1部 リスクの性質
第1章 近代社会におけるリスク
第2章 コンピュータとリスク
第3章 事故の階層的考察
第4章 事故の根本原因
第5章 ヒューマンエラーとリスク
第6章 自動化システムにおける人間の役割
第2部 システム安全への序論
第7章 システム安全の基礎
第8章 システム安全の基本
第3部 定義とモデル
第9章 用語
第10章 事故とヒューマンエラーモデル
第4部 セーフウェアプログラムの要素
第12章 システムとソフトウェア安全プロセス
第13章 ハザード分析
第14章 ハザード分析モデルと技法
第15章 ソフトウェアハザードと要求分析
第16章 安全性のための設計
第17章 ヒューマンマシンインタフェースの設計
第18章 安全性の検証
付録
付録A．医療機器：Therac-25の歴史
付録B．航空宇宙：アポロ13号、DC-10型機、
チャレンジャー号
付録C 化学産業：セベソ、フリックスボロー、ボパール
付録D 原子炉事故:ウィンズケール、
スリーマイル島、及びチェルノブイリ

8. © NISHI, Yasuharu8
講演の流れ
• ソフトウェア開発部門／ソフトハウスのQAの問題点
– 労働を売るというビジネスエッセンスと下請根性
– 自己矮小化
– プロセス・メトリクス指向QA
• 品質保証戦略の立案
– ビジネスエッセンスの見直し
– 組織コンセプトの構築
– 問題構造の分析とアクティビティの設計
– 伝播戦略の立案
• 品質保証アーキテクチャの設計
– QA観点モデル
– アシュアランスパイプライン（保証の網）
– テックシェルフ（技術の棚）
– アシュアランスメカニズムベースのプロセスと測定
• まとめ

9. © NISHI, Yasuharu9
役に立たないソフトQAの例（背景編）
• 現場や営業、客先から品質保証やカイゼンのリクエストは通常出てこない
– 品質が低くて生産性が高い方が工数がかかるのでダメな開発で稼働損を減らせば儲かる、
というビジネスエッセンスの罠にはまっている
» 実は客先は品質の低さや生産性の低さに嫌気がさしており、
客先担当者はダンピングをしてくるし、客先担当者の上司の上司は業者変更をしたいと思っている
– 現場はカイゼンしたいとか技術を高めたいとか言うと誰も賛成しないし、
以前やったら失敗したから雰囲気悪いし、業務時間外にやれとか言われるので
誰もカイゼンしたいと言い出さないし、誰かが言い出しても無視する
» 現場はどんどん自律性を失って下請根性の塊に成り下がってしまう
• しかし現場をよくしたい、とは別の妙な理由で
品質保証やカイゼンめいたものをしなくてはいけなくなる
– 厳しい顧客（＝カネを持っている顧客）に新規開拓したい営業などから、
標準プロセスくらい持ってないと発注しない／受注できないと言われる
» 規格を受注条件やバッジだと思っている顧客から、とにかく規格を取れと言われる
– トラブった現場の客先から営業がクレームを食らい、
再発防止して定量的に結果をお見せしなくちゃいけなくなる
– 経営戦略など持ってない経営陣がどっかからプロセス系の話を聞いてきて、
うちの会社でもやれとか急に言い出す

10. © NISHI, Yasuharu10
役に立たないソフトQAの例（実態編）
• プロセスを構築したりメトリクスを測ろうにも、
現場の仕事の実態をQAは掴んでいない
– エンジニアから話を聞こうにも客先にずっと常駐しているし、
自社に戻ってきてもらうと売り上げが下がるし、自分が行くのはめんどくさい
– そもそも現場で使えないヤツがQAに回されて書類仕事ばかりなのでクサっているし、
普段から役に立つ仕事が出来てないので現場からQAは尊敬されてない
• 現場のためでなく、自分たちのアイデンティティのために
仕事をしている／しようとする
– 年に1度程度の部門計画や部門報告の際に
仕事をしたことにしないとクビが危ないので、
自分は手を動かさないが報告しやすい仕事ばかりしようとする
– 事業部門や開発部門から役に立つと思われてないので、QAに人を回してもらえず、
手持ちの人員でできる程度の仕事しかできないと言い訳をする
– 現場の役に立たない仕事をしていることを正当化するために、
CMMiとかPMOとか社外のバズワード的な監査系の仕事を導入しようとする
• それがQAの仕事であり、そういうものだと自己矮小化している

11. © NISHI, Yasuharu11
役に立たないソフトQAの例（結果編）
• 営業時に顧客に見せる、もしく経営陣に見せるために、
かっこいいだけで根拠のないプロセスや帳票を作りメトリクスを測ろうとする
– 現場のためになることを指向していないので、
QAの仕事の根拠をそのプロセスとメトリクスに依存するようになり、
根拠のない押しつけを日常的に吐くようになる
» 「決めたんだから使え！」 「『測定なくして改善なし』とケルビン卿が言ってるんだよ！」
「ばらつきを減らすのが品質管理なんだ！」 「プロセスで品質を作り込むんだ！」
– 現場の仕事と乖離するかどうかはどうでもいいので、外部の権威に頼ろうとする
• プロセスや帳票、メトリクスができたのだから動かせ、と経営陣に言われる
– しかし現場の仕事と乖離しているから現場は言うことを聞かない
• 現場に無視されたまま現場はバカだと言い訳をするか、
会社指揮命令系統を通じて無理に現場に使わせようとする
– 後者の場合、現場は不要な作業、不要な帳票、不要な測定、不要な印鑑を
しなくてならなくなり、効率が下がりモチベーションが落ち、2重帳簿を作り始める
– もともとそこそこorギリギリで上手く行っていたはずの現場の仕事が回らなくなる
• トラブルが発生して仕事を切られて単価が下がる
• 景気のせいにしてほっかむりを決め込む

12. © NISHI, Yasuharu12
ソフトウェア開発部門／ソフトハウスのQAの問題点
労働を売るというビジネスエッセンスと下請根性
QAの自己矮小化
無根拠型プロセス・メトリクス依存QA
＋＝

13. © NISHI, Yasuharu13
講演の流れ
• ソフトウェア開発部門／ソフトハウスのQAの問題点
– 労働を売るというビジネスエッセンスと下請根性
– 自己矮小化
– プロセス・メトリクス指向QA
• 品質保証戦略の立案
– ビジネスエッセンスの見直し
– 組織コンセプトの構築
– 問題構造の分析とアクティビティの設計
– 伝播戦略の立案
• 品質保証アーキテクチャの設計
– QA観点モデル
– アシュアランスパイプライン（保証の網）
– テックシェルフ（技術の棚）
– アシュアランスメカニズムベースのプロセスと測定
• まとめ

14. © NISHI, Yasuharu14
品質保証戦略の立案が必要
• いきなり自組織の問題点を洗い出そうとするとどうなるか
– それはそうなんだけど、これではにっちもさっちもいかない
» 「PCが遅いです」
» 「窓やトイレが汚いです」
» 「残業が多いです」
» 「給料が安いです」
» 「なんかみんな幸せそうに見えません」
• 品質保証戦略の立案が必要になる
– ビジネスエッセンスの見直し
– 組織コンセプトの構築
– 問題構造の分析とアクティビティの設計
– 伝播戦略の立案
• 品質保証戦略を練るために頭数は必要ない
– QAに人を割いてもらえない、というグチは必要ない

15. © NISHI, Yasuharu15
ビジネスエッセンスの見直し
• 品質保証をするには、自分たちのビジネスが分かっていないといけない
– 誰に何を売っているか
– その質は何によって決まるか
– その質をどこでどう確実に作り込んで確実に実証するか
– 誰が喜ぶか
• ビジネスエッセンスを矮小化しているソフト開発部門やソフトハウスが多い
– 元請けに労働時間を売っている
– 元請けに言われたことに従っている雰囲気を出せば文句を言われないし、
元請けが知りたくない細かいことを知っていると重宝される
– 現場で個々のエンジニアが文句言わずに働けばよい
– 文系的経営陣と営業部長が喜ぶ
» 同じ現場でずっと文句言わずに黙々と働いているので、
営業はノークレームで新規開拓コストが少ないので喜ぶ
» 経営は稼働損が少ないので喜ぶ
• 矮小化されたビジネスエッセンスに従うと、
役に立たないQAが必然的に出現する

16. © NISHI, Yasuharu16
ビジネスエッセンスを見直す際のソフトハウスの例
• 例えばこんな、同業他社より単価の高いソフトハウスがある
– セットメーカーに「派生しやすさ」を売っている
– 「派生しやすさ」の質は、エンジニアの設計技術力によって決まる
– 自社内の教育によって設計技術力を上げ、
その技術力を活かして「派生しやすさ」を設計工程で作り込み、
質の高いレビューで不具合を防止している
– 派生しやすいので製品開発速度が上がり手戻りコストが減るのでお客様が喜び、
単価が上がるので営業と経営が喜び、腕が上がるので技術も喜ぶ
– こんな組織では、どんなQAが必然的に出現するでしょう？

17. © NISHI, Yasuharu17
ビジネスエッセンスを見直す際のソフトハウスの例
• 例えばこんな、同業他社より単価の高いソフトハウスがある
– 元請けに「カイゼン力」を売っている
– 「カイゼン力」の質は、エンジニアのカイゼン技術力やカイゼン経験によって決まる
– 自社内のカイゼン活動で技術力と経験を高め、常駐している客先でカイゼンを提案し、
PDCAを回してきちんと遂行し、客先のカイゼンのよいところを自社に持ち帰り
自社のカイゼンをカイゼンしている
– カイゼンによって元請けの開発力が上がるので元請けの偉い人が喜び、
単価が上がるので営業と経営が喜び、カイゼンによって現場の雰囲気がよくなるので
元請けのエンジニアも自社のエンジニアも喜ぶ
– こんな組織では、どんなQAが必然的に出現するでしょう？

18. © NISHI, Yasuharu18
まずビジネスエッセンスの見直しが必要
ビジネスエッセンスを矮小化していると
必然的に現場に役立たないQAになってしまう

19. © NISHI, Yasuharu19
組織コンセプトの構築
• 品質とは何か、をきちんと分かっている組織は極めて少ない
– 欧米的な考え方：
» 顧客の要求に対する合致度といった「開発の結果」である
– 日本的な考え方：
» 仕事の質，サービスの質，情報の質，工程の質，部門の質，人の質，システムの質，
会社の質など，これら全てを含めた「質」
• TQMを支える思想
– 品質第一の考え方、データ・事実に基づく管理、人間性尊重
– よく考えると、ものの「質」にだけ着目しているわけではない
» 価値的側面、思考様式的側面、人間的側面の3つに着目している
» JIS Q 9005 における質マネジメントの12原則：顧客価値創造、社会的価値創造、
ビジョナリーリーダーシップ、コアコンピタンスの認識、人々の参画、パートナーとの協働、
全体最適、プロセスアプローチ、事実に基づくアプローチ、組織及び個人の学習、
俊敏性（アジリティ）、自律性
• 「質」とは、多様な側面から成り立つ複合概念である
– 結果的側面、価値的側面、思考様式的側面、行動様式的側面、
内部技術的側面、組織的側面、人間的側面など
– 単一の側面にのみ着目しても上手くいかない

20. © NISHI, Yasuharu20
品質コンセプトパッケージング
• 「質」を構成する多様な側面と要素概念を表すキーワードの例
– 結果的側面
» 結果不具合の少なさ、非機能特性、要求合致度など
– 価値的側面
» 感性品質、顧客価値、顧客の顧客の価値、社会的価値など
– 思考様式的側面
» （価値）創造、目的指向、全体俯瞰、融合、アーキテクチャ、事実に基づくアプローチ、
正味作業時間、本質、コアコンピタンス、水平展開、厳密性、納得感、分割統治など
– 行動様式的側面
» カイゼン、学習、アジリティ、自律、チャレンジ、少ない手戻り、フロントローディング、
未然防止、標準化、正確さ、再現性など
– 内部的技術的側面
» 欠陥の少なさ、設計のよさ、スジのよさ/グッドノウハウ、悪さのなさなど
– 組織的側面
» 全員参加、一体感、気配り、パートナーとの協働、顧客巻き込み、リーダーシップ、
フォロワーシップ、上意下達など
– 人間的側面
» 人間性、やりがい/働きがい、よろこび、ワクワク感、プライド

21. © NISHI, Yasuharu21
品質コンセプトパッケージング
• 自分たちにとっての「品質コンセプト・パッケージ」を形作る
– 品質コンセプト・パッケージとは、自分たちにとっての「質」とは何か、を
「質」を構成する多様な側面から選び取ってパッケージングしたものである
» 自分たちの組織コンセプトを表すことになる
– 品質コンセプト・パッケージには、できるだけ多くの側面を含めるべきである
– 要素概念には、容易には相容れないものがある
» 例）アジリティと厳密性
– 容易に相容れない要素概念群をパッケージ化するためのグルー概念がある
» 例）自律、本質、スジのよさ
– グルー概念を軸にできるだけ多くの要素概念群をパッケージ化する際に、
自分たちのドメインや社風などと照らし合わせて取捨選択することが重要である
» 何でもかんでも詰め込んでしまうと齟齬を押さえきれない
– 軸となる少数のグルー概念や要素概念を用いて
コンセプト・パッケージに名前をつけてやるとよい
– 「質」というよりも、技術力などと表現する方がしっくりくる組織もある
• 品質コンセプトパッケージの例
– カイゼン型組織、品質第一、アジャイル、コマンドアンドコントロールなど
• 品質コンセプトが一貫していないと、品質保証アクティビティがチグハグになる

22. © NISHI, Yasuharu22
問題構造の分析とアクティビティの設計
• 不適切なビジネスエッセンスと一貫していない品質コンセプトによって
現場および組織の至るところで問題が発生している
• 発生している問題や原因、原因の原因などの因果関係を
関係者で一緒に作成し、納得し、共感することを、QA活動の一歩目にする
– 因果関係を図にする手法はたくさんある
» 問題を直接記述するタイプ：SaPID by 安達賢二、フロー型なぜなぜ分析、N7（新QC7つ道具）
» プロセスを記述するタイプ：PFD by 清水吉男、PNA（プロセスネットワーク分析） by 金子龍三
– それっぽいものをおざなりに作成するのが目的なのではなく、
関係者があーでもないこーでもないと議論したり不満をぶちまけたり
思いをぶつけあったりしながら、全員が腹落ち（強い納得）をして共感するのが目的である
– 典型的なパターンは、やりっぱなしを示す一方向の図と、
様々な問題が鶏と卵のループ図になっているものである
• 見直したビジネスエッセンスと一貫した品質コンセプトにしたがって、
品質アクティビティダイナミクスモデルを設計する
– 複数のQAのアクティビティ（SPI、バグ分析、メトリクス、レビュー、テストなど）が
相乗効果を及ぼすようなQAアクティビティの全体像をデザインする
– 継続的にQAがよくなるようにループ図が含まれていないといけない

23. © NISHI, Yasuharu23
問題構造の図の例：SaPID
「システムズアプローチに基づくプロセス改善メソッド：SaPIDが意図するコト」
http://www.jaspic.org/event/2012/SPIJapan/session3A/3A3_ID009.pdf

24. © NISHI, Yasuharu24
品質アクティビティダイナミクスモデリング
• 「質」の向上のための複数の取り組み（アクティビティ）が
相乗効果を生み出せない組織が多い
– 多様な側面を持ち、多様な品質特性から構成される
「質」を単一のアクティビティだけで向上することはできない
– 多くの組織では、複数の品質向上の取り組みを採用しているが、
アクティビティ同士がバラバラなため相乗効果を生み出せなかったり、
場合によっては打ち消し合ってしまってさえいる
– 異なるアクティビティを同期させるためにスローガンや目標数値を示すものの、
バラバラなものはバラバラなままである
• アクティビティ間の関係を俯瞰的に把握しデザインすることで、
多様な側面や品質特性を継続的に向上させる必要がある
– 品質向上の様々なアクティビティが相乗効果や相互強化を行い、
持続的でムリ無く品質、競争力、経営をよくし続けていけるような
ストーリーやモデルを構築する
– 問題構造図を品質アクティビティに置き換えたモデルを使ってデザインする
» 問題構造図法はアクティビティデザインの図法を持っていることがある
» この講演では品質アクティブティダイナミクスモデリングを説明する

25. © NISHI, Yasuharu25
品質戦略不全の組織のざっくりしたモデル
プロセス
管理
品質納期コスト
技術
プロダクト
ひと
品質文化
無視
無視

26. © NISHI, Yasuharu26
よいQA戦略が構築・実践されている組織のモデル
ひと
技術 管理
品質
コスト 納期
プロダクト プロセス
品質文化
悪さの知識：リスク
をフィードバック
悪さの知識：バグ
をフィードバック
チームモチベーション
の向上
個人モチベーション
の向上

27. © NISHI, Yasuharu27
品質アクティビティダイナミクスモデリング
• アクティビティ間の関係を俯瞰的に把握しデザインすることで、
多様な側面や品質特性を継続的に向上させる必要がある
– アクティビティダイナミクスモデルを記述して、俯瞰的に把握してデザインする
» アクティビティ（取り組み）、アーティファクト（成果物）、リソースプール（能力蓄積）の３つで表す
· 矢印の意味は因果関係的なものを意味するが、曖昧である
» アーティファクトによってアクティビティ間の論理関係を補強し、
リソースプールによって（ポジティブ）フィードバック構造を見抜く
– そのアクティビティによって何が起こるか、という
因果関係の流れをきちんと把握するのが目的である
» １枚の図に時間的因果関係（ダイナミクス）を描き、全体像を把握する
» アクティビティ間の因果関係に甘い見通しを立ててはいけないが、
例外ばかり考えて本筋を見失ってはいけない
– ポジティブフィードバック構造が発生していると
持続的な「質」の向上を見込める戦略になる
– クリティカル・コア（キラーパス、キーストーン）となる
アクティビティがあると、模倣困難なモデルとなる
» クリティカル・コアなアクティビティは割と非常識的である
» モデルを部分的に（理解不足で）模倣すると失敗に向かう
» バグパターン化戦略や、フルスタックモデル化戦略、
多能工化戦略はよい例だろう
リソースプール
（能力蓄積）
アーティファクト
（成果物）
アクティビティ
（取り組み）

28. © NISHI, Yasuharu28
バグパターン戦略のアクティビティダイナミクスモデル
バグ分析による
パターン化の促進
レビューの
改善
バグパターン
ごとの
開発ROIの測定
バグパターン化への
投資の経営判断
開発ガイドラインの
作成 若手への
教育内容の
明確化
バグ
パターン
増加
品質向上活動への
やる気向上
RvwCL/
DevGL
強化
投資増強の
経営判断
新たな
バグ
短いサイクルで
因果関係の
明確な開発ROI
教育部門の
コンテンツ増強
教育部門の
ROI向上
開発者の実質的な
技術力向上の実感
手戻りの低減による
超過作業の低下と
前向き作業の増加
特定パターンの
バグの撲滅
クリティカル・コア

29. © NISHI, Yasuharu29
フルスタックモデル化戦略のADモデル
設計のモデル化の
増強
モデル化された
設計
設計ノウハウ
向上 設計不具合
低減
モデル化への
投資の経営判断
投資増強の
経営判断
開発ROIの
向上
設計ベーステストの
自動化
ソースコード生成
の自動化
実装不具合
低減
工数削減
モデル化
しにくい仕様
要求定義
工程の改善
よりモデル化
しやすい仕様
仕様不具合
低減
仕様のモデル検査
クリティカル・コア

30. © NISHI, Yasuharu30
ダメなフロントローディング戦略のADモデル
アドホックな
テストケース記述
詳細な
テストケース
仕様策定工程への
テストケース記述の
フロントローディング
詳細だが
意図の分からない
テストケース
詳細に書いて
初めて分かる
仕様の矛盾
仕様策定工程での
仕様矛盾の検出
仕様変更への
テストケースの追従
仕様策定工程での
詳細な
テストケース記述
仕様変更時の
追従工数の爆発
設計工程以降での
仕様由来不具合の
減少
ポジティブフィードバックが
発生していないので
持続的な戦略になりにくい

31. © NISHI, Yasuharu31
伝播戦略の立案
• 適切なビジネスエッセンス、一貫した品質コンセプト、
相乗効果を生む品質アクティビティを組織全体に伝播させる必要がある
– QA部門からの通達や押しつけの経路でも、部門成果を数値で他部門に示すことでもない
– 関係者があーでもないこーでもないと議論したり不満をぶちまけたり
思いをぶつけあったりしながら、全員が腹落ち（強い納得）をして共感するのが目的である
» 当然ながら時間も手間もかかるが、これをおろそかにすると全てが台無しになる
» この過程を経てこそ、技術中心文化や品質文化が醸成される
– 「説明無責任」のために説明することは厳に慎む
» 説明無責任： 自分が責任を回避するために言葉を尽くして説明をすることであり、
そこに自分の仕事が皆の役に立つことを伝えるという意志は微塵もない
• 伝播戦略には様々な仕掛けが必要となる
– トップダウンとボトムアップだけでなく、ミドルダウンアップも必要である
» QA部門は全社組織だからといって、全社を一律にカイゼンしようとしてはいけない
– DD（Developer’s Delight）を向上するという姿勢を忘れない
– カイゼンは「いまダメでも少しずつ変わっていけばいい」という赦しである
» ダメなものやムダなものを少しずつよくしていきましょう、というのは明日から取り組める
– 管理指標や人事施策は会社からの非言語的だが明確なメッセージであることを認識する
» 稼働率から直行率へと管理指標を変えると、率先してダメやムダを取る行動様式になり、
稼働していない時にカイゼン活動や技術向上活動をするようになる
– 「Fearless Changeの48のパターン」はよい意味で泥臭く参考にできる

32. © NISHI, Yasuharu32
Fearless Changeの48のパターン
• 全体に関わるパターン
– Evangelist : エバンジェリスト(1)
– Small Successes : 小さな成功(2)
– Step by Step : ステップバイステップ(3)
– Test the Waters : 予備調査(4)
– Time for Reflection : ふりかえりの時間(5)
• 序盤の活動に関わるパターン
– Ask for Help : 協力を求める(6)
– Brown Bag : ブラウンバッグ・ミーティング(7)
– Connector : コネクター(8)
– Do Food : 何か食べながら(9)
– e-Forum : 電子フォーラム(10)
– Early Adopter : アーリーアダプター(11)
– External Validation : 外部のお墨付き(12)
– Group Identity : グループのアイデンティティ(13)
– Guru on Your Side : 達人を味方に(14)
– In Your Space : 空間を演出する(15)
– Innovator : イノベーター(16)
– Just Do It : やってみる(17)
– Just Say Thanks : 感謝を伝える(18)
– Next Steps : 次のアクション(19)
– Personal Touch : 個人的な接触(20)
– Piggyback : 便乗(21)
– Plant the Seeds : 種をまく(22)
– The Right Time : 適切な時期(23)
– Stay in Touch : 定期的な連絡(24)
– Study Group : 勉強会(25)
• 序盤の活動に関わるパターン（続）
– Tailor Made : テイラーメイド(26)
– Big Jolt : 著名人を招く(27)
• 中盤以降の活動に関わるパターン
– Corporate Angel : 経営層の支持者(28)
– Dedicated Champion : 正式な推進担当者(29)
– Early Majority : アーリーマジョリティ(30)
– Guru Review : 達人のレビュー(31)
– Hometown Story : 体験談の共有(32)
– Involve Everyone : みんなを巻き込む(33)
– Just Enough : ちょうど十分(34)
– Local Sponsor : 身近な支援者(35)
– Location, Location, Location : 場所重要(36)
– Mentor : メンター(37)
– Royal Audience : 謁見(38)
– Shoulder to Cry On : 相談できる同志(39)
– Smell of Success : 成功の匂い(40)
– Sustained Momentum : 勢いの持続(41)
– Token : トークン(42)
• 抵抗と付き合うためのパターン
– Bridge-Builder : 橋渡し役(43)
– Champion Skeptic : 懐疑派代表(44)
– Corridor Politics : 根回し(45)
– Fear Less : 怖れは無用(46)
– Trial Run : お試し期間(47)
– Whisper in the General’s Ear :
将軍の耳元でささやく(48)
Fearless Change：
アジャイルに効く
アイデアを組織に広めるための
48のパターン
https://www.amazon.co.jp/
dp/462108786X

33. © NISHI, Yasuharu33
安直な標準化は組織を硬直化させ現場を不幸にする
• 標準化を“バラツキの低減”と考えると失敗する
– ソフトウェア開発のような考える技術において、
バラツキの低減は低技術化と管理コストの増加を招く
– バラツキの低減は内向きの標準化を指向するようになり、
組織全体が官僚的かつ非可視化に向かうリスクがある
» 成功するメカの生産現場ではカイゼン活動のようなクリエィティブな活動を同時に行う
– 標準化とは、よいやり方を知らないことによる失敗を減らすことである
» 標準化はグローバル化とオープン化だと捉えた方がよい
• よい標準化はグローバル化とオープン化であり、技術向上を牽引する
– 最新の技術だけでなく、技術パラダイムや技術動向に馴染むことができる
» 技術開発に必要なのはむしろ技術パラダイムや技術動向である
– よいやり方だと説明しなくてはならないので組織に説明責任能力がつき仕事の可視化が進む
– 社外のクリエィティブな人材と交流することで、
自組織の官僚性を批判し打破できるようになる
» 技術者の社外活動率を測定してみると、 自組織がいかに内向きかが分かる
• 外モジュラー・内インテグラルをいかに実現するかが重要である
– 自社内だけで通用するツールや方法論で勝負できる時代ではない
» 外モジュラー：オープンなツールや方法論を使うことで顧客や競争相手と
価値共創できるようになり、自社の技術力にレバレッジをかけることができる
» 内インテグラル：オープンなツールや方法論を用いつつ、自組織で経験した
良い／悪い仕事をパターン化する習慣をつけて組織能力を継続的に高められる
– オープン化によって仲間を増やし自社技術の存在感を増しつつ、
一朝一夕に真似できないカイゼン習慣によるパターン化で優位性を保つ
？

34. © NISHI, Yasuharu34
講演の流れ
• ソフトウェア開発部門／ソフトハウスのQAの問題点
– 労働を売るというビジネスエッセンスと下請根性
– 自己矮小化
– プロセス・メトリクス指向QA
• 品質保証戦略の立案
– ビジネスエッセンスの見直し
– 組織コンセプトの構築
– 問題構造の分析とアクティビティの設計
– 伝播戦略の立案
• 品質保証アーキテクチャの設計
– QA観点モデル
– アシュアランスパイプライン（保証の網）
– テックシェルフ（技術の棚）
– アシュアランスメカニズムベースのプロセスと測定
• まとめ

35. © NISHI, Yasuharu35
品質保証アーキテクチャの設計
• 品質保証をするには、自分たちのビジネスが分かっていないといけない
– 誰に何を売っているか
– その質は何によって決まるか
– その質をどこでどう確実に作り込んで確実に実証するか
– 誰が喜ぶか
• 無根拠型プロセス・メトリクス依存QAの問題点は、
「その質は何によって決まるか」
「その質をどこでどう確実に作り込んで確実に実証するか」
が不明確な（無根拠）なことである
• そこで品質保証アーキテクチャを設計する
– 「その質は何によって決まるか」をQA観点モデルによって明らかにする
– 「その質をどこでどう確実に作り込んで確実に実証するか」とその全体像を
アシュアランスパイプライン（保証の網）として設計し、
それを支えるテックシェルフ（技術の棚）を構築し運用する
– QAアーキテクチャに従ってプロセスとメトリクスを導出すると、
そのプロセスやメトリクスによって品質がどう上がって組織が理想に近づくか、
の根拠を示すことができるので、現場が幸せになっていく

36. © NISHI, Yasuharu36
QA観点モデル
• 品質を保証するためにプロダクトやサービスにどのような観点が必要なのか、
をすべて書き出して整理したものがQA観点モデルである
– レビューのチェックリストやテストの大中項目などは部分的なQA観点モデルである
– ISO/IEC25000sの品質特性もQA観点モデルである
– バグ分析の結果もQA観点モデルである
– プロセスや組織のよさやメトリクスは、直接品質を保証しないのでQA観点モデルに入れない
• IoT時代になって、多様なQA観点が求められるようになってきた
– 機能仕様だけでなく非機能仕様も考えないといけないな
» 特にセキュリティや相互運用性は大事な気がする
– IoTになってソフトウェアの仕様だけを考えるような自己矮小化をしていられなくなってきた
» 使い心地、面白さ、安心などといったユーザ感情やUX（ユーザエクリペリエンス）
» 顧客共創、サービスドミナントロジック、プラットフォーム特性
• 適切なQA観点モデルを描くためには、
製品やサービスを提供する開発部門や顧客の
ビジネスエッセンスの見直しを一緒に行う能力が必要となる
– そこで自社のビジネスエッセンスの見直しの経験が活きてくる

37. © NISHI, Yasuharu37
アシュアランスパイプライン（保証の網）
• 開発・検証の工程ごとに、
どのQA観点を作りこんでどのQA観点を検証したかを明示する
– ネットワーク図のようになるので、保証の網とも呼ばれる
– 工場の生産工程におけるQC工程表にあたると考えてもよい
• QA観点と工程との関係を上手に割り当てることで、
特定の意図のQA観点だけを含んだ工程をつなげた
アシュアランスパイプラインを構築することができる
– QAが自動化できる観点の工程だけのパイプラインを作ると、
CI/CDに追随させて超高速で自動化品質保証できるQA観点と、
手動で品質保証しなくてはならないQA観点が区別できるので
メリハリのついたQAが可能になる
– 全製品に共通なQA観点のパイプラインから仕向地ごとのパイプラインに分岐させることで
グローバルなQA体制の全体像を設計することができる

38. © NISHI, Yasuharu38
テックシェルフ（技術の棚）
• アシュアランスパイプラインを支える技術のマネジメントにも
QAは大きく関わらなくてはならない
– プロセスは手順だけではなく、技法や方法論もツールも含まなくてはならない
• ドメイン技術、要素技術、エンジニアリング技術、マネジメント技術と
QA観点との組み合わせと抽象具体の関係で表現することができる
• ポジティブナレッジとネガティブナレッジを意識する
• バッドノウハウでなくグッドノウハウを貯めるようにする

39. © NISHI, Yasuharu39
ポジティブナレッジとネガティブナレッジを整理する
• ポジティブナレッジ（良さの知識）だけでなく
ネガティブナレッジ（悪さの知識）の整理がQAには重要
– 良さの知識：どうやればうまくいくか
» 参照アーキテクチャ、デザインパターン、開発プロセスなど
– 悪さの知識：どうやるとダメになるか
» バグのパターン、リスクのパターンなど
– 良さの知識は自然と蓄積されていくが、
それだけだとマニュアル化を導き
“考えないエンジニア”を生み出す危険性がどんどん高まっていく
– 悪さの知識は自然と蓄積されていかないので、
品質系の組織が主導して蓄積していかないといけない
» 悪さの知識はレビューの指摘項目やテストケースの質を向上させる
» 「品質の作り込み」とは、最初から良いことばかりをすることではなく、
悪さの知識をフィードバックして最初から気をつけて作ることである

40. © NISHI, Yasuharu40
グッドノウハウとバッドノウハウを区別する
• グッドノウハウとバッドノウハウを区別する
– バッドノウハウ：知らないと開発できないが本来知る必要のない制約事項
» 計算機を使っていると、何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、そ
れを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、とい
った類いのノウハウは多い。そうした雑多なノウハウのことを、本来は知りたくもないノウハウという意
味で、私はバッドノウハウ と呼んでいる。…バッドノウハウがはびこる大きな理由は、ソフトウェアの開
発者に使いやすさに対するセンスを欠如していたり、場当たり的な機能拡 張が度重なって行われた
り、単に開発の手を抜くために実装が楽なように仕様を決めてしまうといったところにあるが、別の理
由によ るものも根深いと私は考えている。それは、そういった使いにくいソフトウェアを使いこなす事
に対して、「奥が深い」といって喜び を見出す「奥が深い症候群」によるものである。 （高林哲）
– グッドノウハウ：本質的でセンスのよい汎用的な技術
– 自分たちの技術がグッドノウハウかバッドノウハウかを判別し、
グッドノウハウを育てる文化を醸成する
» 仕事を覚えるということがバッドノウハウの蓄積を意味している組織は実に多い
» バッドノウハウにまみれたエンジニアは潰しがきかず、組織が硬直する
» グッドノウハウやバッドノウハウを端的に表す方言があるとよい

41. © NISHI, Yasuharu41
講演の流れ
• ソフトウェア開発部門／ソフトハウスのQAの問題点
– 労働を売るというビジネスエッセンスと下請根性
– 自己矮小化
– プロセス・メトリクス指向QA
• 品質保証戦略の立案
– ビジネスエッセンスの見直し
– 組織コンセプトの構築
– 問題構造の分析とアクティビティの設計
– 伝播戦略の立案
• 品質保証アーキテクチャの設計
– QA観点モデル
– アシュアランスパイプライン（保証の網）
– テックシェルフ（技術の棚）
– アシュアランスメカニズムベースのプロセスと測定
• まとめ

42. © NISHI, Yasuharu42
まとめ
• 「労働を売るというビジネスエッセンスと下請根性」＋「QAの自己矮小化」
＝「無根拠型プロセス・メトリクス依存QA」という公式から脱却する
• まず品質保証戦略をきちんと練る
• 次にQAアーキテクチャを設計する
• そうすれば、QA主導で「現場が幸せで賢くなり、経営も儲かる」会社にできる

43. © NISHI, Yasuharu
QAの技術を磨いて世界一のQAになりましょう！
電気通信大学 西 康晴
http://qualab.jp/
Yasuharu.Nishi@uec.ac.jp