なんちゃってスクラムを運用してみて

Mon, 08 Jan 2024 12:00:00 +0900

はじめに

前職の株式会社Zuuでの話です。また個人の見解です。

現在とある金融系Webメディアを運営する会社で、新卒二年目のフルスタックエンジニアとして保守運用をしています。

今回は未熟なエンジニアが自チームにスクラムを導入して半年程経ち、なんちゃってスクラムながらかなり恩恵を受けることができたので、ふりかえりの意味を込めてまとめました。

スクラム導入の背景

今年の4月から異動になった新チームでは、過度な残業時間が日常化しており、常に炎上していることが課題となっていました。

ボトルネックとして、工数見積もりの精度の低さ、実績工数の管理の甘さ、タスク漏れから精度の高い工数の見積もりやプロジェクトのプロセスを進められないことにありました。

そのためチームワークの促進、心理的安全性の改善、工数やタスクの見える化の改善を行う必要がありました。

そこでアジャイルで有名なフレームワークであるスクラム開発を採用することで、正常な開発プロセスを踏めるのでないかと思い導入を決めました。

導入プロセス

キャッチアップ

以下の本やUdemyでインプットを行い、また勉強会に参加し現役のスクラムマスターからアドバイスをもらうなどをしてキャッチアップを進めました。

本

Udemy

勉強会

チームメンバーの同意を得る

定期的にアジャイルやスクラムについての勉強会を開催することで、メリットとデメリットなどを共有することやどれだけ本気でやっているか熱意を伝えることで同意を得ることができました。

また、ドラッガー風エクササイズやインセプションデッキなどチームビルディングを行うことで、徐々に取り入れて行きました。

ロールの準備

スクラム開発では、プロダクトオーナー、開発チーム、スクラムマスターの3つの役割があるため、他のメンバーに協力してもらう必要がありました。

プロダクトオーナーには、ディレクターとして兼任しているチームリーダーに担当してもらいました。

スクラムマスターには、前チームのリーダーに担当してもらいました。（工数などの兼ね合いから最初の二ヶ月のみ参加してもらいました。）

スクラム導入！！！

スクラム導入の準備が完了したので、いよいよスクラムの開始です！

以下のイベントを一週間のスプリントで行いました。ビジネスサイドを巻き込むことができなかったため、スプリントレビューは行っていません。

スプリントプランニング
デイリースクラム
見積もり
スプリントレトロスペクティブ

また、タスク管理の不透明性が課題だったため、このタイミングでNukabのバックログタスク管理ツールの統一を行いました。

成果

リリーススケジュールの安定

計画作りを徹底して行うことで差し込み案件や障害などの突然発生するタスクが発生しても、リリースの見通し立てることができるなど、安定したリリーススケジュールを運用することができました。

メンバーのタスクの進捗の可視化

タスク管理ツールのバックログに統一したことやスプリントプランニングでタスクの分割を徹底して行うことで、進捗の把握やタスク漏れなど改善することができました。

タスクの見積もりの精度の向上

チームメンバー全員で見積もりを行うことで、別メンバーが担当するタスクの要件理解の推進やタスク背景の共有を行うことで精度の高い見積もりを行うことができました。

できたこととできなかったこと

できたこと

ペアプロ文化の促進
テスト駆動開発など新しい挑戦
チームメンバー全員で行う精度の高い見積もり
スプリントプランニングによるリリーススケジュールの計画
スプリントレトロスペクティブから週次のふりかえり文化の定着

なぜできたのか？

スクラムの定義しているイベントを運用することで、アジャイルで重要とされているイベントを暗黙的に運用することができた!

Scrum on Yossy's Notes