AbemaTV、サイバーエージェントの講演から探る、アジャイル開発成功の鍵と炎上しないための教訓：DevOps時代のテスト自動化カンファレンス（前編）（1/2 ページ）

“いいもの”を、より早く形にして市場に届ける際に欠かせないのが「テスト」だ。DevOpsやアジャイルといった開発スタイルの中で適切に、かつ効率よくテストを実施する秘訣とは何だろうか？ ＠IT編集部が主催した「DevOps時代のテスト自動化カンファレンス〜はやく、いいものを届けよう〜」の講演から、そのヒントを紹介する。

[高橋睦美，＠IT]

　市場ニーズを素早く形にし、「ビジネスの成果を獲得するまでのリードタイムを短縮する」上で重要な手法となる「アジャイル開発」や「DevOps」だが、これらの取り組みにおいて「テスト」というプロセスをどう組み込むかが「いいもの」を作れるかどうかの大きな分かれ目となる。管理すべきコード、テストすべきコードが増加する中で必要十分なテストを実施し、開発サイクルを素早く回す鍵として注目されているのが自動化だ。2016年12月6日に東京で開催されたセミナー「DevOps時代のテスト自動化カンファレンス〜はやく、いいものを届けよう〜」の講演を基に、そのエッセンスを探っていこう。

　講演内容は、3回の連載で紹介していく。初回は、AbemaTV／サイバーエージェント、日本シノプシス、丸紅情報システムズの講演だ。

「アジャイルありき」ではなく、目の前の課題をこなすこと

　冒頭の基調講演には、DevOpsの実践を通して次々と新しいサービスを生み出しているAbemaTV（アベマティーヴィー）のエンジニア、大崎浩崇氏と、サイバーエージェントのエンジニア／マネージャーを務める板敷康洋氏が、それぞれの体験に基づいて、テストも含めた「DevOps」「アジャイル開発」実践のポイントを紹介した。

バックログ（タスク）とコミュニケーション

　フロントエンド端末の多様化とバックエンドのインフラの汎用化が進む中、近年のWebサービス開発には、徹底したPDCAが求められると大崎氏は述べる。2016年4月にスタートしたインターネットテレビ局「AbemaTV」ももちろん例外ではなく、「仮説を立て、離脱率をはじめとするKPIを見ながら継続的に改善、修正し、すぐにリリースすることが必要だ」（大崎氏）

　AbemaTVでは、このミッションをスクラム開発における「バックログ」（タスク）単位でアサインし、管理している。だが、その中で「バックログにある“やりたいこと”がきちんとエンジニアに伝わっているか、実装に関する共通認識が得られているかといったコミュニケーションの問題が出てくる。そこを解決しなくてはいけない」と大崎氏は述べた。

バックログ（タスク）の流れの例（大崎氏の講演資料から引用）

　そのバックログ管理のため、AbemaTVが活用しているツールが「JIRA Software」だ。「リリースバージョンの管理に始まり、スプリントごとに実施したいバックログのまとめ、見積もりと担当の割り当て、各バックログの着手状況も管理し、テストチームが確認したらリリースしていく」という流れだ。一方、仕様については「Confluence」と「esa」を活用し、「仕様がコロコロ変わることを前提に、変更があれば『Slack』で共有している」（大崎氏）という。

　「Slackは、いまやAbemaTVの開発に必要不可欠になっている。例えば、UIデザインの変更案をどんどんSlackにアップし、それを見て皆でいろいろ指摘し、『これで行きましょう』と仕様を詰めていくことができる。Slackの良いところはコミュニケーションのスピードがとにかく速いこと。ミーティングの場を用意することなくすぐ確認できるし、手戻りも少なく、ログも残る。困ったら取りあえずSlackに投げればいいので、心理的障壁も低い」（大崎氏）

　このようにチーム“内”のコミュニケーションについては、Slackをはじめとするツールを活用しつつ、コードレビューや勉強会を通じて意思疎通を図っているというが、各チーム“間”のコミュニケーションに関してはどうだろうか。「チームが分かれると、どうしてもコミュニケーションが減ってしまう」と大崎氏。そこで、複数のチームに関連し、数カ月単位の時間がかかるような新機能追加の際には、横串でチームにまたがる「プロジェクトチーム」を作って管理するそうだ。もう1つ、「飲み会」も解決策だという。

アジャイル開発をうまく行うには

AbemaTV エンジニア 大崎浩崇氏

　最後に大崎氏は「よく『アジャイル開発をうまく行うには、どうしたらいいだろうか』と聞かれるが、細かいことの積み重ねしかない」と述べた。今うまくいっているやり方や企業文化をいきなり変えるのは、反発を招きかねず難しい。今の開発が抱えている問題点を洗い出した上で、効果が目に見えて分かりやすいツールを導入するといった具合に、できるところから少しずつ手を付けることが肝要だという。

　「サイバーエージェントも、自分が入社した5年前はアジャイルではなかった。同時に多数のサービスを立ち上げ、現場も混乱している中で、アジャイルやスクラムといった活動に取り組み始めたエンジニアがいた。うまくいかない中で、生き残るために新しい挑戦をしていった結果が、自然とアジャイルになった。アジャイルありきではなく、“目の前の課題を、きちんとこなしていく”ことをターゲットに据えてやっていくのが近道だ」（大崎氏）

• 関連記事：マイクロサービスベースのAbemaTV開発プロジェクトが切り開くスクラムとプロジェクト管理の“新境地”

3つの炎上案件からの教訓――問題の本質を捉え、解決すべし

　続いて、フリーランスのエンジニアとして活躍した後、2013年からサイバーエージェントに加わっている板敷氏が、過去の「炎上案件」から得られた貴重な教訓を紹介した。

【1】テストだけで品質を担保しようとして、うまくいかなかった

サイバーエージェント エンジニア／マネージャー 板敷康洋氏

　1つ目の炎上案件は「テストだけで品質を担保しようとして、うまくいかなかったケース」だ。あるところに、バグだらけのソーシャルゲームがあった。なぜバグだらけなのかを探っていくと、「テスト環境と本番環境でデータが違う」「異常系テストの未実施」「結合テスト未実施」といったテストにまつわる問題が続々と明らかになった。

　通常ならば、ここで「テストを徹底する」が再発防止策として挙がるところだ。しかし板敷氏は「『テスト頑張ります！』では防げない。そもそもテスト漏れが起こりやすい要因があったのではないか」と指摘。バグを減らすためにテストの質や量だけに注目するのではなく、「いかにテストしやすいか、管理しやすいかを、システム設計段階から考えることが大事だ。そのために、テスト担当者だけではなく、開発者や実装者、運用者それぞれがテスタビリティを意識して開発を進めることが重要だ」と述べた。

　またこの過程で「自動化」「フロー化」に着目するケースが多いが、「テスタビリティを向上させるための切り口として設計や環境、開発プロセス、コミュニケーションがあり、そのために自動化やフロー化がある。自動化が先にあってはいけない」と釘を刺した。

【2】権力者の介入によって仕様に“ずれ”が発生してしまう

　2つ目の炎上案件は「権力者の介入によって仕様に“ずれ”が発生してしまうケース」だ。「権力者」というと語弊があるが、実績があり、社内でも一目置かれているようなチーフプロデューサーが、開発チームのリーダーであるプロデューサーを通さず、現場に直接修正指示を出してくることがあった。その結果、プロデューサーの知らないところで修正が行われ、モバイルアプリの実装においてAndroid版とiOS版とで実装に“ずれ”が生じる事態になってしまったという。

チーフプロデューサーが介入してくる風景（板敷氏の講演資料から引用）

　解決策として板敷氏は「仕様伝達フローを整備し、開発窓口をプロデューサーに集約するとともに、定期的にチーフプロデューサーと対話する機会を設け、その場にプロデューサーも同席することにした。介入の場を意図的に作ることで、影響を最小化するという狙いだ。権力者というのは“実績がある人”。そういう人とうまく付き合い、ノウハウをもらいながら、現場の混乱を招かないような仕組みで解決した」と述べた。

【3】100万同時接続に耐えられるようにシステムのキャパシティを増強する

　最後の炎上案件は、板敷氏自身が火中に投じられたケースだ。テレビコマーシャルによる大規模プロモーションの直前に、その時点で高負荷に耐えられず何度も落ちているシステムのキャパシティを増強するよう求められたという。当初示された目標は「100万同時接続に耐えられるもの」というとてつもないスペックだった。

　板敷氏はここで、無理なゴールに向かってやみくもにダッシュはしなかった。代わりに、「大型プロモーションに耐えられるシステムにする」という根本的な目標に立ち返って冷静に現在のアクセス傾向・推移を分析し、同時にサービス全体のアーキテクチャを検証。その結果、「100万同時接続は過剰要件。現実的に最大と考えられる30万同時接続に耐えられる性能を目指し、それ以外は耐障害性、可用性の問題を解消するために回す」と、プロジェクトゴールを再設定する決断を下した。

　「ゴールが降ってきた場合でも、まずはそのゴールが適切かどうかを確認すべき。全体を俯瞰し、目的に立ち返って、満たすべき技術的要件を確認することが大切だ。炎上していたり、組織が盛り上がっていたりするときほど、現場は冷静さを失ってはいけない」と板敷氏は述べ、こうした過去の経験に学んで、炎上プロジェクトの解決に役立ててほしいとした。