2011年3月24日木曜日

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

はじめに


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結論

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

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)