偉大なゲームを作るために「変化に適応できる組織」を作る(前篇)
2020.08.07
創業10周年を迎えたアカツキは、創業者経営からチーム経営に大きく舵を切りました。その中心となるのが、CEOの香田をはじめとする11名で構成されるExecutive Leadership Team(以下、ELT)。ELTの中で、Chief of Staff, Gamesという役割を担う湯前 慶大さんに、ゲーム開発組織の強化・効率化をどのように考え進めていきたいのか、話を聞きました。聞き手は、アカツキ応援団でエンジニアリング・アドバイザーの能登 信晴さんです。
湯前 慶大 Yoshihiro Yunomae Chief of Staff, Games
新卒で日立製作所システム開発研究所(現横浜研究所)に入社。Linuxカーネルのアップストリーム活動に従事。2014年10月にクライアントエンジニアとしてアカツキに入社。2017年4月よりVP of Engineeringとしてエンジニア組織のマネジメント業務を行いながら組織づくりに従事。2020年6月よりChief of Staff, Gamesとして、ゲーム事業全体の組織づくりを遂行している。
能登 信晴 Tokiharu Notoアカツキ応援団鼓手長 兼エンジニアリング・アドバイザー
ソフトウェア・エンジニアリングと人事・組織デザインの境界領域を専門とし、2012 年よりアカツキのエンジニアリングを支援。湯前さんの入社以来継続的に 1 on 1 を行い、長きにわたるサポーターのひとり。
Chief of Staff, Gamesの役割とは
能登 まずは、Chief of Staff, Gamesとは何をする人なのか、というところから聞いていきましょうか。
湯前 Chief of Staffって日本企業ではあまりみない名前なんですけれど、アメリカとかでは割とある役職らしくて、一般的にはCEOをサポートする役割とされてます。CEOの右腕という位置づけです。COOと近しく感じるけれど、COOほど組織全体を推進するわけではない。COO-liteと表現する人もいるみたいなんですけれど、CEOでカバーしきれない領域をサポートする役割ですね。
能登 COOでもよかったんじゃないかと思うんですが、そこは遠慮したんですか?
湯前 ゲーム部門だけのCOOは肩書き的に微妙だなって話にELTを結成していく中でなったんですよね。COOという肩書きはやはり全社に貢献する人でありたい。他の書き方を探したときにChief of Staffが近しい役割だからいいんじゃないかとなりました。あと、個人的には、香田さん(代表取締役 CEO)の後にCOOという肩書きを名乗るのはちょっと重荷に感じたのもあります(笑)。
能登 領域を区切るなら、Chief of Staffの方がいいんじゃないかということでしょうか?
湯前 そうです。
今回はゲーム部門の長である戸塚さん(取締役 Head of Games)をCEOと見立て、それを補佐する役割と定義したので、最後に”, Games”とつける必用がありました。それなら、COO, Gamesって言わない表現だよね、と。
能登 アカツキはこれまでもフラットな組織を目指していて、今回も取締役とELTは横並びだとあえて言ったりしてますよね。なのに、CEOとChief of Staff、少し上下差をつけたのはちょっとユニークな感じがしたんですけど。湯前さんはふだんから上下の関係性でなく、フラットな関係性を重視しているな、と感じるんですよね。そこをあえてCEOのサポート役になろうとしたのはなぜなんだろうなと。
湯前 僕は事業戦略を描くのは得意じゃなくて、次の事業を戸塚さんと同じ立場で描くのは正直自信が無かったです。一方で、組織を良くすることは誰にも負けない自信があって。もちろん一人で事業と組織を見れたらいいんでしょうけれど、今のフェーズであれば、事業と組織を考える人がそれぞれいた方が上手くまわるんじゃないかと思いました。そう思った時に、事業のことを考えるのは戸塚さんで、組織のことを考えるのは僕と役割分担するのがうまくいくんじゃないかと思ったんですよね。でも、戸塚さんも組織のことを全く考えられないわけじゃなくて、いつも組織のことをとても大事にして事業を考えています。だから、僕が組織を考えて戸塚さんに報告するっていうレポートラインにするのが、一番上手くいく体制なんじゃないかなって思ったんですよね。
能登 同じCから始まる役割にはCHRO(Chief Human Relations Officer)があって、会社としてかなりゲーム事業をメインにしていくという意思決定をしているから、ゲーム事業の組織戦略が全社の組織戦略になってもおかしくないなって思っていて。そこってどういう役割分担なのか、僕としては興味があったんですよね。
湯前 今のアカツキはゲーム事業が主力なんですけれど、社員の規模的にはゲーム事業以外のメンバーも結構いて、アカツキ全体を1つの組織戦略で考えるのは難しいと思っています。僕の持論なんですけれど、事業の性質によってどのように働くのがベストかは違うなって思っていて。だから、基本的には事業単位で最適化することを目指した方が良いなと。でも、アカツキ全体で最低限担保する施策や制度もそれはそれで考える必要があって。そういう意味では僕がゲーム事業のことを考えて、CHROの法田さんはゲーム事業からあがってきた課題や解決策を全社視点で考えて適用していくっていう形を取ってますね。
能登 そうすると割と、ゲームの領域に特化して最適化していくことに湯前さんはガンガン攻めていって、その結果はCHROにも共有されて、必要であれば全社のルールや制度として伝えていくっていうことでしょうか?
湯前 そうですね。あとは、今はゲーム事業が主体ですが、IP事業本部もできてこれから人もどんどん増えていくことを考えると、ゲーム事業だけを考えて全社の組織設計するのだとちょっと足りてないかなと思ってます。今は割とゲームとの親和性が高いのでIP事業本部の組織づくりは近しくはなってはいますけれど、これから事業が大きくなればずらしていくところはあるんだろうなって思ってます。
能登 実際、ゲームのソフトウェアを開発するのではなくって、キャラクターに純粋に取り組むとか、その著作権ビジネスをやってくみたいな感じになると、その手法は変わってきますよね。
経営メンバーの役割を引き受けた経緯
能登 では、どうしてChief of Staff, Gamesの役割を引き受けることになったのか、その経緯を聞かせてください。
湯前 もともとはこの役割を頼まれたわけではなく、塩田さんが代表取締役を降りることになり、次の経営体制をどうするのがいいんだろうと話しあうところから始まったんですよね。塩田さんを含む当時の経営メンバーがアカツキのエンジニアの組織文化を気に入っていて、次の組織を作っていくのなら、エンジニアの考え方を取り入れた方が良いんじゃないか、と考えたみたいです。僕がエンジニアの組織を見ていたこともあって、僕がなにがしかのポジションとして経営メンバーに入るのが良さそうってことで、その次の経営体制の議論の中に入りました。
その議論を進めていく中で、ゲーム事業はこれからも主力であることは間違いないから、もっとゲーム事業の中を整備して効率的にゲームが作れるような組織を作ってくれないか、というオーダーが香田さんからあったんですね。
ただ、僕の中でゲームを生産的に効率的に作るってことそのものは同意はしながらも、自分の中で引っかかりはあって。その言葉を聞いたときに、僕もエンジニア組織をみている立場ということもあり、自動化とかCIとかCDとかをもっと導入してって話を期待されてるんじゃないかなって思ったんですね。でもそれだと、僕にはエンジニア組織だけ良くしてもゲーム作るのって上手くいかないよなって思いがずっと前からあって。効率化の観点は結果的に一緒なのかもしれないけれど、自分の中ではいろんな職能とコラボレーションを強化してゲームを作れたらもっといいものが作れるじゃないかって思って、そっちの方をできないかって打診しました。後から考えると、多分そういうのも含めて香田さんは効率化って表現をしていたんじゃないか、ちゃんと確認すれば良かった、と思うのですが(笑)。
能登 その湯前さんからの、ある種カウンター的な打診はすんなり話ができたんですか?
湯前 僕からその話をするまでの過程にはいろいろあったんですよね。僕の中では最初の提案はなんとなく物足りない感じがあって。その時、僕はコーチングを受けていたこともあって、自分の思っていることをちゃんと言葉にした方がいいよ、とアドバイスをもらってたんですね。今回の打診があった時に、「正直、ちょっと自分の中で物足りなさがあります」って話をしたら、香田さん、戸塚さんが驚いた顔をして。「僕はもっと大きなことをしたいです。他のELTメンバーは次の事業を作ったりとか全社の最適化をはかったりと大きなミッションがあるのに、僕だけゲームの作り方を効率化するということに物足りなさを感じています。もっと大きな責任あることをやりたいです」と伝えました。そして、いろんな職能の連携を強化する組織を作りたい、という話をしました。
結果、職能を取りまとめる役割はどうかな?と戸塚さんに言ってもらって。戸塚さん自身がやりたいこともあるし、戸塚さんがサポートしてほしいことがあるから、戸塚さんとタッグを組んでやれば戸塚さんは助かるし、なによりそれが物足りなさを感じなくさせるにはいいんじゃないかって話になって、結果、それで行きましょうと形になったんです。
役割そのものをゼロイチで作る挑戦
能登 物足りないって言うのは、他のELTメンバーは大きいチャレンジをしているのにそれと比較するとって言うこと?それとも、湯前さんの中でまだ言語化されていない、もっと大きいものにチャレンジしたいって気持ちがあったんでしょうか?
湯前 ああ、良い質問ですね。
まず、ELTの中で僕がやろうとしていることが小さいなと感じたのは事実あって。一方で、もう少し深堀って考えると、誰かに決められたことをやることからの脱却をしたかったというのもあるのかな、と。これまでの会社の中でやってきたことを考えると、例えば、一番最初のチームではプロジェクトマネージャーやってくれないかっていう打診から入ったんですね。それって僕の最初の意志があったわけでなく要望ベースで始めたってことですよね。もちろん自分から必要性を感じてチームに入っていって課題解決することもあったけれど、何かしらの課題があるところからスタートして改善に回るケースが多かったと振り返ると感じます。
その中で、次の新しいことをやるんだったら、自分も周囲の人も想像してないところのそのさらに先に行くことを自分から導かないといけないのかなと薄々と思っていたんですよね。事業戦略を立てるところは得意ではないという話もさっきしたんですけれど、僕の中でゼロイチを作るところは得意じゃないけれど、何かしらそこに挑戦をしないといけないよなって思ってて。そこで今回の役割そのものを自分の中でゼロイチで作るのどうだろうって思ったんだろうな、と今になって考えられます。
能登 事業をゼロイチで作るんじゃなくて、組織の改善、組織をよくするところの立ち上げ方をゼロイチのような形で取り組みたい、と。
湯前 そうですね。他ではあまり聞いたことのないやり方を取り入れたかったと言うか。
能登 職能の取りまとめの役割をもらったって話があって、だとしたらそれは、職能組織のコミッティ (委員会) を作ってハンドリングしていくのもあるけど、そこは湯前さんは一人でぐっとリードしたいっていうのがあったんですか?
湯前 職能のところはコミッティに近いです。僕が指示出すというよりも、職能のコミュニケーションの壁をなくしていって、情報を気軽に交換できる関係性を築きたかったんですよね。僕が組織図上はリードする立場にあるけれど、そこに上司部下の関係性を作りたかったわけじゃないです。この体制をつくるときにも最初に職能GM陣にそう伝えています。
能登 むしろそこは、サーバント・リーダーシップという言葉あるけど、職能のサーバント・リーダーシップをとることでみんなの壁をなくすアプローチしたいってことですかね?
湯前 まさに、そういう感じです。
職能のリーダーになってから職能GMと1on1する機会が増えたんですけれど、1on1って報告をする場になりがちじゃないですか。でも、そういう報告は僕だけにするのではなく、職能GM全体に共有する方が良いと思っているんですよね。だから、業務報告の場ではなくて、「どうやったらもっといいことができるんだろう」とコーチングやメンタリングの要素を取り入れていて、その人の内面に向き合う場になるように今1on1をやっています。
能登 壁打ちを通して自分で気づいてもらいたい、と。
湯前 そうですね。
エンジニアだけに最適化しない理由
能登 僕は湯前さんのエンジニアリングに閉じないチャレンジをしたいという話は、だいぶ前から聞いていた気がします。そういう、エンジニアリングに閉じていてはだめなんだ、って思うようになった大きなきっかけを聞きたいです。
湯前 これは僕が現場でスクラムマスターをやってたときに思ってたことなんですよね。けれど僕は最初、エンジニアのチームだけスクラムを導入して、他の企画職やデザイナー、QAは他のチームにしていました。その時に、エンジニアチームの開発は上手くいってどんどんアウトプットが出るようになったけれど、結果そのアウトプット量が多くてQAが追いつかないとか、デザイナーも追いつかなくて疲弊してしまうとか、そういう問題が起こり始めました。更に、そもそも作業結果としてのアウトプットはあるけれど、お客様に届ける価値という意味でのアウトカムは十分なのかという観点で見た時に、パフォーマンスが良いとは言えないと思いました。
つまり、エンジニアのところだけ最適化しても上手くいかないんだなあ、と思ったんですね。そこからクロスファンクショナルチームを作って、エンジニアだけでなく、企画職やデザイナー、QAも同じチームに入って、みんなで同じバージョンの開発に取り組むというチームを作ったらうまくいったので、この考えに至った大きな原体験としてこのエピソードがあります。
能登 1つのスクラムチームとして企画職やデザイナー、QAも入っていて、スプリントごとに自分たちで体験可能な開発成果を出していくっていう繰り返しをしていたんでしたっけ?
湯前 そんなに綺麗なストーリーを語れるほどではなかったんですけれど、それをやっていた方が上手くいったという感じですね。そのときのやってたやり方は今から考えるとベストとは思ってなくてけれど、もっと上手くいけていたはず。少なくとも言えることとして、コンポーネントチームを複数作って、エンジニアだけのチーム、企画職だけのチームをあとで統合するとかよりもクロスファンクショナルチームでやってた方があきらかによかったというところが大きいですね。
能登 この話だけを聞いていると、そのやり方をゲームの全タイトルの開発に導入していけばいいような感じがするけど、多分、それだけではないってことなんですよね?
湯前 基本的な思想として、クロスファンクショナルチームをどんどん作っていくのが良いと思っているのですが、全てに適用していくのはかなり難易度が高いと考えています。なぜなら、そのチームの根幹となっている考え方の基本的な方向性は同じだよねって、大事にしたい価値観がある程度すりあっているよねって、状態をつくっていかないといけないかなって。ただ、基本的にプロジェクト内で事業の推進方法は完結するんですけれど、マトリクス型組織なところもあって、職能の考え方も尊重する必要があって。プロジェクトの考え方だけで統一しても、横の職能がずれているとクロスファンクショナルチーム内の考え方の差分を都度調整することが出てきてしまう。だから、ただクロスファンクショナルチームを作っていこうと、ただ言うだけではあまりいいやり方じゃないなと思ったんです。
もう少し具体的に言うと、職能ごとの組織に目を向けたとき、根本的な考えが違うのかなということに気が付きました。エンジニアは元からインターネットの世界でも組織のやり方をオープンにするのが根付いているので情報を得やすい。エンジニアの組織ってこうだよねってことが世界中でやり方を試して、何度も試行錯誤を繰り返して、ベストプラクティスがなんとなくできていったという歴史があって。HRT(「謙虚 (Humility)」「尊敬 (Respect)」「信頼 (Trust)」の頭文字を取ったマインドセット。出典:『Team Geek』)はまさのその1つだと思います。職能ごとにも考え方の違いがあるのは理解しながらも、例えば、HRTのような考え方は共通に持っていて良い思想だと思っているので、そういった根本的な思想を職能間で合わせていきたかったですね。
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
作者:Brian W. Fitzpatrick,Ben Collins-Sussman
出版社/メーカー: オライリージャパン
発売日: 2013/07/20
メディア: 単行本(ソフトカバー)
https://www.amazon.co.jp/exec/obidos/ASIN/4873116309/
Team Geekの中で出てくるHRT
謙虚(Humility): 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
尊敬(Respect): 一緒に働く人のことを心から思いやろう。相手を 1 人の人間として扱い、その能力や功績を高く評価しよう。
信頼(Trust): 自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
職能の壁を超えるために
能登 僕はエンジニアのコンテクストにいるから「そうだよね」って思うけど、エンジニア以外の人にはやり方を押し付けられるんじゃないかなって心配があるんじゃないかなと。そこはどう考えていますか?
湯前 そうですね。僕の前提としては、組織の考え方を押しつけるつもりはなくて。「学習する組織」の中に、「人は変化に抵抗するのではなく、変化させられることに抵抗する」という記述があります。変化させられると思うと人間は拒否感を示すようになってしまうので、可能な限り変化を強制せずに、変化したいと思ったときに、こういうやり方があるよとすっと差し出せるようにしたいなと。
変化したいというタイミングってみんな同じではないですよね。個人の振り返りとかチームの振り返りで、これってもっといいやりかたないのかなって思ったときに、そういえば・・・と、ちょっと思い出してくれるようなことが出来ないかなーと。そのためには、そういう情報を常に流しておくのが必要なんじゃないかと思ってます。
能登 それは #agile-devel という Slack チャネルでやってるような、湯前さんが「こう言うやり方あるよ」を定期的に出しているようなことを、職能のリーダーで交換するってことでしょうか?。積極的にお互いの価値観を外部化してみるとかはありかもしれないですね。
お互いやり方、考え方が違うときに、相互理解するのが先にあってもいいのかなって気がしました。
湯前 そうですね。それは僕も同じ考えがあって。
こういうことをやることに否定をする訳でもないし、僕も読めてないコンテクストがあると思うので。なにかしら困っていることがあったときには、何を言っても大丈夫ですよという話をしているし、例えばもうエンジニアでは解決した問題とか、ほかの組織で解決した問題でも、まだそんな問題やってるの?とかは絶対に言わないとか。僕自身も組織のことで問題があったときに、なんでそんなことまだやってんですかって言われてイラっとしたことがあったので。その場のコンテクストにいないとわからない苦しみってあると思うし、否定してはいけないと思うんですよね。
能登 ブルトーザーでガガガっと強引にやりたいわけではない、というのは伝わってきますね。
湯前 スクラムの影響を受けているのかなとは思いますね。
スクラムマスターの仕事の一つに、怪我をするのを見守るというのがあると認定スクラムマスター研修で教わりました。、もちろん大事故に繋がるときはちゃんと手を引いて止めるけれど、ある一定の怪我や失敗は大事だという話です。怪我をするのをみているのはつらいけれど、怪我をすることで次の段階へいけると思えば次の段階にいくために見守るってことも大事だと思います。
能登 見守るっていうところもアカツキっぽいところかもしれないですね。
あったかさかっていうか、「できたことを見る」とかもそうでしょうし。
参考情報
- Akatsuki Hackers Lab
https://hackerslab.aktsk.jp/ - アカツキ ゲーム事業部特設サイト
https://game.aktsk.jp/