kyon_mmのプロポーザル没ネタ集 #RSGT2020
このエントリは Regional Scrum Gathering Tokyo Advent Calendar 2019 - Adventar のエントリです。
昨日はharadakiroさんの Regional Scrum Gathering Everywhere - haradakiro's blog でした。キーノートとOSTを担当されたとのことでしたが、アジア圏でのScrumコミュニティでも私達とおなじような悩みをかかえているんですね。来年はいってみようかな。
さて、わたしはRSGT2020のプロポーザルが運よくとおりまして、チームの再定義という話をします。 => https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12223/-
で、そもそもプロポーザルに登録しなかったけど、こういったネタもあるにはあるんだよなーっていう一覧を紹介します。 たぶんRSGTにはむかないだろうなーってものもあるし、あとは自分が話したいのはやはり今とおっているものなのでどれもだしませんでした。 もし、これらの内容に興味があるかたは、社内でもオープンイベントでも呼んでください。話にいきます。 => https://kyon-mm.com / twitter @kyon_mm / FB Kyon MM
没ネタ一覧
- アジャイルにおけるシステムアーキテクチャ設計
- レトロスペクティブツアー という複数チームのプラクティス
- Scrum is dead. Long live the alliance.
- 大規模システム開発は予算のとり方にあわせた手法でしか幸せになれない
- チーム開発を10年勉強してわかった3つのこと
- アジャイルコーチと開発チームの2足の草鞋
- 私達がPullRequestよりもLimboを選ぶ3つの理由
タイトルだけだとあれなので、かるい説明をしていきます。
アジャイルにおけるシステムアーキテクチャ設計
これは最近発表している数理的システムアーキテクチャの話をよりアジャイル開発の現場でどう意味があるものなのか、どんな場面で役にたつのかという話になります。 数理的システムアーキテクチャ設計(αバージョン)のスライドはこちらです。 ソフトウェアシステム設計における アレグザンダー理論の活用 数理的システム設計手法の提案 #agileto2019 - Speaker Deck
レトロスペクティブツアー という複数チームのプラクティス
複数チームの全員参加で、他チームのレトロスペクティブを見てまわるというプラクティスです。これによる学びはかなりおおきいんですよね。 ということで、ここ数年いくつかの現場で導入、実践しているので、結果付きで話せたらいいなと。
Scrum is dead. Long live the alliance.
タイトルはあおりなんですが、まぁ大規模アジャイルの手法はどれもだめで、その理由とかです。 いくらかはRSGT2020ではなす、「チームの再定義」にも含まれる内容になります。
大規模システム開発は予算のとり方にあわせた手法でしか幸せになれない
これはタイトルのままです。予算への承認のとりかたがウォーターフォールだとアジャイルには開発がすすめられないとかです。
チーム開発を10年勉強してわかった3つのこと
これはまぁわたしの経験の話ですね。(それ以外もだろ!!!)
アジャイルコーチと開発チームの2足の草鞋
この1年は複業でアジャイルコーチと開発チームをやってきたので、その経験をただはなすかんじ。 https://kyon-mm.com で企業や学生へのアジャイルコーチ、 https://otr-jp.com でシステム開発という感じでした。
私達がPullRequestよりもLimboを選ぶ3つの理由
先日、masterブランチ一本でいいじゃんってかいたらいろいろ反響があったので、そのへんをまとめたやつです。 Limbo というのはこちらです => https://medium.com/@kentbeck_7670/limbo-on-the-cheap-e4cfae840330
関連書籍
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
- 作者:EstherDerby,DianaLarsen
- 出版社/メーカー: オーム社
- 発売日: 2017/07/15
- メディア: Kindle版
A Scrum Book: The Spirit of the Game
- 作者:Jeff Sutherland,James O. Coplien,Lachlan Heasman,Mark den Hollander,Cesario Oliveira Ramos
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2019/09/03
- メディア: ペーパーバック
- 作者:Rachel Davies,Liz Sedley
- 出版社/メーカー: オーム社
- 発売日: 2017/01/21
- メディア: 単行本(ソフトカバー)
JUnit5でテストに時間がかかりすぎたら失敗にする Timeout アノテーション
@Timeout で実行時間がかかりすぎていたらFailにする
自動テストの実行時間がかかりすぎているときには、Failにしたいということがたまにおきます。IOに依存しているテストではよくありますし、複雑なロジックをくんでいて無限ループになってしまったり、組み合わせ爆発がおきてしまったり。そういうのが予見されるときには個別に@Timeoutというアノテーションをテスト対象の範囲に最大実行時間を指定しておくことで実現します。
package junit5.timeout; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.Timeout; import java.time.Duration; import java.util.concurrent.TimeUnit; import static org.junit.jupiter.api.Assertions.assertTimeoutPreemptively; class TimeoutDemo { @BeforeEach @Timeout(5) void setUp() { // この中の処理で5秒以上実行してしまったらここでFailする } @Test @Timeout(value = 100, unit = TimeUnit.MILLISECONDS) // unit指定なし => 秒。 // unit指定 => nano秒から日まで指定できる void _100ミリ秒以上かかるとテストが失敗する() { } @Test void 非同期実行におけるタイムアウトはassertTimeoutPreemptivelyを使うと便利() { assertTimeoutPreemptively( Duration.ofSeconds(1), // なにか非同期で実行するもの。Executableをわたす。 () -> { }); } }
@Timeoutはクラスにつけたら、@Testや@BeforeEachなどのそれぞれにつけたのと一緒の動きになります。 もちろん、@Nested がついたクラスがインナークラスにいても動作します。
package junit5.timeout; import org.junit.jupiter.api.*; import static java.lang.Thread.sleep; // ClassにもTimeoutをつけられる @Timeout(2) public class TimeoutClassDemo { @BeforeEach void setup() throws InterruptedException { sleep(1_000); } @Test void some_spec_1() throws InterruptedException { sleep(1_000); } @Test void some_spec_2() throws InterruptedException { // Timeoutよりおおきいので失敗する sleep(2_100); } // Nestedの中でもClassにつけたTimeoutは有効 @Nested class SomeContext { @BeforeEach void setup() throws InterruptedException { sleep(500); } @Test void some_spec_3() throws InterruptedException { sleep(1_000); } @Test void some_spec_4() throws InterruptedException { // Timeoutよりおおきいので失敗する sleep(2_100); } } }
リポジトリ
GitHub - kyonmm/junit5-timeout
参考書籍
- 作者: Kent Beck,和田卓人
- 出版社/メーカー: オーム社
- 発売日: 2017/10/14
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
Java本格入門 ?モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで
- 作者: 谷本心,阪本雄一郎,岡田拓也,秋葉誠,村田賢一郎
- 出版社/メーカー: 技術評論社
- 発売日: 2017/04/18
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 池田暁,鈴木三紀夫
- 出版社/メーカー: 技術評論社
- 発売日: 2019/04/13
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
既存のシステム設計手法ではつらいので、数理的システム設計という手法をつくった #agileto2019
現代のソフトウェアシステムにおけるシステムアーキテクチャ設計手法や、それらをとりまく各種手法は素晴しい。だけど、わたしはまだまだもっと理想にちかづきたい。 そんな思いから課題をみつめて、自分なりに設計手法をつくってみました。 いまはこれを数理的システム設計とよんでいます。まだαバージョンくらいです。
いままでも、これについては筑波で2度勉強会をしており、今回はAgile Tour Osaka 2019で講演してきました。
アジャイル システム設計 Meetup - connpass
システム設計ハンズオン勉強会 -リジェクトすえなみチャンス暑気払い- - connpass
Agile Tour Osaka 2019 × miniPLoP 2019年11月9日(大阪府) - こくちーずプロ
で、今回はたぶんはじめてスライドを公開しました。 スライドにある通りですが、基本的には僕の経験のみの話で、業界にたいする評価とかではありません。
- アイディア、仮説、要求 と アーキテクチャ へのギャップがおおきく、それによってビジネスの可能性を小さくしてしまっていたり、技術進歩への追従がしにくくなっていたりする。
- 主観的に機能や仕様の配置をしてしまうことによって、システムの無駄がおおくなる。
- 機能に依存した設計をすると、変更によわくなる
おおまかにはこのへんの課題意識があって、これをかいけつするために、より要求などによりそいながらも、アーキテクチャとしてつくるものを想像しやすく、数理的な手法があればいいのではないだろうかという気持ちがうまれました。
そこで参考にしたのが、クリストファーアレグザンダーの The Nature of Order 15の幾何学的特性です。 建築をはじめとして、美しい設計というのは15の幾何学的特性をもっていると発見したというのが彼の主張です。
ということで、これによってシステムを設計してみようということで手法としてつくりあげたのが、この数理的システム設計です。
スライドにもあるようにたくさんの課題がありますが、ITをつかったシステムが巨大で複雑化していくなかで、よりアイディア、仮説、要求などと具象的な技術をつなぐ設計手法として大成できていけたらいいなとおもっています。
これに付随してさまざまな設計手法について勉強するようにもなったのもこの数年の成果かもしれません。
で、またこれのはなしをかるくさせてもらう機会をいただきました。
数理的システム設計以外についてもシステム設計、アプリケーション設計についてはいくばくか詳しいつもりなので、登壇、研修、実務でのアーキテクト業などのご依頼もおまちしております。 kyon-mm.com
参考書籍
- 作者: クリストファーアレグザンダー,Christopher Alexander,中埜博
- 出版社/メーカー: 鹿島出版会
- 発売日: 2013/09/11
- メディア: 大型本
- この商品を含むブログ (2件) を見る
- 作者: クリストファーアレグザンダー,Christopher Alexander,稲葉武司,押野見邦英
- 出版社/メーカー: 鹿島出版会
- 発売日: 2013/12/04
- メディア: 単行本
- この商品を含むブログ (14件) を見る
クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う
- 作者: 長坂一郎
- 出版社/メーカー: 彰国社
- 発売日: 2015/06/27
- メディア: 単行本
- この商品を含むブログ (2件) を見る
Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)
- 作者: RobertC.Martin,角征典,高木正弘
- 出版社/メーカー: ドワンゴ
- 発売日: 2018/08/01
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: ニック・ロザンスキ,オウェン・ウッズ
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2015/06/11
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: Sam Newman,佐藤直生,木下哲也
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/02/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
- 作者: マーチン・ファウラー
- 出版社/メーカー: 翔泳社
- 発売日: 2016/02/19
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
- 作者: Neal Ford,Rebecca Parsons,Patrick Kua,島田浩二
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/08/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
情報アーキテクチャ 第4版 ―見つけやすく理解しやすい情報設計
- 作者: Louis Rosenfeld,Peter Morville,Jorge Arango,篠原稔和,岡真由美
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/11/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
- 作者: 東京工業大学エンジニアリングデザインプロジェクト,齊藤滋規,坂本啓,竹田陽子,角征典,大内孝子
- 出版社/メーカー: 翔泳社
- 発売日: 2017/12/15
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
レゴスクラム研修を筑波技術大学の先生達に提供した話 #lego4scrum
個人事業主うさぎ組 kyon-mm.comでは、スクラムやアジャイルの研修も仕事にしています。 今回はenPiT ビジネスシステムデザイン分野でずっと一緒にお仕事をしている、筑波技術大学 渡辺准教授の職場でスクラムを知ってもらうという目的で研修をしてきました。渡辺さんが声をかけてくださった先生方を対象にという感じです。 その様子を紹介します。
座学
私からアジャイルマニフェスト、スクラムガイド、アジャイルの各手法の関連などを整理して、概観を説明しました。 その後、参加者同士で座学の内容を振り返ってもらって質問を出してもらい、回答したり議論をしたり。 ここで想定以上の量の(しかも良質な)質問が出てきて、議論が盛り上がりました。 ほとんどの参加者がアジャイル開発の経験がないにも関わらず、なかなか鋭い質問があり、「本当にやったことないのかな。。。?」と思ってしまうほどでした。
レゴで街づくり
講師である私(プロダクトオーナー役)からレゴで作って欲しい街の情報を伝えて、あとは各チームで街を作ってもらいます。まずはどんな街にするのかを自分たちで考えて、見積もって、作ってみて、レビューして、やり方を振り返りして、とスクラムのスプリントを実践します。 今回の研修では3スプリント実施しました。
ペルソナについて議論したり、スプリント計画をしているときは各チームいろんな議論の仕方がありました。
ユーザーストーリーマッピングを使いながら、バックログを作って優先順位をつけていき、受け入れ条件を考えていくのも実践してみます。
チームごとに出来上がる街は最初は小さかったり、体験の設計が不足していたりしますが、どんどん良くなっていきます。お互いに「そういうのが得意なの?」なんて驚きもあったりして楽しそうでした。
スプリント毎にプロダクト、自分たちの進め方をふりかえって、自分たちのうまくいっているところや、なんとかしたいなーっていうところを話し合い、自分たちでどうしていくのかを考えていきます。
3スプリントが終わったら1日のふりかえりをして終了です。研修が楽しかった話や、得た学び、今後自分たちはこれをどうやって活かしていくのかなど議論は尽きませんでした。 生徒たちのことを熱心に考えている先生方、尊いわ。。。
まとめ
レゴ®︎によるスクラムの研修をソフトウェア開発などを教えている筑波技術大学の先生方とやってみてわかったのは、何かを模索しながら誰かに何かを提供する、学びについて普段から考えているという人にとってはスクラムの考え方はマッチしやすいのかもしれないと改めて気づかされました。 普段はソフトウェア開発企業の方々にレゴスクラム研修を提供することが多いのですが、もっと違う業界の方にも提供できると良さそうだなぁと。 もしご興味ある方いらっしゃれば https://kyon-mm.com や https://twitter.com/kyon_mm からご連絡いただければ!
あと、筑波はいいぞ!
チームはミッションのためだけではない。生き方そのものである。 #RSGT2020
Regional Scrum Gathering Tokyo 2020というカンファレンスのセッションは公募制で、私も発表してみたかったのでプロポーザルをだしました。 聞いてみたいかたはぜひ下のサイトでVoteしてもらえるとうれしいです。このプロポーザルにおいてどんな話をするつもりなのかをすこし紹介します。
1. セッション概要の引用
1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?
私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。
異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。
2. チームとはなんのためにあるのか
わたしが今まで読んできた書籍であるとか、発表であるとか、会話のなかでは、チームというのはミッションのためにつくられるものであり、そのため同じ目的をいかに共有するのか?という話に焦点があてられていました。 ほかにもチームとグループはちがうとか。ビジネスの世界ではそうだという話がおおくあるとおもっています。
では、プロジェクトがことなれば、ミッションが細分化されていれば、それはチームとはよべない。そういうことになります。そうしてチーム横断での仕事の仕方や組織作りになやむ。そうした日々をおくる。ありふれた風景におもえます。
我々基盤チームも事実上の解散になり、そうなるのかとおもっていました。 でも、我々は基盤チームで仕事をしていくことに誇りをもっており、そしてなによりこのメンバーと仕事をし、失敗も成功もかみしめ、成長をしていくその過程が楽しいとおもってこの5年間をすごしてきました。
ミッションがことなっていても、チームとして存続する方法を模索する。そんな挑戦をはじめました。
3. フラクタルスプリントのスケールアウト
我々がしっている古典的なチーム横断は2つです。横断組織をつくる。そして期間の長いタイミングもしくはアドホックなタイミングで情報の同期をつくる。 これをやっていてはおおきなチームとしては成立しない。基盤チームはこれをかえるために、プロジェクトがことなってもフラクタルスプリントをすることにしました。
なので、プロジェクトがことなるチーム同士で、15minスプリント、1Hourスプリント、1Dayスプリント、1Weekスプリントを実施しています。つまりフラクタルスプリントを複数チームにスケールアウトさせました。
これによりミーティングの時間はのびたりのびなかったりしていますが、我々の経験上、目安時間からずれてしまうの修練上の誤差のようなものであり、メンバーは「いまは修練の時だ」という認識でただひたすらにこのスケールアウトされたフラクタルスプリントをいかに上手につかいこなすのかということをかんがえています。
4. 発表ではなすこと
おおくの組織でチーム同士をつうじた組織の成長、多層な学習、という課題があるとおもいます。事実わたしの仕事ではほとんどがこういった話題です。
まだ小さな事例ではありますが、複数プロジェクトにおいても同期されたスプリントを実行するとえられる効果。そしてこの手法の転用方法や展開についてをはなせるとおもいます。
また、この考え方の根本ともちかい進化心理学からみたアジャイル開発についても話をすることになります。 チームとはミッションのためだけにあるものとかんがえることが、可能性をせばめているときづいた話です。 言い換えれば、なぜ人間はチームを作りたがるのかということについて学術的な側面と、経験的な側面について話します。
アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/01/18
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 12回
- この商品を含むブログ (21件) を見る
- 作者: ロビン・ハンソン,ケヴィン・シムラー,大槻敦子
- 出版社/メーカー: 原書房
- 発売日: 2019/02/27
- メディア: 単行本
- この商品を含むブログを見る
Re: モッククラス、下から見るか?横から見るか?
先日Twitterでリプライがきたのでみてみたら素晴らしいブログ( モッククラス、下から見るか?横から見るか? )がありました。
プログラムにおける自動単体テストでモックをつかうべきかどうか悩んでいるというもの。
私なりにこれに回答しようとおもいます。みんなもなにかおもうところがあれば、SNSではなくブログにしてほしい。(Webからそのままアクセスできるという点において)
- 1. 基本方針
- 2. 仕様化テスト、レガシーコード改善、リファクタリングでつかう
- 3. トランザクションのcloseなどの後処理を確実に検知する。Rxや一部の書き方によってtry-with-resourcesがつかえなくても。
1. 基本方針
- 可能なかぎりモックライブラリはつかわず、コンストラクタDI(Dependency Injection)で解決できるならそうする
- 往々にして厳密な単体テスト(1ファイルにとじたテスト)はしておらずコンポーネントテスト(複数ファイルにまたがったテスト)がおおい
2. 仕様化テスト、レガシーコード改善、リファクタリングでつかう
自動化されたテストがなく、これからリファクタリングをしたいというときには、既存のプロダクトコードを変更せずに自動テストを実装すべきです。そのときには時刻やDBやAPIなどに依存したコードをテストしなければいけないでしょう。
テスタビリティの低い設計ではこれらを「テストから設定」することがむずかしかったり、高速な単体テストとすることがむずかしかったりします。そのときには、モックライブラリをつかって時刻やDBやAPIなどをテストダブル(スタブやモック)におきかえます。
モックライブラリは実質的にリフレクションなどをつかっているものがおおく、プロダクトコードを変更せずにプログラマーが自由なコードで一部の処理を代替させることができます。これによって自動テストを実行できるようにしてから、徐々にリファクタリングをすすめていく。という場面ではモックライブラリが適切でしょう。
3. トランザクションのcloseなどの後処理を確実に検知する。Rxや一部の書き方によってtry-with-resourcesがつかえなくても。
たとえばトランザクションやコネクションのコミットやクローズ処理が確実にされているかを検知したい場合につかえます。 単体テストのメリットとして、IO処理が失敗した場合を簡単に模倣できるという点があります。それ自体はコンストラクタDIな設計における簡易なテスト用のスタブクラスでもできます。
ですが、たとえばDB操作が失敗したときに必ずコネクションがcloseされていることのテストはなかなか検知できません。モックライブラリであればできます。 もちろん静的コード解析でも対応できる部分はありますので、一概にモックライブラリでやるべきとはいいませんが、なかなかに便利なときがあります。
Javaだとtry-with-resourcesとかでかいておけばいいじゃんというのもありますが、rx系というかpromise系というかのライブラリをつかっていたり、いくつかの設計においてはtry-with-resourcesをうまくつかえないことがあります。そのときには、モックライブラリで検知させるというのは妥当だとかんがえています。
実践テスト駆動開発 (Object Oriented SELECTION)
- 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘
- 出版社/メーカー: 翔泳社
- 発売日: 2012/09/14
- メディア: 大型本
- 購入: 4人 クリック: 262回
- この商品を含むブログ (31件) を見る
- 作者: Kent Beck,和田卓人
- 出版社/メーカー: オーム社
- 発売日: 2017/10/14
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
- 作者: Joshua Bloch,柴田芳樹
- 出版社/メーカー: 丸善出版
- 発売日: 2018/10/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
スクラムフェス大阪で基調公演。もしくはJASRACへの支払い #scrumosaka #agileradio
2/22 - 2/23 に開催されたスクラムフェス大阪にてKeynoteを担当させていただきました。 @TAKAKING22 くんと一緒に壇上に上がる日がこうやってくるとはおもってもみませんでした。 テックカンファレンスで世界初「オープニングムービー + 入場曲 + ジャズピアノ生演奏 + メイキング映像 + アンコール + キーノートタイトル参加者で議論」という構成でおとどけしました。(要出典)
本エントリでは、なぜこうできたのかの一部、また、日本で楽曲を使用するときに課題になる JASRACへの対応方法をのこしておきます。
なぜこの構成にできたのか
この辺の大枠は先日出演させていただいた #agileradio にて軽くはなさせてもらいました。
Scrum Fest Osaka 2019 トーク その1 | アジャイルラジオ
簡単にまとめると次の流れでした
- 大切にしたいことは 2018/12に @TAKAKING22 と きょんで決定
- アイディアを RSGT2019 の OSTの1セッションで議論
- OSTにて「アンパンマン」「生演奏」「脇役としてのキーノート」というアイディアがかたまる
- 2日後の1/14 に企画提案、プランニング
- 以後怒涛のプレゼンテーション、編曲、練習、動画編集、構成をねりなおすの制作1ヶ月をすごす
いやー、本当にたのしかったです。 アーティスト活動のさわりをやったのかなっておもうんですが、たしかにこれはたのしい。 バンド活動していたり、絵をかいたりする人達の気持ちがすこしだけわかりました。すごいな。
これは結果であって、なぜこうできたのかという話ですね。僕の中ではだいたい次の要素が強かったなと。
- @TAKAKING22 と きょんが大枠で信頼しあえる仲であった
- @TAKAKING22 がプロレスやアイドルという「エンターテイメント」を好きでありよく見ている
- ジャズピアニストがきょんが所属する基盤チームにいた
- きょんの夢がエンジニアで東京ドーム公演であった
- きょんが昔、ニコニコ動画でアンパンマンのジャズアレンジを聞いたことがあり感動していた
- @TAKAKING22 や きょんを信頼してくれる仲間がいた
どの要素も重要だったのかなーとおもいました。どれかが欠けてもこの構成にはならなかったのではないだろうか。 そしてこの企画をうけいれてくれた 運営および参加者に感謝しています。
楽曲の使用。JASRAC
生演奏するということで、JASRACとのつきあいが必要になりました。 先日料金をおさめたので、そこまでの流れは次のとおりです。
- 会場がJASRACと契約しているかを調べる
- 会場の定員数、チケット代、利用する楽曲のJASRAC登録されているか検索、利用するときの長さを確定する
- オンラインで見積もりをしてみる
- 開催5日前までに申請書を書いて会場最寄りのJASRAC支社に郵送する
- 後日電話で詳細の確認がくる
- 請求書が送付される
- 振り込みをして完了
大学とかで開催する場合でも、きっと音楽教室みたいなところはJASRACと包括契約している場合があるかとおもいます。一般的にはライブハウスとかです。 今回の会場はどうも契約していないのではないかということだったので、2にすすみました。 基本は会場の定員数で料金がきまります。利用するときの長さはメロディをどれくらい演奏するかです。今回のわたしたちの構成はメロディ部分はすくなかったので料金をおさえられました。 楽曲はこちらから検索できます。
見積もりはこちらでできます。
これでだいたいの料金がわかるとおもいます。 ちなみに私は「ファッションショー」みたいなもので見積もりをしました。
ここからは郵送してうんぬんです。公式に手続きの流れがあるのでリンクを。
スクラムフェス大阪は会場が大阪だったので大阪支社に郵送しました。 そうすると後日、イベントの概要とかいろんなことを電話で5minくらい確認してくれます。そりゃIT系のカンファレンスで生演奏してとかわけわからんですよね。。。
で、後日請求書がとどくので振込みをします。 こんな封筒です。
まとめ
最&高なプレゼンテーションのありかたを模索していきたい。大切な1歩をふみださせてくれたみなさまありがとうございました。 どのような形になるかはわからないけれど、ご依頼うけつけております。一緒につくりだせたらとおもいます。