見出し画像

「デバックは最後にやる」という一般論ではなく、「序盤からデバックをやる」というプロセスが意味する、モノ作りの3つのポイントは新規事業開発にも活かせそうだ。

定期的に読み返す「「ゼルダの伝説 BotW」にバグが少ない理由」という記事。読み返す度に気づきがある。私も何度かnoteに書いた。今回で3回目だと思う。(多分)

これはゲーム開発者向け技術交流会CEDEC 2017にて、任天堂の丸子良太氏と大礒琢磨氏が「『ゼルダの伝説 ブレス オブ ザ ワイルド』におけるQA~ゲームの面白さを最大化するツールやデバッグの紹介」という講演の内容を記事にしたものです。

「ゼルダの伝説 BotW」にバグが少ない理由

ゼルダの当たり前を徹底的に見直したQAエンジニア


ゲーム開発に限らず、QA作業はだいたい終盤に行われる事が多い。私も何らかのサービスを開発するときにQAは終盤に設定する。だから「デバックは最後にやる」という一般論ではなく、「序盤からデバックをやる」という発想は、まさに目から鱗が落ちる発想なのだ。

ポイントは3つ

1. 「バグだから後回し」という考え方を避ける

バグとタスクの管理ツールを統合し、「バグだから後回し」という考え方を避け、すべてのバグを序盤から報告して優先順位をつける。

2.「投稿」を押すだけでバグ報告

ゲーム内でバグを検知する仕組み「ZELDA_ERROR」を導入。気づいた時点で「投稿」を押すだけでバグ報告ができる。

3.「報告するだけ」でいいフロー

通常「バグ」を発見してしまったら、最後までそのバグが修正されたか?の確認をしないといけない。これを確認をしなくてもよい。フローの確立。


新規事業開発への応用

この3つのポイントは通常の新規事業開発でも活かせそうだ。例えば新規事業を行うとき、何か違和感があっても中々言えない人って結構居ると思う。

例えば
・違和感があっても「後でいいや」、次の定例会で話そう。
・何か言ったら色々問い詰められそうで面倒だ。
・意見をいったら、それについて何度も話に巻き込まれるのは面倒だ。
とかね。

誰でも「違和感」を報告できる仕組み、これは深掘りしていきたい内容だ。

---

Photo by Aleks Dorohovich on Unsplash



アレとソレを組合せてみたらコノ課題を解決できるソリューションができるよね?と言うパズルをやるような思考回路です。サポートして頂いた費用は、プロジェクト関連の書籍購入やセミナー参加の資金にします。