今回はアジャイル開発のスクラムについて取り上げていきます。
リーダー、マネージャーの皆さんならもちろん聞いたことがあると思います。
おそらくこの記事を見ていただいているということはスクラムを導入すべきか検討中なのではないでしょうか？
現場で実際スクラムを経験した著者の実体験を交えながら皆さんにその内容をお伝えしていきたいと思います。
スクラムの良いところ
実際にスクラムをやってみて個人的に良いなと思うところを挙げていきます。
スクラムガイドという明確な教科書が存在している
スクラムというフレームワークを回すにあたって明確な基準があり、常にそのガイドもアップデートで改善が重ねられています。
メンバー構成、役割、やるべきイベントなどの原則が書かれているため、まずは教科書を見てその通りにやってみるという始め方ができるのは大きいですね。
また、このガイドは聖書みたいなものなので勝手に改変された亜種が世の中に乱立してユーザーが惑わされることはないというのも良いところです。
スクラムという名前の通りメンバーの助け合いがありがたい
がっちり肩を組み合うという様子さながら、メンバー同士が密に連携するためその恩恵は大きいと感じます。
⚫︎開発者視点 → 開発メンバー全員がイベントに参加するので実装についての意見を求めたり詰まったところを聞きやすい
⚫︎プロダクトオーナー視点 → 仕様策定に開発者の視点が入るためプランニングと工数見積の精度が高くなる
スクラム3本柱はとても優秀
スクラム3本柱である「透明性」「検査」「適応」について、これは明快でとても大きいメリットだと思います。
「ヤバい問題は早めにチームに共有してね」「そして問題があったらチームで対応しましょう」ということなのですが、これが出来るのは本当に助かります。
非スクラムの場合、各メンバー同士が疎結合なのでどうしても問題点を相談しにくかったり、場合によっては問題を自分の中に留めてしまうケースがあります。
そして問題が大きなってから打ち明けて炎上してしまうなど。
一方でスクラムはデイリースクラムで毎日自分以外のタスクもある程度把握し、全員が喋りますので早い段階で問題を打ち明けやすいです。
問題点を早く把握して対処するということは結局はプロジェクトの完成に大きく貢献します。
スクラムは万能な手法なのか？
個人的に万能とは言えないと思います。その理由を記載していきます。
コミュニケーションが苦でないメンバーを集める必要がある
各スクラムイベントにおいて開発者自らが提案したり考えたり助言したりする、いわゆるアウトプットの機会がとても多くなります。
誤解を恐れずに言ってしまえばプログラマーは他人とのコミュニケーションが苦手だったり、そこまでいかなくても可能な限り一人の世界で作業に没頭したい人が多いです。
もしそういった人をスクラムに招けば、よっぽど気の合うメンバーに恵まれない限り、強制的にアウトプットを求められる環境に耐えられずチームを抜けてしまう可能性が出てきます。
開発メンバーのレベルをある程度揃えなければいけない
例えば開発メンバーの中に突出してスキルの高い人がいたり、またそのプロジェクトに古くからいて仕様を熟知している人が極端に少ないケース。
これは結局チームがその人に依存してしまう可能性が非常に高くなり、負荷が高くなったり作業負担の不公平感が出るのでおすすめできません。
スクラムでない疎結合なプロジェクトならそれで良いかもしれませんが、肩を組み合うスクラムチームの場合、不公平感をなくさないとメンバーのモチベーション維持が難しくなっていきます。
初期の学習コストが高い
チームを組んで実際にイベントを回し、自律的なチームが完成するまで。
もしスクラムの経験がない or 浅いメンバーが集まった場合、スクラムとは？からはじまり、スクラムガイドのインプット、各スクラムイベント毎のPDCAを回し切るまでに時間がかかります。
最初はデイリースクラムの時間が15分を過ぎてしまう、レトロスペクティブが形式だけのものになる、スプリントレビューがただのお披露目会になるなど大小様々な問題が出てきます。
スクラムマスターが優秀であるほど完成までのスピードはもちろん早くなりますが、メンバーの癖や性格はチーム毎に異なるためどうしても成熟するまでに一定の期間は必要です。
スクラムイベントをうまく回すこと自体が目的になってしまう
スクラムガイドに沿ってやるべきイベントをこなす。これは指標があるというメリットの一方で教科書通り綺麗にやろうといういわば「手段が目的になってしまう」というデメリットにもなりえます。
そもそも自分たちは何のためにコストをかけてスクラムを導入し、毎スプリント走っているのか？それを見失ったまま日々のタスクをこなす状態になりがちです。
プロダクトゴールを達成することへのモチベーションを常に全員が維持し続けるのは本当に難しいと思う日々です。
スクラムが日本の開発現場に根付く可能性
これは完全に著者の見解になりますが、将来的にもアメリカほどスクラムガイド通りのチームは発生しないと考えています。
悪いことをはっきりメンバーに言えない
日本人の良いところであり悪いところでありますが、相手の悪い部分や直して欲しいことをはっきり言えない文化・性格があります。
そしてこれが問題になるのはレトロスペクティブです。
kpt法などで「良いところ」「悪いところ」を議論するわけですが、より肝心な深いところまではどうしても指摘し合うことができないだろうと予測しています。
レトロスペクティブの真髄は良いところを洗い出してキープすることよりも、悪いところを洗い出して改善することにありますがここがどうしてもネックになりそうです。
カスタマイズされたチームが普及するのでは
スクラムを日本に広げようとしたらそれを阻害する要因として、スクラムが日本の文化をベースに生まれたものではないこと、また誰しもがスクラムガイドを熟知するコストをかけられるのか？という点があります。
本来スクラムガイドを逸脱したカスタムは御法度なのですが、現状カスタマイズしてしまうチームが多くあるということを考えると、将来的にはスクラムというよりも「スクラムの考えを取り入れたチーム」もしくは「アジャイルっぽいチーム」が根付いていくと考えています。
もちろんスクラムガイド通りのチームも多く発生していくとは思いますが、日本人の文化・やり方にカスタマイズしてうまくプロジェクトを回しているチームも実際に見てきていますので大きく逸れた予想ではないのかなと思います。
スクラムが適合するチーム
逆にこんなチームならがっちりスクラムがはまりそうだな、という像を挙げてみます。
- ベンチャー気質で、全員が売上数値やビジョンへのコミット意識が高い
- 積極的なアウトプットが好きなメンバーが多い
- 個人的な損得よりもチームの成長を優先できるメンバーが多い
- 優秀なスクラムマスターを確保できる
- メンバー属性とスキルがある程度均一である
とくに1はプロダクトゴールへの意識、スプリントゴールへの意識に直結するところがあるのであえてわかりやすくベンチャー像を挙げてみました。
まとめ
スクラムは非常に完成度が高くかつチームのやり方に対してバッファを持たせた素晴らしいフレームワークです。
それゆえにカスタマイズしすぎないこと。自分のチームに合うかどうかを事前に把握することが大事だと考えます。
スクラムを無理やりチームに当てはめようとしてチームに歪みが出てしまっては本末転倒ですからね。
スクラムを導入するかご検討のリーダー、マネージャーの方の参考になれば幸いです。
