東京のゲーム会社でディレクターだった私のある日のスケジュール

東京のゲーム会社で5年ほど働いていたかぴばらくだです。

私は在職中、運営、プランナー、ディレクター、プロデューサーと担当業種が変わったのですが、「ディレクター」として仕事をしていたある日のスケジュールをご紹介します。

ゲームのディレクターとは

私が担当していたタイトルでは、ディレクターは「ゲームの中身に関する部分を管理する現場監督」でした。

ちょっと違うかもしれませんが、野球に例えるとプロデューサーが球団オーナーなら、ディレクターは監督というイメージ。

毎週のアップデートで使うデータに問題はないか、デバッグの進行状況はどうか、新規機能の開発で詰まっているところはないか……など四方に目を光らせつつ、デバッグやデータ作成なども行う、現場の何でも屋さんという位置づけでした。

ディレクターだった私のある日のスケジュール

「現場の何でも屋さん」ということで、作業内容は目の前のデータ修正から数か月後の新規機能の仕様づくりまで多岐にわたります。

といっても一人で行うというわけではなく、チームの皆の協力を得て進めていきます。

ある火曜日

10:00　出社

タイトルのメンテナンスは木曜日とはいえ、火曜日はまだ余裕がある日。今日のやることを思い浮かべながら出社します。

10:00～11:00　社内作業

今週のメンテナンスに必要なデータやデバッグシートが完成していることを確認し、企画運営メンバーにデバッグ作業を割り振ります。

また、ユーザサポートから回ってきたお問い合わせ内容を確認し、簡単なものは他メンバーへ振り、プログラマーやプロデューサーと相談が必要なものがないかを見ます。

11:00～11:30　朝会

担当タイトルの朝会です。ディレクターが司会進行を担当します。各メンバーの作業内容や連絡事項を共有します。

時にはチームの歓送迎会の出欠連絡をとることも。

11:30～12:30　社内作業続き

今日の午後は、今後控えている他タイトルのコラボレーションに関して外部の会社との打ち合わせ予定があります。

コラボレーションの話をまとめてくるのはプロデューサーの役割ですが、ゲームの中で何をするかを取りまとめるのはディレクターの役目。チームで出し合った案を資料に落とし込み、最終確認をします。

12:30～13:30　昼休み

外に食べに出たり、席で食べたりしつつ、時には昼寝をすることも。所属していた会社は昼休みの始まりと終わりにチャイムがあるため、寝過ごす心配もありません。

13:30～14:00　打ち合わせ準備

外部の方との打ち合わせ準備で、資料印刷や会議室の準備を行います。

14:00～16:00　コラボレーション打ち合わせ

今回のコラボレーションは、他社のPCブラウザゲームとの相互送客。お互いのゲームを遊んでいるユーザに行き来してもらい、ゲームを活性化することが狙いです。

コラボレーションイベントの期間やミッションの難易度、お互いのタイトルでの禁止事項などを話します。相手のタイトルがいわゆる版権ものであった場合、版権元の厳しいチェックが発生することもあるため、約束事項も予め確認しておきます。

16:00～18:30　再び社内作業

打ち合わせでまとまった意見を議事録としてまとめ、チームに共有したり、メンテナンス用のデバッグ進捗に問題がないかを確認したりといった作業を行います。

合間に、今後のゲーム内イベントの仕様書の大枠を作ります。毎週アップデートを行うとはいえ、週単位での仕様書ももちろん作成し、それに沿ってデータ作成などを行います。

18:30　退社

今日の作業には問題なさそうなので、定時で退社します。平和な火曜日です。

ある水曜日

10:00　出社

木曜日に向けて段々忙しくなってくる水曜日。今日あたりは何か起こりそうな予感がしたりしなかったり……

10:00～11:00　社内作業

時間がない中でも、デバッグは基本的にクロスチェックを行います。毎週入れ替わるイベントにはある程度テンプレートがあるとはいえ、データを入れるのは手作業であるため、思わぬところにミスが発生しがち。

ユーザの目に触れる前にデバッグを行いますが、一人だけのチェックでは見落としがあるため、基本は二人で行います。

デバッグシートを確認したら、ある個所が一人分のデバッグしか行われていなかったため、自分もデバッグに参加。問題がないことが確認でき、一安心です。

11:00~11:30　朝会

メンテナンス前日であるため、まだ実装や確認ができていない項目や懸念点などを洗い出します。

11:30～12:30　社内作業

メンテナンス前日の夕方には、アップデート内容の告知を掲載します。

メンテナンス日時の予告に始まり、今週実装されるイベントやキャラクターの詳細、販売キャンペーンのお知らせを出します。

運営担当が作成した告知をチェックし、誤字脱字や記載ミスがないかを確認します。

12:30～13:30　昼休み

メンテナンス前の作業が詰まっている気がするので、がっつりランチ。会社近くにある激辛担々麺のお店に行きました。

13:30～18:30　社内作業

今日は打ち合わせもないので、社内で色々な作業をこなします。あれをしようこれをしようと思っていても、思わぬところから作業が降って来たり、他の人から話しかけられたりと、なかなか予定した通りにはいかないもの。

時間に余裕をみたスケジュールが大切……と思いつつも、てんてこまいになることも。

まずは、今後実装する新機能に関して「こういうことはできるか？」という疑問をプログラマーにぶつけます。

「できるかできないでいえば、仕様書がないと何ともいえない」と言われることも多く、作った仕様書を持って席にすぐUターンということもしばしば。

とはいえ、プランナー側のやりたいことを落とし込んだ書類を見て、「これはできる」「このままだとできないけれど、ここをこうすればできる」というアドバイスを即座にくれるので、プログラマーってすごいなあと感心してしまうこともよくあります。

黙々と作業を行っているうちに、告知が公開される時間になりました。公開漏れの項目がないかをそっと確認し、また作業に戻ります。

告知公開から30分程経った頃、ユーザサポート担当から、公開した告知にミスがあるという連絡が。確認してみると、確かに課金アイテムの販売期間が明らかに間違っています。

自分も確認したのに……と悔しい思いをしつつ、訂正告知を出すよう速やかに依頼します。

何か一つ問題が起こると、何故か連鎖的にずるずると出てくるのは何でだろう、と良く思います。告知ミスが片付いたと思ったら、今度は明日のアップデート内容で仕様ミスが発覚。

現場あるあるですが、仕様を作った時やデータ作成から最初のデバッグまではうまく進んでいるのに、実装直前の段階になって破綻に気づく……世に出す前なのである意味セーフなのですが、「ここで気づいてよかったけど、逆に何でここまで誰も気づかなかったの！？」と思うほど大きな問題点を見逃していることも。

問題のある仕様に修正を加えるだけでは作業は終わりません。データの修正とデバッグし直しをしたうえで、他の箇所に影響がないかも合わせて確認します。

これが火曜日の段階であればもっと落ち着いて対処ができるのですが、このような大きな穴が発覚するのは、私の経験ではなぜか直前のタイミングばかり。冷や汗をかきつつ、今日は残業確定です。

20:00　退社

発覚した仕様ミスに修正を加え、実装に問題がない常態にしたところで退社です。明日のメンテナンスに何もないことを祈りながら家に帰ります。

ある木曜日

10:00　出社

メンテナンスの日はちょっと緊張します。不安な時は「夜にはあったかい布団で寝てるから大丈夫！」と考えてリラックスを図ります。

10:00～11:00　メンテナンス前作業

一晩寝れば頭も冷静になっているもの。昨日発覚した仕様ミスへの対処に問題がないか、改めて確認します。

同時に、デバッグが足りていない箇所はないかの確認も行います。

11:00～12:00　朝会

メンテナンス日の朝会は長め。昨日の夕方に起こった仕様変更に関してもチームに共有しておきます。

12:00～12:30　メンテナンス前作業

クロスチェックのデバッグが完了していることを確認しつつ、メンテナンス後に掲載する告知のチェックもします。

昨日告知にミスがあったので、今日も訂正の告知を出すことにならないよう、いつもより入念にチェックします。

12:30～13:30　昼休み

もうすぐメンテナンスが始まるという時間なので、今日は席で昼食をとります。作業が終わっていない！という場合は、お昼休みもぶっ通しで作業をすることもあります。

13:30～14:00　メンテナンス前作業

本番環境にアップしても大丈夫な状態になっているか、再度データをチェック。メンテ入りを待ちます。

14:00～18:00　メンテナンス

14時のメンテナンス入りを確認したら、ディレクターを含む企画運営メンバーはメンテナンスに関する作業はしばらくお休みです。プログラマーから「メンテ作業終了」の連絡がくるまでは、翌週や今後の準備、その他の作業をしたり、企画案を練ったりします。

およそ1時間が経った頃、プログラマーから「メンテナンス作業が終わった」という連絡を受けたら、企画運営側でメンテナンス終了の18時まで本番環境のチェックをします。

何の問題もなければ時間に余裕はあるのですが、まれにネットワーク不調により本番データのアップに時間がかかったり、本番環境をチェックしている時にミスが見つかってデータに修正を入れたり、ということがあります。

18時の予定終了時刻にメンテナンス明けを迎えられそうか、という現場判断はディレクターにゆだねられていたため、およそ17時半までに、メンテナンスを延長するか予定通り終了するかを決めていました。

もしもメンテナンス延長となった場合は、まずプロデューサーにそのことを共有し、予定終了時刻をチームで決めたうえでメンテナンス延長告知の掲載をします。

今日は問題なく18時にメンテナンス明けを迎えられそうなので一安心。しかしまだ油断はできません。

18:00　メンテナンス明け

無事にメンテナンス明けを迎えました。

しかし10分程だった後、プログラマーから「サーバーが重いかも」という連絡が。実際に自分でもプレイしてみると、ログインできないほどではないですが確かに動きに引っかかりがあります。加えて、TwitterなどのSNSには「重い」という書き込みが続々と増えていきます。

どうやらいくつかあるサーバーのうちの一台の機嫌が悪いとのこと。調子の悪い一台を切り離して負荷を分散させる対処を行ってもらいます。

こうなると全てはプログラマー頼りなので、全てをゆだねて祈ります。

「負荷下がったから、もう大丈夫だと思う」といわれ、ゲームの挙動に問題ないことも確認できました。

19:30　退社

解決済みの負荷問・題以外には何もなさそうだったので退社、今週もヤマが過ぎました！

まとめ

プランナーといえば、イベントなどの企画を立てている人。プロデューサーといえば、ゲームのリーダーというイメージがありますが、「ディレクターって何してるの？」と聞かれることはよくありました。

もちろん会社やタイトル毎の違いはありますが、私のいた会社では「現場のヌシ」というイメージ。

毎週のメンテナンス作業では、例え企画運営メンバー全員がインフルエンザに倒れたとしても、ディレクター一人いればプランナー業務周りは何とかなる……かも！と言われていたような、現場作業のエキスパートであり頼れる監督という位置づけでした。

オンラインゲームの現場ですから、日々様々なことがあります。それに慌てず動じず、現場のヌシとしてディレクター業務をこなしていると、何ものにも動じない鋼の心が手に入るのかもしれません。