 |
| ソニー・コンピュータエンタテインメント ジャパン 古川 隆信氏 |
古川氏はゲームメーカーのデバッグチームが行う業務を「デバッグ」、SCE品質管理部が行う業務を「マスターチェック」と呼び分けて、その業務を実際のワークフローに沿って説明。
 |
| デバックとマスターチェック |
ゲームタイトルはまず、メーカー側のデバッグチームにより仕様書に沿ったチェック（デバッグ）が実施されてからSCEに納品されます。この発売候補は「マスター」と呼ばれ、SCEの品質管理部門ではマスターに対して発売を承認するかどうかのチェック（マスターチェック）を実施します。これはプレイステーションビジネスのルールとして存在するもので、すべてのプレイステーションタイトルはSCE品質管理部門の承認を得てから発売されるようになっています。
マスターチェックの内容はSCEの規定する基準書の要件を満たしているかどうかと、ゲームをプレイして問題がないかどうかの2点。ここで問題が見つかると非承認となり、メーカー側での修正後に再チェックが行われるしくみになっているとのこと。
古川氏は、SCE品質管理部門からの修正依頼には強制力があることを説明した上で、メーカー側で問題がないと考えている事項についても修正を求めることがあると話します。
また同社品質部門は「基準書」の作成にも参加していて、厳しすぎる基準を作成してゲームの開発をいたずらに難しくしないよう最新の注意を払っているそうです。強い決定権を持つ部署だからこそ「ユーザーもメーカーも "Customer"」という思想のもと、公正さを保てるように努めている、と語りました。
続いてテーマは「品質管理」の担当範囲へ。「安全安心における品質」と「性能における品質」というキーワードを挙げ、ゲームメーカー側のデバッグチームは安心安全と性能の「品質向上」を担当し、SCE 品質管理部門では安心安全の「品質維持」を目的としていると説明。たとえばデバッグチームの管轄である「品質向上」に該当するような「やり込み要素が少ない」や「グラフィックをもっと良くして」といった修正を SCE の品質管理部門から出すことはないと語り、デバッグチームとの視点の違いを説明しました。
品質とコストのバランスについては、シーソーの図を使って、チェックが厳しすぎれば発売延期やコスト増につながり、ゆるすぎれば品質低下によって市場で問題が起きることを説明。
古川氏はさらに作家と編集者がよく使う指標「期待の地平」を用いて SCE 品質管理部門におけるバランス感覚を解説しました。
 |  |
| バランスが重要 | 意外と安心 |
ここでいう「期待の地平」とは縦軸に「意外性」と「安心感」を据えて、読者が期待する品質はその真ん中 ― つまり期待の地平 ― にあるとする考え方です（意外性を追求しすぎると意味不明に、安心感を追求しすぎるとありきたりになるということ）。この地平は時代によって変化していくもので、プレイステーションの 15 年の歴史の中でもさまざまな変化があったとか。
古川氏は SCE 品質管理部門の「期待の地平」を真ん中周辺の「妥当な領域」と表現します。
たとえば操作説明もなしにユーザーをゲーム世界に放りこむようなシステムではユーザーは意味がわからないと感じるので「意外性」が過剰、逆に何をするにも確認メッセージが出てくるようなシステムではユーザーは「わずらわしい」と感じるので「安全性」が過剰になります。このような例は極端なものでしょうが、「マスターチェック」ではゲーム全体が「妥当な領域」に収まるようにすることが大きな役割だそうです。
また仕様書に沿ってバグを潰すゲームメーカーのデバッグと異なり、「ユーザーのために妥当な領域でのバグをなくす」ことを目的としたマスターチェックでは「妥当な領域以外のことをするのは過剰品質」と述べ、限られた時間のなかで何に注力するのか？を明確に示しました。
初代プレイステーションが発売されて以来、15 年間の歴史を持つ SCE 品質管理部。その当時は手探りで妥当な領域を探すしかなく、ユーザーやゲームメーカーの声に耳を傾けながら「妥当な領域」を見極めてきたそうです。「妥当な領域は時と共に変わっていく」と考える古川氏は、今後も状況に併せて柔軟に対応していきたいと語りました。
 |
| マスターチェックの体制 |
ちなみに、1 タイトルのマスターチェックはスタッフ 3～4 人で受け持ち、期間は 3～4 日ほど。年間 60 タイトルを審査するそうです。これ以上ではコストやリソースを過剰にかけることになるとのこと。また、機械的なチェックやマクロなどは使用しておらず、「全部アナログで対応している」と明かしました。プレイ時間の長い RPG などではゲームメーカーからセーブデータや攻略資料を提供してもらうこともあるそうです。
 |
| 人員の育成 |
短期間で審査するために、ゲーム初見でもしっかりと対応できるよう「さまざまな仕様やバグ例の経験」を積んだスタッフが順応性を発揮して対応しているとのこと。また、時々はバグが見つからないこともあるそうで（それは喜ばしいことであるとしながらも）そういったケースでは「バグが無い不安から覚える危機感」も抱えつつ、緊張感を持って対応していると述べました。
この他にも多様なジャンルのゲームに対応するため、各スタッフのジャンルの得手不得手や品質管理キャリアの短長をフルに活用（詳しくはプレゼンテーションの写真を参照ください）して、それをマネージャがまとめる手法を採用していると紹介。
また、再提出後のマスターチェックでも「多角的な視点」を保つために前回とは違うメンバーを割り当てていることなどを説明。この手法には、他人が出したバグをチェックすることで他メンバーの見地を得て、スタッフの発想力と応用力を育む目的があるそうです。
チーム内の新人教育では、基準書に記載されている「同時押しや連打をしてみる」などの基本的な手法を除けば「ゲーム中にバグを出すコツは教えていない」と明かし、基本的に実務と研修を交互に行なって覚えた事を実践していくことで育成しているそうです。また研修の講師は現場を知っているベテランスタッフが担当するようにしているとのこと。
 |
| デバッグとマスターチェックの違い |
セッションを通じてデバッグとマスターチェックの違いを説明してきた古川氏でしたが、最後にこれを長距離走と短距離走に例えて、具体的な違いを下のように表現しました。
デバッグ
- 長距離ランナー
- 作り上げる心でチェック
- 製作スタッフの一員
- 仕様を熟知している
- 仕様に基づいて想定外操作を試す発想
- メンバーが固定的
- 担当領域を細かく分けて割り当てされる
マスターチェック
- 短距離ランナー
- 疑う心でチェック
- 最終承認に関わるスタッフ
- 仕様は適度に理解している程度
- 妥当領域内での想定外操作（ユーザーがどんなことをするか）を試す発想
- メンバーが流動的
- 担当領域がおおまか
古川氏はこのような違いがあることを述べた上で、デバッグチームの方に向けて「他人のチェックレポートを検証する」、「短期間でローテーションする」、「仕様書なしでチェックする（仕様から離れた発想でチェックする）」ことで、マスターチェックの承認を得やすくなるのではと提案。
最後にゲームメーカーの聴講者に向けて「SCE 品質管理部門の手法を知ることで、ゲームメーカーの皆様がより快適にゲームを開発する一助になれば幸い」と述べ、学生の聴講者には「将来ゲームを作ったら、こういう業務があることを思い出してもらえたら」と語りかけてセッションを締めくくりました。
少人数短期間で一度限りのチェックを実施する SCE 社の品質管理部門。さまざまなキーワードが用いられましたが、根底にあるのは「ユーザーのゲームプレイを最大限快適にするために、手持ちのカードで何ができるか」を突き詰める姿勢ではないでしょうか。
