「デバックは最後にやる」という一般論ではなく、「序盤からデバックをやる」というプロセスが意味する、モノ作りの3つのポイントは新規事業開発にも活かせそうだ。
定期的に読み返す「「ゼルダの伝説 BotW」にバグが少ない理由」という記事。読み返す度に気づきがある。私も何度かnoteに書いた。今回で3回目だと思う。(多分)
これはゲーム開発者向け技術交流会CEDEC 2017にて、任天堂の丸子良太氏と大礒琢磨氏が「『ゼルダの伝説 ブレス オブ ザ ワイルド』におけるQA~ゲームの面白さを最大化するツールやデバッグの紹介」という講演の内容を記事にしたものです。
「ゼルダの伝説 BotW」にバグが少ない理由
ゼルダの当たり前を徹底的に見直したQAエンジニア
ゲーム開発に限らず、QA作業はだいたい終盤に行われる事が多い。私も何らかのサービスを開発するときにQAは終盤に設定する。だから「デバックは最後にやる」という一般論ではなく、「序盤からデバックをやる」という発想は、まさに目から鱗が落ちる発想なのだ。
ポイントは3つ
1. 「バグだから後回し」という考え方を避ける
バグとタスクの管理ツールを統合し、「バグだから後回し」という考え方を避け、すべてのバグを序盤から報告して優先順位をつける。
2.「投稿」を押すだけでバグ報告
ゲーム内でバグを検知する仕組み「ZELDA_ERROR」を導入。気づいた時点で「投稿」を押すだけでバグ報告ができる。
3.「報告するだけ」でいいフロー
通常「バグ」を発見してしまったら、最後までそのバグが修正されたか?の確認をしないといけない。これを確認をしなくてもよい。フローの確立。
新規事業開発への応用
この3つのポイントは通常の新規事業開発でも活かせそうだ。例えば新規事業を行うとき、何か違和感があっても中々言えない人って結構居ると思う。
例えば
・違和感があっても「後でいいや」、次の定例会で話そう。
・何か言ったら色々問い詰められそうで面倒だ。
・意見をいったら、それについて何度も話に巻き込まれるのは面倒だ。
とかね。
誰でも「違和感」を報告できる仕組み、これは深掘りしていきたい内容だ。
---
Photo by Aleks Dorohovich on Unsplash
アレとソレを組合せてみたらコノ課題を解決できるソリューションができるよね?と言うパズルをやるような思考回路です。サポートして頂いた費用は、プロジェクト関連の書籍購入やセミナー参加の資金にします。