ヤフー、楽天、クックパッドにおける「テスト」への挑戦――ツール、体制、アーキテクチャはどうなっているのか：システムテスト自動化カンファレンス2015（2/3 ページ）

「システムテスト自動化カンファレンス」第3回が開催。ソフトウェアテストの現場にはどのような課題があり、エンジニアがどう解決してきたかが紹介され、いくつか共通するキーワードが見えてきた。

[高橋睦美，＠IT]

【楽天】継続的テストがもたらす価値を見える化する「レポート」「フィードバック」

　楽天の荻野恒太郎氏は、「楽天の品質改善を加速する継続的システムテストパターン」と題して講演を行った。同じく楽天の菊川真理子氏と、“ゆるい”のになぜか胸に突き刺さる言葉をちりばめた寸劇を交えながら、「生産性だけでなく、開発の永続性やプロダクトの信頼性を挙げるためのコンセプトとしての『継続的テスト』」の在り方について説明した。

CI／継続的フィードバック

　永続性を支えるキーワードの一つが「CI／継続的フィードバック」だ。荻野氏は「一番いいところは、開発者がコミット直後にバグに気付けること。毎日テストして毎日フィードバックを得られると、いつ失敗したかが一目瞭然になる」と述べた。同社の場合は、JenkinsとCucumber、Gatling、SonarQubeといったツールを組み合わせ、「毎日実行、毎日レポート」を実現しているという。

　この結果をメトリクス化することも重要だ。「これには二つのポイントがある。一つは、品質改善によって『こんなによくなった』という結果が目に見え、現場のモチベーションが上がることだ。もう一つは、その成果を上の人に見せられること。一日に何回、何十回とデプロイしていることを自動的に取得し、メトリクスで示せば、上層部にもその価値を示すことができる」（荻野氏）

　荻野氏はこの取り組みを、「ATM貯金箱」に例えた。昔ながらの貯金箱は、割って中身を数えないといくらたまったか分からない。これに対し、継続的テストは、「コインを入れたら今の貯金額が分かり、いくら足りないのかをフィードバックしてくれる貯金箱のようなものだ」。これに従って「もうちょっと足そう」といった具合にコントロールしていくことができる。

生産性と自動テスト：貯金することを考えてみる（荻野氏の講演資料より）

「1日にn回テストする」ことが可能なアーキテクチャ

　また、「テスト可能なアーキテクチャ」も重要であり、そのために「プロダクト」と「自動テスト」という二つのシステムを分けて考えるのではなく、一緒に考えていくことが必要だとした。

楽天 荻野恒太郎氏

　その好例として荻野氏が紹介したのがグーグルだ。「Google Test Automation Conference（GTAC）」の講演では、検索というプロダクトを構成するコンポーネントの中に『自動テスト』や『自動評価』といったコンポーネントが含まれている。つまり、運用やテスト、リリースのための要件をプロダクトの中に盛り込んでいることが紹介されたという。

　「『1日にn回テストする』といった要件も盛り込んだ上でシステムとしてリリースしている。プロダクトと自動テストシステムは一緒のもの。一緒に要件定義し、一緒にアーキテクチャを考えるとやりやすい」（荻野氏）

　当たり前だが、テストはそれ自体が目的ではなく、最終的にはプロダクトの品質を上げていくことが目標だ。そこで「チームとユーザーに、またビジネスとテクノロジーの各面でどういう価値を提供するかを、アジャイルテストの価値を四象限に分けて整理することが重要だ」という。

　この文脈で整理すると、DevOpsにおけるテストの価値も見えてくるという。「テストをちゃんとやらないでDevOpsを進め、Dev側でバグを出し切れないと、Opsフェーズに入ってバグが見つかり、その修正に追われて新しい機能追加ができないといったことになりかねない。当たり前の話だが、Devで作ったものをOpsに提供する前にきちんとテストすることによって、Ops側に『信頼できるコード』という価値を提供できるし、Dev側にも開発スピードが上がるという価値が提供される。そしてDevが加速することによって、ユーザーにはより高い頻度でバリューを提供できるようになる」

「テストだけ」ではなく「テストも」できるエンジニアに

　萩野氏は最後に、菊川氏の「テストのスキルって、なめられがちじゃないですか」という小芝居に答え、テストエンジニアの人材育成とスキルセットについてもコメントした。

　「テストができる人、テストをやりたい人があまりいない。そもそも新しい分野であり、テストエンジニアはまだまだ少ない」（萩野氏）

　その意味で育成は必須なのだが、テストだけができるエンジニアでいいというわけではなさそうだ。

　「楽天はサービスカンパニー。だから、テストだけできる人よりも、機能実装もでき、テストもできて、リリースもできる人がうれしい。チームの中には、リリースオートメーションを経験してからテストオートメーションに来た人も多いし、DockerやInfrastructure as a Codeに関心を持っている人もいる。自動化とリリース、テストといった部分を行ったり来たりしながらキャリアアップしていく、というイメージを持っている」（萩野氏）とし、特にクラウドや自動化に対する抵抗感を持たない若いエンジニアに、会社の中での自動化をどんどん進めていってほしいと呼び掛けた。