RSGT2023でDJをしました(?)

今年のRSGT2023でkyon_mmさんのサポートとして登壇をしました。

confengine.com

ぼくの担当はセッションの内容にあわせてBGMを流す、というもので、「スクラムのカンファレンスでDJをする」という世界でもそんなに何人もいないであろう体験をしたので、その様子を書き残しておきます。

DJって何をする人なの?

RSGTでの話に入る前に、簡単にDJについて説明します。詳しい人は読み飛ばしてもらっても大丈夫です。

DJとは、簡単に言うと「その場をいい感じにするための音楽を流す人」です。たとえばクラブDJなら、人が踊りやすい音楽を鳴らしますし、結婚式のDJなら「お祝いの雰囲気が出る音楽を鳴らす」という感じです。

この「その場にあわせた音楽を鳴らす」ためにDJはいろいろな工夫をします。

たとえば、クラブDJを考えてみます。フロアにいる人たちは音楽にあわせて踊りたくて集まっています。ですのでDJは「踊れる楽曲」をフロアに流すわけですが、少し問題があります。

皆さんのお手元の音楽ライブラリを見ていただくとわかりますが、音楽にはだいたい5分とか、10分とかの長さがあります。これを普通に流してしまうと、下の図のように楽曲の境目で一瞬音が止まったり、「あ。今曲が切り替わったな」とはっきりと気づかれたりしてしまいます。

そこでDJは、一時的に2つの楽曲を重ねて流すことで、音楽が途切れないようにします。

異なる楽曲を同時に流すと違和感がありますが、そこがDJの腕の見せどころです。曲のテンポを揃える。高音・中音・低音それぞれのバランスを調整する。といったことを行い、2種類の曲が同時に鳴っていても違和感のないようにします。

DJが片耳だけヘッドフォンをつけている映像を見たことのある人もいるかと思いますが、あれは次の曲をヘッドフォンに流しながら、フロアに今流れている曲と混ぜて違和感が出ないように調整している最中の様子です。

DJの手元には一般的に2つのターンテーブルがついた謎の装置が置かれてます。これがDJコントローラです。

これを使って1曲目を左のテーブルで流す。2曲目を右のテーブルにセットする。1曲目の後半で2曲目の冒頭を流す。1曲目が止まったら、3曲目を左のテーブルにセットする。ということを延々と繰り返します。曲を違和感のないように混ぜるために、音にいろいろな工夫をする必要がありますが、DJコントローラについている複数のつまみはそれをやるための装置です。

このようにして、まるで数十分の長い1つの曲が流れ続けているかのようにフロアに音を鳴らし続けます。それによってお客さんは違和感なく、ずっと踊り続けることができるのです。

これがDJの基本です。

たとえば、今回のRSGTでは用意した楽曲がkyon_mmさんのトークに対して尺が短いような場合、複数の曲を混ぜてトークの尺に長さを合わせる、といったことをやりました。

権利関係はどうしたの?

ここからRSGTでの話に入ります。

RSGTのようなイベントで音楽を扱う際にはいくつかクリアしないといけない権利関係があります。著作権と原盤権です。

特にRSGTは現地での演奏と、アーカイブの配信があり、それぞれ権利処理は別になります。

著作権は、皆さんもおそらくご存知のJASRACという団体が多くの楽曲に対して一元的に権利処理を扱ってくれますので、ここに申請します。アーカイブが配信されるYouTubeは、サービスとしてJASRACとの契約を有しているので、我々演奏者が特別なことをする必要はありません。現地の会場での演奏についてのみ、申請をすれば大丈夫です。

原盤権はあまり馴染みがないかもしれませんが、DJの場合は楽器を演奏するのとは違って、CDとして販売されているような音源を直接再生することがあります。こうした既存の音源の製作者が保有しているのが原盤権です。これはJASRACのように包括して処理してくれる団体が存在しないため、楽曲制作者と個別に交渉する必要があります。

今回は、BGMとしての使用・配信が自由に許可されているフリーの音源と、知人があらかじめ演奏している音源を許可を得て利用させてもらうことでクリアしました。

事前の準備や練習

今回、この登壇に関わるメンバーはそれぞれ居住地が遠く離れているため、練習はすべてオンラインで行いました。

主にkyon_mmさんのトークとのタイミングを合わせる練習をするのですが、インターネットを使った通信には遅延が生じます。会議での会話をする分には気になりませんが、タイミングが非常にシビアな音楽の演奏の場合、この遅延は致命的です。

特に今回の発表では、ぼくのDJで再生するリズム音源と、ギターの生演奏を合わせる、というパートがあり、その練習がオンラインではとても難しかったです。

YAMAHAが提供するSYNCROOMという、オンラインで楽器演奏の練習をするツールがあり、あるときこれを利用したのですが、意外となんとかなるレベルでタイミングをしっかり合わせることができました。

syncroom.yamaha.com

当日の誤算

発表前日に会場で機材のセッティングを行いました。

前日なので、会場にお客さんは入っていません。この状態で各パートの音量調整などを行い、それを維持して本番に臨みました。

人間というものは、体に凹凸があったり、衣類をまとっていたりしますが、これは少なくない音を吸収します。この人間による吸音を甘く見ていました。

当日のkyon_mmさんのセッションは大盛況で、会場は満席。満席の人間による吸音効果で、いざ音を鳴らすと全然聴こえないのです。知識としては知っていましたが、ここまで明確な影響が出るものとは思いもよりませんでした。これが、音楽を主体とするイベントであれば、とりあえず爆音を出しておけば問題ないわけですが、今回はkyon_mmさんのサポートですから、肝心のトークが聴こえなければ意味がありません。トークを邪魔せず、それでいて音楽の存在感も出るボリュームをその場で調整するのは難しかったです。

最後に

実は、今回のDJは自分としてもかなり「うっ」となるチャレンジで、前述の権利処理をどうするか、などの議論もあって一度はお断りしました。ですがkyon_mmさんが常に前向きで「新しいチャレンジっていろいろあって楽しいですね」と言い続けてくださり、最終的な発表までたどり着くことができました。

とても楽しい、貴重な体験ができて、最終的にはとても楽しかったです。どうもありがとうございました。

2022年のふりかえり

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

去年はこんな感じでした。

daiksy.hatenablog.jp

今年は自分がこれまでにやったことが無い仕事にいろいろとチャレンジできて充実していましたが、そのために疲れたなーという1年でした。年末年始はあまり予定を入れずにゆっくり過ごそうと思っています。

去年のふりかえりの後ろの方にも書きましたが、会社の業務とは別に2021年に企画書をつくった仕事がありまして、今年はそれをずーっとやっていました。 会社の仕事をしながらですから、夜の時間や週末を使って進めており、疲れました。ようやく終わりが見えてきていて、詳しくは来年の春にはお披露目できると思います。

会社業務では1つのチームを見る仕事から、会社横断的な仕事へと手を拡げることができました。

今年は、前述の1年かけて進めた仕事とか、引き続きの新型コロナなどもあってあまり外に出ることがなかったので、来年はちょっとアクティブに外に出ていきたいなーと思っています。

あと来年はRSGT2023にkyonさんのサポートとしてお声がけいただき、今はその仕込みをしています。これもまた自分としては結構「うっ」となるものなのですが、楽しんでやらせてもらっています。RSGT2023に参加されるかたはぜひ観に来てください。

月ごとのふりかえりです。

1月

RSGTに登壇しました。 daiksy.hatenablog.jp

RSGT2022は、その後社内でも同時試聴会を開催するなど、盛り上がりがありました。

社内でチームトポロジー読書会をスタート。その後6月まで続きます。 daiksy.hatenablog.jp

エンタープライズアジャイル勉強会に呼んでいただき、Scrum@Scaleの取り組みについてお話しました。 easg.smartcore.jp

2月

だいくしーのスクラムBar #2を開催しました。 www.youtube.com

3月

Zuziの認定アジャイルリーダーシップ研修を受講しました。

その研修をテーマにスクラムBarを開催しました。研修スタッフの川口さんや、一緒に研修を受講した@ebouchiさんも飛び込みで参加してくださり、楽しかったです。 www.youtube.com

4月

同僚がCSDを受講したので、それをテーマにスクラムBarを開催しました。 www.youtube.com

5月

今の会社に入って1周年でした。

会社で新入社員向けにスクラムの研修をしました。

6月

タイミーさんのチームトポロジーのイベントに呼んでいただきました。 timeedev.connpass.com

スクラムフェス大阪で、会社としてスポンサーセッション枠があったので、その枠で会社のスクラム実践者7名を集めてLT大会をやりました。

7月

スクラムマスターのキャリアについて、スクラムBarを開催しました。 www.youtube.com

8月

翔泳社さんから、ヤフーの田原さんとの対談記事を出していただきました。 codezine.jp

7月のスクラムBarをログミーさんが記事にしてくださいました。 logmi.jp

Agile Studioさんのウェビナーにお呼ばれしました。 www.agile-studio.jp

9月

Scrum Interaction 2022に登壇しました。 scruminc.jp

竹内先生にお会いできるかも、と思ったのですが、自分の会場入りが遅くて竹内先生はもうお帰りになったあとでした...残念。

10月

10年以上前からの付き合いである盟友(とぼくが勝手に思ってる)kwappaさんとイベントに登壇しました。 findy.connpass.com

kwappaさんは個人的に自分のロールモデルであると思って背中を見ている存在なので、ご一緒できてとても光栄でした。

会社のイベントにも登壇しました。 lp.chatwork.com

11月

kyonさんのRSGT2023の登壇のサポートをすることになり、その準備をこのくらいからはじめました。

12月

めちゃくちゃ久しぶりにスクラムBarを開催しました。 www.youtube.com

スクラムBarにもゲストで来ていただいた、LAPRASの遠藤さんにお声がけいただき、LAPRASの公開社内勉強会に遊びに行きました(オンラインで)。 lapras.connpass.com

ということで、来年も良い年でありますように...。

社内コーチズクリニックをつくった

コーチズクリニックとは?

こちらのスライドが詳しい。

speakerdeck.com

  • Regional Scrum Gatheringや、スクラムフェスなどのカンファレンスで設けられる相談の場
  • カンファレンス参加者が、同じくカンファレンスに参加しているアジャイルコーチに個別相談ができる
  • アジャイルコーチは、自分の得意分野と、カンファレンスのセッションなどに参加していない時間を表明しておく
  • 相談者はそれを見て、自分の相談内容に答えてくれそうなコーチを指名して相談する

これを社内でもはじめてみた

ぼくの勤める会社にスクラムマスターギルドという集まりがある。毎週1回、30分程度集まって、各チームのスクラムマスターやアジャイルコーチが知見を交換したり、悩みを相談したりする場がある。気軽に相談ができて良い場なのだが、もう少し踏み込んだがっつりした相談をしたいときがある、と意見があった。

そこで、社内コーチズクリニックを立ち上げた。

スクラマスターギルドのドキュメントを集めている社のナレッジツールに専用のページをつくり、そこにコーチ役として名乗りを上げてくれた人の一覧を用意する。 一覧の項目は、名前、得意分野、相談可能な曜日/時間帯。

社内で呼びかけたところ、アジャイルコーチ、スクラムマスター、プロダクトオーナー、テックリード的な人、クリフトストレングスコーチの有資格者など、多彩な人たちがコーチ一覧に登場している。

たとえば、大きいプロダクトバックログアイテムを分割したいが、分割の観点などがまだしっくりこない、といったお悩みを持つ人がこのリストを参照して、コーチ役のプロダクトオーナーを指名して1on1をカレンダーに入れる、といったように相談の場をつくると、コーチ役が話を聞いてくれる。

もちろんコーチ役の人が、別のコーチ役に相談しても良い。さっそく自分も誰かに相談してみようと思っている。

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

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

この本は、翻訳レビューにも参加させていただき、ちょうど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