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

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

はじめに

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

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

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

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

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

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

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

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

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

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

イントロダクション

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

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

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

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

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

Qa night#2 intro from Tetsuya Kouno

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

オープニングスピーチ

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

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

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

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

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

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

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

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

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

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

DeNA QA night #2 presentation from Yasuharu Nishi

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

パネルディスカッション

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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