なんちゃってスクラムを運用してみて
Categories:
はじめに
前職の株式会社Zuuでの話です。また個人の見解です。
現在とある金融系Webメディアを運営する会社で、新卒二年目のフルスタックエンジニアとして保守運用をしています。
今回は未熟なエンジニアが自チームにスクラムを導入して半年程経ち、なんちゃってスクラムながらかなり恩恵を受けることができたので、ふりかえりの意味を込めてまとめました。
スクラム導入の背景
今年の4月から異動になった新チームでは、過度な残業時間が日常化しており、常に炎上していることが課題となっていました。
ボトルネックとして、工数見積もりの精度の低さ、実績工数の管理の甘さ、タスク漏れから精度の高い工数の見積もりやプロジェクトのプロセスを進められないことにありました。
そのためチームワークの促進、心理的安全性の改善、工数やタスクの見える化の改善を行う必要がありました。
そこでアジャイルで有名なフレームワークであるスクラム開発を採用することで、正常な開発プロセスを踏めるのでないかと思い導入を決めました。
導入プロセス
キャッチアップ
以下の本やUdemyでインプットを行い、また勉強会に参加し現役のスクラムマスターからアドバイスをもらうなどをしてキャッチアップを進めました。
本
Udemy
勉強会
チームメンバーの同意を得る
定期的にアジャイルやスクラムについての勉強会を開催することで、メリットとデメリットなどを共有することやどれだけ本気でやっているか熱意を伝えることで同意を得ることができました。
また、ドラッガー風エクササイズやインセプションデッキなどチームビルディングを行うことで、徐々に取り入れて行きました。
ロールの準備
スクラム開発では、プロダクトオーナー、開発チーム、スクラムマスターの3つの役割があるため、他のメンバーに協力してもらう必要がありました。
プロダクトオーナーには、ディレクターとして兼任しているチームリーダーに担当してもらいました。
スクラムマスターには、前チームのリーダーに担当してもらいました。（工数などの兼ね合いから最初の二ヶ月のみ参加してもらいました。）
スクラム導入！！！
スクラム導入の準備が完了したので、いよいよスクラムの開始です！
以下のイベントを一週間のスプリントで行いました。 ビジネスサイドを巻き込むことができなかったため、スプリントレビューは行っていません。
- スプリントプランニング
- デイリースクラム
- 見積もり
- スプリントレトロスペクティブ
また、タスク管理の不透明性が課題だったため、このタイミングでNukabのバックログタスク管理ツールの統一を行いました。
成果
リリーススケジュールの安定
計画作りを徹底して行うことで差し込み案件や障害などの突然発生するタスクが発生しても、リリースの見通し立てることができるなど、安定したリリーススケジュールを運用することができました。
メンバーのタスクの進捗の可視化
タスク管理ツールのバックログに統一したことやスプリントプランニングでタスクの分割を徹底して行うことで、進捗の把握やタスク漏れなど改善することができました。
タスクの見積もりの精度の向上
チームメンバー全員で見積もりを行うことで、別メンバーが担当するタスクの要件理解の推進やタスク背景の共有を行うことで精度の高い見積もりを行うことができました。
できたこととできなかったこと
できたこと
- ペアプロ文化の促進
- テスト駆動開発など新しい挑戦
- チームメンバー全員で行う精度の高い見積もり
- スプリントプランニングによるリリーススケジュールの計画
- スプリントレトロスペクティブから週次のふりかえり文化の定着
なぜできたのか？
スクラムの定義しているイベントを運用することで、アジャイルで重要とされているイベントを暗黙的に運用することができた!
心理的安全性の確保やふりかえりを行うことで新しい挑戦やチームの課題について、共有する機会を増やすことができた!
開発フローの見直しや別メンバーの抱えているタスクに興味を持つ習慣ができ、チームワーク力を向上することができた！
できなかったこと
- ベロシティの運用
- ストーリーポイントを用いた見積もり
- スプリントゴールの設定
- ビジネスサイドを巻き込むこと
- スプリントレビューによるフィードバック
- リソース効率よりフロー効率を意識した開発プロセス
なぜできなかったのか？
差し込み案件が多いプロジェクトにそもそもスクラム開発が向いていない。。。
自分がスクラムマスターの役割をしているのにも関わらず、ビジネス的視座が足りていない。。。
ビジネスサイドの同意を得ていない状態で始めたことやエンジニアとビジネスサイドの連携不足により、短期的な目標を共有することができていない。。。
今後やっていきたいこと
マネジメントからだけではなく、チーム文化などの環境を強化することで生産性の向上に貢献したい!
ビジネスサイドを巻き込んだアジャイル開発
ビジネスサイドとより近い位置でアジャイル開発を促進し、プロダクト価値を最大化する仕組みを作りたい！
脱スクラム開発
自分が担当しているプロジェクトは保守・運用のため、差し込み案件が多いことや最終ゴールが決まっているスクラム開発と相性が悪いです。
自分のチームにより適したアジャイル開発のプロジェクトを運用したい！
まとめ
なんちゃってアジャイル開発状態からスクラム開発を導入することで、チームとしての生産性を改善できたと思います。 チームメンバーもスクラム導入に対して前向きに取り組んでくれたおかげで自分にはない経験則から支えてもらったおかげで失敗に終えることなくできたと思います。 また、この経験から挑戦することの大切さやマネジメントを経験することができ、大きく成長することができました。 来年も新しいことを挑戦して今年に負けないくらいの成果を生み出したいと思います！