アーケードゲームを支えるデバッグ術

ブログ読者のみなさん、はじめまして。
株式会社セガのベテランプログラマー阿部です。

このエントリーではデバッグ手法のあれこれについての体験談と、デバッグをテーマに一昨年に実施されたプログラマー向け新人研修の概要をお伝えしたいと思います。

EXE ファイルのデバッグ

同僚が作った EXE ファイルが手元にあり、あなたはこれを Windows で起動しようとしています。
起動してみたところ何も反応がなく、しかもそれは想定外のことでした。
「何コレ、動かないんだけど」とあなたが同僚に文句を伝えると、同僚はあなたに返します。
「こっちでは動いてるよ」

 

困りましたね。
あなたの手元には EXE のソースコードも無ければ、Visual Studio もありません。
こんな時、どうするのが正解でしょうか?

実はこんな状況でもやれる事がいくつかあるんです。
わたしなら プロセスのメモリダンプ を取って、同僚に渡します。

 


プロセスダンプがあれば、同僚はプログラムがどこまで進んだのかを Visual Studio で把握することができるようになるのです。
プロセスダンプの取得は ツール不要で Windows デスクトップから操作可能 なので、この方法は一番気軽に試せることでしょう。

 

f:id:sgtech:20201124210821p:plain

プロセスダンプの取得

あるいはその前に Sysinternals Suite に含まれる DebugView の出力を確認してみると、プログラムに埋め込まれた OutputDebugString() から 何らかの手掛かりが得られるかもしれません。
もし EXE ファイルと PDB ファイルが揃っていて 別の PC 開発環境があるなら、イーサネット経由でリモートデバッガをアタッチしても良いでしょう。
PDB ファイルが無いとしても 仮に EXE が .NET アセンブリなのであれば、ILSpy などの逆アセンブラーが使えるかもしれません。

 

こういう知識は「持っているかどうか」がとても重要 で、仕事の速いプログラマーほど よりたくさんの手段を自然と身に着けているような気がしています。
社内には SYS ファイル(デバイスドライバー)をデバッグできるプログラマーとかもいて、もうリスペクトしかないです。

イーサネット絡みのデバッグ

ネットワーク上のゲームサーバーと通信するクライアントプログラムを書いて、これをアーケードゲーム機で起動させたとします。
ゲームサーバーとの通信が「たまに成功しないことがある」という場合は、どうデバッグしたら良いのでしようか?

近年のアーケードゲーム機は PC アーキテクチャーをベースに設計されることも多く、セガでも Windows を搭載した機種が多数リリースされています。
コピーガードやリバースエンジニアリング防止を目的として、多くのアーケードゲーム機ではデスクトップ画面を開くことはできず、ネットワーク経由でのログインやプロセスへのアタッチもできません(外界からは ロックダウン されています)。

 

「たまに失敗」という場合は、ソースコードレビューで判明するバグがあるとは考えにくいです。
そこでわたしなら、 イーサネットを流れるイーサフレームを Wireshark でパケットキャプチャーする ことから始めてみます。

 

f:id:sgtech:20201124210834p:plain

フレームの測定


イーサネットを観測することで、最初にまず以下を見極められると期待しています。

  • ケース1: 想定通りにパケットが流れていない(送信失敗)
  • ケース2: 想定外のパケットが流れている
  • ケース3: 想定通りのパケットが流れている(送信成功)

その結果、クライアントのコードが悪いのか、OS 側スタックのネットワーク設定が悪いのか、上流のネットワークが悪いのかを絞り込める、という算段です。

 

f:id:sgtech:20201124210838p:plain

問題を切り分ける


なお 「上流のネットワークが悪い」という結果だった場合は、キャプチャーの測定範囲を変更して 問題の機器を特定 していきます。
過去には、全国ゲームセンターにあるルーターが原因ということもありました。

ルーターが IP パケットのチェックサムを再計算するときに、特定条件下で計算ミスが起こるため、
ルーターのさらに上位にあるネットワーク機器でパケットがドロップされていた

というもので、本来ならばルーターファームウェアを修正し更新版を配信することになります。

 

通信エラーだけではありません。
TCP 通信において 「スループットが足りない」という場合、ここでもパケットキャプチャーから始めるのは良い選択の1つ です。
測定結果から、次に挙げるような点検箇所がいくつか見つかることでしょう。

  • SYN パケットに時間が掛かっている
    → コネクションプールを導入するか、セッションクローズしないプロトコルを採用する
  • リクエストからレスポンスまでの間隔が圧倒的に長い
    → サーバー処理でスワップアウトやスロークエリが発生していないか確認する

周辺機器絡みのデバッグ

広く使われている キャラクター表示器 は、シリアルポートから送信されたアスキー文字や SJIS をドットマトリクスとして表示してくれます。

 

f:id:sgtech:20201124210830p:plain

キャラクター表示器(VFD)

ある日「キャラクター表示器の表示がおかしい」という報告をもらって現地確認に行くと、見慣れない文字列が確かに表示されていました。
プログラムから制御しているというのに、 プログラム内に存在しない文字列が表示されてしまうのはおかしい ですね。
この表示器を含めて、多くは RS232C という低速でレガシーなシリアルポートを使って接続しています。
RS232C 通信は物理層での冗長性に乏しいため、ひょっとすると外的要因でポートに電気的なノイズが乗ってしまい、パケットが化けてしまったのかもしれません。

 

ということで早速 RS232C を測定しました。
RS232C の測定には ロジックアナライザーという測定機器を使います 。
RS232C 接続を構成するラインをプローブすれば、各ラインの Hi/Lo をタイミングチャートとして確認できるようになります。

 

f:id:sgtech:20201124210826p:plain

研修で使用した ZEROPLUS 製 ロジックアナライザー

f:id:sgtech:20201124210842p:plain

測定結果のタイミングチャート

実際測定してみると、タイミングチャート上はプログラムからの出力がそのまま反映されており、異常な部分は見つかりませんでした(結局その後の調査で 別の原因が見付かりました)。

 

同じ手法は USB 機器にも使えます。
USB 機器の場合は USB 対応のプロトコルアナライザーを導入することもできます(実は USBPcap + Wireshark という別の選択肢もあります)。

ゲームセンターに設置されるアーケードゲームは、ゲームパッドに縛られない、多彩なユーザーインターフェースが特徴の1つになっています。
さらにユーザーインターフェースだけでなく、キャビネット上の電飾や可動部のモーターなど さまざまな周辺機器がつながっており、それらをすべてプログラムで制御しています。
そういった周辺機器としては、既製品を採用することもあれば、新規に設計することもあります。
ここにもデバッグの機会が大いにあります。

デバッグスキルブートキャンプ

ここまでいくつか紹介したように、「プログラムのデバッグに使えるもの」にはツール(ソフトウェア)だけでなく、測定機器(ハードウェア)も重要な一端を担っていることが理解いただけたかと思います。
また大学や専門学校などで 「プログラミングをマスターする機会」はあっても、「デバッグをマスターする機会」は無いのが実情 です。

わたしが所属する技術本部では、これらの背景を踏まえてプログラマー向け新人研修が実施されました。
デバッグスキルにフォーカスしたハンズオン研修、題して「デバッグスキルブートキャンプ」です。

学生時代に触れる機会が少ないであろう測定機器にも触れながら バグを正しく観測する技術 を習得し、 printf デバッグ だけでは決して成し得ない、バグの根本原因に辿り着く 貴重な体験を重視としたカリキュラム になっています。

 

開催形態は以下の通り。
他の新人研修とは異なり、新人プログラマーが実務に少し馴染んだ年末年始に開催されています。

  • ハンズオン重視: 当日フラっとやってきて学べればよい
  • 予習・宿題は原則ナシ: 「座学 20min、ハンズオン 75min」とか「座学 10min、ハンズオン 45min」とか
  • 開催時期はプロジェクト配属後6か月後から
  • 開催ペースは毎週1回、計9回(9ネタ)ほど

 

本来なら社内に広く展開して必修化した方が社員みんなの為になるのですが、測定機材の都合もあって一部組織内での開催にとどまっているのが現状のようです。
各回資料は社内公開されていますが、そのうち一冊の本に体系化されたらイイなと密かに期待しています。


f:id:sgtech:20201124210850j:plainf:id:sgtech:20201124210854j:plain

f:id:sgtech:20201124210845j:plain

 

黒子に徹する、裏方系エンジニア

デバッグの世界とデバッグスキルブートキャンプについて紹介しました。
最後にわたしが所属する技術本部について紹介します。

技術本部にはいろいろなキャリアの開発者が在籍しており、 ゲーム体験・感動体験を下支えする何か を日々開発しています。
わたし自身を例に挙げると 以下のような感じです。

  • ゲームを開発するためのライブラリを作ったり
  • コンバーターとか自動化ツールを作ったり
  • Windows Embedded を使いこなして、アーケードゲーム機向けの OS をビルドしたり
  • 開発者向けグループウェアを管理したり

近隣のデスクには ちょっと違う種類の仕事をしている人がいますね。

  • データベースとか VM をいじる人
  • 基板回路を設計する人
  • Maya 上のメッシュモデルをあれこれする人
  • ルーターとか「目新しいユーザーインターフェースデバイス」をいじめる人(w)など

千人規模の社内開発者を支える技術本部にはいろいろな仕事があって、それぞれに奥が深そうです。
そして ゲーム自体のおもしろさを追求するのとは違った立ち位置で、ゲーム周辺にある様々な問題を解決 しています。

 

わたしもゲーム開発を後押しする裏方系エンジニアに転身したことで、結果的にはいろいろなテクノロジースキルを身に着けることができました。
「開発したゲームで世界をあっと言わせる!」という部分に自信を持てなくても、「技術のことなら何でも任せて!」という自信に満ちたプログラマー/ソフトウェアエンジニアなら、セガでキャリアを積むのも悪くないと思いますよ。

ということで、現場で成長をつづけながら「縁の下の力持ち」として共に働ける仲間を求めています。

 

recruit.sega.jp


-----

©SEGA
記載されている会社名、製品名は、各社の登録商標または商標です。

 

ペルソナ5 ザ・ロイヤルの開発中、自動プレイでバグを検出してみた話

ごあいさつ

初めまして、株式会社アトラスのプログラマー埜渡です。
Tech BLOGにお邪魔させていただきます。

今回は、弊社のタイトル「ペルソナ5 ザ・ロイヤル」(P5R)の開発中に、自動プレイを実装してバグの検出を行った経緯とその結果についてのお話をさせていただきます。
ゲーム本編の実装についてのノウハウというよりは、デバッグ作業での工夫についての内容になります。

ただ、触れる内容といたしましてはP5Rのゲームの中身に関する事が多いため、未プレイの方はプレイしてから読んでいただけると、より理解が深められると思います。

p5r.jp 

自動プレイ実装のきっかけ

自分が入社した頃の一昔前のバグの検出といえば(現象発生時の記録を残すために)開発機をビデオデッキに繋ぎながらプレイをして、発見したら詳細な手順をバグシート(紙)に書いて報告をしているような方法でした。

最近では開発環境自体に録画機能が備えてあったり、バグ報告もWebベースでチケット管理したりとだいぶ環境が変わってきました。

報告方法が変わってきただけでなく、検出方法も人が何時間も粘ってプレイして出す方法から、機械的にテストできるものは自動化をするような動きに変わってきています。

弊社タイトルのP5Rは平均プレイ時間がおよそ100時間ほどとなっており、勤勉に日々の業務時間フルにプレイしても、クリアまでに3週間近くかかってしまう計算になります。

f:id:sgtech:20200918095440p:plain

そんなことも背景にあったため、なんとかして少しでもプレイして確認する時間を増やしたい、できればエンディングまで通しで確認できる仕組みを作りたいという考えから人手を介さずともゲーム本編のテストをしてくれるような自動プレイを実装しようと思い立ちました。

自動プレイを実装するにあたって

自動プレイを実装するにあたって、いくつか問題となる事がありました。

  1. 専用の作業時間を用意していなかったため、他の人に作業をお願いはできない
  2. 同様の理由で自動プレイ自体の調整・修正作業に多くの時間は費やせない

1.についてですが、例えばプランナーやデザイナーに自動プレイ用に何かを対応作業をしてほしいというお願いをしようにも、そもそもの担当箇所の実装や調整作業で手一杯なため、追加の作業はお願いできないという状況にありました。

2.についても、自分自身が日常・ダンジョンパート(プレイヤーを操作して自由に移動するパート)という担当箇所を持っていたため、自動プレイの実装をした後にプランナーやデザイナーの仕様変更に合わせた調整をするための時間が十分にあるわけではありませんでした。

 

そんな事もあり、実装する仕組みとしては

  • データ作成の時間が無いため、自動プレイのための専用データはなるべく用意しない
  • 細かい対応する時間が無いため、仕様変更や調整に対応できるような仕組みでの実装を試みる

このようなコンセプトを持って、自動プレイの実装作業を開始しました。

また、実装の目標として

  • 人手を介さずとも、ゲーム開始からエンディングまで自動でプレイできる
  • ランダム要素を増やしなるべく多くの箇所をチェックできるようにする

こちらを達成できるようなものを目指し作成を開始しました。

実装してみたもの

実装内容の説明の前にゲームのシステムを軽く説明させていただきます。

ペルソナシリーズの特徴的なシステムとして、カレンダーシステムがあります。

f:id:sgtech:20200918095455p:plain

カレンダーシステム

こちらはゲーム内1年間の日々を過ごす事でゲームが進行していく仕組みになっています。
極端な話ですと、毎日家に帰って寝るだけの自堕落な生活をしていてもエンディングへ近づく事はできます

f:id:sgtech:20200918095520p:plain

果報は寝て待つ

・・・が、流石にそれだけでゲームが進行するはずもなく、一定期間にダンジョンをクリアしてボスを倒すようなことはゲームクリアするために必要となります。
また、ただ寝るだけの生活ではバグの検出としては不十分なのでなるべく色々なイベントを発生させるようにもしたいという考えがありました。そのためには自室のベットへまっしぐら・・・ではなく様々な場所へ移動するための仕組みが必要となります。

 ここで問題となったのが、どのようにしてプレイヤーキャラを目的地に移動させてゲームを進行させていくかです。

ゲームを進行させるというのは、ダンジョンパートであればギミックを解除しボスの元までたどり着く、日常パートであればNPCに話しかけてイベントを発生させたり、バッティングセンターに通ったりすることになります。
こういったイベントをこなしていくことで、ゲームオーバーになることなく日付が進行しエンディングを迎えることができます。

次に目的地へ移動する仕組みについてですが、真っ先に思いたものは人がプレイしたデータをリプレイまたはそのような操作をツール上で指定するといったものでした。
ただ、今回は先の「データ作成の時間が無いため、自動プレイのための専用データはなるべく用意しない」という事情もあり、実装することはできませんでした。

そのため専用データを必要としない、ルールベースの移動システムを実装することにしました。

ルールベースの実装基本方針として、付近のイベントヒットを探索し起動するという仕組みを実装しました。

ここでいうイベントヒットとは、ゲーム中アクセスすることでイベントが発生するような範囲のことを指します。

f:id:sgtech:20200918095444p:plain

イベントヒット例
  • NPCとのTalkヒット
  • 宝箱や扉のCheckヒット
  • エリア移動を行うGotoヒット
  • …etc

こちらを目標地点として移動することで、闇雲に移動するのではなく先述のゲームを進行させるイベントを発生するために移動することができます。

本実装ではプレイヤーキャラクターの前方範囲を中心に、直線距離で障害物に阻まれることなくたどり着けるものをランダムで検索しそちらを目標地点として移動させました。(画面写真プレイヤー前方の扇形範囲)

f:id:sgtech:20200918095449p:plain

イベントヒット探索

ただ、こちらだけでは付近にイベントヒットがない場合には移動に困ったためもう一つのルールを実装しました。

 もう一つのルールはヒートマップ(時限制の徘徊履歴)になります。(画面写真の赤いラインのブロック)

f:id:sgtech:20200918095500p:plain

ヒートマップ

歩き回ったプレイヤーの周囲(本作では100cm立方のブロック)に時間経過でクリアされる徘徊履歴をつけることで、ヒートマップがない場所=(少なくとも直近では)あるきまわっていない場所というルールができました。

こちらのルールを追加することで、イベントヒットが検索で見つからなかった場合には、付近のヒートマップが配置されていない場所(ブロック)を移動目標にすることで、未踏破部分を目指して歩き回ることができるようになりました。 

f:id:sgtech:20200918095508g:plain

自動プレイの移動例

蛇行した通路でも引っかかることなく、ヒートマップの存在しない未踏破部分へ移動し、イベントヒットを見つけた際には移動して調べる動作をしていることがわかると思います。

未踏破部分には今まで調べたことのないイベントヒットがある可能性が高く、そちらのイベントヒットにアクセスすることで、新たな未踏破エリアが増え、さらなる未踏破部分へと移動というループができ、より広く、より先の範囲を自動で移動できるようになりました。

 その他にも細かい調整はしたものの、大きくは先の2つの移動ルールでエリア内の未踏破部分を歩き回り、発見したイベントヒットを調べることができたため最終的にはダンジョンのボスまで到達することができました。

これまでの仕組みを実装したことで、日常パートではダンジョン最奥部のような目指す目的地は無いものの、同様のルールで様々なNPCや施設にアクセスするため、各種イベントを発生することができるようになりました。

ここまで実装できれば、プレイヤーキャラの移動箇所以外(バトルパートやイベントパートなど)はランダム入力でもなんとかゲームが進行ができ、最終的にはエンディングへ到達することができるようになりました

自動プレイで目的地として使用しているイベントヒットは、ゲーム内で使用するためのデータだったため追加のデータを必要とすることが(ほとんど)なく、ゲーム本編での調整による修正にも強いものとして実装することができました。

そのため開発中盤~マスターの直前あたりからは手の空いた筐体(退社時など)を利用して自動プレイを回すようにしていましたが、各種の調整作業が有ったとしても自動プレイ自体の調整は殆どせずに稼働させておくことができました。

運用した結果

今回実装した自動プレイでは、主にハングアップや進行不能となるような不具合の検出に重点を置いてチェックを行いました。

その結果として、上記のような最重要修正ランクバグの報告数のうち5%程は自動プレイで検出することができました
割合としてはちょっと少ないかなという印象かもしれませんが、こちらはバグチケットとして記録が残っているものに限っているため、報告が残っていない開発中盤時から発見できた不具合などを含めるともう少し多い割合貢献できていたと思います。

また自動プレイで検出できたバグは、人手で再現するのが難しいようなタイミングや方法でのものが多く、こちらが予想できないようなバグを発見することができたのも大きな収穫となりました。

  • バトルの特定タイミングでラッシュをすると進行不能
  • システムセーブ中にデータロードでハングアップ
  • 特定の手順とタイミングでペルソナ合体を行うとハングアップ
  • etc...

開発中盤から1台は自動プレイ用に常に稼働していた筐体がありましたが、そちらはほぼほぼ24時間フル稼働させていた結果、マスターアップ時点の累積プレイ時間は2000時間を超えるものとなっていました。(およそ250人日分の働き!!)

まとめ

今回の自動プレイの実装では、専用のデータを殆ど用意せずゲーム本編の調整があっても自動プレイの調整を行うことはあまりしないで済む方法として実装できました。

実装方法としてメリットが多いように思えるかもしれませんが、もちろんデメリットもありました。

  • ランダムでアクセスするためすべてのチェックを網羅できているわけではない
  • 同様の理由としてランダム操作が多く、複雑な条件のチェックができていない
  • キャラクターの移動効率は良くないため1周あたり300時間かかってしまった

これらは実際に運用してみて、今回の問題点・反省点と感じました。

 

今後の課題として、これらの問題を解消しより効率よく細部までのチェックを行える仕組みを考えていきたいと思っています。

 

アトラスではこのような取り組みに興味のある方を募集しています。もしご興味を持たれましたら下記サイトにアクセスしてみてください。

 

www.atlus.co.jp

 

©SEGA/©ATLUS

CEDEC 2020 セガグループによるセッション紹介!

皆さんこんにちは、毎年恒例のCEDECでのセガグループによるセッション紹介です!
株式会社セガ、第3事業部の麓です。

来月に今年はオンラインで開催されるゲーム業界最大のカンファレンス

CEDEC2020

https://cedec.cesa.or.jp/2020/

会期:2020年9月2日(水)~9月4日(金)
にセガグループ(および関連会社)から今年もいくつか登壇します!
今回で5回目となる、セガグループ関係者によるセッションと登壇者紹介に加え、ここでしか見れない講演者からのメッセージや、当日の資料からの抜粋等、紹介します。

 

デフォルメとリアルの両立を目指して ~新サクラ大戦のキャラクター作成事例~

セッション内容と講演者より

「新サクラ大戦」のキャラクター表現では、トゥーン的諧調表現とPBRのリアル質感表現の双方を混在させて使用することで、アニメ・漫画的なデフォルメ感とリアリティのある質感・存在感を両立させることを目標としていました。一見すると相反する組み合わせのようにも見えますが、適切な使いどころを分けることによって双方の良さを引き出すことを試みています。
また、複数のキャラクターデザインが混在する今作で、全体の統一感を出しつつ、元デザインの個性を活かして調整するという点についても課題の一つとなっていました。
今回はその制作手法とプロセスを紹介し、更にそこから判明した課題点を共有したいと思います。

講演者

株式会社セガ

ジャパンアジアスタジオ統括本部 第2開発2部 第1デザインセクション

デザイナー

柳瀬 遼平

09月03日(木) 11:00 〜 12:00レギュラーセッション

cedec.cesa.or.jp


スナップショット

f:id:sgtech:20200807164830p:plain

f:id:sgtech:20200807164842p:plain

f:id:sgtech:20200807164855p:plain

セッションについて一言

当セッションでは「新サクラ大戦」のキャラクターモデル表現のノウハウを紹介させて頂きます。

細かい技術の積み重ねで出来ているタイトルですので、その中で少しでも制作のヒントになる発見があれば幸いです。

よろしくお願いいたします。

「歌い出すSympathy」、PSO2のボーカルBGM制作談

セッション内容と講演者より

PSO2のBGMシステム「Sympathy」の仕組みやその使用例につきましてこれまでも講演を行ってまいりましたが、今回は各エピソードで制作した「ボーカル」を用いたBGMにつきまして制作事例をご紹介できればと思います。プロシージャルであり、インタラクティブである「ボーカル曲」は果たして作ることができるのか?そのためには作曲、編曲、作詞、レコーディングから、BGM制作ツール「MusicEditor」の改良まで、様々な要素についてチャレンジが必要でした。そのときの体験をご紹介できればと思います。

講演者

株式会社セガ

ジャパンアジアスタジオ統括本部 第2事業部 サウンドセクション

サウンドディレクター・クリエイター

小林 秀聡

09月03日(木) 11:00 〜 12:00(レギュラーセッション)

cedec.cesa.or.jp

スナップショット

f:id:sgtech:20200820152515p:plain

f:id:sgtech:20200820152511p:plain

セッションについて一言

具体的な内容は多めですが、完成までの流れを追って説明を入れることでわかりやすさを目指しました。

ご興味持って頂けましたら幸いです。

また、BGMツール「MusicEditor」を使用した実演(楽曲再生)も予定しております。

在宅勤務でスクラム!

セッション内容と講演者より

私達は、約半年前より新規プロダクトの開発を行っているスクラムチームです。
プロダクトの最初のリリースを目前に控えたある日、在宅勤務による開発を取り組む必要に迫られました。
セレモニーはどうするのか...スクラムを継続できるのか...
様々な不安がよぎりましたが、私達はスクラムを継続する選択をしました。
物理的に距離を乗り越えスクラムを継続した中での成果や気付き、そして失敗をお伝えできればと思います。

講演者

 

株式会社セガ

グローバルパブリッシング事業本部 DMS事業部 システム開発部 研究開発2課

課長/シニアエンジニア

横島 太志

09月03日(木) 18:00 〜 18:25(ショートセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200807163933j:plain

f:id:sgtech:20200807163937j:plain

セッションについて一言

在宅勤務、オフィス勤務、それぞれの在り方を模索されている方も多くいらっしゃるかと思います。

このセッションでは、どのようにリモートでスクラムを実践し、何が良く何につまずき、そしてどう改善していったのか発表させていただきます。

私たちも挑戦の最中ではありますが、皆様にとって何かのキッカケになれば幸いです。

 

「龍が如くスタジオ」のQAエンジニアリング技術を結集した全自動バグ取りシステム

セッション内容と講演者より

近年のゲーム開発におけるバグは、大規模化や開発期間の長期化によって数が増大し、内容も複雑化する傾向にあります。また、バグは見つけて修正するだけではなく、様々な作業フローが必要です。本講演では、バグのワークフローを探索・報告・選別・修正・修正確認のフェーズに分けた上で、「龍が如くスタジオ」で取り組んできた自動テストや開発環境の自動化技術を活用し、バグにまつわる作業フローを最大限自動化した全自動バグ取りシステムについて、実際に運用した「龍が如く7 光と闇の行方」での事例を交えてご紹介いたします。

講演者

株式会社セガ

第1事業部

QAエンジニア

阪上 直樹

 

開発技術部

ビルドエンジニア

粉川 貴至

09月02日(水) 18:00 〜 19:00(レギュラーセッション)

cedec.cesa.or.jp


スナップショット 

f:id:sgtech:20200818174259p:plain

f:id:sgtech:20200818174304p:plain

セッションについて一言
本講演では、手動でのバグの作業フローを整理した上で、自動化に至る過程を丁寧に説明しますので、
エンジニア以外の方にも得られる知見があると思います。
また、チケット管理システム以外に、Jenkinsやテスト自動化にも触れる予定です。
龍が如くシリーズの自動化の集大成となる講演を目指します!是非ご視聴ください!
 

ワーママ・ワーパパたちの「働き方」って改革できていますか? 4社事例から道を探ってみよう!

セッション内容と講演者より

2017年に始まったワーママ・ワーパパ(WM/WP)ラウンドテーブルから分離した、
企業規模を問わない4社合同の情報共有セッションです。以下内容を予定しています。
・各社の働き方情報共有
 (タイムテーブル実例、在宅勤務事情、男性育休の状況、勤務制度の活用状況など)
・各社WM/WPの働き方や悩みの紹介
・どうやったらより働きやすくなるかの試行錯誤状況の共有
・各社社内コミュニティの紹介や、その活動状況の共有
※例年ラウンドテーブルに続けて行われていた自費ランチ交流会は、後日改めての開催となりましたため、
 セッション内でご案内させていただきます。
※ワーキングペアレンツの働き方に関するアンケートへのご協力ありがとうございました。
 結果は本講演内でのご紹介、及び、後日Cedilの資料に掲載させていただきますのでご参照くださいませ。

講演者

株式会社セガ

ジャパンアジアスタジオ統括本部 第5事業部 第5開発2部 プログラムセクション

柳瀬 彩佳 

09月03日(木) 11:00 〜 12:00(レギュラーセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200817134258j:plain

セッションについて一言

4社の様々な働き方を紹介します。
昨年までのCEDECワーママ・ワーパパラウンドテーブルにて多く聞かれた、「子育てしながら働いていけるのか不安」「子育て中の部下のことを知りたい」という疑問への回答の1つに、また、同じく子育てしながら働く人の参考になれると嬉しいです。

 

スケジュール作成をもっと楽に!という動機から生まれた内製アプリケーション開発実例

セッション内容と講演者より

スケジュール作成アプリケーション『ScheduleCanvas』を内製で開発する中で得られた知見を共有します。

・必要な主な機能をピックアップし、何が重要だったかを説明。

・ツールの運用と開発を同時進行するためのノウハウ。

・アンケート結果と要望をまとめ、対応策やユーザー傾向を俯瞰。

・アプリケーション実装からガントチャート描画に関して

このツールはSEGA Techblogでも紹介していますが、ブログの内容を掘り下げて紹介します。

講演者

株式会社セガ

第3事業部 第3開発2部 テクニカルサポートセクション

テクニカルアーティスト:マネージャー

麓 一博

テクニカルアーティスト

清水 宣寿

09月03日(木) 13:30 〜 13:55(ショートセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200805141352p:plain

f:id:sgtech:20200805141356p:plain

セッションについて一言

今回ご用意したセッションは『ScheduleCanvas』の紹介だけではなく、内製ツールを開発するためにどういった対応が必要なのかを実体験を元にまとめて発表させていただきます。皆様が内製ツールを開発する時にちらっと思い出していただけるような、そんなセッションになることを目指しています。よろしくお願い致します。

 

Technical Artist Bootcamp 2020 :「ToolDev for TA」

セッション内容と講演者より

前半:今野「新卒からのTA推移」

「TAはベテランのアーティストやアートへの造詣が深いプログラマがなるもの」

この言葉は僕がTAになるにあたって何度も聞かされた言葉です。本当にそうでしょうか。

求めるTA像によりますが、決してそんなことはなく、むしろ経験の量に限らず技術面の知識はアーティストの武器になることを、実例を併せて紹介させていただきたいと思います。

後半:清水「TAブートキャンプ ツールのGUIを作ろう」

本セッションでは、C#とWindows Formsを使用してのツールのGUIの作り方を1から紹介します。

Visual Studio上でのプロジェクト作成からシンプルなGUIを作成し、任意の処理を動かすところまでの流れを解説します。

また、ツールにあって当然の機能として求められる「ドラッグ&ドロップ対応」「設定の保存」「プログレスバー実装」の実装方法の一例を紹介します。

講演者

株式会社セガ

第3事業部 第3開発2部 テクニカルサポートセクション

テクニカルアーティスト:マネージャー

麓 一博

テクニカルアーティスト

清水 宣寿 

09月04日(金) 09:45 〜 10:45(レギュラーセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200820093931p:plain

f:id:sgtech:20200820093925p:plain

f:id:sgtech:20200820093937j:plain

セッションについて一言

テクニカルアーティストに必要なスキルをブートキャンプ(基礎訓練)と言う形で学び、日々の業務に活かしていこうという趣旨のセッションにて、今回は清水からツールの作り方を基本的なところからを1セッションの半分の時間を使って解説します。
この講演でTAも皆簡単なツールは作れるようになって開発環境をどんどん効率化していきましょう。よろしくお願い致します。

 

技術同人作家になろう ~働き方改革時代におけるエンジニアのレベルアップの一例~

セッション内容と講演者より

近年、「技術同人誌」がIT業界を中心として劇的な盛り上がりを見せています。

「技術同人誌」は、IT技術だけに留まらず、科学や数学、工学系分野等非常に広範な技術内容を取り扱う同人誌の総称です。

このセッションでは、「元々blogで積極的に情報を発信していたエンジニア」と「プライベートでは全く技術情報を発信してこなかったエンジニア」の二人が、それぞれの視点から「技術同人誌」の執筆を通じて得られたものについて紹介します。

「技術同人誌」とblog・勉強会での講演・商業誌等の他の情報発信手段の比較についても実例を元に解説します。

また、ゲームエンジニアが「技術同人誌」を書くことで技術以外の視野が広がり、より広い意味でのレベルアップを果たすことができる点についても紹介します。

講演者

株式会社セガ

エンジニア

竹原 涼

山田 英伸

09月03日(木) 18:30 〜 18:55(ショートセッション)

cedec.cesa.or.jp

スナップショット 

f:id:sgtech:20200817131827p:plain

f:id:sgtech:20200817131834p:plain

f:id:sgtech:20200817131843p:plain

セッションについて

「技術同人誌」という言葉を聞いたことはありますか?
「同人誌」なら聞いたことはあるけど「技術同人誌」って何だろう?と思う人の方が多いかもしれません
当講演では、この「技術同人誌」を通じて、私達がエンジニアとしてレベルアップした事例を共有します
気楽な形で聞ける内容にしようと思ってますので、「技術同人誌」って何だろうという方から、エンジニアとして行き詰まりを感じている方まで、お気軽にご視聴ください
そして、当講演を切っ掛けにゲーム業界にも「技術同人誌」が広がると嬉しく思います


・当講演は副業活動の一環です
・講演内容は個人の意見であり、株式会社セガの公式見解を示すものではありません

 

リギング・クロスオーバー ~ゲームと映像、それぞれのリグ制作事例

講演者

マーザ・アニメーションプラネット株式会社

デジタル本部 映像制作課

ショットワークチーム マネージャー

赤木 達也

09月02日(水) 18:00 〜 19:00(レギュラーセッション)

cedec.cesa.or.jp

 

今回紹介したセッションで聴講したい!と思ったセッションはありましたか?
多くのゲーム開発者から注目が集まるCEDECは、今年はオンラインで 9月2日(水)~9月4日(金)の間、開催されます。

CEDECに聴講して情報収集や交流をし、ゲーム業界の今を知り、業界の未来について語り合いませんか?
それでは皆さんCEDECでお会いましょう!

 

私達は将来CEDECに登壇してみたいと思っている、技術に興味のある方を求めています。
そんな貴方、以下にアクセスしてみませんか?

recruit.sega.jp

 

※複数社登壇の場合でもセガの社員のみ表記しています 
©SEGA

『D×2 真・女神転生リベレーション』でのビッグバナー画像制作事例

はじめまして。セガ 第4事業部・第4開発1部・TAセクションの村上です。

アーケード向けのゲーム開発におよそ10年間携わった後、現在ではスマートフォン用ゲーム『D×2 真・女神転生リベレーション』(以下、『D×2(ディーツー)』)に3D背景チームリーダー兼テクニカルアーティストとして参加しています。

『D×2』の3D背景制作に携わる一方で、制作工程における技術的なサポートも行っています。 

 

『D×2』は悪魔召喚・交渉・悪魔合体・3Dダンジョンなど『真・女神転生』シリーズが持つ醍醐味を踏襲しつつ、スマートフォン向けとして最適化された戦略バトルRPGです。

2.5周年を記念した「超・感謝祭」キャンペーンとイベントを開催中ですので、ご興味がありましたら公式サイトをご覧ください。

d2-megaten-l.sega.jp

 

『真・女神転生』シリーズとは皆様ご存知の通りアトラスさんが開発・販売されている25年以上の歴史を誇る「荒廃し、悪魔が跋扈する現実世界を舞台としたRPGシリーズ」です。

「メガテン」の愛称のほうが馴染み深いかもしれませんね。弊社の家庭用ゲーム機でもいくつものタイトルが発売されてきました。

 

つい最近「ゲームギア」が発売30周年になることを記念したミクロサイズの「ゲームギアミクロ」が発表されました。

全4色のうちの「レッド」には、なんと『女神転生外伝 ラストバイブル』と『女神転生外伝 ラストバイブルスペシャル』が同梱されます。

今まで上記タイトルをプレイする機会に恵まれなかったため、個人的に発売が待ち遠しいです!

60th.sega.com

 

さて少し時間を戻した2020年2月。『D×2』のファンミーティングが有楽町にて開催されました。

新型コロナウイルス対策にスタッフ一同細心の注意を払った上で、ご応募をいただいた皆様の中から抽選により約100名様にご来場いただきました。

app.famitsu.com

game.watch.impress.co.jp

 

当日会場にサービス2周年記念悪魔である英雄 マサカドと天魔 アスラおうを撮影できるビッグバナー(フォトスポット)をご用意したところ、ファンの皆様には大盛況でした。

この画像の制作工程を紹介したいとの依頼を受けまして、本記事では要点を絞り2部構成にしてお届けします。

前半

  • 画像の拡大変換ツールwaifu2x-caffeの使い方
  • waifu2x-caffeとAdobe Senseiの拡大性能を比較検証

後半

  • 拡大前の元素材画像のメイキング(UnityでのキャプチャーからPhotoshopでのレタッチまで紹介)

 

うーん、少し地味ですかね。知っていてもすぐに役立たない情報もあるかもしれません。

例えるなら弊社「メガドライブミニ」のヘッドホンボリュームは動かせますが、本体の音量は変わらないんです、ぐらい地味な話もあるかもしれません。

faq.sega.jp

 

それでもお1人でも役に立ったと言っていただけるように、作業効率が変わりそうなコツを取り揃えてみました!

前置きはほどほどに、地味~にお付き合いください。

 

 

フォトスポットってなに?

巨大なビッグバナーの前で撮影する場所

当日は『真・女神転生』シリーズの人気悪魔と一緒にファンミーティングの楽しい思い出を残せるフォトスポットができました。このフォトスポットに設置されている巨大な写真のことをビッグバナーと呼びます(スマートフォンでさっと撮影した写真で失礼いたします)。

f:id:sgtech:20200723200211p:plain

英雄 マサカド

f:id:sgtech:20200723200204p:plain

天魔 アスラおう

ビッグバナーの解像度はいくつなのか?

高さ2m、横幅4m

「えっ? 高さ2m? 横は4mもあるの!?」

最初にビッグバナーの大きさを聞いた時はビックリしました。

会場で見た実物は床から天井まで届く、文字通り「ビッグバナー」でした

 
ビッグバナーのスペック
  • 2m x 4m(高さ x 横幅)
  • 布地に印刷 ※ベルクロ(マジックテープ)で箱に貼り付け
  • 入稿はIllustratorフォーマット

 

「画像解像度いくつだろう・・・」と不安が頭をよぎりましたが、問題なく作業するには8K~16K解像度が限界ではないか?と予想しました。

※8K=7,680×4,320ピクセル

※16K=15,360 x 8,460ピクセル

 

印刷の密度表現としてはdpiが一般的ですが、ここではピクセルで考えてみます。

タイミング良くPhotoshopを起動していたので、数値入力欄で計算してみましょう。

f:id:sgtech:20200723200002g:plain

Photoshopの入力欄で数値の計算

例えば横幅を16,000ピクセルで作るとします。

横幅1m辺り約4,000ピクセル、横幅1mmだと約4ピクセルの面積となるでしょうか。

 

撮影対象となる悪魔モデルはビッグバナー画像の中央に大写しに立たせることになっていますので、撮影時のカメラまでの距離を考えるとなんとかなりそうです。

「きっと16Kでも大丈夫!」と自分を納得させることにしました・・・(ドキドキ)。

 

出力する画像解像度は16K

少し適当に決めた解像度に聞こえてしまいますが、それにしても16K・・・本当に大きいです。

拡大しても、拡大してもピクセルが見えない!

ちょっと大げさですが、普段はスマートフォン向けゲーム開発をしているだけにこんな気持ちになりました。

後でdpiを計算すると約100dpiでした。※一般的な印刷物は300〜400dpi。

 

PC用モニターは標準で72dpiなので、標準的なPC用モニターよりは細かくできました(Retinaディスプレイは除く)。16K解像度は結構妥当だったようです。

 

制作する画像解像度は8K

私の普段の業務は『D×2』の3D背景制作と技術サポートです。開発業務と平行してのビッグバナー制作のため、入稿締め切りギリギリのスケジュールでした。

『D×2』はアトラスさんの監修を経てリリースされていますので、監修に必要な営業日と修正にかかる時間も考慮する必要があります。
 
スピーディーなワークフローが求められるため「制作自体は8K解像度で作業し、入稿直前に16K解像度に拡大変換する」方法を選択しました。 
 
印刷される画像解像度を最終的に2倍に拡大することができれば、レタッチ面積を節約できるだろうと考えました。
また作業するPSDファイルサイズは8K解像度で経験上1GB~2GBになります。16K解像度で作業するよりも軽くできますね。
 

拡大変換ってなに?

例えばPhotoshopで画像の解像度を2倍に拡大してみます。おそらく拡大する前よりもボヤ~っとしていませんか?
 
数年前まではPhotoshopで拡大してもそれほど良い結果は得られませんでした。それはバイキュービック法やバイリニア法という簡単な補完方法による変換だったからです。
 
でも当時はそれが当たり前でした。
 
――――当たり前だったのですが、ここ数年のAdobe社の画像テクノロジーへの取り組みは目覚ましく、ついにはAdobe Senseiという新技術が生まれました。
 
現在はPhotoshopでもAIと機械学習によるキレイな拡大変換が可能となっています。
※拡大変換=アップスケーリングとも呼ばれます。
 
AI/機械学習による拡大変換は、縮小画像と解像度の高い元画像のペア(教師データ)を大量に学習した成果を生かして、ただ引き延ばすのではなく、不足情報を補っています。
 
機械学習の説明は、こちらの記事が大変参考になりました。

 

入稿前に拡大変換

waifu2x-caffeとは?

それではビッグバナー制作においては、どのように画像を拡大させたのでしょうか?
 
この流れだとAdobe Senseiを――――Photoshopを使う流れに見えますが・・・違うんです。
これからご紹介するツールwaifu2x-caffeを使用すると簡単に、かつキレイに拡大変換できます!
waifu2x-caffe
  • 画像変換ソフトウェア「waifu2x」のWindows用ツール
  • 「waifu2x」の変換機能のみをCaffeを用いて書き直した

「オレの嫁ね!」と、愛称で呼ばれて既に利用されている方もいらっしゃるかと思います。最近だとスマートフォン向けアプリにリリースされていたり、市販の画像最適化ツールにも搭載されていますね。

 

ゲーム開発の立場で考えると、Windows上で実行できるスタンドアローンツールというのが大変に嬉しいです(外部サーバーに開発データをアップロードするのは問題ありますから)。

 

この素敵なツールは下記からダウンロードして使うことができます。

github.com

 

waifu2x-caffeのダウンロードからインストールまで

Windowsへのインストールもとっても簡単です。

インストール方法
  1. lltcggie/waifu2x-caffeのダウンロードページを開きます。
  2. waifu2x-caffe.zipをクリックして保存します。 ※最新版を選びます

    f:id:sgtech:20200723203707p:plain

  3. ダウンロードしたZIPファイルを右クリック→「すべて展開」します。
  4. waifu2x-caffeフォルダ内のwaifu2x-caffe.exeを実行します。
    ※今回はGUI版を使用しますが、コマンドライン版も用意されています(waifu2x-caffe-cui.exe)。

    f:id:sgtech:20200723203710p:plain

  5. 「WindowsによってPCが保護されました」と警告が表示される場合は、「詳細情報」をクリックすると「実行」ボタンが押せるようになります。

    f:id:sgtech:20200723203715p:plain

  6. ウインドウが立ち上がったら、「cuDNNチェック」ボタンを押します。
    特にエラーがなければ、準備完了です。

    f:id:sgtech:20200723203727p:plain

 cuDNNについて

  • GPUを使って変換を行う(※Compute Capability 3.0 以上のNVIDIA製GPU)
  • 高速に画像変換できる
  • VRAM使用量を減らせる
以前のバージョンでは別途NVIDIAのサイトからdllをダウンロードする必要がありましたが、ver 1.2.0.3より同梱されることになりました。とっても便利になりましたね。

 

エラーが出たら?

もし「cuDNNチェック」で「GPUで変換できません」等のエラーが出た場合は、通常は指示に従いますが、ここではCPU変換にすることで解決してみます。

  1. 動作設定」ボタンを押します。

    f:id:sgtech:20200723203722p:plain

  2. 「使用プロセッサー」を「CPU」へ変更します。
    ※CPUは変換時間が遅くなりますが、確実に動作します。

    f:id:sgtech:20200723203719p:plain

 

便利なカスタマイズ

同じ「動作設定」にある「入力参照時固定フォルダ」 で入力パスを設定できます。起動のたびにデフォルトフォルダから変更するのが面倒になったら、カスタマイズしてみましょう。

f:id:sgtech:20200723203943p:plain

「入力参照時固定フォルダ」で入力パスをカスタマイズ

 

waifu2x-caffeの使い方

設定のポイントは2つだけ

詳しい使い方はフォルダ内の「README」ファイルを読んでいただくとして、今回のビッグバナー制作における設定をご紹介します。

f:id:sgtech:20200723203733p:plain

『D×2』ビッグバナー画像の変換設定

使い方

  1. 入力パスの「参照」ボタンを押して、変換する画像を選択します。
    ※出力パスは自動で設定されます。
  2. 「変換モード」はそのままにします。※「ノイズ除去と拡大」
  3. ノイズ除去レベル」を選びます。※今回は「レベル2」
  4. 「拡大サイズ」を選びます。
  5. モデル」を選びます。※今回は「写真・アニメ(UpPhotoモデル)」
  6. 「実行」ボタンを選んで、変換開始です。 

    f:id:sgtech:20200723203738p:plain

 

このように数クリックで変換できてしまうこともwaifu2x-caffeの魅力ですね。

「実行」ボタンを押してしばらく待つと拡大された画像が作成されます。8Kから16K解像度への拡大もGPU変換なら短い時間で終了します。

 

ノイズ除去レベル

ノイズの具合が、質感に大きく影響している印象があります。ここはしっかり設定したほうが良いですね。

まずは「レベル1」を選んで一度変換し、結果を確認することをオススメします。

「レベル1」の結果を見た上で
  • 質感が失われ過ぎていれば「レベル0」で変換する。
  • ノイズが強ければ「レベル2」で変換する。

適切なレベルを設定することで、さらに良い結果を得られると思います。

 

モデル

ビッグバナー画像では「写真・アニメ(UpPhotoモデル)」を選んでいます。
※「写真・アニメ(Photoモデル)」より高速かつ同等以上の画質で変換できます。

アニメやイラスト系の画像では「2次元イラスト」モデルを選びますが、目的に合わせて「UpRGBモデル」「Yモデル」など最適なモデルを選べると良いですね。

 

結局どれくらいキレイになるの?

「オレの嫁(waifu2x-caffe)」と「アドビ先生(Adobe Sensei)」を比較

ところでどれくらいキレイに拡大変換できるのか、気になりませんか?

そこでwaifu2x-caffeとAdobe Senseiをビッグバナー画像を使って比較してみました。いったいどちらの拡大変換がよりキレイな画像になるのでしょうか? 私も楽しみになってきました。

 Adobe Sensei (Photoshop)
  • 人工知能(AI)とマシンラーニング(機械学習)
  • 「イメージ」→「画像解像度」のダイアログにある再サンプルから「ディテールを保持 2.0」を選ぶ
    ※Photoshop CC 2018からの新機能

 

waifu2x-caffeとAdobe Senseiの検証

ベース画像(8K解像度)はそのままの大きさ、100%表示です。

比較画像(16K解像度)は見やすくするため実際よりも200%拡大表示しています。

それでは英雄 マサカドの口元から比較してみましょう。 

ベース画像

f:id:sgtech:20200723200040p:plain

100%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減0%)

f:id:sgtech:20200723200044p:plain

化粧の質感は残っているが、エッジ処理に問題があり

200%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減50%)

f:id:sgtech:20200723200049p:plain

エッジはスムーズ、化粧の質感はノッペリ

200%表示

waifu2x-caffe

写真・アニメ
(UpPhotoモデル)

ノイズ除去レベル2

f:id:sgtech:20200723200052p:plain

化粧の質感を保ちつつ、エッジをスムーズにするバランスが良い

200%表示

waifu2x-caffeの結果が一番良いですね。Adobe Senseiの挽回なるか?

次は天魔 アスラおうの鎧装飾を比較してみましょう。

ベース画像

f:id:sgtech:20200723200008p:plain

100%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減0%)

f:id:sgtech:20200723200012p:plain

四角いドットが残ったまま

200%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減50%)

f:id:sgtech:20200723200016p:plain

エッジはスムーズ、質感は若干失われた

200%表示

waifu2x-caffe

写真・アニメ
(UpPhotoモデル)

ノイズ除去レベル2

f:id:sgtech:20200723200019p:plain

エッジはスムーズ、質感も問題なし

200%表示

ここでもwaifu2x-caffeの結果が一番妥当ですね。Adobe Sensei頑張って!

 

最後は天魔 アスラおうの背景です。段差のエッジとピンク色の背景との境界を比較してみましょう。

ベース画像

f:id:sgtech:20200723200023p:plain

100%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減0%)

f:id:sgtech:20200723200028p:plain

エッジの輪郭がにじむ

200%表示

Adobe Sensei

ディテールを保持 2.0

(ノイズを軽減50%)

f:id:sgtech:20200723200031p:plain

エッジのにじみは改善、あと一歩

200%表示

waifu2x-caffe

写真・アニメ
(UpPhotoモデル)

ノイズ除去レベル2

f:id:sgtech:20200723200036p:plain

エッジのにじみが一番抑えられている

200%表示

最後もwaifu2x-caffeの結果が一番でした。

 

以上で「口元」「鎧装飾」「背景」の3つの比較が終了しましたが、ビッグバナー画像を元に検証した拡大性能に関しては「オレの嫁」――――waifu2x-caffeとの相性が良い結果となりましたね!

※検証を行ったバージョン:waifu2x-caffe (1.1.8.3)、Adobe Sensei (Photoshop CC 2019)

 

上記検証ではwaifu2x-caffe一択ですが、Adobe Senseiの「ディテールを保持 2.0」が活かせるケースもあります。

例えば「テクスチャーデータを簡単に拡大できる」ところですね。数世代前のゲームを移植する際にテクスチャーがHD化されていないこともあります。

この機能をバッチ処理することで、テクスチャーのHD化を低コストで量産できるかもしれません(弊社内で事例があると聞きました)。

 

「ディテールを保持 2.0」が使えない場合は?

f:id:sgtech:20200723204004p:plain

おかしいぞ? 本来はここにあるはずなのに、選べない場合は・・・

f:id:sgtech:20200723203959p:plain

「ディテールを保持 2.0 アップスケールを有効にする」をオン

(Photoshop CC2018以降であれば)環境設定→「テクノロジープレビュー」の「ディテールを保持 2.0 アップスケールを有効にする」をオンにします。

 

前半まとめ

というわけで前半はビッグバナーの解像度、拡大変換ツールwaifu2x-caffeの紹介、Adobe Senseiとの比較を行いました。ここからは画像を拡大変換する前の「元素材ができあがるまで」のメイキングについてご紹介していきます。

 

メイキング:拡大前の元素材の作成手法

全体のワークフロー

それでは全体の工程を確認していきましょう。 1~5までの工程がありますが、このメイキングでは「1. Unity~」と「2. Photoshop~」にフォーカスした内容となります。

ビッグバナー制作全体ワークフロー 

f:id:sgtech:20200723200218p:plain

  1. Unityでキャプチャーする
    ・8K解像度
  2. Photoshopで作業をする
    ・合成
    ・レタッチ
  3. waifu2x-caffeで画像を拡大する
    ・8K→16Kに拡大変換
  4. Photoshopで入稿用画像を作成する
    ・RGB→CMYK変換
    ・色調補正
  5. Illustratorで入稿データを作成する
    ・印刷業者側から提供されたテンプレートファイルに入稿用画像を読み込む
    ・側面デザインや権利表記等などIllustrator上の作業を行う
 

まずはUnityから

Unityのキャプチャー環境

『D×2』はUnityをゲームエンジンとして採用し、開発が行われています。

悪魔モデルと背景シーンは3Dで作成されているため、Unityでカメラを作成することで色々な角度から悪魔モデルと背景シーンをキャプチャーすることができます。

 

用意するデータは

  1. 悪魔モデル
  2. バトルステージ用の背景シーン ※ゲーム中にロードされる
  3. キャプチャー用のシーン ※ゲームには含まれない

です。

シーン内にどのデータが入っているのかは、リストにして下記にまとめました。

背景シーン(バトルステージ用)

  • 背景モデル
  • (背景内の)バトル開始位置
  • バトル開始位置に付随するフォグやライト等の環境設定
  • 悪魔モデルの質感調整等パラメーター


 
キャプチャー用シーン

  • 悪魔モデル
  • キャプチャー用バトル開始位置
  • キャプチャー用カメラ
  • キャプチャー用ライト

 

シーン内のバトル開始位置と連動して背景環境を変更させる仕組みとなっています。そのため同じ背景シーンでも、バトル開始位置によってはガラリと雰囲気が変化します。

f:id:sgtech:20200723200426g:plain

バトル開始位置を切り替えるとシーンの雰囲気や見た目も変わる

この仕組みを流用してキャプチャーのためのカメラのポジションやライティング環境を作り、キャプチャー用シーン内に保存しています。

マメなセーブデータが大切だ!ということを『真・女神転生』シリーズのザコ敵に全滅させられた経験から学んでいますので、うっかりミスで「あの背景をキャプチャーし忘れた!」と問題が発生しても、すぐ同じ環境を復帰できるように備えています(ああ、当時のトラウマが・・・)。

 

キャプチャー

キャプチャー用カメラのベースはバトル時のカメラと同じなのですが、画面をキャプチャーするコンポーネント(スクリプト)がアタッチされています。

画面のキャプチャーはフリーツールが多数ありますが、『D×2』では独自の描画方式を用いているのでフリーツールや標準機能では正しくキャプチャーできません。そのためキャプチャーツールは独自実装となっています。

 

カメラの背景色ですが「Background」をPhotoshopで抜きやすい色に変更しているだけです・・・横着ですね。背景エフェクトをキャプチャーする場合は「Background」を黒色でキャプチャーしています。

f:id:sgtech:20200723203647p:plain

「Background」カラーを抜きやすい色に変更

 

動きのあるポーズはTimeline機能を使う

特定のポーズでキャプチャーしたい場合では、Timeline機能を使っています。

※Timeline機能=シネマティクスやカットシーンを作ることができる

f:id:sgtech:20200723203953p:plain

Timelineを利用したキャプチャー

Timeline機能を使うとライティング、パーティクルエフェクト発動のタイミングも自由に組み合わせることができます。

「再生開始から◯◯フレーム目のアニメーション」をキャプチャーすることで、同じポーズとカメラアングルを再現しています。 

 

猛将 マサカドのレタッチ画像の制作では、「カメラ」「猛将 マサカドのモデル」「攻撃のアニメーション」をTimeline機能で読み込んでキャプチャーしました。この猛将 マサカドの攻撃アニメーションは何度見ても迫力があってカッコイイですね!

f:id:sgtech:20200723200224p:plain

猛将 マサカド「マサカドチャレンジ」 ※クリックすると大きい画像で表示

 

撮影舞台の紹介

英雄 マサカドのビッグバナー撮影の舞台は専用の「チャレンジクエスト」ステージ(いわゆるボス戦)です。

海上の歌舞伎舞台をイメージしていて、奥には三重塔が英雄 マサカドを見守るように佇んでいます。

f:id:sgtech:20200723200153p:plain

英雄 マサカド専用の「チャレンジクエスト」ステージ

『真・女神転生Ⅲ-NOCTURNE』にマサカド公が登場する場面がありますが、アトラスさんからの提案により篝火と鳥居の要素をオマージュとして取り入れています。

 

ここからはPhotoshop

レタッチの方向性は?

Photoshop上にて、以下のように作業を進めていきます。

背景
  1. 空、遠景、近景、エフェクトの合成
  2. レタッチ
  3. 色調補正
キャラクター
  1. 影とライティングの合成
  2. レタッチ
  3. 色調補正

 

英雄 マサカドは「格式の高さ」、そして天魔 アスラおうは「壮麗さ」をキーワードとして写真に収めた際に格好よく見えるような、写真映えするような方向性となっています。

 

記事ボリュームの都合上、ここでは英雄 マサカドのレタッチ工程を中心に進めていきます。

まずはゲーム画面の背景だけのスクリーンショットを確認してみましょう。

f:id:sgtech:20200723200158p:plain

ゲーム画面の背景スクリーンショット(参考用)

ゲーム中は迫力ある背景だと思ったのですが、スマートフォンのカメラで撮影するにはやや物足りないですね。

 

空を高解像度化

屋外の背景で空が見えているようであれば、空から作業を始めます。

画像全体のトーンを空を見ながら決めやすいですし、光がどのように射し込むかイメージできます。

また、単純に絵としてのクオリティーが上がりやすい印象もあります。

実は空の元画像素材は8K解像度には足りていませんでした。

先程Photoshopでの作業と書きましたが、この空だけは先にwaifu2x-caffeを使って4倍に拡大します。

f:id:sgtech:20200723204013p:plain

異なるノイズ除去レベルで4倍拡大した画像を2枚用意

変換してみるとノイズ除去レベル2ではノイズが残り過ぎ、3だと完全にノッペリしていましたので、この2枚を合成して画質をコントロールすることにしました。

 

もし元画像の地平線が傾いていれば「切り抜きツール」の「画像上に線を引いて画像を角度補正」を使います。

f:id:sgtech:20200723203619p:plain

余白を自動的に補正する設定

自動で傾きを修正してくれるので便利ですね。

f:id:sgtech:20200723203623p:plain

「画像上に線を引いて画像を角度補正」で水平線に沿って線を引く

この時に「切り抜いたピクセルを削除」オフ、「コンテンツに応じる」オンに設定します。

本来であれば傾きを修正すると空白が生まれてしまいますが、Photoshopがいい感じに埋めてくれます。

ポイントになるのは「コンテンツに応じる」という機能です。

 

こうして拡大された空をレイヤーマスクを使ってゲーム中の空に合成していきます。

f:id:sgtech:20200723200057p:plain

ゲーム中の空

f:id:sgtech:20200723200101p:plain

合成した空

空を変えただけですが、ずいぶんと雰囲気が変わります。

 

遠景と画像の切り抜き

ここからは三重塔と橋を合成していきます。

三重塔の画像をPhotoshopで読み込み、塔の形状で抜く作業をしていきます。

f:id:sgtech:20200723203703p:plain

選択範囲から「色域指定」

 

選択範囲メニューから「色域指定」を選んで、抜きたい色を削除するのが一番簡単な方法ですが、フチに1ピクセルほど微妙に色が残る場合がありますので注意が必要です。

f:id:sgtech:20200723203654p:plain

フチに色が残ったケース(極端な例)

f:id:sgtech:20200723203650p:plain

フリンジ削除でフチを削除

レイヤーメニューから「マッティング」→「フリンジ削除」で1ピクセル削ってしまうと安心です。

 

背景だと上記で大抵は問題ないのですが、木々のある背景や複雑な形状のキャラクターでは繰り返し調整可能な「レイヤーマスク」を使う方がより良い結果を得られます。

選択レイヤーに「レイヤーマスク」を追加し、マスクの「属性」にある「色域指定」を使います(「反転ボタン」を押すと選択を逆転できます)。

f:id:sgtech:20200723203658p:plain

レイヤーマスク「属性」の「色域指定」と「選択とマスク」

次に「選択とマスク」を使いながらエッジの処理を調整することができます。※以前のバージョンでは「マスクの境界線」

f:id:sgtech:20200723203743p:plain

「選択とマスク」を使用してエッジを微調整

 

空気感の演出として、レイヤースタイルや修正を加えていきます。

「カラーオーバーレイ」は空気感を演出できる便利な機能ですね。

f:id:sgtech:20200723200318p:plain

三重塔を追加

f:id:sgtech:20200723204034p:plain

レイヤースタイルの「カラーオーバーレイ」を選んで、三重塔に空気感を追加

f:id:sgtech:20200723200323p:plain

フォグと橋を追加して遠景の完成

ゲームからキャプチャーした素材だけでは足りなかったので、雲ブラシでフォグを描き足しました。

 

近景と水面反射

歌舞伎舞台、鳥居を合成していきます。

遠景のレタッチによって鳥居のシルエットがハッキリしました。この状態であればキャラクターを追加しても背景に埋没する心配はいらなさそうです。

f:id:sgtech:20200723200328p:plain

歌舞伎舞台と鳥居を追加

8K解像度ではライトマップの精度が荒い箇所がいくつも見つかりました。またアンビエント・オクルージョンも物足りないと感じたため、地味な作業ですが修正します。

 

歌舞伎舞台中央には水面があります。映り込むと美しさが増しますので、三重塔と空の水面反射を追加していきます。

レイヤーを選択して、フィルターメニューから「スマートフィルター用に変換」します。これでフィルター効果を何度でも修正できるようになりました。

f:id:sgtech:20200723203630p:plain

フィルター→「スマートフィルター用に変換」

 

編集の「自由変形」→「垂直方向に反転」で上下反転させますが、若干タテに伸びるように変形させた後に、フィルター→「ぼかし」→「ぼかし(移動)」を実行します。ぼかし表現をタテ方向(90度)に加えていきます(「距離」はケースバイケースで調整します)。

f:id:sgtech:20200723203626p:plain

フィルター→「ぼかし」→「ぼかし(移動)」で90度のぼかし

f:id:sgtech:20200723203441p:plain

水面反射として三重塔を追加

水面への映り込みは若干暗くなるように「トーンカーブ」で暗めに調整します。

 

次に空の反射を追加しますが、水面がツルッとしてしまいました。

f:id:sgtech:20200723203445p:plain

空の反射も追加

 

手っ取り早く調整する方法として、レイヤースタイルの「ブレンド条件」を使っていきます。

下になっているレイヤー」のスライダーを左右に動かして、ピクセルの明るさを基準にしながら、選択中のレイヤーより下になっているレイヤーを合成します。

f:id:sgtech:20200723203450g:plain

「ブレンド条件」で明るい部分だけの反射を残す

このままだと合成が荒いままなので、一度「Alt(Windows)/Option(Mac)」キーを押しながらスライダーをクリックします。

1つだったスライダーが2つに分割されます。隙間を空けるようにスライダーを移動させると、スムーズに境界が合成されます。

※スライダーは左右両端にありますので、目的に応じて使い分けます。

 

さらにレイヤーマスクを追加して、合成する範囲をコントロールしても良いかもしれません。

f:id:sgtech:20200723200340p:plain

近景の完成

 

エフェクトと色調補正

Unityでエフェクトごとにキャプチャーした画像を基本的には描画モードを「スクリーン」で合成していきます。炎だけ、煙だけと要素に分けてキャプチャーするため、キャプチャー枚数は背景よりもずっと多くなります。

f:id:sgtech:20200723200149p:plain

エフェクトは描画モードを「スクリーン」で合成

f:id:sgtech:20200723200249p:plain

背景の完成
※クリックすると大きい画像で表示

それでも足りないエフェクトはブラシで描き足します。色調補正を重ねて背景の完成です。

 

リテイクに強いゴミを消す方法

少し脱線しますが、フォトバッシュやレタッチ作業をしていると画像から不必要なゴミを消したい場合もあります。

定番というと「スポット修復ブラシツール(修復ブラシツール)」「コピースタンプツール」が思い浮かびますが、今回はCC 2019から追加されたマイナー(?)だけど便利な方法をご紹介したいと思います。

スマートフォンで撮影した実物のビッグバナー写真からエフェクトやシミなどを削除してみます。

f:id:sgtech:20200723203530p:plain

火の粉や鳥、印刷のシミを削除するには・・・

f:id:sgtech:20200723203536p:plain

削除したい範囲を囲み・・・

 

メニューから編集→「コンテンツに応じた塗りつぶし」を選びます。
※CC 2019より以前のバージョンでは編集→塗りつぶし→「コンテンツに応じる」ですが、新規レイヤー作成はできません。

f:id:sgtech:20200723203543p:plain

「新規レイヤー」を選ぶと、修正箇所を別レイヤー化できて便利

 

CC 2019からはプレビューで確認しながら調整できるようになり、出力先として「新規レイヤー」が選べるようになりました。このままデフォルト設定で適用します。※意図した結果にならないケースでは、「サンプリング領域」をブラシで塗り直します。

「サンプリング領域」と選択範囲を調節するだけで結果が変わるため、一気に修正できてリテイクに強い便利な機能となりました。

f:id:sgtech:20200723203547p:plain

囲った箇所を一気に修正

 

一方でブラシのストロークで修正できる「スポット修復ブラシツール」も捨てがたいです。

ああ、元画像を直接修正しない方法があれば・・・スマートオブジェクトでも修正できれば・・・。分かります。

実は「スポット修復ブラシツール」の「コンテンツに応じる」を選んでから「全レイヤーを対象」にチェックを入れることで解決できます。

f:id:sgtech:20200723203616p:plain

「スポット修復ブラシツール」の「全レイヤーを対象」を選ぶ

新規レイヤーを作成すれば、ストロークした修正箇所のみ新しいレイヤーに分けることができます。

 

ここまでポイントなっているのは「コンテンツに応じて◯◯」という機能です。Photoshop CS4からバージョンが上がるごとに対応が増えている機能ですが、こちらで詳しく使い方をフォローされています。

blogs.adobe.com

 

キャラクターのライティング

ここからは背景に英雄 マサカドを立たせて、基本的にはキャラクターのライティング調整を優先していきます。

その理由として悪魔モデルはモデリングと質感のクオリティーが非常に高いレベルにあるため、大きい修正をする必要性を感じられないからです(アトラスさんの監修も通っていますし)。

ちなみに下記画像のポーズは元のイラストのマサカド公を再現しています。イラストと見比べても再現性バッチリで、モデリングチームとアニメーションチームの熱意が伝わってくるかのようです。

向かって左側に立っている英雄 マサカドがゲーム中のリアルタイムライトでキャプチャーした画像です

 

まずは影の調整をしてみましょう。

左側の画像をベースにブラシを使用してアンビエント・オクルージョンを追加していきます。

f:id:sgtech:20200723200304p:plain

ベースのキャプチャー画像(左側)

アンビエント・オクルージョン追加後(右側)

夕日のバックライトに合わせて手のひら、袖の下、洋服の重なり部分、足首周りにしっかりと影を落とします。

 

ここからはラィティングの調整をしていきます。作り込んだモデルの立体感とPBRマテリアルによる繊細な質感をさらに引き出すことを目標とします。

基本はキーライト、フィルライト、バックライト(リムライト)があれば対応できます。顔周りが暗かったり、余計な影が顔に落ちているケースではフェイス用ライトを何個か追加してキャプチャーしておきます。

 

最終的にPhotoshop上で合成するため、Unity上でのライト調整はそこそこで大丈夫です。

1ライトにつき1枚キャプチャーしておくと、調整がしやすくなります。

f:id:sgtech:20200723200308p:plain

フロントライト(左側)、フィルライト(右側)

ベースの画像を1枚目として数えると、フロントライト、フィルライトの追加を行ったので合計3枚キャプチャーしたことになります。

 

意外と少ないキャプチャー枚数なのは屋外だったからかもしれません。もし屋内であれば光源が多数あるケースが多いため、キャプチャー枚数も増えていたでしょう。

以前はMayaでディフューズ、スペキュラーなどレンダリング要素別に出力していたことに比べると、とってもシンプルな手法ですね。

 

英雄 マサカドを取り囲むように篝火が配置してありますので、照り返しを感じられるように「トーンカーブ」を使って色調補正します。

f:id:sgtech:20200723200313p:plain

ベース(左側)、レタッチ完了後(右側)

足元には水面反射と影を追加し、注目される箇所を優先して修正します。

顔は注目度が高いので、瞳や歯の辺りは丁寧に手を入れています(口の中までクッキリと映る解像度なんです)。

 

最後に背景とキャラクターをなじませ、全体のバランスを調整をしてレタッチの完成です。

f:id:sgtech:20200723200238p:plain

英雄 マサカドのビッグバナー完成画像
※クリックすると大きい画像で表示

新生ホーム画面背景にそびえ立つ天魔 アスラおうのビッグバナー画像も上記と似たような工程を経ています。

f:id:sgtech:20200723200138p:plain

天魔 アスラおうのビッグバナー完成画像
※クリックすると大きい画像で表示

この後の作業工程ですが、記事前半でご紹介したwaifu2x-caffeを使った拡大変換へとつながっていきます。ここまで長かったですね・・・長文にお付き合いいただきまして、ありがとうございました!

 

まとめ

というわけで『D×2』ビッグバナー制作事例いかがでしたでしょうか?

  • waifu2x-caffeを使って入稿用画像を拡大変換する。
  • waifu2x-caffeの方がPhotoshop (Adobe Sensei)よりもキレイな拡大結果を得られる可能性がある。
  • Photoshopの「コンテンツに応じる」機能はどんどん使ってみる。

辺りがポイントでした。

ちょっとしたツールの使い方の違いで作業効率が地味に変わることもあります。今回の記事が皆様にご活用いただける内容でしたら幸いです。

 

セガではこのような取り組みに興味のある方を募集しています。もしご興味を持たれましたら下記サイトにアクセスしてみてください。

www.sega.co.jp

 

最後は『真・女神転生』シリーズ定番のセリフでしめたいと思います。

『コンゴトモヨロシク』お願いいたします。

 

©SEGA/©ATLUS

セガ・セガロゴ、ゲームギア、ゲームギアミクロ、メガドライブミニは株式会社セガまたはその関連会社の登録商標または商標です。

記載されている会社名、製品名は、各社の登録商標または商標です。

在宅でチームの働き方改革!!

ごあいさつ

初めまして、株式会社セガ開発技術部の廣島です。

 

今回のBlogでは新型コロナウィルスの感染拡大防止のために弊社で実施されたリモートワークに関して、私達のチームで起きた問題やその問題に対してどう対応したのかを紹介します。 

リモートワークをしてみて、私たちのチームに発生した問題は、コミュニケーションが上手くいかず、チームとしての機能が低下していくことでした。

 

そして、その原因は距離でした。

 

チームの間に物理的な距離ができてしまったことで、雑談のような気軽なコミュニケーションが減り、心の距離までもが遠くなってしまったのです。そしてこれまで何事もなく回っていたチームの歯車が、少しずつ噛み合わなくなっていきました。

 

しかし、リモートワークなので当然、物理的な距離を近づけることはできません。

どうすれば良いのか?何をすればこれまでと同じように上手くチームが回るのか?

そういった試行錯誤をした記録とそこから得た知見を共有したいと思います。

 

どうぞ宜しくお願いします。

対象となる読者

  • リモート環境でチームとして何かに取り組んでいる

  • リモート環境でこれからチームとしての作業に取り組もうとしている 

そういった方たちの活動の参考になれば幸いです。

仕事の内容

前置きになりますが、私達が所属する開発技術部はゲームを開発している部署ではありません。

 Windows上で動作する開発支援ツールの作成や、UnityのPlugin開発などを行い、開発現場を支援しています。

f:id:sgtech:20200614231029p:plain

これは私達が制作している、企画さんやデザイナさん向けのGit のクライアントツール「Pengit」です。過去には第1回 GitHub Enterprise ユーザ会」などでも紹介させていただきました。

 

私達のチームにはエンジニアが4人いて、それぞれがツールを作ったりプラグインの開発をしたりと、2人から4人のチームを組んで仕事をしていました。

 4人が関わっているツール作成のプロジェクトに関しては2週間単位で業務の計画を立て振り返りを行うスタイルで開発をしていました。

 それ以外のプロジェクトではやり方はバラバラで必要になったときに都度情報を共有するスタイルで仕事をしていました。

 ビックリするかもしれませんが会社ではお互い席も近く振り向けばそこにチームメンバーがいる環境だったので、このような進め方でも問題ありませんでした。

 

しかしリモートワークではそう上手くはいかなくなります。が、その話はもう少しあとで紹介します。

 

リモートワーク開始準備  2月の中頃から

リモートワークを始めるにあたって、在宅で何をするのかを上司とすり合わせました。

まず、基礎研究や調査と言った案件は比較的個人でも進めやすいので、これを機に新しい技術を勉強することになりました。

 

リモートワーク期間が短期で終われば新技術の勉強だけで良いですが、問題が長期化することも考え、その場合は在宅でも通常業務を回すという方針を立てました。

 まだこの時点では、出社をする必要があるツールのサポート業務が続いていたため、チーム内で順番に出社する人を決めて週に2日ほど出社する半リモートワーク生活からスタートしました。 

当時はまだ緊急事態宣言も発令されていなかったので、出社している人が数多くいたのを覚えています。

 

リモートワーク開始  3月

リモートワークが始まるといくつか困ることが出てきました。 

毎日チャットで朝会を行っていたのですが、当初は文字のみでコミュニケーションをとっていたため、あまりにも効率が悪かったのです。

  • 一つの議論に多くの時間が掛かる
  • 情報が流れてしまうので、あとから情報を追うのが大変

そこで、文字のみのチャットは止めて音声チャットを導入しました。

f:id:sgtech:20200614231035p:plain

文字のみで行っていた朝会

しかしサポートのために出社しているメンバーは周りにも人が居るため音声によるチャットがしにくいなど、環境の不一致による問題が起こりました。

機材調達もまだだったのでマイクが無い人、音声チャットそのものに抵抗感がある人もいて、全員が気軽に使える状態ではありませんでした。

すると、音声チャットが気軽に使えないことから、あまり大きな問題が無い場合は朝会を短縮もしくは中止してしまうようになりました。それが重なり、徐々にそれぞれのプロジェクトが何をやっているかが見えづらくなっていきました。

これはちょっとマズい状態ですが、この当時はまだ基礎研究や調査が中心だったのでそこまで大きな問題にはなりませんでした。

そうしている間にも、新型コロナウィルスの情勢は一向に良くならず長期化が見込まれたため、4月からは完全にリモートワークへ移行することになりました。

完全リモートワークへ  4月

私たちのチームは4月から完全なリモートワークに移行したのですが、振り返って以下のような問題がありました。

  • 長期間一人で作業をすることで、孤立感が高まっていく

  • 行き詰まったときに解決に以前より時間が掛かる

 

f:id:sgtech:20200614231047p:plain

これは「チーム」としてあまり機能していないことが原因だと考えました。マズいと思い進め方を見直しました。

具体的には以下のように変えました

  1. リモート朝会を毎日やる!

  2. 時間が掛かっても全プロジェクトを対象に行う

  3. 計画、振り返りを1週間単位に見直す、これも全プロジェクトでやる

  4. 雑談も積極的にする

  5. 小さいことでも皆で褒めよう!

不定期になっていた朝会でしたが、全員がリモートワークに移行しマイクも無事到着したので、全プロジェクトを対象に音声チャットでやることにしました。

ダラダラしないようにルールを決めて進めることがポイントです。

朝会で設けたルールは以下のようなものです。

  • 前日の作業内容と今日の予定を事前にチャットに書き込んでおく

  • 共有したいことなども事前にチャットに書き込む

  • 書いた内容を読み上げるのではなく気になったことのみを報告する

  • 司会が順番に発言者を指名する

  • プロジェクトごとの詳細な議論は朝会の終了後にそれぞれ行う

このあたりのルールやWeb会議のノウハウは今や色々なところで紹介されているので、自分達の状況に合ったものを見つけてくると良いと思います。

また情報の共有が終わったあとはそれとなく雑談をするようにしました。時事ネタから技術ネタまで自由に話してOK。もちろん強制ではないので忙しい人は自由に抜けてOKです。

こういう空気はとても大事です、雑談を強制されてもツラいだけですしね。

あまり長時間にならないように、時間に気を付けながら進めることも大切です。

また褒められると嬉しいしハッピーに仕事ができるよね。というわけで、些細なことでも褒めるスタンスで進めていくというルールになりました。 

計画から振り返りの期間を1週間に短縮したのにはいくつか理由があります。

  • 2週間後どうなっているかわからない
  • 2週間分の振り返りをリモートで行うと時間が掛かる
  • プロジェクトに関わりの無い人を長時間拘束してしまう

 などです。

私のチームでは同時に複数のプロジェクトを抱えているという特徴もありこのような理由で期間を短縮しました。

 

ちなみに朝会を含めた私達のチームで行うWeb会議ではカメラはOFFでやっています。

f:id:sgtech:20200614231051p:plain

  • 会議の度に部屋を片付けたくない
  • 服を着替えたくない

など色々な理由があるのですが、Web会議に対する心理的なハードルを少しでも下げたかったのでカメラはOFFで運用しています。

メンドクセと思われたらアウトです。

f:id:sgtech:20200614231041p:plain

私の作業環境

在宅勤務なんだからパジャマで仕事したいと思っている人もいるかもしれません。

ただカメラをONにしたほうが臨場感は出るので、オンライン発表などするときはカメラがあった方が良いですね。

 

最初は時間が掛かって「もう昼じゃん」みたいなこともありましたが、進行の慣れやルールの見直しによって良い感じに進むようになってきました。

こりゃ駄目だなと思ったら柔軟にルールを変え改善していくことが大事です。

ルールの見直しの一例

例えば当初は各プロジェクトに対して一人ひとり発言していたのですが、関わりの無い人には無駄な時間なのでプロジェクトごとの確認は行わないようになりました。
その代わり各プロジェクトのリーダーが事前にプロジェクトの状況をチェックして問題がありそうであれば共有をするスタイルに変わりました。

発言に関しても、初めの頃は何か意見はありますかと呼びかけていましたが、これを司会が指名する方式に変更しました。
これは発言が被ることの防止や、会議の時間短縮に役立っています。

気軽に相談や質問ができる環境を作る

雑談や相談は非常に重要で、何か上手くいかない問題があった場合も誰かに相談した途端に解決することは良くあります。

雑談や相談がリモートではやりにくかったので、積極的に音声で質問や相談を行えるようにルールを作りました。

ルールと言っても話は単純で、事前にチャットで聞くだけです。

「今ちょっと良いですか?」

「5分待ってください」

「わかりました、待ちます」

みたいなやり取りをするだけです。

数回チャットでやり取りをしても解決しなければ音声チャットに移るルールも作りました。

f:id:sgtech:20200614231055p:plain

時間が掛かりそうだと思ったらすぐに音声チャットへ

こんな簡単なやり取りですがチームで意識を合わせることでお互いに相談して良いんだ、質問して良いんだという雰囲気ができました。

チャットでのやり取りに関しては、以下のことに気を付けようとチームで共有しました。

  • 対面の会話より意図が伝わりにくいので、質問するときは前提条件などを丁寧に書こう
  • 対面の会話より感情が伝わり辛いので指摘等はきつくならないよう・誤解を招かないように表記に注意を払おう
  • いいね 等のエモーションを多く使おう

雑談に関しては、雑談専用のチャットルームを作ったり、お昼休みに行うフリーインフリーアウトのビデオチャットルームを作るなどして交流していました。

結果どうだったか

毎日朝会を音声チャットでやることで心理的な負担や孤独感を軽くすることができ、音声チャットへの抵抗感も段々と軽減されていきました。

また各プロジェクトの状況もきちんと把握できるようになりました。

相談を積極的に行えるようなルール作り雰囲気作りによって相談や質問の頻度は格段に上がりました。

相手を褒める姿勢は計画の振り返りの際に、メンバーのファインプレーを挙げたり、フォローされて助かったことなどを相手に伝える行動に繋がりました。

リモートワーク開始当初に比べてチームとして機能するようになったと実感しています。

 

以下は週に一度行う振り返りの様子です。振り返りはKPT(Keep・Problem・Try)方式で行っています。継続したい良かったこと、抱えている問題、トライする項目を書き出し共有する方式です。

コミュニケーションに関してはポジティブな意見が多く出ていることがわかります。

f:id:sgtech:20200614231024p:plain

カンバンを使ったKPT方式の振り返りの様子

まとめ

チームで仕事をする上での強みは相互に補強できることにあると思っています。
チームが上手く回っていないときにそれを妨げている要因は何なのかを見極めることが重要です。

それぞれチームによって事情は違うと思いますが、私達の問題はコミュニケーションにあったので、コミュニケーションを改善することに力を入れました。

  • 仕事のやり方、進め方を変える
  • Web会議への心理的なハードルを下げる
  • 機材を調達する(マイクが無いと音声チャットは厳しい)
  • 当たり前のことでもルールとして周知する
  • チャットでのやり取りで気を付ける点を共有する

こうすることでリモートワークの良いところをそのままに、悪いところを解消できたのではないかと思います。

今後も状況は変わっていくと思いますが、問題を見極めチームの力が発揮できるように頑張っていきます。

 

セガではより良いチームを目指し、一緒に働いてくれる方を募集しています。

興味がある方は下記サイトにアクセスして下さい。

 

 

www.sega.co.jp

 

Powered by はてなブログ