"スクラムをスケールする手法" について取り組みの「推移」を話そうと思ったわけ - 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年でもありました。

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

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

アジャイルな見積もりを理解する「コース定数」という概念

アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。

特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。

そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。

「コース定数」でアジャイルな見積もりを考えてみる

国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。

山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。

交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべてです。仮に山行の半分の地点で体力切れをおこし、行くことも戻ることもできなくなれば、それは遭難となります。そのため、このコースは完走可能かどうかを事前の計画で見極める必要があります。 計画が重要でありつつも、実際の難易度や体力度は行ってみないとわからないという経験主義的な分野として、山行計画とソフトウェア開発の見積もりはよく似ています。

たとえば、わたしは近々、立山という山の縦走をしたいと考えているのですが、これが自分にとって完走可能かどうかがいまいちわかりません。インターネットでの山行記録を見ていても、「体力的にきつかったです」と書いている人もいれば「地元の小学生が遠足で登る山なので、初心者でも大丈夫です」と書かれていたりします。体力は人によってまちまちなので、各人の主観はあまり参考にならないのです。

そこで登山計画を判断する際には、客観的な「コース定数」という指標を用います。

「コース定数」とは、鹿屋体育大学・山本正嘉教授によって定義された、登山ルートの難易度を示す指標のひとつです。以下の計算式によって求められます。

1.8×行動時間(h) + 0.3×歩行距離(km) + 10.0×登りの累積標高(km) + 0.6×下りの累積標高(km)

わたしが計画を練っている立山の縦走のデータは以下です。

  • 標準コースタイム (行動時間): 7h
  • 歩行距離: 8.6km
  • 登りの累積標高差: 0.910km
  • 下りの累積標高差: 0.911km

これを計算式にあてはめると、24.8 という値になります。

この24.8というのが、コース定数になります。定数と表現されているのは、実際の山行ではこれに自分の体重や、荷物の重量なども加わるからです。日帰りの軽い荷物と、テント泊を想定した重い装備では同じルートでも体力度は異なります。なので、コース定数はそれらを除いたベースとなります。

さて、唐突に24.8 と言われてもなんのことかさっぱりわかりません。 ソフトウェア開発における相対見積もりで、基準タスクが5ポイント。今目の前にあるタスクは基準ポイントから相対的に考えて3ポイントと8ポイントなので、あわせて11ポイントです。と言われても最初はあまり意味がないのと同じことです。

ここで、実際の自分の経験が必要になります。 以下の表は、わたしが過去に経験したルートと、実際の山行記録をコース定数の算出式にあてはめたものです。

f:id:daiksy:20210817191826p:plain
山行実績

自分の今までの経験でいちばんしんどかった山は「荒島岳」という認識がありますが、それとこの表の結果は一致しています。 自分の経験からすると、30までいくとかなりきつく、20~25くらいであればほどよい疲れの山行、という認識です。

日常的にハードな山に良く行く人であれば、30くらいの山はひょいと登ってしまわれるでしょう。なので他人の情報にはあまり意味がありません。

さて、この表にあてはめると、わたしが計画している立山の24.8という値は、過去の摩耶山(黒岩尾根)のルートや摩耶山(天狗道)のルートに近いということがわかります。これらのルートを歩いた記憶を遡ると、ほどほどにきつくはあったけど、まだ余力を残した状態で山行を終えることができていました。なので、立山もおそらく無理なく走破できそうである、という見通しが立ちます。

この考え方は、アジャイルな見積もりにおけるベロシティの考え方と一致します。

ベロシティとは、チームがスプリント期間に消化することができるポイントの実績をあらわします。過去に1スプリントでチームが消化したポイントの実績値を積み重ね、直近数回分の平均などをとって算出します。 「3ポイントと8ポイントなので、あわせて11ポイントです」という見積もりの謎の数字は、このベロシティと組み合わせてはじめて意味を持ちます。

つまり、見積もりのポイントと、チームの過去の実績から算出した処理能力を照らし合わせて将来の見通しを立てていきます。

ベロシティが8ポイントのチームであれば、前述の2つタスクを終えるのに2スプリントかかります。ベロシティが13ポイントのチームであれば、1スプリントで終わらせることができます。隣のチームのベロシティが11とか20とか、そのような値に意味はありません。他人が有している登山に必要な体力が、自分の山行にとって無意味であるのと同じです。

これが、アジャイルな見積もりとベロシティの考え方です。このように身近な例で考えると、とてもわかりやすいですね。

専門的に学びたい方は以下の書籍がおすすめです。

デイリースクラムでの掛け声

会社でひとつのチームのスクラムマスターをやっていて、デイリースクラムがオンラインということもあってか、なんとなくだらだらと終わっていくのが気になっていた。

前職では、いつのころからかデイリースクラムの終わりに掛け声をやって終わるという流れだったので、それを今のチームでもやってみることにした。

具体的には、デイリースクラムの最後に、ぼくが「今日も1日がんばるぞー」と声をかけるので、メンバー全員がそれにあわせて両手をあげながら「オーッ!」と発声するというやつ。 こういうノリが苦手な人もいるだろうから、嫌なら反対してもいいよ、という感じで伝えると、とくに反対意見がなかったので続けることにした。

やってみると、やはりなんとなくメリハリが生まれて、元気になる気がする。

Twitterでそんな話をしているとこんなリプがあった。

なるほどボーイスカウト。スポーツの円陣なども同様であろうか。

「やる気」のメカニズムなども、ドーパミンによって人間はやる気を喚起されるが、このドーパミンは行動をしないと分泌されないので、ぼーっと待っててもやる気は出ない、という話を聞いたことがある。体を動かしたり、気持ちを無理やり奮い立たせて「やる気のようなもの」を生じさせるには効能があるのかもしれない。

こんな感じのチームで一緒に働きたい人は👇ここ👇をクリック(突然の採用活動)!

recruit.chatwork.com