初の本格スクラム開発体験記
Zenkenブログをご覧の皆様、こんにちは。
メディアクリエイション事業部 開発課の関沼と申します。
私は入社してから6年半、フロントエンドエンジニアとして自社メディアの開発・運用を中心に、コーディングやWordPress開発をメインで行ってきました。
1年ほど前からサーバサイド・バックエンドに転向し、現在はシステム開発に携わっています。
そのシステム開発の中で、本格的なスクラム開発を約半年間経験させていただきました。
これまで経験してきたウォーターフォール型の開発と大きな違いを感じたのと、社内でもこういった体制での開発が行われていることを知り、新たな知識を得ることができました。
今回のブログでは、参加させていただいたスクラム開発についてご紹介していきたいと思います。
そもそもスクラム開発とは
まず初めに簡単に説明しますと、スクラム開発とは、「透明性（見える化）」「検査（確認）」「適応（必要に応じてやり方を変える）」を基盤とし、短いサイクル（以下、スプリント）で継続的に価値を提供するアジャイル手法のフレームワークの一つです。
明確な役割分担と定期的なイベントが設定されており、頻繁なコミュニケーションとフィードバックを重視しています。
これにより、変化に柔軟に対応しつつ、必要最低限の機能単位でリリースし、効率的にユーザーに価値を提供できます。
▼ 参考
— アジャイルソフトウェア開発宣言
— スクラムガイド
一方で、ウォーターフォール開発は、プロジェクトを「要件定義」「設計」「実装」「テスト」「納品」など、明確に区別された段階に従って進める手法です。
ウォーターフォールは要件が明確で変更が少ないプロジェクトに適しており、計画通りに進行することで効率的に成果物を納品することが可能です。
一方で、プロジェクト後半での変更やフィードバックの反映は難しく、完成後に実際に使われない機能が多くなるといったリスクはあります。
これまで私はウォーターフォール型のプロジェクトばかり経験してきたため、本格的なスクラム開発への参加は今回が初めてでした。
※過去のZenkenブログで、スクラム開発について別途解説されている記事もあったので、詳しく知りたい方はよろしければご参照ください。
参加させていただいたスクラムチームの体制
体制としては、
– スプリントは1週間単位
– スクラムチームはPO（プロダクトオーナー）、デザイン、開発、QA（品質保証）のチームで構成
– タスク管理はJira、カンバンとしてMiroを使用
で進めていました。
また、スクラムイベントは、時期や必要性によって増減はありましたが、基本として1スプリント（1週間）で下記のようなミーティング（以下MTG）がありました。
1. スプリントプランニング（PO、開発チーム）
ここで1週間のスプリントの目標と実装する内容（各実装内容のこと。以下PBI）を確認・決定し、実装担当者がそれぞれのPBIを細分化して、いつまでに何の作業を行うかの計画立てを行います。
2. リファインメント前UI確認（PO、UI/UXチーム）
UI/UXチームがPOに作成した画面を共有し、デザインを確定させるためのMTGです。
ここで確定した内容がリファインメントに進むため、開発チームではリファインメント前確認（※）を行います。
※PBIごとに確認担当者を割り振り、リファインメントMTG前に内容を確認し、やることや質問・確認事項の洗い出しをすること。
3. リファインメント（スクラムチーム全員）
POからチーム全体に各PBIの説明をしていただき、要件に対しての認識のすり合わせを行います。
それを元に、リファインメント前確認で洗い出した質問・確認事項のすり合わせを行い、開発チーム全員でポイント数（開発にかかる期間の見積もり）を決めます。
この見積もりまで終わったPBIが着手可能な状態として扱われ、翌週以降のスプリントプランニングでの実装PBIの候補となります。
4. スプリントレビュー（スクラムチーム全員、ステークホルダー）
実装完了したPBIについて、開発チームからステークホルダー・チームにデモンストレーションをお見せして確認していただきます。
この時にフィードバックやアイデアをいただくくことで、新しいPBIが作成されることもあります。
5. レトロスペクティブ（スクラムチーム全員）
スプリントをKeep、Problemで振り返り、スクラムチーム全員で共有し、次のスプリントで行うTryを決定します。
また、ほぼ毎日下記のMTGが行われていました。
– コアタイム（スクラムチーム全員）：朝の同時接続タイム。ラフにチームをまたいで確認や相談などが可能
– 開発チーム朝会（開発チームのみ）：朝の短いMTGで進捗確認、予定共有
– デイリースクラム（開発チームのみ）：POタイムに向けて、夕方の短いMTGで進捗確認とチームとしての相談事項の確認
– POタイム（スクラムチーム全員）：全体でタスクの進捗確認、翌日のスケジュール確認、現スプリントのTryの進捗確認、各チームからの確認相談事項の共有
スクラムとは別に、開発チームではGoogle Meetで定期的にも行っていました。
いつでも質問・相談しやすい環境で、右も左もわからなかった私には非常にありがたかったです。
スクラム開発で感じたこと
スクラム開発では、とにかく密なコミュニケーションが求められました。
1週間単位でスプリントを回し、毎日細かい進捗を確認するために、一日のタスクを強く意識するようになりました。
MTGが多いこともあり、相談はとてもしやすい一方で、開発に割くことができる時間も限られるので、この時間にここまでは仕上げなくてはという開発のタスク管理力が向上した気がします。
また、最初は目まぐるしく感じましたが、1週間をベースとしていることで各PBIが大きくなり過ぎないようにしていることもあり、「こうしたい」という要望が新しく挙がった時に、優先度を上げて次スプリントで対応する…といった差し込み方もしやすく、小回りの利きやすさを実感しました。
この点はウォーターフォールとはやはり大きく違うと感じました。
次に、チームの一員であるという感覚がとても強かったです。
話し合う時間が多く、また、要件の段階から一緒にすり合わせさせていただけることで、「開発の工程を担当している」のではなく、「一緒にサービスを作っている」という認識になりました。
また、スクラム開発では、当事者意識をより強く持つことの他、コミュニケーションが頻繁にある分、チームの雰囲気や心理的安全性がとても大事だと感じました。
今回参加させていただいたスクラムチームは、互いのチームを尊敬・尊重することを当たり前にしてくださる方々だったので、途中参加でも非常に居心地が良く、やり取りしやすかったです。
関わらせていただいたスクラムチームの皆様に感謝しております。
それから、スクラム開発では、依頼元からスクラムチームへの理解と信頼をいただけることが必須だと思いました。
さらに、依頼元からの意見であっても、それがサービスにとって必要かどうか、どの程度の優先順位なのかを判断するのはPOの役割であり、スクラムチーム側にある裁量が非常に大きいことにも驚きました。
その分のサービスへの理解はもちろん、裁量をいただいている分、各チームが自分たちの役割を明確に認識して果たしていく必要があり、その上で、サービスにとってより良いものを探っていくということが求められると思います。
一言に「システム開発」といっても体制は色々あるのだということが知ることができて、非常に新鮮であると同時に知見が広がりました。
今回はスクラム開発の事例として紹介させていただきましたが、これからスクラムを始めてみようとされる方や、興味を持たれている方にとって、少しでもイメージしやすくなったら嬉しく思います。
最後に
スクラム開発を通して、要件に対して実装を行うだけでなく、要望の背景や目的を知った上で仕様を検討し、一緒にサービスを構築することの重要性を学びました。
そのため、「詰めていなかったこの部分はこういう挙動の方が良いのでは」などと考えながら相談させていただくことができて、初の新規のシステム開発をする上で考え方・進め方が非常に勉強になりました。
こちらのプロジェクトではLaravelというPHPのフレームワークを使用していましたが、現在参加しているプロジェクトでは、CakePHPを使用しており、新しい学びを得ています。
まだフレームワークに慣れていないこともあり、既存システムの理解と担当箇所の実装で手一杯の状態ではありますが、徐々にシステム全体やサービスへの理解を深めて、いずれは上流工程から関わっていけるようになりたいと考えています。
そのためにもまずはCakePHPへの理解を深めつつ、プロジェクト内で使用されているReactやTypeScriptも改めて学んでいこうと思います。
また、今は出来上がった環境で作業させていただいておりますが、どういう構成でどうやって出来ているのかにも興味があるので、AWSなどのインフラについても勉強してみたいです。
新しく触れる領域は知らないことやわからないことばかりで、まだまだ伸び代を感じることができて、苦しみつつもとても楽しいです。
知見を広げ、エンジニアとして対応できる範囲を広げるために、これからも楽しみながら成長を続けていきたいと思います。
