はじめに
QualiArts Advent Calendar 2019、最終日、25日目の記事を担当するygenkiです。
QualiArtsの技術責任者をしています。
弊社では前身となるAmebaゲーム時代から技術戦略を毎年決めて実行に移してきました。
これまでの技術戦略と実際に実行してきた事や結果をお話したいと思います。
弊社ではエンジニア主導で様々な取り組みを行っていますので合わせて読んで頂けると幸いです
QualiArtsの技術組織と技術文化について
2014年：「ネイティブ技術者の拡大」
前年の2013年は弊社のブラウザゲーム全盛期で毎月1本以上のブラウザゲームをリリースしていました。
一方でネイティブゲーム市場が拡大している時期で開発体制をネイティブ開発にシフトする必要がありました。
ブラウザゲーム開発組織からネイティブゲーム開発組織にシフトするために、
「ネイティブ技術者の拡大」を技術戦略に置き、ネイティブ技術者育成施策を実行しました。
NGU（NativeGrowUp）
NGU（NativeGrowUp）というネイティブ技術者育成施策を実行しました。
ネイティブ開発経験がある人が中心となり、Unityとcocos2d-xの自己学習を中心とした研修プログラムを作成、運営する「NGU室」という組織を設立。
研修プログラムは指定されたゲームの一部を忠実に再現するという内容で、初心者でも楽しみながら技術を習得する事が出来るよう工夫しました。
Webフロントエンジニアからサーバサイドエンジニアまで広く募集し、初期は23名が受講しました。
最終的に最終試験に合格した人でネイティブ転向意向を持っていた人がUnityエンジニア/cocos2d-xエンジニアになりました。
NGUは定期的に行われるようになり、最終的に50名以上のエンジニアがNGU研修を受講しました。
2015年：「ネイティブ技術の強化」「開発ディレクターの新設」
ネイティブ技術者の拡大に継続して力を入れるため、Unity技術の強化、ネイティブ開発体制の整備を決めました。
Unity技術の強化
ネイティブ技術者の拡大のためには技術選定をする必要があると判断しました。
当時はcocos2d-xとUnityの2つの技術を利用していましたが、3Dゲーム開発との相性が良いためUnityに絞る事にしました。
ネイティブ開発体制の整備
ブラウザゲーム開発では、サーバーやWebフロントの職種リーダーが開発から品質管理、技術判断、チームマネジメント、スケジュール策定などほぼ全てのエンジニア業務を担っていました。
開発規模が小さい時は何とかなりましたが、開発規模が大きくなるにつれて職種リーダーが管理に追われ開発を行う事が出来なくなりました。
開発規模が大きくなった事で職種リーダーが開発もチーム管理も行うのは難しく**「開発全体のリーダー」**が必要になりました。
開発全体のリーダーが出来るまで
開発全体のリーダーとはどんな役割か。
技術ボードや職種リーダーを中心に議論を重ねました。
プロダクトマネージャーを新設してみる
まず開発全体のリーダーとして、プロダクトマネージャーの役割を新設する事にしました。
当時、想定していたプロダクトマネージャーは以下です。
（振り返ってみると、一般的なプロダクトマネージャーとは異なりますね）
プロダクトマネージャーの定義
-
プロダクトマネージャーの方針
-
エンジニアとして一人前のスキルを持っている人
-
プロダクト目線を持っている人
-
新規サービスの立ち上げ経験がある人
-
エンジニアのキャリアパスの中の1つとして目指したくなる役割にする
-
プロダクトマネージャーの立ち位置
-
開発現場の代表
-
プロデューサーと対等な立場で連携し実現したい事を具体的に開発に落とし込む
-
プロダクトマネージャーは開発現場の代表者として責任を持ち、的確な判断を行う
-
プロダクトマネージャーの役割
-
QCDの担保
-
システムアーキテクチャ責任
-
問題解決
-
メンバー育成
この方針に沿って職種リーダーの一部がプロダクトマネージャーになり、それぞれのプロジェクトで半年間携わりました。
プロダクトマネージャーを導入した結果
結果として開発がスムーズに進行するなど良い兆しが出てきました。
- 役割が明確になり、スケジュール管理や改善の取り組みが行いやすくなった
- 職種リーダーが開発に集中出来るようになった
- 将来的にプロダクトマネージャーを目指したい人が一定割合出てきた
一方で課題も出てきました。
- プロダクトマネージャーの定義、他職種との役割の線引きが曖昧
- 実装から遠ざかる事によるキャリアの懸念
- 責任はあるが権限が無い領域がある
課題の原因と対策
プロダクトマネージャーの定義、他職種との役割の線引きが曖昧
プロダクトマネージャーの組織への浸透不足とプロダクトマネージャーの定義が理想が先行していた事が要因でした。
プロダクトマネージャーの役割が広くなってしまったため絞る事にしました。
最終的に開発管理（スケジュール）と品質管理の2つに絞りシンプルにしました。
実装から遠ざかる事によるキャリアの懸念
プロダクトマネージャーも実装を行える仕組みが欲しいという希望とエンジニアのキャリアパスにプロダクトマネージャーが無かった（エンジニアのキャリアパス自体が無かった）事が要因でした。
開発管理と品質管理が出来ていれば必要に応じて実装して良い事を明文化しました。
また、エンジニアのキャリアパスの策定は必要と考え、後述するキャリアパスを整備しました。
責任はあるが権限が無い領域がある
ゲーム開発は仕様変更が頻繁に発生するため、当初計画した開発スケジュールに責任を持っていても形骸化する事が頻発しました。
企画（仕様変更）の最終責任はプロデューサーであるため、仕様変更や追加によるスケジュール遅延には責任を持たない事にしました。
仕様変更や追加が発生した場合は、修正後のスケジュールに責任を持つ事にする事で解決しました。
開発ディレクターに名称を変更
プロダクトマネージャーに取り組んだ結果を受けて、名称を開発ディレクターに変更しました。
開発ディレクターの役割を**「開発管理と品質管理＋α」**に変更し、+αの部分は各自が考える事で個性を活かした開発ディレクターが生まれました。
弊社の開発ディレクターについては以下の記事でも紹介しています。
開発ディレクターとしての役割
今では開発全体のリーダーとして開発ディレクターが浸透しており、プロダクト開発の重要な役割を担っています。
2016年：「スキルUP」「品質向上」
2016年はネイティブゲームの開発ラインが増え、プロダクトに要求される品質も高くなってきました。
また、ブラウザゲームは1年間でリリースする事が多かったのですが、ネイティブゲームではリリースまで2〜3年かかるのが当たり前になり、新規開発経験を積むペースが遅くなってしまいました。
ゲーム開発の長期化に伴い、新規開発経験のイテレーションスピードは落ちる中で更なる品質向上が求められる状態になったのです。
この状況を踏まえ、**「プロジェクト内でのスキルアップ機会の創出」と「品質向上のための専門性」**を強化する事にしました
プロジェクト内ローテーション
プロジェクト内でのスキルアップは、「誰もが全ての開発・運用を担う事が出来る状態にする」事を目標に置き、「プロジェクト内ローテーション」を行う事にしました。
まずプロジェクトメンバーのスキルを可視化しました
空白の項目が未経験となっているので、誰に何を任せるかチームリーダーと決めて目標を立てました。
（理想はペアになる人がお互いの経験を教え合う事で空白を埋めていく）
プロジェクト内ローテーションは開発スピードや品質が下がるリスクもあり、慎重に進める必要があると考えていましたが、懸念していた事は発生しませんでした。
新旧担当者が密に連携して開発に影響が無いように取り組んでくれたためです。
また、同じ機能の改修を継続するとモチベーションが下がる要因になりますが、
プロジェクト内ローテーションはモチベーションアップに繋がる事もわかりました。
適切な役割のローテーションはスキルUPとモチベーションUPに繋がる事がわかりました
テクニカルアーティストチームの設立
プロダクトの品質向上のため専門性を強化するため、テクニカルアーティストチーム（TAチーム）が設立されました。
弊社のTAチームについては以下の記事で詳しく紹介しています。
テクニカルアーティストが3Dのワークフローを改善した話
キャリアパスの策定
当時、エンジニアのキャリアパスとして明示されたものは特にありませんでした。
開発ディレクターが浸透してきたため、リーダー職やマネジメント職も含めたキャリアパスの策定を行いました。
シニアリード
特定領域の強みを持ち、組織における影響力が大きい
-
技術マネージャー
-
事業視点を持ち、技術組織を牽引する技術責任者
-
アーキテクト
-
複数の技術を習得し、アーキテクチャ設計に精通。全体のプロジェクト管理や基礎・中核部分の設計や仕様策定などを行う開発全体の総指揮者
-
シニアリードエンジニア
-
専門領域に特化した唯一無二の技術を持つスペシャリスト
リード
組織全体に技術的な影響力を持つレベル
-
リードエンジニア
-
高い独自性を持ち、技術的な課題の把握や解決をし、また組織への技術伝播や促進が行えるエンジニア
-
開発ディレクター
-
全体を把握し、開発を進めていく上での課題解決や判断を行う現場監督
シニアエンジニア
職種リーダーとして新規サービスを開発できるレベル
担当領域における高い技術力を持ち、事業ニーズに合わせた技術的な判断が行え、開発メンバーをまとめるエンジニア
- 求められる要素
- 本質的な技術力
- チームリーダーになれる自走力
- サービスを良くするための技術貢献目線
キャリアパスまとめ
弊社のキャリアパスの策定はこれが初めてでした。
現在は評価制度の整備なども進めており、ご紹介したキャリアパスから変更が入っていますが、基本的な考え方は変わっておりません。
2017年〜現在：「3D超加速」「技術アップデート」
2017年以降は現在進行形で様々な取り組みを行っています。
オルタナティブガールズの開発を通して3Dゲームの開発の知見を得る事が出来ました。
3Dビジュアライズラボという組織を設立するなど3D組織の強化を行っています。
技術組織としても「3D超加速」をテーマに関連する技術力の向上に努めています。
技術アップデート
現在は**「技術アップデート」**をテーマに掲げて新技術の導入を積極的に行っています。
バックエンドの開発ではNode.jsを採用することが多かったのですが、最近ではGolangの採用が増えています。
弊社では開発するプロダクトに合う技術の選択を行っているため、開発言語の縛りはありませんが、開発メンバーの経験値が高いものを採用する傾向がありました。
バックエンドエンジニアが集まった懇親会で多くのエンジニアがGolangにチャレンジしたい事が判明して採用に至っています。
これまでの経験を活かしながら、最新のアーキテクチャで開発を行っていく組織に変わってきました。
まとめ
QualiArtsで取り組んできた技術戦略をご紹介させて頂きました。
振り返ってみると成功も失敗もありますが、継続的に技術戦略を考えて「まずはやってみる」精神で取り組み、すぐに軌道修正を行う事を繰り返した結果、少しずつではありますが技術組織が強くなってきていると感じています。
「まず、やってみる」
精神を大切に、継続していきたいと思います。
他にも開発効率化のためのツール開発や基盤開発を行うなど、様々な取り組みを行っていますので参考にして頂ければ幸いです
複雑化するAssetBundleの配信からロードまでを基盤化した話【CEDEC 2017】
最後に
QualiArtsとしてのアドベントカレンダーは初めての取り組みでしたが如何だったでしょうか。
QualiArtsは**「ずっとおもしろいセカイをつくる」**ために日々奮闘しております。
おもしろいプロダクトを生み出すために、QualiArtsのエンジニアは技術を楽しみながら新しい挑戦に挑んでいきたいと思います！
来年のアドベントカレンダーもお楽しみに！