アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (4)

みなさんこんにちは。@ryuzeeです。

弊社ではアジャイル開発、スクラムのトレーニングを提供しているのですが、トレーニング中には多くの質問をいただきます。今日はよくある質問とその答えについていくつかご紹介したいと思います。

なお、過去3回のものは以下になります。

■ スクラムマスターはスクラムチームには必ず1人で2人以上はダメですか？

スクラムガイド（日本語版）ではロールの人数について以下のように言っています。

プロダクトオーナーは委員会でなく1人の人間
開発チームは3人から9人が最適

一見するとスクラムマスターの人数は決まっていなさそうですが、スクラムガイド英語版を見ると、「A Scrum Master」の記載があります。つまりスクラムマスターの人数は1人です

スクラムマスターがチームに対してどのような支援をするかはチームの力量や置かれた状況によって大きく異なります。自己組織化していてチームが機能しているのであればスクラムマスターの関与は少なくて済むので、1人のスクラムマスターが複数のチームを支援することもあります。

■ 複数チームのスクラムマスターをしているとき、すべてのチームのイベントに全部参加しなければいけませんか？

これもスクラムガイドを確認してみましょう。要約すると以下のようなことが書かれています。

スプリントプランニング
- スクラムマスターは参加者に目的を理解してもらうようにする
- スクラムマスターは、スクラムチームにタイムボックスを守るように伝える
- スプリントプランニングでは、スクラムチーム（プロダクトオーナー＋開発チーム＋スクラムマスター）がスプリントゴールを設定する
デイリースクラム
- スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする
- デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、開発チームの邪魔にならないようにスクラムマスターが配慮する
スプリントレビュー
- スプリントレビューでは、スクラムチームとステークホルダーがスプリントの成果をレビューする
- スクラムマスターはスプリントレビューが確実に開催されるようにして、参加者には目的を理解してもらうようにする
- スクラムマスターは関係者全員にタイムボックスを守るように伝える
スプリントレトロスペクティブ
- スクラムマスターは、このミーティングがポジティブで生産的になるようにする
- スクラムマスターは、全員にタイムボックスを守るように伝える
- スクラムマスターは、スクラムのプロセスを説明するために、チームメンバーとして参加する

つまり、スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブにはスクラムマスターが必要ですが、デイリースクラムは開発チームが自分たちでうまくできているなら必須ではないことになります。

■ プロダクトオーナーは1人だと単一障害点になると思うのですが、なにか対策をするのでしょうか？

プロダクトオーナーは委員会ではなく1人の人間であると明記されているとおり、単一障害点になりやすい存在です。たとえば、プロダクトオーナーが忙しすぎてイベントへの参加が不安定になったり、開発チームからの質問に答えられなくなったりすると開発が順調に進まなくなります（開発チームが忖度して進めた結果、意図しないものが出来上がることもあります）。

このような状況を防ぐには、プロダクトオーナーにプロダクトオーナーしかできない仕事をしてもらうように、抱えている仕事を棚卸ししてほかの人にやってもらうようにしたり、スクラムマスターや開発チームがプロダクトオーナーのサポートをするようにします。

スクラムチームとして成果を上げるには、プロダクトオーナーが機能することが前提になるので、スプリントレトロスペクティブなどでプロダクトオーナーが抱えている問題を明らかにして改善していくとよいでしょう。

■ イベントを固定するということはイベント日には休暇が取れないように思うのですがどうしたら良いですか？

休暇が取れないことはないですが、なんとなく取りにくい気がしてしまうのはそのとおりだと思います。特にプロダクトオーナーがスプリントプランニングやスプリントレビューの際に不在だとプロダクトの舵取りが行われなくなってしまうので、できる限りイベント日はほかの予定を入れないようにするのが理想です。

とはいえ、休暇取得が必要なこともあるので、そのようなときには事前にプロダクトオーナーの代理の人を設定したり（この場合、代理の人の決定にあとから文句を言うのはナシです）、それがどうしても難しい場合は、イベント日をずらすなどの対応を行います。ただし、これが頻繁に起こるようであれば、そもそもイベントの曜日や時間の設定に問題があったり、プロダクトオーナーの人選に問題があったりする可能性があるので、問題を深堀りして対処していなかければいけません。

■ プロダクトオーナーが強い場合、弱い場合にどういうことが起こりますか？

たとえば会社の創業者や役員の人がプロダクトオーナーをするような場合、開発チームのメンバーもスクラムマスターもその人に対して意見を言いにくいということがあります。この場合、適切なフィードバックループが働きにくくなり、ひどい場合にはアイデアやプロダクトが良いものだと思っているのはプロダクトオーナーだけで、開発チームはうまくいくと思っていないというような不健全な状態になります。どうせ意見を言っても取り入れられないと感じてしまうと、学習性無力感が蔓延していきます。これでは結果はでません。

一方でステークホルダーが強く、プロダクトオーナーが弱い場合には、ステークホルダーの言いなりになってしまうこともあります。この場合プロダクトオーナーに確固たる考えがないので、プロダクトバックログアイテムの並び順や内容は、声の大きい人の順番になり、結果的にプロダクトの軸がぶれたり、そもそも顧客の問題を解決できない役に立たないプロダクトが出来上がったりします。

プロダクトオーナーは一定の権限と、ステークホルダーとのコミュニケーション能力、そして必要に応じて「No」と言える能力が必要です。

■ 新しいプロダクトの開発を始めるとき、技術的な調査も含めて長い時間がかかるように思うのですが、調査が終わってからスプリントを開始するのでしょうか？

スプリント開始前の助走期間が長すぎるのもよくないので、スプリントの準備期間は長くても1月くらいにするのが一般的です。準備期間中にやるべきなのは、最低限スプリント1を始められるくらいのプロダクトバックログアイテムを用意することです。つまり上位のプロダクトバックログアイテムを実現するのに必要な調査を優先し、それ以外はスプリントを回しながら調査していくようにします。

初期に長期の時間をとって全部を詳しく調査するのはムダになる可能性が高いです。なるべく早いスプリントでステークホルダーからフィードバックを貰えるようになるのが理想です。初期フェーズの始め方についてはこちらの記事を参照してください。