インフラエンジニアがゲーム配信するギャップ。仕事と趣味の温度差
平日はGKEクラスタの運用とTerraformのコードレビューをしている。休日はYouTubeでゲーム実況をしている。この温度差がすごい。
職場の人に「休日何してるんですか？」と聞かれて「ゲーム配信してます」と答えると、だいたい一瞬の間がある。インフラエンジニアがマイクに向かって叫んでいる姿は想像しにくいらしい。自分でもそう思う。
仕事の自分
インフラエンジニアの仕事は基本的に地味。サーバーが安定して動いていることが成果で、何も起きないのが理想。障害対応は緊張感があるけど、日常業務は淡々としている。
Slackでのやり取りも丁寧語。PRのコメントも冷静。「こちらの変更ですが、影響範囲を確認しました」みたいなテンション。
Terraformのplanを眺めて、destroyが含まれていないことを確認して、applyする。Grafanaでメトリクスが安定しているのを見て安心する。仕事中の感情の振れ幅は極めて小さい。むしろ感情が動く＝何かトラブルが起きているということなので、動かない方がいい。
配信の自分
ゲーム実況を始めると人が変わる。
「うおおお！」「まじかよ！」「やられた〜」を連発する。テンション高めに喋り続けないと配信として成立しないから、意識的にボルテージを上げている。
同僚が配信を見たらたぶん驚く。あの冷静なインフラの人がこんなテンションで喋るのかと。
配信って、黙ってゲームしてるだけだと本当に誰も見てくれない。だから自分の思考を全部口に出す癖をつけた。「ここに敵いそうだな」「弾数やばい、リロードしたい」「右から詰めるか…いや、上取ろう」みたいに。これが最初はめちゃくちゃ難しかった。普段の仕事では頭の中で考えて、結論だけをSlackに書く。その真逆をやる必要がある。
技術スキルが配信に活きる場面
スキルの重なりがゼロかと思っていたけど、やってみると意外と活きる場面がある。
OBS設定はインフラエンジニアの領域
配信ソフトのOBSの設定は、インフラエンジニアの血が騒ぐ。ビットレート、エンコーダー設定、音声のフィルター構成。パフォーマンスチューニングの要領で最適化できる。
自分の場合、OBSの映像設定はx264ではなくNVENCを使い、ビットレートは6000kbpsに固定している。CBR（固定ビットレート）にするのがポイントで、VBR（可変）だとシーンが激しく動く場面でビットレートが跳ね上がり、配信が途切れやすくなる。こういうパラメータ調整の勘所はサーバーのチューニングと同じ感覚。
音声まわりもフィルターの順序が重要で、ノイズ抑制→ゲート→コンプレッサーの順にかけている。これはリクエスト処理のミドルウェアチェーンと同じで、順番を間違えると結果が変わる。
ネットワーク知識が地味に効く
配信のトラブルで一番多いのが回線の問題。ここはネットワークの基礎知識がそのまま役に立つ。
自宅のルーターでQoS設定をして配信トラフィックの優先度を上げたり、有線LANの経路を見直したり。配信が途切れた時にまず ping と traceroute を叩くのは、もう職業病みたいなもの。MTUサイズの問題で映像が乱れていたことがあって、その時はフラグメンテーションを疑って解決した。こんな切り分けは普通の配信者はやらないと思う。
トラブルシューティングの思考プロセス
ゲームで詰まった時の原因特定と、障害対応のログ調査は、思考プロセスが似ている。「何が変わった？」「直前に何をした？」「再現するか？」という順番で考える。
配信中にゲームがクラッシュした時、パニックにならず冷静に原因を切り分けられるのも仕事の経験のおかげだと思う。GPU温度を確認して、ドライバのバージョンを確認して、直近のWindows Updateを疑って…という流れが自然と出てくる。視聴者からすると「落ち着いてるね」と言われるけど、障害対応に比べたら大したことないという感覚がある。
エンジニアが配信を始めるなら
自分の経験から、エンジニアがゲーム配信を始めるときに知っておくと良いことをいくつか書いておく。
機材はいきなり揃えなくていい。 最初はPCの内蔵マイクとOBSだけで十分。画質や音質を上げるのは続けてからでいい。自分も最初の半年はヘッドセットのマイクで配信していた。
配信スケジュールを決めるのが大事。 エンジニアは平日の業務後に疲れていることが多いから、無理に毎日やろうとしない方がいい。自分は週末の夜だけと決めている。これなら仕事に影響しないし、続けやすい。
顔出しなしでも全然やれる。 インフラエンジニアは顔出しに抵抗がある人が多い印象（自分もそう）。ゲーム実況は画面が主役なので、顔出しなしでも成立する。気になるならVTuberモデルを使う手もある。
収益化は期待しすぎない。 YouTubeの収益化条件（登録者1000人・再生4000時間）は想像以上に遠い。副業として収入を得たいなら、技術ブログのアフィリエイトや技術書の執筆の方が効率はいい。配信はあくまで楽しむためにやるくらいの気持ちがちょうどいい。
両方やる意味
仕事だけだと息が詰まる。かといって趣味だけでは生活できない。
インフラの仕事は成果が見えにくい。安定稼働は当たり前で、感謝されることは少ない。配信は逆で、リアクションが返ってくる。コメントが来る。再生数が見える。
この「反応がもらえる場所」があるのが精神的に大きい。同接が少なくても、ゼロじゃなければ誰かが見てくれている。
仕事での「誰にも気づかれないけど重要な改善」が続くと、じわじわとモチベーションが削られる。Kubernetesのバージョンアップを無停止で完了しても、ユーザーには何も起きていない。それが正解なんだけど、達成感は薄い。配信はその逆で、下手でも何かしらの反応がある。このバランスが自分には合っている。
時間の使い方と切り替えのコツ
エンジニアと配信者の両立で一番難しいのは時間管理。自分はGoogleカレンダーに「配信」のブロックを入れて、仕事の予定と同じように管理している。
切り替えのコツとしては、配信前に30分くらい準備の時間を取ること。OBSの設定確認、マイクテスト、配信タイトルの決定。この準備の時間が、仕事モードから配信モードへの切り替えスイッチになっている。仕事終わりにいきなりマイクの前に座っても、うまくテンションが上がらない。
あと、障害対応のオンコール当番の日は配信しないと決めている。配信中にPagerDutyが鳴ったら最悪なので。一度だけ配信中にSlackの通知が鳴って肝が冷えたことがあり、それ以来は通知を切るか、当番じゃない日にやるようにした。
ギャップを楽しむ
最初は「仕事と全然違うことやってるな」と思っていたけど、今はこのギャップが気に入っている。
堅い仕事をしている分、趣味は思い切り緩くていい。逆に、配信で発散している分、仕事に集中できている気もする。
配信を始めてから、人に説明するスキルが上がった気がする。配信では「今何をしているか」を常に言語化する必要があるので、その癖が仕事のミーティングや障害報告にも活きている。思考を声に出す練習を毎週やっているようなものだから、当然かもしれない。
インフラエンジニアとゲーム配信者。共通点は少ないけど、どっちも自分。片方だけだったら多分飽きていたし、両方あるから続いている。
関連記事
他の記事
ブラウザ横スクロールアクションゲーム開発記｜TypeScript×Canvasで作るネオンランナー
HTML5 CanvasとTypeScriptで横スクロールアクションゲーム「ネオンランナー」を自作した。物理エンジン、衝突判定、操作性の工夫を解説する。
ブラウザで遊べるテトリス風パズルをTypeScriptで作った話
HTML5 CanvasとTypeScriptでテトリス風ブロックパズルを実装した。エンジンとUIを分離するSnapshotパターンや、ネオン演出のこだわりを解説する。
ゲーム実況のサムネイル作りで学んだデザインの基本
非デザイナーがゲーム配信のサムネイルを自作し続けて気づいた、視認性・配色・構図の基本ルール。試行錯誤の記録。
配信のコメント欄が動いた瞬間の話。ゼロからイチの体験
ゲーム配信でコメントがゼロの日々を超えて、初めてリアルタイムでコメントが来た瞬間の話。ゼロからイチの体験がモチベーションを変えた。