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