はじめに 今回の記事では、アジャイル開発手法を使って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 (…)
↧