for Startups Tech blog

このブログのデザインを刷新しました。(2023/12/26)

【フォースタ テックブログ】フォースタートアップスでやったチームビルディングを色々と挙げていく

f:id:forStartups:20211025164523j:plain

どうも、村林(@bayashimura)です。今回は私が入社してから開発チームで行われたチームビルディングの色んな手法を参加者の感想とともに紹介していこうと思います。

ドラッカー風エクササイズ

出典:アジャイルサムライ

 

shop.ohmsha.co.jp

10月に速水が参加したタイミングで実施しました。

  • 自分は何が得意なのか?
  • 自分はどういうふうに仕事をするか?
  • 自分が大切に思う価値は何か?
  • チームメンバーは自分にどんな成果を期待していると思うか?

というのをチームメンバーが各自答えて、チームメンバー同士の相互理解や期待値のすり合わせを促進します。

今回の実施では追加の質問として

  • 他のチームメンバー(各個人)に期待することは何か

というものも付け加えております。これはジョハリの窓で言う秘密の窓を開くだけではなく、盲点の窓を開くこともチームビルディングにおいて重視しているからです。新しく参加したメンバーに関しては期待値のすり合わせ、今まで一緒に活動していたメンバーに対してはフィードバックの作用が望めます。

ジョハリの窓とは

自己には「公開されている自己」(open self) と「隠されている自己」(hidden self) があると共に、「自分は知らないが他人は知っている自己」(blind self) や「誰にも知られていない自己」(unknown self) もあると考えられる。

これらを障子の格子のように図解し、格子をその四角の枠に固定されていないものとして、格子のみ移動しながら考えると、誰にも知られていない自己が小さくなれば、それはフィードバックされているという事であるし、公開された自己が大きくなれば、それは自己開示が進んでいるととる事が出来るだろう。

Wikipedia より引用

実際に実施した際には

  1. ホワイトボードに枠を作っておく
  2. 各々上記の質問を書いておく(まだ貼らない)
  3. 一人ずつみんなに説明しながら貼っていく
  4. 最後に発表しているその人に期待することをみんなが説明しながら貼っていく

というスタイルで行いました。

参加したメンバーの感想はこちらです

相手が得意だと思っていること,バリューを発揮しようとしていることと,周りが期待していることのギャップを認識できると,作業を分担するときのコミュニケーションの取り方により気を遣うことができるので重要だと思った
やっぱり個々人何が得意だと思っているのか自分の言葉で説明を聞けて面白い
自分が武器だと思っているもの、自分が大切に思っていることを周囲に無理なく伝えられるのでとても良い
 

16personalities

画像引用元:https://www.16personalities.com/country-profiles/japan

 

www.16personalities.com

いわゆる性格診断です。

深い自己開示や期待のすりあわせにはつながりませんが、時間をかけずにパッとできるのでお手軽に出来ます。
どちらかと言うとこれを実施し、共有したあとのコミュニケーションに役立てそうです。

各自上記のウェブサイトで答えてそれをSlackで共有するという形で実施しました。

参加した人の感想はこちらです

楽しいし,自分で読んでて当たっていると思う
とても細かくて正確なんだろうけれど,ちょっと長いので結局チームの他の人のパーソナリティを記憶できてない
個々人が勝手にできるので、会社全体など大きい枠組みでやると効果的かも。話をしたことのない人に対して「論理型なんですね、僕も論理型なんですよ」などといったコミュニケーションの糸口に使えそう

自己紹介LT大会

今年の2月にホさんが加入したため、自己紹介を兼ねてLT大会をしました。
単純に5分くらいで自分紹介するLT大会をしたというだけです。
各々の個性が出るようにフォーマットは特に指定しなかったところ
甲斐(@MeguruKai)の見たことないクオリティの宣材写真が出てきたり藤井(@yutafujii)が全編に渡りジントニックの作り方に終始したりとツッコミどころにあふれる会になりました。
とても楽しかったです。

ちなみに私の発表資料はこちら。

参加したみんなの感想はこちらです。

仕事以外の分野の話をたくさん聞けて、純粋に楽しかった。大切にしている価値観や、考え方に大きな影響を与えた経験など、広く人生に関わる話は、なかなか普段の中で聞くことができない。
自己紹介とはいえ、型式に囚われず様々な角度で発表していたので非常に面白かったです。個人的には発表のフォーマットを決めてなかったフランクな取り組みが良いと思っていて、発表内容のピックアップや進め方も含め、自己紹介になっていた気がします。また、純粋にチームメンバーを違う側面をみることができなたので、メンバー個人への興味もあがりましたねー
フォーマットと内容が自由だったことで,その部分にも個性が出た気がしており,初めて開催したからこその面白さがあった気がする。結果的には詳細まで記憶できないけれど、その人その人にキーワードが結び付けられるだけでもとても有意義だったと思う
自己紹介を改めてするというのは良いですね。会社にジョインしたタイミングが違うので、日が浅い人にとっても知るきっかけが出来ますし、逆に「今まで言ってなかったけど伝えておきたい」みたいなことも改めて伝えられるので、チームビルディングによいなと思いました!

webox values card

画像引用元:https://wevox.io/valuescard

 

井原(@tossy_yukky)が買って持ってきたので実施しました。

 

wevox.io

カードに「友情」「愛」「本能的」など価値観にまつわるカードが書かれており、それを引いたり捨てたりすることで自分自身の価値観を表す5つのカードを集めるというゲームです。

やり方としては以下の通り

  1. カードを切り、1人5枚ずつ配る
  2. 残ったカードは全て伏せた状態で中央に置く
  3. カードを引く順番を決める
  4. 順番になったら「山」または「テーブルの上」にあるカードから1枚カードを引く
  5. 手元にあるカードの中から自分の価値観に一番遠いカードを捨てる
  6. 次の人に進み、カードの山がなくなるまで4〜5を繰り返す
  7. 残った5枚のカードを使い、自分の価値観を参加者に説明する

ルールブックより引用

5人くらいが適正な人数かなと思い、うちでは2回に分けて実施しました。
一度目はシンプルに上に書かれたルール通り実施し、二回目は「誰がどんな価値観を捨てたかが面白い」ということに気付き、麻雀のように自分が捨てたカードは自分の前においていくようにしました。

 

個人的に面白かったのが藤井が「愛」と「友情」と「幸せ」を捨てて、最後に残った手札に「遊び心」が入っていたことと
竹内(@manbo34)がCTOの戸村(@KenjiTomura)の目の前で「計画」「努力」「勝利」をバンバン捨てていたことです。

楽しみ方ですが捨てる時に捨てるカードを宣言すること(e.g. 私は家族を捨てます)と、それに対して周りがやいのやいの言うと盛り上がります。

参加したみんなの感想はこちらです。

カードきれい,楽しい
5枚に絞るのが難しく,重要なもののなかで優先度をつけるのでそこに価値観が現れて興味深いし自分の思考整理にもなった
プレイ中に相手が捨てるカードを見て、強く相手に興味を湧いた記憶があります。愛(家族?)や幸せを捨てる人の残しているカードは何なんだとw中だるみせず、最後の結果確認まで楽しかったです。」
似ているがニュアンスが異なる言葉が出てくるので、自分の価値観表現として、この言葉が本当にベストか考えるキッカケになりました。

無礼講ースター

画像引用元:https://yonasato.com/column/teambeerding_bureiko/

よなよなエールで有名なヤッホブルーイングが出している(いた)チームビルディング用、ビアコースターです。
ビアコースターなので対面での飲みの場での使用を想定されていますが、リモート飲みでも、飲みの場じゃなくても使用可能です。

ルール

  1. 親はテーマコースターの山札から1枚引き、読み上げます
  2. 親はお題にYES,NOコースターで答えます。回答が見えないようにビアグラスで隠します。
  3. 親以外のプレイヤーは親の回答を予想し、YES,NOコースターで答えます。これもビアグラスで隠します。(親にガンガン質問してもOK)
  4. 親以外のプレイヤーが一斉に回答をOPEN!時計回りに自分の回答理由を話します。
  5. みんなが話し終わったら、今度は親がYES/NOコースターをオープン!
  6. 親は自分の理由に一番近い回答者に、テーマコースターをプレゼント。

これを親役が一周するまで繰り返し、コースターの枚数が一番多い人の勝ち!

https://yonasato.com/ec/product/burei_coaster/より引用

このコースターはみんながそれぞれその人に対する印象を述べるっていうのが自己開示だけではなく他人から見た自分を教えてもらえるというのが良いですね。
これもジョハリの窓で言うと、秘密の窓の開放だけではなく、盲点の窓の開放が含まれています。

現在は販売がされていないみたいなので、もしやりたかったら周りの人で持っている人を探してやりましょう。
それか私に声かけてもらえればやりますのでお気軽にお声がけください。

感想です。

意外な嗜好性がわかる。絶対この人はこう!って思ってたのに実はそうでもなかった。ずぼらだと思ってたのに意外とマメだったり
フォースタ祭りの打ち上げで使いました!10人くらい人数がいる中でも、全員が参加でき会話しつづけられるコンテンツだった気がします!
(これはかなり前に全社イベントで使用された時の感想ですね。私の入社前)

以上で紹介は終わりです。

世の中にはこれ以外にもたくさんチームビルディングの手法がありますので、これからも色々と探してやってみようと思います。

あ、そうそうフォースタでは良いチームで良いプロダクトを作りたいエンジニアを募集しています。
是非ご興味あれば下のフォームから応募してみて下さい!

【フォースタ テックブログ】検索におけるユーザーのニーズに合わせてElasticsearchをチューニングした話

こんにちは、主にサーバーサイドを担当している速水です。

社内向けプロダクト「タレントエージェンシー支援システム(SFA/CRM)」では、検索エンジンとしてElasticsearchを採用しており、最近、検索機能の大きな改善を行いました。今回はそれに伴って、Elasticsearchに関するTIPSを紹介していきたいと思います。

タレントエージェンシー支援システム(SFA/CRM)とは

tech.forstartups.com

タレントエージェンシー支援システム(SFA/CRM)は、RailsAPIサーバーとして機能し、Vueでフロントを構成する設計となっています。一部、erbで記述された部分もありますが、直近手を入れている機能については、APIを介してフロント分離をしっかり行っております。この記事では、RailsAPI開発におけるElasticsearchに関する部分を紹介します。

データ型の見直し(Text型→Keyword型)

Elasticsearchで文字列を扱う場合、Text型またはKeyword型、どちらかを使用すると思います。Text型とKeyword型の違いは、データを格納する際に、Analyzerによって単語に分割され、分割された単語ごとにインデックスが構成されるかどうかですが、これまで使用していたText型では、分割によって検索結果が曖昧になりすぎ、困るシーンがありました。例えば、「Rubyエンジニア」を検索した際に、「Ruby」と「エンジニア」に分解されてしまうことで、Ruby以外のエンジニアもヒットしてしまう、といった状況です。

そういった分割をせずに格納、検索するために、データ型をText型からKeyword型に変更し、検索ワードが"完全一致"したらヒットするようにしました。

indexes :all_resume_contents, type: 'text', analyzer: 'kuromoji_analyzer'
indexes :all_resume_contents, type: 'keyword'

検索結果でのハイライトの実現

検索結果でヒットした箇所のハイライトを行うため、options[:set_highlight]を指定することで、highlightが返却されるようにしました。

filters = @search_definition[:query][:bool][:filter]
...
...(filters.pushやset_sort_query)
...
set_highlight if options[:set_highlight]
__elasticsearch__.search(@search_definition)


def set_highlight
  @search_definition[:highlight] = {
    fields: {
      "**": {}
    }
  }
end

Elasticsearchのhighlightは、wildcardを利用すると全文が返ってくるため、ハイライトを中心に前後40文字と...(省略記号)の形式に、APIを生成する際に加工しました。

copy_toによる検索対象フィールドの集約と返却フィールド

Elasticsearchではcopy_toという機能で、検索対象フィールドをまとめることができます。検索対象のフィールドを少なくすることで、検索スピード向上が期待できます。
もともとresumeというインデックスは、Nested datatypeを使っていました。all_resume_contents単体で検索するより、file_idやnameなどをまとめて検索した方が効率が良いため、copy_toでall_resume_contentsを指定します。

ただ、開発を進めていたところ、all_resume_contentsでヒットした際に、そのフィールドが返却されないことに気付きました。調べていくと、copy_toはあくまでindexed documentであり、source documentではないようです。検索にヒットした際のフィールドや値を使用したい場合は、storeオプションをつける必要がありました。

indexes :all_resume_contents, type: 'keyword', store: true
indexes :resume, type: 'nested' do
  indexes :id, type: 'integer'
  indexes :file_id, type: 'keyword'
  indexes :name, type: 'keyword'
  indexes :content, type: 'keyword', copy_to: 'all_resume_contents', index: false

case-insensitiveの対応

大文字と小文字を区別しないことを、ケース・インセンシティブ(case-insensitive)と言います。今回、データ型の見直しを行ったことで、Rubyrubyや、HTMLとhtmlの検索結果が異なる、ということが発生してしまいました。Text型の時はAnalyzerで吸収されていた部分ですが、Keyword型に変更したことで発生しました。Keyword型ではAnalyzerが使えないので、代わりにNormalizerを使用します。

www.elastic.co

Normalizerには、char_filterとfilterを定義することができ、今回は大文字と小文字を区別しないようにするため、filterでlowercasesを指定しました。Normalizerはインデックス、検索時の入力、どちらにも適用されます。

indexes :memo, type: 'keyword', normalizer: 'lowercase_normalizer'

analyzer: {
            kuromoji_analyzer: {
              type: 'custom',
              tokenizer: 'kuromoji_tokenizer',
              filter: %w[kuromoji_baseform pos_filter greek_lowercase_filter cjk_width]
            },
            ngram_analyzer: {
              tokenizer: 'ngram_tokenizer'
            }
          },
          normalizer: {
            lowercase_normalizer: {
              type: 'custom',
              char_filter: [],
              filter: ['lowercase']
            }
          }

いかがでしたでしょうか。シーンはかなり限られるかもしれませんが(笑)、Elasticsearchを使った検索機能の開発をするときの参考になればと思います。

今回の検索機能の改善は、フロント、バックエンドそれぞれ細かくタスクを分解し、チームが一丸となって取り組んだものでした。いざ結合して検索してみると、想定と異なる結果が表示されることもありましたが、上記のような解決法を取りながら、1つ1つ対応して完成した機能は、まさにチームでつくりあげたと言えます。

フォースタートアップスではエンジニアを募集中です。チームで協働するスタイルが向いている方は、是非ご応募ください!

【フォースタ テックブログ】社内で実践中!ふりかえりを続けるためのコツ

どうもむらばやし(@bayashimura)です。皆さん「ふりかえり」してますか?ふりかえり挫折しますよね?今回は挫折しがちなふりかえりを続けるためのコツを書いていきます。

この記事は技術書典10で発売された『forstartups tech book 1』のふりかえり再入門から抜粋、一部加筆しております

techbookfest.org

まだみんな前のめりじゃない時にファシリテータを交代制にしない

ファシリテータを一人がやり続けることは、大抵の場合アンチパターンとして捉えられがちです。私もふりかえりのファシリテータがずっと固定されていることには否定的です。しかし物事を新しく始める時に誰か一人、それも情熱を持っている人が引っ張っていくのは大事なことです。

早期にファシリテータを交代制にすることは、ふりかえりにモチベーションもオーナーシップもない人間がファシリテータをやらされることに繋がります。その結果ふりかえりのクオリティは下がったり、もしかしたら開催されないかもしれません。

ふりかえりをこれから始める方、途絶してしまっていたけど再びやろうとしている方はまずあなたが続けるところから始めましょう。あなたが会議を設定し、あなたがチームメンバーを呼び寄せ、あなたがファシリテーションして、あなたがメンバーからのフィードバックをもらいましょう。そういった日々を積み重ね、チームがふりかえりに前のめりになってきた時に初めてファシリテータを譲りましょう。それまではファシリテータを交代制にするのはおすすめしません。

一定のリズムで行う

先に時間を押さえましょう。もしスクラム開発をしているのであれば、スプリントの最後の時間などがいいかもしれません。そうではない方々も、1週間に1回や2週間に1回などの固定の時間を取りましょう。すぐ埋まる会議室を押さえ多忙なチームメンバーのスケジュールを押さえるのにこれだけ簡単な方法はありません。

誰かが思いついた時や開発の節目など固定でないタイミングで行うことは、ふりかえりを開催するハードルを上げます。開催の日時に融通が聞かせられてしまうため、全員が参加できるタイミングをファシリテータが調整する羽目になり労力がかかります。ファシリテータがスケジュールを調整するのではなく、参加者がスケジュールを調整する方向に仕向けることで負荷が分散し継続して開催される可能性が高くなります。

色々なふりかえり手法を試してみる

ふりかえりの種類はたくさんあります。またその性質もそれぞれ違います。チームをポジティブにするふりかえり。チームの問題を発見するふりかえり。チームの目線を合わせるふりかえり。色々なふりかえりを試すことで、チームはふりかえりの多様性を実感します。そうなると次のふりかえりを試したくなり、チームはふりかえりに前のめりになります。そのうちチームメンバーが新しいふりかえり手法を提案してくるかもしれません。もうふりかえりはチームに浸透しましたね。

厳しさより楽しさを重視する

ふりかえりは、その性質上、チームに発生した目を向けたくないような事実に目を向けます。そのため反省会や責任の押し付け合いみたいになりがちで、ふりかえりが嫌な行事に思えてきます。
またふりかえりは「チームの悪いところを直す」という方向に向きがちですが、過度な解決思考は良く言えばチームの規律を正しますが、悪く言えば息苦しく高圧的な雰囲気を生みます。

ふりかえりでチームのマインドをポジティブな方向に仕向けましょう。「このチームの凄いところはどこですか? 」「このスプリントのヒーローは?」 褒められて嫌な人はいません。気恥ずかしいし、自己啓発臭くて嫌かもしれませんが一度やってみましょう。

ネガティブなフィードバックの倍のポジティブなフィードバックを言いましょう。面白いジョークを言いましょう(面白くないのはダメです)。ダメダメな自分たちがちょっとでもマシになるためのアイディアではなくグレートな自分たちが更にグレートになるためには何をしたらいいかを考えましょう。そうすることでチームはポジティブになり、ふりかえりの場が盛り上がります。もうふりかえりを楽しみに一週間を過ごすチームの出来上がりです。

ふりかえりをふりかえる

ふりかえりをしていると白熱して時間を使い切ってしまいがちですが、最後に5分くらい残しておきましょう。そこでふりかえり自体をふりかえることをおすすめします。

何故『ふりかえりをふりかえる』ことで『ふりかえりが継続できる』かというと、ふりかえりを推進している人は孤独で不安です。まだチームにふりかえりが定着していない時などは尚更です。みんなの貴重な時間を使ってふりかえりが盛り上がらない時、次のふりかえりを設定することはみんな の邪魔になるんじゃないかという思いがよぎります。

そんなときは何が必要でしょうか。フィードバックです。参加者は顔に表しませんが、とても有意義だったと思っているかもしれません。ふりかえりのふりかえりで参加者がどう思っていたかを 引き出します。フィードバックを貰えれば後に繋げるのは簡単です。良いフィードバックを貰えれ ば続ければいいし、良くないフィードバックが集まればやり方を変えましょう。どう変えればいいかもフィードバックの内容に含まれているはずです。

ふりかえりが毎回盛り上がりすぎて時間がない場合(タイムマネジメント頑張って!)は、会議室の出口に楽しさと 役立ち度合いの2軸のグラフを作りそこに一言とともに付箋紙を貼ってもらう方法があります。また会議が終わったあとに、slack でコメントを求めてもいいでしょう。どんな方法でも良いです。 フィードバックをもらいましょう。それがふりかえりをすすめる人の活力になります。

早いうちにふりかえりの効果をチームに実感してもらう

チームを巻き込む以上、そしてチームが合理的な時間の使い方を求める以上、あまり効果が感じられない会議体は自然となくなっていきます。つまり、ふりかえりを継続する上で大事なことは「チームのみんなにふりかえりの効果を実感してもらう」ことになります。早いうちにふりかえりの効果をチームに実感してもらいましょう。

もしあなたがふりかえりのファシリテートに自信がない場合は、時間をとってしっかりと準備をしましょう。もしくは近くにふりかえりのファシリテートに長けている人がいれば最初のうちはその人にお願いしましょう。これは身も蓋もない言い方になってしまいますが、ふりかえりの価値を知らないチームメイトはあなたの成長を待ってはくれません。最初のうちは持続的なやり方でなくても良いので、まず価値を感じてもらい、そこからチームメイトと一緒に歩んでいくのがオススメです。

 

今回はふりかえりを続けるコツについて書きました。
先月発売した技術書典の同人誌の方ではふりかえりの型などに関しても書いているため、ご興味があれば是非読んでみてください!

また、フォースタートアップスではエンジニアを募集中です!
ふりかえりをして成長していくチームで働きたい方は是非ご応募ください!

【フォースタ テックブログ】Regional Scrum Gathering℠ Tokyo 2021で配信スタッフとして参加してきました

Copyright 2020, ScrumTokyo. All rights reserved

どうも村林です。
Regional Scrum Gathering Tokyo 2021(以下、RSGT)に配信担当としてスタッフをしてきたので感想書きます。

Regional Scrum Gathering Tokyo 2021とは

Regional Scrum Gathering℠ Tokyo 2021は、東京で行われるRegional Gatheringとして10回目になります。運営母体である一般社団法人スクラムギャザリング東京実行委員会は、スクラムを実践する人が集い垣根を超えて語り合う場を提供するという目的によりコミットしています。

アジャイル初学者からその道の達人までいろんな人達が集まってギャザリングするイベントです。
今年は新型コロナウィルスの影響もあり、オンラインの人もオンサイトの人もギャザリングできるようハイブリッド開催でした。

ハイブリッド開催とは話す人も聞く人も会場かオンラインかを好きに選べるってことです。また会場の人はオンサイトの人の発表しか聞けないなどの制約もなく、会場でオンラインの人の発表を聞く、オンラインの人が会場の発表を聞く、なんなら一緒にOST(Open Space Technology)とかしちゃう。みたいな感じでした。

この要件を満たすために、会場とオンラインの人を双方向に繋ぐということが必要でした。そこらへんをどうにかするべく色々やったのが配信担当です。私は品川アジャイルという品川にまつわる人やまつわらない人が日夜集まってアジャイルの話をするコミュニティに属しているご縁で担当しました。

配信構成

全体像はこちらです

多分これだとなんのこっちゃという話だと思うのでユースケース毎に解説していきます。

まず会場にいる人の発表をオンラインで聞くケースを考えます。

会場のマイク音声はもちろん会場に流さないといけないので、会場の音響設備につなぎます。そして会場の音響設備から分配し、配信用PCに入れます。配信用PCはZoomに接続していて、受け取った音声をZoom側に流します。
これで音声は良さそうです。

次は映像ですが、映像に関しては発表資料と講演者の姿の2つの画面があります。
発表資料は講演者が会場のプロジェクタに接続し、またその画面をZoomで画面共有してもらうことで会場にもZoomにも発表資料を共有することができます。
講演者の姿に関してはカメラで撮影したものを配信用PCに入れ、そこからZoomに出力します。
これでZoomでも講演者の発表スライド、発表姿、音声が全部Zoomに届きますね。
PinP(映像の中に映像をはめ込む)なども考えたのですが、RSGTの参加者のペルソナを考えたときにこちらで映像を組み合わせた状態で渡すより、そのまま渡して参加者の方で勝手に組み合わせられるようにした方が満足度が高いかなということでやめました。幸いZoomは複数の映像のレイアウトを柔軟に変えられますし。Zoom凄い。

次に会場の発表に対してオンラインの人が質問してくるケースを考えます。

講演者が聞くためにZoomからの音声を会場に流す必要があります。
これは配信用PCが受けたZoomの音声を会場の音響設備に流すことで対応できます。

次はオンラインの発表を会場に流すケースです。

基本はオンラインの人が質問してくるケースと同じです。
ただし一点違うのは講演者が会場にいないので、会場のプロジェクターに接続するPCがありません。
これは運営で借りたPCを投影用PCとして置くことで対応しました。
この投影用PCでZoomに接続し、会場のプロジェクタに流すだけで映像はOKです。

最後にオンラインの発表に対して会場の人が質問をするケースです。

これも会場の発表と同じですね。
会場のマイクを使って質問してもらうと、配信用PCを通ってZoomの先にいる発表者の人に伝わります。注意なのが、マイクの音声しか拾っていないのでマイクに向かって話さないと聞こえないことです。

素人でも積み重ねてできた

いかがでしたでしょうか。よくわかりませんね。

実は我々は映像や音声に関して素人だったのですが、ちょっとずつできることを積み重ねていき、こんな最初はよくわからない構成でもある程度できるようになりました。
最初から色んなことをやろうとしない、基本が安定してできるようになると次のステップアップもそんな負荷なくいける。そのステップアップも当たり前にやりだすと、次のステップアップをする。こんな感じでできることを積み上げてできたのが今の構成です。
なので詳しくなってきたらもうちょっと複雑か高度な構成になるかもです。それかよりシンプルになるかも。未来は誰にもわからない。

あと初期案はRSGT実行委員長で品川アジャイルのメンバーでもある川口恭伸さんが考えてくださったのですが、川口さんがこの構成を考えたときに留意した点は以下の通りだそうです。

  1. 登壇者にとって最小変更
  2. その変更点も慣れているZoom対応のみ
  3. 映像系は登壇者、音声系は会場設備(ハウリング対策)
  4. どのPCがこけても全落ちしない(ある程度は相互にリカバーできる)
  5. ネットがこけても平然と会場は進行できる(ハイブリッドなのだけど、実績ある部分を優先)
  6. リモート参加者/講演者に追加のオペレーションを求めない(説明しきれない)
  7. 会場に複雑な機材を入れない(PC中心)
  8. 運用者はみんなプロじゃなくて参加者に近いコミュニティメンバーなので、習熟の時間をとる(お金を人件費より教育研修費で使いたい)
  9. ホールは別に業者さんにお願いすることでリスクヘッジ (ただこの構成は踏襲していただくことでコストは下げる)

大規模なイベントを継続してやってきた川口さんのノウハウが詰まってますね。
新しく発生するリスクに対してはできるだけ冗長化する。
慣れているものでやるのが一番安定してできる、という思想があるような気がします。

得た学び

留意した点の8番に関しては私は恩恵に与かりました。
何をしたかと言うとわざわざ本番の二週間前くらいにカメラを機材レンタル屋さんから借り、その他機材も家に持ち帰り、年末年始にお家で配信設備の構成を試して遊んでました。
そこでようやくぼんやりしていた配信構成が解像度高く自分の中に入りました。
「こうすれば動くらしい」から「これはこういう仕組みだから動く」って感じですね。
仕組みがわかったことで当日昼休みのときに会場に何も流れてなかったのが寂しくてDiscordの映像を会場に流したり、機材トラブルがあった際に土壇場で違う構成で乗り切ったりすることができました。
基本をしっかりするから応用ができるという学びです。

またスタッフ内で印象的だったのが「疲れない、頑張らない」を大事にしていたことでした。大体のイベントでは「燃えつきろ!一生懸命だろ!!」って方向に行きがちなんですがイベントスタッフって頑張っちゃうんですよね。勝手に。
だってみんなに楽しんでもらいたいし、やりがいもあるし。スタッフが追加で動かなきゃいけないときって大体誰かが困っているときだし。
で、頑張ると燃え尽きて、来年からはちょっと出来ないなぁとスタッフがどんどん離脱してイベントの持続可能性が減ってしまう。
営利団体でもないことも相まっていつでも辞められるから、辞めないように工夫する。
スタッフが楽しくて疲れないのが第一。そうすると来年も開かれる。

という思想があるのかなーと思いました。
コミュニティを持続的にしていきたい人は参考になるかもです。

おわりに

ということで、配信スタッフとしてRSGTに参加してきた話でした。

最後に実行委員、スタッフ、発表者、参加者の皆さんお疲れさまでした!
また来年お会いしましょう!

あ、あとフォースタートアップスではRSGTと聞いてピンとくるアジャイルに興味のあるエンジニアを募集中です。
プロダクトに向き合ってより良くあろうとするチームで働きたい場合は是非ご連絡ください!