プロジェクトの技術的な目標を増やすとブレるので絞るのも大事【ゲーム開発】

なにかを行うときには目標は設定しておくべきで、ゲーム作りにおいても目標は大切です。

特に技術的な観点からの目標として、今作っているゲームではEventSystemsを使ったメッセージングをマスターしよう、とか、Addressable Asset System (Addressables)を使ってプロジェクト内のアセットを管理する方法をマスターしよう、といった感じでプロジェクトの目標を立てておきましょう。

このとき、ひとつのプロジェクトではひとつの目標に絞れるとグッド。

なぜなら、複数の目標があると行動がブレるためです。何かのついでにこれをやろう、なんて目標を追加してしまうと行動がブレてしまって逆に効率が悪くなったりするんですよね。

このページでは一度に取り掛かる目標は絞ろうぜ！　という点をあなたに訴えかけていきます(笑)

目的を増やすとブレる

よくやっちゃいがちなのが、〇〇をするついでに△△しよう、みたいな疑似マルチタスク。一回の行動で複数の目標を達成できるのは理想的ではありますが、二兎を追う者は一兎をも得ずのようにどちらも中途半端になってしまうか、あるいはなんとか両方達成したけれどもそれぞれ別で対応していた方が早かった、なんてこともあります。

目標は物理的な世界の目的地にたとえられることが多いです。

例えば今自分が東京にいるとして、大阪を目的地にする、みたいな感じです。

目標は大阪到達なので、物理的な世界だったら東海道新幹線を使って新大阪まで行って新大阪からは京都線か何かを使って大阪まで行く、なんて流れになります。

目的地がひとつだったら最短ルートで行くことができます。

しかし、目的地が複数あったとすると、回り道になることもあります。

目的地が大阪と宮城だったとしたら、先に大阪に行って宮城に向かうのか、先に宮城に行って大阪に向かうのか、どちらにしても単純に大阪に行くときに比べて時間がかかるのはイメージしてもらえるかと思います。2泊3日で同時に達成しようとなると、ほぼ移動で終わっちゃいますよね。

時間が潤沢にあるのならこれでもいいですが、専業ならともかく普段やっている本業のかたわらでゲーム開発をしているとなると、限られた時間で達成するのは難しい部分です。

プロジェクトでの成長ポイントの観点

プロジェクトが終わったタイミングが一番の成長ポイントなので、そのポイントを通る回数をいかに増やすかが成長の鍵です。このブログではPDCAについても触れていますが、「フィードバックと改善」が成長そのものなので、この回数を増やすことは大切です。最近ではOODAという考え方が広く使えて良いぜ！　という意見もあるので、お好みで使い分けてください。大事なのは実行することです。

エクスプラボ

普段使っているPDCAをゲーム作りにも導入してみよう【ゲーム開発】

https://ekulabo.com/pdca-in-game-dev

普段のお仕事でPDCAサイクルの考え方を使ってる方なら、ゲーム開発にもこれを導入することで作ったゲームの改善のプロセスを作ることができます。他の分野にある便利なものはどんどん取り入れちゃうのもおすすめですよ。

エクスプラボ

質より量か、量より質か。技術を学ぶ人々の永遠のテーマ【ゲーム開発】

https://ekulabo.com/quantity-or-quality

これ、迷う人も多いテーマだと思います。個人的な考えだと、「質より量」派です。継続して量をこなしていくことで自然と学びが増え、結果として効率よく質を改善していくことができます。量を意識するのは決して根性論ではなく、それ自体が質を高める方法なんです。

複数の目標があるとそれぞれを達成するまでプロジェクトの完了が遠のくので、中々成長ポイントを通れないんですよね。なので目標は絞るのがグッド。

ただ、目標を細分化していくつか小目標を作っておくのは良いことです。物理世界だったら、大阪に行くためにまずは品川に行って新幹線に乗る、みたいな感じです。

この小目標も、取り掛かっているときにはひとつの小目標に注目するようにすると行動がブレなくて済みます。

システム開発の大事な観点: 部品の再利用

ゲーム開発はシステム開発に含まれます。ここでシステム開発の大事な観点を思い出してみましょう。そう、部品の再利用ですす。

一度作ったものは使いまわして時間を短縮するのが大切です。例えば実装に10時間かかる作業について、以前作った部品を使うことで作業時間が5時間に短縮できたら5時間分早く仕事が終わります。これって成長の表れですよね。

冒頭で少し触れた以下の2つの実装をプロジェクトで使いたいとします。

• EventSystemsを使ったスクリプト間のメッセージング
• Addressable Asset System (Addressables)を使ったアセット管理

ひとつのプロジェクトでEventSystemsを実装してマスターした場合は、他のプロジェクトでも使いまわせる形で部品として取り出せるようにします。EventSystemsの場合は部品化というよりはどんなインタフェースを実装して、どんなメソッドを実装するか、といった手順をマスターする意味が強いかもしれませんが、サンプルコードは残ります。

一度実装したものは別のプロジェクトで使うことも簡単です。しかも部品化する過程で必要な機能を集約することにもなるので、より質が高い状態で別のプロジェクトで使えます。

そうすると、EventSystemsのことはほとんど心配することなくAddressable Asset System (Addressables)の実装に取り組むことができます。

人間はマルチタスクが苦手

脳神経学者の枝川義邦さんによれば、『「人間は本質的にマルチタスクはできない」といったほうがいいくらい』なようで、複数のことをこなしている姿はスマートに見えてそこまで効率が良くないようです。というか脳にダメージを与える行動なので避けた方が良いくらいだそうで。

PRESIDENT Online（プレジデントオンライン）

 

126 Pockets

人間は本質的に"マルチタスク"はできない 「一点集中」を続けるのが効率的

https://president.jp/articles/-/28147?page=1

一点集中とマルチタスク、どちらのほうが仕事の効率は上がるのか。脳神経科学者として、迷わず「一点集中」と答えます。脳はマルチタスクが苦手で、「人間は本質的にマルチタスクはできない」といったほうがいいく…

個人の経験からもこれは実感していて、複数のことを同時に進めようとすると思ったほど効率良く進まないどころか逆に時間がかかっていたことに気付きました。ひとつひとつ片付けていった方が最終的に早いというのは感じます。

プロジェクトの評価も難しい

プロジェクトの振り返りを行う際、目標が複数あるとプロジェクト自体の評価も難しくなります。例えば2つの目標があった時に、両方できてプロジェクトを成功にするのか、それとも片方達成できただけでも成功にするのか、といったブレが生じます。おそらくプロジェクトを計画している段階では「両方できて成功だ！」なんて意気込んでいると思いますが、蓋を開けてみたら片方がべらぼうに難しくて実装を断念した、なんてこともあり得ます。

片方できて片方できずだと、改善策を考える際にはできなかった方に注目してしまって、できている方の改善にはあまり目が向かないなんてこともあるかもしれません。

もちろん両方改善点を見つけるというのが理想ですが、片方できなかったからプロジェクト失敗だ！　なんて自分を追い込んでしまうと自信を喪失することにも繋がりかねません。

可能ならひとつひとつできるようになって自信を積み上げていきたいと思っていますが、これはあくまで私がそうしたいだけなので、考えた結果複数の目標を掲げるべきである場合はそれを否定するものではありません。時間的な制約もあってひとつのプロジェクトしかできない場合なんかは複数の目標を掲げることもあると思いますからね。

まとめ

ひとつのプロジェクトでは技術的な目標についてはなるべく絞ると行動がブレなくて済みます。

これはあくまで技術習得の観点からの話なので、複数の目標を掲げる場合もあるかもしれません。その場合でも、それぞれの目標をについてひとつずつ達成していくと集中して作業を進めることができます。