HOME > 活動報告 > イベント報告 > JaSST'16 Hokkaido

イベント報告
 ソフトウェアテストシンポジウム 2016 北海道

2016年9月2日(金) 於 札幌市教育文化会館

ソフトウェアテストシンポジウム 2016 北海道
「つながるひろがる テストのミカタ」

台風が過ぎたばかりのさわやかな晴れの日にJaSST'16 Hokkaidoは開催された。オープニングの上田和樹実行委員長挨拶によると、シンポジウムテーマにおける「ミカタ」には「見方」と「味方」のふたつの意味があるということである。視野や人との繋がりを広げ明日からの仕事に活かしてほしい、との言葉を踏まえ、筆者の受講したセッションを以下に報告する。

S1)基調講演
「良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -」
(タイトルは講演時のスライドより)
山口 鉄平 (ヤフー株式会社)

山口氏はヤフーのシステム統括本部 技術支援本部に所属し、WEBシステムのアジャイル開発・テスト自動化などの開発改善、および組織改善に従事している。その経験から、良いモノを提供しようという、取り組みや姿勢、各種事例について話してくれた。

前提とする状況

ヤフーで開発対象となるアプリやウェブサービスは、競合他社の状況がわかりにくく、お客様に響くサービスの正解も存在しない。

そのような開発で目指すのは、不具合の少ない開発、および素早い提供である。「早さ」も併せて品質の内であり、早くリリースしてフィードバックを得て改善に繋げるのが開発の基本方針ということだった。

ヤフーでは、ビジネス(企画等ビジネス面の担当者)、プログラマ(ソフトウェア開発担当者)、デザイナ(デザイン担当者)、テスト(品質担当者)の各役割の担当者が集合してチームとなり、それらの集まりがカンパニーを形成する。実施方法が規定されているセキュリティやブランドに関わるプロセスを除き、その多くは各組織に委ねられ全社的な標準プロセスは絶対ではない。

現状に至る過程

組織の変化前の状態として、承認プロセスは次のようなものだ。

ビジネス部門から開発部門へ発注がある。その後の開発物をもって、QA部門へリリース承認の依頼をする。許可が下りればビジネス部門経由で開発部門へリリース依頼があり、無事リリース、というプロセスである。

このときの課題は、ビジネス部門・開発部門・QA部門の連携がしきれず、業務目標の不一致や、情報の伝達速度と精度の低下により、リリースが遅れるというものだった。

課題解決のためにヤフーではQA部門のリリース承認権限をサービス部門へ権限移譲を進めていった。その間、アジャイル開発を社内標準として推し進め、サービス単位のチーム再編と承認プロセスの削減に踏み切った。続けて開発チームへテストメンバーの参加を開始、品質向上組織の統合後に開発支援組織への品質向上組織の統合を行った。

明日からのアクション

明日から取れる改善のためのアクションとして、山口氏は以下のような基本的な考えを述べた。

良い開発に向けチームや組織で努力すること。そのためには考え方を変える。ひとりではできないし、作業だけでお客様は満足しない。せっかくリソースを割いてお客様に喜ばれないものを作るのはもったいない。

プログラマは、自分たちの開発物を利用者の気持ちで使う。テストに関する技術を学び、実施する。

テストエンジニアは、プログラマが作ろうとしているものを知り、それに対する疑問を発信する。プログラミングに関して最低限の知識を身につける。

そして両者が、コミュニケーションを容易に取れるよう、定期的に話す場を設けたり、席を近づけたりする。

まとめと筆者感想

良いモノを作りたい、そのために周囲と協力して改善活動を行いたい、と考えるのは作り手として実に自然なことだと思った。今すぐに試してみたくなるような改善のためのアクションなど、現場で様々な課題を抱える我々へのヒントに溢れた、非常に有益な基調講演であった。

S2)事例発表

2名の事例発表は次のようなものである。自動化すればテスト効率が良くなるのでは?という仮説の元にテスト自動化へ取り組んだ事例と、テストをゲーム化して楽しいものにするマインドチェンジへ取り組んだ事例だった。

「テスト自動化で効果を出すためのアプローチ ~ぶつかる壁の乗り越え方~」
渡部 純樹 (株式会社NTTデータMSE)

最初に強調されたのは、自動化は決して「銀の弾丸ではない」ということだ。一度スクリプトを作成してボタンを押すだけといった簡単な話ではなく、自動化できないテストが半数ほどあるとのことだった。

自動化できなかった例として、人間とは違い仕様書と照らし合わせてレイアウトの正しさを判断できない、ログインできたかどうかについてログを確認する機能がない、などが挙げられる。その他、機種ごとのUI差分やOSバージョンを想定せず、ツールの保守が想定より増えたという問題もあった。

そのような経験を踏まえ渡部氏は、自動試験向けテスト項目作成時に守るべきルールを紹介してくれた。

まず、確認観点はシンプルに保つこと。テスト項目内の曖昧な表現は削除し、テスト項目を見直すことで、自動化の適用範囲が増えた。

次に、機種やOSバージョンに対してはメーカー毎の特徴を処理分岐し、繰り返し処理はコンポーネント化すること。結果として、メンテナンス時間の少ないスクリプトにすることができた。

その他のお勧めとしては、ツールベンダ技術者との合同合宿を開催すること。ツール基本機能やエラー処理の考え方を習得でき、同じ釜の飯を喰うことで裏コマンドもゲットできた、としている。

「ゲーミフィケーション × 探索的テスト ~重大バグヲ発見セヨ!~」
根本 紀之 (東京エレクトロン)

ゲーミフィケーションアプリの例として、節電アプリ(#denkimeter)がある。夏休みのラジオ体操で貰えるスタンプも一種のゲーミフィケーションである。速度違反者に罰金を課すのではなく、法定速度を守った人に報酬を与えるゲーミフィケーションがスウェーデンで実施され、3日間で平均速度が22%下がったという報告もある。

なぜゲーミフィケーションは強力か? それは、進歩している感覚や、快楽を生むからだと考えられる。ゲーム的な仕組みが、何かを達成したい、成長したい、という人間の欲求を満たすのだという。

この仕組みをテストに当てはめたのが今回の取り組みで、実施したゲーミフィケーションの進め方は次の通りである。

まずチーム分けを行い、チームの戦略に従って探索的テストを実施する。チームごとのバグ発見数はリアルタイムで周知され、終了後はバグの重要度の決定とバグの出し方の共有をする。そしてポイント集計をして、個人とチームそれぞれの成績を発表する。

取り組みの際、バグの重要度に比例してポイントも高くなるため、重大バグを発見しようという意識付けにもなった。積極的にバグを見つけようという姿勢が生まれた結果、優勝したのはテストが好きではなかったはずのエンジニアだった。もともとプログラマとして優秀な人が、ゲーミフィケーション+探索的テストを行うことで相乗効果が生まれたのでは、ということだった。

まとめと筆者感想

自動化の取り組み後、渡部氏は以前より早く帰宅できるようになったとのことだ。長時間労働が常識化しがちな日本のIT業界において、自動化は有用な施策のひとつであると思われた。

ゲーミフィケーションの取り組みは、参加者から「テストが楽しかった」という回答が得られバグ発見数も普段の倍以上だった。「仕事と楽しさは両立する」という根本氏の言葉は深く共感するものであり、弊社でもすぐに試してみたいと思う発表であった。

S5-2)探索的テストチュートリアル
「やってみよう!探索的テスト。テストの常識を変えませんか?」
高橋 寿一 (『知識ゼロから学ぶソフトウェアテスト』の著者)

開発スピードが高速化する昨今、多くのテスト時間を割けない会社が増えてきている。テストケースが1万件あってもバグをすべて発見できるわけではなく、テスト予算が上がることもまずない。そのような状況の中でいかに生き残るか? 探索的テストはそのために有用な手段と言える。

チュートリアル概要

探索的テストをどのように導いていくか、以下に考え方をまとめる。

1. テストケースをひとつひとつ書かない

なぜなら、無駄が多いからである。実際に操作しながら見る方が、時間あたりのバグ発見数は10倍になる。テストケースを書く人と実行する人が別々になるより、テストケースを書く人が探索的テストを行う方が良い。

2. 自分で触りながら、バグが出そうな箇所に対して適切にアプローチする

昔ながらのテストケースを書く方法を推奨しない理由は、機能をなぞるだけだと、バグを見つけようというテスターの意識があまり働かないためでもある。if文を書いてelse文を書き忘れる開発者もいるため、ifがあったらelseをチェックするなど、バグが出そうな箇所を攻めた方が良い。

3. どのような品質をユーザーに担保できるのか、頭を柔らかくして臨む

PASS/FAIL基準を書く際に、機能よりも、品質がどのようにあるべきか抽象度を上げて考える。ユーザーの求める品質を担保しようとする姿勢により、思わぬバグを発見できる。

まとめと筆者感想

副次的効果として高橋氏は次のように語ってくれた。

探索的テストではバグを見つけるのが楽しくなり、網羅的手法より時間当たりのバグ検出数も質も上がる。テストはクリエイティブなアクティビティだということが理解できる。

筆者はワークを通して、探索的テストとは、製品ドメインに対する深い造詣やプログラミングスキルがあればより効果の上がるテストであるということがわかった。人命に関わる開発では網羅的テストも避けられないかもしれないが、プログラミングスキル等も磨きながら積極的に業務に取り入れたいと感じた。

S6)招待講演
「IT業界 vs アニメ業界」
河原 大 (ピコグラフ)

アニメ業界とIT業界を比較して違いを楽しんでもらえたら、という主旨で、札幌のアニメーション企画・制作会社ピコグラフの河原氏の講演は始まった。

天才アニメーターの技術

アニメーターには、天才と呼ばれる技術を持つ人々がいる。

人がジャンプするときバネのような動きをする「金田アクション」、ミサイルが糸を引くように描写される「板野サーカス」、爆風やヌルヌルとした動きに特徴のある「庵野爆発」等、これらは見て覚える職人の世界であり、数値化・ライブラリ化が望まれる分野でもある。

1993年発表のアニメーション映画『機動警察パトレイバー2 the Movie』では、押井守監督が様々なカメラレンズの画角をレイアウトに適用し、後のアニメーターに多大な影響を与えた。その演出方法は『Methods 押井守「パトレイバー2」演出ノート』という本にまとめられ、出版されている。

IT業界から学ぶ改善点

アニメーションは30分の尺で1,100~3,000万円の制作費用がかかる。

収入に関しては、監督職なら年収600万を超えることもあるが、若手の動画マンは100万円強とあまり高くないことが多い。離職率も高く、業界全体の平均年収は320万円ほどである。

河原氏が以前、IT業界の人から貰ったアドバイスとしては、アニメ業界に必要なのはマネジメント、作業の自動化、データの流用の主に3点ではないかということだった。それから4年経った今、ゲーム制作に携わった経験からサイボウズとRedmineを使うようになり、進捗管理にその利便性を噛み締めているとのことだ。

まとめと筆者感想

アニメ業界はIT業界と仲良くなりたい、お互いに助け合って良いところを吸収したい、と河原氏は語ってくれた。筆者も様々な業種での職務経験が今に生きており、別ジャンルの掛け合わせが思いもよらないシナジーを起こすというのはままあるものである。今後の業界同士の協働に注目したい。

クロージング
上田 和樹 (JaSST'16 Hokkaido 実行委員長)

テストの見方は変わりましたか?皆さんの味方は増えましたか?気付きを得ることで0が1に、それらを繋げることで1が10に、それらを更に広げることで10が100になる、と実行委員長の上田氏は語ってくれた。

オープニングから一貫して、明日の北海道を良くしたい、テスト業界を良くしたい、という情熱を強く感じられるシンポジウムであった。

今回強化できた「協働」と「改善」の意識を忘れずに、筆者も明日からの業務をより良いものにして行きたいと思う。

記:千葉 まゆみ(JaSST Tohoku実行委員会)

[ページトップへ]