これは Chatwork Advent Calendar 2日目のエントリです。
また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。
chatwork.connpass.com
スクラムマスターって何をする人なの？
本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。
スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。
そういう意味でスクラムマスターは、自分の仕事の結果を成果物という形で見せづらい職種でもあるかもしれません。
スクラムマスターによってもたらされる成果物は「自己管理化*1されたスクラムチーム」です。スクラムマスターが直接モノをつくることはありません。スクラムマスターによって導かれた「自己管理化されたスクラムチーム」によってソフトウェアはつくられます。
ぼくはここであえて、「スクラムマスターによって作られたチーム」とは書きませんでした。「スクラムマスターによって導かれた」と書いています。スクラムマスターは、チーム作りに対して強いリーダーシップを発揮するわけではありません。チームは、あくまでチーム自らによって作られていくべきです。スクラムマスターはそれを手助けするにすぎません。スクラムマスターはチームに対して、サーバントリーダーシップを発揮します。
もう少し具体的にスクラムマスターの仕事を考えていきます。
スクラムマスターは、チームが成果を出すために最大限の支援をします。チームにとって邪魔な障害物を取り除き、チームが成果を出すために必要なことはなんでもやります。「なんでもやる」と書いていますが、チームが手を動かすべき具体的な作業をスクラムマスターはなにもやるべきではありません。あくまで仕事の主体と責任はチームにあります。なので、チーム作業のこぼれ球を拾ったり、雑用をしたりはしません。スクラムマスターはチームの便利屋や秘書ではありません。たとえば、繰り返し発生する雑用などは、自動化できないかをチームに促して効率化していきましょう。
また、スクラムマスターはスクラムフレームワークを教条的にガチガチに守らせる仕事ではありません。極端な例ではありますが、チームがスクラムの廃止を訴え、それがチームの成果にとって最も価値の高い結果をもたらすのであれば、それすらも支援します*2。
スクラムマスターの成功は、チームが自ら強い責任を持って価値を提供し、そして翌日はさらにより良いチームになるように改善していく「自己管理化」したチームになることです。
逆にスクラムマスターの失敗は、たとえばチームがスクラムマスターに頼り切りになってしまったり、スクラムマスターの指示を仰がないと改善していけないようなことが長く続いてしまうような状態です。
つまりスクラムマスターは、チームが自分たちでより良く動けるように支援するのがその役割です。
スクラムマスターのキャリア
完全に自己管理化チームができあがってしまったとき、チームにスクラムマスターは必要なくなります。ではその後スクラムマスターはどうしていくと良いでしょうか？ 次の新しいチームを支援しても良いですし、自分の関わるエリアを外に拡げる道もあります。
Zuzana Sochovaさんは、著書の"SCRUM MASTER THE BOOK"の中で、スクラムマスター道(ScrumMasterWay)というものを説いています。
ScrumMasterWayでは、スクラムマスターのステップは3つのレベルがあるとしています。
- レベル1: 私のチーム
- レベル2: 関係性
- レベル3: システム全体
レベル1: 私のチーム
スクラムマスターの最初のステップです。1つのチームのスクラムマスターとなり、そのチームの自己管理化を支援します。
一般的にみなさんが「スクラムマスター」という役割でイメージするのがここです。
レベル2: 関係性
チームがとてもいい状態になり、それほど手がかからなくなりました。スクラムマスターは、そのチームと、その周辺の関係性に目を向けます。
プロダクト開発は、ご存知のとおり開発チームだけで仕事が完結するわけではありません。営業、マーケティング、サポート、会社のボードメンバーなどさまざまな人や組織との関係性の中にチームは存在します。
これらの関係性を改善していくのが、レベル2のスクラムマスターの仕事です。
レベル3: システム全体
関係性の改善の次は、その視野をシステム全体に拡げます。会社全体、それを取り巻く社会、コミュニティ、といったシステム全体の改善について考えていきます。
このレベルになると、スクラムマスターは「アジャイルコーチ」とか「エンタープライズコーチ」と呼ばれるようになっているかもしれません。
このように、スクラムマスターのスキルや役割を拡げていくことで、自身のキャリアを深めていくことができます。
ちなみに、ぼくは今Chatwork株式会社で、あるチームの現場のスクラムマスターをやりつつ、エンジニアリングマネージャとして部門全体のScrum@Scaleというスケール化されたスクラムの推進だったり、開発組織づくりを手掛けています。自己採点としてはレベル2と3の間くらいかな、と思っています。
daiksyのスクラムマスターとしての暮らし
次に実例として、ぼくがスクラムマスターとして日々どのように仕事をしているのかを解説します。実際は、前述したとおり部門全体に関わる仕事もしているのですが、今回はスクラムマスターにフォーカスを絞って、あるチームのスクラムマスターとしての役割をどのようにこなしているかを書いていきます。
普段の暮らし
スクラムマスターの仕事の起点は「観察」です。なにか具体的なタスクをやっていないときは、業務時間のかなりを「観察」して過ごします。
チームが今どういう状態か。どういったときに誰が声をあげるか。どういうときにチームが動揺するか。そういったチームのさまざまなことを観察します。
場合によっては半日ずっとチャットや、モブプログラミング(ペアプログラミング)に貼り付いていることもあります。ここではあくまで観察に徹するので、なにか具体的に手を出したり、発言したりはしません（雑談に混ざったりはしますが）。
オフィスに集まって仕事をしているときは、メンバーの表情とか、そういったノンバーバルな情報も観察の有効な手がかりだったのですが、最近はリモートワークが主になって、以前のような観察は難しくなりました。しかしリモートワーク生活を2年も続けているうちに、最近はチャットテキストや、ビデオ通話などから読み取れる情報にも慣れてきて、わりとしっかりチームを観察できるようになってきました。
ぼくが最も気を使うのが、デイリースクラムとレトロスペクティブです。
チームはスプリントプランニングでスプリント期間の作業計画をしていると思いますが、デイリースクラムは1日単位のリプランニングの場です。
これは、1日の作業を計画する機会であり、スプリントレビューにむけた1日ごとのマイルストーンでもあります。
このままのペースでスプリントゴールを達成できるか。達成できそうになければなにが障害なのか。どうすればそれを取り除けるのか、ということを考え、チームを促していきます。
スプリントゴールがなかなか達成できない、というチームは、スプリントプランニングもさることながら、デイリースクラムがあまり上手ではない場合も多いです。ここを単に進捗確認とか、日報の場とかですましてしまってはいけません。
スクラムマスターがチームを導く最も重要な介入ポイントがデイリースクラムだと個人的には考えています。
レトロスペクティブ(ふりかえり)
レトロスペクティブもスクラムマスターの腕の見せどころです。毎回KPTをやっておしまい、では物足りないですね。
ここは、スクラムマスターの「観察」が生きてくる場だと思います。
レトロスペクティブはさまざまなアクティビティがあります。『アジャイルレトロスペクティブ』によると、レトロスペクティブは次の5つのフェーズで構成されます。
- 導入
- 情報収集
- アイデア出し
- 次のチャレンジの決定
- 終了
たとえば、有名なKPTはこのプラクティスをやるだけで、2, 3, 4すべてが内包されています。そういう意味ではとても手軽で便利なプラクティスです。
レトロスペクティブのプラクティスは、非常にたくさんあります。
たとえば、森一樹(@viva_tweet_x)さんが作成された「ふりかえりカタログ」には本項執筆時点で71種類ものプラクティスが掲載されています。
speakerdeck.com
これらのプラクティスは、どれを選ぶかによって議論の方向性や、期待される結果が異なります。
たとえば、課題の多く残ったスプリントならば、それにフォーカスしてより具体的な改善案が出るようなプラクティスを選択します。チームの状況によっては未来にフォーカスして、将来どういうチームを目指したいか、プロダクトをどう成長させたいか、といった議論をすべきタイミングもあります。
チームが落ち込んでいるときは、お互いに感謝を述べあって元気が出るようなプラクティスを選択したり、退職者がいる場合は引継ぎがうまく進んでいるかを確認するようなプラクティスをやってみたり。
スクラムマスターは、観察によって得られたチームの状態に対して、どのようにそれを改善したり、深めたりしていけば良いかを考え、それに即したプラクティスを選択してレトロスペクティブを実施します。まさにスクラムマスターのスキルを大いに発揮する腕の見せ所と言えるでしょう。
プランニング、リファインメント、レビューなどそれぞれでもやはりスクラムマスターとしての介入ポイントはありますが、これらのイベントは基本的にチームが主体となるべきです。ぼくはこれらのイベントではあまり介入しません。これらのイベントを観察して、なにか気になるポイントが見つかったら、レトロスペクティブでそれを取り上げてチームに改善を促すことが多いです。
この「介入しない」というのはある程度イベントに慣れてきてチームが自走できる状態になっているから、でもあります。最初のうちは、スクラムマスターがある程度ティーチングしてあげる必要もあるでしょう。たとえば、見積もりがあまり上手ではない場合は、アジャイルにおける見積もりの考え方などについてチームに説明をするのもスクラムマスターの仕事です。
daiksy.hatenablog.jp
スクラムマスターに必要な知識・スキル
ここまで、主にスクラムマスターの持つべきマインドや振る舞いについて説明してきました。最後に、このようなスクラムマスターの役割をこなすのに必要なスキルなどについて、ScrumMasterWayのレベル別に考えてみましょう。とてもすべては書ききれないので、とりあえずぼくが今思いついたものの中から少しだけピックアップしておきます。かなり私見が入っていますので、お近くアジャイルコーチに同じ質問をしてみて、それぞれの考える「必要なスキル」について考えてみるのも面白いかもしれません。
"レベル1:私のチーム"で身につけておきたいスキル
まずは大前提として、アジャイルとスクラムに関する知識ですね。アジャイルソフトウェア開発宣言と、スクラムガイドの内容は自分の血肉になるレベルで体に叩き込んでおきましょう。
ソフトウェア開発の現場のスクラムマスターであるなら、当然チームが扱っている技術スタックや、ソフトウェア開発全般に関する知識も重要です。特にCI/CDに関する技術などは必須スキルです。
効率的な開発や計画づくりにはプロジェクト管理に関する知識も重要です。『アジャイルな見積りと計画づくり』あたりは必読としておきたいところ。
最近だとPMBOKの第7版なども読んでおくといいかもしれません。
"スクラム"マスターとはいえ、ガチガチにスクラムに縛り付ける、というようなことはやるべきではない、という主旨のことを前述しました。チームが継続的な改善を繰り返すにあたって、さまざまなアレンジが必要になってきますから、スクラム以外のプラクティスについても学んでおくと良いでしょう。少なくともXPに関する知識は、必須レベルでおさえておきたい気がします。
カンバンについても学んでおくと、さまざまな場面でその知識を活用できます。
スクラムイベントのファシリテーション、チームメンバーとの1on1などもスクラムマスターの仕事になりますから、ファシリテーション、コーチングなどのスキルも身につけたいです。
また、チームビルディングについても知識が必要ですね。「タックマンモデル」などを引用したり意識したりすることが多いです。
最後はオプショナルといった感じになりますが、チーム開発をしていると、メンバーに「なぜチームで動く必要があるのか」「ペアプロやモブプロの効能はなにか」といったことを説明する必要があったりします。ぼくは『教育心理学特論』という本を読んで「建設的相互作用」による効能がチーミングの最大のメリットであるという腹落ちをしました。
"レベル2:関係性"で身につけておきたいスキル
開発チームの外側に目を向ける必要があるので、関わり合いのあるそれぞれの人々の仕事についての知識が必要になりそうです。たとえば、プロダクトマネージメントやカスタマーサクセス、営業、会計、決算資料の読み方などなど。
意外とこうやって外に好奇心を拡げて身につけた知識が、足元のチームを支援するために役にたったりもするので、とても学習していておもしろい領域です。
LeSSやScrum@Scaleなど、スケーリングスクラムについてもこのレベルになると抑えておきたいかもしれません。
全部読むには会員登録が必要ですが、ぼくが寄稿したScrum@Scaleの解説記事を宣伝させてください...。
eh-career.com
次も手前味噌ですが、ぼくが翻訳レビューとしてお手伝いした「チームトポロジー」は、チーム間の関係性や、開発組織を考えるにあたって興味深いです。
"レベル3: システム全体"で身につけておきたいスキル
このレベルになると、何かを学べばなんとかなる、というレベルではなさそうですね。ひょっとしたらレベル2くらいですでに必要そうな気がしますが、ぼくはこのレベルを意識するにあたってシステム思考などの学習に時間を使ったりしました。
おわりに
以上、簡単ではありましたが、私見を交えつつ「スクラムマスターって何をするの？」について考えてみました。
スクラムマスターの役割は、多岐に渡るわりに具体的に手を動かしたり、成果物を作成したりすることが少ないという点でわかりづらい仕事でもあります。とはいえ、専門的なスキルが必要な仕事でもあります。世話焼きの好きな人が雰囲気でやれてしまう、というような誤解を見かけたりもするのですが、そう簡単なものではありません。
プログラマーやデザイナーといった専門職と同様、探求しがいのある技術がたくさんある仕事でもあります。ぜひ、皆さんもこの興味深い仕事に少しでも目を向けてみてください。
Chatworkでは現在(2021年12月時点で)、スクラムマスター職を大絶賛募集中です。
募集要項に少しマッチしていないけど大丈夫か、などの相談も含めてカジュアル面談などお気軽にお申し込みください。
hrmos.co
また、オフィシャルな採用窓口はちょっと抵抗あるな、という場合はぼく個人のMeetyによるカジュアル面談も受付中です。
お気軽にご相談ください。
meety.net
![Software Design (ソフトウェアデザイン) 2021年2月号 [雑誌]](https://m.media-amazon.com/images/I/51XkawVmODL._SL500_.jpg "Software Design (ソフトウェアデザイン) 2021年2月号 [雑誌]")
