エンジニアリーダーが考える
自己開示からのチームビルディング

玉田：私はアプリボットで『グリモア』(※1)のエンジニアリーダーを務めています。日々の実装タスク以外にも、品質管理のためのテスト計画をたてるなどディレクション業務にも携わっています。そのため、デバッガーを含めて10名弱ぐらいの開発チームのマネジメントもしています。

※1：グリモア～私立グリモワール魔法学園～

ー ゲーム開発をしたくてサイバーエージェントに入社したのですか？

玉田：「サイバーエージェントで新しい事業を作りたい」という目標をもって入社したので、配属先は「自分で新しい事業やサービスをつくれるかどうか」を重視していました。配属先の希望を出すタイミングでどこにするか悩んでいた時、子会社の株式会社アプリボット社長である浮田の話を聞く機会がありました。

浮田は「SGE(※) では事業も作れるエンジニアを必要としている。例えばアプリボットではゲームが主軸だが、Webサービスやコミュニティアプリなどの事業も手掛けていきたいと考えていて、それを担っていけるエンジニアを求めている」と話していました。

その話に共感をして、配属先にSGEを希望しアプリボットに配属されました。

※ 株式会社サイバーエージェントのゲームやエンターテイメント事業に携わる子会社が所属する事業部。SGE（Smartphone Games & Entertainment）

― 自分で事業を作りたいのであれば、ビジネス職を選んでプロデューサーを目指す道もありませんか？

玉田：ビジネス職に必要な能力は、ゲーム開発をしながら身に付くだろうと考えていました。その上でエンジニアとしてプロダクトを開発できることが、自分の強みになると考えました。浮田の話にもあった通り今後は「事業も作れるエンジニアが求められる」気がして、自分はその先駆けになりたいと思いエンジニアを選びました。

もちろん最初は新卒のエンジニアなので、何よりもまず技術力を伸ばすことが重要でした。入社してしばらくの間は、バグを直したりイベントを実装したりといった目の前のタスクをやりきることに集中していました。

ある程度仕事ができるようになってから、自分が作っているサービスや事業の戦略、ユーザーの方々にどう評価されているのかといったことについて、興味と当事者意識を持ってキャッチアップすることを意識するようにしていきました。

そこに軸を置いていれば、エンジニアであってもビジネス職であっても、タスクの違いはあれど「事業をつくる」という点で同じ道にいられると思ったからです。そのため、開発しているサービスの業績やユーザーの声に向き合い、起きていることを自分事として考える習慣が身についた気がします。

ー 開発チームのマネジメントをする際に意識していることはありますか？

玉田：透明性です。エンジニアは組織の透明性を求めている人が多い気がします。

「透明性」がある組織とは、つまり「メンバーの相互理解ができている」ということだと思っています。

もし組織に透明性がないと感じている場合、上司や同僚に対して「自分のことを理解してもらう」「相手のことを理解する」という努力をしてみると、職種間の相互理解が進んだりするケースがあります。

アプリボットは相互理解を非常に重視している組織です。理由として、ゲーム開発は他セクション、他職種が複雑に絡み合い、チーム力とクオリティにとても高い相関がある事業だからです。

例えばエンジニアなら3Dゲームのメインロジック実装をするクライアントをはじめ、インフラ、サーバー、Webフロントに関わる人もいます。デザイナーも3Dモデラー、UIデザイナー、アニメーター、イラストレーターと職種は様々です。ゲームはそういった専門職が集まったチームがコラボレートすることで開発していきます。

そんな組織の中で、セクション間の壁をもった状態になってしまっては、日々ハイエンド化が進んでいるゲーム市場では勝っていけません。だからこそアプリボットでは職種間の相互理解を重視しています。

ー 職種間の相互理解を促進するためには、具体的に何から始めれば良いですか？

玉田：自分の情報をまず開示して、どういう考えを持っているのかを知ってもらうことが重要です。その際「私はこうしたい！」というベクトルではなく「私は組織やプロダクトをこうしたい！」ということにベクトルを向けることを重視しています。

率直に自分が思っていることを吐き出してみたほうが私は楽ですし、そのほうが自分にとって良い結果が生まれることが多いと思います。

― どんなことを自己開示すれば良いのでしょうか。

玉田：例えば「自分は、グリモアというプロジェクトをこうしたいから、そのためにはこの機能が必要で、それにはこういう技術で実装すべきだと思っています！」といった考えを、上流思想というかプロダクトの長期的な目標に沿った上で言語化するプロセスを大事にしています。

もちろん「とにかく最新のプログラミング言語を使いたい、プログラミングを突き詰めていきたい。」という考えもありますが、私は、プロダクトや事業から落としていって技術に落とし込んでいます。

― メンバーに自分の考えを伝えるやり方をどう工夫していますか？

玉田：月1の面談があるので、そこで「あなたが今やっている仕事はこういう意味がある」といった、私が考えるメンバーの仕事の意義を定期的に話すようにしています。

新卒の頃に言われたことで今でも心に留めているのが、「リーダーやチームを率いる立場になりたいなら、自分の考えをしっかりと持った上でそれを広めていかなければならない」と教えられたことです。

広め方としては、日報をしっかりと書いたりブログで自分の考えを発信するという方法もありますし、飲み会やランチ、日々のコミュニケーションで伝えるという方法もあります。ただ、その際に気を付けているのが「理由もセットで説明する」という点です。

あるタスクの解決策について、自分の行動指針はこういう理由に基づいているということは伝えるようにしていますし、メンバーにもしっかり理由を持って行動してもらう。面談でも原因と結果、理由付けといった部分を明確にすることは心がけています。
 

ー 時にはトップダウンで物事が決まってしまい、エンジニアとして納得がいっていないことも、メンバーに伝えなければならないケースもありますよね？

玉田：非常に幸運なことに、私は完全なるトップダウンで何かが決まってしまったという経験がないんです。なぜかというと、経営陣がほぼ全ての情報を月初会などで開示してくれるからです。

新規プロジェクトが立ち上がり、そこに人の異動が必要な場合は「アプリボットという会社をこういう会社にしたい、そのために注力するプロジェクトに今これだけの人が必要だ」といったことをみんなの前で共有してくれます。

加えて役員と社員の距離も近いので、何か聞きたいことがあれば「なぜあれをやっているんですか？」とすぐに聞くことができます。そのため納得しないまま仕事をすることはないです。

―  全ての組織がそうではないですよね。

玉田：はい。浮田はよく「自分の言葉で語れ」と言っていますが、とても大切なことだと思っています。例えば上司から言われたことをみんなに伝える時にメンバーから「なぜこれをやるんですか」と聞かれて「上司に言われたから」としか答えられなかったらみんなを納得させられないし、それが不透明感に繋がってしまいます。

まず言われたことに対し、直接聞いた人間が自分事として捉えて、どう解釈するのかがすごく重要だと思います。

そこで納得できなければ納得できるまで伝えた人と対話をしてみる。そうすることで、今度は自分がメンバーに伝える時に議論が生まれたとしても、「言われたから」ではなく、自分の言葉で話すことができる。

プロデューサーが決めた方針を担当セクションのリーダーが解釈し、それを受けて現場のメンバーが実装する。プロデューサーからメンバーへと伝わっている言葉の表面上は違っていても、コアになる部分は同じものが伝わっていればチームが一体となっていいものを作ることができると思います。

― 将来的にどんなエンジニアでありたいと思っていますか？

玉田：私は新卒採用にも関わっています。今の学生や新卒を見ていると、みんな技術的に非常にレベルが高いし、テクノロジー好きな人が私たちの代よりも年々増えていて、非常に頼もしいと思います。一方でエンジニアは売り手市場なので、自己評価を高く見積もりすぎないよう個人的には気をつけています。

「売り手市場」はエンジニアである自分にとってはありがたいことではあるのですが、環境の良さを当たり前だと思ってはいけないと思っています。権利だけを主張する人になってしまったら1人のビジネスマンとして成熟できない気がするんです。

技術だけをやっていればいい、その技術をお金で売り買いすればいい。そういう考えもあるのかもしれませんが、自分は同じ志を持った人たちと、仲間として一緒にビジネスをやって大きな成果を掴みにいきたい。そうすることで人としてもエンジニアとしても成長できるのではないかと考えています。