「スクラムマスターを雇うときに聞いてみるとよい38個の質問」に自分なりの考えを持って答えてみた

「スクラムマスターを雇うときに聞いてみるとよい38個の質問」に自分なりの考えを持って答えてみた

「自称スクラムエンジニア」こと、メンバーズエッジでエンジニア兼スクラムマスターをやらせてもらっている早坂です。

以前、スクラムマスターを雇う時に聞いてみるとよい38個の質問を見かけて自分もどこかのタイミング答えたいなー、と考えていましたが機会をいただけたので書こうと思います。

アイキャッチ画像はScrum Primer様よりお借りしました。

はじめに

自分なりに考えた結果生まれた答えであり、妥当性はないと思っており、1つくらいは読んでいる皆さんの参考になれば幸いです。

スクラムマスターの役割について

アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか?

「プロセスを守らせる」という強制行為はスクラムマスターには与えられていない、且つ、そもそもチームがよりよい状況を見出すための1手段として私は捉えています。

宣言にも書かれていますが「左記の事柄より右記の事柄に価値をおいている」だけであって、どちらが重要且つ迅速に進められるかはチームで採択するものと考えます。

自分の組織でアジャイルがうまくいっていることを示す兆候は何か?また自分の働きが成功している兆候は何か?

組織でアジャイルがうまく行っていることを示す兆候は「会話が多く生まれ意思決定が早い」点かと思います。

「自分の働きが成功した!」という実感はあまりないですが、私もチームメンバーの一人として働いているのですが、「チームで取り組む事柄の意思決定が早く、取り組んだことのフィードバックを速く多く得よう」としている状態になっていることがチームにとって良い兆しになっているのではないかと思います。

追跡しないといけないメトリクスはあるか?もしそうだとしたら何の目的でどのメトリクスを追跡するか?

「チームが時間を何に割いているのか」を私は気にすることが多いです。

ベロシティで計測できるのはチーム内の活動に限られますが、それ以外の観点で見るとなるとどうしても時間を見てしまいます。

「チームがプロダクトの開発に使える時間=顧客へ提供可能な時間(製品を作る時間)」と考えており、作ったものが顧客の価値提供へとつながりやすいので「時間」をメトリクスとしています。

あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか?そして問題をどのように指摘するか?

チームの状況によるかもしれませんが、まずはコミットメントを達成できるスキルを備えているかを俯瞰します。

振り返りや普段の開発のススメ方など、チームの活動を確認しながら顧客からフィードバックを得ます。

「チームが提供する製品と顧客が要求するもの」を照らし合わせ「何が課題になっているのか」を考える時間を作ると思います。

製品のディスカバリープロセスにスクラムチームは参加してよいか?その場合はどのようにするか?

「参加して一緒に製品の未来を想像しよう!」という感じで誘うと思います。

弊社の事業形態に由来する部分も多いのですが、弊社は「エンジニアチーム」として活動することが多いので、チームメンバー全員が同じ視点・方向を向いていないと、チームが提供できる価値を最大化できないと考えているので、同じ未来を見てもらうように常に意識して取り組んでいます。

設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか?

「何がボトルネックになっているのか」は時と場合により変わると思いますが、もし交渉力がなく返されてしまうといったことであれば、チーム全員が交渉するためのものを作ると思います。

もしくはアプローチを変更(例えばDevOpsを採用・推進するとか、スクラムの浸透から行うなど)してプロダクトオーナーがボトルネックにならないような「なにか」を状況把握を行った上でサポート方法を考え実施します。

どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか?

「ステークホルダーにアクセス出来ないと仕事がやりづらく、成果も出しづらくなる」と言うことを前提に話をします。

「成果を共に創出する」ことを前提としていることがほとんどなので、ステークホルダーと話ができない場面がほとんどないかもしれないです。

どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか?ITじゃないステークホルダーをコーチするのにどんな戦略をとるか?

私は地道に一人ずつ仲間を作ります。

めったにいないのかもしれませんが「現状の仕事への取り組み方に満足しておらず、仕事に熱い想いを持った人」を巻き込んでスモールチームでスタートし、業務改善から取り組みます。

「自分たちのやり方で何が悪いのかわからない」とか「忙しいからやり方を変えられない」とかいろいろな意見が出るのですが、どんな人でも私の場合は一緒にご飯食べたりお酒を飲みに行ったりして、時間を共有し思いを聞き出し巻き込むようにしてます。

上級管理職にどのようにスクラムを紹介するか

「スクラム」を紹介するよりは「問題の早期発見・改善をするならスクラムを導入してみては」という伝え方をすると思います。

スクラムは手段の一つと考えているので「アジャイルにしていきたい」のであれば「スクラムというやり方もあるよ」という感覚で話をします。

あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか?またどんな経験があるか?

過去にあったのは「自分たちが取り組んでいるのはスクラムではない」と発言があったのですが、そのときは「スクラムはチームの状況によって取り組み方やアプローチを変える必要がある。あなたが過去のチームで経験したことは重要な経験だと思うので、あなたの経験を是非このチームで活かしてほしい!」という話をしました。

経験の差がチーム内にあるのであれば、「スキル差を埋める何か」を打診します。

プロダクトバックログのグルーミングと見積りについて

プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか?

多少の前提はありますが純粋に「良い」と思います。

前提として必要なのは「ステークホルダーとPOの意思・未来が整っている」ことで、整っていれば余計な交渉がチーム、PO、ステークホルダー全てに発生しないためです。(かなり稀な状態だと思いますが…)

チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか?

チームが何を知りたいのかを明確にします。

明確にした上で「チームに最新情報やマーケット状況を教えてほしい」と要求します。

そうでないと一般論でしか議論ができないと思うので。

誰がユーザーストーリーを書くとよいか?

プロダクトオーナーとチームだと思います。

よいユーザーストーリーとはどんなものか?どんな構造か?

具体的に書かれているのが良いと思います。

なので、前設問にもかかりますが、具体的に書けるのであれば誰でも良いとは思います。

「Readyの定義」には何が含まれているべきか?

ゴールが含まれ、且つ明確化されているのが望ましいと思います。

ユーザーストーリーを時間で見積もらないのはなぜか?

人にスキル差があったりで、かかる時間が異なるから。

という反面、時間の話を前の設問でしていましたが、時間で見積もっても良いのかなと思ってます。

ものを作ることも大事ですが、ユーザーストーリーはアイディアを出すことも必要なのではないかと最近感じているので。

プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか?スクラムチームは200個のチケットに取り組めるか?

結果的にすべて取り組むことになると思います。

ただ、前段に有益なものかどうかをユーザーストーリーなどと照らし合わせて取り組む必要性を見出します。

スプリントプランニングについて

チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか?

「優先度とどれだけ(体外的な)影響があるのか」を確認すると思います。

影響度はどれだけのユーザーにリーチするのか、とかそういった視点です。

一概には言えないですが「エンジニアも作ったものは使ってもらえると嬉しいし、次の開発でも意欲的に楽しい状況」になってもらえると感じるためです。

ユーザーストーリーの価値をどんなメトリクスに基いて判断するか?どんなメトリクスは受け入れがたいものか?

受け入れがたいものはないかもしれません。

ただ、チームは「売上」といったお金のところを強く意識はしないと思うので、直接的な表現ではなく間接的な(n人のユーザーが今使ってるっぽい!とか)表現にしたほうがいいかもしれない、と最近感じます。

チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか?

聞き方はどうあれ「ユーザーにとって価値の高いものはどれですか?」と直接聞くと思います。
選ぶのはPOだし、それを一番理解しているのがPOでもあるので、チームがわからないことはシンプルに「わからない」といいます。

どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか?

スプリント期間の2割から3割程度の時間だと思います。
リファクタばかり、バグ修正ばかりしてたのでは本来やりたいであろうプロダクトの開発ができないので。

チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか?

なぜ個人に固執しているのか聞き出す。

聞き出した結果個人で分配するのが妥当なのかチームにも検討してもらう。

その結果を持って何が最良なのかお互いで考えさせる。

チームメンバーによるタスクのつまみ食いをどのように扱うか?

「タスクのつまみ食い」がスプリント外のタスクなどを指しているなら、振り返りのときに指摘する。

ひどい場合、朝会の場で「スプリントバックログの重要性」を再認識する場を設ける。

ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか?

ユーザーストーリーが明確になってない以上、入れてもらわない。

もしチームが入れても良いというなら、最低限対象が誰向けに作るものなのかを明確化する。

スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか?

参加したくない理由、時間が無駄だと感じている理由をまず聞き出します。

その後の行動は聞き出した内容により変わります。

スタンドアップやデイリースクラムについて

チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか?

薦めます。

が、チームの状況が悪いもしくは、スクラムに取り組んでいない場合は話す内容や取り組み方を変えて取り組んでもらうよう心がけます。

なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか?

即座に相談できる状況があるなら、次のスタンドアップまで待つ必要はないと思います。

行動しない限りはアジャイルになれないし、アジャイルを目指すならなおさら即座に解決していけることを望みます。

ですが、中には自分のスキル成長のために調べて試すといったことをしたい方もいると思います。

その場合は自ら助けを求めるかスタンドアップで話が出ることを待ちます。

スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか?

疑問に感じたことに対し質問すると思います。

質問と言っても「ごめんなさい、自分ももっとよく知りたいので具体的な状態を教えてくれませんか?」のように少しずつでもいいから引き出していくと思います。

スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか?

遅刻することと無駄だと感じているその背景を教えてもらいます。

その上で無駄だと感じている部分で改善できる部分があれば改善(具体的には話す内容や取り組むことの改善)をします。

遅刻してしまう理由が「朝弱い」というものであれば午後にずらすなど。

スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか?

スタンドアップミーティングの必要性を説明し、スクラムチーム全員の理解を合わせます。

参加者が忙しいといったこともあると思うので、開始時間を変えるなどをしてみると思います。

もし、本当に意味のない場になっているならば、観察し機能しているのかどうか確認します。

分散チーム間のスタンドアップをどのように進めるか?

まさに他拠点に分散してますが、TV会議ツールを頻繁に使ってます。

我々のチームはチームの中で常時接続を行い、あらゆる活動をしています。

スクラムチーム用の物理カンバンボードをいま書いてください

すみません、諸事情によりサクッと準備できないので後日更新します。

ふりかえりについて

だれがふりかえりに参加してよいか?チームだけか?プロダクトオーナーも参加してよいか?

参加して良いと思います。というか参加してほしい。

スプリント中にリリースした機能などがどのような成果があったのか知ることができるとチームの活動がもっと活発に、よりよいものを作ろうとする意識が芽生える可能性があるため。

ただし、いきなり売上数値を持ってこられても困惑するので、参加の仕方を事前にすり合わせると思います。

チームが健全な状態かをふりかえりの中で確認するか?それとも不要か?もし必要だとするとどうやって確認するか?

します。

健全じゃない場合は相手を攻撃するような発言が多く見られるので、そのような発言が出た場合はまず「誰のためにふりかえるのだっけ?」と問いかけます。

それでも理解してもらえてないようであれば、ふりかえりについて説明し直し理解を合わせるよう務めると思います。

過去に使ったふりかえりのフォーマットはどんなものか?

KPT、YWT、FDL、タイムラインくらいです。

どうやってマンネリを防いでいるか?

やり方によるマンネリ化よりは、同じ問題をずっと放置し続けたりすることで発生することが多いので、1つずつでもいいので確実に問題を解消できるようにしてもらいます。

やり方のマンネリ化であれば、時たま違うやり方を入れてみるなどやり方そのものを変えます。

チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか?

具体的なゴールが明確になってない可能性が考えられます。

もしそうであれば、具体的なゴール(ユーザーストーリー)を明確化したり、スプリント内の「完了の定義」を明確にするようアドバイスすると思います。

どうやってアクションアイテムのフォローアップを薦めるか?

次のレトロスペクティブのときに具体的な効果はあったのか、継続する必要性はあるのか、といった点を確認すると思います。

最後に

書いてみて感じましたが、いくつかまだ強制しているかもしれないなぁ、といった点を見つけることができ、自分を振り返るいいきっかけになりました。

スクラムマスターとしてはまだまだ未熟ですが、そんなスクラムマスターが所属する弊社に入社してみたい、または話を聞いてみたいと考えている方がいましたら、下記応募ページから「カジュアル面談」の応募をお待ちしております。

楽しくプロダクト開発できる仲間を弊社では常に待っております。

お問い合わせ

チーム型プロダクト開発やスクラム導入に関するお問い合わせは下記ページよりお気軽にお問い合わせください。