はじめに

こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。

2018年6月27日（水）に、電気通信大学の西 康晴さん（以下「にしさん」と表記）をお招きして、「Testing & Engineering」をテーマに「LINE Developer Meetup Tokyo」を開催しました。

この記事では、イベント企画者 兼 登壇者の立場から、同イベントについてレポートいたします。

1. なぜLINEがテストのイベントを開催したのか？
2. 発表内容
3. Q&A

• Togetterもまとめました！

1. なぜLINEがテストのイベントを開催したのか？

多くの方がまず、この疑問を持たれたのではないかと思います。その理由を一言で言うと、「LINEのことをもっと幅広く知ってもらいたい」に尽きます。

LINEはこれまで数十回、「LINE Developer Meetup Tokyo」を開催してきました。「LINE株式会社/LINE Fukuoka株式会社のエンジニアが、社内で使っている技術について発表するイベント」との位置づけから、これまではプログラミング言語やフレームワークに重きを置いてきました。一方でその結果として、それ以外のコミュニティ、具体的にはテスト（自動化）・アジャイル・DevOps・プロダクトマネジメントといったコミュニティでのLINEの知名度の低さが、新たな課題として明らかになってきました。（「LINEがどのような取り組みをしているのか分からない」と、多くの方から言われ続けています。）

そこで、テスト（自動化）・アジャイル・DevOps・プロダクトマネジメントなどについても積極的に情報を発信していこうと企画したのが、今回のイベントです（つまり、今後も上述のテーマで新たにイベントを開催予定だということです！）。

今回のイベントの狙い

今回の狙いはズバリ、「テストとテスト自動化とアジャイルの融合」です。

いま私が担当しているSETは、テスト自動化だけではなく、アジャイルによるプロダクト開発プロセスの改善、QAとの協力による仕様の洗練と開発者テスト（Developer Testing）の推進、ビジネスへの貢献など、非常に幅広い領域をカバーしています。どれかだけでは不足で、どれも含めた、プロダクト開発ライフサイクル全体で考え行動する視点が必要と考えています。その観点から、「コミュニティ間の越境」、特にテストとアジャイルとの相互越境が、ソフトウェア開発業界全体にインパクトを与えられるのではと考えました。

そうした考えから、今回は真っ先ににしさんにコンタクトを取らせていただきました。

• テスト系コミュニティでの影響力が絶大であるため
• QA4AIコンソーシアム設立の際に声をかけていただくなど、LINEとしてこれまでお世話になっているため（恩返しをしたかった）
• JaSST'18 Tokyoの情報交換会で、アジャイルを活用したテストが海外で当たり前になってきているというお話を伺い、もっと詳しく知りたいと思ったため

※にしさんは今回、出張などの予定を変更してオファーを受けてくださいました。圧倒的感謝。

参加者・登壇者・企画者、そしてソフトウェア開発業界にとってもWin-Winになると考え、今回のイベントを企画しました。実際に、テスト系コミュニティの方が7割、アジャイル系コミュニティの方が3割という、狙い通りの参加者構成となりました。

2. 発表内容

発表とその順序は、次の観点で設計しました。

1. 学術・理論面の話：にしさん
2. 現場での技術の話：大園
3. 現場での戦略の話：伊藤

1) 『イマドキのソフトウェアのテストやQAの考え方』by にしさん

にしさんからは、QAというロール・役割の課題・解決方針・未来像についてお話いただきました。

1. 「労働のスケールアップ」という課題

古い体質（＝「考え方が昭和」）の企業でのQAは、下記のような課題を抱えており、今の「変化の時代」に対応できていないとのことです。

• 無理ゲーに重課金：スケジュール・仕様的に無理なことを、大量に人手を集めて乗り切ろうとする（＝労働集約）
• 間違った戦略：バズワードに振り回される、硬直したプロセスを開発者などに順守させようとするなど、そもそもの戦略が間違っている
• 「生産性」への固執：多くの人が「生産性の向上」を口にするが、「生産性」の定義が人によって違う。また、そもそも「生産性」は計測できない。

2. 「知のスケールアウト」という解決方針

「労働のスケールアップ」を克服・解決するための方針として、にしさんは「知のスケールアウト」を提案されています。

• 納得感をマネジメントする：議事録やプロセスよりも、ペアプロなどによる暗黙知の共有と共感をより重視する
• 労働ではなくミッションをシェアする：労働集約よりも、全員が同じ方向を向いて行動できることをより重視する
• 違和感をアンドン化する：無理な要求は無理だとはっきり言い、問題をすぐに皆で解決することをより重視する

3. 「品質保証」のスコープを広げる

上記を踏まえて、QAの未来像としてにしさんが提示されたのは、「品質保証」という仕事の矮小化からの脱却でした。

• AQUAフレームワーク：無理な共通化はせず、個々のプロダクト・プロジェクトのコンテキストに合わせて、ソフトウェアQAの戦略を立案・実施する
  • Accelerating Project
  • Qualifying Value
  • Unveiling Weakness
  • Accumulating Knowledge
• QAは、エンジニアリングやアーキテクチャ設計も行う
• QAは、テストレベルやテストタイプも設計する
• 企業は、「品質保証」のスコープを広げたQAへ、これまで以上に投資する

「QAは、プロダクト開発ライフサイクル全体に寄与すべき」

使用されている用語こそ違いましたが、にしさんのお話の要点はこれであったと考えています。そしてこれは、アジャイルの考え方そのものです。

ロールや役割に固執するのではなく、ビジネスのプラスになることであればどのようなことでも行う、また技術力も広範に活用する。

このようなお話を、日本のテスト界のアイコンであるにしさんからしていただけたことは、まさに企画者としての期待通りでした。

2) 『LINEのUI自動テスト事例』by 大園 博昭

LINE Fukuokaの大園からは、クライアントサイドのテスト自動化エンジニアとして、UIテストの自動化の技術的側面について、具体例を交えてお話させていただきました。

• 特に独創的・奇抜なことは行っていない

  • 地味なことを地道に、愚直に積み重ねている

• テスト結果レポーティングツール「Ayachan」の開発・運用

  • 非エンジニアに対して、テスト結果を分かりやすく伝える必要性から開発
  • （参考）「Ayachan」は、上司の名前から取った
    • Ayavue：Vue.jsベースのフロントエンド
    • Ayachan-Server：バックエンド

• LINE STOREのプロジェクトでは毎日、1,400のテストスクリプトを自動実行している

• 開発チームが仕事をしやすくするために自動化を進めている

  • 自動化自体が目的ではない
  • 何でも自動化はしない
  • 人的コスト削減を目標として、自動テストには取り組んでいない
    • 手動テストのコストを減らせた一方で、自動テストを実装・メンテナンスするためのコストは増えたため、トータルではほぼ±0。
    • 今後、結果として人的コストの削減につながる可能性はあるが、あくまで焦点はプロダクト・サービス品質の向上。

ビジネスへの貢献を常に念頭におきながら、地道に自動化を進めていく。これが、LINE Fukuokaのテスト自動化チームを率いる大園の態度です。

3) 『An Agile Way As an SET at LINE』by 伊藤 宏幸

私伊藤からは、アジャイルの知識・経験を活用して、SETの戦略を立案・実施し続けているお話をさせていただきました。

• 基本的には、2018年2月に公開した資料と同じ内容です。
• 今回の発表用に、新しい情報を5ページほど追記しています。

以下、ポイントです。

• 各人が抱えている課題を発見・言語化し、施策案とする
• 対象プロダクトや施策は、「3つのビジネスKPI」（売上・利益・従業員満足度）に基づいて決定・実施・評価する
  • （例）単にテスト自動化の範囲を広げるのではなく、MTTR（Mean Time To Repair）を削減する観点からテスト自動化を導入する
• テストスクリプトは、SUT（System Under Test、テスト対象プロダクト・プログラムのこと）を理解するための最高の道具であり、「心理的安全性」を担保するツールでもある
• インパクトを与え続ける：成果を継続的に提供し続けることで、ステークホルダーの関心を惹きつける
• テスト自動化を活用して、ビジネスに貢献するのがLINEのSETである
  • GoogleのSET/SETIの定義に従うのではなく、LINEにとって必要な「SET」を定義し改善し続けている

テスト（自動化）もアジャイルも、結局のところ同じだということが、私のお伝えしたかったことです。

• ロール・役割に固執しない
• プロダクト開発ライフサイクル全体の視点から、繰り返し改善を行う
• 結果として、ビジネスに貢献していく

3. Q&A

イベント当日にQ&Aセッションの時間を割くことができなかったため、会場のホワイトボードで皆様からいただいた質問について、できる限り回答させていただきます。

（注）質問は、付箋に書かれた文言をそのまま書き起こしています。

---

＜テスト全般＞

自動化のメリットデメリットを教えて下さい（回答者：伊藤）

メリット

• 手作業によるヒューマンエラーを予防できる
• 特に繰り返し実施する作業の場合、作業を高速化できる
• 作業が高速化するため、やり直しがしやすくなる
  • 何度でもやり直せるということは、失敗を恐れなくてもよくなるということでもあります。

デメリット

• 初期の実装コストが高い
  • コストの判断の目安として、「そのテストを3回以上繰り返し実行する場合は自動化した方が良い」と言われることが多いです。
• 実装・導入にあたっての学習コストが高くなる恐れがある
• 分かる人がいなくなると、メンテナンスが放棄される恐れがある
  • メンテナンスをできる人は、常に用意しておく必要があります。

（QA初心者なのですが…）レグレッションテストの自動化は具体的にどのようにやるのでしょうか？（回答者：伊藤）

具体的なステップを説明します。

1. まず、テストスクリプトを実装します。
   • LINEでは、単体・結合・E2E（End to End）テストのいずれかを実装しています。
2. 全てのテストが成功する状態にします。
   • この状態を一般的に、「グリーン」と呼称します。
3. CI（Continuous Integration）サーバーで、実装したテストスクリプトを実行できるようにします。
   • テストスクリプトの実行タイミングとしては、GitHubへのコミット・プッシュ後の実行、または1時間おきのような定期実行が一般的です。

これにより、誰かがバグのあるプログラムをGitHubへコミット・プッシュしたとしても、すぐにCIサーバーで問題を検知することができるようになります。

自動化をやるエンジニアは、自動化まわりだけ担当しますか？（回答者：伊藤）

何か「だけ」といったように、仕事に制限を設けることはしません。会社に貢献できることであれば、何でも行います。

参考までに、テスト自動化エンジニア・SETが共通で行なっていることを、以下に列挙します。

• テストスクリプトを実装する（単体・結合・E2Eテストなど）
• CIサーバーの設定を行い、CIを定期実行できるようにする
• 必要に応じて、テスト用のフレームワークやツールを設計・実装し、開発者・QA・テスト自動化エンジニアらに提供する
• （世界各拠点を含む）開発者やQAに、テストスクリプトの書き方・テストケースの設計方法・CIサーバーの設定方法・プロセス改善手法などを、一緒に働きながら教える
• マネージャーからの相談に応じ、テスト（自動化）に関する課題認識を明確化し、必要なアドバイスを行う。必要な場合は、それらを設計・実装する。

テストデータ作るのが大変でこまってます…（回答者：伊藤）

• 個々のデータの作成方法が複雑で大変という意味であれば、テストデータを容易に作成できるツールを開発・利用しています。
• 大量のデータをテストの都度用意することが大変という意味であれば、データを格納したストレージをDockerイメージ化して活用しています。
  • テスト実行時にコンテナを作成、テスト終了後にコンテナを破棄することで、いつでもフレッシュかつ十分な量のデータで、テストを繰り返し実行することができます。

本番環境上でおこなっているテストはありますか？ある場合、それはどの様なテストでしょうか？（回答者：伊藤）

はい、あります。具体的には、以下のようなテストスクリプトを定期実行しています。いずれも、本番環境での障害検知の迅速化とMTTRの短縮を目的としています。

• E2Eテスト形式によるシナリオテスト
• APIが正常に動作していることを確認するためのスモークテスト

クラウドサービスを使ったシステムのテストはどうやってる？（回答者：伊藤）

社外のSaaS（Software as a service）やパブリッククラウドという意味であれば、以下のようにテストを実施しています。

• シナリオテストやE2Eテストでは、直接接続してテストを行なっていることが多いです。
  • クラウドサービスと正常に接続できているか否かが、主要なテストの観点になるためです。
• 単体・結合テストでは、モック・スタブで代替することが多いです。
  • クラウドサービスとの接続よりも、呼び出し結果を想定通りにハンドルできるかが、主要なテストの観点になるためです。

やってみたけどうまくワークしなかった自動テストってありますか？（回答者：伊藤）

ここ5年ほどの経験では、BDD（Behavior-Driven Development）が、ワークしない頻度が多かった印象です。

• 特に日本人で知っている人が少ない
• 説明しても理解してもらえないことが多い
• 無理に実装しても、メンテナンスできる人を育成できずに放置されてしまったことがある

テストコードの設計・効率化をやってますか（回答者：伊藤）

「設計・効率化」の意図を間違えているかもしれませんが、LINEで実施していることを紹介します。

• 「設計書」という意味では、書くことは稀です。
  • テストスクリプトのコメントに、入出力例を書くことはあります。
• 「XUnit Test Patterns」や「Page Object」などを活用し、定期的にテストスクリプトのリファクタリングを実施しています。
• 下記の「テストピラミッド」に従い、実行速度の速い単体テストでカバレッジを増やし、その分実行速度の遅いE2Eテストを減らすといったことを実施しはじめています。

---

＜UIテスト＞

E2Eテストの実行に時間がかかるので、コードの修正のたびに手元で実行するのが、おっくうです。（どこまでMockにして良いか？）（回答者：大園）

• テスト実行時間を減らすため、並列実行できる設計と環境を作っています。
• コードの修正のたびに手元で実行するのがおっくう -> CIで自動的にテストを実行するというのはいかがでしょうか？ 弊社の場合、単体・結合テストはもちろん、E2Eテストに関しても、GitHubへプルリクエストが作成されたことをトリガーにしてテストを実行したり、定期実行（1時間or30分に1回など）で対応しています。
• どこまでMockにして良いか -> これはサービスの性質やSUTによって変わりそうですが、E2Eテストではモックを使用しないことが多いです。

UIテスト自動化について、ツライ＆まだ解決できていない問題ってどういうものがありますか？（回答者：大園）

Meetupの場でもお話させていただきましたが、次の点は今でも改善の必要があると日々痛感しています。

• 安定性
• メンテナンス性
• テスト結果の視認性

あと、最近もっと向上させなければと感じているのが、「テスト結果の追従性」です。

弊社のサービスはそのほとんどがマイクロサービス化されており、ひとつのサービスに様々なコンポーネントが絡みます。例えばUIテストでバグを拾い、期待値と違う挙動をしていることを掴んだとしても、「じゃあなんでこのバグが発生しているのか」というのは開発者が都度各種サーバーやアプリケーションのログを追い、どのサーバーやコンポーネントで、どのような状態になっていたのかを結局調べなければなりません。もしUIテストがバグを見つけると共に、「なぜこのバグが発生したのか」を容易に追従できるシステムがあれば、開発者はもっと作業に集中できるのかな、と考えています。

レイアウトの自動テストってどーですか？（回答者：大園）

レイアウトの自動テストというのは、CSSやアプリケーションの表記崩れに対するテストという認識でよろしいでしょうか？

であれば、BackstopJSは個人的に好きでよく触っています。

このあたりのフレームワークはまだスタンダードなものがない印象ですが、もしなにかオススメのツールなどありましたらぜひ教えてください！

---

＜SET＞

SETのやりがい、どういうときに快感を覚えますか？（回答者：伊藤）

施策が狙い通りの効果をあげられた時もそうですが、関わっている人たちが自力で施策を考え実行できるようになった時に、大きな喜びを感じます。

先日の発表内容でも言及した、開発チームが自発的にスモークテストを書くようになってくれた時は、記念にSlackのスクリーンショットを取得したほどです。

（伊藤さんへ）自動テストを開発が書き始めた時に気をつけてもらうような働きはされましたか？ by なそさん（回答者：伊藤）

いつでも書き始められるよう、予め次のような準備をしておきました。

• 書く際の参考にできるテストスクリプトを、事前に実装しておいた
  • つまりそうなところ全てに、ヒントになるコメントを明記しておきました。
• 上述のテストスクリプトを、CIサーバーで定時実行するようにした
• CIサーバーでテストが失敗した時および問題が解決した時に、開発者・プロダクトマネージャーを含む関係者全員にSlackで通知するようにした
• テストが失敗した際、実際の解決オペレーションをSlack上で実演してみせた。合わせて、オペレーションやTipsをWikiにまとめ、関係者全員に共有した。

これにより、開発者はその気になったら即日キャッチアップしてくれました。

デベロッパーがテストコードを書く際にどこまでテストを書くべきか等の指針は定めていますか（回答者：伊藤）

プロダクトごと／プロダクトのライフサイクルフェーズごとにテストすべき範囲は変わると考えているため、こちらから指針を出すことはしないようにしています。

それよりも、デベロッパー・チームが何をどこまでテストすべきかを自分たちで考える癖をつけるようガイドしています。

この辺りは、自分たちのプロセスを自分たちで徐々に発見・構築していく、スクラムの考え方を応用しています。

プロダクトの品質とビジネスのKPIを結びつけるときにどんな観点でプロダクト／テストを捉えますか？（回答者：伊藤）

これも、プロダクトごと／プロダクトのライフサイクルフェーズごとに変わってくるものだと認識しています。

（例）

• ミッションクリティカルではない新サービス
  • 初期リリース時：完璧を目指さず、品質要因でUXが損なわれないレベルを是とする（金銭的インパクトよりも、利用者数の増加をより重視する）
  • ある程度定着した後：ボトルネックやMTTRを減らすようテストを活用する（利用者数を減らさず、金銭的インパクトも減らす）
• 金銭を取り扱うサービス：初期の段階から、マネーパススイートを重点的にテストし、お客様・ステークホルダーに金銭的被害を与えないレベルを目指す

この点については、LINEのQAマネージャーの鈴木 里惇の資料が分かりやすいと思います。

自動テストの成果はどうやってはかってますか？（回答者：伊藤）

その自動テストの実装・運用を始める際に設定した目標で計測しています。

（例）

• MTTRを、5日から1日以内にする
• テストを書く開発者を、半年以内に5名増やす
• QAの業務時間・残業時間を一人当たりn時間減らす

手動テスト０はテスト自動化のゴールに成りえますか？（回答者：伊藤）

「手動テスト0」だけでは、ゴールとするには浅いです。「手動テスト0」を実現することで、一体何を達成したいのか、改めて考えていただきたいです。

• 「手動テスト0」は、マネージャーや経営層にとって嬉しいことでしょうか？　また場合によっては、仕事を奪われる手動テスターの感情的反発を招きかねません。
• 「手動テスト0」の先に何を達成したいのかを深掘りし、真のニーズを見つけることが肝要です。
  • 問題を深掘りするためのテクニックの1つとして、「5 Whys」が役立つことが多いです。

SETとして行った具体的な施策を教えてください（回答者：伊藤）

2018年4月24日（火）にDevOpsDays Tokyo 2018で発表した下記資料をご覧ください。

---

＜その他＞

CIの前提として自動テストの必要性を上司に理解させたい。よい方法ありますか？（回答者：伊藤）

こっそり自動テストとCIサーバーを用意しておいて、「もう出来ているのでみてください」と言って見せるのが効果的です。（アジャイル界で「ステルス」と呼ばれている手法です）

『自動化の誤解を解き本来の意味を知る　～アジャイルアカデミー「Jenkins Boot Camp」講座』の2ページ目にも、下記の記述があります。

ある知り合いの例では、チームにアジャイルの文化を入れる際にまずどこから着手したかというと、自分のノートパソコンにJenkinsを入れてチームのビルドを自分のパソコン上で自動化し、完全に自動化できた時点で上司に見せて「もうこうなっているからこれだけ時間が短縮できる」と説明したというエピソードがあります。

ちなみに、この「ある知り合い」とは私です（笑）

テストコードを書くことが最も優先度が低い会社の文化を変えるためには、どうすればよいでしょうか？（回答者：伊藤）

「会社の文化を変えたい」は、イベントで特にあがることの多い質問の一つです。そして、ある程度実証された解のある課題でもあります。

• まずは、自分自身が率先して変わりましょう。
  • 人は、他者から変えられることに非常に嫌います。
• 自分の変化について、他者に興味を持ってもらうようにしましょう。
  • 他者を「変える」のではなく、「変わりたいと思わせる」ことの方が、変化に繋がりやすいです。
  • 興味を持ってくれた人は、仲間となりやすいです。
• 仲間を増やしつつ、成果を積み重ねましょう。
  • 草の根のボトムアップと、マネージャーなどを介したトップダウンの両方があると、より効果的です。
• それでもダメな場合、その会社から離れましょう。

この考え方は、Jurgen Appeloさんの書籍『How to Change the World』に詳しいです。

昭和どころか大正のにおいのする会社なのですが、どうしたら良いですか？火つけちゃって良いですか？助けてください！テストの自動化したいのに困ってます！！（回答者：伊藤）

火はお勧めいたしかねます（笑）

まずは上述の文化を変える活動から始めることをお勧めします。

パレハになりたいです

このブログの一番下へGO！

最後に

月末の忙しい時期にも関わらず参加してくださった皆様、お忙しいところ登壇を快諾してくださったにしさん、イベント開催をサポートしてくださった皆様、改めてありがとうございました。

今後の予定としては、テスト（自動化）ももちろんですが、アジャイル・DevOps・プロダクトマネジメントをテーマにしたMeetupについても企画中です。今後の「LINE Developer Meetup」、ご期待ください。

またLINEでは、テスト自動化エンジニアおよびSETを絶賛募集中です。今回のイベントを機にLINEに興味を持たれた方は、ぜひお気軽にコンタクトください。

• （福岡）QA Automation Engineer
• （東京）ソフトウェアエンジニアインテスト（Software Engineer in Test (SET))【LINEプラットフォーム】

※東京オフィス勤務でQA Automation Engineerとして働く（またはその逆）といったことも可能です。

皆様の応募、心よりお待ちしております。