LINEのSETになってぶち当たった最初の課題
伊藤宏幸氏（以下、伊藤）：私、伊藤からは、「Everything from Scratch」、すべてをイチから始めた我々SET（Software Engineer in Test）の、これまでの苦労についてお話しします。ちなみにこの資料ですが、本来であれば2週間後にアメリカで開催される予定だった、世界最大のアジャイルのグローバルカンファレンス「Agile2020」で登壇してお話しする予定だったものです。
その雰囲気を今回の参加者のみなさんに味わっていただきたいと思っています。また、今回英語圏の方が100名ぐらい参加されるとのことですので、資料は英語のままで、（英語に関しては）通訳を介して同時通訳でお送りしますので、どうぞよろしくお願いいたします。
それではまず、みなさんに質問です。みなさんはテストに関連する活動、あるいはその他の改善活動でもよいです。このような目にあったことはありませんか？
例えば私たち、あるいはみなさんの活動などに反発するメンバーやチームがいる。あるいは、私たちやみなさんが作ったツールやソリューションを誰も使ってくれない。あるいはツールなどを作ったはいいけれど、それを使いこなせるだけのスキルをもった人が足りなくて、結局定着しない。こういったはありませんか？ ちなみに私は全部経験しています。
今から3年前、私はLINEのSETの第1号として入社しました。その際に私がぶち当たった課題をここにリストアップしてみました。まずテスト自動化、あるいはSETに関するはっきりとしたゴールをもっている人が、シニアマネージャーの間では誰もいませんでした。また、テスト自動化などの施策に関して、開発者、テスター、QA、マネージャーの間で意見の相違がある状態でした。
また、私たちの施策に対して、ネガティブなフィードバックをもらうことも多々ありました。例えばテストの自動化を例にとると、自動化というのは今あるものを変える作業になります。その効果がたとえよいものであったとしても、基本人間は誰かに変えられようとすれば、反発するものです。ですから、このようなトラブルが発生したり、何らかのチャレンジをすることになるのは、本来、当たり前なことです。ですが、この状態は適切な方法で解決可能です。
我々SETは、まさにこういうトラブルやチャレンジに対する解決方法やソリューションを、文字通りイチからフルスクラッチで作り上げました。今回はそれらをベースに、課題解決の考え方について話をさせていただきます。
セッションのゴールをGherkinのフォーマットで書いた理由
今回のセッションのゴールを書き出してみました。みなさんこちらはご存知でしょうか？ CucumberやBDDで使われているGherkinのフォーマットで、今回のセッションのゴールを書き出してみました。みなさんで確認してみましょう。まずGivenには、私たちはテストに関するトラブルを抱えていると書かれています。そしてWhenで、私たちはお互いのトラブルを共有し合って議論すると。ちなみに、このあとみなさんに議論の時間を提供いたします。
そしてAndで、私はSETでのソリューションでうまくいったものについてアイデアを共有します。そうすることで、我々は自分たちの問題を解決するためのヒントが得られる。これがこのセッションのゴールです。
さてみなさん、なぜこのゴールについてGherkinの書式で説明したのか、わかりますでしょうか？テスト自動化に詳しい方であれば、GherkinやCucumberというのは、実行可能、つまりここに書いてあるものが（そのまま）動かせることが前提になります。ですので、ぜひみなさんには、私のこのセッションを通じて、自分たちのチームや会社に持ち帰って試せるアイデアを手に入れて、それを実行してほしいと思います。
前置きはここまでとして、今回の私のセッションでお話したいことは3つです。一番初めは適切な支援を得る重要性、次に一緒に痛い目にあう重要性、そして3点目に適切な育成の重要性。この3つの重要性についてお話しします。
適切な支援を得る重要性
まず1つ目。支援を得る重要性からお話ししようと思うのですが、その前に、今回各章の頭で5分のディスカッションタイムを用意しています。今回のディスカッションはZoomではできないので、Twitterで先ほど紹介した#LINE_DMというハッシュタグを付けて、そこでぜひみなさんのアイデアを聞かせてください。
では最初のお題です。「みなさんの会社・組織でテスト自動化を阻むものにはどのようなものがありますか？」。これから5分時間をとりますので、ぜひみなさんのアイデアをTwitterで教えていただけますか？
（参加者書き込み中）
「費用対効果は？しか言わない上司」（笑）。「早い案件が次々に来てしまうのでリスケされていく」、ありますよね。ありがとうございます。「英語力が問われる」、ぜひ英語を使いましょう。「テスト自動化の概念を知らない」。みなさんありがとうございます。
こういうかたちでぜひみなさんのご意見をください。ちなみに、みなさんからいただいたアイデアは、後ほどTogetterで、まとめてみなさんに見えるかたちで共有させてください。あと残り2分。「リソースが足りない」「メンテナンスコスト」「勘所がわかるエンジニア」。いいですね。「技術スタックが違って学習コストが高い」。やっぱりありますよね。
ちなみに私がぶち当たっているものについては、このあとこの時間が過ぎたら共有させてください。「マネージャー層の無理解」（笑）、そうですよね。例えば「テストコード、テストスクリプトを書くと、開発コードともう1個同じレベルのものを作るということだから、コストが倍になるよね」というマネージャーは必ずいますよね。でもそういう人は、作るところのコストしか見てなくて、運用に入ってからのコストを見ていなかったりすることってありますよね、とかね（笑）。
「短納期や受託案件」「興味を示さないメンバー」。こういうみなさんの「ムムム」が大好きです。ぜひお聞かせてください。残り30秒です。やっぱり納期とかスキル不足とか、「テストチームが別にいる」、いいですね。いいのか、これ（笑）。「理解度が低い」「自動化に無限の期待が寄せられる」、これすごくわかります。
時間になりました。それではみなさん、いろいろとアイデアをありがとうございます。ちなみにまだ投稿してもらっても大丈夫です。後ほど私のほうで拾いたいと思います。
ではセッションに戻りましょう。次は私の話をさせてください。これは、3年前に私がSETの第1号として入社したときにぶち当たった問題です。
私が入ったときは、テスト自動化やSETに関して、意思決定者・同僚たちの間でテスト自動化をどう活用するかのビジョンやゴールがありませんでした。これは先ほどお話ししました。ビジョンやゴールがはっきりしていないのであれば、当然、テスト自動化に関する共通理解とかはないですよね。そういう状態であれば、当然支援を得られないわけですよ。
さらに社内で話してわかったのが、本当の問題へのニーズというものをはっきり認識して言葉にして伝えられる人が、この当時はいませんでした。これが私のブロッカーでした。
そんな状態で「とりあえず適当なサービスを見繕ってテスト自動化だけやりましょう」と言っても、これって何も解決しないですよね。テスト自動化やSETに対する理解とか、意思決定者・同僚のみなさんがモヤモヤしているものを、まず解決しないことには先に進めないのではないかと私は思いました。
そこでここのポイントは、意思決定者や同僚から適切な支援と理解を得ること。そのためのヒントをここで紹介します。とくに私が活用したアイデアは、ここの2つです。Product Discoveryと、インパクトを与える。この2点を入社当時の3年前に活用しました。それぞれについて説明させてください。
Product Discoveryの活用
まずProduct Discoveryですが、これはプロダクトマネジメントとか、あるいはスクラムのプロダクトオーナー、スタートアップ企業などでよく使われていて、ユーザーのニーズを適切に把握するための、ユーザーテストなどの手法の一覧です。みなさんも、例えばPersonaとかUser Story Mappingという言葉を聞いたことはありませんか？ こういった手法をまとめたものが、Product Discoveryというアイデアです。
私はこのアイデアを、この左にいるDavid Hussmanさんという方から、研修や対話などを通じてガッツリ叩き込んでもらいました。そして、このProduct DiscoveryをLINEのSETとしてどう活用したかと言いますと、その意思決定者・同僚の抱えている課題、真の課題というものをリスト化して発見して、それを言語化するということに活用してみました。
みなさんに話を聞いてみたり、いろいろリストアップしたもの、とくにこの章の後半で関わるものをリストアップすると、こちらになります。まずChannel GatewayというサービスがLINEにはあるんですが、私が入社した当時は、そのサービスが頻繁に本番障害を起こしていることが大きな問題として、多くの同僚や意思決定者の間で共通認識にあることがわかりました。
次にそのChannel Gatewayなんですが、頻繁に障害を起こしているだけではなくて、障害を検知するシステムも当時はなく、障害が起こっても1週間ぐらい気付いていないことが、当時はけっこうざらにありました。
あと、APIのテストに非効率なところが多いというのも、いろいろな方からうかがいました。例えばAPIは普通にプログラムから動かせますよね。ですけど、当時は開発者がそのAPIを実装したら、QAの方に「このAPIのテストをお願いできますか？」と依頼するんですよ。そしたらQAの方たちは何を言うかというと、「わかりました。それではこのAPIを動かすためのUIもセットでください」と言うんです。
APIをcurlコマンドで叩けばいいわけなんですけど、当時はQAもプロダクトマネージャーも、APIであってもテストであるからには、手動でテストしないといけないという（謎の）思い込みが強くあって、それ故に本来は不要であるテスト用のUIを作ったりとか、そのための調整が必要になるとかいったことが、当時はよく見られました。こうした課題をうまく言語化したのが、まずこのProduct Discoveryです。
インパクトを与える
次にインパクトを与えるということを意識してやりました。ちなみにインパクトを与えるとはどういうことかと言うと、この意思決定者・同僚というターゲットに対して、定期的に何か気になるものを提供することで、我々SETに関する興味、関心を持ち続けてもらう。あるいは興味や関心を大きくするようなアプローチです。
この本で読まれた方もいるのではないかと思います。これはGoogle社でテストをやる際、どういうテクニックとか役職があるかというものをまとめた書籍ですが、この本の中でも「インパクトを与える」というテクニックが語られていたりします。では、私はどのようなインパクトを与えていったのか。
私がやったのは、入社して1週目から必ず毎週何かしらのバリュー、それも実行可能なもの、あるいはソフトウェアのような動かせるものを必ず提供し続けました。こちらに、始めの10週分をリストアップしておきましたので、軽く見てみましょう。
まず入社1週目で、さっそくターゲットになりそうなプロダクト候補がいくつかわかりましたので、テストスクリプトを書いて動かしてみて、そのプロダクトの中身とか実装の癖とかを調べることを始めました。ただ動かして調べるだけでなくて、そこで得たアイデアを元に、恐らくこういう問題があって、こういうアクションが取れますよ、という初期の活動提案というものを2週目でまとめあげて、意思決定者に提案しています。
そのあと、対象になるプロダクトの静的コード解析を走らせてレポートを出せるようにしたり、あとはそのレポートを私が出すだけではなくて、そのプロダクトを担当している開発者の人たちが、自分たちで設定、出力できるというように教えたりしました。
そうやって、いろいろなプロダクトや社内の情報を集めていって、それで向こう半年とか1年の活動のマイルストーンやゴールを提案して、それらをベースに意思決定者、例えば役員の方とかと大筋合意できたのが、入社6週目です。
そのあとは合意に基づいて、例えば支社とか拠点ごとにバラバラになっているテスターやQAの情報を1ヶ所に集約したり、あるいは先ほど出ていましたChannel Gatewayの施策を始めたり、こういうことを毎週何らかのかたちで爪痕を残したりということを続けてきました。これが、私が与え続けてきたインパクトですね。
その結果どうなったか。確かにインパクトがあったんですよ。というのは、例えば同僚のみなさんがテストに関して困ったときに、「だったらSETに相談すればいいんじゃないの？」という会話が自然に出始めるようになりました。
また、意思決定者や役員とかシニアマネージャーの人たちが、「このチームで何かをやるのであれば、こういう技術とかツールが必要だから」とか、「これに詳しい人を紹介するから当たってみたらいいよ」とか、そういう人を紹介してくれたり適切なツールなどを教えてくれて、少しずつ活動に対してプラスになるような支援をしてくれるようになってきました。
そういうことも踏まえて、このあと話しますが、Channel Gatewayでの改善活動というのを始められるようになりました。ここまでがまず、同僚や意思決定者の支持や理解を得るために活用した2つの手法です。Product Discoveryとインパクトを与える、この2つで適切な支援や理解を得ることができたというのが、ここまでのポイントです。
一緒に痛い目に合う重要性
次は一緒に痛い目に合う必要性と重要性です。こちらもまた5分とりますので、先ほどのようにTwitterでみなさんの意見をお聞かせください。「テストスクリプトをあえて開発者に書いてもらう際に、どうやって説明、説得しますか？」
みなさんでしたら、どうやって会社のみなさんにテストスクリプト、テストコードを書いてもらいますか？もしテストスクリプトをQAとかテストエンジニアが書くのではなく開発者に書いてもらおうとする場合、みなさんならどうしますか？
（参加者書き込み中）
「コードレビューに参加してもらう」、いいですね。「洗脳していく」、心に訴える方法ですね。「コードのバグを仕込んだ体験談を思い出してもらう」、ありがとうございます。「Show them an example of software without testing!」、Great！I love it.こういうの大好きです。「時間とインセンティブ」、その下のTDDも重要ですね。
「who don't do testing.. or only creating test cases」（笑）。「teams are responsible..」、ですよね。こういうアイデアありがとうございます。「政治的圧力」。
これはけっこう、TDDが多いですよね。自分が書くんだったら自分がやればいいんですけど、みんなに書いてもらおうとなると意外と「あれ？ どうやって説得すればいいんだろう？」とか「どうやって説明するとみんながやる気になるんだろうか」とか、純粋にテストを書くだけじゃないところの脳が鍛えられますよね。
ぜひ自分じゃない人がやる場合にどういった行動が必要なのか、という観点からアイデアを聞かせてください。「道半ば」、いいですね。でも、こういうのに取り組まれるのも重要ですね。「フィードバックが高速に返ってくることの嬉しさを伝えたり、テストを書きやすい環境を整えたり」、うん。これはまさにSETの活動ですよ。
「具体的な成果を共有する。例えばテストを書くことで見つけたバグ、書かなかったことで流出させたバグを共有する」。あとはあれですね、「バグを速く発見したときの対応工数の説明」。「書く作業工数の確保ができればお願いできそう」。つまり工数の問題じゃないかという方もいらっしゃいますね。あとは「書くのが普通じゃない？」と。これ大好き。こういうアイデアは本当にありがたいです。
「設計とかの話をする」とか。やってくれたケースがあるんですね！ この話はいいですね。「サンプルを提供して」、なるほど。「自発的にやることはできないので、啓蒙活動が重要」と。つまりやってもらうための施策が啓発をすると。「比較的リーダーがいてくれると推奨してくれるのでやれる」、なるほど。こういったケースもあるでしょうね。
さて、お時間です。それではみなさん、すごく多くの投稿をありがとうございます。このあときっちり読ませていただきます。
Channel Gatewayでの事例
スライドに戻りましょう。これからはSETの例をお話しします。ここの章のポイントはプロダクト開発チームと一緒に痛い目に合う重要性です。というのは、先ほどもちらっとお話しましたが、SETのメインの業務の目的として、プロダクト開発チームに入っていって、一緒にプロダクト開発をしながら、ここでテストスクリプトを一緒に書いたり、あるいはテストをしやすくするためのツールを導入する活動があります。
そのときに、一方的に私たちSETとかが施策を提供するのではなくて、開発チームと一緒に痛い目に合うことの重要性を説明したのがここのポイントです。どういうことなのか。これは先ほどから名前が出ているChannel Gatewayでの我々の事例でお話しさせてください。
先ほどから出ているChannel Gatewayのシステムについて簡単に説明します。Channel Gatewayの「Gateway」というのが、APIの集合という意味合いの言葉になります。私たちの場合、このChannel Gatewayは、LINEの中のさまざまなサービス、こんなのがあったりします。
それぞれがもっているAPIを束ねて、より使いやすいAPIにして社内のユーザーに提供することで、メッセージを送れたり、Botを動かせたり、APIを社外の主にエンタープライズ向けのお客様に提供することで、LINEの提供しているさまざまなAPIを使ってさまざまなサービスが展開できるといったような、そのためのAPIの集合体です。
ただ、ここのサービスが頻繁に本番で障害を起こしていたり、障害が起こってもそれを見つける仕組みがなかったというのが問題だったのは、最初に説明した通りです。そこで、こちらのチームでまず私が入って取り組んだのが、APIなので、APIのテストスクリプトを書いて、それをCIサーバで定期実行して、障害を検知・通知するようにすれば、この障害検知はできるのではないかと思いました。
例えばこんなスクリプトを書いて提供し始めたりしてみました。これはJUnitで書いたAPIをテストするスクリプトです。こちらをJUnitで書いたのは、このプロダクトがJavaで作られているということと、ここのチームの開発者の人たちに、ここでテストスクリプトを書いてメンテナンスしてもらいたいと思ったので、開発者のみなさんが日々触っているJavaで書けるということで、JUnitを採用してみました。
これを実際に作ったら、テストを作って動かしてみると、どこかのサービスのサーバでリソース不足が起こってるよみたいなエラーを検知してくれて、障害は確かにわかるようになったんですよ。ただこれは定着しなかったんです。これは、私が2、3ヶ月がんばっていろいろ書いて、ツールとか諸々を用意して提供したんですけど、結局「使えない」と言われちゃいました。
なぜかを開発チームのみなさんにいろいろ聞き取ってみました。こちらの先ほどのコードは、いくらJavaをやっているからと言っても、「読みづらいし書きづらいし、テストを見てもわかりづらくてメンテナンスがしにくいです」と言われてしまいました。読みづらくて実装しにくいのであれば、それは定着しないですよね。
