はじめに
今回の記事では、アジャイル開発手法を使ってLINE TODAYサービスを開発した経緯をご紹介します。LINE TODAYは、2016年初めに台湾、タイ、インドネシア、ミャンマー、米国でリリースしたモバイルニュースサービスで、2016年7月30日現在1日3千万ページビュー(Page View：PV)を記録しています。ちなみに、日本では独自のニュースサービスとしてLINE NEWSを展開しています。
LINE TODAY開発プロジェクトは、ユーザー、顧客、開発者、企画者が複数の国にまたがる多国籍プロジェクトです。多数の開発者、企画者、QAエンジニア、UITエンジニア、デザイナー、ビジネス担当者で構成され、メンバーは台湾、中国(大連)、韓国の3ヵ国のオフィスに分散していました。しかも、LINE TODAY開発プロジェクトチームは、新設されたばかりのチームでした。開発者のほとんどがLINEの開発環境と技術に慣れていない新米エンジニアで、プロダクトを開発する全体的なプロセスに詳しいメンバーもいませんでした。
また、このサービスは台湾、タイ、インドネシアなど複数の国でリリースする予定だったため、各国の様々な要望を考慮しなければなりませんでした。例えば、CP(Content Provider)によって希望するコンテンツフィードメカニズムが異なることを意識する必要がありました。台湾のCPはFTPを好み、タイとインドネシアのCPはRSSを好んでいました。
このプロジェクトはとてもタイトなスケジュールで進められました。LINE TODAYサービスは、FastTrack、RegularTrackの2回に分けてリリースされました。FastTrackではビジネスの収益性を評価するProof of Concept(概念実証)を行い、それを踏まえて継続的にサービスを運営するためにRegularTrackをリリースしました。FastTrackは設計、開発、テスト、リリースをたったの6週間で完了しなければいけませんでした。さらに、それから3ヵ月以内にRegularTrackをリリースすることが求められました。
唯一のソリューションは俊敏な対応、つまり「アジャイル」
スクラム(Scrum)は、複雑なプロジェクトに適したソリューションとして知られています。そのため、このプロジェクトにスクラムを採用し、以下の4原則を実践しました。
- チームスピリット(team spirit)
- 自己管理と自己啓発(self-management and self-development)
- コミュニケーション方法論
- 開発方法論
では、LINE TODAY開発プロジェクトでアジャイル開発プロセスとスクラムを適用した方法をご紹介します(理解を助けるために、スクラム用語は下線付きで表示しました。例: daily stand-up meeting)。
チームスピリット(Team Spirit)
真の「アジャイル」なチームになるには、強いチームスピリットが必要です。開発プロジェクトの主要な成功要因は、スクラムプラクティスを実行するうえで常にチームスピリットを持ち続けることです。
信頼と約束(Trust and Commitment)
スクラムマスターは、開発者同士、開発者と企画者、企画者とビジネス担当者間で信頼を構築できるように最善の努力注がなければなりません。そのため、開発者はスケジュールの算出と実行計画の策定に積極的に参加しました。マネジメントチームが一方的に意思決定を行うことはありませんでした。開発者は、自分で約束したスケジュールを守るために最善を尽くしました。開発者が約束した期限に合わせて作業を完了したことで、企画者は開発者を、そして主要担当者は企画者を信頼するという関係が構築されました。
方向性の提示：イノベーションとクリエイティブ
開発者がクリエイティブなアイデアを出せるようにイノベーションを奨励し、Pros/Cons分析を使って皆でアイデアを検討しました。このプロセスは、planning meetingで実行計画を議論し、タスクを分割するときに行われました。例えば、データベースのフレームワークを選択するときやデータのスキーマを決定するときに、開発者全員がPros/Cons分析に参加し、意見を出し合いました。
Why、What、How、When
まず、企画者は、planning meetingやbacklog groomingで「What To Do(やるべきこと)」と「Why To Do(やるべき理由)」を開発者に説明しました。ここで大事なのは、開発者がuser storyの重要性を理解することです。次に、開発者は、planning meetingで「How To Do(どうするべきか)」と「When To Do(いつまでするべきか)」を企画者に伝えました。開発者はそのuser storyの実装にどれくらいの時間が必要かを説明し(complexity estimation)、企画者はコストパフォーマンスを分析して優先順位を調整しました。最後に、企画者と開発者とが互いに合意した優先順位に基づき、開発者はそのスプリント内でどのuser storyを完了するかを伝え、実装方法を決めました(task breakdown：タスク分割)。
自己管理と自己啓発(self-management and self-development)
LINE TODAYチームにはすばらしいチームスピリットがあったため、チームリーダーは比較的容易に自己管理と自己啓発ができるスクラムチームを作り上げることができました。
Planning Meeting
Planning meetingは、通常planning meeting 1とplanning meeting 2の2段階に分かれます。Planning meeting 1の主な活動は、企画者がProduct backlogにあるuser storyとepicを開発者に説明することです。また、Planning meeting 2の主な活動は、開発者がuser storyを選択してタスクを分割することです。
LINE TODAYスクラムチームは、この1段階と2段階を明確に区分していませんでした。その代わり、キーコンセプト、つまり、企画者側で構想中のuser storyを開発者が早期に把握し、理解できるように努めました。また、開発者がその場で初めて聞いたuser storyをそのスプリントですぐに完了するように求めることはありませんでした。必要であれば「backlog grooming」ミーティングを開催し、企画者が大まかなuser storyやepicを詳細に説明する時間を設定しました。なお、企画者はdaily stand-up meetingにおいて、30分を超えない範囲内で細かいuser storyを説明しました。
User storyを実現するための活動には「King and Servant」モデルを活用しました。一人の開発者がそのスプリントでkingの役割を担当してuser storyを選択し、on-time-deliveryや品質、blockerの除去など、すべて責任を取りました。他の開発者はservantとしてkingをサポートしてuser storyを完了しました。
Daily Stand-up Meeting
Daily stand-up meetingは、約15分から30分かけて各自の進捗状況を共有する時間です。
スクラムマスターは、daily stand-up meetingで非常に重要な役割を担っています。メンバーの進捗状況を共有するだけでなく、チームの運営モデルを策定し、関係を構築しなければなりません。このような役割は、新規のスクラムチームにとって特に重要です。新しいチームは協力する方法を自ら模索し、成熟させていく必要があります。リーダーは、トップダウンで命令を下す司令官ではなく、提案とアドバイスをしてメンバーが自力で運営モデルを確立できるようにサポートするのが役割です。約２ヵ月ほど経過したら、LINE TODAYスクラムチームは、チームワークを発揮して開発に取り組む自主的な組織へと成長しました。
Live Demo
企画者と主な担当者にこれまでの作業の成果を説明するのは重要なことです。そのため、スプリントが終了する度にlive demoを行いました。通常、live demoではユーザーの観点からuser storyを説明します。しかし、私たち開発者は、live demoでAPIまたはテスト自動化といったエンジニアリングタスクに関するuser storyを説明しました。User storyのkingの役割を担当している開発者は、live demoを通じてソフトウェアデザインを説明し、単体テスト(unit test)とスモークテスト(smoke test)を実施、性能指標を提示するなど、本人の成果を紹介するようにしました。
この活動は、開発者のスキルと実力の向上のために重要です。また、企画者や他の担当者が当初の予想より開発にもっと時間が必要な理由を理解できるので、企画者と開発者間の信頼構築にも役立ちました。
Retrospective
Retrospectiveは、自己管理と自己啓発が可能なチームを作るための重要な活動です。各メンバーはretrospectiveによって主な改善点を把握しました。目標は、すべての問題点を是正することではなく、毎日少しずつ地道に改善していくことでした。
初期の数回のスプリントを実行する間、チームはcoding convention、code branch/merge、CIなど共同開発(co-development)プロセスの改善に焦点を当てました。これはすべて、LINE TODAYスクラムチームが成熟したシステム開発モデルを構築するために欠かせない改善事項でした。
また、retrospectiveでは一つ興味深い活動をしました。各メンバーに全員の前で良かった点と改善すべき点、感謝したい人について語ってもらいました。そして最後はスクラムマスターの主導の下で、次のスプリントで取り組むべき主な改善点を1~2つほど決めました。スクラムマスターは、daily stand-up meetingにおいて改善点を継続的にリマインドし、次回のretrospectiveにてその結果を検討しました。
コミュニケーション方法論
内部(Inner)コミュニケーションと外部(Outer)コミュニケーション
コミュニケーションの効率化を図るために、二つのチャネルを作りました。内部(Inner)コミュニケーションと外部(Outer)コミュニケーションがそれです。内部コミュニケーションとしては、プロダクトの要件を提供する際に、台湾の企画者が韓国の企画者の要件もまとめて渡す単一窓口の役割を果たしました。そして外部コミュニケーションとしては、台湾の企画者が韓国の企画者や韓国のプロジェクトマネージャー、各国の事業部の担当者とコミュニケーションを行いました。
Product Backlog, Epic, User Story, Task
メンバー全員が開発タスクと進捗状況を共有できるようにJIRAスクラムボードを導入しました。LINE TODAYスクラムチームは、企画者やプロジェクトマネージャーまたは開発者の観点からuser storyを一目で把握できるように「Product Features」というタイトルの特別なepicを作りました。そしてそのepicを1-tier epicと2-tier epicで管理しました。また、企画者やマネジメントチームが全体のバックログを見て進捗状況を把握しやすくするために、Product Featuresのuser storyに関連するuser storyやタスクに対する依存関係(dependency)を設定しました。これで、開発者や企画者、関連の担当者全員はプロダクトのバックログをより簡単に確認できるようになりました。
User storyを「single source of truth」で管理するために、以下のとおりルールを定めました。
- 企画者は、user storyチケットに詳細な要件を記載するか、要件のリンクを張る。そうすることで、他の人が要件を迅速かつ簡単に探すことができるようになる。
- 開発者は、user storyのタスクチケットにコードのコミットログのリンクを張る。そうすることで、他の開発者やQAがそのタスクを実行した人を把握できるようになる。
- すべての要件変更は、user storyチケットへエスカレートする。そうすることで、変更履歴(change history)を追跡できるようになる。
このようなルールを適用したことで、企画者が予期せず要件変更を作成する場合など、企画者と開発者との間で発生する慢性的なコミュニケーションミスを減らすことができました。
普段のコミュニケーションツール
普段のコミュニケーションにはLINEメッセンジャー、HipChat、ビデオカンファレンスを使用しました。どのツールを使用するとしても、最も効果的な手段は「直接会って話すこと」です。そのため、開発者が作業中に疑問が生じたときには、企画者や担当者に直接会って話し合うことを推奨しました。
開発方法論
真のアジャイルチームになるためには、チームスピリットのみならず、どの開発方法論を導入するかも大事です。
リソースの再利用
LINEは、グローバルプラットフォームと共有ソリューションを活用しているグローバルカンパニーです。そのため、複数の拠点に構築されているTimeline Content API、OBS、CDNなどの既存のリソースを積極的に導入しました。既存のプラットフォームやツールを再利用すれば、開発工数を削減でき、より確実にtime-to-marketに対応することができます。
実際、OBS/CDNの導入は、高性能を維持しつつ、単一のサーバファームで5ヵ国にLINE TODAYサービスを提供するために欠かせないことです。CDNのDynamic Site Acceleratorは、ユーザーコメントをAPIサーバのキャッシュメカニズムで処理し、動的コンテンツモジュールを効率的に運営できるようにサポートします。
CI(Continuous Integration)とCD(Continuous Delivery)
CI/CDは、今日のほとんどのインターネット企業が活用するソフトウェアエンジニアリング手法となっています。ここではCI/CDに関する説明は割愛し、このプロジェクトに有効活用できた事例を紹介します。
Pre-commit/commit buildで単体テストとcoding conventionを適用することは、開発の品質確保のためにとても重要です。特に共同開発を行うためには、強力な単体テストフレームワークの構築は必須です。
コードレビューは、品質管理のみならず、チームワークと人材開発にも貢献します。LINE TODAYプロジェクトチームは、上述のKing and Servantモデルを基にGit FlowとPRレビューの段階を直接作りました。特定の分野に詳しい開発者がkingの役割を担当し、他の開発者のスキル向上をサポートしました。そのため、すべての開発者がコードレビューで習得した内容(lessons learned)を熟知することができました。
テスト自動化(Test Automation)
LINE TODAYプロジェクトチームには、テスト自動化を専門に担当する台湾のQAが2人いました。また大連には、手動テストを専門に担当するQAタスクフォースも設置されていました。目標は、すべてのテストを自動化することでした。テスト自動化は相当なコストがかかりますが、それだけの価値があります。
RegularTrackの段階から徐々にテスト自動化を構築していきました。QAエンジニアはlive demo時にテスト自動化をビジュアライズして紹介し、得られるメリットと回避できるリスクについて説明しました。Retrospectiveでは、開発者からもフィードバックがあり、テスト自動化がどのように役立ったかを説明しました。
ExtensibilityおよびScalability
チームでは、開発者がextensibility(機能の拡張性)とscalability(規模の拡張性)の観点からシステム設計を議論することを積極的に促しました。
今日のシステム設計は、extensibilityとscalabilityのためにクラウドソリューションを導入する傾向が強まっています。私たちもこのような流れに乗ってMongoDB、Crawler4j、gclusterfs、Redis、RabbitMQ、ElasticSearchなどのクラウドベースのソリューションを使用しています。システムを設計し、新しい技術を模索・習得するには多くの時間がかかりますが、それでも開発者全員にそのような取り組みを推奨しています。まず、開発者がsizing(規模測定)して性能指標の数値を予測し、続いてQAや開発者がモニタリング環境を構築し、ベータ版と本番サイトでその数値を測定しました。なお、sizingの結果を共有して協議するミーティングを開催し、その設計がどのように、そしてなぜextensibilityとscalabilityを満たしているのかを検討しました。
LINE TODAY - Popular Articles feature
続いて、LINE TODAYサービスの主要機能の一つであるPopular Articlesをご紹介します。
LINE TODAYサービスのホームページでは、記事をカテゴリ別に分けて提供しています。現地のニュース編集者が掲載した記事のみならず、閲覧数の多い人気記事を素早く確認できる「スマートモジュール」をこのページに追加しました。
この機能を実現するためには、様々な技術的な難題を解決しなければなりませんでした。
- リアルタイム更新(応答性): 記事を読んだり、コメントを付けたりするなどのユーザーアクションをリアルタイムで収集・分析し、人気記事リストを動的に更新します。
- 柔軟性: 生データを取得したり、ユーザーアクションを処理したり、記事コンテンツを構成したりするなどの全体的なTrendingメカニズムは包括的でないといけません。多くの労力と時間をかけなくても人気記事を選別するロジックを柔軟に変更でき、モジュールを更新できることが求められます。
- 拡張性と安定性(Scalability and Robustness): 人気記事リストを作成するには、複数のサービスコンポーネントにおいて大量のユーザーアクションを処理しないといけません。現在のところ、ユーザーアクションの量は毎日約3千万ビューに達しています。このような膨大な量のトラフィックを処理するには、安定的で拡張性に優れたシステムが必要です。
全体的なアーキテクチャは以下のように設計されています。
Web API サーバは、ユーザーアクションを収集する主要コンポーネントです。データをリアルタイムで収集しながらWeb APIサーバで発生するオーバーヘッドを減らせるように、データを一時ストレージキューに保存します。
RabbitMQは、大容量処理が可能で複数レベルでのデータ永続性を保証するため、このサービスに適した候補であるといえます。Trendingサーバは、ユーザーアクションログを処理し、収集されたログを基にリアルタイムで人気記事リストを作成します。
人気記事を選別するロジックを柔軟に構築するために、ユーザーアクションのデータを所定のルールに沿って事前集約(pre-aggregation)せず、生データのまま保存します。人気記事リストの作成は、検索エンジンでクエリを実行して処理します。
Elasticsearchは、リアルタイムでデータを分析する強力なフレームワークです。人気記事リストの作成に必要な要件を満たすために、フィルタークエリと一般的なバケット集約(bucket aggregation)を結合しました。
なお、スクリプトによる集約(scripted aggregation)でクエリを拡張することで、より複雑なケースも処理できるようにしました。Bulk APIは効率的で柔軟なクエリの使用をサポートするだけでなく、ユーザーデータを挿入する際にインデキシングの速度を向上させます。
Trending関連のコンポーネントが全部揃ったら、Trendingサーバはバックグラウンドでごく短い間隔でクエリコマンドを実行し、その結果をRedisにキャッシュします。そうすると、WebサーバのWebページ作成モジュールが最新の人気記事リストを取得します。
台湾、タイ、インドネシアをはじめ、世界中にニュース記事を展開する際にかかる読み込み時間をできるだけ短くするために、記事コンテンツをCDNにキャッシュします。そして、ブラウザが最寄のエッジ(edge)サーバからそのコンテンツを取得するようにしてダウンロード時間を短縮します。
このように、複数のコンポーネントが共に一連の作業を行うことで人気記事を取得します。しかし、テスト段階ではより困難な問題が発生します。ユーザーアクションログの量があまりにも膨大なので、そこにユーザーアクションのシーケンスまで追加されると変動性は非常に大きくなってしまいます。そのため、機能を手動でテストして検証することはほぼ不可能です。
まず、複数レベルでの単体テストを行い、各サービスのコンポーネントを検証します。その後、QAチームは、自動的に実行される統合テストスクリプトを使用してユーザーアクションをシミュレーションし、Trendingサーバで多様なユーザーアクションを組み合わせて作成した人気記事リストを検証します。テストスクリプトはJenkinsで実行され、予想外のアウトプットが出た場合は通知メールを送信します。
モニタリング環境を構築して本番の運営環境にリリースする前に、各サービスコンポーネントが正しく動作するのかをチェックします。LINEはiMON、nSightなどの様々な社内ツールを使用しています。このようなツールは、システムレベルからアプリケーションレベルまで全体的にモニタリングし、通知を送ります。RabbitMQとElasticsearchは、Webモニタリングインターフェースによって大量のサービス統計データを提供します。このようにすれば、必要な度に状態をチェックできるのでとても便利です。しかし、問題を防止するためにはより積極的なアプローチが必要です。Health checkスクリプトは特定のサービスが一定の限界値を超えると通知を送ります。このスクリプトには、RabitMQ management APIとElasticsearch cluster/stats/status APIが統合されています。キューのサイズが増加し続けたり、クラスタが停止したりするなどの異常な状況を簡単に検知できます。
終わりに
以上のように、LINE TODAYプロジェクトチームが真のアジャイルをどのように実践しているかについて、チームスピリット、プロセス、フロー、ツール、方法論などの様々な観点からご紹介しました。私たちはアジャイルを実務に適用し、真のアジャイル開発がもたらすメリットを証明しました。チームスピリットが最も重要であることをもう一度強調したいと思います。これがすべての始まりであり、チームを同じ方向に引っ張っていくエンジンであるからです。開発者と企画者が一丸となってチームスピリットを発揮し、解決策を見出だすために努力しました。これは、素晴らしいソフトウェアエンジニアリング手法が確立されていたからこそ可能だったことでした。このような取り組みに支えられ、品質保証はもちろん、迅速なリリースをも実現することができました。
作成者の紹介
Marco Chen: ディレクター。LINE TODAYプロジェクトの開発リーダー兼スクラムマスターとして、スクラムチームを編成し、プロセスや連携モデルを構築しました。
Yang Ya-Chu: シニアサーバサイドエンジニア。LINE TODAYでTrending Serviceシステムの設計を担当しています。