LINE × 出前館プロジェクトの「失敗エピソード」から学べ　QAチームが振り返る、これまでの取り組み

QAのテスト技術を活かせた場面はあったか？

和田卓人氏（以下、和田）：次は7votesに来ている質問にしましょう。「お話を聞いていると、製品全体のドメイン知識を活かしたQAの動き方のように聞こえます。一方で、テスト技術を活用したQAの動き方があまり見えなかったのですが、テスト技術を活かせた場面があれば、教えてください」という質問です。

中川勝樹氏（以下、中川）：いい質問ですねぇ。

和田：中川さんは俺にしゃべらせろと思っているかもしれませんけど、テスト技術を活かせた場面。後藤さん、いかがですか？

後藤瑞希氏（以下、後藤）：テスト技術を活かせた場面？

和田：はい。ドメイン知識を活かしていく話は今日たくさんうかがったのですが、テスト専門家としてのテストの知識や技術を活かせた場面です。

後藤：運用のお手伝いなどですね。QAはよく意地悪な検証をするじゃないですか。なので、リサーチャーさんや運用チームがイレギュラーなことを実現したいときに相談を受けて「ここは動きますよ」「こっちをこう設定すると、できるようになりますよ」というようなアドバイスをすることで運用のお手伝いができたりするのは、技術が活かせた場面かなと思いました。

和田：なるほど、おもしろい意見ですね。ありがとうございます。鈴木さんにもおうかがいしようと思っていて、同じ質問になるのですが、ドメイン知識とは直交しているかもしれないですが、テストの知識・技術が活かせた場面はどんなものがあるでしょうか？

鈴木里惇氏（以下、鈴木）：テストの技術で言うと、テストは計画・設計・実行というそれぞれのフェーズがあります。そこに対して、どういうスキルを持った人が担当がつくのか、体制をつくる上で考えたことでした。

実行の部分はテストベンダーさんに適性を持った実行担当者が多くいるのでお任せしたり、設計の部分は、最低限のエンジニアリングのベースの知識がある担当者じゃないとブラックボックスでも効率的なテストが設計できないので、そこはそういった素地がある人に担当してもらうなど。

テストチームを作る上で、テストのフェーズによって使うスキルセットや求められる技術は変わってくると思うので、保有スキルと役割といったところを意識したかなと思っています。

和田：テストという観点から、テスト計画から降りてくる体制づくりや、全体の力の入れどころ・バランスの取り方などに関して、ほかの案件でも続けられているテスト計画から落としていく知見がそのまま活かせたという話に聞こえました。

門谷篤氏（以下、門谷）：補足をすると、先ほど「テストエンジニアとQAエンジニアって違うんですか？」という話があったと思うんですけど、そこに関係する話だと思っています。ここで質問されているテスト技術の話は、テスト技法などを指しているのかなと僕は捉えたんですけど。

和田：そちらに聞こえますね。

門谷：先ほどの定義で言うとQC、Quality Controlの部分でテストエンジニアが活用すべき武器になるのが、ここで言っているテスト技術かなと思っています。もちろん、テストの詳細設計ではテストエンジニアがテスト技術をしっかり活用するというのが重要だと思います。

今日、ここにいるお二人が、QAエンジニアというポジションで考えると、そこのテストの詳細設計を100パーセントやっている仕事の仕方よりは、今テスト計画から落とす話などもありましたけど、もっとプロセス全体やプロジェクト全体という視点から捉えて活動している部分がすごく多いです。

そういうところでテスト技術そのものが100パーセント活かせるかという話になると、活用のしどころが違うのかなと思っています。今回の事例を、QAエンジニアのプロジェクト全体での活動に置いてみると、テスト技術が活かせる場面はそんなに出てこないというのが正直なところかなと思っています。

中川：テスト計画からテスト詳細設計といったQC部分との連携もあるので、そこではもちろんテスト技術、テスト技法の理解があるほうが、テストエンジニアとの会話がスムーズにできるということはもちろんあります。

テストの質をどう向上させた？

和田：それが実際、鈴木さんの講演資料とも関わってくるわけですよね。QA組織を立ち上げた時の役割の定義を再定義して優先度づけをして、これまでのLINEのQAのやり方にこだわり過ぎずに問題解決をしていく話……資料がSpeaker Deckに上がっているんですけど、そちらを見ながら話をしていきます。

例えば、先ほどいくつか質問があったんですけど、実際に鈴木さんの講演資料で「テスト担当組織の偏重や不明なテストの質」というところで「テストの質が内部で評価されていない」とあったんですね。テストのバランスが悪いというのは、先ほどの開発チームがやるテストとQAチームがやるテストのバランスの話だったと思っています。

テストベンダーに委託したテストの質が、内部で評価されていないので、質の向上を含めてどうやっていったかをもう一度簡単におうかがいしたいです。資料中に検収テストの精度向上とあったんですけど、具体的にはどんなかたちで立て直していったのでしょうか。

鈴木：そこはそんなに難しいことをしたわけではないですが、状況としてはテストを外部に委託していたんだけど、実際細かいところまでどんなテストをやっているかわかっている人がいないという状況でした。テストの組織がないので当然とも言えるかもしれませんが。

まず、「テストやっている項目がちゃんと開発案件に沿ったものになっているのか？」「その影響範囲のところだけをテストしているのか？」「ちゃんと正しいバグというか有効な不具合はレポートできているのか？」などの部分を精査しましたね。

テストベンダーさんに設計書やテスト仕様書を作ってもらっていますが、そこがしっかり計画通りの内容に沿っているか確認したり、観点レビューして「こういうところもテストしてください」みたいなフィードバックをしたり、今は細かくレビューして、精度は少しずつ向上できていますね。

和田：わりと投げっぱなしになっていたところを巻き取って、レビュープロセスを回していくところを地道にやっていったという話になるわけですね。

鈴木：そうですね。今までそこのレビュープロセスがない状態だったので、そこに我々が入って今はやっているという感じですね。

和田：ありがとうございます。

中川：「テスト設計の品質ってどういうのだろう？」という質問もあるんですけど、たぶん同じ部分の話になるのかなと思います。

和田：そういう質問もありましたね。

鈴木：そうですね。今、開発の豊留さんと仕事をしているところで言うと、「開発ではこういう部分をテストします。QAではこういう部分をテストします」など。

効率のいいテストをするために開発としっかり連携とれているかなという感じですね。

和田：ありがとうございます。

「やらかした」話を聞かせてほしい

和田：時間がだいぶやってきました。今、一気に票を集めている質問があるので、そちらにいきましょうか。

中川：ホットなやつがありますね。

和田：一気に上がってきたんですけど、こんな質問です。「わりときれいな成功話が多くてすごいなと思っています。でも、そうじゃなくて『これは失敗した』『やらかした』『これはうまくいかなかったな』みたいな話はあるんでしょうか？　順風満帆に、順調にQAがチームに馴染んだのでしょうか？」。

なんか大成功みたいな話になっているので、「いや、そうじゃない。そんなにきれいな話じゃないよ」「ここは苦戦した」「ここはがんばらなきゃいけなかった」みたいなものがあるんじゃないかなという話なんですね。

ということで、先ほど鈴木さんが話していたので、後藤さんからおうかがいしましょう。何かそういう話はありますか？

後藤：はい。スクラムにQAチームが参加してからは、単純に人数が多くなったので話す時間が長くなりましたね。

今までは開発チームでどう実装するかをお話しされていましたが、それにプラスして「テスト観点はどうですか？」という話をするので、タイムキープをしっかりしないとずっと同じ話をしてしまったりして、「効率的に進められないなぁ」と思う時がたまにありましたね。

和田：そのあたりは改善のためにどういう手を打っていったんでしょうか？

後藤：進行役の方と別にタイムキーパーを用意して進めてもらうなどしました。最近だと、最初に「何分間、話す。そしてストーリーポイントを出す。そのあとに議論をする。それは何分間」みたいな感じでしっかりタイムスケジュールを決めることで、改善されてきた感じがありますね。

和田：なるほど。ありがとうございます。

LINE × 出前館プロジェクトの「失敗した話」

和田：鈴木さんにも同じような話をうかがおうと思っています。成功話というよりは「これは失敗した・やらかした」「うまくいかなかった」みたいな話はありますか？

鈴木：非常にありますし、今回のスライドにはそういう話はあえて入れなかったんですけど、ぶっちゃけ、うまくいっていないことはすごく多かったです。やらかしたかはわからないですけど、「失敗した」は非常に多いです。

ここは豊留さんの意見も聞きたいところなんですけど、正直出前館は非常に難易度の高いプロジェクトで、途中から入ったことと、歴史が長くてシステムが非常に複雑なので、今でもミーティングに出るたびに新しい仕様を毎回知る状況だったりするわけですよ。

先ほど障害報を書いているという話をしましたが、出前館はまだ障害が多いサービスではあると思うんですね。それを減らしていくアプローチを開発と一緒にやっていかなきゃいけないと思っています。

開発と一緒に案件をテストしていく中で、お互い仕様がわからないことで影響範囲が読み切れずに結果としてバグが出てしまうことはよくあって、そういうことを減らすために日々努力をしています。

サービス全体の品質という観点では、正直我々が入ったので品質がよくなったみたいなところは、まだぜんぜん言い切れないので、そこはこれから頑張らないといけないなと思います。

地道に一つずつ失敗を減らすために

和田：豊留さんもせっかくなのでいかがですか？　「これはまだうまくいっていないな」みたいな。

豊留武氏（以下、豊留）：先ほどの鈴木さんお話にあったように、失敗はいろいろありました。「開発もわからないし、QAの方もわからないらしい」など、本番系でしか動かないようなコードがあったりして、QAの段階でもう見つけようがない不具合などもたまにあったりしました。

それが起きた時はもうしょうがないって言っちゃうとよくないんですけれども。「QAがちゃんと見ていないからダメなんだ」「開発がそこをちゃんと把握していないからダメなんだ」とかそういうお互いを責めるようなことはなかったですね。

「こういうことがあったから、次は出さないために、しっかりコードを追って本番系だけ発生するコードを書かないようにしましょう」などの振り返りをQAチームと開発、企画も合わせてできている体制は一応あります。

そうやって、お互い切磋琢磨してこれからもやっていければいいかなと思っていますね。決して順調ではないですけど、悪い方向には行かないようにしたいですね。

鈴木：たしかに。失敗を重ねるところはあるんですけど、「同じ失敗を踏まないように次から気をつけましょう」みたいに、しっかりコミュニケーションはできているので、同じミスは減っていっているかなとは思っています。

また新しい問題が出てきたりすることもあるんですけど、そういうものを一つひとつ潰していけている気がしていますね。

豊留：振り返りのタイミングをしっかり設けて、そこにQAの方も入ってもらったり、開発だけで閉じてやらないところが、いい運用の仕方かなと思いますね。

和田：ありがとうございます。

エラーが起きた際の再発防止策

和田：鈴木さんの資料にOutage Reportや不具合数など、「テスト活動の“質”の向上」とくにスライド左側の部分はどんな画面で、これを活用してどういうことをやっているのか。ここのスクリーンショットを拡大するとみなさん見えるし、いろいろ想像も働くと思います。

鈴木：ここのOutage Reportですかね。中身は改変していますが、本番で障害が出たり、本番で不具合が出てしまった時にレポートを作成する運用ルールにしていて、問題を発見した開発エンジニアやQAが書くこともあります。

フォーマットは「障害に対して、何が問題で、何が原因で、再発防止するためにはどういうことを行うか」。もちろんQAフェーズで救える問題や、システムテストでしっかり見なきゃいけない問題があると、QA側からも再発防止のプロセスを考えます。

実際、そこから再発防止のToDoリストを作って、BTS（Bug Tracking System）チケットを切って、改善を進めるものもあります。次から起きないようにプロセスにしっかり組み込むこともありますし、1つ1つの問題が起きた時に次以降で同じ失敗をしないような感じでしっかり活かせるような運用は考えながらやっている感じですね。

和田：ありがとうございます。スライド右側の緑色の部分が「やる・やらない」をトリアージしている部分とおっしゃっていましたね。もっと拡大すると、きっとテスト項目が並んでいるんですよね。きっと大項目・中項目みたいな感じにたぶんなっているんでしょうか。

鈴木：開発がもともと書いていたシステム一覧みたいな資料があって、リポジトリなどの情報も含めて誰が開発しているか、誰が開発担当で、パートナーさんがいる時はどこが作っているのかが一覧として書かれています。

そこのシステムに対して、我々はどこを見ているかを書いたのがこの資料ですね。なので、QA目線というよりは、開発がベースで作ったシステム一覧に対してその担当をこっちで割り振っていた感じになります。

和田：なるほど、そういう観点の資料なんですね。ありがとうございます。

アグレッシブなコミュニケーションの意味

和田：時間も差し迫ってきているのですが、まだ拾っておきたい質問があります。中川さん、「これ拾いたいな」という質問、ほかにもありますでしょうか？

中川：先ほどの「実際うまくいっていないことあるんですか？」という質問で、もっと門谷さんとか豊留さんから「いや、ぶっちゃけこんなことあったでしょ」みたいな話がないか、僕は気になっています。

（一同笑）

和田：いいですね。

鈴木：そこは「やらかしましたよね」みたいな話をぜひしたいなと思って。もしあれば（笑）。

中川：セッションの時間もギリギリになってきたので、「いや、ぶっちゃけこんなことありましたよ」みたいな話がもしあれば、生の声を聞きたいと思います。

豊留：いや、あまりないですし、不具合があっても「これは見つけられなくてしょうがないよな」とも思ってしまうようなものでした。それこそ「IE8でバグがありました」とかですかね。

鈴木：逆にもっとこういうところにコミットメントしてほしいみたいな話でもいいかもしれないです。

豊留：なんでしょうね……もっと企画の段階でもっとアグレッシブにいってもいいんじゃないかなと思ったりはしますかね。

和田：いいですね。

中川：もっとアグレッシブにと。今はアグレッシブじゃないということかもしれないですね（笑）。

（一同笑）

鈴木：そういうものは、なかなかフィードバックしてもらえる機会がないのでね。

豊留：そうですね（笑）。エンジニアはわりとマサカリを投げる人もいると思うんですけど、QAの方はそういう意見的なものはあまりないと感じています。

中川：もっとマサカリをバンバン受け止めて、逆に「投げ返すぐらいやってこい」という感じでしょうか。

豊留：開発の設計にも、どんどんマサカリを投げてもらえればうれしいですね。

鈴木：そうですね。お互い褒め合うだけじゃなくて、時には尻を叩くというか。

豊留：そうですね（笑）。

鈴木：プロジェクトをよくしていくために、厳しくというよりか、よくするための接し方みたいのをやっていければいいかなと。

豊留：そうですね。実際、エッジケースは開発エンジニアも見落とすシーンというのはたくさんあるので、そういうところを設計段階で攻めて指摘していただけるとすごく助かります。実際、助かっているので、そのへんは遠慮なくきてほしいですね。

和田：そうですよね。

鈴木：そうですね。そういうところを「このケースはしょうがないよね」と許すよりは、お互いに切磋琢磨して厳しくすくっていく感じにしたいと思います。

豊留：はい。

和田：うん、どうしてもいい話の方向に行っちゃうんですよね（笑）。

大きくなったQA・開発組織をどう再編成するか

中川：門谷さんからはお話はありますか？

門谷：なんか言ってやろうと思って一生懸命考えたんですけど、やらかしはあまりないですよね。逆にこれでもかというぐらい、LINEの品質保証としてしっかり見てくれるので。やらかしたというと、どうしてもすごいバグを出しちゃったみたいな、そういったことを思い出そうとしているんですけど、ないんですよね。

ただ、逆にいろいろ慎重にやっていることで、先ほども後藤さんも同じような話をしていましたがどうしても話す時間が長くなってしまいがちです。実際の開発やQAなどに割ける時間が少なくなってしまっているのではないかという思いはありますね。

あとは、スクラムのチーム自体が以前より大きくなっている。実際、開発とQ&Aを合わせて10人を超えているんですよね。最近感じている難しさにはそのあたりも起因しているのかもと思って、開発とQAの混合チームを2つに分けてみるチャレンジもありなのかなというのを最近思い始めているところですね。

和田：そうですよね。でも、それでまた開発とQAチームに分けちゃうと元の木阿弥になってしまいます。つまり、水平分割と垂直分割みたいな話ですけど、どうやって分けるのかみたいな話もありました。

きっと、システムとして1つの大きなシステムではないので、デプロイの独立性を保ちたい範囲で2つに分けて、QAチームとしてはどちらにも入るというか。

チームが4人か5人という話ですから、2人ずつみたいな感じで分けていくのは大いにありだと思いますしほかの組織でいくつかやっていることでもありますよね。

そうすると、いわゆる「QAチームを1つにするべきか、それともバラバラに分かれて各チームにジョインすべきか？」という各企業が頭を悩ませる普遍的な問題が出てくるわけですが、一般かつ、全体的な方向性としてはチームに入っていったほうがよい結果になるのは見えてきています。

それを横串を挿して、QA組織としてレベルを上げていくためにはどうするかが次の課題になるのがよく見えてくる構図ですよね。

ということで、そろそろ終わりにしないとならないという時間になってきてしまったので、まとめに入っていきたいと思います。

QAと開発はいかに協働してきたか

和田：今日は実際に講演を2つやっていただいて、そのあとパネルディスカッションというかたちで、実際にQAのチームと一緒に働き始めた開発チームとしてはどういった観点で見てどういった景色が見えていたかも含めてお話をうかがってきました。

だいたい1時間ぐらいパネルディスカッションをやってきたのですが、slidoで上げていただいた質問の中で、upvoteが多く入ったところに関しては、似たような質問がたくさんあるので、ある程度傾向としては押さえられたかなと思います。

なので、今日は2時間ずっといろいろな観点でお話をしてきたのですが、LINEとして2つのチームがどういったかたちで、QA、Quality Assuranceという観点で、QCだけじゃなくてQA的な観点、つまりプロダクト品質をプロセス品質で支えるという観点からどういう取り組みをしてきたか、2つのチームの事例を通じてお話をうかがってきました。また、いい資料を共有していただきました。

実際にこのイベントを視聴くださっているみなさん、slidoに質問をたくさん投げてくださったみなさん、本当にありがとうございました。

中川：ありがとうございました。

和田：お別れの時間になってしまうわけですが、中川さんいかがですか？

中川：非常に時間もギリギリな中、和田さんにはうまくまとめていただいて、今日は本当にありがとうございます。

ほかのプロジェクトの事例でもお話できることはあると思うので、今日のようなテーマは引き続き、また開催できる機会があればいいなと思っていますので、今後もよろしくお願いします。