CodeIQ MAGAZINECodeIQ MAGAZINE

【アカツキ×Aiming対談】スタートアップのCTOが語るエンジニアリングチーム文化の作り方

2015.03.06 Category:インタビュー Tag: , , ,

  • 17
  • このエントリーをはてなブックマークに追加
akai-1

スマートフォンゲームの開発を主力事業に据えて急成長を続けるアカツキとAiming。外部にエンジニアリング・ポリシーを公開し、企業の枠を越えた勉強会の開催にも熱心など、共通点の多い企業だ。

エンジニア組織を率いるCTOの役割、組織文化の作り方、技術者採用など、互いが抱える悩みをぶつけ合いながら、これからのエンジニア像を探ってもらった。
by 馬場美由紀 (CodeIQ中の人)

互いに意識し合う関係。開発者ポリシーにも共通点

──初対面ということなので、簡単に自己紹介から。

小林(Aiming):僕自身はMO/MMOといったオンラインゲームが日本でも作られるようになってちょっと経った頃から、ずっとこの業界にいます。 オンラインゲーム開発用のミドルウェアを売りながら受託開発をしていたこともあるし、パブリッシングと開発の両方をやる会社にいたこともあります。 Aimingは後者ですね。一時は北京で開発会社をやっていたこともありました。

僕は今、Aimingでは「チーフエンジニアリングオフィサー=CEnO」という肩書にしています。 CTO、「テクノロジー」というとちょっと技術寄りっぽくなりすぎかなと感じまして、もう少し広く、エンジニアの組織づくりとかも含めた語感にしたいという思いがあって、そう名乗っています。

▲株式会社Aiming 最高技術責任者 開発グループ ゼネラルマネージャー 小林俊仁氏

田中(アカツキ):CTOになったのは2014年末からで、ゲーム開発自体がアカツキに入った4年ぐらい前からです。それ以前はユーザー系のSIerで、ERPの導入や社内技術標準化などをやっていました。実態はExcelとPowerPointで仕事をしているようなもの。

このまま終わるのは嫌だと思って、バリバリ開発ができるアカツキに転職しました。現在は、アカツキの技術全体を把握しているつもりですが、これからはもっと組織づくりにも力を入れたい。現場でコードを書きながら、かつ組織マネジメントもやるというのが理想ですね。

▲株式会社アカツキ SG Guild/CTO ハッカーLv.6 田中勇輔氏

小林:それいいですね。僕の場合は現在、経営と現場をつなぐマネジメントが中心の仕事です。例えばプロジェクトAで起きた問題が、Bでも起こるといったことが無いように、横串に刺して情報を共有する。炎上していたら解決に導く。 あとは技術PRや採用教育といったことですね。コードを書く能力は圧倒的にすごい人がたくさんいるので、僕が書いているとみんなに怒られます。(笑)。

田中:お互い業態がよく似ていますよね。技術的にも近いところにあるんじゃないかと思って、前から小林さんとは話をしてみたかったんですよ。

小林:そうなんですよね。Rubyでサーバー書いてて、かつゲーム作ってる会社ってそんなに多くはないですよね。だから、アカツキさんのことは勝手にライバル心を抱きつつ、参考にしたりしていました。

田中:Aimingさんってコーポレイトサイトに「開発者クレド」を公開しているじゃないですか。「変化は善なり」とか「コードの重視・Outputの重視」とか。あの内容、僕らもすごい参考にしているんですよ。

小林:ありがとうございます。それ、僕が書きました。Aimingを設立したときはまだ専任のWeb担当がいなかったんで僕が見てまして、そのついでにしれっと入れちゃいました。最初からウチの技術方針みたいなものを出しておいたほうが、採用のミスマッチも減るし、会社が発展していく上での方針めいたものとして機能するかな、と。意外とこういう開発者の心構えみたいのって、組織が大きくなると忘れがちなんですよね。

田中:僕らは僕らで「アカツキ流開発」というものを公開しています。そこでは「最高の方法を考えないのは悪」とか言い切っちゃっているし、考え方はAimingと結構近いかも。「最良のアーキテクチャは、自己組織的なチームから生み出される」とか、「良いものは全エンジニアで共有」とかも、なんか似ている気がする。

小林:いいモノを作れる組織のあり方を突き詰めていくと、考え方が似てくるのかもしれないですね。

開発者が楽しんでいないゲームは、ユーザーも楽しめない

──例えば、Aimingの開発者クレドの「プロジェクト指向組織」というところに書かれている、インターディシプリナリティ(学際性)の必要性という言葉。これ、Web業界の他の会社のCTOと話したときも、同じフレーズが出てきました。

小林:僕らの場合、チームで仕事をしているわけですが、それをやれ企画者だ、デザイナーだ、エンジニアだと職種でチームを切ってしまうと、それ自体が壁になっちゃうんですよ。その壁はケンカの素になる。エンジニアの中でも例えば、クライアントエンジニアが障害をサーバーエンジニアのせいにしたりといったこともある。

田中:あるある(笑)。

小林:要はチーム内でのケンカを減らしたいんですよ。自分はプランナーだ、など区切ってしまうところからは何も生まれない。気持ちよく仕事をするために、他者の仕事を尊敬してうまくチームになるために必要な、最低限の他職種理解は持っておきましょうということですね。

もちろん意見が異なる場合はぶつかり合いますよ。ただ、そこでは自分がどういう立場に立って議論しているかが重要。目標を達成するための建設的な議論なのか。単に自分を正当化するための議論なのか。そこは区別しないといけない。つまり、いい議論と悪い議論があるわけで。

田中:悪い議論は全て相手のことを理解しようとしないところから始まる。決して仲良しこよしがいいというわけじゃないけど、プロジェクト内では相手の立場に立って考えるぐらいの最低限の人間関係を構築しようよ、ということですよね。

アカツキ流開発の一つに「ワクワクして開発する」というのがあるんですが、ワクワクしないといいものは作れない。ワクワクしてやればきっと面白いものが作れるはずだ、というのは僕の持論でもあります。

小林:開発者が楽しんでいないものって、絶対におもしろくならないんですよ。データ分析で改善はできると思いますが、いいゲームの核を産み出すことはできませんよね。開発者が勝手に、自分のプロダクトを楽しんでいる。開発者であると同時に一人のプレイヤーである、そういう開発は気持ちいいですよね。

田中:ここを0.1秒速くしたら、ゲームが面白くなる。でも、それができるのは開発者だけ。開発者がやる気になるかどうかが、ゲームが面白くなるかどうかの分かれ目ですよ。もちろんビジネスだから収益性というのも大事。

だから、収益に絶対的にコミットする人は必要だけれど、エンジニアが全員それを考えるかどうかは別。僕はときには役割を分離してもいいと思っています。売上げ優先という命題と、エンジニアとしてのここまでは作り込みたいという想いがぶつかったら、そこではエンジニアは妥協しないほうがいい。対立したら議論すればいいだけだから。

小林:エンジニア自身が売上責任を持ってるわけではないですが、収益や面白さにまったくコミットできないエンジニアはそれまでだと思ってます。だって、収益がないとゲームは続かないし、お金を払ってもらうためにはゲームが面白くないといけない。そういう意味でのサービスとしての価値を追求することがエンジニアには求められている。面白いと感じていただき、長く遊んでいただければ、結果的に売上げはついてくると思っています。

田中:ただ、売上げに直接コミットしている担当者は、短期的な利益を求めてきますよね。

小林:そうですね。短期的な利益とのバランスというのはエンジニアリングに限った話ではないんですが、例えば本当に短期的に売上げを上げたかったら、超スーパーウルトラ最強の剣みたいなアイテムを出せばいい。 そしたら一時期はメチャ売れますよ。でも、それがゲームバランスを崩してしまってサービスとしての寿命を縮めるでしょう。一方で、逆に売上が無いとサービスは続かない。技術にしろ何にしろ、絶妙なバランスを求めて議論できる素地がそのチームにあるかどうかが重要なんじゃないかな。

田中:「売上げにコミットする人が権限を握っているプロジェクトのゲームは、結局たいてい失敗する」というのが僕の経験則でもありますね。逆に、売上げまったく考えないチームも失敗しますけど。そのバランスが重要。みんながフラットなチームで、かつお互いのことをわかり合っていて、議論が活発なチームであることこそが、成功の条件だというのは全く同感です。

変化は善なり。変化すればこそ、基礎的な力もついてくる

小林:僕らのクレドの中に「変化は善なり」という言葉でアジャイル開発に触れた部分があります。僕らがアジャイル開発をやっていることはもちろんなのですが、それは、今スマートフォンゲームが急成長する中で、どういうゲームが当たるかわからない状況があるから。どんどん出して、失敗したらまた変えてというプロセスを繰り返さないといけないからなんです。

変化を許容しない文化や組織では勝てない。「変化は善なり」という言葉は、技術的にもプロダクトとしても、常に世の中の先を見ていかないといけないという覚悟なんですね。

田中:もちろん、だからといって、技術の蓄積を無視するわけじゃないんですよね。ITの技術階層ってのは面白くて、いちばん下のレイヤーにはアルゴリズムやデータ構造がある。これは普遍的な知識。これはそう変わらない。その上にフレームワークの知識。

さらにその上に、新しいツールとかプログラミング言語とかがある。いちばん上の変化する要素をどんどん採り入れていくと、下部の普遍的な要素も蓄積される。変化する要素をどれだけ吸収し、チャージしたかで、ベースの幅も変わってくるんですよ。

小林:例えばJavaという言語にこだわって掘り下げているエンジニアがいたとします。それはそれで素晴らしいことだと思います。でも、関数型言語も知り、スクリプト言語やコンパイラのある言語も知ってそれでも今、自分はJavaを選択するんですと言っている人のほうが、広く浅いように見えて実は信頼されるし、深いのかもしれない。

携帯ゲームの頃はみんなPHPで書いていたし、Facebookのソーシャルゲームが流行ったときはActionScript書いてたし、今はC++とcocos2d-x とか、C#とUnityとかでスマフォのゲームを書く。一口にゲームと言ってもエンジニアに求められることは数年単位で全然変わるんですね。逆にいえば技術的な強いこだわりがあることによって波にのるきっかけを失ってしまうことだってあり得る。

田中:プログラマは単に2進数のデータを扱っているだけではダメ。それをどう扱うかというアイデアこそがエンジニアリング力になる。その観点をどれだけ持てるかが、エンジニアとしての重要な要素だと思いますね。

⇒ 後編「ゲーム会社のCTOが求める『愛あるエンジニア』とは」に続く!

対談者プロフィール

小林 俊仁氏
株式会社Aiming
最高技術責任者 開発グループ ゼネラルマネージャー

1977年生。京都大学大学院在学中からオンラインゲームの開発に関わる。2003年にコミュニティーエンジン社取締役に就任、北京に移住して中国版プレイオンラインの設計・開発、モバゲータウンの中国ローカライズ(加加城)等に関わる。2011年6月にAimingに移籍し、2013年5月から現職。

田中 勇輔氏
株式会社アカツキ
SG Guild/CTO ハッカーLv.6

1984年生。専門学校卒業後、ユーザー系SIerでERPや社内技術標準化に携わる。Rubyが大好きだったことと、「世界をハッピーにする」という熱いマインドに惹かれ、2012年アカツキに入社。Rubyとインフラが専門領域で、アプリケーション開発と並行してアカツキのインフラ基盤の整備を担当。

(執筆:広重隆樹/撮影:刑部友康)

自分の書いたコードを誰かに評価されたいエンジニアは、けっこう多い?

ITエンジニアのための実務スキル評価サービス『CodeIQ』で出題されている「コード銀行」問題に挑戦すると、あなたのコードが評価されます。

評価(1)出題者からの評価  ⇒評価フィードバック例を見る

  • 企業ではたらくという観点からあなたのコードをチェックします
  • フィードバックされた観点をふまえてコードを書くと世の中の企業にとって「いいコード」が書けるようになります

評価(2)企業からの評価  ⇒評価フィードバック例を見る

  • 「あなたと一緒にはたらきたい」という企業からスカウトが届きます
  • あなたのコードが社会でどこまで通用するか、リアルな評価が得られます

興味を持った方はこちらからチャレンジを!

  • 17
  • このエントリーをはてなブックマークに追加

■関連記事

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ