いもろぐ

思い立ったら書いていくスタイルで

業務改善と効率と全体最適と

この記事はGaiax Advent Calendar 2016 - Qiitaの2016/12/13の記事です。

このところ、仕事では業務改善とか効率化に関わっています。そんなタイミングで2016/11/13に投稿された 見えない非効率 ー 今、動いているんだからいいじゃないか の記事を読んで思ったことを書きます。耳が痛いというか、刺さった感じがしました。元の記事も2,3分あれば読めると思うのでぜひ一読いただきたいです。こういうのって組織で働く上で誰でも経験することだと思うのと、エンジニアだけではなく、むしろエンジニア以外の職種と関わりながらプロジェクトを進める人には思い当たるフシがあるのではないでしょうか。(お互い)

元記事のサマリー

見えない非効率 ー 今、動いているんだからいいじゃないかの中でキーになる部分を引用すると、

実務層が勤勉で真面目すぎるから、仕事のシステムが多少おかしくても、一所懸命にカバーして動かしてしまう。その結果、かえって問題が隠れて見えなくなってしまうのだ。

とか

だって現に今、動いているんだからいいじゃないか? これが、多くの組織で改善をはばむ最大の心理的障害なのだ。たとえ出来のわるい業務の仕組みでも、現場の人たちが真面目で優秀だと、なんとかだましだまし動かしてしまう。もしかしたら効率は低いのかもしれない。だが、現に今、動いているんだ。何の文句があるんだ? それを変える時間などないほど、忙しいんだし。

のような、「本来あるべき姿とは?」とか「今あるものを改善する時の障壁」とか、そういう話だと私は解釈しました。

私が思ったこと

最初の例で出てくる「工場の書類」の話と我々の業務

毎日の業務(開発業務だけではなく、運用も営業もバックオフィスも含めた「業務」)としてWhat(何をやるか)が定義されていることは多いです。業務のルールや手順書とかまさにそれですよね。「この手順でこれをやること」が仕事として定義されている。これのメリットは「誰がやっても、同じ結果が、短い時間で再現できるようになる」ことです。

この手順書を作った時、作った人の中にはWhy(なぜやるのか)が存在します。何らか解決したい課題があったはず。「オペレーションミスが起こったので再発防止のために別の人がWチェックする手順を追加する」みたいなのありますよね。そこから時間が経ち、人が入れ替わり、その後に新しく入社した人には「これをやるときはWチェックをすること」という手順だけが受け継がれます。

...というような話です。

ここで思うのは

  • 手順とかルールとかはwhyと一緒に定義されているとわかりやすいし、その都度、最適なものに変えていけるようにしておけるといいな。
  • だから「Whatだけじゃなく、Whyもセットにしよう」
  • そして「今の状況」と「Why-What」がマッチするのかを考えよう
  • 例えば上記の例だと、「オペミスが許容値まで減った=課題が解決した」ならWチェックをやめよう、でいいと思います。
  • (エンジニアリング的には、根本解決としてそのミスが起き得ない状況にする、というのがスマートだろうけど)

過去のある時点での最適解と、現在の最適解が同じとは限らない(人がやることでも、システムがやることでも)ので、定期的にルールを見直して、判断して、変える行動力をもつ。

「ルール」というとわかりやすそうですが、ここで言いたいのは「明文化されてるもの」だけじゃなく、暗黙的に行われてる我々の「当たり前なこと」に疑問を持つということかと思います。当たり前に疑問を持つのは難しいです。時には自分(たち)を否定してみることになります。

変えることへの障壁

最初に引用した「動いてるんだからいいじゃない」というのはシステムだけじゃなく、業務全般に言えることです。

実際に一番多いのは、ルートCのように、業務のやり方を変えたために、いったんパフォーマンスが下がってしまうパターンである。その後、皆が新業務になれて、システムが落ち着いたら、きっと成果は上がるだろう。だが、こういう話を聞いたら、皆は何というだろうか。「なぜ、自分がそんなリスクを背負わなければいけないの? 現に今、仕事は一応動いているんだから、何も変える必要はないじゃないか!」 

これ、ありますよね。えぇ、ありますよ。「なんで私がリスクを負う必要があるの?」って思うじゃないですか。

ここでいうリスクってなんですかね?

  • パフォーマンス(=自分の成果)が下がる可能性がある → 自分の評価が下がることに直結
  • 自分たちが築き上げてきたものを壊したり、やめることへの抵抗感
  • 他人(社内外)と「変化」についての合意を取る過程で発生するであろうハードネゴシエーションへの忌避感

こんなところが思いつきました。特に3番目。「お客さまの要望で」っていうのが殺し文句になることありますが、「それ、本当に必要?何を解決したいの?」ってお客様に返すのって難しくないですか?

元記事の最後の言葉ですが、

大事なのは、目の前の仕事を懸命に支えることではない。いったん仕事の手を止めてでも、あるべき姿を考えて、問題解決に向かう勇気を持つことなのである。

ここで浮かんだのが

  • なんで「あるべき姿」を求めるんでしょうか。
  • 私とあなたの「あるべき姿」は同じでしょうか。

という問い。

ちょっとここで、ソフトウェア品質勉強会「開発とテストが一体となったソフトウェア開発」 で聞いた話を引き合いに出します。

ヤフーが「爆速」って言い始めたタイミングで、社内の体制が機能別組織から事業別組織(カンパニー制)に切り替わったようです。これにより、自分が所属する事業で採算が取れるようにすることが必須になったと。

<補足>
1つのチーム(これがイコール「事業」ではないようですが)の構成は、エンジニアが多くて8人くらい、に加えてビジネスの人1,2人+テストエンジニア1,2人、がいる規模だそう。リリースは1週間~2週間に1回。
</補足>

それで何が変わったかというと、それまでテスト担当者は、ばっちりテストをすることで給料をもらえてた。だけど、カンパニー制になったことで、いくらテストをうまくやってもカンパニー自体が利益を上げなければ給料もらえない状況になった。とのこと。

その時の言葉で、

何のためにいるのか?を職責で分けると「プロダクト売れてないけど、テストちゃんとやってるので給料あげてくれ」が起こり得る(ビジネスなんか知らねぇ、的な)。それじゃやっていけない。

というのが印象的でした。

その後、テストエンジニアたちは、テストの内容を変えたり、中にはテスト自体をやめて別なことで事業に貢献する、という判断と行動をした人が出てきたそうです。

「あるべき姿」に話を戻します。

この場合の「あるべき姿」は「カンパニー単体として利益を上げること」(実際はもっと求心力のある言葉でミッションが定義されていると思いますが)なんだと思います。そのための手段として「これまでやっていたのと同じテスト」が本当に必要なのか?を問われた結果なんだと思います。

それを判断するためには「我々には何が必要なのか」(我々のゴールは何か)の共通認識と、「今の状況」を俯瞰できることが大事なハズ。そしてそれは「誰かが俯瞰できる、誰かが俯瞰してくれてる」ではなく「みんなが俯瞰できる(あるいは俯瞰しようとしている)」が大事なことだと思うんです。それには皆が同じ情報にアクセスできる仕組みが必要だし、自分から情報を取りに行く姿勢も必要です。持ってる情報が違えば「私とあなたが考えるあるべき姿」が大きくズレていきます。

時間もコストも有限なので「あれもこれも」はできません。「あれかこれか」で選択する必要があります。その中で何を選ぶか。今回の話の流れで言えば「ゴールに近づくためのもの」になると思います。



(いったんここでおしまい)



こういうことを考えていると、私は「全体最適部分最適」というワードが浮かびます。「部分最適じゃなくて全体最適なことをしよう」がセオリーですが、「何が全体最適なのか」に全員が同意できることがまず大変なのと、「全体最適を求めるのが、その時点での最適解か」という問もあります。全体最適を実現するための労力と、目の前のことを(全体最適ではない方法で)解決する労力。おそらく後者の労力の方が小さくて済むし、後者が将来に必ず負債になるとは限らないじゃないですか。全体最適解でないと先に進めない、だとスピード感が失われると思うんです。

さてどうしましょうか。

「状況によるのでよく話し合って決めましょう」が結論だと面白くないのであえて私の答えを書いてみると、誰かが決めればいいって思います。人任せという意味ではなく、お互いが理解していること、背景・経緯を出し合って、それでも意見が対立してたら先に進まないので、それを踏まえて誰か(おそらく責任者、リーダー、オーナーと呼ばれる人)が決めるしか無くないですか? 絶対の正解なんてない世界なので少しでも前に進んだほうがいいと思うんですよね。もちろん、そういうふうに進めるんだという合意とメンバー間の信頼関係があった上でですけど。



明日のGaiax Advent Calendar 2016はナイスミドルな@hige-taharaさんです!

久々にプラモデルを作った話

久々のブログ更新です。QAとかテストから離れてしまっているのでブログ名も変えてみました。なんか思うことがあったら書いていこうかと思ってます。今回はミデアの話。

f:id:sakaimo:20161210200429j:plain

おそらく20年ぶりくらいにプラモデルを作りました。機動戦士ガンダムに出てくる地球連邦軍の輸送機「ミデア」

なぜミデアかというと、社内で使う効率化ツールを作っているのですがそのプロジェクト名をミデアにしたからです。せっかくだからプラモデル組み立ててプロジェクトリリースまで飾っておこうかと思いまして。詳細は控えておきますがプロジェクトの内容もミデアにちなんでいるのです。ほら、プロジェクトの見える化って大事じゃないですか。(最後はドムに落とされるじゃないかとか言わないで)

プラモデルに触れること自体が久々すぎて、組み立てるために何が必要かも忘れてしまったので、とりあえず必要なプラモデル用接着剤を買いに隣駅まで行ってきました。ついでに棒ヤスリも買ってきました。合わせて400円くらい。ホントはニッパーも欲しかったのですが、プラモデル用ニッパーって意外に高かったのでハサミでなんとかすることにします。

今回、ミデアを作りながら思ったことがあるので書いてみます。

自分との闘い

まず第一にこれは自分との闘いであるということ。

説明書通りに組み立てれば(塗装は別にして)完成します。がしかし。ヤスリがけ、バリの処理、はみ出してしまった接着剤の処理など、どこまでやったら完成なのかと。じつに作業時間の7割はヤスリがけに使ってました。別に誰のために作ってるわけでもなく(プロジェクトメンバーに見せるくらいはするけれど)ほぼ自分の趣味でやってる作業なので、自分が良ければそれでいいのに妙に細かいところが気になってしまうわけです。自分の中での「完成の定義」が必要なわけですね。

↓ランナーから切り離したところ。多少多めに残してますけど。

f:id:sakaimo:20161210223046j:plain

↓余計な部分を整理したところ。

f:id:sakaimo:20161210223333j:plain

...ま、そんなにうまくない。

プラモデル作るのって性格出るなーと思ったです。組み立てた後に内側に入ってしまって見えなくなる部分なんだけど、なんかこう、自分が納得できるまで仕上げたい欲。これに塗装が入ってきたらこだわり度ハンパないんだろうな。

1つの作業に集中できる

パーツが小さく、集中していないと組み立てられない箇所がいくつかあります。音楽を聞きながら組み立てていましたが、手は離せないのでスマホがブルってもメッセージに返信するとか、そういう作業は対応できません。手だけでなく、目も離せませんでした。小さい部品の組み合わせだったり接着剤をいかにうまく付けるかとか、細かい作業の連続なので。結果として「ひたすらプラモデルと向かい合う」という修行のような状態になりました。これって「プログラムと向かい合う」のとは少し違った感じがしました。頭の使う部分が違うという感じもしたし、実際に手(指先)を動かしてものを作るというのが今の私の日常には新しい刺激だった気がします。

おまけのドムが最後の難関

このプラモデルには3体のドムがついています。そう、黒い三連星です。こいつらですがドムの前面と後面の2パーツに加えて、ドムバズーカを持った右手だけが別パーツになってるんです。

f:id:sakaimo:20161210233540j:plain

↓手首の接着面が極小!!どうやってつけろと。

f:id:sakaimo:20161210233946j:plain

↓手首だけだと不安だったので腕部分も接着しといた。

f:id:sakaimo:20161210234133j:plain

↓3時間?4時間?くらいかけて完成しました。塗装は始めからあきらめていたのですが、シールは貼ってみました。(私が小学生のころに作ってたプラモデルのシールって、水に濡らして貼るタイプ(水転写デカールというらしい)だったのですが、最近のは普通のシールなんすねー。ピンセットでつまんでペタリ。

f:id:sakaimo:20161211000841j:plain

↓プロの仕事はここまでやるらしい。(この塗装は不可能だろ...)

f:id:sakaimo:20161210233655j:plain

せっかく作ったので写真撮るか

ここまでの写真は作りながらスマホで撮ってたのですが、翌朝にマクロレンズを引っ張り出して、デジタル一眼レフカメラ(Canon7D)で写真を撮ってみました。

f:id:sakaimo:20161211114222j:plain

f:id:sakaimo:20161211114446j:plain

うん、ミデアもドムも黄色なので全く雰囲気わかんないですねw 見た目って大事。

↓実際はこんな感じでした。もっといいシチュエーション(ジオラマ?)揃えたい欲が出てきたw

f:id:sakaimo:20161211114712j:plain

感想

せっかくプロジェクト名にしたからプラモデル作って飾っといたらウケるかな、から始まったのですが、作ってみたら意外に楽しかった。そしてこの20年でプラモデルも進化していて、接着剤不要だったり、始めからパーツが塗装されたり(プラモデラーからしたら邪道なのかもしれないけど)して、なんだかすごいことになってるみたいです。

あと、ワンフェスに行きたくなってきた。(撮る方で)

Ques#8 VR元年、QAしようゼッ! 感想とメモ

第8回Quesのレポ

イベント告知ページ 第8回Ques #ques8 : ATND

今回のテーマは「VR元年、QAしようゼッ!」ということで、VRサービスのテストや品質について。

発表は3本立てでした

  • はじめてのVRQA
  • Pepperアプリケーション開発で気をつけるべきこと
  • GRID VRICK VRインタラクティブコンテンツ開発の話

先に感想を

ヘッドマウントディスプレイ(以下HMD)などのハードウェアも含めた品質保証をするにあたって、どんなところを大事にするか(どんなところを検証するか)、がとても興味深かった。
これから普及してくるであろうサービスなので、これにともなう「品質」も何をもってOKとしたらいいかを自分たちで考えていくところから始まっていて、産みの苦しみはあるのだろうけれど、QAとしては「俺達が作る!」みたいな意気込みになっているんだろうなと推測。楽しそうだ!

Pepperと「人工知能機械学習」あたりは親和性が高そうだし、GRID VRICKのように「リアルと仮想が一緒になる」ようなサービスも面白い。これがどんなサービスになりそうかはイメージできていないのですが、まず最初の感情として「楽しい!」って思えるのが大事なんだろうな。

以下、資料がアップされるかもしれないけれど、私のメモと感想。 スライドすべてはメモれなかったので、私が気になったところだけ。 スライドの内容と私の感想を一緒に書いてしまいましたすみません。。。

発表1:はじめてのVRQA

グリー株式会社 WrightFlyerStudios事業本部
大塚 直英様

VRQAは非機能テストが重要

  • VR酔い
    • どのように解決するか、がキモ
    • 実際のカラダと、感覚のズレが不快感=酔いになる
    • ズレがどこで発生するかをみつける作業
    • 各画面ごとのズレを主観で3段階で評価(n=10人以上)
    • その結果をどう判断するか、は悩みどころ(例:8人中2人が「ちょっと酔う」)
    • 対応例:1人称視点から3人称視点に変更する
    • (VR体験者が少ない時代で、VR酔いを体験すると二度とVRに触れない、という状況は作りたくなかった。カジュアルVRというコンセプトがあった)
    • 一方で3人称視点はVRならではの体験が減る
      • ユーザーが求めているのはVRならではの体験。1人称視点

この後も「VR酔い」がフォーカスされていて、こんなところがポイントになるのかと思ったです。これを評価する方法も「複数の主観でテスト、数字で表現する」というやりかたなのですね。

VR酔いをどうテストしたか

  • 要因
    • 移動、加速、減速、音声の発生源、遅延、視野角など
    • Oculusベストプラクティス、ってのがあるらしい
  • 種類
    • 吐き気、頭痛、目が疲れる、めまい
    • SimulatorSickness Questionaire が参考になる

VR酔いのテスト項目

  • オープニングでの酔いの有無
  • 画面Aでの酔いの有無

など、それぞれの画面(およびそこで起こるアクション?)で、「酔いチェック」するらしい。

わかりやすさ

VR最大の問題 → 手元が見えない

  • 手による入力操作の難易度があがる(キーボードからの入力はまず無理)
    • ゲームパッドがギリギリ
    • 視線で操作させる(一点を見つめると選択される)方法はある
  • 説明書・攻略サイトがみえない
  • プレイヤーが見ている方向で条件が変わる
    • その時の向きによって、「右を向け」みたいな指示ができない。
  • 対策
    • 説明文を表示させる
    • ゲームの演出として視線を誘導する(蝶を飛ばして、そこに視線を移動することで次の操作を教えてくれる)

わかりやすさのテスト項目

  • ゲームの目的が理解できるか
  • 次に何をすれば良いかわかるか

を判断するために、テスターにテストプレイしてもらう

プレイ時間

  • プレイ時間が長いと疲れる
  • テストすると疲れる
  • 5分を超えるとつかれる、という声が出る
  • 2~5分が今のところ良さそう
  • 画面の切り替わりが早いと目が疲れるという意見も
    • MenuやLoadingの画面、表示
    • Loadingが早過ぎる(すぐ出てすぐ消える)と逆に疲れる

VR特有の機能テストが、品質特性ごとに分けられてました。

@HelloTakuyaさんのツイート

テストする環境

機材確保

  • テスターの大量投入ができなかった
    • HMDの台数が確保できない(発売前だった)
    • スペースの確保
      • センサーを使う仕組みのため、1台あたりのスペースが広い
      • PCとHMDとカメラと。。。
    • VRを動かすためには高性能なPCが必要(1台うん十万円)

→ 少人数を、テスト期間長めで実施することで対応

人材の確保

  • VRテスト人材で一番注意しなければならないこと → メガネ
  • 必要な人材像
    • PCの3Dゲームが得意、テスト経験
    • 3D酔い(VR酔いではなく)しない
    • 探索テストが得意
    • ゲームエンジンでゲーム開発したことがある
    • VRゲームを遊んだことがある
    • (メガネをしていない)→最近のHMDはメガネ対応しているので大丈夫w

テストツール

  • 画面キャプチャ機能は必ず用意する!
    • HMDを装着したままキャプチャできるといい
    • 不具合が発生したときの画面を撮るのは必須
  • FPS表示機能 (flame per secconds)
    • フレームがリアルタイムに表示されるような機能
    • あとで見返せるようにFPSロガーがあるといい(どこでフレーム落ちが発生したか)

こゆの面白い。

今後のVRQA

  • VR酔いの評価方法

    • どこまで許容できるか
    • 定量的に判定できるか
  • テストする環境

    • テストスペース確保
    • 今後はネットワーク対応 ←そのテストを行うための人数
    • イベントなどでの使用を想定したテスト
      • イベント期間中の長時間動作
      • デモ用のオペレーションの用意
  • テスト支援ツール

    • HMDを装着したままバグ報告を行える機能があるとサイバー

サイバーすごいw HMD外さずにバグチケット起票できるとかね。そんなテスターが数十人いたとして、その場を見学してみたい。

まとめ

  • 酔い対策 vs VRならではの体験
  • 人材、機材の用意も入念に
  • VRQAはまだまだ発展段階

Q&A

Q: テスターの規模は? A: 東京ゲームショウに出したのは2名で一ヶ月。製品レベルだとこれの2,3倍か

Q: エイジングのテスト(発熱とか) A: 本格的にはやってない。夜中動かしっぱなしで大丈夫か、くらい。イベント対応で8時間連続動作は担保した


発表2: Pepperアプリケーション開発で気をつけるべきこと

株式会社ネクスト HOME’S事業本部 業務支援推進部
流通ネットワークユニット
上津原 一利様

Pepperについて

人型のコミュニケーションインターフェースである。
ロボット、というといろんなことができそうな気がしちゃう。

部位 役割
頭脳 クラウド
デプスセンサー、カメラ
手、頭、足元 タッチセンサー
タブレット アンドロイド
頭部マイク
耳スピーカー

勝手に話しかけてくる、タッチセンサー付Siriとのことw

「ユーザーが思うPepper」と開発者のギャップ

実際はロボットじゃなく、先行者

  • 脳になるクラウドは公開されていない
  • 都合のいい機能は無い
  • コミュニケーションのシナリオも自分で作る

ユーザーは「Pepperは自分で考えている」と思っている。このギャップ。 ユーザーが期待する体験のレベルは非常に高い

頑張ったけどがっかりなコンテンツになる

これをいかにすり合わせていくか、期待に答えるようにするかが課題

ロボットコンテンツの体験づくり

  • 体験ストーリー
  • ストーリーに必要なコンテンツ(タブレットUI、アニメーション)
  • 実際に実行
  • 改善を繰り返す

特有なのは「会話をする」
いろいろ省きながらユーザーを誘導する
大事なのは、最後まで体験してもらうこと

Pepperはコミュニケーションがメイン。コミュニケーションができなければ人はすぐ離れる。だからこそストーリーが大事。

円滑に話をする。話を面白くする。最後までコミュニケーションする。

QA時に考えるべきこと

  • どういう場所?
    • 状況に合わせた対応。銀行?家電屋さん?
    • 屋外はNG
  • Pepperの役割は?
    • メイン?アシスタント?
    • 途中で止まることもある。音声認識できないこともある
    • アシスタントとして使うのがオススメ
  • どんな人がくるのか?
    • 大人、子供、ビジネス
    • 子どもと大人で、話しかける位置が違う
    • 子供は本気で殴る
  • どんなものならユーザーは喜ぶのか?
    • 面白い?ためになる?
  • ユーザーが何を手に入れたら成功なのか?
    • 好印象?商品購入?
  • ユーザーの抱いているPepper像は?
    • かわいい?カッコイイ?賢い?
    • どんなPepperなら受け入れられるのか
    • 声が変わるとユーザーは驚く(声色が変わる、しゃべり方が変わる)
  • 途中でユーザーが諦めないか?
    • 問いかけは正しいか?
    • Pepperにしゃべりかけたいと思えるか

↑主観、だけど、コミュニケーションインターフェースなので、ここ大事。

  • 肯定の選択肢
    • はい、うん、そうだね、そうだよ、イエス、おっけー、いいよ、、
  • 否定の選択肢
    • いいえ、ちがう、だめ、嫌い、やだ、いらない、、、

など、判別しやすい回答が返ってくるような質問をするようにプログラムしておく。

展示場の例

住宅展示場のイベントスケジュールを話すだけ。要件は満たしたがユーザーはがっかり。→その場で、ユーザーが話しかけてくる単語に反応するようにした

「こんにちわ」「かわいい」「おはよう」など。

ひとこと返事して、スケジュールをアナウンスするとウケるようになって、コンテンツも読んでくれるようになった。

よりよいロボットコンテンツへ

  • Pepperというだけで受けるのは今だけ
  • キャラクターと立場が活きる
  • コンテンツづくりが大事

Pepper(ロボット)だから許せる、かわいい、おもしろい、わかりやすい

人が聞いても答えてくれないけど、Pepperが聞くと話せちゃう。 それを収集する→ビジネスに活かす

↑確かにこれ、今のGoogleだって「知らない間に情報を取られている」ことを考えると、こういう手段での情報収集って熱いよなと思いました。これをPepperにやられると、、、なんだろう、へんな気持ちw

クオリティ=コミュニケーションデザインが問題なくできているか?
アニメーションがしょぼいとかはいい、コミュニケーションがおもしろいか がキモ


発表3: GRID VRICK VRインタラクティブコンテンツ開発の話

株式会社ネクスト グループ経営戦略部 R&Dユニット
リッテルラボラトリーグループ
上野 哲史様

GRID VRICKのデモムービー


GRID VRICK

レゴで部屋を作ると、VRになる レゴをOpenCVで解析、UNREALでCGにしている

大事なこと

  • 家造りの楽しさ
  • 現実と同じリアリティ

  • 楽しい体験、わかりやすい操作

  • 画像解析
  • リアルでインタラクティブな3Dコンテンツ
  • (余談)エンジンとの戦い

楽しい体験・わかりやすい操作

  • 3Dコンテンツ作成の課題
    • 作るのが大変 → ブロックで簡単組み立て
    • 知識が必要 → ブロックで直感的
    • 一人しか操作できない → 何人でも
    • 作業つらい → 触れてたのしい

ブロックとタッチディスプレイで解決!

VRの課題

  • VRだとHMDしてる人しか楽しめない
    • →ブロックの配置をリアルタイム反映。VRの内外で一緒に楽しめる
  • 操作が難しい
    • →操作を分割
      • ブロック:家の構造作成
      • PC画面:インテリア変更
      • VR:ウォークスルー
  • 様々な場所でのテストと改善
    • 社内、イベント出典
    • 学会、勉強会
    • ユーザーの行動を観察(Occuralしながらブロック並べるとかw
    • 筐体の形も改善。

画像解析

課題

  • 照明環境への対応
  • 影の影響
  • 認識物(ブロック)以外の除外

→ブロックの色判定

対策

  • キャリブレーション用のブロックを配置
  • 照明安定用ライト(真上から当てると反射するので角度を持たせる)

リアルでインタラクティブな3Dコンテンツ

数人で開発。経験も少ない

パフォーマンスとの戦い

課題

  • 照明が増える(太陽光、反射光、照明、、)と重い
  • インタラクティブなもの→さらに重い(リアルタイムに変更する

対策:現実とは異なるが、リアルに見えるように

  • 天井ライトを互いに被らないように設置
  • 画面外、今いる部屋以外のライト無効化
  • 反射光を下からのライトで擬似表現
  • 全体光

現実の写真と見比べると違うところはある。が不自然と感じなければOK

パフォーマンス

  • モデルのポリゴン削減
  • オブジェクト数減らす

VRへの対応(これから)

  • インタラクティブ性を重視した、ある程度のクオリティのコンテンツ
  • クオリティを重視した静的コンテンツ
  • そろそろ発売されるGTX1080(グラボ)に期待w

エンジンとの戦い

  • オブジェクトをたくさん置くと、、、オブジェクトが光るw

    • エンジン側のバグ。半年後に直った。
  • コンパイルすると関数名が戻る

    • 原因不明
    • 設定ファイルで回避

テスト、QAの話

課題

  • UXはトラディッショナルなテスト技術では評価が難しい
  • ユーザーの「どの感覚」を計測するのかの検討が大事
  • ハードウェアリソース使用量など、性能評価(合否基準の設定など)が難しい

まとめ

  • アナログ多し
  • 体験の質の向上は、様々な人の反応から
  • 3Dコンテンツのクオリティは「リアルに見える」ように作成
    • 現実と同じ構造では作っていない(省いても不自然に感じないものは無くす)

JaSST'16 で Web.JaSSTに登壇しちゃいました!

縁あって JaSST'16 Tokyo 初日のB2セッション「Web.JaSST ~ウェブ開発のテストや戦略~」のパネルディスカッションに登壇させていただきました。

f:id:sakaimo:20160314164204p:plain

パネリスト:左から

なにこのメンツ。恐れ多いわー。。。

JaSST TokyoでWebのセッションができたのは去年(2015年)からで今回が2回目です。去年は聴講者として聞いていました。その時にも思ったのですが、Web業界といってもイメージするものがみんな違う んですよね。それだけ多様なサービスが存在するということですよね。

現時点での私の「Webサービス」のイメージとしては下記のような感じでしょうか。

  • インターネットと繋がっている
  • PC、スマホガラケーのブラウザで操作する
  • あるいはスマホのネイティブアプリとして操作する

※ 個人の感想です。もっとうまい定義はありそう。

例えばですが、

プレステやWiiがネットにつながっててもWeb系とは言わない気がするのですが、スマホアプリのゲームに関してはWebとゲームが融合されてる感じがします。そしてパネラー4人のうち2人がスマホゲーム専門ていうねw

ネットは広大だわ……

こうなってくると「Webのテスト」というキーワードだけで人が集まっても、話が全く合わないことがあります。

上記のようなジャンル(?)の違いもあるし、ビジネスとしてBtoC なのか BtoB なのかによっても違いそうです。根拠レスですが「Web業界」というと、SNSやゲームのようなBtoCのサービスがイメージされるんじゃないかなと思っています。また、プロジェクトに関わる人数や、開発プロセス組織構造や、売上やユーザー数などの規模の違いもありますよね。

今回のパネルディスカッションでは、

  • 藤澤 正通 (ネクスト)→ BtoB / BtoBtoC
  • 境野 高義 (ガイアックス)→ BtoB
  • 柿崎 憲 (ミクシィ)→ BtoC
  • 山本 健 (グリー)→ BtoC

というラインナップかなと思いました。

パネルのお題

3つのテーマ、および会場からの質問に対して各人の意見を出し合いました。

  1. Webのものづくりってテスト計画や戦略が乏しいと感じますか?その辺を強化した事例などありますか?
  2. レガシーなシステムなどで仕様書などのテストベースが乏しい場合のテストのテクニックがありますか?
  3. リリース判定などでリリース前に意見を求められた際に判断材料が乏しい場合にとる行動やテクニックなどありますか?

この記事にはパネルの中身ではなく、私自身が印象深かったことを書きます。

新規サービスにQA(をちゃんとやること)は必要か

私にとって今回のセッションで一番衝撃だったのはこの話題でした。(パネルのお題ではないけどw)

この問に対する私の回答は 「新規サービスの場合は品質よりもスピード重視して、リリースして顧客に価値を問うて、違ったらやり直す。その場合、テストしすぎてもサービスが当たるかわからないので、無駄になるかもしれない。だからQAにコストかけないのが正解じゃない?」 というスタンスです。

これに対してミクシィの柿崎さんから「残念だ」ってコメントもらったのが衝撃だったw 柿崎さんは 「サービスをブーストさせるためにQAを入れて品質を高める!」 というスタンスでした。

...このセッションが終わった後に疲れ切ってしまい、会場の前にあったドトールでホットカフェオレ飲みながらこのことを考えていたのですが、ここでもやはり議論の前提条件が違った可能性はあるなと思ったです。

私が思ってる「新規サービス」って、リーンスタートアップでいうところの「価値仮説」を検証してる段階のものをイメージしてましたが、柿崎さんがブーストしているものはすでに価値仮説が検証されている(ゲームとしてウケるとわかっている)モノで、より「成長させていく」フェーズだったのかもな、いやそうに違いない!って思い至りました。

レガシーなシステムってどんなもの?

前提条件の違いについてもう1つ。

「レガシーなシステム」をどうテストするか、というお題について、議論の終盤になってみんながイメージしてる「レガシー」が異なってるなと感じてたのですが、タイミング逃して確認コメントを挟めなかったです。。。

レガシーなシステムとは?に対しては「テストコードが無いシステム」というのは回答になり得ると思うのですが、その場の話の流れと会場の反応からは「使われてないシステム」とか「メンテされてないシステム」とか「古いシステム」というのをイメージしてる人もいそうだなと思いました。

使われてないシステムなら捨てればいいし、「メンテされてなくて古い」けど「ちゃんと動いてる」なら何の問題も無いし。ただ、そこに機能追加しようとした時に、内部品質が悪くて迂闊に手を出すとどこに影響あるかわからない、みたいなときにどうするか、ってことかと思いました。

正常系(何を持って正常というのかは自分たちで決める)だけでも自動でのE2Eテストを用意しておいて、そこから機能追加する、がいいかと思いました。E2EテストはSeleniumとかCucumberとかCapybaraとかTurnipをイメージしてます。その上で、今後作るものに対しては将来の自分たちのためにテスト書こうよ(ここでのテストは開発者が書くテストコードをイメージしてます)というのが着地点かなと思いました。

E2Eテストを用意する工数は与えられない、という現実はありそうですが、、、理想論過ぎますかね?w

アジャイルっぽくするとスマートになりそう

ミクシィの「ITS/BTS至上主義」の話はアジャイルに通じるものがあって、なんというかスマートな印象を受けました。

柿崎さんの話を私なりに解釈すると、

  • 全ての課題はチケット化され、いろんな役割の人がそのチケットに関わっていく
  • 例えば企画の人がその機能が必要な理由や背景を書いて、
  • それに対して設計・実装者がだったらこうやるよ、ってコメントして、実装し、
  • QAがそれを見て、だったらこんなテストして、結果はこうだったよ、を記入し、
  • その間、関わってる人はチケットの状況を把握していて、ズレてきたらその場で方向修正して、、、
  • で、条件が満たされたら実装完了としてチケット閉じる、と。

そうすると、最初は仕様(書)は無かったけど、そのチケットを見ればその機能に対する仕様(書)になっている、と。なにこれすごい。さらに、開発とQAだけでなく、関わる人全員が「何がどうなってるか」が把握できている、と。

弊社でもスクラムを取り入れて開発してるプロジェクトが増えてきました。チケット(ユーザーストーリー)に分けて、各ストーリーには完了条件が定義されていて、優先順位の高いものから手を付けて、割り込みが発生したら都度優先度を見直す、と。

このやり方はWeb(少なくとも弊社が扱っているようなサービス開発)とは相性がいい気がします。

最後に

私がJaSSTというイベントを知って参加するようになってから7年目。初めて参加した時の印象は組込みとかSIerの事例とかが多くてダイレクトに共感できる感じではなかったのですが、この数年でJaSSTの中にWebセッションができるし、JaSST以外のテスト界隈でもWeb系の人が増えてきている気がしています。しんすくさん がいうところの 軽量品質保証 の考え方って共感できるわー!みたいな業界の人が増えてきて、私としては楽しくなってきたなーと思います。意見交換とか事例紹介とか、もっとオープンにやっていきたいですよね!(何かを教えてもらう、というよりも、困ってることに対してみんなで解決策を出しあう、みたいな場の方が楽しそうな気がする)


クックパッドエンジニアのトークナイト〜テストエンジニアvol.2 Testing編〜 感想

2015/11/26 に行われた クックパッドエンジニアのトークナイト〜テストエンジニアvol.2 Testing編〜 - connpass に運良く(倍率3倍)参加できて、とても内容が良かったので共有します。

当日の資料が公開されましたのでリンクしておきます。

speakerdeck.com

感想

JaSST、Ques、TestingCasualに参加したことがあるのですが、品質とかテスト関係のイベントとしては今回はだいぶ新鮮というか、新しいアプローチというか、一言でいうと来て良かった。抽選に当たって良かった。vol.1ではBDDとかTDDとか、Checking(正しく動くことを確認する)視点での話がされたようで、なんで私は落選したのだろうかと。そこ(も)聞きたかったよと。

今回の発表で下記のワードが出たかどうか分かんないけど、私的なキーワードとしては

  • 探索的テスト大事 (多分このワードは発表内に出てこなかったけど)
  • フィーリング大事
  • 全員がテスター

でした。

今回の発表内容と、松尾さんからの「技術の寄った話は(勉強会などで)されるけど、人に寄った話はあまりされない」というようなコメントを聞いて、この視点での開発者-テスター両者共通のコミュニティができたら面白いなと思ったです。

今回の勉強会に対する私の感想をまとめると、「結局はユーザーの手元で(製品の形で)ユーザーがやりたいことができるのかが大事なんだから、テストする対象もユーザーに出るのと同じものでやるのが一番効率がいいし、最近の流れから言えばチーム内で役割を分けるより小さいチームでみんながいろんな役割をやれるほうが強いチームなんだからプロジェクトマネージャも企画も開発もテスターもみんなでテストすべきだし、良い(バグを多く見つける)テストをするためにはテストの時だけ頑張ればいいんじゃなくて日常の中から「なんか変だぞ」って感じるところを大事にすべきだし、そこについて追究できる文化・空気感がいいよね」 って、まとめが長くなりました。

長い上に補足しちゃいます。(ごめんなさい、こんなテンションになっちゃうくらい楽しい会でした)

「フィーリング」の話は発表資料を読んでいただければニュアンスわかっていただけるかと思いますが、そのフィーリングの感度を高めるためにやってること(朝会での開発者との会話とか、過去チケットあさるとか)ってのがあって、そういう視点が自分に無かったなーって思いました。

印象的だったのは懇親会で関さんから聞いた "全員がテスター" の話。(クックパッドの例ではないですが)開発者も1日1時間テスト(システムテストレベルの手動テストね)をする時間が持つことで、最終成果物に自分たちで責任をもつ、と。クックパッドでも同じようなスタイルみたいです。(手動テスト専任の人はいないという意味で)

語弊があったり、誤解を生じる書き方かも知れませんが 敢えて書くと、その場合のテストには(テスト設計コンテストに出てくるようなちゃんとした)テスト計画とか、テスト設計とか、テストケースすらも必要ないんじゃないかと思うのです。(何がどうなったらその機能が動いてるといえるのか、みたいな「実装完了条件」みたいのはあるべきだけど)

...という話をする時の私の前提は

  • 開発対象は週に一回リリースするWebサービス
  • アジャイルっぽい開発プロセスを採用していて
  • 開発チームは4,5人で(プrダクトオーナーは別なイメージ)
  • そのチーム内でテストOKになったらリリースする
  • テスト専任の人は1人いたりいなかったり
  • リリース後に不具合が見つかっても修正すれば即時に全ユーザーに適用される

というプロジェクトなのですが、そこに「テスコンのような"ちゃんとした"テスト設計(の活動)」が入り込む余地が無いと思っています。なぜならテストベースが(ドキュメントとしては)無い、あっても曖昧、話し合いの場で決まる、後で変わる、な上に週に一回リリースするというサイクルにマッチしないからです。

一方で「テストをする」という行為は存在するわけで「良いテスト=少ない工数でバグが多く見つかるテスト」を行う際に、テスト(設計)技法を駆使したほうがより良いテストができるかもしれないとも思っています。テスト実施者がテスト設計を知っている・身につけていることは有効かもしれないと思います。わざわざ「かもしれない」と書いたのは、テスト技法を知らない人でもバグをいっぱい見つける人はいるので、技法を知っていることとバグをいっぱい見つけられることにどれくらいの相関関係があるのか(私の体感値として)不明だからです。なので「テスト設計うんぬんよりも、全員で製品を触ってみる(というテスト)」の方が有効なんじゃないか、って思ったわけです。

※ここは誤解してほしくありませんが、今回の勉強会でそう言っていたわけじゃなく、これは「この勉強会に参加して、私が思ったこと」です。

そういうプロジェクトの進め方をする時に大事なのが、今回の発表に出てくるフィーリングというか、なんか変だぞと感じれる能力と、そこに至るまでのアンテナ感度上げる努力と、それを追究できる能力なんじゃないかと。この能力とそれをやる時間(ステークホルダーみんなで)を取ったほうが、結果として短時間でいいものが出せるんじゃないかと思った次第です。また、それを先導できる人がいたら強いチームになれると思うです。

懇親会の最後の方で(過去に弊社でもTDD研修をしていただいた) @t_wadaさんとTDD普及の話もできてとても良い時間を過ごせましたクックパッドさん本当にありがとうございます!

※ 以下、発表のメモです。スライド内の気になったところと、スライドに乗ってないコメントとか会場とのやり取りをメモりました。スライドに関しては上記の資料を見てもらったほうが確実です。

関将俊さんの発表

設計とテスト

  • ソフトウェア開発に必要なことは「設計」と「テスト」の2つ
  • テストとはバグを出すこと。エラーを見つけるのが良いテスト、という定義

CheckingとTesting

  • Checking

    • 既知の情報の確認
    • 待ち伏せ
  • Testing

    • 新しい情報を探す。未知の問題を
    • 探しに行く

感じる、壊す

「あれ、この製品、どこかが悪い気がする。。。」とか、退屈、使いにくい、不親切、、、というフィーリング →なにか悪いものがある

テストの前にフィーリングがある。「なにかおかしいぞ」を感じるの大事

私達のテスト

「感じる」

ポイントは「いつ、対象は、感じた後どうする」

いつ

  • 製品を目の前にして
    • 意外な振る舞い、使いにくさ、カッコ悪さ、過去の問題類似性
  • 朝会で話を聞いて
    • 普段の会話
    • PGの態度、言葉
      • 自信のなさ、アリすぎ
  • これまでの嫌なことから、、、

対象

感じた後どうするか

  • Feelingを理解する
    • 使ってみる、聞いてみる
  • 考えながら触ってみる
    • こうしたらどうなるか
    • こうなってたらユーザーは困るか

違和感を確信に変えていくフェーズ

松尾和昭さん

CookpadでどういうTestingをしているか。 いつだれが、どこで何をどのようにどうなるかを観察

観察する

  • いつもと違う?
    • (朝会とか)話の中で気づく。
    • 眠い、疲れた、とかそういうのを拾う
    • チーム、メンバーの雰囲気、空気、人のメンタル大事。
  • githubのissue
    • やり取りが多い
    • 関係者が多い
    • 話が複雑になってる
    • →これらの機能はエラーがおおい
  • チャット
    • 相談、話題、新しいもの、その他
    • 不具合対応とかで盛り上がってる→開発者が集中できていない
  • 席周辺
    • 人の往来、相談の回数
    • 技術基盤チームの近くにいて、そこに相談に来るときは技術的に難しいところ→その人が関わるissueを眺める
  • 製品を触る
    • 感情の変化、違和感という直感 ←人の直感は当たりやすい。コンピューターにまさる

感じ方をどういうふうに拡げていくか

  • 感じ方、知り方を拡張
    • 多彩な経験、考え、歴史、に触れる (本とかじゃなくて
    • 話す、見る、におう、触れる
  • 視点を動かして拡張
    • 大局と局所、全体と部分、組織と事業
    • 役割の切り替え、繋ぎ目(人の役割も、コードの繋ぎ目も)

何が変わるか、かわらないか

  • 変わらない、変わりにくい

    • 感性、考え方 ←25歳までに固まる。それ以降は変わりにくい
    • 変わるにはストレスがかかる
  • 変化することを知る

    • 動機(があれば変えられないことが変えられる
    • 環境(が変わると
    • 組み合わせ(が変わると  
  • ストレスを上回るだけの何かを見つけると動機付けになる
    • 振り返りの改善効果

(質問すればよかったなと思ったこと) → 社内でどれくらいこういう話ができるひと、ついてくる人、興味ある人がいるのかなー。

深谷美和さんの発表

朝会で知ること(朝会は30分~45分くらい)

  • 担当者のこと
    • 誰がどこをやってるか
  • もめていること
  • PGが混乱していること
    • チケット(実装予定)がわかりにくい
    • 実装者にきいてもわかっていない
  • PGが心配していること
    • ちゃんと作るし、ちゃんと作れるんでしょ?
    • 周りの雰囲気、声のトーン、不安、
    • 想像した心配ごとを開発者、テスターに話す
      • どんなテストをしようとしているのか

前提としてmiwaさんはコードはわからないけど、会話の雰囲気とかから感じる。その場でわからなければ朝会の後とかに聞きに行ってる。また、新人研修として、朝会で思ったことを2次会で報告することをやらせている。そこで鍛えられる、とのこと。なるほど。。。

  • 報告されたバグから多くのことを知る
    • 新しい視点
      • PGや他のテスターは何を気にしているか
      • 自分が思いつかなかったバグ
    • 知らなかった過去
      • 昔のチケットに遡る
    • 振る舞いをしり、誤解していた仕様

この辺り、miwaさんのブログ テスターは朝会から何を知るのか - CAT GETTING OUT OF A BAG に詳しく書かれてて参考になります。

Story2 あるチケットのTesting

チケットをよむ

<自分メモ> (チケットには実装要件が書かれてる。半日~二日間でできる粒度らしい)

  • 何ができるようになるのか
  • できたことはどやってらわかるのか(完了条件)
  • 実装中におきていること(実装中のことが書かれているのが前提ね)
  • 朝会とかでの情報アップデートもね

</自分メモ>

  • あやしい匂い
    • たくさん書いてある
    • 説明がコードっぽい
    • 調査中、苦戦中、、、
    • あっさりしてる、うまくいきすぎてる のも要注意

動かしてみる

チケットに書かれているテストケースを忠実に動かす

  • Checkingの気持ち
  • あまり見つからない

ファーストインプレッション

  • 初見に感じる「何か」を大切に
    • 自分の想像していたものとの「差分」
    • しばらくすると初見の「これ」を感じにくい
  • このあたりからTestingの気持ち

Testing

チケットにあるテストケース(正常系)を変形する

  • 何を与えたら、与えなかったら
  • 処理の途中を想像しながら、操作のタイミングを図る
  • 複雑なものほど丁寧に
  • 面倒なものほど落ち着いて
  • 匂いの種類、強さによってバリエーションを変える
  • などなど・・・

↑人によって得意なところが違う

関連する(かもしれない)機能との相性

  • 朝会で話題になってるところはできてる
  • 話題になってない、見えていないものを探す旅
    • 何を与えたら動くのか、それはどこからくるのか
    • 何が作られるのか、それをつかう機能、使いそうもない機能
    • 一緒につかっていたらどうなるか
    • チケットのキーワード検索(視野を広く)ひらめき

101 Things I Learned in Architecture School 「建築デザイン101のアイディア」 テストのひらめき、のエネルギーになる本だそうです。ゲシュタルトの「図と地」理論

テスターモードからユーザーモード

  • ユーザーはどんな気持ちでこれに触れるのか
  • 触れた時の手触り、見た目、全体としての統一感
  • 触れた後、ユーザーは何をしようと思うのか
  • ユーザーのユーザーのユーザー (cookpadの場合、ユーザーは料理をする人で、その先のユーザーは料理を食べる人
  • やりたいことが本当にできているのか

Q:どこでやめるのか A:時間で切る。やるべき全体に対して、勘だけどバランスとって「ここまででいいかな」で止める

過去に起きた嫌なこと

  • 自分のチームで起きたこと
    • 開発者、テスターとの会話から
    • 10年分の過去チケットから
  • 隣のチーム
  • ニュースになってること
  • 普段の生活から

これから起きるかもしれない嫌なこと

  • 朝会や日々の会話から
  • 試せない心配ごとは誰かに話す

昨日との違い

  • なんとなく遅くなったな、とか
  • 昨日は動いていたのに
  • 昨日と見え方が違う
  • 誰も触ってないけどあの機能が動かない

プログラマとの会話

  • 朝会の会話でわからないことを教えてもらう
  • 朝会で言ってなかったけど、雑談の中で聞いたら不安とか教えてくれる
  • 丁寧に教えてくれる
  • プログラマと一緒にTestingもある

プロと無職との会話

  • 直球
    • ここにバグがあるからためしてみて
  • 私のテストを止めに来るかかり

テスターとの会話

  • 気にするところが違う
  • おかしいと感じたことを同僚はどう感じるか
    • 自分が感じるおかしさ、への疑い
  • テストで会話
  • おかしさを見つけたら開発者の元へGO
    • 現象を見せる(手順を確定させなくても現象を見せる)
    • 何かを知りたがってるときがある
      • その場でTesting、再テスト
    • おかしさの原因がわかると嬉しそうに話に来てくれる

おかしさはいつどこからやってくるのだろう


まとめ

  • Feeling,感じたことを大切にしてくれる土壌
  • 人はミスをするという事実を受け入れる空気

Ques#7 メモと感想

2015/11/20(金)に六本木のヤフー株式会社で行われたQues#7のメモ。

第7回Ques : ATND

私の感想

会の全体の雰囲気として、とても良かったと思います。山崎さんの講義の中に、ワークとその結果について周囲の人とのディスカッションがあったからかな。会場の集中力が高かった気がしました。

ヤフーでのテスト支援チーム(正式名称じゃなかったらごめんなさい)の話ですが、現実として「開発チームが品質で困っている」という状況があり、「今のやり方じゃダメだ」と開発者が実感しているという状況がテストの自動化推進のポイントだと思いました。

青野さんの話もE2Eテストの自動化(画面からユーザー操作のシミュレート)でしたが、本来のアジャイルスクラムで言えば「ホワイトボックステストの自動化」が必要なわけで、ここらへんの導入・推進も気になりました。私のイメージですが、ホワイトボックステスト(つまりユニットテストというか、TDDというか、開発者が自分のためにコードで書くテスト)の導入って、結局は開発者自身が行うことなので、「支援」って難しいんだろうなと思っているところだからです。

にしても、100サービスあって支援チームが5,6人で、(全部のサービスを支援しているわけではないにしても)支援出来るだけの知識とスキルと「ガッツ」がないと実現できませんよね。。。

ベリサーブ山崎さんの「テスト分析」の話はとてもわかり易かったです。あぁ、そういうことだったのね、って思ったです。ただ、JSTQBの定義でもそうですがテストベースとしての「ドキュメント」がスタートになる一連の(分析→設計→実装...)行動なわけで、スタートアップ的なWebサービス開発(往々にしてドキュメントの作成とメンテが重荷になる)には適さないアプローチだなとも思いました。(思いましたというか前から感じてはいるのですが...)

「今の組織、チームで問題が起こっていないのであれば(プロセスをガラッと変えるようなことは)必要はない」みたいなことを話されていたのが印象的。個別の課題に対応することでOKならそれでいいよね、と。そりゃそうだよね。で、疑問に思ったのは、ということは今後のため、とか、未来を良くするため、という活動はどうなるのかな、ってのは気になりました。

(※以下、講演を聞きながらメモったので抜け漏れがあるかもしれないのと、私の言葉に置き換えているところもあるので、正しくは本人の資料を参照ください)

アジャイルとテスト自動化

登壇者:ヤフー山口さん

www.slideshare.net

チーム自らがテスト。テストだけやる人はいない。チームで決める。リリース権限はチームにある。

取り組んでいるテスト自動化

頻繁にテスト、はしんどい。それを自動化して楽する。
モバイル、Web、バックエンド(←これも頻繁にリリースしている)
全員でテストすることで品質を理解することができる

ヤフオクアプリでのテスト自動化事例紹介

登壇者:ヤフー青野さん

www.slideshare.net

自動テスト導入経緯

2015年4月ごろ、特定画面で100%クラッシュとか、古い端末、OSで100%クラッシュがリリース後に発覚。

当時は開発者+リリース前にみんなで確認。リリースは隔週。リリース時に全機能は確認できない。

Androidアプリ

  • 不具合修正→すぐ修正版リリース
  • 段階的公開機能あり→影響小さい

iPhoneアプリ

  • アップル審査が必要→時間がかかる
  • 致命的

テスト支援チームからテスト自動化しませんか?を提案
社内サービスを横断的に支援している
開発チームが支援チームに協力してもらう形

導入時ノウハウ

解決したいこと

  • iOSにフォーカス
  • 致命的なクラッシュは事前に検知
  • 主要画面もうら
  • 古いOS
  • iOS9対応に間に合う

ツールの選択

  • テスト支援チームで知見がある 結果→Appium

選択理由

  • OSS更新頻度が高い
  • 企業サポートも付いている
  • ライセンスがつかいやすい
  • クライアントが複数言語ある
  • GUIツールがわかりやすい
  • iOS,Andoroidに対応
  • テスト対象に手を加える必要が無い

テストコードを何で書くか

  • Pythonを選んだ
  • 経験者多い。誰が書いても読みやすい

対象画面

  • 主要機能の画面から優先度をつける

実行概要

  • macにgitからclone
  • スクショをとってファイルサーバーに置く
  • (メモれなかった)

苦労話

  • appium不安定 UI要素が取得できない
  • 処理の同期が取れない
  • デバッグに時間がかかる
  • アプリのUIにidが振られていない→xpath
  • 画面修正でxpathが変わる
  • pythonのunitテストドキュメントが少ない
  • 結局appiumサーバー、unit testのフレームワークをつくった
  • iOS9からxpath構造が変わった
  • appium自体のiOS対応が遅れた

導入の効果(半年くらい取り組んだ) 

解決したかったこと

  • iOSにフォーカス → OK
  • 致命的なクラッシュは事前に検知 → OK
  • 主要画面網羅 → OK (全画面の約9割をカバー)
  • 古いOS → できてない(サポート対象内だがiOS7ができていない→手動でカバー)
  • iOS9対応に間に合う → OK

やってよかった。

運用

  • 毎日1回定期実行
  • 開発用ブランチが対象。リリース前はリリース用ブランチでやる
  • 失敗したらすぐ調査、プロダクトバックログに積んでスプリントで対応

今後の予定

  • CIツールとの連携
  • 自動テストのバリエーション
  • 任意のタイミング
  • 処理の高速、並列化
  • アンドロイド対応

まとめ

  • 支援という形で背中をおされた (←ここ、サラッと言ってるけど開発チームと支援チームでいい関係ができてるんだろうなと思った)
  • 形になるまで試行錯誤
  • 毎日自動テストが実行される=安心
  • より恩恵を受けるための作業はまだある
  • (他社でも)導入ネタに使ってほしい

Q&A

Q:自動化で見る観点。何を確認しているか。画面遷移が正しいか? 例えば検索機能では、検索結果が正しいかの確認は?
A:画面遷移は見ている。検索については特定キーワードはみているが、検索結果件数とかはみてない。

Q:(テスト工数の)削減効果 (←メモしきれませんでした)
A:手動はまだ残っている

Q:チーム全員で品質を、とのことだが、意識は高かったのか
A:チームのメンバーは導入の方向は賛成だった。協力してくれている。1週間1スプリント。不具合修正は割込みタスクとして考えている。(スプリント内に収まる工数として)

Q:半年かけてやった人数
A:支援チーム2人、開発チーム1人、週一回集中して活動する。がっつりやったら一ヶ月で終わる

Q:1回のテストでどれくらいのテストがどれくらいの時間で完了するのか
A:スクショ取ると2,3時間。スクショなしで1時間くらいで終わる。

Q:支援チームがやることは?
A:必要に応じてやれることをやる。100サービスあって、全部には入れないので、極力やりかたを教えて自立してもらう

Q:支援チームは何人?
A:5,6人


概説テスト分析

登壇者:ベリサーブ山崎さん

(多分資料がアップされるハズ)

www.slideshare.net

「テスト分析」って何?どうやって説明すればいいの?

仕様書からテストケースを導出する → これは失敗フラグ

デキる人は脳内で何かが補完されている。

(スライドのP16参照)
テストベースをもとに
↓
テスト分析をして
↓
テスト条件を導出
↓
テスト設計(効果的にテストをするため)
↓
テストケースを導出
↓
テスト実装 何をテストするか
↓
テスト手順/スクリプトを導出
↓
テスト実行 作ったものを動くかどうか確認する行為

JSTQB AL「テストマネージャ」「テストアナリスト」のシラバスからわかることは、テスト分析とは、テストベースを分析して「テスト条件」を導出する作業

では「テスト条件」って何?

例)
・PWは4文字以上12文字以下の英数字のみ許容する
・PWを3分以内に連続して4回以上間違うと、アカウント5分間ロックする

この場合、

  • 文字列長
  • 文字種
  • 誤入力期間、回数
  • アカウントの状態(ロックか、正常か)

みたいのが「テスト条件」。表現の仕方はいろいろあるけど一例として階層構造にすると

スライドP27より

f:id:sakaimo:20151123001714p:plain

この場合、「セキュリティ」も「文字種」もテスト条件だが、粒度が違う。

テスト分析のメリット

  • 欠陥の早期摘出
  • テスト対象への理解
  • テスト容易性の判断 ←ここ大事。ミリ秒まで精度が求められるなら手動テストじゃ無理だよね、とかを事前に把握・共有しておく。

テスト分析の仕方(例)

  1. テストベースを3色で書き込む、読み込む、洗い出す
  2. マインドマップで思考の発散と集約
  3. ガイドとして「テスト分析の三角形」をつかう

分析結果は人によって異なる

これは大前提。一意的には決まらない。つまり「ゆらぎがある」。例えばエライ人がテスト担当者に任せておしまい、だと結果も(期待値と結果が)ブレる

だから重要なのは分析結果をレビューして、ステークホルダーとコンセンサスを得ておくこと。どんなテストをやるのか。

テスト分析を方法論化すると→出力形式が共通化できる→レビューが容易になる→テストノウハウとして蓄積できる →形式知となり組織に展開できる

方法論

  • HAYST法(ラルフチャート)
  • VSteP(NGT)
  • ゆもつよメソッド(論理的機能構造)

Q&A

Q:仕様書がない、あいまいな場合、要件は曖昧でコードはある場合、テストベースはコード。。。?
A:いい加減な仕様だと、いい加減な分析しかでない。ステークホルダーがどこまでやれば安心できるか(自分もエンジニアもそうじゃない人も)でどこまでやるか絞る

Q:どういう範囲で分析をするか。システム全体?何らかの基準で一部?
A:状況による。担保したい部分はどこか。(機能ごとで分割するとか)

Q:分割する、ということもテスト分析では?
A:その通り。システムを分割できることも分析の結果。粒度を細かくすればするほど工数がかかる。そこまでしなければ設計できないのか?


ポモドーロ・テクニックが調子良さそう

sakaimo.hatenablog.com

↑この投稿で「社内留学してます」という話をしたのが8月。そこから3ヶ月、毎日コードを書いています。実務でのプログラミング経験ゼロから始まり、すでに何度かのリリースを経て私のコードが世の中で使われてるって驚き(そしてバグってたらどうしようという不安...) ここまでの気づきとかは近々ブログにまとめます。

集中力ほしい

日々モニタと向かってコーディングしていると、集中力が長続きしない事があります。自分との勝負ではあるものの、集中力にも限界があります。

そんな中、私の隣で「ポモドーロ・テクニック」を使ってコードを書いてる新人がいてなかなか調子良さそうとのことなので、その影響を受けて真似してみました。ポモドーロ・テクニックとは簡単にいうと「25分作業して、5分休憩、これを4セットやったら長めに休憩」 のサイクルを回るようです。

ポモドーロした感想

今日は途中にミーティングがあったものの、10ポモドーロを回してみました。ちなみにポモドーロとはイタリア語でトマトの意味だそうです。今知った。

メリットとしては、

  • 今何をすべきかがはっきりする。これやってるときにあれも気になって、いつの間にかあれやってた、ということが減ります。25分で時間を切ることで、その時間に何をやって次に何をやるか、を意識できます。今やってることから派生してやることが見えたらメモしておいて別のポモドーロでやる、っていうルールにします。

  • 集中していられる時間が増える。ちゃんと時間を比較したわけじゃないですが体感値で充実感あります。ノッてるときにインターバル挟むと逆に効率下がるんじゃないかなとも思いましたが、インターバルの前後で継続した作業をするので”スイッチング”コストはかかりません。もちろん行き詰まったので次のポモドーロは別なことやる、ってことはあります。

  • 今日やったことを振り返れる。ポモドーロごとに何をやったか1行でメモしてみました。それを見て充実感に浸るもよし、無力感に打ちひしがれるもよし。ただ、「ひたすらコーディングし続けてた割には今日何やったけな?あれ?」ということは無くなります。

デメリットってほどではありませんが、

チャットのレスが遅くなります。その分集中してるわけだし、30分くらい待っててくれるだろうし、待てないくらい緊急なら直接来るから大丈夫。ポモドーロ・テクニック自体が「1人でする作業を効率よく」するものだと思うので、他の人とコミュニケーショ取りながらすすめる作業には向かないかもしれません。

まとめ

ポモドーロ・テクニック試してみて「こりゃ良さそうだな」と嬉しくなってブログ書いてみました。お試しあれ。あと1日の半分くらいをスタンディングデスクで作業すると体の調子が良くなる気がします。(夜もよく眠れるし)