Interdisciplinarity の必要性

我々は、常に新しい分野や新しいプラットフォームへのチャレンジを続けていますし、ビジネス環境も非常に早く変化しています。

このような、答えのない問題になんとか道筋を付けていかなければならない状況において、強すぎる分業、強すぎる上下関係は失敗の原因を作ります。往々にして「失敗の原因を求めやすいあちら側（他部署や上司）」を作ることになってしまうからです。

ゲームやサービスが成立するには、様々な人が必要です。プロデューサー、企画者、2D や 3D のグラフィッカー、UX や UI のデザイナー、スクリプター、データワーカー、KPI のアナリスト、マーケター、ユーザサポートなど、多くの専門性を持った人々が渾然一体となって、上下関係なく一つの目標に向かうチームにならないと、成功しないのです。

我々の仕事は、本質的に interdisciplinarity を必要としています。

プロジェクト指向の席配置

こういった考えはまず、 Aiming での「席配置」に現れています。ゲームは試行錯誤の連続でブラッシュアップされていくものですから、やるべき変更を「できない」と言った時点でクソゲーを作って終わりです。
企画者を信頼し、時には自らが企画をしたりビジネスの根本を考えたりして、可能な限りチームとしての Output の価値が高まるように努力をすることに、専門性の垣根はありません。

よって、「エンジニアの島」のような形で席を分けるのではなく、目的が一緒の人は職種も何も関係無く、１カ所に集まって仕事をするのです。

T型スキルの価値と勉強会

専門性による分業が失敗の原因を作ることは、エンジニアリングについても同様です。「サーバ開発は誰」「クライアント開発は誰」「DB設計は誰」といった形で分けると、問題が起こったときに「これはサーバ開発者のせいだ」となりがちです。

オンラインゲームでは、サーバもクライアントもデータベースも連動して動かなければ機能が成立しないので、少なくともクライアント担当者がサーバ担当の言っていることを理解できる程度の経験が無いと、相手の主張を理解できずにケンカになったりするのです。

自分の専門外の広く浅い知識や経験と好奇心は、ケンカを少なくするという意味で重要なのです。

Aiming では、毎週エンジニア勉強会を行っています。 勉強会は、知識を広げるきっかけ作りに非常に重要です。

3D やゲームエンジンの話、ウェブサービスのスケーラビリティの話、ソースの管理やデプロイ方法の話、インフラの話などなど、非常に多様な勉強会が行われており、プロジェクトに関係無い技術分野の勉強会へも参加が推奨されています。

好奇心の価値

T型スキルは好奇心の発露であり、好奇心とは変化を楽しむ能力のことです。

エンジニアとして自分の慣れ親しんだ言語やライブラリやプラットフォームに固執しすぎることは、変化に億劫な風土とレガシーなシステムを作ってしまいかねません。Xのスペシャリストとは、 X だけをよく知っている人ではなく、Y も Z も知った上で X の善し悪しを理解している人です。Xが陳腐化すれば捨てることも辞さないのが、本当のスペシャリストです。

個人の好奇心こそが、新しい環境に常に触れられる組織風土を作り、こうした風土が、陳腐化への耐性と、新しいチャレンジを可能とする組織的な土台を作るのです。