スクラムマスター候補者の面接 (1)〜役割について

翻訳記事

本記事は、「Scrum Master Interview Questions (1): Scrum Master Role」の翻訳です。著者の Stefan Wolpers さんに許可をいただき翻訳・公開しております。誤字脱字、誤訳がありましたらご指摘ください。

TL;DR: スクラムマスター候補者への面接（１）
イントロダクション
スクラムマスターへの面接質問ガイドのトピック
1. スクラムマスターの役割の背景
スクラムマスターの役割についての面接での質問
結論
1. 関連記事
2. ✋ 見逃さないで！アジャイルのプラクティスコミュニティの詳細を学びませんか？8,000人以上参加の Hands-on Agile Slack コミュニティに参加しよう
本記事の翻訳者:

TL;DR: スクラムマスター候補者への面接（１）

スクラムは、ソフトウェア開発において最も一般的なフレームワークであることが何度も証明されてきました。「ソフトウェアは世界を食いつくす（Software is eating the world.）」から考えると、最近では、熟練のスクラムマスターの需要が高まっています。また、その需要により、1〜2冊のスクラムについての書籍を読むだけで十分であり、他のプロジェクト管理の派生からの新しい専門家の市場参入をもたらしました。あなたが適切なスクラムマスターの候補者を識別するために役に立つ質問集が必要となることを意味しています。

あなたの組織で、スクラムマスター（または、アジャイルコーチ）のポジションを探しているならば、以下の47のスクラムマスターへの面接での質問集が、適切な候補者を見極めるために役に立つかもしれません。47の質問集は、私の14年間におよぶ XP とスクラムの実務経験から生み出したものです。私は、プロダクトオーナーやスクラムマスターの両方を務めてきました。そこで、私のクライアントに代わって何十人ものスクラムマスター候補者を面接してきました。

イントロダクション

「アジャイル」はトレンドではなく、流行りなのかもしれません。いずれにしても、ソフトウェア開発においてスクラムが非常に人気があることは間違いありません。経験豊富なスクラムの実践者の需要と、新しい専門家の市場参入はともに増えていくばかりです。

組織のためにスクラムマスターの採用を検討しているのであれば、以下のような面接での質問が適切な候補者を見極めるために役に立つでしょう。これらの質問に対する候補者の返答の中で何を聴けば良いのかを把握しておくことで、面接担当としては、候補者のスクラムの知識だけではなく、候補者のアジャイルマインドを早く理解できるようになるでしょう。どのような組織にもアジャイルプラクティスを導入することの複雑さを考慮すると、スクラムマスターの候補者のアジャイルマインドセットを見分ける必要があるとき、複数選択式の問題ではほとんどが不十分と言えます。

スクラムマスター面接ガイドはこちらからダウンロードすることができます：

スクラムマスターへの面接質問ガイドのトピック

面接ガイドは、役割と作成物、プロダクトオーナーとの協働、スクラムのアンチパターンまで、8つのトピックで構成されています。この記事では、そのうちで最も大きなカテゴリーである「スクラムマスターという役割」を取り上げています。

スクラムマスターの役割の背景

スクラムは方法論ではなく、フレームワークである。1つ1つのシナリオに適用する規則があるわけではなく、かつての組織において以前にうまくいったグッドプラクティスにすぎない
他の組織のグッドプラクティスは、単純に自分たちの組織に複製することはできない。あらゆるグッドプラクティスには、特定のコンテキストが伴う
スクラムチームのメンバーは、自分の組織にとって何が有効なのかを自分たち自身で判断する必要がある。目的地ではなく、過程である。
スクラムマスターの役割は、主にサーバントリーダーシップとコーチングである。単なるマネジメント職ではない（組織内でのスクラムの推進や支援の責務などマネジメント的な側面もある。『スクラムガイド』の promoting and supporting Scrum を参照のこと）。
スクラムマスターは、スクラムチームの成熟段階によってティーチングや、コーチング、メンタリングなど異なるアプローチが必要であることを認識すべきである。
スクラムマスターは、新しいテクニックを身に着けるために守破離（Shu-Ha-Ri）を知っているべきである。
スクラムマスターの主な目的は、スクラムチームの自己組織化によって、日常業務から彼ら自身を取り除くことである。
スクラムマスターであることは、プロセスを強制することを意味しないし、決してそうすべきではない。
スクラムは、官僚的であっったり、数値規制を置くように設計されているわけではないが、スクラムチームの健全性を理解するのに役に立つメトリクスはある。一般的に、チームが、予測 v.s. ベロシティなど、特定の KPI を達成することを主張しても何も役に立ちません。
スクラムでは、フィーチャーのような価値があり、利用可能で、実現可能な作業アイテムをプロダクトバックログに追加するプロセスについて詳しく説明はしていない。デザイン思考、リーンスタートアップ、リーンXPのフレームワークを用いたプロダクトディスカバリーは役に立つ。いずれにしても、良いスクラムマスターは、スクラムチームがユーザーインタビューや実験するといったプロセスに取り入れることを望むだろう。
スクラムチームとステークホルダーとの対話は、門番を介して（例えば、PO を介してなど）行われるべきではない。それをすると透明性を損ない、チームのパフォーマンスに影響がでてくる。スプリントレビューは、ステークホルダーと緊密な連絡が取り合え、各スプリントでスクラムチームが提供した価値を提示するよい方法である。

スクラムマスターの役割についての面接での質問

質問1. スクラムマスターは、矛盾していないか？

アジャイルマニフェストでは、「プロセスやツールよりも個人との対話」に価値をおいています。プロセスを"強制" する役割であるスクラムマスターは、矛盾していませんか？

スクラムマスターは、権力を振りかざすのではなく、サーバントリーダーととして振る舞います。スクラムチームは、スクラムマスターへの報告義務はありません。この質問は、スクラムマスターの候補者が自分の役割はチームを管理監督することではなく、チームを導くことだと理解しているかどうかを明白にしてくれます。また、候補者がそもそもスクラムマスターの役割に関心をもっている動機も明白になるでしょう。

受け入れることができる返答とは、ファシリテーションや支援を強調するものです：

「私は、スクラムチームのサーバントリーダーです。チームの成功に貢献することが私の仕事です。」
「私は、プロジェクトマネージャーでもピープルマネージャー（訳注: 人事権のある管理職）でもありません。私は、スクラムチームが自己組織化に到達できるように支援します。私は、チームメンバーに何をするべきかを指示しません。」
「私は、スクラムチームのファシリテーターです。チームが優れたチームになるように教師として、コーチとして、メンターとして励ましています。」

質問2. 「アジャイル」の成功要因

あなたの組織でアジャイルプラクティスが役になっていることを示す指標には、どのようなものがありますか？また、どのような効果が成功していることを示す指標はどれでしょうか？

組織のアジリティを測定するために用いる「アジャイルの成功」の標準的な定義や一般的な定義はありません。すべての組織は、独自の基準をつくらなければなりません。チームのベロシティの向上は通常は意味のある指標とは考えられていません。

しかしながら、ほとんどが間接的ですが、成功の判断としてさまざまな指標があります：

顧客に提供したプロダクトが、結果的に定着率を高めたり、コンバージョン率を高めたりしている。顧客の生涯価値を向上したり、ビジネスの改善につなげることができた（成功するスクラムチームはビジネスによい費用対効果をもたらす）。
組織的なアジリティの改善により、以前はムダだと思われていたマーケット機会の追求を成功することができるようになった。
価値の低いプロダクトへのリソース配分を減らすことができた。
検証済みのアイデアがプロダクトとしてリリースするまでのリードタイムを短縮できた。
仮説検証のサイクルタイムが短縮できた。プロダクトディスカバリーのプロセスが迅速になった。
チームの幸福度の向上により、離職が減り、チームメンバーからのリファラル採用が増えた。
人材争奪戦での競争力の向上により、組織に参加したがる経験者の数が増えたことが実証できた。
ソフトウェア品質の向上により、技術的負債が大幅に削減でき、バグが少なくなり、保守にかかる時間が短縮できることが実証できた。
プロダクトを提供するチームに対するステークホルダーからのリスペクトが高まった。
スプリントレビューなどのイベントへのステークホルダーの参加が増えた。

質問3. 妨害要因の除去

スクラムマスターは、スクラムチームに代わって妨害要因を取り除くべきでしょうか？

スクラムマスターは、スクラムチームが自分たちで解決できる問題を取り除くことについて、こだわるべきではありません。これは、求人要件にそれが記載されていたとしてもです。スクラムマスターが「スクラム過保護（Scrum helicopter parent）」として振る舞うようだとスクラムチームは決して自己組織化されません。

スクラムチームは、自らの判断し、学ばなければなりません。これは、チームが新しい何かを学んでいるときには、ほとんどの場合、失敗や行き詰まりや、無計画な実行における結果を伴います。よって、最初のうちは、チームがスクラムマスターからより多くのガイダンスを受けることになります。オフラインボードを作ったり（質問31と32wp参照）、Jira のチケットを更新することで、例示されるのとは異なる種類のガイダンスが必要となるということです。しかしながら、このようなガイダンスは、過保護な子育てのエクササイズになってはいけません。チームは、失敗から学ぶことを許容されなければなりません。

そうは言っても、スクラムマスターがチームに代わって問題を取り除く部分もあります。例えば、問題が組織的な問題である場合です。スクラムチームだけでは、これらは解決できないです。今の話題は、「妨害要因」についてです。この状況に限っては、スクラムマスターは、スクラムチームの妨害要因を取り除く役割を担えます。

質問4. スクラムマスターとプロダクトオーナーの対話

スクラムマスターは、どのようにプロダクトオーナーと対話をするべきですか？

スクラムマスターがプロダクトオーナーの協力を得るためには、正直で、オープンに対話をすることが一番です。スクラムマスターもプロダクトオーナーもどちらも権威を持たず、サーバントリーダーとしての役割を果たすべきです。それぞれがスクラムチームの成功（例えば、スプリントゴール）のために互恵的に働くことに依存します。スクラムマスターもプロダクトオーナーも、組織がアジャイルになり、アジャイルであり続けるようにコーチングするという点で味方です。

プロダクトオーナーには、プロダクトの問題について迅速にフィードバックを行い、目標を明確にし、プロダクトのビジョンをプロダクトデリバリーのチーム全体が理解できるようにする責務があいます。

スクラムマスターには、その代わりに、価値が高く、実行可能なプロダクトバックログの作成をするプロダクトオーナーを支援します。そのためにプロダクトオーナーとスクラムマスターの間で効果的な協働を促進する必要があります。

質問5. プロダクトディスカバリープロセス

スクラムチームは、プロダクトディスカバリープロセスに関わるべきですか？そうならば、どのように関わるべきですか？

スクラムチームが早期にプロダクトディスカバリープロセスに関わるべき理由は主に2つです：

エンジニアが、プロダクトディスカバリープロセスへ参加するのが早ければ早いほど、技術的に実行不可能であったり、投資対効果が低かったりするソリューションを追求してしまう機会が少なくてすみます。
スクラムチームが早期に参加できることで、チームとプロダクトオーナーは、何を開発すべきかについて共通の理解とオーナーシップを確率することができます。

これは、適切な課題に対してリソースを配分し、顧客にとっての価値を最大化し、未完了で価値の低い作業量を最大化することによって投資リスクを軽減することに役に立ちます。

プロセスの早い段階で開発チームのメンバーが参加することは、メンバーの同意を確実に得ることにつながります。また、プロダクト開発のすべてのフェーズに参加する意欲をチームが持つことにもつながります。これは、スプリントやプロダクトリリースごとに定義するスプリントゴールを達成するために必要な変化をするためのモチベーションになります。

質問6. プロダクトオーナーへの支援

プロダクトオーナーの役割が設計上のボトルネックになっています。プロダクトオーナーが価値を最大化するためにどのような支援を行いますか？

この質問は、前述の問題を再考したものになります。ここでも、スクラムマスターの候補者は、プロダクトディスカバリープロセスの早期の段階からスクラムチームに参加してもらうことが、プロダクトオーナーと組織のどちらにとっても有益であるかについて理由を説明することに集中しましょう。

さらに、スクラムマスターは、プロダクトバックログリファインメントのプロセスが継続的であり、プロダクトバックログに関して価値の高いものであることを保証することにより、プロダクトオーナーを効果的に支援することができるでしょう。「garbage in, garbage out」（訳注: 無意味なものを入力すると、無意味な結果が返される）は、スクラムでも当てはまります。本質的には、スクラムチームは、共に勝利するか、共に敗北するかのどちらかなのです。

質問7. ステークホルダーへの接触

スクラムチームがプロダクトのステークホルダーに接触できるようにするにはどうしたらよいでしょうか？

この質問に答える際には、スクラムマスターの候補者は、ステークホルダーへの接触を確保することが簡単にはできないことを説明するべきです。

チームメンバーが、ステークホルダーに接触することを効果的に制限していることも多いです。例えば、大きな組織では、機能的なサイロや、予算編成とガバナンス、組織の階層構造によるものです。この組織的な負債を克服し、参加者全員の信頼を築くことが、スクラムマスターの最大の目的になります。

スクラムマスターの候補者は、効果的（透明性があり、役に立つ）な対話を行うようステークホルダーに働きかける提案をするかもしれません。スプリントレビューは、そのための有用な場になります。相互作用により異なる部門やビジネスユニット間のより良い関係を促進することがよくあります。

質問8. ステークホルダーとアジャイルマインドセット

部門の垣根を越えて、組織全体でアジャイルマインドセットをどのように推進していますか？また、それを追求するために、ITに不慣れなステークホルダーをコーチングするときの戦略は何かありますか？

スクラムマスターが、スクラムを用いてステークホルダーを巻き込むために使える戦術にはさまざまなものがあります。以下はその例です：

最も重要なことは、スクラムマスターは、『スクラムガイド』の原則とアジャイルマニフェストと共にあり、啓発しなければならない。プロダクトの構築に関わる組織内の全員に対して話をするべきである。そして、何をしているのかを透明にしておく必要がある（参照: 「 10 Proven Stakeholder Communication Tactics During an Agile Transition.」）。
プロダクトチームとエンジニアリングチームは、スクラムによってアイデアからプロダクトローンチまでのリードタイムを大幅に短縮できることをステークホルダーに証明できるエビデンスを用意することができる。
プロダクトチームとエンジニアリングチームは、スクラムによってリスクを軽減できる（つまり、新機能がいつ利用になるのかを予測できる）ことを実証し、その結果として、他の部門の計画と実行における成功に貢献できる。
スクラムチームは、チームの活動や進捗状況を伝えるスプリントレビューやそのほかのイベントにステークホルダーを招待することで、自分たちの仕事に対する透明性を保ち、ステークホルダーを積極的に巻き込めるようになる。
組織内の全員、特にステークホルダーを対象とした研修が大切である。実践的なアプローチのひつととしては、非技術者の同僚に対してアジャイルのテクニックを教えるために設計したワークショップを開催することだ。

質問9. スクラムとシニアエグゼクティブ

シニアエグゼクティブにスクラムをどう紹介しますか？

これは議論を促すために意図的にオープンな質問にしています。この質問に返答することで、スクラムマスターの候補者は、どのようにしてアジャイルマインドセットを組織全体に広めていくのかや、理想的にはどのように広めていくべきかを詳しく説明する必要がでてきます。さらに具体的には、顧客にとってベストなプロダクトを見極めるために、実験を受け入れる学ぶ組織をどのようにして作っていくのかを説明する必要がでてきます。

良い候補者は、ステークホルダーの心を掴むために、組織にアジャイルを「売り込む」必要性について話す可能性が高いでしょう。また、変革のスポンサーとなるより高位のエクザクティブを見つける必要性を指摘することでしょう。

移行時の初期には、どのような組織でも変化への慣性が働くので、この抵抗を克服するためには、エグゼクティブやステークホルダーがコミットする前に、まずスクラムがどのように彼らにとって恩恵をもたらすのかを知ってもらう必要があります。どのようにステークホルダーに対してアジャイルマインドセットを発表するかは「The Big Picture of Agile」も読んでみてください。

シニアエグゼクティブに対して、スクラムを紹介する際の実践的なアプローチのひとつは、上位のマネジメント層に対してワークショップを開催することです。エグゼクティブ層へのスクラムの導入は過去にもうまくいっています。スクラムチームとして組織化できれば、エグゼクティブや可能性のある主要なディレクターであっても、アジャイルプラクティスを直接経験することだってできます。

この質問に対しての返答は、正解も不正解もありません。グッドプラクティスは、組織の文化、規模、プロダクトの成熟度、法的な要件、コンプライアンス要件、そして、それらが運用されている業界を考慮しなければなりません。

質問10. ステークホルダーの抵抗を克服する

プロダクトのステークホルダーには、あなたがスクラムの研修を実施したとしましょう。スクラムの概念を採用しようとする初期の段階のあとで、最初の大きな妨害に遭遇したら、ステークホルダーの何人かは採用に対して抵抗をし始めるでしょう。このような状況に対応するための戦略や経験を教えてください。

この質問では、組織内スクラムへの抵抗を克服する際に学んだことや、スクラムについての意見交換をすることを狙いとしています。多くの組織で共通するアジャイルの失敗パターンに精通していることは、スクラムマスターの候補者の経験を表します（アジャイルの失敗パターンについては、「list of several agile failure patterns」をご覧ください）。

スクラムマスターの候補者は、アジャイルプラクティスへの移行において、中間マネージャー（中間管理職）が直面する特殊な課題にも精通している必要があります。人を管理して何をすべきか指示を出す「コマンド＆コントロール」スタイルから「サーバントリーダーシップ」スタイルに移行するということ（要するにテイラー主義を放棄すること）は、すべての人に当てはまるわけではありません。参考: 「Why Agile Turns Into Micromanagement」

結論

これらの面接での質問は、経験の浅い面接担当者をアジャイルソフトウェア開発のエキスパートにすることを意図しているわけではありません。しかし、経験豊富な実践者の手にかかれば、これらの質問は、スクラムマスターの候補者の中で誰がアジャイルの現場で実際に成功しているのか、または、ニセモノなのかを判断する十分な手助けとなるでしょう。

スクラムマスターの役割について、スクラムマスターの候補者にどのような質問をしていますか？コメントで共有してください（訳注: コメントは原文に英語でするか、この投稿へのリンクを添えて Twitter や Facebook で日本語で共有してください）。