はじめに

こんにちは！8月21日から9月29日までの6週間、LINE株式会社でサーバーサイドエンジニアとしてインターンシップをさせていただきました栗本龍一と申します。
普段は大学でComputer Scienceを学んでいるほか、個人事業主としてWEBアプリケーションの開発を行っています。

今回のインターンシップではNEWSサービス開発チームに所属し、記事を見た人のデモグラフィックデータ（人口統計学的データ）を可視化する機能の実装に取り組みました。
この記事では、LINE NEWSで企画や要望がどのようにして実現されるかについてや、NEWSサービス開発チームで実践されているアジャイル開発、特にスクラムでの開発について、自身の実装時の体験をもとにお話したいと思います。

背景

LINE NEWSでは現在1,100を超えるメディアと提携をし、記事をユーザーひとり一人にパーソナライズして配信しています(2022年1月時点)。

一方で記事を配信しているメディアは、自身をフォローしているユーザーのデモグラフィックデータは確認できるものの、各配信記事を見た人のデモグラフィックデータを確認することはできませんでした。
この機能はメディア・LINE NEWS双方から要望されており、もし実装されれば以下のようなメリットがあるため、機能追加を行うこととしました。

仕様策定

機能を追加する際、最も重要なプロセスの一つが仕様策定です。ウォーターフォール型開発では、実装前にすべての仕様が決定され、その仕様通りに段階的にプロジェクトを進行して行きます。そのため根本の仕様が変更される場合、すでに完了しているステージでも修正作業を行う必要があります。しかし、これから開発するプロジェクトの全容を開発する前に完全に把握することは難しく、メンターの齋藤さんもよく「登らない滝は無い」と仰っているほど、後の工程になっての仕様変更は多々あることだそうです。

図1 ウォーターフォール開発の流れ

アジャイル開発では仕様策定は柔軟性を持ったプロセスとして位置づけられています。アジャイル開発で目指すべき方向性は、小さく作ったものを積み上げて大きなものを作ることです。初めからすべての仕様を策定するのではなく、大まかな方向性を設定した後、実際に開発をしながら詳細を詰めていき、変更や改善を繰り返していきます。そのため、実際に開発をしていく中でより良いアイデアが浮かんだ場合、仕様を変更して採用することがよくあります。そうして当初の仕様から変更が積み上げられた場合、最新の仕様がどういった状況なのか分からなくなることが想定されます。LINEではそういった事を防ぐため、各プロジェクト毎にバージョン管理可能なWikiを用意しており、最新の仕様や変更の履歴などがすぐに確認できるようになっています。

図2 アジャイル開発でのイテレーション

仕様策定では、まずどのような機能が求められているのか、どのようなデータを使用する必要があるのか、またそのデータはどのように表示されるのかなど、機能の詳細について決めていきます。LINE NEWSで配信している記事は1日平均10,000件以上(2022年3月時点)あり、また月間利用者数が7,700万人(2021年8月時点)と、多数のユーザーの方にご利用いただいております。理想では全記事の全期間のデモグラフィックデータについて確認できると良いですが、パフォーマンスやデータ使用量を考えると非常に難しい事が容易に想像できます。そのため、対象となるユーザーや記事についてはある程度の条件を設けて、条件を満たした場合についてのみデモグラフィックデータを集めて表示することにしました。

NEWSの特性として、配信された記事はユーザーに速やかに届き、ユーザーも受け取ったニュースをすぐに閲覧する傾向にあります。自身の経験からしてみても、日数がたった記事について閲覧したことはあまりなかったように思います。このような特性を踏まえ、どれくらいの期間を設定すれば有意なデータが得られるか検討しました。そこで配信後何日間で閲覧数の増加が収束するかについて調査した所、配信後数日間に記事閲覧が集中していることが分かりました。したがって、分析の対象期間としては配信後数日間のデータを中心に考えることとしました。また、閲覧数が多かった記事は1週間後ランキング配信といった形で再度配信されるということを知り、ランキングとして配信された記事についても閲覧数の増加が予想されることから、こちらも考慮に入れることにしました。

データの取得期間を決定した後、次なる課題はデータの保存期間についてでした。今回の機能では各記事ごとに閲覧した人のデモグラ情報を集約するため、1日に数千レコードの追加とその約10倍のレコードの更新が必要となります。いくら高性能なデータベースサーバーを利用しているとはいえ無尽蔵にリソースを食い尽くして良いわけでは有りません。これを踏まえてデータの保存期間を決定し、それ以上経過したデータについてはバッチ処理で削除する方針としました。さらに、過去のデータと合わせて分析したい場合が考えられるため、メディアがいつでもデータを利用できるようにCSV形式でのダウンロード機能も提供することにしました。これにより長期的な分析やアーカイブのニーズにも柔軟に対応し、データの利便性と保存効率の双方を満たすことができます。

図3 NEWS配信時の閲覧者数の増減グラフ（実際のデータとは異なります）

次に、データの可視化方法について検討しました。CSVでのRAWデータ形式に加えて、グラフによる表示はデータの傾向や変動を人目で把握しやすく、特に今回のようなデモグラフィックデータを扱う場合に特に有効です。一方テーブル形式の表示は、具体的な数値や情報を知ることができるため、特定のデータを詳しく知りたい場合に有効です。今回の機能追加ではこの3つの方法を組み合わせることで、大局的な視点での分析と細かなデータの確認の両方を効率的に行うことができるようにしました。

図4 グラフ表示イメージ

グラフは直感的に分かりやすいものの、細かいデータの確認は難しい

図5 テーブル表示イメージ

テーブルは詳細なデータまで確認できるが、画面に占めるサイズが大きく比較がし辛い

開発プロセス

設計

アジャイル開発では、仕様策定と設計を同時に進めます。設計と言っても分厚い設計書を書くのではなく、1つの開発単位で実装することに焦点を当てて書いていきます。また、機能のインターフェースだけでなく、その背後にある目的、アーキテクチャ、データフローなどに関する情報も含めて記載するため、いわゆる「Design Document」に近いものであると感じました。アジャイル開発の特性上、開発途中で仕様が変わる可能性があるため、この設計も静的なものでは有りません。仕様の変更や実装上の発見に応じて設計内容も変わるため、柔軟に管理更新ができるよう、バージョン管理機能を備えたWikiに記述します。そうすることで変更の履歴をすぐに確認することができ、チーム全体での共有を容易にしています。このアプローチによって、例えば私のような新たに参加した者が他の実装部分について知る必要がある際に、他のメンバーに何度も質問する必要が減少し、さまざまな文書やトーク履歴を時間をかけて遡るような事を防いでいると感じました。このようなシームレスな情報共有は、アジャイル開発の柔軟性向上に大きく寄与しています。

最終的に今回実装する機能のアーキテクチャは以下のようなものとなりました。

図6 デモグラフィックデータ可視化実装のアーキテクチャイメージ

実装

つづいて実装のフェーズに入ります。NEWSサービス開発チームではアジャイル開発のスタイルの中でもスクラムを取り入れています。スクラムとは、「スプリント」と呼ばれる開発の期間を設け、その期間内で完了できるタスクを決定して作業を行い、終了時に成果物を生み出し、振り返りを行うという手法です。

図7 スクラムをベースとしたアジャイル開発の概要 出典:内閣官房情報通信技術（IT）総合戦略室（2021）

スクラムの代表的な要素として以下のものが挙げられます。

• バックログ
  • チーム全体のプロジェクトがリスト化され優先度順に並んだものです
• プランニング
  • そのスプリントでこなすバックログを決定したり、バックログを分解してタスク化し開発者が行うべきことを明確化します
• デイリースクラム
  • 毎日行われる短いミーティングで、今日の進捗、今後の予定、不明点や問題点等につていて共有します
• スプリントレビュー
  • スプリントの終わりに行うミーティングで、そのスプリントで生み出した成果物を確認し、ステークホルダーのフィードバックを得ます
• レトロスペクティブ
  • スプリントの終わりに行うミーティングで、そのスプリントを振り返り、次のスプリントで改善できることなどについて議論します

上記を見ると分かる通り、スクラムではフィードバックを受ける機会がたくさんあります。これにより成果物の品質向上、不具合や認識齟齬の早期発見、個人が抱えている問題の早期解決、チーム連帯感の醸成といったメリットを得られます。私は今回始めてアジャイル・スクラム開発を体験しましたが、特に毎日行われるデイリースクラムは私にとって非常に重要でした。ただのタスクの進捗を報告する場所としてではなく、困っていることや不明点を相談できる場としても機能していたからです。慣れていない私にとって、毎日相談ができる場があるのは本当に心強く感じました。また、細かく目標を設定し、それを現実的な時間や量に調整できるという点も良いと感じました。この柔軟性により、無理のない範囲でプロダクトを進化させ続けられるのだと思います。

一方、私がスクラムを通じて特に難しく感じた点は、自分の能力や進捗を客観的に捉え、設定した目標を達成することの難しさでした。実際に作業を進めてみると、私が当初想定していたよりも数多くの要素を考慮し、実装しなければならない事がわかりました。また、慣れていないがゆえミスが発生するなど、計画どおりに進まないこともしばしばでした。しかし、アジャイル・スクラム開発では稼働や個人の能力に依存せず、開発を進めることができます。その理由が「短期間でリリースサイクルを回す」という戦略にあります。ウォーターフォール開発では成果物はすべてが完成されたときリリースされます。つまり未完成ではリリースできない、成果物を提供できないことになります。対して定期的にリリースを行うアジャイル・スクラム開発では、どの機能をいつのリリースで行うか調整することができます。作業の優先度を決め、どこまで作るかを制御することで、リリース品質の向上や、リソースに合った開発が実現できます。また、スクラムでは情報共有を頻繁に行うため、開発リソースをコントロールすることができ、より人に依存しない安定的なリリースを行うことができます。機能を使う視点で考えてみても、早くから成果物をイメージすることができ、実際に使用できるまでが短期間で、リリースされてからもフィードバックを行うことができるため、より満足度の高いものが得られます。開発側、使用者側双方にとってメリットが大きい開発スタイルだと感じました。

テスト

実装が完了した後はレビューが行われます。レビューにはいくつか種類があり、私が経験したレビューは主にスプリントレビューとコードレビューでした。スプリントレビューは、実際の成果物の方向性を確認する場であるとともに、ステークホルダーと開発チームの認識をすり合わせる場でもあります。アジャイル開発の目的として「いち早く形作ることでいち早くフィードバックを得る」事が挙げられます。形作ることで、お互いの認識を物ベースで合わせることができ、実際に触ってもらうことで、より具体的なフィードバックを引き出すことができます。実際にデモグラフィックデータを可視化するフロントエンドのレビューをしていただいた際には、自分では気づかなかったデザインのズレや文言のミス、レイアウトの違いなどを具体的な場所をベースに指摘いただけるので、原因や修正箇所の特定が非常に容易でした。スクラムでは各スプリントごとにレビューを行うことで、事前に見つけられるミスや不具合を構造的に減らしています。

コードレビューは、文字通りコードに焦点を当てたレビューで、コードの構造や変数の命名など、細部に渡る品質をチェックする場となります。レビュアーが見やすいようにコミットを整理するのは難しく感じましたが、受けた指摘からたくさんのことを学べました。またNEWSサービス開発チームでは2名以上の方にレビューしていただく必要があり、様々な視点からレビューしていただけるので、より幅広い学びになりました。

実装後ステージング環境にアップされると、今度はQAさんが動作の確認をします。私はこのときものすごい数のバグを指摘していただきました。このときにQAさんのありがたみを痛いほど実感しました。というのも、特に実装終盤は、時間的制約からミスを見落としてしまったり、アジャイルな開発スタイルの都合上仕様について確認ができていなかったり詰めきれていない部分が存在します。そういったミスやバグを、利用されるユーザーの方々へ届ける前にキャッチしてくれる役割は、非常に重要だと考えています。品質を保つことは、サービスとしての信頼性を保証する上で必要不可欠であり、それを実現するのは本当に大変な作業だと感じました。更に、QAの方々がスクラムチームの一員として組み込まれている組織の素晴らしさを体感しました。そのおかげで迅速なフィードバックを受け取り、より質の高いサービスを提供することができるのだと実感しました。

リリース

このような「企画→設計→実装→テスト」のサイクルを経て、サービスがリリースされます。

使用技術

今回の機能追加では様々なデータを取得する必要がありました。これらはIUと呼ばれるデータプラットフォームに存在します。IUはHadoopをベースとしたデータ分析基盤で、LINEにおけるさまざまなサービスからのデータが蓄積されています。すべてのデータが蓄積されているということは当然データ容量も大きいわけで、そのサイズは現在300PBほどあるそうです。そういった分散システム上での実際のデータを取り扱うことは非常に新鮮でした。膨大なデータ量に圧倒され、パーティションを適切に設定しないとデータ処理に多くの時間がかかってしまうことを実感しました。

また、実際にクエリやバッチ処理を行う部分はHiveを用いて実装しました。HiveはSQLライクなクエリ言語を用いたクエリエンジンで、内部的にはコンパイラがクエリをMapReduceに変換し、それをHadoopに渡しています。Hiveの一番の特徴は結果をストレージに書き出すことで、これにより障害発生時にストレージにある中間結果を用いて再度ジョブを実行できることから、データ処理の安定性が高いということです。ただしその性質にはデメリットもあり、他のクエリエンジン、特にメモリ上に結果を書き出すものと比べてストレージI/Oが入る分段違いに遅いということです。非効率なクエリを実行してしまうと平気でランチに行けるくらいの時間がかかることに驚きました（笑）。中間的なデータのサイズをなるべく小さく保つことや条件分岐を行う箇所に気をつけることなど、学んだことはたくさんあり、これは分散システムだけでなく、普段RDBでクエリを実行する際にも役立つ知識であると感じました。

また、NEWSサービス開発チームではドメイン駆動設計(domain-driven design, DDD)の考え方を取り入れています。DDDではドメインとそのロジックを考えることから始まります。実装でもドメインがやることできることを定義し、それをドメインサービスから呼び出すことで、ドメインに対する一連の手続きを表現します。そしてそれを様々なアプリケーションから呼び出すことで、その機能を使用できるという形になります。DDDの良い点は複雑なビジネスロジックをモデル化しやすくなるということだと考えています。これを実感したのは、自身が実装中に他の実装について参考にするときです。実装中に分からなくなったことについて、DDDの構造のおかげで、関連した概念を簡単に参照することができました。例えば、アプリケーションサービス実装時に分からない事があった場合、似たアプリケーションサービスの動作や記述を参考にすることで、疑問を解消することができました。このようにドメインが整理され、各レイヤーが分離できているアプリケーションは様々な実装が参照しやすく、また参照しやすいということは改修しやすいということでもあるので、特に大規模サービスでのアジャイル開発に適していると感じました。今後自身のソフトウェア開発でも積極的に取り入れたいと考えています。

感想

今回のインターンシップでは、6週間実際のチームに配属され、サービスの開発を行いました。まず驚いたことは、プロジェクトの進むスピードの速さです。様々なプロジェクトが同時並行に進行しており、また複数のプロジェクトを横断して関わっている方もたくさんいらっしゃるため、単体でも全体でも非常にスピード感の高い開発現場であると感じました。特に、たくさんプロジェクトを抱えているのにその全てに詳しい方も多くいて、私は分身の術の研修があるのではないかと疑っています（笑）。

そして、エンジニアとしての役割は、単に開発や実装だけにとどまらないことを今回の経験で強く感じました。新機能案が実現可能かの調査や、仕様の決定など、ビジネスに対して技術的な視点から貢献することこそがエンジニアなのだと実感しました。

開発の進め方について、これまで知識としてしか知らなかったアジャイル・スクラム開発を実践的に体験できたことは大きな財産になりました。プロダクトを常に進化させ続けるために、変更を恐れず、柔軟に対応する姿勢が不可欠であると思います。

さらに、変わり続ける中で、文書をしっかりと残す習慣の価値も感じました。文書を書く習慣は未来の自分やチームメンバーが過去の意思決定や背景を容易に理解するための大切な手段です。私は文章を書くことがあまり得意ではないのですが、シンプルで分かりやすい文章を書く能力は、コミュニケーションの一部として非常に価値があると考えています。そのため、このスキルを今後しっかりとみにつけ、より効果的な情報伝達ができるよう努力していきたいと思っています。

エンジニアとして、働く人として学ぶ事の多い6週間であったと感じています。ここで学んだことを必ず自身のキャリアに活かしていきたいと思います。

最後になりますが、メンターとして素晴らしい指摘やアドバイスをくださった齋藤さんに多大なる感謝を申し上げます。また、素晴らしい助言をくださった東山さん、スアルタさん、藤原さんもありがとうございました！他にもたくさんの方に助けていただきました。関わったすべての方に感謝申し上げます。

本当にありがとうございました！！

参考文献

内閣官房情報通信技術（IT）総合戦略室(2021)「アジャイル開発実践ガイドブック」 （最終閲覧日:2023.9.22）