XP祭りでは毎年、出版者様より見本誌をいただき、これからアジャイルを始めたり、これから業界で活躍される若手の皆様に役立つ本をご紹介しております。こちらで本年ご協賛いただいた本のリストを掲示いたします。ご協賛誠にありがとうございます。
以下の本は、5冊いただきました。
以下の本は、5冊いただきました。
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
以下の本は、2冊いただきました。
こちらはコミュニティで出版された同人誌を二冊いただきました。
以上、大変ありがとうございます。こちらでご紹介の上、当日はこちらのリストを掲示しまして、会期終了時に、希望する参加者の方にプレゼントさせていただきます。
脱予算経営 Beyond Budgeting の 12原則というのが BBRT のサイトにあったので日本語訳をつけました。
Beyond Budgeting - enabling business agility
脱予算経営 - ビジネスアジリティを実現する
Leadership Principles
リーダーシップ原則
Management processes
マネジメントプロセス
間違いがありましたら是非教えてください！
**前に書いてたブログ
スクラムフェス大阪を無事に終了しました。スクラムフェス大阪は４回目で、第一回は2019年にオンサイト開催(関大MeRise様をお借りしました)、2020年はコロナ初年度ということでオンライン開催(19トラック)の形を作り、2021年のオンライン開催を経て、2022年はハイブリッド開催となりました。品川アジャイル(#shinagile)では、現地からのラジオ的なライブ放送を通じて、スクラムフェス大阪をはじめ、各地のスクラムフェスのオーガナイザーの皆さんの取り組みや思いを聞きました。
スクラムフェス大阪2022の開催は、オンラインを中心としたハイブリッド開催。現地イケマンカンファレンス会場の役割は、セッション会場ではなく「廊下」。13トラックの地域トラックと、3トラックのスポンサートラックがオンラインで開催され、現地はそれを一覧で観られる設備を用意しつつ、参加者は交流ができるという開催形態でした。
セッションのリストはこちらです。
Scrum Fest Osaka 2022 - Program Schedule | ConfEngine - Conference Platform
見きれないほどたくさんあります。聖徳太子でもすべては見られないので、現在は参加者向けにビデオが公開されています。参加者を中心に同時視聴会(参加者と一緒にみることはできる)が開催されています。
スクラムフェス大阪の会場はこんな感じです。(壁一枚隔てて隣のホール)
スクラムフェス新潟のテーマはテストや品質保証。品川アジャイルの現地放送も600再生を超えたとのこと。ゆるっと見るのにほんといいコンテンツです。「肩剥しってアジャイルなの？」「だってウォーターフォールではやらないでしょ！」
今年は初の開催で、新潟駅前のコワーキングスペースNinnoで開催されました。お昼に地元選出の議員さんが視察に来訪するハプニングもあり、そのタイミングでクリエーションライン社＆ウイングアーク1st社のスポンサートーク、通称「劇団クリエーションライン」を観覧されました。
次回の構想としては、スタジアムを使えるかも、なんて話も出ているようですが、来年も変わらず、Agile Testing Daysの感覚を持ってくるそうです。
私も実行委員なので余計な話をしていますが、スクラムフェス三河のテーマは製造業です。愛知県の三河地域から、静岡県の遠江、駿河地域にかけてを駿遠三(徳川家康の旧領地)地域と言いますが、世界的に有名な製造業の多いこの地域を盛り上げていきたいと考えています。開催地は豊橋です。東海道新幹線から徒歩5分くらいの会場で行いますので、ぜひ足をお運びください。
スクラムフェス大阪基調講演の角征典さんと栃木トラックオーナーの木村さんをゲストにお迎えして Fortnite についてのディスカッションを行いました。いい大人がゲームで交流する意味、世代を超えて繋がれる世界を感じていただくセッションを行いました。
まだ開催はされていないのですが、いずれ開催するはずの鳥取のちんもさんのインタビューを聞きました。「鳥取でできたらどこでもできるんじゃないですか？」ということで、日本全体に夢を与えるために初開催を目指すそうです。放送中に品川アジャイルによる下見が決定しましたので、いずれ開催されるに違いないです。鬼太郎空港とコナン空港があるので間違えないように注意です。
来年初開催を目指しているスクラムフェス福岡は、現在、eスポーツ施設での開催を検討しているそうです。eスポーツの配信に使うプロ機材を使っての配信ができるのではないかということで、品川アジャイルのスタッフが燃えています。福岡は福岡市の行政としての取り組みあり、金融センターとして様々な企業がアジャイルやWeb開発をを行っていて、先端的な事例や苦労話を聞けるカンファレンスになるに違いないです。福岡は空港のアクセスもいいのでぜひ。スタッフとして巻き込まれるチャンスもあります！
オーガナイザーの天野さんが仙台に引っ越したことがきっかけで、スクラムフェス仙台が初開催されることになりました。まさにリモートワーク時代の申し子のようなカンファレンスです。会場も天野さんが仕事で利用しているコワーキングスペースとのことで、地域密着の取り組みが期待されます。基調講演はエバッキーこと江端さん。スポンサーもセッションも数多く集まっているので、素晴らしいカンファレンスになることが期待されます。
仙台はコロナ以前は「支店経済」と呼ばれて、本店である東京からの発注仕事が多かったそうなのですが、地域に縛られずに仕事できるようになった昨今は、新しい取り組みも多く生まれているようです。品川アジャイルでも配信に行きますので、ぜひご期待ください。
今回インタビューは行っていませんが、昨年オンライン開催されたスクラムフェス札幌も、今年はハイブリッド開催に移行し、札幌市教育文化会館での開催の予定です。プロポーザルとスポンサー募集はまもなく開始だそうです！
スクラムフェスは日本各地に広がり、開催のない月の方が少ないという状況になりつつありますが、それぞれ特色を持ったテーマで工夫を凝らして開催されていて、運営もスクラム実践者の人たちですので、無理しない、継続的な開催が行われます。スタッフワークからも実践を学ぶことができると思いますので、各地のスタッフにアクセスしてみてください。スクラムフェス大阪 @ Online のDiscord サーバーへどうぞ。各地のスクラムフェスに参加いただければ、招待が届きます。
今年も年初から、Regional Scrum Gathering Tokyo 2022 のスタッフワークをしてきました。今回も非常に多くの、熱意ある皆様に支えられて、学びの多いギャザリングになったことをお礼申し上げます。「ギャザリング」という言葉をとても尊重していて、ふだん集まらない同志、実践者の皆さんが集まる会として、より深く、話し合える場所を提供していきたいと考えています。Twitter で #RSGT2022 のハッシュタグで検索していただければ、多くの参加報告記事を見つけることができると思います。
今回のキーノートは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
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
クロージングキーノートは牛尾剛さんにお願いしました。10数年来のお付き合いなのですが、常にチャレンジを続ける姿勢がいつもすごいな、と思います。英語を勉強しに留学しに行ったり、Microsoft の本社に飛び込んでクラウドプラットフォームの内側を作っているというものすごいキャリアチェンジの話や、最近の Microsoft の開発文化について聞きたいなー、ということでお願いしました。すでに、ほぼ書き起こしのPublicKeyさんの記事が出てますので、内容を見ていただくことができます。
講演中、特にDiscordが盛り上がっていたのが、「納期がない」という話でしたね。話を遮って質問を入れてしまいましたが、みなさんにとってよい気付きになっていれば嬉しいです。実は８月にあったAgile2021で、ケント・ベックさんが「デッドラインを自分で決められると思っている人々がその権力をいまだに手放していない」点を憂いていて、XPの計画ゲームやスクラムのスプリントプランニングの仕組みに触れていながらも、やはりなかなか説得が難しいと考えているところが、「作業の見積もりを開発者が行い、進捗は開発者を信頼して任せる」ところなんだろうな、と想像します。今後の皆さんの取り組みに期待しています！
あと、「ガチ三流」というタイトルに過激に反応している人がいるようですが、牛尾さんは本心から自分のことを「ガチ三流」だと思っているのだと思います。決して、誰かを下に見て言うとか、思ってないけど卑下して言う、という器用な人ではないことだけは、ここで言っておきたいです。
今回は品川アジャイルとしての配信は二回目になります。iRig2を知ったことと、CenterStage対応のiPadが発売されたことで、機材を一新して配信を行いました。この機材セットは安価で軽量でありながら、どなたにでも扱いやすいものなので、マイクやスピーカーがあるような会場でハイブリッド配信をしようかな、という方には参考にしていただければと思います。
昨年は会場に張り付かざるを得なかった品川アジャイルのスタッフが、ほとんどスタッフルームでの監視とZoom運用に回れたのが非常に大きく、来年こそはスタッフルームラジオをやりたいですね、などと話している余裕っぷりです。一方で、課題もいくつか見つかっていますので、今後の実験がまた楽しみです。特にOSTについては、通常の会議室を使ったハイブリッドはかなりうまくできたようですが、オープンな環境のテーブルでは会議スピーカーが環境音を拾いすぎてしまってリモートからの参加が難しかったようです。そうなんです。課題は音。これは本当に難しくて、上手に設計しないとやってられません。ネットが潤沢にあれば全員がスマホとヘッドセットでDiscord/Zoomにつないでしまうほうがいいわけですが。
アギレルゴコンサルティングとしてはスポンサーを行いました。松元健さんがスタッフとして加わってくれたので、スポンサーセッションで話していただいています。二人ともRSGTのスタッフワークがあり、スポンサーブースはほとんど何もできませんでしたが、アギレルゴコンサルティングでは今年も珠玉のトレーナー陣による通訳付き研修を行っていきます。
スクラムの共同開発者ジェフ・サザーランド博士が2005年に行った講演について紹介しました。デンマークで行われた講演ですが、驚くほど日本からの影響について語ってくれています。2011年に始めてお招きして、Innovation Sprint をやったわけですが、それがどれだけジェフさんにとって大きなことであったのか、改めて認識した思いです。資料はこちらです。
ビデオは現在参加者向けに公開されていますので、参加者の方は会場のDiscordチャンネルの概要欄のURLから見てください (ZoomのURLがあったのと同じ場所です)。Room C Day1 04:40:00 くらいからです。
昨年に比べ、状況はよかったので、リアル参加を選択された方が多くいらっしゃいました。RSGTとしては、コロナ対策として半数の席数のみに制限し、とにかく場を閉めず、参加者の皆さんが自由に選択できるようにしています。そのためにハイブリッド開催への投資も行ってきました。オミクロン株の流行で一気にまた感染者が増えている状況ですので、来年以降もまた流動的な状況での開催になる可能性があります。できるだけ軽量にハイブリッド開催できるようなノウハウも開発していければと思っています。
前回の開催は、スクフェス大阪以降で普及してきた、DiscordとZoomを利用したオンライン開催のノウハウと、品川アジャイルで地道に研究してきた配信の仕組みを組み合わせて、スクフェス三河でご協力いただいた地元田原の技術集団オレンジボックスさんのご協力もいただき、ハイブリッド開催にこぎつけました。アギレルゴコンサルティングの研修の通訳でいつもお世話になっているISSさんともZoomでのオンライン研修のノウハウを溜めてきたことも有用でした。今回はさらにそこに日英通訳としてSeth Reamsさんに加わっていただくなど、これまでの関係を活かしながら、さらにスムーズな開催をできたのではないかと思います。コーヒー提供の縁の木さんもゴミのリサイクル100%を目指す「蔵前モデル」を紹介してくださいました。
アフターコロナの時代では、多くの企業やチームがリモートでの作業を強いられてきました。でも、もう２年経って、だいぶ慣れましたよね。有用性も限界もわかってきた。RSGTに参加する皆さんは、そうしてツールやコミュニケーションのコツについて実験を繰り返してきた方がほとんどだと思いますので、こうした皆さんがリアルでつながり、バーチャルでの活動を続けていくことで、新しい地平が開けていくと感じています。たとえば英語学習で言えば「全然できない」「ネイティブのように流暢」のように過激な二分法で考えるのが、初心者レベルで陥りがちな罠です。アジャイルか？ウォーターフォールか？のように二分法で考えるのも、だいたいやったことがない方なんじゃないかと思います。私たちは実践者なので、そういう表層的なレベルにとどまらず、何がどう役立つのか、具体的に試しながら、選択肢として手に付けていきたいと思うんです。きっと皆さんそうですよね。
今回は各スクフェスのスタッフの皆さんや、開催に興味がある皆さんもリアルに集まれた人もいらっしゃいました。RSGTに比べてスクフェスの「よさ」は、その間口の広さ。スクフェスで始めて発表しました！という方が多くいらっしゃって、内容も生々しい努力の発表が多く、ある意味RSGTよりも学びが深い部分があります。
各地域のスクフェス開催がぐっと進んだ感じがします。すでに行っている大阪、札幌、三河に加え、すでにRFPを募集している新潟が今年加わる予定ですが、仙台、福岡が企画を具体的に進め始めて、広島もやりますよーと言ってくれております。あとやりたいと言ってくれているのが鳥取、金沢、Twitterでにわかに始まっている青森、などなど、まあいずれそのうち、と思っていただいている方々もいるので、決して焦らず、できるときにはできる感じでできたらいいかなーと思っております。あと、品川もやりたくなってきてます。
残っているスタッフワークは、荷物やノベルティの整理のほか、スタッフの皆さんの交通費や経費の精算と、講演料支払いです。幸いスタッフの皆さんの旅費や経費を支払える余裕がありますので、お支払いしていきます。海外講演料については、今回は米国向けということで、租税条約の手続きをするためには米国居住者証明を先方に取ってもらう必要があるので、20.42%の非居住者向けの源泉所得税を支払うことにしました。本来二重課税を防ぐ目的で結ばれている租税条約が、米国IRSはどうも90日以上かかるケースがあるようで(多段居住者証明ですよ？)、このように利用しにくくなっていることは本当によくないと思います。
あと、どこかのタイミングで、参加者以外にも録画を公開することになろうかと思います。現在でも参加者の方と同時視聴することはできますので、ぜひコミュニティの同時視聴会とか、社内での同時視聴会をご検討いただければと思います。
今回のカンファレンスを通じて、思い出したところがあるので最後ですが書いておきます。スクラムでは「自己組織化 Self Organization」したチームを重視しています(最新のスクラムガイドでは自己管理に代わりましたが意味するところは同じと思います )。この用語は、竹内野中 “The New New Product Development Game” から来ています。優れたプロダクトチームの人たちは、それぞれが自律的に動き、創造的に解決していくさまを表しています。メンバーを子供扱いせず、自分からチームに貢献するすべを考えていただくことを、信頼するということです。RSGTというカンファレンスが、これだけ少ないスタッフで、また多くのスピーカー、スポンサー、参加者の皆さんに支えていただけているのは、多くの参加者の方々が、この場を「よいもの」だと思い、もっとよくしたいと感じて、自ら動いていただいているからに他なりません。もしかすると、他の多くのカンファレンスに比べると、丁寧な文書での説明や、入り口での大声でのアナウンスが欠けているんじゃないかなと、思います。この点は初参加の方には申し訳なく感じることもありますが、少なくとも私は「いつも来てくれる皆さん」を重視しています。そしてそうした皆さんが、さらに新しく来た方々と繋がって、親切にご案内いただいたり、会の外でも新しい活動につなげていただいているのを見聞きします。「正統的周辺参加」という概念があります。人は専門知識を身につけるときに、組織の外延から参画して、徐々に学びながら、活動しながら、徐々に中心に向かっていく、という組織学習のモデルのようなものです。今年もしかしたら、残念だったなー、知らなかったなー、というところがあったかもしれません。会期の終了後に聞いた、面白い取り組みがあったのかもしれません。でも、焦らないでください。また来年も、その先も、できる限り同じような場を作っていきたいと考えています。みんなが飽きて来なくなるまで、RSGTがRSGTであり続けたらいいな、と考えています。
技術は変わっても、人は自分の思う通りには変わってくれないものです。RSGTに関わってくださった皆さんが、徹底したリアリストとして、今年も一歩一歩、実験を繰り返していただければと、切に願っています。今年のRSGTは終わりました。お祭りの熱狂が引くのは一瞬のことです。しかし、多くの方の心の中に灯った種火は、これからの行動の糧になるんじゃないかと思います。所属組織で、コミュニティで、家庭で、そしてスクフェスで、RSGTで灯った種火を、具体的な一歩に変換して、一つ一つの実験を進めていただけることを願っています。いきなり膨らませてしまうと、割れるのも早くなります。内部のよさを磨きながら、それでいて機会を逃さず、少しずつ活動を成長させていっていただければと思います。きっと一番面白いのは、次の実験です！なので、今の実験はそこそこにして、休んでしまったほうがいいかもしれません。ゆっくりいきましょう。一歩一歩行きましょう。「スクラム自体は問題を解決しません。解決するのは人間です」
来年もRSGTでお会いできれば幸いです。たぶん6-7月くらいからスポンサーやプロポーザルを募集するのではないかと思います。長文、お読みいただきありがとうございました。
このエントリは、Reginal Scrum Gathering Tokyo 2022（以下RSGT2022）に向けたアドベントカレンダーの記事として書かれたものです。
今日はカンファレンスの運営について、ちょっと言語化してみました。
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というカンファレンスを起点に、そこに共感してくれた人たちが、自分たちでやりたいカンファレンスを始めてくれている、というのがこれまでの流れです。このことは決して私が始めたことでも、私一人が行ってきたことでもないのですが、カンファレンスの運営について、ちょっと思っていることを書いておこうかな、というのがこのエントリの趣旨です。興味のある人だけ、ちらりと読んでいただければ幸いです。
勉強会というものを始めたのは、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)するようにしたい、と考えています。
このことは、カンファレンス運営だけでなく、さまざまな組織的な活動にも共通することなのかもしれないな、と思うところがあります。人々の情熱のエネルギーを最大効率で活かしながら、成果を積み上げていくことができたら、とても素敵なことだし、経済的にも、より幸せが巡ってくる可能性が高まるのではないか、と無邪気に期待している部分があります。
私が関わっているさまざまな場所で、そんな雑談も出来たら楽しいんじゃないかと思います。ぜひ声をかけてくださいまし。
このエントリは、Reginal Scrum Gathering Tokyo 2022（以下RSGT2022）に向けたアドベントカレンダーの記事として書かれたものです。
品川アジャイルが配信を担当したカンファレンスの一つが DevOpsDays Tokyoです。
RSGT2021,2022での配信も、実はDevOpsDays Tokyo で機材の購入を支援してもらっていました。DevOpsDays は、もともと「システムアドミニストレータカンファレンス」という名前を考えていたくらい、運用に関して考えるカンファレンスですので、もちろん私たちは、配信のシステム運用をいかに安定させるかを考えているわけです。安定運用できない配信は価値がありませんので(キリッ)。
ところで、安定した運用とはどこから来るのでしょうか。私が考える重要な要素は二つです。
品川アジャイルでは、毎週のように機材の話をして、運用を繰り返しながら、DevOpsDays Tokyo や RSGT におねだりして機材を整え、試行錯誤を繰り返しています。
今回のRSGTでどんな機材構成にするかは、ばやしさんがすでに書いてくれていますので、今回は、その前にどんな試行錯誤をしてきたかについて、機材の紹介を中心に書いてみます。
いきなり大きな買い物ですが、これがないと話にならないのが、ゲーミングノートPCです。機種についてはもう一年くらいたっていて、内容も変動してしまうので割愛しますが、持ち運びに適した13-15インチで、ちゃんとしたグラフィックカードを載せていて、有線LANとHDMI出力に対応したものを選びました。録画したビデオの編集作業などもあるので、エンコード時間短縮のためにも、グラフィックカードは重要です。
ビデオカメラからの入力を取り込むために必要なのがビデオキャプチャカードです。
それほど高解像度や最新の機材を求めているわけではないので、割と安定したものを使っているのですが、買ってみたらつながらないなどの失敗もありました。最近購入したこれは、USB-Cではなく、Thunderbolt 3 が必要なのに M1 Mac ではソフトウェアが使えないという困った商品でした。
https://www.amazon.co.jp/AVerMedia-Live-Gamer-Ultra-GC553/dp/B07DHV47HF/
昨年、コスパがよいということで急いで確保したのが M1 Macbook です。しかし、有線LANにこだわったことによって、USB-Cに負荷がかかったのか、突如リブートをしてしまうという問題に当たりました。USB-Cが二ポートしかないことと、バスもあまり太くない、ということなのではないかと思います。機械というものは、挿せば動くということでもないのが難しいところです。
パソコンに音声を取り込むための音声インタフェースは、利用実績の多いAG03を使いました。会場からマイク音声をもらって、こちらを経由してパソコンに取り込みます。マイク用のXLR端子も使えますが、基本的には、ステレオ標準プラグで出してもらいました。
DevOpsDays Tokyo 2021では、PA機材(マイクやスピーカー)のない部屋の配信があったので、検討の結果、以下のミキサーを入れて実施しました。狭い部屋なので大規模の機材は不要なのですが、ホールなどと同様にマイクとスピーカーを同じ場所で使ってもハウリングが起きないようにする必要があり、定番のヤマハEMXシリーズの中で、最もローエンドなモデルを選択しました。実はこれを買ったおかげで、後述のiPad+iRig2の検証にも役立ちました。
スピーカーはJBL BT104 という小型/軽量のものを採用しました。パワーは十分でした。
https://www.soundhouse.co.jp/products/detail/item/269502/
マイクは、ワイヤレスマイクも用意したのですが干渉などであまりうまく使えず、安定して使えたのは、やはり定番のShure SM58 でした。ダイナミックマイクなのですが、いい感じに登壇者の声だけを拾ってくれる感じで、安心感があります。
https://www.soundhouse.co.jp/products/detail/item/69782/
RSGT2022 に向けて、2021年秋モデルの iPad を購入しました。Center Stage 対応版です。配信だけなので64GB版で十分です。カメラ、音声インタフェース、(内蔵カメラ用の)ビデオキャプチャ、Zoom クライアントが全部一台に詰まっているのが衝撃です。
iPad の現場運用に欠かせないのが、タブレットホルダーです。最近は譜面をiPadで見るプロが多いみたいで、安定したマイクスタンドにホルダーが組み合わせられた安定感抜群のモデルがありました。これはおすすめです。
https://www.soundhouse.co.jp/products/detail/item/208134/
音声インタフェースとしては、iPadの3極端子(入出力)を、通常のライン端子に変換する必要があるので、iRig2を利用しています。
それから HDMI出力で会場プロジェクタに投影するためには純正のLightning-HDMIアダプタを利用しています。
複数人で話すケースで、かつ会場にPA機材がない場合は、会議用スピーカーを使うことがあります。その場合には、これを使います。RSGTでは、Open Space Technology ように使ってみようと思います。
iPadとJabraを駆使した配信を行った映像はこちらになります。
以上、他にも買って試したものはいくつかあるのですが、結果的に運用に耐えていて、おススメできる機材はこうしたものでした。皆様の参考になれば幸いです。
DevOpsDays Tokyo では現在セッションプロポーザルを募集中です。アジャイルな開発を支えるテストや運用で、日ごろ行っていることをぜひ教えてくだい！
https://confengine.com/conferences/devopsdays-tokyo-2022
では、RSGTでお会いしましょう。機材の実際は、ナイトセッションでも話し合えると思います。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16210/night-sessions
