Agile Testing Days 2015でRedgate SoftwareのJose Lima氏が，マイクロサービスの開発とテストに関する自身の経験について講演した。InfoQは氏とのインタビューで，マイクロサービスを採用したプロダクト開発のメリットとデメリット，マイクロサービスによるプロダクトの品質向上，マイクロサービスのテストに必要なテスタのスキル，マイクロサービスの開発とテストから学んだことなどについて聞いた。
InfoQ: マイクロサービスを採用したことで感じたメリットやデメリットについて，詳しく説明して頂けますか？
Lima: 最初にお断りしておきたいのは，私が今回採用したマイクロサービスアーキテクチャは内部ユーザを対象に開発した，社内利用が中心のサービスだということです。私たちが“ユーザ”(私は社内開発チームに在籍していますので，ユーザの大部分はRedgate Softwareのスタッフです)とコンタクトを取れる場所は，ショッピングカートなどWebサイト上にしかありません。メリットだけでなく，ロードなどデメリットもありますが，このような状況で今回大きな成功を収められた点のひとつは，各サービスの結合性が低くなったことです。開発では相当数の外部サービスやアプリケーションを統合しなければならないため，設計原則としての疎結合が本当に役立ちました。
デメリットとしてあげたいのはパフォーマンスですね。システムがチャネルを通じて通信するようになったために，通信時間が長くなったことの影響があるのかも知れません。“あるかも知れません”と言うのは，私たちには当てはまらないからです。Agile Testing Daysの講演でも話しましたが，私たちの環境では，メッセージ到達に要する時間が問題となることはありません。ただし違う環境(例えば銀行など)では，注意が必要かも知れませんね。
InfoQ: マイクロサービスを採用することで，プロダクトの品質が向上したという例を紹介してください。
Lima: 私たち自身のカートで実現したチェックアウトが，一番よい例だと思います。このカートは支払だけでなく，インボイスを処理したり，ライセンスシステムと交信したり，ユーザの詳細情報を記録したりすることができるようになっています。全体を分割する作業がまだ残っているのですが，支払完了を記録するための小型サービスは開発が完了しています。支払処理だけを実行した後に，他の処理がその情報を参照する仕組みになっています。
InfoQ: あなたのチームで実施したマイクロサービスのテスト方法について，詳しく説明してください。
Lima: テストに対するアプローチが，この数年で大きく変わったことは事実です。ただ私自身，他のチームで開発した経験がないので，以前のテスト方法と比べて何が変わったかという説明しかできません。以前に比べると，開発者やプロダクトオーナと話をする機会が増えたことは間違いありません。場合によっては，ほとんどアドバイス役に近いことをしています。私がチーム内でユニットテストや統合テストを書くことはありませんが，それらのレビュー(あるいは関連するコード修正のレビュー)役に選ばれることはあります。
ただし，その時点で目指している方向を実現するために，開発の原則も合わせて導入していますから，テスト方法の変更というよりも，開発とエンジニアリングの変更といった方がよいかも知れません。プロダクトとして提供可能なマスタを常に用意するようにしたことも，その例のひとつです。プロダクトの水準に達していないものは，マスタにはプッシュしないようにしています。私自身は技術的な作業よりも，もっと(予備的な)テストを行うことが多くなりました。単純なバグを見つけ出すのではなく(姿勢の変化ということです)，テストの対象とするシステムを学んだり調べたりすることに多くの時間を費やすようにしています。
InfoQ: マイクロサービスのテストには，どのようなスキルが必要なのでしょうか？
Lima: 講演では３つのカテゴリについて話しました。間違いなく必要なのは，自動化環境の構築，継続的デプロイメントの優れたプラクティスといったものを学ぶ技術的スキルです。テストの自動化も必要なスキルだと言う人がいますが，私はそうは思いません。そもそも私は自動テストを信用していませんし，自動チェックならばテスタでなくても，他のチームメンバでもできます。自動テストはなくても，確かに自動チェックは必要ですね — テストは単なるチェック以上のものだと思いますし，チェックプロセスならば自動化も可能でしょう。ただし，それが何をするのか，どんな意味があるのかを理解した後でなければ，必要な処理が行われているかどうかをチェックすることは(自動化の有無に関わらず)できません。
私自身のビジネス分析スキルも，この何年かで成長しました。以前よりもステークホルダやプロダクトオーナと会話する機会が多くなり，得られる情報も増えた(こういったことの可能なBAがいる，という幸運もありますが)ため，探索的なテストも以前より効果的に行えるようになりました。それから最後に，最も必要なスキルとして挙げたいのはソーシャルスキルです。私自身も時間を掛けて伸ばしてきましたし，そのためのチャンスは毎日，どこにでもあるはずです。
InfoQ: マイクロサービスの開発やテストから得た教訓について教えて頂けますか？
Lima: 技術的なスキルの変化もありますが，最終的に開発するサービスの数がチームのメンバ数よりも多い状況では，考え方もおのずと変わってくると思います。すべてのメンバが個々に担当する対象だけでなく，集合的な意味で，すべてのサービスを担当することが必要になります。こうすることでノウハウがチーム全体に伝わるようになりますから，メンテナンスの煩わしさが低減するとともに，さまざまな経験を持った人たちの意見を新たなサービスに反映できるようになるのです。
InfoQ: マイクロサービスの採用を検討している人たちに対して，伝えたいと思うアドバイスは何かありますか？
Lima: アプローチの長所と短所を十分に検討することと，マイクロサービスへの転換を実施した企業や人の経験談を，成功例だけでなく失敗例も含めて探すことを勧めたいですね。このアーキテクチャのアプローチを採用するメリットを重視するのは当然ですが，デメリットもありますから，自分たちの状況を考えて，このアプローチが現行のものよりもうまく行きそうか，あるいは他にもっと適切なものがあるのかを検討する必要があります。その結果として採用を決めたならば，(上述したような)スキルを持った人たち，変化に耐える意思のある人たちに参加してもらえるように努めてください。