スクラムがうまく回っていないプロジェクトを立て直した話
スクラムがうまく回っていないプロジェクトを
1からスクラム導入してクロスファンクショナルで安定した開発生産性を実現するまでのお話です。
プロジェクトの状態
参画時、今のチームには以下の課題があると聞かされました。
- 半年間リリースできていない
- 未完了のスプリントが常習化し問題視されていない
- ストーリーポイントが意味をなしていない
- レビュー中に不具合が見つかる
- リファインメントをやっていない
- レトロ（振り返り）をやっていない
- 活気がない
こんな感じで、スクラムが形骸化してるプロジェクトではあるあるな状態でした。
実際にデイリーやレビューに参加すると、上記の課題以外にもいろんな問題点がありました。
- 心理的安全性が低い
- PBIに完成の定義がない
- PBIがユーザーへの価値提供単位になっていない
- PBIが属人化している
- 1スプリントにどのPBIを積むかをSMが感覚で決めている
- 開発メンバーが個人プレイヤーの集まりになっている
- ベロシティを計っていない
どう改善したか
大きく分けると以下の2軸で実施しました。
- ベースの作成：スクラムの基盤を整え、実践する
- 自己組織化チームの醸成：チームと対話し、こうありたいを共有する
ベースの作成
1つ目の軸「ベースの作成：スクラムの基盤を整え、実践する」では
スクラムをゼロから作り直すことを提案し
スクラムの基盤を整えながらチームへ展開することにしました。
私は普段からnotionを使ってスクラムを管理しているので、自作テンプレをそのまま流用しました。
1. 【Notionでスクラムの基盤を作る】
テンプレを流用しスクラムの基盤を作成しました。
ここの詳細を話すとかなり分量が多くなるので割愛しますが、
ざっくりと話すとスクラムに必要な情報をデータベース機能を使って作成し、
イベントごとにページを用意しています。
具体的には以下のようなページです。
■デイリースクラム
このページで日々の進捗を共有し、スプリントゴールの達成ができそうかを確認します。
■プランニング
このページで次のスプリントに積むPBIを選定し、スプリントバックログの作成を行います。
この時、今まで経験したスプリントのベロシティの平均値も一緒に見れるようにしておき、極端に平均値から外れないようにします。
■レビュー
このページでスプリントで完成したインクリメントのお披露目をします。
フィードバックが出た時は、新たにPBIを作成し実施する時期をPOが整理します。
完成できなかったPBIが出てきた場合は、なぜ完成できなかったのかを振り返り、見返せるようにしています。
■レトロスペクティブ
このページでKPTやFunDoneLearnなどのフレームワークを使ってスプリントの振り返りを行い、トライが出てきた場合はスクラム改善として、次のスプリントで実施するためのアクションを作成します。
■リファインメント（アクティビティ）
このページでプロダクトバックログを表示しておき、優先度順を定期的に見直し、ストーリーポイントをつけます。
PBIには必ず完成の定義を書いておき、何を持って完成とするのかをチーム全体で確認します。
2.【スクラムガイドブックの作成】
スクラムの基本概念や登場人物、成果物やイベントをドキュメントにまとめて展開しました。
スクラムが初めてのメンバーもいたため、リファレンスとして使ってもらえるようにしました。
3. 【イベントを通じてスクラムを知ってもらう】
スクラムが形骸化してしまうパターンに陥っていたこともあり、
「そもそもスクラムとはなんなのか」というところから知ってもらうようにしました。
1で作ったイベントごとのページや
2で作ったスクラムガイドを画面共有しながら説明しました。
詳細はスクラム自体の話になってしまうので割愛します。
4. 【何はともあれ実践しまくる】
土台ができたらあとは実践あるのみです。
最初は１週間のスプリントを何度か回しました。
理由は、ベロシティを安定させるためです。
何度もスプリントを回し、チームが達成できるPBIはどれぐらいなのかのデータを取ります。
当然ですが、最初のうちは何度も失敗します。
ここで見切りをつけたり、開発陣のスキルのせいにしてはいけません。
チームのスキルレベルがどの程度であっても一定の開発生産性を再現させるのがスクラムだと思っています。
実際、このチームにはインターン生を含めた構成になっており、スキルレベルが高いチームとは言えませんでした。
しかし今ではベロシティが安定し、市場の変化に伴ってリリースしたいPBIを狙ったタイミングでリリースできるようになりました。
もちろん、このチームも最初は何度も失敗しました。
失敗は実は失敗ではなく、次のスプリントでより正確な数値を出すための成功です。
目先の状態に一喜一憂するのではなく、その先にある本質的なものを常に見据えて継続することが成功の鍵です。
自己組織化チームの醸成
次に、2つ目の軸「自己組織化チームの醸成：チームと対話し、こうありたいを共有する」についてです。
私のチームでは、個人プレイでタスクをこなす状態になっていました。
個々のマインドが「言われたタスクだけを淡々とこなす」となっていたり
チームの雰囲気が「失敗やミスをしてはいけない」という閉鎖的な空気になっていたのが原因だったと思います。
この状態を改善するために大きく３つのことを実施しました。
1. 【改善したスクラムの導入】
スクラムの基盤を整えて、スクラムイベントに参加してもらってから
自己組織化のベースができてきました。
リファインメントを実施することで
チームの何人かは、「何のためにするのか」「こっちの方が良くないか」といった発言をしてくれるようになりましたし、
レトロを実施することで、
「ここがしんどかった」「ここでこうしてくれたのが助かった」という発言が出てきました。
この時、どんな些細な意見、感想、提案であっても
200%のリアクションで肯定することが大事だと思っています。
明るい雰囲気、発言してもいいんだという空気を作り出すことで「心理的安全性」は高くなっていきます。
スクラムがうまく回るか回らないかの差は、この「心理的安全性」と言っても過言ではないと思っています。
2. 【モブプロの実施】
「心理的安全性」をさらに高めてくれるのがモブプロでした。
私のチームでは、ドライバー１人と残りの２人というスリーマンセルでモブプロを実施しました。
実装する中で、当然わからないところが出てくるのでその度にみんなで調べたり
それぞれが持ってるバックグラウンドから知見を共有します。
この過程で会話が増え、心理的安全性がどんどん高まっていきます。
今では、冗談が言い合える明るい雰囲気になり、スクラムイベントの暗い雰囲気はゼロになりました。
モブプロにはさらに良いところがあります。
知見が共有されるためスキルレベルが平準化され、クロスファンクショナルなチームを作ることができ流のです。
チームの中には、属人化させたいと考える人もいます。
スキルを自分だけに留めることで
「契約期間を延ばしたい」であったり「単価交渉の材料にしたい」と考えるからです。
私はこの戦略が悪いとは言いませんが、長くは続かない脆い戦略だと思っています。
企業が重要視していることは、「売り上げを上げること」であり、
我々エンジニアは、企業が期待する価値以上のものを創出するのがお仕事です。
「売り上げを上げる」には「求められる時に求められる機能をリリースすること」が大事です。
これを実現するには、「再現性のある開発生産力」が不可欠です。
「再現性のある開発生産力」とは、どんな外的要因があってもPBIの消化率が安定しているということです。
チームメンバーが急用で休んだとしても、安定した開発力が実現できることこそが価値あるチームです。
そう考えると、属人化はリスクでしかありません。
その人が休めば開発速度は落ちてしまいますし、その人自身もタスクが集中し休みにくい環境になってしまいます。
完全なLose-Loseです。
それよりも、チームのスキルレベル向上のために自分の持ってる知見を共有する方が
チームの開発力向上に貢献できますし、結果として「この人は頼りになる」という定評がつきます。
実際、私のチームでもFEが強いエンジニアの方がいて
その人は後者の考え方を持っていてくれたため、知見の共有をしてくれました。
結果、クロスファンクショナルなチーム作成にかなり貢献してくれました。
知見の平準化ができた今でも、この方は必要不可欠な人財となっています。
企業にとって本当の価値提供をしてくれるのは、どちらのマインドの人かは一目瞭然です。
3. 【勉強会の実施】
チームの抱えるスキル面での障壁は、勉強会を実施することで解消していきました。
特定の人が講師となってスキルの展開を行うケースもあれば
全員で同じ参考書を読み、議論しながらプロダクトに反映させていくケースもあります。
心理的安全性が高くなっていると、得られる情報も濃くなりかなり有意義な時間になります。
私のチームは2週間スプリントということもあり、2週間に1時間勉強会に時間を当てています。
まだまだ少ないとは感じてるので今後はこの時間をもっと増やせるように
テストの自動化を整え、少ない時間でも同じ開発生産力を保てるように開発環境を整備していこうと思っています。
こんな感じでスクラムの立て直しを実現しました。
最後にスクラムが形骸化してしまうプロジェクトで起きがちな間違いをまとめます。
よくある間違い
■いつリリースできるかを見積もる
スクラムでは見積もりはしません。
スプリントを回す中でベロシティが安定してくると、自ずと1スプリントでどれだけのPBIを終わらせることができるのかがわかってきます。
結果としてあるPBIがいつ頃市場に出せるのかがわかってきます。
■スプリント期間に一度だけリファインメントを行う
このチームはそもそもリファインメントをしていなかったのですが、スクラムを導入しているプロジェクトで多いのがこのパターンです。
リファインメントはそもそもイベントではなくアクティビティで、PBIの優先順位を再整理するためのものです。
市場の変化の激しいこの時代にユーザーのニーズをいち早く察知し価値提供するためには、PBIの優先順位もどんどん変化しないといけません。
このことからお分かりいただけるとおり、リファインメントは毎日15分するのが良いと言われています。
■PBIが開発都合単位になっている
本来PBIはユーザーに価値提供する形でなければなりません。ところがこれが開発都合になっており、フロントだけ作るPBI、バックだけ作るPBIという分け方をしているケースがあります。
これではフロントだけのPBIが完成したとしてもバックのPBIが完成するまでリリースすることができません。
PBIが別のPBIに依存してしまう状態が発生してしまいます。
このケースが発生してしまう要因の1つに、フロントチーム、バックチームのように職能ごとに人員が決まってしまっているということがあります。
要するにクロスファンクショナルになっていないということです。
モブプロや勉強会を通じてクロスファンクショナルなチームにすることがおすすめです。
■ストーリーポイントが工数になっている
何人日でできるかではなく、難易度や労力で相対的に出すのがストーリーポイントです。
スプリントの初めは、その基準がないのでブレてしまうのは仕方がないです。
ある程度スプリントを回したら、実施したPBIと比べて相対的にポイントをつけます。
私のチームでは、最初のうちの基準はこんな感じにしました。
1pt : テキスト変更やコードの一部修正で済むようなもの
2pt : 1つの機能までではないが、難易度が1ptよりの場合
3pt : 1つの機能までではないが、難易度が5ptよりの場合
5pt : 1つの機能を作る場合（DBやインフラ面は揃ってる前提）
8pt : 機能が多少複雑な場合
13pt : DBやインフラ面にも及ぶ機能を作る場合
21pt ~ : それ以上
大事なのは相対的に見ることです。
ここを押さえておけば、「〇〇さんがやれば何ポイント」のように人のスキル依存でポイントがブレることがなくなります。
■レビューができたことの確認だけになっている
レビューは作成した成果物をみんなでお祝いし、更にプロダクトを良くするためにはどうすれば良いかのアイデアを出し合う場所です。
「ちゃんと動くよね」の確認をするだけの場ではないですし、不具合が発生するみたいな状態はもってのほかです。
私のチームではレビューで不具合が発覚するという状態でした。
これを解消するために、PBIに「完成の定義」を記載してもらい
実装が完了するとPOに開発環境で動作確認をしてもらうようにしました。
POからOKが出ればそのまま本番へリリースし、フィードバックが出れば修正すると言った流れです。
このフローにしてからは、レビュー時にはPOからOKが出ている状態なので
不具合がそこで出てくるなんてことは無くなりました。
■不具合が出るのはチームに問題がある
私のプロジェクトでもこのように考えてしまっている状態でした。
「チームのスキルが低かったり、コミュニケーション不足によって不具合が出てきている」
と考えてしまっており、何度も外注先を変えたりメンバーを入れ替えるも半年間リリースできていない状態が続いていたのです。
案外こう考えてしまってるプロジェクトは多いのではないでしょうか。
私のチームの不具合を見ていると、こういったものが多くありました。
- バックの修正がフロントに取り込まれていない
- スキーマ定義の変更が共有されていない
- 仕様通りにできていない
これらはPBIの作り方やモブプロの実施で解決できます。
PBIには「何を持って完成とするのか」を明記し、
フロントとバックで分けるのではなく、「ユーザへ価値提供できる」単位で分けます。
1つのPBIをチーム全員で消化しにいくことで、クロスファンクショナルになり
コミュニケーション不足だと考えられていた不具合は出なくなりました。
まとめ
ざっくりとやったことを書いてみました。
まとめきれてない部分があると思いますが、誰かのお役に立てれば幸いです。
Discussion