HDIfes #01「価値のためのテスト」 - UXDx開発xゲーム 情報交換会 に参加してきた #hdifes

勉強会

関連する3つの団体？で言うと一番『DevLOVE』が近いですが、この

のコラボレーション、及び発表内容(告知)を見たところ非常に興味深いセッションが数多く予定されていたので、早速参加申込。そしてこの日参加して来ました。


開催会場は国立情報学研究所/National Institute of Informatics＠神保町。


建物はめっちゃ高くそびえ立ってたので写真サイズに収める事が出来なかったw

当日日中はとても天気が良かったですね。空も綺麗です。


開始時刻になり、今回のイベント実現に至るまでの経緯等、運営メンバーの皆様による各種説明がありました。

キーマンとなる方々数名による『猫の話題』から始まり、そこからスケールがどんどん拡大、色々な繋がりや連鎖反応も手伝って今回のこの豪華な組み合わせが実現したそうです。


以下、参加メモ。

「ソフトウェアのソフトウェアのテストと自動化のメリット・デメリットとは？」

受託開発から見たソフトウェアテストの「難しさ」「考え方」「自動と手動」「これから」についてお話しします。
「テストの見積もりと実装に根拠を持ちながら取り組むための入り口」をぼんやりとでも見つけてもらえれば嬉しいです。

参考資料は以下。(※要ダウンロード)

  • ソフトウェアテストの全体像
    • テストコミュニティ
      • ISTQBという組織…テストを体系化。資格を設け、日本語版も策定。
    • テストコミュニティ、英米との違い
      • 英米では、基本的にテスターは別チーム。ソフトウェア業界では当たり前の認識。また、多方面に認めてもらうためにあらゆる部分で尽力。
      • 一方日本はそうでは無く、また地位も確立されてはいない。
  • テストに関しそうなコミュニティ
    • TDDBC
      • 開発者が行うTDDを入門しよう、TA(言語別のアシスタント、コーチのようなもの)が居て教えてくれる。
    • JaSST/WACATE
    • sqip
      • 品質工学について昔からあるイベント。シンポジウムを開催。
    • なごやこわい(テストなくす的な意味で

えっ？

  • テストプロセス
    • テスト要求分析：達成すべき品質を考える。
    • 戦略策定：テストアーキテクチャ、計画を立てる
    • テスト設計：テスト設計コード、設計書を作っていく
    • テスト実装：テスト仕様書、テストコード
    • テスト実施
    • 報告
  • ソフトウェアテストの分類方法・全体像
    • ◎◎テストって言葉、色々な分類がごっちゃになった状態になっている。
    • 以下4つに分類出来る。それぞれ何があるかを考えると諸々やりやすくなる。
      • テストレベル‥.テストを動かす粒度によって分ける。単体/結合/システム/受け入れ
      • テスト技法
        • テストケース生成アルゴリズム：境界値分析、デシジョンテーブル、同値分析など。
        • ツールが出ているのでこの辺は調べてみよう。どういった時に用いると便利かは異なる。
        • ※このテストの時はこの技法がうまくいく、で使うべき。
      • テストタイプ
        • テスト目的を詳細化したもの。単機能テスト、機能組み合わせ、シナリオテストなど...
        • どんなテストをしたいか。
      • テスト観点
        • テストの関心事。あまり意識しなくても良いかもしれない。
        • 手段と目的を分けた時に…セキュリティに
        • ここに何を含めるかは議論する必要があるかも。
  • 自動化
    • 自動化したくない。『きょんさんは自動化の権化だ』と言われますが...
    • 自動化が活発なゾーン
      • TDD… TDDを明確に定義する/TDDの自殺
        • 開発者フレームワーク。開発者の作業を支援していると言い換えられる。
        • TDDも様々。Webフレームワークが様々であるように
        • どんな目的でTDDをしたいのかを考えるべき。
      • BDD
        • 終着点：実行できる仕様書？
        • コンセプトは良いと思うので、気に入らない場合は作ったほうが早いほうが良い
        • 曰く、この辺りが参考になるらしい。

Specification by Example: How Successful Teams Deliver the Right Software

Specification by Example: How Successful Teams Deliver the Right Software

          • BDDはPOとの会話ツール。それ以上を意味を持っては行けないと思う(でないと死ぬ
      • キャプチャ＆リプレイ
  • 自動テストの誤解
    • コストが0に近くなる？出来ないものが無い？
    • 最大の価値は「属人性を排除する事による引き継ぎコスト、改修コストの低減」。
    • テストの安心感を定性的、定量的に捉えるか次第で自動化、手動化を考えるほうが良い。
    • 無駄なテストケースを書いてしまっては意味が無い。　
    • 自動テストによるコードカバレッジを上げても意味が無い。シナリオカバレッジ等を追求すべき。バグを狙っていく。
  • テスト対象とテスト目的とテスト運用
    • 対象：関数？ユースケース？シナリオ？ドキュメント？UI？
      • 対象物を決める。このテストの対象にどこにバグが有りそうかを考える。
      • リリースバグの8割はある箇所の20％に集中している。考えることは重要。
    • 目的：どれくらい？なぜ？
      • お客さんが求めている要求事項
    • 運用：どれくらいの頻度、誰が？難しさは？
      • 性能テスト：テストが間違ってるのがの原因分析
    • こういったテストをしたいんだな、というまとまりが出来てくる。それがスタート。

      • 性質的な自動テスト(Oracle等で取り組み)
      • ルールを与える。
      • 探索的自動化テストなどがキーワードでは関連。
  • まとめ：

テストの考え方・分類等を分り易く説明しており、後に続く各々の事例セッション等との関連を考えると、イベントの導入としてとても良いセッションだったのでは、と思います。

「評価方法のバリエーションとその特徴、および開発工程への組み込み事例について」

評価方法のバリエーションとその特徴、それを開発行程中のどういうタイミングでやるのか、
どういうことを検証したいときに向いているのかなどをお話しします。

講演資料は以下。@itow_pondeさんの作られる資料は非常に分り易く参考になる部分も多いですね。

このセッションは資料内の一部、スパイラルアップに関するメモのみ追記する形で。

  • PDCAサイクルにも似たスパイラルアップ
    • このサイクルを何度もくりかえす事が大切。その都度評価をする。
    • それぞれのフェーズでテストをして行く。
    • コンセプト・企画段階
      • シナリオ受容性評価
        • どうしても形になっていない。こういう事ができるようになったらどうですか？という点で評価。
      • CLT(セントラルロケーションテスト)
        • 数を集めることにフォーカス。
      • ヒューリスティック評価
        • ガイドラインや指標に基づく観点や細かい部分まで網羅的に確認したい場合に向いている
      • ユーザビリティテスト
        • 実際に使えるものを使って評価。
        • 裏で観察、記録をとったりする。具体的な問題点が明らかになる。
        • なるべく早い段階でやりたくなると思う。悩ましいところ。
          • 簡易モデルによるテスト...実は中に人が入っている。WOZ法(人力でモデルを動かす→実は科学者が裏で操ってた…/元ネタ『オズの魔法使い』のお話)
      • NEM評価
        • 初心者と設計者の操作時間の比較から問題のある箇所を見つける。
        • 熟練者でも時間が掛かるのだからそこは性能の限界だよね、と判断出来る。
        • そうでない場合は操作モデルの不一致と考えられ、改善が可能となる。

『オズの魔法使い』に関するくだりは『へぇ〜、そうだったのか〜！』と感心。つーかこの物語展開、実は初めて知りました(笑

「A/Bテスト成功・失敗の分かれ目」

ウェブサイトにおけるA/Bテストは、簡単に取り組むことができます。
成功・失敗事例をみながら、活用方法を考えます。
  • 自己紹介諸々
    • 久々に顔出したら『発表してください』で今回の流れにw
  • WebサイトのA/Bテストは誰でも簡単に行う事ができる。テストパターンを試し、どれが一番効果があるかを定量的に計測。
1.A/Bテストとは？
    • 勝ち負けを決める。
    • スプリットランで行う事が重要。
      • 時間の影響を受けない。季節曜日/イベント/プロモーション
      • 経験の影響を受けない。(割り振られたパターンだけ見える)
2.何がいいの？
3.A/Bテスト・ツールとは
  • ツールがしてくれること
    • 実装
    • 集計
    • 判定

上述のオバマ大統領選でも言及されている、Optimizelyというツールでかなり便利に色々試すことが出来る。ツール実演デモ等も行われましたが、かなりお手軽に要素を変更する事が出来たりでこれは是非使ってみたいなと思わせるものでした。

4.誰がどのような時に使うのが良い？
  • 事実を知りたい。
  • 微細な差を知りたい。
  • 低コスト・多頻度・大規模
  • 数値根拠で人を動かす

そんな時に。またラボテストとの比較も。

5.どうすすめる？
  • とりあえずやったら良いよ。
  • Livesenseでの事例
    • 何が成功？何が失敗？
      • 成功：A/Bで差が出ること、しかも早く。＝仮説が検証できること
      • 失敗：差が出るテストが出来ないこと
  • なぜいいテストが出来ないの？
    • 仮説の制度が低いから。
  • 調べよう。
    • アクセスログ
      • 前後にどんなページを見ている？
      • 検索キーワード？
      • どんな人？
    • ユーザテスト・インタビュー
      • どこでエラー？
      • 心理モデル？
  • 6.まとめ
    • A/Bテストをやってみよう
      • ツールが充実。楽ちん。やるなら今。
      • ツール紹介

　　 Optimizely
　　 Google Anal ウェブテスト機能 free


A/Bテスト、フレーズとかは良く聞いていますが、大統領選のトピックを聞くに付け、ここまで効果のあるものだとは...。関連するツール等は試しに使ってみようかなと思います。

「ロケテストについて」

  • motoko128k氏 (from IGDA日本)

アーケードゲームのロケテストは定量調査（インカム）と定性調査（ユーザー観察）の組み合わせによって行われます。
ロケテストの方法と、一般的なユーザーテストとの類似点・相違点について紹介します。
  • 自己紹介
    • ゲーセン屋さんの店員です。2000年頃まではやってました。
    • それ以外に何をやってきたかというと
      • 業務用ゲーム気の企画開発
      • 漫画喫茶用のインターネットの端末決め
      • 磁気カードによるアミューズメント施設課金決済システムの運営ロジック設計
      • 等など…

う〜む、このプロフィールはすごい！w

ロケテストって何？
  • 開発中のゲームを一部公開し、ユーザ意見の取り入れ・ゲームバランスの調整・市場調査などのために行うベータテストの一形態。
  • ちなみに日本語版のwikipediaではPlaytestに飛ぶ。しかしこれは意味合い的にはやや間違い？
ロケテストって、何語？
  • ゲームセンターの店舗の事を指す業界用語…？
  • ロケーション＝業界用語？
    • 所謂「ゲーセン」の呼び名が(3k暗い汚い怖い)をイメージさせる言葉として印象ついていたが法律で色々規制された。
    • 業界がイメージ定価からの脱却の一環として「呼称」を変えた。
  • セガ：アミューズメント施設という呼称を用いるように。
  • タイトー：アミューズメントパーク、ゲームパーク
  • ナムコ：
    • 風営法の前に出た本「超発想集団ナムコ」
    • 新風営法以前から自社店舗の社内用語として「ロケーション」という名称を使用…「ナム語？」w
「ロケテスト」と「プレイテスト」・「ユーザーテスト」の違い

スタッフの方のご協力で違いを実演w それによるとこんな感じ。

  • プレテスト…テストプレイヤーと教官。
  • ユーザテスト…一般のユーザの人を会社によんで、テストルームにて。お客様(ユーザ)に対する態度。
  • ロケテスト…あるお店に置かれたゲーム機。ゲーム機と同じ視点に立つ。
  • 違いをまとめると...
    • お金を入れるかどうか、これは大事。
      • ゲーセンならお金を入れる事がキー。お金を稼がない機械を入れるわけには行かない。
      • お金を入れてくれるかを確認するテスト。
ロケテストにおける調査方法について
  • 3つのタイプのロケテストがある。
    • 1.開発ロケテスト：α版、ベータ版。客の食い付きが良いかどうか、面白さを見出してくれるかどうか。
    • 2.インカムロケテスト：実際に売上を本当に稼いでくれるかどうか。3.と対比。なるべく分からないような場所に置く。
      • 最近はインターネットですぐバレるが、昔は敢えて辺鄙な場所に入れてみたりした
    • 3.イベントロケテスト
      • 製品が発売されて稼働する前にイベントとして盛り上げる意味合いが強い。
      • テストと言えば場所と日時を公開、場合によっては
  • ただ、どれにも共通する調査基本として、「定量調査」と「定性調査」がある。
    • 定性調査：アンケート調査。プレイ後にアンケート用紙による調査を行う。
    • 定量調査：こちらは売上げデータそのもの。比較対象機種を決めた上で、それとの相対で測る。
    • それ以外にある要素として「立ち会い調査」というのもある。
    • 1).調査したい「核」をもつこと
    • 2).ターゲットユーザ像を考えること。その上で
    • 3).プレイする「前」からお客を観察することが大事。
      • ここで再度実演開始。観察者が見てるのは...
        • 興味を筐体に持つかどうかを見ている。スルーは訴求として失敗
        • チラ見→しばらくして座るかどうかが勝負。ゲームをプレイする前に、どうやって他にアピールするかを考える。
        • ※プレイする以前のタイミングで、UX関する観察が既に始まっている。
まとめ


登壇者の方の経歴も異色(これまで自分が勉強会でお話を聞いてきた方々からすると)であり、また『ロケテスト』に関する諸々の解説、実演を交えた説明等も非常に新鮮な驚きであり、発見でした。『手に取る前から勝負は始まっている』というのは言われてみれば確かに納得の行く部分ですよね。


「シンプルさと多機能の最高のバランスを求めて（ユーザーテストとその反映）」

PS Vita「ペイントパーク」が、どのようなユーザーテストを経て開発されたか紹介します
（CEDEC2012講演と同じ内容です）

    • 南治さん『Vita持ってるひと？』『(挙手される方を確認し)このイベントはスゴイいい会ですね(笑)』
  • 『ペイントパーク』に課せられたミッション
    • AdHocを楽しく体験できるお絵かきアプリを制作せよ！
    • PS VItaならではな感じで。
    • シンプルで、ボタン類は少なく簡単に。
    • でも、使いやすく楽しくしてね♪
  • 割りと、キタコレ！な仕事だった。
    • 年代的にグラフィックエディタ(死語)を作れる仕事が最高でウェルカム！
    • タッチインターフェースでUIを作ってみたかった。
  • 開発開始：
    • コンセプトを確認。
    • 世の中には既に素晴らしく高機能なphotoshopなど多数のツールが存在。
    • ペイントパークはどうあるべきか？
    • 誰向き？何が必要なのか？
  • ペイントパークは
    • 誰でもすぐ使えるべき
    • 皆簡単に遊べるべき、便利というべき
    • 面白くあるべき
    • 必要なものと不必要な要素の選別
      • レイヤーはバサっと削った。
  • 初期のuIを考案
    • グラフィックエディた部分
    • キャンバスライン（投稿された絵）の部分
    • ボタンを少なくシンプルに。
    • PS Vitaっぽい感じに？
      • これについては、結果本体内蔵(＝本体同時発売)されないのであんま影響受けなかった。

　

  • 編集画面を考えた
    • 開発初期のUIの特徴
    • 伸びるボタン
    • キャンバスライン：ボタン数を少なく。
  • Vitaをタテにすると変わるUI。
    • この部分は『Instagram』に影響を受けたりもしていた。
  • 自信を持ってユーザテストに！
    • …がしかし、色々と考えた工夫が全部裏目に…
      • マニュアルの類は一切教えていない状態で、それに気づくかとうかも含めてテストした。


スライドの挿絵として時折挿入される『トロ』に、悶絶死する面々w

  • 試行錯誤へ…
    • 伸びるボタン・改
      • 伸びることを理解させる演出を、起動時に追加。
    • 描画領域の変更案
      • 覗き窓的なコンセプトにすれば行けるんじゃない？
      • 正方形のエディットエリアはそのままで、その中を拡大縮小・移動出来るようにしてみた
      • 送信時の工夫もこらしてみた。
  • 再度ユーザーテスト
    • でもやっぱり不評...
      • 見えている場所に書けない苛立ち
      • PS Vitaの大きな画面に書きたい！
      • 相変わらずキャンバスラインはわかりずらいまま(ぎゃふん
      • ただし、コンテストモードはとても好評だった
  • 思い切った刷新の必要性へ
    • 正方形のキャンバスラインと切り抜き
    • タテのキャンバスライン表示
    • 伸びるボタン
    • こだわりや資産を捨てて、全て作り直す事に！！
    • 本体から分離される事が決まったことで諸々余裕が生まれてきた。
  • そして改変後
    • UIの事例
    • 斬新＝使い易いことではない、というのを地で行った。
    • 上下にボタンを配置
    • アイコンにも工夫
    • キャンバスラインにボタンが！
    • 見やすく分かり易いあいこん
    • スクリーン全てをキャンバスに
    • ちょっとした工夫も
  • まとめ


  • 追加：テスト環境の紹介
    • テストルーム風景も用意、撮影用Webcamも用意した。
    • ペイントパークの場合、手元の撮影も行った。



…という感じで、メモを取ったのはここまで。参加自体も途中で撤収する形となりました。
(イベントの残り部分については他の人が書いてくれる事でしょう。と期待)

『テスト』という括りで今回はイベントが催され、また色々な視点からの『テスト』に関する発表があった訳なのですが、これまで自分が知らなかった視点も幾つかあり、とても刺激＆勉強になりました。

今回のイベント企画・実現に携わられた皆様及び会場御提供頂いた国立情報学研究所の関係者の皆様、発表者の皆様、また当日ご参加された皆様、ありがとうございました！