プログラミング

2026.04.07

フランクにやり取りできる現場

モノリスソフトのプログラマーは、本作の開発にどのような形で携わったのでしょうか？

Y.T. ゲーム開発におけるプログラマーの仕事には、
物理法則やグラフィック表現といったゲーム全体の基盤となる仕組みを作る領域と、
その仕組みを操って遊びを実装する領域があるのですが、
モノリスソフトのプログラマーは後者を担当し、任天堂と一緒に遊びを実装しました。

以前公開された対談では、モノリスソフトのプログラマーは、
『ブレス オブ ザ ワイルド^※』のダウンロードコンテンツから
「ゼルダ」シリーズの開発に参加したと聞きました。 ※『ゼルダの伝説 ブレス オブ ザ ワイルド』。モノリスソフトが部分受託開発を行った。『ゼルダの伝説 ティアーズ オブ ザ キングダム』の前作にあたる。

Y.T. はい。 本作では、モノリスソフトもより深く開発に携わるために、
ダウンロードコンテンツの時よりも人数規模が大きくなりました。

M.K. 私も本作から「ゼルダ」開発に加わったメンバーの一人です。

参加当初、チームの雰囲気にはどのような印象を持ちましたか？

M.K. コミュニケーションのハードルを感じさせないフランクな雰囲気が印象的でした。

例えば、何か分からないことがある時には、チーム全体が見ているチャットルームに、
「どなたか分かります？」と投げかければ、誰かしらが答えてくれるんです。

それはとてもフランクですね。途中からの参加でも、最初からそういう雰囲気に入っていけたのでしょうか？

M.K. そこは実は、「誰に聞けばいいのか分からなくても、まず聞いてみてOK」
というチームの指針があったんです。
そういう指針があって、実際にそういうやり取りを目にすることで、
「これぐらいフランクでいいんだ」と安心することができました。

チーム内のあちこちにそういう指針があって、
どういう考え方でどう振る舞えばいいのかが分かりやすかったので
雰囲気に馴染むのに時間は掛かりませんでした。

H.N. 開発中は節目ごとに、プログラマー全員で集まって振り返り会を行っていたのですが、
そこでも、小さな指針がたくさん生まれました。
ちょっとした「迷いどころ」や「お見合いしがちなところ」をお互いに出し合って、
「そういう時はこう振る舞いましょう」と認識を揃えていましたね。

なるほど。「フランクにコミュニケーションを取りましょう」というだけでなく、もう一歩踏み込んで、問題になりがちな状況の対応法も言語化されていたのですね。

Y.T. そうですね。
些細なことでも、「そういう時もあるよね」「そのぐらいは仕方ないね」と流さずに
意見を交わしながら改善するやり取りは、開発の最後まで続きましたね。

「生き物らしさ」と
「機能性」のバランス

開発中は他のセクションともやり取りがあったかと思いますが、いかがでしょうか？

Y.T. プログラマー間と同じように、他のセクションとも密にやり取りしました。
一つのコンテンツが完成するまでに、とにかくいろんな人と話しましたね。

例えば、私が挙動のプログラムを担当した中にチューリという賢者がいるのですが、
このキャラクターは鳥なので、飛びながらリンクに付いてくるんです。
実装を進めていると、もっと鳥らしくしようと大らかに飛ばしたくなるんですが、
いざプレイヤーがチューリの力を借りたい時に、近くにいないと困ってしまいます。
かといって、常にリンクの後ろに張り付かせると、
ドローンのような機械的な動きになり、生き物らしくなくなってしまいます。

生き物らしい動きの表現と、遊び応えにつながる機能性、どちらも必要だったのですね。

Y.T. そうなんです。
任天堂とちょうどいい塩梅の表現を探り続けながら、
どんなシチュエーションでも快適に遊べるよう、
洞窟やダンジョンの中ではどうするか、ボス戦の時はどうするか、
他の遊びや他の賢者と絡んだ時はどうするか・・・など、
関係する方と丁寧に対話を重ねて完成したキャラクターでした。

H.N. どんなシチュエーションでもちゃんと遊べるようにするのは、
賢者に限らず、どのアクションやアイテムでも同じでした。
そのため、一人のプログラマーが関わる範囲がとても広く、
一つの遊びを磨き上げる間にも、たくさんの人との連携がありました。

一緒に粘る

多くの人と対話しながら開発を進める中で、変化や気付きはあったでしょうか？

M.K. 私としては、プランナーやデザイナーのアイデアを
ゲームとして正しく動作するように組み込むことがプログラマーの本分である、
という意識が強かったのですが、
それだけではなくて、「どうやったら面白さを実現できるか」を
みんなと一緒に考えることをより強く意識するようになりました。

例えば「ボール運び」というミニチャレンジは、
「ボールを遠くまで運べ」というシンプルな遊びなのですが、
どうやって運ぶかは、プレイヤーの発想に委ねられています。

どこまで運べるか、いろいろな手段を試してみたくなりそうですね。

M.K. まさにそれなんです。
そして、実際に思い付いた手段を試せるのが本作の面白さなんですね。
ただ、「どこまでも運べる」「どんな手段でも運べる」というような制限のない仕組みは、どこでどんな不具合が出るか予測が難しくてリスクが大きいので、
以前の私であれば、アイデアを聞いた段階で「それは難しい」と
反応していたと思うんです。

Y.T. プランナーやデザイナーのアイデアを聞いた時に、
リスクを想像するのは、プログラマーとしては自然なことではありますよね。

M.K. はい。でも、そこでプログラマーが最初から慎重になってしまうと、
遊びを変える話に繋がりやすくなるんですよね。
「遠くまで運ぶとリスクがあるなら、決まった距離を運ぶタイムアタックにしようか」というように。

H.N. 最初に実現したかった面白さから、ちょっと変わっちゃってるんだけど、
「リスクは回避できるし、ボールを運ぶのは変わっていないし、解決！」
と、納得してしまうケースは結構起こりがちかもしれませんね。

M.K. もちろん、本当にできないことや確実にリスクを回避すべき局面もありますが、
プログラマー全員で知恵を出し合えば何とかなる、と体感してからは、
まずは、最初にみんなが「面白い」と感じたアイデアをどうやったら実現できるかを、
とことんチャレンジしてみようと思うようになりました。

H.N. アイデアを実現するのも、リスクを回避するのも、
とにかく、みんなで粘るチームでしたよね。

M.K. はい。
目指す面白さがブレないように、
「どうやったら実現できるか」をみんなで粘り強くチャレンジする姿勢は、
任天堂と仕事をする中で大きく感化された部分です。

スピード感のある試行錯誤

作りたい遊びを実現するために、全員で解決策を考えていくのですね。作り始める前に綿密に相談して、詳細な仕様を固めていたのでしょうか？

H.N. いえ、やっぱり、やってみないと分からないことの方が多いですし、
作りながら相談していましたね。
「すぐ作ってみる」というスピード感は常に大事にしていました。

Y.T. 最低限必要な要素をサッと作ってみたら、
みんなで集まってやりたい面白さが実現できているか確認して、
より良くする方法を相談して、また作って・・・の繰り返しでしたね。

H.N. 私は敵キャラクターの中でボスも担当させてもらったのですが、
ボスとの戦いは、ストーリーにも深く関わってきますし、
そこへ至るまでに手にしたものやプレイヤーの経験値を駆使する遊びになっています。
つまり、関連する要素がとても多いのですが、
どのセクションも試行錯誤を繰り返しているので、
いろいろな要素がちょっとずつ変わっていくんですよね。
当然、それに合わせて、ボスとの戦いも少しずつ変わっていきました。

逆も然りで、私が作っているものが周りにも影響するので、
どんなことをやろうとしているかを、チーム全体に早く共有する意味でも、
スピード感は大事でした。

M.K. 各所の試行錯誤の結果が相互に作用していましたね。
チームのどこでどんなことを試していて、何が起きているのか、
何が決まりそうで、何が変わりそうか・・・
そういった情報に対する感度は、全員が常に高く保っていましたね。

H.N. プログラマー同士は当然、担当範囲以外のプランナーやデザイナーとも、
情報交換していましたし、そういう情報をキャッチできる制作環境でもありました。
そういった感度を高めることで、自分がやるべきことが明確に絞れて、
スピード感のある、効果的な試行錯誤ができるようになったと思います。

チーム全体で、お互いの状況を把握し合っているからこそ可能なスピード感なのですね。

タフなチームを目指して

最後に、今後のプログラマー班の目標を教えてください。

Y.T. 本作の開発を経て、遊びに対する向き合い方、
プログラマーとして面白さに貢献できるアプローチの仕方など、
多くの貴重な経験を積むことができました。

プログラマーはチームの規模をもっと大きくしていく事が目標ですが、
新しく入られる方にも得た経験を余すところなく伝えて、
どんなアイデアにも応えられる、タフなチームを目指したいです。

本日はどうもありがとうございました。