100名規模の開発体制にスクラムを取り入れる、LINE NEWSのリードエンジニアたちが工夫したこと

サービス・機能やそれにまつわる開発の裏話や取り組みを聞く「Product Story」シリーズ。今回は、主要ニュースからエンタメまで、あらゆる話題をLINEアプリ上で読め、月間利用者数7,500万人(2020年4月末時点)を誇る国内No.1スマートフォン向けニュースサービス「LINE NEWS」の開発チームです。 

約100名が携わり、日々様々なプロジェクトが進行するLINE NEWSでは、より柔軟かつスピーディーな開発を目指し、アジャイル開発の手法の1つであるスクラムが取り入れ、3つのチームに分担して取り組んでいます。 

LINE NEWSの大規模開発体制においてスクラムを導入した背景や実際に取り組んで分かったメリットなどについて、それぞれのチームのリードエンジニアとして開発をリードする小野将司、森藤賢司、稲葉大樹の3人に話を聞きました。 

 

小野将司: SIer、Webアプリ開発、Flash向けの開発経験などを経て、iOSの世界へ。前職ではiOS/Android向けのゲーム開発、ゲーム用サーバー開発、クライアントSDK開発など、ゲーム企画などに携わった。現在、LINEにて5年目。当初はiOSアプリケーションエンジニアとして入社したが、現在は過去の経験も生かしてWebアプリケーションエンジニアを担当。 

森藤賢司: SIerにて様々な業務システムや、自社クラウドサービスのWebコンソール開発に従事。その後ソフトウェアベンダーに転職し、コンシューマ向け動画パッケージソフトや自社住所録管理Webサービスの開発に携わる。2015年6月にLINEに入社しLINE MALLやLINE BLOGのサーバサイド開発に携わる。現在はLINE NEWSのサーバサイドエンジニアとして、機能追加開発や運用を担当。 

稲葉大樹:学生時代は国際経済学を専攻していたが、独学やインターンシップでの実務経験を経てサービス開発を学び、2018卒の新卒としてLINEに入社。入社後はLINE NEWSのサーバーサイドエンジニアとして、開発・運用を担当。 

 

LINE NEWSの開発体制スクラムに取り組むまでの進め方 

――まずLINE NEWSの概要と、開発チームから見た特性について教えてください。 

森藤:LINE NEWSは話題のニュースや占い、天気など様々なコンテンツを配信しているサービスであり、月間アクティブユーザー数は約7,500万人に達しています。機能の追加や強化は頻繁に行っており、特に2020年は新型コロナウイルスの影響もあって数多くの新機能をリリースしました。LINEのサービスは数多くありますが、その中でも機能リリースが非常に多いプロジェクトだと思います。 

小野:追加するもので多いのは、内外の様々なサービスやシステム連携に関する機能ですね。たとえばYahoo! Japanから災害情報を取得してLINE NEWSで配信する機能や、検索サービスや社内で開発したレコメンドエンジンと連携する仕組みなど、様々な案件に対応しています。特に昨今のLINE NEWSは、動画や新型コロナウイルス関連の情報まとめなどいわゆるニュース記事の配信以外の部分にも力を入れているため、新規開発の案件は年々増加し続けている状況です。 

 

 

――現在の開発体制を教えてください。 

小野:広い意味だと、企画側を含めて100名程度が開発に携わっています。開発に絞ると総勢40名程度で、3つのチームに分担して大小様々な開発に取り組んでいます。それぞれのチームの役割に違いはなく、案件が発生したときに、アサイン会と呼んでいる会議で都度案件を割り振っています。私たち3人は、その3つのチームで開発を取りまとめるリードエンジニアという立場です。 

 ――LINE NEWSではスクラムを用いたアジャイル開発に取り組んでいるとのことですが、それ以前はどのように開発を行っていたのでしょうか。 

森藤:LINE NEWSの開発には、サーバサイドエンジニア、フロントエンドエンジニア、QAエンジニアという異なる役割のエンジニアが参画していて、スクラムを導入する前は、開発プロジェクトが立ち上がるたびに、それぞれの組織のマネージャーが担当者を決めて適宜アサインされていました。また、プロジェクト全体に関わるテクニカルプロジェクトマネージャーがいて、組織間の調整を一手に担っていました。 

 当時は案件数が増え始めていた時期だったのですが、各組織のマネージャーにすべての案件の詳細把握とアサイン調整が集中してしまったため、スケールすることが難しくなっていました。企画から受けた要望を実装可能な設計に落とし込む作業を担っていたのもマネージャーだったので、案件数が増えたことでその部分がボトルネックになり、リードタイムが伸びる要因になっていました。 

稲葉:案件ごとに、アサインされるメンバーが毎回異なっていたため、メンバー間の連携についてのノウハウが蓄積されないという点も課題だったと感じています。関わる人数もプロジェクトも多く、意思疎通やコミュニケーションにムラがあることは、改善が必要なポイントだったと思います。 

 

 

それぞれのチームにリードエンジニアを配置した背景  

――では、何がきっかけでスクラムを導入することになったのでしょうか。 

 森籐:代表してお話ししますね。開発側としては、今お話したような開発規模の拡大に対して体制をスケールできずにいて、リードタイムが伸びていることを解消したいと思っていました。スケールさせるための1つの方法として、スクラムを導入することをきっかけとして、アジャイルなスモールチームを複数作り、スモールチームが自走することでマネージャーへの一極集中を解消したいという狙いです。 

一方、企画側も総勢50~60名はプロジェクトに関わっているという規模で、どうしても担当案件単位での業務にフォーカスしがちでした。開発側も同様に担当案件ベースでアサインされる体制だったので、お互いに背景や目的の共有が十分にできないままタスクを進行していくような状況になっていました。 

いわゆるコミュニケーションが疎遠な状態になっていて、当事者意識やサービスの全体感といった大事な部分が欠落していることをプロジェクト全体で解決しないといけない、という認識を開発と企画の双方で持つに至りました。 

この両者の課題解決にスクラムの導入が有効ではないかという考えに至り、LINE NEWSでスクラム開発を始めることになったのが、2019年の話です。なお、LINEにはEffective Team and Delivery室という組織があって、スクラムに限らずチームのプロセス改善をサポートしてくれる体制があるのですが、LINE NEWSのスクラム導入でもこのチームに相談していて、導入初期はプロジェクトにサポートで入ってもらっていました。 

こうして始まったスクラム体制での開発ですが、もちろん最初から全部がうまくいったわけではなく、細かい課題がありました。例えば普通のスクラムのチーム体制だと、技術課題に対する判断といった、いわゆるアーキテクト的なまとめ役がいない状態だったので、声の大きい人の意見が通りやすくなってしまったり、多くのメンバーが納得できるような結論に至らなかったりといった問題が発生していました。またステークホルダーである企画側のメンバーから、各チームのコンタクトポイントが誰なのかが分からないと指摘されていました。たとえば新機能の開発について質問したいけれども、誰に聞いていいのか分からないといったことです。 

こうした課題を解決するために、LINE NEWSのスクラムでは、アーキテクトの役割を担うリードエンジニアをチームに配置することになりました。なお、ここまでのスクラム導入からリードエンジニア制といった開発体制の変遷については、LINE DEVELOPER DAY 2020 での発表がありますので、こちらも合わせてご覧いただけると、より深い歴史を知ってもらえるかもしれません。 

 

 

スクラムを導入したものの最初は大きな戸惑いが 

――みなさんがリードエンジニアに指名されたとき、どういった心境でしたか。 

森籐:私は先頭に立って引っ張っていくのは苦手なタイプなので、最初はかなり不安がありました。ただ、マネージャーから信頼されているからリードエンジニアに選ばれたのかなと考え、頑張ってやってみようと思いました。ただ、スクラム開発では、ミーティングのコミュニケーションコストが増えるので、ちゃんと実装するための時間を確保できるのかが正直不安でした。 

稲葉:私も新卒で入社してようやく3年目が終わろうかという状況で、本当に私に務まるのかと不安は大きかったですね。またLINE NEWSに携わる関係者は多く、いきなりプロジェクトの進め方を大きく方向転換できるのかという点は心配でした。 

小野:私は何でも新しいものが好きなので、スクラムに取り組むことも大歓迎でしたし、リードエンジニアに指名されたこともテンションが上がりましたね。よし、やってやるかという感じです。マネジメント業務は決して好きではないのですが、やればできるんじゃないかと思っていました。 

――実際にスクラム開発を導入して、どのような課題が生じましたか。 

小野:最初にぶつかった壁は、どこまでスクラムの作法に沿ってプロジェクトを進めるべきかという悩みでした。最初はスクラム開発の手順どおりに進めていたのですが、これは本当に必要なのかといった議論がどうしても生まれてしまうんですよね。そこで、どう進めるべきかを考えるのに、当初は時間を使いました。 

今はだいぶいい形に落ち着いたと思っています。ただ、スクラムの教科書に書いてあるとおりの進め方ではなく、細かな部分はだいぶ変えています。レトロスペクティブやレビューの時間はスクラムの教科書で一般的に推奨されているよりも短い時間で実施していますし、逆にプランニングにかける時間は少し長いです。そのほうが我々のチームにうまくマッチしました。またスプリントレビュー前準備会、のような独自のスクラムイベントも新たに導入しています。 

稲葉:私たちのチームも最初はスクラムの標準的な進め方にしようとしましたが、自分たちに合わない部分が出てきたので適宜カスタマイズしています。たとえばタスクの実装などに時間を割くために、チームで振り返りを行うレトロスペクティブを2スプリントに1回にするなどといったことです。レトロスペクティブを行なっていく中で、徐々に問題点も出てこなくなってきているので、毎スプリントレトロスペクティブを実施しなくてもよいだろうと判断しました。 

 

 

森藤:私たちのチームで工夫したのは、イベントのファシリテーターをローテーションすることです。特にレトロスペクティブでは、話す人がどうしても偏ってしまう問題がありました。そこでファシリテーターをローテーション制にしてみんなに話してもらうことで、それぞれに当事者意識をもってもらうようにしました。 

稲葉:LINE NEWS全体でのスクラムの使い方も工夫しています。本来であればバックログにあるタスクをそれぞれのエンジニアが取っていく形になると思いますが、LINE NEWSでは各案件をどのチームで対応するかをアサイン会で決め、それを全体のバックログで管理します。案件を受けたチームは、自分たちのバックログに案件を取り込み、そこでタスクや優先度をプロダクトオーナーと話し合って決めるという流れで進行しています。このアサイン会や全体バックログは、LeSS (Large-Scale Scrum) のオーバーオールプロダクトバックログリファインメントを参考にアレンジしています。 

森藤:なので、LINE NEWSではプロダクトオーナーが2つのレイヤーに分かれているんです。全体バックログを統括管理するプロダクトオーナーと、チームごとのバックログを管理するプロダクトオーナーがいて、便宜上それぞれをPPO (Proxy Product Owner)とPO (Product Owner)と呼んでいます。  

 

期限が決まった案件や割り込み案件への対応がネック 

 ――スクラムを適用することが難しいケースとしては、どういったものがありましたか。 

小野:本来のスクラムでは、リリース日を決める権限を持っているのは開発側になります。ただLINE NEWSの場合、いつまでにこの機能をリリースしてほしい、あるいは急いでこの機能を実装してほしいといった要望を企画側から受けることが少なくありません。また緊急でこれを修正してほしいなどといった割り込みもある程度の頻度で発生します。スクラムでは、こういった案件に基本的には対応できません。それをどうするかは大きな課題でした。 

本来のスクラムは開発が完了したらリリースなのですが、リリース日が決まっているため、そこから逆算してユーザーストーリーを組み立てています。一般的なスクラムではやらないことですが、「リリースを行う」とか「QAを行う」といったリリース日に連動しなければならないタスクを独立したユーザーストーリーとし、リリース日のあるスプリントに先んじて割り当てています。要するに、スクラムの中にウォーターフォール的な開発が混じるイメージです。 

稲葉:割り込みに対応するためにスプリントの単位を1週間と短いスパンにしています。現在、各チームへの案件のアサイン1週間単位で行われているので、それと周期を合わせることで、スプリント途中での割り込みを極力防ぐ形です。 

 スプリントの期間は試行錯誤しましたが、たとえば2週間にするとどうしても割り込みへの対応が柔軟にできなくなってしまいます。そのため、各チームとも1スプリント1週間で落ち着いている状況です。 

小野:スプリントを1週間にすると、それだけイベントの回数も増えることになり、コードを書く時間が削られることになります。そこで1つ1つのイベントをスリム化するなど工夫しています。 

 

 

――スクラム開発でよかったと思うのはどういった部分でしょうか。 

小野:デイリースクラムは絶対にやったほうがいいですね。想定外の事態を素早く察知できますし、タスクが進みすぎていたり遅れすぎている場合、それらの原因を突き止めることで問題が深刻化するまえに対処することができます。典型的な例としてはUIデザインが遅れていて作業が進めないから、先に他のタスクを回そうとか、デザインチームに催促に行こうとか。それとスプリントレビューが一番機能していると感じています。 

企画側から案件が下りてきたとき、ウォーターフォールだと動作する形でデモする機会は、あえて作らないとないんですよね。ただ、スクラムの場合は必ず毎週スプリントレビューを実施し、そこでデモを見てもらうといったことを行います。それにより、仕様の漏れや認識のズレを早期に気づくことができるのは大きなメリットです。 

特に大きな案件の場合、見た目や動作が企画側で考えていたものと違うといったことが生じることが少なくありません。それに早いタイミングで気づいて軌道修正できるので、手戻りのコストを抑えられます。従来は検証環境に開発したものを展開した段階で、これは違いますねと戻ってきます。そうすると、リリースまでに余裕がないので非常に慌ただしかったのですが、開発の段階で修正できるようになったのですごく楽になりました。 

 ――当初、デモの開発についてエンジニアの皆さんに戸惑いはありませんでしたか 

小野:デモの実施というと身構えてしまうかもしれませんが、できる限りエンジニアの負担を減らすために、実装したものを画面共有しながらそのままプレゼンテーションするという形にしました。最初はプレゼンテーションが必要ということで難しいのではと思っていましたが、実際にやってみるとエンジニアも普段なかなか実施する機会のない説明する力を要求されるので、スキルアップということで楽しんで実施できていると思います。 

稲葉:先にお話したとおり、もともとフロントエンドとサーバーサイド、QAといった各ロール間のコミュニケーションが希薄になりがちという課題がありました。しかしスクラムを前提とした現在の開発体制に移行したことで、その課題を解消できたことは大きかったと考えています。 

以前は細かい確認を遠慮してしまうような雰囲気もありましたが、今ではロールが異なっていても密にコミュニケーションできるようになりました。これにより、細かい設計ミスや小さなバグの発見漏れが減少したと感じています。 

またウォーターフォールで開発していたときは、プロジェクトを振り返る機会はあまりありませんでした。しかしスクラムで開発することにより、レトロスペクティブなどのイベントで強制的に振り返りをする場が設定されます。そこで課題が発見できるようになったこともスクラムのメリットだと考えています。 

 

 

スクラムを経験したことでウォーターウォールのよさも再発見 

 ――スクラム開発について、企画側の人たちへの理解はすんなり進んだのでしょうか。 

稲葉LINE NEWSの企画は多くの人たちが関わっているため、そこはかなり時間がかかったと思います。最初は、企画側で発生した案件を開発側に割り振る役割を担う人もいなかったので、開発側だけスクラムにしたという感じでした。 

そもそもLINE NEWSの企画はチームや担当者ごとの役割が細分化しているほか、関わる人も相当な数になります。そのため、技術開発への理解やプロジェクトマネジメントの考え方についても差があり、スクラムを取り入れることの難易度はかなり高かったと感じています。 

小野:ここについてはプロダクトオーナー陣がとても協力的で助かっています。 

稲葉:そうですね。最初はプロダクトオーナーもいないところからスタートしましたが、POとPPOの体制ができて、彼らが企画と開発の仲介役を担ってくれたことで、スクラムがうまく回るようになったと思います。 

 ――実際に取り組む前と現在で、スクラムに対する考え方は変わりましたか。 

小野:スクラムを経験したことで、ウォーターフォールのよさが理解できました。決まり切っているものを開発するのであれば、ウォーターフォールにはメリットがあると思います。 

 振り返ることの大切さにも気づきました。手を動かす時間が多少減ったとしても、しっかり振り返りを行うことでコミュニケーションロスなどの無駄を減らすことができます。その効果はすごく大きいと感じています。例えばあるメンバーが問題と思っていなかったような事象でも、別の立場のメンバーから見ると大きな負担になっていることがあったりします。何でも確認作業をQAメンバーに任せてしまっていたりとか。振り返りと話し合いを行う場所を設けてこのような負担を減らしていくことができればメンバー全員のやる気にも繋がります。  

稲葉:スクラムのルールを守らなきゃという意識でやると、不便な部分が多いなと思っています。あくまでフレームワークだと認識した上で、自分たちなりにカスタマイズして取り込めばすごくいいものだと思うようになりました。 

 

怖いのは属人化とチーム運営の形骸化 

 ――スクラム開発において、将来的に改善したい点があれば教えてください。 

 

 

森藤:期限がシビアな大型の案件があり、それを小野さんのチームと協力して開発を行いました。複数チームで開発するのは初めての試みだったのですが、作業分担のすりあわせなどで問題が発生してしまいました。今後、同様の大型案件が来てもスムーズに複数のチームで分担できるように、プロセスの改善などを進めたいと思っています。 

稲葉:そもそものスクラムでは、開発チーム内でロールは分かれていないという認識ですが、LINEではフロントエンドとサーバーサイド、QAで組織が分かれていて、ロールごとのタスクの比重が揃わないことが課題だと考えています。 

たとえば、サーバサイドとフロントエンドでの開発ボリュームがスプリント内で差が出ることもあります。また、設計がある程度進まないとテスト設計も難しく、テスト関連のアクティビティの動き出しがスプリント後半になることもあります。このような異なる動き方や比重に対して、チームとして負担を平準化することなどを今後考えていきたいですね。 

小野:怖いなと感じていることの1つは属人化です。この案件は前回このチームがやったから、今回もこのチームに任せようといった形で、同じチームが同じような案件ばかり対応するようになるのはよくないなと考えています。 

もう1つはチーム運営の形骸化です。たとえばレトロスペクティブで特に課題がないよねという感じになってしまい、チーム運営のための取り組みが形骸化してしまうと、スクラムのメリットが薄れてしまうことにもなりかねないので、注意していきたいところです。 

 スクラム開発においても、LINE NEWSの開發自体もまだまだ改善できる部分があると感じているので、新しいことを楽しんで取り入れていきたいですね。少しでも興味を持った人がいれば、ぜひ一緒に働きましょう。 

 

LINE NEWSでは、一緒に働くメンバーを募集しています