PLASMAプロジェクト誕生〜リモート下でのスクラム開発について【朝デジ システム刷新STORY1】
今回のテックブログは、朝日新聞デジタル（通称、朝デジ）のシステム刷新プロジェクト「Plasma」のリーダー、西島さんによるチーム開発運営のお話です。
リモート環境下、テンポの良いチーム開発を可能にしたコミュニケーションの工夫とは？スクラム開発のポイントとは？プロジェクトの誕生から、開発過程の紆余曲折までを語ってもらいます。
朝デジ刷新プロジェクトとは
はじめまして。朝日新聞社の西島です。
朝日新聞デジタルは今年で10周年になります。10周年に合わせて…というわけではないのですが、朝日新聞デジタルの配信の仕組みは、現在少しずつ入れ替え中です。
この記事を読まれている方はもしかするとお気づきかもしれませんが、今の朝日新聞デジタルの PC 版の記事ページは今までと違うシステムで配信されています。表示を比べてみると以下のようになります。
表面上はまるっきり同じですが、裏側は大きく様変わりしました。もともとのシステムはテストコードもなければ決まった仕様もなく、ごく限られた人にしか手を出せない状態。まさに、絵に描いたようなレガシーコードでした。
私たちは 9 ヶ月かけてレガシーを紐解き、テストがあって CI / CD の仕組みがあって、それなりに誰でも手を加えられるシステムへの移行を一部ですが実現しました。
このブログを借りて、朝デジ Web のシステム刷新プロジェクト「Plasma」の苦労話を何回かに分けてお送りしたいと思います。
第一回のテーマは、プロジェクトの立ち上げと、リモート下でのスクラム開発です。
プロジェクトの立ち上げ
朝日新聞デジタルは非常に多くのステークホルダーが関わるプロダクトです。中でも記事ページは、編集の方や広告の方、UIやUXの改善をおこなう部隊まで、さまざまな方が関わっています。
とにかくステークホルダーが多く、何かを変えるための調整が難しい箇所です。そして私はこのプロジェクトの立ち上げを任された時、まだ入社半年にも満たない時期でした。立ち向かっていける気は全くしません。
そこでプロジェクト発足の段階ではエンジニアだけで組成されていたチームを、今の朝デジに詳しい企画職やデザイナーの方にも加わってもらい、クロスファンクショナルなチームに変更しました。
仕様を紐解いて決めるところからデザインの調整、 UI やバックエンドシステムの実装まで、すべてチーム内でまかなえるようにし、下図の流れでテンポよく開発できる体制を整備しました。
同時に開発のスコープを「既存画面要素の完全な移植」だけに絞りました。マイクロフロントエンドの導入などやりたいことは山のようにあったのですが、前に進むために取り組む課題が複雑になりすぎないようにする必要があったためです。
この体制を整えてから、やっと作るものと取り組み方、そしてプロジェクトのゴールが明確になり、開発が進みはじめました。
開発の進め方
このプロジェクトはスクラムのフレームワークで開発を行なっています。そして、フルリモート環境で進められています。
スプリントは2週間単位で、下図のようにバックログ見直し・スプリント計画・スプリント・スプリントレビュー・振り返りを繰り返す、オーソドックスなやり方です。
メンバー全員がリアルで揃ったことは一度もないくらいの徹底したリモート環境ですが、スクラムを回す上では何も特別なことはしていません。「透明性」「検査」「適応」という基本がしっかりしてさえいれば、スクラムはリモートでも強力に機能します。
まず「透明性」「検査」において重要なことは、とにかく完了条件を明確にすることではないかと考えています。
このプロジェクトでは JIRA でプロダクトバックログやスプリントボードを管理しています。2週間毎にスプリント計画を実施し、JIRA のチケット上で何ができていればストーリーが完了したとみなされるかを明確に記載し、ストーリーを切り分けた具体的なタスクの粒度を1日以内で終わる分量まで細かくし、それぞれのタスクの完了条件に不明瞭なところがある場合はできるだけチケットに文章として残すようにしています。また、スコープを明確にする上で「やらないこと」についても言及するというプラクティスも取り入れています。
タスクやストーリーの完了条件は、疑問点を朝会の場で確認して追記することもあったりと、プランニングやバックログリファインメント以外のタイミングでもかなり細かく手を入れています。
完了条件の明確化はリモートとは関係なしに当たり前に大事なことですが、疎かになった時の生産性低下はリモートだと非常に顕著である、というのがこのプロジェクトでの実感です。
「適応」の面では振り返りのやり方に拘っています。振り返りでは、挙がった意見はすべて議題にあげるようにしています。リモート環境では表情やリアクションが見えづらく、議論する題材を絞りづらいです。紆余曲折ありましたが、時間がかかっても全て取り上げる方式に落ち着きました。
振り返りのツールは今のところ Github Projects に落ち着いています。Keep (図では Good) と Problem (図では Motto) のレーンに各々が書き込んでいき、議論しながら Try を出し合う形にしています。Try は Github の issue にして管理しています。
また、リモートではチーム内のコミュニケーションの量がどうしても落ちてしまいます。それこそ初期の頃は、話せばすぐ解決する問題が次の朝会まで放置されてしまうことも。メインに使っていた Slack ではコミュニケーションの心理的ハードルを跳び越えることが難しくなっていました。
そこで、会議チャットを繋ぎっぱなしにして音声でのコミュニケーションチャンネルを確保する取り組みも行なっています。Slack 上で何往復やりとりしても解決しない事柄が音声通話だと数分で解決してしまうことはザラにあり、有効に機能していると感じています。
最後に
この記事では、プロジェクトの立ち上げと、リモート下でのスクラム開発について紹介しました。次回以降はよりコアな技術の話も取り上げたいと思っております。ぜひご覧ください。
また、朝日新聞社では、スクラムなどチーム運営に興味のある方も募集しています。ご興味のある方は Wantedly から気軽にお声がけください！