DeNA QA Night #2 開催レポート(パネルディスカッションパート)

こんにちは。品質管理部QC2Gの柏倉直樹です。Eコマース、ライブ配信サービス、インキュベーションプロジェクトなどのQAリーダーを勤めつつ、DeNA品質管理部の知名度アップとQA業界への貢献を目指し、DeNA QA Nightと言うイベントのプロジェクトオーナーを担っています。今回はそのDeNA QA Nightの第2回目開催レポートをお届けします。

はじめに

DeNA QA Nightとは、ソフトウェアテスト・品質に関しての技術や事例を共有・議論する事を目的とした定期開催イベントです。ソフトウェアテスト・品質に関して広く議論する機会を提供することでテスト・品質コミュニティへの貢献を目指し企画・開催しております。

今回はその第2回目の開催レポートです。 第1回目の開催レポートもありますので、ご興味のある方はご覧ください。
第1回 DeNA QA Nightレポート(前半)
第1回 DeNA QA Nightレポート(後半)

第2回 DeNA QA Nightは2部構成となっています。

【前半】
DeNA品質管理部QC1Gの山本幸寛よりゲームQAにおける品質改善の取り組みについて発表しました。 上流工程でレビューを実施すると下流工程でみんなハッピーになるよ、と言う話ですが、上流でレビューを実施するまでに持っていくのがなかなか大変だったりしますよね。インクリメンタルなレビューであれば、比較的導入がしやすく、効果も出るよ、と言った内容ですので、興味のある方は是非こちらのブログもご覧ください。

【後半】
本ブログはこの後半をターゲットに書いています。
後半では、社外から2名の講師をお呼びしてパネルディスカッションを開催しました。

■テーマ
QAの過去から現在・現在から未来

■パネラー(社外講師)
奈良 隆正 氏
 NARAコンサルティング代表
 『ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点』著者

西 康晴 氏
 電気通信大学
 ソフトウェアテスト技術振興協会 理事長
 JSTQB 運営委員長

また、モデレーターとしてDeNA品質管理部QC2Gの河野哲也が登壇しました。

■パネルディスカッションの流れ
・イントロダクションで本日のテーマについて会場と認識を合わせる(5min)
・オープニングスピーチでまずは西氏のご意見について伺う(20min)
・会場を交えてパネルディスカッション(50min)

イントロダクション

イントロダクションではモデレーターの河野より、本日のテーマ、パネル企画の意図を会場と共有しました。ここではその概要について簡単に触れておきます。

開発手法の変化やビジネスモデルの変化、そして品質保証に求められることの変化にともない、かつて有効とされてきた仕組みや仕掛けが通用しなくなってきているのではないか。しかし、その全てが現在でも通用しないわけではなく、現在でも引き続き有効なものとそうでないものがありそう。

そこで、
・基礎知識として覚えておく必要があるもの
・今でも使い物になるもの
・忘れても良さそうなもの
と言う観点から過去の技術、仕掛け、仕組みについてパネルディスカッション形式で意見を交換したい。さらにそこから、未来の技術的展望を交えながら考え方・技術・プラクティスを整理していきたい。

過去と現在のコンテキストの違いを表にまとめるとこんな感じ。(イントロダクション資料から抜粋)
qa_night_2_pic01new.png

イントロダクション資料全編はこちら

Qa night#2 intro from Tetsuya Kouno

イントロダクションではこのような感じの大枠を会場と共有しました。
いよいよオープニングスピーチに入っていきます。

オープニングスピーチ

オープニングスピーチでは、パネルディスカッションに先立ち西さんご自身のお考えについてお話しいただきました。

洞窟の奥には隆盛を誇った古代都市の遺跡がある...と言うなんとも聴衆の興味をそそりそうな一言からスピーチが始まりました。さすが喋り慣れてる人は違いますね。と言う個人的な感想を述べてみたところでオープニングスピーチの概要はこちらです。

まずは時代を次の3つに分け、それぞれの時代の特徴と、どんな開発・QAだったかを紹介。

【かなり昔('70年代〜'80年代)】
 ■特徴
  内製や関係の強い企業に発注していた(汎用機)
  あまり複雑でなく、規模はそこそこだった
 ■どんな開発・QAか
  中身をちゃんと理解して納得して作っていた
  全体としてどんな品質で何が問題なのかが分かっていた

【ちょっと昔('90年代〜'00年代)】
 ■特徴
  多重下請構造に基づいたプロジェクト制だった(エンプラ・組込み)
  かなり複雑でかなり大規模だった
 ■どんな開発・QAか
  よく分からないけど指示に従って業務をこなす意識で作っていた
  全体としてどんな品質で何が問題なのかが分かっていなかった

【現在から未来('10年代以降)】
 ■特徴
  内製化が進んできている(クラウド)
  かなり複雑で徐々に大規模になっていく(が経験はない)
 ■どんな開発・QAか
  中身をちゃんと理解して納得して作れている?
  全体としてどんな品質で何が問題なのかが分かっている?

このように、時代とともに特徴や開発・QAの内容も変化している。コンテキストが変化しているので、かつて成功していたQAのやり方をそのまま現代でも適用すると概ね失敗する。リソースにかかる値段も昔と現代とではまるで違うし、オープンソースやクラウドが当たり前になり、全て自社開発で中身を把握できていた時代は過ぎ去った。

これからのQAは、昔からの良い考え方をさらに変化させながら現代に合わせて進化させることが必要。
例えば
・優れた組織イニシアティブの創出や醸成
・品質保証戦略のデザインと着実な積み重ね
・みんなが嬉しくなる品質マネジメントシステムの構築
などが進化のカギである。

逆に、よく陥りがちなワナとしては、
・おかしな組織イニシアティブの創出や醸成
・役に立たない品質保証戦略のコピペとやりっぱなし
・誰も嬉しくならない品質マネジメントシステムの構築
などが挙げられる。

詳細は西さんの資料に書いてあるので、興味がある方はぜひご参照ください!

DeNA QA night #2 presentation from Yasuharu Nishi

さて、オープニングスピーチでの西さんのお話を踏まえ、いよいよ奈良さんにご登場いただき、会場全体を巻き込んでディスカッションしていきます。

パネルディスカッション

パネルディスカッションでは今でも使い物になりそうなもの、基礎知識として必要なもの、忘れても良さそうなもの、の3種類に事前に分類していただきました。 qa_night_2_pic02new.png

この表をもとに、奈良さん、西さん、河野がそれぞれどのような意図で分類したのかを議論していきました。議論のエッセンスをテーマごとに紹介していきますね。なお、時間の関係で全てのテーマについてディスカッションできなかったため、議論できたテーマのみ紹介します。

【品質管理手法】
・考え方は知っておいた方が良いが、実際に使用する機会は少ない
・コンサルがよく品質管理手法を提案するが、騙されないためにも知っておくべき

【品質管理図】
・テストがどこまで進んでいるかを答えられるようにするためのツール
・テスト期間が3日間など短い場合はあまり有効ではなさそう
・スプリントの性質によるが、ある程度のテスト期間がある場合はリリースごとでの利用価値はありそう
・テストがいつ終わりそうか、を答えられる状況にあるのならどんなツールを使ったって構わない

【V&V(Verification:検証とValidation:妥当性確認)】
・検証と妥当性確認はどちらか一方ではダメ。全体を考えることがとても大切
・レビューを実施する上でもV&Vの考え方を理解していないとうまくレビューできない
・自動化すべきところと人間が考えるべきところをきちんと整理するためにも有効

【探針・信頼度成長モデル】
・テストがいつ終わるのか予想するための手法として活用していた
・組織やプロダクトなど各種特性によって曲線は使い分ける必要がある
・テスト期間が3ヶ月とか長期間にわたる場合は有効
・現在では全く使い物にならないと言う意見もあり
・ただしコンサルに騙されないためには知っておくべき

【規模(LOC・FP)ベースの品質マネジメント】
・オープンソースを活用する現在の開発において、自分が書いたソースの行数だけを見て何が測定できるのか疑問
・しかし、ソフトウェアの目方を測るためにはなんらかの指針が必要
・LOCよりも現在の開発手法にあった測定指標があるのではないか、と言う意見もある
・ソフトウェアの目方に関係なく、「自分たちはきちんとテストできてるよね」とみんなで納得できる方法を模索する方が大切では?

【メトリクス(GQM)、品質特性】
・何も考えずに、上司が取れと言ったからメトリクスを取っているような場合は意味がない
・なんでもかんでもむやみにメトリクスを取れば良いと言うものではない
・根拠を示すためにデータを取ることは大切であり、データをもとに議論するべき
・メトリクスを検討するにあたってGQMは役に立つが、やってみると結構難しい

【ソフトウェア工学】
・上手にソフトウェアを開発するための知見を集めたのがソフトウェア工学
・ソフトウェアに関わって飯を食っている人は知っておくべき
・例えばソフトウェアを開発して飯を食っている人はコードだけ書ければお金がもらえるか?否、見積もりしたり管理したり様々なことをやっている
・自動車工学を知らない人が作った自動車に乗りたいか?航空工学を知らない人が作った飛行機に乗りたいか?ソフトウェア工学も一緒

【会場からの質問1】
■Question
「基準に従え!人力でなんとかしろ!誰の責任だ!マニュアル化しろ!文書!文書!文書!ハンコー!」と言った類の管理が横行しモチベーションの低下や仕事の矮小化、視野狭窄が起こっている現場で働いているのですが、どうすればこの現状を打破できますか?
■Answer
・スキルを身につけて会社を辞めれば良いと思う
・会社に残ったまま状況を変えるのは相当な難問。もしその道を選ぶとしたら、小さなプロジェクトでこっそり結果を出して、少しずつ隣のプロジェクトにも波及させていくようなやり方が良い
・今日のような勉強会に仲間数人で参加するのも手。むしろ一人で参加してもあまり意味がない。複数人で参加して課題を共有すれば、会社に持ち帰りやすい。一人で持ち帰ろうとしても、勉強会で感じた課題感を仲間と共有するのは難しい。

【会場からの質問2】
■Question
次の時代のQAが身につけるべきスキルとはなんですか?
■Answer
・テスト技術の話に閉じず、サービスの品質とは?を考える必要がある
・自分が携わっているサービスは社会の課題を本当に解決できているか?ユーザーに価値を提供できているか?まで考える範囲を広げる必要がある
・身につけるべきものの範囲が広がって来ている
・自分の組織でだけ通用する技術を磨いてもダメ
・積極的に社外の勉強会に参加したり、自らが発表して周囲からフィードバックをもらう事も有効

以上、ここまでがパネルディスカッションのエッセンス紹介です。

まとめ

さて、いかがでしたでしょうか。冒頭でお伝えしたテーマについて振り返りましょう。テーマは、
・基礎知識として覚えておく必要があるもの
・今でも使い物になるもの
・忘れても良さそうなもの
と言う観点から過去の技術、仕掛け、仕組みについてパネルディスカッション形式で意見を交換したい。さらにそこから、未来の技術的展望を交えながら考え方・技術・プラクティスを整理していきたい。と言うものでした。

ディスカッションから見えてきた答えとしては、完全に忘れても良いと言えるものは無く、どれも知識として有しておく必要がありそう、と言う事ですね。また、V&Vやソフトウェア工学と言った分野はこれからも間違いなく必要なものと言えそうです。それから、未来において必要なスキルとしては、テスト技術に閉じずに自らが携わるサービスが世の中の課題を解決しているか、また、ユーザーに価値を提供できているか、と言ったところまで視野を広げて仕事ができるかがポイントになりそうですね。

ここまでレポートを書いてきましたが、本記事をお読みいただいた読者の皆様に少しでも刺激を与えることが出来たなら幸いです。そして、この記事を読んで「次回DeNA QA Nightに行ってみたい!」と思っていただけたらなお幸甚です。

最後に

DeNA QA Nightは半年に1回のペースで継続開催を予定しています。次回は8月末くらいを予定しています。案内はconnpassから発信しますので、ぜひグループ登録をお願いします。
connpassグループの登録はこちらから

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA QA Night #2 開催レポート(第一部)

はじめに

こんにちは、品質管理部の山本です。 ゲーム関連のQAを担当しております。

先日(2019/3/6)、DeNAが主催しております ソフトウェアテスト、品質関連のイベント「DeNA QA Night#2」にて、 DeNAのゲームQAで行った取り組みに関しての発表を行いましたので その内容についてご紹介できればと思います。

発表の背景

幅広いプレイヤー層にゲームを楽しんでもらうため、多い時で月に7~8本のイベント施策をリリースしている運用タイトルがありました。

1か月内に多くのイベント施策がリリースされるため、 開発の一人一人がリリースサイクルの短いイベント施策を並行で開発する事となり、 深刻なリソース不足に陥っていました。

開発側とゲームQA側双方がこの現状に問題意識を持ってはいたのですが リソース不足解消の目途はたたず、 またリソース不足の影響で開発成果物(仕様書やデータ)に対してセルフレビューを実施できず、検証時に検出される不具合が増加してしまう不幸な状況が続いていました。

そこで、不具合が増加している状況を解決するために、開発側で実施できなかったレビューをゲームQA側が開発に入り込んで実施しようと考えました。

開発成果物の欠陥を上流工程である開発期間にレビューし検出する事で、 下流工程である検証時の不具合数を減らしていけると考えたのですが 一つ一つのイベント施策のリリースサイクルが短く開発期間も短いため、 レビュー実施方法について工夫する必要があるだろうと考えました。

このような背景をもった運用タイトルに対して行った取り組みが、 今回発表させて頂いた内容となります。

今回の発表内容

DeNA QA Night#2 Game QA part from Yukihiro Yamamoto

上記が発表当日のスライドとなりますが、 インクリメンタルなレビューといたしまして、開発メンバーのすぐ近くに移動して、 直接開発成果物の作成状況を随時確認し、レビューが行えそうな物があれば、 どんどんレビューを実施していくという形を取りました。 (ご協力頂いている開発メンバーには本当に感謝です...!)

リリースサイクルが短く複数のイベント施策を並行で開発している為、 開発成果物が完成してからレビューを実施していると、レビューする期間が足りず、開発側もレビューに対する修正を実施する期間が十分に取れない状態となってしまいます。

また、影響範囲の大きい箇所から随時レビューを実施し問題点を早期指摘する事で、影響範囲内の別箇所に同様の問題が混入しないように対応を促すことが出来、少ない指摘で開発側、ゲームQA側双方が効率よく作業を進められると判断しました。

下流工程になればなるほど仕様変更が発生した際のリスクは大きくなると思いますが、 こちらもインクリメンタルレビューを実施して早期指摘する事により、仕様変更が入ってしまった場合の、開発側、ゲームQA側の負担も軽減出来ると考えました。

そしてインクリメンタルレビューを実施した結果、 検証時の不具合数削減やそれに伴うQAコストの削減について、一定の効果も確認できましたので、詳細が気になった方に関しては上記スライドをご覧頂けますと嬉しいです!

発表のポイント

この発表のポイントとしては下記となります。

・インクリメンタルレビューであれば、完成してからまとめてレビューを行うより、開発側QA側共に心理的ハードルが低く実施しやすい

・開発側のリソースが不足している状況でレビュー工程を追加する事は、一見酷に見えるのですが、インクリメンタルレビューであれば負荷が少なく導入が可能

・最終的に検証時に検出される不具合数が減少したので、下流工程に入ってからの満足度が、開発側もQA側も高い

これからについて

まだまだ発展途上で改善点もある状況ではありますが、 なるべく開発側とゲームQA側がwin-winの関係になれるように、 レビュー対応で不具合数を減らしてQAコストを削減するだけでなく、 開発メンバーへのレビュー対応満足度アンケートを実施したりしながら、 周りの意見を吸い上げて改善しながら進めています。

現在は運用タイトルの1タイトルのみの対応となっておりますが、 インクリメンタルレビューを、他タイトルや新規リリースタイトルにも実施できるように 更に改善していければと思っています。

おわりに

DeNA QA Night#2も前回に引き続き、皆様のお陰で大盛況だったかと思います! 私個人としましても、この発表に至るまでに周りの皆様に支えて頂き助けて頂き、 どうにか本番を迎えられたという状況だったので、 この場を借りて改めて感謝をお伝えしたいです。 本当に皆様ありがとうございました!

引き続きゲームの検証を行う上で有効だと判断出来るものには 積極的に取り組んで行きたいと考えておりますので、 また皆様と意見交流を行えると幸いです!

ありがとうございました!

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

QA Night #1 開催レポート(第二部)

はじめに

品質管理部の河野です。 開催レポートが遅くなってしまってしまったのですが、「おわりに」で遅くなった言い訳を書かせて頂きます。
すでに第一部の松尾谷さんの講演はこちらでレポートさせて頂きました。
こちらの第二部では、DeNAパートの中でも事例のところにフォーカスを当ててレポートいたします。 今回、DeNA QA の事例として、テストプロセス標準化の取り組みを発表させて頂きました。以降、発表の背景と概要をレポートいたします。

発表の背景

ちょうど1年前の12月くらいから部門横断の改善活動を開始したのですが、そのとき真っ先に着手したのがテストプロセスの標準化でした。各チームでバラバラだったテストの進め方をまずは全体的に共通化しようと言うのが本発表の取り組みです。
その後、標準テストプロセスが概ね出来上がった段階でその導入を進めつつ、TPI NEXTを使ったテストプロセスのアセスメントや標準テスト観点の整備などの取り組みを進めてきました。また、テストプロセスが標準化されたことで、今後はテスト活動のメトリクスの収集を行っていく予定です。
ということで、まずはテストプロセスを標準化していくことで、その後の活動がスムーズに進んだように思います。 それでは、当日の発表概要に移ります。その前に、当日のスライドはこちらになります。

DeNA QA Night #1 DeNA part from Tetsuya Kouno

発表の概要

当日の発表では、上記のような背景を初段に説明して、その後は、具体的にどのようにテストプロセスを標準化していったのかという事例を紹介しました。
テストプロセスの標準化というと難易度が高そうに見えますが、我々が取ったアプローチは以下になります。
1.各チームのテストプロセスの見える化する
2.上記テストプロセスの共通化する(積の共通とする)
3.成果物や処理の名称を決める
それで、当日は1.の見える化を「カレーライスを作る」演習を交えて、皆さんで少しワークをしてもらいました。思いの外、盛り上がってよかったです。
その後は、2.と3.を具体例を交えながら解説していき、最後の方で標準化のメリットなどを示しました。

後日談1:プロセスに関しての松尾谷さんの発表について

松尾谷さんの発表で、品質関連のアプローチとして「プロセスや技法」は負け犬の遠吠え、
のような解説がありました。 それに関して、後日というよりは発表後の話になるんですが、
松尾谷さんから以下のような意図のコメントを頂きました。

私が言ったのは河野さんの発表のようなプロセスではなくて
スタッフ部門や管理部門が押し付ける規範的なプロセスを指しているので
逆にこのようなプロセスを標準化するのは良いことだ

ということで、今回の取り組みはそれほどずれていなかったようで安心しました。
今回、気をつけたのは、ボトムアップのアプローチで進めたのでやはりそれが良かったと思いました。

後日談2:PFDってそんなに簡単なだっけ?

本イベントに参加した私の知り合いに、とあるイベントであったのですが、こんなことを言われました。

PFDでプロセスを書くのを簡単に発表してたけど、
そもそも目の前の業務をPFDに書くことは結構難易度高いんじゃない

はい、おっしゃる通りで、よく見かけるのはフローチャートになっていたり、
成果物と処理がごっちゃになったりして、PFDで表現するのは結構難しです。
それで、私は以下のような工夫をしております。

  • 最終成果物から戻るようにプロセスを書いていく
     最終成果物からその前の処理、その処理の入力成果物といった感じで考えるほうが
     経験的に知的ハードルが低くなるように感じます
  • 最初はメタに捉えて、作業の粒度を荒くする
     細かく考えるとキリがないです。まずはメタに捉えて、細かくしていきましょう。
     細かくしていくところは参考資料を見てみてください。
  • ホワイトボード / 紙と鉛筆で書く
     いきなりpptで清書すると挫折します。挫折というより、時間切れになると思います。
     なので、まずはラフにスケッチしましょう。
     スケッチできなければ、よくわかっていないことなので、次の工夫です。
  • 一人で考えすぎずに、他の人を巻き込む
     実態がわからなくて、PFDで表現できないところが出てきます。
     なので、そういうところは知っている人に聞くのが早いです。
  • 成果物と処理の名前付けに気をつける
     これは重要です。周りのメンバが共感できるような実態にあった名前をつけましょう。
     それと、成果物と処理にふさわしい名前、特に処理は動作を表す名前をつけましょう。

おわりに

今回の第一回、DeNA QA Night は参加者・講演者の皆さんのおかげで成功だったと思います。ただ、これは終わりではなくて始まりです。
次回もやります。日程は3月6日(水)で決まっております。次回も業界の一線級の識者にお声がけしてます。是非、期待して下さい。
ということで、次回日程が決まってから開催レポートを書きたいと思っておりましてこんな遅い開催レポートとなってしまいました。という、言い訳でした。
皆様、良いお年を!

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA QA Night#1開催レポート(第一部)

はじめに

みなさんこんにちは。品質管理部の柏倉です。コマース系、エンタメ系サービスのQAを担当しています。 先日(2018/11/27)、DeNA QA Night#1と称してソフトウェアテスト、品質関連のイベントを開催しましたのでそのレポートをしたいと思います。 記念すべき第一回目となるDeNA QA Night#1では招待講演にデバッグ工学研究所の松尾谷徹氏をお迎えし、ご講演いただきました。それから、第二部としてDeNA品質管理部の紹介と、DeNA品質管理部が取り組んだテストプロセス標準化のお話を紹介しました。今回はその第一部、松尾谷徹氏の講演についてレポートしたいと思います。

DeNA QA Nightを発足した背景

まず初めに、そもそもなぜこのイベントを開催しようと思ったのかについてお話ししたいと思います。DeNAには品質管理部という独立した組織が存在していて、品質向上のために日々業務に取り組んでいます。オンサイトとオフサイトを合わせて、その数なんと750名!毎日750名もの人数が品質向上のために稼働しています!

しかし、これほどのパワーをかけている部門にも関わらず、その地名度は低く、DeNA社内においても「品質管理部??知らないなぁ」という人がいるほどでした。社外における知名度も同様で、DeNAに品質管理組織がある事は知られていませんでした。これはいかんという事で、社内・社外双方で知名度&プレゼンスを上げなければならない!そのための活動の一環として社外向けのQA関連イベントを主催しようという事になり、DeNA QA Nightの開催に至りました。また、イベントを通じて世の中の品質関連技術の向上に貢献したいという思いもあります。世の中の技術力向上と品質管理部のプレゼンス向上を両立すべく、今後も継続して開催していく予定ですのでみなさまのご来場を心よりお待ちしております!

DeNA QA Night_logo.jpg

心配をよそに大盛況!

品質管理部のプレゼンス向上の一環として立ち上げたDeNA QA Nightですが、そもそも品質管理部の知名度が低いのでイベントを開催したところでどれくらいのお客様にご来場いただけるのか、スタッフ一同ものすごく不安を感じながら募集を開始しました。イベントの1ヶ月前から参加希望者の募集を開始したのですが、最初はちょっと弱気で『80名くらい来てもらえたら嬉しいね』くらいの気持ちでした。ところが!公開して数日で募集人数を大きく超える応募をいただき、あっという間に応募枠が埋まってしまいました!皆様本当にありがとうございます!これに気を良くしたスタッフ一同は『あと100名くらい増やしてみようか』とか言い始めます。スタッフ一同調子に乗っちゃってるので誰も止める者はなく、勢いで本当に100名ほど枠を増やしてしまいました!結果的に、募集枠180名に対し、約260名のご応募をいただきました。まさかこんなに応募をいただけるとは思っていなかったので、本当に驚きましたし、嬉しかったです!募集枠に入りきらなかった皆様、今回はお会いできず残念ですが、是非#2でお会いできる事を楽しみにしております!

松尾谷徹氏の講演から感じた事

さてここからは、招待講演にてご講演いただいたデバッグ工学研究所の松尾谷徹氏のお話から個人的に感じた事などを書いてみようと思います。大きな印象としては、我々QA担当者にとって辛辣な問いを投げかけられているように感じました。QA担当者はこれからどうなるのか。絶滅危惧種として難民化するのか、はたまたコントリビューターとして繁栄するのか。

(以降、松尾谷氏の許可を得て講演資料から一部抜粋して画像を掲載しております。)

dena_qa_night_1_1_slide1.png

本題に入る前にQAの本質について私なりの解釈を交えて少し述べてみようと思います。講演の一節にQAの本質は測り、良否の判断ができる事とありました。この部分を私なりに解釈して説明します。従来からQAは良否の判断をするために仕様とソフトウェア動作を比較してきました。ソフトウェアの動作が仕様と異なっていれば否、合致していれば良としていたわけです。これはつまり仕様が無ければテストが出来ないという事を示しています。もし仕様に定められていない動きを見つけた場合は良否の判断が出来ないためです。そのような場合どうするかと言うと、見つけた動きを仕様とするのか、あるいはもっと良い動きに修正するのかを検討し、最終的に仕様化します。つまり、テストの実態は仕様記述だったわけです。

dena_qa_night_1_1_slide2.png

そしてここからが本題になるのですが、これからの時代は仕様記述だけのQA担当者は生き残れないと言う事をおっしゃっていたように思います。ここについても私なりの解釈を交えて少し述べてみます。QA担当者の役割が「仕様に対して良か否か」を判断する事から「社会や文化に対しての良否」を判断する事に変化してきています。また、情報サービスが主役となる時代において、情報そのものの正しさをいかに保証するかも品質における課題となっています。それから、品質に対する考え方も変化してきているように思います。テストで徹底的にバグ出しをして、不具合が出来るだけ含まれない状態でプロダクトを出荷する事に重きを置いていた時代から、OSSを用いてソフトウェア開発を進めるようになって以降は現実的で合理的な品質保証にシフトしてきているように感じます。このような時代において、仕様通りにプロダクトが作られているかを追求するだけではもはや品質は保証出来ません。では、我々QA担当者はどうすれば良いのでしょうか...

dena_qa_night_1_1_slide3.png

松尾谷氏曰く、キーワードは「Contribution」だそうです。google翻訳に聞いてみると「貢献」と教えてくれました。松尾谷氏の経験上、海外の人と一緒に働くとだいたい聞かれるのは「お前のContributionは何?」との事。世界的な流れとしてContribution(貢献)が求められるようになってきている模様です。我々QA担当者もこの流れには逆らえないと思います。難民化しないためには『Contributerである事が大切』と松尾谷氏はおっしゃっていました。講演の後、品質管理部内で解釈をすり合わせてみた結果こうなりました「規範的な批評家QAではなくて、開発やサービスにcontributionできるQAである事」。これはDeNA品質管理部と同じ方向性を示しています。その事に気が付いた時、皆とても嬉しそうにしていました。これからも我々品質管理部はサービス品質向上に向け、あらゆる面でContributionしていこうと再認識出来た講演でした!この場を借りて改めてお礼を述べさせていただきます。松尾谷様、貴重な講演ありがとうございました!

dena_qa_night_1_1_slide4.png

テストプロセス標準化のお話

DeNA QA Night#1の第二部では、DeNA品質管理部より品質管理部の紹介とテストプロセス標準化のお話をさせていただきました。この様子は追ってブログで公開します。お楽しみに!

宣伝

connpassグループへのご参加をお待ちしております!

DeNA QA Nightは主にconnpassでの応募となります。是非グループ登録をお願いします! DeNA QA Nightグループページへ

Twitterフォローお願いします!

DeNA TechCon 2019を開催します!

DeNA TechCon 2019 を2019年2月6日(水)に開催します!みなさま、ぜひご登録下さい!! techcon2019_logo.png

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る