エンジニアのチャレンジを支える環境・文化とは
──前回でもお話いただいたように、変化対応力を持つエンジニア集団を作りたいというのは、お二人とも同じだと思います。そこで根本的な問い。果たして高いレベルのエンジニアを複数育てるということは、可能なんでしょうか。
田中:思考は現実化しますから(笑)。そうしようと思えば、そうできる。エンジニア一人ひとりに、自分たちがそういう人になれるんだということを信じさせる、その文化や環境をつくるのがCTOの役割じゃないかな。
小林:スーパーエンジニアでないと変化対応ができないか、というとそんなことはない。僕は本質的には変化対応力の源泉は好奇心だと思ってます。子供の頃に新しいオモチャにワクワクした経験があると思いますが、大人になると忘れてしまう。だからこそ、「いや君はオモチャで遊んでいていいんだよ」と言ってあげる。そういう環境を作ってあげる。
例えば、C++のエンジニアがRubyを書き始めても、すぐにはうまく書けないけど、「それでいいんだ、C++を知りつつ新しい言語を習得しようという君の方向性は正しい」と、稚拙であることを含めて新しいチャレンジを認めてあげる。
逆に、「僕はRubyエンジニアなんで……」とか言ってゲームクライアントを書こうとしない人もいますし、クライアント側のエンジニアが「僕らの仕事は終わりましたけどサーバーAPIができてないので動きません」、みたいな他責がケンカの火種になることもありますよね。でも実は両方できると超活躍できたりするわけですよ。
両方できれば、自分で開発を完結することだってできるわけです。実はこんなかんじで技術的なカバーエリアが広がった人は、次の技術トレンドの変化が来た時に「要らない人」になってしまう確率が減ってるわけです。 これが組織的に積み上がったものが、組織の変化の対応力である、と考えています。
──エンジニアにとって新しい言語を覚えるのは、一つのチャレンジです。それを促す仕掛けみたいなのはありますか。
小林:まず、個人レベルでの技術的チャレンジを承認することでしょうね。さらに、サーバーとクライアントとか、言語が違うけど協働すべきものを作る人達の席を近づけて一緒のチームにしちゃうってのも一つの手かも。
あと、タスク管理を分割すると、その分けたところでケンカになったりするので、なるべく分割しないようにするといいと思います。それをあなたにとっての「あちら側」ではなく、責任を負うべき「こちら側」にしてあげると言うか。こういうことによって知識が混ざる。
田中:ただ、プロジェクトが30人ぐらいになると、全員一緒というわけにはいかない。そこで僕らは、オープニングシーンとか戦闘シーンとか、シーン別・機能別にチームを分けるようにしています。それぞれのシーンに、企画者もディレクターも、サーバーもクライアントのエンジニアもいて、一緒に仕事をする。そういう分け方をすると、そのシーンについての振り返り作業が共有化されていいんです。
エンジニアを刺激するという点では、社内勉強会をよく開いています。最近は、『Understanding Computation』(Tom Stuart著)の輪読会をやっています。それと「月曜Unity会」というのもありますね。毎週Unityで何か好きなものを書いて発表する。
小林:ああ、クソゲー開発コンテストというのがウチにもありますね。(笑) あと勉強会はウチも積極的にやってます。 読書会では、『リーダブルコード』とか。 僕が主催したものだとClinton Keith の『Agile Game Development with Scrum』とか。それから、セキュリティの話とかソフトウェアに関する法律の話など、職種を越えて共通の知識になるようなテーマの勉強会もありますね。
こうした勉強会では社員がチューターになることが多いですね。けっこう社内にエキスパートがいるんだけれども、本人がそれを自覚していない場合が多くて、「おめえ、すげぇんだから、喋れよ」と言ってけしかけたりしてます。
田中:「けしかける」ってのもCTOの一つの役割ですね。輪読会、勉強会をやると「これってあの本に書いてあったよね」というふうに知識が共有化されているから、会話がスムーズになり、それを前提で仕事を進めることができるのがいいです。
アジャイル開発の成否を分かつもの
──お二人とも、高品質・効率的なプロダクトを作るために、アジャイル開発を取り入れていると思うんですが、うまくいっていますか。
田中:アジャイルではドキュメントよりも動くコードが重視されるけれど、ただ、ドキュメントが不要というわけではない。コードとドキュメントのバランスをどうするかが、最近の悩みどころではあります。
小林:かつてのSIerがやっていたような、顧客からお金をいただくために、紙のドキュメントを何センチも積み上げるとか、そういうのは意味がない。「動くコードが大切」というのは、そういう悪習を牽制するための言葉ですよね。ただこれは、ともすれば「俺はコードを書いたからいいんだ」とドキュメントを書かない人のいいわけとして使われてしまう。これはよくない。
田中:API設計のドキュメントがなければ、クライアント側はコードを書けないし、ドキュメントは絶対必要なんですけどね。
小林:アジャイルの失敗の原因は多くの場合、自分の組織の特性を考えず、教科書通りのアジャイルをそのまま当てはめようとすることにあると思うんですよね。その手の失敗はウチでもずいぶんやりました。現場を見ずに手法を強制しちゃうのは、アジャイル嫌いを増やすだけですし、そもそも強制したり手法を固定化してる時点でアジャイルじゃない。結果、プロジェクトの失敗原因をアジャイルのせいにして終了、みたいなことになります。本質的にはゴール設定も手法も定期的に見直して柔軟にやろう、というのがアジャイルですから。
田中:『アジャイルサムライ−達人開発者への道』(Jonathan Rasmusson 著)に、「狙え、構え、撃て」と書いてある。その順番はけっして間違えてはいけないけれど、だからといって、SCRUMでなければだめとか固執する人は、わかってないんじゃないかなと思う。
小林:ウォーターフォールの歴史を勉強すると、アジャイルで言われていることとおなじことが言われたりしますよね。だから、プロジェクトの失敗の原因をウォーターフォールなりアジャイルなりの手法に求めるのは愚の骨頂。問題はたいてい開発手法以外のところにあるものです。
「愛のあるエンジニア」を探し求めて
──ところで、CTOとしては技術者採用にも責任と権限があると思うんですが、採用は苦労していますか。
田中・小林:苦労してますよ。
小林:東京は苦戦してますが、ライバル会社も多いのでしょうがない。じゃあどうするかですけど、うちは勉強会をやって、来た人に声をかけて入社に結びついた例も多いですね。勉強会に来ている人はそれだけアンテナが高いということだし、オープンにやっていくというウチの社風にも合っています。
田中:エンジニアスキルがいくら高くても、ウチの文化に合わないと落としちゃう。社長が、「家族を大事にしていない人はだめ」とか、結構エモーショナルな部分で理想が高いものですから(笑)。人間への愛でもコードへの愛でもいいので、愛を語れるエンジニアに会いたいんだけど、その方法がなかなか……。
──エンジニアですから、当然コードを見て採用しますよね。
小林:最低限のエンジニアリングスキルは確認したいので、コードは見ます。ただそれ以上に、その人が本当にプログラミングなりモノ作りなりが好きなのかを僕らは知りたい。なぜなら、コーディングとかゲームを作ることになんらかの強いモチベーションを持っていないと、これから生き残っていけないですから。なので、アウトプットから透けて見える、その人の「好き」の方向性や程度を知りたいんです。
面接で「ゲーム作りたいです!」なんてのは誰でも言えるし、プレゼンだけうまい人が高く評価されちゃったりするけど、そういうのが嫌なんですね。この人、夏休みすべてを費やしてこのゲーム作ったんだなとか、そういうのって伝わりますよね。
田中:情熱のある人という条件はウチも同じですね。「GitHubにコードがあるなら見せてくれ」と必ず言いますけど、それはコードの良し悪しというより、なぜこのコードにしたのか、もっとよくするためにはどうしたいと考えているのかを知りたいから。そういうことは、面接でコミュニケーションを重ねて初めてわかることも多いです。
小林:僕の考えの根っこには「コーディングスキルは教育できるけれども、情熱やモチベーションは教育できない」ということがあります。後者をなんとか見抜きたいんですね。
田中:アカツキでよくいうところの「内発的な動機」っていうやつですね。これが高い人は、どんな仕事でも高いレベルを達成できると思います。
──対談の最後に、今日の出会いの感想を。
田中:Aimingさんって、開発者クレドとか見ていてすごいなと思ったけれど、きょう話してみてもっとすごいなと実感。外にこんな強敵がいると思うと、怖いぐらいです(笑)。
小林:アカツキさんのことはずっと意識していたんですよ。今日話してみて、すごく共感できました。いいものを作ろうとして組織のあり方を模索していくと似たものになるんですかね。その共通項の部分を確認して共感できたので、ほんとお会いできてよかったです。
⇒「スタートアップのCTOが語るエンジニアリングチーム文化の作り方」を読む!
対談者プロフィール
小林 俊仁氏
株式会社Aiming
最高技術責任者 開発グループ ゼネラルマネージャー
1977年生。京都大学大学院在学中からオンラインゲームの開発に関わる。2003年にコミュニティーエンジン社取締役に就任、北京に移住して中国版プレイオンラインの設計・開発、モバゲータウンの中国ローカライズ(加加城)等に関わる。2011年6月にAimingに移籍し、2013年5月から現職。
田中 勇輔氏
株式会社アカツキ
SG Guild/CTO ハッカーLv.6
1984年生。専門学校卒業後、ユーザー系SIerでERPや社内技術標準化に携わる。Rubyが大好きだったことと、「世界をハッピーにする」という熱いマインドに惹かれ、2012年アカツキに入社。Rubyとインフラが専門領域で、アプリケーション開発と並行してアカツキのインフラ基盤の整備を担当。
自分の書いたコードを誰かに評価されたいエンジニアは、けっこう多い?
ITエンジニアのための実務スキル評価サービス『CodeIQ』で出題されている「コード銀行」問題に挑戦すると、あなたのコードが評価されます。
評価(1)出題者からの評価 ⇒評価フィードバック例を見る
- 企業ではたらくという観点からあなたのコードをチェックします
- フィードバックされた観点をふまえてコードを書くと世の中の企業にとって「いいコード」が書けるようになります
評価(2)企業からの評価 ⇒評価フィードバック例を見る
- 「あなたと一緒にはたらきたい」という企業からスカウトが届きます
- あなたのコードが社会でどこまで通用するか、リアルな評価が得られます
興味を持った方はこちらからチャレンジを!