リードエンジニアが語る、Unity開発環境と組織体制の裏側とは。

Graffityでの開発環境や工程、タスク管理や連携方法などの組織体制についてリードエンジニアの寺林 一旭が回答。手厚いコードレビューや勉強会、「ヘドアビ会」で進捗共有と困りごとの相談をしやすい環境をつくることなど、Graffityの開発チームが大切にしていることも紹介します。

寺林 一旭
専門学校卒業後、株式会社サイバーエージェントに入社し、ゲーム事業部でソーシャルゲームやARアプリの開発に携わる。ARという新しい領域に挑戦してみたいという思いから、2020年3月にGraffity株式会社に入社。

技術スタックや開発手順などUnityの開発環境と、手厚いコードレビュー文化について

開発に利用している技術スタックやツールを教えてください
技術スタックに関して全社的にを使っているものはUniRxとUniTaskです。あとは、最近だとプロジェクトによってVContainerやgRPCなども利用します。また、ARアプリ開発系だと、Unityが提供しているAR Foundationも使います。
同じものを使い続けるというよりは、比較的新しいものを使いますね。最近出たUniRxの後継ライブラリであるR3もプロジェクトに使ってみたいと思っています。

どのような開発手順や工程で進めていますか？
基本的にプロジェクトごとにチームで開発しています。現在プロジェクトに関わるUnityエンジニアは、Graffity社内の人間が6人、業務委託契約など社外の方が4人で、1人のエンジニアが複数プロジェクトを兼務することもよくあります。

開発手順としては、仕様書についてエンジニア側から意見を出して、納得した上で形にしていくということが多いですね。エンジニアが企画側に意見を出して仕様が変わることや、開発していくなかで作ってできたものを企画側に早い段階で触ってもらい「より良くするにはどうするか？」と意見交換をしながら進めています。
R&Dのプロジェクトだと、企画もデザインも入れずに、ほぼエンジニアだけでいろいろ調査・実験をやっている感じですね。

開発手順や工程で、意識していることはありますか？
プロジェクトを進行している際に、デザイナーサイドじゃないと気付けない観点やプランナーサイドじゃないと気付けない観点があると思います。同じようにエンジニアも、実際に手を動かす作業者側じゃないと気付けない観点がある。それに早めに気づいて、意見を出すなどコミュニケーションを取るようにしています。

どのようなテストや評価を行っていますか？
基本的にはコードレビューをやるようにしています。
PullRequestを作成した際に、そのコードがコンパイルエラーを起こしてないか自動でチェックしています。その上で、不具合の可能性の指摘はもちろんですが、「こう書いたほうが処理時間が早くなるよ」「このほうがパフォーマンスがあがるよ」など、なぜそうしているかという質問・解説も活発に行われています。スタートアップでここまでコードレビューに時間を割いているところは少ないと思います。

サーバーやインフラ周りの技術スタックについて教えてください
サーバーサイドで使っているのはRubyとGoを主に使っていて、インフラ周りではAmazonWebService（AWS）でクラウドにサーバーを構築しています。
いまはAWSがメインですが、ひとつに限らず複数知っているほうが今後のためになるので、社内で使う内製ツールにGoogleCloudPlatform (GCP）など、AWS以外のものを使うこともあります。

活発な技術発信と、エンジニアの興味関心を刺激する勉強会

Graffityのエンジニア組織のカルチャーとは？
プロジェクトで得た知見や情報、技術などを会社内で共有することはもちろん、社外にも技術発信するようにしています。「Graffityはこういう技術やノウハウがあります！」というのを、PRも兼ねてパブリックに公開していこうという考えです。現在は「qiita (キータ)」というエンジニア向けの記事投稿サイトで、70記事以上の投稿をしています。コメントや閲覧数も伸びていて、外部ツールの製作者の方からSNSでリアクションをもらうなど、良い反応もいただいております。そういった技術ブログの投稿以外にも、オンラインやオフラインのイベントに登壇することもあります。

会社全体の施策として、プログラミング言語や設計思想などの勉強会を実施しています。現在は毎週金曜日の夕方4時から1時間、業務時間内に時間を確保しています。
去年は、半年から1年ほどかけてPythonの勉強会をやっていました。サーバーサイドとクライアントサイドで共通する言語がなかったので、共通言語のような形になると考えて実施しました。その結果、社内の掃除当番や勉強会のテーマを提案する人を指定するSlackのbotをPythonで書くなど、エンジニアがツールを開発しやすい環境になりました。
ほかにも、ブラウザ上にコンピュータグラフィックスを表示させる「Babylon.js」というライブラリがが話題になったときには、その勉強会をやってみたこともあります。エンジニアの勉強会はそれぞれのやりたいことをベースに、みんなの知らないことをやっています。

開発チームのコミュニケーションや組織体制、「ヘドアビ会」で進捗共有と相談を密に

開発チームはプロジェクトごとにどのようなメンバーや役割分担で構成されていますか？
プロジェクトによってさまざまですが、例えばいまやっているプロジェクトだとエンジニア6人、デザイナー4人、PMが2人という体制です。基本的にエンジニアが2〜3人で、
少数精鋭という形です。今後は新しいプロジェクトも増えていきますし、現行のプロジェクトもアップデート、さらに会社としてはApple Vision Pro向けのアプリ開発にリソースを割きたいと考えているので、エンジニアはどんどん増えていってほしいですね。

開発チームはどのようなコミュニケーションや連携をとっていますか？
チーム内では基本的にはSlackなどのチャットでやりとりしたり、オンラインミーティングが多く、完全リモート勤務の社員もいます。

仕様書については、エンジニアやデザイナーサイドから「こうしたほうがいいんじゃない？」という意見もバンバン飛んで、そのタイミングで仕様が変わるというのもある環境です。上から下に仕様書が降りてきて「仕様書が絶対」という感じではなく、チームみんなで意見交換して、気軽に仕様が変わるということもあります。
意見交換についてはオンラインで話す以外に、仕様書のドキュメントにそれぞれコメントを書いていって返事をもらうというやり方の場合もあります。

開発チームはどのようなプロジェクト管理やスケジュール管理を行なっていますか？
スケジュールはAsanaを使ってタスク管理をしています。
また、各プロジェクトの進捗確認や問題が起きていないかを確認する「ヘドアビ会」を実施しています。ヘドアビ会とはGraffityのVALUEとして掲げる「Head for Ambition」に由来していて、意思統一して目的に向かってみんなで進もうという会です。進捗共有会をして、みんなの見ている方向を確認したり、各プロジェクトで困っている箇所を相談したりしています。
社内でよく使っている「不確実性」という言葉あります。「どう作ればいいのかわからない」「お客さんのレスポンスが悪い」など、作業を進める上でのハードルとなるところを不確実性と言っています。プロジェクトごとに毎週チェックポイントを設定して、なにか遅れそうというアラートもここで拾われて全社で共有されます。その上で、ほかのプロジェクトに余裕があれば人員を持ってこれないか相談するなど、そういった形でスケジュール管理・プロジェクト管理をおこなっています。

3カ月で開発した『LOST ANIMAL PLANET』は、どのような組織体制でリリースが実現しましたか？
『LOST ANIMAL PLANET』の場合は、お客さん側から3カ月でリリースしたいという希望があったので、会社側としてできる範囲でベストを尽くしてリリースできました。
やはり、3カ月という限られた期間でできる上限はみえています。そのため、早い段階で「この仕様が難しい」「この機能を実装する場合は、こっちは間に合わない」などのやりとりをしていました。お客さん側とコミュニケーションを取りながら、できるところを探していったという形です。会社としては良い経験になり、新しいナレッジとして蓄積されたと思います。

Graffityでは積極的に人材を募集しています！

Graffityに興味のある方はぜひ気軽にコチラからご応募ください！まずは話だけ聞きたいなどでも大歓迎です！