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

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

[高橋睦美，＠IT]

　開発効率を高め、コストを削減し、生み出されるシステムやサービスの品質を高める上で不可欠なプロセスが「テスト」。そのテストを自動化し、効果を最大限に引き出すために必要なことは何だろうか――そんな問題意識をぶつけ合う場として、2015年12月13日に「システムテスト自動化カンファレンス」が開催された。

　3回目を迎えた今回はテスト自動化エンジニア「個人」にフォーカス。各セッションでは、現場でどのような課題に直面し、解決してきたかが紹介され、「上層部の理解」「テストが提供する価値の見える化」「テスト可能なアーキテクチャの構築」といった共通するキーワードが見えてきた。その模様の一部を紹介しよう。

【ヤフー】モヤモヤを抱えたシステムを根底から変えたのは？

　このまま改修を続けていくと、いつか破綻するかもしれない。かといって、根本的な作り直しに踏み切るのも今動いているだけに怖い……そんな「モヤモヤ」を抱えたシステムは少なくないのではないだろうか。ヤフー MSC開発本部マーケッターPF開発部の森下大介氏は「広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと」と題して自らの経験を紹介し、「テストができない言い訳をなくしていくこと」と「部門長クラスの理解」が重要だと述べた。

ヤフー MSC開発本部 マーケッターPF開発部 森下大介氏

　森下氏が紹介したシステムは、広告主向けの入稿やレポートといった処理を行うもの。利用者向けのWebサービスとは異なりエンタープライズ的な要素が高く、同社のビジネスの根幹を支えるものだ。

　だがこれが「何をやるにしても、何だかツライ」というシステムだった。「メソッド名のスペルミスを直したい」というレベルのちょっとした修正でも、grepでキーワードを抜き出して修正し、手作業でテストを通すというプロセスを強いられていたという。Web APIに関する統一されたドキュメントも存在しない一方で、本来ならばエラーになるような間違った引数を渡しても、「何となく動いてしまう」という状況だった。

　森下氏はいくつかの理由を挙げた。システムの大規模化、複雑化に加え、「道具とやり方がシステムの要請に合っていなかった。型宣言もコンパイラもない言語を用い、テストを前提としたアーキテクチャになっておらず、無理やりテストしようとしてもコストがかさむ」（同氏）。その一方で既存コンポーネントは拡張され、新規コンポーネントは追加される。結果として「技術的負債」が膨らむ状態だったという。

　「皆も、根本的にひっくり返さないといけないという状況はうすうす分かっていた。ただ、会社としてもビジネスの根幹を担うシステムなのでそうそう手が出せず、悶々としていた」（森下氏）

　そんな状況を変えるきっかけとなったのが、組織変更に伴って新たに就任した部門長の「一から全部変えよう」という鶴の一声だったという。森下氏は「こういうきっかけをもらえたのは大事だ」と振り返る。「ボトムアップで現場だけでできることには限りがある。組織のバックアップや上からのハッパは重要だ」

　そこで森下氏は、テストを当たり前にできるシステムを作るための体制を整え、変革に取り組んだ。「目的を見失わないように注意した。変わるべきはまず自分たち。『エンジニア自身が強くなることが重要であり、システム刷新はその結果である』と位置付けた」（同氏）

言語を変え、アーキテクチャを変え、IDEを変え

　まず、使用するプログラミング言語を変え「Java」を採用した。型やコンパイルがあり「しょうもないミスを動かすまでもなくつぶせる」ことに加え、メモリ管理の容易さや、統合開発環境や優れた解析ツールがそろっていたことも要因だった。

　次に取り組んだのは、「テストできるアーキテクチャにすること」。これを理解するには、「テストができない状態」を考えると分かりやすいという。テストを動かしたくても準備が大変でコストが掛かったり、ブラックボックステストになっていたり、CI（継続的インテグレーション）／CD（継続的デリバリー）で実行できなかったり……同氏は、その根本的な原因を「プロダクト自体がモノリシックな固まりになっていること」にあると考え、DI（依存性の注入）を採用。依存性を排除し、真の意味でのユニットテストができるような形にした。

DIを採用したコードにテストケースを仕掛けてみると……（森下氏の講演資料より）

　当初は「Junit」を用いていたが、テストケースの作成に労力を割かなくても済むように「Spock」を用い、ドメイン固有言語でテストを記述できるようにした。この変更に伴ってIDEもIntelliJに変えたそうだ。

　「ここまでおぜん立てできてやっと、当たり前のようにテストできるようになった」（森下氏）

　これに加え、インタフェース定義言語を一から作成した。「人がAPIを考えて実装し、ドキュメント化していると、どうしても認識の違いやずれが出てしまう。結合試験を行うまで、そのずれが発見できない」ことを解消するのが目的だ。

テストできない言い訳をつぶす

　森下氏は最後に、いくつかのポイントを挙げた。

　「問題検出はできるだけ前工程に持ってきた方がいい。どうしても先の工程に進むとソースコードが開発者の手元から離れ、問題を見つけ、対処するコストがかさんでしまう」。今回紹介した取り組みも、それを目指した結果だという。

　二つ目は「テストできないという言い訳や要因はできるだけつぶす」ということだ。「テストできないアーキテクチャや言語だ」「コストがかさむ」といった理由をつぶしていくと、「エンジニアもテストを書くようになる。誰だってテストをした方がいいのは分かっているし、自分で書いたものを動かしたいと考えている」という。

　最後に森下氏は再び、「部門長や組織のサポートが大事」と述べた。いくら現場に問題意識があっても限界はある。「部門長や組織が攻めと守り、両方の開発の在り方に理解を示してくれると効果的に取り組める。加えて、目的と手段を取り違えないよう、現場から一歩引いた目で見てもらえるといいのではないか」（森下氏）。