失敗を許容するファンディング

昨日はカンファレンスのキャッシュフローについて書いてみたのですが、意外と大変という反応もいただきました。

カンファレンス運営のキャッシュフロー - kawaguti’s diary

これは考えようなのだと思いますが、私が一番避けたいな、と思うのは、こういうことです

  • 答えのない問題に、集団で悩む
  • 誰かにご迷惑をかけて、平謝りする
  • ご支援をいただく代わりに精神的物理的な対価を求められて気を使う
  • 忙しくて、楽しめない
  • なにか価値のあることをやりたくなった時に、できない
  • 誰かの責任を問う
  • あらゆる意思決定にフィルタを入れる(常に慎重を期すとか)
  • 状況がわからないまま議論する
  • 未来を信じてとにかく走る(強迫観念)
  • 不安で死にそう
  • 孤独で辛い
  • 誰かのために自分を犠牲にしている感覚に酔う
  • 徒労感
  • 「大変だったけど終わったから忘れよう!」

これら避けたいことの、割と多くの部分が「具体的で実現可能な案があれば発生しない」んじゃないかと思っています。そして、そのような具体案の実現性を維持するために「資金的なリスクと余裕を適切に管理できている」「タイミングが良い」というあたりが重要なのだと思います。(わぁ、プロダクトオーナーシップっぽい!)

そこに向けての具体的なプラクティスとして、タイムラインを引いてキャッシュフローを管理することが有効だと考えています(カンファレンス運営のキャッシュフロー - kawaguti’s diaryはそのお話でした)。そして長期的には、将来に向けての余裕を作っておくことも、やっておけるといいなぁと思います。

もちろん各回のカンファレンスを良い場所にするということが第一のゴールなので、それを満たした上で、ということになりますが。

f:id:wayaguchi:20181228052019j:image

多少の失敗は許容できるカンファレンス運営にできるといいなと思っていて、そのためにちょっとだけお金のことを考えるだけでだいぶ楽になりそう!....なんて考えてまして、そういうことがおすそ分けできたらいいなと思って、ブログにしてみました。

f:id:wayaguchi:20181228051200j:image

蛇足ですが、法人税まで払っていたりします。日本の財政は世界的にもやばいレベルっぽいので、ちょっとでもお役に立てれば幸いです。微々たるものですが。

ボランティアワークでなければそんな余裕も生まれませんので、スタッフの皆さんに本当に感謝です。

 

あ、さらに蛇足ですが、Beyond Budgeting (脱予算経営) という概念について - kawaguti’s diary あたりもちょっと念頭にあります。

カンファレンス運営のキャッシュフロー

このエントリはRSGTアドベントカレンダーの非公式な27日目の記事です。

adventar.org

昨日は非公式な26日目としてきょんさんが「#RSGT2019 の歩き方 - うさぎ組」について書いてくれました。当日どんな風に過ごしたらいいか、大変参考になるお話だったかと思います。私は前回「RSGTのセッション採択はどのように決まるのか - kawaguti’s diary」というのを書きました。カンファレンス関係者しかうれしくなさそうな内向きの記事だったわけですが、長らく書き出そうと思って書いてなかった内容だったので、個人的には大変満足しています。

あと、ログミーさんの方で、昨年の基調講演であった河野通宗さんの記事がでています。改めて読み返して、本当に素晴らしいお話だったなと思います。

logmi.jp

さて、今日のお話は、またカンファレンス運営に関する話をしようと思います。 

 

非営利カンファレンスのキャッシュフローの話

 RSGTはカンファレンス自体で収益を出すことを目標にしていないカンファレンスです。スタッフも給料や日当をもらわない、ボランティアでの参加が基本です。とはいえ、会場費や通訳などのコストはかかりますし、参加料やスポンサー料などもいただいております。

 もともとスタッフが手弁当で始めていますので、なんらかの資金のバックがなく、損失が出れば実行委員が支払う必要がでてきます。また、途中でキャッシュが底をついてしまうと、一時的にせよ実行委員が補填しなければなりません。そういったあたりのファイナンシャルリスクを避けて、どのように安全にカンファレンスを行うかは、非常に大事な問題です。

 では、カンファレンス開催日までにどのようなキャッシュイン、キャッシュアウトがあるのでしょうか?

f:id:wayaguchi:20181227153652j:plain

開催日までのタイムライン

まず、会場を借ります。多くの会場で前金での入金が必要になります。(企業さんなどで、無料の会場をお借りできれば、コストが大幅に下がりますが、その分、中の方が動かなければならない部分が多くなったりします。)

f:id:wayaguchi:20181227153743j:plain

会場を借りる

昨年からの蓄積がないと、まずは借金から始まるのです。いずれ参加費やスポンサー料などの収入を得られれば返済できるのですが、回収までの期間は短い方がいいです。そこで、アーリーバードチケットを設定し、早めに払っていただける方の協力を求めます。この時点ではコンテンツが決まっていない状態ですので、それでも支払っていただける皆様は、カンファレンスを支えてくださるコアな顧客層ということができると思います。本当にありがたいです。

f:id:wayaguchi:20181227153827j:plain

アーリーバードチケット売り出し

またスポンサーさまにも協力をおねがいします。法人様は一社当たりの金額が大きいため大変助かるのですが、支払いが請求書ベースでになることがあるため、キャッシュフローには注意が必要です。RSGTに関して言えば、早めにお支払いいただけるスポンサー様が増える傾向にあり、非常にありがたいです。

f:id:wayaguchi:20181227153850j:plain

スポンサー様にも呼びかけ

開催1ヶ月前くらいまでに、アーリーバードやスポンサー様のご協力が十分に得られれば、会場費を回収して、ノベルティへの投資に回せるようになります。ノベルティとして優先なのは、まずは名札とストラップです。支払いの証明にもなりますので、ストラップはカンファレンスごとにデザインを変え、年号入りのものを作るのがよいと思います。お土産にもなりますし。

また、このあたりには全てのセッションを確定させます。このあたりで、企業から業務として参加する人にも、カンファレンスに参加することでどんな効果があるのかを説明しやすくなるのではないかと思います。

f:id:wayaguchi:20181227153915j:plain

黒字ならノベルティーが作れる

開催2週間前くらいからは、もし資金的に許すならば、飲み物やお弁当の手配を行います。ビデオ機材などレンタルものも調達をかけます。

f:id:wayaguchi:20181227153951j:plain

通訳代をはじめ、請求書支払いで対応していただける業者様に関しては、後日支払いになります。ですのでカンファレンスの1ヶ月後くらいに、やっと全ての収支が〆になります。

f:id:wayaguchi:20181227154026j:plain

後日清算のものもある

 もしこの時点でさらに資金に余裕があるならば、法人税を支払って翌年に繰り越します。そうすることで、翌年は会場代のマイナススタートを避けられるかもしれません。

 

キャッシュフローに基づく計画 

 ここまで説明したキャッシュフローのモデルを念頭に、時系列で大まかにキャッシュイン/キャッシュアウトを対応させて、計画していきます。同時期までのキャッシュインが少なければ、対応するキャッシュアウトを抑制します。入ってきた分は使えるが、入らなければ使わない、ということで全体が赤字になるリスクを抑制していきます。逆にキャッシュインが増えれば、きちんとコストを使って来場者向けのサービスを拡充していきます。

  • アーリーバード参加料、初期のスポンサー料 -> 会場代と基調講演の講演料など
  • スタンダード参加料、中期のスポンサー料 -> ノベルティや当日費用
  • 後払いの参加料やスポンサー料 -> 後日清算のもの

例えば、中期でチケットやスポンサー料が少ない場合は、ノベルティや当日費用をカットしていきます(作らない、出さない)。

また、前倒しでキャッシュインがあればあるほど、安定した運用や迅速な意思決定が可能になります。

 RSGTでは、キャッシュフローの状態を常に把握する「票読み」と呼ぶ Excelを随時アップデートして、常にキャッシュフローの予測をたてています。

 

テールリスク(あまり発生しないが大きいリスク)について

 私はまだ経験したことがないのですが、気象条件によってはカンファレンスを中止せざるを得ないこともあります。そのようなケースでも大きな負債を抱えないためには、ある程度の資金的な余裕を持っておくことが望ましく、営利が目的ではないのですが、継続的な開催のためにはある程度の資本蓄積は必要であろうと考えております。(もしくは企業や団体の後ろ盾が欲しくなります)

 以上、カンファレンスのキャッシュフローとその計画の考え方をご紹介しました。一つの考え方に過ぎないので、色々な正解があるのだろうと思います。

 

謝辞と恩送り

上記のようなことができるのは、実行委員、スタッフ、参加者、スポンサーの皆様のご協力の賜物です。本当にありがとうございます。

また、2011年に開催した勉強会カンファレンスで、いくつかの大規模非営利カンファレンスの先達から知見をいただきました。現在に至るまでこの時のご意見は大変役立てさせていただいております。ご登壇いただいた皆様には足を向けて眠れないといつも思っております。

kawaguti.hateblo.jp

 

OSCの宮原さん、RubyKaigiの高橋さん、LLイベントの法林さん、CEDECの吉岡さんをお迎えして、1000人以上のカンファレンスを支える意思やノウハウを共有しようというセッションでした。私が進行をさせていただきました。

1000人以上ともなると、そこにかかるコストや不確実性も大きなものになります。
会場代、飲食の手配、スポンサーの獲得、チケット販売、入金までの資金繰りをどうするか(そのリスクをどう分担するか)、など、非常に多くの不安要素を抱えることになります。

年度を越えると、その年の剰余金のなかから、法人税と事業税を支払う必要があります。簡易計算ではだいたい40%くらいらしいです。各カンファレンスで利益を出して翌年に繰り越す場合には、税に関する費用と手間がかかってしまいます。

他にも、アジャイルジャパン、デブサミ、JaSSTを通じて多くの知見をいただきましたし、私も実行委員として参画したXP祭り楽天テクノロジーカンファレンスでの経験/実験は大きな糧になりました。

イノベーションスプリントでピークワンさん、RSGTで翔泳社さん、楽天テクノロジーカンファレンスでCNSさんといったイベントを運営されている皆様と一緒にやらせていただいたことも、学びが多かったです。

みなさまに、大変感謝しております。ありがとうございました。

恩送りといってはなんですが、大阪のスクラムフェス大阪、東京のDevOpsDays Tokyoでは、開催ノウハウの伝達をお手伝いさせていただいております。

 

 

集まったら協調作業しようという文化

ykmc09.hateblo.jp

横道さんにやたら褒めていただいたRSGT実行委員会の作業ですが、一つ大事な文化があるとおもってます。「集まった時に、議論や検討より、できる限り作業を進める」という文化です。

どうしてもみんな集まった時に議論とか意思決定をやりたくなっちゃうんですよね。いろいろ決めるんだけど、そのあと別れてからの実行ができなくて、次に集まった時にまた同じ議論しちゃったり....。前に来てなかった人が蒸し返して、進めてる人との間で雰囲気悪くなったり。

これ原因は、作業が前に進んでないところだと思うんです。特にコミュニティは主業務じゃないでしょうから時間取るのも大変。そりゃうまくいかないです。

作業を終わらせるために意思決定するわけですから、時間内に作業まで進めれば、結果見てOK/NGのフィードバックも得られます。セッション募集などすぐに結果がわからないものも、作業結果(募集サイト)を公開することで、少なくともフィードバックを得る準備ができる。

 

スクラムではデリバリーにフォーカスする

プランニングと実行とフィードバックが繋がっているのがスクラムのポイント。プランニングに時間をかければ実行の時間が減る。だからシンプルに決めてシンプルに実行したい。そんな風に思っています。なので、集まった時に手を動かしたい。

集まった時に意思決定と計画だけで終わるのは、ちょっとウォーターフォールっぽくて、そのあと思った通りにいかない場合に、問題の発見も遅いし、対応も効かないし、疲れますし、誰かを責めたくなりますし、仲も悪くなりがちで、遅い。

f:id:wayaguchi:20181212185318j:image

写真は Scrum Coaches Retreat で手を動かす人々

 

ちょっと言い過ぎかもですし、そんなうまくいくことばかりじゃないのですけど、でもやっぱり早めに試す方が危なくない気がします。早めに失敗がわかればまだ取り戻せる可能性が高いです。だから、話し合ったり決めたりするだけじゃなくて、やってみて見通しを持つとこまで時間内にやりたいと思うんです。

私たちはだいたいこんなことを考えているのですが、なにか皆様のご参考になれば幸いです。

札幌スクラムトゥギャザーリング2018 に行ってきた!

この記事は、札幌スクラムトゥギャザーリングのスタッフの いづいづ (@izumii19) | Twitter さんのアドベントカレンダーの一つとして書きました。

adventar.org

 

札幌スクラムトゥギャザーリングとは!

札幌でスクラムのイベントやりたいですね、という話をねもとさん(@nemorine)とずっと言ってて、一昨年は山口さん(@teyamagu)、昨年は私がJaSST Hokkaido の基調講演に呼んでいただいた縁もあり、楽天の札幌支社とのご縁もあり、たびたび話しながら、ちょっとずつ実現に向けて、札幌のみなさまが動かれてきました。9月の地震と大停電での延期を乗り越えて、ついに実現したイベントでした。いづいづさん自身によるレポートはこちら

f:id:wayaguchi:20181123132625j:plain

手描きイラスト入りの案内板が豪華

 早朝の飛行機が遅延なく飛んでくれたおかげで、朝一から参加することができました。最初のセッションは「20分でわかるスクラム」。

f:id:wayaguchi:20181123102844j:plain

開幕!

そのあと、札幌スタッフが作った紙粘土を使ってスクラムを体験するワークショップに入りました。私は基本的にお菓子の補給を切らさない担当を勝手にやりました。銀河英雄伝説を引くまでもなく、補給重要です。自分で食べるためじゃないですよ!食べたけど。コーヒーおいしかったです。

このワークショップがどれくらいよかったかは、写真の真剣な顔や笑顔を見ていただければ伝わるかなと。

f:id:wayaguchi:20181123150041j:plain

オリジナルのワークショップ中

f:id:wayaguchi:20181123132739j:plain

充実のお菓子神社

さて、私のパートは一番最後の時間枠でして、ギリギリまでなにやるか決まらなくて唸ってたのですが、私がスクラムを始めた頃の話をしたあと、Fun! Done! Learn! を体験してもらうことにしました。

f:id:wayaguchi:20181123173624j:plain

Fun! Done! Learn!

スタッフの皆さんもやられていたのが印象的です。Fun! Done! Learn! はチームのやったこと(事実)を言語化するので、カンファレンス運営のふりかえりとも相性良さそうですね。

f:id:wayaguchi:20181123173842j:plain

スタッフのみなさんも Fun! Done ! Learn!

懇親会も二次会まで大変盛り上がって楽しかったです!

f:id:wayaguchi:20181212190536j:image

 

翌日は小樽・余市観光へ

翌日は、ねもとさんといづいづさんにつきあっていただいて、小樽観光へ。海の幸とか、日銀の旧小樽支店にある金融博物館とか、余市の燻製屋さんとか、堪能しました。

f:id:wayaguchi:20181124123442j:plain

翌日は小樽まで連れてってもらってお金について学習しました

最後に小樽駅から空港に向けて快速に始発乗車。日本海側の眺めの良い席を確保できました。すばらしい心遣いに大変感謝です。また来年、ぜひやりましょう!

f:id:wayaguchi:20181124154034j:plain

ねもとさん、いとうさん、ありがとうございました!

 

RSGTのセッション採択はどのように決まるのか

adventar.org

RSGTアドベントカレンダーの3日目です。昨日は天野さんが「僕がスクラムマスターになった訳 - はてブロ@ama_ch」という実践者ならではの記事を書いてくれました。こうした事例があるのも、この八年くらいで大きく変わったところで、大変頼もしいですね。今日はセッションの決め方について書いてみます。書いてみて思ったことは、これ興味あるのカンファレンスやる人だけじゃない?ということですが、きっと深読みすると様々なプロダクトバックログ作成にも通じるものがあるのではないかと思います。そう、これはプロダクトオーナーシップの話なのです!(どうかな?)

 

オープンプロポーザルとLike投票機能を使ったセッション採択の進め方

Regional Scrum Gathering Tokyo (RSGT) は、永瀬さんが書いてくれたような紆余曲折の結果、おかげさまで大変多くのセッション公募をいただくようになりました。全てのテーマをご発表いただくことができないので、採択するセッションを決める必要があります(Regional Scrum Gathering Tokyo において、たくさんの落選セッションが出てしまってごめんなさい。 - kawaguti’s diary)。ConfEngineでオープンプロポーザルとLike投票を行うようになってからは、だいたい毎年同じような決定方法になっています。RSGTにセッションを投稿いただいた皆様、Likeやコメントでお手伝いいただいた皆様へのご説明を兼ねて、ここにその概略のプロセスを書いてみます。

(ここではプロポーザルが集まってからの採択決定にかかわるプロセスについてだけ書きます。よいカンファレンスになるための前提として、よいプロポーザルがたくさん集まっていることが重要なのはいうまでもありません。RSGTに多くの素晴らしいプロポーザルを投稿していただいた皆様に大変感謝しております。)

目次

  • Like機能による投票
  • Likeはあくまで一つの指標
  • Likeが少なくても落選にしない
  • 一軍でカンファレンスの骨格を作る 
  • テーマを集めてトラックを形成する
  • 全体の流れをみながら、あいている枠に実行委員推薦のセッションを入れていく
  • 参加者のペルソナを想定してウォークスルーをする
  • そして寝かす!
  • 実は手間のかかる作業はここから
  • ここまででセッションスケジュールの作業は完了。最終チケット販売へ
  • 現在プロポーザル募集中のカンファレンスもあります!

 

Like機能による投票

RSGTのセッション公募にはインドの Naresh Jain氏が中心となって運営している ConfEngineを利用しています。ここ数年安定して運用されていて、グローバルなアジャイル系のカンファレンスでの採用実績が多いサイトです。リーンスタートアップを使って開発しているようで、カンファレンス運用者にとって楽になるような機能が必要十分に装備され、要望を出すと修正してくれたりします。

ConfEngineのセッション公募には、Like機能があります。誰でもアカウント(無料)を作ってログインすれば、セッションプロポーザルにLikeをつけることができます。カンファレンスごとにポイントが割り当てられていて、ポイントがゼロになるまでLikeしていくことができます。ポイントが底をついても、すでにつけたLikeを取り下げれば、その分のポイントは戻ってきます。また、自分で新しくプロポーザルを投稿したり、コメントをつけたりといった貢献をすることで、新たにポイントを獲得することもできます。

ConfEngineでの自分の持ちポイントは右上に表示されています。

自分の持ちポイントは右上に表示されています。

各プロポーザルの獲得したLike数はピンク色のハートマークの中に表示されます。

f:id:wayaguchi:20181202150304p:plain

獲得したLike数はハートマークの中に表示されます

このLike数が表しているのは、このセッションは「ConfEngineでログインした人の中で、どのくらい支持を得ているか?」です。RSGT全来場者に比べれば、ConfEngineでログインした人の数は決して多くありませんが、今回投稿した人は全員アカウントを持っていることになりますし、過去にプロポーザルを投稿した人も持っているので、気になったらLikeを押してくれているに違いありません。そのセッションに参加したい人の数を予測する上では、完全には程遠いかもしれませんが、手がかりとして非常に参考になります。

f:id:wayaguchi:20181202141524j:plain

Likeが多いのは参加したい人がたくさんいることを示す

Likeはあくまで一つの指標

Like数が多いから通過、とは限りません。実行委員としてはプロポーザルの持っているテーマがカンファレンスの全体像やカテゴリに合うかどうかをみながら採択するセッションを決めていきます。

ここ3回ほどのRSGT実行委員会では、特にLikeが多く、かつ内容がカンファレンスにふさわしいと考えられる一部のセッションを「一軍」と呼びました。(ちなみに一軍のLike数の基準ははっきりとは決めていません。採択の場で数や内容を見ながら決めます。)

また、Likeが多いセッションを一律に一軍に入れるわけではありませんので、結果的に落選してしまう可能性が出てきます。しかし、Like数は一部の参加者の声を反映していますから、落選にするには、説明を用意する必要があると考えています。(セッションの提案者が説明に納得していただけるとは限りませんが) 実行委員会ではかならずこの点を議論するようにしています。

 

Likeが少なくても落選にしない

なお、Like数が少ないセッションには2つの可能性があるとみています。一つは参加したいと考えた人が少ないケース。もう一つは、プロポーザルの投稿時期が期限ギリギリ(期間が短かったか、すでに多くの人がポイントを使い切っていてLikeできなかった)というケースです。このため、Likeが少ないからといって落選にはしていません。

あくまで落選とは、様々な理由で採択を試みたが採択の中に入れられなかったセッションということであって、なんらかの理由で落とされたわけではありません。

f:id:wayaguchi:20181202141529j:plain

Likeが少ないのは投稿が遅かっただけかもしれない

一軍でカンファレンスの骨格を作る 

まず一軍に選ばれたセッションでカンファレンスの骨格を作っていきます。最後の時間枠と最初の時間枠を埋めます。聴衆として、どういうセッションで一日を終わったら、前向きで、学びの多いカンファレンスだと思ってくれそうか、一番影響を及ぼすのは一番最新の記憶である最後の枠ですので、ここは重要だと考えています。

今回のRSGTでは、会場をほぼ同じ規模で2分割する都合上、どちらかに人気が偏ると集まったほうの部屋は環境が悪くなってしまいますのでそれは避けたい。ですので、最終枠は一軍がそろう、ということになります。(人気の高いセッションが裏番組になってしまうので残念だという声をいただくことも多いのですが、ここはご理解いただければと思います。)

そして、最初のセッションは基調講演後のランチ明けのセッションです。ここも午後のセッションを盛り上げるうえで重要な時間枠になります。

f:id:wayaguchi:20181205232450j:plain

最初と最後の時間枠が重要



 

セッションは公募の時点で希望する長さ(20分/45分/100分)を選んでもらっています。45分のセッションであれば、そのままスロットに納めます。20分のセッションの場合は、もう一つ20分のセッションと組み合わせて、45分の時間枠を埋めることになります。

f:id:wayaguchi:20181205231617j:plain

20ふんセッションは二つ入る

100分はワークショップルーム専用です。参加人数は20名程度に限られますが、じっくりと手を動かすワークショップを行うことができます。

f:id:wayaguchi:20181205231632j:plain

100分のワークショップ部屋

 いったん骨格を作ったところで、セッションのカテゴリをみながら、ばらつきが適切になるように、入れ替えたりして、整えていきます。例えばスクラムマスター視点で行くとどちらのセッションに行くか?これからスクラムを始めようとしている、ないし始めたばかりの人にとって参加できるセッションはあるか?あまりに似たようなテーマのセッションが裏番組になっていないか?などの観点です。

この時点で、全体の大枠が見えてくることが多いです。どういう風に会場の人たちが盛り上がるか、セッション概要をみながら想像します。

テーマを集めてトラックを形成する 

一軍には入らなかったがLike数が多かったセッションを中心に、近しいテーマで流れを作りながら、骨格以外の時間枠に当てはめていきます。今年の場合は、はじめての事例を20分枠で募集しましたので、事例を中心に二日目午後のトラックを形成しました。ここで同じ会社の事例が複数あった場合は、2つ合わせて45分セッションのような形にして、聴衆にわかりやすい流れを作ってもらうようお願いすることがあります。一方で、同じ会社から採択するのは3セッションまで、というルールを設けています。

f:id:wayaguchi:20181205232735j:plain

トラックを作る

今回は、概要の修正をお願いしたかったり、申請された時間枠が短すぎる/長すぎると思われる、など、課題が提案されたプロポーザルがいくつかあり、いったん「パーキングロット」に置いて、後の議論に回すか、発表者に連絡をとって情報をもらう時間を設けるようにしました。先にそういった課題のないセッションを当てはめて全体像を作ることを優先します。(これらの課題は実は公募期間中にも明らかであったと思われるので、コメントを付けるなどして事前に解決できていたらよかったのにね、という気づきはありました。来年頑張ります。)

ここまでの作業で80-90%の時間枠が埋まっている感じにします。後でまた変えるかもしれませんが、いったんは実行委員全員の目に具体的なセッション名が目に入るようにし、常に具体的な議論をできるようにします。(この時点で「こんなジャンルのセッションがあったらいいのに、応募されたセッションがない」という話になったら、来年の募集に生かすべきですので、メモしておきます。セッションが応募されてないのは、たぶん公募のときの説明に込めるメッセージが弱かったのでしょう。)

全体の流れをみながら、あいている枠に実行委員推薦のセッションを入れていく

Likeがそれほど多くなくても、テーマとして特徴があり、Like数の多いプロポーザルだけではカバーできない分野は、実行委員各員の推薦に基づいて採択の議論を行っていきます。このプロセスを行うことで、投稿時期が遅くLikeが多く得られなかったセッションにも可能性が残されます。

今回はこのプロセスの際に意見が割れたため、実行委員内の多数決によって決める場面がありました。概要がよく書けていたり、特色があったり、今回特にやるべき必然性があったり、著名な方で実績があったり、多様な優位性を持つセッションが複数ありましたので、最終的には投票という手段を取ることになりました。逆にいうと、ここまで投票はほぼ行わず、必ず実データをみながら議論によって決めています。人数が6-7人であるからこそ、具体的な議論をもって意思決定を効率的にできるのは、スクラムにおける開発チームとも共通していると思います。

参加者のペルソナを想定してウォークスルーをする

セッション全体が仮組み出来たら、いくつかの参加者のペルソナを想定してウォークスルーを行います。どういう参加者が、どのような順序でセッションを選択しそうか、ホワイトボードに線をひいて確かめます。このあたりは「ユーザーストーリーマッピング」だとか、「実践アジャイルテスト」で出てくるスチールスレッドと似ているといえばピンとくる方もいらっしゃるでしょうか。

ウォークスルーで問題が見つかったら、裏番組とセッションを入れ替えたりして、スムーズに興味のあるセッションに参加できるようにします。あるテーマでセッションを聞きたいのに、会場がころころ変わるようだと煩雑ですので、なるべくそういうことが起こりにくいようにセッションのならびを整えていきます。完璧はないですが。

また、セッションカテゴリの偏りがないか、特定のペルソナばかり聞けるセッションが多かったりしないかもチェックします。

ここまでの議論を経て、全体のセッションスケジュールをいったん確定します。

f:id:wayaguchi:20181202235139j:plain

今回の第一次案のホワイトボード写真。議論はこのホワイトボードとセッション概要を映すプロジェクタを使って行われる

そして寝かす!

ここまで、時に盛り上がりつつ、時に淡々とセッションの並びを議論しながら作ってきたのですが、フェイストゥーフェイスの議論は素早い一方で、一時の熱狂で決めてしまってあとで後悔した、なんて経験の一つや二つ、誰もが経験するところかと思います。ここは「ひとまず完成!」というところで作業を止め、数日の冷却期間を置きます。一晩寝たらおかしな点を思い出したり、見逃したポイントに気づいたりすることがあります。オンラインで引き続き議論する期間を取っておきます。この寝かす期間のうちに、当日参加できなかったメンバーが内容に追いつくこともできるでしょう。

実は手間のかかる作業はここから

採択が決定したセッションについてはスピーカーに登壇の意思確認を行う必要があります。そのためのメール原稿を用意します。辞退された場合にはセッションの組み直しが必要ですので、補欠リストも合意しておきます。今回は投票を行っていたので、票数が次点のセッションが補欠ということになりました。

採択セッションがすべて決まり、登壇意思も確認出来たら、次は落選のご連絡をすることになります。落選者にはなんらかのベネフィットをお渡ししたいので、出せるベネフィットの議論をします。今回はチケット枠の優先確保と割引の提供を行うことができました。

次回以降のチケット売り出しまでに、セッションスケジュールを確定し、公表します。今回は残念ながら11月売り出しにはこの作業が確定できず、12月売り出しまでに確定する形になりました。ConfEngineに詳しい委員がちょうど欠席していたり、運用上の課題がいくつか見えたところがありますので、来年に生かせればと思います。このあたりは複雑にしたところでカンファレンスの価値はあがらないので、もっと楽しよう、というのがコンセンサスです。

ここまででセッションスケジュールの作業は完了。最終チケット販売へ

以上でセッションスケジュールの確定しますが、まだ作業があります。

落選者向けのチケットのうち利用されないと分かった部分などを回収し、12月の最終販売チケットをねん出していきます。一枚単位で地道にカウントをしていく作業が続きます。

これらの作業を進めながら、「票読み」と呼んでいる月次キャッシュフロー表を更新して、ノベルティや、カンファレンス会場で使えそうな備品のコストを確定します。

ここは本当に担当している実行委員の努力に涙が出ます。

 

ということで、永瀬さんから発表があった通り、12月チケットの発売とボランティア募集があります。なんとかひねり出したラストチャンスです。ご活用いただければ幸いです。 

8回目のRegional Scrum Gathering Tokyo #RSGT2019 - ナイスビア珍道記

発売開始日時は、2018年12月11日(火) 12:00 pm(日本時間正午)です。
以下のURLからお申し込みください。
なるべく多くの方に行き渡るようにしたいため、複数枚購入はできません。
1回あたり1名のお申込みになりますのでご了承ください。

www.eventbrite.com

また、当日ボランティアも募集を開始します。
募集要項および応募はこちらから。
ご応募お待ちしています。
RSGT2019 ボランティア登録フォーム

 

現在プロポーザル募集中のカンファレンスもあります!

手前味噌で恐縮ですが、RSGT以外にも筆者が実行委員を務めるカンファレンスでConfEngineを利用したオープンプロポーザルを採用しています。いずれも現在プロポーザルを募集中ですので、発表できそうだ、という方はぜひ投稿をご検討ください。Likeやコメントも絶賛受付中です!

confengine.com

confengine.com

 

予想外の長文になってしまいました。お付き合いいただいた方、大変感謝です。

明日は、高柳謙さんのアドベントカレンダー四日目の予定です!

 

 

スクラムフェス大阪 (Scrum Fest Osaka) はじまります - 2/22(金)〜2/23(土)

大阪でも Regional Scrum Gathering Tokyo みたいなイベントやりたい!という有志が集まりまして、また東京の実行委員会からも支援を得て、Regional Scrum Gathering Osakaをやろう!と申請したのですが、年間にRegionalは一個くらいがいいなぁ、ということになりまして、改めて「Scrum Fest Osaka」として第一回を開催することになりました。スクラムフェス大阪って読んでください。

基調講演は、東京で毎回満席御礼の若手芸人のお二人をお呼びしています。きょんさんはスクラムをよりアップデートする「基盤チーム」というチームをずっと続けています。人間やめてもっとすごい存在になりたいとか、なかなか刺激的なことを言っていますが、冗談でなく大真面目。顧客の要望を高度な技術で高速に叶えていく挑戦を何年もしています。最近は15分スプリントに挑んでいるようです。振り切られないように頑張って聞きましょう。及部さんは昨年からモブプログラミングの伝道師として脚光を浴びています。開発者とビジネス側がなぜ分割するのかに疑問を持ち、また、ビジネス系の新人研修でプログラミングとプロダクト開発を教えるという取り組みをしています。控えめに言って最高のトークが聞けると思います。

基調講演以外のセッションはすべて公募制です。オープンプロポーザル方式ですので、どんなセッションが提案されているか、リアルタイムで見ることができます。RSGTとも共通のConfEngineというサイトを採用しています。ぜひサインインして、よさそうなセッションにLikeをお願いします。

confengine.com

セッション決定前まではチケットを割安で購入できます。
スーパーアーリーバードチケットは11/30まで。
売り切れる前に確保をお願いいたします。

www.eventbrite.com

スポンサーも続々と集まっております。プラチナスポンサーは売り切れ、現在ゴールド、シルバー、ロゴスポンサーのみの募集となりました。決定したスポンサーさんは順次掲載していく予定ですので少々お待ちください。募集要項はこちらです。

http://bit.ly/sfosaka2019-sponsorship

 

チケットサイトにある以下の写真は東京でのオープンスペースの様子です。Scrum Festa Osakaも参加者の距離が近い、みんなで語り合う会にできれば、という思いで実行委員一同準備をすすめています。ぜひ遊びにきてください!

f:id:wayaguchi:20181128160631j:plain

非アジャイルマニフェスト

アジャイルやってないんですよね」「うちアジャイルじゃなくって」っていう話をたまに聞くんですけど、「アジャイルじゃない」って、どういうことかなぁ、と思ったりします。

アジャイルアジャイルマニフェストで定義された言葉なので、その内容をみて、そうなっていない、というのが「アジャイルやってない」ということなのかな?

agilemanifesto.org

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

 

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。 

 

これをひっくり返して、アジャイルやってないケースを考えてみると...

  • 個人や対話より、プロセスやツールを重視してみたり
  • 動くソフトウェアより、ドキュメントが揃ってることが大事だと感じたり
  • 顧客と同じ方向をみるより、チキンレースや責任の押し付け合いをしてみたり
  • 変化への対応はほうっておいて、計画の未達成を問題視してみたり

だったりするのかな?まあ、これだけでなく、いろいろありそう。作ってみた感触としては、なるべく具体的に考えてみると、現状と理想的な状態との差分がわかりやすくなって、改善すべき点がつかめるかもしれないなとおもいました。

 

同じように、アジャイル宣言の背後にある12の原則の方も、職場によって状況によって、「本当は原則のようにありたいけど、現在の現実はちがうなぁ」というのがありそう。

 

アジャイル宣言の背後にある原則

私たちは以下の原則に従う:

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。

シンプルさ(ムダなく作れる量を最大限にすること)が本質です。

最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します

 

 私が書いてみたのはこれです。Scrum Coachin Retreat in Okinawa で、みんなでフィードバックもらっていい感じになってきたきがします。職場ごとに違う非アジャイルマニフェストがあると思いますけど。 

アジャイル宣言は、ものを作っている人にとっては、(理想として)同意できる内容だという人が多そう。だとすれば、アジャイル宣言の各項目をちょっと変えて(理想的でない)現在の状況を記述してみると、改善のヒントになりそう。書き出したら、そこから一つ一つ、よい方向に変えてみれば、幸せで成果の出る職場に近づくんじゃないでしょうか。

私としては、「アジャイルやってない」人に対して、現状どうなっているのか、あなたはどうしたいのかを、もう少し解像度上げて細く聞くきっかけにできるかも。

 

やってみたら、単純に楽しかったので、みなさんも自身の非アジャイルマニフェストを考えてみてはいかがでしょう!

 

アジャイルエンタープライズ (Object Oriented SELECTION)

アジャイルエンタープライズ (Object Oriented SELECTION)

 
Software in 30 Days スクラムによるアジャイルな組織変革

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド

 
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 

kawaguti.hateblo.jp