当日ヘルパーから見た RubyKaigi 2022

三重県津市で開催されたRubyKaigi 2022に参加してきました。

今回はじめて、当日の運営のお手伝い(ヘルパー)として参加したので、その視点で記録しておきます。

開催前

まずはヘルパーとして参加することにした経緯から。

RubyKaigi公式Twitterアカウントでヘルパーの公募がありました。

応募するきっかけがもう一歩なくてどうしようかな〜と迷っていたところ、

会社のSlackで同僚が「ヘルパーに応募しようか迷っています」と言っているのを見かけて

「迷っているなら一緒に応募しませんか!?」という謎のムーブ(自分も迷ってたくせに)を繰り出し、応募することにしました。

結果的に自分で自分の背中を押したというか、自分を客観視したのかな?という気がします。 「迷ってるならやれば良さそう」と思えて、あ、これは自分自身にこの言葉をかけてあげればよかったんだなぁと気づいたというか。

応募後、8月中旬にオーガナイザーの @a_matsuda さんからメールをいただき、正式にヘルパーとしての参加が決まりました。

運営チームのSlackチャンネルに参加し、わいわい始まりました。

開催前にSlackチャンネルでやったことは

  • Staffチケットの受け取り
    • すでにチケットを購入済みの場合はチケット種別の変更と返金
  • 名前やSNSアカウントの報告(サイト掲載用)
  • 運営資料の受け取り
  • そのほか細かい質問など

くらいですかね。About - RubyKaigi 2022 に掲載していただいたの、結構嬉しいです。

開催中

開催1日目の始発電車で東京から三重に向かい、津市の会場に到着したのは10時前でした。

運営チームメンバーのほとんどは前日(あるいはそれ以上前)に会場近辺に集まっており、当日は朝8時から集まって諸々の準備を始めていたので、自分が到着したころには運営真っ最中で、受付にてお手間を取らせてしまいました(一般チケットに紛れてStaffチケットの人が来た!みたいな)。

もしまたヘルパーをやるときには、なるべく前日入りできるように調整するか、遅れて参加する場合には業務に合流する流れを事前に決めておけると良さそうですね。

その後、オーガナイザーの @spring_aki さんにいろいろレクチャーいただいて、ヘルパー業務に合流しました。

自分の主な業務は、①ノベルティブースでノベルティの配布、②大ホールの扉の開閉、③昼食の弁当配布時の人の流れの整備、④そのほか気づいたことや呼ばれたお仕事、でした。担当を決められていたわけではないので、やれそうな仕事を拾っていったらこうなった、という感じです。

お仕事内容は2日目と3日目も大きく変わらず、昼間そんなに忙しいってこともなかったので、合間を見てセッションを聴講していました。手元の聴講メモを見ると、途中から聞いたり途中で抜けたりしたものを含めて12のセッションを聴講できたようです。

またノベルティブースでは、ペパボもお世話になっているフィヨルド@komagata さん、@machida さんとおしゃべりしたり、@swan_match さん(魔王)にキーボードを見せてもらったりしました。

全体を通してめちゃくちゃ忙しいということはなかったですが、3日目の夜のホール撤収作業は結構疲れました。大ホールと中ホールの廃棄品を回収してゴミ捨て場へのルートを何度も往復するのは汗だくになりました。ヘルスケアアプリでこの日の歩数を見てみると24,000歩でした。なかなかよく歩きましたね〜。

ヘルパーとして参加することで、RubyKaigiの裏側を垣間見ることができました。

ヘルパーを含む運営チームメンバーはみなトランシーバーをつけており、これを使って状況報告、相談、依頼などを行ないます。

トランシーバーには終日さまざまな情報が飛び交い、各メンバーがいくつもの課題を解決しているようすや、いくつもの提案をして行動しているようすを窺い知ることができました。(もちろん自分もいくつかのアクションをしました。決して多くはないですが)

そのようすを聞いていると「ああ、これまでのRubyKaigiも毎回こういうふうにして運営されてきたんだなぁ」と感じ、心の底から「うお〜〜〜感謝〜〜〜〜〜」みたいな気持ちが湧き上がってきました。興味のある方はぜひヘルパーに応募してみてください。オススメです。

開催期間中の反省点として「オンライン参加者の視点をあまり意識していなかった」点が挙げられるかなと思います。

RubyKaigi 2022は現地とオンラインのハイブリッド開催で、オンライン参加の方もかなりたくさんいました。にもかかわらず、2日目の通信トラブルの際に「オンライン参加者に向けたアナウンスが乏しかった」という気づきがありました(2日目終了時の運営集会にて)

「オンライン参加者の視点でいまRubyKaigiがどのように見えているか」という思考を常に持っていれば、「こういう案内を出した方が良いかも」という提案ができたかもしれないなと悔やまれます。

こういった反省を踏まえて、次回以降のRubyKaigiをもっと良くしていけると良いですね。

開催後

開催後はヘルパーとしての業務は特にないですが、Slackの運営チャンネルで知ったようすを紹介します。

オーガナイザーの一部の方は、翌日以降も引き続き会場に足を運んで備品の整備やスポンサーブースの備品を各社に送付する手続きなどを行なっていたようです。本当にお疲れさまです、ありがとうございます。

Slackチャンネルでは、集合写真の共有や、次回のRubyKaigiに向けたエモい話などが行なわれていました。

次回は長野県松本市ですね。楽しみです。

まとめ

当日ヘルパーから見た RubyKaigi 2022 について書いてみました。

自分はいつもRubyを使わせてもらっていてお世話になりっぱなしなので、少しでも何かできたらなぁという想いがありました。

その「何か」のひとつとして、今回ヘルパーとして参加することにしたのですが、結局、自分が貢献した何かよりもRubyKaigiからもらったモノの方がたくさんあって、またお世話になっちゃったぜ〜という感じですね。

ますます何かやっていきたくなりました。ありがとうRubyKaigi、また会いましょう。

ゲーム収録環境をつくった 〜みんなで実況編〜【LadioCast, BlackHole】

ゲーム収録環境をつくった 〜ひとり実況編〜【M1 MacBook Air, OBS Studio】 - tanaken’s blog の続編です。

今回の記事では「みんなで実況編」と題して、次の要件をすべて満たす構成については紹介します。

  • ゲーム端末の映像を録画できる
  • ゲーム端末の音声を録音できる
  • 自分の声を録音できる
  • ゲームを遅延なくプレイできる
  • 音声通話アプリの音声(=友人の声)を録音できる (New!)

結論(構成図)

はじめに「結論こうなりました!」という図を示します。図の元データはGitHubで管理しています。

電源供給

前回の記事と同様なので割愛します。

操作入力と映像出力

前回の記事と同様なので割愛します。

音声入出力

登場人物

前回の記事との差分は太字で示します。

人間

  • 自分(手、目、声、耳)
  • インターネットの向こう側の友人たち(声、耳)

ハードウェア

ソフトウェア

前提知識

今回の収録で新たに利用する「仮想オーディオデバイス」と「仮想オーディオミキサー」について説明します。

仮想オーディオデバイス

音声入出力装置をPC内に仮想的につくるソフトウェアです。音声を仮想のスピーカーに出力したり、仮想のマイクで音声を受け取ったりできるようになります。

この仮想オーディオデバイスは、音声通話アプリからの出力音声を収録ソフトウェア(OBS Studio)で収録するために必須です。

そもそもPCは、基本的には出力音声を自身への入力として受け付けることはできないようになっています。これは、出力音声と入力音声が無限ループする状態を避けるためです。

今回利用するOBS Studioには「音声出力キャプチャ」機能がありますが、これも物理オーディオデバイス(PC本体の内蔵スピーカーやイヤホン)への出力音声を収録することはできません。(設定の選択肢に出てきません)

この仕様を掻い潜って音声通話アプリからの出力音声を収録するために、その出力音声をいったん仮想オーディオデバイスで受け取ります。

OBS Studioの「音声出力キャプチャ」機能は、仮想オーディオデバイスであれば選択できるようになっているため、先ほど音声通話アプリの音を受け取った仮想オーディオデバイスを設定することで、その音声を収録することができるようになります。

仮想オーディオデバイスは、macOSではSoundflowerBlackHoleが有名です。この2つのうち、M1で使えるのはBlackHoleなので自分はこれを使っています。

サイトの手順に従って、BlackHoleの2chをインストールしておいてください。

仮想オーディオミキサー

PC内の音声入出力装置について「複数の入力音声を単一の出力装置に出力する」「単一の入力音声を複数の出力装置に出力する」といった操作ができるソフトウェアです。

仮想オーディオデバイスと組みわせて利用することで、音声を自由度高く取り扱うことができます。

今回は、仮想オーディオデバイスで受け取った音声通話アプリの出力音声を、物理デバイスであるイヤホンに流し込むために、このソフトウェアを使用します。

自分はLadioCastを利用しています。

環境構築

では、収録環境をつくっていきましょう。

基本的には前回の記事と同様なので、前回つくった「シーン」を複製して新しい「シーン」をつくると手間が少ないと思います。 「ひとりで収録」を右クリックすると、画像のように「複製」ができるのでクリックします。新しいシーンの名前は「みんなで収録」と名付けました。

電源供給

前回の記事と同様なので割愛します。

操作入力と映像出力

前回の記事と同様なので割愛します。

音声入出力

まず、

  • 自分の声が外部マイク(Blue Yeti)を経由してOBS Studioに収録される
  • Switchの音声がゲームキャプチャーデバイス(HD60 S+)を経由してOBS Studioに収録される
  • Switchの音声が外部ディスプレイを経由して自分の耳に届く

という構成は前回と同様です。

前回と違うのは

  • 自分の声が音声通話アプリを経由して友人たちの耳に届く
  • 友人たちの声が音声通話アプリを経由してOBS Studioに収録される
  • 友人たちの声が音声通話アプリを経由してイヤホン(自分の耳)に届く

という部分ですね。では、それぞれ設定していきましょう。

まずは音声通話アプリを開いてください。(今回の例ではGoogle Meetを扱います) 音声通話アプリには音声の入出力に関する設定があるはずなので、それを開きます。

音声通話アプリの入力装置に、今回使用する外部マイク(Blue Yeti)を指定します。これで「自分の声が音声通話アプリを経由して友人たちの耳に届く」はクリアです。

続いて、音声通話アプリの出力装置としてBlackHoleを指定します。(今回は「BlackHole 2ch」を指定します)

次にOBS Studioを開き、「ソース」のウィンドウで+ボタンから新しいソースを追加します。 今回は「音声出力キャプチャ」を選択し、「通話音声」と名付けましょう。

次の画面で「デバイス」を選択できるので、「BlackHole 2ch」を選択しましょう。

ここまでで「友人たちの声が音声通話アプリを経由してOBS Studioに収録される」がクリアです!

ただしこのままでは、友人たちの声が自分のイヤホンに届きません。

ここでLadioCastを開き、「BlackHole 2ch」に流れている友人たちの会話がイヤホン(Aeropex)に届くように設定します。 具体的には「入力1」に「BlackHole 2ch」を指定してその下の[メイン]ボタンをアクティブにし、「出力メイン」に「Aeropex」を指定します。

これで「友人たちの声が音声通話アプリを経由してイヤホン(自分の耳)に届く」クリアです!

設定は以上です!「ゲーム音声」「マイク」「通話音声」の大きさのバランスは「音声ミキサー」ウィンドウのスライダーで適宜調整していただくと良いと思います。

※ 余談1. ちょっと物理的にズルしてます

骨伝導イヤホンであるAeropexを使うことで、物理的にちょっとズル(というか簡略化)しています。

というのも通常のイヤホンを使うと、通話音声(イヤホンに流れてくる)と外部ディスプレイの音声を同時に聴くことはできないですよね。骨伝導イヤホンで耳が開いているので、物理的に外部ディスプレイの音も聞こえる、という特性を利用しています。

通常のイヤホン(耳を塞ぐイヤホン)を使用する場合には、オーディオミキサー(物理)を購入して外部ディスプレイからの音声出力とPCからの音声出力をオーディオミキサーで統合し、その音声をイヤホンで聴く、という構成にすると良いと思います。

※ 余談2. OBS Studioからの音声出力

前回の記事ではPC本体の音声をミュートにすることでOBS Studioからの音声出力をなくする方針を採用していたのですが、今回は音声通話アプリからの音声を聞く必要があるのでそれはできませんでした。

この対応として当初はPC本体の音声出力をBlackHoleの適当なchに逃す(どこにも出力しない)という作戦を立てていたんですが、OBS Studioの設定をいくつかいじってみると「音声ミキサー」の「音声モニタリング設定」で「モニターOFF」にするだけでOBS Studioの音声出力は無くせる(収録ではちゃんと音声を拾えてる)ということがわかったので、一旦それで行ってみることにしました。

この辺はOBS Studioの挙動が把握しきれてない(というか「モニターOFF」= モニタリングしないって意味だろうから、収録で音声を拾えちゃうのはおかしいような気もする)ので都度様子を見ながら(動作確認をしながら)やっていくことになりそうです。

完「みんなで実況編」

この記事では音声通話アプリの声も同時に収録するための設定を紹介しました。

テスト動画も撮りました。

ただ、音声通話アプリ(Google Meet)の会話相手がいなかったので、

という状態をつくりました。

結果的に、iPhoneの向こう側のニュースキャスターと会話しながらゲーム収録をする羽目になりました。

youtu.be

楽しかったです。

ゲーム収録環境をつくった 〜ひとり実況編〜【M1 MacBook Air, OBS Studio】

ゲームを収録するための環境を構築したので紹介します。

構築するにあたって満たしたい要件は次のとおりでした。

  • ゲーム端末の映像を録画できる
  • ゲーム端末の音声を録音できる
  • 自分の声を録音できる
  • ゲームを遅延なくプレイできる
  • 音声通話アプリの音声(=友人の声)を録音できる

この記事では「ひとり実況編」と題して、4つ目までの要件を満たす構成について紹介します。

すべての要件を満たす構成については「みんなで実況編」と題して、次回の記事で紹介します!お楽しみに。

結論(構成図)

はじめに「結論こうなりました!」という図を示します。図はMermaidのフローチャートを使って書いてGitHubで管理しています。

電源供給

操作入力と映像出力

音声入出力

登場人物

人間

  • 自分(手、目、声、耳)

ハードウェア

ソフトウェア

前提知識

収録環境を構築する方法を調べる過程で知ったことがたくさんありました。前提知識として知っておくと役立つと思うので書いておきます。

ゲームキャプチャーデバイス

録画をPCで行なうためには、ゲーム端末の映像と音声をPCに受け渡す必要があります。そのための装置です。「キャプチャーボード」と呼ばれているケースも観測しました。

いろいろな種類や価格帯のゲームキャプチャーデバイスが販売されていますが、自分はすでに友人が使っていて評判の良かった「Elgato Game Capture HD60 S+」を購入しました。

収録ソフトウェア

PC端末が受け取った映像や音声を収録するためのソフトウェアです。

今回のケースだと、このソフトウェアを使って

  • ゲームキャプチャーデバイスを経由して受け取ったゲームの映像と音声
  • マイクを経由して受け取った自分の声

を収録して動画ファイルとして保存することになります。

自分は検索結果によく出てくる「OBS Studio」を利用しています。(ほかのソフトウェアもあると思いますが調べていません)

仮想オーディオデバイスと仮想オーディオミキサー

ゲーム収録について調べると、SoundflowerBlackHoleなどの「仮想オーディオデバイス」や、LadioCastなどの「仮想オーディオミキサー」についての記載が多くヒットします。

が、ひとりで収録する場合は「仮想オーディオデバイス」も「仮想オーディオミキサー」も必要ありません。

これらのソフトウェアは次回の記事「〜みんなで実況編〜」で使用しますので、そちらで詳しく説明します。

環境構築

では、実際に収録環境をつくっていきましょう。

電源供給

まずはゲーム端末(Switch)、外部ディスプレイ、PC(MacBook Air (M1, 2020))をそれぞれ電源に接続しましょう。

ゲームコントローラー(Proコン)は電池がなければSwitchに繋いで充電しましょう。

ゲームキャプチャーデバイス(HD60 S+)とマイク(Blue Yeti)はPCから給電する必要があるので、USBで接続しましょう。

操作入力と映像出力

SwitchからのHDMIケーブルをHD60 S+に接続し、HD60 S+からのHDMIケーブルを外部ディスプレイに接続します。

HD60 S+はUSB経由でPCから給電されているので、この時点でSwitchのゲーム映像が外部ディスプレイに表示されるはずです(直接Switchと外部ディスプレイを接続している状態とほとんど同じです)。

ここで、PCでOBS Studioを起動しましょう。次のような画面が表示されると思います。

左下の「シーン」のウィンドウで、+ボタンから新しいシーンを作成します。適当な名前をつけましょう。この例では「ひとりで収録」と名付けました。

その右の「ソース」のウィンドウで、+ボタンから新しいソースを追加します。 「映像キャプチャデバイス」を選択し、「ゲーム映像」と名付けましょう。

次の画面で「デバイス」を選択できるので、「Game Capture HD60 S+」を選択しましょう。

すると、いま外部ディスプレイに表示されているものと同じ映像がOBS Studioに表示されているはずです。

プリセットは1920x1080が良いと思います(あとで変更もできるのでご自身の環境に合わせて設定してください)。

ここまでで映像出力の設定は完了です!簡単ですね。

この時点でOBS Studioの右下の「コントロール」ウィンドウにある「録画開始」ボタンを押すと、ゲーム映像を録画することができます。ただし、ゲーム音声は含まれていません。音声に関する設定は次の節で説明します。

※ 録画フォーマットについて

OBS Studioの録画フォーマットは、初期設定だと mkv になっています。このフォーマットで録画しても再生できるソフトウェアを持っていない場合があると思います(自分はそうでした)。その場合は、「設定」> 「出力」で、録画フォーマットを変更しておきましょう。自分はQuikTime Playerで再生できる mp4 に変更しました。

音声入出力

続いて音声の設定をしていきます。

OBS Studioの中央下の「音声ミキサー」のウィンドウに(確かデフォルトで)「マイク」という記載があると思います。これはPCの環境設定で入力装置として設定されているマイクからの音声を収録できるようになっています。これは「設定」> 「出力」> 「グローバル音声デバイス」の「マイク音声」から変更できます。

最後にゲーム音声を収録できるようにしましょう。映像のときと同様に「ソース」のウィンドウで、+ボタンから新しいソースを追加します。 今回は「音声入力キャプチャ」を選択し、「ゲーム音声」と名付けましょう。

次の画面で「デバイス」を選択できるので、「Game Capture HD60 S+」を選択しましょう。

すると「音声ミキサー」のウィンドウに「ゲーム音声」の記載が追加されているはずです。ゲーム音声が大きすぎると自分の声をかき消してしまうので、カーソルを左に動かして小さめに設定すると良いでしょう。この例では -15 dB に設定しています。

以上で設定はおしまいです!最終的にはこんな画面になっていると思います。

遅延を気にせずにプレイするために

ここまで設定すると、外部ディスプレイに表示されている映像・音声からやや遅れて(0.x秒くらい遅れて)、OBS Studioに映像と音声が出力されることに気づくと思います。これはゲームキャプチャーデバイスによる変換(ゲーム端末からの出力として受け取った情報をPCへの入力に変換する処理)があるからでしょう(詳しくないけど)。

映像に関しては外部ディスプレイを見れば良いですが、音声は外部ディスプレイとPCの両方から(しかもPCはやや遅れて)聞こえてくるので、混乱すると思います。加えてマイクに話しかけると、自分の声がOBS Studioを経由してPCから出力されることになります。

遅延しているゲーム音声と自身の話す声を聴きながらプレイするのはとてもやりづらいと思うので、PCの音声出力をミュートにすることをオススメします。(一応OBS Studioの「音声ミキサー」の「音声モニタリング設定」に出力OFFにする機能もあるんですが、なんか期待通りに動くときとそうじゃない時があるので、PCの音声出力自体をOFFにしちゃってます)

これで、外部ディスプレイの映像と音声で(つまり普段と変わらない環境で)プレイすることができます。

完「ひとり実況編」

この記事では、ひとり用のゲーム収録環境について記載しました。参考になったでしょうか?

雑談しながらゲームするの結構楽しくて、気分転換に良いな〜と思っています。

今回の設定で実際に収録してみた様子がこちらです。

youtu.be

次回の記事では「音声通話アプリの音声(=友人の声)を録音できる」という要件も加えた「みんなで実況編」をお送りします。「仮想オーディオデバイス」と「仮想オーディオミキサー」を使うのでややこしい設定になりますが、オンラインゲームの楽しい様子を収録するには大事な設定です。なるべくわかりやすく書こうと思うのでお楽しみに!ではまた!

エンジニアリングリード1年目を終えて

2021年の3月からエンジニアリングリード(以下、EL)という職位に就き、気がつけば1年と5ヶ月が経過していました。

なんとなく文字に起こしておきたいことがある気がするので、とりあえず書いてみます(まとまるかわからないけど)。

GMOペパボ株式会社におけるELとは

まず前提として、自分は現在GMOペパボ株式会社(以下、ペパボ)に所属しています。

ペパボにおけるエンジニア職位制度は次のような構造になっています。

https://tech.pepabo.com/blog/2020/07/30/pepabo-engineering-2020-summer/images/pepabo-engineer-career.png

出典: ペパボのエンジニアの各種制度 2020 夏 - Pepabo Tech Portal

4等級以降のキャリアが「専門職としてのライン」と「マネジメントとしてのライン」に分かれており、ELは後者の4等級として定義されています。

平易な表現をすると「マネジメントも行なうエンジニア」ということですね。

ELとマネージャーの違い

「マネジメントを行なう」という表現を見聞きすると、世の中でよく言われる「マネージャー」や「管理職」と同じことをやるのか?という疑問が出てくると思います。

ペパボでは「マネージャー」という職位は6等級として別途存在しています。(その下位の職位として「サブマネージャー」という4等級の職位も存在します)

マネージャーに求められる要件は大きく4つです:

  • ビジネスパフォーマンス(組織目標、予実管理など)
  • リスクマネジメント(法的リスク、セキュリティリスクなど)
  • ピープルマネジメント(労務管理、エンパワーメントなど)
  • ペパボピープル(社内文化、社内ルールなど)

この4要件を細分化したN個(なんとなく具体的な数字は伏せます)の項目にもとづいてマネージャーの評価が行なわれます。 (そのほかマネージャー間の360度評価もあるようですが割愛します)

一方で「マネジメントも行なうエンジニア」としてのELは、上記のマネージャー要件のうち一部の項目が評価の対象となります。具体的には次のとおりです:

  • ビジネスパフォーマンスの一部(組織目標)
  • リスクマネジメントの一部(セキュリティリスク)
  • ピープルマネジメントの一部(エンパワーメント)

このことからELは、

「マネージャー要件における技術的な観点が不可欠な項目(プロダクト開発による組織目標の達成、継続的なメンテナンスによるセキュリティリスクの回避、技術的な助言を伴う成長支援、など)について成果を出すことが求められている」

と捉えることができると思います。

また、マネージャーに求められる予実管理、労務管理、社内文化などの項目は、ELに求められる項目には含まれていないことも大きな違いです。

ELに対する技術的な評価

ELはあくまでエンジニア職のなかの1つの職位です。 なので、もちろんエンジニアとして技術的な観点で成果を出すことも求められます。

ELの技術的な評価は、上に示したエンジニア職位制度の全体像の図における3等級エンジニア「アドバイザー」として評価が行なわれます。

ELに求められること

ここまでをまとめると、ELは

  • マネージャー要件の一部(技術的な観点が不可欠な)項目で成果を出すこと
  • 3等級エンジニアと同等の水準で技術的な成果を出すこと

が求められています。(と、自分は思っています)

1年目でやってきたこと

1年目(2021年3月〜2022年2月末)の期間は
ビジネスパフォーマンス : リスクマネジメント : ピープルマネジメント = 1 : 6 : 3
くらいの比率でやってきたと思います。

会計周りのシステム化

経理部門の方と密にコミュニケーションを取りながら、残高計算や売上計算のシステム化、会計基準の変更など対応をしました。 これは数字に誤りがあると会社としてリスクを抱えることになるので、リスクマネジメントの一環として取り組んでいました。

脆弱性診断やシステムバージョンアップの対応

自分が担当しているいくつかのサービスのなかで一番古いサービスについて、RubyRails、そのほか各種ライブラリのバージョンアップや脆弱性診断の結果に対する対応を行ないました。これもリスクマネジメントに関する取り組みです。

オンボーディング、1on1、評価

3等級で入社したメンバーのオンボーディング、部署内のエンジニアのうちの3名の評価および定期的な1on1を行ないました。このうち2名は2等級から3等級に昇格し、自分のことのように嬉しかったです。もちろん本人たちの頑張りの賜物なんですが、その頑張りがしっかり評価に反映されるよう、毎月の1on1と評価の際の資料作成フォローを妥協なく行なった自負があります。これはピープルマネジメントに関する取り組みだと捉えています。

セールに向けたパフォーマンスチューニング

細かい対応をいくつかやりました。これはビジネスパフォーマンスに関する取り組みだと捉えています。

就任前後での変化

VPoEもSELもELも、人間(それはそう)

週イチでVPoE、SEL(ELの上位職位)、ELで集まって経営会議の内容や各部門のトピックを共有する会をやっています。

就任前はそのメンバーと仕事について話す場はあまりなかった(部署が異なるメンバーは特に)ので、各部署でエンジニアをバーンと引っ張っているスーパーマンたち、みたいな印象がありました。

就任後は毎週の共有会で、悩んでいることを解決するまでの過程を知ったり、喜ばしいトピックをみんなでワイワイしたり、微妙なトピックについてみんなで「うげぇ〜」と言ったりして、みんな人間なのよなぁ〜という当たり前のことを思ったりしました。

これまでよりも広い範囲で物事を考える

部署を跨いで話す機会が増えたことで、自分の部署で抱えてる課題を同じ課題をあの部署でも抱えてるな〜などがわかるので一緒に解決できないか〜と考えるようになりました。

どうやったらもっと良くなるか考える

現状を受けとめて、どうやったらよくできるかを前向きに考えるようになりました。

根は結構ネガティブでネガティブシンキングには自信があるんですが、周囲のSELやELの影響を受けてか、大変なことでもポジティブに進めることができるようになってきました。

メンバーにもっとやってもらえるように、と考える

評価を担当するようになったからか、エンジニアメンバーに対して

  • 今やっていることをもっと拡張してもらうためには
  • 今やっていないことをできるようになるためには

という観点で、どうすればいいか考えるようになりました。

今後やっていきたいこと

ビジネスパフォーマンスをもっとやっていく

1年目は特に、組織目標を達成するための動きが全然できてなかったので、2年目はやっていきます。

比較的最近のアクションだとPayPayでお買い物できるようにしたり、セールやCM対策のパフォーマンス改善に取り組んだり、ブックマーク機能でお買い物を便利にしたり、などやってました。もっともっとやっていきます。

自分の中にリトルSELを育てる

先日同じ部署のSELである@kurotakyと1on1をして、自分をエンパワーメントしようとしてくれているのを感じました。

お互いに感じている課題を共有して、期待していることも話してもらい、よっしゃ、より高い視点と広い視野でもっと色々やっていくぞ、という気持ちになったので、日々のお仕事を「これ@kurotakyだったら何て言う?ほかのSELだったら何て言う?」という視点で考えながら過ごして行こうと思います。

とはいえ無理せず着実に

無理して何かが壊れてしまっては、結果的にやりたいことが実現できなくなってしまうので、適度にやすんで自分をコントロールしながらやっていきます。

おわりに

思ったよりもたくさん書いちゃいました。ELについて書きたいな〜とずっと思っていたので書けてよかったです。

昼からジョナサンでハイボールイカフライを食べながら書きました!うまい!よっしゃ〜、おしまい!

発表資料をつくるときに気をつけていること

先日とある発表資料をレビューする機会がありまして、自分はこういうことに気をつけているよ〜というフィードバックをしたんですが、フィードバックをしながら「あ、自分これ、結構大事にしているなぁ」と改めて気づいたので書き留めておきます。

気をつけていること

気をつけていることはこの3点です。

  1. 想定するターゲット(聴講者、読者)は誰なのか
  2. この発表の前、ターゲットはどういう状態なのか
  3. この発表を経て、ターゲットにどのような状態になってほしいのか

気をつけている、というか、この3点を直接的に資料に盛り込んでしまうことが多々あります。

  1. あなたに聴いてほしいんです
  2. あなたはいまこういう状態なんじゃないかなぁ?とわたしは想像しています
  3. この発表のあと、あなたにこういう状態になってもらいたいなと思ってます

といった感じですね。

伝えたかったことがまとまる

これを書いておくと、自分自身が「結局だれになにを伝えたかったんだっけ?」と迷子になるのを防げます。

あと、案外、そもそも伝えたいことがふわふわしてたりします。

ターゲットがどういうシーンでこの資料に触れるんだっけ?オフラインで同じ空間で発表を聴いてるんだっけ、それとも自宅でオンラインで?あるいは録画を見る?電車で資料を読むだけ?なども、大事かなと思ってます。

心構え

聴く側(読む側)も心構えができます。

例えば

「私はこの発表のターゲットのド真ん中だな。しっかり聴こう」とか

「自分は過去にはターゲットにいたけど、今は少し違う位置にいるな。その視点からターゲットの人に役立つ質問とか助言とかできるかも」とか

「自分は全然ターゲットじゃないや。聴かないで他のことしよう」とか

です。

立体的になる

結果的に構造が立体的になると思っています。

「発表している人」と「それ以外」という二分類の構造じゃなくて、

「発表している人」と「ターゲットとなる人」と「そのほか多種多様な人」という構造になります。

「そのほか多種多様な人」の中で「発表している人」のねらいに共感した人は、ねらいに沿ったアクションをしてくれる(発表中にSNSで補足説明をしてくれたり、発表後の雑談でフォローしてくれたり)ことがあって、そうなるとラッキーです。

あとは「ターゲットとなる人」が予想より少なかったとか、「こういうターゲットにした方がよかったんじゃないか」などのフィードバックも得やすくなるかなって思ってます。

みなさんはどうですか

みなさんは何か気をつけてることありますか?

ご意見ご感想をお待ちしてます。ではまた。

Discordでの音声収録: Craigを使ってみた

Discordでの音声収録の手段として Craig というボイスチャット録音Botを使ってみました。

はじめに

Craigとは...

Craigは、Discordでマルチトラック・マルチチャンネル録音するためのVC録音Botです。Craigが録音した音声を、それぞれの発言ユーザーごとに分割された音楽ファイルとして取得できます。ユーザーごとに音声を調整・カット・編集できるため、ポッドキャストや実況プレイなどの録音に最適です。

です。ポッドキャストの音声収録をDiscordでやってみたいと思い至って、Craigに辿り着きました。この記事の想定読者と参考資料は次のとおりです。

想定読者:

  • Discordの基本的な使い方はわかる
  • Discordのボイスチャットを手軽に録音したいと思っている

参考資料:

  1. Craig Records! (Craigの公式サイト)
  2. 題名「バーチャルポッドキャストの録音方法 ~ DiscordとCraig

Discordの音声設定を調整する

参考資料2に記載されているとおりに設定を調整します。参考資料2の文章を引用しながら説明していきます。

ユーザーネームの左下のユーザー設定の歯 車アイコンをクリックして、左側の音声•ビデオをクリックする。

話している最中は、入力モードを音声検出に設定するとプッシュトゥトークの様に常時ボタン を押し続ける必要がない。

Discordの音声入力に「プッシュトゥトーク」というモードがあることを初めて知りました。デフォルトでは「音声検出」になっていると思います。

「プッシュトゥトーク」はキーボードの指定したキーを押し続けている間だけ音を拾ってくれるモードなんですね。「基本はミュートにしているけどしゃべりたい時だけキーを押して喋る」というシーンで役立ちそう。Zoomでもミュート時に同じ機能があるはず(確かスペースキー)。

Discordは話し始めと最後をカットしてしまう傾向があるので、入力 感度を決定し「自動」を無効化してからスライダーを左端に移動し、できるだけ音声が途切れ なくする必要がある。

Discordが自動で音声を色々チューニングしてくれているという話は何度か聞いていたけど、話し始めと最後をカットするなどもやっているんですね👀自分が音声収録をする目的はポッドキャストで、できるだけそのままの音声を使いたいので、カットされては困ります。記事どおりに設定を変更しました。

エコー除去と音量調節の自動化を無効化することで、複数の人達が同時 に離す時に迷惑にならない役立ちとなる。設定によってはノイズ低減もオフ状態にする必要が ある。結局は全ての設定をテストすることでポッドキャストの音声を改善できる。

ほ〜、エコー除去などの音声処理もやっているんですね👀 複数人での会話の際にこの辺りの処理が余計になる場合がある、ということらしいです。自分の場合はふたりで会話する音声を収録するので、ここも記事どおりに設定を変更しました。

Craigを使う

まずは https://craig.chat/home から、自身のDiscordサーバーにCraigを招待します。招待が完了したら、CraigのBotがテキストチャンネルに入るはずです。

つぎに、適当なボイスチャンネルを開始します。その状態でテキストチャンネルで /join コマンドを打ちます。

すると、いま自分が入っているボイスチャンネルにCraigのBotが参加し、「Now Recording」という音声とともに録音が開始されます。

録音を終了するときは /stop コマンドを打ちます。

録音された音声データはCraigのWeb画面から様々な形式でダウンロードすることができます。Web画面のURLはCraigのBotから送信されてきます。/join コマンドを打った直後にこのようなダイレクトメッセージを受信しているはずです。

ダウンロードできるデータ形式は次のとおりです。

バックアップ用Bot「Giarc」も使う

実はCraigには、Giarcというバックアップ用のBotも存在しています。

https://craig.chat/home/giarc/

CraigはDiscord用の素晴らしい録音ツールですが、バグやハードウェア障害は常に付き物です。この問題を少しでも緩和するために、Craigの2番目のインスタンスであるGiarcを、Craigとは異なる地域にある別のサーバーで動かしています。 GiarcはCraigの代役なので、Craigと一緒に使用する必要があります。両方のBotをサーバーに招待し、VCに参加させてください。

使い方はCraigと同じです。

使ってみての感想

手軽に利用できて心地良かったです。オープンソース https://github.com/CraigChat/craig なのもすごい。感謝ですね〜。

Craigで録音した音声データは、一部の会話が飛んでしまっていてヒヤヒヤしましたが、Giarcのほうは欠損なく録音できていたのでなんとかなりました。両方あってよかったです。

Giarcのページを改めてみてみると

Giarcは フランスで、Craigは カナダで稼働しています。そのため、もしあなたがヨーロッパやアジアから接続している場合、CraigではなくGiarcのダウンロードリンクを使った方がいいかもしれません。ご自由にどうぞ!

とのことだったので、今後はGiarcをメイン、Craigをバックアップ、という形で使おうと思います。

あとこれはZoomとDiscordとを比較しての感想ですが、Discordの方が断然会話しやすかったです。 Zoomと比べると「遅延が少ない」「会話が重なったときに音声がつぶれにくい」という印象を受けました。

引き続きDiscordを使っていこうと思います。 Craig以外の録音手段もあれば知りたいと思っているので、知っている方がいたらぜひ教えてください〜。ではまた。

Railsアプリケーションで遅い画面を産まないためにチェックすること

Webアプリケーションを運用する中で「この画面が遅いね、もっと動作を速くしたいね」というシーンが度々ありました。 その都度、その時思いつくさまざまな対応をしてきたので、それを思い出しながら雑にメモしておきます。

自分は主にRailsでアプリケーション開発をしているので、その前提で「遅い画面を産まないためにチェックすること」という視点で書き残します。 (思いついたら追記します)

Railsのキャッシュ機構を活用できそうか

Rails のキャッシュ機構 - Railsガイド を頭に入れておきましょう。 どれも便利です。

あと、オプションのところに記載されている race_condition_ttl も便利です。使いましょう。

マルチプロセスで同じエントリが同時に再生成されてキャッシュが無効になる(dog pile効果とも呼ばれます)ときに発生する競合状態を防止するのに使います。このオプションは、新しい値の再生成が完了していない状態で、無効になったエントリを再利用してよい時間を秒で指定します。

N+1問題が発生してないか

初歩的な話ですが preloadeager_load を適切に使っているかを確認します。

この辺りの挙動については2014年の記事ですが ActiveRecordのjoinsとpreloadとincludesとeager_loadの違い - Qiita が分かりやすいです。

個人的には includes はコードリーディングしたときに挙動を想像しにくいと感じるのであまり積極的には使いません。*1

目的を意識しながら preloadeager_load を使い分けて実装するようにしています。*2

N+1問題の検知については、 bullet を導入して、CIの実行時に bullet がテストコードでN+1問題の発生を検知したらCIをfailさせるように設定しておくと便利です。

適切にindexが張られているか

クエリの実行計画をみます。EXPLAIN しましょう。

巨大なテーブル同士のJOINや不要なJOINがないか

巨大なJOINがいくつもある場合は、テーブル構成を見直すきっかけになります。

また、古い機能の名残りでいまは必要のないJOINが含まれていた、といった場合もありそうなので合わせてチェックしましょう。

Materialized View が活用できそうか

例えばランキング表示などために既存のテーブルをいくつか組み合わせて集計する必要がある時など、画面へのアクセスのたびに集計用の重いクエリが発行されてしまう場合があります。そんな時は Materialized View を作って集計結果を記録しておくと便利です。ただし、即時性が必要とされない画面だけで使える手段ですね(1時間毎に最新の集計結果になっていればOK、などであれば適していそう)

Railsアプリケーションの場合は scenic がとても便利です。

*1: includes した association に対する joins, references などによって発行されるクエリの挙動が変わるため

*2:既存コードで includes が使われている場合はそのまま使うことはあります