「世界に、一番のワクワクを届ける」という理念を掲げ、今も世界中がワクワクするコンテンツを生み出し続けている『f4samurai』。そんな『f4samurai』のネイティブエンジニア兼マネージャーを務めている齊藤清司氏に、新設されたグラフィック特化のネイティブチームについてお聞きした。チーム設立の経緯や、現在積極的に募集を行っているネイティブエンジニアについて、そして今後の展望なども詳しくお聞きしてきたので、ぜひチェックして見て欲しい。
テクニカルアーティストチーム新設のキッカケ！専門性を活かして作業クオリティ向上を図る
ーーグラフィック特化のネイティブエンジニアチーム設立に至った経緯を教えていただけますか。
齊藤清司氏（以下、齊藤氏）：グラフィックと言うと少し語弊があり、厳密に言うと表現、演出に対しての要求に応えると言うのと、その実現の為に必要なワークフローに対する要求にも応えるチームとなっています。
なので、確かにグラフィック的な用件も含まれているのですが、もう少し広義の意味を持つチームになってます。
ーーチームとして動く幅を限定したという事でしょうか？
齊藤氏：そうですね。最近のモバイルゲームの開発の流れとして、どんどんネイティブエンジニアが担う業務領域みたいなのが拡大化している上に、各領域に対して求められる品質も高まっているんですよ。
そうなってくると、これまで当社内にあったネイティブエンジニアという枠組みだけだと全てに対応しきれていないという自覚があって、そこを問題として抱えていました。で、特に先ほど話した「表現や演出」、そして「その実現の為のワークフローに対する要求」の2つに対して問題意識を持っていました。
他にも様々な要求がありまして、色んな領域がある中で優先度をつけて対応していく中で、その優先度をつけるのに大きく働く力みたいなものが2つありまして。
1つ目はシステム的な機能要件を満たすところ、これは必須ですね。それに加えて、品質も重要になります。しっかりとしたシステムがなければ、そもそもアプリやゲームとしてのスタートラインにも立てていないですから、より高い水準が求められる部分です。
ーー実際に動かせないとゲームやアプリとして成立しませんからね…
齊藤氏：そうなんですよ。インゲームがないとかアウトゲームがないとか、それはあり得ない事なので、絶対完遂しなければいけない部分なんですよね。そして品質の面では、例えば起動時間やローディングがとても長いとか、ダウンロードが遅いとか、そう言うのはやはりユーザーのプレイ感にダイレクトに直結しますから。
他にも開発環境のシステムが停止してメンテナンスが開けられない、時間が伸びちゃうとか。そもそもサービス開始が出来ないというのは絶対許されません。だからこそ、機能要件に対しては高い数字や品質が求められ、妥協が許されない部分です。
要するに、ユーザーに不利益が出てしまう部分は最優先で対応しなければならないと言うのが1つ目の力になります。
ーーユーザーがあってこそのゲームやアプリですから、使用感に対する要件は優先度を高く設定されているんですね！
齊藤氏：次に2つ目です。表現や演出って色んなプロジェクトがある中で、それぞれ要求水準が違います。ここに対しては業界一番を目指している会社でもありませんし、そういったプロジェクトのみという事もなので、このプロジェクトならこれくらいの水準とクオリティでいいよね、みたいな。一方で他のプロジェクトはもう少し高い水準とクオリティで、とかもあったりするわけです。
そうなると実現フローや開発の工程が、複雑化するという事もあります。その複雑さを解消する為にも、エンジニアがワークフローの構築や最適化を行うようにしてます。
これらはネイティブエンジニアが行っている事ですが、それ自体が大規模なシステム開発のような感じになってしまいます。アセットとか開発のワークフローみたいなものは、それ自体がシステムみたいなもので大規模化もしてしまうし、そうなると作るのも大変だという感じで。使いこなすのも大変ですし（笑）。
ーー聞いただけでも大変そうで…
齊藤氏：そのため、表現や演出面は「本当はここまでやりたいんだけど…」と思っても工数を考えると少し抑えなきゃいけないとなってしまいます。現実的に考えて、そんなに時間はかけられないとなります。
ーーユーザーのプレイ感の向上と比べると、どうしても工数が割き辛いですからね
齊藤氏：ネイティブエンジニアという職種として全ての領域に対応している限り、この2つの力を軸として優先度をつけていくと、やはりシステムの方が優先されてしまうんですよね。ここに問題意識を持っています。
どうすれば解決できるのかを考えたところ、この2つの力の影響を受けないチームを作ればいいんじゃないかと。そのワークフローにだけ向き合うチームを作らなければいけないと思いました。
弊社では新しいセクションと呼んでいますが、セクションを立ち上げようという事になりました。どういう枠組みにしようかと考えていたところで、組織図的な兼ね合いもありネイティブチームを2つに分けようという話になりました。
今までのシステム寄りのチームの事を『ネイティブエンジニアⅠ』、表現・演出とそのワークフローを実現にだけ向き合うチームを『ネイティブエンジニアⅡ』と呼ぶ形にしました。今後新たな体制で開発業務を進めていくなかで、より適したチーム名称を考えていきたいと思っています。
ーーありがとうございます！実際にネイティブエンジニアチームを2つに分けた事で今後の課題も出てきたと存じますが、そちらについてお聞きしてもよろしいでしょうか。
齊藤氏：ネイティブエンジニアⅡで言いますと、まだ出来たばかりのチームという事もあって、実際の業務フローに大きな変化を与えられる状況ではないと思ってます。後は、「チームが2つに分かれたけど実際には何をするの？」といった社内の認識も全然足りておらず、その辺りを少しずつ広げていく必要があることを課題として持っています。
会社によってテクニカルアーティストの定義も結構異なります。そのため、f4samuraiだからこそのネイティブチーム像を作り、その認知を広げていく必要があると考えています。
ーー社内での認知拡大が目下の課題というわけですね。その課題解決に向けて、どういったアプローチをされていますか？
齊藤氏：解決に向けてのイメージは、表現を担うチームなのでアーティストやデザイナー、そういう方と協業が必要な領域に対してのアプローチが必要です。その中でも小さな領域から少しずつ始めて「こういう感じで改善してくれるんだ」とか「こういう風に関わっていけばいいんだ」みたいな、認識の角度を少しずつ高めていけるように動いています。
ネイティブエンジニアを積極募集！主な業務内容や今後のチーム体制に迫る
ーー今後ネイティブエンジニアⅡ（テクニカルアーティスト）チームとしては、どのような業務を行なっていくのでしょうか。
齊藤氏：役割としては、先ほど話をしたことをまとめると、アート視点での機能開発、ワークフロー改善、ツール開発や技術サポートになります。具体的な開発対象や業務内容で言うと、アプリ内でのグラフィック表現とか描画パイプラインの設計、グラフィックに関する性能改善等、こういう表現をしたい！という要望の実現というところになります。
後は、デザイナーが触っているMayaだったりSpineだったりの、ツールのワークフローの改善もですね。弊社だとゲームエンジンとしてUnityを使う事が多いんですけど、DCCツールからUnityに入ってくるフローっていうのがあるのですが、そこのワークフローの改善も行います。
そのインポートされたアセットを使って、ランタイムとしてのアセットの制御基盤みたいなところ、ゲームとして動かすための実装部分のところですね、その辺りを行っていくチームを担ってます。
ーーありがとうございます！業務に関わる上で、UnityだったりMayaだったりと、必要な知識が多く難しそうなイメージを抱いたのですが、チームとしてのアサインの基準とかってあるのでしょうか？
齊藤氏：そうですね、関わる領域が多い分必要となる知識が多岐に渡ります。業務領域全体で言うと、本当にとても広いです。「普通はそこまで触らないよね」というところまで知らなきゃいけない世界だと思うんですけど、それを全員に対して求めると言うのは流石に難しいとは思っています。
その辺りはチーム単位でカバー出来ればと思っています。まずは、自分が活躍できる得意な領域だったり強みが1つでもあるのが理想的です。出来ない領域は新たに採用だったり育成だったり、適宜補強をしていくみたいなイメージをしています。
ーー個人の得意な領域を把握して、チームの補強したい部分を軸と照らし合わせてアサインを決められている感じなんですね！
齊藤氏：そうですね！
ーーありがとうございます！次の質問なんですけど、ネイティブチームとしては今後どのような体制を敷いて、どんな組織に成長していこうというビジョンをお持ちでしょうか。
齊藤氏：まず現在の体制としては、元々ネイティブⅠでマネージャーをしてた自分がそのままネイティブⅡも兼務する状態になっています。そのため、ネイティブⅡの専属メンバーは少数です。
今後の目標としては、各プロジェクトのネイティブⅡには2人から4人、大体4人ぐらいまでは配属させたいと考えており、全体で言うと10名程度を目標にしています。
ーー本当に少数精鋭を想定されているんですね。
齊藤氏：はい、その上でどのような組織の成長を目指すかと申しますと、先ほどお伝えした業務を遂行していくというのが一つと、少し未来のことをお話しすると、表現に対するクオリティラインの工程にも関わる事を想定しています。
業務を進めていく上で何となく「これくらいがいいかな」という、いつの間にか決まってるクオリティラインがあります。
何となくではなく、「このチームならこれくらいのクオリティは出せます」という一定のクオリティラインを何パターンか用意しておいて、それを社内やパブリッシャーに提案できるようになればもっと良いと考えています。そのクオリティラインの模索の行程にも関わることを目指しています。
ーー指標となるクオリティラインがあれば会社やパブリッシャーとしても提案をしやすいですよね、ありがとうございます！
ーー続いての質問は先ほどと少し重複した内容とはなるんですけど、ネイティブエンジニア全体としての業務内容について詳しく伺ってもよろしいでしょうか。
齊藤氏：分かりました、ではネイティブⅠの説明からです。こちらの役割としてはエンジニア視点でのアプリケーション機能基盤全般や非ランタイムの開発です。非ランタイムというのは、アプリが動く手前の部分とか、その開発環境の事です。
後は、コーディング環境だったりエラーハンドリング、これはエンジニアがコードを書く上での環境の構築みたいなところですね、そういうところも担っています。それとシステム的な機能で言うと、プッシュ通知、課金機能だったり、KPIや広告のSDKの組み込み等の機能開発にも携わってます。
更に踏み込んで言うと、アドベンチャーの再生制御です。後はインゲーム、ランタイムで機能を動かすためのアセットのレギュレーションの決定みたいな部分もですね。
ーー本当に請け負う業務の幅が広いというか…
齊藤氏：まだありますよ（笑）。パフォーマンス要件をどこにするかの決定等も含まれています。後は先ほど申し上げた非ランタイム部分で言うと、開発環境自体の構築からどういう環境でエンジニアがコードを変えたり実装していくかという部分も考えてます。
それと、弊社がよく使うゲームエンジンであるUnityについてもです。作業を行なっているとデザイナー以外にも、プランナーが触ることもあるので、エンジニア以外の方でも開発環境に触れるための環境構築を行います。構築のみならず、保守の部分も担当しています。
ここは少々悩みましたが、シナリオのスクリプトの開発ワークフローもネイティブⅠが担っています。表現、演出とも少し異なるというところで、元々持っていたということもあり、ここはネイティブⅠの持ち分にしようと決めました。
ーー開発環境の開発や保守を請け負っているんですね。となると、ネイティブⅡはどんな業務を…？
齊藤氏：ネイティブⅡは先ほどお伝えした業務内容の詳細な部分になりますが、シェーダーの実装、ライティング制御、他にはポストプロセスの制御やレンダリングパイプラインの設計になります。
他にもキャラクターやアニメーション、背景やカメラなどの表現や演出に関する部分の制御全般に携わっています。アセットの開発ワークフローの場合、アーティストに対する技術的なサポートや、質問を受けたり、トラブルシューティングの側面も担っています。
後は、作業の自動化を図ることもあります。毎回手動で設定すると時間がかかってしまうため、できる部分は自動化して効率化を行っています。ここはどういう値を設定して、どのような設定をするべきか、どうしても手を加えなければならない部分のワークフローを構築して、作業を効率化できるように動いてます。
ーー確かにネイティブⅡはアーティストとのコミュニケーションが大事になりそうですね
齊藤氏：そうなりますね。そして、こちらが重要な部分になるのですが、パフォーマンス要件も請け負ってます。これはネイティブⅠにでもあるところで、こちらはその表現、演出に対するパフォーマンス負荷の計測だったり、レギュレーション上これぐらいの負荷に収めるために、テクスチャーサイズの制御をかけたり、最適化や、そもそもその負荷や最適化をどう解析していくのかを分析したりしています。
大事なのはホスピタリティ！チームメンバーに寄り添い作業を効率化
ーー続いての質問なんですけど、御社が求めるネイティブエンジニアの人物像を教えていただけますか。
齊藤氏：はい、これも先ほどと同じくネイティブⅠとⅡで分けてお話しします。まず、ネイティブⅠはクライアント側の機能開発、不具合修正、改善だけではなく開発環境の構築、改善だったり、デプロイの自動化だったりツール開発、プロファイリング最適化だったりと、とにかく請け負う業務の幅が広いです。
表現、演出こそネイティブⅡに任せることにはなったものの、まだまだ幅広い技術に触れる必要があります。本当にゲームを作る以外の部分が大きく、システム的な部分が大部分を占めています。そのため、ゲーム作りを学校で学びました！と入ってきて、ゲームの花形みたいなところを作れると思ったら、それ以外の仕事もとても多いことが実態です。そこにギャップがあるかもしれません。
ギャップはあったとしても、ネイティブエンジニアは、サーバーとかLinuxとか、シェルやバッチ等、それらの知識は必要になりますし、使いこなさなければいけないです。そのため、そういった自分が知らない領域に対しても、フットワーク軽く挑戦ができるような人が良いと思っています。
ーー入社前の成果よりも、入社後の立ち振る舞い的な部分を重視されているんですね。
齊藤氏：扱うプロジェクトによって必要となる技術が変わりますからね、挑戦する気持ちは大切です。後は、会社とかチームとか、ユーザーに向けて届けたい価値をベースに物事を判断できる方でしょうか。
新しい技術で何ができるだろうかと考えるのではなく、こういう課題に対して「それならこういう技術で解決できる」のような考え方です。課題や問題を解決するためにエンジニアリングを使うという考えをベースとして持っていてほしいです。加えて、業務で得た知見をちゃんと周りに還元できる人ですね。
ーー思いやりを持って効率化を図る、という事ですね。ありがとうございます！
齊藤氏：次はネイティブⅡの方ですね、こっちはプログラミングだけじゃなくて、クリエイティブ全般の知識に興味を持ってて、その制作作業や開発作業の意図を理解する姿勢がある方。後はアーティストの行っているワークフローを実際に自分でも試してみて、どんなところに苦労とか痛みがあるのか、そこを理解しようという姿勢があると良いですね。
実際にそのワークフローを改善したいって思い、気持ちみたいな部分です。それらをひっくるめてホスピタリティと捉えているのですが、実際に自分も同じ作業をこなしてどこで苦労するのかを知って「これをどうにかしてあげたい」というような、寄り添う気持ちが一番大切だと考えています。
ーーありがとうございます！話を聞いている感じだと、ネイティブチーム全般として密接なコミュニケーションや色んな職種の知識が必要だったり。かなり難易度的に高いと思うんですけど、その辺りは組織としてどう対処していくのでしょうか。
齊藤氏：そうですね…やはり、どの職種においても仕事をする上ではコミュニケーションは欠かせなくて、そこに対する不確実性みたいな問題は絶対にあります。特にネイティブエンジニアは関わるセクションが多いため、その問題は発生しやすいと感じています。
そこに対しては、開発におけるフローやレギュレーションのマニュアル化、ドキュメント化や自動化を進めて対処をしていきたいです。口頭でやり取りするだけでなく、後から入社してきた方や、忘れてしまった方も見返せるようにしてます。
そもそも自動化されていたら別に分からなくても何とかなる部分もありますし、そういうところで対処をしています。入力ミスや操作ミスは人間が行う以上は問題がついて回るため、要所でデータのバリデーションをかけたり、そもそもその手入力みたいなのを極力無くして、自動化するようにしています。
ーー組織と個人、どちらにも配慮した自動化を進められているんですね
齊藤氏：いかにミスを無くせるかという部分にも繋がりますからね。後は、万が一システムの穴を抜けてしまった場合のミスの被害が最小限になるように、不具合をなるべく早くに検知できるようにしたり、復旧できるように可能な限りシステムの永続化を進めていきます。既に壊れたら取り返しがつかない状況は無くしていますし、不具合も検知するようになっています。
そういったコミュニケーションの問題をコミュニケーションで開発、と言うのは無理があるので、本当に自動化、システム化、マニュアル化を行いサポートをしています。
ーーありがとうございます！それで言いますと、今後チームが大きくなった際に、自動化した上でもやっぱりコミュニケーションが必要な部分は出てくると思うんですけど、そこに対して組織として計画している催しやサポート制度があったりするのでしょうか。
齊藤氏：そうですね、これは会社としてですが、プロジェクト毎に毎月懇親会が開催されています。後はセクション単位で月に1回交流だったり情報交換目的の、セクション会があります。この2つは会社が費用を負担している催しです。
それ以外は、例として人事が入社された方に対してオンボーディングを実施しています。新たに入社された方が業務内容だったり役割だったり、ルールとか文化的なところですね。早く会社に馴染めるように会社全体として動いてくれています。
後はネイティブチームとして同様に、オンボーディングを行っています。実際にプロジェクトで必要となる知識をまとめており、「ここは押さえておきましょう」等です。「最初の一ヶ月はこういうところの知識を拾っていきましょう」とか、「三ヶ月くらい経ったらこれぐらいまでの知識が身についているといいですね」というような入社された方がよく困りがちな部分は事前にまとめておいて、アドバイスとして情報共有を行っています。
目指すは個ではなく組織として戦える集団
ーーネイティブチームにおける今後の方針や風土について、お伝えできる範囲で教えていただけますか。
齊藤氏：そうですね、ではまずはネイティブⅠからなんですけど、ネイティブⅡの設立で業務を分割、細分化した恩恵を活かしていきたいと考えていて、今までよりも2、3段階高いレベルで非機能な要求に応えられるようにしたいです。
具体的にお話しすると、アプリや、その開発環境だったりのどちらもなのですが、それらに対する安定性や構築の容易性、実行速度や障害検知復旧速度みたいな点です。そういった非機能要件に対して、高いレベルで応えられることを目指しています。
ーーネイティブチームとして細分化した分、それぞれが請け負う領域に割けるリソースが増えたら、その分をクオリティ向上に当てようという感じなんですね。
齊藤氏：そうですね、ネイティブⅠは元からあるチームのため、クオリティの向上が目下の課題になります。
次はネイティブⅡですね。先ほどの話をまとめると、まずは社内の認知を広げていくことからです。社内、社外に情報発信を行ない、まずは知ってもらうところから始めています。そして、次のステップである程度の認知と人員が確保できたら、業務領域を広げていき、組織的かつ戦略的にネイティブⅡの業務に取り組めるようになることを目指しています。
更に次のステップは「これくらいのリソースがあったらこれくらいの品質を目指せます」という、クオリティラインを何パターンにも分けて提案できる組織作りに貢献したい。その後は実際のディレクションやゲーム全体のアートディレクション、クオリティラインの決定みたいなところにも関わっていければなと。そういうイメージを持っています。
ーーありがとうございます！ではネイティブチームとして、今後のどのようなバリュー（行動指針）を持って業務に取り組んでいくのでしょうか。
齊藤氏：これに関しては、実はネイティブチームとしてはあまり無く、エンジニアチームとしてはあるという回答です。サーバー、フロントという他のエンジニアチームのセクションがあり、それらを含めたエンジニア組織として掲げてるミッションとかバリューがあるため、それを話します。
1つ目は技術は目的ではなく手段にあるところです。これは先ほど話した部分と近いです。技術は問題解決の手段であって、その導入には納得できる理由が必要という考え方です。この技術を使いたいから、新しいからは理由としては不十分です。最新技術を追い求めるのは重要ですが、シーズ志向とニーズ志向のバランスが大切だと考えてます。
次が2つ目なんですけど、理解されてこその成果だと考えています。どんなに優れた技術を使っても、他人に理解されなかったら価値が無いと考えています。だからこそ、エンジニアだったら誰でも分かるように説明する能力を持つべきだと思っています。
3つ目が効率的かつ戦略的な怠惰のようなところだと考えています。エンジニアリングは省力化の学問であって、無駄を省いて効率化を追求することが重要です。後は繰り返しの作業や時間効率を重視して、短時間で成果を最大化する思考を求めてます。大きく分けてこの3つになりますね。
ーーありがとうございます！続いての質問なんですけど、ネイティブチームとしてどのような組織風土を根付かせていこうと考えていますか。
齊藤氏：ネイティブチームのみの組織風土は模索中です。そのため、明確にあるエンジニアチームの組織風土を説明いたします。
これは「エンジニア全員が個人では無く、組織で戦えるエンジニア集団になる」ということをビジョンとして掲げています。これの意味するところは、特定の個人に依存するのではなく、組織として知識を蓄えて、組織としての開発の再現性を高めていきたいという意味になっています。
ある仕事に対して「これはその人だからこそできた」みたいな仕事があると思うんですけど、それを評価するだけじゃなくて、同じことできる人を増やしたり、他の人ができるような環境を作ることをより評価する組織にしたいです。
で、SECI（セキ）モデルという言葉があるんですけど、それを推進したいです。暗黙知と形式知っていう知識のカテゴリーがあるんですけど、そこの変換サイクルみたいなのを通じて、組織としての常識レベルを引き上げたいなと思ってます。
ーーありがとうございます！それは先ほどおっしゃっていたホスピタリティという言葉に通ずるものがありますね。
ーーそれでは最後の質問になるんですけど、同じ目的に向けて業務を行うチームメンバーに持って欲しいと思う思考プロセスや価値観はございますでしょうか。
齊藤氏：そうですね、これは完全に僕個人の気持ちみたいなところにはなりますが、技術的な課題だけではなく、その開発におけるプロセスやワークフロー、組織的な課題にある不確実性や、技術以外の問題に対しても立ち向かえるようになって欲しいというのは一つあります。
もう一つは、「誰にどんな価値を届けたいか」ということから物事を考えるようにして欲しいです。それを考える時に前提の文脈を正しく知るところから入るべきで、どういうフローになっていて、何を達成したいか、何を解決したいと思っているのかを理解するところから始めることです。
そして、その上で前提を疑う。それは本当なのか？という点から疑う必要があり、そのフロー自体を変えたほうがいいのでは無いかという話も時には出ます。こういった前提を疑う姿勢みたいなものは持っていて欲しいです。その上で、変数と定数を区別して考えて欲しいです。ここは絶対変えられないんだ！という点と、「ここは実は変えてもいいんじゃない？」という点です。
これも前提を疑うということに近いかもしれないですが、そういう変数と定数が何なのかを区別して物事をジャッジして欲しいと思ってます。
次が最後になるんですけど、自分にしかできないことは極力無くす、無くそうとして欲しいというところですね。知識の共有だったり自動化みたいなところだったり、そういう価値観は持っていて欲しいなと思っています。
ーー本日はお忙しい中、ありがとうございました！
『株式会社f4samurai』の概要
©f4samurai, Inc. All Rights Reserved.
[取材協力：株式会社f4samurai]
（編集・執筆／ふうた）
