Re-collection of embedded software qa in the last decade
Report
Share
•8 likes•5,302 views
Re-collection of embedded software qa in the last decade
•8 likes•5,302 views
Report
Share
Download to read offline
JaSST東海2020の基調講演のスライドです。 この10年間の日本の組込みソフトウェアの品質保証を振り返り、次の10年間できちんと進化していくために再構成を試みます。それによって、見たこともない新しいものに変化するのではなく、過去に乗り越えてきたハードルが形を変えて訪れてきたに過ぎないことを示すとともに、どのようにハードルを乗り越え新しいものに変化していくかの考え方を提示します。そして派生開発の名を借りた技術的負債増加型開発による「手が回らないQA」から、継続的カイゼンによる現場力向上という右利きのQAと、デジタルトランスフォーメーションによる左利きのQAとを同時に実現する「両利きのQA」に脱却できるヒントを、QualiTraxというフレームワークを用いて例示します。
More Related Content
What's hot
What's hot(20)
Similar to Re-collection of embedded software qa in the last decade
Similar to Re-collection of embedded software qa in the last decade(20)
More from Yasuharu Nishi
More from Yasuharu Nishi(9)
Re-collection of embedded software qa in the last decade
- 1. Re-collection of embedded software QA in the last decade 2020/10/16（金） ソフトウェアテストシンポジウム（JaSST）東海 2020 西 康晴 電気通信大学 大学院情報理工学研究科 情報学専攻 経営・社会情報学プログラム @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) • Chair: – JIS Drafting Committee on Software Review Process (based on ISO/IEC 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) • Steering Committee Chair – QA4AI Consortium • Advisor: – Software Testing Automation Research group (STAR) © NISHI, Yasuharup.2
- 4. 11年前を“Recollect”して（思い出して）みると… • 説明責任 – テストとは、ステークホルダーに 製品やシステムの価値を説明することである – そのためには、以下のことを説明できないといけない • テストの意図（テスト観点）のモデリング • テストアーキテクチャの設計 • 持続的革新 – テストとは、開発組織やテスト組織の能力を 持続的に革新するための作業である – そのためには、以下の能力を備えていないといけない • バグの分析によるフロントローディング • 技術の徹底／丸投げ感の排除 • 既存技術のカイゼン／新規技術の獲得とパラダイムシフト • さまざまな融合 • 向上能力の維持・向上 © NISHI, Yasuharu 4
- 7. 何をすればいいのか、分からない時代になった • VUCAな時代になったのは実感している – Volatile（不安定）、Uncertain（不確か）、Complex（複雑）、Ambiguous（曖昧） • DXの波がやってきた気はする – ビジネスモデルと強みの源泉がガラッと変わってしまう技術変化が訪れた – 今までも似たようなブームはあったが、ついに政府まで「デジタル庁」だのと騒ぐ時代になった • イマドキパラダイムが多くてついていけない – CASE、MaaS、製造業のサービス化、DX、デジタルツイン、Industrie4.0、Society5.0、エコシステム、顧客共創、 シェアリングエコノミー、IoT、xTech、ビッグデータ、AI/機械学習/ディープラーニング、VR/AR、クラウド、コンテナ化、 サブスクリプション化、レジリエンス、オープンイノベーション、技術の民主化、プラットフォーム化… • 変化とスピードが新しく競争力を左右する時代になった – 自分たちでコントロールできない要素が重要になってきた • セキュリティ、OSS、AI、OTA（組み込みシステムの運用中／稼働中のアップデート） – スピードが重視されるようになってきた • OTA、DevOpsやCI/CD、モジュラー開発化 • 今までの開発のやり方ではダメなことは分かっている – 派生開発に名を借りた技術的負債増加型開発 – ソフト子会社／出入りのソフトハウス／オフショアへの丸投げ無責任型開発 – しかし自組織に「開発のあり方」を考え抜く人がいないので、これからも同じな気がしている © NISHI, Yasuharu 7
- 9. 技術は、振り子です • 技術は適用され、弱点を見つけられ、そこを乗り越えて進化していく – 例） 部門内系列型開発 → プロジェクト型開発 → チーム重視開発（アジャイル開発） → ？ – アジャイル開発 vs. ウォーターフォール開発は、どのような振り子なのか？ • 早く試して直す vs. しっかり考えておく • 小さく単純に保つ vs. 複雑さを可視化して俯瞰して整理する • コミュニケーションの密度と質を高める vs. コミュニケーションのパスを整理してムダや混乱を防ぐ • 銀の弾丸は無い – 振り子の端やある一点が正解ということはありえない • 上手くやっている組織は、自分たちなりのちょうどよい振り幅で振り子をマネジメントしている – とはいえ振り子が振れる度に技術はスパイラルアップするので、 きちんと付いていく必要があるし、一度通過したからもうやらなくてよいわけではない • 動き続ける振り子を追ってばかりいると、技術酔いを起こし、催眠にかかってしまう – 振り子を追ってばかりいる「テクノロジードランカー」は、 エセ専門家の「○○は××と全く違う」「○○さえあればいい」という甘言に易々と騙される • 「シックスシグマはTQCと全く違う」「（機能）安全は品質保証と全然違う」… • 「USDMとXDDPさえあれば大丈夫」「TDDとCIとテストピラミッドさえあれば大丈夫」… – その結果、技術間に分断を起こし、組織をサイロ化させ硬直させ、 組織全体の技術進化力を衰退させる • ちゃんとした専門家は、振り子の両方をきちんと提示している © NISHI, Yasuharu 9
- 11. 「後の先」 • 「後の先」とは – 相撲の立ち合いで「相手より一瞬遅れて立つように見えながら先手を取」る極意（双葉山のWikipedia） • 本来は剣術などにおける返し技（ボクシングにおけるカウンター）の意味らしい – 相手をよく見ることと、遅れて立ったのに先手を取れる俊敏さ、それらを支える日頃の鍛錬が必要 • 特にVUCAな時代では、QAは開発に対して「後の先」で臨むのが理想である – 「後の先」：開発が新しい技術や開発手法や価値などを採り入れたら、すぐにそのQAの技術やプロセスを確立する • 開発がいまどういう状態で、何を目指そうとしていて、何ができていて何ができていないのか、をよく見る • 開発が採り入れた技術や開発手法や価値について、俊敏に把握してQAの技術やプロセスを確立する • 開発が何を目指すべきか、何を採り入れるべきか、その時に何が問題になりそうか、を 日頃からアンテナを立てて情報を収集し、QAとしての技術やプロセスを研究開発しておく – 技術が振り子であるならば、次に何が重要になるかは推測しやすい • QAの技術の振り子はさらに、開発技術の振り子の後を追うことになる – 「先の先」（開発に「こんな技術や価値があるよ」と提案するQA）はもちろん悪くないが、あまり現実的ではないかも… • もし日本人がオリジナルが苦手で真似が得意というなら、「後の先」戦略は得意なはずである • しかし実際の品質保証組織は、開発が新しいことを取り入れたのに… – 「後の後」： QAが追いつかないから責任あるリリースができない – 「後の不」： QAはそれを理解できず適用できず開発に丸投げする – 「後の無」： QAは今まで通りでいいと知らぬ顔を決め込み硬直化しサイロ化する © NISHI, Yasuharu 11
- 13. （組込みの）ソフトウェアQAは、両利きでなくてはいけません • 両利きとは？ – これまでのパラダイムでの仕事を「右利き」と呼ぶこととする • 慣れた仕事、改善による仕事の深化… – DXを始めとしたイマドキパラダイムでの仕事を「左利き」と呼ぶこととする • 慣れない考え方、新しい技術による仕事の探索… • 「左利きは素晴らしい」「これからは左利きの時代だ」「左利きファースト」… • （製造業は）両利きでなければならない時代になった – VUCAな世界で変化とスピードが新しく競争力を左右する時代になったので、 左利きのイマドキパラダイムのビジネスに順応しないと勝てない • 新しいライバルが左利きの技術を携えて、左利きの世界からやってきて我々をdisruptしてくる – しかし、従来の競争力も高めなければ、従来のからの競合相手に敗退してしまう • 10年後にdisruptされる前に、今々国内や欧米、新興国との競争に勝たなければならない • （組込みの）ソフトウェアQAも、両利きにならなくてはいけない – 左利きの技術や価値のQAが必要になるのは当然である – しかし左利きのQAをきちんと行うためには、右利きのQAがきちんとできていることが必要になる • 組込みでもクラウドでも、 左利きにばかり気を取られて右利きが疎かになっている組織が実は多くある • アジャイルになりさえすれば、TDDをやりさえすれば、CI/CDをやりさえすれば幸せになれる、 ほどソフトウェアQAは甘くない © NISHI, Yasuharu 13
- 15. どんなテストをしているのか、説明できますか？ • 右利きのQAは、どんなQAをしているのかを説明でき、 その通りにきちんと遂行するQAである – 何を意図したQAを、どんな開発成果物に対して、 いつ、どのくらい、行っているのかを俯瞰して説明できますか？ • テスト観点 / テストアーキテクチャ / QAアーキテクチャ – 左利きしかできない組織には、バックログCPM法やエセゆもつよマトリックス、探索的テスト信仰が多い – どんなバグが、何を原因として発生していて、 いつ、何をすれば、その種のバグを予防できるのかを説明できますか？ • バグやトラップのパターン化によるフロントローディング – 左利きしかできない組織には、バグの分析が苦手で振り返りが表面的な組織が多い – 左利きしかできない組織の探索的テストは、ただ何となくいじっているだけだったりする • 右利きのQAが得意な組織やエンジニアは、 よいミッションとマインドセットを身につけており、QA内のロールのバランスがよい – 納得感の共感、 サーバントシップ / カイゼンサイクル / ミッションシェア / アップストリーミング / ストーリー化、 QAファンネルによるロールバランスの可視化 • SEA-SIGSQAで議論している • 海外ではモダンテスティングとして議論されている • アジャイルでもウォーターフォールでも、ミッションやマインドセット、ロールのバランスは重要である © NISHI, Yasuharu 15
- 16. テストの意図をテスト観点で表す • テスト観点とテストケースとテストスクリプトをきちんと区別する – テスト観点 • 何をテストするのか（テストケースの意図）のみを端的に記述したもの – 例）正三角形（の場合でテストしたい） – テストケース • そのテスト観点でテストするのに必要な値などのみを特定したもの – 例） (1,1,1), (2,2,2), (3,3,3)… • 何らかのテスト詳細設計モデルに従って、何らかの網羅基準に沿ってテスト値が導出される – 例） 「整数の辺から構成される正三角形」だって立派なモデルである – 例） 状態遷移モデルに従って、1スイッチカバレッジ基準で、状態シーケンスを導出する • テスト詳細設計モデルが複数組み合わさるなど複雑なテストケースが必要なこともある – テストスクリプト（テスト手順） • そのテストケースを実行するために必要な全てが書かれたもの – 例）1. PCを起動する 2. マイコンピュータからC:¥sample¥Myers.exeを起動する… • 手動でのテスト手順書の場合もあれば、自動テストスクリプトの場合もある • 複数のテストケースを集約して一つのテストスクリプトにすることもある • これらを区別し、異なる文書に記述し、 異なる開発工程に割り当てることによって、 テストの意図のみをじっくり検討することができるようになる – テスト観点を基にしてテスト設計をするのは、もう国内では常識になった – きちんとテスト観点をモデリングしてテスト開発を進める方法論にVSTePがある © NISHI, Yasuharup.16 GUI 機能 データ動作環境 プラットフォーム ネットワーク OS ハードウェア OSの種類 OSのバージョン IEのバージョン 電子メール
- 17. テスト観点図によるテスト要求モデリングの例 © NISHI, Yasuharup.17 GUI 機能 データ動作環境 プラットフォーム ネットワーク OS ハードウェア OSの種類 OSのバージョン IEのバージョン 電子メール テストの意図を 俯瞰しながら 整理できる
- 18. テスト観点のモデリングのTips • 仕様書に書いてある仕様や文、単語を書き写してもテスト観点は網羅できない – 仕様書は通常不完全であり（もしくは存在せず）、（特に致命的な）バグは 仕様書に書かれていないテスト観点でしか見つけられないことがある • テスト観点は多面的に挙げる – 入力に関するテスト観点だけを挙げたり、期待結果やその観測に関するテスト観点 だけを挙げたり、品質特性だけをテスト観点として採用すると、漏れが発生する • テスト観点を挙げただけでバグが見つかることがある – 開発者が考慮していなかったテスト観点はバグの温床であり、 テストしなくてもバグだと分かることも多々ある – 期待結果に関するテスト観点を挙げたり詳細化すると、仕様の抜けが分かることがある • テストケースにも期待結果を必ず書くのを忘れないこと • 「正しく動作すること」は期待結果ではない！ • 網羅した風のテスト観点の文書や納品物を作ろうとせず 網羅しようと多面的に様々なことを考え尽くそうとする – あーでもないこーでもないとワイワイ議論したアイデアのリポジトリがテスト観点図である • 見逃したバグを見つけうるテスト観点を気軽に追加して整理することも大事である – 最初から網羅しようと気張ると大事なテスト観点を見逃す • そもそも網羅することが必要なのか？ © NISHI, Yasuharup.18 GUI 機能 データ動作環境 プラットフォーム ネットワーク OS ハードウェア OSの種類 OSのバージョン IEのバージョン 電子メール
- 19. テスト観点のモデリングのTips • 同じテスト観点名を皆が同じように理解しているとは限らない – 子観点が明示すると理解の齟齬は解消しやすい • 観点が通り一遍で関連が多いモデルは理解度が低いことが多い – 不安だから／責任を取りたくないから組み合わせておかなきゃ、と発想していることが多い – なぜその関連をテストすべきだと思ったのか、という掘り下げを行い、 可能なら関連をテスト観点に変換すると、よりテストの意図が明確になる • 詳細化のステレオタイプを明示するとよいモデルをつくりやすい – その親と子はどういう関係なのか、はステレオタイプを明示しないと不明確になりやすい – 異なるステレオタイプの詳細化が混ざっていると網羅しにくい • 抽象度は丁寧に落として（具体化して）いく – 子観点の数は認知的マジックナンバーの範囲内にできるとよい • 網羅できた確信が持てないところにはノートを貼っておく – モデリングの途中では「その他」という一時的なテスト観点を挙げておいてもよい • 後で適切な観点としてきちんとモデリングすること – 抜け落ちの危険性が消失することが一番怖い • 探索的テストにおけるチャーターの記述とテストの（気づいた点の）記録は テスト観点モデルを用いると表現しやすい © NISHI, Yasuharup.19 GUI 機能 データ動作環境 プラットフォーム ネットワーク OS ハードウェア OSの種類 OSのバージョン IEのバージョン 電子メール
- 20. テスト観点モデルのリファインのテクニックの例 • 様々なリファインを何度も行いながら質の高いモデルに向かっていく – 網羅化：MECE分析 • 子観点がMECEに列挙されているかどうかをレビューし、不足している子観点を追加する • MECEにできない場合、必要に応じて「その他」の子観点を追加し非MECEを明示する • 子観点をMECEにできるよう、適切な抽象度の観点を親観点と子観点との間に追加する – 網羅化：ステレオタイプ分析 • MECE性を高めるために、詳細化のステレオタイプを明示し子観点を分類する – 整理 • 読む人によって意味の異なるテスト観点を特定し、名前を変更する • テスト観点や関連の移動、分割、統合、名前の変更、パターンの適用、 観点と関連との変換、観点と網羅基準との変換などを行う • 本当にその関連が必要なのかどうかの精査を行う必要もある – 剪定 • ズームイン・アウト、観点や関連の見直し、網羅基準や組み合わせ基準の緩和によって、 テスト項目数とリスクとのトレードオフを大まかに行う – 確定 • 子観点および関連が全て網羅的に列挙されているかどうかをレビューすることで、 テスト要求モデル全体の網羅性を明示し、見逃しリスクを確定する © NISHI, Yasuharup.20 GUI 機能 データ動作環境 プラットフォーム ネットワーク OS ハードウェア OSの種類 OSのバージョン IEのバージョン 電子メール
- 21. テスト観点図のリファインの例 • モデリングをせずに行き当たりばったりでテストをすると テスト観点図が真っ黒になる – 自分たちがなにをテストしているのか、が分かっていない場合が多い © NISHI, Yasuharup.21
- 22. テスト観点のモデリングによって再利用性を高める • バージョンごとの仕様の違いをテスト観点図で整理すると、 テスト設計が再利用しやすくなり、将来の変更の予測もしやすくなる © NISHI, Yasuharup.22
- 23. テストアーキテクチャの設計 • テストケースやテスト観点を、テストコンテナ （テストレベルやテストタイプ、テストサイクル）にまとめて全体を見通しよくしよう – テストレベル： 単体テスト、結合テスト、システムテストなど – テストタイプ： 負荷テスト、セキュリティテスト、障害対応性テストなど – テストサイクル： 何回か繰り返すテストケース群 © NISHI, Yasuharup.23
- 24. テストアーキテクチャ設計で検討すべき性質 1. Coupling 2. Cohesion 3. Maintainability 4. Automatability 5. Circumstance consistency 6. Development consistency 7. Describability 8. Design direction 9. Design positiveness 10. Execution velocity consistency 11. Stability / Change frequency © NISHI, Yasuharup.24 性能測定 大規模負荷 テスト 負荷分散 機能確認 テスト DoSアタック テスト 性能テスト 適切に 「責務の分担」が なされているだろうか？
- 27. テストアーキテクチャ設計の例：テストピラミッドとSPLIT • クラウド系ではテストピラミッドと呼ばれるテストアーキテクチャが有名である – SPLIT • Scope - テストの対象範囲をどこにするか • Phase - テストのどの段階（in dev. / in prod.）に焦点を当てるか • Level - どのレベルまでオートメーションを進化させるか • sIze - 対象の範囲をどう切り分けて実行するか • Type - どのような種類の目的でテストを行うか © NISHI, Yasuharup.27 https://logmi.jp/282805
- 29. QAアーキテクチャの構築 © NISHI, Yasuharu ※ ハードウェアにおけるQC工程表や QAネットワークなので、本当は無い方がおかしい 社内外に 色々なテストプロセスがあり 全体像が掴めなくなっている 自分たちで 統一したテスト設計ができるようにし、 全体として何を保証しているのかを 把握できるようにする テストやレビューの観点 レビューの種類やテストレベル、テストタイプ p.29
- 30. フロントローディング © NISHI, Yasuharup.30 分析してパターン化して 再利用して 開発を成長させる 開発やバグの情報 使い捨てなので 開発は成長しない フロントローディングをしない組織 フロントローディングが根付いた組織 開発やバグの情報
- 31. フロントローディング • 製造業におけるフロントローディングは「上流における品質の作り込み」である – 開発初期の段階で、 より多くの問題解決サイクルをあらかじめ回しておくことによって、 開発後半における、より手間のかかる設計変更の繰り返し開発を減らすこと • 「生産マネジメント入門 II」, 第14章“開発期間とその短縮”, 藤本隆宏著, 日本経済新聞社 • コンカレント・エンジニアリングやサイマル開発を指すこともある • （ハードの人たちに説明しやすい）ソフトウェア開発におけるフロントローディングの技術 – デジタル化による上流でのモデルベース検証 – バグ分析・RCA（根本原因分析）からの水平展開 • バグ分析には大きく分けてマクロ分析とミクロ分析がある – マクロ分析（バグの傾向分析） • 組織全体としてどのチームにどんなバグが多いか、あるプロダクトのどの部分にどんなバグが多いか、 工程のどこでどんなバグが入りやすいか、を把握することが目的 • フォールトプローン分析やODC（直交欠陥分析）技術がある • よほど注意して実施しないと、形骸化と官僚化の温床になる – 施策が大味になりがちで、バグと施策が結びつかず、効果がでにくい傾向がある » 基本的にフロントローディングの技術ではない – バグの中身や開発の中身をきちんと見る習慣が失われる傾向がある – 傾向という名の数値が一人歩きする傾向がある – マクロ分析からの間接施策は最悪である » 間接施策： プロセスを決めろ/変えろ、この目標メトリクスを達成しろ、など © NISHI, Yasuharup.31
- 32. バグのミクロ分析 • 目的 – バグ、もしくはバグの原因をパターン化して水平展開し、再発防止・未然防止を行う • 根本原因分析（RCA: Root Cause Analysis）や、なぜなぜ分析として行われる • 代表的な技術 – キーワード分析・機能分析・現象分析 • 容易だが精度は低い – 開発者属性分析（開発者の体調や心理状態、経歴や出身に着目する技法） • 容易だが精度は低いし、やってはいけない – プロセス分析 • 「～を読んでない」「～を知らない」「～に従わない」「～を確認しない」 「誤った～を読んだ」「～を誤って解釈した」のように分析する技法 – 容易だが精度は低い – 構造分析（ソフトウェア構造に基づいてバグをパターン化する技法） • そこそこ難しいが精度はそこそこ高い – （欧米型）FMEAと呼ばれる一群の何か – ソフトウェアトラップ分析（不具合モード分析） • 問題点 – そもそも水平展開や再発防止・未然防止という概念をきちんと理解しないと失敗に向かう – 技術（パターンの抽出方法）によっては出来の悪いマクロ分析になる – よほど注意して実施しないと、吊し上げになり形骸化の温床になる © NISHI, Yasuharup.32
- 33. ソフトウェアトラップ分析（不具合モード分析） • ソフトウェアトラップ（不具合モード）を含む仕様書や母体設計書から 作られる構造や機能にはバグが多いと推測する技法 – ソフトウェアの入力成果物（仕様書や母体設計書）に 開発者がバグを作り込んでしまう「トラップ（罠）」が含まれているため、 開発者はそのトラップに引っかかってしまい吸い込まれるように 出力成果物（設計書やソースコード）にバグを作り込んでしまう、という考え方である • 例）「優先順位の表現で1（高い）～5（低い）と5（高い）～1（低い）が混在すると混同しやすい」 • 河野哲也氏（現DeNA）らが不具合モード分析として確立し、嬉野綾氏（ワークスアプリケーションズ）らが バグシェルジェ（ASTER）という研究グループで議論を進めている – 類似品に注意： 水平展開やフロントローディングを行えない類似品もある • 入力成果物は開発者の思考プロセスへの入力なので、 プログラミング言語仕様や直前に作成した成果物のこともある – 例） C言語で発生するif文での代入というバグは、 混同しやすい=（代入）と==（比較）を同じ場所で使えるようにした言語仕様がトラップになっている » そのためMISRA-Cなどでは規格で禁止することで「フロントローディング」を行っている • トラップによって引き起こされる「人間の思考の誤り」を意識する – 一般的なヒューマンエラーは、実のところ「人間の思考の誤り」は取り扱っていない • 人間系の要因は「ブースター」として分離して取り扱う – 「前の晩に夜更かしして注意不足だった」はトラップではなくブースターである – ブースターを根本原因として取り扱うと、 対策が大味になりがちで、バグと施策が結びつかず、効果がでにくい傾向がある © NISHI, Yasuharup.33
- 34. ソフトウェアトラップの例 • 実際に各社で抽出されたトラップの例（特定できないように一部改変しているところがあります） – 二卵性双生児 • 順序が逆のものが混在すると、混同しやすい – 優先順位の表現で1（高い）～5（低い）と5（高い）～1（低い）が混在すると混同しやすい – リトルエンディアンとビッグエンディアンが混在すると混同しやすい – True/false値（1/0）がハード側とソフト側で異なる • 対称であるべきものが一部非対称であると、混同しやすい – アームの行きの動きのルーチンと帰りの動きのルーチンが一部異なっている – ifdefでコンパイルし分けるコードのCPU使用率が異なるので処理が間に合わない – 例外 • 後から追加された例外的な仕様は、設計漏れを引き起こしやすい • 複数ある対となっている条件の両方に必要な正常処理は設計できたが、 特定の対の片方の条件だけ例外的に必要となる準正常処理が抜けてしまった – ポットの水位の事例 – 浦島太郎 • 割り込み先から帰ってきたら、割り込み元の状態が変わっていた – オートフォーカスの事例 © NISHI, Yasuharup.34
- 35. ソフトウェアトラップの例 • 実際に各社で抽出されたトラップの例（特定できないように一部改変しているところがあります） – 山登り船頭 • 指示側に指示を出さずに、被指示側に直接指示を出すと、指示側と被指示側の状態が食い違う – コンプレッサーの緊急停止の事例 – GCありのプラットフォームからGCなしのプラットフォームへのポーティングの事例 – 逆向きの予備動作 • ある動作をする場合に、特に動作の準備をしている時に、逆の働きの動作をする – データ圧縮の事例 – 永遠とゼロ • ソフトや仕様では時間が永遠/ゼロという仮定が置かれているが、現実世界では実時間がかかる – 搬送の事例 – 「備考」 • 備考欄に書かれるものは、書かれないと問題が起こるほど重要なのに、 本文に入れられるほど構造化されていないものである © NISHI, Yasuharup.35
- 36. ソフトウェアトラップの例 • 実際に各社で抽出されたトラップの例（特定できないように一部改変しているところがあります） – 二卵性双生児 • 派生開発で複数のソフトを流用して統合する際に、 統合元の前提が成立すると思い込んでしまう © NISHI, Yasuharup.36 I1 M1 I1 M1 I1 M1 M2 I2 I1 M1 M2 cI +H/Wによって 初期化処理I1が 1度で済む ようになった =1 ≧2 =1 ≧2 =1 ≧2 ユニット1と ユニット2を 統合した 新しいユニット を開発する ことになった 初期化処理I1 に気付いていたが なるべく手を 入れたくないため どうせスキップ されるからと I1をメインループに 残してしまった I1のカウンタは 共通初期化処理cI を反映しないので 初期化処理が 2回動いてしまった
- 37. バグ分析/RCAミーティングの運営 • ダメなバグ分析会議 – 犯人捜し/責任追及・上司による責任回避 – 吊し上げ/晒し者 – 根拠のない思い込みと決めつけ、説教と自慢話 – その後の悪い人事評価 – 防御的心理 • よいバグ分析会議 – 「納得感」の「共感」を軸にしてバグの分析を行う • 自分でも引っかかってしまうと納得できるトラップを探す • 適切なパターン化ができた瞬間は、分析会議の参加者が 「あーそのトラップにはみんな引っかかるよねー」と納得し、皆が共感するようになる – 開発者への敬意を前面に出す • 悪いのはトラップであって開発者ではない、という姿勢を崩さない – 「スキルの高いあなたで “すら” このトラップに引っかかるんですから、若い連中なんてなおのこと…」 – だからトラップ分析ではトラップとブースターを明確に区別している • バグを作り込んだ人という扱いではなく、 トラップの情報を提供してくれる人として尊敬を前面に出すと、前向きの会議になって共感しやすくなる – 効率を求めてはいけない • 分析に時間がかかるのはスキルが低いからだが、 時間をかけてよい分析をしない限りスキルは向上しない • 途中でみんな現場に戻りたくなって分析の質が落ちるところをグッと我慢してもらう © NISHI, Yasuharup.37
- 38. バグ分析/RCAによるフロントローディングの注意点 • 開発者が「腕が上がった」と思える施策を立案する – 開発者の「こんなことやっても意味ないよな」という実感を大事にして、そうならないような施策を立案する – 「腕が上がった」と思ってくれれば、どんどん協力してくれるようになる • そのバグだけを未然防止できる具体的で小さな施策を立案し、 少しずつ注意しながら施策を大きくする – 全社一律や部門全体に効きそうな施策は、結局のところ大味で誰の役にも立たず、「仕事をした感」を出しやすい • 「あーもっと早く気づけたのに、もったいない」という後悔ドリブンにする – 誰も後悔していないバグはフロントローディングできないし、バグ分析ミーティングが形骸化する – 後悔しているバグはトラップも見つけやすい • フロントローディングした作業のための工数をきちんと確保する – きちんとプロセス名をつけて見積もりに載せて工数を確保しないと、進捗圧力をはねのけられない • パターン集を買おうとしない – ソフトウェア開発やQAは至るところで抽象化やパターン化、水平展開が必要になる – バグ分析/RCAを上手にやれるようになるのは確かにしんどいが、しんどい原因は 自組織に抽象化能力やパターン化、水平展開の能力が育っていないからである – しんどいからと言ってパターン集を買ってきてしまうと、そうした能力が育たないため 自組織に特有のバグがパターン化できず、現場に役立つバグ分析にならないし、 継続的な取り組みにならないし、他の取り組みでも上手くいかない • 一緒にあーでもないこーでもないと抽象化能力を鍛えてくれる人と付き合う方がよい © NISHI, Yasuharup.38
- 39. バグ分析のアンチパターンと効果の薄い対策 • Vaporization（その場限りの簡単なミスとして片付けてしまう） – コーディングミス： コーディングスキルを向上するようプログラミング言語教育を行う – 考慮不足： しっかり考慮したかどうかレビュー時間を増やし確認する – うっかりミス： うっかりしていないかどうかレビュー時間を増やし確認する • Exhaustion（不完全な実施や単なる不足を原因としてしまう） – しっかりやらない： しっかりやったかどうかレビュー時間を増やし確認する – スキル不足： スキルを向上させるよう教育を行う – 経験不足： 経験を補うためにスキルを向上させるよう教育を行う • Escalation（上位層に責任を転嫁してしまう） – マネジメントの責任： トップを含めた品質文化を醸成する • Imposition（外部組織に責任を転嫁してしまう） – パートナー企業の責任： パートナー企業を含めた品質文化を醸成する • Culturalization（文化的問題に帰着してしまう） – 品質意識／品質文化の欠如： 全社的な品質文化を醸成する © NISHI, Yasuharup.39
- 40. QAのマインドセットと役割 © NISHI, Yasuharup.40 • QAのミッションとマインドセットをもう一度明確にする – 納得感の共感を高め、チームの弱いところをチーム自らがカイゼンしていけるようにすることがQAのミッションである – サーバントシップ、カイゼンサイクル、ミッションシェア、アップストリーミング、ストーリー化がQAの持つべきマインドセットである – 「悪さの知識」に着目し、知恵の循環が組織全体で行われるようにする（フロントローディング） • QAプロモーターがきちんと組織的な戦略を立てて、QAファンネル（QA内のロール）のバランスを取る – 思いついたように、あるプロジェクトだけ（ミッションクリティカルな）アジャイルQAをやろうとしてもうまくいかない • バックログCPM法や探索的テスト信仰によるイマイチなテストが発生するだけである – インプロセスQAからQAコーチ、QAコンサルタント、QAプロモーターとQAファンネル全体を大きくできるように、 育成や技術開発・技術導入をきちんと進めていく必要がある • 自組織・自プロダクトのQAの戦略を立てて推進する役割（QAプロモーター）は必須であり、最も重要である • QAが上手くいかないからといってひたすらインプロセスQAやフェーズゲートQAを増やしても、 QAの技術的負債が溜まりどんどんコストが増えるだけになる • 可能な限り自動化して内製化し、 QAサービスやフェーズゲートQA、インプロセスQAの肥大化を防ぐべきである
- 41. QAのミッション：納得感の共感を高める • ソフトウェアの品質はひとりでに高くなるほど甘いものではない – QAは「開発不完全性仮説」をおく必要がある • カンペキなエンジニアが技術的負債がゼロの状況でカンペキな開発をすればバグは出ないからQAはいらないが、 自分たちの組織はそんなにカンペキではないという仮説 – ほとんどの組織で、開発不完全性仮説は残念ながら成立してしまう – 「カンペキでないところ（＝弱点）」から品質は低下していく – だから弱点（Spoilable point）を探し、赦し、寄り添い、支えるロール（役割）が必要になる • リーダーやマネージャーは、弱点を赦したり寄り添ったりする余裕や能力、スタンスに欠けていることが少なくない • 専門のロールにしないと、どうしても品質よりもコストや進捗・納期を重視してしまうものである • 素人をアサインしてもスキルが足りないし、開発意識が強く過ぎると弱点を認めない傾向が高くなる – 品質が高いかどうかを「保証する」役割でも「管理する」役割でもない • QAは品質保証という訳語になるが、ソフトウェア開発に銀の弾丸はないので、特定のロールが保証することもできない – もし誰かが品質を保証できるのであれば、その人がやっていることが銀の弾丸ということになるが、それは存在しない • 本来の意味での「Management」をする役割であるが、日本語の悪いイメージの「管理をする」役割ではない – ルールを押しつけたり目標の達成を強いたり、合理的な説明もせずに命令や指示をする存在ではない • 組織やチームの「納得感の共感」が低いところが弱点になるので、 ソフトウェアのQAは「納得感の共感」を高めることがミッションになる – 「納得感の共感が低いところ」は色々なところにあるだけでなく、 乗り越えたり改善すると変化・移動することが多いので、 常に追い回して乗り越えてカイゼンし続ける必要がある © NISHI, Yasuharup.41
- 42. QAのマインドセット：サーバントシップとカイゼンサイクル • サーバントシップ – QAは直接品質を上げられるわけではないし、QAは微に入り細に入り技術的な問題点を言えるわけではない • 開発技術はやっぱり開発者の方が高いし、人数比率もQAの方がずっと少ないことが多い – QAがサーバントに行動することで、納得感の共感が低いところを的確に把握するとともに、 リーダーのサーバントシップが足りないところを補完していく • サーバントは、「リーダーである人は、まず相手に奉仕し、その後相手を導くものである」というリーダーシップ哲学 • 現場に寄り添って「納得感の共感」が低いところを教えてもらうために、サーバントシップが必要になる • カイゼンサイクル – 人間や組織は、いきなり腕は上がらないし賢くもならない – カイゼンのサイクルは色々提案されているが、大事なのは回し続けること • PDCA/CAPD、DMAIC、OODA、LAMDA、経験学習モデル、KPT、YWT、4行日記、 ムダトリ、TOC – 自律と人間性尊重が重要となる • ムダを取るというのは、人間に人間らしい仕事をしてもらうことだと捉えなくてはならない © NISHI, Yasuharup.42
- 43. QAのマインドセット：ミッションシェアとアップストリーミング • ミッションシェア – みんなで納得感の共感を高め合ってもらう • 品質は、QAやテストエンジニアが保証するものではなく、全員で保証し全員で高めるものである – 全員参加、スリーアミーゴスモデル、後工程はお客様 – 仲間をつくってもらい、励まし合ったり癒やしあったり助け合ったりしてもらう • 心理的安全を確保する – 相手に敬意を払い受け入れ、相手の意図や考え方をポジティブに理解しようとし、気軽に一緒に試してみる • アップストリーミング – いまやっていることは目的にかなっているか、いま目的としていることはより大きな目的にかなっているか、 いまやっていることは原理的に適切か、他でうまくいったことを抽象化していまやっていることに応用しよう、など • 製造業の日本的品質管理（TQC/TQM）では様々なアップストリーミングが有効だと言われている – 目的指向、「なぜ？」・なぜなぜ分析、5ゲン主義の2つのゲン（原理原則）、方針展開（の現場側からの戻し）、 品質の作り込み、源流管理、アンドン、横展開・水平展開（ベストプラクティスのパターン化） – アップストリーミングをするためには、いまやっていることをきちんと納得しないといけない • 「いまやっていること」は事実や観察に基づくものか、それとも先入観の混ざった思い込みか、を区別する – 5ゲン主義の3つのゲン（現場現物現実）、データに基づく管理 – アップストリーミングは犯人捜しでも責任回避でもない • 不具合を分析するのはアップストリーミングによる横展開で未然防止することであり、 犯人を捜して責任を追及することでもなければ、自分に責任が無いように言い飾ることでもない © NISHI, Yasuharup.43
- 44. QAのマインドセット：ストーリー化 • ストーリー化 – 共感できるよう納得感を伝達する質を上げてもらう – 一つ一つのロジックに納得感を共感できるような「ストーリー」を見えるようにすることが重要である • メトリクスは必ずGQM（ゴール・クエスチョン・メトリクス）とその間を明らかにすることが必要である – 例） こういう組織がこういう開発をしているので、こういうメカニズムでこのようなトラブルが発生する可能性があ り、 その兆候はこういうところに現れるので、こういうメトリクスを測ることでトラブルの兆候を掴もうとしてます – 「見えないもの」をどう「見える」ようにするかを喧々諤々議論することが大事である • とにかく数値やグラフにすることが見える化の目的になってはいけない • プラクティスレベルのストーリー化の例：AQUAフレームワーク – どういうコンテキストでどこにフォーカスして何に取り組むか、をデザインする • コンテキストに合わないQA活動を行うと、一生懸命頑張ってQAをしているのに、 品質低下が起きたり、ピンボケだったり、「過剰品質」となじられたりする • コンテキストに合わせてフォーカスを決めプラクティスに落としこむからこう品質が上がる、というストーリーになる – AQUAフレームワーク • Accelerating project ～ サービス立ち上げ期 • Qualifying value ～ サービス拡大期 • Unveiling weakness ～ サービス安定期 • Accumulating knowledge ～ サービス入れ替え期 © NISHI, Yasuharup.44
- 45. プラクティスレベルのストーリー化の例：AQUAフレームワーク • Accelerating project – コンテキスト： • とにかく速く何度もリリースを行って市場で存在感を示したり、市場で学ぶべき時期 • プロダクトサイズは小さく、信頼性や安全性はそれほど要求されない時期 – フォーカス： • 主要な価値やUXが損なわれないことと、開発スピードが上がること、成長できるチームになっていること、など – プラクティスの例： • プロダクト／プロジェクトマネジャーとの対話の開始や、チームの／との価値観の共有を目的とした朝会への参加 • 筋のよい設計でよいコードを書いているとメンバが納得感を持てるようにするペア／モブプロの促進やDR • 頻繁なリリースをためらわず最速の開発に近づいてもらうことを促すためのKPT/PDCAやTDD、UTレベルのCI • 市場の求める価値の理解と、市場からのフィードバックに対する反応速度の加速のためのUSMへの参加 • Qualifying value – コンテキスト： • プロダクトのポジションやミッションが分かってきた段階で、製品の価値を最大化する • プロダクトサイズが徐々に大きくなり、機能は増えUXを重視するが、何を目指してるのかがブレ始める時期 – フォーカス： • 価値が向上していることや、提供価値の多様化に追いついていること、複雑さの増加に対応できていること、など – プラクティスの例： • 市場の求める価値とその変化を機能やふるまいで実現していることを実証するE2Eテスト • 暗黙知を暗黙知のまま共有し、新しいメンバにも伝えていくためのペア／モブプロの促進やDR • 頻発する手戻りに対してデバッグで終わらせず設計まで戻し設計の筋をよくするバグ分析とナビゲーション • 設計の複雑さを増加させないためのデザインレベルリファクタリングの推進とテスタビリティの作り込み © NISHI, Yasuharup.45
- 46. プラクティスレベルのストーリー化の例：AQUAフレームワーク • Unveiling weakness – コンテキスト： • 多くのユーザを獲得し、市場で存在感を確立した時期に行う品質保証活動 – プロダクトサイズがかなり大きく、開発体制も大規模化し、一つのバグの影響が甚大になる時期 – フォーカス： • 大規模化に対応できていること、不具合が出やすい仕様・設計上の弱点に気づき対処できていること、 納得感を共感させる仕組みが浸透していること、などに品質保証をフォーカスさせる – プラクティスの例： • 大規模化やSoE/SoRの融合のためのマイクロサービス化などのアーキテクチャレベルリファクタリングの推進 • 大規模化でも開発速度を保つためのE2Eテストの自動化（キーワード駆動テスト化）とフルCI • 暗黙知の形式知化と形式知の実質化（＝反形骸化）のためのドキュメント化とレビュー • 仕様や設計上の弱点をいぶり出し皆が弱点に気をつけられるための市場バグの根本原因分析と探索的テスト • Accumulating knowledge – コンテキスト： • 次世代、発展型、ファミリ的なプロダクトの開発を検討すべき／始めている時期に行う品質保証活動 • 機能の追加と、コア部分や環境の入れ替えが同時多発的に頻発し、中心メンバが入れ替わる時期 – フォーカス： • 俯瞰し見通しよくできていること、シンプルさを保つ仕組みが保たれていること、 開発から知を獲得できていること、メンバの知が向上し循環していること、などに品質保証をフォーカスさせる – プラクティスの例： • プロダクトライン開発や環境多様化のためのコア資産の抽出やエンジン化、フレームワーク化、仮想化の推進 • 複数チームでの共有や俯瞰のためのモデル化、DSL化とレビュー • 不具合の未然防止のための工程内バグや過去バグからの仕様・設計上の弱点の抽出とフロントローディング • 開発全体を見通した俯瞰的なQA活動の把握のためのQAアーキテクチャの記述 • DRなどの作業埋め込み型教育、OJT、集合教育の融合 © NISHI, Yasuharup.46
- 47. QAのマインドセットと役割 © NISHI, Yasuharup.47 • QAのミッションとマインドセットをもう一度明確にする – 納得感の共感を高め、チームの弱いところをチーム自らがカイゼンしていけるようにすることがQAのミッションである – サーバントシップ、カイゼンサイクル、ミッションシェア、アップストリーミング、ストーリー化がQAの持つべきマインドセットである – 「悪さの知識」に着目し、知恵の循環が組織全体で行われるようにする（フロントローディング） • QAプロモーターがきちんと組織的な戦略を立てて、QAファンネル（QA内のロール）のバランスを取る – 思いついたように、あるプロジェクトだけ（ミッションクリティカルな）アジャイルQAをやろうとしてもうまくいかない • バックログCPM法や探索的テスト信仰によるイマイチなテストが発生するだけである – インプロセスQAからQAコーチ、QAコンサルタント、QAプロモーターとQAファンネル全体を大きくできるように、 育成や技術開発・技術導入をきちんと進めていく必要がある • 自組織・自プロダクトのQAの戦略を立てて推進する役割（QAプロモーター）は必須であり、最も重要である • QAが上手くいかないからといってひたすらインプロセスQAやフェーズゲートQAを増やしても、 QAの技術的負債が溜まりどんどんコストが増えるだけになる • 可能な限り自動化して内製化し、 QAサービスやフェーズゲートQA、インプロセスQAの肥大化を防ぐべきである
- 48. QAファンネルでロールのバランスを可視化する © NISHI, Yasuharup.48 QAプロモーター QAコンサルタント QAコーチ インプロセスQA フェーズゲートQA ・ QAサービス 組織全体にQAを推進していく役割 （自分で手を出してはいけない） 開発組織に常駐せずに QAの技術移転や技術向上を担う 開発組織に時々常駐してQAの 技術移転や品質文化の浸透をする 開発とは別組織でQAの 実業務や出荷判定を担う 開発組織に常駐しながら QAの実業務と品質文化を担う
- 49. ダメなバランスのQA組織の例 © NISHI, Yasuharup.49 QAプロモーター QAコンサルタント QAコーチ インプロセスQA フェーズゲートQA ・ QAサービス 組織全体にQAを推進していく役割 （自分で手を出してはいけない） 開発組織に常駐せずに QAの技術移転や技術向上を担う 開発組織に時々常駐してQAの 技術移転や品質文化の浸透をする 開発とは別組織でQAの 実業務や出荷判定を担う 開発組織に常駐しながら QAの実業務と品質文化を担う 手が足りないからと 外部のテスト会社に 丸投げし続けた結果 首根っこを 握られてしまった QA
- 50. ダメなバランスのQA組織の例 © NISHI, Yasuharup.50 QAプロモーター QAコンサルタント QAコーチ インプロセスQA フェーズゲートQA ・ QAサービス 組織全体にQAを推進していく役割 （自分で手を出してはいけない） 開発組織に常駐せずに QAの技術移転や技術向上を担う 開発組織に時々常駐してQAの 技術移転や品質文化の浸透をする 開発とは別組織でQAの 実業務や出荷判定を担う 開発組織に常駐しながら QAの実業務と品質文化を担う インプロセスQAに忙殺されて ずっと手が打てないQA
- 51. ダメなバランスのQA組織の例 © NISHI, Yasuharup.51 QAプロモーター QAコンサルタント QAコーチ インプロセスQA フェーズゲートQA ・ QAサービス 組織全体にQAを推進していく役割 （自分で手を出してはいけない） 開発組織に常駐せずに QAの技術移転や技術向上を担う 開発組織に時々常駐してQAの 技術移転や品質文化の浸透をする 開発とは別組織でQAの 実業務や出荷判定を担う 開発組織に常駐しながら QAの実業務と品質文化を担う プロセスと基準さえ決めて遵守させれば 品質は確保できると考え、 現場に押しつける独立QA部門 そもそも技術的な要諦が分からない上に、 独立QA部門は何も分かっていないと反発したり やらされ感まみれになって 実効的な施策が一切機能しない開発内QA
- 53. テストのスピードを、上げられていますか？ © NISHI, Yasuharu OTAオープンソース /COTS/機械学習 左利きの（デジタルな）ソフトウェアQAである QualiTraxを構成する技術 ・ コンテナ化による分散非同期開発 ・ （ミッションクリティカルな）アジャイルQA ・ モデルベースQA ・ QAパイプライン ・ QAアーキテクチャ ・ フロントローディング ・ シフトライトQA ・ インテリジェントQA p.53
- 54. 機器内クラウド化と分散開発化 © NISHI, Yasuharup.54 ECU仮想化 コンテナ化による 機器内クラウド化 と分散開発化 現在 Unit A Unit B Unit C Cloud Platform Application Dev. Team
- 55. Misaki: デンソーはクルマをコンテナ化した © NISHI, Yasuharup.55 https://www.slideshare.net/KentaSuzuki4/kubernetes-based-connected-vehicle-platform-k8sjpt1-k8sjp
- 56. フルMBD・MBQA化と非同期開発化 © NISHI, Yasuharup.56 コンテナ化による エッジクラウドディスパッチの バランスの最適化 フルMBD・MBQA化 非同期開発化 機器全体のモデルがクラウド上で動くため、 全てのテストを一気通貫で 自動実行できるようになる 非同期にアップデートする 全てのコンポーネントの最新版を随時テストし 機器に組み込むことができるようになる
- 57. マニュアルQAからモデルベースQAによるQAパイプラインへ © NISHI, Yasuharup.57 膨大な人力テストによる 開発遅延を引き起こす 同期型一発勝負的品質保証 フルCI（全ての検証の一気通貫の自動化によるCI）による 短いリリースサイクルでも成功しやすい 非同期型継続的漸進的品質保証 テスト自動生成
- 58. MBQAによるQAパイプラインの例：Fully-automated VSTeP • テスト戦略立案 – 自組織のコンテキストを把握しフォーカスを定め、 開発の自動化とテストの自動化の進度やバランス、 投資額や人員アサイン、対象プロジェクトや共通化などをマネジメントする • 「下回り」を構築するSET的職種に腕っこきを配置するのがミソ • テスト要求分析 – テスト観点モデルはエンジニアが徹底的に頭を使う – どの観点群を自動化し、どの観点群は手動に留め、 自動化するために開発側に手を入れなくてはならないところ などを決め、反復的に成長させる • テストアーキテクチャ設計 – コンテナやフレームの設計はエンジニアが徹底的に頭を使う – QAパイプラインを組む • まずは、ごく限定され粒度が細かく小さい、自動化しやすい 観点やフレームだけを並べて、なるべく早く回るようにする – それに合わせてKDTの下回りやCI環境を徐々に整備する • テスト詳細設計 – 各フレームで用いるテストモデルを開発の仕様書や設計書と紐付ける • 必要なモデルが無ければ開発側に作るよう働きかける – モデルベースドテストでテストケースを自動生成する • テスト実装・実行 – キーワード駆動テストとして（自動生成された）テストケースを 自動テストスクリプトに自動変換する – 構築したCI環境で24時間自動実行を行う © NISHI, Yasuharup.58 GUI 機能 データ動作環境 プラットフォーム ネットワーク OS ハードウェア OSの種類 OSのバージョン IEのバージョン 電子メール
- 59. モデルベースQAの注意点 • QAは「エンジニア」であって「管理屋」でも「ツール紹介屋」でもない – 世界中で最新の技術を調べ、触れ、試し、身につけることが必要である • QiitaやSlack、Githubといったイマドキの環境は必須である • QAが社外のコミュニティに参加したり、コーチやコンサルタント、研究機関に有償で支援を依頼したり、 経験のある有能な人をリファラル採用する、といった施策も重要である • ツールや環境を整備する人には腕っこきを配置する – イマドキはSETチームと呼ばれ、高い技術とサーバントシップが要求される貴重な職種となっている • くれぐれも「手の空いた人」や「現場で使えない人」に担当させない • 全社一斉導入などは間違っても目論まない – コンテキストをきちんと把握し、フォーカスを決めて取り組む • 既に興味を持っており、高い技術を持った、開発難易度の低い、余裕のある、 喜んで協力してくれる、成功しそうなチームと一緒に共創して、まず成功事例をつくる • ツールや環境を導入することが目的ではなく、 QAのスピードアップと問題解決の上流化が目的であると肝に銘ずる – 自分たちの問題は何かを明確に答えられない限り、逆立ちしてもデジタル化による問題解決はできない • 問題点をきちんと把握しているからこそ、独自で、しかし必要な分だけモデル化を行うという選択肢もアリになる – コストダウンを目標に設定すると、まず間違いなく失敗する • 認証が必要なら モデルベースQAやアジャイルQAに対応するよう受審を変化させる – 審査員の指摘を無くすのではなく、自分たちが納得感の高い開発をしていることを 審査員に共感してもらえるような説明力の高い開発・QAを行う © NISHI, Yasuharup.59
- 61. QAアーキテクチャの構築 © NISHI, Yasuharu ※ ハードウェアにおけるQC工程表や QAネットワークなので、本当は無い方がおかしい 社内外に 色々なテストプロセスがあり 全体像が掴めなくなっている 自分たちで 統一したテスト設計ができるようにし、 全体として何を保証しているのかを 把握できるようにする テストやレビューの観点 レビューの種類やテストレベル、テストタイプ p.61
- 62. QAアーキテクチャの構築 © NISHI, Yasuharu 様々なQAの工程で 様々なQA観点が整理されず 雑に考慮されているため、 どこを自動化すればいいのか ちっとも分からない QAの各工程で どのようなＱＡ観点を考慮するのか 整理されているため 自動化やシフトライトの判断が 迅速にできる p.62 高頻度に再実行が必要で 自動化が容易なレビューやテスト 対面での議論での意図確認が必要だが 低頻度の実行でよいレビュー ユーザに実機に使ってもらうので 低頻度でしか実行きないテスト 専門家チームに 任せるテスト
- 63. （ミッションクリティカルな）アジャイルQA • スプリントQAデザインを適切なタイミングで行う必要がある – インスプリントQAの増加をどう自動化することで抑制するか – インスプリントQAのスプリントからアロングサイドQA（QA専門のスプリント）をいつどのようにフォークするか – インスプリントＱＡやアロングサイドQAと、スタンドアロンQA（開発スプリントと同期しないQA）のスプリントとどのように同期するか – 安全関連系や高信頼部位のQAと、そうでないところのQAをどのようにバランスさせるか • 予防的QAとレジリエントQAのリミットを見極めて組み合わせる – レジリエンスリミットにおける予防的QAをスムーズに通過させるQAをどうQAスプリントに割り振り、どう自動化しておくか – レジリエンスリミット以前のレジリエントQAでいかに技術的負債を蓄積せず解消しながら進めるか – レジリエンスリミットを後ろにずらせるようプロダクトマネジャーやビジネスサイドといかに協調するか • 組込みのアジャイル開発のポイントはQAと認証とハードである – QAは（今日の講演も含めて）順応しつつあるし、認証も適応されつつある © NISHI, Yasuharup.63
- 64. 予防的QAとレジリエントQAを組み合わせる • （ミッションクリティカルな）アジャイルQAでは、 Preventive（予防的）なQAとResilient（レジリエント）なQAを 上手に組み合わせる必要がある – 予防的なQA ～ 赦さないQA • 不具合や障害を起こさないように予防することを主眼に置く • 何が起こるかが予見可能な場合にとてもよく機能する • 不具合や障害によるダメージが取り返しのつかない場合には絶対に必要となる • よほど上手く行わないとリリーススピードが落ちる • 形骸化したり官僚化したりしやすいが、上手にフロントローディングすると設計の質が上がる – レジリエントなQA ～ 赦してすぐ直すQA • 不具合や障害が起きることを前提として悪影響が出ないように迅速 • 何が起こるかが予見不能な場合にとてもよく機能する • 不具合や障害によるダメージが許容可能であり、レジリエンスサイクルが早く回るのなら、実現できる • リリーススピードを速くできる • 「直せばいいんでしょ」と考えやすくなるため、 無秩序や混乱がどんどん大きくなって制御不能になり破綻する可能性がある • 右利きのQAは予防的なアプローチが主だったが、 左利きのQAではレジリエントなアプローチが強調され（すぎ）ている – 右利きのQAはフェーズゲートやゲートキーパーと自称することがある – 左利きのQAはフィーチャートグルやカナリアリリース、ブルーグリーンデプロイメントを使いこなす © NISHI, Yasuharup.64
- 65. 予防的QAとレジリエントQAを組み合わせる • レジリエンスリミット（RL）を明確にして、予防的QAとレジリエントQAを組み合わせる – 開発やビジネスにはほとんどの場合、 この時点から先でダメージが発生すると取り返しがつかない、という点（レジリエンスリミット・RL）が存在する • いわゆる（最終）フェーズゲートというのは、RLのことである – 何でもかんでもRLと考えるのではなく、開発やビジネスをもう一度見直して 本当にそれがRLなのかについて納得感を共感することが重要である • 組織は想像以上に、面倒臭さやメンツによってRLが決まっていたりする • キャッシュアウトのような目に見えるダメージだけでなく、 お客様からの信頼やブランド力など目に見えないダメージも考えなくてはいけない • RLの時点で予防的QAを行えるよう、RL以前でレジリエントQAを行っていく – RLにおけるQAをいかに迅速かつスムーズに、そして的確な品質基準を満たして通過させるかが重要となる • RLに到達した時点で高い品質を達成していることが望ましいので、 RL以前のQAで積み上げられるようなQAアーキテクチャをデザインし、 品質の状況に応じてレジリエントにQAアーキテクチャをダイナミックにリデザインしていく • RLにおけるQAは自動化されていることが望ましい • だからといってRLにおけるQAを儀式化させるアプローチは意味がない – 共通のRLがあるサービスや機能、サブシステムをきちんと分割することで、 厳しいRLと相対的に厳しくないRLを組み合わせることが必要になる • ビジネスをきちんと見直すと、本当にそのRLでなくてはならないのはごく一部だけだったりする • 異なるRLは品質基準も異なる可能性が高い © NISHI, Yasuharup.65
- 66. RL以前の予防的QAはなるべくシフトレフトしておく • RLをスムーズに通過する（RLの時点で十分品質が確保されている）ように、 開発の最初期から様々な予防的QAの取り組みを行い平準化する（シフトレフトする）ことで、 開発スピードを落とさずにQAする – ビジネスレビュー、要求レビュー、設計レビュー、コードレビュー、単体テスト、結合テスト、システムテスト…と 頻繁かつ継続的に様々なQAを有機的に行うことで、特定のQA工程に負担がかかりすぎる状況を無くす • たまに散発的に通りいっぺんのQAをバラバラに行うと、どこかで大規模なQAが必要になったり、 不具合が大量に発生して開発がストップしたり、進捗優先の手抜きQAが発生してバグが大量に流出する – 頻度の高い自律的なカイゼンサイクルを回すことで、ビジネスや開発の質そのものを高めていき （フロントローディングしていき）、QAの負担そのものを根本的に減らしていく • QAの負担の多くは、品質が向上して不具合が減ると自然に少なくなっていく • QAの持つ「悪さの知識（どういう風につくると／仕事をすると不具合につながるか）」を開発に移転する • 開発の初期から「後工程はお客様」を考えて「レビューアビリティ」「テスタビリティ」を高めておく – RLにおけるQAを迅速に行うために自動化を開発の最初期から準備しておく – 「RLを超えなきゃダメ」ではなく「このままだとここがこうだからRLを超えられないので一緒にカイゼンしよう」にする • 開発の最初期に、RL以前で行うレジリエントQAの技術や仕組み、体制を整えておき、 不具合を検出したら迅速に修正し再確認し開発を進められるようにする – テスト実行の自動化やデバッグの支援、文書の自動作成、シンプルな不具合管理などを実現する – 修正のスピードを上げるとともに開発者のストレスを無くすように取り組むと上手くいきやすい • したがってQAは開発の最初期から十二分に参画し活躍する必要がある © NISHI, Yasuharup.66
- 67. RLを後ろにずらせないか（シフトライト）を検討し取り組んでいく • 自分たちのスコープや技術という暗黙の制約を外すと、 RLは意外に後ろにずらせたりするかもしれない – レジリエンスなやり方について「それもアリなのか」とレイヤやチェーンの前後で納得感を共感する • 伝統的なQAや管理職、経営陣はレジリエンスなやり方に拒否反応を示したりするので粘り強く議論する • 規格認証がRLの場合は、審査員と（良い意味で）“闘う”覚悟が必要になる – 予見不能性についてレイヤやチェーンの前後で納得感を共感する • 予見できてないのにできたつもりになっている人は組織に驚くほど多い – ダメージの低さについてレイヤやチェーンの前後で納得感を共感する • 「契約」「プロセス」「規定」などがあるとダメージの低さを考慮できない場合が多いので粘り強く議論する – レジリエンスサイクルを速くできるよう業務フローを見直す • 業務全体としてレジリエンスになる方が事業全体の変化追従性が向上する、という大局観が大事になる – レジリエンスサイクルを速くできる技術を導入する • QAがDX、すなわちQAのパイプライン化・モデルベース化・クラウド化・インテリジェント化・AI化といった 最先端の技術に精通している必要がある • 単にQAをレジリエントにするのではなく、業務全体のDXを進めるという大局観が大事になる • 何をシフトライトするのかを迅速かつ的確に判断するために、QAアーキテクチャを構築し、 いつどこでどんなQAをしているのかをきちんと整理しておく必要がある © NISHI, Yasuharup.67
- 68. シフトライトの要諦は技術ではない • シフトライトを行うには、まず現状のQAの問題点と真摯に向き合うことが必要になる – 自分たちは、きちんと品質を保証するのに必要なテストは終わっているのか？ • いつもこのぐらい、とか、予算の制約で、とかの言い訳で、終わらせたことにしているだけではないか？ – 自分たちがRLだと思っているものは、本当にその時点で全て揃っていなくてはならないのか？ – 「今すぐカンペキにシフトライトできないのなら、検討に値しない」などと、 技術開発投資をしない言い訳をしていないか？ • 今すぐカンペキ症候群の組織は、自動化も進まないし、新しい技術の導入も進まないが、 逆にツールベンダの甘言に騙されやすいという特徴がある • 今すぐカンペキ症候群の組織は、今すぐカンペキな技術が欲しいのではなく、 うまくいかない時の責任回避をしたいだけのことが多い – どんな技術だってツールだって、最初からうまくいくものはない • シフトライトは組織的な納得感の共感にも、技術の導入にも時間がかかり投資が必要で、 異なる文化の組織を巻き込まなくてはならない場合が多いので、 QAがビジョンをデザインしなくてはならない – 「世の中はDXだから」「アジャイルがブームだから」「シフトライトってのをやってみましょうよ」 といったノリのアプローチは確かに周囲を動かしやすいが、 結局のところ納得感の共感が低いので腰が据わらず、 すぐに方針が戻ったりしやすいので注意が必要である © NISHI, Yasuharup.68
- 69. フロントローディング © NISHI, Yasuharup.69 分析してパターン化して 再利用して 開発を成長させる 開発やバグの情報 使い捨てなので 開発は成長しない フロントローディングをしない組織 フロントローディングが根付いた組織 開発やバグの情報
- 70. インテリジェントQA © NISHI, Yasuharup.70 デジタル化された 開発やバグの情報 機械学習によって AIが開発支援情報 を生成してくれる フロントローディングが根付き DXできている組織 開発やバグの情報 使い捨てなので 開発は成長しない フロントローディングをしない組織
- 72. シフトライトQA + インテリジェントQA © NISHI, Yasuharup.72 シフトライトテストの結果から BIのように人間が分析したり 機械学習によるAIを活用して ダイナミックに 開発支援情報やテスト支援情報 を生成してくれる
- 73. 左利きの（デジタルな）ソフトウェア品質保証：QualiTrax © NISHI, Yasuharu OTAオープンソース /COTS/機械学習 QualiTraxを構成する技術 ・ コンテナ化による分散非同期開発 ・ （ミッションクリティカルな）アジャイルQA ・ モデルベースQA ・ QAパイプライン ・ QAアーキテクチャ ・ フロントローディング ・ シフトライトQA ・ インテリジェントQA p.73
- 74. 左利きの（デジタルな）ソフトウェア品質保証：QualiTrax • QualiTraxとは – 部品/製品の稼働状況・品質保証状況を 最速かつ継続的かつ動的に把握し予測し品質リスクを最小化するともに、 （継続的な）開発そのものを動的にカイゼンする仕組み • フェーズゲート方式のような静的な把握・予測ではなく 常にテストなどを行い動的な把握・予測を行い対処しカイゼンする – OTAによってOSSやCOTS、MLなどが動的に変化しても、常に最新の品質保証状況を非同期に得ることができる » そのために「手動テストを自動化する」から「自動テストできないところを手動でやる」モデルベースQAにパラダイムシフトして 分散非同期開発によるQAパイプラインを構築し、インテリジェントQAを行う必要がある • 開発中も稼働中も把握し予測し対処しカイゼンする – 開発中からの品質保証状況が全てデジタル化され構造化され記録されているため、 稼働中の不具合検知に対する原因究明が最速で可能になる » そのためにテスト容易性設計とQAアーキテクチャの構築が必要になる – 「終わったことになっている」テストを許さず、デプロイ前には品質リスクの高いテストを行って 運用中には品質リスクの低いテストを行うなどスピードと品質リスクのバランスを取ることができるようになる » そのためにアジャイルQAとシフトライトQAが必要になる » そのためにフロントローディングによる技術的負債が少なくテスト容易性の高い開発へのカイゼンが必要になる • 構成や稼働環境などの異なる全ての部品/製品について把握し予測する – 様々な構成や稼働環境の違いを次期部品/製品に反映できるだけでなく、 構成や環境によってデプロイする機能や制約を動的に変えることによって 品質リスクを最小化することが可能になる – 未テストの部品/製品の品質リスクを、 よく似た構成のテスト済みの部品/製品から推測することで ピンポイントにバグを見つけるテストを設計することができる © NISHI, Yasuharup.74
- 76. 横串が通っているから、うまく焼けるのです • 左利きでも右利きでも、組織に横串を通せるQAが必要である – 開発に限らず、組織というものはすべからく硬直化しサイロ化するものである • とはいえQAが最も硬直化しサイロ化している組織も少なくない – だから横串を通して、関係する組織を融合していかなければならない • 品質はあらゆる業務から影響を受けるので、QAは横串を通せる大義名分を持つロールである – 開発の工程に横串を通す、製品の要素技術に、バリューストリームに、組織に、… – 品質は組織能力の表れであるので、あらゆる組織の能力向上がミッションのはずである – もし横串を通せないQA部門だと自らが思うなら、それは自らを矮小化しており、組織としておかしくなっている • 横串に刺さらない人たちを、仲間はずれにしてはいけない – 組織には様々な人がいるので、誰もがすぐに左利きになれるわけではないし、 右利きに優れた人材も必要である • 竹林一さん（オムロン）の起承転結型人材モデル – https://logmi.jp/business/articles/323358 – しかし時に、「左利き出羽守」が心理的安全性を唱えながら 無意識だが独善的に敵認定して右利きを排除してしまう場合がある • 右利きを「抵抗勢力」と呼んだり感じたりしている場合は危険 – 誰にでも、左利きになるのも、右利きでいようとするのも、それぞれに理由がある • 例） じっくり相手の理由に敬意を払いながら耳を傾け、まずこちらが相手の理由に納得し共感する そして次により大きな理由を話し納得感を共感し、 納得感を落とさないようにこちらの理由に落とし込んでいく – アンフェアな理由で変わってくれない人も組織にはいないわけじゃないのが難しいところでね… © NISHI, Yasuharu 76
- 77. 右利きの組織が左利きにもなれるようになるための考え方 • 左利きの組織は右利きの組織から分離すべきか？ – 経営学者や経営コンサルタントは分離すべきだと主張する – しかし日本の強い製造業企業（の強い現場）は、何度か両利きになって競争を制してきた • 右利きから左利きを生み出すには強い動機や危機意識が必要である – いつも「今のやり方だと先が見えてるよな…もっと違うやり方ないかな…」と考え続け、知識を入れ続ける – 左利きのことをちょっと試してみる組織的余裕、トップの目配り、仲間を誘因しやすいネットワークが必要 • 右利きの組織が「両利き」になるために必要な要素 – 両利きになるという強い戦略的意図と社会的意義 • “I Have a Dream”であって、“I Have a Plan”ではない – 右利きと左利きのインターフェースと、探索的な思考や取り組みのバックアップ • 欧米型組織では組織的インターフェース（右利き組織と左利き組織の完全な分割と保護）が機能し、 日本型組織では人的インターフェースが機能しやすいかもしれない – 「強い製造業」でなければ組織的インターフェースが必要かもしれない • イノベーションのジレンマが発生し、左利き的な思考や取り組みは排除されることが多い – 左利きと右利きの両方に共通なアイデンティティ • 価値観やビジョン、文化、風土、DNAなどと呼ばれるもの – ダイナミック・ケイパビリティ • 変化する勇気と推進力、困難から逃げない姿勢 • 多様なものを歓迎し、掬い上げる風土 • 自分たちに無いものを知ろうとする意欲・行動と、まだ見ぬ脅威とチャンスを論理的に想像する能力 • 自分たちの強みと多様な新しいものとを組み合わせて、未来への道筋を作り進んでいく能力 © NISHI, Yasuharup.77
- 78. 両利きになるためのポイント • 相反すると思われるものを両方とも飼い慣らすことが必要になる – 5ゲン主義 = 3ゲン（現場現物現実） + 2ゲン（原理原則） – サーバント・リーダーシップ – 大局観を描くイマジネーションと、緻密なロジック – あらゆる先入観を取り除きあらゆるものに興味を持つ自由さと、徹底的なこだわり – しなやかに変化できる能力と、困難から逃げない姿勢 – スマートな、愚直・泥臭さ – 事実を基にしたロジカルな予測による予防と、周到に準備されたレジリエンス – データやエビデンスによる論証と、納得感を共感できるストーリー – 仕事がうまく回っているという安心感の追求と、 明日にも退場させられるのではないかという危機感の維持 © NISHI, Yasuharup.78
- 79. 弱い組織の社内で飛び交う危険な言葉 • 強い組織で交わされると両利き力が上がっていくが、 弱い組織の社内で発せられると組織が腐っていく言葉がある – 「それを何とかするのがお前の仕事だ」 • 強い組織： 現状の常識から離れて新しいアプローチを探索しろ • 弱い組織： 無理しろ – 「お前の責任だ」 • 強い組織： （部下に）お前に権限を与えるから周りを気にせず思いっきりやってみろ • 弱い組織： （上司である）自分に責任はない – 「（無理と思える目標に）チャレンジしろ」 • 強い組織： 現状の仕事の進め方に悪い意味で満足してしまっているから、負荷をかけて惰性になっているところを見直そう • 弱い組織： 良い結果を捏造しろ – 「お前はどう思う」 • 強い組織： 担当だからこそ分かることがあるだろうし、温めているアイデアがあるだろうから、オレのアイデアと比べてみよう • 弱い組織： オレは考えたくないからお前が考えろ、それがボトムアップだ – 「なぜだ」 • 強い組織： 真の原因を探ってパターン化し対策を講じて、もうこのことで誰も困らないようにしよう • 弱い組織： お前の責任だオレは悪くない謝れ – 「オレに分かるように説明しろ」 • 強い組織： よりよいシンプルなロジックにして皆に納得してもらいやすくなるよう、 お前のアイデアを一緒にカイゼンしよう • 弱い組織： オレの顔を立てろオレを通さずに仕事をするなお前はオレの道具だ © NISHI, Yasuharup.79
- 82. イマドキパラダイムはパッケージになっている • 様々なイマドキパラダイムは横につながってどんどん価値を高めていく – バリューサイクルやSDGsの解決の価値を倍々ゲームで高めていく – 自己矮小化や停滞は淘汰されるリスクを非常に大きくしてしまう © NISHI, Yasuharup.82 Smart Manufacturing Smart Design Smart Supplier Smart Logistics Smart Finance Smart Sales Smart Used-car Market
- 83. あなたがつくっているものは、なんですか？ • 我々がつくっているものは、ソフトであり、製品であり、ユーザの幸せである – ソフトQAやソフト開発部門だけで横串を通すだけではゴールではない – 逆に言えば、ユーザの幸せだけを見てソフトQAだけで横串を通しても、意味はない • 製造業には様々な右利き・左利きの技術があるから、全てを融合しないといけない – 3D-CAD、CAM、BOM、DA、デジタルサプライチェーン、フィンテック、HRテック、etc. • これらが融合できると、イマドキパラダイムの様々な技術やビジネススタイルを 容易かつ迅速に実現できるようになる – DXの目的はトランスフォームそのものではない – ソフトやサービスをも含めた、様々なデジタルチェーンをフルに活用する 全社QMS（品質マネジメントの仕組み）に再構築することが必要になる • ツールによるパイプラインと共に、方法論パイプラインを構築する必要がある – より拡張性の高い（＝抽象度の高い）、より俯瞰的な思想を持つ方法論をベースにするとよい • ツールベンダはどうしても、ツールありき、そのツールのための局所的技法ありき、になりやすい – 異なる分野の（QAの）方法論を融合するには、様々な分野の技術や歴史的変遷を理解できる QAアーキテクトが必要になるので、きちんと育成していかないといけない • 右利きしかできない、左利きしかできない、自分の知ってることしかやりたくないと思っている 「QAサイロマン」では想像すらできないだろう • だからといって振り子を追っかけてばかりいる「テクノロジードランカー」では、 どうやって横串を通して融合すればよいか分からないだろう © NISHI, Yasuharu 83
- 85. 新しき葡萄酒は、新しき革嚢に • 開発とQAで一緒になって、自社の全社的なものづくりの「あり方」を構築しよう – それはもはや「技術経営」である • 自社の製品やサービスの競争力は何なのか、お客様はどこに向かっていく（べきな）のか、 何が競争領域で何が協調領域なのか、モジュラーとインテグラルをどう組み合わせていくのか、 どうやってプラットフォームを構築／奪取するのか、どんな知恵をどうやって蓄積し循環するのか、 組織の持続的革新能力と活気をどのように発生させ充満させていくのか、 必要ならば組織をどのように再編・獲得するのか、など – エンジニアが経営思考を持つべし、というのはコストや利益といったカネのそろばんを弾くことではない – ウォーターフォールかアジャイル化という卑近な対立ではない » ソフトウェア開発が（基本的に）アジャイル化していくのは議論の余地などない – 全社の方法論プラットフォームとなりうる思想をきちんと確立した上で、 技術領域や工程・業務ごとのデジタルツールパイプラインと方法論パイプラインを構築し、 全社技術パイプラインとして融合していくという長い長い道のりになる • だから組織は常にRe-Collectし続けなければならない – そのためにまず、右利きと左利きの両方の技術を集めてこよう － “Collect” – 次に、自社が以前取り組んできた技術の本質的な良いところを考え直そう－ “Re-” • 技術が振り子であることを理解すれば、本質的な良いところを見つけることができやすくなる • 新しき葡萄酒は、新しき革嚢に – “Re-Collect”“した全社技術パイプラインの呼称を時々新しくして活気を再注入することは悪くない • 新しい革嚢に入れた新しい葡萄酒であっても、 美味しい葡萄酒に必要なものは時代を超えて変わらない © NISHI, Yasuharu 85
- 87. 覚悟を、決めましょう • DXの目的はトランスフォームそのものではなく、 その先にある様々なイマドキパラダイムの技術やビジネススタイルを 迅速かつ容易に実現可能にすることである – その先、の世界のQAを「後の先」で行うために、QAは先の先の議論という鍛錬をしておかなくてはならない • 車載部品のQA？自動車のQA？CASE/MaaSのQA？モビリティのQA？街づくりのQA？ – 技術が振り子であることを理解して、色んなものをRe-Collectして両利きになると、自然にできるようになる • 同業他社には見えないものが見えるようになる – Re-Collectするためには、QAが両利きになり横串を通し続けなくてはならない • そのためには、皆さんの「覚悟」が必要になります – 自社の開発・QAの「あり方」を構築するというのは、たった一人で一朝一夕にできるものではなく、 多くの人が長い時間をかけて考え抜き続けていくものである • しかし、もしこの11年間ずっとこれをやってきていれば、今は全く違った状況になっているのではないか？ – これはそう簡単ではないし、脳みそから血が出るほど考え抜かなきゃならないし、勉強もたくさん必要だし、 仲間を増やさなきゃならないし、上司や経営陣をその気にさせなきゃならないし… • でも、少なくとも、開発から尊敬され、会社から必要とされ、 ルーチンワークや警察とは異なるクリエイティブな仕事ができるチャンスでもある – でも、大まかな道筋は見えているので、あとは覚悟を決めて走り抜くだけである • 少なくとも両利きになるところまでは、何をどうやればいいか分かっているのが現状である © NISHI, Yasuharu 87
- 88. 11年前を“Re-Recollect”して（もう一度思い出して）みると… • 11年前の「説明責任」 ＝ 現在の「右利き」 – テストとは、ステークホルダーに 製品やシステムの価値を説明することである – そのためには、以下のことを説明できないといけない • テストの意図（テスト観点）のモデリング • テストアーキテクチャの設計 • 11年前の「持続的革新」 ＝ 現在の「左利き」 – テストとは、開発組織やテスト組織の能力を 持続的に革新するための作業である – そのためには、以下の能力を備えていないといけない • バグの分析によるフロントローディング • 技術の徹底／丸投げ感の排除 • 既存技術のカイゼン／新規技術の獲得とパラダイムシフト • さまざまな融合 • 向上能力の維持・向上 © NISHI, Yasuharu 88 皆さんの組織は、 11年間で振り子を往復させて スパイラルアップできましたか？