アートマネージャーの仕事術
ゲーム開発におけるアートマネージャーの役割とは何か

目次
● ゲーム開発の組織構造
● アートマネージャーの仕事
● アートマネージャーの連携術
● アートマネージャーに求められる能力
● 最後に

ゲーム開発の組織構造

開発総指揮
ゲームは大きく3つの要素で作られており、それぞれを
に統括者が存在します。
1. ゲームデザイン
○ ゲームディレクター
2. グラフィックス
○ アートマネージャー
3. プログラム
○ エンジニアマネージャー
3人の統括者が連携し、開発プロジェクトをハンドリン
グします。最終的な決定権はディレクターが持ちます。
3人の統括者

アート
ディレクター
グラフィックス要素には見た目の最終決定権をもつ
アートディレクター（AD）が存在します。
ADは絵作りの方向性を示し、ガイドライン策定、クオリ
ティのジャッジなどを行います。
ゲーム内のグラフィックスだけでなく、プロモーションの
観点からゲームの魅せ方についてもディレクションを
行います。絵作りの柱

リード
アーティスト
グラフィックス要素は複数のセクションで構成されてい
ます。セクションのリーダーをリードアーティスト（LA）と
呼びます。
代表的なセクションは下記になります。
● エンバイロメント
● キャラクター
● モーション
● エフェクト
● UI
リードアーティストは担当要素のディレクションと進行
管理の機能を持ちます。また自身を含めた要素の専
門家集団を管理します。
専門家チームの代表

アートマネージャーの仕事

アート
マネージャー
マネージャーの役割
マネージャーの役割は、問題を明らかにして「何とかす
る」こと。メンバーの能力を発揮させて成果を上げるこ
と。
AMは役割に基づき下記の仕事を行います。
1. 要件定義をする
2. マイルストーン設定をする
3. アーティスト人員を管理する
4. アーティスト作業環境を管理する
5. アートが関わる情報の交通整理をする

AMの仕事
何か体験を作りたいとなった時、実装に至るには様々
なことを明確にする必要があります。
● ディレクターが何を望んでいるのか？
● いつ何を誰がどのように進めるのか？
● プロジェクトとしてやるべきなのか？
● そもそも実現できそうなのか？
つまりはお金を何に使うのかを決めるプロセスが必要
です。不明瞭な点に疑問を投げかけ、ディレクターと一
緒になって要件を定義します。
1 / 5
要件定義をする

AMの仕事
要件定義が終わったら、マイルストーンを設定していき
ます。マイルストーン設定を通じてメンバー全員と下記
を共有します。
● ある期間で何とかして達成すべきこと
● プレイヤー体験がどう向上していくか
各要件のリスクやコストを踏まえて優先順位を決めま
す。人員や開発の状況を踏まえて大まかなスケジュー
ルを組みます。
優先順位の判断は下記を意識します。
● やったことが無いことを先にやる
● 出来る事ではなく、すべき事をやる
2 / 5
マイルストーン設定をする

やらない事を決める＝やる事を決める
マイルストーン設定は何をやらないか？を決めることが重要です。
グラフィックスは機能とアートの 2軸評価です。
● 機能…遊びの要件を満たす記号的な役割を満たしているか？
● アート…見た目が良いか？新規性は？インパクトはある？
遊びを作るという観点に立つと、まず達成すべきは機能面です。
アート面の評価を高めるには多くの時間が必要です。
最低限必要なアート品質を定めることが重要です。
特にグラフィックスの量産フェーズに入る前は、
仕様変更や割り込み作業が発生する可能性が高いです。
マイルストーンで行わない作業を明確にし、
善意による前倒し作業を発生させない ようにします。
［完璧を目指すよりまず終わらせろ］

曖昧な要件を受け入れる
ゲーム開発では要件定義や仕様策定を経て実装に移行しますが、
まず簡易的に実装してみて必要性や詳細を決める事が多々あります。
ゲームは時間軸、見た目、ランダム性など複雑に絡み合っており、
頭の中でロジックを組んでも完成図が見えない事があります。
机上の空論に時間をかけすぎるのではなく、
まず実際にプレイ出来るものを素早く作る事が時には重要です。
AMは要件の曖昧さを見極める必要があります。
曖昧だから詳細化してくれ！と突き返すことはしません。
やる目的と意義は理解できるが曖昧となれば、
どうすれば完成図を明らかに出来るのか？
そのためにはまずやってみるべきか？
という思考と対話をしていきます。

仮説検証は計画性が必要
まずやってみよう、検証してみよう。
そうなった時に注意すべき点が「作り込みすぎ」です。
実装したあとに有効性が見いだせず完全に削除することもあります。
検証素材に時間を掛け過ぎるのは無駄です。
仮説検証をする際は最初に下記を明確にします。
● 何を確かめたいのか？（仮説）
● 何をすれば確かめられるのか？（最低要件）
● 有効性をどう確かめるのか？（判定方法）
人はやり始めるとついつい粗さを修正したくなります。
無駄に丁寧に調整したり、余計な機能を付与したくなります。
計画性が足りてないまま検証を始めると、
何か違う何か違うと終わりの無い検証が始まってしまいます。

AMの仕事
3 / 5
アーティスト人員を管理
プロジェクトに必要な人材を定義します。そのためにも
プロジェクトの特性を見極めることが重要となります。
● ゲームジャンルは何か？
● プラットフォームは何か？
● どういった技術が必要そうか？
● どういったリスクがあるか？
● どういったチャレンジが必要か？
当然、過去に似たようなプロジェクトを経験している方
が有利です。プロジェクトで同じものは一つとしてあり
ませんが、共通する条件下では似たような問題が発生
します。
［同じ轍を踏まない］

メンバーのツール理解度は限界点となり得る
どのような人材がプロジェクトに必要か？
それを考える上でツール理解度も重要になります。
● どのような機能があるのか？
● どのような仕組みで動いているのか？
● どのような特徴や不具合があるのか？
アーティストはゲームエンジン上で複雑な絵作りが可能です。
特定の工程に特化したツールも増えてきています。
ツールや機能の習得難易度も高まっています。
ツールに出来ることが限界を決めるのではなく、
ツールの理解度が出来る事の限界を決めてしまう 状況です。
逆に多くのツール、エンジンには似たような思想が多く見られます。
より重要なのは思想や仕組みの理解とも言えます。
どんなツールを使えるかだけでなく理解度を測る事が重要です。

目に見えない技術を評価する必要がある
人材の要件を定義する際は、
プロジェクトの新規性についても検討が必要です。
未知の領域が多いということは、
新しいことに多くチャレンジする必要があります。
問題に切り込んでいく行動力が不可欠です。
● 自立的に仮説を立てて行動できる人材
● 周囲を巻き込み問題を解決できる人材
● 自分の意見を伝えて提案ができる人材
こういった技術は分かりやすい形で評価し辛いです。
しかしながら行動力がある人材が少ないとプロジェクトは動きません。
人材要件をまとめても必要十分な人材が揃うことは滅多にありません。
常に人手不足です。プロジェクトの成功率を上げるため、
人材の成長と確保を継続して編成を見直す必要があります。

AMの仕事
4 / 5
アーティストの作業環境管理
ゲーム開発に必要な作業環境というのは定番化して
きています。
● PC（CPU, GPU, メモリ, 記憶領域）
● モニター（インチ、カラマネ、台数）
● アプリケーション（エンジン、ツール）
● クラウドサービス（チャット、Wiki）
● 開発機（コンソール、スマホ）
● 備品（コントローラ、タブレット）
これら必要機材が十分に行き渡っているか？必要なラ
イセンスはあるか？アカウントはあるか？といった部
分の管理も必要です。

管理ツールは設計・運用保守が必要
開発で使用するツールは何らかのカスタマイズが必要です。
特に情報を管理するツールは導入してお終いとはなりません。
例えば下記のようなものは AMの時間を多く使います。
● タスク管理システム（ JIRAなど）
● ナレッジ管理システム（ Confluenceなど）
● アセット管理システム（ SHOTGUNなど）
● バージョン管理システム（ Perforceなど）
こういったサーバーやデータベースが絡むシステムも、
アーティストにとって馴染み深いものではあります。
ただし、それらを設計（カスタム）するとなれば別です。
AMが中心となってプログラマーやシステム管理者と設計を進めます。
運用保守を怠ると使われなくなったり、大事故に繋がります。

AMの仕事
5 / 5
アートが関わる情報の交通整理
開発中には様々な情報が飛び交います。アーティスト
の扱い辛い情報も多くあります。AMは情報の交通整
理として下記を行います。
● ノウハウや情報をドキュメントにする
● 技術的な話題をアーティストに説明する
● 宙に浮いている話題を着地させる
アーティストは絵作りに専念する人が多く、ゲーム仕様
や技術的な話題から少し離れがちです。複数セクショ
ンに話がまたがる場合、分業の影響もあって進め方に
困るケースがあります。
AMは情報のパイプ役となります。

たぶん、きっとの蔓延で開発はカオス化する
人間は分からないことを都合よく扱いがちです。
分からないところはたぶん別の人が対処してるだろう。
こういう憶測で仕事が進むと事故がおきます。
ただし常にAMが割って入る状態が続くと問題が起きます。
プロジェクトが進んだ時に流れる情報は急激に増加します。
AMでは捌ききれずAMがボトルネックになります。
そうならないように日頃から積極的に交通整理を行い、
代わりのパイプ役（窓口）を作り AMは手を離していきます。
あくまで直接ゲームを作るのはスタッフになります。
スタッフが自立して行動できるよう環境を作っていきます。

アートマネージャーの連携術

AMの連携術
管理の分担
AMは多くの時間を計画と問題解決に使います。
そうすると絵作りに対して距離ができてしまいますが、
管理をする上でAMにはクオリティラインや工数に関す
る情報は必須です。
絵作りに関してはアートディレクター（AD）やリードアー
ティスト（LA）と密に連携して管理を行います。
下記はADとLAに任せます。
● クオリティラインの決定
● 工数試算
● タスクアサイン

AMの連携術
一歩引いた視点で貢献する
AMはワークフローを理解し、ワークフローに改善点が
無いかを気にしておきます。現場が求めるなら新しい
ツールも積極的に導入を進めます。
ゲームデザイナーやプログラマーに対しても関心を持
ちます。相手のワークフローや不満を理解することで、
全体最適となる提案を積極的に行っていきます。
現場は目の前の作業に意識が行きがちです。一歩引
いた視点でグラフィックスを評価し、プレイヤーにとって
価値のある絵作りかどうかをフィードバックします。

アートマネージャーに求められる能力

AMの能力
必要な技術と理解領域
AMに一番求められる技術は下記のとおりです。
✕ 絵を良くする具体的なセンスや技術
◯ 要求をメンバーの仕事に落とし込む技術
そのためには下記に関する理解が必要です。
● ゲームへの理解（プロモーション）
● 開発プロセスへの理解（ワークフロー）
● 開発技術への理解（生産性）

AMの能力
期待値コントロール
AMはアーティスト以外との会話も多いため総合的な
知識が必要です。
ディレクターのやりたい事を具体的な形に落とし込む
ため、アーティストがうまく機能するよう立ち回ります。
更に要件定義を含めてプロジェクトのチャレンジ、つま
りどれくらいリスクを取るかの判断を行います。
これらの判断を通じてアーティストがやりがいを感じ
る、プロジェクトに参加することが成長につながるよう
にします。（プロジェクトは自分たちで面白く意義あるも
のにできる）

最後に

AMのやりがい
クリエイティブな仕事をする
管理と聞くと進捗管理のイメージがあるかもしれませ
ん。もしくは雑用やメンバーの面倒を見るような仕事が
多く、作品作りから離れてしまうようなイメージがある
かもしれません。
しかしながら根幹部分で何を作るかを決めているの
は、そういった管理責任を負う人達にこそ与えられた
裁量でもあります。
クリエイティブとは知識や経験を繋ぐことと考えます。
つまり知識や経験値を常にアップデートして蓄積する
必要があります。明確な制約のもと、完成イメージやプ
ロセスが明確な仕事。こういった仕事以上のクリエイ
ティブがマネジメントには必要です。

おわり
閲覧ありがとうございました
このスライドは筆者のAM経験に基づいて記載したも
のです。量産人員を除いて10人〜100人程度のアー
ティスト組織を想定しています。
またプロジェクトによってはAMをリードアーティストと
呼称します。その場合はセクションリーダーとの区別
が付きづらいためアートマネージャーと明記していま
す。
この資料がゲーム開発におけるマネジメント職への理
解、関心につながる1つになれば幸いです。
以上