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

エンジニアリングマネージャとして会社にジョインするのは難しい

新しい会社に入社して1ヶ月半経った。

今回はエンジニアリングマネージャとしてのポジションでの採用で、過去4回の転職はすべてアプリケーションエンジニアとしての採用だったので、その差分に若干戸惑っている。時勢的にフルリモートワークというのも大きい...。

"成果"が見えにくい仕事に対する実感をどのように得るか

まずひとつは、"成果"に対する手応えが異なること。エンジニア採用であれば、「入社最速RTA!!」などと言いながら、とりあえず小さなタスクを拾って入社後1週間以内くらいに自分の出した最初のプルリクエストがマージされれば、「最初のステップは超えた」という実感を得ることができた。

マネージメント職では、そのようなわかりやすい成果が見えづらい。そもそも、自分の打ち手が効果を発揮するのが翌月、みたいなリードタイムも珍しくないので、自分はちゃんと給料分働けているのだろうか、とまぁまぁ不安になる。そこで、上役の人やメンバーと1on1などで期待値コントロールを丁寧にやる、ということをして心の平穏を保っている。

また、入社後1ヶ月のタイミングで社内のグループウェアにふりかえりを書いた。これを読んでくれた人からも概ね好評だったので、続けていこうと思う。なんとなく自分のやった仕事を書き出してみると、「なんやかんやで結構仕事してるな」という認識が得られるので、これも心の平穏につながる。

観察と干渉のバランス

自分がメンバーだった時代、新しく採用されて就任したマネージャーの過干渉により、ハレーションが起きて大きなストレスとなったことは何度もある。チームの課題を解決するのが仕事なので、必要であればある程度意図的にチームにストレスをもたらす手法はないこともないが、昨今のサーバントリーダーシップの考え方とはそぐわないし、自分の好みでもない。

自分のチームに対する干渉が、チームとってストレスになっていないか、というのがとても気になる。逆に、それを恐れるあまり「あの人、何をするために雇われたの?」と思われてしまっても困る...。このバランスが難しい。

スクラムマスターとしてのトレーニングで身につけた考え方を活かして、当面は「観察」を重視している。このあたりのさじ加減は、いかんせん自分としても経験の少ないことなので、小さく失敗しながらやっていきたい...。(あまり失敗して良い分野でもないんだけど)

表に言える仕事内容

会社のイベントで登壇させてもらったり、ブログエントリを書いたりした。

lp.chatwork.com

creators-note.chatwork.com

こんな感じで、今の所元気に暮らしています。

登山のド素人が1ヶ月でテント泊をやるまでの道のり

コロナ前にたびたび集まって酒を飲んでいた友人たちと、このご時勢で集まれなくなったのだが、彼らはなにやら最近登山に熱中しているらしい。そんな様子をしばらく対岸から眺めていた。

事の起こりは3月の末。その友人たちと琵琶湖疏水を大津から蹴上まで歩くハイキングが計画された。長らくの在宅勤務の運動不足解消に、近頃は自宅の近所を1~2時間歩くなどをしていたのだが、毎回同じようなコースを歩き続けて飽きていたので、気分転換にとても楽しみにしていた。

そのうち、友人たちは疎水歩きの前座として2, 3時間ほど登山をするのだという。京都から大文字山を越えて大津まで行き、そこで自分と合流するのだとか。いったい登山とはそれほど楽しいものなのか。物は試しに、自分もその行程に混ぜてもらうことにした。

どうせやるならと登山靴とハイキング用ザックを買い、参加したその様子がこれである。

大文字山・如意ヶ岳・長等山 / だいくしーさんの大文字山(京都府京都市左京区)如意ヶ岳長等山の活動データ | YAMAP / ヤマップ

この登山のあと、さらに3時間ほど疎水沿いを歩き、当日はクタクタになったのだが、思いの外楽しかった。

さて、実はこのとき、自分はこれまで勤めていた会社を退職し、1ヶ月ほどの有給消化に突入するというタイミングだった。本当は思い切って日本縦断旅行などしたかったのだが、コロナの感染者数の傾向がどうにもきな臭い。そこで方針を変更し、この長期休暇で何度か登山をしてみようと思い立った。

最初に登ったのは摩耶山である。友人が公開している山行計画を頼りにルートを決め、その友人にルートをレビューしてもらいつつ行ってきた。

摩耶山 / だいくしーさんの活動データ | YAMAP / ヤマップ

これがとても天気がよく、歩いたコースもトゥエンティクロスという沢沿いを何度か渡渉しながら歩く楽しいコースで、また山頂で食べたカレーと生ビールが最高で、完全に登山のおもしろさにハマってしまった。

しかしこの摩耶山の山行は同時に課題の残るものでもあった。後半、バテてしまって、登山とはこんなにしんどいのか、という思いもしていたのである。どうやら、自分は街中を歩くのと同じ感覚で山道を歩き、余計な消耗をしていたらしいということがその後調べてわかった。

登山はいかにペースを保ちながら、長時間動き続けるか、という運動である。登りの際は歩幅を小さく、定期的に休憩しながら自分の筋力やスタミナの消耗を最小に保ちながら行動していく。

そうとわかれば、今度は「山の歩き方」を試してみたい。もう次の山に行きたくて仕方がなかった。

また、やるならせっかくの休暇だしとことんやってやろう、と1ヶ月の登山ロードマップを考えた。ゴールは、4月後半にテント泊をやること、である。

この日から、2, 3日おきに山に登り、山に登っていない日は梅田の石井スポーツでテント泊に向けたギアを買い集める、という暮らしがはじまった。

摩耶山に次いで須磨アルプスに行ってきた。

鉢伏山・旗振山・鉄拐山・高倉山・栂尾山・横尾山・東山 / だいくしーさんの活動データ | YAMAP / ヤマップ

前述の「山の歩き方」を練習する目的も兼ねている。 たしかに、歩き方に気を配るだけで疲労度が全然違うことがわかった。

これなら、六甲から有馬へ抜けるルートも歩けそうである。

この「六甲から有馬」というのは、六甲山を登る定番のコースである。阪急の芦屋川駅からロックガーデンを通り、六甲最高峰を登頂した後、有馬温泉へ降りる。距離にして14kmほど。コースタイムは約7時間という長丁場だ。

こんな長い距離を本当に歩けるのか不安だったが、須磨アルプスの様子だと行けるような気がしてきた。

飲料水や行動食、途中の食事のためにクッカーやバーナーといった調理器具など念入りに準備していざ決行。

なかみ山・六甲山 / だいくしーさんの六甲山なかみ山の活動データ | YAMAP / ヤマップ

これまで何度か旅行に行ったことのある有馬温泉へ徒歩でたどり着いた、というのが感動的で、大きな達成感を得られる山行だった。

こうなったらいよいよテント泊である。

ぼくが利用しているYAMAPというアプリには、いくつかの条件を達成すると獲得できる「バッジ」という機能がある。Playstationのトロフィー、Xboxの実績解除、みたいな遊びである。 その中に「六甲ハイカー」というバッジがある。これは六甲山系の決められた7つの山を登頂すると獲得できる。この六甲ハイカー獲得の登山を重ねながら、テント泊の準備を進めていく。

最初、金剛山の山頂近くのキャンプ場を目指した登山を考えていたが、金剛山は近畿では珍しい標高1,000mを超える山である。自分が実行を考えていた4月中旬は、天気予報によると気温が低めで、金剛山山頂付近は夜になると0℃近い気温になる日もあるという。

最初のテント泊でこの条件はすこし不安が大きいので、別の場所を探していると、金剛山より標高の低い生駒にも山上にキャンプ場があるらしい。そこを予約することにした。

テント泊は荷物が多い。テント、マット、寝袋、衣類、調理器具、食料などなどを60Lを超えるサイズのザックに詰める。衣食住すべてを背負って山を登るわけだ。自分の荷物をザックに詰めたところ、20kg近くになった。これには焚き火台やビールなど、登山には必須ではないものもたくさん含まれた結果こうなるわけだが...。必須装備だけに絞っても15kgくらいにはなる。

生駒山には石切から登る3時間ほどのルートを当初計画していたが、この重さを背負っての登山はどうなるか想像もつかないので、生駒駅から2時間ほどでキャンプ場に着く短いルートに変更した。結果的には、この重さを背負っての行動時間は、今の自分の体力では4時間くらいが限界、ということが実際歩いてみてわかった(キャンプ場からの帰りのルートでは山頂を経由する3時間のコースをとったことで感覚を得た)。

生駒山麓公園でテント泊登山(の練習)! - 鐃速日山・生駒山 / だいくしーさんの活動データ | YAMAP / ヤマップ

キャンプそのものはこれまでに何度か経験があるが、一人のテント泊登山はそれとは完全に別物だった。 自身の体力も含む、すべてのリソース配分は自分の責任で、なにかそこで致命的なエラーが生じると最悪下山もままならないことになるという緊張感がとても大きい。テントで寝るときにも、自分ひとりというのはとても心細く、ほとんどまともに眠れなかった。

このようにまぁまぁ過酷な体験ではあるのだが、それを凌駕する楽しさもあった。

キャンプそのものは普通に楽しいし、やりきった達成感も格別である。あの重量を背負っての山行の記憶を思い出すと今でも「二度とやりたくない...」という気持ちになるが、おそらく近いうちにまたやってるだろう。

その後、無事に「六甲ハイカー」バッジも獲得することができ、長期休暇の登山ロードマップは無事完走できたのである。

f:id:daiksy:20210428191948p:plain
1ヶ月で歩いた様子