はじめに
こんにちは！株式会社ブロードエッジ・ウェアリンク CTOの高丸です。
今回は、Qiita Advent Calendar 2024の3日目の記事です。
1日目の記事でも説明した、wine@（ワインアット）オンラインストアのデザインリプレイス（アーキテクチャリプレイス）プロジェクトで、スクラムを導入したお話です。
通常であれば、「うまくいった！」というお話にするところですが、今回は失敗した話（現在は改善している）で書き留めていこうと思います。
ユーザーが触るプロダクトに関する話が少ない
1日目の記事でも紹介しましたが、当時は私以外に正社員エンジニアが1人で、外注の開発会社との橋渡し役をしている状態でした。
外注をする上では、実に基本的な体制であるかと思いますが、自社のプロダクトを強く育てると言う意味では、やはりアジャイル開発（スクラム）の導入は必須だったと私は考えていました。
また、この体制で起こるコミュニケーションのほとんどは
「仕様はどうなっているか」
「仕様はどうするか」
「仕様がまだない」
「仕様通りにできていない」
という仕様にまつわるものでした。
「プロダクトがどうユーザーに使われるか」を考えるコミュニケーションが少なかったのです。
スクラムを導入、ただし少しずつ
スクラム導入で改善しようという私の想いは固かったのですが、当時はスクラム経験者がほとんどおらず、いきなり全てのセレモニーやルールを敷くと動きづらくなるだろうと判断しました。
最初はゆるく始め、必要になったら足していく方針にしました。
その中でも、特にレトロスペクティブ（振り返り）は、チーム開発やプロダクトを改善していく上で最も大事な場と考え、私自身、ファシリテーションに力を入れていました。
レトロスペクティブを通じて、自然と「これは必要だよね」「こういうルールが欲しいよね」といった改善点が浮き彫りになるはずだ、と思っておりました。
導入してみてからはというと、スプリントのタスクが終わらない事象が発生し続けました。
スプリントのタスクが終わらないことは、初期のスクラムではよく起こることだと思いますが、どれだけタスクを分解しても終わらない事象が発生していたのです。ストーリーポイント付けやプランニングが形骸化していっていました。
省略していたものの影響
省略していたセレモニーやルールもありました。
例えば、すでにプロダクトが存在していたため、インセプションデッキは作らずにスタートしていました。ここからすでに間違えていたと思いますが、全員の意識付けができていなかったと思います。
また、アーキテクチャリプレイスのため、開発初期はスプリントのインクリメントだけでは見せられるものが少なかったため、スプリントごとのプロダクトレビューを省略していました。
上記のタスクが終わらない事象が長期化し、スケジュールも押され、長期間プロダクトレビューを省略していたことも問題になりました。
いざ結合テストするタイミングになると、実は「完成」していない箇所が多数発覚。テスト開始時期が想定以上に延び、スケジュールに影響が出てしまいました。
明確なゴールとロードマップの欠如
タスクが終わらない、完成形が見えない、ゴールが不明瞭……メンバーからも「ゴールが分からない」という声が出ました。
確かに、当時はロードマップを十分に示せていなかったと思います。目の前のタスクに追われ、全体感や優先度が見えにくくなっていたと思います。
事業・企画側と相談し、スコープを絞りに絞ったロードマップを策定・共有することで、少しずつ改善が見え始めました。開発メンバーも「ここまで頑張ればひとつの区切りが来る！」と理解できるようになったのです。
助けあうチームが作れていなかった
スクラムではクロスファンクショナルなチームが求められることが多いと思いますが、どうしても外注の開発会社は得意・不得意な部分が分かれていたため、フロントエンドをメインで担当する人と、バックエンドをメインで担当する人を分けていました。
開発品質に関してあまり影響は出ませんでしたが、「自分のパートを終わらせる」ことが優先され、チーム全体でスプリントゴール達成を目指す意識が育ちにくかったのも事実だったと思います。
ペアプロも初期は行っていたのですが、タスクに追われていたので、後半には少なくなり、ノウハウの共有も弱まっていました。
立て直し
今回、アーキテクチャリプレイス（ヘッドレスEC化）ということでフロントに重きが置かれているにもかかわらず、メンバーにフロントエンドが得意なメンバーが少なかったので、コーディングのルールが定まっていないことが一番タスク消化に影響が出ていたと思います。
Remixフレームワークへの移行なので、基本のReactの知識であるコンポーネントの思想やステート管理などをチーム全体にノウハウとして共有する必要がありました。
開発会社に依頼し、フロントに強いメンバーの要請を行い、ルールをしっかり作っていただくことを依頼しました。
失敗から学んだこと
スクラムのセレモニー・ルールは洗練されており、基本的には省略すべきではないことが今回の事象で明らかになりました。
あまり「意識」という言葉で仕組みづくりを考えると、人依存になってしまうので避けがちですが、
実際、現場で雰囲気をつくるのは、みんなの「意識」です。
スクラムには、その意識を根付かせるためのセレモニーやルールが備わっています。
もし、スクラムがうまく回らなくなってきたときには、「意識」をもう一度揃えに行こうと思うようになれたのは、今回の失敗から学びでした。
Discussion