価値のためのセミナーを聞いてきました！
随分日が経ってしまった…こうゆうのはすぐ後悔しないとだめですね汗
2/23に国立情報学研修所で行われた価値のためのテストのセミナーに行ってきました！
奇跡的に迷子にならずにたどり着けましたヾ(o´∀｀o)ﾉ
ほとんどの資料は公開されてますが、印象的だったところを自分用のメモとして残しておこうと思います。
★「ソフトウェアのテストと自動化のメリット・デメリットとは？」★kyon_mmさん
- テストプロセスというのがあり、開発作業とさほど変わらないような工程を踏む
- TDDは開発者支援フレームワーク
- 自動テストの誤解
- 自動テストの最大の価値は、引き継ぎコスト、改修コストの低減である。
- 定量的にしたいなら自動化にする
- バグを狙わない無駄なテストケースを書いては意味がない
- どこにバグがあるかを考える
自動テストの誤解、自動化テストをしたら品質そのものが上がるわけではない、ということを意味しているという解釈をしました。
無駄なテストやたまたまうまくテストが通ってしまっただけ、でテストがすべてグリーンになって喜んでいるだけではだめですもんね、当たり前ですが、それが大事ってことですよね。
今、テストは自動化していませんが、テストケースを考えるとき、
どこにバグがあるかを意識することは自動でも手動でも大事なことだなと思いました。
★「評価方法のバリエーションとその特徴、および開発工程への組み込み事例について」★伊藤英明さん
- 作り手と利用者との認識の違い…ギャップが生まれる
⇒良いUX(ユーザ体験)が提供できなくなる
- このギャップを埋めるために、客観的手法での定量・定性評価によってユーザの潜在ニーズを抽出する
- 人間中心設計プロセスの実施
調査などをしてユーザのニーズをきちんと把握していないと、作り手が想像していない使い方をされたり、全く使われなかったり、そんなことがあるんですね。
また、調査をしてニーズの設定をしても、やはりそれはあくまでの仮定なので、
それを作って出して終わりじゃなく、サービス提供後に継続して測定・分析をして改善していかなきゃなんですね。
以下のプロセスを繰り返す
- 人間中心設計プロセスの計画（ex.ステークホルダーの決断、メンバー集め）
- 利用状況の理解と特定（ex.アンケート、行動調査、インタビュー）
- ユーザ要求の特定/仕様化（ex.ペルソナ、シナリオ、仕様書）
- 設計解の作成（ex.ペーパープロト、シミュレータ）
- 要求に対する設計の評価（ex.ヒューリスティック評価、ユーザビリティテスト）
- ユーザ要求に合致した設計解
評価方法っていろいろあるんですねっ！その知りたい目的に合わせて形式を考えるのが大事なんですね！
よくわからなかったので出てきたテストだけでも調べてみました。
- シナリオ受容性評価
⇒利用イメージや設定などが記載されたシナリオシートを見せつつ、モニタに評価してもらう。企画レベル、コンセプトレベルで評価できるのが特徴。 - CLT(セントラルロケーションテスト)
⇒会場を用意しそこでテストを行う。人員を募集、または通行人にお願いすることがある。コンセプトレベルでも評価できる。らしい。 - ヒューリスティック評価
⇒一般的には、ユーザビリティ専門家がガイドラインに沿って評価する。 - ユーザビリティテスト
⇒一般ユーザにシステム等を使ってもらい、その様子を観察。
ex.ATMで、中に人が入って、ボタンタッチされたら人力で画面を開くなどの方法もある(オズの魔法使い法)。
おもしろい～！これだと、がつがつ実装する前に試せますね～ - NEM評価
⇒調べてもよくわからんかった…
テストって以下の二種類あるんですね。
- 仕様書通りに動くか
- ユーザにとって使いやすいか
今までだと、"テスト"と言われると仕様書通りに動くかどうかの保証の為のテストだけだと思ってました！
仕様書通りに動いても使いづらかったりしたら、ユーザにとっては価値のあるモノではないですもんね。このサービスはバグってる！とか思われる可能性もある。
ユーザにとっての価値を見定める、という意味で”テスト”という言葉があるのかな、と勝手に思いました。
★「A/Bテスト成功・失敗の分かれ目」★榎本徹さん
- A/Bテストとは仮説検証手段みたいなもの
- キャンペーンの広告バナーの内容、以下どちらがアクセスが多かったか？
- 「キャンペーン終了まであと〇日」
- 「キャンペーン終了まであと〇日×時間△分□秒」
私は２だと思いました！会場の皆さんも2に挙手してた方が大多数でしたが！
実際は1のほうがアクセスが多かった！
この原因は、おそらくカウント時間が表示されたことにより、まだ時間があるという認識をさせてしまったのではないか、という見解でした。
作り手の思い込みなどもあるんですね～なんてこったヽ(ﾟДﾟ;)ﾉ!!
検証って大事ですね！
- スプリット・ランで行う
- 時間の影響を受けない（季節、曜日、イベント、プロモーション）
- 経験の影響を受けない
調べたら、A/Bテストはスプリット・ランとも呼ばれるらしい…(ITPro調べ：スプリット・ラン・テストとは)
同じ環境や条件をそろえるってところが大事ですよね！
テストを行う前には事前にどのような影響があるかを洗い出しておくべきなんですねー。
- オバマさんはA/Bテストで選挙に勝った
- キャンペーンでA/Bテストしてたらしい…
- どのようなときにA/Bテストを使う？
- 事実を知りたい
- 微細な差を知りたい……etc
- それに対して、ラボテストは？
- 「なぜ」を知りたい
- 全体像を知りたい……etc
ラボテストてラボラトリーテストですかね？実験室で実際にユーザに目の前で使ってもらって観察するって感じですかね？(検索してもよくわからなかった…)
- A/Bテストの成功と失敗
- 成功：早く差が出ること
- 失敗：差がでない…
- なぜいいテストができないか？⇒仮説の精度が低い⇒調査不足
- アクセスログで確認←前後にどんなページを見ているか？
- ユーザテストやインタビュー←どこでエラー？心理モデル？
あきらかな差がでると対処がしやすいですが、差が出ないと、次の一手をどうするんですかねっ？
仮説検証からやり直しなんですかねっ？うーん勉強不足でわからない…
A/Bテストをするためには、今やツールが充実しているらしいです。。
optimaizely紹介されてましたが、これなんか便利そうですね！
HTMLやCSSの知識がなくても、画面上でアイコンを大きくしたり作れて、もちろん集計もできるんですねー！
発行されるスクリプトタグを埋め込むくらいらしいのか…ふんふんふん！
★「ロケテストについて」★motoko128kさん
- ロケテスト…ゲームセンターに試作品のゲームを置いておき、お店に入ってきたところからお客さんを観察。そのゲーム機をちら見するのか、遊ぶのか、なども観察。
- プレイテスト…テストプレイヤーによるテスト。ゲーム内容をよくする目的がある。
- ユーザテスト…一般の人にやってもらう。
- ロケテストにおける調査手法
- 調査したい核をもつこと
- ターゲットユーザ像を考えること⇒年齢、性別だけでなく、どんなものに興味を持っているかも
- プレイする前から観察
ロケテストって初めて聞きました！
そのゲームに触れる前、お店に入ったときから観察し、通り過ぎて一周してから
戻ってくるパターンも観察してるとは…
ユーザが対象のモノに興味を持つかだけでなく、ユーザの嗜好などの調査も必要なんですね。
ゲームセンターなどにあるゲームの開発については想像できなかったので、話を聞いていて新鮮でした～
★「シンプルさと多機能の最高のバランスを求めて（ユーザーテストとその反映）」★南治一徳さん
- ペイントパークというゲームソフト？の開発
- UI設計をしてユーザテストに挑んだが、不評だった…
- こだわりを捨て、資産を捨て、すべて作り直したら良くなった
- 結局シンプルにオーソドックスになった
- 思い切った刷新の必要性を感じた
こだわりや、今までの資産を捨てる勇気も必要なんですね…。。
これがあったらおもしろそう、と作り手が思っても、
利用者が同じイメージを持っているわけではないですもんね…難しい！
★「ソーシャルゲームの運営方法」★岡本基さん
ソーシャルオンラインゲームの中のカードゲームなどの話でした！
- これらのゲームの設計は意外と超論理的
- ゲームとは…遊ぶ目的、遊ぶモチベーション、手段としての課金
- さらにモチベーションが高まる仕組み
⇒これがないと継続してくれないし、売り上げも上がらない - 運営って？
- ゲームが機能しているか？
- バグがないか
- ゲームバランスが適切か（たしかここらへんでヤムチャとかの話がでてきました、なんで料理の話しているんだろうと思ってました笑）
- 経済バランスが適切か
- 儲かってるか
どこかメモが抜けてる気がする……
上でも書いたけどゲームの開発は関わったことがなかったので、へええ！と思って聞いてました！
確かに飽きっぽい私のような人を継続させるには大変そうですね…
まとめ
テストといってもいろいろ種類もありますし、聞いたことないような言葉も知れたので良かったです～！
何よりも、これらのセッションの最後に、明日から自分は何をするのか何ができるかを話し合うということがすごくいい経験になりました！
人見知り克服したい……！
