スケジュール管理の必要性をどう伝える?

スケジュール管理って必要か?

と問われれば、そりゃ必要だ、と答えます。
むしろなんで要らないと思うんだ、ぐらいは言いそうです。

ですが、たとえば学校の制作で「スケジュール切ってね」というとたいてい切られません。先生方が切ってくれたりもするんですが、見られた形跡が無いことが多いです。

……なぜ?

と考えて、我が身を振り返ってみるに。
自分も学生時代にスケジュール管理なんてしてなかったです、はい。

あ、ここで言うのはガントチャート的な、かなりきっちりと引くヤツを指してます。

バイトの日とか、テストの日とか、なにかしらの発売日とかをカレンダーに書くのはやってましたけど、それくらい。
工数を考えてガントを書くのは、会社員になってからだと気づきました。

……なぜ?

ってそりゃ、管理する必要があるような状況を体感してないからですよね。
文化祭の計画とか、みんなで何かするときには生徒会でガントぽい物を引いた記憶はあるんですが、全員が見てるわけではないですし。

開発現場に行ったら、大量の作業がパラレルでやってきますから、ある程度自分でスケジュール管理しとかないとあっという間に破綻します。

で、破綻してから立て直すのはしんどいので、今のうちに覚えて貰おうと思って「スケジュール書いてね」って言うわけですが──。

言われたからやる、とかしんどいだけ(書かされ感満載)だし、必要に迫られないと「腹オチ」しないのは当然。

やっぱ「これ必要だから書かないと」って状況にならないとやらんなぁ、と反省したところです。

で、最悪現場に行ったらスケジュール書かされますし、プロジェクト全体のスケジュールとガントチャートはディレクターなりチーフなりが引きますから、そこで覚える、というのもありかと思います。OJTと割り切って。

でも、先に必要性を知ってもらって、書き慣れているのに越したことはない。

■じゃあどうやって「必要性」を体感して貰うか?

「ガントがあった方が便利だし、楽に進められる」というのを実感してもらうコト、かなと考えてます。

ですので制作の際に、1回は(ディレクター的な立場で)スケジュールを横で管理してサポートするのがいいのかなと。
それで、なるほどこれは有った方がいい、無いとダメだ、ってのを感じてもらうのがいいかなと思っています。

「とにかく書いてね」ではいきなり書けないし、「スケジュールを書く」っていうよくわかんないタスクが振ってくるだけで、これは意味が無い、はず。

というかこれ、「教える」とか「伝える」こと全般そうですよね。

経験がある人にとっては「必要だってば!」って思うことも、経験してないと分からないのは当たり前。
ある程度は人によりますが、一度失敗して、そっかーこれはスケジュール引かないとしんどいなー、なら書くか、って「体験」を通さないとやらないよね、と思います。

まあ、なにより、僕自身がそうでしたし。

Zaurus、Palm、Outlook/Windows Mobile、フランクリン・プランナー、ほぼ日手帳……などなど。
途中から道具に凝り出して失敗した気もしますが。
※今はほぼ日手帳+Plotter(バレットジャーナル)で管理してます。

スタッフロールの価値と意味

たぶんドラゴンクエストIIあたりだと思います。
小学校3〜4年生くらいでしょうか。

ゲームをクリアするとエンディングになって、スタッフロールが流れて、そこに名前の並んでいる人たちがこのゲームを作ったんだー!って認識したのは。

その頃読んでいたゲーム誌が「ファミリーコンピュータ Magazine」。
そこには開発者の方がインタビューなどで出ていて(記憶にあるのは宮本茂さん)、この人達が作ってるんだ……って、ワクワクしながら読んだのを覚えています。

あんまり自覚はしてなかったんですけど、「ゲームのスタッフロールに自分の名前が載る」のは夢だったかもしれません。
……当時は、「スタッフロール」という名称すら知らなかったわけですが。

それから十数年。
loose@rouseの「電脳遊戯」(いい曲です!)のごとく大人になって、幸いにもゲームを開発するお仕事に就いて。

初めてスタッフロールに、開発者として名前が載ったのは「鉄拳6」でした。
開発が終わって、製品版を手にとって、最後までクリアして。
エンディングで流れるスタッフロールに自分の名前を見つけたときは、なんだかすごい達成感みたいなものがありました。
(正確には開発中とかデバッグでさんざん見てたんですが、製品で見られるのはちがう感動があります)

一昔前には、引き抜きを防ぐためとかさまざまな理由でスタッフロールが無い時期がありました。あっても本名じゃなかったりとか。

でも、2018年現在、そういう時代でもなくなったわけで。

何が言いたいかというと、スマホゲームとかの運営型ゲームや、MMOでももっとスタッフロール出せばいいのにー!っておもいます。

確かに工数はかかるんですが、プレイヤーさんにとっては「この人のシナリオが」とか「この人のプログラムが」とか知って貰えるのは、ゲーム業界を目指すきっかけになるかもしれないです。開発者にとっても嬉しいものですし。かけたコスト以上の価値はあると思ってます。
売り上げに直結する仕様じゃないので、外されやすいっちゃそうなんですが、だからこそ「あって当たり前」になってほしいなー。

Fate/Grand Order とか、エンディングとスタッフロールがあるゲームがありますし、configの中で見られるタイトルもいくつかあります。

ということで、スタッフロールが見られるゲーム、増えるといいなぁ……。

呪いを解いた先に

頭が固くなりました。

子どもの頃から、頭の柔らかいほうではなかったとおもうのだけど、時間を重ねてある日気づくのです。

うっわ思考が固まってる!

仕事中に、いろんな可能性を検討しているつもりで、「あることをやってはいけない」というのを盲目的に信じて、他の可能性を排除して──そこで思考停止していること。
止まるな危険!なのです。

一度思考停止してしまうと、その「呪い」とも言えるものは、自分の中に拡がっていく、って感じました。

この部分って、他人に言われないと気づきにくいのかもしれません。
自分で気づいてたら何とかするわけですが、「気づく」ための自身のOSに、ある意味バグがある状態なわけで。
その状態のOSが、自身のバグを認識するのはなかなか難しいのでは、と。

といって、人に言われても「あぁ?」ってなりやすい部分でもあるので、ここはアレです。

自分で「これは○○すべき」って思ったら、
そしてそれがどこか違和感があったり苦しかったりしたら、

「ほんとにそうか?」って、
自分に「なんで?」って、
問いかけてみることかな、と。

会社に行かなくちゃいけない!
……なんで?

勉強しなきゃいけない!
……なんで?

ご飯は残しちゃいけません!
……なんで?

人に迷惑をかけてはいけません!
……なんで?

ここで「当たり前だろ!」って思うのが思考停止。

それぞれに理由があるだろうし、それぞれの環境は違うので、一律「こうあるべき!」なんてのは無いです。

特に物作りするんであれば、「なんで?」を自分に対して重ねまくるのは、ホントに重要だとおもいます。

かなり気をつけていたつもりだけど、いつの間にか忘れてる。

ということで改めて、

ゲーム作らなきゃいけない!
……なんで?

実装者が仕様を切る、のか?

ゲーム開発をしていると、内容が曖昧なタスクが多いことに気づきます。
これがいろんな問題の根っこになっていることが多いんだな、ということにも。

たとえば──パラメータの上限下限

レベルの上限とか、HPの最大値とかそういうやつです。
いや、そんなのプランナーが決めて仕様書に書いてあるだろ?と思われるかもしれませんが、ものによってはなかったりします。ていうか無いことが多い。

UIに表示される、つまりプレイヤーの目に触れるモノについては、さすがに仕様書に書いてあります。最大レベルは999、とか。

ここで言うのは、内部パラメータとかのことです。

たとえばキャラクターID。
ゲーム中の、プレイヤーが手にするキャラ1体ごとに振られる、ユニークな番号です。仕様書にもそう書いてあったりします。で、初期キャラは12体、後から追加の予定あり、とあります。

ここで、じゃあいくつくらいまで増える見込みなのか?は、誰も分かりません。でも、実装するときには、idを持つ変数のサイズを決めないといけません。通信経路にも乗るデータなのでなおさらです。

何も考えずに uint64 とかやるとあとでしんどいことになります。
具体的にはデータベースエンジニアさんか、ネットワークのインタフェースの実装者に怒られます。怒られるくらいならいいですが、いったん稼働しちゃったら、この辺を直すのは大変です。

あとで Alter すればいいじゃん、とか気軽に言っちゃだめです。
(ゆえに、オルタって単語を聞くとちょっとびくっとします。癖です)

だって、最終的にキャラは100体行かないと分かっていたとしたら、 uint64、つまり42億もサイズがあっても無意味です。tinyint で充分です。

でもですね、最初の段階では、キャラがどれくらい増えるかは不明です。
不明なんですが、プログラマは変数のサイズを決めないとコードが書けません。じゃあってんで、最大取っておけばいいだろうと uint64 で(以下略。

そうなると、プログラマがプランナーに聞くわけです。

キャラって毎月何体追加予定?って。

そうすると、イベントで2体、最大で4体かなぁ、10体は物理的に作れないから、2桁になることは無いとおもう、みたいなのが出てきます。

それを聞いてプログラマは、じゃあ運営が10年続くとして(かなり長い)、尽きに最大10体増える、とすると、初期の12体を加算して、

12 + (10×12)×10 =1212

運営チームがめっちゃ頑張ってキャラ作りまくって、売り上げもよくて10年続いたとしたら、最終的に 1212体になる、と。
tinyintでは足りないけど、smallint なら十分だな、と分かるわけです。
少なくとも uint64 なんて不要だ、と判断する、ってわけです。

そしてこれはプログラマの仕事なのか、プランナーの仕事なのか。

経験上、両方の仕事、気づいた方がやればいいじゃん、と思ってます。

さすがにHPの上限とか、表示物の最大桁数が「わからん」だったらプランナーが考えろ、になります。でも、こういうゲーム本体と実装の狭間にあるものは、プランナーとプログラマ、さらにはデザイナーも一緒に顔をつきあわせて考えていくのが、事故が無いかなとおもいます。

事故るのは、「仕様は切ったからあとはよろしくね」ってプランナーが投げちゃう時。ほんとうに「全部」仕様書にあればいいですけど、たいてい何か抜けてます。実装している最中に見つかる穴も山ほどあります。

ですんで、

プランナーは、担当部分の仕様を切ったら、実装を手伝って、デバッグして、書いた仕様通りに動いているのを確認する

までが担当業務です。

ですから、ハードウェアの特性やプログラムのことは知っている必要がありますし、デザインやUIについても「担当じゃ無いから知らん!」ってのはよくないです(というか僕はそういうプランナーだと一緒にやりづらいです)。
分からないなら、目の前にプログラマなりデザイナーなりのプロが居るわけですから聞くべきですし、自分でもある程度は勉強して知っておきましょう。

ということで、自戒を込めて、なのでした。

 

ゲーム好きはゲームを仕事にできるか?

「好きなことを仕事にするといいよね」
とか、
「好きなことで食べていけるとかうらやましいよね」
なんて言われることがあります。

同時に、
「好きなことを仕事にするのはやめたほうがいい」
とか、
「仕事と趣味は別にしたほうがいいよね」
というのも聞かれます。

どっちなんでしょう?

今のところ、僕は一つのシンプルな答えはないとおもっています。
でも、いくつかの「やり方」はあるのかな、と気づいてきました。

それは、

1)好きなことを掘り下げまくってから、それで稼ぐ方法を探す
2)一番好きなことと同じくらい、好きなことを見つけておく
3)無理に目的を探さない

というところかなと。
それぞれ説明してみますね。

1)好きなことを掘り下げまくる

「ゲームが好き」なので、「ゲームの仕事」をしたい。
それはいいとおもいます。僕もそうでした。

ですが、「ゲームが好き」だからといって「ゲームを作るのが好き」とイコールではないはずです。
おそらく最初の「ゲームが好き」は、「ゲームをプレイするのが好き」であるはず。だとしたら、それをいきなり作る方に回ったとして、おなじ「ゲームが好き」のままであるとは考えにくいです。

ですので、「ゲームが好き」なら、自分はゲームを「どう」するのが好きなのか、というのを考えてみる必要があります。

ゲームで遊ぶのが好きなのか。
→一人で?PVPで?MMOで?ランキングを極める?
ゲームを語るのが好きなのか。
→シナリオを?キャラを?ゲームシステムを?メカニクスを?

……みたいな感じで、自分に「なぜ?」って掘り下げまくっていきます。

たぶん最初は、「あ、今はゲームを一人でプレイして、好きなキャラを育成するのが好きみたいだな」とか分かってきます。

でも、ゲームを仕事にしたい、としたら。

ゲームに関わるいろんなことをやってみたらいいとおもいます。

遊ぶのはもちろん、
・作ってみる(専門学校とかゲームジャムとか、なんなら家でもできます)
・売ってみる(販売店でバイトとか)
・イベントしてみる(身内でゲーム大会してみるとか)
・語ってみる(ブログ書くなりライターに応募するなり)
とかとか。
いろいろできます。

で、そのなかで、ゲームとどうつきあうのが「らく」かな、ってのを見つけていけば良いと思います。たぶんこれが、学生時代の大きな目的の一つなんだろうと、最近考えています。

2)ゲームと同じくらい好きなことを見つけておく

これは、作家の先輩がおっしゃっていたことでして。
僕自身が身にしみて感じたことでもあります。

というのは。

ゲームが好きで、つくってみたい、コレを仕事にしたいとおもってゲーム会社に入って。もちろん開発は楽しいんですが、しんどいこともたくさんです。

スケジュール遅延、ボツ、突然の差し込み作業、ハードウェアトラブルetc。
そうすると、どうしても「もうゲームつくるのしんどい!」ってときがあります。

ゲームを仕事にする前は、たとえば学校でやなコトがあっても、家に帰ってゲーム機の電源を入れてストレス解消!ができました。

ですが、ゲームを仕事にしてしまうと、それができなくなります。
ゲームを作るのが仕事なので、それ自体が、自分の回復に使えなくなるときがあります。しかも、一番回復して欲しいときに。
その上、その回復方法を封じたのは自分自身なのです。だって、一番好きなことを仕事にしたのは、自分なんですから。

これを回避するための方法はひとつ。
ゲーム以外に、ゲームと同じくらい好きなことを見つけておく!
です。

3)無理に目的を探さない

これは理性では理解してるんですが感情でまだもやっとしてることでもあります。つまり、「ゲーム開発者は、全員が、どうしても作りたいゲームややりたいことがあってゲーム会社にいる」わけではない、ということです。

最初はゲームが好きで、作ってみたら楽しくて、それを外に公開して遊んでもらって、感想もらったらめっちゃ嬉しかった、のでこれを仕事にしたい、みたいな始まりだとおもいます。

それを何年か、何十年か続けていくと、作りたいものを見つけたり、一緒に作りたい仲間に出会えたりします。

順番の問題です。
開発者になるなら、作りたいモノややりたいコトを見つけなきゃ!……っていうのは、おそらく、逆です。

人によっては(とても少ないと思います)、最初から「どうしてもコレが作りたいんだ!」って強く思っている人も居ます。

でも大多数は、もっとゆるやかな、「ゲーム開発者で食っていきたい」くらいなんだろうと思っています。

というのは、僕自身が勘違いし続けていたからで。
作りたいものって、無理矢理見つけるものなんかじゃなかった。
作っていく中で、ある日見つかるかもしれないし、見つからないかもしれないし。そういうものなのではないか?って。

なのでまずは、手を動かして何かを作ること。
作ったら他人に見せて、感想をもらうこと。
その時、自分はどう思ったか──感情が、どう動いたか?──を注意深く見ること。

で、まずは「とりあえずやってみる」。
次に「人に見せる」。

これに尽きると思っています。

「できるようになってからやる」だと、人生短いんで何もせずに終わります。
マジで。

ゲームの根っことアクションのリスク

ゲームには目的と手段があります。

プレイヤーは手段=アクションを使って目的を達成する、というのが基本的な作りです。
だからEMSフレームワークなんかを使って、目的と手段を置いて、そこから膨らませたりするわけです。

が、最近気づいたのは、

アクションにメリットしかないように作ってしまう

ということ。

言い換えれば

アクションすることそのもののリスクが無い

ってことです。

敵に当たればダメージを受ける、穴に落ちればミスになる、のは良いとして。
プレイ中に一番多く行うであろうアクション=手段をするところに、何のデメリットもないとすると

・成功か失敗のどちらかしかない
・アクション自体は失敗しない

なんてことになりやすく、プレイヤーが速く飽きます。

リスクを取ったときにメリット(リターン)があれば、そこに緊張感とか達成感とかの感情が生まれます。

この辺の感覚は、プリミティブなアクションゲームをいっぱいプレイするのがよいだろうなーと。
やっぱり任天堂は偉大です。

 

 

ゲームにおける「反応」

なにか行動をしたときに、反応があると素直に嬉しいです。

逆に無反応だと凹みます。やる気も霧散しますし。

「反応なんか要らない、ほっといてくれ」って人はあまりいないとおもいます。

ですんで、ゲームにおいてもおんなじです。
ゲームはある意味、現実世界を模倣したり、デフォルメかけたりしたものですから、

ゲーム中でプレイヤーが何かする(アクションを起こす=操作する)

ゲーム内で何かが起こる(プレイヤーに反応を返す)

というところが、現実よりも強く起こった方が「面白い」です。

だから、プレイヤーがアクション……ジャンプするとか斬るとか走るとか……をしたときに、それがいろんな結果(失敗含む!)を招くように設計します。

で、このインタラクション(相互)関係──が、ゲームの面白さの根っこです。

ギミックが面白い!ではなくて、そのギミックに立ち向かって試行錯誤し、プレイヤーが何か行動を起こす度に帰ってくる反応を見て、さらに次のアクションを考える、という過程が面白いからこそ、面白いのです。

過程というのはつまり(さっきから同じコト繰り返してます)、プレイヤーが何かしたら、ゲームから何か反応が返ってきて、それを見てプレイヤーが次のアクションを考え……という繰り返しのことです。

これ、なんとなくゲームシステムを組んでいるとできません。
ましてや、いろいろオブジェクトギミックと敵キャラ配置しておけば何か起きるだろう、なんてのは論外です(何も起きません)。

・プレイヤーに何を感じさせたいのか?
・このゲームではとことん笑わせたい!
・では、何を見せたらプレイヤーは笑うのか?

のように、「プレイヤーに何を体験させ」「それを体験したプレイヤーに何を感じさせる?」というのをずーっと考えていく必要があります。

で、その思考の根っこ、アイデアの種になるのが、自分自身の体験です。

「こういうことをしたら、こんな反応が返ってきて、こんな気分になった」

という体験から、対象を変えたりデフォルメしたりして、同じ気分=同じ楽しさを再現する、というところが根っこになります。

田尻さんの、子ども時代の虫取りの体験からポケットモンスターの企画を作った、というのは有名ですよね。

そんなわけで、ゲームを作るための基礎体力。

体験を買いましょう!(Amazonにも本屋にも売ってませんが、そのへんに転がっています。いくらでも。そしてどれも安価です)

「終わらせる」体験を

インスタントな解決方法や手段が求められる時代だなぁとおもいます。
なんでそうなるんだ、ってのを友達と話しておりました。

要約すると、

・損をしたくない、という意向

これが根っこなのかなー、と考えました。

食べログ3.5点以上、とかAmazonのレビューで★4つ以上、とか。
それって「変なモノ買って失敗したくない」=「損したくない」ってことなのかなぁと。

もちろんそれはそれで「参考までに」見るのは(僕もしますし)ありだと思うんですが、どこかの段階で「自分で決める」ことをしないと、他人の評価にベタ乗りになっちゃいます。

レビュー評価が高い、ってのはある程度正しくもありますが、いくらでも操作できるのは周知の通りなので「目安」でしかないです。
なにより、レビュー書いた人はどこかの誰かですから、その人の感想と自分の感想が同じになるとは限らないです。

とはいえ、星の数見て判断するというインスタンスな解決方法、しかも責任を自分以外のどこか(めちゃめちゃ曖昧ですが。/dev/null みたいなもんか)に押しつけられるという便利さ。

 

これって、自分の好きなジャンルのものだったら、それなりに目利きはできるようになるわけです。レビューとか見なくても。

そうなるためには、自分の判断で買って、失敗して、損して、できる限り使おうとしたり読もうとしたり遊ぼうとしたりして、自分の中で「終える」ことで経験値が溜まっていくんだ、とおもっています。

これをインスタントに解決する方法とか、ライフハック的なモノはないです。断言できます。

 

同じように、ゲーム開発の目利きも、自分(チームで)で作り始めて、ちゃんと企画を完成し、実装し、デバッグし、少なくとも自分の中では「完成した」というところまで持っていって、要約経験値がもらえます。

途中で投げたら経験値はゼロのままです。

下手だろうがゲーム未満だろうが、最後まで作るのが超絶大事です。

これは先述の「終わらせる」ってことと同じだと考えています。

 

時間も手間もHP/MPも消費するのでたいへんです。
でも、だからこそ、その仕事に価値が発生するんだとおもいます。
インスタントに身につけられて、誰でもできるならこんなに「プランナーが足りない!」なんてことにはならないわけですから。

ということで。

最後まで「終わらせて」みましょう!

浴びるほどゲームをしましょう

ゲームは一日一時間……と、高橋名人がおっしゃってました。

子どもの頃も、今も、守ったことはあんまなかった気がします。
今は仕事なので一時間ってわけにはいかないですし。

最初のゲーム機はファミコンでした。
父の友人の家にあって、「スーパーマリオブラザーズ」を触らせてもらって、夢中になって。それを見た父が買ってきてくれたのがはじまりです。

ドラクエIIIは初めて発売日に買い、スーパーファミコンも発売日、PC-Engineとメガドライブは友達の家で遊びつつ、任天堂ハードメインでした。
高校の時にPlayStationが出てやっぱり買い、間にNEO GEOをはさみつつSEGA SATURNもやってきて、ついでにPC-FXもやってきて。

ほんと浴びるほどゲームしてたと思います。
誰に言われるわけでもなく。

ゲームの世界観とかシナリオを気にしだしたのは、たぶんドラクエIIあたり。
パーティメンバーが増えるごとにフィールドの曲が変わる、ってのにびっくりして、脳内で再生し続け、サントラ(当時はCD持って無かったのでカセットテープ)買って聴いてました。

それから、エニックス(当時)の出版部門が出してた「ドラゴンクエスト アイテム物語」って本があって、おそらくこれの影響が大きいです。
これと「4コマ漫画劇場」シリーズに、「精霊ルビス伝説」。

世界観の補強とか、「実はこういう由来があってね?」的な、今だと当たり前のように出る「設定資料集」みたいなものなんですが、当時、本屋で買える「ゲームの設定資料」ものとしてはほぼ唯一だったと思います。

そんな折、買っていたゲーム誌「ファミリーコンピュータマガジン」のコラムに、ゲーム開発者になるのはどうしたらいいか、というテーマの回がありました。

開発者さん(宮本茂さんだった気がする)の回答が、

浴びるほどゲームをしてください。いつか飽きます。
そしたら作りたくなります。

みたいなことが書いてあって。

当時は「ふーん?」くらいだったんですが、今振り返ってみるとよく分かります。

浴びるほどやらないと、作るためのネタの引き出しが埋まらないので、アイデアを「組み合わせる」ことができないからです。

なにより、「作りたい!」って思うには、自分の感情が強く揺さぶられるような体験があった方が良いので、そんなゲームに出会うために、プレイしまくることがどうしても必要です。

その一方で、ゲームがこれだけ浸透して一般にも(それなりに)認められるようになってきたので(ありがたいことです)、「どうしてもゲームを作りたいんだ!」っていう激情を持った人だけではなく、「職業選択の一つとして、ゲームに関わることがしたい」って人も増えたようにおもいます。

そういう人に、めっちゃ情熱持って「ゲームやろうよ!」って言ってもやりたいこととずれる(ゲームは好きだけど、そこまで好きじゃない)のが悩みどころでもあったりします。

技術的にというか、淡々とくみ上げていってゲームを作ることもできるんですが、ゲームって嗜好品なので、そういうゲームを「面白い」と思うかはまた違う気がしていて。

なので今のところは、ゲームを「作りたい」のだったら、浴びるほど、飽きるまでゲームをやってみる、というのが近道かなとおもいます。

「プランナー」が足りない

ゲームプランナーでいい人いませんか、というご相談がよくあります。

会社員でゲーム開発していた頃(2000年代)は、それほど「プランナーが足りない!」ってことは無かった気がします。
スマホアプリがゲームの主流になってから、どこに行っても「プランナー(ディレクター)が足りない!」という話を聞くようになりました。

2012年くらいの「プランナーが足りない」ってのは、

・それまでゲームを作ったことのない会社がスマホアプリに参入、
ゲームを設計するための人材が欲しい

・スマホゲームが巨大化してきて、そもそも人が足りない

あたりの理由が多かったような気がします。
ゆえに、コンシューマ開発からだいぶ人が移動していきましたし。

それから数年、2018年現在。
同じ理由もありつつ、ゲームアプリが成熟してきた(コンシューマゲームのたどった道を、その何倍もの早さで進化してきた)ため、「できるプランナーが欲しい」というのに変わってきています。

そりゃまぁ、プログラマでもデザイナーでも「できる」人の方が欲しいに違いないので、これ自体は変なことではないです。たぶん。

プランナーってある程度現場最適化する生き物だと思うので、現場で育てればいい……のですが。
なにより、どの開発現場も忙しすぎて、新人を育てる時間がないです。

これは、

・ネットワーク仕様がデフォで入るようになった
・運営フェイズがほぼ必須になった

というので、ずーっと開発が続くのが大きいと感じてます。

その分、スマホゲームのPDCAは(コンシューマよりは)早く回せるので、育つ人は育ちます。勝手に。
それはもう、獅子を千尋の谷に突き落とすみたいなハナシなので、あんまり環境としてはよろしくなさそうです。ていうかよくない。

そもそも、プランナーを「育てられる人」ってのが希有です。
だって、ゲームを作りたくて会社に入ったんだから、そりゃ自分で手を動かしてゲーム作りたいですもん。

さらに、かつてゲーム会社は都市部に集中してましたから、地方だとそもそも「プランナー経験者」がいなかったりします。
そうすると、育てるにしても先輩が居ないのでどうしようもない、という状況になります。

そのうえ、プランナーの仕事は多岐にわたるので、リモートでやりにくい面もあります。
仕様書を切るとか、データ作るとか、シナリオ書くとか、一部を切り出すのは可能です。
でも、ディレクションやプランニングに関しては、リモートだとまだまだ工夫が必要ですし、「人を育てる」となるとリモートはかなり厳しい現状です。

とはいえ、リモートワークでプランナーは可能だと思ってます。
ネットワーク、チャットツール、クラウドサービスなどの環境は整ってきてますし、社内にいても、協力会社さんやフリーランスのクリエイターはリモート対応です。
ですんで、リモートのプランナーをチームに組み込みのは、メンバーの慣れと、「仕組み」(チャットで悪い感情のやりとりをしない、とか資料は一カ所にまとめて誰でも見られるようにする、とか)の問題と考えてます。

そうすると、プランナー不足ってのはある程度、リモートワークで解決できると思ってます。ある程度。

・仕様書を書く
・レベルデザインをする
・パラメータ設計をする
・シナリオ執筆
・デバッグ(コンシューマはまだ難しいけど)

……あたりはリモートでも問題なくできそうです。
というか自分がやってみて、まぁなんとかなる、という感覚です。

現場に居ないとやりづらいことが残るわけで、それが何かって考えてみました。

・PCや機材のセットアップ
・メンバーのモチベーション管理

この辺の物理的なことはリモートでは難しい。
※VRとかロボットとか駆使すればいつかはできそう。

それ以外で、これが重要、と思ったのは

「ゲーム開発」という、巨大でぼんやりしたタスクを、プログラマさんやデザイナーさんが手を動かせるレベルまで細分化する

ということなのかな、と。
これができるプランナーが、どこも欲しいんじゃないかと。

品川・BNG未来研究所(2015年当時)

単に「タスクを割る」のはけっこう機械的にできます。
でも、ゲームの場合、コンセプトやゲームメカニクスを理解し、ゲーム制作全体の流れを知った上で、タスクを作らないといけないわけで。
(でないと、「チュートリアルを作る」ってタスクを渡されても、新人さんは「?」となります。なんでチュートリアルが必要で、どういうUXで、長さはどれくらいで、素材は何が必要で……と分かった上でタスクを切らないと、経験の無いプランナーは、予想でタスクを切るしか無くなります。そしてコンセプトがずれたり、全体の流れがゆがんだりしはじめます)

ここに、プランナーの経験とか知識が必要なのではないかとおもってます。