アカツキという会社は、そこに集まっている人たちがいちばんの特徴になっている、という僕の最初の印象、4年半前に感じた印象は今でも変わっていない。実際社内の何人かに会ってもらうと「予想以上にいい人たちが集まっていて、いい会社なんだなと思いました」と言ってもらうことが多い。ただ、そういう中にいる人たちの人物像って、どうにも会ってもらうまで伝わらないので、それだとウェブではうまく伝わらないということになってしまう。自分としてはそこにずっと歯がゆさを感じていたんだけど、もしかしたら長めのインタビュー記事を載せることで、そこが解消されるんじゃないか、と思って、自分でインタビューして公開してみることにしました。どれくらい意図通り人物像が伝わるかわからないですが、何事もまずはひとつやってみないとね、と思って。
アカツキエンジニアで一番最初に紹介したいのは誰かなと考えた時、速攻で頭に浮かんだのが今回取り上げた湯前さん (id:yunon_phys) でした。
湯前さんは前職で Linux カーネルの改善をやっていて、今は社内で最もスクラムに詳しい男であり、かつ CTO や僕と一緒にアカツキのエンジニアチームを良くしていくマネジメントの役割も担っている。エンジニアチームの主役はマネージャでは決してないけど、こういう人がマネージャをやっているからこそ、エンジニアにとって働きやすい環境・チームができている、というのは伝わるんじゃないかなと思ってます。
ということで、以下、聞き手・構成ともに能登が担当してお送りします。
- Linux カーネル改善を仕事にしていたにもかかわらず、アカツキへ転職した背景
- インフルエンザで PM 不在、混乱したチームが…
- プログラムを書くか、マネジメントをするか、自問自答し続ける
- 新規ゲームタイトル開発ならでは楽しさと難しさ
- アカツキでの成長
- スクラムマスターからエンジニアリング・マネージャへ領域を広げる
Linux カーネル改善を仕事にしていたにもかかわらず、アカツキへ転職した背景
―――― それでは、まずアカツキに来る前にどういうお仕事をしていたか、聞かせてください。
前職では大手電機メーカの研究所にいて、主にインフラ事業向けのシステムに使われるサーバの OS の開発をしていました。そのサーバ OS は当初 Linux を独自改造していたんですけど、そういった OS をメンテナンスし続けるのにけっこうコストがかかっていました。そこで、メンテナンスコストの削減のために、自分たちの変更を Linux カーネルに取り込んでもらうアップストリーム活動を会社としてすることになりました。自分は正にそのアップストリーム活動を担当していました。
―――― カーネルにオリジナルの変更点を入れる、オープンソースに関わるっていうのは、ソフトウェアエンジニアにとっては大変さも感じるだろうけど、おもしろさややりがいも大きい業務だと思うのですが、なぜそこから転職を考えるようになったんですか?
毎回数年かけて開発して、そこからさらに何年も保守してというのを繰り返していて、実際に僕が退職したのは今から 3 年くらい前なんですけど、その時までやっていた開発対象ってどうもまだ世に出ていないらしいんです。それくらいスパンが長い業務になっていて、自分がやったことに対して素早く世の中からフィードバックがあるかというとそういうものではなかったというのがあります。そういう状況に悶々としていたところに、ドイツのおっちゃんからメールが来て、自分が Linux カーネルのメーリングリストに投げたパッチを取り込んで動かしてみたら、すごくうまくいったよというコメントが返ってきたんです。それがすごくうれしくて、もっと自分がやったことに対して世の中からフィードバックが来るような仕事がいいなと感じて、そういう仕事に変えようかなとふと思ったというのがきっかけです。
―――― そういうフィードバックが素早く来る、という点では、ウェブやスマフォゲーム系の会社なら、2, 3 年かかるということはあまりないので、選択肢は広がると思うけど、その中でもアカツキがいいなと思ったのはどういうところなんですか?
アカツキが他の企業とぜんぜん違うと思ったところがあって、エンジニア文化というのを打ち出していて、自分たちはこういう風に開発をしていくんだというのが『アカツキの開発に対する哲学』に明示されていますよね。あと、これはエンジニアについてだけではないのですが、アカツキは会社としても「こういう会社である」というのをコーポレートページで定義しているところがぜんぜん違っていて、しかもそこに自分自身が共感したというところが大きかったなと思います。普段から自分が考えていた、面倒なことをしないように最高の方法を考えるとか、自分たちでワクワクして働くというものが、そのまま書いてあったというのがすごくマッチしたと感じたところでした。
―――― 面倒なことは自動化するとか、自分たちが楽しまないと仕事っておもしろくないよね、っていうのは、前職の時からそういう方針が自分の中にあったということですか?
そうですね、たまに手動でやっていることもあったんですけど、手動でやっていると疲れてくるというのもあって、ちょっとこれスクリプト書いて自動化するかとか、できる限りやっていました。自動化すると手動でやっていた時より楽だし、手でやってミスする可能性を排除できるので結果クオリティが上がります。他にも個々の実行時間が短くなるので、ならこれを追加してみたらどうかとか、その時どういう挙動になるか確認するとか、10 台いっきにセットアップしちゃおうとか、いろいろ試しやすくなるのも大きいです。そのあたりが自分の経験として良かったので、自動化するとか、システム化するというのがすごく好きなんですよね。
「ワクワクして働く」の方も、自分が楽しいと思っていないとそこに情熱注げないと当時から思っていて、オープンソースの活動自体は自分でも情熱持って働けたので、そこは良かったと思っています。
インフルエンザで PM 不在、混乱したチームが…
―――― アカツキに入ってからけっこういろんな仕事をしてきていると思うんですけど、まずは今担当しているものの、ひとつ前のプロジェクトについて聞かせてください。
ひとつ前は、規模大きめの既存ゲームタイトル運営チームにいました。突然 1 週間くらい前に通達があって、プロジェクトマネージャ (アカツキではプロジェクトリーダがゲームタイトルごとの最終責任者で、プロジェクトマネージャは進捗や生産性、問題解決の部分に責任を持つ役割) として異動してくださいということになったわけですけど、移ってみるとまずチームの状態が思ったより良くなかったんです。隣の人が何をやっているか把握していないというか、「隣の人待ちなんですよね… (チラチラ、と横の人を見る)」みたいな。必要なコミュニケーションがとられていないし、形式的な朝会が行われていて、そちらもあまり意味を見出しにくい内容で。「ここにいる人たちはすごい人たちなのに全然この人たちを活かせてない!」と思いましたし、何より楽しそうじゃないなと気付いて。これは何とかしなきゃということで完全にチームを改善する方向で仕事を始めました。
まずは、明確にチームメンバーへのサポートが必要だなと思ったので、自分が整理する、ちゃんと決めていくというところに全力投入していました。スプリントのタスク内容を定義して、自分が「この人がこれをやる、この人がこれををやる」とタスクのアサインをして、かつ、会議など全部のファシリテーションをして、チーム全体のワークフローがスムーズに流れていくよう、まずは自分が頑張るというアプローチでした。ただ、それだけでは不具合もぜんぜん減らないし、ぎりぎりになってもまだやる、ハードワークでカバーするというところも変わらず、これじゃぜんぜんダメだなっていうのもあり、じゃあどうしたらいいんだろうと。そうやっていろいろ悩んでいた時に、自分がインフルエンザにかかって「1 週間会社に来られません」ってことになって… スプリント期間が 1 週間だったので、チームが大混乱になる未来が見えて、ああ開発が止まるなあ、と。
やっと治って出社したら、驚く光景が広がっていました。なんと、自分がインフルエンザになる前よりもチームがすごく良くなっていたんですよね (笑)。チームのメンバーが、じゃあ自分たちだけでどうすればいいんだろうと試行錯誤したみたいで、自主的にチームに分かれて、ワークショップ形式でワイワイ楽しそうにタスク割り振りをやっていました。このとき、自分がやっていたことは改良にはつながっていたけど、もっといい方向もあったんだということに気づきました。
今までのやり方を変えなければなあと思っていた時に、ちょうど認定スクラムマスター研修を受けることができたんですよね。
―――― 湯前さんのインフルエンザという「事故」みたいなものがあって、自分の思いもよらなかったプラスの方向にチームが変化して、それとスクラムマスターの研修っていうのは、割と並行したものだったんですか?
もともとだいぶ前に予約していたんですよね。まさかインフルエンザになった次の週に重なるなんて、予期してなかったことなんです。
「帰ってきたばかりで恐縮なんですけど、来週からいません」みたいな (笑)
―――― でも、その「自分たちで考えて進める」状況を強める結果になったということですね。
そうです。
―――― 自分がいない 2 週間でのチームの変化を体感して、スクラムマスター研修を期にスクラムを理論的にも学ぶようになったんですか?
元から本で勉強はしていたんですけど、真の意味で理解したのはそのスクラムマスター研修です。本を読んでいても、現実との比較をずっとしていて、こうは書いてあるけど現実では無理だよなと感じながらずっときていました。
スクラムマスターの研修に行った時に、そういう現実とのギャップについて講師にくりかえし質問しました。「実際こういう状況になっているんですけど、こういう場合どうするんですか?」と聞くと、「でもそれはあなたのプロジェクトがそういう状況なだけで、理想はこうだから」としか講師は教えてくれないんですよね。何度もそういう回答が来て、自分が理想の状態に持っていこうと努力していなかったということなんだと気づいて、反省しました。現実はこうだからというところに甘えていて、さらにもっとより良くするにはどうすればいいかというのを自分が考えていなかったという。
―――― 推測するに、インフルエンザで湯前さんがいないから苦肉の策で現場の人たちが実践し始めた「自分たちで考えて、自分たちでやってみよう」という姿勢が、実はスクラムとかアジャイルの世界で目指すべき姿だったということでしょうか?
まさにそうだったんです。
―――― これはすごい偶然ですよね (笑)
この機会は絶対逃してはいけないなと感じたんです。
じゃあ、自分が最初からプロジェクトにいなければそういう状況になったのかというとそうでもなかったような気がしていて、湯前が入る前にはそれでうまくいってなかったというのもあるんで。自分のやり方をまわりの人が見ていたから自分たちでできるようになったという面もあるでしょうし、かつ自分たちで学習するっていう下地がチームにできていたんだと思います。あくまでインフルエンザとスクラム研修は、きっかけにすぎなかったと。
それを期に、自分が仕事を割り振るという役割はやめて、できる限りチームに任せて、チームが困っている時にサポートすることに振り切るようにしました。結果そのチームは自分がいなくても回るという状態になったので、じゃあ湯前いなくなってもいいよね、ということで新しいプロジェクトに希望して移りました。
プログラムを書くか、マネジメントをするか、自問自答し続ける
―――― 湯前さんって、そういうスクラムマスターやルーティンじゃない問題解決に専念する役割がチームに必要なんだなというのを、先ほどの経験を通して学ばれている気がするんですけど、一時期エンジニアとして技術を突き詰めるか、マネジメントをやるかという迷いがある時期もあったと思います。マネジメントにしばらく専念しようかなと思ったのは、その経験から来ているんですか?
そこはもっと前なんですね。先ほど話したプロジェクトに入る 2 ヶ月前とか、3 ヶ月前とかだったんですけど、能登さんとも毎回 1 on 1 の時にそういう相談をしていて「ちゃんと自分のこと考えなさい」と言われていて。たしかに自分のことを考えられていなかったなと思って、毎日寝る前に 10 分だけそれを考えるというのを続けてたんですね。「自分が何をしたいのか」とか「自分は何が好きなんだろうか」と。
そうしたら、たしかに技術も好きだし、プログラム書くのもすごい好きなんだけど、自分にとってプログラムを書くことが目的なわけではなく、それを使ってプロダクトが良くなるということが好きなんだと。ということはプロダクトが良くなれば、プログラム書かなくてもいいんじゃないか、って結論に至ったんですよね。そこに落ち着いてからは、プロダクトを良くするためにどうすればいいかという視点で物事を考えるようになったので、エンジニアとしてコードを書いているか書いていないかというのは問題じゃなくなったし、将来的にプログラムを書き続けないといけないのか、というモヤモヤしていたところも、解消されました。
実際その当時のプロダクトチームで、自分がコードを書きながらチームリードをやっていると、ぜんぜん回っていかないという状態になっていて、それがすごく自分の中で嫌だったんですよね。自分はコードも書きたいし、チームを良くしたいのに、ぜんぜんプロダクトが良くなっていかない。自分がチームのボトルネックになってしまっているっていう…
―――― 自問自答を続けて、それで気づいた内発性というか、それをちゃんと仕事の改善に活かしているというのもすごいアカツキっぽいですよね。
確かにアカツキには多いですね。自問自答し続けるのも辛いので、つい逃げてしまうこともよくあるんですけど (笑)。壊れない程度に自分を見つめるバランス感って大事だな、って思います。
―――― チーム開発で気づいたことがあるとき、どうしているんですか？
これまでの経験上、自分が「やばい」って思っても致命的でなければしばらく黙っているのも意味があるなと思っています。そうしていると、まわりからも「これやばいんじゃないか」という声が出てくるんですよね。そうなったタイミングでちゃんと対処するとすごくうまく進むというか。自分だけしかその問題を感知していない状態だと、ひとりでいろいろやらなくちゃいけないのでたいへんなんですけど、自分以外の人も危険だと感じられた時ならまわりの人を巻き込んでできます。しかもそれを二度と起こさないためにどうすればいいかというところまで全員で考えて、チームとして「これはやめよう、なくしていこう」というところまで考えられるようになります。さらに、たまに自分が思っていたよりも更に良い方向に行くこともあって。そういう意味で、気がついていながらあえて見守るのも、チーム開発においては重要だなって思います。怪我をしてちょっと傷つくのを見ているのは辛いんですけどね。(笑)
新規ゲームタイトル開発ならでは楽しさと難しさ
―――― 今は希望していた新規ゲームタイトル開発チームにいますよね? そちらの方はどういう状況ですか?
このプロジェクトも以前の初期と似たコミュニケーション不全などありましたが、まずはエンジニアチームだけ改善してみて、それがちょっとずつうまくいき始めたら、他のプランナーやデザイナーも巻き込んで、という形でやってきました。まだ完全にスクラムの全部をやりきれているわけではないんですけど、チーム開発とは何かというのをみんなで考えながら、いろいろ改善してみているという段階です。
以前のチームより、みんなにまかせる裁量も大きくしているし、自分が無茶苦茶頑張ってなんとかするという方向ではなくて、「どうやったら良くなるんだろうね?」というのをみんなに問いかけながらやっています。とはいえ、以前のチームと同じ状態まで持っていくにはまだ半年くらいはかかるかなという気はしていますが。
―――― 「チーム開発とはなにかみんなで考えながら」のところや、改善内容についてもう少し詳しく教えてもらえますか?
朝会とかスプリント・レトロスペクティブ (=振り返り) の時とかに、これってどうやったら改善されるんですかね? って聞くようにしています。例えば、チームとして誰かが誰かを経由して伝えているような状況だと「それでいいんでしたっけ? 直接伝えたほうが速いんじゃないですか?」と聞いたり。ちょっと嫌そうな顔をされるときもあるのですが、めげずに背中押しをします。
あとはベロシティやバーンダウンチャートを毎日 Slack に投稿して、今こういう状態になっています、前回の Sprint からこう改善されました、これはチームのコミュニケーションが上手くいっているからですよね、というのを伝えることによって、「じゃあこういう状態がいいんだ」というのをみんなで理解するということもやっています。数値やグラフで見えるということはいいことかなと思っていて、感覚ももちろん大事だと思うんですけど、自分たちはこれだけ良くなったんだというのを定量的に見えるというのも大事かと。
ベロシティ測るのは、以前いたチームではちゃんとできてなかったことなんです。いまのチームは最初から自分がいろいろ知識を持った状態で入れましたし、プロセスがほとんど定義されていなくてまっさらな状態だったので、いくらでもいいプラクティスをやろうと思えばやれるので。
―――― 今担当しているプロジェクトは、新規ゲーム開発、ゼロからイチを作るということだと思うんですけど、それってゲーム業界の中では、運用中のタイトルを改善するよりぜんぜん難易度が高いって言われてますよね。そこに移ってみて、実際難易度が高いと感じますか?
新規タイトル開発はやっぱり難しいなと思いますね。すでに形があるものから改善するというのは見えやすいというか、わかりやすいんです。運用しているタイトルならみんなも自分でプレイしていますし、「ここの画面に行くときは以前はこうなってたけど、今後こうなります」というような説明は伝わりやすい。
新規だとそういう前提となるものがないので、先にコンセプトとか、ストーリーをしっかり作っておく必要があります。仕様についても、そういった前提を踏まえて「これは何のためにやるんだ」というのをちゃんとおさえながらやらないと、担当者間で認識の齟齬が出て、手戻りが発生したりします。
あとはやっぱり、スケジュールですかね。運用タイトルの場合は、すでにプロダクトが動いていてお金も稼いでいるので、最悪新しいバージョンが 1, 2 週間、あるいは 1 ヶ月遅れても、まずいはまずいですけど、大ダメージにはならないですよね。でも、新規のタイトルの場合は、本当にそこに出さなければ終わってしまうというか、1 ヶ月伸ばすとコストだけがかさんでいくことになるので。
―――― 見込んでいた売上がまるまる 1 ヶ月たたないとか。
そうなんですよね。
あと難しいのは、作ったことのない機能が多くなるので、予測がしづらくなるというのもあります。見積もりとかも相当ずれるというのもありますし、見積もりがそもそもしづらいというのもありますね。
アカツキでの成長
―――― ここまでの話で、アカツキでいろいろチャレンジしてきている内容が伝わると思うんですが、本人としてアカツキで成長できたなと思うポイントってありますか?
成長したことはたくさんあるなと思っていて、プロダクトに対する考え方とか、そもそもゲーム業界じゃなかったので、すべてが自分にとっての成長になったと思います。
いちばん成長したのは根本から考えるところかなと思っていて、自分がそのエンジニアなのか、マネージャなのかというところで悩んでいたところとか、あとはチームに開発とは? とか、いまの新規開発とは? とか、根本から考えるということを、ちゃんとやれるようになったというのは、すごく大きな成長かなと思います。
―――― なぜ根本から考えるようになったんですかね?
今日すでに話した内容にも出ていますが、根本や前提から考えないで表面上の議論をしていたりとか、表面上取りつくろったりして何かをやっていても最終的にうまくいかなかったりとか、その下にある爆弾が爆発して… というのを何回か経験しているというのも大きいと思います。あとはやっぱり自分の中でモヤモヤし続ける、すっきりしないまま進めてしまうっていう、そこが耐えられないからかもしれません。もうその根本から考えるということが重要だってことをわかった状態にある以上、根本から考えないでやることに抵抗があるというか。
―――― たしかに取りつくろうよりは、過去の自分達を否定することになっても、根本の問題解決をしようという傾向が、アカツキにあるような気がします。
アカツキでよく言われるキーワードだと、より良くなるために、グレートになるためにどうすればいいか、グレートな状態は何かをけっこう CEO の塩田さんたちが口にしているので。これはそもそも『ビジョナリー・カンパニー②飛躍の法則』(ジム・コリンズ 著)という本から来ている内容なんですけど、そういうところが大きかったのかもしれないですね。
現状に満足しないというか、どんなに売上が良かったり、最高益だったとしても、必ずプロブレムを見つけ出して、それを改善していくというのを会社全体で常にやり続けているという姿勢からきているのかもしれないですね。
スクラムマスターからエンジニアリング・マネージャへ領域を広げる
―――― 湯前さんはスクラムマスターとして、担当チームを良くするというのが業務の主軸にあって、それでチームにも会社にも貢献しているんだけど、今さらにエンジニアリング・マネージャとして、エンジニア全体のチームをどうするか、採用をどうするか、今後評価制度をどうするかというところにも関わろうとしているじゃないですか? ある意味すげー忙しいのにそこにチャレンジしようと思うモチベーションって何なんですか?
まず一つは、未知なことに挑戦したいからですね。スクラムマスターはやるべき業務が明確になっていて、何かチームにこういう課題があるとか、あとはいつのタイミングに発動させるかというのを見ながらやっているというのがあって、ある種自分の中では型が定まりつつあります。一方、それ以外の領域はまだぜんぜん見えていないところなので、もっと自分の知見を広げたいなというのがあって、他のことも挑戦してみたいと思っています。もっと広い視点に立った時に、どういうことなんだろうか、見えてくるものは変わるんだろうか、とか。
あとは、最近読んでいる本とかにも感化されているのかもしれないですけど、幸せな状態で働きたいんですよね。それは自分もそうなんですけど、いっしょに働いている人たちが幸せな状態で働きたいと思っていて、だからそこをちゃんと考えたいなというのもあるかもしれないですね。
―――― いま読んでいる本というのはどういうものですか?
ひとつは『Managing for Happiness』 (Jurgen Appelo 著)、 もう一つは 『Joy, Inc.』 (リチャード・シェリダン 著) です。どちらも最近出た本で、タイトル通りなんですが、自分も周りの人も喜びを感じながら幸せに働くためにはどういうマネジメントができるか、どういう組織づくりができるか? について述べた本です。
―――― スクラムマスターとか、エンジニアリング・マネージャをやるにあたって、エンジニアのときの経験って活きると思います?
難しいですが、スクラムマスターって技術のことを基本的には指示しない立場なんですよね。しない立場なんですが、自動化の重要性とかもわかっていないといけないし、これまでの経験上、こういう技術を使ったほうがいいとか、こういうシステムを導入した方がいいとか、先にこれをやっておいた方がいいっていうのはあって。それをなんとなく、それとなーく (笑) 言うという点では活きています。
エンジニアリング・マネージャとしても、エンジニア特有の悩みをわかっていないとエンジニアにとって良い施策を打てないと思っています。先ほどお話したコードを書くのかマネージメントなのか、問題もありますし、技術の学習や情報共有をどうすればスムーズに行えるか、とか。こちらも気づきを与えるようなコミュニケーションを出来るだけ取るようにしています。
―――― 自分が決める役割ではないけど、気づいてもらう?
物事をより良くするためには、個々人の主体性が必要かなと思っています。
スクラムマスターとしての例をあげます。プロダクトオーナーはどんどん目に見えるビジネス価値を追い続けようとするので、目に見えない価値に工数を割くことに対してあまり理解されなかったりします。一方、開発メンバーはこの改善に数日もらえれば劇的に効率良くなる、というアイデアを持っている場合が多いのですが、中々それをプロダクトオーナーに説明しきれない場合があります。そのため、こういうことが大事ですよ、自動化とか、システム化とか、フロー化とか、リファクタリングとか、やり続けないといけないですよ、とプロダクトオーナーが認識し、理解するのをサポートします。一度理解して、あとは結果を出せば、プロダクトオーナーももっと改善出来ることは無いか、と主体的に考えるようになります。そういうサポートをする意味で今までの技術知識が活きているかなって思います。
―――― 開発メンバーがやりたいと思っていることをプロダクトオーナーに翻訳してあげる役割をするんですか?
場合によってはやりますけど、どちらかというと直接言うのをサポートしていますね。話したいって言ってるみたいですよ、って伝えてみたり。
プロダクトオーナーと開発チームの関係ってトップダウンになりやすいですし、壁を作りやすいので、その壁を取っ払う役割として働いたりしてます。もしもそういう提案をする場合は、自分とプロダクトオーナーのふたりだけで話すんではなくて、必ず言い出しっぺの人を連れてきて言ってもらいますね。そうやって、主役になるべき人にちゃんと主役になってもらうようにしています。
