2020年9月2日～4日の3日間に渡るオンラインでの開催となった、コンピュータエンターテインメント開発者向け大規模カンファレンスCEDEC 2020。
本稿では、3日目となる2020年9月4日（金）に行なわれた、任天堂の和田真樹氏、田邨嘉隆氏、成瀬文覚氏による“『リングフィット アドベンチャー』のハード・ソフト一体型開発～開発サイクルの違いを乗り越える～”の内容をお伝えしていく。
開発に携わる3班の詳細とサイクル
『リングフィット アドベンチャー』は、2019年10月18日に発売されたNintendo Switch用タイトルだ。タイトルに“アドベンチャー”とある通り、冒険をしながらフィットネスを楽しめる内容となっている。
そして本作の最大の特徴にして、本講演の主役となるのが、力（チカラ）で操作するというたいへんユニークな専用コントローラー“リングコン”となる。
リングコンをチカラで操作するうえでの秘密は、ふたつある。ひとつは加えられたチカラで変形し反発するバネだ。これはしっかりとした負荷を筋肉に与えるフィットネス効果も持っている。このバネは金属ではなく、軽くて強度の高い“繊維強化プラスチック”で作られており、リングコン専用に新規開発した特別仕様のものだ。
もうひとつの秘密は、押し込んだり引っ張ったりするチカラを精度よく検知する、チカラセンサーだ。同社の『Wii Fit』で使用された“バランスWiiボード”と同種の、微小な変形も感知するセンサーを、リングコンに最適化したものが積まれている。
本講演では、このリングコンを作るために開発陣が行なった、“ハード・ソフト一体型開発”が主題となった。まずは前半として、リングコン開発の概要についての詳細な解説がされた。
まずは開発体制について解説された。リングコンを開発するにあたり、ひと言で開発とは言っても、開発陣が開発した要素は大きく分けると3つある。材料やどこで組み立てるかなど、物理的な側面の“ハードウェア”と、その物理的なリングコンをただの輪っかで終わらせず、Nintendo Switchで動かせるようにする仕組みとなる“システム”、そしてそのリングコンを使ってユーザーにどう遊んでもらうのか、ユーザー体験を開発する“ゲームソフト”だ。
このハード、システム、ゲームのどのひとつが欠けても、ユーザーにゲーム体験を届けることはできない。この3つの要素をセットにしてユーザーにゲームを届ける方法を、開発陣は“ハード・ソフト一体型開発”と称している。
この3つの要素は、いずれも専門性が非常に高い。これらを担当するそれぞれの専門班（ハード班、システム班、ゲーム班）の協業があってこそ、『リンクフィット アドベンチャー』は完成したのだという。
続いてはこの3班が、具体的にどのような作業を行なうのかについて解説された。のちの開発サイクルの解説にも大きく関わる部分なので、各班の作業内容を大まかに把握しておいてほしい。
ハード班
まずハード班は、物理的な部分、つまりリングコンそのものを作る部分を担当した。その中でも機構設計、回路設計、プロダクトデザインと、3つの担当グループが形成された。
その開発タイムラインには、原理試作、開発試作、量産試作の3つのフェーズに分かれる。
まず原理試作フェーズでどんなボタンが必要なのか、どのようなセンサーや回路を使うか、リングの素材や厚みはどうするかなど、さまざまな試作を繰り返す。なお、この段階で携わるスタッフはごく少数となる。
試行錯誤を経て開発進行が決定すると、つぎの開発試作フェーズに入り、携わる人数も大きく増える。製品の機能やデザインが設計通りに実現できるか、操作感触やセンサーの反応のほか、グリップ部分の固さなどまだ追い込みきれていない部分も追求していく。
このフェーズをより細かに分けると、設計、試作、評価、改善の4つとなる。設計に着手してから試作を終え、評価に移るまでの期間がとくに長くなる。機能ごとに、小試作をくり返す必要があるためだ。
つぎの量産試作フェーズでも、基本的には開発試作と同じ4つの流れを取る。このフェーズでは量産を行なううえで、量産と同じ金型や設備を準備して最終製品と同等のリングコンを作り、製造を担当する協力会社とも連携しつつ、より高品質、かつ生産性に優れた製品を追求していく。
以上、この3つのフェーズを経ることで、量産体制へと入ることができる。段階が進むにつれて製品の仕様が固まり、それに対応した設備や関わる人員の数に加え、費用もどんどん増えていく。万一問題が生じた場合、あとのフェーズであるほど大きな出戻りが生じ、影響は大となる。
今回の開発ではこの出戻りを極力防ぐだめに、原理試作の段階で課題を洗い出して解決し、早期検証を可能とする取り組みがされたという。詳細は講演後半の解説にて。
システム班
システム班が担当した、リングコンをNintendo Switchで使用できるようにする“仕組み”とは、ソフトウェアデベロップメントキット“NintendoSDK”のことだ。これを用いることで、ゲームソフトがハードウェアであるリングコンや、Nintendo Switch本体の機能を使用できるようになる。
このNintendoSDKの種類は多彩で、ハードウェアを動かすシステムソフトウェアや、ゲームを作りやすくするミドルウェアなど、ハードウェア、ソフトウェアのそれぞれに近いものが数多く存在しており、これらは任天堂社内を中心に開発されている。
このSDKの中でも本講演に大きく関わるのは“リングコンファームウェア”、“本体システム”、“リングコンライブラリ”の3つとなる。データはハードウェアであるリングコンに搭載されているファームウェアから、本体システム、リングコンライブラリの順に流れていく。
まずはファームウェアについてだが、リングコンにはマイコン（小型のコンピューター）が搭載されており、リングコンを押し引きしたチカラをセンサーがデジタル値に変換し、マイコンのファームウェアが処理したものが接続されたJoy-Conに渡される。この時点では値はとくに補正されておらず、センサーの“生”の値が流されていく。
なお、このファームウェアのサイズは、数十キロバイトというコンパクトなサイズとなっている。
続いてデータが流れて来る本体システム内には、ふたつのソフトウェアがある。Joy-Con内のマイコンで動くファームウェアと、本体内の高性能コンピューター“SoC”（System-on-a-Chip）で動くオペレーティングシステム“Switch OS”だ。Joy-Conファームウェアはデータを渡すだけの比較的軽いソフトウェアだが、Switch OSはハードの性能を限界まで引き出すべく、数百人規模で開発した任天堂の大規模独自OSとなっている。
このふたつのソフトウェアが何をするのかをリングコンの観点から見ると、センサーからの入力データを“適切に処理”し、ゲーム用に出力することになる。この適切な処理という部分がシステム班の大きな役割であり、今回の開発全体の課題を解決する要のひとつとなった部分でもある。
最後にデータを受け取るのが、リングコンライブラリだ。ライブラリにはさまざまなものがあるが、リングコンライブラリは本体データが処理したデータを取り出し、ゲームへ渡すことを仕事としている。ゲーム側が使いやすくなるように、ここで簡単な加工処理を行なう場合もある。
このように、システム班はリングコンのデータをゲームに届けるまでの、一連のシステム開発を担当している。システム開発においては担当者の成瀬氏は、そのコンセプトとしてふだんから“いかに簡単にゲーム開発に専念してもらえるか”を大事にしているとのことだ。
なお、これらのソフトウェアはNintendoSDKという、ひとつのパッケージでゲーム開発者へとまとめて提供される。その開発にあたっては、さまざまなゲームの開発者やシステム担当者などからリクエストがあり、担当開発者が順次対応する。ただし別のSDKでもSwitch OS上で相互影響を及ぼす可能性があるため、スケジュールを決めてSDKの統合テストが行なわれ、そのあとに利用者へと提供されることになる。
つまり、3班が同時に動いているリングコンの開発ではあるが、システムソフトウェアはSDKリリースサイクルという独自のタイミングで、SDK単位で提供されることになるわけだ。
ゲーム班
ゲーム班はほか2班から提供されるリングコンを使用しつつ、その使用結果を“ユーザー体験”として評価することで、開発に協力する。
たとえば、チカラセンサーの精度が十分かどうかという課題があるとして、その評価基準は実際に遊んだ場合にユーザー体験として十分か、という視点になる。リングコンを評価するためには、実際に使われるゲームを通すことが必須なのだ。
ゲーム班では1ヵ月単位で設定したマイルストーンを1サイクルとして、高速で検証をくり返すという方法でゲーム開発を進めている。 1サイクル内は仕様検討、実装、モニタープレイ、改善点検討の4つのフェーズに分かれている。
まず仕様検討の段階でそのサイクルで何を検証するかを決め、実装の段階でプログラムやリソースを製作し、実装された内容にスタッフがモニタープレイを通じて意見を出し合い、最後に改善点検討フェイズで出された意見を確認する。
この高速検証をゲームの仕様が固まるまでくり返し、そのあとは品質を上げる仕上げ期間となり、最後にデバックをして完成を迎える。
3班のサイクルが異なる問題
ここまで解説された3班の開発サイクルを並べてみると、その違いは明白だ。まず、1サイクルごとの長さがまったく違う。タイミングの面でも、各サイクルの開始・終了タイミングは一致していない。
それぞれの班ごとには都合がいいサイクルでも、3班での協業を考えると連携が取りにくい。具体的にリングコンの開発においても、その問題は浮き彫りとなった。
まず開発全体で、『リングフィット アドベンチャー』をより魅力的なタイトルにするべく協議したところ、本作のある特徴が浮上したという。“運動不足の解消”や“お腹周りに不安がある”など、ユーザーのニーズに幅があるという点だ。
ユーザーごとに求めるフィットネスや、できるフィットネスはさまざまとなる。ここでフィットネスを数多く提供することで、ニーズに応えるとともにより長く飽きずに遊んでもらえるようにするという方針が決定したが、そのためにはフィットネスを高速で増やす方法が必要となる。その検証は、ゲーム班の高速サイクルで行なわれることとなった。
しかしシミュレーションしてみると、大きな問題が立ち塞がってきた。あるフィットネスをゲーム班が検証するとして、まずはリングコンの耐久性の確認が必要となる。耐久性評価はハード班の担当だが、その評価タイミングは試作サイクルの後半にある。
評価で問題がなければゲーム班はそのフィットネスの実装に入れるのだが、それまでに大きな待ち時間が発生してしまうのだ。
また、実装に着手したゲーム班でリングコンの機能不足により、やりたいことができないことが判明した場合、新機能追加をシステム班に依頼することになる。この新機能がゲーム班に届けられるのは、SDKリリースのタイミングになってしまう。
そうしてようやくフィットネスの追加ができたものの、またも待ち時間が発生し、高速でフィットネスを追加することは不可能となってしまった。これを改善し、ゲーム班の高速サイクルに合わせて実現するのは、だれが見ても非常に困難と判断できるだろう。
これを実現するためには、開発サイクルの違いをなんとしても乗り越えなくてはならないのだ。
サイクルの違いを乗り越えた開発事例
ここから講演は後半に入り、あまりに難解に見える3班開発サイクルの問題を実際にどう乗り越えたのか、その具体的な事例が紹介された。
耐久性評価の解決
ハード班は、安全・安心な製品を制作することを第一としているとのこと。製品が壊れて怪我をしたりすることがないようにするのはもちろんのこと、ユーザーに満足してもらえるだけの耐久性も重視している。
チカラで操作し、大きく変形するこれまでにないコントローラーを作るにあたり、はじめはゲーム内での使いかたさえ未知数だった。つまり、耐久性においては使いかたも考慮して判断する必要があったのだ。その評価をするにあたり、ハードとゲームの開発サイクルの違いが大きな課題となった。
先述の通り、通常のサイクルではゲーム班に大きな待ち時間が生じてしまう。そこでハード班だけでなく、ゲーム班も巻き込んで検討した結果、リングコンの“耐久値”とゲーム内での使いかたによる“要求値”を、それぞれ数値化すれば解決できるという結論に至った。
この耐久値と要求値を分かりやすく言いかえると、耐久値が“HP”、要求値が“ダメージ”のようなものということになる。このふたつが数値化できれば、HPがダメージを上回っているかどうかで耐久性評価が高速でできるようになるのだ。
このふたつをどのように数値化したのか、具体的なアプローチも紹介された。HPについては全力の押し引きに耐えられる回数と定義し、押し引き試験機を複数準備して検証した。これでHPが具体的な数値となるだけでなく、ゲーム内でのさまざまな使用法に対応した部品単位の小試作においても、HPの数値化により設計・製造方法の改良効果が一目で分かるようになった。
さらにもっともHPが多い仕様がどれか、フェーズごとに確認できるようになったため、ゲーム班に配布するリングコンの制作においても大きく参考になったという。
つぎにダメージの数値化については、使いかたでダメージに差が出ることを考慮し、モニタープレイで収集したプレイログから統計的に分析できないかと考えられた。そのためにはプレイログを収集する仕組みが必要だ。
そこでハード班がゲーム班に相談したところ、モニタープレイ時だけでなく全開発者からつねにデータを収集できるシステムを整えることとなった。耐久性評価というハード班の課題に、班の垣根を超え、ゲーム班と協業で取り組むことになったのだ。
こうして自動収集したログをどのように活用したか、ふたつの実例が提示された。まずはフィットネス“大胸筋チャレンジ”を実装するにあたり、試作版ROMのログを分析した実例だ。
ゲーム開始時の両手がくっつくまでの全力の押し込みを100％として、押し込みをくり返すと疲れにより、その％は下がっていく。これをヒストグラム化すると、何％で何回の押し込みがあったのかが分かる。
押し込み量ごとのダメージを算出するには、定量化する必要がある。そのために押し込み試験機をここでも使用し、100％で押し込んだ場合の耐久回数をまず基準とする。そして90％で耐久試験をした結果、耐久回数は100％の1.36倍となったため、90％時の相対的なダメージ量は0.734となった。
同様に％を下げていくことで、押し込み量に対するダメージ量を％ごとに定量化することができる。そして押し込み量ごとの回数とダメージ量を掛け合わせることで、ダメージ小計を算出する。これらを合算すると、“大胸筋チャレンジ”を1回プレイした際のダメージ合計は23.63となった。
これで“大胸筋チャレンジ”を何回プレイしたらどれだけのダメージが入るのか、簡単に計算できる。たとえば100回プレイすれば、リングコンに入るダメージは2363となる。その結果、ハード班はHPに与える影響は小さいと判断でき、ゲームへのフィットネスの正式採用が素早く決定できた。
続いて第2の実例は、ゲームパラメーターの調整にまつわる事例だ。ゲーム班からより運動負荷がかかるキツい設定にしたいという提案があった際に、全開発者のプレイログをハード班とともに確かめることになった。
運動負荷を強くするということは、リングコンに入るダメージも増えるということだ。そして好みのフィットネスや遊びかたは、人それぞれとなる。そこで海外のスタッフも含めた、全開発者の膨大なプレイログから統計分析し、ゲームをクリアーするまでにどれだけのダメージが入るかを推定した。
リングコンの開発を継続するなかでHPが大きく増えていたこともあり、ゲームクリアーまでのダメージを鑑みても、負荷を増す余裕は十分にあると考えられた。結果、ハード班から大丈夫との判断がされ、ゲーム班が調整を実装した。
耐久性についてまとめると、安全・安心な製品を作るというハード班の試みによって増えたリングコンのHPが、使いかた、遊びの幅を増やしていくゲーム班によって増えていくダメージの総量を常に上回っていることを確認するための、新しい仕組みが作り出されたということになる。
この実現は、1班だけではできなかった。ハード班の評価技術と、ゲーム班のロギング技術を組み合わせ、いっしょにモニター検証を行なう必要があったのだ。
それぞれの班の課題も自分の班の課題ととらえ、お互いの領域に踏み込み合うことで、この課題は解決した。
耐久性を即座に評価できるシステムができあがったことで、ゲーム班はすぐにゲーム実装に取り掛かれるようになった。これでフットネスを高速で実装できるようになればよかったのだが、ここでもうひとつの課題が立ち塞がる。
新たなフィットネスに新機能が必要になった場合、ゲーム班がそれを使えるようになるのは、システム班のSDKリリースタイミングを待たねばならない。この問題がどう解決されたのかも、引き続き解説された。
システム開発の解決
システム班の成瀬氏いわく、SDK開発者として氏がつねに優先しているのは、“開発者にゲームづくりに集中してもらう”ことであるという。これを実現するために、SDKの機能が分かりやすく容易でゲーム側に余計な処理をさせないこと、各ゲームで同じ処理をしないように共通機能をシステムに集約すること、統合テストを通してさまざまな使いかたで安定して動作する堅牢性と、3つの要素を重視しているという。
リングコン開発においてもはじめはこの3つを重視していたとのことだが、これらに固執していては、開発サイクルの違いは乗り越えられなかったという。
システム班が“データ取得”のためのリングコンファームウェア、適切な処理での“変換”のための本体システム、ゲームへの“伝達”のためのリングコンライブラリという3つのソフトウェアを制作するにあたり、開発者が開発を終えてもSDKリリース待ちの状態に入ってしまうため、ゲーム班に提供するのがどうしても遅れてしまう。これは統合テストなどにより堅牢性を確保するため、必要な過程なのだ。
リングコン開発で求められるのは、リングコンを用いたさまざまなフィットネスのためのシステムだ。リングコンがどんな使いかたをされるか、システムの開発当初は決まっていなかったため、システム班には高速サイクルのための即対応・即提供が求められることになった。
そのためにはやはり、SDKリリース待ちを経ずにゲーム班へ提供できる仕組みが求められる。3つのソフトウェアを、SDKに依存せずに提供するための試みが始まった。
まずはリングコンファームウェアを、Joy-Conのファームウェアを本体経由でアップデートするシステムを流用して更新する方法が検討されたが、結局はSDKパッケージに内包する必要があったためNGとなった。
つぎにSwitch上で動くアプリケーションとして、更新ツールを提供する方法が検討された。この方法はSDKリリースサイクルからの脱却に成功したものの、ツール使用者からは自分が更新する必要があるのか、以前のROMを使いたい場合のファームウェアへの更新ツールがどれだったかなど、質問が多く寄せられた。膨大な人数に及ぶ開発者が、全員リングコンの仕様を熟知しているわけではなかったためだ。これは手軽ではなく、開発者に集中してもらえる方法ではない。
システム班だけでは、用意できるものに限界がある。そこでゲーム班に相談したところ、システム班が保有している更新用のライブラリを使えば、ゲーム班側でデバッグメニューにファームウェア変更のシステムを半日で追加できると提案されたという。
最初から相談していればよかったのでは、と思われる人もいるかも知れないが、システム班はゲーム班に気を遣っており、負担をかけない方法をつねに模索していた。しかしそれでは、リングコン開発の全体のためにはならなかったのだ。
結果、先のアプリケーション案で用意されていた更新ツールに含まれる更新用ライブラリとファームウェアを、ゲームそのものに組み込むことで、デバックメニューから直接更新する即提供が可能となった。SDKリリースサイクルを待たずに済むだけでなく、導入コストの低下、バージョン管理の簡易化も実現できたのだ。
手間をかけさせないという気遣いにとらわれず、開発チーム全体でベストな方法を模索した方が全体の手間が軽減されることもあると、システム班は大いに学んだという。
続いて本体システムについては、“適切な処理”でデータを変換し、ゲーム開発者が楽できるようになるという役目についてが重要となった。多くの開発者から要求が続くため、適切な処理はつねに変わり続けてしまうのだ。
しかしSDKリリースサイクルの関係上、各開発者の要求に即対応することはできない。どうすれば即提供できるようにするのか、非常に難しい課題だったという。
ここで先例となる、リングコンファームウェアの際の考えかたがまた解決策を導いてくれた。開発チーム全体のために本体システムをどうすればいいのか考えた結果、システムを“土管”にすればいいという結論が出たという。
土管とはいったいどういうことか。つまり、リングコンから送られてきたデータをそのまま素通りさせ、リングコンライブラリへと届けるということだ。
具体的には、これまでは本体システムが担っていた“変換”の役割をリングコンライブラリに移し、コントローラーとの接続・通信のみを本体で処理するように変更した。
この変更により、本体システムでゲームに影響する部分はすべてライブラリへと移転した。つまり、本体システムにリングコンを使った“ゲームに影響する”コードはゼロとなった。システム班では本体システムについては、接続処理部分のみを独立して作ることとなる。
本体システムに特別な機能を付与しないことにより、本体システムと『リングフィット アドベンチャー』の依存を切り離したことは、機能の集約や汎用性を捨てたとしても、開発全体の易になると判断したわけだ。
では、その機能を預けられたライブラリについてはどうなったのか。そもそもNintendo SDKにおけるライブラリとは、Switch OSの機能をゲーム側から使用する入り口となるソフトウェアだ。これらは使いかたと呼び出しかたをまとめた“ヘッダーファイル”と、ゲームに組み込むライブラリの本体となる"バイナリファイル"で構成されており、任天堂社内ではすべて同一の形式でリリースされる。
では、これをSDKリリースサイクルを待たず即提供するにはどうすればいいのか。これはじつは簡単で、ソースコードで提供し、ゲーム内でビルドしてもらえばいいのだ。これでライブラリを即提供、即更新することが可能となる。
この方法を最初から簡単に行なえないのには理由がある。ライブラリは実装を隠蔽し、容易に使えて堅牢にするために、内部でさまざまなことを保証している。具体的にシステム班がゲーム班に提供するなら、ハードウェアごとの微妙な違いへの対応、Nintendo Switchの本体更新後の動作保証、線形に変化しないセンサー値の補正やセンサーの値のノイズ除去といった点を保証したものを提供する。
リングコン開発の事例では、即提供のためにソースコードを公開した。その提供にあたり、システム班は方針も変更したという。
ふだんはシステム班がライブラリ内で隠蔽している、容易に使えて堅牢に作るためのさまざまな取り組みを、ゲーム開発者側にも理解してもらうことにしたのだ。
こうしてハード班も加え、3班でリングコンライブラリを制作することになった。ふだんは他班の手間を減らすために、システム班だけで隠蔽された堅牢なライブラリを作るところを、ゲームに合ったライブラリを即時作るため、3班でコードを見ながら作ることになったのだ。
この体制では、ゲーム班が提案する実現したいことを、ライブラリの安全面からシステム班が、センサーの特性面などからハード班がサポートしていく形になる。逆にシステム班とハード班からも、ゲーム内容について提案することで、お互いの領域に踏み込みつつ、『リングフィット アドベンチャー』全体のことだけを考え、限界まで追い込んだライブラリを制作できた。
こうしてリングコンライブラリの問題も解決し、ゲーム班への機能リリースはすべてにおいて即対応が可能となったのだ。
ライブラリの容易に使えて堅牢という部分を捨てつつも、3班が内部を理解し、限界を攻められるという利点もまた生まれた。
このように、開発サイクルによって生まれる待ち時間をなくす即提供のシステムの模索は、最終的には3班による作業へと発展した。前述されていたゲームづくりに集中してもらうための3つの大事なことに固執せず、『リングフィット アドベンチャー』チームの一員として、3班でお互いの領域に踏み込み合うことで、さまざまな課題の解決が実現していったのだ。
この3班が“踏み込み合う”ことでの成功事例も紹介された。“ろくろ回し”というミニゲームにおいて、センサーの値をより細かく使いたいという要望が出た際の事例だ。
通常なら、どんな人がどのようにプレイしても対応できる限界値として、「センサーの限界はこれです」という回答が出て終わってしまう。しかし今回の3班では、お互いにどんなゲーム内容なのかを理解し合い、ろくろ回しというゲーム内容であれば通常よりも細かくセンサーの値を取り扱っても問題ない、という結論が導き出せた。
限界の先へ。協業の要は“踏み込み合う”こと
こうしてリアルタイムの耐久性評価と、即提供のシステムというふたつの改善により、高速でフィットネスを追加できる環境が整い、『リングフィット アドベンチャー』では結果として、60種類以上の十分な数のフィットネスが追加できた。
当初の目標通り、より多くのユーザーのニーズに応えられただけでなく、この改善は副次的な効果も生み出した。耐久性が可視化したことでリングコンを思い切り使用できたのに加え、チカラセンサーの値をゲーム班が直接触れるようになり、ハードの仕様を把握したうえでより細かな調整ができるようになった。
これでもう、やるべきことはすべてやったかに思えたが、それでも開発チームは「まだ追い込みが足りない」と思ったという。『リングフィット アドベンチャー』をより魅力的な商品にするために、まだできることはないだろうか、と。
そんな最後のひと押しで生まれたのが、Nintendo Switchを起動していないあいだにもJoy-Conとリングコンのみでフィットネスができ、次回の本体起動時にゲーム内ボーナスを受け取れるという“ながらモード”だ。
最後のひと押しということで、その開発スケジュールは非常にタイトなものになったという。
コントローラーのみで動くということは、各コントローラーのファームウェアの手直しが必要になる。システム班は、システム班だけでは開発できるものには限界があると結論付けた。スケジュール的な問題だけでなく、ユーザーの手ごたえの検証や、保証された耐久性の中で新機能を追加できるのかが不安だったのだという。
この段階では開発チーム全体が、お互いに踏み込み合うことを学んでいた状態だ。システム班はすぐに、ほかの2班に相談した。結果、マスターアップ直前、ハード量産直前の忙しい時期ではあったが、各班ともに得意分野は任せてほしいと、3班での協業が始められた。
そうなると、限られた時間内でのながらモードの実装への課題もまた、今回の講演で取り扱った“高速サイクルでの検証”となる。それに先立って、リングコンとJoy-Conのどちらのファームウェアに機能を追加するかというターニングポイントもあった。
リングコンファームウェアは押し引きの判断に最低限必要なスペックのため処理性能やサイズ面で劣るが、『リングフィット アドベンチャー』専用なだけあって、すでに確立していたリリース方法やほかタイトルへの影響範囲といった面からの自由度は高い。Joy-Conファームウェアは、さまざまなことを行なう汎用性を持つためスペックは高いが、リリース方法を新たに検討する必要性（そのままではSDKリリースサイクルに含まれてしまう）や、影響範囲の観点から見ると自由度は低い。
結果として、作りやすさよりも依存を切って独立性を上げ、3班での協業体制を築くために、リングコンファームウェアへの実装が採用された。高スペックの方が開発は楽となるが、依存を切って3班協業を実現することを優先したわけだ。
こうしてながらモードにおいても、ゲーム班が触り心地を検証し、システム班が最適化し、ハード班が耐久性評価をするという高速サイクルが可能となった。このサイクルがもっとも役立ったのが、ながらモードの一日上限回数を“500回”と決めた際だったという。この回数は少なすぎると物足りなくなり、多すぎると最大ボーナスを獲得できるまでが遠くなってしまうわけだ。
まずゲーム班が、どれくらいの回数なら手応えと楽しさがあるかを検討する。続いてハード班が、ながらモードの分のダメージが加わっても耐久性に問題がないか、モニター検証で確認した。
そうして決まった回数を実現するため、システム班がどこまでの押し込みを1回とカウントするかの検討や、よりユーザーに自然と楽しんでもらえるようなプログラムの最適化を進めた。
この回数設定の事例だけを見ても、お互いに踏み込み合い、限界を突き詰めたことが見て取れる。結果、『リングフィット アドベンチャー』とリングコンは、自信をもって世に送り出せる商品に仕上がった。
ふだんの開発サイクルとはまったく異なる、耐久性評価と即提供システムの実現。それに必要だったのは、お互いの領域に踏み込めるチームの関係だった。『リングフィット アドベンチャー』開発チームは、これができるチームは最高のパフォーマンスを発揮できると実感したという。
読者の皆さんの中でも、違う職種の人が自分の領域に「ここはこうした方がいいじゃないですか？」などと踏み込んできた経験がある人は多いのではないだろうか。
講演では最後に、そうした場面で「担当外なのに」と思うのはもったいなく、それは皆さんのチームがより強くなるきっかけのサインなのではないか、との考えが述べられた。協業が身近な皆さんには、ぜひ今回挙げられたいくつもの成功事例を参考にしていただきたい。
※記事内の画像は、配信画面をキャプチャーしたものとなります。
