yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

JaSST'19 Tokyo D4「QA入門セッション」の参加ブログ #JaSST19Tokyo #JaSST #jasstd4

講演内容

タイトル:「QA入門セッション」

jasst.jp

講演資料

JaSST'19 Tokyoイベントレポートで公開されると思います。

講演中のツイートまとめ

togetter.com


JaSST'19 Tokyo、D4「QA入門セッション」の参加ブログです。
講演中に私がおぉ!と思ったことや、自分でまとめたいと思ったことなどを中心にしています。
なので講演全体を網羅したものではないです。

以下、まとめです。

トラディショナルなQA(秋山さんパート)

そもそも品質とは?

以下2つの定義をしている方がいる。

※ SQiPやASTER標準テキストにも書かれている。 www.juse-sqip.jp

aster.or.jp

要求仕様書の項目に全て○がつけばいい品質?

そうではない。
受け取り手のことを考えましょうというのが品質。

※ この議論は以下のイベントを参考にするといいかと。
nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

品質保証できているとは?(〇〇の△△は、××)

簡単な演習がありました。

問:〇〇の△△は、××という文で、それぞれ以下を参考に埋めてください。

〇〇: 自社の名前
△△: 商品名やサービス名
××: 提供している価値(広く信じられていること)

このとき 「××に書いたモノ、あるいはコト」が「〇〇の△△に対して品質保証できている」となる。
ここで、××が書けなかった人 → 1年後にかけるようになりましょう。
××が書けた人 → もっと良いものにしましょう: これを「品質改善活動」と呼ぶそうです。
とのことでした。

「1年後」というのが気になったのですが、この後 品質保証は継続的な取組み という説明をしていただいたので、価値と呼べるようになる・品質が保証されているというのには1年ぐらいはかかるのかなぁと思いました。

品質保証とはお客様へ提供する価値の約束

f:id:yoshitake_1201:20190404123149p:plain
講演資料P10より

「品質保証とはお客様へ提供する価値の約束」
これが秋山さんの品質保証ということの理解だそうです。
私の中で特に印象的だったのは、「品質保証は一つの製品ではなしえない」「品質保証は誰かの頑張りではない」でした。
継続しなければ品質保証とは言えない・品質保証は品質保証部だけが頑張ることではない。
ただ聞くと当たり前だよなぁと感じたんですが、とても深い言葉だなと思いました。

品質保証活動は組織的活動

f:id:yoshitake_1201:20190404123154p:plain
講演資料P12より

この図にもある通り、品質には以下の3つに分類されるそうです。

  • 商品品質
  • 業務品質
  • 企業品質

それぞれの品質では、良い/悪いの指標や見える(関わる)人が異なるが、それぞれの当事者意識がないと品質は上がらない(保証できない)ということかと思います。

余談になりますが…@saeも自分と一緒にこのセッションを聴講していたんですよ。
そこで理解を深めようと、JaSST終了後に社内でこのセッションについてふりかえりをしたんですが、この図を見ていたときに自分たちが理解できていない…ということに改めて気づきました。
パッと見簡単に理解できそうな気がする(また、講演中は理解した気になってた)んですが、なかなか難しい部分でした。
奥が深いです。

品質保証部は偉いのか?

f:id:yoshitake_1201:20190404123203p:plain
講演資料P13より

品質保証部の位置づけとして↑のように社長の直下に位置づけられることがあるそうです。
ただこれは品質保証部が偉いからというわけではなく以下の2つの理由からこの位置づけになっているそうです。

  • 全社的な活動を行うため
  • 組織全体のレベルを引き上げるため

品質の話はお金にしないと経営者は理解してくれない(ことが多い)

f:id:yoshitake_1201:20190404123207p:plain
講演資料P15より

品質向上を行う場合、どこから取り組むべきか?どこに注力するべきか?
という点について、コストを分類 & 現状を把握すべき、ということでした。

コストの種類は資料にもある通り4つです。

  1. 外部失敗コスト
  2. 内部失敗コスト
  3. 評価コスト
  4. 予防コスト

まずはこの4つのコストについて、現状分析を行いどのコストが一番大きいかを知ることが大事。
そうして今の会社(またはチーム)の成熟度を確認し、↑の順に改善に取り組んでいくと良いとのことでした。
コストの分類、対応の優先度について知れたことが個人的にとても良かったですね。

※ 参考
http://www.f.waseda.jp/yito/quality%20cost1.html

先進的なQA(中野さんパート)

講演のトピックは4つ

  • 新しいテクノロジーへの対応
  • 価値基準の変化
  • DevOpsのその先
  • モチベーションを阻害しない組織へ

新しいテクノロジーへの対応

テクノロジーの進化により製品やサービスは、さらに複雑度を増すことになる。
テクノロジーの性質により課題は異なるが、個々の組織だけでなく品質保証やソフトウェアテストの業界内で研究や議論を進めていく必要がある。

新しいテクノロジーの例として、Gartnerから5つほど品質保証に関係しそうなものを抜粋 → 説明してくださいました。
↓は、中野さんがGartner: Top 10 Strategic Tecnology Trends for 2019 より抜粋された項目

  • AI -Driven Development(AI主導開発)
  • Autonomous Things(自律的なモノ)
    • ロボット、ドローン、自動運転などの「自律的なモノ」+「AI」の融合
  • Empowered Edge(エンパワードエッジ)
    • エッジ: 人々が使用するエンドポイントデバイス
  • Immersive Experience(没入型エクスペリエンス)
    • 仮想現実(VR)・拡張現実(AR)・複合現実(MRS)
  • Blockchain(ブロックチェーン
    • 分散台帳管理

このブログでは↑の5つから2つほど抜粋します。
Empowered Edgeについて。
一般のユーザからすると便利だがその実はデータ構造が複雑になる → テストが困難・複雑になる、といった指摘をされていました。
ブロックチェーンについて。 ミッションクリティカルな領域になり、その領域にテスト(QA)が介入していくことになる。
こういった「ミッションクリティカル」なものが増えてきている現状で、テストを行っていかないといけない。

なので、新しいテクノロジーに対する研究・議論が必要とのことでした。

※ 参考
www.gartner.com

www.atmarkit.co.jp

価値基準の変化

製品品質だけでなく、利用時品質にも責任を持つために必要な仕組みを考え、評価軸を定義し、組織全体で改善できるように取り組むことが重要だと思われる

製品品質から利用時品質へ

f:id:yoshitake_1201:20190404123213p:plain
講演中の資料より(※ Priority #3 → #1 という優先度になっています)

使用性のテストが疎かになっている(評価されにくい)現状がありますよね。
もっとそこを追求し、顧客満足度のつながりを考えましょう!とのことでした。

ちなみに、中野さんが社内の専門家に「なんで使用性って評価されにくいのか?」と聞いたところ「人間の特性に関する勉強(情報)が圧倒的に不足しているから」という回答をもらったとのことでした。
デザイン = センス といったような認識の方が多いけど、実際はそうではなくて様々な理論に基づいていることなので、勉強していったほうが良い、とのことでした。

DevOpsのその先

品質保証組織がDevOpsの文化の中でリリースの高速化やテストの最適化など貢献できる可能性がある。
さらにその先には構築した仕組みなどが技術的負債になる可能性も考えられる。
その上でそれらを踏まえた中長期的戦略を企てる必要がある。

(DevOpsに取り組む組織、チームが多い中「QAがDevOpsに入っている(含まれている)」という事例が少ないと感じている現状に対して)

なぜQAがDevOpsに入らない(入りにくい)のか?

以下2つが考えられるとのこと。

  • 当事者意識の不足
  • 技術不足

たとえばデプロイメントパイプラインについて。
開発側がこういうのをやろう!としたときに「テストには関係ないと思って」QAはあまり関わろうとしていない。
しかし、デプロイメントパイプライン = リリースに直結している。
また、CI/CDを使い開発者がテストの管理を行いだすことにもなってくる。
そういうときにQA側の知識はすごく役に立つはず。
なのでそこに加わり提案していくことは重要、ということでした。

しかし、加わったとした(加わろうとした)とき、QAでありながらデプロイメントパイプラインを構築できる人はとても少ない。
なのでそうした技術の不足を補っていく必要がある、とのことでした。

※ 参考
bliki-ja.github.io

codezine.jp

cloudbees.techmatrix.jp

モチベーションを阻害しない組織へ

QCDや生産性を高めていくために品質保証組織が開発組織との関係性のあり方を考える。
相互に尊重しあえる関係性を築くために議論していく必要がある。

「モチベーションを維持するために品質保証組織は開発組織とどう関わるべきか?」
という問いを提示され、この問に対して中野さんは以下の2つの案を提案されました。

  • マイクロマネジメント型QA
    • 問題の発生を防ぐために業務プロセスを細かく手順化し管理する
  • サーバントマネジメント型QA
    • 自分たちのことは自分たちで考えて実施させ、不足や要求に対して必要なサポートをする

※ マイクロマネジメント型QA、サーバントマネジメント型QAというワードは中野さんがこの発表で定義した言葉です。

どっちが良いか?と参加者に挙手を求められたのですが、「サーバントマネジメント型QAがいい」という方が多かったですね。
私もこっちに手を上げました。

ただ、同じ現場(メンバー)だとしてもチームの成熟度や状況に応じて変わるので模索・議論していかないといけないなぁ…と思いました。

感想

品質とは、品質保証とはなにか?を知る & 整理できてよかった!と思いました。
秋山さんのパートでは、JIS、SQuBOK、PMBOK、TQM、ISOなどなど、品質・品質保証・品質管理について様々なもので定義されているんだなぁ…と驚きました。
まだまだ勉強しないとですね。
ただ、自分がこれまでもやもやとしていたところに「こういう定義があるんだよ」と教えていただけたことがとてもありがたかったです。
(個人的には、品質の分類を知れたことがとてもありがたかったです)

中野さんのパートでは、新しいものや日々変わっていく現状に対してどう向きあうのか?という中野さんの考えの一端を知ることができてよかったです。
技術のことだけでなく、プロセスのこと、人間関係のことなど本当に様々なことを考えられていて、ただただすごいと思いました。
私も自分の現場でもっと考えていこうと思います。

秋山さん、中野さん、ありがとうございました!