決めかねる

ポークジンジャーと何か

DeNA QA Night #2 のこと

イベント

dena-qa-night.connpass.com

資料

http://jasst.jp/symposium/jasst17tokyo/pdf/A7.pdf

DeNA QA night #2 presentation

メモ

品質管理部について

  • システム本部　QC第一グループ
    • 180名程度
    • 新規案件
    • 運用案件
    • LQA（言語QA）
    • 内製チーム（アルバイト）

ゲームQAの上流工程での品質改善について（山本さん）

概要

  • 不具合多発で開発、QA共にコストが増加
  • 並行開発だったためリソース不足、成果物のセルフレビュー不足
  • QAメンバーが開発に入って検証開始前に成果物レビューを実施
  • 一定の効果を得た

背景

  • 運用中のアプリ
  • 実際の暦と連動するのでリリースをずらすことは難しい
  • 開発はひとり
  • コピペ対応で作業していることが多かったので、書き換え漏れのバグが多発

施策紹介

  • インクリメンタルにできたものからQA側がレビューしていった
  • 早期指摘で開発に学習を促した＆手戻り負担軽減
  • 開発の負荷を分散

結果

疑問（業界違うからか初歩的なことがいろいろわからん）

  • もともとレビューって誰がやるもんだったんだろ？開発ひとりなんじゃ？
  • レビューって言っているのはテストのこと？
  • スプレッドシートをアップすることは開発なのか？定型の運用作業に聞こえる。
  • 整合性チェックについて仕組み化していこう、みたいな話は出なかったのかな？

自分のとこだとどうだろう

  • 前行程の品質が悪くて結合テストが一向に進まないのはよくある。
    • 結合テスト前に受入テストを実施
    • 開発中であれば中間品質検査をして品質の良し悪しの要因を探る。たとえば、人依存なのか機能の難易度なのかとか。

パネルディスカッションオープニング（西さん）

我々はどこに向かえばよいのか？

  • ちょっと昔と同じQAをすると概ね失敗する
  • 昔からのよい考え方を変化・進化させる

自組織のQAを進化させよう

  • 優れた組織イニシアティブの創出や醸成
    • 経営TOPは品質についてなんと言っているか？
    • 品質向上は成果物の質、組織能力、人間らしさを高めていくこと
    • 品質保証はみんなが品質向上へ意識を向けるような仕組みづくり、文化を作ること
  • 品質保証戦略のデザインと着実な積み重ね
    • サービスやチームのコンテキストや成長の過程に合わせて品質向上施策をデザインする
  • みんなが嬉しくなる品質マネジメントシステムの構築
    • 組織構造、評価制度、組織的振り返り、ツールや環境の構築・整備などを行う

まとめ

  • 品質保証は組織を賢くするためにあらゆることをするクリエイティブな組織

パネルディスカッション本編（河野さん、奈良さん、西さん）

  • 品質管理手法
    • 考え方は知っておいた方がよい。統計を使おうとしてもソフトウェア現場では役立たない。
    • コンサルにだまされないようにするために知っておいた方が良い。
  • 品質管理図
    • バーンダウンチャートは使えない状況もある
    • なんにせよテストがどんな状況にあるかを答えられる仕組みは必要
  • V&V
    • 工程とあてはめて自動化できているところ、これからするところなどを整理する
    • SWETが次に何をやるべきかに関わってくる
  • 探針・信頼度成長モデル
    • コンサルにだまされないようにするために知っておいた方が良い。
    • いまのコンテキストだとテスト期間が短すぎて統計処理とあわない
  • 規模（LOC、FP）ベースの品質マネジメント
    • ソフトウェアの規模を測定することはある？
      • 「上司が聞いてくるんだよ！」はうちもそうです。
    • ライブラリ使ってやっているなかで自組織のコード計測して意味ある？
    • もっと測定すべきことはある。UTのコードの有無、偏在度合い、開発者のできている感。
    • CMMIではサイズ、工数、バグが必要と説いている
  • メトリクス（GQM）、品質特性
    • 数字の一人歩き、QMSおじさんは無意味
    • 何を把握したくて何を測定するのかというデザインは意味がある
    • Web界隈では数字ベースの話が少ない気がしているので意味のある数字は必要。
    • GQMは難しいが重要
    • 品質保証は開発者よりも頭を使う必要がある
    • 何のために数字とっているのか？に答えられないことが多い
    • そういった指摘自体もらえる機会が少ないのかもしれない
  • ソフトウェア工学
    • 上手なソフトウェアのつくりかたなので役立たないわけない
    • コードを書く以外の業務がたくさんある。見積もり、テスト設計・管理などなど。
    • 読むべしPSP（Personal Software Process）やプレスマン
      • 輪読みたいなことがよいのかも。
    • 国立情報学研究所のトップエスイーもあり。

質問

  • クソCHAPDコントロールをやめたい
    • 小さいチームでこっそりやっていく。隣のチームへ広めていく。
    • 技術のわかる人が役員にいるかどうかもカギ。
    • 自分がコンロール聞かない場面でも仲間をつくりながら取り組んだ経験は転職でかなり有利
    • 勉強会は複数人で参加すると持ち帰って実現しやすい
    • ひとりで始めてまわりに押し付けず注目を集める。過去に夢破れたいちいち文句言ってくる人が協力してくれる。
      • ここのストーリーの妙な具体性すごかったな…
      • 小野さんのこの話を思い出した。

SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ

「『いいな』と思えるやり方を広めて、成功して、そのやり方のファンが増えて、ファンがまたインフルエンサーとなり別のファンを増やして、結果的に会社全体が良くなっていく。」

  • 次の時代のQAが身につけるべきスキルとは
    • 提供しているサービスが何を実現したいのか、どういった社会問題を解決しないといけないのかを考えないといけない。
    • 開発者よりも先取りして変化を察知して、どうQAするのかを考えておく。
    • 自社でしか通用しない技術・知識は役に立たない。どこでも通用する技術を身につける必要がある。