2019/04/01
どうもー！とのの@tonono2587です。
前回に引き続きJaSST'19 Tokyoのレポしていきます。
tonono.hatenablog.com
参加セッション
2019/03/27 (1日目)
QA入門セッション 〜トラディショナルなQAと、先進的なQA〜
JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyo-セッション概要
参加前の期待（気持ち）
- 仕事が「テスト」よりも「QA」が強くなってきたかも？
- QAって？品質って？
- 「入門」だしわかりやすそう！（フラグか?!）
セッション内容のメモ
前半 秋山さんより
■品質とは
- 要求への適合（By Crosby)
- 品質向上とはすなわち利益向上
- 要求には明示されたもの以外の暗黙的要求も含む
- 暗黙的：常識、潜在的なニーズ、期待、など
- 誰かにとっての価値（By Weinberg）
- 受け取り手を意識する（必ず誰かを想定する）
「価値」
お届けするものに価値があるのかを考えよう
■品質保証とはなんだろう？
「品質保証」という定義もひとによって違う？定義は難しい。
品質保証ができている状態とは？
「A社の車はぶつかっても安全」→"A社"にあてはまるのも人によって違ったりするが、何かをイメージできる状態
□演習しました
[問]
「○○の△△は、☓☓だ」を埋めてください
○○：自社名
△△：商品やサービス名
☓☓：提供している価値（広く信じられていることでも可）
”品質保証”：ブランド（お客様が信じてくれていること）
○○の△△は、☓☓だ
→☓☓が〇〇の△△に対して、品質保証できている”モノ”あるいは”コト”
→☓☓がかけなかった人は1年後にはかけるようにしましょう。（すぐには書けない）
→☓☓がかけた人はそれをもっとよいものにしていきましょう。：品質改善活動 と呼びます。
”品質管理状態”
ある事象が管理されている状態というのは過去の経験を使ってその現象が未来においてどのように変化するかが
少なくともある限度内で予測できることである
JIS Q9000 の品質保証の定義
JIS検索サイトで読める。
■品質保証とは（秋山さんの理解）
テストは基準を決めて実施するもの、テストは品質を映し出す鏡のようなもの
品質保証はそうではない。
お客様との約束を決めて、それに向かって社員ががんばること
なんの確信を与えるか、その確信を保証できているか
■品質保証活動のポイント
- 顧客視点であること バグの数などで判断したりしない お客様にとっての価値があるかどうか
- 組織的活動であること
商品品質：プロダクトそのもの
業務品質：仕事の仕方や活動の結果
企業品質：文化
□品質保証部の位置づけ
社長直下なのは（が多いのは?）なぜ？
− 偉いからではない
− 全社的に各部の品質意識が一致していなければならないから
− みんなのベクトルを同じ方へ合わせなければならないから
□品質コストについて
品質の善し悪しはお金に換算しないと経営層は納得してくれない
■前半まとめ
- 品質保証とは、ひとつの製品でなしえるものではない - 信用やブランドのようなもの
- 品質保証とは誰かの頑張りではない - 全員がトコトン良い品質に向かって改善を続けていること
- 品質とはバグゼロのことではない - お客様へ与える価値にフォーカスすること
- 品質保証とはお金持ちの企業だけ行う活動ではない - すべての企業で行うこと
Q&A
Q：要求、価値を具体的にどうやって捉えたらいいのか？
A：常に言い続けて文化をつくるのがいいのでは
QAW：Quality attribute Workshop
みないといけないものを”品質特性”としてまとめたもの
自分たちの製品が、どの特性をどこまでもっているかはかる→数値化しないといけない
なにで計るか、どこまでを目標値とするかをQA部門でなくWorkshopで決めるもの
ADD （アーキテクチャドリブンデベロップメント） を行う（要素＋構造）
中野さんより
17:41
1. 新しいテクノロジーへの対応
AIでどう開発するのか？
それをどう評価するのか？
人間が行っていたもの、システムではないモジュールをAIが実行し、システム的なふるまいをすることに対してどう評価するか
すごく複雑な状況でシステムが動くとき、どうテストするか、評価するか
10年の間に没入型の、ユーザー体験が大きく変わる。
新しいユーザーインターフェイスをもとにシステムが提供されるでしょう。
ブロックチェーン：電子台帳管理→ミッションクリティカル性が高いもの
これに限らず他も高くなってきている
AI側の設計がまずいのか、データが悪いのか
なにをもって受け入れOKとするのか わからない！！！！！！
テクノロジーの進化により製品やサービスは（このあとなんて書きたかったんやろう…）
2. 価値基準の変化
リリース前の製品をテストすることと、顧客満足がどのように繋がっているのか、
ちゃんと考えられているのかどうか？
テストが十分であることをどうやって確かめるのか？
□製品品質から利用時品質へ
priority #3：ソフトウェア品質の基準が要件を満たしていること、製品が要件・仕様通りに動作すること
priority #2：市場やプラットフォームに、ウェブサービスならば検索エンジンに評価・支持されていること、競合に対して不足がないこと
priority #1：利用時品質やUI/UXなどユーザーにとって使いやすいシステムであること、優れたユーザー体験が実現されていること、デザインと利用時の品質要求を結びつけて考え実現できていること
3（製品品質）→2→1（利用時品質）
□利用時品質評価において課題になりそうなこと
- 認識の不足
- 知識の不足
行動や心理などの人間に対する知識が足りていないから評価できない
☆☆☆
製品品質だけでなく、利用時品質にも責任を持つために必要な仕組みを考え、評価軸を定義し、
組織全体で改善できるように取り組むことが重要だと思われる
☆☆☆
3. DevOpsのその先
DevOpsのコンセプトを実現するために、品質保証組織も取り組まなければいけないのではないか
□DevOps 実現に向けて課題になりそうなこと
- 当事者意識の不足
- 技術の不足
デプロイメントパイプラインにはテストの知識があるといいけど、見て見ぬふり感がある
どんどんパイプラインにのせてくけど、（テストに更新がなければ通ってしまうから）テストも都度更新しないといけなくて…
ということはテストの知識寄り
かといって構築を任されても対応できるQAは少ない
☆☆☆
品質保証組織がDevOpsの文化の中でリリースの高速化やテストの最適化など貢献できる可能性がある。
さらにその先には構築した仕組みなどが技術的負債になる可能性も考えられる。
その上でそれらを踏まえた中長期的戦略を企てる必要がある。
☆☆☆
4. モチベーションを阻害しない組織へ
QCD(品質・コスト・納期)や生産性を高めていくために品質保証と開発組織の関係はどうあるべきか？
案1：問題の発生を防ぐため、業務プロセスを細かく手順化し管理する（マイクロマネジメント型QA）
案2：自分たちのことは自分たちで考えて実施させ、不足や要求に対して必要なサポートをする（サーヴァントマネジメント型QA）
（会場アンケートでは案2：サーバントマネジメント型QAがいいんじゃないか派が多かったっぽいです）（わたしもー）
後半まとめ
- 新しいテクノロジー
→テクノロジーの進化は加速度を増していく、品質保証やソフトウェアテストにおいては恩恵も課題も存在する - 価値基準の変化
→プロダクト品質だけでなく顧客満足のために利用時品質にも着目しサービス全体の品質を向上させる必要がある - DevOps
→今後もさらにスマートなサービス・ツールによりDevOpsの文化は発展するが技術的負債になる可能性も導入時に検討が必要 - モチベーションを阻害しない組織へ
→品質面における今後の課題（課題になりそうなこと）が山積みの状況において
ユーザー理解だけでなく開発にも目を向けて協力していく体制をつくることが不可欠
開発組織のモチベーションを阻害することなく継続的デリバリーやDevOpsを推進し 現場が一体となって価値提供を続ける文化が求められるのではないか
セッションのさいごに
やりたいことは理解できるが、時間もお金もない！どうする？？
まずは小さな成果を出す＜上のひとの信用を得る＜やりたいことを実現していく！
感想
- 黙っていても売れるほどの"品質保証"を実現するのは大変なのに一瞬で崩れる場合もある…
- それはたしかにーと思ったのですが、ひたすら努力するしかないのかな？？（"実績"の側面があるからやっぱりそれしかないのかー）
- 企業品質の上に業務品質、その上に商品品質がのっている図をみて、「テスト」だけでない品質保証を少しだけイメージできた気がします。（商品品質だけをみるのは視野が狭いかも、という気づき）
- デプロイメントパイプラインについて全然知らなかったのですが、図を描いてくれたので話が入りやすかったです。
- 考えるばっかりじゃなくて小さくても成果にしなければ。
JaSSTレポは続きます…
