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

『MONSTER HUNTER: WORLD』における、 製品クオリティを最大化するテクニカルディレクションと、 エンジニアの能力を引き出すマネージメント 株式会社カプコン 大井 勇樹 一般公開版 © CAPCOM CO., LTD. ALL RIGHTS RESERVED.

略称について 「MONSTER HUNTER: WORLD」 = 「MH: World」 「テクニカルディレクター」 = 「TD」 と略すことがあります © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 2

「MONSTER HUNTER: WORLD」とは ・「ハンティングアクション」というジャンルの草分けとなった カプコンを代表するメインタイトルの最新作 ・PS4/Xbox One世代をメインプラットフォームとする 初の「MONSTER HUNTER」 ・2018年初頭発売予定！鋭意製作中！ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 3

自己紹介 ・大井 勇樹 (おおい ゆうき) ・2003年入社 (芸歴14年) ・アプリケーションプログラマ出身 - DEMENTO、戦国BASARAシリーズ、バイオハザード5、LOST PLANET 2などなど ・エンジンプログラマに転向(2010年頃) - ツール、リソース管理、メモリ管理、開発環境改善などなど ・テクニカルディレクターへ転向(2012年頃) - エンジン案件管理、各タイトルへの技術サポートやディレクション - (職業的な) コーディングを卒業 ・「MONSTER HUNTER: WORLD」のテクニカルディレクター就任 - システムの要件定義からシステムプログラマのマネージメントまで © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 4

おしながき ①「MONSTER HUNTER: WORLD」プロジェクトの概要 ② グラフィックスシステムに関する意思決定フローの紹介 ③ 重要な製品仕様の決定に対する テクニカルディレクションの関わり方 ④ エンジニアをマネージメントする際に 考えておくべきこと © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 5

①「MONSTER HUNTER: WORLD」 プロジェクトの概要 © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 6

「MONSTER HUNTER: WORLD」プロジェクト ・大規模 - 具体的なことは言えませんが、カプコン社内でもかなりの大規模プロジェクト - スタッフロールでぜひご確認ください ・高い期待 - ファンからはもちろんのこと、社内各部署やパートナー企業様からも - リクエストが多種多様 ・長い歴史を持つシリーズタイトル - 新しく入った人もいれば、携帯機時代から継続している人もいる - 世代、技術、文化など様々 © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 7

「MONSTER HUNTER: WORLD」のミッション ・全世界で勝負、全世界向け開発 - 様々な地域のゲーマーカルチャーやトレンドを考慮 ・現世代機のスペックをフル活用し技術的にもリード - 現世代機は「2周目」時代に突入 ・新しいプラットフォームでの新しいゲームプレイ - これまでの「おやくそく」を見直す © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 8

「MONSTER HUNTER: WORLD」のミッション(システム編) ・世界最高レベルのグラフィックスクオリティ - 世界に名だたる名作達と並んで追い越すことが目標 ・世界にオンリーワンの映像体験 - 単に「美しい」「写実的」なだけでなく、個性的で独創的な体験 ・最新技術のキャッチアップ - 他社にできていることは我々もやる © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 9

テクニカルディレクターとしてのミッション ・チームからの要求を実現できるプログラマを正しく選出する - チーム全体、組織全体、会社全体、業界全体に対する広い見識が求められる ・チームからの要求をプログラマに正しく理解させる - 要求の本質を引き出し、理解し、伝えることで、プログラマに進むべき道を 導かせる ・数ある選択肢の中から、タイトル、プロジェクトに最も適した選択を 正しく提案する - 何もかもすべてを実現できる最良の選択肢は存在しない、「最適な」選択肢を 模索する © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 10

②グラフィックスシステムに関する 意思決定フローの紹介 © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 11

グラフィックスにまつわる人達 プロデューサー アートディレクター (What) アートリーダー (How) セクションリーダー (How) セクションリーダー (How) セクションリーダー (How) テクニカル ディレクター レンダリングプログラマ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 12

アートディレクター ・チーム全体のアートに対して【What】の判断基準を司る - 何がよい、何がよくない - これが見せたい、これは見せなくていい - 何が必要、何が不要 ・プログラマからのアプローチはあまりない ・アートリーダーや各セクションリーダーが直接やり取り © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 13

アートリーダー ・チーム全体のアートに対して【How】の判断基準を司る - どうすればアートディレクターの要求が実現できるのか - どうすれば各セクション間で整合性のある絵が作れるのか - どういう方法でやれば、安く、早く、高品質な絵が出せるのか ・セクションを横断したワークフローやツールの考案、要件出し ・各セクションに対して、それらの説明をおこない浸透させる ・レンダリングプログラマ、TDと最もつながりが強い ・「MH: World」ではライトセクションのリーダーが兼任 - ライトはあらゆる画作りに対して影響が大きい © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 14

セクションリーダー ・アートリーダーが敷いたテクニカル上の制約やビジュアルの方針に基 づき、各分野でのクオリティ、効率最大化を司る ・セクションに特化したワークフローやツールの検討をおこなう ・システムプログラマと直接的なやり取りが多い ・クオリティチェックはアートディレクターへ ・ワークフローや技術の相談はアートリーダーへ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 15

そしてレンダリングプログラマ ・アートリーダー、各セクションリーダーからの要求の実現を司る - ビジュアルクオリティ - 無駄の少ないワークフロー - クオリティの幅を広げ、効率を高めるツール ・限りある資源(ハードウェア、時間、人数)を考慮した 最適解の提示と実装 ・そしてOptimize! さらにOptimize! おまけにOptimize! © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 16

意思決定フロー アートディレクター ①要望 アートディレクターから アートリーダーまたは 各セクションリーダーへ 要望が出される アート アートリーダー セクションリーダー セクションリーダー テクニカル ディレクター プログラム レンダリング プログラマ アプリケーション プログラマ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 17

意思決定フロー アートディレクター ①要望 アートリーダーおよび 各セクションリーダー(+TD)で 要望実現のために必要な機能 (要件)をまとめ、合意を得る ② 要件検討 合意 アート アートリーダー セクションリーダー セクションリーダー テクニカル ディレクター プログラム レンダリング プログラマ アプリケーション プログラマ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 18

意思決定フロー アートディレクター ①要望 アーティスト間での合意を元に、 プログラマに対して実装要望を出す ② 要件検討 合意 アート アートリーダー セクションリーダー セクションリーダー ③要望 テクニカル ディレクター プログラム レンダリング プログラマ アプリケーション プログラマ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 19

意思決定フロー アートディレクター ①要望 プログラマが技術面の都合なども 考慮し最終的な仕様に落とし込み アーティストに提案する ② 要件検討 合意 アート アートリーダー セクションリーダー セクションリーダー 要望 ④提案 テクニカル ディレクター プログラム レンダリング プログラマ アプリケーション プログラマ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 20

アートディレクター VS アートリーダー/セクションリーダー ・テクニカルな知見からはノータッチ - 「目的」を決める場であり、「手段」を決める場ではない - 「技術」を理由に、最初から「表現」の可能性の芽を潰さない © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 21

アートリーダー/セクションリーダー VS セクションリーダー ・第三者的視点のテクニカルからも議論に参加する - 各セクション視点からの主張も入るので、公平性や妥当性を見極める - 技術的なハードルを加味してもらい、妥当な結論を導く - プログラマとの間の「クッション」の役割を果たす意味合いが強い © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 22

アーティスト合意形成ミーティング ・参加者 - アートリーダー(兼ライトセクションリーダー) - 各セクションリーダー(モデル、背景、エフェクト) - テクニカルディレクター ・プログラマは参加させない - アートの中で合意されていないことを聞かせてもあまり意味がない ・ファシリテーターとしてのテクニカルディレクター - 合意形成を目的とした議論にはファシリテーターが必須 © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 23

アート内合意形成 ・セクション単位で完結できるものと、アート全体に関わるものとを区 別する - とあるセクションの要望が、他セクションの要望に反することもあり、 安易に対応するとアートの調和が乱れる ・リーダーから出た要望は作業担当者に、作業担当者から出た要望は リーダーに、合意を確認する - クオリティを優先して、作業担当者に無理な作業を強いていないか - 作業効率を優先して、全体的な整合性を無視していないか ・「何が実現できればいいのか」について合意し、 使用するアルゴリズムや技術選定はゆるくおこなう - 餅は餅屋 - プログラマとの会話をスムーズに進めるために、想定はしておく © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 24

テクニカルアーティスト(TD)のスキル 技術 【リサーチャー】 ・自ら最新技術を追い求める ・複雑な理論でも勉強、試行錯誤を重ね 理解する © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 25

テクニカルアーティスト(TD)のスキル 技術 【インフルエンサー】 ・新しい技術やよりよいワークフローを チームに浸透させる ・チーム文化に合わせた導入方法を 提案する © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 26

テクニカルアーティスト(TD)のスキル 【リサーチャー】 ・自ら最新技術を追い求める ・複雑な理論でも勉強、試行錯誤を重ね 理解する スキルを正しく見極め、 お互いを補う役割分担をおこなう 【インフルエンサー】 ・新しい技術やよりよいワークフローを チームに浸透させる ・チーム文化に合わせた導入方法を 提案する © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 27

アートリーダー VS レンダリングプログラマ ・テクニカルディレクターによる調停が非常に重要 - 考え方も価値観も対立している者同士 - でありながら、この協力関係が製品クオリティを最も左右する ・アートの「目的」は尊重する - プログラマはアートのクオリティに対して責任を持つ立場ではない - もちろん、「言われたとおりやる」という意味でもない ・アートの「手段」には介入する - 目的を実現するためのあらゆる手段に対して検討をおこなう - 持ちうる情報をすべて提供して判断を仰ぐ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 28

プログラマによる仕様検討 ・知見は基本的にすべて信じる - 彼ら彼女らはグラフィックスのスペシャリスト - 知見に対しては決して否定しない ・「ミスがないか」を疑う - プログラマである以前に人間なので間違いはある - いろいろな状況を想定できているか - 現実的な期間、労力で実現できるか - ここは知見よりも「実績」や「勘所」の世界 © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 29

意思決定フローへのテクニカルディレクターの関わり テクニカルディレクターが要望から仕様まで 関わることで、製品クオリティを最大化する © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 30

使用ツール ・選択肢はいろいろ - Redmine - Hansoft - Excel - etc... ・先述のフローの中では社内製ツール(ほぼRedmine)を使用 - チケット管理システム部分はほぼRedmineを踏襲 - ツールの概要はCEDEC 2015「カプコンにおけるゲームプログラマのキャリアパス」を参照 © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 31

なぜRedmine? ・要件ベース > スケジュールベース - ガントチャート不使用 - 既存手段の検証や、仕様の考案からおこなうことが多い - 期日の設定はおこなうが厳密にはしない ・必要なのは「リマインダ」 - あくまでも会話の補助にすることがツールの目的 - 当事者の「記憶の補助」として使う - プログラマ、アーティスト双方の認識合わせが、 ミーティングでの最もかつ唯一の重要事項 - 「なぜそれが必要か」「どのようにその結論に至ったか」という 「思考の流れ」がシンプルに見やすいツールが望ましい © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 32

Hansoftは? ・Hansoftも使っています - セクション単位のマイルストーン設定に使用 - QAに使用 ・下記を重視するならHansoftは有用 - チーム全体のスケジュールを俯瞰で把握したい - 開発速度など、プロジェクトの健康状態を知りたい - 案件数が多く、膨大なタスクを管理したい © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 33

ツールとの付き合い方 ・会話をより効率的に、建設的にするためにツールは存在する ・ツールのために会話時間が削がれるのは本末転倒 ・延々とツールと格闘するのは時間の無駄 ・ツールへの入力や、案件の管理、リマインドはアシスタントに 任せて、TDは当事者との会話に時間を割く © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 34

③重要な製品仕様の決定に対する テクニカルディレクションの関わり方 © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 35

対プロデューサー(プロジェクトオーナー) ・プロモーション、懐事情、パートナー企業との折衝、 経営サイドからの要望など、開発外の要因によって 様々な無理難題要望を依頼してくる - 対応プラットフォームは? - 対応地域は? - DLCは? - コラボは? ・技術的な制約によって、実現可否が決まることもあるため、 技術的知見を持った立場からもコントロールしないと プログラマが泣く羽目になる可能性も… © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 36

製品仕様検討ミーティング ・オーナーからの要望に対し、製品に落とし込むための 仕様を検討するために週次でミーティングを開催している ・参加者 - プロデューサー(オーナー) - 企画リーダー - プログラムリーダー - プロジェクトマネージャー - リリースマネージャー - (CEDEC 2015「カプコンにおけるゲームプログラマのキャリアパス」を参照) - テクニカルディレクター(技術リーダー) © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 37

製品仕様検討ミーティング ・技術的な観点から以下の内容を確認 - メモリは足りるのか? - ディスク容量は足りるのか? - 処理、描画負荷は現実的か? - 作業追加の対応人員およびスケジュールの確保は可能か? - ユーザー視点から見て「ウリ(購買意欲のプラス)」になるか? © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 38

「MONSTER HUNTER: WORLD」での仕様検討例 ・HDR ・画面解像度 ・対応言語 ・通信帯域 ・マルチプラットフォーム対応 ・ミドルウェアの導入 ・ショー用ROMの公開範囲 ・マスタースケジュール ・などなど、まだ言えない話も… © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 39

オーナーに対する誤解 ・「オーナーは無茶ばかり言う」 - 技術的な事情が分からないために、結果として、開発から見れば 無茶に見える要求をしているだけ - (説明が大変なので)現場が説明責任を果たしていないケースの方が多い ・「オーナーの意向は絶対覆らない」 - 目的は「QCD(質、コスト、期間)を最適化し売上につなげる」だけ - よりよい選択を提案できるのであれば合意形成は難しくない (損得勘定のプロなので、むしろプログラマよりも話は早い) © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 40

テクニカルディレクターによるオーナー攻略 ・「取引」を勧める - 製品にとって「絶対必須」は存在するが、そうじゃないものも存在する - 本当に大事なことを実現するためには何を犠牲にできるのか相談する ・技術説明のための時間を割く - プロデューサーは戦略の玄人ではあるが戦術は素人 - 価値が分からない人が相手では取引が成立しないので、 判断材料を十分に揃えて提供する - オーナーは特に忙しいので、資料は少なめ(不要ではない)、対話を中心に プログラマがコーディング片手にやるには難易度が高すぎる →テクニカルディレクター(に準ずる)の役割が必要 © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 41

④エンジニアをマネージメントする際に 考えておくべきこと © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 42

エンジニアってどんな人? ・プライドが高い ・頭がいい ・要領がいい © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 43

エンジニアと向き合う際の原則 ・プライドが高い - 否定しない、見下さない ・頭がいい - ごまかそうとしない ・要領がいい - 無駄なことはさせない © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 44

常に念頭に置いておくべきこと エンジニアを「管理」しようと考えない © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 45

「エンジニアを『管理』する」とは マネージャーの「管理下」に置くこと II マネージャーが扱いやすいように 「縛る」こと © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 46

「エンジニアを『管理』する」とは ・ルールで縛る - 作業は必ず事前に報告し、このツールでこのフォーマットで記録して… ・スケジュールで縛る - この作業はこの日まで、次の作業はこの日まで… ・仕様で縛る - この要件を実現するためにはこの機能とこの機能が必要で… ・ミーティングで縛る - 進捗報告、情報共有、業務連絡… 見下し、ごまかし、無駄がある © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 47

エンジニアを『管理』しない考え方 とは言え、チーム運営上、 エンジニアにもある程度の統制は必要 ↓ エンジニアの意見に基づいた合意を得る © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 48

エンジニアを『管理』しない考え方 ・エンジニアでもマネージメントくらい知ってる - 「理解」までなら大体のエンジニアは出来ている - 「実践」するのが本職のマネージャーの仕事 ・マネージャーに意見してくれるエンジニアは多くはない - だからこそエンジニアが「管理」されることにつながる - エンジニアの意見を汲み取るのもマネージャーの仕事 エンジニアのマネージメントは エンジニアに聞け！ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 49

「管理」じゃなければ何をする? エンジニアを「Leverage」する ※【Leverage】 てこの力、てこ装置 影響力を行使する © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 50

エンジニアをLeverageする ・目的(ゴール)を明確にする ・障害を取り除く ・モチベーションを高め、維持する © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 51

目的(ゴール)を明確にする ・「何をするのか」よりも「なぜするのか」をきちんと伝える - 意図を伝えることで、よりよい提案や、期待の100%以上の結果を出すことも できる - 理由を与えることで納得度を高め、達成意識を強める - ただ「やれ」と言うだけではモチベーションを著しく失わせる © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 52

障害を取り除く ・誰に何をしてほしいのか、何を必要としているのかを聞き出す - エンジニアがうまく能力を発揮できない原因の大半は外部要因 - エンジニアが不満を持っているなら必ず耳を傾ける ・期間が足りない ・人員が足りない ・ツールが足りない ・仕様が不足している ・誰かに判断を仰ぎたい ・制約に合意してほしい ・アーティストが言うことを聞かない ・誰がボールを持っているのかを常に明確にする - 自分がボールを持っていることに気づかないエンジニアは多い - 気づきさえあれば後は自然と円滑に流れる © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 53

モチベーションを高め、維持する ・「望めば叶う」「正しいことは報われる」という実績を積む - 「いち作業員」ではなく「大事なコアメンバー」である意識を持たせる - 不満が解消されれば、また相談しやすくなる良い循環を生む ・不義理をはたらかない - 実現が難しい要望は、曖昧にせずはっきりと伝え、理由を説明する - 「要望は伝えたのでいつか叶う」と期待を持たせることはかえって失望につながる - チームの重要決定事項は、直接業務に無関係なことでも伝える © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 54

エンジニアがマネージャーに期待すること ・判断 - チーム全体を見渡す広い視点を持って、エンジニアが提案する選択肢の中から 最適なものを選ぶ ・検討 - 第三者的な観点から、エンジニアに対してよりよい手段を考える手助けをする ・実践 - エンジニアからの提案をチームの施策として形にする © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 55

よいマネージャーに求められるもの 信頼 establish the trust. © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 56

信頼を得るためにマネージャーがするべきこと 会話 have a conversation. © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 57

信頼を得るためにマネージャーがするべきこと ・信頼とは会話によって生まれるもの - 話したこともない人を信頼しろと言われても… - 「人となり」が分かったところから信頼が生まれる © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 58

会話がいかに大事か ・会話を用いるマネージャーの業務は非常に多い - 要件定義・スコープ定義 - 仕様検討 - スケジュール見積もり - タスク洗い出し - 案件の進捗管理 - 人員アサイン - ミーティングの議事進行 - などなど © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 59

会話がないとき アーティスト プロデューサー ダークゾーン エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 60

会話がないとき アーティスト プロデューサー ダークゾーン これお願い！ エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 61

会話がないとき アーティスト プロデューサー ダークゾーン これお願い！ エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 62

会話がないとき アーティスト プロデューサー 無理！ ダークゾーン これお願い！ エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 63

会話がないとき アーティスト プロデューサー 無理！ ダークゾーン これお願い！ ふざけんな！ エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 64

会話があるとき アーティスト プロデューサー ダークゾーン エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 65

会話があるとき アーティスト プロデューサー ダークゾーン これお願い！ エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 66

会話があるとき アーティスト プロデューサー ダークゾーン これお願い！ エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 67

会話があるとき アーティスト プロデューサー 無理！ ダークゾーン これお願い！ エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 68

会話があるとき アーティスト プロデューサー 無理！ この作業 無駄に時間かかるから とても 間に合いそうにない… マネージャー 何がいいのか よく分からんけど コストかかりそうやし やめとこ… ダークゾーン これお願い！ エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 69

会話があるとき アーティスト プロデューサー 無理！ この作業 無駄に時間かかるから とても 間に合いそうにない… マネージャー 何がいいのか よく分からんけど コストかかりそうやし やめとこ… ダークゾーン これお願い！ こういう方法がある！ こういうメリットがある！ エンジニア © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 70

会話が信頼を生み、信頼が会話を生む ・提案を出してくれる - こっちの方が面白いと思います - こんな手法を使ってみてはどうでしょう ・アラートを出してくれる - このままだと進捗やばそうです - この仕様だとこういう場合にまずいです ・それらを解決することでまた双方の信頼が生まれる 会話 信頼 © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 71

エンジニアとマネージャーの相互作用 ・エンジニアからの情報によってマネージャーは適切な方針が出せる ・マネージャーの施策によってエンジニアは自身の制作業務に 注力できる 主従関係ではない よい共生関係を構築する エンジニア マネージャー © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 72

その他にも… ・アーティストへの尊敬を忘れない・エンジニア個々の個性を殺して平 ・エンジニアからの炎上アラートを均化するような管理をおこなわ 無視しない い ・エンジニアにプロデューサーの知 見を求めず、プロデューサーにエ ンジアの知見を求めさせない ・「プログラマ対応」といった曖昧 な単語は使用しない ・ミーティングには必ず結果として コーディング効率向上が得られる 目的を持たせる 割愛！ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 73

まとめ ・テクニカルディレクターはアーティスト間の合意形成から参加する ・アーティストやプロデューサーなど、他セクションのゴールは尊重し、 そのためのプロセスを担う ・製品の大きな仕様判断の場には技術的知見を持った人も立ち会う ・エンジニアは「管理」せず「Leverage」する ・エンジニアとの会話を最も重要視する ・会話と信頼のサイクルを作り、エンジニアとの相互関係を構築する よきマネージメントライフを！ © CAPCOM CO., LTD. ALL RIGHTS RESERVED. 74