さらに広がるスクラムフェスのハイブリッドカンファレンスの形

スクラムフェス大阪を無事に終了しました。スクラムフェス大阪は4回目で、第一回は2019年にオンサイト開催(関大MeRise様をお借りしました)、2020年はコロナ初年度ということでオンライン開催(19トラック)の形を作り、2021年のオンライン開催を経て、2022年はハイブリッド開催となりました。品川アジャイル(#shinagile)では、現地からのラジオ的なライブ放送を通じて、スクラムフェス大阪をはじめ、各地のスクラムフェスのオーガナイザーの皆さんの取り組みや思いを聞きました。

 

スクラムフェス大阪(6月) https://youtu.be/5BZI9A3jhsY?t=851

スクラムフェス大阪2022の開催は、オンラインを中心としたハイブリッド開催。現地イケマンカンファレンス会場の役割は、セッション会場ではなく「廊下」。13トラックの地域トラックと、3トラックのスポンサートラックがオンラインで開催され、現地はそれを一覧で観られる設備を用意しつつ、参加者は交流ができるという開催形態でした。

セッションのリストはこちらです。

Scrum Fest Osaka 2022 - Program Schedule | ConfEngine - Conference Platform

見きれないほどたくさんあります。聖徳太子でもすべては見られないので、現在は参加者向けにビデオが公開されています。参加者を中心に同時視聴会(参加者と一緒にみることはできる)が開催されています。

 

使用機材の紹介 https://youtu.be/5BZI9A3jhsY?t=2540 

スクラムフェス大阪の会場はこんな感じです。(壁一枚隔てて隣のホール)

スクラムフェス新潟(5月) https://youtu.be/5BZI9A3jhsY?t=9799

スクラムフェス新潟のテーマはテストや品質保証。品川アジャイルの現地放送も600再生を超えたとのこと。ゆるっと見るのにほんといいコンテンツです。「肩剥しってアジャイルなの?」「だってウォーターフォールではやらないでしょ!」

今年は初の開催で、新潟駅前のコワーキングスペースNinnoで開催されました。お昼に地元選出の議員さんが視察に来訪するハプニングもあり、そのタイミングでクリエーションライン社&ウイングアーク1st社のスポンサートーク、通称「劇団クリエーションライン」を観覧されました。
次回の構想としては、スタジアムを使えるかも、なんて話も出ているようですが、来年も変わらず、Agile Testing Daysの感覚を持ってくるそうです。

スクラムフェス三河(9月) https://youtu.be/5BZI9A3jhsY?t=11551

私も実行委員なので余計な話をしていますが、スクラムフェス三河のテーマは製造業です。愛知県の三河地域から、静岡県遠江駿河地域にかけてを駿遠三(徳川家康の旧領地)地域と言いますが、世界的に有名な製造業の多いこの地域を盛り上げていきたいと考えています。開催地は豊橋です。東海道新幹線から徒歩5分くらいの会場で行いますので、ぜひ足をお運びください。

 

フォートナイトで学ぶスクラム  https://youtu.be/5BZI9A3jhsY?t=13333

スクラムフェス大阪基調講演の角征典さんと栃木トラックオーナーの木村さんをゲストにお迎えして Fortnite についてのディスカッションを行いました。いい大人がゲームで交流する意味、世代を超えて繋がれる世界を感じていただくセッションを行いました。

スクラムフェス鳥取(いずれ開催)  https://youtu.be/5BZI9A3jhsY?t=15160

まだ開催はされていないのですが、いずれ開催するはずの鳥取のちんもさんのインタビューを聞きました。「鳥取でできたらどこでもできるんじゃないですか?」ということで、日本全体に夢を与えるために初開催を目指すそうです。放送中に品川アジャイルによる下見が決定しましたので、いずれ開催されるに違いないです。鬼太郎空港とコナン空港があるので間違えないように注意です。

 

スクラムフェス福岡 (3月予定)  https://youtu.be/5BZI9A3jhsY?t=16960

来年初開催を目指しているスクラムフェス福岡は、現在、eスポーツ施設での開催を検討しているそうです。eスポーツの配信に使うプロ機材を使っての配信ができるのではないかということで、品川アジャイルのスタッフが燃えています。福岡は福岡市の行政としての取り組みあり、金融センターとして様々な企業がアジャイルやWeb開発をを行っていて、先端的な事例や苦労話を聞けるカンファレンスになるに違いないです。福岡は空港のアクセスもいいのでぜひ。スタッフとして巻き込まれるチャンスもあります!

 

スクラムフェス仙台 (8月予定)  https://youtu.be/5BZI9A3jhsY?t=18742

オーガナイザーの天野さんが仙台に引っ越したことがきっかけで、スクラムフェス仙台が初開催されることになりました。まさにリモートワーク時代の申し子のようなカンファレンスです。会場も天野さんが仕事で利用しているコワーキングスペースとのことで、地域密着の取り組みが期待されます。基調講演はエバッキーこと江端さん。スポンサーもセッションも数多く集まっているので、素晴らしいカンファレンスになることが期待されます。

仙台はコロナ以前は「支店経済」と呼ばれて、本店である東京からの発注仕事が多かったそうなのですが、地域に縛られずに仕事できるようになった昨今は、新しい取り組みも多く生まれているようです。品川アジャイルでも配信に行きますので、ぜひご期待ください。

 

スクラムフェス札幌 (11月) 

今回インタビューは行っていませんが、昨年オンライン開催されたスクラムフェス札幌も、今年はハイブリッド開催に移行し、札幌市教育文化会館での開催の予定です。プロポーザルとスポンサー募集はまもなく開始だそうです!

 

各地で広がる多様性。地域と実践者に根差したスクラムフェス

スクラムフェスは日本各地に広がり、開催のない月の方が少ないという状況になりつつありますが、それぞれ特色を持ったテーマで工夫を凝らして開催されていて、運営もスクラム実践者の人たちですので、無理しない、継続的な開催が行われます。スタッフワークからも実践を学ぶことができると思いますので、各地のスタッフにアクセスしてみてください。スクラムフェス大阪 @ Online のDiscord サーバーへどうぞ。各地のスクラムフェスに参加いただければ、招待が届きます。

 

Regional Scrum Gathering Tokyo 2022 ご参加ありがとうございました

今年も年初から、Regional Scrum Gathering Tokyo 2022 のスタッフワークをしてきました。今回も非常に多くの、熱意ある皆様に支えられて、学びの多いギャザリングになったことをお礼申し上げます。「ギャザリング」という言葉をとても尊重していて、ふだん集まらない同志、実践者の皆さんが集まる会として、より深く、話し合える場所を提供していきたいと考えています。Twitter#RSGT2022ハッシュタグで検索していただければ、多くの参加報告記事を見つけることができると思います。

2022.scrumgatheringtokyo.org

f:id:wayaguchi:20220120202752p:plain

キーノート: Johanna Rothmanさん

今回のキーノートはJohanna Rothmanさんにお願いしました。アジャイルと組織運営について長年コンサルティングをされてきた方で、また米国のAgile Conferenceでも主導的な立場を取られてきました。日本語に翻訳されているManage It!をはじめ多くの著作があります。今回は Agile Program Management について話していただきました。Program Manager というのは米国企業である役職で、大きめのプロダクトを統括する役割です。例えば Microsoft だと、Visual Studio全体を統括したり、という役割かなと思います。今回よくわかったのは、部長に対する本部長のような、上位職ではなく、あくまで全体に寄与することを考える役割だということ。そしてアジャイルではその役割を、大きな組織で円滑に人々を結びつけるハブとして使えるということでした。Johannaさんが、Program Managerが上司の上司に見えないよう、注意深く役割の説明をされていたのが印象的でした。組織はツリーではないのです。

Johanna Rothman - Management Consultant - Johanna Rothman, Management Consultant

Johanna Rothman (@johannarothman) | Twitter

f:id:wayaguchi:20220120201003p:plainf:id:wayaguchi:20220120201101p:plain

キーノート: Diana Larsenさん

Day2のキーノート入るDiana Larsenさんでした。Dianaさんとも何回会ったか分からないのですが、「いつもだいたいAgileカンファレンスの食事のテーブルだよね」と言ってくれました。そう、あのカンファレンスは食事のテーブルで多くの人が出会うんです。RSGTもそうなれたらいいなといつも思っています。DianaさんもAgileカンファレンスの初期から参加されて、あのカンファレンスの雰囲気を体現する立役者の一人です。チーム文化、技術面、組織全体を包括するアジャイル普及モデルとして、Agile Fluency Modelを紹介していただきました。『アート・オブ・アジャイル デベロップメント』の著者で技術コーチの James Shore さんとのコラボレーションの成果です。『アート・オブ・アジャイル デベロップメント』は昨年原著の第二版が出ました。Dianaさんの『アジャイルレトロスペクティブズ』も待望の第二版を準備中とのことです。

Agile Fluency Project: Chart Your Agile Pathway

DianaOfPortland #BLM (@DianaOfPortland) | Twitter

f:id:wayaguchi:20220120201316p:plainf:id:wayaguchi:20220120201402p:plain

クロージングキーノート: 牛尾剛さん

クロージングキーノートは牛尾剛さんにお願いしました。10数年来のお付き合いなのですが、常にチャレンジを続ける姿勢がいつもすごいな、と思います。英語を勉強しに留学しに行ったり、Microsoft の本社に飛び込んでクラウドプラットフォームの内側を作っているというものすごいキャリアチェンジの話や、最近の Microsoft の開発文化について聞きたいなー、ということでお願いしました。すでに、ほぼ書き起こしのPublicKeyさんの記事が出てますので、内容を見ていただくことができます。

www.publickey1.jp

講演中、特にDiscordが盛り上がっていたのが、「納期がない」という話でしたね。話を遮って質問を入れてしまいましたが、みなさんにとってよい気付きになっていれば嬉しいです。実は8月にあったAgile2021で、ケント・ベックさんが「デッドラインを自分で決められると思っている人々がその権力をいまだに手放していない」点を憂いていて、XPの計画ゲームやスクラムのスプリントプランニングの仕組みに触れていながらも、やはりなかなか説得が難しいと考えているところが、「作業の見積もりを開発者が行い、進捗は開発者を信頼して任せる」ところなんだろうな、と想像します。今後の皆さんの取り組みに期待しています!

www.publickey1.jp

あと、「ガチ三流」というタイトルに過激に反応している人がいるようですが、牛尾さんは本心から自分のことを「ガチ三流」だと思っているのだと思います。決して、誰かを下に見て言うとか、思ってないけど卑下して言う、という器用な人ではないことだけは、ここで言っておきたいです。

品川アジャイルとして配信

今回は品川アジャイルとしての配信は二回目になります。iRig2を知ったことと、CenterStage対応のiPadが発売されたことで、機材を一新して配信を行いました。この機材セットは安価で軽量でありながら、どなたにでも扱いやすいものなので、マイクやスピーカーがあるような会場でハイブリッド配信をしようかな、という方には参考にしていただければと思います。

bayashimura.hateblo.jp

昨年は会場に張り付かざるを得なかった品川アジャイルのスタッフが、ほとんどスタッフルームでの監視とZoom運用に回れたのが非常に大きく、来年こそはスタッフルームラジオをやりたいですね、などと話している余裕っぷりです。一方で、課題もいくつか見つかっていますので、今後の実験がまた楽しみです。特にOSTについては、通常の会議室を使ったハイブリッドはかなりうまくできたようですが、オープンな環境のテーブルでは会議スピーカーが環境音を拾いすぎてしまってリモートからの参加が難しかったようです。そうなんです。課題は音。これは本当に難しくて、上手に設計しないとやってられません。ネットが潤沢にあれば全員がスマホとヘッドセットでDiscord/Zoomにつないでしまうほうがいいわけですが。

f:id:wayaguchi:20220120195638p:plain

アギレルゴコンサルティングとしてスポンサー

アギレルゴコンサルティングとしてはスポンサーを行いました。松元健さんがスタッフとして加わってくれたので、スポンサーセッションで話していただいています。二人ともRSGTのスタッフワークがあり、スポンサーブースはほとんど何もできませんでしたが、アギレルゴコンサルティングでは今年も珠玉のトレーナー陣による通訳付き研修を行っていきます。

f:id:wayaguchi:20220120195014p:plainf:id:wayaguchi:20220120194953p:plain

アギレルゴ アジャイル研修

Roots of Scrum (2005)を紹介してきた

スクラムの共同開発者ジェフ・サザーランド博士が2005年に行った講演について紹介しました。デンマークで行われた講演ですが、驚くほど日本からの影響について語ってくれています。2011年に始めてお招きして、Innovation Sprint をやったわけですが、それがどれだけジェフさんにとって大きなことであったのか、改めて認識した思いです。資料はこちらです。

speakerdeck.com

 

ビデオは現在参加者向けに公開されていますので、参加者の方は会場のDiscordチャンネルの概要欄のURLから見てください (ZoomのURLがあったのと同じ場所です)。Room C Day1 04:40:00 くらいからです。

f:id:wayaguchi:20220120195255p:plain

リアルとバーチャルを全部活かす

昨年に比べ、状況はよかったので、リアル参加を選択された方が多くいらっしゃいました。RSGTとしては、コロナ対策として半数の席数のみに制限し、とにかく場を閉めず、参加者の皆さんが自由に選択できるようにしています。そのためにハイブリッド開催への投資も行ってきました。オミクロン株の流行で一気にまた感染者が増えている状況ですので、来年以降もまた流動的な状況での開催になる可能性があります。できるだけ軽量にハイブリッド開催できるようなノウハウも開発していければと思っています。

前回の開催は、スクフェス大阪以降で普及してきた、DiscordとZoomを利用したオンライン開催のノウハウと、品川アジャイルで地道に研究してきた配信の仕組みを組み合わせて、スクフェス三河でご協力いただいた地元田原の技術集団オレンジボックスさんのご協力もいただき、ハイブリッド開催にこぎつけました。アギレルゴコンサルティングの研修の通訳でいつもお世話になっているISSさんともZoomでのオンライン研修のノウハウを溜めてきたことも有用でした。今回はさらにそこに日英通訳としてSeth Reamsさんに加わっていただくなど、これまでの関係を活かしながら、さらにスムーズな開催をできたのではないかと思います。コーヒー提供の縁の木さんもゴミのリサイクル100%を目指す「蔵前モデル」を紹介してくださいました。

www.tokyo-np.co.jp

アフターコロナの時代では、多くの企業やチームがリモートでの作業を強いられてきました。でも、もう2年経って、だいぶ慣れましたよね。有用性も限界もわかってきた。RSGTに参加する皆さんは、そうしてツールやコミュニケーションのコツについて実験を繰り返してきた方がほとんどだと思いますので、こうした皆さんがリアルでつながり、バーチャルでの活動を続けていくことで、新しい地平が開けていくと感じています。たとえば英語学習で言えば「全然できない」「ネイティブのように流暢」のように過激な二分法で考えるのが、初心者レベルで陥りがちな罠です。アジャイルか?ウォーターフォールか?のように二分法で考えるのも、だいたいやったことがない方なんじゃないかと思います。私たちは実践者なので、そういう表層的なレベルにとどまらず、何がどう役立つのか、具体的に試しながら、選択肢として手に付けていきたいと思うんです。きっと皆さんそうですよね。

f:id:wayaguchi:20220120195841p:plain

スクフェスに向けて

今回は各スクフェスのスタッフの皆さんや、開催に興味がある皆さんもリアルに集まれた人もいらっしゃいました。RSGTに比べてスクフェスの「よさ」は、その間口の広さ。スクフェスで始めて発表しました!という方が多くいらっしゃって、内容も生々しい努力の発表が多く、ある意味RSGTよりも学びが深い部分があります。

各地域のスクフェス開催がぐっと進んだ感じがします。すでに行っている大阪札幌三河に加え、すでにRFPを募集している新潟が今年加わる予定ですが、仙台、福岡が企画を具体的に進め始めて、広島もやりますよーと言ってくれております。あとやりたいと言ってくれているのが鳥取、金沢、Twitterでにわかに始まっている青森、などなど、まあいずれそのうち、と思っていただいている方々もいるので、決して焦らず、できるときにはできる感じでできたらいいかなーと思っております。あと、品川もやりたくなってきてます。

f:id:wayaguchi:20220120200006p:plain

残っている仕事

残っているスタッフワークは、荷物やノベルティの整理のほか、スタッフの皆さんの交通費や経費の精算と、講演料支払いです。幸いスタッフの皆さんの旅費や経費を支払える余裕がありますので、お支払いしていきます。海外講演料については、今回は米国向けということで、租税条約の手続きをするためには米国居住者証明を先方に取ってもらう必要があるので、20.42%の非居住者向けの源泉所得税を支払うことにしました。本来二重課税を防ぐ目的で結ばれている租税条約が、米国IRSはどうも90日以上かかるケースがあるようで(多段居住者証明ですよ?)、このように利用しにくくなっていることは本当によくないと思います。

あと、どこかのタイミングで、参加者以外にも録画を公開することになろうかと思います。現在でも参加者の方と同時視聴することはできますので、ぜひコミュニティの同時視聴会とか、社内での同時視聴会をご検討いただければと思います。

aki-m.hatenadiary.com

自己組織化とは、ある程度の不便を受け入れることかもしれない

今回のカンファレンスを通じて、思い出したところがあるので最後ですが書いておきます。スクラムでは「自己組織化 Self Organization」したチームを重視しています(最新のスクラムガイドでは自己管理に代わりましたが意味するところは同じと思います )。この用語は、竹内野中 “The New New Product Development Game” から来ています。優れたプロダクトチームの人たちは、それぞれが自律的に動き、創造的に解決していくさまを表しています。メンバーを子供扱いせず、自分からチームに貢献するすべを考えていただくことを、信頼するということです。RSGTというカンファレンスが、これだけ少ないスタッフで、また多くのスピーカー、スポンサー、参加者の皆さんに支えていただけているのは、多くの参加者の方々が、この場を「よいもの」だと思い、もっとよくしたいと感じて、自ら動いていただいているからに他なりません。もしかすると、他の多くのカンファレンスに比べると、丁寧な文書での説明や、入り口での大声でのアナウンスが欠けているんじゃないかなと、思います。この点は初参加の方には申し訳なく感じることもありますが、少なくとも私は「いつも来てくれる皆さん」を重視しています。そしてそうした皆さんが、さらに新しく来た方々と繋がって、親切にご案内いただいたり、会の外でも新しい活動につなげていただいているのを見聞きします。「正統的周辺参加」という概念があります。人は専門知識を身につけるときに、組織の外延から参画して、徐々に学びながら、活動しながら、徐々に中心に向かっていく、という組織学習のモデルのようなものです。今年もしかしたら、残念だったなー、知らなかったなー、というところがあったかもしれません。会期の終了後に聞いた、面白い取り組みがあったのかもしれません。でも、焦らないでください。また来年も、その先も、できる限り同じような場を作っていきたいと考えています。みんなが飽きて来なくなるまで、RSGTがRSGTであり続けたらいいな、と考えています。

f:id:wayaguchi:20220120200504p:plainf:id:wayaguchi:20220120202204p:plain

最後に:一歩一歩進もう

技術は変わっても、人は自分の思う通りには変わってくれないものです。RSGTに関わってくださった皆さんが、徹底したリアリストとして、今年も一歩一歩、実験を繰り返していただければと、切に願っています。今年のRSGTは終わりました。お祭りの熱狂が引くのは一瞬のことです。しかし、多くの方の心の中に灯った種火は、これからの行動の糧になるんじゃないかと思います。所属組織で、コミュニティで、家庭で、そしてスクフェスで、RSGTで灯った種火を、具体的な一歩に変換して、一つ一つの実験を進めていただけることを願っています。いきなり膨らませてしまうと、割れるのも早くなります。内部のよさを磨きながら、それでいて機会を逃さず、少しずつ活動を成長させていっていただければと思います。きっと一番面白いのは、次の実験です!なので、今の実験はそこそこにして、休んでしまったほうがいいかもしれません。ゆっくりいきましょう。一歩一歩行きましょう。「スクラム自体は問題を解決しません。解決するのは人間です」

f:id:wayaguchi:20220120200650p:plainf:id:wayaguchi:20220120200732p:plain

 

来年もRSGTでお会いできれば幸いです。たぶん6-7月くらいからスポンサーやプロポーザルを募集するのではないかと思います。長文、お読みいただきありがとうございました。





 

摩擦のないコミュニティ運営を考える

このエントリは、Reginal Scrum Gathering Tokyo 2022(以下RSGT2022)に向けたアドベントカレンダーの記事として書かれたものです。

今日はカンファレンスの運営について、ちょっと言語化してみました。

f:id:wayaguchi:20211223084115p:plain

RSGT、スクラムフェス、DevOpsDays Tokyo

f:id:wayaguchi:20211223084154p:plain
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) という人

f:id:wayaguchi:20211223084249p:plain
勉強会というものを始めたのは、2009年からのすくすくスクラムというコミュニティからが本格的なところです。それまでにも、LLxxRubyKaigiオブラブXP祭りといったカンファレンスや勉強会には参加せてていただいたのですが、スクラムをはじめて社内でやるにあたって支援してくれた林栄一さんと、当時同僚だった江端一将さんが、自分たちで勉強会をやろう、ということになり、始めたのがすくすくスクラムでした。そのころ、Fearless Change という本がある、というのを江端さんがコミュニティの誰かに推薦されたということで、教えてくれて、その読書会をやろう、ということで、懸田剛さんや近藤寛喜さん、他にもいろんな人たちとその本の読書会をやりました。

この本の著者の一人、リンダ・ライジング (Linda Rising) さんは、米国のカンファレンス Agile 20xxでは知らない人がいない、という常連で、2011年の基調講演は私もレポートしました。

enterprisezine.jp

この著者らのアプローチが、パターンランゲージという手法を用いた、実践者による形式知の書き起こしと、実践者同士でそのパターン名をまさに「ランゲージ=共通言語」として、伝え合って活用しよう、というものです。Fearless Change では「新しい考え方を組織内に広めるためには?」という観点で、すでにうまくいった人たちの見識を集め、共通性のある項目について「パターン形式」で抽出・記述・推敲されています。そもそもアジャイルという新しいやり方が、まさに組織内でのコミュニケーションを必要としますし、それ以外にもさまざまな考え方の普及に役立つだろう、ということです。

また、この普及のアプローチそのものも、「トップダウンでやらせる」とか「声の大きい人に主導してもらう」のではなく、自分自身が実践者として、着実に周りを巻き込みながら、中長期的視野に立ってコミュニケーションをしていくという、まだに「アジャイルな普及方法」になっていることも、重要なポイントかなと思います。

新しいアプローチを導入したいなら、強制的に使わせるのが一番早い、という主張を聞いたことがあるかもしれない。もし一度した約束には絶対に従わなければならないとすれば、人はなるべく約束を回避するようになるだろう。王様が性急な改革を命令するかもしれないとわかれば、すぐに抵抗勢力が結成される。経営陣が「さあみんな、今すぐ<イノベーション>に飛び込もう!」と言えば、すぐに実現されるなんてことは期待できない。トップダウンの変化の特徴は、そのスピードにあるが、問題があればすぐに対応しなければならない。ボトムアップの変化はゆっくりだが、抵抗勢力への対応はもっと効率的にできる。ボトムアップな変化の特徴は、参加型、情報共有、不確実性、そして抵抗が最小限になることだ。私たちは経験上、現場管理職や上級管理者の適切な援護射撃をもらいながらのボトムアップな変化こそが最良と信じている。

アジャイルの本質 - 納期は決められないという現実を認める

f:id:wayaguchi:20211223084526p:plain

アジャイルな普及方法」ってなんだよ、という話になるのですが、この点については、ちょうど8月にあった Agile 2021 というカンファレンスで、アジャイルマニフェスト起草者の一人、エクストリームプログラミング(XP) の Kent Beck 氏が興味深いことを言ってました。

エクストリームプログラミングの原動力のひとつは、ビジネスとテクノロジーの間の溝を癒すことでした。私は、一般的に言われている2つのグループが激しく対立し、協力する方法を見つけても必要なものが得られないという状況を目の当たりにしてきました。つまり、自分には納期を決定する力があると思っている人が、その力の幻想を手放そうとしなかったのです。そこにエクストリーム・プログラミングが登場し、一連の人間関係とそれを支える儀式、そしてそれらの儀式や人間関係を支える技術的な慣習を提示しました。そして、その代償として、締め切りを指示することができなくなりました。
注: Otter.aiによる書き起こしと、DeepLによる機械翻訳をかけているので正確でない可能性があります。

クラムでも同様に、プロダクトオーナーは要件をプロダクトバックログに順番をつけて記載できるだけで、開発者たちに納期の約束を迫ることはできません。開発者たちは、一つ一つのプロダクトバックログアイテム(PBL)のサイズを見積もったり、これまでのスプリントで完成させた量(実績値)から、チームが持つベロシティを推測することはできますが、それは納期の約束ではありません。

そもそも、実現しようとしているものが、さまざまな要素がからんだ複雑なものである以上、どれだけ深く考えても、事前に完成時期を予想することがきわめて難しいという前提に立つことに、アジャイルの本質があります。ある程度、作ってみたり、使ってもらったり、ということを通じて積極的にフィードバックを受け、絶えず状況を分析しながら、できる限りやっていくしかない、ということです。「事前に机上で分析した納期を満たすように、一方的に履行を強いる」ということがないように、組織や仕組みからととのえるのがアジャイルの本質、というわけです。

当事者であり、最良の予測をアップデートし続ける

f:id:wayaguchi:20211223084636p:plain
私たちのカンファレンスは、誰か他の人のためにやっているものではありません。自分たちが当事者として、一番学びたくて始めたものですし、おそらく一番知りたい人たちが実行委員として、自分の労力を差し出しているという形態です。「いやもっと自分の方が上だ」という人はぜひ、スタッフや講演者として入り込んでいただきたいです。中心にいる一番欲しい人が一番労力を支払っていて、その周辺に、だんだん労力以外のものを支払うという集団が形成されるというモデルです。実行委員会、当日スタッフの皆さん、登壇者さま、スポンサー各社さま、参加者の皆さま、という風に。実行委員会は企画や意思決定をすることよりも、とにかく実現することに重きをおいて作業しています。できることなら、議論すらしたくない。議論はトヨタ生産方式で言えば、付加価値を生み出さない「必要なムダ」にすぎないからです。ですので、基本的には「議論していないことは昨年を踏襲する」という不文律で進めています。会場もなるべく変えないし、お願いする業者さんや、日程などもできる限り変えません。実行委員の入れ替わりも数えるほどしかなく、スタッフも経験者が多いです。学生時代の文化祭とかだと「来年は後輩に譲る」という文化になりますが、私たちは社会人なので、できる限り来年もやってくれるようなくらいには、燃え尽きないようにタスクを健全に回していきたいのです。疲れないようにしたい。

「スタッフが大変な仕事をしている」こともまた、必要なムダ、下手をすると、まったくのムダなので、できる限りスムーズに、無理なく開催したい、と考えています。今年経験した人が来年もスタッフをやってくれれば、教えるコストが少なくてすみます。スケジュール・スコープ・リソース・品質のすべてを、去年の実績を元に考えます。もちろん、変えざるを得ないところは、ちゃんと議論して、実験して、変えることになりますが、まあ、8-9割は去年と一緒でいいと思ってます。ソフトウェア開発をしていても、運用というのは案外そういうもので、運用が安定しているからこそ、ユーザーさんは信頼して使ってくれるのです。ちゃんと実現していれば、期待もしてくれるし、使い続けるものであれば、要望もくれるようになるかもしれません。

チームで行い、知識の塔を切り崩す

f:id:wayaguchi:20211223084707p:plain

安定した運用を続けるために、できる限りチームで進めます。チームといっても「全員が同じスキルになる」とか「意思決定を全会一致で行う」ということではありません。最低限、二人以上で作業内容を把握するとか、相互にカバーできるようにしていく、ということです。「じゃあモブでやりましょーか」とか、「やったことがないので一緒にやりたいでーす」とか、「やってくれてありがとうございます。尊敬してまーす」とか、「今週は都合がつかないので行けませーん」とか、ってな感じで、作業を無理のない範囲で複数人で進めたり、逆に最悪、自分が参加しなくても、大丈夫になるように考えながら動きます。もちろん完璧はないのですが。

知識の塔は周囲から大事にされているが、その人自身はそうした状況に満足しているだろうか?そんなことはない。デイブは安定した立場というメリットを初めのうちは感じるものの、やがて牢屋に閉じ込められて逃げ出せないような気分になってくる。知識の塔は組織全体のボトルネックとなってしまうんだ。デイブは休暇の予定を組めない。現在のプロジェクトだけでなく、すべての顧客からの緊急事態に対して、彼は欠かせない人物となっているためだ。デイブがやっと休暇を取れても、ノートPCは手放せない。休暇から戻ってくれば仕事は山積みになっている。緊急性の低い仕事もすべて彼のところに回ってくるせいだ。

ペアを頻繁に組み替えながら作業する職場では、知識を独り占めするのは不可能だ。ペア作業は本質的に、知識の集中に反する。 僕たちが毎週ペアを組み替えるのは、毎週知識の塔を崩すためだ。チームの誰か一人だけがシステムのある場所を理解していたり、一人だけが精緻なアルゴリズムを把握しているということは起きない。

モブ作業をすると、毎回感じるのは多様性の力です。アジャイルではよく「四つの眼 Four Eyes」でチェックすると言うのですが、二人以上で作業を行うと、それだけでほとんどのミスはなくなります。それでもミスが起きたときは、おそらく全員の責任なので、やはり誰かがつらくなるということもありません。誰かのせいにすることも、ありません。

「おじゃる様」がなぜダメなのか?

f:id:wayaguchi:20211223084837p:plain

技術のわからないマネジメント層のことを、私は「おじゃる様」と呼んでいます。以前ははげちゃびん問題とも呼んでました。「おじゃる様」には悪気はなく、もしかするとまじめで、だからこそ問題を起こします。理解していないけど、責任を持っています、というのは詭弁です。実際に作業していないと、責任を持つことはできません。

「おじゃる様」の存在を許すと、おじゃる様への説明のために作業が発生していきます。「おじゃる様」なりに実績を残さないといけない、となると、問題はさらに悪化していきます。わからない人の実績をつくるために、わかっている人のリソースが消費されていきます。会議が増え、分かりやすい資料作成を求められ、どんどん「おじゃる」度がひどくなっていきます。さらに、そういう会議では「もっと斬新なアイデア」を求める傾向にあります。人々をもっと引き付けたい。聴衆を増やしたい。社会に変革を起こしたい...。自分でやらない分、会議で満足感を得たくなるのかなと思います。でも、そういうことを言っていいのは、自分で実践する人だけにしてほしいです。他人にやらせる社会変革なんて、誰も許容できません。

ということで、私たちのカンファレンスは、おじゃる様は許容しないし、会議だけでアイデアが盛り上がっても、燃えません。それよりも、集まったら共同作業をして、一つずつでも仕事を終わらせていきたい。壮大なビジョンがどうでもいいとは言いませんが、そういうのはカンファレンス本番の発表だけで十分です。それをするのは、実行委員ではなく、発表者の皆さんであるべきだと思います。

滑り出しの力、できることをさっさとやるために

f:id:wayaguchi:20211223084913p:plain
回数を重ねたカンファレンスや実行委員であれば、自発的にやるべきことをみんなでこなせるようになります。定期的に知識の塔を崩していくような取り組みもできるでしょう。しかし、初回はとても難しいものです。お金についても心もとないし、何をやっていいかわからないし、夢は大きい。ですので、すでに開催したスタッフが、他の地域や別のカンファレンスの実行委員に参画して、やるべきことを伝えたり、一緒にモブ作業して、こういうことだよ、というのを伝えていきます。会場やツールにお金がかかるときは、費用のサポートをしたり、旅費が必要な時にはそれをサポートしたりします。

スクラムでは「チームにとっての障害物を取り除く」という表現をよく使います。スクラムマスターという役目の人がよくやるのですが、それが無くなればチームはもっとスムーズに前に進めるのに!という課題や制約を、できればチームのメンバー(開発者たち)自身で取り除けるようにサポートするのです。私たちのカンファレンスでは、誰もがそうした動きを理解しているので、だれかが障害物について言語化したら、それを取り除くにはどうしたらいいか、ディスカッションや、実際に動いてしまう人が出てきます。少なくとも、応援をします。

そこにいる人で決めてもらって構わないし、必要な時には立ち止まって全員の確認をとって決めます。もちろんそのためには資金的な余裕も必要なので、うまく余裕を持てるようにも、考えています。

摩擦がなく動き続けるギア(場)を目指して

f:id:wayaguchi:20211223084946p:plain
私たちのカンファレンスは、実行委員も含めボランティアで運営されています。ボランティアでやる以上は、参加は任意で、個人の意志で参加してもらいます。なんとなく、より多くの時間を貢献するであろう人が実行委員、という感じになっています。もちろんチームなので、その年の個人的な状況によって、貢献できる量はさまざまだったりしますが、信頼しあって、無理のない範囲で、お互いに調整しながら、必要なタスクをこなしていく感じです。成果主義も泣ければ、評価もなく、組織パターンにおける「信頼で結ばれた共同体」のようなものを形成しています。

それなりにタスクがある中で、なにかをやっていくことのモチベーションがどこにあるのだろうと、改めて考えると、いくつかありました。

  1. キーノートに自分が呼びたい人を呼ぶ
  2. 情熱を摩擦なしで行動に移せるような環境を作る
  3. 自分もその一人。みんなの摩擦が減れば、自分の摩擦が減りそう
  4. 技術とはすべて摩擦を減らすためにある
キーノートに自分が呼びたい人を呼ぶ

RSGTの実行委員をやっていて、最大の恩恵だな、と思うのは、キーノートスピーカーの設定です。これはまったく忖度も配慮もなく、自分が呼びたい人を提案しています。だいたいは海外のカンファレンスに行って、トークを聞いて感動したり、知り合って惚れこんだりした人たちを、日本の人たちに紹介したいというモチベーションです。これは、なぜカンファレンスや勉強会や、研修なんかをやっているか?ということの根幹に関わるところなのですが、日本と海外(特に欧米)との間のディレイを減らしたい、という思いがあります。言語差・地域差・交流の差があるので、そんなギャップは永遠に埋まらないわけですが、それでも、通訳付きで欧米では当たり前かもしれない話を聞いたり、逆に質問や交流をもって、一方的な情報以上の解像度と幅をもって理解を深めていくことは、継続的にやっていくべきことだと思っています。なぜRSGTやDevOpsDays Tokyoが海外スピーカーのキーノートなのか?といえば、それが根本のモチベーションだからです。なので、ある意味そこは、聴衆の意見を全く聞かずに、実行委員のなかでの議論で候補を決めて、その中で交渉して話してくれそうな人をブッキングしています。キーノートスピーチはカンファレンスの全体のテーマをなんとなく決めていくので、早めに決めて告知することで、みなさんからの公募のテーマにも活かしていただけるのかなと考えています。

情熱を摩擦なしで行動に移せるような環境を作る

次が、情熱を摩擦なしで行動に移せるような環境、少なくとも雰囲気を作りたいというところ。セッションを公募制にしたり、Open Space Technology (OST) やパーティ、Discordを通じて皆さんが自己組織的にテーマ設定をして、自由に語り合えるようにしたり、クロージングキーノートで「気持ちの後押し」をしてもらって会期を終えるように工夫したり。関わるすべての人々の情熱がこの一年の活動のエネルギーであり、それは有限なものなので、なるべく摩擦や摩耗なく、仲間を見つけてやり始めてほしい、と願っています。そして、そうした情熱を瞬間的に爆発させるのではなく、なるべく平準化して、安定して燃やしてほしいと考えています。そのための知恵を交換したいです。

自分もその一人。みんなの摩擦が減れば、自分の摩擦が減りそう

そして、摩擦なくなにかをやっていきたいと考えている、おそらく最大の人間が自分だと思っています。みんなの雰囲気が、どんどん摩擦をなくす方向になっていけば、たぶん自分ももっとやりやすくなると思うんですよね。なにが摩擦になり、人の情熱を活かせなくするのか?多くの皆さんによる「群衆の英知」によって、さまざまなことを学んできましたし、摩擦を減らしてくれたと思います。他の人の情熱に後押しされることもしょっちゅうです。

技術とはすべて摩擦を減らすためにある

そして最後に、「技術を向上したい」という欲があります。人間面や、テストなど技術面の知識はもちろんのこと、オンラインカンファレンスやハイブリッドカンファレンスを行うための機材・配信・コミュニケーションの技術、安定した運営を支える財務面や税法の知識などは、やっていると学べることが多くあります。これらのことは、結果的に自分がなにかをやりたい、と考えたときの摩擦を減らしてくれます。やったことがあれば、できる。まさに経験主義(Empirical) そのものです。

摩擦のないコミュニティ運営

f:id:wayaguchi:20211223085035p:plain
というわけで、普段どんなことを考えながらカンファレンスのタスクをこなしたり、コミュニティに参画しているのか、というあたりをつらつらと言語化してみました。その中で出てきたのが「摩擦のない」というキーワードです。人が複数で何かをすれば、もちろん摩擦が存在するわけですが、できる限り摩擦を取り除いて、ちゃんと議論するべきところはして、社会的に最大効率でものごとが完成(Done)するようにしたい、と考えています。

このことは、カンファレンス運営だけでなく、さまざまな組織的な活動にも共通することなのかもしれないな、と思うところがあります。人々の情熱のエネルギーを最大効率で活かしながら、成果を積み上げていくことができたら、とても素敵なことだし、経済的にも、より幸せが巡ってくる可能性が高まるのではないか、と無邪気に期待している部分があります。

私が関わっているさまざまな場所で、そんな雑談も出来たら楽しいんじゃないかと思います。ぜひ声をかけてくださいまし。



DevOpsDays Tokyo に向けて揃えた機材

このエントリは、Reginal Scrum Gathering Tokyo 2022(以下RSGT2022)に向けたアドベントカレンダーの記事として書かれたものです。

品川アジャイルが配信を担当したカンファレンスの一つが DevOpsDays Tokyoです。

www.devopsdaystokyo.org

RSGT2021,2022での配信も、実はDevOpsDays Tokyo で機材の購入を支援してもらっていました。DevOpsDays は、もともと「システムアドミニストレータカンファレンス」という名前を考えていたくらい、運用に関して考えるカンファレンスですので、もちろん私たちは、配信のシステム運用をいかに安定させるかを考えているわけです。安定運用できない配信は価値がありませんので(キリッ)。

安定した運用を支える試行錯誤

ところで、安定した運用とはどこから来るのでしょうか。私が考える重要な要素は二つです。

  • 試行錯誤を繰り返して、練り上げた機材構成
  • 試行錯誤を繰り返して、運用習熟した人々

品川アジャイルでは、毎週のように機材の話をして、運用を繰り返しながら、DevOpsDays Tokyo や RSGT におねだりして機材を整え、試行錯誤を繰り返しています。

今回のRSGTでどんな機材構成にするかは、ばやしさんがすでに書いてくれていますので、今回は、その前にどんな試行錯誤をしてきたかについて、機材の紹介を中心に書いてみます。

bayashimura.hateblo.jp

 

配信に向けて買ってよかったもの

ゲーミングノートPC

いきなり大きな買い物ですが、これがないと話にならないのが、ゲーミングノートPCです。機種についてはもう一年くらいたっていて、内容も変動してしまうので割愛しますが、持ち運びに適した13-15インチで、ちゃんとしたグラフィックカードを載せていて、有線LANとHDMI出力に対応したものを選びました。録画したビデオの編集作業などもあるので、エンコード時間短縮のためにも、グラフィックカードは重要です。

www.mouse-jp.co.jp

ビデオキャプチャカード

ビデオカメラからの入力を取り込むために必要なのがビデオキャプチャカードです。

www.avermedia.co.jp

proav.roland.com

それほど高解像度や最新の機材を求めているわけではないので、割と安定したものを使っているのですが、買ってみたらつながらないなどの失敗もありました。最近購入したこれは、USB-Cではなく、Thunderbolt 3 が必要なのに M1 Mac ではソフトウェアが使えないという困った商品でした。

 https://www.amazon.co.jp/AVerMedia-Live-Gamer-Ultra-GC553/dp/B07DHV47HF/

M1 Macbook Pro

昨年、コスパがよいということで急いで確保したのが M1 Macbook です。しかし、有線LANにこだわったことによって、USB-Cに負荷がかかったのか、突如リブートをしてしまうという問題に当たりました。USB-Cが二ポートしかないことと、バスもあまり太くない、ということなのではないかと思います。機械というものは、挿せば動くということでもないのが難しいところです。

www.apple.com

音声インタフェース

パソコンに音声を取り込むための音声インタフェースは、利用実績の多いAG03を使いました。会場からマイク音声をもらって、こちらを経由してパソコンに取り込みます。マイク用のXLR端子も使えますが、基本的には、ステレオ標準プラグで出してもらいました。

jp.yamaha.com

ミキサー、スピーカー、マイク

DevOpsDays Tokyo 2021では、PA機材(マイクやスピーカー)のない部屋の配信があったので、検討の結果、以下のミキサーを入れて実施しました。狭い部屋なので大規模の機材は不要なのですが、ホールなどと同様にマイクとスピーカーを同じ場所で使ってもハウリングが起きないようにする必要があり、定番のヤマハEMXシリーズの中で、最もローエンドなモデルを選択しました。実はこれを買ったおかげで、後述のiPad+iRig2の検証にも役立ちました。

www.amazon.co.jp

スピーカーはJBL BT104 という小型/軽量のものを採用しました。パワーは十分でした。

https://www.soundhouse.co.jp/products/detail/item/269502/

マイクは、ワイヤレスマイクも用意したのですが干渉などであまりうまく使えず、安定して使えたのは、やはり定番のShure SM58 でした。ダイナミックマイクなのですが、いい感じに登壇者の声だけを拾ってくれる感じで、安心感があります。

https://www.soundhouse.co.jp/products/detail/item/69782/

iPad 第9世代

RSGT2022 に向けて、2021年秋モデルの iPad を購入しました。Center Stage 対応版です。配信だけなので64GB版で十分です。カメラ、音声インタフェース、(内蔵カメラ用の)ビデオキャプチャ、Zoom クライアントが全部一台に詰まっているのが衝撃です。

www.apple.com

iPad の現場運用に欠かせないのが、タブレットホルダーです。最近は譜面をiPadで見るプロが多いみたいで、安定したマイクスタンドにホルダーが組み合わせられた安定感抜群のモデルがありました。これはおすすめです。

https://www.soundhouse.co.jp/products/detail/item/208134/

音声インタフェースとしては、iPadの3極端子(入出力)を、通常のライン端子に変換する必要があるので、iRig2を利用しています。

www.ikmultimedia.com

それから HDMI出力で会場プロジェクタに投影するためには純正のLightning-HDMIアダプタを利用しています。

www.apple.com

f:id:wayaguchi:20211216141143j:plain

会議用スピーカー

複数人で話すケースで、かつ会場にPA機材がない場合は、会議用スピーカーを使うことがあります。その場合には、これを使います。RSGTでは、Open Space Technology ように使ってみようと思います。

www.jabra.jp

 

iPadとJabraを駆使した配信を行った映像はこちらになります。


www.youtube.com

 

以上、他にも買って試したものはいくつかあるのですが、結果的に運用に耐えていて、おススメできる機材はこうしたものでした。皆様の参考になれば幸いです。

 

DevOpsDays Tokyo では現在セッションプロポーザルを募集中です!

DevOpsDays Tokyo では現在セッションプロポーザルを募集中です。アジャイルな開発を支えるテストや運用で、日ごろ行っていることをぜひ教えてくだい!

https://confengine.com/conferences/devopsdays-tokyo-2022

 

では、RSGTでお会いしましょう。機材の実際は、ナイトセッションでも話し合えると思います。

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16210/night-sessions

実行委員、Women in Agile、品川アジャイル、アギレルゴコンサルティング

このエントリは、Reginal Scrum Gathering Tokyo 2022(以下RSGT2022)に向けたアドベントカレンダーの記事として書かれたものです。

それなりに年を取ってきて、自分は何をしている人だろうか?という問いがどんどんあいまいになっていくことに、どんどん慣れていく人生を過ごしています。そういう人も多いんじゃないかと思います。「この人、名前は知られてるけど、何ができる人なんだろう?」という痛い視線を感じることもなくはないです。実際、私も、わからん。

f:id:wayaguchi:20211208090910p:plain

ということで、Regional Scrum Gathering Tokyo 2022 では、実行委員業のほか、ご採択いただいた講演を一つ、それからWomen in Agile としてナイトセッションで話題を一つ、あと、品川アジャイルとして配信周りを担当していきます。アギレルゴコンサルティング株式会社としては、2011年から10年以上にわたって Scrum Alliance 認定スクラム研修をずっと提供させていただいている恩返しの意味を込めまして、スポンサーをしています。なんかいろいろありますね。準備ちゃんとできるんでしょうかね。

2022.scrumgatheringtokyo.org

自分としては、だいたい以下のルールでやることを選んでいます。

  • 独自性 = すなわち、自分しか興味持たない部分に戦力を投入する
  • シンプルさ =  すなわち、あまり複雑な技術を使わない。作りこまない
  • 協調作業 = すなわち、必ず誰かとやる。相手にとってメリットのあることを

あと、選択ではなく実施に際しての重要なこととして、ローコストで実行する道が考えられないことは「今はやらない」ということもあります。またそのうちできるかもしれないので無理しない。

f:id:wayaguchi:20211208091014p:plain

実行委員業2022

  • 独自性: 誰かがやっとけばほかの人は楽しめる
  • シンプルさ: 継続的にできることを積み重ねる。ムダを落としていく
  • 協調作業: 実行委員、スタッフ、講演者、スポンサー、参加者の皆さんと

f:id:wayaguchi:20211208090902p:plain

今回の実行委員業は具体的にはたぶん6月くらいから始動しています。本当は10か月前である3月くらいには基調講演を確定させたいなと思っているんですけど、ちょっと遅れてしまいました。できれば日本に来日してくれる人を、と思っていたんですけど、コロナの状況は先がよめないので、オンラインだとしても問題ない形ですすめてきまして、今回は3名とも北米からのオンライン講演となりました。事前録画収録ではなく、英語セッションは当日通訳付きで提供する予定です。

チケットはオンサイトとオンラインをいつでも選択可能な通常チケットと、オンサイトを選択できないオンライン専用チケットを用意しました。食品ロスを軽減するため、事前のアンケートはさせていただくと思いますが、基本的にはいつでも、オンラインとオンサイトを選択できます。前回と同様の対応ですが、コロナの状況が読めない状況では、これが最善と考えています。ありがたいことに、本年も順調に通常チケットは完売いたしました。会場の収容人数は、昨年同様、最大でも定員の50%としています。

実行委員はすべてボランティアで活動していますので、議論や作業の効率性を重視しています。基本的に、なるべく前回実績を活用するべく、「明示的に議論していないことは昨年と同じ仕様にする」という方針です。定員50%も今回は特に議論していないので、前年同様ということになっています。会場の御茶ノ水ソラシティさんも3年目になりますね。昨年はコロナ対策のためのリモートカンファレンス対応ということで、新たに回線の増強などをしていただき助かりました。

昨年、スタッフ作業中に発明された「尊敬してまーす」とインカムで伝える風習があるのですが、本年も運営のFacebookのコメントで飛び交っています。誰かが何か作業を自発的にしてくれたら、感謝を込めて「尊敬してまーす」というのを表明します。半分、冗談のように使っていて、常に微笑みを巻き起こしていますが、尊敬に嘘はないと考えています。日本人はなかなか「あたりまえのこと」を表現することを省略しがちなので、改めて尊敬を表明する風習は、とても心地よいものだな、と感じています。スクラムマスターの皆様、パクっていいですよ。

講演 - スクラム the ORIGIN : Jeff Sutherland - Roots of Scrum (2005) を語るナラティブ

  • 独自性: 案外これまでだれもやってない
  • シンプルさ: 過去の講演に沿って話すだけ
  • 協調作業: 過去のジェフ・サザーランドさんと。壁打ちも繰り返す

f:id:wayaguchi:20211208091238p:plain

今回は、2005年に行われたスクラムの共同発明者ジェフ・サザーランド博士による、スクラムの源流についての講演について、できる限り原典に忠実に伝える試みをする予定です。同タイトルの講演を、2011年の初来日で、Innovation Sprint 2011 の基調講演として行っていただいたのですが、残念ながらビデオを録画できなかったため、それ以前の講演から同内容を探っていきます。

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/15962/the-origin-jeff-sutherland-roots-of-scrum-2005

スクラムを着想するにあたって、どういったものを参考にしたのか?最初のスクラムはどういったものだったのか。スクラムガイドには記載されていない、源流を探る内容になっています。それを知ったからと言って、スクラムをうまく適用できるようになるというものではないでしょうけれど。生物学の世界では「個体発生系統発生を繰り返す」という言葉があるそうです。ある生物が生まれる過程は、その進化の過程で経てきた様々な生物をトレースするように行われるということです。ジェフさんがスクラムを着想してやってみた、という情報の中には、ソフトウェアやものづくりの進化そのものも織り込まれているのではないかと思います。その知識を深めることで、さらに皆さんのチームのスクラムの進化にも役立つかもしれません。

個人的には、スクラムフェス大阪でスクラムの源流となる「The New New Product Development Game (新しい新製品開発のゲーム)」(竹内・野中論文)をみんなで読みました。スクラムフェス三河XP祭りでは、認知科学の領域で協調作業を研究した論文「Constructive interaction and the Iterative Process of Understanding(建設的相互作用と理解の反復的プロセス)」(三宅なほみ「ボビンの論文」)をみんなで読みました。偶然にも同じ1986年に発表されたこの二本の論文は、当時の組織論と、認知科学におけるコラボレーションの研究の代表例と考えています。35年前の論文ではありますが、ほとんど色褪せず、現代の私たちのスクラム実践に示唆を与えてくれるものだったと思います。

f:id:wayaguchi:20211208091402p:plain

スクラムの最初の実践は1993年で、この野中竹内論文を参考にしたと、ジェフさんは語っています。また、主体的なチームメンバーによる協調的なコミュニケーションを活用する点は、強いリーダーによる専制的な組織運営とは、真逆の文化を感じさせます。また、トヨタ自動車の文化を参照している点で、日本人にとっては理解しやすい内容になっていると思います。

実は、こうした過去の資料や講演をとりあげるようになったのは、昨今の機械学習音声認識技術の向上が背景にあります。このセッションの準備においても、そうした技術を活用しています。10年前にも同じ元資料は存在してたのですが、そうした原典に、容易にアクセスできるようになったことは、現代の我々にとって、日本語と英語の垣根を超えるための、非常によい機会になっていると感じます。

f:id:wayaguchi:20211208091447p:plain

以前は「自分の運営するカンファレンスでは講演しない」というルールを自分に課していたのですが、最近はスタッフ業もこなれてきたので、講演もできるようになってきました。今回もプロポーザルを出しまして、ありがたいことに多くのLikeをいただきまして、採択されました。(実行委員なんだから自分で採択されるようにできるだろう、と感じる方もいらっしゃるかもしれませんが、このトークに関しては完全にLikeの数で採択されていて、忖度も関与もしていません。)

ナイトセッション: Women in Agile 

  • 独自性: 案外これまでだれもやってない
  • シンプルさ: アジェンダなしで話すだけ
  • 協調作業: WiAメンバー4人で

f:id:wayaguchi:20211208091518p:plain

初日(1月5日)の夕方には、通常のセッションのあと、懇親会の代わりにナイトセッションという枠を用意しています。特にアジェンダを用意していませんが、あらかじめ提案された内容について、Open Space Technology のように、カジュアルな雑談をしよう、というセッションです。 

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16210/night-sessions

Women in Agile は、職場や社会における女性や多様性についての課題に取り組むコミュニティ活動として、世界中で行われているものです。Women Developers Summit で日本の有志のセッションを行いました。引き続き Women in Agile を立ち上げていくべく、カジュアルな議論を行っていきます。女性はもちろん、それ以外の方の参加も歓迎です。ぜひ、立ち寄ってみてください。

そのほかに、オンライン配信について語り合うセッション、地方コミュニティについてのセッション、新しく参加した方向けの知り合いを作るセッションなどが行われます。他にもセッションのテーマを追加することもできますので、興味あるテーマを見つけて、参加してみてください。

品川アジャイルによる配信 - よりシンプルに

  • 独自性: 手間も機材費用もかかるのでボランティアでやる人がいない
  • シンプルさ: 放送機材ではなくパソコン技術を活用
  • 協調作業: 品川アジャイルの皆さんと

f:id:wayaguchi:20211208091606p:plain

すでにばやしさんがブログに書いてくれている通り、今年も品川アジャイルとして、ハイブリッドカンファレンスを支えるリモート配信を行います。昨年の反省を活かしながら、さらに新しく発表された機材を活用して、よりシンプルでスリムな配信体制を実験してきました。これがうまくいくと、多くの勉強会のハイブリッド開催に活用できるのではないかと思います。機材も含め、ぜひ参考にしていただければと考えています。

bayashimura.hateblo.jp

アギレルゴコンサルティング株式会社スポンサーセッション

  • 独自性: アギレルゴはそもそも人が少ない
  • シンプルさ: 今回は松元さんにおまかせ(丸投げ)するだけ
  • 協調作業: 松元さん、松浦さんと

f:id:wayaguchi:20211208091745p:plain

アギレルゴのスポンサーセッションとしては、松元さんに話していただくことになりました。

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16242

本年も大変盛況な、認定アジャイルリーダーシップ研修に関連して、リーダーシップ論の最新の話をしてくれるようです。チームとしてスクラムを行うだけでなく、組織に新しい仕組みを導入するリーダーとして、どのようにふるまうと良さそうなのか、大企業でアジャイル適用から経営企画までこなしてきた、松元さんなりの視点で整理してくれそうですね。

ゲーム業界の大規模カンファレンス「CEDEC2021」で、松元さん、松浦さんと、リーダーシップについてのセッションを提供しました。こちらも大変盛況で、多くの好意的なフィードバックをいただきました。

cedec.cesa.or.jp

ということで、RSGT2022でお会いしましょう!

  • 独自性: ハイブリッドカンファレンスとして二年目の実績
  • シンプルさ: チケットを買うだけで参加できる
  • 協調作業: 実行委員、スタッフ、講演者、スポンサー、参加者の皆さんと

f:id:wayaguchi:20211208091929p:plain

ということで、今回のRSGT2022で私が担当する予定のことや、その関連のお話をまとめました。会場で、Discordで、みなさまのご参加をお待ちしております。

 

ちなみにこのブログの草稿は、「閃光のハサウェイ」という映画を一本聞き流しながら書きました。約100分の集中時間確保に使っています。「ハサウェイタイマー」と呼んでいるんですが、他の人におすすめしたところ、「やってみたけど、全然集中できない」というフィードバックをいただいております。あれ、おかしいな。

f:id:wayaguchi:20211208092004p:plain

全然関係ないですけど、閃光のハサウェイについて、プロデューサーの小形さんがどういう考え方で進めているかを話しているインタビューです。

s.akiba-souken.com

 

カンファレンスの基調講演を誰にお願いするか考える時のノート

このエントリは、Reginal Scrum Gathering Tokyo 2022(以下RSGT2022)に向けたアドベントカレンダーの記事として書かれたものです。

 

基調講演を決める時に考えたらよさそうなことを徒然なるままにあげてみたメモです。

f:id:wayaguchi:20211208093527p:plain

  • 実行委員からアクセスできるか(間接的でもよい
  • どんな話をして欲しいか伝えられるか
  • なぜその人に、いまお願いしたいかを伝えられるか
  • 適切な謝礼でお願いする = 無償カンファレンスの場合は、そこの場所で話すことに意義を感じてくれそうな人 (お互いのリスペクト)
  • 他のカンファレンスで話している人だとお願いしやすそう(聴衆がかぶらないなら新作である必要はない
  • 当日のスケジュールを確実に抑えてもらう
  • 初めての参加者も聞くべき話
  • アジャイル歴が長い人だけが聞きたいような奇をてらった人選はよく考えてから(悪いとは限らないので、ちょっと冷静になってもやろうって思えるか
  • オープニングを除けば、その人のトークから1日のテンションが決まるので、刺さるとか明るいとか燃えるとか、イメージをつけられる(終わった時にどうなってそう?
  • そういう意味では聞いたことある話者はお願いしやすいかもですね(思ったよりマンネリって起こらなそう
  • コミュニティのカンファレンスは集客できなくても赤字にならないようにやるので、基調講演者の人気で参加者を増やそうというのは考えなくて良さそう(客寄せパンダさんじゃなくていい
  • 断られたら引き下がる = 優先順位付き候補リストを作っておく
  • 性別とか年齢とかのダイバーシティも考えるといいこともある...けど、そこそこに (属性だけでいい話がハマるわけでもない
  • ここ数年以内にお願いしてないこと
  • 実行委員ではないこと
  • ただし正解はない

株式会社ホロラボに入社しました。 - 最初の2週間でやったこと

株式会社ホロラボに入社しました。アギレルゴコンサルティング株式会社は退社するわけではなく、引き続き研修中心に仕事を行っていきます。

ホロラボとのご縁

ホロラボは、Kinect とか HoloLens をやっているコミュニティのエンジニアを中心に2018年のHoloLens 日本向け正式販売開始を契機に設立されました。私は当時楽天株式会社で Rakuten Technology Conference というのを実行委員の一員として運営していて、そこで、ARとVRに関する展示をしてもらおう、という回があり、その際に、ホロラボ設立直前のCo-Founder、中村薫さんと伊藤武仙さんに出展をしていただいたのがご縁の発端になります。中村さんについては、さらにさかのぼること10年くらい、Shibuya Trac とか すくすくスクラムといった勉強会からのご縁になります。遠巻きにKinectやHoloLensでの活躍を眺めていたのですが、2019年末にホロラボの拡大に伴って組織コンサルのご依頼をいただいたところあたりから、RSGTで話してくれたり、たまにお邪魔してピザを食べたり、などという交流があったのですが、今回、組織拡大に伴って起きてきそうな様々な課題を一緒に考えていきながら、エンジニアの人たちが明るく暮らせるような組織づくりに寄与できたらうれしいな、ということで入社させていただくことにしました。

f:id:wayaguchi:20210817082852p:plain

ホロラボの組織

ホロラボはまだそれほど大きくない組織です。学校で言えばひと学級分くらいの規模感なので、組織階層はかなりフラットです。いくつかのチームに分かれています。2019年にコンサルしたときには、ちょうどこのチームを作ろうか、というあたりだったのですが、そこから1年半ちょっとが立って、おおまかには企業向けにソリューションを展開するチームと、プロダクトのチームに分かれています。軽量ですが本部機能や総務の人たちもいます。

もともと企業向けに個人として受託をやっていた人たちが会社を設立した、というのが源流ということもあり、企業としてPOC(概念実証)や先行研究としてVR(仮想現実)やMixed Realityを取り組んでいく際の技術的なパートナーとして多く採用されています。一人一人が実現力のあるエンジニアで、顧客の要望に合わせて、というだけでなく、相談にのりながら、現時点で技術的に実現可能な部分を見極めて、比較的短期間で成立させていく、というのが現在の主流のビジネスになります。

プロダクトとしては、もともと様々な企業向け案件での実績の蓄積から、共通化されたワークフローや、煩雑なデータ変換(ETL)などを、プロダクトとして切り出したものがあります。

https://hololab.co.jp/service/

f:id:wayaguchi:20210817083237p:plainf:id:wayaguchi:20210817083255p:plain

f:id:wayaguchi:20210817083330p:plainf:id:wayaguchi:20210817083354p:plain

f:id:wayaguchi:20210817083528p:plainf:id:wayaguchi:20210817083552p:plain

最初の二週間でやったこと

まずは、企業向けにソリューションを提供しているチームの人たちと面談をすることにしました。本当はもう少し手っ取り早く、ワークショップで課題や方向性を、というイメージで相談されたのですが、任天堂の故岩田聡さんが、前職であるHAL研究所の社長を引き受けた際に全員との面談をしたというエピソードを思い出しました。
f:id:wayaguchi:20210817080529p:plain

しかし、岩田さんと違って、私はこの組織についても人々についても、技術についてすら全くの素人であることもあり、まずは皆さんがどんな仕事をしているのか?なぜホロラボに入ったのか、など、個人的に興味のある範囲の話をざっくばらんに教えてもらいました。これは本当に楽しい時間で、特色のある多彩なエンジニアが集まっている会社であることを、改めてはっきりと認識できました。

まさに、岩田さんが言っていることを、その片鱗だけですが、追体験できたような気がします。

いろんな人に面談すればするほど、
わたしはいろんなことがわかりまして、
そのなかから
どういうふうに
組織を作りなおして、
どういう運営をしたらよくて、
なにがみんなのやる気を
ひきだすことに役にたっていて、
なにがみんなの
やる気を阻害しているのかとか……

すべて見えてくるんですね。

半分正しいことを避ける

今回、組織について考えていくということもあり、改めてボブ・サットンさんが話していたことについて読み直したりしています。「半分正しいこと」を避けながら、一歩一歩みんなで考えて、社内だけでなく、お客さんやユーザーさん、もちろん家族や地域社会の人たちを含め、いろんな人が幸せに楽しくやっていけそうな組織を目指していければな、などということを考えています。

kawaguti.hateblo.jp

今後とも、ご指導ご鞭撻のほどをよろしくお願いいたします。