マーガリンのテストブログ

このブログはIT関係で知ったこと、思ったことなどを記事として投稿していきます。 内容に不備や疑問点があればコメントしていただけると幸いです。

DeNA QA Night #1 参加記録

DeNA QA Night #1

 

 

今回参加したもの

参加した勉強会・講演:DeNA QA Night #1

日時:2018/11/28(火) 19:00 - 22:00

場所:株式会社ディー・エヌ・エー様(渋谷・ヒカリエ)

dena-qa-night.connpass.com

参加を決めたキッカケ

2018年夏のwacate参加以来QAとは?テストとは?品質とは?

と考えることが多くなり、今回のDeNA QA Night #1に参加を決めた。

参加しての感想は、「参加してとても勉強会とは思えないほど楽しく、また学びある勉強会だった」

 

 

セッションについてのざっくり感想

セッションについての感想は後述するが、まずはざっくりと。

 

  • 「テストの広さと深さ,どっちが大事?」松尾谷 徹 さま(デバッグ工学研究所)

松尾谷さんのお話は最近この業界に足を突っ込んだ私としては過去から現在、将来の"品質"についての話。

また今後のQAとして活動を続けていく中での大切なことを知った。

  • DeNA 品質管理部の概説と改善事」:前川 健二さま(DeNA)/河野 哲也さま(DeNA)

DeNAで複数あるプロジェクトで各チーム毎のやり方でテストをしていて言葉やプロセスが統一されていないので標準化をしたよって話(ざっくり)

過去の現場でプロセスや言葉、成果物でトラブルを経験したことがあったので、「あの時この話を聞いていれば...」と思ったり。

 

感想

「テストの広さと深さ,どっちが大事?」松尾谷 徹 さま(デバッグ工学研究所)

松尾谷さんのお話は、QAが誰に対して品質を保証をするのかという大きなお話でした。

QAは昔その製品の品質を保証すればよかった。

例えば、「機能が仕様書通りに正しく動くことを保証する」ことを保証すればよかった。

ただ今では使い手(ここは社会科学的に考える使い手)のことを考える必要がある。

そしてQAが今後どう活躍してくのか、どうビジネスに結びつけるかを考える時代にきている。

アナリシス:細かいところをみる

シンセス:いろいろな組み合わせをみる(いわゆる”虫の目”、”鳥の目”)

この鳥の目を今後発展させる必要がある。

そのためには、過去のプロセスを定義するなどのプラクティスから脱却すべきではないのであろうかとの話。

 

=====

誰に対する品質?

昔:製品を買った人

今:サービスを使う人

→品質特性も変わってくる

昔は受け取る人が特定されていたが、今では受け取る人が”社会”になっていった。

例えば、フェイクニュース。これもサービスだが今までの製品とは違い、国家や宗教・人種といった”社会”を揺るがすことに。

↑さぁどう保証する?

=====

(上手くまとめられない。。。メモをまとめ直して、再度投稿する予定です)

 

DeNA 品質管理部の概説と改善事」:前川 健二さま(DeNA)/河野 哲也さま(DeNA)

DeNAで複数あるプロジェクトで各チーム毎のやり方でテストをしていて言葉やプロセスが統一されていないので標準化をしたよって話。

品質管理は、各チームの担当者がそれぞれの観点でテスト活動を行っており、

チームによってプロセスや言葉の定義、テストのやり方が統一されてなかった。

そこでPFDを使用して、各チームのテスト活動を見える化

見える化したことで、各チームでバラバラでやっていたことの中でも共通化している箇所を標準化とした。

ただし不足している箇所は追加をしていき、不要な箇所は削除。

そして標準プロセスを作成し、いまそれを回して活動している。

 

見える化するメリット

 

そもそもの最終成果物が作れるかの見通しが立つ

全体作業のスコープが明らかになる

効率的に作業を進められる、作業のボトルネックがわかる

→上司に「これやってね」の”これ”がわかる

 

・箇条書きよりもモデルを使用する

PFDとか(絵を描くと分かりやすくなる)

ボトルアップ的なアプローチ

 ・現状のテストプロセスの見える化と共有

 

積の集合にする。和の集合にはしない。

キックオフ→議事録→テスト計画書→設計・見積もり

→観点→項目→項目書→実行

→見積もりも同時並行

 

・世の中一般のやり方をプロセス標準化にする

 

・標準化を2017/12から現在まで継続している

 成果物の名前を標準化する(テスト観点・仕様書・計画書・概要書)

 成果物の内容と行動を標準化(項目はこのレベルで、書式は〇〇で、これを用意してね を決める)

 名称は、JSTQBなど一般的なものを当てはめる。

 

プロセス標準化のメリット

・案件が出た場合の動きが明確になり、チームごとの差分が少なくなっていく。

・人材育成にも活用できる

 ・全く知らない人を作らない対策

・標準化しても効果はあまり上がらない

 ここから深掘りすることが大切

 → テスト設計を作っていることがわかった

  → じゃあどう作っているの?

   → 開発者のノウハウ ← ここをどうするか

 → そこから工数の見積もりもできるようになる

 → 振り返りにも使える

 

・まとめ

あくまでもDeNAの非ゲーム系のQAの改善活動の紹介

・標準化するおすすめしたい課題

 ・テスト業務の見通しが悪い。

 ・テスト業務の全体が一体どうなっているのかがわからない

 ・そこそこ上手く行っているが、もっとレベルをあげたい