半年間のスクラム開発実践記録

自己紹介

こんにちは、arika79です。現在、エンジニア5年目で、昨年11月にi3DESIGNに転職しました。前職ではデジタルコンテンツを扱う事業会社で、新規事業開発のWebプロジェクトを担当していました。現在はi3DESIGNで技術サポートをメインに、要件定義から開発までを担当しています。

今回は、i3DESIGNに転職して初めて参加したプロジェクトがスクラム開発を用いていたので、そこでの実践記録を残しておきたいと思います。

プロジェクトの背景

今回のプロジェクトは、A社がプロダクトオーナーとなり、大手小売業のZ社のために行われたWebアプリケーション開発です。Next.jsを使用したSPA（Single Page Application）webアプリケーションの開発を担当しました。プロジェクトには複数の企業が関わり、B社がバックエンド、i3DESIGNがフロントエンド、C社がQAを担当していました。私はその中で、1月から6月までの半年間、フロントエンドの開発に携わりました。

チームは以下のように構成されていました。

• A社：プロダクトオーナー、要件定義およびスプリントプランニング
• B社：バックエンド担当
• C社：QA担当
• i3DESIGN：開発者7名、テスターやコミュニケーター4名、TL2名、PM1名、デザイナー2名

プロジェクト参加時点では、開発がある程度進んでいましたが、品質や開発の成果において課題がありました。そのため、開発体制の見直しと品質改善が急務となりました。

スクラム導入の背景

スクラム導入のきっかけは、A社の意向によるものでした。大手小売業の要望により、機能の開発順序が頻繁に変わることがあり、柔軟な対応が求められました。私がプロジェクトに参加した時点でスクラムは既に導入されており、ベロシティの測定や開発内容のポイント確認、品質向上とバックエンドとの連携強化が期待されていました。

スクラムの実践内容

スプリントの期間は、前半3ヶ月は1週間単位、後半は2週間単位で設定しました。前半の3ヶ月の間は、QAがない状態でおおまかな動作確認とテストコードの実装で品質担保を行っていました。後半の3ヶ月でスプリントごとのQAが導入され、品質担保をしていました。具体的には、月曜から翌週の月曜までの6営業日を開発期間とし、火曜から水曜の2営業日をQAに充てました。木曜日にはリリース判定を行って問題がなければリリースし、金曜日には次のスプリントのプランニングを行いました。

ミーティングのスケジュールは以下の通りです。

また、使用したツールとしては、ソースコード管理にはGitHubを使用し、スプリントのissue管理もGitHub Projectsを活用しました。コミュニケーションにはSlackを、オンラインミーティングにはGoogle Meetを使用しました。      

成功体験と学び

オフショア開発メンバーについて

QAを重ねていく上で生産性の向上やバグの減少を感じましたが、参加当初はオフショア開発メンバーへの英語でのレビューや仕様伝達に苦労しました。基本的に、デイリースクラムに日本語を話すことが可能なコミュニケーターに参加してもらい、仕様の伝達を行いました。しかし、開発メンバーに対してのレビューなどは英語を用いる必要があり、画像や動画を用いることによって細かな仕様伝達の実施や、i3DESIGN側で英語が得意なメンバーの力を借りることも多々ありました。

開発において意識した点

デイリースクラムはあくまで進捗確認と仕様確認にとどめました。開発において詰まっている点や不明点の解消については、別途Slackのハドルで行い、コミュニケーションの効率化を図りました。また、過去のコード負債を整理し、コンポーネント設計の見直しとリファクタリングを行うことで、コードの品質を向上させました。デザインレビューでは、デザインの幅を広げつつ、スプリント内に収める調整を行いました。

また、QAとバックエンドとの連携強化においても改善の余地がありました。仕様確認などをSlackやMTG、issueの中で行うことが多かったため、共通の認識は持っているものの、議事録や資料が見つけられないということが多々ありました。この問題を解決するために、基本的にissueに関わる仕様確認などは、全てissue内で完結させるようにし、MTGで共有された内容は後ほどissue内に追記するという手法を取りました。

具体的なエピソード

C社のQAチームがプロジェクトに加わったことで、スプリントの期間が1週間から2週間に変更されました。この変更により、リリースの頻度は減少しましたが、品質が向上し、バグの数も大幅に減少しました。特に、リリースの延期が一度もなかったことは、大きな成功体験として挙げられます。これにより、チーム全体がリリースに追われることなく、計画的に作業を進めることができました。

さらに、スプリント期間の変更により、各メンバーが自身の役割に集中できる環境が整い、チーム全体の効率が向上しました。この変化を通じて、私たちはチームの成長を強く感じることができました。特に、QAチームの加入による品質向上は顕著であり、プロジェクトの成功に大きく寄与しました。

結果と振り返り

プロジェクトの成果として、スプリントごとに品質が向上し、リリースの延期もなく計画通りに進行しました。開発縮小前の段階でも品質に関しては高評価を得ており、スプリント内でのリリースが一度も延期されることなく進められました。ただし、プロダクトオーナーのリードにより受け身になりがちだった点が反省点です。また、スクラムマスターの交代制導入や、チームのベロシティ向上策の洗い出し、メンバー個人の技術サポート強化といった改善点も見つかりました。

特に、人数が多い場合には開発の担当箇所が重ならないようにすることが重要です。これにより、コンフリクトを最小限に抑え、効率的な開発プロセスを維持できます。各メンバーが自身の担当範囲に集中できる環境を整えることで、チーム全体のパフォーマンスが向上し、スムーズなプロジェクト進行が期待されます。

• 結果
  • 進捗確認が容易になり、タスクの見える化が進んだ
  • スプリントのゴールが明確になり、仕様変更や急な改修に対応しやすくなった
• 改善点
  • スクラムマスターの交代制導入
  • チームのベロシティ向上策の洗い出し
  • メンバー個人の技術サポート強化

今後のアクションプラン

今後のアクションプランとしては、スクラムマスターの資格取得、開発者としての技術力アップを進めていきます。まず今期はAWS SAAの資格取得を予定しております。

また、今回の記事は体験記であり、知識をインプットできるようなものではないと考えています。今後は資格取得に合わせて、私の体験談を交えたナレッジの共有や、勉強会の開催も積極的に行っていきたいと考えています。