プロジェクトを蝕む「病」は何？〜ゲームエンジニアが実践するチームの振り返りの質を高めるフレームワーク〜

ゲーム販売元からの受託制作やオリジナルゲームの開発を行う株式会社アールフォース・エンターテインメントのエンジニア組織では、3ヶ月に1回、開発プロジェクトごとにチームの状態を分析し、課題の発見と解決に取り組んでいます。Engagement Run!Academyの「チームの課題を発見するおばけワークショップ」にヒントを得たこの取り組みの詳細について、3名の方にお話を伺いました。
※取材時（2024年6月）の部署・役職になります。

サーベイの導入により、エンゲージメントに対する社員の意識が向上

―御社は2020年からWevoxを利用されています。どのような背景から、Wevoxを活用したエンゲージメント向上の取り組みを行っていらっしゃるのでしょうか？

池下：元々、Wevoxの導入以前に社員から「サーベイツールを使って、会社や自分たちの状態を可視化しながらエンゲージメントを高めていきたい」との提案がありツールを導入した経緯があります。その後、ツールの見直しを行った際にWevoxに切り替えたのが2020年でした。

高野：人事としての現在の課題感でいうと、新卒・中途を問わず入社時のエンゲージメントが高い状態を維持して働いてもらいたいという思いが一つあります。加えて、会社に関わる理由での休職や退職を最小限に留めるためにも、エンゲージメントの状態はしっかり見ていきたいという考えがあります。これらの点で、Wevoxはかなり活用しています。

―毎月のサーベイ結果はどのように活用されているのでしょうか？

高野：当社はクライアントエンジニア、バックエンドエンジニア、ゲームデザイナー、2Dデザイナー、3Dデザイナー、3DCGアニメーターといった職種ごととプロジェクトごとに部門を分けていまして、各部門のリーダーは部門ごとの総合結果を見られるようにしています。具体的には、毎月、サーベイ結果が出た後、各部門のリーダーは自部門の結果を見て課題とそれに対するアクションプラン、そして、前月のアクションプランの結果を報告書に記載していきます。それを持ち寄って、人事と代表も交えた報告会を行っています。

また、並行して人事でもスコアを分析したレポートを作成してリーダーに共有しています。個人の総合評価が「D」以下の社員とは面談を行い、抱えている悩みやスコアが低下した背景などをヒアリングしています。レポートにはその内容もふまえた分析を記載し、報告会でリーダーの見解もふまえて対応を検討しています。

―Wevoxの導入から4年が経過しましたが、何か良い変化などは起こっていますか？

池下：エンゲージメントの状態が数値で表れることで、状態の良い時も悪い時も、理由や背景を皆でしっかりと話し合うきっかけを持てるようになったのが、大きな変化だと感じています。

藤田：「エンゲージメントとは、自分が会社を好きだという気持ちである」ということを皆がちゃんと理解して、日々向き合っていけるようになったことが大きな変化だと思っています。

高野：毎月のサーベイが自分と向き合う時間になりますし、社内全体で、エンゲージメントの重要性に対する認識の底上げになっていると感じています。

プロジェクトに起こりやすい問題を「病」に類型化し、エンジニア組織での振り返りの質を高める

―藤田さんと池下さんが所属するクライアントエンジニアの組織では、「CODE DOCK」という取り組みをされていると伺いました。どのような取り組みなのでしょうか？

池下：開発プロジェクトごとに、チームの状態にどのような課題・問題があるのかを3ヶ月に1回のペースで検討し、対処法を決めて取り組むというものです。

課題や問題を見極める手掛かりとして、アトラエさんの「チームの課題を発見するおばけワークショップ」を参考にして、プロジェクトで発生しやすい問題を「病」という形で27種類、9つの症候群にテンプレート化し、病ごとに「症状」や「よくある特性」をまとめ、「CODE DOCK」と名付けました。このテンプレートを見ながら、自チームにどんな症状が出ているのかを探り、明らかになった症状のうち、向こう3ヶ月で対処すべき病とその処方箋を決め、3ヶ月ごとに達成状況と、新たな症状が出てきていないかを確認しています。

27の病を類型化するにあたっては、マンダラチャートを用いて「開発工程」「品質」「コミュニケーション」「組織文化」などいくつかの項目に分けてプロジェクトの理想形を定義しました。その後、理想形が実現できない要因を洗い出して「症状」や「よくある特性」として整理し、病としての名称をつけていきました。

―なぜこの取り組みを始められたのでしょうか？課題に感じていらっしゃったことなどを教えてください。

池下：当社にはクライアントエンジニアが15〜20人ほどいますが、プロジェクトの異動が頻繁で、かつ、開発のマイルストーンのタイミングや障害が起こったときには振り返りを行うという特徴があります。ただその際、プロジェクトのメンバー構成によって振り返りの方法や深さがまちまちであることに課題を感じていました。

どの開発プロジェクトにいても、適切なタイミングで検討や決定、保守、改善を実行し、プロジェクトやチーム全体が統一感のある、開発・運用しやすい健全なプロジェクトを目指したい。そのために、何かしら統一した振り返りの手法を作りたい。そう考えていたところ、出会ったのが「おばけワークショップ」です。ワークショップに参加して、フレームワークがあることによる話しやすさや、組織の課題・問題の分類の仕方のわかりやすさを感じ、ぜひエンジニア向けの内容にアレンジして活用したいと皆に声をかけました。

藤田：「CODE DOCK」の作成にあたっては、クライアントエンジニアのリーダー陣だけでなく、メンバーにも入ってもらいました。プロジェクトの理想形を定義し、実現できない要因を洗い出して整理し、27の病に類型化するという作業を半年くらいかけて行い、2021年から運用しています。

―これまで、どのような病と処方箋が出てきましたか？

藤田：例えば、この施策を始めた当初に全プロジェクト共通の課題として挙がったのが、「『エディターでは動いていた』病」でした。自分の開発環境、すなわちパソコン上で動作確認をして「動いたから大丈夫」と判断してしまい、それをアプリにしてスマートフォンなどの実機で動作確認をすると動かないということが起こりがちだったんです。これを病だと皆で認識することで、実際の端末で確認するところまでしないといけないという意識を皆が持ってくれるようになり、リーダーが言わなくても実機での動作確認をするようになりました。これは、リーダーからすると大きな変化でした。

池下：直近だと、「サンキュー不足」という病が生じています。クライアントエンジニア部門のWevoxの結果で「承認」や「自己成長」のスコアが低めに出ていた中、各プロジェクトでCODE DOCKをやってみたところ、やはり承認不足だという話になりました。そして、原因はとして挙がったのは、お互いの成果に対して「いいね！」と承認するコミュニケーションが少ないことでした。

そこで、社内で取り組んでいる「サンキュープラス」というサンクスカードを交わす施策をもっと活用することを処方箋の一つとして今取り組んでいます。また、当社では、社内のメンバーに開発中のゲームを触ってもらって改善点をフィードバックしてもらう「おさわり会」を開発中に行うことがあるのですが、今回、終わったプロジェクトでも終わりそうなプロジェクトでも「サンキュー不足」が出ているため、終わったプロジェクトでもおさわり会を開き、開発したゲームの良いところを互いに賞賛し合うことも処方箋とし、実施に向けて動いています。

―「CODE DOCK」の運用において工夫されていることはありますか？

藤田：1つは、病に対する処方箋、すなわち改善策には必ずキャッチーな名前を付けることです。そうして面白おかしくすることで取り組みやすくしています。もう1つは、そういった名称も含めて、3ヶ月に1回の振り返りの内容はプロジェクトの他のメンバーにも共有しています。

池下：「ぼっち・ざ・回避」「未来の孫の手」など、これまでいろいろな名前を付けてきましたが、「『ぼっち・ざ・回避』しようよ」などと言えるので伝わりやすいと感じています。また、CODE DOCKの実績や診断結果は全社で見られる場所にドキュメントとして残し、追加・更新時にはアナウンスもしています。それにより、個々のプロジェクトではなく全体的な課題の傾向や、Wevoxのスコアの変動の要因が見えてくることを感じています。そういった傾向をもとに、他部門とも連携して全社的な取り組みを検討したりもしてきました。

―「CODE DOCK」を始めて3年ほど経過しましたが、組織の変化や成長をどのように感じていらっしゃいますか？

藤田：「起こっている課題・問題に一つひとつ対処して、また次の課題の改善に繋げる」ということを継続できていること自体が成果として一番大きいと感じています。

池下：皆、他のプロジェクトの振り返りを見るようになったなと思います。例えば、CODE DOCKをする際に、「あそこのプロジェクトではこういう症状をこういうふうに解決している」とか、「同じような症状が出てるね」というのを言えるようになったので、他のプロジェクトの開発状況とか問題点に対しても同じように理解できるというか、同じ言葉で話せるようになってきているのは、大きな変化だなと感じています。

―CODE DOCKの今後の運用や展開については、どのようにお考えですか？

池下：病の分類や症状、解決策のヒントなどの見直しを適宜やっていければと思っています。元々、運用しながら見直していくつもりで作成したものですし、プロジェクトの理想の姿とのズレを感じる部分も出てきているのが理由です。加えて、あまり課題として挙がってこない病や症状についても、エンジニアには起こりづらいことだからなのか、あるいは、課題ではあるけれども直視したくないから病として診断していないのかを明らかにしたいです。前者であればCODE DOCKから外し、後者であれば対処法を検討するなどしていきたいと思います。

改善点を一つずつ見つけて、より強い組織を作っていきたい

―高野さんは、推進担当のお立場から、CODE DOCKの取り組みをどのように見ていらっしゃいますか？

高野：こういう考え方でゲーム会社のクリエイターのエンゲージメント向上に取り組んでいくといいんだなということを学ばせてもらっています。

当社においては、人事はメンタル面や健康面からクリエイターのエンゲージメント向上を支援し、スキル面からのエンゲージメント向上は各部門のリーダーに大部分を任せています。なのでCODE DOCKの作成や運用に人事が介入していないのですが、特に各部門のボードメンバーは、エンゲージメントやメンタルヘルスに関する知識も深く、改善のために積極的に取り組んでくれています。中でも、クライアントエンジニア部門は社内で最も人数が多く、組織としてもかなり成熟していると感じます。アールフォースのマインドがものすごく浸透しているので、池下や藤田、その他のメンバーから学ぶことは多いです。

―社内では、他にどのような活動をされていますか？

高野：エンゲージメント向上のための取り組みとしては、面談専門の相談員を配置しており、どんなことでも気軽に相談出来るようにしています。また、メンタルヘルスのセルフケアのスキル向上や健康診断の結果改善のために、「保健委員」の活動として私から衛生講話や社員へのアンケートやインタビューを公開しています。会社が環境を整えることも重要ですが、一人ひとりに自分のエンゲージメントに関心を持ってもらうことを目的としています。今は特性診断を活用した取り組みを検討中です。

池下：先ほど話した「サンキュープラス」も全社での取り組みです。社員が会社に対して提案できる機会があるのですが、そこで提案があり実施に至りました。毎月１つの投稿をピックアップして表彰をしています。少しですが表彰金も出るんですよ。更に、サンキュープラスを送り合うとポイントが貯まり、社員総会後の懇親会での抽選のコンテンツ表彰につながったりもします。

あとはプロジェクトごとや、部門ごとに独自に取り組んでいるものが多いですね。例えば、週1回、直近の1週間でできた成果物をプロジェクトメンバーに披露して賞賛を受ける「ドヤ会」を行っているプロジェクトもあります。CODE DOCKに似た取り組みだと、企画部門において「ゲームデザイナーに必要な9つの力」を定義して自分たちの在り方を見直す機会を持ったりしているようです。

―では最後に、今後、どのような組織・チームを作っていきたいとお考えですか？

藤田：皆でゲームを作っていくにはどういうことが必要なんだろう？ということを追究して、継続的に改善に繋げていけるような施策なり、取り組みなりを続けていきたいと思います。CODE DOCKでカバーできる範囲も多いとは思いますが、まだ足りないところもあると思うので、まだ見つけられていない改善点を見つけて改善し、より良い会社にしていければと思っています。

池下：CODE DOCKは、どちらかというと「これからどうしていこうか？」ということを考えるポジティブな施策なので、そこは継続したいです。その上で、会社や仕事に対するネガディブな気持ちを拾い上げてニュートラルにする取り組みができればと思っています。

例えば、今、全社的に課題となっている承認や成長実感をどのようにして持つかというところや、エンジニアとしての成長意欲を一人ひとりがどうしたらもっと持てるか、というところです。そういった点へのアプローチを強化して、もっと会社を好きになったり、自分たちが良いと思ったことについて主体的に動けるようになれば、より強い組織になるのかなと思います。

高野：Wevoxを活用することによって、チーム全体や個別の問題は感知できるようになってきました。他方で、人事として、社員が自分自身で解決する力をつけていく必要性を感じています。例えば、若い社員には自身の健康への関心が薄い人が多く、仕事にのめりこんでしまって気づくと体調やメンタルの不調に陥っていることがあるので、体調面とメンタル面のセルフケアをもう少し社内に浸透させていきたいと思っています。

また、やりがいや意欲についてまだ解像度が低かったり、自覚が出来ていない若手社員もいるのですが、ジョブ・クラフティング※の考え方がすごく参考になるので、アトラエさんの記事の共有などもしていきたいと思っています。
（※仕事に対する認知や行動を自ら主体的に変えていくことで、仕事を“やりがいのあるもの”へと変容させる手法のこと）