スクラム開発✖️オフショアチームで失敗した話

はじめに

準委任契約で参画しているプロジェクトで初めてスクラム開発を行った（結果的にはスクラム開発とは言えなかったが）。英語でのコミュニケーションが必須のオフショアチームで、どのような経緯で開始をして、何が失敗の原因だったのかを改めて振り返っていきたいと思う。

スクラム開発導入の経緯

クライアントの経営層にあたる人物（プロジェクトに直接関わることはない）からスクラムで開発していきたいという意向で、我々がいつ・誰が・どのようにスクラムイベントを行なっていけば良いかを立案していったという経緯。チーム構成としては、以下のような形だった。

• ステークホルダー
• PO
• 日本開発メンバー
• 海外開発メンバー

スクラムマスターもおらず、チーム内でもスクラム開発を経験したことがないメンバーばかりであった。また、私は英語での口頭コミュニケーションができず、文章ベースでのやり取りか、POを介してのコミュニケーションが前提だった。

なぜ失敗だったと感じるのか

私自身この1年間開発を進めてきて、メンタル的にしんどい場面が多々あったという点と、「スクラム　アンチパターン」で検索すると出てくるような内容をほとんどこのチームでもやっていたから。

何がいけなかったのか

本当に正しいのかはわからないが、私が考えるいけなかったことを記載する。

1. スクラム開発導入の準備期間がなかった

大規模な機能のリリースをいち早く実現したいというステークホルダーの要望があり、いち早く開発を進めていきたいという意向があった。いわゆるスプリント0のような準備期間を十分に設けず、スプリントの期間やスクラムイベントの参加者・内容などを定義・共有だけして、開始してしまった。

スプリントを開始する前に、プロダクトのゴールやそれぞれがどういう責任・役割を持つかなど、共通認識を持てなかったことでチームがバラバラにスタートすることになってしまった。

2. スクラムに関する学習をしようとしていなかった

ただでさえスクラム開発の経験がないメンバーが多い中、定期的な勉強会などを実施しなかった。一部メンバーだけでの勉強会は開催していたが、他メンバーにまで普及させるほどはできなかった（コミュニケーションの問題にも関わるかも）。

3. 振り返りがタスクの進捗確認だけの場になっていた

レトロスペクティブでは、それぞれのタスクの進捗を確認するような進め方になっており、チームとして何が良く、何がダメだったのかという議論や、具体的な改善策が生まれていなかった。

4. コミュニケーションコストがかかった

英語でのコミュニケーションが必須ということもあり、各イベントの場で意見を出すということがなかなか難しかった。

5. リリースサイクルがなかった

大規模な機能の開発で、当初定期的なリリースを提案していたものの、全ての機能が完成しなければ、顧客としては意味ないのでは？という指摘を受けた。またテスト環境での定期的なリリースも、ステークホルダーが通常業務で忙しく、機能を触ることができないという判断で実現しなかった。結果、約半年後に初めて機能を触ってもらい、リリースをすることになった。機能を触った上での定期的なフィードバックはあまり得られなかった。

6. チームの階層がフラットではない

POと開発メンバーが対等な立場になく、意見を言い出すことが難しいような環境にあったと思う。

まとめ

リリース自体はうまく？いった。しかし開発体験としては、あまり良くなく、スクラム開発は本当に良いものなのか？と疑問を持つことも多々あった。自分が参画していたプロジェクトの状況だと、ウォーターフォール開発の方が合っていたように思える。スクラム開発をする意思決定が現場になかったこともよくなかった。

この失敗を活かして、次の現場ではスクラム開発の成功体験を得る！