会社でチームトポロジー読書会を完走した

『チームトポロジー』の読書会を会社で半年かけて完走した。

この本は、翻訳レビューにも参加させていただき、ちょうどScrum@Scaleでチーム作りに取り組んでいる自分の関心ともドンピシャではまった本だった。本の内容は下記のスライドを読むと一瞬ですべてを理解(した気持ちに)なれる。

slide.meguro.ryuzee.com

この本では、「ストリームアラインドチーム」という具合にチーム組成に関する独自の用語が登場する。裏を返せば、この本に出てくる用語を上手に使うことで、チーム組成についての共通言語を手に入れることができる。つまり、自分一人で読むよりも、複数人で本の内容を理解して認識を共有することで、格段に議論が早くなるという感じだ。

そこで、社内で同じ言葉遣いを使って会話ができるように読書会を企画した。

本についての共通理解を得ることが目的なので、ディスカッションに重きを置く構成とする。また、事前に本を読んだり、資料をまとめておく、などの準備が必要となると、最初の方は良くてもだんだん後半になるにつれ面倒になってくるので、継続性を重視して事前準備は一切不要とした。

レギュレーションは以下のとおり

  • 週1回 1時間
  • 毎回1章ずつ進む (長い章は複数回にわける)
  • 前半30分黙読タイム (当日ディスカッションする範囲をみんなでモクモク読む)
    • 読みながら気になったところや感想をMiroに書く
  • 後半30分ディスカッション
    • Miroを眺めながら話す
  • 回の様子は録画しておき、休んだ人があとからキャッチアップできるようにする
  • 回の最後に簡単なふりかえりを行って改善する

当初は全13回と、最終回で既存の組織のAs-IsとTo-Beをチームトポロジーで解釈するワークショップで終了する予定だった。 結果的には全16回で終了することになった。途中ゴールデンウィークなどでお休みなどもあり、2022年1月から開始して6月に終了した。

最後のふりかりが結構効いていて、当初は黙読20分、ディスカッション40分ではじめたが、読む時間が足りないということで30分ずつに変更になったり、さまざまな改善が取り入れられながらブラッシュアップされていった。

読書会の効果はてきめんで、途中くらいから実際の業務でもチームトポロジーの用語を使って会話することが多くなった。 また、最終回のワークショップでは、参加者は完全にチームトポロジーの考え方を使いこなして議論をしながら、既存の開発組織を解釈していって盛り上がりがあった。

しかし本一冊をチームや社内で共通理解とするために、毎回半年かかるのはちょっとリードタイムが長い気がするので、もう少し短くやれないかを模索したい。

定例会議のカレンダーを整理した

リモートワークは会議室という物理的な制約がないので、ミーティングし放題だ。加えて、オフィスでその人の席まで歩いていってちょっと声をかける、ということができないので、そういうことをしたい場合は30分のテレビ会議を設定する、というようなことになる。

マネージャーという仕事をしていると、前述のような状況とあいまって1日の大半がミーティングで埋め尽くされてしまう。

たとえば、自分の勤務時間範囲のカレンダーから、「定例ミーティング」だけを抽出してみても以下のような有様だ。

このように、10時から16時までのコアタイムは定例ミーティングで埋め尽くされている。これに、採用面接であるとか、突発的な相談ごと、四半期ごとのミーティングなどが数少ない隙間をさらに埋めていく。

ミーティングによって生じるコンテキストスイッチに脳は破壊され、ミーティングの合間の30分間はお手洗いや次のミーティングの準備、あるいは脳を休めるためのTwitterによって無為に消費される。マネージャーとして、組織を改善する施策やアイデアを時間をかけて練ったり、メンバーに自分の考えを伝えるための書き物などをしたくてもそんな時間はどこにも残されていはいない。

そもそも、メンバーがマネージャーに気軽に相談をしようにも、それを受ける時間すらないのではマネージャーとしても失格な状態である。

これではいけない。自分の仕事と人生を取り戻さねばならない。

そんな折、NAVITIMEの小田中さんのスライドを読んだ。

speakerdeck.com

これは福音!!!

ということで実践してみた。

まず、午前と午後にちらばっている定例を可能な限り午前中に集約する。

次に、自分が見ている複数のチームのメンバーと相談して、「金曜日はチーム定例に出ない」というチャレンジをさせてもらうことにした。チームの定例自体は実施されているが、自分は出席しない、ということだ。これまでも有給をとって定例を欠席することはあったわけだし、週イチくらいなら問題なかろう、という実験だ。これは問題がありそうならやめるつもり。

その結果カレンダーはこうなった。

月-木は思ったほどスッキリとはしていないが、金曜日はまるまるフリータイム。有給取り放題DeepWorkし放題だ。

こうして、晴れやかな気持ちでフリータイムの金曜日にこのようなブログを書く余裕も生まれた。

世のマネージャー諸氏はどんどんこのようにして時間の空白を作っていくべきだ。

"スクラムをスケールする手法" について取り組みの「推移」を話そうと思ったわけ - RSGT2022で発表してきました

Regional Scrum Gathering Tokyo 2022 にプロポーザルを採択していただき、登壇してきました。

2018年以来になります。前回は、当時まだ今ほど浸透していなかった「リモートワーク」をテーマに発表しましたが、今や自分もRSGTそのものにオンラインで参加するなどあたりまえの世の中になりましたねぇ...。

ぼくは去年、Chatwork株式会社に入社しまして、そこから現在までScrum@Scaleを推進する仕事を主としています。 入社間もない時期から、この取り組みについては継続的に発信してきました。

最初は入社直後に会社の技術ブログで公開。

creators-note.chatwork.com

その後、エンジニアHubさんに機会をいただいて寄稿もさせていただきました。

eh-career.com

そして今回のRSGT2022での発表がこちらです。

speakerdeck.com

いずれも、Scrum@Scaleというスケーリングスクラムの手法についての解説と、社内での「その時点」での適用の様子をお伝えしています。

特に今回のRSGT2022では、Scrum@Scale導入初期から昨年末までの推移についてもご紹介しました。

こういった「手法」についての紹介は、手法そのものの理屈と、それを実際の現場に適用することについて少し乖離があります。

どんなにガイドや教科書を読み込んでも、そっくりそのまま現場に当てはめられるか、というと難しさがあります。 特に、自分たち以外の他の現場の事例というのはそれなりに参考にはなりますが、扱っている事業も集まっているメンバーもコンテキストもまるで違う現場での成功事例をそのまま真似することに意味はありません。重要なのは、どういう考え方に基づいてそのやり方になったのか、という部分だと思います。

そこで、ぼくは継続的に自分たちの取り組みを発信することで、自分たちの現場がどういう推移を経ているのか、に注目してもらいたいと考えました。RSGT2022のプロポーザルを提出したのは去年の夏ですが、その時点での試行錯誤の様子では、ひょっとしたら1月の本番のときはScrum@Scaleをやめている可能性すらありました。その場合は、それはそれでなんでやめたのか、も含めて発表すればいいや、くらいに考えていました。そういった「時系列の時々で選択してきた考え」をふまえて事例を紹介することで、はじめて皆さんの現場でもなんとなく参考になるレベルになるんじゃないかな、と思っています。

もう少しまた時間が経つと、ぼくらの取り組みの様子も変わっていると思いますので、頃合いをみてどこかで発表したいな、と思っています。

今年のRSGTはハイブリット開催でしたが、ぼくはオンライン参加を選択しました。 現地の会場をうろうろしていたわけではなかったので、登壇内容についてご質問などがあっても少し捕まえづらかっただろうと思います。

個別に話を聞いてみたい、などあればお気軽にお声がけください。

meety.net

2021年のふりかえり

毎年恒例のふりかえりです。

今年は登山という新しい趣味をはじめたり、転職したりと変化の多い1年でした。 とはいえ、新型コロナウィルスが油断できない状況でなにかと不自由な1年でもありました。

今年からの新しい取り組みとしてMeetyなどはじめたので、よろしければカジュアル面談もお待ちしております。

meety.net

去年のふりかえりはこちらです。

daiksy.hatenablog.jp

1月

前年に入稿していた雑誌記事が発売されました。

ソフトウェアデザイン2021年2月号の特集「Web API設計・開発入門」で第4章の執筆を担当しました。

2月

新しい会社との採用コミュニケーションは前年からやっていて、2月に内定のオファーをいただき受諾しました。

内定受諾以降は元の会社の引き継ぎを進めながら、新しい会社での活動を前提にした準備などもしていました。

詳しくは下記のエントリにも書きましたが、「スクラムフェス大阪」へのスポンサーを新しい会社にお願いしたり、テックイベントや夏のインターンシップの準備などもすでにこのときからスタートしていました。

daiksy.hatenablog.jp

入社前から次の会社での活動をほんのりはじめる、というのは賛否さまざまな考え方があるでしょうが、エンジニアリングマネージャーとしてジョインしていくことを考えると、ある程度事前に準備しておきつつ新しい会社でのスタートダッシュが切れる、というのはとても助かるなーと思っていました。

3月

こちらも前年に自分の仕事は終わっていましたが、翻訳レビューとしてお手伝いしていた書籍が発売されました。

4月

前の会社の有給消化に突入し、1ヶ月まるまる休んでいました。本当は長い旅行に行きたかったのですが、緊急事態宣言やらで行きづらく、近場の山で登山をして過ごしていました。

daiksy.hatenablog.jp

5月

新しい会社に入社しました。

前述のとおり、入社準備はほんのり開始していたので、いきなり会社主催のテックイベントに登壇させてもらったりなどしていました。

lp.chatwork.com

6月

スクラムフェス大阪に登壇しました。

speakerdeck.com

7月, 8月

会社の仕事をがんばっていました。サマーインターンシップで講師を担当したりもしていました。

9月

新しい会社での取り組みを目に止めてもらって、記事を寄稿しました。

eh-career.com

ikkikoさんとXPまつりに登壇しました。

xpjug.com

10月

会社でのScrum@Scaleの取り組みを知っていただくことが増えて、公式イベントとは別で「話を聞きたい」と声をかけてくださる方が増え、いくつかの会社さんに呼んでいただいてディスカッションなどをさせてもらったりしていました。

11月

マネーフォワードさんのイベントに登壇させてもらいました。

moneyforward.connpass.com

また、スクラムBarというイベントを会社主催ではじめたりもしました。

chatwork.connpass.com

12月

翻訳レビューのお手伝いをさせてもらった本が発売されました。

個人的なハイライトとしては登山でとうとう冬山装備を揃えたりもしました。

来年

1月5日、RSGTに登壇します。

2022.scrumgatheringtokyo.org

また、2021年の春頃からずーっと半年くらいかけてとある企画書を作り続けていて、それが通ったので2022年はほぼ1年かけてその企画についての仕事をやる予定です。予定通りに進めばおそらく2023年にお目見えするはず。

いろいろありましたが、今年も良い1年だった気がします。来年もどうぞよろしくお願いします。

新しい会社に入社してから7ヶ月でスクラムマスターとしてやったこと

いよいよ RSGT2022が迫ってきましたね!

これはRSGT2022を待ちわびるアドベントカレンダーの記事です。

qiita.com

RSGT 2022では、1月5日の14時からRoomCにて「Scrum@Scaleの理論と実装 - 組織をリファクタリングしながらスケールする」というお話をさせていただきます。

Scrum@Scaleを採用して運用しているチームに今年になって参画し、そこでの取り組みや「Scrum@Scaleってどういうものなの?」といったお話をさせてもらう予定です。

スクラムマスターとしての7ヶ月

さて、ぼくは2021年5月に今の会社にエンジニアリングマネージャーとして入社しました。現在のミッションは、Scrum@Scaleで運用されている部門全体を統括して、その開発プロセスを整えていくのが仕事です。他にも、社内にスクラムを横展開したり、採用・育成などエンジニアリングマネージャーとしての仕事もあるのですが、このエントリではその中で「スクラムマスター」としての仕事に焦点を絞って入社から今日までの7ヶ月間なにをしてきたのかをふりかえってみようと思います。

Scrum@Scaleの整えが大きなミッションのひとつになりますので、ぼくの場合は「スクラムマスター」と言ってもチームのスクラムマスターだったり、Scrum@ScaleにおけるScrum of Scrum (SoS)を担うスクラムオブスクラムマスターだったり状況によっていろいろな帽子をかぶってしまうのですが、今回はScrum@Scaleにおけるぼくの役割について書いていきます。

Scrum@Scaleについての詳細はここでは説明しませんので、以下の記事や公式ガイドをご参照ください。

creators-note.chatwork.com

eh-career.com

scruminc.jp

また、スクラムマスターがどういう役割なのかについては、同じく下記の記事をご参照ください。

daiksy.hatenablog.jp

入社前

内定受託後、入社日が決まってから配属先のマネージャなどとのチャットルームが開設され、入社後の仕事や手続きについていくつかのコミュニケーションがはじまっていました。そこでさっそくスクラムフェス大阪へのスポンサーを打診しました。自分がエンジニアリングマネージャーとして採用に関わるであろうことを見越した動きでした。まずはアジャイルコミュニティに対して露出を増やして、自分の入社とあわせてこの会社はスクラムに力を入れている、というブランディングをしていくのが目的でした。

1ヶ月目(2021年5月)

5月1日に入社しました。いちおうぼくは大阪オフィスの配属なのですが、こういうご時世のためフルリモートワークでの入社となります。

まずはチームメンバーやPO、部門に関連する人たち全員と1on1を実施しました。リモートワークでのスタートだったので、そもそも明示的に時間をとって1人ずつと話をしていかないと顔と名前を覚えられません。

エンジニアリングマネージャーとしての入社だったので、まずは周囲の人との期待値調整が重要だと思いました。1on1では主に自分になにを期待されているのか、それに対して自分でそれをやれそうか、それとも自分では難しそうか、といった話をしていきました。

エンジニアリングマネージャーだったり、スクラムマスターといった仕事は自分で直接の成果物をつくる仕事ではありません。入社直後の、周りから信頼を得ていきたいタイミングでも具体的な成果を見せづらい役割でもあります。目に見える成果が出せない分、周囲との期待値調整に気を配って過ごした1ヶ月でした。

スクラムマスターとしての動きは、SoSの各イベントのファシリテーションをこれまで業務委託のアジャイルコーチにお願いしていたのですが、それを自分に巻き取りました。SoSのスクラムマスターとして振る舞うことで、Scrum@Scale組織全体の状況を大まかに把握できるのと、SoSに干渉していくことでScrum@Scale全体の改善に関わる一歩目を踏み出しやすいと考えたからです。

2ヶ月目(2021年6月)

目に見える成果を出しづらい仕事なので期待値調整を丁寧にやる、など偉そうなことをさっき書きましたが、とはいえ不安がいっぱいでこんなエントリを書いたりしていました。

daiksy.hatenablog.jp

6月は引き続きSoSのスクラムマスターとしてふるまうのと同時に、まだ未整備だったMetaScrumを動かしはじめました。具体的にはMetaScrumとしてのデイリースクラムなどのイベントを整えました。

Scrum@Scaleではぼくが参画した時点で3チームが稼働していました。3チームが比較的自由に動いており、その自由度は維持したかったのですが、Scrum@Scale全体としてある程度の全体統一は必要だという課題がSoSを運用するうえで認識されました。そこで、カレンダーを調整して3チームのスクラムイベントがある程度協調できるように変更しました。 たとえば、全チーム統一して水曜開始・火曜終了の1週間スプリントとする、デイリースクラムは3チームが同時間帯に実施し、その直後にSoSのデイリースクラムを設けて情報が時間的に隙間なく流れるようにする、などです。

6月はスクラムフェス大阪に登壇もしました。

speakerdeck.com

3ヶ月目(2021年7月)

MetaScrumの整えをもう少し進めました。会議体の整備などをして、3チーム全体に対する意思決定の場を整えました。

社内向けにアジャイル勉強会を主催して、他部門の方にむけたScrum@Scaleや、各チームのスクラムの取り組みを紹介したりしました。

人員配置の関係と、自分としてももう少し現場に入り込んで観察したい、ということでSoSに加えて3チームのうちの1チームの現場スクラムマスターになりました。

この頃にRSGT2022のスポンサー募集が開始され、会社にスポンサー拠出の打診をしたところ快く応じていただきました。

そうこうしているうちに試用期間が終わりました。

4ヶ月目(2021年8月)

SoSのスクラムイベントを改善しました。コンテキストを共有せずにどう改善したかを書くと難しく、コンテキストを書こうとすると膨大になってしまうので詳細を書きづらいのですが、SoSを含めてScrum@Scale全体の運用の詳細は毎月少しずつ変化しています。

このタイミングでScrum@Scaleで動いているプロジェクト全体のむきなおりをやったりもしました。

ぼくが現場スクラムマスターとして入ったチームは、ちょうどこの頃いい感じに混乱期に突入していたので、チームに「タックマンモデル」について説明するなどもしていました。

5ヶ月目(2021年9月)

Scrum Incさんが提供されているScrum@Scaleの公式トレーニングを受講しました。これは本当に受講した甲斐があって、これまでの自分たちの取り組みの答え合わせにもなりました。Scrum@Scaleではスクラムマスターサイクルとプロダクトオーナーサイクルという2つのサイクルを回して運用していきます。研修を受けたことで、スクラムマスターサイクルの実装は比較的うまくやれているが、プロダクトオーナーサイクルに課題が多い、ということが改めて理解できました。同時に、次はどう改善していくべきなのかを明確化することができました。

先程Scrum@Scale全体のカレンダーを統一した、と書きましたが、1週間のタイムボックスが維持されていれば細かい部分のアレンジは各チームに委ねています。3チームあるうちの1つのチームで1dayスプリントっぽい動き方がはじまりました(大きい枠組みでは1週間単位に他のチームと同期をとります)。

6ヶ月目(2021年10月)

現場に入っているスクラムチームでは、少しベロシティが安定しない時期が続いていたため、デイリースクラムとレトロスペクティブで少し強めにチームに介入しました。その成果もあるのかスプリントゴールの達成度が向上し、ベロシティを安定して計測できるようになりました。

MetaScrumやEATなどの枠組みを再編し、研修を受講して得られた課題を解決していくための体制を整えました。Scrum@Scaleそのものを変革していくバックログをEATの活動として扱えるようにしていきました。

社内横断的にスクラムマスターを支援するために、「スクラムマスターギルド」を立ち上げました。毎週1回の定例に各チーム(別部門の人も含む)からスクラムマスターが集まり、お互いの知見や課題を共有・相談する活動をはじめました。

スクラムマスターの採用や育成を強化するために「スクラムマスター」のジョブ・ディスクリプションをリニューアルしたりしました。

7ヶ月目(2021年11月)

Scrum@Scaleの3チームの状況を整理したところ、そのうちの2チームは関連性が高く、残りの1チームは比較的独立して動けている、ということが見えてきたのでSoSとMetaScrumを再編。2チームによるSoS&MetaScrumと、残りの1チームに別け、3チーム全体はEATとEMSによってつなぎこまれるという形にしました(ただしEMSはまだそこまで上手に機能していないので課題として取り組み中です)。

とこんな感じでここまで、簡単にではありますがぼくの入社から今日までのスクラムマスターとしての仕事をふりかえりました。

Scrum@Scaleとして具体的な実装がどうなっているのか、その変遷はどうなのか、といった詳細はRSGT2022でお話するつもりですので、ぜひお立ち寄りください。また、ぼくが勤めるChatwork株式会社はRSGT2022にスポンサーとして協力しています。

会場でお会いできるのを楽しみにしています!! (オンライン, オフライン問わず)

スクラムマスターって何をする人なの?

これは 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つのフェーズで構成されます。

  1. 導入
  2. 情報収集
  3. イデア出し
  4. 次のチャレンジの決定
  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

*1:自己組織化(Self-organized)というのがよく知られた表現かもしれませんが、スクラムガイド2020年版より自己管理化(Self-managed)と表現されているので本項でもこう表現します

*2:こういう例はごく稀で多くの場合は本当にスクラムを辞めてしまって大丈夫? と問いかける方向に動くべきでしょうけど...