ソフトハウスの品質保証のウソホント

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 ＋＝

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

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

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

ソフトハウスの品質保証のウソホント

Yasuharu Nishi

ソフトハウスの品質保証のウソホント