このエントリは、Reginal Scrum Gathering Tokyo 2022（以下RSGT2022）に向けたアドベントカレンダーの記事として書かれたものです。
今日はカンファレンスの運営について、ちょっと言語化してみました。
RSGT、スクラムフェス、DevOpsDays Tokyo
Regional Scrum Gathering Tokyo (RSGT) というカンファレンスを始めて、ちょうどこの10月で10年が経ちました。最初は「スクラムギャザリング東京」という名前で始めたのですが、私たちのカンファレンスをずっと支援してくれていて、世界中で Scrum Gathering というカンファレンスを主催している Scrum Alliance という団体の方で、同団体が直接運営しないカンファレンスを Regional Scrum Gathering という名前にしよう、ということになり、私たちもRSGTという名前で行うようになって、現在はこの名前が定着しました。
それと、スクラムフェス(Scrum Fest) というカンファレンスの実行委員をいくつかしています。スクラムフェス大阪というのが最初で、これは関西のスクラムコミュニティの人たちが、東京のRSGTに参加してくれていて、「こういうカンファレンスを関西でもやりたい」ということになり、じゃあ、Regional Scrum Gathering Osaka やろう！ということになったのですが、当時の Scrum Alliance の地域コミュニティ担当さん(RSGxxを支援してくれている人)が、「近い地域では一つずつにしたい」という意向だったので、その名前を使わず、別の名前をつけよう、ということでスクラムフェス(Scrum Fest)という名前になりました。Scrum Alliance の許可をもらわなくても開催できるので、結果的に、大阪、札幌、三河という感じに「スクラムフェス」が行われるようになり、来年は新潟が増える予定です。
もう一つ、DevOpsDays Tokyo というカンファレンスもやっています。これも RSGT みたいなカンファレンスを作りたい、DevOps という領域でやりたい、ということになって、2017年から開催し始めました。DevOpsDays というカンファレンスは、元々システムアドミニストレーターカンファレンスというのをはじめようと考えていた人たちが、2009年のFlickr社の発表に共感して、「DevOps」という名前が発案され、2010年からDevOpsDaysというカンファレンス名を冠して世界中で行われるようになりました(関連資料)。日本でも2012-2013年に行われていたんですけど、後を引き継いでやっている人がいなかったので、私たちが名前を使わせてもらうことにしました。
ということで、RSGTというカンファレンスを起点に、そこに共感してくれた人たちが、自分たちでやりたいカンファレンスを始めてくれている、というのがこれまでの流れです。このことは決して私が始めたことでも、私一人が行ってきたことでもないのですが、カンファレンスの運営について、ちょっと思っていることを書いておこうかな、というのがこのエントリの趣旨です。興味のある人だけ、ちらりと読んでいただければ幸いです。
Fearless Changeという本、リンダ・ライジング (Linda Rising) という人
勉強会というものを始めたのは、2009年からのすくすくスクラムというコミュニティからが本格的なところです。それまでにも、LLxx、RubyKaigi、オブラブ、XP祭りといったカンファレンスや勉強会には参加せてていただいたのですが、スクラムをはじめて社内でやるにあたって支援してくれた林栄一さんと、当時同僚だった江端一将さんが、自分たちで勉強会をやろう、ということになり、始めたのがすくすくスクラムでした。そのころ、Fearless Change という本がある、というのを江端さんがコミュニティの誰かに推薦されたということで、教えてくれて、その読書会をやろう、ということで、懸田剛さんや近藤寛喜さん、他にもいろんな人たちとその本の読書会をやりました。
この本の著者の一人、リンダ・ライジング (Linda Rising) さんは、米国のカンファレンス Agile 20xxでは知らない人がいない、という常連で、2011年の基調講演は私もレポートしました。
この著者らのアプローチが、パターンランゲージという手法を用いた、実践者による形式知の書き起こしと、実践者同士でそのパターン名をまさに「ランゲージ=共通言語」として、伝え合って活用しよう、というものです。Fearless Change では「新しい考え方を組織内に広めるためには？」という観点で、すでにうまくいった人たちの見識を集め、共通性のある項目について「パターン形式」で抽出・記述・推敲されています。そもそもアジャイルという新しいやり方が、まさに組織内でのコミュニケーションを必要としますし、それ以外にもさまざまな考え方の普及に役立つだろう、ということです。
また、この普及のアプローチそのものも、「トップダウンでやらせる」とか「声の大きい人に主導してもらう」のではなく、自分自身が実践者として、着実に周りを巻き込みながら、中長期的視野に立ってコミュニケーションをしていくという、まだに「アジャイルな普及方法」になっていることも、重要なポイントかなと思います。
新しいアプローチを導入したいなら、強制的に使わせるのが一番早い、という主張を聞いたことがあるかもしれない。もし一度した約束には絶対に従わなければならないとすれば、人はなるべく約束を回避するようになるだろう。王様が性急な改革を命令するかもしれないとわかれば、すぐに抵抗勢力が結成される。経営陣が「さあみんな、今すぐ＜イノベーション＞に飛び込もう！」と言えば、すぐに実現されるなんてことは期待できない。トップダウンの変化の特徴は、そのスピードにあるが、問題があればすぐに対応しなければならない。ボトムアップの変化はゆっくりだが、抵抗勢力への対応はもっと効率的にできる。ボトムアップな変化の特徴は、参加型、情報共有、不確実性、そして抵抗が最小限になることだ。私たちは経験上、現場管理職や上級管理者の適切な援護射撃をもらいながらのボトムアップな変化こそが最良と信じている。
アジャイルの本質 - 納期は決められないという現実を認める
「アジャイルな普及方法」ってなんだよ、という話になるのですが、この点については、ちょうど８月にあった Agile 2021 というカンファレンスで、アジャイルマニフェスト起草者の一人、エクストリームプログラミング(XP) の Kent Beck 氏が興味深いことを言ってました。
エクストリームプログラミングの原動力のひとつは、ビジネスとテクノロジーの間の溝を癒すことでした。私は、一般的に言われている2つのグループが激しく対立し、協力する方法を見つけても必要なものが得られないという状況を目の当たりにしてきました。つまり、自分には納期を決定する力があると思っている人が、その力の幻想を手放そうとしなかったのです。そこにエクストリーム・プログラミングが登場し、一連の人間関係とそれを支える儀式、そしてそれらの儀式や人間関係を支える技術的な慣習を提示しました。そして、その代償として、締め切りを指示することができなくなりました。
注: Otter.aiによる書き起こしと、DeepLによる機械翻訳をかけているので正確でない可能性があります。
スクラムでも同様に、プロダクトオーナーは要件をプロダクトバックログに順番をつけて記載できるだけで、開発者たちに納期の約束を迫ることはできません。開発者たちは、一つ一つのプロダクトバックログアイテム(PBL)のサイズを見積もったり、これまでのスプリントで完成させた量(実績値)から、チームが持つベロシティを推測することはできますが、それは納期の約束ではありません。
そもそも、実現しようとしているものが、さまざまな要素がからんだ複雑なものである以上、どれだけ深く考えても、事前に完成時期を予想することがきわめて難しいという前提に立つことに、アジャイルの本質があります。ある程度、作ってみたり、使ってもらったり、ということを通じて積極的にフィードバックを受け、絶えず状況を分析しながら、できる限りやっていくしかない、ということです。「事前に机上で分析した納期を満たすように、一方的に履行を強いる」ということがないように、組織や仕組みからととのえるのがアジャイルの本質、というわけです。
当事者であり、最良の予測をアップデートし続ける
私たちのカンファレンスは、誰か他の人のためにやっているものではありません。自分たちが当事者として、一番学びたくて始めたものですし、おそらく一番知りたい人たちが実行委員として、自分の労力を差し出しているという形態です。「いやもっと自分の方が上だ」という人はぜひ、スタッフや講演者として入り込んでいただきたいです。中心にいる一番欲しい人が一番労力を支払っていて、その周辺に、だんだん労力以外のものを支払うという集団が形成されるというモデルです。実行委員会、当日スタッフの皆さん、登壇者さま、スポンサー各社さま、参加者の皆さま、という風に。実行委員会は企画や意思決定をすることよりも、とにかく実現することに重きをおいて作業しています。できることなら、議論すらしたくない。議論はトヨタ生産方式で言えば、付加価値を生み出さない「必要なムダ」にすぎないからです。ですので、基本的には「議論していないことは昨年を踏襲する」という不文律で進めています。会場もなるべく変えないし、お願いする業者さんや、日程などもできる限り変えません。実行委員の入れ替わりも数えるほどしかなく、スタッフも経験者が多いです。学生時代の文化祭とかだと「来年は後輩に譲る」という文化になりますが、私たちは社会人なので、できる限り来年もやってくれるようなくらいには、燃え尽きないようにタスクを健全に回していきたいのです。疲れないようにしたい。
「スタッフが大変な仕事をしている」こともまた、必要なムダ、下手をすると、まったくのムダなので、できる限りスムーズに、無理なく開催したい、と考えています。今年経験した人が来年もスタッフをやってくれれば、教えるコストが少なくてすみます。スケジュール・スコープ・リソース・品質のすべてを、去年の実績を元に考えます。もちろん、変えざるを得ないところは、ちゃんと議論して、実験して、変えることになりますが、まあ、8-9割は去年と一緒でいいと思ってます。ソフトウェア開発をしていても、運用というのは案外そういうもので、運用が安定しているからこそ、ユーザーさんは信頼して使ってくれるのです。ちゃんと実現していれば、期待もしてくれるし、使い続けるものであれば、要望もくれるようになるかもしれません。
チームで行い、知識の塔を切り崩す
安定した運用を続けるために、できる限りチームで進めます。チームといっても「全員が同じスキルになる」とか「意思決定を全会一致で行う」ということではありません。最低限、二人以上で作業内容を把握するとか、相互にカバーできるようにしていく、ということです。「じゃあモブでやりましょーか」とか、「やったことがないので一緒にやりたいでーす」とか、「やってくれてありがとうございます。尊敬してまーす」とか、「今週は都合がつかないので行けませーん」とか、ってな感じで、作業を無理のない範囲で複数人で進めたり、逆に最悪、自分が参加しなくても、大丈夫になるように考えながら動きます。もちろん完璧はないのですが。
知識の塔は周囲から大事にされているが、その人自身はそうした状況に満足しているだろうか？そんなことはない。デイブは安定した立場というメリットを初めのうちは感じるものの、やがて牢屋に閉じ込められて逃げ出せないような気分になってくる。知識の塔は組織全体のボトルネックとなってしまうんだ。デイブは休暇の予定を組めない。現在のプロジェクトだけでなく、すべての顧客からの緊急事態に対して、彼は欠かせない人物となっているためだ。デイブがやっと休暇を取れても、ノートPCは手放せない。休暇から戻ってくれば仕事は山積みになっている。緊急性の低い仕事もすべて彼のところに回ってくるせいだ。
ペアを頻繁に組み替えながら作業する職場では、知識を独り占めするのは不可能だ。ペア作業は本質的に、知識の集中に反する。 僕たちが毎週ペアを組み替えるのは、毎週知識の塔を崩すためだ。チームの誰か一人だけがシステムのある場所を理解していたり、一人だけが精緻なアルゴリズムを把握しているということは起きない。
モブ作業をすると、毎回感じるのは多様性の力です。アジャイルではよく「四つの眼 Four Eyes」でチェックすると言うのですが、二人以上で作業を行うと、それだけでほとんどのミスはなくなります。それでもミスが起きたときは、おそらく全員の責任なので、やはり誰かがつらくなるということもありません。誰かのせいにすることも、ありません。
「おじゃる様」がなぜダメなのか？
技術のわからないマネジメント層のことを、私は「おじゃる様」と呼んでいます。以前ははげちゃびん問題とも呼んでました。「おじゃる様」には悪気はなく、もしかするとまじめで、だからこそ問題を起こします。理解していないけど、責任を持っています、というのは詭弁です。実際に作業していないと、責任を持つことはできません。
「おじゃる様」の存在を許すと、おじゃる様への説明のために作業が発生していきます。「おじゃる様」なりに実績を残さないといけない、となると、問題はさらに悪化していきます。わからない人の実績をつくるために、わかっている人のリソースが消費されていきます。会議が増え、分かりやすい資料作成を求められ、どんどん「おじゃる」度がひどくなっていきます。さらに、そういう会議では「もっと斬新なアイデア」を求める傾向にあります。人々をもっと引き付けたい。聴衆を増やしたい。社会に変革を起こしたい...。自分でやらない分、会議で満足感を得たくなるのかなと思います。でも、そういうことを言っていいのは、自分で実践する人だけにしてほしいです。他人にやらせる社会変革なんて、誰も許容できません。
ということで、私たちのカンファレンスは、おじゃる様は許容しないし、会議だけでアイデアが盛り上がっても、燃えません。それよりも、集まったら共同作業をして、一つずつでも仕事を終わらせていきたい。壮大なビジョンがどうでもいいとは言いませんが、そういうのはカンファレンス本番の発表だけで十分です。それをするのは、実行委員ではなく、発表者の皆さんであるべきだと思います。
滑り出しの力、できることをさっさとやるために
回数を重ねたカンファレンスや実行委員であれば、自発的にやるべきことをみんなでこなせるようになります。定期的に知識の塔を崩していくような取り組みもできるでしょう。しかし、初回はとても難しいものです。お金についても心もとないし、何をやっていいかわからないし、夢は大きい。ですので、すでに開催したスタッフが、他の地域や別のカンファレンスの実行委員に参画して、やるべきことを伝えたり、一緒にモブ作業して、こういうことだよ、というのを伝えていきます。会場やツールにお金がかかるときは、費用のサポートをしたり、旅費が必要な時にはそれをサポートしたりします。
スクラムでは「チームにとっての障害物を取り除く」という表現をよく使います。スクラムマスターという役目の人がよくやるのですが、それが無くなればチームはもっとスムーズに前に進めるのに！という課題や制約を、できればチームのメンバー(開発者たち)自身で取り除けるようにサポートするのです。私たちのカンファレンスでは、誰もがそうした動きを理解しているので、だれかが障害物について言語化したら、それを取り除くにはどうしたらいいか、ディスカッションや、実際に動いてしまう人が出てきます。少なくとも、応援をします。
そこにいる人で決めてもらって構わないし、必要な時には立ち止まって全員の確認をとって決めます。もちろんそのためには資金的な余裕も必要なので、うまく余裕を持てるようにも、考えています。
摩擦がなく動き続けるギア(場)を目指して
私たちのカンファレンスは、実行委員も含めボランティアで運営されています。ボランティアでやる以上は、参加は任意で、個人の意志で参加してもらいます。なんとなく、より多くの時間を貢献するであろう人が実行委員、という感じになっています。もちろんチームなので、その年の個人的な状況によって、貢献できる量はさまざまだったりしますが、信頼しあって、無理のない範囲で、お互いに調整しながら、必要なタスクをこなしていく感じです。成果主義も泣ければ、評価もなく、組織パターンにおける「信頼で結ばれた共同体」のようなものを形成しています。
それなりにタスクがある中で、なにかをやっていくことのモチベーションがどこにあるのだろうと、改めて考えると、いくつかありました。
- キーノートに自分が呼びたい人を呼ぶ
- 情熱を摩擦なしで行動に移せるような環境を作る
- 自分もその一人。みんなの摩擦が減れば、自分の摩擦が減りそう
- 技術とはすべて摩擦を減らすためにある
キーノートに自分が呼びたい人を呼ぶ
RSGTの実行委員をやっていて、最大の恩恵だな、と思うのは、キーノートスピーカーの設定です。これはまったく忖度も配慮もなく、自分が呼びたい人を提案しています。だいたいは海外のカンファレンスに行って、トークを聞いて感動したり、知り合って惚れこんだりした人たちを、日本の人たちに紹介したいというモチベーションです。これは、なぜカンファレンスや勉強会や、研修なんかをやっているか？ということの根幹に関わるところなのですが、日本と海外(特に欧米)との間のディレイを減らしたい、という思いがあります。言語差・地域差・交流の差があるので、そんなギャップは永遠に埋まらないわけですが、それでも、通訳付きで欧米では当たり前かもしれない話を聞いたり、逆に質問や交流をもって、一方的な情報以上の解像度と幅をもって理解を深めていくことは、継続的にやっていくべきことだと思っています。なぜRSGTやDevOpsDays Tokyoが海外スピーカーのキーノートなのか？といえば、それが根本のモチベーションだからです。なので、ある意味そこは、聴衆の意見を全く聞かずに、実行委員のなかでの議論で候補を決めて、その中で交渉して話してくれそうな人をブッキングしています。キーノートスピーチはカンファレンスの全体のテーマをなんとなく決めていくので、早めに決めて告知することで、みなさんからの公募のテーマにも活かしていただけるのかなと考えています。
情熱を摩擦なしで行動に移せるような環境を作る
次が、情熱を摩擦なしで行動に移せるような環境、少なくとも雰囲気を作りたいというところ。セッションを公募制にしたり、Open Space Technology (OST) やパーティ、Discordを通じて皆さんが自己組織的にテーマ設定をして、自由に語り合えるようにしたり、クロージングキーノートで「気持ちの後押し」をしてもらって会期を終えるように工夫したり。関わるすべての人々の情熱がこの一年の活動のエネルギーであり、それは有限なものなので、なるべく摩擦や摩耗なく、仲間を見つけてやり始めてほしい、と願っています。そして、そうした情熱を瞬間的に爆発させるのではなく、なるべく平準化して、安定して燃やしてほしいと考えています。そのための知恵を交換したいです。
自分もその一人。みんなの摩擦が減れば、自分の摩擦が減りそう
そして、摩擦なくなにかをやっていきたいと考えている、おそらく最大の人間が自分だと思っています。みんなの雰囲気が、どんどん摩擦をなくす方向になっていけば、たぶん自分ももっとやりやすくなると思うんですよね。なにが摩擦になり、人の情熱を活かせなくするのか？多くの皆さんによる「群衆の英知」によって、さまざまなことを学んできましたし、摩擦を減らしてくれたと思います。他の人の情熱に後押しされることもしょっちゅうです。
技術とはすべて摩擦を減らすためにある
そして最後に、「技術を向上したい」という欲があります。人間面や、テストなど技術面の知識はもちろんのこと、オンラインカンファレンスやハイブリッドカンファレンスを行うための機材・配信・コミュニケーションの技術、安定した運営を支える財務面や税法の知識などは、やっていると学べることが多くあります。これらのことは、結果的に自分がなにかをやりたい、と考えたときの摩擦を減らしてくれます。やったことがあれば、できる。まさに経験主義(Empirical) そのものです。
摩擦のないコミュニティ運営
というわけで、普段どんなことを考えながらカンファレンスのタスクをこなしたり、コミュニティに参画しているのか、というあたりをつらつらと言語化してみました。その中で出てきたのが「摩擦のない」というキーワードです。人が複数で何かをすれば、もちろん摩擦が存在するわけですが、できる限り摩擦を取り除いて、ちゃんと議論するべきところはして、社会的に最大効率でものごとが完成(Done)するようにしたい、と考えています。
このことは、カンファレンス運営だけでなく、さまざまな組織的な活動にも共通することなのかもしれないな、と思うところがあります。人々の情熱のエネルギーを最大効率で活かしながら、成果を積み上げていくことができたら、とても素敵なことだし、経済的にも、より幸せが巡ってくる可能性が高まるのではないか、と無邪気に期待している部分があります。
私が関わっているさまざまな場所で、そんな雑談も出来たら楽しいんじゃないかと思います。ぜひ声をかけてくださいまし。
