Aimingの開発クレド
Aimingでは、エンジニアが生み出すコードや設計の品質、そして、ノウハウやアイデアのアウトプットを重視しています。
これらは、大規模化するゲーム開発において、チーム全体やメンバー個々の成長に寄与するものです。
こういった成長により、より多様な得意分野を持つメンバーで構成されるチームを築くことができます。
また、柔軟な変化に対応できる開発手法を取り入れることで、改善を繰り返しながらプロジェクトを進めます。
こうして構築されたチームや開発手法によって生み出されるゲームは、より面白く、品質の高いものになると信じています。
Aimingには、さまざまなスキルを持つスタッフが揃っています。
たとえば、クライアントエンジニアには、Unityに精通していたり、C#を得意としていたり、3Dグラフィックスの表現に長けていたり、ソフトウェア設計に強いこだわりを持っているなど、多彩な人材が在籍しています。
サーバエンジニアにおいても、ウェブアプリケーションの開発が得意だったり、リアルタイムサーバが実装できたり、データベースへの高い理解を持っていたり、高負荷に耐えうるサーバの設計・実装ができる、などといった多様な専門知識を持つエンジニアがいます。
エンジニア以外では、ゲームプランナー、UIデザイナー、3Dデザイナー、運営担当、マーケティング担当、インフラエンジニアといった多くの職種のスタッフが在籍し、ゲームの企画から制作、運営までを一貫して行える環境が整っています。
企画フェーズから運営フェーズまで、ゲーム開発のすべてにおいてエンジニアもチームの一員として関わることができる環境がここにあります。
採用や組織編成など、業務のあらゆるところでソースコード重視、アウトプット重視のポリシーを置いています。
作業は工程で分担するのではなく、一人のエンジニアがある機能が完成するまでのすべてをおこないます。この方が責任も明確ですし、作る実感も湧きます。
また、GitHubを使ったコードレビューもおこなっています。コードレビューは、品質保障の点と技術者としての成長の点という2つの点で重視しています。
採用においては、あなたが世の中に何を公開しているか、あなたが個人の興味によって何を作ったかを常に評価します。
どこの大学を出てどんな資格を取った、どの会社で何のプロジェクトに参加したといったことよりも、GitHubのコードや、オープンソースへのコミット、オープンでなくても個人的に作ったオレオレツールやスクリプト、作りかけの dog food、ブログや SNS などを見ます。
これは、所属した組織ではなく「あなたが実際に生み出した価値は何か」に興味があるからです（もちろん、今まで会社の中で価値を出してきた人もいるので、すべての人をこの軸で評価するというわけではありません）。
また、自分で作った何かを公開していることは、小さくても世に出して評価される勇気を持っていることの証明です。これは非常に立派なことです。
孔子の言葉に「子曰く、これを知る者はこれを好むものに如かず。これを好むものはこれを楽しむ者に如かず。」というものがあります。
「知るひとは好いている人に、好いている人も楽しんでいる人には及ばない」という意味です。
個人のアウトプットは、あなたが何を好きで、何を楽しんでいるのかを如実に表しています。
何を考えて、何を作ったのかを話してください。
そして我々と一緒に好きを追求し、エンジニアリングを楽しみませんか？
業務において「チーム対問題の原則」というシンプルな原則を置いています。
問題が起こった際「あいつが悪かった」などと個人のせいにしても何の解決にもなりません。
また、問題は誰かが一人で解決できるということは無く、チームのみんなで解決にあたる必要があります。
犯人探しなどをすることなく、個人ではなくチームで問題に対峙することが、「チーム対問題の原則」です。
この原則は無意味な魔女狩りを避け、解決のための協調性をチームにもたらす、非常に根源的なポリシーです。
作るものが大きくなっていくにつれ、一人の人間がすべてを把握することはできなくなっていきます。
これを認めた上でチームを作らないといけませんが、ここでカギとなるのが、チームとしての「みんなの目」の存在です。
みんなが見ていれば誰かが間違っていると気がつくはずですが、その気づきを顕在化できるかどうかは組織の問題です。
組織が「言ってもムダ」という諦観を抱いてはいけません。
適度なユルさや適度な友達っぽさは、問題発見を早期化し、チームとしてのロバストネス（頑健性）を強化します。
「これってそもそもおもしろくないんじゃない？」「それ、間違ってない？」といったツッコミは、（発言の表現は適切な節度を持ちながらも）上司や外部の方にも軽く言えるようにしなければなりません。
ですから、なるべくチームを一カ所に集め、チャットを使って、ひたすら友達のようにやりあいながらもの作りを進めています。
これを Aiming では、「ツッコミビリティの確保」と表現し、面白いゲームを作るために大事にしています。
我々は、常に新しい技術や新しいプラットフォームへのチャレンジを続けています。ゲームを取り巻くビジネス環境も非常に早く変化しています。
このような答えのない問題に、なんとか道筋を付けていかなければならない状況において、強すぎる分業や強すぎる上下関係は失敗の原因を作ります。往々にして「失敗の原因を求めやすい、あちら側（他部署や上司）」を作ることになってしまうからです。
ゲームやサービスが成立するには様々な人が必要です。プロデューサー、企画者、2D や 3D のグラフィッカー、UX や UI のデザイナー、スクリプター、データワーカー、KPI のアナリスト、マーケター、ユーザサポートなど、多くの専門性を持った人々が渾然一体となって、上下関係なく一つの目標に向かうチームにならないと成功は難しいでしょう。
我々の仕事は本質的に interdisciplinarity を必要としています。
専門性による分業が失敗の原因を作ることはエンジニアリングについても同様です。「サーバ開発は誰」「クライアント開発は誰」「DB設計は誰」といった形で分けると、問題が起こったときに「これはサーバ開発者のせいだ」となりがちです。
オンラインゲームでは、サーバもクライアントもデータベースも連動して動かなければ機能が成立しないため、少なくともクライアント担当者がサーバ担当者の言っていることを理解できる程度の経験が無いと、相手の主張を理解できずにケンカになったりします。
自分の専門外の広く浅い知識や経験と好奇心は、ケンカを少なくするという意味で重要です。
全社横断であったり、事業部内や開発プロジェクト内で定期的、不定期にエンジニア勉強会を開催しています。 勉強会は知識を広げるきっかけ作りに非常に重要です。
過去には 3D グラフィクスやゲームエンジン、ウェブサービスのスケーラビリティ、ソースの管理やデプロイ方法、インフラの話題など、多様な勉強会が行われています。プロジェクトに関係のない分野の勉強会への参加も推奨されています。
T型スキルは好奇心の発露であり、好奇心とは変化を楽しむ能力のことです。
エンジニアとして自分の慣れ親しんだ言語やライブラリやプラットフォームに固執しすぎることは、変化に億劫な風土とレガシーなシステムを作ってしまいかねません。Xのスペシャリストとは、 X だけをよく知っている人ではなく、Y も Z も知った上で X の善し悪しを理解している人です。Xが陳腐化すれば捨てることも辞さないのが、本当のスペシャリストです。
Aimingでは、早い段階で全計画を決めすぎず、変化を許容することによって、ムダとケンカと失敗を最小限に抑える開発をおこなっています。
ゲーム開発やサービス開発は、試行錯誤の積み重ねの上にできていきます。モノがない段階で頭の中にあるイメージのみで方向性を固めてしまうよりも、そこにあるものについて議論をする方が、人間は圧倒的に具体的で建設的な議論ができます。これこそが試行錯誤すること、変化することの価値です。
今ある多くの開発手法は、ソフトウェア開発における先人の多くの失敗と成功の経験から生まれました。
先人の知恵を学ばないことは愚かですが、一方で教科書通りにことを行えばOKという話でもありません。変化を許容するという思想からも分かるように、常に自分たちにとって最適なやり方は何かを考え、自らを変えていくことに合意していることこそ本質的な価値だと考えています。
