はじめに
SHIFT ASIAでプロジェクトマネージャー/スクラムマスターを務めているSONICです。
プロジェクトでスクラムの活用を検討されている方は多いと思いますが、スクラムにおける一つの役割である「スクラムマスター」はその責任と役割がつかみづらく、実はスクラムの運用において混乱をもたらしやすい要素の一つでもあります。
実際に、私もこれまでに多くのプロジェクトでスクラムマスターを担当してきましたが、特に経験が浅かった時期には、スクラムマスターが何を「最低限」果たせばプロジェクトがうまく進むようになるかがいまいちピンと来ず、プロジェクトが円滑に進行しないということを何度か経験してきました。
また、インターネットや書籍などでスクラムマスターの責任や役割について調べても、それらの情報が列挙されているだけで、知識として理解することはできても、実践の場において具体的にどうすればプロジェクトがうまく進行するようになるのかがなかなかつかみきれませんでした。
この記事を訪れた皆さんのなかにも、スクラムについて学んだ上で実際にプロジェクトに導入してみたものの、同じようにスクラムマスターの責任や役割がはっきりしないまま、プロジェクトを混乱させてしまったという経験をお持ちの方もいらっしゃるのではないでしょうか。
私自身も何度も課題にぶつかりながらも、開発プロジェクトにおけるスクラムマスターの経験を積み重ねる中で、その責任と具体的な役割をどのように捉えればプロジェクトがスムーズに進むようになるかについて、自分なりの答えを見つけることができました。
そこで本記事では、スクラムマスターの責任と具体的な役割が分からず悩んでいる方や、あるいはこれから初めてスクラムマスターを任されるという方に向けて、プロジェクトを円滑に進行させるためにスクラムマスターが負うべき責任と具体的な役割について、私自身の経験や考えと合わせて詳しく解説します。
本記事が、スクラムマスターを担当する方や、これからプロジェクトにスクラムマスターを選定・任命しようと検討されている方々にとって、少しでも有益な情報となれば幸いです。
なお、本記事ではスクラムに関連する専門用語が多く登場するため、スクラムについておさらいしたいという方は以下の記事も併せてご参照ください。
スクラムとは｜スクラムの定義や特徴、体制とチーム内の役割
スクラムイベントとは｜スクラムにおけるスプリントと4つのイベント
スクラムの3つの作成物｜プロダクトバックログ、スプリントバックログ、インクリメントについて
スクラムマスターの責任とは
スクラムマスターの責任とは、チームにスクラムフレームワークの土台を導入し、チームが自律的にスクラムサイクルを回せるようにすることにあります。
スクラムとは複雑な問題や前提の変化に対応し、価値を提供し続けるための適応型のソリューションであり、以下で示す通り、スクラムも基本的にはPDCAサイクルと同じフローとなっています。
- Plan：スプリントプランニングによってスプリントバックログという一定期間内の計画をつくり、
- Do：実装し、
- Check：デイリースクラムやスプリントレビューで計画が形になっているかを検査し、
- Action：レトロスペクティブで課題の抽出と改善案を適用します
一方で、スクラムがPDCAと異なる点としては、スクラムではスクラムガイドによって示されるように役割やイベント等がより具体的な標準として定義されており、スクラムチームが変化する前提に適用できるような仕掛けが施されていることにあります。
そして、チームがスクラムフレームワークの仕掛けの恩恵を十分に受けるためには、スクラムのガイドラインで定義されたスクラムの役割やイベントをチームに浸透させていく役割が必要です。
それこそがスクラムマスターの役割です。
また、PDCAサイクル同様、スクラムはサイクルを繰り返すごとにチームの問題抽出や課題設定・原因分析の経験回数が増えていきます。最初期こそスクラムマスター自身も問題抽出を行うものの、現場でより身近に課題を感じているデベロッパーやプロダクトオーナーが挙げる問題や課題の方がはるかに解像度と質が高くなります。
したがって、スクラムの役割やイベントを浸透させていくだけでなく、スクラムチームが自律的且つ能動的にスクラムサイクルを回せるように促すことで、チーム自身がスプリントの効果と品質をより向上させられるようにすることもスクラムマスターの責任です。
しかしながら、実際にスクラムフレームワークをチームに導入することは簡単なことではありません。
私自身も、スクラムのメリットを享受したことがなかったり、イベントのゴールを理解しきれずにいるチームメンバーがいたりすることによって、スクラムがなかなか浸透しないという経験をしました。
このような状況を避けるためには、プロジェクトの中盤ではなく、立ち上げ期や初期フェーズに各役割が作業レベルでいつ・何をするかを伝達したり、イベントを開催するたびにイベントゴールが何かを繰り返し説明したりする努力が必要です。
具体的には、プロジェクトが始まる前に、スクラムの各役割やイベントとゴールについての説明資料や、スクラムに適合する最小のタスク管理ポリシーのテンプレートを事前に作成しておくことが有効です。
スクラムマスターのあなたが、スクラムチームにスクラムの土台を導入しチームが自律的にスクラムサイクルを回せるようにするためにも、事前にスクラムのイベントと役割の説明資料や、タスク管理ポリシーのテンプレートを作成しておくようにしましょう。
スクラムマスターの具体的な役割や仕事内容とは
前章でお伝えした通り、スクラムマスターの責任は、チームにスクラムフレームワークの土台を導入し、チームが自律的にスクラムサイクルを回せるようにすることです。
その責任を果たすための具体的な役割や仕事内容は、主に以下の３つに分類できます。
1. 立ち上げ時にスクラムイベントを導入し、役割を浸透させる
プロジェクトの中盤に差し掛かってからスクラムを導入することは、簡単なことではありません。既に課題抽出と改善が繰り返された既存のオペレーションがあるため、たとえスクラム化できたとしても、タスク管理ポリシーの変更やメンバーのキャッチアップに時間がかかってしまうからです。
そのため、スクラムを導入するときはプロジェクトの序盤に導入することをおすすめします。プロジェクト序盤におけるスクラム導入の目安は、最低限４つのイベントが実施され、各メンバーが役割を認識しPDCAが回せる状態です。
私の経験では、スクラムイベントの導入よりも、チームにスクラムの役割を浸透させていく方が難しいように思います。理由は、プロダクトオーナーに任命された方がプロダクトオーナーやスクラムの経験がないということがあるからです。
スクラムイベントの導入の具体的な手順としては、まずはプロジェクトの立ち上げのキックオフでイベントのための定期的な会議体を設置できるように、スクラムイベントの説明資料と定期的な会議体の候補日を用意しておけば十分です。
次に、役割についてはプロダクトオーナーがいつ何をやるかを作業レベルで明確にしましょう。
実際に、私もプロジェクトにおいてプロダクトオーナーの役割について何度も説明したことがありますが、それだけではスクラム進行に必要なアクションが十分に成されることはありませんでした。
そのため、プロダクトオーナーが徐々に役割について慣れていけるように具体的なことからお願いしていくように努めました。
私が実践していることは、プロダクトオーナーが最低限いつ何をやればスクラムサイクルが回るようになるかを作業レベルで詳細に伝えることです。
具体的には、以下の4つをプロジェクトの序盤にプロダクトオーナーにお願いしています。
- ユーザーストーリーをチケットとして起票すること
※前提として、タスク管理ポリシーは事前に用意し、タスク起票フォーマットの叩き台を用意しています - プロダクトバックログタスクの並び替えること
※前提として、デベロッパーは上から順にユーザーストーリーを実現していくというタスク管理ポリシーを設置しています - チケットに記載する質問に回答してもらうこと
- スプリントレビューに参加してもらうこと
その結果、プロダクトオーナーがいつどんなアクションをとれば良いかが明確になり、プロダクトオーナーによる要望起票→デベロッパーによるタスクの詳細化と質問の抽出といった良いリズムが生まれ、スクラムが効果的に実践されるようになりました。
プロジェクトの立ち上げ時にイベントと役割を浸透させることで円滑にスクラムサイクルを回していけるように、事前の説明資料の準備や未経験者が多いプロダクトオーナーにお願いしたいことの整理は入念に行いましょう。
2. チームの目標達成の障害を事前に取り除く
スクラムの障害事項は多岐に渡ります。ここではスクラムの障害の一例をご紹介します。
スクラムの障害として私がよく直面することは、プロダクトオーナーに技術の知識がなく、要望をタスクブレイクダウン(タスクをエンジニアが着手できる程度に詳細化すること)できないことです。
私がスクラムマスターを担当していたプロジェクトでは、プロダクトオーナーに業務の知識はあるものの、技術の知識や経験がないということが散見されました。
技術的な知見がないプロダクトオーナーは、技術的なことに詳しくない分、業務上何を実現したいのかにフォーカスしやすいという側面があるため、これ自体はマイナス要素ではありません。
ただし、デベロッパーがタスクに着手できるように、要望の内容をデベロッパーが着手できる程度に詳細化しておくためのサポートが必要になります。スプリントプランニングまでにタスクを詳細化できていなければ、デベロッパーがプランニング時に何を実装すればよいかに検討時間を割き、見積りができなかったり、スプリント計画が半分も立てられなかったりということがあるからです。
具体的な対応としては、プロダクトバックログリファインメントを定期化し、リファインメントを行う際に、プロダクトオーナーに要望通りになっていそうかどうかを簡単にチェックしてもらうことが有効です。
ブレイクダウンのアウトプットは、技術的な知見のないプロダクトオーナーでもチェックできるように、手書きレベルのUIラフ画や実装する機能リストがおすすめです。
それでも足りないところはスプリントレビューで実際にデモを行い、フィードバックを獲得して徐々に改善していきましょう。
3. チームが自律的にスクラムサイクルを回せるようになるために、イベントゴールを明確にする
スクラムには、定期的に行われるレトロスペクティブというイベントを通じて問題の抽出と改善事項を提案することで、変化する前提に対応する仕組みが備わっています。
しかしながら、スクラムのプロジェクトにおいて典型的に見られる良くない例の一つとして、問題や改善項目の意見の出どころのほとんどがスクラムマスターのもので埋め尽くされてしまうことが挙げられます。
しかしながら、本来は現場で実際の課題に直面しているデベロッパーやプロダクトオーナーが上げた意見の方が、はるかに解像度も質も高いはずです。
したがって、デベロッパーやプロダクトオーナーが気軽に意見を出しやすくする環境が必要となります。
私の考えでは、イベントゴールを明確にし、参加者のイベントゴールの認識を揃えることが、意見が出やすい環境の基盤になると考えています。
なぜかというと、多くのスクラムプロジェクトにおいて、各スクラムイベントの目的やゴールの捉え方、そのためのプラクティスについての参加者の認識が完全に一致していることはほとんどなく、イベントゴールの齟齬によるコミュニケーションのずれで徐々に意見が出なくなるという現象を私自身も何度も経験したからです。
こうした経験を踏まえ、私がスクラムマスターを務めるプロジェクトでは、タスク管理ポリシーにスクラムイベントの最低限のゴールを明確に記載し、また、プロジェクトの序盤でイベントゴールについての問答を繰り返すことで徐々に参加者全員がゴール認識を揃えていきました。
その結果として、デベロッパーやプロダクトオーナーから課題や改善案の意見が盛んに出るようになり、彼らが自ら出した改善提案で開発オペレーションが更新されていくことでチームの雰囲気もよくなり、さらに自律性が芽生えました。
今では、スクラムマスターがファシリテートを行わなくとも、スクラムのPDCAサイクルが適切に回るようになっています。
チームの意見が出しやすくなる土壌を形にするために、イベントゴールを明記し、デベロッパーとプロダクトオーナーの意見によって自律的にプロジェクトのオペレーションを改善するサポートを行いましょう。
スクラムマスターに必要なスキルとは
これまで述べてきた通り、スクラムマスターの責任は、チームにスクラムフレームワークの土台を導入し、チームが自律的にスクラムサイクルを回せるようにすることです。
たとえスクラムの知識や経験をもっていたとしても、プロジェクトにスクラムを浸透させることができなければ、その効果を十分に発揮することは難しいでしょう。
実際に、プロジェクト運営の実務では、参加者の一部がスクラム導入に消極的であったり、具体的なアクションが分かっていなかったりすることで、スクラムサイクルがうまく回らないというケースが多々あります。
そのようなケースを避け、スクラムのメリットを享受するためにスクラムマスターが持つべきスキルは、スクラムの細かい知識や具体的なツールを紹介することではなく、チームへのスクラム導入の動機付けや、参加者がスクラムの概念をしっかりと理解させるためのスキルです。
私が過去に見たスクラムマスターの中で、スクラムの改善サイクルを効果的に回せている方の経歴を聞くと、エンジニア出身の方よりも営業出身の方が多い印象でした。
たしかに、技術面のコミュニケーションは不足することもあるようですが、プロジェクトにスクラムを導入するための説得力やトラブルの事前防止、また、体制や開発オペレーションの課題を分析し適切にフォローしてあげるスキルがある彼らはスクラムマスターに向いているようです。
このように、スクラムマスターに必要なスキルは、いわゆる”営業力”と言えるかもしれません。
これは、スクラムマスターは必ずしも営業出身の人が就任した方がよいというわけではなく、チームの参加者にとって慣れないスクラムを受け入れてもらうためには、未経験者にわかりやすい説明を心がけることや、説明のための事前準備を怠らないといった営業に通じる姿勢やスキルがとても重要ということです。
スクラムを導入し浸透させるためにも、人を知り、参加者がスクラムをよりスムーズに理解できるようにフォローや説明のスキルを磨き、粘り強い働きかけを行いましょう。
まとめ
本記事では、スクラムマスターの責任や役割と仕事内容について、自身の経験を含めご紹介しました。
さいごに、まとめとしてそれぞれのポイントについて振り返りましょう。
- スクラムマスターの責任は、チームにスクラムフレームワークの土台を導入し、チームが自律的にスクラムサイクルを回せるようにすること
- スクラムマスターの具体的な役割や仕事内容
- プロジェクト中盤ではなく、序盤にスクラムイベントを導入する。そのためにも、最低限スクラムのイベントと役割については事前に説明資料を作成しておき、また、プロダクトオーナーにお願いしたい具体的なアクションを整理しておく
- チームの目標達成の障害を事前に取り除く。一つの例として、技術知識がないプロダクトオーナーが体制に含まれているときは、プロダクトバックログリファインメントを定期開催しプロダクトオーナーの作業をサポートしてあげる
- チームが自律的にスクラムサイクルを回せるようにするためにイベントゴールを明確にする
- スクラムマスターに必要なスキルはいわゆる”営業力”
スクラムを導入し浸透させるためにも、人を知り、参加者がスクラムをよりスムーズに理解できるようにフォローや説明のスキルを磨き、粘り強い働きかけをすることが肝心
お問い合わせContact
ご不明点やご相談などがありましたら、お気軽にお問い合わせください。