Scrumがチームに馴染むまで

こんにちは、AITPの菊池です。
前回の記事で、Scrum開発をとりあえずチームに導入したところまでお話しました。
今回は、3-5-3の初期設定を行うにあたり考えたことと、フローがうまく定着するまでの軌跡をお届けします。

プロダクトオーナーの決め方

プロダクトオーナーの役割は、開発者たちとユーザーの間に立ってプロダクト（システム）や今後の改修方針を確定させていき、責任を持つことです。
マネージャーのような、開発とBiz側の間に入ってコミュニケーションをとっている方は、プロダクトオーナー適性が高いと僕は考えます。当時は現CTOの大野が社内の折衝とプロダクトの面倒見を共に担当していたため、プロダクトオーナーに就任しました。

スクラムマスターの決め方

スクラムマスターの役割は、チームに発生したまたは発生しそうな障害を可能な限り取り除き、日々の業務ができるだけ円滑に回るようサポートをすることです。サーバントリーダーシップが非常に大切とされるポジションです。
世間的には、それまでリーダー職を務めていた人がスクラムマスターを担当するケースが多いように見受けられますが、プロジェクトリーダーとは異なる仕事であり、必ずしもスクラムマスターに向いているとは言えないので、最もScrum開発に興味があり、自走できそうな人をアサインするのが好ましいと僕は考えます。誰も興味がない場合は、チームメンバーやチームを取り巻く関係者全員が不幸になる可能性があるため、そもそもScrum開発を導入しない方がよいです。
スクラムマスターがチームに与える影響は、それくらい大きいです。

当時は、僕が唯一のScrum開発経験者で、過去に名ばかりのスクラムマスターを担当したこともあり、Scrum開発に興味関心、また大きな可能性を感じていたので、自然な流れで僕がスクラムマスターになりました。

最初のチケット

Scrum導入以前から開発は行われていたので、新しく着手するタスクはほとんどなく、各開発者がそれまでに担当していた開発業務を引き続き担当する形で始まりました。中には進捗がいまいちはっきりしないタスクもありましたが、まずは仮で「ここまで終わらせよう」と区切りを無理やり設定し、そこに対して仮でストーリーポイントを振りました。

各種イベント

イベントの中で最初に決めるべきは、スプリントの期間といつからスタートするかでした。
チームが発足してから日が浅かったこともあり、まずはサイクルをたくさん回してScrum開発に慣れて欲しかったので、スプリントは一週間に設定し、それに合わせて他のMTGを設定しました。なお、朝会だけは既に毎日実施していたので、カレンダー上は名前がデイリースクラムに変わるだけの変化で済みました。
いつから始めるかについては、金曜日終わりにすると本番リリースがやりにくくなってしまうので、金曜日〜翌週の木曜日というサイクルで設定しました。

とりあえず1ヶ月やってみた結果

最初の目標だった、ScrumのサイクルやMTG（イベント）にチームが慣れることは達成し、チーム全体でScrumに対してポジティブに取り組むことに成功しました。されにこれは嬉しい誤算だったのですが、レトロスペクティブ（振り返り）が最初から有効に機能し、

• 開発プロセスの改善
• 自分たちにとって、インクリメントとはどういった状態のアウトプットなのか

など開発の地盤がスピーディに整備されていきました。出だしとしては上々で、駆け出しなりにしっかりと成功体験を積んで、自信をつけられたと思います。開発チームの完成度という観点では至らない点が多々ありましたが、Scrumのサイクルにすぐ馴染んだので、顕在化している様々な問題点は近い将来だいたい解決しているだろうという信頼感がありました。

また、スクラムマスター（僕）が30点くらいのたたき台を用意し、とりあえず運用に乗せて開始したScrum開発だったので、当時はもっと非難が噴出すると想定していました。こちらについても議論が非常に生産的で、名指しで文句を言われるなどは一度もなかったため、心配は杞憂に終わりました。A-Teamのみなさんにはとても感謝しております。

最後まで読んでいただき、ありがとうございました。
次回は、Scrumチームがどのように精緻化していったかを書いていきます。