2011年3月25日金曜日

Gamasutra 記事翻訳紹介:KinectのジェスチャーUI: 第一印象

今回は別サイトにて翻訳された Gamasutra の記事を紹介します。

オリジナル:


日本語版:

  • U-site:KinectのジェスチャーUI: 第一印象
  • http://www.usability.gr.jp/alertbox/20101227_kinect-gesture-ux.html 

著者はヤコブ・ニールセン博士(Jakob Nielsen, Ph.D.)で”主にウェブサイトにおける、ユーザビリティ(使いやすさ)研究の第一人者” (Wikipedia)。
その博士が Kinect の第一印象を語った記事です。

矢澤がぜひ日本の方にも読んでほしい!と思い翻訳に着手し、ほぼ翻訳し終えたところで博士から「すでに日本語化されており、権利もそちらにある」とお返事をいただく。というわけでここではリンクのみの紹介とさせていただきます。

ここで紹介したことが日本発 Kinect タイトルのユーザビリティ向上の一助となれば幸いです。


2011年3月24日木曜日

Gamasutra 記事翻訳:MADE IN JAPAN:西洋の視点から見た日本のゲーム開発

はじめに


以下は Gamasutra の Features として公開された記事のうち、原著者に翻訳・公開の許可を得られた記事を Internationalization Force のメンバーが翻訳したものです。

(翻訳担当の矢澤竜太は以前本記事を未承諾のまま公開しておりましたが、今回原著者と直接コンタクトを取り、許可を得られたため、ここに転載します)
  1. 原文の著作権等はすべて原著者に帰属します
  2. 誤訳、誤植等については当記事のコメント欄にてお知らせいただければ幸いです
  3. 本記事の公開を快諾してくださった Ryan Winterhalter 氏に深い感謝の意を表します
(翻訳担当: 矢澤竜太)



日本のゲーム業界の体制とデザイン手法は北米や欧州と大きく異なります。 また、日本のゲームスタジオには外国人社員がほとんどいません。マイノリティである彼らは、あの悪名高い長い労働時間や厳しい要求に加えて、文化的/言語的な違い、日本人上司や同僚からの要望とも向き合わねばなりません。 全体から見ると非常に少ない外国人労働者ですが、日本で働く彼らは日本式の業務文化、作業慣行、ゲーム開発に携わる経験を通じて、西洋的手法とは異なる考え方を発見し、身につけています。 基本的な文化/言語的な相違点に加えて、チーム編成手法や組織の上下関係、デザイン哲学などの相違点が、彼らの経験をより特殊なものにしています。
多くの人達にとって、「日本」とは「ゲーム」の同意語です。 「日本の貢献がなければ、今日のゲーム業界は今日のような姿ではなかったかもしれない」とは、Chris Kohler 氏の日本のゲーム業界に関する著書、「Power Up」の序文で Silicon Nights 社の Denis Dyack 氏が書いたことですが、 海外から日本に飛び込んできた彼らこそ、ゲーム業界の日本的側面に関する最も正確な視野を持っているのかもしれません。 今回は、そんな「ガイジン開発者」3 人のインタビューを紹介していきます。
JC バーネット(仮名)氏は東京の某社に勤務する英国人です。 彼のブログ「Japanmanship」では、日本のゲーム業界に関する彼の考えや日本文化の観察などが紹介されています。 日常生活や日本人のガイジンに対する態度に対する鋭い洞察力、そして(彼が「ゲームマンシップ」と呼ぶ)その態度に対する彼の応対方法が話題を呼び、ブログは日本に住む外国人の間で大人気となりました。また日本式業務についての簡潔で深みのある意見は、日本国外に住むゲーム開発者やゲームマニアの間でも評判となっています。
グレッグ・タバレス氏は業界歴 20 年のベテランです。 彼の携わったタイトルには、「Sid Meier's Pirates」、「Wild 9」「Crash Team Racing」、「Loco Roco」などがあります。 東京で 7 年勤務した彼は、最近米国に戻ってきました。
最後にディラン・カスバート氏。彼のキャリアは英国の Amiga development で始まりました。 任天堂の目に留まって横井軍平氏のチームに加わってからは、最終的には StarFox の制作にも参加し、米国と日本の Sony でも勤務しました。 2001 年、京都で Q Games を設立。最近、PlayStation 3 用カジュアルゲーム「Pixel Junk」を発表しました。

日本への道

「私の場合、日本で働きたいというよりは、生活したいという気持ちのほうが強かったと思います。 少しでもオタク要素があれば、東京に惚れこんでしまうのは簡単なことですから。 なので、私の来日のきっかけは東京に住みたい!という願望が基になっています。 日本で働く、という決断はそれに伴う必然だったんです」と、バーネットは言います。
最近の大学キャンパスでは、日本で働くことを熱望している学生を見つけるのは難しいことではありません。 ゲームへの興味が日本への興味と繋がっていることはよくあります。 いつの日か日本に住んでみたいと願う学生はたくさんいます。 「業界歴の長い開発者はもう少し現実的で、長時間労働の噂なんかを心配しますが、若い人やこれから業界入りを狙ってる人なんかの場合は、(日本行きを)とても熱望しています。 ちょっとした盲目的信仰ですよね。 みんな "宮本さんのチームで次のゼルダとか、ミリオンヒットするゲームの開発に携わるぞ!" とか考えるんですよ」
とは言うものの、好奇心に誘われて日本に来る交換留学生、英語教師、ゲーム開発者は毎年後を絶たない。 「僕が真剣に日本語の勉強を始めたのは 1995~1996 年でした。 1997 年の後半に失業していたとき、"うーん、反対する彼女や嫁、子供もいないんだから、本気で日本語を勉強したかったら日本に行ったほうがいいんじゃないか?" って思って。日本に行って日本語を勉強しよう、って決めたんです。 でも生活する手段がなかったので、どうしても日本で仕事を見つける必要があった」
日本に住むために日本行きを決定するガイジン開発者が多いのですが、彼はそうではありませんでした。 彼は日本に住むことを目的として来日したわけではなかったわけです。 「初めて来日したときは日本についての知識もほとんどありませんでした。 大急ぎでゲームボーイ用の 3D デモを作ってArgonaut Software 社に送ったら、任天堂から 2 週間後に京都に来てエンジニアにデモを見せてくれないかと誘われたんです。 京都とその時に会った日本の人たちの印象がとても良かったので、 その第一印象に従って、"ここで生活し、働いてみよう" って決めたんです」

企業ごとの違い

日本のビジネス文化は、西洋人にとって恐ろしいものとして知られています。 日本の生活と仕事の紹介本は、厳しい上下関係、融通の利かない業務手順、日本の諺「出る杭は打たれる」といった内容で埋め尽くされていますが、幸運なことにゲーム業界はまだ気楽な雰囲気があるようです。 バーネットによると「オジギやケイゴはあまりないし、スーツを着ている人もいないです。 リーダーや上司も肩肘ばった所以外では結構気楽にやってます。 笑い話もできるし、飲みに行ったりもします。 まあ僕はガイジンなので、それ以上うまくはやれないですが、同僚だってみんなが思っているほど堅苦しくはないですよ」
また文化的な違いは時に争いの種となるとカスバート氏は言う。 「日本人上司は間違いなく、西洋社会の上司よりも社員に干渉してきます。そういう風に干渉されるのは "先天的に (上司のほうが) 優れている" と言われているようで、西洋的な考え方からすると不快に感じることが多々あります。でもほとんどの場合、その上司は単に職場の協調性と規則を保とうとしているだけで、理由もその部下の作業効率が高いからなんですよね。 私はいまだかつて、何の理由もなく不機嫌な日本人上司を見たことがありません」
一方、日本で働く多数の社員にとって最大の問題と目されるのはその労働時間の長さだ。 日本の正しいエチケットでは、上司が退社するまで部下は退社してはならず、直属の上司が働いているうちは退社してはならないとされており、 このルールは、各人の仕事が終わっているかいないかに関係なく適用される。 タバレス氏は、このルールが日中の業務内容が「たるむ」原因だと言う。
「日本人は長時間働きませんよ」とタバレス氏。 「彼らはオフィスに長時間いるんです。これはほとんど文化的な要因によるものです。 日本では、米国学生の社交クラブで採用されているような「センパイ - コウハイシステム」が採用されています。 新入生、いわゆる新入りは基本的に誰かの下に配属されます。 その人物がコツなどを教える役目にあたり、その新入生に対する全責任を負います。逆に新入生はセンパイの言われたとおりに動く、というシステムです」
「風習として "センパイが全員帰るまでは退社してはいけない" というのがあるので、センパイや上司が退社するまでは帰らないようにしなければ、となるわけです。 このシステムは常に使用されているわけではないですが、一般的であるのは事実です。通常、これを守らない場合は出世も望めません。 日本の経済的状態のため、多くの企業では終身雇用が維持できなくなってきています。しかし彼らは、いまだに終身雇用が有効であるかのように振舞っているのです」とタバレス氏は続けます。
ここでバーネット氏の意見を紹介しよう。「古い慣習から抜け出すための武器として、自分がガイジンであることを利用することもできますね。ただ、実現するにはそれなりに時間もかかります。 私は入社したての頃は、同僚と同じ時間働くようにして、それから少しずつ短くしていきます。 周りの人に私の勤務時間に慣れてもらう時間が必要だからです。 私が一番に出社することが周囲の人に知れ渡れば、私が一番早く退社しても周囲に与えるショックが薄まります。 そしてもちろん、やるべき仕事は勤務時間内にすべて終わらせておくようにします。 仕事が滞っていたり、品質が一定の水準に達していなければ、私だって早く帰ったりしません」
「私の上司もまだ僕が日本的な勤務時間に合わせることを望んでいると思いますが、それでも最後には収まるものです。 実際、同僚にも "早く来て早く帰る" 僕のスタイルを取り入れるように仕掛けてみたりします。僕という前例があるのでそれに乗っかってしまえばいいと。 僕にとっても、仲間ができれば心強いですし」
日本の勤務時間と同じくらい、ゲーム業界の勤務時間も評判が悪い。 一日あたりの労働時間が長いとはいえ、1 日に働ける時間には限度がある。その点を考慮すると、日本よりも西洋のほうがひどい、とカスバート氏は言う。 「労働時間が一番長い国はまず間違いなく米国です。 3 年ほど前米国で働いていましたから当時のことは知っていますし、現地で働いている人の話でも、週末も休まず働いて平日も恐ろしく長い時間働いていると言います。 日本での仕事もかなりハードではありますが、さすがにそこまでひどくはありません」
勤務時間は企業によって大きく違うようだ。 バーネット氏のブログには連日徹夜する同僚のストーリーがあふれている一方、タバレス氏の次のような例もある「セガでは、平日朝 10 時から夜 11 時半まで働いて、社宅まで片道 1 時間 20 分かけて通勤していました。 それでも我慢できたのは、ひとえに日本に住めるという特権を心から楽しんでいたからですね。 2 度目の来日時に入った会社は、時折忙しい時期こそあれ就業時間としては一般的な範囲内でした」

言語と文化の問題

言語の壁は日本で働く外国人にとって問題であることは間違いない。 長年日本に住み国籍も移していても、レストランで注文も出来ない、という人も珍しくない。 米国防衛省では、日本語をレベル 4 の言語(韓国語、中国語、アラビア語と同じ)と分類しており、”限定的な業務に必要な習熟度” に達するにも 63 週間の集中的な学習が必要と説明している。一方、レベル 3 のベトナム語、タイ語、ロシア語などの言語は 43 週間だ。
タバレス氏によれば、言語の壁に適応しなければならないのは日本人側と外国人開発者の両者であるという。 「日本人スタッフは、私の日本語スキルが高くないとすぐに分かったようでした。 でも私のプログラミングスキルは高かったので、すぐに他の人にはできない仕事が割り当てられるようになりました。 チームには英語が話せるスタッフが 1 名いてサポートしてくれましたが、彼には私の日本語が上達しなくなるので可能な限り英語で話さないで欲しいとお願いしました。 かなりのコミュニケーションは絵を使って行いましたね」
カスバート氏もまた、来日当初は言語の壁に悩まされたそうだ。 彼の場合、チームの対応は次のようだったという。「日本人スタッフが英語を覚えたんです!宮本さんの英語は、ほとんどスターフォックスチームから覚えたようなものですよ。 ただスターフォックスの開発も終わりに近づくと、彼らの英語よりも私の日本語の上達のほうが速くなってきていたので、スターフォックス 2 のときはすべてのコミュニケーションが日本語で行われました」
日本語を第二言語として学ぶ者にとって、丁寧さや敬意を示す動詞の語形変化と語彙、すなわち「敬語」は最大の難問のひとつだ。そして職場においては、敬語こそが優先的に使われる。 社内でのコミュニケーションには丁寧語、上司やクライアント、ユーザーなどに大しては尊敬語が使われる。 カスバート氏は次のような順で日本語を学んだという。「僕の場合、最初に標準的な口語を覚えてから、徐々に敬語や丁寧な言葉を覚えていきました。 普段はみんな口語で喋っているから敬語より覚えやすかったし、敬語だと硬かったりよそよそしかったりするので」
一方で日本人は、たとえ敬語が求められている状況であっても、外国人には敬語を話すことを求めない傾向がある。 実際、日本人は外国人=日本語がまったくしゃべれないと思い込んでいる、と非難する外国人は多い。 さらに悪いことに、管理者が「日本語がわからない」という欠点を不当に利用する例がある。 バーネット氏は言う。「最初私の日本語が酷かった頃、"日本語ができない" ということは、上司がいつでも使える具合のいい逃げ道になっていました。 当時は、何を聞いても、何を頼まれても、どんな問題があっても、"でも君の日本語力では…" というセリフで片付けられてしまっていたんです。 これを止めてもらうには、徹底的に抗議して退職までほのめかす必要がありました」
日本人は外国人に対して英語以外の言語で話しかけにくいと感じることがある。 これは外国人社員にとってみれば不運なことで、彼らの日本語スキルはそこで頭打ちになってしまう。 カスバート氏の言葉を紹介しよう。「日本の人たちは英語で話そうとしますが、とにかく自分に自信を持ってあきらめないことです。そうでなければ、あなたの日本語力はあっという間に上達しなくなるでしょう」
違いはまた、言語以外にも存在する。 一部の企業では、(西洋とは)全く異なるデザイン感覚が採用されている。 カスバート氏の場合、これが特にはっきりしていた。ヨーロッパでは NES(Nintendo Entertainment System:ファミコン)がポピュラーではなく、英国で日本製ゲームに触れる機会があまりなかったためだ。 彼のこの点は、スターフォックスに長所として反映されていると言える。このゲームにより、任天堂はヨーロッパでの活動を開始したからだ。 「任天堂の細部にこだわる姿勢には本当に驚かされました。ゲームデザインの最も小さい要素にさえこだわり抜くんです。 おかげでとても楽しんで仕事ができました。 僕自身もディテールのことになるとトコトンこだわります。 1 ピクセルを納得いく場所に置くために何時間もいじくり回したりしますから。 なので任天堂チームで働いているときに自分と同種の人と何人もめぐり合えたし、それで日本を愛す気持ちを一層強くなりましたね」
また、報道機関に対する態度も異なる。 開発者にとっては、広報やマーケティングにうるさく言われることなく設計する自由がある、とバーネット氏は言う。「この点は、間違いなく日本のゲーム開発の好きな点ですね。広報、報道関係、マーケティングのことは開発のかなり後半になってから始まります。 広報、営業、報道機関側は、なんとか情報を入手しようとするのではなく、こちらからの連絡を待つような感じです」

欧米の視点

日本のゲーム業界で働く外国人は、この業界を独自の視点で捉えることができる。視点を自分の文化を別の視点から見ることができるからだ。 日本のゲーム人口が縮小するに伴い、海外市場の重要性は日ごとに増してきている。 しかしバーネットによると、重要性が増しても彼らが外国人同僚にアドバイスを求めるということはないとの事だ。 「あるときプランナーから、なぜ名前入力スペースを 5 文字以上も確保するんだ?と苦情を受けたことがありました。 ローカライズのために必要だ、というのは彼もなんとなくは分かっていたみたいだったのですが、彼の反論は要するに、"今作っているのは日本語版なんだから 後でローカライズ版を作ればいいじゃないか" というものでした」
「こういう問題についての計画が全体的に足りていないんです。 焦点をメイン市場に絞り、ローカライズ版は後から対処する、という手法には必ず問題が付きまといます。 これは想像に難くありませんが、後からローカライズする場合、修正時に途方もない問題がどんどん発生します。 テキスト表示幅が全然足りない、テキストを表示するテクスチャが多すぎる、どれもこれもハードコードされていて処理を自動化できない、などなど。多くの開発者は、日本よりも規模の大きい海外市場の重要性を認識しているとは思いますが、ではそれに対して何が求められているかを理解している人は本当に少ないと思います」
すべての開発者が上述の意見に当てはまるわけではないようだ。 カスバート氏は言う。「任天堂のプロジェクトでは、最初にローカライズについて考え、別言語のグラフィックスやテキストを差し替えられるように心がけていました。 このほうがローカライズ段階に移ったときに作業負荷が軽くなりますからね」
海外市場向けのゲームを開発する上で問題となるのは、欧米でヒットするのがどのようなゲームなのかを日本の開発者が知らないという点ではないだろうか。 日本人は日本製ゲームの魅力を充分に楽しんではいたが、日本の市場はこれまで欧米に対して開かれたことはなかった。"Gears Of War" と "Final Fantasy" の両方が好まれるようになった今の日本市場に、開発者たちが対応していくにはさまざまな課題があるだろう。 カスバート氏はこう言う。「ゲームのスタイルは、見た目にはアメリカ的、西洋的になります。 (西洋での)テーマはより気骨のあるリアルな方向に進む傾向がある一方で、日本のゲームはより抽象的でアニメ的です。欧米産のゲームは平均的な日本のゲーマーの好みには合わないでしょう。 もちろんクラッシュバンディクーのような一部の例外はありますが」
欧米産ゲームが日本市場で受け入れられてこなかった理由のひとつにローカライズの問題がある。 タバレス氏は言う。「ローカライズというのは、単に字幕をつけて UI テキストをいじればいいというものではありません。 英語版をプレイするゲーマーと同じ没入感を提供するには、音声が日本語化される必要があります。 ゲーム中で使用される歌があるなら、それらも日本語化されなければなりません。 ゲーム内で放送されるラジオに CM やジョーク好きの DJ が出てきてゲームに彩りを添えているなら、それらがすべて日本語化されない限り、日本人プレイヤーはゲームの一部を体験できないことになり、結果そのゲームの評判にも影響が出ます。別の地域からゲームを持ち入れるとき、このことがノータッチのままであることが多い」
だが変化は、ゆっくりながら起きているようだ。 「日本ではかつて、日本のゲームのほうが優れているという考え方がありました。 しかしこの数年、ナンバー 1 ゲームはずっと欧米産です。 日本はもはや技術的にもトップではなくなったことに加え、欧米のチームがゲーム開発の負担をより軽くするシステムを生み出したのを見て、日本の開発チームも注目しだしたようです」とタバレス氏は言う。
これにはバーネット氏も同意する。「文化的に鼻にかけている雰囲気も若干ですがあります。 一部の日本人は、本気で(訳注:この本気は欧米産ゲームの現状を知らず、過去の大味なイメージを持ったままなので本気で、という意味です)欧米産ゲームを見下しています。多くの欧米人と同じように、日本のゲームのほうが数段優れていると思っています。 もちろんこれはナンセンスです。 私の同僚は時々、欧米産ゲームのクオリティを見て驚くんです、こんなのできるわけないと思っていた、と言わんばかりに」
欧米のゲーム開発がよりパワフルで最先端のものであるということが明らかになるにつれて、彼の言うような見解は珍しいものになりつつあり、日本側としても無視できない状況になってきている。バーネット氏は続ける。 「僕の同僚にも欧米産ゲームが好きな人は多いですね。 パブリッシャーは未だにゲーム輸入には消極的ですが…。GTA(グランドセフトオート)が日本に来るまでどれだけの年月がかかったか知っています? まあ、この分野でも変化は起きつつあります。伝統のそれと同じように、非常にゆっくりではありますが」

求められる変化

日本では、変化は非常にゆっくりと起きる。 中央省庁の財務記録は未だに紙の台帳と鉛筆で記録されているという話もある。 民間企業はもう少し対応が早いとはいえ、バーネット氏の次の発言のとおり、変化に対する抵抗は未だに残っている。「日本企業は時代の流れに合わせて変化していくためのアクションが極端に遅いです。 従業員の権利や性の平等といった問題でさえ未だに解決されていないのです」
日本で働く外国人にとって、最大の問題は給与かもしれない。 バーネット氏のブログによると、アーティスト、プログラマーの給与水準は欧米と比較して低い。 タバレス氏は、日本企業は新卒を安い給与で雇用する、と言う。 セガやソニーに入社するプログラマーの年収はおよそ 300 万円で、 トッププログラマーの年収がだいたい 600 万円である。 日本企業がそのような方針を採用しているために、日本企業では個人の持つ経験の価値が軽んじられる。
「経営者にとっては幸運、社員にとっては不運なことに、彼らのほとんどは日本語しか話せない。このため基本的に働く場所が日本のシステムの中にしかないんです。 英語を身に付けることに成功した人たちには、より良い給与を求めて日本を去るという選択肢がありますが、そうでない人には選択肢がありません。だから外部からの圧力ではこのシステムは変わらないんじゃないかとも思うんです」
ゲーム業界自体がめまぐるしい変化を起こしている以上、日本企業も変わる必要がある。 だが現状を見る限りでは、それも望めないようだ。 給与、労働時間、実績に対する報酬などの問題は引き続き日本の開発者たちを苦しめるだろう。 「"新卒を安く買い叩く" 問題には全く進展が見られませんし、変わるかどうかも怪しいものです。青色発光ダイオードの発明者は日本を去りましたが、その理由は、企業が彼の発明に対して充分な報酬を与えなかったことに対する怒りからだということです。日本企業は報酬を与えなさすぎる。先述の例は、日本企業がやり方を変えないなら、賢い人は国外に出ろ、と言っているようなものですよね」とはタバレス氏の言だ。
変化の遅さや、そもそも変化が起きていないことと比較できるほど顕著ではないが、この業界にも進歩の兆候が見られつつある。 「まだまだ道のりは長いですが、私も実際にいくつかの変化を目の当たりにしました」タバレス氏は言う。 「例えば、ミドルウェアの導入なんかは私がいたときに起きた変化でしたね。 バージョン管理システムなんかもそうです。 何でもハードコードする手法からレベルエディタなどのツールを使うようにもなりました。内部からの圧力で変化を起こすことも可能なんです。 もしある企業が各人の経験に対して正当な給与を支払うようになれば、他の企業も経験豊かな人材がそちらに流れないように給与を見直すことになるでしょう」
最後に、ゲームの三大地域で実際に生活し、働いたことのあるカスバート氏のまとめをご覧いただこう。
  • 「英国は "パブ文化" の国と言えるでしょう。びっくりするほどグウグウノロノロしているけど、いざ腰をすえると、仕事はとてもちゃんとやるしスキルも高いです」
  • 「米国は "企業文化" の国です。会社の規模に関係なく、各人が機械の歯車となります。このため企業や財務に対する責任は非常に少なくなります。また人々は最高の賃金、最高の機器、最高のソフトウェア、すべての "最高" を求めます ― それを使う、使わないは置いておいて。 このため仕事自体への責任感がとても大きく、非常に頭の回転が速い勤勉な人たちもいます。 ただ、駆け引きとか噂話、ライバル意識なんかが多すぎると感じます」
  • 「日本のゲーム開発文化は、未だに少し "サラリーマン" 的ですね。多くを語らないことで責任を回避しますが、製品が完成するまで絶え間なく努力し続けます。 (喋らない文化が災いして)情報共有がうまくいっていないせいで、日本のゲーム業界は技術的な発展が滞っています。 日本人は納得できるまでディテールにこだわり続け、場当たり的なもの、荒削りなもの、あるいは "オオザッパ" なものを極力排除しようとします」

Gamasutra 記事翻訳:プロダクションの価値: プロジェクトマネージメントの価値

はじめに


以下は Gamasutra の Features として公開された記事のうち、原著者に翻訳・公開の許可を得られた記事を Internationalization Force のメンバーが翻訳したものです。

(翻訳担当の矢澤竜太とその友人は以前本記事を未承諾のまま無償公開しておりましたが、今回原著者と直接コンタクトを取り、許可を得られたため、ここに転載します)


  1. 原文の著作権等はすべて原著者に帰属します
  2. 誤訳、誤植等については当記事のコメント欄にてお知らせいただければ幸いです
  3. 本記事の公開を快諾してくださった Heather Maxwell Chandler 氏に深い感謝の意を表します

(翻訳担当: 矢澤竜太 および 友人 P)


プロダクションの価値: プロジェクトマネージメントの価値

By Heather Maxwell Chandler
私はこの業界でプロデューサーとして何年も働いてきたが、これまでには開発チームから「敵」とみなされたことや、良いゲームを作ることではなくスケジュールのことばかり気にしていると思われたことがあった。もちろんそうではないのだが、この思い込みを払拭するのは難しい。タイトルの発売日に間に合わせるためにチームの士気を上げようと試みることが頻繁にあることも事実だからだ。
プロデューサーだって、納期しか気にしない悪者になどなりたくない。しかし、カオスなプロジェクト (スケジュールが激しく変動する、スコープがどんどん増える、プロジェクトのリソースが流動的) を管理しようとするとき、厳しい納期が設定されることの多いゲーム開発分野で締め切りを守るには「スケジュールを守るための最善策をとり続ける」しか道がないことも多いのだ。
実際に、クリエイティブな能力が抑制されてしまうことや、根本的な仕様変更ができなくなること、良い作品をスケジュール通りに公開するチャンスが無くなってしまうことを恐れて、ゲームの仕様を明確に決定したり確立されたプロジェクトマネージメント手法を導入することをためらう開発チームは少なくなってきている。
ゲームのスコープが増えて開発チームが大きくなればなるほど、プロデューサーは、プロジェクトの経過を把握するために確立された (規則に沿った、Formal な) プロジェクトマネージメント方法を取り入れる必要がある。しかし、ゲームの開発方法には簡単に枠にはめることのできないもの (ウォーターフォールモデルなど) が数多くあるため、そのようなマネージメント方法は受け入れられ難い。
また、一部の開発者は「クッキーの型みたいな紋切り型のプロセスでは創造的なゲーム開発は難しい」や「ゲーム開発そのものより事務処理に煩わされてしまう」と主張する。しかし、開発環境に合わせて調整できるような有用な方法やプロセスも数多くあり、その方法やプロセスであれば開発チームは日常の作業方法を大きく変更しなくて済む。場合によっては、開発チームやチームメンバーは、プロセスの有用性を確かめてから作業方法を変更することもできる。
形式的なプロジェクトマネージメント手法を上手く導入するには、そのプロセスの必要性と開発チームにおよぼす利点をチームに説明する必要がある。それを怠れば、プロセスの導入は成功しないばかりか、開発チームは、形式的なプロジェクト管理手法がゲーム開発には適用できないと信じ込んでしまうことになる。
チームの賛同は一朝一夕で得られるものではないため、プロデューサーはチームがプロセスの変更に対応して行きやすいように、また、最良の結果を引き出せるように徐々に変更を加えていくことに専念する必要がある。それでは、変更すべき要素とは何だろう? そして、どうすればチームはその変化を積極的に受け入れてくれるだろう?

メンバーのニーズに耳を傾ける

プロデューサーにとって、チームメンバーの声に耳を傾けることは非常に重要なタスクのひとつだ。チームはゲームの開発方法について言いたいことがあるのが当然だ。実際にAIのコードを書き、キャラクターモデルを作り、マルチプレイ機能を設計し、ゲームをテストするのは彼らなのだから。
プロデューサーが何か新しい手法やルールを強制的に導入しようとするときに変更する理由を説明できなければ、チームは反発するだろうし不満がたまって生産性も落ちるだろう。だからこそプロデューサーは、「なぜ彼らが自分たちのやり方で仕事を進めているのか」や「どうやったら業務環境を向上できるか」を話し合えるような「開かれた環境」を作ることが重要なのだ。
例えば、あるアーティストが深夜働くことを好む理由として、日中は頻繁に質問されるのでそれに答えなければならない、呼ばれた会議に出なければならない、だから皆が退社した後が一番生産性が上がるのだ、と答えるかもしれない。こういった場合には、実際に彼に割り当てられている作業量は普通であることがほとんどで、ただ作業を頻繁に中断せざるを得ない状況のために時間をうまく使えず、結果として作業が遅れがちになっていることが多い。
こんなとき、メンバーの業務時間に影響を与えている問題を特定してそれをチーム全体で話し合うことができれば、多くの場合はメンバー全員のワークフローを改善する新しいプロセスを作りあげられる。この方法であれば、チーム全体が問題解決に積極的に携わるようになり、プロデューサーは「独裁者」ではなく「ファシリテーター」になれる。

確立されたマネージメントプロセスがメンバーにもたらす利点を知ってもらう

自分の経験上、プロダクション前の段階でプロジェクトマネージメントの基本方針について簡単に説明する時間を取ると、チームのメンバーは労働時間が短縮される可能性を知って張り切ってくれ、それを実現するべく、方針を積極的にサポートしてくれるようになる。また、基本方針を説明することでチームメンバーはプロデューサーが毎日何をしているのかをより理解できるようになるし、同時にチームがプロデューサーに対して抱いている「スーツ(Suits = スーツを着た、経営責任を持つマネージメント層の人たち)」の手先なのではないか? という疑惑を晴らす助けになることもある。
大多数のゲーム開発者が規則に沿ったプロセスに対して懐疑的である以上、彼らが「スーツ」の押し付けてくる手法を警戒するのも自然な流れだ。だがこれは逆に、開発チームがプロデューサーを身内だとみなしてくれれば、業務環境の向上を実現するためのプロジェクトマネージメント手法をしっかり聞いてくれるようになるということを意味する。
プロデューサーは柔軟で、導入するプロセスがなぜ必要で、プロダクションサイクル全体でどのような利点があるのかを周りの人に対して説明する姿勢がなければならない。また、メンバーがプロジェクトマネージメントについて抱いている不満 (や賞賛) にしっかりと耳を傾けることも大切だ。例えば、開発チームに「新機能を追加する場合には変更依頼書を記入する」というルールを強制すると、実際に書類を作成する人は少なくなってしまうが、その提案が簡単に実装できてゲームを劇的に改良するアイデアであったりする可能性は高い。もちろんこれは変更依頼書は使うべきではないという意味ではないが、「変更依頼書」を作成するタイミングについてプロデューサーは柔軟に対応する必要があるだろう。
プロトタイプ作成フェーズや開発の初期フェーズはその好例だ。これらのフェーズでは変更の発生回数が非常に多いため、変更依頼書が生産性を落とす要因になってしまう。一方で、すべての要素が固まりきった後 (開発終了まであと1ヶ月を切っているような状況) には、変更の内容 (UI のカラースキームを新しくするなど) と依頼者 (上級管理職) に応じて変更依頼書を作成したほうが賢明と言えるだろう。

最も影響力の高い、基本的なプロジェクトマネージメント手法に集中する

導入するプロジェクトマネージメント手法を決定する際には、導入が簡単で、かつチームにとって最も (ポジティブな) 影響力の強い手法を選択するのがいい。例えば、余分な作業を極力なくしながらすぐに実施できる手法のひとつに、ミーティングの実施方法を変えるという手がある。
何のための会議なのかがよく分からないまま時間だけが過ぎていき、会議の後も議論した内容について何のアクションも取られない... そんな風ではそもそもミーティングを持つ意味がない。
プロデューサーがあらかじめアジェンダ(議題)を用意し、メモを取り、アクションアイテムを定義して割り当て(納期も設定する) 、各アクションアイテムについてフォローアップを欠かさないようにする。それだけで、ミーティングは突如として参加者がびっくりするほど有益な時間になる。これならほんの数分で用意できるし、プロジェクト全体で削減できる時間を考えれば極めて有効な時間といえるだろう。
また混乱の生じやすいゲーム開発においては、プロジェクトの定義に焦点を絞る手法も導入が簡単であることが多い。例えば、WBS (Work breakdown structures:作業構成明細) は自分の担当作業が他のメンバーの作業に与える影響を認識してもらう際に非常に有効な資料だ。ライティングツールを担当するエンジニアは、自分の作業が1 週間遅れるとアートのスケジュールに大幅な変更が必要になるなどと知らないかもしれないし、デザイナーは、担当レベルのスクリプトの完成が一日遅れると QA チームの作業フローに影響することを知らないかもしれないのだから。
また WBS には、これ以外にもメンバー向け資料として非常に有効な使い道がある。それは、開発中ゲームのフィーチャーをひとつ選び、その開発に携わっているメンバーを全員集め、メンバーからの入力を元に WBS を作成する方法だ。これにより、各メンバーの業務がどれほど他のメンバーに影響を与えるかがすっきりと示せるだけでなく、ゲームを期日までに完成させるためにメンバー全員が「本当に」何をしているのかを正しく認識できる。
同様の手法はチームにおけるメンバーの役割を定義する際にも利用できる。メンバーの席に行ってから「この人は今日一日何をしていたんだろう?」と思った経験が一度もないプロデューサーはおそらくほとんどいないと思う。そんな場合には、現行プロジェクトにおける各チームメンバーの役割を定義してそれを皆と共有する時間をほんの少し取るだけで、大きな差が生まれる。この程度なら、「車のAIのコード書いてます」や「UI アート作ってます」、「新しいゲームタイプのプロトタイプ作ってます」のように簡単にできるが、メンバー同士の精神的なつながりを醸成する上で非常に役立つのだ。

スケジュールの柔軟性を説明する

私の経験では、ゲーム開発プロセスで形式的なスケジュールを組むことを好まない開発チームは、どのようにスケジュールが作成されているかをほとんど知らないのだ。そういう開発チームは、スケジュールを組むことが開発を進め難くするだけの単なるペーパーワークに過ぎないと思っていたり、Microsoft Project の使い方を覚えさせられ、開発よりもタイムトラッキングの方に時間を奪われてしまうものだと思っている。
また、調整できないようなスケジュールに苦労した経験も過去にあるし、開発の最終段階で発生するフィーチャークリープ (予定されていない機能が追加されること) によって、開発終了までの残り数ヶ月間を週80時間労働で乗り越えなければならなかったような経験もあるため、こういった部分をスケジュールに組み込むことは不可能のように思われるのだ。
そのため、チームメンバーたちにスケジュールを提出するように求めても「明日になればスケジュールは変わってしまうのに、その必要があるんですか?」とか「スケジュールを立てられないような修羅場があるんだし、提出する意味が無いでしょう。土壇場でフィーチャーが追加される場合なんて特にそうじゃないですか」といって拒否されてしまう。しかし、こんなときこそスケジュールがどれほど有効なものかをチームに説明できる絶好のチャンスだ。
実用的なスケジュールの基本要素は、タスク、タスクの所要時間の見積もり、タスクの担当者、それにタスク同士の関連性である。タスクによっては納期が固定されている場合 (例えば、感謝祭にあわせた発売日など) があるが、大抵の場合、スケジュールの要素には最終締め切り日を実現するための柔軟性が豊富に含まれている。
言い換えれば、スケジュールは、フィーチャーの優先順位、リソースの割り当て方、追加すべき、または削除すべきフィーチャーなどを決定する基準とすることが可能なのだ。すでに文書化された基本的なスケジュールが用意されていて、そのスケジュールがさまざまな状況 (アーティストが追加される、フィーチャーが削られる、レンダリングタイムが減少するなど) に迅速に対応できるよう作成されていれば、もっと簡単にこの種の問題に対して迅速な決断を下すことができる。スケジュールを考えるとき、常に変化し続ける (そのためにスケジュールに組み込めない) タスク内容と締め切り日のかたまりとして考えるのではなく、特定の時間枠の中で開発チームが達成できる目標や、発売日に間に合わせるためにどのような調整が可能かを判断するツールとして捉えてみてはどうだろうか。

プロジェクトマネージメントによっていかに作業環境が改善されたかをチームに説明する

新しいプロジェクトマネージメント手法を取り入れる際に、プロデューサーは新しい手法がもたらすポジティブな影響を継続的に説明していかなければならない。チームは、フィードバックのトラッキング、アクションアイテムのフォローアップ、キータスクへのフォーカスによって得られるメリットを体験することで、新しい手法を受け入れるようになり、さらに高度な手法に対しても意欲的に挑戦してくれるようになることもある。
そのうえ、ゲーム開発サイクルに優先順位を確立することでこれまで以上に時間を割り当てられるようになり、工夫を凝らして完成度を高めたり、新しいアイデアに考えをめぐらせたり、バグを修正したりといったゲーム開発に関連する作業そのものにもっと集中できるようになることを理解してもらえるようになるのだ。

毎週の定期ミーティングを変化のフォーラムとして活用する

毎週行うチームミーティングはプロジェクトマネージメント手法の変更内容を説明する絶好の機会だ。プロジェクトがトップスピードで進みだして制御不能になりかけ始めているようなときには特に。ここでの要点は3つ。第一に、チームミーティングはプロジェクトに関する情報を配信し、寄せられた質問に回答する場であること。第二に、新しいアイデアについての議論やフィードバックを容易にするためには、メンバーは全員同じ部屋に集める必要があること。第三に、それにより全員が週に一度必ずプロジェクト全体について考えるようになり、自分のタスクが他のメンバーにどのような影響を与えるのかを理解する機会となるということ。
プロデューサーはミーティング前に議題を必ず用意し、どのプロジェクト管理手法について議論するかを決めておかなければいけない。初めてのミーティングでは「各メンバーにプロジェクトで担当する作業を説明してもらう」といいだろう。チームが大規模の場合は、全員が説明するまでに数回かかる場合もあるため、不必要なまでに詳細な情報を話し続けて15分を無駄にする、などということが起きないようにある程度のルールを設けると良いだろう。

結論

ゲーム開発メンバーに「プロジェクトマネージメントは現場の人たちを支援する」ことを理解してもらうのは別に難しくない。十分に時間をかけて基本的な方針を説明し、プロジェクトに変更を加える際には必ず開発メンバーとも連絡するようにしさえすれば、だが。
ただ覚えておいてほしいのは、この記事はあらゆる問題を解決する魔法の弾丸ではないということだ。混沌を極めたスケジュール、変化し続けるスコープやリソースなど、問題は挙げていけばきりがない。しかし一方で、プロセスに加える変更をどんな細かなものでもチーム全体が団結して決めるようにすれば、問題は最小化できるし、混沌に秩序をもたらすことができるのだ。
Copyright c 2008 Think Services
---------------------------------------------

2011年3月22日火曜日

放射線被曝量の比較図

先日IGDA日本ニュースページにポストした内容ですが、新しくIF(Internationalization Force)としてのブログを作成し、こちらに移しました。翻訳はIFのメンバーで米サンフランシスコ・ベイエリア在住の米田健さんです。直接ゲームとは関係ありませんが、IFではこうした活動も行っていきます。(小野憲史)

==================

理系漫画サイトのXKCD作者、ランダル・モンロー氏がアメリカでのパニックを見てこの比較図を作りました
日本においても、シーベルトという聞きなれない単語が飛び交っている中、それがどのような意味を持つのか。
その説明がマスコミや各種メディアにおいて絶対的な不足をしていると思います。

すごく理解がしやすいこの図を和訳をしてみました。
別に安全だ、安全じゃない、という指針といった意味合いは無いのですが。
現状でどれだけの放射性物質が漏洩しているのか、その数字がどのような意味をもっているのか。
それを理解するだけでも大きく現状把握に役立つと思います。
原作者のランダルさんは転載、翻訳、応用を含む全著作権はフリーとしています。(公有資産指定)


http://xkcd.com/radiation/
by Randal Monroe

原作者よりのコメント:
For people who asked about Japanese translations or other types of reprinting: you may republish this image anywhere without any sort of restriction; I place it in the public domain. I just suggest that you make sure to include a clear translation of the disclaimer that the author is not an expert, and that anyone potentially affected by Fukushima should always defer to the directives of regional health authorities.

この図は専門家が作成しているのではない事、福島、そしてそれ以外にも原子力関係の影響を受けている人はこの図に頼らずに、地域の人身安全の責任者の方針に沿って行動をする事。