肩の力を抜いて

Relax and Enjoy Programming

肩の力を抜いて楽しむ。楽しみながらラクして成果を上げる仕組みを考える。

ゼルダ開発者に学ぶチーム全体の生産性を上げる方法

こんにちは!
タダケン(@tadaken3)です。

日本最大のゲーム開発者向けカンファレンス「CEDEC 2017」が9月1日まで行われていました。ボクの好きなゲームの一つ「ゼルダの伝説 ブレス オブ ザ ワイルド」(以下、BotW)についても多くセッションが開かれてました。

今回はBotWのセッションを読んで学んだこと、感じたことをまとめてみました。

自作のバグ検知ツール「ZELDA_ERROR」で制作効率が上がった

たくさんのセッションが公開されたのですが、個人的に注目したのがこちらの記事です。

jp.ign.com

簡単にまとめると、

BotWは任天堂の歴史の中でも今までにない規模の制作規模だったそうです。制作規模が大きいため、バグも大量に発生し、面白さを検証するためのテストプレイもままならない状態でした。

QAエンジニアである大礒さんが、BotW専用のデバッグツール「ZELDA_ERROR」を作って、効率的にバグ報告をできるようにしました。

通常、ゲームのソフトの開発は制作の終盤にデバックを行なうのですが、「ZELDA_ERROR」のおかげ開発の初期からデバックを効率的に行なうことができ、その効果も制作サイクルを早く回せました。

という内容です。

道具を作ってチームの力を最大限に活かす

ボク自身もBotWは100時間以上遊びましたし、いち任天堂ファンとして、開発の裏側の話を知って単純にすごいなと思いました。

※我が家のニンテンドースイッチ

「ZELDA_ERROR」の記事を読んで一つ思い出したことがあります。

任天堂の元社長、故・岩田さんとほぼ日の糸井さんのとある対談記事です。

当時ふたりは「MOTHER2 ギーグの逆襲」というスーパーファミコンのソフトの開発を行っていました。

開発は難航し4年間たっても完成の目処が見えない状態でした。あまりにも開発が難航したため岩田さんが助っ人として、開発陣に加わったときのエピソードです。

当時の状況を二人はこのように振り返っています。

糸井
あー、もっともですね(笑)。
で、そのときに岩田さんが
なにからはじめたかというと、
まず、道具をつくりはじめたんですよね。
つまり、目の前に大きな問題がごろごろあって、
すごくたいへんだぞ、というときに、
直接は、それに取りかからなかった。
だから、離れたところから見ると、
ぜんぜん手をつけてないように見えたんです。
ところが、それは、問題を片づけていくための
道具をつくっていたんだよね

岩田
はい。

糸井
(まわりのスタッフに向かって)
おもしろいんだよ、これは。
問題を1個ずつ片づけていくかというと
そうじゃないんだ。
いったん、道具をつくっておいて、
「みんなが使える道具をつくりましたから、
これで、あなたはここをつくってください」
というふうに建て直していったんだ。
つまり、道具さえできたら、
あとはやるだけなんですっていう
やり方をしていましたよね。
HOBO NIKKAN ITOI SHINBUN - 1101.com

このとき、岩田さんが具体的に作った「道具」は、当日まだ珍しかった電子メールだそうです。システムを社員一人ひとりのPCに入れさせて、コミュニケーションを円滑化しました。

開発がうまくいってない原因として、コミュニケーションがうまくいっていないと分析したんでしょうね。今でこそメールなんか当たり前ですが、1990年代の話ですから驚きです。

他にも岩田さんは、ファイルの更新状況を管理するために、バージョン管理システムを構築して、MOTHER2の開発効率を劇的に改善しています。1

岩田さんは、いきなりソフトの開発に入らず、みんなが使えるツールを作って、チーム全体の生産性をアップしました。

結果4年間も開発が難航していたMOTHER2が、岩田さんが開発に入ってから1年で発売までこぎつけました。

任天堂の大磯さんがおこなった「ZELDA_ERROR」を作って、チームの開発力を底上げするというのも、岩田さんのやり方そのままです。

岩田さんのDNAはしっかりと任天堂の開発陣に受け継がれているんだなと感じました。

目の前の問題にすぐ取り掛かる前に

とくに忙しくて切羽詰まっているときほど、目の前の問題をすぐに解決しようと手を動かしがちです。

ボクなんかもタスクがたくさんあって消化できるかわからないときほど、不安になってすぐに目の前の課題から手を付けがちでした。

ですが、むかしに岩田さんのツールを作る方法を知ってから、

  • もしまた同じような問題が起きたらまた時間がかかってしまうのではないだろうか
  • そもそも何が本当に問題なのだろうか

ということを一度立ち止まって考えるようになりました。

そして、自分でも自動化したりツールを作ってみたいと思いプログラミングを学び始めました。

プログラミングを少しずつ学んで行く過程で、ちょっとずつ自分の業務を自動化していきました。

時にはそれをチームに公開して他の人も使えるようにしてきました。

もちろん岩田さんや大礒さんのようなすごいツールではありませんし、日々の問題を解決する本当にちょっとしたプログラムだったりします。

それでも、作ったツールが増えれば増えるほど、仕事はどんどん自動化され、楽になっていきました。

まとめ

みんなが使えるツールを作って、チーム全体の生産性をアップするメソッドは、チームで仕事をすすめていく上で非常に役に立つ考え方です。

プログラミングの強みは、ツールを自分で創ってしまえるところだと再認識しました。

プログラミングを学んで、個人の生産性だけでなく、チームの生産性をアップしていけるといいですね。

読者登録をお願いします

本ブログではプログラミングについての記事を公開しています。よろしければ読者登録もしくはTwitterアカウントのフォローをしていただけると更新の励みになります。ぜひ一緒にプログラミングを学びましょう。