大統領、王、リーダーの役割

Sam Stoddard / Tr. Takuya Masuyama / TSV YONEMURA "Pao" Kaoru

2015年2月20日

　今週の記事では、私たちが多く話しているもの、しかし必ずしも本当に説明できていないもの――リード・デベロッパーの役割についてお話ししたいと思います。時間と責任の両方の意味で、セットのチームに属することと、セットのチームをリードすることの間には、大きな隔たりが存在します。マジックのセットのデベロップは民主主義ではありません――そのセットのリードが最終決定を行います。それが他のセットと異なる雰囲気を持つことにとって重要だと私は考えます。マーク・ローズウォーター/Mark Rosewaterとケン・ネーグル/Ken Nagleがリード・デザイナーを務めたセットの間に違いがあるように、それぞれのリード・デベロッパーの特徴を、彼らが手がけたセットの中に見出すことができるのです。

　端から見ると、デベロップ・チームの仕事のほとんどはカードの数字をいじくることのように見えるかもしれませんが、実際にはそれ以上のことを行っています。例えるならば「デザインが小説を書き、デベロップがそれを映画化する」といったところです。そのセットの本質はデザインからそのままで、多くの重要なカード個別のデザインもそのままですが、そのセットがリミテッドとスタンダードの両方で機能するために多くの変更が必要です。リードの重要な特性の一部に対するいくつかの見方を皆さんに提供するために、セットのデベロップが行われるときにそのリード・デベロッパーが担当する多くの役割のうち、いくつかについてお話ししようと思います。

ビジョンの保持者であれ

　私はこれがセットのリード・デベロッパーとして最も重要な部分であると信じています――セットについて深く考え、印刷されたカードに書いてあることのほとんどに対して責任を負うことです。デザインからデベロップへセットが引き継がれたとき、そのセットのリード・デザイナーは既に多くの時間をそのセットに費やしており、そしてその人はリード・デベロッパーが払うであろうものと同じだけの判断をしてきているはずです。一般的にリード・デザイナーはそれぞれ、満足する部分を様々な度合いでを持っています――例えばメカニズムであるとか、リミテッドのアーキタイプ、個別のカード・デザインなどです。リード・デザイナーの作業時間には限りがあるので、リード・デザイナーはその最も重要だと思うものと、その最も得意とするものを見つける仕事に取り組みます――主にそのセットのお膳立てをして全体の正しい感覚を得ることです。

　リード・デベロッパーの目標は、その仕事の後でリード・デザイナーと協力してその人のセットのビジョンを系統立てることであり、そのデザイン・チームが見つけた重要な事柄を全て考慮し、それを最終的な商品に変える方法を考え出すことです。『タルキール覇王譚』では、リードは伝説のクリーチャーを正しくすることの重要性、各氏族がうまくプレイされることと異なった雰囲気にすることの両立の重要性、カードにもっとスタンダードでエキサイティングにするのに必要な作業量、そしてリミテッドのバランスを取るために必要な時間を把握する必要がありました。全ての作業を終わらせるための時間は限られており、最終的には多くの目標は矛盾することになります。

　さらには、『運命再編』の《命運の核心》や「包囲」サイクルの５枚に透かしを入れたりするような、セットをよりクールにする細かいことがたくさんあります。それがまさしくそのセットのリード・デベロッパーが思いつくか、もしくは誰かが提案するかもしれないようなことであり、そしてリード・デベロッパーはその過程全体の面倒を見て、皆にそれがやる価値のあることだと納得させる必要があります。

　さて、これはリード・デベロッパーがやりたいことを何でもできるということではありません。私がどれだけ自分のセットに《頭蓋骨絞め》を入れたかったとしても、FFLの代表であるエリック・ラウアー/Erik Lauerやマジック開発部のディレクターであるアーロン・フォーサイス/Aaron Forsytheに却下されてしまうでしょう。リード・デベロッパーは自分が好きだからとモダンやスタンダードに悪影響を及ぼすカードを再録することや、問題のあるカードを作り出すことはできませんが、確かに過程を通していくつかお気に入りのカードを導く能力を持ちます。

リーダーであれ

　デベロップ・チームは５人で構成される傾向にありますが、ウィザーズ・オブ・ザ・コーストはそれをはるかに越える人数の情熱的な人々で満たされており、その誰もがこのゲームにとっての最良のものを探しています。もちろん、この「ゲーム」が意味するものは人によってそれぞれ異なり、重要なのはそのセットのリード・デベロッパーが周囲の人々の意見を聞き、どれを採用してどれを無視するかを決断することです。リーダーであることの中には、人々の意見によって考えを変えることも含まれますが、重要だと思ったことを押し通すこともまた含まれます。

　例として『イニストラード』を振り返ってみると、両面カードについて内部で多くの議論が行われました。エリック・ラウアーはマーク・ローズウォーター以下数名のこのメカニズムは素晴らしいと言う熱烈な人々と、同じぐらいのこれはやり過ぎだ、もしくは複雑さやトーナメント上の問題を押しのけてまで採用する価値がないと言う別の熱烈な人々を抱えていました。リード・デベロッパーはこのメカニズムを没にすることもできました――簡単なことではありませんが、できなくはないことです――しかし、最終的な決断はこれを維持することがデザインのビジョンにとって重要であり、このメカニズムを機能するように出来得たというものでした。

　個人的な人間関係を越えて、リード・デベロッパーがチームのメンバーという形で与えられたリソースを巧く使う最良の方法を考えることは重要です。ある人はカードをデザインする仕事で最も力を発揮し、またある人はリミテッドのバランス取りに特化しているかもしれないし、そしてさらに他の人はフレーバーをカードに組み込むのが本当にうまいかもしれません。リード・デベロッパーは自分だけ部屋に閉じこもって１人でほとんど全ての仕事をすることもできますが、そうすることは各チームメンバーをどの仕事に割り振り最大限に活かすかを考え出すよりも、ずっと非効率的で実りが得られないでしょう。つまるところ、少なくとも他のデベロッパーにとっては、デベロップ・チームであることの一部は、彼ら自身のセットをリードする方法を学ぶことなのです。

管理者であれ

　ファイルをきれいな状態に保つことはセットをリードすることの中で最もエキサイティングな部分には見えないかもしれません（そしてやっぱりこれは最もエキサイティングな部分ではありません）が、とても重要なことです。これは明らかに見えるかもしれませんが、焦点が当てられることの少ない時間であり、結果として今回についてはこの時間に苦しめられたと思います。このことは過程の後期に、ある色のクリーチャーの数が間違っている、もしくはちょうどの数しかその色にカードがない場合に時々起こり、急いで問題を解決するためにどうやってアートを入れ替えれば良いのかを考え出す羽目になります。さほど壊滅的ではない状況でさえ、マナ・カーブ上の問題や、似たようなカードが２枚あるといった問題が発生します。セットを適切にメンテナンスすることで、それらの問題の発生は防がれるでしょう。

　セットのリード・デベロッパーが大抵２週間ごとぐらいに行っていることは、そのセットに目を通して、 コモンの白いクリーチャーで点数で見たマナ・コストが最も低いものにCW_01とつけ、コモンの点数で見たマナ・コストが最も重い呪文にCW_20とつけて、割り振られた数字を正しくすることです。こうすることで、他のデベロッパーがファイルを見てマナ・カーブが妥当に見えるかどうか、セットのカードの枚数が間違っていないかをとても見つけやすくなります。おかしなように聞こえますが、これは以前起こったことがあり、リード・デベロッパーがファイルを見て、全てを順に並べるようになった理由の１つです。

　セットの作り方の一般的な概念として、各色は異なるクリーチャーの開封比を持っていて、白は60%で、最も低い青は47％です。壁や本当に弱いクリーチャーによってこの数字は変化することもありますが、セットには各色20のコモンと13のアンコモンがあり、つまり白のクリーチャーはコモン13枚とアンコモン６枚、コモン12枚とアンコモン８枚あるということです。同じく青のクリーチャーは９枚のコモンと７枚のアンコモン、もしくは10枚のコモンと５枚のアンコモンかもしれません。各色に正しい数のクリーチャーがあるようにすることは、カラー・パイに忠実であることと、セットが同じような雰囲気を持ったいくつかの要素を持つと同時に異なる雰囲気のものを持つようにするために、充分似た出発点に立つこと、その両方のために重要なことです。

　また定期的にセットを見渡すことは、データを散発的に入力したりデータベースがエラーを起こしたりしても、誤ってカードがセットから取り除かれてしまうことがないようにします。これは発注する必要があるアートが全てあるようにして、見過ごしが少なくなります。

裁判官、陪審員、執行者であれ

　クリエイティブな仕事であれば種類を問わず最もつらい部分の１つは、そのプロジェクト全体をより良くするために、楽しいものや、興味深いもの、美しいものをあきらめる必要がある時です。マジックのセットに取り組んでいるときにも、これはたくさんあります。これはカードを弱体化させたり没にしたりするかどうか、またその方法を考え出す必要があるとき、リード・デベロッパーが決定者になります。例えば緑に優秀なコモンが多すぎてリミテッド環境のバランスを乱している場合、何かを弱くする必要があります。これはこの仕事の最も魅力的な部分とは言えませんが、時には全体をより良くするために《ネシアンの狩猟者》を《ルーン爪の熊》にすることも必要です。

　マジックのセットに取りかかってからファイルをタイプセッターに引き渡すまでの期間は何ヶ月にもわたり、そして多くのカードが大体１人の手に負えないような問題を抱えています。その問題は、前に出たカードとのスタンダードで許容されない相互作用であったり、以前のセットのカードに似すぎているデザインであったりします――問題のあるカードは将来のメカニズムを完全に駄目にしてしまう可能性もあります。理由は色々ありますが、これら全てはある結論にたどり着きます――リード・デベロッパーが、そのカードを弱体化させる、または変更する必要があるということです。腹立たしいかもしれませんが、これはこの仕事ではよくあることです。このセットのカードは他の誰かのセットのすることをしようとしており、それがまさにマジックの性質なのです。

　他にもリード・デベロッパーはセットの複雑さを管理しなければなりません。我々はかなり標準的な測定方法――コモンの文字数――を持っており、これは我々に合理的な基準値をもたらしてくれます。デベロップ中、カードに文を追加してそれらをリミテッドと構築フォーマットの完全に正確な位置に置くことはとても簡単ですが、そうなると文章量が非常に多くなり、セット全体が過剰に重苦しくなってしまいます。そのときにリード・デベロッパーはカードを見て、いくつかの単語を削除します。

　複雑さには２つの形があります――１つはカードの文章量、もう１つは実際にそのセットをプレイしたときの盤面の複雑さです。目的はこの２つの複雑さを扱える範囲内に納めることです。それは盤面を複雑過ぎないようにするためにソーサリー・タイミングの起動型能力にすることかもしれませんし、対象を対戦相手のクリーチャーだけに制限することかもしれませんし、あるクリーチャー・タイプではブロックできないことを説明している12単語の能力を取り払うことを意味しているのかもしれません。

　結局のところ、複雑さを取り払うことの目的はゲーム・プレイをより円滑にし、プレイヤーの決定を意味あるものに維持することで、そのプレイヤーの全体的な経験を改善することです。このステップ、特に多くの働きをしそうな本当に巧妙な物事を没にすることを意味する場合には、リード・デベロッパーにとって辛いものになるかもしれませんが、避けては通れない必須の事柄です。

　今週はここまでです。来週はフューチャー・フューチャー・リーグのデッキの記録をご紹介し、我々が『運命再編』に取り組んでいたときに何を考えていたかについてお話しします。

　ではまた来週お会いしましょう。

　サムより (@samstod)