ソフトウェアの品質保証の基礎とこれから

1. © NISHI, Yasuharu ソフトウェアの品質保証の基礎とこれから日本規格協会品質経営システム研究会 2016/6/27（月）電気通信大学大学院情報理工学研究科情報学専攻経営・社会情報学プログラム西康晴

2. © NISHI, Yasuharu2 講演の流れ • 自己紹介 • IoT時代で品質保証部門は何を考えていけばいいのか？ • 製造業のソフト開発部門の品質保証の問題点の例 • 役に立たないソフトハウスのQAの例 • ソフトウェアとハードウェアの違い • ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • 品質保証アーキテクチャの設計 • ソフトウェアの品質管理の基本的アクティビティの概要 • まとめ • 補足：テスト開発方法論VSTePの概要とWモデル

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

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

5. © NISHI, Yasuharu5 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）を行っている » アジャイル・バグ分析・ゲームテスト・テストプロセス改善など

6. © NISHI, Yasuharu6 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・子供・高信頼性 – セミナーだけでなく、講師用セミナーも実施

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

9. © NISHI, Yasuharu9 （ソフトウェア）品質に対する欧米的な考え方 • PMBOK: Project Management Body Of Knowledge – 品質とは、「本来備わっている特性がまとまって、要求事項を満たす度合い」である（ASQ） » 8章冒頭 – プロジェクト品質マネジメントプロセスには、品質計画、品質保証、品質管理がある。品質管理－特定のプロジェクト結果が適切な品質規格に適合しているかどうかを判断するために、結果を監視し、不満足なパフォーマンスの原因を除去するための方法を特定する » 8章冒頭 • SWEBOK: SoftWare Engineering Body Of Knowledge – よく読むと、品質の定義を巧妙に避けている » ユーザ要求に対する適合性（Crosby）、利用に対する適合性において優れたレベルを達成する（ Humphrey）、顧客満足度（ＩＢＭ、MB賞）、本質的特性の集成体が要求を満たす度合い（ISO9001- 00） » 11章序説 – SQMプロセスは、与えられたプロジェクトにおいて、より良いソフトウェア品質を確証することを助ける。SQMプロセスは、その副産物として、全ソフトウェアエンジニアリングプロセスの品質表示など、マネジメントに対する一般的な情報を提示する » 11.2/ソフトウェア品質マネジメントプロセス

10. © NISHI, Yasuharu10 品質とコスト・納期はトレードオフであるという誤解 • 品質に対する欧米的な考え方 – 顧客の要求に対する合致度といった「開発の結果」である » PMBoK：「本来備わっている特性がまとまって、要求事項を満たす度合い」（ASQ） » SWEBOK：よく読むと、品質の定義を巧妙に避けているが、要するに顧客満足度 – コストや納期などと同列の、もしくは後回しの、単なる指標である – 品質向上活動によって現場が楽にならない » 行き当たりばったりの活動をしていたり、流行を追っている » 自組織の弱点を把握せず解決策に目を奪われている » 目的を見失い現場の信頼も失う – 経営指標ではない » 顧客の要求の達成どころか、自分の仕事の言い訳にしか使わない輩もいる • 品質とコスト・納期はトレードオフであるというのは誤解である – 品質を上げるとコストが上がり納期は長くなる » 品質は検査や監査で確保する – 最適品質を狙い、過剰品質は避けるべきである

11. © NISHI, Yasuharu11 （ソフトウェア）品質に対する日本的な考え方 • SQuBOK: Software Quality Body Of Knowledge – 仕事の質，サービスの質，情報の質，工程の質，部門の質，人の質，システムの質，会社の質など，これら全てを含めた「質」 » 1.1.1.7/品質の定義：石川馨 – 組織を長期的・安定的に存続させるには，組織の活動の主たるアウトプットである製品・サービスを顧客に提供し，それによって対価を得て，そこから得られる利益を再投資して価値提供の再生産サイクルを維持することが必須である。そのためには，組織が提供する製品・サービスが長期的に幅広い顧客に満足を与え続けなければならない。これを実現するための武器が「品質のマネジメント」である。 » 1.2/品質のマネジメント「品質」は技術力そのものであり、組織の持続的な強みの源泉である

12. © NISHI, Yasuharu12 （ソフトウェア）品質に対する日本的な考え方 • 品質とは – 単なる開発の結果ではなく、組織が目指すべき軸である » 欠陥、価値（円）、満足度、喜び、導き » ブランド力、ヒット商品を生み、感受性や予測が必要である – 組織における技術・マネジメント・ひとの持続的成長の源泉である » 顧客、経営、現場の３者を同時によくする – 現場が楽になるように品質向上活動をする » 中長期的な成長のプランを持ち、成果を現場に見えるように出すことで現場の信頼を得て継続的にカイゼンする » 自組織の弱点を把握して、適切な解決策を選びカスタマイズしたり、本質的な解決策を設計する » 絶えざる目的指向が備わるようになる – ロバストな経営指標である » 大きな失敗は無い品質を上げようとするとコストは下がり納期は短くなる

13. © NISHI, Yasuharu13 SQuBOKにみられる日本的TQMの特徴 • 「品質」 – 仕事の質，サービスの質，情報の質，工程の質，部門の質，人の質，システムの質，会社の質など，これら全てを含めた「質」 • 「品質保証」 – お客様に安心して使って頂けるような製品を提供するためのすべての活動 » プロダクトとプロセスが、特定された要求に合致しているかどうかという十分な確信を提供する活動ではない • 「改善」 – 不十分でもとにかく動き出して全員が今より高いところを目指してプロセスそのものを改善しながら進める » 欧米流の、プロセスを定義してその通りに実行していることを確認することではない • 「品質第一」 – 品質を高めることによって手戻りや作業のムダを省き，継続的な納期の短縮やコストダウンにつなげていく » 納期を厳守するために必要な作業を省くのではない

14. © NISHI, Yasuharu14 SQuBOKにみられる日本的TQMの特徴 • 「品質の作り込み」 – より上流で“悪さ”の知識を子細に活用し障害を排除していく » ただ単にきちんと作る、という意味ではない • 「次工程はお客様」 – 他の工程を助けるような改善を進め，全体最適へと向かっていく • 「人間性尊重」「組織活性化」 • 「小集団活動」 • 「5ゲン主義」 – 現場・現物・現実 – 原理・原則 • 「全員参加」 – 品質管理はスタッフだけではなく、現場も経営陣も一丸となって進めなければならない – 現場の関係者全員が納得してベクトルをあわせ，目標達成のために取り組む – 現場中心のため隅々まで改善が行き届くとともに，全員が自ら考えて行動する組織を構築できる

16. © NISHI, Yasuharu16 IoT時代で品質保証部門は何を考えていけばいいのか？ • センサー付き製品がどんどん増えていくので、ソフトのバグがあったら困る • 製品がネットワークでつながるので、セキュリティは大事みたいだ • でもそういうのはソフト部門に任せておけばいい • やっぱり足腰となる「ものづくりの品質」こそ品質保証部門の考えるべきことだ

17. © NISHI, Yasuharu17 IoT時代での品質を考えるための例 • 単体のビジネスホテルの品質にはどのようなものがあるか？ • ビジネスホテルチェーンの品質にはどのようなものがあるか？ • 顧客アクティビティ用のスマートデバイスを使う顧客滞在型リゾートの品質にはどのようなものがあるか？ • 民泊ビジネスの品質にはどのようなものがあるか？

18. © NISHI, Yasuharu18 IoT時代での品質を考えるための例 • 単体のビジネスホテルの品質 – 清潔度、ベッドの質、スタッフの導線、マニュアル通りの言葉遣い、など • ビジネスホテルチェーンの品質 – 顧客情報のセキュリティ・プライバシーの確保、個々のホテルシステムの相互接続性 – 大量の予約情報や顧客クレームすなわちビッグデータから抽出できる品質情報、など • 顧客アクティビティ用のスマートデバイスを使う顧客滞在型リゾートの品質 – お客様がスマートデバイスにカワイイと思ってくださるか – お客様がスマートデバイスでどれだけリゾートを楽しんでくださるか – お客様が家に帰ってからもリゾートの話をずっとしたくなってくださるか – お客様が他の方にリゾートを積極的に進めてくださるか、など • ・民泊ビジネスの品質 – ビジネスプラットフォームとして便利か – お客様にホテルの供給側になって喜びや誇りを感じてくださるか – お客様が他の方をホテルの供給側として誘ってくださるか – 自分たちのプラットフォームが標準になるために何をすればよいか、など » 他の業者が乗ってきやすいか、乗っていて快適か

19. © NISHI, Yasuharu19 IoTは組織のソフトウェア化を否が応にも進めて行く • 製品にソフトウェアが入り込み、製品同士や本社がネットワークでつながる – ネットワーク型組み込みソフト？ • 製品から送られてくるデータを本社側で解析しビジネスの質の向上につなげる – 組み込みソフト連動型業務システム？ • 製品から送られてくるデータを使った新しい機能や製品、サービス、ビジネスを機動的に展開するため、事業部門がソフトウェア開発部門を持たなくてはならなくなる – 事業部門が業務システムや組み込みソフトに深く関与していくようになる • ビジネススピードに追従するために事業部門がソフトウェア主体となっていく – 事業部門が業務システムや組み込みソフトを内製化するようになっていく – ソフト化された事業部門が自分たちで機動的に融合しどんどん形を変えていく • Industrie4.0のその先は？ – ソフトウェアによる製品そのもの、生産、設計、調達の融合 → 財務金融（資金調達）？ – 生産、工場立地選定、物流、販売、アフターサービスの融合 → 中古市場での価値創造？ – 価値の流れ、モノの流れ、情報の流れ、ヒトの流れ、カネの流れがソフト化され機動的に融合しどんどん形を変えていく？ – 事業部門も企業も業種も機動的に融合しどんどん形を変えていく？ • そんな世界を見据えて製造業の品質保証部門は何を考えていけばいいのか？

21. © NISHI, Yasuharu21 製造業のソフト開発部門の品質保証の問題点の例 • 不勉強で固有技術の違いを理解しようとしない QCの専門家を自称する管理屋・統計屋が自分たちの知ってることを押しつけようとする – プロセスで作り込む、を誤解して、プロセスという名の手順とハンコを押しつけようとする » 手順とハンコを標準化と誤解してしまうような文化で、標準化ガーと叫ぶ – 事実で管理する、を誤解して、無根拠のメトリクスを押しつけようとする » 相関が高くなりようがない回帰分析をするために現場に測定を押しつける · ex) レビュー密度と出荷後バグ率 » 7つ道具、特に層別はさせずに管理図を描かせる – 未然防止、を誤解して、教条的ななぜなぜ分析を押しつけようとする » なぜを5つ書かせて工程欠落に誘導し、工程増加かダブルチェックを経て二重帳簿化させる – とにかく自分たちの知ってることと似たことを探したら直交表を見つけたので直交表による組み合わせテストをソフトQAの銀の弾丸だと信じ込む » 直交表による組み合わせテストはソフトQAのごく一部に過ぎない – 見かけ上は全社共通のQMSを持っていることになっているが、実際は固有技術や工程ごとにバラバラのQMSになってしまっている

22. © NISHI, Yasuharu22 製造業のソフト開発部門の品質保証の問題点の例 • ソフトウェアなんて部品の一種だと思う – 出羽守に騙されて本社におかしなリーン化をしてしまい、ソフトハウスの罠にはまる » ソフトウェア開発部隊を子会社化する » ソフトウェア開発部隊をリソースプール化する – 協力会社に丸投げしたが品質が悪くカイゼンの見込みもない » そもそも自社でソフトの技術開発も改善活動もできてないので協力会社の指導ができない » 契約的・金銭的制裁を行うが、ソフトハウスのビジネスモデルを全く理解していないのでダメなエンジニアを寄こされて、もしくは手抜きの仕事をされて、さらに窮地に陥る » 丸投げしてるため調達部門の管轄になっており、カネの付き合いしかできずカイゼン活動をしてもらえない » 自社の仕様も母体の制約や不具合も何もかも協力会社が知っているので、協力会社との関係がズブズブになっている » 実質的にソフトの品質プロセスを協力会社に握られている • 何をやっていいか分からないからひたすら猫の手になり、なんの目的も無いテストという名のチェック作業の手伝いをずっと行う – 「刺身タンポポ」的品質保証になってしまっている

23. © NISHI, Yasuharu23 製造業のソフト開発部門の品質保証の問題点の例 • 品質保証部門が自己矮小化してしまっている – 経営からは生産だけでなく設計もソフトも見ろと言われるが、設計やソフトでの品質管理では結果を出せないので、ひたすら生産の品質管理のやり方を設計やソフトに押しつける – 設計やソフトからは軽んじられ、自分たちは生産の品質管理でこそ輝くとか思ってしまう » 生産の品質あってこその日本のものづくり力だ、とかいう昭和な記事に感情移入してしまう – どう作るかの品質管理はできても、作るべきものがどんな品質を持つべきか、作るべきものがどう変わっていってるのか、そもそも品質ってなんだ、という検討が全くできていないし、する予定もないし、する気もない – だから「過剰品質」という悪口に言い返せない – 会社の体質や組織文化そのものに問題があるが、それは自分たちの仕事では無いと思っている

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

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

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

28. © NISHI, Yasuharu28 ソフトウェア開発部門／ソフトハウスのQAの問題点結局生産と同じだと思ってしまう全社QAの不勉強 or 労働を売るというビジネスエッセンスと下請根性 QAの自己矮小化無根拠型プロセス・メトリクス依存QA ＋＝

30. © NISHI, Yasuharu30 ソフトウェアは物理的実体もばらつきもない • ソフトウェアには「生産」プロセスがない – 実装／コーディング／プログラミングプロセスは、ハードウェアにおける詳細設計プロセスである » 完成したプログラムをCDやROMに焼くプロセスはソフトウェア開発として考慮しない » いわゆる工場メタファによる属人性の排除は幻想である • ソフトウェアは劣化しない – 物理的実体の性質変動を考慮する必要が（あまり）無い » 組込みにおけるハードウェア、エンプラにおけるプラットフォームは必要 • ソフトウェアは物理化学法則に従わない – 不具合の原因は論理性の欠如であり、物理化学法則に対応づかない » 支配法則が異なる：社会学や認知科学的法則、モチベーションが大きく関係する » 故障モードの把握が難しい：ユニットの機能不動作ではない » ファクトコントロールは、データで示すことではなく、論理性の確保である • ソフトウェアには「検査」プロセスがない – 物理的実体のばらつきを公差の範囲内に収めるために、何かの値を測定しある基準値によって振り分けるような、単純作業は無い

31. © NISHI, Yasuharu31 ソフトウェアは複雑である • 規模が大きい – 747の部品点数は600万点(?)、カーナビのステップ数は数百万行 • 協調すべき数・種類が多い – 乗用車に搭載されるECUは数年後に200を超えると言われている – 組込みの場合は、プラットフォームが極めて多様である • 開発人数が多く、開発期間は短い – ある携帯電話は200万ステップで1800人月である • 分割統治原則が必ずしも機能しない – 空間的ないし物理的な分割が不可能である » 例えばOSにメモリ保護などの機能はあるが、不具合の伝播を物理的に食い止めることができない – 性能や省メモリのために、実装の詳細が隠蔽できない場合が少なくない • 論理性が高い – ロジックが入り組んでおり、条件組み合わせが複雑で、並行動作を行う – バグはフェーズを経るごとに指数関数的に増加していく

32. © NISHI, Yasuharu32 ソフトウェアは開発しにくい • 確立した開発方法論が無い – 構造化分析／設計、状態遷移設計、オブジェクト指向、アジャイル開発．．．？ – いわゆるSQC（統計的品質管理）手法はほぼ全く適用できない • 要求が曖昧で記述しにくく、かつ変化してしまう – 暗黙の要求や「使ってみて始めて分かる」要求が少なくない – ビジネスのスピードが速くなり、ソフトは簡単に追加・変更できると思われている • 再利用が難しい – 再利用に最適な機能分割・構造分割・粒度設定が難しい – 開発技術やプラットフォームがどんどん変化する – もともと再利用を想定していない成果物をベースに再利用しようとする – 再利用しやすい標準部品を使うと、競争力は無くなっていく？ • 品質が低く、性能が予測しにくい部品が多い – 部品の受け入れテストや部品との組み合わせテスト、個々の部品向けのパッチコードが必要となる – 品質保証されていない「オープンソース」を使う場合も増えてきている

33. © NISHI, Yasuharu33 「ソフトウェア」品質保証が誤解している点 • 見習うべきはハードウェアの設計工程であり、大量生産工程ではない – ハードの設計工程は基本的に一品ものであり、派生開発である – ハードの設計工程でも定量的管理は夢見ているほど上手くいかない – ハードの設計も作業標準どおりにやれば上手くいく世界ではない – ハードの設計も品質が低い部品やプラットフォームを使わざるを得ないことはある – ハードの設計でも設計ミスなどの人間の誤りは発生する – ハードの設計でも大規模な製品はあるし、協力会社もオフショアも活用する – ハードの設計でも製品企画の段階から要求が固まっていることなど無い – ハードの設計でもほんの小さな設計ミスが大きな影響を及ぼすこともある • 大事なことは、 TQMが培ってきた知恵を原理原則まで分解して再構成しソフトウェアに適用することであり、 TQMの技法をそのまま劣化コピーすることではない

34. © NISHI, Yasuharu34 日本のソフトウェア産業構造の特徴 • 多重下請け構造のため誰が責任を取るのか分かりにくい – 請負契約が多いため、不具合を作り込んで修正する工数でもオカネがもらえるので、品質や技術力を上げるインセンティブが働かない • セットメーカやSIerが技術力を失ってきている – セットメーカやSIer、高次請けが工数管理しかしない（できない）ため、協力会社に対する技術指導をできなくなってきている – セットメーカが自社のソフトウェア開発部門を企画機能を残して子会社化・売却してしまい、ソフトウェア由来の革新的進化もソフトウェア起因のトラブル解決もできなくなっている • ソフトハウスも技術力を失ってきている – もらった仕様書をプログラミング言語に翻訳するのが仕事だと思っているソフトハウスも多い – 自社での技術向上や教育を行っているソフトハウスは驚くほど少ない – 価格ではなく技術力で海外を選ぶケースも増えてきている

36. © NISHI, Yasuharu36 ソフト開発部門／ソフトハウスには品質保証戦略の立案が必要 • いきなり自組織の問題点を洗い出そうとするとどうなるか – それはそうなんだけど、これではにっちもさっちもいかない » 「PCが遅いです」 » 「窓やトイレが汚いです」 » 「残業が多いです」 » 「給料が安いです」 » 「なんかみんな幸せそうに見えません」 • 品質保証戦略の立案が必要になる – ビジネスエッセンスの見直し – 経営に対して寄与する品質の把握：品質コンセプトパッケージング – 経営に対する品質の寄与の把握：品質ポジション分析 – 問題構造の分析とアクティビティの設計 – 伝播戦略の立案 • 品質保証戦略を練るために頭数は必要ない – QAに人を割いてもらえない、というグチは必要ない

37. © NISHI, Yasuharu37 品質保証戦略でないもの • そもそも品質（保証）に戦略などない – 「うちはみんな常駐なので、全社としてのQA戦略なんて考えようがないのですよ」 • それは品質ではない – 「そもそも営業が無理な案件を受注していたのが品質低下の原因なので、案件受注審査を厳しくするというのがQA戦略です」 • スローガン – 「品質こそ我が社のブランド、というのがQA戦略です」 • 目標数値 – 「5年で品質を倍にする、のがQA戦略です」 • 組織構造・体制図・権限 – 「これがISO9000用に描いた体制図で、QA戦略を表しています」 – 「品質保証部の地位や発言力の向上です」 • 機能を並べたもの – 「プロセス改善、レビュー、テスト、メトリクスがQA戦略の軸です」 • 単なる取り組みの列挙 – 「XDDPとHAYST法とAutomotive SPICEがQA戦略の構成要素です」 • 個別の取り組み – 「不具合率算出の精度向上のために○△分析をすることにしました」

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

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

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

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

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

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

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

45. © NISHI, Yasuharu45 品質ポジション分析：品質マネタイズ分析 • そもそも、「質」にカネを払いたいドメインで、もしくは「質」にカネを払いたいお客様と仕事をしなければ、「質」を高めるインセンティブは働かない – しかしそのドメインやお客様がカネを払いたい「質」というのは、結果的側面だけとは限らない – そこで品質マネタイズ分析を行い、「質」にカネを払いたいドメインやお客様なのかを判断する • まず、ドメインやお客様に提供容易な「質」と提供困難な「質」に分ける – 提供容易な「質」： » 結果的側面、価値的側面 – 提供困難な「質」： » 思考様式的側面、行動様式的側面、内部的技術的側面、組織的側面、人間的側面

46. © NISHI, Yasuharu46 品質ポジション分析：品質マネタイズ分析 • 次に、ドメインやお客様が「質」にカネを払いたいかどうかを判定し、自分たちの品質保証戦略の方向性を決める – 払いたい → 自分たちが直接的に「質」の向上に投資する – 払いたくない → 1) “提供容易な「質」”をカネに換えるロジックを探し当てて、直接的に「質」の向上に投資する例）高品質をブランドとして高単価を提示するために投資する → 2) “提供困難な「質」”をカネに換えるロジックを探し当てて、直接的に「質」の向上に投資する例）行動様式的側面の販売：カイゼン力を売るために投資する例）内部的技術的側面の販売：バグパターンを売るために投資する → 3) 「質」以外にお客様がカネを払う特性へのロジックを探し当て、間接的に「質」の向上に投資する例）スピード向上を販売するために、自社のカイゼンに投資する • 品質保証部長は「質」の向上に投資してもらうために、ロジックの意味やつながりを投資元（お客様や自社の経営陣）にきちんと説明し納得感を得なければいけない

47. © NISHI, Yasuharu47 品質ポジション分析：品質ファイブフォース分析 • お客様が「質」にカネを払ってくれるとしても、「質」に対する投資が実を結びやすいドメインやお客様と、そうでないところがある – 「質」の向上を促進するドメイン（やお客様）なのかどうかは、少なくとも5つの要素の相互作用によって成り立っている » お客様がカネを払ってくれないところは「質」の向上がやりにくい » 「質」向上の技術を獲得しにくいところは「質」の向上がやりにくい » 多くの開発技術を必要とするところは「質」の向上がやりにくい » 開発技術の革新が激しいところは「質」の向上がやりにくい » 「質」以外の価値を重視するところは「質」の向上がやりにくい – そこで品質ファイブフォース分析を行い、「質」に対する投資が実を結びやすいドメインやお客様かどうかを判断する » 「質」に対する投資が実を結ぶかどうかを、「質」向上技術が開発技術との“競争”に勝利する、と捉える – 品質ファイブフォース分析は、「質」に対する投資が実を結びにくいドメインやお客様に品質マネタイズ分析ほど明確な戦略的指針を提示できないのが弱みである » 品質マネタイズの強化や、コミュニティの活性化、「待ち」といった感じになってしまう

48. © NISHI, Yasuharu48 品質ポジション分析：品質ファイブフォース分析 • 「質」の向上を促進するファイブフォース – 顧客が「質」を高く買ってくれるか » お客様がカネを払ってくれるところは「質」の向上がやりやすい » ポーターモデルにおける買い手 – 「質」向上技術の獲得容易度 » 「質」向上の技術を獲得しやすいところは「質」の向上がやりやすい · フレームワーク、標準、コンサルタント、学術成果物、コミュニティが活発なところはやりやすい » ポーターモデルにおける供給業者 – 開発技術の数や難易度 » 開発技術が少ないところは「質」の向上がやりやすい · 状態遷移図とC言語でガリガリ作っているだけのところは相対的にやりやすい » ポーターモデルにおける競争業者（直接競合） – 開発技術の革新度 » 開発技術が枯れているところは「質」の向上がやりやすい · 最先端のWebサービスは相対的にやりにくい » ポーターモデルにおける新規参入業者 – 「質」以外の特性（スピードなど）をお客様が重視するか » 「質」以外の価値を重視しないところは「質」の向上がやりやすい · リリーススピードが命のところは相対的にやりにくい » ポーターモデルにおける代替品（間接競合）

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

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

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

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

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

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

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

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

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

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

59. © NISHI, Yasuharu59 カイゼンとイノベーション • カイゼンとイノベーションは対立するものか？ – 欧米かぶれの経営者や管理者は対立すると言ったりする – 現場でしっかりカイゼンしている技術者や管理者は対立すると感じない » 両方とも「変化」であり、その種類が異なるだけ » 対立すると言う人の多くは、改善の範囲が小さくイノベーションを銀の弾丸だと考えている • カイゼンとイノベーションを両立する組織が良い組織 – カイゼンは既存ベース、イノベーションはゼロベース » 変化の結果が目標を超えられるのならカイゼンでよく、超えられないのならイノベーションにトライする · ゼロベース思考は確かにコツが必要なので、両者をバランスよくできる必要がある » いつでもイノベーションにトライできるように「仕込み」が必要 · 技術調査、可能性検討、小規模トライアル、社内情報交換など » カイゼンでもイノベーションでもビジョンが必要 – カイゼンはイノベーションのトレーニングでもある » カイゼンしない個人／組織は変化そのものを怖れるのでイノベーションなどできない » 変化するためには自分の技術の確立が必要：論文執筆などで自分の軸を定めていく » カイゼンできない組織は単に自己矮小化しているだけである

60. © NISHI, Yasuharu60 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

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

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

64. © NISHI, Yasuharu64 QA観点モデル：何の質を保証すればよいのか？ • IoT化における品質保証とはなにか？ – 結局ものづくりなのだから品質保証は不変であるのでいままでと同じことをすればよい、というのは自己矮小化に基づく誤解である • IoT特有の固有技術や品質特性だけでなく、 UXやユーザ感情、SDLにまで広げなくてはならない – IoT特有の固有技術や品質特性を考える必要がある » ソフトウェア、ネットワーク » セキュリティ・プライバシー、相互接続性 » ビッグデータ、AI／ディープラーニング – UX（ユーザエクスペリエンス）やユーザ感情にまで品質保証の扱う範囲を広げなくてはならない – プラットフォーム化や顧客共創／SDL（サービスドミナントロジック）といったビジネスの質にまで品質管理の扱う範囲を広げなくてはならない • そのために組織のアジリティやスピード化、自己変化頻度・速度、改革性も高めねばならない – IoT化に合った品質コンセプトの改善・再構築が必要となる

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

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

67. © NISHI, Yasuharu67 アシュアランスフロー • アシュアランスフローとは、どのQA観点をどの工程でどのように作り込み、どの工程でどのように検証したかを記述したものである – QA観点ごとにアシュアランスフローとメカニズムを明らかにして、その観点の品質保証を確実にしていく » どう作り込むか／入り込んでしまうか、どう検証するか、のメカニズムを明らかにする » 工程ごとの作業内容や採用技術、帳票の形式、ツールの選定などがすべてアシュアランスメカニズムに基づいたものになると、意図不明な作業の押しつけによるやらされ感が低減し、プロセスメトリクスが機能するようになってくる工程P1 QA観点V （作り込み）工程P2 QA観点V （検証）

68. © NISHI, Yasuharu68 アシュアランスパイプライン • アシュアランスパイプライン上で工程とアシュアランスフローを整理し、メカニズムがきちんと機能しているかを測定して管理し、プロセスをカイゼンしていく – 自動化によって個々のフロー要素を短縮し、パイプラインをスピードアップする – アシュアラビリティ・デザインを行って検証側のフロー要素を短縮する – フロントローディングによって作り込み側のフロー要素を短縮する／無くす – フロントローディングによってフローの拡散を防ぎ、全体の工数を減らす – 以上のようなことが可能になるように、工程へのQAフローの割り付けをきちんと設計する

69. © NISHI, Yasuharu69 テックシェルフ（技術の棚） • アシュアランスパイプラインを支える技術のマネジメントにも QAは大きく関わらなくてはならない – プロセスは手順だけではなく、技法や方法論もツールも含まなくてはならない • ドメイン技術、要素技術、エンジニアリング技術、マネジメント技術と QA観点との組み合わせと抽象具体の関係で表現することができる – 「お勉強」の証明ではなく、自分たちで試してみて上手くいったものを棚に載せる • ポジティブナレッジとネガティブナレッジのバランスを取る – ネガティブナレッジは多く場合開発者は好きではないので、 QA部門が積極的に抽出・蓄積しないときちんと貯まらない • バッドノウハウだけでなくグッドノウハウを貯めるようにする – バッドノウハウは通常「業務知識」として自然に伝承されるが、その製品や部品、プラットフォームが変わると不要になる » 気をつけないとテックシェルフがバッドノウハウだらけになるが、それは技術力が低いということを意味する – グッドノウハウは多くの場合、一般的原理と支配法則に分けられる » グッドノウハウから支配法則を分離できると、統合型QMSに必要なテックシェルフに近づく » RCAやバグ／故障解析はテックシェルフの構築に重要だが、その支配法則に詳しくない分析者はたとえ分析経験が豊富でも曖昧な分析をしてしまうが見抜くのは難しい

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

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

72. © NISHI, Yasuharu72 ポジティブナレッジ×グッドノウハウの例：富士通の７つの設計原理 ①単純原理 - 可能な限りシンプルにすること ②同型原理 - 同じものは同じように実現すること - 例外を設けないこと ③対称原理 - 対称にすること - 対になるものは対にすること - バランスを崩さないこと ④階層原理 - 階層関係、主従関係、前後関係、本末関係などを崩さないこと - 層に穴を空けないこと ⑤線形原理 - 特異点や閾値、組み合わせによる特殊な振る舞いが無いこと ⑥明証原理 - ロジックは直感的に分かりやすくすること - 分からないものやふるまいがないこと - おかしなものを受け取らない、先に送らない、無視しない、勝手に処理しないこと ⑦安全原理 - 必然性のないところや曖昧なところは安全サイドに設計しておくこと

73. © NISHI, Yasuharu73 ネガディブナレッジ×グッドノウハウの例：不具合モード分析 • ピンポイント型（検出型）V&Vや探索的V&Vでは、バグを分析してパターン化することが技術的基盤となる – しかしバグ分析を上手にできている組織は意外に少ない » 何かしらの分析結果は出るが、役に立たせることができない » そもそも現象なのか原因なのかなど、何を分析しているか分かっていない場合も多い » 責任追求型の裁判的犯人捜しの分析会議は隠蔽を生むだけで何もメリットは無い – バグ分析が下手な組織は、なぜなぜ分析やRCA（根本原因分析）も下手である – 同様にFMEAやFTAも下手である » 特にソフトの故障モードをきちんと理解して分析し蓄積している組織はとても少ない · 故障モードが蓄積できていないと、DRBFMは変化点解析に成り下がってしまう » モジュールの機能不動作・誤動作を故障モードと捉えても上手にパターン化はできない · 演算間違いや遅延という故障モードは役立つバグのパターンではない – バグのパターンをフィードバックしてフロントローディングして開発プロセスを改善したり、教育組織に展開して教育コンテンツを改善する必要がある • 不具合が作り込まれやすい仕様・設計・コードのパターンをきちんと分析して蓄積する技術を確立する必要がある – 不具合が作り込まれやすいコードのパターンはMISRA-Cなどから得られる » 設計のパターンの蓄積は設計力に依存し、仕様のパターンの蓄積はより難しい

74. © NISHI, Yasuharu74 ネガディブナレッジ×グッドノウハウの例：不具合モード分析 • 不具合が作り込まれそうな「弱点」を特定するように、よく発生する過去のバグを分析しパターン化すると、ソフトウェア開発のための質のよい故障モードが得られる – 当該工程だけでなく、後工程でバグを作り込む原因となりうる部分もパターン化する • 開発者がどう間違えるかに着目して開発者が陥りやすい「罠」をパターン化する – 人間の思考の誤謬と、誤謬を引き起こしやすいパターンをセットで明らかにする » 例）後から追加された例外的な仕様は、設計漏れを引き起こしやすい » 例）優先順位の表現で1（高い）～5（低い）と5（高い）～1（低い）が混在すると混同しやすい » 例）異なるサブシステムでリソースの確保・解放を行うとリークしやすい » 例）「備考」にはバグが多い – 似たようなパターンのバリエーションをツリー状に整理する • 「共感」を軸にしてバグの分析を行う – 適切なパターン化ができた瞬間は、分析会議の参加者が「その罠にはみんなひっかかるよね」と共感するようになる – バグを作り込んだ人という扱いではなく、罠の情報を提供してくれる人として尊敬を前面に出すと、前向きの会議になって共感しやすくなる

75. © NISHI, Yasuharu75 不具合モードで頻発する不具合を未然防止する • 派生開発・SPLEでは特定の種類のバグが派生品をまたいで、かつ異なる機能で頻発することがある – 母体や開発プロセスに不具合モードもしくは不具合モードの芽があるため、派生品を開発する度にバグを作り込んでしまう » 不具合モード「例外」：法規対応、多仕向地、機能複合型製品 » 母体の設計にそもそも難がある » 仕様書群の構造そのものに不具合モードがあったりもする – 母体の不具合モードに着目してテストを設計したり、最初から気をつけて開発することで頻発バグを効率的に防ぐことができる

76. © NISHI, Yasuharu76 ネガディブナレッジ×グッドノウハウの例：ソフトウェアHAZOPのためのより詳しいガイドワード強度強い弱い時期早く遅く数量多い少ない時間長く短く増加減少間隔広く狭く余分不足期間長く短くあるないゼロ順序さきにあとで種類多種小種同時に並行に規模大きい小さい早く遅く距離遠い近い逆転反復挿入速度速い遅いタイミング早く遅く高速低速拡張広く狭く緩急多く少なく設定許容禁止頻度多く少なく必須任意高く低く範囲長い短い程度いつもたまに上限下限回数多く少なく広い狭い接続つなぐ切り離し切り替え最大限最小限方向上へ下へ頻度高い低い負荷高い低い多い少ない超過不足限界金額大きい小さい位置高く低く遠く近く鈴木三紀夫さん（リコーITソリューションズ）、秋山浩一さん（富士ゼロックス）がご作成

77. © NISHI, Yasuharu77 ネガディブナレッジ×グッドノウハウの例：ソフトウェアHAZOPのためのより詳しいガイドワード原則例外正常異常準正常全体部分通常非通常全部一部通常例外代替主従定期臨時正誤通例異例常例無事有事平時非常時緊急時公正不正定常可変任意強制尋常非常基本詳細主要一般特別完了未完普通特殊有効無効並特異起動停止鈴木三紀夫さん（リコーITソリューションズ）、秋山浩一さん（富士ゼロックス）がご作成

79. © NISHI, Yasuharu79 不具合分析のアンチパターンと効果の薄い対策 • Vaporization（その場限りの簡単なミスとして片付けてしまう） – コーディングミス：スキルを向上させるよう教育を行う – 考慮不足：しっかり考慮したかどうかレビュー時間を増やし確認する – うっかりミス：うっかりしていないかどうかレビュー時間を増やし確認する • Exhaustion（不完全な実施や単なる不足を原因としてしまう） – しっかりやらない：しっかりやったかどうかレビュー時間を増やし確認する – スキル不足：スキルを向上させるよう教育を行う – 経験不足：経験を補うためにスキルを向上させるよう教育を行う • Escalation（上位層に責任を転嫁してしまう） – マネジメントの責任：トップを含めた品質文化を醸成する • Imposition（外部組織に責任を転嫁してしまう） – パートナー企業の責任：パートナー企業を含めた品質文化を醸成する • Culturalization（文化的問題に帰着してしまう） – 品質意識／品質文化の欠如：全社的な品質文化を醸成する

81. © NISHI, Yasuharu81 ソフトウェアの品質管理の基本的アクティビティの概要 • プロセスサイドの主なアクティビティ – 品質戦略の立案と推進 – 開発プロセスの構築・評価・改善 – リスクマネジメント • プロダクトサイドの主なアクティビティ – 測定・メトリクス – V&V（レビュー・テスト） – バグの分析

82. © NISHI, Yasuharu82 開発プロセス評価・改善 • ソフトウェアプロセス改善（SPI）には、実態駆動型改善とモデル駆動型改善がある – 実態駆動型改善：実際の問題を解決し続ける改善スタイル – モデル駆動型改善：モデルとの差異を埋める改善スタイル » 例）CMM/CMMi、ISO/IEC15504/33Ks/AutomotiveSPICE、ISO9000s？ • 実態駆動型改善を適切に進めるには、問題を適切に捉えて改善するという能力が必要 – PDCAやDMAIC、KPTなどの改善サイクルがあると進めやすい • モデル駆動型改善には注意が必要 – 改善モデルを軸に、あるべき姿と現状とのギャップ分析を行い、そのギャップを埋めるように達成度を定め改善していく方法 » PRM（プロセス参照モデル）にPAM（プロセス評価モデル）を組み合わせて改善する » モデルに近づけるのが改善だ、というのがモデル駆動型改善の基本思想であるので改善を進めても現場の問題が解決されない罠に陥りやすい – レベル５が継続的改善のスタートであり、レベル３はかえって硬直化を招きやすい » 定義したプロセスをずっと続けるという思想は監査的でありTQM的ではない

83. © NISHI, Yasuharu83 Software Engineering -83- PAM／プロセス成熟度レベル（SW-CMMの例） • レベル１（初期レベル） – プロセスが管理状態に達していない段階 • レベル２（反復可能レベル） – 厳格なプロジェクト管理を行うことにより、類似のプロジェクトを反復できる安定したプロセスに達している段階 • レベル３（定義されたレベル）ＩＳＯ９０００相当 – 組織としてソフトウェアのプロセスが定義されている段階 • レベル４（管理されたレベル） – ソフトウェア組織が包括的にプロセスを測定・分析できる段階 • レベル５（最適化するレベル） – プロセスの永続的な改善と最適化の基盤ができている段階

84. © NISHI, Yasuharu84 ソフトウェアの品質管理の基本的アクティビティ • プロセスサイドの主なアクティビティ – 品質戦略の立案と推進 – 開発プロセスの構築・評価・改善 – リスクマネジメント • プロダクトサイドの主なアクティビティ – 測定・メトリクス – V&V（レビュー・テスト） – バグの分析

85. © NISHI, Yasuharu85 測定・メトリクス • 「計測できないものは制御できない」（ケルビン卿） – 本当にこう言ったのか？これはソフトウェア開発でも正しい示唆なのか？ – ソフトウェアは基本的に計測できないのに、どうすればいいのだろう？ » 生産性のように定義がはっきりしないメトリクスを測ろうとして不幸になる組織すらある – 統計的推測をしようとするとプロセスが固定化し改善を阻み形骸化することが多い • 自組織の開発のメカニズムに合ったメトリクスを使うべきである – ソフトウェアのメトリクスには、大きく分けて3種類ある » （経営的要求に合わせて）何も考えずに測定した結果系のメトリクス · 全体のバグ率や生産性など » 実測したデータに合うように統計式を作ったメトリクス · 式の中に何乗とか妙な項がある » ソフトウェア開発のメカニズムに合わせて（を仮定して）統計式を作ったメトリクス · バグのパターンごとの出現率と対策コスト、手戻り率（直行率）など – 誰か他の人が考えたメトリクスがそのまま自組織に適用できることはほぼ無い » もし適用できるとしても、調整項の効果の方が大きかったりする – GQM：Goal-Question-Metrics（意図－質問－メトリクス）のようにメトリクスの意図やメトリクスの表すメカニズムをきちんと考える必要がある » すなわち、外部で定義されたメトリクスを探し回るよりも、自組織で何が起きているか、何が問題でどう解決しようとしてるのかを、トコトン考える方が先でありはるかに実り多い

86. © NISHI, Yasuharu86 V&V • レビューやテストなど、プロダクトサイドの品質評価を V&V（Verification & Validation）と呼ぶ – V&Vは主に、レビューとテストから構成される – V&Vは主に、バグなどの要改善点を見つけるのが目的である » レビューという活動自体にV&V以外の目的を与えている組織がほとんどではある – 基本的には、プログラムを実行して行うのがテストであり、実行せずに行うのがレビューである » プログラムを実行しないものも静的テストと呼ばれたり、テスト設計時にバグを見つけることもあるので、厳密な境界線ではない

87. © NISHI, Yasuharu87 V&Vの大事な考え方：V&Vの違い・網羅とピンポイント • VerificationとValidationの違い – Verificationは入力成果物と出力成果物の一致確認であり、 Validationは目的達成評価である • 網羅とピンポイント／保証型と検出型 – V&Vには網羅とピンポイントという2つの相反する目標がある » 2つの相反する目標のバランスを取るのがとても重要である – 網羅とは、V&Vしなければバグは見つからないという考え方の基に、漏れなくV&Vを行うことで動作実績を積み上げる「保証型」のV&Vである » 何も考えずにひたすらV&Vに時間を費やすことは、網羅とは呼ばない – ピンポイントとは、全てはV&Vできないので大事なところから行うという考え方の基に、少ない手間でたくさん危険なバグを検出する「検出型」のV&Vである » バグの多そうなところや、大事そうなところからV&Vを行う

88. © NISHI, Yasuharu88 V&Vの大事な考え方：V&V観点によるV&Vの設計 • V&V観点 – V&Vは、ただひたすら読み込んでレビューしたり片っ端からテストするのではなく、何かに着目して網羅したり、何かをピンポイントで狙ったりする » 網羅したいものやピンポイントで狙いたいもののことを「V&V観点」と呼ぶ – V&V観点は、個々のV&Vケースの意図を示している » V&Vケースとは、レビューケース（レビューの指摘項目）やテストケースのことである » V&V観点の不明なレビューやテストは、意図の分からないレビューやテストになるため、往々にして時間がかかる割に意味の無いV&Vになる – V&V観点をきちんと列挙したりモデリングすることが、モダンなV&Vでは必須である » ダメなレビューチェックリストはV&V観点が不明だったり偏っていることが多い » V&V観点の粒度や関係を適切に把握することも大事である – V&V観点をベースにしてV&Vの設計を行うと改善しやすい » テスト（ケース）の設計はよく知られているが、レビューケース（レビューの指摘項目）の設計も重要である · レビューケース設計のガイドとしてのチェックリストの設計も同様に重要である » レビュー設計に着目せずにレビューを改善すると、会議術の改善以上にはならない

89. © NISHI, Yasuharu89 V&Vの大事な考え方：探索 • 探索的V&V – 事前にV&V観点を明示するのではなく、V&Vを行いながらV&V観点を明らかにしていくV&Vを、探索的V&Vと呼ぶ » 担当者の経験やセンス、勘に大きく依存するので、限られた人でしか効果を発揮しない » 大まかな狙いを「チャーター」として与えるとよい – 暗黙的ないし動的なV&V観点を狙っているため、事後のV&V観点のリバースによって改善につなげることが大事である » 経験から得られた暗黙的なバグのパターンを狙っている場合や、インタビュー時のレビュイーの反応や実行時のおかしなプログラムのふるまいから推理する場合などがある » 探索的V&Vを行った後でV&V観点のリバースを行い、フィードバックしてフロントローディングすることで、 V&Vや開発全体の改善につなげる必要がある – 何も考えずに丸投げで行うV&Vは、決して探索的V&Vではない

ソフトウェアの品質保証の基礎とこれから

ソフトウェアの品質保証の基礎とこれから

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(7)

Similar to ソフトウェアの品質保証の基礎とこれから

Similar to ソフトウェアの品質保証の基礎とこれから(20)

More from Yasuharu Nishi

More from Yasuharu Nishi(17)

ソフトウェアの品質保証の基礎とこれから