Agile2017参加レポート - LINE ENGINEERING

はじめに

こんにちは。LINEのSET（Software Engineer in Test）のItoです。

世界最大のアジャイルのカンファレンス「Agile2017」に参加してきました。今年は8月7日から11日にかけて、アメリカのフロリダ州オーランドで開催されました。

この記事では、LINEでのSETの仕事と関連付けて、以下の観点からこのカンファレンスをご紹介します。

テスト自動化の進め方と注意点
メトリクスによるプロセス改善シミュレーション
著名な企業の現場事例

SlideShareにも参加レポート資料を公開していますので、よろしければこちらもご覧ください。

1. テスト自動化の進め方と注意点

『アジャイルサムライ−達人開発者への道−』の著者として日本でもおなじみの、Jonathan Rasmussonさんによるセッション『7 Sources of Waste in Automated Testing and How To Avoid Them』が、テスト自動化の進め方と注意点を考えるうえで非常に有益でした。

テスト自動化を進める際には、技術的側面と文化的側面から、特に次の7つの点に注目して改善を進めると良いとのことでした。

技術的側面

スローテスト
当てにならないテスト
早期に作り込み過ぎたテスト

文化的側面

言語とフレームワークの欠落
スキルの欠落・不足
不自然な役割分担
観点の欠落

1. スローテスト

自動テストが遅くなると、結果（フィードバック）をすぐに得られなくなるため、開発者やQAがテスト自動化を辞めてしまうきっかけになる恐れがあります。

テストには、実行時間の長いものと短いものがあります。テストの性質に応じて、以下のような方針のもとにテストを設計すると良いとのことです。

実行時間の長いUIテストは、ユースケースが想定どおり実現できているかどうかや過去の障害が再発していないかどうかなど、ケースを絞って実施する。
実行時間の短い単体テストのカバレッジを増やすことで細かなバグを事前に除去し、UIテストのケースを必要最小限に絞れるようにする。

スローテストの解決方針を考えるうえでは、以下の「テスト自動化ピラミッド」が役に立つとのことでした。

LINEのSETは、自動テストの実行スピードをモニタリングしており、必要に応じて速度向上のための改善を行なっています。

2) 当てにならないテスト

実行するたびに結果が異なるテストは、フィードバックの質を下げてしまいます。

特にテストの量が多い場合、信頼性の低さは致命的な欠陥となり得ます。テスト自動化を進めるにあたっては、当てにならないテストを早期に発見・修正し、削除する必要があります。

3) 早期に作り込み過ぎたテスト

プロダクト・サービスの開発初期は、UIが頻繁に変わり得ます。そのため、UIテストを早期に作り込み過ぎると、上述の「当てにならないテスト」になり、修正頻度が高くなってしまいます。したがって、テスト自動化を進めるにあたっては、ROIを考慮しながら、ある程度UIが安定してからUIテストを実装・充実させると良いです。

4) 言語とフレームワークの欠落

例えば、チームメンバーやステークホルダーの間で「結合テスト」という用語の定義がみな違っていた、という経験はないでしょうか？テストに関する共通の語彙や観点をあらかじめ用意することで、こうした認識のズレを防ぎ、共通認識を作り上げると、テスト自動化の推進に寄与します。

LINEのSETおよびQAは、テストに関する語彙や観点を、「ISTQB」および「JSTQB」に準拠するようにしています。

5) スキルの欠落・不足

リファクタリングやテストの観点に関する知識が不足していると、テストスクリプトのコピーアンドペーストによる重複が増え、結果としてテストスクリプトの保守性が損なわれる恐れがあります。この課題を解決するには、コードの可読性を高める施策をすると良いです。ペアプログラミングやモブプログラミングを採用すると、コードの可読性を高めるのに役立ちます。

LINEでは、静的コード解析ツールの活用を広め、技術的負債になり得るコードの重複箇所やバグを発生させる箇所の早期検知および修正を進めています。

6) 不自然な役割分担

開発者とQAがサイロ化してしまうと、お互いの情報交流がなくなり、結果課題の解決スピードが遅くなってしまいます。そのため、開発者とQAを同じチームにしたり、システム環境を分けずに共用したりすると良いとのことです。

LINEのSETは、このサイロをなくすための情報共有の仕組みづくりや、開発者とQAとが協力し合いながらプロダクトを改善していくプロセスの構築もミッションとしています。

7) 観点の欠落

全ての観点・機能をテストすることと、テストの実行スピードを高めることとの間には、トレードオフが成立します。各サービス・プロダクトに適合した、テストの観点と実行スピードとのバランスを見つけることが肝要です。

以上の7つの点に加えて、Jonathanさんは、勤務先であるSpotifyで以下の取り組みを行なっているそうです。

テストに関わる全ての情報をモニタリングする。
専任のテスト自動化エンジニアを置く（LINEのSETは、まさにこれに該当します）。
生産性向上のための専任チームを置く。
継続的に1週間ごとにリリースする。
テストエンジニアの社内認定試験を作成・実施する。
チームに権限・説明責任を付与する。

確かに、上述の7つの点を解決する内容になっていますね。このセッションで得たものは、今のLINEのSET活動でも大いに活用しています。

なお、このセッションの内容をより詳しく知りたい方は、Jonathanさんの最新の著書『The Way of the Web Tester』、およびその日本語翻訳版の『初めての自動テスト ―Webシステムのための自動テスト基礎』を一読されることをおすすめします。

2. メトリクスによるプロセス改善シミュレーション

Peter Kananenさんによるメトリクスのワークショップ『Hands-On Flow Metrics』は、メトリクスの取得対象と活用方法を再考する意味で興味深かったです。

たとえば、スクラムでは「バーンダウンチャート」や「ベロシティ」といったメトリクスを使用することが多いです。しかしこれらは、ある一時点のスナップショット情報としては有益ですが、そこに至る過程で何が起きたのかを検知して対策を打つための情報としては不足があります。そこでPeterさんは、以下のフローに関するメトリクスにも注意を向けるべきと説きます。

サイクルタイム：ある要求を発見してから、それをユーザーへ提供するまでの期間
キュー時間：次の作業フェーズを開始するまでの待ち時間
バッチサイズ：各作業フェーズで一度にこなすタスク量
スループット：一定期間におけるアウトプット量

ワークショップではこれらのフローに関するメトリクスを深く理解できるように、Peterさん作成のかんばんシミュレータ（上の図を参照）を使って、どのようなアクションを取れば上述のメトリクスを改善できるかを実験しました。

ちなみにこのシミュレータは、作者のPeterさんのご好意により、日本でも自由に使用して良いとのことです。

このシミュレータ自体が、スクラムやかんばんの理解を深めるうえで非常に有益です。アジャイルを実践されている皆さんには、ぜひとも試していただきたいです。また、スループットをお金（売上・利益）で算出している点も興味深いです。

LINEのSETとしては、コードカバレッジや静的コード解析の結果といったスナップショット情報だけではなく、以下のフローに関するメトリクスにも目を向け、会社の売上と利益に貢献するためのテスト自動化の導入・改善を進めています。

自動テストや静的コード解析の平均実行時間
コードカバレッジや静的コード解析の結果の、時系列による推移（トレンド、ヒストリー）
自動テストの導入・改善による、障害件数と損失金額の削減およびMTTR（平均復旧時間）の短縮

3. 著名な企業の現場事例

Agile2017は、多くの国際的に著名な会社による、アジャイルに関する生々しい現場事例を聞くことができるチャンスでもあります。今回のカンファレンスでも多くの事例を聞くことができましたが、その中からSpotifyとHunter Industriesの2社の事例について紹介します。

1) Spotify

『カンバン仕事術 -チームではじめる見える化と改善』の著者のJoakim Sundénさんとその同僚のCatherine Peck-Phillipsさんによる『You can do better than the Spotify Model』は、会社の急激な成長で発生した課題とその解決策を紹介するセッションで、非常に示唆に富むものでした。

Spotifyは、多くの著名なアジャイルコーチが集う会社としても有名で、自社のアジャイルのアプローチを「The Spotify Model」と称して公開しています。

そんなSpotifyでも近年、以下のような課題が見受けられるようになってきたそうです。

TDD（テスト駆動開発）を行わなくなった。
タスクボードを使わなくなった。
R&D部門以外では、アジャイルを行わなくなった。

これらの原因としては、会社が急激に成長して、わずか4年で社員が1,600名も増加したため、新入社員たちを迅速に会社に適応させきれていないことが大きいそうです。

そこで現在取り組んでいる解決策が、「The Spotify Model + ? = Profit」という「公式」とのことでした。

この「公式」の意味は、以下のとおりです。

上述の「The Spotify Model」を、行動のベースとする。
課題のコンテキストに応じた解決策を考え抜いて適用する（上の公式の「?」に相当）。
必ず「Profit（利益）」につなげる。
上記を実現するために、「Autonomy（自立性・自律性）」を重視する。

自分たちがこれまで築いてきた技術・文化をベースとしつつ、それぞれの現場に即した解決策を見つけ、そしてそれを売上・利益にまでつなげることを念頭に置いて行動する。「でもやるんだよ！」という姿勢に、共感を覚えました。

LINEのSETの活動指針としても、これまで築き上げてきたものを尊重すること、サービス・プロダクトに応じた解決策を見つけること、そして売上・利益につなげる施策を実施することの3点を重要視しています。

2) Hunter Industries

Hunter Industriesは、ゴルフ場などのスプリンクラーの製造で、アメリカで80%以上のシェアを占める会社です。しかし我々IT業界においては、「モブプログラミング」の発祥の地として、近年急速に注目を集めています。

そのHunter Industriesのキーパーソンの1人、Chris Lucianさんによるセッション『How we grew Mob Programming, preserved culture, and maintained quality』は、単にモブプログラミングという手法の新規性だけに限らず、テスト自動化をベースとした技術優位の確立の重要性も強調されていて、非常に刺激的な内容でした（詳しくは、Chrisさんのこのセッションに関する論文「Growing the Mob」をご覧ください）。

Hunter IndustriesもSpotifyと同様に、チームメンバーが5名から30名に急増し、新入社員たちをいかに迅速に会社・モブプログラミングに適応させるかが大きな課題とのことでした。それに対するChrisさんのアプローチは、技術優位をベースとしながら、毎月2名のペースで少しずつメンバーを育成していくというものでした。

Chrisさんのチームにおける「技術優位」とは、具体的に以下のものを指します。

常にクリーンなコードベースで仕事をする。
単体テストとユーザー受入テスト（BDD）の自動化を実施する。
BDDの実行結果をプロダクトオーナーがチェックし、リリース可否の判断を行う。
リリースは1日2回行う。

いずれも、地道な活動の積み重ねですね。

Chrisさんのチームがすごいのは、この技術優位をベースとしながら、さらに以下を実践していることです。

アジャイルの原則に忠実に従って、プラクティスを実装している。
シンプルな解決策を常に追い求め続けている。

実際にその成果として、ここ5年間一切バグを出していないそうです。

モブプログラミングは手法の新規性につい目が行きがちですが、その本質は上記の施策群の集積にあります。これらの施作群を着実に実行していくため、技術優位というベースをしっかりと確立していくことが重要であると、心を新たにした次第です。

4. 結論

私はこのカンファレンスの一連のセッションから、次の3点を持ち帰り、実務に活かしています。

1) 技術優位をベースとした地道な改善活動の積み重ねを、あらゆる課題の基本的な解決策とする

Hunter IndustriesのChrisさんのモブプログラミングによる改善は、詰まるところ、技術優位・技術基盤をベースとした、地道な改善活動の積み重ねでした。

技術優位を確立したうえで、シンプルさを追求し続けること、そしてトライアルアンドエラーの繰り返しによる継続的な改善を行うこと。

同様のアイデアが、LINEにおける仕事の仕方と価値基準とを定義した「LINE STYLE」の一要素「SPEED -Survival of the fast」にも、以下のように明記されています。

私たちはこれまで、愚直に、泥臭く、このトライアンドエラーを何百回、何千回と繰り返し、ユーザーと共にサービスを磨き上げてきました。

世に出す速さ、改善する速さ、一つところに留まらず、絶えず変化し続ける速さ、それこそが、私たちの競争力です。

私は上記のアイデアをベースに、SETとしてテスト自動化を推し進めるために、特に以下の点に注力しています。

静的コード解析ツールを整備し、必要な人がすぐに使えるようにする。
テストに関心のある開発者と共にペアプログラミングなどを行い、開発者のスキル、およびテストの質と量とを向上させる。
負荷テストなど、現状不足のある領域をカバーするためのテストツール・ケースを整備する。
ロール間・チーム間の情報格差をなくし、またトラブル情報などの共有を迅速化する仕組みを整備し運用に乗せる。

テスト自動化を含む改善活動は、終わりのないマラソンであるともいえます。その道のりを、いかにシンプルかつイノベーティブに進めるようにするか？これが、私の直近の狙いでもあります。

2) 技術だけではなく、組織文化の側面からもアプローチを行う

Spotifyにおける各種施策は、技術的側面だけではなく、組織文化の側面からもメスを入れているものが目につきました。

テストエンジニアの社内認定試験を作成・実施している。
テスト自動化に関する権限・説明責任をチームに付与している。
「The Spotify Model + ? = Profit」により、自分たちの文化をベースに改善活動を行っている。

国内・国外問わず、「アジャイル」は「アジャイル開発」または「アジャイルソフトウェア開発」と表現されがちです。しかし、開発手法の一種と表現してしまうと、技術的側面だけに目が向き、改善のための選択肢を狭めかねません。根本的課題を発見し、組織全体の改善を持続的に行なっていくためには、時にはプロダクト開発の阻害要因となり、また時にはそれらを克服する鍵ともなる、組織文化の面にも配慮が必要です。

先述の「LINE STYLE」も、組織文化の面からの継続的改善を念頭に置いて策定されたものといえます。

文化の側面からの改善活動としては、以下のことを実践しています。

SETが開発者・QAと共にプロダクションコード・テストスクリプトを開発することで、テスト自動化のプロセスを組織文化として定着させる。
単体テストのコードカバレッジおよび静的コード解析の結果を定期的に取得して、現状・トレンド・改善点を、開発者・QA・マネージャー・ステークホルダーに常に見せるようにする。
ロール内での局所最適ではなく、プロダクト全体での最適を常に意識して行動できるよう、仕組み・プロセスを整備し運用に乗せる。

3) 売上・利益に寄与する施策を実施する

Spotifyの「The Spotify Model + ? = Profit」は、明確に会社の利益に寄与することを目指したものでした。またPeter Kananenさんのかんばんシミュレータでは、スループットの単位が金額（売上・利益）となっていました。

今日においても、アジャイルの各種プラクティスやテスト自動化は、開発の楽しさ・快適さや開発生産性の向上といった観点・目標から語られることが多いです。楽をすること・楽しむことは美徳ですから、この視点自体は重要です。その一方で、開発の楽しさだけを追求し過ぎてプロダクト開発に失敗してしまったり、開発生産性向上の目的を明確にしないままアジャイルを導入したためにメンバーが疲弊してしまったりという事例も、これまで多く目にしてきました。

プロダクト開発の当事者として振る舞うのであれば、売上・利益に寄与する視点を持って行動することは有益です。なぜならば、売上・利益はお客様に対する貢献の数値化であり、プロダクト開発を継続的に成功させていくための礎となるからです。

売上・利益といった金銭情報をメトリクスとし、それに対する寄与を明確に動機づけることは、プロダクト開発の質を向上させると考えます。

LINEでのテスト自動化の施策も、この方針を反映しています。具体的には、以下のことを実践しています。

障害により生じた影響を「金銭的損失」として計上・共有し、プロダクト開発関係者全員の意識改革を図る。
MTTRの短縮を主要メトリクスとし、その改善をテスト自動化および関連施策で実現する。
テスト自動化の充実によりサイクルタイム・可能リリース頻度を向上させ、プロダクト開発をより売上・利益に密接に関連付けるようにする。

来年のAgile2018

さて、このアジャイルカンファレンスですが、その名前が示すとおり、毎年開催されています。来年も、アメリカのカリフォルニア州サンディエゴで、「Agile2018」が開催されます。

このカンファレンスでは、普通に各セッションに参加するだけではなく、登壇の機会も広く開かれています。登壇に関しては、2017年12月初旬頃に、セッションの公募が開始されます。セッションの種類によって応募方法が少し異なりますが、一般的には、6〜8ページの論文を執筆し投稿することになります。私も2014年に「Technology-Driven Development: Using Automation and Development Techniques to Grow an Agile Culture」を執筆・投稿し、採択されて登壇することができました。

このカンファレンスは、世界中からアジャイルに関する著名人や実践者約2,500人が一堂に会する、世界の最新の情報と有識者に接することのできる非常に良い機会です。カンファレンスに参加するだけでもプラスになりますし、登壇すればさらに多くの経験と世界中の仲間を得ることができます。

皆さんも、この機会を利用されてみてはいかがでしょうか？

最後に

LINEでは、エンジニアであれば誰でも海外カンファレンスに年1回参加できる制度が存在するため、このブログでは参加者による参加レポートが定期的にアップされています。是非ご覧になってください。

またLINEでは、SETを絶賛募集中です。一緒にLINEプラットフォームのテスト自動化を進めてみたい！という方がいらっしゃいましたら、是非以下のフォームからご応募ください。

ソフトウェアエンジニアインテスト（Software Engineer in Test (SET))【LINEプラットフォーム】

皆さんの応募、心よりお待ちしております。

#Agile #QA #test