開発スパンが短く、プロダクトのリリースまで短期間で進められるアジャイル開発。
その中でも少人数で進めるスクラム開発の認知度は非常に高くなっています。
この記事を読んでいる皆さんの会社でも導入が始まった人もいるでしょう。
「スクラムマスターはいらないから、一緒に開発してくれと上司から言われた」
「メンバーからスクラムマスターが機能していないと言われた」
「スクラム開発である必要性は?と言われたことがある」
開発手法としてあまり浸透していないからこそ、スクラムやスクラムマスターの必要性について疑問が出ることは仕方ないのかもしれません。
では、本当にスクラムマスターはいらないのでしょうか?時折耳にする「スクラムマスター不要論」について一緒に考えてみましょう。
スクラムマスター不要論が出てくるときというのは、スクラム開発が上手にできていないことがほとんどです。
決められた予定通りに開発が進んでいないことはもちろん、これからお話しする4つのことが起きているとスクラム開発は失敗していると言えます。
1つ目は振り返りが機能していない場合です。
スクラム開発における振り返りはレトロスペクティブとも呼ばれ、開発が成功しようが失敗しようがなぜその結果となったのか徹底的に議論します。
仮に振り返りを実施していても形式的で内容が伴っていなければ振り返りを実践していないも同然。
間違ったやり方で振り返りをしていてはスクラム開発の意味がありません。
2つ目はスクラム開発における各種イベントに時間がかかっている場合です。
開発開始前のスタンドアップミーティングや日々のデイリースクラムはもちろん、先ほどお伝えしたレトロスペクティブも時間をかけすぎてはいけません。
こうしたイベントはあくまでメンバーが抱えているタスクや課題を短時間のうちに議論する場。
時間がかかっているのであれば何かがずれている可能性があります。
3つ目は従来の開発方法であるウォーターフォール開発になってしまっている場合です。
ウォーターフォール開発では作業の手順が決まっておりリリースまでに全ての機能を開発します。
一方、スクラム開発ではプロダクトの機能ごとにスプリントを組んで開発します。
「プロダクトが擁する機能を全て同時に開発せねばならない」という気持ちが残っていると、完全なスクラム開発には至りません。
4つ目はスクラムマスターの立ち位置が間違っている場合です。
スクラム開発においては個人がそれぞれ能力を発揮し、よりプロダクトを作れる環境整備が重要。
スクラムマスターはあくまでスクラム開発を機能させるための旗振り役でしかありません。
メンバーにタスクを振るなど管理者のようなふるまいは定義から外れてしまいます。
実は、スクラム開発において本当にスクラムマスターがいらない場面というのも存在します。
例えばプロダクトバックログという開発の優先順位やタスクが少ない場合は、スクラムマスターを置かない場合があります。
プロダクト開発の責任者であるプロダクトオーナー(PO)と密に連絡が取れるので、仲介者を挟む必要がありません。
また、メンバー個人の能力次第ではスクラムマスターが足を引っ張る可能性もゼロではありません。
優秀な開発メンバーがそろっている場合もスクラムマスターを置かないパターンもあり得ます。
先ほどの説明を読んで、「やっぱりスクラムマスターはいらないじゃないか!」と思うかもしれません。
しかし、スクラムマスターが不在でも機能する開発はごく一部。
これから取り上げる3つの課題が発生しているときはスクラムマスターがいないと開発は失敗してしまいます。
1つ目は優先順位が決められない場合です。
多くの開発ではスプリントの内容が複雑で、開発メンバーだけで優先順位を決められません。
開発の優先順位がぐちゃぐちゃで、なかなかプロダクトが形にならない場合はスクラムマスターが必要です。z
2つ目はスプリントバックログへの対応が不十分な場合です。
基本的にスクラム開発におけるスプリントバックログの管理は、開発メンバーのみでまかなえる量ではありません。
こうなると正しくスプリント設定ができず、トラブル発生時に上手に対処ができなくなってしまいます。
そのため、基本的にはスクラムマスターがスプリントバックログを管理し、メンバーが作業に集中できるように采配しています。
3つ目は開発メンバーが開発以外のことに時間を割いている場合です。
そもそもスクラム開発では少人数で開発を進めます。
個人が抱える業務量も責任も増えがちな一方で、スピード感のある開発が必要です。
スクラムマスターなしでスピード感のある開発というのは非常に難しく、開発以外の業務に時間をどうしても取られてしまいます。
開発に専念できる環境整備のためにもスクラムマスターは欠かせません。
今ご自身が抱えているプロジェクトにスクラムマスターが必要だと感じましたか?
必要なら、これから先「スクラムマスターがいなくてもいいや」と思われない動きをすることが重要。
スクラムが失敗していると思わせないためには4つのポイントを押さえて開発を進めるべきです。
1つ目はスクラム開発における各種イベントを充実させることです。
スクラム開発においてデイリースクラムやスプリントレビューなど各種イベントは重要である一方、すべてのイベントに全員が参加する必要があるかどうかは考えるべきです。
ステークホルダーは毎回イベントに参加するべきなのか、開発が滞らないようにスケジュールを組めているかなど、イベントが有意義な場になるよう調整してみてください。
こうした調整役もスクラムマスターの役目です。
2つ目はスプリントレビューでの議論を活性化させることです。
スプリントレビューでなかなか意見が出にくいことも起こりうるでしょう。
活発な議論を促せるようにスプリントレビューの目的を共有するのも重要ですし、匿名チャットなどを用いて意見を出しやすくするのも一つの手です。
3つ目はできないからと言って予定を延長しないことです。
「予定通りにタスクが終わらないなら、終わりそうな日まで延期しよう」は絶対NG!
なぜ予定通りに終わらなかったのかきちんと振り返り、次にまた同じ状況が起こらないようにすることが最重要です。
4つ目はモチベーション高く取り組める心理的安全性を確保することです。
良いチームとスクラムマスターがいればスクラム開発はスムーズに進みます。
こうしたチームの雰囲気を作るには忌憚なく意見交換ができる「心理的安全性」の確保が欠かせません。
心理的安全性とは心理学用語で、組織内で自分の意見を誰にでも発信できる状態を指す言葉。
頻繁に意見を交わすスクラム開発が十分機能するためにはこの心理的安全性の確保は必須です。
「ここまでスクラムマスターを頑張ったけど、もう無理!」
「スクラムとは関わりたくない」
スクラムマスターとして働くのが嫌いなってしまったなら、無理にスクラム開発に関わり続けなくても大丈夫です。
スクラムをはじめとしたアジャイル開発が増えてきたといっても、まだまだ従来のウォーターフォール開発を続けている会社は多いです。
事実、IT系のハイキャリア求人で多いのはウォーターフォール開発における上流工程を担う人材。
求人サイトdodaでもスクラムマスターの求人はプロジェクトマネージャー(PM)の求人数の10分の1以下です(2024年7月現在)。スクラム開発での経験も活かしながらPMとして再起を図るのもよいかもしれません。
ITハイキャリア向けの転職サイト・インテントキャリアではPMやプロダクトマネージャー(PdM)といった上流工程の求人を多数取り扱い予定です。求人掲載だけでなく、専属エージェントによる転職サポートも実施予定!
「一人で転職活動をするのが不安」という方も安心です。
スクラム開発における各種イベントが上手に機能せず、スムーズに開発が進まないと「スクラムマスターはいらないのでは?」と思いがちです。
しかし、実際はスクラムマスターがいないとより混乱を招く場合がほとんど。
スクラム開発を正常に機能させるために、やはりスクラムマスターは欠かせません。
スクラムマスターは不要と安直に結論付ける前に、まずスクラムマスターがしっかり機能できるように環境を見直してみましょう。
仮に「スクラム開発が嫌い」と思ってしまうのであれば、一度アジャイル開発で進めるプロジェクトから外れるのも一つの手です。
社内に従来のウォーターフォール開発をしているプロジェクトがあればいいですが、ない場合は転職も視野に入れてみてください。
ITハイキャリアでの転職を検討するなら、求人検索サイトの候補にインテントキャリアも入れてください!