MONSTER HUNTER: WORLD』における、製品クオリティを最大化するテクニカルディレクションと、エンジニアの能力を引き出すマネージメント

講演者

大井 勇樹　さん（株式会社カプコン）

講演内容

プロジェクトの概要

• 大規模
• 高い期待
• 長い歴史を持つシリーズ

プロジェクトのミッション

日本だけではなく、全世界で勝負できるものを作る

現世代機のスペックをフル活用し技術的にもリードできるようにする
新しいプラットフィームでの新しいゲームプレイを作るために、
今までのお約束を見直す。

世界最高レベルのグラフィックス

世界にオンリーワンの映像体験を提供する
→単に美しい写実的なだけではなく独創的な体験を提供する

最新技術のキャッチアップ

他社でできる事は自社でもやる

テクニカルディレクターのミッション

• チームからの要求を実現できるプログラマを選出する
  • チーム全体、組織全体、会社全体、業界全体の広い見識が求めらる。
• チームからの要求を正しくプログラマに理解させる必要がある。
  • 要求の本質を引き出し、理解し伝えることが必要

アートディレクターの役割

チーム全体のアートに対してのWhatの判断基準を司る。
→何が良いのか、見せたいもの、見せたくないものの判断を行う

※プログラマから直接アプローチはあまりなく、ディレクターの下の各セクションのリーダーを通して行う。

アートリーダーの役割

チーム全体のアートに対してのHowの判断を司る
→セクションを横断したワークフローやツールを考案し、要件だしを行う。
各セクションに対して説明や浸透も行うため、レンダリングプログラマやテクニカルディレクターとの繋がりが強い

セクションリーダー

アートリーダーが敷いたテクニカル上の制約やビジュアルの方針に基づき、各分野でのクォリティや効率の最大化を司る

レンダリングプログラマ

各セクションからの要求の実現を司る
限りある資源を考慮し最適解の提示と実装を行う。
あとはひたすら最適化を行う。

アートディレクターVSアートリーダー・セクションリーダー

テクニカル的な知見はノータッチで行い、
目的を決める場として使用する。
この段階で「出来ない」を理由に表現の幅を狭めない。

アートリーダー/セクションリーダーVSセクションリーダー

各セクションの主張や意見が入り乱れるので公平性を見極める必要がある。
公平性や妥当性を決めるために技術的なハードルも加味する。
プログラマとの間に入ってクッション的な役割を果たすため、
非現実的な要求が来ないようにする必要もある。

アート内での合意形成

セクション単位で完結ものかなどを区別しておく。
リーダーからの要望か作業者からの要望かを確認し、
何が実現出切ればOKなのかも合意しておく。
この際のアルゴリズムの選定や技術選定はゆるく行っておく。

アートリーダーVSレンダリングプログラマ

考え方も価値観も対立している。
アートの目的は尊重するが、アートの手段には介入する。

テクニカルディレクターのスキル

• リサーチャー
  • 自ら最新技術を求め、試行錯誤しながら勉強・理解を深める
• インフルエンサー
  • 新しい技術やワークフローをチームに浸透させていく
  • チーム文化に合わせた浸透方法を提案する

意思決定フローへの関わり

要望から仕様まで関わる事で、最大限のクォリティを提供できるようになる。

対プロデューサーやオーナー

プロモーションや経営陣からの要望が来ることがある。
技術的な知見を持った状態でコントロールしないと
プログラマが泣く羽目になるので注意が必要。

そのため、週次で仕様検討のミーティングを行っている。
その場で要望をどうやって製品に落とし込むかを決定している。

オーナーは無茶ばかり・・・

これは誤解である。
そもそも技術的な事情が分からないため無茶な要求をしているように見える。
→きちんと説明することが大切

オーナーの意見は覆らない

質・コスト・期間を加味して売り上げの最適化を求めていくことが目的なので、
よりよい選択を提案することで合意形成も簡単に出来る。

攻略法

オーナーとは「取引」を行う。
必須条件は存在するがそうでない部分に関しての譲歩案などを提案して取引を行う。

プロデューサーは戦略は得意だが、戦術は素人なので説明するときは
しっかりと資料を用意して説明を行う。
これはプログラマが片手間で行うと時間が足りないため、
テクニカルディレクターが行うようにする。

エンジニアのマネージメント法

エンジニアはプライドが高く、頭がいい、論理思考のため要領もいい。
そのため、否定しない、ごまかさない、無駄なことをさせないことが大切である。

エンジニアを管理しようとしない。

管理とは・・・マネージャーが扱いやすいように【縛る】ことである。

• ルールで縛る
  • 作業を行う前に事前報告を行うなどのルール決めを必須とすること
• 期日で縛る
  • いついつまでに期日を決めて作業を行わせること
• 仕様で縛る
  • 要件を満たすために、この機能がいるを予め押し付ける。
• ミーティングで縛る
  • 進捗報告などのミーティング

などのことを指す。

だが、これらを全部やらないということはチーム製作上無理な話なので、
エンジニアから合意を得られたことで実践していくことが大切である。

エンジニアのマネージメントの方法はエンジニアに聞く

マネージャーがすべてを決めるのではなく、エンジニアと会話や意見を出し合い
どうして行った方がいいかを決める。
ただ、マネージャーに対して意見を言ってくれるエンジニアは少ないため
【管理】する方法に行き着いてしまう。
エンジニアから意見を汲み取ることもマネージャーの大事な仕事である。

エンジニアをLeverageする

• 目的を明確に
  • 何をするのかではなく、なぜするのかの目的を正しく伝える
  • 意図をしっかりと伝えることで期待以上のものが出来たりする。
  • ただ「やれ」だけだとモチベーションダウンに繋がる。
• 障害を取り除く
  • 不満に思っていることには耳を傾ける
  • 大半が外的要因による不満（時間がない・人員がないなど）
• モチベーションを高め、維持する
  • 望めば適う。正しいことは報われるという実績を積むことが大切
  • 一作業員ではなく、コアメンバーだとして扱う
  • 不義理を働かない
    • 実現が難しい要望に関してしっかりと説明を行い、理解してもらう。
    • チームの重要事項は業務に関係なくても伝える。

エンジニアがマネージャーに期待すること

• 判断
  • チーム全体を見渡す広い視点を持つ
• 検討
  • 第三者的な観点からエンジニアに対して、より良い手段を提案する
• 実践
  • エンジニアからの提案をチームの施策として形にする

よいマネージャーとは？

信頼があること。
信頼を得るためには会話をすることが大切。

会話をしたこともない人を「信頼」するのは無理な話である。
会話をすることで徐々に信頼できるようになり、
信頼されることでより良い提案をしてくれたりする。

即ち

エンジニアとマネージャーの関係は主従関係ではなく、共生関係であるべき

感想

マネジメントする際の注意点などを聴くことが出来てとても良かったです。
所々思い当たる節があったりしますがこれを実践していくことでいい環境が出来ていければと思います。