中間管理職の仕事 - 情報伝達のアレンジ

自分がまさに中間管理職ど真ん中なので、中間管理職の仕事を可能な限り自分なりに言語化してみようと思い、ざっくばらんに思ったことを書いていく。

今回は、情報伝達について。

組織がコンパクトであれば、中間管理職など必要はない。トップの意思がダイレクトに末端までスムーズに伝わるからだ。 組織が大きくなるにつれ、情報の伝達はスムーズにいかなくなる。

帝人の元会長である安居祥策氏が、日本経済新聞に寄稿した記事で記した「√の法則」というものがある。

100人の社員に物事を理解してもらおうと思えば、√100=10 として10回同じ説明をする必要がある。 10,000人の社員が相手になれば、100回になる。

多くの人に自分の考えを理解してもらうためには、このくらい同じ説明を何度も繰り返す必要があるということだ。全社員が集まる集会で、1回説明すれば明日からすべての社員がそのように動く、ということはない。

これはあくまでも考えの目安であるが、だいたい直感とも一致する。

とはいえ、社長がいちいち同じ話を繰り返すのも効率が悪い。そこで、我らが中間管理職の登場となる。

社長が10人のマネージャーに説明をする。10人のマネージャーはそれぞれ10人の部下に同じ話をする。これを繰り返しながら、組織全体に情報を伝播するのだ。

しかし、間に立つ中間管理職は、右から左に情報を流すだけで良いだろうか?もちろんそんなことはない。それぞれの管理職が担当する部門は、それぞれ職種はバラバラで、役割も異なる。トップの意思を、自分が担当する部門の目的に応じてアレンジをして伝える必要がある。

中間管理職は、上からの指示を、自分の担当する仕事内容に応じてカスタマイズして扱う必要があるということだ。

では、中間管理職が、自分の裁量で情報をカスタマイズするには、なにを手がかりにすればよいのか。カスタマイズの方向性をしくじると、トップの指示は歪んで伝わってしまう。

そこで重要なのが、その情報を伝達する「理由や目的」である。いわゆる「Whyからはじめよ」というやつである。

www.ted.com

少し極端な例を考えてみる。

トップから、ある目的を達成するために我が社ではA, B, Cの3つの施策を行う必要がある、という指示が出る。

エンジニアリング部門のマネージャーは、その目的を達成するためには自部門ではAとBに注力せねばならない。Cは自部門にとってそれほで重要ではないので、部下への指示は簡略化してよいと判断した。

セールス部門のマネージャーは、その目的から、Cに注力する必要があると判断し、AとBについては部下への伝達を簡略化した。

これが、情報伝達のアレンジである。

トップから、施策の目的が伝えられていない場合どうなるか。

マネージャーは、自らの裁量で情報をアレンジするてがかりを持たないため、上からの指示をそのまま現場に伝える。すると、エンジニアリング部門は本来気にする必要のないCにも力を割く必要があるし、セールス部門はAとBに余計なリソースを割くことになる。

要するに、現場としては本来やる必要のない無駄な仕事に忙殺されることになる。

現場からは当然クレームが出る。AとBをやる必要があるんですか? と。マネージャーはそれに対してメンバーに説明する術を持たない。マネージャーにできることは、まぁまぁと現場をなだめることくらいである。

この場合、マネージャーは自分の上長に「これをやる目的はなんですか?」と質問をしているかもしれない。しかし巨大な組織で、上長からも要領を得ない回答がきてしまうとお手上げである。

つまり、中間管理職が情報伝達という仕事を十分にやりとげるためには、トップの情報の中のWhyの部分が最も重要となる。それがあってはじめて、自部門になにを期待されており、自部門はどういうアウトカム、あるいはアウトプットを出せばよいのか、という期待が揃うことになる。

自分がなんのためにその仕事をしているのか、中間管理職として、これを常に説明できる状態にしておけるように振る舞いたい。

2023年のふりかえり

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

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

daiksy.hatenablog.jp

今年の一番のハイライトはなんといっても単著を出せたことでした。

顛末などは以下のエントリに詳しいです。

daiksy.hatenablog.jp

著者としての制作の大半は去年のうちに終わっていましたので、あまり今年の出来事であるという感覚が薄いのですが、それでも出版当日はとても嬉しく、書店めぐりをしました。

それでは月ごとにふりかえっていきます。

1月

RSGTに登壇しました。といっても自分のプロポーザルが採択されたわけではなく、kyon_mmさんのサポートとしてDJ(?)をしました。

daiksy.hatenablog.jp

FLEXYさん主催のイベントに登壇しました。

flexy.connpass.com

2月

3月に公開される記事の取材を受けていました。

3月

スクラムフェス福岡に登壇しました。

speakerdeck.com

アジャイルリーダーシップについて、ユーザベースの皆さんと対談させていただきました。 agilejourney.uzabase.com

4月

ふりかえりカンファレンスでLTをしました。

speakerdeck.com

5月

Scrum Incさんにお声がけいただき、ある会社さんむけのScrum@Scale研修でゲスト講師としてお手伝いしました。

7月

Software Design誌の8月号に寄稿しました gihyo.jp

8月

著書が発売されました。ちょうど、夏休みの北海道旅行の最中に発売のお知らせが出て、友人が運転するレンタカーの後部座席でひたすらエゴサーチをしていました。

SD誌の寄稿記事をテーマにしたウェビナーにお招きいただきました。 www.agile-studio.jp

9月

Scrum IncさんのScrum@Scale研修にゲスト講師としてお招きいただきました。

その後、WEB+DB Press休刊のパーティに著者枠で参加予定だったのですが、台風により参加を断念しました...。

daiksy.hatenablog.jp

アジャイルラジオに出演しました。

agileradio.github.io

agileradio.github.io

agileradio.github.io

自著について、平鍋さんにインタビューしていただきました。

www.agile-studio.jp

10月

自著の読書会が開催されると聞きつけ、参加しました。

agiletechexpo.connpass.com

自著をテーマにしたウェビナーを企画していただき、出演しました。

www.agile-studio.jp

11月

CSP-SM研修を受講し、資格を取得しました。

12月

KDDIアジャイル開発センターさんの社内勉強会にお招きいただきました。

note.com

まとめ

今年はありがたいことに、自著に関するイベントに多くお声がけいただきました。 会社の仕事では、今年は採用にとても大きくパワーをつかった1年であり、採用難易度の高いポジションで多くの人に来ていただくことができました。

身の回りで少しいろいろとあり、来年のことはまだあまり考えられていないのですが、少し大きい新しいチャレンジをしたいなと思っています。

2024年もどうぞよろしくお願いします。

WEB+DB PRESSの思い出 #wdpress #wdpress_party

書くぞ!!!!!!!

WEB+DB PRESSには過去何度か記事を書かせていただき、その流れで著書まで出していただくことになり、自分の人生に大きな影響を与えてくれた雑誌でした。

22.9周年パーティにはぜひとも参加したく、申し込み開始にあわせていち早く登録に成功し、著者枠として参加予定で、前日から東京に行っていました。

ですが、運悪く台風13号の進路が怪しくなり、翌日の午前中には家に帰っておきたい事情もあり、安全をとって旅程を変更して、キャンセルすることになりました...。このときほど自分の雨男を呪ったことはありません。*1

パーティに参加することはできませんでしたが、なにか少しでもこの機会に気持ちを残しておきたいと思いましたので、思い出など書いてみようと思います。

はじめて、WEB+DB PRESSの編集部と接点を持つことになったのは、2015年でした。

当時、ScalaMatsuri 2016のスタッフをやっており、自分は広報担当として、プレスリリースやブログ記事執筆などを担当していました。そのとき、WEB+DB PRESS誌にイベントレポートを掲載したい、という打診が編集部からあり、そのプレス対応などをしたことが最初のきっかけでした。

その後、Scala関西サミット2016にスタッフとして参加した際、このイベントもレポートを掲載してもらえないかと、ScalaMatsuriを取材してくださった編集者さんに自分から企画を持ち込み、その企画が通ったのが、自分の最初のWEB+DB PRESSでの執筆デビューです。

WEB+DB PRESS vol.96に掲載されました。

gihyo.jp

そこから、Scala関西サミットやScalaMatsuriのスタッフを何年か継続し、その度にイベントレポートの企画を持ち込んでは掲載してもらう、という期間が数年ありました。

その後、デブサミ2020の登壇をきっかけに特集記事を単独で書いたり、そこからさらり単著へと繋がったりするという縁が続きました。

daiksy.hatenablog.jp

daiksy.hatenablog.jp

こうして考えてみると、ScalaMatsuri -> Scala関西サミット -> デブサミ -> 特集記事 -> 著書 の流れはまさに自分のキャリアの変遷の過程に都度WEB+DB PRESSとの接点があった、という気がします。

自分の著書が、WEB+DB PRESS PlusシリーズとしてWEB+DB PRESS休刊最後の号の翌日に発売日であったのも、偶然ではありますがなにか縁を感じます。

今後も不定期で継続の予定であるということですので、引き続き縁が続けばよいな、と思っています。

単著の執筆はとてもたいへんで、書いている最中は二度とやりたくないと思っていましたが、喉元を過ぎて今は「もう1回くらいやってみたいな」という気持ちも芽生えていますので、どうぞよろしくお願いします。

*1:高速道路の中央分離帯のこちら側だけ豪雨。ソフトボールで3打席連続にわか雨。北海道に旅行に行く度になぜか台風とチキンレース。などの経験があります。

Scrum@Scaleの日本語書籍を出版します & 執筆の様子の記録

実は密かな長年の夢だったのですが、この度、技術評論社さんから単著を出版することになりました。

Scrum@Scaleの解説書で、全編書き下ろしです。

紆余曲折があり編集者さんに本を書きませんか、と打診いただいてから2年半ほどの大仕事でした。

Scrum@Scaleについてまとまった日本語の書籍は他にはなく、複数のスクラムチームで仕事をされている現場の大きな手がかりとなるはずであると自負しています。ぜひお手にとってみてください。

書籍の内容について

本書はぼくが現職でScrum@Scaleを導入した際の知見を惜しみなく注ぎました。全7章の構成です。

第1章 スクラムのスケーリングと大規模の難しさ

アジャイルコーチになんの前提もなく「スクラムをスケールするにはどうすればいいですか?」と尋ねると、十中八九「スケールしてはいけません」と回答が返ってくるでしょう。ぼくもそう答えます。

この章では、組織のスケールはそもそも難しいということを説明します。それでもどうしてもスケールする必要がある、という場合のみスケールに取り組んでほしいからです。

また、Scrum@Scale以外のスケーリングの手法についても簡単に触れています。

第2章 スクラムのおさらい

ここではスクラムガイドをベースにスクラムの簡単なおさらいを書きました。すでにスクラムを習熟している人は読み飛ばして問題ありません。

第3章 とあるチームのScrum@Scaleでの1スプリント

具体的な解説に入る前に、ある架空のゲーム開発チームがScrum@Scaleで仕事をしている様子をストーリー仕立てで紹介します。ここで実際の仕事の様子を把握してから、それぞれのプラクティスなどの解説をしたほうが、理解がしやすいと思ったからです。

ストーリー仕立てではありますが、本書はあくまでも解説書ですから、過度に小説のような仕立てにはならないように注意しました。ですから最低限、解説書としての読み心地は損ねていないと思っています。

第4章 スクラムマスターサイクルとプロダクトオーナーサイクル

第5章 Scrum@Scaleを形成する12のコンポーネント

ここからScrum@Scaleの解説に入ります。 4章と5章はScrum@Scaleの公式ガイドをさらに深く掘り下げる構成としています。 公式ガイドを読んだことがない人でも、この2つの章を読むことでガイドと同じ知識が身につきます。また、公式ガイドをすでに読んでいる人も、それぞれのトピックをさらに深く具体的に掘り下げていますので、実践の手がかりとしやすくなっています。

第6章 現場へどのように導入していくか

ここからは実践編です。ぼくの経験をもとに、Scrum@Scaleの現場への導入手順を探っていきます。

第7章 Scrum@Scaleで運用される現場 チャットサービスの開発現場の場合

最後の章はより具体的な実践例の紹介です。ぼくがScrum@Scaleを導入した実際の現場の様子を、その現場のコンテキストとあわせて説明しています。 直接みなさんの現場の参考にはならないでしょうが、導入背景とあわせて解説していますから、Scrum@Scaleを現場に適用する際の考え方の補助になるだろうと思っています。

出版の経緯

ここからは、出版の経緯や苦労話を書いていきます。単著の制作は想像を遥かに超えて過酷で、何度も心が折れそうになりました。その度に、他の著者の経験談が書かれたブログなどを読み、「たいへんなのは自分だけじゃないんだ」と心の支えとしていました。ですので、後の世で書籍制作で苦労している人と体験談を共有する目的で、ここからは自分の執筆の様子を残しておきます。

今回の書籍制作の最初は、2020年2月にまで遡ります。

この年のDevelopers Summit 2020での講演を技術評論社の編集者さんが見てくださっていて、ぜひこの講演をテーマにWEB+DB Press誌で特集記事を書きませんかとお声がけいただきました。

その後、この企画はいろいろとあって、最終的に2020年10月にWEB+DB Press vol.119にて、「インフラ障害対応演習」という25ページの特集記事となりました。

daiksy.hatenablog.jp

この特集記事がとても好評で、その後編集者さんから書籍化を打診してもらいました。これが企画のはじまりです。

当初はこの特集記事を膨らませることで書籍化する、ということだったのですが、翌年の2021年に、当時勤めていた会社を退職することになりました。この「障害対応演習」は当時勤めていた会社での取り組みをまとめたものでしたので、退職によってこの企画をそのまま進めることは不可能になり、編集者さんに一度お断りの連絡を入れました。

その後、2021年5月に今の会社に入社し、転職のご挨拶を編集者さんに差し上げたところ「次の会社での取り組みを書籍にしませんか?」というありがたい申し出をいただきました。

新しい会社では「アジャイルコーチとしてScrum@Scaleの導入を促進する」というミッションが自分に与えられており、これがうまく成功すれば、この体験をあわせて書籍化できるかもしれない、と考え、その旨を編集者さんに伝え、少し時期を待っていただくことになりました。

その後、会社での取り組みにある程度成果が出た時点で、編集者さんと企画書の作成に取り組みました。

手元のログでは、2021年11月15日から具体的な企画書を作り始め、その後12月27日に技術評論社さんの企画会議を通過したという連絡をもらっています。この間には何度か担当編集者さんや、企画会議からのフィードバックを受けた手直しもしています。

企画会議通過の連絡をうけて、翌年の2022年の1月から、具体的な執筆がはじまりました。

執筆の見積もりと進捗管理

もともとWEB+DB Press誌で25ページの特集記事を書いた経験がありますから、今回もその延長でなんとかなるだろう、と当初は甘い見通しでした。 企画書時点での見積もりは、全7章で175ページ(1ページあたり800文字)でした。構成の細部は結果的には少し変更になったところもありますが、おおよそ当初見積もりどおりの構成とページ数でゴールすることになります(ページ数は若干減りましたが)。

WEB+DB Press誌は1ページあたり1,200文字の計算ですから、1,200×25ページの30,000文字。1ページ800文字の書籍の換算だと37ページほどを1ヶ月で書いたことがある、というのが執筆に着手した時点での自分の経験でした。

見積もりが175ページだから、特集記事の執筆をおよそ5回分ほど繰り返せば書き終わるから、そんなに無理な仕事ではないな、というのが当初の自分の感覚でした。

いざ蓋を開けてみると、そんなに甘いものではありませんでした。雑誌記事は締め切りも明確ですし、どんなに大変でも1ヶ月ほどで終わります。いわば、今思えば短距離走的な執筆体験でした。書籍執筆は、企画書提出の時点で7ヶ月ほどで書き上げ、その後2ヶ月レビュー期間を置く、という計画でした。7ヶ月間一定のリズムで一冊の本を書き続ける。この長距離走的な執筆体験は、想像以上に過酷でした。

ぼくは自称アジャイルコーチですし、スクラムについての書籍を書くわけですから、進捗管理は状況を常に編集者さんと共有しつつ、しっかりやろうと考えました。スクラムの三本柱の1つ透明性です。

書籍執筆の進捗をどのように測るのか、いろいろと考えましたが、今回は「文字数」を使うことにしました。

とても大雑把なものではありますが、企画書時点での見積もりは175ページでした。数字の根拠は特に無く、企画書を作成する際には目次も詳細に作るのですが、その目次の項目1つに対してだいたい何ページくらいであるか、というのを考え、それを積み上げています。実際に書き始めると、企画書時点の目次からどんどん内容は変わっていくのですが、とはいえ大筋にはこの目次が書籍全体のガードレール的な役割を果たすため、充分にこの見積もりの数字は進捗管理として使えると考えました。スクラムにおいて、プロダクトバックログアイテムにつけるストーリーポイントのようなものです。

1ページ800文字ですから、この本は最終的に175ページ×800文字で140,000文字書き終えると、制作が終わる見積もりになります。自分の進捗は、週末ごとに原稿のマークダウンファイルに対するwcコマンドの数字をプロットすることで、週ごとに何文字進捗したかという形で記録しました。書籍では、図も必要になります。図は自分で手書きで書いたものを最終的に編集部できれいにして掲載してくれます。図は1枚あたり400文字相当として雑に計算しました。

この方式で以下のようなバーンアップチャートを作成し、これを担当編集者さんと共有しました。

進捗共有のためのバーンアップチャート

当初は140,000文字の見積もりでしたが、実際はそれよりも手前ですべてのテーマを書き終えました。

理想線は毎週4,500文字ずつ書き終えた場合の推移。バッファは毎週3,700文字ずつ書いた場合の推移として置きました。これは、雑誌執筆のときに毎週5,000文字ずつ執筆することができた、という経験から出した数字です。雑誌のときは毎週5,000文字書けたのだから、それよりも少ない3,700~4,500文字くらいのペースだったら無理なく書けるだろうという見通しです。

バーンアップチャートにバッファを作ったのは結果としてうまくいきました。途中でしんどくなってサボることもあったのですが、バッファを食いつぶしそうになると焦りが出るのでそれを取り戻すモチベーションが働き、結果として当初の予定からそんなに大きく外れることなくゴールできました。

当初の見込みでは、この理想線とバッファの中間くらいを推移すれば良いな、と思っていたのですが、実際のバーンアップを見ていただくとわかるとおり、やはり人間というものはバッファがあればあるだけ食いつぶすのだな、というのを改めて実感することになりました...。

執筆日記

書籍執筆という、ひょっとしたら人生最初で最後かもしれない経験ですから、時々の自分の気持ちを残しておこうと思い、執筆日記をつけていました。進捗管理のために毎週末にその時点での文字数を記録していますから、そのタイミングで日記を書きました。

そのいくつかを抜粋して、紹介します。執筆の過酷な様子が伝わると幸いです...。

2022/01/10

「自分の知識にちょっと自信が持てない感じがして、とりあえずスクラムの本にたくさん目を通す。」

こういったアウトプットのクオリティは、そのアウトプット量の何倍ものインプットが必要になります。いざ書き始めてみると、どうも自分にはインプットが足りないのではないか、とだんだん心配になってきて、スクラムアジャイルの蔵書を改めて読んだり、追加でたくさん購入したりしました。

その後、執筆期間中は自著のことが頭から離れず、自著に関連しない書籍はまったく頭に入ってこないため、アジャイルスクラムに関するインプット以外は受け付けない体になりました。何を読んでいても、「これは自分の書籍の参考にはならないな。他をあたろう」という気持ちになり、執筆終盤はスクラムのことを考えるのがとても苦痛になっていました。執筆終了後、ようやく自著と関係のない書籍も気にせずに読めるようになり、精神的にも落ち着きました。

2022/01/17

「書きやすいところから書いていこう。2章から。」

前から順番に書いていこうとしたのですが、どうもうまく書けず、書きやすいと思うところから順番に書くことにしました。

2022/01/28

スクラムのおさらい。なんかわざわざ自分が書くことか、という気持ちになってくる。いろんな本に書いてあることの焼き直しをやってるみたい。おさらいだからまぁそれでいいのか。」

2022/02/05

「独自性のある章を書いてやっと楽しくなってきた。ゲーム開発の現場を模した例示をしたいが、違和感がないかどうか専門家のアドバイスがほしい。(中略)ますだーさんに相談してみるか。」

スクラムのおさらいの章は書いていてちょっとしんどかったのですが、3章でオリジナルの内容を書き始めてようやく楽しくなりました。ここで登場するますだーさんとは@scrummasudarさんのことで、当時ゲーム会社でお仕事をされていたので相談することなり、本書のレビュワーさんのお一人となっていただきました。

2022/06/24

「ちょっとモチベが下がってたけど、冨樫義博が執筆してるのをみてがんばろうと思った」

ゴールデンウィークに頑張りすぎてしまい、6月は本当にやる気が出なくて、心が折れかけていました。まったく進捗の出ない週が続いていたのですが、HUNTERxHUNTERの連載再開の報せを見て、おれが筆を折っている場合ではないぞ!!!! と本当にモチベーションが回復しました。

2022/08/11

「TJARの土井さんのゴールを見届けながら、ゴールした!!!!」

トランスジャパンアルプスレース(TJAR)という、日本アルプスを経由して日本を縦断する超人的なレースがあります。この年、土井さんという選手が歴史的な記録を打ち立ててゴールされたのですが、そのインスタライブを横目で見ながら、自分も執筆のゴールを迎えました。

その後

自分の執筆が終わったあと、2ヶ月間はレビュワーさんによるレビュー期間に入りました。とても多くの方に助けていただきました。

本書の謝辞の部分を引用しつつ、あらためてレビュワーの皆さんにはお礼を差し上げます。

 吉羽龍太郎さん、大友聡之さん、和田圭介さん、児山直人さん、湯川正洋さん、遠藤良さん、dairappaさん、山根英次さん、中村洋さん。これらの皆さんは本書全体のレビューをしてくださいました。石毛琴恵さん、増田謙太郎さんは、第3章の架空のチームの活動に対して、ゲーム開発の現場としてよりリアリティが出るようなアドバイスをいただきました。北濱良章さん、tunemageさんは、本書の骨子として最初に書き終えた時点の第4章の感想をくださり、その後の執筆継続の励みになりました。藤井善隆さんには同僚として第7章のレビューをしていただきました。

特に吉羽さん(@ryuzee)さんには、書籍出版の先輩として内容以外にもさまざまなアドバイスをいただいたり、ノウハウを教えていただいたりしました。当初、レビューをお願いしていた人はもっと少なかったのですが、「レビュワーにも事情があり、みんなが書籍全体を見られるわけではないから、できるだけ多いほうが良い。10人は集めて」というアドバイスは本当にそのとおりで、おかげで本当に多様な視点からレビューをいただくことができました。

レビューはプロのアジャイル実践者たちに見ていただいたため、おそらく地球上でこの本のテーマに関して最も学びが深かったのは自分自身だったと思います。一人で書いていた頃に比べて相当量のインプットをいただき、このときに得た学びは書籍制作以外の実務の現場でも大いに役立っています。

書籍制作はすべてをGitHubで管理しているのですが、issueの総数は428件。このうちの大半はレビューのご指摘やアドバイスとして起票されたものです。多大なるお時間をいただき、本当にありがとうございます。

レビューとその反映が終わったのが2022年11月。ここから編集部での作業になります。編集部では自分の書籍以外にも、出版を控えている書籍がたくさんあるため、それらの出版日は編集部の事情で決まります。そういったことから、本書の制作はちょっとの間お休みの期間があり、2023年に制作が再開。このたび無事に発売となりました。

この本が皆さんのお仕事の現場に少しでもお役に立てるなら、書いた甲斐がありました。感想などぜひお聞かせください。

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をカレンダーに入れる、といったように相談の場をつくると、コーチ役が話を聞いてくれる。

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