2017/12/16, 17の二日間で、若手エンジニア向けワークショップ:WACATE （ソフトウェアテストワークショップ）に参加してきました。

１日めのワークショップの各セッションでとったメモと、内容・感想をお伝えします。

BPPセッション：心が叫びたがってるんだ。（阿部孝希さん）

内容・感想

前回のwacate2017夏でBPP賞を取った阿部さんによるセッション。

ライフハックのお話ということで、何かの事象にたいしてすぐ反応していたり、日々の仕事がつまらなく感じられてしまう場合のお話からスタート。

人間は９つのタイプに分けることができる、今回のワークでは大きな区分３つにわけて、自分がどんなタイプかを確認。

そうして自分のタイプを知ることで、自分がどういった反応を示しやすいのかを把握し、それをもとに自己理解を深めたり、日々つまらないと思っている仕事の捉え方を変えて楽しめるようにしたり、できたら良いよね！という流れでした。

ここで紹介されていた内容とは別ですが、私もストレングス・ファインダーで自分の強みを把握することで、仕事に対してどう捉えたら自分に向いている切り口から取り組めるのか、といったことを考えられるようになってきました。（少しずつ）

直感を役立てつつも、直感に従ったらうまくいったからといって勘違いをしてしまうと、結果的にストレスを爆発させてしまったりします。

気をつけます。

阿部さんは今後こっち方面の資格をとろうとされているそうなので、資格取得後にまたつっこんだお話を聴けるのが今から楽しみです。

メモ

  • ライフハックのおはなし
    • 人には９のタイプがある
  • 「本当の自分」の見つけ方の紹介
    • 無意識に起きる動機
    • これが自分だ！と思う瞬間
  • 一つ目の手がかり
    • ピンときた！ってどういうこと？
    • 大切なこと
      • 自分の直感を素直に受け入れる。否定しない。
        • ただし、すぐに言葉や行動には出さないこと
      • 反応した理由を探る
        • 本当の問題に気づくことも多い
  • 二つ目の手がかり
    • 過去の経験を振り返る
      • 自分の好プレーはどんなとき
      • なぜ好プレーだと思うの？
      • その状況を例えてみると？
    • 「これが自分だ！」という瞬間、自己理解
    • 好プレーは直感を駆使している
    • 例え、は自分の本質そのもの
  • これかができると・・・
    • 自分を受け入れて、自分のやり方を見つける。自己受容できるようになる。
      • 自分にあった楽しい業務に変える
      • 覚えた手法・ツールを自分に合わせる
    • もし見つけられたら、モチベーションが上がりませんか？
  • ストレスがたまって爆発する、という場合＝自分の直感を重視しすぎている場合（つまり、やりすぎなとき）
    • 「自分しかできない」と固執したり
    • 試行錯誤に時間かけ過ぎたり
    • 経過がないから報告ができなかったり
      • →調子に乗るのはNG！
  • まとめ
    • 直感を日常や業務に活かしてみよう

ISONO:REBOOT〜評価することにこだわろう〜（朱峰錦司さん）

内容・感想

朱峰さんにより、論文に関するセッション。

論文を書くというととてもハードルが高そうに聞こえますが、

  • 暗黙知が共有されている社内でなく、社外向けに整理することによって自分の知識・経験の棚卸しになる
  • 査読者からのフィードバックがもらえる

などのメリットがあること。

またいきなりパーフェクトな論文を書かなくとも、会議によっては事例発表から受けつけてくれるものもあるので、まずはそういったところから投稿してみるのも良いそう。

↑「よし、論文書こう」から入ってもたぶん大変だな、というのが正直な感想。

じゃあどうすればいいかというと、おそらく普段から課題意識を持って過ごしていて「こうすればいいんじゃないか」をとにかくトライし続ける。

そうすると成功と失敗が溜まってきて、そこからの「論文にまとめてみるか」の流れになるのかなーと。

もちろん論文を書きたいというモチベーションから始まって課題意識を持ち始めるのはアリだとおもいます。

メモ

  • 本日のゴール
    • 論文、会議（学会）の基本をしる
    • 自分の仕事上の取組みや工夫が、イケてるのかどうか評価してみよう
    • 論文ワンチャンある気になる
  • 論文書いて、良い事あるんかい？→ある
    • 自分がやっていることを体系立てて整理・評価できる。棚卸しになる。
    • 論文のフォーマットにそって整理していく過程で、ちょうどいい棚卸しになるのでは？
    • 自分がやっていることに対して客観的なアドバイスがもらえる
  • 工夫・取り組みの評価
    • 仮説とその評価
    • 定量的仮説
      • テスト作業効率化だったら
        • 工数がどれだけ削減できたか
        • 工期がどれだけ短縮できたか
      • テスト設計支援だったら
        • バグ件数がどれだけ増えたか
          • 特に重大バグ件数
    • 定性的仮説
      • 体験者アンケート
      • 行動評価
  • ステップをふもう
    • 事例発表
      • やってみた
    • 経験論文
      • やってみて
      • 評価もした
    • 学術論文
      • めっちゃ新しいことやって評価した
      • イケてるものを作って評価した
  • ブレない
  • マスキング大事
  • エンジニアならエンジニアリングしましょう

違いを捉えよう〜場の力を引き出すカギを手に〜（常盤香央里さん）

内容・感想

常盤さんによる、違いを捉えるセッション。

たとえば話し合いをしているときに、一方は答えを欲していて、もう一方は意見を出しあって一緒に考えたい場合など、思いが違うことによって分かり合えないシチュエーションがあります。

そういったときに、「なんでわかってくれないんだ」と怒ったり悲しんだりするのではなくて、その背景にある「違い」をまず捉えてみよう。そうすると、いろんなところに活かせるよ、というおはなしでした。

ワークではあるシチュエーションに対して、個々人がどういった結論を出すのかを表明して、そこでの考え方の違いなどを話し合いました。

前提事項の違いや、抽象的なことばに対する認識の違いなどがあると、話が平行線になりがちだよなーと再認識。

↑ただし、全部が全部チャンスチャンス！と前のめりになりすぎると燃え尽きてしまうことも・・・。なので、休むときは休む。という常盤さんらしいアドバイスもあって、ためになりました。

メモ

  • 今日のワークはふたつ
  • 苦手な場面を分析してみると・・・
    • いろいろ違う
    • 背景には＜違い＞があるのでは
      • 目的は一緒だけど、手段が違う
      • 背景・考え方が違う
      • 目的が違う
      • 全部違う
  • 違いを捉えたら、次のステップ。活かしてみよう
    • 学んだことを業務で使えない
    • うちの組織では無理ー
    • わたしにはできないですー
  • 違いを捉えすぎることにのめり込みすぎると・・・
    • あれもこれもチャンスと捉えて、最終的に疲れてしまう。
    • 時には休んだり、逃げたりしよう。

ソースコードを読んでみよう（角田俊さん）

内容・感想

テストをやっている人の中には、普段プログラミングしたり、ソースコードを読んだりしない方もいます。

とはいえ、普段テストを考える上で「ソフトウェアの知識」というのも有用。なので、今回はソースコードを読んでみよう！というお話でした。

ワークでは実際にバグの仕込まれているソースコードを読んで、どこがおかしいか指摘するということをやりました。

角田さんの想定したいた以外の問題も見つかったりした一方、やはり普段読むことがない人は苦戦している様子でした。

ただ、「かつ／または」の違いや、型の違いなどが問題だ、という雰囲気のところに触れていたのはよかったかなーと思います。

個人的には「システムテストの自動化で学ぶ、テストエンジニアのためのプログラミング入門」とかやってみたい。

メモ

  • 普段、何をインプットにテストを考えているか
    • 仕様書？
    • 過去の不具合？
    • 経験？
    • 直感？
  • 今回は、ここに「ソフトウェアの知識」を入れよう
  • ソースコードを読むのは難しくないよ
  • ソフトウェアが動く仕組み
    • 使われている技術を理解しよう

ユーザビリティテストをやってみよう！（山口寛子さん）

内容・感想

よく聞くけど実際にちゃんとしたのをやったことがないユーザビリティテスト。

そもそもユーザビリティとはというところから始めて、ユーザビリティテストのフローの一部をワークで体験しました。

正直ワークがわからなかった！というのも、タスクとかシナリオとか、単純に経験なくて聞き慣れないワードで考えないといけなくて、ワークの意図を理解しきれなかったのが一番の原因ぽいです。

たぶんプログラミング経験ゼロの方が「ソースコードを読んでみよう」をやったときはこんな感覚だったのかもなぁ・・・と勝手に想像。

自分はワークには歯が立たなかったものの、機能テストとは全く違う考え方で進むというのが実体験できたのがかなりの収穫でした。イメージとしては、マーケティングリサーチとかに近いかたちで進めているのかな？どうなのかな？続きとして改めて聞きたい・本とかで読んで理解したい内容ですね。

↑何の脈絡もない意味不明なモノが突然置いてあっても、ユーザーはそれをボタンとかリンクとして認識しませんよね？の例で出てきた

メモ

  • ユーザビリティとは
    • ISO9421
    • ISO/SEC25010:2011
  • ユーザビリティの指標・目標は明確に定義できる！！（ニールセン）
    • 学習しやすさ
    • 効率性
    • 記憶しやすさ
    • などなど
      • →実際にはそううまくいかん。難しい。
  • 10ヒューリスティック
  • ユーザビリティテストとは
    • ひとつが思考発話法
      • ユーザにテストしてもらう
      • インタビュワーがファシリテートする
      • カメラ等でテスト担当者が観察している
    • テスト計画・リクルート
      • 何をテストするかを決める
      • どんな人に、何人くらいお願いするかを決める　←　ここがふつうの機能テストと違う
      • 場所を確保したり
      • ふつうのテストと比べても色々シビア
    • テスト設計
      • タスク設計
        • ユーザにやってもらうタスクや課題を決める
        • まず、主要なタスクに落とし込む。細かいバリエーションをやろうとしない。
        • ユーザの視点に立ってタスクを考える
        • スタートとゴールを定義する
        • シナリオ化する
      • インタビューガイドの作成
      • 実査ツールの準備
      • パイロットテストの準備
    • テスト実施
      • 気持ちを言ってもらう
      • ラポール（信頼関係）をユーザと築くことを心がける
      • テスト実施で注意すること
        • 質問に答えない
        • 発話を促す
        • ユーザーがタスクを完了しても一呼吸おく
      • 観察ポイント
        • 操作を間違った
        • ユーザーが「？」という表情をしている
        • ユーザーの感想は気にしない
    • テスト記録
      • 事実を書く
        • 何を、どうすると、どうなった
      • この段階では分析しない
      • 介入はしない。助成は記録する。
    • データ分析

その他！

  • ディナーセッションの抽選でソフトウェアテストPRESSが当たったものの、すでに持っていたのでジャンケンしたのが私です
  • 分科会では「テストの妥当性」の話をしました。この辺ブログにまとめてみたい。
  • 分科会後の自由時間では、B氏の発表の再演をしていただきました。ソフトウェアテスト・品質勉強会（投影資料）

２日めの記事はこちら